Re: [PATCH 1/7] drm/bridge: Support hotplugging panel-bridge.

[Archit Taneja]

On 06/16/2017 02:11 AM, Eric Anholt wrote:

If the panel-bridge is being set up after the drm_mode_config_reset(),
then the connector's state would never get initialized, and we'd
dereference the NULL in the hotplug path.  We also need to register
the connector, so that userspace can get at it.



Shouldn't the KMS driver make sure the panel-bridge is set up before
drm_mode_config_reset? Is it the case when we're inserting the
panel-bridge driver as a module?


All the connectors that have been added are registered automatically
when drm_dev_register() is called by the KMS driver. Registering a
connector in the middle of setting up our driver is prone to race
conditions if the userspace decides to use them immediately.

Thanks,
Archit


Signed-off-by: Eric Anholt 
---
  drivers/gpu/drm/bridge/panel.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
index 67fe19e5a9c6..8ed8a70799c7 100644
--- a/drivers/gpu/drm/bridge/panel.c
+++ b/drivers/gpu/drm/bridge/panel.c
@@ -82,11 +82,14 @@ static int panel_bridge_attach(struct drm_bridge *bridge)
  
  	drm_mode_connector_attach_encoder(_bridge->connector,

  bridge->encoder);
+   drm_atomic_helper_connector_reset(_bridge->connector);
  
  	ret = drm_panel_attach(panel_bridge->panel, _bridge->connector);

if (ret < 0)
return ret;
  
+	drm_connector_register(_bridge->connector);

+
return 0;
  }
  



--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/vc4: update cursors asynchronously through atomic

[Gustavo Padovan]

From: Gustavo Padovan 

Add support for async updates of cursors by using the new atomic
interface for that. Basically what this commit does is do what
vc4_update_plane() did but through atomic.

v5: add missing call to vc4_plane_atomic_check() (Eric Anholt)

v4: add drm_atomic_helper_async() commit (Eric Anholt)

v3: move size checks back to drivers (Ville Syrjälä)

v2: move fb setting to core and use new state (Eric Anholt)

Cc: Eric Anholt 
Signed-off-by: Gustavo Padovan 
Reviewed-by: Eric Anholt 
Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_kms.c   |  20 
 drivers/gpu/drm/vc4/vc4_plane.c | 100 +++-
 2 files changed, 57 insertions(+), 63 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index 928d191..08ff231 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -113,6 +113,26 @@ static int vc4_atomic_commit(struct drm_device *dev,
struct drm_plane *plane;
struct drm_plane_state *new_state;
 
+   if (state->async_update) {
+   ret = down_interruptible(>async_modeset);
+   if (ret)
+   return ret;
+
+   ret = drm_atomic_helper_prepare_planes(dev, state);
+   if (ret) {
+   up(>async_modeset);
+   return ret;
+   }
+
+   drm_atomic_helper_async_commit(dev, state);
+
+   drm_atomic_helper_cleanup_planes(dev, state);
+
+   up(>async_modeset);
+
+   return 0;
+   }
+
c = commit_init(state);
if (!c)
return -ENOMEM;
diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index da18dec..c0c2c49 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -736,70 +736,41 @@ void vc4_plane_async_set_fb(struct drm_plane *plane, 
struct drm_framebuffer *fb)
vc4_state->dlist[vc4_state->ptr0_offset] = addr;
 }
 
-static const struct drm_plane_helper_funcs vc4_plane_helper_funcs = {
-   .atomic_check = vc4_plane_atomic_check,
-   .atomic_update = vc4_plane_atomic_update,
-};
-
-static void vc4_plane_destroy(struct drm_plane *plane)
-{
-   drm_plane_helper_disable(plane);
-   drm_plane_cleanup(plane);
-}
-
-/* Implements immediate (non-vblank-synced) updates of the cursor
- * position, or falls back to the atomic helper otherwise.
- */
-static int
-vc4_update_plane(struct drm_plane *plane,
-struct drm_crtc *crtc,
-struct drm_framebuffer *fb,
-int crtc_x, int crtc_y,
-unsigned int crtc_w, unsigned int crtc_h,
-uint32_t src_x, uint32_t src_y,
-uint32_t src_w, uint32_t src_h,
-struct drm_modeset_acquire_ctx *ctx)
+static int vc4_plane_atomic_async_check(struct drm_plane *plane,
+   struct drm_plane_state *state)
 {
-   struct drm_plane_state *plane_state;
-   struct vc4_plane_state *vc4_state;
-
-   if (plane != crtc->cursor)
-   goto out;
-
-   plane_state = plane->state;
-   vc4_state = to_vc4_plane_state(plane_state);
+   if (plane != state->crtc->cursor)
+   return -EINVAL;
 
-   if (!plane_state)
-   goto out;
+   if (!plane->state)
+   return -EINVAL;
 
/* No configuring new scaling in the fast path. */
-   if (crtc_w != plane_state->crtc_w ||
-   crtc_h != plane_state->crtc_h ||
-   src_w != plane_state->src_w ||
-   src_h != plane_state->src_h) {
-   goto out;
+   if (state->crtc_w != plane->state->crtc_w ||
+   state->crtc_h != plane->state->crtc_h ||
+   state->src_w != plane->state->src_w ||
+   state->src_h != plane->state->src_h) {
+   return -EINVAL;
}
 
-   if (fb != plane_state->fb) {
-   drm_atomic_set_fb_for_plane(plane->state, fb);
-   vc4_plane_async_set_fb(plane, fb);
-   }
+   return 0;
+}
 
-   /* Set the cursor's position on the screen.  This is the
-* expected change from the drm_mode_cursor_universal()
-* helper.
-*/
-   plane_state->crtc_x = crtc_x;
-   plane_state->crtc_y = crtc_y;
+static void vc4_plane_atomic_async_update(struct drm_plane *plane,
+ struct drm_plane_state *new_state)
+{
+   struct vc4_plane_state *vc4_state = to_vc4_plane_state(plane->state);
 
-   /* Allow changing the start position within the cursor BO, if
-* that matters.
-*/
-   plane_state->src_x = src_x;
-   plane_state->src_y = src_y;
+   plane->state->src_x = new_state->src_x;
+   plane->state->src_y = new_state->src_y;
+   

[PATCH 1/2] rnndb: hdmi: Fix HDMI timing bitfields for 8x96

[Archit Taneja]

Signed-off-by: Archit Taneja 
---
 rnndb/hdmi/hdmi.xml | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/rnndb/hdmi/hdmi.xml b/rnndb/hdmi/hdmi.xml
index 69b4828..2bbae43 100644
--- a/rnndb/hdmi/hdmi.xml
+++ b/rnndb/hdmi/hdmi.xml
@@ -457,25 +457,25 @@ xsi:schemaLocation="http://nouveau.freedesktop.org/ 
rules-ng.xsd">

 

-   
+   



-   
-   
+   
+   



-   
-   
+   
+   


-   
-   
+   
+   



-   
+   



-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

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

[PATCH 2/2] rnndb: hdmi: Add register HDMI_INFOFRAME_CTRL1

[Archit Taneja]

Signed-off-by: Archit Taneja 
---
 rnndb/hdmi/hdmi.xml | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/rnndb/hdmi/hdmi.xml b/rnndb/hdmi/hdmi.xml
index 2bbae43..76d88a1 100644
--- a/rnndb/hdmi/hdmi.xml
+++ b/rnndb/hdmi/hdmi.xml
@@ -94,6 +94,12 @@ xsi:schemaLocation="http://nouveau.freedesktop.org/ 
rules-ng.xsd">



+   
+   
+   
+   
+   
+   

[PATCH 1/3] drm/msm/hdmi: 8996 PLL: Populate unprepare

[Archit Taneja]

Without doing anything in unprepare, the HDMI driver isn't able to
switch modes successfully. Calling set_rate with a new rate results
in an un-locked PLL.

If we reset the PLL in unprepare, the PLL is able to lock with the
new rate.

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/msm/hdmi/hdmi_phy_8996.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_phy_8996.c 
b/drivers/gpu/drm/msm/hdmi/hdmi_phy_8996.c
index 143eab46ba68..1fb7645cc721 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_phy_8996.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_phy_8996.c
@@ -670,6 +670,11 @@ static unsigned long hdmi_8996_pll_recalc_rate(struct 
clk_hw *hw,
 
 static void hdmi_8996_pll_unprepare(struct clk_hw *hw)
 {
+   struct hdmi_pll_8996 *pll = hw_clk_to_pll(hw);
+   struct hdmi_phy *phy = pll_get_phy(pll);
+
+   hdmi_phy_write(phy, REG_HDMI_8996_PHY_CFG, 0x6);
+   usleep_range(100, 150);
 }
 
 static int hdmi_8996_pll_is_enabled(struct clk_hw *hw)
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

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

[PATCH 2/3] drm/msm/hdmi: Updated generated headers

[Archit Taneja]

- Add HDMI_INFOFRAME_CONTROL1 register and its bitfields.

- Fix up the HDMI timing registers bitfield widths to 13 bits so that
  values greater than 4095 can be written to them. The older chips
  (APQ8064 etc) only have 12 bit width for these fields, but KMS won't
  let them try to write widths > 4095 anyway.

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/msm/hdmi/hdmi.xml.h | 59 -
 1 file changed, 38 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.xml.h 
b/drivers/gpu/drm/msm/hdmi/hdmi.xml.h
index 0a97ff75ed6f..e4b9753b9d57 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.xml.h
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.xml.h
@@ -8,19 +8,10 @@ This file was generated by the rules-ng-ng headergen tool in 
this git repository
 git clone https://github.com/freedreno/envytools.git
 
 The rules-ng-ng source files this header was generated from are:
-- /home/robclark/src/freedreno/envytools/rnndb/msm.xml (
676 bytes, from 2015-05-20 20:03:14)
-- /home/robclark/src/freedreno/envytools/rnndb/freedreno_copyright.xml (   
1572 bytes, from 2016-02-10 17:07:21)
-- /home/robclark/src/freedreno/envytools/rnndb/mdp/mdp4.xml(  
20915 bytes, from 2015-05-20 20:03:14)
-- /home/robclark/src/freedreno/envytools/rnndb/mdp/mdp_common.xml  (   
2849 bytes, from 2015-09-18 12:07:28)
-- /home/robclark/src/freedreno/envytools/rnndb/mdp/mdp5.xml(  
36965 bytes, from 2016-11-26 23:01:08)
-- /home/robclark/src/freedreno/envytools/rnndb/dsi/dsi.xml (  
27887 bytes, from 2015-10-22 16:34:52)
-- /home/robclark/src/freedreno/envytools/rnndb/dsi/sfpb.xml(
602 bytes, from 2015-10-22 16:35:02)
-- /home/robclark/src/freedreno/envytools/rnndb/dsi/mmss_cc.xml (   
1686 bytes, from 2015-05-20 20:03:14)
-- /home/robclark/src/freedreno/envytools/rnndb/hdmi/qfprom.xml (
600 bytes, from 2015-05-20 20:03:07)
-- /home/robclark/src/freedreno/envytools/rnndb/hdmi/hdmi.xml   (  
41472 bytes, from 2016-01-22 18:18:18)
-- /home/robclark/src/freedreno/envytools/rnndb/edp/edp.xml (  
10416 bytes, from 2015-05-20 20:03:14)
-
-Copyright (C) 2013-2016 by the following authors:
+- /local/mnt/workspace/source_trees/envytools/rnndb/../rnndb/hdmi/hdmi.xml  (  
41799 bytes, from 2017-06-16 04:34:09)
+- /local/mnt/workspace/source_trees/envytools/rnndb/freedreno_copyright.xml (  
 1572 bytes, from 2016-05-09 06:32:54)
+
+Copyright (C) 2013-2017 by the following authors:
 - Rob Clark  (robclark)
 - Ilia Mirkin  (imirkin)
 
@@ -111,6 +102,32 @@ static inline uint32_t 
HDMI_ACR_PKT_CTRL_N_MULTIPLIER(uint32_t val)
 #define HDMI_INFOFRAME_CTRL0_AUDIO_INFO_SOURCE 0x0040
 #define HDMI_INFOFRAME_CTRL0_AUDIO_INFO_UPDATE 0x0080
 
+#define REG_HDMI_INFOFRAME_CTRL1   0x0030
+#define HDMI_INFOFRAME_CTRL1_AVI_INFO_LINE__MASK   0x003f
+#define HDMI_INFOFRAME_CTRL1_AVI_INFO_LINE__SHIFT  0
+static inline uint32_t HDMI_INFOFRAME_CTRL1_AVI_INFO_LINE(uint32_t val)
+{
+   return ((val) << HDMI_INFOFRAME_CTRL1_AVI_INFO_LINE__SHIFT) & 
HDMI_INFOFRAME_CTRL1_AVI_INFO_LINE__MASK;
+}
+#define HDMI_INFOFRAME_CTRL1_AUDIO_INFO_LINE__MASK 0x3f00
+#define HDMI_INFOFRAME_CTRL1_AUDIO_INFO_LINE__SHIFT8
+static inline uint32_t HDMI_INFOFRAME_CTRL1_AUDIO_INFO_LINE(uint32_t val)
+{
+   return ((val) << HDMI_INFOFRAME_CTRL1_AUDIO_INFO_LINE__SHIFT) & 
HDMI_INFOFRAME_CTRL1_AUDIO_INFO_LINE__MASK;
+}
+#define HDMI_INFOFRAME_CTRL1_MPEG_INFO_LINE__MASK  0x003f
+#define HDMI_INFOFRAME_CTRL1_MPEG_INFO_LINE__SHIFT 16
+static inline uint32_t HDMI_INFOFRAME_CTRL1_MPEG_INFO_LINE(uint32_t val)
+{
+   return ((val) << HDMI_INFOFRAME_CTRL1_MPEG_INFO_LINE__SHIFT) & 
HDMI_INFOFRAME_CTRL1_MPEG_INFO_LINE__MASK;
+}
+#define HDMI_INFOFRAME_CTRL1_VENSPEC_INFO_LINE__MASK   0x3f00
+#define HDMI_INFOFRAME_CTRL1_VENSPEC_INFO_LINE__SHIFT  24
+static inline uint32_t HDMI_INFOFRAME_CTRL1_VENSPEC_INFO_LINE(uint32_t val)
+{
+   return ((val) << HDMI_INFOFRAME_CTRL1_VENSPEC_INFO_LINE__SHIFT) & 
HDMI_INFOFRAME_CTRL1_VENSPEC_INFO_LINE__MASK;
+}
+
 #define REG_HDMI_GEN_PKT_CTRL  0x0034
 #define HDMI_GEN_PKT_CTRL_GENERIC0_SEND
0x0001
 #define HDMI_GEN_PKT_CTRL_GENERIC0_CONT
0x0002
@@ -463,7 +480,7 @@ static inline uint32_t HDMI_DDC_REF_REFTIMER(uint32_t val)
 #define REG_HDMI_CEC_RD_FILTER 0x02b0
 
 #define REG_HDMI_ACTIVE_HSYNC  0x02b4
-#define HDMI_ACTIVE_HSYNC_START__MASK  0x0fff
+#define HDMI_ACTIVE_HSYNC_START__MASK  0x1fff
 #define HDMI_ACTIVE_HSYNC_START__SHIFT 

[PATCH 3/3] drm/msm/hdmi: Fix HDMI pink strip issue seen on 8x96

[Archit Taneja]

A 2 pixel wide pink strip was observed on the left end of some HDMI
monitors configured in a HDMI mode.

It turned out that we were missing out on configuring AVI infoframes, and
unlike APQ8064, the 8x96 HDMI H/W seems to be sensitive to that.

Add configuration of AVI infoframes. While at it, make sure that
hdmi_audio_update is only called when we've detected that the monitor
supports HDMI.

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 70 --
 1 file changed, 67 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c 
b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
index 4e6d1bf27474..ae40e7179d4f 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
@@ -86,6 +86,65 @@ static void power_off(struct drm_bridge *bridge)
}
 }
 
+#define AVI_IFRAME_LINE_NUMBER 1
+
+static void msm_hdmi_config_avi_infoframe(struct hdmi *hdmi)
+{
+   struct drm_crtc *crtc = hdmi->encoder->crtc;
+   const struct drm_display_mode *mode = >state->adjusted_mode;
+   union hdmi_infoframe frame;
+   u8 buffer[HDMI_INFOFRAME_SIZE(AVI)];
+   u32 val;
+   int len;
+
+   drm_hdmi_avi_infoframe_from_display_mode(, mode);
+
+   len = hdmi_infoframe_pack(, buffer, sizeof(buffer));
+   if (len < 0) {
+   dev_err(>pdev->dev,
+   "failed to configure avi infoframe\n");
+   return;
+   }
+
+   /*
+* the AVI_INFOx registers don't map exactly to how the AVI infoframes
+* are packed according to the spec. The checksum from the header is
+* written to the LSB byte of AVI_INFO0 and the version is written to
+* the third byte from the LSB of AVI_INFO3
+*/
+   hdmi_write(hdmi, REG_HDMI_AVI_INFO(0),
+  buffer[3] |
+  buffer[4] << 8 |
+  buffer[5] << 16 |
+  buffer[6] << 24);
+
+   hdmi_write(hdmi, REG_HDMI_AVI_INFO(1),
+  buffer[7] |
+  buffer[8] << 8 |
+  buffer[9] << 16 |
+  buffer[10] << 24);
+
+   hdmi_write(hdmi, REG_HDMI_AVI_INFO(2),
+  buffer[11] |
+  buffer[12] << 8 |
+  buffer[13] << 16 |
+  buffer[14] << 24);
+
+   hdmi_write(hdmi, REG_HDMI_AVI_INFO(3),
+  buffer[15] |
+  buffer[16] << 8 |
+  buffer[1] << 24);
+
+   hdmi_write(hdmi, REG_HDMI_INFOFRAME_CTRL0,
+  HDMI_INFOFRAME_CTRL0_AVI_SEND |
+  HDMI_INFOFRAME_CTRL0_AVI_CONT);
+
+   val = hdmi_read(hdmi, REG_HDMI_INFOFRAME_CTRL1);
+   val &= ~HDMI_INFOFRAME_CTRL1_AVI_INFO_LINE__MASK;
+   val |= HDMI_INFOFRAME_CTRL1_AVI_INFO_LINE(AVI_IFRAME_LINE_NUMBER);
+   hdmi_write(hdmi, REG_HDMI_INFOFRAME_CTRL1, val);
+}
+
 static void msm_hdmi_bridge_pre_enable(struct drm_bridge *bridge)
 {
struct hdmi_bridge *hdmi_bridge = to_hdmi_bridge(bridge);
@@ -98,7 +157,10 @@ static void msm_hdmi_bridge_pre_enable(struct drm_bridge 
*bridge)
msm_hdmi_phy_resource_enable(phy);
msm_hdmi_power_on(bridge);
hdmi->power_on = true;
-   msm_hdmi_audio_update(hdmi);
+   if (hdmi->hdmi_mode) {
+   msm_hdmi_config_avi_infoframe(hdmi);
+   msm_hdmi_audio_update(hdmi);
+   }
}
 
msm_hdmi_phy_powerup(phy, hdmi->pixclock);
@@ -134,7 +196,8 @@ static void msm_hdmi_bridge_post_disable(struct drm_bridge 
*bridge)
if (hdmi->power_on) {
power_off(bridge);
hdmi->power_on = false;
-   msm_hdmi_audio_update(hdmi);
+   if (hdmi->hdmi_mode)
+   msm_hdmi_audio_update(hdmi);
msm_hdmi_phy_resource_disable(phy);
}
 }
@@ -196,7 +259,8 @@ static void msm_hdmi_bridge_mode_set(struct drm_bridge 
*bridge,
DBG("frame_ctrl=%08x", frame_ctrl);
hdmi_write(hdmi, REG_HDMI_FRAME_CTRL, frame_ctrl);
 
-   msm_hdmi_audio_update(hdmi);
+   if (hdmi->hdmi_mode)
+   msm_hdmi_audio_update(hdmi);
 }
 
 static const struct drm_bridge_funcs msm_hdmi_bridge_funcs = {
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

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

[PATCH 0/3] drm/msm/hdmi: Some HDMI fixes for 8x96

[Archit Taneja]

Some fixes that makes HDMI more stable on 8x96:

- Make PLL switch to different freqs successfully (when switching between
  modes).
- Add AVI infoframes to reemove the pink strips seen on some monitors.
- Update some of the HDMI timing bitfields so that they can take in
  values > 4K.

The display bindings for 8x96 aren't in yet, so it's okay to have these
for 4.13.

Archit Taneja (3):
  drm/msm/hdmi: 8996 PLL: Populate unprepare
  drm/msm/hdmi: Updated generated headers
  drm/msm/hdmi: Fix HDMI pink strip issue seen on 8x96

 drivers/gpu/drm/msm/hdmi/hdmi.xml.h  | 59 +--
 drivers/gpu/drm/msm/hdmi/hdmi_bridge.c   | 70 ++--
 drivers/gpu/drm/msm/hdmi/hdmi_phy_8996.c |  5 +++
 3 files changed, 110 insertions(+), 24 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

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

R7-250X: Vulkan: Doom lockups.

[Mike Mestnik]

I can tell by the 2 color(green and violet) rendering that this driver
is experimental.  Attached is kern.log from some testing I've done.
Jun 15 22:14:47 agartha kernel: [0.00] Command line: 
BOOT_IMAGE=/vmlinuz-4.11.0-trunk-amd64 
root=UUID=05127f71-6704-4c13-9401-48496c61e0fe ro 
rootflags=subvol=root-amd64-i386 quiet rootflags=subvolid=261
Jun 15 22:14:47 agartha kernel: [0.00] x86/fpu: Supporting XSAVE 
feature 0x001: 'x87 floating point registers'
Jun 15 22:14:47 agartha kernel: [0.00] x86/fpu: Supporting XSAVE 
feature 0x002: 'SSE registers'
Jun 15 22:14:47 agartha kernel: [0.00] x86/fpu: Supporting XSAVE 
feature 0x004: 'AVX registers'
Jun 15 22:14:47 agartha kernel: [0.00] x86/fpu: xstate_offset[2]:  576, 
xstate_sizes[2]:  256
Jun 15 22:14:47 agartha kernel: [0.00] x86/fpu: Enabled xstate features 
0x7, context size is 832 bytes, using 'standard' format.
Jun 15 22:14:47 agartha kernel: [0.00] e820: BIOS-provided physical RAM 
map:
Jun 15 22:14:47 agartha kernel: [0.00] BIOS-e820: [mem 
0x-0x0009] usable
Jun 15 22:14:47 agartha kernel: [0.00] BIOS-e820: [mem 
0x0010-0xdcf9bfff] usable
Jun 15 22:14:47 agartha kernel: [0.00] BIOS-e820: [mem 
0xdcf9c000-0xdcfcbfff] reserved
Jun 15 22:14:47 agartha kernel: [0.00] BIOS-e820: [mem 
0xdcfcc000-0xdcfdbfff] ACPI data
Jun 15 22:14:47 agartha kernel: [0.00] BIOS-e820: [mem 
0xdcfdc000-0xdd654fff] ACPI NVS
Jun 15 22:14:47 agartha kernel: [0.00] BIOS-e820: [mem 
0xdd655000-0xde3e2fff] reserved
Jun 15 22:14:47 agartha kernel: [0.00] BIOS-e820: [mem 
0xde3e3000-0xde43efff] type 20
Jun 15 22:14:47 agartha kernel: [0.00] BIOS-e820: [mem 
0xde43f000-0xde43] usable
Jun 15 22:14:47 agartha kernel: [0.00] BIOS-e820: [mem 
0xde44-0xde645fff] ACPI NVS
Jun 15 22:14:47 agartha kernel: [0.00] BIOS-e820: [mem 
0xde646000-0xdea82fff] usable
Jun 15 22:14:47 agartha kernel: [0.00] BIOS-e820: [mem 
0xdea83000-0xdeff3fff] reserved
Jun 15 22:14:47 agartha kernel: [0.00] BIOS-e820: [mem 
0xdeff4000-0xdeff] usable
Jun 15 22:14:47 agartha kernel: [0.00] BIOS-e820: [mem 
0xf800-0xfbff] reserved
Jun 15 22:14:47 agartha kernel: [0.00] BIOS-e820: [mem 
0xfeb8-0xfec01fff] reserved
Jun 15 22:14:47 agartha kernel: [0.00] BIOS-e820: [mem 
0xfec1-0xfec10fff] reserved
Jun 15 22:14:47 agartha kernel: [0.00] BIOS-e820: [mem 
0xfed0-0xfed00fff] reserved
Jun 15 22:14:47 agartha kernel: [0.00] BIOS-e820: [mem 
0xfed8-0xfed8] reserved
Jun 15 22:14:47 agartha kernel: [0.00] BIOS-e820: [mem 
0xff00-0x] reserved
Jun 15 22:14:47 agartha kernel: [0.00] BIOS-e820: [mem 
0x0001-0x00041eff] usable
Jun 15 22:14:47 agartha kernel: [0.00] NX (Execute Disable) protection: 
active
Jun 15 22:14:47 agartha kernel: [0.00] efi: EFI v32.31 by American 
Megatrends
Jun 15 22:14:47 agartha kernel: [0.00] efi:  ACPI=0xdcfd3000  ACPI 
2.0=0xdcfd3000  SMBIOS=0xf04c0  MPS=0xfd490 
Jun 15 22:14:47 agartha kernel: [0.00] SMBIOS 2.7 present.
Jun 15 22:14:47 agartha kernel: [0.00] DMI: System manufacturer System 
Product Name/A88X-PRO, BIOS 1902 03/27/2015
Jun 15 22:14:47 agartha kernel: [0.00] e820: update [mem 
0x-0x0fff] usable ==> reserved
Jun 15 22:14:47 agartha kernel: [0.00] e820: remove [mem 
0x000a-0x000f] usable
Jun 15 22:14:47 agartha kernel: [0.00] e820: last_pfn = 0x41f000 
max_arch_pfn = 0x4
Jun 15 22:14:47 agartha kernel: [0.00] MTRR default type: uncachable
Jun 15 22:14:47 agartha kernel: [0.00] MTRR fixed ranges enabled:
Jun 15 22:14:47 agartha kernel: [0.00]   0-9 write-back
Jun 15 22:14:47 agartha kernel: [0.00]   A-B write-through
Jun 15 22:14:47 agartha kernel: [0.00]   C-C write-protect
Jun 15 22:14:47 agartha kernel: [0.00]   D-D uncachable
Jun 15 22:14:47 agartha kernel: [0.00]   E-F write-protect
Jun 15 22:14:47 agartha kernel: [0.00] MTRR variable ranges enabled:
Jun 15 22:14:47 agartha kernel: [0.00]   0 base  mask 
8000 write-back
Jun 15 22:14:47 agartha kernel: [0.00]   1 base 8000 mask 
C000 write-back
Jun 15 22:14:47 agartha kernel: [0.00]   2 base C000 mask 
E000 write-back
Jun 15 22:14:47 agartha kernel: [0.00]   3 disabled
Jun 15 22:14:47 agartha kernel: [0.00]   4 disabled
Jun 15 22:14:47 agartha kernel: [0.00]   5 disabled
Jun 

[git pull] drm fixes for 4.12-rc6

[Dave Airlie]

Hi Linus,

This is the main fixes pull for 4.12-rc6, all pretty normal for this
stage, nothing really stands out. The mxsfb one is probably the
largest and it's for a black screen boot problem.

Dave.

The following changes since commit 32c1431eea4881a6b17bd7c639315010aeefa452:

  Linux 4.12-rc5 (2017-06-11 16:48:20 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.12-rc6

for you to fetch changes up to 7119dbdf7c52042acb1b02f116fa3257e97659ea:

  Merge tag 'drm-intel-fixes-2017-06-15' of
git://anongit.freedesktop.org/git/drm-intel into drm-fixes (2017-06-16
10:01:52 +1000)


amd, i915, mgag200, msxfb, tegra fixes


Christian König (1):
  drm/radeon: fix "force the UVD DPB into VRAM as well"

Christophe JAILLET (1):
  gpu: host1x: Fix error handling

Dave Airlie (3):
  Merge branch 'drm-fixes-4.12' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes
  Merge tag 'drm-misc-fixes-2017-06-15' of
git://anongit.freedesktop.org/git/drm-misc into drm-fixes
  Merge tag 'drm-intel-fixes-2017-06-15' of
git://anongit.freedesktop.org/git/drm-intel into drm-fixes

Dmitry Osipenko (2):
  drm/tegra: Fix lockup on a use of staging API
  drm/tegra: Correct idr_alloc() minimum id

Fabio Estevam (1):
  drm: mxsfb_crtc: Reset the eLCDIF controller

Laurent Pinchart (1):
  drm: dw-hdmi: Fix compilation breakage by selecting REGMAP_MMIO

Mario Kleiner (2):
  drm/amdgpu: Fix overflow of watermark calcs at > 4k resolutions.
  drm/radeon: Fix overflow of watermark calcs at > 4k resolutions.

Mathieu Larouche (1):
  drm/mgag200: Fix to always set HiPri for G200e4 V2

Ville Syrjälä (2):
  drm/i915: Fix scaling check for 90/270 degree plane rotation
  drm/i915: Fix SKL+ watermarks for 90/270 rotation

Zhenyu Wang (1):
  drm/i915: Fix GVT-g PVINFO version compatibility check

 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c  |  7 --
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c  |  7 --
 drivers/gpu/drm/amd/amdgpu/dce_v6_0.c   |  7 --
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c   |  7 --
 drivers/gpu/drm/bridge/synopsys/Kconfig |  1 +
 drivers/gpu/drm/i915/i915_pvinfo.h  |  8 ++-
 drivers/gpu/drm/i915/i915_vgpu.c| 10 
 drivers/gpu/drm/i915/intel_display.c| 14 ++-
 drivers/gpu/drm/i915/intel_pm.c | 36 ++--
 drivers/gpu/drm/mgag200/mgag200_mode.c  |  9 ++-
 drivers/gpu/drm/mxsfb/mxsfb_crtc.c  | 42 +
 drivers/gpu/drm/radeon/cik.c|  7 --
 drivers/gpu/drm/radeon/evergreen.c  |  7 --
 drivers/gpu/drm/radeon/radeon_uvd.c |  2 +-
 drivers/gpu/drm/radeon/si.c |  7 --
 drivers/gpu/drm/tegra/drm.c | 22 -
 drivers/gpu/host1x/dev.c|  2 +-
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] amdgpu: use drm sync objects for shared semaphores (v5)

[Dave Airlie]

From: Dave Airlie 

This creates a new command submission chunk for amdgpu
to add in and out sync objects around the submission.

Sync objects are managed via the drm syncobj ioctls.

The command submission interface is enhanced with two new
chunks, one for syncobj pre submission dependencies,
and one for post submission sync obj signalling,
and just takes a list of handles for each.

This is based on work originally done by David Zhou at AMD,
with input from Christian Konig on what things should look like.

In theory VkFences could be backed with sync objects and
just get passed into the cs as syncobj handles as well.

NOTE: this interface addition needs a version bump to expose
it to userspace.

TODO: update to dep_sync when rebasing onto amdgpu master.
(with this - r-b from Christian)

v1.1: keep file reference on import.
v2: move to using syncobjs
v2.1: change some APIs to just use p pointer.
v3: make more robust against CS failures, we now add the
wait sems but only remove them once the CS job has been
submitted.
v4: rewrite names of API and base on new syncobj code.
v5: move post deps earlier, rename some apis
v6: lookup post deps earlier, and just replace fences
in post deps stage (Christian)

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h |  3 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c  | 88 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c |  2 +-
 include/uapi/drm/amdgpu_drm.h   |  6 +++
 4 files changed, 97 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index e0adad5..9f827ac 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1159,6 +1159,9 @@ struct amdgpu_cs_parser {
 
/* user fence */
struct amdgpu_bo_list_entry uf_entry;
+
+   unsigned num_post_dep_syncobjs;
+   struct drm_syncobj **post_dep_syncobjs;
 };
 
 #define AMDGPU_PREAMBLE_IB_PRESENT  (1 << 0) /* bit set means command 
submit involves a preamble IB */
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 29469e6..aeee684 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "amdgpu.h"
 #include "amdgpu_trace.h"
 
@@ -154,6 +155,8 @@ int amdgpu_cs_parser_init(struct amdgpu_cs_parser *p, void 
*data)
break;
 
case AMDGPU_CHUNK_ID_DEPENDENCIES:
+   case AMDGPU_CHUNK_ID_SYNCOBJ_IN:
+   case AMDGPU_CHUNK_ID_SYNCOBJ_OUT:
break;
 
default:
@@ -682,6 +685,11 @@ static void amdgpu_cs_parser_fini(struct amdgpu_cs_parser 
*parser, int error, bo
ttm_eu_backoff_reservation(>ticket,
   >validated);
}
+
+   for (i = 0; i < parser->num_post_dep_syncobjs; i++)
+   drm_syncobj_put(parser->post_dep_syncobjs[i]);
+   kfree(parser->post_dep_syncobjs);
+
dma_fence_put(parser->fence);
 
if (parser->ctx)
@@ -971,6 +979,64 @@ static int amdgpu_cs_process_fence_dep(struct 
amdgpu_cs_parser *p,
return 0;
 }
 
+static int amdgpu_syncobj_lookup_and_add_to_sync(struct amdgpu_cs_parser *p,
+uint32_t handle)
+{
+   int r;
+   struct dma_fence *fence;
+   r = drm_syncobj_fence_get(p->filp, handle, );
+   if (r)
+   return r;
+
+   r = amdgpu_sync_fence(p->adev, >job->sync, fence);
+   dma_fence_put(fence);
+
+   return r;
+}
+
+static int amdgpu_cs_process_syncobj_in_dep(struct amdgpu_cs_parser *p,
+   struct amdgpu_cs_chunk *chunk)
+{
+   unsigned num_deps;
+   int i, r;
+   struct drm_amdgpu_cs_chunk_sem *deps;
+
+   deps = (struct drm_amdgpu_cs_chunk_sem *)chunk->kdata;
+   num_deps = chunk->length_dw * 4 /
+   sizeof(struct drm_amdgpu_cs_chunk_sem);
+
+   for (i = 0; i < num_deps; ++i) {
+   r = amdgpu_syncobj_lookup_and_add_to_sync(p, deps[i].handle);
+   if (r)
+   return r;
+   }
+   return 0;
+}
+
+static int amdgpu_cs_process_syncobj_out_dep(struct amdgpu_cs_parser *p,
+struct amdgpu_cs_chunk *chunk)
+{
+   unsigned num_deps;
+   int i;
+   struct drm_amdgpu_cs_chunk_sem *deps;
+   deps = (struct drm_amdgpu_cs_chunk_sem *)chunk->kdata;
+   num_deps = chunk->length_dw * 4 /
+   sizeof(struct drm_amdgpu_cs_chunk_sem);
+
+   p->post_dep_syncobjs = kmalloc_array(num_deps,
+sizeof(struct drm_syncobj *),
+GFP_KERNEL);
+   p->num_post_dep_syncobjs = 0;
+
+   for (i 

[PATCH 1/2] amdgpu/cs: split out fence dependency checking (v2)

[Dave Airlie]

From: Dave Airlie 

This just splits out the fence depenency checking into it's
own function to make it easier to add semaphore dependencies.

v2: rebase onto other changes.

v1-Reviewed-by: Christian König 
Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 93 +++---
 1 file changed, 51 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index a37bdf4..29469e6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -923,59 +923,68 @@ static int amdgpu_cs_ib_fill(struct amdgpu_device *adev,
return 0;
 }
 
-static int amdgpu_cs_dependencies(struct amdgpu_device *adev,
- struct amdgpu_cs_parser *p)
+static int amdgpu_cs_process_fence_dep(struct amdgpu_cs_parser *p,
+  struct amdgpu_cs_chunk *chunk)
 {
struct amdgpu_fpriv *fpriv = p->filp->driver_priv;
-   int i, j, r;
+   unsigned num_deps;
+   int i, r;
+   struct drm_amdgpu_cs_chunk_dep *deps;
 
-   for (i = 0; i < p->nchunks; ++i) {
-   struct drm_amdgpu_cs_chunk_dep *deps;
-   struct amdgpu_cs_chunk *chunk;
-   unsigned num_deps;
+   deps = (struct drm_amdgpu_cs_chunk_dep *)chunk->kdata;
+   num_deps = chunk->length_dw * 4 /
+   sizeof(struct drm_amdgpu_cs_chunk_dep);
 
-   chunk = >chunks[i];
+   for (i = 0; i < num_deps; ++i) {
+   struct amdgpu_ring *ring;
+   struct amdgpu_ctx *ctx;
+   struct dma_fence *fence;
 
-   if (chunk->chunk_id != AMDGPU_CHUNK_ID_DEPENDENCIES)
-   continue;
+   ctx = amdgpu_ctx_get(fpriv, deps[i].ctx_id);
+   if (ctx == NULL)
+   return -EINVAL;
 
-   deps = (struct drm_amdgpu_cs_chunk_dep *)chunk->kdata;
-   num_deps = chunk->length_dw * 4 /
-   sizeof(struct drm_amdgpu_cs_chunk_dep);
+   r = amdgpu_queue_mgr_map(p->adev, >queue_mgr,
+deps[i].ip_type,
+deps[i].ip_instance,
+deps[i].ring, );
+   if (r) {
+   amdgpu_ctx_put(ctx);
+   return r;
+   }
 
-   for (j = 0; j < num_deps; ++j) {
-   struct amdgpu_ring *ring;
-   struct amdgpu_ctx *ctx;
-   struct dma_fence *fence;
+   fence = amdgpu_ctx_get_fence(ctx, ring,
+deps[i].handle);
+   if (IS_ERR(fence)) {
+   r = PTR_ERR(fence);
+   amdgpu_ctx_put(ctx);
+   return r;
+   } else if (fence) {
+   r = amdgpu_sync_fence(p->adev, >job->sync,
+ fence);
+   dma_fence_put(fence);
+   amdgpu_ctx_put(ctx);
+   if (r)
+   return r;
+   }
+   }
+   return 0;
+}
 
-   ctx = amdgpu_ctx_get(fpriv, deps[j].ctx_id);
-   if (ctx == NULL)
-   return -EINVAL;
+static int amdgpu_cs_dependencies(struct amdgpu_device *adev,
+ struct amdgpu_cs_parser *p)
+{
+   int i, r;
 
-   r = amdgpu_queue_mgr_map(adev, >queue_mgr,
-deps[j].ip_type,
-deps[j].ip_instance,
-deps[j].ring, );
-   if (r) {
-   amdgpu_ctx_put(ctx);
-   return r;
-   }
+   for (i = 0; i < p->nchunks; ++i) {
+   struct amdgpu_cs_chunk *chunk;
 
-   fence = amdgpu_ctx_get_fence(ctx, ring,
-deps[j].handle);
-   if (IS_ERR(fence)) {
-   r = PTR_ERR(fence);
-   amdgpu_ctx_put(ctx);
-   return r;
+   chunk = >chunks[i];
 
-   } else if (fence) {
-   r = amdgpu_sync_fence(adev, >job->sync,
- fence);
-   dma_fence_put(fence);
-   amdgpu_ctx_put(ctx);
-   if (r)
-   return r;
-   }
+   if (chunk->chunk_id == 

Re: [PATCH v3] drm: mxsfb_crtc: Reset the eLCDIF controller

[Stefan Agner]

On 2017-06-15 10:26, Marek Vasut wrote:
> On 06/15/2017 05:12 PM, Fabio Estevam wrote:
>> Hi Marek,
>>
>> On Mon, Jun 5, 2017 at 9:08 AM, Marek Vasut  wrote:
>>
>>> I'm currently on vacation, try one more time and if it doesn't work out
>>> (which means this trivial list is not really working?), I'll send a PR
>>> sometime mid-month.
>>
>> Tried your suggestion, but it did not work.
>>
>> Could you please consider sending Dave Airlie a pull request with this patch?
> 
> I poked the DRM people on IRC, so they should pick it up.
> 
> Stefan, can you test and add a T-B ?

Sorry, I am on vacation too, no access to actual hardware.

@Sanchayan, can you maybe check this patch on mainline?

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

Re: [PATCH 17/44] hexagon: switch to use ->mapping_error for error reporting

[Richard Kuo]

On Thu, Jun 08, 2017 at 03:25:42PM +0200, Christoph Hellwig wrote:
> Signed-off-by: Christoph Hellwig 
> ---
>  arch/hexagon/include/asm/dma-mapping.h |  2 --
>  arch/hexagon/kernel/dma.c  | 12 +---
>  arch/hexagon/kernel/hexagon_ksyms.c|  1 -
>  3 files changed, 9 insertions(+), 6 deletions(-)
> 

Acked-by: Richard Kuo 

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, 
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Color lookup support for the atmel-hlcdc driver

[Peter Rosin]

On 2017-06-13 17:30, Boris Brezillon wrote:
> Hi Peter,
> 
> On Tue, 13 Jun 2017 16:34:25 +0200
> Peter Rosin  wrote:
> 
>> Hi!
>>
>> I need color lookup support for the atmel-hlcdc driver, and had a peek
>> at the code. I also looked at the drivers/gpu/drm/stm driver and came
>> up with the below diff. It compiles, but I have not booted it for the
>> simple reason that I can't imagine it will work.
>>
>> Sure, the code fills the clut registers in the .load_lut helper function
>> and I think it might even do the right thing when setting up the mode.
>> I'm less sure DMA will work correctly? It might, but I haven't looked at
>> it for many seconds...
>>
>> The big question is how the color info gets into the new clut array
>> I created in atmel_hlcdc_crtc? When I look at the stm driver, which does
>> it just like this AFAICT I just don't see it. So, what I'm I missing?
> 
> You should look at drm_atomic_helper_legacy_gamma_set() and its users.

Ok, thanks. I had a long look and could not get it to work at all. So,
I did as below instead. However, there are a few glaring problems...

Something, somewhere, sets up default entries for the 16 first entries
of the palette and seem to expect them to stay as some kind of safe
basic palette, and my applications don't handle it too well. When they
want to draw black, they get a poisonous cyan/green instead etc. But
it's pretty close. Can anyone provide some clue as to how that is
supposed to be handled?

Also, I had to change the second argument of the drm_fbdev_cma_init...
call at the end of atmel_hlcdc_dc.c:atmel_hlcdc_dc_load() from 24 to 8
to make it possible to set 8-modes. However, doing so fucks up 24-bit
modes. Which made me suspect that no non-24-bit mode work w/o my patch.
And I could indeed only get 24-bit modes to work, unless I changed this
value to 16. Then RGB565 works like a charm, but RGB888 don't. What's
up with that? Seems like a rather silly limitation, but it's perhaps
just a bug?

Cheers,
peda


diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index 5348985..0de1047 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -61,6 +61,7 @@ struct atmel_hlcdc_crtc {
struct atmel_hlcdc_dc *dc;
struct drm_pending_vblank_event *event;
int id;
+   u32 clut[256];
 };
 
 static inline struct atmel_hlcdc_crtc *
@@ -140,6 +141,47 @@ static void atmel_hlcdc_crtc_mode_set_nofb(struct drm_crtc 
*c)
   cfg);
 }
 
+static void
+atmel_hlcdc_crtc_load_lut(struct drm_crtc *c)
+{
+   struct atmel_hlcdc_crtc *crtc = drm_crtc_to_atmel_hlcdc_crtc(c);
+   struct atmel_hlcdc_dc *dc = crtc->dc;
+   unsigned int color;
+   int layer;
+
+   for (layer = 0; layer < ATMEL_HLCDC_MAX_LAYERS; layer++) {
+   if (!dc->layers[layer])
+   continue;
+   for (color = 0; color < 256; color++)
+   atmel_hlcdc_layer_write_clut(dc->layers[layer],
+color, crtc->clut[color]);
+   }
+}
+
+void atmel_hlcdc_gamma_set(struct drm_crtc *c,
+  u16 r, u16 g, u16 b, int idx)
+{
+   struct atmel_hlcdc_crtc *crtc = drm_crtc_to_atmel_hlcdc_crtc(c);
+
+   if (idx < 0 || idx > 255)
+   return;
+
+   crtc->clut[idx] = ((r << 8) & 0xff) | (g & 0xff00) | (b >> 8);
+}
+
+void atmel_hlcdc_gamma_get(struct drm_crtc *c,
+  u16 *r, u16 *g, u16 *b, int idx)
+{
+   struct atmel_hlcdc_crtc *crtc = drm_crtc_to_atmel_hlcdc_crtc(c);
+
+   if (idx < 0 || idx > 255)
+   return;
+
+   *r = (crtc->clut[idx] >> 8) & 0xff00;
+   *g = crtc->clut[idx] & 0xff00;
+   *b = (crtc->clut[idx] << 8) & 0xff00;
+}
+
 static enum drm_mode_status
 atmel_hlcdc_crtc_mode_valid(struct drm_crtc *c,
const struct drm_display_mode *mode)
@@ -319,6 +361,7 @@ static const struct drm_crtc_helper_funcs 
lcdc_crtc_helper_funcs = {
.mode_set = drm_helper_crtc_mode_set,
.mode_set_nofb = atmel_hlcdc_crtc_mode_set_nofb,
.mode_set_base = drm_helper_crtc_mode_set_base,
+   .load_lut = atmel_hlcdc_crtc_load_lut,
.disable = atmel_hlcdc_crtc_disable,
.enable = atmel_hlcdc_crtc_enable,
.atomic_check = atmel_hlcdc_crtc_atomic_check,
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index 30dbffd..bec15f8 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -42,6 +42,7 @@ static const struct atmel_hlcdc_layer_desc 
atmel_hlcdc_at91sam9n12_layers[] = {
.default_color = 3,
.general_config = 4,
},
+   .clut_offset = 0x400,
},
 };
 
@@ -73,6 +74,7 @@ static 

Re: [PATCH 31/44] hexagon: remove arch-specific dma_supported implementation

[Richard Kuo]

On Thu, Jun 08, 2017 at 03:25:56PM +0200, Christoph Hellwig wrote:
> This implementation is simply bogus - hexagon only has a simple
> direct mapped DMA implementation and thus doesn't care about the
> address.
> 
> Signed-off-by: Christoph Hellwig 
> ---
>  arch/hexagon/include/asm/dma-mapping.h | 2 --
>  arch/hexagon/kernel/dma.c  | 9 -
>  2 files changed, 11 deletions(-)
> 

Acked-by: Richard Kuo 

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, 
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] gpu: drm: mgag200: remove unnecessary variable in mga_crtc_mode_set

[Gustavo A. R. Silva]

Remove unnecessary variable _misc_ and refactor the code.

A value is assigned to variable _misc_ at lines 1002 and 1004
and then overwritten at line 1127, just before it can be used.
Besides, this variable is only being used as an argument when
calling macro WREG8() and, it is not implied in any other
operation.

Addresses-Coverity-ID: 1397681
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/gpu/drm/mgag200/mgag200_mode.c | 13 ++---
 1 file changed, 2 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c 
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index adb411a..960e43b 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -923,7 +923,6 @@ static int mga_crtc_mode_set(struct drm_crtc *crtc,
int pitch;
int option = 0, option2 = 0;
int i;
-   unsigned char misc = 0;
unsigned char ext_vga[6];
u8 bppshift;
 
@@ -998,11 +997,6 @@ static int mga_crtc_mode_set(struct drm_crtc *crtc,
break;
}
 
-   if (mode->flags & DRM_MODE_FLAG_NHSYNC)
-   misc |= 0x40;
-   if (mode->flags & DRM_MODE_FLAG_NVSYNC)
-   misc |= 0x80;
-
 
for (i = 0; i < sizeof(dacvalue); i++) {
if ((i <= 0x17) ||
@@ -1124,8 +1118,7 @@ static int mga_crtc_mode_set(struct drm_crtc *crtc,
ext_vga[1] |= 0x88;
 
/* Set pixel clocks */
-   misc = 0x2d;
-   WREG8(MGA_MISC_OUT, misc);
+   WREG8(MGA_MISC_OUT, 0x2d);
 
mga_crtc_set_plls(mdev, mode->clock);
 
@@ -1145,9 +1138,7 @@ static int mga_crtc_mode_set(struct drm_crtc *crtc,
 
WREG_ECRT(0, ext_vga[0]);
/* Enable mga pixel clock */
-   misc = 0x2d;
-
-   WREG8(MGA_MISC_OUT, misc);
+   WREG8(MGA_MISC_OUT, 0x2d);
 
if (adjusted_mode)
memcpy(>mode, mode, sizeof(struct drm_display_mode));
-- 
2.5.0

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

Re: [BISECTED, REGRESSION] v4.12-rc: omapdrm fails to probe on Nokia N900

[Peter Ujfalusi]

On 2017-06-15 01:11, Aaro Koskinen wrote:
> Hi,
> 
> When booting v4.12-rc5 on Nokia N900, omapdrm fails to probe and there
> is no display.
> 
> Bisected to:
> 
> a09d2bc1503508c17ef3a71c6b1905e3660f3029 is the first bad commit
> commit a09d2bc1503508c17ef3a71c6b1905e3660f3029
> Author: Peter Ujfalusi 
> Date:   Tue May 3 22:08:01 2016 +0300
> 
> drm/omap: Use omapdss_stack_is_ready() to check that the display stack is 
> up
> 
> Instead of 'guessing' based on aliases of the status of the DSS drivers,
> use the new interface to check that all needed drivers are loaded.
> In this way we can be sure that all needed drivers are loaded so it is
> safe to continue the probing of omapdrm.
> This method will allow the omapdrm to be probed 'headless', without
> outputs.
> 
> Signed-off-by: Peter Ujfalusi 
> Signed-off-by: Tomi Valkeinen 
> 
> Reverting the commit seems to fix the issue.

When you revert this patch do you see a warning saying:
"could not connect display: blah" ? if so what is 'blah'?

n900 have two displays afaik, LCD and TVout. omapdss_stack_is_ready() is
to ensure that we have all the drivers loaded for both displays, while
by reverting it it is enough if one of them is loaded at the time we do
the check and omapdrm would continue to probe, but the missing display
(even if it is going to be probed a bit later) will not work.

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

Re: amdgpu display corruption and hang on AMD A10-9620P

[Carlo Caione]

On Mon, Jun 12, 2017 at 12:24 PM, Carlo Caione  wrote:
> On Tue, May 9, 2017 at 7:03 PM, Deucher, Alexander
>  wrote:
>>> -Original Message-
>>> From: Daniel Drake [mailto:dr...@endlessm.com]
>>> Sent: Tuesday, May 09, 2017 12:55 PM
>>> To: dri-devel; amd-...@lists.freedesktop.org; Deucher, Alexander
>>> Cc: Chris Chiu; Linux Upstreaming Team
>>> Subject: amdgpu display corruption and hang on AMD A10-9620P
>>>
>>> Hi,
>>>
>>> We are working with new laptops that have the AMD Bristol Ridge
>>> chipset with this SoC:
>>>
>>> AMD A10-9620P RADEON R5, 10 COMPUTE CORES 4C+6G
>>>
>>> I think this is the Bristol Ridge chipset.
>>>
>>> During boot, the display becomes unusable at the point where the
>>> amdgpu driver loads. You can see at least two horizontal lines of
>>> garbage at this point. We have reproduced on 4.8, 4.10 and linus
>>> master (early 4.12).
>>>
>>> Photo: http://pasteboard.co/qrC9mh4p.jpg
>>>
>>> Getting logs is tricky because the system appears to freeze at that point.
>>>
>>> Is this a known issue? Anything we can do to help diagnosis?
>>
>> I'm not aware of any specific issues.  Please file a bug and attach your 
>> logs (https://bugs.freedesktop.org) along with information about the system.
>
> Opened https://bugs.freedesktop.org/show_bug.cgi?id=101387 to trace
> this bug. I also have attached there the full log we get when
> modprobing amdgpu.
> Reporting here only the trace for the sake of documentation (full log
> attached to the bug opened on freedesktop)
>
> [   80.766937] ---[ end Kernel panic - not syncing: stack-protector:
> Kernel stack is corrupted in: c0c88942
> [   80.766937]
> [   80.766408] Kernel panic - not syncing: stack-protector: Kernel
> stack is corrupted in: c0c88942
> [   80.766408]
> [   80.766428] CPU: 1 PID: 1594 Comm: modprobe Not tainted 4.11.3+ #2
> [   80.766431] Hardware name: Acer Aspire A515-41G/Wartortle_BS, BIOS
> V0.09 04/19/2017
> [   80.766434] Call Trace:
> [   80.766445]  dump_stack+0x63/0x90
> [   80.766451]  panic+0xe8/0x236
> [   80.766526]  ? amdgpu_atombios_crtc_powergate_init+0x52/0x60 [amdgpu]
> [   80.766537]  __stack_chk_fail+0x1b/0x20
> [   80.766571]  amdgpu_atombios_crtc_powergate_init+0x52/0x60 [amdgpu]
> [   80.766610]  dce_v11_0_hw_init+0x3e/0x2d0 [amdgpu]
> [   80.766643]  amdgpu_device_init+0xe23/0x13c0 [amdgpu]
> [   80.766647]  ? kmalloc_order+0x18/0x40
> [   80.766650]  ? kmalloc_order_trace+0x24/0xa0
> [   80.766683]  amdgpu_driver_load_kms+0x5d/0x240 [amdgpu]
> [   80.766708]  drm_dev_register+0x148/0x1e0 [drm]
> [   80.766721]  drm_get_pci_dev+0xa0/0x160 [drm]
> [   80.766754]  amdgpu_pci_probe+0xb9/0xf0 [amdgpu]
> [   80.766759]  local_pci_probe+0x45/0xa0
> [   80.766762]  pci_device_probe+0xf4/0x150
> [   80.766768]  driver_probe_device+0x2c5/0x470
> [   80.766772]  __driver_attach+0xdf/0xf0
> [   80.766776]  ? driver_probe_device+0x470/0x470
> [   80.766780]  bus_for_each_dev+0x6c/0xc0
> [   80.766784]  driver_attach+0x1e/0x20
> [   80.766787]  bus_add_driver+0x45/0x270
> [   80.766790]  ? 0xc09a8000
> [   80.766794]  driver_register+0x60/0xe0
> [   80.766796]  ? 0xc09a8000
> [   80.766799]  __pci_register_driver+0x4c/0x50
> [   80.766811]  drm_pci_init+0xed/0x100 [drm]
> [   80.766816]  ? vga_switcheroo_register_handler+0x6c/0x90
> [   80.766819]  ? 0xc09a8000
> [   80.766850]  amdgpu_init+0x9b/0xac [amdgpu]
> [   80.766855]  do_one_initcall+0x53/0x1c0
> [   80.766860]  ? __vunmap+0x81/0xd0
> [   80.766865]  ? kmem_cache_alloc_trace+0xdb/0x1b0
> [   80.766868]  ? kfree+0x161/0x170
> [   80.766876]  do_init_module+0x60/0x202
> [   80.766881]  load_module+0x2612/0x29f0
> [   80.766885]  SYSC_finit_module+0xa6/0xf0
> [   80.766888]  ? SYSC_finit_module+0xa6/0xf0
> [   80.766892]  SyS_finit_module+0xe/0x10
> [   80.766896]  entry_SYSCALL_64_fastpath+0x1e/0xad
> [   80.766899] RIP: 0033:0x7fa525e60709
> [   80.766902] RSP: 002b:7fff2f5bbbf8 EFLAGS: 0246 ORIG_RAX:
> 0139
> [   80.766905] RAX: ffda RBX: 7fa526129760 RCX: 
> 7fa525e60709
> [   80.766908] RDX:  RSI: 55f51f1c9439 RDI: 
> 000b
> [   80.766910] RBP: 0070 R08:  R09: 
> 55f51fcd83f0
> [   80.766913] R10: 000b R11: 0246 R12: 
> 55f51fcd9ff0
> [   80.766915] R13: 0007 R14: 7fa5261297b8 R15: 
> 2710
> [   80.766931] Kernel Offset: 0x2280 from 0x8100
> (relocation range: 0x8000-0xbfff)
> [   80.766937] ---[ end Kernel panic - not syncing: stack-protector:
> Kernel stack is corrupted in: c0c88942

Trying to move this discussion here for more visibility. This is what
is happening.

In amdgpu_atombios_crtc_powergate_init() we are declaring
ENABLE_DISP_POWER_GATING_PARAMETERS_V2_1 args as parameter space, this
is 32bytes wide and passed down to the atombios interpreter in
ctx->ps.

Re: [PATCH v3] drm: mxsfb_crtc: Reset the eLCDIF controller

[Marek Vasut]

On 06/15/2017 05:12 PM, Fabio Estevam wrote:
> Hi Marek,
> 
> On Mon, Jun 5, 2017 at 9:08 AM, Marek Vasut  wrote:
> 
>> I'm currently on vacation, try one more time and if it doesn't work out
>> (which means this trivial list is not really working?), I'll send a PR
>> sometime mid-month.
> 
> Tried your suggestion, but it did not work.
> 
> Could you please consider sending Dave Airlie a pull request with this patch?

I poked the DRM people on IRC, so they should pick it up.

Stefan, can you test and add a T-B ?

-- 
Best regards,
Marek Vasut
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon: remove unnecessary variable in si_enable_smc_cac

[Gustavo A. R. Silva]

Remove unnecessary variable smc_result and simplify the logic related.

Variable smc_result is only being used to store the return value of function
si_send_msg_to_smc() and then compare this value against constant
PPSMC_Result_OK. In other cases this variable is not even used after
storing a value in it (lines of code 2833 and 2838). Besides,
by removing this variable the logic can be simplified and the number
of nested IF statements reduced.

Addresses-Coverity-ID: 1226969
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/gpu/drm/radeon/si_dpm.c | 49 ++---
 1 file changed, 22 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dpm.c
index ee3e742..09ef41f 100644
--- a/drivers/gpu/drm/radeon/si_dpm.c
+++ b/drivers/gpu/drm/radeon/si_dpm.c
@@ -2800,42 +2800,37 @@ static int si_enable_smc_cac(struct radeon_device *rdev,
 {
struct ni_power_info *ni_pi = ni_get_pi(rdev);
struct si_power_info *si_pi = si_get_pi(rdev);
-   PPSMC_Result smc_result;
int ret = 0;
 
if (ni_pi->enable_cac) {
-   if (enable) {
-   if (!si_should_disable_uvd_powertune(rdev, 
radeon_new_state)) {
-   if (ni_pi->support_cac_long_term_average) {
-   smc_result = si_send_msg_to_smc(rdev, 
PPSMC_CACLongTermAvgEnable);
-   if (smc_result != PPSMC_Result_OK)
-   
ni_pi->support_cac_long_term_average = false;
-   }
-
-   smc_result = si_send_msg_to_smc(rdev, 
PPSMC_MSG_EnableCac);
-   if (smc_result != PPSMC_Result_OK) {
-   ret = -EINVAL;
-   ni_pi->cac_enabled = false;
-   } else {
-   ni_pi->cac_enabled = true;
-   }
-
-   if (si_pi->enable_dte) {
-   smc_result = si_send_msg_to_smc(rdev, 
PPSMC_MSG_EnableDTE);
-   if (smc_result != PPSMC_Result_OK)
-   ret = -EINVAL;
-   }
+   if (enable &&
+   !si_should_disable_uvd_powertune(rdev, radeon_new_state)) {
+   if (ni_pi->support_cac_long_term_average &&
+   PPSMC_Result_OK !=
+   si_send_msg_to_smc(rdev, 
PPSMC_CACLongTermAvgEnable))
+   ni_pi->support_cac_long_term_average = false;
+
+   if (si_send_msg_to_smc(rdev, PPSMC_MSG_EnableCac) !=
+   PPSMC_Result_OK) {
+   ret = -EINVAL;
+   ni_pi->cac_enabled = false;
+   } else {
+   ni_pi->cac_enabled = true;
}
-   } else if (ni_pi->cac_enabled) {
-   if (si_pi->enable_dte)
-   smc_result = si_send_msg_to_smc(rdev, 
PPSMC_MSG_DisableDTE);
 
-   smc_result = si_send_msg_to_smc(rdev, 
PPSMC_MSG_DisableCac);
+   if (si_pi->enable_dte &&
+   si_send_msg_to_smc(rdev, PPSMC_MSG_EnableDTE) !=
+   PPSMC_Result_OK)
+   ret = -EINVAL;
+   } else if (!enable && ni_pi->cac_enabled) {
+   if (si_pi->enable_dte)
+   si_send_msg_to_smc(rdev, PPSMC_MSG_DisableDTE);
 
+   si_send_msg_to_smc(rdev, PPSMC_MSG_DisableCac);
ni_pi->cac_enabled = false;
 
if (ni_pi->support_cac_long_term_average)
-   smc_result = si_send_msg_to_smc(rdev, 
PPSMC_CACLongTermAvgDisable);
+   si_send_msg_to_smc(rdev, 
PPSMC_CACLongTermAvgDisable);
}
}
return ret;
-- 
2.5.0

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

Re: Color lookup support for the atmel-hlcdc driver

[Peter Rosin]

On 2017-06-15 13:54, Boris Brezillon wrote:
> On Thu, 15 Jun 2017 13:47:35 +0200
> Peter Rosin  wrote:
> 
>> On 2017-06-15 12:15, Boris Brezillon wrote:
>>> On Thu, 15 Jun 2017 11:54:29 +0200
>>> Peter Rosin  wrote:
>>>   
 On 2017-06-13 17:30, Boris Brezillon wrote:  
> Hi Peter,
>
> On Tue, 13 Jun 2017 16:34:25 +0200
> Peter Rosin  wrote:
> 
>> Hi!
>>
>> I need color lookup support for the atmel-hlcdc driver, and had a peek
>> at the code. I also looked at the drivers/gpu/drm/stm driver and came
>> up with the below diff. It compiles, but I have not booted it for the
>> simple reason that I can't imagine it will work.
>>
>> Sure, the code fills the clut registers in the .load_lut helper function
>> and I think it might even do the right thing when setting up the mode.
>> I'm less sure DMA will work correctly? It might, but I haven't looked at
>> it for many seconds...
>>
>> The big question is how the color info gets into the new clut array
>> I created in atmel_hlcdc_crtc? When I look at the stm driver, which does
>> it just like this AFAICT I just don't see it. So, what I'm I missing?
>
> You should look at drm_atomic_helper_legacy_gamma_set() and its users.

 Ok, thanks. I had a long look and could not get it to work at all.  
>>>
>>> Probably because you're trying to set this up through the emulated
>>> fbdev interface. The solution I proposed is supposed to be accessed
>>> through DRM ioctls.  
>>
>> Yes, that seems like the root cause of most of my troubles. But, the apps
>> I have seem to use the fbdev interface, and if the emulation is poorly
>> done, they won't work right...
>>
 So,
 I did as below instead. However, there are a few glaring problems...  
>>>
>>> Well, I doubt this will be accepted. The fbdev emulation layer is
>>> supposed to be rather dumb, partly because DRM people want developers
>>> to switch to the DRM interface.  
>>
>> Sigh.
>>
>>> Also note that I won't accept a solution that supports setting the LUT
>>> table only through the fbdev interface, so please try to make it work
>>> the DRM way before you even consider modifying the fbdev emulation
>>> layer.  
>>
>> Ok, I'll have another look. But to me, it's a maze...
>>

 Something, somewhere, sets up default entries for the 16 first entries
 of the palette and seem to expect them to stay as some kind of safe
 basic palette, and my applications don't handle it too well. When they
 want to draw black, they get a poisonous cyan/green instead etc. But
 it's pretty close. Can anyone provide some clue as to how that is
 supposed to be handled?

 Also, I had to change the second argument of the drm_fbdev_cma_init...
 call at the end of atmel_hlcdc_dc.c:atmel_hlcdc_dc_load() from 24 to 8
 to make it possible to set 8-modes. However, doing so fucks up 24-bit
 modes. Which made me suspect that no non-24-bit mode work w/o my patch.
 And I could indeed only get 24-bit modes to work, unless I changed this
 value to 16. Then RGB565 works like a charm, but RGB888 don't. What's
 up with that? Seems like a rather silly limitation, but it's perhaps
 just a bug?  
>>>
>>> I'm pretty sure this is not a bug. AFAIR, prefered_bpp is used when you
>>> don't explicitly specify the video mode you want to use on the cmdline
>>> [1].
>>>
>>> [1]http://elixir.free-electrons.com/linux/v3.11/source/Documentation/fb/modedb.txt
>>>   
>>
>> (Why refer to v3.11 docs?)
>>
>> Let's start with some basics, I tried to add
>>
>>  video=atmel-hclcd-dc:1024x768-16
>>
>> and
>>
>>  video=atmel_hclcd_dc:1024x768-16
>>
>> to the kernel cmdline of an unpatched linux-next kernel. No dice, I can
>> still only access RBG888. I'm obviously in need of some hand-holding...
>>
>> How am I supposed to get a 16-bit mode?
> 
> You should have a look at [1].
> 
> [1]https://www.at91.com/linux4sam/bin/view/Linux4SAM/UsingAtmelDRMDriver#Choose_supported_modes
> 

Ahh, it works with video=Unknown-1:1024x768-16

Thanks!

So, is this below better? I'll follow-up with a patch I need for the
fbdev emulation to work.

I can't easily test this newfangled drm stuff, my userspace is oldish, so
I don't know if atmel_hlcdc_crtc_atomic_flush() is the correct place to
call atmel_hlcdc_crtc_flush_lut and have the palette loaded?

What I'm saying is that I have only tested the fbdev emulation, and I
still have trouble with the palette colors (poisonous green/cyan instead
of black etc). But that may only be an issue with fbdev?

Cheers,
peda

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index 5348985..68f5e66 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -61,6 +61,7 @@ struct atmel_hlcdc_crtc {
struct atmel_hlcdc_dc 

[PATCH] drm: atmel-hlcdc: sama5d4 does not have overlay2

[Peter Rosin]

From: Peter Rosin 

Remove the layer.

Fixes: 5b9fb5e6c6c7 ("drm: atmel-hlcdc: add support for sama5d4 SoCs")
Signed-off-by: Peter Rosin 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 20 +---
 1 file changed, 1 insertion(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index 30dbffd..888524a 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -295,28 +295,10 @@ static const struct atmel_hlcdc_layer_desc 
atmel_hlcdc_sama5d4_layers[] = {
},
},
{
-   .name = "overlay2",
-   .formats = _hlcdc_plane_rgb_formats,
-   .regs_offset = 0x240,
-   .id = 2,
-   .type = ATMEL_HLCDC_OVERLAY_LAYER,
-   .cfgs_offset = 0x2c,
-   .layout = {
-   .pos = 2,
-   .size = 3,
-   .xstride = { 4 },
-   .pstride = { 5 },
-   .default_color = 6,
-   .chroma_key = 7,
-   .chroma_key_mask = 8,
-   .general_config = 9,
-   },
-   },
-   {
.name = "high-end-overlay",
.formats = _hlcdc_plane_rgb_and_yuv_formats,
.regs_offset = 0x340,
-   .id = 3,
+   .id = 2,
.type = ATMEL_HLCDC_OVERLAY_LAYER,
.cfgs_offset = 0x4c,
.layout = {
-- 
2.1.4

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

Re: [PATCH] fixup! drm/msm: Separate locking of buffer resources from struct_mutex

[Susheelendra, Sushmita]

Hi Rob,

I can see how we can trigger the shrinker on objB while holding objA->lock. So, 
the nested lock with class SHRINKER makes sense.
However, I’m trying to figure how the get_pages/vmap/fault path on an objA can 
end up triggering the shrinker on objA itself. As objA itself would not be 
purgeable (msm_obj->sgt would not be set)/vunmappable (msm_obj->vaddr would not 
be set) yet at that point, we would never end up calling msm_gem_purge or 
msm_gem_vunmap on objA itself right? If that is the case, we may not need the 
(msm_obj->madv == MSM_MADV_WILLNEED) check? Or am I missing something here?

I think shrinker_vmap would also need the nested SHRINKER lock before it calls 
msm_gem_vunmap because a vmap on objA could trigger msm_gem_vunmap on objB.

I really like the idea of protecting priv->inactive_list with a separate lock 
as that is pretty much why the shrinker needs to hold struct_mutex.

Thanks,
Sushmita

> On Jun 15, 2017, at 7:20 AM, Rob Clark  wrote:
> 
> ---
> This is roughly based on Chris's suggestion, in particular the part
> about using mutex_lock_nested().  It's not *exactly* the same, in
> particular msm_obj->lock protects a bit more than just backing store
> and we don't currently track a pin_count.  (Instead we currently
> keep pages pinned until the object is purged or freed.)
> 
> Instead of making msm_obj->lock only cover backing store, it is
> easier to split out madv, which is still protected by struct_mutex,
> which is still held by the shrinker, so the shrinker does not need
> to grab msm_obj->lock until it purges an object.  We avoid going
> down any path that could trigger shrinker by ensuring that
> msm_obj->madv == WILLNEED.  To synchronize access to msm_obj->madv
> it is protected by msm_obj->lock inside struct_mutex.
> 
> This seems to keep lockdep happy in my testing so far.
> 
> drivers/gpu/drm/msm/msm_gem.c  | 54 --
> drivers/gpu/drm/msm/msm_gem.h  |  1 +
> drivers/gpu/drm/msm/msm_gem_shrinker.c | 12 
> 3 files changed, 65 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
> index e132548..f5d1f84 100644
> --- a/drivers/gpu/drm/msm/msm_gem.c
> +++ b/drivers/gpu/drm/msm/msm_gem.c
> @@ -26,6 +26,22 @@
> #include "msm_gpu.h"
> #include "msm_mmu.h"
> 
> +/* The shrinker can be triggered while we hold objA->lock, and need
> + * to grab objB->lock to purge it.  Lockdep just sees these as a single
> + * class of lock, so we use subclasses to teach it the difference.
> + *
> + * OBJ_LOCK_NORMAL is implicit (ie. normal mutex_lock() call), and
> + * OBJ_LOCK_SHRINKER is used in msm_gem_purge().
> + *
> + * It is *essential* that we never go down paths that could trigger the
> + * shrinker for a purgable object.  This is ensured by checking that
> + * msm_obj->madv == MSM_MADV_WILLNEED.
> + */
> +enum {
> + OBJ_LOCK_NORMAL,
> + OBJ_LOCK_SHRINKER,
> +};
> +
> static dma_addr_t physaddr(struct drm_gem_object *obj)
> {
>   struct msm_gem_object *msm_obj = to_msm_bo(obj);
> @@ -150,6 +166,12 @@ struct page **msm_gem_get_pages(struct drm_gem_object 
> *obj)
>   struct page **p;
> 
>   mutex_lock(_obj->lock);
> +
> + if (WARN_ON(msm_obj->madv != MSM_MADV_WILLNEED)) {
> + mutex_unlock(_obj->lock);
> + return ERR_PTR(-EBUSY);
> + }
> +
>   p = get_pages(obj);
>   mutex_unlock(_obj->lock);
>   return p;
> @@ -220,6 +242,11 @@ int msm_gem_fault(struct vm_fault *vmf)
>   if (ret)
>   goto out;
> 
> + if (WARN_ON(msm_obj->madv != MSM_MADV_WILLNEED)) {
> + mutex_unlock(_obj->lock);
> + return VM_FAULT_SIGBUS;
> + }
> +
>   /* make sure we have pages attached now */
>   pages = get_pages(obj);
>   if (IS_ERR(pages)) {
> @@ -358,6 +385,11 @@ int msm_gem_get_iova(struct drm_gem_object *obj,
> 
>   mutex_lock(_obj->lock);
> 
> + if (WARN_ON(msm_obj->madv != MSM_MADV_WILLNEED)) {
> + mutex_unlock(_obj->lock);
> + return -EBUSY;
> + }
> +
>   vma = lookup_vma(obj, aspace);
> 
>   if (!vma) {
> @@ -454,6 +486,12 @@ void *msm_gem_get_vaddr(struct drm_gem_object *obj)
>   struct msm_gem_object *msm_obj = to_msm_bo(obj);
> 
>   mutex_lock(_obj->lock);
> +
> + if (WARN_ON(msm_obj->madv != MSM_MADV_WILLNEED)) {
> + mutex_unlock(_obj->lock);
> + return ERR_PTR(-EBUSY);
> + }
> +
>   if (!msm_obj->vaddr) {
>   struct page **pages = get_pages(obj);
>   if (IS_ERR(pages)) {
> @@ -489,12 +527,18 @@ int msm_gem_madvise(struct drm_gem_object *obj, 
> unsigned madv)
> {
>   struct msm_gem_object *msm_obj = to_msm_bo(obj);
> 
> + mutex_lock(_obj->lock);
> +
>   WARN_ON(!mutex_is_locked(>dev->struct_mutex));
> 
>   if (msm_obj->madv != __MSM_MADV_PURGED)
>   msm_obj->madv = madv;
> 
> - return (msm_obj->madv != 

Re: [PATCH] drm: atmel-hlcdc: sama5d4 does not have overlay2

[Peter Rosin]

On 2017-06-15 11:37, Boris Brezillon wrote:
> On Thu, 15 Jun 2017 11:24:13 +0200
> Peter Rosin  wrote:
> 
>> From: Peter Rosin 
>>
>> Remove the layer.
> 
> Duh. It was present in the datasheet I had. Just downloaded last
> version of the datasheet and it's no longer there.

Heh.

> Nicolas, there's still a reference to OVR2 in the block diagram
> (Section "31.3 Block Diagram"), can ask fix that (or ask someone who
> can).

Also, on page 2 (the Features chapter under peripherals) there's:

   "LCD TFT Controller with 4 overlays..."

I think it should be three?

Cheers,
peda

>>
>> Fixes: 5b9fb5e6c6c7 ("drm: atmel-hlcdc: add support for sama5d4 SoCs")
>> Signed-off-by: Peter Rosin 
>> ---
>>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 20 +---
>>  1 file changed, 1 insertion(+), 19 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
>> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
>> index 30dbffd..888524a 100644
>> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
>> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
>> @@ -295,28 +295,10 @@ static const struct atmel_hlcdc_layer_desc 
>> atmel_hlcdc_sama5d4_layers[] = {
>>  },
>>  },
>>  {
>> -.name = "overlay2",
>> -.formats = _hlcdc_plane_rgb_formats,
>> -.regs_offset = 0x240,
>> -.id = 2,
>> -.type = ATMEL_HLCDC_OVERLAY_LAYER,
>> -.cfgs_offset = 0x2c,
>> -.layout = {
>> -.pos = 2,
>> -.size = 3,
>> -.xstride = { 4 },
>> -.pstride = { 5 },
>> -.default_color = 6,
>> -.chroma_key = 7,
>> -.chroma_key_mask = 8,
>> -.general_config = 9,
>> -},
>> -},
>> -{
>>  .name = "high-end-overlay",
>>  .formats = _hlcdc_plane_rgb_and_yuv_formats,
>>  .regs_offset = 0x340,
>> -.id = 3,
>> +.id = 2,
>>  .type = ATMEL_HLCDC_OVERLAY_LAYER,
>>  .cfgs_offset = 0x4c,
>>  .layout = {
> 

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

lvds-encoder... why not lvds-bridge

[Jean-Francois Dagenais]

Bonjour Laurent!

I was wondering why you choose to name the lvds-encoder.c driver like so.
(https://github.com/torvalds/linux/commit/67cc3e22b00f9027eaa0902ecf52ac5f4f5cac97)

The driver is clearly a drm_bridge, nested in the drm/bridge subdir... so why
not "lvds-bridge.c"?

Also, the associated bindings document is named "lvds-transmitter.txt", how
confusing is that?

Just wondering if it was intended and if not, whether a patch to harmonize all
that would be welcomed.

Cheers!

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

Re: Color lookup support for the atmel-hlcdc driver

[Peter Rosin]

On 2017-06-15 12:15, Boris Brezillon wrote:
> On Thu, 15 Jun 2017 11:54:29 +0200
> Peter Rosin  wrote:
> 
>> On 2017-06-13 17:30, Boris Brezillon wrote:
>>> Hi Peter,
>>>
>>> On Tue, 13 Jun 2017 16:34:25 +0200
>>> Peter Rosin  wrote:
>>>   
 Hi!

 I need color lookup support for the atmel-hlcdc driver, and had a peek
 at the code. I also looked at the drivers/gpu/drm/stm driver and came
 up with the below diff. It compiles, but I have not booted it for the
 simple reason that I can't imagine it will work.

 Sure, the code fills the clut registers in the .load_lut helper function
 and I think it might even do the right thing when setting up the mode.
 I'm less sure DMA will work correctly? It might, but I haven't looked at
 it for many seconds...

 The big question is how the color info gets into the new clut array
 I created in atmel_hlcdc_crtc? When I look at the stm driver, which does
 it just like this AFAICT I just don't see it. So, what I'm I missing?  
>>>
>>> You should look at drm_atomic_helper_legacy_gamma_set() and its users.  
>>
>> Ok, thanks. I had a long look and could not get it to work at all.
> 
> Probably because you're trying to set this up through the emulated
> fbdev interface. The solution I proposed is supposed to be accessed
> through DRM ioctls.

Yes, that seems like the root cause of most of my troubles. But, the apps
I have seem to use the fbdev interface, and if the emulation is poorly
done, they won't work right...

>> So,
>> I did as below instead. However, there are a few glaring problems...
> 
> Well, I doubt this will be accepted. The fbdev emulation layer is
> supposed to be rather dumb, partly because DRM people want developers
> to switch to the DRM interface.

Sigh.

> Also note that I won't accept a solution that supports setting the LUT
> table only through the fbdev interface, so please try to make it work
> the DRM way before you even consider modifying the fbdev emulation
> layer.

Ok, I'll have another look. But to me, it's a maze...

>>
>> Something, somewhere, sets up default entries for the 16 first entries
>> of the palette and seem to expect them to stay as some kind of safe
>> basic palette, and my applications don't handle it too well. When they
>> want to draw black, they get a poisonous cyan/green instead etc. But
>> it's pretty close. Can anyone provide some clue as to how that is
>> supposed to be handled?
>>
>> Also, I had to change the second argument of the drm_fbdev_cma_init...
>> call at the end of atmel_hlcdc_dc.c:atmel_hlcdc_dc_load() from 24 to 8
>> to make it possible to set 8-modes. However, doing so fucks up 24-bit
>> modes. Which made me suspect that no non-24-bit mode work w/o my patch.
>> And I could indeed only get 24-bit modes to work, unless I changed this
>> value to 16. Then RGB565 works like a charm, but RGB888 don't. What's
>> up with that? Seems like a rather silly limitation, but it's perhaps
>> just a bug?
> 
> I'm pretty sure this is not a bug. AFAIR, prefered_bpp is used when you
> don't explicitly specify the video mode you want to use on the cmdline
> [1].
> 
> [1]http://elixir.free-electrons.com/linux/v3.11/source/Documentation/fb/modedb.txt
> 

(Why refer to v3.11 docs?)

Let's start with some basics, I tried to add

video=atmel-hclcd-dc:1024x768-16

and

video=atmel_hclcd_dc:1024x768-16

to the kernel cmdline of an unpatched linux-next kernel. No dice, I can
still only access RBG888. I'm obviously in need of some hand-holding...

How am I supposed to get a 16-bit mode?

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

sub maintainer trees

[Dave Airlie]

rc6 is this Sunday most likely which means I'll be mostly finished
merging at that point.

nouveau and msm are known outstanding, but I've talked to those,
anyone else got something I should know about?

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

Re: [PATCH 3/7] drm/vc4: Mimic drm_atomic_helper_commit() behavior

[Eric Anholt]

Eric Anholt  writes:

> [ Unknown signature status ]
> Boris Brezillon  writes:
>
>> On Tue, 06 Jun 2017 13:27:09 -0700
>> Eric Anholt  wrote:
>>
>>> Boris Brezillon  writes:
>>> 
>>> > The VC4 KMS driver is implementing its own ->atomic_commit() but there
>>> > are a few generic helpers we can use instead of open-coding the logic.
>>> >
>>> > Signed-off-by: Boris Brezillon 
>>> > ---
>>> >  drivers/gpu/drm/vc4/vc4_kms.c | 38 --
>>> >  1 file changed, 12 insertions(+), 26 deletions(-)
>>> >
>>> > diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
>>> > index ad7925a9e0ea..f229abc0991b 100644
>>> > --- a/drivers/gpu/drm/vc4/vc4_kms.c
>>> > +++ b/drivers/gpu/drm/vc4/vc4_kms.c
>>> > @@ -42,6 +42,10 @@ vc4_atomic_complete_commit(struct vc4_commit *c)
>>> >   struct drm_device *dev = state->dev;
>>> >   struct vc4_dev *vc4 = to_vc4_dev(dev);
>>> >  
>>> > + drm_atomic_helper_wait_for_fences(dev, state, false);
>>> > +
>>> > + drm_atomic_helper_wait_for_dependencies(state);  
>>> 
>>> With this wait_for_fences() addition and the reservation stuff that
>>> landed, I think we can rip out the "seqno cb" in vc4, and just use
>>> drm_atomic_helper_commit() and drm_atomic_hepler_commit_tail().  Do you
>>> see anything missing, with that?
>>
>> I can't tell. I haven't dig enough to understand what this seqno cb was
>> used for :-), but Daniel was suggesting the same thing. I'll try to
>> better understand what seqno cb does and if it's all safe to get rid of
>> it and use the standard helpers.
>
> The seqno cb was the thing for stalling the modeset until V3D was done
> rendering to the planes.  The wait_for_fences() does the same thing
> using generic dmabuf reservations, so the seqno cb isn't needed any
> more.

Oh, we've got another user of the seqno cb (async flips), anyway, so we
can't delete it quite yet.  I've pushed this patch since it's a clear
improvement (less code, waits for fences from other devices if any).


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

Re: [PATCH 2/7] drm/vc4: Fix vblank handling

[Eric Anholt]

Boris Brezillon  writes:

> There are two problems related to VBLANK handling in the current CRTC
> driver:
>
> * VBLANK events are missed when the CRTC is being disabled because the
>   driver does not wait till the end of the frame before stopping the
>   HVS and PV blocks. In this case, we should explicitly issue a VBLANK
>   event if there's one waiting
> * when we are enabling a CRTC, drm_crtc_vblank_get() is called before
>   drm_crtc_vblank_on(), which is not supposed to happen (hence the
>   WARN_ON() in the code). To solve the problem, we delay the 'update
>   display list' operation after the CRTC is actually enabled.

Does drm_crtc_vblank_get() actually fail when drm_crtc_vblank_on()
hasn't been called?  The code is a bit twisty, but it looked like we
would track the get refcount and then turn on the interrupt once
drm_crtc_vblank_on() was called.

The first change of the two seems straightforward and good, though (and
possible to separate, right?).


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

[PATCH v2 6/6 squash] drm/vc4: Fixup for the drm core async changes.

[Eric Anholt]

With this squashed in, the vc4 patch is:
Reviewed-by: Eric Anholt 

Signed-off-by: Eric Anholt 
---

Without this, the cursor never moved :)

 drivers/gpu/drm/vc4/vc4_plane.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index aac3a31a9260..59f7ab6b1831 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -792,6 +792,9 @@ static void vc4_plane_atomic_async_update(struct drm_plane 
*plane,
if (plane->state->fb != new_state->fb)
vc4_plane_async_set_fb(plane, new_state->fb);
 
+   /* Update the display list based on the new crtc_x/y. */
+   vc4_plane_atomic_check(plane, plane->state);
+
/* Note that we can't just call vc4_plane_write_dlist()
 * because that would smash the context data that the HVS is
 * currently using.
-- 
2.11.0

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

Re: [PATCH] drm/core: Fail atomic IOCTL with no CRTC state but with signaling.

[Andrey Grodzovsky]

Just a reminder.

Thanks.

On 06/09/2017 05:30 PM, Andrey Grodzovsky wrote:

Problem:
While running IGT kms_atomic_transition test suite i encountered
a hang in drmHandleEvent immidietly follwoing an atomic_commit.
After dumping the atomic state I relized that in this case there was
not even one CRTC attached to the state and only disabled
planes. This probably due to a commit which hadn't changed any property
which would require attaching crtc state. This means drmHandleEvent
will never wake up from read since without CRTC in atomic state
the event fd will not be singnaled.
This point to a bug in IGT but also DRM should gracefully
fail  such scenario so no hang on user side will happen.

Fix:
Explicitly fail by failing atomic_commit early in
drm_mode_atomic_commit where such problem can be identified.

Signed-off-by: Andrey Grodzovsky 
---
  drivers/gpu/drm/drm_atomic.c | 13 -
  1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index a567310..32eae1c 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1933,7 +1933,7 @@ static int prepare_crtc_signaling(struct drm_device *dev,
  {
struct drm_crtc *crtc;
struct drm_crtc_state *crtc_state;
-   int i, ret;
+   int i, c = 0, ret;
  
  	if (arg->flags & DRM_MODE_ATOMIC_TEST_ONLY)

return 0;
@@ -1994,8 +1994,17 @@ static int prepare_crtc_signaling(struct drm_device *dev,
  
  			crtc_state->event->base.fence = fence;

}
+
+   c++;
}
  
+	/*

+* Having this flag means user mode pends on event which will never
+* reach due to lack of at least one CRTC for signaling
+*/
+   if (c == 0 && (arg->flags & DRM_MODE_PAGE_FLIP_EVENT))
+   return -EINVAL;
+
return 0;
  }
  
@@ -2179,6 +2188,8 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,

drm_mode_object_unreference(obj);
}
  
+

+
ret = prepare_crtc_signaling(dev, state, arg, file_priv, _state,
 _fences);
if (ret)


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

Re: [PATCH] fixup! drm/msm: Separate locking of buffer resources from struct_mutex

[Rob Clark]

On Thu, Jun 15, 2017 at 5:59 PM, Susheelendra, Sushmita
 wrote:
> Hi Rob,
>
> I can see how we can trigger the shrinker on objB while holding objA->lock.
> So, the nested lock with class SHRINKER makes sense.
> However, I’m trying to figure how the get_pages/vmap/fault path on an objA
> can end up triggering the shrinker on objA itself. As objA itself would not
> be purgeable (msm_obj->sgt would not be set)/vunmappable (msm_obj->vaddr
> would not be set) yet at that point, we would never end up calling
> msm_gem_purge or msm_gem_vunmap on objA itself right? If that is the case,
> we may not need the (msm_obj->madv == MSM_MADV_WILLNEED) check? Or am I
> missing something here?

get_pages() would set msm_obj->sgt.. I guess that is protected by
msm_obj->lock, so maybe it would be safe to drop the WILLNEED check.
Otoh, I think that does make things more clear to include the check
and a bit more future-proof.

We do check is_purgable() outside of msm_obj->lock.. I'd have to think
about it for more than a few seconds, but it seems like keeping the
WILLNEED check is a good idea.

> I think shrinker_vmap would also need the nested SHRINKER lock before it
> calls msm_gem_vunmap because a vmap on objA could trigger msm_gem_vunmap on
> objB.

hmm, right.. I guess I still need to test this w/ 32b build (where I
guess vmap shrinker is more likely), but I think you are right about
needing the nested lock in _vunmap() as well.

> I really like the idea of protecting priv->inactive_list with a separate
> lock as that is pretty much why the shrinker needs to hold struct_mutex.

yeah, rough idea is split out (probably?) spin-locks to protect the
list and madv.  Then I think we could drop struct_mutex lock for
shrinker.

I think this first patch is pretty close to being ready in time to
queue up for 4.13 (which I probably need to do this weekend).  We
should try and tackle the list+madv locks for 4.14, I think, since
this is already a pretty big change.

BR,
-R

> Thanks,
> Sushmita
>
> On Jun 15, 2017, at 7:20 AM, Rob Clark  wrote:
>
> ---
> This is roughly based on Chris's suggestion, in particular the part
> about using mutex_lock_nested().  It's not *exactly* the same, in
> particular msm_obj->lock protects a bit more than just backing store
> and we don't currently track a pin_count.  (Instead we currently
> keep pages pinned until the object is purged or freed.)
>
> Instead of making msm_obj->lock only cover backing store, it is
> easier to split out madv, which is still protected by struct_mutex,
> which is still held by the shrinker, so the shrinker does not need
> to grab msm_obj->lock until it purges an object.  We avoid going
> down any path that could trigger shrinker by ensuring that
> msm_obj->madv == WILLNEED.  To synchronize access to msm_obj->madv
> it is protected by msm_obj->lock inside struct_mutex.
>
> This seems to keep lockdep happy in my testing so far.
>
> drivers/gpu/drm/msm/msm_gem.c  | 54
> --
> drivers/gpu/drm/msm/msm_gem.h  |  1 +
> drivers/gpu/drm/msm/msm_gem_shrinker.c | 12 
> 3 files changed, 65 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
> index e132548..f5d1f84 100644
> --- a/drivers/gpu/drm/msm/msm_gem.c
> +++ b/drivers/gpu/drm/msm/msm_gem.c
> @@ -26,6 +26,22 @@
> #include "msm_gpu.h"
> #include "msm_mmu.h"
>
> +/* The shrinker can be triggered while we hold objA->lock, and need
> + * to grab objB->lock to purge it.  Lockdep just sees these as a single
> + * class of lock, so we use subclasses to teach it the difference.
> + *
> + * OBJ_LOCK_NORMAL is implicit (ie. normal mutex_lock() call), and
> + * OBJ_LOCK_SHRINKER is used in msm_gem_purge().
> + *
> + * It is *essential* that we never go down paths that could trigger the
> + * shrinker for a purgable object.  This is ensured by checking that
> + * msm_obj->madv == MSM_MADV_WILLNEED.
> + */
> +enum {
> + OBJ_LOCK_NORMAL,
> + OBJ_LOCK_SHRINKER,
> +};
> +
> static dma_addr_t physaddr(struct drm_gem_object *obj)
> {
> struct msm_gem_object *msm_obj = to_msm_bo(obj);
> @@ -150,6 +166,12 @@ struct page **msm_gem_get_pages(struct drm_gem_object
> *obj)
> struct page **p;
>
> mutex_lock(_obj->lock);
> +
> + if (WARN_ON(msm_obj->madv != MSM_MADV_WILLNEED)) {
> + mutex_unlock(_obj->lock);
> + return ERR_PTR(-EBUSY);
> + }
> +
> p = get_pages(obj);
> mutex_unlock(_obj->lock);
> return p;
> @@ -220,6 +242,11 @@ int msm_gem_fault(struct vm_fault *vmf)
> if (ret)
> goto out;
>
> + if (WARN_ON(msm_obj->madv != MSM_MADV_WILLNEED)) {
> + mutex_unlock(_obj->lock);
> + return VM_FAULT_SIGBUS;
> + }
> +
> /* make sure we have pages attached now */
> pages = get_pages(obj);
> if (IS_ERR(pages)) {
> @@ -358,6 +385,11 @@ int msm_gem_get_iova(struct drm_gem_object *obj,
>
> mutex_lock(_obj->lock);
>
> + if (WARN_ON(msm_obj->madv != MSM_MADV_WILLNEED)) {
> + mutex_unlock(_obj->lock);
> + return 

Re: [PATCH 2/2] drm/vc4: Add get/set tiling ioctls.

[Eric Anholt]

Boris Brezillon  writes:

> Hi Eric,
>
> On Wed,  7 Jun 2017 17:13:36 -0700
> Eric Anholt  wrote:
>
>> This allows mesa to set the tiling format for a BO and have that
>> tiling format be respected by mesa on the other side of an
>> import/export (and by vc4 scanout in the kernel), without defining a
>> protocol to pass the tiling through userspace.
>> 
>> Signed-off-by: Eric Anholt 
>> ---
>> 
>> igt tests (which caught two edge cases) submitted to intel-gfx.
>> 
>> Mesa code: https://github.com/anholt/mesa/commits/drm-vc4-tiling
>> 
>>  drivers/gpu/drm/vc4/vc4_bo.c  | 83 
>> +++
>>  drivers/gpu/drm/vc4/vc4_drv.c |  2 ++
>>  drivers/gpu/drm/vc4/vc4_drv.h |  6 
>>  drivers/gpu/drm/vc4/vc4_kms.c | 41 -
>>  include/uapi/drm/vc4_drm.h| 16 +
>>  5 files changed, 147 insertions(+), 1 deletion(-)
>> 
>> diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
>> index 80b2f9e55c5c..21649109fd4f 100644
>> --- a/drivers/gpu/drm/vc4/vc4_bo.c
>> +++ b/drivers/gpu/drm/vc4/vc4_bo.c
>> @@ -347,6 +347,7 @@ void vc4_free_object(struct drm_gem_object *gem_bo)
>>  bo->validated_shader = NULL;
>>  }
>>  
>> +bo->t_format = false;
>>  bo->free_time = jiffies;
>>  list_add(>size_head, cache_list);
>>  list_add(>unref_head, >bo_cache.time_list);
>> @@ -572,6 +573,88 @@ vc4_create_shader_bo_ioctl(struct drm_device *dev, void 
>> *data,
>>  return ret;
>>  }
>>  
>> +/**
>> + * vc4_set_tiling_ioctl() - Sets the tiling modifier for a BO.
>> + * @dev: DRM device
>> + * @data: ioctl argument
>> + * @file_priv: DRM file for this fd
>> + *
>> + * The tiling state of the BO decides the default modifier of an fb if
>> + * no specific modifier was set by userspace, and the return value of
>> + * vc4_get_tiling_ioctl() (so that userspace can treat a BO it
>> + * received from dmabuf as the same tiling format as the producer
>> + * used).
>> + */
>> +int vc4_set_tiling_ioctl(struct drm_device *dev, void *data,
>> + struct drm_file *file_priv)
>> +{
>> +struct drm_vc4_set_tiling *args = data;
>> +struct drm_gem_object *gem_obj;
>> +struct vc4_bo *bo;
>> +bool t_format;
>> +
>> +if (args->flags != 0)
>> +return -EINVAL;
>> +
>> +switch (args->modifier) {
>> +case DRM_FORMAT_MOD_NONE:
>> +t_format = false;
>> +break;
>> +case DRM_FORMAT_MOD_BROADCOM_VC4_T_TILED:
>> +t_format = true;
>> +break;
>> +default:
>> +return -EINVAL;
>> +}
>> +
>> +gem_obj = drm_gem_object_lookup(file_priv, args->handle);
>> +if (!gem_obj) {
>> +DRM_ERROR("Failed to look up GEM BO %d\n", args->handle);
>> +return -ENOENT;
>> +}
>> +bo = to_vc4_bo(gem_obj);
>> +bo->t_format = t_format;
>> +
>> +drm_gem_object_unreference_unlocked(gem_obj);
>> +
>> +return 0;
>> +}
>> +
>> +/**
>> + * vc4_get_tiling_ioctl() - Gets the tiling modifier for a BO.
>> + * @dev: DRM device
>> + * @data: ioctl argument
>> + * @file_priv: DRM file for this fd
>> + *
>> + * Returns the tiling modifier for a BO as set by vc4_set_tiling_ioctl().
>> + */
>> +int vc4_get_tiling_ioctl(struct drm_device *dev, void *data,
>> + struct drm_file *file_priv)
>> +{
>> +struct drm_vc4_get_tiling *args = data;
>> +struct drm_gem_object *gem_obj;
>> +struct vc4_bo *bo;
>> +
>> +if (args->flags != 0 || args->modifier != 0)
>> +return -EINVAL;
>> +
>> +gem_obj = drm_gem_object_lookup(file_priv, args->handle);
>> +if (!gem_obj) {
>> +DRM_ERROR("Failed to look up GEM BO %d\n", args->handle);
>> +return -ENOENT;
>> +}
>> +bo = to_vc4_bo(gem_obj);
>> +
>> +if (bo->t_format)
>> +args->modifier = DRM_FORMAT_MOD_BROADCOM_VC4_T_TILED;
>> +else
>> +args->modifier = DRM_FORMAT_MOD_NONE;
>> +
>> +drm_gem_object_unreference_unlocked(gem_obj);
>> +
>> +return 0;
>> +}
>> +
>>  void vc4_bo_cache_init(struct drm_device *dev)
>>  {
>>  struct vc4_dev *vc4 = to_vc4_dev(dev);
>> diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
>> index 136bb4213dc0..c6b487c3d2b7 100644
>> --- a/drivers/gpu/drm/vc4/vc4_drv.c
>> +++ b/drivers/gpu/drm/vc4/vc4_drv.c
>> @@ -138,6 +138,8 @@ static const struct drm_ioctl_desc vc4_drm_ioctls[] = {
>>  DRM_IOCTL_DEF_DRV(VC4_GET_HANG_STATE, vc4_get_hang_state_ioctl,
>>DRM_ROOT_ONLY),
>>  DRM_IOCTL_DEF_DRV(VC4_GET_PARAM, vc4_get_param_ioctl, DRM_RENDER_ALLOW),
>> +DRM_IOCTL_DEF_DRV(VC4_SET_TILING, vc4_set_tiling_ioctl, 
>> DRM_RENDER_ALLOW),
>> +DRM_IOCTL_DEF_DRV(VC4_GET_TILING, vc4_get_tiling_ioctl, 
>> DRM_RENDER_ALLOW),
>>  };
>>  
>>  static struct drm_driver vc4_drm_driver = {
>> diff --git a/drivers/gpu/drm/vc4/vc4_drv.h 

[Bug 93826] 2560x1440 @144Hz graphic glitches and bad refresh rate

[bugzilla-daemon]

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

--- Comment #68 from i...@posteo.net ---
(In reply to Alex Deucher from comment #67)
> Do you get flickering at 144Hz without forcing the mclk to high?  I.e.,
> without these patches:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/
> ?id=0a646f331db0eb9efc8d3a95a44872036d441d58
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/
> ?id=58d7e3e427db1bd68f33025519a9468140280a75
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/
> ?id=09be4a5219610a6fae3215d4f51f948d6f5d2609
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/
> ?id=2275a3a2fe9914ba6d76c8ea490da3c08342bd19

Yes, I've experienced that before and just tested it again.

> > Do you know how this works on Windows? Do they increase voltage without
> > raising clocks and could this be an option for amdgpu too?
> 
> It's not the mclk frequency or voltage, it's the blanking period for the
> display timing, it's apparently too short on some monitors at very high
> refresh rates for the mclk to finish switching in time.  If part of the mclk
> switch happens outside of the vblank period, you end up with flickering or
> other display artifacts.

I assumed it is related to any voltage because higher sclk helps too. I'll just
call sclk/mclk dpm states "sdpm" and "mdpm"

auto (sdpm 0, mdpm 0 or switching through states): very bad flickering and
artifacts
sdpm 1-7, mdpm 0: better (still flickering/artifacts, but only when bigger
areas on the screen are updated)
sdpm any, mdpm 1: no flickering and artifacts

-- 
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 101387] amdgpu display corruption and hang on AMD A10-9620P

[bugzilla-daemon]

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

--- Comment #18 from Alex Deucher  ---
The VCE regression is fixed.  If you want to try those patches, they are
available here:
https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-4.13-wip

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

[Bug 93826] 2560x1440 @144Hz graphic glitches and bad refresh rate

[bugzilla-daemon]

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

--- Comment #67 from Alex Deucher  ---
(In reply to iuno from comment #66)
> (In reply to Alex Deucher from comment #65)
> > 
> > Yes, that is independent of the patch in attachment 131983 [details] 
> > [review]
> > [review].  The driver disables dynamic mclk switching for refresh rates
> > above 120 hz to avoid flickering.
> 
> Yes, I know it prevents flickering. Comment #62 was a reply and I mentioned
> this as *another* problem (high power draw), independent from the fixed one.
> 

Do you get flickering at 144Hz without forcing the mclk to high?  I.e., without
these patches:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0a646f331db0eb9efc8d3a95a44872036d441d58
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=58d7e3e427db1bd68f33025519a9468140280a75
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=09be4a5219610a6fae3215d4f51f948d6f5d2609
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2275a3a2fe9914ba6d76c8ea490da3c08342bd19

> Do you know how this works on Windows? Do they increase voltage without
> raising clocks and could this be an option for amdgpu too?

It's not the mclk frequency or voltage, it's the blanking period for the
display timing, it's apparently too short on some monitors at very high refresh
rates for the mclk to finish switching in time.  If part of the mclk switch
happens outside of the vblank period, you end up with flickering or other
display artifacts.

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

-misc feature freeze: drm-misc-next-fixes->4.13, drm-misc-next->4.14

[Sean Paul]

Hi -misc committers,
I just sent out the last drm-misc-next pull request for 4.13. Once Dave has
applied it to drm-next, I'll perform a backmerge (there is a single patch
erroneously committed to drm-misc-next-fixes which prevents fast-forward) and
the branch will be open for fixes.

Sean


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

[PULL] drm-misc-next

[Sean Paul]

Hi Dave,
Here's the final drm-misc-next request for 4.13, we'll switch over to
drm-misc-next-fixes for 4.13 with drm-misc-next now targetting 4.14. I'll send
out a separate email to -misc committers to ensure we're all on the same page.

The drm_panel_bridge change introduced a little bit of instability when it first
landed, but it seems like all of that has been fixed and things should be good
to go. Along the same lines, we gained a handful of new panels in panel-simple
and a couple dedicated panel drivers as well.

Aside from those items, one thing to watch out for is the mxsfb patch. I had
applied it to -next first, but upon request from Jani, I also merged it to
-fixes and included it in my PR earlier today. Hopefully it won't cause
problems in the next couple of weeks before merge window, but figured it was
worth mentioning.

drm-misc-next-2017-06-15:
Cross-subsystem Changes:
- dt-bindings: add vendor prefix for NLT Technologies, Ltd. (Lucas)
- dt-bindings: Add support for samsung s6e3hf2 panel (Hoegeun)

Core Changes:
- Add drm_panel_bridge to avoid connector boilerplate in drivers (Eric)
- Trival fixes for dupe forward decl and reduce scope of variable (Dawid)

Driver Changes:
- dw-hdmi: Use mode_valid hook on bridge instead of connector (Jose)
- vc4,atmel-hlcdc: Use drm_panel_bridge where appropriate (Eric)
- panel: Add Innolux P079ZCA panel driver (Chris)
- panel-simple: Add NL12880B20-05, NL192108AC18-02D, P320HVN03 panels (Lucas)
- panel-samsung-s6e3ha2: Add s6e3hf2 panel support (Hoegeun)
- zte,vc4,pl111,panel,mxsfb: Miscellaneous fixes

Cc: Jose Abreu 
Cc: Eric Anholt 
Cc: Chris Zhong 
Cc: Lucas Stach 
Cc: Hoegeun Kwon 
Cc: Dawid Kurek 

Cheers, Sean


The following changes since commit 7f696942a7e52df2a99410bf23da513f9aad04fb:

  drm/vc4: Mark the device as active when enabling runtime PM. (2017-06-02 
13:00:47 -0700)

are available in the git repository at:

  git://anongit.freedesktop.org/git/drm-misc tags/drm-misc-next-2017-06-15

for you to fetch changes up to ac7c748317f515f426f48e72964c71142506f7a6:

  drm: Reduce scope of 'state' variable (2017-06-15 14:26:02 -0400)


Cross-subsystem Changes:
- dt-bindings: add vendor prefix for NLT Technologies, Ltd. (Lucas)
- dt-bindings: Add support for samsung s6e3hf2 panel (Hoegeun)

Core Changes:
- Add drm_panel_bridge to avoid connector boilerplate in drivers (Eric)
- Trival fixes for dupe forward decl and reduce scope of variable (Dawid)

Driver Changes:
- dw-hdmi: Use mode_valid hook on bridge instead of connector (Jose)
- vc4,atmel-hlcdc: Use drm_panel_bridge where appropriate (Eric)
- panel: Add Innolux P079ZCA panel driver (Chris)
- panel-simple: Add NL12880B20-05, NL192108AC18-02D, P320HVN03 panels (Lucas)
- panel-samsung-s6e3ha2: Add s6e3hf2 panel support (Hoegeun)
- zte,vc4,pl111,panel,mxsfb: Miscellaneous fixes

Cc: Jose Abreu 
Cc: Eric Anholt 
Cc: Chris Zhong 
Cc: Lucas Stach 
Cc: Hoegeun Kwon 
Cc: Dawid Kurek 


Arnd Bergmann (2):
  drm/panel: S6E3HA2 needs backlight code
  drm/panel: add backlight dependency for sitronix-st7789v

Benjamin Gaignard (1):
  drm: zte: use devm_of_platform_populate()

Boris Brezillon (1):
  drm/atmel-hlcdc: Fix panel registration

Chris Zhong (2):
  dt-bindings: Add INNOLUX P079ZCA panel bindings
  drm/panel: add Innolux P079ZCA panel driver

Christophe JAILLET (1):
  drm/vc4: Fix resource leak in 'vc4_get_hang_state_ioctl()' in error 
handling path

Dawid Kurek (2):
  drm: Remove duplicate forward declaration
  drm: Reduce scope of 'state' variable

Eric Anholt (6):
  drm/bridge: Refactor out the panel wrapper from the lvds-encoder bridge.
  drm/vc4: Switch DSI to the panel-bridge layer, and support bridges.
  drm/vc4: Switch DPI to using the panel-bridge helper.
  drm/atmel-hlcdc: Drop custom encoder cleanup func.
  drm/atmel-hlcdc: Replace the panel usage with drm_panel_bridge.
  drm/pl111: Fix offset calculation for the primary plane.

Fabio Estevam (1):
  drm: mxsfb_crtc: Reset the eLCDIF controller

Hans Verkuil (1):
  drm/vc4/vc4_bo.c: always set bo->resv

Hoegeun Kwon (2):
  dt-bindings: Add support for samsung s6e3hf2 panel
  drm/panel: s6e3ha2: Add support for s6e3hf2 panel on TM2e board

Jose Abreu (1):
  drm/bridge/synopsys: dw-hdmi: Use bridge->mode_valid() callback

Jyri Sarha (1):
  drm: Add const to name field declaration in struct drm_prop_enum_list

Lucas Stach (4):
  drm/panel: simple: add support for NEC NL12880B20-05
  dt-bindings: add vendor prefix for NLT Technologies, Ltd.
  drm/panel: simple: add 

[Bug 93826] 2560x1440 @144Hz graphic glitches and bad refresh rate

[bugzilla-daemon]

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

--- Comment #66 from i...@posteo.net ---
(In reply to Alex Deucher from comment #65)
> 
> Yes, that is independent of the patch in attachment 131983 [details]
> [review].  The driver disables dynamic mclk switching for refresh rates
> above 120 hz to avoid flickering.

Yes, I know it prevents flickering. Comment #62 was a reply and I mentioned
this as *another* problem (high power draw), independent from the fixed one.

Do you know how this works on Windows? Do they increase voltage without raising
clocks and could this be an option for amdgpu too?

-- 
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 6/7] drm/panel: Add support for the Raspberry Pi 7" Touchscreen.

[Eric Anholt]

This driver communicates with the Atmel microcontroller for sequencing
the poweron of the TC358762 DSI-DPI bridge and controlling the
backlight PWM.

v2: Set the same default orientation as the closed source firmware
used, which is the best for viewing angle.
v3: Rewrite as an i2c client driver after bridge driver rejection.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/panel/Kconfig  |   8 +
 drivers/gpu/drm/panel/Makefile |   1 +
 .../gpu/drm/panel/panel-raspberrypi-touchscreen.c  | 507 +
 3 files changed, 516 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 3e29a9903303..4111f497945d 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -62,6 +62,14 @@ config DRM_PANEL_PANASONIC_VVX10F034N00
  WUXGA (1920x1200) Novatek NT1397-based DSI panel as found in some
  Xperia Z2 tablets
 
+config DRM_PANEL_RASPBERRYPI_TOUCHSCREEN
+   tristate "Raspberry Pi 7-inch touchscreen panel"
+   depends on DRM_MIPI_DSI
+   help
+ Say Y here if you want to enable support for the Raspberry
+ Pi 7" Touchscreen.  To compile this driver as a module,
+ choose M here.
+
 config DRM_PANEL_SAMSUNG_S6E3HA2
tristate "Samsung S6E3HA2 DSI video mode panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 292b3c77aede..fbb8a2373058 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
 obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o
 obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
 obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) += 
panel-panasonic-vvx10f034n00.o
+obj-$(CONFIG_DRM_PANEL_RASPBERRYPI_TOUCHSCREEN) += 
panel-raspberrypi-touchscreen.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E3HA2) += panel-samsung-s6e3ha2.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0) += panel-samsung-s6e8aa0.o
diff --git a/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c 
b/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
new file mode 100644
index ..da398785eac7
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
@@ -0,0 +1,507 @@
+/*
+ * Copyright © 2016-2017 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Portions of this file (derived from panel-simple.c) are:
+ *
+ * Copyright (C) 2013, NVIDIA Corporation.  All rights reserved.
+ *
+ * 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, sub license,
+ * 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 (including the
+ * next paragraph) 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 NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS 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.
+ */
+
+/**
+ * Raspberry Pi 7" touchscreen panel driver.
+ *
+ * The 7" touchscreen consists of a DPI LCD panel, a Toshiba
+ * TC358762XBG DSI-DPI bridge, and an I2C-connected Atmel ATTINY88-MUR
+ * controlling power management, the LCD PWM, and initial register
+ * setup of the Tohsiba.
+ *
+ * This driver controls the TC358762 and ATTINY88, presenting a DSI
+ * device with a drm_panel.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define RPI_DSI_DRIVER_NAME "rpi-ts-dsi"
+
+/* I2C registers of the Atmel microcontroller. */
+enum REG_ADDR {
+   REG_ID = 0x80,
+   REG_PORTA, /* BIT(2) for horizontal flip, BIT(3) for vertical flip */
+   REG_PORTB,
+   REG_PORTC,
+   REG_PORTD,
+   REG_POWERON,
+   REG_PWM,
+   REG_DDRA,
+   REG_DDRB,
+   REG_DDRC,
+   REG_DDRD,
+   REG_TEST,
+   REG_WR_ADDRL,
+   

[PATCH 5/7] dt-bindings: Document the Raspberry Pi Touchscreen nodes.

[Eric Anholt]

This doesn't yet cover input, but the driver does get the display
working when the firmware is disabled from talking to our I2C lines.

Signed-off-by: Eric Anholt 
---
 .../panel/raspberrypi,7inch-touchscreen.txt| 49 ++
 1 file changed, 49 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touchscreen.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touchscreen.txt
 
b/Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touchscreen.txt
new file mode 100644
index ..e9e19c059260
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touchscreen.txt
@@ -0,0 +1,49 @@
+This binding covers the official 7" (800x480) Raspberry Pi touchscreen
+panel.
+
+This DSI panel contains:
+
+- TC358762 DSI->DPI bridge
+- Atmel microcontroller on I2C for power sequencing the DSI bridge and
+  controlling backlight
+- Touchscreen controller on I2C for touch input
+
+and this binding covers the DSI display parts but not its touch input.
+
+Required properties:
+- compatible:  Must be "raspberrypi,7inch-touchscreen-panel"
+- reg: Must be "45"
+- port:See panel-common.txt
+
+Example:
+
+dsi1: dsi@7e70 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   <...>
+
+   port {
+   dsi_out_port: endpoint {
+   remote-endpoint = <_dsi_port>;
+   };
+   };
+};
+
+i2c_dsi: i2c {
+   compatible = "i2c-gpio";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   gpios = < 28 0
+ 29 0>;
+
+   lcd@45 {
+   compatible = "raspberrypi,7inch-touchscreen-panel";
+   reg = <0x45>;
+
+   port {
+   panel_dsi_port: endpoint {
+   remote-endpoint = <_out_port>;
+   };
+   };
+   };
+};
-- 
2.11.0

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

[PATCH 1/7] drm/bridge: Support hotplugging panel-bridge.

[Eric Anholt]

If the panel-bridge is being set up after the drm_mode_config_reset(),
then the connector's state would never get initialized, and we'd
dereference the NULL in the hotplug path.  We also need to register
the connector, so that userspace can get at it.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/bridge/panel.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
index 67fe19e5a9c6..8ed8a70799c7 100644
--- a/drivers/gpu/drm/bridge/panel.c
+++ b/drivers/gpu/drm/bridge/panel.c
@@ -82,11 +82,14 @@ static int panel_bridge_attach(struct drm_bridge *bridge)
 
drm_mode_connector_attach_encoder(_bridge->connector,
  bridge->encoder);
+   drm_atomic_helper_connector_reset(_bridge->connector);
 
ret = drm_panel_attach(panel_bridge->panel, _bridge->connector);
if (ret < 0)
return ret;
 
+   drm_connector_register(_bridge->connector);
+
return 0;
 }
 
-- 
2.11.0

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

[PATCH 7/7] ARM: dts: bcm2835: Enable the Raspberry Pi touchscreen panel.

[Eric Anholt]

This commit is not intended to be merged.  Instead we will use
overlays to enable the panel, and this commit is just a demo of how
things get wired up.

Signed-off-by: Eric Anholt 
---
 arch/arm/boot/dts/bcm2835-rpi-b-plus.dts |  5 
 arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts |  5 
 arch/arm/boot/dts/bcm2835-rpi-b.dts  |  5 
 arch/arm/boot/dts/bcm2836-rpi-2-b.dts|  5 
 arch/arm/boot/dts/bcm283x.dtsi   | 30 +++-
 arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts |  5 
 6 files changed, 54 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts 
b/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
index 432088ebb0a1..79f433eacb8b 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
@@ -101,3 +101,8 @@
  {
hpd-gpios = < 46 GPIO_ACTIVE_LOW>;
 };
+
+_dsi {
+   gpios = < 28 0
+ 29 0>;
+};
diff --git a/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts 
b/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts
index 4133bc2cd9be..145e0e4c2c7f 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts
@@ -94,3 +94,8 @@
  {
hpd-gpios = < 46 GPIO_ACTIVE_LOW>;
 };
+
+_dsi {
+   gpios = < 2 0
+ 3 0>;
+};
diff --git a/arch/arm/boot/dts/bcm2835-rpi-b.dts 
b/arch/arm/boot/dts/bcm2835-rpi-b.dts
index 4d56fe3006b0..5b3f85883f0c 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-b.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-b.dts
@@ -89,3 +89,8 @@
  {
hpd-gpios = < 46 GPIO_ACTIVE_HIGH>;
 };
+
+_dsi {
+   gpios = < 0 0
+ 1 0>;
+};
diff --git a/arch/arm/boot/dts/bcm2836-rpi-2-b.dts 
b/arch/arm/boot/dts/bcm2836-rpi-2-b.dts
index bf19e8cfb9e6..aa63cc29eca8 100644
--- a/arch/arm/boot/dts/bcm2836-rpi-2-b.dts
+++ b/arch/arm/boot/dts/bcm2836-rpi-2-b.dts
@@ -39,3 +39,8 @@
  {
hpd-gpios = < 46 GPIO_ACTIVE_LOW>;
 };
+
+_dsi {
+   gpios = < 28 0
+ 29 0>;
+};
diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
index 35cea3fcaf5c..682f11a4fc91 100644
--- a/arch/arm/boot/dts/bcm283x.dtsi
+++ b/arch/arm/boot/dts/bcm283x.dtsi
@@ -505,7 +505,11 @@
 "dsi1_ddr2",
 "dsi1_ddr";
 
-   status = "disabled";
+   port {
+   dsi_out_port: endpoint {
+   remote-endpoint = <_dsi_port>;
+   };
+   };
};
 
i2c1: i2c@7e804000 {
@@ -575,6 +579,30 @@
vc4: gpu {
compatible = "brcm,bcm2835-vc4";
};
+
+   i2c_dsi: i2c {
+   /* We have to use i2c-gpio because the
+* firmware is also polling another device
+* using the only hardware I2C bus that could
+* connect to these pins.
+*/
+   compatible = "i2c-gpio";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   gpios = < 28 0
+ 29 0>;
+
+   lcd@45 {
+   compatible = 
"raspberrypi,7inch-touchscreen-panel";
+   reg = <0x45>;
+
+   port {
+   panel_dsi_port: endpoint {
+   remote-endpoint = 
<_out_port>;
+   };
+   };
+   };
+   };
};
 
clocks {
diff --git a/arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts 
b/arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts
index c309633a1e87..c11026c6c8b4 100644
--- a/arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts
+++ b/arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts
@@ -22,3 +22,8 @@
  {
status = "okay";
 };
+
+_dsi {
+   gpios = < 44 0
+ 45 0>;
+};
-- 
2.11.0

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

[PATCH 2/7] drm/vc4: Fix DSI T_INIT timing.

[Eric Anholt]

The DPHY spec requires a much larger T_INIT than I was specifying
before.  In the absence of clear specs from the slave of what their
timing is, just use the value that the firmware was using.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_dsi.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c
index 5e8b81eaa168..15f6d5005ab9 100644
--- a/drivers/gpu/drm/vc4/vc4_dsi.c
+++ b/drivers/gpu/drm/vc4/vc4_dsi.c
@@ -1035,7 +1035,17 @@ static void vc4_dsi_encoder_enable(struct drm_encoder 
*encoder)
 DSI_HS_DLT4_TRAIL) |
   VC4_SET_FIELD(0, DSI_HS_DLT4_ANLAT));
 
-   DSI_PORT_WRITE(HS_DLT5, VC4_SET_FIELD(dsi_hs_timing(ui_ns, 1000, 5000),
+   /* T_INIT is how long STOP is driven after power-up to
+* indicate to the slave (also coming out of power-up) that
+* master init is complete, and should be greater than the
+* maximum of two value: T_INIT,MASTER and T_INIT,SLAVE.  The
+* D-PHY spec gives a minimum 100us for T_INIT,MASTER and
+* T_INIT,SLAVE, while allowing protocols on top of it to give
+* greater minimums.  The vc4 firmware uses an extremely
+* conservative 5ms, and we maintain that here.
+*/
+   DSI_PORT_WRITE(HS_DLT5, VC4_SET_FIELD(dsi_hs_timing(ui_ns,
+   5 * 1000 * 1000, 0),
  DSI_HS_DLT5_INIT));
 
DSI_PORT_WRITE(HS_DLT6,
-- 
2.11.0

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

[PATCH 3/7] drm/vc4: Fix misleading name of the continuous flag.

[Eric Anholt]

The logic was all right in the end, the name was just backwards.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_dsi.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c
index 15f6d5005ab9..629d372633e6 100644
--- a/drivers/gpu/drm/vc4/vc4_dsi.c
+++ b/drivers/gpu/drm/vc4/vc4_dsi.c
@@ -736,18 +736,18 @@ static void vc4_dsi_latch_ulps(struct vc4_dsi *dsi, bool 
latch)
 /* Enters or exits Ultra Low Power State. */
 static void vc4_dsi_ulps(struct vc4_dsi *dsi, bool ulps)
 {
-   bool continuous = dsi->mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS;
-   u32 phyc_ulps = ((continuous ? DSI_PORT_BIT(PHYC_CLANE_ULPS) : 0) |
+   bool non_continuous = dsi->mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS;
+   u32 phyc_ulps = ((non_continuous ? DSI_PORT_BIT(PHYC_CLANE_ULPS) : 0) |
 DSI_PHYC_DLANE0_ULPS |
 (dsi->lanes > 1 ? DSI_PHYC_DLANE1_ULPS : 0) |
 (dsi->lanes > 2 ? DSI_PHYC_DLANE2_ULPS : 0) |
 (dsi->lanes > 3 ? DSI_PHYC_DLANE3_ULPS : 0));
-   u32 stat_ulps = ((continuous ? DSI1_STAT_PHY_CLOCK_ULPS : 0) |
+   u32 stat_ulps = ((non_continuous ? DSI1_STAT_PHY_CLOCK_ULPS : 0) |
 DSI1_STAT_PHY_D0_ULPS |
 (dsi->lanes > 1 ? DSI1_STAT_PHY_D1_ULPS : 0) |
 (dsi->lanes > 2 ? DSI1_STAT_PHY_D2_ULPS : 0) |
 (dsi->lanes > 3 ? DSI1_STAT_PHY_D3_ULPS : 0));
-   u32 stat_stop = ((continuous ? DSI1_STAT_PHY_CLOCK_STOP : 0) |
+   u32 stat_stop = ((non_continuous ? DSI1_STAT_PHY_CLOCK_STOP : 0) |
 DSI1_STAT_PHY_D0_STOP |
 (dsi->lanes > 1 ? DSI1_STAT_PHY_D1_STOP : 0) |
 (dsi->lanes > 2 ? DSI1_STAT_PHY_D2_STOP : 0) |
-- 
2.11.0

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

[PATCH 0/7] RPi touchscreen as a panel driver again

[Eric Anholt]

After splitting the panel driver out into a panel and bridge due to
panel review, the feedback from bridge maintainers was that it didn't
make sense as a bridge.  I completely agree with them.  This series
returns the driver to being a panel, but this time probing as an i2c
client rather than a DSI device (due to review from bridge
submission).

Eric Anholt (7):
  drm/bridge: Support hotplugging panel-bridge.
  drm/vc4: Fix DSI T_INIT timing.
  drm/vc4: Fix misleading name of the continuous flag.
  drm/vc4: Use drm_mode_vrefresh() in DSI fixup, in case vrefresh is 0.
  dt-bindings: Document the Raspberry Pi Touchscreen nodes.
  drm/panel: Add support for the Raspberry Pi 7" Touchscreen.
  ARM: dts: bcm2835: Enable the Raspberry Pi touchscreen panel.

 .../panel/raspberrypi,7inch-touchscreen.txt|  49 ++
 arch/arm/boot/dts/bcm2835-rpi-b-plus.dts   |   5 +
 arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts   |   5 +
 arch/arm/boot/dts/bcm2835-rpi-b.dts|   5 +
 arch/arm/boot/dts/bcm2836-rpi-2-b.dts  |   5 +
 arch/arm/boot/dts/bcm283x.dtsi |  30 +-
 arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts   |   5 +
 drivers/gpu/drm/bridge/panel.c |   3 +
 drivers/gpu/drm/panel/Kconfig  |   8 +
 drivers/gpu/drm/panel/Makefile |   1 +
 .../gpu/drm/panel/panel-raspberrypi-touchscreen.c  | 507 +
 drivers/gpu/drm/vc4/vc4_dsi.c  |  24 +-
 12 files changed, 640 insertions(+), 7 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touchscreen.txt
 create mode 100644 drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c

-- 
2.11.0

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

[PATCH 4/7] drm/vc4: Use drm_mode_vrefresh() in DSI fixup, in case vrefresh is 0.

[Eric Anholt]

I'm not sure what changed where I started getting vrefresh=0 from the
mode to be fixed up.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_dsi.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c
index 629d372633e6..fca4d7fd677e 100644
--- a/drivers/gpu/drm/vc4/vc4_dsi.c
+++ b/drivers/gpu/drm/vc4/vc4_dsi.c
@@ -866,7 +866,9 @@ static bool vc4_dsi_encoder_mode_fixup(struct drm_encoder 
*encoder,
adjusted_mode->clock = pixel_clock_hz / 1000 + 1;
 
/* Given the new pixel clock, adjust HFP to keep vrefresh the same. */
-   adjusted_mode->htotal = pixel_clock_hz / (mode->vrefresh * 
mode->vtotal);
+   adjusted_mode->htotal = pixel_clock_hz / (drm_mode_vrefresh(mode) *
+ mode->vtotal);
+
adjusted_mode->hsync_end += adjusted_mode->htotal - mode->htotal;
adjusted_mode->hsync_start += adjusted_mode->htotal - mode->htotal;
 
-- 
2.11.0

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

[Bug 93826] 2560x1440 @144Hz graphic glitches and bad refresh rate

[bugzilla-daemon]

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

--- Comment #65 from Alex Deucher  ---
(In reply to iuno from comment #64)
> (In reply to Alex Deucher from comment #63)
> > 
> > Are you forcing the power state to high?  The mclk shouldn't be affected by
> > the display clock.
> 
> No, setting the refresh rate to 144 results in high mclk, even when I set
> power_dpm_force_performance_level to low or pp_dpm_mclk to 0. Using 120 Hz,
> I could echo 0 or 1 to pp_dpm_mclk. I also got the power meter on now:
> 
> memory dpm state 0  (150 MHz):  77 watts
> memory dpm state 1 (1250 MHz): 112 watts
> 
> So there is a difference of 35 watts. Using Windows, I'm below the 80 Watts
> even with 144 Hz.

Yes, that is independent of the patch in attachment 131983.  The driver
disables dynamic mclk switching for refresh rates above 120 hz to avoid
flickering.

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

[PULL] drm-misc-fixes

[Sean Paul]

Hi Dave,
Here's this week's pull. Nothing worth noting beyond the onelines and summaries.

drm-misc-fixes-2017-06-15:
Driver Changes:
- dw-hdmi: Fix compilation error if REGMAP_MMIO not selected (Laurent)
- host1x: Fix incorrect return value (Christophe)
- tegra: Shore up idr API usage in tegra staging code (Dmitry)
- mgag200: Always use HiPri mode for G200e4v2 and limit max bandwidth (Mathieu)
- mxsfb: Ensure display can be lit up without bootloader initialization (Fabio)

Cc: Laurent Pinchart 
Cc: Christophe JAILLET 
Cc: Dmitry Osipenko 
Cc: Mathieu Larouche 
Cc: Fabio Estevam 

Cheers, Sean


The following changes since commit 6e88007e224ce51969ccf9afeec645146c638816:

  Merge branch 'vmwgfx-fixes-4.12' of 
git://people.freedesktop.org/~thomash/linux into drm-fixes (2017-06-09 13:12:02 
+1000)

are available in the git repository at:

  git://anongit.freedesktop.org/git/drm-misc tags/drm-misc-fixes-2017-06-15

for you to fetch changes up to 0f933328f018c118ded2035f12068bbdfdef399d:

  drm: mxsfb_crtc: Reset the eLCDIF controller (2017-06-15 14:26:24 -0400)


Driver Changes:
- dw-hdmi: Fix compilation error if REGMAP_MMIO not selected (Laurent)
- host1x: Fix incorrect return value (Christophe)
- tegra: Shore up idr API usage in tegra staging code (Dmitry)
- mgag200: Always use HiPri mode for G200e4v2 and limit max bandwidth (Mathieu)
- mxsfb: Ensure display can be lit up without bootloader initialization (Fabio)

Cc: Laurent Pinchart 
Cc: Christophe JAILLET 
Cc: Dmitry Osipenko 
Cc: Mathieu Larouche 
Cc: Fabio Estevam 


Christophe JAILLET (1):
  gpu: host1x: Fix error handling

Dmitry Osipenko (2):
  drm/tegra: Fix lockup on a use of staging API
  drm/tegra: Correct idr_alloc() minimum id

Fabio Estevam (1):
  drm: mxsfb_crtc: Reset the eLCDIF controller

Laurent Pinchart (1):
  drm: dw-hdmi: Fix compilation breakage by selecting REGMAP_MMIO

Mathieu Larouche (1):
  drm/mgag200: Fix to always set HiPri for G200e4 V2

 drivers/gpu/drm/bridge/synopsys/Kconfig |  1 +
 drivers/gpu/drm/mgag200/mgag200_mode.c  |  9 ++-
 drivers/gpu/drm/mxsfb/mxsfb_crtc.c  | 42 +
 drivers/gpu/drm/tegra/drm.c | 22 -
 drivers/gpu/host1x/dev.c|  2 +-
 5 files changed, 57 insertions(+), 19 deletions(-)

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

[Bug 93826] 2560x1440 @144Hz graphic glitches and bad refresh rate

[bugzilla-daemon]

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

--- Comment #64 from i...@posteo.net ---
(In reply to Alex Deucher from comment #63)
> 
> Are you forcing the power state to high?  The mclk shouldn't be affected by
> the display clock.

No, setting the refresh rate to 144 results in high mclk, even when I set
power_dpm_force_performance_level to low or pp_dpm_mclk to 0. Using 120 Hz, I
could echo 0 or 1 to pp_dpm_mclk. I also got the power meter on now:

memory dpm state 0  (150 MHz):  77 watts
memory dpm state 1 (1250 MHz): 112 watts

So there is a difference of 35 watts. Using Windows, I'm below the 80 Watts
even with 144 Hz.

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

Re: [PATCH v3] drm: mxsfb_crtc: Reset the eLCDIF controller

[Sean Paul]

On Thu, Jun 15, 2017 at 01:53:15PM -0400, Sean Paul wrote:
> On Fri, May 05, 2017 at 03:01:41PM -0300, Fabio Estevam wrote:
> > According to the eLCDIF initialization steps listed in the MX6SX
> > Reference Manual the eLCDIF block reset is mandatory. 
> > 
> > Without performing the eLCDIF reset the display shows garbage content
> > when the kernel boots.
> > 
> > In earlier tests this issue has not been observed because the bootloader
> > was previously showing a splash screen and the bootloader display driver
> > does properly implement the eLCDIF reset.
> > 
> > Add the eLCDIF reset to the driver, so that it can operate correctly
> > independently of the bootloader.
> > 
> > Tested on a imx6sx-sdb board.
> > 
> > Cc: 
> > Signed-off-by: Fabio Estevam 
> 
> Per Marek's request, this has been applied to drm-misc-next
> 

Now applied to misc-fixes per Jani's request :)

Sean

> Thanks,
> 
> Sean
> 
> > ---
> > Changes since v2:
> > 
> > - Remove unneeded udelay(1) - Marek
> > 
> >  drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 42 
> > ++
> >  1 file changed, 42 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c 
> > b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> > index 1144e0c..0abe776 100644
> > --- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> > +++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> > @@ -35,6 +35,13 @@
> >  #include "mxsfb_drv.h"
> >  #include "mxsfb_regs.h"
> >  
> > +#define MXS_SET_ADDR   0x4
> > +#define MXS_CLR_ADDR   0x8
> > +#define MODULE_CLKGATE BIT(30)
> > +#define MODULE_SFTRST  BIT(31)
> > +/* 1 second delay should be plenty of time for block reset */
> > +#define RESET_TIMEOUT  100
> > +
> >  static u32 set_hsync_pulse_width(struct mxsfb_drm_private *mxsfb, u32 val)
> >  {
> > return (val & mxsfb->devdata->hs_wdth_mask) <<
> > @@ -159,6 +166,36 @@ static void mxsfb_disable_controller(struct 
> > mxsfb_drm_private *mxsfb)
> > clk_disable_unprepare(mxsfb->clk_disp_axi);
> >  }
> >  
> > +/*
> > + * Clear the bit and poll it cleared.  This is usually called with
> > + * a reset address and mask being either SFTRST(bit 31) or CLKGATE
> > + * (bit 30).
> > + */
> > +static int clear_poll_bit(void __iomem *addr, u32 mask)
> > +{
> > +   u32 reg;
> > +
> > +   writel(mask, addr + MXS_CLR_ADDR);
> > +   return readl_poll_timeout(addr, reg, !(reg & mask), 0, RESET_TIMEOUT);
> > +}
> > +
> > +static int mxsfb_reset_block(void __iomem *reset_addr)
> > +{
> > +   int ret;
> > +
> > +   ret = clear_poll_bit(reset_addr, MODULE_SFTRST);
> > +   if (ret)
> > +   return ret;
> > +
> > +   writel(MODULE_CLKGATE, reset_addr + MXS_CLR_ADDR);
> > +
> > +   ret = clear_poll_bit(reset_addr, MODULE_SFTRST);
> > +   if (ret)
> > +   return ret;
> > +
> > +   return clear_poll_bit(reset_addr, MODULE_CLKGATE);
> > +}
> > +
> >  static void mxsfb_crtc_mode_set_nofb(struct mxsfb_drm_private *mxsfb)
> >  {
> > struct drm_display_mode *m = >pipe.crtc.state->adjusted_mode;
> > @@ -173,6 +210,11 @@ static void mxsfb_crtc_mode_set_nofb(struct 
> > mxsfb_drm_private *mxsfb)
> >  */
> > mxsfb_enable_axi_clk(mxsfb);
> >  
> > +   /* Mandatory eLCDIF reset as per the Reference Manual */
> > +   err = mxsfb_reset_block(mxsfb->base);
> > +   if (err)
> > +   return;
> > +
> > /* Clear the FIFOs */
> > writel(CTRL1_FIFO_CLEAR, mxsfb->base + LCDC_CTRL1 + REG_SET);
> >  
> > -- 
> > 2.7.4
> > 
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> -- 
> Sean Paul, Software Engineer, Google / Chromium OS

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

[Bug 93826] 2560x1440 @144Hz graphic glitches and bad refresh rate

[bugzilla-daemon]

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

--- Comment #63 from Alex Deucher  ---
(In reply to iuno from comment #62)
> It works for me, too, but I already said that ;-)
> 
> However, the problem Pavel describes is another bothersome issue. PowerPlay
> changes to the higher memory DPM state which results in ~40 Watts (Hawaii;
> estimated from memory, have to measure and confirm again) more power draw.
> The higher DPM state is required, otherwise the flickering appears.
> On Windows, this isn't the case and WQHD at 144 Hz works with the low memory
> clock. I assume they raise the voltage independently to the clock in that
> case to maintain stability.

Are you forcing the power state to high?  The mclk shouldn't be affected by the
display clock.

-- 
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 93826] 2560x1440 @144Hz graphic glitches and bad refresh rate

[bugzilla-daemon]

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

--- Comment #62 from i...@posteo.net ---
It works for me, too, but I already said that ;-)

However, the problem Pavel describes is another bothersome issue. PowerPlay
changes to the higher memory DPM state which results in ~40 Watts (Hawaii;
estimated from memory, have to measure and confirm again) more power draw. The
higher DPM state is required, otherwise the flickering appears.
On Windows, this isn't the case and WQHD at 144 Hz works with the low memory
clock. I assume they raise the voltage independently to the clock in that case
to maintain stability.

-- 
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 101387] amdgpu display corruption and hang on AMD A10-9620P

[bugzilla-daemon]

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

--- Comment #17 from Alex Deucher  ---
(In reply to Carlo Caione from comment #16)
> I see. The problem is that the garbage lines result in a very bad experience
> for the user. Do you have any idea how to fix / mitigate that?

If it's related to reprogramming the MC, this patch series may help:
https://lists.freedesktop.org/archives/amd-gfx/2017-February/005675.html
It hasn't landed yet due to regressions with VCE.

-- 
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 93826] 2560x1440 @144Hz graphic glitches and bad refresh rate

[bugzilla-daemon]

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

--- Comment #61 from Pavel Bordukov  ---
(In reply to Alex Deucher from comment #60)
> Created attachment 131983 [details] [review]
> possible fix

It works for me (MG279Q, R9 290x, vanilla 4.11.4, echo high >
/sys/class/drm/card0/device/power_dpm_force_performance_level), thanks! But
temperature of the card has jumped up from 50C to 70C.

-- 
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 101387] amdgpu display corruption and hang on AMD A10-9620P

[bugzilla-daemon]

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

--- Comment #16 from Carlo Caione  ---
I see. The problem is that the garbage lines result in a very bad experience
for the user. Do you have any idea how to fix / mitigate that?

-- 
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] bridge: Fix panel-bridge error return on !panel.

[Eric Anholt]

ERR_PTR() needs a negative errno argument.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/bridge/panel.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
index 99f9a4beb859..67fe19e5a9c6 100644
--- a/drivers/gpu/drm/bridge/panel.c
+++ b/drivers/gpu/drm/bridge/panel.c
@@ -161,7 +161,7 @@ struct drm_bridge *drm_panel_bridge_add(struct drm_panel 
*panel,
int ret;
 
if (!panel)
-   return ERR_PTR(EINVAL);
+   return ERR_PTR(-EINVAL);
 
panel_bridge = devm_kzalloc(panel->dev, sizeof(*panel_bridge),
GFP_KERNEL);
-- 
2.11.0

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

Re: [PATCH v3] drm: mxsfb_crtc: Reset the eLCDIF controller

[Sean Paul]

On Fri, May 05, 2017 at 03:01:41PM -0300, Fabio Estevam wrote:
> According to the eLCDIF initialization steps listed in the MX6SX
> Reference Manual the eLCDIF block reset is mandatory. 
> 
> Without performing the eLCDIF reset the display shows garbage content
> when the kernel boots.
> 
> In earlier tests this issue has not been observed because the bootloader
> was previously showing a splash screen and the bootloader display driver
> does properly implement the eLCDIF reset.
> 
> Add the eLCDIF reset to the driver, so that it can operate correctly
> independently of the bootloader.
> 
> Tested on a imx6sx-sdb board.
> 
> Cc: 
> Signed-off-by: Fabio Estevam 

Per Marek's request, this has been applied to drm-misc-next

Thanks,

Sean

> ---
> Changes since v2:
> 
> - Remove unneeded udelay(1) - Marek
> 
>  drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 42 
> ++
>  1 file changed, 42 insertions(+)
> 
> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c 
> b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> index 1144e0c..0abe776 100644
> --- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> +++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> @@ -35,6 +35,13 @@
>  #include "mxsfb_drv.h"
>  #include "mxsfb_regs.h"
>  
> +#define MXS_SET_ADDR 0x4
> +#define MXS_CLR_ADDR 0x8
> +#define MODULE_CLKGATE   BIT(30)
> +#define MODULE_SFTRSTBIT(31)
> +/* 1 second delay should be plenty of time for block reset */
> +#define RESET_TIMEOUT100
> +
>  static u32 set_hsync_pulse_width(struct mxsfb_drm_private *mxsfb, u32 val)
>  {
>   return (val & mxsfb->devdata->hs_wdth_mask) <<
> @@ -159,6 +166,36 @@ static void mxsfb_disable_controller(struct 
> mxsfb_drm_private *mxsfb)
>   clk_disable_unprepare(mxsfb->clk_disp_axi);
>  }
>  
> +/*
> + * Clear the bit and poll it cleared.  This is usually called with
> + * a reset address and mask being either SFTRST(bit 31) or CLKGATE
> + * (bit 30).
> + */
> +static int clear_poll_bit(void __iomem *addr, u32 mask)
> +{
> + u32 reg;
> +
> + writel(mask, addr + MXS_CLR_ADDR);
> + return readl_poll_timeout(addr, reg, !(reg & mask), 0, RESET_TIMEOUT);
> +}
> +
> +static int mxsfb_reset_block(void __iomem *reset_addr)
> +{
> + int ret;
> +
> + ret = clear_poll_bit(reset_addr, MODULE_SFTRST);
> + if (ret)
> + return ret;
> +
> + writel(MODULE_CLKGATE, reset_addr + MXS_CLR_ADDR);
> +
> + ret = clear_poll_bit(reset_addr, MODULE_SFTRST);
> + if (ret)
> + return ret;
> +
> + return clear_poll_bit(reset_addr, MODULE_CLKGATE);
> +}
> +
>  static void mxsfb_crtc_mode_set_nofb(struct mxsfb_drm_private *mxsfb)
>  {
>   struct drm_display_mode *m = >pipe.crtc.state->adjusted_mode;
> @@ -173,6 +210,11 @@ static void mxsfb_crtc_mode_set_nofb(struct 
> mxsfb_drm_private *mxsfb)
>*/
>   mxsfb_enable_axi_clk(mxsfb);
>  
> + /* Mandatory eLCDIF reset as per the Reference Manual */
> + err = mxsfb_reset_block(mxsfb->base);
> + if (err)
> + return;
> +
>   /* Clear the FIFOs */
>   writel(CTRL1_FIFO_CLEAR, mxsfb->base + LCDC_CTRL1 + REG_SET);
>  
> -- 
> 2.7.4
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[PATCH v3] drm: Reduce scope of 'state' variable

[Dawid Kurek]

Smaller scope reduces visibility of variable and makes usage of
uninitialized variable less possible.

Changes in v2:
- separate declaration and initialization
Changes in v3:
- add missing signed-off-by tag

Signed-off-by: Dawid Kurek 
---
 drivers/gpu/drm/drm_atomic.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index f32506a..5e0d1e1 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -108,9 +108,10 @@ struct drm_atomic_state *
 drm_atomic_state_alloc(struct drm_device *dev)
 {
struct drm_mode_config *config = >mode_config;
-   struct drm_atomic_state *state;
 
if (!config->funcs->atomic_state_alloc) {
+   struct drm_atomic_state *state;
+
state = kzalloc(sizeof(*state), GFP_KERNEL);
if (!state)
return NULL;
-- 
2.10.0


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

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

Re: [PATCH v2] drm: Reduce scope of 'state' variable

[Dawid Kurek]

On 15/06/17, Sean Paul wrote:
> On Thu, Jun 15, 2017 at 04:04:36PM +0200, Dawid Kurek wrote:
> > Smaller scope reduces visibility of variable and makes usage of
> > uninitialized variable less possible.
> > 
> > Changes in v2:
> > - separate declaration and initialization
> 
> Your patch is missing Signed-off-by tag
> 
Right... Missed it. v3 on the way.

Dawid

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

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

Re: [PATCH v2] drm: Reduce scope of 'state' variable

[Sean Paul]

On Thu, Jun 15, 2017 at 04:04:36PM +0200, Dawid Kurek wrote:
> Smaller scope reduces visibility of variable and makes usage of
> uninitialized variable less possible.
> 
> Changes in v2:
>   - separate declaration and initialization

Your patch is missing Signed-off-by tag

Sean

> ---
>  drivers/gpu/drm/drm_atomic.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index f32506a..5e0d1e1 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -108,9 +108,10 @@ struct drm_atomic_state *
>  drm_atomic_state_alloc(struct drm_device *dev)
>  {
>   struct drm_mode_config *config = >mode_config;
> - struct drm_atomic_state *state;
>  
>   if (!config->funcs->atomic_state_alloc) {
> + struct drm_atomic_state *state;
> +
>   state = kzalloc(sizeof(*state), GFP_KERNEL);
>   if (!state)
>   return NULL;
> -- 
> 2.10.0
> 
> 
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus

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

Re: [PATCH 1/1] drm/mgag200: Fix to always set HiPri for G200e4 V2

[Sean Paul]

On Wed, Jun 14, 2017 at 10:39:42AM -0400, mathieu.larou...@matrox.com wrote:
> From: Mathieu Larouche 
> 
>   - Changed the HiPri value for G200e4 to always be 0.
>   - Added Bandwith limitation to block resolution above 1920x1200x60Hz
> 
> Signed-off-by: Mathieu Larouche 

Applied to -misc-fixes with airlied's Ack.

Thanks,

Sean

> ---
>  drivers/gpu/drm/mgag200/mgag200_mode.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c 
> b/drivers/gpu/drm/mgag200/mgag200_mode.c
> index 6b21cb2..292e8eb 100644
> --- a/drivers/gpu/drm/mgag200/mgag200_mode.c
> +++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
> @@ -1133,7 +1133,10 @@ static int mga_crtc_mode_set(struct drm_crtc *crtc,
>  
>  
>   if (IS_G200_SE(mdev)) {
> - if (mdev->unique_rev_id >= 0x02) {
> + if  (mdev->unique_rev_id >= 0x04) {
> + WREG8(MGAREG_CRTCEXT_INDEX, 0x06);
> + WREG8(MGAREG_CRTCEXT_DATA, 0);
> + } else if (mdev->unique_rev_id >= 0x02) {
>   u8 hi_pri_lvl;
>   u32 bpp;
>   u32 mb;
> @@ -1598,6 +1601,10 @@ static int mga_vga_mode_valid(struct drm_connector 
> *connector,
>   if (mga_vga_calculate_mode_bandwidth(mode, bpp)
>   > (30100 * 1024))
>   return MODE_BANDWIDTH;
> + } else {
> + if (mga_vga_calculate_mode_bandwidth(mode, bpp) 
> + > (55000 * 1024)) 
> + return MODE_BANDWIDTH;
>   }
>   } else if (mdev->type == G200_WB) {
>   if (mode->hdisplay > 1280)
> -- 
> 1.8.3.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [PATCH v3 04/14] drm/edid: parse YCBCR 420 videomodes from EDID

[Sharma, Shashank]

Yes, we should check for features, not for some standard version that
implements some/all of those features. But not convinced we need any
featur flags for the other things you listed. Aren't we already doing
all those things anyway?


Yep, I realized you will come back with this point, while typing these 
examples :-).
Ok then, I will add a flag which sounds more like ycbcr_420_supported or 
so.


Regards
Shashank
On 6/15/2017 10:29 PM, Ville Syrjälä wrote:

On Thu, Jun 15, 2017 at 10:18:40PM +0530, Sharma, Shashank wrote:

Regards

Shashank


On 6/15/2017 9:42 PM, Ville Syrjälä wrote:

On Thu, Jun 15, 2017 at 09:05:10PM +0530, Sharma, Shashank wrote:

Regards

Shashank


On 6/15/2017 8:13 PM, Ville Syrjälä wrote:

On Wed, Jun 14, 2017 at 11:17:35PM +0530, Shashank Sharma wrote:

HDMI 2.0 spec adds support for YCBCR420 sub-sampled output.
CEA-861-F adds two new blocks in EDID's CEA extension blocks,
to provide information about sink's YCBCR420 output capabilities.

These blocks are:

- YCBCR420vdb(YCBCR 420 video data block):
This block contains VICs of video modes, which can be sopported only
in YCBCR420 output mode (Not in RGB/YCBCR444/422. Its like a normal
SVD block, valid for YCBCR420 modes only.

- YCBCR420cmdb(YCBCR 420 capability map data block):
This block gives information about video modes which can support
YCBCR420 output mode also (along with RGB,YCBCR444/422 etc) This
block contains a bitmap index of normal svd videomodes, which can
support YCBCR420 output too.
So if bit 0 from first vcb byte is set, first video mode in the svd
list can support YCBCR420 output too. Bit 1 means second video mode
from svd list can support YCBCR420 output too, and so on.

This patch adds two bitmaps in display's hdmi_info structure, one each
for VCB and VDB modes. If the source is HDMI 2.0 capable, this patch
adds:
- VDB modes (YCBCR 420 only modes) in connector's mode list, also makes
 an entry in the vdb_bitmap per vic.
- VCB modes (YCBCR 420 also modes) only entry in the vcb_bitmap.

Cc: Ville Syrjala 
Cc: Jose Abreu 
Cc: Emil Velikov 

V2: Addressed
   Review comments from Emil:
   - Use 1ULL< 64 modes in capability map block.
   - Use y420cmdb in function names and macros while dealing with vcb
 to be aligned with spec.
   - Move the display information parsing block ahead of mode parsing
 blocks.

V3: Addressed design/review comments from Ville
   - Do not add flags in video modes, else we have to expose them to user
   - There should not be a UABI change, and kernel should detect the
 choice of the output based on type of mode, and the bitmaps.
   - Use standard bitops from kernel bitmap header, instead of calculating
 bit positions manually.

Signed-off-by: Shashank Sharma 
---
drivers/gpu/drm/drm_edid.c  | 193 
++--
include/drm/drm_connector.h |  23 ++
2 files changed, 211 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 6fd8a98..4953f87 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2781,7 +2781,9 @@ add_detailed_modes(struct drm_connector *connector, 
struct edid *edid,
#define VIDEO_BLOCK 0x02
#define VENDOR_BLOCK0x03
#define SPEAKER_BLOCK   0x04
-#define VIDEO_CAPABILITY_BLOCK 0x07
+#define VIDEO_CAPABILITY_BLOCK 0x07
+#define VIDEO_DATA_BLOCK_420   0x0E
+#define VIDEO_CAP_BLOCK_Y420CMDB 0x0F
#define EDID_BASIC_AUDIO(1 << 6)
#define EDID_CEA_YCRCB444   (1 << 5)
#define EDID_CEA_YCRCB422   (1 << 4)
@@ -3143,15 +3145,103 @@ drm_display_mode_from_vic_index(struct drm_connector 
*connector,
return newmode;
}

+/*

+ * do_ycbcr_420_vdb_modes - Parse YCBCR 420 only modes
+ * @connector: connector corresponding to the HDMI sink
+ * @svds: start of the data block of CEA YCBCR 420 VDB
+ * @len: length of the CEA YCBCR 420 VDB
+ *
+ * CEA-861-F has added a new video block called YCBCR 420 Video
+ * Data Block (ycbcr 420 vdb). This block contains modes which
+ * support YCBCR 420 HDMI output (only YCBCR 420). This function
+ * parses the block and adds these modes into connector's mode list.

Seems a bit verbose. Maybe something like:
"Parse the CEA-861-F YCbCr 4:2:0 Video Data Block (Y420VDB)
which contains modes which only support YCbCr 4:2:0 output."

Got it.

+ */
+static int do_ycbcr_420_vdb_modes(struct drm_connector *connector,
+  const u8 *svds, u8 svds_len)

Probably we could s/ycbcr_420_vdb/y420vdb/ all over to keep things
shorter and match the terminology in the spec. Same for y420cmdb.

Got it.

+{
+   int modes = 0, i;
+   struct drm_device *dev = connector->dev;
+   struct drm_display_mode *newmode;

This variable can be moved into the loop scope.

Ok.

+   struct drm_display_info 

[Bug 101387] amdgpu display corruption and hang on AMD A10-9620P

[bugzilla-daemon]

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

--- Comment #15 from Alex Deucher  ---
(In reply to Carlo Caione from comment #14)
> 
> Fortunately it disappears after ~2 seconds when plymouth kicks in. My
> impression is that the visual corruption is triggered again when
> interpreting some atombios code, not really easy to debug.

Probably just intermediate garbage that happens to be visible while the memory
controller or display hw is being reprogrammed.

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

Re: [PATCH v3 04/14] drm/edid: parse YCBCR 420 videomodes from EDID

[Ville Syrjälä]

On Thu, Jun 15, 2017 at 10:18:40PM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 6/15/2017 9:42 PM, Ville Syrjälä wrote:
> > On Thu, Jun 15, 2017 at 09:05:10PM +0530, Sharma, Shashank wrote:
> >> Regards
> >>
> >> Shashank
> >>
> >>
> >> On 6/15/2017 8:13 PM, Ville Syrjälä wrote:
> >>> On Wed, Jun 14, 2017 at 11:17:35PM +0530, Shashank Sharma wrote:
>  HDMI 2.0 spec adds support for YCBCR420 sub-sampled output.
>  CEA-861-F adds two new blocks in EDID's CEA extension blocks,
>  to provide information about sink's YCBCR420 output capabilities.
> 
>  These blocks are:
> 
>  - YCBCR420vdb(YCBCR 420 video data block):
>  This block contains VICs of video modes, which can be sopported only
>  in YCBCR420 output mode (Not in RGB/YCBCR444/422. Its like a normal
>  SVD block, valid for YCBCR420 modes only.
> 
>  - YCBCR420cmdb(YCBCR 420 capability map data block):
>  This block gives information about video modes which can support
>  YCBCR420 output mode also (along with RGB,YCBCR444/422 etc) This
>  block contains a bitmap index of normal svd videomodes, which can
>  support YCBCR420 output too.
>  So if bit 0 from first vcb byte is set, first video mode in the svd
>  list can support YCBCR420 output too. Bit 1 means second video mode
>  from svd list can support YCBCR420 output too, and so on.
> 
>  This patch adds two bitmaps in display's hdmi_info structure, one each
>  for VCB and VDB modes. If the source is HDMI 2.0 capable, this patch
>  adds:
>  - VDB modes (YCBCR 420 only modes) in connector's mode list, also makes
>  an entry in the vdb_bitmap per vic.
>  - VCB modes (YCBCR 420 also modes) only entry in the vcb_bitmap.
> 
>  Cc: Ville Syrjala 
>  Cc: Jose Abreu 
>  Cc: Emil Velikov 
> 
>  V2: Addressed
>    Review comments from Emil:
>    - Use 1ULL<    - Use the suggested method for updating dbmap.
>    - Add documentation for YCBCR420_vcb_map to fix kbuild warning.
> 
>    Review comments from Ville:
>    - Do not expose the YCBCR420 flags in uabi layer, keep it internal.
>    - Save a map of YCBCR420 modes for future reference.
>    - Check db length before trying to parse extended tag.
>    - Add a warning if there are > 64 modes in capability map block.
>    - Use y420cmdb in function names and macros while dealing with vcb
>  to be aligned with spec.
>    - Move the display information parsing block ahead of mode parsing
>  blocks.
> 
>  V3: Addressed design/review comments from Ville
>    - Do not add flags in video modes, else we have to expose them to 
>  user
>    - There should not be a UABI change, and kernel should detect the
>  choice of the output based on type of mode, and the bitmaps.
>    - Use standard bitops from kernel bitmap header, instead of 
>  calculating
>  bit positions manually.
> 
>  Signed-off-by: Shashank Sharma 
>  ---
> drivers/gpu/drm/drm_edid.c  | 193 
>  ++--
> include/drm/drm_connector.h |  23 ++
> 2 files changed, 211 insertions(+), 5 deletions(-)
> 
>  diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>  index 6fd8a98..4953f87 100644
>  --- a/drivers/gpu/drm/drm_edid.c
>  +++ b/drivers/gpu/drm/drm_edid.c
>  @@ -2781,7 +2781,9 @@ add_detailed_modes(struct drm_connector 
>  *connector, struct edid *edid,
> #define VIDEO_BLOCK 0x02
> #define VENDOR_BLOCK0x03
> #define SPEAKER_BLOCK 0x04
>  -#define VIDEO_CAPABILITY_BLOCK  0x07
>  +#define VIDEO_CAPABILITY_BLOCK 0x07
>  +#define VIDEO_DATA_BLOCK_4200x0E
>  +#define VIDEO_CAP_BLOCK_Y420CMDB 0x0F
> #define EDID_BASIC_AUDIO  (1 << 6)
> #define EDID_CEA_YCRCB444 (1 << 5)
> #define EDID_CEA_YCRCB422 (1 << 4)
>  @@ -3143,15 +3145,103 @@ drm_display_mode_from_vic_index(struct 
>  drm_connector *connector,
>   return newmode;
> }
> 
>  +/*
>  + * do_ycbcr_420_vdb_modes - Parse YCBCR 420 only modes
>  + * @connector: connector corresponding to the HDMI sink
>  + * @svds: start of the data block of CEA YCBCR 420 VDB
>  + * @len: length of the CEA YCBCR 420 VDB
>  + *
>  + * CEA-861-F has added a new video block called YCBCR 420 Video
>  + * Data Block (ycbcr 420 vdb). This block contains modes which
>  + * support YCBCR 420 HDMI output (only YCBCR 420). This function
>  + * parses the block and adds these modes into connector's mode list.
> >>> Seems a bit verbose. Maybe something like:
> >>> "Parse the 

Re: [PATCH] drm: Reduce scope of 'state' variable

[Dawid Kurek]

On 15/06/17, Jani Nikula wrote:
> On Thu, 15 Jun 2017, Dawid Kurek  wrote:
> > On 15/06/17, Jani Nikula wrote:
> >> Separate declaration and initialization would lead to a cleaner patch
> >> and result.
> >
> > I saw combining declaration and initialization is quite common, i.e. in
> > drm_atomic file. Personally, I also prefer those in one statement. But yes, 
> > it
> > looks cleaner here, in two lines.
> 
> I'd say the rule of thumb is that combined declaration and
> initialization is fine if the initialization is trivial, in particular
> can never fail. If you need to check the return value, like in this
> case, I'd prefer separate initialization.
> 
Yeah, makes sense. If you need to check then it exceeds simple initialization,
and then it is not declare Yes, now I see it.

Thanks a lot,
Dawid

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

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

Re: [PATCH v3 04/14] drm/edid: parse YCBCR 420 videomodes from EDID

[Sharma, Shashank]

Regards

Shashank


On 6/15/2017 9:42 PM, Ville Syrjälä wrote:

On Thu, Jun 15, 2017 at 09:05:10PM +0530, Sharma, Shashank wrote:

Regards

Shashank


On 6/15/2017 8:13 PM, Ville Syrjälä wrote:

On Wed, Jun 14, 2017 at 11:17:35PM +0530, Shashank Sharma wrote:

HDMI 2.0 spec adds support for YCBCR420 sub-sampled output.
CEA-861-F adds two new blocks in EDID's CEA extension blocks,
to provide information about sink's YCBCR420 output capabilities.

These blocks are:

- YCBCR420vdb(YCBCR 420 video data block):
This block contains VICs of video modes, which can be sopported only
in YCBCR420 output mode (Not in RGB/YCBCR444/422. Its like a normal
SVD block, valid for YCBCR420 modes only.

- YCBCR420cmdb(YCBCR 420 capability map data block):
This block gives information about video modes which can support
YCBCR420 output mode also (along with RGB,YCBCR444/422 etc) This
block contains a bitmap index of normal svd videomodes, which can
support YCBCR420 output too.
So if bit 0 from first vcb byte is set, first video mode in the svd
list can support YCBCR420 output too. Bit 1 means second video mode
from svd list can support YCBCR420 output too, and so on.

This patch adds two bitmaps in display's hdmi_info structure, one each
for VCB and VDB modes. If the source is HDMI 2.0 capable, this patch
adds:
- VDB modes (YCBCR 420 only modes) in connector's mode list, also makes
an entry in the vdb_bitmap per vic.
- VCB modes (YCBCR 420 also modes) only entry in the vcb_bitmap.

Cc: Ville Syrjala 
Cc: Jose Abreu 
Cc: Emil Velikov 

V2: Addressed
  Review comments from Emil:
  - Use 1ULL< 64 modes in capability map block.
  - Use y420cmdb in function names and macros while dealing with vcb
to be aligned with spec.
  - Move the display information parsing block ahead of mode parsing
blocks.

V3: Addressed design/review comments from Ville
  - Do not add flags in video modes, else we have to expose them to user
  - There should not be a UABI change, and kernel should detect the
choice of the output based on type of mode, and the bitmaps.
  - Use standard bitops from kernel bitmap header, instead of calculating
bit positions manually.

Signed-off-by: Shashank Sharma 
---
   drivers/gpu/drm/drm_edid.c  | 193 
++--
   include/drm/drm_connector.h |  23 ++
   2 files changed, 211 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 6fd8a98..4953f87 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2781,7 +2781,9 @@ add_detailed_modes(struct drm_connector *connector, 
struct edid *edid,
   #define VIDEO_BLOCK 0x02
   #define VENDOR_BLOCK0x03
   #define SPEAKER_BLOCK0x04
-#define VIDEO_CAPABILITY_BLOCK 0x07
+#define VIDEO_CAPABILITY_BLOCK 0x07
+#define VIDEO_DATA_BLOCK_420   0x0E
+#define VIDEO_CAP_BLOCK_Y420CMDB 0x0F
   #define EDID_BASIC_AUDIO (1 << 6)
   #define EDID_CEA_YCRCB444(1 << 5)
   #define EDID_CEA_YCRCB422(1 << 4)
@@ -3143,15 +3145,103 @@ drm_display_mode_from_vic_index(struct drm_connector 
*connector,
return newmode;
   }
   
+/*

+ * do_ycbcr_420_vdb_modes - Parse YCBCR 420 only modes
+ * @connector: connector corresponding to the HDMI sink
+ * @svds: start of the data block of CEA YCBCR 420 VDB
+ * @len: length of the CEA YCBCR 420 VDB
+ *
+ * CEA-861-F has added a new video block called YCBCR 420 Video
+ * Data Block (ycbcr 420 vdb). This block contains modes which
+ * support YCBCR 420 HDMI output (only YCBCR 420). This function
+ * parses the block and adds these modes into connector's mode list.

Seems a bit verbose. Maybe something like:
"Parse the CEA-861-F YCbCr 4:2:0 Video Data Block (Y420VDB)
which contains modes which only support YCbCr 4:2:0 output."

Got it.

+ */
+static int do_ycbcr_420_vdb_modes(struct drm_connector *connector,
+  const u8 *svds, u8 svds_len)

Probably we could s/ycbcr_420_vdb/y420vdb/ all over to keep things
shorter and match the terminology in the spec. Same for y420cmdb.

Got it.

+{
+   int modes = 0, i;
+   struct drm_device *dev = connector->dev;
+   struct drm_display_mode *newmode;

This variable can be moved into the loop scope.

Ok.

+   struct drm_display_info *info = >display_info;
+   struct drm_hdmi_info *hdmi = >hdmi;
+
+   for (i = 0; i < svds_len; i++) {
+   u8 vic = svds[i] & 0x7f;

What's the 0x7f here? Native bit stuff? I'm thinkign we probably want
some kind of svd_to_vic() function to make sure everyone deals with
this stuff correctly.

Current VICs are 1 < VIC < 108, so seven bits required to show a VIC.
This is inspired from
drm_mode_from_cea_vic_index().

+
+   newmode = drm_mode_duplicate(dev, _cea_modes[vic]);
+   if (!newmode)
+

[tegra-drm:drm/tegra/for-next 2/20] htmldocs: drivers/gpu/host1x/bus.c:50: warning: Excess function parameter 'driver' description in 'host1x_subdev_add'

[kbuild test robot]

tree:   git://anongit.freedesktop.org/tegra/linux.git drm/tegra/for-next
head:   43240bbd871e2c8f89584d369278a3d18680d9ea
commit: fa6d095eb23a8b1aae78d221879032497f6e457f [2/20] drm/tegra: Add driver 
documentation
reproduce: make htmldocs

All warnings (new ones prefixed by >>):

   WARNING: convert(1) not found, for SVG to PDF conversion install ImageMagick 
(https://www.imagemagick.org)
   arch/x86/include/asm/uaccess_32.h:1: warning: no structured comments found
   include/linux/init.h:1: warning: no structured comments found
   include/linux/mod_devicetable.h:686: warning: Excess 
struct/union/enum/typedef member 'ver_major' description in 'fsl_mc_device_id'
   include/linux/mod_devicetable.h:686: warning: Excess 
struct/union/enum/typedef member 'ver_minor' description in 'fsl_mc_device_id'
   kernel/sched/core.c:2088: warning: No description found for parameter 'rf'
   kernel/sched/core.c:2088: warning: Excess function parameter 'cookie' 
description in 'try_to_wake_up_local'
   include/linux/kthread.h:26: warning: Excess function parameter '...' 
description in 'kthread_create'
   kernel/sys.c:1: warning: no structured comments found
   include/linux/device.h:969: warning: No description found for parameter 
'dma_ops'
   drivers/dma-buf/seqno-fence.c:1: warning: no structured comments found
   include/linux/iio/iio.h:597: warning: No description found for parameter 
'trig_readonly'
   include/linux/iio/trigger.h:151: warning: No description found for parameter 
'indio_dev'
   include/linux/iio/trigger.h:151: warning: No description found for parameter 
'trig'
   include/linux/device.h:970: warning: No description found for parameter 
'dma_ops'
   include/linux/usb/gadget.h:230: warning: No description found for parameter 
'claimed'
   include/linux/usb/gadget.h:230: warning: No description found for parameter 
'enabled'
   include/linux/usb/gadget.h:408: warning: No description found for parameter 
'quirk_altset_not_supp'
   include/linux/usb/gadget.h:408: warning: No description found for parameter 
'quirk_stall_not_supp'
   include/linux/usb/gadget.h:408: warning: No description found for parameter 
'quirk_zlp_not_supp'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'set_busid'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'irq_handler'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'irq_preinstall'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'irq_postinstall'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'irq_uninstall'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'debugfs_init'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_open_object'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_close_object'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'prime_handle_to_fd'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'prime_fd_to_handle'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_export'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_import'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_pin'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_unpin'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_res_obj'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_get_sg_table'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_import_sg_table'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_vmap'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_vunmap'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_mmap'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_vm_ops'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'major'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'minor'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'patchlevel'
   include/drm/drm_drv.h:524: warning: No description found for parameter 'name'
   include/drm/drm_drv.h:524: warning: No description found for parameter 'desc'
   include/drm/drm_drv.h:524: warning: No description found for parameter 'date'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'driver_features'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'ioctls'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'num_ioctls'
   include/drm/drm_drv.h:524: warning: No description found for parameter 'fops'
   

[Bug 101387] amdgpu display corruption and hang on AMD A10-9620P

[bugzilla-daemon]

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

--- Comment #14 from Carlo Caione  ---
> not likely related.

Alright, any hint where to start looking? As I said before it looks like the
visual corruption (this https://pasteboard.co/qrC9mh4p.jpg) at boot starts at

[drm] amdgpu atom DIG backlight initialized
[drm] AMDGPU Display Connectors
[drm] Connector 0:
[drm]   eDP-1
[drm]   HPD1
[drm]   DDC: 0x4868 0x4868 0x4869 0x4869 0x486a 0x486a 0x486b 0x486b
[drm]   Encoders:
[drm] LCD1: INTERNAL_UNIPHY
[drm] Connector 1:
[drm]   HDMI-A-1
[drm]   HPD2
[drm]   DDC: 0x486c 0x486c 0x486d 0x486d 0x486e 0x486e 0x486f 0x486f
[drm]   Encoders:
[drm] DFP1: INTERNAL_UNIPHY
[drm] amdgpu atom DIG backlight initialized
[drm] AMDGPU Display Connectors
[drm] Connector 0:
[drm]   eDP-1
[drm]   HPD1
[drm]   DDC: 0x4868 0x4868 0x4869 0x4869 0x486a 0x486a 0x486b 0x486b
[drm]   Encoders:
[drm] LCD1: INTERNAL_UNIPHY
[drm] Connector 1:
[drm]   HDMI-A-1
[drm]   HPD2
[drm]   DDC: 0x486c 0x486c 0x486d 0x486d 0x486e 0x486e 0x486f 0x486f
[drm]   Encoders:
[drm] DFP1: INTERNAL_UNIPHY

Fortunately it disappears after ~2 seconds when plymouth kicks in. My
impression is that the visual corruption is triggered again when interpreting
some atombios code, not really easy to 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: [PATCH] drm: Remove duplicate forward declaration

[Sean Paul]

On Wed, Jun 14, 2017 at 11:35:18PM +0200, Dawid Kurek wrote:
> Forward declarations in C are great but I'm pretty sure one is enough.

Applied to drm-misc-next

Thanks,

Sean

> 
> Signed-off-by: Dawid Kurek 
> ---
>  include/drm/drm_connector.h | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 4eeda12..930222c 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -29,8 +29,6 @@
>  
>  #include 
>  
> -struct drm_device;
> -
>  struct drm_connector_helper_funcs;
>  struct drm_modeset_acquire_ctx;
>  struct drm_device;
> -- 
> 2.10.0
> 
> 
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus

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

Re: [PATCH v3 04/14] drm/edid: parse YCBCR 420 videomodes from EDID

[Ville Syrjälä]

On Thu, Jun 15, 2017 at 09:05:10PM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 6/15/2017 8:13 PM, Ville Syrjälä wrote:
> > On Wed, Jun 14, 2017 at 11:17:35PM +0530, Shashank Sharma wrote:
> >> HDMI 2.0 spec adds support for YCBCR420 sub-sampled output.
> >> CEA-861-F adds two new blocks in EDID's CEA extension blocks,
> >> to provide information about sink's YCBCR420 output capabilities.
> >>
> >> These blocks are:
> >>
> >> - YCBCR420vdb(YCBCR 420 video data block):
> >> This block contains VICs of video modes, which can be sopported only
> >> in YCBCR420 output mode (Not in RGB/YCBCR444/422. Its like a normal
> >> SVD block, valid for YCBCR420 modes only.
> >>
> >> - YCBCR420cmdb(YCBCR 420 capability map data block):
> >> This block gives information about video modes which can support
> >> YCBCR420 output mode also (along with RGB,YCBCR444/422 etc) This
> >> block contains a bitmap index of normal svd videomodes, which can
> >> support YCBCR420 output too.
> >> So if bit 0 from first vcb byte is set, first video mode in the svd
> >> list can support YCBCR420 output too. Bit 1 means second video mode
> >> from svd list can support YCBCR420 output too, and so on.
> >>
> >> This patch adds two bitmaps in display's hdmi_info structure, one each
> >> for VCB and VDB modes. If the source is HDMI 2.0 capable, this patch
> >> adds:
> >> - VDB modes (YCBCR 420 only modes) in connector's mode list, also makes
> >>an entry in the vdb_bitmap per vic.
> >> - VCB modes (YCBCR 420 also modes) only entry in the vcb_bitmap.
> >>
> >> Cc: Ville Syrjala 
> >> Cc: Jose Abreu 
> >> Cc: Emil Velikov 
> >>
> >> V2: Addressed
> >>  Review comments from Emil:
> >>  - Use 1ULL< >>  - Use the suggested method for updating dbmap.
> >>  - Add documentation for YCBCR420_vcb_map to fix kbuild warning.
> >>
> >>  Review comments from Ville:
> >>  - Do not expose the YCBCR420 flags in uabi layer, keep it internal.
> >>  - Save a map of YCBCR420 modes for future reference.
> >>  - Check db length before trying to parse extended tag.
> >>  - Add a warning if there are > 64 modes in capability map block.
> >>  - Use y420cmdb in function names and macros while dealing with vcb
> >>to be aligned with spec.
> >>  - Move the display information parsing block ahead of mode parsing
> >>blocks.
> >>
> >> V3: Addressed design/review comments from Ville
> >>  - Do not add flags in video modes, else we have to expose them to user
> >>  - There should not be a UABI change, and kernel should detect the
> >>choice of the output based on type of mode, and the bitmaps.
> >>  - Use standard bitops from kernel bitmap header, instead of 
> >> calculating
> >>bit positions manually.
> >>
> >> Signed-off-by: Shashank Sharma 
> >> ---
> >>   drivers/gpu/drm/drm_edid.c  | 193 
> >> ++--
> >>   include/drm/drm_connector.h |  23 ++
> >>   2 files changed, 211 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> >> index 6fd8a98..4953f87 100644
> >> --- a/drivers/gpu/drm/drm_edid.c
> >> +++ b/drivers/gpu/drm/drm_edid.c
> >> @@ -2781,7 +2781,9 @@ add_detailed_modes(struct drm_connector *connector, 
> >> struct edid *edid,
> >>   #define VIDEO_BLOCK 0x02
> >>   #define VENDOR_BLOCK0x03
> >>   #define SPEAKER_BLOCK0x04
> >> -#define VIDEO_CAPABILITY_BLOCK0x07
> >> +#define VIDEO_CAPABILITY_BLOCK 0x07
> >> +#define VIDEO_DATA_BLOCK_420  0x0E
> >> +#define VIDEO_CAP_BLOCK_Y420CMDB 0x0F
> >>   #define EDID_BASIC_AUDIO (1 << 6)
> >>   #define EDID_CEA_YCRCB444(1 << 5)
> >>   #define EDID_CEA_YCRCB422(1 << 4)
> >> @@ -3143,15 +3145,103 @@ drm_display_mode_from_vic_index(struct 
> >> drm_connector *connector,
> >>return newmode;
> >>   }
> >>   
> >> +/*
> >> + * do_ycbcr_420_vdb_modes - Parse YCBCR 420 only modes
> >> + * @connector: connector corresponding to the HDMI sink
> >> + * @svds: start of the data block of CEA YCBCR 420 VDB
> >> + * @len: length of the CEA YCBCR 420 VDB
> >> + *
> >> + * CEA-861-F has added a new video block called YCBCR 420 Video
> >> + * Data Block (ycbcr 420 vdb). This block contains modes which
> >> + * support YCBCR 420 HDMI output (only YCBCR 420). This function
> >> + * parses the block and adds these modes into connector's mode list.
> > Seems a bit verbose. Maybe something like:
> > "Parse the CEA-861-F YCbCr 4:2:0 Video Data Block (Y420VDB)
> > which contains modes which only support YCbCr 4:2:0 output."
> Got it.
> >> + */
> >> +static int do_ycbcr_420_vdb_modes(struct drm_connector *connector,
> >> + const u8 *svds, u8 svds_len)
> > Probably we could s/ycbcr_420_vdb/y420vdb/ all over to keep things
> > shorter and match the terminology in the spec. 

Re: [PATCH] drm/i915: fix ifnullfree.cocci warnings

[Chris Wilson]

Quoting kbuild test robot (2017-06-15 16:23:12)
> drivers/gpu/drm/i915/i915_gem_execbuffer.c:300:2-7: WARNING: NULL check 
> before freeing functions like kfree, debugfs_remove, debugfs_remove_recursive 
> or usb_free_urb is not needed. Maybe consider reorganizing relevant code to 
> avoid passing NULL values.

It exists because it was a stepping towards the compare being not
against NULL.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[pull] amdgpu drm-next-4.13

[Alex Deucher]

Hi Dave,

A few more patches for 4.13.  Mostly bug fixes and code cleanup.  This is on
top of my pull request from last week.

The following changes since commit b58c11314a1706bf094c489ef5cb28f76478c704:

  drm/amdgpu: drop deprecated drm_get_pci_dev and drm_put_dev (2017-06-08 
10:54:39 -0400)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-next-4.13

for you to fetch changes up to a1924005a2e9bfcc4e217b4acd0a4f2421969040:

  drm/amdgpu: Fix compiler warnings (2017-06-15 11:50:36 -0400)


Alex Deucher (3):
  drm/amdgpu/gfx: fix MEC interrupt enablement for pipes != 0
  drm/amdgpu/gfx9: fix compute ring doorbell index
  drm/amdgpu: add virtual display support for raven

Alex Xie (3):
  drm/amdgpu: remove duplicate function prototypes
  drm/amdgpu: fix a typo in comment
  drm/amdgpu: move comment to the right place

Eric Huang (3):
  drm/amd/powerplay: update vega10_ppsmc.h
  drm/amd/powerplay: add GPU power display for vega10
  drm/amd/powerplay: add avfs control for Vega10

Harish Kasiviswanathan (6):
  drm/amdgpu: Add vm context module param
  drm/amdgpu: Add amdgpu_sync_wait
  drm/amdgpu: Support page directory update via CPU
  drm/amdgpu: Support page table update via CPU
  drm/amdgpu: vm_update_ptes remove code duplication
  drm/amdgpu: Fix compiler warnings

Hawking Zhang (2):
  drm/amdgpu: add new member in gpu_info fw
  drm/amdgpu: avoid to reset wave_front_size to 0

Huang Rui (2):
  drm/amdgpu: export test ib debugfs interface
  drm/amdgpu: fix missed gpu info firmware when cache firmware during S3

Rex Zhu (1):
  drm/amd/powerplay: fix copy error in powerplay.

Tom St Denis (12):
  drm/amd/amdgpu: gfx9 tidy ups (v2)
  drm/amd/amdgpu: Rename KIQ ring to avoid spaces
  drm/amd/amdgpu: Add offset variant to SOC15 macros
  drm/amd/amdgpu: Port GFXHUB over to new SOC15 macros
  drm/amd/amdgpu: Cleanup gfxhub read-modify-write patterns
  drm/amd/amdgpu: Port MMHUB over to new SOC15 macros
  drm/amd/amdgpu: Port UVD 7.0 over to new SOC15 macros
  drm/amd/amdgpu: Port NBIO v6.1 driver over to new SOC15 macros
  drm/amd/amdgpu: Port NBIO v7.0 driver over to new SOC15 macros
  drm/amd/amdgpu: Port PSP v3.1 over to new SOC15 macros
  drm/amd/amdgpu: Port PSP v10.0 over to new SOC15 macros
  drm/amd/amdgpu: Port VCN over to new SOC15 macros

horchen (1):
  drm/amdgpu: add contiguous flag in ucode bo create

 drivers/gpu/drm/amd/amdgpu/amdgpu.h|   8 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c |   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  81 ++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|   4 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c|   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c|   3 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c   |  19 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_sync.h   |   1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c  |   3 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.h  |   3 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 250 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h |  20 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c  |  57 +++--
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c  |  57 +++--
 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c  |  89 
 drivers/gpu/drm/amd/amdgpu/gfxhub_v1_0.c   |  37 ++-
 drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c|  25 +--
 drivers/gpu/drm/amd/amdgpu/nbio_v6_1.c |  54 ++---
 drivers/gpu/drm/amd/amdgpu/nbio_v7_0.c |  42 ++--
 drivers/gpu/drm/amd/amdgpu/psp_v10_0.c |  14 +-
 drivers/gpu/drm/amd/amdgpu/psp_v3_1.c  |  32 +--
 drivers/gpu/drm/amd/amdgpu/soc15.c |   2 +
 drivers/gpu/drm/amd/amdgpu/soc15_common.h  |  14 ++
 drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c  | 174 +++---
 drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c  | 164 +++---
 drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c |  27 ++-
 drivers/gpu/drm/amd/powerplay/inc/vega10_ppsmc.h   |   3 +-
 27 files changed, 765 insertions(+), 422 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] dim: allow setup to work with different usernames

[Lionel Landwerlin]

If your username on fd.o differs from your local username, you'll run
into issues while setting up dim.

Let's use regexp to filter remotes so it doesn't fail.

Signed-off-by: Lionel Landwerlin 
---
 dim | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/dim b/dim
index 89378033f472..a812320581c2 100755
--- a/dim
+++ b/dim
@@ -228,21 +228,22 @@ function url_to_remote # url
 {
local url remote
 
-   url="$1"
+   url=$1
+   login_url=$(echo $url | sed -e 's,ssh://,ssh://[a-zA-Z0-9]+@?,')
 
if [[ -z "$url" ]]; then
echoerr "$0 without url"
return 1
fi
 
-   remote=$(git remote -v | grep -m 1 "$url" | cut -f 1)
+   remote=$(git remote -v | grep -m 1 -E "$login_url" | cut -f 1)
 
if [[ -z "$remote" ]]; then
-   git_url=$(echo $url | sed -e 's/git\./anongit./' -e 
's/ssh:/git:/')
-   remote=$(git remote -v | grep -m 1 "$git_url" | cut -f 1)
+   git_url=$(echo $url | sed -e 's/git\./anongit./' -e 
's,ssh://[a-zA-Z0-9]+@?,git://,')
+   remote=$(git remote -v | grep -m 1 -E "$git_url" | cut -f 1)
 
if [[ -z "$remote" ]]; then
-   echoerr "No git remote for url $url or $git_url found 
in $(pwd)"
+   echoerr "No git remote for url $url, $login_url or 
$git_url found in $(pwd)"
echoerr "Please set it up using:"
echoerr "$ git remote add  $url"
echoerr "with a name of your choice."
-- 
2.11.0

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

[Bug 101387] amdgpu display corruption and hang on AMD A10-9620P

[bugzilla-daemon]

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

--- Comment #13 from Alex Deucher  ---
(In reply to Carlo Caione from comment #12)
> Also (in case it is useful for the corruption issue):
> 

not likely related.

> 00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
> Device 9874 (rev ca)
> ...
> 03:00.0 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Device
> 699f (rev ff)
> 
> # echo 1 > /sys/bus/pci/devices/\:00\:01.0/rom
> # cat /sys/bus/pci/devices/\:00\:01.0/rom > /tmp/vbios.rom
> cat: /sys/bus/pci/devices/:00:01.0/rom: Input/output error

If this is an UEFI system, that may not work.

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

Re: [PATCH v3 04/14] drm/edid: parse YCBCR 420 videomodes from EDID

[Sharma, Shashank]

Regards

Shashank


On 6/15/2017 8:13 PM, Ville Syrjälä wrote:

On Wed, Jun 14, 2017 at 11:17:35PM +0530, Shashank Sharma wrote:

HDMI 2.0 spec adds support for YCBCR420 sub-sampled output.
CEA-861-F adds two new blocks in EDID's CEA extension blocks,
to provide information about sink's YCBCR420 output capabilities.

These blocks are:

- YCBCR420vdb(YCBCR 420 video data block):
This block contains VICs of video modes, which can be sopported only
in YCBCR420 output mode (Not in RGB/YCBCR444/422. Its like a normal
SVD block, valid for YCBCR420 modes only.

- YCBCR420cmdb(YCBCR 420 capability map data block):
This block gives information about video modes which can support
YCBCR420 output mode also (along with RGB,YCBCR444/422 etc) This
block contains a bitmap index of normal svd videomodes, which can
support YCBCR420 output too.
So if bit 0 from first vcb byte is set, first video mode in the svd
list can support YCBCR420 output too. Bit 1 means second video mode
from svd list can support YCBCR420 output too, and so on.

This patch adds two bitmaps in display's hdmi_info structure, one each
for VCB and VDB modes. If the source is HDMI 2.0 capable, this patch
adds:
- VDB modes (YCBCR 420 only modes) in connector's mode list, also makes
   an entry in the vdb_bitmap per vic.
- VCB modes (YCBCR 420 also modes) only entry in the vcb_bitmap.

Cc: Ville Syrjala 
Cc: Jose Abreu 
Cc: Emil Velikov 

V2: Addressed
 Review comments from Emil:
 - Use 1ULL< 64 modes in capability map block.
 - Use y420cmdb in function names and macros while dealing with vcb
   to be aligned with spec.
 - Move the display information parsing block ahead of mode parsing
   blocks.

V3: Addressed design/review comments from Ville
 - Do not add flags in video modes, else we have to expose them to user
 - There should not be a UABI change, and kernel should detect the
   choice of the output based on type of mode, and the bitmaps.
 - Use standard bitops from kernel bitmap header, instead of calculating
   bit positions manually.

Signed-off-by: Shashank Sharma 
---
  drivers/gpu/drm/drm_edid.c  | 193 ++--
  include/drm/drm_connector.h |  23 ++
  2 files changed, 211 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 6fd8a98..4953f87 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2781,7 +2781,9 @@ add_detailed_modes(struct drm_connector *connector, 
struct edid *edid,
  #define VIDEO_BLOCK 0x02
  #define VENDOR_BLOCK0x03
  #define SPEAKER_BLOCK 0x04
-#define VIDEO_CAPABILITY_BLOCK 0x07
+#define VIDEO_CAPABILITY_BLOCK 0x07
+#define VIDEO_DATA_BLOCK_420   0x0E
+#define VIDEO_CAP_BLOCK_Y420CMDB 0x0F
  #define EDID_BASIC_AUDIO  (1 << 6)
  #define EDID_CEA_YCRCB444 (1 << 5)
  #define EDID_CEA_YCRCB422 (1 << 4)
@@ -3143,15 +3145,103 @@ drm_display_mode_from_vic_index(struct drm_connector 
*connector,
return newmode;
  }
  
+/*

+ * do_ycbcr_420_vdb_modes - Parse YCBCR 420 only modes
+ * @connector: connector corresponding to the HDMI sink
+ * @svds: start of the data block of CEA YCBCR 420 VDB
+ * @len: length of the CEA YCBCR 420 VDB
+ *
+ * CEA-861-F has added a new video block called YCBCR 420 Video
+ * Data Block (ycbcr 420 vdb). This block contains modes which
+ * support YCBCR 420 HDMI output (only YCBCR 420). This function
+ * parses the block and adds these modes into connector's mode list.

Seems a bit verbose. Maybe something like:
"Parse the CEA-861-F YCbCr 4:2:0 Video Data Block (Y420VDB)
which contains modes which only support YCbCr 4:2:0 output."

Got it.

+ */
+static int do_ycbcr_420_vdb_modes(struct drm_connector *connector,
+  const u8 *svds, u8 svds_len)

Probably we could s/ycbcr_420_vdb/y420vdb/ all over to keep things
shorter and match the terminology in the spec. Same for y420cmdb.

Got it.

+{
+   int modes = 0, i;
+   struct drm_device *dev = connector->dev;
+   struct drm_display_mode *newmode;

This variable can be moved into the loop scope.

Ok.

+   struct drm_display_info *info = >display_info;
+   struct drm_hdmi_info *hdmi = >hdmi;
+
+   for (i = 0; i < svds_len; i++) {
+   u8 vic = svds[i] & 0x7f;

What's the 0x7f here? Native bit stuff? I'm thinkign we probably want
some kind of svd_to_vic() function to make sure everyone deals with
this stuff correctly.
Current VICs are 1 < VIC < 108, so seven bits required to show a VIC. 
This is inspired from

drm_mode_from_cea_vic_index().

+
+   newmode = drm_mode_duplicate(dev, _cea_modes[vic]);
+   if (!newmode)
+   break;
+   /*
+* ycbcr420_vdb_modes is a fix position 128 bit bitmap.
+* Every bit here represents a VIC, 

[Bug 101387] amdgpu display corruption and hang on AMD A10-9620P

[bugzilla-daemon]

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

--- Comment #12 from Carlo Caione  ---
Also (in case it is useful for the corruption issue):

00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Device 9874 (rev ca)
...
03:00.0 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Device 699f
(rev ff)

# echo 1 > /sys/bus/pci/devices/\:00\:01.0/rom
# cat /sys/bus/pci/devices/\:00\:01.0/rom > /tmp/vbios.rom
cat: /sys/bus/pci/devices/:00:01.0/rom: Input/output error

...

# echo 1 > /sys/bus/pci/devices/\:03\:00.0/rom
# cat /sys/bus/pci/devices/\:03\:00.0/rom > /tmp/vbios.rom
cat: /sys/bus/pci/devices/:03:00.0/rom: Input/output error

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

[PATCH] drm/i915: fix ifnullfree.cocci warnings

[kbuild test robot]

drivers/gpu/drm/i915/i915_gem_execbuffer.c:300:2-7: WARNING: NULL check before 
freeing functions like kfree, debugfs_remove, debugfs_remove_recursive or 
usb_free_urb is not needed. Maybe consider reorganizing relevant code to avoid 
passing NULL values.

 NULL check before some freeing functions is not needed.

 Based on checkpatch warning
 "kfree(NULL) is safe this check is probably not required"
 and kfreeaddr.cocci by Julia Lawall.

Generated by: scripts/coccinelle/free/ifnullfree.cocci

Signed-off-by: Fengguang Wu 
---

 i915_gem_execbuffer.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -296,8 +296,7 @@ static void eb_destroy(struct i915_execb
 
i915_gem_context_put(eb->ctx);
 
-   if (eb->buckets)
-   kfree(eb->buckets);
+   kfree(eb->buckets);
 }
 
 static inline int use_cpu_reloc(struct drm_i915_gem_object *obj)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[drm-intel:for-linux-next 2/3] drivers/gpu/drm/i915/i915_gem_execbuffer.c:300:2-7: WARNING: NULL check before freeing functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb is

[kbuild test robot]

tree:   git://anongit.freedesktop.org/drm-intel for-linux-next
head:   8c45cec48e5871f93e56650f7e476d4ea7174a0e
commit: d55495b4dcce2efb4656edfe211eb0bfb27c3387 [2/3] drm/i915: Use 
vma->exec_entry as our double-entry placeholder


coccinelle warnings: (new ones prefixed by >>)

>> drivers/gpu/drm/i915/i915_gem_execbuffer.c:300:2-7: WARNING: NULL check 
>> before freeing functions like kfree, debugfs_remove, 
>> debugfs_remove_recursive or usb_free_urb is not needed. Maybe consider 
>> reorganizing relevant code to avoid passing NULL values.

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101387] amdgpu display corruption and hang on AMD A10-9620P

[bugzilla-daemon]

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

--- Comment #11 from Carlo Caione  ---
Yes, that solves the panic issue, thank you. I still have the corruption at
boot though, any idea what that can be?

-- 
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 93826] 2560x1440 @144Hz graphic glitches and bad refresh rate

[bugzilla-daemon]

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

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

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

Re: [PATCH v3] drm: mxsfb_crtc: Reset the eLCDIF controller

[Fabio Estevam]

Hi Marek,

On Mon, Jun 5, 2017 at 9:08 AM, Marek Vasut  wrote:

> I'm currently on vacation, try one more time and if it doesn't work out
> (which means this trivial list is not really working?), I'll send a PR
> sometime mid-month.

Tried your suggestion, but it did not work.

Could you please consider sending Dave Airlie a pull request with this patch?

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

Re: [PATCH] drm: Reduce scope of 'state' variable

[Jani Nikula]

On Thu, 15 Jun 2017, Dawid Kurek  wrote:
> On 15/06/17, Jani Nikula wrote:
>> Separate declaration and initialization would lead to a cleaner patch
>> and result.
>
> I saw combining declaration and initialization is quite common, i.e. in
> drm_atomic file. Personally, I also prefer those in one statement. But yes, it
> looks cleaner here, in two lines.

I'd say the rule of thumb is that combined declaration and
initialization is fine if the initialization is trivial, in particular
can never fail. If you need to check the return value, like in this
case, I'd prefer separate initialization.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101387] amdgpu display corruption and hang on AMD A10-9620P

[bugzilla-daemon]

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

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

This patch should fix the issue.

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

[PULL] drm-intel-fixes

[Jani Nikula]

Hi Dave, a GVT fix and a couple of rotation related fixes.

BR,
Jani.

The following changes since commit ef6c4d75e35345f8f362d6754bcd9a28292a897c:

  drm/i915: fix warning for unused variable (2017-06-08 17:09:44 +0300)

are available in the git repository at:

  git://anongit.freedesktop.org/git/drm-intel tags/drm-intel-fixes-2017-06-15

for you to fetch changes up to c380f681245d7ae57f17d9ebbbe8f8f1557ee1fb:

  drm/i915: Fix GVT-g PVINFO version compatibility check (2017-06-13 11:19:22 
+0300)


drm/i915 fixes for v4.12-rc6


Ville Syrjälä (2):
  drm/i915: Fix scaling check for 90/270 degree plane rotation
  drm/i915: Fix SKL+ watermarks for 90/270 rotation

Zhenyu Wang (1):
  drm/i915: Fix GVT-g PVINFO version compatibility check

 drivers/gpu/drm/i915/i915_pvinfo.h   |  8 ++--
 drivers/gpu/drm/i915/i915_vgpu.c | 10 --
 drivers/gpu/drm/i915/intel_display.c | 14 --
 drivers/gpu/drm/i915/intel_pm.c  | 36 
 4 files changed, 38 insertions(+), 30 deletions(-)

-- 
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 02/14] drm/edid: Complete CEA modedb(VIC 1-107)

[Ville Syrjälä]

On Thu, Jun 15, 2017 at 07:01:38PM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 6/15/2017 6:59 PM, Ville Syrjälä wrote:
> > On Wed, Jun 14, 2017 at 11:17:33PM +0530, Shashank Sharma wrote:
> >> CEA-861-F specs defines new video modes to be used with
> >> HDMI 2.0 EDIDs. The VIC range has been extended from 1-64 to
> >> 1-107.
> >>
> >> Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
> >> to be able to parse new CEA modes using the existing methods, we have
> >> to complete the modedb (VIC=65 onwards).
> >>
> >> This patch adds:
> >> - Timings for existing CEA video modes (from VIC=65 till VIC=92)
> >> - Newly added 4k modes (from VIC=93 to VIC=107).
> >>
> >> The patch was originaly discussed and reviewed here:
> >> https://patchwork.freedesktop.org/patch/135810/
> >>
> >> Cc: Ville Syrjala 
> >> Cc: Jose Abreu 
> >> Cc: Andrzej Hajda 
> >> Cc: Alex Deucher 
> >> Cc: Harry Wentland 
> >>
> >> V2: Rebase
> >> V3: Rebase
> > So what happend to the 'native' bit stuff again?
> Tried really hard finding that code, couldn't :(.
> Might need bit help here.

+static u8 svd_to_vic(u8 svd)
+{
+   ...;
+}
+
 static struct drm_display_mode *
 drm_display_mode_from_vic_index(struct drm_connector *connector,
const u8 *video_db, u8 video_len,
@@ -2915,7 +2920,7 @@ drm_display_mode_from_vic_index(struct drm_connector 
*connector,
return NULL;
 
/* CEA modes are numbered 1..127 */
-   vic = (video_db[video_index] & 127);
+   vic = svd_to_vic(video_db[video_index]);
if (!drm_valid_cea_vic(vic))
return NULL;
 

or something along those lines is what I was thinking.

Actually I'm thinking that we should probably pull the svd_to_vic()
stuff outside drm_display_mode_from_vic_index() since we may anyway
want to deal with the VIC outside. But we could leave that for later.

> 
> - Shashank
> >> Reviewed-by: Jose Abreu 
> >> Reviewed-by: Alex Deucher 
> >> Acked-by: Harry Wentland 
> >> Signed-off-by: Shashank Sharma 
> >> ---
> >>   drivers/gpu/drm/drm_edid.c | 215 
> >> +
> >>   1 file changed, 215 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> >> index d312fe1..6fd8a98 100644
> >> --- a/drivers/gpu/drm/drm_edid.c
> >> +++ b/drivers/gpu/drm/drm_edid.c
> >> @@ -1006,6 +1006,221 @@ static const struct drm_display_mode 
> >> edid_cea_modes[] = {
> >>   2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
> >>   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> >> .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> >> +  /* 65 - 1280x720@24Hz */
> >> +  { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59400, 1280, 3040,
> >> + 3080, 3300, 0, 720, 725, 730, 750, 0,
> >> + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> >> +.vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> >> +  /* 66 - 1280x720@25Hz */
> >> +  { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3700,
> >> + 3740, 3960, 0, 720, 725, 730, 750, 0,
> >> + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> >> +.vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> >> +  /* 67 - 1280x720@30Hz */
> >> +  { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3040,
> >> + 3080, 3300, 0, 720, 725, 730, 750, 0,
> >> + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> >> +.vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> >> +  /* 68 - 1280x720@50Hz */
> >> +  { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1720,
> >> + 1760, 1980, 0, 720, 725, 730, 750, 0,
> >> + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> >> +.vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> >> +  /* 69 - 1280x720@60Hz */
> >> +  { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1390,
> >> + 1430, 1650, 0, 720, 725, 730, 750, 0,
> >> + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> >> +.vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> >> +  /* 70 - 1280x720@100Hz */
> >> +  { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1720,
> >> + 1760, 1980, 0, 720, 725, 730, 750, 0,
> >> + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> >> +.vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> >> +  /* 71 - 1280x720@120Hz */
> >> +  { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1390,
> >> + 1430, 1650, 0, 720, 725, 730, 750, 0,
> >> + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> 

[Bug 101387] amdgpu display corruption and hang on AMD A10-9620P

[bugzilla-daemon]

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

--- Comment #9 from Alex Deucher  ---
Can you please attach a copy of your vbios?  

(as root)
(use lspci to get the bus id)
cd /sys/bus/pci/devices/
echo 1 > rom
cat rom > /tmp/vbios.rom
echo 0 > rom

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

Re: [PATCH v3 04/14] drm/edid: parse YCBCR 420 videomodes from EDID

[Ville Syrjälä]

On Wed, Jun 14, 2017 at 11:17:35PM +0530, Shashank Sharma wrote:
> HDMI 2.0 spec adds support for YCBCR420 sub-sampled output.
> CEA-861-F adds two new blocks in EDID's CEA extension blocks,
> to provide information about sink's YCBCR420 output capabilities.
> 
> These blocks are:
> 
> - YCBCR420vdb(YCBCR 420 video data block):
> This block contains VICs of video modes, which can be sopported only
> in YCBCR420 output mode (Not in RGB/YCBCR444/422. Its like a normal
> SVD block, valid for YCBCR420 modes only.
> 
> - YCBCR420cmdb(YCBCR 420 capability map data block):
> This block gives information about video modes which can support
> YCBCR420 output mode also (along with RGB,YCBCR444/422 etc) This
> block contains a bitmap index of normal svd videomodes, which can
> support YCBCR420 output too.
> So if bit 0 from first vcb byte is set, first video mode in the svd
> list can support YCBCR420 output too. Bit 1 means second video mode
> from svd list can support YCBCR420 output too, and so on.
> 
> This patch adds two bitmaps in display's hdmi_info structure, one each
> for VCB and VDB modes. If the source is HDMI 2.0 capable, this patch
> adds:
> - VDB modes (YCBCR 420 only modes) in connector's mode list, also makes
>   an entry in the vdb_bitmap per vic.
> - VCB modes (YCBCR 420 also modes) only entry in the vcb_bitmap.
> 
> Cc: Ville Syrjala 
> Cc: Jose Abreu 
> Cc: Emil Velikov 
> 
> V2: Addressed
> Review comments from Emil:
> - Use 1ULL< - Use the suggested method for updating dbmap.
> - Add documentation for YCBCR420_vcb_map to fix kbuild warning.
> 
> Review comments from Ville:
> - Do not expose the YCBCR420 flags in uabi layer, keep it internal.
> - Save a map of YCBCR420 modes for future reference.
> - Check db length before trying to parse extended tag.
> - Add a warning if there are > 64 modes in capability map block.
> - Use y420cmdb in function names and macros while dealing with vcb
>   to be aligned with spec.
> - Move the display information parsing block ahead of mode parsing
>   blocks.
> 
> V3: Addressed design/review comments from Ville
> - Do not add flags in video modes, else we have to expose them to user
> - There should not be a UABI change, and kernel should detect the
>   choice of the output based on type of mode, and the bitmaps.
> - Use standard bitops from kernel bitmap header, instead of calculating
>   bit positions manually.
> 
> Signed-off-by: Shashank Sharma 
> ---
>  drivers/gpu/drm/drm_edid.c  | 193 
> ++--
>  include/drm/drm_connector.h |  23 ++
>  2 files changed, 211 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 6fd8a98..4953f87 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2781,7 +2781,9 @@ add_detailed_modes(struct drm_connector *connector, 
> struct edid *edid,
>  #define VIDEO_BLOCK 0x02
>  #define VENDOR_BLOCK0x03
>  #define SPEAKER_BLOCK0x04
> -#define VIDEO_CAPABILITY_BLOCK   0x07
> +#define VIDEO_CAPABILITY_BLOCK 0x07
> +#define VIDEO_DATA_BLOCK_420 0x0E
> +#define VIDEO_CAP_BLOCK_Y420CMDB 0x0F
>  #define EDID_BASIC_AUDIO (1 << 6)
>  #define EDID_CEA_YCRCB444(1 << 5)
>  #define EDID_CEA_YCRCB422(1 << 4)
> @@ -3143,15 +3145,103 @@ drm_display_mode_from_vic_index(struct drm_connector 
> *connector,
>   return newmode;
>  }
>  
> +/*
> + * do_ycbcr_420_vdb_modes - Parse YCBCR 420 only modes
> + * @connector: connector corresponding to the HDMI sink
> + * @svds: start of the data block of CEA YCBCR 420 VDB
> + * @len: length of the CEA YCBCR 420 VDB
> + *
> + * CEA-861-F has added a new video block called YCBCR 420 Video
> + * Data Block (ycbcr 420 vdb). This block contains modes which
> + * support YCBCR 420 HDMI output (only YCBCR 420). This function
> + * parses the block and adds these modes into connector's mode list.

Seems a bit verbose. Maybe something like:
"Parse the CEA-861-F YCbCr 4:2:0 Video Data Block (Y420VDB)
which contains modes which only support YCbCr 4:2:0 output."

> + */
> +static int do_ycbcr_420_vdb_modes(struct drm_connector *connector,
> +const u8 *svds, u8 svds_len)

Probably we could s/ycbcr_420_vdb/y420vdb/ all over to keep things
shorter and match the terminology in the spec. Same for y420cmdb.

> +{
> + int modes = 0, i;
> + struct drm_device *dev = connector->dev;
> + struct drm_display_mode *newmode;

This variable can be moved into the loop scope.

> + struct drm_display_info *info = >display_info;
> + struct drm_hdmi_info *hdmi = >hdmi;
> +
> + for (i = 0; i < svds_len; i++) {
> + u8 vic = svds[i] & 0x7f;

What's the 0x7f here? Native bit stuff? I'm thinkign we probably want
some kind of svd_to_vic() 

Re: [PATCH] drm: Reduce scope of 'state' variable

[Dawid Kurek]

On 15/06/17, Jani Nikula wrote:
> On Thu, 15 Jun 2017, Dawid Kurek  wrote:
> > Smaller scope reduces visibility of variable and makes usage of
> > uninitialized variable less possible.
> > ---
> >  drivers/gpu/drm/drm_atomic.c | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index f32506a..ea5a9a7 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -108,10 +108,11 @@ struct drm_atomic_state *
> >  drm_atomic_state_alloc(struct drm_device *dev)
> >  {
> > struct drm_mode_config *config = >mode_config;
> > -   struct drm_atomic_state *state;
> >  
> > if (!config->funcs->atomic_state_alloc) {
> > -   state = kzalloc(sizeof(*state), GFP_KERNEL);
> > +   struct drm_atomic_state *state
> > +   = kzalloc(sizeof(*state), GFP_KERNEL);
> 
> Separate declaration and initialization would lead to a cleaner patch
> and result.

I saw combining declaration and initialization is quite common, i.e. in
drm_atomic file. Personally, I also prefer those in one statement. But yes, it
looks cleaner here, in two lines.

v2 sent :)

Thanks,
Dawid

> 
> BR,
> Jani.
> 
> > +
> > if (!state)
> > return NULL;
> > if (drm_atomic_state_init(dev, state) < 0) {
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

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

[Bug 93826] 2560x1440 @144Hz graphic glitches and bad refresh rate

[bugzilla-daemon]

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

--- Comment #59 from i...@posteo.net ---
(In reply to Eike from comment #56)

> Sorry to correct you, but my monitor has not been faultier than any other
> MG279Q that was bought before 2017.

Mine is bought before 2017 and it ain't broken.

> BTW I have tried the mclock increase before RMAing my monitor and it did not
> work at all.

Because raising the mclk only helps for the other problem with too low voltage
resulting in flickering, not the broken image.

> Please differentiate between the artifacts I described (left half of the
> screen is offset to the right, a vertical stripe that should be in the
> middle is displayed at the left side of the screen) and other artifacts
> which could in fact be caused by a low mclock or other problems.

I do differentiate but I have to admit that I didn't read the ROG thread and
realise others had this problem on Windows. Also, I didn't say your monitor or
others might not be broken, I just said that there certainly is a software
problem.

I've had the exact same artefacts you had but never(!) on Windows, neither on
Windows nor Linux using Intel GPU. So it's easy enough to reduce it to the free
drivers. I asked for help and agd5f suggested to raise the display clock
(inside the GPU). It solves the problem entirely for me and others (as seen
above).

Don't get me wrong, I don't question your experiences and I believe you had the
same problem on Windows and a new Monitor fixed it for you. But I don't think
suggesting people to send back their hardware when there is a software problem
to be fixed is the right way to handle this.

> The described artifacts might be fixable by software (e.g. Windows with
> certain driver combinations does show these artifacts, but does not with
> others), but ARE CAUSED by the faulty MG279Q firmware.

I have to disagree when doing nothing(!) but raising the clock of the display
engine inside the GPU resolves the problem. The clock is too low on default
which results in wrong timings, that's all.

Also, yours is running at 139 Hz, which is not a supported mode at all nor is
it meant to do that, so you might be bothered about it but you still have a
problem. It should run at 144 and mine does on Windows, it does with Intel, it
does with the dispclk fix.

> I have not found any combination of OS and drivers that caused these
> problems on the fixed monitor, but found several on multiple "not fixed"
> MG279Qs in the past.

Now what I find interesting and what we should focus on imho is the question
why a new firmware resolves the issue (partly). Maybe they changed the
modes/timings resulting in different GPU behaviour.

Could you provide your EDID as I'm really wondering?

--

@withoutaface: You have to rebuild your kernel. It is not hard to do but if
you're not familiar with that, tell us which distribution you are using and
someone might help you.

-- 
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/hdmi: Use bitwise operators when building register values

[Liviu Dudau]

Commit c0c0d9eeeb8d ("drm/msm: hdmi audio support") uses logical
OR operators to build up a value to be written in the
REG_HDMI_AUDIO_INFO0 and REG_HDMI_AUDIO_INFO1 registers when it
should have used bitwise operators.

Signed-off-by: Liviu Dudau 
Fixes: c0c0d9eeeb8d ("drm/msm: hdmi audio support")
---
 drivers/gpu/drm/msm/hdmi/hdmi_audio.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_audio.c 
b/drivers/gpu/drm/msm/hdmi/hdmi_audio.c
index 8177e8511afd..9c34b91ae329 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_audio.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_audio.c
@@ -175,10 +175,10 @@ int msm_hdmi_audio_update(struct hdmi *hdmi)
/* configure infoframe: */
hdmi_audio_infoframe_pack(info, buf, sizeof(buf));
hdmi_write(hdmi, REG_HDMI_AUDIO_INFO0,
-   (buf[3] <<  0) || (buf[4] <<  8) ||
-   (buf[5] << 16) || (buf[6] << 24));
+   (buf[3] <<  0) | (buf[4] <<  8) |
+   (buf[5] << 16) | (buf[6] << 24));
hdmi_write(hdmi, REG_HDMI_AUDIO_INFO1,
-   (buf[7] <<  0) || (buf[8] << 8));
+   (buf[7] <<  0) | (buf[8] << 8));
 
hdmi_write(hdmi, REG_HDMI_GC, 0);
 
-- 
2.13.1

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

[Bug 194761] amdgpu driver breaks on Oland (SI)

[bugzilla-daemon]

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

--- Comment #66 from siyia (eutychio...@gmail.com) ---
Regression persists with kernel 4.11.5, but
https://bugzilla.kernel.org/attachment.cgi?id=256949 thankfully works and fixes
the issue.

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

[PATCH v2] drm: Reduce scope of 'state' variable

[Dawid Kurek]

Smaller scope reduces visibility of variable and makes usage of
uninitialized variable less possible.

Changes in v2:
- separate declaration and initialization
---
 drivers/gpu/drm/drm_atomic.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index f32506a..5e0d1e1 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -108,9 +108,10 @@ struct drm_atomic_state *
 drm_atomic_state_alloc(struct drm_device *dev)
 {
struct drm_mode_config *config = >mode_config;
-   struct drm_atomic_state *state;
 
if (!config->funcs->atomic_state_alloc) {
+   struct drm_atomic_state *state;
+
state = kzalloc(sizeof(*state), GFP_KERNEL);
if (!state)
return NULL;
-- 
2.10.0


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

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

Re: [PATCH v3 00/20] Tegra DRM fixes

[Thierry Reding]

On Thu, Jun 15, 2017 at 02:18:23AM +0300, Dmitry Osipenko wrote:
> I've dropped the two "GART restoring" patches from the series, postponing
> them till a full solution of GART utilization would be ready.
> 
> The "Forbid relocation address shifting in the firewall" patch has been
> reverted to v1, Mikko and me agreed on that it is a reasonable variant.
> 
> All the patches got a r-b, series should be good to go.
> 
> Dmitry Osipenko (19):
>   drm/tegra: Fix lockup on a use of staging API
>   drm/tegra: Correct idr_alloc() minimum id
>   drm/tegra: Check for malformed offsets and sizes in the 'submit' IOCTL
>   drm/tegra: Correct copying of waitchecks and disable them in the
> 'submit' IOCTL
>   drm/tegra: Check syncpoint ID in the 'submit' IOCTL
>   drm/tegra: dc: Avoid reset asserts on Tegra20
>   drm/tegra: dc: Apply clipping to the plane
>   drm/tegra: dc: Disable plane if it is invisible
>   gpu: host1x: Initialize firewall class to the jobs one
>   gpu: host1x: Correct host1x_job_pin() error handling
>   gpu: host1x: Do not leak BO's phys address to userspace
>   gpu: host1x: Forbid relocation address shifting in the firewall
>   gpu: host1x: Forbid RESTART opcode in the firewall
>   gpu: host1x: Forbid unrelated SETCLASS opcode in the firewall
>   gpu: host1x: Correct swapped arguments in the is_addr_reg() definition
>   gpu: host1x: Check waits in the firewall
>   gpu: host1x: Remove unused 'struct host1x_cmdbuf'
>   gpu: host1x: Remove unused host1x_cdma_stop() definition
>   gpu: host1x: At first try a non-blocking allocation for the gather
> copy
> 
> Mikko Perttunen (1):
>   gpu: host1x: Refactor channel allocation code
> 
>  drivers/gpu/drm/tegra/dc.c |  92 +++
>  drivers/gpu/drm/tegra/drm.c| 141 +--
>  drivers/gpu/drm/tegra/drm.h|   1 +
>  drivers/gpu/drm/tegra/gem.c|   5 --
>  drivers/gpu/drm/tegra/gem.h|   5 ++
>  drivers/gpu/drm/tegra/gr2d.c   |  11 ++-
>  drivers/gpu/drm/tegra/gr3d.c   |   4 +-
>  drivers/gpu/drm/tegra/vic.c|   4 +-
>  drivers/gpu/host1x/cdma.h  |   1 -
>  drivers/gpu/host1x/channel.c   | 147 
> +++--
>  drivers/gpu/host1x/channel.h   |  21 --
>  drivers/gpu/host1x/debug.c |  47 +---
>  drivers/gpu/host1x/dev.c   |   7 +-
>  drivers/gpu/host1x/dev.h   |   6 +-
>  drivers/gpu/host1x/hw/channel_hw.c |   4 -
>  drivers/gpu/host1x/job.c   | 124 ---
>  drivers/gpu/host1x/job.h   |  14 
>  include/linux/host1x.h |  13 +++-
>  18 files changed, 440 insertions(+), 207 deletions(-)

Applied patches 3/20 through 20/20 to drm/tegra/for-next, thanks.

Thierry


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

Re: [PATCH v3 02/14] drm/edid: Complete CEA modedb(VIC 1-107)

[Sharma, Shashank]

Regards

Shashank


On 6/15/2017 6:59 PM, Ville Syrjälä wrote:

On Wed, Jun 14, 2017 at 11:17:33PM +0530, Shashank Sharma wrote:

CEA-861-F specs defines new video modes to be used with
HDMI 2.0 EDIDs. The VIC range has been extended from 1-64 to
1-107.

Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
to be able to parse new CEA modes using the existing methods, we have
to complete the modedb (VIC=65 onwards).

This patch adds:
- Timings for existing CEA video modes (from VIC=65 till VIC=92)
- Newly added 4k modes (from VIC=93 to VIC=107).

The patch was originaly discussed and reviewed here:
https://patchwork.freedesktop.org/patch/135810/

Cc: Ville Syrjala 
Cc: Jose Abreu 
Cc: Andrzej Hajda 
Cc: Alex Deucher 
Cc: Harry Wentland 

V2: Rebase
V3: Rebase

So what happend to the 'native' bit stuff again?

Tried really hard finding that code, couldn't :(.
Might need bit help here.

- Shashank

Reviewed-by: Jose Abreu 
Reviewed-by: Alex Deucher 
Acked-by: Harry Wentland 
Signed-off-by: Shashank Sharma 
---
  drivers/gpu/drm/drm_edid.c | 215 +
  1 file changed, 215 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index d312fe1..6fd8a98 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1006,6 +1006,221 @@ static const struct drm_display_mode edid_cea_modes[] = 
{
   2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
 .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
+   /* 65 - 1280x720@24Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59400, 1280, 3040,
+  3080, 3300, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 66 - 1280x720@25Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3700,
+  3740, 3960, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 67 - 1280x720@30Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3040,
+  3080, 3300, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 68 - 1280x720@50Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1720,
+  1760, 1980, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 69 - 1280x720@60Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1390,
+  1430, 1650, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 70 - 1280x720@100Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1720,
+  1760, 1980, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 71 - 1280x720@120Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1390,
+  1430, 1650, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 120, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 72 - 1920x1080@24Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2558,
+  2602, 2750, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 73 - 1920x1080@25Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2448,
+  2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 74 - 1920x1080@30Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2008,
+  2052, 2200, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 75 - 1920x1080@50Hz */
+   { 

Re: [PATCH v3 02/14] drm/edid: Complete CEA modedb(VIC 1-107)

[Ville Syrjälä]

On Wed, Jun 14, 2017 at 11:17:33PM +0530, Shashank Sharma wrote:
> CEA-861-F specs defines new video modes to be used with
> HDMI 2.0 EDIDs. The VIC range has been extended from 1-64 to
> 1-107.
> 
> Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
> to be able to parse new CEA modes using the existing methods, we have
> to complete the modedb (VIC=65 onwards).
> 
> This patch adds:
> - Timings for existing CEA video modes (from VIC=65 till VIC=92)
> - Newly added 4k modes (from VIC=93 to VIC=107).
> 
> The patch was originaly discussed and reviewed here:
> https://patchwork.freedesktop.org/patch/135810/
> 
> Cc: Ville Syrjala 
> Cc: Jose Abreu 
> Cc: Andrzej Hajda 
> Cc: Alex Deucher 
> Cc: Harry Wentland 
> 
> V2: Rebase
> V3: Rebase

So what happend to the 'native' bit stuff again?

> 
> Reviewed-by: Jose Abreu 
> Reviewed-by: Alex Deucher 
> Acked-by: Harry Wentland 
> Signed-off-by: Shashank Sharma 
> ---
>  drivers/gpu/drm/drm_edid.c | 215 
> +
>  1 file changed, 215 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index d312fe1..6fd8a98 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1006,6 +1006,221 @@ static const struct drm_display_mode edid_cea_modes[] 
> = {
>  2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
>  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
>.vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> + /* 65 - 1280x720@24Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59400, 1280, 3040,
> +3080, 3300, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 66 - 1280x720@25Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3700,
> +3740, 3960, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 67 - 1280x720@30Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3040,
> +3080, 3300, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 68 - 1280x720@50Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1720,
> +1760, 1980, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 69 - 1280x720@60Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1390,
> +1430, 1650, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 70 - 1280x720@100Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1720,
> +1760, 1980, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 71 - 1280x720@120Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1390,
> +1430, 1650, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 120, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 72 - 1920x1080@24Hz */
> + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2558,
> +2602, 2750, 0, 1080, 1084, 1089, 1125, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 73 - 1920x1080@25Hz */
> + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2448,
> +2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 74 - 1920x1080@30Hz */
> + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2008,
> +2052, 2200, 0, 1080, 1084, 1089, 1125, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 75 - 1920x1080@50Hz */
> + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 148500, 1920, 2448,
> +2492, 2640, 

[PATCH] fixup! drm/msm: Separate locking of buffer resources from struct_mutex

[Rob Clark]

---
This is roughly based on Chris's suggestion, in particular the part
about using mutex_lock_nested().  It's not *exactly* the same, in
particular msm_obj->lock protects a bit more than just backing store
and we don't currently track a pin_count.  (Instead we currently
keep pages pinned until the object is purged or freed.)

Instead of making msm_obj->lock only cover backing store, it is
easier to split out madv, which is still protected by struct_mutex,
which is still held by the shrinker, so the shrinker does not need
to grab msm_obj->lock until it purges an object.  We avoid going
down any path that could trigger shrinker by ensuring that
msm_obj->madv == WILLNEED.  To synchronize access to msm_obj->madv
it is protected by msm_obj->lock inside struct_mutex.

This seems to keep lockdep happy in my testing so far.

 drivers/gpu/drm/msm/msm_gem.c  | 54 --
 drivers/gpu/drm/msm/msm_gem.h  |  1 +
 drivers/gpu/drm/msm/msm_gem_shrinker.c | 12 
 3 files changed, 65 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index e132548..f5d1f84 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -26,6 +26,22 @@
 #include "msm_gpu.h"
 #include "msm_mmu.h"
 
+/* The shrinker can be triggered while we hold objA->lock, and need
+ * to grab objB->lock to purge it.  Lockdep just sees these as a single
+ * class of lock, so we use subclasses to teach it the difference.
+ *
+ * OBJ_LOCK_NORMAL is implicit (ie. normal mutex_lock() call), and
+ * OBJ_LOCK_SHRINKER is used in msm_gem_purge().
+ *
+ * It is *essential* that we never go down paths that could trigger the
+ * shrinker for a purgable object.  This is ensured by checking that
+ * msm_obj->madv == MSM_MADV_WILLNEED.
+ */
+enum {
+   OBJ_LOCK_NORMAL,
+   OBJ_LOCK_SHRINKER,
+};
+
 static dma_addr_t physaddr(struct drm_gem_object *obj)
 {
struct msm_gem_object *msm_obj = to_msm_bo(obj);
@@ -150,6 +166,12 @@ struct page **msm_gem_get_pages(struct drm_gem_object *obj)
struct page **p;
 
mutex_lock(_obj->lock);
+
+   if (WARN_ON(msm_obj->madv != MSM_MADV_WILLNEED)) {
+   mutex_unlock(_obj->lock);
+   return ERR_PTR(-EBUSY);
+   }
+
p = get_pages(obj);
mutex_unlock(_obj->lock);
return p;
@@ -220,6 +242,11 @@ int msm_gem_fault(struct vm_fault *vmf)
if (ret)
goto out;
 
+   if (WARN_ON(msm_obj->madv != MSM_MADV_WILLNEED)) {
+   mutex_unlock(_obj->lock);
+   return VM_FAULT_SIGBUS;
+   }
+
/* make sure we have pages attached now */
pages = get_pages(obj);
if (IS_ERR(pages)) {
@@ -358,6 +385,11 @@ int msm_gem_get_iova(struct drm_gem_object *obj,
 
mutex_lock(_obj->lock);
 
+   if (WARN_ON(msm_obj->madv != MSM_MADV_WILLNEED)) {
+   mutex_unlock(_obj->lock);
+   return -EBUSY;
+   }
+
vma = lookup_vma(obj, aspace);
 
if (!vma) {
@@ -454,6 +486,12 @@ void *msm_gem_get_vaddr(struct drm_gem_object *obj)
struct msm_gem_object *msm_obj = to_msm_bo(obj);
 
mutex_lock(_obj->lock);
+
+   if (WARN_ON(msm_obj->madv != MSM_MADV_WILLNEED)) {
+   mutex_unlock(_obj->lock);
+   return ERR_PTR(-EBUSY);
+   }
+
if (!msm_obj->vaddr) {
struct page **pages = get_pages(obj);
if (IS_ERR(pages)) {
@@ -489,12 +527,18 @@ int msm_gem_madvise(struct drm_gem_object *obj, unsigned 
madv)
 {
struct msm_gem_object *msm_obj = to_msm_bo(obj);
 
+   mutex_lock(_obj->lock);
+
WARN_ON(!mutex_is_locked(>dev->struct_mutex));
 
if (msm_obj->madv != __MSM_MADV_PURGED)
msm_obj->madv = madv;
 
-   return (msm_obj->madv != __MSM_MADV_PURGED);
+   madv = msm_obj->madv;
+
+   mutex_unlock(_obj->lock);
+
+   return (madv != __MSM_MADV_PURGED);
 }
 
 void msm_gem_purge(struct drm_gem_object *obj)
@@ -506,6 +550,8 @@ void msm_gem_purge(struct drm_gem_object *obj)
WARN_ON(!is_purgeable(msm_obj));
WARN_ON(obj->import_attach);
 
+   mutex_lock_nested(_obj->lock, OBJ_LOCK_SHRINKER);
+
put_iova(obj);
 
msm_gem_vunmap(obj);
@@ -526,6 +572,8 @@ void msm_gem_purge(struct drm_gem_object *obj)
 
invalidate_mapping_pages(file_inode(obj->filp)->i_mapping,
0, (loff_t)-1);
+
+   mutex_unlock(_obj->lock);
 }
 
 void msm_gem_vunmap(struct drm_gem_object *obj)
@@ -660,7 +708,7 @@ void msm_gem_describe(struct drm_gem_object *obj, struct 
seq_file *m)
uint64_t off = drm_vma_node_start(>vma_node);
const char *madv;
 
-   WARN_ON(!mutex_is_locked(>dev->struct_mutex));
+   mutex_lock(_obj->lock);
 
switch (msm_obj->madv) {
case __MSM_MADV_PURGED:
@@ -701,6 +749,8 @@ void msm_gem_describe(struct drm_gem_object *obj, struct 
seq_file *m)

Re: [Intel-gfx] [PATCH][drm-next] drm/i915/cnl: make function cnl_ddi_dp_set_dpll_hw_state static

[Ville Syrjälä]

On Wed, Jun 14, 2017 at 02:03:05PM +0100, Tvrtko Ursulin wrote:
> 
> On 13/06/2017 14:47, Colin King wrote:
> > From: Colin Ian King 
> > 
> > The function cnl_ddi_dp_set_dpll_hw_state does not need to be in global
> > scope, so make it static.
> > 
> > Cleans up sparse warning:
> > "symbol 'cnl_ddi_dp_set_dpll_hw_state' was not declared. Should it
> >   be static?"
> > 
> > Signed-off-by: Colin Ian King 
> > ---
> >   drivers/gpu/drm/i915/intel_dpll_mgr.c | 5 +++--
> >   1 file changed, 3 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
> > b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > index 8e669b6254ae..2f7b0e64f628 100644
> > --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > @@ -2292,8 +2292,9 @@ static bool cnl_ddi_hdmi_pll_dividers(struct 
> > intel_crtc *crtc,
> > return true;
> >   }
> >   
> > -bool cnl_ddi_dp_set_dpll_hw_state(int clock,
> > - struct intel_dpll_hw_state *dpll_hw_state)
> > +static bool
> > +cnl_ddi_dp_set_dpll_hw_state(int clock,
> > +struct intel_dpll_hw_state *dpll_hw_state)
> >   {
> > uint32_t cfgcr0;
> >   
> > 
> 
> Reviewed-by: Tvrtko Ursulin 

Thanks for the patch and review. Pushed to dinq.

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

Re: [PATCH 33/37] drm/tegra: Drop drm_vblank_cleanup

[Thierry Reding]

On Wed, May 24, 2017 at 04:52:08PM +0200, Daniel Vetter wrote:
> Again, doesn't seem to serve a purpose.
> 
> Cc: Thierry Reding 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/tegra/drm.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)

I'm assuming that you want to apply the whole batch at once? From what I
can tell the driver patches should be fine to apply independently, but
it's probably a good idea to keep all of these together for coherence.

Thierry


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