Hi Maxime,
On Wed, Nov 29, 2023 at 12:34 PM Maxime Ripard <mripard@xxxxxxxxxx> wrote:
> On Wed, Nov 29, 2023 at 12:08:17PM +0100, Geert Uytterhoeven wrote:
> > On Wed, Nov 29, 2023 at 11:50 AM Maxime Ripard <mripard@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxx> wrote:
> > > > > > > > > Geert Uytterhoeven <geert+renesas@xxxxxxxxx> 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@xxxxxxxxx>
> > > > > >
> > > > > > > > > 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 very familiar with the R-Car family of SoCs.
>
> However, if I'm to trust that page: https://www.renesas.com/us/en/products/automotive-products/automotive-system-chips-socs
>
> None of them feature the same GPU than the AM62x, so that question is
> completely different?
According to the documentation I have, they contain PowerVR Series6XT
or Series7XE GPUs.
DRM_POWERVR claims to support "Imagination Technologies PowerVR
(Series 6 or later) or IMG GPU".
> > > > > 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.
>
> Sure. And the driver matches on img,img-axe, so it would probe fine even
> with a different first compatible.
>
> > > 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...
>
> Right. And you still don't have to put it upstream, so the binding isn't
> a requirement either.
Oh, how we love out-of-tree...
> > > > > - 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
> >
> > ?
>
> Which is a formality, part of the upstreaming process, but not required
> at all from a technical point of view to make a driver probe.
>
> > > > 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
>
> I'm not seeing any platform Kconfig option there.
There is no need for platform dependencies here because USB and PCI
are better gatekeepers.
> Most importantly, you were arguing that the GPU should be enabled only
s/enabled/visible/
> on systems where the GPU is in the SoC, with a firmware in
> linux-firmware, and the DT bits in.
For now, because it is really only supported on AM62x
If that claim is false, please tell me on which other platform it works.
> And you're now making it equivalent to "the framework handling that
> device is compiled in", which I fully agree with: of course a USB device
> driver should only be compiled if the USB framework is there.
>
> But "having the framework compiled" and "a controller is functional on a
> platform" is completely different, and you know that very well otherwise
> you wouldn't have sent that patch in the first place.
DRM is the framework.
DRM_POWERVR is a driver for hardware that can only be used
(for now) on a very limited platform subset.
> > AMDGPU is a PCI device, and can be plugged everywhere you see a PCI
> > slot. Etnaviv could indeed use some dependencies...
>
> It might be plugged in any PCIe slot. It will not work with any PCIe
> controller.
Why not?
> Anyway, there's no point in discussing it further. We're at the point of
> sending blank threats so it's not super productive anyway.
>
> As far as I'm concerned, and if there's no new actual technical
> argument,
Linus has stated multiple times he does not want to see Kconfig
options that do not make sense and/or cannot be sued. Such options
are wasting everyone's time.
> NAK.
Oh well...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
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
