Re: [PATCH 02/12] drm/etnaviv: add devicetree bindings

[Russell King - ARM Linux <linux@arm.linux.org.uk>]

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.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel