[Bug 104193] [radeonsi] The Witcher 3 freezes the system with no attachments calls & transform feedback Wine patch

[bugzilla-daemon]

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

--- Comment #3 from Shmerl  ---
Tested it with Linux 4.15rc5 and new amdgpu.dc=1 (to enable new display code).
The freeze still happens.

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

[git pull] drm fixes for 4.15-rc6

[Dave Airlie]

Hi Linus,

Just dequeuing some fixes, I'm on holidays next week again, but I
think things should be fine.

Dave.

The following changes since commit 464e1d5f23cca236b930ef068c328a64cab78fb1:

  Linux 4.15-rc5 (2017-12-23 20:47:16 -0800)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.15-rc6

for you to fetch changes up to 03bfd4e19b935adb8be4f7342f13395fb7f11096:

  Merge tag 'drm-intel-fixes-2017-12-22-1' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2017-12-28
05:20:07 +1000)


nouveau and i915 regression fixes


Ben Skeggs (1):
  drm/nouveau: fix race when adding delayed work items

Dave Airlie (2):
  Merge branch 'linux-4.15' of git://github.com/skeggsb/linux into drm-fixes
  Merge tag 'drm-intel-fixes-2017-12-22-1' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes

Gabriel Krisman Bertazi (1):
  i915: Reject CCS modifiers for pipe C on Geminilake

Jani Nikula (1):
  Merge tag 'gvt-fixes-2017-12-21' of
https://github.com/intel/gvt-linux into drm-intel-fixes

Xiaolin Zhang (1):
  drm/i915/gvt: Fix pipe A enable as default for vgpu

 drivers/gpu/drm/i915/gvt/display.c| 5 +++--
 drivers/gpu/drm/i915/intel_display.c  | 2 +-
 drivers/gpu/drm/nouveau/nouveau_drm.c | 2 +-
 3 files changed, 5 insertions(+), 4 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104295] Launching counter strike global offensive fails after update from 17.2 to 17.3

[bugzilla-daemon]

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

--- Comment #6 from sleepyoh  ---
(In reply to Emil Velikov from comment #5)
> (In reply to sleepyoh from comment #4)
> > Running Arch, Had the same problem but is since today solved.
> > 
> > Today there was updates from mesa (17.3.0-2 -> 17.3.1-2) and xorg-server
> > (1.19.5-1 -> 1.19.6-2) wich solved this problem, working fine again.
> > 
> > https://bbs.archlinux.org/viewtopic.php?id=232925
> > 
> > I had problems for weeks, now working fine, resolved for me.
> 
> I fear your observation is unrelated - Mesa 17.3.1 includes commit
> 5ac9d91ee3d897016d54e970a977c3fbbbe2488e, which
>  a) is exclusive for Intel (Skylake or newer)
>  b) resolved a GPU lockup
> 
> While the issue here seems to be:
>  a) radeonsi hardware
>  b) program crash

Hm, well the only thing that's changed on my system from not working csgo to
working csgo was today's new mesa and xorg, only packages that got updated and
now it's working fine. Maybe xorg then, idk.

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

[Bug 101900] No HDMI HBR audio on Polaris (no TrueHD, no Atmos, no Neo:X, no HD Master audio) and static noise in sound when LPCM

[bugzilla-daemon]

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

--- Comment #19 from Andy Furniss  ---
(In reply to lethalwp from comment #14)
> Created attachment 135979 [details]
> recording of audio LPCM output from RX550 card

FWIW, for years "direct" alsa + hdmi on recent cards has had issues.

It can work if there is enough cpu i/o load. Not quite enough load can sound
like that, no where near enough load can sound like it's stuck.

Pulse or jack don't have the issue as they do things differently.

See -

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

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

[Bug 104306] Mesa 17.3 breaks Firefox and other Xwayland apps on AMD HD7750

[bugzilla-daemon]

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

Emil Velikov  changed:

   What|Removed |Added

 CC||breno...@gmail.com

--- Comment #8 from Emil Velikov  ---
*** Bug 104351 has been marked as a duplicate of this bug. ***

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

[Bug 104295] Launching counter strike global offensive fails after update from 17.2 to 17.3

[bugzilla-daemon]

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

--- Comment #5 from Emil Velikov  ---
(In reply to sleepyoh from comment #4)
> Running Arch, Had the same problem but is since today solved.
> 
> Today there was updates from mesa (17.3.0-2 -> 17.3.1-2) and xorg-server
> (1.19.5-1 -> 1.19.6-2) wich solved this problem, working fine again.
> 
> https://bbs.archlinux.org/viewtopic.php?id=232925
> 
> I had problems for weeks, now working fine, resolved for me.

I fear your observation is unrelated - Mesa 17.3.1 includes commit
5ac9d91ee3d897016d54e970a977c3fbbbe2488e, which
 a) is exclusive for Intel (Skylake or newer)
 b) resolved a GPU lockup

