[PATCH] drm/imagination: DRM_POWERVR should depend on ARCH_K3

[Maxime Ripard]

On Wed, Nov 29, 2023 at 11:10:51AM +0100, Geert Uytterhoeven wrote:
> On Wed, Nov 29, 2023 at 10:23 AM Maxime Ripard <mripard at kernel.org> wrote:
> > On Wed, Nov 29, 2023 at 09:58:12AM +0100, Geert Uytterhoeven wrote:
> > > On Wed, Nov 29, 2023 at 9:35 AM Maxime Ripard <mripard at 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 at redhat.com> wrote:
> > > > > > Geert Uytterhoeven <geert+renesas at 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 at 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 just asked, it's not true in most cases. There's some exceptions
(GX6250 for example) that could require different firmwares depending on
the SoC it's used in, but it's not the case here.

> > 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.
> 
> I am talking about posing the question to the user to enable the driver
> or not.  Which applies to everyone who configures a kernel.

If that user doesn't use a defconfig, doesn't use any variant of
*defconfig make target. Plus, the driver still isn't enabled by default.

> > If you have we take that patch in though, we have:
> >
> >   - To keep merging patches as firmwares become available.
> 
> You need to keep merging patches to update DT bindings, DTS,
> SoC-specific drivers, the DRM driver itself, ... too.

The DT binding and DRM driver is already there, the SoC specific drivers
are probably already there by the time you reach GPU enablement, and the
DT doesn't have to be upstream.

> >   - 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.
> 
> You will still need to update parts of the kernel, too.

Not really, no. We can use the AM62x as an example. The only thing that
was required to enable the driver (excluding the driver itself of
course) was a single DT patch, without anything you've mentioned so far.

> As long as none of that has happened, asking about the PowerVR driver
> on non-AM62x hardware is futile...

Maybe. Just like asking whether you want to enable the UMS driver on
platforms that don't have a USB controller. Or, closer to us, whether
you want to enable AMDGPU on platforms without a PCIe bus.

We *never* do that.

If only because we can't. We don't have a per-SoC Kconfig option, so
even if we were to merge your patch, we would still ask about the
PowerVR driver on, let's say, the AM69 that isn't an AM62x and is just
as futile according to you. Or for the TDA4VM, or...

The other reason is that it's just impossible to maintain. You wouldn't
expect everyone, once they got their USB support in, to amend the
Kconfig dependencies for every USB driver out there, would you?

> > 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.
> 
> It is.
> 
> BTW, playing the devil's advocate: why is there a dependency on ARM64?
> PowerVR GPUs are also present on (at least) arm32 and Intel?

I would welcome any patch extending that requirement, or droping that
requirement.

> Oh, dropping that would expose this question to Linus, causing his
> wrath to come down on you... ;-)

Don't threaten me with a good time.

Also, it's already the case for AMDGPU or etnaviv, so I'm not sure what
Linus would have to say about it exactly.

Maxime
-------------- 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-arm-kernel/attachments/20231129/d546983c/attachment.sig>