From: Lucas Stach <hidden> Date: 2015-12-04 13:59:54
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 <redacted>
---
.../bindings/display/etnaviv/etnaviv-drm.txt | 46 ++++++++++++++++++++++
1 file changed, 46 insertions(+)
create mode 100644 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>;+};+++Vivante GPU core devices+====================++Required properties:+- compatible: Should be "vivante,gc"+- reg: should be register base and length as documented in the+ datasheet+- interrupts: Should contain the cores interrupt line+- clocks: should contain one clock for entry in clock-names+ see Documentation/devicetree/bindings/clock/clock-bindings.txt+- clock-names:+ - "bus": AXI/register clock+ - "core": GPU core clock+ - "shader": Shader clock (only required if GPU has feature PIPE_3D)++example:++gpu_3d: gpu@00130000 {+ compatible = "vivante,gc";+ reg = <0x00130000 0x4000>;+ interrupts = <0 9 IRQ_TYPE_LEVEL_HIGH>;+ clocks = <&clks IMX6QDL_CLK_GPU3D_AXI>,+ <&clks IMX6QDL_CLK_GPU3D_CORE>,+ <&clks IMX6QDL_CLK_GPU3D_SHADER>;+ clock-names = "bus", "core", "shader";+};
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Rob Herring <robh@kernel.org> Date: 2015-12-04 16:29:56
On Fri, Dec 04, 2015 at 02:59:54PM +0100, Lucas Stach wrote:
quoted hunk
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@pengutronix.de>
---
.../bindings/display/etnaviv/etnaviv-drm.txt | 46 ++++++++++++++++++++++
1 file changed, 46 insertions(+)
create mode 100644 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.
+
+
+Vivante GPU core devices
+====================
+
+Required properties:
+- compatible: Should be "vivante,gc"
This should at least have the specific cores listed like gc-5000 or
whatever the numbering is. As is, I can't even tell if this a 2d or 3d
core.
Also, it probably should have an SOC specific property to deal with SOC
specific configuration or integration.
+- reg: should be register base and length as documented in the
+ datasheet
+- interrupts: Should contain the cores interrupt line
+- clocks: should contain one clock for entry in clock-names
+ see Documentation/devicetree/bindings/clock/clock-bindings.txt
+- clock-names:
+ - "bus": AXI/register clock
+ - "core": GPU core clock
+ - "shader": Shader clock (only required if GPU has feature PIPE_3D)
+
+example:
+
+gpu_3d: gpu@00130000 {
+ compatible = "vivante,gc";
+ reg = <0x00130000 0x4000>;
+ interrupts = <0 9 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks IMX6QDL_CLK_GPU3D_AXI>,
+ <&clks IMX6QDL_CLK_GPU3D_CORE>,
+ <&clks IMX6QDL_CLK_GPU3D_SHADER>;
+ clock-names = "bus", "core", "shader";
+};
--
2.6.2
From: Lucas Stach <l.stach@pengutronix.de> Date: 2015-12-04 16:41:45
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:
quoted
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@pengutronix.de>
---
.../bindings/display/etnaviv/etnaviv-drm.txt | 46 ++++++++++++++++++++++
1 file changed, 46 insertions(+)
create mode 100644 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.
quoted
+
+
+Vivante GPU core devices
+====================
+
+Required properties:
+- compatible: Should be "vivante,gc"
This should at least have the specific cores listed like gc-5000 or
whatever the numbering is. As is, I can't even tell if this a 2d or 3d
core.
There is really no need for this. The cores have identification
registers that are much more accurate than what we could describe with a
compatible value. So using a more specific compatible just provides
redundant (and possibly wrong) information.
Also, it probably should have an SOC specific property to deal with SOC
specific configuration or integration.
Same as above really. Parts of the identification registers are
different for each SoC integration, even if it's the same IP core, so we
can just derive any needed driver behavior differences from that.
quoted
+- reg: should be register base and length as documented in the
+ datasheet
+- interrupts: Should contain the cores interrupt line
+- clocks: should contain one clock for entry in clock-names
+ see Documentation/devicetree/bindings/clock/clock-bindings.txt
+- clock-names:
+ - "bus": AXI/register clock
+ - "core": GPU core clock
+ - "shader": Shader clock (only required if GPU has feature PIPE_3D)
+
+example:
+
+gpu_3d: gpu@00130000 {
+ compatible = "vivante,gc";
+ reg = <0x00130000 0x4000>;
+ interrupts = <0 9 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks IMX6QDL_CLK_GPU3D_AXI>,
+ <&clks IMX6QDL_CLK_GPU3D_CORE>,
+ <&clks IMX6QDL_CLK_GPU3D_SHADER>;
+ clock-names = "bus", "core", "shader";
+};
--
2.6.2
From: Russell King - ARM Linux <hidden> Date: 2015-12-04 16:56:17
On Fri, Dec 04, 2015 at 10:29:56AM -0600, Rob Herring wrote:
On Fri, Dec 04, 2015 at 02:59:54PM +0100, Lucas Stach wrote:
quoted
+Vivante GPU core devices
+====================
+
+Required properties:
+- compatible: Should be "vivante,gc"
This should at least have the specific cores listed like gc-5000 or
whatever the numbering is. As is, I can't even tell if this a 2d or 3d
core.
Who cares whether it's a 2D or 3D core? There are four options here:
2D
2D and 3D
3D
VG
All of these are determined by feature flags in the core - why should
DT have to specify this information when the hardware tells us, just
because we want something humanly visible?
Also, it probably should have an SOC specific property to deal with SOC
specific configuration or integration.
Thus far, we're not aware of any SoC specific configuration of the
core. Even if there was, I can't see it making much difference to
the DRM driver itself: the DRM driver mostly about command stream
queuing, GEM buffer management (both of which are independent of SoC
issues) and PM management, which is performed via runtime PM.
Where SoC specific integration would come in is the runtime PM, and
that goes as far as what clocks are present, which we already deal
with, power domains, which again we already deal with, and
interrupts - again, which are dealt with.
Given that this driver has been developed on two SoCs (Dove and iMX6)
which are radically different, I can't see any need for other SoC
specifics.
Did you have anything in mind?
Dove:
GC600 combined 2D and 3D GPU core, one clock, one interrupt, one PM
domain.
iMX6 S/DL/D/Q:
GC320 2D GPU core, GC880 or GC2000 3D GPU core, GC335 VG core, multiple
clocks, multiple interrupts, multiple PM domains.
--
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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
Absolutely, this is the interface and method that was discussed and
settled upon, and for DT folk to now start saying that they're not
fans of it is _far_ too late. If they had concerns, they should have
been discussed during the submission of the first users of it, not
after the 4th or 5th user.
Sure, they may be having reservations about it, but then, I think,
it's up to them to come up with a better solution to this, and discuss
it over with the DRM people, remembering that the DRM people are very
adamant that they're not budging on the "not hotplugging bits" issue,
or if they do, it means _radically_ changing the DRM user API for
everything.
quoted
Also, it probably should have an SOC specific property to deal with SOC
specific configuration or integration.
Same as above really. Parts of the identification registers are
different for each SoC integration, even if it's the same IP core,
so we can just derive any needed driver behavior differences from
that.
I agree. There are some bugs in various cores (like the GC320) but
it's not clear whether that's a SoC specific issue or whether it's a
GPU core specific issue: all we know is that GC320 revision X suffers
from a certain bug, which we need to work around in userspace - and as
we pass all the GPU identifying information to userspace, adding such
stuff into DT, and then having to find some way to pass it through to
userspace would just add a whole new level of complexity that isn't
required.
It'd be a case of "okay, we know iMX6 has a GC320 with revision X,
so we better set DT flag Y to indicate that it has this bug" when we
already know in userspace that it's a GC320 revision X and userspace
needs to generate the command stream differently based on that.
So, it seems completely pointless to encode this information in 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
From: Rob Herring <robh@kernel.org> Date: 2015-12-04 17:33:22
On Fri, Dec 4, 2015 at 10:41 AM, Lucas Stach [off-list ref] wrote:
Am Freitag, den 04.12.2015, 10:29 -0600 schrieb Rob Herring:
quoted
On Fri, Dec 04, 2015 at 02:59:54PM +0100, Lucas Stach wrote:
quoted
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@pengutronix.de>
---
.../bindings/display/etnaviv/etnaviv-drm.txt | 46 ++++++++++++++++++++++
1 file changed, 46 insertions(+)
create mode 100644 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.
quoted
quoted
+Vivante GPU core devices
+====================
+
+Required properties:
+- compatible: Should be "vivante,gc"
This should at least have the specific cores listed like gc-5000 or
whatever the numbering is. As is, I can't even tell if this a 2d or 3d
core.
There is really no need for this. The cores have identification
registers that are much more accurate than what we could describe with a
compatible value. So using a more specific compatible just provides
redundant (and possibly wrong) information.
quoted
Also, it probably should have an SOC specific property to deal with SOC
specific configuration or integration.
Same as above really. Parts of the identification registers are
different for each SoC integration, even if it's the same IP core, so we
can just derive any needed driver behavior differences from that.
The h/w designers must have had a clue about s/w. First time for
everything... ;)
Ok, please just add a note to the binding why a more specific
compatible is not needed in this case.
Rob
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
From: Lucas Stach <l.stach@pengutronix.de> Date: 2015-12-04 17:56:00
Am Freitag, den 04.12.2015, 11:33 -0600 schrieb Rob Herring:
On Fri, Dec 4, 2015 at 10:41 AM, Lucas Stach [off-list ref] wrote:
quoted
Am Freitag, den 04.12.2015, 10:29 -0600 schrieb Rob Herring:
quoted
On Fri, Dec 04, 2015 at 02:59:54PM +0100, Lucas Stach wrote:
quoted
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@pengutronix.de>
---
.../bindings/display/etnaviv/etnaviv-drm.txt | 46 ++++++++++++++++++++++
1 file changed, 46 insertions(+)
create mode 100644 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'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.
Regards,
Lucas
--
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions | http://www.pengutronix.de/ |
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
From: Rob Herring <robh@kernel.org> Date: 2015-12-04 20:19:42
On Fri, Dec 4, 2015 at 11:56 AM, Lucas Stach [off-list ref] wrote:
Am Freitag, den 04.12.2015, 11:33 -0600 schrieb Rob Herring:
quoted
On Fri, Dec 4, 2015 at 10:41 AM, Lucas Stach [off-list ref] wrote:
quoted
Am Freitag, den 04.12.2015, 10:29 -0600 schrieb Rob Herring:
quoted
On Fri, Dec 04, 2015 at 02:59:54PM +0100, Lucas Stach wrote:
quoted
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@pengutronix.de>
---
.../bindings/display/etnaviv/etnaviv-drm.txt | 46 ++++++++++++++++++++++
1 file changed, 46 insertions(+)
create mode 100644 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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
From: Russell King - ARM Linux <hidden> Date: 2015-12-04 20:31:01
On Fri, Dec 04, 2015 at 02:19:42PM -0600, Rob Herring wrote:
On Fri, Dec 4, 2015 at 11:56 AM, Lucas Stach [off-list ref] wrote:
quoted
Am Freitag, den 04.12.2015, 11:33 -0600 schrieb Rob Herring:
quoted
On Fri, Dec 4, 2015 at 10:41 AM, Lucas Stach [off-list ref] wrote:
quoted
Am Freitag, den 04.12.2015, 10:29 -0600 schrieb Rob Herring:
quoted
On Fri, Dec 04, 2015 at 02:59:54PM +0100, Lucas Stach wrote:
quoted
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@pengutronix.de>
---
.../bindings/display/etnaviv/etnaviv-drm.txt | 46 ++++++++++++++++++++++
1 file changed, 46 insertions(+)
create mode 100644 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?
Sorry, but it _did_ get answered - I answered that in my reply to you.
I'll repeat it again, but more briefly, and then expand on it: it's what
userspace like Xorg DRI2 and MESA want.
Yes, there's DRI3, which is more modern and in theory allows multiple
renderers to be opened by the client, but so far I fail to see how that
can work with a separate KMS DRM driver. It _may_ be intended to, but
the problem I see here is that when you have the KMS hardware only
capable of scanning out linear buffers, but the GPU hardware is only
capable of rendering to tiled buffers, there needs to be some way to
allocate KMS buffers in the client, and right now I don't see any way
to know what the KMS DRM device being used is in the DRI3/Present Xorg
extensions.
Moreover, DRI3 is not yet available for Gallium, so if we're talking
about Xorg, then functional DRI2 is a requirement, and that _needs_
to have a single device for the rendering instances. Xorg has no way
to pass multiple render nodes to client over DRI2.
--
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
From: Lucas Stach <l.stach@pengutronix.de> Date: 2015-12-05 11:26:19
Am Freitag, den 04.12.2015, 14:19 -0600 schrieb Rob Herring:
On Fri, Dec 4, 2015 at 11:56 AM, Lucas Stach [off-list ref]
wrote:
quoted
Am Freitag, den 04.12.2015, 11:33 -0600 schrieb Rob Herring:
quoted
On Fri, Dec 4, 2015 at 10:41 AM, Lucas Stach <l.stach@pengutronix
.de> wrote:
quoted
Am Freitag, den 04.12.2015, 10:29 -0600 schrieb Rob Herring:
quoted
On Fri, Dec 04, 2015 at 02:59:54PM +0100, Lucas Stach wrote:
quoted
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@pengutronix.de>
---
.../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
@@ -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?
quoted
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.
I see where you are going here and I appreciate that this discussion
isn't a exercise in bikeshed, but based on technical facts.
So let me try to explain things from the other way around:
We made the decision to have a single DRM device for all the Vivante
GPU nodes in a system based on technical merits, not because DRM wants
us to do this, but because it has practical upsides for the
implementation of the driver.
1. It makes buffer and management and information sharing between the
cores that are likely to be used together vastly easier for the use-
cases seen today. Having one DRM device per core would be possible, but
would make things a lot harder implementation wise.
2. It will allow us to share resources such as the GPU page tables,
once we move to per-client address spaces, reducing the footprint of
memory that we need to allocate out of CMA.
3. It makes submit fencing look the same regardless of the core
configuration. There are configurations where a 2D and a 3D core are
sitting behind a shared frontend (Dove) and some where each engine has
it's own frontend (i.MX6). Having a single DRM driver allows us to make
both configurations look the same to userspace from a fencing
perspective.
There are probably some more arguments that have escaped the top of my
head right now. Regardless of how the DT bindings end up, we won't move
away from the single DRM device design.
So the question is: given the above, are you opposed to having a
virtual node in DT to describe this master device?
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?
Regards,
Lucas
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
From: Russell King - ARM Linux <hidden> Date: 2015-12-05 12:17:41
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