[v3,0/8] OMAP3: convert opp-v1 to opp-v2 and read speed binned / 720MHz grade bits
mbox series

Message ID cover.1568224032.git.hns@goldelico.com
Headers show
Series
  • OMAP3: convert opp-v1 to opp-v2 and read speed binned / 720MHz grade bits
Related show

Message

H. Nikolaus Schaller Sept. 11, 2019, 5:47 p.m. UTC
CHANGES V3:
* make omap36xx control the abb-ldo and properly switch mode
  (suggested by Adam Ford <aford173@gmail.com>)
* add a note about enabling the turbo-mode OPPs

PATCH V2 2019-09-07 19:46:58:
* fix ti-cpufreq to properly describe which compatible string is legacy
* add some reviewed-by and acked-by Tony Lindgren <tony@atomide.com>
* include am3517 patches by Adam Ford <aford173@gmail.com>
* review opp-suspend; and add turbo-mode; opp properties
* add a note how to disable an OPP in a board.dts file

PATCH V1 2019-09-07 08:56:19:
* fix typo in omap3-ldp.dts
  (reported by Tony Lindgren <tony@atomide.com>)
* extend commit message to describe the bit patterns needed
  for opp-supported-hw
* add error check to ioremap()
  (suggested by Christ van Willegen <cvwillegen@gmail.com>)
* update Documentation/devicetree/bindings/arm/omap/omap.txt
* change bulk update to use "ti,omap3430" and "ti,omap3630"
* update OPP4 of omap3430 to 1275 mV since it was not a valid
  voltage for the twl4030 driver (reported by Tony Lindgren
  <tony@atomide.com>)

RFC V2 2019-09-04 10:53:43:
* merge separate patch to remove opp-v1 table from n950-n9 into
  the general omap3xxx.dtsi patch
  (suggested by Viresh Kumar <viresh.kumar@linaro.org>)
* add legacy compatibility to ti,omap3430 and ti,omap3630 for
  the ti-cpufreq driver
* make driver and omap3xxx.dtsi patches pass checkpatch
* add bulk patch to explicitly define compatibility to ti,omap3430
  and ti,omap36xx in addition to ti,omap3 of all in-tree boards
  where it was missing

RFC V1 2019-09-02 12:55:55:

This patch set converts the omap3 opp tables to opp-v2 format
and extends the ti-cpufreq to support omap3.

It adds 720 MHz (omap34xx) and 1 GHz (omap36xx) OPPs but
tells the ti-cpufreq driver to disable them if the speed
binned / 720MHz grade eFuse bits indicate that the chip
is not rated for that speed. 

It has been tested (for chip variant detection, not reliability
of the high speed OPPs) on:

* BeagleBoard C2 (omap3530 600MHz)
* BeagleBoard XM B (dm3730 800MHz)
* GTA04A4 (dm3730 800MHz)
* GTA04A5 (dm3730 1GHz)


Adam Ford (2):
  cpufreq: ti-cpufreq: Add support for AM3517
  ARM: dts: Add OPP-V2 table for AM3517

H. Nikolaus Schaller (6):
  cpufreq: ti-cpufreq: add support for omap34xx and omap36xx
  ARM: dts: omap34xx & omap36xx: replace opp-v1 tables by opp-v2 for
  DTS: bindings: omap: update bindings documentation
  ARM: dts: omap3: bulk convert compatible to be explicitly ti,omap3430
    or ti,omap3630 or ti,am3517
  cpufreq: ti-cpufreq: omap36xx use "cpu0","vbb" if run in
    multi_regulator mode
  ARM: dts: omap36xx: using OPP1G needs to control the abb_ldo

 .../devicetree/bindings/arm/omap/omap.txt     |  30 +++--
 .../bindings/cpufreq/ti-cpufreq.txt           |   6 +-
 arch/arm/boot/dts/am3517.dtsi                 |  31 +++++
 arch/arm/boot/dts/am3517_mt_ventoux.dts       |   2 +-
 .../boot/dts/logicpd-som-lv-35xx-devkit.dts   |   2 +-
 .../boot/dts/logicpd-torpedo-35xx-devkit.dts  |   2 +-
 arch/arm/boot/dts/omap3-beagle-xm.dts         |   2 +-
 arch/arm/boot/dts/omap3-beagle.dts            |   2 +-
 arch/arm/boot/dts/omap3-cm-t3530.dts          |   2 +-
 arch/arm/boot/dts/omap3-cm-t3730.dts          |   2 +-
 arch/arm/boot/dts/omap3-devkit8000-lcd43.dts  |   2 +-
 arch/arm/boot/dts/omap3-devkit8000-lcd70.dts  |   2 +-
 arch/arm/boot/dts/omap3-devkit8000.dts        |   2 +-
 arch/arm/boot/dts/omap3-gta04.dtsi            |   2 +-
 arch/arm/boot/dts/omap3-ha-lcd.dts            |   2 +-
 arch/arm/boot/dts/omap3-ha.dts                |   2 +-
 arch/arm/boot/dts/omap3-igep0020-rev-f.dts    |   2 +-
 arch/arm/boot/dts/omap3-igep0020.dts          |   2 +-
 arch/arm/boot/dts/omap3-igep0030-rev-g.dts    |   2 +-
 arch/arm/boot/dts/omap3-igep0030.dts          |   2 +-
 arch/arm/boot/dts/omap3-ldp.dts               |   2 +-
 arch/arm/boot/dts/omap3-lilly-a83x.dtsi       |   2 +-
 arch/arm/boot/dts/omap3-lilly-dbb056.dts      |   2 +-
 arch/arm/boot/dts/omap3-n9.dts                |   2 +-
 arch/arm/boot/dts/omap3-n950-n9.dtsi          |   7 --
 arch/arm/boot/dts/omap3-n950.dts              |   2 +-
 .../arm/boot/dts/omap3-overo-storm-alto35.dts |   2 +-
 .../boot/dts/omap3-overo-storm-chestnut43.dts |   2 +-
 .../boot/dts/omap3-overo-storm-gallop43.dts   |   2 +-
 .../arm/boot/dts/omap3-overo-storm-palo35.dts |   2 +-
 .../arm/boot/dts/omap3-overo-storm-palo43.dts |   2 +-
 .../arm/boot/dts/omap3-overo-storm-summit.dts |   2 +-
 arch/arm/boot/dts/omap3-overo-storm-tobi.dts  |   2 +-
 .../boot/dts/omap3-overo-storm-tobiduo.dts    |   2 +-
 arch/arm/boot/dts/omap3-pandora-1ghz.dts      |   2 +-
 arch/arm/boot/dts/omap3-sbc-t3530.dts         |   2 +-
 arch/arm/boot/dts/omap3-sbc-t3730.dts         |   2 +-
 arch/arm/boot/dts/omap3-sniper.dts            |   2 +-
 arch/arm/boot/dts/omap3-thunder.dts           |   2 +-
 arch/arm/boot/dts/omap3-zoom3.dts             |   2 +-
 arch/arm/boot/dts/omap3430-sdp.dts            |   2 +-
 arch/arm/boot/dts/omap34xx.dtsi               |  66 ++++++++--
 arch/arm/boot/dts/omap36xx.dtsi               |  65 ++++++++--
 drivers/cpufreq/cpufreq-dt-platdev.c          |   2 +-
 drivers/cpufreq/ti-cpufreq.c                  | 119 +++++++++++++++++-
 45 files changed, 320 insertions(+), 80 deletions(-)

Comments

Tony Lindgren Sept. 16, 2019, 4:28 p.m. UTC | #1
* H. Nikolaus Schaller <hns@goldelico.com> [190911 17:48]:
> CHANGES V3:
> * make omap36xx control the abb-ldo and properly switch mode
>   (suggested by Adam Ford <aford173@gmail.com>)
> * add a note about enabling the turbo-mode OPPs

Looks good to me, when applying, please provide a
minimal immutable branch maybe against v5.3 or v5.4-rc1,
that I can also merge in if needed for the dts changes.

Thanks,

Tony
H. Nikolaus Schaller Sept. 17, 2019, 2:35 p.m. UTC | #2
Hi Tony,

> Am 16.09.2019 um 18:28 schrieb Tony Lindgren <tony@atomide.com>:
> 
> * H. Nikolaus Schaller <hns@goldelico.com> [190911 17:48]:
>> CHANGES V3:
>> * make omap36xx control the abb-ldo and properly switch mode
>>  (suggested by Adam Ford <aford173@gmail.com>)
>> * add a note about enabling the turbo-mode OPPs
> 
> Looks good to me, when applying, please provide a
> minimal immutable branch maybe against v5.3 or v5.4-rc1,
> that I can also merge in if needed for the dts changes.

Should I resend a v4 with your Acked-By added?

BR and thanks,
Nikolaus
H. Nikolaus Schaller Oct. 2, 2019, 5:47 a.m. UTC | #3
Hi Tony,

> Am 17.09.2019 um 16:35 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
> 
> Hi Tony,
> 
>> Am 16.09.2019 um 18:28 schrieb Tony Lindgren <tony@atomide.com>:
>> 
>> * H. Nikolaus Schaller <hns@goldelico.com> [190911 17:48]:
>>> CHANGES V3:
>>> * make omap36xx control the abb-ldo and properly switch mode
>>> (suggested by Adam Ford <aford173@gmail.com>)
>>> * add a note about enabling the turbo-mode OPPs
>> 
>> Looks good to me, when applying, please provide a
>> minimal immutable branch maybe against v5.3 or v5.4-rc1,
>> that I can also merge in if needed for the dts changes.
> 
> Should I resend a v4 with your Acked-By added?
> 
> BR and thanks,
> Nikolaus
> 

what is the procedure to get this and Adam's thermal setup into linux-next?
BR and thanks,
Nikolaus
Viresh Kumar Oct. 2, 2019, 9 a.m. UTC | #4
On Tue, 17 Sep 2019 at 16:35, H. Nikolaus Schaller <hns@goldelico.com> wrote:
>
> Hi Tony,
>
> > Am 16.09.2019 um 18:28 schrieb Tony Lindgren <tony@atomide.com>:
> >
> > * H. Nikolaus Schaller <hns@goldelico.com> [190911 17:48]:
> >> CHANGES V3:
> >> * make omap36xx control the abb-ldo and properly switch mode
> >>  (suggested by Adam Ford <aford173@gmail.com>)
> >> * add a note about enabling the turbo-mode OPPs
> >
> > Looks good to me, when applying, please provide a
> > minimal immutable branch maybe against v5.3 or v5.4-rc1,
> > that I can also merge in if needed for the dts changes.
>
> Should I resend a v4 with your Acked-By added?

I will pick them up in a few days. I was waiting for rc1 to get released and
am on vacation right now. Tony already provided his Acks.

--
viresh
Viresh Kumar Oct. 10, 2019, 10:45 a.m. UTC | #5
On 11-09-19, 19:47, H. Nikolaus Schaller wrote:
> CHANGES V3:
> * make omap36xx control the abb-ldo and properly switch mode
>   (suggested by Adam Ford <aford173@gmail.com>)
> * add a note about enabling the turbo-mode OPPs

Applied the series to cpufreq/arm tree.

Also shared a branch for you Tony: cpufreq/ti/oppv2.
Adam Ford Nov. 8, 2019, 8:08 p.m. UTC | #6
On Wed, Sep 11, 2019 at 12:47 PM H. Nikolaus Schaller <hns@goldelico.com> wrote:
>
> CHANGES V3:
> * make omap36xx control the abb-ldo and properly switch mode
>   (suggested by Adam Ford <aford173@gmail.com>)
> * add a note about enabling the turbo-mode OPPs
>
> PATCH V2 2019-09-07 19:46:58:
> * fix ti-cpufreq to properly describe which compatible string is legacy
> * add some reviewed-by and acked-by Tony Lindgren <tony@atomide.com>
> * include am3517 patches by Adam Ford <aford173@gmail.com>
> * review opp-suspend; and add turbo-mode; opp properties
> * add a note how to disable an OPP in a board.dts file
>
> PATCH V1 2019-09-07 08:56:19:
> * fix typo in omap3-ldp.dts
>   (reported by Tony Lindgren <tony@atomide.com>)
> * extend commit message to describe the bit patterns needed
>   for opp-supported-hw
> * add error check to ioremap()
>   (suggested by Christ van Willegen <cvwillegen@gmail.com>)
> * update Documentation/devicetree/bindings/arm/omap/omap.txt
> * change bulk update to use "ti,omap3430" and "ti,omap3630"
> * update OPP4 of omap3430 to 1275 mV since it was not a valid
>   voltage for the twl4030 driver (reported by Tony Lindgren
>   <tony@atomide.com>)
>
> RFC V2 2019-09-04 10:53:43:
> * merge separate patch to remove opp-v1 table from n950-n9 into
>   the general omap3xxx.dtsi patch
>   (suggested by Viresh Kumar <viresh.kumar@linaro.org>)
> * add legacy compatibility to ti,omap3430 and ti,omap3630 for
>   the ti-cpufreq driver
> * make driver and omap3xxx.dtsi patches pass checkpatch
> * add bulk patch to explicitly define compatibility to ti,omap3430
>   and ti,omap36xx in addition to ti,omap3 of all in-tree boards
>   where it was missing
>
> RFC V1 2019-09-02 12:55:55:
>
> This patch set converts the omap3 opp tables to opp-v2 format
> and extends the ti-cpufreq to support omap3.
>
> It adds 720 MHz (omap34xx) and 1 GHz (omap36xx) OPPs but
> tells the ti-cpufreq driver to disable them if the speed
> binned / 720MHz grade eFuse bits indicate that the chip
> is not rated for that speed.
>
> It has been tested (for chip variant detection, not reliability
> of the high speed OPPs) on:
>
> * BeagleBoard C2 (omap3530 600MHz)
> * BeagleBoard XM B (dm3730 800MHz)
> * GTA04A4 (dm3730 800MHz)
> * GTA04A5 (dm3730 1GHz)
>
>
> Adam Ford (2):
>   cpufreq: ti-cpufreq: Add support for AM3517
>   ARM: dts: Add OPP-V2 table for AM3517
>

Nikolaus,

I am getting some notices sent to me when I apply your series.  It
works, but I want to clean up the notice.  Can you suggest what might
cause this:

     debugfs: Directory 'cpu0-cpu0' with parent
'48070000.i2c:twl@48:regulator-vdd1-VDD1' already present!

It wasn't present before your series.  It's not a big deal, but I'd
like to quiet down the messages if I can.
Thanks.

adam

> H. Nikolaus Schaller (6):
>   cpufreq: ti-cpufreq: add support for omap34xx and omap36xx
>   ARM: dts: omap34xx & omap36xx: replace opp-v1 tables by opp-v2 for
>   DTS: bindings: omap: update bindings documentation
>   ARM: dts: omap3: bulk convert compatible to be explicitly ti,omap3430
>     or ti,omap3630 or ti,am3517
>   cpufreq: ti-cpufreq: omap36xx use "cpu0","vbb" if run in
>     multi_regulator mode
>   ARM: dts: omap36xx: using OPP1G needs to control the abb_ldo
>
>  .../devicetree/bindings/arm/omap/omap.txt     |  30 +++--
>  .../bindings/cpufreq/ti-cpufreq.txt           |   6 +-
>  arch/arm/boot/dts/am3517.dtsi                 |  31 +++++
>  arch/arm/boot/dts/am3517_mt_ventoux.dts       |   2 +-
>  .../boot/dts/logicpd-som-lv-35xx-devkit.dts   |   2 +-
>  .../boot/dts/logicpd-torpedo-35xx-devkit.dts  |   2 +-
>  arch/arm/boot/dts/omap3-beagle-xm.dts         |   2 +-
>  arch/arm/boot/dts/omap3-beagle.dts            |   2 +-
>  arch/arm/boot/dts/omap3-cm-t3530.dts          |   2 +-
>  arch/arm/boot/dts/omap3-cm-t3730.dts          |   2 +-
>  arch/arm/boot/dts/omap3-devkit8000-lcd43.dts  |   2 +-
>  arch/arm/boot/dts/omap3-devkit8000-lcd70.dts  |   2 +-
>  arch/arm/boot/dts/omap3-devkit8000.dts        |   2 +-
>  arch/arm/boot/dts/omap3-gta04.dtsi            |   2 +-
>  arch/arm/boot/dts/omap3-ha-lcd.dts            |   2 +-
>  arch/arm/boot/dts/omap3-ha.dts                |   2 +-
>  arch/arm/boot/dts/omap3-igep0020-rev-f.dts    |   2 +-
>  arch/arm/boot/dts/omap3-igep0020.dts          |   2 +-
>  arch/arm/boot/dts/omap3-igep0030-rev-g.dts    |   2 +-
>  arch/arm/boot/dts/omap3-igep0030.dts          |   2 +-
>  arch/arm/boot/dts/omap3-ldp.dts               |   2 +-
>  arch/arm/boot/dts/omap3-lilly-a83x.dtsi       |   2 +-
>  arch/arm/boot/dts/omap3-lilly-dbb056.dts      |   2 +-
>  arch/arm/boot/dts/omap3-n9.dts                |   2 +-
>  arch/arm/boot/dts/omap3-n950-n9.dtsi          |   7 --
>  arch/arm/boot/dts/omap3-n950.dts              |   2 +-
>  .../arm/boot/dts/omap3-overo-storm-alto35.dts |   2 +-
>  .../boot/dts/omap3-overo-storm-chestnut43.dts |   2 +-
>  .../boot/dts/omap3-overo-storm-gallop43.dts   |   2 +-
>  .../arm/boot/dts/omap3-overo-storm-palo35.dts |   2 +-
>  .../arm/boot/dts/omap3-overo-storm-palo43.dts |   2 +-
>  .../arm/boot/dts/omap3-overo-storm-summit.dts |   2 +-
>  arch/arm/boot/dts/omap3-overo-storm-tobi.dts  |   2 +-
>  .../boot/dts/omap3-overo-storm-tobiduo.dts    |   2 +-
>  arch/arm/boot/dts/omap3-pandora-1ghz.dts      |   2 +-
>  arch/arm/boot/dts/omap3-sbc-t3530.dts         |   2 +-
>  arch/arm/boot/dts/omap3-sbc-t3730.dts         |   2 +-
>  arch/arm/boot/dts/omap3-sniper.dts            |   2 +-
>  arch/arm/boot/dts/omap3-thunder.dts           |   2 +-
>  arch/arm/boot/dts/omap3-zoom3.dts             |   2 +-
>  arch/arm/boot/dts/omap3430-sdp.dts            |   2 +-
>  arch/arm/boot/dts/omap34xx.dtsi               |  66 ++++++++--
>  arch/arm/boot/dts/omap36xx.dtsi               |  65 ++++++++--
>  drivers/cpufreq/cpufreq-dt-platdev.c          |   2 +-
>  drivers/cpufreq/ti-cpufreq.c                  | 119 +++++++++++++++++-
>  45 files changed, 320 insertions(+), 80 deletions(-)
>
> --
> 2.19.1
>
H. Nikolaus Schaller Nov. 9, 2019, 6:12 a.m. UTC | #7
Hi Adam,

> Am 08.11.2019 um 21:08 schrieb Adam Ford <aford173@gmail.com>:
> 
> 
> Nikolaus,
> 
> I am getting some notices sent to me when I apply your series.  It
> works, but I want to clean up the notice.  Can you suggest what might
> cause this:
> 
>     debugfs: Directory 'cpu0-cpu0' with parent
> '48070000.i2c:twl@48:regulator-vdd1-VDD1' already present!
> 
> It wasn't present before your series.  It's not a big deal, but I'd
> like to quiet down the messages if I can.
> Thanks.

I have checked and can also see this message - and it should be removed.

There is a debugfs node at:

/sys/kernel/debug/regulator/48070000.i2c:twl@48:regulator-vdd1-VDD1/cpu0-cpu0

OMAP5 also has a similar node but no such debugfs warning:

/sys/kernel/debug/regulator/smps123/cpu0-cpu0

So what I suspect is some bug in the twl4030 regulator driver which is
just revealed by my patch series for the first time.

Could it be that the debugfs node is created and not cleaned up by deferred
probing?

But this is not explicitly done in drivers/regulator/twl-regulator.c

BTW: twl6030 and palmas (twl6037) have separate driver, so that mentioning
twl6030 in the comments in drivers/regulator/twl-regulator.c may be wrong.
It also mentions some "TW5030" which I have never heard of.

To find out the call sequence I added a dump_stack to start_creating()
after the error message is printed:


[    2.289947] debugfs: Directory 'cpu0-cpu0' with parent '48070000.i2c:twl@48:regulator-vdd1-VDD1' already present!
[    2.301727] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.4.0-rc6-letux+ #1329
[    2.309112] Hardware name: Generic OMAP36xx (Flattened Device Tree)
[    2.315734] [<c0110028>] (unwind_backtrace) from [<c010b60c>] (show_stack+0x10/0x14)
[    2.323852] [<c010b60c>] (show_stack) from [<c07b9b60>] (dump_stack+0x7c/0x9c)
[    2.331420] [<c07b9b60>] (dump_stack) from [<c0373588>] (start_creating+0xa8/0x104)
[    2.339477] [<c0373588>] (start_creating) from [<c0373fb0>] (debugfs_create_dir+0xc/0xc0)
[    2.348052] [<c0373fb0>] (debugfs_create_dir) from [<c04e96e0>] (create_regulator+0xd0/0x1c8)
[    2.356994] [<c04e96e0>] (create_regulator) from [<c04ec608>] (_regulator_get+0x190/0x224)
[    2.365661] [<c04ec608>] (_regulator_get) from [<c06653d0>] (dt_cpufreq_probe+0x80/0x108)
[    2.374237] [<c06653d0>] (dt_cpufreq_probe) from [<c053e018>] (platform_drv_probe+0x48/0x98)
[    2.383087] [<c053e018>] (platform_drv_probe) from [<c053c3a8>] (really_probe+0x164/0x324)
[    2.391754] [<c053c3a8>] (really_probe) from [<c053c7b8>] (driver_probe_device+0x10c/0x154)
[    2.400512] [<c053c7b8>] (driver_probe_device) from [<c053a9f4>] (bus_for_each_drv+0x90/0xb8)
[    2.409423] [<c053a9f4>] (bus_for_each_drv) from [<c053c5f8>] (__device_attach+0x90/0x120)
[    2.418090] [<c053c5f8>] (__device_attach) from [<c053b628>] (bus_probe_device+0x28/0x80)
[    2.426666] [<c053b628>] (bus_probe_device) from [<c05393ec>] (device_add+0x2f0/0x55c)
[    2.434967] [<c05393ec>] (device_add) from [<c053decc>] (platform_device_add+0x12c/0x1b8)
[    2.443542] [<c053decc>] (platform_device_add) from [<c053e954>] (platform_device_register_full+0xec/0x13c)
[    2.453765] [<c053e954>] (platform_device_register_full) from [<c0665ff4>] (ti_cpufreq_probe+0x298/0x2fc)
[    2.463775] [<c0665ff4>] (ti_cpufreq_probe) from [<c053e018>] (platform_drv_probe+0x48/0x98)
[    2.472625] [<c053e018>] (platform_drv_probe) from [<c053c3a8>] (really_probe+0x164/0x324)
[    2.481292] [<c053c3a8>] (really_probe) from [<c053c7b8>] (driver_probe_device+0x10c/0x154)
[    2.490051] [<c053c7b8>] (driver_probe_device) from [<c053a9f4>] (bus_for_each_drv+0x90/0xb8)
[    2.498992] [<c053a9f4>] (bus_for_each_drv) from [<c053c5f8>] (__device_attach+0x90/0x120)
[    2.507629] [<c053c5f8>] (__device_attach) from [<c053b628>] (bus_probe_device+0x28/0x80)
[    2.516204] [<c053b628>] (bus_probe_device) from [<c05393ec>] (device_add+0x2f0/0x55c)
[    2.524505] [<c05393ec>] (device_add) from [<c053decc>] (platform_device_add+0x12c/0x1b8)
[    2.533081] [<c053decc>] (platform_device_add) from [<c053e954>] (platform_device_register_full+0xec/0x13c)
[    2.543304] [<c053e954>] (platform_device_register_full) from [<c0665d2c>] (ti_cpufreq_init+0x78/0xa8)
[    2.553039] [<c0665d2c>] (ti_cpufreq_init) from [<c0102ed8>] (do_one_initcall+0xb4/0x268)
[    2.561645] [<c0102ed8>] (do_one_initcall) from [<c0b00fe4>] (kernel_init_freeable+0x11c/0x1ec)
[    2.570770] [<c0b00fe4>] (kernel_init_freeable) from [<c07cf1c8>] (kernel_init+0x8/0x110)
[    2.579345] [<c07cf1c8>] (kernel_init) from [<c01010e8>] (ret_from_fork+0x14/0x2c)
[    2.587249] Exception stack(0xde0b1fb0 to 0xde0b1ff8)
[    2.592559] 1fa0:                                     00000000 00000000 00000000 00000000
[    2.601135] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    2.609680] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000


So the problem seems to be that ti_cpufreq_probe() tries to register the regulators
"vdd" and "vbb" without properly checking if they have been registered elsewhere.

The second attempt to create the debugfs directory seems to come from resources_available()
which thinks that it has to create the regulator (again) [around line 1935 in drivers/regulator/core.c].

Hope this helps, although I have no idea why the vdd regulator already exists at that point.

BR,
Nikolaus
Adam Ford Nov. 9, 2019, 10:02 a.m. UTC | #8
On Sat, Nov 9, 2019 at 12:12 AM H. Nikolaus Schaller <hns@goldelico.com> wrote:
>
> Hi Adam,
>
> > Am 08.11.2019 um 21:08 schrieb Adam Ford <aford173@gmail.com>:
> >
> >
> > Nikolaus,
> >
> > I am getting some notices sent to me when I apply your series.  It
> > works, but I want to clean up the notice.  Can you suggest what might
> > cause this:
> >
> >     debugfs: Directory 'cpu0-cpu0' with parent
> > '48070000.i2c:twl@48:regulator-vdd1-VDD1' already present!
> >
> > It wasn't present before your series.  It's not a big deal, but I'd
> > like to quiet down the messages if I can.
> > Thanks.
>
> I have checked and can also see this message - and it should be removed.
>
> There is a debugfs node at:
>
> /sys/kernel/debug/regulator/48070000.i2c:twl@48:regulator-vdd1-VDD1/cpu0-cpu0
>
> OMAP5 also has a similar node but no such debugfs warning:
>
> /sys/kernel/debug/regulator/smps123/cpu0-cpu0
>
> So what I suspect is some bug in the twl4030 regulator driver which is
> just revealed by my patch series for the first time.

I was wondering that too.

>
> Could it be that the debugfs node is created and not cleaned up by deferred
> probing?

That would make sense to me.

