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

[Conor Dooley]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-riscv/attachments/20251111/59b7ab08/attachment.sig>