Re: [PATCH v5 06/36] drm/rockchip: Only wait for panel ACK on PSR entry

[Archit Taneja]

On Saturday 10 March 2018 03:52 AM, Enric Balletbo i Serra wrote:

From: zain wang 

We currently wait for the panel to mirror our intended PSR state
before continuing on both PSR enter and PSR exit. This is really
only important to do when we're entering PSR, since we want to
be sure the last frame we pushed is being served from the panel's
internal fb before shutting down the soc blocks (vop/analogix).

This patch changes the behavior such that we only wait for the
panel to complete the PSR transition when we're entering PSR, and
to skip verification when we're exiting.



With the subject fix:

Reviewed-by: Archit Taneja 

Thanks,
Archit


Cc: Stéphane Marchesin 
Cc: Sonny Rao 
Signed-off-by: zain wang 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
Signed-off-by: Enric Balletbo i Serra 
Tested-by: Marek Szyprowski 
---

  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 4 ++--
  drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 2 +-
  drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  | 5 -
  3 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 806c3878b3d6..5a2e35dc41e3 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -125,7 +125,7 @@ int analogix_dp_enable_psr(struct analogix_dp_device *dp)
psr_vsc.DB0 = 0;
psr_vsc.DB1 = EDP_VSC_PSR_STATE_ACTIVE | EDP_VSC_PSR_CRC_VALUES_VALID;
  
-	return analogix_dp_send_psr_spd(dp, _vsc);

+   return analogix_dp_send_psr_spd(dp, _vsc, true);
  }
  EXPORT_SYMBOL_GPL(analogix_dp_enable_psr);
  
@@ -151,7 +151,7 @@ int analogix_dp_disable_psr(struct analogix_dp_device *dp)

if (ret != 1)
dev_err(dp->dev, "Failed to set DP Power0 %d\n", ret);
  
-	return analogix_dp_send_psr_spd(dp, _vsc);

+   return analogix_dp_send_psr_spd(dp, _vsc, false);
  }
  EXPORT_SYMBOL_GPL(analogix_dp_disable_psr);
  
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h

index 920607d7eb3e..6a96ef7e6934 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -253,7 +253,7 @@ void analogix_dp_enable_scrambling(struct 
analogix_dp_device *dp);
  void analogix_dp_disable_scrambling(struct analogix_dp_device *dp);
  void analogix_dp_enable_psr_crc(struct analogix_dp_device *dp);
  int analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
-struct edp_vsc_psr *vsc);
+struct edp_vsc_psr *vsc, bool blocking);
  ssize_t analogix_dp_transfer(struct analogix_dp_device *dp,
 struct drm_dp_aux_msg *msg);
  
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c

index 005a3f7005d2..9df2f3ef000c 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -1007,7 +1007,7 @@ static ssize_t analogix_dp_get_psr_status(struct 
analogix_dp_device *dp)
  }
  
  int analogix_dp_send_psr_spd(struct analogix_dp_device *dp,

-struct edp_vsc_psr *vsc)
+struct edp_vsc_psr *vsc, bool blocking)
  {
unsigned int val;
int ret;
@@ -1053,6 +1053,9 @@ int analogix_dp_send_psr_spd(struct analogix_dp_device 
*dp,
val |= IF_EN;
writel(val, dp->reg_base + ANALOGIX_DP_PKT_SEND_CTL);
  
+	if (!blocking)

+   return 0;
+
ret = readx_poll_timeout(analogix_dp_get_psr_status, dp, psr_status,
psr_status >= 0 &&
((vsc->DB1 && psr_status == DP_PSR_SINK_ACTIVE_RFB) ||


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

Re: [PATCH v5 05/36] drm/bridge: analogix_dp: add fast link train for eDP

[Archit Taneja]

On Saturday 10 March 2018 03:52 AM, Enric Balletbo i Serra wrote:

From: zain wang 

We would meet a short black screen when exit PSR with the full link
training, In this case, we should use fast link train instead of full
link training.

Signed-off-by: zain wang 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
Signed-off-by: Enric Balletbo i Serra 
Tested-by: Marek Szyprowski 
---

  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 142 -
  drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |   3 +
  2 files changed, 114 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index ee00d3d920e0..806c3878b3d6 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -10,17 +10,18 @@
  * option) any later version.
  */
  
-#include 

-#include 
-#include 
  #include 
-#include 
+#include 
+#include 
+#include 
  #include 
+#include 
+#include 
+#include 
  #include 
  #include 
-#include 
-#include 
  #include 
+#include 


This re-ordering doesn't seem like it should be a part of this patch,
you can let it stay if it happens to cause conflicts with future
patches. Other than that:

Reviewed-by: Archit Taneja 

Thanks,
Archit

  
  #include 

  #include 
@@ -35,6 +36,8 @@
  
  #define to_dp(nm)	container_of(nm, struct analogix_dp_device, nm)
  
+static const bool verify_fast_training;

+
  struct bridge_init {
struct i2c_client *client;
struct device_node *node;
@@ -528,7 +531,7 @@ static int analogix_dp_process_equalizer_training(struct 
analogix_dp_device *dp)
  {
int lane, lane_count, retval;
u32 reg;
-   u8 link_align, link_status[2], adjust_request[2];
+   u8 link_align, link_status[2], adjust_request[2], spread;
  
  	usleep_range(400, 401);
  
@@ -571,6 +574,20 @@ static int analogix_dp_process_equalizer_training(struct analogix_dp_device *dp)

dev_dbg(dp->dev, "final lane count = %.2x\n",
dp->link_train.lane_count);
  
+		retval = drm_dp_dpcd_readb(>aux, DP_MAX_DOWNSPREAD,

+  );
+   if (retval != 1) {
+   dev_err(dp->dev, "failed to read downspread %d\n",
+   retval);
+   dp->fast_train_support = false;
+   } else {
+   dp->fast_train_support =
+   (spread & DP_NO_AUX_HANDSHAKE_LINK_TRAINING) ?
+   true : false;
+   }
+   dev_dbg(dp->dev, "fast link training %s\n",
+   dp->fast_train_support ? "supported" : "unsupported");
+
/* set enhanced mode if available */
analogix_dp_set_enhanced_mode(dp);
dp->link_train.lt_state = FINISHED;
@@ -627,10 +644,12 @@ static void analogix_dp_get_max_rx_lane_count(struct 
analogix_dp_device *dp,
*lane_count = DPCD_MAX_LANE_COUNT(data);
  }
  
-static void analogix_dp_init_training(struct analogix_dp_device *dp,

- enum link_lane_count_type max_lane,
- int max_rate)
+static int analogix_dp_full_link_train(struct analogix_dp_device *dp,
+  u32 max_lanes, u32 max_rate)
  {
+   int retval = 0;
+   bool training_finished = false;
+
/*
 * MACRO_RST must be applied after the PLL_LOCK to avoid
 * the DP inter pair skew issue for at least 10 us
@@ -656,18 +675,13 @@ static void analogix_dp_init_training(struct 
analogix_dp_device *dp,
}
  
  	/* Setup TX lane count & rate */

-   if (dp->link_train.lane_count > max_lane)
-   dp->link_train.lane_count = max_lane;
+   if (dp->link_train.lane_count > max_lanes)
+   dp->link_train.lane_count = max_lanes;
if (dp->link_train.link_rate > max_rate)
dp->link_train.link_rate = max_rate;
  
  	/* All DP analog module power up */

analogix_dp_set_analog_power_down(dp, POWER_ALL, 0);
-}
-
-static int analogix_dp_sw_link_training(struct analogix_dp_device *dp)
-{
-   int retval = 0, training_finished = 0;
  
  	dp->link_train.lt_state = START;
  
@@ -702,22 +716,88 @@ static int analogix_dp_sw_link_training(struct analogix_dp_device *dp)

return retval;
  }
  
-static int analogix_dp_set_link_train(struct analogix_dp_device *dp,

- u32 count, u32 bwtype)
+static int analogix_dp_fast_link_train(struct analogix_dp_device *dp)
  {
-   int i;
-   int retval;
+   int i, ret;
+   u8 link_align, link_status[2];
+   

[DPU PATCH 1/2] dt-bindings: msm/disp: Remove hw block offset DT entries for SDM845

[Sravanthi Kollukuduru]

Remove DT entries of hw block offsets and other target specific catalog
information for SDM845.

Signed-off-by: Sravanthi Kollukuduru 
---
 .../devicetree/bindings/display/msm/dpu.txt| 530 -
 1 file changed, 530 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/msm/dpu.txt 
b/Documentation/devicetree/bindings/display/msm/dpu.txt
index 136f0d3..90cd3e0 100644
--- a/Documentation/devicetree/bindings/display/msm/dpu.txt
+++ b/Documentation/devicetree/bindings/display/msm/dpu.txt
@@ -19,61 +19,6 @@ Required properties
 - interrupt-controller: Mark the device node as an interrupt controller.
 - #interrupt-cells: Should be one. The first cell is interrupt number.
 - iommus: Specifies the SID's used by this context bank.
-- qcom,dpu-sspp-type:  Array of strings for DPU source surface pipes 
type information.
-   A source pipe can be "vig", "rgb", "dma" or 
"cursor" type.
-   Number of xin ids defined should match the 
number of offsets
-   defined in property: qcom,dpu-sspp-off.
-- qcom,dpu-sspp-off:   Array of offset for DPU source surface pipes. 
The offsets
-   are calculated from register "mdp_phys" defined 
in
-   reg property + "dpu-off". The number of offsets 
defined here should
-   reflect the amount of pipes that can be active 
in DPU for
-   this configuration.
-- qcom,dpu-sspp-xin-id:Array of VBIF clients ids (xins) 
corresponding
-   to the respective source pipes. Number of xin 
ids
-   defined should match the number of offsets
-   defined in property: qcom,dpu-sspp-off.
-- qcom,dpu-ctl-off:Array of offset addresses for the available ctl
-   hw blocks within DPU, these offsets are
-   calculated from register "mdp_phys" defined in
-   reg property.  The number of ctl offsets defined
-   here should reflect the number of control paths
-   that can be configured concurrently on DPU for
-   this configuration.
-- qcom,dpu-wb-off: Array of offset addresses for the programmable
-   writeback blocks within DPU.
-- qcom,dpu-wb-xin-id:  Array of VBIF clients ids (xins) corresponding
-   to the respective writeback. Number of xin ids
-   defined should match the number of offsets
-   defined in property: qcom,dpu-wb-off.
-- qcom,dpu-mixer-off:  Array of offset addresses for the available
-   mixer blocks that can drive data to panel
-   interfaces. These offsets are be calculated from
-   register "mdp_phys" defined in reg property.
-   The number of offsets defined should reflect the
-   amount of mixers that can drive data to a panel
-   interface.
-- qcom,dpu-dspp-top-off:   Offset address for the dspp top block.
-   The offset is calculated from register 
"mdp_phys"
-   defined in reg property.
-- qcom,dpu-dspp-off:   Array of offset addresses for the available dspp
-   blocks. These offsets are calculated from
-   register "mdp_phys" defined in reg property.
-- qcom,dpu-pp-off: Array of offset addresses for the available
-   pingpong blocks. These offsets are calculated
-   from register "mdp_phys" defined in reg 
property.
-- qcom,dpu-pp-slave:   Array of flags indicating whether each ping pong
-   block may be configured as a pp slave.
-- qcom,dpu-intf-off:   Array of offset addresses for the available DPU
-   interface blocks that can drive data to a
-   panel controller. The offsets are calculated
-   from "mdp_phys" defined in reg property. The 
number
-   of offsets defined should reflect the number of
-   programmable interface blocks available in 
hardware.
-- qcom,dpu-mixer-blend-op-off  Array of offset addresses for the available
-   blending stages. The offsets are relative to
-   qcom,dpu-mixer-off.
-- qcom,dpu-mixer-pair-mask Array of mixer numbers that can be paired with
-  

[DPU PATCH 0/2] Add hardware catalog information in driver source for SDM845

[Sravanthi Kollukuduru]

This patch series aims at adding the target specific hardware
catalog information in driver source.
As a result, the current logic of dt based parsing is removed.

The DT clean up patch corresponding to this driver change will
be posted separately.

Sravanthi Kollukuduru (2):
  dt-bindings: msm/disp: Remove hw block offset DT entries for SDM845
  drm/msm: Add hardware catalog file for SDM845

 .../devicetree/bindings/display/msm/dpu.txt|  530 
 drivers/gpu/drm/msm/Makefile   |1 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 3071 +---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h |   17 +-
 .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog_sdm845.c  |  744 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c|2 +-
 6 files changed, 767 insertions(+), 3598 deletions(-)
 create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog_sdm845.c

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

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

[PATCH libdrm] tests/exynos: remove dead condition

[Seung-Woo Kim]

There is already condition checking input values between 2 and 4096
so condition checking 0 is always false. Remove the dead condition.

Signed-off-by: Seung-Woo Kim 
---
 tests/exynos/exynos_fimg2d_perf.c |7 ---
 1 files changed, 0 insertions(+), 7 deletions(-)

diff --git a/tests/exynos/exynos_fimg2d_perf.c 
b/tests/exynos/exynos_fimg2d_perf.c
index a2d5c19..97691a7 100644
--- a/tests/exynos/exynos_fimg2d_perf.c
+++ b/tests/exynos/exynos_fimg2d_perf.c
@@ -274,13 +274,6 @@ int main(int argc, char **argv)
goto out;
}
 
-   if (bufw == 0 || bufh == 0) {
-   fprintf(stderr, "error: buffer width/height should be 
non-zero.\n");
-   ret = -1;
-
-   goto out;
-   }
-
fd = drmOpen("exynos", NULL);
if (fd < 0) {
fprintf(stderr, "error: failed to open drm\n");
-- 
1.7.4.1

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

Re: [PATCH v5 03/36] drm/bridge: analogix_dp: Don't change psr while bridge is disabled

[Archit Taneja]

On Saturday 10 March 2018 03:52 AM, Enric Balletbo i Serra wrote:

From: zain wang 

There is a race between AUX CH bring-up and enabling bridge which will
cause link training to fail. To avoid hitting it, don't change psr state
while enabling the bridge.


Reviewed-by: Archit Taneja 


Cc: Tomeu Vizoso 
Cc: Sean Paul 
Signed-off-by: zain wang 
Signed-off-by: Caesar Wang 
[seanpaul fixed up the commit message a bit and renamed *_supported to 
*_enabled]
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
Signed-off-by: Enric Balletbo i Serra 
Tested-by: Marek Szyprowski 
---

  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 15 ---
  drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  2 +-
  drivers/gpu/drm/rockchip/analogix_dp-rockchip.c|  2 +-
  include/drm/bridge/analogix_dp.h   |  2 +-
  4 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index e738aa6de1af..ee00d3d920e0 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -98,18 +98,18 @@ static int analogix_dp_detect_hpd(struct analogix_dp_device 
*dp)
return 0;
  }
  
-int analogix_dp_psr_supported(struct analogix_dp_device *dp)

+int analogix_dp_psr_enabled(struct analogix_dp_device *dp)
  {
  
-	return dp->psr_support;

+   return dp->psr_enable;
  }
-EXPORT_SYMBOL_GPL(analogix_dp_psr_supported);
+EXPORT_SYMBOL_GPL(analogix_dp_psr_enabled);
  
  int analogix_dp_enable_psr(struct analogix_dp_device *dp)

  {
struct edp_vsc_psr psr_vsc;
  
-	if (!dp->psr_support)

+   if (!dp->psr_enable)
return 0;
  
  	/* Prepare VSC packet as per EDP 1.4 spec, Table 6.9 */

@@ -131,7 +131,7 @@ int analogix_dp_disable_psr(struct analogix_dp_device *dp)
struct edp_vsc_psr psr_vsc;
int ret;
  
-	if (!dp->psr_support)

+   if (!dp->psr_enable)
return 0;
  
  	/* Prepare VSC packet as per EDP 1.4 spec, Table 6.9 */

@@ -871,8 +871,8 @@ static void analogix_dp_commit(struct analogix_dp_device 
*dp)
/* Enable video */
analogix_dp_start_video(dp);
  
-	dp->psr_support = analogix_dp_detect_sink_psr(dp);

-   if (dp->psr_support)
+   dp->psr_enable = analogix_dp_detect_sink_psr(dp);
+   if (dp->psr_enable)
analogix_dp_enable_sink_psr(dp);
  }
  
@@ -1117,6 +1117,7 @@ static void analogix_dp_bridge_disable(struct drm_bridge *bridge)

if (ret)
DRM_ERROR("failed to setup the panel ret = %d\n", ret);
  
+	dp->psr_enable = false;

dp->dpms_mode = DRM_MODE_DPMS_OFF;
  }
  
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h

index b039b28d8fcc..e135a42cb19e 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -170,7 +170,7 @@ struct analogix_dp_device {
int dpms_mode;
int hpd_gpio;
boolforce_hpd;
-   boolpsr_support;
+   boolpsr_enable;
  
  	struct mutex		panel_lock;

boolpanel_is_modeset;
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 36334839a3f8..3e8bf79bea58 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -82,7 +82,7 @@ static void analogix_dp_psr_set(struct drm_encoder *encoder, 
bool enabled)
struct rockchip_dp_device *dp = to_dp(encoder);
int ret;
  
-	if (!analogix_dp_psr_supported(dp->adp))

+   if (!analogix_dp_psr_enabled(dp->adp))
return;
  
  	DRM_DEV_DEBUG(dp->dev, "%s PSR...\n", enabled ? "Entry" : "Exit");

diff --git a/include/drm/bridge/analogix_dp.h b/include/drm/bridge/analogix_dp.h
index 711fff9b6803..e9a1116d2f8e 100644
--- a/include/drm/bridge/analogix_dp.h
+++ b/include/drm/bridge/analogix_dp.h
@@ -41,7 +41,7 @@ struct analogix_dp_plat_data {
 struct drm_connector *);
  };
  
-int analogix_dp_psr_supported(struct analogix_dp_device *dp);

+int analogix_dp_psr_enabled(struct analogix_dp_device *dp);
  int analogix_dp_enable_psr(struct analogix_dp_device *dp);
  int analogix_dp_disable_psr(struct analogix_dp_device *dp);
  


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

Re: [PATCH v5 01/36] drm/bridge: analogix_dp: detect Sink PSR state after configuring the PSR

[Archit Taneja]

On Saturday 10 March 2018 03:52 AM, Enric Balletbo i Serra wrote:

From: Yakir Yang 

Make sure the request PSR state takes effect in analogix_dp_send_psr_spd()
function, or print the sink PSR error state if we failed to apply the
requested PSR setting.


Reviewed-by: Archit Taneja 



Cc: 征增 王 
Cc: Stéphane Marchesin 
Signed-off-by: Yakir Yang 
[seanpaul changed timeout loop to a readx poll]
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
Signed-off-by: Enric Balletbo i Serra 
Tested-by: Marek Szyprowski 
---

  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |  6 ++--
  drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  6 ++--
  drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  | 35 +++---
  3 files changed, 37 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index a693ab3078f0..e738aa6de1af 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -122,8 +122,7 @@ int analogix_dp_enable_psr(struct analogix_dp_device *dp)
psr_vsc.DB0 = 0;
psr_vsc.DB1 = EDP_VSC_PSR_STATE_ACTIVE | EDP_VSC_PSR_CRC_VALUES_VALID;
  
-	analogix_dp_send_psr_spd(dp, _vsc);

-   return 0;
+   return analogix_dp_send_psr_spd(dp, _vsc);
  }
  EXPORT_SYMBOL_GPL(analogix_dp_enable_psr);
  
@@ -149,8 +148,7 @@ int analogix_dp_disable_psr(struct analogix_dp_device *dp)

if (ret != 1)
dev_err(dp->dev, "Failed to set DP Power0 %d\n", ret);
  
-	analogix_dp_send_psr_spd(dp, _vsc);

-   return 0;
+   return analogix_dp_send_psr_spd(dp, _vsc);
  }
  EXPORT_SYMBOL_GPL(analogix_dp_disable_psr);
  
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h

index 5c6a28806129..b039b28d8fcc 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -20,6 +20,8 @@
  #define MAX_CR_LOOP 5
  #define MAX_EQ_LOOP 5
  
+#define DP_TIMEOUT_PSR_LOOP_MS			300

+
  /* DP_MAX_LANE_COUNT */
  #define DPCD_ENHANCED_FRAME_CAP(x)(((x) >> 7) & 0x1)
  #define DPCD_MAX_LANE_COUNT(x)((x) & 0x1f)
@@ -247,8 +249,8 @@ void analogix_dp_config_video_slave_mode(struct 
analogix_dp_device *dp);
  void analogix_dp_enable_scrambling(struct analogix_dp_device *dp);
  void analogix_dp_disable_scrambling(struct analogix_dp_device *dp);
  void analogix_dp_enable_psr_crc(struct analogix_dp_device *dp);
-void analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
- struct edp_vsc_psr *vsc);
+int analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
+struct edp_vsc_psr *vsc);
  ssize_t analogix_dp_transfer(struct analogix_dp_device *dp,
 struct drm_dp_aux_msg *msg);
  
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c

index 303083ad28e3..005a3f7005d2 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -10,10 +10,11 @@
   * option) any later version.
   */
  
-#include 

-#include 
  #include 
+#include 
  #include 
+#include 
+#include 
  
  #include 
  
@@ -992,10 +993,25 @@ void analogix_dp_enable_psr_crc(struct analogix_dp_device *dp)

writel(PSR_VID_CRC_ENABLE, dp->reg_base + ANALOGIX_DP_CRC_CON);
  }
  
-void analogix_dp_send_psr_spd(struct analogix_dp_device *dp,

- struct edp_vsc_psr *vsc)
+static ssize_t analogix_dp_get_psr_status(struct analogix_dp_device *dp)
+{
+   ssize_t val;
+   u8 status;
+
+   val = drm_dp_dpcd_readb(>aux, DP_PSR_STATUS, );
+   if (val < 0) {
+   dev_err(dp->dev, "PSR_STATUS read failed ret=%zd", val);
+   return val;
+   }
+   return status;
+}
+
+int analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
+struct edp_vsc_psr *vsc)
  {
unsigned int val;
+   int ret;
+   ssize_t psr_status;
  
  	/* don't send info frame */

val = readl(dp->reg_base + ANALOGIX_DP_PKT_SEND_CTL);
@@ -1036,6 +1052,17 @@ void analogix_dp_send_psr_spd(struct analogix_dp_device 
*dp,
val = readl(dp->reg_base + ANALOGIX_DP_PKT_SEND_CTL);
val |= IF_EN;
writel(val, dp->reg_base + ANALOGIX_DP_PKT_SEND_CTL);
+
+   ret = readx_poll_timeout(analogix_dp_get_psr_status, dp, psr_status,
+   psr_status >= 0 &&
+   ((vsc->DB1 && psr_status == DP_PSR_SINK_ACTIVE_RFB) ||
+   (!vsc->DB1 && psr_status == DP_PSR_SINK_INACTIVE)), 1500,
+  

[Bug 102905] [R600] Miscompilation of TGSI to VLIW causes artifacts in Gallium Nine with Crysis2 bump mapping

[bugzilla-daemon]

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

Roland Scheidegger  changed:

   What|Removed |Added

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

--- Comment #5 from Roland Scheidegger  ---
Fixed by 274f8bf05ef526d65f01614313dda65bc7ec7a87.
Thanks for the analysis! (the code wasn't really all that difficult after
that...)

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

[Bug 104037] [drm] GPU HANG: ecode 9:0:0x87f9bffb, in Xorg [1688], reason: Hang on rcs0, action: reset

[bugzilla-daemon]

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

--- Comment #1 from sh...@mcewan.id.au ---
Created attachment 138087
  --> https://bugs.freedesktop.org/attachment.cgi?id=138087=edit
Content of /sys/class/drm/card0/error

I'm also getting this exact error. I was running XScreensaver at the time. I
think the `rubikblocks` GL hack was running.

Ubuntu 17.10 4.13.0-36-generic
OpenGL version string: 3.0 Mesa 17.2.8
Lenovo ThinkPad X1 Carbon 4th Gen
Intel(R) Core(TM) i5-6300U CPU @ 2.40GHz
eDP-1 connected primary 2560x1440+0+1440
HDMI-2 connected 2560x1440+0+0

filename:  
/lib/modules/4.13.0-36-generic/kernel/drivers/gpu/drm/i915/i915.ko
license:GPL and additional rights
description:Intel Graphics
author: Intel Corporation
author: Tungsten Graphics, Inc.
firmware:   i915/bxt_dmc_ver1_07.bin
firmware:   i915/skl_dmc_ver1_26.bin
firmware:   i915/kbl_dmc_ver1_01.bin
firmware:   i915/skl_guc_ver6_1.bin
firmware:   i915/kbl_huc_ver02_00_1810.bin
firmware:   i915/bxt_huc_ver01_07_1398.bin
firmware:   i915/skl_huc_ver01_07_1398.bin
srcversion: F27B28CF28ECAE28997AF44

-- 
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 100726] [REGRESSION][BISECTED] Severe flickering with an R9 290

[bugzilla-daemon]

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

--- Comment #9 from hiwatari.se...@gmail.com ---
My last try of bisecting the error. I'm pretty sure I've got the correct commit
this time. I first ran 4 Weeks on the 4.9-rc1 without the error ever appearing,
upgraded to one or two release candidates higher, rebooted and instantly had
the error. I then did the bisecting in this window, waiting 3-4 Weeks for the
error to appear per commit, before flagging the kernel as ok.

Git then tells me, that 5f7f8f6edbf860abf18149a64be036d4be5e2993 is the first
bad commit.
I will attach the new bisect log. I don't know if the error might already have
been fixed, since I've been months on this ancient version. But I will try that
in the following weeks.

-- 
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 100726] [REGRESSION][BISECTED] Severe flickering with an R9 290

[bugzilla-daemon]

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

--- Comment #10 from hiwatari.se...@gmail.com ---
Created attachment 138086
  --> https://bugs.freedesktop.org/attachment.cgi?id=138086=edit
Bisect Log 3

-- 
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: [GIT PULL] omapdrm changes for v4.17

[Dave Airlie]

On 7 March 2018 at 18:27, Tomi Valkeinen  wrote:
> Hi Dave,
>
> Please pull omapdrm changes for v4.17.

Hi Tomi,

Sorry for delay, pulled this it broken my ARM build

/home/airlied/devel/kernel/drm-next/drivers/gpu/drm/omapdrm/dss/dss.c:
In function ‘dss_probe’:
/home/airlied/devel/kernel/drm-next/drivers/gpu/drm/omapdrm/dss/dss.c:1474:10:
error: ‘dss_debug_dump_clocks’ undeclared (first use in this
function); did you mean ‘dispc_dump_clocks’?
  dss_debug_dump_clocks, dss);
  ^
  dispc_dump_clocks
/home/airlied/devel/kernel/drm-next/drivers/gpu/drm/omapdrm/dss/dss.c:1474:10:
note: each undeclared identifier is reported only once for each
function it appears in
make[6]: *** [/home/airlied/devel/kernel/drm-next/scripts/Makefile.build:316:
drivers/gpu/drm/omapdrm/dss/dss.o] Error 1

Looks like a per-config, please push a fix on top and resend the pull req.

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

[RFC PATCH] drm/xen-front: xen_drm_front_platform_info can be static

[kbuild test robot]

Fixes: db81084f9084 ("drm/xen-front: Add support for Xen PV display frontend")
Signed-off-by: Fengguang Wu 
---
 xen_drm_front.c |2 +-
 xen_drm_front_drv.c |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/xen/xen_drm_front.c 
b/drivers/gpu/drm/xen/xen_drm_front.c
index dbabdf9..f421d23 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.c
+++ b/drivers/gpu/drm/xen/xen_drm_front.c
@@ -417,7 +417,7 @@ static int xen_drm_drv_remove(struct platform_device *pdev)
return xen_drm_front_drv_remove(pdev);
 }
 
-struct platform_device_info xen_drm_front_platform_info = {
+static struct platform_device_info xen_drm_front_platform_info = {
.name = XENDISPL_DRIVER_NAME,
.id = 0,
.num_res = 0,
diff --git a/drivers/gpu/drm/xen/xen_drm_front_drv.c 
b/drivers/gpu/drm/xen/xen_drm_front_drv.c
index 3edefa2..04ee389 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_drv.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_drv.c
@@ -122,7 +122,7 @@ static const struct vm_operations_struct xen_drm_vm_ops = {
.close  = drm_gem_vm_close,
 };
 
-struct drm_driver xen_drm_driver = {
+static struct drm_driver xen_drm_driver = {
.driver_features   = DRIVER_GEM | DRIVER_MODESET |
 DRIVER_PRIME | DRIVER_ATOMIC,
.lastclose = lastclose,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH RESEND v2 1/2] drm/xen-front: Add support for Xen PV display frontend

[kbuild test robot]

Hi Oleksandr,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on v4.16-rc5 next-20180313]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Oleksandr-Andrushchenko/drm-xen-front-Add-support-for-Xen-PV-display-frontend/20180314-014856
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

>> drivers/gpu/drm/xen/xen_drm_front.c:420:29: sparse: symbol 
>> 'xen_drm_front_platform_info' was not declared. Should it be static?
--
>> drivers/gpu/drm/xen/xen_drm_front_drv.c:125:19: sparse: symbol 
>> 'xen_drm_driver' was not declared. Should it be static?

Please review and possibly fold the followup patch.

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

Re: [DPU PATCH 02/11] drm/msm: Don't duplicate modeset_enables atomic helper

[Jeykumar Sankaran]

On 2018-03-12 13:21, Sean Paul wrote:

On Thu, Mar 08, 2018 at 04:56:01PM -0800, Jeykumar Sankaran wrote:

On 2018-02-28 11:18, Sean Paul wrote:
> Instead, shuffle things around so we kickoff crtc after enabling

encoder

> during modesets. Also moves the vblank wait to after the frame.
>
> Change-Id: I16c7b7f9390d04f6050aa20e17a5335fbf49eba3
> Signed-off-by: Sean Paul 
> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c|   9 ++
>  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c |   5 +-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c |  31 -
>  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h |   2 +
>  drivers/gpu/drm/msm/msm_atomic.c| 132

+---

>  5 files changed, 48 insertions(+), 131 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> index a3ab6ed2bf1d..94fab2dcca5b 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> @@ -3525,6 +3525,12 @@ static void dpu_crtc_enable(struct drm_crtc
> *crtc,
>DPU_EVT32_VERBOSE(DRMID(crtc));
>dpu_crtc = to_dpu_crtc(crtc);
>
> +  if (msm_is_mode_seamless(>state->adjusted_mode) ||
> +  msm_is_mode_seamless_vrr(>state->adjusted_mode)) {
> +  DPU_DEBUG("Skipping crtc enable, seamless mode\n");
> +  return;
> +  }
> +
>pm_runtime_get_sync(crtc->dev->dev);
>
>drm_for_each_encoder(encoder, crtc->dev) {
> @@ -3572,6 +3578,9 @@ static void dpu_crtc_enable(struct drm_crtc

*crtc,

>DPU_POWER_EVENT_POST_ENABLE | DPU_POWER_EVENT_POST_DISABLE
> |
>DPU_POWER_EVENT_PRE_DISABLE,
>dpu_crtc_handle_power_event, crtc, dpu_crtc->name);
> +
> +  if (msm_needs_vblank_pre_modeset(>state->adjusted_mode))
> +  drm_crtc_wait_one_vblank(crtc);
>  }
>
>  struct plane_state {
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> index 28ceb589ee40..4d1e3652dbf4 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> @@ -3693,8 +3693,11 @@ static void

dpu_encoder_frame_done_timeout(struct

> timer_list *t)
>  static const struct drm_encoder_helper_funcs dpu_encoder_helper_funcs

=

> {
>.mode_set = dpu_encoder_virt_mode_set,
>.disable = dpu_encoder_virt_disable,
> -  .enable = dpu_encoder_virt_enable,
> +  .enable = dpu_kms_encoder_enable,
>.atomic_check = dpu_encoder_virt_atomic_check,
> +
> +  /* This is called by dpu_kms_encoder_enable */
> +  .commit = dpu_encoder_virt_enable,
>  };
>
>  static const struct drm_encoder_funcs dpu_encoder_funcs = {
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> index 81fd3a429e9f..3d83037e8305 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> @@ -425,14 +425,37 @@ static void dpu_kms_prepare_commit(struct

msm_kms

> *kms,
>dpu_encoder_prepare_commit(encoder);
>  }
>
> -static void dpu_kms_commit(struct msm_kms *kms,
> -  struct drm_atomic_state *old_state)
> +/*
> + * Override the encoder enable since we need to setup the inline
> rotator
> and do
> + * some crtc magic before enabling any bridge that might be present.
> + */
> +void dpu_kms_encoder_enable(struct drm_encoder *encoder)
> +{
> +  const struct drm_encoder_helper_funcs *funcs =
> encoder->helper_private;
> +  struct drm_crtc *crtc = encoder->crtc;
> +
> +  /* Forward this enable call to the commit hook */
> +  if (funcs && funcs->commit)
> +  funcs->commit(encoder);

The purpose of this function is not clear. Where are we setting up the
inline rotator?
Why do we need a kickoff here?


The reason the code is shuffled is to avoid duplicating the entire 
atomic

helper
function. By moving calls into the ->enable hooks, we can avoid having 
to

hand
roll the helpers.

The kickoff is preserved from the helper copy when you call
kms->funcs->commit
in between the encoder enable and bridge enable. If this can be 
removed,

that'd
be even better. I was simply trying to preserve the call order of
everything.

Sean
I am with you on cleaning up the atomic helper copy. But using 
enc->commit helper

to call into encoder_enable doesn't look valid to me.

Also, I verified removing the kms->funcs->commit call between encoder 
enable and
bridge enable. It works fine with your newly placed kms->funcs->commit 
after
drm_atomic_helper_commit_modeset_enables. So can you revisit this 
function?


Jeykumar S



> +
> +  if (crtc && crtc->state->active) {
> +  DPU_EVT32(DRMID(crtc));
> +  dpu_crtc_commit_kickoff(crtc);
> +  }
> +}
> +
> +static void dpu_kms_commit(struct msm_kms *kms, struct

drm_atomic_state

> *state)
>  {
>struct drm_crtc *crtc;
> -  struct drm_crtc_state *old_crtc_state;
> +  struct drm_crtc_state *crtc_state;
> +  struct dpu_crtc_state *cstate;
>int i;
>
> -  

[PATCH v5] drm_hwcomposer: Add platformhisi buffer importer for hikey and hikey960

[John Stultz]

This allows for importing buffers allocated from the
hikey and hikey960 gralloc implementations.

Cc: Marissa Wall 
Cc: Sean Paul 
Cc: Dmitry Shmidt 
Cc: Robert Foss 
Cc: Matt Szczesiak 
Cc: Liviu Dudau 
Cc: David Hanna 
Cc: Rob Herring 
Cc: Alexandru-Cosmin Gheorghe 
Cc: Alistair Strachan 
Acked-by: Robert Foss 
Signed-off-by: John Stultz 
---
v2:
* Make platformhisi and the generic importer exclusive in the
  build
* Fixup vendor check
v3:
* Unify format conversions
* Subclass the platformdrmgeneric importer implementation to
  reduce code duplication
* Rework to avoid board specific logic (tweak gralloc to be
  consistent between the two)
v4:
* Minor cleanups as suggested by Alexandru-Cosmin Gheorghe
v5:
* Minor spelling fix in commit message noticed by Robert Foss
---
 Android.mk   |  13 +
 platformdrmgeneric.h |   2 +-
 platformhisi.cpp | 135 +++
 platformhisi.h   |  48 ++
 4 files changed, 197 insertions(+), 1 deletion(-)
 create mode 100644 platformhisi.cpp
 create mode 100644 platformhisi.h

diff --git a/Android.mk b/Android.mk
index 8b11e37..1add286 100644
--- a/Android.mk
+++ b/Android.mk
@@ -75,7 +75,20 @@ LOCAL_CPPFLAGS += \
-DHWC2_USE_CPP11 \
-DHWC2_INCLUDE_STRINGIFICATION
 
+
+ifeq ($(TARGET_PRODUCT),hikey960)
+LOCAL_CPPFLAGS += -DUSE_HISI_IMPORTER
+LOCAL_SRC_FILES += platformhisi.cpp
+LOCAL_C_INCLUDES += device/linaro/hikey/gralloc960/
+else
+ifeq ($(TARGET_PRODUCT),hikey)
+LOCAL_CPPFLAGS += -DUSE_HISI_IMPORTER
+LOCAL_SRC_FILES += platformhisi.cpp
+LOCAL_C_INCLUDES += device/linaro/hikey/gralloc/
+else
 LOCAL_CPPFLAGS += -DUSE_DRM_GENERIC_IMPORTER
+endif
+endif
 
 LOCAL_MODULE := hwcomposer.drm
 LOCAL_MODULE_TAGS := optional
diff --git a/platformdrmgeneric.h b/platformdrmgeneric.h
index 8376580..fbe059b 100644
--- a/platformdrmgeneric.h
+++ b/platformdrmgeneric.h
@@ -35,8 +35,8 @@ class DrmGenericImporter : public Importer {
   int ImportBuffer(buffer_handle_t handle, hwc_drm_bo_t *bo) override;
   int ReleaseBuffer(hwc_drm_bo_t *bo) override;
 
- private:
   uint32_t ConvertHalFormatToDrm(uint32_t hal_format);
+ private:
 
   DrmResources *drm_;
 
diff --git a/platformhisi.cpp b/platformhisi.cpp
new file mode 100644
index 000..16c5e6f
--- /dev/null
+++ b/platformhisi.cpp
@@ -0,0 +1,135 @@
+/*
+ * Copyright (C) 2015 The Android Open Source Project
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+#define LOG_TAG "hwc-platform-hisi"
+
+#include "drmresources.h"
+#include "platform.h"
+#include "platformhisi.h"
+
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include "gralloc_priv.h"
+
+
+namespace android {
+
+Importer *Importer::CreateInstance(DrmResources *drm) {
+  HisiImporter *importer = new HisiImporter(drm);
+  if (!importer)
+return NULL;
+
+  int ret = importer->Init();
+  if (ret) {
+ALOGE("Failed to initialize the hisi importer %d", ret);
+delete importer;
+return NULL;
+  }
+  return importer;
+}
+
+HisiImporter::HisiImporter(DrmResources *drm) : DrmGenericImporter(drm), 
drm_(drm) {
+}
+
+HisiImporter::~HisiImporter() {
+}
+
+int HisiImporter::Init() {
+  int ret = hw_get_module(GRALLOC_HARDWARE_MODULE_ID,
+  (const hw_module_t **)_);
+  if (ret) {
+ALOGE("Failed to open gralloc module %d", ret);
+return ret;
+  }
+
+  if (strcasecmp(gralloc_->common.author, "ARM Ltd."))
+ALOGW("Using non-ARM gralloc module: %s/%s\n", gralloc_->common.name,
+  gralloc_->common.author);
+
+  return 0;
+}
+
+EGLImageKHR HisiImporter::ImportImage(EGLDisplay egl_display, buffer_handle_t 
handle) {
+  private_handle_t const *hnd = reinterpret_cast < private_handle_t const 
*>(handle);
+  if (!hnd)
+return NULL;
+
+  EGLint fmt = ConvertHalFormatToDrm(hnd->req_format);
+  if (fmt < 0)
+   return NULL;
+
+  EGLint attr[] = {
+EGL_WIDTH, hnd->width,
+EGL_HEIGHT, hnd->height,
+EGL_LINUX_DRM_FOURCC_EXT, fmt,
+EGL_DMA_BUF_PLANE0_FD_EXT, hnd->share_fd,
+EGL_DMA_BUF_PLANE0_OFFSET_EXT, 0,
+EGL_DMA_BUF_PLANE0_PITCH_EXT, hnd->byte_stride,
+EGL_NONE,
+  };
+  return 

[Bug 105463] [r600g] 4210 piglit failures, 55 crashes, 14 warnings on ppc (PCIe, ppc64, mesa-18.0.0_rc4)

[bugzilla-daemon]

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

--- Comment #6 from erhar...@mailbox.org ---
Created attachment 138085
  --> https://bugs.freedesktop.org/attachment.cgi?id=138085=edit
html summary from 'pigllit run all' with LLVM

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

Re: [PATCH v3 1/5] drm/i915: Move DP modeset retry work into intel_dp

[Lyude Paul]

On Mon, 2018-03-12 at 23:01 +0200, Ville Syrjälä wrote:
> On Fri, Mar 09, 2018 at 04:32:27PM -0500, Lyude Paul wrote:
> > While having the modeset_retry_work in intel_connector makes sense with
> > SST, this paradigm doesn't make a whole ton of sense when it comes to
> > MST since we have to deal with multiple connectors. In most cases, it's
> > more useful to just use the intel_dp struct since it indicates whether
> > or not we're dealing with an MST device, along with being able to easily
> > trace the intel_dp struct back to it's respective connector (if there is
> > any). So, move the modeset_retry_work function out of the
> > intel_connector struct and into intel_dp.
> > 
> > Signed-off-by: Lyude Paul 
> > Reviewed-by: Manasi Navare 
> > Cc: Manasi Navare 
> > Cc: Ville Syrjälä 
> > 
> > V2:
> >  - Remove accidental duplicate modeset_retry_work in intel_connector
> > V3:
> >  - Also check against eDP in intel_hpd_poll_fini() - mdnavare
> > Signed-off-by: Lyude Paul 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c  | 25 +++-
> > -
> >  drivers/gpu/drm/i915/intel_dp.c   | 10 --
> >  drivers/gpu/drm/i915/intel_dp_link_training.c |  2 +-
> >  drivers/gpu/drm/i915/intel_drv.h  |  6 +++---
> >  4 files changed, 31 insertions(+), 12 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index f424fff477f6..3b7fa430a84a 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -15394,16 +15394,37 @@ static void intel_hpd_poll_fini(struct drm_device
> > *dev)
> >  {
> > struct intel_connector *connector;
> > struct drm_connector_list_iter conn_iter;
> > +   struct work_struct *work;
> > +   int conn_type;
> >  
> > /* Kill all the work that may have been queued by hpd. */
> > drm_connector_list_iter_begin(dev, _iter);
> > for_each_intel_connector_iter(connector, _iter) {
> > -   if (connector->modeset_retry_work.func)
> > -   cancel_work_sync(>modeset_retry_work);
> > if (connector->hdcp_shim) {
> > cancel_delayed_work_sync(
> > >hdcp_check_work);
> > cancel_work_sync(>hdcp_prop_work);
> > }
> > +
> > +   conn_type = connector->base.connector_type;
> > +   if (conn_type != DRM_MODE_CONNECTOR_eDP &&
> > +   conn_type != DRM_MODE_CONNECTOR_DisplayPort)
> > +   continue;
> > +
> > +   if (connector->mst_port) {
> > +   work = >mst_port->modeset_retry_work;
> > +   } else {
> > +   struct intel_encoder *intel_encoder =
> > +   connector->encoder;
> > +   struct intel_dp *intel_dp;
> > +
> > +   if (!intel_encoder)
> > +   continue;
> > +
> > +   intel_dp = enc_to_intel_dp(_encoder->base);
> > +   work = _dp->modeset_retry_work;
> > +   }
> > +
> > +   cancel_work_sync(work);
> 
> Why are we even walking the connectors for this? Can't we just
> walk the encoders instead?
We could walk the encoders for this, but seeing as we're already walking the
connectors for the HDCP prop doesn't it make more sense to just stick our code
there? or is there a simpler solution for this I'm missing
> 
> > }
> > drm_connector_list_iter_end(_iter);
> >  }
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 4dd1b2287dd6..5abf0c95725a 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -6261,12 +6261,10 @@ static bool intel_edp_init_connector(struct intel_dp
> > *intel_dp,
> >  
> >  static void intel_dp_modeset_retry_work_fn(struct work_struct *work)
> >  {
> > -   struct intel_connector *intel_connector;
> > -   struct drm_connector *connector;
> > +   struct intel_dp *intel_dp = container_of(work, typeof(*intel_dp),
> > +modeset_retry_work);
> > +   struct drm_connector *connector = _dp->attached_connector-
> > >base;
> >  
> > -   intel_connector = container_of(work, typeof(*intel_connector),
> > -  modeset_retry_work);
> > -   connector = _connector->base;
> > DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n", connector->base.id,
> >   connector->name);
> >  
> > @@ -6295,7 +6293,7 @@ intel_dp_init_connector(struct intel_digital_port
> > *intel_dig_port,
> > int type;
> >  
> > /* Initialize the work for modeset in case of link train failure */
> > -   INIT_WORK(_connector->modeset_retry_work,
> > +   INIT_WORK(_dp->modeset_retry_work,
> >   intel_dp_modeset_retry_work_fn);
> >  
> > if 

Re: [PATCH v3 2/5] drm/i915: Only use one link bw config for MST topologies

[Lyude Paul]

On Mon, 2018-03-12 at 13:45 -0700, Manasi Navare wrote:
> On Fri, Mar 09, 2018 at 04:32:28PM -0500, Lyude Paul wrote:
> > When a DP MST link needs retraining, sometimes the hub will detect that
> > the current link bw config is impossible and will update it's RX caps in
> > the DPCD to reflect the new maximum link rate. Currently, we make the
> > assumption that the RX caps in the dpcd will never change like this.
> > This means if the sink changes it's RX caps after we've already set up
> > an MST link and we attempt to add or remove another sink from the
> > topology, we could put ourselves into an invalid state where we've tried
> > to configure different sinks on the same MST topology with different
> > link rates. We could also run into this situation if a sink reports a
> > higher link rate after suspend, usually from us having trained it with a
> > fallback bw configuration before suspending.
> > 
> > So: "lock" the bw config by only using the max DP link rate/lane count
> > on the first modeset for an MST topology. For every modeset following,
> > we instead use the last configured link bw for this topology. We only
> > unlock the bw config when we've detected a new MST sink.
> > 
> 
> Just a nit here on commit message about where we unlock the link bw. So we
> also unlock it
> meaning set the mst_link_bw_locked to false when we read the dpcd again
> and obtain the fallback values since at that time the RX cap could have
> changed and so we do unlock the link_bw so that during retraining it reads
> the new max link rate and lane count during the mst compute config.
> Isnt that the case or am I missing something here?
I'm not sure I understand what you mean, are you talking about how we unlock the
link bw when retraining fails and we decide to fallback? If so, that's probably
something we should just mention in the patch that implements the actual
retraining as opposed to this patch.
> 
> Manasi
> 
> > Signed-off-by: Lyude Paul 
> > Cc: Manasi Navare 
> > Cc: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c | 11 +--
> >  drivers/gpu/drm/i915/intel_dp_mst.c | 22 +++---
> >  drivers/gpu/drm/i915/intel_drv.h|  6 ++
> >  3 files changed, 30 insertions(+), 9 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 5abf0c95725a..5645a194de92 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -3871,18 +3871,25 @@ intel_dp_can_mst(struct intel_dp *intel_dp)
> >  static void
> >  intel_dp_configure_mst(struct intel_dp *intel_dp)
> >  {
> > +   bool was_mst;
> > +
> > if (!i915_modparams.enable_dp_mst)
> > return;
> >  
> > if (!intel_dp->can_mst)
> > return;
> >  
> > +   was_mst = intel_dp->is_mst;
> > intel_dp->is_mst = intel_dp_can_mst(intel_dp);
> >  
> > -   if (intel_dp->is_mst)
> > +   if (intel_dp->is_mst) {
> > DRM_DEBUG_KMS("Sink is MST capable\n");
> > -   else
> > +
> > +   if (!was_mst)
> > +   intel_dp->mst_bw_locked = false;
> > +   } else {
> > DRM_DEBUG_KMS("Sink is not MST capable\n");
> > +   }
> >  
> > drm_dp_mst_topology_mgr_set_mst(_dp->mst_mgr,
> > intel_dp->is_mst);
> > diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
> > b/drivers/gpu/drm/i915/intel_dp_mst.c
> > index c3de0918ee13..c0553456b18e 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> > @@ -42,7 +42,7 @@ static bool intel_dp_mst_compute_config(struct
> > intel_encoder *encoder,
> > to_intel_connector(conn_state->connector);
> > struct drm_atomic_state *state = pipe_config->base.state;
> > int bpp;
> > -   int lane_count, slots;
> > +   int lane_count, link_rate, slots;
> > const struct drm_display_mode *adjusted_mode = _config-
> > >base.adjusted_mode;
> > int mst_pbn;
> > bool reduce_m_n = drm_dp_has_quirk(_dp->desc,
> > @@ -56,16 +56,22 @@ static bool intel_dp_mst_compute_config(struct
> > intel_encoder *encoder,
> >   bpp);
> > }
> > /*
> > -* for MST we always configure max link bw - the spec doesn't
> > -* seem to suggest we should do otherwise.
> > +* for MST we always configure max link bw if we don't know better
> > -
> > +* the spec doesn't seem to suggest we should do otherwise. But,
> > +* ensure it always stays consistent with the rest of this hub's
> > +* state.
> >  */
> > -   lane_count = intel_dp_max_lane_count(intel_dp);
> > +   if (intel_dp->mst_bw_locked) {
> > +   lane_count = intel_dp->lane_count;
> > +   link_rate = intel_dp->link_rate;
> > +   } else {
> > +   lane_count = intel_dp_max_lane_count(intel_dp);
> > +   link_rate = intel_dp_max_link_rate(intel_dp);
> > +   }
> >  
> > 

[Bug 105463] [r600g] 4210 piglit failures, 55 crashes, 14 warnings on ppc (PCIe, ppc64, mesa-18.0.0_rc4)

[bugzilla-daemon]

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

--- Comment #5 from erhar...@mailbox.org ---
Created attachment 138084
  --> https://bugs.freedesktop.org/attachment.cgi?id=138084=edit
results from 'pigllit run all' with LLVM

-- 
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/panel: rm68200: add backlight dependency

[Thierry Reding]

On Tue, Mar 13, 2018 at 09:59:54PM +0100, Arnd Bergmann wrote:
> Like many other panel drivers, this one fails to build
> when backlight support is disabled:
> 
> drivers/gpu/drm/panel/panel-raydium-rm68200.o: In function `rm68200_probe':
> panel-raydium-rm68200.c:(.text+0x14a): undefined reference to 
> `devm_of_find_backlight'
> 
> This adds the appropriate dependency.
> 
> Fixes: 2b7ed18bed1a ("drm/panel: Add support for Raydium RM68200 panel 
> driver")
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/gpu/drm/panel/Kconfig | 1 +
>  1 file changed, 1 insertion(+)

This shouldn't be necessary. include/linux/backlight.h defines a stub if
the backlight class is not enabled.

What tree are you seeing this on?

Thierry


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

Re: [PATCH v3 00/10] splash screen on the stm32f769 disco board

[Thierry Reding]

On Tue, Mar 13, 2018 at 04:23:10PM +0100, Daniel Vetter wrote:
> On Tue, Mar 13, 2018 at 02:49:59PM +0100, yannick fertre wrote:
> > Version 3:
> > - Replace some pr_error, pr_warn or pr_info by dev_error, dev_warn & 
> > dev_info.
> > - Refresh stm32f769-disco_defconfig with last modification done on 
> > v2018.3-rc4.
> > - rework include files ordering.
> > 
> > Version 2:
> > - Replace debug log by pr_error, pr_warn or pr_info.
> > - Rework bridge between ltdc & dsi panel
> > - Rework backligh management (with or witout gpio)
> > - Rework panel otm8009a
> > - Add new panel raydium rm68200
> > 
> > Version 1:
> > - Initial commit
> > 
> > This serie contains all patchsets needed for displaying a splash screen 
> > on the stm32f769 disco board.
> > A new config has been created configs/stm32f769-disco_defconfig.
> > This is necessary due to the difference of panels between stm32f769-disco &
> > stm32f746-disco boards.
> 
> Shouldn't we patch the drivers/gpu/drm/stm driver instead of the
> drivers/video one? fbdev is kinda a dead end and not for adding new hw
> support ...

This is confusing, but by the looks of it this is code for U-Boot
display support and has nothing to do with the Linux kernel. I don't
know why dri-devel was on Cc.

Yannick, it's not customary to cross-post U-Boot display drivers to
Linux mailing lists, unless there's some need to coordinate or discuss
across the boundaries (for example if you were proposing a way to do
seamless handover from U-Boot to kernel). If you do cross-post, perhaps
make sure to mark these patches as targetting U-Boot to avoid confusion.

Thierry


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

[Bug 105463] [r600g] 4210 piglit failures, 55 crashes, 14 warnings on ppc (PCIe, ppc64, mesa-18.0.0_rc4)

[bugzilla-daemon]

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

--- Comment #4 from erhar...@mailbox.org ---
Same setup but with mesa built with LLVM support:

# ./piglit run -s all results/OpenGL_all_llvm
Skipping GL_ARB_gpu_shader_fp64 tests
[54211/54211] skip: 30608, pass: 20471, warn: 15, fail: 3044, crash: 73   
Thank you for running Piglit!  
Results have been written to /root/build/piglit/results/OpenGL_all_llvm

$ glxinfo | grep -i opengl
OpenGL vendor string: X.Org
OpenGL renderer string: AMD CAICOS (DRM 2.49.0 / 4.9.87-gentoo, LLVM 5.0.1)
OpenGL core profile version string: 3.2 (Core Profile) Mesa 18.0.0-rc4
OpenGL core profile shading language version string: 1.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 18.0.0-rc4
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.1 Mesa 18.0.0-rc4
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10
OpenGL ES profile extensions:

-- 
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: Reduce object size of DRM_ERROR and DRM_DEBUG uses

[Joe Perches]

drm_printk is used for both DRM_ERROR and DRM_DEBUG with unnecessary
arguments that can be removed by creating separate functins.

Create specific functions for these calls to reduce x86/64 defconfig
size by ~20k.

Modify the existing macros to use the specific calls.

new:
$ size -t drivers/gpu/drm/built-in.a | tail -1
1876562   44542 995 1922099  1d5433 (TOTALS)

old:
$ size -t drivers/gpu/drm/built-in.a | tail -1
1897565   44542 995 1943102  1da63e (TOTALS)

Miscellanea:

o intel_display requires a change to use the specific calls.

Signed-off-by: Joe Perches 
---
 drivers/gpu/drm/drm_print.c  | 28 +---
 drivers/gpu/drm/i915/intel_display.c | 15 ---
 include/drm/drm_print.h  | 27 ++-
 3 files changed, 39 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index 781518fd88e3..79abf6d5b4db 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -89,23 +89,37 @@ void drm_dev_printk(const struct device *dev, const char 
*level,
 }
 EXPORT_SYMBOL(drm_dev_printk);
 
-void drm_printk(const char *level, unsigned int category,
-   const char *format, ...)
+void drm_dbg(unsigned int category, const char *format, ...)
 {
struct va_format vaf;
va_list args;
 
-   if (category != DRM_UT_NONE && !(drm_debug & category))
+   if (!(drm_debug & category))
return;
 
va_start(args, format);
vaf.fmt = format;
vaf.va = 
 
-   printk("%s" "[" DRM_NAME ":%ps]%s %pV",
-  level, __builtin_return_address(0),
-  strcmp(level, KERN_ERR) == 0 ? " *ERROR*" : "", );
+   printk(KERN_DEBUG "[" DRM_NAME ":%ps] %pV",
+  __builtin_return_address(0), );
+
+   va_end(args);
+}
+EXPORT_SYMBOL(drm_dbg);
+
+void drm_err(const char *format, ...)
+{
+   struct va_format vaf;
+   va_list args;
+
+   va_start(args, format);
+   vaf.fmt = format;
+   vaf.va = 
+
+   printk(KERN_ERR "[" DRM_NAME ":%ps] *ERROR* %pV",
+  __builtin_return_address(0), );
 
va_end(args);
 }
-EXPORT_SYMBOL(drm_printk);
+EXPORT_SYMBOL(drm_err);
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 2933ad38094f..d8e522e3cd39 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11059,24 +11059,17 @@ intel_compare_link_m_n(const struct intel_link_m_n 
*m_n,
 static void __printf(3, 4)
 pipe_config_err(bool adjust, const char *name, const char *format, ...)
 {
-   char *level;
-   unsigned int category;
struct va_format vaf;
va_list args;
 
-   if (adjust) {
-   level = KERN_DEBUG;
-   category = DRM_UT_KMS;
-   } else {
-   level = KERN_ERR;
-   category = DRM_UT_NONE;
-   }
-
va_start(args, format);
vaf.fmt = format;
vaf.va = 
 
-   drm_printk(level, category, "mismatch in %s %pV", name, );
+   if (adjust)
+   drm_dbg(DRM_UT_KMS, "mismatch in %s %pV", name, );
+   else
+   drm_err("mismatch in %s %pV", name, );
 
va_end(args);
 }
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index 2a4a42e59a47..3a40c5a3a5fa 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -200,9 +200,10 @@ __printf(6, 7)
 void drm_dev_printk(const struct device *dev, const char *level,
unsigned int category, const char *function_name,
const char *prefix, const char *format, ...);
-__printf(3, 4)
-void drm_printk(const char *level, unsigned int category,
-   const char *format, ...);
+__printf(2, 3)
+void drm_dbg(unsigned int category, const char *format, ...);
+__printf(1, 2)
+void drm_err(const char *format, ...);
 
 /* Macros to make printk easier */
 
@@ -236,7 +237,7 @@ void drm_printk(const char *level, unsigned int category,
drm_dev_printk(dev, KERN_ERR, DRM_UT_NONE, __func__, " *ERROR*",\
   fmt, ##__VA_ARGS__)
 #define DRM_ERROR(fmt, ...)\
-   drm_printk(KERN_ERR, DRM_UT_NONE, fmt,  ##__VA_ARGS__)
+   drm_err(fmt, ##__VA_ARGS__)
 
 /**
  * Rate limited error output.  Like DRM_ERROR() but won't flood the log.
@@ -279,40 +280,40 @@ void drm_printk(const char *level, unsigned int category,
drm_dev_printk(dev, KERN_DEBUG, DRM_UT_CORE, __func__, "", fmt, \
   ##args)
 #define DRM_DEBUG(fmt, ...)\
-   drm_printk(KERN_DEBUG, DRM_UT_CORE, fmt, ##__VA_ARGS__)
+   drm_dbg(DRM_UT_CORE, fmt, ##__VA_ARGS__)
 
 #define DRM_DEV_DEBUG_DRIVER(dev, fmt, args...)
\
drm_dev_printk(dev, KERN_DEBUG, DRM_UT_DRIVER, __func__, "",\
   fmt, 

[PATCH] drm/panel: rm68200: add backlight dependency

[Arnd Bergmann]

Like many other panel drivers, this one fails to build
when backlight support is disabled:

drivers/gpu/drm/panel/panel-raydium-rm68200.o: In function `rm68200_probe':
panel-raydium-rm68200.c:(.text+0x14a): undefined reference to 
`devm_of_find_backlight'

This adds the appropriate dependency.

Fixes: 2b7ed18bed1a ("drm/panel: Add support for Raydium RM68200 panel driver")
Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/panel/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 077bc58c1913..25682ff3449a 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -112,6 +112,7 @@ config DRM_PANEL_RAYDIUM_RM68200
tristate "Raydium RM68200 720x1280 DSI video mode panel"
depends on OF
depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
help
  Say Y here if you want to enable support for Raydium RM68200
  720x1280 DSI video mode panel.
-- 
2.9.0

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

Re: [PATCH v3 00/10] splash screen on the stm32f769 disco board

[Brian Norris]

On Tue, Mar 13, 2018 at 1:50 PM, Anatolij Gustschin  wrote:
> On Tue, 13 Mar 2018 16:23:10 +0100
> Daniel Vetter dan...@ffwll.ch wrote:
> ...
>> Shouldn't we patch the drivers/gpu/drm/stm driver instead of the
>> drivers/video one? fbdev is kinda a dead end and not for adding new hw
>> support ...
>
> this patch series adds display driver to U-Boot project, I don't know
> why it was submitted to the Linux kernel and dri-devel mailing lists.
>
> Yannick, please don't send this to linux-kernel and dri-devel lists
> and also please don't Cc kernel developers when resubmitting the
> patch series.

I couldn't agree more! I mentioned this on the previous confusing post
(where I had the same objection as Daniel, before realizing this was
just a poorly-documented, ill-targeted U-Boot patch series).

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

[PATCH v4 1/5] drm/blend: Add a generic alpha property

[Maxime Ripard]

Some drivers duplicate the logic to create a property to store a per-plane
alpha.

This is especially useful if we ever want to support extra protocols for
Wayland like:
https://lists.freedesktop.org/archives/wayland-devel/2017-August/034741.html

Let's create a helper in order to move that to the core.

Cc: Laurent Pinchart 
Reviewed-by: Boris Brezillon 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/drm_atomic.c|  4 +++-
 drivers/gpu/drm/drm_atomic_helper.c |  4 +++-
 drivers/gpu/drm/drm_blend.c | 38 ++-
 include/drm/drm_blend.h |  3 ++-
 include/drm/drm_plane.h |  6 +-
 5 files changed, 55 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 34b7d420e555..39204c88d2c5 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -753,6 +753,8 @@ static int drm_atomic_plane_set_property(struct drm_plane 
*plane,
state->src_w = val;
} else if (property == config->prop_src_h) {
state->src_h = val;
+   } else if (property == plane->alpha_property) {
+   state->alpha = val;
} else if (property == plane->rotation_property) {
if (!is_power_of_2(val & DRM_MODE_ROTATE_MASK))
return -EINVAL;
@@ -818,6 +820,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
*val = state->src_w;
} else if (property == config->prop_src_h) {
*val = state->src_h;
+   } else if (property == plane->alpha_property) {
+   *val = state->alpha;
} else if (property == plane->rotation_property) {
*val = state->rotation;
} else if (property == plane->zpos_property) {
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 00c78c1c9681..ac4c3f18a0b1 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3484,6 +3484,10 @@ void drm_atomic_helper_plane_reset(struct drm_plane 
*plane)
if (plane->state) {
plane->state->plane = plane;
plane->state->rotation = DRM_MODE_ROTATE_0;
+
+   /* Reset the alpha value to fully opaque if it matters */
+   if (plane->alpha_property)
+   plane->state->alpha = plane->alpha_property->values[1];
}
 }
 EXPORT_SYMBOL(drm_atomic_helper_plane_reset);
diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
index 5a81e1b4c076..05eda2d57c77 100644
--- a/drivers/gpu/drm/drm_blend.c
+++ b/drivers/gpu/drm/drm_blend.c
@@ -88,6 +88,12 @@
  * On top of this basic transformation additional properties can be exposed by
  * the driver:
  *
+ * alpha:
+ * Alpha is setup with drm_plane_create_alpha_property(). It controls the
+ * plane-wide opacity, from transparent (0) to opaque (0x). It can be
+ * combined with pixel alpha.
+ * The alpha value is represented as premultiplied alpha.
+ *
  * rotation:
  * Rotation is set up with drm_plane_create_rotation_property(). It adds a
  * rotation and reflection step between the source and destination 
rectangles.
@@ -106,6 +112,38 @@
  */
 
 /**
+ * drm_plane_create_alpha_property - create a new alpha property
+ * @plane: drm plane
+ *
+ * This function creates a generic, mutable, alpha property and enables support
+ * for it in the DRM core. It is attached to @plane.
+ *
+ * The alpha property will be allowed to be within the bounds of 0
+ * (transparent) to 0x (opaque).
+ *
+ * Returns:
+ * 0 on success, negative error code on failure.
+ */
+int drm_plane_create_alpha_property(struct drm_plane *plane)
+{
+   struct drm_property *prop;
+
+   prop = drm_property_create_range(plane->dev, 0, "alpha",
+0, DRM_BLEND_ALPHA_OPAQUE);
+   if (!prop)
+   return -ENOMEM;
+
+   drm_object_attach_property(>base, prop, DRM_BLEND_ALPHA_OPAQUE);
+   plane->alpha_property = prop;
+
+   if (plane->state)
+   plane->state->alpha = DRM_BLEND_ALPHA_OPAQUE;
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_plane_create_alpha_property);
+
+/**
  * drm_plane_create_rotation_property - create a new rotation property
  * @plane: drm plane
  * @rotation: initial value of the rotation property
diff --git a/include/drm/drm_blend.h b/include/drm/drm_blend.h
index 17606026590b..330c561c4c11 100644
--- a/include/drm/drm_blend.h
+++ b/include/drm/drm_blend.h
@@ -36,6 +36,9 @@ static inline bool drm_rotation_90_or_270(unsigned int 
rotation)
return rotation & (DRM_MODE_ROTATE_90 | DRM_MODE_ROTATE_270);
 }
 
+#define DRM_BLEND_ALPHA_OPAQUE 0x
+
+int drm_plane_create_alpha_property(struct drm_plane *plane);
 int drm_plane_create_rotation_property(struct drm_plane *plane,

[PATCH v4 2/5] drm/atmel-hclcdc: Convert to the new generic alpha property

[Maxime Ripard]

Now that we have support for per-plane alpha in the core, let's use it.

Acked-by: Boris Brezillon 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h| 13 +---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 89 ++
 2 files changed, 14 insertions(+), 88 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
index ab32d5b268d2..60c937f42114 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
@@ -299,7 +299,6 @@ struct atmel_hlcdc_layer {
 struct atmel_hlcdc_plane {
struct drm_plane base;
struct atmel_hlcdc_layer layer;
-   struct atmel_hlcdc_plane_properties *properties;
 };
 
 static inline struct atmel_hlcdc_plane *
@@ -346,18 +345,6 @@ struct atmel_hlcdc_dc_desc {
 };
 
 /**
- * Atmel HLCDC Plane properties.
- *
- * This structure stores plane property definitions.
- *
- * @alpha: alpha blending (or transparency) property
- * @rotation: rotation property
- */
-struct atmel_hlcdc_plane_properties {
-   struct drm_property *alpha;
-};
-
-/**
  * Atmel HLCDC Display Controller.
  *
  * @desc: HLCDC Display Controller description
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
index e18800ed7cd1..73c875db45f4 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
@@ -31,7 +31,6 @@
  * @src_y: y buffer position
  * @src_w: buffer width
  * @src_h: buffer height
- * @alpha: alpha blending of the plane
  * @disc_x: x discard position
  * @disc_y: y discard position
  * @disc_w: discard width
@@ -54,8 +53,6 @@ struct atmel_hlcdc_plane_state {
uint32_t src_w;
uint32_t src_h;
 
-   u8 alpha;
-
int disc_x;
int disc_y;
int disc_w;
@@ -385,7 +382,7 @@ atmel_hlcdc_plane_update_general_settings(struct 
atmel_hlcdc_plane *plane,
cfg |= ATMEL_HLCDC_LAYER_LAEN;
else
cfg |= ATMEL_HLCDC_LAYER_GAEN |
-  ATMEL_HLCDC_LAYER_GA(state->alpha);
+  ATMEL_HLCDC_LAYER_GA(state->base.alpha >> 8);
}
 
if (state->disc_h && state->disc_w)
@@ -553,7 +550,7 @@ atmel_hlcdc_plane_prepare_disc_area(struct drm_crtc_state 
*c_state)
 
if (!ovl_s->fb ||
ovl_s->fb->format->has_alpha ||
-   ovl_state->alpha != 255)
+   ovl_s->alpha != DRM_BLEND_ALPHA_OPAQUE)
continue;
 
/* TODO: implement a smarter hidden area detection */
@@ -829,51 +826,18 @@ static void atmel_hlcdc_plane_destroy(struct drm_plane *p)
drm_plane_cleanup(p);
 }
 
-static int atmel_hlcdc_plane_atomic_set_property(struct drm_plane *p,
-struct drm_plane_state *s,
-struct drm_property *property,
-uint64_t val)
-{
-   struct atmel_hlcdc_plane *plane = drm_plane_to_atmel_hlcdc_plane(p);
-   struct atmel_hlcdc_plane_properties *props = plane->properties;
-   struct atmel_hlcdc_plane_state *state =
-   drm_plane_state_to_atmel_hlcdc_plane_state(s);
-
-   if (property == props->alpha)
-   state->alpha = val;
-   else
-   return -EINVAL;
-
-   return 0;
-}
-
-static int atmel_hlcdc_plane_atomic_get_property(struct drm_plane *p,
-   const struct drm_plane_state *s,
-   struct drm_property *property,
-   uint64_t *val)
-{
-   struct atmel_hlcdc_plane *plane = drm_plane_to_atmel_hlcdc_plane(p);
-   struct atmel_hlcdc_plane_properties *props = plane->properties;
-   const struct atmel_hlcdc_plane_state *state =
-   container_of(s, const struct atmel_hlcdc_plane_state, base);
-
-   if (property == props->alpha)
-   *val = state->alpha;
-   else
-   return -EINVAL;
-
-   return 0;
-}
-
-static int atmel_hlcdc_plane_init_properties(struct atmel_hlcdc_plane *plane,
-   struct atmel_hlcdc_plane_properties *props)
+static int atmel_hlcdc_plane_init_properties(struct atmel_hlcdc_plane *plane)
 {
const struct atmel_hlcdc_layer_desc *desc = plane->layer.desc;
 
if (desc->type == ATMEL_HLCDC_OVERLAY_LAYER ||
-   desc->type == ATMEL_HLCDC_CURSOR_LAYER)
-   drm_object_attach_property(>base.base,
-  props->alpha, 255);
+   desc->type == ATMEL_HLCDC_CURSOR_LAYER) {
+   int ret;
+
+   ret = drm_plane_create_alpha_property(>base);
+ 

[PATCH v4 5/5] drm/docs: Remove the rcar alpha from the csv file

[Maxime Ripard]

Now that we moved the rcar-du DRM driver has been switched to the generic
alpha property, remove the former property documentation from the
deperecated CSV file.

Signed-off-by: Maxime Ripard 
---
 Documentation/gpu/kms-properties.csv | 1 -
 1 file changed, 1 deletion(-)

diff --git a/Documentation/gpu/kms-properties.csv 
b/Documentation/gpu/kms-properties.csv
index 6b28b014cb7d..07ed22ea3bd6 100644
--- a/Documentation/gpu/kms-properties.csv
+++ b/Documentation/gpu/kms-properties.csv
@@ -98,5 +98,4 @@ radeon,DVI-I,“coherent”,RANGE,"Min=0, Max=1",Connector,TBD
 ,,"""underscan vborder""",RANGE,"Min=0, Max=128",Connector,TBD
 ,Audio,“audio”,ENUM,"{ ""off"", ""on"", ""auto"" }",Connector,TBD
 ,FMT Dithering,“dither”,ENUM,"{ ""off"", ""on"" }",Connector,TBD
-rcar-du,Generic,"""alpha""",RANGE,"Min=0, Max=255",Plane,TBD
 ,,"""colorkey""",RANGE,"Min=0, Max=0x01ff",Plane,TBD
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 0/5] drm/blend: Support generic plane-wide alpha

[Maxime Ripard]

Hi,

This serie aims at enhancing the support for plane-wide alpha in the
drivers that are implementing it at the moment, by turning it into a
generic property and converting the drivers (rcar-du and atmel-hclcdc). It
also introduces support for it in the sun4i driver.

Let me know what you think,
Maxime

Changes from v3:
  - Rebased on current drm-misc-next

  - Made the alpha property a 16 bits property, and have the drivers
drop the lowest 8 bits
  - Removed the csv documentation, and documented it in the doc instead

Changes from v2:
  - Rebased on current drm-misc-next
  - Removed the patches already applied
  - Split the patch implementing the automatic pipe assignment in two

Changes from v1:
  - Document the behaviour on concurrent usage of the alpha property and an
alpha component in the format
  - Allowed for higher alpha values
  - Moved the alpha value from a helper to the struct drm_format_info
  - Collected tags
  - Rebased on current drm-misc-next

Maxime Ripard (5):
  drm/blend: Add a generic alpha property
  drm/atmel-hclcdc: Convert to the new generic alpha property
  drm/rcar-du: Convert to the new generic alpha property
  drm/sun4i: Add support for plane alpha
  drm/docs: Remove the rcar alpha from the csv file

 Documentation/gpu/kms-properties.csv|  1 +-
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h| 13 +---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 89 ++
 drivers/gpu/drm/drm_atomic.c|  4 +-
 drivers/gpu/drm/drm_atomic_helper.c |  4 +-
 drivers/gpu/drm/drm_blend.c | 38 -
 drivers/gpu/drm/rcar-du/rcar_du_drv.h   |  1 +-
 drivers/gpu/drm/rcar-du/rcar_du_kms.c   |  5 +-
 drivers/gpu/drm/rcar-du/rcar_du_plane.c | 15 +--
 drivers/gpu/drm/rcar-du/rcar_du_plane.h |  2 +-
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c   | 42 +
 drivers/gpu/drm/rcar-du/rcar_du_vsp.h   |  2 +-
 drivers/gpu/drm/sun4i/sun4i_backend.c   | 16 ++-
 drivers/gpu/drm/sun4i/sun4i_backend.h   |  3 +-
 drivers/gpu/drm/sun4i/sun4i_layer.c |  2 +-
 include/drm/drm_blend.h |  3 +-
 include/drm/drm_plane.h |  6 +-
 17 files changed, 96 insertions(+), 150 deletions(-)

base-commit: 9c936b12f15019b38edb5f8bae77bb5b0046d1b7
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 4/5] drm/sun4i: Add support for plane alpha

[Maxime Ripard]

Our backend supports a per-plane alpha property. Support it through our new
helper.

Reviewed-by: Chen-Yu Tsai 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/sun4i_backend.c | 16 +---
 drivers/gpu/drm/sun4i/sun4i_backend.h |  3 +++
 drivers/gpu/drm/sun4i/sun4i_layer.c   |  2 ++
 3 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c 
b/drivers/gpu/drm/sun4i/sun4i_backend.c
index 092ade4ff6a5..98cd4a8a93ed 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -186,6 +186,15 @@ int sun4i_backend_update_layer_formats(struct 
sun4i_backend *backend,
DRM_DEBUG_DRIVER("Switching display backend interlaced mode %s\n",
 interlaced ? "on" : "off");
 
+   val = SUN4I_BACKEND_ATTCTL_REG0_LAY_GLBALPHA(state->alpha >> 8);
+   if (state->alpha != DRM_BLEND_ALPHA_OPAQUE)
+   val |= SUN4I_BACKEND_ATTCTL_REG0_LAY_GLBALPHA_EN;
+   regmap_update_bits(backend->engine.regs,
+  SUN4I_BACKEND_ATTCTL_REG0(layer),
+  SUN4I_BACKEND_ATTCTL_REG0_LAY_GLBALPHA_MASK |
+  SUN4I_BACKEND_ATTCTL_REG0_LAY_GLBALPHA_EN,
+  val);
+
ret = sun4i_backend_drm_format_to_layer(fb->format->format, );
if (ret) {
DRM_DEBUG_DRIVER("Invalid format\n");
@@ -359,7 +368,7 @@ static int sun4i_backend_atomic_check(struct sunxi_engine 
*engine,
DRM_DEBUG_DRIVER("Plane FB format is %s\n",
 drm_get_format_name(fb->format->format,
 _name));
-   if (fb->format->has_alpha)
+   if (fb->format->has_alpha || (plane_state->alpha != 
DRM_BLEND_ALPHA_OPAQUE))
num_alpha_planes++;
 
DRM_DEBUG_DRIVER("Plane zpos is %d\n",
@@ -412,7 +421,8 @@ static int sun4i_backend_atomic_check(struct sunxi_engine 
*engine,
}
 
/* We can't have an alpha plane at the lowest position */
-   if (plane_states[0]->fb->format->has_alpha)
+   if (plane_states[0]->fb->format->has_alpha ||
+   (plane_states[0]->alpha != DRM_BLEND_ALPHA_OPAQUE))
return -EINVAL;
 
for (i = 1; i < num_planes; i++) {
@@ -424,7 +434,7 @@ static int sun4i_backend_atomic_check(struct sunxi_engine 
*engine,
 * The only alpha position is the lowest plane of the
 * second pipe.
 */
-   if (fb->format->has_alpha)
+   if (fb->format->has_alpha || (p_state->alpha != 
DRM_BLEND_ALPHA_OPAQUE))
current_pipe++;
 
s_state->pipe = current_pipe;
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.h 
b/drivers/gpu/drm/sun4i/sun4i_backend.h
index 52e77591186a..03294d5dd1a2 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.h
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.h
@@ -68,11 +68,14 @@
 #define SUN4I_BACKEND_CKMIN_REG0x884
 #define SUN4I_BACKEND_CKCFG_REG0x888
 #define SUN4I_BACKEND_ATTCTL_REG0(l)   (0x890 + (0x4 * (l)))
+#define SUN4I_BACKEND_ATTCTL_REG0_LAY_GLBALPHA_MASKGENMASK(31, 24)
+#define SUN4I_BACKEND_ATTCTL_REG0_LAY_GLBALPHA(x)  ((x) << 24)
 #define SUN4I_BACKEND_ATTCTL_REG0_LAY_PIPESEL_MASK BIT(15)
 #define SUN4I_BACKEND_ATTCTL_REG0_LAY_PIPESEL(x)   ((x) << 15)
 #define SUN4I_BACKEND_ATTCTL_REG0_LAY_PRISEL_MASK  GENMASK(11, 10)
 #define SUN4I_BACKEND_ATTCTL_REG0_LAY_PRISEL(x)((x) << 
10)
 #define SUN4I_BACKEND_ATTCTL_REG0_LAY_VDOENBIT(1)
+#define SUN4I_BACKEND_ATTCTL_REG0_LAY_GLBALPHA_EN  BIT(0)
 
 #define SUN4I_BACKEND_ATTCTL_REG1(l)   (0x8a0 + (0x4 * (l)))
 #define SUN4I_BACKEND_ATTCTL_REG1_LAY_HSCAFCT  GENMASK(15, 14)
diff --git a/drivers/gpu/drm/sun4i/sun4i_layer.c 
b/drivers/gpu/drm/sun4i/sun4i_layer.c
index 33ad377569ec..cf7857b8ac5c 100644
--- a/drivers/gpu/drm/sun4i/sun4i_layer.c
+++ b/drivers/gpu/drm/sun4i/sun4i_layer.c
@@ -37,6 +37,7 @@ static void sun4i_backend_layer_reset(struct drm_plane *plane)
if (state) {
plane->state = >state;
plane->state->plane = plane;
+   plane->state->alpha = DRM_BLEND_ALPHA_OPAQUE;
plane->state->zpos = layer->id;
}
 }
@@ -163,6 +164,7 @@ static struct sun4i_layer *sun4i_layer_init_one(struct 
drm_device *drm,
 _backend_layer_helper_funcs);
layer->backend = backend;
 
+   drm_plane_create_alpha_property(>plane);
drm_plane_create_zpos_property(>plane, 0, 0,
   SUN4I_BACKEND_NUM_LAYERS - 1);
 
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org

[PATCH v4 3/5] drm/rcar-du: Convert to the new generic alpha property

[Maxime Ripard]

Now that we have support for per-plane alpha in the core, let's use it.

Reviewed-by: Laurent Pinchart 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/rcar-du/rcar_du_drv.h   |  1 +-
 drivers/gpu/drm/rcar-du/rcar_du_kms.c   |  5 +---
 drivers/gpu/drm/rcar-du/rcar_du_plane.c | 15 +++--
 drivers/gpu/drm/rcar-du/rcar_du_plane.h |  2 +-
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c   | 42 ++
 drivers/gpu/drm/rcar-du/rcar_du_vsp.h   |  2 +-
 6 files changed, 9 insertions(+), 58 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
index f400fde65a0c..dad87d449ef7 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
@@ -90,7 +90,6 @@ struct rcar_du_device {
struct rcar_du_vsp vsps[RCAR_DU_MAX_VSPS];
 
struct {
-   struct drm_property *alpha;
struct drm_property *colorkey;
} props;
 
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 566d1a948c8f..e1b5a7b460cc 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -417,11 +417,6 @@ static int rcar_du_encoders_init(struct rcar_du_device 
*rcdu)
 
 static int rcar_du_properties_init(struct rcar_du_device *rcdu)
 {
-   rcdu->props.alpha =
-   drm_property_create_range(rcdu->ddev, 0, "alpha", 0, 255);
-   if (rcdu->props.alpha == NULL)
-   return -ENOMEM;
-
/*
 * The color key is expressed as an RGB888 triplet stored in a 32-bit
 * integer in XRGB format. Bit 24 is used as a flag to disable (0)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c 
b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
index 68556bd9dad2..c20f7ed48c8d 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
@@ -423,7 +423,7 @@ static void rcar_du_plane_setup_mode(struct rcar_du_group 
*rgrp,
rcar_du_plane_write(rgrp, index, PnALPHAR, PnALPHAR_ABIT_0);
else
rcar_du_plane_write(rgrp, index, PnALPHAR,
-   PnALPHAR_ABIT_X | state->alpha);
+   PnALPHAR_ABIT_X | state->state.alpha >> 8);
 
pnmr = PnMR_BM_MD | state->format->pnmr;
 
@@ -692,11 +692,11 @@ static void rcar_du_plane_reset(struct drm_plane *plane)
 
state->hwindex = -1;
state->source = RCAR_DU_PLANE_MEMORY;
-   state->alpha = 255;
state->colorkey = RCAR_DU_COLORKEY_NONE;
state->state.zpos = plane->type == DRM_PLANE_TYPE_PRIMARY ? 0 : 1;
 
plane->state = >state;
+   plane->state->alpha = DRM_BLEND_ALPHA_OPAQUE;
plane->state->plane = plane;
 }
 
@@ -708,9 +708,7 @@ static int rcar_du_plane_atomic_set_property(struct 
drm_plane *plane,
struct rcar_du_plane_state *rstate = to_rcar_plane_state(state);
struct rcar_du_device *rcdu = to_rcar_plane(plane)->group->dev;
 
-   if (property == rcdu->props.alpha)
-   rstate->alpha = val;
-   else if (property == rcdu->props.colorkey)
+   if (property == rcdu->props.colorkey)
rstate->colorkey = val;
else
return -EINVAL;
@@ -726,9 +724,7 @@ static int rcar_du_plane_atomic_get_property(struct 
drm_plane *plane,
container_of(state, const struct rcar_du_plane_state, state);
struct rcar_du_device *rcdu = to_rcar_plane(plane)->group->dev;
 
-   if (property == rcdu->props.alpha)
-   *val = rstate->alpha;
-   else if (property == rcdu->props.colorkey)
+   if (property == rcdu->props.colorkey)
*val = rstate->colorkey;
else
return -EINVAL;
@@ -797,10 +793,9 @@ int rcar_du_planes_init(struct rcar_du_group *rgrp)
continue;
 
drm_object_attach_property(>plane.base,
-  rcdu->props.alpha, 255);
-   drm_object_attach_property(>plane.base,
   rcdu->props.colorkey,
   RCAR_DU_COLORKEY_NONE);
+   drm_plane_create_alpha_property(>plane);
drm_plane_create_zpos_property(>plane, 1, 1, 7);
}
 
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.h 
b/drivers/gpu/drm/rcar-du/rcar_du_plane.h
index 890321b4665d..5c19c69e4691 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_plane.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.h
@@ -50,7 +50,6 @@ static inline struct rcar_du_plane *to_rcar_plane(struct 
drm_plane *plane)
  * @state: base DRM plane state
  * @format: information about the pixel format used by the plane
  * @hwindex: 0-based hardware plane index, -1 means unused
- * @alpha: value of the plane alpha property
  * @colorkey: value of the plane colorkey property
  */
 struct 

Re: [PATCH v3 1/6] cgroup: Allow registration and lookup of cgroup private data

[Tejun Heo]

Hello, Matt.

cc'ing Roman and Alexei.

On Tue, Mar 06, 2018 at 03:46:55PM -0800, Matt Roper wrote:
> There are cases where other parts of the kernel may wish to store data
> associated with individual cgroups without building a full cgroup
> controller.  Let's add interfaces to allow them to register and lookup
> this private data for individual cgroups.
> 
> A kernel system (e.g., a driver) that wishes to register private data
> for a cgroup will do so by subclassing the 'struct cgroup_priv'
> structure to describe the necessary data to store.  Before registering a
> private data structure to a cgroup, the caller should fill in the 'key'
> and 'free' fields of the base cgroup_priv structure.
> 
>  * 'key' should be a unique void* that will act as a key for future
>privdata lookups/removals.  Note that this allows drivers to store
>per-device private data for a cgroup by using a device pointer as a key.
> 
>  * 'free' should be a function pointer to a function that may be used
>to destroy the private data.  This function will be called
>automatically if the underlying cgroup is destroyed.

This feature turned out to have more users than I originally
anticipated and bpf also wants something like this to track network
states.  The requirements are pretty similar but not quite the same.
The extra requirements are...

* Lookup must be really cheap.  Probably using pointer hash or walking
  list isn't great, so maybe idr based lookup + RCU protected index
  table per cgroup?

* It should support both regular memory and percpu pointers.  Given
  that what cgroup does is pretty much cgroup:key -> pointer lookup,
  it's mostly about getting the interface right so that it's not too
  error-prone.

Sorry about moving the goalpost.

Thanks.

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

Re: [PATCH v3 3/6] cgroup: Introduce cgroup_permission()

[Tejun Heo]

On Tue, Mar 06, 2018 at 03:46:57PM -0800, Matt Roper wrote:
> Non-controller kernel subsystems may base access restrictions for
> cgroup-related syscalls/ioctls on a process' access to the cgroup.
> Let's make it easy for other parts of the kernel to check these cgroup
> permissions.

I'm not sure about pulling in cgroup perms this way because cgroup
access perms have more to it than the file and directory permissions.
Can't this be restricted to root or some CAP?

Thanks.

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

Re: [PATCH v3 2/6] cgroup: Introduce task_get_dfl_cgroup()

[Tejun Heo]

(cc'ing Roman)

Hello,

On Tue, Mar 06, 2018 at 03:46:56PM -0800, Matt Roper wrote:
> +static inline struct cgroup *
> +task_get_dfl_cgroup(struct task_struct *task)
> +{
> + struct cgroup *cgrp;
> +
> + mutex_lock(_mutex);
> + cgrp = task_dfl_cgroup(task);
> + cgroup_get(cgrp);
> + mutex_unlock(_mutex);

Heh, this is super heavy.  Can't we do "rcu, try get, compare &
retry"?

Thanks.

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

[Bug 102905] [R600] Miscompilation of TGSI to VLIW causes artifacts in Gallium Nine with Crysis2 bump mapping

[bugzilla-daemon]

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

--- Comment #4 from i...@yahoo.com ---
(In reply to Roland Scheidegger from comment #3)
> I've just sent a patch to mesa-dev which should
> fix this, can you verify it works?

Yes it works nicely.

Can't wait to see the patch in git master. :)

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

Re: [Intel-gfx] [PATCH] [v2] drm/i915/pmu: avoid -Wmaybe-uninitialized warning

[Arnd Bergmann]

On Tue, Mar 13, 2018 at 6:46 PM, Tvrtko Ursulin
 wrote:
>
> On 13/03/2018 16:19, Arnd Bergmann wrote:
>>
>> The conditional spinlock confuses gcc into thinking the 'flags' value
>> might contain uninitialized data:
>>
>> drivers/gpu/drm/i915/i915_pmu.c: In function '__i915_pmu_event_read':
>> arch/x86/include/asm/paravirt_types.h:573:3: error: 'flags' may be used
>> uninitialized in this function [-Werror=maybe-uninitialized]
>
>
> Hm, how does paravirt_types.h comes into the picture?

spin_unlock_irqrestore() calls arch_local_irq_restore()

>> The code is correct, but it's easy to see how the compiler gets confused
>> here. This avoids the problem by pulling the lock outside of the function
>> into its only caller.
>
>
> Is it specific gcc version, specific options, or specific kernel config that
> this happens?

Not gcc version specific (same result with gcc-4.9 through 8, didn't test
earlier versions that are currently broken).

> Strange that it hasn't been seen so far.

It seems to be a relatively rare 'randconfig' combination. Looking at
the preprocessed sources, I find:

static u64 get_rc6(struct drm_i915_private *i915, bool locked)
{

 unsigned long flags;
 u64 val;

 if (intel_runtime_pm_get_if_in_use(i915)) {
  val = __get_rc6(i915);
  intel_runtime_pm_put(i915);
  if (!locked)
   do { do { ({ unsigned long __dummy; typeof(flags) __dummy2;
(void)(&__dummy == &__dummy2); 1; }); do { do { do { ({ unsigned long
__dummy; typeof(flags) __dummy2; (void)(&__dummy == &__dummy2); 1; });
flags = arch_local_irq_save(); } while (0); trace_hardirqs_off(); }
while (0); do { __asm__ __volatile__("": : :"memory"); do { (void)0;
(void)(spinlock_check(>pmu.lock)); } while (0); } while (0); }
while (0); } while (0); } while (0);

  if (val >= i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur) {
   i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur = 0;
   i915->pmu.sample[__I915_SAMPLE_RC6].cur = val;
  } else {
   val = i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur;
  }
  if (!locked)
   spin_unlock_irqrestore(>pmu.lock, flags);
 } else {
  struct pci_dev *pdev = i915->drm.pdev;
  struct device *kdev = >dev;
  unsigned long flags2;
# 455 "/git/arm-soc/drivers/gpu/drm/i915/i915_pmu.c"
  if (!locked)
   do { do { ({ unsigned long __dummy; typeof(flags) __dummy2;
(void)(&__dummy == &__dummy2); 1; }); do { do { do { ({ unsigned long
__dummy; typeof(flags) __dummy2; (void)(&__dummy == &__dummy2); 1; });
flags = arch_local_irq_save(); } while (0); trace_hardirqs_off(); }
while (0); do { __asm__ __volatile__("": : :"memory"); do { (void)0;
(void)(spinlock_check(>pmu.lock)); } while (0); } while (0); }
while (0); } while (0); } while (0);

  do { do { ({ unsigned long __dummy; typeof(flags2) __dummy2;
(void)(&__dummy == &__dummy2); 1; }); do { do { do { ({ unsigned long
__dummy; typeof(flags2) __dummy2; (void)(&__dummy == &__dummy2); 1;
}); flags2 = arch_local_irq_save(); } while (0); trace_hardirqs_off();
} while (0); do { __asm__ __volatile__("": : :"memory"); do { (void)0;
(void)(spinlock_check(>power.lock)); } while (0); } while (0); }
while (0); } while (0); } while (0);

  if (!i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur)
   i915->pmu.suspended_jiffies_last =
  kdev->power.suspended_jiffies;

  val = kdev->power.suspended_jiffies -
i915->pmu.suspended_jiffies_last;
  val += jiffies - kdev->power.accounting_timestamp;

  spin_unlock_irqrestore(>power.lock, flags2);

  val = jiffies_to_nsecs(val);
  val += i915->pmu.sample[__I915_SAMPLE_RC6].cur;
  i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur = val;

  if (!locked)
   spin_unlock_irqrestore(>pmu.lock, flags);
 }
  return val;
}

so it seems that the spin_lock_irqsave() is completely inlined through
a macro while the unlock is not, and the lock contains a memory barrier
(among other things) that might tell the compiler that the state of the
'locked' flag could changed underneath it.

It could also be the problem that arch_local_irq_restore() uses
__builtin_expect() in  PVOP_TEST_NULL(op) when
CONFIG_PARAVIRT_DEBUG is enabled, see

static inline __attribute__((unused))
__attribute__((no_instrument_function))
__attribute__((no_instrument_function)) void
arch_local_irq_restore(unsigned long f)
{
 ({ unsigned long __eax = __eax, __edx = __edx, __ecx = __ecx;; do {
if (__builtin_expect(!!(pv_irq_ops.restore_fl.func == ((void *)0)),
0)) do { do { asm volatile("1:\t" ".byte 0x0f, 0x0b" "\n"
".pushsection __bug_table,\"aw\"\n" "2:\t" ".long " "1b" "\t#
bug_entry::bug_addr\n" "\t" ".long " "%c0" "\t# bug_entry::file\n"
"\t.word %c1" "\t# bug_entry::line\n" "\t.word %c2" "\t#
bug_entry::flags\n" "\t.org 2b+%c3\n" ".popsection" : : "i"
("/git/arm-soc/arch/x86/include/asm/paravirt.h"), "i" (783), "i" (0),
"i" (sizeof(struct bug_entry))); } while (0); do { ; asm volatile("");
__builtin_unreachable(); } while (0); } while (0); } while (0); asm
volatile("" "771:\n\t" "999:\n\t" ".pushsection
.discard.retpoline_safe\n\t" " " 

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

[kbuild test robot]

Hi Maruthi,

FYI, the error/warning still remains.

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

All errors (new ones prefixed by >>):

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

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

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

Re: [PATCH 3/3] drm: Store the calculated vrefresh in the user mode

[Maarten Lankhorst]

Op 13-03-18 om 16:07 schreef Ville Syrjala:
> From: Ville Syrjälä 
>
> Ignore the vrefresh in the mode the user passed in and instead
> calculate the value based on the actual timings. This way we can
> actually trust mode->vrefresh to some degree.
>
> Or should we compare the user's idea of vrefresh with the one
> we get from the timings and return an error if they differ? We
> can't really be sure what the user is asking in that case.
>
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/drm_modes.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index f6b7c0e36a1a..021526ec6fa0 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -1609,7 +1609,11 @@ int drm_mode_convert_umode(struct drm_device *dev,
>   out->vsync_end = in->vsync_end;
>   out->vtotal = in->vtotal;
>   out->vscan = in->vscan;
> - out->vrefresh = in->vrefresh;
> +  /*
> +   * Ignore what the user is saying here and instead
> +   * calculate vrefresh based on the actual timings.
> +   */
> + out->vrefresh = 0;
>   out->flags = in->flags;
>   out->type = in->type;
>   strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
> @@ -1619,6 +1623,8 @@ int drm_mode_convert_umode(struct drm_device *dev,
>   if (out->status != MODE_OK)
>   return -EINVAL;
>  
> + out->vrefresh = drm_mode_vrefresh(out);
> +
>   drm_mode_set_crtcinfo(out, CRTC_INTERLACE_HALVE_V);
>  
>   return 0;

Could we also get this with dim fixes tags dc911f5bd8aa, so we can backport the 
alt mode handling patch?

And update the documentation about vrefresh, that you can retrieve it with 
drm_mode_vrefresh?

~Maarten

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

[Bug 102646] [dc] Screen flickering under amdgpu-experimental [buggy auto power profile]

[bugzilla-daemon]

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

--- Comment #27 from Ruben Harutyunyan  ---
Hmm.

I guess I got deceived by `CONFIG_DRM_AMD_DC=y` being available in that commit
and logs like `dc_link_detect` and `dc_link_handle_hpd_rx_irq` that didn't show
up before.

Sorry about that!

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

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

[bugzilla-daemon]

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

sh...@tuta.io changed:

   What|Removed |Added

 CC||sh...@tuta.io

--- Comment #35 from sh...@tuta.io ---
Has the cause of this issue been identified/confirmed?

On boot I have grey console background instead of black.

Linux 4.15.8-1-ARCH x86_64

1002:6758 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Turks XT [Radeon HD 6670/7670]

-- 
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 libdrm 2/2] meson: detect alloca.h

[Dylan Baker]

Quoting Eric Engestrom (2018-03-13 07:54:12)
> amdgpu makes use of it
> 
> Signed-off-by: Eric Engestrom 
> ---
>  meson.build | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meson.build b/meson.build
> index 3a33928d02a6dce5f075..f7986af9bb5259be5da5 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -186,7 +186,7 @@ else
>dep_rt = []
>  endif
>  dep_m = cc.find_library('m', required : false)
> -foreach header : ['sys/sysctl.h', 'sys/select.h']
> +foreach header : ['sys/sysctl.h', 'sys/select.h', 'alloca.h']
>if cc.compiles('#include <@0@>'.format(header), name : '@0@ 
> works'.format(header))
>  config.set10('HAVE_' + header.underscorify().to_upper(), true)
>endif
> -- 
> Cheers,
>   Eric
> 

for the series:
Reviewed-by: Dylan Baker 


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

Re: [PATCH hwc v1] [RFC] drm_hwcomposer: Flatten composition using writeback connector

[Stefan Schake]

Hey Alexandru,

On Tue, Mar 13, 2018 at 5:21 PM, Alexandru Gheorghe
 wrote:
> This patchset tries to add support for using writeback connector to
> flatten a scene when it doesn't change for a while. This idea had
> been floated around on IRC here [1] and here [2].
>
> 2. Heuristic for triggering the flattening.
> I just created a VSyncWorker which will trigger the flattening of the
> scene if it doesn't change for 60 consecutive vsyncs. The countdown
> gets reset every time ValidateDisplay is called. This is a relatively
> basic heuristic, so I'm open to suggestions.

I think when Android deems that the display is sufficiently idle, it will
disable VSync through setVsyncEnabled. Presumably we could just trigger the
flattening on an enabled -> disabled transition?

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

Re: [DPU PATCH 08/11] drm/msm: Remove hand-rolled out fences

[Jeykumar Sankaran]

On 2018-03-12 13:30, Sean Paul wrote:

On Fri, Mar 02, 2018 at 04:44:55PM -0800, Jeykumar Sankaran wrote:

On 2018-02-28 11:19, Sean Paul wrote:
> Remove release/output/retire fences from the dpu driver. These are
> already available via drm core's OUT_FENCE property.
>
> Change-Id: Id4238d0b5457f2c8ee2e87bb7814e1850a573623
> Signed-off-by: Sean Paul 


Reviewed-by: Jeykumar Sankaran 


> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c |  66 +--
>  drivers/gpu/drm/msm/disp/dpu1/dpu_connector.h |  23 ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c  | 178

+++---

>  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h  |  28 ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c   |   3 -
>  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h   |   4 +-
>  .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h  |   8 -
>  .../drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c  |  73 +--
>  .../drm/msm/disp/dpu1/dpu_encoder_phys_vid.c  |  19 --
>  .../drm/msm/disp/dpu1/dpu_encoder_phys_wb.c   |  12 +-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   |  30 ---
>  drivers/gpu/drm/msm/msm_drv.h |   3 -
>  12 files changed, 36 insertions(+), 411 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c
> index 57b8627ef418..cc5bfa862cb7 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c
> @@ -521,7 +521,6 @@ static void dpu_connector_destroy(struct
> drm_connector
> *connector)
>backlight_device_unregister(c_conn->bl_device);
>drm_connector_unregister(connector);
>mutex_destroy(_conn->lock);
> -  dpu_fence_deinit(_conn->retire_fence);
>drm_connector_cleanup(connector);
>kfree(c_conn);
>  }
> @@ -906,12 +905,9 @@ static int

dpu_connector_atomic_get_property(struct

> drm_connector *connector,
>c_state = to_dpu_connector_state(state);
>
>idx = msm_property_index(_conn->property_info, property);
> -  if (idx == CONNECTOR_PROP_RETIRE_FENCE)
> -  rc = dpu_fence_create(_conn->retire_fence, val, 0);
> -  else
> -  /* get cached property value */
> -  rc = msm_property_atomic_get(_conn->property_info,
> -  _state->property_state, property, val);
> +  /* get cached property value */
> +  rc = msm_property_atomic_get(_conn->property_info,
> +  _state->property_state, property, val);
>
>/* allow for custom override */
>if (c_conn->ops.get_property)
> @@ -923,39 +919,6 @@ static int

dpu_connector_atomic_get_property(struct

> drm_connector *connector,
>return rc;
>  }
>
> -void dpu_connector_prepare_fence(struct drm_connector *connector)
> -{
> -  if (!connector) {
> -  DPU_ERROR("invalid connector\n");
> -  return;
> -  }
> -
> -  dpu_fence_prepare(_dpu_connector(connector)->retire_fence);
> -}
> -
> -void dpu_connector_complete_commit(struct drm_connector *connector,
> -  ktime_t ts)
> -{
> -  if (!connector) {
> -  DPU_ERROR("invalid connector\n");
> -  return;
> -  }
> -
> -  /* signal connector's retire fence */
> -  dpu_fence_signal(_dpu_connector(connector)->retire_fence, ts,
> false);
> -}
> -
> -void dpu_connector_commit_reset(struct drm_connector *connector,
> ktime_t
> ts)
> -{
> -  if (!connector) {
> -  DPU_ERROR("invalid connector\n");
> -  return;
> -  }
> -
> -  /* signal connector's retire fence */
> -  dpu_fence_signal(_dpu_connector(connector)->retire_fence, ts,
> true);
> -}
> -
>  static enum drm_connector_status
>  dpu_connector_detect(struct drm_connector *connector, bool force)
>  {
> @@ -1214,26 +1177,19 @@ struct drm_connector

*dpu_connector_init(struct

> drm_device *dev,
>"conn%u",
>c_conn->base.base.id);
>
> -  rc = dpu_fence_init(_conn->retire_fence, c_conn->name,
> -  c_conn->base.base.id);
> -  if (rc) {
> -  DPU_ERROR("failed to init fence, %d\n", rc);
> -  goto error_cleanup_conn;
> -  }
> -
>mutex_init(_conn->lock);
>
>rc = drm_mode_connector_attach_encoder(_conn->base, encoder);
>if (rc) {
>DPU_ERROR("failed to attach encoder to connector, %d\n",
> rc);
> -  goto error_cleanup_fence;
> +  goto error_cleanup_conn;
>}
>
>  #ifdef CONFIG_DRM_MSM_DSI_STAGING
>rc = dpu_backlight_setup(c_conn, dev);
>if (rc) {
>DPU_ERROR("failed to setup backlight, rc=%d\n", rc);
> -  goto error_cleanup_fence;
> +  goto error_cleanup_conn;
>}
>  #endif
>
> @@ -1248,7 +1204,7 @@ struct drm_connector *dpu_connector_init(struct
> drm_device *dev,
>if (!info) {
>DPU_ERROR("failed to allocate info buffer\n");
>rc = -ENOMEM;
> -  goto error_cleanup_fence;
> +  goto error_cleanup_conn;
>}
>
>

Re: [DPU PATCH 01/11] drm/msm: Skip seamless disables in crtc/encoder

[Jeykumar Sankaran]

On 2018-03-12 13:14, Sean Paul wrote:

On Fri, Mar 02, 2018 at 04:04:24PM -0800, jsa...@codeaurora.org wrote:

On 2018-02-28 11:18, Sean Paul wrote:
> Instead of duplicating whole swaths of atomic helper functions (which
> are already out-of-date), just skip the encoder/crtc disables in the
> .disable hooks.
>
> Change-Id: I7bd9183ae60624204fb1de9550656b776efc7202
> Signed-off-by: Sean Paul 


Reviewed-by: Jeykumar Sankaran 



Can you consider getting rid of these checks?


Do you mean the Change-Id? Yeah, I forgot to strip them out before
sending, I'll
make sure I clean it up before I apply.

Actually, I meant removing the seamless check flags that you are moving 
to

encode/crtc. But you can ignore that, I am planning to submit a seperate
change to remove the support from the whole pipeline.


> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c|   8 +
>  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c |   8 +
>  drivers/gpu/drm/msm/msm_atomic.c| 185

+---

>  3 files changed, 17 insertions(+), 184 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> index 3cdf1e3d9d96..a3ab6ed2bf1d 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> @@ -3393,6 +3393,7 @@ static void dpu_crtc_disable(struct drm_crtc
> *crtc)
>  {
>struct dpu_crtc *dpu_crtc;
>struct dpu_crtc_state *cstate;
> +  struct drm_display_mode *mode;
>struct drm_encoder *encoder;
>struct msm_drm_private *priv;
>unsigned long flags;
> @@ -3407,8 +3408,15 @@ static void dpu_crtc_disable(struct drm_crtc
> *crtc)
>}
>dpu_crtc = to_dpu_crtc(crtc);
>cstate = to_dpu_crtc_state(crtc->state);
> +  mode = >base.adjusted_mode;
>priv = crtc->dev->dev_private;
>
> +  if (msm_is_mode_seamless(mode) || msm_is_mode_seamless_vrr(mode)
> ||
> +  msm_is_mode_seamless_dms(mode)) {
> +  DPU_DEBUG("Seamless mode is being applied, skip
> disable\n");
> +  return;
> +  }
> +
Another topic of discussion which should be brought up with dri-devel.

May not be common in PC world, but there are a handful of mobile OEM's
using panels which supports more than one resolution. Primary use 
cases

involve "seamless" switching to optimized display resolution when
streaming content changes resolutions or rendering lossless data.


Yeah, I think we can do this under the covers if the hardware supports 
it

such
as this patch. We could probably do a better job of making this useful 
for

other
drivers, but I was really just trying to get the seamless stuff out of 
the

way
so we don't need to roll our own atomic commit.

Sean



Jeykumar S.

>DPU_DEBUG("crtc%d\n", crtc->base.id);
>
>if (dpu_kms_is_suspend_state(crtc->dev))
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> index 3d168fa09f3f..28ceb589ee40 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> @@ -2183,6 +2183,7 @@ static void dpu_encoder_virt_disable(struct
> drm_encoder *drm_enc)
>struct dpu_encoder_virt *dpu_enc = NULL;
>struct msm_drm_private *priv;
>struct dpu_kms *dpu_kms;
> +  struct drm_display_mode *mode;
>int i = 0;
>
>if (!drm_enc) {
> @@ -2196,6 +2197,13 @@ static void dpu_encoder_virt_disable(struct
> drm_encoder *drm_enc)
>return;
>}
>
> +  mode = _enc->crtc->state->adjusted_mode;
> +  if (msm_is_mode_seamless(mode) || msm_is_mode_seamless_vrr(mode)
> ||
> +  msm_is_mode_seamless_dms(mode)) {
> +  DPU_DEBUG("Seamless mode is being applied, skip
> disable\n");
> +  return;
> +  }
> +
>dpu_enc = to_dpu_encoder_virt(drm_enc);
>DPU_DEBUG_ENC(dpu_enc, "\n");
>
> diff --git a/drivers/gpu/drm/msm/msm_atomic.c
> b/drivers/gpu/drm/msm/msm_atomic.c
> index 46536edb72ee..5cfb80345052 100644
> --- a/drivers/gpu/drm/msm/msm_atomic.c
> +++ b/drivers/gpu/drm/msm/msm_atomic.c
> @@ -84,189 +84,6 @@ static void msm_atomic_wait_for_commit_done(
>}
>  }
>
> -static void
> -msm_disable_outputs(struct drm_device *dev, struct drm_atomic_state
> *old_state)
> -{
> -  struct drm_connector *connector;
> -  struct drm_connector_state *old_conn_state, *new_conn_state;
> -  struct drm_crtc *crtc;
> -  struct drm_crtc_state *old_crtc_state, *new_crtc_state;
> -  int i;
> -
> -  for_each_oldnew_connector_in_state(old_state, connector,
> old_conn_state, new_conn_state, i) {
> -  const struct drm_encoder_helper_funcs *funcs;
> -  struct drm_encoder *encoder;
> -  struct drm_crtc_state *old_crtc_state;
> -  unsigned int crtc_idx;
> -
> -  /*
> -   * Shut down everything that's in the changeset and
> currently
> -   * still on. So need to check the old, saved state.
> -   */
> -  if (!old_conn_state->crtc)
> -  

[PATCH v2 11/11] drm: rcar-du: Support interlaced video output through vsp1

[Kieran Bingham]

Use the newly exposed VSP1 interface to enable interlaced frame support
through the VSP1 lif pipelines.

Signed-off-by: Kieran Bingham 
---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 1 +
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c  | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 5685d5af6998..9854d9deb944 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -248,6 +248,7 @@ static void rcar_du_crtc_set_display_timing(struct 
rcar_du_crtc *rcrtc)
/* Signal polarities */
value = ((mode->flags & DRM_MODE_FLAG_PVSYNC) ? DSMR_VSL : 0)
  | ((mode->flags & DRM_MODE_FLAG_PHSYNC) ? DSMR_HSL : 0)
+ | ((mode->flags & DRM_MODE_FLAG_INTERLACE) ? DSMR_ODEV : 0)
  | DSMR_DIPM_DISP | DSMR_CSPM;
rcar_du_crtc_write(rcrtc, DSMR, value);
 
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c 
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index 2c260c33840b..5e47daef8bd2 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
@@ -178,6 +178,9 @@ static void rcar_du_vsp_plane_setup(struct 
rcar_du_vsp_plane *plane)
};
unsigned int i;
 
+   cfg.interlaced = !!(plane->plane.state->crtc->mode.flags
+   & DRM_MODE_FLAG_INTERLACE);
+
cfg.src.left = state->state.src.x1 >> 16;
cfg.src.top = state->state.src.y1 >> 16;
cfg.src.width = drm_rect_width(>state.src) >> 16;
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 07/11] media: vsp1: Use header display lists for all WPF outputs linked to the DU

[Kieran Bingham]

Header mode display lists are now supported on all WPF outputs. To
support extended headers and auto-fld capabilities for interlaced mode
handling only header mode display lists can be used.

Disable the headerless display list configuration, and remove the dead
code.

Signed-off-by: Kieran Bingham 
---
 drivers/media/platform/vsp1/vsp1_dl.c | 107 ++-
 1 file changed, 27 insertions(+), 80 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
b/drivers/media/platform/vsp1/vsp1_dl.c
index 680eedb6fc9f..5f5706f8a84c 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -98,7 +98,7 @@ struct vsp1_dl_body_pool {
  * struct vsp1_dl_list - Display list
  * @list: entry in the display list manager lists
  * @dlm: the display list manager
- * @header: display list header, NULL for headerless lists
+ * @header: display list header
  * @dma: DMA address for the header
  * @body0: first display list body
  * @bodies: list of extra display list bodies
@@ -119,15 +119,9 @@ struct vsp1_dl_list {
struct list_head chain;
 };
 
-enum vsp1_dl_mode {
-   VSP1_DL_MODE_HEADER,
-   VSP1_DL_MODE_HEADERLESS,
-};
-
 /**
  * struct vsp1_dl_manager - Display List manager
  * @index: index of the related WPF
- * @mode: display list operation mode (header or headerless)
  * @singleshot: execute the display list in single-shot mode
  * @vsp1: the VSP1 device
  * @lock: protects the free, active, queued, pending and gc_bodies lists
@@ -139,7 +133,6 @@ enum vsp1_dl_mode {
  */
 struct vsp1_dl_manager {
unsigned int index;
-   enum vsp1_dl_mode mode;
bool singleshot;
struct vsp1_device *vsp1;
 
@@ -320,6 +313,7 @@ static struct vsp1_dl_list *vsp1_dl_list_alloc(struct 
vsp1_dl_manager *dlm,
   struct vsp1_dl_body_pool *pool)
 {
struct vsp1_dl_list *dl;
+   size_t header_offset;
 
dl = kzalloc(sizeof(*dl), GFP_KERNEL);
if (!dl)
@@ -332,16 +326,15 @@ static struct vsp1_dl_list *vsp1_dl_list_alloc(struct 
vsp1_dl_manager *dlm,
dl->body0 = vsp1_dl_body_get(pool);
if (!dl->body0)
return NULL;
-   if (dlm->mode == VSP1_DL_MODE_HEADER) {
-   size_t header_offset = dl->body0->max_entries
-* sizeof(*dl->body0->entries);
 
-   dl->header = ((void *)dl->body0->entries) + header_offset;
-   dl->dma = dl->body0->dma + header_offset;
+   header_offset = dl->body0->max_entries
+* sizeof(*dl->body0->entries);
 
-   memset(dl->header, 0, sizeof(*dl->header));
-   dl->header->lists[0].addr = dl->body0->dma;
-   }
+   dl->header = ((void *)dl->body0->entries) + header_offset;
+   dl->dma = dl->body0->dma + header_offset;
+
+   memset(dl->header, 0, sizeof(*dl->header));
+   dl->header->lists[0].addr = dl->body0->dma;
 
return dl;
 }
@@ -473,16 +466,9 @@ struct vsp1_dl_body *vsp1_dl_list_get_body0(struct 
vsp1_dl_list *dl)
  *
  * The reference must be explicitly released by a call to vsp1_dl_body_put()
  * when the body isn't needed anymore.
- *
- * Additional bodies are only usable for display lists in header mode.
- * Attempting to add a body to a header-less display list will return an error.
  */
 int vsp1_dl_list_add_body(struct vsp1_dl_list *dl, struct vsp1_dl_body *dlb)
 {
-   /* Multi-body lists are only available in header mode. */
-   if (dl->dlm->mode != VSP1_DL_MODE_HEADER)
-   return -EINVAL;
-
refcount_inc(>refcnt);
 
list_add_tail(>list, >bodies);
@@ -503,17 +489,10 @@ int vsp1_dl_list_add_body(struct vsp1_dl_list *dl, struct 
vsp1_dl_body *dlb)
  * Adding a display list to a chain passes ownership of the display list to
  * the head display list item. The chain is released when the head dl item is
  * put back with __vsp1_dl_list_put().
- *
- * Chained display lists are only usable in header mode. Attempts to add a
- * display list to a chain in header-less mode will return an error.
  */
 int vsp1_dl_list_add_chain(struct vsp1_dl_list *head,
   struct vsp1_dl_list *dl)
 {
-   /* Chained lists are only available in header mode. */
-   if (head->dlm->mode != VSP1_DL_MODE_HEADER)
-   return -EINVAL;
-
head->has_chain = true;
list_add_tail(>chain, >chain);
return 0;
@@ -581,17 +560,10 @@ static bool vsp1_dl_list_hw_update_pending(struct 
vsp1_dl_manager *dlm)
return false;
 
/*
-* Check whether the VSP1 has taken the update. In headerless mode the
-* hardware indicates this by clearing the UPD bit in the DL_BODY_SIZE
-* register, and in header mode by clearing the UPDHDR bit in the CMD
-* register.
+* Check whether the VSP1 has taken the update. In header mode 

[PATCH v2 09/11] media: vsp1: Provide support for extended command pools

[Kieran Bingham]

VSPD and VSP-DL devices can provide extended display lists supporting
extended command display list objects.

These extended commands require their own dma memory areas for a header
and body specific to the command type.

Implement a command pool to allocate all necessary memory in a single
DMA allocation to reduce pressure on the TLB, and provide convenient
re-usable command objects for the entities to utilise.

Signed-off-by: Kieran Bingham 

---

v2:
 - Fix spelling typo in commit message
 - constify, and staticify the instantiation of vsp1_extended_commands
 - s/autfld_cmds/autofld_cmds/
 - staticify cmd pool functions (Thanks kbuild-bot)

 drivers/media/platform/vsp1/vsp1_dl.c | 190 +++-
 drivers/media/platform/vsp1/vsp1_dl.h |   3 +-
 2 files changed, 193 insertions(+)

diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
b/drivers/media/platform/vsp1/vsp1_dl.c
index cd91b50deed1..d8392bd866f1 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -121,6 +121,30 @@ struct vsp1_dl_body_pool {
 };
 
 /**
+ * struct vsp1_cmd_pool - display list body pool
+ * @dma: DMA address of the entries
+ * @size: size of the full DMA memory pool in bytes
+ * @mem: CPU memory pointer for the pool
+ * @bodies: Array of DLB structures for the pool
+ * @free: List of free DLB entries
+ * @lock: Protects the pool and free list
+ * @vsp1: the VSP1 device
+ */
+struct vsp1_dl_cmd_pool {
+   /* DMA allocation */
+   dma_addr_t dma;
+   size_t size;
+   void *mem;
+
+   struct vsp1_dl_ext_cmd *cmds;
+   struct list_head free;
+
+   spinlock_t lock;
+
+   struct vsp1_device *vsp1;
+};
+
+/**
  * struct vsp1_dl_list - Display list
  * @list: entry in the display list manager lists
  * @dlm: the display list manager
@@ -163,6 +187,7 @@ struct vsp1_dl_list {
  * @queued: list queued to the hardware (written to the DL registers)
  * @pending: list waiting to be queued to the hardware
  * @pool: body pool for the display list bodies
+ * @autofld_cmds: command pool to support auto-fld interlaced mode
  */
 struct vsp1_dl_manager {
unsigned int index;
@@ -176,6 +201,7 @@ struct vsp1_dl_manager {
struct vsp1_dl_list *pending;
 
struct vsp1_dl_body_pool *pool;
+   struct vsp1_dl_cmd_pool *autofld_cmds;
 };
 
 /* 
-
@@ -339,6 +365,139 @@ void vsp1_dl_body_write(struct vsp1_dl_body *dlb, u32 
reg, u32 data)
 }
 
 /* 
-
+ * Display List Extended Command Management
+ */
+
+enum vsp1_extcmd_type {
+   VSP1_EXTCMD_AUTODISP,
+   VSP1_EXTCMD_AUTOFLD,
+};
+
+struct vsp1_extended_command_info {
+   u16 opcode;
+   size_t body_size;
+} static const vsp1_extended_commands[] = {
+   [VSP1_EXTCMD_AUTODISP] = { 0x02, 96 },
+   [VSP1_EXTCMD_AUTOFLD]  = { 0x03, 160 },
+};
+
+/**
+ * vsp1_dl_cmd_pool_create - Create a pool of commands from a single allocation
+ * @vsp1: The VSP1 device
+ * @type: The command pool type
+ * @num_commands: The quantity of commands to allocate
+ *
+ * Allocate a pool of commands each with enough memory to contain the private
+ * data of each command. The allocation sizes are dependent upon the command
+ * type.
+ *
+ * Return a pointer to a pool on success or NULL if memory can't be allocated.
+ */
+static struct vsp1_dl_cmd_pool *
+vsp1_dl_cmd_pool_create(struct vsp1_device *vsp1, enum vsp1_extcmd_type type,
+   unsigned int num_cmds)
+{
+   struct vsp1_dl_cmd_pool *pool;
+   unsigned int i;
+   size_t cmd_size;
+
+   pool = kzalloc(sizeof(*pool), GFP_KERNEL);
+   if (!pool)
+   return NULL;
+
+   pool->cmds = kcalloc(num_cmds, sizeof(*pool->cmds), GFP_KERNEL);
+   if (!pool->cmds) {
+   kfree(pool);
+   return NULL;
+   }
+
+   cmd_size = sizeof(struct vsp1_dl_ext_cmd_header) +
+  vsp1_extended_commands[type].body_size;
+   cmd_size = ALIGN(cmd_size, 16);
+
+   pool->size = cmd_size * num_cmds;
+   pool->mem = dma_alloc_wc(vsp1->bus_master, pool->size, >dma,
+GFP_KERNEL);
+   if (!pool->mem) {
+   kfree(pool->cmds);
+   kfree(pool);
+   return NULL;
+   }
+
+   spin_lock_init(>lock);
+   INIT_LIST_HEAD(>free);
+
+   for (i = 0; i < num_cmds; ++i) {
+   struct vsp1_dl_ext_cmd *cmd = >cmds[i];
+   size_t cmd_offset = i * cmd_size;
+   size_t data_offset = sizeof(struct vsp1_dl_ext_cmd_header) +
+cmd_offset;
+
+   cmd->pool = pool;
+   cmd->cmd_opcode = vsp1_extended_commands[type].opcode;
+
+   /* TODO: Auto-disp can utilise more than one command per cmd */
+   

[Bug 102646] [dc] Screen flickering under amdgpu-experimental [buggy auto power profile]

[bugzilla-daemon]

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

--- Comment #26 from Harry Wentland  ---
That regression commit is the one that introduced the new DC display driver, so
going back to the last working commit will effectively be the same as disabling
DC for you.

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

[PATCH v2 10/11] media: vsp1: Support Interlaced display pipelines

[Kieran Bingham]

Calculate the top and bottom fields for the interlaced frames and
utilise the extended display list command feature to implement the
auto-field operations. This allows the DU to update the VSP2 registers
dynamically based upon the currently processing field.

Signed-off-by: Kieran Bingham 

---

v2:
 - fix erroneous BIT value which enabled interlaced
 - fix field handling at frame_end interrupt

 drivers/media/platform/vsp1/vsp1_dl.c   | 10 -
 drivers/media/platform/vsp1/vsp1_drm.c  | 11 -
 drivers/media/platform/vsp1/vsp1_regs.h |  1 +-
 drivers/media/platform/vsp1/vsp1_rpf.c  | 72 --
 drivers/media/platform/vsp1/vsp1_rwpf.h |  1 +-
 include/media/vsp1.h|  1 +-
 6 files changed, 93 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
b/drivers/media/platform/vsp1/vsp1_dl.c
index d8392bd866f1..08715ce6db1e 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -889,7 +889,9 @@ void vsp1_dl_list_commit(struct vsp1_dl_list *dl)
  */
 bool vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
 {
+   struct vsp1_device *vsp1 = dlm->vsp1;
bool completed = false;
+   u32 status = vsp1_read(vsp1, VI6_STATUS);
 
spin_lock(>lock);
 
@@ -914,6 +916,14 @@ bool vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
goto done;
 
/*
+* Progressive streams report only TOP fields. If we have a BOTTOM
+* field, we are interlaced, and expect the frame to complete on the
+* next frame end interrupt.
+*/
+   if (status & VI6_STATUS_FLD_STD(dlm->index))
+   goto done;
+
+   /*
 * The device starts processing the queued display list right after the
 * frame end interrupt. The display list thus becomes active.
 */
diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index 0459b970e9da..a714c53601b6 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -368,6 +368,17 @@ int vsp1_du_atomic_update(struct device *dev, unsigned int 
pipe_index,
return -EINVAL;
}
 
+   if (!(vsp1_feature(vsp1, VSP1_HAS_EXT_DL)) && cfg->interlaced) {
+   /*
+* Interlaced support requires extended display lists to
+* provide the auto-fld feature with the DU.
+*/
+   dev_dbg(vsp1->dev, "Interlaced unsupported on this output\n");
+   return -EINVAL;
+   }
+
+   rpf->interlaced = cfg->interlaced;
+
rpf->fmtinfo = fmtinfo;
rpf->format.num_planes = fmtinfo->planes;
rpf->format.plane_fmt[0].bytesperline = cfg->pitch;
diff --git a/drivers/media/platform/vsp1/vsp1_regs.h 
b/drivers/media/platform/vsp1/vsp1_regs.h
index 43ad68ff3167..e2dffbe82809 100644
--- a/drivers/media/platform/vsp1/vsp1_regs.h
+++ b/drivers/media/platform/vsp1/vsp1_regs.h
@@ -31,6 +31,7 @@
 #define VI6_SRESET_SRTS(n) (1 << (n))
 
 #define VI6_STATUS 0x0038
+#define VI6_STATUS_FLD_STD(n)  (1 << ((n) + 28))
 #define VI6_STATUS_SYS_ACT(n)  (1 << ((n) + 8))
 
 #define VI6_WPF_IRQ_ENB(n) (0x0048 + (n) * 12)
diff --git a/drivers/media/platform/vsp1/vsp1_rpf.c 
b/drivers/media/platform/vsp1/vsp1_rpf.c
index 67f2fb3e0611..86ac8f488b7a 100644
--- a/drivers/media/platform/vsp1/vsp1_rpf.c
+++ b/drivers/media/platform/vsp1/vsp1_rpf.c
@@ -24,6 +24,20 @@
 #define RPF_MAX_WIDTH  8190
 #define RPF_MAX_HEIGHT 8190
 
+/* Pre extended display list command data structure */
+struct vsp1_extcmd_auto_fld_body {
+   u32 top_y0;
+   u32 bottom_y0;
+   u32 top_c0;
+   u32 bottom_c0;
+   u32 top_c1;
+   u32 bottom_c1;
+   u32 reserved0;
+   u32 reserved1;
+} __packed;
+
+#define VSP1_DL_EXT_AUTOFLD_INTBIT(0)
+
 /* 
-
  * Device Access
  */
@@ -68,6 +82,14 @@ static void rpf_configure_stream(struct vsp1_entity *entity,
pstride |= format->plane_fmt[1].bytesperline
<< VI6_RPF_SRCM_PSTRIDE_C_SHIFT;
 
+   /*
+* pstride has both STRIDE_Y and STRIDE_C, but multiplying the whole
+* of pstride by 2 is conveniently OK here as we are multiplying both
+* values.
+*/
+   if (rpf->interlaced)
+   pstride *= 2;
+
vsp1_rpf_write(rpf, dlb, VI6_RPF_SRCM_PSTRIDE, pstride);
 
/* Format */
@@ -104,6 +126,9 @@ static void rpf_configure_stream(struct vsp1_entity *entity,
top = compose->top;
}
 
+   if (rpf->interlaced)
+   top /= 2;
+
vsp1_rpf_write(rpf, dlb, VI6_RPF_LOC,
   (left << VI6_RPF_LOC_HCOORD_SHIFT) |
 

[PATCH v2 08/11] media: vsp1: Add support for extended display list headers

[Kieran Bingham]

Extended display list headers allow pre and post command lists to be
executed by the VSP pipeline. This provides the base support for
features such as AUTO_FLD (for interlaced support) and AUTO_DISP (for
supporting continuous camera preview pipelines.

Signed-off-by: Kieran Bingham 

---

v2:
 - remove __packed attributes

 drivers/media/platform/vsp1/vsp1.h  |  1 +-
 drivers/media/platform/vsp1/vsp1_dl.c   | 83 +-
 drivers/media/platform/vsp1/vsp1_dl.h   | 29 -
 drivers/media/platform/vsp1/vsp1_drv.c  |  7 +-
 drivers/media/platform/vsp1/vsp1_regs.h |  5 +-
 5 files changed, 116 insertions(+), 9 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1.h 
b/drivers/media/platform/vsp1/vsp1.h
index 1c080538c993..bb3b32795206 100644
--- a/drivers/media/platform/vsp1/vsp1.h
+++ b/drivers/media/platform/vsp1/vsp1.h
@@ -55,6 +55,7 @@ struct vsp1_uds;
 #define VSP1_HAS_HGO   (1 << 7)
 #define VSP1_HAS_HGT   (1 << 8)
 #define VSP1_HAS_BRS   (1 << 9)
+#define VSP1_HAS_EXT_DL(1 << 10)
 
 struct vsp1_device_info {
u32 version;
diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
b/drivers/media/platform/vsp1/vsp1_dl.c
index 5f5706f8a84c..cd91b50deed1 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -26,6 +26,9 @@
 #define VSP1_DLH_INT_ENABLE(1 << 1)
 #define VSP1_DLH_AUTO_START(1 << 0)
 
+#define VSP1_DLH_EXT_PRE_CMD_EXEC  (1 << 9)
+#define VSP1_DLH_EXT_POST_CMD_EXEC (1 << 8)
+
 struct vsp1_dl_header_list {
u32 num_bytes;
u32 addr;
@@ -38,11 +41,34 @@ struct vsp1_dl_header {
u32 flags;
 };
 
+struct vsp1_dl_ext_header {
+   u32 reserved0;  /* alignment padding */
+
+   u16 pre_ext_cmd_qty;
+   u16 flags;
+   u32 pre_ext_cmd_plist;
+
+   u32 post_ext_cmd_qty;
+   u32 post_ext_cmd_plist;
+};
+
+struct vsp1_dl_header_extended {
+   struct vsp1_dl_header header;
+   struct vsp1_dl_ext_header ext;
+};
+
 struct vsp1_dl_entry {
u32 addr;
u32 data;
 };
 
+struct vsp1_dl_ext_cmd_header {
+   u32 cmd;
+   u32 flags;
+   u32 data;
+   u32 reserved;
+};
+
 /**
  * struct vsp1_dl_body - Display list body
  * @list: entry in the display list list of bodies
@@ -99,9 +125,12 @@ struct vsp1_dl_body_pool {
  * @list: entry in the display list manager lists
  * @dlm: the display list manager
  * @header: display list header
+ * @extended: extended display list header. NULL for normal lists
  * @dma: DMA address for the header
  * @body0: first display list body
  * @bodies: list of extra display list bodies
+ * @pre_cmd: pre cmd to be issued through extended dl header
+ * @post_cmd: post cmd to be issued through extended dl header
  * @has_chain: if true, indicates that there's a partition chain
  * @chain: entry in the display list partition chain
  */
@@ -110,11 +139,15 @@ struct vsp1_dl_list {
struct vsp1_dl_manager *dlm;
 
struct vsp1_dl_header *header;
+   struct vsp1_dl_ext_header *extended;
dma_addr_t dma;
 
struct vsp1_dl_body *body0;
struct list_head bodies;
 
+   struct vsp1_dl_ext_cmd *pre_cmd;
+   struct vsp1_dl_ext_cmd *post_cmd;
+
bool has_chain;
struct list_head chain;
 };
@@ -498,6 +531,14 @@ int vsp1_dl_list_add_chain(struct vsp1_dl_list *head,
return 0;
 }
 
+static void vsp1_dl_ext_cmd_fill_header(struct vsp1_dl_ext_cmd *cmd)
+{
+   cmd->cmds[0].cmd = cmd->cmd_opcode;
+   cmd->cmds[0].flags = cmd->flags;
+   cmd->cmds[0].data = cmd->data_dma;
+   cmd->cmds[0].reserved = 0;
+}
+
 static void vsp1_dl_list_fill_header(struct vsp1_dl_list *dl, bool is_last)
 {
struct vsp1_dl_manager *dlm = dl->dlm;
@@ -550,6 +591,27 @@ static void vsp1_dl_list_fill_header(struct vsp1_dl_list 
*dl, bool is_last)
 */
dl->header->flags = VSP1_DLH_INT_ENABLE;
}
+
+   if (!dl->extended)
+   return;
+
+   dl->extended->flags = 0;
+
+   if (dl->pre_cmd) {
+   dl->extended->pre_ext_cmd_plist = dl->pre_cmd->cmd_dma;
+   dl->extended->pre_ext_cmd_qty = dl->pre_cmd->num_cmds;
+   dl->extended->flags |= VSP1_DLH_EXT_PRE_CMD_EXEC;
+
+   vsp1_dl_ext_cmd_fill_header(dl->pre_cmd);
+   }
+
+   if (dl->post_cmd) {
+   dl->extended->pre_ext_cmd_plist = dl->post_cmd->cmd_dma;
+   dl->extended->pre_ext_cmd_qty = dl->post_cmd->num_cmds;
+   dl->extended->flags |= VSP1_DLH_EXT_POST_CMD_EXEC;
+
+   vsp1_dl_ext_cmd_fill_header(dl->pre_cmd);
+   }
 }
 
 static bool vsp1_dl_list_hw_update_pending(struct vsp1_dl_manager *dlm)
@@ -715,14 +777,20 @@ bool vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
 }
 
 /* Hardware Setup */
-void vsp1_dlm_setup(struct vsp1_device *vsp1)
+void 

[PATCH v2 05/11] media: vsp1: Clean up DLM objects on error

[Kieran Bingham]

If there is an error allocating a display list within a DLM object
the existing display lists are not free'd, and neither is the DL body
pool.

Use the existing vsp1_dlm_destroy() function to clean up on error.

Signed-off-by: Kieran Bingham 
---
 drivers/media/platform/vsp1/vsp1_dl.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
b/drivers/media/platform/vsp1/vsp1_dl.c
index 310ce81cd724..680eedb6fc9f 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -831,8 +831,10 @@ struct vsp1_dl_manager *vsp1_dlm_create(struct vsp1_device 
*vsp1,
struct vsp1_dl_list *dl;
 
dl = vsp1_dl_list_alloc(dlm, dlm->pool);
-   if (!dl)
+   if (!dl) {
+   vsp1_dlm_destroy(dlm);
return NULL;
+   }
 
list_add_tail(>list, >free);
}
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 03/11] media: vsp1: Rename dl_child to dl_next

[Kieran Bingham]

Both vsp1_dl_list_commit() and __vsp1_dl_list_put() walk the display
list chain referencing the nodes as children, when in reality they are
siblings.

Update the terminology to 'dl_next' to be consistent with the
vsp1_video_pipeline_run() usage.

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

diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
b/drivers/media/platform/vsp1/vsp1_dl.c
index 85795b55a357..8162f4ce66eb 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -400,7 +400,7 @@ struct vsp1_dl_list *vsp1_dl_list_get(struct 
vsp1_dl_manager *dlm)
 /* This function must be called with the display list manager lock held.*/
 static void __vsp1_dl_list_put(struct vsp1_dl_list *dl)
 {
-   struct vsp1_dl_list *dl_child;
+   struct vsp1_dl_list *dl_next;
 
if (!dl)
return;
@@ -410,8 +410,8 @@ static void __vsp1_dl_list_put(struct vsp1_dl_list *dl)
 * hardware operation.
 */
if (dl->has_chain) {
-   list_for_each_entry(dl_child, >chain, chain)
-   __vsp1_dl_list_put(dl_child);
+   list_for_each_entry(dl_next, >chain, chain)
+   __vsp1_dl_list_put(dl_next);
}
 
dl->has_chain = false;
@@ -667,17 +667,17 @@ static void vsp1_dl_list_commit_singleshot(struct 
vsp1_dl_list *dl)
 void vsp1_dl_list_commit(struct vsp1_dl_list *dl)
 {
struct vsp1_dl_manager *dlm = dl->dlm;
-   struct vsp1_dl_list *dl_child;
+   struct vsp1_dl_list *dl_next;
unsigned long flags;
 
if (dlm->mode == VSP1_DL_MODE_HEADER) {
/* Fill the header for the head and chained display lists. */
vsp1_dl_list_fill_header(dl, list_empty(>chain));
 
-   list_for_each_entry(dl_child, >chain, chain) {
-   bool last = list_is_last(_child->chain, >chain);
+   list_for_each_entry(dl_next, >chain, chain) {
+   bool last = list_is_last(_next->chain, >chain);
 
-   vsp1_dl_list_fill_header(dl_child, last);
+   vsp1_dl_list_fill_header(dl_next, last);
}
}
 
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 01/11] media: vsp1: drm: Fix minor grammar error

[Kieran Bingham]

The pixel format is 'unsupported'. Fix the small debug message which
incorrectly declares this.

Signed-off-by: Kieran Bingham 
---
 drivers/media/platform/vsp1/vsp1_drm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index 3c8b1952799d..0459b970e9da 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -363,7 +363,7 @@ int vsp1_du_atomic_update(struct device *dev, unsigned int 
pipe_index,
 */
fmtinfo = vsp1_get_format_info(vsp1, cfg->pixelformat);
if (!fmtinfo) {
-   dev_dbg(vsp1->dev, "Unsupport pixel format %08x for RPF\n",
+   dev_dbg(vsp1->dev, "Unsupported pixel format %08x for RPF\n",
cfg->pixelformat);
return -EINVAL;
}
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 06/11] media: vsp1: Provide VSP1 feature helper macro

[Kieran Bingham]

The VSP1 devices define their specific capabilities through features
marked in their device info structure. Various parts of the code read
this info structure to infer if the features are available.

Wrap this into a more readable vsp1_feature(vsp1, f) macro to ensure
that usage is consistent throughout the driver.

Signed-off-by: Kieran Bingham 
---
 drivers/media/platform/vsp1/vsp1.h |  2 ++
 drivers/media/platform/vsp1/vsp1_drv.c | 16 
 drivers/media/platform/vsp1/vsp1_wpf.c |  6 +++---
 3 files changed, 13 insertions(+), 11 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1.h 
b/drivers/media/platform/vsp1/vsp1.h
index 78ef838416b3..1c080538c993 100644
--- a/drivers/media/platform/vsp1/vsp1.h
+++ b/drivers/media/platform/vsp1/vsp1.h
@@ -69,6 +69,8 @@ struct vsp1_device_info {
bool uapi;
 };
 
+#define vsp1_feature(vsp1, f) ((vsp1)->info->features & (f))
+
 struct vsp1_device {
struct device *dev;
const struct vsp1_device_info *info;
diff --git a/drivers/media/platform/vsp1/vsp1_drv.c 
b/drivers/media/platform/vsp1/vsp1_drv.c
index eed9516e25e1..6fa0019ffc6e 100644
--- a/drivers/media/platform/vsp1/vsp1_drv.c
+++ b/drivers/media/platform/vsp1/vsp1_drv.c
@@ -268,7 +268,7 @@ static int vsp1_create_entities(struct vsp1_device *vsp1)
}
 
/* Instantiate all the entities. */
-   if (vsp1->info->features & VSP1_HAS_BRS) {
+   if (vsp1_feature(vsp1, VSP1_HAS_BRS)) {
vsp1->brs = vsp1_bru_create(vsp1, VSP1_ENTITY_BRS);
if (IS_ERR(vsp1->brs)) {
ret = PTR_ERR(vsp1->brs);
@@ -278,7 +278,7 @@ static int vsp1_create_entities(struct vsp1_device *vsp1)
list_add_tail(>brs->entity.list_dev, >entities);
}
 
-   if (vsp1->info->features & VSP1_HAS_BRU) {
+   if (vsp1_feature(vsp1, VSP1_HAS_BRU)) {
vsp1->bru = vsp1_bru_create(vsp1, VSP1_ENTITY_BRU);
if (IS_ERR(vsp1->bru)) {
ret = PTR_ERR(vsp1->bru);
@@ -288,7 +288,7 @@ static int vsp1_create_entities(struct vsp1_device *vsp1)
list_add_tail(>bru->entity.list_dev, >entities);
}
 
-   if (vsp1->info->features & VSP1_HAS_CLU) {
+   if (vsp1_feature(vsp1, VSP1_HAS_CLU)) {
vsp1->clu = vsp1_clu_create(vsp1);
if (IS_ERR(vsp1->clu)) {
ret = PTR_ERR(vsp1->clu);
@@ -314,7 +314,7 @@ static int vsp1_create_entities(struct vsp1_device *vsp1)
 
list_add_tail(>hst->entity.list_dev, >entities);
 
-   if (vsp1->info->features & VSP1_HAS_HGO && vsp1->info->uapi) {
+   if (vsp1_feature(vsp1, VSP1_HAS_HGO) && vsp1->info->uapi) {
vsp1->hgo = vsp1_hgo_create(vsp1);
if (IS_ERR(vsp1->hgo)) {
ret = PTR_ERR(vsp1->hgo);
@@ -325,7 +325,7 @@ static int vsp1_create_entities(struct vsp1_device *vsp1)
  >entities);
}
 
-   if (vsp1->info->features & VSP1_HAS_HGT && vsp1->info->uapi) {
+   if (vsp1_feature(vsp1, VSP1_HAS_HGT) && vsp1->info->uapi) {
vsp1->hgt = vsp1_hgt_create(vsp1);
if (IS_ERR(vsp1->hgt)) {
ret = PTR_ERR(vsp1->hgt);
@@ -356,7 +356,7 @@ static int vsp1_create_entities(struct vsp1_device *vsp1)
}
}
 
-   if (vsp1->info->features & VSP1_HAS_LUT) {
+   if (vsp1_feature(vsp1, VSP1_HAS_LUT)) {
vsp1->lut = vsp1_lut_create(vsp1);
if (IS_ERR(vsp1->lut)) {
ret = PTR_ERR(vsp1->lut);
@@ -390,7 +390,7 @@ static int vsp1_create_entities(struct vsp1_device *vsp1)
}
}
 
-   if (vsp1->info->features & VSP1_HAS_SRU) {
+   if (vsp1_feature(vsp1, VSP1_HAS_SRU)) {
vsp1->sru = vsp1_sru_create(vsp1);
if (IS_ERR(vsp1->sru)) {
ret = PTR_ERR(vsp1->sru);
@@ -524,7 +524,7 @@ static int vsp1_device_init(struct vsp1_device *vsp1)
vsp1_write(vsp1, VI6_DPR_HSI_ROUTE, VI6_DPR_NODE_UNUSED);
vsp1_write(vsp1, VI6_DPR_BRU_ROUTE, VI6_DPR_NODE_UNUSED);
 
-   if (vsp1->info->features & VSP1_HAS_BRS)
+   if (vsp1_feature(vsp1, VSP1_HAS_BRS))
vsp1_write(vsp1, VI6_DPR_ILV_BRS_ROUTE, VI6_DPR_NODE_UNUSED);
 
vsp1_write(vsp1, VI6_DPR_HGO_SMPPT, (7 << VI6_DPR_SMPPT_TGW_SHIFT) |
diff --git a/drivers/media/platform/vsp1/vsp1_wpf.c 
b/drivers/media/platform/vsp1/vsp1_wpf.c
index 68218625549e..f90e474cf2cc 100644
--- a/drivers/media/platform/vsp1/vsp1_wpf.c
+++ b/drivers/media/platform/vsp1/vsp1_wpf.c
@@ -146,13 +146,13 @@ static int wpf_init_controls(struct vsp1_rwpf *wpf)
if (wpf->entity.index != 0) {
/* Only WPF0 supports flipping. */
num_flip_ctrls = 0;
-   } else if (vsp1->info->features & VSP1_HAS_WPF_HFLIP) {
+   } else if (vsp1_feature(vsp1, 

[PATCH v2 04/11] media: vsp1: Remove unused display list structure field

[Kieran Bingham]

The vsp1 reference in the vsp1_dl_body structure is not used.
Remove it.

Signed-off-by: Kieran Bingham 
---
 drivers/media/platform/vsp1/vsp1_dl.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
b/drivers/media/platform/vsp1/vsp1_dl.c
index 8162f4ce66eb..310ce81cd724 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -48,7 +48,6 @@ struct vsp1_dl_entry {
  * @list: entry in the display list list of bodies
  * @free: entry in the pool free body list
  * @pool: pool to which this body belongs
- * @vsp1: the VSP1 device
  * @entries: array of entries
  * @dma: DMA address of the entries
  * @size: size of the DMA memory in bytes
@@ -62,7 +61,6 @@ struct vsp1_dl_body {
refcount_t refcnt;
 
struct vsp1_dl_body_pool *pool;
-   struct vsp1_device *vsp1;
 
struct vsp1_dl_entry *entries;
dma_addr_t dma;
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 00/11] R-Car DU Interlaced support through VSP1

[Kieran Bingham]

The Gen3 R-Car DU devices make use of the VSP to handle frame processing.

In this series we implement support for handling interlaced pipelines by using
the auto-fld feature of the VSP hardware.

The implementation is preceded by some cleanup work and refactoring, through
patches 1 to 6. These are trivial and could be collected earlier and
independently if this series requires further revisions.

Patch 7 makes a key distinctive change to remove all existing support for
headerless display lists throughout the VSP1 driver, and ensures that all
pipelines use the same code path. This simplifies the code and reduces
opportunity for untested code paths to exist.

Patches 8, 9 and 10 implement the relevant support in the VSP1 driver, before
patch 11 finally enables the feature through the drm R-Car DU driver.

This series is based upon my previous TLB optimise and body rework (v7), and is
available from the following URL:

  git://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git
  tags/vsp1/du/interlaced/v2

ChangeLog:

v2:
 - media: vsp1: use kernel __packed for structures
became:
   media: vsp1: Remove packed attributes from aligned structures

 - media: vsp1: Add support for extended display list headers
   - No longer declares structs __packed

 - media: vsp1: Provide support for extended command pools
   - Fix spelling typo in commit message
   - constify, and staticify the instantiation of vsp1_extended_commands
   - s/autfld_cmds/autofld_cmds/
   - staticify cmd pool functions (Thanks kbuild-bot)

 - media: vsp1: Support Interlaced display pipelines
   - fix erroneous BIT value which enabled interlaced
   - fix field handling at frame_end interrupt

Kieran Bingham (11):
  media: vsp1: drm: Fix minor grammar error
  media: vsp1: Remove packed attributes from aligned structures
  media: vsp1: Rename dl_child to dl_next
  media: vsp1: Remove unused display list structure field
  media: vsp1: Clean up DLM objects on error
  media: vsp1: Provide VSP1 feature helper macro
  media: vsp1: Use header display lists for all WPF outputs linked to the DU
  media: vsp1: Add support for extended display list headers
  media: vsp1: Provide support for extended command pools
  media: vsp1: Support Interlaced display pipelines
  drm: rcar-du: Support interlaced video output through vsp1

 drivers/gpu/drm/rcar-du/rcar_du_crtc.c  |   1 +-
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c   |   3 +-
 drivers/media/platform/vsp1/vsp1.h  |   3 +-
 drivers/media/platform/vsp1/vsp1_dl.c   | 406 +++--
 drivers/media/platform/vsp1/vsp1_dl.h   |  32 +-
 drivers/media/platform/vsp1/vsp1_drm.c  |  13 +-
 drivers/media/platform/vsp1/vsp1_drv.c  |  23 +-
 drivers/media/platform/vsp1/vsp1_regs.h |   6 +-
 drivers/media/platform/vsp1/vsp1_rpf.c  |  72 +++-
 drivers/media/platform/vsp1/vsp1_rwpf.h |   1 +-
 drivers/media/platform/vsp1/vsp1_wpf.c  |   6 +-
 include/media/vsp1.h|   1 +-
 12 files changed, 455 insertions(+), 112 deletions(-)

base-commit: 397eb3811ec096d0ceefa1dbea2d0ae68feb0587
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 02/11] media: vsp1: Remove packed attributes from aligned structures

[Kieran Bingham]

The use of the packed attribute can cause a performance penalty for
all accesses to the struct members, as the compiler will assume that the
structure has the potential to have an unaligned base.

These structures are all correctly aligned and contain no holes, thus
the attribute is redundant and negatively impacts performance, so we
remove the attributes entirely.

Signed-off-by: Kieran Bingham 
---
v2
 - Remove attributes entirely

 drivers/media/platform/vsp1/vsp1_dl.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
b/drivers/media/platform/vsp1/vsp1_dl.c
index 37e2c984fbf3..85795b55a357 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -29,19 +29,19 @@
 struct vsp1_dl_header_list {
u32 num_bytes;
u32 addr;
-} __attribute__((__packed__));
+};
 
 struct vsp1_dl_header {
u32 num_lists;
struct vsp1_dl_header_list lists[8];
u32 next_header;
u32 flags;
-} __attribute__((__packed__));
+};
 
 struct vsp1_dl_entry {
u32 addr;
u32 data;
-} __attribute__((__packed__));
+};
 
 /**
  * struct vsp1_dl_body - Display list body
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] drm/sun4i: Handle DRM_BUS_FLAG_PIXDATA_*EDGE

[Giulio Benetti]

Handle both positive and negative dclk polarity,
according to bus_flags, taking care of this:

On A20 and similar SoCs, the only way to achieve Positive Edge
(Rising Edge), is setting dclk clock phase to 2/3(240°).
By default TCON works in Negative Edge(Falling Edge), this is why phase
is set to 0 in that case.
Unfortunately there's no way to logically invert dclk through IO_POL
register.
The only acceptable way to work, triple checked with scope,
is using clock phase set to 0° for Negative Edge and set to 240° for
Positive Edge.
On A33 and similar SoCs there would be a 90° phase option, but it divides
also dclk by 2.
This patch is a way to avoid quirks all around TCON and DOTCLOCK drivers
for using A33 90° phase divided by 2 and consequently increase code
complexity.

Signed-off-by: Giulio Benetti 
---
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 8ee87c2..3f1455d 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -345,6 +346,9 @@ static void sun4i_tcon0_mode_set_lvds(struct sun4i_tcon 
*tcon,
 static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon *tcon,
 const struct drm_display_mode *mode)
 {
+   struct drm_panel *panel = tcon->panel;
+   struct drm_connector *connector = panel->connector;
+   struct drm_display_info display_info = connector->display_info;
unsigned int bp, hsync, vsync;
u8 clk_delay;
u32 val = 0;
@@ -400,6 +404,27 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon 
*tcon,
if (mode->flags & DRM_MODE_FLAG_PVSYNC)
val |= SUN4I_TCON0_IO_POL_VSYNC_POSITIVE;
 
+   /*
+* On A20 and similar SoCs, the only way to achieve Positive Edge
+* (Rising Edge), is setting dclk clock phase to 2/3(240°).
+* By default TCON works in Negative Edge(Falling Edge),
+* this is why phase is set to 0 in that case.
+* Unfortunately there's no way to logically invert dclk through
+* IO_POL register.
+* The only acceptable way to work, triple checked with scope,
+* is using clock phase set to 0° for Negative Edge and set to 240°
+* for Positive Edge.
+* On A33 and similar SoCs there would be a 90° phase option,
+* but it divides also dclk by 2.
+* Following code is a way to avoid quirks all around TCON
+* and DOTCLOCK drivers.
+*/
+   if (display_info.bus_flags & DRM_BUS_FLAG_PIXDATA_POSEDGE)
+   clk_set_phase(tcon->dclk, 240);
+
+   if (display_info.bus_flags & DRM_BUS_FLAG_PIXDATA_NEGEDGE)
+   clk_set_phase(tcon->dclk, 0);
+
regmap_update_bits(tcon->regs, SUN4I_TCON0_IO_POL_REG,
   SUN4I_TCON0_IO_POL_HSYNC_POSITIVE | 
SUN4I_TCON0_IO_POL_VSYNC_POSITIVE,
   val);
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH] [v2] drm/i915/pmu: avoid -Wmaybe-uninitialized warning

[Tvrtko Ursulin]

On 13/03/2018 16:19, Arnd Bergmann wrote:

The conditional spinlock confuses gcc into thinking the 'flags' value
might contain uninitialized data:

drivers/gpu/drm/i915/i915_pmu.c: In function '__i915_pmu_event_read':
arch/x86/include/asm/paravirt_types.h:573:3: error: 'flags' may be used 
uninitialized in this function [-Werror=maybe-uninitialized]


Hm, how does paravirt_types.h comes into the picture?


The code is correct, but it's easy to see how the compiler gets confused
here. This avoids the problem by pulling the lock outside of the function
into its only caller.


Is it specific gcc version, specific options, or specific kernel config 
that this happens?


Strange that it hasn't been seen so far.

Regards,

Tvrtko


Fixes: 1fe699e30113 ("drm/i915/pmu: Fix sleep under atomic in RC6 readout")
Signed-off-by: Arnd Bergmann 
---
v2: removed unused function argument, fixed 'break' statement.
---
  drivers/gpu/drm/i915/i915_pmu.c | 25 ++---
  1 file changed, 10 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 4bc7aefa9541..d6b9b6b5fb98 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -412,10 +412,9 @@ static u64 __get_rc6(struct drm_i915_private *i915)
return val;
  }
  
-static u64 get_rc6(struct drm_i915_private *i915, bool locked)

+static u64 get_rc6(struct drm_i915_private *i915)
  {
  #if IS_ENABLED(CONFIG_PM)
-   unsigned long flags;
u64 val;
  
  	if (intel_runtime_pm_get_if_in_use(i915)) {

@@ -428,18 +427,12 @@ static u64 get_rc6(struct drm_i915_private *i915, bool 
locked)
 * previously.
 */
  
-		if (!locked)

-   spin_lock_irqsave(>pmu.lock, flags);
-
if (val >= i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur) {
i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur = 0;
i915->pmu.sample[__I915_SAMPLE_RC6].cur = val;
} else {
val = i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur;
}
-
-   if (!locked)
-   spin_unlock_irqrestore(>pmu.lock, flags);
} else {
struct pci_dev *pdev = i915->drm.pdev;
struct device *kdev = >dev;
@@ -452,9 +445,6 @@ static u64 get_rc6(struct drm_i915_private *i915, bool 
locked)
 * on top of the last known real value, as the approximated RC6
 * counter value.
 */
-   if (!locked)
-   spin_lock_irqsave(>pmu.lock, flags);
-
spin_lock_irqsave(>power.lock, flags2);
  
  		if (!i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur)

@@ -470,9 +460,6 @@ static u64 get_rc6(struct drm_i915_private *i915, bool 
locked)
val = jiffies_to_nsecs(val);
val += i915->pmu.sample[__I915_SAMPLE_RC6].cur;
i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur = val;
-
-   if (!locked)
-   spin_unlock_irqrestore(>pmu.lock, flags);
}
  
  	return val;

@@ -519,7 +506,15 @@ static u64 __i915_pmu_event_read(struct perf_event *event, 
bool locked)
val = count_interrupts(i915);
break;
case I915_PMU_RC6_RESIDENCY:
-   val = get_rc6(i915, locked);
+   if (!locked) {
+   unsigned long flags;
+
+   spin_lock_irqsave(>pmu.lock, flags);
+   val = get_rc6(i915);
+   spin_unlock_irqrestore(>pmu.lock, flags);
+   } else {
+   val = get_rc6(i915);
+   }
break;
}
}


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

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

[bugzilla-daemon]

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

--- Comment #22 from Germano Massullo  ---
(In reply to Michel Dänzer from comment #21)
> (In reply to Germano Massullo from comment #20)
> > I experienced the problem with both of them.
> 
> Did you check in Firefox about:support (look for "Driver Version") that it
> was actually using your self-built Mesa?
> 
> 
> BTW, I notice a lot of messages like
> 
>  [GFX1-]: ClientLayerManager::BeginTransaction with IPC channel down. GPU
> process may have died.
> 
> in the Firefox output you attached. Have you contacted Firefox folks about
> whether those are harmless, or how to get more information about them?


You are right. There were a ton of such messages, plus other messages
concerning load failures of radeonsi, and other libraries.
about:support contained so many errors, that I was surprised I even had the
opportunity to use Firefox for many days.

Since the libraries were available in the LD_LIBRARY_PATH and
LIBGL_DRIVERS_PATH, I tried to run

$ LD_LIBRARY_PATH='foo/mesa_n_version/usr/lib64/'
LIBGL_DRIVERS_PATH='foo/mesa_n_version/usr/lib64/dri' firefox

instead of

$ LD_LIBRARY_PATH='foo/mesa_n_version/usr/$LIB/'
LIBGL_DRIVERS_PATH='foo/mesa_n_version/usr/$LIB/dri' firefox

and I got no errors except for those few lines.


(/usr/lib64/firefox/firefox:8582): dconf-WARNING **: Unable to open
/var/lib/flatpak/exports/share/dconf/profile/user: Permission denied
ATTENTION: default value of option force_s3tc_enable overridden by environment.
WebGL(0x7f9488ce7800)::ForceLoseContext
WebGL(0x7f945e1b8000)::ForceLoseContext
[Child 8509, MediaPlayback #5] WARNING: Decoder=7fa5623cf400
state=DECODING_METADATA Decode metadata failed, shutting down decoder: file
/builddir/build/BUILD/firefox-58.0.2/dom/media/MediaDecoderStateMachine.cpp,
line 372
[Child 8509, MediaPlayback #5] WARNING: Decoder=7fa5623cf400 Decode error:
NS_ERROR_DOM_MEDIA_METADATA_ERR (0x806e0006): file
/builddir/build/BUILD/firefox-58.0.2/dom/media/MediaDecoderStateMachine.cpp,
line 3365


about:support is fine too.

I don't know why $LIB caused such problems to Firefox in Fedora 27.
I am actually testing again both Mesa 17.0.5 and 18.0.0

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

Re: [PATCH v2 0/7] Modernize vga_switcheroo by using device link for HDA

[Bjorn Helgaas]

On Sun, Mar 11, 2018 at 04:55:49PM +0100, Lukas Wunner wrote:
> On Tue, Mar 06, 2018 at 11:29:40AM +0100, Daniel Vetter wrote:
> > On Sat, Mar 03, 2018 at 10:53:24AM +0100, Lukas Wunner wrote:
> > > Modernize vga_switcheroo by using a device link to enforce a runtime PM
> > > dependency from an HDA controller to the GPU it's integrated into, v2.
> > > 
> > > https://github.com/l1k/linux/commits/switcheroo_devlink_v2
> > 
> > This all looks really reasonable and like a good cleanup, but it's a bit
> > too much detail so I'll punt review to someone else with more clue.
> 
> Patches [3/7] to [7/7] were reviewed by Peter Wu, the HDA bits in
> patch [5/7] additionally by Takashi.
> 
> Patch [2/7] was acked by Bjorn.  There was no ack for patch [1/7]
> (authored by Rafael), but it adressed the objection Bjorn raised
> against my original patch, so I'm assuming Bjorn is okay with it.
> (Bjorn, please let me know if that isn't the case.)

I am OK with it.  I sent an ack and possible minor changelog tweak.

I expect that you'll merge the whole series via drm-misc.

> The series has been tested on 5 systems, which raises the confidence:
> 2x AMD PowerXpress (Mike Lothian, Kai Heng Feng)
> 2x Nvidia Optimus (Denis Lisov, Peter Wu)
> 1x MacBook Pro
> 
> The issues found during Peter Wu's thorough testing appear to all
> be unrelated to this series, as per my e-mail yesterday.
> 
> If there are no objections, I plan to push the series to
> drm-misc-next by the middle of the coming week so that it
> would still catch the last train to 4.17.
> 
> Thanks,
> 
> Lukas
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/7] PCI: Restore config space on runtime resume despite being unbound

[Bjorn Helgaas]

On Sat, Mar 03, 2018 at 10:53:24AM +0100, Lukas Wunner wrote:
> From: Rafael J. Wysocki 
> 
> We leave PCI devices not bound to a driver in D0 during runtime suspend.
> But they may have a parent which is bound and can be transitioned to
> D3cold at runtime.  Once the parent goes to D3cold, the unbound child
> may go to D3cold as well.  When the child comes out of D3cold, its BARs
> are uninitialized and thus inaccessible when a driver tries to probe.

There's no clear way to tell whether a BAR is uninitialized.  At
power-up, the writable bits will be zero, which is a valid BAR value.
If enabled in PCI_COMMAND, the BAR is accessible and may conflict with
other devices.

Possible alternate wording:

  When the child goes to D3cold, its internal state, including
  configuration of BARs, MSI, ASPM, MPS, etc., is lost.

> Moreover configuration done during enumeration, e.g. ASPM and MPS, will
> be lost.
> 
> One example are recent hybrid graphics laptops which cut power to the
> discrete GPU when the root port above it goes to ACPI power state D3.
> Users may provoke this by unbinding the GPU driver and allowing runtime
> PM on the GPU via sysfs:  The PM core will then treat the GPU as
> "suspended", which in turn allows the root port to runtime suspend,
> causing the power resources listed in its _PR3 object to be powered off.
> The GPU's BARs will be uninitialized when a driver later probes it.
> 
> Another example are hybrid graphics laptops where the GPU itself (rather
> than the root port) is capable of runtime suspending to D3cold.  If the
> GPU's integrated HDA controller is not bound and the GPU's driver
> decides to runtime suspend to D3cold, the HDA controller's BARs will be
> uninitialized when a driver later probes it.
> 
> Fix by saving and restoring config space over a runtime suspend cycle
> even if the device is not bound.
> 
> Cc: Bjorn Helgaas 
> Signed-off-by: Rafael J. Wysocki 
> [lukas: add commit message, bikeshed code comments for clarity]
> Signed-off-by: Lukas Wunner 

Acked-by: Bjorn Helgaas 

> ---
> Changes since v1:
> - Replace patch to use pci_save_state() / pci_restore_state()
>   for consistency between runtime PM code path of bound and unbound
>   devices. (Rafael, Bjorn)
> 
>  drivers/pci/pci-driver.c | 17 +++--
>  1 file changed, 11 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
> index 3bed6beda051..6a67cdbd0e6a 100644
> --- a/drivers/pci/pci-driver.c
> +++ b/drivers/pci/pci-driver.c
> @@ -1224,11 +1224,14 @@ static int pci_pm_runtime_suspend(struct device *dev)
>   int error;
>  
>   /*
> -  * If pci_dev->driver is not set (unbound), the device should
> -  * always remain in D0 regardless of the runtime PM status
> +  * If pci_dev->driver is not set (unbound), we leave the device in D0,
> +  * but it may go to D3cold when the bridge above it runtime suspends.
> +  * Save its config space in case that happens.

Thanks for this clarification.

>*/
> - if (!pci_dev->driver)
> + if (!pci_dev->driver) {
> + pci_save_state(pci_dev);
>   return 0;
> + }
>  
>   if (!pm || !pm->runtime_suspend)
>   return -ENOSYS;
> @@ -1276,16 +1279,18 @@ static int pci_pm_runtime_resume(struct device *dev)
>   const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
>  
>   /*
> -  * If pci_dev->driver is not set (unbound), the device should
> -  * always remain in D0 regardless of the runtime PM status
> +  * Restoring config space is necessary even if the device is not bound
> +  * to a driver because although we left it in D0, it may have gone to
> +  * D3cold when the bridge above it runtime suspended.
>*/
> + pci_restore_standard_config(pci_dev);
> +
>   if (!pci_dev->driver)
>   return 0;
>  
>   if (!pm || !pm->runtime_resume)
>   return -ENOSYS;
>  
> - pci_restore_standard_config(pci_dev);
>   pci_fixup_device(pci_fixup_resume_early, pci_dev);
>   pci_enable_wake(pci_dev, PCI_D0, false);
>   pci_fixup_device(pci_fixup_resume, pci_dev);
> -- 
> 2.15.1
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/4] dma-buf: add optional invalidate_mappings callback

[Christian König]

Am 13.03.2018 um 17:00 schrieb Daniel Vetter:

On Tue, Mar 13, 2018 at 04:52:02PM +0100, Christian König wrote:

Am 13.03.2018 um 16:17 schrieb Daniel Vetter:
[SNIP]

Ok, so plan is to support fully pipeline moves and everything, with the
old sg tables lazily cleaned up. I was thinking more about evicting stuff
and throwing it out, where there's not going to be any new sg list but the
object is going to be swapped out.


Yes, exactly. Well my example was the unlikely case when the object is 
swapped out and immediately swapped in again because somebody needs it.




I think some state flow charts (we can do SVG or DOT) in the kerneldoc
would be sweet.Yeah, probably a good idea.


Sounds good and I find it great that you're volunteering for that :D

Ok seriously, my drawing capabilities are a bit underdeveloped. So I 
would prefer if somebody could at least help with that.



Re GPU might cause a deadlock: Isn't that already a problem if you hold
reservations of buffers used on other gpus, which want those reservations
to complete the gpu reset, but that gpu reset blocks some fence that the
reservation holder is waiting for?

Correct, that's why amdgpu and TTM tries quite hard to never wait for a
fence while a reservation object is locked.

We might have a fairly huge mismatch of expectations here :-/


What do you mean with that?


The only use case I haven't fixed so far is reaping deleted object during
eviction, but that is only a matter of my free time to fix it.

Yeah, this is the hard one.


Actually it isn't so hard, it's just that I didn't had time so far to 
clean it up and we never hit that issue so far during our reset testing.


The main point missing just a bit of functionality in the reservation 
object and Chris and I already had a good idea how to implement that.



In general the assumption is that dma_fence will get signalled no matter
what you're doing, assuming the only thing you need is to not block
interrupts. The i915 gpu reset logic to make that work is a bit a work of
art ...


Correct, but I don't understand why that is so hard on i915? Our GPU 
scheduler makes all of that rather trivial, e.g. fences either signal 
correctly or are aborted and set as erroneous after a timeout.



If we expect amdgpu and i915 to cooperate with shared buffers I guess one
has to give in. No idea how to do that best.


Again at least from amdgpu side I don't see much of an issue with that. 
So what exactly do you have in mind here?



We have tons of fun with deadlocks against GPU resets, and loots of
testcases, and I kinda get the impression amdgpu is throwing a lot of
issues under the rug through trylock tricks that shut up lockdep, but
don't fix much really.

Hui? Why do you think that? The only trylock I'm aware of is during eviction
and there it isn't a problem.

mmap fault handler had one too last time I looked, and it smelled fishy.


Good point, never wrapped my head fully around that one either.


btw adding cross-release lockdep annotations for fences will probably turn
up _lots_ more bugs in this area.

At least for amdgpu that should be handled by now.

You're sure? :-)


Yes, except for fallback paths and bootup self tests we simply never 
wait for fences while holding locks.



Trouble is that cross-release wasn't even ever enabled, much less anyone
typed the dma_fence annotations. And just cross-release alone turned up
_lost_ of deadlocks in i915 between fences, async workers (userptr, gpu
reset) and core mm stuff.


Yeah, we had lots of fun with the mm locks as well but as far as I know 
Felix and I already fixed all of them.


Christian.


I'd be seriously surprised if it wouldn't find an entire rats nest of
issues around dma_fence once we enable it.
-Daniel


+*
+* New mappings can be created immediately, but can't be used before the
+* exclusive fence in the dma_bufs reservation object is signaled.
+*/
+   void (*invalidate_mappings)(struct dma_buf_attachment *attach);

Bunch of questions about exact semantics, but I very much like this. And I
think besides those technical details, the overall approach seems sound.

Yeah this initial implementation was buggy like hell. Just wanted to confirm
that the idea is going in the right direction.

I wanted this 7 years ago, idea very much acked :-)


Ok, thanks. Good to know.

Christian.


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

Re: [PATCH] [v2] drm/i915/pmu: avoid -Wmaybe-uninitialized warning

[Chris Wilson]

Quoting Arnd Bergmann (2018-03-13 16:19:31)
> The conditional spinlock confuses gcc into thinking the 'flags' value
> might contain uninitialized data:
> 
> drivers/gpu/drm/i915/i915_pmu.c: In function '__i915_pmu_event_read':
> arch/x86/include/asm/paravirt_types.h:573:3: error: 'flags' may be used 
> uninitialized in this function [-Werror=maybe-uninitialized]
> 
> The code is correct, but it's easy to see how the compiler gets confused
> here. This avoids the problem by pulling the lock outside of the function
> into its only caller.
> 
> Fixes: 1fe699e30113 ("drm/i915/pmu: Fix sleep under atomic in RC6 readout")
> Signed-off-by: Arnd Bergmann 
Reviewed-by: Chris Wilson 
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105436] Blinking textures in UT2004 [bisected]

[bugzilla-daemon]

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

almos  changed:

   What|Removed |Added

   Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org
  Component|Drivers/Gallium/radeonsi|Mesa core
 QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org
Summary|Blinking textures in UT2004 |Blinking textures in UT2004
   ||[bisected]

--- Comment #2 from almos  ---
f314a532fdc7af8381586144d2631d9968331f05 is the first bad commit
commit f314a532fdc7af8381586144d2631d9968331f05
Author: Samuel Pitoiset 
Date:   Wed Jun 21 11:31:43 2017 +0200

mesa: do not trigger _NEW_TEXTURE_STATE in glActiveTexture()

This looks like useless because gl_context::Texture::CurrentUnit
is not used by _mesa_update_texture_state() and friends.

Signed-off-by: Samuel Pitoiset 
Reviewed-by: Brian Paul 

:04 04 c2a46b6dcce50edf810147e07de977f38d33533a
606c977b6357381074d205daf2815ebb93da1029 M  src

Adding back the FLUSH_VERTICES fixes the issue.

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

[Bug 102646] [dc] Screen flickering under amdgpu-experimental [buggy auto power profile]

[bugzilla-daemon]

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

--- Comment #25 from Ruben Harutyunyan  ---
Seems like this is a regression actually. I've managed bisect the commit which
caused the problems.

Last working commit:
https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-4.15-dc=8ee5702afdd48b5864c46418ad310d6a23c8e9ab

Breaking commit:
https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-4.15-dc=b9e56e41e0c55c2b2ab5919c5e167faa4200b083

Keep in mind that you need
https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-4.15-dc=9ba29fcb76a559078491adffc74f66bf92b9dbea
commit to be able to compile the kernel, but judging by the changes the merge
commit was the one that broke it.

Some more details:

1) Disabling/enabling FreeSync doesn't matter
2) Issue happens under Xorg KDE/Wayland Gnome/Xorg GNOME
3) HDMI or DP doesn't matter


I'd try to narrow it down to the exact part of the commit that causes the
issue, but I am having an issue with my Ryzen soft locking thread by thread
until a complete lockup happens when compiling with 16 threads.

-- 
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/pmu: avoid -Wmaybe-uninitialized warning

[Arnd Bergmann]

The conditional spinlock confuses gcc into thinking the 'flags' value
might contain uninitialized data:

drivers/gpu/drm/i915/i915_pmu.c: In function '__i915_pmu_event_read':
arch/x86/include/asm/paravirt_types.h:573:3: error: 'flags' may be used 
uninitialized in this function [-Werror=maybe-uninitialized]

The code is correct, but it's easy to see how the compiler gets confused
here. This avoids the problem by pulling the lock outside of the function
into its only caller.

Fixes: 1fe699e30113 ("drm/i915/pmu: Fix sleep under atomic in RC6 readout")
Signed-off-by: Arnd Bergmann 
---
v2: removed unused function argument, fixed 'break' statement.
---
 drivers/gpu/drm/i915/i915_pmu.c | 25 ++---
 1 file changed, 10 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 4bc7aefa9541..d6b9b6b5fb98 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -412,10 +412,9 @@ static u64 __get_rc6(struct drm_i915_private *i915)
return val;
 }
 
-static u64 get_rc6(struct drm_i915_private *i915, bool locked)
+static u64 get_rc6(struct drm_i915_private *i915)
 {
 #if IS_ENABLED(CONFIG_PM)
-   unsigned long flags;
u64 val;
 
if (intel_runtime_pm_get_if_in_use(i915)) {
@@ -428,18 +427,12 @@ static u64 get_rc6(struct drm_i915_private *i915, bool 
locked)
 * previously.
 */
 
-   if (!locked)
-   spin_lock_irqsave(>pmu.lock, flags);
-
if (val >= i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur) {
i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur = 0;
i915->pmu.sample[__I915_SAMPLE_RC6].cur = val;
} else {
val = i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur;
}
-
-   if (!locked)
-   spin_unlock_irqrestore(>pmu.lock, flags);
} else {
struct pci_dev *pdev = i915->drm.pdev;
struct device *kdev = >dev;
@@ -452,9 +445,6 @@ static u64 get_rc6(struct drm_i915_private *i915, bool 
locked)
 * on top of the last known real value, as the approximated RC6
 * counter value.
 */
-   if (!locked)
-   spin_lock_irqsave(>pmu.lock, flags);
-
spin_lock_irqsave(>power.lock, flags2);
 
if (!i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur)
@@ -470,9 +460,6 @@ static u64 get_rc6(struct drm_i915_private *i915, bool 
locked)
val = jiffies_to_nsecs(val);
val += i915->pmu.sample[__I915_SAMPLE_RC6].cur;
i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur = val;
-
-   if (!locked)
-   spin_unlock_irqrestore(>pmu.lock, flags);
}
 
return val;
@@ -519,7 +506,15 @@ static u64 __i915_pmu_event_read(struct perf_event *event, 
bool locked)
val = count_interrupts(i915);
break;
case I915_PMU_RC6_RESIDENCY:
-   val = get_rc6(i915, locked);
+   if (!locked) {
+   unsigned long flags;
+
+   spin_lock_irqsave(>pmu.lock, flags);
+   val = get_rc6(i915);
+   spin_unlock_irqrestore(>pmu.lock, flags);
+   } else {
+   val = get_rc6(i915);
+   }
break;
}
}
-- 
2.9.0

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

[PATCH RESEND v2 1/2] drm/xen-front: Add support for Xen PV display frontend

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko 

Add support for Xen para-virtualized frontend display driver.
Accompanying backend [1] is implemented as a user-space application
and its helper library [2], capable of running as a Weston client
or DRM master.
Configuration of both backend and frontend is done via
Xen guest domain configuration options [3].

Driver limitations:
 1. Only primary plane without additional properties is supported.
 2. Only one video mode supported which resolution is configured via XenStore.
 3. All CRTCs operate at fixed frequency of 60Hz.

1. Implement Xen bus state machine for the frontend driver according to
the state diagram and recovery flow from display para-virtualized
protocol: xen/interface/io/displif.h.

2. Read configuration values from Xen store according
to xen/interface/io/displif.h protocol:
  - read connector(s) configuration
  - read buffer allocation mode (backend/frontend)

3. Handle Xen event channels:
  - create for all configured connectors and publish
corresponding ring references and event channels in Xen store,
so backend can connect
  - implement event channels interrupt handlers
  - create and destroy event channels with respect to Xen bus state

4. Implement shared buffer handling according to the
para-virtualized display device protocol at xen/interface/io/displif.h:
  - handle page directories according to displif protocol:
- allocate and share page directories
- grant references to the required set of pages for the
  page directory
  - allocate xen balllooned pages via Xen balloon driver
with alloc_xenballooned_pages/free_xenballooned_pages
  - grant references to the required set of pages for the
shared buffer itself
  - implement pages map/unmap for the buffers allocated by the
backend (gnttab_map_refs/gnttab_unmap_refs)

5. Implement kernel modesetiing/connector handling using
DRM simple KMS helper pipeline:

- implement KMS part of the driver with the help of DRM
  simple pipepline helper which is possible due to the fact
  that the para-virtualized driver only supports a single
  (primary) plane:
  - initialize connectors according to XenStore configuration
  - handle frame done events from the backend
  - create and destroy frame buffers and propagate those
to the backend
  - propagate set/reset mode configuration to the backend on display
enable/disable callbacks
  - send page flip request to the backend and implement logic for
reporting backend IO errors on prepare fb callback

- implement virtual connector handling:
  - support only pixel formats suitable for single plane modes
  - make sure the connector is always connected
  - support a single video mode as per para-virtualized driver
configuration

6. Implement GEM handling depending on driver mode of operation:
depending on the requirements for the para-virtualized environment, namely
requirements dictated by the accompanying DRM/(v)GPU drivers running in both
host and guest environments, number of operating modes of para-virtualized
display driver are supported:
 - display buffers can be allocated by either frontend driver or backend
 - display buffers can be allocated to be contiguous in memory or not

Note! Frontend driver itself has no dependency on contiguous memory for
its operation.

6.1. Buffers allocated by the frontend driver.

The below modes of operation are configured at compile-time via
frontend driver's kernel configuration.

6.1.1. Front driver configured to use GEM CMA helpers
 This use-case is useful when used with accompanying DRM/vGPU driver in
 guest domain which was designed to only work with contiguous buffers,
 e.g. DRM driver based on GEM CMA helpers: such drivers can only import
 contiguous PRIME buffers, thus requiring frontend driver to provide
 such. In order to implement this mode of operation para-virtualized
 frontend driver can be configured to use GEM CMA helpers.

6.1.2. Front driver doesn't use GEM CMA
 If accompanying drivers can cope with non-contiguous memory then, to
 lower pressure on CMA subsystem of the kernel, driver can allocate
 buffers from system memory.

Note! If used with accompanying DRM/(v)GPU drivers this mode of operation
may require IOMMU support on the platform, so accompanying DRM/vGPU
hardware can still reach display buffer memory while importing PRIME
buffers from the frontend driver.

6.2. Buffers allocated by the backend

This mode of operation is run-time configured via guest domain configuration
through XenStore entries.

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

Note, while using this scenario the following should be 

[PATCH RESEND v2 0/2] drm/xen-front: Add support for Xen PV display frontend

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko 

Hello!

Resending with all the patches squashed on Daniel's request.

This patch series adds support for Xen [1] para-virtualized
frontend display driver. It implements the protocol from
include/xen/interface/io/displif.h [2].
Accompanying backend [3] is implemented as a user-space application
and its helper library [4], capable of running as a Weston client
or DRM master.
Configuration of both backend and frontend is done via 
Xen guest domain configuration options [5].

***
* Driver limitations
***
 1. Configuration options 1.1 (contiguous display buffers) and 2 (backend
allocated buffers) below are not supported at the same time.

 2. Only primary plane without additional properties is supported.

 3. Only one video mode supported which resolution is configured via XenStore.

 4. All CRTCs operate at fixed frequency of 60Hz.

***
* Driver modes of operation in terms of display buffers used
***
 Depending on the requirements for the para-virtualized environment, namely
 requirements dictated by the accompanying DRM/(v)GPU drivers running in both
 host and guest environments, number of operating modes of para-virtualized
 display driver are supported:
  - display buffers can be allocated by either frontend driver or backend
  - display buffers can be allocated to be contiguous in memory or not

 Note! Frontend driver itself has no dependency on contiguous memory for
   its operation.

***
* 1. Buffers allocated by the frontend driver.
***

 The below modes of operation are configured at compile-time via
 frontend driver's kernel configuration.

 1.1. Front driver configured to use GEM CMA helpers
  This use-case is useful when used with accompanying DRM/vGPU driver in
  guest domain which was designed to only work with contiguous buffers,
  e.g. DRM driver based on GEM CMA helpers: such drivers can only import
  contiguous PRIME buffers, thus requiring frontend driver to provide
  such. In order to implement this mode of operation para-virtualized
  frontend driver can be configured to use GEM CMA helpers.

 1.2. Front driver doesn't use GEM CMA
  If accompanying drivers can cope with non-contiguous memory then, to
  lower pressure on CMA subsystem of the kernel, driver can allocate
  buffers from system memory.

 Note! If used with accompanying DRM/(v)GPU drivers this mode of operation
   may require IOMMU support on the platform, so accompanying DRM/vGPU
   hardware can still reach display buffer memory while importing PRIME
   buffers from the frontend driver.

***
* 2. Buffers allocated by the backend
***

 This mode of operation is run-time configured via guest domain configuration
 through XenStore entries.

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


I would like to thank at least, but not at last the following
people/communities who helped this driver to happen ;)

1. My team at EPAM for continuous support
2. Xen community for answering tons of questions on different
modes of operation of the driver with respect to virtualized
environment.
3. Rob Clark for "GEM allocation for para-virtualized DRM driver" [6]
4. Maarten Lankhorst for "Atomic driver and old remove FB behavior" [7]
5. Ville Syrjälä for "Questions on page flips and atomic modeset" [8]


Changes since v1:
***
- use SPDX license identifier, set license to GPLv2 OR MIT
- changed midlayers to direct function calls, removed:
  - front_ops
  - gem_ops
- renamed xenbus_driver callbacks to align with exisitng PV drivers
- re-worked backend error handling with connector hotplug uevents
- removed vblank handling so user-space doesn't have an impression
  we really support that
- directly use front's mode_set in display enable/disable
- removed BUG_ON, error handling implemented
- moved driver documentation into Documentation/gpu
- other comments from Xen community addressed (Boris and Juergen)
- squashed Xen and DRM patches for better interrconnection 

[PATCH hwc v1] [RFC] drm_hwcomposer: Flatten composition using writeback connector

[Alexandru Gheorghe]

This patchset tries to add support for using writeback connector to
flatten a scene when it doesn't change for a while. This idea had
been floated around on IRC here [1] and here [2].

Developed on top of the latest writeback series, sent by Liviu here
[3].

Probably the patch should/could be broken in more patches, but since I
want to put this out there to get feedback, I kept them as a single
patch for now.

This change could be summarize as follow:
- Attach a writeback connector to the CRTC that's controlling a
display.
- Detect the scene did not change for a while(60 vblanks).
- Re-commit scene and get the composited scene through the writeback
connector.
- Commit the whole scene as a single plane.

Some areas that I consider important and I could use some
feedback/ideas:

1. Building the pipeline.
Currently, drm_hwcomposer allows to connect just a single connector
to a crtc. For now, I decided to treat the writeback connector as a
separate field inside DrmCrtc. I'm not sure if it's a good idea to try
to handle this in a unified way, since the writeback connector is such
a special connector. Regarding the allocation of writeback connectors,
my idea was to allocate writeback connector to the primary display
first and then continue allocating while respecting the display number. 0
gets a writeback before 1 and so on.

2. Heuristic for triggering the flattening.
I just created a VSyncWorker which will trigger the flattening of the
scene if it doesn't change for 60 consecutive vsyncs. The countdown
gets reset every time ValidateDisplay is called. This is a relatively
basic heuristic, so I'm open to suggestions.

3. Locking scheme corner cases.
The Vsynworker is a separate thread which will contend with
SurfaceFlinger for showing things on the screen. I tried to limit the
race window by resetting the countdown on ValidateDisplay and
explicitely checking that we still need to use the flatten scene before
commiting to get the writeback result or before applying the flattened
scene.

4. Building the DrmDisplayComposition for the flattened scene.
I kind of lost myself  in all types of layers/planes and compositions,
so I'm not sure if I'm correctly building the DrmDisplayComposition
object for the FlattenScene, it works and shows what I expect on the
screen. So, any feedback here is appreciated.

5. I see there is a drmcompositorworker.cpp which implemented the same
idea using the GPU, however that seems to not be used anymore, does
anyone know the rationale behind it?

Some unfinished/untested things:
- Make sure the DrmFrameBuffer allocates one of the formats reported
  in WRITEBACK_PIXEL_FORMATS.
- I'm using a hacked setup where, when needed it, the GL compositing is
  done by Surfaceflinger, so I'm not sure how well this changes are
  getting along with the GLCompositorWorker.

[1] 
https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel_names==2018-02-23
[2] 
https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel_names==2018-02-09
[3] https://lists.freedesktop.org/archives/dri-devel/2018-February/167703.html

Signed-off-by: Alexandru Gheorghe 
---
 drmconnector.cpp |  36 ++-
 drmconnector.h   |   8 +++
 drmcrtc.cpp  |  11 +++-
 drmcrtc.h|   8 ++-
 drmdisplaycompositor.cpp | 164 +--
 drmdisplaycompositor.h   |  16 +++--
 drmencoder.cpp   |  15 +
 drmencoder.h |   7 +-
 drmhwctwo.cpp|   1 +
 drmresources.cpp |  56 +++-
 drmresources.h   |   1 +
 11 files changed, 306 insertions(+), 17 deletions(-)

diff --git a/drmconnector.cpp b/drmconnector.cpp
index 145518f..2ed4f23 100644
--- a/drmconnector.cpp
+++ b/drmconnector.cpp
@@ -52,6 +52,23 @@ int DrmConnector::Init() {
 ALOGE("Could not get CRTC_ID property\n");
 return ret;
   }
+  if (writeback()) {
+ret = drm_->GetConnectorProperty(*this, "WRITEBACK_PIXEL_FORMATS", 
_pixel_formats_);
+if (ret) {
+  ALOGE("Could not get WRITEBACK_PIXEL_FORMATS connector_id = %d\n", id_);
+  return ret;
+}
+ret = drm_->GetConnectorProperty(*this, "WRITEBACK_FB_ID", 
_fb_id_);
+if (ret) {
+  ALOGE("Could not get WRITEBACK_FB_ID connector_id = %d\n", id_);
+  return ret;
+}
+ret = drm_->GetConnectorProperty(*this, "WRITEBACK_OUT_FENCE_PTR", 
_out_fence_);
+if (ret) {
+  ALOGE("Could not get WRITEBACK_OUT_FENCE_PTR connector_id = %d\n", id_);
+  return ret;
+}
+  }
   return 0;
 }

@@ -78,8 +95,13 @@ bool DrmConnector::external() const {
  type_ == DRM_MODE_CONNECTOR_VGA;
 }

+#define DRM_MODE_CONNECTOR_WRITEBACK   18
+bool DrmConnector::writeback() const {
+return type_ == DRM_MODE_CONNECTOR_WRITEBACK;
+}
+
 bool DrmConnector::valid_type() const {
-  return internal() || external();
+  return internal() || external() || writeback();
 }

 int DrmConnector::UpdateModes() {
@@ -130,6 

[PATCH RESEND v2 2/2] drm/xen-front: Provide kernel documentation

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko 

Provide kernel documentation for the Xen para-virtualized
frontend DRM driver.

Signed-off-by: Oleksandr Andrushchenko 
---
 Documentation/gpu/index.rst |  1 +
 Documentation/gpu/xen-front.rst | 77 +
 2 files changed, 78 insertions(+)
 create mode 100644 Documentation/gpu/xen-front.rst

diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst
index c36586dad29d..e31684af0a20 100644
--- a/Documentation/gpu/index.rst
+++ b/Documentation/gpu/index.rst
@@ -20,6 +20,7 @@ Linux GPU Driver Developer's Guide
vga-switcheroo
vgaarbiter
bridge/dw-hdmi
+   xen-front
todo
 
 .. only::  subproject and html
diff --git a/Documentation/gpu/xen-front.rst b/Documentation/gpu/xen-front.rst
new file mode 100644
index ..6ac0b75373c4
--- /dev/null
+++ b/Documentation/gpu/xen-front.rst
@@ -0,0 +1,77 @@
+
+Xen para-virtualized frontend driver
+
+This frontend driver implements Xen para-virtualized display
+according to the display protocol described at
+include/xen/interface/io/displif.h
+
+Driver modes of operation in terms of display buffers used
+==
+
+Depending on the requirements for the para-virtualized environment, namely
+requirements dictated by the accompanying DRM/(v)GPU drivers running in both
+host and guest environments, number of operating modes of para-virtualized
+display driver are supported:
+
+- display buffers can be allocated by either frontend driver or backend
+- display buffers can be allocated to be contiguous in memory or not
+
+Note! Frontend driver itself has no dependency on contiguous memory for
+its operation.
+
+Buffers allocated by the frontend driver
+
+
+The below modes of operation are configured at compile-time via
+frontend driver's kernel configuration:
+
+With GEM CMA helpers
+
+ This use-case is useful when used with accompanying DRM/vGPU driver in
+ guest domain which was designed to only work with contiguous buffers,
+ e.g. DRM driver based on GEM CMA helpers: such drivers can only import
+ contiguous PRIME buffers, thus requiring frontend driver to provide
+ such. In order to implement this mode of operation para-virtualized
+ frontend driver can be configured to use GEM CMA helpers.
+
+Without GEM CMA helpers
+~~~
+ If accompanying drivers can cope with non-contiguous memory then, to
+ lower pressure on CMA subsystem of the kernel, driver can allocate
+ buffers from system memory.
+
+ Note! If used with accompanying DRM/(v)GPU drivers this mode of operation
+ may require IOMMU support on the platform, so accompanying DRM/vGPU
+ hardware can still reach display buffer memory while importing PRIME
+ buffers from the frontend driver.
+
+Buffers allocated by the backend
+
+
+This mode of operation is run-time configured via guest domain configuration
+through XenStore entries.
+
+For systems which do not provide IOMMU support, but having specific
+requirements for display buffers it is possible to allocate such buffers
+at backend side and share those with the frontend.
+For example, if host domain is 1:1 mapped and has DRM/GPU hardware expecting
+physically contiguous memory, this allows implementing zero-copying
+use-cases.
+
+Note, while using this scenario the following should be considered:
+
+#. If guest domain dies then pages/grants received from the backend
+   cannot be claimed back
+
+#. Misbehaving guest may send too many requests to the
+   backend exhausting its grant references and memory
+   (consider this from security POV).
+
+Driver limitations
+==
+
+#. Only primary plane without additional properties is supported.
+
+#. Only one video mode per connector supported which is configured via 
XenStore.
+
+#. All CRTCs operate at fixed frequency of 60Hz.
-- 
2.7.4

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

Re: [PATCH 1/3] drm: Nuke the useless 'ret' variable from drm_mode_convert_umode()

[Daniel Vetter]

On Tue, Mar 13, 2018 at 05:07:57PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> No need to store the return value in a variable since we don't have to
> do any unwinding.
> 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_modes.c | 15 ---
>  1 file changed, 4 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index 5a8033fda4e3..4157250140b0 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -1596,12 +1596,8 @@ int drm_mode_convert_umode(struct drm_device *dev,
>  struct drm_display_mode *out,
>  const struct drm_mode_modeinfo *in)
>  {
> - int ret = -EINVAL;
> -
> - if (in->clock > INT_MAX || in->vrefresh > INT_MAX) {
> - ret = -ERANGE;
> - goto out;
> - }
> + if (in->clock > INT_MAX || in->vrefresh > INT_MAX)
> + return -ERANGE;
>  
>   out->clock = in->clock;
>   out->hdisplay = in->hdisplay;
> @@ -1622,14 +1618,11 @@ int drm_mode_convert_umode(struct drm_device *dev,
>  
>   out->status = drm_mode_validate_driver(dev, out);
>   if (out->status != MODE_OK)
> - goto out;
> + return -EINVAL;
>  
>   drm_mode_set_crtcinfo(out, CRTC_INTERLACE_HALVE_V);
>  
> - ret = 0;
> -
> -out:
> - return ret;
> + return 0;
>  }
>  
>  /**
> -- 
> 2.16.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [RfC PATCH] Add udmabuf misc device

[Daniel Vetter]

On Tue, Mar 13, 2018 at 04:48:26PM +0100, Gerd Hoffmann wrote:
> A driver to let userspace turn iovecs into dma-bufs.
> 
> Use case:  Allows qemu pass around dmabufs for the guest framebuffer.
> https://www.kraxel.org/cgit/qemu/log/?h=sirius/udmabuf has an
> experimental patch.
> 
> Also allows qemu to export guest virtio-gpu resources as host dmabufs.
> Should be possible to use it to display guest wayland windows on the
> host display server.  virtio-gpu ressources can be chunked so we will
> actually need multiple iovec entries.  UNTESTED.
> 
> Want collect some feedback on the general approach with this RfC series.
> Can this work?  If not, better ideas?
> 
> Question:  Must this be hooked into some kind of mlock accounting, to
> limit the amout of memory userspace is allowed to pin this way?  Or will
> get_user_pages_fast() handle that for me?

Either mlock account (because it's mlocked defacto), and get_user_pages
won't do that for you.

Or you write the full-blown userptr implementation, including mmu_notifier
support (see i915 or amdgpu), but that also requires Christian Königs
latest ->invalidate_mapping RFC for dma-buf (since atm exporting userptr
buffers is a no-go).

> 
> Known issue:  Driver API isn't complete yet.  Need add some flags, for
> example to support read-only buffers.

dma-buf has no concept of read-only. I don't think we can even enforce
that (not many iommus can enforce this iirc), so pretty much need to
require r/w memory.

> Cc: David Airlie 
> Cc: Tomeu Vizoso 
> Signed-off-by: Gerd Hoffmann 

btw there's also the hyperdmabuf stuff from the xen folks, but imo their
solution of forwarding the entire dma-buf api is over the top. This here
looks _much_ better, pls cc all the hyperdmabuf people on your next
version.

Overall I like the idea, but too lazy to review. Can maybe be bribed :-)

Oh, some kselftests for this stuff would be lovely.
-Daniel
> ---
>  include/uapi/linux/udmabuf.h |  21 
>  drivers/dma-buf/udmabuf.c| 250 
> +++
>  drivers/dma-buf/Kconfig  |   7 ++
>  drivers/dma-buf/Makefile |   1 +
>  4 files changed, 279 insertions(+)
>  create mode 100644 include/uapi/linux/udmabuf.h
>  create mode 100644 drivers/dma-buf/udmabuf.c
> 
> diff --git a/include/uapi/linux/udmabuf.h b/include/uapi/linux/udmabuf.h
> new file mode 100644
> index 00..fd2fa441fe
> --- /dev/null
> +++ b/include/uapi/linux/udmabuf.h
> @@ -0,0 +1,21 @@
> +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
> +#ifndef _UAPI_LINUX_UDMABUF_H
> +#define _UAPI_LINUX_UDMABUF_H
> +
> +#include 
> +#include 
> +
> +struct udmabuf_iovec {
> + __u64 base;
> + __u64 len;
> +};
> +
> +struct udmabuf_create {
> + __u32 flags;
> + __u32 niov;
> + struct udmabuf_iovec iovs[];
> +};
> +
> +#define UDMABUF_CREATE _IOW(0x42, 0x23, struct udmabuf_create)
> +
> +#endif /* _UAPI_LINUX_UDMABUF_H */
> diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
> new file mode 100644
> index 00..ec012d7ac7
> --- /dev/null
> +++ b/drivers/dma-buf/udmabuf.c
> @@ -0,0 +1,250 @@
> +/*
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +struct udmabuf {
> + u32 pagecount;
> + struct page **pages;
> +};
> +
> +static int udmabuf_vm_fault(struct vm_fault *vmf)
> +{
> + struct vm_area_struct *vma = vmf->vma;
> + struct udmabuf *ubuf = vma->vm_private_data;
> +
> + if (WARN_ON(vmf->pgoff >= ubuf->pagecount))
> + return VM_FAULT_SIGBUS;
> +
> + vmf->page = ubuf->pages[vmf->pgoff];
> + get_page(vmf->page);
> + return 0;
> +}
> +
> +static const struct vm_operations_struct udmabuf_vm_ops = {
> + .fault = udmabuf_vm_fault,
> +};
> +
> +static int mmap_udmabuf(struct dma_buf *buf, struct vm_area_struct *vma)
> +{
> + struct udmabuf *ubuf = buf->priv;
> +
> + if ((vma->vm_flags & VM_SHARED) == 0)
> + return -EINVAL;
> +
> + vma->vm_ops = _vm_ops;
> + vma->vm_private_data = ubuf;
> + return 0;
> +}
> +
> +static struct sg_table *map_udmabuf(struct dma_buf_attachment *at,
> + enum dma_data_direction direction)
> +{
> + struct udmabuf *ubuf = at->dmabuf->priv;
> + struct sg_table *sg;
> +
> + sg = kzalloc(sizeof(*sg), GFP_KERNEL);
> + if (!sg)
> + goto err1;
> + if (sg_alloc_table_from_pages(sg, ubuf->pages, ubuf->pagecount,
> +   0, ubuf->pagecount << PAGE_SHIFT,
> +   GFP_KERNEL) < 0)
> + goto err2;
> + if (!dma_map_sg(at->dev, sg->sgl, sg->nents, direction))
> + 

Re: [PATCH 1/4] dma-buf: add optional invalidate_mappings callback

[Daniel Vetter]

On Tue, Mar 13, 2018 at 04:52:02PM +0100, Christian König wrote:
> Am 13.03.2018 um 16:17 schrieb Daniel Vetter:
> > [SNIP]
> > > > I think a helper which both unmaps _and_ waits for all the fences to 
> > > > clear
> > > > would be best, with some guarantees that it'll either fail or all the
> > > > mappings _will_ be gone. The locking for that one will be hilarious, 
> > > > since
> > > > we need to figure out dmabuf->lock vs. the reservation. I kinda prefer 
> > > > we
> > > > throw away the dmabuf->lock and superseed it entirely by the reservation
> > > > lock.
> > > Big NAK on that. The whole API is asynchronously, e.g. we never block for
> > > any operation to finish.
> > > 
> > > Otherwise you run into big trouble with cross device GPU resets and stuff
> > > like that.
> > But how will the unmapping work then? You can't throw the sg list away
> > before the dma stopped. The dma only stops once the fence is signalled.
> > The importer can't call dma_buf_detach because the reservation lock is
> > hogged already by the exporter trying to unmap everything.
> > 
> > How is this supposed to work?
> 
> Even after invalidation the sg list stays alive until it is explicitly
> destroyed by the importer using dma_buf_unmap_attachment() which in turn is
> only allowed after all fences have signaled.
> 
> The implementation is in ttm_bo_pipeline_gutting(), basically we use the
> same functionality as for pipelined moves/evictions which hangs the old
> backing store on a dummy object and destroys it after all fences signaled.
> 
> While the old sg list is still about to be destroyed the importer can
> request a new sg list for the new location of the DMA-buf using
> dma_buf_map_attachment(). This new location becomes valid after the move
> fence in the reservation object is signaled.
> 
> So from the CPU point of view multiple sg list could exists at the same time
> which allows us to have a seamless transition from the old to the new
> location from the GPU point of view.

Ok, so plan is to support fully pipeline moves and everything, with the
old sg tables lazily cleaned up. I was thinking more about evicting stuff
and throwing it out, where there's not going to be any new sg list but the
object is going to be swapped out.

I think some state flow charts (we can do SVG or DOT) in the kerneldoc
would be sweet.

> > Re GPU might cause a deadlock: Isn't that already a problem if you hold
> > reservations of buffers used on other gpus, which want those reservations
> > to complete the gpu reset, but that gpu reset blocks some fence that the
> > reservation holder is waiting for?
> 
> Correct, that's why amdgpu and TTM tries quite hard to never wait for a
> fence while a reservation object is locked.

We might have a fairly huge mismatch of expectations here :-/

> The only use case I haven't fixed so far is reaping deleted object during
> eviction, but that is only a matter of my free time to fix it.

Yeah, this is the hard one.

In general the assumption is that dma_fence will get signalled no matter
what you're doing, assuming the only thing you need is to not block
interrupts. The i915 gpu reset logic to make that work is a bit a work of
art ...

If we expect amdgpu and i915 to cooperate with shared buffers I guess one
has to give in. No idea how to do that best.

> > We have tons of fun with deadlocks against GPU resets, and loots of
> > testcases, and I kinda get the impression amdgpu is throwing a lot of
> > issues under the rug through trylock tricks that shut up lockdep, but
> > don't fix much really.
> 
> Hui? Why do you think that? The only trylock I'm aware of is during eviction
> and there it isn't a problem.

mmap fault handler had one too last time I looked, and it smelled fishy.

> > btw adding cross-release lockdep annotations for fences will probably turn
> > up _lots_ more bugs in this area.
> 
> At least for amdgpu that should be handled by now.

You're sure? :-)

Trouble is that cross-release wasn't even ever enabled, much less anyone
typed the dma_fence annotations. And just cross-release alone turned up
_lost_ of deadlocks in i915 between fences, async workers (userptr, gpu
reset) and core mm stuff.

I'd be seriously surprised if it wouldn't find an entire rats nest of
issues around dma_fence once we enable it.
-Daniel

> > > > > +  *
> > > > > +  * New mappings can be created immediately, but can't be used 
> > > > > before the
> > > > > +  * exclusive fence in the dma_bufs reservation object is 
> > > > > signaled.
> > > > > +  */
> > > > > + void (*invalidate_mappings)(struct dma_buf_attachment *attach);
> > > > Bunch of questions about exact semantics, but I very much like this. 
> > > > And I
> > > > think besides those technical details, the overall approach seems sound.
> > > Yeah this initial implementation was buggy like hell. Just wanted to 
> > > confirm
> > > that the idea is going in the right direction.
> > I wanted this 7 years ago, idea very much acked 

Re: [RFC PATCH 00/13] SVM (share virtual memory) with HMM in nouveau

[Jerome Glisse]

On Mon, Mar 12, 2018 at 11:14:47PM -0700, John Hubbard wrote:
> On 03/12/2018 10:50 AM, Jerome Glisse wrote:

[...]

> Yes, on NVIDIA GPUs, the Host/FIFO unit is limited to 40-bit addresses, so
> things such as the following need to be below (1 << 40), and also accessible 
> to both CPU (user space) and GPU hardware. 
> -- command buffers (CPU user space driver fills them, GPU consumes them), 
> -- semaphores (here, a GPU-centric term, rather than OS-type: these are
>memory locations that, for example, the GPU hardware might write to, in
>order to indicate work completion; there are other uses as well), 
> -- a few other things most likely (this is not a complete list).
> 
> So what I'd tentatively expect that to translate into in the driver stack is, 
> approximately:
> 
> -- User space driver code mmap's an area below (1 << 40). It's hard to 
> avoid this,
>given that user space needs access to the area (for filling out command
>buffers and monitoring semaphores, that sort of thing). Then 
> suballocate
>from there using mmap's MAP_FIXED or (future-ish) MAP_FIXED_SAFE flags.
> 
>...glancing at the other fork of this thread, I think that is exactly 
> what
>Felix is saying, too. So that's good.
> 
> -- The user space program sits above the user space driver, and although 
> the
>program could, in theory, interfere with this mmap'd area, that would 
> be
>wrong in the same way that mucking around with malloc'd areas (outside 
> of
>malloc() itself) is wrong. So I don't see any particular need to do 
> much
>more than the above.

I am worried that rogue program (i am not worried about buggy program
if people shoot themself in the foot they should feel the pain) could
use that to abuse channel to do something harmful. I am not familiar
enough with the hardware to completely rule out such scenario.

I do believe hardware with userspace queue support have the necessary
boundary to keep thing secure as i would assume for those the hardware
engineers had to take security into consideration.

Note that in my patchset the code that monitor the special vma is small
something like 20lines of code that only get call if something happen
to the reserved area. So i believe it is worth having such thing, cost
is low for little extra peace of mind :)

Cheers,
Jérôme
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/4] dma-buf: add optional invalidate_mappings callback

[Christian König]

Am 13.03.2018 um 16:17 schrieb Daniel Vetter:

[SNIP]

I think a helper which both unmaps _and_ waits for all the fences to clear
would be best, with some guarantees that it'll either fail or all the
mappings _will_ be gone. The locking for that one will be hilarious, since
we need to figure out dmabuf->lock vs. the reservation. I kinda prefer we
throw away the dmabuf->lock and superseed it entirely by the reservation
lock.

Big NAK on that. The whole API is asynchronously, e.g. we never block for
any operation to finish.

Otherwise you run into big trouble with cross device GPU resets and stuff
like that.

But how will the unmapping work then? You can't throw the sg list away
before the dma stopped. The dma only stops once the fence is signalled.
The importer can't call dma_buf_detach because the reservation lock is
hogged already by the exporter trying to unmap everything.

How is this supposed to work?


Even after invalidation the sg list stays alive until it is explicitly 
destroyed by the importer using dma_buf_unmap_attachment() which in turn 
is only allowed after all fences have signaled.


The implementation is in ttm_bo_pipeline_gutting(), basically we use the 
same functionality as for pipelined moves/evictions which hangs the old 
backing store on a dummy object and destroys it after all fences signaled.


While the old sg list is still about to be destroyed the importer can 
request a new sg list for the new location of the DMA-buf using 
dma_buf_map_attachment(). This new location becomes valid after the move 
fence in the reservation object is signaled.


So from the CPU point of view multiple sg list could exists at the same 
time which allows us to have a seamless transition from the old to the 
new location from the GPU point of view.



Re GPU might cause a deadlock: Isn't that already a problem if you hold
reservations of buffers used on other gpus, which want those reservations
to complete the gpu reset, but that gpu reset blocks some fence that the
reservation holder is waiting for?


Correct, that's why amdgpu and TTM tries quite hard to never wait for a 
fence while a reservation object is locked.


The only use case I haven't fixed so far is reaping deleted object 
during eviction, but that is only a matter of my free time to fix it.



We have tons of fun with deadlocks against GPU resets, and loots of
testcases, and I kinda get the impression amdgpu is throwing a lot of
issues under the rug through trylock tricks that shut up lockdep, but
don't fix much really.


Hui? Why do you think that? The only trylock I'm aware of is during 
eviction and there it isn't a problem.



btw adding cross-release lockdep annotations for fences will probably turn
up _lots_ more bugs in this area.


At least for amdgpu that should be handled by now.


+*
+* New mappings can be created immediately, but can't be used before the
+* exclusive fence in the dma_bufs reservation object is signaled.
+*/
+   void (*invalidate_mappings)(struct dma_buf_attachment *attach);

Bunch of questions about exact semantics, but I very much like this. And I
think besides those technical details, the overall approach seems sound.

Yeah this initial implementation was buggy like hell. Just wanted to confirm
that the idea is going in the right direction.

I wanted this 7 years ago, idea very much acked :-)


Ok, thanks. Good to know.

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

[RfC PATCH] Add udmabuf misc device

[Gerd Hoffmann]

A driver to let userspace turn iovecs into dma-bufs.

Use case:  Allows qemu pass around dmabufs for the guest framebuffer.
https://www.kraxel.org/cgit/qemu/log/?h=sirius/udmabuf has an
experimental patch.

Also allows qemu to export guest virtio-gpu resources as host dmabufs.
Should be possible to use it to display guest wayland windows on the
host display server.  virtio-gpu ressources can be chunked so we will
actually need multiple iovec entries.  UNTESTED.

Want collect some feedback on the general approach with this RfC series.
Can this work?  If not, better ideas?

Question:  Must this be hooked into some kind of mlock accounting, to
limit the amout of memory userspace is allowed to pin this way?  Or will
get_user_pages_fast() handle that for me?

Known issue:  Driver API isn't complete yet.  Need add some flags, for
example to support read-only buffers.

Cc: David Airlie 
Cc: Tomeu Vizoso 
Signed-off-by: Gerd Hoffmann 
---
 include/uapi/linux/udmabuf.h |  21 
 drivers/dma-buf/udmabuf.c| 250 +++
 drivers/dma-buf/Kconfig  |   7 ++
 drivers/dma-buf/Makefile |   1 +
 4 files changed, 279 insertions(+)
 create mode 100644 include/uapi/linux/udmabuf.h
 create mode 100644 drivers/dma-buf/udmabuf.c

diff --git a/include/uapi/linux/udmabuf.h b/include/uapi/linux/udmabuf.h
new file mode 100644
index 00..fd2fa441fe
--- /dev/null
+++ b/include/uapi/linux/udmabuf.h
@@ -0,0 +1,21 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+#ifndef _UAPI_LINUX_UDMABUF_H
+#define _UAPI_LINUX_UDMABUF_H
+
+#include 
+#include 
+
+struct udmabuf_iovec {
+   __u64 base;
+   __u64 len;
+};
+
+struct udmabuf_create {
+   __u32 flags;
+   __u32 niov;
+   struct udmabuf_iovec iovs[];
+};
+
+#define UDMABUF_CREATE _IOW(0x42, 0x23, struct udmabuf_create)
+
+#endif /* _UAPI_LINUX_UDMABUF_H */
diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
new file mode 100644
index 00..ec012d7ac7
--- /dev/null
+++ b/drivers/dma-buf/udmabuf.c
@@ -0,0 +1,250 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+struct udmabuf {
+   u32 pagecount;
+   struct page **pages;
+};
+
+static int udmabuf_vm_fault(struct vm_fault *vmf)
+{
+   struct vm_area_struct *vma = vmf->vma;
+   struct udmabuf *ubuf = vma->vm_private_data;
+
+   if (WARN_ON(vmf->pgoff >= ubuf->pagecount))
+   return VM_FAULT_SIGBUS;
+
+   vmf->page = ubuf->pages[vmf->pgoff];
+   get_page(vmf->page);
+   return 0;
+}
+
+static const struct vm_operations_struct udmabuf_vm_ops = {
+   .fault = udmabuf_vm_fault,
+};
+
+static int mmap_udmabuf(struct dma_buf *buf, struct vm_area_struct *vma)
+{
+   struct udmabuf *ubuf = buf->priv;
+
+   if ((vma->vm_flags & VM_SHARED) == 0)
+   return -EINVAL;
+
+   vma->vm_ops = _vm_ops;
+   vma->vm_private_data = ubuf;
+   return 0;
+}
+
+static struct sg_table *map_udmabuf(struct dma_buf_attachment *at,
+   enum dma_data_direction direction)
+{
+   struct udmabuf *ubuf = at->dmabuf->priv;
+   struct sg_table *sg;
+
+   sg = kzalloc(sizeof(*sg), GFP_KERNEL);
+   if (!sg)
+   goto err1;
+   if (sg_alloc_table_from_pages(sg, ubuf->pages, ubuf->pagecount,
+ 0, ubuf->pagecount << PAGE_SHIFT,
+ GFP_KERNEL) < 0)
+   goto err2;
+   if (!dma_map_sg(at->dev, sg->sgl, sg->nents, direction))
+   goto err3;
+
+   return sg;
+
+err3:
+   sg_free_table(sg);
+err2:
+   kfree(sg);
+err1:
+   return ERR_PTR(-ENOMEM);
+}
+
+static void unmap_udmabuf(struct dma_buf_attachment *at,
+ struct sg_table *sg,
+ enum dma_data_direction direction)
+{
+   sg_free_table(sg);
+   kfree(sg);
+}
+
+static void release_udmabuf(struct dma_buf *buf)
+{
+   struct udmabuf *ubuf = buf->priv;
+   pgoff_t pg;
+
+   for (pg = 0; pg < ubuf->pagecount; pg++)
+   put_page(ubuf->pages[pg]);
+   kfree(ubuf->pages);
+   kfree(ubuf);
+}
+
+static void *kmap_atomic_udmabuf(struct dma_buf *buf, unsigned long offset)
+{
+   struct udmabuf *ubuf = buf->priv;
+   struct page *page = ubuf->pages[offset >> PAGE_SHIFT];
+
+   return kmap_atomic(page);
+}
+
+static void *kmap_udmabuf(struct dma_buf *buf, unsigned long offset)
+{
+   struct udmabuf *ubuf = buf->priv;
+   struct page *page = ubuf->pages[offset >> PAGE_SHIFT];
+
+   return kmap(page);
+}
+
+static struct dma_buf_ops udmabuf_ops = {
+   

Re: [PATCH v2 1/3] drm: Add the optional .fb_modifier() hook

[Ville Syrjälä]

On Tue, Mar 13, 2018 at 04:35:02PM +0100, Michel Dänzer wrote:
> On 2018-03-13 04:20 PM, Daniel Vetter wrote:
> > On Tue, Mar 13, 2018 at 03:38:38PM +0100, Michel Dänzer wrote:
> >> On 2018-03-13 03:28 PM, Ville Syrjala wrote:
> >>> From: Ville Syrjälä 
> >>>
> >>> To make it possible for the core to check the fb pixel format and
> >>> modifier, we need to first ask the driver to deduce the modifier
> >>> when the request does not explicitly specify one.
> >>>
> >>> Add a new .fb_modifier() hook for that purpose and convert i915
> >>> and vc4 to make use if it. All other drivers seem to currently
> >>> assume linear when the request does not specify anything else,
> >>> [...]
> >>
> >> That's not true at least for the amdgpu and radeon drivers. The tiling
> >> mode is communicated via BO metadata.
> > 
> > But atm amdgpu and radeon also don't support explicit modifiers in the
> > kernel driver, so it again all checks out. Or should at least.
> 
> Sounds like I misunderstood that this is trying to guess modifiers for
> all drivers. So far, so good if so.

Somehow I convinced myself that amdgpu already had some modifier
support. But looks like I was mistaken.

> > Once you add modifier support, you need to wire up all the bits and the
> > rigth default selection, and it should again pan out.
> 
> Well, this change allows a driver not to wire up the fb_modifier hook,
> and just assumes linear in that case. Seems like an accident waiting to
> happen, but I'll leave it to you guys.

That's already the case with the current code. mode_cmd->modifier[0]
will be 0 when when DRM_MODE_FB_MODIFIERS isn't specified, which is the
same thing as DRM_FORMAT_MOD_LINEAR. So if the driver doesn't change
it before calling drm_helper_mode_fill_fb_struct() you end up with
fb->modifier == DRM_FORMAT_MOD_LINEAR.

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

Re: [PATCH v2 1/3] drm: Add the optional .fb_modifier() hook

[Michel Dänzer]

On 2018-03-13 04:20 PM, Daniel Vetter wrote:
> On Tue, Mar 13, 2018 at 03:38:38PM +0100, Michel Dänzer wrote:
>> On 2018-03-13 03:28 PM, Ville Syrjala wrote:
>>> From: Ville Syrjälä 
>>>
>>> To make it possible for the core to check the fb pixel format and
>>> modifier, we need to first ask the driver to deduce the modifier
>>> when the request does not explicitly specify one.
>>>
>>> Add a new .fb_modifier() hook for that purpose and convert i915
>>> and vc4 to make use if it. All other drivers seem to currently
>>> assume linear when the request does not specify anything else,
>>> [...]
>>
>> That's not true at least for the amdgpu and radeon drivers. The tiling
>> mode is communicated via BO metadata.
> 
> But atm amdgpu and radeon also don't support explicit modifiers in the
> kernel driver, so it again all checks out. Or should at least.

Sounds like I misunderstood that this is trying to guess modifiers for
all drivers. So far, so good if so.


> Once you add modifier support, you need to wire up all the bits and the
> rigth default selection, and it should again pan out.

Well, this change allows a driver not to wire up the fb_modifier hook,
and just assumes linear in that case. Seems like an accident waiting to
happen, but I'll leave it to you guys.


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

Re: [RFC PATCH 00/13] SVM (share virtual memory) with HMM in nouveau

[Felix Kuehling]

On 2018-03-13 10:28 AM, Jerome Glisse wrote:
> On Mon, Mar 12, 2018 at 02:28:42PM -0400, Felix Kuehling wrote:
>> On 2018-03-10 10:01 AM, Christian König wrote:
 To accomodate those we need to
 create a "hole" inside the process address space. This patchset have
 a hack for that (patch 13 HACK FOR HMM AREA), it reserves a range of
 device file offset so that process can mmap this range with PROT_NONE
 to create a hole (process must make sure the hole is below 1 << 40).
 I feel un-easy of doing it this way but maybe it is ok with other
 folks.
>>> Well we have essentially the same problem with pre gfx9 AMD hardware.
>>> Felix might have some advise how it was solved for HSA. 
>> For pre-gfx9 hardware we reserve address space in user mode using a big
>> mmap PROT_NONE call at application start. Then we manage the address
>> space in user mode and use MAP_FIXED to map buffers at specific
>> addresses within the reserved range.
>>
>> The big address space reservation causes issues for some debugging tools
>> (clang-sanitizer was mentioned to me), so with gfx9 we're going to get
>> rid of this address space reservation.
> What do you need those mapping for ? What kind of object (pm4 packet
> command buffer, GPU semaphore | fence, ...) ? Kernel private object ?
> On nv we need it for the main command buffer ring which we do not want
> to expose to application.

On pre-gfx9 hardware the GPU virtual address space is limted to 40 bits
for all hardware blocks. So all GPU-accessible memory must be below 40-bits.

> Thus for nv gpu we need kernel to monitor this PROT_NONE region to make
> sure that i never got unmapped, resize, move ... this is me fearing a
> rogue userspace that munmap and try to abuse some bug in SVM/GPU driver
> to abuse object map behind those fix mapping.

We mmap PROT_NONE anonymous memory and we don't have any safeguards
against rogue code unmapping it or modifying the mappings. The same
argument made by John Hubbard applies. If applications mess with
existing memory mappings, they are broken anyway. Why do our mappings
need special protections, but a mapping of e.g. libc doesn't?

In our case, we don't have HMM (yet), so in most cases changing the
memory mapping on the CPU side won't affect the GPU mappings. The
exception to that would be userptr mappings where a rogue unmap would
trigger an MMU notifier and result in updating the GPU mapping, which
could lead to a GPU VM fault later on.

Regards,
  Felix

>
> Cheers,
> Jérôme

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

Re: [PATCH v3 00/10] splash screen on the stm32f769 disco board

[Daniel Vetter]

On Tue, Mar 13, 2018 at 02:49:59PM +0100, yannick fertre wrote:
> Version 3:
> - Replace some pr_error, pr_warn or pr_info by dev_error, dev_warn & dev_info.
> - Refresh stm32f769-disco_defconfig with last modification done on 
> v2018.3-rc4.
> - rework include files ordering.
> 
> Version 2:
> - Replace debug log by pr_error, pr_warn or pr_info.
> - Rework bridge between ltdc & dsi panel
> - Rework backligh management (with or witout gpio)
> - Rework panel otm8009a
> - Add new panel raydium rm68200
> 
> Version 1:
> - Initial commit
> 
> This serie contains all patchsets needed for displaying a splash screen 
> on the stm32f769 disco board.
> A new config has been created configs/stm32f769-disco_defconfig.
> This is necessary due to the difference of panels between stm32f769-disco &
> stm32f746-disco boards.

Shouldn't we patch the drivers/gpu/drm/stm driver instead of the
drivers/video one? fbdev is kinda a dead end and not for adding new hw
support ...
-Daniel

> This serie depends on:
>   http://patchwork.ozlabs.org/patch/870938/
>   http://patchwork.ozlabs.org/cover/880576/
> yannick fertre (10):
>   video: stm32: stm32_ltdc: add bridge to display controller
>   video: stm32: stm32_ltdc: update debug log
>   video: add support of MIPI DSI interface
>   video: add support of panel OTM8009A
>   video: add MIPI DSI host controller bridge
>   video: add support of STM32 MIPI DSI controller driver
>   video: add support of panel rm68200
>   arm: dts: stm32: add dsi for STM32F746
>   arm: dts: stm32: add display for STM32F769 disco board
>   board: Add STM32F769 SoC, discovery board support
> 
>  arch/arm/dts/stm32f746.dtsi|  12 +
>  arch/arm/dts/stm32f769-disco.dts   |  71 
>  configs/stm32f769-disco_defconfig  |  65 +++
>  drivers/video/Kconfig  |  32 ++
>  drivers/video/Makefile |   4 +
>  drivers/video/dw_mipi_dsi.c| 822 
> +
>  drivers/video/mipi_display.c   | 807 
>  drivers/video/orisetech_otm8009a.c | 327 +++
>  drivers/video/raydium-rm68200.c| 326 +++
>  drivers/video/stm32/Kconfig|  10 +
>  drivers/video/stm32/Makefile   |   1 +
>  drivers/video/stm32/stm32_dsi.c| 426 +++
>  drivers/video/stm32/stm32_ltdc.c   | 144 ---
>  include/dw_mipi_dsi.h  |  34 ++
>  include/mipi_display.h | 257 +++-
>  15 files changed, 3279 insertions(+), 59 deletions(-)
>  create mode 100644 configs/stm32f769-disco_defconfig
>  create mode 100644 drivers/video/dw_mipi_dsi.c
>  create mode 100644 drivers/video/mipi_display.c
>  create mode 100644 drivers/video/orisetech_otm8009a.c
>  create mode 100644 drivers/video/raydium-rm68200.c
>  create mode 100644 drivers/video/stm32/stm32_dsi.c
>  create mode 100644 include/dw_mipi_dsi.h
> 
> -- 
> 1.9.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [PATCH v2 1/3] drm: Add the optional .fb_modifier() hook

[Daniel Vetter]

On Tue, Mar 13, 2018 at 03:38:38PM +0100, Michel Dänzer wrote:
> On 2018-03-13 03:28 PM, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> > 
> > To make it possible for the core to check the fb pixel format and
> > modifier, we need to first ask the driver to deduce the modifier
> > when the request does not explicitly specify one.
> > 
> > Add a new .fb_modifier() hook for that purpose and convert i915
> > and vc4 to make use if it. All other drivers seem to currently
> > assume linear when the request does not specify anything else,
> > [...]
> 
> That's not true at least for the amdgpu and radeon drivers. The tiling
> mode is communicated via BO metadata.

But atm amdgpu and radeon also don't support explicit modifiers in the
kernel driver, so it again all checks out. Or should at least.

Once you add modifier support, you need to wire up all the bits and the
rigth default selection, and it should again pan out.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105449] dual radeon xserver crash on startup: destination is framebuffer incomplete: incomplete/missing attachment [8cd7]

[bugzilla-daemon]

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

--- Comment #3 from SMF  ---
Removed old glamor components and rebuilt xserver:

[   517.455] (II) Loading /usr/lib/X11/modules/libglamoregl.so
[   517.474] (II) Module glamoregl: vendor="X.Org Foundation"
[   517.474]compiled for 1.19.6, module version = 1.0.0

problem solved 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 1/3] drm: Add the optional .fb_modifier() hook

[Michel Dänzer]

On 2018-03-13 04:12 PM, Ville Syrjälä wrote:
> On Tue, Mar 13, 2018 at 03:38:38PM +0100, Michel Dänzer wrote:
>> On 2018-03-13 03:28 PM, Ville Syrjala wrote:
>>> From: Ville Syrjälä 
>>>
>>> To make it possible for the core to check the fb pixel format and
>>> modifier, we need to first ask the driver to deduce the modifier
>>> when the request does not explicitly specify one.
>>>
>>> Add a new .fb_modifier() hook for that purpose and convert i915
>>> and vc4 to make use if it. All other drivers seem to currently
>>> assume linear when the request does not specify anything else,
>>> [...]
>>
>> That's not true at least for the amdgpu and radeon drivers. The tiling
>> mode is communicated via BO metadata.
> 
> Well, at least those driver don't do any bo tiling->modifier conversion.
> Radeon doesn't do modifiers I suppose, so that part is probably OK.
> amggpu might just be broken, not sure.

amdgpu certainly wasn't broken before modifiers came along. If something
broke with those, I'd say it's more accurate to say that's broken and
needs to be fixed, rather than adding more incorrect assumptions based
on it.


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

Re: [PATCH 1/4] dma-buf: add optional invalidate_mappings callback

[Daniel Vetter]

On Mon, Mar 12, 2018 at 08:13:15PM +0100, Christian K??nig wrote:
> Am 12.03.2018 um 18:07 schrieb Daniel Vetter:
> > On Fri, Mar 09, 2018 at 08:11:41PM +0100, Christian K??nig wrote:
> > > [SNIP]
> > > +/**
> > > + * dma_buf_invalidate_mappings - invalidate all mappings of this dma_buf
> > > + *
> > > + * @dmabuf:  [in]buffer which mappings should be invalidated
> > > + *
> > > + * Informs all attachmenst that they need to destroy and recreated all 
> > > their
> > > + * mappings.
> > > + */
> > > +void dma_buf_invalidate_mappings(struct dma_buf *dmabuf)
> > > +{
> > > + struct dma_buf_attachment *attach;
> > > +
> > > + reservation_object_assert_held(dmabuf->resv);
> > > +
> > > + list_for_each_entry(attach, >attachments, node)
> > > + attach->invalidate_mappings(attach);
> > To make the locking work I think we also need to require importers to hold
> > the reservation object while attaching/detaching. Otherwise the list walk
> > above could go boom.
> 
> Oh, good point. Going, to fix this.
> 
> > [SNIP]
> > > + /**
> > > +  * @supports_mapping_invalidation:
> > > +  *
> > > +  * True for exporters which supports unpinned DMA-buf operation using
> > > +  * the reservation lock.
> > > +  *
> > > +  * When attachment->invalidate_mappings is set the @map_dma_buf and
> > > +  * @unmap_dma_buf callbacks can be called with the reservation lock
> > > +  * held.
> > > +  */
> > > + bool supports_mapping_invalidation;
> > Why do we need this? Importer could simply always register with the
> > invalidate_mapping hook registered, and exporters could use it when they
> > see fit. That gives us more lockdep coverage to make sure importers use
> > their attachment callbacks correctly (aka they hold the reservation
> > object).
> 
> One sole reason: Backward compability.
> 
> I didn't wanted to audit all those different drivers if they can handle
> being called with the reservation lock held.
> 
> > 
> > > +
> > >   /**
> > >* @map_dma_buf:
> > >*
> > > @@ -326,6 +338,29 @@ struct dma_buf_attachment {
> > >   struct device *dev;
> > >   struct list_head node;
> > >   void *priv;
> > > +
> > > + /**
> > > +  * @invalidate_mappings:
> > > +  *
> > > +  * Optional callback provided by the importer of the attachment which
> > > +  * must be set before mappings are created.
> > This doesn't work, it must be set before the attachment is created,
> > otherwise you race with your invalidate callback.
> 
> Another good point.
> 
> > 
> > I think the simplest option would be to add a new dma_buf_attach_dynamic
> > (well except a less crappy name).
> 
> Well how about adding an optional invalidate_mappings parameter to the
> existing dma_buf_attach?

Not sure that's best, it might confuse dumb importers and you need to
change all the callers. But up to you.

> > > +  *
> > > +  * If provided the exporter can avoid pinning the backing store while
> > > +  * mappings exists.
> > > +  *
> > > +  * The function is called with the lock of the reservation object
> > > +  * associated with the dma_buf held and the mapping function must be
> > > +  * called with this lock held as well. This makes sure that no mapping
> > > +  * is created concurrently with an ongoing invalidation.
> > > +  *
> > > +  * After the callback all existing mappings are still valid until all
> > > +  * fences in the dma_bufs reservation object are signaled, but should be
> > > +  * destroyed by the importer as soon as possible.
> > Do we guarantee that the importer will attach a fence, after which the
> > mapping will be gone? What about re-trying? Or just best effort (i.e. only
> > useful for evicting to try to make room).
> 
> The importer should attach fences for all it's operations with the DMA-buf.
> 
> > I think a helper which both unmaps _and_ waits for all the fences to clear
> > would be best, with some guarantees that it'll either fail or all the
> > mappings _will_ be gone. The locking for that one will be hilarious, since
> > we need to figure out dmabuf->lock vs. the reservation. I kinda prefer we
> > throw away the dmabuf->lock and superseed it entirely by the reservation
> > lock.
> 
> Big NAK on that. The whole API is asynchronously, e.g. we never block for
> any operation to finish.
> 
> Otherwise you run into big trouble with cross device GPU resets and stuff
> like that.

But how will the unmapping work then? You can't throw the sg list away
before the dma stopped. The dma only stops once the fence is signalled.
The importer can't call dma_buf_detach because the reservation lock is
hogged already by the exporter trying to unmap everything.

How is this supposed to work?

Re GPU might cause a deadlock: Isn't that already a problem if you hold
reservations of buffers used on other gpus, which want those reservations
to complete the gpu reset, but that gpu reset blocks some fence that the
reservation holder is waiting for?

We have tons of fun with deadlocks against GPU 

Re: [PATCH v2 1/3] drm: Add the optional .fb_modifier() hook

[Ville Syrjälä]

On Tue, Mar 13, 2018 at 03:38:38PM +0100, Michel Dänzer wrote:
> On 2018-03-13 03:28 PM, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> > 
> > To make it possible for the core to check the fb pixel format and
> > modifier, we need to first ask the driver to deduce the modifier
> > when the request does not explicitly specify one.
> > 
> > Add a new .fb_modifier() hook for that purpose and convert i915
> > and vc4 to make use if it. All other drivers seem to currently
> > assume linear when the request does not specify anything else,
> > [...]
> 
> That's not true at least for the amdgpu and radeon drivers. The tiling
> mode is communicated via BO metadata.

Well, at least those driver don't do any bo tiling->modifier conversion.
Radeon doesn't do modifiers I suppose, so that part is probably OK.
amggpu might just be broken, not sure.

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

Re: [RFC v3 09/12] drm: Add API for in-kernel clients

[Daniel Vetter]

On Mon, Mar 12, 2018 at 09:21:40PM +0100, Noralf Tr??nnes wrote:
> 
> Den 12.03.2018 17.51, skrev Daniel Vetter:
> > On Thu, Mar 08, 2018 at 06:12:11PM +0100, Noralf Tr??nnes wrote:
> > > Den 06.03.2018 09.56, skrev Daniel Vetter:
> > > > On Thu, Feb 22, 2018 at 09:06:50PM +0100, Noralf Tr??nnes wrote:
> > > > > This adds an API for writing in-kernel clients.
> > > > > 
> > > > > TODO:
> > > > > - Flesh out and complete documentation.
> > > > > - Cloned displays is not tested.
> > > > > - Complete tiled display support and test it.
> > > > > - Test plug/unplug different monitors.
> > > > > - A runtime knob to prevent clients from attaching for debugging 
> > > > > purposes.
> > > > > - Maybe a way to unbind individual client instances.
> > > > > - Maybe take the sysrq support in drm_fb_helper and move it here 
> > > > > somehow.
> > > > > - Add suspend/resume callbacks.
> > > > > Does anyone know why fbdev requires suspend/resume?
> > > > > 
> > > > > Signed-off-by: Noralf Tr??nnes 
> > > > The core client api I like. Some of the opens I'm seeing:
> > > > 
> > > > - If we go with using the internal kms api directly instead of IOCTL
> > > > wrappers then a huge pile of the functions you have here aren't 
> > > > needed
> > > > (e.g. all the event stuff we can just directly use vblank events 
> > > > instead
> > > > of all the wrapping). I'm leaning ever more into that direction, 
> > > > since
> > > > much less code to add.
> > > Looking at drm_fb_helper once again I now see an opportunity to simplify
> > > the modesetting code by nuking drm_fb_helper_connector and stop
> > > maintaining an array of connectors. It looks to be possible to just
> > > create an array temporarily in drm_setup_crtcs() for the duration of the
> > > function. The connectors we care about are ref counted and attached to
> > > modesets. This would remove the need for 
> > > drm_fb_helper_add_one_connector().
> > > 
> > > So I might be able to do struct drm_fb_helper_crtc -> drm_client_crtc
> > > and let the client API take over drm_setup_crtcs(). I'll give it a try.
> > I'm more wondering why we need drm_client_crtc at all, why is drm_crtc not
> > good enough. Or maybe I'm missing something. Imo ioctl wrappers should be
> > the exception where we really, really need them (because the backend of
> > the ioctl isn't implemented in a generic way, e.g. dumb buffers), not for
> > stuff where we already have a perfectly useable in-kernel abi (anything
> > related to modesetting).
> 
> I was talking about moving the modesetting code from drm_fb_helper.c
> to drm_client.c, which meant moving 'struct drm_fb_helper_crtc' as well.
> 
> struct drm_fb_helper_crtc {
>     struct drm_mode_set mode_set;
>     struct drm_display_mode *desired_mode;
>     int x, y;
> };
> 
> But maybe we can get rid of that struct as well.
> The info it contains is also available in drm_mode_set:

drm_mode_set is the uapi struct for the legacy ioctl, but yeah I guess we
can recycle that. And I didn't understand what you wanted to do,
extracting the fbdev helper might make sense. But most of the code seems
fbdev specific, so not sure how much use that would be in other clients.

There's also a bit the problem that it's crufty (it started out as
something that was fully integrated into drivers and digging around in
driver internals directly, hence also the convoluted allocation logic).
-Daniel

> 
> static void drm_setup_crtcs(struct drm_fb_helper *fb_helper,
>                 u32 width, u32 height)
> {
> ...
>     drm_fb_helper_for_each_connector(fb_helper, i) {
>         struct drm_display_mode *mode = modes[i];
>         struct drm_fb_helper_crtc *fb_crtc = crtcs[i];
>         struct drm_fb_offset *offset = [i];
> 
>         if (mode && fb_crtc) {
>             struct drm_mode_set *modeset = _crtc->mode_set;
> 
>             fb_crtc->desired_mode = mode;
>             fb_crtc->x = offset->x;
>             fb_crtc->y = offset->y;
>             modeset->mode = drm_mode_duplicate(dev,
>                                fb_crtc->desired_mode);
>             modeset->x = offset->x;
>             modeset->y = offset->y;
>         }
>     }
> 
> I took the hint about my ioctl wrappers :-)
> 
> Noralf.
> 
> > 
> > And in a way the ioctl wrappers wouldn't really be ioctl wrappers
> > conceptually, but simple share some of the same code with the ioctl call
> > chain. The idea is to provide some minimal wrappar around the ->dumb*
> > callbacks.
> > 
> > Anything else is not needed, I think.
> > 
> > > There is one challenge I see upfront and that's the i915 fb_helper
> > > callback in drm_setup_crtcs().
> > > 
> > > > - The register/unregister model needs more thought. Allowing both 
> > > > clients
> > > > to register whenever they want to, and drm_device instances to come 
> > > > and
> > > > go is what fbcon has done, and the resulting locking is a horror 
> > > > show.
> > > > 
> > > > I think if we require that all 

[PATCH 3/3] drm: Store the calculated vrefresh in the user mode

[Ville Syrjala]

From: Ville Syrjälä 

Ignore the vrefresh in the mode the user passed in and instead
calculate the value based on the actual timings. This way we can
actually trust mode->vrefresh to some degree.

Or should we compare the user's idea of vrefresh with the one
we get from the timings and return an error if they differ? We
can't really be sure what the user is asking in that case.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_modes.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index f6b7c0e36a1a..021526ec6fa0 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1609,7 +1609,11 @@ int drm_mode_convert_umode(struct drm_device *dev,
out->vsync_end = in->vsync_end;
out->vtotal = in->vtotal;
out->vscan = in->vscan;
-   out->vrefresh = in->vrefresh;
+/*
+ * Ignore what the user is saying here and instead
+ * calculate vrefresh based on the actual timings.
+ */
+   out->vrefresh = 0;
out->flags = in->flags;
out->type = in->type;
strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
@@ -1619,6 +1623,8 @@ int drm_mode_convert_umode(struct drm_device *dev,
if (out->status != MODE_OK)
return -EINVAL;
 
+   out->vrefresh = drm_mode_vrefresh(out);
+
drm_mode_set_crtcinfo(out, CRTC_INTERLACE_HALVE_V);
 
return 0;
-- 
2.16.1

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

[PATCH 1/3] drm: Nuke the useless 'ret' variable from drm_mode_convert_umode()

[Ville Syrjala]

From: Ville Syrjälä 

No need to store the return value in a variable since we don't have to
do any unwinding.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_modes.c | 15 ---
 1 file changed, 4 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 5a8033fda4e3..4157250140b0 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1596,12 +1596,8 @@ int drm_mode_convert_umode(struct drm_device *dev,
   struct drm_display_mode *out,
   const struct drm_mode_modeinfo *in)
 {
-   int ret = -EINVAL;
-
-   if (in->clock > INT_MAX || in->vrefresh > INT_MAX) {
-   ret = -ERANGE;
-   goto out;
-   }
+   if (in->clock > INT_MAX || in->vrefresh > INT_MAX)
+   return -ERANGE;
 
out->clock = in->clock;
out->hdisplay = in->hdisplay;
@@ -1622,14 +1618,11 @@ int drm_mode_convert_umode(struct drm_device *dev,
 
out->status = drm_mode_validate_driver(dev, out);
if (out->status != MODE_OK)
-   goto out;
+   return -EINVAL;
 
drm_mode_set_crtcinfo(out, CRTC_INTERLACE_HALVE_V);
 
-   ret = 0;
-
-out:
-   return ret;
+   return 0;
 }
 
 /**
-- 
2.16.1

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

[PATCH 2/3] drm: Make drm_mode_vrefresh() a bit more accurate

[Ville Syrjala]

From: Ville Syrjälä 

Do the refresh rate calculation with a single division. This gives
us slightly more accurate results, especially for interlaced since
we don't just double the final truncated result.

We do lose one bit compared to the old way, so with an interlaced
mode the new code can only handle ~2GHz instead of the ~4GHz the
old code handeled.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_modes.c | 19 +--
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 4157250140b0..f6b7c0e36a1a 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -773,24 +773,23 @@ EXPORT_SYMBOL(drm_mode_hsync);
 int drm_mode_vrefresh(const struct drm_display_mode *mode)
 {
int refresh = 0;
-   unsigned int calc_val;
 
if (mode->vrefresh > 0)
refresh = mode->vrefresh;
else if (mode->htotal > 0 && mode->vtotal > 0) {
-   int vtotal;
-   vtotal = mode->vtotal;
-   /* work out vrefresh the value will be x1000 */
-   calc_val = (mode->clock * 1000);
-   calc_val /= mode->htotal;
-   refresh = (calc_val + vtotal / 2) / vtotal;
+   unsigned int num, den;
+
+   num = mode->clock * 1000;
+   den = mode->htotal * mode->vtotal;
 
if (mode->flags & DRM_MODE_FLAG_INTERLACE)
-   refresh *= 2;
+   num *= 2;
if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
-   refresh /= 2;
+   den *= 2;
if (mode->vscan > 1)
-   refresh /= mode->vscan;
+   den *= mode->vscan;
+
+   refresh = DIV_ROUND_CLOSEST(num, den);
}
return refresh;
 }
-- 
2.16.1

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

Re: [PATCH v2 0/7] Modernize vga_switcheroo by using device link for HDA

[Daniel Vetter]

On Mon, Mar 12, 2018 at 09:55:50PM +0100, Lukas Wunner wrote:
> On Mon, Mar 12, 2018 at 05:54:47PM +0100, Daniel Vetter wrote:
> > On Sun, Mar 11, 2018 at 04:55:49PM +0100, Lukas Wunner wrote:
> > > > On Sat, Mar 03, 2018 at 10:53:24AM +0100, Lukas Wunner wrote:
> > > > > Modernize vga_switcheroo by using a device link to enforce a runtime 
> > > > > PM
> > > > > dependency from an HDA controller to the GPU it's integrated into, v2.
> > > > > 
> > > > > https://github.com/l1k/linux/commits/switcheroo_devlink_v2
> > >
> > > Patches [3/7] to [7/7] were reviewed by Peter Wu, the HDA bits in
> > > patch [5/7] additionally by Takashi.
> > > 
> > > Patch [2/7] was acked by Bjorn.  There was no ack for patch [1/7]
> > > (authored by Rafael), but it adressed the objection Bjorn raised
> > > against my original patch, so I'm assuming Bjorn is okay with it.
> > > (Bjorn, please let me know if that isn't the case.)
> > > 
> > > If there are no objections, I plan to push the series to
> > > drm-misc-next by the middle of the coming week so that it
> > > would still catch the last train to 4.17.
> > 
> > Please make sure all maintainers of other bits are ok with that and have
> > given their formal ack for merging through drm-misc.
> 
> Oh, I had thought Bjorn's acks for patches [2/7] and [5/7] and
> Takashi's reviewed-by for the HDA-related patches were sufficient.

There's a huge confusion around acked-by "I think this looks reasonable",
acked-by "this is reviewed but I don't feel like a full review tag" and
acked-by "for merging through some other tree" and a few other meanings.
Always good to double-check :-)
-Daniel

> 
> Bjorn, Takashi, any objections against merging this through drm-misc?
> 
> Thanks,
> 
> Lukas

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

[PATCH libdrm 2/2] meson: detect alloca.h

[Eric Engestrom]

amdgpu makes use of it

Signed-off-by: Eric Engestrom 
---
 meson.build | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meson.build b/meson.build
index 3a33928d02a6dce5f075..f7986af9bb5259be5da5 100644
--- a/meson.build
+++ b/meson.build
@@ -186,7 +186,7 @@ else
   dep_rt = []
 endif
 dep_m = cc.find_library('m', required : false)
-foreach header : ['sys/sysctl.h', 'sys/select.h']
+foreach header : ['sys/sysctl.h', 'sys/select.h', 'alloca.h']
   if cc.compiles('#include <@0@>'.format(header), name : '@0@ 
works'.format(header))
 config.set10('HAVE_' + header.underscorify().to_upper(), true)
   endif
-- 
Cheers,
  Eric

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

[PATCH libdrm 1/2] meson: make it easy to add headers to check

[Eric Engestrom]

Signed-off-by: Eric Engestrom 
---
 meson.build | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/meson.build b/meson.build
index f4c95394c52e65672f24..3a33928d02a6dce5f075 100644
--- a/meson.build
+++ b/meson.build
@@ -186,12 +186,11 @@ else
   dep_rt = []
 endif
 dep_m = cc.find_library('m', required : false)
-if cc.compiles('#include ', name : 'sys/sysctl.h works')
-  config.set10('HAVE_SYS_SYSCTL_H', true)
-endif
-if cc.compiles('#include ', name : 'sys/select.h works')
-  config.set10('HAVE_SYS_SELECT_H', true)
-endif
+foreach header : ['sys/sysctl.h', 'sys/select.h']
+  if cc.compiles('#include <@0@>'.format(header), name : '@0@ 
works'.format(header))
+config.set10('HAVE_' + header.underscorify().to_upper(), true)
+  endif
+endforeach
 if cc.has_header_symbol('sys/sysmacros.h', 'major')
   config.set10('MAJOR_IN_SYSMACROS', true)
 elif cc.has_header_symbol('sys/mkdev.h', 'major')
-- 
Cheers,
  Eric

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

Re: [PATCH libdrm] meson: don't use compiler.has_header

[Eric Engestrom]

On Monday, 2018-03-12 11:18:27 -0700, Dylan Baker wrote:
> Meson's compiler.has_header is completely useless, it only checks that a
> header exists, not whether it's usable. This creates problems if a
> header contains a conditional #error declaration, like so:
> 
> > #if __x86_64__
> > # error "Doesn't work with x86_64!"
> > #endif
> 
> Compiler.has_header will return true in this case, even when compiling
> for x86_64. This is useless.
> 
> Instead, we'll do a compile check so that any #error declarations will
> be treated as errors, and compilation will work.
> 
> Fixes compilation on x32 architecture.
> 
> Gentoo Bugzilla: https://bugs.gentoo.org/show_bug.cgi?id=649746
> meson bug: https://github.com/mesonbuild/meson/issues/2246
> CC: Matt Turner 
> Signed-off-by: Dylan Baker 

Nvm my comment on your mesa patch, you've done this already :)

Reviewed-by: Eric Engestrom 

Sending a couple patches on this bit of the code, they'll be based on
top of this patch.

> ---
>  meson.build | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/meson.build b/meson.build
> index df6f2bd2..a0c79e30 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -186,10 +186,10 @@ else
>dep_rt = []
>  endif
>  dep_m = cc.find_library('m', required : false)
> -if cc.has_header('sys/sysctl.h')
> +if cc.compiles('#include ', name : 'sys/sysctl.h works')
>config.set10('HAVE_SYS_SYSCTL_H', true)
>  endif
> -if cc.has_header('sys/select.h')
> +if cc.compiles('#include ', name : 'sys/select.h works')
>config.set10('HAVE_SYS_SELECT_H', true)
>  endif
>  if cc.has_header_symbol('sys/sysmacros.h', 'major')
> -- 
> 2.16.2
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

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

--- Comment #185 from Sandeep  ---
I have that display/corruption issue too, on the XFX R9 390.

Usually happens after suspend/resume. Will test if it gets fixed with above
steps.

-- 
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 1/3] drm: Add the optional .fb_modifier() hook

[Michel Dänzer]

On 2018-03-13 03:28 PM, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> To make it possible for the core to check the fb pixel format and
> modifier, we need to first ask the driver to deduce the modifier
> when the request does not explicitly specify one.
> 
> Add a new .fb_modifier() hook for that purpose and convert i915
> and vc4 to make use if it. All other drivers seem to currently
> assume linear when the request does not specify anything else,
> [...]

That's not true at least for the amdgpu and radeon drivers. The tiling
mode is communicated via BO metadata.


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

Re: [PATCH v3 04/10] otm

[Yannick FERTRE]

Hi,

Sorry, I send more than 10 patches.

I will remove this dummy patches tomorrow with next version.



On 03/13/2018 03:12 PM, Patrice CHOTARD wrote:
> Hi Yannick
>
> There is a problem with patch 4. I received two patches 04/10, this one
> and [PATCH v3 04/10] video: add support of panel OTM8009A.
>
> Patrice
>
> On 03/13/2018 02:50 PM, yannick fertre wrote:
>> ---
>>drivers/video/orisetech_otm8009a.c | 4 +++-
>>1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/video/orisetech_otm8009a.c 
>> b/drivers/video/orisetech_otm8009a.c
>> index 81b11d7..aa8139a 100644
>> --- a/drivers/video/orisetech_otm8009a.c
>> +++ b/drivers/video/orisetech_otm8009a.c
>> @@ -289,9 +289,11 @@ static int otm8009a_panel_probe(struct udevice *dev)
>>  struct otm8009a_panel_priv *priv = dev_get_priv(dev);
>>  int ret;
>>
>> -/* reset panel must be done before probe */
>> +/* reset panel */
>>  dm_gpio_set_value(>reset, true);
>>
>> +mdelay(1);
>> +
>>  if (IS_ENABLED(CONFIG_DM_REGULATOR) && priv->reg) {
>>  dev_err(dev, "enable regulator '%s'\n", priv->reg->name);
>>  ret = regulator_set_enable(priv->reg, true);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH 00/13] SVM (share virtual memory) with HMM in nouveau

[Jerome Glisse]

On Tue, Mar 13, 2018 at 06:29:40AM -0700, Matthew Wilcox wrote:
> On Mon, Mar 12, 2018 at 11:14:47PM -0700, John Hubbard wrote:
> > Yes, on NVIDIA GPUs, the Host/FIFO unit is limited to 40-bit addresses, so
> > things such as the following need to be below (1 << 40), and also 
> > accessible 
> > to both CPU (user space) and GPU hardware. 
> > -- command buffers (CPU user space driver fills them, GPU consumes 
> > them), 
> > -- semaphores (here, a GPU-centric term, rather than OS-type: these are
> >memory locations that, for example, the GPU hardware might write to, 
> > in
> >order to indicate work completion; there are other uses as well), 
> > -- a few other things most likely (this is not a complete list).
> 
> Is that a 40-bit virtual address limit or physical address limit?  I'm
> no longer sure who is addressing what memory through what mechanism ;-)
> 

Virtual address limit, those object get mapped into GPU page table but
the register/structure fields where you program those object's address
only are 32bits (the virtual address is shifted by 8bits for alignment).

Cheers,
Jérôme
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 1/3] drm: Add the optional .fb_modifier() hook

[Ville Syrjala]

From: Ville Syrjälä 

To make it possible for the core to check the fb pixel format and
modifier, we need to first ask the driver to deduce the modifier
when the request does not explicitly specify one.

Add a new .fb_modifier() hook for that purpose and convert i915
and vc4 to make use if it. All other drivers seem to currently
assume linear when the request does not specify anything else,
hence we make the core use that as the fallback strategy when
the hook is not provided.

Since the two hooks are now separate it is of course possible
to race set_tiling against addfb. But since that's just userspace
intentially shooting itself in the foot I don't think we should
hve to worry about it. The addfb will simply fail in the
.fb_create() hook if the tiling has changed since
.fb_mofifier() was called. Well, that's the case for i915.
vc4 never did any cross checks between the tiling and modifier.

framebuffer_check() now checks the request against the deduced
modifier, and since we now know the final modifier we can
convert the request to one with modifiers. This means that a
driver will never even have to look at a request without
modifiers outside of the .fb_modifuer() hook, should it need
to provide one.

v2: return -EINVAL for handles[0]==0 from i915/vc4 .fb_modifier() hook
to keep igt/kms_addfb_basic/no-handle happy

Cc: Eric Anholt 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_framebuffer.c| 61 
 drivers/gpu/drm/i915/intel_display.c | 79 +---
 drivers/gpu/drm/i915/intel_drv.h |  2 +-
 drivers/gpu/drm/i915/intel_fbdev.c   |  2 +
 drivers/gpu/drm/vc4/vc4_kms.c| 58 --
 include/drm/drm_mode_config.h| 29 +
 6 files changed, 158 insertions(+), 73 deletions(-)

diff --git a/drivers/gpu/drm/drm_framebuffer.c 
b/drivers/gpu/drm/drm_framebuffer.c
index 7df025669067..21d3d51eb261 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -153,7 +153,8 @@ static int fb_plane_height(int height,
 }
 
 static int framebuffer_check(struct drm_device *dev,
-const struct drm_mode_fb_cmd2 *r)
+struct drm_mode_fb_cmd2 *r,
+u64 modifier)
 {
const struct drm_format_info *info;
int i;
@@ -210,14 +211,14 @@ static int framebuffer_check(struct drm_device *dev,
}
 
if (r->flags & DRM_MODE_FB_MODIFIERS &&
-   r->modifier[i] != r->modifier[0]) {
+   r->modifier[i] != modifier) {
DRM_DEBUG_KMS("bad fb modifier %llu for plane %d\n",
  r->modifier[i], i);
return -EINVAL;
}
 
/* modifier specific checks: */
-   switch (r->modifier[i]) {
+   switch (modifier) {
case DRM_FORMAT_MOD_SAMSUNG_64_32_TILE:
/* NOTE: the pitch restriction may be lifted later if 
it turns
 * out that no hw has this restriction:
@@ -261,45 +262,73 @@ static int framebuffer_check(struct drm_device *dev,
}
}
 
+   /*
+* Finally convert the request into one with
+* modifiers to make life easier for drivers.
+*/
+   if (dev->mode_config.allow_fb_modifiers) {
+   r->flags |= DRM_MODE_FB_MODIFIERS;
+
+   for (i = 0; i < info->num_planes; i++)
+   r->modifier[i] = modifier;
+   }
+
return 0;
 }
 
 struct drm_framebuffer *
 drm_internal_framebuffer_create(struct drm_device *dev,
-   const struct drm_mode_fb_cmd2 *r,
+   const struct drm_mode_fb_cmd2 *user_r,
struct drm_file *file_priv)
 {
struct drm_mode_config *config = >mode_config;
+   struct drm_mode_fb_cmd2 r = *user_r;
struct drm_framebuffer *fb;
+   u64 modifier = 0;
int ret;
 
-   if (r->flags & ~(DRM_MODE_FB_INTERLACED | DRM_MODE_FB_MODIFIERS)) {
-   DRM_DEBUG_KMS("bad framebuffer flags 0x%08x\n", r->flags);
+   if (r.flags & ~(DRM_MODE_FB_INTERLACED | DRM_MODE_FB_MODIFIERS)) {
+   DRM_DEBUG_KMS("bad framebuffer flags 0x%08x\n", r.flags);
return ERR_PTR(-EINVAL);
}
 
-   if ((config->min_width > r->width) || (r->width > config->max_width)) {
+   if (config->min_width > r.width || r.width > config->max_width) {
DRM_DEBUG_KMS("bad framebuffer width %d, should be >= %d && <= 
%d\n",
- r->width, config->min_width, config->max_width);
+ r.width, config->min_width, config->max_width);
return ERR_PTR(-EINVAL);
}
-   if