[PATCH v5 3/6] arm64: dts: exynos: add micro-USB connector node to TM2 platforms

[Andrzej Hajda]

Since USB connector bindings are available we can describe it on TM2(e).

Signed-off-by: Andrzej Hajda 
---
 arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
index 0b61dda99569..f604f6b1a9c2 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
@@ -836,6 +836,13 @@
 
muic: max77843-muic {
compatible = "maxim,max77843-muic";
+
+   musb_con: musb_connector {
+   compatible = "samsung,usb-connector-11pin",
+"usb-b-connector";
+   label = "micro-USB";
+   type = "micro";
+   };
};
 
regulators {
-- 
2.16.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 4/6] arm64: dts: exynos: add OF graph between MHL and USB connector

[Andrzej Hajda]

OF graph describes MHL data lanes between MHL and respective USB
connector.

Signed-off-by: Andrzej Hajda 
---
v5: removed extra parenthesis (kbuild test robot)
v4: added missing reg property in connector's port node (Krzysztof)
---
 .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 31 +++---
 1 file changed, 28 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
index f604f6b1a9c2..03453b822093 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
@@ -817,9 +817,22 @@
clocks = <_system_controller 0>;
clock-names = "xtal";
 
-   port {
-   mhl_to_hdmi: endpoint {
-   remote-endpoint = <_to_mhl>;
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   mhl_to_hdmi: endpoint {
+   remote-endpoint = <_to_mhl>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+   mhl_to_musb_con: endpoint {
+   remote-endpoint = <_con_to_mhl>;
+   };
};
};
};
@@ -842,6 +855,18 @@
 "usb-b-connector";
label = "micro-USB";
type = "micro";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@3 {
+   reg = <3>;
+   musb_con_to_mhl: endpoint {
+   remote-endpoint = 
<_to_musb_con>;
+   };
+   };
+   };
};
};
 
-- 
2.16.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 1/6] dt-bindings: add bindings for USB physical connector

[Andrzej Hajda]

These bindings allow to describe most known standard USB connectors
and it should be possible to extend it if necessary.
USB connectors, beside USB can be used to route other protocols,
for example UART, Audio, MHL. In such case every device passing data
through the connector should have appropriate graph bindings.

Signed-off-by: Andrzej Hajda 
---
v4:
- improved 'type' description (Rob),
- improved description of 2nd example (Rob).
v3:
- removed MHL port (samsung connector will have separate bindings),
- added 2nd example for USB-C,
- improved formatting.
v2:
- moved connector type(A,B,C) to compatible string (Rob),
- renamed size property to type (Rob),
- changed type description to be less confusing (Laurent),
- removed vendor specific compatibles (implied by graph port number),
- added requirement of connector being a child of IC (Rob),
- removed max-mode (subtly suggested by Rob, it should be detected anyway
  by USB Controller in runtime, downside is that device is not able to
  report its real capabilities, maybe better would be to make it optional(?)),
- assigned port numbers to data buses (Rob).

Regards
Andrzej
---
 .../bindings/connector/usb-connector.txt   | 75 ++
 1 file changed, 75 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/connector/usb-connector.txt

diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt 
b/Documentation/devicetree/bindings/connector/usb-connector.txt
new file mode 100644
index ..e1463f14af38
--- /dev/null
+++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
@@ -0,0 +1,75 @@
+USB Connector
+=
+
+USB connector node represents physical USB connector. It should be
+a child of USB interface controller.
+
+Required properties:
+- compatible: describes type of the connector, must be one of:
+"usb-a-connector",
+"usb-b-connector",
+"usb-c-connector".
+
+Optional properties:
+- label: symbolic name for the connector,
+- type: size of the connector, should be specified in case of USB-A, USB-B
+  non-fullsize connectors: "mini", "micro".
+
+Required nodes:
+- any data bus to the connector should be modeled using the OF graph bindings
+  specified in bindings/graph.txt, unless the bus is between parent node and
+  the connector. Since single connector can have multpile data buses every bus
+  has assigned OF graph port number as follows:
+0: High Speed (HS), present in all connectors,
+1: Super Speed (SS), present in SS capable connectors,
+2: Sideband use (SBU), present in USB-C.
+
+Examples
+
+
+1. Micro-USB connector with HS lines routed via controller (MUIC):
+
+muic-max77843@66 {
+   ...
+   usb_con: connector {
+   compatible = "usb-b-connector";
+   label = "micro-USB";
+   type = "micro";
+   };
+};
+
+2. USB-C connector attached to CC controller (s2mm005), HS lines routed
+to companion PMIC (max77865), SS lines to USB3 PHY and SBU to DisplayPort.
+DisplayPort video lines are routed to the connector via SS mux in USB3 PHY.
+
+ccic: s2mm005@33 {
+   ...
+   usb_con: connector {
+   compatible = "usb-c-connector";
+   label = "USB-C";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   usb_con_hs: endpoint {
+   remote-endpoint = <_usbc_hs>;
+   };
+   };
+   port@1 {
+   reg = <1>;
+   usb_con_ss: endpoint {
+   remote-endpoint = <_phy_ss>;
+   };
+   };
+   port@2 {
+   reg = <2>;
+   usb_con_sbu: endpoint {
+   remote-endpoint = <_aux>;
+   };
+   };
+   };
+   };
+};
-- 
2.16.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 2/6] dt-bindings: add bindings for Samsung micro-USB 11-pin connector

[Andrzej Hajda]

Samsung micro-USB 11-pin connector beside standard micro-USB pins,
has pins dedicated to route MHL traffic.

Signed-off-by: Andrzej Hajda 
Reviewed-by: Rob Herring 
---
v4:
- removed description of property inherited from usb-connector (Rob),
- fixed example description.
---
 .../connector/samsung,usb-connector-11pin.txt  | 49 ++
 1 file changed, 49 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/connector/samsung,usb-connector-11pin.txt

diff --git 
a/Documentation/devicetree/bindings/connector/samsung,usb-connector-11pin.txt 
b/Documentation/devicetree/bindings/connector/samsung,usb-connector-11pin.txt
new file mode 100644
index ..22256e295a7a
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/connector/samsung,usb-connector-11pin.txt
@@ -0,0 +1,49 @@
+Samsung micro-USB 11-pin connector
+==
+
+Samsung micro-USB 11-pin connector is an extension of micro-USB connector.
+It is present in multiple Samsung mobile devices.
+It has additional pins to route MHL traffic simultanously with USB.
+
+The bindings are superset of usb-connector bindings for micro-USB connector[1].
+
+Required properties:
+- compatible: must be: "samsung,usb-connector-11pin", "usb-b-connector",
+- type: must be "micro".
+
+Required nodes:
+- any data bus to the connector should be modeled using the OF graph bindings
+  specified in bindings/graph.txt, unless the bus is between parent node and
+  the connector. Since single connector can have multpile data buses every bus
+  has assigned OF graph port number as follows:
+0: High Speed (HS),
+3: Mobile High-Definition Link (MHL), specific to 11-pin Samsung micro-USB.
+
+[1]: bindings/connector/usb-connector.txt
+
+Example
+---
+
+Micro-USB connector with HS lines routed via controller (MUIC) and MHL lines
+connected to HDMI-MHL bridge (sii8620):
+
+muic-max77843@66 {
+   ...
+   usb_con: connector {
+   compatible = "samsung,usb-connector-11pin", "usb-b-connector";
+   label = "micro-USB";
+   type = "micro";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@3 {
+   reg = <3>;
+   usb_con_mhl: endpoint {
+   remote-endpoint = <_mhl>;
+   };
+   };
+   };
+   };
+};
-- 
2.16.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 6/6] drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL

[Andrzej Hajda]

From: Maciej Purski 

Currently MHL chip must be turned on permanently to detect MHL cable. It
duplicates micro-USB controller's (MUIC) functionality and consumes
unnecessary power. Lets use extcon attached to MUIC to enable MHL chip
only if it detects MHL cable.

Signed-off-by: Maciej Purski 
Signed-off-by: Andrzej Hajda 
---
v5: updated extcon API

This is rework of the patch by Maciej with following changes:
- use micro-USB port bindings to get extcon, instead of extcon property,
- fixed remove sequence,
- fixed extcon get state logic.

Code finding extcon node is hacky IMO, I guess ultimately it should be done
via some framework (maybe even extcon), or at least via helper, I hope it
can stay as is until the proper solution will be merged.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/bridge/sil-sii8620.c | 97 ++--
 1 file changed, 94 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
index 9e785b8e0ea2..62b0adabcac2 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -17,6 +17,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -25,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -81,6 +83,10 @@ struct sii8620 {
struct edid *edid;
unsigned int gen2_write_burst:1;
enum sii8620_mt_state mt_state;
+   struct extcon_dev *extcon;
+   struct notifier_block extcon_nb;
+   struct work_struct extcon_wq;
+   int cable_state;
struct list_head mt_queue;
struct {
int r_size;
@@ -2175,6 +2181,77 @@ static void sii8620_init_rcp_input_dev(struct sii8620 
*ctx)
ctx->rc_dev = rc_dev;
 }
 
+static void sii8620_cable_out(struct sii8620 *ctx)
+{
+   disable_irq(to_i2c_client(ctx->dev)->irq);
+   sii8620_hw_off(ctx);
+}
+
+static void sii8620_extcon_work(struct work_struct *work)
+{
+   struct sii8620 *ctx =
+   container_of(work, struct sii8620, extcon_wq);
+   int state = extcon_get_state(ctx->extcon, EXTCON_DISP_MHL);
+
+   if (state == ctx->cable_state)
+   return;
+
+   ctx->cable_state = state;
+
+   if (state > 0)
+   sii8620_cable_in(ctx);
+   else
+   sii8620_cable_out(ctx);
+}
+
+static int sii8620_extcon_notifier(struct notifier_block *self,
+   unsigned long event, void *ptr)
+{
+   struct sii8620 *ctx =
+   container_of(self, struct sii8620, extcon_nb);
+
+   schedule_work(>extcon_wq);
+
+   return NOTIFY_DONE;
+}
+
+static int sii8620_extcon_init(struct sii8620 *ctx)
+{
+   struct extcon_dev *edev;
+   struct device_node *musb, *muic;
+   int ret;
+
+   /* get micro-USB connector node */
+   musb = of_graph_get_remote_node(ctx->dev->of_node, 1, -1);
+   /* next get micro-USB Interface Controller node */
+   muic = of_get_next_parent(musb);
+
+   if (!muic) {
+   dev_info(ctx->dev, "no extcon found, switching to 'always on' 
mode\n");
+   return 0;
+   }
+
+   edev = extcon_find_edev_by_node(muic);
+   of_node_put(muic);
+   if (IS_ERR(edev)) {
+   if (PTR_ERR(edev) == -EPROBE_DEFER)
+   return -EPROBE_DEFER;
+   dev_err(ctx->dev, "Invalid or missing extcon\n");
+   return PTR_ERR(edev);
+   }
+
+   ctx->extcon = edev;
+   ctx->extcon_nb.notifier_call = sii8620_extcon_notifier;
+   INIT_WORK(>extcon_wq, sii8620_extcon_work);
+   ret = extcon_register_notifier(edev, EXTCON_DISP_MHL, >extcon_nb);
+   if (ret) {
+   dev_err(ctx->dev, "failed to register notifier for MHL\n");
+   return ret;
+   }
+
+   return 0;
+}
+
 static inline struct sii8620 *bridge_to_sii8620(struct drm_bridge *bridge)
 {
return container_of(bridge, struct sii8620, bridge);
@@ -2307,13 +2384,20 @@ static int sii8620_probe(struct i2c_client *client,
if (ret)
return ret;
 
+   ret = sii8620_extcon_init(ctx);
+   if (ret < 0) {
+   dev_err(ctx->dev, "failed to initialize EXTCON\n");
+   return ret;
+   }
+
i2c_set_clientdata(client, ctx);
 
ctx->bridge.funcs = _bridge_funcs;
ctx->bridge.of_node = dev->of_node;
drm_bridge_add(>bridge);
 
-   sii8620_cable_in(ctx);
+   if (!ctx->extcon)
+   sii8620_cable_in(ctx);
 
return 0;
 }
@@ -2322,8 +2406,15 @@ static int sii8620_remove(struct i2c_client *client)
 {
struct sii8620 *ctx = i2c_get_clientdata(client);
 
-   disable_irq(to_i2c_client(ctx->dev)->irq);
-   sii8620_hw_off(ctx);
+   if (ctx->extcon) {
+   extcon_unregister_notifier(ctx->extcon, EXTCON_DISP_MHL,
+ 

[PATCH v5 0/6] dt-bindings: add bindings for USB physical connector

[Andrzej Hajda]

Hi,

Thanks for reviews of previous iterations.

This patchset introduces USB physical connector bindings, together with
working example.
I have removed RFC prefix - the patchset seems to be heading
to a happy end :)

v5: fixed extra parenthesis in dts, renamed extcon function.
v4: improved binding descriptions, added missing reg in dts.
v3: Separate binding for Samsung 11-pin connector, added full-blown USB-C
example.
v2: I have addressed comments by Rob and Laurent, thanks 

Changes in datail are described in the patches.

Regards
Andrzej


Andrzej Hajda (5):
  dt-bindings: add bindings for USB physical connector
  dt-bindings: add bindings for Samsung micro-USB 11-pin connector
  arm64: dts: exynos: add micro-USB connector node to TM2 platforms
  arm64: dts: exynos: add OF graph between MHL and USB connector
  extcon: add possibility to get extcon device by OF node

Maciej Purski (1):
  drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL

 .../connector/samsung,usb-connector-11pin.txt  | 49 +++
 .../bindings/connector/usb-connector.txt   | 75 +
 .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 38 -
 drivers/extcon/extcon.c| 44 +++---
 drivers/gpu/drm/bridge/sil-sii8620.c   | 97 +-
 include/linux/extcon.h |  6 ++
 6 files changed, 293 insertions(+), 16 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/connector/samsung,usb-connector-11pin.txt
 create mode 100644 
Documentation/devicetree/bindings/connector/usb-connector.txt

-- 
2.16.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 5/6] extcon: add possibility to get extcon device by OF node

[Andrzej Hajda]

Since extcon property is not allowed in DT, extcon subsystem requires
another way to get extcon device. Lets try the simplest approach - get
edev by of_node.

Signed-off-by: Andrzej Hajda 
Acked-by: Chanwoo Choi 
---
v5: function renamed to extcon_find_edev_by_node (Andy)
v2: changed label to follow local convention (Chanwoo)
---
 drivers/extcon/extcon.c | 44 ++--
 include/linux/extcon.h  |  6 ++
 2 files changed, 40 insertions(+), 10 deletions(-)

diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
index cb38c2747684..47a5ca9eb86d 100644
--- a/drivers/extcon/extcon.c
+++ b/drivers/extcon/extcon.c
@@ -1336,6 +1336,28 @@ void extcon_dev_unregister(struct extcon_dev *edev)
 EXPORT_SYMBOL_GPL(extcon_dev_unregister);
 
 #ifdef CONFIG_OF
+
+/*
+ * extcon_find_edev_by_node - Find the extcon device from devicetree.
+ * @node   : OF node identyfying edev
+ *
+ * Return the pointer of extcon device if success or ERR_PTR(err) if fail.
+ */
+struct extcon_dev *extcon_find_edev_by_node(struct device_node *node)
+{
+   struct extcon_dev *edev;
+
+   mutex_lock(_dev_list_lock);
+   list_for_each_entry(edev, _dev_list, entry)
+   if (edev->dev.parent && edev->dev.parent->of_node == node)
+   goto out;
+   edev = ERR_PTR(-EPROBE_DEFER);
+out:
+   mutex_unlock(_dev_list_lock);
+
+   return edev;
+}
+
 /*
  * extcon_get_edev_by_phandle - Get the extcon device from devicetree.
  * @dev: the instance to the given device
@@ -1363,25 +1385,27 @@ struct extcon_dev *extcon_get_edev_by_phandle(struct 
device *dev, int index)
return ERR_PTR(-ENODEV);
}
 
-   mutex_lock(_dev_list_lock);
-   list_for_each_entry(edev, _dev_list, entry) {
-   if (edev->dev.parent && edev->dev.parent->of_node == node) {
-   mutex_unlock(_dev_list_lock);
-   of_node_put(node);
-   return edev;
-   }
-   }
-   mutex_unlock(_dev_list_lock);
+   edev = extcon_find_edev_by_node(node);
of_node_put(node);
 
-   return ERR_PTR(-EPROBE_DEFER);
+   return edev;
 }
+
 #else
+
+struct extcon_dev *extcon_find_edev_by_node(struct device_node *node)
+{
+   return ERR_PTR(-ENOSYS);
+}
+
 struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev, int index)
 {
return ERR_PTR(-ENOSYS);
 }
+
 #endif /* CONFIG_OF */
+
+EXPORT_SYMBOL_GPL(extcon_find_edev_by_node);
 EXPORT_SYMBOL_GPL(extcon_get_edev_by_phandle);
 
 /**
diff --git a/include/linux/extcon.h b/include/linux/extcon.h
index 6d94e82c8ad9..7f033b1ea568 100644
--- a/include/linux/extcon.h
+++ b/include/linux/extcon.h
@@ -230,6 +230,7 @@ extern void devm_extcon_unregister_notifier_all(struct 
device *dev,
  * Following APIs get the extcon_dev from devicetree or by through extcon name.
  */
 extern struct extcon_dev *extcon_get_extcon_dev(const char *extcon_name);
+extern struct extcon_dev *extcon_find_edev_by_node(struct device_node *node);
 extern struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev,
 int index);
 
@@ -283,6 +284,11 @@ static inline struct extcon_dev 
*extcon_get_extcon_dev(const char *extcon_name)
return ERR_PTR(-ENODEV);
 }
 
+static inline struct extcon_dev *extcon_find_edev_by_node(struct device_node 
*node)
+{
+   return ERR_PTR(-ENODEV);
+}
+
 static inline struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev,
int index)
 {
-- 
2.16.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [linux-sunxi] [PATCH 14/15] ARM: dts: sun8i: h3: Enable HDMI output on H3 boards

[Maxime Ripard]

On Tue, Feb 27, 2018 at 01:29:27PM +1100, Julian Calaby wrote:
> Hi Jernej,
> 
> On Tue, Feb 27, 2018 at 3:27 AM, Jernej Škrabec  
> wrote:
> > Hi,
> >
> > Dne ponedeljek, 26. februar 2018 ob 17:21:05 CET je Icenowy Zheng 
> > napisal(a):
> >> 于 2018年2月27日 GMT+08:00 上午12:16:44, "Jernej Škrabec"
> >  写到:
> >> >Hi Julian,
> >> >
> >> >Dne nedelja, 25. februar 2018 ob 09:11:34 CET je Julian Calaby
> >> >
> >> >napisal(a):
> >> >> Hi Jernej,
> >> >>
> >> >> On Sun, Feb 25, 2018 at 8:45 AM, Jernej Skrabec
> >> >
> >> >
> >> >
> >> >wrote:
> >> >> > Enable HDMI output on all boards which have HDMI connector.
> >> >> >
> >> >> > Signed-off-by: Jernej Skrabec 
> >> >> > ---
> >> >> >
> >> >> >  arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts| 25
> >> >> >  ++ arch/arm/boot/dts/sun8i-h3-beelink-x2.dts
> >> >> >
> >> >> >   | 25 ++
> >> >> >
> >> >> >  arch/arm/boot/dts/sun8i-h3-libretech-all-h3-cc.dts | 25
> >> >> >  ++ arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts
> >> >> >
> >> >> >   | 25 ++
> >> >
> >> >arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
> >> >
> >> >> > | 25 ++
> >> >> >
> >> >> >  arch/arm/boot/dts/sun8i-h3-orangepi-lite.dts   | 25
> >> >> >  ++ arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
> >> >> >
> >> >> >   | 24 +
> >> >
> >> >arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
> >> >
> >> >> >| 25 ++ 8 files changed, 199
> >> >
> >> >insertions(+)
> >> >
> >> >> As I understand it, the H2+ is just a slightly trimmed down H3. In
> >> >> terms of HDMI support, the difference is that the H2+ can't output
> >> >
> >> >4k.
> >> >
> >> >> If this code is compatible with the H2+, could you please add the
> >> >> necessary bits and pieces to the h2-plus DTSs too?
> >> >
> >> >There are only 3 H2+ boards in kernel and none of them has HDMI
> >> >connector, so
> >>
> >> BPi M2 Zero has miniHDMI connector.
> >
> > Ah, sorry, I missed that one. Since I don't have it (or any other board with
> > H2+) I'm not really comfortable including such patch. If anyone will test 
> > it,
> > I can include it in next revision.
> 
> I have one of those (this is why I'm interested in this patchset) so
> I'm willing to test, however I can't guarantee I'll get to it quickly.

Then I guess the best way forward will be to keep the current patch as
is, and you'll send a patch whenever you have the time to test it.

Thanks!
Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 4/6] arm64: dts: exynos: add OF graph between MHL and USB connector

[Andrzej Hajda]

On 26.02.2018 16:21, Krzysztof Kozlowski wrote:
> On Wed, Feb 21, 2018 at 9:55 AM, Andrzej Hajda  wrote:
>> OF graph describes MHL data lanes between MHL and respective USB
>> connector.
>>
>> Signed-off-by: Andrzej Hajda 
>> ---
>> v4:
>> - added missing reg property in connector's port node (Krzysztof)
>> ---
>>  .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 32 
>> --
>>  1 file changed, 29 insertions(+), 3 deletions(-)
> You have a duplicated '};' so kbuild complains so I assume there will
> be next iteration of this. Beside that I am okay with both, so I will
> take next version when your bindings and driver changes get
> acked/accepted.

Yes, test robot already reported it, thanks for looking at it.
I have postponed next iteration in case anything new is spotted, but
since it is calm I will send it in few minutes.

Regards
Andrzej

>
> Best Regards,
> Krzysztof
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 8/9] drm/xen-front: Implement GEM operations

[Oleksandr Andrushchenko]

On 02/27/2018 01:47 AM, Boris Ostrovsky wrote:

On 02/23/2018 10:35 AM, Oleksandr Andrushchenko wrote:

On 02/23/2018 05:26 PM, Boris Ostrovsky wrote:

On 02/21/2018 03:03 AM, Oleksandr Andrushchenko wrote:

+static struct xen_gem_object *gem_create(struct drm_device *dev,
size_t size)
+{
+struct xen_drm_front_drm_info *drm_info = dev->dev_private;
+struct xen_gem_object *xen_obj;
+int ret;
+
+size = round_up(size, PAGE_SIZE);
+xen_obj = gem_create_obj(dev, size);
+if (IS_ERR_OR_NULL(xen_obj))
+return xen_obj;
+
+if (drm_info->cfg->be_alloc) {
+/*
+ * backend will allocate space for this buffer, so
+ * only allocate array of pointers to pages
+ */
+xen_obj->be_alloc = true;

If be_alloc is a flag (which I am not sure about) --- should it be set
to true *after* you've successfully allocated your things?

this is a configuration option telling about the way
the buffer gets allocated: either by the frontend or
backend (be_alloc -> buffer allocated by the backend)


I can see how drm_info->cfg->be_alloc might be a configuration option
but xen_obj->be_alloc is set here and that's not how configuration
options typically behave.

you are right, I will put be_alloc down the code and will slightly
rework error handling for this function



+ret = gem_alloc_pages_array(xen_obj, size);
+if (ret < 0) {
+gem_free_pages_array(xen_obj);
+goto fail;
+}
+
+ret = alloc_xenballooned_pages(xen_obj->num_pages,
+xen_obj->pages);

Why are you allocating balloon pages?

in this use-case we map pages provided by the backend
(yes, I know this can be a problem from both security
POV and that DomU can die holding pages of Dom0 forever:
but still it is a configuration option, so user decides
if her use-case needs this and takes responsibility for
such a decision).


Perhaps I am missing something here but when you say "I know this can be
a problem from both security POV ..." then there is something wrong with
your solution.

well, in this scenario there are actually 2 concerns:
1. If DomU dies the pages/grants from Dom0/DomD cannot be
reclaimed back
2. Misbehaving guest may send too many requests to the
backend exhausting grant references and memory of Dom0/DomD
(this is the only concern from security POV). Please see [1]

But, we are focusing on embedded use-cases,
so those systems we use are not that "dynamic" with respect to 2).
Namely: we have fixed number of domains and their functionality
is well known, so we can do rather precise assumption on resource
usage. This is why I try to warn on such a use-case and rely on
the end user who understands the caveats

I'll probably add more precise description of this use-case
clarifying what is that security POV, so there is no confusion

Hope this explanation answers your questions

-boris


Please see description of the buffering modes in xen_drm_front.h
specifically for backend allocated buffers:
  
***

  * 2. Buffers allocated by the backend
  
***

  *
  * This mode of operation is run-time configured via guest domain
configuration
  * through XenStore entries.
  *
  * For systems which do not provide IOMMU support, but having specific
  * requirements for display buffers it is possible to allocate such
buffers
  * at backend side and share those with the frontend.
  * For example, if host domain is 1:1 mapped and has DRM/GPU hardware
expecting
  * physically contiguous memory, this allows implementing zero-copying
  * use-cases.


-boris


+if (ret < 0) {
+DRM_ERROR("Cannot allocate %zu ballooned pages: %d\n",
+xen_obj->num_pages, ret);
+goto fail;
+}
+
+return xen_obj;
+}
+/*
+ * need to allocate backing pages now, so we can share those
+ * with the backend
+ */
+xen_obj->num_pages = DIV_ROUND_UP(size, PAGE_SIZE);
+xen_obj->pages = drm_gem_get_pages(_obj->base);
+if (IS_ERR_OR_NULL(xen_obj->pages)) {
+ret = PTR_ERR(xen_obj->pages);
+xen_obj->pages = NULL;
+goto fail;
+}
+
+return xen_obj;
+
+fail:
+DRM_ERROR("Failed to allocate buffer with size %zu\n", size);
+return ERR_PTR(ret);
+}
+


Thank you,
Oleksandr

[1] 
https://lists.xenproject.org/archives/html/xen-devel/2017-07/msg03100.html

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/7] drm/virtio: Checkpatch cleanup for virtio

[Gerd Hoffmann]

On Thu, Feb 22, 2018 at 08:59:33PM -0300, Rodrigo Siqueira wrote:
> This patchset fixes warnings and errors found by checkpatch.pl in the
> drm/virtio:

Added to drm-qemu queue, will land in drm-misc soon.

thanks,
  Gerd

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[radeon-alex:drm-next-4.17-wip 390/390] drivers/gpu//drm/amd/amdgpu/si_dpm.c:7317:29: error: 'CAIL_PCIE_LINK_SPEED_SUPPORT_MASK' undeclared; did you mean 'LC_TARGET_LINK_SPEED_OVERRIDE_MASK'?

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git drm-next-4.17-wip
head:   1d0e528594e2040c6c208be32bad4ad57437aabb
commit: 1d0e528594e2040c6c208be32bad4ad57437aabb [390/390] drm/amdgpu: used 
cached pcie gen info for SI
config: powerpc64-allyesconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 1d0e528594e2040c6c208be32bad4ad57437aabb
# save the attached .config to linux build tree
make.cross ARCH=powerpc64 

All errors (new ones prefixed by >>):

   drivers/gpu//drm/amd/amdgpu/si_dpm.c: In function 'si_dpm_init':
>> drivers/gpu//drm/amd/amdgpu/si_dpm.c:7317:29: error: 
>> 'CAIL_PCIE_LINK_SPEED_SUPPORT_MASK' undeclared (first use in this function); 
>> did you mean 'LC_TARGET_LINK_SPEED_OVERRIDE_MASK'?
  (adev->pm.pcie_gen_mask & CAIL_PCIE_LINK_SPEED_SUPPORT_MASK) >>
^
LC_TARGET_LINK_SPEED_OVERRIDE_MASK
   drivers/gpu//drm/amd/amdgpu/si_dpm.c:7317:29: note: each undeclared 
identifier is reported only once for each function it appears in
   drivers/gpu//drm/amd/amdgpu/si_dpm.c:7318:3: error: 
'CAIL_PCIE_LINK_SPEED_SUPPORT_SHIFT' undeclared (first use in this function); 
did you mean 'CAIL_PCIE_LINK_SPEED_SUPPORT_MASK'?
  CAIL_PCIE_LINK_SPEED_SUPPORT_SHIFT;
  ^~
  CAIL_PCIE_LINK_SPEED_SUPPORT_MASK

