linux-kernel - Re: [etnaviv-next v13 7/7] drm/etnaviv: Add support for vivante GPU cores attached via PCI(e)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ad282cac-1455-4063-aa47-400c9ac07851@linux.dev>
Date: Wed, 7 Feb 2024 23:22:20 +0800
From: Sui Jingfeng <sui.jingfeng@...ux.dev>
To: Lucas Stach <l.stach@...gutronix.de>,
 Russell King <linux+etnaviv@...linux.org.uk>,
 Christian Gmeiner <christian.gmeiner@...il.com>,
 David Airlie <airlied@...il.com>, Maxime Ripard <mripard@...nel.org>,
 Thomas Zimmermann <tzimmermann@...e.de>, dri-devel@...ts.freedesktop.org,
 etnaviv@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: [etnaviv-next v13 7/7] drm/etnaviv: Add support for vivante GPU
 cores attached via PCI(e)

Hi,


On 2024/2/7 17:35, Daniel Vetter wrote:
> On Wed, Feb 07, 2024 at 01:27:59AM +0800, Sui Jingfeng wrote:
>> The component helper functions are the glue, which is used to bind multiple
>> GPU cores to a virtual master platform device. Which is fine and works well
>> for the SoCs who contains multiple GPU cores.
>>
>> The problem is that usperspace programs (such as X server and Mesa) will
>> search the PCIe device to use if it is exist. In other words, usperspace
>> programs open the PCIe device with higher priority. Creating a virtual
>> master platform device for PCI(e) GPUs is unnecessary, as the PCI device
>> has been created by the time drm/etnaviv is loaded.
>>
>> we create virtual platform devices as a representation for the vivante GPU
>> ip core. As all of subcomponent are attached via the PCIe master device,
>> we reflect this hardware layout by binding all of the virtual child to the
>> the real master.
>>
>> Signed-off-by: Sui Jingfeng <sui.jingfeng@...ux.dev>
> Uh so my understanding is that drivers really shouldn't create platform
> devices of their own.
>

Yes,

At least for DT-based systems, this driver can be modified
to let the core to create the virtual master for us. We don't
have to create platform devices by our own(refer to the drm/etnaviv
driver).

I means that we could put the following example device node
into the .dts file.


		gpu_2d: gpu@...00 {
			compatible = "vivante,gc";
			reg = <0xA0000 0x4000>;
		};

		gpu_3d: gpu@...00 {
			compatible = "vivante,gc";
			reg = <0x90000 0x4000>;
		};

		gpu@0 {
			compatible = "etnaviv";
			cores = <&gpu_2d &gpu_3d>;
			dma-coherent;
			dma-mask = <0xffffffff>
			virtual_master;
		};

But now, I'm afraid it's too late. Because the DTS/DTB may already have been
burned into board's BIOS for years. I guess, nowadays, modifying(changes)
this driver have to take the backward compatibility constraint into consideration.

Since we only have one chance to form the spec, that happens when this driver was
initially merged. Apparently, we miss it.