[00/13] Add IPU & DSP remoteprocs on OMAP4 and OMAP5
mbox series

Message ID 20200709231954.1973-1-s-anna@ti.com
Headers show
Series
  • Add IPU & DSP remoteprocs on OMAP4 and OMAP5
Related show

Message

Suman Anna July 9, 2020, 11:19 p.m. UTC
Hi Tony,

The following series contains all the necessary DT pieces to boot the
IPU and DSP remote processors on OMAP4 and OMAP5 SoCs. They are
enabled specifically on the TI OMAP4 PandaBoard and OMAP5 uEVM boards.
This is the last DT piece that now completes the support for IPUs and
DSPs on all OMAP4+ SoCs, similar patches were merged for 5.8 covering
the DRA7xx/AM57xx SoCs. Appreciate it if you can pick up the series for
5.9 if it isn't too late.

There is one issue that I have run into while testing this series on
the latest kernel. I am seeing a l3_noc error for OMAP4 DSP when it
attempts to auto-suspend or stop after it is booted. The issue is a
L4CFG read error that happens in the sysc_disable_module() function
in ti-sysc code.

I do not have any issues on my downstream 5.4 based SDK kernel. I have
root-caused this to the OMAP4 voltage controller patches you added for
5.5 kernel through your omap-for-v5.5/pm branch, specifically the
commit 4873843718f9 ("ARM: OMAP2+: Initialize voltage controller for omap4").
The VOLTCTRL register value is 0x300 before that patch, and modifying
this register either through  omap4_vc_init_pmic_signaling() or
omap4_vc_set_pmic_signaling() will trigger this. A debug print in
sysc_disable_module() also seems to help.

regards
Suman

Suman Anna (13):
  ARM: dts: omap4: Add timer_sys_ck clocks for timers
  ARM: dts: omap5: Add timer_sys_ck clocks for timers
  ARM: dts: omap4: Update the DSP node
  ARM: dts: omap4: Add IPU DT node
  ARM: dts: omap4: Add aliases for rproc nodes
  ARM: dts: omap4-panda-common: Add CMA pools and enable IPU & DSP
  ARM: dts: omap4-panda-common:: Add system timers to DSP and IPU
  ARM: dts: omap5: Add DSP and IPU nodes
  ARM: dts: omap5: Add aliases for rproc nodes
  ARM: dts: omap5-uevm: Add CMA pools and enable IPU & DSP
  ARM: dts: omap5-uevm: Add system timers to DSP and IPU
  ARM: dts: omap4-panda-common: Add watchdog timers for IPU and DSP
  ARM: dts: omap5-uevm: Add watchdog timers for IPU and DSP

 arch/arm/boot/dts/omap4-l4-abe.dtsi       | 20 +++++++------
 arch/arm/boot/dts/omap4-l4.dtsi           | 35 ++++++++++++++---------
 arch/arm/boot/dts/omap4-panda-common.dtsi | 34 ++++++++++++++++++++++
 arch/arm/boot/dts/omap4.dtsi              | 29 ++++++++++++++++---
 arch/arm/boot/dts/omap5-l4-abe.dtsi       | 20 +++++++------
 arch/arm/boot/dts/omap5-l4.dtsi           | 35 ++++++++++++++---------
 arch/arm/boot/dts/omap5-uevm.dts          | 34 ++++++++++++++++++++++
 arch/arm/boot/dts/omap5.dtsi              | 25 ++++++++++++++++
 8 files changed, 184 insertions(+), 48 deletions(-)

Comments

Tony Lindgren July 10, 2020, 4:58 p.m. UTC | #1
Hi,

* Suman Anna <s-anna@ti.com> [200709 16:20]:
> Hi Tony,
> 
> The following series contains all the necessary DT pieces to boot the
> IPU and DSP remote processors on OMAP4 and OMAP5 SoCs. They are
> enabled specifically on the TI OMAP4 PandaBoard and OMAP5 uEVM boards.
> This is the last DT piece that now completes the support for IPUs and
> DSPs on all OMAP4+ SoCs, similar patches were merged for 5.8 covering
> the DRA7xx/AM57xx SoCs. Appreciate it if you can pick up the series for
> 5.9 if it isn't too late.

Great and good to hear things are working with only dts changes now :)
Yes let's try to get these merged.

> There is one issue that I have run into while testing this series on
> the latest kernel. I am seeing a l3_noc error for OMAP4 DSP when it
> attempts to auto-suspend or stop after it is booted. The issue is a
> L4CFG read error that happens in the sysc_disable_module() function
> in ti-sysc code.
> 
> I do not have any issues on my downstream 5.4 based SDK kernel. I have
> root-caused this to the OMAP4 voltage controller patches you added for
> 5.5 kernel through your omap-for-v5.5/pm branch, specifically the
> commit 4873843718f9 ("ARM: OMAP2+: Initialize voltage controller for omap4").
> The VOLTCTRL register value is 0x300 before that patch, and modifying
> this register either through  omap4_vc_init_pmic_signaling() or
> omap4_vc_set_pmic_signaling() will trigger this. A debug print in
> sysc_disable_module() also seems to help.

Hmm interesting, not sure how the VOLTCTRL register affects this.

I wonder the following commit in v5.8-rc3 might help with this though:

5ce8aee81be6 ("bus: ti-sysc: Flush posted write on enable and disable")

I was seeing that occasionally with mcspi, but never had anything
reproducable.

Regards,

Tony
Suman Anna July 10, 2020, 5:17 p.m. UTC | #2
On 7/10/20 11:58 AM, Tony Lindgren wrote:
> Hi,
> 
> * Suman Anna <s-anna@ti.com> [200709 16:20]:
>> Hi Tony,
>>
>> The following series contains all the necessary DT pieces to boot the
>> IPU and DSP remote processors on OMAP4 and OMAP5 SoCs. They are
>> enabled specifically on the TI OMAP4 PandaBoard and OMAP5 uEVM boards.
>> This is the last DT piece that now completes the support for IPUs and
>> DSPs on all OMAP4+ SoCs, similar patches were merged for 5.8 covering
>> the DRA7xx/AM57xx SoCs. Appreciate it if you can pick up the series for
>> 5.9 if it isn't too late.
> 
> Great and good to hear things are working with only dts changes now :)
> Yes let's try to get these merged.

Thanks.

> 
>> There is one issue that I have run into while testing this series on
>> the latest kernel. I am seeing a l3_noc error for OMAP4 DSP when it
>> attempts to auto-suspend or stop after it is booted. The issue is a
>> L4CFG read error that happens in the sysc_disable_module() function
>> in ti-sysc code.
>>
>> I do not have any issues on my downstream 5.4 based SDK kernel. I have
>> root-caused this to the OMAP4 voltage controller patches you added for
>> 5.5 kernel through your omap-for-v5.5/pm branch, specifically the
>> commit 4873843718f9 ("ARM: OMAP2+: Initialize voltage controller for omap4").
>> The VOLTCTRL register value is 0x300 before that patch, and modifying
>> this register either through  omap4_vc_init_pmic_signaling() or
>> omap4_vc_set_pmic_signaling() will trigger this. A debug print in
>> sysc_disable_module() also seems to help.
> 
> Hmm interesting, not sure how the VOLTCTRL register affects this.
> 
> I wonder the following commit in v5.8-rc3 might help with this though:
> 
> 5ce8aee81be6 ("bus: ti-sysc: Flush posted write on enable and disable")
> 

I had already tested on v5.8-rc4 when I posted the patches, so this 
patch doesn't help. OMAP5 DSP is fine, because Think it has to do with 
this automated

So, I am looking at the TRM, and the three 
VDD_{IVA,MPU,CORE}_I2C_DISABLE bits in VOLTCTRL are marked debug-purpose 
only, so I don't think we should be setting those to begin with. Any 
reason why you want to set those? Anyway, these bits were not an issue, 
I have specifically tried that already.

regards
Suman