vim +7317 drivers/gpu//drm/amd/amdgpu/si_dpm.c

  7298  
  7299  static int si_dpm_init(struct amdgpu_device *adev)
  7300  {
  7301  struct rv7xx_power_info *pi;
  7302  struct evergreen_power_info *eg_pi;
  7303  struct ni_power_info *ni_pi;
  7304  struct si_power_info *si_pi;
  7305  struct atom_clock_dividers dividers;
  7306  int ret;
  7307  
  7308  si_pi = kzalloc(sizeof(struct si_power_info), GFP_KERNEL);
  7309  if (si_pi == NULL)
  7310  return -ENOMEM;
  7311  adev->pm.dpm.priv = si_pi;
  7312  ni_pi = _pi->ni;
  7313  eg_pi = _pi->eg;
  7314  pi = _pi->rv7xx;
  7315  
  7316  si_pi->sys_pcie_mask =
> 7317  (adev->pm.pcie_gen_mask & 
> CAIL_PCIE_LINK_SPEED_SUPPORT_MASK) >>
  7318  CAIL_PCIE_LINK_SPEED_SUPPORT_SHIFT;
  7319  si_pi->force_pcie_gen = AMDGPU_PCIE_GEN_INVALID;
  7320  si_pi->boot_pcie_gen = si_get_current_pcie_speed(adev);
  7321  
  7322  si_set_max_cu_value(adev);
  7323  
  7324  rv770_get_max_vddc(adev);
  7325  si_get_leakage_vddc(adev);
  7326  si_patch_dependency_tables_based_on_leakage(adev);
  7327  
  7328  pi->acpi_vddc = 0;
  7329  eg_pi->acpi_vddci = 0;
  7330  pi->min_vddc_in_table = 0;
  7331  pi->max_vddc_in_table = 0;
  7332  
  7333  ret = amdgpu_get_platform_caps(adev);
  7334  if (ret)
  7335  return ret;
  7336  
  7337  ret = amdgpu_parse_extended_power_table(adev);
  7338  if (ret)
  7339  return ret;
  7340  
  7341  ret = si_parse_power_table(adev);
  7342  if (ret)
  7343  return ret;
  7344  
  7345  adev->pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries =
  7346  kzalloc(4 * sizeof(struct 
amdgpu_clock_voltage_dependency_entry), GFP_KERNEL);
  7347  if (!adev->pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries) 
{
  7348  amdgpu_free_extended_power_table(adev);
  7349  return -ENOMEM;
  7350  }
  7351  adev->pm.dpm.dyn_state.vddc_dependency_on_dispclk.count = 4;
  7352  
adev->pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries[0].clk = 0;
  7353  adev->pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries[0].v 
= 0;
  7354  
adev->pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries[1].clk = 36000;
  7355  adev->pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries[1].v 
= 720;
  7356  
adev->pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries[2].clk = 54000;
  7357  adev->pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries[2].v 
= 810;
  7358  
adev->pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries[3].clk = 72000;
  7359  adev->pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries[3].v 
= 900;
  7360  
  7361  if (adev->pm.dpm.voltage_response_time == 0)
  7362  adev->pm.dpm.voltage_response_time = 
R600_VOLTAGERESPONSETIME_DFLT;
  7363  if (adev->pm.dpm.backbias_response_time == 0)
  7364  adev->pm.dpm.backbias_response_time = 
R600_BACKBIASRESPONSETIME_DFLT;
  7365  
  7366  ret = amdgpu_atombios_get_clock_dividers(adev, 
COMPUTE_ENGINE_PLL_PARAM,
  7367  

[radeon-alex:drm-next-4.17-wip 390/390] drivers/gpu/drm/amd/amdgpu/si.c:1500:34: error: 'CAIL_PCIE_LINK_SPEED_SUPPORT_GEN2' undeclared

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git drm-next-4.17-wip
head:   1d0e528594e2040c6c208be32bad4ad57437aabb
commit: 1d0e528594e2040c6c208be32bad4ad57437aabb [390/390] drm/amdgpu: used 
cached pcie gen info for SI
config: x86_64-randconfig-u0-02271135 (attached as .config)
compiler: gcc-5 (Debian 5.5.0-3) 5.4.1 20171010
reproduce:
git checkout 1d0e528594e2040c6c208be32bad4ad57437aabb
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/amd/amdgpu/si.c: In function 'si_pcie_gen3_enable':
>> drivers/gpu/drm/amd/amdgpu/si.c:1500:34: error: 
>> 'CAIL_PCIE_LINK_SPEED_SUPPORT_GEN2' undeclared (first use in this function)
 if (!(adev->pm.pcie_gen_mask & (CAIL_PCIE_LINK_SPEED_SUPPORT_GEN2 |
 ^
   drivers/gpu/drm/amd/amdgpu/si.c:1500:34: note: each undeclared identifier is 
reported only once for each function it appears in
>> drivers/gpu/drm/amd/amdgpu/si.c:1501:6: error: 
>> 'CAIL_PCIE_LINK_SPEED_SUPPORT_GEN3' undeclared (first use in this function)
 CAIL_PCIE_LINK_SPEED_SUPPORT_GEN3)))
 ^
   drivers/gpu/drm/amd/amdgpu/si.c:1488:6: warning: unused variable 'ret' 
[-Wunused-variable]
 int ret, i;
 ^
--
   drivers/gpu/drm/amd/amdgpu/si_dpm.c: In function 'si_dpm_init':
   drivers/gpu/drm/amd/amdgpu/si_dpm.c:7317:29: error: 
'CAIL_PCIE_LINK_SPEED_SUPPORT_MASK' undeclared (first use in this function)
  (adev->pm.pcie_gen_mask & CAIL_PCIE_LINK_SPEED_SUPPORT_MASK) >>
^
   drivers/gpu/drm/amd/amdgpu/si_dpm.c:7317:29: note: each undeclared 
identifier is reported only once for each function it appears in
>> drivers/gpu/drm/amd/amdgpu/si_dpm.c:7318:3: error: 
>> 'CAIL_PCIE_LINK_SPEED_SUPPORT_SHIFT' undeclared (first use in this function)
  CAIL_PCIE_LINK_SPEED_SUPPORT_SHIFT;
  ^

vim +/CAIL_PCIE_LINK_SPEED_SUPPORT_GEN2 +1500 drivers/gpu/drm/amd/amdgpu/si.c

  1482  
  1483  static void si_pcie_gen3_enable(struct amdgpu_device *adev)
  1484  {
  1485  struct pci_dev *root = adev->pdev->bus->self;
  1486  int bridge_pos, gpu_pos;
  1487  u32 speed_cntl, current_data_rate;
  1488  int ret, i;
  1489  u16 tmp16;
  1490  
  1491  if (pci_is_root_bus(adev->pdev->bus))
  1492  return;
  1493  
  1494  if (amdgpu_pcie_gen2 == 0)
  1495  return;
  1496  
  1497  if (adev->flags & AMD_IS_APU)
  1498  return;
  1499  
> 1500  if (!(adev->pm.pcie_gen_mask & 
> (CAIL_PCIE_LINK_SPEED_SUPPORT_GEN2 |
> 1501  
> CAIL_PCIE_LINK_SPEED_SUPPORT_GEN3)))
  1502  return;
  1503  
  1504  speed_cntl = RREG32_PCIE_PORT(PCIE_LC_SPEED_CNTL);
  1505  current_data_rate = (speed_cntl & LC_CURRENT_DATA_RATE_MASK) >>
  1506  LC_CURRENT_DATA_RATE_SHIFT;
  1507  if (adev->pm.pcie_gen_mask & CAIL_PCIE_LINK_SPEED_SUPPORT_GEN3) 
{
  1508  if (current_data_rate == 2) {
  1509  DRM_INFO("PCIE gen 3 link speeds already 
enabled\n");
  1510  return;
  1511  }
  1512  DRM_INFO("enabling PCIE gen 3 link speeds, disable with 
amdgpu.pcie_gen2=0\n");
  1513  } else if (adev->pm.pcie_gen_mask & 
CAIL_PCIE_LINK_SPEED_SUPPORT_GEN2) {
  1514  if (current_data_rate == 1) {
  1515  DRM_INFO("PCIE gen 2 link speeds already 
enabled\n");
  1516  return;
  1517  }
  1518  DRM_INFO("enabling PCIE gen 2 link speeds, disable with 
amdgpu.pcie_gen2=0\n");
  1519  }
  1520  
  1521  bridge_pos = pci_pcie_cap(root);
  1522  if (!bridge_pos)
  1523  return;
  1524  
  1525  gpu_pos = pci_pcie_cap(adev->pdev);
  1526  if (!gpu_pos)
  1527  return;
  1528  
  1529  if (adev->pm.pcie_gen_mask & CAIL_PCIE_LINK_SPEED_SUPPORT_GEN3) 
{
  1530  if (current_data_rate != 2) {
  1531  u16 bridge_cfg, gpu_cfg;
  1532  u16 bridge_cfg2, gpu_cfg2;
  1533  u32 max_lw, current_lw, tmp;
  1534  
  1535  pci_read_config_word(root, bridge_pos + 
PCI_EXP_LNKCTL, _cfg);
  1536  pci_read_config_word(adev->pdev, gpu_pos + 
PCI_EXP_LNKCTL, _cfg);
  1537  
  1538  tmp16 = bridge_cfg | PCI_EXP_LNKCTL_HAWD;
  1539  pci_write_config_word(root, bridge_pos + 
PCI_EXP_LNKCTL, tmp16);
  1540  
  1541  tmp16 = gpu_cfg | PCI_EXP_LNKCTL_HAWD;
  1542  pci_write_config_word(adev->pdev, gpu_pos + 
PCI_EXP_LNKCTL, tmp16);
  1543  
  1544  tmp = 

Re: [Mesa-dev] Allocator Nouveau driver, Mesa EXT_external_objects, and DRM metadata import interfaces

[James Jones]

On 02/22/2018 01:16 PM, Alex Deucher wrote:

On Thu, Feb 22, 2018 at 1:49 PM, Bas Nieuwenhuizen
 wrote:

On Thu, Feb 22, 2018 at 7:04 PM, Kristian Høgsberg  wrote:

On Wed, Feb 21, 2018 at 4:00 PM Alex Deucher  wrote:


On Wed, Feb 21, 2018 at 1:14 AM, Chad Versace 

wrote:

On Thu 21 Dec 2017, Daniel Vetter wrote:

On Thu, Dec 21, 2017 at 12:22 AM, Kristian Kristensen <

hoegsb...@google.com> wrote:

On Wed, Dec 20, 2017 at 12:41 PM, Miguel Angel Vico <

mvicom...@nvidia.com> wrote:

On Wed, 20 Dec 2017 11:54:10 -0800 Kristian Høgsberg <

hoegsb...@gmail.com> wrote:

I'd like to see concrete examples of actual display controllers
supporting more format layouts than what can be specified with a 64
bit modifier.


The main problem is our tiling and other metadata parameters can't
generally fit in a modifier, so we find passing a blob of metadata a
more suitable mechanism.


I understand that you may have n knobs with a total of more than a

total of

56 bits that configure your tiling/swizzling for color buffers. What

I don't

buy is that you need all those combinations when passing buffers

around

between codecs, cameras and display controllers. Even if you're

sharing

between the same 3D drivers in different processes, I expect just

locking

down, say, 64 different combinations (you can add more over time) and
assigning each a modifier would be sufficient. I doubt you'd extract
meaningful performance gains from going all the way to a blob.


I agree with Kristian above. In my opinion, choosing to encode in
modifiers a precise description of every possible tiling/compression
layout is not technically incorrect, but I believe it misses the point.
The intention behind modifiers is not to exhaustively describe all
possibilites.

I summarized this opinion in VK_EXT_image_drm_format_modifier,
where I wrote an "introdution to modifiers" section. Here's an excerpt:

 One goal of modifiers in the Linux ecosystem is to enumerate for

each

 vendor a reasonably sized set of tiling formats that are

appropriate for

 images shared across processes, APIs, and/or devices, where each
 participating component may possibly be from different vendors.
 A non-goal is to enumerate all tiling formats supported by all

vendors.

 Some tiling formats used internally by vendors are inappropriate for
 sharing; no modifiers should be assigned to such tiling formats.



Where it gets tricky is how to select that subset?  Our tiling mode
are defined more by the asic specific constraints than the tiling mode
itself.  At a high level we have basically 3 tiling modes (out of 16
possible) that would be the minimum we'd want to expose for gfx6-8.
gfx9 uses a completely new scheme.
1. Linear (per asic stride requirements, not usable by many hw blocks)
2. 1D Thin (5 layouts, displayable, depth, thin, rotated, thick)
3. 2D Thin (1D tiling constraints, plus pipe config (18 possible),
tile split (7 possible), sample split (4 possible), num banks (4
possible), bank width (4 possible), bank height (4 possible), macro
tile aspect (4 possible) all of which are asic config specific)



I guess we could do something like:
AMD_GFX6_LINEAR_ALIGNED_64B
AMD_GFX6_LINEAR_ALIGNED_256B
AMD_GFX6_LINEAR_ALIGNED_512B
AMD_GFX6_1D_THIN_DISPLAY
AMD_GFX6_1D_THIN_DEPTH
AMD_GFX6_1D_THIN_ROTATED
AMD_GFX6_1D_THIN_THIN
AMD_GFX6_1D_THIN_THICK


AMD_GFX6_2D_1D_THIN_DISPLAY_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1

AMD_GFX6_2D_1D_THIN_DEPTH_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1

AMD_GFX6_2D_1D_THIN_ROTATED_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1

AMD_GFX6_2D_1D_THIN_THIN_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1

AMD_GFX6_2D_1D_THIN_THICK_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1

AMD_GFX6_2D_1D_THIN_DISPLAY_PIPE_CONFIG_P4_8x16_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1

AMD_GFX6_2D_1D_THIN_DEPTH_PIPE_CONFIG_P4_8x16_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1

AMD_GFX6_2D_1D_THIN_ROTATED_PIPE_CONFIG_P4_8x16_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1

AMD_GFX6_2D_1D_THIN_THIN_PIPE_CONFIG_P4_8x16_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1

AMD_GFX6_2D_1D_THIN_THICK_PIPE_CONFIG_P4_8x16_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1

etc.



We only probably need 40 bits to encode all of the tiling parameters
so we could do family, plus tiling encoding that still seems unwieldy
to deal with from an application 

Re: [PATCH] drm/nouveau: Replace the iturbt_709 prop with the standarad COLOR_ENCODNIG prop

[Ilia Mirkin]

On Tue, Feb 20, 2018 at 9:25 AM, Ilia Mirkin  wrote:
> On Tue, Feb 20, 2018 at 8:48 AM, Ville Syrjala
>  wrote:
>> From: Ville Syrjälä 
>>
>> Replace the ad-hoc iturbt_709 property with the new standard
>> COLOR_ENCODING property. Compiles, but not tested.
>>
>> Cc: Daniel Vetter 
>> Cc: nouv...@lists.freedesktop.org
>> Cc: Ben Skeggs 
>> Cc: Ilia Mirkin 
>> Signed-off-by: Ville Syrjälä 
>
> s/standarad/standard/ in subject
>
> I'd like the opportunity to test this out on real hardware, but I
> don't have any pre-NV41 boards plugged in right now. I should be able
> to attend to it within 7 days. If you don't hear back from me by then,
> I'd appreciate a ping, as I do let things (hopefully occasionally)
> slip through.

Tested this out on a NV34. Seems to work - at least the green SMPTE
bar looks different in the two different modes (had to hack modetest
to use the SMPTE pattern on planes).

I do wonder about the new color range property... that's more of a
connector thing than a plane thing no? Presumably over S-Video it's a
partial range, and over VGA it's full? I'd flip it to always full here
tbh. (Or just not provide it at all.)

Anyways, with the subject typo(s! noticed ENCODNIG -> ENCODING just
now) fixed, this is

Reviewed-by: Ilia Mirkin 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105018] Kernel panic when waking up after screen goes blank.

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105018

--- Comment #21 from L.S.S.  ---
Another problem: When I woke up the screen, sometimes the system would have
intermittent soft lockups that made the system kind of unusable... This is
after I included the patch to the latest 4.15 kernel, 4.15.5 (4.15.5-1-MANJARO)

In journalctl I find the following phenomenon. During its sleep the error
"failed to get VBLANK" is being written every 20s.

Feb 27 11:57:29 linuxsys kernel: [drm:dm_logger_write [amdgpu]] *ERROR* Failed
to get VBLANK!
Feb 27 11:57:49 linuxsys kernel: [drm:dm_logger_write [amdgpu]] *ERROR* Failed
to get VBLANK!
Feb 27 11:58:09 linuxsys kernel: [drm:dm_logger_write [amdgpu]] *ERROR* Failed
to get VBLANK!
Feb 27 11:58:29 linuxsys kernel: [drm:dm_logger_write [amdgpu]] *ERROR* Failed
to get VBLANK!
Feb 27 11:58:49 linuxsys kernel: [drm:dm_logger_write [amdgpu]] *ERROR* Failed
to get VBLANK!
Feb 27 11:59:09 linuxsys kernel: [drm:dm_logger_write [amdgpu]] *ERROR* Failed
to get VBLANK!
Feb 27 11:59:29 linuxsys kernel: [drm:dm_logger_write [amdgpu]] *ERROR* Failed
to get VBLANK!
Feb 27 11:59:49 linuxsys kernel: [drm:dm_logger_write [amdgpu]] *ERROR* Failed
to get VBLANK!

After I woke the screen up and I get the intermittent soft lockup issue, the
error "dc_stream_state is NULL for crtc '1'" is written multiple times from
either dm_vblank_get_counter or dm_crtc_get_scanoutpos every 8 or 18 seconds,
which seemed to correspond to the lockup interval. I did not test the issue
further as the system was almost unusable due to the lockup and I had to
reboot.

Feb 27 12:17:08 linuxsys kernel: [drm:dm_vblank_get_counter [amdgpu]] *ERROR*
dc_stream_state is NULL for crtc '1'!
Feb 27 12:17:08 linuxsys kernel: [drm:dm_crtc_get_scanoutpos [amdgpu]] *ERROR*
dc_stream_state is NULL for crtc '1'!
Feb 27 12:17:08 linuxsys kernel: [drm:dm_vblank_get_counter [amdgpu]] *ERROR*
dc_stream_state is NULL for crtc '1'!
Feb 27 12:17:08 linuxsys kernel: [drm:dm_vblank_get_counter [amdgpu]] *ERROR*
dc_stream_state is NULL for crtc '1'!
Feb 27 12:17:08 linuxsys kernel: [drm:dm_crtc_get_scanoutpos [amdgpu]] *ERROR*
dc_stream_state is NULL for crtc '1'!
Feb 27 12:17:08 linuxsys kernel: [drm:dm_vblank_get_counter [amdgpu]] *ERROR*
dc_stream_state is NULL for crtc '1'!
Feb 27 12:17:16 linuxsys kernel: [drm:dm_vblank_get_counter [amdgpu]] *ERROR*
dc_stream_state is NULL for crtc '1'!
Feb 27 12:17:16 linuxsys kernel: [drm:dm_crtc_get_scanoutpos [amdgpu]] *ERROR*
dc_stream_state is NULL for crtc '1'!
Feb 27 12:17:16 linuxsys kernel: [drm:dm_vblank_get_counter [amdgpu]] *ERROR*
dc_stream_state is NULL for crtc '1'!
Feb 27 12:17:16 linuxsys kernel: [drm:dm_vblank_get_counter [amdgpu]] *ERROR*
dc_stream_state is NULL for crtc '1'!
Feb 27 12:17:16 linuxsys kernel: [drm:dm_crtc_get_scanoutpos [amdgpu]] *ERROR*
dc_stream_state is NULL for crtc '1'!
Feb 27 12:17:16 linuxsys kernel: [drm:dm_vblank_get_counter [amdgpu]] *ERROR*
dc_stream_state is NULL for crtc '1'!
Feb 27 12:17:34 linuxsys kernel: [drm:dm_vblank_get_counter [amdgpu]] *ERROR*
dc_stream_state is NULL for crtc '1'!
Feb 27 12:17:34 linuxsys kernel: [drm:dm_crtc_get_scanoutpos [amdgpu]] *ERROR*
dc_stream_state is NULL for crtc '1'!
Feb 27 12:17:34 linuxsys kernel: [drm:dm_vblank_get_counter [amdgpu]] *ERROR*
dc_stream_state is NULL for crtc '1'!
Feb 27 12:17:34 linuxsys kernel: [drm:dm_vblank_get_counter [amdgpu]] *ERROR*
dc_stream_state is NULL for crtc '1'!
Feb 27 12:17:34 linuxsys kernel: [drm:dm_crtc_get_scanoutpos [amdgpu]] *ERROR*
dc_stream_state is NULL for crtc '1'!
Feb 27 12:17:34 linuxsys kernel: [drm:dm_vblank_get_counter [amdgpu]] *ERROR*
dc_stream_state is NULL for crtc '1'!
Feb 27 12:17:42 linuxsys kernel: [drm:dm_vblank_get_counter [amdgpu]] *ERROR*
dc_stream_state is NULL for crtc '1'!
Feb 27 12:17:42 linuxsys kernel: [drm:dm_crtc_get_scanoutpos [amdgpu]] *ERROR*
dc_stream_state is NULL for crtc '1'!
Feb 27 12:17:42 linuxsys kernel: [drm:dm_vblank_get_counter [amdgpu]] *ERROR*
dc_stream_state is NULL for crtc '1'!
Feb 27 12:17:42 linuxsys kernel: [drm:dm_vblank_get_counter [amdgpu]] *ERROR*
dc_stream_state is NULL for crtc '1'!
Feb 27 12:17:42 linuxsys kernel: [drm:dm_crtc_get_scanoutpos [amdgpu]] *ERROR*
dc_stream_state is NULL for crtc '1'!
Feb 27 12:17:42 linuxsys kernel: [drm:dm_vblank_get_counter [amdgpu]] *ERROR*
dc_stream_state is NULL for crtc '1'!
Feb 27 12:18:00 linuxsys kernel: [drm:dm_vblank_get_counter [amdgpu]] *ERROR*
dc_stream_state is NULL for crtc '1'!
Feb 27 12:18:00 linuxsys kernel: [drm:dm_crtc_get_scanoutpos [amdgpu]] *ERROR*
dc_stream_state is NULL for crtc '1'!
Feb 27 12:18:00 linuxsys kernel: [drm:dm_vblank_get_counter [amdgpu]] *ERROR*
dc_stream_state is NULL for crtc '1'!
Feb 27 12:18:00 linuxsys kernel: [drm:dm_vblank_get_counter [amdgpu]] *ERROR*
dc_stream_state is NULL for crtc '1'!
Feb 27 12:18:00 linuxsys kernel: [drm:dm_crtc_get_scanoutpos [amdgpu]] *ERROR*
dc_stream_state is NULL for crtc '1'!
Feb 27 

[radeon-alex:amd-staging-drm-next 699/715] sound/soc/amd/raven/pci-acp3x.c:58:8: error: implicit declaration of function 'pci_enable_msi'; did you mean 'pci_enable_sriov'?

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head:   1dec943aa3f9e9a9c39559851239e382ad1e436c
commit: 944b5289c92d9c1aad3760c012daf4cf2478381f [699/715] ASoC: AMD: enable 
ACP3x drivers build
config: sh-allmodconfig (attached as .config)
compiler: sh4-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 944b5289c92d9c1aad3760c012daf4cf2478381f
# save the attached .config to linux build tree
make.cross ARCH=sh 

All errors (new ones prefixed by >>):

   sound/soc/amd/raven/pci-acp3x.c: In function 'snd_acp3x_probe':
>> sound/soc/amd/raven/pci-acp3x.c:58:8: error: implicit declaration of 
>> function 'pci_enable_msi'; did you mean 'pci_enable_sriov'? 
>> [-Werror=implicit-function-declaration]
 ret = pci_enable_msi(pci);
   ^~
   pci_enable_sriov
>> sound/soc/amd/raven/pci-acp3x.c:122:2: error: implicit declaration of 
>> function 'pci_disable_msi'; did you mean 'pci_disable_sriov'? 
>> [-Werror=implicit-function-declaration]
 pci_disable_msi(pci);
 ^~~
 pci_disable_sriov
   sound/soc/amd/raven/pci-acp3x.c: At top level:
   sound/soc/amd/raven/pci-acp3x.c:159:1: warning: data definition has no type 
or storage class
module_pci_driver(acp3x_driver);
^
>> sound/soc/amd/raven/pci-acp3x.c:159:1: error: type defaults to 'int' in 
>> declaration of 'module_pci_driver' [-Werror=implicit-int]
   sound/soc/amd/raven/pci-acp3x.c:159:1: warning: parameter names (without 
types) in function declaration
   sound/soc/amd/raven/pci-acp3x.c:152:26: warning: 'acp3x_driver' defined but 
not used [-Wunused-variable]
static struct pci_driver acp3x_driver  = {
 ^~~~
   cc1: some warnings being treated as errors

vim +58 sound/soc/amd/raven/pci-acp3x.c

e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27   29  
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27   30  static int 
snd_acp3x_probe(struct pci_dev *pci,
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27   31  
const struct pci_device_id *pci_id)
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27   32  {
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27   33   int ret;
4a00d378 Maruthi Srinivas Bayyavarapu 2017-03-29   34   u32 addr, val;
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27   35   struct acp3x_dev_data 
*adata;
4a00d378 Maruthi Srinivas Bayyavarapu 2017-03-29   36   struct 
platform_device_info pdevinfo;
4a00d378 Maruthi Srinivas Bayyavarapu 2017-03-29   37   unsigned int irqflags;
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27   38  
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27   39   if 
(pci_enable_device(pci)) {
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27   40   
dev_err(>dev, "pci_enable_device failed\n");
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27   41   return -ENODEV;
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27   42   }
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27   43  
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27   44   ret = 
pci_request_regions(pci, "AMD ACP3x audio");
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27   45   if (ret < 0) {
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27   46   
dev_err(>dev, "pci_request_regions failed\n");
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27   47   goto 
disable_pci;
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27   48   }
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27   49  
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27   50   adata = 
devm_kzalloc(>dev, sizeof(struct acp3x_dev_data),
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27   51   
GFP_KERNEL);
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27   52   if (adata == NULL) {
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27   53   ret = -ENOMEM;
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27   54   goto 
release_regions;
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27   55   }
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27   56  
4a00d378 Maruthi Srinivas Bayyavarapu 2017-03-29   57   /* check for msi 
interrupt support */
4a00d378 Maruthi Srinivas Bayyavarapu 2017-03-29  @58   ret = 
pci_enable_msi(pci);
4a00d378 Maruthi Srinivas Bayyavarapu 2017-03-29   59   if (ret)
4a00d378 Maruthi Srinivas Bayyavarapu 2017-03-29   60   /* msi is not 
enabled */
4a00d378 Maruthi Srinivas Bayyavarapu 2017-03-29   61   irqflags = 
IRQF_SHARED;
4a00d378 Maruthi Srinivas Bayyavarapu 2017-03-29   62   else
4a00d378 Maruthi Srinivas Bayyavarapu 2017-03-29   63   /* msi is 
enabled */
4a00d378 Maruthi Srinivas Bayyavarapu 2017-03-29   64   irqflags = 0;
4a00d378 Maruthi Srinivas Bayyavarapu 2017-03-29   65  
e8f3716a Maruthi Srinivas Bayyavarapu 2017-03-27   66   addr = 

[Bug 104064] (DC 4.15-rc2) WARNING: CPU: 4 PID: 75 at drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:601 dm_suspend+0x4e/0x60 [amdgpu]

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=104064

--- Comment #5 from Bjorn  ---
I certainly wouldn't mind.

I've never really done anything of the sort before however, so is there an easy
way for me to set it up? For reference, I'm on Ubuntu 17.10 and while I know my
way around git and compilers fairly well, I've never compiled or installed a
custom kernel or kernel module before.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105256] Slow performance using glDrawElements calls with GL_UNSIGNED_BYTE indices

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105256

Logan McNaughton  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #6 from Logan McNaughton  ---
Fair enough, even a warning when MESA_DEBUG is set would be good, just
something to notify the developer what is wrong

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 12/15] drm/sun4i: Allow building on arm64

[kbuild test robot]

Hi Jernej,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on drm/drm-next]
[also build test WARNING on next-20180226]
[cannot apply to robh/for-next v4.16-rc3]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Jernej-Skrabec/Implement-H3-H5-HDMI-driver/20180227-054135
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: arm64-allmodconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64 

All warnings (new ones prefixed by >>):

   In file included from drivers/gpu//drm/sun4i/sun8i_dw_hdmi.h:12:0,
from drivers/gpu//drm/sun4i/sun8i_hdmi_phy.c:9:
   drivers/gpu//drm/sun4i/sun8i_hdmi_phy.c: In function 
'sun8i_hdmi_phy_config_h3':
>> drivers/gpu//drm/sun4i/sun8i_hdmi_phy.c:188:7: warning: large integer 
>> implicitly truncated to unsigned type [-Woverflow]
  ~SUN8I_HDMI_PHY_PLL_CFG2_PREDIV_MSK, pll_cfg2_init);
  ^
   include/linux/regmap.h:75:36: note: in definition of macro 
'regmap_update_bits'
 regmap_update_bits_base(map, reg, mask, val, NULL, false, false)
   ^~~~

vim +188 drivers/gpu//drm/sun4i/sun8i_hdmi_phy.c

b7c7436a Jernej Skrabec 2018-02-148  
b7c7436a Jernej Skrabec 2018-02-14   @9  #include "sun8i_dw_hdmi.h"
b7c7436a Jernej Skrabec 2018-02-14   10  
b7c7436a Jernej Skrabec 2018-02-14   11  /*
b7c7436a Jernej Skrabec 2018-02-14   12   * Address can be actually any value. 
Here is set to same value as
b7c7436a Jernej Skrabec 2018-02-14   13   * it is set in BSP driver.
b7c7436a Jernej Skrabec 2018-02-14   14   */
b7c7436a Jernej Skrabec 2018-02-14   15  #define I2C_ADDR   0x69
b7c7436a Jernej Skrabec 2018-02-14   16  
322900e8 Jernej Skrabec 2018-02-24   17  static int 
sun8i_hdmi_phy_config_a83t(struct dw_hdmi *hdmi,
322900e8 Jernej Skrabec 2018-02-24   18   
struct sun8i_hdmi_phy *phy,
322900e8 Jernej Skrabec 2018-02-24   19   
unsigned int clk_rate)
b7c7436a Jernej Skrabec 2018-02-14   20  {
b7c7436a Jernej Skrabec 2018-02-14   21 regmap_update_bits(phy->regs, 
SUN8I_HDMI_PHY_REXT_CTRL_REG,
b7c7436a Jernej Skrabec 2018-02-14   22
SUN8I_HDMI_PHY_REXT_CTRL_REXT_EN,
b7c7436a Jernej Skrabec 2018-02-14   23
SUN8I_HDMI_PHY_REXT_CTRL_REXT_EN);
b7c7436a Jernej Skrabec 2018-02-14   24  
b7c7436a Jernej Skrabec 2018-02-14   25 /* power down */
b7c7436a Jernej Skrabec 2018-02-14   26 dw_hdmi_phy_gen2_txpwron(hdmi, 
0);
b7c7436a Jernej Skrabec 2018-02-14   27 dw_hdmi_phy_gen2_pddq(hdmi, 1);
b7c7436a Jernej Skrabec 2018-02-14   28  
b7c7436a Jernej Skrabec 2018-02-14   29 dw_hdmi_phy_reset(hdmi);
b7c7436a Jernej Skrabec 2018-02-14   30  
b7c7436a Jernej Skrabec 2018-02-14   31 dw_hdmi_phy_gen2_pddq(hdmi, 0);
b7c7436a Jernej Skrabec 2018-02-14   32  
b7c7436a Jernej Skrabec 2018-02-14   33 dw_hdmi_phy_i2c_set_addr(hdmi, 
I2C_ADDR);
b7c7436a Jernej Skrabec 2018-02-14   34  
b7c7436a Jernej Skrabec 2018-02-14   35 /*
b7c7436a Jernej Skrabec 2018-02-14   36  * Values are taken from BSP 
HDMI driver. Although AW didn't
b7c7436a Jernej Skrabec 2018-02-14   37  * release any documentation, 
explanation of this values can
b7c7436a Jernej Skrabec 2018-02-14   38  * be found in i.MX 6Dual/6Quad 
Reference Manual.
b7c7436a Jernej Skrabec 2018-02-14   39  */
322900e8 Jernej Skrabec 2018-02-24   40 if (clk_rate <= 2700) {
b7c7436a Jernej Skrabec 2018-02-14   41 
dw_hdmi_phy_i2c_write(hdmi, 0x01e0, 0x06);
b7c7436a Jernej Skrabec 2018-02-14   42 
dw_hdmi_phy_i2c_write(hdmi, 0x, 0x15);
b7c7436a Jernej Skrabec 2018-02-14   43 
dw_hdmi_phy_i2c_write(hdmi, 0x08da, 0x10);
b7c7436a Jernej Skrabec 2018-02-14   44 
dw_hdmi_phy_i2c_write(hdmi, 0x0007, 0x19);
b7c7436a Jernej Skrabec 2018-02-14   45 
dw_hdmi_phy_i2c_write(hdmi, 0x0318, 0x0e);
b7c7436a Jernej Skrabec 2018-02-14   46 
dw_hdmi_phy_i2c_write(hdmi, 0x8009, 0x09);
322900e8 Jernej Skrabec 2018-02-24   47 } else if (clk_rate <= 
7425) {
b7c7436a Jernej Skrabec 2018-02-14   48 
dw_hdmi_phy_i2c_write(hdmi, 0x0540, 0x06);
b7c7436a Jernej Skrabec 2018-02-14   49 
dw_hdmi_phy_i2c_write(hdmi, 0x0005, 0x15);
b7c7436a Jernej Skrabec 2018-02-14   50 
dw_hdmi_phy_i2c_write(hdmi, 0x, 0x10);
b7c7436a Jernej Skrabec 2018-02-14   51 
dw_

Re: [PATCH 2/2] selftests: ion: Add simple test with the vgem driver

[Laura Abbott]

On 02/26/2018 09:07 AM, Shuah Khan wrote:

On 02/19/2018 11:33 AM, Daniel Vetter wrote:

On Mon, Feb 19, 2018 at 10:18:21AM -0800, Laura Abbott wrote:

On 02/19/2018 07:31 AM, Daniel Vetter wrote:

On Thu, Feb 15, 2018 at 05:24:45PM -0800, Laura Abbott wrote:

Ion is designed to be a framework used by other clients who perform
operations on the buffer. Use the DRM vgem client as a simple consumer.
In conjunction with the dma-buf sync ioctls, this tests the full attach/map
path for the system heap.

Signed-off-by: Laura Abbott 
---
   tools/testing/selftests/android/ion/Makefile  |   3 +-
   tools/testing/selftests/android/ion/config|   1 +
   tools/testing/selftests/android/ion/ionmap_test.c | 136 
++
   3 files changed, 139 insertions(+), 1 deletion(-)
   create mode 100644 tools/testing/selftests/android/ion/ionmap_test.c

diff --git a/tools/testing/selftests/android/ion/Makefile 
b/tools/testing/selftests/android/ion/Makefile
index 96e0c448b39d..d23b6d537d8b 100644
--- a/tools/testing/selftests/android/ion/Makefile
+++ b/tools/testing/selftests/android/ion/Makefile
@@ -2,7 +2,7 @@
   INCLUDEDIR := -I. -I../../../../../drivers/staging/android/uapi/
   CFLAGS := $(CFLAGS) $(INCLUDEDIR) -Wall -O2 -g
-TEST_GEN_FILES := ionapp_export ionapp_import
+TEST_GEN_FILES := ionapp_export ionapp_import ionmap_test
   all: $(TEST_GEN_FILES)
@@ -14,3 +14,4 @@ include ../../lib.mk
   $(OUTPUT)/ionapp_export: ionapp_export.c ipcsocket.c ionutils.c
   $(OUTPUT)/ionapp_import: ionapp_import.c ipcsocket.c ionutils.c
+$(OUTPUT)/ionmap_test: ionmap_test.c ionutils.c
diff --git a/tools/testing/selftests/android/ion/config 
b/tools/testing/selftests/android/ion/config
index 19db6ca9aa2b..b4ad748a9dd9 100644
--- a/tools/testing/selftests/android/ion/config
+++ b/tools/testing/selftests/android/ion/config
@@ -2,3 +2,4 @@ CONFIG_ANDROID=y
   CONFIG_STAGING=y
   CONFIG_ION=y
   CONFIG_ION_SYSTEM_HEAP=y
+CONFIG_DRM_VGEM=y
diff --git a/tools/testing/selftests/android/ion/ionmap_test.c 
b/tools/testing/selftests/android/ion/ionmap_test.c
new file mode 100644
index ..dab36b06b37d
--- /dev/null
+++ b/tools/testing/selftests/android/ion/ionmap_test.c
@@ -0,0 +1,136 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+
+#include "ion.h"
+#include "ionutils.h"
+
+int check_vgem(int fd)
+{
+   drm_version_t version = { 0 };
+   char name[5];
+   int ret;
+
+   version.name_len = 4;
+   version.name = name;
+
+   ret = ioctl(fd, DRM_IOCTL_VERSION, );
+   if (ret)
+   return 1;
+
+   return strcmp(name, "vgem");
+}
+
+int open_vgem(void)
+{
+   int i, fd;
+   const char *drmstr = "/dev/dri/card";
+
+   fd = -1;
+   for (i = 0; i < 16; i++) {
+   char name[80];
+
+   sprintf(name, "%s%u", drmstr, i);
+
+   fd = open(name, O_RDWR);
+   if (fd < 0)
+   continue;
+
+   if (check_vgem(fd)) {
+   close(fd);
+   continue;
+   } else {
+   break;
+   }
+
+   }
+   return fd;
+}
+
+int import_vgem_fd(int vgem_fd, int dma_buf_fd, uint32_t *handle)
+{
+   struct drm_prime_handle import_handle = { 0 };
+   int ret;
+
+   import_handle.fd = dma_buf_fd;
+   import_handle.flags = 0;
+   import_handle.handle = 0;
+
+   ret = ioctl(vgem_fd, DRM_IOCTL_PRIME_FD_TO_HANDLE, _handle);
+   if (ret == 0)
+   *handle = import_handle.handle;
+   return ret;
+}
+
+void close_handle(int vgem_fd, uint32_t handle)
+{
+   struct drm_gem_close close = { 0 };
+
+   close.handle = handle;
+   ioctl(vgem_fd, DRM_IOCTL_GEM_CLOSE, );
+}
+
+int main()
+{
+   int ret, vgem_fd;
+   struct ion_buffer_info info;
+   uint32_t handle = 0;
+   struct dma_buf_sync sync = { 0 };
+
+   info.heap_type = ION_HEAP_TYPE_SYSTEM;
+   info.heap_size = 4096;
+   info.flag_type = ION_FLAG_CACHED;
+
+   ret = ion_export_buffer_fd();
+   if (ret < 0) {
+   printf("ion buffer alloc failed\n");
+   return -1;
+   }
+
+   vgem_fd = open_vgem();
+   if (vgem_fd < 0) {
+   ret = vgem_fd;
+   printf("Failed to open vgem\n");
+   goto out_ion;
+   }
+
+   ret = import_vgem_fd(vgem_fd, info.buffd, );
+
+   if (ret < 0) {
+   printf("Failed to import buffer\n");
+   goto out_vgem;
+   }
+
+   sync.flags = DMA_BUF_SYNC_START | DMA_BUF_SYNC_RW;
+   ret = ioctl(info.buffd, DMA_BUF_IOCTL_SYNC, );
+   if (ret)
+   printf("sync start failed %d\n", errno);
+
+   memset(info.buffer, 0xff, 4096);
+
+   sync.flags = DMA_BUF_SYNC_END | DMA_BUF_SYNC_RW;
+   ret = ioctl(info.buffd, DMA_BUF_IOCTL_SYNC, );
+   if 

[Bug 104142] Stack trace in runpm when Tonga card powers down

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=104142

--- Comment #8 from Harry Wentland  ---
Thanks for the update.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104142] Stack trace in runpm when Tonga card powers down

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=104142

Mike Lothian  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #7 from Mike Lothian  ---
I'm running agd5f's drm-next-4.17-wip branch with
https://patchwork.freedesktop.org/series/38985/ applied on top along with
https://github.com/FireBurn/KernelStuff/blob/master/05-remove-warn.patch
removing the WARN_ON(adev->dm.cached_state);

I've reverted the removal of the WARN_ON and it seems to be fixed thanks

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104200] [Vega10] suspend hangs on Vega 64

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=104200

--- Comment #3 from Harry Wentland  ---
We have a few new patches in our staging trees relating to suspend and driver
unload.

Would you be able to try syncing amd-staging-drm-next and see if the issue has
been fixed?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 197925] [amdgpu_dc][carrizo] multiple monitor handling errors

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=197925

Harry Wentland (harry.wentl...@amd.com) changed:

   What|Removed |Added

 CC||harry.wentl...@amd.com

--- Comment #13 from Harry Wentland (harry.wentl...@amd.com) ---
kwkaess, are you talking about the error message when saying "still not fixed"
or the (arguably more disruptive and important) non-desirable behaviors
mentioned in comment 1?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104142] Stack trace in runpm when Tonga card powers down

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=104142

--- Comment #6 from Harry Wentland  ---
We have a few new patches in our staging trees relating to suspend and driver
unload.

Would you be able to try amd-staging-drm-next or drm-next-4.17-wip from
https://cgit.freedesktop.org/~agd5f/linux/?h=drm-next-4.17-wip and see if the
issue is fixed there?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105256] Slow performance using glDrawElements calls with GL_UNSIGNED_BYTE indices

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105256

Roland Scheidegger  changed:

   What|Removed |Added

Summary|Slow performance using  |Slow performance using
   |glDrawElementsBaseVertex|glDrawElements calls with
   ||GL_UNSIGNED_BYTE indices

--- Comment #5 from Roland Scheidegger  ---
FWIW from a driver perspective this isn't really resolved fixed, I'd consider
that a bug. Using GL_UNSIGNED_BYTE indices will never be the optimal solution,
but clearly the driver could do better, as evidenced by the driver for some
other OS (I don't know what the driver does, but it could for instance maintain
a shadow copy, translate indices with a compute shader, the problem likely is
that the driver translates the indices on the cpu for each draw call
currently).

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104064] (DC 4.15-rc2) WARNING: CPU: 4 PID: 75 at drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:601 dm_suspend+0x4e/0x60 [amdgpu]

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=104064

--- Comment #4 from Harry Wentland  ---
We have a few new patches in our staging trees relating to suspend and driver
unload.

Would you be able to try amd-staging-drm-next or drm-next-4.17-wip from
https://cgit.freedesktop.org/~agd5f/linux/?h=drm-next-4.17-wip and see if the
issue is fixed there?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Google Summer of Code 2018

[Martin Peres]

Hi everyone,

Just a quick word to remind you that the X.Org Foundation got accepted
to the Google Summer of Code 2018!

As a potential mentor, if you have a project falling under the
foundation's (large) umbrella that you would like to kick start or get
help finishing, please add it to the list on the ideas page[1] as soon
as possible. Students will start applying on the 12th of March, see the
full timeline[2].

As a student, check out the projects our ideas' page[1]. If you find one
that interests you, check out our application guidelines[3] and, if you
are eligible, contact your potential mentor and start discussing right
away with him/her. We welcome any student who finds the prospect of
working on our Open Source Graphics stack exciting!

I will be once again the primary contact for the X.Org Foundation, so
please ask me anything by email or on IRC (mupuf on freenode). Other
administrators are Alex Deucher and Taylor Campbell (both Cc:ed).

Looking forward to interacting with old and new contributors, and maybe
welcome previous GSoC/EVoC students as mentors now that they grew to
become core contributors and/or have full-time jobs in the Graphics
stack (*wink wink nudge nudge*)!

Martin, on behalf of the X.Org Foundation

[1] https://www.x.org/wiki/SummerOfCodeIdeas/
[2] https://developers.google.com/open-source/gsoc/timeline
[3] https://www.x.org/wiki/GSoCApplication/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105083] Random blinking display

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105083

--- Comment #10 from Harry Wentland  ---
We have some patches that rework our gamma programming in our staging trees.
Would you be able to try amd-staging-drm-next or drm-next-4.17-wip from
https://cgit.freedesktop.org/~agd5f/linux/?h=drm-next-4.17-wip ?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104825] [amdgpu] [drm:gfx_v8_0_hw_fini] *ERROR* KCQ disabled failed (scratch(0xC040)=0x00000000) when unbinding

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=104825

--- Comment #4 from Harry Wentland  ---
Good to hear DC issues are gone. Not sure about the unlock balance myself.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/5] HDCP1.4 fixes

[Rodrigo Vivi]

On Mon, Feb 26, 2018 at 10:42:34PM +0530, Ramalingam C wrote:
> This series addresses the requriement of below HDCP compliance tests
>   DP: 1A-06 and 1B-05
>   HDMI: 1A-04 and 1A-07a
> 
> One of the patch uses the I915 power infra-structure for checking
> the power state of PW#1. Which enables the init path for all legacy
> platforms.
> 
> And encoder specific msg availability detection is moved into hdcp_shim.
> This will help to sync with DP hdcp data availability in the best
> possible way by fielding the CP_IRQ.

Do we want any of these on 4.16 or backported?
Please consider the use of "Fixes:" on whatever makes sense.

Thanks,
Rodrigo.

> 
> 
> Ramalingam C (5):
>   drm/i915: Read HDCP R0 thrice in case of mismatch
>   drm/i915: read Vprime thrice incase of mismatch
>   drm/i915: Check hdcp key loadability
>   drm/i915: Poll hdcp register on sudden NACK
>   drm/i915: Move hdcp msg detection into shim
> 
>  drivers/gpu/drm/i915/intel_dp.c   |  70 ++--
>  drivers/gpu/drm/i915/intel_drv.h  |   6 +-
>  drivers/gpu/drm/i915/intel_hdcp.c | 166 
> +++---
>  drivers/gpu/drm/i915/intel_hdmi.c |  28 ++-
>  4 files changed, 214 insertions(+), 56 deletions(-)
> 
> -- 
> 2.7.4
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105039] No 120hz with 4.15 kernel and DC enabled

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105039

--- Comment #4 from Emanuel Couto  ---
(In reply to Harry Wentland from comment #3)
> This should be fixed in our staging branches.
> 
> Can you try either the amd-staging-drm-next or drm-next-4.17-wip branch from
> Alex's repo. You can find it at
> https://cgit.freedesktop.org/~agd5f/linux/?h=amd-staging-drm-next

I confirmed this bug is fixed on amd-staging-drm-next branch (commit:
82beba2883b2). I'll test drm-next.4.17-wip later as well just to be sure. I
assume this fix is going to be in kernel 4.16 (or already is)?

BTW I really like what AMD is doing regarding Linux. Thanks.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Move hdcp msg detection into shim

[Chris Wilson]

Quoting Ramalingam C (2018-02-26 17:12:39)
> DP and HDMI HDCP specifications are varying with respect to
> detecting the R0 and ksv_fifo availability.
> 
> DP will produce CP_IRQ and set a bit for indicating the R0 and
> FIFO_READY status.
> 
> Whereas HDMI will set a bit for FIFO_READY but there is no bit
> indication for R0 ready. And also polling of READY bit is needed for
> HDMI as ther is no CP_IRQ.
> 
> So Fielding the CP_IRQ for DP and the polling the READY bit for a
> period and blindly waiting for a fixed time for R0 incase of HDMI are
> moved into corresponding hdcp_shim.
> 
> Signed-off-by: Ramalingam C 
> ---
> +static int intel_dp_hdcp_wait_for_cp_irq(struct completion *cp_irq_recved,
> +int timeout)
> +{
> +   long ret;
> +
> +   if (completion_done(cp_irq_recved))
> +   reinit_completion(cp_irq_recved);
> +
> +   ret = wait_for_completion_interruptible_timeout(cp_irq_recved,
> +   msecs_to_jiffies(
> +   timeout));
> +   reinit_completion(cp_irq_recved);

This is not thread-safe.

The trick is to use a waitqueue to interrupt the sleeps inside the wait
loops to complete the polling quicker. (As stated, you can't escape the
polling, and you always need to check the IRQ was for the event you
expected anyway.)
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105262] ttf fonts are invisible

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105262

--- Comment #1 from Pavel Vinogradov  ---
Created attachment 137623
  --> https://bugs.freedesktop.org/attachment.cgi?id=137623=edit
Xorg.log

Xorg.log with today's build of mesa from git.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105262] ttf fonts are invisible

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105262

Bug ID: 105262
   Summary: ttf fonts are invisible
   Product: Mesa
   Version: git
  Hardware: Other
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: pub...@sourcemage.org
QA Contact: dri-devel@lists.freedesktop.org

Created attachment 137622
  --> https://bugs.freedesktop.org/attachment.cgi?id=137622=edit
gvim main window as an example

Video: Radeon 4650HD PRO
Xorg: 1.19.6
Kernel: 4.15.6

Non-TTF fonts are rendered fine. Also, Firefox and LibreOffice can render TTF
in their work areas, but not in gtk interface.

Mesa 17.3.5 is unaffected.

Attached screenshot illustrates the bug.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 15/15] v4l: vsp1: Rename BRU to BRx

[Laurent Pinchart]

Some VSP instances have two blending units named BRU (Blend/ROP Unit)
and BRS (Blend/ROP Sub unit). The BRS is a smaller version of the BRU
with only two inputs, but otherwise offers similar features and offers
the same register interface. The BRU and BRS can be used exchangeably in
VSP pipelines (provided no more than two inputs are needed).

Due to historical reasons, the VSP1 driver implements support for both
the BRU and BRS through objects named vsp1_bru. The code uses the name
BRU to refer to either the BRU or the BRS, except in a few places where
noted explicitly. This creates confusion.

In an effort to avoid confusion, rename the vsp1_bru object and the
corresponding API to vsp1_brx, and use BRx to refer to blend unit
instances regardless of their type. The names BRU and BRS are retained
where reference to a particular blend unit type is needed, as well as in
hardware registers to stay close to the datasheet.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/Makefile   |   2 +-
 drivers/media/platform/vsp1/vsp1.h |   6 +-
 .../media/platform/vsp1/{vsp1_bru.c => vsp1_brx.c} | 202 ++---
 .../media/platform/vsp1/{vsp1_bru.h => vsp1_brx.h} |  18 +-
 drivers/media/platform/vsp1/vsp1_drm.c | 172 +-
 drivers/media/platform/vsp1/vsp1_drm.h |   6 +-
 drivers/media/platform/vsp1/vsp1_drv.c |   6 +-
 drivers/media/platform/vsp1/vsp1_pipe.c|  12 +-
 drivers/media/platform/vsp1/vsp1_pipe.h|   4 +-
 drivers/media/platform/vsp1/vsp1_rpf.c |  12 +-
 drivers/media/platform/vsp1/vsp1_rwpf.h|   2 +-
 drivers/media/platform/vsp1/vsp1_video.c   |  16 +-
 drivers/media/platform/vsp1/vsp1_wpf.c |   8 +-
 13 files changed, 233 insertions(+), 233 deletions(-)
 rename drivers/media/platform/vsp1/{vsp1_bru.c => vsp1_brx.c} (63%)
 rename drivers/media/platform/vsp1/{vsp1_bru.h => vsp1_brx.h} (66%)

diff --git a/drivers/media/platform/vsp1/Makefile 
b/drivers/media/platform/vsp1/Makefile
index f5cd6f0491cb..596775f932c0 100644
--- a/drivers/media/platform/vsp1/Makefile
+++ b/drivers/media/platform/vsp1/Makefile
@@ -3,7 +3,7 @@ vsp1-y  := vsp1_drv.o 
vsp1_entity.o vsp1_pipe.o
 vsp1-y += vsp1_dl.o vsp1_drm.o vsp1_video.o
 vsp1-y += vsp1_rpf.o vsp1_rwpf.o vsp1_wpf.o
 vsp1-y += vsp1_clu.o vsp1_hsit.o vsp1_lut.o
-vsp1-y += vsp1_bru.o vsp1_sru.o vsp1_uds.o
+vsp1-y += vsp1_brx.o vsp1_sru.o vsp1_uds.o
 vsp1-y += vsp1_hgo.o vsp1_hgt.o vsp1_histo.o
 vsp1-y += vsp1_lif.o
 
diff --git a/drivers/media/platform/vsp1/vsp1.h 
b/drivers/media/platform/vsp1/vsp1.h
index 78ef838416b3..894cc725c2d4 100644
--- a/drivers/media/platform/vsp1/vsp1.h
+++ b/drivers/media/platform/vsp1/vsp1.h
@@ -30,7 +30,7 @@ struct rcar_fcp_device;
 struct vsp1_drm;
 struct vsp1_entity;
 struct vsp1_platform_data;
-struct vsp1_bru;
+struct vsp1_brx;
 struct vsp1_clu;
 struct vsp1_hgo;
 struct vsp1_hgt;
@@ -78,8 +78,8 @@ struct vsp1_device {
struct rcar_fcp_device *fcp;
struct device *bus_master;
 
-   struct vsp1_bru *brs;
-   struct vsp1_bru *bru;
+   struct vsp1_brx *brs;
+   struct vsp1_brx *bru;
struct vsp1_clu *clu;
struct vsp1_hgo *hgo;
struct vsp1_hgt *hgt;
diff --git a/drivers/media/platform/vsp1/vsp1_bru.c 
b/drivers/media/platform/vsp1/vsp1_brx.c
similarity index 63%
rename from drivers/media/platform/vsp1/vsp1_bru.c
rename to drivers/media/platform/vsp1/vsp1_brx.c
index e8fd2ae3b3eb..b4af1d546022 100644
--- a/drivers/media/platform/vsp1/vsp1_bru.c
+++ b/drivers/media/platform/vsp1/vsp1_brx.c
@@ -1,5 +1,5 @@
 /*
- * vsp1_bru.c  --  R-Car VSP1 Blend ROP Unit
+ * vsp1_brx.c  --  R-Car VSP1 Blend ROP Unit (BRU and BRS)
  *
  * Copyright (C) 2013 Renesas Corporation
  *
@@ -17,45 +17,45 @@
 #include 
 
 #include "vsp1.h"
-#include "vsp1_bru.h"
+#include "vsp1_brx.h"
 #include "vsp1_dl.h"
 #include "vsp1_pipe.h"
 #include "vsp1_rwpf.h"
 #include "vsp1_video.h"
 
-#define BRU_MIN_SIZE   1U
-#define BRU_MAX_SIZE   8190U
+#define BRX_MIN_SIZE   1U
+#define BRX_MAX_SIZE   8190U
 
 /* 
-
  * Device Access
  */
 
-static inline void vsp1_bru_write(struct vsp1_bru *bru, struct vsp1_dl_list 
*dl,
+static inline void vsp1_brx_write(struct vsp1_brx *brx, struct vsp1_dl_list 
*dl,
  u32 reg, u32 data)
 {
-   vsp1_dl_list_write(dl, bru->base + reg, data);
+   vsp1_dl_list_write(dl, brx->base + reg, data);
 }
 
 /* 

[PATCH 13/15] v4l: vsp1: Assign BRU and BRS to pipelines dynamically

[Laurent Pinchart]

The VSPDL variant drives two DU channels through two LIF and two
blenders, BRU and BRS. The DU channels thus share the five available
VSPDL inputs and expose them as five KMS planes.

The current implementation assigns the BRS to the second LIF and thus
artificially limits the number of planes for the second display channel
to two at most.

Lift this artificial limitation by assigning the BRU and BRS to the
display pipelines on demand based on the number of planes used by each
pipeline. When a display pipeline needs more than two inputs and the BRU
is already in use by the other pipeline, this requires reconfiguring the
other pipeline to free the BRU before processing, which can result in
frame drop on both pipelines.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_drm.c | 160 +++--
 drivers/media/platform/vsp1/vsp1_drm.h |   9 ++
 2 files changed, 144 insertions(+), 25 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index 6c60b72b6f50..87e31ba0ddf5 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -39,7 +39,13 @@ static void vsp1_du_pipeline_frame_end(struct vsp1_pipeline 
*pipe,
struct vsp1_drm_pipeline *drm_pipe = to_vsp1_drm_pipeline(pipe);
 
if (drm_pipe->du_complete)
-   drm_pipe->du_complete(drm_pipe->du_private, completed);
+   drm_pipe->du_complete(drm_pipe->du_private,
+ completed && !notify);
+
+   if (notify) {
+   drm_pipe->force_bru_release = false;
+   wake_up(_pipe->wait_queue);
+   }
 }
 
 /* 
-
@@ -149,6 +155,10 @@ static int vsp1_du_pipeline_setup_rpf(struct vsp1_device 
*vsp1,
 }
 
 /* Setup the BRU source pad. */
+static int vsp1_du_pipeline_setup_input(struct vsp1_device *vsp1,
+   struct vsp1_pipeline *pipe);
+static void vsp1_du_pipeline_configure(struct vsp1_pipeline *pipe);
+
 static int vsp1_du_pipeline_setup_bru(struct vsp1_device *vsp1,
  struct vsp1_pipeline *pipe)
 {
@@ -156,8 +166,93 @@ static int vsp1_du_pipeline_setup_bru(struct vsp1_device 
*vsp1,
struct v4l2_subdev_format format = {
.which = V4L2_SUBDEV_FORMAT_ACTIVE,
};
+   struct vsp1_entity *bru;
int ret;
 
+   /*
+* Pick a BRU:
+* - If we need more than two inputs, use the main BRU.
+* - Otherwise, if we are not forced to release our BRU, keep it.
+* - Else, use any free BRU (randomly starting with the main BRU).
+*/
+   if (pipe->num_inputs > 2)
+   bru = >bru->entity;
+   else if (pipe->bru && !drm_pipe->force_bru_release)
+   bru = pipe->bru;
+   else if (!vsp1->bru->entity.pipe)
+   bru = >bru->entity;
+   else
+   bru = >brs->entity;
+
+   /* Switch BRU if needed. */
+   if (bru != pipe->bru) {
+   struct vsp1_entity *released_bru = NULL;
+
+   /* Release our BRU if we have one. */
+   if (pipe->bru) {
+   /*
+* The BRU might be acquired by the other pipeline in
+* the next step. We must thus remove it from the list
+* of entities for this pipeline. The other pipeline's
+* hardware configuration will reconfigure the BRU
+* routing.
+*
+* However, if the other pipeline doesn't acquire our
+* BRU, we need to keep it in the list, otherwise the
+* hardware configuration step won't disconnect it from
+* the pipeline. To solve this, store the released BRU
+* pointer to add it back to the list of entities later
+* if it isn't acquired by the other pipeline.
+*/
+   released_bru = pipe->bru;
+
+   list_del(>bru->list_pipe);
+   pipe->bru->sink = NULL;
+   pipe->bru->pipe = NULL;
+   pipe->bru = NULL;
+   }
+
+   /*
+* If the BRU we need is in use, force the owner pipeline to
+* switch to the other BRU and wait until the switch completes.
+*/
+   if (bru->pipe) {
+   struct vsp1_drm_pipeline *owner_pipe;
+
+   owner_pipe = to_vsp1_drm_pipeline(bru->pipe);
+   owner_pipe->force_bru_release = true;
+
+   vsp1_du_pipeline_setup_input(vsp1, _pipe->pipe);
+   

[PATCH 11/15] v4l: vsp1: Add per-display list completion notification support

[Laurent Pinchart]

Display list completion is already reported to the frame end handler,
but that mechanism is global to all display lists. In order to implement
BRU and BRS reassignment in DRM pipelines we will need to wait for
completion of a particular display list. Extend the display list and
frame end handler APIs to support such a notification.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_dl.c| 27 +--
 drivers/media/platform/vsp1/vsp1_dl.h|  4 ++--
 drivers/media/platform/vsp1/vsp1_drm.c   |  4 ++--
 drivers/media/platform/vsp1/vsp1_pipe.c  |  5 +++--
 drivers/media/platform/vsp1/vsp1_pipe.h  |  3 ++-
 drivers/media/platform/vsp1/vsp1_video.c |  4 ++--
 6 files changed, 36 insertions(+), 11 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
b/drivers/media/platform/vsp1/vsp1_dl.c
index 0b86ed01e85d..eb2971218e28 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -72,6 +72,7 @@ struct vsp1_dl_body {
  * @fragments: list of extra display list bodies
  * @has_chain: if true, indicates that there's a partition chain
  * @chain: entry in the display list partition chain
+ * @notify: whether the display list completion should be notified
  */
 struct vsp1_dl_list {
struct list_head list;
@@ -85,6 +86,8 @@ struct vsp1_dl_list {
 
bool has_chain;
struct list_head chain;
+
+   bool notify;
 };
 
 enum vsp1_dl_mode {
@@ -550,8 +553,16 @@ static void vsp1_dl_list_commit_continuous(struct 
vsp1_dl_list *dl)
 * case we can't replace the queued list by the new one, as we could
 * race with the hardware. We thus mark the update as pending, it will
 * be queued up to the hardware by the frame end interrupt handler.
+*
+* If a display list is already pending we simply drop it as the new
+* display list is assumed to contain a more recent configuration. It is
+* an error if the already pending list has the notify flag set, as
+* there is then a process waiting for that list to complete. This
+* shouldn't happen as the waiting process should perform proper
+* locking, but warn just in case.
 */
if (vsp1_dl_list_hw_update_pending(dlm)) {
+   WARN_ON(dlm->pending && dlm->pending->notify);
__vsp1_dl_list_put(dlm->pending);
dlm->pending = dl;
return;
@@ -581,7 +592,7 @@ static void vsp1_dl_list_commit_singleshot(struct 
vsp1_dl_list *dl)
dlm->active = dl;
 }
 
-void vsp1_dl_list_commit(struct vsp1_dl_list *dl)
+void vsp1_dl_list_commit(struct vsp1_dl_list *dl, bool notify)
 {
struct vsp1_dl_manager *dlm = dl->dlm;
struct vsp1_dl_list *dl_child;
@@ -598,6 +609,8 @@ void vsp1_dl_list_commit(struct vsp1_dl_list *dl)
}
}
 
+   dl->notify = notify;
+
spin_lock_irqsave(>lock, flags);
 
if (dlm->singleshot)
@@ -615,16 +628,23 @@ void vsp1_dl_list_commit(struct vsp1_dl_list *dl)
 /**
  * vsp1_dlm_irq_frame_end - Display list handler for the frame end interrupt
  * @dlm: the display list manager
+ * @notify: whether the display list that completed has notification enabled
  *
  * Return true if the previous display list has completed at frame end, or 
false
  * if it has been delayed by one frame because the display list commit raced
  * with the frame end interrupt. The function always returns true in header 
mode
  * as display list processing is then not continuous and races never occur.
+ *
+ * Upon return, the @notify parameter is set to true if the previous display
+ * list has completed and had been queued with the notify flag, or to false
+ * otherwise. Notification is only supported for continuous mode.
  */
-bool vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
+bool vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm, bool *notify)
 {
bool completed = false;
 
+   *notify = false;
+
spin_lock(>lock);
 
/*
@@ -652,6 +672,9 @@ bool vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
 * frame end interrupt. The display list thus becomes active.
 */
if (dlm->queued) {
+   *notify = dlm->queued->notify;
+   dlm->queued->notify = false;
+
__vsp1_dl_list_put(dlm->active);
dlm->active = dlm->queued;
dlm->queued = NULL;
diff --git a/drivers/media/platform/vsp1/vsp1_dl.h 
b/drivers/media/platform/vsp1/vsp1_dl.h
index ee3508172f0a..480c6b0dd2e4 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.h
+++ b/drivers/media/platform/vsp1/vsp1_dl.h
@@ -27,12 +27,12 @@ struct vsp1_dl_manager *vsp1_dlm_create(struct vsp1_device 
*vsp1,
unsigned int prealloc);
 void vsp1_dlm_destroy(struct vsp1_dl_manager *dlm);
 void vsp1_dlm_reset(struct vsp1_dl_manager *dlm);
-bool 

[Bug 104274] Unable to cleanly unload kernel module: BUG: unable to handle kernel NULL pointer dereference at 0000000000000258 (mutex_lock)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=104274

--- Comment #10 from Jordan L  ---
Hi Luke, it actually looks like you're running with DC disabled. Can you also
try with amdgpu.dc=1 explicitly set? Potentially there are issues in multiple
IP blocks, though we fixed a driver unload issue recently with DC enabled.


Thanks

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 09/15] v4l: vsp1: Replace manual DRM pipeline input setup in vsp1_du_setup_lif

[Laurent Pinchart]

The vsp1_du_setup_lif() function setups the DRM pipeline input manually.
This duplicates the code from the vsp1_du_pipeline_setup_input()
function. Replace the manual implementation by a call to the function.

As the pipeline has no enabled input in vsp1_du_setup_lif(), the
vsp1_du_pipeline_setup_input() function will not setup any RPF, and will
thus not setup formats on the BRU sink pads. This isn't a problem as all
inputs are disabled, and the BRU sink pads will be reconfigured from the
atomic commit handler when inputs will be enabled.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_drm.c | 40 +-
 1 file changed, 6 insertions(+), 34 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index 6ad8aa6c8138..00ce99bd1605 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -412,47 +412,19 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int 
pipe_index,
dev_dbg(vsp1->dev, "%s: configuring LIF%u with format %ux%u\n",
__func__, pipe_index, cfg->width, cfg->height);
 
-   /*
-* Configure the format at the BRU sinks and propagate it through the
-* pipeline.
-*/
+   /* Setup formats through the pipeline. */
+   ret = vsp1_du_pipeline_setup_input(vsp1, pipe);
+   if (ret < 0)
+   return ret;
+
memset(, 0, sizeof(format));
format.which = V4L2_SUBDEV_FORMAT_ACTIVE;
-
-   for (i = 0; i < pipe->bru->source_pad; ++i) {
-   format.pad = i;
-
-   format.format.width = cfg->width;
-   format.format.height = cfg->height;
-   format.format.code = MEDIA_BUS_FMT_ARGB_1X32;
-   format.format.field = V4L2_FIELD_NONE;
-
-   ret = v4l2_subdev_call(>bru->subdev, pad,
-  set_fmt, NULL, );
-   if (ret < 0)
-   return ret;
-
-   dev_dbg(vsp1->dev, "%s: set format %ux%u (%x) on %s pad %u\n",
-   __func__, format.format.width, format.format.height,
-   format.format.code, BRU_NAME(pipe->bru), i);
-   }
-
-   format.pad = pipe->bru->source_pad;
+   format.pad = RWPF_PAD_SINK;
format.format.width = cfg->width;
format.format.height = cfg->height;
format.format.code = MEDIA_BUS_FMT_ARGB_1X32;
format.format.field = V4L2_FIELD_NONE;
 
-   ret = v4l2_subdev_call(>bru->subdev, pad, set_fmt, NULL,
-  );
-   if (ret < 0)
-   return ret;
-
-   dev_dbg(vsp1->dev, "%s: set format %ux%u (%x) on %s pad %u\n",
-   __func__, format.format.width, format.format.height,
-   format.format.code, BRU_NAME(pipe->bru), i);
-
-   format.pad = RWPF_PAD_SINK;
ret = v4l2_subdev_call(>output->entity.subdev, pad, set_fmt, NULL,
   );
if (ret < 0)
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 08/15] v4l: vsp1: Setup BRU at atomic commit time

[Laurent Pinchart]

To implement fully dynamic plane assignment to pipelines, we need to
reassign the BRU and BRS to the DRM pipelines in the atomic commit
handler. In preparation for this setup factor out the BRU source pad
code and call it both at LIF setup and atomic commit time.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_drm.c | 56 +-
 drivers/media/platform/vsp1/vsp1_drm.h |  5 +++
 2 files changed, 60 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index 7bf697ba7969..6ad8aa6c8138 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -148,12 +148,51 @@ static int vsp1_du_pipeline_setup_rpf(struct vsp1_device 
*vsp1,
return 0;
 }
 
+/* Setup the BRU source pad. */
+static int vsp1_du_pipeline_setup_bru(struct vsp1_device *vsp1,
+ struct vsp1_pipeline *pipe)
+{
+   struct vsp1_drm_pipeline *drm_pipe = to_vsp1_drm_pipeline(pipe);
+   struct v4l2_subdev_format format = {
+   .which = V4L2_SUBDEV_FORMAT_ACTIVE,
+   };
+   int ret;
+
+   /*
+* Configure the format on the BRU source and verify that it matches the
+* requested format. We don't set the media bus code as it is configured
+* on the BRU sink pad 0 and propagated inside the entity, not on the
+* source pad.
+*/
+   format.pad = pipe->bru->source_pad;
+   format.format.width = drm_pipe->width;
+   format.format.height = drm_pipe->height;
+   format.format.field = V4L2_FIELD_NONE;
+
+   ret = v4l2_subdev_call(>bru->subdev, pad, set_fmt, NULL,
+  );
+   if (ret < 0)
+   return ret;
+
+   dev_dbg(vsp1->dev, "%s: set format %ux%u (%x) on %s pad %u\n",
+   __func__, format.format.width, format.format.height,
+   format.format.code, BRU_NAME(pipe->bru), pipe->bru->source_pad);
+
+   if (format.format.width != drm_pipe->width ||
+   format.format.height != drm_pipe->height) {
+   dev_dbg(vsp1->dev, "%s: format mismatch\n", __func__);
+   return -EPIPE;
+   }
+
+   return 0;
+}
+
 static unsigned int rpf_zpos(struct vsp1_device *vsp1, struct vsp1_rwpf *rpf)
 {
return vsp1->drm->inputs[rpf->entity.index].zpos;
 }
 
-/* Setup the input side of the pipeline (RPFs and BRU sink pads). */
+/* Setup the input side of the pipeline (RPFs and BRU). */
 static int vsp1_du_pipeline_setup_input(struct vsp1_device *vsp1,
struct vsp1_pipeline *pipe)
 {
@@ -191,6 +230,18 @@ static int vsp1_du_pipeline_setup_input(struct vsp1_device 
*vsp1,
inputs[j] = rpf;
}
 
+   /*
+* Setup the BRU. This must be done before setting up the RPF input
+* pipelines as the BRU sink compose rectangles depend on the BRU source
+* format.
+*/
+   ret = vsp1_du_pipeline_setup_bru(vsp1, pipe);
+   if (ret < 0) {
+   dev_err(vsp1->dev, "%s: failed to setup %s source\n", __func__,
+   BRU_NAME(pipe->bru));
+   return ret;
+   }
+
/* Setup the RPF input pipeline for every enabled input. */
for (i = 0; i < pipe->bru->source_pad; ++i) {
struct vsp1_rwpf *rpf = inputs[i];
@@ -355,6 +406,9 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int 
pipe_index,
return 0;
}
 
+   drm_pipe->width = cfg->width;
+   drm_pipe->height = cfg->height;
+
dev_dbg(vsp1->dev, "%s: configuring LIF%u with format %ux%u\n",
__func__, pipe_index, cfg->width, cfg->height);
 
diff --git a/drivers/media/platform/vsp1/vsp1_drm.h 
b/drivers/media/platform/vsp1/vsp1_drm.h
index 9aa19325cbe9..c8dd75ba01f6 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.h
+++ b/drivers/media/platform/vsp1/vsp1_drm.h
@@ -20,12 +20,17 @@
 /**
  * vsp1_drm_pipeline - State for the API exposed to the DRM driver
  * @pipe: the VSP1 pipeline used for display
+ * @width: output display width
+ * @height: output display height
  * @du_complete: frame completion callback for the DU driver (optional)
  * @du_private: data to be passed to the du_complete callback
  */
 struct vsp1_drm_pipeline {
struct vsp1_pipeline pipe;
 
+   unsigned int width;
+   unsigned int height;
+
/* Frame synchronisation */
void (*du_complete)(void *, bool);
void *du_private;
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 14/15] v4l: vsp1: Add BRx dynamic assignment debugging messages

[Laurent Pinchart]

Dynamic assignment of the BRU and BRS to pipelines is prone to
regressions, add messages to make debugging easier. Keep it as a
separate commit to ease removal of those messages once the code will
deem to be completely stable.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_drm.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index 87e31ba0ddf5..521bbc227110 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -190,6 +190,10 @@ static int vsp1_du_pipeline_setup_bru(struct vsp1_device 
*vsp1,
 
/* Release our BRU if we have one. */
if (pipe->bru) {
+   dev_dbg(vsp1->dev, "%s: pipe %u: releasing %s\n",
+   __func__, pipe->lif->index,
+   BRU_NAME(pipe->bru));
+
/*
 * The BRU might be acquired by the other pipeline in
 * the next step. We must thus remove it from the list
@@ -219,6 +223,9 @@ static int vsp1_du_pipeline_setup_bru(struct vsp1_device 
*vsp1,
if (bru->pipe) {
struct vsp1_drm_pipeline *owner_pipe;
 
+   dev_dbg(vsp1->dev, "%s: pipe %u: waiting for %s\n",
+   __func__, pipe->lif->index, BRU_NAME(bru));
+
owner_pipe = to_vsp1_drm_pipeline(bru->pipe);
owner_pipe->force_bru_release = true;
 
@@ -245,6 +252,9 @@ static int vsp1_du_pipeline_setup_bru(struct vsp1_device 
*vsp1,
  >entities);
 
/* Add the BRU to the pipeline. */
+   dev_dbg(vsp1->dev, "%s: pipe %u: acquired %s\n",
+   __func__, pipe->lif->index, BRU_NAME(bru));
+
pipe->bru = bru;
pipe->bru->pipe = pipe;
pipe->bru->sink = >output->entity;
@@ -549,6 +559,10 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int 
pipe_index,
drm_pipe->du_complete = NULL;
pipe->num_inputs = 0;
 
+   dev_dbg(vsp1->dev, "%s: pipe %u: releasing %s\n",
+   __func__, pipe->lif->index,
+   BRU_NAME(pipe->bru));
+
list_del(>bru->list_pipe);
pipe->bru->pipe = NULL;
pipe->bru = NULL;
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 06/15] v4l: vsp1: Share duplicated DRM pipeline configuration code

[Laurent Pinchart]

Move the duplicated DRM pipeline configuration code to a function and
call it from vsp1_du_setup_lif() and vsp1_du_atomic_flush().

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_drm.c | 95 +++---
 1 file changed, 43 insertions(+), 52 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index e210917fdc3f..9a043a915c0b 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -42,6 +42,47 @@ static void vsp1_du_pipeline_frame_end(struct vsp1_pipeline 
*pipe,
drm_pipe->du_complete(drm_pipe->du_private, completed);
 }
 
+/* 
-
+ * Pipeline Configuration
+ */
+
+/* Configure all entities in the pipeline. */
+static void vsp1_du_pipeline_configure(struct vsp1_pipeline *pipe)
+{
+   struct vsp1_entity *entity;
+   struct vsp1_entity *next;
+   struct vsp1_dl_list *dl;
+
+   dl = vsp1_dl_list_get(pipe->output->dlm);
+
+   list_for_each_entry_safe(entity, next, >entities, list_pipe) {
+   /* Disconnect unused RPFs from the pipeline. */
+   if (entity->type == VSP1_ENTITY_RPF &&
+   !pipe->inputs[entity->index]) {
+   vsp1_dl_list_write(dl, entity->route->reg,
+  VI6_DPR_NODE_UNUSED);
+
+   entity->pipe = NULL;
+   list_del(>list_pipe);
+
+   continue;
+   }
+
+   vsp1_entity_route_setup(entity, pipe, dl);
+
+   if (entity->ops->configure) {
+   entity->ops->configure(entity, pipe, dl,
+  VSP1_ENTITY_PARAMS_INIT);
+   entity->ops->configure(entity, pipe, dl,
+  VSP1_ENTITY_PARAMS_RUNTIME);
+   entity->ops->configure(entity, pipe, dl,
+  VSP1_ENTITY_PARAMS_PARTITION);
+   }
+   }
+
+   vsp1_dl_list_commit(dl);
+}
+
 /* 
-
  * DU Driver API
  */
@@ -85,9 +126,6 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int 
pipe_index,
struct vsp1_drm_pipeline *drm_pipe;
struct vsp1_pipeline *pipe;
struct vsp1_bru *bru;
-   struct vsp1_entity *entity;
-   struct vsp1_entity *next;
-   struct vsp1_dl_list *dl;
struct v4l2_subdev_format format;
unsigned long flags;
unsigned int i;
@@ -239,22 +277,7 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int 
pipe_index,
vsp1_write(vsp1, VI6_DISP_IRQ_ENB, 0);
 
/* Configure all entities in the pipeline. */
-   dl = vsp1_dl_list_get(pipe->output->dlm);
-
-   list_for_each_entry_safe(entity, next, >entities, list_pipe) {
-   vsp1_entity_route_setup(entity, pipe, dl);
-
-   if (entity->ops->configure) {
-   entity->ops->configure(entity, pipe, dl,
-  VSP1_ENTITY_PARAMS_INIT);
-   entity->ops->configure(entity, pipe, dl,
-  VSP1_ENTITY_PARAMS_RUNTIME);
-   entity->ops->configure(entity, pipe, dl,
-  VSP1_ENTITY_PARAMS_PARTITION);
-   }
-   }
-
-   vsp1_dl_list_commit(dl);
+   vsp1_du_pipeline_configure(pipe);
 
/* Start the pipeline. */
spin_lock_irqsave(>irqlock, flags);
@@ -490,15 +513,9 @@ void vsp1_du_atomic_flush(struct device *dev, unsigned int 
pipe_index)
struct vsp1_pipeline *pipe = _pipe->pipe;
struct vsp1_rwpf *inputs[VSP1_MAX_RPF] = { NULL, };
struct vsp1_bru *bru = to_bru(>bru->subdev);
-   struct vsp1_entity *entity;
-   struct vsp1_entity *next;
-   struct vsp1_dl_list *dl;
unsigned int i;
int ret;
 
-   /* Prepare the display list. */
-   dl = vsp1_dl_list_get(pipe->output->dlm);
-
/* Count the number of enabled inputs and sort them by Z-order. */
pipe->num_inputs = 0;
 
@@ -557,33 +574,7 @@ void vsp1_du_atomic_flush(struct device *dev, unsigned int 
pipe_index)
__func__, rpf->entity.index);
}
 
-   /* Configure all entities in the pipeline. */
-   list_for_each_entry_safe(entity, next, >entities, list_pipe) {
-   /* Disconnect unused RPFs from the pipeline. */
-   if (entity->type == VSP1_ENTITY_RPF &&
-   !pipe->inputs[entity->index]) {
-   vsp1_dl_list_write(dl, entity->route->reg,
-  VI6_DPR_NODE_UNUSED);
-
-   

[PATCH 12/15] v4l: vsp1: Generalize detection of entity removal from DRM pipeline

[Laurent Pinchart]

When disabling a DRM plane, the corresponding RPF is only marked as
removed from the pipeline in the atomic update handler, with the actual
removal happening when configuring the pipeline at atomic commit time.
This is required as the RPF has to be disabled in the hardware, which
can't be done from the atomic update handler.

The current implementation is RPF-specific. Make it independent of the
entity type by using the entity's pipe pointer to mark removal from the
pipeline. This will allow using the mechanism to remove BRU instances.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_drm.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index d705a6e9fa1d..6c60b72b6f50 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -346,13 +346,12 @@ static void vsp1_du_pipeline_configure(struct 
vsp1_pipeline *pipe)
dl = vsp1_dl_list_get(pipe->output->dlm);
 
list_for_each_entry_safe(entity, next, >entities, list_pipe) {
-   /* Disconnect unused RPFs from the pipeline. */
-   if (entity->type == VSP1_ENTITY_RPF &&
-   !pipe->inputs[entity->index]) {
+   /* Disconnect unused entities from the pipeline. */
+   if (!entity->pipe) {
vsp1_dl_list_write(dl, entity->route->reg,
   VI6_DPR_NODE_UNUSED);
 
-   entity->pipe = NULL;
+   entity->sink = NULL;
list_del(>list_pipe);
 
continue;
@@ -569,10 +568,11 @@ int vsp1_du_atomic_update(struct device *dev, unsigned 
int pipe_index,
rpf_index);
 
/*
-* Remove the RPF from the pipe's inputs. The atomic flush
-* handler will disable the input and remove the entity from the
-* pipe's entities list.
+* Remove the RPF from the pipeline's inputs. Keep it in the
+* pipeline's entity list to let vsp1_du_pipeline_configure()
+* remove it from the hardware pipeline.
 */
+   rpf->entity.pipe = NULL;
drm_pipe->pipe.inputs[rpf_index] = NULL;
return 0;
}
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 07/15] v4l: vsp1: Move DRM atomic commit pipeline setup to separate function

[Laurent Pinchart]

The DRM pipeline setup code used at atomic commit time is similar to the
setup code used when enabling the pipeline. Move it to a separate
function in order to share it.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_drm.c | 347 +
 1 file changed, 180 insertions(+), 167 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index 9a043a915c0b..7bf697ba7969 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -46,6 +46,185 @@ static void vsp1_du_pipeline_frame_end(struct vsp1_pipeline 
*pipe,
  * Pipeline Configuration
  */
 
+/* Setup one RPF and the connected BRU sink pad. */
+static int vsp1_du_pipeline_setup_rpf(struct vsp1_device *vsp1,
+ struct vsp1_pipeline *pipe,
+ struct vsp1_rwpf *rpf,
+ unsigned int bru_input)
+{
+   struct v4l2_subdev_selection sel;
+   struct v4l2_subdev_format format;
+   const struct v4l2_rect *crop;
+   int ret;
+
+   /*
+* Configure the format on the RPF sink pad and propagate it up to the
+* BRU sink pad.
+*/
+   crop = >drm->inputs[rpf->entity.index].crop;
+
+   memset(, 0, sizeof(format));
+   format.which = V4L2_SUBDEV_FORMAT_ACTIVE;
+   format.pad = RWPF_PAD_SINK;
+   format.format.width = crop->width + crop->left;
+   format.format.height = crop->height + crop->top;
+   format.format.code = rpf->fmtinfo->mbus;
+   format.format.field = V4L2_FIELD_NONE;
+
+   ret = v4l2_subdev_call(>entity.subdev, pad, set_fmt, NULL,
+  );
+   if (ret < 0)
+   return ret;
+
+   dev_dbg(vsp1->dev,
+   "%s: set format %ux%u (%x) on RPF%u sink\n",
+   __func__, format.format.width, format.format.height,
+   format.format.code, rpf->entity.index);
+
+   memset(, 0, sizeof(sel));
+   sel.which = V4L2_SUBDEV_FORMAT_ACTIVE;
+   sel.pad = RWPF_PAD_SINK;
+   sel.target = V4L2_SEL_TGT_CROP;
+   sel.r = *crop;
+
+   ret = v4l2_subdev_call(>entity.subdev, pad, set_selection, NULL,
+  );
+   if (ret < 0)
+   return ret;
+
+   dev_dbg(vsp1->dev,
+   "%s: set selection (%u,%u)/%ux%u on RPF%u sink\n",
+   __func__, sel.r.left, sel.r.top, sel.r.width, sel.r.height,
+   rpf->entity.index);
+
+   /*
+* RPF source, hardcode the format to ARGB to turn on format
+* conversion if needed.
+*/
+   format.pad = RWPF_PAD_SOURCE;
+
+   ret = v4l2_subdev_call(>entity.subdev, pad, get_fmt, NULL,
+  );
+   if (ret < 0)
+   return ret;
+
+   dev_dbg(vsp1->dev,
+   "%s: got format %ux%u (%x) on RPF%u source\n",
+   __func__, format.format.width, format.format.height,
+   format.format.code, rpf->entity.index);
+
+   format.format.code = MEDIA_BUS_FMT_ARGB_1X32;
+
+   ret = v4l2_subdev_call(>entity.subdev, pad, set_fmt, NULL,
+  );
+   if (ret < 0)
+   return ret;
+
+   /* BRU sink, propagate the format from the RPF source. */
+   format.pad = bru_input;
+
+   ret = v4l2_subdev_call(>bru->subdev, pad, set_fmt, NULL,
+  );
+   if (ret < 0)
+   return ret;
+
+   dev_dbg(vsp1->dev, "%s: set format %ux%u (%x) on %s pad %u\n",
+   __func__, format.format.width, format.format.height,
+   format.format.code, BRU_NAME(pipe->bru), format.pad);
+
+   sel.pad = bru_input;
+   sel.target = V4L2_SEL_TGT_COMPOSE;
+   sel.r = vsp1->drm->inputs[rpf->entity.index].compose;
+
+   ret = v4l2_subdev_call(>bru->subdev, pad, set_selection, NULL,
+  );
+   if (ret < 0)
+   return ret;
+
+   dev_dbg(vsp1->dev, "%s: set selection (%u,%u)/%ux%u on %s pad %u\n",
+   __func__, sel.r.left, sel.r.top, sel.r.width, sel.r.height,
+   BRU_NAME(pipe->bru), sel.pad);
+
+   return 0;
+}
+
+static unsigned int rpf_zpos(struct vsp1_device *vsp1, struct vsp1_rwpf *rpf)
+{
+   return vsp1->drm->inputs[rpf->entity.index].zpos;
+}
+
+/* Setup the input side of the pipeline (RPFs and BRU sink pads). */
+static int vsp1_du_pipeline_setup_input(struct vsp1_device *vsp1,
+   struct vsp1_pipeline *pipe)
+{
+   struct vsp1_rwpf *inputs[VSP1_MAX_RPF] = { NULL, };
+   struct vsp1_bru *bru = to_bru(>bru->subdev);
+   unsigned int i;
+   int ret;
+
+   /* Count the number of enabled inputs and sort them by Z-order. */
+   pipe->num_inputs = 0;
+
+   for (i = 0; i < 

[PATCH 05/15] v4l: vsp1: Use vsp1_entity.pipe to check if entity belongs to a pipeline

[Laurent Pinchart]

The DRM pipeline handling code uses the entity's pipe list head to check
whether the entity is already included in a pipeline. This method is a
bit fragile in the sense that it uses list_empty() on a list_head that
is a list member. Replace it by a simpler check for the entity pipe
pointer.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_drm.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index a7ad85ab0b08..e210917fdc3f 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -119,9 +119,9 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int 
pipe_index,
 * Remove the RPF from the pipe and the list of BRU
 * inputs.
 */
-   WARN_ON(list_empty(>entity.list_pipe));
+   WARN_ON(!rpf->entity.pipe);
rpf->entity.pipe = NULL;
-   list_del_init(>entity.list_pipe);
+   list_del(>entity.list_pipe);
pipe->inputs[i] = NULL;
 
bru->inputs[rpf->bru_input].rpf = NULL;
@@ -537,7 +537,7 @@ void vsp1_du_atomic_flush(struct device *dev, unsigned int 
pipe_index)
continue;
}
 
-   if (list_empty(>entity.list_pipe)) {
+   if (!rpf->entity.pipe) {
rpf->entity.pipe = pipe;
list_add_tail(>entity.list_pipe, >entities);
}
@@ -566,7 +566,7 @@ void vsp1_du_atomic_flush(struct device *dev, unsigned int 
pipe_index)
   VI6_DPR_NODE_UNUSED);
 
entity->pipe = NULL;
-   list_del_init(>list_pipe);
+   list_del(>list_pipe);
 
continue;
}
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 10/15] v4l: vsp1: Move DRM pipeline output setup code to a function

[Laurent Pinchart]

In order to make the vsp1_du_setup_lif() easier to read, and for
symmetry with the DRM pipeline input setup, move the pipeline output
setup code to a separate function.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_drm.c | 107 +++--
 1 file changed, 61 insertions(+), 46 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index 00ce99bd1605..1c8adda47440 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -276,6 +276,66 @@ static int vsp1_du_pipeline_setup_input(struct vsp1_device 
*vsp1,
return 0;
 }
 
+/* Setup the output side of the pipeline (WPF and LIF). */
+static int vsp1_du_pipeline_setup_output(struct vsp1_device *vsp1,
+struct vsp1_pipeline *pipe)
+{
+   struct vsp1_drm_pipeline *drm_pipe = to_vsp1_drm_pipeline(pipe);
+   struct v4l2_subdev_format format = {
+   .which = V4L2_SUBDEV_FORMAT_ACTIVE,
+   };
+   int ret;
+
+   format.pad = RWPF_PAD_SINK;
+   format.format.width = drm_pipe->width;
+   format.format.height = drm_pipe->height;
+   format.format.code = MEDIA_BUS_FMT_ARGB_1X32;
+   format.format.field = V4L2_FIELD_NONE;
+
+   ret = v4l2_subdev_call(>output->entity.subdev, pad, set_fmt, NULL,
+  );
+   if (ret < 0)
+   return ret;
+
+   dev_dbg(vsp1->dev, "%s: set format %ux%u (%x) on WPF%u sink\n",
+   __func__, format.format.width, format.format.height,
+   format.format.code, pipe->output->entity.index);
+
+   format.pad = RWPF_PAD_SOURCE;
+   ret = v4l2_subdev_call(>output->entity.subdev, pad, get_fmt, NULL,
+  );
+   if (ret < 0)
+   return ret;
+
+   dev_dbg(vsp1->dev, "%s: got format %ux%u (%x) on WPF%u source\n",
+   __func__, format.format.width, format.format.height,
+   format.format.code, pipe->output->entity.index);
+
+   format.pad = LIF_PAD_SINK;
+   ret = v4l2_subdev_call(>lif->subdev, pad, set_fmt, NULL,
+  );
+   if (ret < 0)
+   return ret;
+
+   dev_dbg(vsp1->dev, "%s: set format %ux%u (%x) on LIF%u sink\n",
+   __func__, format.format.width, format.format.height,
+   format.format.code, pipe->lif->index);
+
+   /*
+* Verify that the format at the output of the pipeline matches the
+* requested frame size and media bus code.
+*/
+   if (format.format.width != drm_pipe->width ||
+   format.format.height != drm_pipe->height ||
+   format.format.code != MEDIA_BUS_FMT_ARGB_1X32) {
+   dev_dbg(vsp1->dev, "%s: format mismatch on LIF%u\n", __func__,
+   pipe->lif->index);
+   return -EPIPE;
+   }
+
+   return 0;
+}
+
 /* Configure all entities in the pipeline. */
 static void vsp1_du_pipeline_configure(struct vsp1_pipeline *pipe)
 {
@@ -356,7 +416,6 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int 
pipe_index,
struct vsp1_drm_pipeline *drm_pipe;
struct vsp1_pipeline *pipe;
struct vsp1_bru *bru;
-   struct v4l2_subdev_format format;
unsigned long flags;
unsigned int i;
int ret;
@@ -417,54 +476,10 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int 
pipe_index,
if (ret < 0)
return ret;
 
-   memset(, 0, sizeof(format));
-   format.which = V4L2_SUBDEV_FORMAT_ACTIVE;
-   format.pad = RWPF_PAD_SINK;
-   format.format.width = cfg->width;
-   format.format.height = cfg->height;
-   format.format.code = MEDIA_BUS_FMT_ARGB_1X32;
-   format.format.field = V4L2_FIELD_NONE;
-
-   ret = v4l2_subdev_call(>output->entity.subdev, pad, set_fmt, NULL,
-  );
+   ret = vsp1_du_pipeline_setup_output(vsp1, pipe);
if (ret < 0)
return ret;
 
-   dev_dbg(vsp1->dev, "%s: set format %ux%u (%x) on WPF%u sink\n",
-   __func__, format.format.width, format.format.height,
-   format.format.code, pipe->output->entity.index);
-
-   format.pad = RWPF_PAD_SOURCE;
-   ret = v4l2_subdev_call(>output->entity.subdev, pad, get_fmt, NULL,
-  );
-   if (ret < 0)
-   return ret;
-
-   dev_dbg(vsp1->dev, "%s: got format %ux%u (%x) on WPF%u source\n",
-   __func__, format.format.width, format.format.height,
-   format.format.code, pipe->output->entity.index);
-
-   format.pad = LIF_PAD_SINK;
-   ret = v4l2_subdev_call(>lif->subdev, pad, set_fmt, NULL,
-  );
-   if (ret < 0)
-   return ret;
-
-   dev_dbg(vsp1->dev, "%s: set format %ux%u (%x) on LIF%u 

[PATCH 01/15] v4l: vsp1: Don't start/stop media pipeline for DRM

[Laurent Pinchart]

The DRM support code manages a pipeline of VSP entities, each backed by
a media entity. When starting or stopping the pipeline, it starts and
stops the media pipeline through the media API in order to store the
pipeline pointer in every entity.

The driver doesn't use the pipe pointer in media entities, neither does
it rely on the other effects of the media_pipeline_start() and
media_pipeline_stop() functions. Furthermore, as the media links for the
DRM pipeline are never set up correctly, and as the pipeline can be
modified dynamically when enabling or disabling planes, the current
implementation is not correct. Remove the incorrect and unneeded code.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_drm.c | 18 +++---
 1 file changed, 3 insertions(+), 15 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index b8fee1834253..e31fb371eaf9 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -109,8 +109,6 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int 
pipe_index,
if (ret == -ETIMEDOUT)
dev_err(vsp1->dev, "DRM pipeline stop timeout\n");
 
-   media_pipeline_stop(>output->entity.subdev.entity);
-
for (i = 0; i < ARRAY_SIZE(pipe->inputs); ++i) {
struct vsp1_rwpf *rpf = pipe->inputs[i];
 
@@ -224,11 +222,9 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int 
pipe_index,
}
 
/*
-* Mark the pipeline as streaming and enable the VSP1. This will store
-* the pipeline pointer in all entities, which the s_stream handlers
-* will need. We don't start the entities themselves right at this point
-* as there's no plane configured yet, so we can't start processing
-* buffers.
+* Enable the VSP1. We don't start the entities themselves right at this
+* point as there's no plane configured yet, so we can't start
+* processing buffers.
 */
ret = vsp1_device_get(vsp1);
if (ret < 0)
@@ -241,14 +237,6 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int 
pipe_index,
drm_pipe->du_complete = cfg->callback;
drm_pipe->du_private = cfg->callback_data;
 
-   ret = media_pipeline_start(>output->entity.subdev.entity,
- >pipe);
-   if (ret < 0) {
-   dev_dbg(vsp1->dev, "%s: pipeline start failed\n", __func__);
-   vsp1_device_put(vsp1);
-   return ret;
-   }
-
/* Disable the display interrupts. */
vsp1_write(vsp1, VI6_DISP_IRQ_STA, 0);
vsp1_write(vsp1, VI6_DISP_IRQ_ENB, 0);
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 00/15] R-Car VSP1: Dynamically assign blend units to display pipelines

[Laurent Pinchart]

Hello,

On R-Car H3 ES2.0+ and M3-N SoCs, two display pipelines are served by the same
VSP instance (named VSPDL). The VSPDL includes two blending units named BRU
and BRS, unlike the other display-related VSPD that serves a single display
channel with a single blending unit.

The VSPDL has five inputs and can freely assign them at runtime to two display
pipelines, using the BRU and BRS to blend multiple inputs. The BRU supports
blending up to five inputs, while the BRS is limited to two inputs.

Each display pipeline requires a blending unit, and the BRU and BRS are
currently assigned statically to the first and second pipeline respectively.
This artificially limits the number of inputs for the second pipeline to two.
To overcome that limitation, the BRU and BRS need to be dynamically assigned
to the display pipelines, which is what this patch series does.

Patches 01/15 to 10/15 perform small cleanups and refactoring to prepare for
the rest of the series. Patches 11/15 and 12/15 implement new internal
features for the same purpose, and patch 13/15 performs the bulk of the work
by implementing dynamic BRU and BRS assignment to pipelines.

Reassigning the BRU and BRS when two pipelines are running results in flicker
as one pipeline has to first release its blending unit. Synchronization
between the two pipelines also require locking that effectively serializes
page flips for the two pipelines, even when not interacting with each other.
This is currently believed to be unavoidable due to the hardware design, but
please feel free to prove me wrong (ideally with a patch - one can always
dream).

Patch 14/15 then adds messages useful for debugging this new feature. I have
kept it separate from 13/15 to make it easier to remove those messages once
dynamic assignment of blending units will be deemed perfectly stable, but I
won't oppose squashing it with 13/15 if that is preferred.

Patch 15/15 finally rename BRU to BRx to avoid confusion between the BRU terms
that refer to the BRU in particular, and the ones that refer to any of the BRU
or BRS. As this might be a bit controversial I've put the patch last in the
series in case it needs to be dropped.

I have decided to CC the dri-devel mailing list even though the code doesn't
touch the R-Car DU driver and will be merged through the Linux media tree as
the display is involved and the series could benefit from the expertise of the
DRM/KMS community from that point of view.

The patches are based on top of the latest Linux media master branch. For
convenience their are available from

git://linuxtv.org/pinchartl/media.git v4l2/vsp1/bru-brs

The series passes the DU test suite with the new BRx dynamic assignment
test available from

git://git.ideasonboard.com/renesas/kms-tests.git bru-brs

The VSP test suite also runs without any noticed regression.

Laurent Pinchart (15):
  v4l: vsp1: Don't start/stop media pipeline for DRM
  v4l: vsp1: Remove outdated comment
  v4l: vsp1: Remove unused field from vsp1_drm_pipeline structure
  v4l: vsp1: Store pipeline pointer in vsp1_entity
  v4l: vsp1: Use vsp1_entity.pipe to check if entity belongs to a
pipeline
  v4l: vsp1: Share duplicated DRM pipeline configuration code
  v4l: vsp1: Move DRM atomic commit pipeline setup to separate function
  v4l: vsp1: Setup BRU at atomic commit time
  v4l: vsp1: Replace manual DRM pipeline input setup in
vsp1_du_setup_lif
  v4l: vsp1: Move DRM pipeline output setup code to a function
  v4l: vsp1: Add per-display list completion notification support
  v4l: vsp1: Generalize detection of entity removal from DRM pipeline
  v4l: vsp1: Assign BRU and BRS to pipelines dynamically
  v4l: vsp1: Add BRx dynamic assignment debugging messages
  v4l: vsp1: Rename BRU to BRx

 drivers/media/platform/vsp1/Makefile   |   2 +-
 drivers/media/platform/vsp1/vsp1.h |   6 +-
 .../media/platform/vsp1/{vsp1_bru.c => vsp1_brx.c} | 202 ++---
 .../media/platform/vsp1/{vsp1_bru.h => vsp1_brx.h} |  18 +-
 drivers/media/platform/vsp1/vsp1_dl.c  |  27 +-
 drivers/media/platform/vsp1/vsp1_dl.h  |   4 +-
 drivers/media/platform/vsp1/vsp1_drm.c | 829 -
 drivers/media/platform/vsp1/vsp1_drm.h |  16 +-
 drivers/media/platform/vsp1/vsp1_drv.c |   8 +-
 drivers/media/platform/vsp1/vsp1_entity.h  |   2 +
 drivers/media/platform/vsp1/vsp1_histo.c   |   2 +-
 drivers/media/platform/vsp1/vsp1_histo.h   |   3 -
 drivers/media/platform/vsp1/vsp1_pipe.c|  50 +-
 drivers/media/platform/vsp1/vsp1_pipe.h|   7 +-
 drivers/media/platform/vsp1/vsp1_rpf.c |  12 +-
 drivers/media/platform/vsp1/vsp1_rwpf.h|   4 +-
 drivers/media/platform/vsp1/vsp1_video.c   |  37 +-
 drivers/media/platform/vsp1/vsp1_wpf.c |   8 +-
 18 files changed, 705 insertions(+), 532 deletions(-)
 rename drivers/media/platform/vsp1/{vsp1_bru.c => 

[PATCH 03/15] v4l: vsp1: Remove unused field from vsp1_drm_pipeline structure

[Laurent Pinchart]

The vsp1_drm_pipeline enabled field is set but never used. Remove it.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_drm.c | 4 
 drivers/media/platform/vsp1/vsp1_drm.h | 2 --
 2 files changed, 6 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index a1f2ba044092..a267f12f0cc8 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -273,10 +273,6 @@ EXPORT_SYMBOL_GPL(vsp1_du_setup_lif);
  */
 void vsp1_du_atomic_begin(struct device *dev, unsigned int pipe_index)
 {
-   struct vsp1_device *vsp1 = dev_get_drvdata(dev);
-   struct vsp1_drm_pipeline *drm_pipe = >drm->pipe[pipe_index];
-
-   drm_pipe->enabled = drm_pipe->pipe.num_inputs != 0;
 }
 EXPORT_SYMBOL_GPL(vsp1_du_atomic_begin);
 
diff --git a/drivers/media/platform/vsp1/vsp1_drm.h 
b/drivers/media/platform/vsp1/vsp1_drm.h
index 1cd9db785bf7..9aa19325cbe9 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.h
+++ b/drivers/media/platform/vsp1/vsp1_drm.h
@@ -20,13 +20,11 @@
 /**
  * vsp1_drm_pipeline - State for the API exposed to the DRM driver
  * @pipe: the VSP1 pipeline used for display
- * @enabled: pipeline state at the beginning of an update
  * @du_complete: frame completion callback for the DU driver (optional)
  * @du_private: data to be passed to the du_complete callback
  */
 struct vsp1_drm_pipeline {
struct vsp1_pipeline pipe;
-   bool enabled;
 
/* Frame synchronisation */
void (*du_complete)(void *, bool);
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 04/15] v4l: vsp1: Store pipeline pointer in vsp1_entity

[Laurent Pinchart]

Various types of objects subclassing vsp1_entity currently store a
pointer to the pipeline. Move the pointer to vsp1_entity to simplify the
code and avoid storing the pipeline in more entity subclasses later.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_drm.c| 20 +--
 drivers/media/platform/vsp1/vsp1_drv.c|  2 +-
 drivers/media/platform/vsp1/vsp1_entity.h |  2 ++
 drivers/media/platform/vsp1/vsp1_histo.c  |  2 +-
 drivers/media/platform/vsp1/vsp1_histo.h  |  3 ---
 drivers/media/platform/vsp1/vsp1_pipe.c   | 33 +--
 drivers/media/platform/vsp1/vsp1_rwpf.h   |  2 --
 drivers/media/platform/vsp1/vsp1_video.c  | 17 +++-
 8 files changed, 34 insertions(+), 47 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index a267f12f0cc8..a7ad85ab0b08 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -120,6 +120,7 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int 
pipe_index,
 * inputs.
 */
WARN_ON(list_empty(>entity.list_pipe));
+   rpf->entity.pipe = NULL;
list_del_init(>entity.list_pipe);
pipe->inputs[i] = NULL;
 
@@ -536,8 +537,10 @@ void vsp1_du_atomic_flush(struct device *dev, unsigned int 
pipe_index)
continue;
}
 
-   if (list_empty(>entity.list_pipe))
+   if (list_empty(>entity.list_pipe)) {
+   rpf->entity.pipe = pipe;
list_add_tail(>entity.list_pipe, >entities);
+   }
 
bru->inputs[i].rpf = rpf;
rpf->bru_input = i;
@@ -562,6 +565,7 @@ void vsp1_du_atomic_flush(struct device *dev, unsigned int 
pipe_index)
vsp1_dl_list_write(dl, entity->route->reg,
   VI6_DPR_NODE_UNUSED);
 
+   entity->pipe = NULL;
list_del_init(>list_pipe);
 
continue;
@@ -625,24 +629,28 @@ int vsp1_drm_init(struct vsp1_device *vsp1)
 
vsp1_pipeline_init(pipe);
 
+   pipe->frame_end = vsp1_du_pipeline_frame_end;
+
/*
 * The DRM pipeline is static, add entities manually. The first
 * pipeline uses the BRU and the second pipeline the BRS.
 */
pipe->bru = i == 0 ? >bru->entity : >brs->entity;
-   pipe->lif = >lif[i]->entity;
pipe->output = vsp1->wpf[i];
-   pipe->output->pipe = pipe;
-   pipe->frame_end = vsp1_du_pipeline_frame_end;
+   pipe->lif = >lif[i]->entity;
 
+   pipe->bru->pipe = pipe;
pipe->bru->sink = >output->entity;
pipe->bru->sink_pad = 0;
+   list_add_tail(>bru->list_pipe, >entities);
+
+   pipe->output->entity.pipe = pipe;
pipe->output->entity.sink = pipe->lif;
pipe->output->entity.sink_pad = 0;
+   list_add_tail(>output->entity.list_pipe, >entities);
 
-   list_add_tail(>bru->list_pipe, >entities);
+   pipe->lif->pipe = pipe;
list_add_tail(>lif->list_pipe, >entities);
-   list_add_tail(>output->entity.list_pipe, >entities);
}
 
/* Disable all RPFs initially. */
diff --git a/drivers/media/platform/vsp1/vsp1_drv.c 
b/drivers/media/platform/vsp1/vsp1_drv.c
index eed9516e25e1..58a7993f2306 100644
--- a/drivers/media/platform/vsp1/vsp1_drv.c
+++ b/drivers/media/platform/vsp1/vsp1_drv.c
@@ -63,7 +63,7 @@ static irqreturn_t vsp1_irq_handler(int irq, void *data)
vsp1_write(vsp1, VI6_WPF_IRQ_STA(i), ~status & mask);
 
if (status & VI6_WFP_IRQ_STA_DFE) {
-   vsp1_pipeline_frame_end(wpf->pipe);
+   vsp1_pipeline_frame_end(wpf->entity.pipe);
ret = IRQ_HANDLED;
}
}
diff --git a/drivers/media/platform/vsp1/vsp1_entity.h 
b/drivers/media/platform/vsp1/vsp1_entity.h
index 408602ebeb97..c26523c56c05 100644
--- a/drivers/media/platform/vsp1/vsp1_entity.h
+++ b/drivers/media/platform/vsp1/vsp1_entity.h
@@ -106,6 +106,8 @@ struct vsp1_entity {
unsigned int index;
const struct vsp1_route *route;
 
+   struct vsp1_pipeline *pipe;
+
struct list_head list_dev;
struct list_head list_pipe;
 
diff --git a/drivers/media/platform/vsp1/vsp1_histo.c 
b/drivers/media/platform/vsp1/vsp1_histo.c
index afab77cf4fa5..8638ebc514b4 100644
--- a/drivers/media/platform/vsp1/vsp1_histo.c
+++ b/drivers/media/platform/vsp1/vsp1_histo.c
@@ -61,7 +61,7 @@ void vsp1_histogram_buffer_complete(struct vsp1_histogram 

[PATCH 02/15] v4l: vsp1: Remove outdated comment

[Laurent Pinchart]

The entities in the pipeline are all started when the LIF is setup.
Remove the outdated comment that state otherwise.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_drm.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index e31fb371eaf9..a1f2ba044092 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -221,11 +221,7 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int 
pipe_index,
return -EPIPE;
}
 
-   /*
-* Enable the VSP1. We don't start the entities themselves right at this
-* point as there's no plane configured yet, so we can't start
-* processing buffers.
-*/
+   /* Enable the VSP1. */
ret = vsp1_device_get(vsp1);
if (ret < 0)
return ret;
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 103234] KWin crashed when Alt+Tab-ing through open windows

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103234

--- Comment #13 from Roman Gilg  ---
GDB output near to current master (at 8d1f1ce412, later does not compile on my
system at the moment):



Thread 17 "gallium_drv:0" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f67d592f700 (LWP 7986)]
si_emit_draw_packets (sctx=sctx@entry=0x2c94390, info=info@entry=0x2ce22e8,
indexbuf=, index_size=index_size@entry=2,
index_offset=) at
/home/roman/dev/mesa/src/mesa/src/gallium/drivers/radeonsi/si_state_draw.c:718
718 index_max_size = (indexbuf->width0 - index_offset) /



(gdb) bt
#0  si_emit_draw_packets (sctx=sctx@entry=0x2c94390, info=info@entry=0x2ce22e8,
indexbuf=, index_size=index_size@entry=2,
index_offset=) at
/home/roman/dev/mesa/src/mesa/src/gallium/drivers/radeonsi/si_state_draw.c:718
#1  0x7f67d4a2467d in si_draw_vbo (ctx=0x2c94390, info=0x2ce22e8) at
/home/roman/dev/mesa/src/mesa/src/gallium/drivers/radeonsi/si_state_draw.c:1481
#2  0x7f67d492f871 in tc_call_draw_vbo (pipe=,
payload=0x2ce22e8) at
/home/roman/dev/mesa/src/mesa/src/gallium/auxiliary/util/u_threaded_context.c:2012
#3  0x7f67d492bff7 in tc_batch_execute (job=job@entry=0x2ce18f0,
thread_index=thread_index@entry=0) at
/home/roman/dev/mesa/src/mesa/src/gallium/auxiliary/util/u_threaded_context.c:96
#4  0x7f67d47b529f in util_queue_thread_func (input=input@entry=0x2ad6d30)
at /home/roman/dev/mesa/src/mesa/src/util/u_queue.c:271
#5  0x7f67d47b4e27 in impl_thrd_routine (p=) at
/home/roman/dev/mesa/src/mesa/include/c11/threads_posix.h:87
#6  0x7f68839146ba in start_thread (arg=0x7f67d592f700) at
pthread_create.c:333
#7  0x7f688ad0c41d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:109



(gdb) bt full
#0  si_emit_draw_packets (sctx=sctx@entry=0x2c94390, info=info@entry=0x2ce22e8,
indexbuf=, index_size=index_size@entry=2,
index_offset=) at
/home/roman/dev/mesa/src/mesa/src/gallium/drivers/radeonsi/si_state_draw.c:718
indirect = 0x0
cs = 0x2ca3a90
sh_base_reg = 45360
render_cond_bit = false
index_max_size = 0
index_va = 0
__PRETTY_FUNCTION__ = "si_emit_draw_packets"
#1  0x7f67d4a2467d in si_draw_vbo (ctx=0x2c94390, info=0x2ce22e8) at
/home/roman/dev/mesa/src/mesa/src/gallium/drivers/radeonsi/si_state_draw.c:1481
sctx = 0x2c94390
rs = 
indexbuf = 0x0
dirty_tex_counter = 
rast_prim = 
index_size = 2
index_offset = 0
__PRETTY_FUNCTION__ = "si_draw_vbo"
#2  0x7f67d492f871 in tc_call_draw_vbo (pipe=,
payload=0x2ce22e8) at
/home/roman/dev/mesa/src/mesa/src/gallium/auxiliary/util/u_threaded_context.c:2012
info = 0x2ce22e8
#3  0x7f67d492bff7 in tc_batch_execute (job=job@entry=0x2ce18f0,
thread_index=thread_index@entry=0) at
/home/roman/dev/mesa/src/mesa/src/gallium/auxiliary/util/u_threaded_context.c:96
iter = 0x2ce22e0
batch = 0x2ce18f0
pipe = 0x2c94390
last = 0x2ce24e0
#4  0x7f67d47b529f in util_queue_thread_func (input=input@entry=0x2ad6d30)
at /home/roman/dev/mesa/src/mesa/src/util/u_queue.c:271
job = {job = 0x2ce18f0, fence = 0x2ce1908, execute = 0x7f67d492bfb0
, cleanup = 0x0}
queue = 0x2cde788
thread_index = 
__PRETTY_FUNCTION__ = "util_queue_thread_func"
#5  0x7f67d47b4e27 in impl_thrd_routine (p=) at
/home/roman/dev/mesa/src/mesa/include/c11/threads_posix.h:87
pack = {func = 0x7f67d47b5060 , arg =
0x2ad6d30}
#6  0x7f68839146ba in start_thread (arg=0x7f67d592f700) at
pthread_create.c:333
__res = 
pd = 0x7f67d592f700
now = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140083941537536,
7002528104003647912, 0, 140728410686399, 8388608, 39522672,
-6925884145858791000, -6918376651715135064}, mask_was_saved = 0}}, priv = {pad
= {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, 
  canceltype = 0}}}
