linux-kernel - Re: [etnaviv-next v14 0/8] drm/etnaviv: Add driver wrapper for vivante GPUs attached on PCI(e) device

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]

Date: Tue, 25 Jun 2024 19:06:17 +0800
From: Sui Jingfeng <sui.jingfeng@...ux.dev>
To: Icenowy Zheng <uwu@...nowy.me>, Lucas Stach <l.stach@...gutronix.de>
Cc: Russell King <linux+etnaviv@...linux.org.uk>,
 Christian Gmeiner <christian.gmeiner@...il.com>,
 linux-kernel@...r.kernel.org, etnaviv@...ts.freedesktop.org,
 dri-devel@...ts.freedesktop.org
Subject: Re: [etnaviv-next v14 0/8] drm/etnaviv: Add driver wrapper for
 vivante GPUs attached on PCI(e) device

Hi,

On 6/25/24 11:18, Icenowy Zheng wrote:
> 在 2024-05-20星期一的 00:53 +0800，Sui Jingfeng写道：
>> drm/etnaviv use the component framework to bind multiple GPU cores to
>> a
>> virtual master, the virtual master is manually create during driver
>> load
>> time. This works well for various SoCs, yet there are some PCIe card
>> has
>> the vivante GPU cores integrated. The driver lacks the support for
>> PCIe
>> devices currently.
>>
>> Adds PCIe driver wrapper on the top of what drm/etnaviv already has,
>> the
>> component framework is still being used to bind subdevices, even
>> though
>> there is only one GPU core. But the process is going to be reversed,
>> we
>> create virtual platform device for each of the vivante GPU IP core
>> shipped
>> by the PCIe master. The PCIe master is real, bind all the virtual
>> child
>> to the master with component framework.
>>
>>
>> v6:
>>          * Fix build issue on system without CONFIG_PCI enabled
>> v7:
>>          * Add a separate patch for the platform driver rearrangement
>> (Bjorn)
>>          * Switch to runtime check if the GPU is dma coherent or not
>> (Lucas)
>>          * Add ETNAVIV_PARAM_GPU_COHERENT to allow userspace to query
>> (Lucas)
>>          * Remove etnaviv_gpu.no_clk member (Lucas)
>>          * Fix Various typos and coding style fixed (Bjorn)
>> v8:
>>          * Fix typos and remove unnecessary header included (Bjorn).
>>          * Add a dedicated function to create the virtual master
>> platform
>>            device.
>> v9:
>>          * Use PCI_VDEVICE() macro (Bjorn)
>>          * Add trivial stubs for the PCI driver (Bjorn)
>>          * Remove a redundant dev_err() usage (Bjorn)
>>          * Clean up etnaviv_pdev_probe() with
>> etnaviv_of_first_available_node()
>> v10:
>>          * Add one more cleanup patch
>>          * Resolve the conflict with a patch from Rob
>>          * Make the dummy PCI stub inlined
>>          * Print only if the platform is dma-coherrent
>> V11:
>>          * Drop unnecessary changes (Lucas)
>>          * Tweak according to other reviews of v10.
>>
>> V12:
>>          * Create a virtual platform device for the subcomponent GPU
>> cores
>>          * Bind all subordinate GPU cores to the real PCI master via
>> component.
>>
>> V13:
>>          * Drop the non-component code path, always use the component
>> framework
>>            to bind subcomponent GPU core. Even though there is only
>> one core.
>>          * Defer the irq handler register.
>>          * Rebase and improve the commit message
>>
>> V14:
>>          * Rebase onto etnaviv-next and improve commit message.
>>
>> Tested with JD9230P GPU and LingJiu GP102 GPU.
> 
> BTW how should VRAM and displayed related parts be handled on these
> dGPUs?

Emm, I can only say I have no ideas.

Thanks for Christian's tested-by, but I'm a bit worry about if etnaviv
folks really like(or need) this. In the past, we started to contribute
before we know the policy/framework very well. I have to managed to
make things work before knowing the full picture. We developing drivers
in a rather rapid way and rather wild. Sometime, we do it just for fun. 
As the card don't has a usable driver, we want do something and we do
have already learned the framework and knowledge.

But now as we know a bit more, I actually don't intend to brings
concerns to other people. So only first 6 patch (or only part of them)
are requested to be merged, patch 0007 or patch 0008 can just leave it
there to be reviewed a bit longer if something is unsure.

Its totally up to etnaviv folks, I don't mind. Thanks for the nice
project.

-- 
Best regards
Sui