Re: [PATCH 00/13] Add IPU & DSP remoteprocs on OMAP4 and OMAP5

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxx> [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






[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux