Messages in this thread | | | From | Geert Uytterhoeven <> | Date | Wed, 29 Nov 2023 12:08:17 +0100 | 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@kernel.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@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@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 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@linux-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
| |