not_first_call = 
pagesize_m1 = 
sp = 
freesize = 
__PRETTY_FUNCTION__ = "start_thread"
#7  0x7f688ad0c41d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:109
No locals.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101672] radeonsi: 3D engines causing frequent GPU lockups

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101672

--- Comment #24 from MirceaKitsune  ---
I can confirm that the exact same system freeze happens with both the radeon
and amdgpu driver: Using either module makes absolutely no difference.

This is the last piece of confirmation I needed to conclude that what's
happening must be a deliberate malware: There is simply no way a GPU crash bug
could behave 100% the same way on two entirely different video drivers. Further
more, this freeze is completely identical to the one I initially reported
here... which was obviously fixed since there's been so many updates to every
system component it would have been solved by sheer chance at this point!
Functionality like this should only be seen if someone is actively
re-implementing the problem on top of updated system components, with the
active intent of keeping its effects identical each time. It's possible that my
machine may be used to test malware usable to shut down Linux systems, in which
case I need to find out where it's hidden and how it's bricking computers
before it spreads.

This attack must exploit vulnerabilities that keep coming and going in X11,
Mesa, or some other system component... those are hopefully holes which can be
discovered and plugged to render the attacks impractical altogether. Again I
only know that it's triggered while certain 3D engines are running (possibly
aimed primarily at gamers?) and has a random chance of happening roughly once
every 30 minutes (likely to make testing harder and better hide the exploit).

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105257] GPU HANG: ecode 9:0:0x86dffffd, in Xorg, reason: Hang on render ring, action: reset

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105257

