Re: [PATCH v7 10/42] clk: davinci: New driver for davinci PSC clocks

[Bartosz Golaszewski]

2018-03-16 18:55 GMT+01:00 Stephen Boyd :
> Quoting Bartosz Golaszewski (2018-02-28 04:38:38)
>> 2018-02-19 21:21 GMT+01:00 David Lechner :
>>
>> I believe there to be two issues: one is with v7 - we need to increase
>> the clock reference count in davinci_psc_genpd_attach_dev().
>>
>> Second is the error path in the clock framework - we should remove the
>> destroyed clk_core from the debug list, which is not being done now.
>>
>> Why we even need to track the refcount of clk_core is a mistery for me
>> though. Stephen, Mike?
>>
>
> Which part of the code are we talking about? I see that
> __clk_core_init() calls clk_debug_register() when ret == 0 and that
> looks fine. I do wonder why clk_debug_register() even returns a value
> though because we ignore it.

Hi Stephen,

invalid usage of clock pm ops was the culprit here. I just had not
understood why we count references in the CCF - now I get it so
nevermind this mail.

Thanks,
Bart

Re: [PATCH v7 10/42] clk: davinci: New driver for davinci PSC clocks

[Bartosz Golaszewski]

2018-03-16 18:55 GMT+01:00 Stephen Boyd :
> Quoting Bartosz Golaszewski (2018-02-28 04:38:38)
>> 2018-02-19 21:21 GMT+01:00 David Lechner :
>>
>> I believe there to be two issues: one is with v7 - we need to increase
>> the clock reference count in davinci_psc_genpd_attach_dev().
>>
>> Second is the error path in the clock framework - we should remove the
>> destroyed clk_core from the debug list, which is not being done now.
>>
>> Why we even need to track the refcount of clk_core is a mistery for me
>> though. Stephen, Mike?
>>
>
> Which part of the code are we talking about? I see that
> __clk_core_init() calls clk_debug_register() when ret == 0 and that
> looks fine. I do wonder why clk_debug_register() even returns a value
> though because we ignore it.

Hi Stephen,

invalid usage of clock pm ops was the culprit here. I just had not
understood why we count references in the CCF - now I get it so
nevermind this mail.

Thanks,
Bart

Re: [PATCH v7 10/42] clk: davinci: New driver for davinci PSC clocks

[Stephen Boyd]

Quoting Bartosz Golaszewski (2018-02-28 04:38:38)
> 2018-02-19 21:21 GMT+01:00 David Lechner :
> 
> I believe there to be two issues: one is with v7 - we need to increase
> the clock reference count in davinci_psc_genpd_attach_dev().
> 
> Second is the error path in the clock framework - we should remove the
> destroyed clk_core from the debug list, which is not being done now.
> 
> Why we even need to track the refcount of clk_core is a mistery for me
> though. Stephen, Mike?
> 

Which part of the code are we talking about? I see that
__clk_core_init() calls clk_debug_register() when ret == 0 and that
looks fine. I do wonder why clk_debug_register() even returns a value
though because we ignore it.

Re: [PATCH v7 10/42] clk: davinci: New driver for davinci PSC clocks

[Stephen Boyd]

Quoting Bartosz Golaszewski (2018-02-28 04:38:38)
> 2018-02-19 21:21 GMT+01:00 David Lechner :
> 
> I believe there to be two issues: one is with v7 - we need to increase
> the clock reference count in davinci_psc_genpd_attach_dev().
> 
> Second is the error path in the clock framework - we should remove the
> destroyed clk_core from the debug list, which is not being done now.
> 
> Why we even need to track the refcount of clk_core is a mistery for me
> though. Stephen, Mike?
> 

Which part of the code are we talking about? I see that
__clk_core_init() calls clk_debug_register() when ret == 0 and that
looks fine. I do wonder why clk_debug_register() even returns a value
though because we ignore it.

Re: [PATCH v7 10/42] clk: davinci: New driver for davinci PSC clocks

[David Lechner]

On 03/05/2018 10:23 AM, David Lechner wrote:

On 03/05/2018 07:02 AM, Bartosz Golaszewski wrote:

2018-03-01 17:44 GMT+01:00 David Lechner :

On 03/01/2018 02:36 AM, Bartosz Golaszewski wrote:


2018-02-28 22:40 GMT+01:00 David Lechner :


On 02/28/2018 06:38 AM, Bartosz Golaszewski wrote:




I think I found the reason for the strange crashes we were
experiencing (emac core->name being NULL) thanks to Sekhar who pointed
me in the right direction.

The mdio driver fails to probe with v7 due to the supplied clock rate
being wrong. Before failing we register the emac clock with
pm_clk_add_clk(). When clock_ops puts the clock, it decreases the
reference count of the clock, but we never actually increased it in
the first place in the line above. The core clock code then destroys
the associated clk_core structure. When the next user comes around (in
our case the clk debug functions) the system crashes.

I believe there to be two issues: one is with v7 - we need to increase
the clock reference count in davinci_psc_genpd_attach_dev().

Second is the error path in the clock framework - we should remove the
destroyed clk_core from the debug list, which is not being done now.

Why we even need to track the refcount of clk_core is a mistery for me
though. Stephen, Mike?

Best regards,
Bartosz Golaszewski




Great find. I figured it had to be something like this, but I wasn't
able to reproduce the problem yet.

I suppose it is time to spin up a v8 with some fixes.



I still don't know why the mdio clock rate is much lower than in
mainline though. Any ideas?

Thanks,
Bart



Now that you have fixed the crash, can you answer the questions I have
asked earlier?


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


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.serial    active


Hi David, Sekhar,

I tried booting the board today over tftp but didn't succeed. I then
switched to a normal boot from SD card and the boot process froze at
the same moment (right after the DHCP config, or after rtc config if I
disabled DHCP in bootargs). I then realized that the emac clock can't
be the culprit. After some digging I found out that the late_initcall
to clk_disable_unused() disables sysclk6 - the parent of the arm
clock, which of course freezes the device.

If I remove the call to clk_disable_unused(), I can boot just fine.

The following other clocks are disabled before pll0_sysclk6:
pll1_sysclk3
pll0_obsclk
pll0_sysclk7

davinci_lpsc_clk_enable() is never called for these clocks - in fact
it's not called for any parent that's not explicitly defined in
psc-da850.c - I believe this may be one of the reasons. I will get
back to debugging it tomorrow.

Best regards,
Bartosz Golaszewski



Thanks for continuing to dig into this. I think I know what needs to
be done now. I think I don't have the dependencies quite right where
the PSC clocks are being registered before the PLL clocks, in which
case they aren't getting the correct parent clock.



Bartosz,

One more thing to check: I think I had some typos in da850.dtsi where
I wrote clock_names instead of clock-names. Please make sure this is
fixed in your working branch.

Re: [PATCH v7 10/42] clk: davinci: New driver for davinci PSC clocks

[David Lechner]

On 03/05/2018 10:23 AM, David Lechner wrote:

On 03/05/2018 07:02 AM, Bartosz Golaszewski wrote:

2018-03-01 17:44 GMT+01:00 David Lechner :

On 03/01/2018 02:36 AM, Bartosz Golaszewski wrote:


2018-02-28 22:40 GMT+01:00 David Lechner :


On 02/28/2018 06:38 AM, Bartosz Golaszewski wrote:




I think I found the reason for the strange crashes we were
experiencing (emac core->name being NULL) thanks to Sekhar who pointed
me in the right direction.

The mdio driver fails to probe with v7 due to the supplied clock rate
being wrong. Before failing we register the emac clock with
pm_clk_add_clk(). When clock_ops puts the clock, it decreases the
reference count of the clock, but we never actually increased it in
the first place in the line above. The core clock code then destroys
the associated clk_core structure. When the next user comes around (in
our case the clk debug functions) the system crashes.

I believe there to be two issues: one is with v7 - we need to increase
the clock reference count in davinci_psc_genpd_attach_dev().

Second is the error path in the clock framework - we should remove the
destroyed clk_core from the debug list, which is not being done now.

Why we even need to track the refcount of clk_core is a mistery for me
though. Stephen, Mike?

Best regards,
Bartosz Golaszewski




Great find. I figured it had to be something like this, but I wasn't
able to reproduce the problem yet.

I suppose it is time to spin up a v8 with some fixes.



I still don't know why the mdio clock rate is much lower than in
mainline though. Any ideas?

Thanks,
Bart



Now that you have fixed the crash, can you answer the questions I have
asked earlier?


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


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.serial    active


Hi David, Sekhar,

I tried booting the board today over tftp but didn't succeed. I then
switched to a normal boot from SD card and the boot process froze at
the same moment (right after the DHCP config, or after rtc config if I
disabled DHCP in bootargs). I then realized that the emac clock can't
be the culprit. After some digging I found out that the late_initcall
to clk_disable_unused() disables sysclk6 - the parent of the arm
clock, which of course freezes the device.

If I remove the call to clk_disable_unused(), I can boot just fine.

The following other clocks are disabled before pll0_sysclk6:
pll1_sysclk3
pll0_obsclk
pll0_sysclk7

davinci_lpsc_clk_enable() is never called for these clocks - in fact
it's not called for any parent that's not explicitly defined in
psc-da850.c - I believe this may be one of the reasons. I will get
back to debugging it tomorrow.

Best regards,
Bartosz Golaszewski



Thanks for continuing to dig into this. I think I know what needs to
be done now. I think I don't have the dependencies quite right where
the PSC clocks are being registered before the PLL clocks, in which
case they aren't getting the correct parent clock.



Bartosz,

One more thing to check: I think I had some typos in da850.dtsi where
I wrote clock_names instead of clock-names. Please make sure this is
fixed in your working branch.

Re: [PATCH v7 10/42] clk: davinci: New driver for davinci PSC clocks

[David Lechner]

On 03/05/2018 07:02 AM, Bartosz Golaszewski wrote:

2018-03-01 17:44 GMT+01:00 David Lechner :

On 03/01/2018 02:36 AM, Bartosz Golaszewski wrote:


2018-02-28 22:40 GMT+01:00 David Lechner :


On 02/28/2018 06:38 AM, Bartosz Golaszewski wrote:




I think I found the reason for the strange crashes we were
experiencing (emac core->name being NULL) thanks to Sekhar who pointed
me in the right direction.

The mdio driver fails to probe with v7 due to the supplied clock rate
being wrong. Before failing we register the emac clock with
pm_clk_add_clk(). When clock_ops puts the clock, it decreases the
reference count of the clock, but we never actually increased it in
the first place in the line above. The core clock code then destroys
the associated clk_core structure. When the next user comes around (in
our case the clk debug functions) the system crashes.

I believe there to be two issues: one is with v7 - we need to increase
the clock reference count in davinci_psc_genpd_attach_dev().

Second is the error path in the clock framework - we should remove the
destroyed clk_core from the debug list, which is not being done now.

Why we even need to track the refcount of clk_core is a mistery for me
though. Stephen, Mike?

Best regards,
Bartosz Golaszewski




Great find. I figured it had to be something like this, but I wasn't
able to reproduce the problem yet.

I suppose it is time to spin up a v8 with some fixes.



I still don't know why the mdio clock rate is much lower than in
mainline though. Any ideas?

Thanks,
Bart



Now that you have fixed the crash, can you answer the questions I have
asked earlier?


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


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


Hi David, Sekhar,

I tried booting the board today over tftp but didn't succeed. I then
switched to a normal boot from SD card and the boot process froze at
the same moment (right after the DHCP config, or after rtc config if I
disabled DHCP in bootargs). I then realized that the emac clock can't
be the culprit. After some digging I found out that the late_initcall
to clk_disable_unused() disables sysclk6 - the parent of the arm
clock, which of course freezes the device.

If I remove the call to clk_disable_unused(), I can boot just fine.

The following other clocks are disabled before pll0_sysclk6:
pll1_sysclk3
pll0_obsclk
pll0_sysclk7

davinci_lpsc_clk_enable() is never called for these clocks - in fact
it's not called for any parent that's not explicitly defined in
psc-da850.c - I believe this may be one of the reasons. I will get
back to debugging it tomorrow.

Best regards,
Bartosz Golaszewski



Thanks for continuing to dig into this. I think I know what needs to
be done now. I think I don't have the dependencies quite right where
the PSC clocks are being registered before the PLL clocks, in which
case they aren't getting the correct parent clock.

Re: [PATCH v7 10/42] clk: davinci: New driver for davinci PSC clocks

[David Lechner]

On 03/05/2018 07:02 AM, Bartosz Golaszewski wrote:

2018-03-01 17:44 GMT+01:00 David Lechner :

On 03/01/2018 02:36 AM, Bartosz Golaszewski wrote:


2018-02-28 22:40 GMT+01:00 David Lechner :


On 02/28/2018 06:38 AM, Bartosz Golaszewski wrote:




I think I found the reason for the strange crashes we were
experiencing (emac core->name being NULL) thanks to Sekhar who pointed
me in the right direction.

The mdio driver fails to probe with v7 due to the supplied clock rate
being wrong. Before failing we register the emac clock with
pm_clk_add_clk(). When clock_ops puts the clock, it decreases the
reference count of the clock, but we never actually increased it in
the first place in the line above. The core clock code then destroys
the associated clk_core structure. When the next user comes around (in
our case the clk debug functions) the system crashes.

I believe there to be two issues: one is with v7 - we need to increase
the clock reference count in davinci_psc_genpd_attach_dev().

Second is the error path in the clock framework - we should remove the
destroyed clk_core from the debug list, which is not being done now.

Why we even need to track the refcount of clk_core is a mistery for me
though. Stephen, Mike?

Best regards,
Bartosz Golaszewski




Great find. I figured it had to be something like this, but I wasn't
able to reproduce the problem yet.

I suppose it is time to spin up a v8 with some fixes.



I still don't know why the mdio clock rate is much lower than in
mainline though. Any ideas?

Thanks,
Bart



Now that you have fixed the crash, can you answer the questions I have
asked earlier?


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


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


Hi David, Sekhar,

I tried booting the board today over tftp but didn't succeed. I then
switched to a normal boot from SD card and the boot process froze at
the same moment (right after the DHCP config, or after rtc config if I
disabled DHCP in bootargs). I then realized that the emac clock can't
be the culprit. After some digging I found out that the late_initcall
to clk_disable_unused() disables sysclk6 - the parent of the arm
clock, which of course freezes the device.

If I remove the call to clk_disable_unused(), I can boot just fine.

The following other clocks are disabled before pll0_sysclk6:
pll1_sysclk3
pll0_obsclk
pll0_sysclk7

davinci_lpsc_clk_enable() is never called for these clocks - in fact
it's not called for any parent that's not explicitly defined in
psc-da850.c - I believe this may be one of the reasons. I will get
back to debugging it tomorrow.

Best regards,
Bartosz Golaszewski



Thanks for continuing to dig into this. I think I know what needs to
be done now. I think I don't have the dependencies quite right where
the PSC clocks are being registered before the PLL clocks, in which
case they aren't getting the correct parent clock.

Re: [PATCH v7 10/42] clk: davinci: New driver for davinci PSC clocks

[Bartosz Golaszewski]

2018-03-01 17:44 GMT+01:00 David Lechner :
> On 03/01/2018 02:36 AM, Bartosz Golaszewski wrote:
>>
>> 2018-02-28 22:40 GMT+01:00 David Lechner :
>>>
>>> On 02/28/2018 06:38 AM, Bartosz Golaszewski wrote:



 I think I found the reason for the strange crashes we were
 experiencing (emac core->name being NULL) thanks to Sekhar who pointed
 me in the right direction.

 The mdio driver fails to probe with v7 due to the supplied clock rate
 being wrong. Before failing we register the emac clock with
 pm_clk_add_clk(). When clock_ops puts the clock, it decreases the
 reference count of the clock, but we never actually increased it in
 the first place in the line above. The core clock code then destroys
 the associated clk_core structure. When the next user comes around (in
 our case the clk debug functions) the system crashes.

 I believe there to be two issues: one is with v7 - we need to increase
 the clock reference count in davinci_psc_genpd_attach_dev().

 Second is the error path in the clock framework - we should remove the
 destroyed clk_core from the debug list, which is not being done now.

 Why we even need to track the refcount of clk_core is a mistery for me
 though. Stephen, Mike?

 Best regards,
 Bartosz Golaszewski
>>>
>>>
>>>
>>> Great find. I figured it had to be something like this, but I wasn't
>>> able to reproduce the problem yet.
>>>
>>> I suppose it is time to spin up a v8 with some fixes.
>>
>>
>> I still don't know why the mdio clock rate is much lower than in
>> mainline though. Any ideas?
>>
>> Thanks,
>> Bart
>>
>
> Now that you have fixed the crash, can you answer the questions I have
> asked earlier?
>
>> 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
>
>> 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

Hi David, Sekhar,

I tried booting the board today over tftp but didn't succeed. I then
switched to a normal boot from SD card and the boot process froze at
the same moment (right after the DHCP config, or after rtc config if I
disabled DHCP in bootargs). I then realized that the emac clock can't
be the culprit. After some digging I found out that the late_initcall
to clk_disable_unused() disables sysclk6 - the parent of the arm
clock, which of course freezes the device.

If I remove the call to clk_disable_unused(), I can boot just fine.

The following other clocks are disabled before pll0_sysclk6:
pll1_sysclk3
pll0_obsclk
pll0_sysclk7

davinci_lpsc_clk_enable() is never called for these clocks - in fact
it's not called for any parent that's not explicitly defined in
psc-da850.c - I believe this may be one of the reasons. I will get
back to debugging it tomorrow.

Best regards,
Bartosz Golaszewski

Re: [PATCH v7 10/42] clk: davinci: New driver for davinci PSC clocks

[Bartosz Golaszewski]

2018-03-01 17:44 GMT+01:00 David Lechner :
> On 03/01/2018 02:36 AM, Bartosz Golaszewski wrote:
>>
>> 2018-02-28 22:40 GMT+01:00 David Lechner :
>>>
>>> On 02/28/2018 06:38 AM, Bartosz Golaszewski wrote:



 I think I found the reason for the strange crashes we were
 experiencing (emac core->name being NULL) thanks to Sekhar who pointed
 me in the right direction.

 The mdio driver fails to probe with v7 due to the supplied clock rate
 being wrong. Before failing we register the emac clock with
 pm_clk_add_clk(). When clock_ops puts the clock, it decreases the
 reference count of the clock, but we never actually increased it in
 the first place in the line above. The core clock code then destroys
 the associated clk_core structure. When the next user comes around (in
 our case the clk debug functions) the system crashes.

 I believe there to be two issues: one is with v7 - we need to increase
 the clock reference count in davinci_psc_genpd_attach_dev().

 Second is the error path in the clock framework - we should remove the
 destroyed clk_core from the debug list, which is not being done now.

 Why we even need to track the refcount of clk_core is a mistery for me
 though. Stephen, Mike?

 Best regards,
 Bartosz Golaszewski
>>>
>>>
>>>
>>> Great find. I figured it had to be something like this, but I wasn't
>>> able to reproduce the problem yet.
>>>
>>> I suppose it is time to spin up a v8 with some fixes.
>>
>>
>> I still don't know why the mdio clock rate is much lower than in
>> mainline though. Any ideas?
>>
>> Thanks,
>> Bart
>>
>
> Now that you have fixed the crash, can you answer the questions I have
> asked earlier?
>
>> 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
>
>> 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

Hi David, Sekhar,

I tried booting the board today over tftp but didn't succeed. I then
switched to a normal boot from SD card and the boot process froze at
the same moment (right after the DHCP config, or after rtc config if I
disabled DHCP in bootargs). I then realized that the emac clock can't
be the culprit. After some digging I found out that the late_initcall
to clk_disable_unused() disables sysclk6 - the parent of the arm
clock, which of course freezes the device.

If I remove the call to clk_disable_unused(), I can boot just fine.

The following other clocks are disabled before pll0_sysclk6:
pll1_sysclk3
pll0_obsclk
pll0_sysclk7

davinci_lpsc_clk_enable() is never called for these clocks - in fact
it's not called for any parent that's not explicitly defined in
psc-da850.c - I believe this may be one of the reasons. I will get
back to debugging it tomorrow.

Best regards,
Bartosz Golaszewski

Re: [PATCH v7 10/42] clk: davinci: New driver for davinci PSC clocks

[Bartosz Golaszewski]

2018-03-01 17:44 GMT+01:00 David Lechner :
> On 03/01/2018 02:36 AM, Bartosz Golaszewski wrote:
>>
>> 2018-02-28 22:40 GMT+01:00 David Lechner :
>>>
>>> On 02/28/2018 06:38 AM, Bartosz Golaszewski wrote:



 I think I found the reason for the strange crashes we were
 experiencing (emac core->name being NULL) thanks to Sekhar who pointed
 me in the right direction.

 The mdio driver fails to probe with v7 due to the supplied clock rate
 being wrong. Before failing we register the emac clock with
 pm_clk_add_clk(). When clock_ops puts the clock, it decreases the
 reference count of the clock, but we never actually increased it in
 the first place in the line above. The core clock code then destroys
 the associated clk_core structure. When the next user comes around (in
 our case the clk debug functions) the system crashes.

 I believe there to be two issues: one is with v7 - we need to increase
 the clock reference count in davinci_psc_genpd_attach_dev().

 Second is the error path in the clock framework - we should remove the
 destroyed clk_core from the debug list, which is not being done now.

 Why we even need to track the refcount of clk_core is a mistery for me
 though. Stephen, Mike?

 Best regards,
 Bartosz Golaszewski
>>>
>>>
>>>
>>> Great find. I figured it had to be something like this, but I wasn't
>>> able to reproduce the problem yet.
>>>
>>> I suppose it is time to spin up a v8 with some fixes.
>>
>>
>> I still don't know why the mdio clock rate is much lower than in
>> mainline though. Any ideas?
>>
>> Thanks,
>> Bart
>>
>
> Now that you have fixed the crash, can you answer the questions I have
> asked earlier?
>
>> 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
>
>> 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

I used of_clk_get() in the genpd attach callback so the crash no
longer happens, but I still can't boot it over NFS due to mdio
failing. Do you have any idea why the clock rate differs between v7
and mainline?

>From the logs I can see that genpd domains are correctly registered,
and the provider is added (you should probably skip setting up the
domains in legacy mode though), the pm clocks are enabled (after being
disabled by mdio after its failed probe()) but the boot process gets
stuck after the kernel gets an IP address over DHCP (which is strange
because apparently it had some kind of network connection).

On Monday I'll prepare a small ramfs and boot over tftp only and see from there.

Best regards,
Bartosz

Re: [PATCH v7 10/42] clk: davinci: New driver for davinci PSC clocks

[Bartosz Golaszewski]

2018-03-01 17:44 GMT+01:00 David Lechner :
> On 03/01/2018 02:36 AM, Bartosz Golaszewski wrote:
>>
>> 2018-02-28 22:40 GMT+01:00 David Lechner :
>>>
>>> On 02/28/2018 06:38 AM, Bartosz Golaszewski wrote:



 I think I found the reason for the strange crashes we were
 experiencing (emac core->name being NULL) thanks to Sekhar who pointed
 me in the right direction.

 The mdio driver fails to probe with v7 due to the supplied clock rate
 being wrong. Before failing we register the emac clock with
 pm_clk_add_clk(). When clock_ops puts the clock, it decreases the
 reference count of the clock, but we never actually increased it in
 the first place in the line above. The core clock code then destroys
 the associated clk_core structure. When the next user comes around (in
 our case the clk debug functions) the system crashes.

 I believe there to be two issues: one is with v7 - we need to increase
 the clock reference count in davinci_psc_genpd_attach_dev().

 Second is the error path in the clock framework - we should remove the
 destroyed clk_core from the debug list, which is not being done now.

 Why we even need to track the refcount of clk_core is a mistery for me
 though. Stephen, Mike?

 Best regards,
 Bartosz Golaszewski
>>>
>>>
>>>
>>> Great find. I figured it had to be something like this, but I wasn't
>>> able to reproduce the problem yet.
>>>
>>> I suppose it is time to spin up a v8 with some fixes.
>>
>>
>> I still don't know why the mdio clock rate is much lower than in
>> mainline though. Any ideas?
>>
>> Thanks,
>> Bart
>>
>
> Now that you have fixed the crash, can you answer the questions I have
> asked earlier?
>
>> 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
>
>> 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

I used of_clk_get() in the genpd attach callback so the crash no
longer happens, but I still can't boot it over NFS due to mdio
failing. Do you have any idea why the clock rate differs between v7
and mainline?

>From the logs I can see that genpd domains are correctly registered,
and the provider is added (you should probably skip setting up the
domains in legacy mode though), the pm clocks are enabled (after being
disabled by mdio after its failed probe()) but the boot process gets
stuck after the kernel gets an IP address over DHCP (which is strange
because apparently it had some kind of network connection).

On Monday I'll prepare a small ramfs and boot over tftp only and see from there.

Best regards,
Bartosz

Re: [PATCH v7 10/42] clk: davinci: New driver for davinci PSC clocks

[David Lechner]

On 03/01/2018 02:36 AM, Bartosz Golaszewski wrote:

2018-02-28 22:40 GMT+01:00 David Lechner :

On 02/28/2018 06:38 AM, Bartosz Golaszewski wrote:



I think I found the reason for the strange crashes we were
experiencing (emac core->name being NULL) thanks to Sekhar who pointed
me in the right direction.

The mdio driver fails to probe with v7 due to the supplied clock rate
being wrong. Before failing we register the emac clock with
pm_clk_add_clk(). When clock_ops puts the clock, it decreases the
reference count of the clock, but we never actually increased it in
the first place in the line above. The core clock code then destroys
the associated clk_core structure. When the next user comes around (in
our case the clk debug functions) the system crashes.

I believe there to be two issues: one is with v7 - we need to increase
the clock reference count in davinci_psc_genpd_attach_dev().

Second is the error path in the clock framework - we should remove the
destroyed clk_core from the debug list, which is not being done now.

Why we even need to track the refcount of clk_core is a mistery for me
though. Stephen, Mike?

Best regards,
Bartosz Golaszewski



Great find. I figured it had to be something like this, but I wasn't
able to reproduce the problem yet.

I suppose it is time to spin up a v8 with some fixes.


I still don't know why the mdio clock rate is much lower than in
mainline though. Any ideas?

Thanks,
Bart



Now that you have fixed the crash, can you answer the questions I have
asked earlier?


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


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

Re: [PATCH v7 10/42] clk: davinci: New driver for davinci PSC clocks

[David Lechner]

On 03/01/2018 02:36 AM, Bartosz Golaszewski wrote:

2018-02-28 22:40 GMT+01:00 David Lechner :

On 02/28/2018 06:38 AM, Bartosz Golaszewski wrote:



I think I found the reason for the strange crashes we were
experiencing (emac core->name being NULL) thanks to Sekhar who pointed
me in the right direction.

The mdio driver fails to probe with v7 due to the supplied clock rate
being wrong. Before failing we register the emac clock with
pm_clk_add_clk(). When clock_ops puts the clock, it decreases the
reference count of the clock, but we never actually increased it in
the first place in the line above. The core clock code then destroys
the associated clk_core structure. When the next user comes around (in
our case the clk debug functions) the system crashes.

I believe there to be two issues: one is with v7 - we need to increase
the clock reference count in davinci_psc_genpd_attach_dev().

Second is the error path in the clock framework - we should remove the
destroyed clk_core from the debug list, which is not being done now.

Why we even need to track the refcount of clk_core is a mistery for me
though. Stephen, Mike?

Best regards,
Bartosz Golaszewski



Great find. I figured it had to be something like this, but I wasn't
able to reproduce the problem yet.

I suppose it is time to spin up a v8 with some fixes.


I still don't know why the mdio clock rate is much lower than in
mainline though. Any ideas?

Thanks,
Bart



Now that you have fixed the crash, can you answer the questions I have
asked earlier?


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


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

Re: [PATCH v7 10/42] clk: davinci: New driver for davinci PSC clocks

[Bartosz Golaszewski]

2018-02-28 22:40 GMT+01:00 David Lechner :
> On 02/28/2018 06:38 AM, Bartosz Golaszewski wrote:
>>
>>
>> I think I found the reason for the strange crashes we were
>> experiencing (emac core->name being NULL) thanks to Sekhar who pointed
>> me in the right direction.
>>
>> The mdio driver fails to probe with v7 due to the supplied clock rate
>> being wrong. Before failing we register the emac clock with
>> pm_clk_add_clk(). When clock_ops puts the clock, it decreases the
>> reference count of the clock, but we never actually increased it in
>> the first place in the line above. The core clock code then destroys
>> the associated clk_core structure. When the next user comes around (in
>> our case the clk debug functions) the system crashes.
>>
>> I believe there to be two issues: one is with v7 - we need to increase
>> the clock reference count in davinci_psc_genpd_attach_dev().
>>
>> Second is the error path in the clock framework - we should remove the
>> destroyed clk_core from the debug list, which is not being done now.
>>
>> Why we even need to track the refcount of clk_core is a mistery for me
>> though. Stephen, Mike?
>>
>> Best regards,
>> Bartosz Golaszewski
>
>
> Great find. I figured it had to be something like this, but I wasn't
> able to reproduce the problem yet.
>
> I suppose it is time to spin up a v8 with some fixes.

I still don't know why the mdio clock rate is much lower than in
mainline though. Any ideas?

Thanks,
Bart

Re: [PATCH v7 10/42] clk: davinci: New driver for davinci PSC clocks

[Bartosz Golaszewski]

2018-02-28 22:40 GMT+01:00 David Lechner :
> On 02/28/2018 06:38 AM, Bartosz Golaszewski wrote:
>>
>>
>> I think I found the reason for the strange crashes we were
>> experiencing (emac core->name being NULL) thanks to Sekhar who pointed
>> me in the right direction.
>>
>> The mdio driver fails to probe with v7 due to the supplied clock rate
>> being wrong. Before failing we register the emac clock with
>> pm_clk_add_clk(). When clock_ops puts the clock, it decreases the
>> reference count of the clock, but we never actually increased it in
>> the first place in the line above. The core clock code then destroys
>> the associated clk_core structure. When the next user comes around (in
>> our case the clk debug functions) the system crashes.
>>
>> I believe there to be two issues: one is with v7 - we need to increase
>> the clock reference count in davinci_psc_genpd_attach_dev().
>>
>> Second is the error path in the clock framework - we should remove the
>> destroyed clk_core from the debug list, which is not being done now.
>>
>> Why we even need to track the refcount of clk_core is a mistery for me
>> though. Stephen, Mike?
>>
>> Best regards,
>> Bartosz Golaszewski
>
>
> Great find. I figured it had to be something like this, but I wasn't
> able to reproduce the problem yet.
>
> I suppose it is time to spin up a v8 with some fixes.

I still don't know why the mdio clock rate is much lower than in
mainline though. Any ideas?

Thanks,
Bart

Re: [PATCH v7 10/42] clk: davinci: New driver for davinci PSC clocks

[David Lechner]

On 02/28/2018 06:38 AM, Bartosz Golaszewski wrote:


I think I found the reason for the strange crashes we were
experiencing (emac core->name being NULL) thanks to Sekhar who pointed
me in the right direction.

The mdio driver fails to probe with v7 due to the supplied clock rate
being wrong. Before failing we register the emac clock with
pm_clk_add_clk(). When clock_ops puts the clock, it decreases the
reference count of the clock, but we never actually increased it in
the first place in the line above. The core clock code then destroys
the associated clk_core structure. When the next user comes around (in
our case the clk debug functions) the system crashes.

I believe there to be two issues: one is with v7 - we need to increase
the clock reference count in davinci_psc_genpd_attach_dev().

Second is the error path in the clock framework - we should remove the
destroyed clk_core from the debug list, which is not being done now.

Why we even need to track the refcount of clk_core is a mistery for me
though. Stephen, Mike?

Best regards,
Bartosz Golaszewski


Great find. I figured it had to be something like this, but I wasn't
able to reproduce the problem yet.

I suppose it is time to spin up a v8 with some fixes.

Re: [PATCH v7 10/42] clk: davinci: New driver for davinci PSC clocks

[David Lechner]

On 02/28/2018 06:38 AM, Bartosz Golaszewski wrote:


I think I found the reason for the strange crashes we were
experiencing (emac core->name being NULL) thanks to Sekhar who pointed
me in the right direction.

The mdio driver fails to probe with v7 due to the supplied clock rate
being wrong. Before failing we register the emac clock with
pm_clk_add_clk(). When clock_ops puts the clock, it decreases the
reference count of the clock, but we never actually increased it in
the first place in the line above. The core clock code then destroys
the associated clk_core structure. When the next user comes around (in
our case the clk debug functions) the system crashes.

I believe there to be two issues: one is with v7 - we need to increase
the clock reference count in davinci_psc_genpd_attach_dev().

Second is the error path in the clock framework - we should remove the
destroyed clk_core from the debug list, which is not being done now.

Why we even need to track the refcount of clk_core is a mistery for me
though. Stephen, Mike?

Best regards,
Bartosz Golaszewski


Great find. I figured it had to be something like this, but I wasn't
able to reproduce the problem yet.

I suppose it is time to spin up a v8 with some fixes.

Re: [PATCH v7 10/42] clk: davinci: New driver for davinci PSC clocks

[Bartosz Golaszewski]

