[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230328135100.rbmnfelphe7juhxo@pengutronix.de>
Date: Tue, 28 Mar 2023 15:51:00 +0200
From: Marco Felsch <m.felsch@...gutronix.de>
To: Greg Ungerer <gerg@...ux-m68k.org>
Cc: peng.fan@....com,
Alexander Stein <alexander.stein@...tq-group.com>,
abailon@...libre.com, krzysztof.kozlowski+dt@...aro.org,
festevam@...il.com, abelvesa@...nel.org, marex@...x.de,
Markus.Niebel@...tq-group.com,
Ahmad Fatoum <a.fatoum@...gutronix.de>,
paul.elder@...asonboard.com, gerg@...nel.org, linux-imx@....com,
devicetree@...r.kernel.org,
"Peng Fan (OSS)" <peng.fan@....nxp.com>, linux-pm@...r.kernel.org,
s.hauer@...gutronix.de, robh+dt@...nel.org, aford173@...il.com,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
laurent.pinchart@...asonboard.com, linux-kernel@...r.kernel.org,
kernel@...gutronix.de, djakov@...nel.org, shawnguo@...nel.org,
l.stach@...gutronix.de
Subject: Re: [PATCH V3 7/7] arm64: dts: imx8mp: add interconnect for hsio blk
ctrl
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@...30000 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
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
Regards,
Marco
Powered by blists - more mailing lists