On Fri, 06 Jan 2023 14:36:41 +0200, Laurent Pinchart wrote:
> Hi Michael,
>
> Thank you for the patch.
>
> On Thu, Jan 05, 2023 at 02:47:29PM +0100, Michael Tretter wrote:
> > The i.MX7d contains a Pixel Pipeline in version 3.0. Add the device tree
> > node to make it available.
> >
> > Signed-off-by: Michael Tretter <m.tretter@xxxxxxxxxxxxxx>
> > ---
> > arch/arm/boot/dts/imx7d.dtsi | 9 +++++++++
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/imx7d.dtsi b/arch/arm/boot/dts/imx7d.dtsi
> > index 7ceb7c09f7ad..728cc9413a7c 100644
> > --- a/arch/arm/boot/dts/imx7d.dtsi
> > +++ b/arch/arm/boot/dts/imx7d.dtsi
> > @@ -165,6 +165,15 @@ pcie_phy: pcie-phy@306d0000 {
> > reg = <0x306d0000 0x10000>;
> > status = "disabled";
> > };
> > +
> > + pxp: pxp@30700000 {
> > + compatible = "fsl,imx7d-pxp";
>
> Hmmm... The i.MX7S also has a PXP that seems compatible. I thus wonder
> if we shouldn't move this node to imx7s.dtsi.
The i.MX7S has a PXP at the same address, but the architecture in the
reference manual (Figure 13-71. PXP Architecture, p. 3797) looks slightly
different wrt. the location of the multiplexers. The reference manual is also
conspicuously lacking documentation of the DATA_PATH_CTRL0 register.
I wouldn't risk adding the node to the imx7s.dtsi and would rather keep the
option to add a different compatible for the i.MX7S to be able to handle the
difference.
Michael
>
> > + reg = <0x30700000 0x10000>;
> > + interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 46 IRQ_TYPE_LEVEL_HIGH>;
>
> Nitpicking, alignment ?
>
> > + clocks = <&clks IMX7D_PXP_CLK>;
> > + clock-names = "axi";
> > + };
> > };
> >
> > &aips3 {
