linux-kernel - Re: [RFC PATCH 2/9] drm: bridge: Add Samsung SEC MIPI DSIM bridge driver

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]

Message-ID: <CAMty3ZBnj6AwdrGXKx1jsqVnrk9abShzamM4H++WE7mcU09sYA@mail.gmail.com>
Date:   Wed, 30 Jun 2021 15:51:34 +0530
From:   Jagan Teki <jagan@...rulasolutions.com>
To:     Frieder Schrempf <frieder.schrempf@...tron.de>,
        Daniel Vetter <daniel.vetter@...el.com>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc:     Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>,
        Fabio Estevam <festevam@...il.com>,
        Michael Tretter <m.tretter@...gutronix.de>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>, Peng Fan <peng.fan@....com>,
        Francis Laniel <francis.laniel@...rulasolutions.com>,
        Matteo Lisi <matteo.lisi@...icam.com>,
        Neil Armstrong <narmstrong@...libre.com>,
        linux-amarula <linux-amarula@...rulasolutions.com>,
        Tomasz Figa <t.figa@...sung.com>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Robert Foss <robert.foss@...aro.org>,
        Andrzej Hajda <a.hajda@...sung.com>,
        DRI mailing list <dri-devel@...ts.freedesktop.org>,
        Milco Pratesi <milco.pratesi@...icam.com>,
        Anthony Brandon <anthony@...rulasolutions.com>,
        linux-phy@...ts.infradead.org, Fancy Fang <chen.fang@....com>,
        Shawn Guo <shawnguo@...nel.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" 
        <linux-arm-kernel@...ts.infradead.org>,
        NXP Linux Team <linux-imx@....com>,
        "marex@...x.de" <marex@...x.de>
Subject: Re: [RFC PATCH 2/9] drm: bridge: Add Samsung SEC MIPI DSIM bridge driver

Hi Frieder,

Thanks for sharing the details.

On Mon, Jun 28, 2021 at 1:49 PM Frieder Schrempf
<frieder.schrempf@...tron.de> wrote:
>
> Hi Jagan,
>
> On 24.06.21 10:30, Krzysztof Kozlowski wrote:
> > On 24/06/2021 04:48, Fabio Estevam wrote:
> >> Hi Jagan/Laurent,
> >>
> >> On Wed, Jun 23, 2021 at 7:23 PM Laurent Pinchart
> >> <laurent.pinchart@...asonboard.com> wrote:
> >>
> >>> Looking at the register set, it seems to match the Exynos 5433,
> >>> supported by drivers/gpu/drm/exynos/exynos_drm_dsi.c. Can we leverage
> >>> that driver instead of adding a new one for the same IP core ?
> >>
> >> Yes. there was an attempt from Michael in this direction:
> >> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.kernel.org%2Fproject%2Fdri-devel%2Fcover%2F20200911135413.3654800-1-m.tretter%40pengutronix.de%2F&amp;data=04%7C01%7Cfrieder.schrempf%40kontron.de%7C52db05459ef0462d5a9b08d936eab1ba%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C637601203901391193%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=LTYk9kpUeB9bgfRITQT6wIij3XTOIk37AHXbzQ2UI4Y%3D&amp;reserved=0
> >
> > That's the proper direction (maybe as Marek suggested - sharing common
> > code like for Analogix DP), not duplicating a driver.
> >
>
> Just to make sure that you are aware of the previous patches and discussions here are some additional pointers:
>
> * i.MX8MM glue code from Marek (+ Cc): [1]
> * DPHY driver from Marek: [2]
> * General discussion about driver implementation: [3]
> * Daniel's (+ Cc) suggested direction to move forward: [4]

It Looks like Daniel's suggestion is to have a common bridge driver
without sharing a code between platforms. It makes sense and clean but
the key issues lie on the exynos side, the exynos drm drives require
potential changes and tests, which indeed are hard but possible -
IMHO. However there is another issue with component_ops the i.MX8M
side MXSFB doesn't use any component_ops but the exynos are fully
component aware.

>
> It looks like you already did a fork of the Exynos driver, so your approach might be generally in line with what Daniel suggested.

I did use PMS computation from exynos and reference driver from imx8
tree. Last 2 days I worked on exynos_drm_dsi.c (with some additions)
and converted a bridge driver and it worked on my i.MX8MM platform.

Right now, I'm checking the possible implementations and will come
back to my approach for further comments.

Jagan.