While the issue here seems to be:
 a) radeonsi hardware
 b) program crash

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

[Bug 104295] Launching counter strike global offensive fails after update from 17.2 to 17.3

[bugzilla-daemon]

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

--- Comment #4 from sleepyoh  ---
Running Arch, Had the same problem but is since today solved.

Today there was updates from mesa (17.3.0-2 -> 17.3.1-2) and xorg-server
(1.19.5-1 -> 1.19.6-2) wich solved this problem, working fine again.

https://bbs.archlinux.org/viewtopic.php?id=232925

I had problems for weeks, now working fine, resolved for me.

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

[PATCH v3] backlight: tdo24m: fix the spi cs between transfers

[Robert Jarzmik]

Currently the LCD display (TD035S) on the cm-x300 platform is broken and
remains blank.

The TD0245S specification requires that the chipselect is toggled
between commands sent to the panel. This was also the purpose of the
former patch of commit f64dcac0b124 ("backlight: tdo24m: ensure chip
select changes between transfers").

Unfortunately, the "cs_change" field of a SPI transfer is
misleading. Its true meaning is that for a SPI message holding multiple
transfers, the chip select is toggled between each transfer, but for the
last transfer it remains asserted.

In this driver, all the SPI messages contain exactly one transfer, which
means that each transfer is the last of its message, and as a
consequence the chip select is never toggled.

Actually, there was a second bug hidding the first one, hence the
problem was not seen until v4.6. This problem was fixed by commit
a52db659c79c ("spi: pxa2xx: Fix cs_change management") for PXA based
boards.

This fix makes the TD035S work again on a cm-x300 board. The same
applies to other PXA boards, ie. corgi and tosa.

Fixes: a52db659c79c ("spi: pxa2xx: Fix cs_change management")
Reported-by: Andrea Adami 
Signed-off-by: Robert Jarzmik 
Acked-by: Daniel Thompson 
---
Since v1: added 2 other panels
Since v2: added Daniel's ack
---
 drivers/video/backlight/corgi_lcd.c | 2 +-
 drivers/video/backlight/tdo24m.c| 2 +-
 drivers/video/backlight/tosa_lcd.c  | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/video/backlight/corgi_lcd.c 
b/drivers/video/backlight/corgi_lcd.c
index d7c239ea3d09..f5574060f9c8 100644
--- a/drivers/video/backlight/corgi_lcd.c
+++ b/drivers/video/backlight/corgi_lcd.c
@@ -177,7 +177,7 @@ static int corgi_ssp_lcdtg_send(struct corgi_lcd *lcd, int 
adrs, uint8_t data)
struct spi_message msg;
struct spi_transfer xfer = {
.len= 1,
-   .cs_change  = 1,
+   .cs_change  = 0,
.tx_buf = lcd->buf,
};
 
diff --git a/drivers/video/backlight/tdo24m.c b/drivers/video/backlight/tdo24m.c
index eab1f842f9c0..e4bd63e9db6b 100644
--- a/drivers/video/backlight/tdo24m.c
+++ b/drivers/video/backlight/tdo24m.c
@@ -369,7 +369,7 @@ static int tdo24m_probe(struct spi_device *spi)
 
spi_message_init(m);
 
-   x->cs_change = 1;
+   x->cs_change = 0;
x->tx_buf = >buf[0];
spi_message_add_tail(x, m);
 
diff --git a/drivers/video/backlight/tosa_lcd.c 
b/drivers/video/backlight/tosa_lcd.c
index 6a41ea92737a..4dc5ee8debeb 100644
--- a/drivers/video/backlight/tosa_lcd.c
+++ b/drivers/video/backlight/tosa_lcd.c
@@ -49,7 +49,7 @@ static int tosa_tg_send(struct spi_device *spi, int adrs, 
uint8_t data)
struct spi_message msg;
struct spi_transfer xfer = {
.len= 1,
-   .cs_change  = 1,
+   .cs_change  = 0,
.tx_buf = buf,
};
 
-- 
2.11.0

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

[Bug 102491] OpenCL image processing produces artifacts on Cape Verde 7770

[bugzilla-daemon]

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

ka.n...@mail.ru changed:

   What|Removed |Added

Summary|OpenCL app gets |OpenCL image processing
   |CL_OUT_OF_HOST_MEMORY on|produces artifacts on Cape
   |Cape Verde 7770 |Verde 7770

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

[Bug 102491] OpenCL app gets CL_OUT_OF_HOST_MEMORY on Cape Verde 7770

[bugzilla-daemon]

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

--- Comment #5 from ka.n...@mail.ru ---
I managed to make it work somehow, but it's still unusable due to producing
artifacts on images processed using opencl on darktable and few other programs
I tried. So probably the title should be changed.

However, CL_OUT_OF_HOST_MEMORY error may be removed via envitonment var
setting, namely 

export GPU_FORCE_64BIT_PTR=1

also

export GPU_USE_SYNC_OBJECTS=1
export GPU_MAX_ALLOC_PERCENT=100
export GPU_SINGLE_ALLOC_PERCENT=100
export GPU_MAX_HEAP_SIZE=100

are recommended but I haven't noticed any difference.
What I've noticed, however, is that the driver reports the different amount of
available GPU memory each time darktable is started...

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

[PATCH] drm/virtio: Add window server support

[Tomeu Vizoso]

This is to allow clients running within VMs to be able to communicate
with a compositor in the host. Clients will use the communication
protocol that the compositor supports, and virtio-gpu will assist with
making buffers available in both sides, and copying content as needed.

It is expected that a service in the guest will act as a proxy,
interacting with virtio-gpu to support unmodified clients. For some
features of the protocol, the hypervisor might have to intervene and
also parse the protocol data to properly bridge resources. The following
IOCTLs have been added to this effect:

*_WINSRV_CONNECT: Opens a connection to the compositor in the host,
returns a FD that represents this connection and on which the following
IOCTLs can be used. Callers are expected to poll this FD for new
messages from the compositor.

*_WINSRV_TX: Asks the hypervisor to forward a message to the compositor

*_WINSRV_RX: Returns all queued messages

Alongside protocol data that is opaque to the kernel, the client can
send file descriptors that reference GEM buffers allocated by
virtio-gpu. The guest proxy is expected to figure out when a client is
passing a FD that refers to shared memory in the guest and allocate a
virtio-gpu buffer of the same size with DRM_VIRTGPU_RESOURCE_CREATE.

When the client notifies the compositor that it can read from that buffer,
the proxy should copy the contents from the SHM region to the virtio-gpu
resource and call DRM_VIRTGPU_TRANSFER_TO_HOST.

This has been tested with Wayland clients that make use of wl_shm to
pass buffers to the compositor, but is expected to work similarly for X
clients that make use of MIT-SHM with FD passing.

v2: * Add padding to two virtio command structs
* Properly cast two __user pointers (kbuild test robot)

Signed-off-by: Tomeu Vizoso 
Cc: Zach Reizner 

---

Hi,

this work is based on the virtio_wl driver in the ChromeOS kernel by
Zach Reizner, currently at:

https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4/drivers/virtio/virtio_wl.c

There's two features missing in this patch when compared with virtio_wl:

* Allow the guest access directly host memory, without having to resort
to TRANSFER_TO_HOST

* Pass FDs from host to guest (Wayland specifies that the compositor
shares keyboard data with the guest via a shared buffer)

I plan to work on this next, but I would like to get some comments on
the general approach so I can better choose which patch to follow.

Thanks,

Tomeu
---
 drivers/gpu/drm/virtio/virtgpu_drv.h   |  39 -
 drivers/gpu/drm/virtio/virtgpu_ioctl.c | 168 +++
 drivers/gpu/drm/virtio/virtgpu_kms.c   |  58 +--
 drivers/gpu/drm/virtio/virtgpu_vq.c| 285 -
 include/uapi/drm/virtgpu_drm.h |  29 
 include/uapi/linux/virtio_gpu.h|  41 +
 6 files changed, 605 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h 
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index da2fb585fea4..268b386e1232 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -178,6 +178,8 @@ struct virtio_gpu_device {
 
struct virtio_gpu_queue ctrlq;
struct virtio_gpu_queue cursorq;
+   struct virtio_gpu_queue winsrv_rxq;
+   struct virtio_gpu_queue winsrv_txq;
struct kmem_cache *vbufs;
bool vqs_ready;
 
@@ -205,10 +207,32 @@ struct virtio_gpu_device {
 
 struct virtio_gpu_fpriv {
uint32_t ctx_id;
+
+   struct list_head winsrv_conns; /* list of virtio_gpu_winsrv_conn */
+   spinlock_t winsrv_lock;
+};
+
+struct virtio_gpu_winsrv_rx_qentry {
+   struct virtio_gpu_winsrv_rx *cmd;
+   struct list_head next;
+};
+
+struct virtio_gpu_winsrv_conn {
+   struct virtio_gpu_device *vgdev;
+
+   spinlock_t lock;
+
+   int fd;
+   struct drm_file *drm_file;
+
+   struct list_head cmdq; /* queue of virtio_gpu_winsrv_rx_qentry */
+   wait_queue_head_t cmdwq;
+
+   struct list_head next;
 };
 
 /* virtio_ioctl.c */
-#define DRM_VIRTIO_NUM_IOCTLS 10
+#define DRM_VIRTIO_NUM_IOCTLS 11
 extern struct drm_ioctl_desc virtio_gpu_ioctls[DRM_VIRTIO_NUM_IOCTLS];
 
 /* virtio_kms.c */
@@ -318,9 +342,22 @@ virtio_gpu_cmd_resource_create_3d(struct virtio_gpu_device 
*vgdev,
 void virtio_gpu_ctrl_ack(struct virtqueue *vq);
 void virtio_gpu_cursor_ack(struct virtqueue *vq);
 void virtio_gpu_fence_ack(struct virtqueue *vq);
+void virtio_gpu_winsrv_tx_ack(struct virtqueue *vq);
+void virtio_gpu_winsrv_rx_read(struct virtqueue *vq);
 void virtio_gpu_dequeue_ctrl_func(struct work_struct *work);
 void virtio_gpu_dequeue_cursor_func(struct work_struct *work);
+void virtio_gpu_dequeue_winsrv_rx_func(struct work_struct *work);
+void virtio_gpu_dequeue_winsrv_tx_func(struct work_struct *work);
 void virtio_gpu_dequeue_fence_func(struct work_struct *work);
+void virtio_gpu_fill_winsrv_rx(struct virtio_gpu_device 

RE: [PATCH] staging: vboxvideo adapt to new TTM interface

[He, Roger]

Seems I have no permission to push the patch into amd-staging-drm-next.
Needs Whitelisted.

http://git.amd.com:8080/#/c/124051/1
anyone can help?

Thanks
Roger(Hongbo.He)
-Original Message-
From: Zhou, David(ChunMing) 
Sent: Thursday, December 28, 2017 12:24 PM
To: He, Roger ; dri-devel@lists.freedesktop.org
Cc: hdego...@redhat.com; gre...@linuxfoundation.org; Koenig, Christian 
; Zhou, David(ChunMing) 
Subject: Re: [PATCH] staging: vboxvideo adapt to new TTM interface

Reviewed-by: Chunming Zhou 


On 2017年12月28日 11:35, Roger He wrote:
> Fixes interface change done in the following commit:
> eb86c98 drm/ttm: use an operation ctx for ttm_tt_populate in ttm_bo_driver
>
> i missed this driver because it is in staging dir.
>
> Signed-off-by: Roger He 
> ---
>   drivers/staging/vboxvideo/vbox_ttm.c | 5 +++--
>   1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/vboxvideo/vbox_ttm.c 
> b/drivers/staging/vboxvideo/vbox_ttm.c
> index 231c89e..55f14c9 100644
> --- a/drivers/staging/vboxvideo/vbox_ttm.c
> +++ b/drivers/staging/vboxvideo/vbox_ttm.c
> @@ -213,9 +213,10 @@ static struct ttm_tt *vbox_ttm_tt_create(struct 
> ttm_bo_device *bdev,
>   return tt;
>   }
>   
> -static int vbox_ttm_tt_populate(struct ttm_tt *ttm)
> +static int vbox_ttm_tt_populate(struct ttm_tt *ttm,
> + struct ttm_operation_ctx *ctx)
>   {
> - return ttm_pool_populate(ttm);
> + return ttm_pool_populate(ttm, ctx);
>   }
>   
>   static void vbox_ttm_tt_unpopulate(struct ttm_tt *ttm)

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

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

[bugzilla-daemon]

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

Bill Fraser (bill.fra...@gmail.com) changed:

   What|Removed |Added

 CC||bill.fra...@gmail.com

--- Comment #9 from Bill Fraser (bill.fra...@gmail.com) ---
I'm seeing a very similar problem with the 'ast' driver: a black-on-black text
console, with only red-colored text visible -- luckily I have a systemd unit
that fails on boot with a red message, which I can see scrolling up the screen
as it boots, but nothing else.

I've bisected it back to the same commit as Deposite Pirate above,
[b8e2b0199cc377617dc238f5106352c06dcd3fa2].

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

Re: [PATCH 1/1] drm: Add dirty_rects atomic blob property for drm_plane

[Thomas Hellstrom]

Hi, Lukasz!

(Sorry for top-posting).

We have Deepak from our team working on the same subject. I think he's 
in over the holidays so I'll add him to the CC list.


Adding damage to the plane state is, IMO the correct way to do it. 
However, from your proposal it's not clear whether damage is given in 
the plane-, crtc- or framebuffer coordinates. The last conclusion from 
our email thread discussion was that they should be given in framebuffer 
coordinates with helpers to compute plane coordinates or crtc 
coordinates. The reason being that it's easier for user-space apps to 
send damage that way, and again, we have the full information that we 
can clip and scale if necessary. Most drivers probably want the damage 
in clipped plane- or crtc coordinates. Helpers could for example be in 
the form of region iterators.


Full (multi-rect) damage regions are OK with us, although we should keep 
in mind that we won't be able to compute region unions in the kernel 
(yet?). Implying: Should we forbid overlapping rects at the interface 
level or should we just recommend rects not to be overlapping? The 
former would be pretty hard to enforce efficiently.


Another thing we should think about is how to use this interface for the 
legacy "dirtyfb" call. Probably we need to clear the damage property on 
each state-update, or set a flag that "this is a dirtyfb state update".


IMO we should also have as an end goal of this work to have gnome-shell 
on drm sending damage regions on page-flip, which means either porting 
gnome-shell to atomic or set up a new legacy page-flip-with-atomic ioctl.


/Thomas


On 12/21/2017 12:10 PM, Lukasz Spintzyk wrote:

Change-Id: I63dce004f8d3c5dc6a7c71070f1fab0707286ea5
Signed-off-by: Lukasz Spintzyk 
---
  drivers/gpu/drm/drm_atomic.c  | 10 ++
  drivers/gpu/drm/drm_mode_config.c |  6 ++
  drivers/gpu/drm/drm_plane.c   |  1 +
  include/drm/drm_mode_config.h |  5 +
  include/drm/drm_plane.h   |  3 +++
  5 files changed, 25 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index b76d49218cf1..cd3b4ed7b04c 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -759,6 +759,14 @@ static int drm_atomic_plane_set_property(struct drm_plane 
*plane,
state->rotation = val;
} else if (property == plane->zpos_property) {
state->zpos = val;
+   } else if (property == config->dirty_rects_property) {
+   bool replaced = false;
+   int ret = drm_atomic_replace_property_blob_from_id(dev,
+   >dirty_blob,
+   val,
+   -1,
+   );
+   return ret;
} else if (plane->funcs->atomic_set_property) {
return plane->funcs->atomic_set_property(plane, state,
property, val);
@@ -818,6 +826,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
*val = state->rotation;
} else if (property == plane->zpos_property) {
*val = state->zpos;
+   } else if (property == config->dirty_rects_property) {
+   *val = (state->dirty_blob) ? state->dirty_blob->base.id : 0;
} else if (plane->funcs->atomic_get_property) {
return plane->funcs->atomic_get_property(plane, state, 
property, val);
} else {
diff --git a/drivers/gpu/drm/drm_mode_config.c 
b/drivers/gpu/drm/drm_mode_config.c
index bc5c46306b3d..d5f1021c6ece 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -293,6 +293,12 @@ static int drm_mode_create_standard_properties(struct 
drm_device *dev)
return -ENOMEM;
dev->mode_config.prop_crtc_id = prop;
  
+	prop = drm_property_create(dev, DRM_MODE_PROP_BLOB,

+   "DIRTY_RECTS", 0);
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.dirty_rects_property = prop;
+
prop = drm_property_create_bool(dev, DRM_MODE_PROP_ATOMIC,
"ACTIVE");
if (!prop)
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 37a93cdffb4a..add110f025e5 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -258,6 +258,7 @@ int drm_universal_plane_init(struct drm_device *dev, struct 
drm_plane *plane,
drm_object_attach_property(>base, config->prop_src_y, 0);
drm_object_attach_property(>base, config->prop_src_w, 0);
drm_object_attach_property(>base, config->prop_src_h, 0);
+   drm_object_attach_property(>base, 
config->dirty_rects_property, 0);
}
  
  	if (config->allow_fb_modifiers)

diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index e5f3b43014e1..65f64eb04c0c 100644
---