On Mon, Jul 6, 2026 at 8:07 AM Liu Ying <[email protected]> wrote: > > On Sun, Jul 05, 2026 at 03:33:51AM +0530, Piyush Patle wrote: > > On Fri, Jun 26, 2026 at 3:22 PM Liu Ying <[email protected]> wrote: > > > > > > 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 > > > > Hi Liu, > > Hi Piyush, > > > > > A quick follow-up with some progress. > > I went ahead with the refactoring we discussed and now have it working on the > > i.MX95 15x15 FRDM, following the component-based model. > > The common implementations for ConstFrame, ExtDst, LayerBlend, FrameGen and > > the FetchUnit base have been moved into shared dc-lib-* helpers, with > > Can you please share the code in a public place, like github? >
Sure. I've pushed the current work-in-progress branch here: https://github.com/PiyushPatle26/linux-mecha-im95-wip/tree/imx95-dc-preview The files you asked about are: drivers/gpu/drm/imx/dc/dc-drv-common.c drivers/gpu/drm/imx/dc/dc-lib-*.c One thing I'd like to point out is that the pixel interleaver, display pixel link, LDB and LVDS PHY drivers are ports of the existing NXP downstream drivers. The new work in this branch is mainly the DC refactoring into the component model and the shared helper library. > > SoC-specific register layouts and tables supplied as data. The per-SoC glue is > > split into dc-drv-common.c, dc-drv-imx8qxp.c and dc-drv-imx95.c, while > > Same here, just want to see how dc-drv-common.c and dc-lib-* would look like. > The files you mentioned are available under: drivers/gpu/drm/imx/dc/dc-drv-common.c drivers/gpu/drm/imx/dc/dc-lib-*.c The helper library currently contains the common implementations for ConstFrame, ExtDst, LayerBlend, FrameGen and the FetchUnit base. > > i.MX95-specific blocks such as DomainBlend, Dither, FetchEco, FetchYUV, > > HScaler and VScaler remain separate component drivers. > > i.MX8QXP display controller also has Dither, FetchEco, HScaler and Vscaler, > so they are not i.MX95-specific blocks. To add minimal feautures at first, > we don't need to support them as of now. i.MX95-specific FetchYUV is similar > to i.MX8QXP-specific FetchDecode, so maybe FetchYUV won't be a separate > component driver at the end of the day. To start up small, I think the > must-have DomainBlend and Dither(for Data-Enable, HSync and VSync polarity > controls) and two FetchLayers can be enabled to support two display pipelines. > Okay, I've reduced the implementation accordingly. The current branch only keeps DomainBlend, Dither and two FetchLayers. FetchEco, FetchYUV, HScaler and VScaler have been dropped for now. > BTW, do you have the i.MX95 TRM? If no, then it would be difficult for you > to add DT bindings for *all* blocks. Note that the DT bindings are supposed > to be complete at the first place. > Yes, I do. > > > > The implementation is functional on the FRDM over the pipeline > > DPU -> pixel-interleaver -> pixel-link -> LDB -> LVDS PHY -> IT6263 -> HDMI > > As I said before in separate mail thread, pixel link is not used in the LVDS > display pipeline, but instead it's only used in the MIPI DSI display pipeline. > Thanks for pointing that out. After checking the TRM, I updated the DT graph so the LVDS pipeline is now: DC -> Pixel-interleaver -> LDB -> LVDS PHY -> IT6263 -> HDMI Removing display_pixel_link from the LVDS path also required moving the bridge format translation into the pixel interleaver driver. > > > > EDID is read successfully, the initial modeset works for all tested modes > > (1920x1080@60, 1280x720@60, 720x480 and 640x480), and Weston and sway both run. > > > > There are still two known limitations. The initial modeset works, but > > subsequent mode changes currently wedge the ExtDst content shadow load, which > > appears related to the lack of a reset path for the i.MX95 FrameGen. > > Not sure what's the cause of the issue, but FrameGen needs to be disabled and > then re-enabled if you want to do a full modeset. I'd say that's not a reset > path. This critical issue needs to be fixed before posting formal patches. > Understood. I'll continue investigating the modeset issue before posting the formal patch series. > > In > > addition, the DSI path is implemented on the DC side but remains unvalidated. > > It's fine to support the LVDS display pipeline first as long as it doesn't > do harm to the MIPI DSI display pipeline support. So, maybe drop the latter > first. I've done that in the current branch. It now focuses only on the validated LVDS pipeline. > > > > > The implementation is currently based on v7.2-rc1 together with your prefetch > > v5 series. > > > > The work is now ready to be posted as patch series: Adding LVDS/DSI > > i.MX95 support. > > > > > > Regards, > > Piyush Patle > > -- > Regards, > Liu Ying Thanks again for taking the time to review this. Regards, Piyush Patle
