linux-kernel - Re: [PATCH RFC 00/13] drm: starfive: jh7110: Enable display subsystem

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: <e1696331-1271-46a8-adb6-9fed4521f22b@samsung.com>
Date: Thu, 13 Nov 2025 15:57:57 +0100
From: Michal Wilczynski <m.wilczynski@...sung.com>
To: Conor Dooley <conor@...nel.org>, Maxime Ripard <mripard@...nel.org>,
	Heiko Stuebner <heiko@...ech.de>, Dmitry Baryshkov
	<dmitry.baryshkov@....qualcomm.com>, Robert Foss <rfoss@...nel.org>
Cc: Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Emil Renner Berthing <kernel@...il.dk>, Hal Feng
	<hal.feng@...rfivetech.com>, Michael Turquette <mturquette@...libre.com>,
	Stephen Boyd <sboyd@...nel.org>, Conor Dooley <conor+dt@...nel.org>, Xingyu
	Wu <xingyu.wu@...rfivetech.com>, Vinod Koul <vkoul@...nel.org>, Kishon Vijay
	Abraham I <kishon@...nel.org>, 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>, Simona Vetter <simona@...ll.ch>, Maarten Lankhorst
	<maarten.lankhorst@...ux.intel.com>, Maxime Ripard <mripard@...nel.org>,
	Thomas Zimmermann <tzimmermann@...e.de>, Lee Jones <lee@...nel.org>, Philipp
	Zabel <p.zabel@...gutronix.de>, Paul Walmsley <paul.walmsley@...ive.com>,
	Palmer Dabbelt <palmer@...belt.com>, Albert Ou <aou@...s.berkeley.edu>,
	Alexandre Ghiti <alex@...ti.fr>, Marek Szyprowski
	<m.szyprowski@...sung.com>, Icenowy Zheng <uwu@...nowy.me>, Maud Spierings
	<maudspierings@...ontroll.com>, Andy Yan <andyshrk@....com>, Heiko Stuebner
	<heiko@...ech.de>, devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-clk@...r.kernel.org, linux-phy@...ts.infradead.org,
	dri-devel@...ts.freedesktop.org, linux-riscv@...ts.infradead.org
Subject: Re: [PATCH RFC 00/13] drm: starfive: jh7110: Enable display
 subsystem



On 11/11/25 19:37, Conor Dooley wrote:
> On Tue, Nov 11, 2025 at 06:14:48PM +0000, Conor Dooley wrote:
>> On Tue, Nov 11, 2025 at 04:33:28PM +0100, Michal Wilczynski wrote:
>>>
>>>
>>> On 11/10/25 20:35, Conor Dooley wrote:
>>>> On Sat, Nov 08, 2025 at 02:04:34AM +0100, Michal Wilczynski wrote:
>>>>> This series enables the display subsystem on the StarFive JH7110 SoC.
>>>>> This hardware has a complex set of dependencies that this series aims to
>>>>> solve.
>>>>>
>>>>> I believe this is a PHY tuning issue that can be fixed in the new
>>>>> phy-jh7110-inno-hdmi.c driver without changing the overall architecture.
>>>>> I plan to continue debugging these modes and will submit follow up fixes
>>>>> as needed.
>>>>>
>>>>> The core architectural plumbing is sound and ready for review.
>>>>>
>>>>> Notes:
>>>>> - The JH7110 does not have a centralized MAINTAINERS entry like the
>>>>>   TH1520, and driver maintainership seems fragmented. I have therefore
>>>>>   added a MAINTAINERS entry for the display subsystem and am willing to
>>>>>   help with its maintenance.
>>>>
>>>> Yeah, bunch of different folks wrote the drivers, so lots of entries.
>>>> Pretty much all as you've done here, authors are responsible for the
>>>> individual components and Emil is the platform maintainer but
>>>> responsible for most drivers.
>>>>
>>>> Do you need any feedback dt wise on the RFC, or is it too likely that
>>>> we'll both waste our breath if the DRM folks don't approve of your
>>>> approach for the rest of this series?
>>>
>>> Hi Conor,
>>>
>>> Thank you for your response.
>>>
>>> That's a fair point about the risk of the DRM approach being rejected.
>>> While I can't be certain, I'm hopeful that part is relatively
>>> straightforward, as it primarily integrates other recently reviewed
>>> (though not yet merged) components like the inno-hdmi bridge and dc8200
>>> drivers.
>>>
>>> To be honest, I was more concerned that the DT part of the series would
>>> be more problematic. Given that, I would find it very helpful to get
>>> your feedback on the DT aspects now, if you have the time.
>>
>> Right. You'll definitely want some actual DRM people to weigh in though
>> before making changes, I am really not familiar enough with this type of
>> hardware to know if the breakdown is correct.
> 
> It looks generally sane to me chief, but as I said I am not really
> familiar enough with this sort of hardware to have a real take on it.
> Sorry, you'll need to get your affirmation about how you've laid stuff
> out elsewhere :/

Thanks for the look, Conor.

I appreciate the sanity check on the DT side. I'll focus on getting the
necessary feedback from the DRM maintainers regarding the architectural
breakdown before spinning a v2.

[Adding Dmitry Baryshkov and highlighting Maxime, Heiko, and Robert]

Could you folks take a brief look at the driver split in this series?

Conor has reviewed the DT bindings and they look sane to him, but we
need to verify that the architectural split between the
phy-jh7110-inno-hdmi and the DRM bridge driver is acceptable for this
Innosilicon IP.

I am particularly interested if the current handling of the PHY tuning
parameters (as described in the cover letter) fits the modern DRM
bridge/PHY paradigm, or if this should be modeled differently given the
similarities to Rockchip implementations.

Best regards,
-- 
Michal Wilczynski <m.wilczynski@...sung.com>