2018-02-19 21:21 GMT+01:00 David Lechner :
> This adds a new driver for mach-davinci PSC clocks. This is porting the
> code from arch/arm/mach-davinci/psc.c to the common clock framework and
> is converting it to use regmap to simplify the code. Additionally, it
> adds device tree support for these clocks.
>
> Note: although there are similar clocks for TI Keystone we are not able
> to share the code for a few reasons. The keystone clocks are device tree
> only and use legacy one-node-per-clock bindings. Also the keystone
> driver makes the assumption that there is only one PSC per SoC and uses
> global variables, but here we have two controllers per SoC.
>
> Signed-off-by: David Lechner 
> ---
>
> v7 changes:
> - convert to platform device
> - rename lpsc field to md
> - rename PSC to LPSC where appropriate
> - rename LPSC_ARM_RATE to LPSC_SET_RATE_PARENT
> - add genpd provider
> - add reset provider
>
> v6 changes:
> - use GENMASK
> - add quirk flag for FORCE bit
> - add quirk flag for propagating set_rate
> - fix writing to PDSTAT instead of PDCTL
> - remove unused doc comment parameter
> - change davinci_psc_register_clocks() to handle registering clkdev entries
>
>
>  drivers/clk/davinci/Makefile |   2 +
>  drivers/clk/davinci/psc.c| 495 
> +++
>  drivers/clk/davinci/psc.h|  89 
>  3 files changed, 586 insertions(+)
>  create mode 100644 drivers/clk/davinci/psc.c
>  create mode 100644 drivers/clk/davinci/psc.h
>
> diff --git a/drivers/clk/davinci/Makefile b/drivers/clk/davinci/Makefile
> index d471386..cd1bf2c 100644
> --- a/drivers/clk/davinci/Makefile
> +++ b/drivers/clk/davinci/Makefile
> @@ -8,4 +8,6 @@ obj-$(CONFIG_ARCH_DAVINCI_DM355)+= pll-dm355.o
>  obj-$(CONFIG_ARCH_DAVINCI_DM365)   += pll-dm365.o
>  obj-$(CONFIG_ARCH_DAVINCI_DM644x)  += pll-dm644x.o
>  obj-$(CONFIG_ARCH_DAVINCI_DM646x)  += pll-dm646x.o
> +
> +obj-y += psc.o
>  endif
> diff --git a/drivers/clk/davinci/psc.c b/drivers/clk/davinci/psc.c
> new file mode 100644
> index 000..8e08ac8
> --- /dev/null
> +++ b/drivers/clk/davinci/psc.c
> @@ -0,0 +1,495 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Clock driver for TI Davinci PSC controllers
> + *
> + * Copyright (C) 2017 David Lechner 
> + *
> + * Based on: drivers/clk/keystone/gate.c
> + * Copyright (C) 2013 Texas Instruments.
> + * Murali Karicheri 
> + * Santosh Shilimkar 
> + *
> + * And: arch/arm/mach-davinci/psc.c
> + * Copyright (C) 2006 Texas Instruments.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "psc.h"
> +
> +/* PSC register offsets */
> +#define EPCPR  0x070
> +#define PTCMD  0x120
> +#define PTSTAT 0x128
> +#define PDSTAT(n)  (0x200 + 4 * (n))
> +#define PDCTL(n)   (0x300 + 4 * (n))
> +#define MDSTAT(n)  (0x800 + 4 * (n))
> +#define MDCTL(n)   (0xa00 + 4 * (n))
> +
> +/* PSC module states */
> +enum davinci_lpsc_state {
> +   LPSC_STATE_SWRSTDISABLE = 0,
> +   LPSC_STATE_SYNCRST  = 1,
> +   LPSC_STATE_DISABLE  = 2,
> +   LPSC_STATE_ENABLE   = 3,
> +};
> +
> +#define MDSTAT_STATE_MASK  GENMASK(5, 0)
> +#define MDSTAT_MCKOUT  BIT(12)
> +#define PDSTAT_STATE_MASK  GENMASK(4, 0)
> +#define MDCTL_FORCEBIT(31)
> +#define MDCTL_LRESET   BIT(8)
> +#define PDCTL_EPCGOOD  BIT(8)
> +#define PDCTL_NEXT BIT(0)
> +
> +struct davinci_psc_data {
> +   struct clk_onecell_data clk_data;
> +   struct genpd_onecell_data pm_data;
> +   struct reset_controller_dev rcdev;
> +};
> +
> +/**
> + * struct davinci_lpsc_clk - LPSC clock structure
> + * @hw: clk_hw for the LPSC
> + * @pm_domain: power domain for the LPSC
> + * @regmap: PSC MMIO region
> + * @md: Module domain (LPSC module id)
> + * @pd: Power domain
> + * @flags: LPSC_* quirk flags
> + */
> +struct davinci_lpsc_clk {
> +   struct clk_hw hw;
> +   struct generic_pm_domain pm_domain;
> +   struct regmap *regmap;
> +   u32 md;
> +   u32 pd;
> +   u32 flags;
> +};
> +
> +#define to_davinci_psc_data(x) container_of(x, struct davinci_psc_data, x)
> +#define to_davinci_lpsc_clk(x) container_of(x, struct davinci_lpsc_clk, x)
> +
> +static void davinci_lpsc_config(struct davinci_lpsc_clk *lpsc,
> +   enum davinci_lpsc_state next_state)
> +{
> +   u32 epcpr, pdstat, mdstat, ptstat;
> +
> +   regmap_write_bits(lpsc->regmap, MDCTL(lpsc->md), MDSTAT_STATE_MASK,
> + next_state);
> +
> +   if (lpsc->flags & LPSC_FORCE)
> +   regmap_write_bits(lpsc->regmap, MDCTL(lpsc->md), MDCTL_FORCE,
> +   

Re: [PATCH v7 10/42] clk: davinci: New driver for davinci PSC clocks

[Bartosz Golaszewski]

2018-02-19 21:21 GMT+01:00 David Lechner :
> This adds a new driver for mach-davinci PSC clocks. This is porting the
> code from arch/arm/mach-davinci/psc.c to the common clock framework and
> is converting it to use regmap to simplify the code. Additionally, it
> adds device tree support for these clocks.
>
> Note: although there are similar clocks for TI Keystone we are not able
> to share the code for a few reasons. The keystone clocks are device tree
> only and use legacy one-node-per-clock bindings. Also the keystone
> driver makes the assumption that there is only one PSC per SoC and uses
> global variables, but here we have two controllers per SoC.
>
> Signed-off-by: David Lechner 
> ---
>
> v7 changes:
> - convert to platform device
> - rename lpsc field to md
> - rename PSC to LPSC where appropriate
> - rename LPSC_ARM_RATE to LPSC_SET_RATE_PARENT
> - add genpd provider
> - add reset provider
>
> v6 changes:
> - use GENMASK
> - add quirk flag for FORCE bit
> - add quirk flag for propagating set_rate
> - fix writing to PDSTAT instead of PDCTL
> - remove unused doc comment parameter
> - change davinci_psc_register_clocks() to handle registering clkdev entries
>
>
>  drivers/clk/davinci/Makefile |   2 +
>  drivers/clk/davinci/psc.c| 495 
> +++
>  drivers/clk/davinci/psc.h|  89 
>  3 files changed, 586 insertions(+)
>  create mode 100644 drivers/clk/davinci/psc.c
>  create mode 100644 drivers/clk/davinci/psc.h
>
> diff --git a/drivers/clk/davinci/Makefile b/drivers/clk/davinci/Makefile
> index d471386..cd1bf2c 100644
> --- a/drivers/clk/davinci/Makefile
> +++ b/drivers/clk/davinci/Makefile
> @@ -8,4 +8,6 @@ obj-$(CONFIG_ARCH_DAVINCI_DM355)+= pll-dm355.o
>  obj-$(CONFIG_ARCH_DAVINCI_DM365)   += pll-dm365.o
>  obj-$(CONFIG_ARCH_DAVINCI_DM644x)  += pll-dm644x.o
>  obj-$(CONFIG_ARCH_DAVINCI_DM646x)  += pll-dm646x.o
> +
> +obj-y += psc.o
>  endif
> diff --git a/drivers/clk/davinci/psc.c b/drivers/clk/davinci/psc.c
> new file mode 100644
> index 000..8e08ac8
> --- /dev/null
> +++ b/drivers/clk/davinci/psc.c
> @@ -0,0 +1,495 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Clock driver for TI Davinci PSC controllers
> + *
> + * Copyright (C) 2017 David Lechner 
> + *
> + * Based on: drivers/clk/keystone/gate.c
> + * Copyright (C) 2013 Texas Instruments.
> + * Murali Karicheri 
> + * Santosh Shilimkar 
> + *
> + * And: arch/arm/mach-davinci/psc.c
> + * Copyright (C) 2006 Texas Instruments.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "psc.h"
> +
> +/* PSC register offsets */
> +#define EPCPR  0x070
> +#define PTCMD  0x120
> +#define PTSTAT 0x128
> +#define PDSTAT(n)  (0x200 + 4 * (n))
> +#define PDCTL(n)   (0x300 + 4 * (n))
> +#define MDSTAT(n)  (0x800 + 4 * (n))
> +#define MDCTL(n)   (0xa00 + 4 * (n))
> +
> +/* PSC module states */
> +enum davinci_lpsc_state {
> +   LPSC_STATE_SWRSTDISABLE = 0,
> +   LPSC_STATE_SYNCRST  = 1,
> +   LPSC_STATE_DISABLE  = 2,
> +   LPSC_STATE_ENABLE   = 3,
> +};
> +
> +#define MDSTAT_STATE_MASK  GENMASK(5, 0)
> +#define MDSTAT_MCKOUT  BIT(12)
> +#define PDSTAT_STATE_MASK  GENMASK(4, 0)
> +#define MDCTL_FORCEBIT(31)
> +#define MDCTL_LRESET   BIT(8)
> +#define PDCTL_EPCGOOD  BIT(8)
> +#define PDCTL_NEXT BIT(0)
> +
> +struct davinci_psc_data {
> +   struct clk_onecell_data clk_data;
> +   struct genpd_onecell_data pm_data;
> +   struct reset_controller_dev rcdev;
> +};
> +
> +/**
> + * struct davinci_lpsc_clk - LPSC clock structure
> + * @hw: clk_hw for the LPSC
> + * @pm_domain: power domain for the LPSC
> + * @regmap: PSC MMIO region
> + * @md: Module domain (LPSC module id)
> + * @pd: Power domain
> + * @flags: LPSC_* quirk flags
> + */
> +struct davinci_lpsc_clk {
> +   struct clk_hw hw;
> +   struct generic_pm_domain pm_domain;
> +   struct regmap *regmap;
> +   u32 md;
> +   u32 pd;
> +   u32 flags;
> +};
> +
> +#define to_davinci_psc_data(x) container_of(x, struct davinci_psc_data, x)
> +#define to_davinci_lpsc_clk(x) container_of(x, struct davinci_lpsc_clk, x)
> +
> +static void davinci_lpsc_config(struct davinci_lpsc_clk *lpsc,
> +   enum davinci_lpsc_state next_state)
> +{
> +   u32 epcpr, pdstat, mdstat, ptstat;
> +
> +   regmap_write_bits(lpsc->regmap, MDCTL(lpsc->md), MDSTAT_STATE_MASK,
> + next_state);
> +
> +   if (lpsc->flags & LPSC_FORCE)
> +   regmap_write_bits(lpsc->regmap, MDCTL(lpsc->md), MDCTL_FORCE,
> + MDCTL_FORCE);
> +
> +   regmap_read(lpsc->regmap, PDSTAT(lpsc->pd), );
> +