> I was seeing that occasionally with mcspi, but never had anything
> reproducable.
> 
> Regards,
> 
> Tony
>
Suman Anna July 10, 2020, 5:28 p.m. UTC | #3
On 7/10/20 12:17 PM, Suman Anna wrote:
> On 7/10/20 11:58 AM, Tony Lindgren wrote:
>> Hi,
>>
>> * Suman Anna <s-anna@ti.com> [200709 16:20]:
>>> Hi Tony,
>>>
>>> The following series contains all the necessary DT pieces to boot the
>>> IPU and DSP remote processors on OMAP4 and OMAP5 SoCs. They are
>>> enabled specifically on the TI OMAP4 PandaBoard and OMAP5 uEVM boards.
>>> This is the last DT piece that now completes the support for IPUs and
>>> DSPs on all OMAP4+ SoCs, similar patches were merged for 5.8 covering
>>> the DRA7xx/AM57xx SoCs. Appreciate it if you can pick up the series for
>>> 5.9 if it isn't too late.
>>
>> Great and good to hear things are working with only dts changes now :)
>> Yes let's try to get these merged.
> 
> Thanks.
> 
>>
>>> There is one issue that I have run into while testing this series on
>>> the latest kernel. I am seeing a l3_noc error for OMAP4 DSP when it
>>> attempts to auto-suspend or stop after it is booted. The issue is a
>>> L4CFG read error that happens in the sysc_disable_module() function
>>> in ti-sysc code.
>>>
>>> I do not have any issues on my downstream 5.4 based SDK kernel. I have
>>> root-caused this to the OMAP4 voltage controller patches you added for
>>> 5.5 kernel through your omap-for-v5.5/pm branch, specifically the
>>> commit 4873843718f9 ("ARM: OMAP2+: Initialize voltage controller for 
>>> omap4").
>>> The VOLTCTRL register value is 0x300 before that patch, and modifying
>>> this register either through  omap4_vc_init_pmic_signaling() or
>>> omap4_vc_set_pmic_signaling() will trigger this. A debug print in
>>> sysc_disable_module() also seems to help.
>>
>> Hmm interesting, not sure how the VOLTCTRL register affects this.
>>
>> I wonder the following commit in v5.8-rc3 might help with this though:
>>
>> 5ce8aee81be6 ("bus: ti-sysc: Flush posted write on enable and disable")
>>
> 
> I had already tested on v5.8-rc4 when I posted the patches, so this 
> patch doesn't help. OMAP5 DSP is fine, because Think it has to do with 
> this automated
> 
> So, I am looking at the TRM, and the three 
> VDD_{IVA,MPU,CORE}_I2C_DISABLE bits in VOLTCTRL are marked debug-purpose 
> only, so I don't think we should be setting those to begin with. Any 
> reason why you want to set those? Anyway, these bits were not an issue, 
> I have specifically tried that already.

FYI, the following one-line removal is enough for me to not see the error.

diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
index 86f1ac4c2412..b80c9dff81c4 100644
--- a/arch/arm/mach-omap2/vc.c
+++ b/arch/arm/mach-omap2/vc.c
@@ -44,7 +44,6 @@
  #define OMAP4_VDD_DEFAULT_VAL  \
         (OMAP4430_VDD_I2C_DISABLE_MASK | \
          OMAP4430_VDD_IVA_PRESENCE | OMAP4430_VDD_MPU_PRESENCE | \
-        OMAP4430_AUTO_CTRL_VDD_IVA(OMAP4430_AUTO_CTRL_VDD_RET) | \
          OMAP4430_AUTO_CTRL_VDD_MPU(OMAP4430_AUTO_CTRL_VDD_RET) | \
          OMAP4430_AUTO_CTRL_VDD_CORE(OMAP4430_AUTO_CTRL_VDD_RET))

regards
Suman

> 
>> I was seeing that occasionally with mcspi, but never had anything
>> reproducable.
>>
>> Regards,
>>
>> Tony
>>
>
Tony Lindgren July 10, 2020, 5:40 p.m. UTC | #4
* Suman Anna <s-anna@ti.com> [200710 17:18]:
> On 7/10/20 11:58 AM, Tony Lindgren wrote:
> > I wonder the following commit in v5.8-rc3 might help with this though:
> > 
> > 5ce8aee81be6 ("bus: ti-sysc: Flush posted write on enable and disable")
> > 
> 
> I had already tested on v5.8-rc4 when I posted the patches, so this patch
> doesn't help. OMAP5 DSP is fine, because Think it has to do with this
> automated

OK

> So, I am looking at the TRM, and the three VDD_{IVA,MPU,CORE}_I2C_DISABLE
> bits in VOLTCTRL are marked debug-purpose only, so I don't think we should
> be setting those to begin with. Any reason why you want to set those?
> Anyway, these bits were not an issue, I have specifically tried that
> already.

I'm pretty sure that's how the old TI PM branch was initializing them to
disable voltctrl I2C use on init. But if these are not the issue I guess
no need to mess with them.

Could it be that we have wrong voltage tables for 4460 in the mainline
kernel? See earlier commit 32236a84906f ("ARM: OMAP2+: Update 4430
voltage controller operating points").

Regards,

Tony
Tony Lindgren July 10, 2020, 5:59 p.m. UTC | #5
* Suman Anna <s-anna@ti.com> [200710 17:29]:
> FYI, the following one-line removal is enough for me to not see the error.
> 
> diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
> index 86f1ac4c2412..b80c9dff81c4 100644
> --- a/arch/arm/mach-omap2/vc.c
> +++ b/arch/arm/mach-omap2/vc.c
> @@ -44,7 +44,6 @@
>  #define OMAP4_VDD_DEFAULT_VAL  \
>         (OMAP4430_VDD_I2C_DISABLE_MASK | \
>          OMAP4430_VDD_IVA_PRESENCE | OMAP4430_VDD_MPU_PRESENCE | \
> -        OMAP4430_AUTO_CTRL_VDD_IVA(OMAP4430_AUTO_CTRL_VDD_RET) | \
>          OMAP4430_AUTO_CTRL_VDD_MPU(OMAP4430_AUTO_CTRL_VDD_RET) | \
>          OMAP4430_AUTO_CTRL_VDD_CORE(OMAP4430_AUTO_CTRL_VDD_RET))
> 

OK.

Below is an untested attempt to sync the 4460 opp values with
what earlier TI kernels had. Not sure if this help, might be worth
testing :) My pandaboard-es seems to have a corrupt sdio card.

Regards,

Tony

8< ---------------------
diff --git a/arch/arm/mach-omap2/opp4xxx_data.c b/arch/arm/mach-omap2/opp4xxx_data.c
--- a/arch/arm/mach-omap2/opp4xxx_data.c
+++ b/arch/arm/mach-omap2/opp4xxx_data.c
@@ -66,21 +66,23 @@ struct omap_volt_data omap443x_vdd_core_volt_data[] = {
 };
 
 #define OMAP4460_VDD_MPU_OPP50_UV		1025000
-#define OMAP4460_VDD_MPU_OPP100_UV		1200000
-#define OMAP4460_VDD_MPU_OPPTURBO_UV		1313000
-#define OMAP4460_VDD_MPU_OPPNITRO_UV		1375000
+#define OMAP4460_VDD_MPU_OPP100_UV		1203000
+#define OMAP4460_VDD_MPU_OPPTURBO_UV		1317000
+#define OMAP4460_VDD_MPU_OPPNITRO_UV		1380000
+#define OMAP4460_VDD_MPU_OPPNITROSB_UV		1390000
 
 struct omap_volt_data omap446x_vdd_mpu_volt_data[] = {
 	VOLT_DATA_DEFINE(OMAP4460_VDD_MPU_OPP50_UV, OMAP44XX_CONTROL_FUSE_MPU_OPP50, 0xf4, 0x0c),
 	VOLT_DATA_DEFINE(OMAP4460_VDD_MPU_OPP100_UV, OMAP44XX_CONTROL_FUSE_MPU_OPP100, 0xf9, 0x16),
 	VOLT_DATA_DEFINE(OMAP4460_VDD_MPU_OPPTURBO_UV, OMAP44XX_CONTROL_FUSE_MPU_OPPTURBO, 0xfa, 0x23),
 	VOLT_DATA_DEFINE(OMAP4460_VDD_MPU_OPPNITRO_UV, OMAP44XX_CONTROL_FUSE_MPU_OPPNITRO, 0xfa, 0x27),
+	VOLT_DATA_DEFINE(OMAP4460_VDD_MPU_OPPNITROSB_UV, OMAP44XX_CONTROL_FUSE_MPU_OPPNITROSB, 0xfa, 0x27),
 	VOLT_DATA_DEFINE(0, 0, 0, 0),
 };
 
-#define OMAP4460_VDD_IVA_OPP50_UV		1025000
-#define OMAP4460_VDD_IVA_OPP100_UV		1200000
-#define OMAP4460_VDD_IVA_OPPTURBO_UV		1313000
+#define OMAP4460_VDD_IVA_OPP50_UV		 950000
+#define OMAP4460_VDD_IVA_OPP100_UV		1140000
+#define OMAP4460_VDD_IVA_OPPTURBO_UV		1291000
 #define OMAP4460_VDD_IVA_OPPNITRO_UV		1375000
 
 struct omap_volt_data omap446x_vdd_iva_volt_data[] = {
@@ -91,8 +93,8 @@ struct omap_volt_data omap446x_vdd_iva_volt_data[] = {
 	VOLT_DATA_DEFINE(0, 0, 0, 0),
 };
 
-#define OMAP4460_VDD_CORE_OPP50_UV		1025000
-#define OMAP4460_VDD_CORE_OPP100_UV		1200000
+#define OMAP4460_VDD_CORE_OPP50_UV		 962000
+#define OMAP4460_VDD_CORE_OPP100_UV		1127000
 #define OMAP4460_VDD_CORE_OPP100_OV_UV		1250000
 
 struct omap_volt_data omap446x_vdd_core_volt_data[] = {
Suman Anna July 10, 2020, 6:24 p.m. UTC | #6
On 7/10/20 12:40 PM, Tony Lindgren wrote:
> * Suman Anna <s-anna@ti.com> [200710 17:18]:
>> On 7/10/20 11:58 AM, Tony Lindgren wrote:
>>> I wonder the following commit in v5.8-rc3 might help with this though:
>>>
>>> 5ce8aee81be6 ("bus: ti-sysc: Flush posted write on enable and disable")
>>>
>>
>> I had already tested on v5.8-rc4 when I posted the patches, so this patch
>> doesn't help. OMAP5 DSP is fine, because Think it has to do with this
>> automated
> 
> OK
> 
>> So, I am looking at the TRM, and the three VDD_{IVA,MPU,CORE}_I2C_DISABLE
>> bits in VOLTCTRL are marked debug-purpose only, so I don't think we should
>> be setting those to begin with. Any reason why you want to set those?
>> Anyway, these bits were not an issue, I have specifically tried that
>> already.
> 
> I'm pretty sure that's how the old TI PM branch was initializing them to
> disable voltctrl I2C use on init. But if these are not the issue I guess
> no need to mess with them.

OK.

> 
> Could it be that we have wrong voltage tables for 4460 in the mainline
> kernel? See earlier commit 32236a84906f ("ARM: OMAP2+: Update 4430
> voltage controller operating points").

I am running on Pandaboard, so it's a OMAP4430 ES2.2. Tried with the 
older values reverting the above commit, didn't make any difference. So, 
the only trigger point so far seems to be the automatic IVA voltage 
domain transition. Looks to be a timing related issue given that a debug 
trace also helped, wondering if it goes through a quick RET->ON->RET 
sequence from the time I disable the MMUs (child device) to the actual 
module disabling in sysc_module_disable() on the parent target-module 
device.

regards
Suman
Suman Anna July 10, 2020, 6:29 p.m. UTC | #7
On 7/10/20 12:59 PM, Tony Lindgren wrote:
> * Suman Anna <s-anna@ti.com> [200710 17:29]:
>> FYI, the following one-line removal is enough for me to not see the error.
>>
>> diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
>> index 86f1ac4c2412..b80c9dff81c4 100644
>> --- a/arch/arm/mach-omap2/vc.c
>> +++ b/arch/arm/mach-omap2/vc.c
>> @@ -44,7 +44,6 @@
>>   #define OMAP4_VDD_DEFAULT_VAL  \
>>          (OMAP4430_VDD_I2C_DISABLE_MASK | \
>>           OMAP4430_VDD_IVA_PRESENCE | OMAP4430_VDD_MPU_PRESENCE | \
>> -        OMAP4430_AUTO_CTRL_VDD_IVA(OMAP4430_AUTO_CTRL_VDD_RET) | \
>>           OMAP4430_AUTO_CTRL_VDD_MPU(OMAP4430_AUTO_CTRL_VDD_RET) | \
>>           OMAP4430_AUTO_CTRL_VDD_CORE(OMAP4430_AUTO_CTRL_VDD_RET))
>>
> 
> OK.
> 
> Below is an untested attempt to sync the 4460 opp values with
> what earlier TI kernels had. Not sure if this help, might be worth
> testing :) My pandaboard-es seems to have a corrupt sdio card.

Yeah, mine is the regular pandaboard with 4430, so the below patch will 
not make any difference.

regards
Suman

> 
> Regards,
> 
> Tony
> 
> 8< ---------------------
> diff --git a/arch/arm/mach-omap2/opp4xxx_data.c b/arch/arm/mach-omap2/opp4xxx_data.c
> --- a/arch/arm/mach-omap2/opp4xxx_data.c
> +++ b/arch/arm/mach-omap2/opp4xxx_data.c
> @@ -66,21 +66,23 @@ struct omap_volt_data omap443x_vdd_core_volt_data[] = {
>   };
>   
>   #define OMAP4460_VDD_MPU_OPP50_UV		1025000
> -#define OMAP4460_VDD_MPU_OPP100_UV		1200000
> -#define OMAP4460_VDD_MPU_OPPTURBO_UV		1313000
> -#define OMAP4460_VDD_MPU_OPPNITRO_UV		1375000
> +#define OMAP4460_VDD_MPU_OPP100_UV		1203000
> +#define OMAP4460_VDD_MPU_OPPTURBO_UV		1317000
> +#define OMAP4460_VDD_MPU_OPPNITRO_UV		1380000
> +#define OMAP4460_VDD_MPU_OPPNITROSB_UV		1390000
>   
>   struct omap_volt_data omap446x_vdd_mpu_volt_data[] = {
>   	VOLT_DATA_DEFINE(OMAP4460_VDD_MPU_OPP50_UV, OMAP44XX_CONTROL_FUSE_MPU_OPP50, 0xf4, 0x0c),
>   	VOLT_DATA_DEFINE(OMAP4460_VDD_MPU_OPP100_UV, OMAP44XX_CONTROL_FUSE_MPU_OPP100, 0xf9, 0x16),
>   	VOLT_DATA_DEFINE(OMAP4460_VDD_MPU_OPPTURBO_UV, OMAP44XX_CONTROL_FUSE_MPU_OPPTURBO, 0xfa, 0x23),
>   	VOLT_DATA_DEFINE(OMAP4460_VDD_MPU_OPPNITRO_UV, OMAP44XX_CONTROL_FUSE_MPU_OPPNITRO, 0xfa, 0x27),
> +	VOLT_DATA_DEFINE(OMAP4460_VDD_MPU_OPPNITROSB_UV, OMAP44XX_CONTROL_FUSE_MPU_OPPNITROSB, 0xfa, 0x27),
>   	VOLT_DATA_DEFINE(0, 0, 0, 0),
>   };
>   
> -#define OMAP4460_VDD_IVA_OPP50_UV		1025000
> -#define OMAP4460_VDD_IVA_OPP100_UV		1200000
> -#define OMAP4460_VDD_IVA_OPPTURBO_UV		1313000
> +#define OMAP4460_VDD_IVA_OPP50_UV		 950000
> +#define OMAP4460_VDD_IVA_OPP100_UV		1140000
> +#define OMAP4460_VDD_IVA_OPPTURBO_UV		1291000
>   #define OMAP4460_VDD_IVA_OPPNITRO_UV		1375000
>   
>   struct omap_volt_data omap446x_vdd_iva_volt_data[] = {
> @@ -91,8 +93,8 @@ struct omap_volt_data omap446x_vdd_iva_volt_data[] = {
>   	VOLT_DATA_DEFINE(0, 0, 0, 0),
>   };
>   
> -#define OMAP4460_VDD_CORE_OPP50_UV		1025000
> -#define OMAP4460_VDD_CORE_OPP100_UV		1200000
> +#define OMAP4460_VDD_CORE_OPP50_UV		 962000
> +#define OMAP4460_VDD_CORE_OPP100_UV		1127000
>   #define OMAP4460_VDD_CORE_OPP100_OV_UV		1250000
>   
>   struct omap_volt_data omap446x_vdd_core_volt_data[] = {
>
Suman Anna July 10, 2020, 8:45 p.m. UTC | #8
On 7/10/20 1:29 PM, Suman Anna wrote:
> On 7/10/20 12:59 PM, Tony Lindgren wrote:
>> * Suman Anna <s-anna@ti.com> [200710 17:29]:
>>> FYI, the following one-line removal is enough for me to not see the 
>>> error.
>>>
>>> diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
>>> index 86f1ac4c2412..b80c9dff81c4 100644
>>> --- a/arch/arm/mach-omap2/vc.c
>>> +++ b/arch/arm/mach-omap2/vc.c
>>> @@ -44,7 +44,6 @@
>>>   #define OMAP4_VDD_DEFAULT_VAL  \
>>>          (OMAP4430_VDD_I2C_DISABLE_MASK | \
>>>           OMAP4430_VDD_IVA_PRESENCE | OMAP4430_VDD_MPU_PRESENCE | \
>>> -        OMAP4430_AUTO_CTRL_VDD_IVA(OMAP4430_AUTO_CTRL_VDD_RET) | \
>>>           OMAP4430_AUTO_CTRL_VDD_MPU(OMAP4430_AUTO_CTRL_VDD_RET) | \
>>>           OMAP4430_AUTO_CTRL_VDD_CORE(OMAP4430_AUTO_CTRL_VDD_RET))
>>>
>>
>> OK.
>>
>> Below is an untested attempt to sync the 4460 opp values with
>> what earlier TI kernels had. Not sure if this help, might be worth
>> testing :) My pandaboard-es seems to have a corrupt sdio card.
> 
> Yeah, mine is the regular pandaboard with 4430, so the below patch will 
> not make any difference.
> 
> regards
> Suman
> 
>>
>> Regards,
>>
>> Tony
>>
>> 8< ---------------------
>> diff --git a/arch/arm/mach-omap2/opp4xxx_data.c 
>> b/arch/arm/mach-omap2/opp4xxx_data.c
>> --- a/arch/arm/mach-omap2/opp4xxx_data.c
>> +++ b/arch/arm/mach-omap2/opp4xxx_data.c
>> @@ -66,21 +66,23 @@ struct omap_volt_data 
>> omap443x_vdd_core_volt_data[] = {
>>   };
>>   #define OMAP4460_VDD_MPU_OPP50_UV        1025000
>> -#define OMAP4460_VDD_MPU_OPP100_UV        1200000
>> -#define OMAP4460_VDD_MPU_OPPTURBO_UV        1313000
>> -#define OMAP4460_VDD_MPU_OPPNITRO_UV        1375000
>> +#define OMAP4460_VDD_MPU_OPP100_UV        1203000
>> +#define OMAP4460_VDD_MPU_OPPTURBO_UV        1317000
>> +#define OMAP4460_VDD_MPU_OPPNITRO_UV        1380000
>> +#define OMAP4460_VDD_MPU_OPPNITROSB_UV        1390000

I am not sure about this, I see it as 1380 for both OPPNITRO and OPPNITROSB.

>>   struct omap_volt_data omap446x_vdd_mpu_volt_data[] = {
>>       VOLT_DATA_DEFINE(OMAP4460_VDD_MPU_OPP50_UV, 
>> OMAP44XX_CONTROL_FUSE_MPU_OPP50, 0xf4, 0x0c),
>>       VOLT_DATA_DEFINE(OMAP4460_VDD_MPU_OPP100_UV, 
>> OMAP44XX_CONTROL_FUSE_MPU_OPP100, 0xf9, 0x16),
>>       VOLT_DATA_DEFINE(OMAP4460_VDD_MPU_OPPTURBO_UV, 
>> OMAP44XX_CONTROL_FUSE_MPU_OPPTURBO, 0xfa, 0x23),
>>       VOLT_DATA_DEFINE(OMAP4460_VDD_MPU_OPPNITRO_UV, 
>> OMAP44XX_CONTROL_FUSE_MPU_OPPNITRO, 0xfa, 0x27),
>> +    VOLT_DATA_DEFINE(OMAP4460_VDD_MPU_OPPNITROSB_UV, 
>> OMAP44XX_CONTROL_FUSE_MPU_OPPNITROSB, 0xfa, 0x27),
>>       VOLT_DATA_DEFINE(0, 0, 0, 0),
>>   };
>> -#define OMAP4460_VDD_IVA_OPP50_UV        1025000
>> -#define OMAP4460_VDD_IVA_OPP100_UV        1200000
>> -#define OMAP4460_VDD_IVA_OPPTURBO_UV        1313000
>> +#define OMAP4460_VDD_IVA_OPP50_UV         950000
>> +#define OMAP4460_VDD_IVA_OPP100_UV        1140000

Btw, this should be 1114000

>> +#define OMAP4460_VDD_IVA_OPPTURBO_UV        1291000
>>   #define OMAP4460_VDD_IVA_OPPNITRO_UV        1375000
>>   struct omap_volt_data omap446x_vdd_iva_volt_data[] = {
>> @@ -91,8 +93,8 @@ struct omap_volt_data omap446x_vdd_iva_volt_data[] = {
>>       VOLT_DATA_DEFINE(0, 0, 0, 0),
>>   };
>> -#define OMAP4460_VDD_CORE_OPP50_UV        1025000
>> -#define OMAP4460_VDD_CORE_OPP100_UV        1200000
>> +#define OMAP4460_VDD_CORE_OPP50_UV         962000
>> +#define OMAP4460_VDD_CORE_OPP100_UV        1127000
>>   #define OMAP4460_VDD_CORE_OPP100_OV_UV        1250000
>>   struct omap_volt_data omap446x_vdd_core_volt_data[] = {
>>
> 

Atleast this update and the previous OMAP4430 patch matches up to what I 
can see from the Data Manual. So, guess you can add an official version 
of this patch.

regards
Suman
Tony Lindgren July 10, 2020, 10:08 p.m. UTC | #9
* Suman Anna <s-anna@ti.com> [200710 20:46]:
> On 7/10/20 1:29 PM, Suman Anna wrote:
> > On 7/10/20 12:59 PM, Tony Lindgren wrote:
> > > +#define OMAP4460_VDD_MPU_OPPNITROSB_UV        1390000
> 
> I am not sure about this, I see it as 1380 for both OPPNITRO and OPPNITROSB.

OK I'll drop that one.

> > > +#define OMAP4460_VDD_IVA_OPP100_UV        1140000
> 
> Btw, this should be 1114000

OK thanks for catching it.

> > > +#define OMAP4460_VDD_IVA_OPPTURBO_UV        1291000
> > >   #define OMAP4460_VDD_IVA_OPPNITRO_UV        1375000
> > >   struct omap_volt_data omap446x_vdd_iva_volt_data[] = {
> > > @@ -91,8 +93,8 @@ struct omap_volt_data omap446x_vdd_iva_volt_data[] = {
> > >       VOLT_DATA_DEFINE(0, 0, 0, 0),
> > >   };
> > > -#define OMAP4460_VDD_CORE_OPP50_UV        1025000
> > > -#define OMAP4460_VDD_CORE_OPP100_UV        1200000
> > > +#define OMAP4460_VDD_CORE_OPP50_UV         962000
> > > +#define OMAP4460_VDD_CORE_OPP100_UV        1127000
> > >   #define OMAP4460_VDD_CORE_OPP100_OV_UV        1250000
> > >   struct omap_volt_data omap446x_vdd_core_volt_data[] = {
> > > 
> > 
> 
> Atleast this update and the previous OMAP4430 patch matches up to what I can
> see from the Data Manual. So, guess you can add an official version of this
> patch.

OK thanks for checking. I'll post an updated patch with a proper
description.

Regards,

Tony
Tony Lindgren July 13, 2020, 6:24 p.m. UTC | #10
* Suman Anna <s-anna@ti.com> [200709 16:20]:
> Hi Tony,
> 
> The following series contains all the necessary DT pieces to boot the
> IPU and DSP remote processors on OMAP4 and OMAP5 SoCs. They are
> enabled specifically on the TI OMAP4 PandaBoard and OMAP5 uEVM boards.
> This is the last DT piece that now completes the support for IPUs and
> DSPs on all OMAP4+ SoCs, similar patches were merged for 5.8 covering
> the DRA7xx/AM57xx SoCs. Appreciate it if you can pick up the series for
> 5.9 if it isn't too late.

Applying the series into omap-for-v5.9/dt thanks.

Regards,

Tony