>
> But this is not explicitly done in drivers/regulator/twl-regulator.c
>
> BTW: twl6030 and palmas (twl6037) have separate driver, so that mentioning
> twl6030 in the comments in drivers/regulator/twl-regulator.c may be wrong.
> It also mentions some "TW5030" which I have never heard of.
>
> To find out the call sequence I added a dump_stack to start_creating()
> after the error message is printed:
>
>
> [    2.289947] debugfs: Directory 'cpu0-cpu0' with parent '48070000.i2c:twl@48:regulator-vdd1-VDD1' already present!
> [    2.301727] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.4.0-rc6-letux+ #1329
> [    2.309112] Hardware name: Generic OMAP36xx (Flattened Device Tree)
> [    2.315734] [<c0110028>] (unwind_backtrace) from [<c010b60c>] (show_stack+0x10/0x14)
> [    2.323852] [<c010b60c>] (show_stack) from [<c07b9b60>] (dump_stack+0x7c/0x9c)
> [    2.331420] [<c07b9b60>] (dump_stack) from [<c0373588>] (start_creating+0xa8/0x104)
> [    2.339477] [<c0373588>] (start_creating) from [<c0373fb0>] (debugfs_create_dir+0xc/0xc0)
> [    2.348052] [<c0373fb0>] (debugfs_create_dir) from [<c04e96e0>] (create_regulator+0xd0/0x1c8)
> [    2.356994] [<c04e96e0>] (create_regulator) from [<c04ec608>] (_regulator_get+0x190/0x224)
> [    2.365661] [<c04ec608>] (_regulator_get) from [<c06653d0>] (dt_cpufreq_probe+0x80/0x108)
> [    2.374237] [<c06653d0>] (dt_cpufreq_probe) from [<c053e018>] (platform_drv_probe+0x48/0x98)
> [    2.383087] [<c053e018>] (platform_drv_probe) from [<c053c3a8>] (really_probe+0x164/0x324)
> [    2.391754] [<c053c3a8>] (really_probe) from [<c053c7b8>] (driver_probe_device+0x10c/0x154)
> [    2.400512] [<c053c7b8>] (driver_probe_device) from [<c053a9f4>] (bus_for_each_drv+0x90/0xb8)
> [    2.409423] [<c053a9f4>] (bus_for_each_drv) from [<c053c5f8>] (__device_attach+0x90/0x120)
> [    2.418090] [<c053c5f8>] (__device_attach) from [<c053b628>] (bus_probe_device+0x28/0x80)
> [    2.426666] [<c053b628>] (bus_probe_device) from [<c05393ec>] (device_add+0x2f0/0x55c)
> [    2.434967] [<c05393ec>] (device_add) from [<c053decc>] (platform_device_add+0x12c/0x1b8)
> [    2.443542] [<c053decc>] (platform_device_add) from [<c053e954>] (platform_device_register_full+0xec/0x13c)
> [    2.453765] [<c053e954>] (platform_device_register_full) from [<c0665ff4>] (ti_cpufreq_probe+0x298/0x2fc)
> [    2.463775] [<c0665ff4>] (ti_cpufreq_probe) from [<c053e018>] (platform_drv_probe+0x48/0x98)
> [    2.472625] [<c053e018>] (platform_drv_probe) from [<c053c3a8>] (really_probe+0x164/0x324)
> [    2.481292] [<c053c3a8>] (really_probe) from [<c053c7b8>] (driver_probe_device+0x10c/0x154)
> [    2.490051] [<c053c7b8>] (driver_probe_device) from [<c053a9f4>] (bus_for_each_drv+0x90/0xb8)
> [    2.498992] [<c053a9f4>] (bus_for_each_drv) from [<c053c5f8>] (__device_attach+0x90/0x120)
> [    2.507629] [<c053c5f8>] (__device_attach) from [<c053b628>] (bus_probe_device+0x28/0x80)
> [    2.516204] [<c053b628>] (bus_probe_device) from [<c05393ec>] (device_add+0x2f0/0x55c)
> [    2.524505] [<c05393ec>] (device_add) from [<c053decc>] (platform_device_add+0x12c/0x1b8)
> [    2.533081] [<c053decc>] (platform_device_add) from [<c053e954>] (platform_device_register_full+0xec/0x13c)
> [    2.543304] [<c053e954>] (platform_device_register_full) from [<c0665d2c>] (ti_cpufreq_init+0x78/0xa8)
> [    2.553039] [<c0665d2c>] (ti_cpufreq_init) from [<c0102ed8>] (do_one_initcall+0xb4/0x268)
> [    2.561645] [<c0102ed8>] (do_one_initcall) from [<c0b00fe4>] (kernel_init_freeable+0x11c/0x1ec)
> [    2.570770] [<c0b00fe4>] (kernel_init_freeable) from [<c07cf1c8>] (kernel_init+0x8/0x110)
> [    2.579345] [<c07cf1c8>] (kernel_init) from [<c01010e8>] (ret_from_fork+0x14/0x2c)
> [    2.587249] Exception stack(0xde0b1fb0 to 0xde0b1ff8)
> [    2.592559] 1fa0:                                     00000000 00000000 00000000 00000000
> [    2.601135] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> [    2.609680] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000
>
>
> So the problem seems to be that ti_cpufreq_probe() tries to register the regulators
> "vdd" and "vbb" without properly checking if they have been registered elsewhere.
>
> The second attempt to create the debugfs directory seems to come from resources_available()
> which thinks that it has to create the regulator (again) [around line 1935 in drivers/regulator/core.c].
>
> Hope this helps, although I have no idea why the vdd regulator already exists at that point.

Thank you for the detailed analysis.


>
> BR,
> Nikolaus
>
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel