[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <21696f2b-9321-4992-8a05-a4d8bf998e5b@linux.dev>
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
Powered by blists - more mailing lists