[PATCH v14 RESEND 1/6] dt-bindings: display: imx: Add i.MX8qxp/qm DPU binding
Ying Liu
victor.liu at nxp.com
Mon Sep 4 20:44:23 PDT 2023
On Thursday, August 24, 2023 5:48 PM, Maxime Ripard <mripard at kernel.org> wrote:
> On Wed, Aug 23, 2023 at 08:47:51AM +0000, Ying Liu wrote:
> > > > This dt-binding just follows generic dt-binding rule to describe the DPU
> IP
> > > > hardware, not the software implementation. DPU internal units do not
> > > > constitute separate devices.
> > >
> > > I mean, your driver does split them into separate devices so surely it
> > > constitutes separate devices.
> >
> > My driver treats them as DPU internal units, especially not Linux devices.
> >
> > Let's avoid Linuxisms when implementing this dt-binding and just be simple
> > to describe necessary stuff exposing to DPU's embodying system/SoC, like
> > reg, interrupts, clocks and power-domains.
>
> Let's focus the conversation here, because it's redundant with the rest.
>
> Your driver registers two additional devices, that have a different
> register space, different clocks, different interrupts, different power
> domains, etc. That has nothing to do with Linux, it's hardware
> properties.
>
> That alone is a very good indication to me that these devices should be
> modeled as such. And your driver agrees.
>
> Whether or not the other internal units need to be described as separate
> devices, I can't really tell, I don't have the datasheet.
i.MX8qxp and i.MX8qm SoC reference manuals can be found at(I think
registration is needed first):
https://www.nxp.com/webapp/Download?colCode=IMX8DQXPRM
https://www.nxp.com/webapp/Download?colCode=IMX8QMRM
Sorry for putting this in a short way, but the DPU is one IP, so one dt-binding.
>
> But at least the CRTC and the interrupt controller should be split away,
> or explained and detailed far better than "well it's just convenient".
CRTC is Linuxisms, which cannot be referenced to determine dt-binding.
DPU as Display Controller is listed as a standalone module/IP in RM.
This is how the IP is designed in the first place, not for any convenient
purpose.
Regards,
Liu Ying
>
> Maxime
More information about the linux-arm-kernel
mailing list