imx8mm eLCDIF clock

Adam Ford aford173 at gmail.com
Thu Apr 21 14:05:13 CEST 2022


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


More information about the U-Boot mailing list