Re: [PATCH] arm64: dts: freescale: imx8mq: Disable noc dts node
From: Martin Kepplinger
Date: Tue Nov 23 2021 - 04:30:13 EST
Am Dienstag, dem 23.11.2021 um 17:24 +0800 schrieb Shawn Guo:
> On Tue, Nov 23, 2021 at 09:15:57AM +0000, Martin Kepplinger wrote:
> > Am Dienstag, dem 23.11.2021 um 16:58 +0800 schrieb Shawn Guo:
> > > On Thu, Nov 11, 2021 at 01:16:09PM +0200, Abel Vesa wrote:
> > > > Adding interconnect properties to the consumer nodes creates
> > > > a dependency on noc device. The imx-bus devfreq driver is not
> > > > usable
> > > > without the full interconnect support. The interconnect is not
> > > > yet
> > > > working on i.MX platforms. The devlink created on device_add
> > > > makes
> > > > the lcdif and other nodes that have the interconnect properties
> > > > wait for the noc (imx-bus driver) to probe first.
> > > >
> > > > To make sure the interconnect consumers (nodes that have
> > > > interconnect
> > > > properties already added) will still probe, lets disable the
> > > > noc
> > > > node
> > > > for now. Once the interconnect on i.MX platforms is fully
> > > > functional,
> > > > the status of the noc node can be changed.
> > > >
> > > > Fixes: ad1abc8a03fdbc05b ("arm64: dts: imx8mq: Add interconnect
> > > > for
> > > > lcdif")
> > >
> > > Martin,
> > >
> > > Do you have any comment? So your commit added something
> > > untested?
> > >
> > > Shawn
> > hi Shawn,
> > well, for imx8mq the only missing piece is the mxsfb icc bandwidth
> > request. I posted a first version a year ago but that didn't make
> > it
> > in:
> > https://lore.kernel.org/linux-arm-kernel/20201201103757.32165-1-martin.kepplinger@xxxxxxx/
> > So this should create a working state until the real fix in mxsfb
> > is
> > there (although I'd revert commit ad1abc8a03fd ("arm64: dts:
> > imx8mq:
> > Add interconnect for lcdif") instead).
> Besides lcdif, the mipi-csi devices have interconnects property too.
> they already working? If so, it makes more sense to revert
imx8mq-mipi-csi.c request the bandwidth, yes. we use that and the
preliminary mxsfb request above so that works.
do you want me to send the revert?
> > I am indeed to blame for this
> > and I'm sorry I haven't yet taken the time to work on mxsfb again.
> > I can say I plan to do so soon, but without promise that I quickly
> > find
> > a solution that'll be merged...
> > If you merge this (or revert ad1abc8a03fd), I'll remember to revert
> > with said update.