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]>
