Re: [PATCH] arm64: dts: imx8mq: Add dcss node

[Frank Li <Frank.li@oss.nxp.com>]

On Fri, Jul 10, 2026 at 09:52:10AM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [High] The `dcss` device node is missing the `power-domains = <&pgc_disp>;` property, which will cause a bus hang when the driver accesses its registers.
> - [Low] The `dcss` node is placed at the `soc` level, outside of the `aips4` bus node, causing an overlapping `reg` region and violating the hardware bus topology.
> --
>
> --- Patch [1]: [PATCH] arm64: dts: imx8mq: Add dcss node ---
> commit 014c87fe4bc51f0ac006bc4660c8f156f9a40538
> Author: Esben Haabendal <esben@geanix.com>
>
> arm64: dts: imx8mq: Add dcss node
>
> Add DCSS node for i.MX8MQ based on the example in the bindings documentation.
>
> > diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> > index e60872aeeb49e..fb99bd3ad7c92 100644
> > --- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> > @@ -1611,6 +1611,27 @@ irqsteer: interrupt-controller@32e2d000 {
> >  			};
> >  		};
> >
> > +		dcss: display-controller@32e00000 {
>
> [Severity: Low]
> The aips4 bus explicitly claims the 0x32c00000 - 0x33000000 address range:
>
> 		aips4: bus@32c00000 { /* AIPS4 */
> 			compatible = "fsl,aips-bus", "simple-bus";
> 			reg = <0x32c00000 0x400000>;
> 			ranges = <0x32c00000 0x32c00000 0x400000>;
>
> Placing the dcss node at the soc level with address 0x32e00000 creates an
> overlapping reg region and violates the hardware bus topology, which can
> cause structural devicetree warnings about overlapping ranges.
>
> Should this node be placed as a child of the aips4 bus instead?

Make sense, please move it under aips4

Frank
>
> > +			compatible = "nxp,imx8mq-dcss";
> > +			reg = <0x32e00000 0x2d000>, <0x32e2f000 0x1000>;
> > +			interrupts = <6>, <8>, <9>;
>
> [Severity: High]
> If power-domains = <&pgc_disp>; is omitted, the generic PM domain framework
> won't track the dependency between this device and the DISP domain.
>
> If no other active devices claim pgc_disp, the PM core may disable the
> domain during late_initcall.
>
> If a board enables this node and the driver subsequently tries to access the
> memory-mapped registers of the unpowered peripheral, it will trigger a
> synchronous external abort and panic the kernel.
>
> Is this node missing the power-domains property?
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260710-imx8mq-dcss-device-tree-node-v1-1-fc724dfd574e@geanix.com?part=1