On 10/16/25, Marek Vasut <[email protected]> wrote: > On 10/15/25 12:00 PM, Liu Ying wrote: > > Hi,
Hi, > > >> I wanted to put this whole thing on the list first, before I start > >> splitting it > up. > >> > >> For starters, I think I can send these separately: > > > > Before discussing how to split, a bigger question is that is it fine to > > support both i.MX8qxp DC and i.MX95 DC in the same imx8_dc_drm > module? > > Separate modules look more reasonable to me, considering the fact that > > there are quite a lot difference between the two DCs. > > (maybe I do not quite understand your suggestion with "separate module", > I assume this means entirely duplicate driver, is that correct? I > operate with that assumption in the text below.) I'd expect separate modules: the existing imx8_dc_drm(which can be modprobe'd) and something like imx95_dc_drm. I wouldn't call them *entirely* duplicated drivers since I mentioned common part of the DCs could be wrapped as helpers in an additional module(something like imx_dc_drm_common). > > This series indicates that the functional units in the DC are basically > identical, with the majority of changes being register base addresses of > the whole DC and an odd bit or register offset here and there. Most of > the code can be reused, as can be seen in the first half of the series. The major differences between the i.MX95 and i.MX8qxp DCs are different components in Display Engines(especially the additional Domain Blend Unit in i.MX95 DC) plus i.MX8qxp DC's capability to connect with the prefetch engines(DPRC & PRG). Both would have significant impact on how we implement the drivers. We'll certainly end up having different implementations for callbacks to enable/disable CRTCs or update/disable planes. The sort of minor difference is in Pixel Engine(including Blit Engine) where FethUnit types and numbers are different plus different numbers of Scaler Engine. I'd expect logics to allocate FetchUnits for planes can be implemented in the imx_dc_drm_common module > > The addition of iMX95 into the iMX8QXP DC also does not seem to be > making the driver in any way more complicated. Disagree. The addition would introduce quite a few i.MX95 or i.MX8qxp DC specific code branches due to the differences mentioned above. I'd say i.MX95 DC support could be in drivers/gpu/drm/imx/dc, but it needs to be in a separate module like again imx95_dc_drm. This makes feel that the debate here becomes kind of similar to what we did for single mxsfb module vs mxsfb + imx_lcdif separate modules... > > What would be the benefit of having duplicate driver for IP that is > basically identical, for i.MX95 ? Cleaner driver implementation and easier to maintain. I don’t want to test both i.MX95 and i.MX8qxp platforms when only either i.MX95 DC specific or i.MX8qxp DC specific code is changed. But again, they won't be entirely duplicated drivers. Common part could be shared between the drivers with software techniques, like the imx_dc_drm_common module mentioned above. > > [...] > > >> - drm/imx: dc: Rename i.MX8QXP specific Link IDs > > > > TBH, I'm not a big fan of adding LINK_ID_x_MXy to enum dc_link_id, since > > the members may have the same value and it's kind of a mess considering > > future SoCs. > > I am open to a better suggestion which does not involve duplicate driver. > > >> - drm/imx: Add more RGB swizzling options > > > > This one seems ok. > > I can send that one separately. Can you test that on MX8QXP ? I don't > have a board with that SoC, sorry. I guess I can. > > [...] > > > I kind of opt to separate modules. Maybe, to save some code, an > additional > > module can be introduced to wrap common part as helpers, plus some > callback > > magics, like fg->dc_fg_cfg_videomode(). > Let me ask for clarification here -- by separate modules, do you mean > two totally separate drivers ? See above my reply. I'd expect separate modules(imx8_dc_drm and something like imx95_dc_drm) + imx_dc_drm_common module. Liu Ying
