[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20221013085947.jux4tfbh64ldluin@houat>
Date: Thu, 13 Oct 2022 10:59:47 +0200
From: Maxime Ripard <maxime@...no.tech>
To: Florian Fainelli <f.fainelli@...il.com>
Cc: Daniel Vetter <daniel@...ll.ch>, David Airlie <airlied@...ux.ie>,
Broadcom internal kernel review list
<bcm-kernel-feedback-list@...adcom.com>,
Michael Turquette <mturquette@...libre.com>,
Scott Branden <sbranden@...adcom.com>,
Stephen Boyd <sboyd@...nel.org>, Emma Anholt <emma@...olt.net>,
Ray Jui <rjui@...adcom.com>,
linux-rpi-kernel@...ts.infradead.org, linux-clk@...r.kernel.org,
linux-kernel@...r.kernel.org, Dom Cobley <popcornmix@...il.com>,
dri-devel@...ts.freedesktop.org,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2 0/7] drm/vc4: Fix the core clock behaviour
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@cerno.tech/
> > >
> > > 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
Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)
Powered by blists - more mailing lists