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

[David Lechner]

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.

> Backtrace:
> [<c049d464>] (strlen) from [<c01f32a8>] (start_creating+0x58/0xc0)
> [<c01f3250>] (start_creating) from [<c01f34c8>] (debugfs_create_dir+0x14/0xd8)
>   r7:c04dadbc r6:c0567480 r5:c0656274 r4:c68a9300
> [<c01f34b4>] (debugfs_create_dir) from [<c0296838>]
> (clk_debug_create_one+0x28/0x1d0)
>   r5:c0656274 r4:c68a9300
> [<c0296810>] (clk_debug_create_one) from [<c05cdf84>]
> (clk_debug_init+0x100/0x15c)
>   r5:c0656274 r4:c68a9300
> [<c05cde84>] (clk_debug_init) from [<c000a54c>] (do_one_initcall+0x50/0x19c)
>   r7:c05e3834 r6:ffffe000 r5:c05f7008 r4:c05cde84
> [<c000a4fc>] (do_one_initcall) from [<c05b6eb4>]
> (kernel_init_freeable+0x110/0x1cc)
>   r9:c05b4584 r8:c05b6614 r7:c05e3834 r6:c063cc80 r5:00000073 r4:c05f2354
> [<c05b6da4>] (kernel_init_freeable) from [<c04a2ce4>] (kernel_init+0x10/0xfc)
>   r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c04a2cd4
>   r4:00000000
> [<c04a2cd4>] (kernel_init) from [<c00090e0>] (ret_from_fork+0x14/0x34)
>
> It turns out that the emac clock is correctly registered in
> __davinci_psc_register_clocks() and a corresponding clk_core structure
> is added to the list and core->name is correctly assigned, but then
> later when clk_debug_init() is called, the name in emac clk_core is
> NULL. This is the direct reason for the panic. Interestingly other
> members of clk_core seem to be fine.
>
> I'll continue on debugging it. Let me know if you have any ideas.
>
> Best regards,
> Bartosz Golaszewski