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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

--
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



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux