Re: [PATCH] drm/xen-front: use simple display pipe prepare_fb helper

[Oleksandr Andrushchenko]

On 04/09/2018 11:51 AM, Daniel Vetter wrote:

I missed this one because on an older tree.

Signed-off-by: Daniel Vetter 
Cc: Oleksandr Andrushchenko 
Cc: xen-de...@lists.xen.org
---
  drivers/gpu/drm/xen/xen_drm_front_kms.c | 8 +---
  1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/xen/xen_drm_front_kms.c 
b/drivers/gpu/drm/xen/xen_drm_front_kms.c
index 0bd6681fa4f3..a3479eb72d79 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_kms.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_kms.c
@@ -226,12 +226,6 @@ static bool display_send_page_flip(struct 
drm_simple_display_pipe *pipe,
return false;
  }
  
-static int display_prepare_fb(struct drm_simple_display_pipe *pipe,

- struct drm_plane_state *plane_state)
-{
-   return drm_gem_fb_prepare_fb(>plane, plane_state);
-}
-
  static void display_update(struct drm_simple_display_pipe *pipe,
   struct drm_plane_state *old_plane_state)
  {
@@ -294,7 +288,7 @@ static const struct drm_simple_display_pipe_funcs 
display_funcs = {
.mode_valid = display_mode_valid,
.enable = display_enable,
.disable = display_disable,
-   .prepare_fb = display_prepare_fb,
+   .prepare_fb = drm_gem_fb_simple_display_pipe_prepare_fb,
.update = display_update,
  };
  

Thank you,
Reviewed-by: Oleksandr Andrushchenko 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/9] drm: Move simple_display_pipe prepare_fb helper into gem fb helpers

[Oleksandr Andrushchenko]

On 04/05/2018 06:44 PM, Daniel Vetter wrote:

There's nothing tinydrm specific to this, and there's a few more
copies of the same in various other drivers.

Signed-off-by: Daniel Vetter 
Cc: Gustavo Padovan 
Cc: Maarten Lankhorst 
Cc: Sean Paul 
Cc: David Airlie 
Cc: David Lechner 
Cc: "Noralf Trønnes" 
Cc: Daniel Vetter 
Cc: Shawn Guo 
Cc: Neil Armstrong 
Cc: Daniel Stone 
Cc: Haneen Mohammed 
Cc: Ben Widawsky 
Cc: "Ville Syrjälä" 
---
  drivers/gpu/drm/drm_gem_framebuffer_helper.c | 19 +++
  drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c  | 17 -
  drivers/gpu/drm/tinydrm/ili9225.c|  2 +-
  drivers/gpu/drm/tinydrm/mi0283qt.c   |  3 ++-
  drivers/gpu/drm/tinydrm/repaper.c|  2 +-
  drivers/gpu/drm/tinydrm/st7586.c |  2 +-
  drivers/gpu/drm/tinydrm/st7735r.c|  2 +-
  include/drm/drm_gem_framebuffer_helper.h |  3 +++
  include/drm/drm_simple_kms_helper.h  |  3 +++
  include/drm/tinydrm/tinydrm.h|  2 --
  10 files changed, 31 insertions(+), 24 deletions(-)

Reviewed-by: Oleksandr Andrushchenko 

diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c 
b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
index 4d682a6e8bcb..acfbc0641a06 100644
--- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
+++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
@@ -22,6 +22,7 @@
  #include 
  #include 
  #include 
+#include 
  
  /**

   * DOC: overview
@@ -265,6 +266,24 @@ int drm_gem_fb_prepare_fb(struct drm_plane *plane,
  }
  EXPORT_SYMBOL_GPL(drm_gem_fb_prepare_fb);
  
+/**

+ * drm_gem_fb_simple_display_pipe_prepare_fb - prepare_fb helper for
+ * _simple_display_pipe
+ * @pipe: Simple display pipe
+ * @plane_state: Plane state
+ *
+ * This function uses drm_gem_fb_prepare_fb() to check if the plane FB has a
+ * _buf attached, extracts the exclusive fence and attaches it to plane
+ * state for the atomic helper to wait on. Drivers can use this as their
+ * _simple_display_pipe_funcs.prepare_fb callback.
+ */
+int drm_gem_fb_simple_display_pipe_prepare_fb(struct drm_simple_display_pipe 
*pipe,
+ struct drm_plane_state 
*plane_state)
+{
+   return drm_gem_fb_prepare_fb(>plane, plane_state);
+}
+EXPORT_SYMBOL(drm_gem_fb_simple_display_pipe_prepare_fb);
+
  /**
   * drm_gem_fbdev_fb_create - Create a GEM backed _framebuffer for fbdev
   *   emulation
diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c 
b/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
index e68b528ae64d..7e8e24d0b7a7 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
@@ -138,23 +138,6 @@ void tinydrm_display_pipe_update(struct 
drm_simple_display_pipe *pipe,
  }
  EXPORT_SYMBOL(tinydrm_display_pipe_update);
  
-/**

- * tinydrm_display_pipe_prepare_fb - Display pipe prepare_fb helper
- * @pipe: Simple display pipe
- * @plane_state: Plane state
- *
- * This function uses drm_gem_fb_prepare_fb() to check if the plane FB has an
- * dma-buf attached, extracts the exclusive fence and attaches it to plane
- * state for the atomic helper to wait on. Drivers can use this as their
- * _simple_display_pipe_funcs->prepare_fb callback.
- */
-int tinydrm_display_pipe_prepare_fb(struct drm_simple_display_pipe *pipe,
-   struct drm_plane_state *plane_state)
-{
-   return drm_gem_fb_prepare_fb(>plane, plane_state);
-}
-EXPORT_SYMBOL(tinydrm_display_pipe_prepare_fb);
-
  static int tinydrm_rotate_mode(struct drm_display_mode *mode,
   unsigned int rotation)
  {
diff --git a/drivers/gpu/drm/tinydrm/ili9225.c 
b/drivers/gpu/drm/tinydrm/ili9225.c
index 0874e877b111..841c69aba059 100644
--- a/drivers/gpu/drm/tinydrm/ili9225.c
+++ b/drivers/gpu/drm/tinydrm/ili9225.c
@@ -354,7 +354,7 @@ static const struct drm_simple_display_pipe_funcs 
ili9225_pipe_funcs = {
.enable = ili9225_pipe_enable,
.disable= ili9225_pipe_disable,
.update = tinydrm_display_pipe_update,
-   .prepare_fb = tinydrm_display_pipe_prepare_fb,
+   .prepare_fb = drm_gem_fb_simple_display_pipe_prepare_fb,
  };
  
  static const struct drm_display_mode ili9225_mode = {

diff --git a/drivers/gpu/drm/tinydrm/mi0283qt.c 
b/drivers/gpu/drm/tinydrm/mi0283qt.c
index 4e6d2ee94e55..d5ef65179c16 100644
--- a/drivers/gpu/drm/tinydrm/mi0283qt.c
+++ b/drivers/gpu/drm/tinydrm/mi0283qt.c
@@ -19,6 +19,7 @@
  
  #include 

  #include 
+#include 
  #include 
  #include 
  #include 
@@ -134,7 +135,7 @@ static const 

[PATCH] drm: xlnx: pl_disp: fix odd_ptr_err.cocci warnings

[Julia Lawall]

From: Fengguang Wu 

 PTR_ERR should normally access the value just tested by IS_ERR

Generated by: scripts/coccinelle/tests/odd_ptr_err.cocci

Fixes: 742243a44a73 ("drm: xlnx: pl_disp: Use xlnx pipeline calls")
CC: Hyun Kwon 
Signed-off-by: Fengguang Wu 
Signed-off-by: Julia Lawall 
---

tree:   https://github.com/Xilinx/linux-xlnx xlnx_rebase_v4.14
head:   fe04d2ee0dfea6b5fdbb04f4f6dbcaa13bfd2fda
commit: 742243a44a738b165f8da5cbdb6662139e85a5c5 [651/842] drm: xlnx:
pl_disp: Use xlnx pipeline calls


 xlnx_pl_disp.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/xlnx/xlnx_pl_disp.c
+++ b/drivers/gpu/drm/xlnx/xlnx_pl_disp.c
@@ -482,7 +482,7 @@ static int xlnx_pl_disp_probe(struct pla

xlnx_pl_disp->master = xlnx_drm_pipeline_init(pdev);
if (IS_ERR(xlnx_pl_disp->master)) {
-   ret = PTR_ERR(xlnx_pl_disp->dev);
+   ret = PTR_ERR(xlnx_pl_disp->master);
dev_err(dev, "failed to initialize the drm pipeline\n");
goto err_component;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] drm/bridge: sii902x: add optional power supplies

[Philippe Cornu]

Add the 3 optional power supplies using the exact description
found in the document named
"SiI9022A/SiI9024A HDMI Transmitter Data Sheet (August 2016)".

Signed-off-by: Philippe Cornu 
---
 drivers/gpu/drm/bridge/sii902x.c | 39 +++
 1 file changed, 35 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/bridge/sii902x.c b/drivers/gpu/drm/bridge/sii902x.c
index 60373d7eb220..e17ba6db1ec8 100644
--- a/drivers/gpu/drm/bridge/sii902x.c
+++ b/drivers/gpu/drm/bridge/sii902x.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -86,6 +87,7 @@ struct sii902x {
struct drm_bridge bridge;
struct drm_connector connector;
struct gpio_desc *reset_gpio;
+   struct regulator_bulk_data supplies[3];
 };
 
 static inline struct sii902x *bridge_to_sii902x(struct drm_bridge *bridge)
@@ -392,23 +394,43 @@ static int sii902x_probe(struct i2c_client *client,
return PTR_ERR(sii902x->reset_gpio);
}
 
+   sii902x->supplies[0].supply = "iovcc";
+   sii902x->supplies[1].supply = "avcc12";
+   sii902x->supplies[2].supply = "cvcc12";
+   ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(sii902x->supplies),
+ sii902x->supplies);
+   if (ret) {
+   dev_err(dev, "regulator_bulk_get failed\n");
+   return ret;
+   }
+
+   ret = regulator_bulk_enable(ARRAY_SIZE(sii902x->supplies),
+   sii902x->supplies);
+   if (ret) {
+   dev_err(dev, "regulator_bulk_enable failed\n");
+   return ret;
+   }
+
+   usleep_range(1, 2);
+
sii902x_reset(sii902x);
 
ret = regmap_write(sii902x->regmap, SII902X_REG_TPI_RQB, 0x0);
if (ret)
-   return ret;
+   goto err_disable_regulator;
 
ret = regmap_bulk_read(sii902x->regmap, SII902X_REG_CHIPID(0),
   , 4);
if (ret) {
dev_err(dev, "regmap_read failed %d\n", ret);
-   return ret;
+   goto err_disable_regulator;
}
 
if (chipid[0] != 0xb0) {
dev_err(dev, "Invalid chipid: %02x (expecting 0xb0)\n",
chipid[0]);
-   return -EINVAL;
+   ret = -EINVAL;
+   goto err_disable_regulator;
}
 
/* Clear all pending interrupts */
@@ -424,7 +446,7 @@ static int sii902x_probe(struct i2c_client *client,
IRQF_ONESHOT, dev_name(dev),
sii902x);
if (ret)
-   return ret;
+   goto err_disable_regulator;
}
 
sii902x->bridge.funcs = _bridge_funcs;
@@ -434,6 +456,12 @@ static int sii902x_probe(struct i2c_client *client,
i2c_set_clientdata(client, sii902x);
 
return 0;
+
+err_disable_regulator:
+   regulator_bulk_disable(ARRAY_SIZE(sii902x->supplies),
+  sii902x->supplies);
+
+   return ret;
 }
 
 static int sii902x_remove(struct i2c_client *client)
@@ -443,6 +471,9 @@ static int sii902x_remove(struct i2c_client *client)
 
drm_bridge_remove(>bridge);
 
+   regulator_bulk_disable(ARRAY_SIZE(sii902x->supplies),
+  sii902x->supplies);
+
return 0;
 }
 
-- 
2.15.1

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

[PATCH 0/2] drm/bridge: sii902x: add optional power supplies

[Philippe Cornu]

This patchset adds the 3 optional power supplies to the sii902x
drm bridge driver.

Philippe Cornu (2):
  dt-bindings/display/bridge: sii902x: add optional power supplies
  drm/bridge: sii902x: add optional power supplies

 .../devicetree/bindings/display/bridge/sii902x.txt |  3 ++
 drivers/gpu/drm/bridge/sii902x.c   | 39 +++---
 2 files changed, 38 insertions(+), 4 deletions(-)

-- 
2.15.1

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

[PATCH 1/2] dt-bindings/display/bridge: sii902x: add optional power supplies

[Philippe Cornu]

Add the 3 optional power supplies using the exact description
found in the document named
"SiI9022A/SiI9024A HDMI Transmitter Data Sheet (August 2016)".

Signed-off-by: Philippe Cornu 
---
 Documentation/devicetree/bindings/display/bridge/sii902x.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/bridge/sii902x.txt 
b/Documentation/devicetree/bindings/display/bridge/sii902x.txt
index 56a3e68ccb80..cf53678fe574 100644
--- a/Documentation/devicetree/bindings/display/bridge/sii902x.txt
+++ b/Documentation/devicetree/bindings/display/bridge/sii902x.txt
@@ -8,6 +8,9 @@ Optional properties:
- interrupts-extended or interrupt-parent + interrupts: describe
  the interrupt line used to inform the host about hotplug events.
- reset-gpios: OF device-tree gpio specification for RST_N pin.
+   - iovcc-supply: I/O supply voltage (1.8V or 3.3V, host-dependent).
+   - avcc12-supply: TMDS analog supply voltage (1.2V).
+   - cvcc12-supply: Digital core supply voltage (1.2V).
 
 Optional subnodes:
- video input: this subnode can contain a video input port node
-- 
2.15.1

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

[radeon-alex:drm-next-4.18-wip 43/120] drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_optc.c:127 get_start_vline() warn: unsigned 'vertical_line_start' is never less than zero.

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git drm-next-4.18-wip
head:   5d404d3139a4624892a12683240abfae931ee849
commit: 2852a36199784540a872f42fa6dc7d8d51eee0d8 [43/120] drm/amd/display: Add 
vline IRQ programming for DCN

smatch warnings:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_optc.c:127 
get_start_vline() warn: unsigned 'vertical_line_start' is never less than zero.

vim +/vertical_line_start +127 
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_optc.c

95  
96  static uint32_t get_start_vline(struct timing_generator *optc, const 
struct dc_crtc_timing *dc_crtc_timing)
97  {
98  struct dc_crtc_timing patched_crtc_timing;
99  uint32_t vesa_sync_start;
   100  uint32_t asic_blank_end;
   101  uint32_t interlace_factor;
   102  uint32_t vertical_line_start;
   103  
   104  patched_crtc_timing = *dc_crtc_timing;
   105  optc1_apply_front_porch_workaround(optc, _crtc_timing);
   106  
   107  vesa_sync_start = patched_crtc_timing.h_addressable +
   108  patched_crtc_timing.h_border_right +
   109  patched_crtc_timing.h_front_porch;
   110  
   111  asic_blank_end = patched_crtc_timing.h_total -
   112  vesa_sync_start -
   113  patched_crtc_timing.h_border_left;
   114  
   115  interlace_factor = patched_crtc_timing.flags.INTERLACE ? 2 : 1;
   116  
   117  vesa_sync_start = patched_crtc_timing.v_addressable +
   118  patched_crtc_timing.v_border_bottom +
   119  patched_crtc_timing.v_front_porch;
   120  
   121  asic_blank_end = (patched_crtc_timing.v_total -
   122  vesa_sync_start -
   123  patched_crtc_timing.v_border_top)
   124  * interlace_factor;
   125  
   126  vertical_line_start = asic_blank_end - 
optc->dlg_otg_param.vstartup_start + 1;
 > 127  if (vertical_line_start < 0) {
   128  ASSERT(0);
   129  vertical_line_start = 0;
   130  }
   131  
   132  return vertical_line_start;
   133  }
   134  

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

[radeon-alex:amd-staging-drm-next 12/33] freesync.c:undefined reference to `__udivdi3'

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head:   24110c70630998dc83da23cae910a9538f54ef64
commit: 0547606296e739e875a294d786233bf2e6680421 [12/33] drm/amd/display: 
Refactor FreeSync module
config: i386-allyesconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
git checkout 0547606296e739e875a294d786233bf2e6680421
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.o: In function 
`hwss_edp_power_control':
   dce110_hw_sequencer.c:(.text+0xda8): undefined reference to `__udivdi3'
   drivers/gpu/drm/amd/display/modules/freesync/freesync.o: In function 
`mod_freesync_build_vrr_params':
>> freesync.c:(.text+0x3b5): undefined reference to `__udivdi3'

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


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

Re: [DPU PATCH 1/2] drm/panel: Add Truly Dual DSI video mode panel

[abhinavk]

On 2018-04-08 09:36, Archit Taneja wrote:

Hi Abhinav,

Thanks for posting this driver. Some comments below.

On Saturday 07 April 2018 12:36 PM, Abhinav Kumar wrote:

From: Archit Taneja 

Add support for truly dual DSI video mode panel
panel used in MSM reference platforms >
Signed-off-by: Archit Taneja 
Signed-off-by: Abhinav Kumar 
---
  .../bindings/display/truly,dual_wqxga.txt  |  47 ++
  drivers/gpu/drm/panel/Kconfig  |   7 +
  drivers/gpu/drm/panel/Makefile |   1 +
  drivers/gpu/drm/panel/panel-truly-dual-dsi.c   | 530 
+

  4 files changed, 585 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/display/truly,dual_wqxga.txt

  create mode 100644 drivers/gpu/drm/panel/panel-truly-dual-dsi.c

diff --git 
a/Documentation/devicetree/bindings/display/truly,dual_wqxga.txt 
b/Documentation/devicetree/bindings/display/truly,dual_wqxga.txt

new file mode 100644
index 000..a1b24c1
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/truly,dual_wqxga.txt
@@ -0,0 +1,47 @@
+Truly model NT35597 1440x2560 DSI Panel
+
+Required properties:
+- compatible: should be "truly,dual_wqxga"


The compatible string, kernel config and the driver file should be 
based

on the panel model no. There can be many truly based panels that
support wqxga. Something like "truly,nt35597" would be better.


[Abhinav] Yes, will change it in v2.

+- vdda-supply: phandle of the regulator that provides the supply 
voltage

+  Power IC supply
+- lab-supply: phandle of the regulator that provides the supply 
voltage

+  for LCD bias
+- ibb-supply: phandle of the regulator that provides the supply 
voltage

+  for LCD bias


Both seem to have the same description. Aren't lab and ibb qualcomm
specific terms? Could we use the pin names specified in the panel's
data sheet?

[Abhinav] There isnt a number specified on the data sheet. I will use 
vdispp-supply and

vdispn-supply . Does that work?



+- reset-gpios: phandle of gpio for reset line
+  This should be 8mA, gpio can be configured using mux, pinctrl, 
pinctrl-names
+- mode-gpios: phandle of the gpio for choosing the mode of the 
display

+  for single DSI or Dual DSI


Could we describe here how to use this gpio? I.e, whether we need to 
set

it to low for dual DSI, etc?


[Abhinav] Yes, will do this in v2.

+- display-timings: Node for the Panel timings
+- link2: phandle to the secondary node of the panel


The link2 binding was a temporary hack we used. We should use the
of-graph bindings to represent the two DSI input ports of the panel.


[Abhinav] Alright will start using of-graph in the next patchset.

+
+Example:
+
+   dsi@ae94000 {
+   panel@0 {
+   compatible = "truly,dual_wqxga";
+   reg = <0>;
+   link2 = <>;
+   vdda-supply = <_l14>;
+
+   pinctrl-names = "default", "suspend";
+   pinctrl-0 = <_dsi_active>;
+   pinctrl-1 = <_dsi_suspend>;
+
+   reset-gpios = < 6 0>;
+   mode-gpios = < 52 0>;
+   display-timings {
+   timing0: timing-0 {
+   clock-frequency = <268316138>;
+   hactive = <1440>;
+   vactive = <2560>;
+   hfront-porch = <200>;
+   hback-porch = <64>;
+   hsync-len = <32>;
+   vfront-porch = <8>;
+   vback-porch = <7>;
+   vsync-len = <1>;
+   };
+   };
+   };
+   };
diff --git a/drivers/gpu/drm/panel/Kconfig 
b/drivers/gpu/drm/panel/Kconfig

index 988048e..a63c3f7 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -168,4 +168,11 @@ config DRM_PANEL_SITRONIX_ST7789V
  Say Y here if you want to enable support for the Sitronix
  ST7789V controller for 240x320 LCD panels
  +config DRM_PANEL_TRULY_WQXGA
+   tristate "Truly WQXGA"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   help
+ Say Y here if you want to enable support for Truly WQXGA Dual DSI
+ Video Mode panel
  endmenu

[Abhinav] These configs will be updated too
diff --git a/drivers/gpu/drm/panel/Makefile 
b/drivers/gpu/drm/panel/Makefile

index 3d2a88d..64891f6 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -17,3 +17,4 @@ obj-$(CONFIG_DRM_PANEL_SEIKO_43WVF1G) += 
panel-seiko-43wvf1g.o
  obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += 
panel-sharp-lq101r1sx01.o
  

Re: [RFC 0/2] drm/vc4: Async page flip cleanup

[Eric Anholt]

Boris Brezillon  writes:

> Hello,
>
> This is an attempt at simplifying the async page flip handling in VC4
> in order to get rid of vc4_queue_seqno_cb() and its dependencies and
> rely on fences instead.
>
> The reason I'm sending this as an RFC is because I'm pretty sure we can
> put some of the code added in patch 1 in drm_atomic_helper.c. Also, I'd
> like to have feedback from Padovan, Daniel and maybe others who have
> already thought about handling async page flips generically.
> And the last reason is that it's not been extensively tested, so it may
> not work correctly :-).

I'm certainly eager to see our custom async code die.  Any KMS core
folks want to comment on this proposal?


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

[radeon-alex:drm-next-4.18-wip 95/120] dce110_hw_sequencer.c:undefined reference to `__udivdi3'

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git drm-next-4.18-wip
head:   5d404d3139a4624892a12683240abfae931ee849
commit: 9c1f5ab7dcce1b9ddb9321b328c5445238450671 [95/120] drm/amd/display: add 
delay between panel pwr off to on.
config: i386-allyesconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
git checkout 9c1f5ab7dcce1b9ddb9321b328c5445238450671
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.o: In function 
`hwss_edp_power_control':
>> dce110_hw_sequencer.c:(.text+0xd78): undefined reference to `__udivdi3'

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


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

[PATCH 2/3] ARM: dts: bcm283x: Remove the vc4 GPU subsystem node.

[Eric Anholt]

This is no longer required by the DRM driver, and was just a temporary
hack for it.

Signed-off-by: Eric Anholt 
---
 arch/arm/boot/dts/bcm283x.dtsi | 4 
 1 file changed, 4 deletions(-)

diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
index 9d293decf8d3..869bf350d426 100644
--- a/arch/arm/boot/dts/bcm283x.dtsi
+++ b/arch/arm/boot/dts/bcm283x.dtsi
@@ -609,10 +609,6 @@
reg = <0x7ec0 0x1000>;
interrupts = <1 10>;
};
-
-   vc4: gpu {
-   compatible = "brcm,bcm2835-vc4";
-   };
};
 
clocks {
-- 
2.17.0

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

[PATCH 1/3] drm/vc4: Remove the need for the GPU-subsystem DT node.

[Eric Anholt]

The GPU subsystem node was a workaround to have a central device to
bind V3D and display to.  Following the lead of 246774d17fc0
("drm/etnaviv: remove the need for a gpu-subsystem DT node"), remove
the subsystem node usage and just create a platform device for the DRM
device to attach to if any of the subsystem devices are present.

Signed-off-by: Eric Anholt 
---
 .../bindings/display/brcm,bcm-vc4.txt |  7 
 drivers/gpu/drm/vc4/vc4_drv.c | 33 ++-
 drivers/gpu/drm/vc4/vc4_hvs.c |  1 +
 drivers/gpu/drm/vc4/vc4_v3d.c |  1 +
 4 files changed, 27 insertions(+), 15 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt 
b/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
index 284e2b14cfbe..5fd4717101d6 100644
--- a/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
+++ b/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
@@ -4,9 +4,6 @@ The VC4 device present on the Raspberry Pi includes a display 
system
 with HDMI output and the HVS (Hardware Video Scaler) for compositing
 display planes.
 
-Required properties for VC4:
-- compatible:  Should be "brcm,bcm2835-vc4" or "brcm,cygnus-vc4"
-
 Required properties for Pixel Valve:
 - compatible:  Should be one of "brcm,bcm2835-pixelvalve0",
  "brcm,bcm2835-pixelvalve1", or "brcm,bcm2835-pixelvalve2"
@@ -153,10 +150,6 @@ v3d: v3d@7ec0 {
interrupts = <1 10>;
 };
 
-vc4: gpu {
-   compatible = "brcm,bcm2835-vc4";
-};
-
 panel: panel {
compatible = "ontat,yx700wv03", "simple-panel";
 
diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index 7c95ed5c5cac..d282ab7de03a 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -364,22 +364,34 @@ static int vc4_platform_drm_remove(struct platform_device 
*pdev)
return 0;
 }
 
-static const struct of_device_id vc4_of_match[] = {
-   { .compatible = "brcm,bcm2835-vc4", },
-   { .compatible = "brcm,cygnus-vc4", },
-   {},
-};
-MODULE_DEVICE_TABLE(of, vc4_of_match);
-
 static struct platform_driver vc4_platform_driver = {
.probe  = vc4_platform_drm_probe,
.remove = vc4_platform_drm_remove,
.driver = {
.name   = "vc4-drm",
-   .of_match_table = vc4_of_match,
},
 };
 
+static bool
+driver_of_table_has_a_match(const struct platform_driver *driver)
+{
+   int i;
+
+   for (i = 0; driver->driver.of_match_table[i].compatible; i++) {
+   const char *compat = 
driver->driver.of_match_table[i].compatible;
+   struct device_node *node;
+
+   while ((node = of_find_compatible_node(node, NULL, compat))) {
+   if (of_device_is_available(node)) {
+   of_node_put(node);
+   return true;
+   }
+   }
+   }
+
+   return false;
+}
+
 static int __init vc4_drm_register(void)
 {
int ret;
@@ -389,6 +401,11 @@ static int __init vc4_drm_register(void)
if (ret)
return ret;
 
+   if (driver_of_table_has_a_match(_v3d_driver) ||
+   driver_of_table_has_a_match(_hvs_driver)) {
+   platform_device_register_simple("vc4-drm", -1, NULL, 0);
+   }
+
return platform_driver_register(_platform_driver);
 }
 
diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drivers/gpu/drm/vc4/vc4_hvs.c
index 2b62fc5b8d85..730813ee74ae 100644
--- a/drivers/gpu/drm/vc4/vc4_hvs.c
+++ b/drivers/gpu/drm/vc4/vc4_hvs.c
@@ -262,6 +262,7 @@ static const struct of_device_id vc4_hvs_dt_match[] = {
{ .compatible = "brcm,bcm2835-hvs" },
{}
 };
+MODULE_DEVICE_TABLE(of, vc4_hvs_dt_match);
 
 struct platform_driver vc4_hvs_driver = {
.probe = vc4_hvs_dev_probe,
diff --git a/drivers/gpu/drm/vc4/vc4_v3d.c b/drivers/gpu/drm/vc4/vc4_v3d.c
index bfc2fa73d2ae..e77e9ebbab4b 100644
--- a/drivers/gpu/drm/vc4/vc4_v3d.c
+++ b/drivers/gpu/drm/vc4/vc4_v3d.c
@@ -459,6 +459,7 @@ static const struct of_device_id vc4_v3d_dt_match[] = {
{ .compatible = "brcm,vc4-v3d" },
{}
 };
+MODULE_DEVICE_TABLE(of, vc4_v3d_dt_match);
 
 struct platform_driver vc4_v3d_driver = {
.probe = vc4_v3d_dev_probe,
-- 
2.17.0

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

[PATCH 3/3] ARM: dts: cygnus: Remove the vc4 GPU subsystem node.

[Eric Anholt]

This is no longer required by the DRM driver, and was just a temporary
hack for it.

Signed-off-by: Eric Anholt 
---
 arch/arm/boot/dts/bcm-cygnus.dtsi | 4 
 1 file changed, 4 deletions(-)

diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi 
b/arch/arm/boot/dts/bcm-cygnus.dtsi
index 699fdf94d139..258bb3d61582 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -492,10 +492,6 @@
status = "disabled";
};
 
-   vc4: gpu {
-   compatible = "brcm,cygnus-vc4";
-   };
-
gpio_asiu: gpio@180a5000 {
compatible = "brcm,cygnus-asiu-gpio";
reg = <0x180a5000 0x668>;
-- 
2.17.0

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

[Bug 104216] Firefox quirks (black and/or white squares)

[bugzilla-daemon]

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

--- Comment #23 from Germano Massullo  ---
Trying to get some answers from Mozilla developers

https://bugzilla.mozilla.org/show_bug.cgi?id=1421353#c17

https://bugzilla.mozilla.org/show_bug.cgi?id=1421353#c18

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

Re: RFC for a render API to support adaptive sync and VRR

[Manasi Navare]

Thanks for initiating the discussion. Find my comments below:

On Mon, Apr 09, 2018 at 04:00:21PM -0400, Harry Wentland wrote:
> Adding dri-devel, which I should've included from the start.
> 
> On 2018-04-09 03:56 PM, Harry Wentland wrote:
> > === What is adaptive sync and VRR? ===
> > 
> > Adaptive sync has been part of the DisplayPort spec for a while now and 
> > allows graphics adapters to drive displays with varying frame timings. VRR 
> > (variable refresh rate) is essentially the same, but defined for HDMI.
> > 
> > 
> > 
> > === Why allow variable frame timings? ===
> > 
> > Variable render times don't align with fixed refresh rates, leading to
> > stuttering, tearing, and/or input lag.
> > 
> > e.g. (rc = render completion, dr = display refresh)
> > 
> > rc   B  CDE  F
> > dr  A   B   C   C   D   E   F
> > 
> > ^ ^
> >   frame missed 
> >  repeated   display
> >   twice refresh   
> > 
> > 
> > 
> > === Other use cases of adaptive sync 
> > 
> > Beside the variable render case, adaptive sync also allows adjustment of 
> > refresh rates without a mode change. One such use case would be 24 Hz video.
> >

One of the the advantages here when the render speed is slower than the display 
refresh rate, since we are stretching the vertical blanking interval
the display adapters will follow "draw fast and then go idle" approach. This 
gives power savings when render rate is lower than the display refresh rate.
 
> > 
> > 
> > === A DRM render API to support variable refresh rates ===
> > 
> > In order to benefit from adaptive sync and VRR userland needs a way to let 
> > us know whether to vary frame timings or to target a different frame time. 
> > These can be provided as atomic properties on a CRTC:
> >  * bool variable_refresh_compatible
> >  * int  target_frame_duration_ns (nanosecond frame duration)
> > 
> > This gives us the following cases:
> > 
> > variable_refresh_compatible = 0, target_frame_duration_ns = 0
> >  * drive monitor at timing's normal refresh rate
> > 
> > variable_refresh_compatible = 1, target_frame_duration_ns = 0
> >  * send new frame to monitor as soon as it's available, if within min/max 
> > of monitor's reported capabilities
> > 
> > variable_refresh_compatible = 0/1, target_frame_duration_ns = > 0
> >  * send new frame to monitor with the specified target_frame_duration_ns
> > 
> > When a target_frame_duration_ns or variable_refresh_compatible cannot be 
> > supported the atomic check will reject the commit.
> >

What I would like is two sets of properties on a CRTC or preferably on a 
connector:

KMD properties that UMD can query:
* vrr_capable -  This will be an immutable property for exposing hardware's 
capability of supporting VRR. This will be set by the kernel after 
reading the EDID mode information and monitor range capabilities.
* vrr_vrefresh_max, vrr_vrefresh_min - To expose the min and max refresh rates 
supported.
These properties are optional and will be created and attached to the DP/eDP 
connector when the connector
is getting intialized.

Properties that you mentioned above that the UMD can set before kernel can 
enable VRR functionality
*bool vrr_enable or vrr_compatible
target_frame_duration_ns

The monitor only specifies the monitor range through EDID. Apart from this 
should we also need to scan the modes and check
if there are modes that have the same pixel clock and horizontal timings but 
variable vertical totals?

I have RFC patches for all the above mentioned. If we get a concensus/agreement 
on the above properties and method to check
monitor's VRR capability, I can submit those patches atleast as RFC.

Regards
Manasi

> > 
> > 
> > === Previous discussions ===
> > 
> > https://lists.freedesktop.org/archives/dri-devel/2017-October/155207.html
> > 
> > 
> > 
> > === Feedback and moving forward ===
> > 
> > I'm hoping to get some feedback on this or continue the discussion on how 
> > adaptive sync / VRR might look like in the DRM ecosystem. Once there are no 
> > major concerns or objections left we'll probably start creating some 
> > patches to sketch this out a bit better and see how it looks in practice.
> > 
> > 
> > 
> > Cheers,
> > Harry
> > ___
> > amd-gfx mailing list
> > amd-...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/amd-gfx
> > 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 6/7] clk: sunxi-ng: sun5i: Export the MBUS clock

[Rob Herring]

On Tue, Apr 03, 2018 at 03:29:19PM +0200, Maxime Ripard wrote:
> The MBUS clock is used by the MBUS controller, so let's export it so that
> we can use it in our DT node.
> 
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/clk/sunxi-ng/ccu-sun5i.h  | 4 
>  include/dt-bindings/clock/sun5i-ccu.h | 2 +-
>  2 files changed, 1 insertion(+), 5 deletions(-)

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

Re: [PATCH] display: panel: Add AUO g070vvn01 display support (800x480)

[Rob Herring]

On Tue, Apr 03, 2018 at 12:15:25PM +0200, Lukasz Majewski wrote:
> This commit adds support for AUO's 7.0" display.
> 
> Signed-off-by: Lukasz Majewski 
> ---
>  .../bindings/display/panel/auo,g070vvn01   | 30 +

.txt

>  drivers/gpu/drm/panel/panel-simple.c   | 31 
> ++
>  2 files changed, 61 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/auo,g070vvn01
> 
> diff --git a/Documentation/devicetree/bindings/display/panel/auo,g070vvn01 
> b/Documentation/devicetree/bindings/display/panel/auo,g070vvn01
> new file mode 100644
> index ..bd4017362094
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/auo,g070vvn01
> @@ -0,0 +1,30 @@
> +AU Optronics Corporation 7.0" FHD (800 x 480) TFT LCD panel
> +
> +Required properties:
> +- compatible: should be "auo,g070vvn01"
> +- backlight: phandle of the backlight device attached to the panel
> +- power-supply: single regulator to provide the supply voltage
> +
> +Required nodes:
> +- port: Parallel port mapping to connect this display
> +
> +This panel needs single power supply voltage. Its backlight is conntrolled
> +via PWM signal.
> +
> +Example:
> +
> +
> +Example device-tree definition when connected to iMX6Q based board
> +
> + lcd_panel: lcd-panel {
> + compatible = "auo,g070vvn01";
> + backlight = <_lcd>;
> + bus-format-override = "rgb565";

This is not documented though it appears in a few i.MX dts files.

> + power-supply = <_display>;
> +
> + port {
> + lcd_panel_in: endpoint {
> + remote-endpoint = <_display_out>;
> + };
> + };
> + };
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Freedreno] [DPU PATCH 1/2] drm/msm/dsi: check video mode engine status before waiting

[abhinavk]

On 2018-04-09 08:28, Jordan Crouse wrote:

On Sat, Apr 07, 2018 at 12:50:04AM -0700, Abhinav Kumar wrote:

Make sure the video mode engine is on before waiting
for the video done interrupt.

Otherwise it leads to silent timeouts increasing display
turn ON time.

Signed-off-by: Abhinav Kumar 
---
 drivers/gpu/drm/msm/dsi/dsi_host.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c

index 7a03a94..24766c3 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -173,6 +173,7 @@ struct msm_dsi_host {

bool registered;
bool power_on;
+   bool enabled;
int irq;
 };

@@ -986,13 +987,18 @@ static void dsi_set_tx_power_mode(int mode, 
struct msm_dsi_host *msm_host)


 static void dsi_wait4video_done(struct msm_dsi_host *msm_host)
 {
+   u32 ret = 0;
+
dsi_intr_ctrl(msm_host, DSI_IRQ_MASK_VIDEO_DONE, 1);

reinit_completion(_host->video_comp);

-   wait_for_completion_timeout(_host->video_comp,
+   ret = wait_for_completion_timeout(_host->video_comp,
msecs_to_jiffies(70));

+   if (ret <= 0)
+   pr_err("wait for video done failed\n");
+


Does this need to be rate limited? How often will it print?  Also, 
'wait for
video done timed out" would be more descriptive for the situation.  I'm 
not sure
from the context if you have a pr_fmt defined for this file but if you 
don't you
might want to add the appropriate prefixes (or use dev_err) so the 
reader can
get a bit more detailed information about where to look and what is 
going on.


Jordan

[Abhinav] With the rest of this change, this error should not happen.
This will print whenever we need to call this for waiting for each panel 
command.
The number of panel commands can vary with panel from < 10 to 100s at 
times.
But since we do not expect this to happen at all, at this point i dont 
think we need

to rate limit this.

Yes, will replace the pr_err with dev_err in V2.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/i2c: tda998x: Remove VLA usage

[Laura Abbott]

There's an ongoing effort to remove VLAs[1] from the kernel to eventually
turn on -Wvla. The vla in reg_write_range is based on the length of data
passed. The one use of a non-constant size for this range is bounded by
the size buffer passed to hdmi_infoframe_pack which is a fixed size.
Switch to this upper bound.

[1] https://lkml.org/lkml/2018/3/7/621

Signed-off-by: Laura Abbott 
---
This one really feels like it should be a #define but I wasn't sure
where the 32 came from. It looks like most other uses use one of the
#defines in include/linux/hdmi?
---
 drivers/gpu/drm/i2c/tda998x_drv.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
b/drivers/gpu/drm/i2c/tda998x_drv.c
index 9e67a7b4e3a4..29e2f49601c7 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -470,7 +470,8 @@ static void
 reg_write_range(struct tda998x_priv *priv, u16 reg, u8 *p, int cnt)
 {
struct i2c_client *client = priv->hdmi;
-   u8 buf[cnt+1];
+   /* This is the maximum size of the buffer passed in */
+   u8 buf[33];
int ret;
 
buf[0] = REG2ADDR(reg);
-- 
2.14.3

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

[PATCH] drm/gma500: Remove VLA

[Laura Abbott]

There's an ongoing effort to remove VLAs[1] from the kernel to eventually
turn on -Wvla. Switch to a reasonable upper bound for the VLAs in
the gma500 driver.

[1] https://lkml.org/lkml/2018/3/7/621

Signed-off-by: Laura Abbott 
---
This was a little hard to figure out but I think 32 should be a
comfortable upper bound based on all the structures I saw. Of course I
can't test it.
---
 drivers/gpu/drm/gma500/psb_intel_sdvo.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/gma500/psb_intel_sdvo.c 
b/drivers/gpu/drm/gma500/psb_intel_sdvo.c
index 84507912be84..3d4fa9f6b94c 100644
--- a/drivers/gpu/drm/gma500/psb_intel_sdvo.c
+++ b/drivers/gpu/drm/gma500/psb_intel_sdvo.c
@@ -429,13 +429,20 @@ static const char *cmd_status_names[] = {
"Scaling not supported"
 };
 
+#define MAX_ARG_LEN 32
+
 static bool psb_intel_sdvo_write_cmd(struct psb_intel_sdvo *psb_intel_sdvo, u8 
cmd,
 const void *args, int args_len)
 {
-   u8 buf[args_len*2 + 2], status;
-   struct i2c_msg msgs[args_len + 3];
+   u8 buf[MAX_ARG_LEN*2 + 2], status;
+   struct i2c_msg msgs[MAX_ARG_LEN + 3];
int i, ret;
 
+   if (args_len > MAX_ARG_LEN) {
+   DRM_ERROR("Need to increase arg length\n");
+   return false;
+   }
+
psb_intel_sdvo_debug_write(psb_intel_sdvo, cmd, args, args_len);
 
for (i = 0; i < args_len; i++) {
-- 
2.14.3

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

[PATCH] drm/amdkfd: Remove vla

[Laura Abbott]

There's an ongoing effort to remove VLAs[1] from the kernel to eventually
turn on -Wvla. The single VLA usage in the amdkfd driver is actually
constant across all current platforms. Switch to a constant size array
instead.

[1] https://lkml.org/lkml/2018/3/7/621

Signed-off-by: Laura Abbott 
---
 drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c
index 035c351f47c5..c9863858f343 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c
@@ -139,10 +139,12 @@ static void interrupt_wq(struct work_struct *work)
 {
struct kfd_dev *dev = container_of(work, struct kfd_dev,
interrupt_work);
+   uint32_t ih_ring_entry[4];
 
-   uint32_t ih_ring_entry[DIV_ROUND_UP(
-   dev->device_info->ih_ring_entry_size,
-   sizeof(uint32_t))];
+   if (dev->device_info->ih_ring_entry_size > (4 * sizeof(uint32_t))) {
+   dev_err(kfd_chardev(), "Ring entry too small\n");
+   return;
+   }
 
while (dequeue_ih_ring_entry(dev, ih_ring_entry))
dev->device_info->event_interrupt_class->interrupt_wq(dev,
-- 
2.14.3

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

[PATCH] drm/vc4: Fix leak of the file_priv that stored the perfmon.

[Eric Anholt]

Signed-off-by: Eric Anholt 
Fixes: 65101d8c9108 ("drm/vc4: Expose performance counters to userspace")
---
 drivers/gpu/drm/vc4/vc4_drv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index 94b99c90425a..7c95ed5c5cac 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -130,6 +130,7 @@ static void vc4_close(struct drm_device *dev, struct 
drm_file *file)
struct vc4_file *vc4file = file->driver_priv;
 
vc4_perfmon_close_file(vc4file);
+   kfree(vc4file);
 }
 
 static const struct vm_operations_struct vc4_vm_ops = {
-- 
2.17.0

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

[Bug 104597] [bisected] Compton weird colors

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

 CC||c...@fuckyouprius.com

--- Comment #17 from Timothy Arceri  ---
*** Bug 105918 has been marked as a duplicate of this bug. ***

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

Re: [PATCHv3 5/8] dt-bindings: panel: common: document orientation property

[Rob Herring]

On Fri, Mar 30, 2018 at 07:18:19PM +0200, Sebastian Reichel wrote:
> Merge "rotation" property description into common panel
> binding.
> 
> Suggested-by: Rob Herring 
> Signed-off-by: Sebastian Reichel 
> ---
>  .../devicetree/bindings/display/panel/panel-common.txt   | 12 
> 
>  Documentation/devicetree/bindings/display/panel/panel.txt|  4 
>  2 files changed, 12 insertions(+), 4 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/display/panel/panel.txt

Reviewed-by: Rob Herring 

Thanks for consolidating.

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

Re: [PATCH v3 2/2] drivers: remove force dma flag from buses

[Rob Herring]

On Fri, Mar 30, 2018 at 01:24:45PM +0530, Nipun Gupta wrote:
> With each bus implementing its own DMA configuration callback,
> there is no need for bus to explicitly have force_dma in its
> global structure. This patch modifies of_dma_configure API to
> accept an input parameter which specifies if implicit DMA
> configuration is required even when it is not described by the
> firmware.
> 
> Signed-off-by: Nipun Gupta 
> ---
> Changes in v2:
>   - This is a new change suggested by Robin and Christoph
> and is added to the series.
> 
> Changes in v3:
>   - Rebase and changes corresponding to the changes in patch 1/2
> 
>  drivers/amba/bus.c| 1 -
>  drivers/base/platform.c   | 3 +--
>  drivers/bcma/main.c   | 2 +-
>  drivers/dma/qcom/hidma_mgmt.c | 2 +-
>  drivers/gpu/host1x/bus.c  | 5 ++---
>  drivers/of/device.c   | 6 --
>  drivers/of/of_reserved_mem.c  | 2 +-
>  drivers/pci/pci-driver.c  | 3 +--
>  include/linux/device.h| 4 
>  include/linux/of_device.h | 8 ++--
>  10 files changed, 17 insertions(+), 19 deletions(-)

Reviewed-by: Rob Herring 

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

[Bug 105425] 3D & games produce periodic GPU crashes (Radeon R7 370)

[bugzilla-daemon]

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

--- Comment #19 from MirceaKitsune  ---
(In reply to Alex Deucher from comment #18)
> Those parameters are not used on your chip.

That would be quite something, since after setting them I've clearly seen an
enormous difference. I will investigate further in the upcoming days.

-- 
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: drm/vc4: false-positive negative cursor position warning

[Eric Anholt]

Daniel J Blueman  writes:

> Hi Eric et al,
>
> In a number of windowing environments (eg GNOME 3) on Raspberry Pi 3B
> on 4.16.0 arm64, the mouse cursor top-left gets down to x,y -4,-4,
> tripping WARN_ON_ONCE(plane->state->crtc_x < 0 || plane->state->crtc_y
> < 0) [1], which therefore seems false-positive.
>
> Git history doesn't turn up any reason, eg it could cause undefined
> hardware behaviour, which it doesn't appear to, so would it be better
> to drop the warning, or adjust it to trip on x or y < -4 or so? If so,
> I'll prepare a patch to adjust it.

Ccing Boris, who's been doing work on the async update path.

Take a look at vc4_plane_setup_clipping_and_scaling(state) -- that has
the corrections necessary for negative x/y.  We're calling that too late
(through the avc4_plane_atomic_check() path) for this function's usage
of the offsets[].

Since it affects the computed src_w/h, we'd have to update those as well
in our async update.  Our async update is racy in a way that makes me
uncomfortable -- the HVS could process our display list at any point in
our writel() sequence, which is not very atomic.  Maybe we should be
using a double-buffered HVS display list per element, and then have the
main display list jump into each element's current display list and back
out, so that we can do async flips to new plane state by just commiting
a single writel() to the new HVS display element list.


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

[Bug 105425] 3D & games produce periodic GPU crashes (Radeon R7 370)

[bugzilla-daemon]

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

--- Comment #18 from Alex Deucher  ---
(In reply to MirceaKitsune from comment #17)
> I will continue trying different values and seeing how tweaking them changes
> the issue. Please let me know what you think.

Those parameters are not used on your chip.

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

Re: RFC for a render API to support adaptive sync and VRR

[Harry Wentland]

Adding dri-devel, which I should've included from the start.

On 2018-04-09 03:56 PM, Harry Wentland wrote:
> === What is adaptive sync and VRR? ===
> 
> Adaptive sync has been part of the DisplayPort spec for a while now and 
> allows graphics adapters to drive displays with varying frame timings. VRR 
> (variable refresh rate) is essentially the same, but defined for HDMI.
> 
> 
> 
> === Why allow variable frame timings? ===
> 
> Variable render times don't align with fixed refresh rates, leading to
> stuttering, tearing, and/or input lag.
> 
> e.g. (rc = render completion, dr = display refresh)
> 
> rc   B  CDE  F
> drA   B   C   C   D   E   F
> 
> ^ ^
> frame missed 
>repeated   display
> twice refresh   
> 
> 
> 
> === Other use cases of adaptive sync 
> 
> Beside the variable render case, adaptive sync also allows adjustment of 
> refresh rates without a mode change. One such use case would be 24 Hz video.
> 
> 
> 
> === A DRM render API to support variable refresh rates ===
> 
> In order to benefit from adaptive sync and VRR userland needs a way to let us 
> know whether to vary frame timings or to target a different frame time. These 
> can be provided as atomic properties on a CRTC:
>  * bool   variable_refresh_compatible
>  * inttarget_frame_duration_ns (nanosecond frame duration)
> 
> This gives us the following cases:
> 
> variable_refresh_compatible = 0, target_frame_duration_ns = 0
>  * drive monitor at timing's normal refresh rate
> 
> variable_refresh_compatible = 1, target_frame_duration_ns = 0
>  * send new frame to monitor as soon as it's available, if within min/max of 
> monitor's reported capabilities
> 
> variable_refresh_compatible = 0/1, target_frame_duration_ns = > 0
>  * send new frame to monitor with the specified target_frame_duration_ns
> 
> When a target_frame_duration_ns or variable_refresh_compatible cannot be 
> supported the atomic check will reject the commit.
> 
> 
> 
> === Previous discussions ===
> 
> https://lists.freedesktop.org/archives/dri-devel/2017-October/155207.html
> 
> 
> 
> === Feedback and moving forward ===
> 
> I'm hoping to get some feedback on this or continue the discussion on how 
> adaptive sync / VRR might look like in the DRM ecosystem. Once there are no 
> major concerns or objections left we'll probably start creating some patches 
> to sketch this out a bit better and see how it looks in practice.
> 
> 
> 
> Cheers,
> Harry
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/vc4: Fix memory leak during BO teardown

[Eric Anholt]

Daniel J Blueman  writes:

> During BO teardown, an indirect list 'uniform_addr_offsets' wasn't being
> freed leading to leaking many 128B allocations. Fix the memory leak by
> releasing it at teardown time.

Reviewed, added a Fixes tag, and pushed to drm-misc-fixes.  Thanks!


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

[Bug 105425] 3D & games produce periodic GPU crashes (Radeon R7 370)

[bugzilla-daemon]

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

--- Comment #17 from MirceaKitsune  ---
I have a very important preliminary result: Today I tested the last amdgpu
parameters on the list, and seem to have found a set that greatly mitigates the
problem. Those parameters have given me up to 144 minutes before experiencing
the freeze, a huge record compared to the previous 90 minutes! They are:

amdgpu.prim_buf_per_se=16
amdgpu.pos_buf_per_se=16
amdgpu.cntl_sb_buf_per_se=16
amdgpu.param_buf_per_se=16

By default, all 4 of those settings are set to 0 by the system. Setting them to
16 has, at least during one test case, reduced the problem to 1/5 of its
previous frequency. The descriptions of the variables are:

parm: prim_buf_per_se:the size of Primitive Buffer per Shader Engine (default
depending on gfx) (int)
parm: pos_buf_per_se:the size of Position Buffer per Shader Engine (default
depending on gfx) (int)
parm: cntl_sb_buf_per_se:the size of Control Sideband per Shader Engine
(default depending on gfx) (int)
parm: param_buf_per_se:the size of Off-Chip Pramater Cache per Shader Engine
(default depending on gfx) (int)

I will continue trying different values and seeing how tweaking them changes
the issue. Please let me know what you think.

-- 
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 v2 4/5] drm: bridge: lvds-encoder: allow specifying the input bus format

[Rob Herring]

On Mon, Mar 26, 2018 at 11:24:46PM +0200, Peter Rosin wrote:
> If the bridge changes the bus format, allow this to be described in
> the bridge, instead of providing false information about the bus
> format of the connector or panel.

I guess this is dead, but I'll comment here anyway because this issue 
has come up several times and I think something is needed.

> 
> Signed-off-by: Peter Rosin 
> ---
>  .../bindings/display/bridge/lvds-transmitter.txt   |  6 ++
>  drivers/gpu/drm/bridge/lvds-encoder.c  | 25 
> ++
>  2 files changed, 31 insertions(+)
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt 
> b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
> index 50220190c203..8d40a2069252 100644
> --- a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
> +++ b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
> @@ -30,6 +30,12 @@ Required properties:
>device-specific version corresponding to the device first
>followed by the generic version.
>  
> +Optional properties:
> +
> +- interface-pix-fmt:
> +  List of valid input bus formats of the encoder. Recognized bus formats
> +  are listed in ../bus-format.txt

We already have bus interface properties defined in 
media/video-interfaces.txt. It's the same problem though the bus/pixel 
formats are somewhat different. "bus-width" is probably enough to handle 
your particular case, but I'd imagine that could easily not be the case. 
If so, we should extend the existing binding rather than diverge with 
something new.

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

Re: [Patch 2/4] dt-bindings: display/ti: Add plane binding to dispc node

[Rob Herring]

On Fri, Mar 23, 2018 at 2:53 AM, Tomi Valkeinen  wrote:
> Hi Rob,
>
> On 23/03/18 03:23, Rob Herring wrote:
>
>>> Ok, I think the description was a bit unclear. So, the driver can do
>>> this just fine, it can reserve hw planes dynamically when needed. The
>>> problem is the userspace.
>>>
>>> When a DRM application starts, it sees a bunch of planes, and can see on
>>> which crtcs each plane can be used. The expectation is, of course, that
>>> these planes can be used normally. If the driver would dynamically
>>> reserve an additional, currently unused plane, the userspace would be
>>> totally baffled, as it fails to configure basic plane setups.
>>>
>>> For example, the userspace could see that there are two planes, usable
>>> on LCD and HDMI crtcs. But mysteriously modesetting would sometimes fail
>>> if the HDMI is 2k+ display. Setting up a plane on the HDMI would work,
>>> except when the LCD already has a plane. Setting up two planes on the
>>> LCD would work, but moving one or both planes to the HDMI would fail. Etc.
>>
>> I suspect this is a common problem. Not because the h/w requires
>> different allocation of planes, but because the memory bandwidth can't
>> handle having a 2nd plane if the resolution is above a certain
>> size/depth. So while the plane doesn't disappear, the effect is the
>> same. How does DRM handle this?
>
> I don't think DRM handles this. Each driver can probably filter out
> videomodes which it knows can't be used even with single plane (we do
> this on omapdrm), and also can give an error if the plane setup would
> result in too high bandwidth use.
>
> So yes, plane setups can always fail, "mysteriously" from userspace's
> perspective. But I don't think it's exactly comparable to this one. The
> difference is that in this case we can avoid all the userspace issues
> with a simple static plane partitioning done at probe time, but I can't
> see how the bandwidth issue could be solved in a similar way.
>
>>> We could, of course, convey this information to the userspace at runtime
>>> via the DRM properties, but then it would mean we'd need customized
>>> applications.
>>>
>>> So, as far as I can see, keeping normal DRM behavior with 2k+ displays
>>> on OMAP DSS requires a static virtual plane setup. The most simple setup
>>> would be to just split the number of available planes by 2, but then in
>>> many use cases that wastes one hw plane.
>>
>> For HDMI, you can't know in advance what resolution will be. So I
>> think you always need to reserve 2 planes. Now, if you want to reduce
>
> We can decide not to support 2k+ resolutions for HDMI, which, with this
> series, happens by not reserving dual-plane for the HDMI.

Right. So turn this around. Define in DT what is the maximum
resolution supported for HDMI and configure the planes based on that.
The difference is defining a max is generic enough that it can work
for others and for a variety of reasons whether it is # of planes,
memory bandwidth, crappy monitor, poor board signal quality, etc.

>> the max resolution for some reason, I guess we could have properties
>> for that. That would be more generic and work whether you need to
>> change plane allocation or have a limit for other reasons.
>>
>> For attached panels, you know the resolution up front and can allocate
>> planes before the userspace interface is up.
>
> But reserve how many of the planes? We have N planes and M displays. For
> some of the displays we know they're 2k+, some are known to be -2k and
> some are unknown. The driver can't independently make any sensible
> static reservation of the planes for the displays, because it doesn't
> know what the user wants to do.

After you've handled HDMI as above and any permanently attached panels
with fixed resolutions, what is left for a user to configure? Perhaps
only one display can support an overlay at that point because you are
out of planes?

> So either we reserve the extra planes at runtime on demand, making it
> difficult to manage for the userspace, or we rely on the user to give
> the driver a static partitioning of the planes according to the user's
> use case.

And by user, who do you mean exactly? The use case is tied to the
board design and product or tied to the whims of an end user (e.g. I
want to do video playback with overlay to disp 2)? You should equate
users making DT changes with telling users to update/change their
BIOS.

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

RE: [RFC 1/3] drm: Add DAMAGE_CLIPS property to plane

[Deepak Singh Rawat]

> > > > +void drm_plane_enable_damage_clips(struct drm_plane *plane)
> > > > +{
> > > > +   struct drm_device *dev = plane->dev;
> > > > +   struct drm_mode_config *config = >mode_config;
> > > > +
> > > > +   drm_object_attach_property(>base, config-
> > > >prop_damage_clips, 0);
> > > > +}
> > > > diff --git a/include/drm/drm_mode_config.h
> > > b/include/drm/drm_mode_config.h
> > > > index 7569f22..d8767da 100644
> > > > --- a/include/drm/drm_mode_config.h
> > > > +++ b/include/drm/drm_mode_config.h
> > > > @@ -628,6 +628,21 @@ struct drm_mode_config {
> > > >  */
> > > > struct drm_property *prop_crtc_id;
> > > > /**
> > > > +* @prop_damage_clips: Optional plane property to mark damaged
> > > regions
> > > > +* on the plane in framebuffer coordinates of the framebuffer
> > > attached
> > > > +* to the plane.
> > >
> > > Why should we make this optional? Looks like just another thing drivers
> > > might screw up, since we have multiple callbacks and things to set up for
> > > proper dirty tracking.
> >
> > Thanks Daniel for the review.
> >
> > I think not all compositor will be interested in sending damage, that was 
> > the
> > reason to make this optional. Also when damage is not set that means
> > user-space need full update just like eglSwapBuffersWithDamageKHR.
> >
> > I will add better documentation.
> 
> I think if we also handle this case in the helper that'd be even better:
> In the case of no damage, the helper/core code could automatically supply
> a damage rect for the entire buffer. That way drivers don't have to handle
> this case specially.
> -Daniel

Agreed.

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

Re: [PATCH 8/8] drm/arm/malidp: Added the late system pm functions

[Brian Starkey]

Hi Daniel,

On Mon, Apr 09, 2018 at 10:23:37AM +0200, Daniel Vetter wrote:

On Fri, Apr 06, 2018 at 08:02:16PM +0100, Ayan Halder wrote:

On Tue, Mar 27, 2018 at 01:09:36PM +0200, Daniel Vetter wrote:
> On Tue, Mar 27, 2018 at 11:59 AM, Ayan Halder  wrote:
> > On Tue, Mar 27, 2018 at 10:29:03AM +0200, Daniel Vetter wrote:
> >> On Mon, Mar 26, 2018 at 06:03:20PM +0100, Ayan Kumar Halder wrote:
> >> > malidp_pm_suspend_late checks if the runtime status is not suspended
> >> > and if so, invokes malidp_runtime_pm_suspend which disables the
> >> > display engine/core interrupts and the clocks. It sets the runtime status
> >> > as suspended. Subsequently, malidp_pm_resume_early will invoke
> >> > malidp_runtime_pm_resume which enables the clocks and the interrupts
> >> > (previously disabled) and sets the runtime status as active.
> >> >
> >> > Signed-off-by: Ayan Kumar Halder 
> >> > Change-Id: I5f8c3d28f076314a1c9da2a46760a9c37039ccda
> >>
> >> Why exactly do you need late/early hooks? If you have dependencies with
> >> other devices, pls consider adding device_links instead. This here
> >> shouldn't be necessary.
> >> -Daniel
> > We need to late/early hooks to disable malidp interrupts and the
> > clocks.
>
> Yes, but why this ordering constraint? Why can't you just disable the
> interrupts/clocks in the normal suspend code. I see that the patch
> does this, I want to understand why it does it.
> -Daniel
Apologies for my delayed response on this.

With reference to https://lwn.net/Articles/505683/ :-
1. "suspend() should leave the device in a quiescent state." We invoke
drm_mode_config_helper_suspend() which deactivates the crtc. I
understand that this is the quiescent state.

2. "suspend_late() can often be the same as runtime_suspend()."  We
invoke runtime suspend/resume calls in late/early hooks.


This article is from 2012. That's not really recommended best practices
anymore. device_links have only been added a few years ago, so ofc an
article from 2012 can't tell you that you should use those instead :-)

That's why I brought this up, we have much better ways to handle device
dependencies now.



We aren't trying to manage any device dependencies here, I don't know
where that idea came from?

The kernel-doc on drm-next this afternoon says effectively the same
thing:

  * @suspend: Executed before putting the system into a sleep state in which the
  *  contents of main memory are preserved.  The exact action to perform
  *  depends on the device's subsystem (PM domain, device type, class or bus
  *  type), but generally the device must be quiescent after subsystem-level
  *  @suspend() has returned, so that it doesn't do any I/O or DMA.
  *  Subsystem-level @suspend() is executed for all devices after invoking
  *  subsystem-level @prepare() for all of them.

(i.e. suspend() makes the device quiescent).

  * @suspend_late: Continue operations started by @suspend().  For a number of
  *  devices @suspend_late() may point to the same callback routine as the
  *  runtime suspend callback.

(suggests suspend_late() be assigned to the same function as runtime
suspend).

As for why, my understanding is like so:

For ->suspend(), we use the DRM helper, which disables the CRTC.
Normally disabling the CRTC would be enough to also invoke our
pm_runtime callback to do the final clock disable etc., however when a
system suspend is in-progress, the core forcibly takes a runtime
reference on all devices - preventing any pm_runtime paths from
running.

This means that after the CRTC is disabled in ->suspend(), our normal
pm_runtime path will not be invoked, and so the things done in
malidp_runtime_pm_suspend() will never happen.

We were just following the advice in the kernel-doc to deal with this.

The alternative would be to call malidp_runtime_pm_{suspend,resume}
from the "not late" hooks, but I'd ask why?


Also, you still haven't explained what exactly the dependency is.


Because there isn't one :-)

Thanks,
-Brian


-Daniel



> >> > ---
> >> >  drivers/gpu/drm/arm/malidp_drv.c | 17 +
> >> >  1 file changed, 17 insertions(+)
> >> >
> >> > diff --git a/drivers/gpu/drm/arm/malidp_drv.c 
b/drivers/gpu/drm/arm/malidp_drv.c
> >> > index bd44a6d..f6124d8 100644
> >> > --- a/drivers/gpu/drm/arm/malidp_drv.c
> >> > +++ b/drivers/gpu/drm/arm/malidp_drv.c
> >> > @@ -766,8 +766,25 @@ static int __maybe_unused malidp_pm_resume(struct 
device *dev)
> >> > return 0;
> >> >  }
> >> >
> >> > +static int __maybe_unused malidp_pm_suspend_late(struct device *dev)
> >> > +{
> >> > +   if (!pm_runtime_status_suspended(dev)) {
> >> > +   malidp_runtime_pm_suspend(dev);
> >> > +   pm_runtime_set_suspended(dev);
> >> > +   }
> >> > +   return 0;
> >> > +}
> >> > +
> >> > +static int __maybe_unused malidp_pm_resume_early(struct device *dev)
> >> > +{
> >> > +   malidp_runtime_pm_resume(dev);
> >> > +   

[Bug 199319] Flickering screen on AMDGPU and DC with Linux 4.16-2

[bugzilla-daemon]

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

zxvfxwing (zxvfxw...@protonmail.com) changed:

   What|Removed |Added

 CC||zxvfxw...@protonmail.com

--- Comment #11 from zxvfxwing (zxvfxw...@protonmail.com) ---
Flickering here too: 4.16.0-2-ARCH, RX480, Mesa 18.0.0, x11 (X.Org 1.19.6).

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

Re: [Freedreno] [DPU PATCH 1/2] drm/msm/dsi: check video mode engine status before waiting

[Jordan Crouse]

On Sat, Apr 07, 2018 at 12:50:04AM -0700, Abhinav Kumar wrote:
> Make sure the video mode engine is on before waiting
> for the video done interrupt.
> 
> Otherwise it leads to silent timeouts increasing display
> turn ON time.
> 
> Signed-off-by: Abhinav Kumar 
> ---
>  drivers/gpu/drm/msm/dsi/dsi_host.c | 14 ++
>  1 file changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
> b/drivers/gpu/drm/msm/dsi/dsi_host.c
> index 7a03a94..24766c3 100644
> --- a/drivers/gpu/drm/msm/dsi/dsi_host.c
> +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
> @@ -173,6 +173,7 @@ struct msm_dsi_host {
>  
>   bool registered;
>   bool power_on;
> + bool enabled;
>   int irq;
>  };
>  
> @@ -986,13 +987,18 @@ static void dsi_set_tx_power_mode(int mode, struct 
> msm_dsi_host *msm_host)
>  
>  static void dsi_wait4video_done(struct msm_dsi_host *msm_host)
>  {
> + u32 ret = 0;
> +
>   dsi_intr_ctrl(msm_host, DSI_IRQ_MASK_VIDEO_DONE, 1);
>  
>   reinit_completion(_host->video_comp);
>  
> - wait_for_completion_timeout(_host->video_comp,
> + ret = wait_for_completion_timeout(_host->video_comp,
>   msecs_to_jiffies(70));
>  
> + if (ret <= 0)
> + pr_err("wait for video done failed\n");
> +

Does this need to be rate limited? How often will it print?  Also, 'wait for
video done timed out" would be more descriptive for the situation.  I'm not sure
from the context if you have a pr_fmt defined for this file but if you don't you
might want to add the appropriate prefixes (or use dev_err) so the reader can
get a bit more detailed information about where to look and what is going on.

Jordan
-- 
The 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: clarify adjusted_mode documentation for bridges

[Philippe Cornu]

This patch clarifies the adjusted_mode documentation
for bridges.

Signed-off-by: Philippe Cornu 
Signed-off-by: Laurent Pinchart 
---
This patch follows discussions in:
- "drm: clarify adjusted_mode for a bridge connected to a crtc"
  https://patchwork.freedesktop.org/patch/206801/
- "drm: bridge: Constify mode arguments to bridge .mode_set() operation"
  https://patchwork.freedesktop.org/patch/215449/

 include/drm/drm_bridge.h | 16 
 include/drm/drm_crtc.h   | 11 +++
 2 files changed, 23 insertions(+), 4 deletions(-)

diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index 3270fec46979..7d632c6a9214 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -178,6 +178,22 @@ struct drm_bridge_funcs {
 * then this would be _encoder_helper_funcs.mode_set. The display
 * pipe (i.e.  clocks and timing signals) is off when this function is
 * called.
+*
+* The adjusted_mode parameter corresponds to the mode output by the 
CRTC
+* for the first bridge in the chain. It can be different from the mode
+* parameter that contains the desired mode for the connector at the end
+* of the bridges chain, for instance when the first bridge in the chain
+* performs scaling. The adjusted mode is mostly useful for the first
+* bridge in the chain and is likely irrelevant for the other bridges.
+*
+* For atomic drivers the adjusted_mode is the mode stored in
+* _crtc_state.adjusted_mode.
+*
+* NOTE:
+*
+* If a need arises to store and access modes adjusted for other 
locations
+* than the connection between the CRTC and the first bridge, the DRM
+* framework will have to be extended with DRM bridge states.
 */
void (*mode_set)(struct drm_bridge *bridge,
 struct drm_display_mode *mode,
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index a2d81d2907a9..65f749a9e9d3 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -134,10 +134,13 @@ struct drm_crtc_state {
 *
 * Internal display timings which can be used by the driver to handle
 * differences between the mode requested by userspace in @mode and what
-* is actually programmed into the hardware. It is purely driver
-* implementation defined what exactly this adjusted mode means. Usually
-* it is used to store the hardware display timings used between the
-* CRTC and encoder blocks.
+* is actually programmed into the hardware.
+*
+* For drivers using drm_bridge, this stores the hardware display 
timings
+* used between the CRTC and the first bridge. For other drivers, the
+* meaning of the adjusted_mode field is purely driver implementation
+* defined information, and will usually be used to store the hardware
+* display timings used between the CRTC and encoder blocks.
 */
struct drm_display_mode adjusted_mode;
 
-- 
2.15.1

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

Re: [PATCH 2/9] drm: Move simple_display_pipe prepare_fb helper into gem fb helpers

[David Lechner]

On 04/05/2018 10:44 AM, Daniel Vetter wrote:

There's nothing tinydrm specific to this, and there's a few more
copies of the same in various other drivers.

Signed-off-by: Daniel Vetter 
Cc: Gustavo Padovan 
Cc: Maarten Lankhorst 
Cc: Sean Paul 
Cc: David Airlie 
Cc: David Lechner 
Cc: "Noralf Trønnes" 
Cc: Daniel Vetter 
Cc: Shawn Guo 
Cc: Neil Armstrong 
Cc: Daniel Stone 
Cc: Haneen Mohammed 
Cc: Ben Widawsky 
Cc: "Ville Syrjälä" 
---


Acked-by: David Lechner 


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

[PATCH v3 3/3] drm/msm/dsi: replace version checks with helper functions

[Sibi Sankar]

Replace version checks with the helper functions bound to
cfg_handler for DSI v2, DSI 6G 1.x and DSI 6G v2.0+ controllers

Signed-off-by: Sibi Sankar 
---
 drivers/gpu/drm/msm/dsi/dsi_host.c | 242 +
 1 file changed, 29 insertions(+), 213 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 46e992f706d8..d82e673a1c7e 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -426,19 +426,6 @@ static int dsi_clk_init(struct msm_dsi_host *msm_host)
goto exit;
}
 
-   if (cfg_hnd->major == MSM_DSI_VER_MAJOR_6G &&
-   cfg_hnd->minor >= MSM_DSI_6G_VER_MINOR_V2_2_1) {
-   msm_host->byte_intf_clk = msm_clk_get(pdev, "byte_intf");
-   if (IS_ERR(msm_host->byte_intf_clk)) {
-   ret = PTR_ERR(msm_host->byte_intf_clk);
-   pr_err("%s: can't find byte_intf clock. ret=%d\n",
-   __func__, ret);
-   goto exit;
-   }
-   } else {
-   msm_host->byte_intf_clk = NULL;
-   }
-
msm_host->byte_clk_src = clk_get_parent(msm_host->byte_clk);
if (!msm_host->byte_clk_src) {
ret = -ENODEV;
@@ -453,31 +440,8 @@ static int dsi_clk_init(struct msm_dsi_host *msm_host)
goto exit;
}
 
-   if (cfg_hnd->major == MSM_DSI_VER_MAJOR_V2) {
-   msm_host->src_clk = msm_clk_get(pdev, "src");
-   if (IS_ERR(msm_host->src_clk)) {
-   ret = PTR_ERR(msm_host->src_clk);
-   pr_err("%s: can't find src clock. ret=%d\n",
-   __func__, ret);
-   msm_host->src_clk = NULL;
-   goto exit;
-   }
-
-   msm_host->esc_clk_src = clk_get_parent(msm_host->esc_clk);
-   if (!msm_host->esc_clk_src) {
-   ret = -ENODEV;
-   pr_err("%s: can't get esc clock parent. ret=%d\n",
-   __func__, ret);
-   goto exit;
-   }
-
-   msm_host->dsi_clk_src = clk_get_parent(msm_host->src_clk);
-   if (!msm_host->dsi_clk_src) {
-   ret = -ENODEV;
-   pr_err("%s: can't get src clock parent. ret=%d\n",
-   __func__, ret);
-   }
-   }
+   if (cfg_hnd->ops->clk_init_ver)
+   ret = cfg_hnd->ops->clk_init_ver(msm_host);
 exit:
return ret;
 }
@@ -681,16 +645,6 @@ int dsi_link_clk_enable_v2(struct msm_dsi_host *msm_host)
return ret;
 }
 
-static int dsi_link_clk_enable(struct msm_dsi_host *msm_host)
-{
-   const struct msm_dsi_cfg_handler *cfg_hnd = msm_host->cfg_hnd;
-
-   if (cfg_hnd->major == MSM_DSI_VER_MAJOR_6G)
-   return dsi_link_clk_enable_6g(msm_host);
-   else
-   return dsi_link_clk_enable_v2(msm_host);
-}
-
 void dsi_link_clk_disable_6g(struct msm_dsi_host *msm_host)
 {
clk_disable_unprepare(msm_host->esc_clk);
@@ -708,24 +662,6 @@ void dsi_link_clk_disable_v2(struct msm_dsi_host *msm_host)
clk_disable_unprepare(msm_host->byte_clk);
 }
 
-static void dsi_link_clk_disable(struct msm_dsi_host *msm_host)
-{
-   const struct msm_dsi_cfg_handler *cfg_hnd = msm_host->cfg_hnd;
-
-   if (cfg_hnd->major == MSM_DSI_VER_MAJOR_6G) {
-   clk_disable_unprepare(msm_host->esc_clk);
-   clk_disable_unprepare(msm_host->pixel_clk);
-   if (msm_host->byte_intf_clk)
-   clk_disable_unprepare(msm_host->byte_intf_clk);
-   clk_disable_unprepare(msm_host->byte_clk);
-   } else {
-   clk_disable_unprepare(msm_host->pixel_clk);
-   clk_disable_unprepare(msm_host->src_clk);
-   clk_disable_unprepare(msm_host->esc_clk);
-   clk_disable_unprepare(msm_host->byte_clk);
-   }
-}
-
 int dsi_calc_clk_rate_6g(struct msm_dsi_host *msm_host)
 {
struct drm_display_mode *mode = msm_host->mode;
@@ -804,73 +740,6 @@ int dsi_calc_clk_rate_v2(struct msm_dsi_host *msm_host)
return 0;
 }
 
-static int dsi_calc_clk_rate(struct msm_dsi_host *msm_host)
-{
-   struct drm_display_mode *mode = msm_host->mode;
-   const struct msm_dsi_cfg_handler *cfg_hnd = msm_host->cfg_hnd;
-   u8 lanes = msm_host->lanes;
-   u32 bpp = dsi_get_bpp(msm_host->format);
-   u32 pclk_rate;
-
-   if (!mode) {
-   pr_err("%s: mode not set\n", __func__);
-   return -EINVAL;
-   }
-
-   pclk_rate = mode->clock * 1000;
-   if (lanes > 0) {
-   msm_host->byte_clk_rate = (pclk_rate * bpp) / (8 * lanes);
-   } else {
-   pr_err("%s: forcing mdss_dsi lanes to 1\n", __func__);
-   

[PATCH v3 2/3] drm/msm/dsi: add implementation for helper functions

[Sibi Sankar]

Add dsi host helper function implementation for DSI v2
DSI 6G 1.x and DSI 6G v2.0+ controllers

Signed-off-by: Sibi Sankar 
---
 drivers/gpu/drm/msm/dsi/dsi.h  |  15 +++
 drivers/gpu/drm/msm/dsi/dsi_cfg.c  |  56 --
 drivers/gpu/drm/msm/dsi/dsi_host.c | 218 -
 3 files changed, 278 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index 80be83e8fdec..dfa049d876bd 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -183,6 +183,21 @@ int msm_dsi_host_modeset_init(struct mipi_dsi_host *host,
 int msm_dsi_host_init(struct msm_dsi *msm_dsi);
 int msm_dsi_runtime_suspend(struct device *dev);
 int msm_dsi_runtime_resume(struct device *dev);
+int dsi_link_clk_enable_6g(struct msm_dsi_host *msm_host);
+int dsi_link_clk_enable_v2(struct msm_dsi_host *msm_host);
+void dsi_link_clk_disable_6g(struct msm_dsi_host *msm_host);
+void dsi_link_clk_disable_v2(struct msm_dsi_host *msm_host);
+int dsi_tx_buf_alloc_6g(struct msm_dsi_host *msm_host, int size);
+int dsi_tx_buf_alloc_v2(struct msm_dsi_host *msm_host, int size);
+void *dsi_tx_buf_get_6g(struct msm_dsi_host *msm_host);
+void *dsi_tx_buf_get_v2(struct msm_dsi_host *msm_host);
+void dsi_tx_buf_put_6g(struct msm_dsi_host *msm_host);
+int dsi_dma_base_get_6g(struct msm_dsi_host *msm_host, uint64_t *iova);
+int dsi_dma_base_get_v2(struct msm_dsi_host *msm_host, uint64_t *iova);
+int dsi_clk_init_v2(struct msm_dsi_host *msm_host);
+int dsi_clk_init_6g_v2(struct msm_dsi_host *msm_host);
+int dsi_calc_clk_rate_v2(struct msm_dsi_host *msm_host);
+int dsi_calc_clk_rate_6g(struct msm_dsi_host *msm_host);
 
 /* dsi phy */
 struct msm_dsi_phy;
diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.c 
b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
index 0327bb54b01b..dcdfb1bb54f9 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
@@ -136,20 +136,58 @@ static const struct msm_dsi_config sdm845_dsi_cfg = {
.num_dsi = 2,
 };
 
+const static struct msm_dsi_host_cfg_ops msm_dsi_v2_host_ops = {
+   .link_clk_enable = dsi_link_clk_enable_v2,
+   .link_clk_disable = dsi_link_clk_disable_v2,
+   .clk_init_ver = dsi_clk_init_v2,
+   .tx_buf_alloc = dsi_tx_buf_alloc_v2,
+   .tx_buf_get = dsi_tx_buf_get_v2,
+   .tx_buf_put = NULL,
+   .dma_base_get = dsi_dma_base_get_v2,
+   .calc_clk_rate = dsi_calc_clk_rate_v2,
+};
+
+const static struct msm_dsi_host_cfg_ops msm_dsi_6g_host_ops = {
+   .link_clk_enable = dsi_link_clk_enable_6g,
+   .link_clk_disable = dsi_link_clk_disable_6g,
+   .clk_init_ver = NULL,
+   .tx_buf_alloc = dsi_tx_buf_alloc_6g,
+   .tx_buf_get = dsi_tx_buf_get_6g,
+   .tx_buf_put = dsi_tx_buf_put_6g,
+   .dma_base_get = dsi_dma_base_get_6g,
+   .calc_clk_rate = dsi_calc_clk_rate_6g,
+};
+
+const static struct msm_dsi_host_cfg_ops msm_dsi_6g_v2_host_ops = {
+   .link_clk_enable = dsi_link_clk_enable_6g,
+   .link_clk_disable = dsi_link_clk_disable_6g,
+   .clk_init_ver = dsi_clk_init_6g_v2,
+   .tx_buf_alloc = dsi_tx_buf_alloc_6g,
+   .tx_buf_get = dsi_tx_buf_get_6g,
+   .tx_buf_put = dsi_tx_buf_put_6g,
+   .dma_base_get = dsi_dma_base_get_6g,
+   .calc_clk_rate = dsi_calc_clk_rate_6g,
+};
+
 static const struct msm_dsi_cfg_handler dsi_cfg_handlers[] = {
-   {MSM_DSI_VER_MAJOR_V2, MSM_DSI_V2_VER_MINOR_8064, _dsi_cfg},
+   {MSM_DSI_VER_MAJOR_V2, MSM_DSI_V2_VER_MINOR_8064,
+   _dsi_cfg, _dsi_v2_host_ops},
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_0,
-   _apq8084_dsi_cfg},
+   _apq8084_dsi_cfg, _dsi_6g_host_ops},
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_1,
-   _apq8084_dsi_cfg},
+   _apq8084_dsi_cfg, _dsi_6g_host_ops},
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_1_1,
-   _apq8084_dsi_cfg},
+   _apq8084_dsi_cfg, _dsi_6g_host_ops},
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_2,
-   _apq8084_dsi_cfg},
-   {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_3, _dsi_cfg},
-   {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_3_1, _dsi_cfg},
-   {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_4_1, _dsi_cfg},
-   {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V2_2_1, _dsi_cfg},
+   _apq8084_dsi_cfg, _dsi_6g_host_ops},
+   {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_3,
+   _dsi_cfg, _dsi_6g_host_ops},
+   {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_3_1,
+   _dsi_cfg, _dsi_6g_host_ops},
+   {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_4_1,
+   _dsi_cfg, _dsi_6g_host_ops},
+   {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V2_2_1,
+   _dsi_cfg, 

[PATCH v3 0/3] Cleanup excessive DSI host controller version checks

[Sibi Sankar]

This patch series aims to create and bind dsi host controller helper
functions to functionalities that vary across DSI v2, DSI 6G 1.x and
DSI 6G v2.0+ controllers. These functionalities are currently under
excessive version checks which is now replaced with the corresponding
helper function.

V3:
  Removed redundant mode checks in calc_clk_rate_6g/v2
  Removed dev->struct_mutex unlock in tx_buf_alloc_6g
  Use msm_gem_kernel_new in tx_buf_alloc_6g 
  Modified author to first name/last name format

V2:
  Removes command broadcast support for DSI 6G v2.0+ controllers from
  the patch series and incorporates all the suggested corrections

Sibi Sankar (3):
  drm/msm/dsi: add dsi host helper functions support
  drm/msm/dsi: add implementation for helper functions
  drm/msm/dsi: replace version checks with helper functions

 drivers/gpu/drm/msm/dsi/dsi.h  |  16 ++
 drivers/gpu/drm/msm/dsi/dsi_cfg.c  |  56 +-
 drivers/gpu/drm/msm/dsi/dsi_cfg.h  |  12 ++
 drivers/gpu/drm/msm/dsi/dsi_host.c | 356 -
 4 files changed, 268 insertions(+), 172 deletions(-)

-- 
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 v3 1/3] drm/msm/dsi: add dsi host helper functions support

[Sibi Sankar]

Add dsi host helper functions support for DSI v2 and DSI 6G 1.x
controllers that are under version checks

Signed-off-by: Sibi Sankar 
---
 drivers/gpu/drm/msm/dsi/dsi.h |  1 +
 drivers/gpu/drm/msm/dsi/dsi_cfg.h | 12 
 2 files changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index 70d9a9a47acd..80be83e8fdec 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -149,6 +149,7 @@ static inline int msm_dsi_pll_set_usecase(struct 
msm_dsi_pll *pll,
 #endif
 
 /* dsi host */
+struct msm_dsi_host;
 int msm_dsi_host_xfer_prepare(struct mipi_dsi_host *host,
const struct mipi_dsi_msg *msg);
 void msm_dsi_host_xfer_restore(struct mipi_dsi_host *host,
diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.h 
b/drivers/gpu/drm/msm/dsi/dsi_cfg.h
index 9cfdcf1c95d5..a795a062b779 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_cfg.h
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.h
@@ -40,10 +40,22 @@ struct msm_dsi_config {
const int num_dsi;
 };
 
+struct msm_dsi_host_cfg_ops {
+   int (*link_clk_enable)(struct msm_dsi_host *msm_host);
+   void (*link_clk_disable)(struct msm_dsi_host *msm_host);
+   int (*clk_init_ver)(struct msm_dsi_host *msm_host);
+   int (*tx_buf_alloc)(struct msm_dsi_host *msm_host, int size);
+   void* (*tx_buf_get)(struct msm_dsi_host *msm_host);
+   void (*tx_buf_put)(struct msm_dsi_host *msm_host);
+   int (*dma_base_get)(struct msm_dsi_host *msm_host, uint64_t *iova);
+   int (*calc_clk_rate)(struct msm_dsi_host *msm_host);
+};
+
 struct msm_dsi_cfg_handler {
u32 major;
u32 minor;
const struct msm_dsi_config *cfg;
+   const struct msm_dsi_host_cfg_ops *ops;
 };
 
 const struct msm_dsi_cfg_handler *msm_dsi_cfg_get(u32 major, u32 minor);
-- 
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

[Bug 104602] [apitrace] Graphical artifacts in Civilization VI on RX Vega

[bugzilla-daemon]

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

--- Comment #7 from Zach Tibbitts  ---
This issue is also persisting with the latest update to Civ VI, including the
Rise and Fall expansion.

-- 
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 198883] amdgpu: carrizo: Screen stalls after starting X

[bugzilla-daemon]

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

--- Comment #80 from Andrey Grodzovsky (andrey.grodzov...@amd.com) ---
(In reply to Ricardo Ribalda from comment #79)
> Hi Jerome
> 
> Not really, I am waiting for some feedback from Andrey. 
> 
> 
> With the env. variable:
> 
> GALLIUM_DDEBUG=flush
> 
> it works better, but still not perfect. 
> 
> Andrey, did you managed to replicate the issue? I can send you a root file
> system.
> 
> 
> Regards!

Unfortunately I have been side tracked by more prioritized issues, I definitely
will get to this, it's on my TODO list.

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

Re: GPU/DRM issue with DSI commands on msm 8916

[Archit Taneja]

On Monday 09 April 2018 04:28 PM, Daniel Mack wrote:

Hi Archit,

Thanks a lot for your reply.

On Friday, April 06, 2018 01:25 PM, Archit Taneja wrote:

On Thursday 05 April 2018 08:28 PM, Daniel Mack wrote:

I'm having issues with the GPU/DRM drivers on a msm8916 based platform
which is very similar to the DragonBoard 410c. In my setup, a DSI
display is directly connected to the SoC, and the video link is stable.

However, when the host sends DCS commands down to the DSI panel (for
instance to set the backlight brightness), the image drops out, most of
the time only in terms of a short flicker, but sometimes it will
completely kill the image. In the latter case, only restarting the
Wayland compositor in userspace helps. This is also quite reproducible;
sending a NOP command once a second would give a visual flicker in 90%
of the cases, and it needs at most a minute to make the screen turn black.

The interesting thing is that this used to work in a v4.9 based version,
but it broke somewhere on the way to v4.14. Unfortunately, the platform
does not boot a vanilla kernel, so I can't really bisect this. We
currently depend on the Linaro downstream patches which can be found here:


The major change that happened between qcomlt-4.9 and qcomlt-4.14 from a
DSI point of view was probably the addition of runtime PM support.

The register configurations that are responsible for interleaving DCS
commands while video mode is still on should be the same.


Yeah, I think so too. I compared a lot of code but couldn't really find
anything either. At least, the command buffer contents and lengths are
identical.


You could comment out the pm_runtime_put_sync() calls in
drivers/gpu/drm/msm/dsi/dsi_host.c, in case some registers got
reset during put_sync and weren't restored correctly after get_sync().


That was my first suspicion too, but unfortunately, that's not the culprit.


I think it would be good to comment out the put_sync() calls in
drivers/gpu/drm/msm/mdp/mdp5/mdp5_mdss.c and 
drivers/gpu/drm/msm/msm_drv.c too, since there is a parent-child 
hierarchy between DSI

and the top level MDSS block. Commenting out the put_syncs() just
in put_sync() might still result in the MDSS GDSC to switch off.




Does your device initialize a splash screen in the bootloader?


It does, but that's the case for either of the two kernels. Do you think
that matters? And as you mention it - I'm building the driver as module,
because when built into the kernel, the msm driver fails to initialize
the hardware, and the console is flooded with the following message:


The bootloader may have configured some additional registers that the
DSI driver in the kernel doesn't touch. On 4.9, these registers would
have retained their state since we don't do any PM stuff. On 4.14, these
registers would probably lose their state, which results in a difference
in behavior. This can be avoided by commenting all the put_sync() calls
as mentioned above.



[   63.356837] dsi_err_worker: status=4


You could also compare the reg dumps between 4.9 and 4.14 by enabling
the config CONFIG_DRM_MSM_REGISTER_LOGGING and check if there are
any register configuration differences between the two.


I did that, and there a quite a number of changes, mostly because the
KMS bits have changed a lot. Given that I'm not too familiar with this
driver stack, I'm not sure what exactly to look at.


Mostly to check if there were any changes in the DSI register writes,
and maybe writes to the MDP5 INTF blocks.




One (rather unlikely) possibility I can think of is if somehow the
buffers used to send/receive DCS commands aren't mapped/unmapped
correctly. There have been some msm_gem changes, and the IOMMU driver
is new. That's the main reason why I'm wondering if the contents of the
DCS buffers somehow got corrupt.


That may well be, but I can't really see what's wrong in that area.
Which iommu driver are you referring to, exactly?


On 4.9, this driver is used:
drivers/iommu/qcom

On 4.14 we use:
drivers/iommu/qcom_iommu.c



Is the panel initialized using DCS
commands too?


Yes, and that works. The thing is that the commands do in fact reach the
panel and cause the desired effect, it's just that as a side effect, the
display very likely drops out when a command is sent. The registers that
are modified through msm_writel() by and between
msm_dsi_host_xfer_prepare() and msm_dsi_host_xfer_restore() are exactly
the same though. So it must be that some other part (the GPU or the
KMS?) doesn't like the fact that the DSI core mangles with the hardware
state in some way.


It seems unlikely that sending a DCS command via DSI core would affect
MDP or the GPU. It feels like sending the DCS commands is causing the
DSI lanes to be temporarily in an invalid state, resulting in the
flicker.



What hardware are all these changes developed and tested on, btw? I
guess it might be worth looking into differences between these platforms
and my own.


The releases are mostly tested 

Re: [PATCH v2 0/5] allow override of bus format in bridges

[Laurent Pinchart]

Hi Peter,

On Monday, 9 April 2018 10:04:05 EEST Peter Rosin wrote:
> On 2018-04-04 14:35, Peter Rosin wrote:
> > On 2018-04-04 11:07, Laurent Pinchart wrote:
> >> On Wednesday, 4 April 2018 09:34:41 EEST Daniel Vetter wrote:
> >>> On Wed, Apr 4, 2018 at 12:28 AM, Laurent Pinchart wrote:
>  On Wednesday, 28 March 2018 10:08:26 EEST Daniel Vetter wrote:
> > On Mon, Mar 26, 2018 at 11:24:42PM +0200, Peter Rosin wrote:
> >> Hi!
> >> 
> >> [I got to v2 sooner than expected]
> >> 
> >> I have an Atmel sama5d31 hooked up to an lvds encoder and then
> >> on to an lvds panel. Which seems like something that has been
> >> done one or two times before...
> >> 
> >> The problem is that the bus_format of the SoC and the panel do
> >> not agree. The SoC driver (atmel-hlcdc) can handle the
> >> rgb444, rgb565, rgb666 and rgb888 bus formats. The hardware is
> >> wired for the rgb565 case. The lvds encoder supports rgb888 on
> >> its input side with the LSB wires for each color simply pulled
> >> down internally in the encoder in my case which means that the
> >> rgb565 bus_format is the format that works best. And the panel
> >> is expecting lvds (vesa-24), which is what the encoder outputs.
> >> 
> >> The reason I "blame" the bus_format of the drm_connector is that
> >> with the below DT snippet, things do not work *exactly* due to
> >> that. At least, it starts to work if I hack the panel-lvds driver
> >> to report the rgb565 bus_format instead of vesa-24.
> >> 
> >> panel: panel {
> >> compatible = "panel-lvds";
> >> 
> >> width-mm = <304>;
> >> height-mm = <228;
> >> 
> >> data-mapping = "vesa-24";
> >> 
> >> panel-timing {
> >> // 1024x768 @ 60Hz (typical)
> >> clock-frequency = <5214 6500 7110>;
> >> hactive = <1024>;
> >> vactive = <768>;
> >> hfront-porch = <48 88 88>;
> >> hback-porch = <96 168 168>;
> >> hsync-len = <32 64 64>;
> >> vfront-porch = <8 13 14>;
> >> vback-porch = <8 13 14>;
> >> vsync-len = <8 12 14>;
> >> };
> >> 
> >> port {
> >> panel_input: endpoint {
> >> remote-endpoint = <_encoder_output>;
> >> };
> >> };
> >> };
> >> 
> >> lvds-encoder {
> >> compatible = "ti,ds90c185", "lvds-encoder";
> >> 
> >> ports {
> >> #address-cells = <1>;
> >> #size-cells = <0>;
> >> 
> >> port@0 {
> >> reg = <0>;
> >> 
> >> lvds_encoder_input: endpoint {
> >> remote-endpoint =
> >> <_output>;
> >> };
> >> };
> >> 
> >> port@1 {
> >> reg = <1>;
> >> 
> >> lvds_encoder_output: endpoint {
> >> remote-endpoint = <_input>;
> >> };
> >> };
> >> };
> >> };
> >> 
> >> But, instead of perverting the panel-lvds driver with support
> >> for a totally fake non-lvds bus_format, I intruduce an API that
> >> allows display controller drivers to query the required bus_format of
> >> any intermediate bridges, and match up with that instead of the
> >> formats given by the drm_connector. I trigger this with this addition
> >> to the lvds-encoder DT node:
> >> interface-pix-fmt = "rgb565";
> >> 
> >> Naming is hard though, so I'm not sure if that's good?
> >> 
> >> I threw in the first patch, since that is the actual lvds encoder
> >> I have in this case.
> >> 
> >> Suggestions welcome.
> > 
> > Took a quick look, feels rather un-atomic. And there's beend
> > discussing for other bridge related state that we might want to track
> > (like the full adjusted_mode that might need to be adjusted at each
> > stage in the chain). So here's my suggestions:
> > 
> > - Add an optional per-bridge internal state struct using the support
> >   in https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#handling-> 
> > >   driver-private-state
> >   
> >   Yes it 

[Bug 199101] AMDGPU Fury X random screen flicker on Linux kernel 4.16rc5

[bugzilla-daemon]

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

Sergey Kondakov (virtuous...@gmail.com) changed:

   What|Removed |Added

 CC||virtuous...@gmail.com

--- Comment #16 from Sergey Kondakov (virtuous...@gmail.com) ---
(In reply to Harry Wentland from comment #15)
> We reproduced the issue and have someone looking into it.

Too bad a fix doesn't seem to be included in 4.16.1. I myself got this on RX
580 (but on old FX-6100 / PCI-e v.2 system), wasn't able to revert commit above
and just resorted to disabling DC with amdgpu.dc=0 boot option.

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

[Bug 104602] [apitrace] Graphical artifacts in Civilization VI on RX Vega

[bugzilla-daemon]

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

--- Comment #6 from Jason Playne  ---
Can Confirm that this problem still persists on Kernel 4.16.1 and Mesa 18

-- 
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 3/4] drm/virtio: remove drm_dev_set_unique workaround

[Emil Velikov]

On 9 April 2018 at 11:24, Emil Velikov  wrote:
> On 9 April 2018 at 09:26, Daniel Vetter  wrote:
>
>>>  - point drm_device::dev to the parent of the virtio_device
>>> The biggest hack imaginable, if even possible.
>>
>> What would/could break if we do this? Why is this a hack?
>
> It _feels_ very hacky to reach/store the parent of the _parent_ device given.
> Dummy grep for \ showed hundreds of entries, but many of those
> are unrelated.
> Will give it a closer look - might not be as bad, as I originally thought.
>
Here are the side-effects:

Semantic changes
* using the wrong device for i2c - via drm_dp_add_port
* passing the wrong device to framebuffer_alloc - via drm_fb_helper_alloc_fbi
* using the wrong parent device to drm_gem_prime_import_dev

Visual
* printing the wrong device on DRM_DEV_ERROR, dev_info, drm_printer, etc

Needs a pdev_to_virtio() since we have the struct
virtio_device::struct device::struct device parent - via
virtio_gpu_driver_load

One, might get away with the above, by introducing drm_device::device
bus_device, or alike.
That one is used solely for the unique magic :-\

It sounds tad dirty, so I'm leaning with just commenting it. Open to
alternative suggestions though.

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

[Bug 199319] Flickering screen on AMDGPU and DC with Linux 4.16-2

[bugzilla-daemon]

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

--- Comment #10 from Mike Lothian (m...@fireburn.co.uk) ---
I should add this is 4.16-rc7 (agd5f's 4.18-wip branch) Qt 5.10, KDE frameworks
5.44, Plasma 5.12.4, Xorg 1.19.5 using the modesetting DDX (I'll try the Intel
& AMDGPU DDXs tonight.

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

[Bug 199319] Flickering screen on AMDGPU and DC with Linux 4.16-2

[bugzilla-daemon]

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

Mike Lothian (m...@fireburn.co.uk) changed:

   What|Removed |Added

 CC||m...@fireburn.co.uk

--- Comment #9 from Mike Lothian (m...@fireburn.co.uk) ---
I'm seeing this too, also plasma-wayland but with a PRIME Skylake/Tonga setup
only Skylake is used on the desktop

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

[Bug 105950] radeonsi: OpenCL not working correctly on a big endian machine

[bugzilla-daemon]

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

--- Comment #2 from Bas Vermeulen  ---
Created attachment 138698
  --> https://bugs.freedesktop.org/attachment.cgi?id=138698=edit
Patch for dispatch_packet endianness 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

[Bug 105950] radeonsi: OpenCL not working correctly on a big endian machine

[bugzilla-daemon]

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

--- Comment #1 from Bas Vermeulen  ---
Created attachment 138697
  --> https://bugs.freedesktop.org/attachment.cgi?id=138697=edit
Patch for si_vgt_param_key endian 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

[Bug 105589] [CI] igt@kms_chamelium@* - fail - Failed assertion: !chamelium->env.fault_occurred - Last errno: 101, Network is unreachable (kms_chamelium:2833) igt_chamelium-CRITICAL: Chamelium RPC cal

[bugzilla-daemon]

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

Marta Löfstedt  changed:

   What|Removed |Added

  Component|DRM/Intel   |IGT
   Assignee|intel-gfx-bugs@lists.freede |dri-devel@lists.freedesktop
   |sktop.org   |.org
 QA Contact|intel-gfx-bugs@lists.freede |
   |sktop.org   |

-- 
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 105950] radeonsi: OpenCL not working correctly on a big endian machine

[bugzilla-daemon]

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

Bug ID: 105950
   Summary: radeonsi: OpenCL not working correctly on a big endian
machine
   Product: Mesa
   Version: 17.3
  Hardware: PowerPC
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: b...@daedalean.ai
QA Contact: dri-devel@lists.freedesktop.org

Running any OpenCL program on a big endian machine using a radeonsi card fails.

- union si_vgt_param_key uses a bitfield shared with a 32 bit value. This
causes the index to be wrong on a big endian machine, and crashes any OpenCL
program with a segfault.
- si_setup_user_sgprs_co_v2 in si_compute.c fills a dispatch_packet struct with
values which are uploaded to the GPU. To ensure this works correctly, these
values need to be converted to little endian.

I'll send patches to the mesa-dev list for both these issues.

Bas Vermeulen

-- 
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 3/4] drm/virtio: remove drm_dev_set_unique workaround

[Emil Velikov]

On 9 April 2018 at 09:26, Daniel Vetter  wrote:

>>  - point drm_device::dev to the parent of the virtio_device
>> The biggest hack imaginable, if even possible.
>
> What would/could break if we do this? Why is this a hack?

It _feels_ very hacky to reach/store the parent of the _parent_ device given.
Dummy grep for \ showed hundreds of entries, but many of those
are unrelated.
Will give it a closer look - might not be as bad, as I originally thought.

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

Re: [PATCH v7 1/2] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[Mark Brown]

On Fri, Apr 06, 2018 at 06:40:14PM +0300, Laurent Pinchart wrote:
> On Friday, 6 April 2018 17:25:58 EEST jacopo mondi wrote:

> > Same on the mandatory/optional VCC supply thing. Let's try to make
> > next version the final one. If the optional property with the dummy
> > regulator doesn't satisfy you and it is preferred to have a fixed-regulator
> > anyhow in DT I'll do in next version, othewise let's try not to change
> > it again. I'll just remark here that in the current Eagle design vcc is
> > connected to a power rail with no regulator at all :)

> I don't like the dummy regulator much, as it generates a dev_warn(), which 
> makes me believe that it's a hack rather than a proper solution. You might 
> want to ask Mark Brown for his opinion.

The DT should describe the physical supplies the device needs, if that's
a fixed regulator with no software control then the DT should have a
fixed regulator with no software control.


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

Re: [PATCH] drm: bridge: Constify mode arguments to bridge .mode_set() operation

[Laurent Pinchart]

Hi Daniel,

On Monday, 9 April 2018 12:18:28 EEST Daniel Vetter wrote:
> On Mon, Apr 09, 2018 at 11:56:55AM +0300, Laurent Pinchart wrote:
> > On Monday, 9 April 2018 11:53:07 EEST Daniel Vetter wrote:
> >> On Fri, Apr 06, 2018 at 07:23:57PM +0300, Laurent Pinchart wrote:
> >>> The mode and ajusted_mode passed to the bridge .mode_set() operation
> >>> should never be modified by the bridge (and are not in any of the
> >>> existing bridge drivers). Make them const to make this clear.
> >>> 
> >>> Signed-off-by: Laurent Pinchart
> >> > 
> >> 
> >> Why should the adjusted_mode not be modified?
> > 
> > Why should it ? .mode_set() performs a mode set, mode adjustment should be
> > performed in .mode_fixup().
> 
> Oh right, totally missed that you're only touching the ->mode_set
> callbacks. Assuming gcc is happy (not going to check for that, too lazy):
> 
> Reviewed-by: Daniel Vetter 

I've compile-tested this patch for all the drivers it touches and gcc didn't 
complain. I'll give 0day a few days to give it a go too, just in case.

> >>> ---
> >>> 
> >>>  drivers/gpu/drm/bridge/adv7511/adv7511.h   |  4 ++--
> >>>  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c   |  8 
> >>>  drivers/gpu/drm/bridge/adv7511/adv7533.c   |  2 +-
> >>>  drivers/gpu/drm/bridge/analogix-anx78xx.c  |  4 ++--
> >>>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |  4 ++--
> >>>  drivers/gpu/drm/bridge/sii902x.c   |  4 ++--
> >>>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c  |  4 ++--
> >>>  drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c  | 16 ---
> >>>  drivers/gpu/drm/bridge/tc358767.c  |  9 +
> >>>  drivers/gpu/drm/drm_bridge.c   |  4 ++--
> >>>  drivers/gpu/drm/exynos/exynos_drm_mic.c|  4 ++--
> >>>  drivers/gpu/drm/mediatek/mtk_hdmi.c|  4 ++--
> >>>  drivers/gpu/drm/msm/dsi/dsi.h  |  2 +-
> >>>  drivers/gpu/drm/msm/dsi/dsi_host.c |  2 +-
> >>>  drivers/gpu/drm/msm/dsi/dsi_manager.c  |  4 ++--
> >>>  drivers/gpu/drm/msm/edp/edp_bridge.c   |  4 ++--
> >>>  drivers/gpu/drm/msm/hdmi/hdmi_bridge.c |  4 ++--
> >>>  drivers/gpu/drm/rcar-du/rcar_lvds.c|  4 ++--
> >>>  drivers/gpu/drm/sti/sti_dvo.c  |  4 ++--
> >>>  drivers/gpu/drm/sti/sti_hda.c  |  4 ++--
> >>>  drivers/gpu/drm/sti/sti_hdmi.c |  4 ++--
> >>>  drivers/gpu/drm/stm/dw_mipi_dsi-stm.c  |  2 +-
> >>>  include/drm/bridge/dw_mipi_dsi.h   |  3 ++-
> >>>  include/drm/drm_bridge.h   |  8 
> >>>  24 files changed, 57 insertions(+), 55 deletions(-)
> >>> 
> >>> Philippe,
> >>> 
> >>> I wrote this patch while reviewing your adjusted_mode documentation. I
> >>> initially wanted to document the fact that the adjusted_mode argument
> >>> to the bridge .mode_set() operation should not be modified by the
> >>> bridge, and then realized that constifying it would be a better way to
> >>> express that. I thus wouldn't mind if you took that patch in your tree
> >>> and pushed it with the documentation patch once we get the necessary
> >>> acks :-)

-- 
Regards,

Laurent Pinchart



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

Re: AMD graphics performance regression in 4.15 and later

[Christian König]

Am 07.04.2018 um 00:00 schrieb Jean-Marc Valin:

Hi Christian,

Thanks for the info. FYI, I've also opened a Firefox bug for that at:
https://bugzilla.mozilla.org/show_bug.cgi?id=1448778
Feel free to comment since you have a better understanding of what's
going on.

One last question: right now I'm running 4.15.0 with the "offending"
patch reverted. Is that safe to run or are there possible bad
interactions with other changes.


That should work without problems.

But I just had another idea as well, if you want you could still test 
the new code path which will be using in 4.17.


Backporting all the detection logic is to invasive, but you could just 
go into drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c and forcefull use the 
other code path.


Just look out for "#ifdef CONFIG_SWIOTLB" checks and disable those.

Regards,
Christian.



Cheers,

Jean-Marc

On 04/06/2018 01:20 PM, Christian König wrote:

Am 06.04.2018 um 18:42 schrieb Jean-Marc Valin:

Hi Christian,

On 04/09/2018 07:48 AM, Christian König wrote:

Am 06.04.2018 um 17:30 schrieb Jean-Marc Valin:

Hi Christian,

Is there a way to turn off these huge pages at boot-time/run-time?

Only at compile time by not setting CONFIG_TRANSPARENT_HUGEPAGE.

Any reason why
echo never > /sys/kernel/mm/transparent_hugepage/enabled
doesn't solve the problem?

Because we unfortunately try to allocate huge pages anyway, we
unfortunately just fail in 100% of all cases.

That basically gives you both, the extra allocation overhead and the
still bad throughput.


Also, I assume that disabling CONFIG_TRANSPARENT_HUGEPAGE will disable
them for everything and not just what your patch added, right?

Correct, that's why I wrote that disabling SWIOTLBs might be better.


I'm not sure what you mean by "We mitigated the problem by avoiding the
slow coherent DMA code path on almost all platforms on newer
kernels". I
tested up to 4.16 and the performance regression is just as bad as
it is
for 4.15.

Indeed 4.16 still doesn't have that. You could use the
amd-staging-drm-next branch or wait for 4.17.

Is there a way to pull just that change or is there too much
interactions with other changes?

It adds a new detection if memory allocation needs to be coherent or
not, that is not something you can easily pull into older versions.


That isn't related to the GFX hardware, but to your CPU/motherboard and
whatever else you have in the system.

Well, I have an nvidia GPU in the same system (normally only used for
CUDA) and if I use it instead of my RX 560 then I'm not seeing any
performance issue with 4.15.

That's because you are probably using the Nvidia binary driver which has
a completely separate code base.


Some part of your system needs SWIOTLB and that makes allocating memory
much slower.

What would that part be? FTR, I have a complete description of my system
at https://jmvalin.dreamwidth.org/15583.html

I don't know if it's related, but I can maybe see one thing in common
between my machine and the Core 2 Quad from the other bug report and
that's the "NUMA part". I have a dual-socket Xeon and (AFAIK) the Core 2
Quad is made of two two-core CPUs glued together with little
communication between them.

Yeah, that is probably the reason.


Intel doesn't use TTM because they don't have dedicated VRAM, but the
open source nvidia driver should be affected as well.

I'm using the proprietary nvidia driver (because CUDA). Is that supposed
to be affected as well?

No.


We already mitigated that problem and I don't see any solution which
will arrive faster than 4.17.

Is that supposed to make the slowdown unnoticeable or just slightly
better?

It completely goes away. The issue with the coherent path is that it
tries to always allocate the lowest possible memory to make sure that it
fits into the DMA constrains of all devices in the system.

But since AMD GPU can handle 40bits of addresses you would need at least
1TB of memory in the system to trigger that (or a NUMA where some system
is low and some in a high area).

Christian.


The only quick workaround I can see is to avoid firefox, chrome for
example is reported to work perfectly fine.

Or use an unaffected GPU/driver ;-)

Cheers,

 Jean-Marc


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


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

[Bug 199319] Flickering screen on AMDGPU and DC with Linux 4.16-2

[bugzilla-daemon]

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

--- Comment #8 from m...@rainer-finke.de ---
The random flickering every 30 seconds is the same from my point of view. What
is different on my setup is that Plasma-Wayland with night shift enabled with a
changed color flickers with every mouse movement since Linux 4.16. So the
answer is partially.

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

Re: [PATCH 0/7] sunxi: Add DT representation for the MBUS controller

[Maxime Ripard]

Hi Rob,

On Tue, Apr 03, 2018 at 11:03:30AM -0500, Rob Herring wrote:
> On Tue, Apr 3, 2018 at 8:29 AM, Maxime Ripard  
> wrote:
> > Hi,
> >
> > We've had for quite some time to hack around in our drivers to take into
> > account the fact that our DMA accesses are not done through the parent
> > node, but through another bus with a different mapping than the CPU for the
> > RAM (0 instead of 0x4000 for most SoCs).
> >
> > After some discussion after the submission of a camera device suffering of
> > the same hacks, I've decided to put together a serie that introduce a
> > property called dma-parent that allows to express the DMA relationship
> > between a master and its bus, even if they are not direct parents in the DT.
> 
> Reading thru v6 of the camera driver, it seems like having
> intermediate buses would solve the problem in your case?

I guess it would yes, but I guess it wouldn't model the hardware
properly since this seems to be really a bus only meant to do DMA, and
you're not accessing the registers of the device through that bus.

And as far as I know, the DT implies that the topology is the one of
the "control" side of the devices.

We'll also need eventually to have retrieve the MBUS endpoints ID to
be able to support perf and PM QoS properly.

> As Arnd mentioned in that thread, something new needs to address all
> the deficiencies with dma-ranges and describing DMA bus topologies.
> This doesn't address the needs of describing bus interconnects.
> There's been some efforts by the QCom folks with an interconnect
> binding. They've mostly punted (for now at least) to not describing
> the whole interconnect in DT and keeping the details in a driver.

Is it that patch serie? https://lkml.org/lkml/2018/3/9/856

> On the flip side, this does mirror the established pattern used by
> interrupts, so maybe it's okay on it's own. I'll wait for others to
> comment.

We'll see how it turns out then :)

Maxime

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


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

Re: [PATCH] drm: bridge: Constify mode arguments to bridge .mode_set() operation

[Daniel Vetter]

On Mon, Apr 09, 2018 at 11:56:55AM +0300, Laurent Pinchart wrote:
> On Monday, 9 April 2018 11:53:07 EEST Daniel Vetter wrote:
> > On Fri, Apr 06, 2018 at 07:23:57PM +0300, Laurent Pinchart wrote:
> > > The mode and ajusted_mode passed to the bridge .mode_set() operation
> > > should never be modified by the bridge (and are not in any of the
> > > existing bridge drivers). Make them const to make this clear.
> > > 
> > > Signed-off-by: Laurent Pinchart
> > > 
> > 
> > Why should the adjusted_mode not be modified?
> 
> Why should it ? .mode_set() performs a mode set, mode adjustment should be 
> performed in .mode_fixup().

Oh right, totally missed that you're only touching the ->mode_set
callbacks. Assuming gcc is happy (not going to check for that, too lazy):

Reviewed-by: Daniel Vetter 

> 
> > 
> > > ---
> > > 
> > >  drivers/gpu/drm/bridge/adv7511/adv7511.h   |  4 ++--
> > >  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c   |  8 
> > >  drivers/gpu/drm/bridge/adv7511/adv7533.c   |  2 +-
> > >  drivers/gpu/drm/bridge/analogix-anx78xx.c  |  4 ++--
> > >  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |  4 ++--
> > >  drivers/gpu/drm/bridge/sii902x.c   |  4 ++--
> > >  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c  |  4 ++--
> > >  drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c  | 16 
> > >  drivers/gpu/drm/bridge/tc358767.c  |  9 +
> > >  drivers/gpu/drm/drm_bridge.c   |  4 ++--
> > >  drivers/gpu/drm/exynos/exynos_drm_mic.c|  4 ++--
> > >  drivers/gpu/drm/mediatek/mtk_hdmi.c|  4 ++--
> > >  drivers/gpu/drm/msm/dsi/dsi.h  |  2 +-
> > >  drivers/gpu/drm/msm/dsi/dsi_host.c |  2 +-
> > >  drivers/gpu/drm/msm/dsi/dsi_manager.c  |  4 ++--
> > >  drivers/gpu/drm/msm/edp/edp_bridge.c   |  4 ++--
> > >  drivers/gpu/drm/msm/hdmi/hdmi_bridge.c |  4 ++--
> > >  drivers/gpu/drm/rcar-du/rcar_lvds.c|  4 ++--
> > >  drivers/gpu/drm/sti/sti_dvo.c  |  4 ++--
> > >  drivers/gpu/drm/sti/sti_hda.c  |  4 ++--
> > >  drivers/gpu/drm/sti/sti_hdmi.c |  4 ++--
> > >  drivers/gpu/drm/stm/dw_mipi_dsi-stm.c  |  2 +-
> > >  include/drm/bridge/dw_mipi_dsi.h   |  3 ++-
> > >  include/drm/drm_bridge.h   |  8 
> > >  24 files changed, 57 insertions(+), 55 deletions(-)
> > > 
> > > Philippe,
> > > 
> > > I wrote this patch while reviewing your adjusted_mode documentation. I
> > > initially wanted to document the fact that the adjusted_mode argument to
> > > the bridge .mode_set() operation should not be modified by the bridge,
> > > and then realized that constifying it would be a better way to express
> > > that. I thus wouldn't mind if you took that patch in your tree and
> > > pushed it with the documentation patch once we get the necessary acks
> > > 
> > > :-)
> > > 
> > > diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h
> > > b/drivers/gpu/drm/bridge/adv7511/adv7511.h index
> > > d034b2cb5eee..f60d29defd18 100644
> > > --- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
> > > +++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
> > > @@ -389,7 +389,7 @@ static inline int adv7511_cec_init(struct device *dev,
> > > struct adv7511 *adv7511)> 
> > >  #ifdef CONFIG_DRM_I2C_ADV7533
> > >  void adv7533_dsi_power_on(struct adv7511 *adv);
> > >  void adv7533_dsi_power_off(struct adv7511 *adv);
> > > 
> > > -void adv7533_mode_set(struct adv7511 *adv, struct drm_display_mode
> > > *mode);
> > > +void adv7533_mode_set(struct adv7511 *adv, const struct drm_display_mode
> > > *mode);> 
> > >  int adv7533_patch_registers(struct adv7511 *adv);
> > >  int adv7533_patch_cec_registers(struct adv7511 *adv);
> > >  int adv7533_attach_dsi(struct adv7511 *adv);
> > > 
> > > @@ -405,7 +405,7 @@ static inline void adv7533_dsi_power_off(struct
> > > adv7511 *adv)> 
> > >  }
> > >  
> > >  static inline void adv7533_mode_set(struct adv7511 *adv,
> > > 
> > > - struct drm_display_mode *mode)
> > > + const struct drm_display_mode *mode)
> > > 
> > >  {
> > >  }
> > > 
> > > diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > > b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c index
> > > efa29db5fc2b..99028d36ed74 100644
> > > --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > > +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > > @@ -664,8 +664,8 @@ static int adv7511_mode_valid(struct adv7511 *adv7511,
> > > 
> > >  }
> > >  
> > >  static void adv7511_mode_set(struct adv7511 *adv7511,
> > > 
> > > -  struct drm_display_mode *mode,
> > > -  struct drm_display_mode *adj_mode)
> > > +  const struct drm_display_mode 

Re: DRM_UDL and GPU under Xserver

[Daniel Vetter]

On Mon, Apr 09, 2018 at 08:55:36AM +, Alexey Brodkin wrote:
> Hi Daniel,
> 
> On Mon, 2018-04-09 at 10:31 +0200, Daniel Vetter wrote:
> > On Thu, Apr 05, 2018 at 06:39:41PM +, Alexey Brodkin wrote:
> > > Hi Daniel, all,
> 
> [snip]
> 
> > > Ok it was quite some time ago so I forgot about that completely.
> > > I really made one trivial change in xf86-video-armada:
> > > >8--
> > > --- a/src/armada_module.c
> > > +++ b/src/armada_module.c
> > > @@ -26,7 +26,7 @@
> > >  #define ARMADA_NAME"armada"
> > >  #define ARMADA_DRIVER_NAME "armada"
> > >  
> > > -#define DRM_MODULE_NAMES   "armada-drm", "imx-drm"
> > > +#define DRM_MODULE_NAMES   "armada-drm", "imx-drm", "udl"
> > >  #define DRM_DEFAULT_BUS_ID NULL
> > > >8--
> > > 
> > > Otherwise Xserver fails on start which is expected given "imx-drm" is 
> > > intentionally removed.
> 
> Here I meant I explicitly disabled DRM_IMX in the kernel configuraion
> so that it is not used in run-time.
> 
> > You need to keep imx-drm around. And then light up the udl display using
> > prime. Afaiui it should all just work (but with maybe a few disconnected
> > outputs from imx-drm around that you don't need, but that's not a
> > problem).
> 
> And given my comment above I don't really see any difference between
> DRM_IMX and DRM_UDL (except their HW implmentation which I guess should
> not bother upper layers) so why do wee need to treat them differently?
> 
> Most probably I'm missing something but my thought was if we have
> 2 equally well supported KMS devices we may easily swap them and still
> have resulting setup functional.

armada is not a generic drm driver, but can only be used for armada-drm
and imx-drm. You can't just use it with any drm device, for that you need
a generic driver like -modesetting.

Just enable all the drivers you have for your hw, and it should work.
Hacking on drivers without knowing what they expect tends to not work so
well.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/1] drm: Add crtc_queue_syncobj and crtc_get_syncobj ioctls

[Daniel Vetter]

On Fri, Apr 06, 2018 at 04:56:48PM -0700, Keith Packard wrote:
> (This is an RFC on whether this pair of ioctls seems reasonable. The
> code compiles, but I haven't tested it as I'm away from home this
> weekend.)
> 
> I'm rewriting my implementation of the Vulkan EXT_display_control
> extension, which provides a way to signal a Vulkan fence at vblank
> time. I had implemented it using events, but that isn't great as the
> Vulkan API includes the ability to wait for any of a set of fences to
> be signaled. As the other Vulkan fences are implemented using
> dma_fences in the kernel, and (eventually) using syncobj up in user
> space, it seems reasonable to use syncobjs for everything and hook
> vblank to those.
> 
> In any case, I'm proposing two new syncobj/vblank ioctls (the names
> aren't great; suggestions welcome, as usual):
> 
> DRM_IOCTL_CRTC_QUEUE_SYNCOBJ
> 
>   Create a new syncobj that will be signaled at (or after) the
>   specified vblank sequence value. This uses the same parameters
>   to specify the target sequence as
>   DRM_IOCTL_CRTC_QUEUE_SEQUENCE.

My understanding of drm_syncobj is that you:

- Create a syncobj with the drm_syncobj_create ioctl.

- Pass it around to various driver callbacks who update the attached
  dma_fence pointer using drm_syncobj_replace_fence().

Yes amdgpu does this a bit differently, but that seems to be the
exception.

From that pov I'd massage the uapi to just extend
drm_crtc_queue_sequence_ioctl with a new syncobj flag. Syncobj we can just
add at the bottom of struct drm_crtc_queue_sequence (drm structs can be
extended like that, it's part of the uapi). Or we reuse user_data, but
that's a bit a hack.

We also don't need a new event type, vblank code simply singals
event->fence, which we'll arrange to be the fence behind the syncobj.

> DRM_IOCTL_CRTC_GET_SYNCOBJ
> 
>   Once the above syncobj has been signaled, this ioctl allows
>   the application to find out when that happened, returning both
>   the vblank sequence count and time (in ns).

The android syncpt stuff already had the concept of a fence timestamp, and
we carried it over as part of struct dma_fence.timestamp. It's just not
exposed yet as proper uapi. I think we should aim a bit more into that
direction with something like the below sketch:

- Add a dma_fence_signal_ts, which allows us to set the timestamp from a
  hw clock.

- Use that in the vblank code.

- Add new drm_syncobj ioctl to query the timestamp of the attached fence
  (if it's signalled).

That would entirely avoid the special-case ioctl just for vblank syncobj
here. Also, this might be useful in your implementation of
VK_GOOGLE_display_timing, since the current query timestamp you're using
won't take into account irq wakeup latency. Using fence->timestamp will
still miss the irq->atomic worker wakupe latency, but should be a lot
better already.

> I'd like to hear comments on whether this seems reasonable, or whether
> I should go in some other direction.

Besides a few bikesheds to align better with other stuff going around I
think this looks good.
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: bridge: Constify mode arguments to bridge .mode_set() operation

[Laurent Pinchart]

On Monday, 9 April 2018 11:53:07 EEST Daniel Vetter wrote:
> On Fri, Apr 06, 2018 at 07:23:57PM +0300, Laurent Pinchart wrote:
> > The mode and ajusted_mode passed to the bridge .mode_set() operation
> > should never be modified by the bridge (and are not in any of the
> > existing bridge drivers). Make them const to make this clear.
> > 
> > Signed-off-by: Laurent Pinchart
> > 
> 
> Why should the adjusted_mode not be modified?

Why should it ? .mode_set() performs a mode set, mode adjustment should be 
performed in .mode_fixup().

> 
> > ---
> > 
> >  drivers/gpu/drm/bridge/adv7511/adv7511.h   |  4 ++--
> >  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c   |  8 
> >  drivers/gpu/drm/bridge/adv7511/adv7533.c   |  2 +-
> >  drivers/gpu/drm/bridge/analogix-anx78xx.c  |  4 ++--
> >  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |  4 ++--
> >  drivers/gpu/drm/bridge/sii902x.c   |  4 ++--
> >  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c  |  4 ++--
> >  drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c  | 16 
> >  drivers/gpu/drm/bridge/tc358767.c  |  9 +
> >  drivers/gpu/drm/drm_bridge.c   |  4 ++--
> >  drivers/gpu/drm/exynos/exynos_drm_mic.c|  4 ++--
> >  drivers/gpu/drm/mediatek/mtk_hdmi.c|  4 ++--
> >  drivers/gpu/drm/msm/dsi/dsi.h  |  2 +-
> >  drivers/gpu/drm/msm/dsi/dsi_host.c |  2 +-
> >  drivers/gpu/drm/msm/dsi/dsi_manager.c  |  4 ++--
> >  drivers/gpu/drm/msm/edp/edp_bridge.c   |  4 ++--
> >  drivers/gpu/drm/msm/hdmi/hdmi_bridge.c |  4 ++--
> >  drivers/gpu/drm/rcar-du/rcar_lvds.c|  4 ++--
> >  drivers/gpu/drm/sti/sti_dvo.c  |  4 ++--
> >  drivers/gpu/drm/sti/sti_hda.c  |  4 ++--
> >  drivers/gpu/drm/sti/sti_hdmi.c |  4 ++--
> >  drivers/gpu/drm/stm/dw_mipi_dsi-stm.c  |  2 +-
> >  include/drm/bridge/dw_mipi_dsi.h   |  3 ++-
> >  include/drm/drm_bridge.h   |  8 
> >  24 files changed, 57 insertions(+), 55 deletions(-)
> > 
> > Philippe,
> > 
> > I wrote this patch while reviewing your adjusted_mode documentation. I
> > initially wanted to document the fact that the adjusted_mode argument to
> > the bridge .mode_set() operation should not be modified by the bridge,
> > and then realized that constifying it would be a better way to express
> > that. I thus wouldn't mind if you took that patch in your tree and
> > pushed it with the documentation patch once we get the necessary acks
> > 
> > :-)
> > 
> > diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h
> > b/drivers/gpu/drm/bridge/adv7511/adv7511.h index
> > d034b2cb5eee..f60d29defd18 100644
> > --- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
> > +++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
> > @@ -389,7 +389,7 @@ static inline int adv7511_cec_init(struct device *dev,
> > struct adv7511 *adv7511)> 
> >  #ifdef CONFIG_DRM_I2C_ADV7533
> >  void adv7533_dsi_power_on(struct adv7511 *adv);
> >  void adv7533_dsi_power_off(struct adv7511 *adv);
> > 
> > -void adv7533_mode_set(struct adv7511 *adv, struct drm_display_mode
> > *mode);
> > +void adv7533_mode_set(struct adv7511 *adv, const struct drm_display_mode
> > *mode);> 
> >  int adv7533_patch_registers(struct adv7511 *adv);
> >  int adv7533_patch_cec_registers(struct adv7511 *adv);
> >  int adv7533_attach_dsi(struct adv7511 *adv);
> > 
> > @@ -405,7 +405,7 @@ static inline void adv7533_dsi_power_off(struct
> > adv7511 *adv)> 
> >  }
> >  
> >  static inline void adv7533_mode_set(struct adv7511 *adv,
> > 
> > -   struct drm_display_mode *mode)
> > +   const struct drm_display_mode *mode)
> > 
> >  {
> >  }
> > 
> > diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c index
> > efa29db5fc2b..99028d36ed74 100644
> > --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > @@ -664,8 +664,8 @@ static int adv7511_mode_valid(struct adv7511 *adv7511,
> > 
> >  }
> >  
> >  static void adv7511_mode_set(struct adv7511 *adv7511,
> > 
> > -struct drm_display_mode *mode,
> > -struct drm_display_mode *adj_mode)
> > +const struct drm_display_mode *mode,
> > +const struct drm_display_mode *adj_mode)
> > 
> >  {
> >  
> > unsigned int low_refresh_rate;
> > unsigned int hsync_polarity = 0;
> > 
> > @@ -827,8 +827,8 @@ static void adv7511_bridge_disable(struct drm_bridge
> > *bridge)> 
> >  }
> >  
> >  static void adv7511_bridge_mode_set(struct drm_bridge *bridge,
> > 
> > -   struct drm_display_mode *mode,
> > - 

Re: [PATCH] drm: bridge: Constify mode arguments to bridge .mode_set() operation

[Daniel Vetter]

On Fri, Apr 06, 2018 at 07:23:57PM +0300, Laurent Pinchart wrote:
> The mode and ajusted_mode passed to the bridge .mode_set() operation
> should never be modified by the bridge (and are not in any of the
> existing bridge drivers). Make them const to make this clear.
> 
> Signed-off-by: Laurent Pinchart 

Why should the adjusted_mode not be modified?
-Daniel

> ---
>  drivers/gpu/drm/bridge/adv7511/adv7511.h   |  4 ++--
>  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c   |  8 
>  drivers/gpu/drm/bridge/adv7511/adv7533.c   |  2 +-
>  drivers/gpu/drm/bridge/analogix-anx78xx.c  |  4 ++--
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |  4 ++--
>  drivers/gpu/drm/bridge/sii902x.c   |  4 ++--
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c  |  4 ++--
>  drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c  | 16 
>  drivers/gpu/drm/bridge/tc358767.c  |  9 +
>  drivers/gpu/drm/drm_bridge.c   |  4 ++--
>  drivers/gpu/drm/exynos/exynos_drm_mic.c|  4 ++--
>  drivers/gpu/drm/mediatek/mtk_hdmi.c|  4 ++--
>  drivers/gpu/drm/msm/dsi/dsi.h  |  2 +-
>  drivers/gpu/drm/msm/dsi/dsi_host.c |  2 +-
>  drivers/gpu/drm/msm/dsi/dsi_manager.c  |  4 ++--
>  drivers/gpu/drm/msm/edp/edp_bridge.c   |  4 ++--
>  drivers/gpu/drm/msm/hdmi/hdmi_bridge.c |  4 ++--
>  drivers/gpu/drm/rcar-du/rcar_lvds.c|  4 ++--
>  drivers/gpu/drm/sti/sti_dvo.c  |  4 ++--
>  drivers/gpu/drm/sti/sti_hda.c  |  4 ++--
>  drivers/gpu/drm/sti/sti_hdmi.c |  4 ++--
>  drivers/gpu/drm/stm/dw_mipi_dsi-stm.c  |  2 +-
>  include/drm/bridge/dw_mipi_dsi.h   |  3 ++-
>  include/drm/drm_bridge.h   |  8 
>  24 files changed, 57 insertions(+), 55 deletions(-)
> 
> Philippe,
> 
> I wrote this patch while reviewing your adjusted_mode documentation. I
> initially wanted to document the fact that the adjusted_mode argument to
> the bridge .mode_set() operation should not be modified by the bridge,
> and then realized that constifying it would be a better way to express
> that. I thus wouldn't mind if you took that patch in your tree and
> pushed it with the documentation patch once we get the necessary acks
> :-)
> 
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h 
> b/drivers/gpu/drm/bridge/adv7511/adv7511.h
> index d034b2cb5eee..f60d29defd18 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
> @@ -389,7 +389,7 @@ static inline int adv7511_cec_init(struct device *dev, 
> struct adv7511 *adv7511)
>  #ifdef CONFIG_DRM_I2C_ADV7533
>  void adv7533_dsi_power_on(struct adv7511 *adv);
>  void adv7533_dsi_power_off(struct adv7511 *adv);
> -void adv7533_mode_set(struct adv7511 *adv, struct drm_display_mode *mode);
> +void adv7533_mode_set(struct adv7511 *adv, const struct drm_display_mode 
> *mode);
>  int adv7533_patch_registers(struct adv7511 *adv);
>  int adv7533_patch_cec_registers(struct adv7511 *adv);
>  int adv7533_attach_dsi(struct adv7511 *adv);
> @@ -405,7 +405,7 @@ static inline void adv7533_dsi_power_off(struct adv7511 
> *adv)
>  }
>  
>  static inline void adv7533_mode_set(struct adv7511 *adv,
> - struct drm_display_mode *mode)
> + const struct drm_display_mode *mode)
>  {
>  }
>  
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c 
> b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> index efa29db5fc2b..99028d36ed74 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> @@ -664,8 +664,8 @@ static int adv7511_mode_valid(struct adv7511 *adv7511,
>  }
>  
>  static void adv7511_mode_set(struct adv7511 *adv7511,
> -  struct drm_display_mode *mode,
> -  struct drm_display_mode *adj_mode)
> +  const struct drm_display_mode *mode,
> +  const struct drm_display_mode *adj_mode)
>  {
>   unsigned int low_refresh_rate;
>   unsigned int hsync_polarity = 0;
> @@ -827,8 +827,8 @@ static void adv7511_bridge_disable(struct drm_bridge 
> *bridge)
>  }
>  
>  static void adv7511_bridge_mode_set(struct drm_bridge *bridge,
> - struct drm_display_mode *mode,
> - struct drm_display_mode *adj_mode)
> + const struct drm_display_mode *mode,
> + const struct drm_display_mode *adj_mode)
>  {
>   struct adv7511 *adv = bridge_to_adv7511(bridge);
>  
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7533.c 
> b/drivers/gpu/drm/bridge/adv7511/adv7533.c
> index 185b6d842166..5d5e7d9eded2 

[PATCH] drm/xen-front: use simple display pipe prepare_fb helper

[Daniel Vetter]

I missed this one because on an older tree.

Signed-off-by: Daniel Vetter 
Cc: Oleksandr Andrushchenko 
Cc: xen-de...@lists.xen.org
---
 drivers/gpu/drm/xen/xen_drm_front_kms.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/xen/xen_drm_front_kms.c 
b/drivers/gpu/drm/xen/xen_drm_front_kms.c
index 0bd6681fa4f3..a3479eb72d79 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_kms.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_kms.c
@@ -226,12 +226,6 @@ static bool display_send_page_flip(struct 
drm_simple_display_pipe *pipe,
return false;
 }
 
-static int display_prepare_fb(struct drm_simple_display_pipe *pipe,
- struct drm_plane_state *plane_state)
-{
-   return drm_gem_fb_prepare_fb(>plane, plane_state);
-}
-
 static void display_update(struct drm_simple_display_pipe *pipe,
   struct drm_plane_state *old_plane_state)
 {
@@ -294,7 +288,7 @@ static const struct drm_simple_display_pipe_funcs 
display_funcs = {
.mode_valid = display_mode_valid,
.enable = display_enable,
.disable = display_disable,
-   .prepare_fb = display_prepare_fb,
+   .prepare_fb = drm_gem_fb_simple_display_pipe_prepare_fb,
.update = display_update,
 };
 
-- 
2.16.2

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

Re: [PATCH 0/9] implicit fencing clarification

[Daniel Vetter]

On Fri, Apr 06, 2018 at 10:38:38AM +0300, Oleksandr Andrushchenko wrote:
> Hi, Daniel!
> 
> It seems that this series misses xen-front's
> "Use simple_display_pipe prepare_fb helper" change?

Hm indeed, I guess I was on an older tree. Will follow up. Care to review
the other patches meanwhile?
-Daniel

> 
> Thank you,
> Oleksandr
> 
> On 04/05/2018 06:44 PM, Daniel Vetter wrote:
> > Hi all,
> > 
> > Somewhat motivated (but only really tangentially) by the dirtyfb
> > discussion with Rob and Thomas I started digging around in the various
> > driver implementations for implicit vs. explicit fencing.
> > 
> > There's definitely a huge pile of drivers which don't do any implicit
> > fencing at all - not sure that's good or not. And for some of the drivers
> > with more history I think they don't correctly overwrite implicit fencing
> > when explicit fencing is present. At least I've gotten lost in the mazes
> > before I found positive proof.
> > 
> > So this is just the lower hanging stuff, plus a doc patch to hopefully
> > clarify this all better.
> > 
> > Comments and review and especially in the case of the msm/vc4 patches,
> > also testing, very much welcome.
> > 
> > Thanks, Daniel
> > 
> > Daniel Vetter (9):
> >drm/vmwgfx: Remove no-op prepare/cleanup_fb callbacks
> >drm: Move simple_display_pipe prepare_fb helper into gem fb helpers
> >drm/tve200: Use simple_display_pipe prepare_fb helper
> >drm/pl111: Use simple_display_pipe prepare_fb helper
> >drm/mxsfb: Use simple_display_pipe prepare_fb helper
> >drm/atomic: better doc for implicit vs explicit fencing
> >drm/gem-fb-helper: Always do implicit sync
> >drm/vc4: Always obey implicit sync
> >drm/msm: Always obey implicit fencing
> > 
> >   drivers/gpu/drm/drm_atomic.c |  8 +++
> >   drivers/gpu/drm/drm_gem_framebuffer_helper.c | 21 -
> >   drivers/gpu/drm/msm/msm_atomic.c |  2 +-
> >   drivers/gpu/drm/mxsfb/mxsfb_drv.c|  8 +--
> >   drivers/gpu/drm/pl111/pl111_display.c|  8 +--
> >   drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c  | 17 --
> >   drivers/gpu/drm/tinydrm/ili9225.c|  2 +-
> >   drivers/gpu/drm/tinydrm/mi0283qt.c   |  3 ++-
> >   drivers/gpu/drm/tinydrm/repaper.c|  2 +-
> >   drivers/gpu/drm/tinydrm/st7586.c |  2 +-
> >   drivers/gpu/drm/tinydrm/st7735r.c|  2 +-
> >   drivers/gpu/drm/tve200/tve200_display.c  |  8 +--
> >   drivers/gpu/drm/vc4/vc4_plane.c  | 11 +
> >   drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c  | 35 
> > 
> >   include/drm/drm_gem_framebuffer_helper.h |  3 +++
> >   include/drm/drm_modeset_helper_vtables.h |  5 +++-
> >   include/drm/drm_plane.h  |  7 +-
> >   include/drm/drm_simple_kms_helper.h  |  3 +++
> >   include/drm/tinydrm/tinydrm.h|  2 --
> >   19 files changed, 61 insertions(+), 88 deletions(-)
> > 
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/9] drm: Move simple_display_pipe prepare_fb helper into gem fb helpers

[Daniel Vetter]

On Fri, Apr 06, 2018 at 11:42:42AM +0200, Noralf Trønnes wrote:
> 
> Den 05.04.2018 17.44, skrev Daniel Vetter:
> > There's nothing tinydrm specific to this, and there's a few more
> > copies of the same in various other drivers.
> > 
> > Signed-off-by: Daniel Vetter 
> > Cc: Gustavo Padovan 
> > Cc: Maarten Lankhorst 
> > Cc: Sean Paul 
> > Cc: David Airlie 
> > Cc: David Lechner 
> > Cc: "Noralf Trønnes" 
> > Cc: Daniel Vetter 
> > Cc: Shawn Guo 
> > Cc: Neil Armstrong 
> > Cc: Daniel Stone 
> > Cc: Haneen Mohammed 
> > Cc: Ben Widawsky 
> > Cc: "Ville Syrjälä" 
> > ---
> >   drivers/gpu/drm/drm_gem_framebuffer_helper.c | 19 +++
> >   drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c  | 17 -
> >   drivers/gpu/drm/tinydrm/ili9225.c|  2 +-
> >   drivers/gpu/drm/tinydrm/mi0283qt.c   |  3 ++-
> >   drivers/gpu/drm/tinydrm/repaper.c|  2 +-
> >   drivers/gpu/drm/tinydrm/st7586.c |  2 +-
> >   drivers/gpu/drm/tinydrm/st7735r.c|  2 +-
> >   include/drm/drm_gem_framebuffer_helper.h |  3 +++
> >   include/drm/drm_simple_kms_helper.h  |  3 +++
> >   include/drm/tinydrm/tinydrm.h|  2 --
> >   10 files changed, 31 insertions(+), 24 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c 
> > b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> > index 4d682a6e8bcb..acfbc0641a06 100644
> > --- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> > +++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> > @@ -22,6 +22,7 @@
> >   #include 
> >   #include 
> >   #include 
> > +#include 
> >   /**
> >* DOC: overview
> > @@ -265,6 +266,24 @@ int drm_gem_fb_prepare_fb(struct drm_plane *plane,
> >   }
> >   EXPORT_SYMBOL_GPL(drm_gem_fb_prepare_fb);
> > +/**
> > + * drm_gem_fb_simple_display_pipe_prepare_fb - prepare_fb helper for
> > + * _simple_display_pipe
> > + * @pipe: Simple display pipe
> > + * @plane_state: Plane state
> > + *
> > + * This function uses drm_gem_fb_prepare_fb() to check if the plane FB has 
> > a
> > + * _buf attached, extracts the exclusive fence and attaches it to plane
> > + * state for the atomic helper to wait on. Drivers can use this as their
> > + * _simple_display_pipe_funcs.prepare_fb callback.
> > + */
> > +int drm_gem_fb_simple_display_pipe_prepare_fb(struct 
> > drm_simple_display_pipe *pipe,
> > + struct drm_plane_state 
> > *plane_state)
> > +{
> > +   return drm_gem_fb_prepare_fb(>plane, plane_state);
> > +}
> > +EXPORT_SYMBOL(drm_gem_fb_simple_display_pipe_prepare_fb);
> > +
> 
> I was suprised that you didn't put this function in drm_simple_kms_helper.c.
> Anyways, thanks for slimming down tinydrm.

It was a coin toss between that and the gem helpers. I tossed for gem :-)

> Reviewed-by: Noralf Trønnes 

Thanks for the review, I'll pull these all in once more acks/reviews have
shown up.
-Daniel

> 
> >   /**
> >* drm_gem_fbdev_fb_create - Create a GEM backed _framebuffer for 
> > fbdev
> >*   emulation
> > diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c 
> > b/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
> > index e68b528ae64d..7e8e24d0b7a7 100644
> > --- a/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
> > +++ b/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
> > @@ -138,23 +138,6 @@ void tinydrm_display_pipe_update(struct 
> > drm_simple_display_pipe *pipe,
> >   }
> >   EXPORT_SYMBOL(tinydrm_display_pipe_update);
> > -/**
> > - * tinydrm_display_pipe_prepare_fb - Display pipe prepare_fb helper
> > - * @pipe: Simple display pipe
> > - * @plane_state: Plane state
> > - *
> > - * This function uses drm_gem_fb_prepare_fb() to check if the plane FB has 
> > an
> > - * dma-buf attached, extracts the exclusive fence and attaches it to plane
> > - * state for the atomic helper to wait on. Drivers can use this as their
> > - * _simple_display_pipe_funcs->prepare_fb callback.
> > - */
> > -int tinydrm_display_pipe_prepare_fb(struct drm_simple_display_pipe *pipe,
> > -   struct drm_plane_state *plane_state)
> > -{
> > -   return drm_gem_fb_prepare_fb(>plane, plane_state);
> > -}
> > -EXPORT_SYMBOL(tinydrm_display_pipe_prepare_fb);
> > -
> >   static int tinydrm_rotate_mode(struct drm_display_mode *mode,
> >unsigned int rotation)
> >   {
> > diff --git a/drivers/gpu/drm/tinydrm/ili9225.c 
> > b/drivers/gpu/drm/tinydrm/ili9225.c
> > index 0874e877b111..841c69aba059 100644
> > --- a/drivers/gpu/drm/tinydrm/ili9225.c
> > +++ b/drivers/gpu/drm/tinydrm/ili9225.c
> > @@ -354,7 +354,7 @@ static const 

Re: [Intel-gfx] [PATCH 11/13] drm/omapdrm: Nuke omap_framebuffer_get_next_connector()

[Daniel Vetter]

On Fri, Apr 06, 2018 at 09:10:43AM +0300, Tomi Valkeinen wrote:
> On 05/04/18 19:50, Daniel Vetter wrote:
> > On Thu, Apr 05, 2018 at 06:13:58PM +0300, Ville Syrjala wrote:
> >> From: Ville Syrjälä 
> >>
> >> omap_framebuffer_get_next_connector() uses plane->fb which we want to
> >> deprecate for atomic drivers. As omap_framebuffer_get_next_connector()
> >> is unused just nuke the entire function.
> >>
> >> Cc: Tomi Valkeinen 
> >> Signed-off-by: Ville Syrjälä 
> > 
> > Yeah was slightly worried how to fix up this one, but we're lucky!
> > 
> > Reviewed-by: Daniel Vetter 
> 
> I tried to remove it just a week ago, but Sebastian said that it's used
> by a unmerged series about DSI command mode displays, so I dropped the
> patch.
> 
> In the unmerged series, it's used by omap_framebuffer_dirty() ([PATCHv3
> 3/8] drm/omap: add support for manually updated displays). So we have a
> framebuffer, and we want to know which crtcs need to be flushed.

You can't do that in atomic drivers.

You need to take appropriate locks and do the full ->state->fb deref.
Also, there's a gazillion of copies for generic framebuffer_dirty
implementations floating around, pleas try to coordinate with those.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 3/3] drm: Add helper to validate damage during modeset_check

[Daniel Vetter]

On Thu, Apr 05, 2018 at 11:55:29PM +, Deepak Singh Rawat wrote:
> > 
> > On Wed, Apr 04, 2018 at 04:49:08PM -0700, Deepak Rawat wrote:
> > > This patch adds a helper which should be called by driver which enable
> > > damage (by calling drm_plane_enable_damage_clips) from atomic_check
> > > hook. This helper for now set the damage to NULL for the planes on crtc
> > > which need full modeset.
> > >
> > > The driver also need to check for other crtc properties which can
> > > affect damage in atomic_check hook, like gamma, ctm, etc. Plane related
> > > properties which affect damage can be handled in damage iterator.
> > >
> > > Signed-off-by: Deepak Rawat 
> > > ---
> > >  drivers/gpu/drm/drm_atomic_helper.c | 47
> > +
> > >  include/drm/drm_atomic_helper.h |  2 ++
> > >  2 files changed, 49 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > > index 355b514..23f44ab 100644
> > > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > @@ -3987,3 +3987,50 @@ drm_atomic_helper_damage_iter_next(struct
> > drm_atomic_helper_damage_iter *iter,
> > >   return true;
> > >  }
> > >  EXPORT_SYMBOL(drm_atomic_helper_damage_iter_next);
> > > +
> > > +/**
> > > + * drm_atomic_helper_check_damage - validate state object for damage
> > changes
> > > + * @dev: DRM device
> > > + * @state: the driver state object
> > > + *
> > > + * Check the state object if damage is required or not. In case damage is
> > not
> > > + * required e.g. need modeset, the damage blob is set to NULL.
> > 
> > Why is that needed?
> > 
> > I can imagine that drivers unconditionally upload everything for a
> > modeset, and hence don't need special damage tracking. But for that it's
> > imo better to have a clear_damage() helper.
> 
> Don't we need a generic helper which all drivers can use to see if anything
> in drm_atomic_state will result in full update? My intention for calling that
> function from atomic_check hook was because state access can
> return -EDEADLK.
> 
> I think for now having drm_damage_helper_clear_damage helper and 
> calling it from atomic_check seems better option. In future once I have
> clear idea, a generic function can be done.

Yeah, if some of the future helpers need to e.g. allocate memory, then we
need to do any necessary prep steps from ->atomic_check.

But this isn't just prep, it clears stuff, so giving it a name that
indicates better what it does seems like a good idea to me. Just make it
clear that this should be called from ->atomic_check callbacks.

> > But even for modesets (e.g. resolution changes) I'd expect that virtual
> > drivers don't want to upload unecessary amounts of data. Manual upload
> > hw drivers probably need to upload everything, because the panel will have
> > forgotten all the old data once power cycled.
> 
> AFAIK current vmwgfx will do full upload for resolution change.
> 
> > 
> > And if you think this is really the right thing, then we need to rename
> > the function to tell what it does, e.g.
> > 
> > drm_damage_helper_clear_damage_on_modeset()
> > 
> > drm_damage_helper because I think we should stuff this all into
> > drm_damage_helper.c, see previous patch.
> > 
> > But I think a
> > 
> > drm_damage_helper_clear_damage(crtc_state)
> > 
> > which you can use in your crtc->atomic_check function like
> > 
> > crtc_atomic_check(state)
> > {
> > if (drm_atomic_crtc_needs_modeset(state))
> > drm_damage_helper_clear_damage(state);
> > }
> > 
> > is more flexible and useful for drivers. There might be other cases where
> > clearing damage is the right thing to do. Also, there's the question of
> > whether no damage clips == full damage or not, so maybe we should call
> > this helper full_damage() instead.
> 
> In my opinion if via proper documentation it is conveyed that no damage
> means full-update the clear_damage makes sense.

Documentation is the worst documentation. Function names, or just outright
implemented behaviour is much better (e.g. runtime checks). For full
damage if there's no clip rect I think the iterator should implement that
for us.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 1/3] drm: Add DAMAGE_CLIPS property to plane

[Daniel Vetter]

On Thu, Apr 05, 2018 at 11:07:19PM +, Deepak Singh Rawat wrote:
> > 
> > On Wed, Apr 04, 2018 at 04:49:06PM -0700, Deepak Rawat wrote:
> > > From: Lukasz Spintzyk 
> > >
> > > Optional plane property to mark damaged regions on the plane in
> > > framebuffer coordinates of the framebuffer attached to the plane.
> > >
> > > The layout of blob data is simply an array of drm_mode_rect with
> > maximum
> > > array size limited by DRM_MODE_FB_DIRTY_MAX_CLIPS. Unlike plane src
> > > coordinates, damage clips are not in 16.16 fixed point.
> > >
> > > Damage clips are a hint to kernel as which area of framebuffer has
> > > changed since last page-flip. This should be helpful for some drivers
> > > especially for virtual devices where each framebuffer change needs to
> > > be transmitted over network, usb, etc.
> > >
> > > Driver which are interested in enabling DAMAGE_CLIPS property for a
> > > plane should enable this property using drm_plane_enable_damage_clips.
> > >
> > > Signed-off-by: Lukasz Spintzyk 
> > > Signed-off-by: Deepak Rawat 
> > 
> > The property uapi section is missing, see:
> > 
> > https://urldefense.proofpoint.com/v2/url?u=https-
> > 3A__dri.freedesktop.org_docs_drm_gpu_drm-2Dkms.html-23plane-
> > 2Dcomposition-
> > 2Dproperties=DwIBAg=uilaK90D4TOVoH58JNXRgQ=zOOG28inJK0762
> > SxAf-
> > cyZdStnd2NQpRu98lJP2iYGw=ELAUsNTjD0ICwUEDFjPW4jsmy2A5AkhS5Q
> > z_3vlEC9Q=nH-HNXPczoJQMj1iwHiGfrhXz4-00b0M8-3kirjm-EY=
> > 
> > Plane composition feels like the best place to put this. Please use that
> > section to tie all the various bits together, including the helpers you're
> > adding in the following patches for drivers to use.
> > 
> > Bunch of nitpicks below, but overall I'm agreeing now with just going with
> > fb coordinate damage rects.
> > 
> > Like you say, the thing needed here now is userspace + driver actually
> > implementing this. I'd also say the compat helper to map the legacy
> > fb->dirty to this new atomic way of doing things should be included here
> > (gives us a lot more testing for these new paths).
> > 
> > Icing on the cake would be an igt to make sure kernel rejects invalid clip
> > rects correctly.
> > 
> > > ---
> > >  drivers/gpu/drm/drm_atomic.c| 42
> > +
> > >  drivers/gpu/drm/drm_atomic_helper.c |  4 
> > >  drivers/gpu/drm/drm_mode_config.c   |  5 +
> > >  drivers/gpu/drm/drm_plane.c | 12 +++
> > >  include/drm/drm_mode_config.h   | 15 +
> > >  include/drm/drm_plane.h | 16 ++
> > >  include/uapi/drm/drm_mode.h | 15 +
> > >  7 files changed, 109 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_atomic.c
> > b/drivers/gpu/drm/drm_atomic.c
> > > index 7d25c42..9226d24 100644
> > > --- a/drivers/gpu/drm/drm_atomic.c
> > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > @@ -669,6 +669,40 @@ static void drm_atomic_crtc_print_state(struct
> > drm_printer *p,
> > >  }
> > >
> > >  /**
> > > + * drm_atomic_set_damage_for_plane - sets the damage clips property
> > to plane
> > > + * @state: plane state
> > > + * @blob: damage clips in framebuffer coordinates
> > > + *
> > > + * Returns:
> > > + *
> > > + * Zero on success, error code on failure.
> > > + */
> > > +static int drm_atomic_set_damage_for_plane(struct drm_plane_state
> > *state,
> > > +struct drm_property_blob *blob)
> > > +{
> > > + if (blob == state->damage_clips)
> > > + return 0;
> > > +
> > > + drm_property_blob_put(state->damage_clips);
> > > + state->damage_clips = NULL;
> > > +
> > > + if (blob) {
> > > + uint32_t count = blob->length/sizeof(struct drm_rect);
> > > +
> > > + if (count > DRM_MODE_FB_DIRTY_MAX_CLIPS)
> > > + return -EINVAL;
> > > +
> > > + state->damage_clips = drm_property_blob_get(blob);
> > > + state->num_clips = count;
> > > + } else {
> > > + state->damage_clips = NULL;
> > > + state->num_clips = 0;
> > > + }
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +/**
> > >   * drm_atomic_get_plane_state - get plane state
> > >   * @state: global atomic state object
> > >   * @plane: plane to get state object for
> > > @@ -793,6 +827,12 @@ static int drm_atomic_plane_set_property(struct
> > drm_plane *plane,
> > >   state->color_encoding = val;
> > >   } else if (property == plane->color_range_property) {
> > >   state->color_range = val;
> > > + } else if (property == config->prop_damage_clips) {
> > > + struct drm_property_blob *blob =
> > > + drm_property_lookup_blob(dev, val);
> > > + int ret = drm_atomic_set_damage_for_plane(state, blob);
> > 
> > There's already a helper with size-checking built-in, see
> > drm_atomic_replace_property_blob_from_id(). Wrt computing num_clips
> > I'd
> > just provide a little inline helper that 

Re: DRM_UDL and GPU under Xserver

[Daniel Vetter]

On Thu, Apr 05, 2018 at 06:39:41PM +, Alexey Brodkin wrote:
> Hi Daniel, all,
> 
> On Thu, 2018-04-05 at 15:44 +0200, Daniel Vetter wrote:
> > On Thu, Apr 05, 2018 at 11:10:03AM +, Alexey Brodkin wrote:
> > > Hi Daniel, Lucas,
> > > 
> > > On Thu, 2018-04-05 at 12:59 +0200, Daniel Vetter wrote:
> > > > On Thu, Apr 5, 2018 at 12:29 PM, Lucas Stach  
> > > > wrote:
> > > > > Am Donnerstag, den 05.04.2018, 11:32 +0200 schrieb Daniel Vetter:
> > > > > > On Thu, Apr 5, 2018 at 9:16 AM, Alexey Brodkin
> > > > > >  wrote:
> > > > > > > Hi Daniel,
> > > > > > > 
> > > > > > > On Thu, 2018-04-05 at 08:18 +0200, Daniel Vetter wrote:
> > > > > > > > On Wed, Apr 4, 2018 at 10:06 PM, Alexey Brodkin
> > > > > > > >  wrote:
> > > > > > > > > Hello,
> > > > > > > > > 
> > > > > > > > > We're trying to use DisplayLink USB2-to-HDMI adapter to render
> > > > > > > > > GPU-accelerated graphics.
> > > > > > > > > Hardware setup is as simple as a devboard + DisplayLink
> > > > > > > > > adapter.
> > > > > > > > > Devboards we use for this experiment are:
> > > > > > > > >  * Wandboard Quad (based on IMX6 SoC with Vivante GPU) or
> > > > > > > > >  * HSDK (based on Synopsys ARC HS38 SoC with Vivante GPU as
> > > > > > > > > well)
> > > > > > > > > 
> > > > > > > > > I'm sure any other board with DRM supported GPU will work,
> > > > > > > > > those we just used
> > > > > > > > > as the very recent Linux kernels could be easily run on them
> > > > > > > > > both.
> > > > > > > > > 
> > > > > > > > > Basically the problem is UDL needs to be explicitly notified
> > > > > > > > > about new data
> > > > > > > > > to be rendered on the screen compared to typical bit-streamers
> > > > > > > > > that infinitely
> > > > > > > > > scan a dedicated buffer in memory.
> > > > > > > > > 
> > > > > > > > > In case of UDL there're just 2 ways for this notification:
> > > > > > > > >  1) DRM_IOCTL_MODE_PAGE_FLIP that calls drm_crtc_funcs-
> > > > > > > > > > page_flip()
> > > > > > > > > 
> > > > > > > > >  2) DRM_IOCTL_MODE_DIRTYFB that calls drm_framebuffer_funcs-
> > > > > > > > > > dirty()
> > > > > > > > > 
> > > > > > > > > But neither of IOCTLs happen when we run Xserver with xf86-
> > > > > > > > > video-armada driver
> > > > > > > > > (see 
> > > > > > > > > https://urldefense.proofpoint.com/v2/url?u=http-3A__git.ar
> > > > > > > > > m.linux.org.uk_cgit_xf86-2Dvideo-2Darmada.git_log_-3Fh-
> > > > > > > > > 3Dunstable-2Ddevel=DwIBaQ&;
> > > > > > > > > c=DPL6_X_6JkXFx7AXWqB0tg=lqdeeSSEes0GFDDl656eViXO7breS55ytWkh
> > > > > > > > > pk5R81I=oEAlP64L9vkuUs_k3kGwwwlN1WJbDMJbCo0uDhwKwwk=3ZHj-
> > > > > > > > > 6JXZBLSTWg_4KMnL0VNi7z8c0RxHzj2U5ywVIw=).
> > > > > > > > > 
> > > > > > > > > Is it something missing in Xserver or in UDL driver?
> > > > > > > > 
> > > > > > > > Use the -modesetting driverr for UDL, that one works correctly.
> > > > > > > 
> > > > > > > If you're talking about "modesetting" driver of Xserver [1] then
> > > > > > > indeed
> > > > > > > picture is displayed on the screen. But there I guess won't be any
> > > > > > > 3D acceleration.
> > > > > > > 
> > > > > > > At least that's what was suggested to me earlier here [2] by 
> > > > > > > Lucas:
> > > > > > > >8---
> > > > > > > For 3D acceleration to work under X you need the etnaviv specific
> > > > > > > DDX
> > > > > > > driver, which can be found here:
> > > > > > > 
> > > > > > > https://urldefense.proofpoint.com/v2/url?u=http-3A__git.arm.linux.org.uk_cgit_xf86-2Dvideo-2Darmada.git_log_-3Fh-3Dunsta=DwIBaQ=DPL6_X
> > > > > > > _6Jk
> > > > > > > XFx7AXWqB0tg=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I=FleDFAQb2lBcZk5DMld7qpeSrB5Srsb4XPQecA5BPvU=YUzMQWe3lpC_pjGqRjb4MvRYh16ZBbe
> > > > > > > alqf
> > > > > > > rywlqjKE=
> > > > > > > ble-devel
> > > > > > 
> > > > > > You definitely want to use -modesetting for UDL. And I thought with
> > > > > > glamour and the corresponding mesa work you should also get
> > > > > > accelaration. Insisting that you must use a driver-specific ddx is
> > > > > > broken, the world doesn't work like that anymore.
> > > > > 
> > > > > On etnaviv the world definitely still works like this. The etnaviv DDX
> > > > > uses the dedicated 2D hardware of the Vivante GPUs, which is much
> > > > > faster and efficient than going through Glamor.
> > > > > Especially since almost all X accel operations are done on linear
> > > > > buffers, while the 3D GPU can only ever do tiled on both sampler and
> > > > > render, where some multi-pipe 3D cores can't even read the tiling they
> > > > > write out. So Glamor is an endless copy fest using the resolve engine
> > > > > on those.
> > > > 
> > > > Ah right, I've forgotten about the vivante 2d cores again.
> > > > 
> > > > > If using etnaviv with UDL is a use-case that need to be supported, one
> > > > > would need to port the UDL specifics from -modesetting to the 

Re: [RFC 2/3] drm: Add helper iterator functions to iterate over plane damage.

[Daniel Vetter]

On Thu, Apr 05, 2018 at 11:59:57PM +, Deepak Singh Rawat wrote:
> > plane damage.
> > 
> > On 04/05/2018 09:52 AM, Daniel Vetter wrote:
> > >
> > > TYPE_PLANE I have no idea who needs that. I suggest we just drop it.
> > 
> > I'm assuming CRTC plane coordinates here. They are used for uploading
> > contents of hardware planes. Like, in the simplest case, cursor images.
> 
> Yes they are CRTC plane coordinates, so is TYPE_PLANE naming confusing ?
> And should be named to TYPE_CRTC_PLANE but then it is confusing with
> TYPE_CRTC.

Yeah, I think TYPE_PLANE is really confusing, and too much aimied at your
vmwgfx special case (where the virtual hw requires that this all lines up
properly). I think providing FB coordinates, and doing the vmwgfx-specific
remapping in vmwgfx code is better.

And someone else can then figure out how to handle CRTC overall damage for
physical devices. As mentioned by me (and Rob Clark too), most hw only
allows for 1 (or maybe 2) overall damage rects, so that helper would need
to combine all the damge rects into 1. Plus take stuff like
gamma/ctm/alpha into account too. Better we leave that to someone who
needs it.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers

[Daniel Vetter]

On Sat, Apr 07, 2018 at 11:34:57AM +0200, Hans de Goede wrote:
> Hi,
> 
> On 06-04-18 18:06, Ville Syrjälä wrote:
> > On Thu, Apr 05, 2018 at 01:37:31PM +0200, Hans de Goede wrote:
> > > Hi,
> > > 
> > > On 04-04-18 22:49, Ville Syrjälä wrote:
> > > > On Wed, Apr 04, 2018 at 10:06:29PM +0200, Hans de Goede wrote:
> > > > > Hi,
> > > > > 
> > > > > On 04-04-18 17:50, Ville Syrjälä wrote:
> > > > > > On Fri, Mar 30, 2018 at 04:26:53PM +0200, Hans de Goede wrote:
> > > > > > > Hi,
> > > > > > > 
> > > > > > > On 30-03-18 15:25, Hans de Goede wrote:
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > On 30-03-18 14:44, Chris Wilson wrote:
> > > > > > > > > Quoting Hans de Goede (2018-03-30 13:37:40)
> > > > > > > > > > Hi,
> > > > > > > > > > 
> > > > > > > > > > On 30-03-18 14:30, Chris Wilson wrote:
> > > > > > > > > > > Quoting Hans de Goede (2018-03-30 13:27:15)
> > > > > > > > > > > > Before this commit the WaSkipStolenMemoryFirstPage 
> > > > > > > > > > > > workaround code was
> > > > > > > > > > > > skipping the first 4k by passing 4096 as start of the 
> > > > > > > > > > > > address range passed
> > > > > > > > > > > > to drm_mm_init(). This means that calling 
> > > > > > > > > > > > drm_mm_reserve_node() to try and
> > > > > > > > > > > > reserve the firmware framebuffer so that we can inherit 
> > > > > > > > > > > > it would always
> > > > > > > > > > > > fail, as the firmware framebuffer starts at address 0.
> > > > > > > > > > > > 
> > > > > > > > > > > > Commit d43537610470 ("drm/i915: skip the first 4k of 
> > > > > > > > > > > > stolen memory on
> > > > > > > > > > > > everything >= gen8") says in its commit message: "This 
> > > > > > > > > > > > is confirmed to fix
> > > > > > > > > > > > Skylake screen flickering issues (probably caused by 
> > > > > > > > > > > > the fact that we
> > > > > > > > > > > > initialized a ring in the first page of stolen, but I 
> > > > > > > > > > > > didn't 100% confirm
> > > > > > > > > > > > this theory)."
> > > > > > > > > > > > 
> > > > > > > > > > > > Which suggests that it is safe to use the first page 
> > > > > > > > > > > > for a linear
> > > > > > > > > > > > framebuffer as the firmware is doing.
> > > > > > > > > > > > 
> > > > > > > > > > > > This commit always passes 0 as start to drm_mm_init() 
> > > > > > > > > > > > and works around
> > > > > > > > > > > > WaSkipStolenMemoryFirstPage in 
> > > > > > > > > > > > i915_gem_stolen_insert_node_in_range()
> > > > > > > > > > > > by insuring the start address passed by to 
> > > > > > > > > > > > drm_mm_insert_node_in_range()
> > > > > > > > > > > > is always 4k or more. All entry points to 
> > > > > > > > > > > > i915_gem_stolen.c go through
> > > > > > > > > > > > i915_gem_stolen_insert_node_in_range(), so that any 
> > > > > > > > > > > > newly allocated
> > > > > > > > > > > > objects such as ring-buffers will not be allocated in 
> > > > > > > > > > > > the first 4k.
> > > > > > > > > > > > 
> > > > > > > > > > > > The one exception is 
> > > > > > > > > > > > i915_gem_object_create_stolen_for_preallocated()
> > > > > > > > > > > > which directly calls drm_mm_reserve_node() which now 
> > > > > > > > > > > > will be able to
> > > > > > > > > > > > use the first 4k.
> > > > > > > > > > > > 
> > > > > > > > > > > > This fixes the i915 driver no longer being able to 
> > > > > > > > > > > > inherit the firmware
> > > > > > > > > > > > framebuffer on gen8+, which fixes the video output 
> > > > > > > > > > > > changing from the
> > > > > > > > > > > > vendor logo to a black screen as soon as the i915 
> > > > > > > > > > > > driver is loaded
> > > > > > > > > > > > (on systems without fbcon).
> > > > > > > > > > > 
> > > > > > > > > > > We've been told by the HW guys not to use the first page. 
> > > > > > > > > > > (That's my
> > > > > > > > > > > understanding from every time this gets questioned.)
> > > > > > > > > > 
> > > > > > > > > > Yet the GOP is happily using the first page. I think we may 
> > > > > > > > > > need to make
> > > > > > > > > > a difference here between the GPU not using the first page 
> > > > > > > > > > and the
> > > > > > > > > > display engine/pipeline not using the first page. Note that 
> > > > > > > > > > my patch
> > > > > > > > > > only influences the inheriting of the initial framebuffer 
> > > > > > > > > > as allocated
> > > > > > > > > > by the GOP. It does not influence any other allocations 
> > > > > > > > > > from the
> > > > > > > > > > reserved range, those will still all avoid the first page.
> > > > > > > > > > 
> > > > > > > > > > Without this patch fastboot / flickerfree support is 
> > > > > > > > > > essentially broken
> > > > > > > > > > on any gen8+ hardware given that one of the goals of atomic 
> > > > > > > > > > is to be
> > > > > > > > > > able to do flickerfree transitions I think that this 
> > > > > > > > > > warrants a closer
> > > > > > > > > > look then just simply saying never use the first page.
> > > > > > > > > 
> > > > > > > > 

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

[Daniel Vetter]

On Fri, Apr 06, 2018 at 07:02:02PM +0300, Ville Syrjälä wrote:
> On Mon, Apr 02, 2018 at 02:35:42PM +0530, Ramalingam C wrote:
> > 
> > 
> > On Thursday 29 March 2018 07:54 PM, Ville Syrjälä wrote:
> > > On Thu, Mar 29, 2018 at 07:39:07PM +0530, Ramalingam C wrote:
> > >> HDCP1.4 key can be loaded, only when Power well #1 is enabled and cdclk
> > >> is enabled. Using the I915 power well infrastruture, above requirement
> > >> is verified.
> > >>
> > >> This patch enables the hdcp initialization for HSW, BDW, and BXT.
> > >>
> > >> v2:
> > >>Choose the PW# based on the platform.
> > >>
> > >> Signed-off-by: Ramalingam C 
> > >> Reviewed-by: Sean Paul 
> > >> ---
> > >>   drivers/gpu/drm/i915/intel_hdcp.c | 41 
> > >> +--
> > >>   1 file changed, 39 insertions(+), 2 deletions(-)
> > >>
> > >> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
> > >> b/drivers/gpu/drm/i915/intel_hdcp.c
> > >> index f77d956b2b18..d8af09b46a44 100644
> > >> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> > >> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> > >> @@ -37,6 +37,43 @@ static int intel_hdcp_poll_ksv_fifo(struct 
> > >> intel_digital_port *intel_dig_port,
> > >>  return 0;
> > >>   }
> > >>   
> > >> +static bool hdcp_key_loadable(struct drm_i915_private *dev_priv)
> > >> +{
> > >> +struct i915_power_domains *power_domains = 
> > >> _priv->power_domains;
> > >> +struct i915_power_well *power_well;
> > >> +enum i915_power_well_id id;
> > >> +bool enabled = false;
> > >> +
> > >> +/*
> > >> + * On HSW and BDW, Display HW loads the Key as soon as Display 
> > >> resumes.
> > >> + * On all BXT+, SW can load the keys only when the PW#1 is 
> > >> turned on.
> > >> + */
> > >> +if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
> > >> +id = HSW_DISP_PW_GLOBAL;
> > >> +else
> > >> +id = SKL_DISP_PW_1;
> > >> +
> > >> +mutex_lock(_domains->lock);
> > >> +
> > >> +/* PG1 (power well #1) needs to be enabled */
> > >> +for_each_power_well(dev_priv, power_well) {
> > >> +if (power_well->id == id) {
> > >> +enabled = power_well->ops->is_enabled(dev_priv,
> > >> +  
> > >> power_well);
> > >> +break;
> > >> +}
> > >> +}
> > >> +mutex_unlock(_domains->lock);
> > >> +
> > >> +/*
> > >> + * Another req for hdcp key loadability is enabled state of pll 
> > >> for
> > >> + * cdclk. Without active crtc we wont land here. So we are 
> > >> assuming that
> > >> + * cdclk is already on.
> > >> + */
> > >> +
> > >> +return enabled;
> > >> +}
> > >> +
> > >>   static void intel_hdcp_clear_keys(struct drm_i915_private *dev_priv)
> > >>   {
> > >>  I915_WRITE(HDCP_KEY_CONF, HDCP_CLEAR_KEYS_TRIGGER);
> > >> @@ -615,8 +652,8 @@ static int _intel_hdcp_enable(struct intel_connector 
> > >> *connector)
> > >>  DRM_DEBUG_KMS("[%s:%d] HDCP is being enabled...\n",
> > >>connector->base.name, connector->base.base.id);
> > >>   
> > >> -if (!(I915_READ(SKL_FUSE_STATUS) & SKL_FUSE_PG_DIST_STATUS(1))) 
> > >> {
> > >> -DRM_ERROR("PG1 is disabled, cannot load keys\n");
> > >> +if (!hdcp_key_loadable(dev_priv)) {
> > >> +DRM_ERROR("HDCP key Load is not possible\n");
> > >>  return -ENXIO;
> > >>  }
> > > If you need the power well then why aren't you grabbing the correct
> > > power domain reference somewhere?
> > 
> > Ville,
> > 
> > As HDCP is supposed to be enabled after the basic display is up, power well 
> > #1 is supposed to be enabled.
> > If not that is mostly an error w.r.t HDCP.
> > 
> > So at this point we just want to verify whether required PW is up and HDCP 
> > key can be loaded from the HW. Else fail the HDCP request.
> 
> So this is in practice dead code to deal with a hypothetical bug
> elsewhere in the driver?

Yeah looks like it should be wrapped in a WARN_ON, or maybe outright
thrown out. The unclaimed mmio debug stuff will catch when this happens
(or well, should).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

[Daniel Vetter]

On Fri, Apr 06, 2018 at 02:25:08PM +0300, Oleksandr Andrushchenko wrote:
> On 04/03/2018 12:47 PM, Daniel Vetter wrote:
> > On Thu, Mar 29, 2018 at 04:19:31PM +0300, Oleksandr Andrushchenko wrote:
> > > From: Oleksandr Andrushchenko 
> > > +static int to_refs_grant_foreign_access(struct xen_gem_object *xen_obj)
> > > +{
> > > + grant_ref_t priv_gref_head;
> > > + int ret, j, cur_ref, num_pages;
> > > + struct sg_page_iter sg_iter;
> > > +
> > > + ret = gnttab_alloc_grant_references(xen_obj->num_pages,
> > > + _gref_head);
> > > + if (ret < 0) {
> > > + DRM_ERROR("Cannot allocate grant references\n");
> > > + return ret;
> > > + }
> > > +
> > > + j = 0;
> > > + num_pages = xen_obj->num_pages;
> > > + for_each_sg_page(xen_obj->sgt->sgl, _iter, xen_obj->sgt->nents, 0) {
> > > + struct page *page;
> > > +
> > > + page = sg_page_iter_page(_iter);
> > Quick drive-by: You can't assume that an sgt is struct page backed.
> Do you mean that someone could give me sgt which never
> seen sg_assign_page for its entries?

Yes.

> What are the other use-cases for that to happen?

Sharing vram or other resources which are not backed by a struct page. See
Christian König's recent work to accomplish just that for admgpu.

> > And you probably want to check this at import/attach time.
> The check you mean is to make sure that when I call
> page = sg_page_iter_page(_iter);
> I have to make sure that I get a valid page?

Yup.

> > -Daniel
> Thank you,
> Oleksandr

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/4] drm/virtio: remove drm_dev_set_unique workaround

[Daniel Vetter]

On Fri, Apr 06, 2018 at 01:56:15PM +0100, Emil Velikov wrote:
> Hi Laszlo,
> 
> On 6 April 2018 at 13:15, Laszlo Ersek  wrote:
> > On 04/04/18 19:29, Laszlo Ersek wrote:
> >> Hi Emil,
> >>
> >> On 04/03/18 19:13, Emil Velikov wrote:
> >>> On 29 March 2018 at 12:17, Laszlo Ersek  wrote:
>  On 03/28/18 16:35, Emil Velikov wrote:
> > On 28 March 2018 at 11:27, Laszlo Ersek  wrote:
> >> On 03/28/18 03:24, Emil Velikov wrote:
> 
> >>> Gents, can someone double-check this please? Just in case.
> >>
> >> I guess I should test whether this series regresses the use case
> >> described in c2cbc38b97; is that correct?
> >>
> > Precisely.
> 
> > [3] https://github.com/evelikov/linux/commits/ioctl-cleanups
> 
>  Unfortunately, this series seems to reintroduce the regression fixed
>  / described earlier in commit c2cbc38b97.
> 
> >>> Thank you very much for testing.
> >>>
> >>> Believe I've tracked it down to a broken commit from 2014 ;-)
> >>> Please try the following branch [1] - it's untested, but I'm 99% sure
> >>> it will work like a charm.
> >>
> >> Alas, it does not work.
> >
> > I've done some more digging. Let me quote the commit message on the
> > proposed patch again:
> >
> >> Ealier commit a325725633c26aa66ab940f762a6b0778edf76c0 did not attribute
> >> that virtio can be either PCI or a platform device and removed the
> >> .set_busid hook. Whereas only the "platform" instance should have been
> >> removed.
> >>
> >> Since then, two things have happened:
> >>  - the driver manually calls drm_dev_set_unique, addressing the Xserver
> >> regression - see commit 9785b4321b0bd701f8d21d3d3c676a7739a5cf22
> >>  - core itself calls drm_pci_set_busid, on drm_set_busid IOCTL setting
> >> the busid, so we don't need to fallback to dev->unique - see commit
> >> 5c484cee7ef9c4fd29fa0ba09640d55960977145
> >>
> >> With that in place we can remove the local workaround.
> >
> > This write-up of events is not precise enough. Instead, I think the
> > timeline is as follows:
> >
> > (1) Commit a325725633c2 ("drm: Lobotomize set_busid nonsense for !pci
> > drivers", 2016-06-21) introduced the regression. By removing
> > drm_virtio_set_busid(), commit a325725633c2 changed the behavior of
> > the following function:
> >
> >> static int drm_set_busid(struct drm_device *dev, struct drm_file 
> >> *file_priv)
> >> {
> >>   struct drm_master *master = file_priv->master;
> >>   int ret;
> >>
> >>   if (master->unique != NULL)
> >>   drm_unset_busid(dev, master);
> >>
> >>   if (dev->driver->set_busid) {
> >>   ret = dev->driver->set_busid(dev, master);
> >>   if (ret) {
> >>   drm_unset_busid(dev, master);
> >>   return ret;
> >>   }
> >>   } else {
> >>   WARN_ON(!dev->unique);
> >>   master->unique = kstrdup(dev->unique, GFP_KERNEL);
> >>   if (master->unique)
> >>   master->unique_len = strlen(dev->unique);
> >>   }
> >>
> >>   return 0;
> >> }
> >
> > When a325725633c2 removed drm_virtio_set_busid(), drm_set_busid()
> > started taking the second branch, which wasn't doing the right thing
> > for virtio-vga at the time.
> >
> > (2) There were two ways to fix the regression: either (a) return
> > drm_set_busid() to taking the first branch, or (b) tweak the
> > virtio-vga driver so that the second branch in drm_set_busid() start
> > to behave right.
> >
> > My commit c2cbc38b9715 ("drm: virtio: reinstate
> > drm_virtio_set_busid()", 2016-10-04) implemented (a), by reverting a
> > few chunks of a325725633c2.
> >
> > (3) Gerd thought that approach (b) was superior (and I totally defer to
> > him on this, now that I'm learning of his patches in the first place
> > :) ). Namely, in commit 9785b4321b0b ("drm/virtio: fix busid
> > regression", 2016-11-15), he implemented approach (b), and right
> > after, in commit 1775db074a32 ("Revert "drm: virtio: reinstate
> > drm_virtio_set_busid()"", 2016-11-15), he undid my commit
> > c2cbc38b9715.
> >
> > In other words, Gerd replaced approach (a) with approach (b).
> >
> > (4) Subsequently, commit 5c484cee7ef9 ("drm: Remove
> > drm_driver->set_busid hook", 2017-06-20), changed drm_set_busid()
> > to  the following:
> >
> >> static int drm_set_busid(struct drm_device *dev, struct drm_file 
> >> *file_priv)
> >> {
> >>   struct drm_master *master = file_priv->master;
> >>   int ret;
> >>
> >>   if (master->unique != NULL)
> >>   drm_unset_busid(dev, master);
> >>
> >>   if (dev_is_pci(dev->dev)) {
> >>   ret = drm_pci_set_busid(dev, master);
> >>   if (ret) {
> >>   drm_unset_busid(dev, master);
> >>   return ret;
> >>   }
> >>  

Re: [PATCH 8/8] drm/arm/malidp: Added the late system pm functions

[Daniel Vetter]

On Fri, Apr 06, 2018 at 08:02:16PM +0100, Ayan Halder wrote:
> On Tue, Mar 27, 2018 at 01:09:36PM +0200, Daniel Vetter wrote:
> > On Tue, Mar 27, 2018 at 11:59 AM, Ayan Halder  wrote:
> > > On Tue, Mar 27, 2018 at 10:29:03AM +0200, Daniel Vetter wrote:
> > >> On Mon, Mar 26, 2018 at 06:03:20PM +0100, Ayan Kumar Halder wrote:
> > >> > malidp_pm_suspend_late checks if the runtime status is not suspended
> > >> > and if so, invokes malidp_runtime_pm_suspend which disables the
> > >> > display engine/core interrupts and the clocks. It sets the runtime 
> > >> > status
> > >> > as suspended. Subsequently, malidp_pm_resume_early will invoke
> > >> > malidp_runtime_pm_resume which enables the clocks and the interrupts
> > >> > (previously disabled) and sets the runtime status as active.
> > >> >
> > >> > Signed-off-by: Ayan Kumar Halder 
> > >> > Change-Id: I5f8c3d28f076314a1c9da2a46760a9c37039ccda
> > >>
> > >> Why exactly do you need late/early hooks? If you have dependencies with
> > >> other devices, pls consider adding device_links instead. This here
> > >> shouldn't be necessary.
> > >> -Daniel
> > > We need to late/early hooks to disable malidp interrupts and the
> > > clocks.
> > 
> > Yes, but why this ordering constraint? Why can't you just disable the
> > interrupts/clocks in the normal suspend code. I see that the patch
> > does this, I want to understand why it does it.
> > -Daniel
> Apologies for my delayed response on this. 
> 
> With reference to https://lwn.net/Articles/505683/ :-
> 1. "suspend() should leave the device in a quiescent state." We invoke
> drm_mode_config_helper_suspend() which deactivates the crtc. I
> understand that this is the quiescent state.
> 
> 2. "suspend_late() can often be the same as runtime_suspend()."  We
> invoke runtime suspend/resume calls in late/early hooks.

This article is from 2012. That's not really recommended best practices
anymore. device_links have only been added a few years ago, so ofc an
article from 2012 can't tell you that you should use those instead :-)

That's why I brought this up, we have much better ways to handle device
dependencies now.

Also, you still haven't explained what exactly the dependency is.
-Daniel

> 
> > >> > ---
> > >> >  drivers/gpu/drm/arm/malidp_drv.c | 17 +
> > >> >  1 file changed, 17 insertions(+)
> > >> >
> > >> > diff --git a/drivers/gpu/drm/arm/malidp_drv.c 
> > >> > b/drivers/gpu/drm/arm/malidp_drv.c
> > >> > index bd44a6d..f6124d8 100644
> > >> > --- a/drivers/gpu/drm/arm/malidp_drv.c
> > >> > +++ b/drivers/gpu/drm/arm/malidp_drv.c
> > >> > @@ -766,8 +766,25 @@ static int __maybe_unused malidp_pm_resume(struct 
> > >> > device *dev)
> > >> > return 0;
> > >> >  }
> > >> >
> > >> > +static int __maybe_unused malidp_pm_suspend_late(struct device *dev)
> > >> > +{
> > >> > +   if (!pm_runtime_status_suspended(dev)) {
> > >> > +   malidp_runtime_pm_suspend(dev);
> > >> > +   pm_runtime_set_suspended(dev);
> > >> > +   }
> > >> > +   return 0;
> > >> > +}
> > >> > +
> > >> > +static int __maybe_unused malidp_pm_resume_early(struct device *dev)
> > >> > +{
> > >> > +   malidp_runtime_pm_resume(dev);
> > >> > +   pm_runtime_set_active(dev);
> > >> > +   return 0;
> > >> > +}
> > >> > +
> > >> >  static const struct dev_pm_ops malidp_pm_ops = {
> > >> > SET_SYSTEM_SLEEP_PM_OPS(malidp_pm_suspend, malidp_pm_resume) \
> > >> > +   SET_LATE_SYSTEM_SLEEP_PM_OPS(malidp_pm_suspend_late, 
> > >> > malidp_pm_resume_early) \
> > >> > SET_RUNTIME_PM_OPS(malidp_runtime_pm_suspend, 
> > >> > malidp_runtime_pm_resume, NULL)
> > >> >  };
> > >> >
> > >> > --
> > >> > 2.7.4
> > >> >
> > >> > ___
> > >> > dri-devel mailing list
> > >> > dri-devel@lists.freedesktop.org
> > >> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > >>
> > >> --
> > >> Daniel Vetter
> > >> Software Engineer, Intel Corporation
> > >> http://blog.ffwll.ch
> > >> ___
> > >> dri-devel mailing list
> > >> dri-devel@lists.freedesktop.org
> > >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > > IMPORTANT NOTICE: The contents of this email and any attachments are 
> > > confidential and may also be privileged. If you are not the intended 
> > > recipient, please notify the sender immediately and do not disclose the 
> > > contents to any other person, use it for any purpose, or store or copy 
> > > the information in any medium. Thank you.
> > > ___
> > > dri-devel mailing list
> > > dri-devel@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > 
> > 
> > 
> > -- 
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > +41 (0) 79 365 57 48 - http://blog.ffwll.ch

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___

Re: [PATCH v2] Add udmabuf misc device

[Daniel Vetter]

On Fri, Apr 06, 2018 at 02:24:46PM +0200, Christian König wrote:
> Am 06.04.2018 um 11:33 schrieb Gerd Hoffmann:
> >Hi,
> > 
> > > The pages backing a DMA-buf are not allowed to move (at least not without 
> > > a
> > > patch set I'm currently working on), but for certain MM operations to work
> > > correctly you must be able to modify the page tables entries and move the
> > > pages backing them around.
> > > 
> > > For example try to use fork() with some copy on write pages with this
> > > approach. You will find that you have only two options to correctly handle
> > > this.
> > The fork() issue should go away with shared memory pages (no cow).
> > I guess this is the reason why vgem is internally backed by shmem.
> 
> Yes, exactly that is also an approach which should work fine. Just don't try
> to get this working with get_user_pages().
> 
> > 
> > Hmm.  So I could try to limit the udmabuf driver to shmem too (i.e.
> > have the ioctl take a shmem filehandle and offset instead of a virtual
> > address).
> > 
> > But maybe it is better then to just extend vgem, i.e. add support to
> > create gem objects from existing shmem.
> > 
> > Comments?
> 
> Yes, extending vgem instead of creating something new sounds like a good
> idea to me as well.

+1 on adding a vgem "import from shmem/memfd" ioctl. Sounds like a good
idea, and generally useful.

We might want to limit to memfd though for semantic reasons: dma-buf have
invariant size, shmem not so much. memfd can be locked down to not change
their size anymore. And iirc the core mm page invalidation protocol around
truncate() is about as bad as get_user_pages vs cow :-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RfC PATCH] Add udmabuf misc device

[Daniel Vetter]

On Thu, Apr 05, 2018 at 05:11:17PM -0700, Matt Roper wrote:
> On Thu, Apr 05, 2018 at 10:32:04PM +0200, Daniel Vetter wrote:
> > Pulling this out of the shadows again.
> > 
> > We now also have xen-zcopy from Oleksandr and the hyper dmabuf stuff
> > from Matt and Dongwong.
> > 
> > At least from the intel side there seems to be the idea to just have 1
> > special device that can handle cross-gues/host sharing for all kinds
> > of hypervisors, so I guess you all need to work together :-)
> > 
> > Or we throw out the idea that hyper dmabuf will be cross-hypervisor
> > (not sure how useful/reasonable that is, someone please convince me
> > one way or the other).
> > 
> > Cheers, Daniel
> 
> Dongwon (DW) is the one doing all the real work on hyper_dmabuf, but I'm
> familiar with the use cases he's trying to address, and I think there
> are a couple high-level goals of his work that are worth calling out as
> we discuss the various options for sharing buffers produced in one VM
> with a consumer running in another VM:
> 
>  * We should try to keep the interface/usage separate from the
>underlying hypervisor implementation details.  I.e., in DW's design
>the sink/source drivers that handle the actual buffer passing in the
>two VM's should provide a generic interface that does not depend on a
>specific hypervisor.  Behind the scenes there could be various
>implementations for specific hypervisors (Xen, KVM, ACRN, etc.), and
>some of those backends may have additional restrictions, but it would
>be best if userspace didn't have to know the specific hypervisor
>running on the system and could just query the general capabilities
>available to it.  We've already got projects in flight that are
>wanting this functionality on Xen and ACRN today.

Two comments on this:

- Just because it's in drivers/gpu doesn't mean you can't use it for
  anything else. E.g. the xen-zcopy driver can very much be used for any
  dma-buf, there's nothing gpu specific with it - well besides that it
  resuses some useful DRM ioctls, but if that annoys you just do a #define
  TOTALLY_GENERIC DRM and be done :-)

- Especially the kvm memory and hypervisor model seems totally different
  from other hypervisors, e.g. no real use for guest-guest sharing (which
  doesn't go through the host) and other cases. So trying to make
  something 100% generic seems like a bad idea.

  Wrt making it generic: Just use generic interfaces - if you can somehow
  use xen-front for the display sharing, then a) no need for hyper-dmabuf
  and b) already fully generic since it looks like a normal drm device to
  the guest userspace.

>  * The general interface should be able to express sharing from any
>guest:guest, not just guest:host.  Arbitrary G:G sharing might be
>something some hypervisors simply aren't able to support, but the
>userspace API itself shouldn't make assumptions or restrict that.  I
>think ideally the sharing API would include some kind of
>query_targets interface that would return a list of VM's that your
>current OS is allowed to share with; that list would be depend on the
>policy established by the system integrator, but obviously wouldn't
>include targets that the hypervisor itself wouldn't be capable of
>handling.

Uh ... has a proper security architect analyzed this idea?

>  * A lot of the initial use cases are in the realm of graphics, but this
>shouldn't be a graphics-specific API.  Buffers might contain other
>types of content as well (e.g., audio).  Really the content producer
>could potentially be any driver (or userspace) running in the VM that
>knows how to import/export dma_buf's (or maybe just import given
>danvet's suggestion that we should make the sink driver do all the
>actual memory allocation for any buffers that may be shared).

See above, just because it uses drm ioctls doesn't make it gfx specific.

Otoh making it even more graphics specific might be even better, i.e. just
sharing the backend tech (grant tables or whatever), but having dedicated
front-ents for each use-case so there's less code to type.

>  * We need to be able to handle cross-VM coordination of buffer usage as
>well, so I think we'd want to include fence forwarding support in the
>API as well to signal back and forth about production/consumption
>completion.  And of course document really well what should happen
>if, for example, the entire VM you're sharing with/from dies.

Implicit fencing has been proven to be a bad idea. Please do explicit
passing of dma_fences (plus assorted protocol).

>  * The sharing API could be used to share multiple kinds of content in a
>single system.  The sharing sink driver running in the content
>producer's VM should accept some additional metadata that will be
>passed over to the target VM as well.  The sharing source driver
>running in the content consumer's VM would then be able to use 

[Bug 105883] booting with kernel using amd-staging-drm-next on 2400G hangs

[bugzilla-daemon]

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

--- Comment #8 from Michel Dänzer  ---
Is CONFIG_DRM_AMD_DC_DCN1_0 enabled in the kernel build configuration in both
cases?

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

Re: [RfC PATCH] Add udmabuf misc device

[Daniel Vetter]

On Fri, Apr 06, 2018 at 12:54:22PM +0200, Gerd Hoffmann wrote:
> On Fri, Apr 06, 2018 at 10:52:21AM +0100, Daniel Stone wrote:
> > Hi Gerd,
> > 
> > On 14 March 2018 at 08:03, Gerd Hoffmann  wrote:
> > >> Either mlock account (because it's mlocked defacto), and get_user_pages
> > >> won't do that for you.
> > >>
> > >> Or you write the full-blown userptr implementation, including 
> > >> mmu_notifier
> > >> support (see i915 or amdgpu), but that also requires Christian Königs
> > >> latest ->invalidate_mapping RFC for dma-buf (since atm exporting userptr
> > >> buffers is a no-go).
> > >
> > > I guess I'll look at mlock accounting for starters then.  Easier for
> > > now, and leaves the door open to switch to userptr later as this should
> > > be transparent to userspace.
> > 
> > Out of interest, do you have usecases for full userptr support? Maybe
> > another way would be to allow creation of dmabufs from memfds.
> 
> I have two things in mind.
> 
> One is vga emulation.  I have virtual pci memory bar for the virtual
> vga.  qemu backs vga memory with anonymous pages right now, switching
> that to shmem should be easy though if that makes things easier.  Guest
> places the framebuffer somewhere in the pci bar, and I want export the
> chunk which represents the framebuffer as dma-buf to display it on the
> host without copying around data.  Framebuffer is linear in guest
> physical memory, so a single block only.  That is the simpler case.
> 
> The more difficuilt one is virtio-gpu ressources.  virtio-gpu resources
> live in host memory (guest has no direct access).  The guest can
> optionally specify guest memory pages as backing storage for the
> resource.  Guest backing storage is allowed to be scattered.  Commands
> exist to copy both ways between host storage and guest backing.
> 
> With virgl (opengl acceleration) enabled the guest will send rendering
> commands to fill the framebuffer ressource, so there is no need to copy
> content to the framebuffer ressource.  The guest may fill other
> resources such as textures used for rendering with copy commands.
> 
> Without acceleration the guest does software-rendering to the backing
> storage, then sends a command to copy the framebuffer content from guest
> backing storage to host ressource.
> 
> Now it would be useful to allow a shared mapping, so no copying between
> guest backing storage and host resource is needed, especially for the
> software rendering case (i.e. dumb gem buffers).  Being able to export
> guest dumb buffers to other host processes would be useful too, for
> example to display guest windows seamlessly on the host wayland server.
> 
> So getting a dma-buf for the guest backing storage via udmabuf looked
> like a useful approach.  We can export the guest gem buffers to other
> host processes that way.  qemu itself could map it too, to get a linear
> representation of the scattered guest backing storage.
> 
> The other obvious approach would be to do it the other way around and
> allow the guest map the host resource somehow.  On the host side qemu
> could use vgem to allocate resource memory, so it'll be a gem object
> already.  Mapping that into the guest isn't that straight-forward
> though.  The guest manages its physical address space, so the guest
> would need to find a free spot and ask the host to place the resource
> there.  Then the guest needs page structs covering the mapped resource,
> so it can work with it.  Didn't investigate how difficuilt that is.  Use
> memory hotplug maybe?  Can we easily unmap the resource then?  Also I
> think updating the guests physical memory layout (which we would need to
> do on every resource map/unmap) isn't an exactly cheap operation ...

Generally we try to cache mappings as much as possible. And wrt finding a
slot: Create a sufficiently sized BAR on the virgl device, just for that?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 199319] Flickering screen on AMDGPU and DC with Linux 4.16-2

[bugzilla-daemon]

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

Michel Dänzer (mic...@daenzer.net) changed:

   What|Removed |Added

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

--- Comment #7 from Michel Dänzer (mic...@daenzer.net) ---
Is this the same as bug 199101?

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

Re: [PATCH] drm: clarify adjusted_mode for a bridge connected to a crtc

[Daniel Vetter]

On Fri, Apr 06, 2018 at 03:28:27PM +, Philippe CORNU wrote:
> Hi Laurent,
> 
> On 04/06/2018 04:53 PM, Laurent Pinchart wrote:
> > Hi Philippe,
> > 
> > Thank you for the patch.
> > 
> > On Monday, 26 February 2018 14:16:04 EEST Philippe Cornu wrote:
> >> This patch clarifies the adjusted_mode documentation
> >> for a bridge directly connected to a crtc.
> >>
> >> Signed-off-by: Philippe Cornu 
> >> ---
> >> This patch is linked to the discussion https://lkml.org/lkml/2018/1/25/367
> >>
> >>   include/drm/drm_bridge.h | 3 ++-
> >>   1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> >> index 3270fec46979..b5f3c070467c 100644
> >> --- a/include/drm/drm_bridge.h
> >> +++ b/include/drm/drm_bridge.h
> >> @@ -177,7 +177,8 @@ struct drm_bridge_funcs {
> >> * pipeline has been called already. If the bridge is the first element
> >> * then this would be _encoder_helper_funcs.mode_set. The display
> >> * pipe (i.e.  clocks and timing signals) is off when this function is
> >> -   * called.
> >> +   * called. If the bridge is connected to the crtc, the adjusted_mode
> >> +   * parameter is the one defined in _crtc_state.adjusted_mode.
> > 
> > Unless I'm mistaken this will always be the mode stored in
> > _crtc_state.adjusted_mode (at least for atomic drivers), regardless of
> > whether the bridge is the first in the chain (connected to the CRTC) or not.
> > What is important to document is that we have a single adjusted_mode for the
> > whole chain of bridges, and that it corresponds to the mode output by the 
> > CRTC
> > for the first bridge. Bridges further in the chain can look at that mode,
> > although there will probably be nothing of interest to them there.
> > 
> > How about the following text ?
> > 
> >  /**
> >   * @mode_set:
> >   *
> >   * This callback should set the given mode on the bridge. It is called
> >   * after the @mode_set callback for the preceding element in the 
> > display
> >   * pipeline has been called already. If the bridge is the first element
> >   * then this would be _encoder_helper_funcs.mode_set. The display
> >   * pipe (i.e.  clocks and timing signals) is off when this function is
> >   * called.
> >   *
> >   * The adjusted_mode parameter corresponds to the mode output by the 
> > CRTC
> >   * for the first bridge in the chain. It can be different from the mode
> >   * parameter that contains the desired mode for the connector at the 
> > end
> >   * of the bridges chain, for instance when the first bridge in the 
> > chain
> >   * performs scaling. The adjusted mode is mostly useful for the first
> >   * bridge in the chain and is likely irrelevant for the other bridges.
> >   *
> >   * For atomic drivers the adjusted_mode is the mode stored in
> >   * _crtc_state.adjusted_mode.
> >   *
> >   * NOTE:
> >   *
> >   * If a need arises to store and access modes adjusted for other 
> > locations
> >   * than the connection between the CRTC and the first bridge, the DRM
> >   * framework will have to be extended with DRM bridge states.
> >  */
> > 
> > Then I think we should also update the documentation of
> > drm_crtc_state.adjusted_mode accordingly:
> > 
> >  /*
> >   * @adjusted_mode:
> >   *
> >   * Internal display timings which can be used by the driver to handle
> >   * differences between the mode requested by userspace in @mode and 
> > what
> >   * is actually programmed into the hardware.
> >   *
> >   * For drivers using drm_bridge, this store the hardware display 
> > timings
> >   * used between the CRTC and the first bridge. For other drivers, the
> >   * meaning of the adjusted_mode field is purely driver implementation
> >   * defined information, and will usually be used to store the hardware
> >   * display timings used between the CRTC and encoder blocks.
> >   */
> > 
> 
> Your proposal is very clear and understandable. I will make a new patch 
> version based on it.

Just to avoid confusion: Needs to be a fully new patch on top of latest
drm-misc-next, since no rebasing in a group maintained tree.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 199319] Flickering screen on AMDGPU and DC with Linux 4.16-2

[bugzilla-daemon]

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

--- Comment #6 from m...@rainer-finke.de ---
The flickering that is happening from time to time is probably the same as in
the bug report https://bugzilla.kernel.org/show_bug.cgi?id=199101.

So only the flickering when night shift is enabled on Plasma-Wayland seems to
be different.

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

[Bug 105684] Loading amdgpu hits general protection fault: 0000 [#1] SMP NOPTI

[bugzilla-daemon]

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

--- Comment #15 from jian-h...@endlessm.com ---
Created attachment 138692
  --> https://bugs.freedesktop.org/attachment.cgi?id=138692=edit
tested with Linux kernel 4.16+ (commit
f8cf2f16a7c95acce497bfafa90e7c6d8397d653)

I have tried Linux kernel 4.16+ (commit
f8cf2f16a7c95acce497bfafa90e7c6d8397d653) and load amdgpu module manually.
The error becomes different: "system will hit the NULL pointer dereference at
0018" during loading amdgpu module.

[   26.715245] [drm] use_doorbell being set to: [true]
[   26.730536] [drm] Found VCN firmware Version: 1.45 Family ID: 18
[   26.894292] amdgpu: [powerplay] dpm has been enabled
[   26.896020] [drm] Display Core initialized with v3.1.38!
[   26.896269] BUG: unable to handle kernel NULL pointer dereference at
0018
[   26.896274] PGD 0 P4D 0 
[   26.896277] Oops:  [#1] SMP NOPTI
[   26.896280] Modules linked in: amdkfd amd_iommu_v2 amdgpu(+) chash gpu_sched
ttm drm_kms_helper drm i2c_algo_bit fb_sys_fops syscopyarea sysfillrect
sysimgblt efi_pstore cmac bnep edac_mce_amd kvm_amd arc4 ccp kvm irqbypass
crct10dif_pclmul crc32_pclmul snd_hda_codec_realtek ghash_clmulni_intel
snd_hda_codec_generic btusb pcbc snd_hda_codec_hdmi input_leds snd_hda_intel
btrtl btbcm btintel bluetooth ecdh_generic snd_hda_codec aesni_intel
snd_hda_core ath10k_pci ath10k_core wmi_bmof snd_hwdep aes_x86_64 crypto_simd
cryptd r8169 glue_helper snd_pcm ath mac80211 sparse_keymap cfg80211 snd_timer
snd mii wmi soundcore psmouse shpchp i2c_piix4 mac_hid video zram ip_tables
x_tables hid_generic serio_raw uas ahci usb_storage libahci usbhid hid
[   26.896324] CPU: 5 PID: 752 Comm: modprobe Not tainted 4.16.0+ #10
[   26.896326] Hardware name: Acer Aspire TC-380/Aspire TC-380, BIOS D05
02/01/2018
[   26.896331] RIP: 0010:klist_node_init+0x1c/0x40
[   26.896333] RSP: 0018:b89e823ef6e0 EFLAGS: 00010246
[   26.896335] RAX: 8bd9732e66f0 RBX:  RCX:
121c
[   26.896337] RDX: 121b RSI: 8bd9732e66e8 RDI:

[   26.896339] RBP: b89e823ef6f8 R08: 000271a0 R09:
fffe
[   26.896341] R10: ee228fccbe00 R11: 8bd9732fa000 R12:
8bd9732e66e8
[   26.896343] R13:  R14: 8bd98795c000 R15:
8bd98d4ef600
[   26.896346] FS:  7f75665d7700() GS:8bd99ed4()
knlGS:
[   26.896348] CS:  0010 DS:  ES:  CR0: 80050033
[   26.896350] CR2: 0018 CR3: 0003f7986000 CR4:
003406e0
[   26.896352] Call Trace:
[   26.896355]  ? klist_add_tail+0x18/0x50
[   26.896360]  device_add+0x38d/0x640
[   26.896363]  device_create_groups_vargs+0xe0/0xf0
[   26.896366]  device_create_with_groups+0x3f/0x60
[   26.896370]  ? fb_get_options+0x26/0x180
[   26.896382]  drm_sysfs_connector_add+0x59/0xa0 [drm]
[   26.896392]  drm_connector_register.part.9+0x4b/0xb0 [drm]
[   26.896402]  drm_connector_register+0x1a/0x20 [drm]
[   26.896455]  dm_hw_init+0x854/0xe50 [amdgpu]
[   26.896491]  amdgpu_device_init+0x13c5/0x1490 [amdgpu]
[   26.896526]  amdgpu_driver_load_kms+0x8b/0x2c0 [amdgpu]
[   26.896535]  drm_dev_register+0x149/0x1e0 [drm]
[   26.896571]  amdgpu_pci_probe+0x13f/0x1f0 [amdgpu]
[   26.896574]  local_pci_probe+0x4a/0xa0
[   26.896577]  pci_device_probe+0x109/0x1b0
[   26.896580]  driver_probe_device+0x2bb/0x4a0
[   26.896582]  __driver_attach+0xe2/0xf0
[   26.896584]  ? driver_probe_device+0x4a0/0x4a0
[   26.896587]  bus_for_each_dev+0x6a/0xc0
[   26.896590]  ? kmem_cache_alloc_trace+0x1c4/0x1d0
[   26.896592]  driver_attach+0x1e/0x20
[   26.896594]  bus_add_driver+0x170/0x260
[   26.896596]  driver_register+0x60/0xe0
[   26.896599]  ? 0xc0c04000
[   26.896601]  __pci_register_driver+0x5a/0x60
[   26.896636]  amdgpu_init+0x7a/0x89 [amdgpu]
[   26.896639]  do_one_initcall+0x55/0x19d
[   26.896642]  ? __vunmap+0x81/0xb0
[   26.896644]  ? _cond_resched+0x1a/0x50
[   26.896646]  ? kmem_cache_alloc_trace+0xbb/0x1d0
[   26.896650]  ? do_init_module+0x27/0x219
[   26.896653]  do_init_module+0x5f/0x219
[   26.896655]  load_module+0x260e/0x2e10
[   26.896659]  SYSC_finit_module+0xe5/0x120
[   26.896662]  ? SYSC_finit_module+0xe5/0x120
[   26.896665]  SyS_finit_module+0xe/0x10
[   26.896667]  do_syscall_64+0x73/0x130

-- 
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 01/10] include: Move ascii85 functions from i915 to linux/ascii85.h

[kbuild test robot]

Hi Jordan,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on robclark/msm-next]
[also build test ERROR on v4.16 next-20180406]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Jordan-Crouse/drm-msm-GPU-crash-state/20180406-170513
base:   git://people.freedesktop.org/~robclark/linux msm-next
config: x86_64-rhel (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/gpu//drm/i915/i915_gpu_error.c: In function 'print_error_obj':
>> drivers/gpu//drm/i915/i915_gpu_error.c:549:4: error: implicit declaration of 
>> function 'error_puts'; did you mean 'err_puts'? 
>> [-Werror=implicit-function-declaration]
   error_puts(m, ascii85_encode(obj->pages[page][i], out));
   ^~
   err_puts
   cc1: some warnings being treated as errors

vim +549 drivers/gpu//drm/i915/i915_gpu_error.c

   520  
   521  static void print_error_obj(struct drm_i915_error_state_buf *m,
   522  struct intel_engine_cs *engine,
   523  const char *name,
   524  struct drm_i915_error_object *obj)
   525  {
   526  char out[ASCII85_BUFSZ];
   527  int page;
   528  
   529  if (!obj)
   530  return;
   531  
   532  if (name) {
   533  err_printf(m, "%s --- %s = 0x%08x %08x\n",
   534 engine ? engine->name : "global", name,
   535 upper_32_bits(obj->gtt_offset),
   536 lower_32_bits(obj->gtt_offset));
   537  }
   538  
   539  err_compression_marker(m);
   540  for (page = 0; page < obj->page_count; page++) {
   541  int i, len;
   542  
   543  len = PAGE_SIZE;
   544  if (page == obj->page_count - 1)
   545  len -= obj->unused;
   546  len = ascii85_encode_len(len);
   547  
   548  for (i = 0; i < len; i++)
 > 549  error_puts(m, 
 > ascii85_encode(obj->pages[page][i], out));
   550  }
   551  err_puts(m, "\n");
   552  }
   553  

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


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

Re: [PATCH v6 05/30] drm/bridge: analogix_dp: Wait for HPD signal before configuring link

[Sasha Levin]

Hi,

[This is an automated email]

This commit has been processed by the -stable helper bot and determined
to be a high probability candidate for -stable trees. (score: 22.9952)

The bot has tested the following trees: v4.16, v4.15.15, v4.14.32, v4.9.92, 
v4.4.126.

v4.16: Failed to apply! Possible dependencies:
705e208c7389 ("drm/bridge: analogix_dp: Retry bridge enable when it failed")

v4.15.15: Failed to apply! Possible dependencies:
705e208c7389 ("drm/bridge: analogix_dp: Retry bridge enable when it failed")

v4.14.32: Failed to apply! Possible dependencies:
705e208c7389 ("drm/bridge: analogix_dp: Retry bridge enable when it failed")

v4.9.92: Failed to apply! Possible dependencies:
705e208c7389 ("drm/bridge: analogix_dp: Retry bridge enable when it failed")

v4.4.126: Failed to apply! Possible dependencies:
705e208c7389 ("drm/bridge: analogix_dp: Retry bridge enable when it failed")


Please let us know if you'd like to have this patch included in a stable tree.

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

Re: [PATCH] uapi: fix linux/kfd_ioctl.h userspace compilation errors

[Sasha Levin]

Hi,

[This is an automated email]

This commit has been processed because it contains a "Fixes:" tag,
fixing commit: 6a1c9510694f drm/amdkfd: Adding new IOCTL for scratch memory v2.

The bot has also determined it's probably a bug fixing patch. (score: 20.4472)

The bot has tested the following trees: v4.16, v4.15.15, v4.14.32.


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

Re: [PATCH v6 07/30] drm/bridge: analogix_dp: Ensure edp is disabled when shutting down the panel

[Sasha Levin]

Hi,

[This is an automated email]

This commit has been processed by the -stable helper bot and determined
to be a high probability candidate for -stable trees. (score: 15.6725)

The bot has tested the following trees: v4.16, v4.15.15, v4.14.32, v4.9.92, 
v4.4.126.

v4.16: Failed to apply! Possible dependencies:
715600a4c96e ("drm/bridge: analogix_dp: Retry bridge enable when it failed")

v4.15.15: Failed to apply! Possible dependencies:
715600a4c96e ("drm/bridge: analogix_dp: Retry bridge enable when it failed")

v4.14.32: Failed to apply! Possible dependencies:
715600a4c96e ("drm/bridge: analogix_dp: Retry bridge enable when it failed")

v4.9.92: Failed to apply! Possible dependencies:
715600a4c96e ("drm/bridge: analogix_dp: Retry bridge enable when it failed")

v4.4.126: Failed to apply! Possible dependencies:
3424e3a4f844 ("drm: bridge: analogix/dp: split exynos dp driver to bridge 
directory")
715600a4c96e ("drm/bridge: analogix_dp: Retry bridge enable when it failed")


Please let us know if you'd like to have this patch included in a stable tree.

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

Re: [PATCH v6 15/30] drm/bridge: analogix_dp: Fix timeout of video streamclk config

[Sasha Levin]

Hi,

[This is an automated email]

This commit has been processed by the -stable helper bot and determined
to be a high probability candidate for -stable trees. (score: 94.5181)

The bot has tested the following trees: v4.16, v4.15.15, v4.14.32, v4.9.92, 
v4.4.126.

v4.16: Build OK!
v4.15.15: Build OK!
v4.14.32: Build OK!
v4.9.92: Build OK!
v4.4.126: Failed to apply! Possible dependencies:
3424e3a4f844 ("drm: bridge: analogix/dp: split exynos dp driver to bridge 
directory")
bcbb7033acf9 ("drm: bridge: analogix/dp: fix some obvious code style")


Please let us know if you'd like to have this patch included in a stable tree.

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

Re: [PATCH] drm/sti: Depend on OF rather than selecting it

[Sasha Levin]

Hi,

[This is an automated email]

This commit has been processed because it contains a "Fixes:" tag,
fixing commit: cc6b741c6f63 drm: sti: remove useless fields from vtg structure.

The bot has also determined it's probably a bug fixing patch. (score: 96.6729)

The bot has tested the following trees: v4.16.

v4.16: Build OK!

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

Re: [PATCH v6 18/30] drm/bridge: analogix_dp: Reorder plat_data->power_off to happen sooner

[Sasha Levin]

Hi,

[This is an automated email]

This commit has been processed by the -stable helper bot and determined
to be a high probability candidate for -stable trees. (score: 13.9476)

The bot has tested the following trees: v4.16, v4.15.15, v4.14.32, v4.9.92, 
v4.4.126.

v4.16: Failed to apply! Possible dependencies:
533122d0d37a ("drm/bridge: analogix_dp: Ensure edp is disabled when 
shutting down the panel")

v4.15.15: Failed to apply! Possible dependencies:
533122d0d37a ("drm/bridge: analogix_dp: Ensure edp is disabled when 
shutting down the panel")

v4.14.32: Failed to apply! Possible dependencies:
533122d0d37a ("drm/bridge: analogix_dp: Ensure edp is disabled when 
shutting down the panel")

v4.9.92: Failed to apply! Possible dependencies:
533122d0d37a ("drm/bridge: analogix_dp: Ensure edp is disabled when 
shutting down the panel")

v4.4.126: Failed to apply! Possible dependencies:
3424e3a4f844 ("drm: bridge: analogix/dp: split exynos dp driver to bridge 
directory")
533122d0d37a ("drm/bridge: analogix_dp: Ensure edp is disabled when 
shutting down the panel")


Please let us know if you'd like to have this patch included in a stable tree.

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

Re: [PATCH v6 16/30] drm/bridge: analogix_dp: Fix incorrect operations with register ANALOGIX_DP_FUNC_EN_1

[Sasha Levin]

Hi,

[This is an automated email]

This commit has been processed by the -stable helper bot and determined
to be a high probability candidate for -stable trees. (score: 23.2149)

The bot has tested the following trees: v4.16, v4.15.15, v4.14.32, v4.9.92, 
v4.4.126.

v4.16: Build OK!
v4.15.15: Build OK!
v4.14.32: Build OK!
v4.9.92: Build OK!
v4.4.126: Failed to apply! Possible dependencies:
092f899420c9 ("drm: bridge: analogix/dp: rename register constants")
bcbb7033acf9 ("drm: bridge: analogix/dp: fix some obvious code style")


Please let us know if you'd like to have this patch included in a stable tree.

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

Re: AMD graphics performance regression in 4.15 and later

[Jean-Marc Valin]

Hi Christian,

Thanks for the info. FYI, I've also opened a Firefox bug for that at:
https://bugzilla.mozilla.org/show_bug.cgi?id=1448778
Feel free to comment since you have a better understanding of what's
going on.

One last question: right now I'm running 4.15.0 with the "offending"
patch reverted. Is that safe to run or are there possible bad
interactions with other changes.

Cheers,

Jean-Marc

On 04/06/2018 01:20 PM, Christian König wrote:
> Am 06.04.2018 um 18:42 schrieb Jean-Marc Valin:
>> Hi Christian,
>>
>> On 04/09/2018 07:48 AM, Christian König wrote:
>>> Am 06.04.2018 um 17:30 schrieb Jean-Marc Valin:
 Hi Christian,

 Is there a way to turn off these huge pages at boot-time/run-time?
>>> Only at compile time by not setting CONFIG_TRANSPARENT_HUGEPAGE.
>> Any reason why
>> echo never > /sys/kernel/mm/transparent_hugepage/enabled
>> doesn't solve the problem?
> 
> Because we unfortunately try to allocate huge pages anyway, we
> unfortunately just fail in 100% of all cases.
> 
> That basically gives you both, the extra allocation overhead and the
> still bad throughput.
> 
>> Also, I assume that disabling CONFIG_TRANSPARENT_HUGEPAGE will disable
>> them for everything and not just what your patch added, right?
> 
> Correct, that's why I wrote that disabling SWIOTLBs might be better.
> 
 I'm not sure what you mean by "We mitigated the problem by avoiding the
 slow coherent DMA code path on almost all platforms on newer
 kernels". I
 tested up to 4.16 and the performance regression is just as bad as
 it is
 for 4.15.
>>> Indeed 4.16 still doesn't have that. You could use the
>>> amd-staging-drm-next branch or wait for 4.17.
>> Is there a way to pull just that change or is there too much
>> interactions with other changes?
> 
> It adds a new detection if memory allocation needs to be coherent or
> not, that is not something you can easily pull into older versions.
> 
>>> That isn't related to the GFX hardware, but to your CPU/motherboard and
>>> whatever else you have in the system.
>> Well, I have an nvidia GPU in the same system (normally only used for
>> CUDA) and if I use it instead of my RX 560 then I'm not seeing any
>> performance issue with 4.15.
> 
> That's because you are probably using the Nvidia binary driver which has
> a completely separate code base.
> 
>>> Some part of your system needs SWIOTLB and that makes allocating memory
>>> much slower.
>> What would that part be? FTR, I have a complete description of my system
>> at https://jmvalin.dreamwidth.org/15583.html
>>
>> I don't know if it's related, but I can maybe see one thing in common
>> between my machine and the Core 2 Quad from the other bug report and
>> that's the "NUMA part". I have a dual-socket Xeon and (AFAIK) the Core 2
>> Quad is made of two two-core CPUs glued together with little
>> communication between them.
> 
> Yeah, that is probably the reason.
> 
>>> Intel doesn't use TTM because they don't have dedicated VRAM, but the
>>> open source nvidia driver should be affected as well.
>> I'm using the proprietary nvidia driver (because CUDA). Is that supposed
>> to be affected as well?
> 
> No.
> 
>>> We already mitigated that problem and I don't see any solution which
>>> will arrive faster than 4.17.
>> Is that supposed to make the slowdown unnoticeable or just slightly
>> better?
> 
> It completely goes away. The issue with the coherent path is that it
> tries to always allocate the lowest possible memory to make sure that it
> fits into the DMA constrains of all devices in the system.
> 
> But since AMD GPU can handle 40bits of addresses you would need at least
> 1TB of memory in the system to trigger that (or a NUMA where some system
> is low and some in a high area).
> 
> Christian.
> 
>>> The only quick workaround I can see is to avoid firefox, chrome for
>>> example is reported to work perfectly fine.
>> Or use an unaffected GPU/driver ;-)
>>
>> Cheers,
>>
>> Jean-Marc
>>
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 06/30] drm/bridge: analogix_dp: Set PD_INC_BG first when powering up edp phy

[Sasha Levin]

Hi,

[This is an automated email]

This commit has been processed by the -stable helper bot and determined
to be a high probability candidate for -stable trees. (score: 8.8719)

The bot has tested the following trees: v4.16, v4.15.15, v4.14.32, v4.9.92, 
v4.4.126.

v4.16: Build OK!
v4.15.15: Build OK!
v4.14.32: Build OK!
v4.9.92: Build OK!
v4.4.126: Failed to apply! Possible dependencies:
092f899420c9 ("drm: bridge: analogix/dp: rename register constants")
bcec20fd5ad6 ("drm: bridge: analogix/dp: add some rk3288 special registers 
setting")


Please let us know if you'd like to have this patch included in a stable tree.

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

Re: [PATCH v6 01/30] drm/bridge: analogix_dp: Move enable video into config_video()

[Sasha Levin]

Hi,

[This is an automated email]

This commit has been processed by the -stable helper bot and determined
to be a high probability candidate for -stable trees. (score: 6.1286)

The bot has tested the following trees: v4.16, v4.15.15, v4.14.32, v4.9.92, 
v4.4.126.

v4.16: Failed to apply! Possible dependencies:
243e398aab8d ("drm/bridge: analogix_dp: Don't change psr while bridge is 
disabled")

v4.15.15: Failed to apply! Possible dependencies:
243e398aab8d ("drm/bridge: analogix_dp: Don't change psr while bridge is 
disabled")

v4.14.32: Failed to apply! Possible dependencies:
243e398aab8d ("drm/bridge: analogix_dp: Don't change psr while bridge is 
disabled")

v4.9.92: Failed to apply! Possible dependencies:
243e398aab8d ("drm/bridge: analogix_dp: Don't change psr while bridge is 
disabled")

v4.4.126: Failed to apply! Possible dependencies:
243e398aab8d ("drm/bridge: analogix_dp: Don't change psr while bridge is 
disabled")
3424e3a4f844 ("drm: bridge: analogix/dp: split exynos dp driver to bridge 
directory")
5b3f84f222b6 ("drm/bridge: analogix_dp: add the PSR function support")
bcbb7033acf9 ("drm: bridge: analogix/dp: fix some obvious code style")


Please let us know if you'd like to have this patch included in a stable tree.

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