lkml.org 
[lkml]   [2023]   [Nov]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] drm/imagination: DRM_POWERVR should depend on ARCH_K3
On Wed, Nov 29, 2023 at 09:58:12AM +0100, Geert Uytterhoeven wrote:
> Hi Maxime,
>
> On Wed, Nov 29, 2023 at 9:35 AM Maxime Ripard <mripard@kernel.org> wrote:
> > On Tue, Nov 28, 2023 at 08:16:18PM +0100, Geert Uytterhoeven wrote:
> > > On Tue, Nov 28, 2023 at 8:03 PM Javier Martinez Canillas
> > > <javierm@redhat.com> wrote:
> > > > Geert Uytterhoeven <geert+renesas@glider.be> writes:
> > > > > The Imagination Technologies PowerVR Series 6 GPU is currently only
> > > > > supported on Texas Instruments K3 AM62x SoCs. Hence add a dependency on
> > > > > ARCH_K3, to prevent asking the user about this driver when configuring a
> > > > > kernel without Texas Instruments K3 Multicore SoC support.
> > > > >
> > > > > Fixes: 4babef0708656c54 ("drm/imagination: Add skeleton PowerVR driver")
> > > > > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
> > > > In any case, I agree with you that restricting to only K3 makes sense.
> > >
> > > I am looking forward to adding || SOC_AM33XX || ARCH_RENESAS || ...,
> > > eventually ;-)
> >
> > I disagree. This is to handle a generic IP, just like panfrost, lima, or
> > etnaviv, and we certaintly don't want to maintain the Kconfig list of
> > every possible architecture and SoC family it might or might not be
> > found.
>
> While PowerVR is a generic IP, I believe it needs a non-generic
> firmware, which is currently only available for AM62x SoCs.

I'm not sure it's actually true, but let's consider it is. Then what? If
the firmware isn't there and/or the DT bits too, then nothing will
happen. We would have wasted a couple of 100kB on a system that is
taking somewhere in the 100MB-10GB range, and that's pretty much it.

If you have we take that patch in though, we have:

- To keep merging patches as firmwares become available.

- If we update linux-firmware only, then the driver is still not
loading even though it could.

- If we have gotten our firmware through some other mean, then the
driver is still not loading even though it could.

It makes life harder for everyone: maintainers, users, devs, based on
the state of some external project that might or might not be updated in
sync.

> Once it becomes truly generic, I'm happy to drop all platform
> dependencies. Until then, there is no point in asking everyone who
> configures an arm64 kernel about this driver, unless they also enabled
> K3 support.

Whether it's truly generic, whatever that means, is irrelevant here.

Maxime
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2023-11-29 10:23    [W:0.077 / U:0.832 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site