--- Comment #5 from Ivan Levshin  ---
Hi Mathias,

Thanks for your comment. So it looks like a Mesa bug, will check if downgrade
helps. Anyway I'd like to get a fix for actual Mesa version.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105256] Slow performance using glDrawElementsBaseVertex

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105256

Roland Scheidegger  changed:

   What|Removed |Added

 Resolution|NOTABUG |FIXED

--- Comment #4 from Roland Scheidegger  ---
(In reply to Logan McNaughton from comment #2)
> Interesting, is this documented somewhere? How do you know what data formats
> the HW supports? Is there any other hardware besides these cards that don't
> support it?
> 
> I'll have the users test using GL_UNSIGNED_SHORT

I'm not sure if AMD (or ATI) had some perf guides published where this was
stated. You can, however, see this from the published register guides -
https://developer.amd.com/resources/developer-guides-manuals/
It says VGT_INDEX_16 and VGT_INDEX_32 as valid values for VGT_DMA_INDEX_TYPE
(for evergreen, others should be similar), interestingly however it's already a
2-bit value there.
(Actually the register guides only seem to go up to Sea Islands, so you can't
even see that it is supported starting with VI.)
A look at the mesa driver is probably easier though :-). This should affect all
amd/ati hw up to Sea Islands. Of course, if you use old-school non-vbo element
data, it's probably no big deal.
At a very quick glance at the driver code, it looks like newer nvidia chips can
handle it (everything from g80). nv30/nv40 cannot, but there it looks like nv30
will emulate index buffers anyway, so the only chips which this might make a
difference is nv40 family.
Looks like all intel chips can handle it fine.

That said, even if the slowdown is due to this, I'm not convinced the driver
couldn't do better (though it does not look trivial to do better). But it's one
of the features which noone really expects to get used, therefore it's good
enough as long as it works correctly...

You can't query this afaik and just have to know... Apparently using
GL_UNSIGNED_BYTE indices was simply broken at some point with windows drivers
too - it's possible the blob implements a more sophisticated emulation
strategy: https://community.amd.com/thread/159040

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105256] Slow performance using glDrawElementsBaseVertex

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105256

Logan McNaughton  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTABUG

--- Comment #3 from Logan McNaughton  ---
The user confirmed that using GL_UNSIGNED_SHORT fixed the issue, thanks. I
would still be curious if there is some easy way to figure this out via
documentation or querying the device somehow.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105256] Slow performance using glDrawElementsBaseVertex

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105256

--- Comment #2 from Logan McNaughton  ---
Interesting, is this documented somewhere? How do you know what data formats
the HW supports? Is there any other hardware besides these cards that don't
support it?

I'll have the users test using GL_UNSIGNED_SHORT

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105256] Slow performance using glDrawElementsBaseVertex

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105256

--- Comment #1 from Roland Scheidegger  ---
At a quick glance, I'd suspect the problem isn't really drawElementsBaseVertex
per se, but the use of GL_UNSIGNED_BYTE indices as the code seemed to do.
The hw doesn't support ubyte indices, and this has to be emulated by converting
the elements to ushort (and if you don't start from zero, IIRC this can get
huge buffers allocated especially if start is negative, but I don't remember
the details).
I don't know if the driver could do better, but in general you're advised to
not use ubyte indices (this is a gl only feature, d3d doesn't support it, so
it's unsurprising some hw doesn't support it natively).
(Note that even early GCN does not support ubyte indices, they are only
supported starting with Vulcanic Islands.)

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 6/6] arm64: dts: rockchip: Specify override mode for kevin panel

[Doug Anderson]

Hi,

On Thu, Feb 8, 2018 at 9:48 AM, Sean Paul  wrote:
> This patch adds an override mode for kevin devices. The mode increases
> both back porches to allow a pixel clock of 2kHz as opposed to the
> 'typical' value of 252750kHz. This is needed to avoid interference with
> the touch digitizer on these laptops.
>
> Changes in v2:
>  - Wrap the timing in display-timings node to match binding (Rob/Thierry)
> Changes in v3:
>  - Unwrap the timing from display-timings and rename panel-timing (Rob)
>
> Cc: Doug Anderson 
> Cc: Eric Anholt 
> Cc: Heiko Stuebner 
> Cc: Jeffy Chen 
> Cc: Rob Herring 
> Cc: Stéphane Marchesin 
> Cc: Thierry Reding 
> Cc: devicet...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-rockc...@lists.infradead.org
> Signed-off-by: Sean Paul 
> ---
>  arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts | 14 ++
>  1 file changed, 14 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts 
> b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
> index 191a6bcb1704..658411ce37ea 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
> @@ -98,6 +98,20 @@
> backlight = <>;
> power-supply = <_disp>;
>
> +   panel-timing {
> +   clock-frequency = <266604720>;
> +   hactive = <2400>;
> +   hfront-porch = <48>;
> +   hback-porch = <84>;
> +   hsync-len = <32>;
> +   hsync-active = <0>;
> +   vactive = <1600>;
> +   vfront-porch = <3>;
> +   vback-porch = <120>;
> +   vsync-len = <10>;
> +   vsync-active = <0>;
> +   };
> +
> ports {
> panel_in_edp: endpoint {
> remote-endpoint = <_out_panel>;

Kristian brought an old bug to my attention
 and it
made me think.  Should we somehow adjust the bindings here to account
for the fact that a board may source several different panels?

AKA: on some boards an ODM may want to second source (or third source,
or ...) the panel.  They'll randomly connect several different panels
to the board and ship the boards out.  The panels are all compatible
electrically (same power sequencing) but might need slightly different
timings.  In this particular case there's no board-level strappings
for the different panels--it's assumed that the EDID on the panels can
be used to distinguish them.

In that case it seems like it would be nice to allow specifying more
than one "panel-timing" nodes.  Maybe keyed off some type of ID that's
present in the EDID?


Is that something we'd want to account for before we land this series?
 It seems like it would just be adding an extra level of nodes?


-Doug
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105257] GPU HANG: ecode 9:0:0x86dffffd, in Xorg, reason: Hang on render ring, action: reset

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105257

--- Comment #4 from Mathias Fröhlich  ---
If it helps:
Same story on fedora 27 with a skylake system.
Poor mens bisect on downgradable rpms show: 
Shows up somewhere between mesa-17.3.3-1.fc27 and mesa-17.3.5-1.fc27.

best

Mathias

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/5] drm/i915: Move hdcp msg detection into shim

[Sean Paul]

On Mon, Feb 26, 2018 at 10:42:39PM +0530, Ramalingam C wrote:
> DP and HDMI HDCP specifications are varying with respect to
> detecting the R0 and ksv_fifo availability.
> 
> DP will produce CP_IRQ and set a bit for indicating the R0 and
> FIFO_READY status.

I'm not sure what the benefit is? Keeping things common was a deliberate
decision on my part to keep complexity down and increase the amount of common
code.

Sean

> 
> Whereas HDMI will set a bit for FIFO_READY but there is no bit
> indication for R0 ready. And also polling of READY bit is needed for
> HDMI as ther is no CP_IRQ.
> 
> So Fielding the CP_IRQ for DP and the polling the READY bit for a
> period and blindly waiting for a fixed time for R0 incase of HDMI are
> moved into corresponding hdcp_shim.
> 
> Signed-off-by: Ramalingam C 
> ---
>  drivers/gpu/drm/i915/intel_dp.c   | 70 
> +++
>  drivers/gpu/drm/i915/intel_drv.h  |  6 ++--
>  drivers/gpu/drm/i915/intel_hdcp.c | 39 ++
>  drivers/gpu/drm/i915/intel_hdmi.c | 28 +++-
>  4 files changed, 98 insertions(+), 45 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 2c3eb90b9499..afe310a91d3c 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4436,6 +4436,7 @@ static bool
>  intel_dp_short_pulse(struct intel_dp *intel_dp)
>  {
>   struct drm_i915_private *dev_priv = to_i915(intel_dp_to_dev(intel_dp));
> + struct intel_connector *connector = intel_dp->attached_connector;
>   u8 sink_irq_vector = 0;
>   u8 old_sink_count = intel_dp->sink_count;
>   bool ret;
> @@ -4470,8 +4471,11 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
>  
>   if (sink_irq_vector & DP_AUTOMATED_TEST_REQUEST)
>   intel_dp_handle_test_request(intel_dp);
> - if (sink_irq_vector & (DP_CP_IRQ | DP_SINK_SPECIFIC_IRQ))
> - DRM_DEBUG_DRIVER("CP or sink specific irq unhandled\n");
> + if (sink_irq_vector & DP_CP_IRQ)
> + if (connector->hdcp_shim)
> + complete_all(>cp_irq_recved);
> + if (sink_irq_vector & DP_SINK_SPECIFIC_IRQ)
> + DRM_DEBUG_DRIVER("Sink specific irq unhandled\n");
>   }
>  
>   intel_dp_check_link_status(intel_dp);
> @@ -5083,6 +5087,25 @@ void intel_dp_encoder_suspend(struct intel_encoder 
> *intel_encoder)
>   pps_unlock(intel_dp);
>  }
>  
> +static int intel_dp_hdcp_wait_for_cp_irq(struct completion *cp_irq_recved,
> +  int timeout)
> +{
> + long ret;
> +
> + if (completion_done(cp_irq_recved))
> + reinit_completion(cp_irq_recved);
> +
> + ret = wait_for_completion_interruptible_timeout(cp_irq_recved,
> + msecs_to_jiffies(
> + timeout));
> + reinit_completion(cp_irq_recved);
> + if (ret < 0)
> + return (int)ret;
> + else if (!ret)
> + return -ETIMEDOUT;
> + return 0;
> +}
> +
>  static
>  int intel_dp_hdcp_write_an_aksv(struct intel_digital_port *intel_dig_port,
>   u8 *an)
> @@ -5188,11 +5211,38 @@ int intel_dp_hdcp_repeater_present(struct 
> intel_digital_port *intel_dig_port,
>   return 0;
>  }
>  
> +static int intel_dp_hdcp_wait_for_r0(struct intel_digital_port 
> *intel_dig_port)
> +{
> + struct intel_dp *dp = _dig_port->dp;
> + struct intel_connector *connector = dp->attached_connector;
> + int ret;
> + u8 bstatus;
> +
> + intel_dp_hdcp_wait_for_cp_irq(>cp_irq_recved, 100);
> +
> + ret = drm_dp_dpcd_read(_dig_port->dp.aux, DP_AUX_HDCP_BSTATUS,
> +, 1);
> + if (ret != 1) {
> + DRM_ERROR("Read bstatus from DP/AUX failed (%d)\n", ret);
> + return ret >= 0 ? -EIO : ret;
> + }
> +
> + if (!(bstatus & DP_BSTATUS_R0_PRIME_READY))
> + return -ETIMEDOUT;
> +
> + return 0;
> +}
> +
>  static
>  int intel_dp_hdcp_read_ri_prime(struct intel_digital_port *intel_dig_port,
>   u8 *ri_prime)
>  {
>   ssize_t ret;
> +
> + ret = intel_dp_hdcp_wait_for_r0(intel_dig_port);
> + if (!ret)
> + return ret;
> +
>   ret = drm_dp_dpcd_read(_dig_port->dp.aux, DP_AUX_HDCP_RI_PRIME,
>  ri_prime, DRM_HDCP_RI_LEN);
>   if (ret != DRM_HDCP_RI_LEN) {
> @@ -5203,18 +5253,26 @@ int intel_dp_hdcp_read_ri_prime(struct 
> intel_digital_port *intel_dig_port,
>  }
>  
>  static
> -int intel_dp_hdcp_read_ksv_ready(struct intel_digital_port *intel_dig_port,
> -  bool *ksv_ready)
> +int intel_dp_hdcp_ksv_ready(struct intel_digital_port *intel_dig_port)
>  {
> + struct intel_dp *dp = _dig_port->dp;
> + struct 

[Bug 105257] GPU HANG: ecode 9:0:0x86dffffd, in Xorg, reason: Hang on render ring, action: reset

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105257

--- Comment #3 from Ivan Levshin  ---
Created attachment 137614
  --> https://bugs.freedesktop.org/attachment.cgi?id=137614=edit
Presentation sample

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/5] drm/i915: Poll hdcp register on sudden NACK

[Sean Paul]

On Mon, Feb 26, 2018 at 10:42:38PM +0530, Ramalingam C wrote:
> In a connected state, If a HDMI HDCP sink is responded with NACK for
> HDCP I2C register access, then HDMI HDCP spec mandates the polling
> of any HDCP space registers for accessibility, minimum once in 2Secs
> atleast for 4Secs.
> 

I'm not convinced this is the right place to do this. 

The reason is that this is more complex than how you have it below. You can't
access state outside of check/commit, so polling state->content_protection is
not permissable from check_link. If the check fails, the driver will change the
current value of content_protection, so userspace will be able to retry.

In the case of enable, since it's synchronous, the error will be propagated to
userspace and it can retry if that's the right thing to do.

Sean

> Just to make it simple, this is generically implemented for both HDMI
> and DP. But we dont expect that this scanario will occur for DP.
> 
> HDMI HDCP CTS Tests: 1A-04 and 1A-07A.
> 
> Signed-off-by: Ramalingam C 
> ---
>  drivers/gpu/drm/i915/intel_hdcp.c | 74 
> +++
>  1 file changed, 67 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
> b/drivers/gpu/drm/i915/intel_hdcp.c
> index 95081aaa832a..14be14a45e5a 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -16,6 +16,47 @@
>  
>  #define KEY_LOAD_TRIES   5
>  
> +static
> +struct intel_digital_port *conn_to_dig_port(struct intel_connector 
> *connector)
> +{
> + return enc_to_dig_port(_attached_encoder(>base)->base);
> +}
> +
> +static inline bool hdcp_port_accessible(struct intel_connector *connector)
> +{
> + struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
> + int ret = -ENXIO;
> + u8 bksv[DRM_HDCP_KSV_LEN];
> +
> + ret = connector->hdcp_shim->read_bksv(intel_dig_port, bksv);
> + if (!ret)
> + return true;
> + return false;
> +}
> +
> +static bool wait_for_hdcp_port(struct intel_connector *connector)
> +{
> + int i, tries = 10;
> +
> + for (i = 0; i < tries; i++) {
> + if (connector->base.status != connector_status_connected ||
> + connector->base.state->content_protection ==
> + DRM_MODE_CONTENT_PROTECTION_UNDESIRED ||
> + connector->hdcp_value ==
> + DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
> + return false;
> +
> + if (hdcp_port_accessible(connector))
> + break;
> +
> + msleep_interruptible(500);
> + }
> +
> + if (i == tries)
> + return false;
> + return true;
> +}
> +
>  static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port 
> *intel_dig_port,
>   const struct intel_hdcp_shim *shim)
>  {
> @@ -584,12 +625,6 @@ static int intel_hdcp_auth(struct intel_digital_port 
> *intel_dig_port,
>   return 0;
>  }
>  
> -static
> -struct intel_digital_port *conn_to_dig_port(struct intel_connector 
> *connector)
> -{
> - return enc_to_dig_port(_attached_encoder(>base)->base);
> -}
> -
>  static int _intel_hdcp_disable(struct intel_connector *connector)
>  {
>   struct drm_i915_private *dev_priv = connector->base.dev->dev_private;
> @@ -719,14 +754,26 @@ int intel_hdcp_init(struct intel_connector *connector,
>  
>  int intel_hdcp_enable(struct intel_connector *connector)
>  {
> - int ret;
> + int ret, tries = 2;
>  
>   if (!connector->hdcp_shim)
>   return -ENOENT;
>  
>   mutex_lock(>hdcp_mutex);
>  
> +enable_hdcp:
>   ret = _intel_hdcp_enable(connector);
> +
> + /*
> +  * Suddenly if sink is NACK-ed for the access of HDCP
> +  * registers, but display is still connected, poll for hdcp
> +  * port accessibility. One of the HDCP spec requirement.
> +  */
> + if ((ret == -EIO || ret == -ENXIO) &&
> + connector->base.status == connector_status_connected &&
> + !hdcp_port_accessible(connector))
> + if (wait_for_hdcp_port(connector) && --tries)
> + goto enable_hdcp;
>   if (ret)
>   goto out;
>  
> @@ -838,6 +885,19 @@ int intel_hdcp_check_link(struct intel_connector 
> *connector)
>   goto out;
>   }
>  
> + /*
> +  * Suddenly if sink is NACK-ed for the access of HDCP
> +  * registers, but display is still connected, poll for hdcp
> +  * port accessibility. One of the HDCP spec requirement.
> +  */
> + if (connector->base.status == connector_status_connected &&
> + !hdcp_port_accessible(connector)) {
> + mutex_unlock(>hdcp_mutex);
> + if (!wait_for_hdcp_port(connector))
> + return ret;
> + mutex_lock(>hdcp_mutex);
> + }
> +
>   ret = _intel_hdcp_enable(connector);
>   if (ret) {
>   DRM_ERROR("Failed 

Re: [PATCH 3/5] drm/i915: Check hdcp key loadability

[Sean Paul]

On Mon, Feb 26, 2018 at 10:42:37PM +0530, Ramalingam C wrote:
> HDCP1.4 key can be loaded, only when Power well #1 is enabled and cdclk
> is enabled. Using the I915 power well infrastruture, above requirement
> is verified.
> 
> This patch enables the hdcp initialization for HSW, BDW, and BXT.
> 
> Signed-off-by: Ramalingam C 

Reviewed-by: Sean Paul 

> ---
>  drivers/gpu/drm/i915/intel_hdcp.c | 31 +--
>  1 file changed, 29 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
> b/drivers/gpu/drm/i915/intel_hdcp.c
> index 7ea55fa46f41..95081aaa832a 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -37,6 +37,33 @@ static int intel_hdcp_poll_ksv_fifo(struct 
> intel_digital_port *intel_dig_port,
>   return 0;
>  }
>  
> +static bool hdcp_key_loadable(struct drm_i915_private *dev_priv)
> +{
> + struct i915_power_domains *power_domains = _priv->power_domains;
> + struct i915_power_well *power_well;
> + bool enabled = false;
> +
> + mutex_lock(_domains->lock);
> +
> + /* PG1 (power well #1) needs to be enabled */
> + for_each_power_well(dev_priv, power_well) {
> + if (power_well->id == SKL_DISP_PW_1) {
> + enabled = power_well->ops->is_enabled(dev_priv,
> +   power_well);
> + break;
> + }
> + }
> + mutex_unlock(_domains->lock);
> +
> + /*
> +  * Another req for hdcp key loadability is enabled state of pll for
> +  * cdclk. Without active crtc we wont land here. So we are assuming that
> +  * cdclk is already on.
> +  */
> +
> + return enabled;
> +}
> +
>  static void intel_hdcp_clear_keys(struct drm_i915_private *dev_priv)
>  {
>   I915_WRITE(HDCP_KEY_CONF, HDCP_CLEAR_KEYS_TRIGGER);
> @@ -598,8 +625,8 @@ static int _intel_hdcp_enable(struct intel_connector 
> *connector)
>   DRM_DEBUG_KMS("[%s:%d] HDCP is being enabled...\n",
> connector->base.name, connector->base.base.id);
>  
> - if (!(I915_READ(SKL_FUSE_STATUS) & SKL_FUSE_PG_DIST_STATUS(1))) {
> - DRM_ERROR("PG1 is disabled, cannot load keys\n");
> + if (!hdcp_key_loadable(dev_priv)) {
> + DRM_ERROR("HDCP key Load is not possible\n");
>   return -ENXIO;
>   }
>  
> -- 
> 2.7.4
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105257] GPU HANG: ecode 9:0:0x86dffffd, in Xorg, reason: Hang on render ring, action: reset

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105257

--- Comment #2 from Ivan Levshin  ---
Created attachment 137613
  --> https://bugs.freedesktop.org/attachment.cgi?id=137613=edit
Output of "xrandr --verbose"

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105257] GPU HANG: ecode 9:0:0x86dffffd, in Xorg, reason: Hang on render ring, action: reset

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105257

--- Comment #1 from Ivan Levshin  ---
Created attachment 137612
  --> https://bugs.freedesktop.org/attachment.cgi?id=137612=edit
Output of "cat /sys/class/drm/card0/error"

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105257] GPU HANG: ecode 9:0:0x86dffffd, in Xorg, reason: Hang on render ring, action: reset

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105257

Bug ID: 105257
   Summary: GPU HANG: ecode 9:0:0x86dd, in Xorg, reason: Hang
on render ring, action: reset
   Product: Mesa
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/i915
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: ivanlevs...@yandex.ru
QA Contact: dri-devel@lists.freedesktop.org

Created attachment 137611
  --> https://bugs.freedesktop.org/attachment.cgi?id=137611=edit
dmesg output with an error

I'm in trouble with LibreOffice 6.0.1 during editing presentation in Impress:
everything just stops responding (whole DE, I'm using KDE Plasma) then after
some time I see that whole session reset, I have to start it again.

I'm using X.org in OpenSUSE Tumbleweed on MSI GS40 6QE Phantom. I've seen this
problem before (probably a yesr ago) but after some of updates it disappeared.
Nor it happening again and again.

To reproduce try to edit attached presentation, I cannot say what exactly
needed to be done as I had spontaneous freezes but I can say that it will
happens after 5-15 minutes you're working with it.

mynote:/home/ivan # uname -a
Linux mynote.levshin.site 4.15.4-1-default #1 SMP PREEMPT Sat Feb 17 09:02:00
UTC 2018 (7169cf1) x86_64 x86_64 x86_64 GNU/Linux

Problem happening only in the time I'm editing some (not all) presentations in
Impress, I haven't seen this problem with any other kind of workload. But I can
say that it seems to be related with presentation with a lot of graphic objects
embedded. At the same time it seems like X.org issue rather than LibreOffice
issue as I see error message in dmesg output where exactly i915 mentioned and
not a LO processes (like soffice).

mynote:/home/ivan # rpm -qa|grep -i mesa
Mesa-dri-nouveau-18.0.0-187.1.x86_64
Mesa-libGL-devel-18.0.0-187.1.x86_64
Mesa-libva-18.0.0-187.1.x86_64
Mesa-libEGL-devel-18.0.0-187.1.x86_64
Mesa-libGL1-18.0.0-187.1.x86_64
Mesa-gallium-18.0.0-187.1.x86_64
Mesa-dri-18.0.0-187.1.x86_64
Mesa-18.0.0-187.1.x86_64
Mesa-libEGL1-18.0.0-187.1.x86_64
Mesa-libglapi0-18.0.0-187.1.x86_64

mynote:/home/ivan # rpm -qa | grep -i xorg
xorg-x11-server-wayland-1.19.6-3.1.x86_64
xorg-x11-essentials-7.6_1-16.4.noarch
xorg-x11-libX11-ccache-7.6-20.5.noarch
xorg-x11-fonts-core-7.6-32.3.noarch
xorg-x11-fonts-7.6-32.3.noarch
xorg-x11-server-1.19.6-3.1.x86_64
xorg-x11-driver-input-7.6_1-14.3.noarch
xorg-x11-driver-video-7.6_1-17.1.x86_64

mynote:/home/ivan # rpm -qa | grep -i libreoffice
libreoffice-6.0.1.1-1.3.x86_64
libreoffice-gtk3-6.0.1.1-1.3.x86_64
libreoffice-l10n-ru-6.0.1.1-1.3.noarch
libreoffice-kde4-6.0.1.1-1.3.x86_64
libreoffice-l10n-en-6.0.1.1-1.3.noarch
libreoffice-draw-6.0.1.1-1.3.x86_64
libreoffice-writer-6.0.1.1-1.3.x86_64
libreoffice-base-drivers-mysql-6.0.1.1-1.3.x86_64
libreoffice-writer-extensions-6.0.1.1-1.3.x86_64
libreoffice-calc-6.0.1.1-1.3.x86_64
libreoffice-share-linker-1-4.3.noarch
libreoffice-branding-upstream-6.0.1.1-1.3.noarch
libreoffice-mailmerge-6.0.1.1-1.3.x86_64
libreoffice-pyuno-6.0.1.1-1.3.x86_64
libreoffice-impress-6.0.1.1-1.3.x86_64
libreoffice-filters-optional-6.0.1.1-1.3.x86_64
libreoffice-gnome-6.0.1.1-1.3.x86_64
libreoffice-base-6.0.1.1-1.3.x86_64
libreofficekit-6.0.1.1-1.3.x86_64
libreoffice-icon-themes-6.0.1.1-1.3.noarch
libreoffice-math-6.0.1.1-1.3.x86_64
libreoffice-calc-extensions-6.0.1.1-1.3.x86_64

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/5] drm/i915: read Vprime thrice incase of mismatch

[Sean Paul]

On Mon, Feb 26, 2018 at 10:42:36PM +0530, Ramalingam C wrote:
> In case of V prime mismatch, DP HDCP spec mandates the re-read of
> Vprime atleast twice.
> 
> DP HDCP CTS Test: 1B-05
> 
> Signed-off-by: Ramalingam C 
> ---
>  drivers/gpu/drm/i915/intel_hdcp.c | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
> b/drivers/gpu/drm/i915/intel_hdcp.c
> index 730681d2dbfb..7ea55fa46f41 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -150,7 +150,7 @@ int intel_hdcp_auth_downstream(struct intel_digital_port 
> *intel_dig_port,
>   struct drm_i915_private *dev_priv;
>   u32 vprime, sha_text, sha_leftovers, rep_ctl;
>   u8 bstatus[2], num_downstream, *ksv_fifo;
> - int ret, i, j, sha_idx;
> + int ret, i, j, sha_idx, tries = 3;
>  
>   dev_priv = intel_dig_port->base.base.dev->dev_private;
>  
> @@ -189,6 +189,7 @@ int intel_hdcp_auth_downstream(struct intel_digital_port 
> *intel_dig_port,
>   if (ret)
>   return ret;
>  
> +read_v_prime:

Instead of using the label for retry, please break it out into a function that's
enclosed in a retry loop.

Sean

>   /* Process V' values from the receiver */
>   for (i = 0; i < DRM_HDCP_V_PRIME_NUM_PARTS; i++) {
>   ret = shim->read_v_prime_part(intel_dig_port, i, );
> @@ -385,6 +386,13 @@ int intel_hdcp_auth_downstream(struct intel_digital_port 
> *intel_dig_port,
>   return -ETIMEDOUT;
>   }
>   if (!(I915_READ(HDCP_REP_CTL) & HDCP_SHA1_V_MATCH)) {
> +
> + /*
> +  * When V prime mismatches, DP Spec mandates re-read of
> +  * V prime atleast twice.
> +  */
> + if (--tries)
> + goto read_v_prime;
>   DRM_ERROR("SHA-1 mismatch, HDCP failed\n");
>   return -ENXIO;
>   }
> -- 
> 2.7.4
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/5] drm/i915: Read HDCP R0 thrice in case of mismatch

[Sean Paul]

On Mon, Feb 26, 2018 at 10:42:35PM +0530, Ramalingam C wrote:
> As per DP spec when R0 mismatch is detected, HDCP source supported
> re-read the R0 atleast twice.
> 
> And For HDMI and DP minimum wait required for the R0 availability is
> 100mSec. So this patch changes the wait time to 100mSec but retries
> twice with the time interval of 100mSec for each attempt.

"R0' must be available for the HDCP Transmitter to read within 100
milliseconds from the time that the HDCP Transmitter finishes writing Aksv to
the video receiver."

100ms is a minimum, waiting for 300ms is quite generous.

The retry is to account for link errors, so there's no need to include the wait
in the retry loop.

Sean

> 
> DP CTS Test: 1A-06.
> 
> Signed-off-by: Ramalingam C 
> ---
>  drivers/gpu/drm/i915/intel_hdcp.c | 34 ++
>  1 file changed, 22 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
> b/drivers/gpu/drm/i915/intel_hdcp.c
> index 14ca5d3057a7..730681d2dbfb 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -496,25 +496,35 @@ static int intel_hdcp_auth(struct intel_digital_port 
> *intel_dig_port,
>   }
>  
>   /*
> -  * Wait for R0' to become available. The spec says 100ms from Aksv, but
> -  * some monitors can take longer than this. We'll set the timeout at
> -  * 300ms just to be sure.
> +  * Wait for R0' to become available. The spec says minimum 100ms from
> +  * Aksv, but some monitors can take longer than this. So we are
> +  * combinely waiting for 300mSec just to be sure in case of HDMI.
> +  * DP HDCP Spec mandates the two more reattempt to read R0, incase
> +  * of R0 mismatch.
>*
>* On DP, there's an R0_READY bit available but no such bit
>* exists on HDMI. Since the upper-bound is the same, we'll just do
>* the stupid thing instead of polling on one and not the other.
>*/
> - wait_remaining_ms_from_jiffies(r0_prime_gen_start, 300);
>  
> - ri.reg = 0;
> - ret = shim->read_ri_prime(intel_dig_port, ri.shim);
> - if (ret)
> - return ret;
> - I915_WRITE(PORT_HDCP_RPRIME(port), ri.reg);
> + tries = 3;
> + for (i = 0; i < tries; i++) {
> + wait_remaining_ms_from_jiffies(r0_prime_gen_start,
> +100 * (i + 1));
>  
> - /* Wait for Ri prime match */
> - if (wait_for(I915_READ(PORT_HDCP_STATUS(port)) &
> -  (HDCP_STATUS_RI_MATCH | HDCP_STATUS_ENC), 1)) {
> + ri.reg = 0;
> + ret = shim->read_ri_prime(intel_dig_port, ri.shim);
> + if (ret)
> + return ret;
> + I915_WRITE(PORT_HDCP_RPRIME(port), ri.reg);
> +
> + /* Wait for Ri prime match */
> + if (!wait_for(I915_READ(PORT_HDCP_STATUS(port)) &
> + (HDCP_STATUS_RI_MATCH | HDCP_STATUS_ENC), 1))
> + break;
> + }
> +
> + if (i == tries) {
>   DRM_ERROR("Timed out waiting for Ri prime match (%x)\n",
> I915_READ(PORT_HDCP_STATUS(port)));
>   return -ETIMEDOUT;
> -- 
> 2.7.4
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 5/5] drm/i915: Move hdcp msg detection into shim

[Ramalingam C]

DP and HDMI HDCP specifications are varying with respect to
detecting the R0 and ksv_fifo availability.

DP will produce CP_IRQ and set a bit for indicating the R0 and
FIFO_READY status.

Whereas HDMI will set a bit for FIFO_READY but there is no bit
indication for R0 ready. And also polling of READY bit is needed for
HDMI as ther is no CP_IRQ.

So Fielding the CP_IRQ for DP and the polling the READY bit for a
period and blindly waiting for a fixed time for R0 incase of HDMI are
moved into corresponding hdcp_shim.

Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/i915/intel_dp.c   | 70 +++
 drivers/gpu/drm/i915/intel_drv.h  |  6 ++--
 drivers/gpu/drm/i915/intel_hdcp.c | 39 ++
 drivers/gpu/drm/i915/intel_hdmi.c | 28 +++-
 4 files changed, 98 insertions(+), 45 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 2c3eb90b9499..afe310a91d3c 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4436,6 +4436,7 @@ static bool
 intel_dp_short_pulse(struct intel_dp *intel_dp)
 {
struct drm_i915_private *dev_priv = to_i915(intel_dp_to_dev(intel_dp));
+   struct intel_connector *connector = intel_dp->attached_connector;
u8 sink_irq_vector = 0;
u8 old_sink_count = intel_dp->sink_count;
bool ret;
@@ -4470,8 +4471,11 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
 
if (sink_irq_vector & DP_AUTOMATED_TEST_REQUEST)
intel_dp_handle_test_request(intel_dp);
-   if (sink_irq_vector & (DP_CP_IRQ | DP_SINK_SPECIFIC_IRQ))
-   DRM_DEBUG_DRIVER("CP or sink specific irq unhandled\n");
+   if (sink_irq_vector & DP_CP_IRQ)
+   if (connector->hdcp_shim)
+   complete_all(>cp_irq_recved);
+   if (sink_irq_vector & DP_SINK_SPECIFIC_IRQ)
+   DRM_DEBUG_DRIVER("Sink specific irq unhandled\n");
}
 
intel_dp_check_link_status(intel_dp);
@@ -5083,6 +5087,25 @@ void intel_dp_encoder_suspend(struct intel_encoder 
*intel_encoder)
pps_unlock(intel_dp);
 }
 
+static int intel_dp_hdcp_wait_for_cp_irq(struct completion *cp_irq_recved,
+int timeout)
+{
+   long ret;
+
+   if (completion_done(cp_irq_recved))
+   reinit_completion(cp_irq_recved);
+
+   ret = wait_for_completion_interruptible_timeout(cp_irq_recved,
+   msecs_to_jiffies(
+   timeout));
+   reinit_completion(cp_irq_recved);
+   if (ret < 0)
+   return (int)ret;
+   else if (!ret)
+   return -ETIMEDOUT;
+   return 0;
+}
+
 static
 int intel_dp_hdcp_write_an_aksv(struct intel_digital_port *intel_dig_port,
u8 *an)
@@ -5188,11 +5211,38 @@ int intel_dp_hdcp_repeater_present(struct 
intel_digital_port *intel_dig_port,
return 0;
 }
 
+static int intel_dp_hdcp_wait_for_r0(struct intel_digital_port *intel_dig_port)
+{
+   struct intel_dp *dp = _dig_port->dp;
+   struct intel_connector *connector = dp->attached_connector;
+   int ret;
+   u8 bstatus;
+
+   intel_dp_hdcp_wait_for_cp_irq(>cp_irq_recved, 100);
+
+   ret = drm_dp_dpcd_read(_dig_port->dp.aux, DP_AUX_HDCP_BSTATUS,
+  , 1);
+   if (ret != 1) {
+   DRM_ERROR("Read bstatus from DP/AUX failed (%d)\n", ret);
+   return ret >= 0 ? -EIO : ret;
+   }
+
+   if (!(bstatus & DP_BSTATUS_R0_PRIME_READY))
+   return -ETIMEDOUT;
+
+   return 0;
+}
+
 static
 int intel_dp_hdcp_read_ri_prime(struct intel_digital_port *intel_dig_port,
u8 *ri_prime)
 {
ssize_t ret;
+
+   ret = intel_dp_hdcp_wait_for_r0(intel_dig_port);
+   if (!ret)
+   return ret;
+
ret = drm_dp_dpcd_read(_dig_port->dp.aux, DP_AUX_HDCP_RI_PRIME,
   ri_prime, DRM_HDCP_RI_LEN);
if (ret != DRM_HDCP_RI_LEN) {
@@ -5203,18 +5253,26 @@ int intel_dp_hdcp_read_ri_prime(struct 
intel_digital_port *intel_dig_port,
 }
 
 static
-int intel_dp_hdcp_read_ksv_ready(struct intel_digital_port *intel_dig_port,
-bool *ksv_ready)
+int intel_dp_hdcp_ksv_ready(struct intel_digital_port *intel_dig_port)
 {
+   struct intel_dp *dp = _dig_port->dp;
+   struct intel_connector *connector = dp->attached_connector;
ssize_t ret;
u8 bstatus;
+
+   intel_dp_hdcp_wait_for_cp_irq(>cp_irq_recved,
+ 5 * 1000 * 1000);
+
ret = drm_dp_dpcd_read(_dig_port->dp.aux, DP_AUX_HDCP_BSTATUS,
   , 1);
if (ret != 1) {
DRM_ERROR("Read bstatus 

[PATCH 0/5] HDCP1.4 fixes

[Ramalingam C]

This series addresses the requriement of below HDCP compliance tests
DP: 1A-06 and 1B-05
HDMI: 1A-04 and 1A-07a

One of the patch uses the I915 power infra-structure for checking
the power state of PW#1. Which enables the init path for all legacy
platforms.

And encoder specific msg availability detection is moved into hdcp_shim.
This will help to sync with DP hdcp data availability in the best
possible way by fielding the CP_IRQ.


Ramalingam C (5):
  drm/i915: Read HDCP R0 thrice in case of mismatch
  drm/i915: read Vprime thrice incase of mismatch
  drm/i915: Check hdcp key loadability
  drm/i915: Poll hdcp register on sudden NACK
  drm/i915: Move hdcp msg detection into shim

 drivers/gpu/drm/i915/intel_dp.c   |  70 ++--
 drivers/gpu/drm/i915/intel_drv.h  |   6 +-
 drivers/gpu/drm/i915/intel_hdcp.c | 166 +++---
 drivers/gpu/drm/i915/intel_hdmi.c |  28 ++-
 4 files changed, 214 insertions(+), 56 deletions(-)

-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4/5] drm/i915: Poll hdcp register on sudden NACK

[Ramalingam C]

In a connected state, If a HDMI HDCP sink is responded with NACK for
HDCP I2C register access, then HDMI HDCP spec mandates the polling
of any HDCP space registers for accessibility, minimum once in 2Secs
atleast for 4Secs.

Just to make it simple, this is generically implemented for both HDMI
and DP. But we dont expect that this scanario will occur for DP.

HDMI HDCP CTS Tests: 1A-04 and 1A-07A.

Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/i915/intel_hdcp.c | 74 +++
 1 file changed, 67 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index 95081aaa832a..14be14a45e5a 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -16,6 +16,47 @@
 
 #define KEY_LOAD_TRIES 5
 
+static
+struct intel_digital_port *conn_to_dig_port(struct intel_connector *connector)
+{
+   return enc_to_dig_port(_attached_encoder(>base)->base);
+}
+
+static inline bool hdcp_port_accessible(struct intel_connector *connector)
+{
+   struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+   int ret = -ENXIO;
+   u8 bksv[DRM_HDCP_KSV_LEN];
+
+   ret = connector->hdcp_shim->read_bksv(intel_dig_port, bksv);
+   if (!ret)
+   return true;
+   return false;
+}
+
+static bool wait_for_hdcp_port(struct intel_connector *connector)
+{
+   int i, tries = 10;
+
+   for (i = 0; i < tries; i++) {
+   if (connector->base.status != connector_status_connected ||
+   connector->base.state->content_protection ==
+   DRM_MODE_CONTENT_PROTECTION_UNDESIRED ||
+   connector->hdcp_value ==
+   DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
+   return false;
+
+   if (hdcp_port_accessible(connector))
+   break;
+
+   msleep_interruptible(500);
+   }
+
+   if (i == tries)
+   return false;
+   return true;
+}
+
 static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port *intel_dig_port,
const struct intel_hdcp_shim *shim)
 {
@@ -584,12 +625,6 @@ static int intel_hdcp_auth(struct intel_digital_port 
*intel_dig_port,
return 0;
 }
 
-static
-struct intel_digital_port *conn_to_dig_port(struct intel_connector *connector)
-{
-   return enc_to_dig_port(_attached_encoder(>base)->base);
-}
-
 static int _intel_hdcp_disable(struct intel_connector *connector)
 {
struct drm_i915_private *dev_priv = connector->base.dev->dev_private;
@@ -719,14 +754,26 @@ int intel_hdcp_init(struct intel_connector *connector,
 
 int intel_hdcp_enable(struct intel_connector *connector)
 {
-   int ret;
+   int ret, tries = 2;
 
if (!connector->hdcp_shim)
return -ENOENT;
 
mutex_lock(>hdcp_mutex);
 
+enable_hdcp:
ret = _intel_hdcp_enable(connector);
+
+   /*
+* Suddenly if sink is NACK-ed for the access of HDCP
+* registers, but display is still connected, poll for hdcp
+* port accessibility. One of the HDCP spec requirement.
+*/
+   if ((ret == -EIO || ret == -ENXIO) &&
+   connector->base.status == connector_status_connected &&
+   !hdcp_port_accessible(connector))
+   if (wait_for_hdcp_port(connector) && --tries)
+   goto enable_hdcp;
if (ret)
goto out;
 
@@ -838,6 +885,19 @@ int intel_hdcp_check_link(struct intel_connector 
*connector)
goto out;
}
 
+   /*
+* Suddenly if sink is NACK-ed for the access of HDCP
+* registers, but display is still connected, poll for hdcp
+* port accessibility. One of the HDCP spec requirement.
+*/
+   if (connector->base.status == connector_status_connected &&
+   !hdcp_port_accessible(connector)) {
+   mutex_unlock(>hdcp_mutex);
+   if (!wait_for_hdcp_port(connector))
+   return ret;
+   mutex_lock(>hdcp_mutex);
+   }
+
ret = _intel_hdcp_enable(connector);
if (ret) {
DRM_ERROR("Failed to enable hdcp (%d)\n", ret);
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/5] drm/i915: read Vprime thrice incase of mismatch

[Ramalingam C]

In case of V prime mismatch, DP HDCP spec mandates the re-read of
Vprime atleast twice.

DP HDCP CTS Test: 1B-05

Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/i915/intel_hdcp.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index 730681d2dbfb..7ea55fa46f41 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -150,7 +150,7 @@ int intel_hdcp_auth_downstream(struct intel_digital_port 
*intel_dig_port,
struct drm_i915_private *dev_priv;
u32 vprime, sha_text, sha_leftovers, rep_ctl;
u8 bstatus[2], num_downstream, *ksv_fifo;
-   int ret, i, j, sha_idx;
+   int ret, i, j, sha_idx, tries = 3;
 
dev_priv = intel_dig_port->base.base.dev->dev_private;
 
@@ -189,6 +189,7 @@ int intel_hdcp_auth_downstream(struct intel_digital_port 
*intel_dig_port,
if (ret)
return ret;
 
+read_v_prime:
/* Process V' values from the receiver */
for (i = 0; i < DRM_HDCP_V_PRIME_NUM_PARTS; i++) {
ret = shim->read_v_prime_part(intel_dig_port, i, );
@@ -385,6 +386,13 @@ int intel_hdcp_auth_downstream(struct intel_digital_port 
*intel_dig_port,
return -ETIMEDOUT;
}
if (!(I915_READ(HDCP_REP_CTL) & HDCP_SHA1_V_MATCH)) {
+
+   /*
+* When V prime mismatches, DP Spec mandates re-read of
+* V prime atleast twice.
+*/
+   if (--tries)
+   goto read_v_prime;
DRM_ERROR("SHA-1 mismatch, HDCP failed\n");
return -ENXIO;
}
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/5] drm/i915: Check hdcp key loadability

[Ramalingam C]

HDCP1.4 key can be loaded, only when Power well #1 is enabled and cdclk
is enabled. Using the I915 power well infrastruture, above requirement
is verified.

This patch enables the hdcp initialization for HSW, BDW, and BXT.

Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/i915/intel_hdcp.c | 31 +--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index 7ea55fa46f41..95081aaa832a 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -37,6 +37,33 @@ static int intel_hdcp_poll_ksv_fifo(struct 
intel_digital_port *intel_dig_port,
return 0;
 }
 
+static bool hdcp_key_loadable(struct drm_i915_private *dev_priv)
+{
+   struct i915_power_domains *power_domains = _priv->power_domains;
+   struct i915_power_well *power_well;
+   bool enabled = false;
+
+   mutex_lock(_domains->lock);
+
+   /* PG1 (power well #1) needs to be enabled */
+   for_each_power_well(dev_priv, power_well) {
+   if (power_well->id == SKL_DISP_PW_1) {
+   enabled = power_well->ops->is_enabled(dev_priv,
+ power_well);
+   break;
+   }
+   }
+   mutex_unlock(_domains->lock);
+
+   /*
+* Another req for hdcp key loadability is enabled state of pll for
+* cdclk. Without active crtc we wont land here. So we are assuming that
+* cdclk is already on.
+*/
+
+   return enabled;
+}
+
 static void intel_hdcp_clear_keys(struct drm_i915_private *dev_priv)
 {
I915_WRITE(HDCP_KEY_CONF, HDCP_CLEAR_KEYS_TRIGGER);
@@ -598,8 +625,8 @@ static int _intel_hdcp_enable(struct intel_connector 
*connector)
DRM_DEBUG_KMS("[%s:%d] HDCP is being enabled...\n",
  connector->base.name, connector->base.base.id);
 
-   if (!(I915_READ(SKL_FUSE_STATUS) & SKL_FUSE_PG_DIST_STATUS(1))) {
-   DRM_ERROR("PG1 is disabled, cannot load keys\n");
+   if (!hdcp_key_loadable(dev_priv)) {
+   DRM_ERROR("HDCP key Load is not possible\n");
return -ENXIO;
}
 
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/5] drm/i915: Read HDCP R0 thrice in case of mismatch

[Ramalingam C]

As per DP spec when R0 mismatch is detected, HDCP source supported
re-read the R0 atleast twice.

And For HDMI and DP minimum wait required for the R0 availability is
100mSec. So this patch changes the wait time to 100mSec but retries
twice with the time interval of 100mSec for each attempt.

DP CTS Test: 1A-06.

Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/i915/intel_hdcp.c | 34 ++
 1 file changed, 22 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index 14ca5d3057a7..730681d2dbfb 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -496,25 +496,35 @@ static int intel_hdcp_auth(struct intel_digital_port 
*intel_dig_port,
}
 
/*
-* Wait for R0' to become available. The spec says 100ms from Aksv, but
-* some monitors can take longer than this. We'll set the timeout at
-* 300ms just to be sure.
+* Wait for R0' to become available. The spec says minimum 100ms from
+* Aksv, but some monitors can take longer than this. So we are
+* combinely waiting for 300mSec just to be sure in case of HDMI.
+* DP HDCP Spec mandates the two more reattempt to read R0, incase
+* of R0 mismatch.
 *
 * On DP, there's an R0_READY bit available but no such bit
 * exists on HDMI. Since the upper-bound is the same, we'll just do
 * the stupid thing instead of polling on one and not the other.
 */
-   wait_remaining_ms_from_jiffies(r0_prime_gen_start, 300);
 
-   ri.reg = 0;
-   ret = shim->read_ri_prime(intel_dig_port, ri.shim);
-   if (ret)
-   return ret;
-   I915_WRITE(PORT_HDCP_RPRIME(port), ri.reg);
+   tries = 3;
+   for (i = 0; i < tries; i++) {
+   wait_remaining_ms_from_jiffies(r0_prime_gen_start,
+  100 * (i + 1));
 
-   /* Wait for Ri prime match */
-   if (wait_for(I915_READ(PORT_HDCP_STATUS(port)) &
-(HDCP_STATUS_RI_MATCH | HDCP_STATUS_ENC), 1)) {
+   ri.reg = 0;
+   ret = shim->read_ri_prime(intel_dig_port, ri.shim);
+   if (ret)
+   return ret;
+   I915_WRITE(PORT_HDCP_RPRIME(port), ri.reg);
+
+   /* Wait for Ri prime match */
+   if (!wait_for(I915_READ(PORT_HDCP_STATUS(port)) &
+   (HDCP_STATUS_RI_MATCH | HDCP_STATUS_ENC), 1))
+   break;
+   }
+
+   if (i == tries) {
DRM_ERROR("Timed out waiting for Ri prime match (%x)\n",
  I915_READ(PORT_HDCP_STATUS(port)));
return -ETIMEDOUT;
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] selftests: ion: Add simple test with the vgem driver

[Shuah Khan]

On 02/19/2018 11:33 AM, Daniel Vetter wrote:
> On Mon, Feb 19, 2018 at 10:18:21AM -0800, Laura Abbott wrote:
>> On 02/19/2018 07:31 AM, Daniel Vetter wrote:
>>> On Thu, Feb 15, 2018 at 05:24:45PM -0800, Laura Abbott wrote:
 Ion is designed to be a framework used by other clients who perform
 operations on the buffer. Use the DRM vgem client as a simple consumer.
 In conjunction with the dma-buf sync ioctls, this tests the full attach/map
 path for the system heap.

 Signed-off-by: Laura Abbott 
 ---
   tools/testing/selftests/android/ion/Makefile  |   3 +-
   tools/testing/selftests/android/ion/config|   1 +
   tools/testing/selftests/android/ion/ionmap_test.c | 136 
 ++
   3 files changed, 139 insertions(+), 1 deletion(-)
   create mode 100644 tools/testing/selftests/android/ion/ionmap_test.c

 diff --git a/tools/testing/selftests/android/ion/Makefile 
 b/tools/testing/selftests/android/ion/Makefile
 index 96e0c448b39d..d23b6d537d8b 100644
 --- a/tools/testing/selftests/android/ion/Makefile
 +++ b/tools/testing/selftests/android/ion/Makefile
 @@ -2,7 +2,7 @@
   INCLUDEDIR := -I. -I../../../../../drivers/staging/android/uapi/
   CFLAGS := $(CFLAGS) $(INCLUDEDIR) -Wall -O2 -g
 -TEST_GEN_FILES := ionapp_export ionapp_import
 +TEST_GEN_FILES := ionapp_export ionapp_import ionmap_test
   all: $(TEST_GEN_FILES)
 @@ -14,3 +14,4 @@ include ../../lib.mk
   $(OUTPUT)/ionapp_export: ionapp_export.c ipcsocket.c ionutils.c
   $(OUTPUT)/ionapp_import: ionapp_import.c ipcsocket.c ionutils.c
 +$(OUTPUT)/ionmap_test: ionmap_test.c ionutils.c
 diff --git a/tools/testing/selftests/android/ion/config 
 b/tools/testing/selftests/android/ion/config
 index 19db6ca9aa2b..b4ad748a9dd9 100644
 --- a/tools/testing/selftests/android/ion/config
 +++ b/tools/testing/selftests/android/ion/config
 @@ -2,3 +2,4 @@ CONFIG_ANDROID=y
   CONFIG_STAGING=y
   CONFIG_ION=y
   CONFIG_ION_SYSTEM_HEAP=y
 +CONFIG_DRM_VGEM=y
 diff --git a/tools/testing/selftests/android/ion/ionmap_test.c 
 b/tools/testing/selftests/android/ion/ionmap_test.c
 new file mode 100644
 index ..dab36b06b37d
 --- /dev/null
 +++ b/tools/testing/selftests/android/ion/ionmap_test.c
 @@ -0,0 +1,136 @@
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +
 +#include 
 +#include 
 +#include 
 +
 +#include 
 +
 +#include 
 +
 +#include "ion.h"
 +#include "ionutils.h"
 +
 +int check_vgem(int fd)
 +{
 +  drm_version_t version = { 0 };
 +  char name[5];
 +  int ret;
 +
 +  version.name_len = 4;
 +  version.name = name;
 +
 +  ret = ioctl(fd, DRM_IOCTL_VERSION, );
 +  if (ret)
 +  return 1;
 +
 +  return strcmp(name, "vgem");
 +}
 +
 +int open_vgem(void)
 +{
 +  int i, fd;
 +  const char *drmstr = "/dev/dri/card";
 +
 +  fd = -1;
 +  for (i = 0; i < 16; i++) {
 +  char name[80];
 +
 +  sprintf(name, "%s%u", drmstr, i);
 +
 +  fd = open(name, O_RDWR);
 +  if (fd < 0)
 +  continue;
 +
 +  if (check_vgem(fd)) {
 +  close(fd);
 +  continue;
 +  } else {
 +  break;
 +  }
 +
 +  }
 +  return fd;
 +}
 +
 +int import_vgem_fd(int vgem_fd, int dma_buf_fd, uint32_t *handle)
 +{
 +  struct drm_prime_handle import_handle = { 0 };
 +  int ret;
 +
 +  import_handle.fd = dma_buf_fd;
 +  import_handle.flags = 0;
 +  import_handle.handle = 0;
 +
 +  ret = ioctl(vgem_fd, DRM_IOCTL_PRIME_FD_TO_HANDLE, _handle);
 +  if (ret == 0)
 +  *handle = import_handle.handle;
 +  return ret;
 +}
 +
 +void close_handle(int vgem_fd, uint32_t handle)
 +{
 +  struct drm_gem_close close = { 0 };
 +
 +  close.handle = handle;
 +  ioctl(vgem_fd, DRM_IOCTL_GEM_CLOSE, );
 +}
 +
 +int main()
 +{
 +  int ret, vgem_fd;
 +  struct ion_buffer_info info;
 +  uint32_t handle = 0;
 +  struct dma_buf_sync sync = { 0 };
 +
 +  info.heap_type = ION_HEAP_TYPE_SYSTEM;
 +  info.heap_size = 4096;
 +  info.flag_type = ION_FLAG_CACHED;
 +
 +  ret = ion_export_buffer_fd();
 +  if (ret < 0) {
 +  printf("ion buffer alloc failed\n");
 +  return -1;
 +  }
 +
 +  vgem_fd = open_vgem();
 +  if (vgem_fd < 0) {
 +  ret = vgem_fd;
 +  printf("Failed to open vgem\n");
 +  goto out_ion;
 +  }
 +
 +  ret = import_vgem_fd(vgem_fd, info.buffd, );
 +
 +  if (ret < 0) {
 +  

Re: [PATCH 1/2] selftests: ion: Remove some prints

[Shuah Khan]

On 02/15/2018 06:24 PM, Laura Abbott wrote:
> There's no need to print messages each time we alloc and free. Remove them.
> 
> Signed-off-by: Laura Abbott 
> ---
>  tools/testing/selftests/android/ion/ionutils.c | 6 --
>  1 file changed, 6 deletions(-)
> 
> diff --git a/tools/testing/selftests/android/ion/ionutils.c 
> b/tools/testing/selftests/android/ion/ionutils.c
> index ce69c14f51fa..7d1d37c4ef6a 100644
> --- a/tools/testing/selftests/android/ion/ionutils.c
> +++ b/tools/testing/selftests/android/ion/ionutils.c
> @@ -80,11 +80,6 @@ int ion_export_buffer_fd(struct ion_buffer_info *ion_info)
>   heap_id = MAX_HEAP_COUNT + 1;
>   for (i = 0; i < query.cnt; i++) {
>   if (heap_data[i].type == ion_info->heap_type) {
> - printf("--\n");
> - printf("heap type: %d\n", heap_data[i].type);
> - printf("  heap id: %d\n", heap_data[i].heap_id);
> - printf("heap name: %s\n", heap_data[i].name);
> - printf("--\n");
>   heap_id = heap_data[i].heap_id;
>   break;
>   }
> @@ -204,7 +199,6 @@ void ion_close_buffer_fd(struct ion_buffer_info *ion_info)
>   /* Finally, close the client fd */
>   if (ion_info->ionfd > 0)
>   close(ion_info->ionfd);
> - printf("<%s>: buffer release successfully\n", __func__);
>   }
>  }
>  
> 
Thanks Laura. I will queue this up for 4.17-rc1.

thanks,
-- Shuah

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 0/1] Color space conversion uapi part2

[Alexandru-Cosmin Gheorghe]

On Mon, Feb 26, 2018 at 06:04:37PM +0200, Ville Syrjälä wrote:
> On Mon, Feb 26, 2018 at 03:59:21PM +, Alexandru Gheorghe wrote:
> > This is an attempt to revive the color space conversation that started
> > here [1] and was materialized with the color encoding and color range
> > properties for converting YUV2RGB, the last version of this patch
> > series is here [2].
> > 
> > However, we still need a way of specifing the color gamut and transfer
> > function(gamma) for a given plane, in order to be sure that the
> > blending is done in the same domain space, which is not an issue for
> > similar gammuts, but not so good when mixing wider gamuts like Rec2020
> > and DCI-P3 with narrow ones.
> > 
> > In consequence, the userspace needs to control what is the color gamut
> > used for blending.
> > 
> > On Mali DP hardware, a complete color processing pipeline for a plane
> > looks like this:
> > 
> > YUV2RGB -> DEGAMA -> RGB2RGB(Gammut conv) -> GAMMA.
> > 
> > Of course, depending on hardware generation some of this elements are
> > not present or disabled if we are dealing with a RGB buffer already
> > in linear space. But it's up to the usperspace to decide what it wants
> > when the hardware doesn't provide full support for its needs.
> > 
> > What this patchset proposes is to add plane degamma, ctm and gamma
> > properties to be applied in this order after the yuv2rgb conversion
> > specified by the color encoding property[2]. We already have this sort
> > of pipeline(degamma, ctm, gamma) at the other end of a CRTC, so it
> > wouldn't be a totaly new interface for userspaces to figure it out how
> > to use.
> > 
> > There are still some things to be done before getting this patchset in
> > mergeable shape like: mali-dp driver implementation, real userspace
> > (drm_hwcomposer is the likely candidate here, but I'm open to
> > suggestions here), reuse some of the code for both crtc and plane.
> > 
> > But first, I would like to see what everybody things about this idea,
> > or if it has a different perspective of how this should be handled.
> > 
> > [1] https://lkml.org/lkml/2017/3/16/681
> > [2] https://www.spinics.net/lists/intel-gfx/msg156211.html
> 
> How is this related to eg.
> https://patchwork.freedesktop.org/series/30876/ ?
I wasn't aware of this patchset. Thanks.
Same idea, almost identical implementation, I suppose it's true that
some topics pop-up periodically.

@Uma, is there an updated patchset anywhere that I missed.

> 
> > 
> > Mihail Atanassov (1):
> >   drm: Add per-plane color management
> > 
> >  drivers/gpu/drm/drm_atomic.c| 28 ++
> >  drivers/gpu/drm/drm_atomic_helper.c |  9 +
> >  drivers/gpu/drm/drm_color_mgmt.c| 76 
> > +++--
> >  include/drm/drm_color_mgmt.h|  5 +++
> >  include/drm/drm_mode_config.h   | 20 +-
> >  include/drm/drm_plane.h |  8 
> >  6 files changed, 117 insertions(+), 29 deletions(-)
> > 
> > -- 
> > 2.7.4
> > 
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> -- 
> Ville Syrjälä
> Intel OTC
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105256] Slow performance using glDrawElementsBaseVertex

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105256

Bug ID: 105256
   Summary: Slow performance using glDrawElementsBaseVertex
   Product: Mesa
   Version: 17.3
  Hardware: Other
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: lo...@bacoosta.com
QA Contact: dri-devel@lists.freedesktop.org

Original application bug report here:

https://github.com/gonetz/GLideN64/issues/1561

This bug happens using mupen64plus (N64 emulator) and the GLideN64 graphics
plugin.

The application uses VBO streaming
(https://www.khronos.org/opengl/wiki/Buffer_Object_Streaming) using
ARB_buffer_storage to upload the VBO data.

Multiple users that when using Mesa + r600 driver, the performance was abysmal.
It turns out that converting the glDrawElementsBaseVertex calls to glDrawArrays
fixed the problem.

You can see the commit that fixed the problem here:

https://github.com/loganmc10/GLideN64/commit/9bcfa67d9550c7f1cd4ba72f657facd66a4d27e4

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104285] Euro Truck Simulator 2 and American Truck Simulator artifacts (Mesa 17.3, AMD R9 280X)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=104285

--- Comment #8 from Alex Vorobyev  ---
I think it's not the same bug. CS:GO works on my system as it should, while SCS
games still have broken shadows.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm 2/2] amdgpu: add AMDGPU_VA_RANGE_HIGH

[Marek Olšák]

For the series:

Reviewed-by: Marek Olšák 

Marek

On Mon, Feb 26, 2018 at 2:16 PM, Christian König
 wrote:
> Return high addresses if requested and available.
>
> Signed-off-by: Christian König 
> ---
>  amdgpu/amdgpu.h  |  1 +
>  amdgpu/amdgpu_device.c   |  6 --
>  amdgpu/amdgpu_internal.h |  1 -
>  amdgpu/amdgpu_vamgr.c| 24 +++-
>  4 files changed, 24 insertions(+), 8 deletions(-)
>
> diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
> index 928b2a68..36f91058 100644
> --- a/amdgpu/amdgpu.h
> +++ b/amdgpu/amdgpu.h
> @@ -1162,6 +1162,7 @@ int amdgpu_read_mm_registers(amdgpu_device_handle dev, 
> unsigned dword_offset,
>   * Flag to request VA address range in the 32bit address space
>  */
>  #define AMDGPU_VA_RANGE_32_BIT 0x1
> +#define AMDGPU_VA_RANGE_HIGH   0x2
>
>  /**
>   * Allocate virtual address range
> diff --git a/amdgpu/amdgpu_device.c b/amdgpu/amdgpu_device.c
> index ca0c7987..9ff6ad16 100644
> --- a/amdgpu/amdgpu_device.c
> +++ b/amdgpu/amdgpu_device.c
> @@ -268,7 +268,6 @@ int amdgpu_device_initialize(int fd,
> max = MIN2(dev->dev_info.virtual_address_max, 0x1ULL);
> amdgpu_vamgr_init(>vamgr_32, start, max,
>   dev->dev_info.virtual_address_alignment);
> -   dev->address32_hi = start >> 32;
>
> start = max;
> max = MAX2(dev->dev_info.virtual_address_max, 0x1ULL);
> @@ -323,7 +322,10 @@ int amdgpu_query_sw_info(amdgpu_device_handle dev, enum 
> amdgpu_sw_info info,
>
> switch (info) {
> case amdgpu_sw_info_address32_hi:
> -   *val32 = dev->address32_hi;
> +   if (dev->vamgr_high_32.va_max)
> +   *val32 = dev->vamgr_high_32.va_max >> 32;
> +   else
> +   *val32 = dev->vamgr_32.va_max >> 32;
> return 0;
> }
> return -EINVAL;
> diff --git a/amdgpu/amdgpu_internal.h b/amdgpu/amdgpu_internal.h
> index 423880ed..aeb5d651 100644
> --- a/amdgpu/amdgpu_internal.h
> +++ b/amdgpu/amdgpu_internal.h
> @@ -73,7 +73,6 @@ struct amdgpu_device {
> int flink_fd;
> unsigned major_version;
> unsigned minor_version;
> -   uint32_t address32_hi;
>
> char *marketing_name;
> /** List of buffer handles. Protected by bo_table_mutex. */
> diff --git a/amdgpu/amdgpu_vamgr.c b/amdgpu/amdgpu_vamgr.c
> index 58400428..ac1202de 100644
> --- a/amdgpu/amdgpu_vamgr.c
> +++ b/amdgpu/amdgpu_vamgr.c
> @@ -201,10 +201,21 @@ int amdgpu_va_range_alloc(amdgpu_device_handle dev,
>  {
> struct amdgpu_bo_va_mgr *vamgr;
>
> -   if (flags & AMDGPU_VA_RANGE_32_BIT)
> -   vamgr = >vamgr_32;
> -   else
> -   vamgr = >vamgr;
> +   /* Clear the flag when the high VA manager is not initialized */
> +   if (flags & AMDGPU_VA_RANGE_HIGH && !dev->vamgr_high_32.va_max)
> +   flags &= ~AMDGPU_VA_RANGE_HIGH;
> +
> +   if (flags & AMDGPU_VA_RANGE_HIGH) {
> +   if (flags & AMDGPU_VA_RANGE_32_BIT)
> +   vamgr = >vamgr_high_32;
> +   else
> +   vamgr = >vamgr_high;
> +   } else {
> +   if (flags & AMDGPU_VA_RANGE_32_BIT)
> +   vamgr = >vamgr_32;
> +   else
> +   vamgr = >vamgr;
> +   }
>
> va_base_alignment = MAX2(va_base_alignment, vamgr->va_alignment);
> size = ALIGN(size, vamgr->va_alignment);
> @@ -215,7 +226,10 @@ int amdgpu_va_range_alloc(amdgpu_device_handle dev,
> if (!(flags & AMDGPU_VA_RANGE_32_BIT) &&
> (*va_base_allocated == AMDGPU_INVALID_VA_ADDRESS)) {
> /* fallback to 32bit address */
> -   vamgr = >vamgr_32;
> +   if (flags & AMDGPU_VA_RANGE_HIGH)
> +   vamgr = >vamgr_high_32;
> +   else
> +   vamgr = >vamgr_32;
> *va_base_allocated = amdgpu_vamgr_find_va(vamgr, size,
> va_base_alignment, va_base_required);
> }
> --
> 2.14.1
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 198883] amdgpu: carrizo: Screen stalls after starting X

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=198883

--- Comment #22 from Andrey Grodzovsky (andrey.grodzov...@amd.com) ---
I tried cold resets around 15 times (taking out the power cord) running lightdm
manger or directly xinit and haven't seen any hang.

Let me know your firmware versions - 
cat /sys/kernel/debug/dri/0/amdgpu_firmware_info

THanks,
Andrey

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105244] NULL dereference during startup of Cape Verde with AMDGPU and GPU passthrough

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105244

--- Comment #1 from Alex Deucher  ---
Created attachment 137609
  --> https://bugs.freedesktop.org/attachment.cgi?id=137609=edit
possible fix

This patch should fix it.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 0/1] Color space conversion uapi part2

[Ville Syrjälä]

On Mon, Feb 26, 2018 at 03:59:21PM +, Alexandru Gheorghe wrote:
> This is an attempt to revive the color space conversation that started
> here [1] and was materialized with the color encoding and color range
> properties for converting YUV2RGB, the last version of this patch
> series is here [2].
> 
> However, we still need a way of specifing the color gamut and transfer
> function(gamma) for a given plane, in order to be sure that the
> blending is done in the same domain space, which is not an issue for
> similar gammuts, but not so good when mixing wider gamuts like Rec2020
> and DCI-P3 with narrow ones.
> 
> In consequence, the userspace needs to control what is the color gamut
> used for blending.
> 
> On Mali DP hardware, a complete color processing pipeline for a plane
> looks like this:
> 
> YUV2RGB -> DEGAMA -> RGB2RGB(Gammut conv) -> GAMMA.
> 
> Of course, depending on hardware generation some of this elements are
> not present or disabled if we are dealing with a RGB buffer already
> in linear space. But it's up to the usperspace to decide what it wants
> when the hardware doesn't provide full support for its needs.
> 
> What this patchset proposes is to add plane degamma, ctm and gamma
> properties to be applied in this order after the yuv2rgb conversion
> specified by the color encoding property[2]. We already have this sort
> of pipeline(degamma, ctm, gamma) at the other end of a CRTC, so it
> wouldn't be a totaly new interface for userspaces to figure it out how
> to use.
> 
> There are still some things to be done before getting this patchset in
> mergeable shape like: mali-dp driver implementation, real userspace
> (drm_hwcomposer is the likely candidate here, but I'm open to
> suggestions here), reuse some of the code for both crtc and plane.
> 
> But first, I would like to see what everybody things about this idea,
> or if it has a different perspective of how this should be handled.
> 
> [1] https://lkml.org/lkml/2017/3/16/681
> [2] https://www.spinics.net/lists/intel-gfx/msg156211.html

How is this related to eg.
https://patchwork.freedesktop.org/series/30876/ ?

> 
> Mihail Atanassov (1):
>   drm: Add per-plane color management
> 
>  drivers/gpu/drm/drm_atomic.c| 28 ++
>  drivers/gpu/drm/drm_atomic_helper.c |  9 +
>  drivers/gpu/drm/drm_color_mgmt.c| 76 
> +++--
>  include/drm/drm_color_mgmt.h|  5 +++
>  include/drm/drm_mode_config.h   | 20 +-
>  include/drm/drm_plane.h |  8 
>  6 files changed, 117 insertions(+), 29 deletions(-)
> 
> -- 
> 2.7.4
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 102323] [DC] System crashes when woken up from S3 sleep while HDMI display is switched off

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=102323

--- Comment #5 from Harry Wentland  ---
Are you able to give Alex's amd-staging-drm-next or drm-next-4.17-wip branch
from https://cgit.freedesktop.org/~agd5f/linux/?h=amd-staging-drm-next a try?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/1] [RFC] drm: Add per-plane color management

[Alexandru Gheorghe]

From: Mihail Atanassov 

Export drm_plane_enable_color_mgmt, which attaches the existing degamma,
ctm, and gamma properties to a plane. Add a color_mgmt_changed flag to
drm_plane_state, mimicking the drm_crtc_state flag of the same name.

Signed-off-by: Mihail Atanassov 
Signed-off-by: Alexandru Gheorghe 
---
 drivers/gpu/drm/drm_atomic.c| 33 
 drivers/gpu/drm/drm_atomic_helper.c |  9 +
 drivers/gpu/drm/drm_color_mgmt.c| 76 +++--
 include/drm/drm_color_mgmt.h|  5 +++
 include/drm/drm_mode_config.h   | 20 +-
 include/drm/drm_plane.h |  8 
 6 files changed, 122 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 46733d5..39af45f 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -717,6 +717,8 @@ static int drm_atomic_plane_set_property(struct drm_plane 
*plane,
 {
struct drm_device *dev = plane->dev;
struct drm_mode_config *config = >mode_config;
+   bool replaced = false;
+   int ret;
 
if (property == config->prop_fb_id) {
struct drm_framebuffer *fb = drm_framebuffer_lookup(dev, NULL, 
val);
@@ -762,6 +764,31 @@ static int drm_atomic_plane_set_property(struct drm_plane 
*plane,
} else if (plane->funcs->atomic_set_property) {
return plane->funcs->atomic_set_property(plane, state,
property, val);
+   }
+   if (property == config->degamma_lut_property) {
+   ret = drm_atomic_replace_property_blob_from_id(dev,
+   >degamma_lut,
+   val,
+   -1,
+   );
+   state->color_mgmt_changed |= replaced;
+   return ret;
+   } else if (property == config->ctm_property) {
+   ret = drm_atomic_replace_property_blob_from_id(dev,
+   >ctm,
+   val,
+   sizeof(struct drm_color_ctm),
+   );
+   state->color_mgmt_changed |= replaced;
+   return ret;
+   } else if (property == config->gamma_lut_property) {
+   ret = drm_atomic_replace_property_blob_from_id(dev,
+   >gamma_lut,
+   val,
+   -1,
+   );
+   state->color_mgmt_changed |= replaced;
+   return ret;
} else {
return -EINVAL;
}
@@ -814,6 +841,12 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
*val = state->src_w;
} else if (property == config->prop_src_h) {
*val = state->src_h;
+   } else if (property == config->degamma_lut_property) {
+   *val = (state->degamma_lut) ? state->degamma_lut->base.id : 0;
+   } else if (property == config->ctm_property) {
+   *val = (state->ctm) ? state->ctm->base.id : 0;
+   } else if (property == config->gamma_lut_property) {
+   *val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
} else if (property == plane->rotation_property) {
*val = state->rotation;
} else if (property == plane->zpos_property) {
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index ae3cbfe..1995b49 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3501,6 +3501,12 @@ void __drm_atomic_helper_plane_duplicate_state(struct 
drm_plane *plane,
 
if (state->fb)
drm_framebuffer_get(state->fb);
+   if (state->degamma_lut)
+   drm_property_reference_blob(state->degamma_lut);
+   if (state->ctm)
+   drm_property_reference_blob(state->ctm);
+   if (state->gamma_lut)
+   drm_property_reference_blob(state->gamma_lut);
 
state->fence = NULL;
state->commit = NULL;
@@ -3548,6 +3554,9 @@ void __drm_atomic_helper_plane_destroy_state(struct 
drm_plane_state *state)
 
if (state->commit)
drm_crtc_commit_put(state->commit);
+   drm_property_unreference_blob(state->degamma_lut);
+   drm_property_unreference_blob(state->ctm);
+   drm_property_unreference_blob(state->gamma_lut);
 }
 EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
 
diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index 0d002b0..e0871ce 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -90,6 +90,61 @@
  * "GAMMA_LUT" property above.
  */
 
+static void 

[RFC 0/1] Color space conversion uapi part2

[Alexandru Gheorghe]

This is an attempt to revive the color space conversation that started
here [1] and was materialized with the color encoding and color range
properties for converting YUV2RGB, the last version of this patch
series is here [2].

However, we still need a way of specifing the color gamut and transfer
function(gamma) for a given plane, in order to be sure that the
blending is done in the same domain space, which is not an issue for
similar gammuts, but not so good when mixing wider gamuts like Rec2020
and DCI-P3 with narrow ones.

In consequence, the userspace needs to control what is the color gamut
used for blending.

On Mali DP hardware, a complete color processing pipeline for a plane
looks like this:

YUV2RGB -> DEGAMA -> RGB2RGB(Gammut conv) -> GAMMA.

Of course, depending on hardware generation some of this elements are
not present or disabled if we are dealing with a RGB buffer already
in linear space. But it's up to the usperspace to decide what it wants
when the hardware doesn't provide full support for its needs.

What this patchset proposes is to add plane degamma, ctm and gamma
properties to be applied in this order after the yuv2rgb conversion
specified by the color encoding property[2]. We already have this sort
of pipeline(degamma, ctm, gamma) at the other end of a CRTC, so it
wouldn't be a totaly new interface for userspaces to figure it out how
to use.

There are still some things to be done before getting this patchset in
mergeable shape like: mali-dp driver implementation, real userspace
(drm_hwcomposer is the likely candidate here, but I'm open to
suggestions here), reuse some of the code for both crtc and plane.

But first, I would like to see what everybody things about this idea,
or if it has a different perspective of how this should be handled.

[1] https://lkml.org/lkml/2017/3/16/681
[2] https://www.spinics.net/lists/intel-gfx/msg156211.html

Mihail Atanassov (1):
  drm: Add per-plane color management

 drivers/gpu/drm/drm_atomic.c| 28 ++
 drivers/gpu/drm/drm_atomic_helper.c |  9 +
 drivers/gpu/drm/drm_color_mgmt.c| 76 +++--
 include/drm/drm_color_mgmt.h|  5 +++
 include/drm/drm_mode_config.h   | 20 +-
 include/drm/drm_plane.h |  8 
 6 files changed, 117 insertions(+), 29 deletions(-)

-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 8/9] drm: Add aspect ratio parsing in DRM layer

[Ville Syrjälä]

On Mon, Feb 26, 2018 at 09:18:57PM +0530, Nautiyal, Ankit K wrote:
> 
> 
> On 2/23/2018 8:24 PM, Ville Syrjälä wrote:
> > On Thu, Feb 15, 2018 at 05:51:01PM +0530, Nautiyal, Ankit K wrote:
> >> From: "Sharma, Shashank" 
> >>
> >> Current DRM layer functions don't parse aspect ratio information
> >> while converting a user mode->kernel mode or vice versa. This
> >> causes modeset to pick mode with wrong aspect ratio, eventually
> >> causing failures in HDMI compliance test cases, due to wrong VIC.
> >>
> >> This patch adds aspect ratio information in DRM's mode conversion
> >> and mode comparision functions, to make sure kernel picks mode
> >> with right aspect ratio (as per the VIC).
> >>
> >> Background:
> >> This patch was once reviewed and merged, and later reverted due to
> >> lack of DRM cap protection. This is a re-spin of this patch, this
> >> time with DRM cap protection, to avoid aspect ratio information, when
> >> the client doesn't request for it.
> >>
> >> Review link: https://pw-emeril.freedesktop.org/patch/104068/
> >> Background discussion: https://patchwork.kernel.org/patch/9379057/
> >>
> >> Signed-off-by: Shashank Sharma 
> >> Signed-off-by: Lin, Jia 
> >> Signed-off-by: Akashdeep Sharma 
> >> Reviewed-by: Jim Bride  (V2)
> >> Reviewed-by: Jose Abreu  (V4)
> >>
> >> Cc: Ville Syrjala 
> >> Cc: Jim Bride 
> >> Cc: Jose Abreu 
> >> Cc: Ankit Nautiyal 
> >>
> >> V3: modified the aspect-ratio check in drm_mode_equal as per new flags
> >>  provided by Ville. https://patchwork.freedesktop.org/patch/188043/
> >> V4: rebase
> >> V5: rebase
> >> ---
> >>   drivers/gpu/drm/drm_modes.c | 33 -
> >>   1 file changed, 32 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> >> index ca4c5cc..25140b9 100644
> >> --- a/drivers/gpu/drm/drm_modes.c
> >> +++ b/drivers/gpu/drm/drm_modes.c
> >> @@ -1050,7 +1050,8 @@ bool drm_mode_equal(const struct drm_display_mode 
> >> *mode1,
> >>  DRM_MODE_MATCH_TIMINGS |
> >>  DRM_MODE_MATCH_CLOCK |
> >>  DRM_MODE_MATCH_FLAGS |
> >> -DRM_MODE_MATCH_3D_FLAGS);
> >> +DRM_MODE_MATCH_3D_FLAGS|
> >> +DRM_MODE_MATCH_ASPECT_RATIO);
> > Hmm. I wonder if all the users are expecting this. Based on a cursory
> > examination drm_fb_helper might want to ignore the aspect ratio since
> > it's just looking to clone the same mode on multiple outputs. The other
> > cases don't look to me like they should suffer badly from this.
> 
> Agreed.
> Need to add a function drm_mode_equal_no_aspect_ratio() in drm_modes.c 
> which will compare
> every field, other than the aspect-ratio.
> Next, in the drm_target_cloned( ), where same modes are to be cloned on 
> multiple outputs, instead
> of drm_mode_equal( ), drm_mode_equal_no_aspect_ratio( ) must be called.
> 
> Is this approach correct?

Please no more drm_mode_equal_no_whatever(). We should nuke the current
ones. If we think the no_whatever pattern is useful we should probably
add something like drm_mode_match_except() which takes the set of flags
we're going to ignore. Not 100% convinced it's a good pattern to follow
though. Just stating explicitly what we want to match seems generally
better to me.

> 
> >
> >>   }
> >>   EXPORT_SYMBOL(drm_mode_equal);
> >>   
> >> @@ -1649,6 +1650,21 @@ void drm_mode_convert_to_umode(struct 
> >> drm_mode_modeinfo *out,
> >>out->vrefresh = in->vrefresh;
> >>out->flags = in->flags;
> >>out->type = in->type;
> >> +  out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
> > This looks redundant. The internal mode should not have the aspect ratio
> > flags set. Or are we changing that?
> 
> Yes right, the aspect-ratio flags are never set in the internal-mode flags.
> This line can be dropped.
> 
> >
> >> +
> >> +  switch (in->picture_aspect_ratio) {
> >> +  case HDMI_PICTURE_ASPECT_4_3:
> >> +  out->flags |= DRM_MODE_FLAG_PIC_AR_4_3;
> >> +  break;
> >> +  case HDMI_PICTURE_ASPECT_16_9:
> >> +  out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
> >> +  break;
> >> +  case HDMI_PICTURE_ASPECT_RESERVED:
> >> +  default:
> >> +  out->flags |= DRM_MODE_FLAG_PIC_AR_NONE;
> >> +  break;
> >> +  }
> >> +
> >>strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
> >>out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
> >>   }
> >> @@ -1693,6 +1709,21 @@ int drm_mode_convert_umode(struct drm_device *dev,
> >>strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
> >>out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
> >>   
> >> +  /* Clearing picture aspect ratio bits from out flags */
> > What the 

[Bug 100919] [DC] "Out of range" on a display connected to a DVI-D output of RX460 card via DVI-D<=>HDMI-A cable

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100919

--- Comment #15 from Harry Wentland  ---
Please open a separate ticket for the issue with amd-stg and the 2nd monitor,
including
* dmesg log with amdgpu.dc_log=1 and drm.debug=0x6 kernel options
* model of both monitors and how they're connected (DP, HDMI, etc... any
adapter)
* commit from amd-staging-drm-next being tested

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 8/9] drm: Add aspect ratio parsing in DRM layer

[Nautiyal, Ankit K]

On 2/23/2018 8:24 PM, Ville Syrjälä wrote:

On Thu, Feb 15, 2018 at 05:51:01PM +0530, Nautiyal, Ankit K wrote:

From: "Sharma, Shashank" 

Current DRM layer functions don't parse aspect ratio information
while converting a user mode->kernel mode or vice versa. This
causes modeset to pick mode with wrong aspect ratio, eventually
causing failures in HDMI compliance test cases, due to wrong VIC.

This patch adds aspect ratio information in DRM's mode conversion
and mode comparision functions, to make sure kernel picks mode
with right aspect ratio (as per the VIC).

Background:
This patch was once reviewed and merged, and later reverted due to
lack of DRM cap protection. This is a re-spin of this patch, this
time with DRM cap protection, to avoid aspect ratio information, when
the client doesn't request for it.

Review link: https://pw-emeril.freedesktop.org/patch/104068/
Background discussion: https://patchwork.kernel.org/patch/9379057/

Signed-off-by: Shashank Sharma 
Signed-off-by: Lin, Jia 
Signed-off-by: Akashdeep Sharma 
Reviewed-by: Jim Bride  (V2)
Reviewed-by: Jose Abreu  (V4)

Cc: Ville Syrjala 
Cc: Jim Bride 
Cc: Jose Abreu 
Cc: Ankit Nautiyal 

V3: modified the aspect-ratio check in drm_mode_equal as per new flags
 provided by Ville. https://patchwork.freedesktop.org/patch/188043/
V4: rebase
V5: rebase
---
  drivers/gpu/drm/drm_modes.c | 33 -
  1 file changed, 32 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index ca4c5cc..25140b9 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1050,7 +1050,8 @@ bool drm_mode_equal(const struct drm_display_mode *mode1,
  DRM_MODE_MATCH_TIMINGS |
  DRM_MODE_MATCH_CLOCK |
  DRM_MODE_MATCH_FLAGS |
- DRM_MODE_MATCH_3D_FLAGS);
+ DRM_MODE_MATCH_3D_FLAGS|
+ DRM_MODE_MATCH_ASPECT_RATIO);

Hmm. I wonder if all the users are expecting this. Based on a cursory
examination drm_fb_helper might want to ignore the aspect ratio since
it's just looking to clone the same mode on multiple outputs. The other
cases don't look to me like they should suffer badly from this.


Agreed.
Need to add a function drm_mode_equal_no_aspect_ratio() in drm_modes.c 
which will compare

every field, other than the aspect-ratio.
Next, in the drm_target_cloned( ), where same modes are to be cloned on 
multiple outputs, instead

of drm_mode_equal( ), drm_mode_equal_no_aspect_ratio( ) must be called.

Is this approach correct?




  }
  EXPORT_SYMBOL(drm_mode_equal);
  
@@ -1649,6 +1650,21 @@ void drm_mode_convert_to_umode(struct drm_mode_modeinfo *out,

out->vrefresh = in->vrefresh;
out->flags = in->flags;
out->type = in->type;
+   out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;

This looks redundant. The internal mode should not have the aspect ratio
flags set. Or are we changing that?


Yes right, the aspect-ratio flags are never set in the internal-mode flags.
This line can be dropped.




+
+   switch (in->picture_aspect_ratio) {
+   case HDMI_PICTURE_ASPECT_4_3:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_4_3;
+   break;
+   case HDMI_PICTURE_ASPECT_16_9:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
+   break;
+   case HDMI_PICTURE_ASPECT_RESERVED:
+   default:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_NONE;
+   break;
+   }
+
strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
  }
@@ -1693,6 +1709,21 @@ int drm_mode_convert_umode(struct drm_device *dev,
strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
  
+	/* Clearing picture aspect ratio bits from out flags */

What the code is doing is obvious so this comment is redundant.
The non-obvious part (ie. the "why?") is what the comment
should contain.


Thanks for pointing that out, will take care of this in future patches.

Regards,
Ankit




+   out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
+
+   switch (in->flags & DRM_MODE_FLAG_PIC_AR_MASK) {
+   case DRM_MODE_FLAG_PIC_AR_4_3:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_4_3;
+   break;
+   case DRM_MODE_FLAG_PIC_AR_16_9:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
+   break;
+   default:
+   out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
+   break;
+   }
+
out->status = drm_mode_validate_driver(dev, 

[Bug 100919] [DC] "Out of range" on a display connected to a DVI-D output of RX460 card via DVI-D<=>HDMI-A cable

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100919

--- Comment #14 from Thomas R.  ---
Harry, I tried amd-staging-drm-next and there is no corruption on the primary,
but my second monitor is dead. It may be something like bug #91202 or something
else entirely, the dmesg output is very sparse (egrep drm|amd below).

What can I do now?

[0.583791] [drm] amdgpu kernel modesetting enabled.
[0.583968] [drm] initializing kernel modesetting (TONGA 0x1002:0x6939
0x1043:0x0486 0x00).
[0.584028] [drm] register mmio base: 0xFE98
[0.584071] [drm] register mmio size: 262144
[0.584109] [drm] add ip block number 0 
[0.584140] [drm] add ip block number 1 
[0.584172] [drm] add ip block number 2 
[0.584207] [drm] add ip block number 3 
[0.584239] [drm] add ip block number 4 
[0.584271] [drm] add ip block number 5 
[0.584303] [drm] add ip block number 6 
[0.584334] [drm] add ip block number 7 
[0.584367] [drm] add ip block number 8 
[0.584402] [drm] probing gen 2 caps for device 1002:5a16 = 31cd02/0
[0.584434] [drm] probing mlw for device 1002:5a16 = 31cd02
[0.584472] [drm] VCE enabled in physical mode
[0.584775] amdgpu :05:00.0: Invalid PCI ROM header signature: expecting
0xaa55, got 0xb60f
[0.585447] [drm] vm size is 64 GB, 2 levels, block size is 10-bit, fragment
size is 9-bit
[0.585490] amdgpu :05:00.0: VRAM: 2048M 0x00F4 -
0x00F47FFF (2048M used)
[0.585526] amdgpu :05:00.0: GTT: 1024M 0x -
0x3FFF
[0.585563] [drm] Detected VRAM RAM=2048M, BAR=256M
[0.585594] [drm] RAM width 256bits GDDR5
[0.585843] [drm] amdgpu: 2048M of VRAM memory ready
[0.585874] [drm] amdgpu: 3072M of GTT memory ready.
[0.585907] [drm] GART: num cpu pages 262144, num gpu pages 262144
[0.586405] [drm] PCIE GART of 1024M enabled (table at 0x00F40004).
[0.587618] [drm] Found UVD firmware Version: 1.65 Family ID: 10
[0.588927] [drm] Found VCE firmware Version: 52.8 Binary ID: 3
[0.638265] [drm] Display Core initialized with v3.1.34!
[0.651084] [drm] SADs count is: -2, don't need to read it
[0.663759] [drm] SADs count is: -2, don't need to read it
[0.663823] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[0.663879] [drm] Driver supports precise vblank timestamp query.
[0.712563] [drm] UVD initialized successfully.
[0.921688] [drm] VCE initialized successfully.
[0.925673] [drm] fb mappable at 0xD0566000
[0.925738] [drm] vram apper at 0xD000
[0.925798] [drm] size 8294400
[0.925857] [drm] fb depth is 24
[0.925909] [drm]pitch is 7680
[0.926025] fbcon: amdgpudrmfb (fb0) is primary device
[1.123458] amdgpu :05:00.0: fb0: amdgpudrmfb frame buffer device
[1.131506] [drm] Initialized amdgpu 3.25.0 20150101 for :05:00.0 on
minor 0

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Include the header with the prototype for drm_get_panel_orientation_quirk()

[Ville Syrjälä]

On Mon, Feb 26, 2018 at 03:35:34PM +0100, Hans de Goede wrote:
> Hi,
> 
> On 26-02-18 15:24, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> > 
> > sparse complains:
> > drivers/gpu/drm/drm_panel_orientation_quirks.c:133:5: warning: symbol 
> > 'drm_get_panel_orientation_quirk' was not declared. Should it be static?
> > 
> > Cc: Hans de Goede 
> > Cc: Daniel Vetter 
> > Signed-off-by: Ville Syrjälä 
> 
> Good catch:
> 
> Reviewed-by: Hans de Goede 

Thanks. Pushed to drm-misc-next.

> 
> Regards,
> 
> Hans
> 
> > ---
> >   drivers/gpu/drm/drm_panel_orientation_quirks.c | 1 +
> >   1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c 
> > b/drivers/gpu/drm/drm_panel_orientation_quirks.c
> > index 1f2af707ce03..902cc1a71e45 100644
> > --- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
> > +++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
> > @@ -11,6 +11,7 @@
> >   #include 
> >   #include 
> >   #include 
> > +#include 
> >   
> >   #ifdef CONFIG_DMI
> >   
> > 

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 4/4] drm/msm/mdp5: writeback support

[Sean Paul]

On Fri, Feb 23, 2018 at 01:15:54PM -0500, Rob Clark wrote:
> On Fri, Feb 23, 2018 at 11:30 AM, Sean Paul  wrote:
> > On Fri, Feb 23, 2018 at 08:17:54AM -0500, Rob Clark wrote:
> >> In a way, based on the original writeback patch from Jilai Wang, but a
> >> lot has shifted around since then.
> >>
> >> Signed-off-by: Rob Clark 
> >> ---
> >>  drivers/gpu/drm/msm/Makefile  |   1 +
> >>  drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c |  23 +-
> >>  drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c  |  38 +++-
> >>  drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.h  |   7 +-
> >>  drivers/gpu/drm/msm/disp/mdp5/mdp5_wb.c   | 367 
> >> ++
> >>  drivers/gpu/drm/msm/dsi/dsi_host.c|   4 +-
> >>  6 files changed, 431 insertions(+), 9 deletions(-)
> >>  create mode 100644 drivers/gpu/drm/msm/disp/mdp5/mdp5_wb.c
> >>
> >> diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
> >> index cd40c050b2d7..c9f50adef2db 100644
> >> --- a/drivers/gpu/drm/msm/Makefile
> >> +++ b/drivers/gpu/drm/msm/Makefile
> >> @@ -45,6 +45,7 @@ msm-y := \
> >>   disp/mdp5/mdp5_mixer.o \
> >>   disp/mdp5/mdp5_plane.o \
> >>   disp/mdp5/mdp5_smp.o \
> >> + disp/mdp5/mdp5_wb.o \
> >>   msm_atomic.o \
> >>   msm_debugfs.o \
> >>   msm_drv.o \
> >> diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c 
> >> b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
> >> index 9893e43ba6c5..b00ca88b741d 100644
> >> --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
> >> +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
> >> @@ -484,7 +484,11 @@ static void mdp5_crtc_atomic_enable(struct drm_crtc 
> >> *crtc,
> >>   }
> >>
> >>   /* Restore vblank irq handling after power is enabled */
> >> - drm_crtc_vblank_on(crtc);
> >> +// TODO we can't ->get_scanout_pos() for wb (since virtual intf)..
> >> +// perhaps drm core should be clever enough not to 
> >> drm_reset_vblank_timestamp()
> >> +// for virtual encoders / writeback?
> >> + if (mdp5_cstate->pipeline.intf->type != INTF_WB)
> >> + drm_crtc_vblank_on(crtc);
> >>
> >>   mdp5_crtc_mode_set_nofb(crtc);
> >>
> >> @@ -518,7 +522,11 @@ int mdp5_crtc_setup_pipeline(struct drm_crtc *crtc,
> >>   u32 caps;
> >>   int ret;
> >>
> >> - caps = MDP_LM_CAP_DISPLAY;
> >> + if (pipeline->intf->type == INTF_WB)
> >> + caps = MDP_LM_CAP_WB;
> >> + else
> >> + caps = MDP_LM_CAP_DISPLAY;
> >> +
> >>   if (need_right_mixer)
> >>   caps |= MDP_LM_CAP_PAIR;
> >>
> >> @@ -545,6 +553,7 @@ int mdp5_crtc_setup_pipeline(struct drm_crtc *crtc,
> >>   mdp5_cstate->err_irqmask = intf2err(intf->num);
> >>   mdp5_cstate->vblank_irqmask = intf2vblank(pipeline->mixer, intf);
> >>
> >> +// XXX should we be treating WB as cmd_mode??
> >>   if ((intf->type == INTF_DSI) &&
> >>   (intf->mode == MDP5_INTF_DSI_MODE_COMMAND)) {
> >>   mdp5_cstate->pp_done_irqmask = lm2ppdone(pipeline->mixer);
> >> @@ -639,8 +648,12 @@ static int mdp5_crtc_atomic_check(struct drm_crtc 
> >> *crtc,
> >>   }
> >>
> >>   /* bail out early if there aren't any planes */
> >> - if (!cnt)
> >> - return 0;
> >> + if (!cnt) {
> >> + if (!state->active)
> >> + return 0;
> >> + dev_err(dev->dev, "%s has no planes!\n", crtc->name);
> >> + return -EINVAL;
> >> + }
> >
> > This seems unrelated?
> >
> 
> hmm, yeah, kinda.  It was a case that I hit before working out all the
> bugs in my kmscube writeback mode, but I guess isn't directly related
> to wb.
> 
> >>
> >>   hw_cfg = mdp5_cfg_get_hw_config(mdp5_kms->cfg);
> >>
> >> @@ -1160,7 +1173,7 @@ void mdp5_crtc_wait_for_commit_done(struct drm_crtc 
> >> *crtc)
> >>
> >>   if (mdp5_cstate->cmd_mode)
> >>   mdp5_crtc_wait_for_pp_done(crtc);
> >> - else
> >> + else if (mdp5_cstate->pipeline.intf->type != INTF_WB)
> >>   mdp5_crtc_wait_for_flush_done(crtc);
> >>  }
> >>
> >> diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c 
> >> b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> >> index 1f44d8f15ce1..239010905637 100644
> >> --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> >> +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> >> @@ -427,7 +427,8 @@ static int modeset_init(struct mdp5_kms *mdp5_kms)
> >>* the MDP5 interfaces) than the number of layer mixers present in 
> >> HW,
> >>* but let's be safe here anyway
> >>*/
> >> - num_crtcs = min(priv->num_encoders, mdp5_kms->num_hwmixers);
> >> + num_crtcs = min(priv->num_encoders + hw_cfg->wb.count,
> >> + mdp5_kms->num_hwmixers);
> >>
> >>   /*
> >>* Construct planes equaling the number of hw pipes, and CRTCs for 
> >> the
> >> @@ -482,6 +483,33 @@ static int modeset_init(struct mdp5_kms *mdp5_kms)
> >> 

Re: [PATCH v5 7/9] drm: Expose modes with aspect ratio, only if requested

[Nautiyal, Ankit K]

On 2/23/2018 8:06 PM, Ville Syrjälä wrote:

On Thu, Feb 15, 2018 at 05:51:00PM +0530, Nautiyal, Ankit K wrote:

From: Ankit Nautiyal 

We parse the EDID and add all the modes in the connector's modelist.
This adds CEA modes with aspect ratio information too, regadless of
whether user space requested this information or not.

This patch prunes the modes with aspect-ratio information, from a
connector's modelist, if the user-space has not set the aspect ratio
DRM client cap.

Cc: Ville Syrjala 
Cc: Shashank Sharma 
Cc: Jose Abreu 

Signed-off-by: Ankit Nautiyal 

V3: As suggested by Ville, modified the mechanism of pruning of modes
 with aspect-ratio, if the aspect-ratio is not supported. Instead
 of straight away pruning such a mode, the mode is retained with
 aspect ratio bits set to zero, provided it is unique.
V4: rebase
V5: Addressed review comments from Ville:
 -used a pointer to store last valid mode.
 -avoided, modifying of picture_aspect_ratio in kernel mode,
  instead only flags bits of user mode are reset (if aspect-ratio
  is not supported).
---
  drivers/gpu/drm/drm_connector.c | 45 -
  1 file changed, 40 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 16b9c38..49778e8 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1507,8 +1507,10 @@ static struct drm_encoder 
*drm_connector_get_encoder(struct drm_connector *conne
return connector->encoder;
  }
  
-static bool drm_mode_expose_to_userspace(const struct drm_display_mode *mode,

-const struct drm_file *file_priv)
+static bool
+drm_mode_expose_to_userspace(const struct drm_display_mode *last_mode,
+const struct drm_display_mode *mode,

I would put the 'mode' argument first since that's the "main" object
we're operating on.
Yes that makes more sense. Will make the mode as first argument in the 
next revision.





+const struct drm_file *file_priv)
  {
/*
 * If user-space hasn't configured the driver to expose the stereo 3D
@@ -1516,6 +1518,23 @@ static bool drm_mode_expose_to_userspace(const struct 
drm_display_mode *mode,
 */
if (!file_priv->stereo_allowed && drm_mode_is_stereo(mode))
return false;
+   /*
+* If user-space hasn't configured the driver to expose the modes
+* with aspect-ratio, don't expose them. But in case of a unique
+* mode, let the mode be passed, so that it can be enumerated with
+* aspect ratio bits erased.

Might want to note that we expect the list to be sorted such that modes
that have different aspect ratio but are otherwise identical are back to
back.


Indeed. The whole idea, is based on the fact that the list of modes are 
sorted.

Will put a note here.


+*/
+   if (!file_priv->aspect_ratio_allowed &&
+   mode->picture_aspect_ratio != HDMI_PICTURE_ASPECT_NONE) {
+   if (last_mode && !drm_mode_match(mode, last_mode,
+DRM_MODE_MATCH_TIMINGS |
+DRM_MODE_MATCH_CLOCK |
+DRM_MODE_MATCH_FLAGS |
+DRM_MODE_MATCH_3D_FLAGS))
+   return true;
+   else
+   return false;

How does that even work? It'll return false as long as
last_mode==NULL, and last_mode never becomes non-NULL unless
we return true.

To me it looks like the correct logic would be:
if (last_mode && drm_mode_match(...))
return false;


This is a mistake, thanks for pointing it out.

While testing with aspect-ratio cap not set, for all the available 
displays, the first mode in the list,
never had a mode with aspect ratio. (or in other words, first mode was 
always with aspect ratio NONE)
This resulted in early exit from the condition and returning true, 
making last_mode as the first mode.


Long story short, couldn't catch the problem while testing as first mode 
was always with aspect ratio NONE :)


Your suggested code is indeed the correct logic, which I intended.


+   }
  
  	return true;

  }
@@ -1527,6 +1546,7 @@ int drm_mode_getconnector(struct drm_device *dev, void 
*data,
struct drm_connector *connector;
struct drm_encoder *encoder;
struct drm_display_mode *mode;
+   struct drm_display_mode *last_valid_mode;
int mode_count = 0;
int encoders_count = 0;
int ret = 0;
@@ -1582,9 +1602,13 @@ int drm_mode_getconnector(struct drm_device *dev, void 
*data,
out_resp->connection = connector->status;
  
  	/* delayed so we get 

[Bug 105039] No 120hz with 4.15 kernel and DC enabled

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105039

--- Comment #3 from Harry Wentland  ---
This should be fixed in our staging branches.

Can you try either the amd-staging-drm-next or drm-next-4.17-wip branch from
Alex's repo. You can find it at
https://cgit.freedesktop.org/~agd5f/linux/?h=amd-staging-drm-next

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 4/6] arm64: dts: exynos: add OF graph between MHL and USB connector

[Krzysztof Kozlowski]

On Wed, Feb 21, 2018 at 9:55 AM, Andrzej Hajda  wrote:
> OF graph describes MHL data lanes between MHL and respective USB
> connector.
>
> Signed-off-by: Andrzej Hajda 
> ---
> v4:
> - added missing reg property in connector's port node (Krzysztof)
> ---
>  .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 32 
> --
>  1 file changed, 29 insertions(+), 3 deletions(-)

You have a duplicated '};' so kbuild complains so I assume there will
be next iteration of this. Beside that I am okay with both, so I will
take next version when your bindings and driver changes get
acked/accepted.

Best Regards,
Krzysztof
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105163] *-symbol-checks hard-code the nm executable

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105163

Eric Engestrom  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Eric Engestrom  ---
Fixed as of:

commit 4f08bfe96da1542f336589edf310d06ebce3cf20
Author: Heiko Becker 
Date:   Mon Feb 19 15:13:15 2018 +

*-symbol-check: Don't hard-code nm executable

Helpful if your nm executable has a prefix based on the
architecture, for example.

Signed-off-by: Heiko Becker 
Cc: Timo Gurr 
[Eric: v2: rebase and add Meson support]
Signed-off-by: Eric Engestrom 
Reviewed-by: Eric Anholt 
Reviewed-by: Emil Velikov 

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 6/9] drm: Handle aspect ratio info in legacy and atomic modeset paths

[Nautiyal, Ankit K]

Hi Ville,

I agree to all the comments here, and will correct the required things 
in the next patch-set.


On 2/23/2018 7:58 PM, Ville Syrjälä wrote:

On Thu, Feb 15, 2018 at 05:50:59PM +0530, Nautiyal, Ankit K wrote:

From: Ankit Nautiyal 

If the user-space does not support aspect-ratio, and requests for a
modeset with mode having aspect ratio bits set, then the given
user-mode must be rejected. Secondly, while preparing a user-mode from
kernel mode, the aspect-ratio info must not be given, if aspect-ratio
is not supported by the user.

This patch:
1. passes the file_priv structure from the drm_mode_atomic_ioctl till
the drm_mode_crtc_set_mode_prop, to get the user capability.
2. rejects the modes with aspect-ratio info, during modeset, if the
user does not support aspect ratio.
3. does not load the aspect-ratio info in user-mode structure, if
aspect ratio is not supported.

Signed-off-by: Ankit Nautiyal 

V3: Addressed review comments from Ville:
 Do not corrupt the current crtc state by updating aspect ratio on
 the fly.
V4: rebase
V5: As suggested by Ville, rejected the modeset calls for modes with
 aspect ratio, if the user does not set aspect ratio cap.
---
  drivers/gpu/drm/drm_atomic.c| 30 ++
  drivers/gpu/drm/drm_atomic_helper.c |  6 +++---
  drivers/gpu/drm/drm_crtc.c  | 15 +++
  drivers/gpu/drm/drm_crtc_internal.h |  3 ++-
  drivers/gpu/drm/drm_mode_object.c   |  9 ++---
  drivers/gpu/drm/drm_modes.c |  1 +
  include/drm/drm_atomic.h|  5 +++--
  7 files changed, 52 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 86b483e..7e78305 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -368,6 +368,7 @@ EXPORT_SYMBOL(drm_atomic_set_mode_for_crtc);
   * drm_atomic_set_mode_prop_for_crtc - set mode for CRTC
   * @state: the CRTC whose incoming state to update
   * @blob: pointer to blob property to use for mode
+ * @file_priv: file priv structure, to get the userspace capabilities
   *
   * Set a mode (originating from a blob property) on the desired CRTC state.
   * This function will take a reference on the blob property for the CRTC 
state,
@@ -378,7 +379,8 @@ EXPORT_SYMBOL(drm_atomic_set_mode_for_crtc);
   * Zero on success, error code on failure. Cannot return -EDEADLK.
   */
  int drm_atomic_set_mode_prop_for_crtc(struct drm_crtc_state *state,
-  struct drm_property_blob *blob)
+ struct drm_property_blob *blob,
+ struct drm_file *file_priv)
  {
if (blob == state->mode_blob)
return 0;
@@ -389,10 +391,20 @@ int drm_atomic_set_mode_prop_for_crtc(struct 
drm_crtc_state *state,
memset(>mode, 0, sizeof(state->mode));
  
  	if (blob) {

+   struct drm_mode_modeinfo *u_mode;
+
+   u_mode = (struct drm_mode_modeinfo *) blob->data;
+   if (!file_priv->aspect_ratio_allowed &&
+   (u_mode->flags & DRM_MODE_FLAG_PIC_AR_MASK) !=
+   DRM_MODE_FLAG_PIC_AR_NONE) {
+   DRM_DEBUG_ATOMIC("Unexpected aspect-ratio flag bits\n");
+   return -EINVAL;
+   }

We should probably pull this logic into a small helper so that we don't
have to duplicate it in both the setprop and setcrtc code paths.


Agreed. I would add the required helper function, in the next patch-set.




+
if (blob->length != sizeof(struct drm_mode_modeinfo) ||

The blob length check has to be done before you access the data.


Right. Will take care in the next patch-set.


drm_mode_convert_umode(state->crtc->dev, >mode,
-  (const struct drm_mode_modeinfo *)
-   blob->data))
+  (const struct drm_mode_modeinfo *)
+  u_mode))
return -EINVAL;
  
  		state->mode_blob = drm_property_blob_get(blob);

@@ -441,6 +453,7 @@ drm_atomic_replace_property_blob_from_id(struct drm_device 
*dev,
   * @state: the state object to update with the new property value
   * @property: the property to set
   * @val: the new property value
+ * @file_priv: the file private structure, to get the user capabilities
   *
   * This function handles generic/core properties and calls out to driver's
   * _crtc_funcs.atomic_set_property for driver properties. To ensure
@@ -452,7 +465,7 @@ drm_atomic_replace_property_blob_from_id(struct drm_device 
*dev,
   */
  int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
struct drm_crtc_state *state, struct drm_property *property,
-   uint64_t val)
+   uint64_t val, struct drm_file