RE: [PATCH v14 RESEND 1/6] dt-bindings: display: imx: Add i.MX8qxp/qm DPU binding

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thursday, August 24, 2023 5:48 PM, Maxime Ripard <mripard@xxxxxxxxxx> 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




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux