| Message ID | 20200709231954.1973-1-s-anna@ti.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add IPU & DSP remoteprocs on OMAP4 and OMAP5 | expand |
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
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 >
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 >> >
* 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
* 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[] = {
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
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[] = { >
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
* 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
* 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
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(-)