imx8mm eLCDIF clock

[Michael Nazzareno Trimarchi]

Hi

On Thu, Apr 21, 2022 at 2:05 PM Adam Ford <aford173 at gmail.com> wrote:
>
> On Thu, Apr 21, 2022 at 7:03 AM Stefano Babic <sbabic at denx.de> wrote:
> >
> > On 21.04.22 14:01, Marek Vasut wrote:
> > > On 4/21/22 13:54, Tommaso Merciai wrote:
> > >> On Thu, Apr 21, 2022 at 01:20:58PM +0200, Marek Vasut wrote:
> > >>> On 4/21/22 13:14, Adam Ford wrote:
> > >>>> On Thu, Apr 21, 2022 at 5:29 AM Tommaso Merciai
> > >>>> <tommaso.merciai at amarulasolutions.com> wrote:
> > >>>>>
> > >>>>> On Thu, Apr 21, 2022 at 08:48:05AM +0200, Tommaso Merciai wrote:
> > >>>>>
> > >>>>> + Fabio
> > >>>>> + Tim
> > >>>>> + Michael
> > >>>>> + Marek
> > >>>>> + Adam
> > >>>>>
> > >>>>>> Hi,
> > >>>>>> I'm working on drivers/clk/imx/clk-imx8mm.c to port and bring up
> > >>>>>> eLCDIF
> > >>>>>> clocks. After port all necessary clocks needed by eLCDIF I found that
> > >>>>>> IMX8MM_VIDEO_PLL1 clock is not enabled and need the clk_enable to
> > >>>>>> enable
> > >>>>>> it at the end of the clk-imx8mm probe:
> > >>>>>>
> > >>>>>> struct clk *clkp;
> > >>>>>>
> > >>>>>> clk_get_by_id(IMX8MM_VIDEO_PLL1, &clkp);
> > >>>>>> clk_set_rate(clkp, 594000000UL);
> > >>>>>> clk_enable(clkp);
> > >>>>>>
> > >>>>>> What do you think about this solution?
> > >>>>>> There is a more standard way to do this?
> > >>>>>> I'm missing somethings?
> > >>>>
> > >>>> I think the LCD driver should request the clock and clock rate based
> > >>>> on settings the device tree.  However, I think the bigger issues is
> > >>>> that you might run into issues with the lack of a disp-blkctrl driver.
> > >>>> Marek enable the GPC driver fairly recently, but the blkctrl driver
> > >>>> will be needed to enable the LCD and DSI portions or the system may
> > >>>> hang.
> > >>>
> > >>> Just boot quickly and init the graphics pipeline in Linux ?
> > >>
> > >> Hi Marek,
> > >> Thanks for your feedback. You think make no sense to enable support
> > >> for the graphics pipeline at U-Boot level? Some customers want this
> > >> feature for that I think is better to have support for that.
> > >> What do you think about?
> > >
> > > I think it makes no sense to duplicate graphics pipeline in U-Boot.
> > >
> > > Just boot quickly enough and bring the graphics pipeline in Linux,
> >
> > +1
> >
> > Rather, it is not time anymore to get a flickering-free display from
> > U-Boot to Linux (it was possible on some SOC before DRM). Just booting
> > fast is the best option.
> >
> > Regards,
> > Stefano
> >
> > > then
> > > maintain one copy of all the drivers involved in the pipeline (scanout
> > > engine, GPCs, block controllers, bridge drivers, panel drivers). Also,
> > > you won't have to deal with the display pipeline handoff from U-Boot to
> > > Linux, which incurs flicker.
>
> For what it's worth, there was a thread about using Falcon mode with
> ARM64.  I was going to investigate it when I have some time.  It would
> be nice to bypass the U-Boot phase completely and jump from
> SPL->ATF->Linux if possible.
>
> adam

Well we should consider graphics panel in uboot, it's standard chain
for mobile phone, or rockchip bsp

Michael


> >
> >
> >
> >
> > --
> > =====================================================================
> > DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
> > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> > Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
> > =====================================================================



--
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