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
