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

[Bartosz Golaszewski]

2018-02-21 18:46 GMT+01:00 Bartosz Golaszewski :
> 2018-02-21 18:05 GMT+01:00 David Lechner :
>> On 02/21/2018 06:01 AM, Bartosz Golaszewski wrote:
>>>
>>> 2018-02-20 19:39 GMT+01:00 David Lechner :

 On 02/20/2018 07:33 AM, Bartosz Golaszewski wrote:
>
>
> 2018-02-19 21:21 GMT+01:00 David Lechner :
>>
>>
>> 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 220
> 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 (11400Hz) vs common-clock-v7 (1800). 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@1c0/1d0d000.serialactive


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

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

[Bartosz Golaszewski]

2018-02-21 18:46 GMT+01:00 Bartosz Golaszewski :
> 2018-02-21 18:05 GMT+01:00 David Lechner :
>> On 02/21/2018 06:01 AM, Bartosz Golaszewski wrote:
>>>
>>> 2018-02-20 19:39 GMT+01:00 David Lechner :

 On 02/20/2018 07:33 AM, Bartosz Golaszewski wrote:
>
>
> 2018-02-19 21:21 GMT+01:00 David Lechner :
>>
>>
>> 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 220
> 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 (11400Hz) vs common-clock-v7 (1800). 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@1c0/1d0d000.serialactive


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

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

[Bartosz Golaszewski]

2018-02-21 18:05 GMT+01:00 David Lechner :
> On 02/21/2018 06:01 AM, Bartosz Golaszewski wrote:
>>
>> 2018-02-20 19:39 GMT+01:00 David Lechner :
>>>
>>> On 02/20/2018 07:33 AM, Bartosz Golaszewski wrote:


 2018-02-19 21:21 GMT+01:00 David Lechner :
>
>
> 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 220
 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 (11400Hz) vs common-clock-v7 (1800). 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@1c0/1d0d000.serialactive
>>>
>>>

 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

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

[Bartosz Golaszewski]

2018-02-21 18:05 GMT+01:00 David Lechner :
> On 02/21/2018 06:01 AM, Bartosz Golaszewski wrote:
>>
>> 2018-02-20 19:39 GMT+01:00 David Lechner :
>>>
>>> On 02/20/2018 07:33 AM, Bartosz Golaszewski wrote:


 2018-02-19 21:21 GMT+01:00 David Lechner :
>
>
> 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 220
 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 (11400Hz) vs common-clock-v7 (1800). 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@1c0/1d0d000.serialactive
>>>
>>>

 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

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 :

On 02/20/2018 07:33 AM, Bartosz Golaszewski wrote:


2018-02-19 21:21 GMT+01:00 David Lechner :


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 220
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 (11400Hz) vs common-clock-v7 (1800). 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@1c0/1d0d000.serialactive




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.

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 :

On 02/20/2018 07:33 AM, Bartosz Golaszewski wrote:


2018-02-19 21:21 GMT+01:00 David Lechner :


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 220
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 (11400Hz) vs common-clock-v7 (1800). 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@1c0/1d0d000.serialactive




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.

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

[Bartosz Golaszewski]

2018-02-20 19:39 GMT+01:00 David Lechner :
> On 02/20/2018 07:33 AM, Bartosz Golaszewski wrote:
>>
>> 2018-02-19 21:21 GMT+01:00 David Lechner :
>>>
>>> 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 220
>> 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 (11400Hz) vs common-clock-v7 (1800). 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@1c0/1d0d000.serialactive
>
>
>>
>> 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

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

[Bartosz Golaszewski]

2018-02-20 19:39 GMT+01:00 David Lechner :
> On 02/20/2018 07:33 AM, Bartosz Golaszewski wrote:
>>
>> 2018-02-19 21:21 GMT+01:00 David Lechner :
>>>
>>> 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 220
>> 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 (11400Hz) vs common-clock-v7 (1800). 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@1c0/1d0d000.serialactive
>
>
>>
>> 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

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 :

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 220
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 (11400Hz) vs common-clock-v7 (1800). 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@1c0/1d0d000.serialactive




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:
[] (strlen) from [] (start_creating+0x58/0xc0)
[] (start_creating) from [] (debugfs_create_dir+0x14/0xd8)
  r7:c04dadbc r6:c0567480 r5:c0656274 r4:c68a9300
