linux-kernel - Re: [PATCH 6/6] drm/meson: add support for MIPI-DSI transceiver

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] [day] [month] [year] [list]

Message-ID: <e1fa9887-da2e-3a69-0e2e-3a6d07e13cb5@baylibre.com>
Date:   Thu, 20 Jan 2022 14:28:11 +0100
From:   Neil Armstrong <narmstrong@...libre.com>
To:     Jagan Teki <jagan@...rulasolutions.com>
Cc:     daniel@...ll.ch, linux-amlogic@...ts.infradead.org,
        linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH 6/6] drm/meson: add support for MIPI-DSI transceiver

Hi Jagan,

On 20/01/2022 12:03, Jagan Teki wrote:
> On Wed, Jan 12, 2022 at 1:49 PM Neil Armstrong <narmstrong@...libre.com> wrote:
>>
>> Hi,
>>
>> On 12/01/2022 08:24, Jagan Teki wrote:
>>> Hi Neil,
>>>
>>> On Mon, Sep 7, 2020 at 1:48 PM Neil Armstrong <narmstrong@...libre.com> wrote:
>>>>
>>>> The Amlogic AXg SoCs embeds a Synopsys DW-MIPI-DSI transceiver (ver 1.21a), with a custom
>>>> glue managing the IP resets, clock and data input similar to the DW-HDMI Glue on other
>>>> Amlogic SoCs.
>>>>
>>>> This adds support for the Glue managing the transceiver, mimicing the init flow provided
>>>> by Amlogic to setup the ENCl encoder, the glue, the transceiver, the digital D-PHY and the
>>>> Analog PHY in the proper way.
>>>>
>>>> The DW-MIPI-DSI transceiver + D-PHY are directly clocked by the VCLK2 clock, which pixel clock
>>>> is derived and feeds the ENCL encoder and the VIU pixel reader.
>>>>
>>>> An optional "MEAS" clock can be enabled to measure the delay between each vsync feeding the
>>>> DW-MIPI-DSI transceiver.
>>>>
>>>> Signed-off-by: Neil Armstrong <narmstrong@...libre.com>
>>>> ---
>>
>> [..]
>>
>>>> +
>>>> +static const struct component_ops meson_dw_mipi_dsi_ops = {
>>>> +       .bind   = meson_dw_mipi_dsi_bind,
>>>> +       .unbind = meson_dw_mipi_dsi_unbind,
>>>> +};
>>>
>>> Do you thought of non-component based meson DSI like STM DSI? It
>>> require changes from meson drm but just to understand if you have any
>>> such plan.
>>
>> I have no such plans for now, note this serie has been rewritten at [1] but still
>> with based with components.
>>
>> If worth it, the plan is to get it with components and than yes if it's simpler
>> drop components completely.
> 
> Dropping components make the pipeline well suited for bridges as we
> are moving bridge-driven pipelines in other areas.
> 
>>
>> I'll have a look at how ST does
> 
> ST has no components. As I said above, eventually there would be
> common bridge driver for dw-mipi-dsi if meson and rockchip moving away
> from components.

ST driver is much more simpler.

And having a common dw-mipi-dsi is unreal since each HW has a different glue HW
me must handle. Even if we moved all the glue handling under drm/bridge/synopsys,
we would need a different set of callbacks for each HW for each compatible
which is basically the actual situation except components.

Neil

> 
> Thanks,
> Jagan.
>