On Sat, Dec 05, 2015 at 12:26:19PM +0100, Lucas Stach wrote: > I already sketched up the alternative of having the master driver scan > the DT for matching GPU nodes at probe time and binding them together > into a single device. But given that we end up with one master device > anyways, do you really prefer this over the virtual node, which is a > working and proven solution to this exact problem? I really don't think that would be a sane approach for several reasons: 1. We end up with a load of platform devices which are just dangling. 2. We lose the ability to runtime PM manage each GPU core separately, along with the PM domain infrastructure to manage the separate GPU power domains, as we wouldn't be able to bind to the individual struct devices. 3. We still need some kind of master struct device to trigger the registration of devices, and to act as the struct device for DRM and DMA allocations. I can't see any advantages to such an approach, only downsides. Hence, I'd say that such an approach is completely unsuitable - especially as the 3D GPUs consume much more power than their 2D counterparts, so it's very advantageous to have the individual GPU core power management that the current structure elegantly gives us. To do the above, we'd probably have to re-implement our own private per-GPU runtime PM infrastructure, and somehow couple that into the PM domains stuff - or even bring the SoC specific PM domain manipulation into the GPU driver. The only way I can see around that would be to keep the existing driver structure, but have a non-driver shim which scans the DT and is responsible for creating the platform devices - duplicating in effect what the platform device code in drivers/of is already doing but specifically for this driver. It'd also be responsible for creating the master device as well. In other words, it would be a half-way between DT and non-DT solutions: DT would be dealt with in the shim layer and the etnaviv driver itself would effectively know nothing about DT. -- FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
