Re: [PATCH v3 5/6] dt-bindings: add the rockchip, dual-channel for dw-mipi-dsi

[Archit Taneja]

On 12/05/2017 06:49 AM, Brian Norris wrote:

Hi Archit,

I'm a relative n00b here, but I'm trying to follow along and I have some
questions:

On Fri, Dec 01, 2017 at 06:29:04PM +0530, Archit Taneja wrote:

On 11/30/2017 11:02 PM, Nickey Yang wrote:

I try to follow as you suggested,use

mipi_dsi: mipi@ff96 {
     ...
     ...
     clock-master;    /* implies that this DSI instance drivers the clock
              * for both the DSIs.
              */
     ports {
         mipi_in: port {
             ...
             ...
         };
         /* add extra output ports for both DSIs */
         mipi_out: port {
             mipi_panel_out: endpoint {
                 remote-endpoint = <_in_channel0>;
             };
         };
     };
     panel {
         ...
         ...
         /*
          * panel node can describe its input ports, if both the DSIs output
          * ports are connected to the same device (i.e, the same DSI panel),
          * we can assume that the DSIs need to operate in dual DSI mode
          */
         ports {
             ...
             port@0 {
                 panel_in_channel0: endpoint {
                     remote-endpoint = <_panel_out>;
                 };
             };
             port@1 {
                 panel_in_channel1: endpoint {
                     remote-endpoint = <_panel_out>;
                 };

             };
         };
     };
};

mipi_dsi1: mipi@ff968000 {
     ...
     ...
     ports {
         mipi1_in: port {
             ...
             ...
         };
         mipi1_out: port {
             mipi1_panel_out: endpoint {
                 remote-endpoint = <_in_channel1>;
             };
         };
     };
}

But it seems we can not use of_drm_find_panel(like below)

/*
     port = of_graph_get_port_by_id(dev->of_node, 1);
     if (port) {
     endpoint = of_get_child_by_name(port, "endpoint");
     of_node_put(port);
     if (!endpoint) {
     dev_err(dev, "no output endpoint found\n");
     return -EINVAL;
     }
     panel_node = of_graph_get_remote_port_parent(endpoint);
     of_node_put(endpoint);
     if (!panel_node) {
     dev_err(dev, "no output node found\n");
     return -EINVAL;
     }
     panel = of_drm_find_panel(panel_node);
     of_node_put(panel_node);
     if (!panel)
     return -EPROBE_DEFER;
     }
*/
to get DSI1 outputs,because of_drm_find_panel need compare

if (panel->dev->of_node == np)

in dsi_panel driver innolux->base.dev = >link->dev;
dsi->dev


Yes, we should only have 1 drm_panel in the global panel list.
Shouldn't it be possible to modify the dsi driver such that dsi1
doesn't care whether it has a drm_panel for it or not, if we are
in dual dsi mode?

I imagine a sequence like this:

1. dsi0 probes, parses the of-graph, finds the panel and saves its device
node.


Does this mean we depend on probe order? Or would we be able to
-EPROBE_DEFER or similar if dsi1 binds first?


I don't think the probe order should matter. However, I also don't know what
challenges it might bring up once we actually try to implement it. I can see
the the driver's of-graph parsing code getting a bit complicated. The first dsi
instance that probes/binds (say dsi1) should peek into the panels other ports
and see if it is the slave DSI instance in a dual DSI set-up. If so, it could
defer until DSI0 first probes and registers the panel.

Btw, full disclosure, I work on the drm/msm driver, and the code uses a binding
called "qcom,dual-dsi-mode" done by someone in the past, but thankfully it isn't
used in any dts file. I plan to remove these and use the bindings I've suggested
here.

Also, the bindings I've shared above are more a proof of concept, and based on
how dual DSI is implemented on the MSM chipsets. If the HW requires special
properties while operating in Dual DSI mode, then it might be okay to have
additional bindings. However, it seems strange to have a DT prop that says
"operate in dual DSI mode" if it can be inferred from the port connections.

I'll post a RFC explaining the bindings and copy all the people with kms drivers
that support DSI. Maybe we'd come up with a better consensus.




2. dsi1 probes, parses the of-graph, find the panel's device node
   - dsi1 checks if it is the same as the panel attached to dsi0.
   - If so, it just takes the drm_panel pointer from dsi0.
   - If not, it tries a of_drm_find_panel() on the panel's device node.


So, that all means we'd need a new variant of
drm_of_find_panel_or_bridge() for "dual" drivers like this? Or else
open-code this logic in dw-mipi-dsi.c?


Yeah. It would be nice to have these in helpers.




A dual DSI panel driver would also be a bit different. It will be a
mipi_dsi_driver with the master DSI (dsi0) as the 

[PATCH v3 8/9] drm/i915: Implement HDCP for HDMI

[Sean Paul]

This patch adds HDCP support for HDMI connectors by implementing
the intel_hdcp_shim.

Nothing too special, just a bunch of DDC reads/writes.

Changes in v2:
- Rebased on drm-intel-next
Changes in v3:
- Initialize new worker

Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/i915/i915_reg.h   |   1 +
 drivers/gpu/drm/i915/intel_ddi.c  |  50 
 drivers/gpu/drm/i915/intel_drv.h  |   2 +
 drivers/gpu/drm/i915/intel_hdmi.c | 257 ++
 4 files changed, 310 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 107e16392710..79944ab4218a 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8450,6 +8450,7 @@ enum skl_power_gate {
 #define  TRANS_DDI_EDP_INPUT_A_ONOFF   (4<<12)
 #define  TRANS_DDI_EDP_INPUT_B_ONOFF   (5<<12)
 #define  TRANS_DDI_EDP_INPUT_C_ONOFF   (6<<12)
+#define  TRANS_DDI_HDCP_SIGNALLING (1<<9)
 #define  TRANS_DDI_DP_VC_PAYLOAD_ALLOC (1<<8)
 #define  TRANS_DDI_HDMI_SCRAMBLER_CTS_ENABLE (1<<7)
 #define  TRANS_DDI_HDMI_SCRAMBLER_RESET_FREQ (1<<6)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index eff3b51872eb..a179fd9968a5 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1615,6 +1615,56 @@ void intel_ddi_disable_transcoder_func(struct 
drm_i915_private *dev_priv,
I915_WRITE(reg, val);
 }
 
+int intel_ddi_disable_hdcp_signalling(struct intel_encoder *intel_encoder)
+{
+   struct drm_device *dev = intel_encoder->base.dev;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+   enum pipe pipe = 0;
+   int ret = 0;
+   uint32_t tmp;
+
+   if (!intel_display_power_get_if_enabled(dev_priv,
+   intel_encoder->power_domain))
+   return -ENXIO;
+
+   if (!intel_encoder->get_hw_state(intel_encoder, )) {
+   ret = -EIO;
+   goto out;
+   }
+
+   tmp = I915_READ(TRANS_DDI_FUNC_CTL(pipe));
+   tmp &= ~TRANS_DDI_HDCP_SIGNALLING;
+   I915_WRITE(TRANS_DDI_FUNC_CTL(pipe), tmp);
+out:
+   intel_display_power_put(dev_priv, intel_encoder->power_domain);
+   return ret;
+}
+
+int intel_ddi_enable_hdcp_signalling(struct intel_encoder *intel_encoder)
+{
+   struct drm_device *dev = intel_encoder->base.dev;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+   enum pipe pipe = 0;
+   int ret = 0;
+   uint32_t tmp;
+
+   if (!intel_display_power_get_if_enabled(dev_priv,
+   intel_encoder->power_domain))
+   return -ENXIO;
+
+   if (!intel_encoder->get_hw_state(intel_encoder, )) {
+   ret = -EIO;
+   goto out;
+   }
+
+   tmp = I915_READ(TRANS_DDI_FUNC_CTL(pipe));
+   tmp |= TRANS_DDI_HDCP_SIGNALLING;
+   I915_WRITE(TRANS_DDI_FUNC_CTL(pipe), tmp);
+out:
+   intel_display_power_put(dev_priv, intel_encoder->power_domain);
+   return ret;
+}
+
 bool intel_ddi_connector_get_hw_state(struct intel_connector *intel_connector)
 {
struct drm_device *dev = intel_connector->base.dev;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 6f47a4227f5f..0b4405f3e988 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1379,6 +1379,8 @@ void intel_ddi_compute_min_voltage_level(struct 
drm_i915_private *dev_priv,
 u32 bxt_signal_levels(struct intel_dp *intel_dp);
 uint32_t ddi_signal_levels(struct intel_dp *intel_dp);
 u8 intel_ddi_dp_voltage_max(struct intel_encoder *encoder);
+int intel_ddi_enable_hdcp_signalling(struct intel_encoder *intel_encoder);
+int intel_ddi_disable_hdcp_signalling(struct intel_encoder *intel_encoder);
 
 unsigned int intel_fb_align_height(const struct drm_framebuffer *fb,
   int plane, unsigned int height);
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 9d5e72728475..17a525b9fcf9 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "intel_drv.h"
 #include 
@@ -873,6 +874,252 @@ void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi 
*hdmi, bool enable)
 adapter, enable);
 }
 
+static int intel_hdmi_hdcp_read(struct intel_digital_port *intel_dig_port,
+   unsigned int offset, void *buffer, size_t size)
+{
+   struct intel_hdmi *hdmi = _dig_port->hdmi;
+   struct drm_i915_private *dev_priv =
+   intel_dig_port->base.base.dev->dev_private;
+   struct i2c_adapter *adapter = intel_gmbus_get_adapter(dev_priv,
+ hdmi->ddc_bus);
+   int ret;
+   u8 start = offset & 0xff;
+   struct i2c_msg msgs[] = {
+ 

[PATCH v3 3/9] drm: Add Content Protection property

[Sean Paul]

This patch adds a new optional connector property to allow userspace to enable
protection over the content it is displaying. This will typically be implemented
by the driver using HDCP.

The property is a tri-state with the following values:
- OFF: Self explanatory, no content protection
- DESIRED: Userspace requests that the driver enable protection
- ENABLED: Once the driver has authenticated the link, it sets this value

The driver is responsible for downgrading ENABLED to DESIRED if the link becomes
unprotected. The driver should also maintain the desiredness of protection
across hotplug/dpms/suspend.

If this looks familiar, I posted [1] this 3 years ago. We have been using this
in ChromeOS across exynos, mediatek, and rockchip over that time.

Changes in v2:
 - Pimp kerneldoc for content_protection_property (Daniel)
 - Drop sysfs attribute
Changes in v3:
 - None

Cc: Daniel Vetter 
Signed-off-by: Sean Paul 

[1] https://lists.freedesktop.org/archives/dri-devel/2014-December/073336.html
---
 drivers/gpu/drm/drm_atomic.c|  8 +
 drivers/gpu/drm/drm_connector.c | 71 +
 drivers/gpu/drm/drm_sysfs.c |  1 +
 include/drm/drm_connector.h | 16 ++
 include/uapi/drm/drm_mode.h |  4 +++
 5 files changed, 100 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index c2da5585e201..676025d755b2 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1196,6 +1196,12 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
state->picture_aspect_ratio = val;
} else if (property == connector->scaling_mode_property) {
state->scaling_mode = val;
+   } else if (property == connector->content_protection_property) {
+   if (val == DRM_MODE_CONTENT_PROTECTION_ENABLED) {
+   DRM_DEBUG_KMS("only drivers can set CP Enabled\n");
+   return -EINVAL;
+   }
+   state->content_protection = val;
} else if (connector->funcs->atomic_set_property) {
return connector->funcs->atomic_set_property(connector,
state, property, val);
@@ -1275,6 +1281,8 @@ drm_atomic_connector_get_property(struct drm_connector 
*connector,
*val = state->picture_aspect_ratio;
} else if (property == connector->scaling_mode_property) {
*val = state->scaling_mode;
+   } else if (property == connector->content_protection_property) {
+   *val = state->content_protection;
} else if (connector->funcs->atomic_get_property) {
return connector->funcs->atomic_get_property(connector,
state, property, val);
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index f14b48e6e839..8626aa8f485e 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -698,6 +698,13 @@ static const struct drm_prop_enum_list 
drm_tv_subconnector_enum_list[] = {
 DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
 drm_tv_subconnector_enum_list)
 
+static struct drm_prop_enum_list drm_cp_enum_list[] = {
+{ DRM_MODE_CONTENT_PROTECTION_OFF, "Off" },
+{ DRM_MODE_CONTENT_PROTECTION_DESIRED, "Desired" },
+{ DRM_MODE_CONTENT_PROTECTION_ENABLED, "Enabled" },
+};
+DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
+
 /**
  * DOC: standard connector properties
  *
@@ -764,6 +771,34 @@ DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
  *  after modeset, the kernel driver may set this to "BAD" and issue a
  *  hotplug uevent. Drivers should update this value using
  *  drm_mode_connector_set_link_status_property().
+ * Content Protection:
+ * This property is used by userspace to request the kernel protect future
+ * content communicated over the link. When requested, kernel will apply
+ * the appropriate means of protection (most often HDCP), and use the
+ * property to tell userspace the protection is active.
+ *
+ * The value of this property can be one of the following:
+ *
+ * - DRM_MODE_CONTENT_PROTECTION_OFF = 0
+ * The link is not protected, content is transmitted in the clear.
+ * - DRM_MODE_CONTENT_PROTECTION_DESIRED = 1
+ * Userspace has requested content protection, but the link is not
+ * currently protected. When in this state, kernel should enable
+ * Content Protection as soon as possible.
+ * - DRM_MODE_CONTENT_PROTECTION_ENABLED = 2
+ * Userspace has requested content protection, and the link is
+ * protected. Only the driver can set the property to this value.
+ * If userspace attempts to set to ENABLED, kernel will return
+ * -EINVAL.
+ *
+ * A few guidelines:
+ *

[PATCH v3 5/9] drm/i915: Add HDCP framework + base implementation

[Sean Paul]

This patch adds the framework required to add HDCP support to intel
connectors. It implements Aksv loading from fuse, and parts 1/2/3
of the HDCP authentication scheme.

Note that without shim implementations, this does not actually implement
HDCP. That will come in subsequent patches.

Changes in v2:
- Don't open code wait_fors (Chris)
- drm_hdcp.c under MIT license (Daniel)
- Move intel_hdcp_disable() call above ddi_disable (Ram)
- Fix // comments (I wore a cone of shame for 12 hours to atone) (Daniel)
- Justify intel_hdcp_shim with comments (Daniel)
- Fixed async locking issues by adding hdcp_mutex (Daniel)
- Don't alter connector_state in enable/disable (Daniel)
Changes in v3:
- Added hdcp_mutex/hdcp_value to make async reasonable
- Added hdcp_prop_work to separate link checking & property setting
- Added new helper for atomic_check state tracking (Daniel)
- Moved enable/disable into atomic_commit with matching helpers
- Moved intel_hdcp_check_link out of all locks when called from dp
- Bumped up ksv_fifo timeout (noticed failure on one of my dongles)

Cc: Chris Wilson 
Cc: Daniel Vetter 
Cc: Ramalingam C 
Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/i915/Makefile|   1 +
 drivers/gpu/drm/i915/i915_reg.h  |  83 
 drivers/gpu/drm/i915/intel_atomic.c  |   2 +
 drivers/gpu/drm/i915/intel_display.c |  14 +
 drivers/gpu/drm/i915/intel_drv.h |  88 +
 drivers/gpu/drm/i915/intel_hdcp.c| 731 +++
 6 files changed, 919 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/intel_hdcp.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 42bc8bd4ff06..3facea4eefdb 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -107,6 +107,7 @@ i915-y += intel_audio.o \
  intel_fbc.o \
  intel_fifo_underrun.o \
  intel_frontbuffer.o \
+ intel_hdcp.o \
  intel_hotplug.o \
  intel_modes.o \
  intel_overlay.o \
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 09bf043c1c2e..2bd2cc8441d4 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8034,6 +8034,7 @@ enum {
 #define GEN9_MEM_LATENCY_LEVEL_1_5_SHIFT   8
 #define GEN9_MEM_LATENCY_LEVEL_2_6_SHIFT   16
 #define GEN9_MEM_LATENCY_LEVEL_3_7_SHIFT   24
+#define   SKL_PCODE_LOAD_HDCP_KEYS 0x5
 #define   SKL_PCODE_CDCLK_CONTROL  0x7
 #define SKL_CDCLK_PREPARE_FOR_CHANGE   0x3
 #define SKL_CDCLK_READY_FOR_CHANGE 0x1
@@ -8335,6 +8336,88 @@ enum skl_power_gate {
 #define  SKL_PW_TO_PG(pw)  ((pw) - SKL_DISP_PW_1 + SKL_PG1)
 #define  SKL_FUSE_PG_DIST_STATUS(pg)   (1 << (27 - (pg)))
 
+
+/* HDCP Key Registers */
+#define SKL_HDCP_KEY_CONF  _MMIO(0x66c00)
+#define SKL_HDCP_AKSV_SEND_TRIGGER BIT(31)
+#define  SKL_HDCP_CLEAR_KEYS_TRIGGER   BIT(30)
+#define SKL_HDCP_KEY_STATUS_MMIO(0x66c04)
+#define  SKL_HDCP_FUSE_IN_PROGRESS BIT(7)
+#define  SKL_HDCP_FUSE_ERROR   BIT(6)
+#define  SKL_HDCP_FUSE_DONEBIT(5)
+#define  SKL_HDCP_KEY_LOAD_STATUS  BIT(1)
+#define  SKL_HDCP_KEY_LOAD_DONEBIT(0)
+#define SKL_HDCP_AKSV_LO   _MMIO(0x66c10)
+#define SKL_HDCP_AKSV_HI   _MMIO(0x66c14)
+
+/* HDCP Repeater Registers */
+#define SKL_HDCP_REP_CTL   _MMIO(0x66d00)
+#define  SKL_HDCP_DDIB_REP_PRESENT BIT(30)
+#define  SKL_HDCP_DDIA_REP_PRESENT BIT(29)
+#define  SKL_HDCP_DDIC_REP_PRESENT BIT(28)
+#define  SKL_HDCP_DDID_REP_PRESENT BIT(27)
+#define  SKL_HDCP_DDIF_REP_PRESENT BIT(26)
+#define  SKL_HDCP_DDIE_REP_PRESENT BIT(25)
+#define  SKL_HDCP_DDIB_SHA1_M0 (1 << 20)
+#define  SKL_HDCP_DDIA_SHA1_M0 (2 << 20)
+#define  SKL_HDCP_DDIC_SHA1_M0 (3 << 20)
+#define  SKL_HDCP_DDID_SHA1_M0 (4 << 20)
+#define  SKL_HDCP_DDIF_SHA1_M0 (5 << 20)
+#define  SKL_HDCP_DDIE_SHA1_M0 (6 << 20) /* Bspec says 5? */
+#define  SKL_HDCP_SHA1_BUSYBIT(16)
+#define  SKL_HDCP_SHA1_READY   BIT(17)
+#define  SKL_HDCP_SHA1_COMPLETEBIT(18)
+#define  SKL_HDCP_SHA1_V_MATCH BIT(19)
+#define  SKL_HDCP_SHA1_TEXT_32 (1 << 1)
+#define  SKL_HDCP_SHA1_COMPLETE_HASH   (2 << 1)
+#define  SKL_HDCP_SHA1_TEXT_24 (4 << 1)
+#define  SKL_HDCP_SHA1_TEXT_16 (5 << 1)
+#define  SKL_HDCP_SHA1_TEXT_8  (6 << 1)
+#define  SKL_HDCP_SHA1_TEXT_0  (7 << 1)
+#define SKL_HDCP_SHA_V_PRIME_H0_MMIO(0x66d04)
+#define SKL_HDCP_SHA_V_PRIME_H1_MMIO(0x66d08)
+#define SKL_HDCP_SHA_V_PRIME_H2_MMIO(0x66d0C)
+#define SKL_HDCP_SHA_V_PRIME_H3_MMIO(0x66d10)
+#define SKL_HDCP_SHA_V_PRIME_H4_MMIO(0x66d14)
+#define 

[PATCH v3 4/9] drm: Add some HDCP related #defines

[Sean Paul]

In preparation for implementing HDCP in i915, add some HDCP related
register offsets and defines. The dpcd register offsets will go in
drm_dp_helper.h whereas the ddc offsets along with generic HDCP stuff
will get stuffed in drm_hdcp.h, which is new.

Changes in v2:
- drm_hdcp.h gets MIT license (Daniel)
Changes in v3:
 - None

Cc: Daniel Vetter 
Signed-off-by: Sean Paul 
---
 include/drm/drm_dp_helper.h | 17 ++
 include/drm/drm_hdcp.h  | 56 +
 2 files changed, 73 insertions(+)
 create mode 100644 include/drm/drm_hdcp.h

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 8b9ac321c3bd..4b2640d54c70 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -815,6 +815,23 @@
 #define DP_CEC_TX_MESSAGE_BUFFER   0x3020
 #define DP_CEC_MESSAGE_BUFFER_LENGTH 0x10
 
+#define DP_AUX_HDCP_BKSV   0x68000
+#define DP_AUX_HDCP_RI_PRIME   0x68005
+#define DP_AUX_HDCP_AKSV   0x68007
+#define DP_AUX_HDCP_AN 0x6800C
+#define DP_AUX_HDCP_V_PRIME(h) (0x68014 + h * 4)
+#define DP_AUX_HDCP_BCAPS  0x68028
+# define DP_BCAPS_REPEATER_PRESENT BIT(1)
+# define DP_BCAPS_HDCP_CAPABLE BIT(0)
+#define DP_AUX_HDCP_BSTATUS0x68029
+# define DP_BSTATUS_REAUTH_REQ BIT(3)
+# define DP_BSTATUS_LINK_FAILURE   BIT(2)
+# define DP_BSTATUS_R0_PRIME_READY BIT(1)
+# define DP_BSTATUS_READY  BIT(0)
+#define DP_AUX_HDCP_BINFO  0x6802A
+#define DP_AUX_HDCP_KSV_FIFO   0x6802C
+#define DP_AUX_HDCP_AINFO  0x6803B
+
 /* DP 1.2 Sideband message defines */
 /* peer device type - DP 1.2a Table 2-92 */
 #define DP_PEER_DEVICE_NONE0x0
diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
new file mode 100644
index ..c9b2484240d4
--- /dev/null
+++ b/include/drm/drm_hdcp.h
@@ -0,0 +1,56 @@
+/*
+ * Copyright (C) 2017 Google, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * Authors:
+ * Sean Paul 
+ */
+
+#ifndef _DRM_HDCP_H_INCLUDED_
+#define _DRM_HDCP_H_INCLUDED_
+
+/* Period of hdcp checks (to ensure we're still authenticated) */
+#define DRM_HDCP_CHECK_PERIOD_MS   (128 * 16)
+
+/* Shared lengths/masks between HDMI/DVI/DisplayPort */
+#define DRM_HDCP_AN_LEN8
+#define DRM_HDCP_BSTATUS_LEN   2
+#define DRM_HDCP_KSV_LEN   5
+#define DRM_HDCP_RI_LEN2
+#define DRM_HDCP_V_PRIME_PART_LEN  4
+#define DRM_HDCP_V_PRIME_NUM_PARTS 5
+#define DRM_HDCP_NUM_DOWNSTREAM(x) (x & 0x3f)
+
+/* Slave address for the HDCP registers in the receiver */
+#define DRM_HDCP_DDC_ADDR  0x3A
+
+/* HDCP register offsets for HDMI/DVI devices */
+#define DRM_HDCP_DDC_BKSV  0x00
+#define DRM_HDCP_DDC_RI_PRIME  0x08
+#define DRM_HDCP_DDC_AKSV  0x10
+#define DRM_HDCP_DDC_AN0x18
+#define DRM_HDCP_DDC_V_PRIME(h)(0x20 + h * 4)
+#define DRM_HDCP_DDC_BCAPS 0x40
+#define  DRM_HDCP_DDC_BCAPS_REPEATER_PRESENT   BIT(6)
+#define  DRM_HDCP_DDC_BCAPS_KSV_FIFO_READY BIT(5)
+#define DRM_HDCP_DDC_BSTATUS   0x41
+#define DRM_HDCP_DDC_KSV_FIFO  0x43
+
+#endif
-- 
2.15.0.531.g2ccb3012c9-goog

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

[PATCH v3 9/9] drm/i915: Implement HDCP for DisplayPort

[Sean Paul]

This patch adds HDCP support for DisplayPort connectors by implementing
the intel_hdcp_shim.

Most of this is straightforward read/write from/to DPCD registers. One
thing worth pointing out is the Aksv output bit. It wasn't easily
separable like it's HDMI counterpart, so it's crammed in with the rest
of it.

Changes in v2:
- Moved intel_hdcp_check_link out of intel_dp_check_link and only call
  it on short pulse. Since intel_hdcp_check_link does its own locking,
  this ensures we don't deadlock when intel_dp_check_link is called
  holding connection_mutex.
- Rebased on drm-intel-next
Changes in v3:
- Initialize new worker
- Move intel_hdcp_check_link further out to avoid calling it while
  holding _any_ locks

Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/i915/intel_dp.c | 248 ++--
 1 file changed, 241 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index c603d4c903e1..dc303e18c1dd 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -36,7 +36,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include "intel_drv.h"
 #include 
 #include "i915_drv.h"
@@ -1025,10 +1027,29 @@ static uint32_t skl_get_aux_send_ctl(struct intel_dp 
*intel_dp,
   DP_AUX_CH_CTL_SYNC_PULSE_SKL(32);
 }
 
+static uint32_t intel_dp_get_aux_send_ctl(struct intel_dp *intel_dp,
+ bool has_aux_irq,
+ int send_bytes,
+ uint32_t aux_clock_divider,
+ bool aksv_write)
+{
+   uint32_t val = 0;
+
+   if (aksv_write) {
+   send_bytes += 5;
+   val |= DP_AUX_CH_CTL_AUX_AKSV_SELECT;
+   }
+
+   return val | intel_dp->get_aux_send_ctl(intel_dp,
+   has_aux_irq,
+   send_bytes,
+   aux_clock_divider);
+}
+
 static int
 intel_dp_aux_ch(struct intel_dp *intel_dp,
const uint8_t *send, int send_bytes,
-   uint8_t *recv, int recv_size)
+   uint8_t *recv, int recv_size, bool aksv_write)
 {
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
struct drm_i915_private *dev_priv =
@@ -1088,10 +1109,11 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
}
 
while ((aux_clock_divider = intel_dp->get_aux_clock_divider(intel_dp, 
clock++))) {
-   u32 send_ctl = intel_dp->get_aux_send_ctl(intel_dp,
- has_aux_irq,
- send_bytes,
- aux_clock_divider);
+   u32 send_ctl = intel_dp_get_aux_send_ctl(intel_dp,
+has_aux_irq,
+send_bytes,
+aux_clock_divider,
+aksv_write);
 
/* Must try at least 3 times according to DP spec */
for (try = 0; try < 5; try++) {
@@ -1228,7 +1250,8 @@ intel_dp_aux_transfer(struct drm_dp_aux *aux, struct 
drm_dp_aux_msg *msg)
if (msg->buffer)
memcpy(txbuf + HEADER_SIZE, msg->buffer, msg->size);
 
-   ret = intel_dp_aux_ch(intel_dp, txbuf, txsize, rxbuf, rxsize);
+   ret = intel_dp_aux_ch(intel_dp, txbuf, txsize, rxbuf, rxsize,
+ false);
if (ret > 0) {
msg->reply = rxbuf[0] >> 4;
 
@@ -1250,7 +1273,8 @@ intel_dp_aux_transfer(struct drm_dp_aux *aux, struct 
drm_dp_aux_msg *msg)
if (WARN_ON(rxsize > 20))
return -E2BIG;
 
-   ret = intel_dp_aux_ch(intel_dp, txbuf, txsize, rxbuf, rxsize);
+   ret = intel_dp_aux_ch(intel_dp, txbuf, txsize, rxbuf, rxsize,
+ false);
if (ret > 0) {
msg->reply = rxbuf[0] >> 4;
/*
@@ -4981,6 +5005,203 @@ void intel_dp_encoder_suspend(struct intel_encoder 
*intel_encoder)
pps_unlock(intel_dp);
 }
 
+static
+int intel_dp_hdcp_write_an_aksv(struct intel_digital_port *intel_dig_port,
+   u8 *an)
+{
+   struct intel_dp *intel_dp = enc_to_intel_dp(_dig_port->base.base);
+   uint8_t txbuf[4], rxbuf[2], reply = 0;
+   ssize_t dpcd_ret;
+   int ret;
+
+   /* Output An first, that's easy */
+   dpcd_ret = drm_dp_dpcd_write(_dig_port->dp.aux, DP_AUX_HDCP_AN,
+an, DRM_HDCP_AN_LEN);
+   if (dpcd_ret != 

[PATCH v3 6/9] drm/i915: Make use of indexed write GMBUS feature

[Sean Paul]

This patch enables the indexed write feature of the GMBUS to concatenate
2 consecutive messages into one. The criteria for an indexed write is
that both messages are writes, the first is length == 1, and the second
is length > 0. The first message is sent out by the GMBUS as the slave
command, and the second one is sent via the GMBUS FIFO as usual.

Changes in v3:
- Added to series

Suggested-by: Ville Syrjälä 
Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/i915/intel_i2c.c | 39 ++-
 1 file changed, 34 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index 49fdf09f9919..7399009aee0a 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -373,7 +373,8 @@ gmbus_xfer_read(struct drm_i915_private *dev_priv, struct 
i2c_msg *msg,
 
 static int
 gmbus_xfer_write_chunk(struct drm_i915_private *dev_priv,
-  unsigned short addr, u8 *buf, unsigned int len)
+  unsigned short addr, u8 *buf, unsigned int len,
+  u32 gmbus1_index)
 {
unsigned int chunk_size = len;
u32 val, loop;
@@ -386,7 +387,7 @@ gmbus_xfer_write_chunk(struct drm_i915_private *dev_priv,
 
I915_WRITE_FW(GMBUS3, val);
I915_WRITE_FW(GMBUS1,
- GMBUS_CYCLE_WAIT |
+ gmbus1_index | GMBUS_CYCLE_WAIT |
  (chunk_size << GMBUS_BYTE_COUNT_SHIFT) |
  (addr << GMBUS_SLAVE_ADDR_SHIFT) |
  GMBUS_SLAVE_WRITE | GMBUS_SW_RDY);
@@ -409,7 +410,8 @@ gmbus_xfer_write_chunk(struct drm_i915_private *dev_priv,
 }
 
 static int
-gmbus_xfer_write(struct drm_i915_private *dev_priv, struct i2c_msg *msg)
+gmbus_xfer_write(struct drm_i915_private *dev_priv, struct i2c_msg *msg,
+u32 gmbus1_index)
 {
u8 *buf = msg->buf;
unsigned int tx_size = msg->len;
@@ -419,7 +421,8 @@ gmbus_xfer_write(struct drm_i915_private *dev_priv, struct 
i2c_msg *msg)
do {
len = min(tx_size, GMBUS_BYTE_COUNT_MAX);
 
-   ret = gmbus_xfer_write_chunk(dev_priv, msg->addr, buf, len);
+   ret = gmbus_xfer_write_chunk(dev_priv, msg->addr, buf, len,
+gmbus1_index);
if (ret)
return ret;
 
@@ -430,6 +433,14 @@ gmbus_xfer_write(struct drm_i915_private *dev_priv, struct 
i2c_msg *msg)
return 0;
 }
 
+static int
+gmbus_xfer_index_write(struct drm_i915_private *dev_priv, u8 cmd,
+  struct i2c_msg *msg)
+{
+   u8 gmbus1_index = GMBUS_CYCLE_INDEX | (cmd << GMBUS_SLAVE_INDEX_SHIFT);
+   return gmbus_xfer_write(dev_priv, msg, gmbus1_index);
+}
+
 /*
  * The gmbus controller can combine a 1 or 2 byte write with a read that
  * immediately follows it by using an "INDEX" cycle.
@@ -444,6 +455,20 @@ gmbus_is_index_read(struct i2c_msg *msgs, int i, int num)
(msgs[i + 1].flags & I2C_M_RD));
 }
 
+/*
+ * The gmbus controller can combine a 2-msg write into a single write that
+ * immediately follows it by using an "INDEX" cycle.
+ */
+static bool
+gmbus_is_index_write(struct i2c_msg *msgs, int i, int num)
+{
+   return (i + 1 < num &&
+   msgs[i].addr == msgs[i + 1].addr &&
+   !(msgs[i].flags & I2C_M_RD) &&
+   !(msgs[i + 1].flags & I2C_M_RD) &&
+   (msgs[i].len == 1 || msgs[i + 1].len > 0));
+}
+
 static int
 gmbus_xfer_index_read(struct drm_i915_private *dev_priv, struct i2c_msg *msgs)
 {
@@ -489,10 +514,14 @@ do_gmbus_xfer(struct i2c_adapter *adapter, struct i2c_msg 
*msgs, int num)
if (gmbus_is_index_read(msgs, i, num)) {
ret = gmbus_xfer_index_read(dev_priv, [i]);
inc = 2; /* an index read is two msgs */
+   } else if (gmbus_is_index_write(msgs, i, num)) {
+   ret = gmbus_xfer_index_write(dev_priv, msgs[i].buf[0],
+   [i + 1]);
+   inc = 2; /* an index write is two msgs */
} else if (msgs[i].flags & I2C_M_RD) {
ret = gmbus_xfer_read(dev_priv, [i], 0);
} else {
-   ret = gmbus_xfer_write(dev_priv, [i]);
+   ret = gmbus_xfer_write(dev_priv, [i], 0);
}
 
if (!ret)
-- 
2.15.0.531.g2ccb3012c9-goog

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

[PATCH v3 7/9] drm/i915: Add function to output Aksv over GMBUS

[Sean Paul]

Once the Aksv is available in the PCH, we need to get it on the wire to
the receiver via DDC. The hardware doesn't allow us to read the value
directly, so we need to tell GMBUS to source the Aksv internally and
send it to the right offset on the receiver.

The way we do this is to initiate an indexed write where the index is
the Aksv register offset. We write dummy values to GMBUS3 as if we were
sending the key, and the hardware slips in the "real" values when it
goes out.

Changes in v2:
- None
Changes in v3:
- Uses new index write feature (Ville)

Cc: Ville Syrjälä 
Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/i915/i915_drv.h  |  1 +
 drivers/gpu/drm/i915/i915_reg.h  |  1 +
 drivers/gpu/drm/i915/intel_i2c.c | 47 +---
 3 files changed, 46 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index bddd65839f60..6b39081c5e53 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -4049,6 +4049,7 @@ extern int intel_setup_gmbus(struct drm_i915_private 
*dev_priv);
 extern void intel_teardown_gmbus(struct drm_i915_private *dev_priv);
 extern bool intel_gmbus_is_valid_pin(struct drm_i915_private *dev_priv,
 unsigned int pin);
+extern int intel_gmbus_output_aksv(struct i2c_adapter *adapter);
 
 extern struct i2c_adapter *
 intel_gmbus_get_adapter(struct drm_i915_private *dev_priv, unsigned int pin);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 2bd2cc8441d4..107e16392710 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3043,6 +3043,7 @@ enum i915_power_well_id {
 # define GPIO_DATA_PULLUP_DISABLE  (1 << 13)
 
 #define GMBUS0 _MMIO(dev_priv->gpio_mmio_base + 0x5100) /* 
clock/port select */
+#define   GMBUS_AKSV_SELECT(1<<11)
 #define   GMBUS_RATE_100KHZ(0<<8)
 #define   GMBUS_RATE_50KHZ (1<<8)
 #define   GMBUS_RATE_400KHZ(2<<8) /* reserved on Pineview */
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index 7399009aee0a..0a4c7486fc7b 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "intel_drv.h"
 #include 
 #include "i915_drv.h"
@@ -497,7 +498,8 @@ gmbus_xfer_index_read(struct drm_i915_private *dev_priv, 
struct i2c_msg *msgs)
 }
 
 static int
-do_gmbus_xfer(struct i2c_adapter *adapter, struct i2c_msg *msgs, int num)
+do_gmbus_xfer(struct i2c_adapter *adapter, struct i2c_msg *msgs, int num,
+ u32 gmbus0_source)
 {
struct intel_gmbus *bus = container_of(adapter,
   struct intel_gmbus,
@@ -507,7 +509,7 @@ do_gmbus_xfer(struct i2c_adapter *adapter, struct i2c_msg 
*msgs, int num)
int ret = 0;
 
 retry:
-   I915_WRITE_FW(GMBUS0, bus->reg0);
+   I915_WRITE_FW(GMBUS0, gmbus0_source | bus->reg0);
 
for (; i < num; i += inc) {
inc = 1;
@@ -629,7 +631,7 @@ gmbus_xfer(struct i2c_adapter *adapter, struct i2c_msg 
*msgs, int num)
if (ret < 0)
bus->force_bit &= ~GMBUS_FORCE_BIT_RETRY;
} else {
-   ret = do_gmbus_xfer(adapter, msgs, num);
+   ret = do_gmbus_xfer(adapter, msgs, num, 0);
if (ret == -EAGAIN)
bus->force_bit |= GMBUS_FORCE_BIT_RETRY;
}
@@ -639,6 +641,45 @@ gmbus_xfer(struct i2c_adapter *adapter, struct i2c_msg 
*msgs, int num)
return ret;
 }
 
+int intel_gmbus_output_aksv(struct i2c_adapter *adapter)
+{
+   struct intel_gmbus *bus = container_of(adapter, struct intel_gmbus,
+  adapter);
+   struct drm_i915_private *dev_priv = bus->dev_priv;
+   int ret;
+   u8 cmd = DRM_HDCP_DDC_AKSV ;
+   u8 buf[DRM_HDCP_KSV_LEN] = { 0 };
+   struct i2c_msg msgs[] = {
+   {
+   .addr = DRM_HDCP_DDC_ADDR,
+   .flags = 0,
+   .len = sizeof(cmd),
+   .buf = ,
+   },
+   {
+   .addr = DRM_HDCP_DDC_ADDR,
+   .flags = 0,
+   .len = sizeof(buf),
+   .buf = buf,
+   }
+   };
+
+   intel_display_power_get(dev_priv, POWER_DOMAIN_GMBUS);
+   mutex_lock(_priv->gmbus_mutex);
+
+   /*
+* In order to output Aksv to the receiver, use an indexed write to
+* pass the i2c command, and tell GMBUS to use the HW-provided value
+* instead of sourcing GMBUS3 for the data.
+*/
+   ret = do_gmbus_xfer(adapter, msgs, ARRAY_SIZE(msgs), GMBUS_AKSV_SELECT);
+
+   mutex_unlock(_priv->gmbus_mutex);
+   intel_display_power_put(dev_priv, 

[PATCH v3 0/9] drm/i915: Implement HDCP

[Sean Paul]

Oh, hello there. Here's v3 of the HDCP patchset.

Highlights of v3 are:
- Add atomic_check/commit helpers to intel_hdcp to handle state transitions and
  call enable/disable at the right time.
- intel_hdcp_check_link() gets moved again to avoid being called with locks held
- Split out setting the property from the check worker into its own dedicated
  worker. This avoids deadlock when doing a synchronous cancel with mode_config
  lock(s) held.
- Add internal connector->hdcp_value to track actual state of hardware
- Add "indexed writes" to GMBUS driver
- Rebase on drm-tip to pick up new wait_for
- Tested with igt patch

Thanks!

Sean


Sean Paul (9):
  drm: Fix link-status kerneldoc line lengths
  drm/i915: Add more control to wait_for routines
  drm: Add Content Protection property
  drm: Add some HDCP related #defines
  drm/i915: Add HDCP framework + base implementation
  drm/i915: Make use of indexed write GMBUS feature
  drm/i915: Add function to output Aksv over GMBUS
  drm/i915: Implement HDCP for HDMI
  drm/i915: Implement HDCP for DisplayPort

 drivers/gpu/drm/drm_atomic.c |   8 +
 drivers/gpu/drm/drm_connector.c  |  80 +++-
 drivers/gpu/drm/drm_sysfs.c  |   1 +
 drivers/gpu/drm/i915/Makefile|   1 +
 drivers/gpu/drm/i915/i915_drv.h  |   1 +
 drivers/gpu/drm/i915/i915_reg.h  |  85 
 drivers/gpu/drm/i915/intel_atomic.c  |   2 +
 drivers/gpu/drm/i915/intel_ddi.c |  50 +++
 drivers/gpu/drm/i915/intel_display.c |  14 +
 drivers/gpu/drm/i915/intel_dp.c  | 248 +++-
 drivers/gpu/drm/i915/intel_drv.h | 107 -
 drivers/gpu/drm/i915/intel_hdcp.c| 731 +++
 drivers/gpu/drm/i915/intel_hdmi.c| 257 
 drivers/gpu/drm/i915/intel_i2c.c |  86 -
 drivers/gpu/drm/i915/intel_uncore.c  |  23 +-
 drivers/gpu/drm/i915/intel_uncore.h  |  14 +-
 include/drm/drm_connector.h  |  16 +
 include/drm/drm_dp_helper.h  |  17 +
 include/drm/drm_hdcp.h   |  56 +++
 include/uapi/drm/drm_mode.h  |   4 +
 20 files changed, 1767 insertions(+), 34 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_hdcp.c
 create mode 100644 include/drm/drm_hdcp.h

-- 
2.15.0.531.g2ccb3012c9-goog

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

[PATCH v3 1/9] drm: Fix link-status kerneldoc line lengths

[Sean Paul]

I'm adding some stuff below it and it's killing my editor's vibe.

Changes in v2:
- Added to the series
Changes in v3:
- None

Cc: Manasi Navare 
Acked-by: Daniel Vetter 
Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/drm_connector.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 704fc8934616..f14b48e6e839 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -759,10 +759,11 @@ DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
  * should update this value using drm_mode_connector_set_tile_property().
  * Userspace cannot change this property.
  * link-status:
- *  Connector link-status property to indicate the status of link. The 
default
- *  value of link-status is "GOOD". If something fails during or after 
modeset,
- *  the kernel driver may set this to "BAD" and issue a hotplug uevent. 
Drivers
- *  should update this value using 
drm_mode_connector_set_link_status_property().
+ *  Connector link-status property to indicate the status of link. The
+ *  default value of link-status is "GOOD". If something fails during or
+ *  after modeset, the kernel driver may set this to "BAD" and issue a
+ *  hotplug uevent. Drivers should update this value using
+ *  drm_mode_connector_set_link_status_property().
  *
  * Connectors also have one standardized atomic property:
  *
-- 
2.15.0.531.g2ccb3012c9-goog

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

[PATCH v3 2/9] drm/i915: Add more control to wait_for routines

[Sean Paul]

This patch adds a little more control to a couple wait_for routines such
that we can avoid open-coding read/wait/timeout patterns which:
 - need the value of the register after the wait_for
 - run arbitrary operation for the read portion

This patch also chooses the correct sleep function (based on
timers-howto.txt) for the polling interval the caller specifies.

Changes in v2:
- Added to the series
Changes in v3:
- Rebased on drm-intel-next-queued and the new Wmin/max _wait_for
- Removed msleep option

Suggested-by: Chris Wilson 
Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/i915/intel_drv.h| 17 ++---
 drivers/gpu/drm/i915/intel_uncore.c | 23 ---
 drivers/gpu/drm/i915/intel_uncore.h | 14 +-
 3 files changed, 39 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 64426d3e078e..852b3d161754 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -41,20 +41,21 @@
 #include 
 
 /**
- * _wait_for - magic (register) wait macro
+ * __wait_for - magic wait macro
  *
- * Does the right thing for modeset paths when run under kdgb or similar atomic
- * contexts. Note that it's important that we check the condition again after
- * having timed out, since the timeout could be due to preemption or similar 
and
- * we've never had a chance to check the condition before the timeout.
+ * Macro to help avoid open coding check/wait/timeout patterns. Note that it's
+ * important that we check the condition again after having timed out, since 
the
+ * timeout could be due to preemption or similar and we've never had a chance 
to
+ * check the condition before the timeout.
  */
-#define _wait_for(COND, US, Wmin, Wmax) ({ \
+#define __wait_for(OP, COND, US, Wmin, Wmax) ({ \
unsigned long timeout__ = jiffies + usecs_to_jiffies(US) + 1;   \
long wait__ = (Wmin); /* recommended min for usleep is 10 us */ \
int ret__;  \
might_sleep();  \
for (;;) {  \
bool expired__ = time_after(jiffies, timeout__);\
+   OP; \
if (COND) { \
ret__ = 0;  \
break;  \
@@ -70,7 +71,9 @@
ret__;  \
 })
 
-#define wait_for(COND, MS) _wait_for((COND), (MS) * 1000, 10, 1000)
+#define _wait_for(COND, US, Wmin, Wmax)__wait_for(;, (COND), (US), 
(Wmin), \
+  (Wmax))
+#define wait_for(COND, MS) _wait_for((COND), (MS) * 1000, 10, 1000)
 
 /* If CONFIG_PREEMPT_COUNT is disabled, in_atomic() always reports false. */
 #if defined(CONFIG_DRM_I915_DEBUG) && defined(CONFIG_PREEMPT_COUNT)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index b4621271e7a2..9c7d07151f16 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1770,12 +1770,14 @@ int __intel_wait_for_register_fw(struct 
drm_i915_private *dev_priv,
 }
 
 /**
- * intel_wait_for_register - wait until register matches expected state
+ * __intel_wait_for_register - wait until register matches expected state
  * @dev_priv: the i915 device
  * @reg: the register to read
  * @mask: mask to apply to register value
  * @value: expected value
- * @timeout_ms: timeout in millisecond
+ * @fast_timeout_us: fast timeout in microsecond for atomic/tight wait
+ * @slow_timeout_ms: slow timeout in millisecond
+ * @out_value: optional placeholder to hold registry value
  *
  * This routine waits until the target register @reg contains the expected
  * @value after applying the @mask, i.e. it waits until ::
@@ -1786,15 +1788,18 @@ int __intel_wait_for_register_fw(struct 
drm_i915_private *dev_priv,
  *
  * Returns 0 if the register matches the desired condition, or -ETIMEOUT.
  */
-int intel_wait_for_register(struct drm_i915_private *dev_priv,
+int __intel_wait_for_register(struct drm_i915_private *dev_priv,
i915_reg_t reg,
u32 mask,
u32 value,
-   unsigned int timeout_ms)
+   unsigned int fast_timeout_us,
+   unsigned int slow_timeout_ms,
+   u32 *out_value)
 {
unsigned fw =
intel_uncore_forcewake_for_reg(dev_priv, reg, FW_REG_READ);
int ret;
+   u32 reg_value;
 
might_sleep();
 
@@ -1803,14 +1808,18 @@ int intel_wait_for_register(struct 

linux-next: Signed-off-by missing for commits in the drm tree

[Stephen Rothwell]

Hi all,

Commits

  36a46da90212 ("drm: rcar-du: Add R8A7743 support")
  cdd907001572 ("drm: rcar-du: Add R8A7745 support")
  7912dee7775e ("drm: rcar-du: Implement system suspend/resume support")
  cf05f74ef40e ("drm: rcar-du: Remove unused CRTC suspend/resume functions")

are missing a Signed-off-by from their committer.

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

RE: [PATCH 2/2] drm/ttm: swap consecutive allocated pooled pages v3

[He, Roger]

Hold on,  only Patch 1 is Reviewed-by: Roger He .

For Patch 2:

+   list_for_each_entry(p, , lru) {
+   /* Swap the pages if we detect consecutive order */
+   if (count > first && pages[count - 1] == p - 1) {   

+   swap(p, pages[count - 1]);// swap seems breaking 
the plist, after that iteration plist will not work.
}
pages[count++] = temp;
+   }

-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of 
He, Roger
Sent: Tuesday, December 05, 2017 10:01 AM
To: Christian König ; 
dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org
Subject: RE: [PATCH 2/2] drm/ttm: swap consecutive allocated pooled pages v3

Series is:
Reviewed-by: Roger He 

Thanks
Roger(Hongbo.He)
-Original Message-
From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com] 
Sent: Monday, December 04, 2017 8:46 PM
To: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org; He, Roger 

Subject: [PATCH 2/2] drm/ttm: swap consecutive allocated pooled pages v3

When we detect consecutive allocation of pages swap them to avoid accidentally 
freeing them as huge page.

v2: use swap
v3: check if it's really the first allocated page

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_page_alloc.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 7c4d4edce0ba..da8a50f7c8fe 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -954,8 +954,13 @@ static int ttm_get_pages(struct page **pages, unsigned 
npages, int flags,
r = ttm_page_pool_get_pages(pool, , flags, cstate,
npages - count, 0);
 
-   list_for_each_entry(p, , lru)
+   first = count;
+   list_for_each_entry(p, , lru) {
+   /* Swap the pages if we detect consecutive order */
+   if (count > first && pages[count - 1] == p - 1)
+   swap(p, pages[count - 1]);
pages[count++] = p;
+   }
 
if (r) {
/* If there is any pages in the list put them back to
--
2.11.0

___
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

RE: [PATCH 2/2] drm/ttm: swap consecutive allocated pooled pages v3

[He, Roger]

Series is:
Reviewed-by: Roger He 

Thanks
Roger(Hongbo.He)
-Original Message-
From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com] 
Sent: Monday, December 04, 2017 8:46 PM
To: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org; He, Roger 

Subject: [PATCH 2/2] drm/ttm: swap consecutive allocated pooled pages v3

When we detect consecutive allocation of pages swap them to avoid accidentally 
freeing them as huge page.

v2: use swap
v3: check if it's really the first allocated page

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_page_alloc.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 7c4d4edce0ba..da8a50f7c8fe 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -954,8 +954,13 @@ static int ttm_get_pages(struct page **pages, unsigned 
npages, int flags,
r = ttm_page_pool_get_pages(pool, , flags, cstate,
npages - count, 0);
 
-   list_for_each_entry(p, , lru)
+   first = count;
+   list_for_each_entry(p, , lru) {
+   /* Swap the pages if we detect consecutive order */
+   if (count > first && pages[count - 1] == p - 1)
+   swap(p, pages[count - 1]);
pages[count++] = p;
+   }
 
if (r) {
/* If there is any pages in the list put them back to
--
2.11.0

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

Re: [PATCH v3 5/6] dt-bindings: add the rockchip, dual-channel for dw-mipi-dsi

[Brian Norris]

Hi Archit,

I'm a relative n00b here, but I'm trying to follow along and I have some
questions:

On Fri, Dec 01, 2017 at 06:29:04PM +0530, Archit Taneja wrote:
> On 11/30/2017 11:02 PM, Nickey Yang wrote:
> >I try to follow as you suggested,use
> >
> >mipi_dsi: mipi@ff96 {
> >     ...
> >     ...
> >     clock-master;    /* implies that this DSI instance drivers the clock
> >              * for both the DSIs.
> >              */
> >     ports {
> >         mipi_in: port {
> >             ...
> >             ...
> >         };
> >         /* add extra output ports for both DSIs */
> >         mipi_out: port {
> >             mipi_panel_out: endpoint {
> >                 remote-endpoint = <_in_channel0>;
> >             };
> >         };
> >     };
> >     panel {
> >         ...
> >         ...
> >         /*
> >          * panel node can describe its input ports, if both the DSIs output
> >          * ports are connected to the same device (i.e, the same DSI panel),
> >          * we can assume that the DSIs need to operate in dual DSI mode
> >          */
> >         ports {
> >             ...
> >             port@0 {
> >                 panel_in_channel0: endpoint {
> >                     remote-endpoint = <_panel_out>;
> >                 };
> >             };
> >             port@1 {
> >                 panel_in_channel1: endpoint {
> >                     remote-endpoint = <_panel_out>;
> >                 };
> >
> >             };
> >         };
> >     };
> >};
> >
> >mipi_dsi1: mipi@ff968000 {
> >     ...
> >     ...
> >     ports {
> >         mipi1_in: port {
> >             ...
> >             ...
> >         };
> >         mipi1_out: port {
> >             mipi1_panel_out: endpoint {
> >                 remote-endpoint = <_in_channel1>;
> >             };
> >         };
> >     };
> >}
> >
> >But it seems we can not use of_drm_find_panel(like below)
> >
> >/*
> >     port = of_graph_get_port_by_id(dev->of_node, 1);
> >     if (port) {
> >     endpoint = of_get_child_by_name(port, "endpoint");
> >     of_node_put(port);
> >     if (!endpoint) {
> >     dev_err(dev, "no output endpoint found\n");
> >     return -EINVAL;
> >     }
> >     panel_node = of_graph_get_remote_port_parent(endpoint);
> >     of_node_put(endpoint);
> >     if (!panel_node) {
> >     dev_err(dev, "no output node found\n");
> >     return -EINVAL;
> >     }
> >     panel = of_drm_find_panel(panel_node);
> >     of_node_put(panel_node);
> >     if (!panel)
> >     return -EPROBE_DEFER;
> >     }
> >*/
> >to get DSI1 outputs,because of_drm_find_panel need compare
> >
> >if (panel->dev->of_node == np)
> >
> >in dsi_panel driver innolux->base.dev = >link->dev;
> >dsi->dev
> 
> Yes, we should only have 1 drm_panel in the global panel list.
> Shouldn't it be possible to modify the dsi driver such that dsi1
> doesn't care whether it has a drm_panel for it or not, if we are
> in dual dsi mode?
> 
> I imagine a sequence like this:
> 
> 1. dsi0 probes, parses the of-graph, finds the panel and saves its device
> node.

Does this mean we depend on probe order? Or would we be able to
-EPROBE_DEFER or similar if dsi1 binds first?

> 2. dsi1 probes, parses the of-graph, find the panel's device node
>   - dsi1 checks if it is the same as the panel attached to dsi0.
>   - If so, it just takes the drm_panel pointer from dsi0.
>   - If not, it tries a of_drm_find_panel() on the panel's device node.

So, that all means we'd need a new variant of
drm_of_find_panel_or_bridge() for "dual" drivers like this? Or else
open-code this logic in dw-mipi-dsi.c?

> A dual DSI panel driver would also be a bit different. It will be a
> mipi_dsi_driver with the master DSI (dsi0) as the mipi_dsi_device. Using
> the of-graph helpers, we would get the device node of dsi1 using
> of_find_mipi_dsi_host_by_node(), and create another DSI device using
> mipi_dsi_device_register_full(). Then, we call mipi_dsi_attach() on
> both the dsi devices.

That seems...interesting. I guess that sounds like it could work, but
someone would have to play with that a bit more.

I assume one wouldn't want to do all this in every dual DSI driver that
needs this, right?

> >struct innolux_panel {
> >     struct drm_panel base;
> >     struct mipi_dsi_device *link;
> >};
> >It means one panel can only be found in his dsi node,(like dsi0 above).
> >
> >I'm doubting about it, Or  may we follow tegra_dsi_ganged_probe
> >(drivers/gpu/drm/tergra/dsi.c) method.
> 
> This method will add a new binding similar to "nvidia,ganged-mode", which
> is something we don't want to do.

It's unfortunate we have the anti-pattern already merged :(

Brian
___
dri-devel mailing list

[drm-tip:drm-tip 8/11] drivers/gpu/drm/i915/intel_dsi.c:1673:13: error: storage size of 'plane' isn't known

[kbuild test robot]

tree:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
head:   da94f258bbf0786f7578d4804a77ce75cf58777f
commit: b41c97d7270b82207c5edc7c2d67337b15918462 [8/11] Merge remote-tracking 
branch 'drm-intel/drm-intel-next-queued' into drm-tip
config: i386-randconfig-x007-12041112 (attached as .config)
compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
reproduce:
git checkout b41c97d7270b82207c5edc7c2d67337b15918462
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/i915/intel_dsi.c: In function 
'intel_dsi_get_panel_orientation':
>> drivers/gpu/drm/i915/intel_dsi.c:1673:13: error: storage size of 'plane' 
>> isn't known
 enum plane plane;
^
   drivers/gpu/drm/i915/intel_dsi.c:1673:13: warning: unused variable 'plane' 
[-Wunused-variable]

vim +1673 drivers/gpu/drm/i915/intel_dsi.c

4e646495 Jani Nikula   2013-08-27  1668  
82daca29 Hans de Goede 2017-11-25  1669  static int 
intel_dsi_get_panel_orientation(struct intel_connector *connector)
82daca29 Hans de Goede 2017-11-25  1670  {
82daca29 Hans de Goede 2017-11-25  1671 struct drm_i915_private 
*dev_priv = to_i915(connector->base.dev);
82daca29 Hans de Goede 2017-11-25  1672 int orientation = 
DRM_MODE_PANEL_ORIENTATION_NORMAL;
82daca29 Hans de Goede 2017-11-25 @1673 enum plane plane;
82daca29 Hans de Goede 2017-11-25  1674 u32 val;
82daca29 Hans de Goede 2017-11-25  1675  
82daca29 Hans de Goede 2017-11-25  1676 if (IS_VALLEYVIEW(dev_priv) || 
IS_CHERRYVIEW(dev_priv)) {
82daca29 Hans de Goede 2017-11-25  1677 if 
(connector->encoder->crtc_mask == BIT(PIPE_B))
82daca29 Hans de Goede 2017-11-25  1678 plane = PLANE_B;
82daca29 Hans de Goede 2017-11-25  1679 else
82daca29 Hans de Goede 2017-11-25  1680 plane = PLANE_A;
82daca29 Hans de Goede 2017-11-25  1681  
82daca29 Hans de Goede 2017-11-25  1682 val = 
I915_READ(DSPCNTR(plane));
82daca29 Hans de Goede 2017-11-25  1683 if (val & 
DISPPLANE_ROTATE_180)
82daca29 Hans de Goede 2017-11-25  1684 orientation = 
DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP;
82daca29 Hans de Goede 2017-11-25  1685 }
82daca29 Hans de Goede 2017-11-25  1686  
82daca29 Hans de Goede 2017-11-25  1687 return orientation;
82daca29 Hans de Goede 2017-11-25  1688  }
82daca29 Hans de Goede 2017-11-25  1689  

:: The code at line 1673 was first introduced by commit
:: 82daca297506a93354a532f7a08654ef3a646924 drm/i915: Add "panel 
orientation" property to the panel connector, v6.

:: TO: Hans de Goede 
:: CC: Hans de Goede 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[drm-tip:drm-tip 8/11] drivers/gpu//drm/i915/intel_dsi.c:1673:13: error: unused variable 'plane'

[kbuild test robot]

tree:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
head:   da94f258bbf0786f7578d4804a77ce75cf58777f
commit: b41c97d7270b82207c5edc7c2d67337b15918462 [8/11] Merge remote-tracking 
branch 'drm-intel/drm-intel-next-queued' into drm-tip
config: x86_64-randconfig-x009-201749 (attached as .config)
compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
reproduce:
git checkout b41c97d7270b82207c5edc7c2d67337b15918462
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/gpu//drm/i915/intel_dsi.c: In function 
'intel_dsi_get_panel_orientation':
   drivers/gpu//drm/i915/intel_dsi.c:1673:13: error: storage size of 'plane' 
isn't known
 enum plane plane;
^
>> drivers/gpu//drm/i915/intel_dsi.c:1673:13: error: unused variable 'plane' 
>> [-Werror=unused-variable]
   cc1: all warnings being treated as errors

vim +/plane +1673 drivers/gpu//drm/i915/intel_dsi.c

4e646495 Jani Nikula   2013-08-27  1668  
82daca29 Hans de Goede 2017-11-25  1669  static int 
intel_dsi_get_panel_orientation(struct intel_connector *connector)
82daca29 Hans de Goede 2017-11-25  1670  {
82daca29 Hans de Goede 2017-11-25  1671 struct drm_i915_private 
*dev_priv = to_i915(connector->base.dev);
82daca29 Hans de Goede 2017-11-25  1672 int orientation = 
DRM_MODE_PANEL_ORIENTATION_NORMAL;
82daca29 Hans de Goede 2017-11-25 @1673 enum plane plane;
82daca29 Hans de Goede 2017-11-25  1674 u32 val;
82daca29 Hans de Goede 2017-11-25  1675  
82daca29 Hans de Goede 2017-11-25  1676 if (IS_VALLEYVIEW(dev_priv) || 
IS_CHERRYVIEW(dev_priv)) {
82daca29 Hans de Goede 2017-11-25  1677 if 
(connector->encoder->crtc_mask == BIT(PIPE_B))
82daca29 Hans de Goede 2017-11-25  1678 plane = PLANE_B;
82daca29 Hans de Goede 2017-11-25  1679 else
82daca29 Hans de Goede 2017-11-25  1680 plane = PLANE_A;
82daca29 Hans de Goede 2017-11-25  1681  
82daca29 Hans de Goede 2017-11-25  1682 val = 
I915_READ(DSPCNTR(plane));
82daca29 Hans de Goede 2017-11-25  1683 if (val & 
DISPPLANE_ROTATE_180)
82daca29 Hans de Goede 2017-11-25  1684 orientation = 
DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP;
82daca29 Hans de Goede 2017-11-25  1685 }
82daca29 Hans de Goede 2017-11-25  1686  
82daca29 Hans de Goede 2017-11-25  1687 return orientation;
82daca29 Hans de Goede 2017-11-25  1688  }
82daca29 Hans de Goede 2017-11-25  1689  

:: The code at line 1673 was first introduced by commit
:: 82daca297506a93354a532f7a08654ef3a646924 drm/i915: Add "panel 
orientation" property to the panel connector, v6.

:: TO: Hans de Goede 
:: CC: Hans de Goede 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104090] Reduced colors on RX580 through eDP on Asus GL702ZC laptop

[bugzilla-daemon]

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

--- Comment #10 from Hein-Pieter van Braam  ---
Created attachment 135955
  --> https://bugs.freedesktop.org/attachment.cgi?id=135955=edit
DC: dmesg -T

-- 
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 104090] Reduced colors on RX580 through eDP on Asus GL702ZC laptop

[bugzilla-daemon]

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

--- Comment #9 from Hein-Pieter van Braam  ---
Created attachment 135954
  --> https://bugs.freedesktop.org/attachment.cgi?id=135954=edit
DC: Xorg.log

-- 
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 104090] Reduced colors on RX580 through eDP on Asus GL702ZC laptop

[bugzilla-daemon]

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

--- Comment #8 from Hein-Pieter van Braam  ---
Created attachment 135953
  --> https://bugs.freedesktop.org/attachment.cgi?id=135953=edit
DC: xrandr --prop output

-- 
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 104090] Reduced colors on RX580 through eDP on Asus GL702ZC laptop

[bugzilla-daemon]

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

--- Comment #7 from Hein-Pieter van Braam  ---
Created attachment 135952
  --> https://bugs.freedesktop.org/attachment.cgi?id=135952=edit
Without DC: dmesg -T

-- 
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 104090] Reduced colors on RX580 through eDP on Asus GL702ZC laptop

[bugzilla-daemon]

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

--- Comment #5 from Hein-Pieter van Braam  ---
Created attachment 135950
  --> https://bugs.freedesktop.org/attachment.cgi?id=135950=edit
Without DC: xrandr --prop output

-- 
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 104090] Reduced colors on RX580 through eDP on Asus GL702ZC laptop

[bugzilla-daemon]

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

--- Comment #6 from Hein-Pieter van Braam  ---
Created attachment 135951
  --> https://bugs.freedesktop.org/attachment.cgi?id=135951=edit
Without DC: Xorg.log

-- 
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 104090] Reduced colors on RX580 through eDP on Asus GL702ZC laptop

[bugzilla-daemon]

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

--- Comment #4 from Hein-Pieter van Braam  ---
Created attachment 135949
  --> https://bugs.freedesktop.org/attachment.cgi?id=135949=edit
Without DC: Gnome shell shutdown dialog

-- 
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 104090] Reduced colors on RX580 through eDP on Asus GL702ZC laptop

[bugzilla-daemon]

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

--- Comment #3 from Hein-Pieter van Braam  ---
Created attachment 135948
  --> https://bugs.freedesktop.org/attachment.cgi?id=135948=edit
DC: Gnome shell shutdown dialog

-- 
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 104090] Reduced colors on RX580 through eDP on Asus GL702ZC laptop

[bugzilla-daemon]

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

--- Comment #2 from Hein-Pieter van Braam  ---
Created attachment 135947
  --> https://bugs.freedesktop.org/attachment.cgi?id=135947=edit
DC: Gnome shell overview

-- 
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 104090] Reduced colors on RX580 through eDP on Asus GL702ZC laptop

[bugzilla-daemon]

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

--- Comment #1 from Hein-Pieter van Braam  ---
Created attachment 135946
  --> https://bugs.freedesktop.org/attachment.cgi?id=135946=edit
Without DC: Gnome shell overview

-- 
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 104090] Reduced colors on RX580 through eDP on Asus GL702ZC laptop

[bugzilla-daemon]

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

Bug ID: 104090
   Summary: Reduced colors on RX580 through eDP on Asus GL702ZC
laptop
   Product: DRI
   Version: DRI git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Keywords: regression
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: h...@tmm.cx

When enabling DC on the RX580 on Linux 4.15.0-rc2 I get a reduced color palette
compared to having DC turned off. 

My setup: 
Fedora 27
Xorg 1.19.5
Xorg drivers amdgpu 1.3.0
Linux 4.15.0-rc2

Attached you will find dmesg, xorg, and xrandr output with and without DC along
with 2 pictures with and without dc for the results that I'm talking about.

-- 
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] drm: Document that drm_panel_orientation_quirks.c is shared with fbdev

[Hans de Goede]

Add a comment to the DRM_PANEL_ORIENTATION_QUIRKS documenting that the
reason for a separate Kconfig for this is because
drm_panel_orientation_quirks.c code is shared with fbdev.

Suggested-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 0b166e626eb6..d853989848d6 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -27,6 +27,7 @@ config DRM_MIPI_DSI
bool
depends on DRM
 
+# Separate option because drm_panel_orientation_quirks.c is shared with fbdev
 config DRM_PANEL_ORIENTATION_QUIRKS
tristate
 
-- 
2.14.3

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

Re: [PATCH v7 0/7] drm/fbdev: Panel orientation connector property support

[Hans de Goede]

Hi,

On 01-12-17 19:02, Bartlomiej Zolnierkiewicz wrote:

On Saturday, November 25, 2017 08:35:46 PM Hans de Goede wrote:

Here is v7 of my series to add a "panel orientation" property to
the drm-connector for the LCD panel to let userspace know about LCD
panels which are not mounted upright, as well as detecting upside-down
panels without needing quirks (like we do for 90 degree rotated screens).

Bartlomiej, can we please have your Acked-by for merging patches 1,
6 and 7 through the drm tree?


Acked-by: Bartlomiej Zolnierkiewicz 


Thank you.


Given that you add (can be in a incremental patch) a comment to:

   drivers/gpu/drm/drm_panel_orientation_quirks.c [ at the top ]


I've fixed this up before merging, adding this comment:

 * Note the quirks in this file are shared with fbdev/efifb and as such
 * must not depend on other drm code.


and

   drivers/gpu/drm/Kconfig [ to config DRM_PANEL_ORIENTATION_QUIRKS ]


Not everyone likes adding comments to Kconfig files I've had
push-back against that in the past. So I will post a follow-up patch
for this and then we will see from there.


explaining that the code in question is shared with fbdev/efifb (so
hopefully people will be careful and not try to make this code DRM
specific at some point in a future).


Regards,

Hans




New in v7:
-Fix embarrassing build error in efifb due to me only rebuilding modules
  after cleanups from v6

New in v6:
-Fix / reference kernel-doc comments
-Don't export the DRM_MODE_PANEL_ORIENTATION_* defines in the UAPI
-Move i915 dsi hardware rotation state read-out to intel_dsi_init()

New in v5:
-Add kernel-doc comment documenting drm_get_panel_orientation_quirk()
-drm_fb_helper: Only use hardware (crtc primary plane) rotation for
  180 degrees for now as 9-/270 degrees rotation requires special handling

New in v4:
-Fix drm_fb_helper code setting an invalid rotation value on the primary
  plane of disabled/unused crtcs (caught by Fi.CI)

New in v3:
-As requested by Daniel v3 moves the quirks over from the fbdev
  subsys to the drm subsys. I've done this by simpy starting with a copy of
  the quirk table and eventually removing the fbdev version.

The 1st patch in this series is a small fbdev/fbcon patch, patches 2-5
are all drm patches and patches 6-7 are fbdev/fbcon patches again. As
discussed previously the plan is to merge all 7 patches through the
drm tree.


Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics


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

Re: [PATCH 0/4] Move DP phy switch to PHY driver

[Heiko Stübner]

Hi,

Am Montag, 4. Dezember 2017, 08:08:31 CET schrieb Doug Anderson:
> On Sun, Dec 3, 2017 at 11:46 PM, Heiko Stübner  wrote:
> > Am Montag, 4. Dezember 2017, 10:47:08 CET schrieb Chris Zhong:
> >> On 2017年12月02日 05:58, Heiko Stuebner wrote:
> >> > Am Freitag, 1. Dezember 2017, 13:42:46 CET schrieb Doug Anderson:
> >> >> On Wed, Nov 29, 2017 at 6:27 PM, Chris Zhong  
wrote:
> >> >>> Thank you for mentioning this patch.
> >> >>> 
> >> >>> I think the focus of the discussion is: can we put the grf control
> >> >>> bit
> >> >>> to
> >> >>> dts.
> >> >>> 
> >> >>> The RK3399 has 2 Type-C phy, but only one DP controller, this
> >> >>> "uphy_dp_sel"
> >> >>> 
> >> >>> can help to switch these 2 phy. So I think this bit can be considered
> >> >>> as
> >> >>> a
> >> >>> part of
> >> >>> 
> >> >>> Type-C phy, these 2 phy have different bits, just similar to other
> >> >>> bits
> >> >>> (such as "pipe-status").
> >> >>> 
> >> >>> Put them to DTS file might be a accepted practice.
> >> >> 
> >> >> I guess the first step would be finding the person to make a decision.
> >> >> Is that Heiko?  Olof?  Kishon?  Rob?.  As I see it there are a few
> >> >> options:
> >> >> 
> >> >> 1. Land this series as-is.  This makes the new bit work just like all
> >> >> the other ones next to it.  If anyone happens to try to use an old
> >> >> device tree on a new kernel they'll break.  Seems rather unlikely
> >> >> given that the whole type C PHY is not really fully functional
> >> >> upstream, but technically this is a no-no from a device tree
> >> >> perspective.
> >> >> 
> >> >> 2. Change the series to make this property optional.  If it's not
> >> >> there then the code behaves like it always did.  This would address
> >> >> the "compatibility" problem but likely wouldn't actually help any real
> >> >> people, and it would be extra work.
> >> >> 
> >> >> 3. Redo the driver to deprecate all the old offsets / bits and just
> >> >> put the table in the driver, keyed off the compatible string and base
> >> >> address if the IO memory.
> >> >> 
> >> >> 
> >> >> I can't make this decision.  It's up to those folks who would be
> >> >> landing the patch and I'd be happy with any of them.  What I'm less
> >> >> happy with, however, is the indecision preventing forward progress.
> >> >> We should pick one of the above things and land it.  My own personal
> >> >> bias is #1: just land the series.  No real people will be hurt and
> >> >> it's just adding another property that matches the ones next to it.
> >> > 
> >> > I'd second that #1 . That whole type-c phy thingy never fully worked in
> >> > the past (some for the never used dp output), so personally I don't
> >> > have
> >> > issues with going that route.
> >> > 
> >> >>  From a long term perspective (AKA how I'd write the next driver like
> >> >> 
> >> >> this) I personally lean towards to "tables in the driver, not in the
> >> >> device tree" but quite honestly I'm happy to take whatever direction
> >> >> the maintainers give.
> >> > 
> >> > It looks like we're in agreement here :-) . GRF stuff should not leak
> >> > into
> >> > the devicetree, as it causes endless headaches later. But I guess we'll
> >> > need to live with the ones that happened so far.
> >> 
> >> So, the first step is: move all the private property of tcphy to
> >> drivers/phy/rockchip/phy-rockchip-typec.c.
> >> Second step: new a member: uphy-dp-sel.
> >> In my mind, we should have discussed these properties before, and then I
> >> moved them all into DTS.
> > 
> > Actually, I was agreeing with Doug, that we probably don't need to rework
> > the type-c phy driver. As most properties for it are in the devicetree
> > right now we'll need to support them for backwards-compatiblity anyway.
> > 
> > And yes, there probably was discussion over dts vs. driver-table when the
> > type-c driver was introduced, but I either missed it or wasn't firm enough
> > back then ;-) .
> > 
> > Hence the "we'll need to live with it" for the type-c phy, but should not
> > do similar things in future drivers.
> 
> So I guess now we're just waiting for some agreement from Kishon that
> he's willing to land the PHY change?  Heiko: presumably you could
> apply the DP change to drm-misc?  ...or is there some other process
> needed there?

I was lagging behind a bit with the drm-misc account request but have
done so now. So once I got the hang of how drm-misc works and Kishon
has picked the phy-part I can most likely push the drm part (or Sandy,
depending on who is faster).

As for process, I don't think there is special care necessary. When
you get the intermediate case of phy-change but no drm-change
everything will just revert to how it works now anyway.


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

Re: [PATCH 0/2] Move scheduler out of AMDGPU

[Alex Deucher]

On Fri, Dec 1, 2017 at 10:55 AM, Christian König
 wrote:
> Am 01.12.2017 um 16:28 schrieb Lucas Stach:
>>
>> Hi all,
>>
>> so this is the first step to make the marvelous AMDGPU scheduler useable
>> for other drivers. I have a (mostly) working prototype of Etnaviv using
>> the scheduler, but those patches need to keep baking for a while.
>>
>> I'm sending this out as I want to avoid rebasing this change too much
>> and don't want to take people by surprise when the Etnaviv implementation
>> surfaces. Also this might need some coordination between AMDGPU and
>> Etnaviv, which might be good to get going now.
>>
>> Please speak up now if you have any objections or comments.
>
>
> Looks good to me, but question is what is this based upon?
>
> I strongly assume drm-next, so question is now if we have any patches inside
> amd branches we should apply before doing this.

We have a bunch of changes queued up which will go usptream for 4.16.
See amd-staging-drm-next:
https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next
which is a mirror of our main development branch or:
https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-4.16-wip
which is what is currently queued for 4.16.

Alex

>
> CCing Andrey as well cause he has some tasks assigned around the scheduler
> as well.
>
> Regards,
> Christian.
>
>
>>
>> Regards,
>> Lucas
>>
>> Lucas Stach (2):
>>drm: move amd_gpu_scheduler into common location
>>drm/sched: move fence slab handling to module init/exit
>>
>>   drivers/gpu/drm/Kconfig|   5 +
>>   drivers/gpu/drm/Makefile   |   1 +
>>   drivers/gpu/drm/amd/amdgpu/Makefile|   5 +-
>>   drivers/gpu/drm/amd/amdgpu/amdgpu.h|  16 +-
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c |   8 +-
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c|  38 +--
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  12 +-
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|   8 -
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c  |   4 +-
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_job.c|  22 +-
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c   |  14 +-
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h   |  12 +-
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c  |  20 +-
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_sched.h  |   2 +-
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c   |   6 +-
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c|   8 +-
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h|   4 +-
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c|   8 +-
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.h|   4 +-
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c|   8 +-
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_vce.h|   2 +-
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c|  14 +-
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h|   4 +-
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c |  10 +-
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h |   4 +-
>>   drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c  |   4 +-
>>   drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c  |   8 +-
>>   drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c  |   8 +-
>>   drivers/gpu/drm/amd/scheduler/gpu_scheduler.h  | 185 --
>>   drivers/gpu/drm/scheduler/Makefile |   4 +
>>   .../gpu/drm/{amd => }/scheduler/gpu_scheduler.c| 281
>> +++--
>>   drivers/gpu/drm/{amd => }/scheduler/sched_fence.c  | 122 +
>>   include/drm/gpu_scheduler.h| 171 +
>>   .../drm/gpu_scheduler_trace.h  |  14 +-
>>   34 files changed, 525 insertions(+), 511 deletions(-)
>>   delete mode 100644 drivers/gpu/drm/amd/scheduler/gpu_scheduler.h
>>   create mode 100644 drivers/gpu/drm/scheduler/Makefile
>>   rename drivers/gpu/drm/{amd => }/scheduler/gpu_scheduler.c (64%)
>>   rename drivers/gpu/drm/{amd => }/scheduler/sched_fence.c (58%)
>>   create mode 100644 include/drm/gpu_scheduler.h
>>   rename drivers/gpu/drm/amd/scheduler/gpu_sched_trace.h =>
>> include/drm/gpu_scheduler_trace.h (83%)
>>
>
> ___
> 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

[PATCH] drm: savely free connectors from connector_iter

[Daniel Vetter]

In

commit 613051dac40da1751ab269572766d3348d45a197
Author: Daniel Vetter 
Date:   Wed Dec 14 00:08:06 2016 +0100

drm: locking iterators for connector_list

we've went to extreme lengths to make sure connector iterations works
in any context, without introducing any additional locking context.
This worked, except for a small fumble in the implementation:

When we actually race with a concurrent connector unplug event, and
our temporary connector reference turns out to be the final one, then
everything breaks: We call the connector release function from
whatever context we happen to be in, which can be an irq/atomic
context. And connector freeing grabs all kinds of locks and stuff.

Fix this by creating a specially safe put function for connetor_iter,
which (in this rare case) punts the cleanup to a worker.

Reported-by: Ben Widawsky 
Cc: Ben Widawsky 
Fixes: 613051dac40d ("drm: locking iterators for connector_list")
Cc: Dave Airlie 
Cc: Chris Wilson 
Cc: Sean Paul 
Cc:  # v4.11+
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_connector.c   | 28 ++--
 drivers/gpu/drm/drm_mode_config.c |  2 ++
 include/drm/drm_connector.h   |  8 
 3 files changed, 36 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 25f4b2e9a44f..482014137953 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -152,6 +152,16 @@ static void drm_connector_free(struct kref *kref)
connector->funcs->destroy(connector);
 }
 
+static void drm_connector_free_work_fn(struct work_struct *work)
+{
+   struct drm_connector *connector =
+   container_of(work, struct drm_connector, free_work);
+   struct drm_device *dev = connector->dev;
+
+   drm_mode_object_unregister(dev, >base);
+   connector->funcs->destroy(connector);
+}
+
 /**
  * drm_connector_init - Init a preallocated connector
  * @dev: DRM device
@@ -181,6 +191,8 @@ int drm_connector_init(struct drm_device *dev,
if (ret)
return ret;
 
+   INIT_WORK(>free_work, drm_connector_free_work_fn);
+
connector->base.properties = >properties;
connector->dev = dev;
connector->funcs = funcs;
@@ -529,6 +541,18 @@ void drm_connector_list_iter_begin(struct drm_device *dev,
 }
 EXPORT_SYMBOL(drm_connector_list_iter_begin);
 
+/*
+ * Extra-safe connector put function that works in any context. Should only be
+ * used from the connector_iter functions, where we never really expect to
+ * actually release the connector when dropping our final reference.
+ */
+static void
+drm_connector_put_safe(struct drm_connector *conn)
+{
+   if (refcount_dec_and_test(>base.refcount.refcount))
+   schedule_work(>free_work);
+}
+
 /**
  * drm_connector_list_iter_next - return next connector
  * @iter: connectr_list iterator
@@ -561,7 +585,7 @@ drm_connector_list_iter_next(struct drm_connector_list_iter 
*iter)
spin_unlock_irqrestore(>connector_list_lock, flags);
 
if (old_conn)
-   drm_connector_put(old_conn);
+   drm_connector_put_safe(old_conn);
 
return iter->conn;
 }
@@ -580,7 +604,7 @@ void drm_connector_list_iter_end(struct 
drm_connector_list_iter *iter)
 {
iter->dev = NULL;
if (iter->conn)
-   drm_connector_put(iter->conn);
+   drm_connector_put_safe(iter->conn);
lock_release(_list_iter_dep_map, 0, _RET_IP_);
 }
 EXPORT_SYMBOL(drm_connector_list_iter_end);
diff --git a/drivers/gpu/drm/drm_mode_config.c 
b/drivers/gpu/drm/drm_mode_config.c
index 7623607c0f1e..346c19c6ce01 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -431,6 +431,8 @@ void drm_mode_config_cleanup(struct drm_device *dev)
drm_connector_put(connector);
}
drm_connector_list_iter_end(_iter);
+   /* connector_iter drops references in a work item. */
+   flush_scheduled_work();
if (WARN_ON(!list_empty(>mode_config.connector_list))) {
drm_connector_list_iter_begin(dev, _iter);
drm_for_each_connector_iter(connector, _iter)
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 66d6c99d15e5..c5c753a1be85 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -926,6 +926,14 @@ struct drm_connector {
uint8_t num_h_tile, num_v_tile;
uint8_t tile_h_loc, tile_v_loc;
uint16_t tile_h_size, tile_v_size;
+
+   /**
+* @free_work:
+*
+* Work used only by _connector_iter to be able to clean up a
+* connector from any context.
+*/
+   struct work_struct free_work;
 };
 
 #define obj_to_connector(x) container_of(x, struct 

Re: [PATCH] drm: amd: dc: don't use FP math when Kcov is enabled

[Harry Wentland]

On 2017-12-04 08:08 AM, Arnd Bergmann wrote:
> Building the DCN 1.0 Raven display driver with CONFIG_KCOV_INSTRUMENT_ALL=y
> and CONFIG_KCOV_ENABLE_COMPARISONS=y results in warnings about many functions
> that do a comparison of floating-point variables:
> 
> drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.o: In function 
> `dcn_bw_calc_rq_dlg_ttu':
> dcn_calcs.c:(.text+0x263): undefined reference to `__sanitizer_cov_trace_cmpf'
> drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.o: In function 
> `hack_force_pipe_split':
> dcn_calcs.c:(.text+0x155b): undefined reference to 
> `__sanitizer_cov_trace_cmpf'
> drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.o: In function 
> `dcn_find_dcfclk_suits_all':
> dcn_calcs.c:(.text+0x190e): undefined reference to 
> `__sanitizer_cov_trace_cmpf'
> drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.o: In function 
> `dcn_validate_bandwidth':
> dcn_calcs.c:(.text+0xe121): undefined reference to 
> `__sanitizer_cov_trace_cmpd'
> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_math.o: In function 
> `dcn_bw_mod':
> dcn_calc_math.c:(.text+0x22): undefined reference to 
> `__sanitizer_cov_trace_cmpf'
> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_math.o: In function 
> `dcn_bw_min2':
> dcn_calc_math.c:(.text+0xb2): undefined reference to 
> `__sanitizer_cov_trace_cmpf'
> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_math.o: In function 
> `dcn_bw_ceil2':
> dcn_calc_math.c:(.text+0x2a0): undefined reference to 
> `__sanitizer_cov_trace_cmpd'
> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_math.o: In function 
> `dcn_bw_max3':
> dcn_calc_math.c:(.text+0x325): undefined reference to 
> `__sanitizer_cov_trace_cmpf'
> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_math.o: In function 
> `dcn_bw_max5':
> dcn_calc_math.c:(.text+0x3c3): undefined reference to 
> `__sanitizer_cov_trace_cmpf'
> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_math.o: In function 
> `dcn_bw_log':
> dcn_calc_math.c:(.text+0x54e): undefined reference to 
> `__sanitizer_cov_trace_cmpd'
> dcn_calc_math.c:(.text+0x57c): undefined reference to 
> `__sanitizer_cov_trace_cmpd'
> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function 
> `scaler_settings_calculation':
> dcn_calc_auto.c:(.text+0x5c5): undefined reference to 
> `__sanitizer_cov_trace_cmpf'
> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function 
> `mode_support_and_system_configuration':
> dcn_calc_auto.c:(.text+0x137c): undefined reference to 
> `__sanitizer_cov_trace_cmpd'
> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function 
> `mode_support_and_system_configuration':
> dcn_calc_auto.c:(.text+0x9233): undefined reference to 
> `__sanitizer_cov_trace_cmpd'
> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function 
> `mode_support_and_system_configuration':
> dcn_calc_auto.c:(.text+0xb70f): undefined reference to 
> `__sanitizer_cov_trace_cmpd'
> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function 
> `mode_support_and_system_configuration':
> dcn_calc_auto.c:(.text+0x121fd): undefined reference to 
> `__sanitizer_cov_trace_cmpd'
> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function 
> `display_pipe_configuration':
> dcn_calc_auto.c:(.text+0x15a2f): undefined reference to 
> `__sanitizer_cov_trace_cmpd'
> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function 
> `dispclkdppclkdcfclk_deep_sleep_prefetch_parameters_watermarks_and_performance_calculation':
> dcn_calc_auto.c:(.text+0x17c2d): undefined reference to 
> `__sanitizer_cov_trace_cmpf'
> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function 
> `dispclkdppclkdcfclk_deep_sleep_prefetch_parameters_watermarks_and_performance_calculation':
> dcn_calc_auto.c:(.text+0x19362): undefined reference to 
> `__sanitizer_cov_trace_cmpd'
> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function 
> `dispclkdppclkdcfclk_deep_sleep_prefetch_parameters_watermarks_and_performance_calculation':
> dcn_calc_auto.c:(.text+0x25575): undefined reference to 
> `__sanitizer_cov_trace_cmpd'
> drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function 
> `dispclkdppclkdcfclk_deep_sleep_prefetch_parameters_watermarks_and_performance_calculation':
> dcn_calc_auto.c:(.text+0x27f33): undefined reference to 
> `__sanitizer_cov_trace_cmpd'
> drivers/gpu/drm/amd/display/dc/dml/display_rq_dlg_calc.o: In function 
> `get_refcyc_per_delivery':
> display_rq_dlg_calc.c:(.text+0xb5): undefined reference to 
> `__sanitizer_cov_trace_cmpd'
> drivers/gpu/drm/amd/display/dc/dml/display_rq_dlg_calc.o: In function 
> `calculate_ttu_cursor.isra.1':
> display_rq_dlg_calc.c:(.text+0x9f6): undefined reference to 
> `__sanitizer_cov_trace_cmpd'
> drivers/gpu/drm/amd/display/dc/dml/display_rq_dlg_calc.o: In function 
> `dml_rq_dlg_get_dlg_params':
> display_rq_dlg_calc.c:(.text+0x82cc): undefined reference to 
> `__sanitizer_cov_trace_cmpf'
> drivers/gpu/drm/amd/display/dc/dml/dml1_display_rq_dlg_calc.o: In function 
> 

Re: PROBLEM: Asus C201 video mode problems on HDMI hotplug (regression)

[Laurent Pinchart]

Hi Nick,

On Monday, 4 December 2017 21:30:01 EET Nick Bowler wrote:
> On 2017-12-04 21:06 +0200, Laurent Pinchart wrote:
> > As you reported that the PLL lock failure message is not printed, the
> > failure can only come from either the extra delay introduced by the
> > above loop, or from reading the HDMI_PHY_STAT0 register.
> > 
> > How many iterations of the for loop execute before the condition
> > becomes true?
> 
> Judging from the log posted elsethread (where I added extra printouts),
> it seems to consistently become true on the second iteration.
> 
> I will try to rule out read side effects by replacing the polling loop
> with an unconditional delay.

You're reading my mind :-)

-- 
Regards,

Laurent Pinchart

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

[radeon-alex:amd-staging-drm-next 151/500] 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:   762f01cfcaa042752cbcec9e9e5a67100ee7be11
commit: 0bd599b1f523598c05f13a4a562884e82a378c2c [151/500] 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 0bd599b1f523598c05f13a4a562884e82a378c2c
# 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

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

[Bug 103791] Tearing after screen wakeup/on

[bugzilla-daemon]

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

--- Comment #14 from denisgolo...@yandex.ru ---
Created attachment 135938
  --> https://bugs.freedesktop.org/attachment.cgi?id=135938=edit
dmesg with vblank debug

-- 
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: PROBLEM: Asus C201 video mode problems on HDMI hotplug (regression)

[Laurent Pinchart]

Hi Nick,

On Friday, 1 December 2017 02:11:46 EET Nick Bowler wrote:
> On 2017-11-27 22:30 -0500, Nick Bowler wrote:
> > A note about the test setup: I had to remove the test equipment so I
> > no longer have any information about the video mode from the sink side
> > (like in the photos).  Thus, with the current setup, I am using the
> > presense or absense of audio to determine whether the issue is present
> > or not.
> > 
> > The test procedure is: boot up, start music, then hotplug the hdmi four
> > times.  If sound is heard after all four connections, PASS; otherwise
> > FAIL.
> > 
> >  - I retested on 4.15-rc1 to confirm that the issue is still present (it
> >  is).
> >  
> >  - I applied the functional revert from earlier on top of 4.15-rc1 and the
> >problem is fixed.
> >  
> >  - Returning to 4.15-rc1 and applying [Laurent Pinchart's] patch --
> >the issue is present again (no change in behaviour compared to
> >4.15-rc1).
> 
> Another data point... the following patch appears sufficient to restore
> working behaviour.
> 
> Cheers,
>   Nick
> 
> ---
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 17 -
>  1 file changed, 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index
> bf14214fa464..3118fbd8433d 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -1101,8 +1101,6 @@ static void dw_hdmi_phy_power_off(struct dw_hdmi
> *hdmi) static int dw_hdmi_phy_power_on(struct dw_hdmi *hdmi)
>  {
>   const struct dw_hdmi_phy_data *phy = hdmi->phy.data;
> - unsigned int i;
> - u8 val;
> 
>   if (phy->gen == 1) {
>   dw_hdmi_phy_enable_powerdown(hdmi, false);
> @@ -1116,21 +1114,6 @@ static int dw_hdmi_phy_power_on(struct dw_hdmi *hdmi)
> dw_hdmi_phy_gen2_txpwron(hdmi, 1);
>   dw_hdmi_phy_gen2_pddq(hdmi, 0);
> 
> - /* Wait for PHY PLL lock */
> - for (i = 0; i < 5; ++i) {
> - val = hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_TX_PHY_LOCK;
> - if (val)
> - break;
> -
> - usleep_range(1000, 2000);
> - }
> -
> - if (!val) {
> - dev_err(hdmi->dev, "PHY PLL failed to lock\n");
> - return -ETIMEDOUT;
> - }
> -
> - dev_dbg(hdmi->dev, "PHY PLL locked %u iterations\n", i);

As you reported that the PLL lock failure message is not printed, the failure 
can only come from either the extra delay introduced by the above loop, or 
from reading the HDMI_PHY_STAT0 register.

How many iterations of the for loop execute before the condition becomes true 
?

>   return 0;
>  }

-- 
Regards,

Laurent Pinchart

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

[Bug 104082] amdgpu 0000:07:00.0: swiotlb buffer is full (sz: 2097152 bytes)

[bugzilla-daemon]

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

Bug ID: 104082
   Summary: amdgpu :07:00.0: swiotlb buffer is full (sz:
2097152 bytes)
   Product: DRI
   Version: XOrg git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: mikhail.v.gavri...@gmail.com

With latest AMD staging driver and Vega 56 I have a lot of messages about
swiotlb buffer is full:

[122422.348708] amdgpu :07:00.0: swiotlb buffer is full (sz: 2097152 bytes)
[122422.348713] swiotlb: coherent allocation failed for device :07:00.0
size=2097152
[122422.348717] CPU: 1 PID: 17546 Comm: gnome-shell Not tainted
4.14.0-rc3-amd-vega+ #7
[122422.348719] Hardware name: Gigabyte Technology Co., Ltd. Z87M-D3H/Z87M-D3H,
BIOS F11 08/12/2014
[122422.348721] Call Trace:
[122422.348728]  dump_stack+0x8e/0xd6
[122422.348733]  swiotlb_alloc_coherent+0xec/0x160
[122422.348739]  x86_swiotlb_alloc_coherent+0x43/0x50
[122422.348747]  ttm_dma_pool_get_pages+0x220/0x630 [ttm]
[122422.348755]  ttm_dma_populate+0x24c/0x330 [ttm]
[122422.348785]  amdgpu_ttm_tt_populate+0xc1/0xe0 [amdgpu]
[122422.348790]  ttm_tt_bind+0x28/0x60 [ttm]
[122422.348795]  ttm_bo_handle_move_mem+0x569/0x5b0 [ttm]
[122422.348800]  ? ttm_bo_mem_space+0x385/0x450 [ttm]
[122422.348807]  ttm_bo_validate+0x185/0x1a0 [ttm]
[122422.348813]  ? _raw_write_unlock+0x27/0x40
[122422.348819]  ttm_bo_init_reserved+0x38c/0x4f0 [ttm]
[122422.348843]  amdgpu_bo_do_create+0x209/0x540 [amdgpu]
[122422.348866]  ? amdgpu_fill_buffer+0x2f0/0x2f0 [amdgpu]
[122422.348892]  amdgpu_bo_create+0x50/0x2c0 [amdgpu]
[122422.348917]  amdgpu_gem_object_create+0x83/0x110 [amdgpu]
[122422.348943]  amdgpu_gem_create_ioctl+0x135/0x280 [amdgpu]
[122422.348967]  ? amdgpu_gem_object_close+0x210/0x210 [amdgpu]
[122422.348979]  drm_ioctl_kernel+0x5d/0xb0 [drm]
[122422.348988]  drm_ioctl+0x31b/0x3d0 [drm]
[122422.349010]  ? amdgpu_gem_object_close+0x210/0x210 [amdgpu]
[122422.349017]  ? trace_hardirqs_on+0xd/0x10
[122422.349040]  amdgpu_drm_ioctl+0x4f/0x90 [amdgpu]
[122422.349045]  do_vfs_ioctl+0xa6/0x6c0
[122422.349051]  SyS_ioctl+0x79/0x90
[122422.349055]  entry_SYSCALL_64_fastpath+0x1f/0xbe
[122422.349058] RIP: 0033:0x7f01c9d2adc7
[122422.349060] RSP: 002b:7ffd5ea6feb8 EFLAGS: 0246 ORIG_RAX:
0010
[122422.349063] RAX: ffda RBX: 56017d05df70 RCX:
7f01c9d2adc7
[122422.349066] RDX: 7ffd5ea6ff00 RSI: c0206440 RDI:
000c
[122422.349068] RBP: 7ffd5ea70de0 R08: 560179ae1b70 R09:
560179ae1b70
[122422.349070] R10: 0007 R11: 0246 R12:
0018
[122422.349072] R13: 7f00fef8aa00 R14: 0018 R15:
0900
[122423.894049] amdgpu :07:00.0: swiotlb buffer is full (sz: 2097152 bytes)
[122423.894055] swiotlb: coherent allocation failed for device :07:00.0
size=2097152
[122423.894058] CPU: 7 PID: 17546 Comm: gnome-shell Not tainted
4.14.0-rc3-amd-vega+ #7
[122423.894061] Hardware name: Gigabyte Technology Co., Ltd. Z87M-D3H/Z87M-D3H,
BIOS F11 08/12/2014
[122423.894063] Call Trace:
[122423.894071]  dump_stack+0x8e/0xd6
[122423.894077]  swiotlb_alloc_coherent+0xec/0x160
[122423.894083]  x86_swiotlb_alloc_coherent+0x43/0x50
[122423.894093]  ttm_dma_pool_get_pages+0x220/0x630 [ttm]
[122423.894103]  ttm_dma_populate+0x24c/0x330 [ttm]
[122423.894136]  amdgpu_ttm_tt_populate+0xc1/0xe0 [amdgpu]
[122423.894143]  ttm_tt_bind+0x28/0x60 [ttm]
[122423.894149]  ttm_bo_handle_move_mem+0x569/0x5b0 [ttm]
[122423.894154]  ? ttm_bo_mem_space+0x385/0x450 [ttm]
[122423.894163]  ttm_bo_validate+0x185/0x1a0 [ttm]
[122423.894169]  ? _raw_write_unlock+0x27/0x40
[122423.894176]  ttm_bo_init_reserved+0x38c/0x4f0 [ttm]
[122423.894208]  amdgpu_bo_do_create+0x209/0x540 [amdgpu]
[122423.894239]  ? amdgpu_fill_buffer+0x2f0/0x2f0 [amdgpu]
[122423.894269]  amdgpu_bo_create+0x50/0x2c0 [amdgpu]
[122423.894300]  amdgpu_gem_object_create+0x83/0x110 [amdgpu]
[122423.894330]  amdgpu_gem_create_ioctl+0x135/0x280 [amdgpu]
[122423.894358]  ? amdgpu_gem_object_close+0x210/0x210 [amdgpu]
[122423.894372]  drm_ioctl_kernel+0x5d/0xb0 [drm]
[122423.894384]  drm_ioctl+0x31b/0x3d0 [drm]
[122423.894408]  ? amdgpu_gem_object_close+0x210/0x210 [amdgpu]
[122423.894417]  ? trace_hardirqs_on+0xd/0x10
[122423.894443]  amdgpu_drm_ioctl+0x4f/0x90 [amdgpu]
[122423.894449]  do_vfs_ioctl+0xa6/0x6c0
[122423.894456]  SyS_ioctl+0x79/0x90
[122423.894462]  entry_SYSCALL_64_fastpath+0x1f/0xbe
[122423.894465] RIP: 0033:0x7f01c9d2adc7
[122423.894467] RSP: 002b:7ffd5ea6ff28 EFLAGS: 0246 ORIG_RAX:
0010
[122423.894471] RAX: ffda RBX: 7ffd5ea71460 RCX:
7f01c9d2adc7
[122423.894473] RDX: 7ffd5ea6ff70 RSI: c0206440 RDI:
000c
[122423.894476] RBP: 56017f08d6f0 R08: 560181fc1e40 

Re: [Intel-gfx] [PATCH] drm/i915: Mark expected switch fall-throughs

[Daniel Vetter]

On Mon, Dec 4, 2017 at 4:20 PM, Gustavo A. R. Silva
 wrote:
> Hi Joonas,
>
> Quoting Joonas Lahtinen :
>
>> On Mon, 2017-11-27 at 16:17 -0600, Gustavo A. R. Silva wrote:
>>>
>>> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
>>> where we are expecting to fall through.
>>
>>
>> I have to say I'm totally not sold on regexps matching comment
>> contents. Was something more explicit ever considered? Like:
>>
>> #define FALLTHROUGH __attribute__((fallthrough));
>>
>> With the appropriate version checks, of course.
>>
>
> One of the arguments is that comments lets us leverage the existing static
> analyzers.
>
> We've been discussing this during the last week, feel free to join the
> discussion:
>
> http://www.spinics.net/lists/kernel/msg2659908.html
> http://www.spinics.net/lists/kernel/msg2659906.html

If we go with existing rules, then either pls patch coding style, or
be a bit more liberal in what you accept. E.g. fallthrough vs fall
through seems a bit a bikeshed (and will be an endless source of work
for you).

I'd also claim that "this shouldn't happen, dump a backtrace and hope
for the best" style macros like i915's MISSING_CASE or WARN_ON (as the
only thing) should count as an auto-fallthrough annotation.

From a quick look, that would cover everything in your patch.
-Daniel

>
> Thanks!
> --
> Gustavo A. R. Silva
>
>
>
>
>
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: xf86-video-armada via UDL [was: Re: UDL's fbdev doesn't work for user-space apps]

[Emil Velikov]

On 4 December 2017 at 14:02, Jose Abreu  wrote:
> On 04-12-2017 13:16, Alexey Brodkin wrote:
>> Option  "kmsdev" "/dev/dri/card1"
>
> Which drm driver uses /dev/dri/card0? I'm seing drmOpen code and
> if you don't specify the busID it will fallback for the first
> card that matches "armada-drm" or "imx-drm" or "udl".
>
As you've noticed, drmOpen can give you some 'nice' side-effects.
I'd recommend getting a list of devices with drmGetDevice{,s}2 and
applying $heuristics to filter the device you want.

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

Re: xf86-video-armada via UDL [was: Re: UDL's fbdev doesn't work for user-space apps]

[Jose Abreu]

On 04-12-2017 16:00, Alexey Brodkin wrote:
> [30.763] (II) armada(0): etnaviv: Xv: using YUY2 format intermediate YUV 
> target
>

I'm wondering if this means that target format for UDL is YUV ...

But anyway, I revisited your first email and noticed that you
said kmscube runs fine. Is this using etnaviv as renderer? And
you also said X is claiming the screen but nothing appears ...
which X client are you using to test this?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH][next] drm/i915/gvt: fix off-by-one comparison of ring_id

[Colin King]

From: Colin Ian King 

The ring_id maximum boundary is being compared using the > operator
instead of >=, leading to an off-by-one error and an out of bounds
write into array vgpu->hws_pga[].  Fix this by simply using the
correct comparison operator. Also re-work another comparison that
uses the comparison > I915_NUM_ENGINES - 1 to use the >= idiom using
to keep this consistent in this code.

Detected by CoverityScan, CID#1462404 ("Out-of-bounds write")

Fixes: a2ae95af9646 ("drm/i915/gvt: update CSB and CSB write pointer in virtual 
HWSP")
Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/i915/gvt/handlers.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/handlers.c 
b/drivers/gpu/drm/i915/gvt/handlers.c
index 7354ed816f92..c982867e7c2b 100644
--- a/drivers/gpu/drm/i915/gvt/handlers.c
+++ b/drivers/gpu/drm/i915/gvt/handlers.c
@@ -1398,7 +1398,7 @@ static int hws_pga_write(struct intel_vgpu *vgpu, 
unsigned int offset,
 * update the VM CSB status correctly. Here listed registers can
 * support BDW, SKL or other platforms with same HWSP registers.
 */
-   if (unlikely(ring_id < 0 || ring_id > I915_NUM_ENGINES)) {
+   if (unlikely(ring_id < 0 || ring_id >= I915_NUM_ENGINES)) {
gvt_vgpu_err("VM(%d) access unknown hardware status page 
register:0x%x\n",
 vgpu->id, offset);
return -EINVAL;
@@ -1473,7 +1473,7 @@ static int elsp_mmio_write(struct intel_vgpu *vgpu, 
unsigned int offset,
u32 data = *(u32 *)p_data;
int ret = 0;
 
-   if (WARN_ON(ring_id < 0 || ring_id > I915_NUM_ENGINES - 1))
+   if (WARN_ON(ring_id < 0 || ring_id >= I915_NUM_ENGINES))
return -EINVAL;
 
execlist = >submission.execlist[ring_id];
-- 
2.14.1

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

Re: [PATCH] drm: msm: avoid false-positive -Wmaybe-uninitialized warning

[Arnd Bergmann]

On Mon, Dec 4, 2017 at 5:36 PM, Laurent Pinchart
 wrote:
> Hi Arnd,
>
> Thank you for the patch.
>
> On Monday, 4 December 2017 16:44:23 EET Arnd Bergmann wrote:
>> gcc-8 -fsanitize-coverage=trace-pc produces a false-positive warning:
>>
>> drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c: In function
>> 'mdp5_plane_mode_set.isra.8':
>> drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c:1053:3: error: 'crtc_x_r' may be
>> used uninitialized in this function [-Werror=maybe-uninitialized]
>>
>> It's relatively clear from reading the source that this cannot happen,
>> and older compilers get it right. This rearranges the code remove
>> the two affected variables, which reliably avoids the problem.
>>
>> Signed-off-by: Arnd Bergmann 
>
> The patch looks good to me, so
>
> Acked-by: Laurent Pinchart 
>
> However I think it would also be useful to file a bug report for gcc,
> especially if older versions got this right.

I was rather close to it, and even spent time on a reduced test case
with "creduce", which came down to

int drm_rect_width_r_0, calc_phase_step_src, calc_scalex_steps_ret,
calc_scalex_steps_dest, calc_scaley_steps_ret, calc_scaley_steps_dest,
mdp5_plane_mode_set___trans_tmp_2;
struct mdp5_hw_pipe {
  int caps;
} * mdp5_plane_mode_set_right_hwpipe;
int fn1(int p1) {
  if (calc_phase_step_src || p1 == 0)
return 2;
  if (calc_phase_step_src > p1)
return 5;
  return 0;
}
int fn2() {
  struct mdp5_hw_pipe hwpipe = hwpipe;
  int src_x_r;
  if (mdp5_plane_mode_set_right_hwpipe)
src_x_r = drm_rect_width_r_0;
  calc_scalex_steps_ret = fn1(calc_scalex_steps_dest);
  if (calc_scalex_steps_ret)
return calc_scalex_steps_ret;
  calc_scaley_steps_ret = fn1(calc_scaley_steps_dest);
  if (calc_scaley_steps_ret)
return calc_scaley_steps_ret;
  if (hwpipe.caps)
if (mdp5_plane_mode_set_right_hwpipe)
  mdp5_plane_mode_set___trans_tmp_2 = src_x_r;
  return calc_scaley_steps_ret;
}

This is still not something that is "obviously" wrong, it seems rather
that gcc can't keep track of enough state at the same time, which
is a fundamental problem but also a bit unpredictable.

I've seen many false-positive (and also false-negative) -Wmaybe-uninitialized
warnings that are likely easier to fix than this particular one, so I
ended up not reporting it.

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

Re: [PATCH] arm64: dts: exynos: increase bus frequency for MHL chip

[Krzysztof Kozlowski]

On Fri, Dec 01, 2017 at 12:33:51PM +0100, Andrzej Hajda wrote:
> sii8620 supports 1MHz clock, it allows faster transmissions and according
> to extensive tests allows to mitigate some obscure bugs in I2C client
> logic of the chip.
> 
> Signed-off-by: Andrzej Hajda 
> ---
>  arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 1 +
>  1 file changed, 1 insertion(+)
> 

Thanks, applied.

Best regards,
Krzysztof

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

[PATCH][next] drm/i915/gvt: Add missing breaks in switch statement

[Colin King]

From: Colin Ian King 

The switch statement is missing breaks for the cases of
GVT_FAILSAFE_INSUFFICIENT_RESOURCE and GVT_FAILSAFE_GUEST_ERR. Add them
in.

Detected by CoverityScan, CID#1462416 ("Missing break in switch")

Fixes: e011c6ce2b4f ("drm/i915/gvt: Add VM healthy check for workload_thread")
Fixes: a33fc7a0482a ("drm/i915/gvt: enter failsafe mode when guest requires 
more resources")

Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/i915/gvt/handlers.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/gvt/handlers.c 
b/drivers/gpu/drm/i915/gvt/handlers.c
index 94fc04210bac..7354ed816f92 100644
--- a/drivers/gpu/drm/i915/gvt/handlers.c
+++ b/drivers/gpu/drm/i915/gvt/handlers.c
@@ -174,8 +174,10 @@ void enter_failsafe_mode(struct intel_vgpu *vgpu, int 
reason)
break;
case GVT_FAILSAFE_INSUFFICIENT_RESOURCE:
pr_err("Graphics resource is not enough for the guest\n");
+   break;
case GVT_FAILSAFE_GUEST_ERR:
pr_err("GVT Internal error  for the guest\n");
+   break;
default:
break;
}
-- 
2.14.1

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

[GIT PULL FOR v4.16] R-Car DU changes

[Laurent Pinchart]

Hi Dave,

The following changes since commit ca797d29cd63e7b71b4eea29aff3b1cefd1ecb59:

  Merge tag 'drm-intel-next-2017-11-17-1' of git://anongit.freedesktop.org/
drm/drm-intel into drm-next (2017-12-04 10:56:53 +1000)

are available in the git repository at:

  git://linuxtv.org/pinchartl/media.git drm/next/du

for you to fetch changes up to 401712e035c699d569dbd37024f4b21dc76cc870:

  drm: rcar-du: Clip planes to screen boundaries (2017-12-04 18:38:31 +0200)

The series contains one patch that touches the V4L2 VSP driver. Mauro has 
acked it for merge through your tree, it doesn't conflict with anything 
scheduled for merge in v4.16 through Mauro's tree.


Fabrizio Castro (3):
  dt-bindings: display: rcar-du: Document R8A774[35] DU
  drm: rcar-du: Add R8A7743 support
  drm: rcar-du: Add R8A7745 support

Kieran Bingham (2):
  drm: rcar-du: Implement system suspend/resume support
  drm: rcar-du: Remove unused CRTC suspend/resume functions

Laurent Pinchart (4):
  drm: rcar-du: Don't set connector DPMS property
  v4l: vsp1: Start and stop DRM pipeline independently of planes
  drm: rcar-du: Share plane atomic check code between Gen2 and Gen3
  drm: rcar-du: Clip planes to screen boundaries

 .../devicetree/bindings/display/renesas,du.txt  | 30 +-
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c  | 38 +
 drivers/gpu/drm/rcar-du/rcar_du_drv.c   | 62 +++-
 drivers/gpu/drm/rcar-du/rcar_du_drv.h   |  1 +
 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c   |  4 --
 drivers/gpu/drm/rcar-du/rcar_du_plane.c | 75 
 drivers/gpu/drm/rcar-du/rcar_du_plane.h |  4 ++
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c   | 64 ++--
 drivers/media/platform/vsp1/vsp1_drm.c  | 37 
 9 files changed, 187 insertions(+), 128 deletions(-)

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH v4] arm64: dts: rockchip: update mipi cells for RK3399

[Laurent Pinchart]

Hi Heiko,

On Monday, 4 December 2017 15:46:32 EET Heiko Stuebner wrote:
> Am Montag, 4. Dezember 2017, 15:22:07 CET schrieb Laurent Pinchart:
> > On Wednesday, 29 November 2017 20:47:55 EET Brian Norris wrote:
> > > From: Nickey Yang 
> > > 
> > > We might include additional ports in derivative device trees, so the
> > > 'port' node should have an address, and the parent 'ports' node needs
> > > /#{addres,size}-cells.
> > > 
> > > v4:
> > >  * keep #{address,size}-cells in both 'ports' and 'port@0' nodes
> > >  * separate from the rest of the series, since this is mostly
> > >  
> > >independent of the driver refactoring
> > > 
> > > Signed-off-by: Nickey Yang 
> > > Signed-off-by: Brian Norris 
> > 
> > Reviewed-by: Laurent Pinchart 
> 
> As I hadn't pushed that one yet, I've amended it with your Review-tag :-)

Thank you :-)

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH] drm: msm: avoid false-positive -Wmaybe-uninitialized warning

[Laurent Pinchart]

Hi Arnd,

Thank you for the patch.

On Monday, 4 December 2017 16:44:23 EET Arnd Bergmann wrote:
> gcc-8 -fsanitize-coverage=trace-pc produces a false-positive warning:
> 
> drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c: In function
> 'mdp5_plane_mode_set.isra.8':
> drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c:1053:3: error: 'crtc_x_r' may be
> used uninitialized in this function [-Werror=maybe-uninitialized]
> 
> It's relatively clear from reading the source that this cannot happen,
> and older compilers get it right. This rearranges the code remove
> the two affected variables, which reliably avoids the problem.
> 
> Signed-off-by: Arnd Bergmann 

The patch looks good to me, so

Acked-by: Laurent Pinchart 

However I think it would also be useful to file a bug report for gcc, 
especially if older versions got this right.

> ---
>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 9 ++---
>  1 file changed, 2 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c index
> be50445f9901..c50449882037 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
> @@ -964,8 +964,6 @@ static int mdp5_plane_mode_set(struct drm_plane *plane,
>   uint32_t src_x, src_y;
>   uint32_t src_w, src_h;
>   uint32_t src_img_w, src_img_h;
> - uint32_t src_x_r;
> - int crtc_x_r;
>   int ret;
> 
>   nplanes = fb->format->num_planes;
> @@ -1010,9 +1008,6 @@ static int mdp5_plane_mode_set(struct drm_plane
> *plane, crtc_w /= 2;
>   src_w /= 2;
>   src_img_w /= 2;
> -
> - crtc_x_r = crtc_x + crtc_w;
> - src_x_r = src_x + src_w;
>   }
> 
>   ret = calc_scalex_steps(plane, pix_format, src_w, crtc_w, step.x);
> @@ -1052,9 +1047,9 @@ static int mdp5_plane_mode_set(struct drm_plane
> *plane, if (right_hwpipe)
>   mdp5_hwpipe_mode_set(mdp5_kms, right_hwpipe, fb, , ,
>config, hdecm, vdecm, hflip, vflip,
> -  crtc_x_r, crtc_y, crtc_w, crtc_h,
> +  crtc_x + crtc_w, crtc_y, crtc_w, crtc_h,
>src_img_w, src_img_h,
> -  src_x_r, src_y, src_w, src_h);
> +  src_x + src_w, src_y, src_w, src_h);
> 
>   plane->fb = fb;

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH 1/2] drm/ttm: swap consecutive allocated cached pages v3

[Michel Dänzer]

On 2017-12-04 01:46 PM, Christian König wrote:
> When we detect consecutive allocation of pages swap them to avoid
> accidentally freeing them as huge page.
> 
> v2: use swap
> v3: check if it's really the first allocated page
> 
> Signed-off-by: Christian König 
> ---
>  drivers/gpu/drm/ttm/ttm_page_alloc.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
> b/drivers/gpu/drm/ttm/ttm_page_alloc.c
> index c82d94cbbabc..7c4d4edce0ba 100644
> --- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
> +++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
> @@ -875,7 +875,7 @@ static int ttm_get_pages(struct page **pages, unsigned 
> npages, int flags,
>  #endif
>   struct list_head plist;
>   struct page *p = NULL;
> - unsigned count;
> + unsigned count, first;
>   int r;
>  
>   /* No pool for cached pages */
> @@ -914,6 +914,7 @@ static int ttm_get_pages(struct page **pages, unsigned 
> npages, int flags,
>   }
>  #endif
>  
> + first = i;
>   while (npages) {
>   p = alloc_page(gfp_flags);
>   if (!p) {
> @@ -921,6 +922,10 @@ static int ttm_get_pages(struct page **pages, unsigned 
> npages, int flags,
>   return -ENOMEM;
>   }
>  
> + /* Swap the pages if we detect consecutive order */
> + if (i > first && pages[i - 1] == p - 1)
> + swap(p, pages[i - 1]);
> +
>   pages[i++] = p;
>   --npages;
>   }
> 

Both patches are

Reviewed-by: Michel Dänzer 


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/4] Move DP phy switch to PHY driver

[Doug Anderson]

Hi,

On Sun, Dec 3, 2017 at 11:46 PM, Heiko Stübner  wrote:
> Hi Chris,
>
> Am Montag, 4. Dezember 2017, 10:47:08 CET schrieb Chris Zhong:
>> On 2017年12月02日 05:58, Heiko Stuebner wrote:
>> > Am Freitag, 1. Dezember 2017, 13:42:46 CET schrieb Doug Anderson:
>> >> Hi,
>> >>
>> >> On Wed, Nov 29, 2017 at 6:27 PM, Chris Zhong  wrote:
>> >>> Hi Doug
>> >>>
>> >>> Thank you for mentioning this patch.
>> >>>
>> >>> I think the focus of the discussion is: can we put the grf control bit
>> >>> to
>> >>> dts.
>> >>>
>> >>> The RK3399 has 2 Type-C phy, but only one DP controller, this
>> >>> "uphy_dp_sel"
>> >>>
>> >>> can help to switch these 2 phy. So I think this bit can be considered as
>> >>> a
>> >>> part of
>> >>>
>> >>> Type-C phy, these 2 phy have different bits, just similar to other bits
>> >>> (such as "pipe-status").
>> >>>
>> >>> Put them to DTS file might be a accepted practice.
>> >>
>> >> I guess the first step would be finding the person to make a decision.
>> >> Is that Heiko?  Olof?  Kishon?  Rob?.  As I see it there are a few
>> >> options:
>> >>
>> >> 1. Land this series as-is.  This makes the new bit work just like all
>> >> the other ones next to it.  If anyone happens to try to use an old
>> >> device tree on a new kernel they'll break.  Seems rather unlikely
>> >> given that the whole type C PHY is not really fully functional
>> >> upstream, but technically this is a no-no from a device tree
>> >> perspective.
>> >>
>> >> 2. Change the series to make this property optional.  If it's not
>> >> there then the code behaves like it always did.  This would address
>> >> the "compatibility" problem but likely wouldn't actually help any real
>> >> people, and it would be extra work.
>> >>
>> >> 3. Redo the driver to deprecate all the old offsets / bits and just
>> >> put the table in the driver, keyed off the compatible string and base
>> >> address if the IO memory.
>> >>
>> >>
>> >> I can't make this decision.  It's up to those folks who would be
>> >> landing the patch and I'd be happy with any of them.  What I'm less
>> >> happy with, however, is the indecision preventing forward progress.
>> >> We should pick one of the above things and land it.  My own personal
>> >> bias is #1: just land the series.  No real people will be hurt and
>> >> it's just adding another property that matches the ones next to it.
>> >
>> > I'd second that #1 . That whole type-c phy thingy never fully worked in
>> > the past (some for the never used dp output), so personally I don't have
>> > issues with going that route.
>> >
>> >>  From a long term perspective (AKA how I'd write the next driver like
>> >>
>> >> this) I personally lean towards to "tables in the driver, not in the
>> >> device tree" but quite honestly I'm happy to take whatever direction
>> >> the maintainers give.
>> >
>> > It looks like we're in agreement here :-) . GRF stuff should not leak into
>> > the devicetree, as it causes endless headaches later. But I guess we'll
>> > need to live with the ones that happened so far.
>>
>> So, the first step is: move all the private property of tcphy to
>> drivers/phy/rockchip/phy-rockchip-typec.c.
>> Second step: new a member: uphy-dp-sel.
>> In my mind, we should have discussed these properties before, and then I
>> moved them all into DTS.
>
> Actually, I was agreeing with Doug, that we probably don't need to rework the
> type-c phy driver. As most properties for it are in the devicetree right now
> we'll need to support them for backwards-compatiblity anyway.
>
> And yes, there probably was discussion over dts vs. driver-table when the
> type-c driver was introduced, but I either missed it or wasn't firm enough
> back then ;-) .
>
> Hence the "we'll need to live with it" for the type-c phy, but should not
> do similar things in future drivers.

So I guess now we're just waiting for some agreement from Kishon that
he's willing to land the PHY change?  Heiko: presumably you could
apply the DP change to drm-misc?  ...or is there some other process
needed there?

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

Re: xf86-video-armada via UDL [was: Re: UDL's fbdev doesn't work for user-space apps]

[Jose Abreu]

On 04-12-2017 14:53, Alexey Brodkin wrote:
> Full log you may find below.

Sorry but I meant /var/log/Xorg.0.log file.

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

[PATCH v6 4/5] drm/i915: expose engine availability through sysfs

[Lionel Landwerlin]

This enables userspace to discover the engines available on the GPU.
Here is the layout on a Skylake GT4:

/sys/devices/pci:00/:00:02.0/drm/card0/gt/
└── engines
├── bcs
│   └── 0
│   ├── capabilities
│   ├── class
│   ├── id
│   └── instance
├── rcs
│   └── 0
│   ├── capabilities
│   ├── class
│   ├── id
│   └── instance
├── vcs
│   ├── 0
│   │   ├── capabilities
│   │   │   └── hevc
│   │   ├── class
│   │   ├── id
│   │   └── instance
│   └── 1
│   ├── capabilities
│   ├── class
│   ├── id
│   └── instance
└── vecs
└── 0
├── capabilities
├── class
├── id
└── instance

Instance is the instance number of the engine for a particular class :
$ cat 
/sys/devices/pci\:00/\:00\:02.0/drm/card0/gt/engines/bcs/0/instance
0

Id is a global id used from submitting commands from userspace through execbuf :
$ cat /sys/devices/pci\:00/\:00\:02.0/drm/card0/gt/engines/bcs/0/id
3

Class maps to enum drm_i915_gem_engine_class in i915_drm.h :
$ cat /sys/devices/pci\:00/\:00\:02.0/drm/card0/gt/engines/bcs/0/class
1

Further capabilities can be added later as attributes of each engine.

v2: Add capabilities sub directory (Tvrtko)
Move engines directory to drm/card/gt (Chris)

v3: Move engines to drm/card/gt/engines/ (Tvrtko)
Add instance attribute to engines (Tvrtko)

v4: Fix dev_priv->gt_topology.engines_classes_kobj size (Lionel)

Signed-off-by: Lionel Landwerlin 
---
 drivers/gpu/drm/i915/i915_drv.h |   6 ++
 drivers/gpu/drm/i915/i915_sysfs.c   | 178 
 drivers/gpu/drm/i915/intel_engine_cs.c  |  12 +++
 drivers/gpu/drm/i915/intel_ringbuffer.h |   4 +
 4 files changed, 200 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0a8e8a3772e5..893ecb0d4639 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2731,6 +2731,12 @@ struct drm_i915_private {
} oa;
} perf;
 
+   struct {
+   struct kobject gt_kobj;
+   struct kobject engines_kobj;
+   struct kobject engines_classes_kobjs[MAX_ENGINE_CLASS + 1];
+   } gt_topology;
+
/* Abstract the submission mechanism (legacy ringbuffer or execlists) 
away */
struct {
void (*resume)(struct drm_i915_private *);
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c 
b/drivers/gpu/drm/i915/i915_sysfs.c
index c74a20b80182..d8ec8ec51cca 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -570,6 +570,178 @@ static void i915_setup_error_capture(struct device *kdev) 
{}
 static void i915_teardown_error_capture(struct device *kdev) {}
 #endif
 
+static struct attribute engine_class_attr = {
+   .name = "class",
+   .mode = 0444,
+};
+
+static struct attribute engine_id_attr = {
+   .name = "id",
+   .mode = 0444,
+};
+
+static struct attribute engine_instance_attr = {
+   .name = "instance",
+   .mode = 0444,
+};
+
+static ssize_t
+show_engine_attr(struct kobject *kobj, struct attribute *attr, char *buf)
+{
+   struct intel_engine_cs *engine =
+   container_of(kobj, struct intel_engine_cs, instance_kobj);
+
+   if (attr == _class_attr)
+   return sprintf(buf, "%hhu\n", engine->uabi_class);
+   if (attr == _id_attr)
+   return sprintf(buf, "%hhu\n", engine->uabi_id);
+   if (attr == _instance_attr)
+   return sprintf(buf, "%hhu\n", engine->instance);
+   return sprintf(buf, "\n");
+}
+
+static const struct sysfs_ops engine_ops = {
+   .show = show_engine_attr,
+};
+
+static struct kobj_type engine_type = {
+   .sysfs_ops = _ops,
+};
+
+static struct attribute engine_capability_hevc_attr = {
+   .name = "hevc",
+   .mode = 0444,
+};
+
+static ssize_t
+show_engine_capabilities_attr(struct kobject *kobj, struct attribute *attr, 
char *buf)
+{
+   struct intel_engine_cs *engine =
+   container_of(kobj, struct intel_engine_cs, capabilities_kobj);
+
+   if (attr == _capability_hevc_attr)
+   return sprintf(buf, "%i\n", INTEL_GEN(engine->i915) >= 8);
+   return sprintf(buf, "\n");
+}
+
+static const struct sysfs_ops engine_capabilities_ops = {
+   .show = show_engine_capabilities_attr,
+};
+
+static struct kobj_type engine_capabilities_type = {
+   .sysfs_ops = _capabilities_ops,
+};
+
+static int i915_setup_engines_sysfs(struct drm_i915_private *dev_priv,
+   struct kobject *gt_kobj)
+{
+   struct intel_engine_cs *engine_for_class, *engine;
+   enum intel_engine_id id_for_class, id;
+   struct kobject *engines_kobj = _priv->gt_topology.engines_kobj;
+   bool registred[MAX_ENGINE_CLASS 

[PATCH v6 5/5] drm/i915: expose EU topology through sysfs

[Lionel Landwerlin]

With the introduction of asymetric slices in CNL, we cannot rely on
the previous SUBSLICE_MASK getparam. Here we introduce a more detailed
way of querying the Gen's GPU topology that doesn't aggregate numbers.

This is essential for monitoring parts of the GPU with the OA unit,
because signals need to be accounted properly based on whether part of
the GPU has been fused off. The current aggregated numbers like
EU_TOTAL do not gives us sufficient information.

Here is the sysfs layout on a Skylake GT4 :

/sys/devices/pci:00/:00:02.0/drm/card0/gt/engines/rcs/topology/
├── max_eus_per_subslice
├── max_slices
├── max_subslices_per_slice
├── slice0
│   ├── subslice0
│   │   └── eus_enabled_mask
│   ├── subslice1
│   │   └── eus_enabled_mask
│   ├── subslice2
│   │   └── eus_enabled_mask
│   ├── subslice3
│   │   └── eus_enabled_mask
│   └── subslices_enabled_mask
├── slice1
│   ├── subslice0
│   │   └── eus_enabled_mask
│   ├── subslice1
│   │   └── eus_enabled_mask
│   ├── subslice2
│   │   └── eus_enabled_mask
│   ├── subslice3
│   │   └── eus_enabled_mask
│   └── subslices_enabled_mask
├── slice2
│   ├── subslice0
│   │   └── eus_enabled_mask
│   ├── subslice1
│   │   └── eus_enabled_mask
│   ├── subslice2
│   │   └── eus_enabled_mask
│   ├── subslice3
│   │   └── eus_enabled_mask
│   └── subslices_enabled_mask
└── slices_enabled_mask

Each enabled_mask file gives us a mask of the enabled units :

$ cat 
/sys/devices/pci\:00/\:00\:02.0/drm/card0/gt/engines/rcs/topology/slices_enabled_mask
0x7

$ cat 
/sys/devices/pci\:00/\:00\:02.0/drm/card0/gt/engines/rcs/topology/slice2/subslice1/eus_enabled_mask
0xff

max_eus_per_subslice/max_slices/max_subslices_per_slice are useful
numbers for userspace to build up a n-dimensional representation of
the device so that it can allocated upfront and filled up while
reading through each of the slices/subslices.

v2: Move topology below rcs engine (Chris)
Add max_eus_per_subslice/max_slices/max_subslices_per_slice (Lionel)

v3: Rename enabled_mask (Lionel)

v4: Move slices to drm/card/gt/rcs/topology (Tvrtko)

Signed-off-by: Lionel Landwerlin 
---
 drivers/gpu/drm/i915/i915_drv.h   |  27 +
 drivers/gpu/drm/i915/i915_sysfs.c | 208 ++
 2 files changed, 235 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 893ecb0d4639..fbdfd59ed1bd 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2260,6 +2260,24 @@ struct intel_cdclk_state {
u8 voltage_level;
 };
 
+struct intel_topology_kobject {
+   struct kobject kobj;
+   struct drm_i915_private *dev_priv;
+};
+
+struct intel_slice_kobject {
+   struct kobject kobj;
+   struct drm_i915_private *dev_priv;
+   u8 slice_index;
+};
+
+struct intel_subslice_kobject {
+   struct kobject kobj;
+   struct drm_i915_private *dev_priv;
+   u8 slice_index;
+   u8 subslice_index;
+};
+
 struct drm_i915_private {
struct drm_device drm;
 
@@ -2735,6 +2753,15 @@ struct drm_i915_private {
struct kobject gt_kobj;
struct kobject engines_kobj;
struct kobject engines_classes_kobjs[MAX_ENGINE_CLASS + 1];
+   struct kobject topology_kobj;
+
+   struct sysfs_slice {
+   struct intel_slice_kobject kobj;
+
+   struct sysfs_subslice {
+   struct intel_subslice_kobject kobj;
+   } subslices[GEN_MAX_SUBSLICES];
+   } slices[GEN_MAX_SLICES];
} gt_topology;
 
/* Abstract the submission mechanism (legacy ringbuffer or execlists) 
away */
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c 
b/drivers/gpu/drm/i915/i915_sysfs.c
index d8ec8ec51cca..b277338ab3fb 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -570,6 +570,205 @@ static void i915_setup_error_capture(struct device *kdev) 
{}
 static void i915_teardown_error_capture(struct device *kdev) {}
 #endif
 
+static struct attribute slices_enabled_mask_attr = {
+   .name = "slices_enabled_mask",
+   .mode = 0444,
+};
+
+static struct attribute subslices_enabled_mask_attr = {
+   .name = "subslices_enabled_mask",
+   .mode = 0444,
+};
+
+static struct attribute eus_enabled_mask_attr = {
+   .name = "eus_enabled_mask",
+   .mode = 0444,
+};
+
+static struct attribute max_slices_attr = {
+   .name = "max_slices",
+   .mode = 0444,
+};
+
+static struct attribute max_subslices_per_slice_attr = {
+   .name = "max_subslices_per_slice",
+   .mode = 0444,
+};
+
+static struct attribute max_eus_per_subslice_attr = {
+   .name = "max_eus_per_subslice",
+   .mode = 0444,
+};
+
+static ssize_t
+show_topology_attr(struct kobject *kobj, struct attribute *attr, char *buf)
+{
+   struct drm_i915_private *dev_priv =
+   

[PATCH v6 3/5] drm/i915/debugfs: reuse max slice/subslices already stored in sseu

[Lionel Landwerlin]

Now that we have that information in topology fields, let's just reused it.

Signed-off-by: Lionel Landwerlin 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 26 ++
 1 file changed, 10 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index ef091a2a6b12..961c5969b223 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4355,11 +4355,11 @@ static void gen10_sseu_device_status(struct 
drm_i915_private *dev_priv,
 struct sseu_dev_info *sseu)
 {
const struct intel_device_info *info = INTEL_INFO(dev_priv);
-   int s_max = 6, ss_max = 4;
int s, ss;
-   u32 s_reg[s_max], eu_reg[2 * s_max], eu_mask[2];
+   u32 s_reg[info->sseu.max_slices],
+   eu_reg[2 * info->sseu.max_subslices], eu_mask[2];
 
-   for (s = 0; s < s_max; s++) {
+   for (s = 0; s < info->sseu.max_slices; s++) {
/*
 * FIXME: Valid SS Mask respects the spec and read
 * only valid bits for those registers, excluding reserverd
@@ -4381,7 +4381,7 @@ static void gen10_sseu_device_status(struct 
drm_i915_private *dev_priv,
 GEN9_PGCTL_SSB_EU210_ACK |
 GEN9_PGCTL_SSB_EU311_ACK;
 
-   for (s = 0; s < s_max; s++) {
+   for (s = 0; s < info->sseu.max_slices; s++) {
if ((s_reg[s] & GEN9_PGCTL_SLICE_ACK) == 0)
/* skip disabled slice */
continue;
@@ -4389,7 +4389,7 @@ static void gen10_sseu_device_status(struct 
drm_i915_private *dev_priv,
sseu->slice_mask |= BIT(s);
sseu->subslices_mask[s] = info->sseu.subslices_mask[s];
 
-   for (ss = 0; ss < ss_max; ss++) {
+   for (ss = 0; ss < info->sseu.max_subslices; ss++) {
unsigned int eu_cnt;
 
if (!(s_reg[s] & (GEN9_PGCTL_SS_ACK(ss
@@ -4409,17 +4409,11 @@ static void gen10_sseu_device_status(struct 
drm_i915_private *dev_priv,
 static void gen9_sseu_device_status(struct drm_i915_private *dev_priv,
struct sseu_dev_info *sseu)
 {
-   int s_max = 3, ss_max = 4;
+   const struct intel_device_info *info = INTEL_INFO(dev_priv);
int s, ss;
-   u32 s_reg[s_max], eu_reg[2*s_max], eu_mask[2];
-
-   /* BXT has a single slice and at most 3 subslices. */
-   if (IS_GEN9_LP(dev_priv)) {
-   s_max = 1;
-   ss_max = 3;
-   }
+   u32 s_reg[info->sseu.max_slices], eu_reg[2*info->sseu.max_subslices], 
eu_mask[2];
 
-   for (s = 0; s < s_max; s++) {
+   for (s = 0; s < info->sseu.max_slices; s++) {
s_reg[s] = I915_READ(GEN9_SLICE_PGCTL_ACK(s));
eu_reg[2*s] = I915_READ(GEN9_SS01_EU_PGCTL_ACK(s));
eu_reg[2*s + 1] = I915_READ(GEN9_SS23_EU_PGCTL_ACK(s));
@@ -4434,7 +4428,7 @@ static void gen9_sseu_device_status(struct 
drm_i915_private *dev_priv,
 GEN9_PGCTL_SSB_EU210_ACK |
 GEN9_PGCTL_SSB_EU311_ACK;
 
-   for (s = 0; s < s_max; s++) {
+   for (s = 0; s < info->sseu.max_slices; s++) {
if ((s_reg[s] & GEN9_PGCTL_SLICE_ACK) == 0)
/* skip disabled slice */
continue;
@@ -4445,7 +4439,7 @@ static void gen9_sseu_device_status(struct 
drm_i915_private *dev_priv,
sseu->subslices_mask[s] =
INTEL_INFO(dev_priv)->sseu.subslices_mask[s];
 
-   for (ss = 0; ss < ss_max; ss++) {
+   for (ss = 0; ss < info->sseu.max_subslices; ss++) {
unsigned int eu_cnt;
 
if (IS_GEN9_LP(dev_priv)) {
-- 
2.15.1

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

[PATCH v6 2/5] drm/i915: store all subslice masks

[Lionel Landwerlin]

Up to now, subslice mask was assumed to be uniform across slices. But
starting with Cannonlake, slices can be asymetric (for example slice0
has different number of subslices as slice1+). This change stores all
subslices masks for all slices rather than having a single mask that
applies to all slices.

Signed-off-by: Lionel Landwerlin 
---
 drivers/gpu/drm/i915/i915_debugfs.c  |  24 +++--
 drivers/gpu/drm/i915/i915_drv.c  |   2 +-
 drivers/gpu/drm/i915/i915_drv.h  |  23 -
 drivers/gpu/drm/i915/intel_device_info.c | 169 ++-
 drivers/gpu/drm/i915/intel_lrc.c |   2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.h  |   2 +-
 6 files changed, 161 insertions(+), 61 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 28294470ae31..ef091a2a6b12 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4340,7 +4340,7 @@ static void cherryview_sseu_device_status(struct 
drm_i915_private *dev_priv,
continue;
 
sseu->slice_mask = BIT(0);
-   sseu->subslice_mask |= BIT(ss);
+   sseu->subslices_mask[0] |= BIT(ss);
eu_cnt = ((sig1[ss] & CHV_EU08_PG_ENABLE) ? 0 : 2) +
 ((sig1[ss] & CHV_EU19_PG_ENABLE) ? 0 : 2) +
 ((sig1[ss] & CHV_EU210_PG_ENABLE) ? 0 : 2) +
@@ -4387,7 +4387,7 @@ static void gen10_sseu_device_status(struct 
drm_i915_private *dev_priv,
continue;
 
sseu->slice_mask |= BIT(s);
-   sseu->subslice_mask = info->sseu.subslice_mask;
+   sseu->subslices_mask[s] = info->sseu.subslices_mask[s];
 
for (ss = 0; ss < ss_max; ss++) {
unsigned int eu_cnt;
@@ -4442,8 +4442,8 @@ static void gen9_sseu_device_status(struct 
drm_i915_private *dev_priv,
sseu->slice_mask |= BIT(s);
 
if (IS_GEN9_BC(dev_priv))
-   sseu->subslice_mask =
-   INTEL_INFO(dev_priv)->sseu.subslice_mask;
+   sseu->subslices_mask[s] =
+   INTEL_INFO(dev_priv)->sseu.subslices_mask[s];
 
for (ss = 0; ss < ss_max; ss++) {
unsigned int eu_cnt;
@@ -4453,7 +4453,7 @@ static void gen9_sseu_device_status(struct 
drm_i915_private *dev_priv,
/* skip disabled subslice */
continue;
 
-   sseu->subslice_mask |= BIT(ss);
+   sseu->subslices_mask[s] |= BIT(ss);
}
 
eu_cnt = 2 * hweight32(eu_reg[2*s + ss/2] &
@@ -4475,9 +4475,12 @@ static void broadwell_sseu_device_status(struct 
drm_i915_private *dev_priv,
sseu->slice_mask = slice_info & GEN8_LSLICESTAT_MASK;
 
if (sseu->slice_mask) {
-   sseu->subslice_mask = INTEL_INFO(dev_priv)->sseu.subslice_mask;
sseu->eu_per_subslice =
INTEL_INFO(dev_priv)->sseu.eu_per_subslice;
+   for (s = 0; s < fls(sseu->slice_mask); s++) {
+   sseu->subslices_mask[s] =
+   INTEL_INFO(dev_priv)->sseu.subslices_mask[s];
+   }
sseu->eu_total = sseu->eu_per_subslice *
 sseu_subslice_total(sseu);
 
@@ -4496,6 +4499,7 @@ static void i915_print_sseu_info(struct seq_file *m, bool 
is_available_info,
 {
struct drm_i915_private *dev_priv = node_to_i915(m->private);
const char *type = is_available_info ? "Available" : "Enabled";
+   int s;
 
seq_printf(m, "  %s Slice Mask: %04x\n", type,
   sseu->slice_mask);
@@ -4503,10 +4507,10 @@ static void i915_print_sseu_info(struct seq_file *m, 
bool is_available_info,
   hweight8(sseu->slice_mask));
seq_printf(m, "  %s Subslice Total: %u\n", type,
   sseu_subslice_total(sseu));
-   seq_printf(m, "  %s Subslice Mask: %04x\n", type,
-  sseu->subslice_mask);
-   seq_printf(m, "  %s Subslice Per Slice: %u\n", type,
-  hweight8(sseu->subslice_mask));
+   for (s = 0; s < fls(sseu->slice_mask); s++) {
+   seq_printf(m, "  %s Slice%i Subslice Mask: %04x\n", type,
+  s, sseu->subslices_mask[s]);
+   }
seq_printf(m, "  %s EU Total: %u\n", type,
   sseu->eu_total);
seq_printf(m, "  %s EU Per Subslice: %u\n", type,
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 7faf20aff25a..b9bfc38e6188 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -414,7 +414,7 @@ static int i915_getparam(struct drm_device *dev, void *data,
 

[PATCH v6 1/5] drm: add card symlink in render sysfs directory

[Lionel Landwerlin]

In i915 we would like to expose information about the GPU topology
which would be useful mostly to applications making use of the device
computational capability (not so much the display part). At the moment
we already store information like frequency, etc... into the card
directory (/sys/class/drm/card0). It seems natural to add the
additional data there too.

Unfortunately it's not obvious how to go from the render node back to
the sysfs card directory.

From the major/minor number it's possible to figure out what device
associated with the render node. For example with this render node :

$ ls -l /dev/dri/renderD128
crw-rw+ 1 root video 226, 128 Oct 24 16:17 /dev/dri/renderD128

You can rebuild a part to access the associated drm device in :

$ ls -l /sys/dev/char/226\:128/device/drm/
total 0
drwxr-xr-x 9 root root 0 Nov 27 16:52 card0
lrwxrwxrwx 1 root root 0 Nov 27 16:52 controlD64 -> card0
drwxr-xr-x 3 root root 0 Nov 27 16:50 renderD128

Right now, most devices have usually only one card. But in order to be
future proof, we would like to associate the render node with the card
so that you can get access to the card with the following path :

/sys/dev/char/226\:128/card/

Signed-off-by: Lionel Landwerlin 
Cc: dri-devel@lists.freedesktop.org
---
 drivers/gpu/drm/drm_drv.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 9acc1e157813..a26c0e86778e 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -779,6 +779,14 @@ int drm_dev_register(struct drm_device *dev, unsigned long 
flags)
if (drm_core_check_feature(dev, DRIVER_MODESET))
drm_modeset_register_all(dev);
 
+   if (drm_core_check_feature(dev, DRIVER_RENDER)) {
+   ret = sysfs_create_link(>render->kdev->kobj,
+   >primary->kdev->kobj,
+   "card");
+   if (ret)
+   goto err_minors;
+   }
+
ret = 0;
 
DRM_INFO("Initialized %s %d.%d.%d %s for %s on minor %d\n",
@@ -835,6 +843,9 @@ void drm_dev_unregister(struct drm_device *dev)
list_for_each_entry_safe(r_list, list_temp, >maplist, head)
drm_legacy_rmmap(dev, r_list->map);
 
+   if (drm_core_check_feature(dev, DRIVER_RENDER))
+   sysfs_remove_link(>render->kdev->kobj, "card");
+
remove_compat_control_link(dev);
drm_minor_unregister(dev, DRM_MINOR_PRIMARY);
drm_minor_unregister(dev, DRM_MINOR_RENDER);
-- 
2.15.1

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

[PATCH v6 0/5] drm/i915: Expose more GPU properties through sysfs

[Lionel Landwerlin]

Hi,

After discussion with Chris, Joonas & Tvrtko, this series adds an
additional commit to link the render node back to the card through a
symlink. Making it obvious from an application using a render node to
know where to get the information it needs.

Cheers,

Lionel Landwerlin (5):
  drm: add card symlink in render sysfs directory
  drm/i915: store all subslice masks
  drm/i915/debugfs: reuse max slice/subslices already stored in sseu
  drm/i915: expose engine availability through sysfs
  drm/i915: expose EU topology through sysfs

 drivers/gpu/drm/drm_drv.c|  11 +
 drivers/gpu/drm/i915/i915_debugfs.c  |  50 ++--
 drivers/gpu/drm/i915/i915_drv.c  |   2 +-
 drivers/gpu/drm/i915/i915_drv.h  |  56 -
 drivers/gpu/drm/i915/i915_sysfs.c| 386 +++
 drivers/gpu/drm/i915/intel_device_info.c | 169 ++
 drivers/gpu/drm/i915/intel_engine_cs.c   |  12 +
 drivers/gpu/drm/i915/intel_lrc.c |   2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.h  |   6 +-
 9 files changed, 617 insertions(+), 77 deletions(-)

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

[PATCH] drm: nouveau: use correct string length

[Arnd Bergmann]

gcc-8 reports

drivers/gpu/drm/nouveau/nvkm/engine/pm/base.c: In function 'nvkm_perfmon_mthd':
include/linux/string.h:265:9: error: '__builtin_strncpy' specified bound 64 
equals destination size [-Werror=stringop-truncation]

We need one less byte or call strlcpy() to make it a
nul-terminated string.

Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/nouveau/nvkm/engine/pm/base.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/pm/base.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/pm/base.c
index dde89a4a0f5b..53859b6254d6 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/pm/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/pm/base.c
@@ -462,7 +462,7 @@ nvkm_perfmon_mthd_query_domain(struct nvkm_perfmon *perfmon,
 
args->v0.id = di;
args->v0.signal_nr  = nvkm_perfdom_count_perfsig(dom);
-   strncpy(args->v0.name, dom->name, sizeof(args->v0.name));
+   strncpy(args->v0.name, dom->name, sizeof(args->v0.name) - 1);
 
/* Currently only global counters (PCOUNTER) are implemented
 * but this will be different for local counters (MP). */
@@ -514,7 +514,7 @@ nvkm_perfmon_mthd_query_signal(struct nvkm_perfmon *perfmon,
 "/%s/%02x", dom->name, si);
} else {
strncpy(args->v0.name, sig->name,
-   sizeof(args->v0.name));
+   sizeof(args->v0.name) - 1);
}
 
args->v0.signal = si;
@@ -572,7 +572,7 @@ nvkm_perfmon_mthd_query_source(struct nvkm_perfmon *perfmon,
 
args->v0.source = sig->source[si];
args->v0.mask   = src->mask;
-   strncpy(args->v0.name, src->name, sizeof(args->v0.name));
+   strncpy(args->v0.name, src->name, sizeof(args->v0.name) - 1);
}
 
if (++si < source_nr) {
-- 
2.9.0

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

[PATCH] gpu: ipu-v3: prg: avoid possible array underflow

[Arnd Bergmann]

gcc-8 reports that we access an array with a negative index
in an error case:

drivers/gpu/ipu-v3/ipu-prg.c: In function 'ipu_prg_channel_disable':
drivers/gpu/ipu-v3/ipu-prg.c:252:43: error: array subscript -22 is below array 
bounds of 'struct ipu_prg_channel[3]' [-Werror=array-bounds]

This moves the range check in front of the dereference.

Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/ipu-v3/ipu-prg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/ipu-v3/ipu-prg.c b/drivers/gpu/ipu-v3/ipu-prg.c
index 0013ca9f72c8..1417db856989 100644
--- a/drivers/gpu/ipu-v3/ipu-prg.c
+++ b/drivers/gpu/ipu-v3/ipu-prg.c
@@ -252,7 +252,7 @@ void ipu_prg_channel_disable(struct ipuv3_channel *ipu_chan)
struct ipu_prg_channel *chan = >chan[prg_chan];
u32 val;
 
-   if (!chan->enabled || prg_chan < 0)
+   if (prg_chan < 0 || !chan->enabled)
return;
 
clk_prepare_enable(prg->clk_ipg);
-- 
2.9.0

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

[Bug 103829] [CI] igt@gem_busy@close-race - fail - Failed assertion: gem_bo_busy(fd, object[0].handle)

[bugzilla-daemon]

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

Chris Wilson  changed:

   What|Removed |Added

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

--- Comment #3 from Chris Wilson  ---
commit 7e07894d8b0f567cb4241b5bed8a9644874ddd47 (HEAD, upstream/master)
Author: Chris Wilson 
Date:   Fri Dec 1 21:53:03 2017 +

igt/gem_busy: Replace arbitrary busy batch with indefinite spinbatch

In CI, we were observing situations where the busy blt would complete
before the very next instruction (in userspace) to assert that it was
busy. This is entirely possible if the process was scheduled away and
slept for longer than the arbitrary batch. Instead replace arbitrariness
with a precise infinity.

v2: Be respectful to UP!
v3: Move spinbatch to owning process to avoid serialisation delays.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103829
Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 

(Hopefully)

-- 
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] drm: msm: avoid false-positive -Wmaybe-uninitialized warning

[Arnd Bergmann]

gcc-8 -fsanitize-coverage=trace-pc produces a false-positive warning:

drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c: In function 
'mdp5_plane_mode_set.isra.8':
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c:1053:3: error: 'crtc_x_r' may be used 
uninitialized in this function [-Werror=maybe-uninitialized]

It's relatively clear from reading the source that this cannot happen,
and older compilers get it right. This rearranges the code remove
the two affected variables, which reliably avoids the problem.

Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
index be50445f9901..c50449882037 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
@@ -964,8 +964,6 @@ static int mdp5_plane_mode_set(struct drm_plane *plane,
uint32_t src_x, src_y;
uint32_t src_w, src_h;
uint32_t src_img_w, src_img_h;
-   uint32_t src_x_r;
-   int crtc_x_r;
int ret;
 
nplanes = fb->format->num_planes;
@@ -1010,9 +1008,6 @@ static int mdp5_plane_mode_set(struct drm_plane *plane,
crtc_w /= 2;
src_w /= 2;
src_img_w /= 2;
-
-   crtc_x_r = crtc_x + crtc_w;
-   src_x_r = src_x + src_w;
}
 
ret = calc_scalex_steps(plane, pix_format, src_w, crtc_w, step.x);
@@ -1052,9 +1047,9 @@ static int mdp5_plane_mode_set(struct drm_plane *plane,
if (right_hwpipe)
mdp5_hwpipe_mode_set(mdp5_kms, right_hwpipe, fb, , ,
 config, hdecm, vdecm, hflip, vflip,
-crtc_x_r, crtc_y, crtc_w, crtc_h,
+crtc_x + crtc_w, crtc_y, crtc_w, crtc_h,
 src_img_w, src_img_h,
-src_x_r, src_y, src_w, src_h);
+src_x + src_w, src_y, src_w, src_h);
 
plane->fb = fb;
 
-- 
2.9.0

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

Re: [PATCH v3 2/2] drm: rcar-du: Clip planes to screen boundaries

[Kieran Bingham]

Hi Laurent,

Thankyou for the patch.

On 26/11/17 11:30, Laurent Pinchart wrote:
> Unlike the KMS API, the hardware doesn't support planes exceeding the
> screen boundaries or planes being located fully off-screen. We need to
> clip plane coordinates to support the use case.
> 
> Fortunately the DRM core offers a drm_atomic_helper_check_plane_state()
> helper that valides the scaling factor and clips the plane coordinates.

s/valides/validates/

> Use it to implement the plane atomic check and use the clipped source
> and destination rectangles from the plane state instead of the unclipped
> source and CRTC coordinates to configure the device.
> 
> Signed-off-by: Laurent Pinchart 


Aside from the spelling error above - I can't find a fault here. Maybe next 
time :-)

Reviewed-by: Kieran Bingham 

> ---
> Changes since v2:
> 
> - Actually use the clipped source and destination rectangles
> - Use drm_crtc_state::mode instead of drm_crtc_state::adjusted_mode
>   where applicable
> - Removed spurious semicolon
> - Rebased on top of latest drm+drm-misc
> ---
>  drivers/gpu/drm/rcar-du/rcar_du_crtc.c  |  3 +-
>  drivers/gpu/drm/rcar-du/rcar_du_plane.c | 50 
> -
>  drivers/gpu/drm/rcar-du/rcar_du_vsp.c   | 42 ++-
>  3 files changed, 62 insertions(+), 33 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> index b492063a6e1f..5685d5af6998 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> @@ -319,7 +319,8 @@ static void rcar_du_crtc_update_planes(struct 
> rcar_du_crtc *rcrtc)
>   struct rcar_du_plane *plane = >group->planes[i];
>   unsigned int j;
>  
> - if (plane->plane.state->crtc != >crtc)
> + if (plane->plane.state->crtc != >crtc ||
> + !plane->plane.state->visible)
>   continue;
>  
>   /* Insert the plane in the sorted planes array. */
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c 
> b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> index 4f076c364f25..4a3d16cf3ed6 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> @@ -332,8 +332,8 @@ static void rcar_du_plane_write(struct rcar_du_group 
> *rgrp,
>  static void rcar_du_plane_setup_scanout(struct rcar_du_group *rgrp,
>   const struct rcar_du_plane_state *state)
>  {
> - unsigned int src_x = state->state.src_x >> 16;
> - unsigned int src_y = state->state.src_y >> 16;
> + unsigned int src_x = state->state.src.x1 >> 16;
> + unsigned int src_y = state->state.src.y1 >> 16;
>   unsigned int index = state->hwindex;
>   unsigned int pitch;
>   bool interlaced;
> @@ -357,7 +357,7 @@ static void rcar_du_plane_setup_scanout(struct 
> rcar_du_group *rgrp,
>   dma[i] = gem->paddr + fb->offsets[i];
>   }
>   } else {
> - pitch = state->state.src_w >> 16;
> + pitch = drm_rect_width(>state.src) >> 16;
>   dma[0] = 0;
>   dma[1] = 0;
>   }
> @@ -521,6 +521,7 @@ static void rcar_du_plane_setup_format(struct 
> rcar_du_group *rgrp,
>  const struct rcar_du_plane_state *state)
>  {
>   struct rcar_du_device *rcdu = rgrp->dev;
> + const struct drm_rect *dst = >state.dst;
>  
>   if (rcdu->info->gen < 3)
>   rcar_du_plane_setup_format_gen2(rgrp, index, state);
> @@ -528,10 +529,10 @@ static void rcar_du_plane_setup_format(struct 
> rcar_du_group *rgrp,
>   rcar_du_plane_setup_format_gen3(rgrp, index, state);
>  
>   /* Destination position and size */
> - rcar_du_plane_write(rgrp, index, PnDSXR, state->state.crtc_w);
> - rcar_du_plane_write(rgrp, index, PnDSYR, state->state.crtc_h);
> - rcar_du_plane_write(rgrp, index, PnDPXR, state->state.crtc_x);
> - rcar_du_plane_write(rgrp, index, PnDPYR, state->state.crtc_y);
> + rcar_du_plane_write(rgrp, index, PnDSXR, drm_rect_width(dst));
> + rcar_du_plane_write(rgrp, index, PnDSYR, drm_rect_height(dst));
> + rcar_du_plane_write(rgrp, index, PnDPXR, dst->x1);
> + rcar_du_plane_write(rgrp, index, PnDPYR, dst->y1);
>  
>   if (rcdu->info->gen < 3) {
>   /* Wrap-around and blinking, disabled */
> @@ -570,16 +571,39 @@ int __rcar_du_plane_atomic_check(struct drm_plane 
> *plane,
>const struct rcar_du_format_info **format)
>  {
>   struct drm_device *dev = plane->dev;
> + struct drm_crtc_state *crtc_state;
> + struct drm_rect clip;
> + int ret;
>  
> - if (!state->fb || !state->crtc) {
> + if (!state->crtc) {
> + /*
> +  * The visible field is not reset by the DRM core but only
> +

Re: xf86-video-armada via UDL [was: Re: UDL's fbdev doesn't work for user-space apps]

[Jose Abreu]

On 04-12-2017 13:16, Alexey Brodkin wrote:
> Option  "kmsdev" "/dev/dri/card1"

Which drm driver uses /dev/dri/card0? I'm seing drmOpen code and
if you don't specify the busID it will fallback for the first
card that matches "armada-drm" or "imx-drm" or "udl".

> But if I swap "imx-drm" to "udl" I don't see anything on my screen
> (connected via UDL) even though Xserver seems to really start claiming the 
> screen
> (so I see it becomes black, effectively overriding whatever was there before) 
> and
> glmark benchmark prints results.
>
>

Xorg.log can help confirm if everything is ok.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RESENT PATCH] drm/panel: support Innolux P097PFG panel

[Lothar Waßmann]

Hi,

On Thu, 30 Nov 2017 14:14:40 +0800 Lin Huang wrote:
> Support Innolux P097PFG 9.7" 1536x2048 TFT LCD panel,
> it refactor Innolux P079ZCA panel driver, let it support
> multi panel, and add support P097PFG panel in this driver.
> 
> Signed-off-by: Lin Huang 
> 
> ---
>  drivers/gpu/drm/panel/panel-innolux-p079zca.c | 178 
> --
>  1 file changed, 136 insertions(+), 42 deletions(-)
> 
> diff --git a/drivers/gpu/drm/panel/panel-innolux-p079zca.c 
> b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
> index 6ba9344..a40798f 100644
> --- a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
> +++ b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
[...]
> @@ -209,20 +284,39 @@ static const struct drm_panel_funcs innolux_panel_funcs 
> = {
>  };
>  
>  static const struct of_device_id innolux_of_match[] = {
> - { .compatible = "innolux,p079zca", },
> - { }
> + { .compatible = "innolux,p079zca",
> +   .data = _p079zca_panel_desc
> + },
> + { .compatible = "innolux,p097pfg",
> +   .data = _p097pfg_panel_desc
> + }
>  };
>
This hunk deletes the empty entry which is required as an end of list
marker!


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

Re: [PATCH v4] arm64: dts: rockchip: update mipi cells for RK3399

[Heiko Stuebner]

Hi Laurent,

Am Montag, 4. Dezember 2017, 15:22:07 CET schrieb Laurent Pinchart:
> On Wednesday, 29 November 2017 20:47:55 EET Brian Norris wrote:
> > From: Nickey Yang 
> > 
> > We might include additional ports in derivative device trees, so the
> > 'port' node should have an address, and the parent 'ports' node needs
> > /#{addres,size}-cells.
> > 
> > v4:
> >  * keep #{address,size}-cells in both 'ports' and 'port@0' nodes
> >  * separate from the rest of the series, since this is mostly
> >independent of the driver refactoring
> > 
> > Signed-off-by: Nickey Yang 
> > Signed-off-by: Brian Norris 
> 
> Reviewed-by: Laurent Pinchart 

As I hadn't pushed that one yet, I've amended it with your Review-tag :-)

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

[PATCH] drm/msm: Memory leak bug fix

[Sharat Masetty]

This patch fixes a possible memory leak in get_pages()

Prakash Kamliya (1):
  drm/msm: fix leak in failed get_pages

 drivers/gpu/drm/msm/msm_gem.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

--
1.9.1

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

[PATCH] drm/msm: fix leak in failed get_pages

[Sharat Masetty]

From: Prakash Kamliya 

get_pages doesn't keep a reference of the pages allocated
when it fails later in the code path. This can lead to
a memory leak. Keep reference of the allocated pages so
that it can be freed when msm_gem_free_object gets called
later during cleanup.

Signed-off-by: Prakash Kamliya 
Signed-off-by: Sharat Masetty 
---
 drivers/gpu/drm/msm/msm_gem.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 0776160..cb3d58d 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -93,14 +93,17 @@ static struct page **get_pages(struct drm_gem_object *obj)
return p;
}
 
+   msm_obj->pages = p;
+
msm_obj->sgt = drm_prime_pages_to_sg(p, npages);
if (IS_ERR(msm_obj->sgt)) {
+   void *ptr = ERR_CAST(msm_obj->sgt);
+
dev_err(dev->dev, "failed to allocate sgt\n");
-   return ERR_CAST(msm_obj->sgt);
+   msm_obj->sgt = NULL;
+   return ptr;
}
 
-   msm_obj->pages = p;
-
/* For non-cached buffers, ensure the new pages are clean
 * because display controller, GPU, etc. are not coherent:
 */
@@ -135,7 +138,10 @@ static void put_pages(struct drm_gem_object *obj)
if (msm_obj->flags & (MSM_BO_WC|MSM_BO_UNCACHED))
dma_unmap_sg(obj->dev->dev, msm_obj->sgt->sgl,
msm_obj->sgt->nents, DMA_BIDIRECTIONAL);
-   sg_free_table(msm_obj->sgt);
+
+   if (msm_obj->sgt)
+   sg_free_table(msm_obj->sgt);
+
kfree(msm_obj->sgt);
 
if (use_pages(obj))
-- 
1.9.1

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

[PATCH for 4.15] omapdrm/dss/hdmi4_cec: fix interrupt handling

[Hans Verkuil]

The omap4 CEC hardware cannot tell a Nack from a Low Drive from an
Arbitration Lost error, so just report a Nack, which is almost
certainly the reason for the error anyway.

This also simplifies the implementation. The only three interrupts
that need to be enabled are:

Transmit Buffer Full/Empty Change event: triggered when the
transmit finished successfully and cleared the buffer.

Receiver FIFO Not Empty event: triggered when a message was received.

Frame Retransmit Count Exceeded event: triggered when a transmit
failed repeatedly, usually due to the message being Nacked. Other
reasons are possible (Low Drive, Arbitration Lost) but there is no
way to know. If this happens the TX buffer needs to be cleared
manually.

While testing various error conditions I noticed that the hardware
can receive messages up to 18 bytes in total, which exceeds the legal
maximum of 16. This could cause a buffer overflow, so we check for
this and constrain the size to 16 bytes.

The old incorrect interrupt handler could cause the CEC framework to
enter into a bad state because it mis-detected the "Start Bit Irregularity
event" as an ARB_LOST transmit error when it actually is a receive error
which should be ignored.

Signed-off-by: Hans Verkuil 
Reported-by: Henrik Austad 
Tested-by: Henrik Austad 
Tested-by: Hans Verkuil 
---
 drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c | 46 +++--
 1 file changed, 9 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c 
b/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c
index d86873f2abe6..108a84cedaf6 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c
@@ -78,6 +78,8 @@ static void hdmi_cec_received_msg(struct hdmi_core_data *core)

/* then read the message */
msg.len = cnt & 0xf;
+   if (msg.len > CEC_MAX_MSG_SIZE - 2)
+   msg.len = CEC_MAX_MSG_SIZE - 2;
msg.msg[0] = hdmi_read_reg(core->base,
   HDMI_CEC_RX_CMD_HEADER);
msg.msg[1] = hdmi_read_reg(core->base,
@@ -104,26 +106,6 @@ static void hdmi_cec_received_msg(struct hdmi_core_data 
*core)
}
 }

-static void hdmi_cec_transmit_fifo_empty(struct hdmi_core_data *core, u32 
stat1)
-{
-   if (stat1 & 2) {
-   u32 dbg3 = hdmi_read_reg(core->base, HDMI_CEC_DBG_3);
-
-   cec_transmit_done(core->adap,
- CEC_TX_STATUS_NACK |
- CEC_TX_STATUS_MAX_RETRIES,
- 0, (dbg3 >> 4) & 7, 0, 0);
-   } else if (stat1 & 1) {
-   cec_transmit_done(core->adap,
- CEC_TX_STATUS_ARB_LOST |
- CEC_TX_STATUS_MAX_RETRIES,
- 0, 0, 0, 0);
-   } else if (stat1 == 0) {
-   cec_transmit_done(core->adap, CEC_TX_STATUS_OK,
- 0, 0, 0, 0);
-   }
-}
-
 void hdmi4_cec_irq(struct hdmi_core_data *core)
 {
u32 stat0 = hdmi_read_reg(core->base, HDMI_CEC_INT_STATUS_0);
@@ -132,27 +114,21 @@ void hdmi4_cec_irq(struct hdmi_core_data *core)
hdmi_write_reg(core->base, HDMI_CEC_INT_STATUS_0, stat0);
hdmi_write_reg(core->base, HDMI_CEC_INT_STATUS_1, stat1);

-   if (stat0 & 0x40)
+   if (stat0 & 0x20) {
+   cec_transmit_done(core->adap, CEC_TX_STATUS_OK,
+ 0, 0, 0, 0);
REG_FLD_MOD(core->base, HDMI_CEC_DBG_3, 0x1, 7, 7);
-   else if (stat0 & 0x24)
-   hdmi_cec_transmit_fifo_empty(core, stat1);
-   if (stat1 & 2) {
+   } else if (stat1 & 0x02) {
u32 dbg3 = hdmi_read_reg(core->base, HDMI_CEC_DBG_3);

cec_transmit_done(core->adap,
  CEC_TX_STATUS_NACK |
  CEC_TX_STATUS_MAX_RETRIES,
  0, (dbg3 >> 4) & 7, 0, 0);
-   } else if (stat1 & 1) {
-   cec_transmit_done(core->adap,
- CEC_TX_STATUS_ARB_LOST |
- CEC_TX_STATUS_MAX_RETRIES,
- 0, 0, 0, 0);
+   REG_FLD_MOD(core->base, HDMI_CEC_DBG_3, 0x1, 7, 7);
}
if (stat0 & 0x02)
hdmi_cec_received_msg(core);
-   if (stat1 & 0x3)
-   REG_FLD_MOD(core->base, HDMI_CEC_DBG_3, 0x1, 7, 7);
 }

 static bool hdmi_cec_clear_tx_fifo(struct cec_adapter *adap)
@@ -231,18 +207,14 @@ static int hdmi_cec_adap_enable(struct cec_adapter *adap, 
bool enable)
/*
 * Enable CEC interrupts:
 * Transmit Buffer Full/Empty Change event
-* Transmitter FIFO Empty event
 * Receiver 

Re: [PATCH v4] arm64: dts: rockchip: update mipi cells for RK3399

[Laurent Pinchart]

Hi Nickey,

Thank you for the patch.

On Wednesday, 29 November 2017 20:47:55 EET Brian Norris wrote:
> From: Nickey Yang 
> 
> We might include additional ports in derivative device trees, so the
> 'port' node should have an address, and the parent 'ports' node needs
> /#{addres,size}-cells.
> 
> v4:
>  * keep #{address,size}-cells in both 'ports' and 'port@0' nodes
>  * separate from the rest of the series, since this is mostly
>independent of the driver refactoring
> 
> Signed-off-by: Nickey Yang 
> Signed-off-by: Brian Norris 

Reviewed-by: Laurent Pinchart 

> ---
>  arch/arm64/boot/dts/rockchip/rk3399.dtsi | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> b/arch/arm64/boot/dts/rockchip/rk3399.dtsi index d340b58ab184..c6dae25a3f23
> 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> @@ -1652,7 +1652,11 @@
>   status = "disabled";
> 
>   ports {
> - mipi_in: port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + mipi_in: port@0 {
> + reg = <0>;
>   #address-cells = <1>;
>   #size-cells = <0>;


-- 
Regards,

Laurent Pinchart

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

[PATCH] drm: amd: dc: don't use FP math when Kcov is enabled

[Arnd Bergmann]

Building the DCN 1.0 Raven display driver with CONFIG_KCOV_INSTRUMENT_ALL=y
and CONFIG_KCOV_ENABLE_COMPARISONS=y results in warnings about many functions
that do a comparison of floating-point variables:

drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.o: In function 
`dcn_bw_calc_rq_dlg_ttu':
dcn_calcs.c:(.text+0x263): undefined reference to `__sanitizer_cov_trace_cmpf'
drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.o: In function 
`hack_force_pipe_split':
dcn_calcs.c:(.text+0x155b): undefined reference to `__sanitizer_cov_trace_cmpf'
drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.o: In function 
`dcn_find_dcfclk_suits_all':
dcn_calcs.c:(.text+0x190e): undefined reference to `__sanitizer_cov_trace_cmpf'
drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.o: In function 
`dcn_validate_bandwidth':
dcn_calcs.c:(.text+0xe121): undefined reference to `__sanitizer_cov_trace_cmpd'
drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_math.o: In function `dcn_bw_mod':
dcn_calc_math.c:(.text+0x22): undefined reference to 
`__sanitizer_cov_trace_cmpf'
drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_math.o: In function `dcn_bw_min2':
dcn_calc_math.c:(.text+0xb2): undefined reference to 
`__sanitizer_cov_trace_cmpf'
drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_math.o: In function 
`dcn_bw_ceil2':
dcn_calc_math.c:(.text+0x2a0): undefined reference to 
`__sanitizer_cov_trace_cmpd'
drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_math.o: In function `dcn_bw_max3':
dcn_calc_math.c:(.text+0x325): undefined reference to 
`__sanitizer_cov_trace_cmpf'
drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_math.o: In function `dcn_bw_max5':
dcn_calc_math.c:(.text+0x3c3): undefined reference to 
`__sanitizer_cov_trace_cmpf'
drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_math.o: In function `dcn_bw_log':
dcn_calc_math.c:(.text+0x54e): undefined reference to 
`__sanitizer_cov_trace_cmpd'
dcn_calc_math.c:(.text+0x57c): undefined reference to 
`__sanitizer_cov_trace_cmpd'
drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function 
`scaler_settings_calculation':
dcn_calc_auto.c:(.text+0x5c5): undefined reference to 
`__sanitizer_cov_trace_cmpf'
drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function 
`mode_support_and_system_configuration':
dcn_calc_auto.c:(.text+0x137c): undefined reference to 
`__sanitizer_cov_trace_cmpd'
drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function 
`mode_support_and_system_configuration':
dcn_calc_auto.c:(.text+0x9233): undefined reference to 
`__sanitizer_cov_trace_cmpd'
drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function 
`mode_support_and_system_configuration':
dcn_calc_auto.c:(.text+0xb70f): undefined reference to 
`__sanitizer_cov_trace_cmpd'
drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function 
`mode_support_and_system_configuration':
dcn_calc_auto.c:(.text+0x121fd): undefined reference to 
`__sanitizer_cov_trace_cmpd'
drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function 
`display_pipe_configuration':
dcn_calc_auto.c:(.text+0x15a2f): undefined reference to 
`__sanitizer_cov_trace_cmpd'
drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function 
`dispclkdppclkdcfclk_deep_sleep_prefetch_parameters_watermarks_and_performance_calculation':
dcn_calc_auto.c:(.text+0x17c2d): undefined reference to 
`__sanitizer_cov_trace_cmpf'
drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function 
`dispclkdppclkdcfclk_deep_sleep_prefetch_parameters_watermarks_and_performance_calculation':
dcn_calc_auto.c:(.text+0x19362): undefined reference to 
`__sanitizer_cov_trace_cmpd'
drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function 
`dispclkdppclkdcfclk_deep_sleep_prefetch_parameters_watermarks_and_performance_calculation':
dcn_calc_auto.c:(.text+0x25575): undefined reference to 
`__sanitizer_cov_trace_cmpd'
drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function 
`dispclkdppclkdcfclk_deep_sleep_prefetch_parameters_watermarks_and_performance_calculation':
dcn_calc_auto.c:(.text+0x27f33): undefined reference to 
`__sanitizer_cov_trace_cmpd'
drivers/gpu/drm/amd/display/dc/dml/display_rq_dlg_calc.o: In function 
`get_refcyc_per_delivery':
display_rq_dlg_calc.c:(.text+0xb5): undefined reference to 
`__sanitizer_cov_trace_cmpd'
drivers/gpu/drm/amd/display/dc/dml/display_rq_dlg_calc.o: In function 
`calculate_ttu_cursor.isra.1':
display_rq_dlg_calc.c:(.text+0x9f6): undefined reference to 
`__sanitizer_cov_trace_cmpd'
drivers/gpu/drm/amd/display/dc/dml/display_rq_dlg_calc.o: In function 
`dml_rq_dlg_get_dlg_params':
display_rq_dlg_calc.c:(.text+0x82cc): undefined reference to 
`__sanitizer_cov_trace_cmpf'
drivers/gpu/drm/amd/display/dc/dml/dml1_display_rq_dlg_calc.o: In function 
`get_refcyc_per_delivery.isra.0':
dml1_display_rq_dlg_calc.c:(.text+0x6c4): undefined reference to 
`__sanitizer_cov_trace_cmpd'
drivers/gpu/drm/amd/display/dc/dml/dml1_display_rq_dlg_calc.o: In function 
`get_vratio_pre.isra.2':
dml1_display_rq_dlg_calc.c:(.text+0x957): 

[PATCH] drm/msm: fix leak in failed get_pages

[Sharat Masetty]

From: Prakash Kamliya 

get_pages doesn't keep a reference of the pages allocated
when it fails later in the code path. This can lead to
a memory leak. Keep reference of the allocated pages so
that it can be freed when msm_gem_free_object gets called
later during cleanup.

Signed-off-by: Prakash Kamliya 
Signed-off-by: Sharat Masetty 
---
 drivers/gpu/drm/msm/msm_gem.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 0776160..cb3d58d 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -93,14 +93,17 @@ static struct page **get_pages(struct drm_gem_object *obj)
return p;
}
 
+   msm_obj->pages = p;
+
msm_obj->sgt = drm_prime_pages_to_sg(p, npages);
if (IS_ERR(msm_obj->sgt)) {
+   void *ptr = ERR_CAST(msm_obj->sgt);
+
dev_err(dev->dev, "failed to allocate sgt\n");
-   return ERR_CAST(msm_obj->sgt);
+   msm_obj->sgt = NULL;
+   return ptr;
}
 
-   msm_obj->pages = p;
-
/* For non-cached buffers, ensure the new pages are clean
 * because display controller, GPU, etc. are not coherent:
 */
@@ -135,7 +138,10 @@ static void put_pages(struct drm_gem_object *obj)
if (msm_obj->flags & (MSM_BO_WC|MSM_BO_UNCACHED))
dma_unmap_sg(obj->dev->dev, msm_obj->sgt->sgl,
msm_obj->sgt->nents, DMA_BIDIRECTIONAL);
-   sg_free_table(msm_obj->sgt);
+
+   if (msm_obj->sgt)
+   sg_free_table(msm_obj->sgt);
+
kfree(msm_obj->sgt);
 
if (use_pages(obj))
-- 
1.9.1

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

[PATCH] drm/msm: Memory leak bug fix

[Sharat Masetty]

This patch fixes a possible memory leak in get_pages()

Prakash Kamliya (1):
  drm/msm: fix leak in failed get_pages

 drivers/gpu/drm/msm/msm_gem.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

--
1.9.1

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

[PATCH 2/2] drm/ttm: swap consecutive allocated pooled pages v3

[Christian König]

When we detect consecutive allocation of pages swap them to avoid
accidentally freeing them as huge page.

v2: use swap
v3: check if it's really the first allocated page

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_page_alloc.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 7c4d4edce0ba..da8a50f7c8fe 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -954,8 +954,13 @@ static int ttm_get_pages(struct page **pages, unsigned 
npages, int flags,
r = ttm_page_pool_get_pages(pool, , flags, cstate,
npages - count, 0);
 
-   list_for_each_entry(p, , lru)
+   first = count;
+   list_for_each_entry(p, , lru) {
+   /* Swap the pages if we detect consecutive order */
+   if (count > first && pages[count - 1] == p - 1)
+   swap(p, pages[count - 1]);
pages[count++] = p;
+   }
 
if (r) {
/* If there is any pages in the list put them back to
-- 
2.11.0

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

[PATCH 1/2] drm/ttm: swap consecutive allocated cached pages v3

[Christian König]

When we detect consecutive allocation of pages swap them to avoid
accidentally freeing them as huge page.

v2: use swap
v3: check if it's really the first allocated page

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_page_alloc.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index c82d94cbbabc..7c4d4edce0ba 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -875,7 +875,7 @@ static int ttm_get_pages(struct page **pages, unsigned 
npages, int flags,
 #endif
struct list_head plist;
struct page *p = NULL;
-   unsigned count;
+   unsigned count, first;
int r;
 
/* No pool for cached pages */
@@ -914,6 +914,7 @@ static int ttm_get_pages(struct page **pages, unsigned 
npages, int flags,
}
 #endif
 
+   first = i;
while (npages) {
p = alloc_page(gfp_flags);
if (!p) {
@@ -921,6 +922,10 @@ static int ttm_get_pages(struct page **pages, unsigned 
npages, int flags,
return -ENOMEM;
}
 
+   /* Swap the pages if we detect consecutive order */
+   if (i > first && pages[i - 1] == p - 1)
+   swap(p, pages[i - 1]);
+
pages[i++] = p;
--npages;
}
-- 
2.11.0

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

RE: [PATCH 1/2] drm/ttm: swap consecutive allocated cached pages v2

[He, Roger]

-Original Message-
From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com] 
Sent: Monday, December 04, 2017 8:13 PM
To: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org; He, Roger 
; ckoenig.leichtzumer...@gmail.com
Subject: [PATCH 1/2] drm/ttm: swap consecutive allocated cached pages v2

When we detect consecutive allocation of pages swap them to avoid accidentally 
freeing them as huge page.

v2: use swap

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_page_alloc.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index c82d94cbbabc..b6c5148607e9 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -921,6 +921,10 @@ static int ttm_get_pages(struct page **pages, unsigned 
npages, int flags,
return -ENOMEM;
}
 
How about add first index as below?

first = i;  //init  first here
while (npages) {
p = alloc_page(gfp_flags);
if (!p) {
pr_debug("Unable to allocate page\n");
return -ENOMEM;
}

/* Swap the pages if we detect consecutive order */
if (i > first && pages[i - 1] == p - 1) 
 //change to (i > first), because I worry if npages is 
513, the first regular page is exactly consecutive with last page of huge page. 
Then swap them is not what I want here.
swap(p, pages[i - 1]);

pages[i++] = p;
--npages;
}

pages[i++] = p;
--npages;
}
--
2.11.0

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

Re: [PATCH 1/2] drm/ttm: swap consecutive allocated cached pages

[Christian König]

Am 04.12.2017 um 12:51 schrieb Michel Dänzer:

On 2017-12-04 12:42 PM, Christian König wrote:

When we detect consecutive allocation of pages swap them to avoid
accidentally freeing them as huge page.

Signed-off-by: Christian König 
---
  drivers/gpu/drm/ttm/ttm_page_alloc.c | 8 
  1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index c82d94cbbabc..60401350a01a 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -921,6 +921,14 @@ static int ttm_get_pages(struct page **pages, unsigned 
npages, int flags,
return -ENOMEM;
}
  
+			/* Swap the pages if we detect consecutive order */

+   if (i && pages[i - 1] == p - 1) {
+   struct page *tmp = p;
+
+   p = pages[i - 1];
+   pages[i - 1] = tmp;
+   }
+

Should be (something like):

if (i && pages[i - 1] == p - 1)
swap(pages[i - 1], p);


Good point, updates patches send out a few seconds ago.

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

[PATCH 1/2] drm/ttm: swap consecutive allocated cached pages v2

[Christian König]

When we detect consecutive allocation of pages swap them to avoid
accidentally freeing them as huge page.

v2: use swap

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_page_alloc.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index c82d94cbbabc..b6c5148607e9 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -921,6 +921,10 @@ static int ttm_get_pages(struct page **pages, unsigned 
npages, int flags,
return -ENOMEM;
}
 
+   /* Swap the pages if we detect consecutive order */
+   if (i && pages[i - 1] == p - 1)
+   swap(p, pages[i - 1]);
+
pages[i++] = p;
--npages;
}
-- 
2.11.0

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

[PATCH 2/2] drm/ttm: swap consecutive allocated pooled pages v2

[Christian König]

When we detect consecutive allocation of pages swap them to avoid
accidentally freeing them as huge page.

v2: use swap

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_page_alloc.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index b6c5148607e9..29652b2615a8 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -953,8 +953,12 @@ static int ttm_get_pages(struct page **pages, unsigned 
npages, int flags,
r = ttm_page_pool_get_pages(pool, , flags, cstate,
npages - count, 0);
 
-   list_for_each_entry(p, , lru)
+   list_for_each_entry(p, , lru) {
+   /* Swap the pages if we detect consecutive order */
+   if (count && pages[count - 1] == p - 1)
+   swap(p, pages[count - 1]);
pages[count++] = p;
+   }
 
if (r) {
/* If there is any pages in the list put them back to
-- 
2.11.0

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

Re: d17a1d97dc ("x86/mm/kasan: don't use vmemmap_populate() to initialize shadow"): BUG: KASAN: use-after-scope in __drm_mm_interval_first

[Chris Wilson]

Quoting Dmitry Vyukov (2017-11-29 19:00:59)
> On Wed, Nov 29, 2017 at 6:21 AM, Fengguang Wu  wrote:
> > Greetings,
> >
> > 0day kernel testing robot got the below dmesg and the first bad commit is
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> >
> > commit d17a1d97dc208d664c91cc387ffb752c7f85dc61
> > Author: Andrey Ryabinin 
> > AuthorDate: Wed Nov 15 17:36:35 2017 -0800
> > Commit: Linus Torvalds 
> > CommitDate: Wed Nov 15 18:21:05 2017 -0800
> >
> >  x86/mm/kasan: don't use vmemmap_populate() to initialize shadow
> >
> >  The kasan shadow is currently mapped using vmemmap_populate() since 
> > that
> >  provides a semi-convenient way to map pages into init_top_pgt.  
> > However,
> >  since that no longer zeroes the mapped pages, it is not suitable for
> >  kasan, which requires zeroed shadow memory.
> >
> >  Add kasan_populate_shadow() interface and use it instead of
> >  vmemmap_populate().  Besides, this allows us to take advantage of
> >  gigantic pages and use them to populate the shadow, which should save 
> > us
> >  some memory wasted on page tables and reduce TLB pressure.
> >
> >  Link: 
> > http://lkml.kernel.org/r/20171103185147.2688-2-pasha.tatas...@oracle.com
> >  Signed-off-by: Andrey Ryabinin 
> >  Signed-off-by: Pavel Tatashin 
> >  Cc: Steven Sistare 
> >  Cc: Daniel Jordan 
> >  Cc: Bob Picco 
> >  Cc: Michal Hocko 
> >  Cc: Alexander Potapenko 
> >  Cc: Ard Biesheuvel 
> >  Cc: Catalin Marinas 
> >  Cc: Christian Borntraeger 
> >  Cc: David S. Miller 
> >  Cc: Dmitry Vyukov 
> >  Cc: Heiko Carstens 
> >  Cc: "H. Peter Anvin" 
> >  Cc: Ingo Molnar 
> >  Cc: Mark Rutland 
> >  Cc: Matthew Wilcox 
> >  Cc: Mel Gorman 
> >  Cc: Michal Hocko 
> >  Cc: Sam Ravnborg 
> >  Cc: Thomas Gleixner 
> >  Cc: Will Deacon 
> >  Signed-off-by: Andrew Morton 
> >  Signed-off-by: Linus Torvalds 
> >
> > a4a3ede213  mm: zero reserved and unavailable struct pages
> > d17a1d97dc  x86/mm/kasan: don't use vmemmap_populate() to initialize shadow
> > 43570f0383  Merge branch 'linus' of 
> > git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6
> > 5bef2980ad  Add linux-next specific files for 20171128
> > +---++++---+
> > |   | a4a3ede213 | 
> > d17a1d97dc | 43570f0383 | next-20171128 |
> > +---++++---+
> > | boot_successes| 30 | 0
> >   | 0  | 0 |
> > | boot_failures | 8  | 15   
> >   | 19 | 2 |
> > | WARNING:at_drivers/pci/pci-sysfs.c:#pci_mmap_resource | 8  |  
> >   ||   |
> > | RIP:pci_mmap_resource | 8  |  
> >   ||   |
> > | BUG:KASAN:use-after-scope_in__drm_mm_interval_first   | 0  | 15   
> >   | 19 | 2 |
> > +---++++---+
> >
> > [   27.628251] AMD IOMMUv2 functionality not available on this system
> > [   27.631925] drm_mm: Testing DRM range manger (struct drm_mm), with 
> > random_seed=0x248e657d max_iterations=8192 max_prime=128
> > [   27.633191] drm_mm: igt_sanitycheck - ok!
> > [   79.880445] Writes:  Total: 2  Max/Min: 0/0   Fail: 0
> > [  103.749567] 
> > ==
> > [  103.750064] BUG: KASAN: use-after-scope in 
> > __drm_mm_interval_first+0xbb/0x1bf
> > [  103.750064] Read of size 8 at addr 880016577c08 by task swapper/0/1
> > [  103.750064]
> > [  103.750064] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
> > 4.14.0-04319-gd17a1d9 #1
> > [  103.750064] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> > 1.10.2-1 04/01/2014
> > [  103.750064] Call Trace:
> > [  103.750064]  ? dump_stack+0xd1/0x16c
> > [  103.750064]  ? _atomic_dec_and_lock+0x10f/0x10f
> > [  103.750064]  ? 

Re: [PATCH 1/2] drm/ttm: swap consecutive allocated cached pages

[Michel Dänzer]

On 2017-12-04 12:42 PM, Christian König wrote:
> When we detect consecutive allocation of pages swap them to avoid
> accidentally freeing them as huge page.
> 
> Signed-off-by: Christian König 
> ---
>  drivers/gpu/drm/ttm/ttm_page_alloc.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
> b/drivers/gpu/drm/ttm/ttm_page_alloc.c
> index c82d94cbbabc..60401350a01a 100644
> --- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
> +++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
> @@ -921,6 +921,14 @@ static int ttm_get_pages(struct page **pages, unsigned 
> npages, int flags,
>   return -ENOMEM;
>   }
>  
> + /* Swap the pages if we detect consecutive order */
> + if (i && pages[i - 1] == p - 1) {
> + struct page *tmp = p;
> +
> + p = pages[i - 1];
> + pages[i - 1] = tmp;
> + }
> +

Should be (something like):

if (i && pages[i - 1] == p - 1)
swap(pages[i - 1], p);


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: UDL's fbdev doesn't work for user-space apps

[Jose Abreu]

Hi Alexey,

On 04-12-2017 11:32, Alexey Brodkin wrote:
> My first [probably incorrect] assumption is Xserver requires fbdev (/dev/fbX)
> and it cannot use DRI video card natively. Is that correct?
>
>

Xserver can use DRI directly, you need to enable modesetting
driver in Xorg config or use the designated driver for your card
(if there is any).

e.g.:

Section "Device"
Identifier "Card0"
Driver "modesetting"
Option "kmsdev" "/dev/dri/card0"
Option "SWcursor" "true"
BusID "PCI:X:X:X"
EndSection

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

Re: [PATCH 0/4] Backported amdgpu ttm deadlock fixes for 4.14

[Greg KH]

On Thu, Nov 30, 2017 at 07:23:02PM -0500, Lyude Paul wrote:
> I haven't gone to see where it started, but as of late a good number of
> pretty nasty deadlock issues have appeared with the kernel. Easy
> reproduction recipe on a laptop with i915/amdgpu prime with lockdep enabled:
> 
> DRI_PRIME=1 glxinfo
> 
> Additionally, some more race conditions exist that I've managed to
> trigger with piglit and lockdep enabled after applying these patches:
> 
> =
> WARNING: suspicious RCU usage
> 4.14.3Lyude-Test+ #2 Not tainted
> -
> ./include/linux/reservation.h:216 suspicious rcu_dereference_protected() 
> usage!
> 
> other info that might help us debug this:
> 
> rcu_scheduler_active = 2, debug_locks = 1
> 1 lock held by ext_image_dma_b/27451:
>  #0:  (reservation_ww_class_mutex){+.+.}, at: [] 
> ttm_bo_unref+0x9f/0x3c0 [ttm]
> 
> stack backtrace:
> CPU: 0 PID: 27451 Comm: ext_image_dma_b Not tainted 4.14.3Lyude-Test+ #2
> Hardware name: HP HP ZBook 15 G4/8275, BIOS P70 Ver. 01.02 06/09/2017
> Call Trace:
>  dump_stack+0x8e/0xce
>  lockdep_rcu_suspicious+0xc5/0x100
>  reservation_object_copy_fences+0x292/0x2b0
>  ? ttm_bo_unref+0x9f/0x3c0 [ttm]
>  ttm_bo_unref+0xbd/0x3c0 [ttm]
>  amdgpu_bo_unref+0x2a/0x50 [amdgpu]
>  amdgpu_gem_object_free+0x4b/0x50 [amdgpu]
>  drm_gem_object_free+0x1f/0x40 [drm]
>  drm_gem_object_put_unlocked+0x40/0xb0 [drm]
>  drm_gem_object_handle_put_unlocked+0x6c/0xb0 [drm]
>  drm_gem_object_release_handle+0x51/0x90 [drm]
>  drm_gem_handle_delete+0x5e/0x90 [drm]
>  ? drm_gem_handle_create+0x40/0x40 [drm]
>  drm_gem_close_ioctl+0x20/0x30 [drm]
>  drm_ioctl_kernel+0x5d/0xb0 [drm]
>  drm_ioctl+0x2f7/0x3b0 [drm]
>  ? drm_gem_handle_create+0x40/0x40 [drm]
>  ? trace_hardirqs_on_caller+0xf4/0x190
>  ? trace_hardirqs_on+0xd/0x10
>  amdgpu_drm_ioctl+0x4f/0x90 [amdgpu]
>  do_vfs_ioctl+0x93/0x670
>  ? __fget+0x108/0x1f0
>  SyS_ioctl+0x79/0x90
>  entry_SYSCALL_64_fastpath+0x23/0xc2
> 
> I've also added the relevant fixes for the issue mentioned above.
> 
> Christian König (3):
>   drm/ttm: fix ttm_bo_cleanup_refs_or_queue once more
>   dma-buf: make reservation_object_copy_fences rcu save
>   drm/amdgpu: reserve root PD while releasing it
> 
> Michel Dänzer (1):
>   drm/ttm: Always and only destroy bo->ttm_resv in ttm_bo_release_list

All now queued up, thanks.

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

[Bug 103788] [DC] Screen goes blank after screen sleep and will not come back on

[bugzilla-daemon]

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

--- Comment #8 from Michel Dänzer  ---
(In reply to oschowa from comment #7)
> I have a similar issue which is still present in 4.15-rc2. Though, in my
> case the system completly hangs after the screen wakes up from sleep and I
> can't even ssh in and there is nothing in the logs after a forced reboot.

In other words, an almost completely different issue. ;) Please file your own
report.

-- 
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/2] drm/ttm: swap consecutive allocated cached pages

[Christian König]

When we detect consecutive allocation of pages swap them to avoid
accidentally freeing them as huge page.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_page_alloc.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index c82d94cbbabc..60401350a01a 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -921,6 +921,14 @@ static int ttm_get_pages(struct page **pages, unsigned 
npages, int flags,
return -ENOMEM;
}
 
+   /* Swap the pages if we detect consecutive order */
+   if (i && pages[i - 1] == p - 1) {
+   struct page *tmp = p;
+
+   p = pages[i - 1];
+   pages[i - 1] = tmp;
+   }
+
pages[i++] = p;
--npages;
}
-- 
2.11.0

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

[PATCH 2/2] drm/ttm: swap consecutive allocated pooled pages

[Christian König]

When we detect consecutive allocation of pages swap them to avoid
accidentally freeing them as huge page.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_page_alloc.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 60401350a01a..909028fd663d 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -957,8 +957,16 @@ static int ttm_get_pages(struct page **pages, unsigned 
npages, int flags,
r = ttm_page_pool_get_pages(pool, , flags, cstate,
npages - count, 0);
 
-   list_for_each_entry(p, , lru)
+   list_for_each_entry(p, , lru) {
+   /* Swap the pages if we detect consecutive order */
+   if (count && pages[count - 1] == p - 1) {
+   struct page *tmp = p;
+
+   p = pages[count - 1];
+   pages[count - 1] = tmp;
+   }
pages[count++] = p;
+   }
 
if (r) {
/* If there is any pages in the list put them back to
-- 
2.11.0

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

[Bug 103791] Tearing after screen wakeup/on

[bugzilla-daemon]

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

--- Comment #13 from Michel Dänzer  ---
Created attachment 135923
  --> https://bugs.freedesktop.org/attachment.cgi?id=135923=edit
drm_vblank_get debugging output

Please do the same with this patch, to see why drm_vblank_get returns -EINVAL.

-- 
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/9] v4l: vsp1: Document the vsp1_du_atomic_config structure

[Laurent Pinchart]

Hi Sergei,

On Monday, 4 December 2017 11:31:49 EET Sergei Shtylyov wrote:
> On 12/3/2017 1:57 PM, Laurent Pinchart wrote:
> > The structure is used in the API that the VSP1 driver exposes to the DU
> > driver. Documenting it is thus important.
> > 
> > Signed-off-by: Laurent Pinchart
> > 
> > ---
> > 
> >   include/media/vsp1.h | 10 ++
> >   1 file changed, 10 insertions(+)
> > 
> > diff --git a/include/media/vsp1.h b/include/media/vsp1.h
> > index 68a8abe4fac5..7850f96fb708 100644
> > --- a/include/media/vsp1.h
> > +++ b/include/media/vsp1.h
> > @@ -41,6 +41,16 @@ struct vsp1_du_lif_config {
> >   int vsp1_du_setup_lif(struct device *dev, unsigned int pipe_index,
> >   const struct vsp1_du_lif_config *cfg);
> > 
> > +/**
> > + * struct vsp1_du_atomic_config - VSP atomic configuration parameters
> > + * @pixelformat: plan pixel format (V4L2 4CC)
> 
> s/plan/plane/?

Of course, my bad. This will be fixed in v2. Thank you for catching the typo.

-- 
Regards,

Laurent Pinchart

___
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 #1 from taij...@posteo.de ---
Created attachment 135922
  --> https://bugs.freedesktop.org/attachment.cgi?id=135922=edit
relevant output of #lspci -vv

-- 
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

Bug ID: 104064
   Summary: (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]
   Product: DRI
   Version: DRI git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: taij...@posteo.de

Created attachment 135921
  --> https://bugs.freedesktop.org/attachment.cgi?id=135921=edit
relevant dmesg output

I am getting repeated gpu resets on 4.15-rc2 with my hybrid laptop
(i7-7700HQ/RX470) with amdgpu.dc=1 set on the command line. Something seems to
be off with power management, as the dGPU does not fully power down, even when
not in use. dmesg attached, lspci follows.

-- 
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 104063] (DC 4.15-rc2) [drm:dm_logger_write [amdgpu]] *ERROR* hwss_edp_wait_for_hpd_ready: wait timed out!

[bugzilla-daemon]

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

--- Comment #1 from taij...@posteo.de ---
Created attachment 135920
  --> https://bugs.freedesktop.org/attachment.cgi?id=135920=edit
relevant output of #lspci -vv

-- 
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 104063] (DC 4.15-rc2) [drm:dm_logger_write [amdgpu]] *ERROR* hwss_edp_wait_for_hpd_ready: wait timed out!

[bugzilla-daemon]

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

Bug ID: 104063
   Summary: (DC 4.15-rc2) [drm:dm_logger_write [amdgpu]] *ERROR*
hwss_edp_wait_for_hpd_ready: wait timed out!
   Product: DRI
   Version: DRI git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: taij...@posteo.de

Created attachment 135919
  --> https://bugs.freedesktop.org/attachment.cgi?id=135919=edit
relevant dmesg output

I am getting this error message repeatedly on startup on my laptop with a
hybrid Intel/AMD gpu setup (i7-7700HQ/RX470). dmesg attached, lspci follows.

-- 
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 103962] (DC 4.15-rc1) [drm:gfx_v8_0_hw_fini [amdgpu]] *ERROR* KCQ disabled failed (scratch(0xC040)=0xCAFEDEAD)

[bugzilla-daemon]

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

taij...@posteo.de changed:

   What|Removed |Added

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

-- 
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 103962] (DC 4.15-rc1) [drm:gfx_v8_0_hw_fini [amdgpu]] *ERROR* KCQ disabled failed (scratch(0xC040)=0xCAFEDEAD)

[bugzilla-daemon]

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

--- Comment #2 from taij...@posteo.de ---
OK, 4.15-rc2 seems to have fixed this bug, not getting it anymore.

-- 
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 103788] [DC] Screen goes blank after screen sleep and will not come back on

[bugzilla-daemon]

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

--- Comment #7 from osch...@web.de ---
I have a similar issue which is still present in 4.15-rc2. Though, in my case
the system completly hangs after the screen wakes up from sleep and I can't
even ssh in and there is nothing in the logs after a forced reboot.
My GPU is a RX560.

-- 
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/i915: Mark expected switch fall-throughs

[Joonas Lahtinen]

On Mon, 2017-11-27 at 16:17 -0600, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.

I have to say I'm totally not sold on regexps matching comment
contents. Was something more explicit ever considered? Like:

#define FALLTHROUGH __attribute__((fallthrough));

With the appropriate version checks, of course.

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 103829] [CI] igt@gem_busy@close-race - fail - Failed assertion: gem_bo_busy(fd, object[0].handle)

[bugzilla-daemon]

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

--- Comment #2 from Jani Saarinen  ---
Reference: https://patchwork.freedesktop.org/series/34818/

-- 
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] arm64: dts: rockchip: update mipi cells for RK3399

[Heiko Stuebner]

Am Mittwoch, 29. November 2017, 10:47:55 CET schrieb Brian Norris:
> From: Nickey Yang 
> 
> We might include additional ports in derivative device trees, so the
> 'port' node should have an address, and the parent 'ports' node needs
> /#{addres,size}-cells.
> 
> v4:
>  * keep #{address,size}-cells in both 'ports' and 'port@0' nodes
>  * separate from the rest of the series, since this is mostly
>independent of the driver refactoring
> 
> Signed-off-by: Nickey Yang 
> Signed-off-by: Brian Norris 

applied for 4.16 with Doug's Review

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

Re: PROBLEM: Asus C201 video mode problems on HDMI hotplug (regression)

[Jose Abreu]

On 03-12-2017 05:20, Nick Bowler wrote:
>
> Your patch changes things.  With this applied on top of 4.15-rc1
> it is failing 100% of the time instead of only half of the time.

Ok, it was a long shot anyway.

>
> I brought the original test equipment back to the setup so I can
> see the video and pink bar again.  The symptoms remain the same
> (unexpected size, pink bar, and no audio).
>

Can you tell me which test equipment are you using?

> It is very consistent: pink bar <=> no audio.
>
> My suspicion is that the audio problem is just the wrong video mode
> on the sink side messing things up, but I have no way of confirming
> that (that I know of).

Hmmm, my first thought was that audio is being configured first
because of the phy lock wait time, I've seen this happening before.

Lets try this:
- Disable all alsa clients (e.g. pulseaudio, ...) so that no one
tries to configure audio.
- Plug out/in the cable until the issue appears
- When the issue appears use aplay to play audio through the HDMI
output
- Repeat several times with different audio rates and with no
resample (you can use the plughw interface in aplay).

>
> Thanks,
>   Nick

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

Re: [PATCH 0/2] Move scheduler out of AMDGPU

[Lucas Stach]

Hi,

Am Samstag, den 02.12.2017, 12:14 + schrieb Liu, Monk:
> I'm wondering if GPU reset still work after this home move ...

Why wouldn't it continue to work? After all this is just a code move
that doesn't change anything about the inner workings of the scheduler.

Regards,
Lucas

> 
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On
> Behalf Of Christian K?nig
> Sent: Friday, December 1, 2017 11:55 PM
> To: Lucas Stach ; Deucher, Alexander  er.deuc...@amd.com>
> Cc: Grodzovsky, Andrey ; David Airlie  l...@linux.ie>; amd-...@lists.freedesktop.org; patchwork-lst@pengutro
> nix.de; dri-devel@lists.freedesktop.org; ker...@pengutronix.de
> Subject: Re: [PATCH 0/2] Move scheduler out of AMDGPU
> 
> Am 01.12.2017 um 16:28 schrieb Lucas Stach:
> > Hi all,
> > 
> > so this is the first step to make the marvelous AMDGPU scheduler 
> > useable for other drivers. I have a (mostly) working prototype of 
> > Etnaviv using the scheduler, but those patches need to keep baking
> > for a while.
> > 
> > I'm sending this out as I want to avoid rebasing this change too
> > much 
> > and don't want to take people by surprise when the Etnaviv 
> > implementation surfaces. Also this might need some coordination 
> > between AMDGPU and Etnaviv, which might be good to get going now.
> > 
> > Please speak up now if you have any objections or comments.
> 
> Looks good to me, but question is what is this based upon?
> 
> I strongly assume drm-next, so question is now if we have any patches
> inside amd branches we should apply before doing this.
> 
> CCing Andrey as well cause he has some tasks assigned around the
> scheduler as well.
> 
> Regards,
> Christian.
> 
> > 
> > Regards,
> > Lucas
> > 
> > Lucas Stach (2):
> >    drm: move amd_gpu_scheduler into common location
> >    drm/sched: move fence slab handling to module init/exit
> > 
> >   drivers/gpu/drm/Kconfig|   5 +
> >   drivers/gpu/drm/Makefile   |   1 +
> >   drivers/gpu/drm/amd/amdgpu/Makefile|   5 +-
> >   drivers/gpu/drm/amd/amdgpu/amdgpu.h|  16 +-
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c |   8 +-
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c|  38 +--
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  12 +-
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|   8 -
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c  |   4 +-
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_job.c|  22 +-
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c   |  14 +-
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h   |  12 +-
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c  |  20 +-
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_sched.h  |   2 +-
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c   |   6 +-
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c|   8 +-
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h|   4 +-
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c|   8 +-
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.h|   4 +-
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c|   8 +-
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_vce.h|   2 +-
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c|  14 +-
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h|   4 +-
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c |  10 +-
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h |   4 +-
> >   drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c  |   4 +-
> >   drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c  |   8 +-
> >   drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c  |   8 +-
> >   drivers/gpu/drm/amd/scheduler/gpu_scheduler.h  | 185 
> > --
> >   drivers/gpu/drm/scheduler/Makefile |   4 +
> >   .../gpu/drm/{amd => }/scheduler/gpu_scheduler.c| 281
> > +++--
> >   drivers/gpu/drm/{amd => }/scheduler/sched_fence.c  | 122 +---
> > -
> >   include/drm/gpu_scheduler.h| 171
> > +
> >   .../drm/gpu_scheduler_trace.h  |  14 +-
> >   34 files changed, 525 insertions(+), 511 deletions(-)
> >   delete mode 100644 drivers/gpu/drm/amd/scheduler/gpu_scheduler.h
> >   create mode 100644 drivers/gpu/drm/scheduler/Makefile
> >   rename drivers/gpu/drm/{amd => }/scheduler/gpu_scheduler.c (64%)
> >   rename drivers/gpu/drm/{amd => }/scheduler/sched_fence.c (58%)
> >   create mode 100644 include/drm/gpu_scheduler.h
> >   rename drivers/gpu/drm/amd/scheduler/gpu_sched_trace.h => 
> > include/drm/gpu_scheduler_trace.h (83%)
> > 
> 
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list