Hi Marco,
On 28/3/23 23:51, Marco Felsch wrote:
On 23-03-28, Marco Felsch wrote:
Hi Greg,
On 23-03-28, Greg Ungerer wrote:
Hi Marco,
On 28/3/23 17:33, Marco Felsch wrote:
Hi Greg,
On 23-03-27, Greg Ungerer wrote:
Hi Ahmad,
On 27/3/23 17:16, Ahmad Fatoum wrote:
On 27.03.23 08:27, Alexander Stein wrote:
Am Montag, 27. März 2023, 06:50:37 CEST schrieb Greg Ungerer:
Any thoughts on why this breaks USB?
Maybe you are missing CONFIG_INTERCONNECT_IMX8MP?
And if that's the case, did you check /sys/kernel/debug/devices_deferred
to see if there was any indication that this is the reason?
Yeah, it does:
# cat /sys/kernel/debug/devices_deferred
32f10100.usb platform: supplier 32f10000.blk-ctrl not ready
32f10108.usb platform: supplier 32f10000.blk-ctrl not ready
32ec0000.blk-ctrl imx8m-blk-ctrl: failed to get noc entries
381f0040.usb-phy platform: supplier 32f10000.blk-ctrl not ready
382f0040.usb-phy platform: supplier 32f10000.blk-ctrl not ready
imx-pgc-domain.11
imx-pgc-domain.12
imx-pgc-domain.13
38330000.blk-ctrl platform: supplier imx-pgc-domain.11 not ready
32f10000.blk-ctrl imx8mp-blk-ctrl: failed to get noc entries
As far as I can tell blk-ctrl should be good:
#
# i.MX SoC drivers
#
CONFIG_IMX_GPCV2_PM_DOMAINS=y
CONFIG_SOC_IMX8M=y
# CONFIG_SOC_IMX9 is not set
CONFIG_IMX8M_BLK_CTRL=y
# end of i.MX SoC drivers
If you didn't find any hint there, you might want to place a
dev_err_probe with a suitable message at the place where -EPROBE_DEFER
was returned.
I will try that.
Can you check that CONFIG_ARM_IMX_BUS_DEVFREQ is enabled? This is the
noc/interconnect driver. This could also the problem for you vpu issue.
I do not have that enabled. Enabling that fixes the USB probing.
So that is good, thanks.
It doesn't fix the other problem I mentioned with the vpu pgc nodes though.
I do get some extra messages now with this enabled and the 6.1 kernel:
imx-pgc imx-pgc-domain.8: failed to command PGC
imx-pgc imx-pgc-domain.8: failed to command PGC
imx8m-blk-ctrl 38330000.blk-ctrl: deferred probe timeout, ignoring dependency
imx8m-blk-ctrl 38330000.blk-ctrl: error -110: failed to attach power domain "g1"
imx8m-blk-ctrl: probe of 38330000.blk-ctrl failed with error -110
Okay, this seems more like a "real" issue not related to some missing
drivers. I followed the code and found a poll within the
imx_pgc_power_up() in gpcv2.c. Power-domain 8 is the vpumix domain which
is used as power-domain for the g1 power-domain. My assumption is that
this poll does run into the timeout. Maybe Peng can support you here
since I didn't had the time for to test the VPUs yet and he did the
integration patches.
Just ignore the errors if you don't use the VPUs or disable the
blk-ctrl@38330000 node via status = "disabled".
I forgot to ask: Does your i.MX8MP have a VPU? There are i.MX8MP devices
(don't know the name) which don't have support for certain IPs. If this
The hardware platform I have is using the MIMX8ML4CVNKZAB "i.MX 8M Plus QuadLite"
(https://www.nxp.com/part/MIMX8ML4CVNKZAB#/) which does not have the hardware
video encode/decoder module (like the "i.MX 8M Plus Quad" parts).
is the case the bootloader will fixup your devicetree by disable the
corresponding nodes, we call this feature-controller:
https://elixir.bootlin.com/barebox/latest/source/arch/arm/dts/imx8mp.dtsi
As you can see the imx8mp.dtsi is missing the feature bits for the VPU
but you can check the i.mx8mm.dtsi. Here you can see that barebox will
check the availability of the vpu:
https://elixir.bootlin.com/barebox/latest/source/arch/arm/dts/imx8mm.dtsi
Ok, thanks, I'll take a look.
Regards
Greg
