[RFC] dma-buf: Import/export the implicit fences on the dma-buf

2016-07-11 Thread Chris Wilson
When dealing with user interfaces that utilize explicit fences, it is
convenient to sometimes create those fences after the fact, i.e. to
query the dma-buf for the current set of implicit fences, encapsulate
those into a sync_file and hand that fd back to userspace.
Correspondingly, being able to add an explicit fence back into the mix
of fences being tracked by the dma-buf allows that userspace fence to be
included in any implicit tracking.

Signed-off-by: Chris Wilson 
Cc: Gustavo Padovan 
Cc: Rob Clark 
Cc: Sumit Semwal 
Cc: Daniel Vetter 
Cc: dri-devel at lists.freedesktop.org
---

Gustavo, could you look at the sync-file/fence-array handling? There's
definitely room for a cleaner sync_file_create() API.

I was thinking about this for the "why not sync-file" question Gustavo
posed for the vgem_fences. I wanted to add an ioctl to the vgem to allow
exporting and creating fences from sync-file for testing passing 
explicit userspaces around between drivers, and realised that I was just
writing a generic mechanism that only required dma-buf.

Whilst this interface could be used for lazily creating explicit fences,
drivers will also likely want to support specific ioctl to skip the
dmabuf creation, I think this interfaces will be useful with the vgem
fences for testing sync_file handling in drivers (on i915 at the moment,
my tests for sync_file involve sleeping and a few white lies). So
fulfilling a similar role in driver testing to debugfs/sw_sync?
(sw_sync is still more apt for testing timelines etc, vgem feels more
apt for ease of testing rendering.)
-Chris

---
 drivers/dma-buf/dma-buf.c| 100 +++
 include/uapi/linux/dma-buf.h |   9 
 2 files changed, 109 insertions(+)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 41fbce0c273a..6f066a8affd7 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -26,11 +26,13 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -254,6 +256,97 @@ out:
return events;
 }

+static long dma_buf_import_fence_ioctl(struct dma_buf *dmabuf,
+  struct dma_buf_fence  __user *arg)
+{
+   struct reservation_object *resv = dmabuf->resv;
+   struct dma_buf_fence cmd;
+   struct fence *fence;
+   int ret;
+
+   if (copy_from_user(, arg, sizeof(cmd)))
+   return -EFAULT;
+
+   fence = NULL;
+   //fence = sync_file_get_fence(cmd.fd);
+   if (!fence)
+   return -EINVAL;
+
+   mutex_lock(>lock.base);
+   if (cmd.flags & DMA_BUF_FENCE_WRITE)
+   reservation_object_add_excl_fence(resv, fence);
+   else if ((ret = reservation_object_reserve_shared(resv)) == 0)
+   reservation_object_add_shared_fence(resv, fence);
+   mutex_unlock(>lock.base);
+
+   fence_put(fence);
+   return ret;
+}
+
+static long dma_buf_export_fence_ioctl(struct dma_buf *dmabuf,
+  struct dma_buf_fence  __user *arg)
+{
+   struct reservation_object *resv = dmabuf->resv;
+   struct dma_buf_fence cmd;
+   struct fence *excl, **shared;
+   struct sync_file *sync = NULL;
+   unsigned int count, n;
+   int ret;
+
+   if (get_user(cmd.flags, >flags))
+   return -EFAULT;
+
+   ret = reservation_object_get_fences_rcu(resv, , , );
+   if (ret)
+   return ret;
+
+   if (cmd.flags & DMA_BUF_FENCE_WRITE) {
+   if (excl) {
+   sync = sync_file_create(excl);
+   if (!sync) {
+   ret = -ENOMEM;
+   fence_put(excl);
+   }
+   }
+   for (n = 0; n < count; n++)
+   fence_put(shared[n]);
+   kfree(shared);
+   } else {
+   if (count) {
+   struct fence_array *array;
+
+   array = fence_array_create(count, shared, 0, 0, false);
+   if (!array) {
+   for (n = 0; n < count; n++)
+   fence_put(shared[n]);
+   kfree(shared);
+   } else
+   sync = sync_file_create(>base);
+   if (!sync) {
+   ret = -ENOMEM;
+   fence_put(>base);
+   }
+   }
+   fence_put(excl);
+   }
+   if (ret)
+   return ret;
+
+   cmd.fd = get_unused_fd_flags(O_CLOEXEC);
+   if (cmd.fd < 0) {
+   fput(sync->file);
+   return cmd.fd;
+   }
+
+   if (put_user(cmd.fd, >fd)) {
+   fput(sync->file);
+   return -EFAULT;
+   }
+
+   fd_install(cmd.fd, 

[added to the 4.1 stable tree] drm: Fix for DP CTS test 4.2.2.5 - I2C DEFER handling

2016-07-11 Thread Sasha Levin
From: Todd Previte 

This patch has been added to the 4.1 stable tree. If you have any
objections, please let us know.

===

[ Upstream commit 396aa4451e865d1e36d6d4e0686a9303c038b606 ]

For test 4.2.2.5 to pass per the Link CTS Core 1.2 rev1.1 spec, the source
device must attempt at least 7 times to read the EDID when it receives an
I2C defer. The normal DRM code makes only 7 retries, regardless of whether
or not the response is a native defer or an I2C defer. Test 4.2.2.5 fails
since there are native defers interspersed with the I2C defers which
results in less than 7 EDID read attempts.

The solution is to add the numer of defers to the retry counter when an I2C
DEFER is returned such that another read attempt will be made. This situation
should normally only occur in compliance testing, however, as a worse case
real-world scenario, it would result in 13 attempts ( 6 native defers, 7 I2C
defers) for a single transaction to complete. The net result is a slightly
slower response to an EDID read that shouldn't significantly impact overall
performance.

V2:
- Added a check on the number of I2C Defers to limit the number
  of times that the retries variable will be decremented. This
  is to address review feedback regarding possible infinite loops
  from misbehaving sink devices.
V3:
- Fixed the limit value to 7 instead of 8 to get the correct retry
  count.
- Combined the increment of the defer count into the if-statement
V4:
- Removed i915 tag from subject as the patch is not i915-specific
V5:
- Updated the for-loop to add the number of i2c defers to the retry
  counter such that the correct number of retry attempts will be
  made

Signed-off-by: Todd Previte 
Cc: dri-devel at lists.freedesktop.org
Reviewed-by: Paulo Zanoni 
Signed-off-by: Daniel Vetter 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/drm_dp_helper.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 71dcbc6..7f0356e 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -432,7 +432,7 @@ static u32 drm_dp_i2c_functionality(struct i2c_adapter 
*adapter)
  */
 static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, struct drm_dp_aux_msg 
*msg)
 {
-   unsigned int retry;
+   unsigned int retry, defer_i2c;
int ret;

/*
@@ -440,7 +440,7 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, struct 
drm_dp_aux_msg *msg)
 * is required to retry at least seven times upon receiving AUX_DEFER
 * before giving up the AUX transaction.
 */
-   for (retry = 0; retry < 7; retry++) {
+   for (retry = 0, defer_i2c = 0; retry < (7 + defer_i2c); retry++) {
mutex_lock(>hw_mutex);
ret = aux->transfer(aux, msg);
mutex_unlock(>hw_mutex);
@@ -499,7 +499,13 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, 
struct drm_dp_aux_msg *msg)

case DP_AUX_I2C_REPLY_DEFER:
DRM_DEBUG_KMS("I2C defer\n");
+   /* DP Compliance Test 4.2.2.5 Requirement:
+* Must have at least 7 retries for I2C defers on the
+* transaction to pass this test
+*/
aux->i2c_defer_count++;
+   if (defer_i2c < 7)
+   defer_i2c++;
usleep_range(400, 500);
continue;

-- 
2.5.0



[Bug 96868] AMDGPU Tonga only does 2560x1440 at 120hz, switching to 144hz causes display errors, same thing used to happen with fglrx.

2016-07-11 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=96868

--- Comment #7 from almoped at gmail.com ---
Created attachment 125011
  --> https://bugs.freedesktop.org/attachment.cgi?id=125011=edit
143.9hz picture of screen

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160711/cdedb324/attachment.html>


[Bug 96868] AMDGPU Tonga only does 2560x1440 at 120hz, switching to 144hz causes display errors, same thing used to happen with fglrx.

2016-07-11 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=96868

--- Comment #6 from almoped at gmail.com ---
Neither high or low power_dpm_force_performance_level seems to make any
difference.

There is a difference between the 143.9 and 144 option. At 144 the whole screen
is displayed between the flickers, such that it is possible to make out whats
going on. 143.9 hz is never better than attached picture.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160711/e0a4c1b7/attachment.html>


[PATCH v1 6/6] drm/rockchip: dw_hdmi: introduce the pclk for grf

2016-07-11 Thread Yakir Yang
For RK3399's GRF module, if we want to operate the graphic related grf
registers, we need to enable the pclk_vio_grf which supply power for VIO
GRF IOs, so it's better to introduce an optional grf clock in driver.

Signed-off-by: Yakir Yang 
---
 .../bindings/display/rockchip/dw_hdmi-rockchip.txt   |  3 ++-
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c  | 20 
 2 files changed, 22 insertions(+), 1 deletion(-)

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt 
b/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
index 4e23ca4..e22d70f 100644
--- a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
+++ b/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
@@ -18,7 +18,8 @@ Required properties:
 Optional properties
 - ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
 - clocks, clock-names: phandle to the HDMI CEC clock, name should be "cec",
-  phandle to the VPLL clock, name should be "vpll".
+  phandle to the VPLL clock, name should be "vpll",
+  phandle to the GRF clock, name should be "grf".

 Example:
 hdmi: hdmi at ff98 {
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 701bb73..69e6efb 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -36,6 +36,7 @@ struct rockchip_hdmi {
struct drm_encoder encoder;
enum dw_hdmi_devtype dev_type;
struct clk *vpll_clk;
+   struct clk *grf_clk;
 };

 #define to_rockchip_hdmi(x)container_of(x, struct rockchip_hdmi, x)
@@ -166,6 +167,16 @@ static int rockchip_hdmi_parse_dt(struct rockchip_hdmi 
*hdmi)
return PTR_ERR(hdmi->vpll_clk);
}

+   hdmi->grf_clk = devm_clk_get(hdmi->dev, "grf");
+   if (PTR_ERR(hdmi->grf_clk) == -ENOENT) {
+   hdmi->grf_clk = NULL;
+   } else if (PTR_ERR(hdmi->grf_clk) == -EPROBE_DEFER) {
+   return -EPROBE_DEFER;
+   } else if (IS_ERR(hdmi->grf_clk)) {
+   dev_err(hdmi->dev, "failed to get grf clock\n");
+   return PTR_ERR(hdmi->grf_clk);
+   }
+
ret = clk_prepare_enable(hdmi->vpll_clk);
if (ret) {
dev_err(hdmi->dev, "Failed to enable HDMI vpll: %d\n", ret);
@@ -225,6 +236,7 @@ static void dw_hdmi_rockchip_encoder_enable(struct 
drm_encoder *encoder)
u32 lcdsel_grf_reg, lcdsel_mask;
u32 val;
int mux;
+   int ret;

switch (hdmi->dev_type) {
case RK3288_HDMI:
@@ -245,9 +257,17 @@ static void dw_hdmi_rockchip_encoder_enable(struct 
drm_encoder *encoder)
else
val = HIWORD_UPDATE(0, lcdsel_mask);

+   ret = clk_prepare_enable(hdmi->grf_clk);
+   if (ret < 0) {
+   dev_err(hdmi->dev, "failed to enable grfclk %d\n", ret);
+   return;
+   }
+
regmap_write(hdmi->regmap, lcdsel_grf_reg, val);
dev_dbg(hdmi->dev, "vop %s output to hdmi\n",
(mux) ? "LIT" : "BIG");
+
+   clk_disable_unprepare(hdmi->grf_clk);
 }

 static int
-- 
1.9.1




[PATCH v1 5/6] drm/rockchip: dw_hdmi: introduce the VPLL clock setting

2016-07-11 Thread Yakir Yang
For RK3399 HDMI, there is an external clock need for HDMI PHY,
and it should keep the same clock rate with VOP DCLK.

VPLL have supported the clock for HDMI PHY, but there is no
clock divider bewteen VPLL and HDMI PHY. So we need to set the
VPLL rate manually in HDMI driver.

Signed-off-by: Yakir Yang 
---
 .../bindings/display/rockchip/dw_hdmi-rockchip.txt |  3 ++-
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c| 25 +-
 2 files changed, 26 insertions(+), 2 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt 
b/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
index 4e573d2..4e23ca4 100644
--- a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
+++ b/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
@@ -17,7 +17,8 @@ Required properties:

 Optional properties
 - ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
-- clocks, clock-names: phandle to the HDMI CEC clock, name should be "cec"
+- clocks, clock-names: phandle to the HDMI CEC clock, name should be "cec",
+  phandle to the VPLL clock, name should be "vpll".

 Example:
 hdmi: hdmi at ff98 {
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 329099b..701bb73 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -7,10 +7,12 @@
  * (at your option) any later version.
  */

+#include 
+#include 
 #include 
 #include 
-#include 
 #include 
+
 #include 
 #include 
 #include 
@@ -33,6 +35,7 @@ struct rockchip_hdmi {
struct regmap *regmap;
struct drm_encoder encoder;
enum dw_hdmi_devtype dev_type;
+   struct clk *vpll_clk;
 };

 #define to_rockchip_hdmi(x)container_of(x, struct rockchip_hdmi, x)
@@ -145,6 +148,7 @@ static const struct dw_hdmi_phy_config 
rockchip_phy_config[] = {
 static int rockchip_hdmi_parse_dt(struct rockchip_hdmi *hdmi)
 {
struct device_node *np = hdmi->dev->of_node;
+   int ret;

hdmi->regmap = syscon_regmap_lookup_by_phandle(np, "rockchip,grf");
if (IS_ERR(hdmi->regmap)) {
@@ -152,6 +156,22 @@ static int rockchip_hdmi_parse_dt(struct rockchip_hdmi 
*hdmi)
return PTR_ERR(hdmi->regmap);
}

+   hdmi->vpll_clk = devm_clk_get(hdmi->dev, "vpll");
+   if (PTR_ERR(hdmi->vpll_clk) == -ENOENT) {
+   hdmi->vpll_clk = NULL;
+   } else if (PTR_ERR(hdmi->vpll_clk) == -EPROBE_DEFER) {
+   return -EPROBE_DEFER;
+   } else if (IS_ERR(hdmi->vpll_clk)) {
+   dev_err(hdmi->dev, "failed to get grf clock\n");
+   return PTR_ERR(hdmi->vpll_clk);
+   }
+
+   ret = clk_prepare_enable(hdmi->vpll_clk);
+   if (ret) {
+   dev_err(hdmi->dev, "Failed to enable HDMI vpll: %d\n", ret);
+   return ret;
+   }
+
return 0;
 }

@@ -194,6 +214,9 @@ static void dw_hdmi_rockchip_encoder_mode_set(struct 
drm_encoder *encoder,
  struct drm_display_mode *mode,
  struct drm_display_mode *adj_mode)
 {
+   struct rockchip_hdmi *hdmi = to_rockchip_hdmi(encoder);
+
+   clk_set_rate(hdmi->vpll_clk, adj_mode->clock * 1000);
 }

 static void dw_hdmi_rockchip_encoder_enable(struct drm_encoder *encoder)
-- 
1.9.1




[PATCH v1 4/6] drm/rockchip: dw_hdmi: add RK3399 HDMI support

2016-07-11 Thread Yakir Yang
RK3399 and RK3288 shared the same HDMI IP controller, only some light
difference with GRF configure.

Signed-off-by: Yakir Yang 
---
 .../devicetree/bindings/display/bridge/dw_hdmi.txt |  1 +
 .../bindings/display/rockchip/dw_hdmi-rockchip.txt |  3 +-
 drivers/gpu/drm/bridge/dw-hdmi.c   |  2 +-
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c| 45 ++
 include/drm/bridge/dw_hdmi.h   |  6 +++
 5 files changed, 48 insertions(+), 9 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt 
b/Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt
index dc1452f..f50d4d5 100644
--- a/Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt
+++ b/Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt
@@ -6,6 +6,7 @@ Required properties:
* "fsl,imx6q-hdmi"
* "fsl,imx6dl-hdmi"
* "rockchip,rk3288-dw-hdmi"
+   * "rockchip,rk3399-dw-hdmi"
 - reg: Physical base address and length of the controller's registers.
 - interrupts: The HDMI interrupt number
 - clocks, clock-names : must have the phandles to the HDMI iahb and isfr 
clocks,
diff --git 
a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt 
b/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
index 668091f..4e573d2 100644
--- a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
+++ b/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
@@ -2,7 +2,8 @@ Rockchip specific extensions to the Synopsys Designware HDMI
 

 Required properties:
-- compatible: "rockchip,rk3288-dw-hdmi";
+- compatible: "rockchip,rk3288-dw-hdmi",
+ "rockchip,rk3399-dw-hdmi";
 - reg: Physical base address and length of the controller's registers.
 - clocks: phandle to hdmi iahb and isfr clocks.
 - clock-names: should be "iahb" "isfr"
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 70b1f7d..29f855a 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -833,7 +833,7 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi, 
unsigned char prep,
dw_hdmi_phy_gen2_txpwron(hdmi, 1);
dw_hdmi_phy_gen2_pddq(hdmi, 0);

-   if (hdmi->dev_type == RK3288_HDMI)
+   if (is_rockchip(hdmi->dev_type))
dw_hdmi_phy_enable_spare(hdmi, 1);

/*Wait for PHY PLL lock */
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 8cb9ed2..329099b 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -21,13 +21,18 @@
 #include "rockchip_drm_drv.h"
 #include "rockchip_drm_vop.h"

-#define GRF_SOC_CON60x025c
-#define HDMI_SEL_VOP_LIT(1 << 4)
+#define RK3288_GRF_SOC_CON60x025C
+#define RK3288_HDMI_LCDC_SEL   BIT(4)
+#define RK3399_GRF_SOC_CON20   0x6250
+#define RK3399_HDMI_LCDC_SEL   BIT(6)
+
+#define HIWORD_UPDATE(val, mask)   (val | (mask) << 16)

 struct rockchip_hdmi {
struct device *dev;
struct regmap *regmap;
struct drm_encoder encoder;
+   enum dw_hdmi_devtype dev_type;
 };

 #define to_rockchip_hdmi(x)container_of(x, struct rockchip_hdmi, x)
@@ -194,16 +199,30 @@ static void dw_hdmi_rockchip_encoder_mode_set(struct 
drm_encoder *encoder,
 static void dw_hdmi_rockchip_encoder_enable(struct drm_encoder *encoder)
 {
struct rockchip_hdmi *hdmi = to_rockchip_hdmi(encoder);
+   u32 lcdsel_grf_reg, lcdsel_mask;
u32 val;
int mux;

+   switch (hdmi->dev_type) {
+   case RK3288_HDMI:
+   lcdsel_grf_reg = RK3288_GRF_SOC_CON6;
+   lcdsel_mask = RK3288_HDMI_LCDC_SEL;
+   break;
+   case RK3399_HDMI:
+   lcdsel_grf_reg = RK3399_GRF_SOC_CON20;
+   lcdsel_mask = RK3399_HDMI_LCDC_SEL;
+   break;
+   default:
+   return;
+   };
+
mux = drm_of_encoder_active_endpoint_id(hdmi->dev->of_node, encoder);
if (mux)
-   val = HDMI_SEL_VOP_LIT | (HDMI_SEL_VOP_LIT << 16);
+   val = HIWORD_UPDATE(lcdsel_mask, lcdsel_mask);
else
-   val = HDMI_SEL_VOP_LIT << 16;
+   val = HIWORD_UPDATE(0, lcdsel_mask);

-   regmap_write(hdmi->regmap, GRF_SOC_CON6, val);
+   regmap_write(hdmi->regmap, lcdsel_grf_reg, val);
dev_dbg(hdmi->dev, "vop %s output to hdmi\n",
(mux) ? "LIT" : "BIG");
 }
@@ -229,7 +248,7 @@ static const struct drm_encoder_helper_funcs 
dw_hdmi_rockchip_encoder_helper_fun
.atomic_check = dw_hdmi_rockchip_encoder_atomic_check,
 };

-static const struct dw_hdmi_plat_data rockchip_hdmi_drv_data = {
+static const struct dw_hdmi_plat_data rk3288_hdmi_drv_data = {
.mode_valid = dw_hdmi_rockchip_mode_valid,
.mpll_cfg   = 

[PATCH v1 3/6] drm/rockchip: dw_hdmi: Use auto-generated tables

2016-07-11 Thread Yakir Yang
From: Douglas Anderson 

The previous tables for mpll_cfg and curr_ctrl were created using the
20-pages of example settings provided by the PHY vendor.  Those
example settings weren't particularly dense, so there were places
where we were guessing what the settings would be for 10-bit and
12-bit (not that we use those anyway).  It was also always a lot of
extra work every time we wanted to add a new clock rate since we had
to cross-reference several tables.

In  I've gone through the work to figure
out how to generate this table automatically.  Let's now use the
automatically generated table and then we'll never need to look at it
again.

We only support 8-bit mode right now and only support a small number
of clock rates and and I've verified that the only 8-bit rate that was
affected was 148.5.  That mode appears to have been wrong in the old
table.

Signed-off-by: Douglas Anderson 
Signed-off-by: Yakir Yang 
Reviewed-by: Stéphane Marchesin 
---
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 130 +++-
 1 file changed, 69 insertions(+), 61 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index cdb63ac..8cb9ed2 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -34,80 +34,88 @@ struct rockchip_hdmi {

 static const struct dw_hdmi_mpll_config rockchip_mpll_cfg[] = {
{
-   2700, {
-   { 0x00b3, 0x},
-   { 0x2153, 0x},
-   { 0x40f3, 0x}
+   30666000, {
+   { 0x00b3, 0x },
+   { 0x2153, 0x },
+   { 0x40f3, 0x },
},
-   }, {
-   3600, {
-   { 0x00b3, 0x},
-   { 0x2153, 0x},
-   { 0x40f3, 0x}
+   },  {
+   3680, {
+   { 0x00b3, 0x },
+   { 0x2153, 0x },
+   { 0x40a2, 0x0001 },
},
-   }, {
-   4000, {
-   { 0x00b3, 0x},
-   { 0x2153, 0x},
-   { 0x40f3, 0x}
+   },  {
+   4600, {
+   { 0x00b3, 0x },
+   { 0x2142, 0x0001 },
+   { 0x40a2, 0x0001 },
},
-   }, {
-   5400, {
-   { 0x0072, 0x0001},
-   { 0x2142, 0x0001},
-   { 0x40a2, 0x0001},
+   },  {
+   61333000, {
+   { 0x0072, 0x0001 },
+   { 0x2142, 0x0001 },
+   { 0x40a2, 0x0001 },
},
-   }, {
-   6500, {
-   { 0x0072, 0x0001},
-   { 0x2142, 0x0001},
-   { 0x40a2, 0x0001},
+   },  {
+   7360, {
+   { 0x0072, 0x0001 },
+   { 0x2142, 0x0001 },
+   { 0x4061, 0x0002 },
},
-   }, {
-   6600, {
-   { 0x013e, 0x0003},
-   { 0x217e, 0x0002},
-   { 0x4061, 0x0002}
+   },  {
+   9200, {
+   { 0x0072, 0x0001 },
+   { 0x2145, 0x0002 },
+   { 0x4061, 0x0002 },
+   },
+   },  {
+   122666000, {
+   { 0x0051, 0x0002 },
+   { 0x2145, 0x0002 },
+   { 0x4061, 0x0002 },
},
-   }, {
-   7425, {
-   { 0x0072, 0x0001},
-   { 0x2145, 0x0002},
-   { 0x4061, 0x0002}
+   },  {
+   14720, {
+   { 0x0051, 0x0002 },
+   { 0x2145, 0x0002 },
+   { 0x4064, 0x0003 },
},
-   }, {
-   8350, {
-   { 0x0072, 0x0001},
+   },  {
+   18400, {
+   { 0x0051, 0x0002 },
+   { 0x214c, 0x0003 },
+   { 0x4064, 0x0003 },
},
-   }, {
-   10800, {
-   { 0x0051, 0x0002},
-   { 0x2145, 0x0002},
-   { 0x4061, 0x0002}
+   },  {
+   22000, {
+   { 0x0040, 0x0003 },
+   { 0x214c, 0x0003 },
+   { 0x4064, 0x0003 },
},
-   }, {
-   10650, {
-   { 0x0051, 0x0002},
-   { 0x2145, 0x0002},
-   

[PATCH v1 2/6] drm/rockchip: dw_hdmi: adjust cklvl & txlvl for RF/EMI

2016-07-11 Thread Yakir Yang
Dut to the high HDMI signal voltage driver, Mickey have meet
a serious RF/EMI problem, so we decided to reduce HDMI signal
voltage to a proper value.

The default params for phy is cklvl = 20 & txlvl = 13 (RF/EMI failed)
  ck: lvl = 13, term=100, vlo = 2.71, vhi=3.14, vswing = 0.43
  tx: lvl = 20, term=100, vlo = 2.81, vhi=3.16, vswing = 0.35

1. We decided to reduce voltage value to lower, but VSwing still
keep high, RF/EMI have been improved but still failed.
   ck: lvl =  6, term=100, vlo = 2.61, vhi=3.11, vswing = 0.50
   tx: lvl =  6, term=100, vlo = 2.61, vhi=3.11, vswing = 0.50

2. We try to keep voltage value and vswing both lower, then RF/EMI
test all passed  ;)
   ck: lvl = 11, term= 66, vlo = 2.68, vhi=3.09, vswing = 0.40
   tx: lvl = 11, term= 66, vlo = 2.68, vhi=3.09, vswing = 0.40
When we back to run HDMI different test and single-end test, we see
different test passed, but signle-end test failed. The oscilloscope
show that simgle-end clock's VL value is 1.78v (which remind LowLimit
should not lower then 2.6v).

3. That's to say there are some different between PHY document and
measure value. And according to experiment 2 results, we need to
higher clock voltage and lower data voltage, then we can keep RF/EMI
satisfied and single-end & differen test passed.
  ck: lvl =  9, term=100, vlo = 2.65, vhi=3.12, vswing = 0.47
  tx: lvl = 16, term=100, vlo = 2.75, vhi=3.15, vswing = 0.39

Signed-off-by: Yakir Yang 
Reviewed-by: Douglas Anderson 
---
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index a621118..cdb63ac 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -124,7 +124,7 @@ static const struct dw_hdmi_curr_ctrl rockchip_cur_ctr[] = {
 static const struct dw_hdmi_phy_config rockchip_phy_config[] = {
/*pixelclk   symbol   term   vlev*/
{ 7425,  0x8009, 0x0004, 0x0272},
-   { 14850, 0x802b, 0x0004, 0x028d},
+   { 16500, 0x802b, 0x0004, 0x0209},
{ 29700, 0x8039, 0x0005, 0x028d},
{ ~0UL,  0x, 0x, 0x}
 };
-- 
1.9.1




[PATCH v1 1/6] drm/rockchip: dw_hdmi: Set cur_ctr to 0 always

2016-07-11 Thread Yakir Yang
From: Douglas Anderson 

Jitter was improved by lowering the MPLL bandwidth to account for high
frequency noise in the rk3288 PLL.  In each case MPLL bandwidth was
lowered only enough to get us a comfortable margin.  We believe that
lowering the bandwidth like this is safe given sufficient testing.

Signed-off-by: Douglas Anderson 
Signed-off-by: Yakir Yang 
---
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 16 ++--
 1 file changed, 2 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 801110f..a621118 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -115,20 +115,8 @@ static const struct dw_hdmi_mpll_config 
rockchip_mpll_cfg[] = {
 static const struct dw_hdmi_curr_ctrl rockchip_cur_ctr[] = {
/*  pixelclkbpp8bpp10   bpp12 */
{
-   4000,  { 0x0018, 0x0018, 0x0018 },
-   }, {
-   6500,  { 0x0028, 0x0028, 0x0028 },
-   }, {
-   6600,  { 0x0038, 0x0038, 0x0038 },
-   }, {
-   7425,  { 0x0028, 0x0038, 0x0038 },
-   }, {
-   8350,  { 0x0028, 0x0038, 0x0038 },
-   }, {
-   14625, { 0x0038, 0x0038, 0x0038 },
-   }, {
-   14850, { 0x, 0x0038, 0x0038 },
-   }, {
+   6, { 0x, 0x, 0x },
+   },  {
~0UL,  { 0x, 0x, 0x},
}
 };
-- 
1.9.1




[PATCH v1 0/6] Add RK3399 HDMI Support

2016-07-11 Thread Yakir Yang
Mark,

RK3399 and RK3288 shared the same HDMI IP controller, only some
light difference with GRF configure, and an external VPLL clock
need to configure.

Thanks,
- Yakir


Douglas Anderson (2):
  drm/rockchip: dw_hdmi: Set cur_ctr to 0 always
  drm/rockchip: dw_hdmi: Use auto-generated tables

Yakir Yang (4):
  drm/rockchip: dw_hdmi: adjust cklvl & txlvl for RF/EMI
  drm/rockchip: dw_hdmi: add RK3399 HDMI support
  drm/rockchip: dw_hdmi: introduce the VPLL clock setting
  drm/rockchip: dw_hdmi: introduce the pclk for grf

 .../devicetree/bindings/display/bridge/dw_hdmi.txt |   1 +
 .../bindings/display/rockchip/dw_hdmi-rockchip.txt |   7 +-
 drivers/gpu/drm/bridge/dw-hdmi.c   |   2 +-
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c| 238 +
 include/drm/bridge/dw_hdmi.h   |   6 +
 5 files changed, 167 insertions(+), 87 deletions(-)

-- 
1.9.1




[PATCH 3/3] drm/i915/guc: revisit GuC loader message levels

2016-07-11 Thread Dave Gordon
Some downgraded from DRM_ERROR() to DRM_WARN(), some eliminated,
and a few upgraded from DRM_INFO() to DRM_NOTE() or DRM_WARN().

Signed-off-by: Dave Gordon 
---
 drivers/gpu/drm/i915/intel_guc_loader.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 605c696..fd032eb 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -140,12 +140,14 @@ static u32 get_gttype(struct drm_i915_private *dev_priv)

 static u32 get_core_family(struct drm_i915_private *dev_priv)
 {
-   switch (INTEL_INFO(dev_priv)->gen) {
+   u32 gen = INTEL_GEN(dev_priv);
+
+   switch (gen) {
case 9:
return GFXCORE_FAMILY_GEN9;

default:
-   DRM_ERROR("GUC: unsupported core family\n");
+   DRM_WARN("GEN%d does not support GuC operation\n", gen);
return GFXCORE_FAMILY_UNKNOWN;
}
 }
@@ -433,7 +435,7 @@ int intel_guc_setup(struct drm_device *dev)
goto fail;
} else if (*fw_path == '\0') {
/* Device has a GuC but we don't know what f/w to load? */
-   DRM_INFO("No GuC firmware known for this platform\n");
+   DRM_WARN("No GuC firmware known for this platform\n");
err = -ENODEV;
goto fail;
}
@@ -471,10 +473,8 @@ int intel_guc_setup(struct drm_device *dev)
 * that the state and timing are fairly predictable
 */
err = i915_reset_guc(dev_priv);
-   if (err) {
-   DRM_ERROR("GuC reset failed: %d\n", err);
+   if (err)
goto fail;
-   }

err = guc_ucode_xfer(dev_priv);
if (!err)
@@ -532,15 +532,15 @@ int intel_guc_setup(struct drm_device *dev)
else if (err == 0)
DRM_INFO("GuC firmware load skipped\n");
else if (ret != -EIO)
-   DRM_INFO("GuC firmware load failed: %d\n", err);
+   DRM_NOTE("GuC firmware load failed: %d\n", err);
else
-   DRM_ERROR("GuC firmware load failed: %d\n", err);
+   DRM_WARN("GuC firmware load failed: %d\n", err);

if (i915.enable_guc_submission) {
if (fw_path == NULL)
DRM_INFO("GuC submission without firmware not 
supported\n");
if (ret == 0)
-   DRM_INFO("Falling back from GuC submission to execlist 
mode\n");
+   DRM_NOTE("Falling back from GuC submission to execlist 
mode\n");
else
DRM_ERROR("GuC init failed: %d\n", ret);
}
@@ -656,7 +656,7 @@ static void guc_fw_fetch(struct drm_device *dev, struct 
intel_guc_fw *guc_fw)
 fail:
DRM_DEBUG_DRIVER("GuC fw fetch status FAIL; err %d, fw %p, obj %p\n",
err, fw, guc_fw->guc_fw_obj);
-   DRM_ERROR("Failed to fetch GuC firmware from %s (error %d)\n",
+   DRM_WARN("Failed to fetch GuC firmware from %s (error %d)\n",
  guc_fw->guc_fw_path, err);

mutex_lock(>struct_mutex);
-- 
1.9.1



[PATCH 2/3] drm/i915/guc: downgrade some DRM_ERROR() messages to DRM_WARN()

2016-07-11 Thread Dave Gordon
Where we're going to continue regardless of the problem, rather than
fail, then the message should be a WARNing rather than an ERROR.

Signed-off-by: Dave Gordon 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 18 +++---
 1 file changed, 7 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 2112e02..e299b64 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -114,10 +114,8 @@ static int host2guc_action(struct intel_guc *guc, u32 
*data, u32 len)
if (ret != -ETIMEDOUT)
ret = -EIO;

-   DRM_ERROR("GUC: host2guc action 0x%X failed. ret=%d "
-   "status=0x%08X response=0x%08X\n",
-   data[0], ret, status,
-   I915_READ(SOFT_SCRATCH(15)));
+   DRM_WARN("Action 0x%X failed; ret=%d status=0x%08X 
response=0x%08X\n",
+data[0], ret, status, I915_READ(SOFT_SCRATCH(15)));

dev_priv->guc.action_fail += 1;
dev_priv->guc.action_err = ret;
@@ -553,8 +551,8 @@ static int guc_ring_doorbell(struct i915_guc_client *gc)
if (db_ret.db_status == GUC_DOORBELL_DISABLED)
break;

-   DRM_ERROR("Cookie mismatch. Expected %d, returned %d\n",
- db_cmp.cookie, db_ret.cookie);
+   DRM_WARN("Cookie mismatch. Expected %d, found %d\n",
+db_cmp.cookie, db_ret.cookie);

/* update the cookie to newly read cookie from GuC */
db_cmp.cookie = db_ret.cookie;
@@ -726,8 +724,8 @@ static void guc_init_doorbell_hw(struct intel_guc *guc)
/* Restore to original value */
err = guc_update_doorbell_id(guc, client, db_id);
if (err)
-   DRM_ERROR("Failed to restore doorbell to %d, err %d\n",
-   db_id, err);
+   DRM_WARN("Failed to restore doorbell to %d, err %d\n",
+db_id, err);

for (i = 0; i < GUC_MAX_DOORBELLS; ++i) {
i915_reg_t drbreg = GEN8_DRBREGL(i);
@@ -819,8 +817,6 @@ static void guc_init_doorbell_hw(struct intel_guc *guc)
return client;

 err:
-   DRM_ERROR("FAILED to create priority %u GuC client!\n", priority);
-
guc_client_free(dev_priv, client);
return NULL;
 }
@@ -998,7 +994,7 @@ int i915_guc_submission_enable(struct drm_i915_private 
*dev_priv)
  GUC_CTX_PRIORITY_KMD_NORMAL,
  dev_priv->kernel_context);
if (!client) {
-   DRM_ERROR("Failed to create execbuf guc_client\n");
+   DRM_ERROR("Failed to create normal GuC client!\n");
return -ENOMEM;
}

-- 
1.9.1



[PATCH 1/3] drm: extra printk() wrapper macros

2016-07-11 Thread Dave Gordon
We had only DRM_INFO() and DRM_ERROR(), whereas the underlying printk()
provides several other useful intermediate levels such as NOTICE and
WARNING. So this patch fills out the set by providing both regular and
once-only macros for each of the levels INFO, NOTICE, and WARNING, using
a common underlying macro that does all the token-pasting.

DRM_ERROR is unchanged, as it's not just a printk wrapper.

Signed-off-by: Dave Gordon 
---
 include/drm/drmP.h | 26 --
 1 file changed, 20 insertions(+), 6 deletions(-)

diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index cf918e3e..82648b1 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -162,6 +162,26 @@ void drm_err(const char *format, ...);
 /** \name Macros to make printk easier */
 /*@{*/

+#define_DRM_PRINTK(once, level, fmt, ...)  
\
+   do {\
+   printk##once(KERN_##level "[" DRM_NAME "] " fmt,\
+##__VA_ARGS__);\
+   } while (0)
+
+#define DRM_INFO(fmt, ...) \
+   _DRM_PRINTK(, INFO, fmt, ##__VA_ARGS__)
+#define DRM_NOTE(fmt, ...) \
+   _DRM_PRINTK(, NOTICE, fmt, ##__VA_ARGS__)
+#define DRM_WARN(fmt, ...) \
+   _DRM_PRINTK(, WARNING, fmt, ##__VA_ARGS__)
+
+#define DRM_INFO_ONCE(fmt, ...)
\
+   _DRM_PRINTK(_once, INFO, fmt, __VA_ARGS__)
+#define DRM_NOTE_ONCE(fmt, ...)\
+   _DRM_PRINTK(_once, NOTICE, fmt, ##__VA_ARGS__)
+#define DRM_WARN_ONCE(fmt, ...)
\
+   _DRM_PRINTK(_once, WARNING, fmt, ##__VA_ARGS__)
+
 /**
  * Error output.
  *
@@ -187,12 +207,6 @@ void drm_err(const char *format, ...);
drm_err(fmt, ##__VA_ARGS__);\
 })

-#define DRM_INFO(fmt, ...) \
-   printk(KERN_INFO "[" DRM_NAME "] " fmt, ##__VA_ARGS__)
-
-#define DRM_INFO_ONCE(fmt, ...)\
-   printk_once(KERN_INFO "[" DRM_NAME "] " fmt, ##__VA_ARGS__)
-
 /**
  * Debug output.
  *
-- 
1.9.1



[PATCH v7 2/2] drm/panel: Add JDI LT070ME05000 WUXGA DSI Panel

2016-07-11 Thread Vinay Simha
emil,

As you had suggested to drop the spurious returns in
jdi_panel_unprepare and drop the return itself.
But as i had mentioned earlier , we cannot drop the return function
and void for jdi_panel_unprepare , since the drm fun* requires int as
return type (drm_panel_funcs .unprepare).

please do re-point out if i had still missed anything.

fyi,
v7:
 * emil review comments incorporated
   added ARRAY_SIZE in struct, regulator_bulk_disable in poweroff,
   gpios checks dropped.
   some returns cannot be dropped, since drm panel framework return
   type required.

On Mon, Jul 11, 2016 at 5:50 PM, Thierry Reding
 wrote:
> On Sun, Jul 03, 2016 at 11:52:11PM +0100, Emil Velikov wrote:
>> On 28 June 2016 at 16:59, Vinay Simha  wrote:
>> > hi,
>> >
>> > Any further comments or reviews?
>> >
>> You still haven't covered my earlier suggestions, as such I cannot
>> give you a r-b :-( They are not blockers by any means, but it'll be
>> up-to the maintainer to ack/pick this up.
>>
>> Thierry ?
>
> Vinay, please address Emil's comments and resend. I also see that you
> stopped sending the device tree bindings patch at some point. Please do
> include that when you repost as I don't seem to be able to find a recent
> version anywhere.
>
> Thierry



-- 
Regards,

Vinay Simha.B.N.


[PATCH] drm/i915/skl: Add support for the SAGV, fix underrun hangs

2016-07-11 Thread Lyude
Since the watermark calculations for Skylake are still broken, we're apt
to hitting underruns very easily under multi-monitor configurations.
While it would be lovely if this was fixed, it's not. Another problem
that's been coming from this however, is the mysterious issue of
underruns causing full system hangs. An easy way to reproduce this with
a skylake system:

- Get a laptop with a skylake GPU, and hook up two external monitors to
  it
- Move the cursor from the built-in LCD to one of the external displays
  as quickly as you can
- You'll get a few pipe underruns, and eventually the entire system will
  just freeze.

After doing a lot of investigation and reading through the bspec, I
found the existence of the SAGV, which is responsible for adjusting the
system agent voltage and clock frequencies depending on how much power
we need. According to the bspec:

"The display engine access to system memory is blocked during the
 adjustment time. SAGV defaults to enabled. Software must use the
 GT-driver pcode mailbox to disable SAGV when the display engine is not
 able to tolerate the blocking time."

The rest of the bspec goes on to explain that software can simply leave
the SAGV enabled, and disable it when we use interlaced pipes/have more
then one pipe active.

Sure enough, with this patchset the system hangs resulting from pipe
underruns on Skylake have completely vanished on my T460s.

Cc: Daniel Vetter 
Cc: Ville Syrjälä 
Signed-off-by: Lyude 
---
 drivers/gpu/drm/i915/i915_drv.h |   2 +
 drivers/gpu/drm/i915/i915_reg.h |   5 ++
 drivers/gpu/drm/i915/intel_pm.c | 103 
 3 files changed, 110 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 03e1bfa..660d0a6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1959,6 +1959,8 @@ struct drm_i915_private {
struct i915_suspend_saved_registers regfile;
struct vlv_s0ix_state vlv_s0ix_state;

+   bool skl_sagv_enabled;
+
struct {
/*
 * Raw watermark latency values:
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 8bfde75..9b2eb0b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7162,6 +7162,11 @@ enum {
 #define   HSW_PCODE_DE_WRITE_FREQ_REQ  0x17
 #define   DISPLAY_IPS_CONTROL  0x19
 #define  HSW_PCODE_DYNAMIC_DUTY_CYCLE_CONTROL  0x1A
+#define   GEN9_PCODE_SAGV_CONTROL  0x21
+#define GEN9_SAGV_DISABLE  0x0
+#define GEN9_SAGV_LOW_FREQ 0x1
+#define GEN9_SAGV_HIGH_FREQ0x2
+#define GEN9_SAGV_DYNAMIC_FREQ  0x3
 #define GEN6_PCODE_DATA_MMIO(0x138128)
 #define   GEN6_PCODE_FREQ_IA_RATIO_SHIFT   8
 #define   GEN6_PCODE_FREQ_RING_RATIO_SHIFT 16
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 5a8ee0c..07807aa 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2876,6 +2876,102 @@ skl_wm_plane_id(const struct intel_plane *plane)
 }

 static void
+skl_sagv_get_hw_state(struct drm_i915_private *dev_priv)
+{
+   u32 temp;
+   int ret;
+
+   mutex_lock(_priv->rps.hw_lock);
+   ret = sandybridge_pcode_read(dev_priv, GEN9_PCODE_SAGV_CONTROL, );
+   mutex_unlock(_priv->rps.hw_lock);
+
+   if (!ret) {
+   dev_priv->skl_sagv_enabled = !!(temp & GEN9_SAGV_DYNAMIC_FREQ);
+   } else {
+   /*
+* If for some reason we can't access the SAGV state, follow
+* the bspec and assume it's enabled
+*/
+   DRM_ERROR("Failed to get SAGV state, assuming enabled\n");
+   dev_priv->skl_sagv_enabled = true;
+   }
+}
+
+/*
+ * SAGV dynamically adjusts the system agent voltage and clock frequencies
+ * depending on power and performance requirements. The display engine access
+ * to system memory is blocked during the adjustment time. Having this enabled
+ * in multi-pipe configurations can cause issues (such as underruns causing
+ * full system hangs), and the bspec also suggests that software disable it
+ * when more then one pipe is enabled.
+ */
+static int
+skl_enable_sagv(struct drm_i915_private *dev_priv)
+{
+   int ret;
+
+   if (dev_priv->skl_sagv_enabled)
+   return 0;
+
+   mutex_lock(_priv->rps.hw_lock);
+   DRM_DEBUG_KMS("Enabling the SAGV\n");
+
+   ret = sandybridge_pcode_write(dev_priv, GEN9_PCODE_SAGV_CONTROL,
+ GEN9_SAGV_DYNAMIC_FREQ);
+   if (!ret)
+   dev_priv->skl_sagv_enabled = true;
+   else
+   DRM_ERROR("Failed to enable the SAGV\n");
+
+   /* We don't need to wait for SAGV when enabling */
+   mutex_unlock(_priv->rps.hw_lock);
+   return ret;
+}
+

[PATCH] dma-buf/sync_file: only enable fence signalling during wait

2016-07-11 Thread Gustavo Padovan
2016-07-10 Maarten Lankhorst :

> Op 08-07-16 om 17:44 schreef Gustavo Padovan:
> > From: Gustavo Padovan 
> >
> > Signalling doesn't need to be enabled at sync_file creation, it is only
> > required if userspace waiting the fence to signal through poll().
> >
> > Thus we delay fence_add_callback() until poll is called. It only adds the
> > callback the first time poll() is called. This avoid re-adding the same
> > callback multiple times.
> >
> > v2: rebase and update to work with new fence support for sync_file
> >
> > Signed-off-by: Gustavo Padovan 
> > ---
> > This patch applies on top of my latest sync_file changes to support
> > fence_array: https://lkml.org/lkml/2016/7/4/534
> >
> >  drivers/dma-buf/sync_file.c | 23 ++-
> >  include/linux/sync_file.h   |  2 ++
> >  2 files changed, 16 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
> > index 61a687c..1db4a64 100644
> > --- a/drivers/dma-buf/sync_file.c
> > +++ b/drivers/dma-buf/sync_file.c
> > @@ -86,8 +86,6 @@ struct sync_file *sync_file_create(struct fence *fence)
> >  fence->ops->get_timeline_name(fence), fence->context,
> >  fence->seqno);
> >  
> > -   fence_add_callback(fence, _file->cb, fence_check_cb_func);
> > -
> > return sync_file;
> >  }
> >  EXPORT_SYMBOL(sync_file_create);
> > @@ -269,9 +267,6 @@ static struct sync_file *sync_file_merge(const char 
> > *name, struct sync_file *a,
> > goto err;
> > }
> >  
> > -   fence_add_callback(sync_file->fence, _file->cb,
> > -  fence_check_cb_func);
> > -
> > strlcpy(sync_file->name, name, sizeof(sync_file->name));
> > return sync_file;
> >  
> > @@ -286,7 +281,6 @@ static void sync_file_free(struct kref *kref)
> > struct sync_file *sync_file = container_of(kref, struct sync_file,
> >  kref);
> >  
> > -   fence_remove_callback(sync_file->fence, _file->cb);
> > fence_put(sync_file->fence);
> > kfree(sync_file);
> >  }
> > @@ -306,13 +300,24 @@ static unsigned int sync_file_poll(struct file *file, 
> > poll_table *wait)
> >  
> > poll_wait(file, _file->wq, wait);
> >  
> > +   if (!sync_file->enabled) {
> > +   fence_add_callback(sync_file->fence, _file->cb,
> > +  fence_check_cb_func);
> > +   sync_file->enabled = true;
> > +   }
> Won't this blow up completely with 2 threads polling at the same time?

Indeed, using atomic operations on enabled should fix this.

Gustavo


[PATCH] drm/vc4: remove redundant ret status check

2016-07-11 Thread Eric Anholt
Colin King  writes:

> From: Colin Ian King 
>
> At the current point where ret is being checked for non-zero it has
> not changed since it was initialized to zero, hence the check and the
> label unref are redundant and can be removed.

Reviewed-by: Eric Anholt 

I'll put this in my next pull request.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160711/1ab4cd63/attachment.sig>


[Bug 96881] ViennaCL fails dense_blas-bench-opencl benchmark with doubles on AMD CYPRESS (DRM 2.43.0, LLVM 3.8.0)

2016-07-11 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=96881

--- Comment #2 from Jan Vesely  ---
(In reply to Vedran Miletić from comment #1)
> Jan, does R600 backend in LLVM have relevant instructions implemented?

I don't think they are.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160711/c40973c4/attachment.html>


[PATCH 3/3] drm/vgem: Attach sw fences to exported vGEM dma-buf (ioctl)

2016-07-11 Thread Chris Wilson
On Mon, Jul 11, 2016 at 12:10:40PM -0300, Gustavo Padovan wrote:
> 2016-07-11 Chris Wilson :
> 
> > vGEM buffers are useful for passing data between software clients and
> > hardware renders. By allowing the user to create and attach fences to
> > the exported vGEM buffers (on the dma-buf), the user can implement a
> > deferred renderer and queue hardware operations like flipping and then
> > signal the buffer readiness (i.e. this allows the user to schedule
> > operations out-of-order, but have them complete in-order).
> > 
> > This also makes it much easier to write tightly controlled testcases for
> > dma-buf fencing and signaling between hardware drivers.
> > 
> > Testcase: igt/vgem_basic/dmabuf-fence
> > Signed-off-by: Chris Wilson 
> > Cc: Sean Paul 
> > Cc: Zach Reizner 
> > Cc: Gustavo Padovan 
> > Acked-by: Zach Reizner 
> > ---
> >  drivers/gpu/drm/vgem/Makefile |   2 +-
> >  drivers/gpu/drm/vgem/vgem_drv.c   |  34 ++
> >  drivers/gpu/drm/vgem/vgem_drv.h   |  18 
> >  drivers/gpu/drm/vgem/vgem_fence.c | 220 
> > ++
> >  include/uapi/drm/vgem_drm.h   |  62 +++
> >  5 files changed, 335 insertions(+), 1 deletion(-)
> >  create mode 100644 drivers/gpu/drm/vgem/vgem_fence.c
> >  create mode 100644 include/uapi/drm/vgem_drm.h
> > 
> > diff --git a/drivers/gpu/drm/vgem/Makefile b/drivers/gpu/drm/vgem/Makefile
> > index 3f4c7b842028..bfcdea1330e6 100644
> > --- a/drivers/gpu/drm/vgem/Makefile
> > +++ b/drivers/gpu/drm/vgem/Makefile
> > @@ -1,4 +1,4 @@
> >  ccflags-y := -Iinclude/drm
> > -vgem-y := vgem_drv.o
> > +vgem-y := vgem_drv.o vgem_fence.o
> >  
> >  obj-$(CONFIG_DRM_VGEM) += vgem.o
> > diff --git a/drivers/gpu/drm/vgem/vgem_drv.c 
> > b/drivers/gpu/drm/vgem/vgem_drv.c
> > index b5fb968d2d5c..2659e5cda857 100644
> > --- a/drivers/gpu/drm/vgem/vgem_drv.c
> > +++ b/drivers/gpu/drm/vgem/vgem_drv.c
> > @@ -83,6 +83,34 @@ static const struct vm_operations_struct vgem_gem_vm_ops 
> > = {
> > .close = drm_gem_vm_close,
> >  };
> >  
> > +static int vgem_open(struct drm_device *dev, struct drm_file *file)
> > +{
> > +   struct vgem_file *vfile;
> > +   int ret;
> > +
> > +   vfile = kzalloc(sizeof(*vfile), GFP_KERNEL);
> > +   if (!vfile)
> > +   return -ENOMEM;
> > +
> > +   file->driver_priv = vfile;
> > +
> > +   ret = vgem_fence_open(vfile);
> > +   if (ret) {
> > +   kfree(vfile);
> > +   return ret;
> > +   }
> > +
> > +   return 0;
> > +}
> > +
> > +static void vgem_preclose(struct drm_device *dev, struct drm_file *file)
> > +{
> > +   struct vgem_file *vfile = file->driver_priv;
> > +
> > +   vgem_fence_close(vfile);
> > +   kfree(vfile);
> > +}
> > +
> >  /* ioctls */
> >  
> >  static struct drm_gem_object *vgem_gem_create(struct drm_device *dev,
> > @@ -164,6 +192,8 @@ unref:
> >  }
> >  
> >  static struct drm_ioctl_desc vgem_ioctls[] = {
> > +   DRM_IOCTL_DEF_DRV(VGEM_FENCE_ATTACH, vgem_fence_attach_ioctl, 
> > DRM_AUTH|DRM_RENDER_ALLOW),
> > +   DRM_IOCTL_DEF_DRV(VGEM_FENCE_SIGNAL, vgem_fence_signal_ioctl, 
> > DRM_AUTH|DRM_RENDER_ALLOW),
> >  };
> >  
> >  static int vgem_mmap(struct file *filp, struct vm_area_struct *vma)
> > @@ -271,9 +301,12 @@ static int vgem_prime_mmap(struct drm_gem_object *obj,
> >  
> >  static struct drm_driver vgem_driver = {
> > .driver_features= DRIVER_GEM | DRIVER_PRIME,
> > +   .open   = vgem_open,
> > +   .preclose   = vgem_preclose,
> > .gem_free_object_unlocked   = vgem_gem_free_object,
> > .gem_vm_ops = _gem_vm_ops,
> > .ioctls = vgem_ioctls,
> > +   .num_ioctls = ARRAY_SIZE(vgem_ioctls),
> > .fops   = _driver_fops,
> >  
> > .dumb_create= vgem_gem_dumb_create,
> > @@ -328,5 +361,6 @@ module_init(vgem_init);
> >  module_exit(vgem_exit);
> >  
> >  MODULE_AUTHOR("Red Hat, Inc.");
> > +MODULE_AUTHOR("Intel Corporation");
> >  MODULE_DESCRIPTION(DRIVER_DESC);
> >  MODULE_LICENSE("GPL and additional rights");
> > diff --git a/drivers/gpu/drm/vgem/vgem_drv.h 
> > b/drivers/gpu/drm/vgem/vgem_drv.h
> > index 988cbaae7588..88ce21010e28 100644
> > --- a/drivers/gpu/drm/vgem/vgem_drv.h
> > +++ b/drivers/gpu/drm/vgem/vgem_drv.h
> > @@ -32,9 +32,27 @@
> >  #include 
> >  #include 
> >  
> > +#include 
> > +
> > +struct vgem_file {
> > +   struct idr fence_idr;
> > +   struct mutex fence_mutex;
> > +   u64 fence_context;
> > +   atomic_t fence_seqno;
> > +};
> > +
> >  #define to_vgem_bo(x) container_of(x, struct drm_vgem_gem_object, base)
> >  struct drm_vgem_gem_object {
> > struct drm_gem_object base;
> >  };
> >  
> > +int vgem_fence_open(struct vgem_file *file);
> > +int vgem_fence_attach_ioctl(struct drm_device *dev,
> > +   void *data,
> > +   struct drm_file *file);
> > +int vgem_fence_signal_ioctl(struct drm_device *dev,
> > +   

[PATCH] drm: Only handle _DRM_VBLANK_NEXTONMISS once

2016-07-11 Thread Michel Dänzer
On 24.06.2016 17:17, Chris Wilson wrote:
> On Fri, Jun 24, 2016 at 04:59:47PM +0900, Michel Dänzer wrote:
>> From: Michel Dänzer 
>>
>> Consolidate the _DRM_VBLANK_NEXTONMISS handling between drm_wait_vblank
>> and drm_queue_vblank_event.
>>
>> This is a cleanup spotted while working on other changes.
>>
>> (The way it was previously handled could also theoretically result in
>> drm_queue_vblank_event unnecessarily bumping vblwait->request.sequence,
>> if the vblank counter happened to increment between the
>> drm_vblank_count(_and_time) calls in each function, but that's unlikely)
>>
>> Signed-off-by: Michel Dänzer 
> Reviewed-by: Chris Wilson 

Thanks, Chris!


Daniel, can you pick this up?


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer


[PATCH v3 1/7] lib: string: add functions to case-convert strings

2016-07-11 Thread Markus Mayer
On 9 July 2016 at 08:30, Markus Mayer  wrote:
> On 9 July 2016 at 05:04, Luis de Bethencourt  
> wrote:
>> On 08/07/16 23:43, Markus Mayer wrote:
>>> Add a collection of generic functions to convert strings to lowercase
>>> or uppercase.
>>>
>>> Changing the case of a string (with or without copying it first) seems
>>> to be a recurring requirement in the kernel that is currently being
>>> solved by several duplicated implementations doing the same thing. This
>>> change aims at reducing this code duplication.
>>>
>>> The new functions are
>>> void strlcpytoupper(char *dst, const char *src, size_t len);
>>> void strlcpytolower(char *dst, const char *src, size_t len);
>>> void strcpytoupper(char *dst, const char *src);
>>> void strcpytolower(char *dst, const char *src);
>>> void strtoupper(char *s);
>>> void strtolower(char *s);
>>>
>>> The "str[l]cpyto*" versions of the function take a destination string
>>> and a source string as arguments. The "strlcpyto*" versions additionally
>>> take a length argument like strlcpy() itself. Lastly, the strto*
>>> functions take a single string argument and modify the passed-in string.
>>>
>>> Like strlcpy(), and unlike strncpy(), the functions guarantee NULL
>>> termination of the destination string.
>>>
>>> Signed-off-by: Markus Mayer 
>>> ---
>>>  include/linux/string.h | 40 
>>>  lib/string.c   | 38 ++
>>>  2 files changed, 78 insertions(+)
>>>
>>> diff --git a/include/linux/string.h b/include/linux/string.h
>>> index 26b6f6a..36c9d14 100644
>>> --- a/include/linux/string.h
>>> +++ b/include/linux/string.h
>>> @@ -116,6 +116,8 @@ extern void * memchr(const void *,int,__kernel_size_t);
>>>  #endif
>>>  void *memchr_inv(const void *s, int c, size_t n);
>>>  char *strreplace(char *s, char old, char new);
>>> +extern void strlcpytoupper(char *dst, const char *src, size_t len);
>>> +extern void strlcpytolower(char *dst, const char *src, size_t len);
>>>
>>>  extern void kfree_const(const void *x);
>>>
>>> @@ -169,4 +171,42 @@ static inline const char *kbasename(const char *path)
>>>   return tail ? tail + 1 : path;
>>>  }
>>>
>>> +/**
>>> + * strcpytoupper - Copy string and convert to uppercase.
>>> + * @dst: The buffer to store the result.
>>> + * @src: The string to convert to uppercase.
>>> + */
>>> +static inline void strcpytoupper(char *dst, const char *src)
>>> +{
>>> + strlcpytoupper(dst, src, -1);
>>> +}
>>> +
>>
>> Why not use SIZE_MAX instead of -1?
>
> Sure. I'll change all four of them. Thanks.

Turns out there's actually a circular dependency here. SIZE_MAX is
defined in linux/kernel.h. So, string.h would need to include
kernel.h. But kernel.h, by way of several other headers, includes
string.h.

Attempting to include kernel.h in string.h then leads to something like this:

  CHK include/config/kernel.release
  CHK include/generated/uapi/linux/version.h
  CHK include/generated/utsrelease.h
  CC  scripts/mod/devicetable-offsets.s
  CHK include/generated/timeconst.h
In file included from include/linux/printk.h:289:0,
 from include/linux/kernel.h:13,
 from include/linux/string.h:11,
 from include/uapi/linux/uuid.h:21,
 from include/linux/uuid.h:19,
 from include/linux/mod_devicetable.h:12,
 from scripts/mod/devicetable-offsets.c:2:
include/linux/dynamic_debug.h: In function ‘ddebug_dyndbg_module_param_cb’:
include/linux/dynamic_debug.h:122:2: error: implicit declaration of
function ‘strstr’ [-Werror=implicit-function-declaration]
  if (strstr(param, "dyndbg")) {
  ^
include/linux/dynamic_debug.h:122:6: warning: incompatible implicit
declaration of built-in function ‘strstr’ [enabled by default]
  if (strstr(param, "dyndbg")) {
  ^
Since kernel.h is referencing string.h (which is needed, but not
included a second time due to the include guards), this leads to
undeclared string functions, because we are still in the early stages
of including string.h itself and haven't gotten to the function
declarations yet.

>>> +/**
>>> + * strcpytolower - Copy string and convert to lowercase.
>>> + * @dst: The buffer to store the result.
>>> + * @src: The string to convert to lowercase.
>>> + */
>>> +static inline void strcpytolower(char *dst, const char *src)
>>> +{
>>> + strlcpytolower(dst, src, -1);
>>> +}
>>> +
>>
>> Same here, and the 2 below :)
>>
>> Thanks Markus,
>> Luis
>>
>>> +/**
>>> + * strtoupper - Convert string to uppercase.
>>> + * @s: The string to operate on.
>>> + */
>>> +static inline void strtoupper(char *s)
>>> +{
>>> + strlcpytoupper(s, s, -1);
>>> +}
>>> +
>>> +/**
>>> + * strtolower - Convert string to lowercase.
>>> + * @s: The string to operate on.
>>> + */
>>> +static inline void strtolower(char *s)
>>> +{
>>> + strlcpytolower(s, s, -1);
>>> +}
>>> +
>>>  #endif /* _LINUX_STRING_H_ */
>>> 

[PATCH v7 2/2] drm/panel: Add JDI LT070ME05000 WUXGA DSI Panel

2016-07-11 Thread Emil Velikov
On 11 July 2016 at 13:31, Vinay Simha  wrote:
> emil,
>
> As you had suggested to drop the spurious returns in
> jdi_panel_unprepare and drop the return itself.
> But as i had mentioned earlier , we cannot drop the return function
> and void for jdi_panel_unprepare , since the drm fun* requires int as
> return type (drm_panel_funcs .unprepare).
>
> please do re-point out if i had still missed anything.
>
Simple steps:
 - forget/ignore anything you know about the driver for a moment.
 - note: existing DRM interfaces cannot be changed.
 - teardown path(s) should _not_ return prematurely. be that within
the function itself or any of the functions that it uses.

Now put the above into practise:
 - jdi_panel_unprepare, should _not_ return if jdi_panel_off fails.
 - similarly, _everything_ in jdi_panel_off should be executed, hence
one can drop the return type all together.
 - bonus points for inlining the {2,4} line helpers
jdi_panel_{on,off}. don't bother with this if it makes things too
complex/confusing from your POV.

If the above is still ambiguous, just copy/pasta from panel-sharp-lq101r1sx01.c.

Regards,
Emil

P.S. Please avoid top-posting where possible.


[Bug 96868] AMDGPU Tonga only does 2560x1440 at 120hz, switching to 144hz causes display errors, same thing used to happen with fglrx.

2016-07-11 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=96868

--- Comment #5 from Alex Deucher  ---
I think the vblank period is too short at 144Hz for the mclk switching.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160711/ca152d4d/attachment.html>


[Bug 96868] AMDGPU Tonga only does 2560x1440 at 120hz, switching to 144hz causes display errors, same thing used to happen with fglrx.

2016-07-11 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=96868

--- Comment #4 from Alex Deucher  ---
Does forcing the clocks to high or low fix the issue? (as root):
echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level
or
echo low > /sys/class/drm/card0/device/power_dpm_force_performance_level

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160711/1c07da9e/attachment.html>


[PATCH] drm/panel: Remove the get_timings() function.

2016-07-11 Thread Thierry Reding
On Wed, Jun 01, 2016 at 12:18:01PM -0700, Eric Anholt wrote:
> It appears to have no callers.
> 
> Signed-off-by: Eric Anholt 
> ---
>  drivers/gpu/drm/panel/panel-simple.c | 18 --
>  include/drm/drm_panel.h  |  4 
>  2 files changed, 22 deletions(-)

Looks like I never replied to this, though I remember at least making up
the reply in my head.

The reason why I'd like to keep this is that it's technically the right
interface for display drivers to use. It was introduced in order to fix
some of the short-comings of ->get_modes(), though it seems like there
simply hasn't been a need so far for drivers to do this.

The problem with ->get_modes() is that it gives you a fixed mode for
most panels. However, a mode that works on one display controller does
not necessarily work on another (typical reasons could be extra limits
imposed on porches by the display controller).

Timings are supposed to solve this by allowing the video timings to be
specified in triplets of (minimum, maximum, typical) values for each of
the parameters (much like the tables you see in panel datasheets) and
make it possible for drivers to make up a valid mode from those ranges.
This makes the panel more widely useful.

At least that's the theory, but, like I said, in practice nobody seems
to be needing this currently.

Bottom line, I think we'll be needing this down the road eventually, so
keeping it around will avoid unnecessary churn.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160711/41baeca4/attachment.sig>


[PATCH v5 2/2] drm/panel: Add JDI LT070ME05000 WUXGA DSI Panel

2016-07-11 Thread Thierry Reding
On Thu, Jun 16, 2016 at 06:02:53PM +0100, Emil Velikov wrote:
> On 16 June 2016 at 04:00, Vinay Simha BN  wrote:
[...]
> > +static int jdi_panel_disable(struct drm_panel *panel)
> > +{
> > +   struct jdi_panel *jdi = to_jdi_panel(panel);
> > +
> > +   if (!jdi->enabled)
> > +   return 0;
> > +
> Thinking out loud:
> 
> Thierry,
> Shouldn't we fold 'enabled' and 'prepared' in struct drm_panel and
> tweak the helpers respectively ? Is there any specific reason for
> keeping these in the drivers ?

Yes, I think that would make sense eventually. It's clearly a recurring
pattern. Ideally nothing would be calling these functions more than once
and thereby making the checks unnecessary. In practice that may mean
that we need to put the variables and checks into the drm/panel core
because display drivers (as opposed to a sane core implementation) call
these. I suppose we could encourage proper usage by adding a couple of
WARNs here and there if expectations aren't met.

I don't think doing this is terribly urgent because it's easy to rip out
of drivers once the drm/panel core supports it. And it's something that
we could even leave within drivers when the core supports it, so trivial
to remove one by one after the core patches have landed.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160711/3247f239/attachment.sig>


[PATCH v7 2/2] drm/panel: Add JDI LT070ME05000 WUXGA DSI Panel

2016-07-11 Thread Thierry Reding
On Sun, Jul 03, 2016 at 11:52:11PM +0100, Emil Velikov wrote:
> On 28 June 2016 at 16:59, Vinay Simha  wrote:
> > hi,
> >
> > Any further comments or reviews?
> >
> You still haven't covered my earlier suggestions, as such I cannot
> give you a r-b :-( They are not blockers by any means, but it'll be
> up-to the maintainer to ack/pick this up.
> 
> Thierry ?

Vinay, please address Emil's comments and resend. I also see that you
stopped sending the device tree bindings patch at some point. Please do
include that when you repost as I don't seem to be able to find a recent
version anywhere.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160711/cfbc15c2/attachment.sig>


[PATCH 2/2] drm/bridge: tc358767: Add DPI to eDP bridge driver

2016-07-11 Thread Archit Taneja


On 07/11/2016 02:14 PM, Philipp Zabel wrote:
> Am Montag, den 11.07.2016, 14:02 +0530 schrieb Archit Taneja:
> [...]
> + /* PXL PLL setup */
> + if (tc->test_pattern) {

 I couldn't find out who is setting tc->test_pattern. Is it always
 0?
>>>
>>> Hm, you are right. I wonder what a good mechanism would be to enable a
>>> test pattern for a bridge driver. Module parameters? We don't have
>>> anyhting like V4L2_CID_TEST_PATTERN in drm. I could also drop test
>>> pattern support from the initial patch and submit it separately.
>>
>> Module parameter sounds like a good option.
>
> Ok.
>
>> Although, it seems like the pll is enabled only when test_pattern is
>> set. How does the bridge work if the pll isn't enabled?
>
> The PXL PLL is only necessary regenerate the pixel clock from the DSI HS
> clock, or to create the test pattern. In DPI mode the pixel clock from
> the parallel interface is used directly.

Okay. Thanks for the clarification.

Archit

>
> regards
> Philipp
>

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


[Bug 96885] AMDGPU Power management failure on 290X

2016-07-11 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=96885

Alex Deucher  changed:

   What|Removed |Added

 Attachment #124990|0   |1
   is patch||
 Attachment #124990|text/x-log  |text/plain
  mime type||

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160711/18ce74cb/attachment.html>


[PATCH 3/3] drm/vgem: Attach sw fences to exported vGEM dma-buf (ioctl)

2016-07-11 Thread Chris Wilson
vGEM buffers are useful for passing data between software clients and
hardware renders. By allowing the user to create and attach fences to
the exported vGEM buffers (on the dma-buf), the user can implement a
deferred renderer and queue hardware operations like flipping and then
signal the buffer readiness (i.e. this allows the user to schedule
operations out-of-order, but have them complete in-order).

This also makes it much easier to write tightly controlled testcases for
dma-buf fencing and signaling between hardware drivers.

Testcase: igt/vgem_basic/dmabuf-fence
Signed-off-by: Chris Wilson 
Cc: Sean Paul 
Cc: Zach Reizner 
Cc: Gustavo Padovan 
Acked-by: Zach Reizner 
---
 drivers/gpu/drm/vgem/Makefile |   2 +-
 drivers/gpu/drm/vgem/vgem_drv.c   |  34 ++
 drivers/gpu/drm/vgem/vgem_drv.h   |  18 
 drivers/gpu/drm/vgem/vgem_fence.c | 220 ++
 include/uapi/drm/vgem_drm.h   |  62 +++
 5 files changed, 335 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/vgem/vgem_fence.c
 create mode 100644 include/uapi/drm/vgem_drm.h

diff --git a/drivers/gpu/drm/vgem/Makefile b/drivers/gpu/drm/vgem/Makefile
index 3f4c7b842028..bfcdea1330e6 100644
--- a/drivers/gpu/drm/vgem/Makefile
+++ b/drivers/gpu/drm/vgem/Makefile
@@ -1,4 +1,4 @@
 ccflags-y := -Iinclude/drm
-vgem-y := vgem_drv.o
+vgem-y := vgem_drv.o vgem_fence.o

 obj-$(CONFIG_DRM_VGEM) += vgem.o
diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index b5fb968d2d5c..2659e5cda857 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -83,6 +83,34 @@ static const struct vm_operations_struct vgem_gem_vm_ops = {
.close = drm_gem_vm_close,
 };

+static int vgem_open(struct drm_device *dev, struct drm_file *file)
+{
+   struct vgem_file *vfile;
+   int ret;
+
+   vfile = kzalloc(sizeof(*vfile), GFP_KERNEL);
+   if (!vfile)
+   return -ENOMEM;
+
+   file->driver_priv = vfile;
+
+   ret = vgem_fence_open(vfile);
+   if (ret) {
+   kfree(vfile);
+   return ret;
+   }
+
+   return 0;
+}
+
+static void vgem_preclose(struct drm_device *dev, struct drm_file *file)
+{
+   struct vgem_file *vfile = file->driver_priv;
+
+   vgem_fence_close(vfile);
+   kfree(vfile);
+}
+
 /* ioctls */

 static struct drm_gem_object *vgem_gem_create(struct drm_device *dev,
@@ -164,6 +192,8 @@ unref:
 }

 static struct drm_ioctl_desc vgem_ioctls[] = {
+   DRM_IOCTL_DEF_DRV(VGEM_FENCE_ATTACH, vgem_fence_attach_ioctl, 
DRM_AUTH|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(VGEM_FENCE_SIGNAL, vgem_fence_signal_ioctl, 
DRM_AUTH|DRM_RENDER_ALLOW),
 };

 static int vgem_mmap(struct file *filp, struct vm_area_struct *vma)
@@ -271,9 +301,12 @@ static int vgem_prime_mmap(struct drm_gem_object *obj,

 static struct drm_driver vgem_driver = {
.driver_features= DRIVER_GEM | DRIVER_PRIME,
+   .open   = vgem_open,
+   .preclose   = vgem_preclose,
.gem_free_object_unlocked   = vgem_gem_free_object,
.gem_vm_ops = _gem_vm_ops,
.ioctls = vgem_ioctls,
+   .num_ioctls = ARRAY_SIZE(vgem_ioctls),
.fops   = _driver_fops,

.dumb_create= vgem_gem_dumb_create,
@@ -328,5 +361,6 @@ module_init(vgem_init);
 module_exit(vgem_exit);

 MODULE_AUTHOR("Red Hat, Inc.");
+MODULE_AUTHOR("Intel Corporation");
 MODULE_DESCRIPTION(DRIVER_DESC);
 MODULE_LICENSE("GPL and additional rights");
diff --git a/drivers/gpu/drm/vgem/vgem_drv.h b/drivers/gpu/drm/vgem/vgem_drv.h
index 988cbaae7588..88ce21010e28 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.h
+++ b/drivers/gpu/drm/vgem/vgem_drv.h
@@ -32,9 +32,27 @@
 #include 
 #include 

+#include 
+
+struct vgem_file {
+   struct idr fence_idr;
+   struct mutex fence_mutex;
+   u64 fence_context;
+   atomic_t fence_seqno;
+};
+
 #define to_vgem_bo(x) container_of(x, struct drm_vgem_gem_object, base)
 struct drm_vgem_gem_object {
struct drm_gem_object base;
 };

+int vgem_fence_open(struct vgem_file *file);
+int vgem_fence_attach_ioctl(struct drm_device *dev,
+   void *data,
+   struct drm_file *file);
+int vgem_fence_signal_ioctl(struct drm_device *dev,
+   void *data,
+   struct drm_file *file);
+void vgem_fence_close(struct vgem_file *file);
+
 #endif
diff --git a/drivers/gpu/drm/vgem/vgem_fence.c 
b/drivers/gpu/drm/vgem/vgem_fence.c
new file mode 100644
index ..649e9e1cee35
--- /dev/null
+++ b/drivers/gpu/drm/vgem/vgem_fence.c
@@ -0,0 +1,220 @@
+/*
+ * Copyright 2016 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation 

[PATCH 2/3] drm/vgem: Enable dmabuf interface for export

2016-07-11 Thread Chris Wilson
Enable the standard GEM dma-buf interface provided by the DRM core, but
only for exporting the VGEM object. This allows passing around the VGEM
objects created from the dumb interface and using them as sources
elsewhere. Creating a VGEM object for a foriegn handle is not supported.

v2: With additional completeness.
v3: Need to clear the CPU cache upon exporting the dma-addresses.
v4: Use drm_gem_put_pages() as well.
v5: Use drm_prime_pages_to_sg()

Testcase: igt/vgem_basic/dmabuf-*
Testcase: igt/prime_vgem
Signed-off-by: Chris Wilson 
Cc: Sean Paul 
Cc: Zach Reizner 
Acked-by: Zach Reizner 
Reviewed-by: Matthew Auld 
---
 drivers/gpu/drm/vgem/vgem_drv.c | 89 -
 1 file changed, 88 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index c161b6d7e427..b5fb968d2d5c 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -192,14 +192,101 @@ static const struct file_operations vgem_driver_fops = {
.release= drm_release,
 };

+static int vgem_prime_pin(struct drm_gem_object *obj)
+{
+   long n_pages = obj->size >> PAGE_SHIFT;
+   struct page **pages;
+
+   /* Flush the object from the CPU cache so that importers can rely
+* on coherent indirect access via the exported dma-address.
+*/
+   pages = drm_gem_get_pages(obj);
+   if (IS_ERR(pages))
+   return PTR_ERR(pages);
+
+   drm_clflush_pages(pages, n_pages);
+   drm_gem_put_pages(obj, pages, true, false);
+
+   return 0;
+}
+
+static struct sg_table *vgem_prime_get_sg_table(struct drm_gem_object *obj)
+{
+   struct sg_table *st;
+   struct page **pages;
+
+   pages = drm_gem_get_pages(obj);
+   if (IS_ERR(pages))
+   return ERR_CAST(pages);
+
+   st = drm_prime_pages_to_sg(pages, obj->size >> PAGE_SHIFT);
+   drm_gem_put_pages(obj, pages, false, false);
+
+   return st;
+}
+
+static void *vgem_prime_vmap(struct drm_gem_object *obj)
+{
+   long n_pages = obj->size >> PAGE_SHIFT;
+   struct page **pages;
+   void *addr;
+
+   pages = drm_gem_get_pages(obj);
+   if (IS_ERR(pages))
+   return NULL;
+
+   addr = vmap(pages, n_pages, 0, pgprot_writecombine(PAGE_KERNEL_IO));
+   drm_gem_put_pages(obj, pages, false, false);
+
+   return addr;
+}
+
+static void vgem_prime_vunmap(struct drm_gem_object *obj, void *vaddr)
+{
+   vunmap(vaddr);
+}
+
+static int vgem_prime_mmap(struct drm_gem_object *obj,
+  struct vm_area_struct *vma)
+{
+   int ret;
+
+   if (obj->size < vma->vm_end - vma->vm_start)
+   return -EINVAL;
+
+   if (!obj->filp)
+   return -ENODEV;
+
+   ret = obj->filp->f_op->mmap(obj->filp, vma);
+   if (ret)
+   return ret;
+
+   fput(vma->vm_file);
+   vma->vm_file = get_file(obj->filp);
+   vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP;
+   vma->vm_page_prot = 
pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
+
+   return 0;
+}
+
 static struct drm_driver vgem_driver = {
-   .driver_features= DRIVER_GEM,
+   .driver_features= DRIVER_GEM | DRIVER_PRIME,
.gem_free_object_unlocked   = vgem_gem_free_object,
.gem_vm_ops = _gem_vm_ops,
.ioctls = vgem_ioctls,
.fops   = _driver_fops,
+
.dumb_create= vgem_gem_dumb_create,
.dumb_map_offset= vgem_gem_dumb_map,
+
+   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
+   .gem_prime_pin = vgem_prime_pin,
+   .gem_prime_export = drm_gem_prime_export,
+   .gem_prime_get_sg_table = vgem_prime_get_sg_table,
+   .gem_prime_vmap = vgem_prime_vmap,
+   .gem_prime_vunmap = vgem_prime_vunmap,
+   .gem_prime_mmap = vgem_prime_mmap,
+
.name   = DRIVER_NAME,
.desc   = DRIVER_DESC,
.date   = DRIVER_DATE,
-- 
2.8.1



[PATCH 1/3] drm/vgem: Fix mmaping

2016-07-11 Thread Chris Wilson
The vGEM mmap code has bitrotted slightly and now immediately BUGs.
Since vGEM was last updated, there are new core GEM facilities to
provide more common functions, so let's use those here.

v2: drm_gem_free_mmap_offset() is performed from
drm_gem_object_release() so we can remove the redundant call.

Testcase: igt/vgem_basic/mmap
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96603
Signed-off-by: Chris Wilson 
Cc: Sean Paul 
Cc: Zach Reizner 
Cc: Matthew Auld 
Tested-by: Humberto Israel Perez Rodriguez 
Reviewed-by: Matthew Auld 
Acked-by: Zach Reizner 
---
 drivers/gpu/drm/vgem/vgem_drv.c | 164 +++-
 drivers/gpu/drm/vgem/vgem_drv.h |   6 --
 2 files changed, 61 insertions(+), 109 deletions(-)

diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index 35ea5d02a827..c161b6d7e427 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -42,81 +42,38 @@
 #define DRIVER_MAJOR   1
 #define DRIVER_MINOR   0

-void vgem_gem_put_pages(struct drm_vgem_gem_object *obj)
-{
-   drm_gem_put_pages(>base, obj->pages, false, false);
-   obj->pages = NULL;
-}
-
 static void vgem_gem_free_object(struct drm_gem_object *obj)
 {
struct drm_vgem_gem_object *vgem_obj = to_vgem_bo(obj);

-   drm_gem_free_mmap_offset(obj);
-
-   if (vgem_obj->use_dma_buf && obj->dma_buf) {
-   dma_buf_put(obj->dma_buf);
-   obj->dma_buf = NULL;
-   }
-
drm_gem_object_release(obj);
-
-   if (vgem_obj->pages)
-   vgem_gem_put_pages(vgem_obj);
-
-   vgem_obj->pages = NULL;
-
kfree(vgem_obj);
 }

-int vgem_gem_get_pages(struct drm_vgem_gem_object *obj)
-{
-   struct page **pages;
-
-   if (obj->pages || obj->use_dma_buf)
-   return 0;
-
-   pages = drm_gem_get_pages(>base);
-   if (IS_ERR(pages)) {
-   return PTR_ERR(pages);
-   }
-
-   obj->pages = pages;
-
-   return 0;
-}
-
 static int vgem_gem_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
 {
struct drm_vgem_gem_object *obj = vma->vm_private_data;
-   loff_t num_pages;
-   pgoff_t page_offset;
-   int ret;
-
/* We don't use vmf->pgoff since that has the fake offset */
-   page_offset = ((unsigned long)vmf->virtual_address - vma->vm_start) >>
-   PAGE_SHIFT;
-
-   num_pages = DIV_ROUND_UP(obj->base.size, PAGE_SIZE);
-
-   if (page_offset > num_pages)
-   return VM_FAULT_SIGBUS;
-
-   ret = vm_insert_page(vma, (unsigned long)vmf->virtual_address,
-obj->pages[page_offset]);
-   switch (ret) {
-   case 0:
-   return VM_FAULT_NOPAGE;
-   case -ENOMEM:
-   return VM_FAULT_OOM;
-   case -EBUSY:
-   return VM_FAULT_RETRY;
-   case -EFAULT:
-   case -EINVAL:
-   return VM_FAULT_SIGBUS;
-   default:
-   WARN_ON(1);
-   return VM_FAULT_SIGBUS;
+   unsigned long vaddr = (unsigned long)vmf->virtual_address;
+   struct page *page;
+
+   page = shmem_read_mapping_page(file_inode(obj->base.filp)->i_mapping,
+  (vaddr - vma->vm_start) >> PAGE_SHIFT);
+   if (!IS_ERR(page)) {
+   vmf->page = page;
+   return 0;
+   } else switch (PTR_ERR(page)) {
+   case -ENOSPC:
+   case -ENOMEM:
+   return VM_FAULT_OOM;
+   case -EBUSY:
+   return VM_FAULT_RETRY;
+   case -EFAULT:
+   case -EINVAL:
+   return VM_FAULT_SIGBUS;
+   default:
+   WARN_ON_ONCE(PTR_ERR(page));
+   return VM_FAULT_SIGBUS;
}
 }

@@ -134,57 +91,43 @@ static struct drm_gem_object *vgem_gem_create(struct 
drm_device *dev,
  unsigned long size)
 {
struct drm_vgem_gem_object *obj;
-   struct drm_gem_object *gem_object;
-   int err;
-
-   size = roundup(size, PAGE_SIZE);
+   int ret;

obj = kzalloc(sizeof(*obj), GFP_KERNEL);
if (!obj)
return ERR_PTR(-ENOMEM);

-   gem_object = >base;
-
-   err = drm_gem_object_init(dev, gem_object, size);
-   if (err)
-   goto out;
-
-   err = vgem_gem_get_pages(obj);
-   if (err)
-   goto out;
-
-   err = drm_gem_handle_create(file, gem_object, handle);
-   if (err)
-   goto handle_out;
+   ret = drm_gem_object_init(dev, >base, roundup(size, PAGE_SIZE));
+   if (ret)
+   goto err_free;

-   drm_gem_object_unreference_unlocked(gem_object);
+   ret = drm_gem_handle_create(file, >base, handle);
+   drm_gem_object_unreference_unlocked(>base);
+   if (ret)
+   goto err;

-   return gem_object;
+   return >base;


drm/vgem fixes and new ioctl for testing prime

2016-07-11 Thread Chris Wilson
Just a quick resend of the existing vgem patches, all 3 have been acked,
but only the first 2 have reviews. The third involves both new ioctl and
dma-buf/fences, so perhaps people have been reluctant... But now is a
good time! These patches are exercised by intel-gpu-tools (or will be once
the new ioctls are ratified).
-Chris



[PATCH v2 1/2] dt-bindings: add Starry KR122EA0SRA panel binding

2016-07-11 Thread Thierry Reding
On Fri, Jun 10, 2016 at 10:02:06AM -0700, Douglas Anderson wrote:
> The Starry KR122EA0SRA is a 12.2", 1920x1200 TFT-LCD panel connected
> using eDP interfaces.
> 
> Signed-off-by: Douglas Anderson 
> ---
> Changes in v2:
> - Proper title (sorry!)
> 
>  .../devicetree/bindings/display/panel/starry,kr122ea0sra.txt   | 7 
> +++
>  1 file changed, 7 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/starry,kr122ea0sra.txt

Applied both patches.

Thanks,
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160711/b5a5639f/attachment.sig>


[REPOST v3 1/2] drm/panel: simple: Add support for Sharp LQ101K1LY04

2016-07-11 Thread Thierry Reding
On Wed, Jul 06, 2016 at 03:59:16PM -0700, Joshua Clayton wrote:
> Add simple-panel support for the  Sharp LQ101K1LY04i, which  is
> a 10 inch WXGA (1280x800) lvds panel.
> 
> Signed-off-by: Joshua Clayton 
> ---
>  Reposting again in hopes of getting this into 4.8
> 
>  drivers/gpu/drm/panel/panel-simple.c | 27 +++
>  1 file changed, 27 insertions(+)

Applied both patches, thanks.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160711/6bb6c150/attachment.sig>


[PATCH 2/2] drm/bridge: tc358767: Add DPI to eDP bridge driver

2016-07-11 Thread Archit Taneja


On 07/05/2016 01:30 PM, Philipp Zabel wrote:
> Hi Archit,
>
> thanks for the review!
>
> Am Dienstag, den 05.07.2016, 10:08 +0530 schrieb Archit Taneja:
> [...]
>>> +#include 
>>
>> This may not be needed.
>
> I'll check and remove it.
>
>>> +#ifndef regmap_read_poll_timeout
>>> +#define regmap_read_poll_timeout(map, addr, val, cond, sleep_us, 
>>> timeout_us) \
>>> +({ \
>>> +   ktime_t timeout = ktime_add_us(ktime_get(), timeout_us); \
>>> +   int ret; \
>>> +   might_sleep_if(sleep_us); \
>>> +   for (;;) { \
>>> +   ret = regmap_read((map), (addr), &(val)); \
>>> +   if (ret) \
>>> +   break; \
>>> +   if (cond) \
>>> +   break; \
>>> +   if (timeout_us && ktime_compare(ktime_get(), timeout) > 0) { \
>>> +   ret = regmap_read((map), (addr), &(val)); \
>>> +   break; \
>>> +   } \
>>> +   if (sleep_us) \
>>> +   usleep_range((sleep_us >> 2) + 1, sleep_us); \
>>> +   } \
>>> +   ret ?: ((cond) ? 0 : -ETIMEDOUT); \
>>> +})
>>> +#endif
>>
>> Is there a reason why this is wrapped around a #ifndef? I don't see it
>> in the current regmap.h headers. It would also be nice if it were made
>> into a function.
>
> This is a macro similar to those defined in iopoll.h. It can't be a
> function because the "cond"ition is specified by the caller and has to
> be evaluated in the loop.
> I'll submit this for regmap. If it doesn't get accepted I'll change this
> into two properly named functions.
>
> [...]
>>> +static int tc_pxl_pll_en(struct tc_data *tc, u32 refclk)
>>> +{
>>> +   int ret;
>>> +   int i_pre, best_pre = 1;
>>> +   int i_post, best_post = 1;
>>> +   int div, best_div = 1;
>>> +   int mul, best_mul = 1;
>>> +   int delta, best_delta;
>>> +   int ext_div[] = {1, 2, 3, 5, 7};
>>> +   int best_pixelclock = 0;
>>> +   int vco_hi = 0;
>>> +   int pixelclock;
>>> +
>>> +   pixelclock = tc->pll_clk;
>>> +
>>> +   dev_dbg(tc->dev, "PLL: requested %d pixelclock, ref %d\n", pixelclock,
>>> +   refclk);
>>> +   best_delta = pixelclock;
>>> +   /* big loops */
>>
>> The above comment could be improved.
>
> Will do.
>
>>> +   for (i_pre = 0; i_pre < ARRAY_SIZE(ext_div); i_pre++) {
>>> +   /* refclk / ext_pre_div should be in the 1 to 200 MHz range */
>>> +   if ((refclk / ext_div[i_pre] > 2) ||
>>
>> The > 200 Mhz check seems redundant, since no refclk beyond 38.4 Mhz is
>> supported.
>
> Indeed. I'll drop the check and update the comment.
>
>>> +   (refclk / ext_div[i_pre] < 100))
>>> +   continue;
>>> +   for (i_post = 0; i_post < ARRAY_SIZE(ext_div); i_post++) {
>>> +   for (div = 1; div <= 16; div++) {
>>> +   u32 clk;
>>> +   u64 tmp;
>>> +
>>> +   tmp = pixelclock * ext_div[i_pre] *
>>> + ext_div[i_post] * div;
>>> +   do_div(tmp, refclk);
>>> +   mul = tmp;
>>> +
>>> +   clk = refclk / ext_div[i_pre] / div * mul /
>>> + ext_div[i_post];
>>
>> Some braces for the above expression might help :)
>
> Ok.
>
>>> +   delta = clk - pixelclock;
>>> +
>>> +   /* check limits */
>>> +   if ((mul < 1) ||
>>> +   (mul > 128))
>>
>> minor comment: the above check could be in a single line.
>
> Oversight, will fix.
>
> [...]
>>> +static int tc_aux_link_setup(struct tc_data *tc)
>>> +{
>>> +   unsigned long rate;
>>> +   u32 value;
>>> +   int ret;
>>> +
>>> +   rate = clk_get_rate(tc->refclk);
>>
>> Ah, you can discard my comment on the clock binding in the DT patch.
>> I guess you needed it to figure out the rate.
>
> Alright, going back to the other mail and updating my answer.
>
>>> +   switch (rate) {
>>> +   case 3840:
>>> +   value = REF_FREQ_38M4;
>>> +   break;
>>> +   case 2600:
>>> +   value = REF_FREQ_26M;
>>> +   break;
>>> +   case 1920:
>>> +   value = REF_FREQ_19M2;
>>> +   break;
>>> +   case 1300:
>>> +   value = REF_FREQ_13M;
>>> +   break;
>>> +   default:
>>> +   dev_err(tc->dev, "Invalid refclk rate: %lu Hz\n", rate);
>>> +   return -EINVAL;
>>> +   }
>>> +
>>> +   /* Setup DP-PHY / PLL */
>>> +   value |= SYSCLK_SEL_LSCLK | LSCLK_DIV_2;
>>> +   tc_write(SYS_PLLPARAM, value);
>>> +
>>> +   tc_write(DP_PHY_CTRL, BGREN | PWR_SW_EN | BIT(2) | PHY_A0_EN);
>>
>> It seems a bit strange to have BIT(2) besides the other predefined
>> macros.
>
> I accidentally lost the comment when shortening this, BIT(2) is reserved
> but set.
>
> [...]
>>> +   /* PXL PLL setup */
>>> +   if (tc->test_pattern) {
>>
>> I couldn't find out who is setting tc->test_pattern. Is it always
>> 0?
>
> Hm, you are right. I 

[PATCH v1 4/6] drm/rockchip: dw_hdmi: add RK3399 HDMI support

2016-07-11 Thread Philipp Zabel
Am Montag, den 11.07.2016, 19:05 +0800 schrieb Yakir Yang:
> RK3399 and RK3288 shared the same HDMI IP controller, only some light
> difference with GRF configure.
> 
> Signed-off-by: Yakir Yang 

Reviewed-by: Philipp Zabel 

regards
Philipp



[PATCH][libdrm] drm: Fix multi GPU drmGetDevice return wrong device

2016-07-11 Thread Qiang Yu
drmGetDevice will always return the first device it find
under /dev/dri/. This is not true for multi GPU situation.

Plus fix the memory leak in error handling path of
drmGetDevices.

Change-Id: I2a85a8a4feba8a5cc517ad75c6afb532fa07c53d
Signed-off-by: Qiang Yu 
---
 xf86drm.c | 26 +-
 1 file changed, 21 insertions(+), 5 deletions(-)

diff --git a/xf86drm.c b/xf86drm.c
index 6689f7c..e90e8e5 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -3064,6 +3064,17 @@ static void drmFoldDuplicatedDevices(drmDevicePtr 
local_devices[], int count)
 }
 }
 }
+
+// move all devices to the beginning of local_devices continuously
+for (i = 0, j = 0; i < count; i++) {
+if (local_devices[i]) {
+if (i != j) {
+local_devices[j] = local_devices[i];
+local_devices[i] = NULL;
+}
+j++;
+}
+}
 }

 /**
@@ -3087,6 +3098,7 @@ int drmGetDevice(int fd, drmDevicePtr *device)
 int maj, min;
 int ret, i, node_count;
 int max_count = 16;
+dev_t find_rdev;

 if (fd == -1 || device == NULL)
 return -EINVAL;
@@ -3094,6 +3106,7 @@ int drmGetDevice(int fd, drmDevicePtr *device)
 if (fstat(fd, ))
 return -errno;

+find_rdev = sbuf.st_rdev;
 maj = major(sbuf.st_rdev);
 min = minor(sbuf.st_rdev);

@@ -3154,7 +3167,13 @@ int drmGetDevice(int fd, drmDevicePtr *device)
 local_devices = temp;
 }

-local_devices[i] = d;
+/* move target to the first of local_devices */
+if (find_rdev == sbuf.st_rdev && i) {
+local_devices[i] = local_devices[0];
+local_devices[0] = d;
+}
+else
+local_devices[i] = d;
 i++;
 }
 node_count = i;
@@ -3267,10 +3286,7 @@ int drmGetDevices(drmDevicePtr devices[], int 
max_devices)
 drmFoldDuplicatedDevices(local_devices, node_count);

 device_count = 0;
-for (i = 0; i < node_count; i++) {
-if (!local_devices[i])
-continue;
-
+for (i = 0; i < node_count && local_devices[i]; i++) {
 if ((devices != NULL) && (device_count < max_devices))
 devices[device_count] = local_devices[i];
 else
-- 
1.9.1



[Bug 96877] Bioshock Infinite: LLVM triggered Diagnostic Handler: Illegal instruction detected: Operand has incorrect register class.

2016-07-11 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=96877

--- Comment #4 from Nicolai Hähnle  ---
Another update: there are two separate problems in LLVM which "cooperate" to
lead to this bug. http://reviews.llvm.org/D22210 and
http://reviews.llvm.org/D22217 fix both problems (and either is sufficient for
this bug here).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160711/8deaacab/attachment.html>


[PATCH 1/3] drm/imx: check the value returned by regulator_set_voltage()

2016-07-11 Thread Philipp Zabel
Am Samstag, den 09.07.2016, 18:57 -0300 schrieb Fabio Estevam:
> From: Fabio Estevam 
> 
> regulator_set_voltage() may fail, so we better check its return value
> and propagate it in the case of error.
> 
> Signed-off-by: Fabio Estevam 

Applied all three, thank you.

regards
Philipp



[PATCH 2/5] drm/imx: imx-ldb: check return code on panel attach

2016-07-11 Thread Philipp Zabel
Am Freitag, den 17.06.2016, 12:13 +0200 schrieb Lucas Stach:
> Check the return code on panel attach. Avoids a kernel crash later
> on if the attach failed.
> 
> Signed-off-by: Lucas Stach 
> ---
>  drivers/gpu/drm/imx/imx-ldb.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c
> index beff793bb717..48166df14042 100644
> --- a/drivers/gpu/drm/imx/imx-ldb.c
> +++ b/drivers/gpu/drm/imx/imx-ldb.c
> @@ -427,8 +427,12 @@ static int imx_ldb_register(struct drm_device *drm,
>   drm_connector_init(drm, _ldb_ch->connector,
>  _ldb_connector_funcs, DRM_MODE_CONNECTOR_LVDS);
>  
> - if (imx_ldb_ch->panel)
> - drm_panel_attach(imx_ldb_ch->panel, _ldb_ch->connector);
> + if (imx_ldb_ch->panel) {
> + ret = drm_panel_attach(imx_ldb_ch->panel,
> +_ldb_ch->connector);
> + if (ret)
> + return ret;
> + }
>  
>   drm_mode_connector_attach_encoder(_ldb_ch->connector,
>   _ldb_ch->encoder);

Applied, thanks.

regards
Philipp



[PATCH] gpu: ipu-v3: ipu-dc: don't bug out on invalid bus_format

2016-07-11 Thread Philipp Zabel
If imx-drm is combined with a bridge or panel that requests an
unsupported format, warn and use a default mapping instead of
hanging the machine. The worst that can happen here are wrong
colors.

Signed-off-by: Philipp Zabel 
---
 drivers/gpu/ipu-v3/ipu-dc.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-dc.c b/drivers/gpu/ipu-v3/ipu-dc.c
index cd72dad..659475c 100644
--- a/drivers/gpu/ipu-v3/ipu-dc.c
+++ b/drivers/gpu/ipu-v3/ipu-dc.c
@@ -150,6 +150,9 @@ static void dc_write_tmpl(struct ipu_dc *dc, int word, u32 
opcode, u32 operand,
 static int ipu_bus_format_to_map(u32 fmt)
 {
switch (fmt) {
+   default:
+   WARN_ON(1);
+   /* fall-through */
case MEDIA_BUS_FMT_RGB888_1X24:
return IPU_DC_MAP_RGB24;
case MEDIA_BUS_FMT_RGB565_1X16:
@@ -162,8 +165,6 @@ static int ipu_bus_format_to_map(u32 fmt)
return IPU_DC_MAP_LVDS666;
case MEDIA_BUS_FMT_BGR888_1X24:
return IPU_DC_MAP_BGR24;
-   default:
-   return -EINVAL;
}
 }

@@ -178,7 +179,6 @@ int ipu_dc_init_sync(struct ipu_dc *dc, struct ipu_di *di, 
bool interlaced,
dc->di = ipu_di_get_num(di);

map = ipu_bus_format_to_map(bus_format);
-   BUG_ON(map < 0);

/*
 * In interlaced mode we need more counters to create the asymmetric
-- 
2.8.1



[PATCH] drm/atmel-hlcdc: Make ->reset() implementation static

2016-07-11 Thread Thierry Reding
From: Thierry Reding 

The atmel_hlcdc_crtc_reset() function is never used outside the file and
can be static. This avoids a warning from sparse.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index 613f6c99b76a..71471aec46a3 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -387,7 +387,7 @@ void atmel_hlcdc_crtc_irq(struct drm_crtc *c)
atmel_hlcdc_crtc_finish_page_flip(drm_crtc_to_atmel_hlcdc_crtc(c));
 }

-void atmel_hlcdc_crtc_reset(struct drm_crtc *crtc)
+static void atmel_hlcdc_crtc_reset(struct drm_crtc *crtc)
 {
struct atmel_hlcdc_crtc_state *state;

-- 
2.8.3



[RESEND PATCH] drm/exynos: Use VIDEO_SAMSUNG_EXYNOS_GSC=n as GSC Kconfig dependency

2016-07-11 Thread Javier Martinez Canillas
Commit aeefb36832e5 ("drm/exynos: gsc: add device tree support and remove
usage of static mappings") made the DRM_EXYNOS_GSC Kconfig symbol to only
be selectable if the exynos-gsc V4L2 driver isn't enabled, since both use
the same HW IP block.

But added the dependency as depends on !VIDEO_SAMSUNG_EXYNOS_GSC which is
not correct since Kconfig expressions are not boolean but tristate. So it
will only evaluate to 'n' if VIDEO_SAMSUNG_EXYNOS_GSC=y but will evaluate
to 'm' if VIDEO_SAMSUNG_S5P_G2D=m.

This means that both the V4L2 and DRM drivers can be enabled if the former
is enabled as a module, which is not what we want.

Signed-off-by: Javier Martinez Canillas 

---

 drivers/gpu/drm/exynos/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index d814b3048ee5..ec2dcc5e4962 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -119,7 +119,7 @@ config DRM_EXYNOS_ROTATOR

 config DRM_EXYNOS_GSC
bool "GScaler"
-   depends on DRM_EXYNOS_IPP && ARCH_EXYNOS5 && !VIDEO_SAMSUNG_EXYNOS_GSC
+   depends on DRM_EXYNOS_IPP && ARCH_EXYNOS5 && VIDEO_SAMSUNG_EXYNOS_GSC=n
help
  Choose this option if you want to use Exynos GSC for DRM.

-- 
2.5.5



[PATCH 3/3] drm/vgem: Attach sw fences to exported vGEM dma-buf (ioctl)

2016-07-11 Thread Gustavo Padovan
2016-07-11 Chris Wilson :

> vGEM buffers are useful for passing data between software clients and
> hardware renders. By allowing the user to create and attach fences to
> the exported vGEM buffers (on the dma-buf), the user can implement a
> deferred renderer and queue hardware operations like flipping and then
> signal the buffer readiness (i.e. this allows the user to schedule
> operations out-of-order, but have them complete in-order).
> 
> This also makes it much easier to write tightly controlled testcases for
> dma-buf fencing and signaling between hardware drivers.
> 
> Testcase: igt/vgem_basic/dmabuf-fence
> Signed-off-by: Chris Wilson 
> Cc: Sean Paul 
> Cc: Zach Reizner 
> Cc: Gustavo Padovan 
> Acked-by: Zach Reizner 
> ---
>  drivers/gpu/drm/vgem/Makefile |   2 +-
>  drivers/gpu/drm/vgem/vgem_drv.c   |  34 ++
>  drivers/gpu/drm/vgem/vgem_drv.h   |  18 
>  drivers/gpu/drm/vgem/vgem_fence.c | 220 
> ++
>  include/uapi/drm/vgem_drm.h   |  62 +++
>  5 files changed, 335 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/vgem/vgem_fence.c
>  create mode 100644 include/uapi/drm/vgem_drm.h
> 
> diff --git a/drivers/gpu/drm/vgem/Makefile b/drivers/gpu/drm/vgem/Makefile
> index 3f4c7b842028..bfcdea1330e6 100644
> --- a/drivers/gpu/drm/vgem/Makefile
> +++ b/drivers/gpu/drm/vgem/Makefile
> @@ -1,4 +1,4 @@
>  ccflags-y := -Iinclude/drm
> -vgem-y := vgem_drv.o
> +vgem-y := vgem_drv.o vgem_fence.o
>  
>  obj-$(CONFIG_DRM_VGEM)   += vgem.o
> diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
> index b5fb968d2d5c..2659e5cda857 100644
> --- a/drivers/gpu/drm/vgem/vgem_drv.c
> +++ b/drivers/gpu/drm/vgem/vgem_drv.c
> @@ -83,6 +83,34 @@ static const struct vm_operations_struct vgem_gem_vm_ops = 
> {
>   .close = drm_gem_vm_close,
>  };
>  
> +static int vgem_open(struct drm_device *dev, struct drm_file *file)
> +{
> + struct vgem_file *vfile;
> + int ret;
> +
> + vfile = kzalloc(sizeof(*vfile), GFP_KERNEL);
> + if (!vfile)
> + return -ENOMEM;
> +
> + file->driver_priv = vfile;
> +
> + ret = vgem_fence_open(vfile);
> + if (ret) {
> + kfree(vfile);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static void vgem_preclose(struct drm_device *dev, struct drm_file *file)
> +{
> + struct vgem_file *vfile = file->driver_priv;
> +
> + vgem_fence_close(vfile);
> + kfree(vfile);
> +}
> +
>  /* ioctls */
>  
>  static struct drm_gem_object *vgem_gem_create(struct drm_device *dev,
> @@ -164,6 +192,8 @@ unref:
>  }
>  
>  static struct drm_ioctl_desc vgem_ioctls[] = {
> + DRM_IOCTL_DEF_DRV(VGEM_FENCE_ATTACH, vgem_fence_attach_ioctl, 
> DRM_AUTH|DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(VGEM_FENCE_SIGNAL, vgem_fence_signal_ioctl, 
> DRM_AUTH|DRM_RENDER_ALLOW),
>  };
>  
>  static int vgem_mmap(struct file *filp, struct vm_area_struct *vma)
> @@ -271,9 +301,12 @@ static int vgem_prime_mmap(struct drm_gem_object *obj,
>  
>  static struct drm_driver vgem_driver = {
>   .driver_features= DRIVER_GEM | DRIVER_PRIME,
> + .open   = vgem_open,
> + .preclose   = vgem_preclose,
>   .gem_free_object_unlocked   = vgem_gem_free_object,
>   .gem_vm_ops = _gem_vm_ops,
>   .ioctls = vgem_ioctls,
> + .num_ioctls = ARRAY_SIZE(vgem_ioctls),
>   .fops   = _driver_fops,
>  
>   .dumb_create= vgem_gem_dumb_create,
> @@ -328,5 +361,6 @@ module_init(vgem_init);
>  module_exit(vgem_exit);
>  
>  MODULE_AUTHOR("Red Hat, Inc.");
> +MODULE_AUTHOR("Intel Corporation");
>  MODULE_DESCRIPTION(DRIVER_DESC);
>  MODULE_LICENSE("GPL and additional rights");
> diff --git a/drivers/gpu/drm/vgem/vgem_drv.h b/drivers/gpu/drm/vgem/vgem_drv.h
> index 988cbaae7588..88ce21010e28 100644
> --- a/drivers/gpu/drm/vgem/vgem_drv.h
> +++ b/drivers/gpu/drm/vgem/vgem_drv.h
> @@ -32,9 +32,27 @@
>  #include 
>  #include 
>  
> +#include 
> +
> +struct vgem_file {
> + struct idr fence_idr;
> + struct mutex fence_mutex;
> + u64 fence_context;
> + atomic_t fence_seqno;
> +};
> +
>  #define to_vgem_bo(x) container_of(x, struct drm_vgem_gem_object, base)
>  struct drm_vgem_gem_object {
>   struct drm_gem_object base;
>  };
>  
> +int vgem_fence_open(struct vgem_file *file);
> +int vgem_fence_attach_ioctl(struct drm_device *dev,
> + void *data,
> + struct drm_file *file);
> +int vgem_fence_signal_ioctl(struct drm_device *dev,
> + void *data,
> + struct drm_file *file);
> +void vgem_fence_close(struct vgem_file *file);
> +
>  #endif
> diff --git a/drivers/gpu/drm/vgem/vgem_fence.c 
> b/drivers/gpu/drm/vgem/vgem_fence.c
> new file mode 100644
> index 

[patch 2/2] qxl: silence uninitialized variable warning

2016-07-11 Thread Dan Carpenter
GCC doesn't complain about this but my static checker does.  We're
passing "drawable" before initializing it.  It's not actually used so
it's harmless and I just removed it.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/qxl/qxl_draw.c b/drivers/gpu/drm/qxl/qxl_draw.c
index 56e1d63..ffe8853 100644
--- a/drivers/gpu/drm/qxl/qxl_draw.c
+++ b/drivers/gpu/drm/qxl/qxl_draw.c
@@ -37,7 +37,6 @@ static int alloc_clips(struct qxl_device *qdev,
  * the qxl_clip_rects. This is *not* the same as the memory allocated
  * on the device, it is offset to qxl_clip_rects.chunk.data */
 static struct qxl_rect *drawable_set_clipping(struct qxl_device *qdev,
- struct qxl_drawable *drawable,
  unsigned num_clips,
  struct qxl_bo *clips_bo)
 {
@@ -349,7 +350,7 @@ void qxl_draw_dirty_fb(struct qxl_device *qdev,
if (ret)
goto out_release_backoff;

-   rects = drawable_set_clipping(qdev, drawable, num_clips, clips_bo);
+   rects = drawable_set_clipping(qdev, num_clips, clips_bo);
if (!rects)
goto out_release_backoff;



[patch 1/2] qxl: check for kmap failures

2016-07-11 Thread Dan Carpenter
If kmap fails, it leads to memory corruption.

Fixes: f64122c1f6ad ('drm: add new QXL driver. (v1.4)')
Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/qxl/qxl_draw.c b/drivers/gpu/drm/qxl/qxl_draw.c
index 56e1d63..6e6c760 100644
--- a/drivers/gpu/drm/qxl/qxl_draw.c
+++ b/drivers/gpu/drm/qxl/qxl_draw.c
@@ -136,6 +136,8 @@ static int qxl_palette_create_1bit(struct qxl_bo 
*palette_bo,
 * correctly globaly, since that would require
 * tracking all of our palettes. */
ret = qxl_bo_kmap(palette_bo, (void **));
+   if (ret)
+   return ret;
pal->num_ents = 2;
pal->unique = unique++;
if (visual == FB_VISUAL_TRUECOLOR || visual == FB_VISUAL_DIRECTCOLOR) {


[PATCH 0/3] imx drm atomic mode setting fixups

2016-07-11 Thread Ying Liu
Hi Philipp,

On Sat, Jul 9, 2016 at 1:24 AM, Philipp Zabel  wrote:
> Hi Liu,
>
> Am Freitag, den 08.07.2016, 17:38 +0800 schrieb Liu Ying:
> [...]
>> I'll respin to fix the LVDS bus format translation issue.
>> To keep my patch set as small as possible, I'll leave your 3 patches
>> for you to handle.  Please consider to rebase.
>
> Thanks, that works. I have rebased my changes on top:
>
> git://git.pengutronix.de/git/pza/linux.git imx-drm/atomic

It looks there is build break issue on this branch for the imx-tve driver.
It seems that driver is not fully cleanup wrt imx_drm_encoder.

Regards,
Liu Ying

>
> I plan to include this with my next pull request if there are no more
> issues.
>
> regards
> Philipp
>


[PATCH 0/3] imx drm atomic mode setting fixups

2016-07-11 Thread Philipp Zabel
Am Montag, den 11.07.2016, 10:56 +0800 schrieb Ying Liu:
> Hi Philipp,
> 
> On Sat, Jul 9, 2016 at 1:24 AM, Philipp Zabel  
> wrote:
> > Hi Liu,
> >
> > Am Freitag, den 08.07.2016, 17:38 +0800 schrieb Liu Ying:
> > [...]
> >> I'll respin to fix the LVDS bus format translation issue.
> >> To keep my patch set as small as possible, I'll leave your 3 patches
> >> for you to handle.  Please consider to rebase.
> >
> > Thanks, that works. I have rebased my changes on top:
> >
> > git://git.pengutronix.de/git/pza/linux.git imx-drm/atomic
> 
> It looks there is build break issue on this branch for the imx-tve driver.
> It seems that driver is not fully cleanup wrt imx_drm_encoder.

Thanks, it should be fixed now.

regards
Philipp



[PATCH 2/2] drm/bridge: tc358767: Add DPI to eDP bridge driver

2016-07-11 Thread Philipp Zabel
Am Montag, den 11.07.2016, 14:02 +0530 schrieb Archit Taneja:
[...]
> >>> + /* PXL PLL setup */
> >>> + if (tc->test_pattern) {
> >>
> >> I couldn't find out who is setting tc->test_pattern. Is it always
> >> 0?
> >
> > Hm, you are right. I wonder what a good mechanism would be to enable a
> > test pattern for a bridge driver. Module parameters? We don't have
> > anyhting like V4L2_CID_TEST_PATTERN in drm. I could also drop test
> > pattern support from the initial patch and submit it separately.
> 
> Module parameter sounds like a good option.

Ok.

> Although, it seems like the pll is enabled only when test_pattern is
> set. How does the bridge work if the pll isn't enabled?

The PXL PLL is only necessary regenerate the pixel clock from the DSI HS
clock, or to create the test pattern. In DPI mode the pixel clock from
the parallel interface is used directly.

regards
Philipp



[PATCH v3 3/3] drm/imx: turn remaining container_of macros into inline functions

2016-07-11 Thread Philipp Zabel
This allows the compiler to do type checking.

Signed-off-by: Philipp Zabel 
---
 drivers/gpu/drm/imx/imx-ldb.c  | 7 +--
 drivers/gpu/drm/imx/imx-tve.c  | 7 +--
 drivers/gpu/drm/imx/ipuv3-crtc.c   | 5 -
 drivers/gpu/drm/imx/ipuv3-plane.c  | 5 -
 drivers/gpu/drm/imx/parallel-display.c | 7 +--
 5 files changed, 23 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c
index 9ac8335..00d67b5 100644
--- a/drivers/gpu/drm/imx/imx-ldb.c
+++ b/drivers/gpu/drm/imx/imx-ldb.c
@@ -51,8 +51,6 @@
 #define LDB_DI1_VS_POL_ACT_LOW (1 << 10)
 #define LDB_BGREF_RMODE_INT(1 << 15)

-#define con_to_imx_ldb_ch(x) container_of(x, struct imx_ldb_channel, connector)
-
 struct imx_ldb;

 struct imx_ldb_channel {
@@ -70,6 +68,11 @@ struct imx_ldb_channel {
u32 bus_format;
 };

+static inline struct imx_ldb_channel *con_to_imx_ldb_ch(struct drm_connector 
*c)
+{
+   return container_of(c, struct imx_ldb_channel, connector);
+}
+
 static inline struct imx_ldb_channel *enc_to_imx_ldb_ch(struct drm_encoder *e)
 {
return container_of(e, struct imx_ldb_channel, encoder);
diff --git a/drivers/gpu/drm/imx/imx-tve.c b/drivers/gpu/drm/imx/imx-tve.c
index 520b312..a293a7d 100644
--- a/drivers/gpu/drm/imx/imx-tve.c
+++ b/drivers/gpu/drm/imx/imx-tve.c
@@ -98,8 +98,6 @@
 /* TVE_TST_MODE_REG */
 #define TVE_TVDAC_TEST_MODE_MASK   (0x7 << 0)

-#define con_to_tve(x) container_of(x, struct imx_tve, connector)
-
 enum {
TVE_MODE_TVOUT,
TVE_MODE_VGA,
@@ -124,6 +122,11 @@ struct imx_tve {
struct clk *di_clk;
 };

+static inline struct imx_tve *con_to_tve(struct drm_connector *c)
+{
+   return container_of(c, struct imx_tve, connector);
+}
+
 static inline struct imx_tve *enc_to_tve(struct drm_encoder *e)
 {
return container_of(e, struct imx_tve, encoder);
diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c b/drivers/gpu/drm/imx/ipuv3-crtc.c
index 2791ef0..08e188b 100644
--- a/drivers/gpu/drm/imx/ipuv3-crtc.c
+++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
@@ -46,7 +46,10 @@ struct ipu_crtc {
int irq;
 };

-#define to_ipu_crtc(x) container_of(x, struct ipu_crtc, base)
+static inline struct ipu_crtc *to_ipu_crtc(struct drm_crtc *crtc)
+{
+   return container_of(crtc, struct ipu_crtc, base);
+}

 static void ipu_crtc_enable(struct drm_crtc *crtc)
 {
diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
b/drivers/gpu/drm/imx/ipuv3-plane.c
index 3f5f956..4ad67d0 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -23,7 +23,10 @@
 #include "video/imx-ipu-v3.h"
 #include "ipuv3-plane.h"

-#define to_ipu_plane(x)container_of(x, struct ipu_plane, base)
+static inline struct ipu_plane *to_ipu_plane(struct drm_plane *p)
+{
+   return container_of(p, struct ipu_plane, base);
+}

 static const uint32_t ipu_plane_formats[] = {
DRM_FORMAT_ARGB1555,
diff --git a/drivers/gpu/drm/imx/parallel-display.c 
b/drivers/gpu/drm/imx/parallel-display.c
index 9da60df..7b7bb31 100644
--- a/drivers/gpu/drm/imx/parallel-display.c
+++ b/drivers/gpu/drm/imx/parallel-display.c
@@ -26,8 +26,6 @@

 #include "imx-drm.h"

-#define con_to_imxpd(x) container_of(x, struct imx_parallel_display, connector)
-
 struct imx_parallel_display {
struct drm_connector connector;
struct drm_encoder encoder;
@@ -39,6 +37,11 @@ struct imx_parallel_display {
struct drm_panel *panel;
 };

+static inline struct imx_parallel_display *con_to_imxpd(struct drm_connector 
*c)
+{
+   return container_of(c, struct imx_parallel_display, connector);
+}
+
 static inline struct imx_parallel_display *enc_to_imxpd(struct drm_encoder *e)
 {
return container_of(e, struct imx_parallel_display, encoder);
-- 
2.8.1



[PATCH v3 2/3] drm/imx: store internal bus configuration in crtc state

2016-07-11 Thread Philipp Zabel
The internal bus configuration is imx-drm specific crtc state. Store it
in imx_crtc_state and let the encoder atomic_check callbacks determine
bus_flags, bus_format and the sync pins, possibly taking into account
the mode and the connector display info.
The custom imx_drm_encoder structure can be replaced again with
drm_encoder.

Signed-off-by: Philipp Zabel 
---
Changes since v2:
 - Fixed build of imx-tve driver by removing remaining imx_drm_encoder
   occurences.
---
 drivers/gpu/drm/imx/dw_hdmi-imx.c  |  31 ++---
 drivers/gpu/drm/imx/imx-drm.h  |   9 ++-
 drivers/gpu/drm/imx/imx-ldb.c  | 111 ++---
 drivers/gpu/drm/imx/imx-tve.c  |  55 +---
 drivers/gpu/drm/imx/ipuv3-crtc.c   |  67 
 drivers/gpu/drm/imx/parallel-display.c |  63 +++
 6 files changed, 229 insertions(+), 107 deletions(-)

diff --git a/drivers/gpu/drm/imx/dw_hdmi-imx.c 
b/drivers/gpu/drm/imx/dw_hdmi-imx.c
index dce1ea5..359cd27 100644
--- a/drivers/gpu/drm/imx/dw_hdmi-imx.c
+++ b/drivers/gpu/drm/imx/dw_hdmi-imx.c
@@ -22,14 +22,17 @@

 #include "imx-drm.h"

-#define imx_enc_to_imx_hdmi(x) container_of(x, struct imx_hdmi, imx_encoder)
-
 struct imx_hdmi {
struct device *dev;
-   struct imx_drm_encoder imx_encoder;
+   struct drm_encoder encoder;
struct regmap *regmap;
 };

+static inline struct imx_hdmi *enc_to_imx_hdmi(struct drm_encoder *e)
+{
+   return container_of(e, struct imx_hdmi, encoder);
+}
+
 static const struct dw_hdmi_mpll_config imx_mpll_cfg[] = {
{
4525, {
@@ -113,8 +116,7 @@ static void dw_hdmi_imx_encoder_disable(struct drm_encoder 
*encoder)

 static void dw_hdmi_imx_encoder_enable(struct drm_encoder *encoder)
 {
-   struct imx_drm_encoder *imx_encoder = enc_to_imx_enc(encoder);
-   struct imx_hdmi *hdmi = imx_enc_to_imx_hdmi(imx_encoder);
+   struct imx_hdmi *hdmi = enc_to_imx_hdmi(encoder);
int mux = drm_of_encoder_active_port_id(hdmi->dev->of_node, encoder);

regmap_update_bits(hdmi->regmap, IOMUXC_GPR3,
@@ -122,9 +124,23 @@ static void dw_hdmi_imx_encoder_enable(struct drm_encoder 
*encoder)
   mux << IMX6Q_GPR3_HDMI_MUX_CTL_SHIFT);
 }

+static int dw_hdmi_imx_atomic_check(struct drm_encoder *encoder,
+   struct drm_crtc_state *crtc_state,
+   struct drm_connector_state *conn_state)
+{
+   struct imx_crtc_state *imx_crtc_state = to_imx_crtc_state(crtc_state);
+
+   imx_crtc_state->bus_format = MEDIA_BUS_FMT_RGB888_1X24;
+   imx_crtc_state->di_hsync_pin = 2;
+   imx_crtc_state->di_vsync_pin = 3;
+
+   return 0;
+}
+
 static const struct drm_encoder_helper_funcs dw_hdmi_imx_encoder_helper_funcs 
= {
.enable = dw_hdmi_imx_encoder_enable,
.disable= dw_hdmi_imx_encoder_disable,
+   .atomic_check = dw_hdmi_imx_atomic_check,
 };

 static const struct drm_encoder_funcs dw_hdmi_imx_encoder_funcs = {
@@ -205,10 +221,7 @@ static int dw_hdmi_imx_bind(struct device *dev, struct 
device *master,
match = of_match_node(dw_hdmi_imx_dt_ids, pdev->dev.of_node);
plat_data = match->data;
hdmi->dev = >dev;
-   encoder = >imx_encoder.encoder;
-   hdmi->imx_encoder.bus_format = MEDIA_BUS_FMT_RGB888_1X24;
-   hdmi->imx_encoder.di_hsync_pin = 2;
-   hdmi->imx_encoder.di_vsync_pin = 3;
+   encoder = >encoder;

irq = platform_get_irq(pdev, 0);
if (irq < 0)
diff --git a/drivers/gpu/drm/imx/imx-drm.h b/drivers/gpu/drm/imx/imx-drm.h
index 39cef15..07d33e4 100644
--- a/drivers/gpu/drm/imx/imx-drm.h
+++ b/drivers/gpu/drm/imx/imx-drm.h
@@ -15,15 +15,18 @@ struct platform_device;

 unsigned int imx_drm_crtc_id(struct imx_drm_crtc *crtc);

-struct imx_drm_encoder {
-   struct drm_encoder  encoder;
+struct imx_crtc_state {
+   struct drm_crtc_state   base;
u32 bus_format;
u32 bus_flags;
int di_hsync_pin;
int di_vsync_pin;
 };

-#define enc_to_imx_enc(x) container_of(x, struct imx_drm_encoder, encoder)
+static inline struct imx_crtc_state *to_imx_crtc_state(struct drm_crtc_state 
*s)
+{
+   return container_of(s, struct imx_crtc_state, base);
+}

 struct imx_drm_crtc_helper_funcs {
int (*enable_vblank)(struct drm_crtc *crtc);
diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c
index 9c48c4b..9ac8335 100644
--- a/drivers/gpu/drm/imx/imx-ldb.c
+++ b/drivers/gpu/drm/imx/imx-ldb.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -51,15 +52,13 @@
 #define LDB_BGREF_RMODE_INT(1 << 15)

 #define con_to_imx_ldb_ch(x) container_of(x, struct imx_ldb_channel, connector)

[PATCH v3 1/3] drm/imx: remove empty mode_set encoder callbacks

2016-07-11 Thread Philipp Zabel
With atomic modeset support, these callbacks are optional.

Signed-off-by: Philipp Zabel 
---
 drivers/gpu/drm/imx/dw_hdmi-imx.c  | 7 ---
 drivers/gpu/drm/imx/parallel-display.c | 7 ---
 2 files changed, 14 deletions(-)

diff --git a/drivers/gpu/drm/imx/dw_hdmi-imx.c 
b/drivers/gpu/drm/imx/dw_hdmi-imx.c
index 5f1d437..dce1ea5 100644
--- a/drivers/gpu/drm/imx/dw_hdmi-imx.c
+++ b/drivers/gpu/drm/imx/dw_hdmi-imx.c
@@ -111,12 +111,6 @@ static void dw_hdmi_imx_encoder_disable(struct drm_encoder 
*encoder)
 {
 }

-static void dw_hdmi_imx_encoder_mode_set(struct drm_encoder *encoder,
-struct drm_display_mode *mode,
-struct drm_display_mode *adj_mode)
-{
-}
-
 static void dw_hdmi_imx_encoder_enable(struct drm_encoder *encoder)
 {
struct imx_drm_encoder *imx_encoder = enc_to_imx_enc(encoder);
@@ -129,7 +123,6 @@ static void dw_hdmi_imx_encoder_enable(struct drm_encoder 
*encoder)
 }

 static const struct drm_encoder_helper_funcs dw_hdmi_imx_encoder_helper_funcs 
= {
-   .mode_set   = dw_hdmi_imx_encoder_mode_set,
.enable = dw_hdmi_imx_encoder_enable,
.disable= dw_hdmi_imx_encoder_disable,
 };
diff --git a/drivers/gpu/drm/imx/parallel-display.c 
b/drivers/gpu/drm/imx/parallel-display.c
index bb5dbd6..4a2942e 100644
--- a/drivers/gpu/drm/imx/parallel-display.c
+++ b/drivers/gpu/drm/imx/parallel-display.c
@@ -101,12 +101,6 @@ static void imx_pd_encoder_enable(struct drm_encoder 
*encoder)
drm_panel_enable(imxpd->panel);
 }

-static void imx_pd_encoder_mode_set(struct drm_encoder *encoder,
-struct drm_display_mode *orig_mode,
-struct drm_display_mode *mode)
-{
-}
-
 static void imx_pd_encoder_disable(struct drm_encoder *encoder)
 {
struct imx_drm_encoder *imx_encoder = enc_to_imx_enc(encoder);
@@ -136,7 +130,6 @@ static const struct drm_encoder_funcs imx_pd_encoder_funcs 
= {
 };

 static const struct drm_encoder_helper_funcs imx_pd_encoder_helper_funcs = {
-   .mode_set = imx_pd_encoder_mode_set,
.enable = imx_pd_encoder_enable,
.disable = imx_pd_encoder_disable,
 };
-- 
2.8.1



[PATCH v2 17/25] drm/msm/mdp5: Update compatible strings for MDSS/MDP5

2016-07-11 Thread Matthias Brugger
On 23/06/16 16:13, Archit Taneja wrote:
> Introduce new compatible strings for the top level MDSS wrapper device,
> and the MDP5 device.
>
> Previously, the "qcom,mdp5" and "qcom,mdss_mdp" compatible strings
> were used to match the top level platform_device (which was also tied
> to the top level drm_device struct). Now, these strings are used
> to match the MDP5 platform device.
>
> Use "qcom,mdss" as the compatible string for top level MDSS device.
> This is now used to match the top level platform_device (which is
> tied to the drm_device struct).
>
> Signed-off-by: Archit Taneja 
> ---
>   drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 10 +-
>   drivers/gpu/drm/msm/msm_drv.c   |  6 ++
>   2 files changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c 
> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
> index 174d7e7..a2bd6a4 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
> @@ -809,12 +809,20 @@ static int mdp5_dev_remove(struct platform_device *pdev)
>   return 0;
>   }
>
> +static const struct of_device_id dt_match[] = {
> + { .compatible = "qcom,mdp5", },
> + /* to support downstream DT files */
> + { .compatible = "qcom,mdss_mdp", },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, dt_match);
> +
>   static struct platform_driver mdp5_driver = {
>   .probe = mdp5_dev_probe,
>   .remove = mdp5_dev_remove,
>   .driver = {
>   .name = "msm_mdp",
> - /* Add a DT match field once we move to new hierarchy */
> + .of_match_table = dt_match,
>   },
>   };
>
> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> index be8f73a..f133dd5 100644
> --- a/drivers/gpu/drm/msm/msm_drv.c
> +++ b/drivers/gpu/drm/msm/msm_drv.c
> @@ -992,10 +992,8 @@ static int msm_pdev_remove(struct platform_device *pdev)
>   }
>
>   static const struct of_device_id dt_match[] = {
> - { .compatible = "qcom,mdp4", .data = (void *) 4 },  /* mdp4 */
> - { .compatible = "qcom,mdp5", .data = (void *) 5 },  /* mdp5 */
> - /* to support downstream DT files */
> - { .compatible = "qcom,mdss_mdp", .data = (void *) 5 },  /* mdp5 */
> + { .compatible = "qcom,mdp4", .data = (void *)4 },   /* MDP4 */
> + { .compatible = "qcom,mdss", .data = (void *)5 },   /* MDP5 MDSS */

This seems to break linux-next:
[ 3945s]   CC [M]  drivers/gpu/drm/nouveau/nvkm/core/ioctl.o
[ 3947s]   LD [M]  drivers/gpu/drm/msm/msm.o
[ 3947s] drivers/gpu/drm/msm/msm_drv.o:(.rodata+0x300): multiple 
definition of `__mod_of__dt_match_device_table'
[ 3947s] drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.o:(.rodata+0x1b0): first 
defined here
[ 3947s] make[6]: *** [../scripts/Makefile.build:427: 
drivers/gpu/drm/msm/msm.o] Error 1
[ 3947s] make[5]: *** [../scripts/Makefile.build:440: 
drivers/gpu/drm/msm] Error 2
[ 3947s] make[5]: *** Waiting for unfinished jobs

Reverting commit b71a717c955a ("drm/msm/mdp5: Update compatible strings 
for MDSS/MDP5") fixes the compilation error.

Regards,
Matthias


[PATCH] vga_switcheroo: Sphinxify docs

2016-07-11 Thread Lukas Wunner
Fix up formatting glitches remaining after the automatic rst conversion.

Cc: Jonathan Corbet 
Cc: Jani Nikula 
Signed-off-by: Lukas Wunner 
---
 Documentation/gpu/drm-internals.rst  |  4 ++--
 Documentation/gpu/vga-switcheroo.rst |  8 ++--
 drivers/gpu/vga/vga_switcheroo.c | 28 ++--
 3 files changed, 18 insertions(+), 22 deletions(-)

diff --git a/Documentation/gpu/drm-internals.rst 
b/Documentation/gpu/drm-internals.rst
index 4f71765..490d655 100644
--- a/Documentation/gpu/drm-internals.rst
+++ b/Documentation/gpu/drm-internals.rst
@@ -280,8 +280,8 @@ private data in the open method should free it here.
 The lastclose method should restore CRTC and plane properties to default
 value, so that a subsequent open of the device will not inherit state
 from the previous user. It can also be used to execute delayed power
-switching state changes, e.g. in conjunction with the vga_switcheroo
-infrastructure (see ?). Beyond that KMS drivers should not do any
+switching state changes, e.g. in conjunction with the :ref:`vga_switcheroo`
+infrastructure. Beyond that KMS drivers should not do any
 further cleanup. Only legacy UMS drivers might need to clean up device
 state so that the vga console or an independent fbdev driver could take
 over.
diff --git a/Documentation/gpu/vga-switcheroo.rst 
b/Documentation/gpu/vga-switcheroo.rst
index 327d930..cbbdb99 100644
--- a/Documentation/gpu/vga-switcheroo.rst
+++ b/Documentation/gpu/vga-switcheroo.rst
@@ -1,3 +1,5 @@
+.. _vga_switcheroo:
+
 ==
 VGA Switcheroo
 ==
@@ -94,9 +96,3 @@ Public functions

 .. kernel-doc:: include/linux/apple-gmux.h
:internal:
-
-.. WARNING: DOCPROC directive not supported: !Cdrivers/gpu/vga/vga_switcheroo.c
-
-.. WARNING: DOCPROC directive not supported: !Cinclude/linux/vga_switcheroo.h
-
-.. WARNING: DOCPROC directive not supported: 
!Cdrivers/platform/x86/apple-gmux.c
diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
index 2df216b3..5f962bf 100644
--- a/drivers/gpu/vga/vga_switcheroo.c
+++ b/drivers/gpu/vga/vga_switcheroo.c
@@ -52,9 +52,9 @@
  *
  * * muxed: Dual GPUs with a multiplexer chip to switch outputs between GPUs.
  * * muxless: Dual GPUs but only one of them is connected to outputs.
- * The other one is merely used to offload rendering, its results
- * are copied over PCIe into the framebuffer. On Linux this is
- * supported with DRI PRIME.
+ *   The other one is merely used to offload rendering, its results
+ *   are copied over PCIe into the framebuffer. On Linux this is
+ *   supported with DRI PRIME.
  *
  * Hybrid graphics started to appear in the late Naughties and were initially
  * all muxed. Newer laptops moved to a muxless architecture for cost reasons.
@@ -560,21 +560,21 @@ EXPORT_SYMBOL(vga_switcheroo_unlock_ddc);
  * * OFF: Power off the device not in use.
  * * ON: Power on the device not in use.
  * * IGD: Switch to the integrated graphics device.
- * Power on the integrated GPU if necessary, power off the discrete GPU.
- * Prerequisite is that no user space processes (e.g. Xorg, alsactl)
- * have opened device files of the GPUs or the audio client. If the
- * switch fails, the user may invoke lsof(8) or fuser(1) on /dev/dri/
- * and /dev/snd/controlC1 to identify processes blocking the switch.
+ *   Power on the integrated GPU if necessary, power off the discrete GPU.
+ *   Prerequisite is that no user space processes (e.g. Xorg, alsactl)
+ *   have opened device files of the GPUs or the audio client. If the
+ *   switch fails, the user may invoke lsof(8) or fuser(1) on /dev/dri/
+ *   and /dev/snd/controlC1 to identify processes blocking the switch.
  * * DIS: Switch to the discrete graphics device.
  * * DIGD: Delayed switch to the integrated graphics device.
- * This will perform the switch once the last user space process has
- * closed the device files of the GPUs and the audio client.
+ *   This will perform the switch once the last user space process has
+ *   closed the device files of the GPUs and the audio client.
  * * DDIS: Delayed switch to the discrete graphics device.
  * * MIGD: Mux-only switch to the integrated graphics device.
- * Does not remap console or change the power state of either gpu.
- * If the integrated GPU is currently off, the screen will turn black.
- * If it is on, the screen will show whatever happens to be in VRAM.
- * Either way, the user has to blindly enter the command to switch back.
+ *   Does not remap console or change the power state of either gpu.
+ *   If the integrated GPU is currently off, the screen will turn black.
+ *   If it is on, the screen will show whatever happens to be in VRAM.
+ *   Either way, the user has to blindly enter the command to switch back.
  * * MDIS: Mux-only switch to the discrete graphics device.
  *
  * For GPUs whose power state is controlled by the driver's runtime pm,
-- 
2.8.1



[PATCH 5/7] drm/rockchip: dw-mipi: support HPD poll

2016-07-11 Thread John Keeping
On Mon, 11 Jul 2016 08:46:53 +0800, Mark yao wrote:

> On 2016年07月08日 21:52, John Keeping wrote:
> > On Fri,  8 Jul 2016 17:04:59 +0800, Chris Zhong wrote:
> >  
> >> At the first time of bind, there is no any panel attach in mipi. Add a
> >> DRM_CONNECTOR_POLL_HPD porperty to detect the panel status, when panel
> >> probe, the dw_mipi_dsi_host_attach would be called, then mipi-dsi will
> >> trigger a event to notify the drm framework.
> >>
> >> Signed-off-by: Chris Zhong   
> > Can we do something like this instead?  We know that the panel must
> > always be attached and this has the advantage that the display size will
> > be known when the framebuffer console loads.
> >  
> > -- >8 --  
> > Subject: [PATCH] drm/rockchip: dw-mipi-dsi: defer probe if panel is not 
> > loaded
> >
> > This ensures that the output resolution is known before fbcon loads.
> >
> > Signed-off-by: John Keeping 
> > ---
> >   drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 11 +--
> >   1 file changed, 9 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
> > b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> > index 6ef5f3be8468..c0499266d116 100644
> > --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> > +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> > @@ -1154,10 +1154,17 @@ static int dw_mipi_dsi_bind(struct device *dev, 
> > struct device *master,
> >   
> > dsi->dsi_host.ops = _mipi_dsi_host_ops;
> > dsi->dsi_host.dev = dev;
> > -   return mipi_dsi_host_register(>dsi_host);
> > +   ret = mipi_dsi_host_register(>dsi_host);
> > +   if (!ret && !dsi->panel) {
> > +   mipi_dsi_host_unregister(>dsi_host);
> > +   drm_encoder_cleanup(>encoder);
> > +   drm_connector_cleanup(>connector);
> > +   ret = -EPROBE_DEFER;  
> 
> Do you verify this patch? I do the similar change before, but found 
> panel can't probe.
> 
> mipi_dsi_host_register will call device_add, I think the panel probe 
> need this.
> 
> Seems that mipi panel probe request mipi_dsi_host_register, 
> mipi_dsi_host_register request panel on your patch, endless loop.

Yes, I've been running this patch for months.  It's possible that I have
another patch that is needed to get this to work correctly (I have a
whole set of Rockchip MIPI patches that I need to find time to submit,
for now I've pushed a branch to Github [1]).

I don't know what you mean about the panel probe requesting
mipi_dsi_host_register, the panel probe calls mipi_dsi_attach() and is
itself called from mipi_dsi_host_register().  My patch doesn't change
this at all, the only change is that if the panel driver is not
available, then the probe fails.  Later, once the panel driver has been
registered the probe will succeed.  This is no different from the
current behaviour if the order of probing drivers happens to load the
panel before dw-mipi-dsi.

[1] https://github.com/johnkeeping/linux/commits/topic/rockchip-mipi

> > +   }
> >   
> >   err_pllref:
> > -   clk_disable_unprepare(dsi->pllref_clk);
> > +   if (ret)
> > +   clk_disable_unprepare(dsi->pllref_clk);
> > return ret;
> >   }
> >   
> >
> >
> >  
> 
> 


[Bug 96881] ViennaCL fails dense_blas-bench-opencl benchmark with doubles on AMD CYPRESS (DRM 2.43.0, LLVM 3.8.0)

2016-07-11 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=96881

Vedran Miletić  changed:

   What|Removed |Added

 CC||jan.vesely at rutgers.edu,
   ||vedran at miletic.net

--- Comment #1 from Vedran Miletić  ---
Jan, does R600 backend in LLVM have relevant instructions implemented?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160711/6c812688/attachment.html>


[Bug 96868] AMDGPU Tonga only does 2560x1440 at 120hz, switching to 144hz causes display errors, same thing used to happen with fglrx.

2016-07-11 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=96868

Michel Dänzer  changed:

   What|Removed |Added

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

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160711/8017bc8c/attachment.html>


[Bug 96868] AMDGPU Tonga only does 2560x1440 at 120hz, switching to 144hz causes display errors, same thing used to happen with fglrx.

2016-07-11 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=96868

Michel Dänzer  changed:

   What|Removed |Added

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

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160711/3bfb0de5/attachment.html>


[Bug 121831] Several kmemcheck: Caught 64-bit read from uninitialized memory in radeo

2016-07-11 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=121831

--- Comment #1 from Michel Dänzer  ---
Shouldn't drivers/dma-buf/fence.c:fence_init() fully initialize the struct
fence passed in? If not, using kzalloc instead of kmalloc in radeon_fence_emit
should probably fix this.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.


[Bug 96868] AMDGPU Tonga only does 2560x1440 at 120hz, switching to 144hz causes display errors, same thing used to happen with fglrx.

2016-07-11 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=96868

--- Comment #3 from almoped at gmail.com ---
Created attachment 125007
  --> https://bugs.freedesktop.org/attachment.cgi?id=125007=edit
dmesg of 4.6.3 kernel

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160711/4e66eba7/attachment-0001.html>


[Bug 96868] AMDGPU Tonga only does 2560x1440 at 120hz, switching to 144hz causes display errors, same thing used to happen with fglrx.

2016-07-11 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=96868

--- Comment #2 from almoped at gmail.com ---
Created attachment 125006
  --> https://bugs.freedesktop.org/attachment.cgi?id=125006=edit
X log with 144hz not working

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160711/45b96e00/attachment-0001.html>


[PATCH 5/7] drm/rockchip: dw-mipi: support HPD poll

2016-07-11 Thread Mark yao
On 2016年07月08日 21:52, John Keeping wrote:
> On Fri,  8 Jul 2016 17:04:59 +0800, Chris Zhong wrote:
>
>> At the first time of bind, there is no any panel attach in mipi. Add a
>> DRM_CONNECTOR_POLL_HPD porperty to detect the panel status, when panel
>> probe, the dw_mipi_dsi_host_attach would be called, then mipi-dsi will
>> trigger a event to notify the drm framework.
>>
>> Signed-off-by: Chris Zhong 
> Can we do something like this instead?  We know that the panel must
> always be attached and this has the advantage that the display size will
> be known when the framebuffer console loads.
>
> -- >8 --
> Subject: [PATCH] drm/rockchip: dw-mipi-dsi: defer probe if panel is not loaded
>
> This ensures that the output resolution is known before fbcon loads.
>
> Signed-off-by: John Keeping 
> ---
>   drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 11 +--
>   1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
> b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> index 6ef5f3be8468..c0499266d116 100644
> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> @@ -1154,10 +1154,17 @@ static int dw_mipi_dsi_bind(struct device *dev, 
> struct device *master,
>   
>   dsi->dsi_host.ops = _mipi_dsi_host_ops;
>   dsi->dsi_host.dev = dev;
> - return mipi_dsi_host_register(>dsi_host);
> + ret = mipi_dsi_host_register(>dsi_host);
> + if (!ret && !dsi->panel) {
> + mipi_dsi_host_unregister(>dsi_host);
> + drm_encoder_cleanup(>encoder);
> + drm_connector_cleanup(>connector);
> + ret = -EPROBE_DEFER;

Hi John

Do you verify this patch? I do the similar change before, but found 
panel can't probe.

mipi_dsi_host_register will call device_add, I think the panel probe 
need this.

Seems that mipi panel probe request mipi_dsi_host_register, 
mipi_dsi_host_register request panel on your patch, endless loop.

Thanks.

> + }
>   
>   err_pllref:
> - clk_disable_unprepare(dsi->pllref_clk);
> + if (ret)
> + clk_disable_unprepare(dsi->pllref_clk);
>   return ret;
>   }
>   
>
>
>


-- 
ï¼­ark Yao




[PULL] topic/drm-misc

2016-07-11 Thread Daniel Vetter
Hi Dave,

Just flushing out drm-misc for the merge window:
- rpm fixes from Lukas that I promised to merge and dropped the ball until
  he pinged me.
- misc trivial patches Jani picked up.

I haven't recovered mail backlog yet, so no idea what's hiding still ;-)

Cheers, Daniel


The following changes since commit 2a3467063ae3b17264578626dec2377dd48cd1c3:

  Merge tag 'mediatek-drm-2016-06-20' of git://git.pengutronix.de/git/pza/linux 
into drm-next (2016-06-24 13:16:07 +1000)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/topic/drm-misc-2016-07-11

for you to fetch changes up to 2ae995887830b335f9bdab3040018071da54bcdb:

  drm: Fix a typo in drm_ioctl.c (2016-06-30 12:04:44 +0300)


Frank Binns (1):
  drm: fix some spelling mistakes

Lukas Wunner (15):
  drm/nouveau: Don't leak runtime pm ref on driver unload
  drm/nouveau: Forbid runtime pm on driver unload
  drm/radeon: Don't leak runtime pm ref on driver unload
  drm/radeon: Don't leak runtime pm ref on driver load
  drm/radeon: Forbid runtime pm on driver unload
  drm/amdgpu: Don't leak runtime pm ref on driver unload
  drm/amdgpu: Don't leak runtime pm ref on driver load
  drm/amdgpu: Forbid runtime pm on driver unload
  drm: Add helpers to turn off CRTCs
  drm/nouveau: Turn off CRTCs on driver unload
  drm/radeon: Turn off CRTCs on driver unload
  drm/amdgpu: Turn off CRTCs on driver unload
  drm: Use helper to turn off CRTC
  drm/i2c/ch7006: Use helper to turn off CRTC
  drm/nouveau/dispnv04: Use helper to turn off CRTC

Masanari Iida (1):
  drm: Fix a typo in drm_ioctl.c

 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c| 12 +--
 drivers/gpu/drm/drm_crtc.c | 53 ++
 drivers/gpu/drm/drm_ioctl.c|  2 +-
 drivers/gpu/drm/drm_irq.c  |  4 +--
 drivers/gpu/drm/i2c/ch7006_drv.c   |  9 ++---
 drivers/gpu/drm/nouveau/dispnv04/disp.c| 10 --
 drivers/gpu/drm/nouveau/dispnv04/tvnv17.c  |  9 ++---
 drivers/gpu/drm/nouveau/nouveau_display.c  |  1 +
 drivers/gpu/drm/nouveau/nouveau_drm.c  |  6 +++-
 drivers/gpu/drm/radeon/radeon_device.c |  4 +++
 drivers/gpu/drm/radeon/radeon_display.c|  1 +
 drivers/gpu/drm/radeon/radeon_kms.c|  5 ++-
 include/drm/drm_crtc.h |  2 ++
 14 files changed, 80 insertions(+), 39 deletions(-)

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


[Bug 96877] Bioshock Infinite: LLVM triggered Diagnostic Handler: Illegal instruction detected: Operand has incorrect register class.

2016-07-11 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=96877

--- Comment #3 from Michel Dänzer  ---
FWIW, Nicolai's patch seems to fix lots of piglit regressions on my Kaveri.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160711/2c7f1bfe/attachment.html>


[PATCH v2 17/25] drm/msm/mdp5: Update compatible strings for MDSS/MDP5

2016-07-11 Thread Rob Clark
On Mon, Jul 11, 2016 at 4:39 AM, Matthias Brugger  wrote:
> On 23/06/16 16:13, Archit Taneja wrote:
>>
>> Introduce new compatible strings for the top level MDSS wrapper device,
>> and the MDP5 device.
>>
>> Previously, the "qcom,mdp5" and "qcom,mdss_mdp" compatible strings
>> were used to match the top level platform_device (which was also tied
>> to the top level drm_device struct). Now, these strings are used
>> to match the MDP5 platform device.
>>
>> Use "qcom,mdss" as the compatible string for top level MDSS device.
>> This is now used to match the top level platform_device (which is
>> tied to the drm_device struct).
>>
>> Signed-off-by: Archit Taneja 
>> ---
>>   drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 10 +-
>>   drivers/gpu/drm/msm/msm_drv.c   |  6 ++
>>   2 files changed, 11 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
>> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
>> index 174d7e7..a2bd6a4 100644
>> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
>> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
>> @@ -809,12 +809,20 @@ static int mdp5_dev_remove(struct platform_device
>> *pdev)
>> return 0;
>>   }
>>
>> +static const struct of_device_id dt_match[] = {
>> +   { .compatible = "qcom,mdp5", },
>> +   /* to support downstream DT files */
>> +   { .compatible = "qcom,mdss_mdp", },
>> +   {}
>> +};
>> +MODULE_DEVICE_TABLE(of, dt_match);
>> +
>>   static struct platform_driver mdp5_driver = {
>> .probe = mdp5_dev_probe,
>> .remove = mdp5_dev_remove,
>> .driver = {
>> .name = "msm_mdp",
>> -   /* Add a DT match field once we move to new hierarchy */
>> +   .of_match_table = dt_match,
>> },
>>   };
>>
>> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
>> index be8f73a..f133dd5 100644
>> --- a/drivers/gpu/drm/msm/msm_drv.c
>> +++ b/drivers/gpu/drm/msm/msm_drv.c
>> @@ -992,10 +992,8 @@ static int msm_pdev_remove(struct platform_device
>> *pdev)
>>   }
>>
>>   static const struct of_device_id dt_match[] = {
>> -   { .compatible = "qcom,mdp4", .data = (void *) 4 },  /* mdp4 */
>> -   { .compatible = "qcom,mdp5", .data = (void *) 5 },  /* mdp5 */
>> -   /* to support downstream DT files */
>> -   { .compatible = "qcom,mdss_mdp", .data = (void *) 5 },  /* mdp5 */
>> +   { .compatible = "qcom,mdp4", .data = (void *)4 },   /* MDP4 */
>> +   { .compatible = "qcom,mdss", .data = (void *)5 },   /* MDP5
>> MDSS */
>
>
> This seems to break linux-next:
> [ 3945s]   CC [M]  drivers/gpu/drm/nouveau/nvkm/core/ioctl.o
> [ 3947s]   LD [M]  drivers/gpu/drm/msm/msm.o
> [ 3947s] drivers/gpu/drm/msm/msm_drv.o:(.rodata+0x300): multiple definition
> of `__mod_of__dt_match_device_table'
> [ 3947s] drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.o:(.rodata+0x1b0): first
> defined here
> [ 3947s] make[6]: *** [../scripts/Makefile.build:427:
> drivers/gpu/drm/msm/msm.o] Error 1
> [ 3947s] make[5]: *** [../scripts/Makefile.build:440: drivers/gpu/drm/msm]
> Error 2
> [ 3947s] make[5]: *** Waiting for unfinished jobs
>
> Reverting commit b71a717c955a ("drm/msm/mdp5: Update compatible strings for
> MDSS/MDP5") fixes the compilation error.


fyi, I updated msm-next over the weekend, which should fix this (and
an unrelated bisectability issue).  I guess it should show up in
linux-next soonish..

BR,
-R


[Bug 96868] AMDGPU Tonga only does 2560x1440 at 120hz, switching to 144hz causes display errors, same thing used to happen with fglrx.

2016-07-11 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=96868

Michel Dänzer  changed:

   What|Removed |Added

  Component|Driver/AMDgpu   |DRM/AMDgpu
Version|7.7 (2012.06)   |unspecified
 QA Contact|xorg-team at lists.x.org   |
Product|xorg|DRI
   Assignee|xorg-driver-ati at lists.x.org |dri-devel at 
lists.freedesktop
   ||.org

--- Comment #1 from Michel Dänzer  ---
Please attach the corresponding dmesg output and Xorg log file.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160711/65dbddb9/attachment.html>


[Bug 96885] AMDGPU Power management failure on 290X

2016-07-11 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=96885

Michel Dänzer  changed:

   What|Removed |Added

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

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160711/d8b1b169/attachment.html>