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
