Re: [PATCH v7 00/42] ARM: davinci: convert to common clock frameworkâ

[David Lechner]

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.