2018-02-21 18:46 GMT+01:00 Bartosz Golaszewski <brgl@xxxxxxxx>: > 2018-02-21 18:05 GMT+01:00 David Lechner <david@xxxxxxxxxxxxxx>: >> On 02/21/2018 06:01 AM, Bartosz Golaszewski wrote: >>> >>> 2018-02-20 19:39 GMT+01:00 David Lechner <david@xxxxxxxxxxxxxx>: >>>> >>>> On 02/20/2018 07:33 AM, Bartosz Golaszewski wrote: >>>>> >>>>> >>>>> 2018-02-19 21:21 GMT+01:00 David Lechner <david@xxxxxxxxxxxxxx>: >>>>>> >>>>>> >>>>>> This series converts mach-davinci to use the common clock framework. >>>>>> >>>>>> >>>>> >>>>> Hi David, >>>>> >>>>> just some quick results from today's playing with v7. >>>>> >>>>> I started out with da850-lcdk with my standard rootfs over NFS. I was >>>>> not able to boot to console so far. The first problem is that mdio >>>>> fails to probe: >>>>> >>>>> libphy: Fixed MDIO Bus: probed >>>>> davinci_mdio 1e24000.mdio: davinci mdio revision 1.5, bus freq 2200000 >>>>> davinci_mdio 1e24000.mdio: no live phy, scanning all >>>>> davinci_mdio: probe of 1e24000.mdio failed with error -5> After some >>>>> digging I noticed that the supplied clock rate differs >>>>> between mainline (114000000Hz) vs common-clock-v7 (18000000). Since >>>>> we're not setting the rate in mdio, using LPSC_SET_RATE_PARENT would >>>>> not help like with lcdc. >>>> >>>> >>>> >>>> Can you post the output of this command so that I can see how your >>>> clocks are setup: >>>> >>>> cat /sys/kernel/debug/clk/clk_summary >>>> >>>> >>>>> >>>>> After that, the boot just hangs without ever getting to emac's probe. >>>> >>>> >>>> >>>> Using your workaround, can you run: >>>> >>>> cat /sys/kernel/debug/pm_genpd/pm_genpd_summary >>>> >>>> If you see: >>>> 1e27000.clock-controller: emac off-0 >>>> >>>> then genpd is not working like it is supposed to. You should see >>>> something >>>> like this for device that are working: >>>> 1e27000.clock-controller: uart2 on >>>> /devices/platform/soc@1c00000/1d0d000.serial active >>>> >>>> >>>>> >>>>> Once I set the emac clock to always enabled (a workaround that was >>>>> necessary with v6, but could be dropped with my first >>>>> genpd-in-a-separate-driver attempt), I'm getting a rather strange NULL >>>>> pointer dereference: >>>> >>>> >>>> >>>> I noticed this too when adding the power-domains property to some device >>>> tree nodes. This is part of the reason why I didn't add it everywhere. >>>> I wasn't able to figure out the cause of this yet. As a work around >>>> though, please try removing the power-domains property from the emac >>>> and mdio nodes and use your previous workaround of having an always >>>> enabled clock. >>>> >>>> >>> >>> When I use any of the workarounds I just keep getting more problems >>> (e.g. [1] from blk and pinctrl). I only had a couple hours today to >>> play with it but it seems to me we have some memory corruption >>> somewhere. I'll check the initialization order of all the frameworks >>> involved tomorrow. >>> >>> Best regards, >>> Bartosz >>> >>> [1] https://pastebin.com/75mkkuJL >>> >> >> I wonder if we need to delete all of the __init and __initconst attributes >> now that this has been converted to platform devices. >> > > Duh... Of course we do. IIRC everything in the init section gets > removed after late_initcall. I'll test that tomorrow. > > Bart It's not that. Not only anyway as it doesn't fix anything, I'm getting the exact same panics. I tried to play with various settings, like initializing the platform driver later in the boot sequence etc. but haven't yet figured out what's going on. Bart -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
