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.
regards
Suman
I was seeing that occasionally with mcspi, but never had anything
reproducable.
Regards,
Tony
