Re: [PATCH v2 2/2] drm/tinydrm: add driver for ST7735R panels

[David Lechner]

On 12/11/2017 03:18 PM, Noralf Trønnes wrote:


Den 10.12.2017 23.10, skrev David Lechner:

This adds a new driver for Sitronix ST7735R display panels.

This has been tested using an Adafruit 1.8" TFT.

Signed-off-by: David Lechner 
---



+static void st7735r_pipe_enable(struct drm_simple_display_pipe *pipe,
+    struct drm_crtc_state *crtc_state)
+{
+    struct tinydrm_device *tdev = pipe_to_tinydrm(pipe);
+    struct mipi_dbi *mipi = mipi_dbi_from_tinydrm(tdev);
+    struct device *dev = tdev->drm->dev;
+    int ret;
+    u8 addr_mode;
+
+    DRM_DEBUG_KMS("\n");
+
+    mipi_dbi_hw_reset(mipi);
+
+    ret = mipi_dbi_command(mipi, MIPI_DCS_SOFT_RESET);
+    if (ret) {
+    DRM_DEV_ERROR(dev, "Error sending command %d\n", ret);
+    return;
+    }
+
+    msleep(150);
+
+    mipi_dbi_command(mipi, MIPI_DCS_EXIT_SLEEP_MODE);
+    msleep(500);
+
+    mipi_dbi_command(mipi, ST7735R_FRMCTR1, 0x01, 0x2c, 0x2d);
+    mipi_dbi_command(mipi, ST7735R_FRMCTR2, 0x01, 0x2c, 0x2d);
+    mipi_dbi_command(mipi, ST7735R_FRMCTR3, 0x01, 0x2c, 0x2d, 0x01, 
0x2c,

+ 0x2d);
+    mipi_dbi_command(mipi, ST7735R_INVCTR, 0x07);
+    mipi_dbi_command(mipi, ST7735R_PWCTR1, 0xa2, 0x02, 0x84);
+    mipi_dbi_command(mipi, ST7735R_PWCTR2, 0xc5);
+    mipi_dbi_command(mipi, ST7735R_PWCTR3, 0x0a, 0x00);
+    mipi_dbi_command(mipi, ST7735R_PWCTR4, 0x8a, 0x2a);
+    mipi_dbi_command(mipi, ST7735R_PWCTR5, 0x8a, 0xee);
+    mipi_dbi_command(mipi, ST7735R_VMCTR1, 0x0e);
+    mipi_dbi_command(mipi, MIPI_DCS_EXIT_INVERT_MODE);
+    switch (mipi->rotation) {
+    default:
+    addr_mode = ST7735R_MX | ST7735R_MY;
+    break;
+    case 90:
+    addr_mode = ST7735R_MX | ST7735R_MV;
+    break;
+    case 180:
+    addr_mode = 0;
+    break;
+    case 270:
+    addr_mode = ST7735R_MY | ST7735R_MV;
+    break;
+    }
+    mipi_dbi_command(mipi, MIPI_DCS_SET_ADDRESS_MODE, addr_mode);
+    mipi_dbi_command(mipi, MIPI_DCS_SET_PIXEL_FORMAT,
+ MIPI_DCS_PIXEL_FMT_16BIT);
+    mipi_dbi_command(mipi, ST7735R_GAMCTRP1, 0x0f, 0x1a, 0x0f, 0x18, 
0x2f,

+ 0x28, 0x20, 0x22, 0x1f, 0x1b, 0x23, 0x37, 0x00, 0x07,
+ 0x02, 0x10);
+    mipi_dbi_command(mipi, ST7735R_GAMCTRN1, 0x0f, 0x1b, 0x0f, 0x17, 
0x33,

+ 0x2c, 0x29, 0x2e, 0x30, 0x30, 0x39, 0x3f, 0x00, 0x07,
+ 0x03, 0x10);
+    mipi_dbi_command(mipi, MIPI_DCS_SET_DISPLAY_ON);
+
+    msleep(100);
+
+    mipi_dbi_command(mipi, MIPI_DCS_ENTER_NORMAL_MODE);
+
+    msleep(20);
+
+    mipi_dbi_pipe_enable(pipe, crtc_state);
+}
+
+static const struct drm_simple_display_pipe_funcs st7735r_pipe_funcs = {
+    .enable    = st7735r_pipe_enable,
+    .disable    = mipi_dbi_pipe_disable,
+    .update    = tinydrm_display_pipe_update,
+    .prepare_fb    = tinydrm_display_pipe_prepare_fb,
+};
+
+static const struct drm_display_mode st7735r_mode = {
+    TINYDRM_MODE(128, 160, 28, 35),
+};


This naming talk has made me realise that these should be named after
the panel since they're not generic controller functions.
Maybe the mode can be generic, not sure if the physical size can/will
differ, the resolution is very likely to be the same for all.


Adafruit has a 1.44" 128x128px display [1] with the same controller, so 
the answer is no, the mode cannot be generic.


[1]: https://www.adafruit.com/product/2088


What's your view on my descision to split the MIPI DBI compatible
controllers into per controller drivers instead of having one driver
that supports them all?


My first impression was that I didn't like it so much. But now, I 
actually think that it is a good idea. I think it is a good compromise 
between some boilerplate code in every driver and a driver with so many 
quirks that it is very difficult to work on. It may make sense to 
combine some very similar controllers, but as a rule of thumb, I think 
one driver per controller will work nicely.



I've been afraid that it will be a very big file with macro definitions
per controller and enable functions per panel.

This driver has 15 macros and ~80 panel specific lines.
With one panel supported, half the driver is boilerplate.
The mi0283qt panel (MIPI DBI compatible) is in the same ballpark.

Adding helpers for panel reset/exit_sleep, for MIPI_DCS_SET_ADDRESS_MODE
and for display_on/enter_normal/flush could cut it down some more if we
made one driver to rule them all. Maybe the enable function per panel
could be cut in half that way.

I'm starting to wonder if one driver isn't such a bad solution after all...


I think as we add more drivers, the parts that get duplicated will 
become obvious candidates for helper functions to refactor, but I don't 
think trying to cram everything all into one driver is such a good idea.

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

Re: [PATCH v6 3/3] drm/rockchip: Add ROCKCHIP DW MIPI DSI controller driver

[Nickey Yang]

Hi Brian,


On 2017年12月07日 05:52, Brian Norris wrote:

Hi Nickey, others,

I just want to highlight a thing or two here. Otherwise, my
'Reviewed-by' still basically stands (FWIW).

On Wed, Dec 06, 2017 at 05:08:21PM +0800, Nickey Yang wrote:

Add the ROCKCHIP DSI controller driver that uses the Synopsys DesignWare
MIPI DSI host controller bridge.

Signed-off-by: Nickey Yang 
Signed-off-by: Brian Norris 
Reviewed-by: Brian Norris 
Reviewed-by: Sean Paul 
---
change:

v2:
add err_pllref, remove unnecessary encoder.enable & disable
correct spelling mistakes
v3:
call dw_mipi_dsi_unbind() in dw_mipi_dsi_rockchip_unbind()
fix typo, use of_device_get_match_data(),
change some ‘bind()’ logic into 'probe()'
add 'dev_set_drvdata()'
v4:
   return -EINVAL when can not get best_freq
   add a clarifying comment when get vco
   add review tag
v5:
   keep our power domain enabled while touching GRF
v6:
   change func dw_mipi_encoder_disable name to
   dw_mipi_dsi_encoder_disable

We noticed a regression w.r.t. pm_runtime_*() handling using this patch,
hence the pm_runtime changes in v5/v6. We actually need to keep our
power domain enabled in the mode_set() function, where we start to
configure some Rockchip-specific registers (GRF). More on that below.


  drivers/gpu/drm/rockchip/Kconfig|2 +-
  drivers/gpu/drm/rockchip/Makefile   |2 +-
  drivers/gpu/drm/rockchip/dw-mipi-dsi.c  | 1349 ---
  drivers/gpu/drm/rockchip/dw-mipi-dsi_rockchip.c |  785 +
  drivers/gpu/drm/rockchip/rockchip_drm_drv.c |2 +-
  drivers/gpu/drm/rockchip/rockchip_drm_drv.h |2 +-
  6 files changed, 789 insertions(+), 1353 deletions(-)
  delete mode 100644 drivers/gpu/drm/rockchip/dw-mipi-dsi.c
  create mode 100644 drivers/gpu/drm/rockchip/dw-mipi-dsi_rockchip.c


...


diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi_rockchip.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi_rockchip.c
new file mode 100644
index 000..66ab6fe
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi_rockchip.c
@@ -0,0 +1,785 @@

...


+static void dw_mipi_dsi_encoder_mode_set(struct drm_encoder *encoder,
+struct drm_display_mode *mode,
+struct drm_display_mode *adjusted)
+{
+   struct dw_mipi_dsi_rockchip *dsi = to_dsi(encoder);
+   const struct rockchip_dw_dsi_chip_data *cdata = dsi->cdata;
+   int val, ret, mux;
+
+   mux = drm_of_encoder_active_endpoint_id(dsi->dev->of_node,
+   >encoder);
+   if (mux < 0)
+   return;
+   /*
+* For the RK3399, the clk of grf must be enabled before writing grf
+* register. And for RK3288 or other soc, this grf_clk must be NULL,
+* the clk_prepare_enable return true directly.
+*/
+   ret = clk_prepare_enable(dsi->grf_clk);
+   if (ret) {
+   DRM_DEV_ERROR(dsi->dev, "Failed to enable grf_clk: %d\n", ret);
+   return;
+   }
+   pm_runtime_get_sync(dsi->dev);

What happens if there's a clk_prepare_enable() failure or failure to
retrieve the endpoint ID earlier in this function? You won't call
pm_runtime_get_*()...but might we still see a call to
dw_mipi_dsi_encoder_disable(), which would mean we get unbalanced
runtime PM status?

So should we change this to
1、remove dw_mipi_dsi_encoder_disable, and in
dw_mipi_dsi_encoder_mode_set:
   drm_of_encoder_active_endpoint_id  ->
      clk_prepare_enable ->
     pm_runtime_get_sync ->
   grf_config ->
     pm_runtime_put_sync ->
      clk_prepare_disable?
or
2、use dw_mipi_dsi_encoder_disable, and in
dw_mipi_dsi_encoder_mode_set:
   pm_runtime_get_sync ->
 drm_of_encoder_active_endpoint_id  ->
        clk_prepare_enable ->
   grf_config ->
    clk_prepare_disable?
and call pm_runtime_put_sync if there is a failure in
drm_of_encoder_active_endpoint_id or clk_prepare_enable


Also (and more importantly), is it fair to do all of this in mode_set()?
I believe Archit asked about this before, and the reason we're doing
this stuff in mode_set() now (where previously, the Rockchip driver was
doing it in ->enable()) is because when Philippe extracted the synopsys
bridge driver, that code migrated to ->mode_set().

But, I'm reading the comments on drm_encoder_helper_funcs::mode_set, and
I see:

 /**
  * @mode_set:
  *
  * This callback is used to update the display mode of an encoder.
  *
  * Note that the display pipe is completely off when this function is
  * called. Drivers which need hardware to be running before they 
program
  * the new display mode (because they implement runtime PM) should not
  * use this hook, because the helper library calls it only once 

[PATCH v7 1/3] drm/bridge/synopsys: dsi: stop clobbering drvdata

[Nickey Yang]

From: Brian Norris 

Bridge drivers/helpers shouldn't be clobbering the drvdata, since a
parent driver might need to own this. Instead, let's return our
'dw_mipi_dsi' object and have callers pass that back to us for removal.

Signed-off-by: Brian Norris 
Signed-off-by: Nickey Yang 
Link:https://patchwork.kernel.org/patch/10078493/

---
Changes

v4:
- Add From tag,update subject line
- keep patch "drm/stm: dsi: Adjust dw_mipi_dsi_probe and remove"
  in this piece together.

v5:
- remove Review & Ack tag
- fix remove() directly referencing the static
  dw_mipi_dsi_stm_plat_data struct.

v7:
- add missing platform_set_drvdata in stm part.

 drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 36 ++-
 drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 12 ++---
 include/drm/bridge/dw_mipi_dsi.h  | 17 -
 3 files changed, 32 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index d9cca4f..c39c7dc 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -922,8 +922,6 @@ static int dw_mipi_dsi_bridge_attach(struct drm_bridge 
*bridge)
dsi->bridge.of_node = pdev->dev.of_node;
 #endif
 
-   dev_set_drvdata(dev, dsi);
-
return dsi;
 }
 
@@ -935,23 +933,16 @@ static void __dw_mipi_dsi_remove(struct dw_mipi_dsi *dsi)
 /*
  * Probe/remove API, used from platforms based on the DRM bridge API.
  */
-int dw_mipi_dsi_probe(struct platform_device *pdev,
- const struct dw_mipi_dsi_plat_data *plat_data)
+struct dw_mipi_dsi *
+dw_mipi_dsi_probe(struct platform_device *pdev,
+ const struct dw_mipi_dsi_plat_data *plat_data)
 {
-   struct dw_mipi_dsi *dsi;
-
-   dsi = __dw_mipi_dsi_probe(pdev, plat_data);
-   if (IS_ERR(dsi))
-   return PTR_ERR(dsi);
-
-   return 0;
+   return __dw_mipi_dsi_probe(pdev, plat_data);
 }
 EXPORT_SYMBOL_GPL(dw_mipi_dsi_probe);
 
-void dw_mipi_dsi_remove(struct platform_device *pdev)
+void dw_mipi_dsi_remove(struct dw_mipi_dsi *dsi)
 {
-   struct dw_mipi_dsi *dsi = platform_get_drvdata(pdev);
-
mipi_dsi_host_unregister(>dsi_host);
 
__dw_mipi_dsi_remove(dsi);
@@ -961,31 +952,30 @@ void dw_mipi_dsi_remove(struct platform_device *pdev)
 /*
  * Bind/unbind API, used from platforms based on the component framework.
  */
-int dw_mipi_dsi_bind(struct platform_device *pdev, struct drm_encoder *encoder,
-const struct dw_mipi_dsi_plat_data *plat_data)
+struct dw_mipi_dsi *
+dw_mipi_dsi_bind(struct platform_device *pdev, struct drm_encoder *encoder,
+const struct dw_mipi_dsi_plat_data *plat_data)
 {
struct dw_mipi_dsi *dsi;
int ret;
 
dsi = __dw_mipi_dsi_probe(pdev, plat_data);
if (IS_ERR(dsi))
-   return PTR_ERR(dsi);
+   return dsi;
 
ret = drm_bridge_attach(encoder, >bridge, NULL);
if (ret) {
-   dw_mipi_dsi_remove(pdev);
+   dw_mipi_dsi_remove(dsi);
DRM_ERROR("Failed to initialize bridge with drm\n");
-   return ret;
+   return ERR_PTR(ret);
}
 
-   return 0;
+   return dsi;
 }
 EXPORT_SYMBOL_GPL(dw_mipi_dsi_bind);
 
-void dw_mipi_dsi_unbind(struct device *dev)
+void dw_mipi_dsi_unbind(struct dw_mipi_dsi *dsi)
 {
-   struct dw_mipi_dsi *dsi = dev_get_drvdata(dev);
-
__dw_mipi_dsi_remove(dsi);
 }
 EXPORT_SYMBOL_GPL(dw_mipi_dsi_unbind);
diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c 
b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
index e5b6310..c1ed691 100644
--- a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
+++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
@@ -66,6 +66,7 @@ enum dsi_color {
 struct dw_mipi_dsi_stm {
void __iomem *base;
struct clk *pllref_clk;
+   struct dw_mipi_dsi *dmd;
 };
 
 static inline void dsi_write(struct dw_mipi_dsi_stm *dsi, u32 reg, u32 val)
@@ -290,6 +291,8 @@ static int dw_mipi_dsi_stm_probe(struct platform_device 
*pdev)
if (!dsi)
return -ENOMEM;
 
+   platform_set_drvdata(pdev, dsi);
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
DRM_ERROR("Unable to get resource\n");
@@ -318,10 +321,11 @@ static int dw_mipi_dsi_stm_probe(struct platform_device 
*pdev)
dw_mipi_dsi_stm_plat_data.base = dsi->base;
dw_mipi_dsi_stm_plat_data.priv_data = dsi;
 
-   ret = dw_mipi_dsi_probe(pdev, _mipi_dsi_stm_plat_data);
-   if (ret) {
+   dsi->dmd = dw_mipi_dsi_probe(pdev, _mipi_dsi_stm_plat_data);
+   if (IS_ERR(dsi->dmd)) {
DRM_ERROR("Failed to initialize mipi dsi host\n");
clk_disable_unprepare(dsi->pllref_clk);
+   return PTR_ERR(dsi->dmd);
}
 
return 

[PATCH v7 3/3] drm/rockchip: Add ROCKCHIP DW MIPI DSI controller driver

[Nickey Yang]

Add the ROCKCHIP DSI controller driver that uses the Synopsys DesignWare
MIPI DSI host controller bridge.

Signed-off-by: Nickey Yang 
Signed-off-by: Brian Norris 
Reviewed-by: Brian Norris 
Reviewed-by: Sean Paul 
---
changes:

v2:
   add err_pllref, remove unnecessary encoder.enable & disable
   correct spelling mistakes
v3:
   call dw_mipi_dsi_unbind() in dw_mipi_dsi_rockchip_unbind()
   fix typo, use of_device_get_match_data(),
   change some ‘bind()’ logic into 'probe()'
   add 'dev_set_drvdata()'
v4:
  return -EINVAL when can not get best_freq
  add a clarifying comment when get vco
  add review tag
v5:
  keep our power domain enabled while touching GRF
v6:
  change func name dw_mipi_encoder_disable to
  dw_mipi_dsi_encoder_disable

 drivers/gpu/drm/rockchip/Kconfig|2 +-
 drivers/gpu/drm/rockchip/Makefile   |2 +-
 drivers/gpu/drm/rockchip/dw-mipi-dsi.c  | 1349 ---
 drivers/gpu/drm/rockchip/dw-mipi-dsi_rockchip.c |  785 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c |2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h |2 +-
 6 files changed, 789 insertions(+), 1353 deletions(-)
 delete mode 100644 drivers/gpu/drm/rockchip/dw-mipi-dsi.c
 create mode 100644 drivers/gpu/drm/rockchip/dw-mipi-dsi_rockchip.c

diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 0ccc762..9eb4795 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -7,7 +7,7 @@ config DRM_ROCKCHIP
select VIDEOMODE_HELPERS
select DRM_ANALOGIX_DP if ROCKCHIP_ANALOGIX_DP
select DRM_DW_HDMI if ROCKCHIP_DW_HDMI
-   select DRM_MIPI_DSI if ROCKCHIP_DW_MIPI_DSI
+   select DRM_DW_MIPI_DSI if ROCKCHIP_DW_MIPI_DSI
select SND_SOC_HDMI_CODEC if ROCKCHIP_CDN_DP && SND_SOC
help
  Choose this option if you have a Rockchip soc chipset.
diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
index a314e21..c05fe47 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -11,7 +11,7 @@ rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += 
rockchip_drm_fbdev.o
 rockchipdrm-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
 rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o
 rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
-rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
+rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi_rockchip.o
 rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
 rockchipdrm-$(CONFIG_ROCKCHIP_LVDS) += rockchip_lvds.o
 
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
deleted file mode 100644
index b15755b..000
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ /dev/null
@@ -1,1349 +0,0 @@
-/*
- * Copyright (c) 2016, Fuzhou Rockchip Electronics Co., Ltd
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- */
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include "rockchip_drm_drv.h"
-#include "rockchip_drm_vop.h"
-
-#define DRIVER_NAME"dw-mipi-dsi"
-
-#define RK3288_GRF_SOC_CON60x025c
-#define RK3288_DSI0_SEL_VOP_LITBIT(6)
-#define RK3288_DSI1_SEL_VOP_LITBIT(9)
-
-#define RK3399_GRF_SOC_CON20   0x6250
-#define RK3399_DSI0_SEL_VOP_LITBIT(0)
-#define RK3399_DSI1_SEL_VOP_LITBIT(4)
-
-/* disable turnrequest, turndisable, forcetxstopmode, forcerxmode */
-#define RK3399_GRF_SOC_CON22   0x6258
-#define RK3399_GRF_DSI_MODE0x
-
-#define DSI_VERSION0x00
-#define DSI_PWR_UP 0x04
-#define RESET  0
-#define POWERUPBIT(0)
-
-#define DSI_CLKMGR_CFG 0x08
-#define TO_CLK_DIVIDSION(div)  (((div) & 0xff) << 8)
-#define TX_ESC_CLK_DIVIDSION(div)  (((div) & 0xff) << 0)
-
-#define DSI_DPI_VCID   0x0c
-#define DPI_VID(vid)   (((vid) & 0x3) << 0)
-
-#define DSI_DPI_COLOR_CODING   0x10
-#define EN18_LOOSELY   BIT(8)
-#define DPI_COLOR_CODING_16BIT_1   0x0
-#define DPI_COLOR_CODING_16BIT_2   0x1
-#define DPI_COLOR_CODING_16BIT_3   0x2
-#define DPI_COLOR_CODING_18BIT_1   0x3
-#define DPI_COLOR_CODING_18BIT_2   0x4
-#define DPI_COLOR_CODING_24BIT 0x5
-
-#define DSI_DPI_CFG_POL0x14
-#define 

[PATCH v7 0/3] Update ROCKCHIP DSI driver that uses dw-mipi-dsi bridge

[Nickey Yang]

We now have a generic dw-mipi-dsi bridge driver.So we send
this patchs to moving rockchip dw-mipi-dsi driver to that
in order to add new features(dual mipi support).
Update ROCKCHIP DSI controller driver that uses the Synopsys
DesignWare MIPI DSI host controller bridge.

ChangeLog:
v2:
   add err_pllref、remove unnecessary encoder.enable & disable
   correct spelling mistakes
v3:
   add Brian's patch "drm/bridge/synopsys: stop clobbering drvdata"
   (Link:https://patchwork.kernel.org/patch/10078493/)
   adjust drm/stm/dsi code for above
   drm/rockchip: Add ROCKCHIP DW MIPI DSI controller driver:
   call dw_mipi_dsi_unbind() in dw_mipi_dsi_rockchip_unbind()
   fix typo, use of_device_get_match_data(),
   change some ‘bind()’ logic into 'probe()'
   add 'dev_set_drvdata()'
v4:
   keep "drm/stm: dsi: Adjust dw_mipi_dsi_probe and remove"
   into Brians "drm/bridge/synopsys: stop clobbering drvdata"
   add review tag and add some comments 
v5:
  1/3: fix stm part remove() directly referencing the static
   dw_mipi_dsi_stm_plat_data struct.
  3/3: keep our power domain enabled while touching GRF
v6:
  3/3: just change func dw_mipi_encoder_disable name to
   dw_mipi_dsi_encoder_disable
v7:
  1/3: add missing platform_set_drvdata in stm part.

Nickey Yang (3):
  drm/bridge/synopsys: dsi: stop clobbering drvdata
  dt-bindings: display: rockchip: update DSI controller
  drm/rockchip: Add ROCKCHIP DW MIPI DSI controller driver

 .../display/rockchip/dw_mipi_dsi_rockchip.txt  |   23 +-
 drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c  |   36 +-
 drivers/gpu/drm/rockchip/Kconfig   |2 +-
 drivers/gpu/drm/rockchip/Makefile  |2 +-
 drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 1349 
 drivers/gpu/drm/rockchip/dw-mipi-dsi_rockchip.c|  785 
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c|2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h|2 +-
 drivers/gpu/drm/stm/dw_mipi_dsi-stm.c  |   12 +-
 include/drm/bridge/dw_mipi_dsi.h   |   17 +-
 10 files changed, 842 insertions(+), 1388 deletions(-)
 delete mode 100644 drivers/gpu/drm/rockchip/dw-mipi-dsi.c
 create mode 100644 drivers/gpu/drm/rockchip/dw-mipi-dsi_rockchip.c

-- 
1.9.1

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

[PATCH v7 2/3] dt-bindings: display: rockchip: update DSI controller

[Nickey Yang]

This patch update describe panel/port links, including
unit addresses in documentation of device tree bindings
for the rockchip DSI controller based on the Synopsys
DesignWare MIPI DSI host controller.

Signed-off-by: Nickey Yang 
Reviewed-by: Brian Norris 
---
 .../display/rockchip/dw_mipi_dsi_rockchip.txt  | 23 --
 1 file changed, 21 insertions(+), 2 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt 
b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
index 6bb59ab..ce4c1fc 100644
--- 
a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
+++ 
b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
@@ -14,6 +14,8 @@ Required properties:
 - rockchip,grf: this soc should set GRF regs to mux vopl/vopb.
 - ports: contain a port node with endpoint definitions as defined in [2].
   For vopb,set the reg = <0> and set the reg = <1> for vopl.
+- video port 0 for the VOP input, the remote endpoint maybe vopb or vopl
+- video port 1 for either a panel or subsequent encoder
 
 Optional properties:
 - power-domains: a phandle to mipi dsi power domain node.
@@ -40,11 +42,12 @@ Example:
ports {
#address-cells = <1>;
#size-cells = <0>;
-   reg = <1>;
 
-   mipi_in: port {
+   mipi_in: port@0 {
+   reg = <0>;
#address-cells = <1>;
#size-cells = <0>;
+
mipi_in_vopb: endpoint@0 {
reg = <0>;
remote-endpoint = <_out_mipi>;
@@ -54,6 +57,16 @@ Example:
remote-endpoint = <_out_mipi>;
};
};
+
+   mipi_out: port@1 {
+   reg = <1>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   mipi_out_panel: endpoint {
+   remote-endpoint = <_in_mipi>;
+   };
+   };
};
 
panel {
@@ -64,5 +77,11 @@ Example:
pinctrl-names = "default";
pinctrl-0 = <_en>;
backlight = <>;
+
+   port {
+   panel_in_mipi: endpoint {
+   remote-endpoint = <_out_panel>;
+   };
+   };
};
};
-- 
1.9.1

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

[Bug 198123] Console is the wrong color at boot with radeon 6670

[bugzilla-daemon]

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

--- Comment #2 from Deposite Pirate (dpir...@metalpunks.info) ---
(In reply to Alex Deucher from comment #1)
> Can you bisect?

Hi,

I'm working on it. I haven't compiled a kernel in a few years so I had to set
up all this stuff. This PC is quite slow, so it might take me a few days before
I find the commit with the problem.

-- 
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 197851] Resume from suspend sometimes results in black screen on Radeon R5

[bugzilla-daemon]

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

Tyler McLean (sonarsoundapplicati...@gmail.com) changed:

   What|Removed |Added

 Kernel Version|4.14.0-041400rc8-generic|4.15.0-041500rc2-generic

-- 
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 02/13] fbdev: add remove_conflicting_pci_framebuffers()

[Sudip Mukherjee]

Hi Emil,

On Fri, Dec 01, 2017 at 02:40:11PM +, Emil Velikov wrote:
> On 30 November 2017 at 23:49, Sudip Mukherjee
>  wrote:
> > Hi Daniel,
> >
> > On Wed, Nov 29, 2017 at 10:56:34AM +0100, Daniel Vetter wrote:

> > submit it to dri-devel.
> >
> A crazy idea, mostly towards Tedd and Sudip:
> 
> Start small and build gradually. An example split for separate patch series:
> 
>  - one HW, basic setup + atomic KMS
>  - add second HW
>  - more KMS features
>  - fancy memory management
>  - 2D/3D/other acceleration
> 
> The driver as seen above tries to do all of the above (almost, it's not 
> atomic)
> at once - 40k loc.
> 
> Someone familiar with the code can quickly split it up and while doing
> so, feed it through checkpatch.

I can try but will be very tough since I have to go through the code to
get familiar with it and, as mentioned before, its not part of my dayjob,
so time will be a problem. Developing from scratch takes much more time
than fixing something.

> Current code is _very_ far from kernel coding style, plus the
> copyright blurp is very disturbing:

I will fix the coding style before my first submission to dri-devel,
which should be in January after I have setup my desktop with the
hardware for testing.

The copyright thing - I am sure Teddy can talk to his company and will
confirm that we can change it to the way kernel code is done.

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

[Bug 103277] [bisected] Systems hangs on resume from S3 sleep due to "Match actual state during S3 resume" commit

[bugzilla-daemon]

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

--- Comment #4 from jerry@amd.com ---
(In reply to dwagner from comment #3)
> (In reply to Jordan L from comment #2)
> > Thanks, we can reproduce this too, should have something shortly.
> 
> Any news on this?
> 
> I am asking, because the current head of
> https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next (as of
> commit d66bebab317cc56a2a6d2438fcd89870c3d172ca) still has this very bug -
> and that is even though within "git log" I can see in commit
> 26c860d5579684528114c3875ef88f7796330eb5 there was
> > Revert "drm/amd/display: Match actual state during S3 resume."
> so I currently know of no way to make the current amd-staging-drm-next
> resume from S3 sleep.

S3 starts working since commit 95539e2be57. 

Test is performed on the following condition:
Commit: c6f284d9888
Asic: Baffin
4K display: Acer H277HK
S3 passed in 10 runs

Please verify at your side as well. Thanks.

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

Re: [PATCH v2 2/2] drm/tinydrm: add driver for ST7735R panels

[Noralf Trønnes]

Den 10.12.2017 23.10, skrev David Lechner:

This adds a new driver for Sitronix ST7735R display panels.

This has been tested using an Adafruit 1.8" TFT.

Signed-off-by: David Lechner 
---



+static void st7735r_pipe_enable(struct drm_simple_display_pipe *pipe,
+   struct drm_crtc_state *crtc_state)
+{
+   struct tinydrm_device *tdev = pipe_to_tinydrm(pipe);
+   struct mipi_dbi *mipi = mipi_dbi_from_tinydrm(tdev);
+   struct device *dev = tdev->drm->dev;
+   int ret;
+   u8 addr_mode;
+
+   DRM_DEBUG_KMS("\n");
+
+   mipi_dbi_hw_reset(mipi);
+
+   ret = mipi_dbi_command(mipi, MIPI_DCS_SOFT_RESET);
+   if (ret) {
+   DRM_DEV_ERROR(dev, "Error sending command %d\n", ret);
+   return;
+   }
+
+   msleep(150);
+
+   mipi_dbi_command(mipi, MIPI_DCS_EXIT_SLEEP_MODE);
+   msleep(500);
+
+   mipi_dbi_command(mipi, ST7735R_FRMCTR1, 0x01, 0x2c, 0x2d);
+   mipi_dbi_command(mipi, ST7735R_FRMCTR2, 0x01, 0x2c, 0x2d);
+   mipi_dbi_command(mipi, ST7735R_FRMCTR3, 0x01, 0x2c, 0x2d, 0x01, 0x2c,
+0x2d);
+   mipi_dbi_command(mipi, ST7735R_INVCTR, 0x07);
+   mipi_dbi_command(mipi, ST7735R_PWCTR1, 0xa2, 0x02, 0x84);
+   mipi_dbi_command(mipi, ST7735R_PWCTR2, 0xc5);
+   mipi_dbi_command(mipi, ST7735R_PWCTR3, 0x0a, 0x00);
+   mipi_dbi_command(mipi, ST7735R_PWCTR4, 0x8a, 0x2a);
+   mipi_dbi_command(mipi, ST7735R_PWCTR5, 0x8a, 0xee);
+   mipi_dbi_command(mipi, ST7735R_VMCTR1, 0x0e);
+   mipi_dbi_command(mipi, MIPI_DCS_EXIT_INVERT_MODE);
+   switch (mipi->rotation) {
+   default:
+   addr_mode = ST7735R_MX | ST7735R_MY;
+   break;
+   case 90:
+   addr_mode = ST7735R_MX | ST7735R_MV;
+   break;
+   case 180:
+   addr_mode = 0;
+   break;
+   case 270:
+   addr_mode = ST7735R_MY | ST7735R_MV;
+   break;
+   }
+   mipi_dbi_command(mipi, MIPI_DCS_SET_ADDRESS_MODE, addr_mode);
+   mipi_dbi_command(mipi, MIPI_DCS_SET_PIXEL_FORMAT,
+MIPI_DCS_PIXEL_FMT_16BIT);
+   mipi_dbi_command(mipi, ST7735R_GAMCTRP1, 0x0f, 0x1a, 0x0f, 0x18, 0x2f,
+0x28, 0x20, 0x22, 0x1f, 0x1b, 0x23, 0x37, 0x00, 0x07,
+0x02, 0x10);
+   mipi_dbi_command(mipi, ST7735R_GAMCTRN1, 0x0f, 0x1b, 0x0f, 0x17, 0x33,
+0x2c, 0x29, 0x2e, 0x30, 0x30, 0x39, 0x3f, 0x00, 0x07,
+0x03, 0x10);
+   mipi_dbi_command(mipi, MIPI_DCS_SET_DISPLAY_ON);
+
+   msleep(100);
+
+   mipi_dbi_command(mipi, MIPI_DCS_ENTER_NORMAL_MODE);
+
+   msleep(20);
+
+   mipi_dbi_pipe_enable(pipe, crtc_state);
+}
+
+static const struct drm_simple_display_pipe_funcs st7735r_pipe_funcs = {
+   .enable = st7735r_pipe_enable,
+   .disable= mipi_dbi_pipe_disable,
+   .update = tinydrm_display_pipe_update,
+   .prepare_fb = tinydrm_display_pipe_prepare_fb,
+};
+
+static const struct drm_display_mode st7735r_mode = {
+   TINYDRM_MODE(128, 160, 28, 35),
+};


This naming talk has made me realise that these should be named after
the panel since they're not generic controller functions.
Maybe the mode can be generic, not sure if the physical size can/will
differ, the resolution is very likely to be the same for all.

What's your view on my descision to split the MIPI DBI compatible
controllers into per controller drivers instead of having one driver
that supports them all?
I've been afraid that it will be a very big file with macro definitions
per controller and enable functions per panel.

This driver has 15 macros and ~80 panel specific lines.
With one panel supported, half the driver is boilerplate.
The mi0283qt panel (MIPI DBI compatible) is in the same ballpark.

Adding helpers for panel reset/exit_sleep, for MIPI_DCS_SET_ADDRESS_MODE
and for display_on/enter_normal/flush could cut it down some more if we
made one driver to rule them all. Maybe the enable function per panel
could be cut in half that way.

I'm starting to wonder if one driver isn't such a bad solution after all...

Noralf.

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

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

[Daniel Vetter]

On Mon, Dec 11, 2017 at 02:38:53PM +, Tvrtko Ursulin wrote:
> On 11/12/2017 10:50, Joonas Lahtinen wrote:
> > + Daniel, Chris
> > 
> > On Thu, 2017-12-07 at 09:21 +, Tvrtko Ursulin wrote:
> > > On 04/12/2017 15:02, Lionel Landwerlin wrote:
> > > > Hi,
> > > > 
> > > > After discussion with Chris, Joonas & Tvrtko, this series adds an
> > > > additional commit to link the render node back to the card through a
> > > > symlink. Making it obvious from an application using a render node to
> > > > know where to get the information it needs.
> > > 
> > > Important thing to mention as well is that it is trivial to get from the
> > > master drm fd to the sysfs root, via fstat and opendir
> > > /sys/dev/char/:. With the addition of the card symlink to
> > > render nodes it is trivial for render node fd as well.
> > > 
> > > I am happy with this approach - it is extensible, flexible and avoids
> > > issues with ioctl versioning or whatnot. With one value per file it is
> > > trivial for userspace to access.
> > > 
> > > So for what I'm concerned, given how gputop would use all of this and so
> > > be the userspace, if everyone else is happy, I think we could do a
> > > detailed review and prehaps also think about including gputop in some
> > > distribution to make the case 100% straightforward.
> > 
> > For the GPU topology I agree this is the right choice, it's going to be
> > about topology after all, and directory tree is the perfect candidate.
> > And if a new platform appears, then it's a new platform and may change
> > the topology well the hardware topology has changed.
> > 
> > For the engine enumeration, I'm not equally sold for sysfs exposing it.
> > It's a "linear list of engine instances with flags" how the userspace
> > is going to be looking at them. And it's also information about what to
> > pass to an IOCTL as arguments after decision has been made, and then
> > you already have the FD you know you'll be dealing with, at hand. So
> > another IOCTL for that seems more convenient.
> 
> Apart from more flexibility and easier to extend, sysfs might be a better
> fit for applications which do not otherwise need a drm fd. Say a top-like
> tool which shows engine utilization, or those patches I RFC-ed recently
> which do the same but per DRM client.
> 
> Okay, these stats are now available also via PMU so the argument is not the
> strongest I admit, but I still find it quite neat. It also might allow us to
> define our own policy with regards to needed privilege to access these
> stats, and not be governed by the perf API rules.

How exactly is sysfs easier to extend than ioctl? There's lots of
serializing and deserializing going on, ime that's more boilerplate. Imo
the only reason for sysfs is when you _must_ access it without having an
fd to the gpu. The inverse is generally not true (i.e. using sysfs when
you have the fd already), and as soon as you add a writeable field here
you're screwed (because sysfs can't be passed to anyone else but root,
compared to drm fd - viz the backlight fiasco).

But even without writeable fields: Think of highly contained
containers/clients which only get the drm fd to render. If sysfs is gone,
will they fall on their faces? Atm "drm fd is all you need" is very deeply
ingrained into our various OS stacks.
-Daniel

> > So I'd say for the GPU topology part, we go forward with the review and
> > make sure we don't expose driver internal bits that could break when
> > refactoring code. If the exposed N bits of information are strictly
> > tied to the underlying hardware, we should have no trouble maintaining
> > that for the foreseeable future.
> > 
> > Then we can continue on about the engine discovery in parallel, not
> > blocking GPU topology discovery.
> 
> I can live with that, but would like to keep the gt/engines/ namespace
> reserved for the eventuality with go with engine info in sysfs at a later
> stage then.
> 
> Also, Lionel, did you have plans to use the engine info straight away in gpu
> top, or you only needed topology? I think you were drawing a nice block
> diagram of a GPU so do you need it for that?
> 
> Regards,
> 
> Tvrtko

-- 
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 v2 13/14] drm: rcar-du: Restrict DPLL duty cycle workaround to H3 ES1.x

[Laurent Pinchart]

Hi Kieran,

I found this e-mail already written and sitting in my outbox, so even if it's 
quite outdated I decided to still send it.

On Tuesday 01 Aug 2017 15:06:20 Kieran Bingham wrote:
> On 26/06/17 19:12, Laurent Pinchart wrote:
> > The H3 ES1.x exhibits dot clock duty cycle stability issues. We can work
> > around them by configuring the DPLL to twice the desired frequency,
> > coupled with a /2 post-divider. This isn't needed on other SoCs and
> > breaks HDMI output on M3-W for a currently unknown reason, so restrict
> > the workaround to H3 ES1.x.
> > 
> > From an implementation point of view, move work around handling outside
> > of the rcar_du_dpll_divider() function by requesting a x2 DPLL output
> > frequency explicitly. The existing post-divider calculation mechanism
> > will then take care of dividing the clock by two automatically.
> > 
> > While at it, print a more useful debugging message to ease debugging
> > clock rate issues.
> > 
> > Signed-off-by: Laurent Pinchart
> > 
> > ---
> > 
> >  drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 37 -
> >  1 file changed, 27 insertions(+), 10 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c index 8f942ebdd0c6..6c29981377c0
> > 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > @@ -13,6 +13,7 @@
> > 
> >  #include 
> >  #include 
> > +#include 
> > 
> >  #include 
> >  #include 
> > @@ -129,10 +130,8 @@ static void rcar_du_dpll_divider(struct rcar_du_crtc
> > *rcrtc,
> > for (fdpll = 1; fdpll < 32; fdpll++) {
> > unsigned long output;
> > 
> > -   /* 1/2 (FRQSEL=1) for duty rate 50% */
> > output = input * (n + 1) / (m + 1)
> > -  / (fdpll + 1) / 2;
> > -
> > +  / (fdpll + 1);
> 
> I'm finding this hard to interpret vs the commit-message.
> 
> Here we remove the /2 (which affects all targets... is this a problem?)

The purpose of the rcar_du_dpll_divider() function is to compute the DPLL 
settings for a target output frequency. However, at the moment, it computes 
settings that will generate twice the output frequency, assuming that the 
caller will configure an additional /2 post-divider.

I found that confusing, so I've modified this function to generate the target 
output frequency. The caller is modified below to request twice the desired 
display clock frequency when adding the post-divider.

Note that DPLLs are available on Gen3 only, so this affects H3 and M3-W only.

> > if (output >= 4)
> > continue;

[snip]

> > @@ -185,7 +189,20 @@ static void rcar_du_crtc_set_display_timing(struct
> > rcar_du_crtc *rcrtc)> 
> > extclk = clk_get_rate(rcrtc->extclock);
> > if (rcdu->info->dpll_ch & (1 << rcrtc->index)) {
> > 
> > -   rcar_du_dpll_divider(rcrtc, , extclk,
> > mode_clock);
> > +   unsigned long target = mode_clock;
> > +
> > +   /*
> > +* The H3 ES1.x exhibits dot clock duty cycle
> > stability
> > +* issues. We can work around them by configuring the
> > +* DPLL to twice the desired frequency, coupled with a
> > +* /2 post-divider. This isn't needed on other SoCs
> > and
> 
> But here we discuss 'coupling' it with a /2 post - divider.
> 
> My inference here then is that by setting a target that is 'twice' the value
> - code later will provide the /2 post-divide?

Correct. On H3 ES1.x the behaviour of the code is unchanged, while on H3 ES2.0 
and M3-W we now configure the DPLL without the post-divider.

> > +* breaks HDMI output on M3-W for a currently unknown
> > +* reason, so restrict the workaround to H3 ES1.x.
> > +*/
> > +   if (soc_device_match(rcar_du_r8a7795_es1))
> > +   target *= 2;
> > +
> > +   rcar_du_dpll_divider(rcrtc, , extclk, target);
> > extclk = dpll.output;
> > }
> > 
> > @@ -197,8 +214,6 @@ static void rcar_du_crtc_set_display_timing(struct
> > rcar_du_crtc *rcrtc)
> > if (abs((long)extrate - (long)mode_clock) <
> > abs((long)rate - (long)mode_clock)) {
> > -   dev_dbg(rcrtc->group->dev->dev,
> > -   "crtc%u: using external clock\n",
> > rcrtc->index);
> > 
> > if (rcdu->info->dpll_ch & (1 << rcrtc->index)) {
> > u32 dpllcr = DPLLCR_CODE | DPLLCR_CLKE
> > @@ -215,12 +230,14 @@ static void rcar_du_crtc_set_display_timing(struct
> > rcar_du_crtc *rcrtc)
> > 

Re: [PATCH 25/25] drm/armada: add iturbt_709 plane property to control YUV colorspace

[Daniel Vetter]

On Fri, Dec 08, 2017 at 12:31:08PM +, Russell King wrote:
> Add the defacto-standard "iturbt_709" property to the overlay plane to
> control the YUV to RGB colorspace conversion.  This is mutually
> exclusive with the CSC_YUV CRTC property - the last property to be set
> determines the resulting colorspace conversion.
> 
> Signed-off-by: Russell King 

Can you pls provide a link to the corresponding userspace code using this?

Thanks, Daniel

> ---
>  drivers/gpu/drm/armada/armada_crtc.c| 26 +++---
>  drivers/gpu/drm/armada/armada_crtc.h|  2 ++
>  drivers/gpu/drm/armada/armada_drm.h |  1 +
>  drivers/gpu/drm/armada/armada_overlay.c | 25 ++---
>  4 files changed, 48 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
> b/drivers/gpu/drm/armada/armada_crtc.c
> index 8b66377a4890..1bf632bb8855 100644
> --- a/drivers/gpu/drm/armada/armada_crtc.c
> +++ b/drivers/gpu/drm/armada/armada_crtc.c
> @@ -535,12 +535,30 @@ static irqreturn_t armada_drm_irq(int irq, void *arg)
>   return IRQ_NONE;
>  }
>  
> +void armada_drm_crtc_set_yuv_colorimetry(struct armada_crtc *dcrtc, u32 csc)
> +{
> + armada_updatel(csc, CFG_CSC_YUV_CCIR709,
> +dcrtc->base + LCD_SPU_IOPAD_CONTROL);
> +
> + dcrtc->csc_yuv_ovl_mode = csc == CFG_CSC_YUV_CCIR709 ?
> + CSC_YUV_CCIR709 : CSC_YUV_CCIR601;
> +}
> +
>  static uint32_t armada_drm_crtc_calculate_csc(struct armada_crtc *dcrtc)
>  {
>   struct drm_display_mode *adj = >crtc.mode;
> - uint32_t val = 0;
> + u32 val = 0;
> + u8 csc_yuv_mode;
> +
> + /*
> +  * If the iturbt_709 overlay plane property is used, it overrides
> +  * the CSC_YUV crtc property until the CSC_YUV property is set.
> +  */
> + csc_yuv_mode = dcrtc->csc_yuv_ovl_mode;
> + if (csc_yuv_mode == CSC_AUTO)
> + csc_yuv_mode = dcrtc->csc_yuv_mode;
>  
> - if (dcrtc->csc_yuv_mode == CSC_YUV_CCIR709)
> + if (csc_yuv_mode == CSC_YUV_CCIR709)
>   val |= CFG_CSC_YUV_CCIR709;
>   if (dcrtc->csc_rgb_mode == CSC_RGB_STUDIO)
>   val |= CFG_CSC_RGB_STUDIO;
> @@ -555,7 +573,7 @@ static uint32_t armada_drm_crtc_calculate_csc(struct 
> armada_crtc *dcrtc)
>   if ((adj->hdisplay == 1280 && adj->vdisplay == 720 &&
>!(adj->flags & DRM_MODE_FLAG_INTERLACE)) ||
>   (adj->hdisplay == 1920 && adj->vdisplay == 1080)) {
> - if (dcrtc->csc_yuv_mode == CSC_AUTO)
> + if (csc_yuv_mode == CSC_AUTO)
>   val |= CFG_CSC_YUV_CCIR709;
>   }
>  
> @@ -1094,6 +1112,7 @@ armada_drm_crtc_set_property(struct drm_crtc *crtc,
>  
>   if (property == priv->csc_yuv_prop) {
>   dcrtc->csc_yuv_mode = val;
> + dcrtc->csc_yuv_ovl_mode = CSC_AUTO;
>   update_csc = true;
>   } else if (property == priv->csc_rgb_prop) {
>   dcrtc->csc_rgb_mode = val;
> @@ -1396,6 +1415,7 @@ static int armada_drm_crtc_create(struct drm_device 
> *drm, struct device *dev,
>   dcrtc->num = drm->mode_config.num_crtc;
>   dcrtc->clk = ERR_PTR(-EINVAL);
>   dcrtc->csc_yuv_mode = CSC_AUTO;
> + dcrtc->csc_yuv_ovl_mode = CSC_AUTO;
>   dcrtc->csc_rgb_mode = CSC_AUTO;
>   dcrtc->cfg_dumb_ctrl = DUMB24_RGB888_0;
>   dcrtc->spu_iopad_ctrl = CFG_VSCALE_LN_EN | CFG_IOPAD_DUMB24;
> diff --git a/drivers/gpu/drm/armada/armada_crtc.h 
> b/drivers/gpu/drm/armada/armada_crtc.h
> index 445829b8877a..5d70b4af20b7 100644
> --- a/drivers/gpu/drm/armada/armada_crtc.h
> +++ b/drivers/gpu/drm/armada/armada_crtc.h
> @@ -90,6 +90,7 @@ struct armada_crtc {
>   boolinterlaced;
>   boolcursor_update;
>   uint8_t csc_yuv_mode;
> + uint8_t csc_yuv_ovl_mode;
>   uint8_t csc_rgb_mode;
>  
>   struct drm_plane*plane;
> @@ -113,6 +114,7 @@ struct armada_crtc {
>  #define drm_to_armada_crtc(c) container_of(c, struct armada_crtc, crtc)
>  
>  void armada_drm_crtc_update_regs(struct armada_crtc *, struct armada_regs *);
> +void armada_drm_crtc_set_yuv_colorimetry(struct armada_crtc *dcrtc, u32 csc);
>  
>  int armada_drm_plane_disable(struct drm_plane *plane,
>struct drm_modeset_acquire_ctx *ctx);
> diff --git a/drivers/gpu/drm/armada/armada_drm.h 
> b/drivers/gpu/drm/armada/armada_drm.h
> index b064879ecdbd..45d5168d5748 100644
> --- a/drivers/gpu/drm/armada/armada_drm.h
> +++ b/drivers/gpu/drm/armada/armada_drm.h
> @@ -60,6 +60,7 @@ struct armada_private {
>   struct armada_crtc  *dcrtc[2];
>   struct drm_mm   linear; /* protected by linear_lock */
>   struct mutexlinear_lock;
> + struct drm_property *iturbt709_prop;
>   struct drm_property *csc_yuv_prop;
>   struct drm_property *csc_rgb_prop;
>   struct 

Re: [Intel-gfx] linux-next: Signed-off-by missing for commit in the drm-intel-fixes tree

[Daniel Vetter]

On Mon, Dec 11, 2017 at 12:31:06PM +0200, Joonas Lahtinen wrote:
> + GVT folks.
> 
> On Fri, 2017-12-08 at 09:15 +1100, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Commit
> > 
> >   365ad5df9caa ("drm/i915/gvt: Export
> > intel_gvt_render_mmio_to_ring_id()")
> > 
> > is missing a Signed-off-by from its committer.

We also patched our pull processing script to check for this in the
future.
-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 libdrm] android: make libdrm*.so available to the vendor partition

[Emil Velikov]

On 11 December 2017 at 03:51, Chih-Wei Huang  wrote:

> Please rebase to the latest master and re-submit the patch.
> In particular, please consider the master already has
> a Rob Herring's patch which moved libdrm* to /vendor.
>
This please.

>
>
> 2017-07-26 18:08 GMT+08:00 Jiyong Park :
>> libdrm_.so are moved to the vendor partition (/vendor/lib or
>> /system/vendor/lib if there is no dedicated vendor partition), since
>> they are vendor-specific extension that must not be in the system
>> partition which should be generic.
>>
>> libdrm.so (which is generic) is built/installed twice: once to
>> /vendor/lib to satisfy the dependency for the libdrm_.so libs
>> and once to /system/lib for platform clients such as the recovery
>> executable.
>>
Strange I though we already have both issues addressed?
Admittedly the /vendor move was recent, although the static build of
libdrm (for recovery) has been around for ages.

Аre you saying that despite that it's around latest AOSP does not pick it up?
Can you share a bit more light on the topic?

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

Re: [PATCH] [v2] drm/i915: use static const array for PICK macro

[Chris Wilson]

Quoting Chris Wilson (2017-12-11 12:51:42)
> Quoting Arnd Bergmann (2017-12-11 12:46:22)
> > The varargs macro trick in _PIPE3/_PHY3/_PORT3 was meant as an optimization
> > to shrink the i915 kernel module by around 1000 bytes. However, the
> > downside is a size regression with CONFIG_KASAN, as I found from stack size
> > warnings with gcc-7.0.1:
> > 
> > before:
> > drivers/gpu/drm/i915/intel_dpll_mgr.c: In function 
> > 'bxt_ddi_pll_get_hw_state':
> > drivers/gpu/drm/i915/intel_dpll_mgr.c:1644:1: error: the frame size of 176 
> > bytes is larger than 100 bytes [-Werror=frame-larger-than=]
> > drivers/gpu/drm/i915/intel_dpll_mgr.c: In function 'bxt_ddi_pll_enable':
> > drivers/gpu/drm/i915/intel_dpll_mgr.c:1548:1: error: the frame size of 224 
> > bytes is larger than 100 bytes [-Werror=frame-larger-than=]
> > 
> > after:
> > drivers/gpu/drm/i915/intel_dpll_mgr.c: In function 
> > 'bxt_ddi_pll_get_hw_state':
> > drivers/gpu/drm/i915/intel_dpll_mgr.c:1644:1: error: the frame size of 1016 
> > bytes is larger than 1000 bytes [-Werror=frame-larger-than=]
> > drivers/gpu/drm/i915/intel_dpll_mgr.c: In function 'bxt_ddi_pll_enable':
> > drivers/gpu/drm/i915/intel_dpll_mgr.c:1548:1: error: the frame size of 1960 
> > bytes is larger than 1000 bytes [-Werror=frame-larger-than=]
> > 
> > I also checked the module sizes and got with gcc-7.0.1
> > 
> > original:
> >textdata bss dec hex filename
> > 2380830 11554364448 3540714  3606ea drivers/gpu/drm/i915/i915-kasan.o
> > 1298054  5436922884 1844630  1c2596 drivers/gpu/drm/i915/i915-nokasan.o
> > 
> > after ce64645d86ac:
> >textdata bss dec hex filename
> > 2389515 11544764448 3548439  362517 drivers/gpu/drm/i915/i915-kasan.o
> > 1299639  5436922884 1846215  1c2bc7 drivers/gpu/drm/i915/i915-nokasan.o
> > 
> > with this patch:
> >textdata bss dec hex filename
> > 2381275 11638844448 3549607  3629a7 drivers/gpu/drm/i915/i915-kasan.o
> > 1296038  5436922884 1842614  1c1db6 drivers/gpu/drm/i915/i915-nokasan.o
> > 
> > Actually showing a code size growth in .text both with and without kasan,
> > and my version gets most of it back at the expense of larger .data when
> > kasan is enabled.
> > 
> > Fixes: ce64645d86ac ("drm/i915: use variadic macros and arrays to choose 
> > port/pipe based registers")
> > Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80114
> > Link: https://lkml.org/lkml/2017/3/20/1022
> > Cc: Jani Nikula 
> > Signed-off-by: Arnd Bergmann 
> > ---
> > v2: rebased after a1986f4174a4 ("drm/i915: Remove unnecessary PORT3 
> > definition.")
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h | 18 +-
> >  1 file changed, 9 insertions(+), 9 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 09bf043c1c2e..36f4408503e1 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -139,7 +139,7 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
> > return !i915_mmio_reg_equal(reg, INVALID_MMIO_REG);
> >  }
> >  
> > -#define _PICK(__index, ...) (((const u32 []){ __VA_ARGS__ })[__index])
> > +#define _PICK(__index, ...) ({static const u32 __arr[] = { __VA_ARGS__ }; 
> > __arr[__index];})
> 
> Is gcc smart enough for
> if (__builtin_context_p(__index)) {
> ((const u32 []){ __VA_ARGS__ })[__index];
> } else {
> static const u32 __arr[] = { __VA_ARGS__ };
> __arr[__index];
> }
> ?

Not really, we don't have enough constants for it to make a substantial
difference:

add/remove: 1/0 grow/shrink: 3/5 up/down: 617/-604 (13)
Function old new   delta
cnl_ddi_vswing_program.isra- 574+574
bxt_ddi_phy_is_enabled   220 241 +21
bxt_ddi_phy_set_signal_level 537 556 +19
i9xx_get_pipe_config14741477  +3
bxt_ddi_phy_verify_state 411 408  -3
_bxt_ddi_phy_init956 950  -6
vlv_display_power_well_init  470 461  -9
bxt_ddi_pll_get_hw_state 774 762 -12
cnl_ddi_vswing_sequence 1166 592-574
Total: Before=13461532, After=13461545, chg +0.00%

Of particular note the size of __arr[] is not reduced, so gcc is already
eliminating the static[] for constant index, or not eliminating the
redundant branch here.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v14 0/3] Move backlight helper functions from tinydrm-helpers to linux/backlight

[Noralf Trønnes]

Den 11.12.2017 18.45, skrev Noralf Trønnes:


Den 11.12.2017 15.58, skrev Meghana Madhyastha:

On Mon, Dec 11, 2017 at 03:12:06PM +0100, Noralf Trønnes wrote:

Den 11.12.2017 14.17, skrev Meghana Madhyastha:

On Sat, Dec 09, 2017 at 03:09:28PM +0100, Noralf Trønnes wrote:

Den 21.10.2017 13.55, skrev Meghana Madhyastha:

Changes in v14:
- s/backlight_get/of_find_backlight/ in patch 2/3
- Change commit message in patch 3/3 from requiring to acquiring

Meghana Madhyastha (3):
   drm/tinydrm: Move helper functions from tinydrm-helpers to 
backlight.h

   drm/tinydrm: Move tinydrm_of_find_backlight to backlight.c
   drm/tinydrm: Add devres versions of of_find_backlight

I tried the patchset and this is what I got:

[    8.057792] Unable to handle kernel paging request at virtual 
address

fe6b



[    9.144181] ---[ end trace 149c05934b6a6dcc ]---

Is the reason possibly because we have omitted error checking on the
return value of backlight_enable function ? 
tinydrm_enable_backlight and

tinydrm_disable_baclight do this.
Eg.
ret = backlight_update_status(backlight);
if (ret)
DRM_ERROR("Failed to enable backlight %d\n", ret);

I'm not sure, just asking whether this could be a possible reason
for the above trace.

The crash happens during probe.
I guess you'll figure this out when you get some hw to test on.
I have set up the raspberry pi and have built and boot into the 
custom kernel

but I am waiting for the panel to arrive. Meanwhile, any thoughts on
error message ? Sorry for the trivial question, but I did not quite
understand the crash message and how to replicate it.


of_find_backlight() can return an error pointer (-EPROBE_DEFER):

diff --git a/drivers/video/backlight/backlight.c 
b/drivers/video/backlight/backlight.c

index 4bb7bf3ee443..57370c5d51f0 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -635,8 +635,8 @@ struct backlight_device 
*devm_of_find_backlight(struct device *dev)

    int ret;

    bd = of_find_backlight(dev);
-   if (!bd)
-   return NULL;
+   if (IS_ERR_OR_NULL(bd))
+   return bd;

    ret = devm_add_action(dev, devm_backlight_put, bd);
    if (ret) {

That solved the crash, but the backlight didn't turn on.
I had to do this as well:

diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index 5c441d4c049c..6f9925f10a7c 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -139,6 +139,8 @@ static inline int backlight_enable(struct 
backlight_device *bd)

    if (!bd)
    return 0;

+   if (!bd->props.brightness)
+   bd->props.brightness = bd->props.max_brightness;


No, this is wrong, it should happen on probe, not every time it's enabled.
So maybe it should be done in of_find_backlight() or something.
I see that I'm currently doing it in tinydrm_of_find_backlight().


bd->props.power = FB_BLANK_UNBLANK;
    bd->props.state &= ~BL_CORE_FBBLANK;

This is my backlight node[1]:

backlight: backlight {
    compatible = "gpio-backlight";
    gpios = < 18 0>; // GPIO_ACTIVE_HIGH
};

Not certain that this is the "correct" solution, but I can't use the
gpio-backlight property default-on, because that would turn on backlight
before the pipeline is enabled.

You can dry-run the driver without a panel connected, it can work
without being able to read from the controller.

Noralf.

[1] 
https://github.com/notro/tinydrm/blob/master/rpi-overlays/rpi-display-overlay.dts


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



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

Re: [PATCH v14 0/3] Move backlight helper functions from tinydrm-helpers to linux/backlight

[Noralf Trønnes]

Den 11.12.2017 15.58, skrev Meghana Madhyastha:

On Mon, Dec 11, 2017 at 03:12:06PM +0100, Noralf Trønnes wrote:

Den 11.12.2017 14.17, skrev Meghana Madhyastha:

On Sat, Dec 09, 2017 at 03:09:28PM +0100, Noralf Trønnes wrote:

Den 21.10.2017 13.55, skrev Meghana Madhyastha:

Changes in v14:
- s/backlight_get/of_find_backlight/ in patch 2/3
- Change commit message in patch 3/3 from requiring to acquiring

Meghana Madhyastha (3):
   drm/tinydrm: Move helper functions from tinydrm-helpers to backlight.h
   drm/tinydrm: Move tinydrm_of_find_backlight to backlight.c
   drm/tinydrm: Add devres versions of of_find_backlight

I tried the patchset and this is what I got:

[    8.057792] Unable to handle kernel paging request at virtual address
fe6b
[    8.069118] pgd = 93817cf7
[    8.075704] [fe6b] *pgd=1bfd7861, *pte=, *ppte=
[    8.086047] Internal error: Oops: 37 [#1] ARM
[    8.094285] Modules linked in: mi0283qt(+) mipi_dbi tinydrm backlight
bcm2835_rng rng_core
[    8.110535] CPU: 0 PID: 121 Comm: systemd-udevd Not tainted 4.15.0-rc2+
#2
[    8.121531] Hardware name: BCM2835
[    8.128964] task: 85dc6e21 task.stack: 4d8f2d19
[    8.137482] PC is at kobject_put+0x18/0x1dc
[    8.145556] LR is at put_device+0x24/0x28
[    8.153312] pc : []    lr : [] psr: a013
[    8.163321] sp : d6d33c18  ip : d6d33c40  fp : d6d33c3c
[    8.172238] r10: c0496d38  r9 :   r8 : d6e46680
[    8.181108] r7 : 0004  r6 : d766bc00  r5 : d6d33c70  r4 : fe4b
[    8.191237] r3 : bf0113b8  r2 : d766bd2c  r1 : d6e46710  r0 : fe4b
[    8.201248] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM Segment
none
[    8.211869] Control: 00c5387d  Table: 16d20008  DAC: 0051
[    8.221141] Process systemd-udevd (pid: 121, stack limit = 0xa0ab0c84)
[    8.231264] Stack: (0xd6d33c18 to 0xd6d34000)
[    8.239228] 3c00:
bf011858 c049728c
[    8.254539] 3c20: d7737010 d6e46700 d6d33c70 d766bc00 d6d33c4c d6d33c40
c048edb8 c076a1a8
[    8.270045] 3c40: d6d33c5c d6d33c50 bf0113dc c048eda0 d6d33c6c d6d33c60
c0496fc4 bf0113c4
[    8.285883] 3c60: d6d33ca4 d6d33c70 c04979f0 c0496fb4 d7737000 d6e46700
d6d33c9c d766bc00
[    8.301819] 3c80:  bf030100 c0d369dc c0d369e0 000e fdfb
d6d33cb4 d6d33ca8
[    8.317917] 3ca0: c0497ad0 c0497858 d6d33cec d6d33cb8 c0493efc c0497a94
c057e738 c057d26c
[    8.334043] 3cc0: d6d33cec d766bc00 d766bc34 bf030100 c0c4a5d8 0001
d6e46464 0028
[    8.350344] 3ce0: d6d33d0c d6d33cf0 c049414c c0493c4c 0001 
bf030100 c04940b0
[    8.367036] 3d00: d6d33d34 d6d33d10 c0492018 c04940bc d754f28c d76afbb0
d6dca534 bf030100
[    8.383997] 3d20:  d6dca500 d6d33d44 d6d33d38 c0493750 c0491fa8
d6d33d6c d6d33d48
[    8.401301] 3d40: c0493124 c0493734 bf02f4d6 d6d33d58 bf030100 bf033000
c0c04048 
[    8.418938] 3d60: d6d33d84 d6d33d70 c0494954 c0493048 bf030140 bf033000
d6d33d94 d6d33d88
[    8.436692] 3d80: c04c8794 c04948b4 d6d33da4 d6d33d98 bf033020 c04c8748
d6d33e1c d6d33da8
[    8.454638] 3da0: c0101a30 bf03300c d6d33dcc d6d33db8 c01013f4 c03f7c64
c0221690 6013
[    8.472918] 3dc0: d6d33e44 d6d33dd0 c010d04c c01013e0 d7401e40 014000c0
000c c0221770
[    8.491185] 3de0: d6d33e1c d6d33df0 c0221770 c021e29c 0001 fc36740d
bf030140 0001
[    8.509455] 3e00: d6e46500 d6e46440 0001 d6e46464 d6d33e44 d6d33e20
c0178628 c0101978
[    8.527727] 3e20: bf030140 d6e46440 d6d33e44 d6d33f40 0001 bf030140
d6d33f1c d6d33e48
[    8.546000] 3e40: c0177810 c01785c8 bf03014c 7fff bf030140 c0174ae8
d6d33f38 d6d33eb8
[    8.564264] 3e60: d6d33e9c b6d4f004 dcb059a4 c0c1619c bf030324 d6e46448
bf030188 dcad6000
[    8.582529] 3e80:  d6ca3e40    
 
[    8.600797] 3ea0:     6e72656b 6c65
 
[    8.619065] 3ec0:      
 
[    8.637319] 3ee0:    fc36740d 7fff 
b6d4f004 000d
[    8.655582] 3f00: 017b c0108044 d6d32000  d6d33fa4 d6d33f20
c0177f94 c0175d00
[    8.673835] 3f20: 7fff  0003   dcad6000
0002f9f4 
[    8.692093] 3f40: dcad6b80 dcad6000 0002f9f4 dcb05274 dcaf9e6a dcafa860
3000 3240
[    8.710350] 3f60:    1e34 002e 002f
0019 
[    8.728612] 3f80: 0013   1ef80900  
 d6d33fa8
[    8.746870] 3fa0: c0107e60 c0177f04 1ef80900  000d b6d4f004
 b6d4f928
[    8.765132] 3fc0: 1ef80900   017b b6d4f004 0002
00af6e18 
[    8.783394] 3fe0: bec95200 bec951f0 b6d4709c b6ea3c40 6010 000d
 
[    8.801685] [] (kobject_put) from []
(put_device+0x24/0x28)
[    8.814234] [] (put_device) from []
(devm_backlight_put+0x24/0x28 [backlight])
[    8.833323] [] (devm_backlight_put [backlight]) from
[] 

Re: [PATCH] drm: Give the DRM device's anon_inode a unique lockclass for its mmap_rswem

[Daniel Vetter]

On Mon, Dec 11, 2017 at 6:27 PM, Chris Wilson  wrote:
> Quoting Daniel Vetter (2017-12-11 17:20:32)
>> On Mon, Dec 11, 2017 at 11:39 AM, Chris Wilson  
>> wrote:
>> > Teach lockdep to track the device's internal mmapping separately
>> > from the generic lockclass over all other inodes. Since this is device
>> > private we wish to allow a different locking hierarchy than is typified
>> > by the requirement for the mmap_rwsem being the outermost lock for
>> > handling pagefaults. By giving the internal mmap_rwsem a distinct
>> > lockclass, lockdep can identify it and learn/enforce its distinct locking
>> > requirements.
>> >
>> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104209
>> > Signed-off-by: Chris Wilson 
>> > Cc: Daniel Vetter 
>>
>> I think both the commit message and comment are a bit too fluffy - the
>> critical bit is that we're biting ourselves on gtt mmaps from
>> usersptr, and that's explicitly not allowed exactly because it would
>> deadlock.
>>
>> I'm also not sure it's a good idea to implement this in generic code,
>> since this is a very i915 specific issue, and other drivers (who might
>> be a lot less sloppy here) will now no longer get reports about this
>> deadlock.
>
> I was thinking that in a more general sense manipulating of the
> vma_manager's inode is independent of the processes's mappings. As such
> we do not want to tie the two together and force them to conform to the
> same rules, because the core mapping semaphore will be held on entry to
> driver code, but the internal mapping will be used from within driver
> code.

I think they're the same locks really. Maybe I'm missing something,
but I thought the mapping->rwsem we get on mmap/fault is exactly the
one we want/need to use for zap_pte.

Looking at the bugzilla trace I think the deadlock happens when the
i915_gem_userptr_mn_invalidate_range_start callback calls
flush_workqueue for a range that is not itself not allowed to be
userptr-mapped. But because it does that, we end up in a deadlock. I
think if the userptr callback would checkthe range it gets against all
the userptr mappings, we'd avoid this deadlock: userptr is not allowed
to map a gtt range, which means this should avoid calling
flush_workqueue while holding our drm mapping->rwsem.

So there seems to be a real deadlock, at least in my current understanding.

Of course if we'd fix that deadlock we'd still have lockdep
complaining, but maybe the deadlock fix also gets rid of the lockdep
splat (but that would be more rework than just making the flush_work
conditional).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104206] [drm:construct [amdgpu]] *ERROR* construct: Invalid Connector ObjectID from Adapter Service for connector index:2!

[bugzilla-daemon]

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

--- Comment #8 from Andrew  ---
Correct you are about _not_ disabling the "accel". I was trying to figure
out what is breaking X this time around (i have a long thread on forums
trying to get amdgpu to work on this laptop).

I run on init3. And use "startx" when logged in as root. (Usually im on
init 5, but on all prior kernels to  4.15rc2 i didnt even got to see
terminals , just a black screen).


On Dec 11, 2017 11:10,  wrote:

> *Comment # 7  on
> bug 104206  from
> Michel Dänzer  *
>
> (In reply to Andrew from comment #6 
> )> the X doesn't hard 
> crash when i turn an acceleration off.
>
> Normally you'd want Option "Accel" "off" to disable accleration, not
> "AccelMethod" "none".
>
> > X still doesn't work - just exists back to the terminal.
>
> The Xorg log doesn't show any problem anymore, so it sounds like that's an X
> client session issue now. How exactly are you trying to start X?
>
> --
> You are receiving this mail because:
>
>- You reported the bug.
>
>

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

Re: [PATCH] drm: Give the DRM device's anon_inode a unique lockclass for its mmap_rswem

[Chris Wilson]

Quoting Daniel Vetter (2017-12-11 17:20:32)
> On Mon, Dec 11, 2017 at 11:39 AM, Chris Wilson  
> wrote:
> > Teach lockdep to track the device's internal mmapping separately
> > from the generic lockclass over all other inodes. Since this is device
> > private we wish to allow a different locking hierarchy than is typified
> > by the requirement for the mmap_rwsem being the outermost lock for
> > handling pagefaults. By giving the internal mmap_rwsem a distinct
> > lockclass, lockdep can identify it and learn/enforce its distinct locking
> > requirements.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104209
> > Signed-off-by: Chris Wilson 
> > Cc: Daniel Vetter 
> 
> I think both the commit message and comment are a bit too fluffy - the
> critical bit is that we're biting ourselves on gtt mmaps from
> usersptr, and that's explicitly not allowed exactly because it would
> deadlock.
> 
> I'm also not sure it's a good idea to implement this in generic code,
> since this is a very i915 specific issue, and other drivers (who might
> be a lot less sloppy here) will now no longer get reports about this
> deadlock.

I was thinking that in a more general sense manipulating of the
vma_manager's inode is independent of the processes's mappings. As such
we do not want to tie the two together and force them to conform to the
same rules, because the core mapping semaphore will be held on entry to
driver code, but the internal mapping will be used from within driver
code.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Give the DRM device's anon_inode a unique lockclass for its mmap_rswem

[Daniel Vetter]

On Mon, Dec 11, 2017 at 11:39 AM, Chris Wilson  wrote:
> Teach lockdep to track the device's internal mmapping separately
> from the generic lockclass over all other inodes. Since this is device
> private we wish to allow a different locking hierarchy than is typified
> by the requirement for the mmap_rwsem being the outermost lock for
> handling pagefaults. By giving the internal mmap_rwsem a distinct
> lockclass, lockdep can identify it and learn/enforce its distinct locking
> requirements.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104209
> Signed-off-by: Chris Wilson 
> Cc: Daniel Vetter 

I think both the commit message and comment are a bit too fluffy - the
critical bit is that we're biting ourselves on gtt mmaps from
usersptr, and that's explicitly not allowed exactly because it would
deadlock.

I'm also not sure it's a good idea to implement this in generic code,
since this is a very i915 specific issue, and other drivers (who might
be a lot less sloppy here) will now no longer get reports about this
deadlock.

Aside from that I'm not really sure why you think the bugzilla link is
a false positive: The mapping->rwsem is the one for the gtt in both
cases I think.
-Daniel

> ---
>  drivers/gpu/drm/drm_drv.c | 17 -
>  1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 9acc1e157813..21ad06c3d684 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -393,6 +393,7 @@ static struct file_system_type drm_fs_type = {
>
>  static struct inode *drm_fs_inode_new(void)
>  {
> +   static struct lock_class_key lockclass;
> struct inode *inode;
> int r;
>
> @@ -403,8 +404,22 @@ static struct inode *drm_fs_inode_new(void)
> }
>
> inode = alloc_anon_inode(drm_fs_mnt->mnt_sb);
> -   if (IS_ERR(inode))
> +   if (IS_ERR(inode)) {
> simple_release_fs(_fs_mnt, _fs_cnt);
> +   return inode;
> +   }
> +
> +   /*
> +* Teach lockdep to track the device's internal mmapping separately
> +* from all other inodes. Since this is device private we wish to
> +* allow a different locking hierarchy than is typified by the
> +* requirement for the mmap_rwsem being the outermost lock for
> +* handling pagefaults. By giving the internal mmap_rwsem a distinct
> +* lockclass, lockdep can identify it and thereby learn and enforce 
> its
> +* distinct locking requirements.
> +*/
> +   lockdep_set_class_and_name(>i_mapping->i_mmap_rwsem,
> +  , "drm_fs_inode");
>
> return inode;
>  }
> --
> 2.15.1
>



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

Re: [PATCH v2 1/2] dt-bindings: Add binding for Sitronix ST7735R display panels

[Noralf Trønnes]

Den 10.12.2017 23.10, skrev David Lechner:

This adds a new device tree binding for Sitronix ST7735R display panels,
such as the Adafruit 1.8" TFT.

Signed-off-by: David Lechner 
Acked-by: Rob Herring 
---

v2: changes:
* None, but...

I'm wondering about my choice of compatible here. I chose the name
"sitronix,st7735r-jd-t18003-t01" to mean a Sitronix ST7735R controller
connected to a JD-T18003-T01 LCD screen.

What I am actually using, though, is an Adafruit 1.8" TFT breakout [1]. It
has some additional electronics which just pass through signals to the
controller. The bare display is also available from Adafruit [2].

Limor brought up an interesting point in an off-list discussion. The
same controller can be wired to the same LCD in different ways. This is
evident in the fbftf drivers in staging. There is an "adafruit18" and an
"adafruit18_green" in fbftf_devices.c where apparently, two otherwise
identical displays were wired slightly differently at the factory so that
on one, the on-board GRAM word 0 does not correspond to pixel 0,0 on the
LCD. It requires a special offset to the GRAM starting address in order to
have the image displayed correctly.

Additionally, fbtft supports a SainSmart 1.8" TFT [3] that uses the same
controller, but it appears that these have different gamma curves (perhaps
they use different LCDs?). The available pins are exactly the same as the
Adafruit display though.

As I am writing this, I am looking at the JD-1800 datasheet [4] again for
the Adafruit display and I see that in addition to specifying the size of
the display it says "IC: ST7735B". So, I am starting to think that "jianda,
jd-t18003-t01" would be a better compatible string since it tells you
everything you need to know about this display. Just using the controller
name by itself ("sitronix,st7735r") is not enough because it does not tell
you things like the number of pixels or the physical size of the LCD.

What I am not sure about, though, is how to represent the Adafruit display
that requires the offset in the device tree. Would it be a different
compatible string or should we add an extra property to indicate this
quirk?

On a related note, I recently submitted device tree bindings for a similar
SPI display breakout board [5][6]. After more digging though, I found a
datasheet for that display [7], so I'm thinking a compatible string of
"vot,v220hf01a-t" would be better by the same reasoning above.

And, I know this is getting long, but one more thing...

There was a binding acked recently for the LCD on a D-Link DIR-685 Wireless
N Storage Router [8]. This uses the compound compatible string of "dlink,
dir-685-panel", "ilitek,ili9322". If we want to try to keep things
consistent, perhaps I should be adopting this pattern as well? And perhaps
it would be better to use the better known vendor name instead of the
obscure vendors from the datasheets that I have found? For example,
"adafruit,618" "sitronix,st7735r" instead of "jianda,jd-t18003-t01"?


I vote for this:
"jianda,jd-t18003-t01"

The display controller is part of the panel so you can't have this
panel with another controller. If the Adafruit #358 panel with
breakout board did something that made it incompatible with a bare
jianda panel, then it would make sense to call it "adafruit,something".

I don't know the full story about the green tab version of the display
with the offset problem, but it's a long time ago and I don't think
it's worth it to support it. It would require a custom dirtyfb callback.

There's also a black tab version of this Adafruit display with the
colors reversed BGR/RGB, but that also is some time back now.

I guess they all had different panels with their own names which would
result in different compatible strings. This means that the end user
would have to know excatly which version of the Adafruit display they're
using to know which compatible string to use. If the SPI MISO signal
had been routed out from the panel, it would have been possible to make
a driver just with a "adafruit,tft18" comaptible and let the driver ask
the controller which version it is. Assuming that info is available in
the controller. Not all panel vendors bother to do that.

The "mi,mi0283qt" panel for instance is used on the Adafruit PiTFT 28
and the Watterott rpi-display, making it possible to use the same
compatible for both displays and also for anyone buying that panel from
some other source.

One last thing, if the panel is made specifically for Adafruit and not
available from any other source, then it makes sense to call it
something "adafruit".

Noralf.


[1]: https://www.adafruit.com/product/358
[2]: https://www.adafruit.com/product/618
[3]: 
https://www.sainsmart.com/products/1-8-tft-spi-lcd-screen-with-microsd-socket
[4]: http://www.adafruit.com/datasheets/JD-T1800.pdf
[5]: https://patchwork.freedesktop.org/patch/187038/
[6]: https://patchwork.freedesktop.org/patch/189233/
[7]: 

[Bug 95306] Random Blank(black) screens on "Carrizo"

[bugzilla-daemon]

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

--- Comment #77 from Kelly Anderson  ---
4.15rc3 also seems to be fine with respect to this problem.

-- 
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 104206] [drm:construct [amdgpu]] *ERROR* construct: Invalid Connector ObjectID from Adapter Service for connector index:2!

[bugzilla-daemon]

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

--- Comment #7 from Michel Dänzer  ---
(In reply to Andrew from comment #6)
> the X doesn't hard crash when i turn an acceleration off.

Normally you'd want Option "Accel" "off" to disable accleration, not
"AccelMethod" "none".


> X still doesn't work - just exists back to the terminal.

The Xorg log doesn't show any problem anymore, so it sounds like that's an X
client session issue now. How exactly are you trying to start X?

-- 
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: tinydrm: page allocation failure

[David Lechner]

On 12/11/2017 07:37 AM, Noralf Trønnes wrote:


Den 11.12.2017 13.45, skrev Noralf Trønnes:


Den 11.12.2017 04.28, skrev David Lechner:
I'm using drm-misc/drm-misc-next and occasionally getting errors as 
seen in the stack traces below. I'm not really sure what to make of 
it. Any ideas?




The spi controller driver has told the spi core to allocate dummy
buffers for tx/rx: spi_sync -> __spi_pump_messages -> spi_map_msg
-> krealloc -> __do_krealloc -> kmalloc_track_caller

order:4 means it's trying to allocate 2^4*PAGE_SIZE = 64kB, which
probably is the max DMA limit. So this is a pixel data transfer.

On my Raspberry Pi I've got 43 chunks of 64kB available if I have
understood this right:

$ sudo cat /proc/buddyinfo
Node 0, zone   Normal 40 68 66 51 43 46 
13  1  3  3 75


I don't know what those dummy buffers are used for.



tinydrm has a spi_max module parameter that can set the chunk size.
I have wondered if I should just remove this parameter when spi-bcm2835
has been fixed as explained here:
https://lists.freedesktop.org/archives/dri-devel/2017-February/132725.html
I'm figuring it is better to add this parameter if the problem arises 
again,

instead of preparing for something that might not be a problem anymore.

But now I'm reminded of this dummy buffer and if we were to send the entire
framebuffer in one go, the dummy buffer would have to be the same size as
the framebuffer. Not sure how well that works on long running boards with
little ram, to be able to allocate 320*480*2 = 300kB ~= 512kB (continous)
for the largest SPI displays on every flush, after months of run time.

How much ram do you have on the Lego module?


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

[Bug 104206] [drm:construct [amdgpu]] *ERROR* construct: Invalid Connector ObjectID from Adapter Service for connector index:2!

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

 Attachment #136083|text/x-log  |text/plain
  mime type||

-- 
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 104206] [drm:construct [amdgpu]] *ERROR* construct: Invalid Connector ObjectID from Adapter Service for connector index:2!

[bugzilla-daemon]

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

--- Comment #6 from Andrew  ---
Created attachment 136083
  --> https://bugs.freedesktop.org/attachment.cgi?id=136083=edit
x log with "Aceel" turned off

the X doesn't hard crash when i turn an acceleration off. X still doesn't work
- just exists back to the terminal.

i used the following config in this case:
[code]
Section "Device"
Identifier "Carrizo"
Driver "amdgpu"
Option "AccelMethod" "none"
#   Option "Accel" "on"
#   Option "DRI" "3"
Option "TearFree" "on"
EndSection
[/code]

-- 
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 104206] [drm:construct [amdgpu]] *ERROR* construct: Invalid Connector ObjectID from Adapter Service for connector index:2!

[bugzilla-daemon]

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

--- Comment #5 from Andrew  ---
Created attachment 136082
  --> https://bugs.freedesktop.org/attachment.cgi?id=136082=edit
messages.log

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

[Bug 104206] [drm:construct [amdgpu]] *ERROR* construct: Invalid Connector ObjectID from Adapter Service for connector index:2!

[bugzilla-daemon]

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

--- Comment #4 from Andrew  ---
Created attachment 136081
  --> https://bugs.freedesktop.org/attachment.cgi?id=136081=edit
Xlog

-- 
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 103987] [DC] drm:drm_atomic_helper_wait_for_dependencies - flip_done timed out

[bugzilla-daemon]

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

--- Comment #6 from Harry Wentland  ---
Been busy and haven't gotten it in yet. It's still staged. Hope to queue it up
for next RC this week.

-- 
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 v14 0/3] Move backlight helper functions from tinydrm-helpers to linux/backlight

[Meghana Madhyastha]

On Mon, Dec 11, 2017 at 03:12:06PM +0100, Noralf Trønnes wrote:
> 
> Den 11.12.2017 14.17, skrev Meghana Madhyastha:
> >On Sat, Dec 09, 2017 at 03:09:28PM +0100, Noralf Trønnes wrote:
> >>Den 21.10.2017 13.55, skrev Meghana Madhyastha:
> >>>Changes in v14:
> >>>- s/backlight_get/of_find_backlight/ in patch 2/3
> >>>- Change commit message in patch 3/3 from requiring to acquiring
> >>>
> >>>Meghana Madhyastha (3):
> >>>   drm/tinydrm: Move helper functions from tinydrm-helpers to backlight.h
> >>>   drm/tinydrm: Move tinydrm_of_find_backlight to backlight.c
> >>>   drm/tinydrm: Add devres versions of of_find_backlight
> >>I tried the patchset and this is what I got:
> >>
> >>[    8.057792] Unable to handle kernel paging request at virtual address
> >>fe6b
> >>[    8.069118] pgd = 93817cf7
> >>[    8.075704] [fe6b] *pgd=1bfd7861, *pte=, *ppte=
> >>[    8.086047] Internal error: Oops: 37 [#1] ARM
> >>[    8.094285] Modules linked in: mi0283qt(+) mipi_dbi tinydrm backlight
> >>bcm2835_rng rng_core
> >>[    8.110535] CPU: 0 PID: 121 Comm: systemd-udevd Not tainted 4.15.0-rc2+
> >>#2
> >>[    8.121531] Hardware name: BCM2835
> >>[    8.128964] task: 85dc6e21 task.stack: 4d8f2d19
> >>[    8.137482] PC is at kobject_put+0x18/0x1dc
> >>[    8.145556] LR is at put_device+0x24/0x28
> >>[    8.153312] pc : []    lr : [] psr: a013
> >>[    8.163321] sp : d6d33c18  ip : d6d33c40  fp : d6d33c3c
> >>[    8.172238] r10: c0496d38  r9 :   r8 : d6e46680
> >>[    8.181108] r7 : 0004  r6 : d766bc00  r5 : d6d33c70  r4 : fe4b
> >>[    8.191237] r3 : bf0113b8  r2 : d766bd2c  r1 : d6e46710  r0 : fe4b
> >>[    8.201248] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM Segment
> >>none
> >>[    8.211869] Control: 00c5387d  Table: 16d20008  DAC: 0051
> >>[    8.221141] Process systemd-udevd (pid: 121, stack limit = 0xa0ab0c84)
> >>[    8.231264] Stack: (0xd6d33c18 to 0xd6d34000)
> >>[    8.239228] 3c00:
> >>bf011858 c049728c
> >>[    8.254539] 3c20: d7737010 d6e46700 d6d33c70 d766bc00 d6d33c4c d6d33c40
> >>c048edb8 c076a1a8
> >>[    8.270045] 3c40: d6d33c5c d6d33c50 bf0113dc c048eda0 d6d33c6c d6d33c60
> >>c0496fc4 bf0113c4
> >>[    8.285883] 3c60: d6d33ca4 d6d33c70 c04979f0 c0496fb4 d7737000 d6e46700
> >>d6d33c9c d766bc00
> >>[    8.301819] 3c80:  bf030100 c0d369dc c0d369e0 000e fdfb
> >>d6d33cb4 d6d33ca8
> >>[    8.317917] 3ca0: c0497ad0 c0497858 d6d33cec d6d33cb8 c0493efc c0497a94
> >>c057e738 c057d26c
> >>[    8.334043] 3cc0: d6d33cec d766bc00 d766bc34 bf030100 c0c4a5d8 0001
> >>d6e46464 0028
> >>[    8.350344] 3ce0: d6d33d0c d6d33cf0 c049414c c0493c4c 0001 
> >>bf030100 c04940b0
> >>[    8.367036] 3d00: d6d33d34 d6d33d10 c0492018 c04940bc d754f28c d76afbb0
> >>d6dca534 bf030100
> >>[    8.383997] 3d20:  d6dca500 d6d33d44 d6d33d38 c0493750 c0491fa8
> >>d6d33d6c d6d33d48
> >>[    8.401301] 3d40: c0493124 c0493734 bf02f4d6 d6d33d58 bf030100 bf033000
> >>c0c04048 
> >>[    8.418938] 3d60: d6d33d84 d6d33d70 c0494954 c0493048 bf030140 bf033000
> >>d6d33d94 d6d33d88
> >>[    8.436692] 3d80: c04c8794 c04948b4 d6d33da4 d6d33d98 bf033020 c04c8748
> >>d6d33e1c d6d33da8
> >>[    8.454638] 3da0: c0101a30 bf03300c d6d33dcc d6d33db8 c01013f4 c03f7c64
> >>c0221690 6013
> >>[    8.472918] 3dc0: d6d33e44 d6d33dd0 c010d04c c01013e0 d7401e40 014000c0
> >>000c c0221770
> >>[    8.491185] 3de0: d6d33e1c d6d33df0 c0221770 c021e29c 0001 fc36740d
> >>bf030140 0001
> >>[    8.509455] 3e00: d6e46500 d6e46440 0001 d6e46464 d6d33e44 d6d33e20
> >>c0178628 c0101978
> >>[    8.527727] 3e20: bf030140 d6e46440 d6d33e44 d6d33f40 0001 bf030140
> >>d6d33f1c d6d33e48
> >>[    8.546000] 3e40: c0177810 c01785c8 bf03014c 7fff bf030140 c0174ae8
> >>d6d33f38 d6d33eb8
> >>[    8.564264] 3e60: d6d33e9c b6d4f004 dcb059a4 c0c1619c bf030324 d6e46448
> >>bf030188 dcad6000
> >>[    8.582529] 3e80:  d6ca3e40    
> >> 
> >>[    8.600797] 3ea0:     6e72656b 6c65
> >> 
> >>[    8.619065] 3ec0:      
> >> 
> >>[    8.637319] 3ee0:    fc36740d 7fff 
> >>b6d4f004 000d
> >>[    8.655582] 3f00: 017b c0108044 d6d32000  d6d33fa4 d6d33f20
> >>c0177f94 c0175d00
> >>[    8.673835] 3f20: 7fff  0003   dcad6000
> >>0002f9f4 
> >>[    8.692093] 3f40: dcad6b80 dcad6000 0002f9f4 dcb05274 dcaf9e6a dcafa860
> >>3000 3240
> >>[    8.710350] 3f60:    1e34 002e 002f
> >>0019 
> >>[    8.728612] 3f80: 0013   1ef80900  
> >> d6d33fa8
> >>[    8.746870] 3fa0: c0107e60 c0177f04 1ef80900  000d b6d4f004
> >> b6d4f928
> >>[    8.765132] 3fc0: 1ef80900   017b b6d4f004 0002
> 

Re: [PATCH 2/3] uapi: drm: New fourcc codes needed by Xilinx Video IP

[Laurent Pinchart]

Hi Ville,

On Monday, 11 December 2017 16:24:32 EET Ville Syrjälä wrote:
> On Mon, Dec 11, 2017 at 04:08:07PM +0200, Laurent Pinchart wrote:
> > On Tuesday, 28 November 2017 20:11:42 EET Ville Syrjälä wrote:
> >> On Tue, Nov 28, 2017 at 05:25:46PM +, Hyun Kwon wrote:
> >>> On Tuesday, November 28, 2017 6:44 AM Ville Syrjälä wrote:
>  On Mon, Nov 27, 2017 at 06:27:32PM -0800, Hyun Kwon wrote:
> > From: Jeffrey Mouroux 
> > 
> > The Xilinx Video Mixer and Xilinx Video Framebuffer DMA IP
> > support video memory formats that are not represented in the
> > current DRM fourcc library.  This patch adds those missing
> > fourcc codes.
> > 
> > Signed-off-by: Jeffrey Mouroux 
> > Signed-off-by: Hyun Kwon 
> > ---
> > 
> >  include/uapi/drm/drm_fourcc.h | 9 +
> >  1 file changed, 9 insertions(+)
> > 
> > diff --git a/include/uapi/drm/drm_fourcc.h
> > b/include/uapi/drm/drm_fourcc.h
> > index 3ad838d..83806d5 100644
> > --- a/include/uapi/drm/drm_fourcc.h
> > +++ b/include/uapi/drm/drm_fourcc.h
> > @@ -112,6 +112,13 @@ extern "C" {
> > 
> >  #define DRM_FORMAT_VYUYfourcc_code('V', 'Y', 'U', 'Y')
> > 
> > /* [31:0] Y1:Cb0:Y0:Cr0 8:8:8:8 little endian */
> > 
> >  #define DRM_FORMAT_AYUVfourcc_code('A', 'Y', 'U', 'V')
> > 
> > /* [31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
> > +#define DRM_FORMAT_VUY888  fourcc_code('V', 'U', '2', '4') /* 
> > [23:0]
> > Cr:Cb:Y little endian */
> > +#define DRM_FORMAT_XVUYfourcc_code('X', 'V', '2', '4') /*
> > [31:0]
> > x:Cr:Cb:Y 8:8:8:8 little endian */
> > +#define DRM_FORMAT_XVUY2101010 fourcc_code('X', 'V', '3', '0')
> > /* [31:0] x:Cr:Cb:Y 2:10:10:10 little endian */
> > +
> > +/* Grey scale */
> > +#define DRM_FORMAT_Y8  fourcc_code('G', 'R', 'E', 'Y') /* 8-bit
> > packed greyscale Y:Y:Y:Y 8:8:8:8 */
> > +#define DRM_FORMAT_Y10 fourcc_code('Y', '1', '0', ' ') /*
> > 10-bit packed greyscale X:Y:Y:Y 2:10:10:10 */
>  
>  These don't make sense to me. What does it even mean to have Y
>  replicated three or four times for each pixel?
> >>> 
> >>> Each pixel has one Y component. The comment is to describe how
> >>> components are stored in 32bit, but I agree it's confusing. Will
> >>> describe better.
> >> 
> >> For the 8 bit Y format you should then define it as 8 bits. Unless of
> >> course it really is defined as a 32bit word containing 4 pixels. The
> >> 10 bit case would be even funky since there would have to be two
> >> bits of padding after every 3 pixels.
> >> 
> >> So are these really defined as 32 bit wits 3 or 4 pixels and potentially
> >> a few bits of extra padding packed into each word? That seems rather
> >> nuts to me because you can't even byte address each pixel.
> >> 
> >> I think such crazyness has no business living right next to the
> >> sane formats, hence we should put all these into their own little
> >> section of the header, and the names should somehow reflect that
> >> they are in fact "special".
> > 
> > Thee Y8 format isn't special as it's just a plain 8-bit format.
> 
> Is it? The patch made it out to be something else perhaps. Impossible
> to judge without reading the relevant xilinx docs I suppose.

What I meant is that despite the presentation of this 8-bit greyscale format 
as storing 4 pixels in 32 bits, it's really an 8-bit greyscale format without 
anything special.

> > The Y10 format is indeed not byte-addressable, but don't be too fast to
> > dismiss it as crazy, this kind of format is pretty common outside of the
> > desktop graphics world. There are even 10-bit formats with 3 components
> > where the 8 LSBs of each component are stored in three bytes, and the 2
> > MSBs are grouped in a fourth byte with 2 bits of padding (or possibly with
> > LSB and MSB switched, I can't remember right now).
> 
> So you're saying the formats in this patch aren't quite as crazy as some
> other formats out there? ;)

Don't get me started about some of the GPU tiled formats ;-) The graphics and 
camera industries have taken different paths because they have different 
needs, but both have invented their share of convoluted formats that are not 
always easy to support.

-- 
Regards,

Laurent Pinchart

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

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

[Lionel Landwerlin]

On 11/12/17 14:38, Tvrtko Ursulin wrote:


On 11/12/2017 10:50, Joonas Lahtinen wrote:

+ Daniel, Chris

On Thu, 2017-12-07 at 09:21 +, Tvrtko Ursulin wrote:

On 04/12/2017 15:02, Lionel Landwerlin wrote:

Hi,

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


Important thing to mention as well is that it is trivial to get from 
the

master drm fd to the sysfs root, via fstat and opendir
/sys/dev/char/:. With the addition of the card symlink to
render nodes it is trivial for render node fd as well.

I am happy with this approach - it is extensible, flexible and avoids
issues with ioctl versioning or whatnot. With one value per file it is
trivial for userspace to access.

So for what I'm concerned, given how gputop would use all of this 
and so

be the userspace, if everyone else is happy, I think we could do a
detailed review and prehaps also think about including gputop in some
distribution to make the case 100% straightforward.


For the GPU topology I agree this is the right choice, it's going to be
about topology after all, and directory tree is the perfect candidate.
And if a new platform appears, then it's a new platform and may change
the topology well the hardware topology has changed.

For the engine enumeration, I'm not equally sold for sysfs exposing it.
It's a "linear list of engine instances with flags" how the userspace
is going to be looking at them. And it's also information about what to
pass to an IOCTL as arguments after decision has been made, and then
you already have the FD you know you'll be dealing with, at hand. So
another IOCTL for that seems more convenient.


Apart from more flexibility and easier to extend, sysfs might be a 
better fit for applications which do not otherwise need a drm fd. Say 
a top-like tool which shows engine utilization, or those patches I 
RFC-ed recently which do the same but per DRM client.


Okay, these stats are now available also via PMU so the argument is 
not the strongest I admit, but I still find it quite neat. It also 
might allow us to define our own policy with regards to needed 
privilege to access these stats, and not be governed by the perf API 
rules.



So I'd say for the GPU topology part, we go forward with the review and
make sure we don't expose driver internal bits that could break when
refactoring code. If the exposed N bits of information are strictly
tied to the underlying hardware, we should have no trouble maintaining
that for the foreseeable future.

Then we can continue on about the engine discovery in parallel, not
blocking GPU topology discovery.


I can live with that, but would like to keep the gt/engines/ namespace 
reserved for the eventuality with go with engine info in sysfs at a 
later stage then.


Also, Lionel, did you have plans to use the engine info straight away 
in gpu top, or you only needed topology? I think you were drawing a 
nice block diagram of a GPU so do you need it for that?


Yes, I was planning to use it (in whatever form). I think it's quite a 
good piece of information to show in GPUTop.
The topology is not so much needed for diagrams, but more for making 
sense of the counters (which might need to be normalized per number of 
eus per slice/subslice for example).




Regards,

Tvrtko



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

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

[Tvrtko Ursulin]

On 11/12/2017 10:50, Joonas Lahtinen wrote:

+ Daniel, Chris

On Thu, 2017-12-07 at 09:21 +, Tvrtko Ursulin wrote:

On 04/12/2017 15:02, Lionel Landwerlin wrote:

Hi,

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


Important thing to mention as well is that it is trivial to get from the
master drm fd to the sysfs root, via fstat and opendir
/sys/dev/char/:. With the addition of the card symlink to
render nodes it is trivial for render node fd as well.

I am happy with this approach - it is extensible, flexible and avoids
issues with ioctl versioning or whatnot. With one value per file it is
trivial for userspace to access.

So for what I'm concerned, given how gputop would use all of this and so
be the userspace, if everyone else is happy, I think we could do a
detailed review and prehaps also think about including gputop in some
distribution to make the case 100% straightforward.


For the GPU topology I agree this is the right choice, it's going to be
about topology after all, and directory tree is the perfect candidate.
And if a new platform appears, then it's a new platform and may change
the topology well the hardware topology has changed.

For the engine enumeration, I'm not equally sold for sysfs exposing it.
It's a "linear list of engine instances with flags" how the userspace
is going to be looking at them. And it's also information about what to
pass to an IOCTL as arguments after decision has been made, and then
you already have the FD you know you'll be dealing with, at hand. So
another IOCTL for that seems more convenient.


Apart from more flexibility and easier to extend, sysfs might be a 
better fit for applications which do not otherwise need a drm fd. Say a 
top-like tool which shows engine utilization, or those patches I RFC-ed 
recently which do the same but per DRM client.


Okay, these stats are now available also via PMU so the argument is not 
the strongest I admit, but I still find it quite neat. It also might 
allow us to define our own policy with regards to needed privilege to 
access these stats, and not be governed by the perf API rules.



So I'd say for the GPU topology part, we go forward with the review and
make sure we don't expose driver internal bits that could break when
refactoring code. If the exposed N bits of information are strictly
tied to the underlying hardware, we should have no trouble maintaining
that for the foreseeable future.

Then we can continue on about the engine discovery in parallel, not
blocking GPU topology discovery.


I can live with that, but would like to keep the gt/engines/ namespace 
reserved for the eventuality with go with engine info in sysfs at a 
later stage then.


Also, Lionel, did you have plans to use the engine info straight away in 
gpu top, or you only needed topology? I think you were drawing a nice 
block diagram of a GPU so do you need it for that?


Regards,

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

Re: [PATCH 2/3] uapi: drm: New fourcc codes needed by Xilinx Video IP

[Ville Syrjälä]

On Mon, Dec 11, 2017 at 04:08:07PM +0200, Laurent Pinchart wrote:
> Hi Ville,
> 
> On Tuesday, 28 November 2017 20:11:42 EET Ville Syrjälä wrote:
> > On Tue, Nov 28, 2017 at 05:25:46PM +, Hyun Kwon wrote:
> > > On Tuesday, November 28, 2017 6:44 AM Ville Syrjälä wrote:
> > >> On Mon, Nov 27, 2017 at 06:27:32PM -0800, Hyun Kwon wrote:
> > >>> From: Jeffrey Mouroux 
> > >>> 
> > >>> The Xilinx Video Mixer and Xilinx Video Framebuffer DMA IP
> > >>> support video memory formats that are not represented in the
> > >>> current DRM fourcc library.  This patch adds those missing
> > >>> fourcc codes.
> > >>> 
> > >>> Signed-off-by: Jeffrey Mouroux 
> > >>> Signed-off-by: Hyun Kwon 
> > >>> ---
> > >>> 
> > >>>  include/uapi/drm/drm_fourcc.h | 9 +
> > >>>  1 file changed, 9 insertions(+)
> > >>> 
> > >>> diff --git a/include/uapi/drm/drm_fourcc.h
> > >>> b/include/uapi/drm/drm_fourcc.h
> > >>> index 3ad838d..83806d5 100644
> > >>> --- a/include/uapi/drm/drm_fourcc.h
> > >>> +++ b/include/uapi/drm/drm_fourcc.h
> > >>> @@ -112,6 +112,13 @@ extern "C" {
> > >>> 
> > >>>  #define DRM_FORMAT_VYUYfourcc_code('V', 'Y', 'U', 'Y')
> > >>> /* [31:0] Y1:Cb0:Y0:Cr0 8:8:8:8 little endian */
> > >>>  #define DRM_FORMAT_AYUVfourcc_code('A', 'Y', 'U', 'V')
> > >>> /* [31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
> > >>> +#define DRM_FORMAT_VUY888  fourcc_code('V', 'U', '2', '4') /* 
> > >>> [23:0]
> > >>> Cr:Cb:Y little endian */
> > >>> +#define DRM_FORMAT_XVUYfourcc_code('X', 'V', '2', '4') /* 
> > >>> [31:0]
> > >>> x:Cr:Cb:Y 8:8:8:8 little endian */
> > >>> +#define DRM_FORMAT_XVUY2101010 fourcc_code('X', 'V', '3', '0')
> > >>> /* [31:0] x:Cr:Cb:Y 2:10:10:10 little endian */
> > >>> +
> > >>> +/* Grey scale */
> > >>> +#define DRM_FORMAT_Y8  fourcc_code('G', 'R', 'E', 'Y') /* 8-bit
> > >>> packed greyscale Y:Y:Y:Y 8:8:8:8 */
> > >>> +#define DRM_FORMAT_Y10 fourcc_code('Y', '1', '0', ' ') /*
> > >>> 10-bit packed greyscale X:Y:Y:Y 2:10:10:10 */
> > >> 
> > >> These don't make sense to me. What does it even mean to have Y
> > >> replicated three or four times for each pixel?
> > > 
> > > Each pixel has one Y component. The comment is to describe how components
> > > are stored in 32bit, but I agree it's confusing. Will describe better.
> > For the 8 bit Y format you should then define it as 8 bits. Unless of
> > course it really is defined as a 32bit word containing 4 pixels. The
> > 10 bit case would be even funky since there would have to be two
> > bits of padding after every 3 pixels.
> > 
> > So are these really defined as 32 bit wits 3 or 4 pixels and potentially
> > a few bits of extra padding packed into each word? That seems rather
> > nuts to me because you can't even byte address each pixel.
> > 
> > I think such crazyness has no business living right next to the
> > sane formats, hence we should put all these into their own little
> > section of the header, and the names should somehow reflect that
> > they are in fact "special".
> 
> Thee Y8 format isn't special as it's just a plain 8-bit format.

Is it? The patch made it out to be something else perhaps. Impossible
to judge without reading the relevant xilinx docs I suppose.

> The Y10 format 
> is indeed not byte-addressable, but don't be too fast to dismiss it as crazy, 
> this kind of format is pretty common outside of the desktop graphics world. 
> There are even 10-bit formats with 3 components where the 8 LSBs of each 
> component are stored in three bytes, and the 2 MSBs are grouped in a fourth 
> byte with 2 bits of padding (or possibly with LSB and MSB switched, I can't 
> remember right now).

So you're saying the formats in this patch aren't quite as crazy as some
other formats out there? ;)

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

Re: [PATCH v14 0/3] Move backlight helper functions from tinydrm-helpers to linux/backlight

[Noralf Trønnes]

Den 11.12.2017 14.17, skrev Meghana Madhyastha:

On Sat, Dec 09, 2017 at 03:09:28PM +0100, Noralf Trønnes wrote:

Den 21.10.2017 13.55, skrev Meghana Madhyastha:

Changes in v14:
- s/backlight_get/of_find_backlight/ in patch 2/3
- Change commit message in patch 3/3 from requiring to acquiring

Meghana Madhyastha (3):
   drm/tinydrm: Move helper functions from tinydrm-helpers to backlight.h
   drm/tinydrm: Move tinydrm_of_find_backlight to backlight.c
   drm/tinydrm: Add devres versions of of_find_backlight

I tried the patchset and this is what I got:

[    8.057792] Unable to handle kernel paging request at virtual address
fe6b
[    8.069118] pgd = 93817cf7
[    8.075704] [fe6b] *pgd=1bfd7861, *pte=, *ppte=
[    8.086047] Internal error: Oops: 37 [#1] ARM
[    8.094285] Modules linked in: mi0283qt(+) mipi_dbi tinydrm backlight
bcm2835_rng rng_core
[    8.110535] CPU: 0 PID: 121 Comm: systemd-udevd Not tainted 4.15.0-rc2+
#2
[    8.121531] Hardware name: BCM2835
[    8.128964] task: 85dc6e21 task.stack: 4d8f2d19
[    8.137482] PC is at kobject_put+0x18/0x1dc
[    8.145556] LR is at put_device+0x24/0x28
[    8.153312] pc : []    lr : [] psr: a013
[    8.163321] sp : d6d33c18  ip : d6d33c40  fp : d6d33c3c
[    8.172238] r10: c0496d38  r9 :   r8 : d6e46680
[    8.181108] r7 : 0004  r6 : d766bc00  r5 : d6d33c70  r4 : fe4b
[    8.191237] r3 : bf0113b8  r2 : d766bd2c  r1 : d6e46710  r0 : fe4b
[    8.201248] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM Segment
none
[    8.211869] Control: 00c5387d  Table: 16d20008  DAC: 0051
[    8.221141] Process systemd-udevd (pid: 121, stack limit = 0xa0ab0c84)
[    8.231264] Stack: (0xd6d33c18 to 0xd6d34000)
[    8.239228] 3c00:
bf011858 c049728c
[    8.254539] 3c20: d7737010 d6e46700 d6d33c70 d766bc00 d6d33c4c d6d33c40
c048edb8 c076a1a8
[    8.270045] 3c40: d6d33c5c d6d33c50 bf0113dc c048eda0 d6d33c6c d6d33c60
c0496fc4 bf0113c4
[    8.285883] 3c60: d6d33ca4 d6d33c70 c04979f0 c0496fb4 d7737000 d6e46700
d6d33c9c d766bc00
[    8.301819] 3c80:  bf030100 c0d369dc c0d369e0 000e fdfb
d6d33cb4 d6d33ca8
[    8.317917] 3ca0: c0497ad0 c0497858 d6d33cec d6d33cb8 c0493efc c0497a94
c057e738 c057d26c
[    8.334043] 3cc0: d6d33cec d766bc00 d766bc34 bf030100 c0c4a5d8 0001
d6e46464 0028
[    8.350344] 3ce0: d6d33d0c d6d33cf0 c049414c c0493c4c 0001 
bf030100 c04940b0
[    8.367036] 3d00: d6d33d34 d6d33d10 c0492018 c04940bc d754f28c d76afbb0
d6dca534 bf030100
[    8.383997] 3d20:  d6dca500 d6d33d44 d6d33d38 c0493750 c0491fa8
d6d33d6c d6d33d48
[    8.401301] 3d40: c0493124 c0493734 bf02f4d6 d6d33d58 bf030100 bf033000
c0c04048 
[    8.418938] 3d60: d6d33d84 d6d33d70 c0494954 c0493048 bf030140 bf033000
d6d33d94 d6d33d88
[    8.436692] 3d80: c04c8794 c04948b4 d6d33da4 d6d33d98 bf033020 c04c8748
d6d33e1c d6d33da8
[    8.454638] 3da0: c0101a30 bf03300c d6d33dcc d6d33db8 c01013f4 c03f7c64
c0221690 6013
[    8.472918] 3dc0: d6d33e44 d6d33dd0 c010d04c c01013e0 d7401e40 014000c0
000c c0221770
[    8.491185] 3de0: d6d33e1c d6d33df0 c0221770 c021e29c 0001 fc36740d
bf030140 0001
[    8.509455] 3e00: d6e46500 d6e46440 0001 d6e46464 d6d33e44 d6d33e20
c0178628 c0101978
[    8.527727] 3e20: bf030140 d6e46440 d6d33e44 d6d33f40 0001 bf030140
d6d33f1c d6d33e48
[    8.546000] 3e40: c0177810 c01785c8 bf03014c 7fff bf030140 c0174ae8
d6d33f38 d6d33eb8
[    8.564264] 3e60: d6d33e9c b6d4f004 dcb059a4 c0c1619c bf030324 d6e46448
bf030188 dcad6000
[    8.582529] 3e80:  d6ca3e40    
 
[    8.600797] 3ea0:     6e72656b 6c65
 
[    8.619065] 3ec0:      
 
[    8.637319] 3ee0:    fc36740d 7fff 
b6d4f004 000d
[    8.655582] 3f00: 017b c0108044 d6d32000  d6d33fa4 d6d33f20
c0177f94 c0175d00
[    8.673835] 3f20: 7fff  0003   dcad6000
0002f9f4 
[    8.692093] 3f40: dcad6b80 dcad6000 0002f9f4 dcb05274 dcaf9e6a dcafa860
3000 3240
[    8.710350] 3f60:    1e34 002e 002f
0019 
[    8.728612] 3f80: 0013   1ef80900  
 d6d33fa8
[    8.746870] 3fa0: c0107e60 c0177f04 1ef80900  000d b6d4f004
 b6d4f928
[    8.765132] 3fc0: 1ef80900   017b b6d4f004 0002
00af6e18 
[    8.783394] 3fe0: bec95200 bec951f0 b6d4709c b6ea3c40 6010 000d
 
[    8.801685] [] (kobject_put) from []
(put_device+0x24/0x28)
[    8.814234] [] (put_device) from []
(devm_backlight_put+0x24/0x28 [backlight])
[    8.833323] [] (devm_backlight_put [backlight]) from
[] (devm_action_release+0x1c/0x20)
[    8.853182] [] (devm_action_release) from []
(release_nodes+0x1a4/0x1cc)
[    8.871702] [] (release_nodes) 

Re: [PATCH 2/3] uapi: drm: New fourcc codes needed by Xilinx Video IP

[Laurent Pinchart]

Hi Ville,

On Tuesday, 28 November 2017 20:11:42 EET Ville Syrjälä wrote:
> On Tue, Nov 28, 2017 at 05:25:46PM +, Hyun Kwon wrote:
> > On Tuesday, November 28, 2017 6:44 AM Ville Syrjälä wrote:
> >> On Mon, Nov 27, 2017 at 06:27:32PM -0800, Hyun Kwon wrote:
> >>> From: Jeffrey Mouroux 
> >>> 
> >>> The Xilinx Video Mixer and Xilinx Video Framebuffer DMA IP
> >>> support video memory formats that are not represented in the
> >>> current DRM fourcc library.  This patch adds those missing
> >>> fourcc codes.
> >>> 
> >>> Signed-off-by: Jeffrey Mouroux 
> >>> Signed-off-by: Hyun Kwon 
> >>> ---
> >>> 
> >>>  include/uapi/drm/drm_fourcc.h | 9 +
> >>>  1 file changed, 9 insertions(+)
> >>> 
> >>> diff --git a/include/uapi/drm/drm_fourcc.h
> >>> b/include/uapi/drm/drm_fourcc.h
> >>> index 3ad838d..83806d5 100644
> >>> --- a/include/uapi/drm/drm_fourcc.h
> >>> +++ b/include/uapi/drm/drm_fourcc.h
> >>> @@ -112,6 +112,13 @@ extern "C" {
> >>> 
> >>>  #define DRM_FORMAT_VYUY  fourcc_code('V', 'Y', 'U', 'Y')
> >>> /* [31:0] Y1:Cb0:Y0:Cr0 8:8:8:8 little endian */
> >>>  #define DRM_FORMAT_AYUV  fourcc_code('A', 'Y', 'U', 'V')
> >>> /* [31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
> >>> +#define DRM_FORMAT_VUY888fourcc_code('V', 'U', '2', '4') /* 
> >>> [23:0]
> >>> Cr:Cb:Y little endian */
> >>> +#define DRM_FORMAT_XVUY  fourcc_code('X', 'V', '2', '4') /* 
> >>> [31:0]
> >>> x:Cr:Cb:Y 8:8:8:8 little endian */
> >>> +#define DRM_FORMAT_XVUY2101010   fourcc_code('X', 'V', '3', '0')
> >>> /* [31:0] x:Cr:Cb:Y 2:10:10:10 little endian */
> >>> +
> >>> +/* Grey scale */
> >>> +#define DRM_FORMAT_Y8fourcc_code('G', 'R', 'E', 'Y') /* 8-bit
> >>> packed greyscale Y:Y:Y:Y 8:8:8:8 */
> >>> +#define DRM_FORMAT_Y10   fourcc_code('Y', '1', '0', ' ') /*
> >>> 10-bit packed greyscale X:Y:Y:Y 2:10:10:10 */
> >> 
> >> These don't make sense to me. What does it even mean to have Y
> >> replicated three or four times for each pixel?
> > 
> > Each pixel has one Y component. The comment is to describe how components
> > are stored in 32bit, but I agree it's confusing. Will describe better.
> For the 8 bit Y format you should then define it as 8 bits. Unless of
> course it really is defined as a 32bit word containing 4 pixels. The
> 10 bit case would be even funky since there would have to be two
> bits of padding after every 3 pixels.
> 
> So are these really defined as 32 bit wits 3 or 4 pixels and potentially
> a few bits of extra padding packed into each word? That seems rather
> nuts to me because you can't even byte address each pixel.
> 
> I think such crazyness has no business living right next to the
> sane formats, hence we should put all these into their own little
> section of the header, and the names should somehow reflect that
> they are in fact "special".

Thee Y8 format isn't special as it's just a plain 8-bit format. The Y10 format 
is indeed not byte-addressable, but don't be too fast to dismiss it as crazy, 
this kind of format is pretty common outside of the desktop graphics world. 
There are even 10-bit formats with 3 components where the 8 LSBs of each 
component are stored in three bytes, and the 2 MSBs are grouped in a fourth 
byte with 2 bits of padding (or possibly with LSB and MSB switched, I can't 
remember right now).

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH 1/3] drm: drm_fourcc: Add scaling and padding factor to drm_format_info

[Laurent Pinchart]

Hi Hyun,

Thank you for the patch.

On Tuesday, 28 November 2017 04:27:31 EET Hyun Kwon wrote:
> From: Satish Kumar Nagireddy 
> 
> 'cpp_scale' can be used as a multiplying factor to calculate
> bytes per component based on color format.
> For eg. scaling factor of YUV420 8 bit format is 1
> so multiplying factor is 1 (8/8)
> scaling factor of YUV420 10 bit format is 1.25 (10/8)
> 
> 'padding_scale' can be used as a multiplying factor to calculate
> actual width of video according to color format.
> For eg. padding factor of YUV420 8 bit format: 8 bits per 1 component
> no padding bits here, so multiplying factor is 1
> padding factor of YUV422 10 bit format: 32 bits per 3 components
> each component is 10 bit and the factor is 32/30
> 
> Signed-off-by: Satish Kumar Nagireddy 
> Signed-off-by: Hyun Kwon 
> ---
>  drivers/gpu/drm/drm_fourcc.c | 136 ++--
>  include/drm/drm_fourcc.h |   9 +++
>  2 files changed, 77 insertions(+), 68 deletions(-)

[snip]

> diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
> index 6942e84..0202d19 100644
> --- a/include/drm/drm_fourcc.h
> +++ b/include/drm/drm_fourcc.h
> @@ -36,16 +36,25 @@ struct drm_mode_fb_cmd2;
>   *   use in new code and set to 0 for new formats.
>   * @num_planes: Number of color planes (1 to 3)
>   * @cpp: Number of bytes per pixel (per plane)
> + * @cpp_scale: { numerator, denominator }. Scaling factor for
> + *   non 8bit aligned formats. For instance, { 10, 8 } can be used for
> + *   10 bit component / pixel formats.

Stupid question, wouldn't it be better to replace cpp with a number of bits 
per pixel then ? Or possibly supplement it if we need both. A scaling factor 
seems difficult to use.

>   * @hsub: Horizontal chroma subsampling factor
>   * @vsub: Vertical chroma subsampling factor
> + * @padding_scale: { numerator, denominator }. Scaling factor for
> + *   padding. This can be used for formats with padding bits after
> + *   multiple pixels / components. For instance, if there are 2 bit
> + *   padding after 3 10bit components, the value should be { 32, 30 }.

Similarly, why don't you instead specify the number of padding bits directly ?

>   */
>  struct drm_format_info {
>   u32 format;
>   u8 depth;
>   u8 num_planes;
>   u8 cpp[3];
> + u8 cpp_scale[2];
>   u8 hsub;
>   u8 vsub;
> + u8 padding_scale[2];
>  };
> 
>  /**


-- 
Regards,

Laurent Pinchart

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

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

[Lionel Landwerlin]

On 11/12/17 10:50, Joonas Lahtinen wrote:

+ Daniel, Chris

On Thu, 2017-12-07 at 09:21 +, Tvrtko Ursulin wrote:

On 04/12/2017 15:02, Lionel Landwerlin wrote:

Hi,

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

Important thing to mention as well is that it is trivial to get from the
master drm fd to the sysfs root, via fstat and opendir
/sys/dev/char/:. With the addition of the card symlink to
render nodes it is trivial for render node fd as well.

I am happy with this approach - it is extensible, flexible and avoids
issues with ioctl versioning or whatnot. With one value per file it is
trivial for userspace to access.

So for what I'm concerned, given how gputop would use all of this and so
be the userspace, if everyone else is happy, I think we could do a
detailed review and prehaps also think about including gputop in some
distribution to make the case 100% straightforward.

For the GPU topology I agree this is the right choice, it's going to be
about topology after all, and directory tree is the perfect candidate.
And if a new platform appears, then it's a new platform and may change
the topology well the hardware topology has changed.

For the engine enumeration, I'm not equally sold for sysfs exposing it.
It's a "linear list of engine instances with flags" how the userspace
is going to be looking at them. And it's also information about what to
pass to an IOCTL as arguments after decision has been made, and then
you already have the FD you know you'll be dealing with, at hand. So
another IOCTL for that seems more convenient.


We'll be working with topology from the render FD too.
This last series added the ability to find the card from the fd's 
major/minor just for that case.




So I'd say for the GPU topology part, we go forward with the review and
make sure we don't expose driver internal bits that could break when
refactoring code. If the exposed N bits of information are strictly
tied to the underlying hardware, we should have no trouble maintaining
that for the foreseeable future.


If we're going with just topology through sysfs, what should the layout 
look like?

card/gt/rcs/topology?



Then we can continue on about the engine discovery in parallel, not
blocking GPU topology discovery.

Regards, Joonas


Regards,

Tvrtko


Cheers,

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

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

--
2.15.1
___
Intel-gfx mailing list
intel-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


___
Intel-gfx mailing list
intel-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx



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

[Bug 104206] [drm:construct [amdgpu]] *ERROR* construct: Invalid Connector ObjectID from Adapter Service for connector index:2!

[bugzilla-daemon]

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

--- Comment #3 from Andrew  ---
Michael,
 Thank you for your reply.

Why pastebin is not good? ( Thought fedora's one is blessed/approved)

The rawhide mesa rpms versions are the same as in f27. Should i
recompile/reconfigure them somehow?


On Dec 11, 2017 6:25 AM,  wrote:

> *Comment # 2  on
> bug 104206  from
> Michel Dänzer  *
>
> ... instead of referencing external sites, especially pastebins.
>
> Looks like there's a Mesa installation / configuration issue which prevents
> hardware acceleration from working, and the xf86-video-amdgpu driver can't
> handle this and crashes.
>
> --
> You are receiving this mail because:
>
>- You reported the bug.
>
>

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

[Bug 104192] [amdgpu][VEGA10] regular lockups with VM_L2_PROTECTION_FAULT_STATUS

[bugzilla-daemon]

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

--- Comment #11 from Tom Englund  ---
(In reply to Tom Englund from comment #10)
> (In reply to Michel Dänzer from comment #9)
> > FWIW, I bisected some piglit regressions to LLVM SVN r319894.
> 
> thanks, that gave me some starting points to bisecting, narrowed things down
> now to where r319882 works while r319894 freezes. starting to look like the
> same regression you are facing.

after yet another compilation, r319893 works. so it would mean this commit is
the cause for the freezes/errors.

https://github.com/llvm-mirror/llvm/commit/3b06fccc7749b974d2905fe852b389b4697485b7

-- 
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 v14 0/3] Move backlight helper functions from tinydrm-helpers to linux/backlight

[Meghana Madhyastha]

On Sat, Dec 09, 2017 at 03:09:28PM +0100, Noralf Trønnes wrote:
> 
> Den 21.10.2017 13.55, skrev Meghana Madhyastha:
> >Changes in v14:
> >- s/backlight_get/of_find_backlight/ in patch 2/3
> >- Change commit message in patch 3/3 from requiring to acquiring
> >
> >Meghana Madhyastha (3):
> >   drm/tinydrm: Move helper functions from tinydrm-helpers to backlight.h
> >   drm/tinydrm: Move tinydrm_of_find_backlight to backlight.c
> >   drm/tinydrm: Add devres versions of of_find_backlight
> 
> I tried the patchset and this is what I got:
> 
> [    8.057792] Unable to handle kernel paging request at virtual address
> fe6b
> [    8.069118] pgd = 93817cf7
> [    8.075704] [fe6b] *pgd=1bfd7861, *pte=, *ppte=
> [    8.086047] Internal error: Oops: 37 [#1] ARM
> [    8.094285] Modules linked in: mi0283qt(+) mipi_dbi tinydrm backlight
> bcm2835_rng rng_core
> [    8.110535] CPU: 0 PID: 121 Comm: systemd-udevd Not tainted 4.15.0-rc2+
> #2
> [    8.121531] Hardware name: BCM2835
> [    8.128964] task: 85dc6e21 task.stack: 4d8f2d19
> [    8.137482] PC is at kobject_put+0x18/0x1dc
> [    8.145556] LR is at put_device+0x24/0x28
> [    8.153312] pc : []    lr : [] psr: a013
> [    8.163321] sp : d6d33c18  ip : d6d33c40  fp : d6d33c3c
> [    8.172238] r10: c0496d38  r9 :   r8 : d6e46680
> [    8.181108] r7 : 0004  r6 : d766bc00  r5 : d6d33c70  r4 : fe4b
> [    8.191237] r3 : bf0113b8  r2 : d766bd2c  r1 : d6e46710  r0 : fe4b
> [    8.201248] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM Segment
> none
> [    8.211869] Control: 00c5387d  Table: 16d20008  DAC: 0051
> [    8.221141] Process systemd-udevd (pid: 121, stack limit = 0xa0ab0c84)
> [    8.231264] Stack: (0xd6d33c18 to 0xd6d34000)
> [    8.239228] 3c00:  
> bf011858 c049728c
> [    8.254539] 3c20: d7737010 d6e46700 d6d33c70 d766bc00 d6d33c4c d6d33c40
> c048edb8 c076a1a8
> [    8.270045] 3c40: d6d33c5c d6d33c50 bf0113dc c048eda0 d6d33c6c d6d33c60
> c0496fc4 bf0113c4
> [    8.285883] 3c60: d6d33ca4 d6d33c70 c04979f0 c0496fb4 d7737000 d6e46700
> d6d33c9c d766bc00
> [    8.301819] 3c80:  bf030100 c0d369dc c0d369e0 000e fdfb
> d6d33cb4 d6d33ca8
> [    8.317917] 3ca0: c0497ad0 c0497858 d6d33cec d6d33cb8 c0493efc c0497a94
> c057e738 c057d26c
> [    8.334043] 3cc0: d6d33cec d766bc00 d766bc34 bf030100 c0c4a5d8 0001
> d6e46464 0028
> [    8.350344] 3ce0: d6d33d0c d6d33cf0 c049414c c0493c4c 0001 
> bf030100 c04940b0
> [    8.367036] 3d00: d6d33d34 d6d33d10 c0492018 c04940bc d754f28c d76afbb0
> d6dca534 bf030100
> [    8.383997] 3d20:  d6dca500 d6d33d44 d6d33d38 c0493750 c0491fa8
> d6d33d6c d6d33d48
> [    8.401301] 3d40: c0493124 c0493734 bf02f4d6 d6d33d58 bf030100 bf033000
> c0c04048 
> [    8.418938] 3d60: d6d33d84 d6d33d70 c0494954 c0493048 bf030140 bf033000
> d6d33d94 d6d33d88
> [    8.436692] 3d80: c04c8794 c04948b4 d6d33da4 d6d33d98 bf033020 c04c8748
> d6d33e1c d6d33da8
> [    8.454638] 3da0: c0101a30 bf03300c d6d33dcc d6d33db8 c01013f4 c03f7c64
> c0221690 6013
> [    8.472918] 3dc0: d6d33e44 d6d33dd0 c010d04c c01013e0 d7401e40 014000c0
> 000c c0221770
> [    8.491185] 3de0: d6d33e1c d6d33df0 c0221770 c021e29c 0001 fc36740d
> bf030140 0001
> [    8.509455] 3e00: d6e46500 d6e46440 0001 d6e46464 d6d33e44 d6d33e20
> c0178628 c0101978
> [    8.527727] 3e20: bf030140 d6e46440 d6d33e44 d6d33f40 0001 bf030140
> d6d33f1c d6d33e48
> [    8.546000] 3e40: c0177810 c01785c8 bf03014c 7fff bf030140 c0174ae8
> d6d33f38 d6d33eb8
> [    8.564264] 3e60: d6d33e9c b6d4f004 dcb059a4 c0c1619c bf030324 d6e46448
> bf030188 dcad6000
> [    8.582529] 3e80:  d6ca3e40    
>  
> [    8.600797] 3ea0:     6e72656b 6c65
>  
> [    8.619065] 3ec0:      
>  
> [    8.637319] 3ee0:    fc36740d 7fff 
> b6d4f004 000d
> [    8.655582] 3f00: 017b c0108044 d6d32000  d6d33fa4 d6d33f20
> c0177f94 c0175d00
> [    8.673835] 3f20: 7fff  0003   dcad6000
> 0002f9f4 
> [    8.692093] 3f40: dcad6b80 dcad6000 0002f9f4 dcb05274 dcaf9e6a dcafa860
> 3000 3240
> [    8.710350] 3f60:    1e34 002e 002f
> 0019 
> [    8.728612] 3f80: 0013   1ef80900  
>  d6d33fa8
> [    8.746870] 3fa0: c0107e60 c0177f04 1ef80900  000d b6d4f004
>  b6d4f928
> [    8.765132] 3fc0: 1ef80900   017b b6d4f004 0002
> 00af6e18 
> [    8.783394] 3fe0: bec95200 bec951f0 b6d4709c b6ea3c40 6010 000d
>  
> [    8.801685] [] (kobject_put) from []
> (put_device+0x24/0x28)
> [    8.814234] [] (put_device) from []
> 

[Bug 104192] [amdgpu][VEGA10] regular lockups with VM_L2_PROTECTION_FAULT_STATUS

[bugzilla-daemon]

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

--- Comment #10 from Tom Englund  ---
(In reply to Michel Dänzer from comment #9)
> FWIW, I bisected some piglit regressions to LLVM SVN r319894.

thanks, that gave me some starting points to bisecting, narrowed things down
now to where r319882 works while r319894 freezes. starting to look like the
same regression you are facing.

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

[PATCH] [v2] drm/i915: use static const array for PICK macro

[Arnd Bergmann]

The varargs macro trick in _PIPE3/_PHY3/_PORT3 was meant as an optimization
to shrink the i915 kernel module by around 1000 bytes. However, the
downside is a size regression with CONFIG_KASAN, as I found from stack size
warnings with gcc-7.0.1:

before:
drivers/gpu/drm/i915/intel_dpll_mgr.c: In function 'bxt_ddi_pll_get_hw_state':
drivers/gpu/drm/i915/intel_dpll_mgr.c:1644:1: error: the frame size of 176 
bytes is larger than 100 bytes [-Werror=frame-larger-than=]
drivers/gpu/drm/i915/intel_dpll_mgr.c: In function 'bxt_ddi_pll_enable':
drivers/gpu/drm/i915/intel_dpll_mgr.c:1548:1: error: the frame size of 224 
bytes is larger than 100 bytes [-Werror=frame-larger-than=]

after:
drivers/gpu/drm/i915/intel_dpll_mgr.c: In function 'bxt_ddi_pll_get_hw_state':
drivers/gpu/drm/i915/intel_dpll_mgr.c:1644:1: error: the frame size of 1016 
bytes is larger than 1000 bytes [-Werror=frame-larger-than=]
drivers/gpu/drm/i915/intel_dpll_mgr.c: In function 'bxt_ddi_pll_enable':
drivers/gpu/drm/i915/intel_dpll_mgr.c:1548:1: error: the frame size of 1960 
bytes is larger than 1000 bytes [-Werror=frame-larger-than=]

I also checked the module sizes and got with gcc-7.0.1

original:
   textdata bss dec hex filename
2380830 11554364448 3540714  3606ea drivers/gpu/drm/i915/i915-kasan.o
1298054  5436922884 1844630  1c2596 drivers/gpu/drm/i915/i915-nokasan.o

after ce64645d86ac:
   textdata bss dec hex filename
2389515 11544764448 3548439  362517 drivers/gpu/drm/i915/i915-kasan.o
1299639  5436922884 1846215  1c2bc7 drivers/gpu/drm/i915/i915-nokasan.o

with this patch:
   textdata bss dec hex filename
2381275 11638844448 3549607  3629a7 drivers/gpu/drm/i915/i915-kasan.o
1296038  5436922884 1842614  1c1db6 drivers/gpu/drm/i915/i915-nokasan.o

Actually showing a code size growth in .text both with and without kasan,
and my version gets most of it back at the expense of larger .data when
kasan is enabled.

Fixes: ce64645d86ac ("drm/i915: use variadic macros and arrays to choose 
port/pipe based registers")
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80114
Link: https://lkml.org/lkml/2017/3/20/1022
Cc: Jani Nikula 
Signed-off-by: Arnd Bergmann 
---
v2: rebased after a1986f4174a4 ("drm/i915: Remove unnecessary PORT3 
definition.")
---
 drivers/gpu/drm/i915/i915_reg.h | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 09bf043c1c2e..36f4408503e1 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -139,7 +139,7 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
return !i915_mmio_reg_equal(reg, INVALID_MMIO_REG);
 }
 
-#define _PICK(__index, ...) (((const u32 []){ __VA_ARGS__ })[__index])
+#define _PICK(__index, ...) ({static const u32 __arr[] = { __VA_ARGS__ }; 
__arr[__index];})
 
 #define _PIPE(pipe, a, b) ((a) + (pipe)*((b)-(a)))
 #define _MMIO_PIPE(pipe, a, b) _MMIO(_PIPE(pipe, a, b))
@@ -3097,10 +3097,10 @@ enum i915_power_well_id {
 /*
  * Clock control & power management
  */
-#define _DPLL_A (dev_priv->info.display_mmio_offset + 0x6014)
-#define _DPLL_B (dev_priv->info.display_mmio_offset + 0x6018)
-#define _CHV_DPLL_C (dev_priv->info.display_mmio_offset + 0x6030)
-#define DPLL(pipe) _MMIO_PIPE3((pipe), _DPLL_A, _DPLL_B, _CHV_DPLL_C)
+#define _DPLL_A0x6014
+#define _DPLL_B0x6018
+#define _CHV_DPLL_C0x6030
+#define DPLL(pipe) _MMIO(dev_priv->info.display_mmio_offset + _PICK((pipe), 
_DPLL_A, _DPLL_B, _CHV_DPLL_C))
 
 #define VGA0   _MMIO(0x6000)
 #define VGA1   _MMIO(0x6004)
@@ -3196,10 +3196,10 @@ enum i915_power_well_id {
 #define   SDVO_MULTIPLIER_SHIFT_HIRES  4
 #define   SDVO_MULTIPLIER_SHIFT_VGA0
 
-#define _DPLL_A_MD (dev_priv->info.display_mmio_offset + 0x601c)
-#define _DPLL_B_MD (dev_priv->info.display_mmio_offset + 0x6020)
-#define _CHV_DPLL_C_MD (dev_priv->info.display_mmio_offset + 0x603c)
-#define DPLL_MD(pipe) _MMIO_PIPE3((pipe), _DPLL_A_MD, _DPLL_B_MD, 
_CHV_DPLL_C_MD)
+#define _DPLL_A_MD 0x601c
+#define _DPLL_B_MD 0x6020
+#define _CHV_DPLL_C_MD 0x603c
+#define DPLL_MD(pipe) _MMIO(dev_priv->info.display_mmio_offset + _PICK((pipe), 
_DPLL_A_MD, _DPLL_B_MD, _CHV_DPLL_C_MD))
 
 /*
  * UDI pixel divider, controlling how many pixels are stuffed into a packet.
-- 
2.9.0

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

Re: tinydrm: page allocation failure

[Noralf Trønnes]

Den 11.12.2017 04.28, skrev David Lechner:
I'm using drm-misc/drm-misc-next and occasionally getting errors as 
seen in the stack traces below. I'm not really sure what to make of 
it. Any ideas?




The spi controller driver has told the spi core to allocate dummy
buffers for tx/rx: spi_sync -> __spi_pump_messages -> spi_map_msg
-> krealloc -> __do_krealloc -> kmalloc_track_caller

order:4 means it's trying to allocate 2^4*PAGE_SIZE = 64kB, which
probably is the max DMA limit. So this is a pixel data transfer.

On my Raspberry Pi I've got 43 chunks of 64kB available if I have
understood this right:

$ sudo cat /proc/buddyinfo
Node 0, zone   Normal 40 68 66 51 43 46 13  
1  3  3 75


I don't know what those dummy buffers are used for.

Noralf.



[ 1727.253743] kworker/0:2: page allocation failure: order:4, 
mode:0x14040c1(GFP_KERNEL|GFP_DMA|__GFP_COMP), nodemask=(null)
[ 1727.298438] CPU: 0 PID: 1913 Comm: kworker/0:2 Tainted: P 
4.15.0-rc2-08575-gbc02198-dirty #612

[ 1727.331513] Hardware name: Generic DA850/OMAP-L138/AM18x
[ 1727.354135] Workqueue: events drm_fb_helper_dirty_work 
[drm_kms_helper]

[ 1727.379355] Backtrace:
[ 1727.380665] [] (dump_backtrace) from [] 
(show_stack+0x18/0x1c)

[ 1727.423509]  r7:0040 r6:c0521840 r5:e000 r4:
[ 1727.434302] [] (show_stack) from [] 
(dump_stack+0x20/0x28)
[ 1727.468647] [] (dump_stack) from [] 
(warn_alloc+0x94/0x13c)
[ 1727.481443] [] (warn_alloc) from [] 
(__alloc_pages_nodemask+0x8d0/0xbd4)

[ 1727.514315]  r3:0004 r2:c0521840
[ 1727.524305]  r6:0023 r5: r4:c05c915c
[ 1727.530599] [] (__alloc_pages_nodemask) from [] 
(kmalloc_order+0x20/0x54)
[ 1727.554296]  r10: r9:6013 r8:c02f0e98 r7:014000c1 
r6:c2ae9d94 r5:a000

[ 1727.575312]  r4:
[ 1727.587963] [] (kmalloc_order) from [] 
(__kmalloc_track_caller+0x180/0x1a4)
[ 1727.624311] [] (__kmalloc_track_caller) from [] 
(krealloc+0x7c/0xc0)
[ 1727.654324]  r10: r9:6013 r8:c02f0e98 r7:014000c1 
r6:c2ae9d94 r5:a000

[ 1727.668407]  r4:
[ 1727.669779] [] (krealloc) from [] 
(__spi_pump_messages+0x4bc/0x584)
[ 1727.704329]  r9:6013 r8:c02ef590 r7: r6:c2ae9d94 
r5:c2b50c00 r4:a000
[ 1727.710940] [] (__spi_pump_messages) from [] 
(__spi_sync+0x250/0x284)
[ 1727.744313]  r10: r9:6013 r8:c02ef590 r7:c2b50c00 
r6:c2ae9d94 r5:c2b50400

[ 1727.751125]  r4:6013
[ 1727.752479] [] (__spi_sync) from [] 
(spi_sync+0x2c/0x44)
[ 1727.781959]  r9: r8:c305a000 r7:c2b50400 r6:c2ae9d94 
r5:c2ae9d94 r4:c2b50400
[ 1727.814395] [] (spi_sync) from [] 
(tinydrm_spi_transfer+0x118/0x1b8 [tinydrm])

[ 1727.822355]  r5:7ffc r4:
[ 1727.840616] [] (tinydrm_spi_transfer [tinydrm]) from 
[] (mipi_dbi_typec3_command+0x114/0x1cc [mipi_dbi])
[ 1727.874285]  r10:c05e67e4 r9: r8:0010 r7:c2b50400 
r6:c305 r5:c2bd6010

[ 1727.881098]  r4:a000
[ 1727.882486] [] (mipi_dbi_typec3_command [mipi_dbi]) from 
[] (mipi_dbi_command_buf+0x40/0x54 [mipi_dbi])
[ 1727.924298]  r8:a000 r7:c305 r6:bf2b32d8 r5:c2bd65c0 
r4:c2bd6010
[ 1727.929891] [] (mipi_dbi_command_buf [mipi_dbi]) from 
[] (mipi_dbi_fb_dirty+0x18c/0x218 [mipi_dbi])
[ 1727.964291]  r9: r8:c305 r7:0001 r6:c1f7f600 
r5:c2bd65a0 r4:c2bd6010
[ 1727.971220] [] (mipi_dbi_fb_dirty [mipi_dbi]) from 
[] (drm_fb_helper_dirty_work+0xc8/0xe4 [drm_kms_helper])
[ 1728.004256]  r9: r8:c05e67e4 r7:c2f5d200 r6: 
r5:6013 r4:bf2b24dc
[ 1728.011371] [] (drm_fb_helper_dirty_work 
[drm_kms_helper]) from [] (process_one_work+0x140/0x454)

[ 1728.054256]  r5:c1f6de40 r4:c1e861f4
[ 1728.056676] [] (process_one_work) from [] 
(worker_thread+0x40/0x64c)
[ 1728.063570]  r10:c05e67e4 r9:c2ae8000 r8:0008 r7:c05f7220 
r6:c05e67f8 r5:c1f6de58

[ 1728.090392]  r4:c1f6de40
[ 1728.097104] [] (worker_thread) from [] 
(kthread+0x108/0x148)
[ 1728.103522]  r10:c1ced258 r9:c283bea4 r8:c1f6de40 r7:c2ae8000 
r6: r5:c058da00

[ 1728.144241]  r4:c1ced240
[ 1728.145601] [] (kthread) from [] 
(ret_from_fork+0x14/0x34)
[ 1728.152331]  r10: r9: r8: r7: 
r6: r5:c00382c4

[ 1728.182111]  r4:c058da00
[ 1728.183397] Mem-Info:
[ 1728.184877] active_anon:2927 inactive_anon:204 isolated_anon:0
    active_file:2033 inactive_file:1830 isolated_file:0
    unevictable:0 dirty:107 writeback:0 unstable:0
    slab_reclaimable:996 slab_unreclaimable:1441
    mapped:3107 shmem:320 pagetables:149 bounce:0
    free:4279 free_pcp:0 free_cma:3098
[ 1728.254307] Node 0 active_anon:11732kB inactive_anon:792kB 
active_file:8188kB inactive_file:7376kB unevictable:0kB 
isolated(anon):0kB isolated(file):0kB mapped:12512kB dirty:456kB 
writeback:0kB shmem:1280kB writeback_tmp:0kB unstable:0kB 
all_unreclaimable? no
[ 1728.304296] DMA free:16988kB min:820kB low:1024kB high:1228kB 
active_anon:11748kB inactive_anon:776kB 

Re: [Intel-gfx] [PATCH] drm/i915: use static const array for PICK macro

[Arnd Bergmann]

On Tue, Mar 21, 2017 at 12:23 PM, Jani Nikula
 wrote:
> On Tue, 21 Mar 2017, Daniel Vetter  wrote:
>> On Tue, Mar 21, 2017 at 09:44:07AM +0100, Arnd Bergmann wrote:
>>> On Tue, Mar 21, 2017 at 9:26 AM, Jani Nikula
>>>  wrote:
>>> > On Mon, 20 Mar 2017, Arnd Bergmann  wrote:
>>> >> The varargs macro trick in _PIPE3/_PHY3/_PORT3 was meant as an 
>>> >> optimization
>>> >> to shrink the i915 kernel module by around 1000 bytes.
>>> >
>>> > Really, I didn't care one bit about the size shrink, I only cared about
>>> > making it easier and less error prone to increase the number of args in
>>> > a number of places. Maintainability and correctness were the goals. Just
>>> > for the record. ;)
>>>
>>> Ok. My only interest here is the warning about possible stack overflow,
>>> though the fact that KASAN considers the array code to be fragile is
>>> an indication that it is perhaps actually dangerous: if we ever run into
>>> a bug that causes the array index to overflow, we might in theory
>>> have a security bug that lets users access arbitrary kernel pointers.
>>>
>>> While the risk for that actually happening is very low, the original code
>>> was safer in that regard. My patch on top of yours merely turns a
>>> hypothetical arbitrary stack access into an arbitrary .data access,
>>> and I don't even know which one would be worse.
>>
>> Even without these arrays, if userspace could control the index we feed
>> into these you get arbitrary mmio access. Or semi-arbitrary at least.
>>
>> None of these are bugs we should ever let through, and I think with the
>> current code design (where the driver constructs structs that contain the
>> right indizes, and userspace only ever gets to point at these structs
>> using an idr lookup) none of these are likely to happen.
>
> That's all true, but I'm curious if explicit checks would help
> kasan. Something like:
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 04c8f69fcc62..0ab32a05b5d8 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -48,7 +48,8 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
> return !i915_mmio_reg_equal(reg, INVALID_MMIO_REG);
>  }
>
> -#define _PICK(__index, ...) (((const u32 []){ __VA_ARGS__ })[__index])
> +#define _PICK_NARGS(...) ARRAY_SIZE(((const u32 []){ __VA_ARGS__ }))
> +#define _PICK(__index, ...) ((__index) >= 0 && (__index) < 
> _PICK_NARGS(__VA_ARGS__) ? ((const u32 []){ __VA_ARGS__ })[__index] : 0)
>
>  #define _PIPE(pipe, a, b) ((a) + (pipe)*((b)-(a)))
>  #define _MMIO_PIPE(pipe, a, b) _MMIO(_PIPE(pipe, a, b))
>
> ---
>
> Arnd, can you check that with kasan please? (I don't have gcc 7.) For me
> the size diff against current git is
>
> text   data bss dec hex filename
> -1137236  312112948 1171395  11dfc3 drivers/gpu/drm/i915/i915.ko
> +1139702  312112948 1173861  11e965 drivers/gpu/drm/i915/i915.ko
>

I just revisited my old patch when I ran into the stack size warning once
more, and realized I had not really answered your question earlier.

I compared your version to what is in 4.15-rc3 now, and to my version,
and confirmed that yours produces the largest code size of the three,
and doesn't address the warnings we get, but does cause additional
warnings ("comparison of constant '3' with boolean expression is always
true"), so that won't get us anywhere. Here are the numbers I get
with gcc-8:

   textdata bss dec hex filename
2500045 4864536912 2993410 2dad02 i915-kasan-4_14.ko
2488028 4979096912 2992849 2daad1 i915-kasan-arnd.ko
2508814 4864536912 3002179 2dcf43 i915-kasan-jani.ko
1639798   632694448 1707515 1a0dfb i915-nokasan-4.15.ko
1635284   632694448 1703001 19fc59 i915-nokasan-arnd.ko
1648331   632694448 1716048 1a2f50 i915-nokasan-jani.ko

I'll resend my old patch with the original description since I can't easily
reproduce it now without your original change, and the code has
changed again in the meantime, so I had to slightly adapt my
patch to still apply.

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

Re: [PATCH 20/27] drm/etnaviv: refcount the submit object

[Philipp Zabel]

On Fri, 2017-12-01 at 11:36 +0100, Lucas Stach wrote:
> The submit object lifetime will get extended to the actual GPU
> execution. As multiple users will depend on this, add a kref to
> properly control destuction of the object.
> 
> Signed-off-by: Lucas Stach 

Reviewed-by: Philipp Zabel 

regards
Philipp

>  drivers/gpu/drm/etnaviv/etnaviv_gem.h|  3 +++
>  drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 12 ++--
>  2 files changed, 13 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.h 
> b/drivers/gpu/drm/etnaviv/etnaviv_gem.h
> index 6b78d059ed2d..4238f8d8541d 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gem.h
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.h
> @@ -101,6 +101,7 @@ struct etnaviv_gem_submit_bo {
>   * lasts for the duration of the submit-ioctl.
>   */
>  struct etnaviv_gem_submit {
> + struct kref refcount;
>   struct etnaviv_gpu *gpu;
>   struct dma_fence *out_fence, *in_fence;
>   u32 flags;
> @@ -109,6 +110,8 @@ struct etnaviv_gem_submit {
>   /* No new members here, the previous one is variable-length! */
>  };
>  
> +void etnaviv_submit_put(struct etnaviv_gem_submit * submit);
> +
>  int etnaviv_gem_wait_bo(struct etnaviv_gpu *gpu, struct drm_gem_object *obj,
>   struct timespec *timeout);
>  int etnaviv_gem_new_private(struct drm_device *dev, size_t size, u32 flags,
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c 
> b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> index 3090a46979af..9b4436c380ea 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> @@ -43,6 +43,7 @@ static struct etnaviv_gem_submit *submit_create(struct 
> drm_device *dev,
>   return NULL;
>  
>   submit->gpu = gpu;
> + kref_init(>refcount);
>  
>   return submit;
>  }
> @@ -341,8 +342,10 @@ static int submit_perfmon_validate(struct 
> etnaviv_gem_submit *submit,
>   return 0;
>  }
>  
> -static void submit_cleanup(struct etnaviv_gem_submit *submit)
> +static void submit_cleanup(struct kref *kref)
>  {
> + struct etnaviv_gem_submit *submit =
> + container_of(kref, struct etnaviv_gem_submit, refcount);
>   unsigned i;
>  
>   for (i = 0; i < submit->nr_bos; i++) {
> @@ -367,6 +370,11 @@ static void submit_cleanup(struct etnaviv_gem_submit 
> *submit)
>   kfree(submit);
>  }
>  
> +void etnaviv_submit_put(struct etnaviv_gem_submit *submit)
> +{
> + kref_put(>refcount, submit_cleanup);
> +}
> +
>  int etnaviv_ioctl_gem_submit(struct drm_device *dev, void *data,
>   struct drm_file *file)
>  {
> @@ -544,7 +552,7 @@ int etnaviv_ioctl_gem_submit(struct drm_device *dev, void 
> *data,
>   args->fence = submit->out_fence->seqno;
>  
>  err_submit_objects:
> - submit_cleanup(submit);
> + etnaviv_submit_put(submit);
>  
>  err_submit_ww_acquire:
>   ww_acquire_fini();
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 102985] HDMI 2.0 4k EDIDs not available (Radeon RX Vega 56)

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

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

--- Comment #6 from Michel Dänzer  ---
Resolving per comment 5, thanks for the followup, glad it's working now!

-- 
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 104206] [drm:construct [amdgpu]] *ERROR* construct: Invalid Connector ObjectID from Adapter Service for connector index:2!

[bugzilla-daemon]

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

--- Comment #2 from Michel Dänzer  ---
... instead of referencing external sites, especially pastebins.

Looks like there's a Mesa installation / configuration issue which prevents
hardware acceleration from working, and the xf86-video-amdgpu driver can't
handle this and crashes.

-- 
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 104206] [drm:construct [amdgpu]] *ERROR* construct: Invalid Connector ObjectID from Adapter Service for connector index:2!

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

 CC||harry.wentl...@amd.com,
   ||jordan.laz...@amd.com

--- Comment #1 from Michel Dänzer  ---
Please attach files here directly instead of

-- 
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 104205] displayport connected monitor doesn't initialize display

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

 QA Contact|xorg-t...@lists.x.org   |
Product|xorg|DRI
  Component|Driver/AMDgpu   |DRM/AMDgpu
   Assignee|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop
   ||.org

--- Comment #1 from Michel Dänzer  ---
Please attach the full dmesg output.

It might be worth trying a current 4.15-rc kernel with CONFIG_DRM_AMD_DC and
CONFIG_DRM_AMD_DC_PRE_VEGA enabled.

-- 
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 10/27] drm/etnaviv: remove switch_context member from etnaviv_gpu

[Christian Gmeiner]

2017-12-01 11:36 GMT+01:00 Lucas Stach :
> There is no need to store this in the gpu struct. MMU flushes are triggered
> correctly in reaction to MMU maps and unmaps, independent of the current ctx
> and required pipe switches can be infered from the current and the desired
> GPU exec state.
>
> Signed-off-by: Lucas Stach 

Reviewed-by: Christian Gmeiner 

> ---
>  drivers/gpu/drm/etnaviv/etnaviv_buffer.c | 10 ++
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.c|  8 +---
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.h|  1 -
>  3 files changed, 7 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_buffer.c 
> b/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
> index 9e7098e3207f..6ad8972a59cc 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
> @@ -294,6 +294,7 @@ void etnaviv_buffer_queue(struct etnaviv_gpu *gpu, 
> unsigned int event,
> unsigned int waitlink_offset = buffer->user_size - 16;
> u32 return_target, return_dwords;
> u32 link_target, link_dwords;
> +   bool switch_context = gpu->exec_state != cmdbuf->exec_state;
>
> if (drm_debug & DRM_UT_DRIVER)
> etnaviv_buffer_dump(gpu, buffer, 0, 0x50);
> @@ -306,7 +307,7 @@ void etnaviv_buffer_queue(struct etnaviv_gpu *gpu, 
> unsigned int event,
>  * need to append a mmu flush load state, followed by a new
>  * link to this buffer - a total of four additional words.
>  */
> -   if (gpu->mmu->need_flush || gpu->switch_context) {
> +   if (gpu->mmu->need_flush || switch_context) {
> u32 target, extra_dwords;
>
> /* link command */
> @@ -321,7 +322,7 @@ void etnaviv_buffer_queue(struct etnaviv_gpu *gpu, 
> unsigned int event,
> }
>
> /* pipe switch commands */
> -   if (gpu->switch_context)
> +   if (switch_context)
> extra_dwords += 4;
>
> target = etnaviv_buffer_reserve(gpu, buffer, extra_dwords);
> @@ -349,10 +350,9 @@ void etnaviv_buffer_queue(struct etnaviv_gpu *gpu, 
> unsigned int event,
> gpu->mmu->need_flush = false;
> }
>
> -   if (gpu->switch_context) {
> +   if (switch_context) {
> etnaviv_cmd_select_pipe(gpu, buffer, 
> cmdbuf->exec_state);
> gpu->exec_state = cmdbuf->exec_state;
> -   gpu->switch_context = false;
> }
>
> /* And the link to the submitted buffer */
> @@ -421,4 +421,6 @@ void etnaviv_buffer_queue(struct etnaviv_gpu *gpu, 
> unsigned int event,
>
> if (drm_debug & DRM_UT_DRIVER)
> etnaviv_buffer_dump(gpu, buffer, 0, 0x50);
> +
> +   gpu->lastctx = cmdbuf->ctx;
>  }
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> index ae152bb78f18..65eaa8c10ba2 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> @@ -1416,12 +1416,6 @@ int etnaviv_gpu_submit(struct etnaviv_gpu *gpu,
> submit->fence = dma_fence_get(fence);
> gpu->active_fence = submit->fence->seqno;
>
> -   if (gpu->lastctx != cmdbuf->ctx) {
> -   gpu->mmu->need_flush = true;
> -   gpu->switch_context = true;
> -   gpu->lastctx = cmdbuf->ctx;
> -   }
> -
> if (cmdbuf->nr_pmrs) {
> gpu->event[event[1]].sync_point = 
> _point_perfmon_sample_pre;
> gpu->event[event[1]].cmdbuf = cmdbuf;
> @@ -1662,7 +1656,7 @@ static int etnaviv_gpu_hw_resume(struct etnaviv_gpu 
> *gpu)
> etnaviv_gpu_update_clock(gpu);
> etnaviv_gpu_hw_init(gpu);
>
> -   gpu->switch_context = true;
> +   gpu->lastctx = NULL;
> gpu->exec_state = -1;
>
> mutex_unlock(>lock);
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h 
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
> index 4f10f147297a..15090bb68f5a 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
> @@ -106,7 +106,6 @@ struct etnaviv_gpu {
> struct mutex lock;
> struct etnaviv_chip_identity identity;
> struct etnaviv_file_private *lastctx;
> -   bool switch_context;
>
> /* 'ring'-buffer: */
> struct etnaviv_cmdbuf *buffer;
> --
> 2.11.0
>
> ___
> etnaviv mailing list
> etna...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/etnaviv



-- 
greets
--
Christian Gmeiner, MSc

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

Re: [PATCH 08/27] drm/etnaviv: remove stale TODO in etnaviv_gpu_submit

[Christian Gmeiner]

2017-12-01 11:36 GMT+01:00 Lucas Stach :
> Flush and prefetch are properly handled in the buffer code, data endianess
> would need much wider changes than adding something to this single function.
>
> Signed-off-by: Lucas Stach 

Reviewed-by: Christian Gmeiner 

> ---
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 9 -
>  1 file changed, 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> index f0fae218e4aa..3dffccfcefce 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> @@ -1391,15 +1391,6 @@ int etnaviv_gpu_submit(struct etnaviv_gpu *gpu,
> return ret;
>
> /*
> -* TODO
> -*
> -* - flush
> -* - data endian
> -* - prefetch
> -*
> -*/
> -
> -   /*
>  * if there are performance monitor requests we need to have
>  * - a sync point to re-configure gpu and process ETNA_PM_PROCESS_PRE
>  *   requests.
> --
> 2.11.0
>



-- 
greets
--
Christian Gmeiner, MSc

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

Re: [PATCH 12/27] drm/etnaviv: hold GPU lock while inserting END command

[Christian Gmeiner]

2017-12-01 11:36 GMT+01:00 Lucas Stach :
> Inserting the END command when suspending the GPU is changing the
> command buffer state, which requires the GPU to be held.
>
> Signed-off-by: Lucas Stach 

Reviewed-by: Christian Gmeiner 

> ---
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> index 1e1e34adb07f..85f6ee1da016 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> @@ -1631,7 +1631,9 @@ static int etnaviv_gpu_hw_suspend(struct etnaviv_gpu 
> *gpu)
>  {
> if (gpu->buffer) {
> /* Replace the last WAIT with END */
> +   mutex_lock(>lock);
> etnaviv_buffer_end(gpu);
> +   mutex_unlock(>lock);
>
> /*
>  * We know that only the FE is busy here, this should
> --
> 2.11.0
>



-- 
greets
--
Christian Gmeiner, MSc

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

Re: [PATCH 05/27] drm/etnaviv: change return type of etnaviv_gem_obj_add to void

[Christian Gmeiner]

2017-12-01 11:36 GMT+01:00 Lucas Stach :
> This function never fails, as it does nothing more than adding the GEM
> object to the global device list. Making this explicit through the void
> return type allows to drop some unnecessary error handling.
>
> Signed-off-by: Lucas Stach 

Reviewed-by: Christian Gmeiner 

> ---
>  drivers/gpu/drm/etnaviv/etnaviv_gem.c   | 16 
>  drivers/gpu/drm/etnaviv/etnaviv_gem.h   |  2 +-
>  drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c |  4 +---
>  3 files changed, 6 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c 
> b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> index f75105b7e1a4..a5222045 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> @@ -586,7 +586,7 @@ void etnaviv_gem_free_object(struct drm_gem_object *obj)
> kfree(etnaviv_obj);
>  }
>
> -int etnaviv_gem_obj_add(struct drm_device *dev, struct drm_gem_object *obj)
> +void etnaviv_gem_obj_add(struct drm_device *dev, struct drm_gem_object *obj)
>  {
> struct etnaviv_drm_private *priv = dev->dev_private;
> struct etnaviv_gem_object *etnaviv_obj = to_etnaviv_bo(obj);
> @@ -594,8 +594,6 @@ int etnaviv_gem_obj_add(struct drm_device *dev, struct 
> drm_gem_object *obj)
> mutex_lock(>gem_lock);
> list_add_tail(_obj->gem_node, >gem_list);
> mutex_unlock(>gem_lock);
> -
> -   return 0;
>  }
>
>  static int etnaviv_gem_new_impl(struct drm_device *dev, u32 size, u32 flags,
> @@ -678,11 +676,7 @@ int etnaviv_gem_new_handle(struct drm_device *dev, 
> struct drm_file *file,
> if (ret)
> goto fail;
>
> -   ret = etnaviv_gem_obj_add(dev, obj);
> -   if (ret < 0) {
> -   drm_gem_object_put_unlocked(obj);
> -   return ret;
> -   }
> +   etnaviv_gem_obj_add(dev, obj);
>
> ret = drm_gem_handle_create(file, obj, handle);
>
> @@ -895,12 +889,10 @@ int etnaviv_gem_new_userptr(struct drm_device *dev, 
> struct drm_file *file,
> etnaviv_obj->userptr.ro = !(flags & ETNA_USERPTR_WRITE);
> get_task_struct(current);
>
> -   ret = etnaviv_gem_obj_add(dev, _obj->base);
> -   if (ret)
> -   goto unreference;
> +   etnaviv_gem_obj_add(dev, _obj->base);
>
> ret = drm_gem_handle_create(file, _obj->base, handle);
> -unreference:
> +
> /* drop reference from allocate - handle holds it now */
> drm_gem_object_put_unlocked(_obj->base);
> return ret;
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.h 
> b/drivers/gpu/drm/etnaviv/etnaviv_gem.h
> index e437fba1209d..00bd9c851a02 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gem.h
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.h
> @@ -117,7 +117,7 @@ int etnaviv_gem_wait_bo(struct etnaviv_gpu *gpu, struct 
> drm_gem_object *obj,
>  int etnaviv_gem_new_private(struct drm_device *dev, size_t size, u32 flags,
> struct reservation_object *robj, const struct etnaviv_gem_ops *ops,
> struct etnaviv_gem_object **res);
> -int etnaviv_gem_obj_add(struct drm_device *dev, struct drm_gem_object *obj);
> +void etnaviv_gem_obj_add(struct drm_device *dev, struct drm_gem_object *obj);
>  struct page **etnaviv_gem_get_pages(struct etnaviv_gem_object *obj);
>  void etnaviv_gem_put_pages(struct etnaviv_gem_object *obj);
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c 
> b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
> index ea87bf87b187..5704305d41e6 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
> @@ -142,9 +142,7 @@ struct drm_gem_object 
> *etnaviv_gem_prime_import_sg_table(struct drm_device *dev,
> if (ret)
> goto fail;
>
> -   ret = etnaviv_gem_obj_add(dev, _obj->base);
> -   if (ret)
> -   goto fail;
> +   etnaviv_gem_obj_add(dev, _obj->base);
>
> return _obj->base;
>
> --
> 2.11.0
>
> ___
> etnaviv mailing list
> etna...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/etnaviv



-- 
greets
--
Christian Gmeiner, MSc

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

[Bug 104192] [amdgpu][VEGA10] regular lockups with VM_L2_PROTECTION_FAULT_STATUS

[bugzilla-daemon]

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

--- Comment #9 from Michel Dänzer  ---
FWIW, I bisected some piglit regressions to LLVM SVN r319894.

-- 
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 03/27] drm/etnaviv: add lockdep annotation for userptr object population

[Christian Gmeiner]

2017-12-01 11:36 GMT+01:00 Lucas Stach :
> The current userptr page population will defer work to a work item if
> needed to avoid ever taking the mmap_sem in the direct call path. With
> the more fine-grained locking in etnaviv this isn't needed anymore, so
> a future commit will simplify this code.
>
> Add a lockdep annotation to validate the assumption that the mmap_sem
> can be taken in the direct call path.
>
> Signed-off-by: Lucas Stach 

Reviewed-by: Christian Gmeiner 

> ---
>  drivers/gpu/drm/etnaviv/etnaviv_gem.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c 
> b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> index e3582507963d..555a331c51a9 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> @@ -804,6 +804,8 @@ static int etnaviv_gem_userptr_get_pages(struct 
> etnaviv_gem_object *etnaviv_obj)
> struct mm_struct *mm;
> int ret, pinned, npages = etnaviv_obj->base.size >> PAGE_SHIFT;
>
> +   might_lock_read(>mm->mmap_sem);
> +
> if (etnaviv_obj->userptr.work) {
> if (IS_ERR(etnaviv_obj->userptr.work)) {
> ret = PTR_ERR(etnaviv_obj->userptr.work);
> --
> 2.11.0
>



-- 
greets
--
Christian Gmeiner, MSc

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

Re: [PATCH 04/27] drm/etnaviv: fold __etnaviv_gem_new into caller

[Christian Gmeiner]

2017-12-01 11:36 GMT+01:00 Lucas Stach :
> This function has only one caller and it isn't expected that there will
> be any more in the future. Folding this function into the caller is
> helping the readability.
>
> Signed-off-by: Lucas Stach 

Reviewed-by: Christian Gmeiner 

> ---
>  drivers/gpu/drm/etnaviv/etnaviv_gem.c | 26 +-
>  1 file changed, 5 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c 
> b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> index 555a331c51a9..f75105b7e1a4 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> @@ -643,8 +643,9 @@ static int etnaviv_gem_new_impl(struct drm_device *dev, 
> u32 size, u32 flags,
> return 0;
>  }
>
> -static struct drm_gem_object *__etnaviv_gem_new(struct drm_device *dev,
> -   u32 size, u32 flags)
> +/* convenience method to construct a GEM buffer object, and userspace handle 
> */
> +int etnaviv_gem_new_handle(struct drm_device *dev, struct drm_file *file,
> +   u32 size, u32 flags, u32 *handle)
>  {
> struct drm_gem_object *obj = NULL;
> int ret;
> @@ -665,7 +666,7 @@ static struct drm_gem_object *__etnaviv_gem_new(struct 
> drm_device *dev,
> /*
>  * Our buffers are kept pinned, so allocating them
>  * from the MOVABLE zone is a really bad idea, and
> -* conflicts with CMA.  See coments above new_inode()
> +* conflicts with CMA. See comments above new_inode()
>  * why this is required _and_ expected if you're
>  * going to pin these pages.
>  */
> @@ -677,24 +678,6 @@ static struct drm_gem_object *__etnaviv_gem_new(struct 
> drm_device *dev,
> if (ret)
> goto fail;
>
> -   return obj;
> -
> -fail:
> -   drm_gem_object_put_unlocked(obj);
> -   return ERR_PTR(ret);
> -}
> -
> -/* convenience method to construct a GEM buffer object, and userspace handle 
> */
> -int etnaviv_gem_new_handle(struct drm_device *dev, struct drm_file *file,
> -   u32 size, u32 flags, u32 *handle)
> -{
> -   struct drm_gem_object *obj;
> -   int ret;
> -
> -   obj = __etnaviv_gem_new(dev, size, flags);
> -   if (IS_ERR(obj))
> -   return PTR_ERR(obj);
> -
> ret = etnaviv_gem_obj_add(dev, obj);
> if (ret < 0) {
> drm_gem_object_put_unlocked(obj);
> @@ -704,6 +687,7 @@ int etnaviv_gem_new_handle(struct drm_device *dev, struct 
> drm_file *file,
> ret = drm_gem_handle_create(file, obj, handle);
>
> /* drop reference from allocate - handle holds it now */
> +fail:
> drm_gem_object_put_unlocked(obj);
>
> return ret;
> --
> 2.11.0
>



-- 
greets
--
Christian Gmeiner, MSc

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

[Bug 104159] llvm 6.0svn: firefox GPU fault/hang with r319975

[bugzilla-daemon]

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

--- Comment #3 from Michel Dänzer  ---
FWIW, I bisected some piglit regressions to LLVM SVN r319894.

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

[PATCH] drm: Give the DRM device's anon_inode a unique lockclass for its mmap_rswem

[Chris Wilson]

Teach lockdep to track the device's internal mmapping separately
from the generic lockclass over all other inodes. Since this is device
private we wish to allow a different locking hierarchy than is typified
by the requirement for the mmap_rwsem being the outermost lock for
handling pagefaults. By giving the internal mmap_rwsem a distinct
lockclass, lockdep can identify it and learn/enforce its distinct locking
requirements.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104209
Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/drm_drv.c | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 9acc1e157813..21ad06c3d684 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -393,6 +393,7 @@ static struct file_system_type drm_fs_type = {
 
 static struct inode *drm_fs_inode_new(void)
 {
+   static struct lock_class_key lockclass;
struct inode *inode;
int r;
 
@@ -403,8 +404,22 @@ static struct inode *drm_fs_inode_new(void)
}
 
inode = alloc_anon_inode(drm_fs_mnt->mnt_sb);
-   if (IS_ERR(inode))
+   if (IS_ERR(inode)) {
simple_release_fs(_fs_mnt, _fs_cnt);
+   return inode;
+   }
+
+   /*
+* Teach lockdep to track the device's internal mmapping separately
+* from all other inodes. Since this is device private we wish to
+* allow a different locking hierarchy than is typified by the
+* requirement for the mmap_rwsem being the outermost lock for
+* handling pagefaults. By giving the internal mmap_rwsem a distinct
+* lockclass, lockdep can identify it and thereby learn and enforce its
+* distinct locking requirements.
+*/
+   lockdep_set_class_and_name(>i_mapping->i_mmap_rwsem,
+  , "drm_fs_inode");
 
return inode;
 }
-- 
2.15.1

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

[Bug 104159] llvm 6.0svn: firefox GPU fault/hang with r319975

[bugzilla-daemon]

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

Christoph Haag  changed:

   What|Removed |Added

Summary|llvm 6.0svn: GPU fault/hang |llvm 6.0svn: firefox GPU
   |with r319975|fault/hang with r319975

--- Comment #2 from Christoph Haag  ---
Vega broke around the same time.
https://bugs.freedesktop.org/show_bug.cgi?id=104192
"llvm-svn revision 320250 gives me the freezes meanwhile, 317901 doesnt."

It could be a different bug though.

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

Re: [Intel-gfx] linux-next: Signed-off-by missing for commit in the drm-intel-fixes tree

[Joonas Lahtinen]

+ GVT folks.

On Fri, 2017-12-08 at 09:15 +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Commit
> 
>   365ad5df9caa ("drm/i915/gvt: Export
> intel_gvt_render_mmio_to_ring_id()")
> 
> is missing a Signed-off-by from its committer.
> 
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104159] llvm 6.0svn: GPU fault/hang with r319975

[bugzilla-daemon]

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

--- Comment #1 from Lorenzo Bona  ---
I can confirm this bug on svn320332 too.

I'm using vanilla kernel.

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

[PATCH 21/25] drm/armada: wait for previous work when moving overlay window

[Russell King]

We must wait for the previous plane work to complete before moving
the overlay window, as it could overwrite our positioning update.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/armada/armada_overlay.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_overlay.c 
b/drivers/gpu/drm/armada/armada_overlay.c
index e5fa346f572b..853f889e84f5 100644
--- a/drivers/gpu/drm/armada/armada_overlay.c
+++ b/drivers/gpu/drm/armada/armada_overlay.c
@@ -239,16 +239,16 @@ armada_ovl_plane_update(struct drm_plane *plane, struct 
drm_crtc *crtc,
if (!dplane->base.state.changed)
return 0;
 
+   /* Wait for pending work to complete */
+   if (armada_drm_plane_work_wait(>base, HZ / 25) == 0)
+   armada_drm_plane_work_cancel(dcrtc, >base);
+
/* Just updating the position/size? */
if (!dplane->base.state.vsync_update) {
armada_ovl_plane_work(dcrtc, work);
return 0;
}
 
-   /* Wait for pending work to complete */
-   if (armada_drm_plane_work_wait(>base, HZ / 25) == 0)
-   armada_drm_plane_work_cancel(dcrtc, >base);
-
if (!dcrtc->plane) {
dcrtc->plane = plane;
armada_ovl_update_attr(>prop, dcrtc);
-- 
2.7.4

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

Re: [PATCH] drm/nouveau/imem/nv50: fix incorrect use of refcount API

[Adam Borowski]

On Fri, Dec 08, 2017 at 06:30:34PM +, Ard Biesheuvel wrote:
> Commit be55287aa5b ("drm/nouveau/imem/nv50: embed nvkm_instobj directly
> into nv04_instobj") introduced some new calls to the refcount api to
> the nv50 mapping code. In one particular instance, it does the
> following:
> 
> if (!refcount_inc_not_zero(>maps)) {
> ...
> refcount_inc(>maps);
> }
> 
> i.e., it calls refcount_inc() to increment the refcount when it is known
> to be zero, which is explicitly forbidden by the API. Instead, use
> refcount_set() to set it to 1.
> 
> Signed-off-by: Ard Biesheuvel 
> ---

Awesome!  Works for me.

> Apologies if this was already found and fixed. I don't usually follow
> the DRM or nouveau mailing lists.

I see nothing relevant in dri-devel and nouveau archives, except my
complaint (GTX 560 Ti (GF114)):
https://lists.freedesktop.org/archives/nouveau/2017-December/029264.html
and Richard Narron seconding it (MSI GeForce 210):
https://lists.freedesktop.org/archives/nouveau/2017-December/029276.html

>  drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.c 
> b/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.c
> index 1ba7289684aa..db48a1daca0c 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.c
> @@ -249,7 +249,7 @@ nv50_instobj_acquire(struct nvkm_memory *memory)
>   iobj->base.memory.ptrs = _instobj_fast;
>   else
>   iobj->base.memory.ptrs = _instobj_slow;
> - refcount_inc(>maps);
> + refcount_set(>maps, 1);
>   }
>  
>   mutex_unlock(>subdev.mutex);
> -- 

I'm just a dumb user here, my tags don't carry a weight, but Tested-by:.


Meow!
-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable And Non-Discriminatory prices.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 13/25] drm/armada: move writes of LCD_SPU_SRAM_PARA1 under lock

[Russell King]

Move writes of LCD_SPU_SRAM_PARA1 under the irq lock, so that we can
add this to the frame updates at interrupt time when disabling a
plane.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/armada/armada_crtc.c| 10 ++
 drivers/gpu/drm/armada/armada_overlay.c |  5 +++--
 2 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
b/drivers/gpu/drm/armada/armada_crtc.c
index 02eefdc6f062..b0091142a79f 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -657,8 +657,6 @@ static int armada_drm_crtc_mode_set(struct drm_crtc *crtc,
/* Now compute the divider for real */
dcrtc->variant->compute_clock(dcrtc, adj, );
 
-   /* Ensure graphic fifo is enabled */
-   armada_reg_queue_mod(regs, i, 0, CFG_PDWN64x66, LCD_SPU_SRAM_PARA1);
armada_reg_queue_set(regs, i, sclk, LCD_CFG_SCLK_DIV);
 
if (interlaced ^ dcrtc->interlaced) {
@@ -671,6 +669,9 @@ static int armada_drm_crtc_mode_set(struct drm_crtc *crtc,
 
spin_lock_irqsave(>irq_lock, flags);
 
+   /* Ensure graphic fifo is enabled */
+   armada_reg_queue_mod(regs, i, 0, CFG_PDWN64x66, LCD_SPU_SRAM_PARA1);
+
/* Even interlaced/progressive frame */
dcrtc->v[1].spu_v_h_total = adj->crtc_vtotal << 16 |
adj->crtc_htotal;
@@ -869,9 +870,11 @@ static int armada_drm_crtc_cursor_update(struct 
armada_crtc *dcrtc, bool reload)
return 0;
}
 
+   spin_lock_irq(>irq_lock);
para1 = readl_relaxed(dcrtc->base + LCD_SPU_SRAM_PARA1);
armada_updatel(CFG_CSB_256x32, CFG_CSB_256x32 | CFG_PDWN256x32,
   dcrtc->base + LCD_SPU_SRAM_PARA1);
+   spin_unlock_irq(>irq_lock);
 
/*
 * Initialize the transparency if the SRAM was powered down.
@@ -1157,9 +1160,8 @@ int armada_drm_plane_disable(struct drm_plane *plane,
 
spin_lock_irq(>irq_lock);
armada_updatel(0, enable_mask, dcrtc->base + LCD_SPU_DMA_CTRL0);
-   spin_unlock_irq(>irq_lock);
-
armada_updatel(sram_para1, 0, dcrtc->base + LCD_SPU_SRAM_PARA1);
+   spin_unlock_irq(>irq_lock);
 
return 0;
 }
diff --git a/drivers/gpu/drm/armada/armada_overlay.c 
b/drivers/gpu/drm/armada/armada_overlay.c
index 200223861bfb..e02d0d9d4c23 100644
--- a/drivers/gpu/drm/armada/armada_overlay.c
+++ b/drivers/gpu/drm/armada/armada_overlay.c
@@ -162,8 +162,9 @@ armada_ovl_plane_update(struct drm_plane *plane, struct 
drm_crtc *crtc,
return 0;
} else if (~dplane->base.state.ctrl0 & ctrl0 & CFG_DMA_ENA) {
/* Power up the Y/U/V FIFOs on ENA 0->1 transitions */
-   armada_updatel(0, CFG_PDWN16x66 | CFG_PDWN32x66,
-  dcrtc->base + LCD_SPU_SRAM_PARA1);
+   armada_reg_queue_mod(work->regs, idx,
+0, CFG_PDWN16x66 | CFG_PDWN32x66,
+LCD_SPU_SRAM_PARA1);
}
 
if (armada_drm_plane_work_wait(>base, HZ / 25) == 0)
-- 
2.7.4

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

[PATCH 2/5] drm/armada: fix SRAM powerdown

[Russell King]

Avoid powering down the overlay SRAM banks when disabling the primary
plane, thereby masking any overlay video.  This feature is supposed to
allow us to cut the bandwidth required while displaying full-frame
overlay video.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/armada/armada_crtc.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
b/drivers/gpu/drm/armada/armada_crtc.c
index 79ce877bf45f..77fc038cbfae 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -744,15 +744,14 @@ void armada_drm_crtc_plane_disable(struct armada_crtc 
*dcrtc,
if (plane->fb)
drm_framebuffer_put(plane->fb);
 
-   /* Power down the Y/U/V FIFOs */
-   sram_para1 = CFG_PDWN16x66 | CFG_PDWN32x66;
-
/* Power down most RAMs and FIFOs if this is the primary plane */
if (plane->type == DRM_PLANE_TYPE_PRIMARY) {
-   sram_para1 |= CFG_PDWN256x32 | CFG_PDWN256x24 | CFG_PDWN256x8 |
- CFG_PDWN32x32 | CFG_PDWN64x66;
+   sram_para1 = CFG_PDWN256x32 | CFG_PDWN256x24 | CFG_PDWN256x8 |
+CFG_PDWN32x32 | CFG_PDWN64x66;
dma_ctrl0_mask = CFG_GRA_ENA;
} else {
+   /* Power down the Y/U/V FIFOs */
+   sram_para1 = CFG_PDWN16x66 | CFG_PDWN32x66;
dma_ctrl0_mask = CFG_DMA_ENA;
}
 
-- 
2.7.4

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

Re: [PATCHv1 00/14] omapdrm: DSI command mode panel support

[Sebastian Reichel]

Hi Tomi,

On Fri, Dec 01, 2017 at 02:58:13PM +0200, Tomi Valkeinen wrote:
> Hi,
> 
> On 24/07/17 20:32, Sebastian Reichel wrote:
> > Hi,
> > 
> > This adds support for command mode DSI panels to
> > omapdrm. I tested the patches on Nokia N950 (omap3)
> > and Motorola Droid 4 (omap4). This is basically
> > PATCHv3 of my series adding N950 display support,
> > but I started from scratch without reverting the
> > removal of manual display update support.
> > 
> > Tested:
> >  * Framebuffer Console
> >  * Display blanking
> >  * kmstest
> >  * Xorg with omap and modesetting driver
> >  * No updates send when nothing needs to be sent
> > 
> > Known issues:
> >  * Proper display rotation support
> >  * N950 (and N9) has first and last few lines
> >covered by plastic, so we should expose a
> >smaller screen
> > 
> > I plan to look into these issues once basic support
> > has been merged.
> > 
> > -- Sebastian
> > 
> > Sebastian Reichel (13):
> >   [A] drm/omap: remove unused function defines
> >   [A] drm/omap: drop incorrect comment
> >   [ ] drm/omap: plane: update fifo size on ovl setup
> >   [ ] drm/omap: add framedone interrupt support
> >   [ ] drm/omap: add manual update detection helper
> >   [ ] drm/omap: add support for manually updated displays
> >   [A] drm/omap: add support for physical size hints from display drivers
> >   [A] drm/omap: panel-dsi-cm: add regulator support
> >   [A] drm/omap: panel-dsi-cm: add physical size support
> >   [A] drm/omap: panel-dsi-cm: add external backlight support
> >   [A] drm/omap: panel-dsi-cm: switch to gpiod
> >   [A] ARM: dts: omap4-droid4: improve LCD description
> >   [ ] ARM: dts: n950: add display support
> > 
> > Tony Lindgren (1):
> >   drm/omap: panel-dsi-cm: fix driver
> 
> I've also picked patches 7-12.

Thanks. I just wanted to rebase the remaining patches on your
branch, but I don't see those patches in linux-next and your tree
does not seem to be updated properly either:

https://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git/

-- Sebastian


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

[PATCH 19/25] drm/armada: re-organise overlay register update generation

[Russell King]

Re-organise overlay register generation so that we do not have to wait
for the previous update to complete while creating the new state.  This
allows the update to be fully prepared before queueing it for the next
interrupt.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/armada/armada_overlay.c | 52 ++---
 1 file changed, 22 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_overlay.c 
b/drivers/gpu/drm/armada/armada_overlay.c
index 0fe3f2db8ff5..00da2c58701c 100644
--- a/drivers/gpu/drm/armada/armada_overlay.c
+++ b/drivers/gpu/drm/armada/armada_overlay.c
@@ -136,43 +136,18 @@ armada_ovl_plane_update(struct drm_plane *plane, struct 
drm_crtc *crtc,
if (format->num_planes == 1 && state.src.x1 >> 16 & (format->hsub - 1))
ctrl0 ^= CFG_DMA_MOD(CFG_SWAPUV);
 
-   fb_changed = plane->fb != fb ||
-dplane->base.state.src_x != state.src.x1 >> 16 ||
-dplane->base.state.src_y != state.src.y1 >> 16;
-
-   /* FIXME: overlay on an interlaced display */
-   /* Just updating the position/size? */
-   if (!fb_changed && dplane->base.state.ctrl0 == ctrl0) {
-   val = (drm_rect_height() & 0x) |
-  drm_rect_width() >> 16;
-   dplane->base.state.src_hw = val;
-   writel_relaxed(val, dcrtc->base + LCD_SPU_DMA_HPXL_VLN);
-
-   val = drm_rect_height() << 16 |
- drm_rect_width();
-   dplane->base.state.dst_hw = val;
-   writel_relaxed(val, dcrtc->base + LCD_SPU_DZM_HPXL_VLN);
-
-   val = state.dst.y1 << 16 | state.dst.x1;
-   dplane->base.state.dst_yx = val;
-   writel_relaxed(val, dcrtc->base + LCD_SPU_DMA_OVSA_HPXL_VLN);
-
-   return 0;
-   } else if (~dplane->base.state.ctrl0 & ctrl0 & CFG_DMA_ENA) {
+   if (~dplane->base.state.ctrl0 & ctrl0 & CFG_DMA_ENA) {
/* Power up the Y/U/V FIFOs on ENA 0->1 transitions */
armada_reg_queue_mod(work->regs, idx,
 0, CFG_PDWN16x66 | CFG_PDWN32x66,
 LCD_SPU_SRAM_PARA1);
}
 
-   if (armada_drm_plane_work_wait(>base, HZ / 25) == 0)
-   armada_drm_plane_work_cancel(dcrtc, >base);
-
-   if (!dcrtc->plane) {
-   dcrtc->plane = plane;
-   armada_ovl_update_attr(>prop, dcrtc);
-   }
+   fb_changed = plane->fb != fb ||
+dplane->base.state.src_x != state.src.x1 >> 16 ||
+dplane->base.state.src_y != state.src.y1 >> 16;
 
+   /* FIXME: overlay on an interlaced display */
if (fb_changed) {
u32 addrs[3];
 
@@ -243,6 +218,23 @@ armada_ovl_plane_update(struct drm_plane *plane, struct 
drm_crtc *crtc,
CFG_YUV2RGB) | CFG_DMA_ENA,
LCD_SPU_DMA_CTRL0);
}
+
+   /* Just updating the position/size? */
+   if (!fb_changed && dplane->base.state.ctrl0 == ctrl0) {
+   armada_reg_queue_end(work->regs, idx);
+   armada_ovl_plane_work(dcrtc, work);
+   return 0;
+   }
+
+   /* Wait for pending work to complete */
+   if (armada_drm_plane_work_wait(>base, HZ / 25) == 0)
+   armada_drm_plane_work_cancel(dcrtc, >base);
+
+   if (!dcrtc->plane) {
+   dcrtc->plane = plane;
+   armada_ovl_update_attr(>prop, dcrtc);
+   }
+
if (idx) {
armada_reg_queue_end(work->regs, idx);
/* Queue it for update on the next interrupt if we are enabled 
*/
-- 
2.7.4

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

drm: vc4: WARNING: CPU: 2 PID: 172 at kernel/irq/chip.c:244 __irq_startup+0x9c/0xa8

[Stefan Wahren]

Hi,

the commit 253696ccd613 ("drm/vc4: Account for interrupts in flight") triggers 
a warning during boot of Raspberry Pi 2 with multi_v7_defconfig:

[7.962699] vc4_hdmi 3f902000.hdmi: vc4-hdmi-hifi <-> 3f902000.hdmi mapping 
ok
[7.962732] vc4_hdmi 3f902000.hdmi: ASoC: no DMI vendor name!
[7.973355] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops [vc4])
[7.973651] vc4-drm soc:gpu: bound 3f806000.vec (ops vc4_vec_ops [vc4])
[7.973788] vc4-drm soc:gpu: bound 3f40.hvs (ops vc4_hvs_ops [vc4])
[7.974157] vc4-drm soc:gpu: bound 3f206000.pixelvalve (ops vc4_crtc_ops 
[vc4])
[7.974464] vc4-drm soc:gpu: bound 3f207000.pixelvalve (ops vc4_crtc_ops 
[vc4])
[7.974746] vc4-drm soc:gpu: bound 3f807000.pixelvalve (ops vc4_crtc_ops 
[vc4])
[8.018820] [ cut here ]
[8.018861] WARNING: CPU: 2 PID: 172 at kernel/irq/chip.c:244 
__irq_startup+0x9c/0xa8
[8.018868] Modules linked in: vc4(+) snd_soc_core ac97_bus 
snd_pcm_dmaengine snd_pcm snd_timer snd soundcore cec
[8.018911] CPU: 2 PID: 172 Comm: systemd-udevd Not tainted 
4.15.0-rc1-00291-g75f64f6 #10
[8.018914] Hardware name: BCM2835
[8.018950] [] (unwind_backtrace) from [] 
(show_stack+0x10/0x14)
[8.018970] [] (show_stack) from [] 
(dump_stack+0x88/0xa4)
[8.018993] [] (dump_stack) from [] (__warn+0xe4/0x110)
[8.019012] [] (__warn) from [] 
(warn_slowpath_null+0x3c/0x48)
[8.019029] [] (warn_slowpath_null) from [] 
(__irq_startup+0x9c/0xa8)
[8.019045] [] (__irq_startup) from [] 
(irq_startup+0x44/0x134)
[8.019061] [] (irq_startup) from [] 
(enable_irq+0x34/0x6c)
[8.019210] [] (enable_irq) from [] 
(vc4_irq_postinstall+0x14/0x34 [vc4])
[8.019338] [] (vc4_irq_postinstall [vc4]) from [] 
(drm_irq_install+0xc0/0x134)
[8.019456] [] (drm_irq_install) from [] 
(vc4_v3d_bind+0x12c/0x238 [vc4])
[8.019550] [] (vc4_v3d_bind [vc4]) from [] 
(component_bind_all+0xe8/0x21c)
[8.019635] [] (component_bind_all) from [] 
(vc4_drm_bind+0x78/0x130 [vc4])
[8.019721] [] (vc4_drm_bind [vc4]) from [] 
(try_to_bring_up_master+0x13c/0x184)
[8.019739] [] (try_to_bring_up_master) from [] 
(component_master_add_with_match+0x80/0xb8)
[8.019822] [] (component_master_add_with_match) from [] 
(vc4_platform_drm_probe+0x90/0xa8 [vc4])
[8.019905] [] (vc4_platform_drm_probe [vc4]) from [] 
(platform_drv_probe+0x4c/0xac)
[8.019924] [] (platform_drv_probe) from [] 
(driver_probe_device+0x234/0x338)
[8.019939] [] (driver_probe_device) from [] 
(__driver_attach+0xac/0xb0)
[8.019953] [] (__driver_attach) from [] 
(bus_for_each_dev+0x64/0x94)
[8.019967] [] (bus_for_each_dev) from [] 
(bus_add_driver+0x184/0x20c)
[8.019981] [] (bus_add_driver) from [] 
(driver_register+0x78/0xf8)
[8.019997] [] (driver_register) from [] 
(do_one_initcall+0x3c/0x16c)
[8.020018] [] (do_one_initcall) from [] 
(do_init_module+0x5c/0x1f0)
[8.020037] [] (do_init_module) from [] 
(load_module+0x1ba4/0x2248)
[8.020058] [] (load_module) from [] 
(SyS_finit_module+0x8c/0x9c)
[8.020076] [] (SyS_finit_module) from [] 
(__sys_trace_return+0x0/0x10)
[8.020085] ---[ end trace d5c350f831cb07d2 ]---
[8.020201] vc4-drm soc:gpu: bound 3fc0.v3d (ops vc4_v3d_ops [vc4])
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 09/25] drm/armada: move overlay plane work out from under spinlock

[Russell King]

Move the overlay plane work out from under the spinlock so that both the
primary and overlay planes run their work in the same context.  This is
necessary so that we can use frame works with the overlay plane.

However, we must update the CRTC registers under the spinlock, so fix up
the overlay code for that.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/armada/armada_crtc.c| 2 +-
 drivers/gpu/drm/armada/armada_overlay.c | 4 
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
b/drivers/gpu/drm/armada/armada_crtc.c
index bedcaed81ffa..be3fd82ef516 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -471,11 +471,11 @@ static void armada_drm_crtc_irq(struct armada_crtc 
*dcrtc, u32 stat)
if (stat & VSYNC_IRQ)
drm_crtc_handle_vblank(>crtc);
 
-   spin_lock(>irq_lock);
ovl_plane = dcrtc->plane;
if (ovl_plane)
armada_drm_plane_work_run(dcrtc, ovl_plane);
 
+   spin_lock(>irq_lock);
if (stat & GRA_FRAME_IRQ && dcrtc->interlaced) {
int i = stat & GRA_FRAME_IRQ0 ? 0 : 1;
uint32_t val;
diff --git a/drivers/gpu/drm/armada/armada_overlay.c 
b/drivers/gpu/drm/armada/armada_overlay.c
index 995463cd542d..04746ade74e6 100644
--- a/drivers/gpu/drm/armada/armada_overlay.c
+++ b/drivers/gpu/drm/armada/armada_overlay.c
@@ -84,10 +84,14 @@ static void armada_ovl_plane_work(struct armada_crtc *dcrtc,
 {
struct armada_ovl_plane *dplane = container_of(work->plane,
struct armada_ovl_plane, base.base);
+   unsigned long flags;
 
trace_armada_ovl_plane_work(>crtc, work->plane);
 
+   spin_lock_irqsave(>irq_lock, flags);
armada_drm_crtc_update_regs(dcrtc, dplane->vbl.regs);
+   spin_unlock_irqrestore(>irq_lock, flags);
+
armada_ovl_retire_fb(dplane, NULL);
 }
 
-- 
2.7.4

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

[PATCH 25/25] drm/armada: add iturbt_709 plane property to control YUV colorspace

[Russell King]

Add the defacto-standard "iturbt_709" property to the overlay plane to
control the YUV to RGB colorspace conversion.  This is mutually
exclusive with the CSC_YUV CRTC property - the last property to be set
determines the resulting colorspace conversion.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/armada/armada_crtc.c| 26 +++---
 drivers/gpu/drm/armada/armada_crtc.h|  2 ++
 drivers/gpu/drm/armada/armada_drm.h |  1 +
 drivers/gpu/drm/armada/armada_overlay.c | 25 ++---
 4 files changed, 48 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
b/drivers/gpu/drm/armada/armada_crtc.c
index 8b66377a4890..1bf632bb8855 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -535,12 +535,30 @@ static irqreturn_t armada_drm_irq(int irq, void *arg)
return IRQ_NONE;
 }
 
+void armada_drm_crtc_set_yuv_colorimetry(struct armada_crtc *dcrtc, u32 csc)
+{
+   armada_updatel(csc, CFG_CSC_YUV_CCIR709,
+  dcrtc->base + LCD_SPU_IOPAD_CONTROL);
+
+   dcrtc->csc_yuv_ovl_mode = csc == CFG_CSC_YUV_CCIR709 ?
+   CSC_YUV_CCIR709 : CSC_YUV_CCIR601;
+}
+
 static uint32_t armada_drm_crtc_calculate_csc(struct armada_crtc *dcrtc)
 {
struct drm_display_mode *adj = >crtc.mode;
-   uint32_t val = 0;
+   u32 val = 0;
+   u8 csc_yuv_mode;
+
+   /*
+* If the iturbt_709 overlay plane property is used, it overrides
+* the CSC_YUV crtc property until the CSC_YUV property is set.
+*/
+   csc_yuv_mode = dcrtc->csc_yuv_ovl_mode;
+   if (csc_yuv_mode == CSC_AUTO)
+   csc_yuv_mode = dcrtc->csc_yuv_mode;
 
-   if (dcrtc->csc_yuv_mode == CSC_YUV_CCIR709)
+   if (csc_yuv_mode == CSC_YUV_CCIR709)
val |= CFG_CSC_YUV_CCIR709;
if (dcrtc->csc_rgb_mode == CSC_RGB_STUDIO)
val |= CFG_CSC_RGB_STUDIO;
@@ -555,7 +573,7 @@ static uint32_t armada_drm_crtc_calculate_csc(struct 
armada_crtc *dcrtc)
if ((adj->hdisplay == 1280 && adj->vdisplay == 720 &&
 !(adj->flags & DRM_MODE_FLAG_INTERLACE)) ||
(adj->hdisplay == 1920 && adj->vdisplay == 1080)) {
-   if (dcrtc->csc_yuv_mode == CSC_AUTO)
+   if (csc_yuv_mode == CSC_AUTO)
val |= CFG_CSC_YUV_CCIR709;
}
 
@@ -1094,6 +1112,7 @@ armada_drm_crtc_set_property(struct drm_crtc *crtc,
 
if (property == priv->csc_yuv_prop) {
dcrtc->csc_yuv_mode = val;
+   dcrtc->csc_yuv_ovl_mode = CSC_AUTO;
update_csc = true;
} else if (property == priv->csc_rgb_prop) {
dcrtc->csc_rgb_mode = val;
@@ -1396,6 +1415,7 @@ static int armada_drm_crtc_create(struct drm_device *drm, 
struct device *dev,
dcrtc->num = drm->mode_config.num_crtc;
dcrtc->clk = ERR_PTR(-EINVAL);
dcrtc->csc_yuv_mode = CSC_AUTO;
+   dcrtc->csc_yuv_ovl_mode = CSC_AUTO;
dcrtc->csc_rgb_mode = CSC_AUTO;
dcrtc->cfg_dumb_ctrl = DUMB24_RGB888_0;
dcrtc->spu_iopad_ctrl = CFG_VSCALE_LN_EN | CFG_IOPAD_DUMB24;
diff --git a/drivers/gpu/drm/armada/armada_crtc.h 
b/drivers/gpu/drm/armada/armada_crtc.h
index 445829b8877a..5d70b4af20b7 100644
--- a/drivers/gpu/drm/armada/armada_crtc.h
+++ b/drivers/gpu/drm/armada/armada_crtc.h
@@ -90,6 +90,7 @@ struct armada_crtc {
boolinterlaced;
boolcursor_update;
uint8_t csc_yuv_mode;
+   uint8_t csc_yuv_ovl_mode;
uint8_t csc_rgb_mode;
 
struct drm_plane*plane;
@@ -113,6 +114,7 @@ struct armada_crtc {
 #define drm_to_armada_crtc(c) container_of(c, struct armada_crtc, crtc)
 
 void armada_drm_crtc_update_regs(struct armada_crtc *, struct armada_regs *);
+void armada_drm_crtc_set_yuv_colorimetry(struct armada_crtc *dcrtc, u32 csc);
 
 int armada_drm_plane_disable(struct drm_plane *plane,
 struct drm_modeset_acquire_ctx *ctx);
diff --git a/drivers/gpu/drm/armada/armada_drm.h 
b/drivers/gpu/drm/armada/armada_drm.h
index b064879ecdbd..45d5168d5748 100644
--- a/drivers/gpu/drm/armada/armada_drm.h
+++ b/drivers/gpu/drm/armada/armada_drm.h
@@ -60,6 +60,7 @@ struct armada_private {
struct armada_crtc  *dcrtc[2];
struct drm_mm   linear; /* protected by linear_lock */
struct mutexlinear_lock;
+   struct drm_property *iturbt709_prop;
struct drm_property *csc_yuv_prop;
struct drm_property *csc_rgb_prop;
struct drm_property *colorkey_prop;
diff --git a/drivers/gpu/drm/armada/armada_overlay.c 
b/drivers/gpu/drm/armada/armada_overlay.c
index 853f889e84f5..d7a9c79f0ada 100644
--- a/drivers/gpu/drm/armada/armada_overlay.c
+++ b/drivers/gpu/drm/armada/armada_overlay.c
@@ -28,6 +28,8 

[PATCH 07/25] drm/armada: clean up armada_drm_crtc_plane_disable()

[Russell King]

Merge armada_drm_primary_disable() into armada_drm_crtc_plane_disable()
and rename to armada_drm_plane_disable().  Use this to simplify
armada_ovl_plane_disable().

Signed-off-by: Russell King 
---
 drivers/gpu/drm/armada/armada_crtc.c| 21 +
 drivers/gpu/drm/armada/armada_crtc.h|  4 ++--
 drivers/gpu/drm/armada/armada_overlay.c |  9 +++--
 3 files changed, 14 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
b/drivers/gpu/drm/armada/armada_crtc.c
index 7f7f21166488..3287b72e48cc 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -1123,12 +1123,16 @@ static const struct drm_crtc_funcs armada_crtc_funcs = {
.disable_vblank = armada_drm_crtc_disable_vblank,
 };
 
-void armada_drm_crtc_plane_disable(struct armada_crtc *dcrtc,
-   struct drm_plane *plane)
+int armada_drm_plane_disable(struct drm_plane *plane,
+struct drm_modeset_acquire_ctx *ctx)
 {
struct armada_plane *dplane = drm_to_armada_plane(plane);
+   struct armada_crtc *dcrtc;
u32 sram_para1, dma_ctrl0_mask;
 
+   if (!plane->crtc)
+   return 0;
+
/*
 * Drop our reference on any framebuffer attached to this plane.
 * We don't need to NULL this out as drm_plane_force_disable(),
@@ -1150,6 +1154,8 @@ void armada_drm_crtc_plane_disable(struct armada_crtc 
*dcrtc,
dma_ctrl0_mask = CFG_DMA_ENA;
}
 
+   dcrtc = drm_to_armada_crtc(plane->crtc);
+
/* Wait for any preceding work to complete, but don't wedge */
if (WARN_ON(!armada_drm_plane_work_wait(dplane, HZ)))
armada_drm_plane_work_cancel(dcrtc, dplane);
@@ -1159,22 +1165,13 @@ void armada_drm_crtc_plane_disable(struct armada_crtc 
*dcrtc,
spin_unlock_irq(>irq_lock);
 
armada_updatel(sram_para1, 0, dcrtc->base + LCD_SPU_SRAM_PARA1);
-}
-
-static int armada_drm_primary_disable(struct drm_plane *plane,
- struct drm_modeset_acquire_ctx *ctx)
-{
-   if (plane->crtc) {
-   struct armada_crtc *dcrtc = drm_to_armada_crtc(plane->crtc);
 
-   armada_drm_crtc_plane_disable(dcrtc, plane);
-   }
return 0;
 }
 
 static const struct drm_plane_funcs armada_primary_plane_funcs = {
.update_plane   = drm_primary_helper_update,
-   .disable_plane  = armada_drm_primary_disable,
+   .disable_plane  = armada_drm_plane_disable,
.destroy= drm_primary_helper_destroy,
 };
 
diff --git a/drivers/gpu/drm/armada/armada_crtc.h 
b/drivers/gpu/drm/armada/armada_crtc.h
index c26814c2ce08..521ae5b6ad86 100644
--- a/drivers/gpu/drm/armada/armada_crtc.h
+++ b/drivers/gpu/drm/armada/armada_crtc.h
@@ -106,8 +106,8 @@ struct armada_crtc {
 
 void armada_drm_crtc_update_regs(struct armada_crtc *, struct armada_regs *);
 
-void armada_drm_crtc_plane_disable(struct armada_crtc *dcrtc,
-   struct drm_plane *plane);
+int armada_drm_plane_disable(struct drm_plane *plane,
+struct drm_modeset_acquire_ctx *ctx);
 
 extern struct platform_driver armada_lcd_platform_driver;
 
diff --git a/drivers/gpu/drm/armada/armada_overlay.c 
b/drivers/gpu/drm/armada/armada_overlay.c
index cf8442583bfc..a53e7dd26b0b 100644
--- a/drivers/gpu/drm/armada/armada_overlay.c
+++ b/drivers/gpu/drm/armada/armada_overlay.c
@@ -264,15 +264,12 @@ static int armada_ovl_plane_disable(struct drm_plane 
*plane,
 {
struct armada_ovl_plane *dplane = drm_to_armada_ovl_plane(plane);
struct drm_framebuffer *fb;
-   struct armada_crtc *dcrtc;
 
-   if (!dplane->base.base.crtc)
-   return 0;
+   armada_drm_plane_disable(plane, ctx);
 
-   dcrtc = drm_to_armada_crtc(dplane->base.base.crtc);
-   armada_drm_crtc_plane_disable(dcrtc, plane);
+   if (dplane->base.base.crtc)
+   drm_to_armada_crtc(dplane->base.base.crtc)->plane = NULL;
 
-   dcrtc->plane = NULL;
dplane->base.state.ctrl0 = 0;
 
fb = xchg(>old_fb, NULL);
-- 
2.7.4

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

[PATCH 24/25] drm/armada: expand overlay trace entry

[Russell King]

Add CRTC and source positions to the Armada overlay trace entry.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/armada/armada_trace.h | 24 ++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_trace.h 
b/drivers/gpu/drm/armada/armada_trace.h
index 8dbfea7a00fe..f03a56bda596 100644
--- a/drivers/gpu/drm/armada/armada_trace.h
+++ b/drivers/gpu/drm/armada/armada_trace.h
@@ -34,14 +34,34 @@ TRACE_EVENT(armada_ovl_plane_update,
__field(struct drm_plane *, plane)
__field(struct drm_crtc *, crtc)
__field(struct drm_framebuffer *, fb)
+   __field(int, crtc_x)
+   __field(int, crtc_y)
+   __field(unsigned int, crtc_w)
+   __field(unsigned int, crtc_h)
+   __field(u32, src_x)
+   __field(u32, src_y)
+   __field(u32, src_w)
+   __field(u32, src_h)
),
TP_fast_assign(
__entry->plane = plane;
__entry->crtc = crtc;
__entry->fb = fb;
+   __entry->crtc_x = crtc_x;
+   __entry->crtc_y = crtc_y;
+   __entry->crtc_w = crtc_w;
+   __entry->crtc_h = crtc_h;
+   __entry->src_x = src_x;
+   __entry->src_y = src_y;
+   __entry->src_w = src_w;
+   __entry->src_h = src_h;
),
-   TP_printk("plane %p crtc %p fb %p",
-   __entry->plane, __entry->crtc, __entry->fb)
+   TP_printk("plane %p crtc %p fb %p crtc @ (%d,%d, %ux%u) src @ (%u,%u, 
%ux%u)",
+   __entry->plane, __entry->crtc, __entry->fb,
+   __entry->crtc_x, __entry->crtc_y,
+   __entry->crtc_w, __entry->crtc_h,
+   __entry->src_x >> 16, __entry->src_y >> 16,
+   __entry->src_w >> 16, __entry->src_h >> 16)
 );
 
 TRACE_EVENT(armada_ovl_plane_work,
-- 
2.7.4

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

[PATCH 16/25] drm/armada: allow armada_drm_plane_work_queue() to silently fail

[Russell King]

Avoid printing an error message when armada_drm_plane_work_queue() is
unable to get the vblank (eg, because we're doing a modeset.)  Continue
to report the failure to the caller, so the caller can handle this.

Move the error message into armada_ovl_plane_update().

Signed-off-by: Russell King 
---
 drivers/gpu/drm/armada/armada_crtc.c| 4 +---
 drivers/gpu/drm/armada/armada_overlay.c | 4 +++-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
b/drivers/gpu/drm/armada/armada_crtc.c
index 401ad854d751..2f8e45976444 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -254,10 +254,8 @@ int armada_drm_plane_work_queue(struct armada_crtc *dcrtc,
int ret;
 
ret = drm_crtc_vblank_get(>crtc);
-   if (ret) {
-   DRM_ERROR("failed to acquire vblank counter\n");
+   if (ret)
return ret;
-   }
 
ret = cmpxchg(>work, NULL, work) ? -EBUSY : 0;
if (ret)
diff --git a/drivers/gpu/drm/armada/armada_overlay.c 
b/drivers/gpu/drm/armada/armada_overlay.c
index 010f3e438607..53edf42c5863 100644
--- a/drivers/gpu/drm/armada/armada_overlay.c
+++ b/drivers/gpu/drm/armada/armada_overlay.c
@@ -245,7 +245,9 @@ armada_ovl_plane_update(struct drm_plane *plane, struct 
drm_crtc *crtc,
if (idx) {
armada_reg_queue_end(work->regs, idx);
/* Queue it for update on the next interrupt if we are enabled 
*/
-   armada_drm_plane_work_queue(dcrtc, work);
+   ret = armada_drm_plane_work_queue(dcrtc, work);
+   if (ret)
+   DRM_ERROR("failed to queue plane work: %d\n", ret);
}
return 0;
 }
-- 
2.7.4

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

[PATCH 18/25] drm/armada: disable planes at next blanking period

[Russell King]

Disable planes at the next blanking period rather than immediately.
In order to achieve this, we need to delay the clearing of dcrtc->plane
until after the next blanking period, so move that into a separate
work function.  To avoid races, we also need to move its assignment in
the overlay code.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/armada/armada_crtc.c| 59 -
 drivers/gpu/drm/armada/armada_overlay.c | 23 -
 2 files changed, 50 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
b/drivers/gpu/drm/armada/armada_crtc.c
index 98fb955f6889..c38a1409a14e 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -293,6 +293,19 @@ static void armada_drm_crtc_complete_frame_work(struct 
armada_crtc *dcrtc,
spin_unlock_irqrestore(>irq_lock, flags);
 }
 
+static void armada_drm_crtc_complete_disable_work(struct armada_crtc *dcrtc,
+   struct armada_plane_work *work)
+{
+   unsigned long flags;
+
+   if (dcrtc->plane == work->plane)
+   dcrtc->plane = NULL;
+
+   spin_lock_irqsave(>irq_lock, flags);
+   armada_drm_crtc_update_regs(dcrtc, work->regs);
+   spin_unlock_irqrestore(>irq_lock, flags);
+}
+
 static struct armada_plane_work *
 armada_drm_crtc_alloc_plane_work(struct drm_plane *plane)
 {
@@ -392,8 +405,11 @@ static void armada_drm_crtc_prepare(struct drm_crtc *crtc)
 * the new mode parameters.
 */
plane = dcrtc->plane;
-   if (plane)
+   if (plane) {
drm_plane_force_disable(plane);
+   WARN_ON(!armada_drm_plane_work_wait(drm_to_armada_plane(plane),
+   HZ));
+   }
 }
 
 /* The mode_config.mutex will be held for this call */
@@ -1120,28 +1136,22 @@ int armada_drm_plane_disable(struct drm_plane *plane,
 {
struct armada_plane *dplane = drm_to_armada_plane(plane);
struct armada_crtc *dcrtc;
+   struct armada_plane_work *work;
+   unsigned int idx = 0;
u32 sram_para1, enable_mask;
 
if (!plane->crtc)
return 0;
 
/*
-* Drop our reference on any framebuffer attached to this plane.
-* We don't need to NULL this out as drm_plane_force_disable(),
-* and __setplane_internal() will do so for an overlay plane, and
-* __drm_helper_disable_unused_functions() will do so for the
-* primary plane.
+* Arrange to power down most RAMs and FIFOs if this is the primary
+* plane, otherwise just the YUV FIFOs for the overlay plane.
 */
-   if (plane->fb)
-   drm_framebuffer_put(plane->fb);
-
-   /* Power down most RAMs and FIFOs if this is the primary plane */
if (plane->type == DRM_PLANE_TYPE_PRIMARY) {
sram_para1 = CFG_PDWN256x32 | CFG_PDWN256x24 | CFG_PDWN256x8 |
 CFG_PDWN32x32 | CFG_PDWN64x66;
enable_mask = CFG_GRA_ENA;
} else {
-   /* Power down the Y/U/V FIFOs */
sram_para1 = CFG_PDWN16x66 | CFG_PDWN32x66;
enable_mask = CFG_DMA_ENA;
}
@@ -1150,14 +1160,33 @@ int armada_drm_plane_disable(struct drm_plane *plane,
 
dcrtc = drm_to_armada_crtc(plane->crtc);
 
+   /*
+* Try to disable the plane and drop our ref on the framebuffer
+* at the next frame update. If we fail for any reason, disable
+* the plane immediately.
+*/
+   work = >works[dplane->next_work];
+   work->fn = armada_drm_crtc_complete_disable_work;
+   work->cancel = armada_drm_crtc_complete_disable_work;
+   work->old_fb = plane->fb;
+
+   armada_reg_queue_mod(work->regs, idx,
+0, enable_mask, LCD_SPU_DMA_CTRL0);
+   armada_reg_queue_mod(work->regs, idx,
+sram_para1, 0, LCD_SPU_SRAM_PARA1);
+   armada_reg_queue_end(work->regs, idx);
+
/* Wait for any preceding work to complete, but don't wedge */
if (WARN_ON(!armada_drm_plane_work_wait(dplane, HZ)))
armada_drm_plane_work_cancel(dcrtc, dplane);
 
-   spin_lock_irq(>irq_lock);
-   armada_updatel(0, enable_mask, dcrtc->base + LCD_SPU_DMA_CTRL0);
-   armada_updatel(sram_para1, 0, dcrtc->base + LCD_SPU_SRAM_PARA1);
-   spin_unlock_irq(>irq_lock);
+   if (armada_drm_plane_work_queue(dcrtc, work)) {
+   work->fn(dcrtc, work);
+   if (work->old_fb)
+   drm_framebuffer_unreference(work->old_fb);
+   }
+
+   dplane->next_work = !dplane->next_work;
 
return 0;
 }
diff --git a/drivers/gpu/drm/armada/armada_overlay.c 
b/drivers/gpu/drm/armada/armada_overlay.c
index bad966ae6758..0fe3f2db8ff5 100644
--- a/drivers/gpu/drm/armada/armada_overlay.c
+++ b/drivers/gpu/drm/armada/armada_overlay.c
@@ -140,11 +140,6 @@ 

[PATCH 4/5] drm/armada: improve efficiency of armada_drm_plane_calc_addrs()

[Russell King]

Lookup the drm_format_info structure once when computing all the
framebuffer plane addresses by using drm_format_info(), rather than
repetitive lookups via drm_format_plane_cpp().

Signed-off-by: Russell King 
---
 drivers/gpu/drm/armada/armada_crtc.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
b/drivers/gpu/drm/armada/armada_crtc.c
index 77fc038cbfae..748de4691224 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -168,8 +168,9 @@ static void armada_drm_crtc_update(struct armada_crtc 
*dcrtc)
 void armada_drm_plane_calc_addrs(u32 *addrs, struct drm_framebuffer *fb,
int x, int y)
 {
+   const struct drm_format_info *format = fb->format;
+   unsigned int num_planes = format->num_planes;
u32 addr = drm_fb_obj(fb)->dev_addr;
-   int num_planes = fb->format->num_planes;
int i;
 
if (num_planes > 3)
@@ -177,7 +178,7 @@ void armada_drm_plane_calc_addrs(u32 *addrs, struct 
drm_framebuffer *fb,
 
for (i = 0; i < num_planes; i++)
addrs[i] = addr + fb->offsets[i] + y * fb->pitches[i] +
-x * fb->format->cpp[i];
+x * format->cpp[i];
for (; i < 3; i++)
addrs[i] = 0;
 }
-- 
2.7.4

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

[PATCH 05/25] drm/armada: wait and cancel any pending frame work at disable

[Russell King]

Wait for a second, and if we time out, cancel any pending work when
disabling the primary plane.  This ensures that any pending work is
completed or cleaned up prior to the disable taking effect.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/armada/armada_crtc.c| 28 ++--
 drivers/gpu/drm/armada/armada_overlay.c |  2 --
 2 files changed, 22 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
b/drivers/gpu/drm/armada/armada_crtc.c
index f10ab0275ce7..328f030ffbdc 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -273,18 +273,15 @@ void armada_drm_plane_work_cancel(struct armada_crtc 
*dcrtc,
armada_drm_plane_work_call(dcrtc, work, work->cancel);
 }
 
-static void armada_drm_crtc_complete_frame_work(struct armada_crtc *dcrtc,
+static void armada_drm_crtc_finish_frame_work(struct armada_crtc *dcrtc,
struct armada_plane_work *work)
 {
struct armada_frame_work *fwork = container_of(work, struct 
armada_frame_work, work);
-   struct drm_device *dev = dcrtc->crtc.dev;
unsigned long flags;
 
-   spin_lock_irqsave(>irq_lock, flags);
-   armada_drm_crtc_update_regs(dcrtc, fwork->regs);
-   spin_unlock_irqrestore(>irq_lock, flags);
-
if (fwork->event) {
+   struct drm_device *dev = dcrtc->crtc.dev;
+
spin_lock_irqsave(>event_lock, flags);
drm_crtc_send_vblank_event(>crtc, fwork->event);
spin_unlock_irqrestore(>event_lock, flags);
@@ -295,6 +292,19 @@ static void armada_drm_crtc_complete_frame_work(struct 
armada_crtc *dcrtc,
kfree(fwork);
 }
 
+static void armada_drm_crtc_complete_frame_work(struct armada_crtc *dcrtc,
+   struct armada_plane_work *work)
+{
+   struct armada_frame_work *fwork = container_of(work, struct 
armada_frame_work, work);
+   unsigned long flags;
+
+   spin_lock_irqsave(>irq_lock, flags);
+   armada_drm_crtc_update_regs(dcrtc, fwork->regs);
+   spin_unlock_irqrestore(>irq_lock, flags);
+
+   armada_drm_crtc_finish_frame_work(dcrtc, work);
+}
+
 static struct armada_frame_work *
 armada_drm_crtc_alloc_frame_work(struct drm_plane *plane)
 {
@@ -307,6 +317,7 @@ armada_drm_crtc_alloc_frame_work(struct drm_plane *plane)
 
work->work.plane = plane;
work->work.fn = armada_drm_crtc_complete_frame_work;
+   work->work.cancel = armada_drm_crtc_finish_frame_work;
armada_reg_queue_end(work->regs, i);
 
return work;
@@ -752,6 +763,7 @@ static int armada_drm_crtc_mode_set_base(struct drm_crtc 
*crtc, int x, int y,
 void armada_drm_crtc_plane_disable(struct armada_crtc *dcrtc,
struct drm_plane *plane)
 {
+   struct armada_plane *dplane = drm_to_armada_plane(plane);
u32 sram_para1, dma_ctrl0_mask;
 
/*
@@ -775,6 +787,10 @@ void armada_drm_crtc_plane_disable(struct armada_crtc 
*dcrtc,
dma_ctrl0_mask = CFG_DMA_ENA;
}
 
+   /* Wait for any preceding work to complete, but don't wedge */
+   if (WARN_ON(!armada_drm_plane_work_wait(dplane, HZ)))
+   armada_drm_plane_work_cancel(dcrtc, dplane);
+
spin_lock_irq(>irq_lock);
armada_updatel(0, dma_ctrl0_mask, dcrtc->base + LCD_SPU_DMA_CTRL0);
spin_unlock_irq(>irq_lock);
diff --git a/drivers/gpu/drm/armada/armada_overlay.c 
b/drivers/gpu/drm/armada/armada_overlay.c
index 1fa8ea8cb2de..cf8442583bfc 100644
--- a/drivers/gpu/drm/armada/armada_overlay.c
+++ b/drivers/gpu/drm/armada/armada_overlay.c
@@ -270,8 +270,6 @@ static int armada_ovl_plane_disable(struct drm_plane *plane,
return 0;
 
dcrtc = drm_to_armada_crtc(dplane->base.base.crtc);
-
-   armada_drm_plane_work_cancel(dcrtc, >base);
armada_drm_crtc_plane_disable(dcrtc, plane);
 
dcrtc->plane = NULL;
-- 
2.7.4

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

[PATCH 20/25] drm/armada: move overlay plane register update generation

[Russell King]

Move the overlay plane register update generation to a separate function
as this is independent of the legacy or atomic update.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/armada/armada_crtc.h|   2 +
 drivers/gpu/drm/armada/armada_overlay.c | 203 +---
 2 files changed, 112 insertions(+), 93 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_crtc.h 
b/drivers/gpu/drm/armada/armada_crtc.h
index 0c7b519c09e8..445829b8877a 100644
--- a/drivers/gpu/drm/armada/armada_crtc.h
+++ b/drivers/gpu/drm/armada/armada_crtc.h
@@ -52,6 +52,8 @@ struct armada_plane_state {
u32 dst_hw;
u32 dst_yx;
u32 ctrl0;
+   bool changed;
+   bool vsync_update;
 };
 
 struct armada_plane {
diff --git a/drivers/gpu/drm/armada/armada_overlay.c 
b/drivers/gpu/drm/armada/armada_overlay.c
index 00da2c58701c..e5fa346f572b 100644
--- a/drivers/gpu/drm/armada/armada_overlay.c
+++ b/drivers/gpu/drm/armada/armada_overlay.c
@@ -75,153 +75,172 @@ static void armada_ovl_plane_work(struct armada_crtc 
*dcrtc,
spin_unlock_irqrestore(>irq_lock, flags);
 }
 
-static int
-armada_ovl_plane_update(struct drm_plane *plane, struct drm_crtc *crtc,
-   struct drm_framebuffer *fb,
-   int crtc_x, int crtc_y, unsigned crtc_w, unsigned crtc_h,
-   uint32_t src_x, uint32_t src_y, uint32_t src_w, uint32_t src_h,
-   struct drm_modeset_acquire_ctx *ctx)
+static void armada_ovl_plane_update_state(struct drm_plane_state *state,
+   struct armada_regs *regs)
 {
-   struct armada_ovl_plane *dplane = drm_to_armada_ovl_plane(plane);
-   struct armada_crtc *dcrtc = drm_to_armada_crtc(crtc);
-   struct armada_plane_work *work;
+   struct armada_ovl_plane *dplane = drm_to_armada_ovl_plane(state->plane);
+   struct armada_framebuffer *dfb = drm_fb_to_armada_fb(state->fb);
const struct drm_format_info *format;
-   struct drm_plane_state state = {
-   .plane = plane,
-   .crtc = crtc,
-   .fb = fb,
-   .src_x = src_x,
-   .src_y = src_y,
-   .src_w = src_w,
-   .src_h = src_h,
-   .crtc_x = crtc_x,
-   .crtc_y = crtc_y,
-   .crtc_w = crtc_w,
-   .crtc_h = crtc_h,
-   .rotation = DRM_MODE_ROTATE_0,
-   };
-   const struct drm_rect clip = {
-   .x2 = crtc->mode.hdisplay,
-   .y2 = crtc->mode.vdisplay,
-   };
-   uint32_t val, ctrl0;
-   unsigned idx = 0;
+   unsigned int idx = 0;
bool fb_changed;
-   int ret;
+   u32 val, ctrl0;
+   u16 src_x, src_y;
 
-   trace_armada_ovl_plane_update(plane, crtc, fb,
-crtc_x, crtc_y, crtc_w, crtc_h,
-src_x, src_y, src_w, src_h);
-
-   ret = drm_plane_helper_check_state(, , 0, INT_MAX, true,
-   false);
-   if (ret)
-   return ret;
-
-   work = >base.works[dplane->base.next_work];
-
-   ctrl0 = CFG_DMA_FMT(drm_fb_to_armada_fb(fb)->fmt) |
-   CFG_DMA_MOD(drm_fb_to_armada_fb(fb)->mod) |
-   CFG_CBSH_ENA;
-   if (state.visible)
+   ctrl0 = CFG_DMA_FMT(dfb->fmt) | CFG_DMA_MOD(dfb->mod) | CFG_CBSH_ENA;
+   if (state->visible)
ctrl0 |= CFG_DMA_ENA;
-   if (drm_rect_width() >> 16 != drm_rect_width())
+   if (drm_rect_width(>src) >> 16 != drm_rect_width(>dst))
ctrl0 |= CFG_DMA_HSMOOTH;
 
/*
 * Shifting a YUV packed format image by one pixel causes the U/V
 * planes to swap.  Compensate for it by also toggling the UV swap.
 */
-   format = fb->format;
-   if (format->num_planes == 1 && state.src.x1 >> 16 & (format->hsub - 1))
+   format = dfb->fb.format;
+   if (format->num_planes == 1 && state->src.x1 >> 16 & (format->hsub - 1))
ctrl0 ^= CFG_DMA_MOD(CFG_SWAPUV);
 
if (~dplane->base.state.ctrl0 & ctrl0 & CFG_DMA_ENA) {
/* Power up the Y/U/V FIFOs on ENA 0->1 transitions */
-   armada_reg_queue_mod(work->regs, idx,
+   armada_reg_queue_mod(regs, idx,
 0, CFG_PDWN16x66 | CFG_PDWN32x66,
 LCD_SPU_SRAM_PARA1);
}
 
-   fb_changed = plane->fb != fb ||
-dplane->base.state.src_x != state.src.x1 >> 16 ||
-dplane->base.state.src_y != state.src.y1 >> 16;
+   fb_changed = dplane->base.base.fb != >fb ||
+dplane->base.state.src_x != state->src.x1 >> 16 ||
+dplane->base.state.src_y != state->src.y1 >> 16;
+
+   dplane->base.state.vsync_update = fb_changed;
 
/* FIXME: overlay on an interlaced display */
if (fb_changed) {
u32 addrs[3];
 
-   /*
-* Take a 

Re: [PATCH v2 2/7] drm/i2c: tda998x: move CEC device initialisation later

[Russell King - ARM Linux]

On Wed, Dec 06, 2017 at 02:54:04PM +0100, Hans Verkuil wrote:
> On 12/06/17 13:35, Russell King wrote:
> > We no longer use the CEC client to access the CEC part itself, so we can
> > move this later in the initialisation sequence.
> > 
> > Signed-off-by: Russell King 
> > ---
> >  drivers/gpu/drm/i2c/tda998x_drv.c | 7 ---
> >  1 file changed, 4 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
> > b/drivers/gpu/drm/i2c/tda998x_drv.c
> > index 7f4dbca7f7f4..4aeac2127974 100644
> > --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> > +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> > @@ -1490,9 +1490,6 @@ static int tda998x_create(struct i2c_client *client, 
> > struct tda998x_priv *priv)
> > priv->cec_addr = 0x34 + (client->addr & 0x03);
> > priv->current_page = 0xff;
> > priv->hdmi = client;
> > -   priv->cec = i2c_new_dummy(client->adapter, priv->cec_addr);
> > -   if (!priv->cec)
> > -   return -ENODEV;
> >  
> > /* wake up the device: */
> > cec_write(priv, REG_CEC_ENAMODS,
> > @@ -1546,6 +1543,10 @@ static int tda998x_create(struct i2c_client *client, 
> > struct tda998x_priv *priv)
> > CEC_FRO_IM_CLK_CTRL_GHOST_DIS | 
> > CEC_FRO_IM_CLK_CTRL_IMCLK_SEL);
> >  
> > /* initialize the optional IRQ */
> > +   priv->cec = i2c_new_dummy(client->adapter, priv->cec_addr);
> > +   if (!priv->cec)
> > +   return -ENODEV;
> > +
> 
> I'd move this up to before the 'initialize the optional IRQ' comment, since
> that should stay with the 'if (client->irq) {' line below.

I've swapped the order of patches 2 and 3, and moved this further down
near where we add the real cec device in a later patch.  This is
starting to get quite different from the patch series that I've tested,
and as I've already mentioned, testing is not going to happen for a
while.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 17/25] drm/armada: avoid work allocation

[Russell King]

Signed-off-by: Russell King 
---
 drivers/gpu/drm/armada/armada_crtc.c| 24 +---
 drivers/gpu/drm/armada/armada_crtc.h|  3 +++
 drivers/gpu/drm/armada/armada_overlay.c | 11 +++
 3 files changed, 23 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
b/drivers/gpu/drm/armada/armada_crtc.c
index 2f8e45976444..98fb955f6889 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -214,13 +214,15 @@ static void armada_drm_plane_work_call(struct armada_crtc 
*dcrtc,
void (*fn)(struct armada_crtc *, struct armada_plane_work *))
 {
struct armada_plane *dplane = drm_to_armada_plane(work->plane);
-   struct drm_pending_vblank_event *event = work->event;
-   struct drm_framebuffer *fb = work->old_fb;
+   struct drm_pending_vblank_event *event;
+   struct drm_framebuffer *fb;
 
if (fn)
fn(dcrtc, work);
drm_crtc_vblank_put(>crtc);
 
+   event = work->event;
+   fb = work->old_fb;
if (event || fb) {
struct drm_device *dev = dcrtc->crtc.dev;
unsigned long flags;
@@ -233,6 +235,9 @@ static void armada_drm_plane_work_call(struct armada_crtc 
*dcrtc,
spin_unlock_irqrestore(>event_lock, flags);
}
 
+   if (work->need_kfree)
+   kfree(work);
+
wake_up(>frame_wait);
 }
 
@@ -278,12 +283,6 @@ void armada_drm_plane_work_cancel(struct armada_crtc 
*dcrtc,
armada_drm_plane_work_call(dcrtc, work, work->cancel);
 }
 
-static void armada_drm_crtc_finish_frame_work(struct armada_crtc *dcrtc,
-   struct armada_plane_work *work)
-{
-   kfree(work);
-}
-
 static void armada_drm_crtc_complete_frame_work(struct armada_crtc *dcrtc,
struct armada_plane_work *work)
 {
@@ -292,8 +291,6 @@ static void armada_drm_crtc_complete_frame_work(struct 
armada_crtc *dcrtc,
spin_lock_irqsave(>irq_lock, flags);
armada_drm_crtc_update_regs(dcrtc, work->regs);
spin_unlock_irqrestore(>irq_lock, flags);
-
-   armada_drm_crtc_finish_frame_work(dcrtc, work);
 }
 
 static struct armada_plane_work *
@@ -308,7 +305,7 @@ armada_drm_crtc_alloc_plane_work(struct drm_plane *plane)
 
work->plane = plane;
work->fn = armada_drm_crtc_complete_frame_work;
-   work->cancel = armada_drm_crtc_finish_frame_work;
+   work->need_kfree = true;
armada_reg_queue_end(work->regs, i);
 
return work;
@@ -1173,6 +1170,11 @@ static const struct drm_plane_funcs 
armada_primary_plane_funcs = {
 
 int armada_drm_plane_init(struct armada_plane *plane)
 {
+   unsigned int i;
+
+   for (i = 0; i < ARRAY_SIZE(plane->works); i++)
+   plane->works[i].plane = >base;
+
init_waitqueue_head(>frame_wait);
 
return 0;
diff --git a/drivers/gpu/drm/armada/armada_crtc.h 
b/drivers/gpu/drm/armada/armada_crtc.h
index 12ef9688a45a..0c7b519c09e8 100644
--- a/drivers/gpu/drm/armada/armada_crtc.h
+++ b/drivers/gpu/drm/armada/armada_crtc.h
@@ -38,6 +38,7 @@ struct armada_variant;
 struct armada_plane_work {
void (*fn)(struct armada_crtc *, struct armada_plane_work *);
void (*cancel)(struct armada_crtc *, struct armada_plane_work *);
+   bool need_kfree;
struct drm_plane *plane;
struct drm_framebuffer *old_fb;
struct drm_pending_vblank_event *event;
@@ -56,6 +57,8 @@ struct armada_plane_state {
 struct armada_plane {
struct drm_planebase;
wait_queue_head_t   frame_wait;
+   boolnext_work;
+   struct armada_plane_work works[2];
struct armada_plane_work *work;
struct armada_plane_state state;
 };
diff --git a/drivers/gpu/drm/armada/armada_overlay.c 
b/drivers/gpu/drm/armada/armada_overlay.c
index 53edf42c5863..bad966ae6758 100644
--- a/drivers/gpu/drm/armada/armada_overlay.c
+++ b/drivers/gpu/drm/armada/armada_overlay.c
@@ -32,7 +32,6 @@ struct armada_ovl_plane_properties {
 
 struct armada_ovl_plane {
struct armada_plane base;
-   struct armada_plane_work work;
struct armada_ovl_plane_properties prop;
 };
 #define drm_to_armada_ovl_plane(p) \
@@ -85,7 +84,7 @@ armada_ovl_plane_update(struct drm_plane *plane, struct 
drm_crtc *crtc,
 {
struct armada_ovl_plane *dplane = drm_to_armada_ovl_plane(plane);
struct armada_crtc *dcrtc = drm_to_armada_crtc(crtc);
-   struct armada_plane_work *work = >work;
+   struct armada_plane_work *work;
const struct drm_format_info *format;
struct drm_plane_state state = {
.plane = plane,
@@ -119,6 +118,8 @@ armada_ovl_plane_update(struct drm_plane *plane, struct 
drm_crtc *crtc,
if (ret)
return ret;
 
+   work = >base.works[dplane->base.next_work];
+
ctrl0 = CFG_DMA_FMT(drm_fb_to_armada_fb(fb)->fmt) |

RE: [PATCH] drm/i915: Use copy_from_user() in fence copying

[David Laight]

From: Kees Cook
> Sent: 06 December 2017 20:29
>
> There's no good reason to separate the access_ok() from the copy,
> especially since the access_ok() size is hard-coded instead of using
> sizeof(). Instead, just use copy_from_user() directly.

Looks like an optimisation to save doing the access_ok() check
for every 'fence'.

OTOH 'user copy hardening' probably makes a much larger performance
degradation on this kind of code.
(Might be ok here because  probably refers to something in the
current stack frame.)

David

> Fixes: cf6e7bac6357 ("drm/i915: Add support for drm syncobjs")
> Cc: Jason Ekstrand 
> Cc: Chris Wilson 
> Signed-off-by: Kees Cook 
> ---
>  drivers/gpu/drm/i915/i915_gem_execbuffer.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index 435ed95df144..1da703213b17 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -2087,8 +2087,6 @@ get_fence_array(struct drm_i915_gem_execbuffer2 *args,
>   return ERR_PTR(-EINVAL);
> 
>   user = u64_to_user_ptr(args->cliprects_ptr);
> - if (!access_ok(VERIFY_READ, user, nfences * 2 * sizeof(u32)))
> - return ERR_PTR(-EFAULT);
> 
>   fences = kvmalloc_array(args->num_cliprects, sizeof(*fences),
>   __GFP_NOWARN | GFP_KERNEL);
> @@ -2099,7 +2097,7 @@ get_fence_array(struct drm_i915_gem_execbuffer2 *args,
>   struct drm_i915_gem_exec_fence fence;
>   struct drm_syncobj *syncobj;
> 
> - if (__copy_from_user(, user++, sizeof(fence))) {
> + if (copy_from_user(, user++, sizeof(fence))) {
>   err = -EFAULT;
>   goto err;
>   }
> --
> 2.7.4
> 
> 
> --
> Kees Cook
> Pixel Security
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 03/25] drm/armada: store plane in armada_plane_work

[Russell King]

Store the plane in the armada_plane_work structure rather than passing
it around; it doesn't get used very much in the work structures, so
passing it around is a needless expense.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/armada/armada_crtc.c| 27 +++
 drivers/gpu/drm/armada/armada_crtc.h|  7 +++
 drivers/gpu/drm/armada/armada_overlay.c | 12 +++-
 3 files changed, 21 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
b/drivers/gpu/drm/armada/armada_crtc.c
index 8606f6e35986..4d3db441466e 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -224,7 +224,7 @@ static void armada_drm_plane_work_run(struct armada_crtc 
*dcrtc,
 
/* Handle any pending frame work. */
if (work) {
-   work->fn(dcrtc, dplane, work);
+   work->fn(dcrtc, work);
drm_crtc_vblank_put(>crtc);
}
 
@@ -232,8 +232,9 @@ static void armada_drm_plane_work_run(struct armada_crtc 
*dcrtc,
 }
 
 int armada_drm_plane_work_queue(struct armada_crtc *dcrtc,
-   struct armada_plane *plane, struct armada_plane_work *work)
+   struct armada_plane_work *work)
 {
+   struct armada_plane *plane = drm_to_armada_plane(work->plane);
int ret;
 
ret = drm_crtc_vblank_get(>crtc);
@@ -263,16 +264,8 @@ void armada_drm_plane_work_cancel(struct armada_crtc 
*dcrtc,
drm_crtc_vblank_put(>crtc);
 }
 
-static int armada_drm_crtc_queue_frame_work(struct armada_crtc *dcrtc,
-   struct armada_frame_work *work)
-{
-   struct armada_plane *plane = drm_to_armada_plane(dcrtc->crtc.primary);
-
-   return armada_drm_plane_work_queue(dcrtc, plane, >work);
-}
-
 static void armada_drm_crtc_complete_frame_work(struct armada_crtc *dcrtc,
-   struct armada_plane *plane, struct armada_plane_work *work)
+   struct armada_plane_work *work)
 {
struct armada_frame_work *fwork = container_of(work, struct 
armada_frame_work, work);
struct drm_device *dev = dcrtc->crtc.dev;
@@ -293,7 +286,8 @@ static void armada_drm_crtc_complete_frame_work(struct 
armada_crtc *dcrtc,
kfree(fwork);
 }
 
-static struct armada_frame_work *armada_drm_crtc_alloc_frame_work(void)
+static struct armada_frame_work *
+armada_drm_crtc_alloc_frame_work(struct drm_plane *plane)
 {
struct armada_frame_work *work;
int i = 0;
@@ -302,6 +296,7 @@ static struct armada_frame_work 
*armada_drm_crtc_alloc_frame_work(void)
if (!work)
return NULL;
 
+   work->work.plane = plane;
work->work.fn = armada_drm_crtc_complete_frame_work;
armada_reg_queue_end(work->regs, i);
 
@@ -322,11 +317,11 @@ static void armada_drm_crtc_finish_fb(struct armada_crtc 
*dcrtc,
return;
}
 
-   work = armada_drm_crtc_alloc_frame_work();
+   work = armada_drm_crtc_alloc_frame_work(dcrtc->crtc.primary);
if (work) {
work->old_fb = fb;
 
-   if (armada_drm_crtc_queue_frame_work(dcrtc, work) == 0)
+   if (armada_drm_plane_work_queue(dcrtc, work) == 0)
return;
 
kfree(work);
@@ -1044,7 +1039,7 @@ static int armada_drm_crtc_page_flip(struct drm_crtc 
*crtc,
if (fb->format != crtc->primary->fb->format)
return -EINVAL;
 
-   work = armada_drm_crtc_alloc_frame_work();
+   work = armada_drm_crtc_alloc_frame_work(dcrtc->crtc.primary);
if (!work)
return -ENOMEM;
 
@@ -1061,7 +1056,7 @@ static int armada_drm_crtc_page_flip(struct drm_crtc 
*crtc,
 */
drm_framebuffer_get(fb);
 
-   ret = armada_drm_crtc_queue_frame_work(dcrtc, work);
+   ret = armada_drm_plane_work_queue(dcrtc, work);
if (ret) {
/* Undo our reference above */
drm_framebuffer_put(fb);
diff --git a/drivers/gpu/drm/armada/armada_crtc.h 
b/drivers/gpu/drm/armada/armada_crtc.h
index a054527eb962..821c0dd21e45 100644
--- a/drivers/gpu/drm/armada/armada_crtc.h
+++ b/drivers/gpu/drm/armada/armada_crtc.h
@@ -36,9 +36,8 @@ struct armada_plane;
 struct armada_variant;
 
 struct armada_plane_work {
-   void(*fn)(struct armada_crtc *,
- struct armada_plane *,
- struct armada_plane_work *);
+   void (*fn)(struct armada_crtc *, struct armada_plane_work *);
+   struct drm_plane *plane;
 };
 
 struct armada_plane_state {
@@ -60,7 +59,7 @@ struct armada_plane {
 
 int armada_drm_plane_init(struct armada_plane *plane);
 int armada_drm_plane_work_queue(struct armada_crtc *dcrtc,
-   struct armada_plane *plane, struct armada_plane_work *work);
+   struct armada_plane_work *work);
 int armada_drm_plane_work_wait(struct armada_plane *plane, long timeout);
 void armada_drm_plane_work_cancel(struct armada_crtc *dcrtc,
   

[PATCH 08/25] drm/armada: clear plane enable bit when disabling

[Russell King]

Clear the plane enable bit in the software state within
armada_drm_plane_disable() when disabling either the primary or
overlay planes.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/armada/armada_crtc.c| 10 ++
 drivers/gpu/drm/armada/armada_overlay.c |  2 --
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
b/drivers/gpu/drm/armada/armada_crtc.c
index 3287b72e48cc..bedcaed81ffa 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -1128,7 +1128,7 @@ int armada_drm_plane_disable(struct drm_plane *plane,
 {
struct armada_plane *dplane = drm_to_armada_plane(plane);
struct armada_crtc *dcrtc;
-   u32 sram_para1, dma_ctrl0_mask;
+   u32 sram_para1, enable_mask;
 
if (!plane->crtc)
return 0;
@@ -1147,13 +1147,15 @@ int armada_drm_plane_disable(struct drm_plane *plane,
if (plane->type == DRM_PLANE_TYPE_PRIMARY) {
sram_para1 = CFG_PDWN256x32 | CFG_PDWN256x24 | CFG_PDWN256x8 |
 CFG_PDWN32x32 | CFG_PDWN64x66;
-   dma_ctrl0_mask = CFG_GRA_ENA;
+   enable_mask = CFG_GRA_ENA;
} else {
/* Power down the Y/U/V FIFOs */
sram_para1 = CFG_PDWN16x66 | CFG_PDWN32x66;
-   dma_ctrl0_mask = CFG_DMA_ENA;
+   enable_mask = CFG_DMA_ENA;
}
 
+   dplane->state.ctrl0 &= ~enable_mask;
+
dcrtc = drm_to_armada_crtc(plane->crtc);
 
/* Wait for any preceding work to complete, but don't wedge */
@@ -1161,7 +1163,7 @@ int armada_drm_plane_disable(struct drm_plane *plane,
armada_drm_plane_work_cancel(dcrtc, dplane);
 
spin_lock_irq(>irq_lock);
-   armada_updatel(0, dma_ctrl0_mask, dcrtc->base + LCD_SPU_DMA_CTRL0);
+   armada_updatel(0, enable_mask, dcrtc->base + LCD_SPU_DMA_CTRL0);
spin_unlock_irq(>irq_lock);
 
armada_updatel(sram_para1, 0, dcrtc->base + LCD_SPU_SRAM_PARA1);
diff --git a/drivers/gpu/drm/armada/armada_overlay.c 
b/drivers/gpu/drm/armada/armada_overlay.c
index a53e7dd26b0b..995463cd542d 100644
--- a/drivers/gpu/drm/armada/armada_overlay.c
+++ b/drivers/gpu/drm/armada/armada_overlay.c
@@ -270,8 +270,6 @@ static int armada_ovl_plane_disable(struct drm_plane *plane,
if (dplane->base.base.crtc)
drm_to_armada_crtc(dplane->base.base.crtc)->plane = NULL;
 
-   dplane->base.state.ctrl0 = 0;
-
fb = xchg(>old_fb, NULL);
if (fb)
drm_framebuffer_put(fb);
-- 
2.7.4

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

[PATCH 14/25] drm/armada: only enable HSMOOTH if scaling horizontally

[Russell King]

Only enable the HSMOOTH control bit if we are scaling horizontally,
otherwise it makes no sense to enable the horizontal scaler.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/armada/armada_crtc.c|  5 +++--
 drivers/gpu/drm/armada/armada_overlay.c | 10 +-
 2 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
b/drivers/gpu/drm/armada/armada_crtc.c
index b0091142a79f..401ad854d751 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -583,7 +583,8 @@ static void armada_drm_primary_set(struct drm_crtc *crtc,
armada_reg_queue_mod(regs, i, ctrl0, CFG_GRAFORMAT |
 CFG_GRA_MOD(CFG_SWAPRB | CFG_SWAPUV |
 CFG_SWAPYU | CFG_YUV2RGB) |
-CFG_PALETTE_ENA | CFG_GRA_FTOGGLE,
+CFG_PALETTE_ENA | CFG_GRA_FTOGGLE |
+CFG_GRA_HSMOOTH | CFG_GRA_ENA,
 LCD_SPU_DMA_CTRL0);
armada_reg_queue_end(regs, i);
armada_drm_crtc_update_regs(dcrtc, regs);
@@ -605,7 +606,7 @@ static int armada_drm_crtc_mode_set(struct drm_crtc *crtc,
 
interlaced = !!(adj->flags & DRM_MODE_FLAG_INTERLACE);
 
-   val = CFG_GRA_ENA | CFG_GRA_HSMOOTH;
+   val = CFG_GRA_ENA;
val |= CFG_GRA_FMT(drm_fb_to_armada_fb(dcrtc->crtc.primary->fb)->fmt);
val |= CFG_GRA_MOD(drm_fb_to_armada_fb(dcrtc->crtc.primary->fb)->mod);
 
diff --git a/drivers/gpu/drm/armada/armada_overlay.c 
b/drivers/gpu/drm/armada/armada_overlay.c
index e02d0d9d4c23..19fce1a7159f 100644
--- a/drivers/gpu/drm/armada/armada_overlay.c
+++ b/drivers/gpu/drm/armada/armada_overlay.c
@@ -120,11 +120,11 @@ armada_ovl_plane_update(struct drm_plane *plane, struct 
drm_crtc *crtc,
 
ctrl0 = CFG_DMA_FMT(drm_fb_to_armada_fb(fb)->fmt) |
CFG_DMA_MOD(drm_fb_to_armada_fb(fb)->mod) |
-   CFG_CBSH_ENA | CFG_DMA_HSMOOTH | CFG_DMA_ENA;
-
-   /* Does the position/size result in nothing to display? */
-   if (!visible)
-   ctrl0 &= ~CFG_DMA_ENA;
+   CFG_CBSH_ENA;
+   if (visible)
+   ctrl0 |= CFG_DMA_ENA;
+   if (drm_rect_width() >> 16 != drm_rect_width())
+   ctrl0 |= CFG_DMA_HSMOOTH;
 
/*
 * Shifting a YUV packed format image by one pixel causes the U/V
-- 
2.7.4

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

Re: [PATCH v2 6/7] drm/i2c: tda998x: add CEC support

[Russell King - ARM Linux]

On Wed, Dec 06, 2017 at 02:50:44PM +0100, Hans Verkuil wrote:
> Hi Russell,
> 
> Thanks for this patch series!
> 
> On 12/06/17 13:35, Russell King wrote:
> > The TDA998x is a HDMI transmitter with a TDA9950 CEC engine integrated
> > onto the same die.  Add support for the TDA9950 CEC engine to the
> > TDA998x driver.
> > 
> > Signed-off-by: Russell King 
> > ---
> >  drivers/gpu/drm/i2c/Kconfig   |   1 +
> >  drivers/gpu/drm/i2c/tda998x_drv.c | 209 
> > +++---
> >  2 files changed, 196 insertions(+), 14 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i2c/Kconfig b/drivers/gpu/drm/i2c/Kconfig
> > index 3a232f5ff0a1..096d2139e733 100644
> > --- a/drivers/gpu/drm/i2c/Kconfig
> > +++ b/drivers/gpu/drm/i2c/Kconfig
> > @@ -22,6 +22,7 @@ config DRM_I2C_SIL164
> >  config DRM_I2C_NXP_TDA998X
> > tristate "NXP Semiconductors TDA998X HDMI encoder"
> > default m if DRM_TILCDC
> > +   select CEC_NOTIFIER
> 
> I believe this should be 'select CEC_CORE if CEC_NOTIFIER', conform the
> other drivers that do something similar.
> 
> Otherwise if tda9950 is configured as a module, and this as built-in, then
> cec is built as a module as well and this can't find the cec functions from
> the module.

You mean when we have:

CONFIG_DRM_I2C_NXP_TDA998X=y
CONFIG_DRM_I2C_NXP_TDA9950=m

?

That appears to work fine with:

CONFIG_CEC_CORE=m
CONFIG_CEC_NOTIFIER=y

in 4.14, as that's exactly the configuration I test with on Dove.  Maybe
that's changed recently, or maybe I haven't noticed it not working (I
can't test it at the moment, sorry.)

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 0/5] Armada DRM fixes

[Russell King - ARM Linux]

Hi David,

This series fixes some issues in the Armada DRM driver:
- A memory leak while cleaning up in the CRTC initialisation path
- Avoid powering down YUV FIFOs when disabling the graphics plane
- Several fixes for the overlay plane positioning

Minor updates for the comments from Sean Paul, and applies cleanly to
your drm-fixes branch, but otherwise the same.

Thanks.

 drivers/gpu/drm/armada/armada_crtc.c| 47 +++--
 drivers/gpu/drm/armada/armada_crtc.h|  2 ++
 drivers/gpu/drm/armada/armada_overlay.c | 38 +-
 3 files changed, 48 insertions(+), 39 deletions(-)

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 04/25] drm/armada: add work cancel callback

[Russell King]

Add a work cancel callback, so that work items can add functionality to
clean themselves up when they are cancelled.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/armada/armada_crtc.c | 23 ---
 drivers/gpu/drm/armada/armada_crtc.h |  1 +
 2 files changed, 17 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
b/drivers/gpu/drm/armada/armada_crtc.c
index 4d3db441466e..f10ab0275ce7 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -216,6 +216,19 @@ static unsigned armada_drm_crtc_calc_fb(struct 
drm_framebuffer *fb,
return i;
 }
 
+static void armada_drm_plane_work_call(struct armada_crtc *dcrtc,
+   struct armada_plane_work *work,
+   void (*fn)(struct armada_crtc *, struct armada_plane_work *))
+{
+   struct armada_plane *dplane = drm_to_armada_plane(work->plane);
+
+   if (fn)
+   fn(dcrtc, work);
+   drm_crtc_vblank_put(>crtc);
+
+   wake_up(>frame_wait);
+}
+
 static void armada_drm_plane_work_run(struct armada_crtc *dcrtc,
struct drm_plane *plane)
 {
@@ -223,12 +236,8 @@ static void armada_drm_plane_work_run(struct armada_crtc 
*dcrtc,
struct armada_plane_work *work = xchg(>work, NULL);
 
/* Handle any pending frame work. */
-   if (work) {
-   work->fn(dcrtc, work);
-   drm_crtc_vblank_put(>crtc);
-   }
-
-   wake_up(>frame_wait);
+   if (work)
+   armada_drm_plane_work_call(dcrtc, work, work->fn);
 }
 
 int armada_drm_plane_work_queue(struct armada_crtc *dcrtc,
@@ -261,7 +270,7 @@ void armada_drm_plane_work_cancel(struct armada_crtc *dcrtc,
struct armada_plane_work *work = xchg(>work, NULL);
 
if (work)
-   drm_crtc_vblank_put(>crtc);
+   armada_drm_plane_work_call(dcrtc, work, work->cancel);
 }
 
 static void armada_drm_crtc_complete_frame_work(struct armada_crtc *dcrtc,
diff --git a/drivers/gpu/drm/armada/armada_crtc.h 
b/drivers/gpu/drm/armada/armada_crtc.h
index 821c0dd21e45..c26814c2ce08 100644
--- a/drivers/gpu/drm/armada/armada_crtc.h
+++ b/drivers/gpu/drm/armada/armada_crtc.h
@@ -37,6 +37,7 @@ struct armada_variant;
 
 struct armada_plane_work {
void (*fn)(struct armada_crtc *, struct armada_plane_work *);
+   void (*cancel)(struct armada_crtc *, struct armada_plane_work *);
struct drm_plane *plane;
 };
 
-- 
2.7.4

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

[PATCH 22/25] drm/armada: extract register generation from armada_drm_primary_set()

[Russell King]

Extract the register generation from armada_drm_primary_set(), so that
it can be re-used.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/armada/armada_crtc.c | 25 -
 1 file changed, 16 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
b/drivers/gpu/drm/armada/armada_crtc.c
index c38a1409a14e..9958f2d3d0e8 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -571,18 +571,14 @@ static uint32_t armada_drm_crtc_calculate_csc(struct 
armada_crtc *dcrtc)
return val;
 }
 
-static void armada_drm_primary_set(struct drm_crtc *crtc,
-   struct drm_plane *plane, int x, int y)
+static void armada_drm_gra_plane_regs(struct armada_regs *regs,
+   struct drm_framebuffer *fb, struct armada_plane_state *state,
+   int x, int y, bool interlaced)
 {
-   struct armada_plane_state *state = _to_armada_plane(plane)->state;
-   struct armada_crtc *dcrtc = drm_to_armada_crtc(crtc);
-   struct armada_regs regs[8];
-   bool interlaced = dcrtc->interlaced;
-   unsigned i;
+   unsigned int i;
u32 ctrl0;
 
-   i = armada_drm_crtc_calc_fb(plane->fb, x, y, regs, interlaced);
-
+   i = armada_drm_crtc_calc_fb(fb, x, y, regs, interlaced);
armada_reg_queue_set(regs, i, state->dst_yx, LCD_SPU_GRA_OVSA_HPXL_VLN);
armada_reg_queue_set(regs, i, state->src_hw, LCD_SPU_GRA_HPXL_VLN);
armada_reg_queue_set(regs, i, state->dst_hw, LCD_SPU_GZM_HPXL_VLN);
@@ -598,6 +594,17 @@ static void armada_drm_primary_set(struct drm_crtc *crtc,
 CFG_GRA_HSMOOTH | CFG_GRA_ENA,
 LCD_SPU_DMA_CTRL0);
armada_reg_queue_end(regs, i);
+}
+
+static void armada_drm_primary_set(struct drm_crtc *crtc,
+   struct drm_plane *plane, int x, int y)
+{
+   struct armada_plane_state *state = _to_armada_plane(plane)->state;
+   struct armada_crtc *dcrtc = drm_to_armada_crtc(crtc);
+   struct armada_regs regs[8];
+   bool interlaced = dcrtc->interlaced;
+
+   armada_drm_gra_plane_regs(regs, plane->fb, state, x, y, interlaced);
armada_drm_crtc_update_regs(dcrtc, regs);
 }
 
-- 
2.7.4

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

[PATCH 11/25] drm/armada: move event sending into armada_plane_work

[Russell King]

Move the sending of events into the armada_plane_work structure, and
combine the processing in armada_drm_plane_work_call().

Signed-off-by: Russell King 
---
 drivers/gpu/drm/armada/armada_crtc.c | 27 +--
 drivers/gpu/drm/armada/armada_crtc.h |  1 +
 2 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
b/drivers/gpu/drm/armada/armada_crtc.c
index d1f4171966cc..b043766c416c 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -22,7 +22,6 @@
 
 struct armada_frame_work {
struct armada_plane_work work;
-   struct drm_pending_vblank_event *event;
struct armada_regs regs[4];
 };
 
@@ -220,15 +219,24 @@ static void armada_drm_plane_work_call(struct armada_crtc 
*dcrtc,
void (*fn)(struct armada_crtc *, struct armada_plane_work *))
 {
struct armada_plane *dplane = drm_to_armada_plane(work->plane);
+   struct drm_pending_vblank_event *event = work->event;
struct drm_framebuffer *fb = work->old_fb;
 
if (fn)
fn(dcrtc, work);
drm_crtc_vblank_put(>crtc);
 
-   /* Finally, queue the process-half of the cleanup. */
-   if (fb)
-   armada_drm_queue_unref_work(dcrtc->crtc.dev, fb);
+   if (event || fb) {
+   struct drm_device *dev = dcrtc->crtc.dev;
+   unsigned long flags;
+
+   spin_lock_irqsave(>event_lock, flags);
+   if (event)
+   drm_crtc_send_vblank_event(>crtc, event);
+   if (fb)
+   __armada_drm_queue_unref_work(dev, fb);
+   spin_unlock_irqrestore(>event_lock, flags);
+   }
 
wake_up(>frame_wait);
 }
@@ -281,15 +289,6 @@ static void armada_drm_crtc_finish_frame_work(struct 
armada_crtc *dcrtc,
struct armada_plane_work *work)
 {
struct armada_frame_work *fwork = container_of(work, struct 
armada_frame_work, work);
-   unsigned long flags;
-
-   if (fwork->event) {
-   struct drm_device *dev = dcrtc->crtc.dev;
-
-   spin_lock_irqsave(>event_lock, flags);
-   drm_crtc_send_vblank_event(>crtc, fwork->event);
-   spin_unlock_irqrestore(>event_lock, flags);
-   }
 
kfree(fwork);
 }
@@ -1032,7 +1031,7 @@ static int armada_drm_crtc_page_flip(struct drm_crtc 
*crtc,
if (!work)
return -ENOMEM;
 
-   work->event = event;
+   work->work.event = event;
work->work.old_fb = dcrtc->crtc.primary->fb;
 
i = armada_drm_crtc_calc_fb(fb, crtc->x, crtc->y, work->regs,
diff --git a/drivers/gpu/drm/armada/armada_crtc.h 
b/drivers/gpu/drm/armada/armada_crtc.h
index b40db72c61d8..4cdd2f0eabd9 100644
--- a/drivers/gpu/drm/armada/armada_crtc.h
+++ b/drivers/gpu/drm/armada/armada_crtc.h
@@ -40,6 +40,7 @@ struct armada_plane_work {
void (*cancel)(struct armada_crtc *, struct armada_plane_work *);
struct drm_plane *plane;
struct drm_framebuffer *old_fb;
+   struct drm_pending_vblank_event *event;
 };
 
 struct armada_plane_state {
-- 
2.7.4

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

Re: [git pull] drm fixes for v4.15-rc3

[Philippe Ombredanne]

Linus,

On Fri, Dec 8, 2017 at 10:16 PM, Linus Torvalds
 wrote:
> On Thu, Dec 7, 2017 at 5:20 PM, Dave Airlie  wrote:
>>
>> This pull is a bit larger than I'd like but a large bunch of it is
>> license fixes, AMD wanted to fix the licenses for a bunch of files
>> that were missing them,
>
> Oh Christ, couldn't they have just added the one-liner SPDX tags
> rather than doing that crazy "new 22 line boiler plate garbage to
> fifteen random Makefiles"?
>
> I pulled it, but let's try to reign in the crazy "lets add filler
> lines" behavior, ok?
>
> Alex, can you talk to the AMD lawyers and ask them about just putting
> the SPDX line instead?
>
> Linus

You made my day! I shall add that every time someone sends a patch
with long legalese boilerplate instead of a shorter SDPX tag, there is
a kitten that dies somewhere.
-- 
Cordially
Philippe Ombredanne, your friendly kernel licensing decraper
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 10/25] drm/armada: move fb retirement into armada_plane_work

[Russell King]

Both the primary and overlay planes retire framebuffers in a similar
manner; this can be consolidated by moving the retirement up to the
armada_plane_work layer.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/armada/armada_crtc.c| 12 +++-
 drivers/gpu/drm/armada/armada_crtc.h|  1 +
 drivers/gpu/drm/armada/armada_overlay.c | 30 +-
 3 files changed, 13 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
b/drivers/gpu/drm/armada/armada_crtc.c
index be3fd82ef516..d1f4171966cc 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -24,7 +24,6 @@ struct armada_frame_work {
struct armada_plane_work work;
struct drm_pending_vblank_event *event;
struct armada_regs regs[4];
-   struct drm_framebuffer *old_fb;
 };
 
 enum csc_mode {
@@ -221,11 +220,16 @@ static void armada_drm_plane_work_call(struct armada_crtc 
*dcrtc,
void (*fn)(struct armada_crtc *, struct armada_plane_work *))
 {
struct armada_plane *dplane = drm_to_armada_plane(work->plane);
+   struct drm_framebuffer *fb = work->old_fb;
 
if (fn)
fn(dcrtc, work);
drm_crtc_vblank_put(>crtc);
 
+   /* Finally, queue the process-half of the cleanup. */
+   if (fb)
+   armada_drm_queue_unref_work(dcrtc->crtc.dev, fb);
+
wake_up(>frame_wait);
 }
 
@@ -287,8 +291,6 @@ static void armada_drm_crtc_finish_frame_work(struct 
armada_crtc *dcrtc,
spin_unlock_irqrestore(>event_lock, flags);
}
 
-   /* Finally, queue the process-half of the cleanup. */
-   __armada_drm_queue_unref_work(dcrtc->crtc.dev, fwork->old_fb);
kfree(fwork);
 }
 
@@ -339,7 +341,7 @@ static void armada_drm_crtc_finish_fb(struct armada_crtc 
*dcrtc,
 
work = armada_drm_crtc_alloc_frame_work(dcrtc->crtc.primary);
if (work) {
-   work->old_fb = fb;
+   work->work.old_fb = fb;
 
if (armada_drm_plane_work_queue(dcrtc, >work) == 0)
return;
@@ -1031,7 +1033,7 @@ static int armada_drm_crtc_page_flip(struct drm_crtc 
*crtc,
return -ENOMEM;
 
work->event = event;
-   work->old_fb = dcrtc->crtc.primary->fb;
+   work->work.old_fb = dcrtc->crtc.primary->fb;
 
i = armada_drm_crtc_calc_fb(fb, crtc->x, crtc->y, work->regs,
dcrtc->interlaced);
diff --git a/drivers/gpu/drm/armada/armada_crtc.h 
b/drivers/gpu/drm/armada/armada_crtc.h
index 521ae5b6ad86..b40db72c61d8 100644
--- a/drivers/gpu/drm/armada/armada_crtc.h
+++ b/drivers/gpu/drm/armada/armada_crtc.h
@@ -39,6 +39,7 @@ struct armada_plane_work {
void (*fn)(struct armada_crtc *, struct armada_plane_work *);
void (*cancel)(struct armada_crtc *, struct armada_plane_work *);
struct drm_plane *plane;
+   struct drm_framebuffer *old_fb;
 };
 
 struct armada_plane_state {
diff --git a/drivers/gpu/drm/armada/armada_overlay.c 
b/drivers/gpu/drm/armada/armada_overlay.c
index 04746ade74e6..01087c952916 100644
--- a/drivers/gpu/drm/armada/armada_overlay.c
+++ b/drivers/gpu/drm/armada/armada_overlay.c
@@ -32,7 +32,6 @@ struct armada_ovl_plane_properties {
 
 struct armada_ovl_plane {
struct armada_plane base;
-   struct drm_framebuffer *old_fb;
struct {
struct armada_plane_work work;
struct armada_regs regs[13];
@@ -67,17 +66,6 @@ armada_ovl_update_attr(struct armada_ovl_plane_properties 
*prop,
spin_unlock_irq(>irq_lock);
 }
 
-static void armada_ovl_retire_fb(struct armada_ovl_plane *dplane,
-   struct drm_framebuffer *fb)
-{
-   struct drm_framebuffer *old_fb;
-
-   old_fb = xchg(>old_fb, fb);
-
-   if (old_fb)
-   armada_drm_queue_unref_work(dplane->base.base.dev, old_fb);
-}
-
 /* === Plane support === */
 static void armada_ovl_plane_work(struct armada_crtc *dcrtc,
struct armada_plane_work *work)
@@ -91,8 +79,6 @@ static void armada_ovl_plane_work(struct armada_crtc *dcrtc,
spin_lock_irqsave(>irq_lock, flags);
armada_drm_crtc_update_regs(dcrtc, dplane->vbl.regs);
spin_unlock_irqrestore(>irq_lock, flags);
-
-   armada_ovl_retire_fb(dplane, NULL);
 }
 
 static int
@@ -196,8 +182,7 @@ armada_ovl_plane_update(struct drm_plane *plane, struct 
drm_crtc *crtc,
 */
drm_framebuffer_get(fb);
 
-   if (plane->fb)
-   armada_ovl_retire_fb(dplane, plane->fb);
+   dplane->vbl.work.old_fb = plane->fb;
 
dplane->base.state.src_y = src_y = src.y1 >> 16;
dplane->base.state.src_x = src_x = src.x1 >> 16;
@@ -223,6 +208,8 @@ armada_ovl_plane_update(struct drm_plane *plane, struct 
drm_crtc *crtc,
val = fb->pitches[1] << 16 | fb->pitches[2];

Re: [PATCH] drm/i915: Use copy_from_user() in fence copying

[Kees Cook]

On Fri, Dec 8, 2017 at 2:17 AM, David Laight  wrote:
> From: Kees Cook
>> Sent: 06 December 2017 20:29
>>
>> There's no good reason to separate the access_ok() from the copy,
>> especially since the access_ok() size is hard-coded instead of using
>> sizeof(). Instead, just use copy_from_user() directly.
>
> Looks like an optimisation to save doing the access_ok() check
> for every 'fence'.

If it really makes a difference, okay, but access_ok() checks are fast. :P

> OTOH 'user copy hardening' probably makes a much larger performance
> degradation on this kind of code.
> (Might be ok here because  probably refers to something in the
> current stack frame.)

Well, the good news there is that it's using sizeof(fence), so no
hardening check is done (it's not a size that changes at runtime).
What I didn't like is that the access_ok() doesn't use sizeof(fence)
(it is currently correct: 2 u32s == sizeof(fence)) but that kind of
fragility keeps me up at night. ;)

So, fixing either would be fine, but if we're going to touch it, it
seems best to just do away with the __copy_*() usage instead.

-Kees


>
> David
>
>> Fixes: cf6e7bac6357 ("drm/i915: Add support for drm syncobjs")
>> Cc: Jason Ekstrand 
>> Cc: Chris Wilson 
>> Signed-off-by: Kees Cook 
>> ---
>>  drivers/gpu/drm/i915/i915_gem_execbuffer.c | 4 +---
>>  1 file changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
>> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
>> index 435ed95df144..1da703213b17 100644
>> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
>> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
>> @@ -2087,8 +2087,6 @@ get_fence_array(struct drm_i915_gem_execbuffer2 *args,
>>   return ERR_PTR(-EINVAL);
>>
>>   user = u64_to_user_ptr(args->cliprects_ptr);
>> - if (!access_ok(VERIFY_READ, user, nfences * 2 * sizeof(u32)))
>> - return ERR_PTR(-EFAULT);
>>
>>   fences = kvmalloc_array(args->num_cliprects, sizeof(*fences),
>>   __GFP_NOWARN | GFP_KERNEL);
>> @@ -2099,7 +2097,7 @@ get_fence_array(struct drm_i915_gem_execbuffer2 *args,
>>   struct drm_i915_gem_exec_fence fence;
>>   struct drm_syncobj *syncobj;
>>
>> - if (__copy_from_user(, user++, sizeof(fence))) {
>> + if (copy_from_user(, user++, sizeof(fence))) {
>>   err = -EFAULT;
>>   goto err;
>>   }
>> --
>> 2.7.4
>>
>>
>> --
>> Kees Cook
>> Pixel Security



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

[PATCH 12/25] drm/armada: move regs into armada_plane_work

[Russell King]

Move the register update structure out of the overlay private structure
into armada_plane_work, as this is common to both the primary and
overlay planes.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/armada/armada_crtc.c| 42 --
 drivers/gpu/drm/armada/armada_crtc.h|  1 +
 drivers/gpu/drm/armada/armada_overlay.c | 46 +++--
 3 files changed, 39 insertions(+), 50 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
b/drivers/gpu/drm/armada/armada_crtc.c
index b043766c416c..02eefdc6f062 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -20,11 +20,6 @@
 #include "armada_hw.h"
 #include "armada_trace.h"
 
-struct armada_frame_work {
-   struct armada_plane_work work;
-   struct armada_regs regs[4];
-};
-
 enum csc_mode {
CSC_AUTO = 0,
CSC_YUV_CCIR601 = 1,
@@ -288,37 +283,34 @@ void armada_drm_plane_work_cancel(struct armada_crtc 
*dcrtc,
 static void armada_drm_crtc_finish_frame_work(struct armada_crtc *dcrtc,
struct armada_plane_work *work)
 {
-   struct armada_frame_work *fwork = container_of(work, struct 
armada_frame_work, work);
-
-   kfree(fwork);
+   kfree(work);
 }
 
 static void armada_drm_crtc_complete_frame_work(struct armada_crtc *dcrtc,
struct armada_plane_work *work)
 {
-   struct armada_frame_work *fwork = container_of(work, struct 
armada_frame_work, work);
unsigned long flags;
 
spin_lock_irqsave(>irq_lock, flags);
-   armada_drm_crtc_update_regs(dcrtc, fwork->regs);
+   armada_drm_crtc_update_regs(dcrtc, work->regs);
spin_unlock_irqrestore(>irq_lock, flags);
 
armada_drm_crtc_finish_frame_work(dcrtc, work);
 }
 
-static struct armada_frame_work *
-armada_drm_crtc_alloc_frame_work(struct drm_plane *plane)
+static struct armada_plane_work *
+armada_drm_crtc_alloc_plane_work(struct drm_plane *plane)
 {
-   struct armada_frame_work *work;
+   struct armada_plane_work *work;
int i = 0;
 
work = kzalloc(sizeof(*work), GFP_KERNEL);
if (!work)
return NULL;
 
-   work->work.plane = plane;
-   work->work.fn = armada_drm_crtc_complete_frame_work;
-   work->work.cancel = armada_drm_crtc_finish_frame_work;
+   work->plane = plane;
+   work->fn = armada_drm_crtc_complete_frame_work;
+   work->cancel = armada_drm_crtc_finish_frame_work;
armada_reg_queue_end(work->regs, i);
 
return work;
@@ -327,7 +319,7 @@ armada_drm_crtc_alloc_frame_work(struct drm_plane *plane)
 static void armada_drm_crtc_finish_fb(struct armada_crtc *dcrtc,
struct drm_framebuffer *fb, bool force)
 {
-   struct armada_frame_work *work;
+   struct armada_plane_work *work;
 
if (!fb)
return;
@@ -338,11 +330,11 @@ static void armada_drm_crtc_finish_fb(struct armada_crtc 
*dcrtc,
return;
}
 
-   work = armada_drm_crtc_alloc_frame_work(dcrtc->crtc.primary);
+   work = armada_drm_crtc_alloc_plane_work(dcrtc->crtc.primary);
if (work) {
-   work->work.old_fb = fb;
+   work->old_fb = fb;
 
-   if (armada_drm_plane_work_queue(dcrtc, >work) == 0)
+   if (armada_drm_plane_work_queue(dcrtc, work) == 0)
return;
 
kfree(work);
@@ -1019,7 +1011,7 @@ static int armada_drm_crtc_page_flip(struct drm_crtc 
*crtc,
struct drm_modeset_acquire_ctx *ctx)
 {
struct armada_crtc *dcrtc = drm_to_armada_crtc(crtc);
-   struct armada_frame_work *work;
+   struct armada_plane_work *work;
unsigned i;
int ret;
 
@@ -1027,12 +1019,12 @@ static int armada_drm_crtc_page_flip(struct drm_crtc 
*crtc,
if (fb->format != crtc->primary->fb->format)
return -EINVAL;
 
-   work = armada_drm_crtc_alloc_frame_work(dcrtc->crtc.primary);
+   work = armada_drm_crtc_alloc_plane_work(dcrtc->crtc.primary);
if (!work)
return -ENOMEM;
 
-   work->work.event = event;
-   work->work.old_fb = dcrtc->crtc.primary->fb;
+   work->event = event;
+   work->old_fb = dcrtc->crtc.primary->fb;
 
i = armada_drm_crtc_calc_fb(fb, crtc->x, crtc->y, work->regs,
dcrtc->interlaced);
@@ -1044,7 +1036,7 @@ static int armada_drm_crtc_page_flip(struct drm_crtc 
*crtc,
 */
drm_framebuffer_get(fb);
 
-   ret = armada_drm_plane_work_queue(dcrtc, >work);
+   ret = armada_drm_plane_work_queue(dcrtc, work);
if (ret) {
/* Undo our reference above */
drm_framebuffer_put(fb);
diff --git a/drivers/gpu/drm/armada/armada_crtc.h 
b/drivers/gpu/drm/armada/armada_crtc.h
index 4cdd2f0eabd9..12ef9688a45a 100644
--- a/drivers/gpu/drm/armada/armada_crtc.h
+++ b/drivers/gpu/drm/armada/armada_crtc.h
@@ -41,6 +41,7 @@ 

Re: drm: vc4: WARNING: CPU: 2 PID: 172 at kernel/irq/chip.c:244 __irq_startup+0x9c/0xa8

[Marc Zyngier]

On Sat, 09 Dec 2017 14:17:58 +,
Stefan Schake wrote:
> 
> On Sat, Dec 9, 2017 at 1:34 PM, Marc Zyngier  wrote:
> > On Fri, 08 Dec 2017 22:44:27 +,
> > Stefan Wahren wrote:
> >>
> >> Hi,
> >>
> >> the commit 253696ccd613 ("drm/vc4: Account for interrupts in
> >> flight") triggers a warning during boot of Raspberry Pi 2 with
> >> multi_v7_defconfig:
> >>
> >> [7.962699] vc4_hdmi 3f902000.hdmi: vc4-hdmi-hifi <-> 3f902000.hdmi 
> >> mapping ok
> >> [7.962732] vc4_hdmi 3f902000.hdmi: ASoC: no DMI vendor name!
> >> [7.973355] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops 
> >> [vc4])
> >> [7.973651] vc4-drm soc:gpu: bound 3f806000.vec (ops vc4_vec_ops [vc4])
> >> [7.973788] vc4-drm soc:gpu: bound 3f40.hvs (ops vc4_hvs_ops [vc4])
> >> [7.974157] vc4-drm soc:gpu: bound 3f206000.pixelvalve (ops 
> >> vc4_crtc_ops [vc4])
> >> [7.974464] vc4-drm soc:gpu: bound 3f207000.pixelvalve (ops 
> >> vc4_crtc_ops [vc4])
> >> [7.974746] vc4-drm soc:gpu: bound 3f807000.pixelvalve (ops 
> >> vc4_crtc_ops [vc4])
> >> [8.018820] [ cut here ]
> >> [8.018861] WARNING: CPU: 2 PID: 172 at kernel/irq/chip.c:244 
> >> __irq_startup+0x9c/0xa8
> >> [8.018868] Modules linked in: vc4(+) snd_soc_core ac97_bus 
> >> snd_pcm_dmaengine snd_pcm snd_timer snd soundcore cec
> >> [8.018911] CPU: 2 PID: 172 Comm: systemd-udevd Not tainted 
> >> 4.15.0-rc1-00291-g75f64f6 #10
> >> [8.018914] Hardware name: BCM2835
> >> [8.018950] [] (unwind_backtrace) from [] 
> >> (show_stack+0x10/0x14)
> >> [8.018970] [] (show_stack) from [] 
> >> (dump_stack+0x88/0xa4)
> >> [8.018993] [] (dump_stack) from [] 
> >> (__warn+0xe4/0x110)
> >> [8.019012] [] (__warn) from [] 
> >> (warn_slowpath_null+0x3c/0x48)
> >> [8.019029] [] (warn_slowpath_null) from [] 
> >> (__irq_startup+0x9c/0xa8)
> >> [8.019045] [] (__irq_startup) from [] 
> >> (irq_startup+0x44/0x134)
> >> [8.019061] [] (irq_startup) from [] 
> >> (enable_irq+0x34/0x6c)
> >> [8.019210] [] (enable_irq) from [] 
> >> (vc4_irq_postinstall+0x14/0x34 [vc4])
> >> [8.019338] [] (vc4_irq_postinstall [vc4]) from [] 
> >> (drm_irq_install+0xc0/0x134)
> >> [8.019456] [] (drm_irq_install) from [] 
> >> (vc4_v3d_bind+0x12c/0x238 [vc4])
> >
> > The sequence "request_irq/enable" feels pretty odd, given that the
> > interrupt wasn't requested with NOAUTOEN. What are the expected
> > semantics of that patch?
> >
> > Thanks,
> >
> > M.
> >
> > --
> > Jazz is not dead, it just smell funny.
> 
> There is a second path to vc4_irq_postinstall when we return from
> power management disable. Maybe the enable would be better situated there?

I've no idea. But enabling an already enabled interrupts feels a bit
wrong, to say the least

> That said, some more study of the irq code is giving me more questions than
> answers. If disable/enable are depth-counted, why isn't it also warning
> about that (there is a check)? Depth must be 1 after request_irq.
> Similarly, the irq is activated in request_irq, but the warning reported
> here is complaining that it is not.

I'm afraid you'll have to trace why the irq is not flagged as
activated. From what I can see, the irqchip driver of this HW doesn't
even implement an activate callback, so the interrupt should be
trivially flagged as activated. If it is not, it means something
rather bad has happened. Do you see this splat on each enable_irq()?

M.

-- 
Jazz is not dead, it just smell funny.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/2] drm/tinydrm: add driver for ST7735R panels

[Philippe Ombredanne]

David,

On Sun, Dec 10, 2017 at 11:10 PM, David Lechner  wrote:
> This adds a new driver for Sitronix ST7735R display panels.
>
> This has been tested using an Adafruit 1.8" TFT.
>
> Signed-off-by: David Lechner 
> --- /dev/null
> +++ b/drivers/gpu/drm/tinydrm/st7735r.c
> @@ -0,0 +1,219 @@
> +/*
> + * DRM driver for Sitronix ST7735R panels
> + *
> + * Copyright 2017 David Lechner 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */

Have you considered using the new SPDX ids? Check the doc patches from
Thomas for details.

This could come out this way if you are using the C++ comment style
all the way, a style that you should at least use for the license id
as requested and commented by Linus:

> +// SPDX-License-Identifier: GPL-2.0+
> +// Copyright 2017 David Lechner 
> +// DRM driver for Sitronix ST7735R panels

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

RE: [PATCH] drm/i915: Use copy_from_user() in fence copying

[David Laight]

From: Kees Cook
> Sent: 08 December 2017 21:10
> >> There's no good reason to separate the access_ok() from the copy,
> >> especially since the access_ok() size is hard-coded instead of using
> >> sizeof(). Instead, just use copy_from_user() directly.
> >
> > Looks like an optimisation to save doing the access_ok() check
> > for every 'fence'.
> 
> If it really makes a difference, okay, but access_ok() checks are fast. :P

Not compared to get_user() :-)

David

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

Re: [RESEND PATCH 0/4] drm/meson: power domain init related fixes

[Jerome Brunet]

On Wed, 2017-12-06 at 12:54 +0100, Neil Armstrong wrote:
> On the Amlogic Gx SoCs (GXBB, GXL & GXM), the VPU power domain is initialized
> by the vendor U-Boot code, but running mainline U-boot has been possible
> on these SoCs. But lacking such init made the system lock at kernel boot.
> 
> A PM Power Domain driver has been pushed at [1] to solve the main issue.
> The following patches :
> - updates the DT bindings accordingly
> - adds support for missing regulators and registers init
> 
> Neil Armstrong (4):
>   dt-bindings: display: amlogic,meson-vpu: Add optional power domain
> property
>   dt-bindings: display: amlogic,meson-dw-hdmi: Add optional HDMI 5V
> regulator
>   drm/meson: dw_hdmi: Add support for an optional external 5V regulator
>   drm/meson: Add missing VPU init
> 
>  .../devicetree/bindings/display/amlogic,meson-dw-hdmi.txt   |  4 
>  .../devicetree/bindings/display/amlogic,meson-vpu.txt   |  4 
>  drivers/gpu/drm/meson/meson_drv.c   |  9 +
>  drivers/gpu/drm/meson/meson_dw_hdmi.c   | 13
> +
>  drivers/gpu/drm/meson/meson_registers.h |  4 
>  5 files changed, 34 insertions(+)
> 

No dependencies on the bootloader anymore, this is great ! Thanks 
Series tested on libretech-cc s905x

Tested-by: Jerome Brunet 
Reviewed-by: Jerome Brunet 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel