Messages in this thread | | | Subject | Re: [PATCH v7 00/42] ARM: davinci: convert to common cloc k framework | From | David Lechner <> | Date | Wed, 21 Feb 2018 11:05:41 -0600 |
| |
On 02/21/2018 06:01 AM, Bartosz Golaszewski wrote: > 2018-02-20 19:39 GMT+01:00 David Lechner <david@lechnology.com>: >> On 02/20/2018 07:33 AM, Bartosz Golaszewski wrote: >>> >>> 2018-02-19 21:21 GMT+01:00 David Lechner <david@lechnology.com>: >>>> >>>> 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.
| |