[PATCH 0/8] Add imx8mp video support

[Michael Nazzareno Trimarchi]

Hi Miquel

On Tue, Sep 10, 2024 at 2:56 PM Miquel Raynal <miquel.raynal at bootlin.com> wrote:
>
> Hi Michael,
>
> michael at amarulasolutions.com wrote on Tue, 10 Sep 2024 12:30:42 +0200:
>
> > Hi Miquel
> >
> > On Tue, Sep 10, 2024 at 12:13 PM Miquel Raynal
> > <miquel.raynal at bootlin.com> wrote:
> > >
> > > In order to display a boot picture or an error message, the i.MX8MP
> > > display pipeline must be enabled. The SoC has support for various
> > > interfaces (LVDS, HDMI, DSI). The one supported in this series is the
> > > standard 4-lane LVDS output. The minimal setup is thus composed of:
> > > * An LCD InterFace (LCDIF) with an AXI/APB interface, generating a pixel
> > >   stream
> > > * One LVDS Display Bridge (LDB), also named pixel mapper, which receives
> > >   the pixel stream and route it to one or two (possibly combined) LVDS
> > >   displays.
> > > * All necessary clocks and power controls coming from the MEDIAMIX
> > >   control block.
> > >
> > > Patch 1 adds a very useful helper to the core in order to grab devices
> > > through endpoints instead of being limited to phandles. Video pipelines
> > > being often described using graphs endpoints, the introduced helper is
> > > used several times in the serires (there are 3 LCDIF, one of them being
> > > connected to the LDB, itself having 2 ports).
> > >
> > > Patch 2 is a fix which is necessary for this series to work properly,
> > > but is way broader than just this use case. In practice, when assigned
> > > clocks are defined in the device tree, the clock uclass tries to assign
> > > the parents first and then sets them to the correct frequency. This only
> > > works if the parents have been enabled themselves. Otherwise we end-up
> > > with a non-clocked parent. I believe this is not the intended behavior
> > > in general, but more importantly on the i.MX8MP, there are "clock
> > > slices" which have pre-requisites in order to be modified and selecting
> > > an ungated parent is one of them.
> > >
> > > All the other patches progressively build support for the whole video
> > > pipeline. Regarding the LCDIF driver, there is already a similar driver
> > > for older i.MX SoCs but I didn't manage to get it to work. It was
> > > written more than a decade ago while device-model, clocks and others
> > > were not yet generically supported. Thus, numerous ad-hoc solutions
> > > were implemented, which no longer fit today's requirements. I preferred
> > > to add a new "clean" driver instead of modifying the existing one
> > > because of the too high risk of breaking these platforms. Once proper
> > > clocks/power-domain descriptions will be added to them they might be
> > > converted (and tested) to work with the "new" implementation, but going
> > > the opposite way felt drawback.
> > >
> >
> > Thank you for adding those patches. We are working on mipi support
> > here and some of the clock patches
> > are there too. I will try to look and rebase our patchset
> >
> > https://patchwork.amarulasolutions.com/patch/3401/
>
> Thanks for letting me know. Indeed there are a couple of conflicts.
> - My patch 2 can easily be replaced by your approach.
> - Regarding the power domain we had two different approaches, I
>   didn't look in details, but again one or the other seems fine, I
>   guess.
> - The LDB driver in my series is new.
> - Finally regarding the LCDIF changes, the approach taken on your
>   side follows the somewhat too ad-hoc logic and would probably benefit
>   from being migrated to the driver I propose, which does make use of
>   the (DM) clock, power domain and DT API. I am really happy with the
>   core helper I've added retrieving a device in front of a graph
>   endpoint, which makes the whole "get panel/bridge" approach much more
>   flexible and adapted to today's needs.
>

My idea is to work on top of your patches and try to migrate them and
cover conflicts.
What be helpful is to get some of our clock patches and include in
your series and then I will try
to move our work on it

Michael

> What is the status of your patchset? How shall we handle the conflicts?
>
> Thanks,
> Miquèl



-- 
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
michael at amarulasolutions.com
__________________________________

Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
info at amarulasolutions.com
www.amarulasolutions.com