Re: [PATCH v2 0/7] drm/vc4: Fix the core clock behaviour
From: Maxime Ripard
Date: Thu Oct 13 2022 - 04:59:58 EST
Hi Florian,
On Mon, Oct 10, 2022 at 12:07:22PM -0700, Florian Fainelli wrote:
> On 10/10/22 04:44, Maxime Ripard wrote:
> > Hi Florian,
> >
> > On Tue, Sep 20, 2022 at 02:50:19PM +0200, Maxime Ripard wrote:
> > > Those patches used to be part of a larger clock fixes series:
> > > https://lore.kernel.org/linux-clk/20220715160014.2623107-1-maxime@xxxxxxxxxx/
> > >
> > > However, that series doesn't seem to be getting anywhere, so I've split out
> > > these patches that fix a regression that has been there since 5.18 and that
> > > prevents the 4k output from working on the RaspberryPi4.
> > >
> > > Hopefully, we will be able to merge those patches through the DRM tree to avoid
> > > any further disruption.
> >
> > Could you review this? Ideally this would be merged through drm-misc due
> > to the dependencies between the new firmware functions and the DRM
> > patches.
>
> I suppose I can review the firmware parts if you would like me to
I was of course asking for the firmware parts :)
> for vc4 I am pretty much clueless, and despite efforts from Emma to
> get the vc4 driver to be usable on platforms other than Pi, that never
> happened unfortunately.
Stefan had the same concerns, but I don't think that's a big one. If
needs be, we can move the call to the firware into an if statement or
whatever and support a firmware-less device.
> It would be better to keep the firmware and vc4 drivers decoupled,
> just so "wrong" assumptions are not made, but for all practical
> purposes this is the only combination that exists.
I know, and my initial proposal was relying on a generic CCF function to
implement this. Stephen didn't feel like a single user for it was
enough, and there were some technical drawbacks too that might not have
made this solution robust enough. Hence the firmware solution.
Maxime
Attachment:
signature.asc
Description: PGP signature