On Wed, Feb 07, 2024 at 10:35:49AM +0100, 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@xxxxxxxxx> > > Uh so my understanding is that drivers really shouldn't create platform > devices of their own. For this case here I think the aux-bus framework is > the right thing to use. Alternatively would be some infrastructure where > you feed a DT tree to driver core or pci subsystem and it instantiates it > all for you correctly, and especially with hotunplug all done right since > this is pci now, not actually part of the soc that cannot be hotunplugged. I don't think we need intermediate platform devices at all. We just need to register our GPU against the PCI device and that's it. We don't need a platform device, we don't need the component framework. > I think I've seen some other pci devices from arm soc designs that would > benefit from this too, so lifting this logic into a pci function would > make sense imo. Nouveau supports both iirc. Maxime
Attachment:
signature.asc
Description: PGP signature
