OMAP3: convert opp-v1 to opp-v2 and read speed binned / 720MHz grade bits

This adds code and tables to read the silicon revision and eFuse (speed binned / 720 MHz grade) bits for selecting opp-v2 table entries.

Since these bits are not always part of the syscon register range (like for am33xx, am43, dra7), we add code to directly read the register values using ioremap() if syscon access fails.

The format of the opp-supported-hw entries is that it has two 32 bit bitfields. E.g.:

        opp-supported-hw = <0xffffffff 3>

The first value is matched against the bit position of the silicon revision which is (see TRM)

omap34xx:

BIT(0)  ES1.0
BIT(1)  ES2.0
BIT(2)  ES2.1
BIT(3)  ES3.0
BIT(4)  ES3.1
BIT(7)  ES3.1.2

omap36xx:

BIT(0)  ES1.0
BIT(1)  ES1.1
BIT(2)  ES1.2

The second value is matched against the speed grade eFuse:

BIT(0) no high speed OPP
BIT(1) high speed OPP

This means for the example above that it is always enabled while e.g.

        opp-supported-hw = <0x1 2>

enables the OPP only for ES1.0 BIT(0) and if the high speed eFuse is set BIT(1).

Signed-off-by H. Nikolaus Schaller <[email protected]>

Reviewed-by Tony Lindgren <[email protected]>

---
 drivers/cpufreq/ti-cpufreq.c | 91 +++++++++++++++++++++++++++++++++++-
 1 file changed, 89 insertions(+), 2 deletions(-)

drivers/cpufreq/ti-cpufreq.c +89 -3

index 2ad1ae17932d..f2f58d689320 100644
@@ -31,6 +31,11 @@
 #define DRA7_EFUSE_OD_MPU_OPP                  BIT(1)
 #define DRA7_EFUSE_HIGH_MPU_OPP                        BIT(2)
 
+#define OMAP3_CONTROL_DEVICE_STATUS            0x4800244C
+#define OMAP3_CONTROL_IDCODE                   0x4830A204
+#define OMAP34xx_ProdID_SKUID                  0x4830A20C
+#define OMAP3_SYSCON_BASE      (0x48000000 + 0x2000 + 0x270)
+
 #define VERSION_COUNT                          2
 
 struct ti_cpufreq_data;

@@ -84,6 +89,13 @@ static unsigned long dra7_efuse_xlate(struct ti_cpufreq_data *opp_data,
        return calculated_efuse;
 }
 
+static unsigned long omap3_efuse_xlate(struct ti_cpufreq_data *opp_data,
+                                     unsigned long efuse)
+{
+       /* OPP enable bit ("Speed Binned") */
+       return BIT(efuse);
+}
+
 static struct ti_cpufreq_soc_data am3x_soc_data = {
        .efuse_xlate = amx3_efuse_xlate,
        .efuse_fallback = AM33XX_800M_ARM_MPU_MAX_FREQ,

@@ -111,6 +123,56 @@ static struct ti_cpufreq_soc_data dra7_soc_data = {
        .multi_regulator = true,
 };
 
+/*
+ * OMAP35x TRM (SPRUF98K):
+ *  CONTROL_IDCODE (0x4830 A204) describes Silicon revisions.
+ *  Control OMAP Status Register 15:0 (Address 0x4800 244C)
+ *    to separate between omap3503, omap3515, omap3525, omap3530
+ *    and feature presence.
+ *    There are encodings for versions limited to 400/266MHz
+ *    but we ignore.
+ *    Not clear if this also holds for omap34xx.
+ *  some eFuse values e.g. CONTROL_FUSE_OPP1_VDD1
+ *    are stored in the SYSCON register range
+ *  Register 0x4830A20C [ProdID.SKUID] [0:3]
+ *    0x0 for normal 600/430MHz device.
+ *    0x8 for 720/520MHz device.
+ *    Not clear what omap34xx value is.
+ */
+
+static struct ti_cpufreq_soc_data omap34xx_soc_data = {
+       .efuse_xlate = omap3_efuse_xlate,
+       .efuse_offset = OMAP34xx_ProdID_SKUID - OMAP3_SYSCON_BASE,
+       .efuse_shift = 3,
+       .efuse_mask = BIT(3),
+       .rev_offset = OMAP3_CONTROL_IDCODE - OMAP3_SYSCON_BASE,
+       .multi_regulator = false,
+};
+
+/*
+ * AM/DM37x TRM (SPRUGN4M)
+ *  CONTROL_IDCODE (0x4830 A204) describes Silicon revisions.
+ *  Control Device Status Register 15:0 (Address 0x4800 244C)
+ *    to separate between am3703, am3715, dm3725, dm3730
+ *    and feature presence.
+ *   Speed Binned = Bit 9
+ *     0 800/600 MHz
+ *     1 1000/800 MHz
+ *  some eFuse values e.g. CONTROL_FUSE_OPP 1G_VDD1
+ *    are stored in the SYSCON register range.
+ *  There is no 0x4830A20C [ProdID.SKUID] register (exists but
+ *    seems to always read as 0).
+ */
+
+static struct ti_cpufreq_soc_data omap36xx_soc_data = {
+       .efuse_xlate = omap3_efuse_xlate,
+       .efuse_offset = OMAP3_CONTROL_DEVICE_STATUS - OMAP3_SYSCON_BASE,
+       .efuse_shift = 9,
+       .efuse_mask = BIT(9),
+       .rev_offset = OMAP3_CONTROL_IDCODE - OMAP3_SYSCON_BASE,
+       .multi_regulator = false,
+};
+
 /**
  * ti_cpufreq_get_efuse() - Parse and return efuse value present on SoC
  * @opp_data: pointer to ti_cpufreq_data context

@@ -127,7 +189,17 @@ static int ti_cpufreq_get_efuse(struct ti_cpufreq_data *opp_data,
 
        ret = regmap_read(opp_data->syscon, opp_data->soc_data->efuse_offset,
                          &efuse);
-       if (ret) {
+       if (ret == -EIO) {
+               /* not a syscon register! */
+               void __iomem *regs = ioremap(OMAP3_SYSCON_BASE +
+                               opp_data->soc_data->efuse_offset, 4);
+
+               if (!regs)
+                       return -ENOMEM;
+               efuse = readl(regs);
+               iounmap(regs);
+               }
+       else if (ret) {
                dev_err(dev,
                        "Failed to read the efuse value from syscon: %d\n",
                        ret);

@@ -158,7 +230,17 @@ static int ti_cpufreq_get_rev(struct ti_cpufreq_data *opp_data,
 
        ret = regmap_read(opp_data->syscon, opp_data->soc_data->rev_offset,
                          &revision);
-       if (ret) {
+       if (ret == -EIO) {
+               /* not a syscon register! */
+               void __iomem *regs = ioremap(OMAP3_SYSCON_BASE +
+                               opp_data->soc_data->rev_offset, 4);
+
+               if (!regs)
+                       return -ENOMEM;
+               revision = readl(regs);
+               iounmap(regs);
+               }
+       else if (ret) {
                dev_err(dev,
                        "Failed to read the revision number from syscon: %d\n",
                        ret);

@@ -190,6 +272,11 @@ static const struct of_device_id ti_cpufreq_of_match[] = {
        { .compatible = "ti,am33xx", .data = &am3x_soc_data, },
        { .compatible = "ti,am43", .data = &am4x_soc_data, },
        { .compatible = "ti,dra7", .data = &dra7_soc_data },
+       { .compatible = "ti,omap34xx", .data = &omap34xx_soc_data, },
+       { .compatible = "ti,omap36xx", .data = &omap36xx_soc_data, },
+       /* legacy */
+       { .compatible = "ti,omap3430", .data = &omap34xx_soc_data, },
+       { .compatible = "ti,omap3630", .data = &omap36xx_soc_data, },
        {},
 };
 
--

2.19.1

_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

In preparation for using the multi_regulator capability of this driver for handling the ABB LDO for OPP1G of the omap36xx we have to take care that the (legacy) vdd-supply name is cpu0-supply = <&vcc>;

To do this we add another field to the SoC description table which optionally can specify a list of regulator names.

For omap36xx we define "cpu0-supply" and "vbb-supply".

The default remains "vdd-supply" and "vbb-supply".

In preparation for using the multi_regulator capability of this driver for handling the ABB LDO for OPP1G of the omap36xx we have to take care that the (legacy) vdd-supply name is cpu0-supply = <&vcc>;

To do this we add another field to the SoC description table which optionally can specify a list of regulator names.

For omap36xx we define "cpu0-supply" and "vbb-supply".

The default remains "vdd-supply" and "vbb-supply".

Signed-off-by H. Nikolaus Schaller <[email protected]>

---
 .../devicetree/bindings/cpufreq/ti-cpufreq.txt       |  6 +++++-
 drivers/cpufreq/ti-cpufreq.c                         | 12 ++++++++++--
 2 files changed, 15 insertions(+), 3 deletions(-)

See DM3730,DM275 data sheet (SPRS685B) footnote (6) in Table 4-19 which says that ABB must be switched to FBB mode when using the OPP1G.

The LOD definition abb_mpu_iva already exists so that we need to add plumbing for vbb-supply = <&abb_mpu_iva>
and define two voltage vectors for each OPP so that the abb LDO is also updated by the ti-cpufreq driver.

We also must switch the ti_cpufreq_soc_data to multi_regulator.

Note: reading out the abb reglator voltage to verify that it does do transitions can be done by

cat /sys/devices/platform/68000000.ocp/483072f0.regulator-abb-mpu/regulator/regulator.*/microvolts

Likewise, read the twl4030 provided VDD voltage by

cat /sys/devices/platform/68000000.ocp/48070000.i2c/i2c-0/0-0048/48070000.i2c:twl@48:regulator-vdd1/regulator/regulator.*/microvolts

Note: to check if the ABB FBB is enabled/disabled, check registers

PRM_LDO_ABB_CTRL 0x483072F4 bit 3:0 1=bypass 5=FBB PRM_LDO_ABB_SETUP 0x483072F0 0x00=bypass 0x11=FBB

e.g.

/dev/mem opened.
Memory mapped at address 0xb6fe4000.
Value at address 0x483072F4 (0xb6fe42f4): 0x3205
/dev/mem opened.
Memory mapped at address 0xb6f89000.
Value at address 0x483072F4 (0xb6f892f4): 0x3201

Note: omap34xx and am3517 have/need no comparable LDO or mechanism.

Suggested-by Adam Ford <[email protected]>

Signed-off-by H. Nikolaus Schaller <[email protected]>

---
 arch/arm/boot/dts/omap36xx.dtsi | 21 ++++++++++++++++-----
 drivers/cpufreq/ti-cpufreq.c    |  2 +-
 2 files changed, 17 insertions(+), 6 deletions(-)

arch/arm/boot/dts/omap36xx.dtsi +9 -4

index cb5bd0969124..4bb4f534afe2 100644
@@ -23,6 +23,7 @@
                cpu: cpu@0 {
                        operating-points-v2 = <&cpu0_opp_table>;
 
+                       vbb-supply = <&abb_mpu_iva>;
                        clock-latency = <300000>; /* From omap-cpufreq driver */
                };
        };

@@ -37,9 +38,11 @@
                        /*
                         * we currently only select the max voltage from table
                         * Table 4-19 of the DM3730 Data sheet (SPRS685B)
-                        * Format is: <target min max>
+                        * Format is:   cpu0-supply:    <target min max>
+                        *              vbb-supply:     <target min max>
                         */
-                       opp-microvolt = <1012500 1012500 1012500>;
+                       opp-microvolt = <1012500 1012500 1012500>,
+                                        <1012500 1012500 1012500>;
                        /*
                         * first value is silicon revision bit mask
                         * second one is "speed binned" bit mask

@@ -50,25 +53,33 @@
 
                opp100-600000000 {
                        opp-hz = /bits/ 64 <600000000>;
-                       opp-microvolt = <1200000 1200000 1200000>;
+                       opp-microvolt = <1200000 1200000 1200000>,
+                                        <1200000 1200000 1200000>;
                        opp-supported-hw = <0xffffffff 3>;
                };
 
                opp130-800000000 {
                        opp-hz = /bits/ 64 <800000000>;
-                       opp-microvolt = <1325000 1325000 1325000>;
+                       opp-microvolt = <1325000 1325000 1325000>,
+                                        <1325000 1325000 1325000>;
                        opp-supported-hw = <0xffffffff 3>;

arch/arm/boot/dts/omap36xx.dtsi +5 -0

                };
        };
 
+       opp_supply_mpu_iva: opp_supply {
+               compatible = "ti,omap-opp-supply";
+               ti,absolute-max-voltage-uv = <1375000>;
+       };
+
        ocp@68000000 {
                uart4: serial@49042000 {
                        compatible = "ti,omap3-uart";

drivers/cpufreq/ti-cpufreq.c +1 -2

index 1a3073a3093e..f4704f9033e0 100644
@@ -174,7 +174,7 @@ static struct ti_cpufreq_soc_data omap36xx_soc_data = {
        .efuse_shift = 9,
        .efuse_mask = BIT(9),
        .rev_offset = OMAP3_CONTROL_IDCODE - OMAP3_SYSCON_BASE,
-       .multi_regulator = false,
+       .multi_regulator = true,
 };
 
 /**
--

2.19.1

Am 13.09.2019 um 23:13 schrieb Adam Ford <[email protected]>:

Quoted 90 lines · H. Nikolaus Schaller

See DM3730,DM275 data sheet (SPRS685B) footnote (6) in Table 4-19 which says that ABB must be switched to FBB mode when using the OPP1G.

The LOD definition abb_mpu_iva already exists so that we need to add plumbing for vbb-supply = <&abb_mpu_iva>
and define two voltage vectors for each OPP so that the abb LDO is also updated by the ti-cpufreq driver.

We also must switch the ti_cpufreq_soc_data to multi_regulator.

Note: reading out the abb reglator voltage to verify that it does do transitions can be done by

cat /sys/devices/platform/68000000.ocp/483072f0.regulator-abb-mpu/regulator/regulator.*/microvolts

Likewise, read the twl4030 provided VDD voltage by

cat /sys/devices/platform/68000000.ocp/48070000.i2c/i2c-0/0-0048/48070000.i2c:twl@48:regulator-vdd1/regulator/regulator.*/microvolts

Note: to check if the ABB FBB is enabled/disabled, check registers

PRM_LDO_ABB_CTRL 0x483072F4 bit 3:0 1=bypass 5=FBB PRM_LDO_ABB_SETUP 0x483072F0 0x00=bypass 0x11=FBB

e.g.

/dev/mem opened.
Memory mapped at address 0xb6fe4000.
Value at address 0x483072F4 (0xb6fe42f4): 0x3205
/dev/mem opened.
Memory mapped at address 0xb6f89000.
Value at address 0x483072F4 (0xb6f892f4): 0x3201

Note: omap34xx and am3517 have/need no comparable LDO or mechanism.

Suggested-by Adam Ford <[email protected]>

Signed-off-by H. Nikolaus Schaller <[email protected]>

---
arch/arm/boot/dts/omap36xx.dtsi | 21 ++++++++++++++++-----
drivers/cpufreq/ti-cpufreq.c | 2 +-

2 files changed, 17 insertions(+), 6 deletions(-)

arch/arm/boot/dts/omap36xx.dtsi +9 -4

index cb5bd0969124..4bb4f534afe2 100644
@@ -23,6 +23,7 @@
               cpu: cpu@0 {
                       operating-points-v2 = <&cpu0_opp_table>;
 
+                       vbb-supply = <&abb_mpu_iva>;
                       clock-latency = <300000>; /* From omap-cpufreq driver */
               };
       };

@@ -37,9 +38,11 @@
                       /*
                        * we currently only select the max voltage from table
                        * Table 4-19 of the DM3730 Data sheet (SPRS685B)
-                        * Format is: <target min max>
+                        * Format is:   cpu0-supply:    <target min max>
+                        *              vbb-supply:     <target min max>
                        */
-                       opp-microvolt = <1012500 1012500 1012500>;
+                       opp-microvolt = <1012500 1012500 1012500>,
+                                        <1012500 1012500 1012500>;
                       /*
                        * first value is silicon revision bit mask
                        * second one is "speed binned" bit mask

@@ -50,25 +53,33 @@
 
               opp100-600000000 {
                       opp-hz = /bits/ 64 <600000000>;
-                       opp-microvolt = <1200000 1200000 1200000>;
+                       opp-microvolt = <1200000 1200000 1200000>,
+                                        <1200000 1200000 1200000>;
                       opp-supported-hw = <0xffffffff 3>;
               };
 
               opp130-800000000 {
                       opp-hz = /bits/ 64 <800000000>;
-                       opp-microvolt = <1325000 1325000 1325000>;
+                       opp-microvolt = <1325000 1325000 1325000>,
+                                        <1325000 1325000 1325000>;
                       opp-supported-hw = <0xffffffff 3>;
               };
 

arch/arm/boot/dts/omap36xx.dtsi line 74

Quoted 8 lines

arch/arm/boot/dts/omap36xx.dtsi +2 -1

               opp1g-1000000000 {
                       opp-hz = /bits/ 64 <1000000000>;
-                       opp-microvolt = <1375000 1375000 1375000>;
+                       opp-microvolt = <1375000 1375000 1375000>,
+                                        <1375000 1375000 1375000>;
                       /* only on am/dm37x with speed-binned bit set */
                       opp-supported-hw = <0xffffffff 2>;
                       turbo-mode;

If / when the thermal changes I submitted get approved, would you entertain dropping this turbo-mode flag so it's enabled by default?

See DM3730,DM275 data sheet (SPRS685B) footnote (6) in Table 4-19 which says that ABB must be switched to FBB mode when using the OPP1G.

The LOD definition abb_mpu_iva already exists so that we need to add plumbing for vbb-supply = <&abb_mpu_iva>
and define two voltage vectors for each OPP so that the abb LDO is also updated by the ti-cpufreq driver.

We also must switch the ti_cpufreq_soc_data to multi_regulator.

Note: reading out the abb reglator voltage to verify that it does do transitions can be done by

cat /sys/devices/platform/68000000.ocp/483072f0.regulator-abb-mpu/regulator/regulator.*/microvolts

Likewise, read the twl4030 provided VDD voltage by

cat /sys/devices/platform/68000000.ocp/48070000.i2c/i2c-0/0-0048/48070000.i2c:twl@48:regulator-vdd1/regulator/regulator.*/microvolts

Note: to check if the ABB FBB is enabled/disabled, check registers

PRM_LDO_ABB_CTRL 0x483072F4 bit 3:0 1=bypass 5=FBB PRM_LDO_ABB_SETUP 0x483072F0 0x00=bypass 0x11=FBB

e.g.

/dev/mem opened.
Memory mapped at address 0xb6fe4000.
Value at address 0x483072F4 (0xb6fe42f4): 0x3205
/dev/mem opened.
Memory mapped at address 0xb6f89000.
Value at address 0x483072F4 (0xb6f892f4): 0x3201

Note: omap34xx and am3517 have/need no comparable LDO or mechanism.

From: Adam Ford <[email protected]>

The AM3517 only lists 600MHz @ 1.2V, but the register values for 0x4830A204 = 1b86 802f, it seems like am3517 might be a derivative of the omap36 which OPPs would be OPP50 (300 MHz) and OPP100 (600 MHz).

This patch simply adds the am3517 to the compatible table similar to a mix of the omap3430 and omap3430 structure.

From: Adam Ford <[email protected]>

The AM3517 only lists 600MHz @ 1.2V, but the register values for 0x4830A204 = 1b86 802f, it seems like am3517 might be a derivative of the omap36 which OPPs would be OPP50 (300 MHz) and OPP100 (600 MHz).

This patch sets up the OPP50 and OPP100 tables at 300MHz and 600MHz for the AM3517 with each having an operating voltage at 1.2V.

CHANGES V3:
* make omap36xx control the abb-ldo and properly switch mode (suggested by Adam Ford <[email protected]>)
* add a note about enabling the turbo-mode OPPs

Am 16.09.2019 um 18:28 schrieb Tony Lindgren <[email protected]>:

Quoted 4 lines · H. Nikolaus Schaller

CHANGES V3:
* make omap36xx control the abb-ldo and properly switch mode (suggested by Adam Ford <[email protected]>)
* 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.

Am 17.09.2019 um 16:35 schrieb H. Nikolaus Schaller <[email protected]>:

Hi Tony,

Quoted 8 lines

Am 16.09.2019 um 18:28 schrieb Tony Lindgren <[email protected]>:

Quoted 4 lines · H. Nikolaus Schaller

CHANGES V3:
* make omap36xx control the abb-ldo and properly switch mode (suggested by Adam Ford <[email protected]>)
* add a note about enabling the turbo-mode OPPs

Quoted 3 lines

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

Hi Tony,

Quoted 8 lines

Am 16.09.2019 um 18:28 schrieb Tony Lindgren <[email protected]>:

Quoted 4 lines · H. Nikolaus Schaller

CHANGES V3:
* make omap36xx control the abb-ldo and properly switch mode (suggested by Adam Ford <[email protected]>)
* add a note about enabling the turbo-mode OPPs

Quoted 3 lines

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?

CHANGES V3:
* make omap36xx control the abb-ldo and properly switch mode (suggested by Adam Ford <[email protected]>)
* add a note about enabling the turbo-mode OPPs

CHANGES V3:
* make omap36xx control the abb-ldo and properly switch mode (suggested by Adam Ford <[email protected]>)
* 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 <[email protected]>
* include am3517 patches by Adam Ford <[email protected]>
* 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 <[email protected]>)
* extend commit message to describe the bit patterns needed for opp-supported-hw
* add error check to ioremap()
(suggested by Christ van Willegen <[email protected]>)
* 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 <[email protected]>)

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 <[email protected]>)
* 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(-)

--
2.19.1

Am 08.11.2019 um 21:08 schrieb Adam Ford <[email protected]>:

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.

Hi Adam,

Quoted 9 lines

Am 08.11.2019 um 21:08 schrieb Adam Ford <[email protected]>:

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:

Quoted 6 lines

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

_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel