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 <[email protected]>
