Re: [PATCH v2] drm/hisilicon: fix build error without fbdev emulation

2017-07-25 Thread Arnd Bergmann
On Wed, Jul 26, 2017 at 7:55 AM, Daniel Vetter  wrote:
> On Tue, Jul 25, 2017 at 8:05 PM, Arnd Bergmann  wrote:
>> We cannot reference priv->fbdev outside of the #ifdef:
>>
>> drivers/net/virtio_net.c:1881:12: error: 'virtnet_restore_up' defined but 
>> not used [-Werror=unused-function]
>>  static int virtnet_restore_up(struct virtio_device *vdev)
>> drivers/net/virtio_net.c:1859:13: error: 'virtnet_freeze_down' defined but 
>> not used [-Werror=unused-function]
>>  static void virtnet_freeze_down(struct virtio_device *vdev)
>>
>> As the #ifdef is a bit annoying here, this removes it entirely
>> and uses an IS_ENABLED() check in it place where needed.
>>
>> Fixes: b4dd9f1ffaba ("drm/hisilicon: Remove custom FB helper deferred setup")
>> Signed-off-by: Arnd Bergmann 
>
> I guess I wasn't clear enough, but you don't even need the IS_ENABLED.
> The cma_fini/init functions themselves don't get no-opped out (I guess
> we could fix that), but the underlying fb helper functions they call
> do, so this is all perfectly fine to call unconditionally. And that's
> what all other drivers do. Should I edit while applying, or do you
> want to respin?

Please just edit as you like then, I think that's quicker.

The version I sent was meant to have smaller object code as well, and
I didn't think we could rely on drm_fb_cma_helper.c being built without
CONFIG_DRM_FBDEV_EMULATION, but I see now that they are
independent as you say, so making them unconditional indeed gives
the simplest code.

Thanks!

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


[PATCH v6 4/7] drm/rockchip: vop: group vop registers

2017-07-25 Thread Mark Yao
Grouping the vop registers facilitates make register
definition clearer, and also is useful for different vop
reuse the same group register.

Signed-off-by: Mark Yao 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  99 
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h |  60 ---
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 112 +++-
 3 files changed, 144 insertions(+), 127 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index fd47da5..92d098b 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -42,30 +42,19 @@
 #include "rockchip_drm_psr.h"
 #include "rockchip_drm_vop.h"
 
-#define REG_SET(x, base, reg, v) \
-   vop_mask_write(x, base + reg.offset, reg.mask, reg.shift, \
-  v, reg.write_mask, reg.relaxed)
-#define REG_SET_MASK(x, base, reg, mask, v) \
-   vop_mask_write(x, base + reg.offset, \
-  mask, reg.shift, v, reg.write_mask, reg.relaxed)
-
 #define VOP_WIN_SET(x, win, name, v) \
-   REG_SET(x, win->base, win->phy->name, v)
+   vop_reg_set(vop, &win->phy->name, win->base, ~0, v, #name)
 #define VOP_SCL_SET(x, win, name, v) \
-   REG_SET(x, win->base, win->phy->scl->name, v)
+   vop_reg_set(vop, &win->phy->scl->name, win->base, ~0, v, #name)
 #define VOP_SCL_SET_EXT(x, win, name, v) \
-   REG_SET(x, win->base, win->phy->scl->ext->name, v)
-#define VOP_CTRL_SET(x, name, v) \
-   REG_SET(x, 0, (x)->data->ctrl->name, v)
-
-#define VOP_INTR_GET(vop, name) \
-   vop_read_reg(vop, 0, &vop->data->ctrl->name)
-
-#define VOP_INTR_SET(vop, name, v) \
-   REG_SET(vop, 0, vop->data->intr->name, v)
+   vop_reg_set(vop, &win->phy->scl->ext->name, \
+   win->base, ~0, v, #name)
 
 #define VOP_INTR_SET_MASK(vop, name, mask, v) \
-   REG_SET_MASK(vop, 0, vop->data->intr->name, mask, v)
+   vop_reg_set(vop, &vop->data->intr->name, 0, mask, v, #name)
+
+#define VOP_REG_SET(vop, group, name, v) \
+   vop_reg_set(vop, &vop->data->group->name, 0, ~0, v, #name)
 
 #define VOP_INTR_SET_TYPE(vop, name, type, v) \
do { \
@@ -82,7 +71,7 @@
vop_get_intr_type(vop, &vop->data->intr->name, type)
 
 #define VOP_WIN_GET(x, win, name) \
-   vop_read_reg(x, win->base, &win->phy->name)
+   vop_read_reg(x, win->offset, win->phy->name)
 
 #define VOP_WIN_GET_YRGBADDR(vop, win) \
vop_readl(vop, win->base + win->phy->yrgb_mst.offset)
@@ -164,14 +153,20 @@ static inline uint32_t vop_read_reg(struct vop *vop, 
uint32_t base,
return (vop_readl(vop, base + reg->offset) >> reg->shift) & reg->mask;
 }
 
-static inline void vop_mask_write(struct vop *vop, uint32_t offset,
- uint32_t mask, uint32_t shift, uint32_t v,
- bool write_mask, bool relaxed)
+static void vop_reg_set(struct vop *vop, const struct vop_reg *reg,
+   uint32_t _offset, uint32_t _mask, uint32_t v,
+   const char *reg_name)
 {
-   if (!mask)
+   int offset = reg->offset + _offset;
+   int mask = reg->mask & _mask;
+   int shift = reg->shift;
+
+   if (!reg || !reg->mask) {
+   dev_dbg(vop->dev, "Warning: not support %s\n", reg_name);
return;
+   }
 
-   if (write_mask) {
+   if (reg->write_mask) {
v = ((v << shift) & 0x) | (mask << (shift + 16));
} else {
uint32_t cached_val = vop->regsbak[offset >> 2];
@@ -180,7 +175,7 @@ static inline void vop_mask_write(struct vop *vop, uint32_t 
offset,
vop->regsbak[offset >> 2] = v;
}
 
-   if (relaxed)
+   if (reg->relaxed)
writel_relaxed(v, vop->regs + offset);
else
writel(v, vop->regs + offset);
@@ -202,7 +197,7 @@ static inline uint32_t vop_get_intr_type(struct vop *vop,
 
 static inline void vop_cfg_done(struct vop *vop)
 {
-   VOP_CTRL_SET(vop, cfg_done, 1);
+   VOP_REG_SET(vop, common, cfg_done, 1);
 }
 
 static bool has_rb_swapped(uint32_t format)
@@ -540,7 +535,7 @@ static int vop_enable(struct drm_crtc *crtc)
 
spin_lock(&vop->reg_lock);
 
-   VOP_CTRL_SET(vop, standby, 0);
+   VOP_REG_SET(vop, common, standby, 1);
 
spin_unlock(&vop->reg_lock);
 
@@ -600,7 +595,7 @@ static void vop_crtc_disable(struct drm_crtc *crtc)
 
spin_lock(&vop->reg_lock);
 
-   VOP_CTRL_SET(vop, standby, 1);
+   VOP_REG_SET(vop, common, standby, 1);
 
spin_unlock(&vop->reg_lock);
 
@@ -923,7 +918,7 @@ static void vop_crtc_enable(struct drm_crtc *crtc)
 
spin_lock(&vop->reg_lock);
 
-   VOP_CTRL_SET(v

[PATCH v6 5/7] drm/rockchip: vop: add a series of vop support

2017-07-25 Thread Mark Yao
Vop Full framework now has following vops:
IP versionchipname
  3.1   rk3288
  3.2   rk3368
  3.4   rk3366
  3.5   rk3399 big
  3.6   rk3399 lit
  3.7   rk3228
  3.8   rk3328

The above IP version is from H/W define, some of vop support get
the IP version from VERSION_INFO register, some are not.
hardcode the IP version for each vop to identify them.

major version: used for IP structure, Vop full framework is 3,
   vop little framework is 2.
minor version: on same structure, newer design vop will bigger
   then old one.

Signed-off-by: Mark Yao 
---
Changes in v3:
- fixup some mistake
- use separate structures instead VOP_REG_VER mechanism

Changes in v2:
- rename rk322x to rk3228(Heiko Stübner)
- correct some vop registers define

 drivers/gpu/drm/rockchip/rockchip_drm_vop.h |   9 +
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 218 ++-
 drivers/gpu/drm/rockchip/rockchip_vop_reg.h | 905 ++--
 3 files changed, 908 insertions(+), 224 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
index 3ba962c..43d08c8 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
@@ -15,6 +15,14 @@
 #ifndef _ROCKCHIP_DRM_VOP_H
 #define _ROCKCHIP_DRM_VOP_H
 
+/*
+ * major: IP major version, used for IP structure
+ * minor: big feature change under same structure
+ */
+#define VOP_VERSION(major, minor)  ((major) << 8 | (minor))
+#define VOP_MAJOR(version) ((version) >> 8)
+#define VOP_MINOR(version) ((version) & 0xff)
+
 enum vop_data_format {
VOP_FMT_ARGB = 0,
VOP_FMT_RGB888,
@@ -142,6 +150,7 @@ struct vop_win_data {
 };
 
 struct vop_data {
+   uint32_t version;
const struct vop_intr *intr;
const struct vop_common *common;
const struct vop_misc *misc;
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c 
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 20607a8..bc7b2d0 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -277,6 +277,7 @@
 };
 
 static const struct vop_data rk3288_vop = {
+   .version = VOP_VERSION(3, 1),
.feature = VOP_FEATURE_OUTPUT_RGB10,
.intr = &rk3288_vop_intr,
.common = &rk3288_common,
@@ -286,7 +287,7 @@
.win_size = ARRAY_SIZE(rk3288_vop_win_data),
 };
 
-static const int rk3399_vop_intrs[] = {
+static const int rk3368_vop_intrs[] = {
FS_INTR,
0, 0,
LINE_FLAG_INTR,
@@ -296,22 +297,95 @@
DSP_HOLD_VALID_INTR,
 };
 
-static const struct vop_intr rk3399_vop_intr = {
-   .intrs = rk3399_vop_intrs,
-   .nintrs = ARRAY_SIZE(rk3399_vop_intrs),
-   .line_flag_num[0] = VOP_REG(RK3399_LINE_FLAG, 0x, 0),
-   .line_flag_num[1] = VOP_REG(RK3399_LINE_FLAG, 0x, 16),
-   .status = VOP_REG_MASK_SYNC(RK3399_INTR_STATUS0, 0x, 0),
-   .enable = VOP_REG_MASK_SYNC(RK3399_INTR_EN0, 0x, 0),
-   .clear = VOP_REG_MASK_SYNC(RK3399_INTR_CLEAR0, 0x, 0),
+static const struct vop_intr rk3368_vop_intr = {
+   .intrs = rk3368_vop_intrs,
+   .nintrs = ARRAY_SIZE(rk3368_vop_intrs),
+   .line_flag_num[0] = VOP_REG(RK3368_LINE_FLAG, 0x, 0),
+   .line_flag_num[1] = VOP_REG(RK3368_LINE_FLAG, 0x, 16),
+   .status = VOP_REG_MASK_SYNC(RK3368_INTR_STATUS, 0x3fff, 0),
+   .enable = VOP_REG_MASK_SYNC(RK3368_INTR_EN, 0x3fff, 0),
+   .clear = VOP_REG_MASK_SYNC(RK3368_INTR_CLEAR, 0x3fff, 0),
+};
+
+static const struct vop_win_phy rk3368_win23_data = {
+   .data_formats = formats_win_lite,
+   .nformats = ARRAY_SIZE(formats_win_lite),
+   .gate = VOP_REG(RK3368_WIN2_CTRL0, 0x1, 0),
+   .enable = VOP_REG(RK3368_WIN2_CTRL0, 0x1, 4),
+   .format = VOP_REG(RK3368_WIN2_CTRL0, 0x3, 5),
+   .rb_swap = VOP_REG(RK3368_WIN2_CTRL0, 0x1, 20),
+   .dsp_info = VOP_REG(RK3368_WIN2_DSP_INFO0, 0x0fff0fff, 0),
+   .dsp_st = VOP_REG(RK3368_WIN2_DSP_ST0, 0x1fff1fff, 0),
+   .yrgb_mst = VOP_REG(RK3368_WIN2_MST0, 0x, 0),
+   .yrgb_vir = VOP_REG(RK3368_WIN2_VIR0_1, 0x1fff, 0),
+   .src_alpha_ctl = VOP_REG(RK3368_WIN2_SRC_ALPHA_CTRL, 0xff, 0),
+   .dst_alpha_ctl = VOP_REG(RK3368_WIN2_DST_ALPHA_CTRL, 0xff, 0),
+};
+
+static const struct vop_win_data rk3368_vop_win_data[] = {
+   { .base = 0x00, .phy = &rk3288_win01_data,
+ .type = DRM_PLANE_TYPE_PRIMARY },
+   { .base = 0x40, .phy = &rk3288_win01_data,
+ .type = DRM_PLANE_TYPE_OVERLAY },
+   { .base = 0x00, .phy = &rk3368_win23_data,
+ .type = DRM_PLANE_TYPE_OVERLAY },
+   { .base = 0x50, .phy = &rk3368_win23_data,
+ .type = DRM_PLANE_TYPE_CURSOR },
+};
+
+static const struct vop_output rk3368_output = {
+   .rgb_pin_pol = VOP_REG(RK3368_DSP_CTRL1, 0xf, 16),
+   .hdmi_pin_pol = VOP_REG(RK3368_DSP_CTRL1,

[PATCH v6 7/7] drm/rockchip: vop: rk3328: fix overlay abnormal

2017-07-25 Thread Mark Yao
It's a hardware bug, all window's overlay channel reset
value is same, hardware overlay would be die.

so we must initial difference id for each overlay channel.

The Channel register is supported on all vop will full design.
Following is the details for this register
VOP_WIN0_CTRL2
  bit[7:4] win_rid_win0_cbr
   axi read id of win0 cbr channel
  bit[3:0] win_rid_win0_yrgb
   axi read id of win0 yrgb channel

Signed-off-by: Mark Yao 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 2 ++
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 1 +
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 1 +
 3 files changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 92d098b..e4b3388 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -1452,7 +1452,9 @@ static int vop_initial(struct vop *vop)
 
for (i = 0; i < vop_data->win_size; i++) {
const struct vop_win_data *win = &vop_data->win[i];
+   int channel = i * 2 + 1;
 
+   VOP_WIN_SET(vop, win, channel, (channel + 1) << 4 | channel);
VOP_WIN_SET(vop, win, enable, 0);
VOP_WIN_SET(vop, win, gate, 1);
}
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
index 43d08c8..af1091f 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
@@ -141,6 +141,7 @@ struct vop_win_phy {
 
struct vop_reg dst_alpha_ctl;
struct vop_reg src_alpha_ctl;
+   struct vop_reg channel;
 };
 
 struct vop_win_data {
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c 
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index bc7b2d0..94de7b9 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -197,6 +197,7 @@
.uv_vir = VOP_REG(RK3288_WIN0_VIR, 0x3fff, 16),
.src_alpha_ctl = VOP_REG(RK3288_WIN0_SRC_ALPHA_CTRL, 0xff, 0),
.dst_alpha_ctl = VOP_REG(RK3288_WIN0_DST_ALPHA_CTRL, 0xff, 0),
+   .channel = VOP_REG(RK3288_WIN0_CTRL2, 0xff, 0),
 };
 
 static const struct vop_win_phy rk3288_win23_data = {
-- 
1.9.1


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


[PATCH v6 2/7] drm/rockchip: vop: move write_relaxed flags to vop register

2017-07-25 Thread Mark Yao
Since the drm atomic framework, only a small part of the vop
register needs sync write, Currently seems only following registers
need sync write:
   cfg_done, standby and interrupt related register.

All ctrl registers are using the sync write method that is
inefficient, hardcode the write_relaxed flags to vop registers,
then can only do synchronize write for those actual needed register.

Signed-off-by: Mark Yao 
---
Changes in v6:
- fix compile error

 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 28 ---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h |  1 +
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 42 -
 3 files changed, 36 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 81164d6..a792ea3 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -42,33 +42,27 @@
 #include "rockchip_drm_psr.h"
 #include "rockchip_drm_vop.h"
 
-#define __REG_SET_RELAXED(x, off, mask, shift, v, write_mask) \
-   vop_mask_write(x, off, mask, shift, v, write_mask, true)
-
-#define __REG_SET_NORMAL(x, off, mask, shift, v, write_mask) \
-   vop_mask_write(x, off, mask, shift, v, write_mask, false)
-
-#define REG_SET(x, base, reg, v, mode) \
-   __REG_SET_##mode(x, base + reg.offset, \
-reg.mask, reg.shift, v, reg.write_mask)
-#define REG_SET_MASK(x, base, reg, mask, v, mode) \
-   __REG_SET_##mode(x, base + reg.offset, \
-mask, reg.shift, v, reg.write_mask)
+#define REG_SET(x, base, reg, v) \
+   vop_mask_write(x, base + reg.offset, reg.mask, reg.shift, \
+  v, reg.write_mask, reg.relaxed)
+#define REG_SET_MASK(x, base, reg, mask, v) \
+   vop_mask_write(x, base + reg.offset, \
+  mask, reg.shift, v, reg.write_mask, reg.relaxed)
 
 #define VOP_WIN_SET(x, win, name, v) \
-   REG_SET(x, win->base, win->phy->name, v, RELAXED)
+   REG_SET(x, win->base, win->phy->name, v)
 #define VOP_SCL_SET(x, win, name, v) \
-   REG_SET(x, win->base, win->phy->scl->name, v, RELAXED)
+   REG_SET(x, win->base, win->phy->scl->name, v)
 #define VOP_SCL_SET_EXT(x, win, name, v) \
-   REG_SET(x, win->base, win->phy->scl->ext->name, v, RELAXED)
+   REG_SET(x, win->base, win->phy->scl->ext->name, v)
 #define VOP_CTRL_SET(x, name, v) \
-   REG_SET(x, 0, (x)->data->ctrl->name, v, NORMAL)
+   REG_SET(x, 0, (x)->data->ctrl->name, v)
 
 #define VOP_INTR_GET(vop, name) \
vop_read_reg(vop, 0, &vop->data->ctrl->name)
 
 #define VOP_INTR_SET(vop, name, mask, v) \
-   REG_SET_MASK(vop, 0, vop->data->intr->name, mask, v, NORMAL)
+   REG_SET_MASK(vop, 0, vop->data->intr->name, mask, v)
 #define VOP_INTR_SET_TYPE(vop, name, type, v) \
do { \
int i, reg = 0, mask = 0; \
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
index 084d3b2..056b974 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
@@ -29,6 +29,7 @@ struct vop_reg {
uint32_t shift;
uint32_t mask;
bool write_mask;
+   bool relaxed;
 };
 
 struct vop_ctrl {
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c 
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 58da855..d7974da 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -20,17 +20,23 @@
 #include "rockchip_drm_vop.h"
 #include "rockchip_vop_reg.h"
 
-#define VOP_REG(off, _mask, s) \
-   {.offset = off, \
+#define _VOP_REG(off, _mask, _shift, _write_mask, _relaxed) \
+   { \
+.offset = off, \
 .mask = _mask, \
-.shift = s, \
-.write_mask = false,}
+.shift = _shift, \
+.write_mask = _write_mask, \
+.relaxed = _relaxed, \
+   }
 
-#define VOP_REG_MASK(off, _mask, s) \
-   {.offset = off, \
-.mask = _mask, \
-.shift = s, \
-.write_mask = true,}
+#define VOP_REG(off, _mask, _shift) \
+   _VOP_REG(off, _mask, _shift, false, true)
+
+#define VOP_REG_SYNC(off, _mask, _shift) \
+   _VOP_REG(off, _mask, _shift, false, false)
+
+#define VOP_REG_MASK_SYNC(off, _mask, _shift) \
+   _VOP_REG(off, _mask, _shift, true, false)
 
 static const uint32_t formats_win_full[] = {
DRM_FORMAT_XRGB,
@@ -116,7 +122,7 @@
 };
 
 static const struct vop_ctrl rk3036_ctrl_data = {
-   .standby = VOP_REG(RK3036_SYS_CTRL, 0x1, 30),
+   .standby = VOP_REG_SYNC(RK3036_SYS_CTRL, 0x1, 30),
.o

[PATCH v6 6/7] dt-bindings: display: rockchip: fill Documents for vop series

2017-07-25 Thread Mark Yao
Signed-off-by: Mark Yao 
Acked-by: Rob Herring 
---
Changes in v5:
- clean document commit title
- move changes description out of docummit commit msg

Changes in v2:
- rename rk322x to rk3228
- correct some vop registers define

 Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt | 4 
 1 file changed, 4 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt 
b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
index 9eb3f0a..5d835d9 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
@@ -8,8 +8,12 @@ Required properties:
 - compatible: value should be one of the following
"rockchip,rk3036-vop";
"rockchip,rk3288-vop";
+   "rockchip,rk3368-vop";
+   "rockchip,rk3366-vop";
"rockchip,rk3399-vop-big";
"rockchip,rk3399-vop-lit";
+   "rockchip,rk3228-vop";
+   "rockchip,rk3328-vop";
 
 - interrupts: should contain a list of all VOP IP block interrupts in the
 order: VSYNC, LCD_SYSTEM. The interrupt specifier
-- 
1.9.1


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


[PATCH v6 3/7] drm/rockchip: vop: move line_flag_num to interrupt registers

2017-07-25 Thread Mark Yao
In the hardware design process, the design of line flags
register is associated with the interrupt register,
placing the line flags in the interrupt definition is
more reasonable, and it would make multi-vop define easilier.

Signed-off-by: Mark Yao 
Reviewed-by: Sean Paul 
---
Changes in v6:
- fixes complie error

Changes in v3:
- Explain more in details, introduce why we need this patch

 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 10 +++---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h |  4 ++--
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c |  8 
 3 files changed, 13 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index a792ea3..fd47da5 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -61,8 +61,12 @@
 #define VOP_INTR_GET(vop, name) \
vop_read_reg(vop, 0, &vop->data->ctrl->name)
 
-#define VOP_INTR_SET(vop, name, mask, v) \
+#define VOP_INTR_SET(vop, name, v) \
+   REG_SET(vop, 0, vop->data->intr->name, v)
+
+#define VOP_INTR_SET_MASK(vop, name, mask, v) \
REG_SET_MASK(vop, 0, vop->data->intr->name, mask, v)
+
 #define VOP_INTR_SET_TYPE(vop, name, type, v) \
do { \
int i, reg = 0, mask = 0; \
@@ -72,7 +76,7 @@
mask |= 1 << i; \
} \
} \
-   VOP_INTR_SET(vop, name, mask, reg); \
+   VOP_INTR_SET_MASK(vop, name, mask, reg); \
} while (0)
 #define VOP_INTR_GET_TYPE(vop, name, type) \
vop_get_intr_type(vop, &vop->data->intr->name, type)
@@ -982,7 +986,7 @@ static void vop_crtc_enable(struct drm_crtc *crtc)
VOP_CTRL_SET(vop, vact_st_end, val);
VOP_CTRL_SET(vop, vpost_st_end, val);
 
-   VOP_CTRL_SET(vop, line_flag_num[0], vact_end);
+   VOP_INTR_SET(vop, line_flag_num[0], vact_end);
 
clk_set_rate(vop->dclk, adjusted_mode->clock * 1000);
 
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
index 056b974..850f8e4 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
@@ -60,8 +60,6 @@ struct vop_ctrl {
struct vop_reg hpost_st_end;
struct vop_reg vpost_st_end;
 
-   struct vop_reg line_flag_num[2];
-
struct vop_reg global_regdone_en;
struct vop_reg cfg_done;
 };
@@ -69,6 +67,8 @@ struct vop_ctrl {
 struct vop_intr {
const int *intrs;
uint32_t nintrs;
+
+   struct vop_reg line_flag_num[2];
struct vop_reg enable;
struct vop_reg clear;
struct vop_reg status;
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c 
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index d7974da..0a5f0d2 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -116,6 +116,7 @@
 static const struct vop_intr rk3036_intr = {
.intrs = rk3036_vop_intrs,
.nintrs = ARRAY_SIZE(rk3036_vop_intrs),
+   .line_flag_num[0] = VOP_REG(RK3036_INT_STATUS, 0xfff, 12),
.status = VOP_REG(RK3036_INT_STATUS, 0xf, 0),
.enable = VOP_REG(RK3036_INT_STATUS, 0xf, 4),
.clear = VOP_REG(RK3036_INT_STATUS, 0xf, 8),
@@ -130,7 +131,6 @@
.hact_st_end = VOP_REG(RK3036_DSP_HACT_ST_END, 0x1fff1fff, 0),
.vtotal_pw = VOP_REG(RK3036_DSP_VTOTAL_VS_END, 0x1fff1fff, 0),
.vact_st_end = VOP_REG(RK3036_DSP_VACT_ST_END, 0x1fff1fff, 0),
-   .line_flag_num[0] = VOP_REG(RK3036_INT_STATUS, 0xfff, 12),
.cfg_done = VOP_REG_SYNC(RK3036_REG_CFG_DONE, 0x1, 0),
 };
 
@@ -226,7 +226,6 @@
.vact_st_end = VOP_REG(RK3288_DSP_VACT_ST_END, 0x1fff1fff, 0),
.hpost_st_end = VOP_REG(RK3288_POST_DSP_HACT_INFO, 0x1fff1fff, 0),
.vpost_st_end = VOP_REG(RK3288_POST_DSP_VACT_INFO, 0x1fff1fff, 0),
-   .line_flag_num[0] = VOP_REG(RK3288_INTR_CTRL0, 0x1fff, 12),
.global_regdone_en = VOP_REG(RK3288_SYS_CTRL, 0x1, 11),
.cfg_done = VOP_REG_SYNC(RK3288_REG_CFG_DONE, 0x1, 0),
 };
@@ -258,6 +257,7 @@
 static const struct vop_intr rk3288_vop_intr = {
.intrs = rk3288_vop_intrs,
.nintrs = ARRAY_SIZE(rk3288_vop_intrs),
+   .line_flag_num[0] = VOP_REG(RK3288_INTR_CTRL0, 0x1fff, 12),
.status = VOP_REG(RK3288_INTR_CTRL0, 0xf, 0),
.enable = VOP_REG(RK3288_INTR_CTRL0, 0xf, 4),
.clear = VOP_REG(RK3288_INTR_CTRL0, 0xf, 8),
@@ -294,8 +294,6 @@
.vact_st_end = VOP_REG(RK3399_DSP_VACT_ST_END, 0x1fff1fff, 0),
.hpost_st_end = VOP_REG(RK3399_POST_DSP_HACT_INFO, 0x1fff1fff, 0),
.vpost_st_end = VOP_REG(RK3399_POST_DSP_VACT_INFO, 0x1fff1fff, 0),
-   .line_flag_num[0] = VOP_REG(RK3399_LINE_FLAG, 0x, 0),
-   .line_flag_num[1] = VOP_REG(RK3399_LINE_FLAG, 0x, 16),
.cfg_done = VOP_REG_MASK_SYNC(RK3399_REG_CFG_DONE, 0x1, 0),
 

[PATCH v6 0/7] drm/rockchip: add all full framework vop support

2017-07-25 Thread Mark Yao
These patches try to make all current rockchip full framework vop works
on drm, fill missing vop on full framework.
Vop Full framework now has following vops:
IP versionchipname
  3.1   rk3288
  3.2   rk3368
  3.4   rk3366
  3.5   rk3399 big
  3.6   rk3399 lit
  3.7   rk3228
  3.8   rk3328

Group the vop register, it would make register  definition clearer and
more easily to reuse same group register define for difference vops.

Tested on rk3399 excavator board with kernel 4.13-rc1.

And other chips tested on rockchip kernel 4.4:
   
https://github.com/rockchip-linux/kernel/tree/release-4.4/drivers/gpu/drm/rockchip

Changes in v6:
- fix some patches complie error
- fix rk3036 display blank

Changes in v5:
- clean document commit title
- move changes description out of docummit commit msg

Changes in v4:
- rebase to newest torvalds kernel, fix merge conflict 

Changes in v3:
- group vop register instead using VOP_REG_VER mechanism
- Explain more on patch commit message
- move write_relaxed flags to vop registers
- fix rk3328 overlay abnormal

Changes in v2:
- rename rk322x to rk3228
- correct some vop registers define

Mark Yao (7):
  drm/rockchip: vop: initialize registers directly
  drm/rockchip: vop: move write_relaxed flags to vop register
  drm/rockchip: vop: move line_flag_num to interrupt registers
  drm/rockchip: vop: group vop registers
  drm/rockchip: vop: add a series of vop support
  dt-bindings: display: rockchip: fill Documents for vop series
  drm/rockchip: vop: rk3328: fix overlay abnormal

 .../bindings/display/rockchip/rockchip-vop.txt |   4 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c| 109 ++-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h|  81 +-
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c| 375 ++---
 drivers/gpu/drm/rockchip/rockchip_vop_reg.h| 905 -
 5 files changed, 1075 insertions(+), 399 deletions(-)

-- 
1.9.1


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


[PATCH v6 1/7] drm/rockchip: vop: initialize registers directly

2017-07-25 Thread Mark Yao
At present we are using init_table to initialize some
registers, but the Register init table use un-document define,
it is unreadable, and sometimes we only want to update tiny
bits, init table method is not friendly, it's diffcult to
reuse for difference chips.

To make it clean, initialize registers directly, and drops
init_table mechanism out.

Signed-off-by: Mark Yao 
---
Changes in v6:
- fix rk3036 blank display

Changes in v3:
- Explain more in details

 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  6 ++--
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 10 ++-
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 44 -
 3 files changed, 11 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 5d45033..81164d6 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -1395,7 +1395,6 @@ static void vop_destroy_crtc(struct vop *vop)
 static int vop_initial(struct vop *vop)
 {
const struct vop_data *vop_data = vop->data;
-   const struct vop_reg_data *init_table = vop_data->init_table;
struct reset_control *ahb_rst;
int i, ret;
 
@@ -1455,13 +1454,14 @@ static int vop_initial(struct vop *vop)
 
memcpy(vop->regsbak, vop->regs, vop->len);
 
-   for (i = 0; i < vop_data->table_size; i++)
-   vop_writel(vop, init_table[i].offset, init_table[i].value);
+   VOP_CTRL_SET(vop, global_regdone_en, 1);
+   VOP_CTRL_SET(vop, dsp_blank, 0);
 
for (i = 0; i < vop_data->win_size; i++) {
const struct vop_win_data *win = &vop_data->win[i];
 
VOP_WIN_SET(vop, win, enable, 0);
+   VOP_WIN_SET(vop, win, gate, 1);
}
 
vop_cfg_done(vop);
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
index 9979fd0..084d3b2 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
@@ -24,11 +24,6 @@ enum vop_data_format {
VOP_FMT_YUV444SP,
 };
 
-struct vop_reg_data {
-   uint32_t offset;
-   uint32_t value;
-};
-
 struct vop_reg {
uint32_t offset;
uint32_t shift;
@@ -46,6 +41,7 @@ struct vop_ctrl {
struct vop_reg hdmi_en;
struct vop_reg mipi_en;
struct vop_reg dp_en;
+   struct vop_reg dsp_blank;
struct vop_reg out_mode;
struct vop_reg dither_down;
struct vop_reg dither_up;
@@ -65,6 +61,7 @@ struct vop_ctrl {
 
struct vop_reg line_flag_num[2];
 
+   struct vop_reg global_regdone_en;
struct vop_reg cfg_done;
 };
 
@@ -115,6 +112,7 @@ struct vop_win_phy {
uint32_t nformats;
 
struct vop_reg enable;
+   struct vop_reg gate;
struct vop_reg format;
struct vop_reg rb_swap;
struct vop_reg act_info;
@@ -136,8 +134,6 @@ struct vop_win_data {
 };
 
 struct vop_data {
-   const struct vop_reg_data *init_table;
-   unsigned int table_size;
const struct vop_ctrl *ctrl;
const struct vop_intr *intr;
const struct vop_win_data *win;
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c 
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index bafd698..58da855 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -119,6 +119,7 @@
.standby = VOP_REG(RK3036_SYS_CTRL, 0x1, 30),
.out_mode = VOP_REG(RK3036_DSP_CTRL0, 0xf, 0),
.pin_pol = VOP_REG(RK3036_DSP_CTRL0, 0xf, 4),
+   .dsp_blank = VOP_REG(RK3036_DSP_CTRL1, 0x1, 24),
.htotal_pw = VOP_REG(RK3036_DSP_HTOTAL_HS_END, 0x1fff1fff, 0),
.hact_st_end = VOP_REG(RK3036_DSP_HACT_ST_END, 0x1fff1fff, 0),
.vtotal_pw = VOP_REG(RK3036_DSP_VTOTAL_VS_END, 0x1fff1fff, 0),
@@ -127,13 +128,7 @@
.cfg_done = VOP_REG(RK3036_REG_CFG_DONE, 0x1, 0),
 };
 
-static const struct vop_reg_data rk3036_vop_init_reg_table[] = {
-   {RK3036_DSP_CTRL1, 0x},
-};
-
 static const struct vop_data rk3036_vop = {
-   .init_table = rk3036_vop_init_reg_table,
-   .table_size = ARRAY_SIZE(rk3036_vop_init_reg_table),
.ctrl = &rk3036_ctrl_data,
.intr = &rk3036_intr,
.win = rk3036_vop_win_data,
@@ -193,7 +188,8 @@
 static const struct vop_win_phy rk3288_win23_data = {
.data_formats = formats_win_lite,
.nformats = ARRAY_SIZE(formats_win_lite),
-   .enable = VOP_REG(RK3288_WIN2_CTRL0, 0x1, 0),
+   .enable = VOP_REG(RK3288_WIN2_CTRL0, 0x1, 4),
+   .gate = VOP_REG(RK3288_WIN2_CTRL0, 0x1, 0),
.format = VOP_REG(RK3288_WIN2_CTRL0, 0x7, 1),
.rb_swap = VOP_REG(RK3288_WIN2_CTRL0, 0x1, 12),
.dsp_info = VOP_REG(RK3288_WIN2_DSP_INFO0, 0x0fff0fff, 0),
@@ -215,6 +211,7 @@
.dither_down = VOP_REG(RK3288_DSP_CTRL1, 0xf, 1),
.dither_up = VOP_REG(RK3288_DSP_CTRL1, 0x1, 6),
.data_bl

Re: [PATCH v5 2/7] drm/rockchip: vop: move write_relaxed flags to vop register

2017-07-25 Thread Mark yao

On 2017年07月26日 05:47, Heiko Stuebner wrote:

Hi Mark,

Am Donnerstag, 20. Juli 2017, 10:43:27 CEST schrieb Mark Yao:

Since the drm atomic framework, only a small part of the vop
register needs sync write, Currently seems only following registers
need sync write:
cfg_done, standby and interrupt related register.

All ctrl registers are using the sync write method that is
inefficient, hardcode the write_relaxed flags to vop registers,
then can only do synchronize write for those actual needed register.

Signed-off-by: Mark Yao 
---
  drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 14 +++---
  drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 42 -
  2 files changed, 28 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 81164d6..784a2b7 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -42,18 +42,12 @@
  #include "rockchip_drm_psr.h"
  #include "rockchip_drm_vop.h"
  
-#define __REG_SET_RELAXED(x, off, mask, shift, v, write_mask) \

-   vop_mask_write(x, off, mask, shift, v, write_mask, true)
-
-#define __REG_SET_NORMAL(x, off, mask, shift, v, write_mask) \
-   vop_mask_write(x, off, mask, shift, v, write_mask, false)
-
  #define REG_SET(x, base, reg, v, mode) \
-   __REG_SET_##mode(x, base + reg.offset, \
-reg.mask, reg.shift, v, reg.write_mask)
+   vop_mask_write(x, base + reg.offset, reg.mask, reg.shift, \
+  v, reg.write_mask, reg.relaxed)
  #define REG_SET_MASK(x, base, reg, mask, v, mode) \
-   __REG_SET_##mode(x, base + reg.offset, \
-mask, reg.shift, v, reg.write_mask)
+   vop_mask_write(x, base + reg.offset, \
+  mask, reg.shift, v, reg.write_mask, reg.relaxed)

you only introduce the relaxed element of struct vop_reg in patch4.
So using it here produces a compile error

../drivers/gpu/drm/rockchip/rockchip_drm_vop.c: In function ‘vop_cfg_done’:
../drivers/gpu/drm/rockchip/rockchip_drm_vop.c:47:33: error: ‘const struct 
vop_reg’ has no member named ‘relaxed’
v, reg.write_mask, reg.relaxed)
  ^
../drivers/gpu/drm/rockchip/rockchip_drm_vop.c:59:3: note: in expansion of 
macro ‘REG_SET’
REG_SET(x, 0, (x)->data->ctrl->name, v, NORMAL)
^~~
../drivers/gpu/drm/rockchip/rockchip_drm_vop.c:201:2: note: in expansion of 
macro ‘VOP_CTRL_SET’
   VOP_CTRL_SET(vop, cfg_done, 1);
   ^~~~

when only patches 1+2 are applied. So the relaxed field addition should
definitly move into this patch to not break bisectability.


Heiko





Hi Heiko

Thanks for the test, will fix it at next version.

--
Mark Yao


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


Re: [PATCH v5 3/7] drm/rockchip: vop: move line_flag_num to interrupt registers

2017-07-25 Thread Mark yao

On 2017年07月26日 05:54, Heiko Stuebner wrote:

Hi Mark,

Am Donnerstag, 20. Juli 2017, 10:43:32 CEST schrieb Mark Yao:

In the hardware design process, the design of line flags
register is associated with the interrupt register,
placing the line flags in the interrupt definition is
more reasonable, and it would make multi-vop define easilier.

Changes in v3:
- Explain more in details, introduce why we need this patch

Signed-off-by: Mark Yao 
Reviewed-by: Sean Paul 
---
  drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 2 +-
  drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 4 ++--
  drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 8 
  3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 784a2b7..4f6c7bc 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -982,7 +982,7 @@ static void vop_crtc_enable(struct drm_crtc *crtc)
VOP_CTRL_SET(vop, vact_st_end, val);
VOP_CTRL_SET(vop, vpost_st_end, val);
  
-	VOP_CTRL_SET(vop, line_flag_num[0], vact_end);

+   VOP_INTR_SET(vop, line_flag_num[0], vact_end);

With patches applied up to this one I end up with

   CC [M]  drivers/gpu/drm/rockchip/rockchip_drm_vop.o
../drivers/gpu/drm/rockchip/rockchip_drm_vop.c: In function ‘vop_crtc_enable’:
../drivers/gpu/drm/rockchip/rockchip_drm_vop.c:985:46: error: macro 
"VOP_INTR_SET" requires 4 arguments, but only 3 given
   VOP_INTR_SET(vop, line_flag_num[0], vact_end);
   ^
../drivers/gpu/drm/rockchip/rockchip_drm_vop.c:985:2: error: ‘VOP_INTR_SET’ 
undeclared (first use in this function)
   VOP_INTR_SET(vop, line_flag_num[0], vact_end);
   ^~~~
../drivers/gpu/drm/rockchip/rockchip_drm_vop.c:985:2: note: each undeclared 
identifier is reported only once for each function it appears in

In patch4 you replace this again, with
-   VOP_INTR_SET(vop, line_flag_num[0], vact_end);
+   VOP_REG_SET(vop, intr, line_flag_num[0], vact_end);

but this intermediate breakage should not happen, to keep bisectability.


Heiko




Hi Heiko

Thanks for the test, will fix it at next version.

--
Mark Yao


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


linux-next: unsigned commits in the drm-misc tree

2017-07-25 Thread Stephen Rothwell
Hi all,

I noticed a set of commits that have no Signed-off-by from their
committer:

  d9864a1d2dfc ("drm/stm: drv: Rename platform driver name")

to

  ed34d261a12a ("drm/stm: dsi: Constify phy ops structure")

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


Re: [PATCH v2] drm/hisilicon: fix build error without fbdev emulation

2017-07-25 Thread Daniel Vetter
On Tue, Jul 25, 2017 at 8:05 PM, Arnd Bergmann  wrote:
> We cannot reference priv->fbdev outside of the #ifdef:
>
> drivers/net/virtio_net.c:1881:12: error: 'virtnet_restore_up' defined but not 
> used [-Werror=unused-function]
>  static int virtnet_restore_up(struct virtio_device *vdev)
> drivers/net/virtio_net.c:1859:13: error: 'virtnet_freeze_down' defined but 
> not used [-Werror=unused-function]
>  static void virtnet_freeze_down(struct virtio_device *vdev)
>
> As the #ifdef is a bit annoying here, this removes it entirely
> and uses an IS_ENABLED() check in it place where needed.
>
> Fixes: b4dd9f1ffaba ("drm/hisilicon: Remove custom FB helper deferred setup")
> Signed-off-by: Arnd Bergmann 

I guess I wasn't clear enough, but you don't even need the IS_ENABLED.
The cma_fini/init functions themselves don't get no-opped out (I guess
we could fix that), but the underlying fb helper functions they call
do, so this is all perfectly fine to call unconditionally. And that's
what all other drivers do. Should I edit while applying, or do you
want to respin?

Thanks, Daniel

> ---
>  drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 19 ---
>  drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h |  2 --
>  2 files changed, 8 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c 
> b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
> index 1178341c3858..5d2dfe92f62c 100644
> --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
> +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
> @@ -34,12 +34,11 @@ static int kirin_drm_kms_cleanup(struct drm_device *dev)
>  {
> struct kirin_drm_private *priv = dev->dev_private;
>
> -#ifdef CONFIG_DRM_FBDEV_EMULATION
> -   if (priv->fbdev) {
> +   if (IS_ENABLED(CONFIG_DRM_FBDEV_EMULATION) && priv->fbdev) {
> drm_fbdev_cma_fini(priv->fbdev);
> priv->fbdev = NULL;
> }
> -#endif
> +
> drm_kms_helper_poll_fini(dev);
> dc_ops->cleanup(to_platform_device(dev->dev));
> drm_mode_config_cleanup(dev);
> @@ -49,20 +48,17 @@ static int kirin_drm_kms_cleanup(struct drm_device *dev)
> return 0;
>  }
>
> -#ifdef CONFIG_DRM_FBDEV_EMULATION
>  static void kirin_fbdev_output_poll_changed(struct drm_device *dev)
>  {
> struct kirin_drm_private *priv = dev->dev_private;
>
> drm_fbdev_cma_hotplug_event(priv->fbdev);
>  }
> -#endif
>
>  static const struct drm_mode_config_funcs kirin_drm_mode_config_funcs = {
> .fb_create = drm_fb_cma_create,
> -#ifdef CONFIG_DRM_FBDEV_EMULATION
> -   .output_poll_changed = kirin_fbdev_output_poll_changed,
> -#endif
> +   .output_poll_changed = IS_ENABLED(CONFIG_DRM_FBDEV_EMULATION) ?
> +  kirin_fbdev_output_poll_changed : NULL,
> .atomic_check = drm_atomic_helper_check,
> .atomic_commit = drm_atomic_helper_commit,
>  };
> @@ -121,14 +117,15 @@ static int kirin_drm_kms_init(struct drm_device *dev)
> /* init kms poll for handling hpd */
> drm_kms_helper_poll_init(dev);
>
> -   priv->fbdev = drm_fbdev_cma_init(dev, 32,
> -dev->mode_config.num_connector);
> +   if (IS_ENABLED(CONFIG_DRM_FBDEV_EMULATION))
> +   priv->fbdev = drm_fbdev_cma_init(dev, 32,
> +
> dev->mode_config.num_connector);
> +
> if (IS_ERR(priv->fbdev)) {
> DRM_ERROR("failed to initialize fbdev.\n");
> ret = PTR_ERR(priv->fbdev);
> goto err_cleanup_poll;
> }
> -
> return 0;
>
>  err_cleanup_poll:
> diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h 
> b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
> index 7f60c64915d9..56cb62df065c 100644
> --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
> +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
> @@ -20,9 +20,7 @@ struct kirin_dc_ops {
>  };
>
>  struct kirin_drm_private {
> -#ifdef CONFIG_DRM_FBDEV_EMULATION
> struct drm_fbdev_cma *fbdev;
> -#endif
>  };
>
>  extern const struct kirin_dc_ops ade_dc_ops;
> --
> 2.9.0
>



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


Re: [PATCH v5 1/7] drm/rockchip: vop: initialize registers directly

2017-07-25 Thread Mark yao

On 2017年07月26日 06:36, Heiko Stuebner wrote:

Hi Mark,

Am Donnerstag, 20. Juli 2017, 10:43:22 CEST schrieb Mark Yao:

At present we are using init_table to initialize some
registers, but the Register init table use un-document define,
it is unreadable, and sometimes we only want to update tiny
bits, init table method is not friendly, it's diffcult to
reuse for difference chips.

To make it clean, initialize registers directly, and drops
init_table mechanism out.

Changes in v3:
- Explain more in details

Signed-off-by: Mark Yao 

[...]


diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c 
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index bafd698..00e9d79 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -127,13 +127,7 @@
.cfg_done = VOP_REG(RK3036_REG_CFG_DONE, 0x1, 0),
  };
  
-static const struct vop_reg_data rk3036_vop_init_reg_table[] = {

-   {RK3036_DSP_CTRL1, 0x},
-};
-
  static const struct vop_data rk3036_vop = {
-   .init_table = rk3036_vop_init_reg_table,
-   .table_size = ARRAY_SIZE(rk3036_vop_init_reg_table),
.ctrl = &rk3036_ctrl_data,
.intr = &rk3036_intr,
.win = rk3036_vop_win_data,

This seems to break vop initialization on my rk3036 kylin board.

Before, kylin was able to bring output to the hdmi but with this
patch applied this stops working. As the init-value is to zero it seems
there is still something turned on, that should be turned off instead.

rk3288 seems to stay in working condition though.


Heiko

___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip




Hi Heiko

Thanks for your testing on rk3036 board.

I research the init table on rk3036, the dsp_blank reset value is 1, we need 
set the register to zero.

So I think not working problem can be fixed by following change:

drivers/gpu/drm/rockchip/rockchip_vop_reg.c:
static const struct vop_ctrl rk3036_ctrl_data = {
.standby = VOP_REG(RK3036_SYS_CTRL, 0x1, 30),
+   .dsp_blank = VOP_REG(RK3036_DSP_CTRL1, 0x1, 24),
.out_mode = VOP_REG(RK3036_DSP_CTRL0, 0xf, 0),
.pin_pol = VOP_REG(RK3036_DSP_CTRL0, 0xf, 4),
.htotal_pw = VOP_REG(RK3036_DSP_HTOTAL_HS_END, 0x1fff1fff, 0),

--
Mark Yao


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


Re: [Intel-gfx] [PATCH 6/8] drm: Nuke drm_atomic_helper_connector_set_property

2017-07-25 Thread Maarten Lankhorst
Op 25-07-17 om 10:01 schreef Daniel Vetter:
> It's dead code, the core handles all this directly now. This also
> allows us to unexport drm_atomic_helper_connector_set_property.
>
> The only special case is nouveau which used one function for both
> pre-nv50 legacy modeset code and post-nv50 atomic world instead of 2
> vtables. But amounts to exactly the same.
>
> What is rather strange here is how few drivers set this up, I suspect
> the earlier patch to handle properties in the core did end up fixing a
> pile of possible issues.
Legacy drivers didn't always hook it up either, probably why. :)
No use hooking it up in legacy world if you didn't expose a property.

But yeah, good to fix this.
> Signed-off-by: Daniel Vetter 
> Cc: Daniel Vetter 
> Cc: Jani Nikula 
> Cc: Sean Paul 
> Cc: David Airlie 
> Cc: Ben Skeggs 
> Cc: Benjamin Gaignard 
> Cc: Vincent Abriou 
> Cc: Eric Anholt 
> Cc: intel-...@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> ---
>  drivers/gpu/drm/drm_atomic.c|  3 +-
>  drivers/gpu/drm/drm_atomic_helper.c | 55 
> -
>  drivers/gpu/drm/i915/intel_crt.c|  1 -
>  drivers/gpu/drm/i915/intel_dp.c |  1 -
>  drivers/gpu/drm/i915/intel_dp_mst.c |  1 -
>  drivers/gpu/drm/i915/intel_dsi.c|  1 -
>  drivers/gpu/drm/i915/intel_dvo.c|  1 -
>  drivers/gpu/drm/i915/intel_hdmi.c   |  1 -
>  drivers/gpu/drm/i915/intel_lvds.c   |  1 -
>  drivers/gpu/drm/i915/intel_sdvo.c   |  1 -
>  drivers/gpu/drm/i915/intel_tv.c |  1 -
>  drivers/gpu/drm/nouveau/nouveau_connector.c |  3 --
>  drivers/gpu/drm/nouveau/nv50_display.c  |  1 -
>  drivers/gpu/drm/sti/sti_hdmi.c  |  1 -
>  drivers/gpu/drm/vc4/vc4_vec.c   |  1 -
>  include/drm/drm_atomic.h|  3 --
>  include/drm/drm_atomic_helper.h |  3 --
>  17 files changed, 1 insertion(+), 78 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 395438a7a576..306fdca92abf 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1144,7 +1144,7 @@ EXPORT_SYMBOL(drm_atomic_get_connector_state);
>   * RETURNS:
>   * Zero on success, error code on failure
>   */
> -int drm_atomic_connector_set_property(struct drm_connector *connector,
> +static int drm_atomic_connector_set_property(struct drm_connector *connector,
>   struct drm_connector_state *state, struct drm_property 
> *property,
>   uint64_t val)
>  {
> @@ -1211,7 +1211,6 @@ int drm_atomic_connector_set_property(struct 
> drm_connector *connector,
>  
>   return 0;
>  }
> -EXPORT_SYMBOL(drm_atomic_connector_set_property);
>  
>  static void drm_atomic_connector_print_state(struct drm_printer *p,
>   const struct drm_connector_state *state)
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 0482e39a7889..1ca0dcca6230 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2967,61 +2967,6 @@ int drm_atomic_helper_resume(struct drm_device *dev,
>  }
>  EXPORT_SYMBOL(drm_atomic_helper_resume);
>  
> -/**
> - * drm_atomic_helper_connector_set_property - helper for connector properties
> - * @connector: DRM connector
> - * @property: DRM property
> - * @val: value of property
> - *
> - * Provides a default connector set_property handler using the atomic driver
> - * interface.
> - *
> - * RETURNS:
> - * Zero on success, error code on failure
> - */
> -int
> -drm_atomic_helper_connector_set_property(struct drm_connector *connector,
> - struct drm_property *property,
> - uint64_t val)
> -{
> - struct drm_atomic_state *state;
> - struct drm_connector_state *connector_state;
> - int ret = 0;
> -
> - state = drm_atomic_state_alloc(connector->dev);
> - if (!state)
> - return -ENOMEM;
> -
> - /* ->set_property is always called with all locks held. */
> - state->acquire_ctx = connector->dev->mode_config.acquire_ctx;
> -retry:
> - connector_state = drm_atomic_get_connector_state(state, connector);
> - if (IS_ERR(connector_state)) {
> - ret = PTR_ERR(connector_state);
> - goto fail;
> - }
> -
> - ret = drm_atomic_connector_set_property(connector, connector_state,
> - property, val);
> - if (ret)
> - goto fail;
> -
> - ret = drm_atomic_commit(state);
> -fail:
> - if (ret == -EDEADLK)
> - goto backoff;
> -
> - drm_atomic_state_put(state);
> - return ret;
> -
> -backoff:
> - drm_atomic_state_clear(state);
> - drm_atomic_legacy_backoff(state);
> -
> - goto retry;
> -}
> -EXPORT_SYMBOL(drm_atomic_helper_connector_set_property);
> -
>  static int page_flip_common(struct drm_atomic_state *state,
>

[PATCH] drm/amd/powerplay: rv: Use designated initializers

2017-07-25 Thread Kees Cook
As done for vega10 in commit 3ddd396f6b57 ("drm/amd/powerplay: Use
designated initializers") mark other tableFunction entries with designated
initializers. The randstruct plugin requires designated initializers for
structures that are entirely function pointers.

Cc: Rex Zhu 
Cc: Hawking Zhang 
Cc: Alex Deucher 
Signed-off-by: Kees Cook 
---
If I can get an Ack for this, I'll carry it in the gcc-plugins tree, unless
you think this is worth landing for v4.13, in which case, please take it
now. :)

Thanks!
---
 drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c
index 4c7f430b36eb..8e6cfd89c7e0 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c
@@ -308,8 +308,8 @@ static int rv_tf_set_num_active_display(struct pp_hwmgr 
*hwmgr, void *input,
 }
 
 static const struct phm_master_table_item rv_set_power_state_list[] = {
-   { NULL, rv_tf_set_clock_limit },
-   { NULL, rv_tf_set_num_active_display },
+   { .tableFunction = rv_tf_set_clock_limit },
+   { .tableFunction = rv_tf_set_num_active_display },
{ }
 };
 
@@ -382,7 +382,7 @@ static int rv_tf_disable_gfx_off(struct pp_hwmgr *hwmgr,
 }
 
 static const struct phm_master_table_item rv_disable_dpm_list[] = {
-   {NULL, rv_tf_disable_gfx_off},
+   { .tableFunction = rv_tf_disable_gfx_off },
{ },
 };
 
@@ -407,7 +407,7 @@ static int rv_tf_enable_gfx_off(struct pp_hwmgr *hwmgr,
 }
 
 static const struct phm_master_table_item rv_enable_dpm_list[] = {
-   {NULL, rv_tf_enable_gfx_off},
+   { .tableFunction = rv_tf_enable_gfx_off },
{ },
 };
 
-- 
2.7.4


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


[RESEND PATCH v2 2/2] drm/exynos/decon: Add include guard to the Exynos7 header

2017-07-25 Thread Krzysztof Kozlowski
Although header is included only once but still having an include guard
is a good practice.  To avoid confusion, add SoC prefix to existing
Exynos5433 header include guard.

Signed-off-by: Krzysztof Kozlowski 

---

Changes since v1:
1. Just re-order patches in patchset and slightly adjust include guard
   name.
---
 drivers/gpu/drm/exynos/regs-decon5433.h | 6 +++---
 drivers/gpu/drm/exynos/regs-decon7.h| 5 +
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/regs-decon5433.h 
b/drivers/gpu/drm/exynos/regs-decon5433.h
index 78957c9626f5..19ad9e47945e 100644
--- a/drivers/gpu/drm/exynos/regs-decon5433.h
+++ b/drivers/gpu/drm/exynos/regs-decon5433.h
@@ -6,8 +6,8 @@
  * published by the Free Software Foundationr
  */
 
-#ifndef EXYNOS_REGS_DECON_H
-#define EXYNOS_REGS_DECON_H
+#ifndef EXYNOS_REGS_DECON5433_H
+#define EXYNOS_REGS_DECON5433_H
 
 /* Exynos543X DECON */
 #define DECON_VIDCON0  0x
@@ -206,4 +206,4 @@
 #define CRCCTRL_CRCEN  (0x1 << 0)
 #define CRCCTRL_MASK   (0x7)
 
-#endif /* EXYNOS_REGS_DECON_H */
+#endif /* EXYNOS_REGS_DECON5433_H */
diff --git a/drivers/gpu/drm/exynos/regs-decon7.h 
b/drivers/gpu/drm/exynos/regs-decon7.h
index 339ea1007ff5..5df7765d2397 100644
--- a/drivers/gpu/drm/exynos/regs-decon7.h
+++ b/drivers/gpu/drm/exynos/regs-decon7.h
@@ -8,6 +8,9 @@
  * option) any later version.
  */
 
+#ifndef EXYNOS_REGS_DECON7_H
+#define EXYNOS_REGS_DECON7_H
+
 /* VIDCON0 */
 #define VIDCON00x00
 
@@ -346,3 +349,5 @@
 
 #define DECON_UPDATE_SLAVE_SYNC(1 << 4)
 #define DECON_UPDATE_STANDALONE_F  (1 << 0)
+
+#endif /* EXYNOS_REGS_DECON7_H */
-- 
2.7.4

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


Re: iMac 10,1 with Ubuntu 16.04: black screen after suspend

2017-07-25 Thread Florian Echtler
On 25.07.2017 07:14, Mario Kleiner wrote:
> On 07/24/2017 03:45 PM, Florian Echtler wrote:
> 
> That's the same here with my patch applied. After a suspend -> resume, the
> internal panel stays black, the patch doesn't help for that. Somethig i didn't
> notice btw., apparently i never suspend->resumed it.

OK - I'm guessing if the panel/connector mess gets properly sorted out in
general, then it will probably also start working after suspend/resume...

> The internal panel always works during boot, until the radeon kms driver loads
> and modesetting gets initialized, then the panel goes dark.

Weirdly enough, this is now the behaviour I'm getting, too, no matter if I use
the patched driver or the original one. So there's definitely some bit of
persistent state somewhere that got flipped during experimentation, probably
inside that stupid SMC.

> Without my patch the internal panel stays dark, but plugging in an external
> hdmi/dvi display gets both internal+external to light up.
> 
> Another way i was able to force the internal panel to stay on without my patch
> and without an external display connected is to use the kernel cmdline option
> "video=DP-1:2560x1440D" to force the external output on, although nothing is
> connected.

None of the video options, either with "DP" or "eDP", made a difference in my
case. The one scenario where I suddenly got the internal panel to turn on was
when I plugged in a DP _source_ (my laptop). Also caused the same DP link train
error messages to appear in dmesg.

> So the same machine model behaves differently with the same patch, and worse 
> in
> your case than without it? Maybe different hardware or firmware?
> 
> Apples website lists two models of late 2009 iMac10,1 and Radeon HD 4670, to
> which the patch should apply. One 21.5 inch model without TDM and a 27 inch
> model with TDM. Mine is the 27 inch one. I assume yours as well due to TDM?
> Attached is the output of dmidecode on mine, not sure what to look for for
> differences?

Yes, also 27 inch. I've compared the dmidecode output, only notable differences
are data from RAM modules, so it's the same machine and same FW versions.

> Also attached a dmesg snippet for comparison wrt. SMBIOS version etc.

Nearly everything identical, except my dmesg doesn't show the following lines:

-[0.00] efi: EFI v1.10 by Apple
-[0.00] efi:  ACPI=0xbfeee000  ACPI 2.0=0xbfeee014  SMBIOS=0xbfec4000

I'm booting Linux via rEFIt, so I would have assumed that it's a "regular" EFI
boot, but apparently not. What's your boot configuration?

> Lukas idea that some hardware mux gets switched into the wrong position on
> models with TDM sounds pretty appealing to me, but how to test?

I'm using TDM regularly; interestingly enough, this works completely reliably,
even if the panel was dark before. My code is at
https://github.com/floe/smc_util if you want to give it a try, but apparently
there's more to it than just the two keys (MVMR/MVHR) which I'm currently using.

Maybe you can run smc_dump_linux.sh on your machine (should be safe, only reads
keys) and see if there's some difference between keys depending on what state
the panel is in?

Best, Florian
-- 
SENT FROM MY DEC VT50 TERMINAL



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


[RESEND PATCH v2 1/2] drm/exynos/decon: Move headers from global to local place

2017-07-25 Thread Krzysztof Kozlowski
The DECON headers contain only defines for registers.  There are no
other drivers using them so this should be put locally to the Exynos DRM
driver.  Keeping headers local helps managing the code.

Suggested-by: Marek Szyprowski 
Signed-off-by: Krzysztof Kozlowski 

---

Changes since v1:
1. Just re-order patches in patchset.
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c  | 3 +--
 drivers/gpu/drm/exynos/exynos7_drm_decon.c | 2 +-
 .../exynos5433_decon.h => drivers/gpu/drm/exynos/regs-decon5433.h  | 0
 include/video/exynos7_decon.h => drivers/gpu/drm/exynos/regs-decon7.h  | 3 +--
 4 files changed, 3 insertions(+), 5 deletions(-)
 rename include/video/exynos5433_decon.h => 
drivers/gpu/drm/exynos/regs-decon5433.h (100%)
 rename include/video/exynos7_decon.h => drivers/gpu/drm/exynos/regs-decon7.h 
(99%)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 5792ca88ab7a..5aca8c16f2bc 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -19,13 +19,12 @@
 #include 
 #include 
 
-#include 
-
 #include "exynos_drm_drv.h"
 #include "exynos_drm_crtc.h"
 #include "exynos_drm_fb.h"
 #include "exynos_drm_plane.h"
 #include "exynos_drm_iommu.h"
+#include "regs-decon5433.h"
 
 #define DSD_CFG_MUX 0x1004
 #define DSD_CFG_MUX_TE_UNMASK_GLOBAL BIT(13)
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 3e88269fdc2e..387e436c97d2 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -25,13 +25,13 @@
 
 #include 
 #include 
-#include 
 
 #include "exynos_drm_crtc.h"
 #include "exynos_drm_plane.h"
 #include "exynos_drm_drv.h"
 #include "exynos_drm_fb.h"
 #include "exynos_drm_iommu.h"
+#include "regs-decon7.h"
 
 /*
  * DECON stands for Display and Enhancement controller.
diff --git a/include/video/exynos5433_decon.h 
b/drivers/gpu/drm/exynos/regs-decon5433.h
similarity index 100%
rename from include/video/exynos5433_decon.h
rename to drivers/gpu/drm/exynos/regs-decon5433.h
diff --git a/include/video/exynos7_decon.h 
b/drivers/gpu/drm/exynos/regs-decon7.h
similarity index 99%
rename from include/video/exynos7_decon.h
rename to drivers/gpu/drm/exynos/regs-decon7.h
index a62b11b613f6..339ea1007ff5 100644
--- a/include/video/exynos7_decon.h
+++ b/drivers/gpu/drm/exynos/regs-decon7.h
@@ -1,5 +1,4 @@
-/* include/video/exynos7_decon.h
- *
+/*
  * Copyright (c) 2014 Samsung Electronics Co., Ltd.
  * Author: Ajay Kumar 
  *
-- 
2.7.4

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


Re: [PATCH v5 1/7] drm/rockchip: vop: initialize registers directly

2017-07-25 Thread Heiko Stuebner
Hi Mark,

Am Donnerstag, 20. Juli 2017, 10:43:22 CEST schrieb Mark Yao:
> At present we are using init_table to initialize some
> registers, but the Register init table use un-document define,
> it is unreadable, and sometimes we only want to update tiny
> bits, init table method is not friendly, it's diffcult to
> reuse for difference chips.
> 
> To make it clean, initialize registers directly, and drops
> init_table mechanism out.
> 
> Changes in v3:
> - Explain more in details
> 
> Signed-off-by: Mark Yao 

[...]

> diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c 
> b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
> index bafd698..00e9d79 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
> @@ -127,13 +127,7 @@
>   .cfg_done = VOP_REG(RK3036_REG_CFG_DONE, 0x1, 0),
>  };
>  
> -static const struct vop_reg_data rk3036_vop_init_reg_table[] = {
> - {RK3036_DSP_CTRL1, 0x},
> -};
> -
>  static const struct vop_data rk3036_vop = {
> - .init_table = rk3036_vop_init_reg_table,
> - .table_size = ARRAY_SIZE(rk3036_vop_init_reg_table),
>   .ctrl = &rk3036_ctrl_data,
>   .intr = &rk3036_intr,
>   .win = rk3036_vop_win_data,

This seems to break vop initialization on my rk3036 kylin board.

Before, kylin was able to bring output to the hdmi but with this
patch applied this stops working. As the init-value is to zero it seems
there is still something turned on, that should be turned off instead.

rk3288 seems to stay in working condition though.


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


Re: [PATCH v5 3/7] drm/rockchip: vop: move line_flag_num to interrupt registers

2017-07-25 Thread Heiko Stuebner
Hi Mark,

Am Donnerstag, 20. Juli 2017, 10:43:32 CEST schrieb Mark Yao:
> In the hardware design process, the design of line flags
> register is associated with the interrupt register,
> placing the line flags in the interrupt definition is
> more reasonable, and it would make multi-vop define easilier.
> 
> Changes in v3:
> - Explain more in details, introduce why we need this patch
> 
> Signed-off-by: Mark Yao 
> Reviewed-by: Sean Paul 
> ---
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 2 +-
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 4 ++--
>  drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 8 
>  3 files changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index 784a2b7..4f6c7bc 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -982,7 +982,7 @@ static void vop_crtc_enable(struct drm_crtc *crtc)
>   VOP_CTRL_SET(vop, vact_st_end, val);
>   VOP_CTRL_SET(vop, vpost_st_end, val);
>  
> - VOP_CTRL_SET(vop, line_flag_num[0], vact_end);
> + VOP_INTR_SET(vop, line_flag_num[0], vact_end);

With patches applied up to this one I end up with

  CC [M]  drivers/gpu/drm/rockchip/rockchip_drm_vop.o
../drivers/gpu/drm/rockchip/rockchip_drm_vop.c: In function ‘vop_crtc_enable’:
../drivers/gpu/drm/rockchip/rockchip_drm_vop.c:985:46: error: macro 
"VOP_INTR_SET" requires 4 arguments, but only 3 given
  VOP_INTR_SET(vop, line_flag_num[0], vact_end);
  ^
../drivers/gpu/drm/rockchip/rockchip_drm_vop.c:985:2: error: ‘VOP_INTR_SET’ 
undeclared (first use in this function)
  VOP_INTR_SET(vop, line_flag_num[0], vact_end);
  ^~~~
../drivers/gpu/drm/rockchip/rockchip_drm_vop.c:985:2: note: each undeclared 
identifier is reported only once for each function it appears in

In patch4 you replace this again, with 
-   VOP_INTR_SET(vop, line_flag_num[0], vact_end);
+   VOP_REG_SET(vop, intr, line_flag_num[0], vact_end);

but this intermediate breakage should not happen, to keep bisectability.


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


Re: [PATCH v5 2/7] drm/rockchip: vop: move write_relaxed flags to vop register

2017-07-25 Thread Heiko Stuebner
Hi Mark,

Am Donnerstag, 20. Juli 2017, 10:43:27 CEST schrieb Mark Yao:
> Since the drm atomic framework, only a small part of the vop
> register needs sync write, Currently seems only following registers
> need sync write:
>cfg_done, standby and interrupt related register.
> 
> All ctrl registers are using the sync write method that is
> inefficient, hardcode the write_relaxed flags to vop registers,
> then can only do synchronize write for those actual needed register.
> 
> Signed-off-by: Mark Yao 
> ---
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 14 +++---
>  drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 42 
> -
>  2 files changed, 28 insertions(+), 28 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index 81164d6..784a2b7 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -42,18 +42,12 @@
>  #include "rockchip_drm_psr.h"
>  #include "rockchip_drm_vop.h"
>  
> -#define __REG_SET_RELAXED(x, off, mask, shift, v, write_mask) \
> - vop_mask_write(x, off, mask, shift, v, write_mask, true)
> -
> -#define __REG_SET_NORMAL(x, off, mask, shift, v, write_mask) \
> - vop_mask_write(x, off, mask, shift, v, write_mask, false)
> -
>  #define REG_SET(x, base, reg, v, mode) \
> - __REG_SET_##mode(x, base + reg.offset, \
> -  reg.mask, reg.shift, v, reg.write_mask)
> + vop_mask_write(x, base + reg.offset, reg.mask, reg.shift, \
> +v, reg.write_mask, reg.relaxed)
>  #define REG_SET_MASK(x, base, reg, mask, v, mode) \
> - __REG_SET_##mode(x, base + reg.offset, \
> -  mask, reg.shift, v, reg.write_mask)
> + vop_mask_write(x, base + reg.offset, \
> +mask, reg.shift, v, reg.write_mask, reg.relaxed)

you only introduce the relaxed element of struct vop_reg in patch4.
So using it here produces a compile error

../drivers/gpu/drm/rockchip/rockchip_drm_vop.c: In function ‘vop_cfg_done’:
../drivers/gpu/drm/rockchip/rockchip_drm_vop.c:47:33: error: ‘const struct 
vop_reg’ has no member named ‘relaxed’
   v, reg.write_mask, reg.relaxed)
 ^
../drivers/gpu/drm/rockchip/rockchip_drm_vop.c:59:3: note: in expansion of 
macro ‘REG_SET’
   REG_SET(x, 0, (x)->data->ctrl->name, v, NORMAL)
   ^~~
../drivers/gpu/drm/rockchip/rockchip_drm_vop.c:201:2: note: in expansion of 
macro ‘VOP_CTRL_SET’
  VOP_CTRL_SET(vop, cfg_done, 1);
  ^~~~

when only patches 1+2 are applied. So the relaxed field addition should
definitly move into this patch to not break bisectability.


Heiko

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


Re: [PATCH 1/3] drm: Widen vblank count to 64 bits. Change vblank time precision to ns

2017-07-25 Thread Keith Packard
Daniel Vetter  writes:

> I'd drop that part (but keep 64 everywhere else ofc).

Yeah, we only ever ask drivers for a delta anyways, so keeping an
internal 64-bit value while retaining the 32-bit driver API is
easy to manage.

>> > Other thought on this, since you bother to change all the types: Afaik
>> > both timespec and timeval suffer from the 32bit issues.
>> 
>> I'm not sure what 32bit issues you're concerned about here? We don't
>> compare these values, just report them up to user space.
>
> Year 2038 32bit wrap-around bug. Yes I believe/fear drm will still be
> around then :-)

A fine point. I've switched to ktime_t, which has additional benefits in
making the internal interfaces a bit cleaner with pass-by-value possible
in more cases now.

I've pushed incremental patches out for all of the suggested changes to
my drm-sequence-64 branch. I think I'll send those out as incremental
patches and then also send out a squashed version from the original
branch point.

-- 
-keith


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


[Bug 99136] Blood Effects corrupt graphics in Total War: Warhammer

2017-07-25 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=99136

Marek Olšák  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|REOPENED|RESOLVED

--- Comment #42 from Marek Olšák  ---
(In reply to Alexandr Zelinsky from comment #41)
> its not mesa bug
> its known bug in cracked release by razor1911

Closing without a fix because we refuse to support cracked games. Feel free to
re-open the bug if you encounter this issue on a legal version of the game.
Thanks.

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


[Bug 101900] No HDMI HBR audio on Polaris (no TrueHD, no Atmos, no Neo:X, no HD Master audio)

2017-07-25 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=101900

Direx  changed:

   What|Removed |Added

Summary|No HDMI audio on Polaris|No HDMI HBR audio on
   ||Polaris (no TrueHD, no
   ||Atmos, no Neo:X, no HD
   ||Master audio)

--- Comment #3 from Direx  ---
OK, it seems I tested with the wrong file. PCM is working fine, the issue is
just related to HBR audio.

This is my observation:

- Stereo and 5.1 PCM are working
- Dolby Digial and DTS are working

- Dolby TrueHD is not working
- DTS HD Master Audio is not working
- Dolby Atmos is not working
- DTS:X is not working

I have updated the title of the bug to make clear that this is about high
bitrate audio. I have also tested the suggested patch, but it does not change
anything (neither positive nor negative).

I also turned on my PC speakers which are connected to my internal Intel HDA
device and made a funny observation: when I am playing HBR audio there is some
bad noise coming from them, although the passthrough device is set to HDMI1.

My audio player is Kodi (ALSA backend) on Arch Linux.

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


Re: [PATCH] vc4: Add an ioctl for labeling GEM BOs for summary stats

2017-07-25 Thread Eric Anholt
Chris Wilson  writes:

> Quoting Eric Anholt (2017-06-22 21:50:54)
>> This has proven immensely useful for debugging memory leaks and
>> overallocation (which is a rather serious concern on the platform,
>> given that we typically run at about 256MB of CMA out of up to 1GB
>> total memory, with framebuffers that are about 8MB ecah).
>> 
>> The state of the art without this is to dump debug logs from every GL
>> application, guess as to kernel allocations based on bo_stats, and try
>> to merge that all together into a global picture of memory allocation
>> state.  With this, you can add a couple of calls to the debug build of
>> the 3D driver and get a pretty detailed view of GPU memory usage from
>> /debug/dri/0/bo_stats (or when we debug print to dmesg on allocation
>> failure).
>> 
>> The Mesa side currently labels at the gallium resource level (so you
>> see that a 1920x20 pixmap has been created, presumably for the window
>> system panel), but we could extend that to be even more useful with
>> glObjectLabel() names being sent all the way down to the kernel.
>> 
>> (partial) example of sorted debugfs output with Mesa labeling all
>> resources:
>> 
>>kernel BO cache:  16392kb BOs (3)
>>tiling shadow 1920x1080:   8160kb BOs (1)
>>resource 1920x1080@32/0:   8160kb BOs (1)
>> scanout resource 1920x1080@32/0:   8100kb BOs (1)
>> kernel:   8100kb BOs (1)
>> 
>> Signed-off-by: Eric Anholt 
>> ---
>
>>  static void vc4_bo_stats_dump(struct vc4_dev *vc4)
>>  {
>
> Now unused?

Still used from the splat when CMA allocation fails.  It's less
catastrophic than it used to be, but still bad, so we're dumping to
dmesg for now.

>> -   DRM_INFO("num bos allocated: %d\n",
>> -vc4->bo_stats.num_allocated);
>> -   DRM_INFO("size bos allocated: %dkb\n",
>> -vc4->bo_stats.size_allocated / 1024);
>> -   DRM_INFO("num bos used: %d\n",
>> -vc4->bo_stats.num_allocated - vc4->bo_stats.num_cached);
>> -   DRM_INFO("size bos used: %dkb\n",
>> -(vc4->bo_stats.size_allocated -
>> - vc4->bo_stats.size_cached) / 1024);
>> -   DRM_INFO("num bos cached: %d\n",
>> -vc4->bo_stats.num_cached);
>> -   DRM_INFO("size bos cached: %dkb\n",
>> -vc4->bo_stats.size_cached / 1024);
>> +   int i;
>> +
>> +   for (i = 0; i < vc4->num_labels; i++) {
>> +   if (!vc4->bo_labels[i].num_allocated)
>> +   continue;
>> +
>> +   DRM_INFO("%30s: %6dkb BOs (%d)\n",
>> +vc4->bo_labels[i].name,
>> +vc4->bo_labels[i].size_allocated / 1024,
>> +vc4->bo_labels[i].num_allocated);
>> +   }
>>  }
>>  
>>  #ifdef CONFIG_DEBUG_FS
>
>> +/* Must be called with bo_lock held. */
>> +static void vc4_bo_set_label(struct drm_gem_object *gem_obj, int label)
>> +{
>> +   struct vc4_bo *bo = to_vc4_bo(gem_obj);
>> +   struct vc4_dev *vc4 = to_vc4_dev(gem_obj->dev);
>
> lockdep_assert_held(&vc4->bo_lock);

Nice.  I've converted the other instances of this comment, too.

>> +
>> +   vc4->bo_labels[label].num_allocated++;
>> +   vc4->bo_labels[label].size_allocated += gem_obj->size;
>
> This gets called with label=-1 on destroy.

Oh, good catch, thanks.  This code got reworked a couple of times and I
lost that check.

>> +   vc4->bo_labels[bo->label].num_allocated--;
>> +   vc4->bo_labels[bo->label].size_allocated -= gem_obj->size;
>
> Ok, preassigned to TYPE_KERNEL on creation.
>
>> +   if (vc4->bo_labels[bo->label].num_allocated == 0 &&
>> +   is_user_label(bo->label)) {
>> +   /* Free user BO label slots on last unreference. */
>> +   kfree(vc4->bo_labels[bo->label].name);
>> +   vc4->bo_labels[bo->label].name = NULL;
>> +   }
>
> This seems dubious. As a user I would expect the label I created to last
> until I closed the fd. Otherwise if I ever close all bo of one type,
> wait a few seconds for the cache to be reaped, then reallocate a new bo,
> someone else may have assigned my label a new name.
>
> If that's guarded against, a comment would help.

Userspace can't see the label index, though, and can only set string
names on BOs.  New text:

/* Free user BO label slots on last unreference.
 * Slots are just where we track the stats for a given
 * name, and once a name is unused we can reuse that
 * slot.
 */

>> +
>> +   bo->label = label;
>> +}
>
>> +int vc4_label_bo_ioctl(struct drm_device *dev, void *data,
>> +  struct drm_file *file_priv)
>> +{
>> +   struct vc4_dev *vc4 = to_vc4_dev(dev);
>> +   struct drm_vc4_label_bo *args = data;
>> +   char *name;
>> +   struct drm_gem_object *gem_obj;
>> +   int ret = 0, label;
>> +
>> +   name = kmalloc(args->len + 1

[PATCH v2 2/3] drm/vc4: Add an ioctl for labeling GEM BOs for summary stats

2017-07-25 Thread Eric Anholt
This has proven immensely useful for debugging memory leaks and
overallocation (which is a rather serious concern on the platform,
given that we typically run at about 256MB of CMA out of up to 1GB
total memory, with framebuffers that are about 8MB ecah).

The state of the art without this is to dump debug logs from every GL
application, guess as to kernel allocations based on bo_stats, and try
to merge that all together into a global picture of memory allocation
state.  With this, you can add a couple of calls to the debug build of
the 3D driver and get a pretty detailed view of GPU memory usage from
/debug/dri/0/bo_stats (or when we debug print to dmesg on allocation
failure).

The Mesa side currently labels at the gallium resource level (so you
see that a 1920x20 pixmap has been created, presumably for the window
system panel), but we could extend that to be even more useful with
glObjectLabel() names being sent all the way down to the kernel.

(partial) example of sorted debugfs output with Mesa labeling all
resources:

   kernel BO cache:  16392kb BOs (3)
   tiling shadow 1920x1080:   8160kb BOs (1)
   resource 1920x1080@32/0:   8160kb BOs (1)
scanout resource 1920x1080@32/0:   8100kb BOs (1)
kernel:   8100kb BOs (1)

v2: Use strndup_user(), use lockdep assertion instead of just a
comment, fix an array[-1] reference, extend comment about name
freeing.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_bo.c| 258 
 drivers/gpu/drm/vc4/vc4_drv.c   |   8 +-
 drivers/gpu/drm/vc4/vc4_drv.h   |  39 +-
 drivers/gpu/drm/vc4/vc4_gem.c   |   2 +-
 drivers/gpu/drm/vc4/vc4_render_cl.c |   2 +-
 drivers/gpu/drm/vc4/vc4_v3d.c   |   3 +-
 include/uapi/drm/vc4_drm.h  |  11 ++
 7 files changed, 257 insertions(+), 66 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
index 487f96412d35..f4387e1e178d 100644
--- a/drivers/gpu/drm/vc4/vc4_bo.c
+++ b/drivers/gpu/drm/vc4/vc4_bo.c
@@ -24,21 +24,35 @@
 #include "vc4_drv.h"
 #include "uapi/drm/vc4_drm.h"
 
+static const char * const bo_type_names[] = {
+   "kernel",
+   "V3D",
+   "V3D shader",
+   "dumb",
+   "binner",
+   "RCL",
+   "BCL",
+   "kernel BO cache",
+};
+
+static bool is_user_label(int label)
+{
+   return label >= VC4_BO_TYPE_COUNT;
+}
+
 static void vc4_bo_stats_dump(struct vc4_dev *vc4)
 {
-   DRM_INFO("num bos allocated: %d\n",
-vc4->bo_stats.num_allocated);
-   DRM_INFO("size bos allocated: %dkb\n",
-vc4->bo_stats.size_allocated / 1024);
-   DRM_INFO("num bos used: %d\n",
-vc4->bo_stats.num_allocated - vc4->bo_stats.num_cached);
-   DRM_INFO("size bos used: %dkb\n",
-(vc4->bo_stats.size_allocated -
- vc4->bo_stats.size_cached) / 1024);
-   DRM_INFO("num bos cached: %d\n",
-vc4->bo_stats.num_cached);
-   DRM_INFO("size bos cached: %dkb\n",
-vc4->bo_stats.size_cached / 1024);
+   int i;
+
+   for (i = 0; i < vc4->num_labels; i++) {
+   if (!vc4->bo_labels[i].num_allocated)
+   continue;
+
+   DRM_INFO("%30s: %6dkb BOs (%d)\n",
+vc4->bo_labels[i].name,
+vc4->bo_labels[i].size_allocated / 1024,
+vc4->bo_labels[i].num_allocated);
+   }
 }
 
 #ifdef CONFIG_DEBUG_FS
@@ -47,30 +61,103 @@ int vc4_bo_stats_debugfs(struct seq_file *m, void *unused)
struct drm_info_node *node = (struct drm_info_node *)m->private;
struct drm_device *dev = node->minor->dev;
struct vc4_dev *vc4 = to_vc4_dev(dev);
-   struct vc4_bo_stats stats;
+   int i;
 
-   /* Take a snapshot of the current stats with the lock held. */
mutex_lock(&vc4->bo_lock);
-   stats = vc4->bo_stats;
+   for (i = 0; i < vc4->num_labels; i++) {
+   if (!vc4->bo_labels[i].num_allocated)
+   continue;
+
+   seq_printf(m, "%30s: %6dkb BOs (%d)\n",
+  vc4->bo_labels[i].name,
+  vc4->bo_labels[i].size_allocated / 1024,
+  vc4->bo_labels[i].num_allocated);
+   }
mutex_unlock(&vc4->bo_lock);
 
-   seq_printf(m, "num bos allocated: %d\n",
-  stats.num_allocated);
-   seq_printf(m, "size bos allocated: %dkb\n",
-  stats.size_allocated / 1024);
-   seq_printf(m, "num bos used: %d\n",
-  stats.num_allocated - stats.num_cached);
-   seq_printf(m, "size bos used: %dkb\n",
-  (stats.size_allocated - stats.size_cached) / 1024);
-   seq_printf(m, "num bos cached: %d\n",
-  stats.num_cached);
-   seq_printf(m, "size bos cached: %dkb\n",
-  stats.size_cached / 1024);
-
retu

[PATCH v2 1/3] drm/vc4: Start using u64_to_user_ptr.

2017-07-25 Thread Eric Anholt
Chris Wilson pointed out this little cleanup in a review of new code,
so let's fix up the code I was copying from.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_gem.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
index d5b821ad06af..595f93f57821 100644
--- a/drivers/gpu/drm/vc4/vc4_gem.c
+++ b/drivers/gpu/drm/vc4/vc4_gem.c
@@ -119,7 +119,7 @@ vc4_get_hang_state_ioctl(struct drm_device *dev, void *data,
bo_state[i].size = vc4_bo->base.base.size;
}
 
-   if (copy_to_user((void __user *)(uintptr_t)get_state->bo,
+   if (copy_to_user(u64_to_user_ptr(get_state->bo),
 bo_state,
 state->bo_count * sizeof(*bo_state)))
ret = -EFAULT;
@@ -678,8 +678,7 @@ vc4_cl_lookup_bos(struct drm_device *dev,
goto fail;
}
 
-   if (copy_from_user(handles,
-  (void __user *)(uintptr_t)args->bo_handles,
+   if (copy_from_user(handles, u64_to_user_ptr(args->bo_handles),
   exec->bo_count * sizeof(uint32_t))) {
ret = -EFAULT;
DRM_ERROR("Failed to copy in GEM handles\n");
@@ -755,21 +754,21 @@ vc4_get_bcl(struct drm_device *dev, struct vc4_exec_info 
*exec)
exec->shader_state_size = args->shader_rec_count;
 
if (copy_from_user(bin,
-  (void __user *)(uintptr_t)args->bin_cl,
+  u64_to_user_ptr(args->bin_cl),
   args->bin_cl_size)) {
ret = -EFAULT;
goto fail;
}
 
if (copy_from_user(exec->shader_rec_u,
-  (void __user *)(uintptr_t)args->shader_rec,
+  u64_to_user_ptr(args->shader_rec),
   args->shader_rec_size)) {
ret = -EFAULT;
goto fail;
}
 
if (copy_from_user(exec->uniforms_u,
-  (void __user *)(uintptr_t)args->uniforms,
+  u64_to_user_ptr(args->uniforms),
   args->uniforms_size)) {
ret = -EFAULT;
goto fail;
-- 
2.11.0

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


[PATCH v2 3/3] drm/vc4: Convert more lock requirement comments to lockdep assertions.

2017-07-25 Thread Eric Anholt
Since I do my development with lockdep on, this will help make sure I
don't introduce bugs here.

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

diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
index f4387e1e178d..b24dd8685590 100644
--- a/drivers/gpu/drm/vc4/vc4_bo.c
+++ b/drivers/gpu/drm/vc4/vc4_bo.c
@@ -163,10 +163,12 @@ static uint32_t bo_page_index(size_t size)
return (size / PAGE_SIZE) - 1;
 }
 
-/* Must be called with bo_lock held. */
 static void vc4_bo_destroy(struct vc4_bo *bo)
 {
struct drm_gem_object *obj = &bo->base.base;
+   struct vc4_dev *vc4 = to_vc4_dev(obj->dev);
+
+   lockdep_assert_held(&vc4->bo_lock);
 
vc4_bo_set_label(obj, -1);
 
@@ -181,9 +183,11 @@ static void vc4_bo_destroy(struct vc4_bo *bo)
drm_gem_cma_free_object(obj);
 }
 
-/* Must be called with bo_lock held. */
 static void vc4_bo_remove_from_cache(struct vc4_bo *bo)
 {
+   struct vc4_dev *vc4 = to_vc4_dev(bo->base.base.dev);
+
+   lockdep_assert_held(&vc4->bo_lock);
list_del(&bo->unref_head);
list_del(&bo->size_head);
 }
@@ -367,12 +371,13 @@ int vc4_dumb_create(struct drm_file *file_priv,
return ret;
 }
 
-/* Must be called with bo_lock held. */
 static void vc4_bo_cache_free_old(struct drm_device *dev)
 {
struct vc4_dev *vc4 = to_vc4_dev(dev);
unsigned long expire_time = jiffies - msecs_to_jiffies(1000);
 
+   lockdep_assert_held(&vc4->bo_lock);
+
while (!list_empty(&vc4->bo_cache.time_list)) {
struct vc4_bo *bo = list_last_entry(&vc4->bo_cache.time_list,
struct vc4_bo, unref_head);
-- 
2.11.0

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


[PATCH v2] drm/hisilicon: fix build error without fbdev emulation

2017-07-25 Thread Arnd Bergmann
We cannot reference priv->fbdev outside of the #ifdef:

drivers/net/virtio_net.c:1881:12: error: 'virtnet_restore_up' defined but not 
used [-Werror=unused-function]
 static int virtnet_restore_up(struct virtio_device *vdev)
drivers/net/virtio_net.c:1859:13: error: 'virtnet_freeze_down' defined but not 
used [-Werror=unused-function]
 static void virtnet_freeze_down(struct virtio_device *vdev)

As the #ifdef is a bit annoying here, this removes it entirely
and uses an IS_ENABLED() check in it place where needed.

Fixes: b4dd9f1ffaba ("drm/hisilicon: Remove custom FB helper deferred setup")
Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 19 ---
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h |  2 --
 2 files changed, 8 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
index 1178341c3858..5d2dfe92f62c 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
@@ -34,12 +34,11 @@ static int kirin_drm_kms_cleanup(struct drm_device *dev)
 {
struct kirin_drm_private *priv = dev->dev_private;
 
-#ifdef CONFIG_DRM_FBDEV_EMULATION
-   if (priv->fbdev) {
+   if (IS_ENABLED(CONFIG_DRM_FBDEV_EMULATION) && priv->fbdev) {
drm_fbdev_cma_fini(priv->fbdev);
priv->fbdev = NULL;
}
-#endif
+
drm_kms_helper_poll_fini(dev);
dc_ops->cleanup(to_platform_device(dev->dev));
drm_mode_config_cleanup(dev);
@@ -49,20 +48,17 @@ static int kirin_drm_kms_cleanup(struct drm_device *dev)
return 0;
 }
 
-#ifdef CONFIG_DRM_FBDEV_EMULATION
 static void kirin_fbdev_output_poll_changed(struct drm_device *dev)
 {
struct kirin_drm_private *priv = dev->dev_private;
 
drm_fbdev_cma_hotplug_event(priv->fbdev);
 }
-#endif
 
 static const struct drm_mode_config_funcs kirin_drm_mode_config_funcs = {
.fb_create = drm_fb_cma_create,
-#ifdef CONFIG_DRM_FBDEV_EMULATION
-   .output_poll_changed = kirin_fbdev_output_poll_changed,
-#endif
+   .output_poll_changed = IS_ENABLED(CONFIG_DRM_FBDEV_EMULATION) ?
+  kirin_fbdev_output_poll_changed : NULL,
.atomic_check = drm_atomic_helper_check,
.atomic_commit = drm_atomic_helper_commit,
 };
@@ -121,14 +117,15 @@ static int kirin_drm_kms_init(struct drm_device *dev)
/* init kms poll for handling hpd */
drm_kms_helper_poll_init(dev);
 
-   priv->fbdev = drm_fbdev_cma_init(dev, 32,
-dev->mode_config.num_connector);
+   if (IS_ENABLED(CONFIG_DRM_FBDEV_EMULATION))
+   priv->fbdev = drm_fbdev_cma_init(dev, 32,
+
dev->mode_config.num_connector);
+
if (IS_ERR(priv->fbdev)) {
DRM_ERROR("failed to initialize fbdev.\n");
ret = PTR_ERR(priv->fbdev);
goto err_cleanup_poll;
}
-
return 0;
 
 err_cleanup_poll:
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
index 7f60c64915d9..56cb62df065c 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
@@ -20,9 +20,7 @@ struct kirin_dc_ops {
 };
 
 struct kirin_drm_private {
-#ifdef CONFIG_DRM_FBDEV_EMULATION
struct drm_fbdev_cma *fbdev;
-#endif
 };
 
 extern const struct kirin_dc_ops ade_dc_ops;
-- 
2.9.0

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


Re: [PATCH] drm/hisilicon: fix build error without fbdev emulation

2017-07-25 Thread Arnd Bergmann
On Tue, Jul 25, 2017 at 5:53 PM, Daniel Vetter  wrote:
> On Tue, Jul 25, 2017 at 05:33:25PM +0200, Arnd Bergmann wrote:

>>  drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 5 -
>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c 
>> b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
>> index 1178341c3858..d48102d1a7a4 100644
>> --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
>> +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
>> @@ -121,6 +121,7 @@ static int kirin_drm_kms_init(struct drm_device *dev)
>>   /* init kms poll for handling hpd */
>>   drm_kms_helper_poll_init(dev);
>>
>> +#ifdef CONFIG_DRM_FBDEV_EMULATION
>>   priv->fbdev = drm_fbdev_cma_init(dev, 32,
>>dev->mode_config.num_connector);
>>   if (IS_ERR(priv->fbdev)) {
>> @@ -128,11 +129,13 @@ static int kirin_drm_kms_init(struct drm_device *dev)
>>   ret = PTR_ERR(priv->fbdev);
>>   goto err_cleanup_poll;
>>   }
>> -
>> +#endif
>
> Could we instead stop compling out priv->fbdev? There's nothing
> driver-specific here, so teh #ifdef are kinda annoying ...

Yes, I guess that would be better, I just didn't want to do too much
of a rework. If we remove the #ifdef here, we should replace all
instances in that driver.

I'll send a patch to do that and let you pick which one you apply.

> And saving that one pointer in a really huge structure is somewhat silly.

It looks like it's the only member in that structure, but that doesn't
make a big difference either, since there is only one instance in
the system.

>> +#ifdef CONFIG_DRM_FBDEV_EMULATION
>>  err_cleanup_poll:
>>   drm_kms_helper_poll_fini(dev);
>
> poll helpers aren't fbdev specific. Why do we need this? Is this just to
> shut up gcc?

Yes, gcc warns about the unused label here otherwise.

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


Re: [PATCH] vc4: Add an ioctl for labeling GEM BOs for summary stats

2017-07-25 Thread Chris Wilson
Quoting Eric Anholt (2017-06-22 21:50:54)
> This has proven immensely useful for debugging memory leaks and
> overallocation (which is a rather serious concern on the platform,
> given that we typically run at about 256MB of CMA out of up to 1GB
> total memory, with framebuffers that are about 8MB ecah).
> 
> The state of the art without this is to dump debug logs from every GL
> application, guess as to kernel allocations based on bo_stats, and try
> to merge that all together into a global picture of memory allocation
> state.  With this, you can add a couple of calls to the debug build of
> the 3D driver and get a pretty detailed view of GPU memory usage from
> /debug/dri/0/bo_stats (or when we debug print to dmesg on allocation
> failure).
> 
> The Mesa side currently labels at the gallium resource level (so you
> see that a 1920x20 pixmap has been created, presumably for the window
> system panel), but we could extend that to be even more useful with
> glObjectLabel() names being sent all the way down to the kernel.
> 
> (partial) example of sorted debugfs output with Mesa labeling all
> resources:
> 
>kernel BO cache:  16392kb BOs (3)
>tiling shadow 1920x1080:   8160kb BOs (1)
>resource 1920x1080@32/0:   8160kb BOs (1)
> scanout resource 1920x1080@32/0:   8100kb BOs (1)
> kernel:   8100kb BOs (1)
> 
> Signed-off-by: Eric Anholt 
> ---

>  static void vc4_bo_stats_dump(struct vc4_dev *vc4)
>  {

Now unused?

> -   DRM_INFO("num bos allocated: %d\n",
> -vc4->bo_stats.num_allocated);
> -   DRM_INFO("size bos allocated: %dkb\n",
> -vc4->bo_stats.size_allocated / 1024);
> -   DRM_INFO("num bos used: %d\n",
> -vc4->bo_stats.num_allocated - vc4->bo_stats.num_cached);
> -   DRM_INFO("size bos used: %dkb\n",
> -(vc4->bo_stats.size_allocated -
> - vc4->bo_stats.size_cached) / 1024);
> -   DRM_INFO("num bos cached: %d\n",
> -vc4->bo_stats.num_cached);
> -   DRM_INFO("size bos cached: %dkb\n",
> -vc4->bo_stats.size_cached / 1024);
> +   int i;
> +
> +   for (i = 0; i < vc4->num_labels; i++) {
> +   if (!vc4->bo_labels[i].num_allocated)
> +   continue;
> +
> +   DRM_INFO("%30s: %6dkb BOs (%d)\n",
> +vc4->bo_labels[i].name,
> +vc4->bo_labels[i].size_allocated / 1024,
> +vc4->bo_labels[i].num_allocated);
> +   }
>  }
>  
>  #ifdef CONFIG_DEBUG_FS

> +/* Must be called with bo_lock held. */
> +static void vc4_bo_set_label(struct drm_gem_object *gem_obj, int label)
> +{
> +   struct vc4_bo *bo = to_vc4_bo(gem_obj);
> +   struct vc4_dev *vc4 = to_vc4_dev(gem_obj->dev);

lockdep_assert_held(&vc4->bo_lock);

> +
> +   vc4->bo_labels[label].num_allocated++;
> +   vc4->bo_labels[label].size_allocated += gem_obj->size;

This gets called with label=-1 on destroy.

> +   vc4->bo_labels[bo->label].num_allocated--;
> +   vc4->bo_labels[bo->label].size_allocated -= gem_obj->size;

Ok, preassigned to TYPE_KERNEL on creation.

> +   if (vc4->bo_labels[bo->label].num_allocated == 0 &&
> +   is_user_label(bo->label)) {
> +   /* Free user BO label slots on last unreference. */
> +   kfree(vc4->bo_labels[bo->label].name);
> +   vc4->bo_labels[bo->label].name = NULL;
> +   }

This seems dubious. As a user I would expect the label I created to last
until I closed the fd. Otherwise if I ever close all bo of one type,
wait a few seconds for the cache to be reaped, then reallocate a new bo,
someone else may have assigned my label a new name.

If that's guarded against, a comment would help.

> +
> +   bo->label = label;
> +}

> +int vc4_label_bo_ioctl(struct drm_device *dev, void *data,
> +  struct drm_file *file_priv)
> +{
> +   struct vc4_dev *vc4 = to_vc4_dev(dev);
> +   struct drm_vc4_label_bo *args = data;
> +   char *name;
> +   struct drm_gem_object *gem_obj;
> +   int ret = 0, label;
> +
> +   name = kmalloc(args->len + 1, GFP_KERNEL);
> +   if (!name)
> +   return -ENOMEM;
> +
> +   if (copy_from_user(name, (void __user *)(uintptr_t)args->name,
> +  args->len)) {
> +   kfree(name);
> +   return -EFAULT;
> +   }
> +   name[args->len] = 0;

if (!args->len)
return -EINVAL;

name = strndup_user(u64_to_user_ptr(args->name), args->len + 1);
if (IS_ERR(name))
return PTR_ERR(name);
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/stm: fix warning about multiplication in condition

2017-07-25 Thread Philippe CORNU


On 07/25/2017 05:40 PM, Arnd Bergmann wrote:
> gcc-7 complains about multiplying within a condition being
> suspicious:
> 
> drivers/gpu/drm/stm/dw_mipi_dsi-stm.c: In function 'dsi_pll_get_clkout_khz':
> drivers/gpu/drm/stm/dw_mipi_dsi-stm.c:117:10: error: '*' in boolean context, 
> suggest '&&' instead [-Werror=int-in-bool-context]
> 
> The code here is correct, but can be easily rephrased to make
> that more obvious. I also swap out the error handling and the normal
> code path for clarity.

Hi Arnd,
And many thanks for this new & much better code.

Acked-by: Philippe Cornu 
Tested-by: Philippe Cornu 

Philippe :-)

> 
> Fixes: b0f09a3c69d9 ("drm/stm: Add STM32 DSI controller driver")
> Signed-off-by: Arnd Bergmann 
> ---
>   drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 8 +---
>   1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c 
> b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> index 568c5d0461ea..e5b6310240fe 100644
> --- a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> +++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> @@ -113,11 +113,13 @@ static enum dsi_color dsi_color_from_mipi(enum 
> mipi_dsi_pixel_format fmt)
>   
>   static int dsi_pll_get_clkout_khz(int clkin_khz, int idf, int ndiv, int odf)
>   {
> + int divisor = idf * odf;
> +
>   /* prevent from division by 0 */
> - if (idf * odf)
> - return DIV_ROUND_CLOSEST(clkin_khz * ndiv, idf * odf);
> + if (!divisor)
> + return 0;
>   
> - return 0;
> + return DIV_ROUND_CLOSEST(clkin_khz * ndiv, divisor);
>   }
>   
>   static int dsi_pll_get_params(int clkin_khz, int clkout_khz,
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] vc4: Add an ioctl for labeling GEM BOs for summary stats

2017-07-25 Thread Eric Anholt
Eric Anholt  writes:

> This has proven immensely useful for debugging memory leaks and
> overallocation (which is a rather serious concern on the platform,
> given that we typically run at about 256MB of CMA out of up to 1GB
> total memory, with framebuffers that are about 8MB ecah).

I'm still interested in merging this patch if someone can ack.


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


[PATCH 1/2] drm/vc4: Demote user-accessible DRM_ERROR paths to DRM_DEBUG.

2017-07-25 Thread Eric Anholt
Userspace shouldn't be able to spam dmesg by passing bad arguments.
This has particularly become an issues since we started using a bad
argument to set_tiling to detect if set_tiling was supported.

Signed-off-by: Eric Anholt 
Fixes: 83753117f1de ("drm/vc4: Add get/set tiling ioctls.")
---
 drivers/gpu/drm/vc4/vc4_bo.c   | 14 +++---
 drivers/gpu/drm/vc4/vc4_gem.c  | 10 ++--
 drivers/gpu/drm/vc4/vc4_kms.c  |  2 +-
 drivers/gpu/drm/vc4/vc4_render_cl.c| 40 +++
 drivers/gpu/drm/vc4/vc4_validate.c | 78 +++---
 drivers/gpu/drm/vc4/vc4_validate_shaders.c | 72 +--
 6 files changed, 108 insertions(+), 108 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
index 487f96412d35..ede80199001d 100644
--- a/drivers/gpu/drm/vc4/vc4_bo.c
+++ b/drivers/gpu/drm/vc4/vc4_bo.c
@@ -389,7 +389,7 @@ vc4_prime_export(struct drm_device *dev, struct 
drm_gem_object *obj, int flags)
struct vc4_bo *bo = to_vc4_bo(obj);
 
if (bo->validated_shader) {
-   DRM_ERROR("Attempting to export shader BO\n");
+   DRM_DEBUG("Attempting to export shader BO\n");
return ERR_PTR(-EINVAL);
}
 
@@ -410,7 +410,7 @@ int vc4_mmap(struct file *filp, struct vm_area_struct *vma)
bo = to_vc4_bo(gem_obj);
 
if (bo->validated_shader && (vma->vm_flags & VM_WRITE)) {
-   DRM_ERROR("mmaping of shader BOs for writing not allowed.\n");
+   DRM_DEBUG("mmaping of shader BOs for writing not allowed.\n");
return -EINVAL;
}
 
@@ -435,7 +435,7 @@ int vc4_prime_mmap(struct drm_gem_object *obj, struct 
vm_area_struct *vma)
struct vc4_bo *bo = to_vc4_bo(obj);
 
if (bo->validated_shader && (vma->vm_flags & VM_WRITE)) {
-   DRM_ERROR("mmaping of shader BOs for writing not allowed.\n");
+   DRM_DEBUG("mmaping of shader BOs for writing not allowed.\n");
return -EINVAL;
}
 
@@ -447,7 +447,7 @@ void *vc4_prime_vmap(struct drm_gem_object *obj)
struct vc4_bo *bo = to_vc4_bo(obj);
 
if (bo->validated_shader) {
-   DRM_ERROR("mmaping of shader BOs not allowed.\n");
+   DRM_DEBUG("mmaping of shader BOs not allowed.\n");
return ERR_PTR(-EINVAL);
}
 
@@ -501,7 +501,7 @@ int vc4_mmap_bo_ioctl(struct drm_device *dev, void *data,
 
gem_obj = drm_gem_object_lookup(file_priv, args->handle);
if (!gem_obj) {
-   DRM_ERROR("Failed to look up GEM BO %d\n", args->handle);
+   DRM_DEBUG("Failed to look up GEM BO %d\n", args->handle);
return -EINVAL;
}
 
@@ -605,7 +605,7 @@ int vc4_set_tiling_ioctl(struct drm_device *dev, void *data,
 
gem_obj = drm_gem_object_lookup(file_priv, args->handle);
if (!gem_obj) {
-   DRM_ERROR("Failed to look up GEM BO %d\n", args->handle);
+   DRM_DEBUG("Failed to look up GEM BO %d\n", args->handle);
return -ENOENT;
}
bo = to_vc4_bo(gem_obj);
@@ -636,7 +636,7 @@ int vc4_get_tiling_ioctl(struct drm_device *dev, void *data,
 
gem_obj = drm_gem_object_lookup(file_priv, args->handle);
if (!gem_obj) {
-   DRM_ERROR("Failed to look up GEM BO %d\n", args->handle);
+   DRM_DEBUG("Failed to look up GEM BO %d\n", args->handle);
return -ENOENT;
}
bo = to_vc4_bo(gem_obj);
diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
index d5b821ad06af..a3e45e67f417 100644
--- a/drivers/gpu/drm/vc4/vc4_gem.c
+++ b/drivers/gpu/drm/vc4/vc4_gem.c
@@ -659,7 +659,7 @@ vc4_cl_lookup_bos(struct drm_device *dev,
/* See comment on bo_index for why we have to check
 * this.
 */
-   DRM_ERROR("Rendering requires BOs to validate\n");
+   DRM_DEBUG("Rendering requires BOs to validate\n");
return -EINVAL;
}
 
@@ -691,7 +691,7 @@ vc4_cl_lookup_bos(struct drm_device *dev,
struct drm_gem_object *bo = idr_find(&file_priv->object_idr,
 handles[i]);
if (!bo) {
-   DRM_ERROR("Failed to look up GEM BO %d: %d\n",
+   DRM_DEBUG("Failed to look up GEM BO %d: %d\n",
  i, handles[i]);
ret = -EINVAL;
spin_unlock(&file_priv->table_lock);
@@ -729,7 +729,7 @@ vc4_get_bcl(struct drm_device *dev, struct vc4_exec_info 
*exec)
args->shader_rec_count >= (UINT_MAX /
  sizeof(struct vc4_shader_state)) ||
temp_size < exec_size) {
-   DRM_ERROR("overflow in exec arguments\n");
+   DRM_DEBUG("overflow in exec arguments\n");
   

[PATCH 2/2] drm/vc4: Add exec flags to allow forcing a specific X/Y tile walk order.

2017-07-25 Thread Eric Anholt
This is useful to allow GL to provide defined results for overlapping
glBlitFramebuffer, which X11 in turn uses to accelerate uncomposited
window movement without first blitting to a temporary.  x11perf
-copywinwin100 goes from 1850/sec to 4850/sec.

Signed-off-by: Eric Anholt 
---

The work-in-progress userspace is at:

https://github.com/anholt/xserver/commits/glamor-draw-bounds-overlap
https://github.com/anholt/mesa/commits/vc4-overlapping-blit

and the next step is to build the GL extension spec and piglit tests
for it.

 drivers/gpu/drm/vc4/vc4_drv.c   |  1 +
 drivers/gpu/drm/vc4/vc4_gem.c   |  5 -
 drivers/gpu/drm/vc4/vc4_render_cl.c | 21 -
 include/uapi/drm/vc4_drm.h  | 11 +++
 4 files changed, 32 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index c6b487c3d2b7..b5c2c28289ed 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -99,6 +99,7 @@ static int vc4_get_param_ioctl(struct drm_device *dev, void 
*data,
case DRM_VC4_PARAM_SUPPORTS_BRANCHES:
case DRM_VC4_PARAM_SUPPORTS_ETC1:
case DRM_VC4_PARAM_SUPPORTS_THREADED_FS:
+   case DRM_VC4_PARAM_SUPPORTS_FIXED_RCL_ORDER:
args->value = true;
break;
default:
diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
index a3e45e67f417..ba0782ebda34 100644
--- a/drivers/gpu/drm/vc4/vc4_gem.c
+++ b/drivers/gpu/drm/vc4/vc4_gem.c
@@ -1008,7 +1008,10 @@ vc4_submit_cl_ioctl(struct drm_device *dev, void *data,
struct ww_acquire_ctx acquire_ctx;
int ret = 0;
 
-   if ((args->flags & ~VC4_SUBMIT_CL_USE_CLEAR_COLOR) != 0) {
+   if ((args->flags & ~(VC4_SUBMIT_CL_USE_CLEAR_COLOR |
+VC4_SUBMIT_CL_FIXED_RCL_ORDER |
+VC4_SUBMIT_CL_RCL_ORDER_INCREASING_X |
+VC4_SUBMIT_CL_RCL_ORDER_INCREASING_Y)) != 0) {
DRM_DEBUG("Unknown flags: 0x%02x\n", args->flags);
return -EINVAL;
}
diff --git a/drivers/gpu/drm/vc4/vc4_render_cl.c 
b/drivers/gpu/drm/vc4/vc4_render_cl.c
index da3bfd53f0bd..c3b064052147 100644
--- a/drivers/gpu/drm/vc4/vc4_render_cl.c
+++ b/drivers/gpu/drm/vc4/vc4_render_cl.c
@@ -261,8 +261,17 @@ static int vc4_create_rcl_bo(struct drm_device *dev, 
struct vc4_exec_info *exec,
uint8_t max_y_tile = args->max_y_tile;
uint8_t xtiles = max_x_tile - min_x_tile + 1;
uint8_t ytiles = max_y_tile - min_y_tile + 1;
-   uint8_t x, y;
+   uint8_t xi, yi;
uint32_t size, loop_body_size;
+   bool positive_x = false;
+   bool positive_y = false;
+
+   if (args->flags & VC4_SUBMIT_CL_FIXED_RCL_ORDER) {
+   if (args->flags & VC4_SUBMIT_CL_RCL_ORDER_INCREASING_X)
+   positive_x = true;
+   if (args->flags & VC4_SUBMIT_CL_RCL_ORDER_INCREASING_Y)
+   positive_y = true;
+   }
 
size = VC4_PACKET_TILE_RENDERING_MODE_CONFIG_SIZE;
loop_body_size = VC4_PACKET_TILE_COORDINATES_SIZE;
@@ -354,10 +363,12 @@ static int vc4_create_rcl_bo(struct drm_device *dev, 
struct vc4_exec_info *exec,
rcl_u16(setup, args->height);
rcl_u16(setup, args->color_write.bits);
 
-   for (y = min_y_tile; y <= max_y_tile; y++) {
-   for (x = min_x_tile; x <= max_x_tile; x++) {
-   bool first = (x == min_x_tile && y == min_y_tile);
-   bool last = (x == max_x_tile && y == max_y_tile);
+   for (yi = 0; yi < ytiles; yi++) {
+   int y = positive_y ? min_y_tile + yi : max_y_tile - yi;
+   for (xi = 0; xi < xtiles; xi++) {
+   int x = positive_x ? min_x_tile + xi : max_x_tile - xi;
+   bool first = (xi == 0 && yi == 0);
+   bool last = (xi == xtiles - 1 && yi == ytiles - 1);
 
emit_tile(exec, setup, x, y, first, last);
}
diff --git a/include/uapi/drm/vc4_drm.h b/include/uapi/drm/vc4_drm.h
index 6ac4c5c014cb..a8bf9a76d5b6 100644
--- a/include/uapi/drm/vc4_drm.h
+++ b/include/uapi/drm/vc4_drm.h
@@ -153,6 +153,16 @@ struct drm_vc4_submit_cl {
__u32 pad:24;
 
 #define VC4_SUBMIT_CL_USE_CLEAR_COLOR  (1 << 0)
+/* By default, the kernel gets to choose the order that the tiles are
+ * rendered in.  If this is set, then the tiles will be rendered in a
+ * raster order, with the right-to-left vs left-to-right and
+ * top-to-bottom vs bottom-to-top dictated by
+ * VC4_SUBMIT_CL_RCL_ORDER_INCREASING_*.  This allows overlapping
+ * blits to be implemented using the 3D engine.
+ */
+#define VC4_SUBMIT_CL_FIXED_RCL_ORDER  (1 << 1)
+#define VC4_SUBMIT_CL_RCL_ORDER_INCREASING_X   (1 << 2)
+#define VC4_SUBMIT_CL_RCL_ORDER_INCREASING_Y   (1 << 3)
__u32 flags;
 
/* Returned value of

Re: [PATCH] drm/hisilicon: fix build error without fbdev emulation

2017-07-25 Thread Daniel Vetter
On Tue, Jul 25, 2017 at 05:33:25PM +0200, Arnd Bergmann wrote:
> We cannot reference priv->fbdev outside of the #ifdef:
> 
> drivers/net/virtio_net.c:1881:12: error: 'virtnet_restore_up' defined but not 
> used [-Werror=unused-function]
>  static int virtnet_restore_up(struct virtio_device *vdev)
> drivers/net/virtio_net.c:1859:13: error: 'virtnet_freeze_down' defined but 
> not used [-Werror=unused-function]
>  static void virtnet_freeze_down(struct virtio_device *vdev)
> 
> Since the code is moved into the main probe function now, this
> adds another #ifdef.
> 
> Fixes: b4dd9f1ffaba ("drm/hisilicon: Remove custom FB helper deferred setup")
> Signed-off-by: Arnd Bergmann 

Thanks for catching this.

> ---
>  drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c 
> b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
> index 1178341c3858..d48102d1a7a4 100644
> --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
> +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
> @@ -121,6 +121,7 @@ static int kirin_drm_kms_init(struct drm_device *dev)
>   /* init kms poll for handling hpd */
>   drm_kms_helper_poll_init(dev);
>  
> +#ifdef CONFIG_DRM_FBDEV_EMULATION
>   priv->fbdev = drm_fbdev_cma_init(dev, 32,
>dev->mode_config.num_connector);
>   if (IS_ERR(priv->fbdev)) {
> @@ -128,11 +129,13 @@ static int kirin_drm_kms_init(struct drm_device *dev)
>   ret = PTR_ERR(priv->fbdev);
>   goto err_cleanup_poll;
>   }
> -
> +#endif

Could we instead stop compling out priv->fbdev? There's nothing
driver-specific here, so teh #ifdef are kinda annoying ... And saving that
one pointer in a really huge structure is somewhat silly.

>   return 0;
>  
> +#ifdef CONFIG_DRM_FBDEV_EMULATION
>  err_cleanup_poll:
>   drm_kms_helper_poll_fini(dev);

poll helpers aren't fbdev specific. Why do we need this? Is this just to
shut up gcc?

Thanks, Daniel

> +#endif
>  err_unbind_all:
>   component_unbind_all(dev->dev, dev);
>  err_dc_cleanup:
> -- 
> 2.9.0
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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


Re: [PATCH] drm/stm: fix warning about multiplication in condition

2017-07-25 Thread Joe Perches
On Tue, 2017-07-25 at 17:40 +0200, Arnd Bergmann wrote:
> gcc-7 complains about multiplying within a condition being
> suspicious:
> 
> drivers/gpu/drm/stm/dw_mipi_dsi-stm.c: In function 'dsi_pll_get_clkout_khz':
> drivers/gpu/drm/stm/dw_mipi_dsi-stm.c:117:10: error: '*' in boolean context, 
> suggest '&&' instead [-Werror=int-in-bool-context]
> 
> The code here is correct, but can be easily rephrased to make
> that more obvious. I also swap out the error handling and the normal
> code path for clarity.

Thanks, the new code does read much better.

> diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c 
> b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
[]
> @@ -113,11 +113,13 @@ static enum dsi_color dsi_color_from_mipi(enum 
> mipi_dsi_pixel_format fmt)
>  
>  static int dsi_pll_get_clkout_khz(int clkin_khz, int idf, int ndiv, int odf)
>  {
> + int divisor = idf * odf;
> +
>   /* prevent from division by 0 */
> - if (idf * odf)
> - return DIV_ROUND_CLOSEST(clkin_khz * ndiv, idf * odf);
> + if (!divisor)
> + return 0;
>  
> - return 0;
> + return DIV_ROUND_CLOSEST(clkin_khz * ndiv, divisor);
>  }
>  
>  static int dsi_pll_get_params(int clkin_khz, int clkout_khz,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 1/2] drm/edid: Add helper to detect whether EDID changed

2017-07-25 Thread Daniel Vetter
On Tue, Jul 25, 2017 at 03:18:04PM +0300, Paul Kocialkowski wrote:
> On Tue, 2017-07-25 at 10:16 +0200, Daniel Vetter wrote:
> > On Tue, Jul 25, 2017 at 10:58:55AM +0300, Paul Kocialkowski wrote:
> > > On Tue, 2017-07-25 at 09:34 +0200, Daniel Vetter wrote:
> > > > On Tue, Jul 25, 2017 at 9:25 AM, Paul Kocialkowski
> > > >  wrote:
> > > > > On Tue, 2017-07-25 at 08:53 +0200, Daniel Vetter wrote:
> > > > > > On Mon, Jul 24, 2017 at 05:54:46PM +0300, Paul Kocialkowski
> > > > > > wrote:
> > > > > > > This adds a common drm helper to detect whether the EDID
> > > > > > > changed
> > > > > > > from
> > > > > > > the last known cached one. This is useful help detect that a
> > > > > > > monitor
> > > > > > > was
> > > > > > > changed during a suspend/resume cycle.
> > > > > > > 
> > > > > > > When that happens (a monitor is replaced by another one
> > > > > > > during
> > > > > > > suspend),
> > > > > > > no hotplug event will be triggered so the change will not be
> > > > > > > caught
> > > > > > > at
> > > > > > > resume time. Detecting that the EDID changed allows
> > > > > > > detecting
> > > > > > > it.
> > > > > > > 
> > > > > > > Signed-off-by: Paul Kocialkowski  > > > > > > tel.
> > > > > > > com>
> > > > > > 
> > > > > > I can't find the older mails I've typed about this, but the
> > > > > > plan
> > > > > > we've
> > > > > > discussed a while back was:
> > > > > > - Add a generational counter to each connector, maybe even
> > > > > > expose
> > > > > > it
> > > > > > to
> > > > > >   userspace.
> > > > > > 
> > > > > > - Increment that counter every time something changed, e.g.
> > > > > >   connector->status in the propbe helpers, or when attaching a
> > > > > > new
> > > > > > edid
> > > > > >   with the set_edid helper.
> > > > > > 
> > > > > > - Tada, no changes needed to drivers, and easily extensible to
> > > > > > other
> > > > > >   things than edid!
> > > > > 
> > > > > I don't see how it solves the problem here though. After a
> > > > > suspend/resume cycle, there is simply no indication that
> > > > > anything
> > > > > has
> > > > > changed when a monitor was replaced by another one, so I don't
> > > > > see
> > > > > how
> > > > > adding a counter in the mix would help.
> > > > > 
> > > > > Could you provide more details about the reasoning? I feel like
> > > > > I'm
> > > > > missing something here.
> > > > 
> > > > Your bug doesn't just exist over s/r, it's just much easier to
> > > > observe
> > > > in s/r since users can take however long they want to with
> > > > plugging in
> > > > a different monitor. But the same issue exists e.g. when we go
> > > > from
> > > > hpd to polling because too much noise on the line.
> > > > 
> > > > Wrt the suspend/resume issue: What we need to do on resume is do a
> > > > full reprobe of all outputs, in an async worker. Telling userspace
> > > > to
> > > > do this by sending an uevent was the cheapest way, but it'd be
> > > > better
> > > > if the kernel could do that asynchronously and inform userspace
> > > > about
> > > > the exact changes. And there's more to reprobe than just the edid,
> > > > and
> > > > we don't want to re-invent a separate reprobe path just for resume
> > > > like you start in your patch series. So yeah my plan was missing:
> > > > 
> > > > - force a full async reprobe after resume (maybe we could reuse
> > > > the
> > > > poll worker for that as a one-shot).
> > > 
> > > First off, I definitely agree we need a way to tell userspace
> > > exactly
> > > what has happened. I wanted to start a discussion about that in i-g-
> > > t
> > > patch "Unrelated hotplug uevent masking out actual test result" but
> > > it
> > > didn't get much traction. For testing purposes, it is unacceptable
> > > that
> > > userspace only gets notified that "something happened".
> > > 
> > > Still, as far as I know, userspace is expected to ask for a full
> > > reprobe
> > > when something has changed, and that is apparently part of the DRM
> > > spec,
> > > so we can't expect that it could query for an update on "only the
> > > things
> > > that changed".
> > 
> > We can update that spec in a backwards compatible way. E.g. we can ask
> > for
> > the current properties without forcing a reprobe (won't even call down
> > into the driver), and userspace could use that to check which
> > connector
> > has an incremented epoche counter since the last time it sampled
> > things.
> > Then it can reprobe just that one.
> > 
> > Old userspace wouldn't know about this, and would keep working as-is.
> 
> So the level of detail you're aiming at providing userspace is
> "connector foo changed" then? I agree it is better than the current
> "some connector(s) changed", but what I'd like to see for proper testing
> is a way to find out "bar for connector foo changed".

If you want taht level of detail you need introspection in a in-kernel
selftest I think. We'd need to rather massively change/extend the uapi to
support that level of testing through the uapi, and thus

Re: [PATCH] drm/etnaviv: Fix off-by-one error in reloc checking

2017-07-25 Thread Philipp Zabel
On Tue, 2017-07-25 at 14:33 +0200, Wladimir J. van der Laan wrote:
> A relocation pointing to the last four bytes of a buffer can
> legitimately happen in the case of small vertex buffers.
> 
> Signed-off-by: Wladimir J. van der Laan 
> ---
>  drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c 
> b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> index de80ee1..21be4dc 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> @@ -270,8 +270,8 @@ static int submit_reloc(struct etnaviv_gem_submit 
> *submit, void *stream,
>   if (ret)
>   return ret;
>  
> - if (r->reloc_offset >= bo->obj->base.size - sizeof(*ptr)) {
> - DRM_ERROR("relocation %u outside object", i);
> + if (r->reloc_offset > bo->obj->base.size - sizeof(*ptr)) {
> + DRM_ERROR("relocation %u outside object\n", i);
>   return -EINVAL;
>   }
>  

Reviewed-by: Philipp Zabel 

regards
Philipp

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


Re: [PATCH] drm/amdgpu: fix spelling mistake: "suuport"-> "support"

2017-07-25 Thread Alex Deucher
On Tue, Jul 25, 2017 at 4:40 AM, Christian König
 wrote:
> Am 25.07.2017 um 00:45 schrieb Colin King:
>>
>> From: Colin Ian King 
>>
>> Trivial fix to spelling mistake in WARN_ONCE message
>>
>> Signed-off-by: Colin Ian King 

This is actually already fixed in code slated to go upstream in the next kernel.

Alex


>
>
> Reviewed-by: Christian König 
>
>> ---
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>> index 5795f81369f0..06f11e2a32af 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>> @@ -1301,7 +1301,7 @@ static int amdgpu_vm_update_ptes(struct
>> amdgpu_pte_update_params *params,
>> if (params->shadow) {
>> if (WARN_ONCE(use_cpu_update,
>> -   "CPU VM update doesn't suuport shadow
>> pages"))
>> +   "CPU VM update doesn't support shadow
>> pages"))
>> return 0;
>> if (!pt->shadow)
>
>
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] drm/stm: fix warning about multiplication in condition

2017-07-25 Thread Arnd Bergmann
gcc-7 complains about multiplying within a condition being
suspicious:

drivers/gpu/drm/stm/dw_mipi_dsi-stm.c: In function 'dsi_pll_get_clkout_khz':
drivers/gpu/drm/stm/dw_mipi_dsi-stm.c:117:10: error: '*' in boolean context, 
suggest '&&' instead [-Werror=int-in-bool-context]

The code here is correct, but can be easily rephrased to make
that more obvious. I also swap out the error handling and the normal
code path for clarity.

Fixes: b0f09a3c69d9 ("drm/stm: Add STM32 DSI controller driver")
Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c 
b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
index 568c5d0461ea..e5b6310240fe 100644
--- a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
+++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
@@ -113,11 +113,13 @@ static enum dsi_color dsi_color_from_mipi(enum 
mipi_dsi_pixel_format fmt)
 
 static int dsi_pll_get_clkout_khz(int clkin_khz, int idf, int ndiv, int odf)
 {
+   int divisor = idf * odf;
+
/* prevent from division by 0 */
-   if (idf * odf)
-   return DIV_ROUND_CLOSEST(clkin_khz * ndiv, idf * odf);
+   if (!divisor)
+   return 0;
 
-   return 0;
+   return DIV_ROUND_CLOSEST(clkin_khz * ndiv, divisor);
 }
 
 static int dsi_pll_get_params(int clkin_khz, int clkout_khz,
-- 
2.9.0

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


[PATCH] drm/hisilicon: fix build error without fbdev emulation

2017-07-25 Thread Arnd Bergmann
We cannot reference priv->fbdev outside of the #ifdef:

drivers/net/virtio_net.c:1881:12: error: 'virtnet_restore_up' defined but not 
used [-Werror=unused-function]
 static int virtnet_restore_up(struct virtio_device *vdev)
drivers/net/virtio_net.c:1859:13: error: 'virtnet_freeze_down' defined but not 
used [-Werror=unused-function]
 static void virtnet_freeze_down(struct virtio_device *vdev)

Since the code is moved into the main probe function now, this
adds another #ifdef.

Fixes: b4dd9f1ffaba ("drm/hisilicon: Remove custom FB helper deferred setup")
Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
index 1178341c3858..d48102d1a7a4 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
@@ -121,6 +121,7 @@ static int kirin_drm_kms_init(struct drm_device *dev)
/* init kms poll for handling hpd */
drm_kms_helper_poll_init(dev);
 
+#ifdef CONFIG_DRM_FBDEV_EMULATION
priv->fbdev = drm_fbdev_cma_init(dev, 32,
 dev->mode_config.num_connector);
if (IS_ERR(priv->fbdev)) {
@@ -128,11 +129,13 @@ static int kirin_drm_kms_init(struct drm_device *dev)
ret = PTR_ERR(priv->fbdev);
goto err_cleanup_poll;
}
-
+#endif
return 0;
 
+#ifdef CONFIG_DRM_FBDEV_EMULATION
 err_cleanup_poll:
drm_kms_helper_poll_fini(dev);
+#endif
 err_unbind_all:
component_unbind_all(dev->dev, dev);
 err_dc_cleanup:
-- 
2.9.0

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


Re: [PATCH 7/8] drm: Nuke drm_atomic_helper_connector_dpms

2017-07-25 Thread Shawn Guo
On Tue, Jul 25, 2017 at 10:01:21AM +0200, Daniel Vetter wrote:
> It's dead code, the core handles all this directly now.
> 
> The only special case is nouveau and tda988x which used one function
> for both legacy modeset code and -nv50 atomic world instead of 2
> vtables. But amounts to exactly the same.
> 
> v2: Rebase over the panel/brideg refactorings in stm/ltdc.
> 
> Signed-off-by: Daniel Vetter 
...
>  drivers/gpu/drm/zte/zx_hdmi.c  |  1 -
>  drivers/gpu/drm/zte/zx_tvenc.c |  1 -
>  drivers/gpu/drm/zte/zx_vga.c   |  1 -

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


[Bug 101656] Invalid signal timestamps with EGL_SYNC_NATIVE_FENCE_ANDROID on android

2017-07-25 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=101656

Yogesh Marathe  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTOURBUG

--- Comment #2 from Yogesh Marathe  ---
Turns out to be kernel issue, where fence timestamp was not initialized.

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


Re: [PATCH 20/41] drm/zte: Use .dumb_map_offset and .dumb_destroy defaults

2017-07-25 Thread Shawn Guo
On Sun, Jul 23, 2017 at 09:16:36PM +0200, Noralf Trønnes wrote:
> This driver can use the drm_driver.dumb_destroy and
> drm_driver.dumb_map_offset defaults, so no need to set them.
> 
> Cc: Shawn Guo 

Acked-by: Shawn Guo 

> Signed-off-by: Noralf Trønnes 
> ---
>  drivers/gpu/drm/zte/zx_drm_drv.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/zte/zx_drm_drv.c 
> b/drivers/gpu/drm/zte/zx_drm_drv.c
> index c983cdf..4524482 100644
> --- a/drivers/gpu/drm/zte/zx_drm_drv.c
> +++ b/drivers/gpu/drm/zte/zx_drm_drv.c
> @@ -62,8 +62,6 @@ static struct drm_driver zx_drm_driver = {
>   .gem_free_object_unlocked = drm_gem_cma_free_object,
>   .gem_vm_ops = &drm_gem_cma_vm_ops,
>   .dumb_create = drm_gem_cma_dumb_create,
> - .dumb_map_offset = drm_gem_cma_dumb_map_offset,
> - .dumb_destroy = drm_gem_dumb_destroy,
>   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
>   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
>   .gem_prime_export = drm_gem_prime_export,
> -- 
> 2.7.4
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 7/8] drm: Nuke drm_atomic_helper_connector_dpms

2017-07-25 Thread Laurent Pinchart
Hi Daniel,

Thank you for the patch.

On Tuesday 25 Jul 2017 10:01:21 Daniel Vetter wrote:
> It's dead code, the core handles all this directly now.
> 
> The only special case is nouveau and tda988x which used one function
> for both legacy modeset code and -nv50 atomic world instead of 2
> vtables. But amounts to exactly the same.
> 
> v2: Rebase over the panel/brideg refactorings in stm/ltdc.
> 
> Signed-off-by: Daniel Vetter 

[snip]

> ---
>  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c   |  1 -
>  drivers/gpu/drm/bridge/dumb-vga-dac.c  |  1 -
>  drivers/gpu/drm/bridge/panel.c |  1 -
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c  |  1 -
>  drivers/gpu/drm/drm_atomic_helper.c| 79 ---
>  drivers/gpu/drm/omapdrm/omap_connector.c   |  1 -
>  drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c  |  1 -

For the above,

Reviewed-by: Laurent Pinchart 

-- 
Regards,

Laurent Pinchart

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


[PATCH] dma-buf: fix reservation_object_wait_timeout_rcu to wait correctly v2

2017-07-25 Thread Christian König
From: Christian König 

With hardware resets in mind it is possible that all shared fences are
signaled, but the exlusive isn't. Fix waiting for everything in this situation.

v2: make sure we always wait for the exclusive fence

Signed-off-by: Christian König 
---
 drivers/dma-buf/reservation.c | 33 +++--
 1 file changed, 15 insertions(+), 18 deletions(-)

diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index 393817e..9d4316d 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -373,12 +373,25 @@ long reservation_object_wait_timeout_rcu(struct 
reservation_object *obj,
long ret = timeout ? timeout : 1;
 
 retry:
-   fence = NULL;
shared_count = 0;
seq = read_seqcount_begin(&obj->seq);
rcu_read_lock();
 
-   if (wait_all) {
+   fence = rcu_dereference(obj->fence_excl);
+   if (fence && !test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) {
+   if (!dma_fence_get_rcu(fence))
+   goto unlock_retry;
+
+   if (dma_fence_is_signaled(fence)) {
+   dma_fence_put(fence);
+   fence = NULL;
+   }
+
+   } else {
+   fence = NULL;
+   }
+
+   if (!fence && wait_all) {
struct reservation_object_list *fobj =
rcu_dereference(obj->fence);
 
@@ -405,22 +418,6 @@ long reservation_object_wait_timeout_rcu(struct 
reservation_object *obj,
}
}
 
-   if (!shared_count) {
-   struct dma_fence *fence_excl = rcu_dereference(obj->fence_excl);
-
-   if (fence_excl &&
-   !test_bit(DMA_FENCE_FLAG_SIGNALED_BIT,
- &fence_excl->flags)) {
-   if (!dma_fence_get_rcu(fence_excl))
-   goto unlock_retry;
-
-   if (dma_fence_is_signaled(fence_excl))
-   dma_fence_put(fence_excl);
-   else
-   fence = fence_excl;
-   }
-   }
-
rcu_read_unlock();
if (fence) {
if (read_seqcount_retry(&obj->seq, seq)) {
-- 
2.7.4

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


[Bug 101900] No HDMI audio on Polaris

2017-07-25 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=101900

--- Comment #2 from Harry Wentland  ---
Does this patch fix your issue?

https://patchwork.freedesktop.org/patch/168445/

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


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

2017-07-25 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=194761

--- Comment #73 from siyia (eutychio...@gmail.com) ---
Any further news about this issue?Why dont you just use the p4 config for the
afflicted cards as a fix?

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


Re: [RFC v3] drm/hdcp: drm enum property for CP State

2017-07-25 Thread Sean Paul
On Mon, Jul 24, 2017 at 2:12 PM, Ramalingam C  wrote:
> DRM connector property is created to represent the content protection
> state of the connector and to configure the same.
>
> Content protection states defined:
> DRM_MODE_CONTENT_PROTECTION_UNSUPPORTED - Unsupported
> DRM_MODE_CONTENT_PROTECTION_DISABLE - Disabled
> DRM_MODE_CONTENT_PROTECTION_ENABLE  - Enabled
>
> v2: Redesigned the property to match with CP needs of CrOS [Sean].
>
> v3: Renamed the state names. Header is removed [sean].
>
> Signed-off-by: Ramalingam C 
> ---
>  drivers/gpu/drm/drm_connector.c | 14 ++
>  include/drm/drm_mode_config.h   |  5 +
>  include/uapi/drm/drm_mode.h |  5 +
>  3 files changed, 24 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 5cd61af..d6aaa08 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -617,6 +617,13 @@ static const struct drm_prop_enum_list 
> drm_link_status_enum_list[] = {
>  };
>  DRM_ENUM_NAME_FN(drm_get_link_status_name, drm_link_status_enum_list)
>
> +static const struct drm_prop_enum_list drm_cp_enum_list[] = {
> +   { DRM_MODE_CONTENT_PROTECTION_UNSUPPORTED,  "Unsupported" },

You're still changing the enum names from the original patch/CrOS
implementation.

https://lists.freedesktop.org/archives/dri-devel/2014-December/073336.html

https://cs.chromium.org/chromium/src/ui/ozone/platform/drm/gpu/drm_display.cc?l=27



> +   { DRM_MODE_CONTENT_PROTECTION_DISABLE,  "Disabled" },
> +   { DRM_MODE_CONTENT_PROTECTION_ENABLE,   "Enabled" },
> +};
> +DRM_ENUM_NAME_FN(drm_get_cp_status_name, drm_cp_enum_list)
> +
>  /**
>   * drm_display_info_set_bus_formats - set the supported bus formats
>   * @info: display info to store bus formats in
> @@ -789,6 +796,13 @@ int drm_connector_create_standard_properties(struct 
> drm_device *dev)
> return -ENOMEM;
> dev->mode_config.link_status_property = prop;
>
> +   prop = drm_property_create_enum(dev, 0, "Content Protection",
> +   drm_cp_enum_list,
> +   ARRAY_SIZE(drm_cp_enum_list));
> +   if (!prop)
> +   return -ENOMEM;
> +   dev->mode_config.cp_property = prop;
> +
> return 0;
>  }
>
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index 4298171..7acb8b2 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -538,6 +538,11 @@ struct drm_mode_config {
>  */
> struct drm_property *link_status_property;
> /**
> +* @cp_property: Default connector property for CP
> +* of a connector

Can you please elaborate on this, so readers can understand how this
property works? Perhaps just copy the docs from the original patch?

> +*/
> +   struct drm_property *cp_property;
> +   /**
>  * @plane_type_property: Default plane property to differentiate
>  * CURSOR, PRIMARY and OVERLAY legacy uses of planes.
>  */
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 403339f..554a770 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -127,6 +127,11 @@ extern "C" {
>  #define DRM_MODE_LINK_STATUS_GOOD  0
>  #define DRM_MODE_LINK_STATUS_BAD   1
>
> +/* Content Protection options */
> +#define DRM_MODE_CONTENT_PROTECTION_UNSUPPORTED0
> +#define DRM_MODE_CONTENT_PROTECTION_DISABLE1
> +#define DRM_MODE_CONTENT_PROTECTION_ENABLE 2
> +
>  /*
>   * DRM_MODE_ROTATE_
>   *
> --
> 2.7.4
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] drm/etnaviv: Fix off-by-one error in reloc checking

2017-07-25 Thread Wladimir J. van der Laan
A relocation pointing to the last four bytes of a buffer can
legitimately happen in the case of small vertex buffers.

Signed-off-by: Wladimir J. van der Laan 
---
 drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
index de80ee1..21be4dc 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
@@ -270,8 +270,8 @@ static int submit_reloc(struct etnaviv_gem_submit *submit, 
void *stream,
if (ret)
return ret;
 
-   if (r->reloc_offset >= bo->obj->base.size - sizeof(*ptr)) {
-   DRM_ERROR("relocation %u outside object", i);
+   if (r->reloc_offset > bo->obj->base.size - sizeof(*ptr)) {
+   DRM_ERROR("relocation %u outside object\n", i);
return -EINVAL;
}
 
-- 
2.7.4

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


[Bug 98146] DRI_PRIME=1 and fullscreen issues

2017-07-25 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=98146

Darek Deoniziak  changed:

   What|Removed |Added

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

--- Comment #22 from Darek Deoniziak  ---
Hi, thanks for the tip to launch only steam game with DRI_PRIME setting
enabled, indeed it works.

Also big thanks for making dedicated gpu work without any issues on Linux 4.10
(currently running). Indeed there are no issues whatsoever.

Was testing for few days, both intel and amd gpu:
-Steam app itself,
-few native desktop apps,
-Several games from Steam: Tides of Numenera, Dota2, PAYDAY2, Arma3, Shadow
Warrior
-STALKER runned using Wine (previously it was unplayable because of tearing
with DRI_PRIME=1, now runs like a charm).

I am basicly forced to close this issue, marking as resolved! Once again
thanks.

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


[drm-intel:for-linux-next 4/4] drivers/gpu/drm/i915/selftests/intel_hangcheck.c:845:3: error: too few arguments to function 'i915_reset'

2017-07-25 Thread kbuild test robot
tree:   git://anongit.freedesktop.org/drm-intel for-linux-next
head:   af2788925ae0b83737ee847c5b2e9f19c5bf3630
commit: af2788925ae0b83737ee847c5b2e9f19c5bf3630 [4/4] drm/i915: Squelch reset 
messages during selftests
config: i386-randconfig-x013-201730 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout af2788925ae0b83737ee847c5b2e9f19c5bf3630
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   In file included from drivers/gpu/drm/i915/intel_hangcheck.c:485:0:
   drivers/gpu/drm/i915/selftests/intel_hangcheck.c: In function 
'igt_render_engine_reset_fallback':
>> drivers/gpu/drm/i915/selftests/intel_hangcheck.c:845:3: error: too few 
>> arguments to function 'i915_reset'
  i915_reset(i915);
  ^~
   In file included from drivers/gpu/drm/i915/intel_hangcheck.c:25:0:
   drivers/gpu/drm/i915/i915_drv.h:3115:13: note: declared here
extern void i915_reset(struct drm_i915_private *i915, unsigned int flags);
^~

vim +/i915_reset +845 drivers/gpu/drm/i915/selftests/intel_hangcheck.c

496b575e Chris Wilson   2017-02-13  772  
abeb4def Michel Thierry 2017-06-20  773  static int 
igt_render_engine_reset_fallback(void *arg)
abeb4def Michel Thierry 2017-06-20  774  {
abeb4def Michel Thierry 2017-06-20  775 struct drm_i915_private *i915 = 
arg;
abeb4def Michel Thierry 2017-06-20  776 struct intel_engine_cs *engine 
= i915->engine[RCS];
abeb4def Michel Thierry 2017-06-20  777 struct hang h;
abeb4def Michel Thierry 2017-06-20  778 struct drm_i915_gem_request *rq;
abeb4def Michel Thierry 2017-06-20  779 unsigned int reset_count, 
reset_engine_count;
abeb4def Michel Thierry 2017-06-20  780 int err = 0;
abeb4def Michel Thierry 2017-06-20  781  
abeb4def Michel Thierry 2017-06-20  782 /* Check that we can issue a 
global GPU and engine reset */
abeb4def Michel Thierry 2017-06-20  783  
abeb4def Michel Thierry 2017-06-20  784 if 
(!intel_has_reset_engine(i915))
abeb4def Michel Thierry 2017-06-20  785 return 0;
abeb4def Michel Thierry 2017-06-20  786  
5b3d2c87 Chris Wilson   2017-07-21  787 global_reset_lock(i915);
5b3d2c87 Chris Wilson   2017-07-21  788  
abeb4def Michel Thierry 2017-06-20  789 
mutex_lock(&i915->drm.struct_mutex);
abeb4def Michel Thierry 2017-06-20  790  
abeb4def Michel Thierry 2017-06-20  791 err = hang_init(&h, i915);
abeb4def Michel Thierry 2017-06-20  792 if (err)
774eed4a Chris Wilson   2017-06-23  793 goto err_unlock;
abeb4def Michel Thierry 2017-06-20  794  
abeb4def Michel Thierry 2017-06-20  795 rq = hang_create_request(&h, 
engine, i915->kernel_context);
abeb4def Michel Thierry 2017-06-20  796 if (IS_ERR(rq)) {
abeb4def Michel Thierry 2017-06-20  797 err = PTR_ERR(rq);
774eed4a Chris Wilson   2017-06-23  798 goto err_fini;
abeb4def Michel Thierry 2017-06-20  799 }
abeb4def Michel Thierry 2017-06-20  800  
abeb4def Michel Thierry 2017-06-20  801 i915_gem_request_get(rq);
abeb4def Michel Thierry 2017-06-20  802 __i915_add_request(rq, true);
abeb4def Michel Thierry 2017-06-20  803  
abeb4def Michel Thierry 2017-06-20  804 /* make reset engine fail */
abeb4def Michel Thierry 2017-06-20  805 rq->fence.error = -EIO;
abeb4def Michel Thierry 2017-06-20  806  
abeb4def Michel Thierry 2017-06-20  807 if (!wait_for_hang(&h, rq)) {
abeb4def Michel Thierry 2017-06-20  808 pr_err("Failed to start 
request %x\n", rq->fence.seqno);
abeb4def Michel Thierry 2017-06-20  809 err = -EIO;
774eed4a Chris Wilson   2017-06-23  810 goto err_request;
abeb4def Michel Thierry 2017-06-20  811 }
abeb4def Michel Thierry 2017-06-20  812  
abeb4def Michel Thierry 2017-06-20  813 reset_engine_count = 
i915_reset_engine_count(&i915->gpu_error, engine);
abeb4def Michel Thierry 2017-06-20  814 reset_count = 
fake_hangcheck(rq);
abeb4def Michel Thierry 2017-06-20  815  
abeb4def Michel Thierry 2017-06-20  816 /* unlock since we'll call 
handle_error */
abeb4def Michel Thierry 2017-06-20  817 
mutex_unlock(&i915->drm.struct_mutex);
5b3d2c87 Chris Wilson   2017-07-21  818 global_reset_unlock(i915);
abeb4def Michel Thierry 2017-06-20  819  
abeb4def Michel Thierry 2017-06-20  820 i915_handle_error(i915, 
intel_engine_flag(engine), "live test");
abeb4def Michel Thierry 2017-06-20  821  
abeb4def Michel Thierry 2017-06-20  822 if 
(i915_reset_engine_count(&i915->gpu_error, engine) !=
abeb4def Michel Thierry 2017-06-20  823 reset_engine_count) {
abeb4def Michel Thierry 2017-06-20  824 pr_err("render engine 
reset recorded! (full reset expected)\n");
abeb4def Michel Thierry 2017-06-20  825 err = -EINVAL;
ab

Re: [PATCH 1/2] drm/edid: Add helper to detect whether EDID changed

2017-07-25 Thread Paul Kocialkowski
On Tue, 2017-07-25 at 10:16 +0200, Daniel Vetter wrote:
> On Tue, Jul 25, 2017 at 10:58:55AM +0300, Paul Kocialkowski wrote:
> > On Tue, 2017-07-25 at 09:34 +0200, Daniel Vetter wrote:
> > > On Tue, Jul 25, 2017 at 9:25 AM, Paul Kocialkowski
> > >  wrote:
> > > > On Tue, 2017-07-25 at 08:53 +0200, Daniel Vetter wrote:
> > > > > On Mon, Jul 24, 2017 at 05:54:46PM +0300, Paul Kocialkowski
> > > > > wrote:
> > > > > > This adds a common drm helper to detect whether the EDID
> > > > > > changed
> > > > > > from
> > > > > > the last known cached one. This is useful help detect that a
> > > > > > monitor
> > > > > > was
> > > > > > changed during a suspend/resume cycle.
> > > > > > 
> > > > > > When that happens (a monitor is replaced by another one
> > > > > > during
> > > > > > suspend),
> > > > > > no hotplug event will be triggered so the change will not be
> > > > > > caught
> > > > > > at
> > > > > > resume time. Detecting that the EDID changed allows
> > > > > > detecting
> > > > > > it.
> > > > > > 
> > > > > > Signed-off-by: Paul Kocialkowski  > > > > > tel.
> > > > > > com>
> > > > > 
> > > > > I can't find the older mails I've typed about this, but the
> > > > > plan
> > > > > we've
> > > > > discussed a while back was:
> > > > > - Add a generational counter to each connector, maybe even
> > > > > expose
> > > > > it
> > > > > to
> > > > >   userspace.
> > > > > 
> > > > > - Increment that counter every time something changed, e.g.
> > > > >   connector->status in the propbe helpers, or when attaching a
> > > > > new
> > > > > edid
> > > > >   with the set_edid helper.
> > > > > 
> > > > > - Tada, no changes needed to drivers, and easily extensible to
> > > > > other
> > > > >   things than edid!
> > > > 
> > > > I don't see how it solves the problem here though. After a
> > > > suspend/resume cycle, there is simply no indication that
> > > > anything
> > > > has
> > > > changed when a monitor was replaced by another one, so I don't
> > > > see
> > > > how
> > > > adding a counter in the mix would help.
> > > > 
> > > > Could you provide more details about the reasoning? I feel like
> > > > I'm
> > > > missing something here.
> > > 
> > > Your bug doesn't just exist over s/r, it's just much easier to
> > > observe
> > > in s/r since users can take however long they want to with
> > > plugging in
> > > a different monitor. But the same issue exists e.g. when we go
> > > from
> > > hpd to polling because too much noise on the line.
> > > 
> > > Wrt the suspend/resume issue: What we need to do on resume is do a
> > > full reprobe of all outputs, in an async worker. Telling userspace
> > > to
> > > do this by sending an uevent was the cheapest way, but it'd be
> > > better
> > > if the kernel could do that asynchronously and inform userspace
> > > about
> > > the exact changes. And there's more to reprobe than just the edid,
> > > and
> > > we don't want to re-invent a separate reprobe path just for resume
> > > like you start in your patch series. So yeah my plan was missing:
> > > 
> > > - force a full async reprobe after resume (maybe we could reuse
> > > the
> > > poll worker for that as a one-shot).
> > 
> > First off, I definitely agree we need a way to tell userspace
> > exactly
> > what has happened. I wanted to start a discussion about that in i-g-
> > t
> > patch "Unrelated hotplug uevent masking out actual test result" but
> > it
> > didn't get much traction. For testing purposes, it is unacceptable
> > that
> > userspace only gets notified that "something happened".
> > 
> > Still, as far as I know, userspace is expected to ask for a full
> > reprobe
> > when something has changed, and that is apparently part of the DRM
> > spec,
> > so we can't expect that it could query for an update on "only the
> > things
> > that changed".
> 
> We can update that spec in a backwards compatible way. E.g. we can ask
> for
> the current properties without forcing a reprobe (won't even call down
> into the driver), and userspace could use that to check which
> connector
> has an incremented epoche counter since the last time it sampled
> things.
> Then it can reprobe just that one.
> 
> Old userspace wouldn't know about this, and would keep working as-is.

So the level of detail you're aiming at providing userspace is
"connector foo changed" then? I agree it is better than the current
"some connector(s) changed", but what I'd like to see for proper testing
is a way to find out "bar for connector foo changed".

> > However, one way to mitigate this is to make sure that the driver
> > knows
> > what changed and only updates these things when a full reprobe is
> > requested. Is this the approach that you have in mind?
> > 
> > The methodology behind my series follows what is currently done:
> > detect
> > change in whatever way necessary, inform userspace and let it
> > trigger
> > full reprobe. If I'm understanding correctly, what you're suggesting
> > is
> > instead to reprobe what is needed on the kernel side

Re: [PATCH] dma-buf: fix reservation_object_wait_timeout_rcu to wait correctly

2017-07-25 Thread Daniel Vetter
On Tue, Jul 25, 2017 at 11:11:35AM +0200, Christian König wrote:
> Am 24.07.2017 um 13:57 schrieb Daniel Vetter:
> > On Mon, Jul 24, 2017 at 11:51 AM, Christian König
> >  wrote:
> > > Am 24.07.2017 um 10:33 schrieb Daniel Vetter:
> > > > On Fri, Jul 21, 2017 at 06:20:01PM +0200, Christian König wrote:
> > > > > From: Christian König 
> > > > > 
> > > > > With hardware resets in mind it is possible that all shared fences are
> > > > > signaled, but the exlusive isn't. Fix waiting for everything in this
> > > > > situation.
> > > > How did you end up with both shared and exclusive fences on the same
> > > > reservation object? At least I thought the point of exclusive was that
> > > > it's exclusive (and has an implicit barrier on all previous shared
> > > > fences). Same for shared fences, they need to wait for the exclusive one
> > > > (and replace it).
> > > > 
> > > > Is this fallout from the amdgpu trickery where by default you do all
> > > > shared fences? I thought we've aligned semantics a while back ...
> > > 
> > > No, that is perfectly normal even for other drivers. Take a look at the
> > > reservation code.
> > > 
> > > The exclusive fence replaces all shared fences, but adding a shared fence
> > > doesn't replace the exclusive fence. That actually makes sense, cause when
> > > you want to add move shared fences those need to wait for the last 
> > > exclusive
> > > fence as well.
> > Hm right.
> > 
> > > Now normally I would agree that when you have shared fences it is 
> > > sufficient
> > > to wait for all of them cause those operations can't start before the
> > > exclusive one finishes. But with GPU reset and/or the ability to abort
> > > already submitted operations it is perfectly possible that you end up with
> > > an exclusive fence which isn't signaled and a shared fence which is 
> > > signaled
> > > in the same reservation object.
> > How does that work? The batch(es) with the shared fence are all
> > supposed to wait for the exclusive fence before they start, which
> > means even if you gpu reset and restart/cancel certain things, they
> > shouldn't be able to complete out of order.
> 
> Assume the following:
> 1. The exclusive fence is some move operation by the kernel which executes
> on a DMA engine.
> 2. The shared fence is a 3D operation submitted by userspace which executes
> on the 3D engine.
> 
> Now we found the 3D engine to be hung and needs a reset, all currently
> submitted jobs are aborted, marked with an error code and their fences put
> into the signaled state.
> 
> Since we only reset the 3D engine, the move operation (fortunately) isn't
> affected by this.
> 
> I think this applies to all drivers and isn't something amdgpu specific.

Not i915 because:
- At first we only had system wide gpu reset that killed everything, which
  means all requests will be completed, not just on a single engine.

- Now we have per-engine reset, but combined with replaying them (the
  offending one gets a no-op batch to avoid re-hanging), to make sure the
  depency tree doesn't fall apart.

Now I see that doing this isn't all that simple, and either way we still
have the case where one driver resets but not the other (in multi-gpu),
but I'm not exactly sure how to best handle this.

What exactly is the downside of not dropping this assumption, i.e. why do
you want this patch? What blows up?
-Daniel


> 
> Regards,
> Christian.
> 
> > 
> > If you outright cancel a fence then you're supposed to first call
> > dma_fence_set_error(-EIO) and then complete it. Note that atm that
> > part might be slightly overengineered and I'm not sure about how we
> > expose stuff to userspace, e.g. dma_fence_set_error(-EAGAIN) is (or
> > soon, has been) used by i915 for it's internal book-keeping, which
> > might not be the best to leak to other consumers. But completing
> > fences (at least exported ones, where userspace or other drivers can
> > get at them) shouldn't be possible.
> > -Daniel
> 
> 

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


[PATCH] drm: Don't update property values for atomic drivers

2017-07-25 Thread Daniel Vetter
Atomic drivers only use the property value store for immutable (i.e.
can't be set by userspace, but the kernel can still adjust it)
properties. The only tricky part is the removal of the update in
drm_atomic_helper_update_legacy_modeset_state().

This was added in

commit 8c10342cb48f3140d9abeadcfd2fa6625d447282 (tag: topic/drm-misc-2015-07-28)
Author: Maarten Lankhorst 
Date:   Mon Jul 27 13:24:29 2015 +0200

drm/atomic: Update legacy DPMS state during modesets, v3.

by copying it from the i915 code, where it was originally added in

commit 68d3472047a572936551f8ff0b6f4016c5a1fdef
Author: Daniel Vetter 
Date:   Thu Sep 6 22:08:35 2012 +0200

drm/i915: update dpms property in set_mode

for the legacy modeset code. The reason we needed this hack was that
i915 didn't yet set DRIVER_ATOMIC, and we checked for that instead of
the newer-ish drm_drv_uses_atomic_modeset(), which avoids such
troubles. With the correct feature checks this isn't needed anymore at
all.

Also make sure that drivers don't accidentally get this wrong by
making the exported version of drm_object_property_get_value() only
work for legacy drivers. Only gma500 uses it anyway.

v2: Fixup the uses_atomic_modeset() checks (Maarten)

Cc: Maarten Lankhorst 
Reviewed-by: Maarten Lankhorst 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_atomic_helper.c |  4 ---
 drivers/gpu/drm/drm_connector.c |  3 +--
 drivers/gpu/drm/drm_crtc.c  |  2 +-
 drivers/gpu/drm/drm_mode_object.c   | 49 +++--
 drivers/gpu/drm/drm_plane.c |  2 +-
 5 files changed, 33 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 7582bbc5decc..4a960c741e35 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -921,16 +921,12 @@ drm_atomic_helper_update_legacy_modeset_state(struct 
drm_device *dev,
crtc = new_conn_state->crtc;
if ((!crtc && old_conn_state->crtc) ||
(crtc && drm_atomic_crtc_needs_modeset(crtc->state))) {
-   struct drm_property *dpms_prop =
-   dev->mode_config.dpms_property;
int mode = DRM_MODE_DPMS_OFF;
 
if (crtc && crtc->state->active)
mode = DRM_MODE_DPMS_ON;
 
connector->dpms = mode;
-   drm_object_property_set_value(&connector->base,
- dpms_prop, mode);
}
}
 
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 8072e6e4c62c..0e9e3161bdd0 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1225,8 +1225,7 @@ int drm_mode_connector_set_obj_prop(struct 
drm_mode_object *obj,
} else if (connector->funcs->set_property)
ret = connector->funcs->set_property(connector, property, 
value);
 
-   /* store the property value if successful */
-   if (!ret)
+   if (!ret && !drm_drv_uses_atomic_modeset(property->dev))
drm_object_property_set_value(&connector->base, property, 
value);
return ret;
 }
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 5af25ce5bf7c..9271235d84b0 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -736,7 +736,7 @@ int drm_mode_crtc_set_obj_prop(struct drm_mode_object *obj,
 
if (crtc->funcs->set_property)
ret = crtc->funcs->set_property(crtc, property, value);
-   if (!ret)
+   if (!ret && !drm_drv_uses_atomic_modeset(property->dev))
drm_object_property_set_value(obj, property, value);
 
return ret;
diff --git a/drivers/gpu/drm/drm_mode_object.c 
b/drivers/gpu/drm/drm_mode_object.c
index da9a9adbcc98..92743a796bf0 100644
--- a/drivers/gpu/drm/drm_mode_object.c
+++ b/drivers/gpu/drm/drm_mode_object.c
@@ -233,6 +233,9 @@ int drm_object_property_set_value(struct drm_mode_object 
*obj,
 {
int i;
 
+   WARN_ON(drm_drv_uses_atomic_modeset(property->dev) &&
+   !(property->flags & DRM_MODE_PROP_IMMUTABLE));
+
for (i = 0; i < obj->properties->count; i++) {
if (obj->properties->properties[i] == property) {
obj->properties->values[i] = val;
@@ -244,24 +247,7 @@ int drm_object_property_set_value(struct drm_mode_object 
*obj,
 }
 EXPORT_SYMBOL(drm_object_property_set_value);
 
-/**
- * drm_object_property_get_value - retrieve the value of a property
- * @obj: drm mode object to get property value from
- * @property: property to retrieve
- * @val: storage for the property value
- *
- * This function retrieves the softare state of the given property for the 
given
- * property. Since there is no driver callback to retrieve the current property
- * value this might be out of sync with the hardw

[PATCH] drm: Handle properties in the core for atomic drivers

2017-07-25 Thread Daniel Vetter
The reason behind the original indirection through the helper
functions was to allow existing drivers to overwrite how they handle
properties. For example when a vendor-specific userspace had
expectations that didn't match atomic. That seemed likely, since
atomic is standardizing a _lot_ more of the behaviour of a kms driver.

But 20 drivers later there's no such need at all. Worse, this forces
all drivers to hook up the default behaviour, breaking userspace if
they forget to do that. And it forces us to export a bunch of core
function just for those helpers.

And finally, these helpers are the last places using
drm_atomic_legacy_backoff() and the implicit acquire_ctx.

This patch here just implements the new behaviour and updates the
docs. Follow-up patches will garbage-collect all the dead code.

v2: Fixup docs even better!

v3: Make it actually work ...

v4: Drop the uses_atomic_modeset() checks from the previous patch
again, since they're now moved up in the callchain.

Cc: Maarten Lankhorst 
Reviewed-by: Archit Taneja  (v3)
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_atomic.c|  60 ++--
 drivers/gpu/drm/drm_connector.c |   8 +--
 drivers/gpu/drm/drm_crtc.c  |   2 +-
 drivers/gpu/drm/drm_crtc_helper.c   |   3 +-
 drivers/gpu/drm/drm_crtc_internal.h |   7 +++
 drivers/gpu/drm/drm_mode_object.c   | 110 +++-
 drivers/gpu/drm/drm_plane.c |   2 +-
 include/drm/drm_connector.h |  10 ++--
 include/drm/drm_crtc.h  |   6 +-
 include/drm/drm_plane.h |   6 +-
 10 files changed, 161 insertions(+), 53 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 01192dd3ed79..0fd14aff7add 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1864,9 +1864,60 @@ static struct drm_pending_vblank_event 
*create_vblank_event(
return e;
 }
 
-static int atomic_set_prop(struct drm_atomic_state *state,
-   struct drm_mode_object *obj, struct drm_property *prop,
-   uint64_t prop_value)
+int drm_atomic_connector_commit_dpms(struct drm_atomic_state *state,
+struct drm_connector *connector,
+int mode)
+{
+   struct drm_connector *tmp_connector;
+   struct drm_connector_state *new_conn_state;
+   struct drm_crtc *crtc;
+   struct drm_crtc_state *crtc_state;
+   int i, ret, old_mode = connector->dpms;
+   bool active = false;
+
+   ret = drm_modeset_lock(&state->dev->mode_config.connection_mutex,
+  state->acquire_ctx);
+   if (ret)
+   return ret;
+
+   if (mode != DRM_MODE_DPMS_ON)
+   mode = DRM_MODE_DPMS_OFF;
+   connector->dpms = mode;
+
+   crtc = connector->state->crtc;
+   if (!crtc)
+   goto out;
+   ret = drm_atomic_add_affected_connectors(state, crtc);
+   if (ret)
+   goto out;
+
+   crtc_state = drm_atomic_get_crtc_state(state, crtc);
+   if (IS_ERR(crtc_state)) {
+   ret = PTR_ERR(crtc_state);
+   goto out;
+   }
+
+   for_each_new_connector_in_state(state, tmp_connector, new_conn_state, 
i) {
+   if (new_conn_state->crtc != crtc)
+   continue;
+   if (tmp_connector->dpms == DRM_MODE_DPMS_ON) {
+   active = true;
+   break;
+   }
+   }
+
+   crtc_state->active = active;
+   ret = drm_atomic_commit(state);
+out:
+   if (ret != 0)
+   connector->dpms = old_mode;
+   return ret;
+}
+
+int drm_atomic_set_property(struct drm_atomic_state *state,
+   struct drm_mode_object *obj,
+   struct drm_property *prop,
+   uint64_t prop_value)
 {
struct drm_mode_object *ref;
int ret;
@@ -2286,7 +2337,8 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
goto out;
}
 
-   ret = atomic_set_prop(state, obj, prop, prop_value);
+   ret = drm_atomic_set_property(state, obj, prop,
+ prop_value);
if (ret) {
drm_mode_object_put(obj);
goto out;
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 0e9e3161bdd0..ba9f36cef68c 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -717,9 +717,9 @@ DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
  * drivers, it remaps to controlling the "ACTIVE" property on the CRTC the
  * connector is linked to. Drivers should never set this property directly,
  * it is handled by the DRM core by calling the &drm_connector_funcs.dpms
- * callbac

[Bug 195295] USB device insertion turns on discrete Radeon GPU

2017-07-25 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=195295

Eugene Shalygin (eugene.shaly...@gmail.com) changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #5 from Eugene Shalygin (eugene.shaly...@gmail.com) ---
Caused by laptop-mode service.

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


Re: [PATCH] [RESEND] gpu: ipu-v3: add DRM dependency

2017-07-25 Thread Arnd Bergmann
On Tue, Jul 25, 2017 at 1:52 PM, Philipp Zabel  wrote:
> On Tue, 2017-07-25 at 13:35 +0200, Arnd Bergmann wrote:
>> On Tue, Jul 25, 2017 at 10:03 AM, Philipp Zabel  
>> wrote:
>> > On Tue, 2017-07-25 at 09:33 +0200, Arnd Bergmann wrote:
>> >> On Mon, Jul 24, 2017 at 10:05 AM, Philipp Zabel  
>> >> wrote:
>> >> > On Fri, 2017-07-21 at 22:56 +0200, Arnd Bergmann wrote:
>>
>> >> If you only need build-testing, you could have a simple wrapper like
>> >>
>> >> const struct drm_format_info *ipu_format_info(u32 format)
>> >> {
>> >>  static const struct drm_format_info invalid = {};
>> >>
>> >>  if (!IS_REACHABLE(CONFIG_DRM))
>> >>   return &invalid;
>> >>
>> >>  return drm_format_info(format);
>> >> }
>> >
>> > That should work fine. Both ipu_prg_format_supported and
>> > ipu_prg_channel_configure are only ever called by DRM code.
>>
>> Ok, in that case, I think we should just make the compilation
>> of PRE and PRG conditional and leave them out when DRM
>> is not built-in (be aware of the case of DRM=m, IPU=y).
>
> Maybe we should just:
>
> config IMX_IPUV3_CORE
> depends on DRM || !DRM # if DRM=m, this can't be 'y'

Yes, that would solve that case. I see now that the DRM=n
case is already handled by 30310c835f3e ("gpu: ipu-v3: don't
depend on DRM being enabled"), so that is probably sufficient.

I've added that change to my randconfig tree now and will give
it some more testing. If you don't hear back from me, please assume
that it works, and send that version upstream.

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


Re: [PATCH] drm: tegra: add CONFIG_OF dependency

2017-07-25 Thread Arnd Bergmann
On Tue, Jul 25, 2017 at 10:25 AM, Jon Hunter  wrote:
>
> On 21/07/17 17:13, Arnd Bergmann wrote:
>> Without CONFIG_OF, we can run into a build error:
>>
>> drivers/gpu/drm/tegra/dpaux.c:378:20: error: 
>> 'pinconf_generic_dt_node_to_map_group' undeclared here (not in a function); 
>> did you mean 'pinconf_generic_params'?
>>   .dt_node_to_map = pinconf_generic_dt_node_to_map_group,
>> ^~~~
>> pinconf_generic_params
>> drivers/gpu/drm/tegra/dpaux.c:379:17: error: 'pinconf_generic_dt_free_map' 
>> undeclared here (not in a function); did you mean 'pinconf_generic_params'?
>>
>> This adds an explicit dependency.
>>
>> Signed-off-by: Arnd Bergmann 
>> ---
>>  drivers/gpu/drm/tegra/Kconfig | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/gpu/drm/tegra/Kconfig b/drivers/gpu/drm/tegra/Kconfig
>> index 2db29d67193d..dc58ab140151 100644
>> --- a/drivers/gpu/drm/tegra/Kconfig
>> +++ b/drivers/gpu/drm/tegra/Kconfig
>> @@ -3,6 +3,7 @@ config DRM_TEGRA
>>   depends on ARCH_TEGRA || (ARM && COMPILE_TEST)
>>   depends on COMMON_CLK
>>   depends on DRM
>> + depends on OF
>>   select DRM_KMS_HELPER
>>   select DRM_MIPI_DSI
>>   select DRM_PANEL
>
> Thanks Arnd. I am curious if it can still fail if PINCTRL is not
> selected in whatever config you are using?

I have not run into other those problems in many randconfig builds.
Looking at the driver now, I see it has an "#ifdef CONFIG_GENERIC_PINCONF"
to handle that case.

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


Re: [PATCH] [RESEND] gpu: ipu-v3: add DRM dependency

2017-07-25 Thread Philipp Zabel
On Tue, 2017-07-25 at 13:35 +0200, Arnd Bergmann wrote:
> On Tue, Jul 25, 2017 at 10:03 AM, Philipp Zabel  
> wrote:
> > On Tue, 2017-07-25 at 09:33 +0200, Arnd Bergmann wrote:
> >> On Mon, Jul 24, 2017 at 10:05 AM, Philipp Zabel  
> >> wrote:
> >> > On Fri, 2017-07-21 at 22:56 +0200, Arnd Bergmann wrote:
> 
> >> If you only need build-testing, you could have a simple wrapper like
> >>
> >> const struct drm_format_info *ipu_format_info(u32 format)
> >> {
> >>  static const struct drm_format_info invalid = {};
> >>
> >>  if (!IS_REACHABLE(CONFIG_DRM))
> >>   return &invalid;
> >>
> >>  return drm_format_info(format);
> >> }
> >
> > That should work fine. Both ipu_prg_format_supported and
> > ipu_prg_channel_configure are only ever called by DRM code.
> 
> Ok, in that case, I think we should just make the compilation
> of PRE and PRG conditional and leave them out when DRM
> is not built-in (be aware of the case of DRM=m, IPU=y).

Maybe we should just:

config IMX_IPUV3_CORE
depends on DRM || !DRM # if DRM=m, this can't be 'y'

regards
Philipp

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


Re: [PATCH] drm/udl: Make page_flip asynchronous

2017-07-25 Thread Chris Wilson
Quoting Dawid Kurek (2017-07-07 06:48:49)
> In page_flip vblank is sent with no delay. Driver does not know when the
> actual update is present on the display and has no means for getting
> this information from a device. It is practically impossible to say
> exactly *when* as there is also i.e. a usb delay.
> 
> When we are unable to determine when the vblank actually happens we may
> assume it will behave accordingly, i.e. it will present frames with
> proper timing. In the worst case scenario it should take up to duration
> of one frame (we may get new frame in the device just after presenting
> current one so we would need to wait for the whole frame).
> 
> Because of the asynchronous nature of the delay we need to synchronize:
>  * read/write vrefresh/page_flip data when changing mode and
>preparing/executing vblank
>  * USB requests to prevent interleaved access to URBs for two different
>frame buffers
> 
> All those changes are backports from ChromeOS:
>   1. https://chromium-review.googlesource.com/250622
>   2. https://chromium-review.googlesource.com/249450
>   partially, only change in udl_modeset.c for 'udl_flip_queue'
>   3. https://chromium-review.googlesource.com/321378
>   4. https://chromium-review.googlesource.com/324119
> + fixes for checkpatch and latest drm changes
> 
> Cc: h...@chromium.org
> Cc: marc...@chromium.org
> Cc: za...@chromium.org
> Cc: db...@google.com
> Signed-off-by: Dawid Kurek 

> +struct udl_flip_queue {
> +   struct mutex lock;
> +   struct workqueue_struct *wq;
> +   struct delayed_work work;
> +   struct drm_crtc *crtc;
> +   struct drm_pending_vblank_event *event;
> +   u64 flip_time; /*in jiffies */
> +   u64 vblank_interval; /*in jiffies */

jiffies are unsigned long. That avoids the complication of the reader
having to consider whether all the divides are 32bit safe.

mallocing this struct seems a little overkill as opposed to embedding it
tino the udl_device, flip_queue.wq provides the safety check after
initialisation.

I couldn't spot anything drastically wrong, certainly it looks complete,
I would have structured it such that everything went through the same
worker with a hrtimer emulating the vblank. That model is then but a
stone's throw away from atomic.

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


Re: [PATCH] [RESEND] gpu: ipu-v3: add DRM dependency

2017-07-25 Thread Arnd Bergmann
On Tue, Jul 25, 2017 at 10:03 AM, Philipp Zabel  wrote:
> On Tue, 2017-07-25 at 09:33 +0200, Arnd Bergmann wrote:
>> On Mon, Jul 24, 2017 at 10:05 AM, Philipp Zabel  
>> wrote:
>> > On Fri, 2017-07-21 at 22:56 +0200, Arnd Bergmann wrote:

>> If you only need build-testing, you could have a simple wrapper like
>>
>> const struct drm_format_info *ipu_format_info(u32 format)
>> {
>>  static const struct drm_format_info invalid = {};
>>
>>  if (!IS_REACHABLE(CONFIG_DRM))
>>   return &invalid;
>>
>>  return drm_format_info(format);
>> }
>
> That should work fine. Both ipu_prg_format_supported and
> ipu_prg_channel_configure are only ever called by DRM code.

Ok, in that case, I think we should just make the compilation
of PRE and PRG conditional and leave them out when DRM
is not built-in (be aware of the case of DRM=m, IPU=y).

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


Re: iMac 10,1 with Ubuntu 16.04: black screen after suspend

2017-07-25 Thread Lukas Wunner
On Tue, Jul 25, 2017 at 07:14:23AM +0200, Mario Kleiner wrote:
> On 07/24/2017 03:45 PM, Florian Echtler wrote:
> > thanks for the hint. I've applied this patch to the v4.12 tree I'm
> > currently running, and it didn't seem to make any difference (i.e.
> > display stays black after suspend).
> 
> That's the same here with my patch applied. After a suspend -> resume, the
> internal panel stays black, the patch doesn't help for that. Somethig i
> didn't notice btw., apparently i never suspend->resumed it.
[...]
> Lukas idea that some hardware mux gets switched into the wrong position on
> models with TDM sounds pretty appealing to me, but how to test?

If all else fails, with a multimeter / oscilloscope. :-)  The board
schematics are available by googling for the right terms, such as
the drawing number "051-7863" and internal codename "K23".

Of interest is the eDP connector on the mainboard, page 90.  Notice
there are two power rails going into it, 3.3V (pin 31) and 12V (pins
27 - 30).  Florian obtained dmesg output of the machine coming out
of suspend by ssh'ing into it and it showed that the eDP link could
be trained properly upon system resume.  Still the panel stayed black.

My guess is that the panel's DisplayPort transceiver is powered via the
3.3V rail.  This rail is powered permanently when the system is in S0,
it cannot be switched off at runtime.  So, the Radeon card can talk to
the DisplayPort transceiver (which has power) but the 12V rail, which
presumably powers the LED backlight, is off.  You could test this theory
by attaching a multimeter after coming out of suspend:  You should see
a voltage difference of 3.3V between pins 31 and 32 (ground) and 0V
between pins 27 - 30 and 32.

The logic for the 12V rail is somewhat complicated, first there's
pin 21 ("VIDEO_ON"), this seems to come *from* the panel and presumably
signals that the link is trained. This should go high after resume.
If it does not then maybe a write to a custom DPCD register is necessary
to make it go high.  If this pin stays low then the 12V rail is not
powered.

Next there's a 74LVC157A mux (page 95 top-left).  Datasheet:
https://assets.nexperia.com/documents/data-sheet/74LVC157A.pdf
The mux can switch four wires, but Apple only needed three.
I guess all outputs (pins 7, 9, 12) must be high for the backlight
to go on.  The mux is under the control of the SMC and is presumably
switched by issuing appropriate commands to the SMC.  It's unclear
to me if the SMC has switched it to the Radeon or to the TDM source
after resume.

Assuming that the mux is switched to the Radeon card, follow input
pins 5, 10 and 14 (MXM_PNL_BL_PWM, MXM_PNL_BL_EN, MXM_PNL_PWR_EN).
They are coming from a "system management" block on the Radeon card
(pins 25, 27, 23, page 85).  Apparently these are GPIO pins for
OEM use and I guess they can be controlled by writing to the PCI BAR
of the Radeon card, but I've no idea at what address their registers
might be located.  I'll try to look at the macOS Radeon drivers with
a disassembler but this is like looking for a needle in a haystack.


> However this is something i got when connecting the external Displayport
> panel:
> 
> Jul  7 04:16:09 kleinerm-MaxtorLinux kernel: [ 1441.344792]
> [drm:radeon_dp_link_train [radeon]] *ERROR* displayport link status failed
> Jul  7 04:16:09 kleinerm-MaxtorLinux kernel: [ 1441.344819]
> [drm:radeon_dp_link_train [radeon]] *ERROR* clock recovery failed
> Jul  7 04:18:07 kleinerm-MaxtorLinux kernel: [ 1559.770783]
> drm_dp_i2c_do_msg: 20 callbacks suppressed
> Jul  7 04:30:19 kleinerm-MaxtorLinux kernel: [ 2291.143406]
> [drm:radeon_dp_link_train [radeon]] *ERROR* displayport link status failed
> Jul  7 04:30:19 kleinerm-MaxtorLinux kernel: [ 2291.143439]
> [drm:radeon_dp_link_train [radeon]] *ERROR* clock recovery failed
> Jul  7 04:30:19 kleinerm-MaxtorLinux kernel: [ 2291.356173]
> [drm:radeon_dp_link_train [radeon]] *ERROR* displayport link status failed
> Jul  7 04:30:19 kleinerm-MaxtorLinux kernel: [ 2291.356205]
> [drm:radeon_dp_link_train [radeon]] *ERROR* clock recovery failed
> 
> So link training failed, because drm_dp_dpcd_read_link_status() already
> failed to read from the dp aux channel.

The AUX channel can be terminated in either of two modes under the control
of the SMC:  100k source termination or weak sink termination (page 94/95).
Failure to communicate over AUX may be explained by being in the incorrect
mode.

HTH,

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


Re: [PATCH v2 2/7] drm/atomic: Clean up drm_atomic_helper_async_check

2017-07-25 Thread Maarten Lankhorst
Op 25-07-17 om 11:27 schreef Daniel Vetter:
> On Tue, Jul 25, 2017 at 11:11 AM, Maarten Lankhorst
>  wrote:
>> Op 25-07-17 om 10:23 schreef Daniel Vetter:
>>> On Wed, Jul 19, 2017 at 04:39:15PM +0200, Maarten Lankhorst wrote:
  /*
 - * Don't do an async update if there is an outstanding commit 
 modifying
 - * the plane.  This prevents our async update's changes from getting
 - * overridden by a previous synchronous update's state.
 + * FIXME: We should prevent an async update if there is an outstanding
 + * commit modifying the plane.  This prevents our async update's
 + * changes from getting overwritten by a previous synchronous update's
 + * state.
   */
 -for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
 -if (plane->crtc != crtc)
 -continue;
 -
 -spin_lock(&crtc->commit_lock);
 -commit = list_first_entry_or_null(&crtc->commit_list,
 -  struct drm_crtc_commit,
 -  commit_entry);
 -if (!commit) {
 -spin_unlock(&crtc->commit_lock);
 -continue;
 -}
 -spin_unlock(&crtc->commit_lock);
 -
 -if (!crtc->state->state)
 -continue;
 -
 -for_each_plane_in_state(crtc->state->state, __plane,
 -__plane_state, j) {
>>> I'm pretty sure this oopses, because crtc->state->state is NULL after
>>> commit. I think Gustavo needs to review this first (and write a nasty igt
>>> testcase to catch it) before we remove this. I think the correct check is
>>> to simply bail out if our current crtc has a pending commit (i.e.
>>> !list_empty(&crtc->commit_list) should be all we need to check.
>> It didn't oops. Right above it was a null check. It was never executed. :)
>>
>> obj->state->state is always NULL. Excluding a brief moment during swap_state 
>> where this may oops,  this code willl never do a thing.
> Oh right. It's still completely buggy, and I'd like to fix that first,
> testcase included. Can you pls poke Gustavo a bit (or maybe he's on
> vacation)?
> -Daniel

The only thing we have atm excercising it is kms_cursor_legacy, but that 
doesn't check if flips can be overwritten.
Perhaps we should make IGT tests a requirement for features in the future?

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


Re: [PATCH 0/4] [v2] Blobifiers (FKA GET_PLANE2)

2017-07-25 Thread Philippe CORNU


On 07/24/2017 05:46 AM, Ben Widawsky wrote:
> Second attempt (although most patches are much further along than that) and 
> the
> blob property for modifiers.
> 
> This small series adds the DRM blob property that allows clients to be made
> aware of per plane modifiers and the formats which are supported in 
> conjunction
> with  those modifiers. This interface will allow clients to create buffers for
> scanout with a good set of modifiers, and later import those buffers (through
> EGL already, and Vulkan WSI later) into a graphics runtime. EGL/WSI will 
> provide
> similar interfaces for rendering - modifiers which can be used for rendering.
> 
> Ben Widawsky (4):
>drm: Plumb modifiers through plane init
>drm: Create a format/modifier blob
>drm/i915: Add format modifiers for Intel
>drm/i915: Add support for CCS modifiers
> 
>   drivers/gpu/drm/arc/arcpgu_crtc.c   |   1 +
>   drivers/gpu/drm/arm/hdlcd_crtc.c|   1 +
>   drivers/gpu/drm/arm/malidp_planes.c |   2 +-
>   drivers/gpu/drm/armada/armada_crtc.c|   1 +
>   drivers/gpu/drm/armada/armada_overlay.c |   1 +
>   drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c |   3 +-
>   drivers/gpu/drm/drm_mode_config.c   |   7 +
>   drivers/gpu/drm/drm_modeset_helper.c|   1 +
>   drivers/gpu/drm/drm_plane.c | 120 +-
>   drivers/gpu/drm/drm_simple_kms_helper.c |   3 +
>   drivers/gpu/drm/exynos/exynos_drm_plane.c   |   2 +-
>   drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c |   2 +-
>   drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c  |   1 +
>   drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c |   2 +-
>   drivers/gpu/drm/i915/intel_display.c| 148 +-
>   drivers/gpu/drm/i915/intel_drv.h|   1 -
>   drivers/gpu/drm/i915/intel_sprite.c | 162 
> +++-
>   drivers/gpu/drm/imx/ipuv3-plane.c   |   4 +-
>   drivers/gpu/drm/mediatek/mtk_drm_plane.c|   2 +-
>   drivers/gpu/drm/meson/meson_plane.c |   1 +
>   drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c   |   2 +-
>   drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c   |   4 +-
>   drivers/gpu/drm/mxsfb/mxsfb_drv.c   |   2 +-
>   drivers/gpu/drm/nouveau/nv50_display.c  |   5 +-
>   drivers/gpu/drm/omapdrm/omap_plane.c|   2 +-
>   drivers/gpu/drm/pl111/pl111_display.c   |   2 +-
>   drivers/gpu/drm/qxl/qxl_display.c   |   2 +-
>   drivers/gpu/drm/rcar-du/rcar_du_plane.c |   4 +-
>   drivers/gpu/drm/rcar-du/rcar_du_vsp.c   |   4 +-
>   drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   4 +-
>   drivers/gpu/drm/sti/sti_cursor.c|   2 +-
>   drivers/gpu/drm/sti/sti_gdp.c   |   2 +-
>   drivers/gpu/drm/sti/sti_hqvdp.c |   2 +-
>   drivers/gpu/drm/stm/ltdc.c  |   2 +-

for stm,

Acked-by: Philippe Cornu 
Tested-by: Philippe Cornu 

Many thanks
Philippe :-)

>   drivers/gpu/drm/sun4i/sun4i_layer.c |   2 +-
>   drivers/gpu/drm/tegra/dc.c  |  12 +-
>   drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c |   2 +-
>   drivers/gpu/drm/vc4/vc4_plane.c |   2 +-
>   drivers/gpu/drm/virtio/virtgpu_plane.c  |   2 +-
>   drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c |   4 +-
>   drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c|   4 +-
>   drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c|   4 +-
>   drivers/gpu/drm/zte/zx_plane.c  |   2 +-
>   include/drm/drm_mode_config.h   |   6 +
>   include/drm/drm_plane.h |  22 +++-
>   include/drm/drm_simple_kms_helper.h |   1 +
>   include/uapi/drm/drm_fourcc.h   |  11 ++
>   include/uapi/drm/drm_mode.h |  50 
>   48 files changed, 576 insertions(+), 52 deletions(-)
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 7/8] drm: Nuke drm_atomic_helper_connector_dpms

2017-07-25 Thread Philippe CORNU


On 07/25/2017 10:01 AM, Daniel Vetter wrote:
> It's dead code, the core handles all this directly now.
> 
> The only special case is nouveau and tda988x which used one function
> for both legacy modeset code and -nv50 atomic world instead of 2
> vtables. But amounts to exactly the same.
> 
> v2: Rebase over the panel/brideg refactorings in stm/ltdc.
> 
> Signed-off-by: Daniel Vetter 
> Cc: Archit Taneja 
> Cc: Andrzej Hajda 
> Cc: Laurent Pinchart 
> Cc: Peter Senna Tschudin 
> Cc: Martin Donnelly 
> Cc: Martyn Welch 
> Cc: Daniel Vetter 
> Cc: Jani Nikula 
> Cc: Sean Paul 
> Cc: David Airlie 
> Cc: Inki Dae 
> Cc: Joonyoung Shim 
> Cc: Seung-Woo Kim 
> Cc: Kyungmin Park 
> Cc: Kukjin Kim 
> Cc: Krzysztof Kozlowski 
> Cc: Stefan Agner 
> Cc: Alison Wang 
> Cc: Russell King 
> Cc: Philipp Zabel 
> Cc: CK Hu 
> Cc: Matthias Brugger 
> Cc: Neil Armstrong 
> Cc: Carlo Caione 
> Cc: Kevin Hilman 
> Cc: Marek Vasut 
> Cc: Ben Skeggs 
> Cc: Tomi Valkeinen 
> Cc: Eric Anholt 
> Cc: Mark Yao 
> Cc: Heiko Stuebner 
> Cc: Benjamin Gaignard 
> Cc: Vincent Abriou 
> Cc: Yannick Fertre 
> Cc: Philippe Cornu 

Tested-by: Philippe Cornu  (on stm)

Many thanks
Philippe :-)

> Cc: Maxime Ripard 
> Cc: Chen-Yu Tsai 
> Cc: Thierry Reding 
> Cc: Jonathan Hunter 
> Cc: Jyri Sarha 
> Cc: Gerd Hoffmann 
> Cc: Shawn Guo 
> Cc: John Stultz 
> Cc: Lars-Peter Clausen 
> Cc: Sergei Shtylyov 
> Cc: Jeffy Chen 
> Cc: Tomeu Vizoso 
> Cc: Yakir Yang 
> Cc: Marek Szyprowski 
> Cc: Jose Abreu 
> Cc: Romain Perier 
> Cc: Kieran Bingham 
> Cc: Xinliang Liu 
> Cc: Alexey Brodkin 
> Cc: Alex Deucher 
> Cc: Rongrong Zou 
> Cc: Rob Clark 
> Cc: Hai Li 
> Cc: "Noralf Trønnes" 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: intel-...@lists.freedesktop.org
> Cc: linux-media...@lists.infradead.org
> Cc: linux-amlo...@lists.infradead.org
> Cc: nouv...@lists.freedesktop.org
> Cc: linux-renesas-...@vger.kernel.org
> Cc: linux-rockc...@lists.infradead.org
> Cc: linux-te...@vger.kernel.org
> Cc: virtualizat...@lists.linux-foundation.org
> Cc: zain wang 
> Cc: Baoyou Xie 
> Cc: Boris Brezillon 
> ---
>   drivers/gpu/drm/bridge/adv7511/adv7511_drv.c   |  1 -
>   drivers/gpu/drm/bridge/analogix-anx78xx.c  |  1 -
>   drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |  1 -
>   drivers/gpu/drm/bridge/dumb-vga-dac.c  |  1 -
>   .../drm/bridge/megachips-stdp-ge-b850v3-fw.c   |  1 -
>   drivers/gpu/drm/bridge/nxp-ptn3460.c   |  1 -
>   drivers/gpu/drm/bridge/panel.c |  1 -
>   drivers/gpu/drm/bridge/parade-ps8622.c |  1 -
>   drivers/gpu/drm/bridge/sii902x.c   |  1 -
>   drivers/gpu/drm/bridge/synopsys/dw-hdmi.c  |  1 -
>   drivers/gpu/drm/bridge/tc358767.c  |  1 -
>   drivers/gpu/drm/bridge/ti-tfp410.c |  1 -
>   drivers/gpu/drm/drm_atomic_helper.c| 79 
> --
>   drivers/gpu/drm/exynos/exynos_drm_dpi.c|  1 -
>   drivers/gpu/drm/exynos/exynos_drm_dsi.c|  1 -
>   drivers/gpu/drm/exynos/exynos_drm_vidi.c   |  1 -
>   drivers/gpu/drm/exynos/exynos_hdmi.c   |  1 -
>   drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c  |  1 -
>   drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c   |  1 -
>   drivers/gpu/drm/i2c/tda998x_drv.c  | 10 +--
>   drivers/gpu/drm/i915/intel_crt.c   |  1 -
>   drivers/gpu/drm/i915/intel_dp.c|  1 -
>   drivers/gpu/drm/i915/intel_dp_mst.c|  1 -
>   drivers/gpu/drm/i915/intel_dsi.c   |  1 -
>   drivers/gpu/drm/i915/intel_dvo.c   |  1 -
>   drivers/gpu/drm/i915/intel_hdmi.c  |  1 -
>   drivers/gpu/drm/i915/intel_lvds.c  |  1 -
>   drivers/gpu/drm/i915/intel_sdvo.c  |  1 -
>   drivers/gpu/drm/i915/intel_tv.c|  1 -
>   drivers/gpu/drm/imx/imx-ldb.c  |  1 -
>   drivers/gpu/drm/imx/imx-tve.c  |  1 -
>   drivers/gpu/drm/imx/parallel-display.c |  1 -
>   drivers/gpu/drm/mediatek/mtk_dsi.c |  1 -
>   drivers/gpu/drm/mediatek/mtk_hdmi.c|  1 -
>   drivers/gpu/drm/meson/meson_venc_cvbs.c|  1 -
>   drivers/gpu/drm/msm/dsi/dsi_manager.c  |  1 -
>   drivers/gpu/drm/msm/edp/edp_connector.c|  1 -
>   drivers/gpu/drm/msm/hdmi/hdmi_connector.c  |  1 -
>   drivers/gpu/drm/msm/mdp/mdp4/mdp4_lvds_connector.c |  1 -
>   drivers/gpu/drm/mxsfb/mxsfb_out.c  |  1 -
>   drivers/gpu/drm/nouveau/nouveau_connector.c| 12 +---
>   drivers/gpu/drm/nouveau/nv50_display.c |  1 -
>   drivers/gpu/drm/omapdrm/omap_connector.c   |  1 -
>   drivers/gpu/drm/pl111/pl111_connector.c|  1 -
>   drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c  |  1 -
>   drivers/gpu/drm/rockchip/cdn-dp-core.c   

Re: [PATCH 4/8] drm: Nuke drm_atomic_helper_crtc_set_property

2017-07-25 Thread Philippe CORNU


On 07/25/2017 10:01 AM, Daniel Vetter wrote:
> It's dead code because this is now handled in the core.
> 
> Signed-off-by: Daniel Vetter 
> Cc: Boris Brezillon 
> Cc: Daniel Vetter 
> Cc: Jani Nikula 
> Cc: Sean Paul 
> Cc: David Airlie 
> Cc: Ben Skeggs 
> Cc: Tomi Valkeinen 
> Cc: Laurent Pinchart 
> Cc: Alexey Brodkin 
> Cc: Shawn Guo 
> Cc: Eric Engestrom 
> Cc: Chris Wilson 
> Cc: "Ville Syrjälä" 
> Cc: Rob Clark 
> Cc: Philippe Cornu 

Tested-by: Philippe Cornu 

Many thanks
Philippe :-)

> Cc: Masahiro Yamada 
> Cc: Sushmita Susheelendra 
> Cc: Archit Taneja 
> Cc: intel-...@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Cc: Philipp Zabel 
> Cc: Maxime Ripard 
> Cc: Thomas Hellstrom 
> ---
>   drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c  |  1 -
>   drivers/gpu/drm/drm_atomic_helper.c | 55 
> -
>   drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c |  1 -
>   drivers/gpu/drm/i915/intel_display.c|  1 -
>   drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c|  1 -
>   drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c|  2 -
>   drivers/gpu/drm/nouveau/nv50_display.c  |  1 -
>   drivers/gpu/drm/omapdrm/omap_crtc.c |  1 -
>   include/drm/drm_atomic_helper.h |  3 --
>   9 files changed, 66 deletions(-)
> 
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> index 4fbbeab5c5d4..d73281095fac 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> @@ -431,7 +431,6 @@ static const struct drm_crtc_funcs atmel_hlcdc_crtc_funcs 
> = {
>   .atomic_destroy_state = atmel_hlcdc_crtc_destroy_state,
>   .enable_vblank = atmel_hlcdc_crtc_enable_vblank,
>   .disable_vblank = atmel_hlcdc_crtc_disable_vblank,
> - .set_property = drm_atomic_helper_crtc_set_property,
>   .gamma_set = drm_atomic_helper_legacy_gamma_set,
>   };
>   
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 4a960c741e35..22245aa8b1aa 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2968,61 +2968,6 @@ int drm_atomic_helper_resume(struct drm_device *dev,
>   EXPORT_SYMBOL(drm_atomic_helper_resume);
>   
>   /**
> - * drm_atomic_helper_crtc_set_property - helper for crtc properties
> - * @crtc: DRM crtc
> - * @property: DRM property
> - * @val: value of property
> - *
> - * Provides a default crtc set_property handler using the atomic driver
> - * interface.
> - *
> - * RETURNS:
> - * Zero on success, error code on failure
> - */
> -int
> -drm_atomic_helper_crtc_set_property(struct drm_crtc *crtc,
> - struct drm_property *property,
> - uint64_t val)
> -{
> - struct drm_atomic_state *state;
> - struct drm_crtc_state *crtc_state;
> - int ret = 0;
> -
> - state = drm_atomic_state_alloc(crtc->dev);
> - if (!state)
> - return -ENOMEM;
> -
> - /* ->set_property is always called with all locks held. */
> - state->acquire_ctx = crtc->dev->mode_config.acquire_ctx;
> -retry:
> - crtc_state = drm_atomic_get_crtc_state(state, crtc);
> - if (IS_ERR(crtc_state)) {
> - ret = PTR_ERR(crtc_state);
> - goto fail;
> - }
> -
> - ret = drm_atomic_crtc_set_property(crtc, crtc_state,
> - property, val);
> - if (ret)
> - goto fail;
> -
> - ret = drm_atomic_commit(state);
> -fail:
> - if (ret == -EDEADLK)
> - goto backoff;
> -
> - drm_atomic_state_put(state);
> - return ret;
> -
> -backoff:
> - drm_atomic_state_clear(state);
> - drm_atomic_legacy_backoff(state);
> -
> - goto retry;
> -}
> -EXPORT_SYMBOL(drm_atomic_helper_crtc_set_property);
> -
> -/**
>* drm_atomic_helper_plane_set_property - helper for plane properties
>* @plane: DRM plane
>* @property: DRM property
> diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c 
> b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
> index 706efd0c4190..961551135a39 100644
> --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
> +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
> @@ -567,7 +567,6 @@ static const struct drm_crtc_funcs ade_crtc_funcs = {
>   .set_config = drm_atomic_helper_set_config,
>   .page_flip  = drm_atomic_helper_page_flip,
>   .reset  = drm_atomic_helper_crtc_reset,
> - .set_property = drm_atomic_helper_crtc_set_property,
>   .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
>   .atomic_destroy_state   = drm_atomic_helper_crtc_destroy_state,
>   .enable_vblank  = ade_crtc_enable_vblank,
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index f7b128c33aa1..b4d0c5298a53 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/

Re: [PATCH 5/8] drm: Nuke drm_atomic_helper_plane_set_property

2017-07-25 Thread Philippe CORNU


On 07/25/2017 10:01 AM, Daniel Vetter wrote:
> It's dead code, the core handles all this directly now. This also
> allows us to unexport drm_atomic_helper_plane_set_property.
> 
> Signed-off-by: Daniel Vetter 
> Cc: Liviu Dudau 
> Cc: Brian Starkey 
> Cc: Mali DP Maintainers 
> Cc: Boris Brezillon 
> Cc: Daniel Vetter 
> Cc: Jani Nikula 
> Cc: Sean Paul 
> Cc: David Airlie 
> Cc: Inki Dae 
> Cc: Joonyoung Shim 
> Cc: Seung-Woo Kim 
> Cc: Kyungmin Park 
> Cc: Kukjin Kim 
> Cc: Krzysztof Kozlowski 
> Cc: Ben Skeggs 
> Cc: Tomi Valkeinen 
> Cc: Laurent Pinchart 
> Cc: Benjamin Gaignard 
> Cc: Vincent Abriou 
> Cc: Yannick Fertre 
> Cc: Philippe Cornu 

for stm,

Acked-by: Philippe Cornu 
Tested-by: Philippe Cornu 

Many thanks
Philippe :-)

> Cc: Jyri Sarha 
> Cc: "Ville Syrjälä" 
> Cc: Rongrong Zou 
> Cc: Shawn Guo 
> Cc: Alexey Brodkin 
> Cc: Eric Engestrom 
> Cc: Chris Wilson 
> Cc: Rob Clark 
> Cc: Archit Taneja 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: intel-...@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Cc: linux-renesas-...@vger.kernel.org
> Cc: Thomas Hellstrom 
> Cc: Maxime Ripard 
> ---
>   drivers/gpu/drm/arm/malidp_planes.c |  1 -
>   drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c |  1 -
>   drivers/gpu/drm/drm_atomic.c|  3 +-
>   drivers/gpu/drm/drm_atomic_helper.c | 55 
> -
>   drivers/gpu/drm/exynos/exynos_drm_plane.c   |  1 -
>   drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c  |  1 -
>   drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c |  1 -
>   drivers/gpu/drm/i915/intel_display.c|  2 -
>   drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c   |  2 -
>   drivers/gpu/drm/nouveau/nv50_display.c  |  1 -
>   drivers/gpu/drm/omapdrm/omap_plane.c|  1 -
>   drivers/gpu/drm/rcar-du/rcar_du_plane.c |  1 -
>   drivers/gpu/drm/rcar-du/rcar_du_vsp.c   |  1 -
>   drivers/gpu/drm/sti/sti_cursor.c|  1 -
>   drivers/gpu/drm/sti/sti_gdp.c   |  1 -
>   drivers/gpu/drm/sti/sti_hqvdp.c |  1 -
>   drivers/gpu/drm/stm/ltdc.c  |  1 -
>   drivers/gpu/drm/tilcdc/tilcdc_plane.c   |  1 -
>   include/drm/drm_atomic.h|  3 --
>   include/drm/drm_atomic_helper.h |  3 --
>   20 files changed, 1 insertion(+), 81 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/malidp_planes.c 
> b/drivers/gpu/drm/arm/malidp_planes.c
> index 600fa7bd7f52..0f0f8234fe21 100644
> --- a/drivers/gpu/drm/arm/malidp_planes.c
> +++ b/drivers/gpu/drm/arm/malidp_planes.c
> @@ -128,7 +128,6 @@ static void malidp_plane_atomic_print_state(struct 
> drm_printer *p,
>   static const struct drm_plane_funcs malidp_de_plane_funcs = {
>   .update_plane = drm_atomic_helper_update_plane,
>   .disable_plane = drm_atomic_helper_disable_plane,
> - .set_property = drm_atomic_helper_plane_set_property,
>   .destroy = malidp_de_plane_destroy,
>   .reset = malidp_plane_reset,
>   .atomic_duplicate_state = malidp_duplicate_plane_state,
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c 
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> index b5bd9b005225..9cd9e23e75c6 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> @@ -1052,7 +1052,6 @@ static void 
> atmel_hlcdc_plane_atomic_destroy_state(struct drm_plane *p,
>   static struct drm_plane_funcs layer_plane_funcs = {
>   .update_plane = drm_atomic_helper_update_plane,
>   .disable_plane = drm_atomic_helper_disable_plane,
> - .set_property = drm_atomic_helper_plane_set_property,
>   .destroy = atmel_hlcdc_plane_destroy,
>   .reset = atmel_hlcdc_plane_reset,
>   .atomic_duplicate_state = atmel_hlcdc_plane_atomic_duplicate_state,
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 0fd14aff7add..395438a7a576 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -713,7 +713,7 @@ EXPORT_SYMBOL(drm_atomic_get_plane_state);
>* RETURNS:
>* Zero on success, error code on failure
>*/
> -int drm_atomic_plane_set_property(struct drm_plane *plane,
> +static int drm_atomic_plane_set_property(struct drm_plane *plane,
>   struct drm_plane_state *state, struct drm_property *property,
>   uint64_t val)
>   {
> @@ -770,7 +770,6 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
>   
>   return 0;
>   }
> -EXPORT_SYMBOL(drm_atomic_plane_set_property);
>   
>   /**
>* drm_atomic_plane_get_property - get property value from plane state
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 22245aa8b1aa..0482e39a7889 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2968,61 +2968,6 @@ int drm_atomic_helper_r

Re: [PATCH 5/8] drm: Nuke drm_atomic_helper_plane_set_property

2017-07-25 Thread Archit Taneja



On 07/25/2017 01:31 PM, Daniel Vetter wrote:

It's dead code, the core handles all this directly now. This also
allows us to unexport drm_atomic_helper_plane_set_property.



Reviewed-by: Archit Taneja 


Signed-off-by: Daniel Vetter 
Cc: Liviu Dudau 
Cc: Brian Starkey 
Cc: Mali DP Maintainers 
Cc: Boris Brezillon 
Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: Sean Paul 
Cc: David Airlie 
Cc: Inki Dae 
Cc: Joonyoung Shim 
Cc: Seung-Woo Kim 
Cc: Kyungmin Park 
Cc: Kukjin Kim 
Cc: Krzysztof Kozlowski 
Cc: Ben Skeggs 
Cc: Tomi Valkeinen 
Cc: Laurent Pinchart 
Cc: Benjamin Gaignard 
Cc: Vincent Abriou 
Cc: Yannick Fertre 
Cc: Philippe Cornu 
Cc: Jyri Sarha 
Cc: "Ville Syrjälä" 
Cc: Rongrong Zou 
Cc: Shawn Guo 
Cc: Alexey Brodkin 
Cc: Eric Engestrom 
Cc: Chris Wilson 
Cc: Rob Clark 
Cc: Archit Taneja 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: intel-...@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Cc: linux-renesas-...@vger.kernel.org
Cc: Thomas Hellstrom 
Cc: Maxime Ripard 
---
  drivers/gpu/drm/arm/malidp_planes.c |  1 -
  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c |  1 -
  drivers/gpu/drm/drm_atomic.c|  3 +-
  drivers/gpu/drm/drm_atomic_helper.c | 55 -
  drivers/gpu/drm/exynos/exynos_drm_plane.c   |  1 -
  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c  |  1 -
  drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c |  1 -
  drivers/gpu/drm/i915/intel_display.c|  2 -
  drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c   |  2 -
  drivers/gpu/drm/nouveau/nv50_display.c  |  1 -
  drivers/gpu/drm/omapdrm/omap_plane.c|  1 -
  drivers/gpu/drm/rcar-du/rcar_du_plane.c |  1 -
  drivers/gpu/drm/rcar-du/rcar_du_vsp.c   |  1 -
  drivers/gpu/drm/sti/sti_cursor.c|  1 -
  drivers/gpu/drm/sti/sti_gdp.c   |  1 -
  drivers/gpu/drm/sti/sti_hqvdp.c |  1 -
  drivers/gpu/drm/stm/ltdc.c  |  1 -
  drivers/gpu/drm/tilcdc/tilcdc_plane.c   |  1 -
  include/drm/drm_atomic.h|  3 --
  include/drm/drm_atomic_helper.h |  3 --
  20 files changed, 1 insertion(+), 81 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_planes.c 
b/drivers/gpu/drm/arm/malidp_planes.c
index 600fa7bd7f52..0f0f8234fe21 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -128,7 +128,6 @@ static void malidp_plane_atomic_print_state(struct 
drm_printer *p,
  static const struct drm_plane_funcs malidp_de_plane_funcs = {
.update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
-   .set_property = drm_atomic_helper_plane_set_property,
.destroy = malidp_de_plane_destroy,
.reset = malidp_plane_reset,
.atomic_duplicate_state = malidp_duplicate_plane_state,
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
index b5bd9b005225..9cd9e23e75c6 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
@@ -1052,7 +1052,6 @@ static void atmel_hlcdc_plane_atomic_destroy_state(struct 
drm_plane *p,
  static struct drm_plane_funcs layer_plane_funcs = {
.update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
-   .set_property = drm_atomic_helper_plane_set_property,
.destroy = atmel_hlcdc_plane_destroy,
.reset = atmel_hlcdc_plane_reset,
.atomic_duplicate_state = atmel_hlcdc_plane_atomic_duplicate_state,
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 0fd14aff7add..395438a7a576 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -713,7 +713,7 @@ EXPORT_SYMBOL(drm_atomic_get_plane_state);
   * RETURNS:
   * Zero on success, error code on failure
   */
-int drm_atomic_plane_set_property(struct drm_plane *plane,
+static int drm_atomic_plane_set_property(struct drm_plane *plane,
struct drm_plane_state *state, struct drm_property *property,
uint64_t val)
  {
@@ -770,7 +770,6 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
  
  	return 0;

  }
-EXPORT_SYMBOL(drm_atomic_plane_set_property);
  
  /**

   * drm_atomic_plane_get_property - get property value from plane state
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 22245aa8b1aa..0482e39a7889 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2968,61 +2968,6 @@ int drm_atomic_helper_resume(struct drm_device *dev,
  EXPORT_SYMBOL(drm_atomic_helper_resume);
  
  /**

- * drm_atomic_helper_plane_set_property - helper for plane properties
- * @plane: DRM plane
- * @property: DRM property
- * @val: value of property
- *
- * Provides a default plane set_pr

Re: [PATCH 4/8] drm: Nuke drm_atomic_helper_crtc_set_property

2017-07-25 Thread Archit Taneja



On 07/25/2017 01:31 PM, Daniel Vetter wrote:

It's dead code because this is now handled in the core.


Reviewed-by: Archit Taneja 



Signed-off-by: Daniel Vetter 
Cc: Boris Brezillon 
Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: Sean Paul 
Cc: David Airlie 
Cc: Ben Skeggs 
Cc: Tomi Valkeinen 
Cc: Laurent Pinchart 
Cc: Alexey Brodkin 
Cc: Shawn Guo 
Cc: Eric Engestrom 
Cc: Chris Wilson 
Cc: "Ville Syrjälä" 
Cc: Rob Clark 
Cc: Philippe Cornu 
Cc: Masahiro Yamada 
Cc: Sushmita Susheelendra 
Cc: Archit Taneja 
Cc: intel-...@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Cc: Philipp Zabel 
Cc: Maxime Ripard 
Cc: Thomas Hellstrom 
---
  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c  |  1 -
  drivers/gpu/drm/drm_atomic_helper.c | 55 -
  drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c |  1 -
  drivers/gpu/drm/i915/intel_display.c|  1 -
  drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c|  1 -
  drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c|  2 -
  drivers/gpu/drm/nouveau/nv50_display.c  |  1 -
  drivers/gpu/drm/omapdrm/omap_crtc.c |  1 -
  include/drm/drm_atomic_helper.h |  3 --
  9 files changed, 66 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index 4fbbeab5c5d4..d73281095fac 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -431,7 +431,6 @@ static const struct drm_crtc_funcs atmel_hlcdc_crtc_funcs = 
{
.atomic_destroy_state = atmel_hlcdc_crtc_destroy_state,
.enable_vblank = atmel_hlcdc_crtc_enable_vblank,
.disable_vblank = atmel_hlcdc_crtc_disable_vblank,
-   .set_property = drm_atomic_helper_crtc_set_property,
.gamma_set = drm_atomic_helper_legacy_gamma_set,
  };
  
diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c

index 4a960c741e35..22245aa8b1aa 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2968,61 +2968,6 @@ int drm_atomic_helper_resume(struct drm_device *dev,
  EXPORT_SYMBOL(drm_atomic_helper_resume);
  
  /**

- * drm_atomic_helper_crtc_set_property - helper for crtc properties
- * @crtc: DRM crtc
- * @property: DRM property
- * @val: value of property
- *
- * Provides a default crtc set_property handler using the atomic driver
- * interface.
- *
- * RETURNS:
- * Zero on success, error code on failure
- */
-int
-drm_atomic_helper_crtc_set_property(struct drm_crtc *crtc,
-   struct drm_property *property,
-   uint64_t val)
-{
-   struct drm_atomic_state *state;
-   struct drm_crtc_state *crtc_state;
-   int ret = 0;
-
-   state = drm_atomic_state_alloc(crtc->dev);
-   if (!state)
-   return -ENOMEM;
-
-   /* ->set_property is always called with all locks held. */
-   state->acquire_ctx = crtc->dev->mode_config.acquire_ctx;
-retry:
-   crtc_state = drm_atomic_get_crtc_state(state, crtc);
-   if (IS_ERR(crtc_state)) {
-   ret = PTR_ERR(crtc_state);
-   goto fail;
-   }
-
-   ret = drm_atomic_crtc_set_property(crtc, crtc_state,
-   property, val);
-   if (ret)
-   goto fail;
-
-   ret = drm_atomic_commit(state);
-fail:
-   if (ret == -EDEADLK)
-   goto backoff;
-
-   drm_atomic_state_put(state);
-   return ret;
-
-backoff:
-   drm_atomic_state_clear(state);
-   drm_atomic_legacy_backoff(state);
-
-   goto retry;
-}
-EXPORT_SYMBOL(drm_atomic_helper_crtc_set_property);
-
-/**
   * drm_atomic_helper_plane_set_property - helper for plane properties
   * @plane: DRM plane
   * @property: DRM property
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
index 706efd0c4190..961551135a39 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
@@ -567,7 +567,6 @@ static const struct drm_crtc_funcs ade_crtc_funcs = {
.set_config = drm_atomic_helper_set_config,
.page_flip  = drm_atomic_helper_page_flip,
.reset  = drm_atomic_helper_crtc_reset,
-   .set_property = drm_atomic_helper_crtc_set_property,
.atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
.atomic_destroy_state   = drm_atomic_helper_crtc_destroy_state,
.enable_vblank  = ade_crtc_enable_vblank,
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index f7b128c33aa1..b4d0c5298a53 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12373,7 +12373,6 @@ static int intel_atomic_commit(struct drm_device *dev,
  static const struct drm_crtc_funcs intel_crtc_funcs = {
.gamma_set = drm_atomic_helper_legacy_gamma_s

[PATCH v13 7/7] drm/i915/gvt: Dmabuf support for GVT-g

2017-07-25 Thread Tina Zhang
This patch introduces a guest's framebuffer sharing mechanism based on
dma-buf subsystem. With this sharing mechanism, guest's framebuffer can
be shared between guest VM and host.

Signed-off-by: Tina Zhang 
---
 drivers/gpu/drm/i915/gvt/Makefile  |   2 +-
 drivers/gpu/drm/i915/gvt/dmabuf.c  | 380 +
 drivers/gpu/drm/i915/gvt/dmabuf.h  |  58 +
 drivers/gpu/drm/i915/gvt/gvt.c |   1 +
 drivers/gpu/drm/i915/gvt/gvt.h |   9 +
 drivers/gpu/drm/i915/gvt/hypercall.h   |   2 +
 drivers/gpu/drm/i915/gvt/kvmgt.c   |  42 
 drivers/gpu/drm/i915/gvt/mpt.h |  30 +++
 drivers/gpu/drm/i915/gvt/vgpu.c|   2 +-
 drivers/gpu/drm/i915/i915_gem_object.h |   2 +
 10 files changed, 526 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gvt/dmabuf.c
 create mode 100644 drivers/gpu/drm/i915/gvt/dmabuf.h

diff --git a/drivers/gpu/drm/i915/gvt/Makefile 
b/drivers/gpu/drm/i915/gvt/Makefile
index 019d596..18f43cb 100644
--- a/drivers/gpu/drm/i915/gvt/Makefile
+++ b/drivers/gpu/drm/i915/gvt/Makefile
@@ -2,7 +2,7 @@ GVT_DIR := gvt
 GVT_SOURCE := gvt.o aperture_gm.o handlers.o vgpu.o trace_points.o firmware.o \
interrupt.o gtt.o cfg_space.o opregion.o mmio.o display.o edid.o \
execlist.o scheduler.o sched_policy.o render.o cmd_parser.o \
-   fb_decoder.o
+   fb_decoder.o dmabuf.o
 
 ccflags-y  += -I$(src) -I$(src)/$(GVT_DIR)
 i915-y += $(addprefix $(GVT_DIR)/, 
$(GVT_SOURCE))
diff --git a/drivers/gpu/drm/i915/gvt/dmabuf.c 
b/drivers/gpu/drm/i915/gvt/dmabuf.c
new file mode 100644
index 000..b6ccd61f
--- /dev/null
+++ b/drivers/gpu/drm/i915/gvt/dmabuf.c
@@ -0,0 +1,380 @@
+/*
+ * Copyright 2017 Intel Corporation. All rights reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Authors:
+ *Zhiyuan Lv 
+ *
+ * Contributors:
+ *Xiaoguang Chen 
+ *Tina Zhang 
+ */
+
+#include 
+#include 
+#include 
+
+#include "i915_drv.h"
+#include "gvt.h"
+
+#define GEN8_DECODE_PTE(pte) (pte & GENMASK_ULL(63, 12))
+
+#define VBLNAK_TIMER_PERIOD 1600
+
+static struct sg_table *intel_vgpu_gem_get_pages(
+   struct drm_i915_gem_object *obj)
+{
+   struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
+   struct sg_table *st;
+   struct scatterlist *sg;
+   int i, ret;
+   gen8_pte_t __iomem *gtt_entries;
+   struct intel_vgpu_fb_info *fb_info;
+
+   fb_info = (struct intel_vgpu_fb_info *)obj->gvt_info;
+   if (WARN_ON(!fb_info))
+   return ERR_PTR(-ENODEV);
+
+   st = kmalloc(sizeof(*st), GFP_KERNEL);
+   if (!st)
+   return ERR_PTR(-ENOMEM);
+
+   ret = sg_alloc_table(st, fb_info->size, GFP_KERNEL);
+   if (ret) {
+   kfree(st);
+   return ERR_PTR(ret);
+   }
+   gtt_entries = (gen8_pte_t __iomem *)dev_priv->ggtt.gsm +
+   (fb_info->start >> PAGE_SHIFT);
+   for_each_sg(st->sgl, sg, fb_info->size, i) {
+   sg->offset = 0;
+   sg->length = PAGE_SIZE;
+   sg_dma_address(sg) =
+   GEN8_DECODE_PTE(readq(>t_entries[i]));
+   sg_dma_len(sg) = PAGE_SIZE;
+   }
+
+   return st;
+}
+
+static void intel_vgpu_gem_put_pages(struct drm_i915_gem_object *obj,
+   struct sg_table *pages)
+{
+   sg_free_table(pages);
+   kfree(pages);
+}
+
+static void intel_vgpu_gem_release(struct drm_i915_gem_object *obj)
+{
+   struct intel_vgpu_dmabuf_obj *dmabuf_obj;
+   struct intel_vgpu_fb_info *fb_info;
+   struct intel_vgpu *vgpu;
+   struct list_head *pos;
+
+   fb_info = (struct intel_vgpu_fb_info *)obj->gvt_info;
+   if (WARN_ON(!fb_info || !fb_info->vgpu)) {
+   gvt_err("gvt info is invalid\n");
+   goto out;
+   }
+
+ 

Re: [PATCH 3/8] drm: Handle properties in the core for atomic drivers

2017-07-25 Thread Archit Taneja



On 07/25/2017 01:31 PM, Daniel Vetter wrote:

The reason behind the original indirection through the helper
functions was to allow existing drivers to overwrite how they handle
properties. For example when a vendor-specific userspace had
expectations that didn't match atomic. That seemed likely, since
atomic is standardizing a _lot_ more of the behaviour of a kms driver.

But 20 drivers later there's no such need at all. Worse, this forces
all drivers to hook up the default behaviour, breaking userspace if
they forget to do that. And it forces us to export a bunch of core
function just for those helpers.

And finally, these helpers are the last places using
drm_atomic_legacy_backoff() and the implicit acquire_ctx.

This patch here just implements the new behaviour and updates the
docs. Follow-up patches will garbage-collect all the dead code.

v2: Fixup docs even better!

v3: Make it actually work ...


Reviewed-by: Archit Taneja 



Signed-off-by: Daniel Vetter 
---
  drivers/gpu/drm/drm_atomic.c|  60 ++--
  drivers/gpu/drm/drm_connector.c |   6 +-
  drivers/gpu/drm/drm_crtc_helper.c   |   3 +-
  drivers/gpu/drm/drm_crtc_internal.h |   7 +++
  drivers/gpu/drm/drm_mode_object.c   | 110 +++-
  include/drm/drm_connector.h |  10 ++--
  include/drm/drm_crtc.h  |   6 +-
  include/drm/drm_plane.h |   6 +-
  8 files changed, 158 insertions(+), 50 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 01192dd3ed79..0fd14aff7add 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1864,9 +1864,60 @@ static struct drm_pending_vblank_event 
*create_vblank_event(
return e;
  }
  
-static int atomic_set_prop(struct drm_atomic_state *state,

-   struct drm_mode_object *obj, struct drm_property *prop,
-   uint64_t prop_value)
+int drm_atomic_connector_commit_dpms(struct drm_atomic_state *state,
+struct drm_connector *connector,
+int mode)
+{
+   struct drm_connector *tmp_connector;
+   struct drm_connector_state *new_conn_state;
+   struct drm_crtc *crtc;
+   struct drm_crtc_state *crtc_state;
+   int i, ret, old_mode = connector->dpms;
+   bool active = false;
+
+   ret = drm_modeset_lock(&state->dev->mode_config.connection_mutex,
+  state->acquire_ctx);
+   if (ret)
+   return ret;
+
+   if (mode != DRM_MODE_DPMS_ON)
+   mode = DRM_MODE_DPMS_OFF;
+   connector->dpms = mode;
+
+   crtc = connector->state->crtc;
+   if (!crtc)
+   goto out;
+   ret = drm_atomic_add_affected_connectors(state, crtc);
+   if (ret)
+   goto out;
+
+   crtc_state = drm_atomic_get_crtc_state(state, crtc);
+   if (IS_ERR(crtc_state)) {
+   ret = PTR_ERR(crtc_state);
+   goto out;
+   }
+
+   for_each_new_connector_in_state(state, tmp_connector, new_conn_state, 
i) {
+   if (new_conn_state->crtc != crtc)
+   continue;
+   if (tmp_connector->dpms == DRM_MODE_DPMS_ON) {
+   active = true;
+   break;
+   }
+   }
+
+   crtc_state->active = active;
+   ret = drm_atomic_commit(state);
+out:
+   if (ret != 0)
+   connector->dpms = old_mode;
+   return ret;
+}
+
+int drm_atomic_set_property(struct drm_atomic_state *state,
+   struct drm_mode_object *obj,
+   struct drm_property *prop,
+   uint64_t prop_value)
  {
struct drm_mode_object *ref;
int ret;
@@ -2286,7 +2337,8 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
goto out;
}
  
-			ret = atomic_set_prop(state, obj, prop, prop_value);

+   ret = drm_atomic_set_property(state, obj, prop,
+ prop_value);
if (ret) {
drm_mode_object_put(obj);
goto out;
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 349104eadefe..12371f184019 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -717,9 +717,9 @@ DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
   *drivers, it remaps to controlling the "ACTIVE" property on the CRTC the
   *connector is linked to. Drivers should never set this property directly,
   *it is handled by the DRM core by calling the &drm_connector_funcs.dpms
- * callback. Atomic drivers should implement this hook using
- * drm_atomic_helper_connector_dpms(). This is the only property standard
- * connector property that userspace can change.
+ * c

[PATCH v13 5/7] vfio: ABI for mdev display dma-buf operation

2017-07-25 Thread Tina Zhang
Add VFIO_DEVICE_QUERY_GFX_PLANE ioctl command to let user mode query and
get the plan and its related information.

The dma-buf's life cycle is handled by user mode and tracked by kernel.
The returned fd in struct vfio_device_query_gfx_plane can be a new
fd or an old fd of a re-exported dma-buf. Host User mode can check the
value of fd and to see if it needs to create new resource according to
the new fd or just use the existed resource related to the old fd.

Signed-off-by: Tina Zhang 
---
 include/uapi/linux/vfio.h | 28 
 1 file changed, 28 insertions(+)

diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
index ae46105..827a230 100644
--- a/include/uapi/linux/vfio.h
+++ b/include/uapi/linux/vfio.h
@@ -502,6 +502,34 @@ struct vfio_pci_hot_reset {
 
 #define VFIO_DEVICE_PCI_HOT_RESET  _IO(VFIO_TYPE, VFIO_BASE + 13)
 
+/**
+ * VFIO_DEVICE_QUERY_GFX_PLANE - _IOW(VFIO_TYPE, VFIO_BASE + 14, struct 
vfio_device_query_gfx_plane)
+ *
+ * Set the drm_plane_type and retrieve information about the gfx plane.
+ *
+ * Return: 0 on success, -errno on failure.
+ */
+struct vfio_device_gfx_plane_info {
+   __u32 argsz;
+   __u32 flags;
+   /* in */
+   __u32 drm_plane_type;   /* type of plane: DRM_PLANE_TYPE_* */
+   /* out */
+   __u32 drm_format;   /* drm format of plane */
+   __u64 drm_format_mod;   /* tiled mode */
+   __u32 width;/* width of plane */
+   __u32 height;   /* height of plane */
+   __u32 stride;   /* stride of plane */
+   __u32 size; /* size of plane in bytes, align on page*/
+   __u32 x_pos;/* horizontal position of cursor plane, upper left 
corner in pixels */
+   __u32 y_pos;/* vertical position of cursor plane, upper left corner 
in lines*/
+   __u32 region_index;
+   __s32 fd;   /* dma-buf fd */
+};
+
+#define VFIO_DEVICE_QUERY_GFX_PLANE _IO(VFIO_TYPE, VFIO_BASE + 14)
+
+
 /*  API for Type1 VFIO IOMMU  */
 
 /**
-- 
2.7.4

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


[PATCH v13 6/7] drm/i915: Introduce GEM proxy

2017-07-25 Thread Tina Zhang
GEM proxy is a kind of GEM, whose backing physical memory is pinned
and produced by guest VM and is used by host as read only. With GEM
proxy, host is able to access guest physical memory through GEM object
interface. As GEM proxy is such a special kind of GEM, a new flag
I915_GEM_OBJECT_IS_PROXY is introduced to ban host from changing the
backing storage of GEM proxy.

Signed-off-by: Tina Zhang 
---
 drivers/gpu/drm/i915/i915_gem.c| 24 +++-
 drivers/gpu/drm/i915/i915_gem_object.h |  7 +++
 drivers/gpu/drm/i915/i915_gem_tiling.c |  8 
 3 files changed, 38 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 1b2dfa8..75530fb 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1624,6 +1624,16 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, void 
*data,
if (err)
goto out;
 
+   /* Proxy objects do not control access to the backing storage, ergo
+* they cannot be used as a means to manipulate the cache domain
+* tracking for that backing storage. The proxy object is always
+* considered to be outside of any cache domain.
+*/
+   if (i915_gem_object_is_proxy(obj)) {
+   err = -EPERM;
+   goto out;
+   }
+
/* Flush and acquire obj->pages so that we are coherent through
 * direct access in memory with previous cached writes through
 * shmemfs and that our cache domain tracking remains valid.
@@ -1680,6 +1690,10 @@ i915_gem_sw_finish_ioctl(struct drm_device *dev, void 
*data,
if (!obj)
return -ENOENT;
 
+   /* Proxy objects are barred from CPU access, so there is no
+* need to ban sw_finish as it is a nop.
+*/
+
/* Pinned buffers may be scanout, so flush the cache */
i915_gem_object_flush_if_display(obj);
i915_gem_object_put(obj);
@@ -1730,7 +1744,7 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *data,
 */
if (!obj->base.filp) {
i915_gem_object_put(obj);
-   return -EINVAL;
+   return -EPERM;
}
 
addr = vm_mmap(obj->base.filp, 0, args->size,
@@ -3764,6 +3778,14 @@ int i915_gem_set_caching_ioctl(struct drm_device *dev, 
void *data,
if (!obj)
return -ENOENT;
 
+   /* The caching mode of proxy object is handled by its generator, and not
+* expected to be changed by user mode.
+*/
+   if (i915_gem_object_is_proxy(obj)) {
+   ret = -EPERM;
+   goto out;
+   }
+
if (obj->cache_level == level)
goto out;
 
diff --git a/drivers/gpu/drm/i915/i915_gem_object.h 
b/drivers/gpu/drm/i915/i915_gem_object.h
index 5b19a49..f3b382a 100644
--- a/drivers/gpu/drm/i915/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/i915_gem_object.h
@@ -39,6 +39,7 @@ struct drm_i915_gem_object_ops {
unsigned int flags;
 #define I915_GEM_OBJECT_HAS_STRUCT_PAGE BIT(0)
 #define I915_GEM_OBJECT_IS_SHRINKABLE   BIT(1)
+#define I915_GEM_OBJECT_IS_PROXY   BIT(2)
 
/* Interface between the GEM object and its backing storage.
 * get_pages() is called once prior to the use of the associated set
@@ -300,6 +301,12 @@ i915_gem_object_is_shrinkable(const struct 
drm_i915_gem_object *obj)
 }
 
 static inline bool
+i915_gem_object_is_proxy(const struct drm_i915_gem_object *obj)
+{
+   return obj->ops->flags & I915_GEM_OBJECT_IS_PROXY;
+}
+
+static inline bool
 i915_gem_object_is_active(const struct drm_i915_gem_object *obj)
 {
return obj->active_count;
diff --git a/drivers/gpu/drm/i915/i915_gem_tiling.c 
b/drivers/gpu/drm/i915/i915_gem_tiling.c
index fb5231f..d12859d 100644
--- a/drivers/gpu/drm/i915/i915_gem_tiling.c
+++ b/drivers/gpu/drm/i915/i915_gem_tiling.c
@@ -345,6 +345,14 @@ i915_gem_set_tiling_ioctl(struct drm_device *dev, void 
*data,
if (!obj)
return -ENOENT;
 
+   /* The tiling mode of proxy objects is handled by its generator, and not
+* expected to be changed by user mode.
+*/
+   if (i915_gem_object_is_proxy(obj)) {
+   err = -EPERM;
+   goto err;
+   }
+
if (!i915_tiling_ok(obj, args->tiling_mode, args->stride)) {
err = -EINVAL;
goto err;
-- 
2.7.4

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


Re: [Intel-gfx] [PATCH 8/8] drm: Nuke drm_atomic_legacy_backoff

2017-07-25 Thread Maarten Lankhorst
Op 25-07-17 om 10:01 schreef Daniel Vetter:
> Finally all users are gone!
>
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_atomic.c | 32 
>  include/drm/drm_atomic.h |  2 --
>  2 files changed, 34 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 306fdca92abf..1b755439f591 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1588,38 +1588,6 @@ drm_atomic_add_affected_planes(struct drm_atomic_state 
> *state,
>  EXPORT_SYMBOL(drm_atomic_add_affected_planes);
>  
>  /**
> - * drm_atomic_legacy_backoff - locking backoff for legacy ioctls
> - * @state: atomic state
> - *
> - * This function should be used by legacy entry points which don't understand
> - * -EDEADLK semantics. For simplicity this one will grab all modeset locks 
> after
> - * the slowpath completed.
> - */
> -void drm_atomic_legacy_backoff(struct drm_atomic_state *state)
> -{
> - struct drm_device *dev = state->dev;
> - int ret;
> - bool global = false;
> -
> - if (WARN_ON(dev->mode_config.acquire_ctx == state->acquire_ctx)) {
> - global = true;
> -
> - dev->mode_config.acquire_ctx = NULL;
> - }
> -
> -retry:
> - drm_modeset_backoff(state->acquire_ctx);
> -
> - ret = drm_modeset_lock_all_ctx(dev, state->acquire_ctx);
> - if (ret)
> - goto retry;
> -
> - if (global)
> - dev->mode_config.acquire_ctx = state->acquire_ctx;
> -}
> -EXPORT_SYMBOL(drm_atomic_legacy_backoff);
You're missing one patch here. We should also mark dev->mode_config.acquire_ctx 
__private. That way atomic commits will never be able to use lock_all. :)

Though I think it requires fixing vmwgfx_fb.c and i915 first.

Otherwise series looks good, so with review comments addressed.

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


[PATCH v13 4/7] drm/i915/gvt: Add opregion support

2017-07-25 Thread Tina Zhang
Windows guest UPT driver can use operegion to configure the setting
for display. Without the opregion support, the display registers won't
be set and this blocks display model to get the correct information
of the guest display plane.

Signed-off-by: Bing Niu 
Signed-off-by: Xiaoguang Chen 
Signed-off-by: Tina Zhang 
---
 drivers/gpu/drm/i915/gvt/hypercall.h |   1 +
 drivers/gpu/drm/i915/gvt/kvmgt.c | 109 ++-
 drivers/gpu/drm/i915/gvt/mpt.h   |  15 +
 drivers/gpu/drm/i915/gvt/opregion.c  |  26 +++--
 drivers/gpu/drm/i915/gvt/vgpu.c  |   4 ++
 5 files changed, 146 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/hypercall.h 
b/drivers/gpu/drm/i915/gvt/hypercall.h
index df7f33a..32c345c 100644
--- a/drivers/gpu/drm/i915/gvt/hypercall.h
+++ b/drivers/gpu/drm/i915/gvt/hypercall.h
@@ -55,6 +55,7 @@ struct intel_gvt_mpt {
  unsigned long mfn, unsigned int nr, bool map);
int (*set_trap_area)(unsigned long handle, u64 start, u64 end,
 bool map);
+   int (*set_opregion)(void *vgpu);
 };
 
 extern struct intel_gvt_mpt xengt_mpt;
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index fd0c85f..6b0a330 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -53,11 +53,23 @@ static const struct intel_gvt_ops *intel_gvt_ops;
 #define VFIO_PCI_INDEX_TO_OFFSET(index) ((u64)(index) << VFIO_PCI_OFFSET_SHIFT)
 #define VFIO_PCI_OFFSET_MASK(((u64)(1) << VFIO_PCI_OFFSET_SHIFT) - 1)
 
+#define OPREGION_SIGNATURE "IntelGraphicsMem"
+
+struct vfio_region;
+struct intel_vgpu_regops {
+   size_t (*rw)(struct intel_vgpu *vgpu, char *buf,
+   size_t count, loff_t *ppos, bool iswrite);
+   void (*release)(struct intel_vgpu *vgpu,
+   struct vfio_region *region);
+};
+
 struct vfio_region {
u32 type;
u32 subtype;
size_t  size;
u32 flags;
+   const struct intel_vgpu_regops  *ops;
+   void*data;
 };
 
 struct kvmgt_pgfn {
@@ -430,6 +442,91 @@ static void kvmgt_protect_table_del(struct 
kvmgt_guest_info *info,
}
 }
 
+static size_t intel_vgpu_reg_rw_opregion(struct intel_vgpu *vgpu, char *buf,
+   size_t count, loff_t *ppos, bool iswrite)
+{
+   unsigned int i = VFIO_PCI_OFFSET_TO_INDEX(*ppos) -
+   VFIO_PCI_NUM_REGIONS;
+   void *base = vgpu->vdev.region[i].data;
+   loff_t pos = *ppos & VFIO_PCI_OFFSET_MASK;
+
+   if (pos >= vgpu->vdev.region[i].size || iswrite) {
+   gvt_vgpu_err("invalid op or offset for Intel vgpu OpRegion\n");
+   return -EINVAL;
+   }
+   count = min(count, (size_t)(vgpu->vdev.region[i].size - pos));
+   memcpy(buf, base + pos, count);
+
+   return count;
+}
+
+static void intel_vgpu_reg_release_opregion(struct intel_vgpu *vgpu,
+   struct vfio_region *region)
+{
+   memunmap(region->data);
+}
+
+static const struct intel_vgpu_regops intel_vgpu_regops_opregion = {
+   .rw = intel_vgpu_reg_rw_opregion,
+   .release = intel_vgpu_reg_release_opregion,
+};
+
+static int intel_vgpu_register_reg(struct intel_vgpu *vgpu,
+   unsigned int type, unsigned int subtype,
+   const struct intel_vgpu_regops *ops,
+   size_t size, u32 flags, void *data)
+{
+   struct vfio_region *region;
+
+   region = krealloc(vgpu->vdev.region,
+   (vgpu->vdev.num_regions + 1) * sizeof(*region),
+   GFP_KERNEL);
+   if (!region)
+   return -ENOMEM;
+
+   vgpu->vdev.region = region;
+   vgpu->vdev.region[vgpu->vdev.num_regions].type = type;
+   vgpu->vdev.region[vgpu->vdev.num_regions].subtype = subtype;
+   vgpu->vdev.region[vgpu->vdev.num_regions].ops = ops;
+   vgpu->vdev.region[vgpu->vdev.num_regions].size = size;
+   vgpu->vdev.region[vgpu->vdev.num_regions].flags = flags;
+   vgpu->vdev.region[vgpu->vdev.num_regions].data = data;
+   vgpu->vdev.num_regions++;
+
+   return 0;
+}
+
+static int kvmgt_set_opregion(void *p_vgpu)
+{
+   struct intel_vgpu *vgpu = (struct intel_vgpu *)p_vgpu;
+   unsigned int addr;
+   void *base;
+   int ret;
+
+   addr = vgpu->gvt->opregion.opregion_pa;
+   if (!addr || !(~addr))
+   return -ENODEV;
+
+   base = memremap(addr, OPREGION_SIZE, MEMREMAP_WB);
+   if (!base)
+   return -ENOMEM;
+
+   if (memcmp(base, OPREGION_SIGNATURE, 16)) {
+   memunmap(base);
+   return -EINVAL;
+   }
+
+   ret = intel_vgpu_register_reg(vgpu,
+   PCI_VENDOR_ID_INTEL | VFIO_REGION_TYPE_PCI_VENDOR_TYPE,
+   VFIO_REGION_SUBTYPE_INT

[PATCH v13 3/7] drm/i915/gvt: Add RGB 64-bit 16:16:16:16 float format support

2017-07-25 Thread Tina Zhang
The RGB 64-bit 16:16:16:16 float pixel format is needed by windows 10
guest VM. This patch is to add this pixel format support to gvt device
model. Without this patch, some Apps, e.g. "DXGIGammaVM.exe", will crash
and make guest screen black.

Signed-off-by: Xiaoguang Chen 
Signed-off-by: Tina Zhang 
---
 drivers/gpu/drm/i915/gvt/fb_decoder.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/i915/gvt/fb_decoder.c 
b/drivers/gpu/drm/i915/gvt/fb_decoder.c
index 2bd5b3c..739ca81 100644
--- a/drivers/gpu/drm/i915/gvt/fb_decoder.c
+++ b/drivers/gpu/drm/i915/gvt/fb_decoder.c
@@ -54,6 +54,8 @@ static struct pixel_format 
bdw_pixel_formats[PRIMARY_FORMAT_NUM] = {
"32-bit RGBX (2:10:10:10 MSB-X:B:G:R)"},
[0xa] = {DRM_FORMAT_XRGB2101010, 32,
"32-bit BGRX (2:10:10:10 MSB-X:R:G:B)"},
+   [0xc] = {DRM_FORMAT_XRGB161616, 64,
+   "64-bit RGBX Floating Point(16:16:16:16 MSB-X:B:G:R)"},
[0xe] = {DRM_FORMAT_XBGR, 32,
"32-bit RGBX (8:8:8:8 MSB-X:B:G:R)"},
 };
@@ -75,6 +77,10 @@ static struct pixel_format skl_pixel_formats[] = {
{DRM_FORMAT_XBGR2101010, 32, "32-bit RGBX (2:10:10:10 MSB-X:B:G:R)"},
{DRM_FORMAT_XRGB2101010, 32, "32-bit BGRX (2:10:10:10 MSB-X:R:G:B)"},
 
+   {DRM_FORMAT_XRGB161616, 64,
+   "64-bit XRGB (16:16:16:16 MSB-X:R:G:B)"},
+   {DRM_FORMAT_XBGR161616, 64,
+   "64-bit XBGR (16:16:16:16 MSB-X:B:G:R)"},
 
/* non-supported format has bpp default to 0 */
{0, 0, NULL},
@@ -101,6 +107,9 @@ static int skl_format_to_drm(int format, bool rgb_order, 
bool alpha,
case PLANE_CTL_FORMAT_XRGB_2101010:
skl_pixel_formats_index = rgb_order ? 10 : 11;
break;
+   case PLANE_CTL_FORMAT_XRGB_16161616F:
+   skl_pixel_formats_index = rgb_order ? 12 : 13;
+   break;
case PLANE_CTL_FORMAT_YUV422:
skl_pixel_formats_index = yuv_order >> 16;
if (skl_pixel_formats_index > 3)
@@ -321,6 +330,8 @@ static struct pixel_format 
sprite_pixel_formats[SPRITE_FORMAT_NUM] = {
[0x0]  = {DRM_FORMAT_YUV422, 16, "YUV 16-bit 4:2:2 packed"},
[0x1]  = {DRM_FORMAT_XRGB2101010, 32, "RGB 32-bit 2:10:10:10"},
[0x2]  = {DRM_FORMAT_XRGB, 32, "RGB 32-bit 8:8:8:8"},
+   [0x3]  = {DRM_FORMAT_XRGB161616, 64,
+   "RGB 64-bit 16:16:16:16 Floating Point"},
[0x4] = {DRM_FORMAT_AYUV, 32,
"YUV 32-bit 4:4:4 packed (8:8:8:8 MSB-X:Y:U:V)"},
 };
-- 
2.7.4

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


[PATCH v13 2/7] drm: Introduce RGB 64-bit 16:16:16:16 float format

2017-07-25 Thread Tina Zhang
The RGB 64-bit 16:16:16:16 float pixel format is needed by windows
guest VM. This patch is to introduce the format to drm.

v1:
Suggested by Ville to submit this patch to dri-devel.

Signed-off-by: Xiaoguang Chen 
Signed-off-by: Tina Zhang 
---
 include/uapi/drm/drm_fourcc.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 7586c46..3e002e3 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -113,6 +113,10 @@ extern "C" {
 
 #define DRM_FORMAT_AYUVfourcc_code('A', 'Y', 'U', 'V') /* 
[31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
 
+/* 64 bpp RGB */
+#define DRM_FORMAT_XRGB161616  fourcc_code('X', 'R', '4', '8') /* [63:0] 
x:R:G:B 16:16:16:16 little endian */
+#define DRM_FORMAT_XBGR161616  fourcc_code('X', 'B', '4', '8') /* [63:0] 
x:B:G:R 16:16:16:16 little endian */
+
 /*
  * 2 plane RGB + A
  * index 0 = RGB plane, same format as the corresponding non _A8 format has
-- 
2.7.4

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


[PATCH v13 1/7] drm/i915/gvt: Add framebuffer decoder support

2017-07-25 Thread Tina Zhang
Framebuffer decoder returns guest framebuffer information.
Guest framebuffer includes primary, cursor and sprite plane.

Signed-off-by: Xiaoguang Chen 
Signed-off-by: Tina Zhang 
---
 drivers/gpu/drm/i915/gvt/Makefile |   3 +-
 drivers/gpu/drm/i915/gvt/display.c|   2 +-
 drivers/gpu/drm/i915/gvt/display.h|   2 +
 drivers/gpu/drm/i915/gvt/fb_decoder.c | 429 ++
 drivers/gpu/drm/i915/gvt/fb_decoder.h | 175 ++
 drivers/gpu/drm/i915/gvt/gvt.h|   1 +
 6 files changed, 610 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gvt/fb_decoder.c
 create mode 100644 drivers/gpu/drm/i915/gvt/fb_decoder.h

diff --git a/drivers/gpu/drm/i915/gvt/Makefile 
b/drivers/gpu/drm/i915/gvt/Makefile
index f5486cb9..019d596 100644
--- a/drivers/gpu/drm/i915/gvt/Makefile
+++ b/drivers/gpu/drm/i915/gvt/Makefile
@@ -1,7 +1,8 @@
 GVT_DIR := gvt
 GVT_SOURCE := gvt.o aperture_gm.o handlers.o vgpu.o trace_points.o firmware.o \
interrupt.o gtt.o cfg_space.o opregion.o mmio.o display.o edid.o \
-   execlist.o scheduler.o sched_policy.o render.o cmd_parser.o
+   execlist.o scheduler.o sched_policy.o render.o cmd_parser.o \
+   fb_decoder.o
 
 ccflags-y  += -I$(src) -I$(src)/$(GVT_DIR)
 i915-y += $(addprefix $(GVT_DIR)/, 
$(GVT_SOURCE))
diff --git a/drivers/gpu/drm/i915/gvt/display.c 
b/drivers/gpu/drm/i915/gvt/display.c
index 2deb05f..58d90cf 100644
--- a/drivers/gpu/drm/i915/gvt/display.c
+++ b/drivers/gpu/drm/i915/gvt/display.c
@@ -67,7 +67,7 @@ static int edp_pipe_is_enabled(struct intel_vgpu *vgpu)
return 1;
 }
 
-static int pipe_is_enabled(struct intel_vgpu *vgpu, int pipe)
+int pipe_is_enabled(struct intel_vgpu *vgpu, int pipe)
 {
struct drm_i915_private *dev_priv = vgpu->gvt->dev_priv;
 
diff --git a/drivers/gpu/drm/i915/gvt/display.h 
b/drivers/gpu/drm/i915/gvt/display.h
index d73de22..b46b868 100644
--- a/drivers/gpu/drm/i915/gvt/display.h
+++ b/drivers/gpu/drm/i915/gvt/display.h
@@ -179,4 +179,6 @@ int intel_vgpu_init_display(struct intel_vgpu *vgpu, u64 
resolution);
 void intel_vgpu_reset_display(struct intel_vgpu *vgpu);
 void intel_vgpu_clean_display(struct intel_vgpu *vgpu);
 
+int pipe_is_enabled(struct intel_vgpu *vgpu, int pipe);
+
 #endif
diff --git a/drivers/gpu/drm/i915/gvt/fb_decoder.c 
b/drivers/gpu/drm/i915/gvt/fb_decoder.c
new file mode 100644
index 000..2bd5b3c
--- /dev/null
+++ b/drivers/gpu/drm/i915/gvt/fb_decoder.c
@@ -0,0 +1,429 @@
+/*
+ * Copyright(c) 2011-2016 Intel Corporation. All rights reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN 
THE
+ * SOFTWARE.
+ *
+ * Authors:
+ *Kevin Tian 
+ *
+ * Contributors:
+ *Bing Niu 
+ *Xu Han 
+ *Ping Gao 
+ *Xiaoguang Chen 
+ *Yang Liu 
+ *Tina Zhang 
+ *
+ */
+
+#include 
+#include "i915_drv.h"
+#include "gvt.h"
+
+#define PRIMARY_FORMAT_NUM 16
+struct pixel_format {
+   int drm_format; /* Pixel format in DRM definition */
+   int bpp;/* Bits per pixel, 0 indicates invalid */
+   char *desc; /* The description */
+};
+
+/* non-supported format has bpp default to 0 */
+static struct pixel_format bdw_pixel_formats[PRIMARY_FORMAT_NUM] = {
+   [0x2] = {DRM_FORMAT_C8, 8, "8-bit Indexed"},
+   [0x5] = {DRM_FORMAT_RGB565, 16, "16-bit BGRX (5:6:5 MSB-R:G:B)"},
+   [0x6] = {DRM_FORMAT_XRGB, 32,
+   "32-bit BGRX (8:8:8:8 MSB-X:R:G:B)"},
+   [0x8] = {DRM_FORMAT_XBGR2101010, 32,
+   "32-bit RGBX (2:10:10:10 MSB-X:B:G:R)"},
+   [0xa] = {DRM_FORMAT_XRGB2101010, 32,
+   "32-bit BGRX (2:10:10:10 MSB-X:R:G:B)"},
+   [0xe] = {DRM_FORMAT_XBGR, 32,
+   "32-bit RGBX (8:8:8:8 MSB-X:B:G:R)"},
+};
+
+/* non-supported format has bpp default to 0 */
+static struct pixel_format skl_pixel_formats[] = {
+ 

[PATCH v13 0/7] drm/i915/gvt: Dma-buf support for GVT-g

2017-07-25 Thread Tina Zhang
v12->v13:
1) add comments to GEM proxy. (Chris)
2) don't ban GEM proxy in i915_gem_sw_finish_ioctl. (Chris)
3) check GEM proxy bar after finishing i915_gem_object_wait. (Chris)
4) remove GEM proxy bar in i915_gem_madvise_ioctl.

v11->v12:
1) add drm_format_mod back. (Gerd and Zhenyu)
2) add region_index. (Gerd)
3) refine the lifecycle of dmabuf.
4) send to dri-devel@lists.freedesktop.org. (Ville) 

v10->v11:
1) rename plane_type to drm_plane_type. (Gerd)
2) move fields of vfio_device_query_gfx_plane to
   vfio_device_gfx_plane_info. (Gerd)
3) remove drm_format_mod, start fields. (Daniel)
4) remove plane_id.

v9->v10:
1) remove dma-buf management
2) refine the ABI API VFIO_DEVICE_QUERY_GFX_PLANE
3) track the dma-buf create and release in kernel mode

v8->v9:
1) refine the dma-buf ioctl definition
2) add a lock to protect the dmabuf list
3) move drm format change to a separate patch
4) codes cleanup

v7->v8:
1) refine framebuffer decoder code
2) fix a bug in decoding primary plane

v6->v7:
1) release dma-buf related allocations in dma-buf's associated release
   function.
2) refine ioctl interface for querying plane info or create dma-buf
3) refine framebuffer decoder code
4) the patch series is based on 4.12.0-rc1

v5->v6:
1) align the dma-buf life cycle with the vfio device.
2) add the dma-buf releated operations in a separate patch.
3) i915 releated changes.

v4->v5:
1) fix bug while checking whether the gem obj is gvt's dma-buf when user
   change caching mode or domains. Add a helper function to do it.
2) add definition for the query plane and create dma-buf.

v3->v4:
1) fix bug while checking whether the gem obj is gvt's dma-buf when set
   caching mode or doamins.

v2->v3:
1) add a field gvt_plane_info in the drm_i915_gem_obj structure to save
   the decoded plane information to avoid look up while need the plane info.
2) declare a new flag I915_GEM_OBJECT_IS_GVT_DMABUF in drm_i915_gem_object
   to represent the gem obj for gvt's dma-buf. The tiling mode, caching mode
   and domains can not be changed for this kind of gem object.
3) change dma-buf related information to be more generic. So other vendor
   can use the same interface.

v1->v2:
1) create a management fd for dma-buf operations.
2) alloc gem object's backing storage in gem obj's get_pages() callback.

This patch set adds the dma-buf support for intel GVT-g.
dma-buf is a uniform mechanism to share DMA buffers across different
devices and sub-systems.
dma-buf for intel GVT-g is mainly used to share the vgpu's framebuffer
to other users or sub-systems so they can use the dma-buf to show the
desktop of a vm which uses intel vgpu.

The main idea is we create a gem object and set vgpu's framebuffer as
the backing storage of this gem object. And associate this gem obj
to a dma-buf object then export this dma-buf at the meantime
generate a file descriptor for this dma-buf. Finally deliver this file
descriptor to user space. And user can use this dma-buf fd to do render
or other operations.


Tina Zhang (7):
  drm/i915/gvt: Add framebuffer decoder support
  drm: Introduce RGB 64-bit 16:16:16:16 float format
  drm/i915/gvt: Add RGB 64-bit 16:16:16:16 float format support
  drm/i915/gvt: Add opregion support
  vfio: ABI for mdev display dma-buf operation
  drm/i915: Introduce GEM proxy
  drm/i915/gvt: Dmabuf support for GVT-g

 drivers/gpu/drm/i915/gvt/Makefile  |   3 +-
 drivers/gpu/drm/i915/gvt/display.c |   2 +-
 drivers/gpu/drm/i915/gvt/display.h |   2 +
 drivers/gpu/drm/i915/gvt/dmabuf.c  | 380 
 drivers/gpu/drm/i915/gvt/dmabuf.h  |  58 +
 drivers/gpu/drm/i915/gvt/fb_decoder.c  | 440 +
 drivers/gpu/drm/i915/gvt/fb_decoder.h  | 175 +
 drivers/gpu/drm/i915/gvt/gvt.c |   1 +
 drivers/gpu/drm/i915/gvt/gvt.h |  10 +
 drivers/gpu/drm/i915/gvt/hypercall.h   |   3 +
 drivers/gpu/drm/i915/gvt/kvmgt.c   | 151 ++-
 drivers/gpu/drm/i915/gvt/mpt.h |  45 
 drivers/gpu/drm/i915/gvt/opregion.c|  26 +-
 drivers/gpu/drm/i915/gvt/vgpu.c|   6 +-
 drivers/gpu/drm/i915/i915_gem.c|  24 +-
 drivers/gpu/drm/i915/i915_gem_object.h |   9 +
 drivers/gpu/drm/i915/i915_gem_tiling.c |   8 +
 include/uapi/drm/drm_fourcc.h  |   4 +
 include/uapi/linux/vfio.h  |  28 +++
 19 files changed, 1362 insertions(+), 13 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gvt/dmabuf.c
 create mode 100644 drivers/gpu/drm/i915/gvt/dmabuf.h
 create mode 100644 drivers/gpu/drm/i915/gvt/fb_decoder.c
 create mode 100644 drivers/gpu/drm/i915/gvt/fb_decoder.h

-- 
2.7.4

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


Re: [PATCH 7/8] drm: Nuke drm_atomic_helper_connector_dpms

2017-07-25 Thread Archit Taneja



On 07/25/2017 01:31 PM, Daniel Vetter wrote:

It's dead code, the core handles all this directly now.

The only special case is nouveau and tda988x which used one function
for both legacy modeset code and -nv50 atomic world instead of 2
vtables. But amounts to exactly the same.

v2: Rebase over the panel/brideg refactorings in stm/ltdc.


s/brideg/bridge





---
  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c   |  1 -
  drivers/gpu/drm/bridge/analogix-anx78xx.c  |  1 -
  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |  1 -
  drivers/gpu/drm/bridge/dumb-vga-dac.c  |  1 -
  .../drm/bridge/megachips-stdp-ge-b850v3-fw.c   |  1 -
  drivers/gpu/drm/bridge/nxp-ptn3460.c   |  1 -
  drivers/gpu/drm/bridge/panel.c |  1 -
  drivers/gpu/drm/bridge/parade-ps8622.c |  1 -
  drivers/gpu/drm/bridge/sii902x.c   |  1 -
  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c  |  1 -
  drivers/gpu/drm/bridge/tc358767.c  |  1 -
  drivers/gpu/drm/bridge/ti-tfp410.c |  1 -


For bridge changes:

Acked-by: Archit Taneja 

Archit

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


Re: [PATCH v2 2/7] drm/atomic: Clean up drm_atomic_helper_async_check

2017-07-25 Thread Daniel Vetter
On Tue, Jul 25, 2017 at 11:11 AM, Maarten Lankhorst
 wrote:
> Op 25-07-17 om 10:23 schreef Daniel Vetter:
>> On Wed, Jul 19, 2017 at 04:39:15PM +0200, Maarten Lankhorst wrote:
>>>  /*
>>> - * Don't do an async update if there is an outstanding commit modifying
>>> - * the plane.  This prevents our async update's changes from getting
>>> - * overridden by a previous synchronous update's state.
>>> + * FIXME: We should prevent an async update if there is an outstanding
>>> + * commit modifying the plane.  This prevents our async update's
>>> + * changes from getting overwritten by a previous synchronous update's
>>> + * state.
>>>   */
>>> -for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
>>> -if (plane->crtc != crtc)
>>> -continue;
>>> -
>>> -spin_lock(&crtc->commit_lock);
>>> -commit = list_first_entry_or_null(&crtc->commit_list,
>>> -  struct drm_crtc_commit,
>>> -  commit_entry);
>>> -if (!commit) {
>>> -spin_unlock(&crtc->commit_lock);
>>> -continue;
>>> -}
>>> -spin_unlock(&crtc->commit_lock);
>>> -
>>> -if (!crtc->state->state)
>>> -continue;
>>> -
>>> -for_each_plane_in_state(crtc->state->state, __plane,
>>> -__plane_state, j) {
>> I'm pretty sure this oopses, because crtc->state->state is NULL after
>> commit. I think Gustavo needs to review this first (and write a nasty igt
>> testcase to catch it) before we remove this. I think the correct check is
>> to simply bail out if our current crtc has a pending commit (i.e.
>> !list_empty(&crtc->commit_list) should be all we need to check.
> It didn't oops. Right above it was a null check. It was never executed. :)
>
> obj->state->state is always NULL. Excluding a brief moment during swap_state 
> where this may oops,  this code willl never do a thing.

Oh right. It's still completely buggy, and I'd like to fix that first,
testcase included. Can you pls poke Gustavo a bit (or maybe he's on
vacation)?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [Intel-gfx] [PATCH 6/8] drm: Nuke drm_atomic_helper_connector_set_property

2017-07-25 Thread Daniel Vetter
On Tue, Jul 25, 2017 at 11:23 AM, Maarten Lankhorst
 wrote:
> Op 25-07-17 om 10:01 schreef Daniel Vetter:
>> It's dead code, the core handles all this directly now. This also
>> allows us to unexport drm_atomic_helper_connector_set_property.
>>
>> The only special case is nouveau which used one function for both
>> pre-nv50 legacy modeset code and post-nv50 atomic world instead of 2
>> vtables. But amounts to exactly the same.
>>
>> What is rather strange here is how few drivers set this up, I suspect
>> the earlier patch to handle properties in the core did end up fixing a
>> pile of possible issues.
> Legacy drivers didn't always hook it up either, probably why. :)
> No use hooking it up in legacy world if you didn't expose a property.
>
> But yeah, good to fix this.

With atomic, everyone has properties ...
-Daniel

>> Signed-off-by: Daniel Vetter 
>> Cc: Daniel Vetter 
>> Cc: Jani Nikula 
>> Cc: Sean Paul 
>> Cc: David Airlie 
>> Cc: Ben Skeggs 
>> Cc: Benjamin Gaignard 
>> Cc: Vincent Abriou 
>> Cc: Eric Anholt 
>> Cc: intel-...@lists.freedesktop.org
>> Cc: nouv...@lists.freedesktop.org
>> ---
>>  drivers/gpu/drm/drm_atomic.c|  3 +-
>>  drivers/gpu/drm/drm_atomic_helper.c | 55 
>> -
>>  drivers/gpu/drm/i915/intel_crt.c|  1 -
>>  drivers/gpu/drm/i915/intel_dp.c |  1 -
>>  drivers/gpu/drm/i915/intel_dp_mst.c |  1 -
>>  drivers/gpu/drm/i915/intel_dsi.c|  1 -
>>  drivers/gpu/drm/i915/intel_dvo.c|  1 -
>>  drivers/gpu/drm/i915/intel_hdmi.c   |  1 -
>>  drivers/gpu/drm/i915/intel_lvds.c   |  1 -
>>  drivers/gpu/drm/i915/intel_sdvo.c   |  1 -
>>  drivers/gpu/drm/i915/intel_tv.c |  1 -
>>  drivers/gpu/drm/nouveau/nouveau_connector.c |  3 --
>>  drivers/gpu/drm/nouveau/nv50_display.c  |  1 -
>>  drivers/gpu/drm/sti/sti_hdmi.c  |  1 -
>>  drivers/gpu/drm/vc4/vc4_vec.c   |  1 -
>>  include/drm/drm_atomic.h|  3 --
>>  include/drm/drm_atomic_helper.h |  3 --
>>  17 files changed, 1 insertion(+), 78 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
>> index 395438a7a576..306fdca92abf 100644
>> --- a/drivers/gpu/drm/drm_atomic.c
>> +++ b/drivers/gpu/drm/drm_atomic.c
>> @@ -1144,7 +1144,7 @@ EXPORT_SYMBOL(drm_atomic_get_connector_state);
>>   * RETURNS:
>>   * Zero on success, error code on failure
>>   */
>> -int drm_atomic_connector_set_property(struct drm_connector *connector,
>> +static int drm_atomic_connector_set_property(struct drm_connector 
>> *connector,
>>   struct drm_connector_state *state, struct drm_property 
>> *property,
>>   uint64_t val)
>>  {
>> @@ -1211,7 +1211,6 @@ int drm_atomic_connector_set_property(struct 
>> drm_connector *connector,
>>
>>   return 0;
>>  }
>> -EXPORT_SYMBOL(drm_atomic_connector_set_property);
>>
>>  static void drm_atomic_connector_print_state(struct drm_printer *p,
>>   const struct drm_connector_state *state)
>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
>> b/drivers/gpu/drm/drm_atomic_helper.c
>> index 0482e39a7889..1ca0dcca6230 100644
>> --- a/drivers/gpu/drm/drm_atomic_helper.c
>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
>> @@ -2967,61 +2967,6 @@ int drm_atomic_helper_resume(struct drm_device *dev,
>>  }
>>  EXPORT_SYMBOL(drm_atomic_helper_resume);
>>
>> -/**
>> - * drm_atomic_helper_connector_set_property - helper for connector 
>> properties
>> - * @connector: DRM connector
>> - * @property: DRM property
>> - * @val: value of property
>> - *
>> - * Provides a default connector set_property handler using the atomic driver
>> - * interface.
>> - *
>> - * RETURNS:
>> - * Zero on success, error code on failure
>> - */
>> -int
>> -drm_atomic_helper_connector_set_property(struct drm_connector *connector,
>> - struct drm_property *property,
>> - uint64_t val)
>> -{
>> - struct drm_atomic_state *state;
>> - struct drm_connector_state *connector_state;
>> - int ret = 0;
>> -
>> - state = drm_atomic_state_alloc(connector->dev);
>> - if (!state)
>> - return -ENOMEM;
>> -
>> - /* ->set_property is always called with all locks held. */
>> - state->acquire_ctx = connector->dev->mode_config.acquire_ctx;
>> -retry:
>> - connector_state = drm_atomic_get_connector_state(state, connector);
>> - if (IS_ERR(connector_state)) {
>> - ret = PTR_ERR(connector_state);
>> - goto fail;
>> - }
>> -
>> - ret = drm_atomic_connector_set_property(connector, connector_state,
>> - property, val);
>> - if (ret)
>> - goto fail;
>> -
>> - ret = drm_atomic_commit(state);
>> -fail:
>> - if (ret == -EDEADLK)
>> - goto backoff;
>> -
>> - drm_atomic_state_put(state);
>> - return ret;
>> -
>> -backoff:
>> - drm_a

Re: [Intel-gfx] [PATCH 1/8] drm/omap: Simplify the rotation-on-crtc hack

2017-07-25 Thread Daniel Vetter
On Tue, Jul 25, 2017 at 10:47 AM, Maarten Lankhorst
 wrote:
> Op 25-07-17 om 10:01 schreef Daniel Vetter:
>> I want/need to rework the core property handling, and this hack is
>> getting in the way. But since it's a non-standard propety only used by
>> legacy userspace we know that this will only every be called from
>> ioctl code. And never on some other free-standing state struct, where
>> this old hack wouldn't work either.
>>
>> v2: don't forget zorder and get_property!
>>
>> Cc: Tomi Valkeinen > Cc: Laurent Pinchart 
>> Signed-off-by: Daniel Vetter 
>> ---
>>  drivers/gpu/drm/omapdrm/omap_crtc.c | 64 
>> -
>>  1 file changed, 28 insertions(+), 36 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
>> b/drivers/gpu/drm/omapdrm/omap_crtc.c
>> index 14e8a7738b06..efa525442e7d 100644
>> --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
>> +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
>> @@ -498,39 +498,30 @@ static void omap_crtc_atomic_flush(struct drm_crtc 
>> *crtc,
>>   spin_unlock_irq(&crtc->dev->event_lock);
>>  }
>>
>> -static bool omap_crtc_is_plane_prop(struct drm_crtc *crtc,
>> - struct drm_property *property)
>> -{
>> - struct drm_device *dev = crtc->dev;
>> - struct omap_drm_private *priv = dev->dev_private;
>> -
>> - return property == priv->zorder_prop ||
>> - property == crtc->primary->rotation_property;
>> -}
>> -
>>  static int omap_crtc_atomic_set_property(struct drm_crtc *crtc,
>>struct drm_crtc_state *state,
>>struct drm_property *property,
>>uint64_t val)
>>  {
>> - if (omap_crtc_is_plane_prop(crtc, property)) {
>> - struct drm_plane_state *plane_state;
>> - struct drm_plane *plane = crtc->primary;
>> -
>> - /*
>> -  * Delegate property set to the primary plane. Get the plane
>> -  * state and set the property directly.
>> -  */
>> -
>> - plane_state = drm_atomic_get_plane_state(state->state, plane);
>> - if (IS_ERR(plane_state))
>> - return PTR_ERR(plane_state);
>> + struct omap_drm_private *priv = crtc->dev->dev_private;
>> + struct drm_plane_state *plane_state;
>>
>> - return drm_atomic_plane_set_property(plane, plane_state,
>> - property, val);
>> - }
>> + /*
>> +  * Delegate property set to the primary plane. Get the plane
>> +  * state and set the property directly.
>> +  */
>> + plane_state = drm_atomic_get_plane_state(state->state, crtc->primary);
>> + if (IS_ERR(plane_state))
>> + return PTR_ERR(plane_state);
>> +
>> + if (property == crtc->primary->rotation_property)
>> + plane_state->rotation = val;
>> + else if (property == priv->zorder_prop)
>> + plane_state->zpos = val;
>> + else
>> + return -EINVAL;
>>
>> - return -EINVAL;
>> + return 0;
>>  }
>>
>>  static int omap_crtc_atomic_get_property(struct drm_crtc *crtc,
>> @@ -538,16 +529,17 @@ static int omap_crtc_atomic_get_property(struct 
>> drm_crtc *crtc,
>>struct drm_property *property,
>>uint64_t *val)
>>  {
>> - if (omap_crtc_is_plane_prop(crtc, property)) {
>> - /*
>> -  * Delegate property get to the primary plane. The
>> -  * drm_atomic_plane_get_property() function isn't exported, but
>> -  * can be called through drm_object_property_get_value() as 
>> that
>> -  * will call drm_atomic_get_property() for atomic drivers.
>> -  */
>> - return drm_object_property_get_value(&crtc->primary->base,
>> - property, val);
>> - }
>> + struct omap_drm_private *priv = crtc->dev->dev_private;
>> +
>> + /*
>> +  * Remap to the plane rotation/zorder property. We can peek at the 
>> plane
>> +  * state directly since holding the crtc locks gives you a read-lock on
>> +  * the plane state.
>> +  */
>> + if (property == crtc->primary->rotation_property)
>> + return crtc->primary->state->rotation;
>> + else if (property == priv->zorder_prop)
>> + return crtc->primary->state->zpos;
>>
>>   return -EINVAL;
>>  }
>
> acquire_ctx for crtc's getprop too then?
>
> The comment about read lock is only valid when the plane is bound to the 
> crtc. In general this is not always the case.
> You can only peak at plane->state when crtc->state->plane_mask & 
> BIT(drm_plane_index(plane)) is true.
>
> I think we might need -EDEADLK handling for getprop then, even though it's 
> not optimal. :(

Well both the old an new way only worked because we grab all the locks
unconditionally. And I'd really want to avoid get_prop being anything
but a simple

Re: [PATCH v2 2/7] drm/atomic: Clean up drm_atomic_helper_async_check

2017-07-25 Thread Maarten Lankhorst
Op 25-07-17 om 10:23 schreef Daniel Vetter:
> On Wed, Jul 19, 2017 at 04:39:15PM +0200, Maarten Lankhorst wrote:
>> Instead of assigning plane to __plane, iterate over plane
>> which is the same thing. Simplify the check for n_planes != 1,
>> at that point we know plane != NULL as well.
>>
>> Rename obj_state to new_obj_state, and get rid of the bogus stuff.
>> crtc->state->state is NEVER non-null, if it is, there is a bug.
>> We should definitely try to prevent async updates if there are flips
>> queued, but this code will simply not be executed and needs to be
>> rethought.
>>
>> Also remove the loop too, because we're trying to loop over the crtc until
>> we find plane_state->crtc == crtc, which we already know is non-zero.
>> It's dead code anyway. :)
>>
>> Signed-off-by: Maarten Lankhorst 
>> Cc: Gustavo Padovan 
>> ---
>>  drivers/gpu/drm/drm_atomic_helper.c | 56 
>> ++---
>>  1 file changed, 15 insertions(+), 41 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
>> b/drivers/gpu/drm/drm_atomic_helper.c
>> index a46b51291006..c538528a794a 100644
>> --- a/drivers/gpu/drm/drm_atomic_helper.c
>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
>> @@ -1372,68 +1372,42 @@ int drm_atomic_helper_async_check(struct drm_device 
>> *dev,
>> struct drm_atomic_state *state)
>>  {
>>  struct drm_crtc *crtc;
>> -struct drm_crtc_state *crtc_state;
>> -struct drm_crtc_commit *commit;
>> -struct drm_plane *__plane, *plane = NULL;
>> -struct drm_plane_state *__plane_state, *plane_state = NULL;
>> +struct drm_crtc_state *new_crtc_state;
>> +struct drm_plane *plane;
>> +struct drm_plane_state *new_plane_state;
>>  const struct drm_plane_helper_funcs *funcs;
>> -int i, j, n_planes = 0;
>> +int i, n_planes = 0;
>>  
>> -for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
>> -if (drm_atomic_crtc_needs_modeset(crtc_state))
>> +for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
>> +if (drm_atomic_crtc_needs_modeset(new_crtc_state))
>>  return -EINVAL;
>>  }
>>  
>> -for_each_new_plane_in_state(state, __plane, __plane_state, i) {
>> +for_each_new_plane_in_state(state, plane, new_plane_state, i)
>>  n_planes++;
>> -plane = __plane;
>> -plane_state = __plane_state;
>> -}
>>  
>>  /* FIXME: we support only single plane updates for now */
>> -if (!plane || n_planes != 1)
>> +if (n_planes != 1)
>>  return -EINVAL;
>>  
>> -if (!plane_state->crtc)
>> +if (!new_plane_state->crtc)
>>  return -EINVAL;
>>  
>>  funcs = plane->helper_private;
>>  if (!funcs->atomic_async_update)
>>  return -EINVAL;
>>  
>> -if (plane_state->fence)
>> +if (new_plane_state->fence)
>>  return -EINVAL;
>>  
>>  /*
>> - * Don't do an async update if there is an outstanding commit modifying
>> - * the plane.  This prevents our async update's changes from getting
>> - * overridden by a previous synchronous update's state.
>> + * FIXME: We should prevent an async update if there is an outstanding
>> + * commit modifying the plane.  This prevents our async update's
>> + * changes from getting overwritten by a previous synchronous update's
>> + * state.
>>   */
>> -for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
>> -if (plane->crtc != crtc)
>> -continue;
>> -
>> -spin_lock(&crtc->commit_lock);
>> -commit = list_first_entry_or_null(&crtc->commit_list,
>> -  struct drm_crtc_commit,
>> -  commit_entry);
>> -if (!commit) {
>> -spin_unlock(&crtc->commit_lock);
>> -continue;
>> -}
>> -spin_unlock(&crtc->commit_lock);
>> -
>> -if (!crtc->state->state)
>> -continue;
>> -
>> -for_each_plane_in_state(crtc->state->state, __plane,
>> -__plane_state, j) {
> I'm pretty sure this oopses, because crtc->state->state is NULL after
> commit. I think Gustavo needs to review this first (and write a nasty igt
> testcase to catch it) before we remove this. I think the correct check is
> to simply bail out if our current crtc has a pending commit (i.e.
> !list_empty(&crtc->commit_list) should be all we need to check.
It didn't oops. Right above it was a null check. It was never executed. :)

obj->state->state is always NULL. Excluding a brief moment during swap_state 
where this may oops,  this code willl never do a thing.
> But I think we need a testcase for this.
>
> Otherwise the patch looks ok I think.
> -Daniel
>
>
>> -if (__plane == plane)
>> -return -EINVAL;
>> -

Re: [PATCH] dma-buf: fix reservation_object_wait_timeout_rcu to wait correctly

2017-07-25 Thread Christian König

Am 24.07.2017 um 13:57 schrieb Daniel Vetter:

On Mon, Jul 24, 2017 at 11:51 AM, Christian König
 wrote:

Am 24.07.2017 um 10:33 schrieb Daniel Vetter:

On Fri, Jul 21, 2017 at 06:20:01PM +0200, Christian König wrote:

From: Christian König 

With hardware resets in mind it is possible that all shared fences are
signaled, but the exlusive isn't. Fix waiting for everything in this
situation.

How did you end up with both shared and exclusive fences on the same
reservation object? At least I thought the point of exclusive was that
it's exclusive (and has an implicit barrier on all previous shared
fences). Same for shared fences, they need to wait for the exclusive one
(and replace it).

Is this fallout from the amdgpu trickery where by default you do all
shared fences? I thought we've aligned semantics a while back ...


No, that is perfectly normal even for other drivers. Take a look at the
reservation code.

The exclusive fence replaces all shared fences, but adding a shared fence
doesn't replace the exclusive fence. That actually makes sense, cause when
you want to add move shared fences those need to wait for the last exclusive
fence as well.

Hm right.


Now normally I would agree that when you have shared fences it is sufficient
to wait for all of them cause those operations can't start before the
exclusive one finishes. But with GPU reset and/or the ability to abort
already submitted operations it is perfectly possible that you end up with
an exclusive fence which isn't signaled and a shared fence which is signaled
in the same reservation object.

How does that work? The batch(es) with the shared fence are all
supposed to wait for the exclusive fence before they start, which
means even if you gpu reset and restart/cancel certain things, they
shouldn't be able to complete out of order.


Assume the following:
1. The exclusive fence is some move operation by the kernel which 
executes on a DMA engine.
2. The shared fence is a 3D operation submitted by userspace which 
executes on the 3D engine.


Now we found the 3D engine to be hung and needs a reset, all currently 
submitted jobs are aborted, marked with an error code and their fences 
put into the signaled state.


Since we only reset the 3D engine, the move operation (fortunately) 
isn't affected by this.


I think this applies to all drivers and isn't something amdgpu specific.

Regards,
Christian.



If you outright cancel a fence then you're supposed to first call
dma_fence_set_error(-EIO) and then complete it. Note that atm that
part might be slightly overengineered and I'm not sure about how we
expose stuff to userspace, e.g. dma_fence_set_error(-EAGAIN) is (or
soon, has been) used by i915 for it's internal book-keeping, which
might not be the best to leak to other consumers. But completing
fences (at least exported ones, where userspace or other drivers can
get at them) shouldn't be possible.
-Daniel



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


Re: [Intel-gfx] [PATCH v2 7/7] drm/atomic: Remove deprecated accessor macros

2017-07-25 Thread Daniel Vetter
On Wed, Jul 19, 2017 at 04:39:20PM +0200, Maarten Lankhorst wrote:
> Now that the last users have been converted, we can finally get rid of
> for_each_obj_in_state, we have better macros to replace them with.
> 
> Signed-off-by: Maarten Lankhorst 
> Cc: Daniel Vetter 
> Cc: Jani Nikula 
> Cc: Sean Paul 
> Cc: David Airlie 

Reviewed-by: Daniel Vetter 

> ---
>  include/drm/drm_atomic.h| 75 
> -
>  include/drm/drm_connector.h |  3 +-
>  include/drm/drm_crtc.h  |  8 ++---
>  include/drm/drm_plane.h |  8 ++---
>  4 files changed, 9 insertions(+), 85 deletions(-)
> 
> diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
> index 7cd0f303f5a3..679e746f0459 100644
> --- a/include/drm/drm_atomic.h
> +++ b/include/drm/drm_atomic.h
> @@ -563,31 +563,6 @@ int __must_check drm_atomic_nonblocking_commit(struct 
> drm_atomic_state *state);
>  void drm_state_dump(struct drm_device *dev, struct drm_printer *p);
>  
>  /**
> - * for_each_connector_in_state - iterate over all connectors in an atomic 
> update
> - * @__state: &struct drm_atomic_state pointer
> - * @connector: &struct drm_connector iteration cursor
> - * @connector_state: &struct drm_connector_state iteration cursor
> - * @__i: int iteration cursor, for macro-internal use
> - *
> - * This iterates over all connectors in an atomic update. Note that before 
> the
> - * software state is committed (by calling drm_atomic_helper_swap_state(), 
> this
> - * points to the new state, while afterwards it points to the old state. Due 
> to
> - * this tricky confusion this macro is deprecated.
> - *
> - * FIXME:
> - *
> - * Replace all usage of this with one of the explicit iterators below and 
> then
> - * remove this macro.
> - */
> -#define for_each_connector_in_state(__state, connector, connector_state, 
> __i) \
> - for ((__i) = 0; \
> -  (__i) < (__state)->num_connector &&
> \
> -  ((connector) = (__state)->connectors[__i].ptr, 
> \
> -  (connector_state) = (__state)->connectors[__i].state, 1);  \
> -  (__i)++)   \
> - for_each_if (connector)
> -
> -/**
>   * for_each_oldnew_connector_in_state - iterate over all connectors in an 
> atomic update
>   * @__state: &struct drm_atomic_state pointer
>   * @connector: &struct drm_connector iteration cursor
> @@ -651,31 +626,6 @@ void drm_state_dump(struct drm_device *dev, struct 
> drm_printer *p);
>   for_each_if (connector)
>  
>  /**
> - * for_each_crtc_in_state - iterate over all connectors in an atomic update
> - * @__state: &struct drm_atomic_state pointer
> - * @crtc: &struct drm_crtc iteration cursor
> - * @crtc_state: &struct drm_crtc_state iteration cursor
> - * @__i: int iteration cursor, for macro-internal use
> - *
> - * This iterates over all CRTCs in an atomic update. Note that before the
> - * software state is committed (by calling drm_atomic_helper_swap_state(), 
> this
> - * points to the new state, while afterwards it points to the old state. Due 
> to
> - * this tricky confusion this macro is deprecated.
> - *
> - * FIXME:
> - *
> - * Replace all usage of this with one of the explicit iterators below and 
> then
> - * remove this macro.
> - */
> -#define for_each_crtc_in_state(__state, crtc, crtc_state, __i)   \
> - for ((__i) = 0; \
> -  (__i) < (__state)->dev->mode_config.num_crtc &&\
> -  ((crtc) = (__state)->crtcs[__i].ptr,   \
> -  (crtc_state) = (__state)->crtcs[__i].state, 1);\
> -  (__i)++)   \
> - for_each_if (crtc_state)
> -
> -/**
>   * for_each_oldnew_crtc_in_state - iterate over all CRTCs in an atomic update
>   * @__state: &struct drm_atomic_state pointer
>   * @crtc: &struct drm_crtc iteration cursor
> @@ -735,31 +685,6 @@ void drm_state_dump(struct drm_device *dev, struct 
> drm_printer *p);
>   for_each_if (crtc)
>  
>  /**
> - * for_each_plane_in_state - iterate over all planes in an atomic update
> - * @__state: &struct drm_atomic_state pointer
> - * @plane: &struct drm_plane iteration cursor
> - * @plane_state: &struct drm_plane_state iteration cursor
> - * @__i: int iteration cursor, for macro-internal use
> - *
> - * This iterates over all planes in an atomic update. Note that before the
> - * software state is committed (by calling drm_atomic_helper_swap_state(), 
> this
> - * points to the new state, while afterwards it points to the old state. Due 
> to
> - * this tricky confusion this macro is deprecated.
> - *
> - * FIXME:
> - *
> - * Replace all usage of this with one of the explicit iterators below and 
> then
> - * remove this macro.
> - */
> -#define for_each_plane_in_state(__state, plane, plane_state, __i)
> \
> -

Re: [PATCH v2 6/7] drm/nouveau: Convert nouveau to use new iterator macros, v2.

2017-07-25 Thread Daniel Vetter
On Wed, Jul 19, 2017 at 04:39:19PM +0200, Maarten Lankhorst wrote:
> Use the new atomic iterator macros, the old ones are about to be
> removed. With the new macros, it's more easy to get old and new state so
> get them from the macros instead of from obj->state.
> 
> Changes since v1:
> - Don't mix up old and new state. (danvet)
> - Rebase on top of interruptible swap_state changes.
> 
> Signed-off-by: Maarten Lankhorst 
> Cc: Ben Skeggs 
> Cc: nouv...@lists.freedesktop.org

Reviewed-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/nouveau/nv50_display.c | 72 
> +-
>  1 file changed, 37 insertions(+), 35 deletions(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/nv50_display.c 
> b/drivers/gpu/drm/nouveau/nv50_display.c
> index 747c99c1e474..7abfb561b00c 100644
> --- a/drivers/gpu/drm/nouveau/nv50_display.c
> +++ b/drivers/gpu/drm/nouveau/nv50_display.c
> @@ -2103,7 +2103,7 @@ nv50_head_atomic_check(struct drm_crtc *crtc, struct 
> drm_crtc_state *state)
>  
>   NV_ATOMIC(drm, "%s atomic_check %d\n", crtc->name, asyh->state.active);
>   if (asyh->state.active) {
> - for_each_connector_in_state(asyh->state.state, conn, conns, i) {
> + for_each_new_connector_in_state(asyh->state.state, conn, conns, 
> i) {
>   if (conns->crtc == crtc) {
>   asyc = nouveau_conn_atom(conns);
>   break;
> @@ -3905,9 +3905,9 @@ static void
>  nv50_disp_atomic_commit_tail(struct drm_atomic_state *state)
>  {
>   struct drm_device *dev = state->dev;
> - struct drm_crtc_state *crtc_state;
> + struct drm_crtc_state *new_crtc_state;
>   struct drm_crtc *crtc;
> - struct drm_plane_state *plane_state;
> + struct drm_plane_state *new_plane_state;
>   struct drm_plane *plane;
>   struct nouveau_drm *drm = nouveau_drm(dev);
>   struct nv50_disp *disp = nv50_disp(dev);
> @@ -3926,8 +3926,8 @@ nv50_disp_atomic_commit_tail(struct drm_atomic_state 
> *state)
>   mutex_lock(&disp->mutex);
>  
>   /* Disable head(s). */
> - for_each_crtc_in_state(state, crtc, crtc_state, i) {
> - struct nv50_head_atom *asyh = nv50_head_atom(crtc->state);
> + for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
> + struct nv50_head_atom *asyh = nv50_head_atom(new_crtc_state);
>   struct nv50_head *head = nv50_head(crtc);
>  
>   NV_ATOMIC(drm, "%s: clr %04x (set %04x)\n", crtc->name,
> @@ -3940,8 +3940,8 @@ nv50_disp_atomic_commit_tail(struct drm_atomic_state 
> *state)
>   }
>  
>   /* Disable plane(s). */
> - for_each_plane_in_state(state, plane, plane_state, i) {
> - struct nv50_wndw_atom *asyw = nv50_wndw_atom(plane->state);
> + for_each_new_plane_in_state(state, plane, new_plane_state, i) {
> + struct nv50_wndw_atom *asyw = nv50_wndw_atom(new_plane_state);
>   struct nv50_wndw *wndw = nv50_wndw(plane);
>  
>   NV_ATOMIC(drm, "%s: clr %02x (set %02x)\n", plane->name,
> @@ -4006,8 +4006,8 @@ nv50_disp_atomic_commit_tail(struct drm_atomic_state 
> *state)
>   }
>  
>   /* Update head(s). */
> - for_each_crtc_in_state(state, crtc, crtc_state, i) {
> - struct nv50_head_atom *asyh = nv50_head_atom(crtc->state);
> + for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
> + struct nv50_head_atom *asyh = nv50_head_atom(new_crtc_state);
>   struct nv50_head *head = nv50_head(crtc);
>  
>   NV_ATOMIC(drm, "%s: set %04x (clr %04x)\n", crtc->name,
> @@ -4019,14 +4019,14 @@ nv50_disp_atomic_commit_tail(struct drm_atomic_state 
> *state)
>   }
>   }
>  
> - for_each_crtc_in_state(state, crtc, crtc_state, i) {
> - if (crtc->state->event)
> + for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
> + if (new_crtc_state->event)
>   drm_crtc_vblank_get(crtc);
>   }
>  
>   /* Update plane(s). */
> - for_each_plane_in_state(state, plane, plane_state, i) {
> - struct nv50_wndw_atom *asyw = nv50_wndw_atom(plane->state);
> + for_each_new_plane_in_state(state, plane, new_plane_state, i) {
> + struct nv50_wndw_atom *asyw = nv50_wndw_atom(new_plane_state);
>   struct nv50_wndw *wndw = nv50_wndw(plane);
>  
>   NV_ATOMIC(drm, "%s: set %02x (clr %02x)\n", plane->name,
> @@ -4056,23 +4056,23 @@ nv50_disp_atomic_commit_tail(struct drm_atomic_state 
> *state)
>   mutex_unlock(&disp->mutex);
>  
>   /* Wait for HW to signal completion. */
> - for_each_plane_in_state(state, plane, plane_state, i) {
> - struct nv50_wndw_atom *asyw = nv50_wndw_atom(plane->state);
> + for_each_new_plane_in_state(state, plane, new_plane_state, i) {
> + struct nv50_wndw_atom *asyw = nv50_wndw_atom(new_plane_state);
>   struct nv50_wndw *wndw

Re: [PATCH 7/8] drm: Nuke drm_atomic_helper_connector_dpms

2017-07-25 Thread Philipp Zabel
On Tue, 2017-07-25 at 10:01 +0200, Daniel Vetter wrote:
> It's dead code, the core handles all this directly now.
> 
> The only special case is nouveau and tda988x which used one function
> for both legacy modeset code and -nv50 atomic world instead of 2
> vtables. But amounts to exactly the same.
> 
> v2: Rebase over the panel/brideg refactorings in stm/ltdc.
> 
> Signed-off-by: Daniel Vetter 
[...]
>  drivers/gpu/drm/imx/imx-ldb.c  |  1 -
>  drivers/gpu/drm/imx/imx-tve.c  |  1 -
>  drivers/gpu/drm/imx/parallel-display.c |  1 -
>  drivers/gpu/drm/mediatek/mtk_dsi.c |  1 -
>  drivers/gpu/drm/mediatek/mtk_hdmi.c|  1 -

Acked-by: Philipp Zabel 

regards
Philipp

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


Re: [PATCH] drm/amdgpu: fix spelling mistake: "suuport"-> "support"

2017-07-25 Thread Christian König

Am 25.07.2017 um 00:45 schrieb Colin King:

From: Colin Ian King 

Trivial fix to spelling mistake in WARN_ONCE message

Signed-off-by: Colin Ian King 


Reviewed-by: Christian König 


---
  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 5795f81369f0..06f11e2a32af 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -1301,7 +1301,7 @@ static int amdgpu_vm_update_ptes(struct 
amdgpu_pte_update_params *params,
  
  		if (params->shadow) {

if (WARN_ONCE(use_cpu_update,
-   "CPU VM update doesn't suuport shadow pages"))
+   "CPU VM update doesn't support shadow pages"))
return 0;
  
  			if (!pt->shadow)



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


[PATCH] staging: vboxvideo: select GENERIC_ALLOCATOR

2017-07-25 Thread Hans de Goede
The vboxvideo code uses various gen_pool_* functions, so it needs
lib/genalloc.c to be built. In some configs this is not happening,
so add select GENERIC_ALLOCATOR to the Kconfig file to enforce this.

Note all other Kconfig references to GENERIC_ALLOCATOR also use select.

Signed-off-by: Hans de Goede 
---
 drivers/staging/vboxvideo/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/vboxvideo/Kconfig 
b/drivers/staging/vboxvideo/Kconfig
index a52746f9a670..cfabe3ce4bab 100644
--- a/drivers/staging/vboxvideo/Kconfig
+++ b/drivers/staging/vboxvideo/Kconfig
@@ -2,6 +2,7 @@ config DRM_VBOXVIDEO
tristate "Virtual Box Graphics Card"
depends on DRM && X86 && PCI
select DRM_KMS_HELPER
+   select GENERIC_ALLOCATOR
help
  This is a KMS driver for the virtual Graphics Card used in
  Virtual Box virtual machines.
-- 
2.13.3

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


Re: [PATCH 00/41] drm/dumb-buffers: Add defaults for .dumb_map_offset and .dumb_destroy

2017-07-25 Thread Philippe CORNU


On 07/23/2017 09:16 PM, Noralf Trønnes wrote:
> This adds defaults for the drm_driver.dumb_destroy and
> drm_driver.dumb_map_offset callbacks as discussed with Daniel.
> 
> vmwgfx is the only driver that doesn't use drm_gem_dumb_destroy().
> 
> vgem
> 
> vgem changes behaviour after this, because it didn't have .dumb_destroy
> set, something the docs mandates.
> 
> This patchset is part of a process to add a shmem gem library like the
> cma library. The common parts between the two goes into core or helpers.
> 
> Noralf.
> 
> 
> Noralf Trønnes (41):
>drm/gem: Add drm_gem_dumb_map_offset()
>drm/dumb-buffers: Add defaults for .dumb_map_offset and .dumb_destroy
>drm/arc: Use .dumb_map_offset and .dumb_destroy defaults
>drm/arm: hdlcd: Use .dumb_map_offset and .dumb_destroy defaults
>drm/arm: mali-dp: Use .dumb_map_offset and .dumb_destroy defaults
>drm/atmel-hlcdc: Use .dumb_map_offset and .dumb_destroy defaults
>drm/fsl-dcu: Use .dumb_map_offset and .dumb_destroy defaults
>drm/kirin: Use .dumb_map_offset and .dumb_destroy defaults
>drm/imx: Use .dumb_map_offset and .dumb_destroy defaults
>drm/meson: Use .dumb_map_offset and .dumb_destroy defaults
>drm/mxsfb: Use .dumb_map_offset and .dumb_destroy defaults
>drm/pl111: Use .dumb_map_offset and .dumb_destroy defaults
>drm/rcar-du: Use .dumb_map_offset and .dumb_destroy defaults
>drm/shmobile: Use .dumb_map_offset and .dumb_destroy defaults
>drm/sti: Use .dumb_map_offset and .dumb_destroy defaults
>drm/stm: Use .dumb_map_offset and .dumb_destroy defaults

for stm

Tested-by: Philippe Cornu 

Many thanks for the cleanup.
Philippe :-)

>drm/sun4i: Use .dumb_map_offset and .dumb_destroy defaults
>drm/tilcdc: Use .dumb_map_offset and .dumb_destroy defaults
>drm/vc4: Use .dumb_map_offset and .dumb_destroy defaults
>drm/zte: Use .dumb_map_offset and .dumb_destroy defaults
>drm/tinydrm: Use .dumb_map_offset and .dumb_destroy defaults
>drm/mediatek: Use .dumb_map_offset and .dumb_destroy defaults
>drm/gma500: Use .dumb_map_offset and .dumb_destroy defaults
>drm/rockchip: Use .dumb_map_offset and .dumb_destroy defaults
>drm/tegra: Use .dumb_map_offset and .dumb_destroy defaults
>drm/cirrus: Use the drm_driver.dumb_destroy default
>drm/udl: Use the drm_driver.dumb_destroy default
>drm/qxl: Use the drm_driver.dumb_destroy default
>drm/amdgpu: Use the drm_driver.dumb_destroy default
>drm/omapdrm: Use the drm_driver.dumb_destroy default
>drm/ast: Use the drm_driver.dumb_destroy default
>drm/nouveau: Use the drm_driver.dumb_destroy default
>drm/i915: Use the drm_driver.dumb_destroy default
>drm/msm: Use the drm_driver.dumb_destroy default
>drm/exynos: Use the drm_driver.dumb_destroy default
>drm/hisilicon: hibmc: Use the drm_driver.dumb_destroy default
>drm/mgag200: Use the drm_driver.dumb_destroy default
>drm/radeon: Use the drm_driver.dumb_destroy default
>drm/bochs: Use the drm_driver.dumb_destroy default
>drm/armada: Use the drm_driver.dumb_destroy default
>drm/virtio: Use the drm_driver.dumb_destroy default
> 
>   drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c |  1 -
>   drivers/gpu/drm/arc/arcpgu_drv.c|  2 --
>   drivers/gpu/drm/arm/hdlcd_drv.c |  2 --
>   drivers/gpu/drm/arm/malidp_drv.c|  2 --
>   drivers/gpu/drm/armada/armada_drv.c |  1 -
>   drivers/gpu/drm/armada/armada_gem.c |  6 -
>   drivers/gpu/drm/armada/armada_gem.h |  2 --
>   drivers/gpu/drm/ast/ast_drv.c   |  1 -
>   drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c|  2 --
>   drivers/gpu/drm/bochs/bochs_drv.c   |  1 -
>   drivers/gpu/drm/cirrus/cirrus_drv.c |  1 -
>   drivers/gpu/drm/drm_dumb_buffers.c  | 26 --
>   drivers/gpu/drm/drm_gem.c   | 35 
> +
>   drivers/gpu/drm/exynos/exynos_drm_drv.c |  1 -
>   drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c   |  2 --
>   drivers/gpu/drm/gma500/gem.c| 30 -
>   drivers/gpu/drm/gma500/psb_drv.c|  2 --
>   drivers/gpu/drm/gma500/psb_drv.h|  2 --
>   drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c |  1 -
>   drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c |  2 --
>   drivers/gpu/drm/i915/i915_drv.c |  1 -
>   drivers/gpu/drm/imx/imx-drm-core.c  |  2 --
>   drivers/gpu/drm/mediatek/mtk_drm_drv.c  |  2 --
>   drivers/gpu/drm/mediatek/mtk_drm_gem.c  | 25 --
>   drivers/gpu/drm/mediatek/mtk_drm_gem.h  |  3 ---
>   drivers/gpu/drm/meson/meson_drv.c   |  2 --
>   drivers/gpu/drm/mgag200/mgag200_drv.c   |  1 -
>   drivers/gpu/drm/msm/msm_drv.c   |  1 -
>   drivers/gpu/drm/mxsfb/mxsfb_drv.c   |  2 --
>   drivers/gpu/dr

Re: [PATCH 16/41] drm/stm: Use .dumb_map_offset and .dumb_destroy defaults

2017-07-25 Thread Philippe CORNU


On 07/23/2017 09:16 PM, Noralf Trønnes wrote:
> This driver can use the drm_driver.dumb_destroy and
> drm_driver.dumb_map_offset defaults, so no need to set them.
> 
> Cc: Yannick Fertre 
> Cc: Philippe Cornu 
> Cc: Benjamin Gaignard 
> Cc: Vincent Abriou 
> Signed-off-by: Noralf Trønnes 
> ---
>   drivers/gpu/drm/stm/drv.c | 2 --
>   1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/stm/drv.c b/drivers/gpu/drm/stm/drv.c
> index 095971f..b333b37 100644
> --- a/drivers/gpu/drm/stm/drv.c
> +++ b/drivers/gpu/drm/stm/drv.c
> @@ -60,8 +60,6 @@ static struct drm_driver drv_driver = {
>   .patchlevel = 0,
>   .fops = &drv_driver_fops,
>   .dumb_create = drm_gem_cma_dumb_create,
> - .dumb_map_offset = drm_gem_cma_dumb_map_offset,
> - .dumb_destroy = drm_gem_dumb_destroy,
>   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
>   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
>   .gem_free_object_unlocked = drm_gem_cma_free_object,
> 

Tested-by: Philippe Cornu 
Acked-by: Philippe Cornu 

Many thanks for the cleanup.

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


Re: [Intel-gfx] [PATCH 1/8] drm/omap: Simplify the rotation-on-crtc hack

2017-07-25 Thread Maarten Lankhorst
Op 25-07-17 om 10:01 schreef Daniel Vetter:
> I want/need to rework the core property handling, and this hack is
> getting in the way. But since it's a non-standard propety only used by
> legacy userspace we know that this will only every be called from
> ioctl code. And never on some other free-standing state struct, where
> this old hack wouldn't work either.
>
> v2: don't forget zorder and get_property!
>
> Cc: Tomi Valkeinen  Cc: Laurent Pinchart 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/omapdrm/omap_crtc.c | 64 
> -
>  1 file changed, 28 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
> b/drivers/gpu/drm/omapdrm/omap_crtc.c
> index 14e8a7738b06..efa525442e7d 100644
> --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
> +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
> @@ -498,39 +498,30 @@ static void omap_crtc_atomic_flush(struct drm_crtc 
> *crtc,
>   spin_unlock_irq(&crtc->dev->event_lock);
>  }
>  
> -static bool omap_crtc_is_plane_prop(struct drm_crtc *crtc,
> - struct drm_property *property)
> -{
> - struct drm_device *dev = crtc->dev;
> - struct omap_drm_private *priv = dev->dev_private;
> -
> - return property == priv->zorder_prop ||
> - property == crtc->primary->rotation_property;
> -}
> -
>  static int omap_crtc_atomic_set_property(struct drm_crtc *crtc,
>struct drm_crtc_state *state,
>struct drm_property *property,
>uint64_t val)
>  {
> - if (omap_crtc_is_plane_prop(crtc, property)) {
> - struct drm_plane_state *plane_state;
> - struct drm_plane *plane = crtc->primary;
> -
> - /*
> -  * Delegate property set to the primary plane. Get the plane
> -  * state and set the property directly.
> -  */
> -
> - plane_state = drm_atomic_get_plane_state(state->state, plane);
> - if (IS_ERR(plane_state))
> - return PTR_ERR(plane_state);
> + struct omap_drm_private *priv = crtc->dev->dev_private;
> + struct drm_plane_state *plane_state;
>  
> - return drm_atomic_plane_set_property(plane, plane_state,
> - property, val);
> - }
> + /*
> +  * Delegate property set to the primary plane. Get the plane
> +  * state and set the property directly.
> +  */
> + plane_state = drm_atomic_get_plane_state(state->state, crtc->primary);
> + if (IS_ERR(plane_state))
> + return PTR_ERR(plane_state);
> +
> + if (property == crtc->primary->rotation_property)
> + plane_state->rotation = val;
> + else if (property == priv->zorder_prop)
> + plane_state->zpos = val;
> + else
> + return -EINVAL;
>  
> - return -EINVAL;
> + return 0;
>  }
>  
>  static int omap_crtc_atomic_get_property(struct drm_crtc *crtc,
> @@ -538,16 +529,17 @@ static int omap_crtc_atomic_get_property(struct 
> drm_crtc *crtc,
>struct drm_property *property,
>uint64_t *val)
>  {
> - if (omap_crtc_is_plane_prop(crtc, property)) {
> - /*
> -  * Delegate property get to the primary plane. The
> -  * drm_atomic_plane_get_property() function isn't exported, but
> -  * can be called through drm_object_property_get_value() as that
> -  * will call drm_atomic_get_property() for atomic drivers.
> -  */
> - return drm_object_property_get_value(&crtc->primary->base,
> - property, val);
> - }
> + struct omap_drm_private *priv = crtc->dev->dev_private;
> +
> + /*
> +  * Remap to the plane rotation/zorder property. We can peek at the plane
> +  * state directly since holding the crtc locks gives you a read-lock on
> +  * the plane state.
> +  */
> + if (property == crtc->primary->rotation_property)
> + return crtc->primary->state->rotation;
> + else if (property == priv->zorder_prop)
> + return crtc->primary->state->zpos;
>  
>   return -EINVAL;
>  }

acquire_ctx for crtc's getprop too then?

The comment about read lock is only valid when the plane is bound to the crtc. 
In general this is not always the case.
You can only peak at plane->state when crtc->state->plane_mask & 
BIT(drm_plane_index(plane)) is true.

I think we might need -EDEADLK handling for getprop then, even though it's not 
optimal. :(

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


Re: [PATCH 2/8] drm: Don't update property values for atomic drivers

2017-07-25 Thread Maarten Lankhorst
Op 25-07-17 om 10:01 schreef Daniel Vetter:
> Atomic drivers only use the property value store for immutable (i.e.
> can't be set by userspace, but the kernel can still adjust it)
> properties. The only tricky part is the removal of the update in
> drm_atomic_helper_update_legacy_modeset_state().
>
> This was added in
>
> commit 8c10342cb48f3140d9abeadcfd2fa6625d447282 (tag: 
> topic/drm-misc-2015-07-28)
> Author: Maarten Lankhorst 
> Date:   Mon Jul 27 13:24:29 2015 +0200
>
> drm/atomic: Update legacy DPMS state during modesets, v3.
>
> by copying it from the i915 code, where it was originally added in
>
> commit 68d3472047a572936551f8ff0b6f4016c5a1fdef
> Author: Daniel Vetter 
> Date:   Thu Sep 6 22:08:35 2012 +0200
>
> drm/i915: update dpms property in set_mode
>
> for the legacy modeset code. The reason we needed this hack was that
> i915 didn't yet set DRIVER_ATOMIC, and we checked for that instead of
> the newer-ish drm_drv_uses_atomic_modeset(), which avoids such
> troubles. With the correct feature checks this isn't needed anymore at
> all.
>
> Also make sure that drivers don't accidentally get this wrong by
> making the exported version of drm_object_property_get_value() only
> work for legacy drivers. Only gma500 uses it anyway.
>
> Cc: Maarten Lankhorst 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_atomic_helper.c |  4 ---
>  drivers/gpu/drm/drm_connector.c |  3 +--
>  drivers/gpu/drm/drm_crtc.c  |  2 +-
>  drivers/gpu/drm/drm_mode_object.c   | 49 
> +++--
>  drivers/gpu/drm/drm_plane.c |  2 +-
>  5 files changed, 33 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 7582bbc5decc..4a960c741e35 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -921,16 +921,12 @@ drm_atomic_helper_update_legacy_modeset_state(struct 
> drm_device *dev,
>   crtc = new_conn_state->crtc;
>   if ((!crtc && old_conn_state->crtc) ||
>   (crtc && drm_atomic_crtc_needs_modeset(crtc->state))) {
> - struct drm_property *dpms_prop =
> - dev->mode_config.dpms_property;
>   int mode = DRM_MODE_DPMS_OFF;
>  
>   if (crtc && crtc->state->active)
>   mode = DRM_MODE_DPMS_ON;
>  
>   connector->dpms = mode;
> - drm_object_property_set_value(&connector->base,
> -   dpms_prop, mode);
>   }
>   }
>  
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 8072e6e4c62c..349104eadefe 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1225,8 +1225,7 @@ int drm_mode_connector_set_obj_prop(struct 
> drm_mode_object *obj,
>   } else if (connector->funcs->set_property)
>   ret = connector->funcs->set_property(connector, property, 
> value);
>  
> - /* store the property value if successful */
> - if (!ret)
> + if (!ret && drm_drv_uses_atomic_modeset(property->dev))
>   drm_object_property_set_value(&connector->base, property, 
> value);
>   return ret;
>  }
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 5af25ce5bf7c..7d4fcdd34342 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -736,7 +736,7 @@ int drm_mode_crtc_set_obj_prop(struct drm_mode_object 
> *obj,
>  
>   if (crtc->funcs->set_property)
>   ret = crtc->funcs->set_property(crtc, property, value);
> - if (!ret)
> + if (!ret && drm_drv_uses_atomic_modeset(property->dev))
>   drm_object_property_set_value(obj, property, value);
You've inverted the checks here for connector and crtc. :)

Otherwise looks sane, fix this and you can add my r-b.

On second thought, as penance you should add kms_properties to the 
fast-feedback testlist. ;)
>   return ret;
> diff --git a/drivers/gpu/drm/drm_mode_object.c 
> b/drivers/gpu/drm/drm_mode_object.c
> index da9a9adbcc98..92743a796bf0 100644
> --- a/drivers/gpu/drm/drm_mode_object.c
> +++ b/drivers/gpu/drm/drm_mode_object.c
> @@ -233,6 +233,9 @@ int drm_object_property_set_value(struct drm_mode_object 
> *obj,
>  {
>   int i;
>  
> + WARN_ON(drm_drv_uses_atomic_modeset(property->dev) &&
> + !(property->flags & DRM_MODE_PROP_IMMUTABLE));
> +
>   for (i = 0; i < obj->properties->count; i++) {
>   if (obj->properties->properties[i] == property) {
>   obj->properties->values[i] = val;
> @@ -244,24 +247,7 @@ int drm_object_property_set_value(struct drm_mode_object 
> *obj,
>  }
>  EXPORT_SYMBOL(drm_object_property_set_value);
>  
> -/**
> - * drm_object_property_get_value - retrieve the value of a property
> - * @obj: drm 

Re: [Intel-gfx] [PATCH v2 4/7] drm/omapdrm: Fix omap_atomic_wait_for_completion

2017-07-25 Thread Daniel Vetter
On Wed, Jul 19, 2017 at 04:39:17PM +0200, Maarten Lankhorst wrote:
> Use the new iterator macro and look for crtc_state->active instead of
> enable, only crtc_state->enable implies that vblanks will happen.

s/enable/active/, since enable only means logically enabled (aka resources
reserved). With that my r-b holds.
-Daniel

> 
> Signed-off-by: Maarten Lankhorst 
> Cc: Tomi Valkeinen 
> Reviewed-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/omapdrm/omap_drv.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
> b/drivers/gpu/drm/omapdrm/omap_drv.c
> index 022029ea6972..66d3c6bfd6a8 100644
> --- a/drivers/gpu/drm/omapdrm/omap_drv.c
> +++ b/drivers/gpu/drm/omapdrm/omap_drv.c
> @@ -57,13 +57,13 @@ static void omap_fb_output_poll_changed(struct drm_device 
> *dev)
>  static void omap_atomic_wait_for_completion(struct drm_device *dev,
>   struct drm_atomic_state *old_state)
>  {
> - struct drm_crtc_state *old_crtc_state;
> + struct drm_crtc_state *new_crtc_state;
>   struct drm_crtc *crtc;
>   unsigned int i;
>   int ret;
>  
> - for_each_crtc_in_state(old_state, crtc, old_crtc_state, i) {
> - if (!crtc->state->enable)
> + for_each_new_crtc_in_state(old_state, crtc, new_crtc_state, i) {
> + if (!new_crtc_state->active)
>   continue;
>  
>   ret = omap_crtc_wait_pending(crtc);
> -- 
> 2.11.0
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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


Re: [Intel-gfx] [PATCH v2 3/7] drm/rcar-du: Use new iterator macros, v2.

2017-07-25 Thread Daniel Vetter
On Wed, Jul 19, 2017 at 04:39:16PM +0200, Maarten Lankhorst wrote:
> for_each_obj_in_state is about to be removed, so use the correct new
> iterator macros.
> 
> Also look at new_plane_state instead of plane->state when looking up
> the hw planes in use. They should be the same except when reallocating,
> (in which case this code is skipped) and we should really stop looking
> at obj->state whenever possible.
> 
> Changes since v1:
> - Actually compile correctly.
> 
> Signed-off-by: Maarten Lankhorst 
> Cc: Laurent Pinchart 
> Cc: linux-renesas-...@vger.kernel.org

Didn't compile-test, but looks correct now.

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/rcar-du/rcar_du_plane.c | 57 
> -
>  1 file changed, 28 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c 
> b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> index dcde6288da6c..50fd793c38d1 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> @@ -51,12 +51,9 @@
>   */
>  
>  static bool rcar_du_plane_needs_realloc(struct rcar_du_plane *plane,
> + const struct rcar_du_plane_state 
> *cur_state,
>   struct rcar_du_plane_state *new_state)
>  {
> - struct rcar_du_plane_state *cur_state;
> -
> - cur_state = to_rcar_plane_state(plane->plane.state);
> -
>   /* Lowering the number of planes doesn't strictly require reallocation
>* as the extra hardware plane will be freed when committing, but doing
>* so could lead to more fragmentation.
> @@ -141,16 +138,17 @@ int rcar_du_atomic_check_planes(struct drm_device *dev,
>   unsigned int groups = 0;
>   unsigned int i;
>   struct drm_plane *drm_plane;
> - struct drm_plane_state *drm_plane_state;
> + struct drm_plane_state *old_drm_plane_state, *new_drm_plane_state;
>  
>   /* Check if hardware planes need to be reallocated. */
> - for_each_plane_in_state(state, drm_plane, drm_plane_state, i) {
> - struct rcar_du_plane_state *plane_state;
> + for_each_oldnew_plane_in_state(state, drm_plane, old_drm_plane_state, 
> new_drm_plane_state, i) {
> + struct rcar_du_plane_state *old_plane_state, *new_plane_state;
>   struct rcar_du_plane *plane;
>   unsigned int index;
>  
>   plane = to_rcar_plane(drm_plane);
> - plane_state = to_rcar_plane_state(drm_plane_state);
> + old_plane_state = to_rcar_plane_state(old_drm_plane_state);
> + new_plane_state = to_rcar_plane_state(new_drm_plane_state);
>  
>   dev_dbg(rcdu->dev, "%s: checking plane (%u,%tu)\n", __func__,
>   plane->group->index, plane - plane->group->planes);
> @@ -159,19 +157,19 @@ int rcar_du_atomic_check_planes(struct drm_device *dev,
>* the full reallocation procedure. Just mark the hardware
>* plane(s) as freed.
>*/
> - if (!plane_state->format) {
> + if (!new_plane_state->format) {
>   dev_dbg(rcdu->dev, "%s: plane is being disabled\n",
>   __func__);
>   index = plane - plane->group->planes;
>   group_freed_planes[plane->group->index] |= 1 << index;
> - plane_state->hwindex = -1;
> + new_plane_state->hwindex = -1;
>   continue;
>   }
>  
>   /* If the plane needs to be reallocated mark it as such, and
>* mark the hardware plane(s) as free.
>*/
> - if (rcar_du_plane_needs_realloc(plane, plane_state)) {
> + if (rcar_du_plane_needs_realloc(plane, old_plane_state, 
> new_plane_state)) {
>   dev_dbg(rcdu->dev, "%s: plane needs reallocation\n",
>   __func__);
>   groups |= 1 << plane->group->index;
> @@ -179,7 +177,7 @@ int rcar_du_atomic_check_planes(struct drm_device *dev,
>  
>   index = plane - plane->group->planes;
>   group_freed_planes[plane->group->index] |= 1 << index;
> - plane_state->hwindex = -1;
> + new_plane_state->hwindex = -1;
>   }
>   }
>  
> @@ -204,7 +202,7 @@ int rcar_du_atomic_check_planes(struct drm_device *dev,
>  
>   for (i = 0; i < group->num_planes; ++i) {
>   struct rcar_du_plane *plane = &group->planes[i];
> - struct rcar_du_plane_state *plane_state;
> + struct rcar_du_plane_state *new_plane_state;
>   struct drm_plane_state *s;
>  
>   s = drm_atomic_get_plane_state(state, &plane->plane);
> @@ -226,16 +224,16 @@ int rcar_du_atomic_check_planes(struct drm_device *dev,
> 

Re: [PATCH] drm: tegra: add CONFIG_OF dependency

2017-07-25 Thread Jon Hunter

On 21/07/17 17:13, Arnd Bergmann wrote:
> Without CONFIG_OF, we can run into a build error:
> 
> drivers/gpu/drm/tegra/dpaux.c:378:20: error: 
> 'pinconf_generic_dt_node_to_map_group' undeclared here (not in a function); 
> did you mean 'pinconf_generic_params'?
>   .dt_node_to_map = pinconf_generic_dt_node_to_map_group,
> ^~~~
> pinconf_generic_params
> drivers/gpu/drm/tegra/dpaux.c:379:17: error: 'pinconf_generic_dt_free_map' 
> undeclared here (not in a function); did you mean 'pinconf_generic_params'?
> 
> This adds an explicit dependency.
> 
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/gpu/drm/tegra/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/tegra/Kconfig b/drivers/gpu/drm/tegra/Kconfig
> index 2db29d67193d..dc58ab140151 100644
> --- a/drivers/gpu/drm/tegra/Kconfig
> +++ b/drivers/gpu/drm/tegra/Kconfig
> @@ -3,6 +3,7 @@ config DRM_TEGRA
>   depends on ARCH_TEGRA || (ARM && COMPILE_TEST)
>   depends on COMMON_CLK
>   depends on DRM
> + depends on OF
>   select DRM_KMS_HELPER
>   select DRM_MIPI_DSI
>   select DRM_PANEL

Thanks Arnd. I am curious if it can still fail if PINCTRL is not
selected in whatever config you are using?

That said ...

Acked-by: Jon Hunter 

Cheers
Jon

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


  1   2   >