[PATCH 5/5] drm/radeon: use kobj_to_dev()

[Geliang Tang]

Use kobj_to_dev() instead of open-coding it.

Signed-off-by: Geliang Tang 
---
 drivers/gpu/drm/radeon/radeon_pm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_pm.c 
b/drivers/gpu/drm/radeon/radeon_pm.c
index 59abebd..460c8f2 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -713,7 +713,7 @@ static struct attribute *hwmon_attributes[] = {
 static umode_t hwmon_attributes_visible(struct kobject *kobj,
struct attribute *attr, int index)
 {
-   struct device *dev = container_of(kobj, struct device, kobj);
+   struct device *dev = kobj_to_dev(kobj);
struct radeon_device *rdev = dev_get_drvdata(dev);
umode_t effective_mode = attr->mode;

-- 
2.5.0

[PATCH 4/5] drm/amdgpu: use kobj_to_dev()

[Geliang Tang]

Use kobj_to_dev() instead of open-coding it.

Signed-off-by: Geliang Tang 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
index 4386cba..7d8d84e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
@@ -326,7 +326,7 @@ static struct attribute *hwmon_attributes[] = {
 static umode_t hwmon_attributes_visible(struct kobject *kobj,
struct attribute *attr, int index)
 {
-   struct device *dev = container_of(kobj, struct device, kobj);
+   struct device *dev = kobj_to_dev(kobj);
struct amdgpu_device *adev = dev_get_drvdata(dev);
umode_t effective_mode = attr->mode;

-- 
2.5.0

[PATCH 3/5] drm/sysfs: use kobj_to_dev()

[Geliang Tang]

Use kobj_to_dev() instead of open-coding it.

Signed-off-by: Geliang Tang 
---
 drivers/gpu/drm/drm_sysfs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index 0ca6410..d503f8e 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu/drm/drm_sysfs.c
@@ -240,7 +240,7 @@ static ssize_t edid_show(struct file *filp, struct kobject 
*kobj,
 struct bin_attribute *attr, char *buf, loff_t off,
 size_t count)
 {
-   struct device *connector_dev = container_of(kobj, struct device, kobj);
+   struct device *connector_dev = kobj_to_dev(kobj);
struct drm_connector *connector = to_drm_connector(connector_dev);
unsigned char *edid;
size_t size;
-- 
2.5.0

[PATCH 2/5] drm/i915: use kobj_to_dev()

[Geliang Tang]

Use kobj_to_dev() instead of open-coding it.

Signed-off-by: Geliang Tang 
---
 drivers/gpu/drm/i915/i915_sysfs.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_sysfs.c 
b/drivers/gpu/drm/i915/i915_sysfs.c
index 37e3f0d..c6188dd 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -164,7 +164,7 @@ i915_l3_read(struct file *filp, struct kobject *kobj,
 struct bin_attribute *attr, char *buf,
 loff_t offset, size_t count)
 {
-   struct device *dev = container_of(kobj, struct device, kobj);
+   struct device *dev = kobj_to_dev(kobj);
struct drm_minor *dminor = dev_to_drm_minor(dev);
struct drm_device *drm_dev = dminor->dev;
struct drm_i915_private *dev_priv = drm_dev->dev_private;
@@ -200,7 +200,7 @@ i915_l3_write(struct file *filp, struct kobject *kobj,
  struct bin_attribute *attr, char *buf,
  loff_t offset, size_t count)
 {
-   struct device *dev = container_of(kobj, struct device, kobj);
+   struct device *dev = kobj_to_dev(kobj);
struct drm_minor *dminor = dev_to_drm_minor(dev);
struct drm_device *drm_dev = dminor->dev;
struct drm_i915_private *dev_priv = drm_dev->dev_private;
@@ -521,7 +521,7 @@ static ssize_t error_state_read(struct file *filp, struct 
kobject *kobj,
loff_t off, size_t count)
 {

-   struct device *kdev = container_of(kobj, struct device, kobj);
+   struct device *kdev = kobj_to_dev(kobj);
struct drm_minor *minor = dev_to_drm_minor(kdev);
struct drm_device *dev = minor->dev;
struct i915_error_state_file_priv error_priv;
@@ -556,7 +556,7 @@ static ssize_t error_state_write(struct file *file, struct 
kobject *kobj,
 struct bin_attribute *attr, char *buf,
 loff_t off, size_t count)
 {
-   struct device *kdev = container_of(kobj, struct device, kobj);
+   struct device *kdev = kobj_to_dev(kobj);
struct drm_minor *minor = dev_to_drm_minor(kdev);
struct drm_device *dev = minor->dev;
int ret;
-- 
2.5.0

[PATCH 1/5] drm/i915: use hlist_for_each_entry

[Geliang Tang]

Use hlist_for_each_entry() instead of hlist_for_each() to simplify
the code.

Signed-off-by: Geliang Tang 
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 5d01ea6..8f194be 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -192,14 +192,10 @@ static struct i915_vma *eb_get_vma(struct eb_vmas *eb, 
unsigned long handle)
return NULL;
return eb->lut[handle];
} else {
-   struct hlist_head *head;
-   struct hlist_node *node;
-
-   head = >buckets[handle & eb->and];
-   hlist_for_each(node, head) {
-   struct i915_vma *vma;
+   struct i915_vma *vma;

-   vma = hlist_entry(node, struct i915_vma, exec_node);
+   hlist_for_each_entry(vma, >buckets[handle & eb->and],
+exec_node) {
if (vma->exec_handle == handle)
return vma;
}
-- 
2.5.0

[RESEND,V2] drm: fsl-dcu: Fix no fb check bug

[Stefan Agner]

On 2016-01-08 01:20, Emil Velikov wrote:
> Hi guys,
> 
> Am I loosing the plot here or something feels amiss here ?
> 
> On 6 January 2016 at 06:12, Meng Yi  wrote:
>> For state->fb or state->crtc may be NULL in fsl_dcu_drm_plane_atomic_check
>> function, if so, return 0.
>>
>> Signed-off-by: Meng Yi 
>> Signed-off-by: Jianwei Wang 
>>
>> ---
>>
>> change in v2:
>> -Add state->crtc check
>> -return 0 when state->fb or state->crtc is NULL, instead of -EINVAL
>> Adviced by Daniel Stone
>>
>>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c 
>> b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c
>> index 4b13cf9..8965580 100644
>> --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c
>> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c
>> @@ -41,6 +41,9 @@ static int fsl_dcu_drm_plane_atomic_check(struct drm_plane 
>> *plane,
>>  {
>> struct drm_framebuffer *fb = state->fb;
>>
>> +   if (!state->fb || !state->crtc)
>> +   return 0;
>> +
> Namely: if we return success here core drm will end up calling the
> atomic_update...
> 

After atomic_check atomic_disable could be called too. However, this
seem not directly depend on state'>fb, but more on plane->state->crtc.



>> switch (fb->pixel_format) {
>> case DRM_FORMAT_RGB565:
>> case DRM_FORMAT_RGB888:
>> @@ -85,9 +88,6 @@ static void fsl_dcu_drm_plane_atomic_update(struct 
>> drm_plane *plane,
>> unsigned int alpha, bpp;
>> int index, ret;
>>
>> -   if (!fb)
>> -   return;
>> -
> ... which no longer has the !fb check, and we'll crash with null deref
> a few lines below ?


If there is a legitimate situation where fb is null which also
ultimately leads to a atomic_commit, I guess we should keep the return
here...

--
Stefan

[PATCH] drm: avoid uninitialized timestamp use in wait_vblank

[Arnd Bergmann]

gcc warns about the timestamp in drm_wait_vblank being possibly
used without an initialization:

drivers/gpu/drm/drm_irq.c: In function 'drm_wait_vblank':
drivers/gpu/drm/drm_irq.c:1755:28: warning: 'now.tv_usec' may be used 
uninitialized in this function [-Wmaybe-uninitialized]
   vblwait->reply.tval_usec = now.tv_usec;
drivers/gpu/drm/drm_irq.c:1754:27: warning: 'now.tv_sec' may be used 
uninitialized in this function [-Wmaybe-uninitialized]
   vblwait->reply.tval_sec = now.tv_sec;

This can happen if drm_vblank_count_and_time() returns 0 in its
error path. To sanitize the error case, I'm changing that function
to return a zero timestamp when it fails.

Signed-off-by: Arnd Bergmann 
Fixes: e6ae8687a87b ("drm: idiot-proof vblank")
---
I'm going through the maybe-unused warnings in randconfig builds, this one is
apparently not a false positive, although it only happens if something
else has already gone wrong.

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index d12a4efa651b..d32ff169fdb8 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -939,8 +939,10 @@ u32 drm_vblank_count_and_time(struct drm_device *dev, 
unsigned int pipe,
int count = DRM_TIMESTAMP_MAXRETRIES;
u32 cur_vblank;

-   if (WARN_ON(pipe >= dev->num_crtcs))
+   if (WARN_ON(pipe >= dev->num_crtcs)) {
+   *vblanktime = (struct timeval) { 0 };
return 0;
+   }

/*
 * Vblank timestamps are read lockless. To ensure consistency the vblank

[PATCH v2 07/16] drm: omapdrm: gem: Remove omap_drm_private has_dmm field

[Tomi Valkeinen]

On 14/12/15 22:39, Laurent Pinchart wrote:
> The field is set to true iff the usergart field is not NULL. Test
> usergart instead.

That's true, but I don't like the change.

'has_dmm' means we have DMM (well, TILER, really). TILER is used for 1D
and 2D modes. 'usergart' is only for TILER 2D CPU access (if I'm not
mistaken).

I'm not sure what it would buy us or if it's worth the effort, but maybe
we want to make the 2D mode optional in the future.

And even if we do have 2D mode enabled, due to HW issues a 2D mapped
buffer can't really be accessed by the CPU, as it's just too slow. So
maybe we can have 2D mode supported, but without usergart.

I don't know. But I want to keep these things separated.

That said, maybe some of the 'if's would be cleaner if they checked for
usergart instead of has_dmm, if usergart is really what they depend on.

 Tomi

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160113/c56d1294/attachment.sig>

[PATCH] uapi: use __u8 from linux/types.h

[Gleb Fotengauer-Malinovskiy]

Kernel headers should use linux/types.h based definitions.

Signed-off-by: Gleb Fotengauer-Malinovskiy 
---
 include/uapi/linux/virtio_gpu.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/uapi/linux/virtio_gpu.h b/include/uapi/linux/virtio_gpu.h
index 7a63faa..4b04ead 100644
--- a/include/uapi/linux/virtio_gpu.h
+++ b/include/uapi/linux/virtio_gpu.h
@@ -287,7 +287,7 @@ struct virtio_gpu_get_capset {
 /* VIRTIO_GPU_RESP_OK_CAPSET */
 struct virtio_gpu_resp_capset {
struct virtio_gpu_ctrl_hdr hdr;
-   uint8_t capset_data[];
+   __u8 capset_data[];
 };

 #define VIRTIO_GPU_EVENT_DISPLAY (1 << 0)
-- 
glebfm

[PATCH RFC 2/2] drm: sunxi: Add a basic DRM driver for Allwinner DE2

[Jean-Francois Moine]

On Wed, 6 Jan 2016 21:41:30 +0100
Jens Kuske  wrote:

> On 05/01/16 19:40, Jean-Francois Moine wrote:
> [snip]
> > diff --git a/drivers/gpu/drm/sunxi/de2_hdmi_h3.c 
> > b/drivers/gpu/drm/sunxi/de2_hdmi_h3.c
> > new file mode 100644
> > index 000..c54b090
> > --- /dev/null
> > +++ b/drivers/gpu/drm/sunxi/de2_hdmi_h3.c
> > @@ -0,0 +1,478 @@
> > +/*
> > + * Allwinner H3 HDMI lowlevel functions
> > + *
> > + * Copyright (C) 2016 Jean-Francois Moine 
> > + *
> > + * Adapted from the file
> > + * lichee/linux-3.4/drivers/video/sunxi/disp2/hdmi/aw/hdmi_bsp_sun8iw7.c
> > + * with no license nor copyright.
> > + */
[snip]
> > +/*
> > + * [0] = vic (cea Video ID)
> > + * [1] used in hdmi_phy_set / bsp_hdmi_audio
> > + * [2..17] used in bsp_hdmi_video
> > + */
> > +static const struct para_tab ptbl[] = {
> > +   {{  6,  1, 1,  1,  5,  3, 0, 1, 4, 0, 0, 160,  20,  38, 124, 240, 22, 
> > 0, 0}},
[snip]

> did you try to figure out what the values in this table actually mean?
> 
> I tried it some time ago because I wanted to add some more resolutions
> to 3.4, but never got further than what I'll add below. But it might be
> useful now, to get rid of at least some of the magic constants.
> With some more work (what does [1] mean?) we might be able to drop the
> entire table and use the values from drm_display_mode directly instead.
> 
> unsure (hard to verify):
> [2] = pixel repetition (1 = 2x)
> [3] = bit0: interlaced (no idea about the 96/0x60 yet)
> [17] = something csc related
> [18] = unused
> 
> pretty sure (verified by comparing with timings):
> [4] = horizontal active (high byte)
> [5] = vsync width
> [6] = vertical active (high byte)
> [7] = horizontal blanking (high byte)
> [8] = vertical front porch
> [9] = horizontal front porch (high byte)
> [10] = hsync width (high byte)
> [11] = horizontal active (low byte)
> [12] = horizontal blanking (low byte)
> [13] = horizontal front porch (low byte)
> [14] = hsync width (low byte)
> [15] = vertical active (low byte)
> [16] = vertical blanking
> 
> Generally, nice work. I only skimmed over it by now, but I hope to test
> and review the hardware related parts more intensively sometime.

Hi Jens,

Thanks for this information, but this table is only a very small part
of the HDMI code.

I doubt that anyone could understand the other sequences of the
functions of this BSP without documentation, or could do some reverse
engineering and understand how the DE2 HDMI device works.

So, I think that we have to wait for some information and/or
authorisation from Allwinner before putting a HDMI driver for the H3
(and A83T, A64...) into the mainline.

-- 
Ken ar c'hentañ| ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

[PATCH] uapi: use __u8 from linux/types.h

[Michael S. Tsirkin]

On Wed, Jan 13, 2016 at 07:10:15PM +0300, Gleb Fotengauer-Malinovskiy wrote:
> Kernel headers should use linux/types.h based definitions.
> 
> Signed-off-by: Gleb Fotengauer-Malinovskiy 

Acked-by: Michael S. Tsirkin 

> ---
>  include/uapi/linux/virtio_gpu.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/uapi/linux/virtio_gpu.h b/include/uapi/linux/virtio_gpu.h
> index 7a63faa..4b04ead 100644
> --- a/include/uapi/linux/virtio_gpu.h
> +++ b/include/uapi/linux/virtio_gpu.h
> @@ -287,7 +287,7 @@ struct virtio_gpu_get_capset {
>  /* VIRTIO_GPU_RESP_OK_CAPSET */
>  struct virtio_gpu_resp_capset {
>   struct virtio_gpu_ctrl_hdr hdr;
> - uint8_t capset_data[];
> + __u8 capset_data[];
>  };
>  
>  #define VIRTIO_GPU_EVENT_DISPLAY (1 << 0)
> -- 
> glebfm

[RFC/PATCH] drm/rockchip: don't wait for vblank if fb hasn't changed

[Daniel Vetter]

On Wed, Jan 13, 2016 at 04:40:38PM +, John Keeping wrote:
> On Wed, 13 Jan 2016 17:21:56 +0100, Daniel Vetter wrote:
> 
> > On Wed, Jan 13, 2016 at 03:55:29PM +, John Keeping wrote:
> > > On Wed, 13 Jan 2016 16:40:05 +0100, Daniel Vetter wrote:
> > >   
> > > > On Wed, Jan 13, 2016 at 02:34:25PM +, John Keeping wrote:  
> > > > > On Wed, 13 Jan 2016 15:23:20 +0100, Daniel Vetter wrote:
> > > > > 
> > > > > > On Wed, Jan 13, 2016 at 12:53:34PM +, John Keeping wrote:
> > > > > > > As commented in drm_atomic_helper_wait_for_vblanks(), userspace
> > > > > > > relies on cursor ioctls being unsynced.  Converting the rockchip
> > > > > > > driver to atomic has significantly impacted cursor performance by
> > > > > > > making every cursor update wait for vblank.
> > > > > > > 
> > > > > > > By skipping the vblank sync when the framebuffer has not changed
> > > > > > > (as is done in drm_atomic_helper_wait_for_vblanks()) we can avoid
> > > > > > > this for the common case of moving the cursor and only need to
> > > > > > > delay the cursor ioctl when the cursor icon changes.
> > > > > > > 
> > > > > > > I originally inserted a check on legacy_cursor_update as well, but
> > > > > > > that caused a storm of iommu page faults.  I didn't investigate 
> > > > > > > the
> > > > > > > cause of those since this change gives enough of a performance
> > > > > > > improvement for my use case.
> > > > > > > 
> > > > > > > This is RFC because of that and because the framebuffer_changed()
> > > > > > > function is copied from drm_atomic_helper.c as a quick way to test
> > > > > > > the result.
> > > > > > > 
> > > > > > > Signed-off-by: John Keeping 
> > > > > > > ---
> > > > > > >  drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 27
> > > > > > > +-- 1 file changed, 25 insertions(+), 2
> > > > > > > deletions(-)
> > > > > > > 
> > > > > > > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> > > > > > > b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c index 
> > > > > > > f784488..8fd9821
> > > > > > > 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> > > > > > > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> > > > > > > @@ -177,8 +177,28 @@ static void
> > > > > > > rockchip_crtc_wait_for_update(struct drm_crtc *crtc)
> > > > > > > crtc_funcs->wait_for_update(crtc); }
> > > > > > >  
> > > > > > > +static bool framebuffer_changed(struct drm_device *dev,
> > > > > > > + struct drm_atomic_state *old_state,
> > > > > > > + struct drm_crtc *crtc)
> > > > > > > +{
> > > > > > > + struct drm_plane *plane;
> > > > > > > + struct drm_plane_state *old_plane_state;
> > > > > > > + int i;
> > > > > > > +
> > > > > > > + for_each_plane_in_state(old_state, plane, old_plane_state,
> > > > > > > i) {
> > > > > > > + if (plane->state->crtc != crtc &&
> > > > > > > + old_plane_state->crtc != crtc)
> > > > > > > + continue;
> > > > > > > +
> > > > > > > + if (plane->state->fb != old_plane_state->fb)
> > > > > > > + return true;
> > > > > > > + }
> > > > > > > +
> > > > > > > + return false;
> > > > > > > +}  
> > > > > > 
> > > > > > Please don't hand-roll logic that affects semantics like this. 
> > > > > > Instead
> > > > > > please use drm_atomic_helper_wait_for_vblanks(), which should do 
> > > > > > this
> > > > > > correctly for you.
> > > > > > 
> > > > > > If that's not the case then we need to improve the generic helper, 
> > > > > > or
> > > > > > figure out what's different with rockhip.
> > > > > 
> > > > > According to commit 63ebb9f (drm/rockchip: Convert to support atomic
> > > > > API) it's because rockchip doesn't have a hardware vblank counter.
> > > > > 
> > > > > I'm not entirely clear on why this prevents the use of
> > > > > drm_atomic_helper_wait_for_vblanks().
> > > > 
> > > > Hm, that commit isn't terribly helpful. If that's really needed then 
> > > > imo I
> > > > think we should extract a "drm_atomic_helper_plane_needs_vblank_wait()"
> > > > helper that's used by both. But since rockchip does vblank_get/put calls
> > > > I'd hope vblanks actually work correctly. And then the helper should 
> > > > work
> > > > too.  
> > > 
> > > I tried switching the call to rockchip_crtc_wait_for_update() to
> > > drm_atomic_helper_wait_for_vblanks() and it works fine until I switch
> > > the buffer associated with a cursor, at which point I get iommu page
> > > faults, presumably because the GEM buffer is unreferenced too early.
> > > 
> > > AFAICT the buffer will be released via drm_atomic_state_free()
> > > unconditionally, but I suspect I'm missing something since that would
> > > mean every driver would hit a similar problem.  
> > 
> > Yeah, with the helper we always skip, which means when the cursor bo
> > changes you indeed unmap too early. So can't even share the overall
> > condition, but we could definitely share the little framebuffer_changed
> 

[RFC/PATCH] drm/rockchip: don't wait for vblank if fb hasn't changed

[John Keeping]

On Wed, 13 Jan 2016 18:19:17 +0100, Daniel Vetter wrote:

> On Wed, Jan 13, 2016 at 04:40:38PM +, John Keeping wrote:
> > On Wed, 13 Jan 2016 17:21:56 +0100, Daniel Vetter wrote:
> >   
> > > On Wed, Jan 13, 2016 at 03:55:29PM +, John Keeping wrote:  
> > > > On Wed, 13 Jan 2016 16:40:05 +0100, Daniel Vetter wrote:
> > > > 
> > > > > On Wed, Jan 13, 2016 at 02:34:25PM +, John Keeping wrote:
> > > > > > On Wed, 13 Jan 2016 15:23:20 +0100, Daniel Vetter wrote:
> > > > > >   
> > > > > > > On Wed, Jan 13, 2016 at 12:53:34PM +, John Keeping wrote: 
> > > > > > >  
> > > > > > > > As commented in drm_atomic_helper_wait_for_vblanks(), userspace
> > > > > > > > relies on cursor ioctls being unsynced.  Converting the rockchip
> > > > > > > > driver to atomic has significantly impacted cursor performance 
> > > > > > > > by
> > > > > > > > making every cursor update wait for vblank.
> > > > > > > > 
> > > > > > > > By skipping the vblank sync when the framebuffer has not changed
> > > > > > > > (as is done in drm_atomic_helper_wait_for_vblanks()) we can 
> > > > > > > > avoid
> > > > > > > > this for the common case of moving the cursor and only need to
> > > > > > > > delay the cursor ioctl when the cursor icon changes.
> > > > > > > > 
> > > > > > > > I originally inserted a check on legacy_cursor_update as well, 
> > > > > > > > but
> > > > > > > > that caused a storm of iommu page faults.  I didn't investigate 
> > > > > > > > the
> > > > > > > > cause of those since this change gives enough of a performance
> > > > > > > > improvement for my use case.
> > > > > > > > 
> > > > > > > > This is RFC because of that and because the 
> > > > > > > > framebuffer_changed()
> > > > > > > > function is copied from drm_atomic_helper.c as a quick way to 
> > > > > > > > test
> > > > > > > > the result.
> > > > > > > > 
> > > > > > > > Signed-off-by: John Keeping 
> > > > > > > > ---
> > > > > > > >  drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 27
> > > > > > > > +-- 1 file changed, 25 insertions(+), 2
> > > > > > > > deletions(-)
> > > > > > > > 
> > > > > > > > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> > > > > > > > b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c index 
> > > > > > > > f784488..8fd9821
> > > > > > > > 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> > > > > > > > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> > > > > > > > @@ -177,8 +177,28 @@ static void
> > > > > > > > rockchip_crtc_wait_for_update(struct drm_crtc *crtc)
> > > > > > > > crtc_funcs->wait_for_update(crtc); }
> > > > > > > >  
> > > > > > > > +static bool framebuffer_changed(struct drm_device *dev,
> > > > > > > > +   struct drm_atomic_state 
> > > > > > > > *old_state,
> > > > > > > > +   struct drm_crtc *crtc)
> > > > > > > > +{
> > > > > > > > +   struct drm_plane *plane;
> > > > > > > > +   struct drm_plane_state *old_plane_state;
> > > > > > > > +   int i;
> > > > > > > > +
> > > > > > > > +   for_each_plane_in_state(old_state, plane, 
> > > > > > > > old_plane_state,
> > > > > > > > i) {
> > > > > > > > +   if (plane->state->crtc != crtc &&
> > > > > > > > +   old_plane_state->crtc != crtc)
> > > > > > > > +   continue;
> > > > > > > > +
> > > > > > > > +   if (plane->state->fb != old_plane_state->fb)
> > > > > > > > +   return true;
> > > > > > > > +   }
> > > > > > > > +
> > > > > > > > +   return false;
> > > > > > > > +}
> > > > > > > 
> > > > > > > Please don't hand-roll logic that affects semantics like this. 
> > > > > > > Instead
> > > > > > > please use drm_atomic_helper_wait_for_vblanks(), which should do 
> > > > > > > this
> > > > > > > correctly for you.
> > > > > > > 
> > > > > > > If that's not the case then we need to improve the generic 
> > > > > > > helper, or
> > > > > > > figure out what's different with rockhip.  
> > > > > > 
> > > > > > According to commit 63ebb9f (drm/rockchip: Convert to support atomic
> > > > > > API) it's because rockchip doesn't have a hardware vblank counter.
> > > > > > 
> > > > > > I'm not entirely clear on why this prevents the use of
> > > > > > drm_atomic_helper_wait_for_vblanks().  
> > > > > 
> > > > > Hm, that commit isn't terribly helpful. If that's really needed then 
> > > > > imo I
> > > > > think we should extract a 
> > > > > "drm_atomic_helper_plane_needs_vblank_wait()"
> > > > > helper that's used by both. But since rockchip does vblank_get/put 
> > > > > calls
> > > > > I'd hope vblanks actually work correctly. And then the helper should 
> > > > > work
> > > > > too.
> > > > 
> > > > I tried switching the call to rockchip_crtc_wait_for_update() to
> > > > drm_atomic_helper_wait_for_vblanks() and it works fine until I switch
> > > > the buffer associated with a cursor, at which point I get iommu page
> > > > 

[RFC/PATCH] drm/rockchip: don't wait for vblank if fb hasn't changed

[Daniel Vetter]

On Wed, Jan 13, 2016 at 03:55:29PM +, John Keeping wrote:
> On Wed, 13 Jan 2016 16:40:05 +0100, Daniel Vetter wrote:
> 
> > On Wed, Jan 13, 2016 at 02:34:25PM +, John Keeping wrote:
> > > On Wed, 13 Jan 2016 15:23:20 +0100, Daniel Vetter wrote:
> > >   
> > > > On Wed, Jan 13, 2016 at 12:53:34PM +, John Keeping wrote:  
> > > > > As commented in drm_atomic_helper_wait_for_vblanks(), userspace
> > > > > relies on cursor ioctls being unsynced.  Converting the rockchip
> > > > > driver to atomic has significantly impacted cursor performance by
> > > > > making every cursor update wait for vblank.
> > > > > 
> > > > > By skipping the vblank sync when the framebuffer has not changed
> > > > > (as is done in drm_atomic_helper_wait_for_vblanks()) we can avoid
> > > > > this for the common case of moving the cursor and only need to
> > > > > delay the cursor ioctl when the cursor icon changes.
> > > > > 
> > > > > I originally inserted a check on legacy_cursor_update as well, but
> > > > > that caused a storm of iommu page faults.  I didn't investigate the
> > > > > cause of those since this change gives enough of a performance
> > > > > improvement for my use case.
> > > > > 
> > > > > This is RFC because of that and because the framebuffer_changed()
> > > > > function is copied from drm_atomic_helper.c as a quick way to test
> > > > > the result.
> > > > > 
> > > > > Signed-off-by: John Keeping 
> > > > > ---
> > > > >  drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 27
> > > > > +-- 1 file changed, 25 insertions(+), 2
> > > > > deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> > > > > b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c index f784488..8fd9821
> > > > > 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> > > > > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> > > > > @@ -177,8 +177,28 @@ static void
> > > > > rockchip_crtc_wait_for_update(struct drm_crtc *crtc)
> > > > > crtc_funcs->wait_for_update(crtc); }
> > > > >  
> > > > > +static bool framebuffer_changed(struct drm_device *dev,
> > > > > + struct drm_atomic_state *old_state,
> > > > > + struct drm_crtc *crtc)
> > > > > +{
> > > > > + struct drm_plane *plane;
> > > > > + struct drm_plane_state *old_plane_state;
> > > > > + int i;
> > > > > +
> > > > > + for_each_plane_in_state(old_state, plane, old_plane_state,
> > > > > i) {
> > > > > + if (plane->state->crtc != crtc &&
> > > > > + old_plane_state->crtc != crtc)
> > > > > + continue;
> > > > > +
> > > > > + if (plane->state->fb != old_plane_state->fb)
> > > > > + return true;
> > > > > + }
> > > > > +
> > > > > + return false;
> > > > > +}
> > > > 
> > > > Please don't hand-roll logic that affects semantics like this. Instead
> > > > please use drm_atomic_helper_wait_for_vblanks(), which should do this
> > > > correctly for you.
> > > > 
> > > > If that's not the case then we need to improve the generic helper, or
> > > > figure out what's different with rockhip.  
> > > 
> > > According to commit 63ebb9f (drm/rockchip: Convert to support atomic
> > > API) it's because rockchip doesn't have a hardware vblank counter.
> > > 
> > > I'm not entirely clear on why this prevents the use of
> > > drm_atomic_helper_wait_for_vblanks().  
> > 
> > Hm, that commit isn't terribly helpful. If that's really needed then imo I
> > think we should extract a "drm_atomic_helper_plane_needs_vblank_wait()"
> > helper that's used by both. But since rockchip does vblank_get/put calls
> > I'd hope vblanks actually work correctly. And then the helper should work
> > too.
> 
> I tried switching the call to rockchip_crtc_wait_for_update() to
> drm_atomic_helper_wait_for_vblanks() and it works fine until I switch
> the buffer associated with a cursor, at which point I get iommu page
> faults, presumably because the GEM buffer is unreferenced too early.
> 
> AFAICT the buffer will be released via drm_atomic_state_free()
> unconditionally, but I suspect I'm missing something since that would
> mean every driver would hit a similar problem.

Yeah, with the helper we always skip, which means when the cursor bo
changes you indeed unmap too early. So can't even share the overall
condition, but we could definitely share the little framebuffer_changed
helper. Plus rockchip_crtc_wait_for_update should have a big comment
explaining why we have different rules than core helpers!

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

[RFC] handling of alpha mode (pre-multiplied/straight) in ARGB modes

[Ville Syrjälä]

On Wed, Jan 13, 2016 at 03:13:35PM +0100, Marek Szyprowski wrote:
> Hello,
> 
> On 2016-01-11 16:22, Ville Syrjälä wrote:
> > On Mon, Jan 11, 2016 at 04:07:50PM +0100, Daniel Vetter wrote:
> >> On Mon, Jan 11, 2016 at 03:18:44PM +0100, Marek Szyprowski wrote:
> >>> Dear All,
> >>>
> >>> I would like to add support for configuring alpha modes: straight and
> >>> pre-multiplied for blending to Exynos DRM driver. For those who see those
> >>> terms for the first time:
> >>> 1. straight alpha mode means means that all A and RGB values are from full
> >>> 0.255 range,
> >>> 2. pre-multiplied alpha mode means that A is from 0..255 range and RGB
> >>> values are scaled to 0..ALPHA range (where ALPHA is the A value for the
> >>> given pixel).
> >>> The pre-multiplied mode is quite common in texture processing.
> >>>
> >>> I did a little research and found that there is no common approach for
> >>> defining straight or pre-multiplied alpha modes for ARGB framebuffers.
> >>>
> >>> >From reading the sources and the register names I found that following
> >>> drivers use pre-multiplied modes for ARGB framebuffers:
> >>> radeon (at least for ARGB cursors),
> >>> amdgpu (cursor),
> >>> intel (all ARGB planes),
> >>> rock chip.
> >>>
> >>> On the other hand, there are drm drivers which support ARGB modes and use
> >>> straight alpha modes:
> >>> omap,
> >>> msm.
> >>>
> >>> For the rest of drivers, which might deal with per-pixel alpha, I was not
> >>> able to determine from the code if the pixel RGB values are interpreted as
> >>> per-multiplied or straight:
> >>> atmel_hlcdc,
> >>> sti,
> >>> mdp5,
> >>> shmobile,
> >>> rcar,
> >>> vc4,
> >>> imx.
> >> Imo in case of doubt/mixed definitions the semantics of the big desktop
> >> drivers should win. True generic userspace is most likely developed on
> >> those, everything else should just adjust. And in most cases we can get
> >> away with that on arm drivers since they tend to ship userspace and kernel
> >> in lockstep. At least where it really matters.
> >>
> >>> Exynos DRM driver now mixes pre-multiplied and straight modes, depending 
> >>> on
> >>> the CRTC sub-driver.
> >>>
> >>> While checking the code I found a following comment in
> >>> drm/i915/intel_display.c in skl_plane_ctl_format() function:
> >>> /*
> >>>   * XXX: For ARBG/ABGR formats we default to expecting scanout buffers
> >>>   * to be already pre-multiplied. We need to add a knob (or a different
> >>>   * DRM_FORMAT) for user-space to configure that.
> >>>   */
> >>>
> >>> The question is how to cleanup this ambiguities and let generic userspace 
> >>> to
> >>> properly use ARGB/ARGB modes with proper blending mode. I came up with the
> >>> following 3 solutions:
> >>>
> >>> 1. Define new fourcc values for pre-multiplied (or/and straight) alpha
> >>> modes,
> >>> 2. Introduce a new framebuffer flag for pre-multiplied or straight alpha 
> >>> (or
> >>> both),
> >>> 3. Introduce a new plane property for controlling alpha blending mode.
> >>>
> >>> The first solution has serious compatibility problem, because we can 
> >>> either
> >>> map existing fourcc to pre-multiplied (to follow radeon/amdgpu, intel and
> >>> rockchip behavior) or straight mode. Both ways it will break some existing
> >>> applications. To avoid compatibility problem we would need to add 2 more
> >>> sets of fourcc and leave existing ARGB modes as 'driver dependent'.
> >>>
> >>> The second solution is probably a bit less intrusive, but it suffers for 
> >>> the
> >>> similar compatibility problem. To make this feature compatible with 
> >>> existing
> >>> code, probably 2 flags will be needed: 
> >>> DRM_MODE_FB_ALPHA_FORCE_PREMULTIPLIED
> >>> and DRM_MODE_FB_ALPHA_FORCE_STRAIGHT. This way when userspace provides no
> >>> flag, the driver can use its default mode.
> >>>
> >>> Third solution (additional plane property) has been already proposed:
> >>> https://lkml.org/lkml/2015/6/19/330, however I found no follow-up nor
> >>> comments. Separate property lets at least drivers to notify userspace 
> >>> about
> >>> driver's default alpha mode and lets generic application to properly set 
> >>> the
> >>> requested mode. The only problem is that the alpha mode is not directly
> >>> configured on the framebuffer object, where in my opinion it should be
> >>> stored.
> >>>
> >>> Please let me know which approach You like best and which should I take 
> >>> for
> >>> introducing generic way of configuring alpha mode.
> >> One idea that was tossed around a few times is to go full generic and
> >> implement something like glBlendFunc for planes, except that we'd also
> >> pre-multiplied/straight versions where it makes sense. For drivers that
> >> can't support pre-multiplied alpha they could simply leave out these
> >> values from the blend-func property (like we already allow with e.g.
> >> rotation, when a driver can't do 90/270°).
> >>
> >> Wrt backwards compat a property would work well too: If it's not there
> >> then userspace 

[PATCH 3/5] drm/sysfs: use kobj_to_dev()

[Daniel Vetter]

On Wed, Jan 13, 2016 at 10:48:41PM +0800, Geliang Tang wrote:
> Use kobj_to_dev() instead of open-coding it.
> 
> Signed-off-by: Geliang Tang 

Merged to drm-misc, thanks.
-Daniel

> ---
>  drivers/gpu/drm/drm_sysfs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
> index 0ca6410..d503f8e 100644
> --- a/drivers/gpu/drm/drm_sysfs.c
> +++ b/drivers/gpu/drm/drm_sysfs.c
> @@ -240,7 +240,7 @@ static ssize_t edid_show(struct file *filp, struct 
> kobject *kobj,
>struct bin_attribute *attr, char *buf, loff_t off,
>size_t count)
>  {
> - struct device *connector_dev = container_of(kobj, struct device, kobj);
> + struct device *connector_dev = kobj_to_dev(kobj);
>   struct drm_connector *connector = to_drm_connector(connector_dev);
>   unsigned char *edid;
>   size_t size;
> -- 
> 2.5.0
> 
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Intel-gfx] [PATCH 2/5] drm/i915: use kobj_to_dev()

[Daniel Vetter]

On Wed, Jan 13, 2016 at 10:48:40PM +0800, Geliang Tang wrote:
> Use kobj_to_dev() instead of open-coding it.
> 
> Signed-off-by: Geliang Tang 

Queued for -next, thanks for the patch.
-Daniel

> ---
>  drivers/gpu/drm/i915/i915_sysfs.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_sysfs.c 
> b/drivers/gpu/drm/i915/i915_sysfs.c
> index 37e3f0d..c6188dd 100644
> --- a/drivers/gpu/drm/i915/i915_sysfs.c
> +++ b/drivers/gpu/drm/i915/i915_sysfs.c
> @@ -164,7 +164,7 @@ i915_l3_read(struct file *filp, struct kobject *kobj,
>struct bin_attribute *attr, char *buf,
>loff_t offset, size_t count)
>  {
> - struct device *dev = container_of(kobj, struct device, kobj);
> + struct device *dev = kobj_to_dev(kobj);
>   struct drm_minor *dminor = dev_to_drm_minor(dev);
>   struct drm_device *drm_dev = dminor->dev;
>   struct drm_i915_private *dev_priv = drm_dev->dev_private;
> @@ -200,7 +200,7 @@ i915_l3_write(struct file *filp, struct kobject *kobj,
> struct bin_attribute *attr, char *buf,
> loff_t offset, size_t count)
>  {
> - struct device *dev = container_of(kobj, struct device, kobj);
> + struct device *dev = kobj_to_dev(kobj);
>   struct drm_minor *dminor = dev_to_drm_minor(dev);
>   struct drm_device *drm_dev = dminor->dev;
>   struct drm_i915_private *dev_priv = drm_dev->dev_private;
> @@ -521,7 +521,7 @@ static ssize_t error_state_read(struct file *filp, struct 
> kobject *kobj,
>   loff_t off, size_t count)
>  {
>  
> - struct device *kdev = container_of(kobj, struct device, kobj);
> + struct device *kdev = kobj_to_dev(kobj);
>   struct drm_minor *minor = dev_to_drm_minor(kdev);
>   struct drm_device *dev = minor->dev;
>   struct i915_error_state_file_priv error_priv;
> @@ -556,7 +556,7 @@ static ssize_t error_state_write(struct file *file, 
> struct kobject *kobj,
>struct bin_attribute *attr, char *buf,
>loff_t off, size_t count)
>  {
> - struct device *kdev = container_of(kobj, struct device, kobj);
> + struct device *kdev = kobj_to_dev(kobj);
>   struct drm_minor *minor = dev_to_drm_minor(kdev);
>   struct drm_device *dev = minor->dev;
>   int ret;
> -- 
> 2.5.0
> 
> 
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[RFC/PATCH] drm/rockchip: don't wait for vblank if fb hasn't changed

[John Keeping]

On Wed, 13 Jan 2016 17:21:56 +0100, Daniel Vetter wrote:

> On Wed, Jan 13, 2016 at 03:55:29PM +, John Keeping wrote:
> > On Wed, 13 Jan 2016 16:40:05 +0100, Daniel Vetter wrote:
> >   
> > > On Wed, Jan 13, 2016 at 02:34:25PM +, John Keeping wrote:  
> > > > On Wed, 13 Jan 2016 15:23:20 +0100, Daniel Vetter wrote:
> > > > 
> > > > > On Wed, Jan 13, 2016 at 12:53:34PM +, John Keeping wrote:
> > > > > > As commented in drm_atomic_helper_wait_for_vblanks(), userspace
> > > > > > relies on cursor ioctls being unsynced.  Converting the rockchip
> > > > > > driver to atomic has significantly impacted cursor performance by
> > > > > > making every cursor update wait for vblank.
> > > > > > 
> > > > > > By skipping the vblank sync when the framebuffer has not changed
> > > > > > (as is done in drm_atomic_helper_wait_for_vblanks()) we can avoid
> > > > > > this for the common case of moving the cursor and only need to
> > > > > > delay the cursor ioctl when the cursor icon changes.
> > > > > > 
> > > > > > I originally inserted a check on legacy_cursor_update as well, but
> > > > > > that caused a storm of iommu page faults.  I didn't investigate the
> > > > > > cause of those since this change gives enough of a performance
> > > > > > improvement for my use case.
> > > > > > 
> > > > > > This is RFC because of that and because the framebuffer_changed()
> > > > > > function is copied from drm_atomic_helper.c as a quick way to test
> > > > > > the result.
> > > > > > 
> > > > > > Signed-off-by: John Keeping 
> > > > > > ---
> > > > > >  drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 27
> > > > > > +-- 1 file changed, 25 insertions(+), 2
> > > > > > deletions(-)
> > > > > > 
> > > > > > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> > > > > > b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c index f784488..8fd9821
> > > > > > 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> > > > > > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> > > > > > @@ -177,8 +177,28 @@ static void
> > > > > > rockchip_crtc_wait_for_update(struct drm_crtc *crtc)
> > > > > > crtc_funcs->wait_for_update(crtc); }
> > > > > >  
> > > > > > +static bool framebuffer_changed(struct drm_device *dev,
> > > > > > +   struct drm_atomic_state *old_state,
> > > > > > +   struct drm_crtc *crtc)
> > > > > > +{
> > > > > > +   struct drm_plane *plane;
> > > > > > +   struct drm_plane_state *old_plane_state;
> > > > > > +   int i;
> > > > > > +
> > > > > > +   for_each_plane_in_state(old_state, plane, old_plane_state,
> > > > > > i) {
> > > > > > +   if (plane->state->crtc != crtc &&
> > > > > > +   old_plane_state->crtc != crtc)
> > > > > > +   continue;
> > > > > > +
> > > > > > +   if (plane->state->fb != old_plane_state->fb)
> > > > > > +   return true;
> > > > > > +   }
> > > > > > +
> > > > > > +   return false;
> > > > > > +}  
> > > > > 
> > > > > Please don't hand-roll logic that affects semantics like this. Instead
> > > > > please use drm_atomic_helper_wait_for_vblanks(), which should do this
> > > > > correctly for you.
> > > > > 
> > > > > If that's not the case then we need to improve the generic helper, or
> > > > > figure out what's different with rockhip.
> > > > 
> > > > According to commit 63ebb9f (drm/rockchip: Convert to support atomic
> > > > API) it's because rockchip doesn't have a hardware vblank counter.
> > > > 
> > > > I'm not entirely clear on why this prevents the use of
> > > > drm_atomic_helper_wait_for_vblanks().
> > > 
> > > Hm, that commit isn't terribly helpful. If that's really needed then imo I
> > > think we should extract a "drm_atomic_helper_plane_needs_vblank_wait()"
> > > helper that's used by both. But since rockchip does vblank_get/put calls
> > > I'd hope vblanks actually work correctly. And then the helper should work
> > > too.  
> > 
> > I tried switching the call to rockchip_crtc_wait_for_update() to
> > drm_atomic_helper_wait_for_vblanks() and it works fine until I switch
> > the buffer associated with a cursor, at which point I get iommu page
> > faults, presumably because the GEM buffer is unreferenced too early.
> > 
> > AFAICT the buffer will be released via drm_atomic_state_free()
> > unconditionally, but I suspect I'm missing something since that would
> > mean every driver would hit a similar problem.  
> 
> Yeah, with the helper we always skip, which means when the cursor bo
> changes you indeed unmap too early. So can't even share the overall
> condition, but we could definitely share the little framebuffer_changed
> helper.

That leaves me with the question: why do other atomic drivers work?

If drm_atomic_helper_wait_for_vblanks() skipping vblanks results in the
cursor bo being unmapped too early for rockchip, why is it not unmapped
too early for all of the other drivers using that helper?

[RFC/PATCH] drm/rockchip: don't wait for vblank if fb hasn't changed

[Daniel Vetter]

On Wed, Jan 13, 2016 at 02:34:25PM +, John Keeping wrote:
> On Wed, 13 Jan 2016 15:23:20 +0100, Daniel Vetter wrote:
> 
> > On Wed, Jan 13, 2016 at 12:53:34PM +, John Keeping wrote:
> > > As commented in drm_atomic_helper_wait_for_vblanks(), userspace
> > > relies on cursor ioctls being unsynced.  Converting the rockchip
> > > driver to atomic has significantly impacted cursor performance by
> > > making every cursor update wait for vblank.
> > > 
> > > By skipping the vblank sync when the framebuffer has not changed
> > > (as is done in drm_atomic_helper_wait_for_vblanks()) we can avoid
> > > this for the common case of moving the cursor and only need to
> > > delay the cursor ioctl when the cursor icon changes.
> > > 
> > > I originally inserted a check on legacy_cursor_update as well, but
> > > that caused a storm of iommu page faults.  I didn't investigate the
> > > cause of those since this change gives enough of a performance
> > > improvement for my use case.
> > > 
> > > This is RFC because of that and because the framebuffer_changed()
> > > function is copied from drm_atomic_helper.c as a quick way to test
> > > the result.
> > > 
> > > Signed-off-by: John Keeping 
> > > ---
> > >  drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 27
> > > +-- 1 file changed, 25 insertions(+), 2
> > > deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> > > b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c index f784488..8fd9821
> > > 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> > > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> > > @@ -177,8 +177,28 @@ static void
> > > rockchip_crtc_wait_for_update(struct drm_crtc *crtc)
> > > crtc_funcs->wait_for_update(crtc); }
> > >  
> > > +static bool framebuffer_changed(struct drm_device *dev,
> > > + struct drm_atomic_state *old_state,
> > > + struct drm_crtc *crtc)
> > > +{
> > > + struct drm_plane *plane;
> > > + struct drm_plane_state *old_plane_state;
> > > + int i;
> > > +
> > > + for_each_plane_in_state(old_state, plane, old_plane_state,
> > > i) {
> > > + if (plane->state->crtc != crtc &&
> > > + old_plane_state->crtc != crtc)
> > > + continue;
> > > +
> > > + if (plane->state->fb != old_plane_state->fb)
> > > + return true;
> > > + }
> > > +
> > > + return false;
> > > +}  
> > 
> > Please don't hand-roll logic that affects semantics like this. Instead
> > please use drm_atomic_helper_wait_for_vblanks(), which should do this
> > correctly for you.
> > 
> > If that's not the case then we need to improve the generic helper, or
> > figure out what's different with rockhip.
> 
> According to commit 63ebb9f (drm/rockchip: Convert to support atomic
> API) it's because rockchip doesn't have a hardware vblank counter.
> 
> I'm not entirely clear on why this prevents the use of
> drm_atomic_helper_wait_for_vblanks().

Hm, that commit isn't terribly helpful. If that's really needed then imo I
think we should extract a "drm_atomic_helper_plane_needs_vblank_wait()"
helper that's used by both. But since rockchip does vblank_get/put calls
I'd hope vblanks actually work correctly. And then the helper should work
too.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH v7 2/2] drm/bridge: Add I2C based driver for ps8640 bridge

[Daniel Kurtz]

Hi Jitao,

On Tue, Jan 12, 2016 at 6:18 PM, Jitao Shi  wrote:
> This patch adds drm_bridge driver for parade DSI to eDP bridge chip.
>
> Signed-off-by: Jitao Shi 
> ---
> Changes since v6:
>  - Add ps8640 firmware update function
>  - Change i2c to i2c_transfer from i2c_master_recv/i2c_master_send

Thank you for using i2c_transfer.
Did you notice any improvement during i2c-intesive operations (eg.,
mode set or suspend/resume) by doing so?

>  - Add comments for each page client
> ---
>  drivers/gpu/drm/bridge/Kconfig |   10 +
>  drivers/gpu/drm/bridge/Makefile|1 +
>  drivers/gpu/drm/bridge/parade-ps8640.c | 1106 
> 
>  3 files changed, 1117 insertions(+)
>  create mode 100644 drivers/gpu/drm/bridge/parade-ps8640.c
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 639..dcfdbc9 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -41,4 +41,14 @@ config DRM_PARADE_PS8622
> ---help---
>   Parade eDP-LVDS bridge chip driver.
>
> +config DRM_PARADE_PS8640
> +   tristate "Parade PS8640 MIPI DSI to eDP Converter"
> +   depends on OF

depends on I2C, too.

> +   select DRM_KMS_HELPER
> +   select DRM_PANEL
> +   ---help---
> + Choose this option if you have PS8640 for display
> + The PS8640 is a high-performance and low-power
> + MIPI DSI to eDP converter
> +
>  endmenu
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index d4e28be..272e3c01 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -4,3 +4,4 @@ obj-$(CONFIG_DRM_DW_HDMI) += dw_hdmi.o
>  obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw_hdmi-ahb-audio.o
>  obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
>  obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
> +obj-$(CONFIG_DRM_PARADE_PS8640) += parade-ps8640.o
> diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c 
> b/drivers/gpu/drm/bridge/parade-ps8640.c
> new file mode 100644
> index 000..a18d8e9
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/parade-ps8640.c
> @@ -0,0 +1,1106 @@
> +/*
> + * Copyright (c) 2014 MediaTek Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define PAGE2_SPI_CFG3 0x82
> +#define I2C_TO_SPI_RESET   0x20
> +#define PAGE2_ROMADD_BYTE1 0x8e
> +#define PAGE2_ROMADD_BYTE2 0x8f
> +#define PAGE2_SWSPI_WDATA  0x90
> +#define PAGE2_SWSPI_RDATA  0x91
> +#define PAGE2_SWSPI_LEN0x92
> +#define PAGE2_SWSPI_CTL0x93
> +#define TRIGGER_NO_READBACK0x05
> +#define TRIGGER_READBACK   0x01
> +#define PAGE2_SPI_STATUS   0x9e
> +#define PAGE2_GPIO_L   0xa6
> +#define PAGE2_GPIO_H   0xa7
> +#define PS_GPIO9   BIT(1)
> +#define PAGE2_IROM_CTRL0xb0
> +#define IROM_ENABLE0xc0
> +#define IROM_DISABLE   0x80
> +#define PAGE2_SW_REST  0xbc
> +#define PAGE2_ENCTLSPI_WR  0xda
> +#define PAGE2_I2C_BYPASS   0xea
> +#define I2C_BYPASS_EN  0xd0
> +
> +#define PAGE3_SET_ADD  0xfe
> +#define PAGE3_SET_VAL  0xff
> +#define VDO_CTL_ADD0x13
> +#define VDO_DIS0x18
> +#define VDO_EN 0x1c
> +
> +#define PAGE4_REV_L0xf0
> +#define PAGE4_REV_H0xf1
> +#define PAGE4_CHIP_L   0xf2
> +#define PAGE4_CHIP_H   0xf3
> +
> +/* Firmware */
> +#define SPI_MAX_RETRY_CNT  8
> +#define PS_FW_NAME "ps864x_fw.bin"
> +
> +#define FW_CHIP_ID_OFFSET  0
> +#define FW_VERSION_OFFSET  2
> +
> +#define bridge_to_ps8640(e)container_of(e, struct ps8640, bridge)
> +#define connector_to_ps8640(e) container_of(e, struct ps8640, connector)
> +
> +struct ps8640_info {
> +   u8 family_id;
> +   u8 variant_id;
> +   u16 version;
> +};
> +
> +struct ps8640 {
> +   struct drm_connector connector;
> +   struct drm_bridge bridge;
> +   struct i2c_client *page[8];
> +   struct ps8640_driver_data *driver_data;
> +   struct regulator *pwr_1v2_supply;
> +   struct regulator *pwr_3v3_supply;
> +   struct drm_panel *panel;
> +   struct gpio_desc *gpio_rst_n;
> +   struct gpio_desc *gpio_slp_n;
> +   

[PATCH 2/2] drm/rockchip: cleanup unnecessary export symbol

[Mark Yao]

Now rockchip_drm_vop.c is build into rockchipdrm.ko, so
no need to export following symbol anymore:
rockchip_drm_dma_attach_device
rockchip_drm_dma_detach_device
rockchip_drm_dma_attach_device
rockchip_drm_dma_detach_device
rockchip_register_crtc_funcs
rockchip_unregister_crtc_funcs
rockchip_fb_get_gem_obj

Signed-off-by: Mark Yao 
---
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c |4 
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c  |1 -
 2 files changed, 5 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index 8397d1b..a0d51cc 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -55,14 +55,12 @@ int rockchip_drm_dma_attach_device(struct drm_device 
*drm_dev,

return arm_iommu_attach_device(dev, mapping);
 }
-EXPORT_SYMBOL_GPL(rockchip_drm_dma_attach_device);

 void rockchip_drm_dma_detach_device(struct drm_device *drm_dev,
struct device *dev)
 {
arm_iommu_detach_device(dev);
 }
-EXPORT_SYMBOL_GPL(rockchip_drm_dma_detach_device);

 int rockchip_register_crtc_funcs(struct drm_crtc *crtc,
 const struct rockchip_crtc_funcs *crtc_funcs)
@@ -77,7 +75,6 @@ int rockchip_register_crtc_funcs(struct drm_crtc *crtc,

return 0;
 }
-EXPORT_SYMBOL_GPL(rockchip_register_crtc_funcs);

 void rockchip_unregister_crtc_funcs(struct drm_crtc *crtc)
 {
@@ -89,7 +86,6 @@ void rockchip_unregister_crtc_funcs(struct drm_crtc *crtc)

priv->crtc_funcs[pipe] = NULL;
 }
-EXPORT_SYMBOL_GPL(rockchip_unregister_crtc_funcs);

 static struct drm_crtc *rockchip_crtc_from_pipe(struct drm_device *drm,
int pipe)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
index f784488..dd1f8d3 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
@@ -39,7 +39,6 @@ struct drm_gem_object *rockchip_fb_get_gem_obj(struct 
drm_framebuffer *fb,

return rk_fb->obj[plane];
 }
-EXPORT_SYMBOL_GPL(rockchip_fb_get_gem_obj);

 static void rockchip_drm_fb_destroy(struct drm_framebuffer *fb)
 {
-- 
1.7.9.5

[PATCH 1/2] drm/rockchip: Don't build rockchip_drm_vop as modules

[Mark Yao]

rockchip_drm_vop's module init had moved to rockchip_vop_reg.c
so no need to build rockchip_drm_vop.ko

Signed-off-by: Mark Yao 
---
 drivers/gpu/drm/rockchip/Makefile |5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
index a9d380f..9e6e992 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -3,9 +3,8 @@
 # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.

 rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o rockchip_drm_fbdev.o \
-   rockchip_drm_gem.o
+   rockchip_drm_gem.o rockchip_drm_vop.o

 obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o

-obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o rockchip_drm_vop.o \
-   rockchip_vop_reg.o
+obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o rockchip_vop_reg.o
-- 
1.7.9.5

[PATCH 0/2] drm/rockchip: cleanup unnecessary modules and symbol

[Mark Yao]

Since a67719d (drm/rockchip: vop: spilt register related into
rockchip_reg_vop.c), rockchip_drm_vop's module_init moved to
rockchip_vop_reg.c, then no need to build rockchip_drm_vop.ko

After build rockchip_drm_vop.c into rockchipdrm.ko, following
export symbol is also no needed:
rockchip_drm_dma_attach_device
rockchip_drm_dma_detach_device
rockchip_drm_dma_attach_device
rockchip_drm_dma_detach_device
rockchip_register_crtc_funcs
rockchip_unregister_crtc_funcs
rockchip_fb_get_gem_obj

Mark Yao (2):
  drm/rockchip: Don't build rockchip_drm_vop as modules
  drm/rockchip: cleanup unnecessary export symbol

 drivers/gpu/drm/rockchip/Makefile   |5 ++---
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c |4 
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c  |1 -
 3 files changed, 2 insertions(+), 8 deletions(-)

-- 
1.7.9.5

[PATCH] drm/rockchip: vop: fix mask when updating interrupts

[Mark yao]

On 2016年01月13日 02:05, John Keeping wrote:
> Commit dbb3d94 (drm/rockchip: vop: move interrupt registers into
> vop_data) introduced new macros for updating the interrupt control
> registers but these always use the mask from the register definition
> without refining it for the particular bits that are being changed.
>
> This means that whenever we enable/disable a particular interrupt we end
> up disabling all of the others as a side effect.
>
> Signed-off-by: John Keeping 
> ---
>   drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 16 +---
>   1 file changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index 46c2a8d..fd37054 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -43,8 +43,8 @@
>   
>   #define REG_SET(x, base, reg, v, mode) \
>   __REG_SET_##mode(x, base + reg.offset, reg.mask, reg.shift, v)
> -#define REG_SET_MASK(x, base, reg, v, mode) \
> - __REG_SET_##mode(x, base + reg.offset, reg.mask, reg.shift, v)
> +#define REG_SET_MASK(x, base, reg, mask, v, mode) \
> + __REG_SET_##mode(x, base + reg.offset, mask, reg.shift, v)
>   
>   #define VOP_WIN_SET(x, win, name, v) \
>   REG_SET(x, win->base, win->phy->name, v, RELAXED)
> @@ -58,16 +58,18 @@
>   #define VOP_INTR_GET(vop, name) \
>   vop_read_reg(vop, 0, >data->ctrl->name)
>   
> -#define VOP_INTR_SET(vop, name, v) \
> - REG_SET(vop, 0, vop->data->intr->name, v, NORMAL)
> +#define VOP_INTR_SET(vop, name, mask, v) \
> + REG_SET_MASK(vop, 0, vop->data->intr->name, mask, v, NORMAL)
>   #define VOP_INTR_SET_TYPE(vop, name, type, v) \
>   do { \
> - int i, reg = 0; \
> + int i, reg = 0, mask = 0; \
>   for (i = 0; i < vop->data->intr->nintrs; i++) { \
> - if (vop->data->intr->intrs[i] & type) \
> + if (vop->data->intr->intrs[i] & type) { \
>   reg |= (v) << i; \
> + mask |= 1 << i; \
> + } \
>   } \
> - VOP_INTR_SET(vop, name, reg); \
> + VOP_INTR_SET(vop, name, mask, reg); \
>   } while (0)
>   #define VOP_INTR_GET_TYPE(vop, name, type) \
>   vop_get_intr_type(vop, >data->intr->name, type)
Hi John

Great, it works for me, Thanks for this fix.

Applied to my drm-next branch.

-- ï¼­ark Yao

[PATCH v12 0/18] Add Analogix Core Display Port Driver

[Heiko Stuebner]

Hi Yakir,

Am Mittwoch, 23. Dezember 2015, 20:25:38 schrieb Yakir Yang:
>The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller
> share the same IP, so a lot of parts can be re-used. I split the common
> code into bridge directory, then rk3288 and exynos only need to keep
> some platform code. Cause I can't find the exact IP name of exynos dp
> controller, so I decide to name dp core driver with "analogix" which I
> find in rk3288 eDP TRM

could you rebase your patches on top of Dave's drm-next branch [0] please?
The exynos part got some const attributes for the *_func_ops structs and 
drm_encoder_init got an additional parameter.
I'm still hoping that we can get this finally committed once 4.5-rc1 is 
released in 1.5 weeks :-) .

I did try to merge things together [1], the system at least comes up and 
detects the panel (EDID is read correctly and it turns the backlight on) but 
I don't see any output on the display - hdmi works fine though and X11 is 
claiming everything to be fine in both cases.

So I don't know yet if I made a mistake when putting this together or there 
is an issue on the driver-side.


Thanks
Heiko


[0] http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-next
[1] https://github.com/mmind/linux-rockchip/tree/tmp/analogixdp_v12-veyron
I left out patch16, per your talk with Jingoo and me not seeing any AUX CH 
errors without it.

[PATCH 12/22] drm/atmel: Nuke preclose

[Boris Brezillon]

On Mon, 11 Jan 2016 22:41:06 +0100
Daniel Vetter  wrote:

> The only thing this did was cancle pending flip events, and the core
> takes care of that now.
> 
> Cc: Boris Brezillon 
> Acked-by: Daniel Stone 
> Reviewed-by: Alex Deucher 
> Signed-off-by: Daniel Vetter 

Acked-by: Boris Brezillon 

> ---
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 18 --
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c   | 10 --
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h   |  3 ---
>  3 files changed, 31 deletions(-)
> 
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> index 468a14f266a7..9863291a9a54 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> @@ -280,24 +280,6 @@ static void atmel_hlcdc_crtc_destroy(struct drm_crtc *c)
>   kfree(crtc);
>  }
>  
> -void atmel_hlcdc_crtc_cancel_page_flip(struct drm_crtc *c,
> -struct drm_file *file)
> -{
> - struct atmel_hlcdc_crtc *crtc = drm_crtc_to_atmel_hlcdc_crtc(c);
> - struct drm_pending_vblank_event *event;
> - struct drm_device *dev = c->dev;
> - unsigned long flags;
> -
> - spin_lock_irqsave(>event_lock, flags);
> - event = crtc->event;
> - if (event && event->base.file_priv == file) {
> - event->base.destroy(>base);
> - drm_vblank_put(dev, crtc->id);
> - crtc->event = NULL;
> - }
> - spin_unlock_irqrestore(>event_lock, flags);
> -}
> -
>  static void atmel_hlcdc_crtc_finish_page_flip(struct atmel_hlcdc_crtc *crtc)
>  {
>   struct drm_device *dev = crtc->base.dev;
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> index a45b32ba029e..3d8d16402d07 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> @@ -619,15 +619,6 @@ static void atmel_hlcdc_dc_connector_unplug_all(struct 
> drm_device *dev)
>   mutex_unlock(>mode_config.mutex);
>  }
>  
> -static void atmel_hlcdc_dc_preclose(struct drm_device *dev,
> - struct drm_file *file)
> -{
> - struct drm_crtc *crtc;
> -
> - list_for_each_entry(crtc, >mode_config.crtc_list, head)
> - atmel_hlcdc_crtc_cancel_page_flip(crtc, file);
> -}
> -
>  static void atmel_hlcdc_dc_lastclose(struct drm_device *dev)
>  {
>   struct atmel_hlcdc_dc *dc = dev->dev_private;
> @@ -698,7 +689,6 @@ static struct drm_driver atmel_hlcdc_dc_driver = {
>   .driver_features = DRIVER_HAVE_IRQ | DRIVER_GEM |
>  DRIVER_MODESET | DRIVER_PRIME |
>  DRIVER_ATOMIC,
> - .preclose = atmel_hlcdc_dc_preclose,
>   .lastclose = atmel_hlcdc_dc_lastclose,
>   .irq_handler = atmel_hlcdc_dc_irq_handler,
>   .irq_preinstall = atmel_hlcdc_dc_irq_uninstall,
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h 
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
> index cf6b375bc38d..fed517f297da 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
> @@ -152,9 +152,6 @@ int atmel_hlcdc_plane_prepare_disc_area(struct 
> drm_crtc_state *c_state);
>  
>  void atmel_hlcdc_crtc_irq(struct drm_crtc *c);
>  
> -void atmel_hlcdc_crtc_cancel_page_flip(struct drm_crtc *crtc,
> -struct drm_file *file);
> -
>  void atmel_hlcdc_crtc_suspend(struct drm_crtc *crtc);
>  void atmel_hlcdc_crtc_resume(struct drm_crtc *crtc);
>  



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[RFC/PATCH] drm/rockchip: don't wait for vblank if fb hasn't changed

[John Keeping]

On Wed, 13 Jan 2016 16:40:05 +0100, Daniel Vetter wrote:

> On Wed, Jan 13, 2016 at 02:34:25PM +, John Keeping wrote:
> > On Wed, 13 Jan 2016 15:23:20 +0100, Daniel Vetter wrote:
> >   
> > > On Wed, Jan 13, 2016 at 12:53:34PM +, John Keeping wrote:  
> > > > As commented in drm_atomic_helper_wait_for_vblanks(), userspace
> > > > relies on cursor ioctls being unsynced.  Converting the rockchip
> > > > driver to atomic has significantly impacted cursor performance by
> > > > making every cursor update wait for vblank.
> > > > 
> > > > By skipping the vblank sync when the framebuffer has not changed
> > > > (as is done in drm_atomic_helper_wait_for_vblanks()) we can avoid
> > > > this for the common case of moving the cursor and only need to
> > > > delay the cursor ioctl when the cursor icon changes.
> > > > 
> > > > I originally inserted a check on legacy_cursor_update as well, but
> > > > that caused a storm of iommu page faults.  I didn't investigate the
> > > > cause of those since this change gives enough of a performance
> > > > improvement for my use case.
> > > > 
> > > > This is RFC because of that and because the framebuffer_changed()
> > > > function is copied from drm_atomic_helper.c as a quick way to test
> > > > the result.
> > > > 
> > > > Signed-off-by: John Keeping 
> > > > ---
> > > >  drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 27
> > > > +-- 1 file changed, 25 insertions(+), 2
> > > > deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> > > > b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c index f784488..8fd9821
> > > > 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> > > > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> > > > @@ -177,8 +177,28 @@ static void
> > > > rockchip_crtc_wait_for_update(struct drm_crtc *crtc)
> > > > crtc_funcs->wait_for_update(crtc); }
> > > >  
> > > > +static bool framebuffer_changed(struct drm_device *dev,
> > > > +   struct drm_atomic_state *old_state,
> > > > +   struct drm_crtc *crtc)
> > > > +{
> > > > +   struct drm_plane *plane;
> > > > +   struct drm_plane_state *old_plane_state;
> > > > +   int i;
> > > > +
> > > > +   for_each_plane_in_state(old_state, plane, old_plane_state,
> > > > i) {
> > > > +   if (plane->state->crtc != crtc &&
> > > > +   old_plane_state->crtc != crtc)
> > > > +   continue;
> > > > +
> > > > +   if (plane->state->fb != old_plane_state->fb)
> > > > +   return true;
> > > > +   }
> > > > +
> > > > +   return false;
> > > > +}
> > > 
> > > Please don't hand-roll logic that affects semantics like this. Instead
> > > please use drm_atomic_helper_wait_for_vblanks(), which should do this
> > > correctly for you.
> > > 
> > > If that's not the case then we need to improve the generic helper, or
> > > figure out what's different with rockhip.  
> > 
> > According to commit 63ebb9f (drm/rockchip: Convert to support atomic
> > API) it's because rockchip doesn't have a hardware vblank counter.
> > 
> > I'm not entirely clear on why this prevents the use of
> > drm_atomic_helper_wait_for_vblanks().  
> 
> Hm, that commit isn't terribly helpful. If that's really needed then imo I
> think we should extract a "drm_atomic_helper_plane_needs_vblank_wait()"
> helper that's used by both. But since rockchip does vblank_get/put calls
> I'd hope vblanks actually work correctly. And then the helper should work
> too.

I tried switching the call to rockchip_crtc_wait_for_update() to
drm_atomic_helper_wait_for_vblanks() and it works fine until I switch
the buffer associated with a cursor, at which point I get iommu page
faults, presumably because the GEM buffer is unreferenced too early.

AFAICT the buffer will be released via drm_atomic_state_free()
unconditionally, but I suspect I'm missing something since that would
mean every driver would hit a similar problem.

[PATCH 4/4] drm: virtio-gpu: set atomic flag

[Rob Herring]

Advertise atomic mode setting capability to user space.

Signed-off-by: Rob Herring 
---
 drivers/gpu/drm/virtio/virtgpu_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c 
b/drivers/gpu/drm/virtio/virtgpu_drv.c
index b40ed60..7f898cf 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.c
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.c
@@ -118,7 +118,7 @@ static const struct file_operations virtio_gpu_driver_fops 
= {


 static struct drm_driver driver = {
-   .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME | 
DRIVER_RENDER,
+   .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME | 
DRIVER_RENDER | DRIVER_ATOMIC,
.set_busid = drm_virtio_set_busid,
.load = virtio_gpu_driver_load,
.unload = virtio_gpu_driver_unload,
-- 
2.5.0

[PATCH 3/4] drm: virtio-gpu: transfer dumb buffers to host on plane update

[Rob Herring]

For dumb buffers, we need to transfer them to the host when updating a
plane.

Signed-off-by: Rob Herring 
---
 drivers/gpu/drm/virtio/virtgpu_plane.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c 
b/drivers/gpu/drm/virtio/virtgpu_plane.c
index af121cf..7b6e5c5 100644
--- a/drivers/gpu/drm/virtio/virtgpu_plane.c
+++ b/drivers/gpu/drm/virtio/virtgpu_plane.c
@@ -72,6 +72,13 @@ static void virtio_gpu_plane_atomic_update(struct drm_plane 
*plane,
vgfb = to_virtio_gpu_framebuffer(plane->state->fb);
bo = gem_to_virtio_gpu_obj(vgfb->obj);
handle = bo->hw_res_handle;
+   if (bo->dumb) {
+   virtio_gpu_cmd_transfer_to_host_2d
+   (vgdev, handle, 0,
+cpu_to_le32(plane->state->crtc_w),
+cpu_to_le32(plane->state->crtc_h),
+plane->state->crtc_x, plane->state->crtc_y, 
NULL);
+   }
} else {
handle = 0;
}
-- 
2.5.0

[PATCH 2/4] drm: virtio-gpu: ensure plane is flushed to host on atomic update

[Rob Herring]

This fixes drawing updates when updating planes with atomic API.

Signed-off-by: Rob Herring 
---
 drivers/gpu/drm/virtio/virtgpu_plane.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c 
b/drivers/gpu/drm/virtio/virtgpu_plane.c
index 6b9ad59..af121cf 100644
--- a/drivers/gpu/drm/virtio/virtgpu_plane.c
+++ b/drivers/gpu/drm/virtio/virtgpu_plane.c
@@ -84,6 +84,11 @@ static void virtio_gpu_plane_atomic_update(struct drm_plane 
*plane,
   plane->state->crtc_h,
   plane->state->crtc_x,
   plane->state->crtc_y);
+   virtio_gpu_cmd_resource_flush(vgdev, handle,
+ plane->state->crtc_x,
+ plane->state->crtc_y,
+ plane->state->crtc_w,
+ plane->state->crtc_h);
 }


-- 
2.5.0

[PATCH 1/4] drm: virtio-gpu: get the fb from the plane state for atomic updates

[Rob Herring]

When using the atomic API, plane->fb is not set when calling
virtio_gpu_plane_atomic_update. Use plane->state->fb instead.

Signed-off-by: Rob Herring 
---
 drivers/gpu/drm/virtio/virtgpu_plane.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c 
b/drivers/gpu/drm/virtio/virtgpu_plane.c
index 4a74129..6b9ad59 100644
--- a/drivers/gpu/drm/virtio/virtgpu_plane.c
+++ b/drivers/gpu/drm/virtio/virtgpu_plane.c
@@ -68,8 +68,8 @@ static void virtio_gpu_plane_atomic_update(struct drm_plane 
*plane,
struct virtio_gpu_object *bo;
uint32_t handle;

-   if (plane->fb) {
-   vgfb = to_virtio_gpu_framebuffer(plane->fb);
+   if (plane->state->fb) {
+   vgfb = to_virtio_gpu_framebuffer(plane->state->fb);
bo = gem_to_virtio_gpu_obj(vgfb->obj);
handle = bo->hw_res_handle;
} else {
-- 
2.5.0

[PATCH 0/4] virtio-gpu: Fixes for atomic support

[Rob Herring]

Dave,

This series is the minimal changes to get virtio-gpu working with 
Android DRM based hwcomposer. The first 3 patches are fixes, but I 
assume they are only hit if using the atomic APIs which is dependent on 
the 4th patch. I suspect async commit support is also missing, but 
Android doesn't seem to need it.

I also have a few more patches for fb emulation to support panning and 
mmapping the framebuffer. I'm not too sure that is really worth 
supporting though.

Rob

Rob Herring (4):
  drm: virtio-gpu: get the fb from the plane state for atomic updates
  drm: virtio-gpu: ensure plane is flushed to host on atomic update
  drm: virtio-gpu: transfer dumb buffers to host on plane update
  drm: virtio-gpu: set atomic flag

 drivers/gpu/drm/virtio/virtgpu_drv.c   |  2 +-
 drivers/gpu/drm/virtio/virtgpu_plane.c | 16 ++--
 2 files changed, 15 insertions(+), 3 deletions(-)

-- 
2.5.0

[PATCH] drm/crtc-helper: Add caveat to disable_unused_functions doc

[Daniel Vetter]

This shouldn't be used by atomic drivers any more, it confuses the
state tracking.

Cc: Maxime Ripard 
Cc: Laurent Pinchart 
Acked-by: Laurent Pinchart 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_crtc_helper.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index a02a7f9a6a9d..a278fbbe23e0 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -220,6 +220,15 @@ static void __drm_helper_disable_unused_functions(struct 
drm_device *dev)
  * disconnected connectors. Then it will disable all unused encoders and CRTCs
  * either by calling their disable callback if available or by calling their
  * dpms callback with DRM_MODE_DPMS_OFF.
+ *
+ * NOTE:
+ *
+ * This function is part of the legacy modeset helper library and will cause
+ * major confusion with atomic drivers. This is because atomic helpers 
guarantee
+ * to never call ->disable() hooks on a disabled function, or ->enable() hooks
+ * on an enabled functions. drm_helper_disable_unused_functions() on the other
+ * hand throws such guarantees into the wind and calls disable hooks
+ * unconditionally on unused functions.
  */
 void drm_helper_disable_unused_functions(struct drm_device *dev)
 {
-- 
2.7.0.rc3

[RFC] handling of alpha mode (pre-multiplied/straight) in ARGB modes

[Daniel Vetter]

On Wed, Jan 13, 2016 at 03:13:35PM +0100, Marek Szyprowski wrote:
> Hello,
> 
> On 2016-01-11 16:22, Ville Syrjälä wrote:
> >On Mon, Jan 11, 2016 at 04:07:50PM +0100, Daniel Vetter wrote:
> >>On Mon, Jan 11, 2016 at 03:18:44PM +0100, Marek Szyprowski wrote:
> >>>Dear All,
> >>>
> >>>I would like to add support for configuring alpha modes: straight and
> >>>pre-multiplied for blending to Exynos DRM driver. For those who see those
> >>>terms for the first time:
> >>>1. straight alpha mode means means that all A and RGB values are from full
> >>>0.255 range,
> >>>2. pre-multiplied alpha mode means that A is from 0..255 range and RGB
> >>>values are scaled to 0..ALPHA range (where ALPHA is the A value for the
> >>>given pixel).
> >>>The pre-multiplied mode is quite common in texture processing.
> >>>
> >>>I did a little research and found that there is no common approach for
> >>>defining straight or pre-multiplied alpha modes for ARGB framebuffers.
> >>>
> From reading the sources and the register names I found that following
> >>>drivers use pre-multiplied modes for ARGB framebuffers:
> >>>radeon (at least for ARGB cursors),
> >>>amdgpu (cursor),
> >>>intel (all ARGB planes),
> >>>rock chip.
> >>>
> >>>On the other hand, there are drm drivers which support ARGB modes and use
> >>>straight alpha modes:
> >>>omap,
> >>>msm.
> >>>
> >>>For the rest of drivers, which might deal with per-pixel alpha, I was not
> >>>able to determine from the code if the pixel RGB values are interpreted as
> >>>per-multiplied or straight:
> >>>atmel_hlcdc,
> >>>sti,
> >>>mdp5,
> >>>shmobile,
> >>>rcar,
> >>>vc4,
> >>>imx.
> >>Imo in case of doubt/mixed definitions the semantics of the big desktop
> >>drivers should win. True generic userspace is most likely developed on
> >>those, everything else should just adjust. And in most cases we can get
> >>away with that on arm drivers since they tend to ship userspace and kernel
> >>in lockstep. At least where it really matters.
> >>
> >>>Exynos DRM driver now mixes pre-multiplied and straight modes, depending on
> >>>the CRTC sub-driver.
> >>>
> >>>While checking the code I found a following comment in
> >>>drm/i915/intel_display.c in skl_plane_ctl_format() function:
> >>>/*
> >>>  * XXX: For ARBG/ABGR formats we default to expecting scanout buffers
> >>>  * to be already pre-multiplied. We need to add a knob (or a different
> >>>  * DRM_FORMAT) for user-space to configure that.
> >>>  */
> >>>
> >>>The question is how to cleanup this ambiguities and let generic userspace 
> >>>to
> >>>properly use ARGB/ARGB modes with proper blending mode. I came up with the
> >>>following 3 solutions:
> >>>
> >>>1. Define new fourcc values for pre-multiplied (or/and straight) alpha
> >>>modes,
> >>>2. Introduce a new framebuffer flag for pre-multiplied or straight alpha 
> >>>(or
> >>>both),
> >>>3. Introduce a new plane property for controlling alpha blending mode.
> >>>
> >>>The first solution has serious compatibility problem, because we can either
> >>>map existing fourcc to pre-multiplied (to follow radeon/amdgpu, intel and
> >>>rockchip behavior) or straight mode. Both ways it will break some existing
> >>>applications. To avoid compatibility problem we would need to add 2 more
> >>>sets of fourcc and leave existing ARGB modes as 'driver dependent'.
> >>>
> >>>The second solution is probably a bit less intrusive, but it suffers for 
> >>>the
> >>>similar compatibility problem. To make this feature compatible with 
> >>>existing
> >>>code, probably 2 flags will be needed: 
> >>>DRM_MODE_FB_ALPHA_FORCE_PREMULTIPLIED
> >>>and DRM_MODE_FB_ALPHA_FORCE_STRAIGHT. This way when userspace provides no
> >>>flag, the driver can use its default mode.
> >>>
> >>>Third solution (additional plane property) has been already proposed:
> >>>https://lkml.org/lkml/2015/6/19/330, however I found no follow-up nor
> >>>comments. Separate property lets at least drivers to notify userspace about
> >>>driver's default alpha mode and lets generic application to properly set 
> >>>the
> >>>requested mode. The only problem is that the alpha mode is not directly
> >>>configured on the framebuffer object, where in my opinion it should be
> >>>stored.
> >>>
> >>>Please let me know which approach You like best and which should I take for
> >>>introducing generic way of configuring alpha mode.
> >>One idea that was tossed around a few times is to go full generic and
> >>implement something like glBlendFunc for planes, except that we'd also
> >>pre-multiplied/straight versions where it makes sense. For drivers that
> >>can't support pre-multiplied alpha they could simply leave out these
> >>values from the blend-func property (like we already allow with e.g.
> >>rotation, when a driver can't do 90/270°).
> >>
> >>Wrt backwards compat a property would work well too: If it's not there
> >>then userspace should assume old behaviour (which should be pre-multiplied
> >>really, but might be somewhat broken on some 

[RFC/PATCH] drm/rockchip: don't wait for vblank if fb hasn't changed

[Daniel Vetter]

On Wed, Jan 13, 2016 at 12:53:34PM +, John Keeping wrote:
> As commented in drm_atomic_helper_wait_for_vblanks(), userspace relies
> on cursor ioctls being unsynced.  Converting the rockchip driver to
> atomic has significantly impacted cursor performance by making every
> cursor update wait for vblank.
> 
> By skipping the vblank sync when the framebuffer has not changed (as is
> done in drm_atomic_helper_wait_for_vblanks()) we can avoid this for the
> common case of moving the cursor and only need to delay the cursor ioctl
> when the cursor icon changes.
> 
> I originally inserted a check on legacy_cursor_update as well, but that
> caused a storm of iommu page faults.  I didn't investigate the cause of
> those since this change gives enough of a performance improvement for my
> use case.
> 
> This is RFC because of that and because the framebuffer_changed()
> function is copied from drm_atomic_helper.c as a quick way to test the
> result.
> 
> Signed-off-by: John Keeping 
> ---
>  drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 27 +--
>  1 file changed, 25 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> index f784488..8fd9821 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> @@ -177,8 +177,28 @@ static void rockchip_crtc_wait_for_update(struct 
> drm_crtc *crtc)
>   crtc_funcs->wait_for_update(crtc);
>  }
>  
> +static bool framebuffer_changed(struct drm_device *dev,
> + struct drm_atomic_state *old_state,
> + struct drm_crtc *crtc)
> +{
> + struct drm_plane *plane;
> + struct drm_plane_state *old_plane_state;
> + int i;
> +
> + for_each_plane_in_state(old_state, plane, old_plane_state, i) {
> + if (plane->state->crtc != crtc &&
> + old_plane_state->crtc != crtc)
> + continue;
> +
> + if (plane->state->fb != old_plane_state->fb)
> + return true;
> + }
> +
> + return false;
> +}

Please don't hand-roll logic that affects semantics like this. Instead
please use drm_atomic_helper_wait_for_vblanks(), which should do this
correctly for you.

If that's not the case then we need to improve the generic helper, or
figure out what's different with rockhip.

Thanks, Daniel

> +
>  static void
> -rockchip_atomic_wait_for_complete(struct drm_atomic_state *old_state)
> +rockchip_atomic_wait_for_complete(struct drm_device *dev, struct 
> drm_atomic_state *old_state)
>  {
>   struct drm_crtc_state *old_crtc_state;
>   struct drm_crtc *crtc;
> @@ -194,6 +214,9 @@ rockchip_atomic_wait_for_complete(struct drm_atomic_state 
> *old_state)
>   if (!crtc->state->active)
>   continue;
>  
> + if (!framebuffer_changed(dev, old_state, crtc))
> + continue;
> +
>   ret = drm_crtc_vblank_get(crtc);
>   if (ret != 0)
>   continue;
> @@ -241,7 +264,7 @@ rockchip_atomic_commit_complete(struct 
> rockchip_atomic_commit *commit)
>  
>   drm_atomic_helper_commit_planes(dev, state, true);
>  
> - rockchip_atomic_wait_for_complete(state);
> + rockchip_atomic_wait_for_complete(dev, state);
>  
>   drm_atomic_helper_cleanup_planes(dev, state);
>  
> -- 
> 2.7.0.rc3.140.g520a093
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

OMAPDSS: panel-sharp-ls037v7dw01: update to use gpiod

[Tony Lindgren]

Hi,

* Dan Carpenter  [151223 23:29]:
> [ It's weird that I'm just now getting this warning from 2014...  Oh
> well, looks legit. -dan ]

Sorry for the delay on this one, got distracted few times with
other bugs to deal with. This seems like a valid warning yeah.

Tomi, do we really need two copies of the the same panels
files in kernel?

For example:

$ find . -name panel-sharp-ls037v7dw01.c
./drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c
./drivers/video/fbdev/omap2/omapfb/displays/panel-sharp-ls037v7dw01.c

> The patch 9522f9fe86f9: "OMAPDSS: panel-sharp-ls037v7dw01: update to
> use gpiod" from Apr 28, 2014, leads to the following static checker
> warning:
> 
>   drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c:213 
> sharp_ls_get_gpio()
>   warn: 'gd' isn't an ERR_PTR
> 
> drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c
>200  static int sharp_ls_get_gpio(struct device *dev, int gpio, unsigned 
> long flags,
>201char *desc, struct gpio_desc **gpiod)
>202  {
>203  struct gpio_desc *gd;
>204  int r;
>205  
>206  *gpiod = NULL;
>207  
>208  r = devm_gpio_request_one(dev, gpio, flags, desc);
>209  if (r)
>210  return r == -ENOENT ? 0 : r;
>211  
>212  gd = gpio_to_desc(gpio);
>213  if (IS_ERR(gd))
>214  return PTR_ERR(gd) == -ENOENT ? 0 : PTR_ERR(gd);
>^^
> gd can be an ERR_PTR if gpio_to_desc is defined out but it's never
> -ENOENT.

Seems like we can just remove the check for -ENOENT here.

Rgards,

Tony

[patch] drm/nouveau/pci: reversed condition in nvkm_pcie_set_link()

[Dan Carpenter]

The condition is reversed so this function is a no-op.

Fixes: bcc19d9bf5cd ('drm/nouveau/pci: implement generic code for pcie speed 
change')
Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/pci/pcie.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/pci/pcie.c
index b32954f..d71e5db 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/pci/pcie.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pci/pcie.c
@@ -119,7 +119,7 @@ nvkm_pcie_set_link(struct nvkm_pci *pci, enum 
nvkm_pcie_speed speed, u8 width)
struct pci_bus *pbus;
int ret;

-   if (pci || !pci_is_pcie(pci->pdev))
+   if (!pci || !pci_is_pcie(pci->pdev))
return 0;
pbus = pci->pdev->bus;

[RFC] handling of alpha mode (pre-multiplied/straight) in ARGB modes

[Marek Szyprowski]

Hello,

On 2016-01-11 16:22, Ville Syrjälä wrote:
> On Mon, Jan 11, 2016 at 04:07:50PM +0100, Daniel Vetter wrote:
>> On Mon, Jan 11, 2016 at 03:18:44PM +0100, Marek Szyprowski wrote:
>>> Dear All,
>>>
>>> I would like to add support for configuring alpha modes: straight and
>>> pre-multiplied for blending to Exynos DRM driver. For those who see those
>>> terms for the first time:
>>> 1. straight alpha mode means means that all A and RGB values are from full
>>> 0.255 range,
>>> 2. pre-multiplied alpha mode means that A is from 0..255 range and RGB
>>> values are scaled to 0..ALPHA range (where ALPHA is the A value for the
>>> given pixel).
>>> The pre-multiplied mode is quite common in texture processing.
>>>
>>> I did a little research and found that there is no common approach for
>>> defining straight or pre-multiplied alpha modes for ARGB framebuffers.
>>>
>>> >From reading the sources and the register names I found that following
>>> drivers use pre-multiplied modes for ARGB framebuffers:
>>> radeon (at least for ARGB cursors),
>>> amdgpu (cursor),
>>> intel (all ARGB planes),
>>> rock chip.
>>>
>>> On the other hand, there are drm drivers which support ARGB modes and use
>>> straight alpha modes:
>>> omap,
>>> msm.
>>>
>>> For the rest of drivers, which might deal with per-pixel alpha, I was not
>>> able to determine from the code if the pixel RGB values are interpreted as
>>> per-multiplied or straight:
>>> atmel_hlcdc,
>>> sti,
>>> mdp5,
>>> shmobile,
>>> rcar,
>>> vc4,
>>> imx.
>> Imo in case of doubt/mixed definitions the semantics of the big desktop
>> drivers should win. True generic userspace is most likely developed on
>> those, everything else should just adjust. And in most cases we can get
>> away with that on arm drivers since they tend to ship userspace and kernel
>> in lockstep. At least where it really matters.
>>
>>> Exynos DRM driver now mixes pre-multiplied and straight modes, depending on
>>> the CRTC sub-driver.
>>>
>>> While checking the code I found a following comment in
>>> drm/i915/intel_display.c in skl_plane_ctl_format() function:
>>> /*
>>>   * XXX: For ARBG/ABGR formats we default to expecting scanout buffers
>>>   * to be already pre-multiplied. We need to add a knob (or a different
>>>   * DRM_FORMAT) for user-space to configure that.
>>>   */
>>>
>>> The question is how to cleanup this ambiguities and let generic userspace to
>>> properly use ARGB/ARGB modes with proper blending mode. I came up with the
>>> following 3 solutions:
>>>
>>> 1. Define new fourcc values for pre-multiplied (or/and straight) alpha
>>> modes,
>>> 2. Introduce a new framebuffer flag for pre-multiplied or straight alpha (or
>>> both),
>>> 3. Introduce a new plane property for controlling alpha blending mode.
>>>
>>> The first solution has serious compatibility problem, because we can either
>>> map existing fourcc to pre-multiplied (to follow radeon/amdgpu, intel and
>>> rockchip behavior) or straight mode. Both ways it will break some existing
>>> applications. To avoid compatibility problem we would need to add 2 more
>>> sets of fourcc and leave existing ARGB modes as 'driver dependent'.
>>>
>>> The second solution is probably a bit less intrusive, but it suffers for the
>>> similar compatibility problem. To make this feature compatible with existing
>>> code, probably 2 flags will be needed: DRM_MODE_FB_ALPHA_FORCE_PREMULTIPLIED
>>> and DRM_MODE_FB_ALPHA_FORCE_STRAIGHT. This way when userspace provides no
>>> flag, the driver can use its default mode.
>>>
>>> Third solution (additional plane property) has been already proposed:
>>> https://lkml.org/lkml/2015/6/19/330, however I found no follow-up nor
>>> comments. Separate property lets at least drivers to notify userspace about
>>> driver's default alpha mode and lets generic application to properly set the
>>> requested mode. The only problem is that the alpha mode is not directly
>>> configured on the framebuffer object, where in my opinion it should be
>>> stored.
>>>
>>> Please let me know which approach You like best and which should I take for
>>> introducing generic way of configuring alpha mode.
>> One idea that was tossed around a few times is to go full generic and
>> implement something like glBlendFunc for planes, except that we'd also
>> pre-multiplied/straight versions where it makes sense. For drivers that
>> can't support pre-multiplied alpha they could simply leave out these
>> values from the blend-func property (like we already allow with e.g.
>> rotation, when a driver can't do 90/270°).
>>
>> Wrt backwards compat a property would work well too: If it's not there
>> then userspace should assume old behaviour (which should be pre-multiplied
>> really, but might be somewhat broken on some drivers/kernel).
>>
>> Damien had some RFC about all this way back, but can't find it right now.
> I remembe he said he wanted to work on it, but I don't remember seeing
> anything come out of that. I guess he got swallowed by 

[Intel-gfx] [PATCH 1/5] drm/i915: use hlist_for_each_entry

[Chris Wilson]

On Wed, Jan 13, 2016 at 10:48:39PM +0800, Geliang Tang wrote:
> Use hlist_for_each_entry() instead of hlist_for_each() to simplify
> the code.
> 
> Signed-off-by: Geliang Tang 
> ---
>  drivers/gpu/drm/i915/i915_gem_execbuffer.c | 10 +++---
>  1 file changed, 3 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index 5d01ea6..8f194be 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -192,14 +192,10 @@ static struct i915_vma *eb_get_vma(struct eb_vmas *eb, 
> unsigned long handle)
>   return NULL;
>   return eb->lut[handle];
>   } else {
> - struct hlist_head *head;
> - struct hlist_node *node;
> -
> - head = >buckets[handle & eb->and];
> - hlist_for_each(node, head) {
> - struct i915_vma *vma;
> + struct i915_vma *vma;
>  
> - vma = hlist_entry(node, struct i915_vma, exec_node);
> + hlist_for_each_entry(vma, >buckets[handle & eb->and],
> +  exec_node) {

Keep the 
head = >buckets[handle & eb->and];
local assignment as it makes the line splitting neater (and iirc
something like gcc -Os doesn't use the temporary assignment - but then
who would use CONFIG_OPTIMIZE_FOR_SIZE!).
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH 19/22] drm/tegra: Stop cancelling page flip events

[Thierry Reding]

On Mon, Jan 11, 2016 at 10:41:13PM +0100, Daniel Vetter wrote:
> The core takes care of that now.
> 
> v2: Fixup misplaced hunk.
> 
> Cc: Thierry Reding 
> Cc: Terje Bergström 
> Acked-by: Daniel Stone 
> Reviewed-by: Alex Deucher 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/tegra/dc.c  | 17 -
>  drivers/gpu/drm/tegra/drm.c |  3 ---
>  drivers/gpu/drm/tegra/drm.h |  1 -
>  3 files changed, 21 deletions(-)

Acked-by: Thierry Reding 
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160113/031530ad/attachment.sig>

[PATCH 0/7] drm/exynos/hdmi: add Exynos5433 support

[Andrzej Hajda]

Hi Inki,

Ping.

Regards
Andrzej

On 11/02/2015 02:16 PM, Andrzej Hajda wrote:
> Hi Inki, Krzysztof,
> 
> This patchset adds support for Exynos 5433 HDMI.
> There are also few preparation/cleanup patches.
> All patches except one touch only exynos-drm.
> Sixth patch adds binding properties for Exynos5433 HDMI,
> Krzysztof could you look at it.
> 
> The patchset is based on exynos-drm-next.
> 
> Regards
> Andrzej
> 
> 
> Andrzej Hajda (7):
>   drm/exynos/hdmi: clock code re-factoring
>   drm/exynos/hdmi: constify global variables
>   drm/exynos/hdmi: use array specifier for HDMI-PHY configurations
>   drm/exynos/hdmi: code cleanup
>   drm/exynos/hdmi: stop programming registers with default values
>   dt-bindings: exynos_hdmi: add bindings for Exynos5433 variant
>   drm/exynos/hdmi: add Exynos5433 support
> 
>  .../devicetree/bindings/video/exynos_hdmi.txt  |  27 +-
>  drivers/gpu/drm/exynos/exynos_hdmi.c   | 454 
> +++--
>  drivers/gpu/drm/exynos/regs-hdmi.h |   9 +-
>  3 files changed, 352 insertions(+), 138 deletions(-)
> 

[PATCH] drm: nouveau: fix nouveau_debugfs_init prototype

[Arnd Bergmann]

On Wednesday 13 January 2016 14:55:47 Karol Herbst wrote:
> > Arnd Bergmann  hat am 13. Januar 2016 um 14:48 
> > geschrieben:
> > 
> > The new debugfs initialization code fails to build when CONFIG_DEBUG_FS
> > is disabled:
> > 
> > In file included from 
> > /git/arm-soc/drivers/gpu/drm/nouveau/nouveau_drm.c:57:0:
> > drivers/gpu/drm/nouveau/nouveau_debugfs.h: In function 
> > 'nouveau_debugfs_init':
> > drivers/gpu/drm/nouveau/nouveau_debugfs.h:37:29: error: parameter name 
> > omitted
> >  nouveau_debugfs_init(struct nouveau_drm *)
> > 
> > This fixes the prototypes so we can build it again.
> > 
> 
> thanks for this. I already send a patch to the nouveau ML here:
> http://lists.freedesktop.org/archives/nouveau/2016-January/023779.html

Ok, thanks

Arnd

[PATCH] drm: nouveau: fix nouveau_debugfs_init prototype

[Karol Herbst]

> Arnd Bergmann  hat am 13. Januar 2016 um 14:48 geschrieben:
> 
> The new debugfs initialization code fails to build when CONFIG_DEBUG_FS
> is disabled:
> 
> In file included from /git/arm-soc/drivers/gpu/drm/nouveau/nouveau_drm.c:57:0:
> drivers/gpu/drm/nouveau/nouveau_debugfs.h: In function 'nouveau_debugfs_init':
> drivers/gpu/drm/nouveau/nouveau_debugfs.h:37:29: error: parameter name omitted
>  nouveau_debugfs_init(struct nouveau_drm *)
> 
> This fixes the prototypes so we can build it again.
> 

thanks for this. I already send a patch to the nouveau ML here:
http://lists.freedesktop.org/archives/nouveau/2016-January/023779.html

but I guess I should mail to the kernel list directly next time.

> Signed-off-by: Arnd Bergmann 
> Fixes: b126a200e9db ("drm/nouveau/debugfs: we need a ctrl object for debugfs")
> ---
> This broke when the nouveau patches got merged into drm-next on Monday.
> Found on ARM randconfig builds.
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_debugfs.h
> b/drivers/gpu/drm/nouveau/nouveau_debugfs.h
> index 52c7161297d7..b8c03ff5bf05 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_debugfs.h
> +++ b/drivers/gpu/drm/nouveau/nouveau_debugfs.h
> @@ -34,13 +34,13 @@ nouveau_drm_debugfs_cleanup(struct drm_minor *minor)
>  }
> 
>  static inline int
> -nouveau_debugfs_init(struct nouveau_drm *)
> +nouveau_debugfs_init(struct nouveau_drm *drm)
>  {
>  return 0;
>  }
> 
>  static inline void
> -nouveau_debugfs_fini(struct nouveau_drm *)
> +nouveau_debugfs_fini(struct nouveau_drm *drm)
>  {
>  }

>

[PATCH] drm: nouveau: fix nouveau_debugfs_init prototype

[Arnd Bergmann]

The new debugfs initialization code fails to build when CONFIG_DEBUG_FS
is disabled:

In file included from /git/arm-soc/drivers/gpu/drm/nouveau/nouveau_drm.c:57:0:
drivers/gpu/drm/nouveau/nouveau_debugfs.h: In function 'nouveau_debugfs_init':
drivers/gpu/drm/nouveau/nouveau_debugfs.h:37:29: error: parameter name omitted
 nouveau_debugfs_init(struct nouveau_drm *)

This fixes the prototypes so we can build it again.

Signed-off-by: Arnd Bergmann 
Fixes: b126a200e9db ("drm/nouveau/debugfs: we need a ctrl object for debugfs")
---
This broke when the nouveau patches got merged into drm-next on Monday.
Found on ARM randconfig builds.

diff --git a/drivers/gpu/drm/nouveau/nouveau_debugfs.h 
b/drivers/gpu/drm/nouveau/nouveau_debugfs.h
index 52c7161297d7..b8c03ff5bf05 100644
--- a/drivers/gpu/drm/nouveau/nouveau_debugfs.h
+++ b/drivers/gpu/drm/nouveau/nouveau_debugfs.h
@@ -34,13 +34,13 @@ nouveau_drm_debugfs_cleanup(struct drm_minor *minor)
 }

 static inline int
-nouveau_debugfs_init(struct nouveau_drm *)
+nouveau_debugfs_init(struct nouveau_drm *drm)
 {
return 0;
 }

 static inline void
-nouveau_debugfs_fini(struct nouveau_drm *)
+nouveau_debugfs_fini(struct nouveau_drm *drm)
 {
 }

[RFC/PATCH] drm/rockchip: don't wait for vblank if fb hasn't changed

[John Keeping]

On Wed, 13 Jan 2016 15:23:20 +0100, Daniel Vetter wrote:

> On Wed, Jan 13, 2016 at 12:53:34PM +, John Keeping wrote:
> > As commented in drm_atomic_helper_wait_for_vblanks(), userspace
> > relies on cursor ioctls being unsynced.  Converting the rockchip
> > driver to atomic has significantly impacted cursor performance by
> > making every cursor update wait for vblank.
> > 
> > By skipping the vblank sync when the framebuffer has not changed
> > (as is done in drm_atomic_helper_wait_for_vblanks()) we can avoid
> > this for the common case of moving the cursor and only need to
> > delay the cursor ioctl when the cursor icon changes.
> > 
> > I originally inserted a check on legacy_cursor_update as well, but
> > that caused a storm of iommu page faults.  I didn't investigate the
> > cause of those since this change gives enough of a performance
> > improvement for my use case.
> > 
> > This is RFC because of that and because the framebuffer_changed()
> > function is copied from drm_atomic_helper.c as a quick way to test
> > the result.
> > 
> > Signed-off-by: John Keeping 
> > ---
> >  drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 27
> > +-- 1 file changed, 25 insertions(+), 2
> > deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> > b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c index f784488..8fd9821
> > 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> > @@ -177,8 +177,28 @@ static void
> > rockchip_crtc_wait_for_update(struct drm_crtc *crtc)
> > crtc_funcs->wait_for_update(crtc); }
> >  
> > +static bool framebuffer_changed(struct drm_device *dev,
> > +   struct drm_atomic_state *old_state,
> > +   struct drm_crtc *crtc)
> > +{
> > +   struct drm_plane *plane;
> > +   struct drm_plane_state *old_plane_state;
> > +   int i;
> > +
> > +   for_each_plane_in_state(old_state, plane, old_plane_state,
> > i) {
> > +   if (plane->state->crtc != crtc &&
> > +   old_plane_state->crtc != crtc)
> > +   continue;
> > +
> > +   if (plane->state->fb != old_plane_state->fb)
> > +   return true;
> > +   }
> > +
> > +   return false;
> > +}  
> 
> Please don't hand-roll logic that affects semantics like this. Instead
> please use drm_atomic_helper_wait_for_vblanks(), which should do this
> correctly for you.
> 
> If that's not the case then we need to improve the generic helper, or
> figure out what's different with rockhip.

According to commit 63ebb9f (drm/rockchip: Convert to support atomic
API) it's because rockchip doesn't have a hardware vblank counter.

I'm not entirely clear on why this prevents the use of
drm_atomic_helper_wait_for_vblanks().

> > +
> >  static void
> > -rockchip_atomic_wait_for_complete(struct drm_atomic_state
> > *old_state) +rockchip_atomic_wait_for_complete(struct drm_device
> > *dev, struct drm_atomic_state *old_state) {
> > struct drm_crtc_state *old_crtc_state;
> > struct drm_crtc *crtc;
> > @@ -194,6 +214,9 @@ rockchip_atomic_wait_for_complete(struct
> > drm_atomic_state *old_state) if (!crtc->state->active)
> > continue;
> >  
> > +   if (!framebuffer_changed(dev, old_state, crtc))
> > +   continue;
> > +
> > ret = drm_crtc_vblank_get(crtc);
> > if (ret != 0)
> > continue;
> > @@ -241,7 +264,7 @@ rockchip_atomic_commit_complete(struct
> > rockchip_atomic_commit *commit) 
> > drm_atomic_helper_commit_planes(dev, state, true);
> >  
> > -   rockchip_atomic_wait_for_complete(state);
> > +   rockchip_atomic_wait_for_complete(dev, state);
> >  
> > drm_atomic_helper_cleanup_planes(dev, state);
> >  
> > -- 
> > 2.7.0.rc3.140.g520a093
> > 
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel  
> 

[pull] radeon and amdgpu drm-next-4.5

[Alex Deucher]

Hi Dave,

A few more misc things for radeon and amdgpu for 4.5:
- TTM fixes for imported buffers
- amdgpu fixes to avoid -ENOMEM in CS ioctl
- CZ UVD and VCE clock force options for debugging video issues
- A couple of ACP prerequisites
- Misc fixes

The following changes since commit 57b4f7e68720e8a9f5e6e9e61446ec36822e4c57:

  Merge branch 'linux-4.5' of git://github.com/skeggsb/linux into drm-next 
(2016-01-11 11:48:18 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-next-4.5

for you to fetch changes up to d8e0cae645504a787b05abfb91afee8cd7fa1701:

  drm/amdgpu: validate duplicates first (2016-01-13 12:22:59 -0500)


Alex Deucher (6):
  drm/amdgpu/cgs: add an interface to access PCI resources
  drm/amdgpu: add irq domain support
  drm/amdgpu/cz: add code to enable forcing UVD clocks
  drm/amdgpu/cz: add code to enable forcing VCE clocks
  drm/amdgpu/cz: force uvd clocks when sclks are forced
  drm/amdgpu/cz: force vce clocks when sclks are forced

Christian König (5):
  drm/ttm: fix adding foreign BOs to the LRU during init v2
  drm/ttm: fix adding foreign BOs to the swap LRU
  drm/ttm: add ttm_bo_move_to_lru_tail function v2
  drm/amdgpu: move VM page tables to the LRU end on CS v2
  drm/amdgpu: validate duplicates first

Chunming Zhou (1):
  drm/amdgpu: fix lost sync_to if scheduler is enabled.

Geliang Tang (2):
  drm/amdgpu: use kobj_to_dev()
  drm/radeon: use kobj_to_dev()

Rex Zhu (1):
  drm/amd/powerplay: fix static checker warning for return meaningless 
value.

 drivers/gpu/drm/amd/amdgpu/amdgpu.h|   2 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c|  36 +++
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c |  11 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c| 108 +++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_irq.h|   9 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c |   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c   |   5 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c |  27 ++
 drivers/gpu/drm/amd/amdgpu/cik_ih.c|   6 +
 drivers/gpu/drm/amd/amdgpu/cz_dpm.c| 273 -
 drivers/gpu/drm/amd/amdgpu/cz_dpm.h|   2 +
 drivers/gpu/drm/amd/amdgpu/cz_ih.c |   7 +
 drivers/gpu/drm/amd/amdgpu/iceland_ih.c|   7 +
 drivers/gpu/drm/amd/amdgpu/tonga_ih.c  |   7 +
 drivers/gpu/drm/amd/include/cgs_common.h   |  34 +++
 .../gpu/drm/amd/powerplay/smumgr/tonga_smumgr.c|   6 +-
 drivers/gpu/drm/radeon/radeon_pm.c |   2 +-
 drivers/gpu/drm/ttm/ttm_bo.c   |  31 ++-
 include/drm/ttm/ttm_bo_api.h   |  10 +
 19 files changed, 564 insertions(+), 21 deletions(-)

[patch] drm/nouveau/pci: reversed condition in nvkm_pcie_set_link()

[Karol Herbst]

> Karol Herbst  hat am 13. Januar 2016 um 13:30
> geschrieben:
> 
> Hi Dan,
> 
> yeah I also catched that. I assume something went wrong in the review process,
> because I am sure I didn't added that "pci ||" check myself ;) but who knows,
> maybe I was tired working with ben on that, cause it was like 4am while doing

maybe I chose the wrong words here. Seems like I still need to improve my
english here and there ;)

I meant that I was literally tired, cause it was 4am, not that I was tired
because of ben. Just clarify that before somebody thinks I am a mean person.

> the last polishing steps.
> 
> nvm, I already send a patch to the nouveau ML:
> http://lists.freedesktop.org/archives/nouveau/2016-January/023772.html
> 
> I just tried to poke ben the last day like several times, but he didn't seem
> to
> be there yesterday
> 
> > Dan Carpenter  hat am 13. Januar 2016 um 13:21
> > geschrieben:
> > 
> > The condition is reversed so this function is a no-op.
> > 
> > Fixes: bcc19d9bf5cd ('drm/nouveau/pci: implement generic code for pcie speed
> > change')
> > Signed-off-by: Dan Carpenter 
> > 
> > diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/pci/pcie.c
> > b/drivers/gpu/drm/nouveau/nvkm/subdev/pci/pcie.c
> > index b32954f..d71e5db 100644
> > --- a/drivers/gpu/drm/nouveau/nvkm/subdev/pci/pcie.c
> > +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pci/pcie.c
> > @@ -119,7 +119,7 @@ nvkm_pcie_set_link(struct nvkm_pci *pci, enum
> > nvkm_pcie_speed speed, u8 width)
> > struct pci_bus *pbus;
> > int ret;
> > 
> > - if (pci || !pci_is_pcie(pci->pdev))
> > + if (!pci || !pci_is_pcie(pci->pdev))
> > return 0;
> > pbus = pci->pdev->bus;
> 
> >

[PATCH] drm: Do not set connector->encoder in drivers

[Daniel Vetter]

On Wed, Jan 13, 2016 at 11:47:20AM +, Liviu Dudau wrote:
> On Tue, Nov 17, 2015 at 10:29:56AM +, Liviu Dudau wrote:
> > On Mon, Nov 16, 2015 at 06:19:53PM +0100, Thierry Reding wrote:
> > > From: Thierry Reding 
> > > 
> > > An encoder is associated with a connector by the DRM core as a result of
> > > setting up a configuration. Drivers using the atomic or legacy helpers
> > > should never set up this link, even if it is a static one.
> > > 
> > > While at it, try to catch this kind of error in the future by adding a
> > > WARN_ON() in drm_mode_connector_attach_encoder(). Note that this doesn't
> > > cover all the cases, since drivers could set this up after attaching.
> > > Drivers that use the atomic helpers will get a warning later on, though,
> > > so hopefully the two combined cover enough to help people avoid this in
> > > the future.
> > > 
> > > Cc: Russell King 
> > > Cc: Philipp Zabel 
> > > Cc: Laurent Pinchart 
> > > Cc: Liviu Dudau 
> > > Cc: Mark yao 
> > > Signed-off-by: Thierry Reding 
> > > ---
> > > Daniel, I didn't add your Reviewed-by because I included two more fixes
> > > for the same errors in the i.MX and shmobile drivers. But I suspect that
> > > you will want to pick this up into drm/misc anyway.
> 
> Thierry,
> 
> I've been using your patch for weeks and I found it very useful as it removes
> an ugly WARN() in the kernel boot log. However, it doesn't seem to have been
> included in any upstream trees. Do you have any plans to push it to Daniel?

There's been a serious lack of acks from driver maintainers, that's why I
stalled on this one. Applied to drm-misc now.
-Daniel

> 
> Best regards,
> Liviu
> 
> 
> > > 
> > >  drivers/gpu/drm/bridge/dw_hdmi.c  |  2 --
> > >  drivers/gpu/drm/drm_crtc.c| 14 ++
> > >  drivers/gpu/drm/i2c/tda998x_drv.c |  1 -
> > >  drivers/gpu/drm/imx/parallel-display.c|  2 --
> > >  drivers/gpu/drm/shmobile/shmob_drm_crtc.c |  2 --
> > >  5 files changed, 14 insertions(+), 7 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c 
> > > b/drivers/gpu/drm/bridge/dw_hdmi.c
> > > index 56de9f1c95fc..ffef392ccc13 100644
> > > --- a/drivers/gpu/drm/bridge/dw_hdmi.c
> > > +++ b/drivers/gpu/drm/bridge/dw_hdmi.c
> > > @@ -1648,8 +1648,6 @@ static int dw_hdmi_register(struct drm_device *drm, 
> > > struct dw_hdmi *hdmi)
> > >   drm_connector_init(drm, >connector, _hdmi_connector_funcs,
> > >  DRM_MODE_CONNECTOR_HDMIA);
> > >  
> > > - hdmi->connector.encoder = encoder;
> > > -
> > >   drm_mode_connector_attach_encoder(>connector, encoder);
> > >  
> > >   return 0;
> > > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > > index 24c5434abd1c..bc0693c63ca4 100644
> > > --- a/drivers/gpu/drm/drm_crtc.c
> > > +++ b/drivers/gpu/drm/drm_crtc.c
> > > @@ -4983,6 +4983,20 @@ int drm_mode_connector_attach_encoder(struct 
> > > drm_connector *connector,
> > >  {
> > >   int i;
> > >  
> > > + /*
> > > +  * In the past, drivers have attempted to model the static association
> > > +  * of connector to encoder in simple connector/encoder devices using a
> > > +  * direct assignment of connector->encoder = encoder. This connection
> > > +  * is a logical one and the responsibility of the core, so drivers are
> > > +  * expected not to mess with this.
> > > +  *
> > > +  * Note that the error return should've been enough here, but a large
> > > +  * majority of drivers ignores the return value, so add in a big WARN
> > > +  * to get people's attention.
> > > +  */
> > > + if (WARN_ON(connector->encoder))
> > > + return -EINVAL;
> > > +
> > >   for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++) {
> > >   if (connector->encoder_ids[i] == 0) {
> > >   connector->encoder_ids[i] = encoder->base.id;
> > > diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
> > > b/drivers/gpu/drm/i2c/tda998x_drv.c
> > > index 896b6aaf8c4d..8b0a402190eb 100644
> > > --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> > > +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> > > @@ -1453,7 +1453,6 @@ static int tda998x_bind(struct device *dev, struct 
> > > device *master, void *data)
> > >   if (ret)
> > >   goto err_sysfs;
> > >  
> > > - priv->connector.encoder = >encoder;
> > >   drm_mode_connector_attach_encoder(>connector, >encoder);
> > 
> > For the drivers/gpu/drm/drm_crtc.c and drivers/gpu/drm/i2c/tda998x_drv.c 
> > combination, together
> > with an atomic modesetting enabled KMS driver (HDLCD):
> > 
> > Tested-by: Liviu Dudau 
> > 
> > Many thanks,
> > Liviu
> > 
> > >  
> > >   return 0;
> > > diff --git a/drivers/gpu/drm/imx/parallel-display.c 
> > > b/drivers/gpu/drm/imx/parallel-display.c
> > > index b4deb9cf9d71..57b78226e392 100644
> > > --- a/drivers/gpu/drm/imx/parallel-display.c
> > > +++ b/drivers/gpu/drm/imx/parallel-display.c
> > > @@ -200,8 +200,6 @@ static int imx_pd_register(struct drm_device *drm,
> > >  
> > >   

[patch] drm/nouveau/pci: reversed condition in nvkm_pcie_set_link()

[Karol Herbst]

Hi Dan,

yeah I also catched that. I assume something went wrong in the review process,
because I am sure I didn't added that "pci ||" check myself ;) but who knows,
maybe I was tired working with ben on that, cause it was like 4am while doing
the last polishing steps.

nvm, I already send a patch to the nouveau ML:
http://lists.freedesktop.org/archives/nouveau/2016-January/023772.html

I just tried to poke ben the last day like several times, but he didn't seem to
be there yesterday

> Dan Carpenter  hat am 13. Januar 2016 um 13:21
> geschrieben:
> 
> The condition is reversed so this function is a no-op.
> 
> Fixes: bcc19d9bf5cd ('drm/nouveau/pci: implement generic code for pcie speed
> change')
> Signed-off-by: Dan Carpenter 
> 
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/pci/pcie.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/pci/pcie.c
> index b32954f..d71e5db 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/pci/pcie.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pci/pcie.c
> @@ -119,7 +119,7 @@ nvkm_pcie_set_link(struct nvkm_pci *pci, enum
> nvkm_pcie_speed speed, u8 width)
>  struct pci_bus *pbus;
>  int ret;
> 
> - if (pci || !pci_is_pcie(pci->pdev))
> + if (!pci || !pci_is_pcie(pci->pdev))
>  return 0;
>  pbus = pci->pdev->bus;

>

[PATCH 20/22] drm/tilcdc: Nuke preclose hook

[Tomi Valkeinen]

On 12/01/16 17:12, Daniel Vetter wrote:

> Different approaches to the same problem:
> 
> - omap just unlinks the event from fpriv and still process it normally.
>   But then before sending it out it checks whether the fpriv is still
>   there or not and either sends it, or deletes the event directly. This
>   way the vblank_put is always called from the worker/irq handler as part
>   of the event processing.
> 
>   This is the same approach I implemented in core with this series.
> 
> - tilcdc (and most other drivers) entirely destroy the event in the
>   preclose hook, which means they must also release any other resources
>   acquired as part of that event. Therefore they have the vblank_put here.
>   But the vblank_put is obviously also in the normal event processing
>   paths, so with the new approach of only unlinking it we can handle this
>   without any special cases in the driver.
> 
> I hope this explains what's going on. Since you're about driver maintainer
> no. 3 with the same question: Can you pls review the kerneldoc and make
> sure it explains this well? I tried to improve it already a bit after
> Laurent's/Thomas' questions.

Ok, makes sense. I think the kernel doc is fine.

I wasn't able to test tilcdc, as it seems to crash on drm-next at the
moment... Need to debug that first.

 Tomi

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160113/24f365a9/attachment.sig>

[GIT PULL][drm-next] drm: Add support for ARM HDLCD

[Liviu Dudau]

Hi David,

This is the DRM part of the ARM HDLCD driver. It has been included in
linux-next for about a week and includes the Kconfig patches submitted
by Arnd Bergman last week. Please pull into drm-next.

Best regards,
Liviu

The following changes since commit 8a0d560f3e651808ae0a3d9ab9fe476e59de132b:

  drm/amdgpu/powerplay: include asm/div64.h for do_div() (2016-01-12 09:29:25 
+1000)

are available in the git repository at:

  git://linux-arm.org/linux-ld for-upstream/hdlcd

for you to fetch changes up to 499ad2fdbe562f9e40c390d70690e26e2941ef27:

  MAINTAINERS: Add Liviu Dudau as maintainer for ARM HDLCD driver. (2016-01-13 
12:28:54 +)


Liviu Dudau (3):
  drm: arm: Add DT bindings documentation for HDLCD driver.
  drm: Add support for ARM's HDLCD controller.
  MAINTAINERS: Add Liviu Dudau as maintainer for ARM HDLCD driver.

 .../devicetree/bindings/display/arm,hdlcd.txt  |  79 +++
 MAINTAINERS|   6 +
 drivers/gpu/drm/Kconfig|   2 +
 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/arm/Kconfig|  27 +
 drivers/gpu/drm/arm/Makefile   |   2 +
 drivers/gpu/drm/arm/hdlcd_crtc.c   | 327 
 drivers/gpu/drm/arm/hdlcd_drv.c| 567 +
 drivers/gpu/drm/arm/hdlcd_drv.h|  42 ++
 drivers/gpu/drm/arm/hdlcd_regs.h   |  87 
 10 files changed, 1140 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/arm,hdlcd.txt
 create mode 100644 drivers/gpu/drm/arm/Kconfig
 create mode 100644 drivers/gpu/drm/arm/Makefile
 create mode 100644 drivers/gpu/drm/arm/hdlcd_crtc.c
 create mode 100644 drivers/gpu/drm/arm/hdlcd_drv.c
 create mode 100644 drivers/gpu/drm/arm/hdlcd_drv.h
 create mode 100644 drivers/gpu/drm/arm/hdlcd_regs.h

[PATCH 16/22] drm/omap: Nuke close hooks

[Tomi Valkeinen]

Hi Daniel,

On 11/01/16 23:41, Daniel Vetter wrote:

> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
> b/drivers/gpu/drm/omapdrm/omap_drv.c
> index dfafdb602ad2..603a65498b40 100644
> --- a/drivers/gpu/drm/omapdrm/omap_drv.c
> +++ b/drivers/gpu/drm/omapdrm/omap_drv.c
> @@ -175,17 +175,6 @@ static int omap_atomic_commit(struct drm_device *dev,
>   priv->commit.pending |= commit->crtcs;
>   spin_unlock(>commit.lock);
>  
> - /* Keep track of all CRTC events to unlink them in preclose(). */
> - spin_lock_irqsave(>event_lock, flags);
> - for (i = 0; i < dev->mode_config.num_crtc; ++i) {
> - struct drm_crtc_state *cstate = state->crtc_states[i];
> -
> - if (cstate && cstate->event)
> - list_add_tail(>event->base.link,
> -   >commit.events);
> - }
> - spin_unlock_irqrestore(>event_lock, flags);
> -
>   /* Swap the state, this is the point of no return. */
>   drm_atomic_helper_swap_state(dev, state);

'flags' local needs to be removed from omap_atomic_commit, otherwise:

drivers/gpu/drm/omapdrm/omap_drv.c:145:16: error: unused variable 'flags'

 Tomi

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160113/381b7dd1/attachment.sig>

[RFC/PATCH] drm/rockchip: don't wait for vblank if fb hasn't changed

[John Keeping]

As commented in drm_atomic_helper_wait_for_vblanks(), userspace relies
on cursor ioctls being unsynced.  Converting the rockchip driver to
atomic has significantly impacted cursor performance by making every
cursor update wait for vblank.

By skipping the vblank sync when the framebuffer has not changed (as is
done in drm_atomic_helper_wait_for_vblanks()) we can avoid this for the
common case of moving the cursor and only need to delay the cursor ioctl
when the cursor icon changes.

I originally inserted a check on legacy_cursor_update as well, but that
caused a storm of iommu page faults.  I didn't investigate the cause of
those since this change gives enough of a performance improvement for my
use case.

This is RFC because of that and because the framebuffer_changed()
function is copied from drm_atomic_helper.c as a quick way to test the
result.

Signed-off-by: John Keeping 
---
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 27 +--
 1 file changed, 25 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
index f784488..8fd9821 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
@@ -177,8 +177,28 @@ static void rockchip_crtc_wait_for_update(struct drm_crtc 
*crtc)
crtc_funcs->wait_for_update(crtc);
 }

+static bool framebuffer_changed(struct drm_device *dev,
+   struct drm_atomic_state *old_state,
+   struct drm_crtc *crtc)
+{
+   struct drm_plane *plane;
+   struct drm_plane_state *old_plane_state;
+   int i;
+
+   for_each_plane_in_state(old_state, plane, old_plane_state, i) {
+   if (plane->state->crtc != crtc &&
+   old_plane_state->crtc != crtc)
+   continue;
+
+   if (plane->state->fb != old_plane_state->fb)
+   return true;
+   }
+
+   return false;
+}
+
 static void
-rockchip_atomic_wait_for_complete(struct drm_atomic_state *old_state)
+rockchip_atomic_wait_for_complete(struct drm_device *dev, struct 
drm_atomic_state *old_state)
 {
struct drm_crtc_state *old_crtc_state;
struct drm_crtc *crtc;
@@ -194,6 +214,9 @@ rockchip_atomic_wait_for_complete(struct drm_atomic_state 
*old_state)
if (!crtc->state->active)
continue;

+   if (!framebuffer_changed(dev, old_state, crtc))
+   continue;
+
ret = drm_crtc_vblank_get(crtc);
if (ret != 0)
continue;
@@ -241,7 +264,7 @@ rockchip_atomic_commit_complete(struct 
rockchip_atomic_commit *commit)

drm_atomic_helper_commit_planes(dev, state, true);

-   rockchip_atomic_wait_for_complete(state);
+   rockchip_atomic_wait_for_complete(dev, state);

drm_atomic_helper_cleanup_planes(dev, state);

-- 
2.7.0.rc3.140.g520a093

[PATCH v9 14/14] drm/mediatek: Add interface to allocate Mediatek GEM buffer.

[Philipp Zabel]

Am Dienstag, den 12.01.2016, 23:40 +0100 schrieb Daniel Vetter:
> On Tue, Jan 12, 2016 at 11:02 PM, Rob Herring  wrote:
> > On Tue, Jan 12, 2016 at 9:15 AM, Philipp Zabel  
> > wrote:
> >> From: CK Hu 
> >>
> >> Add an interface to allocate Mediatek GEM buffers, allow the IOCTLs
> >> to be used by render nodes.
> >> This patch also sets the RENDER driver feature.
> >
> > But it should not a be render node unless it has a GPU AFAIK. Then
> > again, I still don't understand the madness of every driver defining
> > their own buffer ioctls either. The only line remotely h/w specific
> > here is mtk_drm_gem_create call.
> 
> Support gem_create/mmap_offet alone is indeed pointless without some
> real support for gpu workloads. For plain display drivers the dumb
> buffer api, plus prime/dma-buf import should be plenty enough.
> 
> The usual reason for doing this is some blob driver for opengl that
> can't be open-source, which is a big no-go for upstream.
> 
> Imo best to just rip this out, consider it nacked without full-blown
> userspace and whatever else is needing these buffers.
> -Daniel

Yes, I'll drop this one.

thanks
Philipp

[PATCH v7 2/2] drm/bridge: Add I2C based driver for ps8640 bridge

[Archit Taneja]

Hi Jitao,

On 01/13/2016 07:48 AM, Jitao Shi wrote:
> This patch adds drm_bridge driver for parade DSI to eDP bridge chip.
>
> Signed-off-by: Jitao Shi 
> ---
> Changes since v6:
>   - Add ps8640 firmware update function
>   - Change i2c to i2c_transfer from i2c_master_recv/i2c_master_send
>   - Add comments for each page client

I'd commented on the v6 patch set here:

https://lkml.org/lkml/2015/12/15/62

I wanted to know how the bridge driver was transferring parameters
to the dsi host. Is that something that you are hardcoding on both
the dsi host and ps8640 drivers for now?

My intention of asking this is to know if there are other users
that can take advantage of this patch set:

https://lkml.org/lkml/2015/12/10/283

Thanks,
Archit

> ---
>   drivers/gpu/drm/bridge/Kconfig |   10 +
>   drivers/gpu/drm/bridge/Makefile|1 +
>   drivers/gpu/drm/bridge/parade-ps8640.c | 1106 
> 
>   3 files changed, 1117 insertions(+)
>   create mode 100644 drivers/gpu/drm/bridge/parade-ps8640.c
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 639..dcfdbc9 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -41,4 +41,14 @@ config DRM_PARADE_PS8622
>   ---help---
> Parade eDP-LVDS bridge chip driver.
>
> +config DRM_PARADE_PS8640
> + tristate "Parade PS8640 MIPI DSI to eDP Converter"
> + depends on OF
> + select DRM_KMS_HELPER
> + select DRM_PANEL
> + ---help---
> +   Choose this option if you have PS8640 for display
> +   The PS8640 is a high-performance and low-power
> +   MIPI DSI to eDP converter
> +
>   endmenu
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index d4e28be..272e3c01 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -4,3 +4,4 @@ obj-$(CONFIG_DRM_DW_HDMI) += dw_hdmi.o
>   obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw_hdmi-ahb-audio.o
>   obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
>   obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
> +obj-$(CONFIG_DRM_PARADE_PS8640) += parade-ps8640.o
> diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c 
> b/drivers/gpu/drm/bridge/parade-ps8640.c
> new file mode 100644
> index 000..a18d8e9
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/parade-ps8640.c
> @@ -0,0 +1,1106 @@
> +/*
> + * Copyright (c) 2014 MediaTek Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define PAGE2_SPI_CFG3   0x82
> +#define I2C_TO_SPI_RESET 0x20
> +#define PAGE2_ROMADD_BYTE1   0x8e
> +#define PAGE2_ROMADD_BYTE2   0x8f
> +#define PAGE2_SWSPI_WDATA0x90
> +#define PAGE2_SWSPI_RDATA0x91
> +#define PAGE2_SWSPI_LEN  0x92
> +#define PAGE2_SWSPI_CTL  0x93
> +#define TRIGGER_NO_READBACK  0x05
> +#define TRIGGER_READBACK 0x01
> +#define PAGE2_SPI_STATUS 0x9e
> +#define PAGE2_GPIO_L 0xa6
> +#define PAGE2_GPIO_H 0xa7
> +#define PS_GPIO9 BIT(1)
> +#define PAGE2_IROM_CTRL  0xb0
> +#define IROM_ENABLE  0xc0
> +#define IROM_DISABLE 0x80
> +#define PAGE2_SW_REST0xbc
> +#define PAGE2_ENCTLSPI_WR0xda
> +#define PAGE2_I2C_BYPASS 0xea
> +#define I2C_BYPASS_EN0xd0
> +
> +#define PAGE3_SET_ADD0xfe
> +#define PAGE3_SET_VAL0xff
> +#define VDO_CTL_ADD  0x13
> +#define VDO_DIS  0x18
> +#define VDO_EN   0x1c
> +
> +#define PAGE4_REV_L  0xf0
> +#define PAGE4_REV_H  0xf1
> +#define PAGE4_CHIP_L 0xf2
> +#define PAGE4_CHIP_H 0xf3
> +
> +/* Firmware */
> +#define SPI_MAX_RETRY_CNT8
> +#define PS_FW_NAME   "ps864x_fw.bin"
> +
> +#define FW_CHIP_ID_OFFSET0
> +#define FW_VERSION_OFFSET2
> +
> +#define bridge_to_ps8640(e)  container_of(e, struct ps8640, bridge)
> +#define connector_to_ps8640(e)   container_of(e, struct ps8640, 
> connector)
> +
> +struct ps8640_info {
> + u8 family_id;
> + u8 variant_id;
> + u16 version;
> +};
> +
> +struct ps8640 {
> + struct drm_connector connector;
> + struct drm_bridge bridge;
> + struct i2c_client *page[8];
> + struct ps8640_driver_data *driver_data;
> + 

[PATCH] x86: Add an explicit barrier() to clflushopt()

[Chris Wilson]

On Tue, Jan 12, 2016 at 06:06:34PM -0800, Linus Torvalds wrote:
> On Tue, Jan 12, 2016 at 4:55 PM, Chris Wilson  
> wrote:
> >
> > The double clflush() remains a mystery.
> 
> Actually, I think it's explainable.
> 
> It's wrong to do the clflush *after* the GPU has done the write, which
> seems to be what you are doing.
> 
> Why?
> 
> If the GPU really isn't cache coherent, what can happen is:
> 
>  - the CPU has the line cached
> 
>  - the GPU writes the data
> 
>  - you do the clflushopt to invalidate the cacheline
> 
>  - you expect to see the GPU data.
> 
> Right?
> 
> Wrong. The above is complete crap.
> 
> Why?
> 
> Very simple reason: the CPU may have had the cacheline dirty at some
> level in its caches, so when you did the clflushopt, it didn't just
> invalidate the CPU cacheline, it wrote it back to memory. And in the
> process over-wrote the data that the GPU had written.

Forgive me for being dense, but if we overwrite the GPU data in the
backing struct page with the cacheline from the CPU, how do we see the
results from the GPU afterwards?

> Now you can say "but the CPU never wrote to the cacheline, so it's not
> dirty in the CPU caches". That may or may not be trie. The CPU may
> have written to it quite a long time ago.

What we do is we clflush the entire object after it is written to by the
CPU (including newly allocated objects from shmemfs, or pages being
returned to us by shmemfs) before any operation on that object by the
GPU. We have to so that the GPU sees the correct page contents.
(If I change the clflush of the written objects to a wbinvd, that's not
sufficient for the tests to pass.)

We do not clflush the object after we read the backing pages on the CPU
before the next GPU operation, even if it is a GPU write. This leaves us
with clean but stale cachelines. Should. That's why we then
clflush_cache_range() prior to the next read on the object, it is
intended to be a pure cache line invalidation.

If we clflush the entire object between every CPU read back and the *next*
GPU operation, it fails. If we clflush the object before every GPU write
to it, it passes. And to refresh, we always clflush after a CPU write.

I am reasonably confident that any cachelines we dirty (or inherited)
are flushed. What you are suggesting is that there are dirty cachelines
regardless. I am also reasonably confident that even if we clflush the
entire object after touching it before the GPU write, and clflush the
individual cachelines again after the GPU write, we see the errors.

I haven't found the hole yet, or been convincingly able to explain the
differences between gen.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH 00/10] libdrm amdgpu patches

[Christian König]

Am 13.01.2016 um 12:15 schrieb Marek Olšák:
> On Wed, Jan 13, 2016 at 11:43 AM, Christian König
>  wrote:
>> Am 12.01.2016 um 22:30 schrieb Alex Deucher:
>>> On Tue, Jan 12, 2016 at 4:23 PM, Marek Olšák  wrote:
 Hi,

 These are libdrm_amdgpu patches harvested from an internal branch.

 The first patch is a revert I had to make to fix the build. Yeah,
 sequence_mutex should be renamed to a more appropriate name. That can be
 done as a follow-up.

 One notable change is the addition of DRM_IOCTL_AMDGPU_WAIT_FENCES. I
 hope the kernel contains (or will contain) the changes too, so that I don't
 push something that doesn't exist in the kernel.
>>> We haven't pushed DRM_IOCTL_AMDGPU_WAIT_FENCES upstream yet so I would
>>> hold off on any changes that depend on that.
>>
>> Yeah, and do we really have patch #9 in our internal branch without an
>> Review? Cause that one breaks the API.
> It doesn't break the API, because the API is added by this series in
> an earlier patch. The API would be broken if it was changed between
> two libdrm versions.

Ah, in this case please squash the two patches together for upstreaming.

Regards,
Christian.

>
> Marek

[PATCH 05/10] amdgpu: Cast pointer to uintptr_t for assignment to unsigned integer

[Michel Dänzer]

On 13.01.2016 06:23, Marek Olšák wrote:
> From: Michel Dänzer 
> 
>   CC   amdgpu_bo.lo
> ../../amdgpu/amdgpu_bo.c: In function 'amdgpu_create_bo_from_user_mem':
> ../../amdgpu/amdgpu_bo.c:539:12: warning: assignment makes integer from 
> pointer without a cast [-Wint-conversion]
>   args.addr = cpu;
> ^
> 
> Reviewed-by: Jammy Zhou 
> ---
>  amdgpu/amdgpu_bo.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/amdgpu/amdgpu_bo.c b/amdgpu/amdgpu_bo.c
> index 61db58c..2ae1c18 100644
> --- a/amdgpu/amdgpu_bo.c
> +++ b/amdgpu/amdgpu_bo.c
> @@ -538,7 +538,7 @@ int amdgpu_create_bo_from_user_mem(amdgpu_device_handle 
> dev,
>   struct amdgpu_bo *bo;
>   struct drm_amdgpu_gem_userptr args;
>  
> - args.addr = cpu;
> + args.addr = (uintptr_t)cpu;
>   args.flags = AMDGPU_GEM_USERPTR_ANONONLY | AMDGPU_GEM_USERPTR_REGISTER;
>   args.size = size;
>   r = drmCommandWriteRead(dev->fd, DRM_AMDGPU_GEM_USERPTR,
> 

This patch should be squashed into patch 3.


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

[PATCH 5/5] drm/amdgpu: validate duplicates first

[Alex Deucher]

On Mon, Jan 11, 2016 at 9:35 AM, Christian König
 wrote:
> From: Christian König 
>
> Most VM BOs end up in the duplicates list, validate it
> first make -ENOMEM less likely.
>
> Signed-off-by: Christian König 
> Reviewed-by: Chunming Zhou 

Applied the series.  thanks!

Alex

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> index 1fffc33..6f89f8e 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> @@ -421,11 +421,11 @@ static int amdgpu_cs_parser_relocs(struct 
> amdgpu_cs_parser *p)
>
> amdgpu_vm_get_pt_bos(>vm, );
>
> -   r = amdgpu_cs_list_validate(p->adev, >vm, >validated);
> +   r = amdgpu_cs_list_validate(p->adev, >vm, );
> if (r)
> goto error_validate;
>
> -   r = amdgpu_cs_list_validate(p->adev, >vm, );
> +   r = amdgpu_cs_list_validate(p->adev, >vm, >validated);
>
>  error_validate:
> if (r) {
> --
> 2.5.0
>

[PATCH 5/5] drm/radeon: use kobj_to_dev()

[Alex Deucher]

On Wed, Jan 13, 2016 at 9:48 AM, Geliang Tang  wrote:
> Use kobj_to_dev() instead of open-coding it.
>
> Signed-off-by: Geliang Tang 

Applied patches 4 and 5.  thanks!

Alex

> ---
>  drivers/gpu/drm/radeon/radeon_pm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_pm.c 
> b/drivers/gpu/drm/radeon/radeon_pm.c
> index 59abebd..460c8f2 100644
> --- a/drivers/gpu/drm/radeon/radeon_pm.c
> +++ b/drivers/gpu/drm/radeon/radeon_pm.c
> @@ -713,7 +713,7 @@ static struct attribute *hwmon_attributes[] = {
>  static umode_t hwmon_attributes_visible(struct kobject *kobj,
> struct attribute *attr, int index)
>  {
> -   struct device *dev = container_of(kobj, struct device, kobj);
> +   struct device *dev = kobj_to_dev(kobj);
> struct radeon_device *rdev = dev_get_drvdata(dev);
> umode_t effective_mode = attr->mode;
>
> --
> 2.5.0
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 00/10] libdrm amdgpu patches

[Marek Olšák]

On Wed, Jan 13, 2016 at 11:43 AM, Christian König
 wrote:
> Am 12.01.2016 um 22:30 schrieb Alex Deucher:
>>
>> On Tue, Jan 12, 2016 at 4:23 PM, Marek Olšák  wrote:
>>>
>>> Hi,
>>>
>>> These are libdrm_amdgpu patches harvested from an internal branch.
>>>
>>> The first patch is a revert I had to make to fix the build. Yeah,
>>> sequence_mutex should be renamed to a more appropriate name. That can be
>>> done as a follow-up.
>>>
>>> One notable change is the addition of DRM_IOCTL_AMDGPU_WAIT_FENCES. I
>>> hope the kernel contains (or will contain) the changes too, so that I don't
>>> push something that doesn't exist in the kernel.
>>
>> We haven't pushed DRM_IOCTL_AMDGPU_WAIT_FENCES upstream yet so I would
>> hold off on any changes that depend on that.
>
>
> Yeah, and do we really have patch #9 in our internal branch without an
> Review? Cause that one breaks the API.

It doesn't break the API, because the API is added by this series in
an earlier patch. The API would be broken if it was changed between
two libdrm versions.

Marek

[PATCH] drm/omap: Nuke close hooks

[Daniel Vetter]

Again since the core takes care of this we can remove them. While at
it also remove the postclose hook, it's empty.

v2: Laurent pointed me at even more code to delete.

v3: Remove unused flags (Tomi).

Cc: Laurent Pinchart 
Cc: Tomi Valkeinen 
Acked-by: Daniel Stone 
Reviewed-by: Alex Deucher 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/omapdrm/omap_crtc.c | 13 +---
 drivers/gpu/drm/omapdrm/omap_drv.c  | 42 -
 drivers/gpu/drm/omapdrm/omap_drv.h  |  1 -
 3 files changed, 1 insertion(+), 55 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 2ed0754ed19e..d38fcbcc43a8 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -269,18 +269,7 @@ static void omap_crtc_complete_page_flip(struct drm_crtc 
*crtc)
return;

spin_lock_irqsave(>event_lock, flags);
-
-   list_del(>base.link);
-
-   /*
-* Queue the event for delivery if it's still linked to a file
-* handle, otherwise just destroy it.
-*/
-   if (event->base.file_priv)
-   drm_crtc_send_vblank_event(crtc, event);
-   else
-   event->base.destroy(>base);
-
+   drm_crtc_send_vblank_event(crtc, event);
spin_unlock_irqrestore(>event_lock, flags);
 }

diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
b/drivers/gpu/drm/omapdrm/omap_drv.c
index dfafdb602ad2..33370f42e4d7 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -142,7 +142,6 @@ static int omap_atomic_commit(struct drm_device *dev,
 {
struct omap_drm_private *priv = dev->dev_private;
struct omap_atomic_state_commit *commit;
-   unsigned long flags;
unsigned int i;
int ret;

@@ -175,17 +174,6 @@ static int omap_atomic_commit(struct drm_device *dev,
priv->commit.pending |= commit->crtcs;
spin_unlock(>commit.lock);

-   /* Keep track of all CRTC events to unlink them in preclose(). */
-   spin_lock_irqsave(>event_lock, flags);
-   for (i = 0; i < dev->mode_config.num_crtc; ++i) {
-   struct drm_crtc_state *cstate = state->crtc_states[i];
-
-   if (cstate && cstate->event)
-   list_add_tail(>event->base.link,
- >commit.events);
-   }
-   spin_unlock_irqrestore(>event_lock, flags);
-
/* Swap the state, this is the point of no return. */
drm_atomic_helper_swap_state(dev, state);

@@ -673,7 +661,6 @@ static int dev_load(struct drm_device *dev, unsigned long 
flags)
priv->wq = alloc_ordered_workqueue("omapdrm", 0);
init_waitqueue_head(>commit.wait);
spin_lock_init(>commit.lock);
-   INIT_LIST_HEAD(>commit.events);

spin_lock_init(>list_lock);
INIT_LIST_HEAD(>obj_list);
@@ -787,33 +774,6 @@ static void dev_lastclose(struct drm_device *dev)
}
 }

-static void dev_preclose(struct drm_device *dev, struct drm_file *file)
-{
-   struct omap_drm_private *priv = dev->dev_private;
-   struct drm_pending_event *event;
-   unsigned long flags;
-
-   DBG("preclose: dev=%p", dev);
-
-   /*
-* Unlink all pending CRTC events to make sure they won't be queued up
-* by a pending asynchronous commit.
-*/
-   spin_lock_irqsave(>event_lock, flags);
-   list_for_each_entry(event, >commit.events, link) {
-   if (event->file_priv == file) {
-   file->event_space += event->event->length;
-   event->file_priv = NULL;
-   }
-   }
-   spin_unlock_irqrestore(>event_lock, flags);
-}
-
-static void dev_postclose(struct drm_device *dev, struct drm_file *file)
-{
-   DBG("postclose: dev=%p, file=%p", dev, file);
-}
-
 static const struct vm_operations_struct omap_gem_vm_ops = {
.fault = omap_gem_fault,
.open = drm_gem_vm_open,
@@ -838,8 +798,6 @@ static struct drm_driver omap_drm_driver = {
.unload = dev_unload,
.open = dev_open,
.lastclose = dev_lastclose,
-   .preclose = dev_preclose,
-   .postclose = dev_postclose,
.set_busid = drm_platform_set_busid,
.get_vblank_counter = drm_vblank_no_hw_counter,
.enable_vblank = omap_irq_enable_vblank,
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.h 
b/drivers/gpu/drm/omapdrm/omap_drv.h
index 9e0030731c37..c23cbe6fe9e4 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.h
+++ b/drivers/gpu/drm/omapdrm/omap_drv.h
@@ -106,7 +106,6 @@ struct omap_drm_private {

/* atomic commit */
struct {
-   struct list_head events;
wait_queue_head_t wait;
u32 pending;
spinlock_t lock;/* Protects commit.pending */
-- 
2.7.0.rc3

[PATCH] drm: Do not set connector->encoder in drivers

[Liviu Dudau]

On Tue, Nov 17, 2015 at 10:29:56AM +, Liviu Dudau wrote:
> On Mon, Nov 16, 2015 at 06:19:53PM +0100, Thierry Reding wrote:
> > From: Thierry Reding 
> > 
> > An encoder is associated with a connector by the DRM core as a result of
> > setting up a configuration. Drivers using the atomic or legacy helpers
> > should never set up this link, even if it is a static one.
> > 
> > While at it, try to catch this kind of error in the future by adding a
> > WARN_ON() in drm_mode_connector_attach_encoder(). Note that this doesn't
> > cover all the cases, since drivers could set this up after attaching.
> > Drivers that use the atomic helpers will get a warning later on, though,
> > so hopefully the two combined cover enough to help people avoid this in
> > the future.
> > 
> > Cc: Russell King 
> > Cc: Philipp Zabel 
> > Cc: Laurent Pinchart 
> > Cc: Liviu Dudau 
> > Cc: Mark yao 
> > Signed-off-by: Thierry Reding 
> > ---
> > Daniel, I didn't add your Reviewed-by because I included two more fixes
> > for the same errors in the i.MX and shmobile drivers. But I suspect that
> > you will want to pick this up into drm/misc anyway.

Thierry,

I've been using your patch for weeks and I found it very useful as it removes
an ugly WARN() in the kernel boot log. However, it doesn't seem to have been
included in any upstream trees. Do you have any plans to push it to Daniel?

Best regards,
Liviu


> > 
> >  drivers/gpu/drm/bridge/dw_hdmi.c  |  2 --
> >  drivers/gpu/drm/drm_crtc.c| 14 ++
> >  drivers/gpu/drm/i2c/tda998x_drv.c |  1 -
> >  drivers/gpu/drm/imx/parallel-display.c|  2 --
> >  drivers/gpu/drm/shmobile/shmob_drm_crtc.c |  2 --
> >  5 files changed, 14 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c 
> > b/drivers/gpu/drm/bridge/dw_hdmi.c
> > index 56de9f1c95fc..ffef392ccc13 100644
> > --- a/drivers/gpu/drm/bridge/dw_hdmi.c
> > +++ b/drivers/gpu/drm/bridge/dw_hdmi.c
> > @@ -1648,8 +1648,6 @@ static int dw_hdmi_register(struct drm_device *drm, 
> > struct dw_hdmi *hdmi)
> > drm_connector_init(drm, >connector, _hdmi_connector_funcs,
> >DRM_MODE_CONNECTOR_HDMIA);
> >  
> > -   hdmi->connector.encoder = encoder;
> > -
> > drm_mode_connector_attach_encoder(>connector, encoder);
> >  
> > return 0;
> > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > index 24c5434abd1c..bc0693c63ca4 100644
> > --- a/drivers/gpu/drm/drm_crtc.c
> > +++ b/drivers/gpu/drm/drm_crtc.c
> > @@ -4983,6 +4983,20 @@ int drm_mode_connector_attach_encoder(struct 
> > drm_connector *connector,
> >  {
> > int i;
> >  
> > +   /*
> > +* In the past, drivers have attempted to model the static association
> > +* of connector to encoder in simple connector/encoder devices using a
> > +* direct assignment of connector->encoder = encoder. This connection
> > +* is a logical one and the responsibility of the core, so drivers are
> > +* expected not to mess with this.
> > +*
> > +* Note that the error return should've been enough here, but a large
> > +* majority of drivers ignores the return value, so add in a big WARN
> > +* to get people's attention.
> > +*/
> > +   if (WARN_ON(connector->encoder))
> > +   return -EINVAL;
> > +
> > for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++) {
> > if (connector->encoder_ids[i] == 0) {
> > connector->encoder_ids[i] = encoder->base.id;
> > diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
> > b/drivers/gpu/drm/i2c/tda998x_drv.c
> > index 896b6aaf8c4d..8b0a402190eb 100644
> > --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> > +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> > @@ -1453,7 +1453,6 @@ static int tda998x_bind(struct device *dev, struct 
> > device *master, void *data)
> > if (ret)
> > goto err_sysfs;
> >  
> > -   priv->connector.encoder = >encoder;
> > drm_mode_connector_attach_encoder(>connector, >encoder);
> 
> For the drivers/gpu/drm/drm_crtc.c and drivers/gpu/drm/i2c/tda998x_drv.c 
> combination, together
> with an atomic modesetting enabled KMS driver (HDLCD):
> 
> Tested-by: Liviu Dudau 
> 
> Many thanks,
> Liviu
> 
> >  
> > return 0;
> > diff --git a/drivers/gpu/drm/imx/parallel-display.c 
> > b/drivers/gpu/drm/imx/parallel-display.c
> > index b4deb9cf9d71..57b78226e392 100644
> > --- a/drivers/gpu/drm/imx/parallel-display.c
> > +++ b/drivers/gpu/drm/imx/parallel-display.c
> > @@ -200,8 +200,6 @@ static int imx_pd_register(struct drm_device *drm,
> >  
> > drm_mode_connector_attach_encoder(>connector, >encoder);
> >  
> > -   imxpd->connector.encoder = >encoder;
> > -
> > return 0;
> >  }
> >  
> > diff --git a/drivers/gpu/drm/shmobile/shmob_drm_crtc.c 
> > b/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
> > index e9272b0a8592..cb72b35d85d1 100644
> > --- a/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
> > +++ 

[PATCH 00/10] libdrm amdgpu patches

[Christian König]

Am 12.01.2016 um 22:30 schrieb Alex Deucher:
> On Tue, Jan 12, 2016 at 4:23 PM, Marek Olšák  wrote:
>> Hi,
>>
>> These are libdrm_amdgpu patches harvested from an internal branch.
>>
>> The first patch is a revert I had to make to fix the build. Yeah, 
>> sequence_mutex should be renamed to a more appropriate name. That can be 
>> done as a follow-up.
>>
>> One notable change is the addition of DRM_IOCTL_AMDGPU_WAIT_FENCES. I hope 
>> the kernel contains (or will contain) the changes too, so that I don't push 
>> something that doesn't exist in the kernel.
> We haven't pushed DRM_IOCTL_AMDGPU_WAIT_FENCES upstream yet so I would
> hold off on any changes that depend on that.

Yeah, and do we really have patch #9 in our internal branch without an 
Review? Cause that one breaks the API.

Christian.

>
> Alex
>
>> Please let me know if these are okay to push.
>>
>> Thanks,
>>
>> Chunming Zhou (3):
>>amdgpu: add semaphore support
>>tests/amdgpu: add semaphore test
>>amdgpu: validate user memory for userptr
>>
>> Junwei Zhang (3):
>>amdgpu: add the interface of waiting multiple fences
>>amdgpu/tests: add multi-fence test in base test
>>amdgpu: list each entry safely for sw semaphore when submit ib
>>
>> Marek Olšák (1):
>>Revert "amdgpu: remove sequence mutex"
>>
>> Michel Dänzer (1):
>>amdgpu: Cast pointer to uintptr_t for assignment to unsigned integer
>>
>> monk.liu (2):
>>amdgpu: drop address patching logics
>>amdgpu: cs_wait_fences now can return the first signaled fence index
>>
>>   amdgpu/amdgpu.h|  88 +
>>   amdgpu/amdgpu_bo.c |  14 ++-
>>   amdgpu/amdgpu_cs.c | 253 
>> --
>>   amdgpu/amdgpu_internal.h   |  15 +++
>>   include/drm/amdgpu_drm.h   |  28 +
>>   tests/amdgpu/basic_tests.c | 233 
>> 
>>   6 files changed, 616 insertions(+), 15 deletions(-)
>>
>> Marek
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/nouveau/device: ensure ret is initialized to zero

[Colin King]

From: Colin Ian King 

nvkm_udevice_time does not initialize ret and this is used
in the macro nvif_unpack(). Intializing it to zero allows the
compiler to optimize out the ret == -ENOSYS check in the macro.

Issue found by static analysis with cppcheck:
[drivers/gpu/drm/nouveau/nvkm/engine/device/user.c:136]:
   (error) Uninitialized variable: ret

Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/nouveau/nvkm/engine/device/user.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/user.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/device/user.c
index 1ae48f2..93e0e53 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/device/user.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/user.c
@@ -127,7 +127,7 @@ nvkm_udevice_time(struct nvkm_udevice *udev, void *data, 
u32 size)
union {
struct nv_device_time_v0 v0;
} *args = data;
-   int ret;
+   int ret = 0;

if (nvif_unpack(args->v0, 0, 0, false)) {
args->v0.time = nvkm_timer_read(device->timer);
-- 
2.7.0.rc3

[PATCH] x86: Add an explicit barrier() to clflushopt()

[Linus Torvalds]

On Wed, Jan 13, 2016 at 4:34 AM, Chris Wilson  
wrote:
>
> Forgive me for being dense, but if we overwrite the GPU data in the
> backing struct page with the cacheline from the CPU, how do we see the
> results from the GPU afterwards?

Hmm. Good point.

Ok, all the symptoms just say "writes from GPU are delayed and out of order".

Do you have access to the GPU hardware people?

I thought that all the modern Intel GPU's are cache-coherent. If this
is some castrated chip where coherence is removed (perhaps because it
is not working? perhaps config setting?) maybe it needs some extra
ghardware setting to make the GPU "flush" operation actually do
something. In a cache-coherent model, a flush could/should be a noop,
so maybe the hardware is set for that kind of "flush does nothing"
behavior.

Or maybe the GPU is just a buggy pile of crap.

Linus

[PATCH v7 2/2] drm/bridge: Add I2C based driver for ps8640 bridge

[Jitao Shi]

This patch adds drm_bridge driver for parade DSI to eDP bridge chip.

Signed-off-by: Jitao Shi 
---
Changes since v6:
 - Add ps8640 firmware update function
 - Change i2c to i2c_transfer from i2c_master_recv/i2c_master_send
 - Add comments for each page client
---
 drivers/gpu/drm/bridge/Kconfig |   10 +
 drivers/gpu/drm/bridge/Makefile|1 +
 drivers/gpu/drm/bridge/parade-ps8640.c | 1106 
 3 files changed, 1117 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/parade-ps8640.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 639..dcfdbc9 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -41,4 +41,14 @@ config DRM_PARADE_PS8622
---help---
  Parade eDP-LVDS bridge chip driver.

+config DRM_PARADE_PS8640
+   tristate "Parade PS8640 MIPI DSI to eDP Converter"
+   depends on OF
+   select DRM_KMS_HELPER
+   select DRM_PANEL
+   ---help---
+ Choose this option if you have PS8640 for display
+ The PS8640 is a high-performance and low-power
+ MIPI DSI to eDP converter
+
 endmenu
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index d4e28be..272e3c01 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -4,3 +4,4 @@ obj-$(CONFIG_DRM_DW_HDMI) += dw_hdmi.o
 obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw_hdmi-ahb-audio.o
 obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
 obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
+obj-$(CONFIG_DRM_PARADE_PS8640) += parade-ps8640.o
diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c 
b/drivers/gpu/drm/bridge/parade-ps8640.c
new file mode 100644
index 000..a18d8e9
--- /dev/null
+++ b/drivers/gpu/drm/bridge/parade-ps8640.c
@@ -0,0 +1,1106 @@
+/*
+ * Copyright (c) 2014 MediaTek Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#define PAGE2_SPI_CFG3 0x82
+#define I2C_TO_SPI_RESET   0x20
+#define PAGE2_ROMADD_BYTE1 0x8e
+#define PAGE2_ROMADD_BYTE2 0x8f
+#define PAGE2_SWSPI_WDATA  0x90
+#define PAGE2_SWSPI_RDATA  0x91
+#define PAGE2_SWSPI_LEN0x92
+#define PAGE2_SWSPI_CTL0x93
+#define TRIGGER_NO_READBACK0x05
+#define TRIGGER_READBACK   0x01
+#define PAGE2_SPI_STATUS   0x9e
+#define PAGE2_GPIO_L   0xa6
+#define PAGE2_GPIO_H   0xa7
+#define PS_GPIO9   BIT(1)
+#define PAGE2_IROM_CTRL0xb0
+#define IROM_ENABLE0xc0
+#define IROM_DISABLE   0x80
+#define PAGE2_SW_REST  0xbc
+#define PAGE2_ENCTLSPI_WR  0xda
+#define PAGE2_I2C_BYPASS   0xea
+#define I2C_BYPASS_EN  0xd0
+
+#define PAGE3_SET_ADD  0xfe
+#define PAGE3_SET_VAL  0xff
+#define VDO_CTL_ADD0x13
+#define VDO_DIS0x18
+#define VDO_EN 0x1c
+
+#define PAGE4_REV_L0xf0
+#define PAGE4_REV_H0xf1
+#define PAGE4_CHIP_L   0xf2
+#define PAGE4_CHIP_H   0xf3
+
+/* Firmware */
+#define SPI_MAX_RETRY_CNT  8
+#define PS_FW_NAME "ps864x_fw.bin"
+
+#define FW_CHIP_ID_OFFSET  0
+#define FW_VERSION_OFFSET  2
+
+#define bridge_to_ps8640(e)container_of(e, struct ps8640, bridge)
+#define connector_to_ps8640(e) container_of(e, struct ps8640, connector)
+
+struct ps8640_info {
+   u8 family_id;
+   u8 variant_id;
+   u16 version;
+};
+
+struct ps8640 {
+   struct drm_connector connector;
+   struct drm_bridge bridge;
+   struct i2c_client *page[8];
+   struct ps8640_driver_data *driver_data;
+   struct regulator *pwr_1v2_supply;
+   struct regulator *pwr_3v3_supply;
+   struct drm_panel *panel;
+   struct gpio_desc *gpio_rst_n;
+   struct gpio_desc *gpio_slp_n;
+   struct gpio_desc *gpio_mode_sel_n;
+   bool enabled;
+
+   /* firmware file name */
+   bool in_fw_update;
+   char *fw_file;
+   struct ps8640_info info;
+};
+
+static const u8 enc_ctrl_code[6] = {0xaa, 0x55, 0x50, 0x41, 0x52, 0x44};
+
+static int ps8640_regr(struct i2c_client *client, u8 reg, u8 *data,
+  u16 data_len)
+{
+   int ret;
+
+   struct i2c_msg msgs[] = {
+   {
+.addr = client->addr,
+.flags = 0,
+

[PATCH v7 1/2] Documentation: bridge: Add documentation for ps8640 DT properties

[Jitao Shi]

Add documentation for DT properties supported by
ps8640 DSI-eDP converter.

Signed-off-by: Jitao Shi 
Acked-by: Rob Herring 
Reviewed-by: Philipp Zabel 
---
Change since v6:
 - No change
---
 .../devicetree/bindings/display/bridge/ps8640.txt  |   43 
 1 file changed, 43 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/bridge/ps8640.txt

diff --git a/Documentation/devicetree/bindings/display/bridge/ps8640.txt 
b/Documentation/devicetree/bindings/display/bridge/ps8640.txt
new file mode 100644
index 000..a3e0971
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ps8640.txt
@@ -0,0 +1,43 @@
+ps8640-bridge bindings
+
+Required properties:
+   - compatible: "parade,ps8640"
+   - reg: first page address of the bridge.
+   - sleep-gpios: OF device-tree gpio specification for PD_ pin.
+   - reset-gpios: OF device-tree gpio specification for reset pin.
+   - mode-sel-gpios: OF device-tree gpio specification for mode-sel pin.
+   - vdd12-supply: OF device-tree regulator specification for 1.2V power.
+   - vdd33-supply: OF device-tree regulator specification for 3.3V power.
+   - ports: The device node can contain video interface port nodes per
+the video-interfaces bind[1]. For port at 0,set the reg = <0> 
as
+ps8640 dsi in and port at 1,set the reg = <1> as ps8640 eDP 
out.
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+   edp-bridge at 18 {
+   compatible = "parade,ps8640";
+   reg = <0x18>;
+   sleep-gpios = < 116 GPIO_ACTIVE_HIGH>;
+   reset-gpios = < 115 GPIO_ACTIVE_HIGH>;
+   mode-sel-gpios = < 92 GPIO_ACTIVE_HIGH>;
+   vdd12-supply = <_fixed_1v2>;
+   vdd33-supply = <_vgp2_reg>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   port at 0 {
+   reg = <0>;
+   ps8640_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   port at 1 {
+   reg = <1>;
+   ps8640_out: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+   };
-- 
1.7.9.5

[PATCH v3 1/3] drm: add generic zpos property

[Benjamin Gaignard]

 +
> for_each_plane_in_state(state, plane, plane_state, i) {
> const struct drm_plane_helper_funcs *funcs;
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 62fa95fa5471..54a21e7c1ca5 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -5880,6 +5880,59 @@ struct drm_property
> *drm_mode_create_rotation_property(struct drm_device *dev,
>  EXPORT_SYMBOL(drm_mode_create_rotation_property);
>
>  /**
> + * drm_mode_create_zpos_property - create muttable zpos property
> + * @dev: DRM device
> + *
> + * This function initializes generic muttable zpos property and enables
> support
> + * for it in drm core. Drivers can then attach this property to planes to
> enable
> + * support for configurable planes arrangement during blending operation.
> + * Drivers can also use drm_atomic_helper_normalize_zpos() function to
> calculate
> + * drm_plane_state->normalized_zpos values.
> + *
> + * Returns:
> + * Zero on success, negative errno on failure.
> + */
> +int drm_mode_create_zpos_property(struct drm_device *dev)
> +{
> +   struct drm_property *prop;
> +
> +   prop = drm_property_create_range(dev, 0, "zpos", 0, 255);
> +   if (!prop)
> +   return -ENOMEM;
> +
> +   dev->mode_config.zpos_property = prop;
> +   return 0;
> +}
> +EXPORT_SYMBOL(drm_mode_create_zpos_property);
> +
> +/**
> + * drm_plane_create_zpos_property - create immuttable zpos property
> + * @dev: DRM device
> + *
> + * This function initializes generic immuttable zpos property and enables
> + * support for it in drm core. Using this property driver lets userspace
> + * to get the arrangement of the planes for blending operation and
> notifies
> + * it that the hardware (or driver) doesn't support changing of the
> planes'
> + * order.
> + *
> + * Returns:
> + * Zero on success, negative errno on failure.
> + */
> +int drm_mode_create_zpos_immutable_property(struct drm_device *dev)
> +{
> +   struct drm_property *prop;
> +
> +   prop = drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE,
> "zpos",
> +0, 255);
> +   if (!prop)
> +   return -ENOMEM;
> +
> +   dev->mode_config.zpos_immutable_property = prop;
> +   return 0;
> +}
> +EXPORT_SYMBOL(drm_mode_create_zpos_immutable_property);
> +
> +/**
>   * DOC: Tile group
>   *
>   * Tile groups are used to represent tiled monitors with a unique
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 3b040b355472..0607ad2ce918 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -305,6 +305,7 @@ struct drm_plane_helper_funcs;
>   * @mode_changed: crtc_state->mode or crtc_state->enable has been changed
>   * @active_changed: crtc_state->active has been toggled.
>   * @connectors_changed: connectors to this crtc have been updated
> + * @zpos_changed: zpos values of planes on this crtc have been updated
>   * @plane_mask: bitmask of (1 << drm_plane_index(plane)) of attached
> planes
>   * @last_vblank_count: for helpers and drivers to capture the vblank of
> the
>   * update to ensure framebuffer cleanup isn't done too early
> @@ -331,6 +332,7 @@ struct drm_crtc_state {
> bool mode_changed : 1;
> bool active_changed : 1;
> bool connectors_changed : 1;
> +   bool zpos_changed : 1;
>
> /* attached planes bitmask:
>  * WARNING: transitional helpers do not maintain plane_mask so
> @@ -1243,6 +1245,9 @@ struct drm_connector {
>   * plane (in 16.16)
>   * @src_w: width of visible portion of plane (in 16.16)
>   * @src_h: height of visible portion of plane (in 16.16)
> + * @zpos: priority of the given plane on crtc (optional)
> + * @normalized_zpos: normalized value of zpos: uniqe, range from 0 to
> + * (number of planes - 1) for given crtc
>   * @state: backpointer to global drm_atomic_state
>   */
>  struct drm_plane_state {
> @@ -1263,6 +1268,10 @@ struct drm_plane_state {
> /* Plane rotation */
> unsigned int rotation;
>
> +   /* Plane zpos */
> +   unsigned int zpos;
> +   unsigned int normalized_zpos;
> +
> struct drm_atomic_state *state;
>  };
>
> @@ -2083,6 +2092,8 @@ struct drm_mode_config {
> struct drm_property *tile_property;
> struct drm_property *plane_type_property;
> struct drm_property *rotation_property;
> +   struct drm_property *zpos_property;
> +   struct drm_property *zpos_immutable_property;
> struct drm_property *prop_src_x;
> struct drm_property *prop_src_y;
> struct drm_property *prop_src_w;
> @@ -2484,6 +2495,9 @@ extern struct drm_property
> *drm_mode_create_rotation_property(struct drm_device
>  extern unsigned int drm_rotation_simplify(unsigned int rotation,
>   unsigned int
> supported_rotations);
>
> +extern int drm_mode_create_zpos_property(struct drm_device *dev);
> +extern int drm_mode_create_zpos_immutable_property(struct drm_device
> *dev);
> +
>  /* Helpers */
>
>  static inline struct drm_plane *drm_plane_find(struct drm_device *dev,
> --
> 1.9.2
>
>


-- 

Benjamin Gaignard

Graphic Working Group

Linaro.org <http://www.linaro.org/> *│ *Open source software for ARM SoCs

Follow *Linaro: *Facebook <http://www.facebook.com/pages/Linaro> | Twitter
<http://twitter.com/#!/linaroorg> | Blog
<http://www.linaro.org/linaro-blog/>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160113/bbf7f5e1/attachment-0001.html>

[PATCH 2/5] drm: sti: add atomic get/set properties for planes

[Daniel Vetter]

On Wed, Jan 13, 2016 at 09:53:32AM +0100, Benjamin Gaignard wrote:
> Hi,
> 
> I have been able to implement zpos in generic way using Marek's patches (v3)
> so I'm abandon this patch and wait to see Marek's patches merged to propose
> a new one.

Imo Marek's patch is pretty much ready. Feel like doing a full review on
it?
-Daniel

> 
> Regards,
> Benjamin
> 
> 2016-01-07 15:47 GMT+01:00 Daniel Vetter :
> 
> > On Thu, Jan 07, 2016 at 03:05:02PM +0100, Benjamin Gaignard wrote:
> > > zpos property isn't new in sti driver only the atomic set/get functions
> > are
> > > new.
> > > Without those functions atomictest failed to discover any of the other
> > > atomic planes properties.
> > >
> > > I agree with you, zpos should be generic and I could work with Marek for
> > > that
> > > but if this patch isn't merge sti atomic modesetting support will be
> > > limited to primary planes...
> >
> > These two hooks should be optional. The only downside of not adding them
> > is that zpos property can't be read, everything else should still work ...
> >
> > And yeah everyone added zpos without a hole lot of thought about
> > cross-driver consistency, which is not great. Now everyone gets to clean
> > things up again I'd say.
> > -Daniel
> >
> > >
> > > Benjamin
> > >
> > >
> > > 2016-01-07 14:50 GMT+01:00 Daniel Vetter :
> > >
> > > > On Thu, Jan 07, 2016 at 02:30:38PM +0100, Benjamin Gaignard wrote:
> > > > > Without those function zpos property isn't displayed in atomic mode.
> > > > >
> > > > > Signed-off-by: Benjamin Gaignard 
> > > >
> > > > Oh, another iteration of a driver-private zpos property. This _really_
> > > > should be generic, with some consistent cross-driver semantics. Marek
> > from
> > > > samsung has started with a patch series for that.
> > > >
> > > > Can you please work together with him, and rebase the sti zpos support
> > on
> > > > top of his work? And hold of this patch for now meanwhile?
> > > >
> > > > Also adding Marek.
> > > >
> > > > Thanks, Daniel
> > > >
> > > > > ---
> > > > >  drivers/gpu/drm/sti/sti_plane.c | 40
> > > > 
> > > > >  1 file changed, 40 insertions(+)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/sti/sti_plane.c
> > > > b/drivers/gpu/drm/sti/sti_plane.c
> > > > > index 2e5c751..e739c5a 100644
> > > > > --- a/drivers/gpu/drm/sti/sti_plane.c
> > > > > +++ b/drivers/gpu/drm/sti/sti_plane.c
> > > > > @@ -69,6 +69,44 @@ static int sti_plane_set_property(struct drm_plane
> > > > *drm_plane,
> > > > >   return -EINVAL;
> > > > >  }
> > > > >
> > > > > +static int sti_plane_atomic_set_property(struct drm_plane
> > *drm_plane,
> > > > > +  struct drm_plane_state *state,
> > > > > +  struct drm_property *property,
> > > > > +  uint64_t val)
> > > > > +{
> > > > > + struct drm_device *dev = drm_plane->dev;
> > > > > + struct sti_private *private = dev->dev_private;
> > > > > + struct sti_plane *plane = to_sti_plane(drm_plane);
> > > > > +
> > > > > + DRM_DEBUG_DRIVER("\n");
> > > > > +
> > > > > + if (property == private->plane_zorder_property) {
> > > > > + plane->zorder = val;
> > > > > + return 0;
> > > > > + }
> > > > > +
> > > > > + return -EINVAL;
> > > > > +}
> > > > > +
> > > > > +static int sti_plane_atomic_get_property(struct drm_plane
> > *drm_plane,
> > > > > +  const struct drm_plane_state
> > > > *state,
> > > > > +  struct drm_property *property,
> > > > > +  uint64_t *val)
> > > > > +{
> > > > > + struct drm_device *dev = drm_plane->dev;
> > > > > + struct sti_private *private = dev->dev_private;
> > > > > + struct sti_plane *plane = to_sti_plane(drm_plane);
> > > > > +
> > > > > + DRM_DEBUG_DRIVER("\n");
> > > > > +
> > > > > + if (property == private->plane_zorder_property) {
> > > > > + *val = plane->zorder;
> > > > > + return 0;
> > > > > + }
> > > > > +
> > > > > + return -EINVAL;
> > > > > +}
> > > > > +
> > > > >  static void sti_plane_attach_zorder_property(struct drm_plane
> > > > *drm_plane)
> > > > >  {
> > > > >   struct drm_device *dev = drm_plane->dev;
> > > > > @@ -116,4 +154,6 @@ struct drm_plane_funcs sti_plane_helpers_funcs =
> > {
> > > > >   .reset = drm_atomic_helper_plane_reset,
> > > > >   .atomic_duplicate_state =
> > drm_atomic_helper_plane_duplicate_state,
> > > > >   .atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
> > > > > + .atomic_set_property = sti_plane_atomic_set_property,
> > > > > + .atomic_get_property = sti_plane_atomic_get_property,
> > > > >  };
> > > > > --
> > > > > 1.9.1
> > > > >
> > > > > ___
> > > > > dri-devel mailing list
> > > > > dri-devel at lists.freedesktop.org
> > > > > 

[PATCH 2/5] drm: sti: add atomic get/set properties for planes

[Benjamin Gaignard]

> > @@ -116,4 +154,6 @@ struct drm_plane_funcs sti_plane_helpers_funcs =
> {
> > > >   .reset = drm_atomic_helper_plane_reset,
> > > >   .atomic_duplicate_state =
> drm_atomic_helper_plane_duplicate_state,
> > > >   .atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
> > > > + .atomic_set_property = sti_plane_atomic_set_property,
> > > > + .atomic_get_property = sti_plane_atomic_get_property,
> > > >  };
> > > > --
> > > > 1.9.1
> > > >
> > > > ___
> > > > dri-devel mailing list
> > > > dri-devel at lists.freedesktop.org
> > > > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> > >
> > > --
> > > Daniel Vetter
> > > Software Engineer, Intel Corporation
> > > http://blog.ffwll.ch
> > >
> >
> >
> >
> > --
> >
> > Benjamin Gaignard
> >
> > Graphic Working Group
> >
> > Linaro.org <http://www.linaro.org/> *│ *Open source software for ARM
> SoCs
> >
> > Follow *Linaro: *Facebook <http://www.facebook.com/pages/Linaro> |
> Twitter
> > <http://twitter.com/#!/linaroorg> | Blog
> > <http://www.linaro.org/linaro-blog/>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
>



-- 

Benjamin Gaignard

Graphic Working Group

Linaro.org <http://www.linaro.org/> *│ *Open source software for ARM SoCs

Follow *Linaro: *Facebook <http://www.facebook.com/pages/Linaro> | Twitter
<http://twitter.com/#!/linaroorg> | Blog
<http://www.linaro.org/linaro-blog/>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160113/d4478af8/attachment-0001.html>

[Bug 92858] AMD Radeon GPU Acceleration Disabled Under Kernels 4.2.x and later versions

[bugzilla-dae...@freedesktop.org]

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

--- Comment #18 from Michel Dänzer  ---
Darren, why did you resolve this report as invalid?

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

[Bug 93687] ppc64el:Gallium / clover fails to compile

[bugzilla-dae...@freedesktop.org]

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

--- Comment #3 from Timothy Pearson  ---
Since this is marked NOTOURBUG, is there somewhere I should be submitting a bug
report to get this fixed?  I'd really like to see OpenCL on the OpenPOWER
hardware without having to manually patch / build, and without having to get a
downstream patch into Debian / RHEL.

Thanks!

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

[Bug 93687] ppc64el:Gallium / clover fails to compile

[bugzilla-dae...@freedesktop.org]

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

Francisco Jerez  changed:

   What|Removed |Added

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

--- Comment #2 from Francisco Jerez  ---
The error is caused by the altivec.h system header (included on PPC systems by
Khronos' CL headers we cannot change) which redefines standard C++ keywords. 
You may be able to use the attached hack to work around the issue, sigh...

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

[Bug 93687] ppc64el:Gallium / clover fails to compile

[bugzilla-dae...@freedesktop.org]

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

Francisco Jerez  changed:

   What|Removed |Added

 CC||currojerez at riseup.net

--- Comment #1 from Francisco Jerez  ---
Created attachment 120997
  --> https://bugs.freedesktop.org/attachment.cgi?id=120997=edit
clover_workaround_altivec_madness.patch

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

[Bug 93687] ppc64el:Gallium / clover fails to compile

[bugzilla-dae...@freedesktop.org]

a-program.o
In file included from /usr/include/c++/5/map:60:0,
 from
../../../../../../src/gallium/state_trackers/clover/core/property.hpp:26,
 from
../../../../../../src/gallium/state_trackers/clover/api/util.hpp:30,
 from
../../../../../../src/gallium/state_trackers/clover/api/context.cpp:23:
/usr/include/c++/5/bits/stl_tree.h: In constructor 'std::_Rb_tree<_Key, _Val,
_KeyOfValue, _Compare, _Alloc>::_Rb_tree(std::_Rb_tree<_Key, _Val, _KeyOfValue,
_Compare, _Alloc>&&, std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
_Alloc>::_Node_allocator&&)':
/usr/include/c++/5/bits/stl_tree.h:1332:76: error: '__vector(4) __bool int' is
not a valid type for a template non-type parameter
   using __eq = integral_constant<bool, _Alloc_traits::_S_always_equal()>;
^
/usr/include/c++/5/bits/stl_tree.h:1334:25: error: there are no arguments to
'__eq' that depend on a template parameter, so a declaration of '__eq' must be
available [-fpermissive]
  _M_move_data(__x, __eq());
 ^
/usr/include/c++/5/bits/stl_tree.h:1334:25: note: (if you use '-fpermissive',
G++ will accept your code, but allowing the use of an undeclared name is
deprecated)

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

[PATCH] x86: Add an explicit barrier() to clflushopt()

[Chris Wilson]

On Tue, Jan 12, 2016 at 02:07:35PM -0800, Linus Torvalds wrote:
> On Tue, Jan 12, 2016 at 1:13 PM, Chris Wilson  
> wrote:
> > Indeed. So I replaced the post-clflush_cache_range() clflush() with a
> > udelay(10) instead, and the corruption vanished. Putting the udelay(10)
> > before the clflush_cache_range() does not fix the corruption.
> 
> Odd.
> 
> > passes, I'm inclined to point the finger at the mb() following the
> > clflush_cache_range().
> 
> We have an entirely unrelated discussion about the value of "mfence"
> as a memory barrier.
> 
> Mind trying to just make the memory barrier (in
> arch/x86/include/asm/barrier.h) be a locked op instead?

Replacing the following mb() in clflush_cache_range() with
"lock; addl $0,0(%%rsp)" gave no improvement. Neither did replacing all
mb(). Undoubtably the memory stream as seen by the CPU is serialised.
The concern then is back to the visibility of the stream from the external
device. Adding an uncached mmio read after the clflush_cache_range()
also works, but I'm not clear if this achieves anything other than
inserting a delay or if it is flushing some other write buffer in the
chipset. It is odd that is required after the clflush_cache_range() and
ineffective before. It is also odd that such a flush would be needed
multiple times after the GPU write.

The double clflush() remains a mystery.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[GIT PULL 2nd] exynos-drm-next

[inki....@samsung.com]

Hi Dave,

   This 2nd pull request includes the following,
   - add configurable plane support and relevant cleanups.
   - fixup kernel panic issue at drm releasing.
   - remove unnecessary codes.

   This has been delayed to resolve a critical issue - which incurrs
   a kernel panic when driver is released - and review it.

   Please, kindly let me know if there is any problem.

Thanks,
Inki Dae

The following changes since commit 8a0d560f3e651808ae0a3d9ab9fe476e59de132b:

  drm/amdgpu/powerplay: include asm/div64.h for do_div() (2016-01-12 09:29:25 
+1000)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git 
exynos-drm-next

for you to fetch changes up to c74d8eb5649386c2cfcd65cc960fd283ba876877:

  drm/exynos: fix kernel panic issue at drm releasing (2016-01-13 00:16:39 
+0900)


Inki Dae (2):
  drm/exynos: crtc: do not wait for the scanout completion
  drm/exynos: fix kernel panic issue at drm releasing

Marek Szyprowski (7):
  drm/exynos: rename zpos to index
  drm/exynos: make zpos property configurable
  drm/exynos: mixer: set window priority based on zpos
  drm/exynos: mixer: refactor layer setup
  drm/exynos: mixer: unify a check for video-processor window
  drm/exynos: crtc: rework atomic_{begin,flush}
  drm/exynos: mixer: properly update all planes on the same vblank event

Tobias Jakobi (2):
  drm/exynos: mixer: remove all static blending setup
  drm/exynos: mixer: also allow ARGB1555 and ARGB

 drivers/gpu/drm/exynos/exynos5433_drm_decon.c |   20 ++--
 drivers/gpu/drm/exynos/exynos7_drm_decon.c|   20 ++--
 drivers/gpu/drm/exynos/exynos_drm_crtc.c  |   69 +--
 drivers/gpu/drm/exynos/exynos_drm_crtc.h  |5 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.c   |5 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |   18 +--
 drivers/gpu/drm/exynos/exynos_drm_fb.c|3 -
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  |   20 ++--
 drivers/gpu/drm/exynos/exynos_drm_plane.c |   55 +++--
 drivers/gpu/drm/exynos/exynos_drm_plane.h |2 +-
 drivers/gpu/drm/exynos/exynos_drm_vidi.c  |2 +-
 drivers/gpu/drm/exynos/exynos_mixer.c |  155 -
 drivers/gpu/drm/exynos/regs-mixer.h   |4 +
 13 files changed, 235 insertions(+), 143 deletions(-)

RPM wakelock ref not held during HW access

[Sergey Senozhatsky]

Hello,

-mmots 4.4.0-mm1-dbg-00602-g776bd09


[ 5331.509087] WARNING: CPU: 0 PID: 359 at 
drivers/gpu/drm/i915/intel_drv.h:1446 gen6_read32+0x7b/0x253 [i915]()
[ 5331.509091] RPM wakelock ref not held during HW access
[ 5331.509093] Modules linked in:
[ 5331.509182] CPU: 0 PID: 359 Comm: Xorg Not tainted 
4.4.0-mm1-dbg-00602-g776bd09-dirty #34
[ 5331.509186]   88041bddfac0 811eb860 
88041bddfb08
[ 5331.509194]  88041bddfaf8 81040fc2 a05442a9 
88041aab
[ 5331.509200]  00064000 88041afcb001 0001 
88041bddfb60
[ 5331.509207] Call Trace:
[ 5331.509218]  [] dump_stack+0x4b/0x63
[ 5331.509227]  [] warn_slowpath_common+0x99/0xb2
[ 5331.509277]  [] ? gen6_read32+0x7b/0x253 [i915]
[ 5331.509283]  [] warn_slowpath_fmt+0x48/0x50
[ 5331.509331]  [] gen6_read32+0x7b/0x253 [i915]
[ 5331.509338]  [] ? mutex_unlock+0xe/0x10
[ 5331.509391]  [] intel_ddi_get_hw_state+0x5e/0x159 [i915]
[ 5331.509443]  [] intel_ddi_connector_get_hw_state+0x5c/0xdf 
[i915]
[ 5331.509494]  [] intel_atomic_commit+0x8e0/0x1250 [i915]
[ 5331.509528]  [] ? drm_atomic_check_only+0x293/0x564 [drm]
[ 5331.509558]  [] drm_atomic_commit+0x4d/0x52 [drm]
[ 5331.509572]  [] 
drm_atomic_helper_connector_dpms+0x116/0x17e [drm_kms_helper]
[ 5331.509599]  [] drm_mode_obj_set_property_ioctl+0xef/0x17a 
[drm]
[ 5331.509626]  [] 
drm_mode_connector_property_set_ioctl+0x30/0x32 [drm]
[ 5331.509642]  [] drm_ioctl+0x26d/0x3a8 [drm]
[ 5331.509668]  [] ? 
drm_mode_obj_set_property_ioctl+0x17a/0x17a [drm]
[ 5331.509675]  [] ? lock_acquire+0x101/0x188
[ 5331.509681]  [] ? __fget+0x5/0x19d
[ 5331.509685]  [] ? __lock_is_held+0x3c/0x57
[ 5331.509691]  [] vfs_ioctl+0x18/0x34
[ 5331.509695]  [] do_vfs_ioctl+0x572/0x5f1
[ 5331.509699]  [] ? __fget_light+0x62/0x71
[ 5331.509704]  [] SyS_ioctl+0x43/0x61
[ 5331.509711]  [] entry_SYSCALL_64_fastpath+0x12/0x6f
[ 5331.509715] ---[ end trace 70d4fd86a0395d92 ]---

-ss