2019.1 device tree changed clock for lpd_watchdog causing issues

[frosteyes]

Hi

Working on migrating a 2018.3 project for ZynqMP to 2019.1

When booting I see the following issue.

1.410449] zynqmp_clk_mux_get_parent() getparent failed for clock: lpd_wdt, ret = -22

Looking closer the issue is caused by the zynqmp-clk-ccf.dtsi - and the fact that lpd_watchdog have changed its clk to 112.

See https://github.com/Xilinx/device-tree-xlnx/blob/master/device_tree/data/kernel_dtsi/2019.1/zynqmp/zynqmp-clk-ccf.dtsi

Compared to PMU firmware defines it shows the clock 112 as PM_CLOCK_EXT_PSS_REF from PM_CLOCK_EXT_BASE and not the watchdog.

See https://github.com/Xilinx/embeddedsw/blob/master/lib/sw_apps/zynqmp_pmufw/src/pm_defs.h

Please elaborate - e.g. do we need a patch for the device tree, or should the PMU be updated to fit with the devicetree.

[frosteyes]

Have looked more into it, and written with a developer at Xilinx.

With the current code, it uses zynqmp_clk_mux_get_parent()

This again calls zynqmp_pm_invoke_fn(PM_CLOCK_GETPARENT, clock_id, 0, 0, 0, ret_payload);

Resulting in the call to PMU.

In PMU it will fail in PmClockGetById

PmClock* PmClockGetById(const u32 clockId)
{
        u32 i;
        PmClock* clock = NULL;

        for (i = 0U; i < ARRAY_SIZE(pmClocks); i++) {
                if (clockId == pmClocks[i]->id) {
                        clock = pmClocks[i];
                        break;
                }
        }

        return clock;
}

As pmClocks does not contain any clocks with the lpd_wdt clock.

So the PMU part of LPD_WDT is currently missing.

I can also see the issue is present in your own exampels - https://www.xilinx.com/support/answers/72602.html

Search for " getparent failed for clock”

I will fix it in my local setup currently with a device tree patch, and wait on a more correct solution from Xilinx.

[frosteyes]

Just a minor update.

The idea about devicetree does not work.

Instead I needed to patch the ATF (Arm Trusted Firmware) and just commented the CLK_LPD_WDT out for now, until Xilinx sends out a fix for the PMU.

[tsillanp]

Any update on this, and clarification from Xilinx side why we see this?

[frosteyes]

I have not head anything from Xilinx yet, so no update.

It is not super critical for me, as I can easily create a workaround, but would like to see it fixed with 2019.2