Message-ID: <CAMuHMdW2wCeHU+4HRoT_CM6noMzQjanmvMk5=Wg0t98tg9o1Qw@mail.gmail.com>
Date:   Wed, 29 Nov 2023 12:08:17 +0100
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     Maxime Ripard <mripard@...nel.org>
Cc:     Javier Martinez Canillas <javierm@...hat.com>,
        Frank Binns <frank.binns@...tec.com>,
        Donald Robson <donald.robson@...tec.com>,
        Matt Coster <matt.coster@...tec.com>,
        Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
        Thomas Zimmermann <tzimmermann@...e.de>,
        David Airlie <airlied@...il.com>,
        Daniel Vetter <daniel@...ll.ch>,
        Sarah Walker <sarah.walker@...tec.com>,
        Nishanth Menon <nm@...com>,
        Vignesh Raghavendra <vigneshr@...com>,
        Tero Kristo <kristo@...nel.org>, linux-kernel@...r.kernel.org,
        dri-devel@...ts.freedesktop.org,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH] drm/imagination: DRM_POWERVR should depend on ARCH_K3

Hi Maxime,

On Wed, Nov 29, 2023 at 11:50 AM Maxime Ripard <mripard@...nel.org> wrote:
> 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@...nel.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@...nel.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@...hat.com> wrote:
> > > > > > > Geert Uytterhoeven <geert+renesas@...der.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@...der.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.

OK, please tell me how to use it on e.g. R-Car Gen3.

> > > 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

The DT binding only lists "ti,am62-gpu" with "img,img-axe" as a fallback.

> are probably already there by the time you reach GPU enablement, and the
> DT doesn't have to be upstream.

And getting it upstream requires updating the bindings...

> > >   - 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.

Who added:

Documentation/devicetree/bindings/gpu/img,powervr.yaml-          - ti,am62-gpu
Documentation/devicetree/bindings/gpu/img,powervr.yaml:      - const:
img,img-axe # IMG AXE GPU model/revision is fully discoverable

?

> > 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.

Thanks for not checking ;-)

    if USB
    [...]
    source "drivers/usb/storage/Kconfig"

    config DRM_AMDGPU
            tristate "AMD GPU"
            depends on DRM && PCI && MMU

> 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...

That's why we use per-family options.  It's the next best thing we have.

> 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?

USB devices are (usually) truly generic, and can be plugged in
everywhere you see a USB port.

> > > 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.

AMDGPU is a PCI device, and can be plugged everywhere you see a PCI
slot.  Etnaviv could indeed use some dependencies...

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Powered by blists - more mailing lists