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

[Michal Wilczynski <m.wilczynski@samsung.com>]

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@samsung.com>