linux-kernel - Re: [PATCH V2 5/6] drm: bridge: samsung-dsim: Support non-burst mode

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: <46429c9b-cf14-a67e-81a8-b56be0350ea3@samsung.com>
Date:   Fri, 28 Apr 2023 16:04:50 +0200
From:   Marek Szyprowski <m.szyprowski@...sung.com>
To:     Adam Ford <aford173@...il.com>
Cc:     dri-devel@...ts.freedesktop.org, aford@...conembedded.com,
        dario.binacchi@...rulasolutions.com, l.stach@...gutronix.de,
        Inki Dae <inki.dae@...sung.com>,
        Jagan Teki <jagan@...rulasolutions.com>,
        Andrzej Hajda <andrzej.hajda@...el.com>,
        Neil Armstrong <neil.armstrong@...aro.org>,
        Robert Foss <rfoss@...nel.org>,
        Laurent Pinchart <Laurent.pinchart@...asonboard.com>,
        Jonas Karlman <jonas@...boo.se>,
        Jernej Skrabec <jernej.skrabec@...il.com>,
        David Airlie <airlied@...il.com>,
        Daniel Vetter <daniel@...ll.ch>, Marek Vasut <marex@...x.de>,
        Frieder Schrempf <frieder.schrempf@...tron.de>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH V2 5/6] drm: bridge: samsung-dsim: Support non-burst
 mode

On 28.04.2023 15:35, Adam Ford wrote:
> On Fri, Apr 28, 2023 at 7:31 AM Marek Szyprowski
> <m.szyprowski@...sung.com> wrote:
>> On 24.04.2023 12:00, Adam Ford wrote:
>>> On Mon, Apr 24, 2023 at 3:25 AM Marek Szyprowski
>>> <m.szyprowski@...sung.com> wrote:
>>>> On 23.04.2023 14:12, Adam Ford wrote:
>>>>> The high-speed clock is hard-coded to the burst-clock
>>>>> frequency specified in the device tree.  However, when
>>>>> using devices like certain bridge chips without burst mode
>>>>> and varying resolutions and refresh rates, it may be
>>>>> necessary to set the high-speed clock dynamically based
>>>>> on the desired pixel clock for the connected device.
>>>>>
>>>>> This also removes the need to set a clock speed from
>>>>> the device tree for non-burst mode operation, since the
>>>>> pixel clock rate is the rate requested from the attached
>>>>> device like an HDMI bridge chip.  This should have no
>>>>> impact for people using burst-mode and setting the burst
>>>>> clock rate is still required for those users.
>>>>>
>>>>> Signed-off-by: Adam Ford <aford173@...il.com>
>>>> This one breaks Exynos-5433 based TM2e board with a DSI panel.
>>> Marek S,
>>>
>>> Thank you for testing!  I knoiw there are several of us who appreciate
>>> your testing this since it's hard to know if something broke without
>>> hardware.  Is there any way you can tell me if the flag is set to
>>> enable MIPI_DSI_MODE_VIDEO_BURST?
>> TM2e board uses the DSI panel operated in command mode and handled by
>> panel-samsung-s6e3ha2.c driver. The MIPI_DSI_MODE_VIDEO_BURST flag is
>> not set by the driver. However, the MIPI_DSI_CLOCK_NON_CONTINUOUS flags
>> is set there. I really have no idea if setting VIDEO_BURST would make
>> sense together with CLOCK_NON_CONTINUOUS or not. Maybe the driver lacks
>> setting it?
>>
>>
>>> I was trying to be diligent about not breaking your boards, but
>>> without your boards, it's difficult.  The theory was that if
>>> MIPI_DSI_MODE_VIDEO_BURST is set and there is a burst clock set in the
>>> device tree, it would use the burst clock.
>>>
>>> As a fall-back I could just simply check for the presence of the
>>> burst_clock_rate instead of both MIPI_DSI_MODE_VIDEO_BURST and
>>> burst_clock_rate.
>> Maybe you should extend your check also for the
>> MIPI_DSI_CLOCK_NON_CONTINUOUS flag? Does it make sense?
> Looking at some of the devices that might attach in the future, It
> appears that ti-sn65dsi86.c sets this flag.  It's a display port
> bridge, so I would expect it to need a variable clock rate similar to
> how the HDMI bridge that I need works.  I am concerned that I make the
> burst clock dependent on MIPI_DSI_CLOCK_NON_CONTINUOUS, it might break
> the Display Port bridge.
>
> I think it's better to just check if the samsung,burst-clock-frequency
> is present in the device tree and use it when present.  If it's not
> present, then fall back to the pixel clock of the connected device.

Right, this sounds rational.

> I looked at a bunch of Exynos parts, and it looks like they all use
> the samsung,burst-clock-frequency device tree setting.  Is that true,
> or did I miss one?

That true. All Exynos based boards with DSI panels use constant DSI 
burst frequency defined in the device tree.


Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland