On 6/8/26 9:48 AM, Liu Ying wrote:
Hello everyone,
I brought this series up on the i.MX95 15x15 FRDM (IT6263 LVDS-to-HDMI on
LVDS ch1). It mostly works, but I ran into a few issues around DI routing,
LVDS format handling, and DC enable sequencing which needed rework before
HDMI would come up reliably on the board.
I don't see a v2 of the series and things seem to have been quiet since
November. Are you planning to post an updated version?
My plan was to enable prefetch engine support[1] for i.MX8QXP display
controller and add device tree for a whole i.MX8QXP LVDS display pipeline,
before adding i.MX95 display controller support.
Unfortunately, it seems that Marek is not a big fan of [1]
I am fine with [1] as long as it can be isolated and does not affect
every SoC that might reuse this driver, which I think it can be done.
and I'm busy
with downstream development so the plan doesn't move forward well. I still
think [1] makes sense(maybe I need to rebase it on latest drm-misc-next),
so I'd like to see review comments on [1] and hopefully people think that
the overall idea of [1] is ok.
My only concern is, to keep it isolated to MX8Q, so this driver can be
reused by MX95.
I've accumulated a fair amount of rework while getting this running on the
FRDM. If you're not planning a v2, I can clean things up and send one based
on the current series.
I still think that i.MX95 display controller driver should be in a separate
driver, rather than sharing the same driver with i.MX8QXP display controller
like this patch series does, because the two display controllers are quite
different as I mentioned in comments on this patch series and in discussion
in [1]. Also, the common part between the two display controllers should
be extracted to a common helper library as I mentioned there too.
Are they really? It seems this series adds support for the MX95 DC
without that many changes, so are the DCs really that different ? It
seems the MX95 DC is simply a reuse/evolution of the MX8Q DC blocks, so
duplicating the code seems like the wrong direction, it will only lead
to disparate sets of bugs in two drivers, which isn't desired.
(I might not fully understand what you have in mind with the helper
library though?)
