On Wed, Jun 24, 2026 at 03:33:18PM +0530, Piyush Patle wrote: [...]
> The current dc/ implementation is a multi-device component driver with one > platform_driver per block bound via the component framework. The downstream > i.MX95 driver is a single monolithic platform_driver mapping all blocks from > one register base. Unifying appears to require reconciling two bind models, > rather than only adding match_data. I think that upstream i.MX95 display controller driver would also be based on the component helper. That's something for sure. [...] > There is also anticipated divergence which is not yet upstream (i.MX8QXP > prefetch/PRG, LTS and tiling modifiers, and the downstream i.MX95 blit > engine), although mainline dc/ is KMS-only today. Just want to point out that I sent out v5 patch set[2] to add i.MX8QXP prefetch engine(DPRC + PRG) support for KMS. That changes the driver's mode setting code a lot. [2] https://lore.kernel.org/all/[email protected]/ [...] > One question for Liu Ying is whether the separate-driver plus shared > helper-library approach is still the preferred direction, and where the > helper boundary would be drawn (which blocks/ops are shared versus > implemented per driver). Yes, separate DRM drivers + a helper library approach is still the direction I want. I think that the drivers and library would sit in the same directory drivers/gpu/drm/imx/dc/. The purpose to add a library is to share code to reduce overall code lines. I'd assume that shared blocks or common part of slightly different blocks should be covered by the library. [...] > how the component and monolithic driver models > would be reconciled given the differences described above. Like I said above, I don't think upstream driver would be monolithic. -- Regards, Liu Ying
