[PATCH V3 7/7] arm64: dts: imx8mp: add interconnect for hsio blk ctrl

[Markus Niebel]

Hi Greg,

Am Freitag, dem 31.03.2023 um 15:55 +1000 schrieb Greg Ungerer:
> Hi Marco,
> 
> On 29/3/23 01:11, Marco Felsch wrote:
> > Hi Greg,
> > 
> > On 23-03-29, Greg Ungerer wrote:
> > > Hi Marco,
> > 
> > ...
> > 
> > > > 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).
> > 
> > and that's the problem :) You need to update your bootloader to a
> > version which support disabling the VPU nodes else you will always
> > see
> > the errors.
> 
> I agree this is the problem, I don't agree that the boot loader is
> the
> only place to fix this :-)  I should be able to generate a working
> devicetree
> blob from the kernel that is good, and ready to use no runtime
> changes
> required I figure.
> 

Just to point out: the approach of run time fixing in boot loader is
used for the other i.MX8M SOC, too. If you know exactly what SOC type
is assembled, you could disable non available IP in the board part of
your tree.

> It is not overly difficult to break out the vpu nodes and have them
> only included when you have a board that has the iMX8MP-quad with the
> VPU hardware blocks.
> 

Depending on the SOC type there is more to look for than the VPU: core
count, ISP, NPU - just to mention a few. Current approach allows to
keep a single tree for all types.

Regards, Markus

-- 
-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/