On Fri, Dec 4, 2015 at 11:56 AM, Lucas Stach <l.stach@xxxxxxxxxxxxxx> wrote:
> Am Freitag, den 04.12.2015, 11:33 -0600 schrieb Rob Herring:
>> On Fri, Dec 4, 2015 at 10:41 AM, Lucas Stach <l.stach@xxxxxxxxxxxxxx> wrote:
>> > Am Freitag, den 04.12.2015, 10:29 -0600 schrieb Rob Herring:
>> >> On Fri, Dec 04, 2015 at 02:59:54PM +0100, Lucas Stach wrote:
>> >> > Etnaviv follows the same priciple as imx-drm to have a virtual
>> >> > master device node to bind all the individual GPU cores together
>> >> > into one DRM device.
>> >> >
>> >> > Signed-off-by: Lucas Stach <l.stach@xxxxxxxxxxxxxx>
>> >> > ---
>> >> > .../bindings/display/etnaviv/etnaviv-drm.txt | 46 ++++++++++++++++++++++
>> >> > 1 file changed, 46 insertions(+)
>> >> > create mode 100644 Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt
>> >> >
>> >> > diff --git a/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt b/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt
>> >> > new file mode 100644
>> >> > index 000000000000..19fde29dc1d7
>> >> > --- /dev/null
>> >> > +++ b/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt
>> >> > @@ -0,0 +1,46 @@
>> >> > +Etnaviv DRM master device
>> >> > +================================
>> >> > +
>> >> > +The Etnaviv DRM master device is a virtual device needed to list all
>> >> > +Vivante GPU cores that comprise the GPU subsystem.
>> >> > +
>> >> > +Required properties:
>> >> > +- compatible: Should be one of
>> >> > + "fsl,imx-gpu-subsystem"
>> >> > + "marvell,dove-gpu-subsystem"
>> >> > +- cores: Should contain a list of phandles pointing to Vivante GPU devices
>> >> > +
>> >> > +example:
>> >> > +
>> >> > +gpu-subsystem {
>> >> > + compatible = "fsl,imx-gpu-subsystem";
>> >> > + cores = <&gpu_2d>, <&gpu_3d>;
>> >> > +};
>> >>
>> >> Yeah, I'm not really a fan of doing this simply because DRM wants 1
>> >> driver.
>> >>
>> > I'm aware of that, but I don't see much value in kicking this discussion
>> > around for every DRM driver submission. This is the binding that has
>> > emerged from a lengthy discussion at KS 2013 in Edinburgh and at least
>> > allows us to standardize on _something_. Also ALSA does a similar thing
>> > to bind codecs and CPU interfaces together.
>>
>> This case is quite different though I think. The ALSA case and other
>> DRM cases are ones that have inter-dependencies between the blocks
>> (e.g. some sort of h/w connection). What is the inter-dependency here?
>>
>> Doing this way has also been found to be completely unnecessary and
>> removed in recent DRM driver reviews. Admittedly, those are cases
>> where one device can be the master of the others. For 2 parallel
>> devices, I don't have an alternative other than question why they need
>> to be a single driver.
>>
> If you insist on doing things differently for this driver, we could add
> a pass at driver registration that scans through the DT, looking for
> nodes matching the GPU core compatible.
I've not insisted on anything. I'm only asking a question which didn't
get answered. I'll ask another way. Why can't you have 2 instances of
the same driver given they are only rendering nodes?
> I'm not sure if that makes things cleaner though and might bite us later
> on. Also I'm not sure if moving away from the binding scheme already
> established for other DRM drivers makes things better from a DT
> perspective. Personally I would prefer DT binding consistency over
> perfection for single drivers, segmenting the DT binding space.
This is the least of our issues in terms of consistency among drivers,
but that is in fact what I'm pushing for. This is probably the first
case of a render only driver (at least for DT). So this isn't a case
of just follow what others are doing.
The h/w in this area can be quite different, so the DT bindings are
going to reflect that to some extent. A virtual node makes sense in
some cases, but for others it may not.
Rob
--
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
