linux-kernel - Re: [PATCH] arm64: dts: imx8m: add syscon node for display_blk

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 2 Nov 2021 11:18:53 -0700
From:   Tim Harvey <tharvey@...eworks.com>
To:     Adam Ford <aford173@...il.com>
Cc:     Tommaso Merciai <tomm.merciai@...il.com>,
        Ahmad Fatoum <a.fatoum@...gutronix.de>,
        arm-soc <linux-arm-kernel@...ts.infradead.org>,
        devicetree <devicetree@...r.kernel.org>,
        Peng Fan <peng.fan@....com>, Alice Guo <alice.guo@....com>,
        Shawn Guo <shawnguo@...nel.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Joakim Zhang <qiangqing.zhang@....com>,
        Krzysztof Kozlowski <krzk@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Rob Herring <robh+dt@...nel.org>,
        NXP Linux Team <linux-imx@....com>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        Fabio Estevam <festevam@...il.com>,
        Lucas Stach <l.stach@...gutronix.de>,
        Schrempf Frieder <frieder.schrempf@...tron.de>,
        Jagan Teki <jagan@...rulasolutions.com>,
        Michael Tretter <m.tretter@...gutronix.de>
Subject: Re: [PATCH] arm64: dts: imx8m: add syscon node for display_blk_ctrl
 module regs

On Tue, Nov 2, 2021 at 9:08 AM Adam Ford <aford173@...il.com> wrote:
>
> On Tue, Nov 2, 2021 at 10:47 AM Tommaso Merciai <tomm.merciai@...il.com> wrote:
> >
> > On Tue, Nov 02, 2021 at 07:23:06AM -0500, Adam Ford wrote:
> > > The upcoming 5.16 kernel will have a new blk-ctrl driver which will
> > > work in conjunction with the GPC.  You can see it in linux-next [1],
> > > and I would expect it to be present in 5.16-rc1 once the merge is
> > > done.
> > >
> > > In [1], Look for :
> > >
> > > disp_blk_ctrl: blk-ctrl@...28000 {
> > >     compatible = "fsl,imx8mm-disp-blk-ctrl", "syscon";
> > >
> > > It creates a bunch of virtual power domains which are effectively the
> > > resets for the VPU, CSI, DSI, and LCDIF [2].
> > >
> > > Basically, to pull the respective device out of reset, you'd reference
> > > them using power-domains.  I have an RFC patch for the CSI located [3]
> > > which should bring the GPC power domain up, then take the CSI bridge
> > > and MIPI_CSI out of reset using the blk-ctrl.  A few of us are still
> > > investigating the CSI bridge and mipi_csi drivers to determine what's
> > > going wrong, but  inside that patch, you'll see that we reference
> > > "power-domains = <&disp_blk_ctrl IMX8MM_DISPBLK_PD_CSI_BRIDGE>;" and
> > > "power-domains = <&disp_blk_ctrl IMX8MM_DISPBLK_PD_MIPI_CSI>;" which
> > > are part of the new blk-ctrl driver @32e2800.  Other peripherals like
> > > LCD, DSI, and the VPU's should be able to reference their respective
> > > power domains to activate the corresponding resets after enabling the
> > > proper GPC power domain.
> >
> >   Hi Adam,
> >   Then is all done right. Using this this new driver/dts node eLCDIF/mipi_dsi
> >   module are out of reset. Thanks for the tips. I'm trying to get eLCDIF/mipi_dsi
> >   work on mainline. I try to get work
> >
> >   - eLCDIF using: mxsfb_drv.c
> >   - mipi_dsi using: nwl-dsi.c
> >
> >   What do you think about? You think that can be a good way ( taking
> >   imx8mq as reference )?
>
> The DSI controller for the 8MM and 8MN is not the same as the DSI
> controller on the 8MQ, but the LCDIF controller should be compatible.
>
> There have been several attempts to support the 8MM DSI, but none of
> them have been accepted for various reasons.
>
> The latest was found here [1], but others [2]  and [3] , when used
> together, do something similar.
>
> If memory serves, the main issue has to do with the fact that the DSIM
> controller in the 8MM and 8MN is also present in one of the Samsung
> processors, and the goal is to rework those drivers so we'll have one
> driver that supports both Samsung progressors and NXP instead of
> having two duplicate drivers doing the same thing. When whatever
> driver is chosen is ready, it'll be likely that the LCDIF will use
> power-domains = <&disp_blk_ctrl MX8MM_DISPBLK_PD_LCDIF> and the DSI
> node will use power-domains = <&disp_blk_ctrl
> IMX8MM_DISPBLK_PD_MIPI_DSI> to pull their respective devices out of
> reset and enable the gpc.
>
>
> [1] - https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=510489&archive=both&state=*
> [2] - https://patchwork.kernel.org/project/dri-devel/list/?series=347439&archive=both&state=*
> [3] - https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=359775&archive=both&state=*

Adam,

Thanks for the good summary... I was just putting this info together
as well. I'm also interested to see if anyone has made progress on
IMX8MM MIPI DSI display. Now that blk-ctl and most of the dt bindings
have been merged for 5.16 I think we are just down to the drm/exynos
driver issue.

Added Frieder, Jagan, and Michael to the thread.

Best Regards,

Tim