[] (debugfs_create_dir) from []
(clk_debug_create_one+0x28/0x1d0)
  r5:c0656274 r4:c68a9300
[] (clk_debug_create_one) from []
(clk_debug_init+0x100/0x15c)
  r5:c0656274 r4:c68a9300
[] (clk_debug_init) from [] (do_one_initcall+0x50/0x19c)
  r7:c05e3834 r6:e000 r5:c05f7008 r4:c05cde84
[] (do_one_initcall) from []
(kernel_init_freeable+0x110/0x1cc)
  r9:c05b4584 r8:c05b6614 r7:c05e3834 r6:c063cc80 r5:0073 r4:c05f2354
[] (kernel_init_freeable) from [] (kernel_init+0x10/0xfc)
  r10: r9: r8: r7: r6: r5:c04a2cd4
  r4:
[] (kernel_init) from [] (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

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 :

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 220
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 (11400Hz) vs common-clock-v7 (1800). 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@1c0/1d0d000.serialactive




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:
[] (strlen) from [] (start_creating+0x58/0xc0)
[] (start_creating) from [] (debugfs_create_dir+0x14/0xd8)
  r7:c04dadbc r6:c0567480 r5:c0656274 r4:c68a9300
[] (debugfs_create_dir) from []
(clk_debug_create_one+0x28/0x1d0)
  r5:c0656274 r4:c68a9300
[] (clk_debug_create_one) from []
(clk_debug_init+0x100/0x15c)
  r5:c0656274 r4:c68a9300
[] (clk_debug_init) from [] (do_one_initcall+0x50/0x19c)
  r7:c05e3834 r6:e000 r5:c05f7008 r4:c05cde84
[] (do_one_initcall) from []
(kernel_init_freeable+0x110/0x1cc)
  r9:c05b4584 r8:c05b6614 r7:c05e3834 r6:c063cc80 r5:0073 r4:c05f2354
[] (kernel_init_freeable) from [] (kernel_init+0x10/0xfc)
  r10: r9: r8: r7: r6: r5:c04a2cd4
  r4:
[] (kernel_init) from [] (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

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

[Bartosz Golaszewski]

2018-02-19 21:21 GMT+01:00 David Lechner :
> This series converts mach-davinci to use the common clock framework.
>
> The series works like this, the first 19 patches create new clock drivers
> using the common clock framework. There are basically 3 groups of clocks -
> PLL, PSC and CFGCHIP (syscon). There are six different SoCs that each have
> unique init data, which is the reason for so many patches.
>
> Then, starting with "ARM: davinci: pass clock as parameter to
> davinci_timer_init()", we get the mach code ready for the switch by adding the
> code needed for the new clock drivers and adding #ifndef CONFIG_COMMON_CLK
> around the legacy clocks so that we can switch easily between the old and the
> new.
>
> "ARM: davinci: switch to common clock framework" actually flips the switch
> to start using the new clock drivers. Then the next 8 patches remove all
> of the old clock code.
>
> The final three patches add device tree clock support to the one SoC that
> supports it.
>
> ---
>
> The change to make all of the clocks platform devices in v7 was a pretty
> major change, so unfortunately I had to drop quite a few Reviewed-bys and
> this series will need more close review and testing again.
>
> v7 changes (also see individual patches for details):
> - Rebased on linux-davinci/master (v4.16-rc)
> - Convert clock drivers to platform devices
> - New patch "ARM: davinci: pass clock as parameter to davinci_timer_init()"
> - Fix issues with lcdk and aemif clock lookups and power domains
> - Fixed other minor issues brought up in v6 review
>
> v6 changes (also see individual patches for details):
> - All of the device tree bindings are changed
> - All of the clock drivers are changed significantly
> - Fixed issues brought up during review of v5
> - "ARM: davinci: move davinci_clk_init() to init_time" is removed from this
>   series and submitted separately
>
> v5 changes:
> - Basically, this is an entirely new series
> - Patches are broken up into bite-sized pieces
> - Converted PSC clock driver to use regmap
> - Restored "force" flag for certain DA850 clocks
> - Added device tree bindings
> - Moved more of the clock init to drivers/clk
> - Fixed frequency scaling (maybe*)
>
> * I have frequency scaling using cpufreq-dt, so I know the clocks are doing
>   what they need to do to make this work, but I haven't figured out how to
>   test davinci-cpufreq driver yet. (Patches to make cpufreq-dt work will be
>   sent separately after this series has landed.)
>
> Dependencies:
>
> Most of the dependencies have landed in mainline already in v4.16-rc1 or
> are in linux-davinci/master.
>
> There are no build dependencies any more, but you will need to pickup a
> couple of patches to get CPU frequency scaling working because of a divider
> clock bug.
>
> - https://patchwork.kernel.org/patch/10218941/
> - https://patchwork.kernel.org/patch/10218927/
>
> You can find a working branch with everything included in the "common-clk-v7"
> branch of https://github.com/dlech/ev3dev-kernel.git.
>
>
> Testing/debugging for the uninitiated:
>
> I only have one device to test with, which is based on da850, so I will
> have to rely on others to do some testing here. Since we are dealing with
> clocks, if something isn't working, you most likely won't see output on
> the serial port. To figure out what is going on, you need to enable...
>
> CONFIG_DEBUG_LL=y
> CONFIG_EARLY_PRINTK=y
>
> and add "earlyprintk clk_ignore_unused" to the kernel command line options.
> You may need to select a different UART for this depending on your board. I
> think UART1 is the default in the kernel configuration.
>
> On da850 devices comment out the lines:
>
> else
> clk_set_parent(clk, parent->clk);
>
> in da850.c or, if using device tree, comment out the lines:
>
> assigned-clocks = <_clk>;
> assigned-clock-parents = <_sysclk 2>;
>
> in da850.dtsi when doing earlyprintk, otherwise the UART1 and UART2 clock
> source will change during boot and cause garbled output after a point.
>
> David Lechner (42):
>   dt-bindings: clock: Add new bindings for TI Davinci PLL clocks
>   clk: davinci: New driver for davinci PLL clocks
>   clk: davinci: Add platform information for TI DA830 PLL
>   clk: davinci: Add platform information for TI DA850 PLL
>   clk: davinci: Add platform information for TI DM355 PLL
>   clk: davinci: Add platform information for TI DM365 PLL
>   clk: davinci: Add platform information for TI DM644x PLL
>   clk: davinci: Add platform information for TI DM646x PLL
>   dt-bindings: clock: New bindings for TI Davinci PSC
>   clk: davinci: New driver for davinci PSC clocks
>   clk: davinci: Add platform information for TI DA830 PSC
>   clk: davinci: Add platform information for TI DA850 PSC
>   clk: davinci: Add platform information for TI DM355 PSC
>   clk: davinci: Add platform information for TI DM365 PSC
>   clk: davinci: Add platform information for TI DM644x PSC
>  

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

[Bartosz Golaszewski]

2018-02-19 21:21 GMT+01:00 David Lechner :
> This series converts mach-davinci to use the common clock framework.
>
> The series works like this, the first 19 patches create new clock drivers
> using the common clock framework. There are basically 3 groups of clocks -
> PLL, PSC and CFGCHIP (syscon). There are six different SoCs that each have
> unique init data, which is the reason for so many patches.
>
> Then, starting with "ARM: davinci: pass clock as parameter to
> davinci_timer_init()", we get the mach code ready for the switch by adding the
> code needed for the new clock drivers and adding #ifndef CONFIG_COMMON_CLK
> around the legacy clocks so that we can switch easily between the old and the
> new.
>
> "ARM: davinci: switch to common clock framework" actually flips the switch
> to start using the new clock drivers. Then the next 8 patches remove all
> of the old clock code.
>
> The final three patches add device tree clock support to the one SoC that
> supports it.
>
> ---
>
> The change to make all of the clocks platform devices in v7 was a pretty
> major change, so unfortunately I had to drop quite a few Reviewed-bys and
> this series will need more close review and testing again.
>
> v7 changes (also see individual patches for details):
> - Rebased on linux-davinci/master (v4.16-rc)
> - Convert clock drivers to platform devices
> - New patch "ARM: davinci: pass clock as parameter to davinci_timer_init()"
> - Fix issues with lcdk and aemif clock lookups and power domains
> - Fixed other minor issues brought up in v6 review
>
> v6 changes (also see individual patches for details):
> - All of the device tree bindings are changed
> - All of the clock drivers are changed significantly
> - Fixed issues brought up during review of v5
> - "ARM: davinci: move davinci_clk_init() to init_time" is removed from this
>   series and submitted separately
>
> v5 changes:
> - Basically, this is an entirely new series
> - Patches are broken up into bite-sized pieces
> - Converted PSC clock driver to use regmap
> - Restored "force" flag for certain DA850 clocks
> - Added device tree bindings
> - Moved more of the clock init to drivers/clk
> - Fixed frequency scaling (maybe*)
>
> * I have frequency scaling using cpufreq-dt, so I know the clocks are doing
>   what they need to do to make this work, but I haven't figured out how to
>   test davinci-cpufreq driver yet. (Patches to make cpufreq-dt work will be
>   sent separately after this series has landed.)
>
> Dependencies:
>
> Most of the dependencies have landed in mainline already in v4.16-rc1 or
> are in linux-davinci/master.
>
> There are no build dependencies any more, but you will need to pickup a
> couple of patches to get CPU frequency scaling working because of a divider
> clock bug.
>
> - https://patchwork.kernel.org/patch/10218941/
> - https://patchwork.kernel.org/patch/10218927/
>
> You can find a working branch with everything included in the "common-clk-v7"
> branch of https://github.com/dlech/ev3dev-kernel.git.
>
>
> Testing/debugging for the uninitiated:
>
> I only have one device to test with, which is based on da850, so I will
> have to rely on others to do some testing here. Since we are dealing with
> clocks, if something isn't working, you most likely won't see output on
> the serial port. To figure out what is going on, you need to enable...
>
> CONFIG_DEBUG_LL=y
> CONFIG_EARLY_PRINTK=y
>
> and add "earlyprintk clk_ignore_unused" to the kernel command line options.
> You may need to select a different UART for this depending on your board. I
> think UART1 is the default in the kernel configuration.
>
> On da850 devices comment out the lines:
>
> else
> clk_set_parent(clk, parent->clk);
>
> in da850.c or, if using device tree, comment out the lines:
>
> assigned-clocks = <_clk>;
> assigned-clock-parents = <_sysclk 2>;
>
> in da850.dtsi when doing earlyprintk, otherwise the UART1 and UART2 clock
> source will change during boot and cause garbled output after a point.
>
> David Lechner (42):
>   dt-bindings: clock: Add new bindings for TI Davinci PLL clocks
>   clk: davinci: New driver for davinci PLL clocks
>   clk: davinci: Add platform information for TI DA830 PLL
>   clk: davinci: Add platform information for TI DA850 PLL
>   clk: davinci: Add platform information for TI DM355 PLL
>   clk: davinci: Add platform information for TI DM365 PLL
>   clk: davinci: Add platform information for TI DM644x PLL
>   clk: davinci: Add platform information for TI DM646x PLL
>   dt-bindings: clock: New bindings for TI Davinci PSC
>   clk: davinci: New driver for davinci PSC clocks
>   clk: davinci: Add platform information for TI DA830 PSC
>   clk: davinci: Add platform information for TI DA850 PSC
>   clk: davinci: Add platform information for TI DM355 PSC
>   clk: davinci: Add platform information for TI DM365 PSC
>   clk: davinci: Add platform information for TI DM644x PSC
>   clk: davinci: Add