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: <1b2c290b-5716-4a07-82b3-e53c35af2150@samsung.com>
Date: Sat, 22 Nov 2025 12:42:20 +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>, 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>, 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>, 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/13/25 15:57, Michal Wilczynski wrote:
> 
> 
> 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,

Hi folks,

Just a gentle ping on this series.

I am primarily waiting on architectural feedback regarding the split
between the DRM bridge and the PHY driver.

If I don't receive any objections soon, I'll assume the current
structure is acceptable and proceed with addressing the known PHY tuning
issues for v2.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