Re: [Intel-gfx] [PATCH 11/11] drm/tiny: drm_gem_simple_display_pipe_prepare_fb is the default
On 5/21/21 12:09 PM, Daniel Vetter wrote: > Goes through all the drivers and deletes the default hook since it's > the default now. > > Signed-off-by: Daniel Vetter Acked-by: Oleksandr Andrushchenko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/xen-front: Add support for EDID based configuration
From: Oleksandr Andrushchenko
Version 2 of the Xen displif protocol adds XENDISPL_OP_GET_EDID
request which allows frontends to request EDID structure per
connector. This request is optional and if not supported by the
backend then visible area is still defined by the relevant
XenStore's "resolution" property.
If backend provides EDID with XENDISPL_OP_GET_EDID request then
its values must take precedence over the resolutions defined in
XenStore.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/gpu/drm/xen/xen_drm_front.c | 62
drivers/gpu/drm/xen/xen_drm_front.h | 9 ++-
drivers/gpu/drm/xen/xen_drm_front_cfg.c | 82 +
drivers/gpu/drm/xen/xen_drm_front_cfg.h | 7 ++
drivers/gpu/drm/xen/xen_drm_front_conn.c| 26 ++-
drivers/gpu/drm/xen/xen_drm_front_evtchnl.c | 4 +
drivers/gpu/drm/xen/xen_drm_front_evtchnl.h | 3 +
drivers/gpu/drm/xen/xen_drm_front_kms.c | 5 ++
8 files changed, 195 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/xen/xen_drm_front.c
b/drivers/gpu/drm/xen/xen_drm_front.c
index 013c9e0e412c..cc5981bdbfb3 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.c
+++ b/drivers/gpu/drm/xen/xen_drm_front.c
@@ -381,6 +381,59 @@ void xen_drm_front_on_frame_done(struct xen_drm_front_info
*front_info,
fb_cookie);
}
+int xen_drm_front_get_edid(struct xen_drm_front_info *front_info,
+ int conn_idx, struct page **pages,
+ u32 buffer_sz, u32 *edid_sz)
+{
+ struct xen_drm_front_evtchnl *evtchnl;
+ struct xen_front_pgdir_shbuf_cfg buf_cfg;
+ struct xen_front_pgdir_shbuf shbuf;
+ struct xendispl_req *req;
+ unsigned long flags;
+ int ret;
+
+ if (unlikely(conn_idx >= front_info->num_evt_pairs))
+ return -EINVAL;
+
+ memset(_cfg, 0, sizeof(buf_cfg));
+ buf_cfg.xb_dev = front_info->xb_dev;
+ buf_cfg.num_pages = DIV_ROUND_UP(buffer_sz, PAGE_SIZE);
+ buf_cfg.pages = pages;
+ buf_cfg.pgdir =
+ buf_cfg.be_alloc = false;
+
+ ret = xen_front_pgdir_shbuf_alloc(_cfg);
+ if (ret < 0)
+ return ret;
+
+ evtchnl = _info->evt_pairs[conn_idx].req;
+
+ mutex_lock(>u.req.req_io_lock);
+
+ spin_lock_irqsave(_info->io_lock, flags);
+ req = be_prepare_req(evtchnl, XENDISPL_OP_GET_EDID);
+ req->op.get_edid.gref_directory =
+ xen_front_pgdir_shbuf_get_dir_start();
+ req->op.get_edid.buffer_sz = buffer_sz;
+
+ ret = be_stream_do_io(evtchnl, req);
+ spin_unlock_irqrestore(_info->io_lock, flags);
+
+ if (ret < 0)
+ goto fail;
+
+ ret = be_stream_wait_io(evtchnl);
+ if (ret < 0)
+ goto fail;
+
+ *edid_sz = evtchnl->u.req.resp.get_edid.edid_sz;
+
+fail:
+ mutex_unlock(>u.req.req_io_lock);
+ xen_front_pgdir_shbuf_free();
+ return ret;
+}
+
static int xen_drm_drv_dumb_create(struct drm_file *filp,
struct drm_device *dev,
struct drm_mode_create_dumb *args)
@@ -466,6 +519,7 @@ static void xen_drm_drv_release(struct drm_device *dev)
xenbus_switch_state(front_info->xb_dev,
XenbusStateInitialising);
+ xen_drm_front_cfg_free(front_info, _info->cfg);
kfree(drm_info);
}
@@ -562,6 +616,7 @@ static int xen_drm_drv_init(struct xen_drm_front_info
*front_info)
drm_mode_config_cleanup(drm_dev);
drm_dev_put(drm_dev);
fail:
+ xen_drm_front_cfg_free(front_info, _info->cfg);
kfree(drm_info);
return ret;
}
@@ -622,7 +677,14 @@ static int displback_initwait(struct xen_drm_front_info
*front_info)
static int displback_connect(struct xen_drm_front_info *front_info)
{
+ int ret;
+
xen_drm_front_evtchnl_set_state(front_info, EVTCHNL_STATE_CONNECTED);
+
+ /* We are all set to read additional configuration from the backend. */
+ ret = xen_drm_front_cfg_tail(front_info, _info->cfg);
+ if (ret < 0)
+ return ret;
return xen_drm_drv_init(front_info);
}
diff --git a/drivers/gpu/drm/xen/xen_drm_front.h
b/drivers/gpu/drm/xen/xen_drm_front.h
index 54486d89650e..be0c982f4d82 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.h
+++ b/drivers/gpu/drm/xen/xen_drm_front.h
@@ -112,9 +112,12 @@ struct xen_drm_front_drm_pipeline {
struct drm_simple_display_pipe pipe;
struct drm_connector conn;
- /* These are only for connector mode checking */
+ /* These are only for connector mode checking if no EDID present */
int width, height;
+ /* Is not NULL if EDID is used for connector configuration. */
+ struct edid *edid;
+
struct drm_pending_vblank_event *pending_event;
Re: [Intel-gfx] [PATCH v2 0/5] Fixes and improvements for Xen pvdrm
On 8/13/20 6:13 PM, Jürgen Groß wrote: > On 13.08.20 17:10, Oleksandr Andrushchenko wrote: >> >> On 8/13/20 6:02 PM, Jürgen Groß wrote: >>> On 13.08.20 08:21, Oleksandr Andrushchenko wrote: >>>> From: Oleksandr Andrushchenko >>> >>> Series pushed to: >>> >>> xen/tip.git for-linus-5.9 >>> >> The top patch has strange title though: >> >> "Subject: [PATCH v2 5/5] drm/xen-front: Pass dumb buffer data offset to the >> backend" > > Oh, indeed. I had to repair it manually as it seems some mail system > (probably on my end) mangled it a little bit. > > Will repair it. > Now everything is great, Thank you! > > Juergen ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 0/5] Fixes and improvements for Xen pvdrm
On 8/13/20 6:02 PM, Jürgen Groß wrote: > On 13.08.20 08:21, Oleksandr Andrushchenko wrote: >> From: Oleksandr Andrushchenko > > Series pushed to: > > xen/tip.git for-linus-5.9 > The top patch has strange title though: "Subject: [PATCH v2 5/5] drm/xen-front: Pass dumb buffer data offset to the backend" > > Juergen Thank you, Oleksandr ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 0/5] Fixes and improvements for Xen pvdrm
On 8/13/20 10:05 AM, Jürgen Groß wrote: > On 13.08.20 08:32, Oleksandr Andrushchenko wrote: >> Juergen, Boris, >> >> can we please merge these via Xen Linux tree as I have collected enough >> Ack/R-b? >> >> The series has DRM patches, but those anyway are Xen related, so I think >> >> this should be fine from DRI point of view. > > Yes, fine with me. Great, thank you > > > Juergen > >> >> Thank you, >> >> Oleksandr >> >> On 8/13/20 9:21 AM, Oleksandr Andrushchenko wrote: >>> From: Oleksandr Andrushchenko >>> >>> Hello, >>> >>> This series contains an assorted set of fixes and improvements for >>> the Xen para-virtualized display driver and grant device driver which >>> I have collected over the last couple of months: >>> >>> 1. Minor fixes to grant device driver and drm/xen-front. >>> >>> 2. New format (YUYV) added to the list of the PV DRM supported formats >>> which allows the driver to be used in zero-copying use-cases when >>> a camera device is the source of the dma-bufs. >>> >>> 3. Synchronization with the latest para-virtualized protocol definition >>> in Xen [1]. >>> >>> 4. SGT offset is now propagated to the backend: while importing a dmabuf >>> it is possible that the data of the buffer is put with offset which is >>> indicated by the SGT offset. This is needed for some GPUs which have >>> non-zero offset. >>> >>> Thank you, >>> Oleksandr Andrushchenko >>> >>> [1] >>> https://urldefense.com/v3/__https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=c27a184225eab54d20435c8cab5ad0ef384dc2c0__;!!GF_29dbcQIUBPA!iAHOdk4M167VNM1AypMGVmyKJu-iqC9e5cXyu6N595Np3iyIZDnZl0MIBX3IROJSD1GSMX_GfQ$ >>> [xenbits[.]xen[.]org] >>> >>> Changes since v1: >>> = >>> >>> 1. Removed patch which adds EDID to PV DRM as it needs more time for review: >>> "5. Version 2 of the Xen displif protocol adds XENDISPL_OP_GET_EDID >>> request which allows frontends to request EDID structure per >>> connector. This request is optional and if not supported by the >>> backend then visible area is still defined by the relevant >>> XenStore's "resolution" property. >>> If backend provides EDID with XENDISPL_OP_GET_EDID request then >>> its values must take precedence over the resolutions defined in >>> XenStore." >>> I will send this as a dedicated patch. >>> >>> 2. Added missing CC stable for the patches with fixes >>> >>> Oleksandr Andrushchenko (5): >>> xen/gntdev: Fix dmabuf import with non-zero sgt offset >>> drm/xen-front: Fix misused IS_ERR_OR_NULL checks >>> drm/xen-front: Add YUYV to supported formats >>> xen: Sync up with the canonical protocol definition in Xen >>> drm/xen-front: Pass dumb buffer data offset to the backend >>> >>> drivers/gpu/drm/xen/xen_drm_front.c | 10 +-- >>> drivers/gpu/drm/xen/xen_drm_front.h | 2 +- >>> drivers/gpu/drm/xen/xen_drm_front_conn.c | 1 + >>> drivers/gpu/drm/xen/xen_drm_front_gem.c | 11 +-- >>> drivers/gpu/drm/xen/xen_drm_front_kms.c | 2 +- >>> drivers/xen/gntdev-dmabuf.c | 8 +++ >>> include/xen/interface/io/displif.h | 91 +++- >>> 7 files changed, 111 insertions(+), 14 deletions(-) >>> >> > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 18/20] drm/xen: Introduce GEM object functions
Hi,
On 8/13/20 11:36 AM, Thomas Zimmermann wrote:
> GEM object functions deprecate several similar callback interfaces in
> struct drm_driver. This patch replaces the per-driver callbacks with
> per-instance callbacks in xen. The only exception is gem_prime_mmap,
> which is non-trivial to convert.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/xen/xen_drm_front.c | 12 +---
> drivers/gpu/drm/xen/xen_drm_front.h | 2 ++
> drivers/gpu/drm/xen/xen_drm_front_gem.c | 15 +++
> 3 files changed, 18 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/xen/xen_drm_front.c
> b/drivers/gpu/drm/xen/xen_drm_front.c
> index 3e660fb111b3..bd9af1875af1 100644
> --- a/drivers/gpu/drm/xen/xen_drm_front.c
> +++ b/drivers/gpu/drm/xen/xen_drm_front.c
> @@ -433,7 +433,7 @@ static int xen_drm_drv_dumb_create(struct drm_file *filp,
> return ret;
> }
>
> -static void xen_drm_drv_free_object_unlocked(struct drm_gem_object *obj)
> +void xen_drm_drv_free_object_unlocked(struct drm_gem_object *obj)
Can we please have naming consistent and name it as
xen_drm_front_drv_free_object_unlocked or any other name if this seems to be
too long,
but starting with xen_drm_front_ as the rest of exported functions?
With this,
Acked-by: Oleksandr Andrushchenko
Thank you,
Oleksandr
> {
> struct xen_drm_front_drm_info *drm_info = obj->dev->dev_private;
> int idx;
> @@ -481,22 +481,12 @@ static const struct file_operations xen_drm_dev_fops = {
> .mmap = xen_drm_front_gem_mmap,
> };
>
> -static const struct vm_operations_struct xen_drm_drv_vm_ops = {
> - .open = drm_gem_vm_open,
> - .close = drm_gem_vm_close,
> -};
> -
> static struct drm_driver xen_drm_driver = {
> .driver_features = DRIVER_GEM | DRIVER_MODESET |
> DRIVER_ATOMIC,
> .release = xen_drm_drv_release,
> - .gem_vm_ops= _drm_drv_vm_ops,
> - .gem_free_object_unlocked = xen_drm_drv_free_object_unlocked,
> .prime_handle_to_fd= drm_gem_prime_handle_to_fd,
> .prime_fd_to_handle= drm_gem_prime_fd_to_handle,
> .gem_prime_import_sg_table = xen_drm_front_gem_import_sg_table,
> - .gem_prime_get_sg_table= xen_drm_front_gem_get_sg_table,
> - .gem_prime_vmap= xen_drm_front_gem_prime_vmap,
> - .gem_prime_vunmap = xen_drm_front_gem_prime_vunmap,
> .gem_prime_mmap= xen_drm_front_gem_prime_mmap,
> .dumb_create = xen_drm_drv_dumb_create,
> .fops = _drm_dev_fops,
> diff --git a/drivers/gpu/drm/xen/xen_drm_front.h
> b/drivers/gpu/drm/xen/xen_drm_front.h
> index f92c258350ca..93e60c1db550 100644
> --- a/drivers/gpu/drm/xen/xen_drm_front.h
> +++ b/drivers/gpu/drm/xen/xen_drm_front.h
> @@ -160,4 +160,6 @@ int xen_drm_front_page_flip(struct xen_drm_front_info
> *front_info,
> void xen_drm_front_on_frame_done(struct xen_drm_front_info *front_info,
>int conn_idx, u64 fb_cookie);
>
> +void xen_drm_drv_free_object_unlocked(struct drm_gem_object *obj);
> +
> #endif /* __XEN_DRM_FRONT_H_ */
> diff --git a/drivers/gpu/drm/xen/xen_drm_front_gem.c
> b/drivers/gpu/drm/xen/xen_drm_front_gem.c
> index f0b85e094111..7b315c08bcfc 100644
> --- a/drivers/gpu/drm/xen/xen_drm_front_gem.c
> +++ b/drivers/gpu/drm/xen/xen_drm_front_gem.c
> @@ -56,6 +56,19 @@ static void gem_free_pages_array(struct xen_gem_object
> *xen_obj)
> xen_obj->pages = NULL;
> }
>
> +static const struct vm_operations_struct xen_drm_drv_vm_ops = {
> + .open = drm_gem_vm_open,
> + .close = drm_gem_vm_close,
> +};
> +
> +static const struct drm_gem_object_funcs xen_drm_front_gem_object_funcs = {
> + .free = xen_drm_drv_free_object_unlocked,
> + .get_sg_table = xen_drm_front_gem_get_sg_table,
> + .vmap = xen_drm_front_gem_prime_vmap,
> + .vunmap = xen_drm_front_gem_prime_vunmap,
> + .vm_ops = _drm_drv_vm_ops,
> +};
> +
> static struct xen_gem_object *gem_create_obj(struct drm_device *dev,
>size_t size)
> {
> @@ -66,6 +79,8 @@ static struct xen_gem_object *gem_create_obj(struct
> drm_device *dev,
> if (!xen_obj)
> return ERR_PTR(-ENOMEM);
>
> + xen_obj->base.funcs = _drm_front_gem_object_funcs;
> +
> ret = drm_gem_object_init(dev, _obj->base, size);
> if (ret < 0) {
> kfree(xen_obj);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 0/5] Fixes and improvements for Xen pvdrm
Juergen, Boris, can we please merge these via Xen Linux tree as I have collected enough Ack/R-b? The series has DRM patches, but those anyway are Xen related, so I think this should be fine from DRI point of view. Thank you, Oleksandr On 8/13/20 9:21 AM, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > Hello, > > This series contains an assorted set of fixes and improvements for > the Xen para-virtualized display driver and grant device driver which > I have collected over the last couple of months: > > 1. Minor fixes to grant device driver and drm/xen-front. > > 2. New format (YUYV) added to the list of the PV DRM supported formats > which allows the driver to be used in zero-copying use-cases when > a camera device is the source of the dma-bufs. > > 3. Synchronization with the latest para-virtualized protocol definition > in Xen [1]. > > 4. SGT offset is now propagated to the backend: while importing a dmabuf > it is possible that the data of the buffer is put with offset which is > indicated by the SGT offset. This is needed for some GPUs which have > non-zero offset. > > Thank you, > Oleksandr Andrushchenko > > [1] > https://urldefense.com/v3/__https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=c27a184225eab54d20435c8cab5ad0ef384dc2c0__;!!GF_29dbcQIUBPA!iAHOdk4M167VNM1AypMGVmyKJu-iqC9e5cXyu6N595Np3iyIZDnZl0MIBX3IROJSD1GSMX_GfQ$ > [xenbits[.]xen[.]org] > > Changes since v1: > = > > 1. Removed patch which adds EDID to PV DRM as it needs more time for review: > "5. Version 2 of the Xen displif protocol adds XENDISPL_OP_GET_EDID > request which allows frontends to request EDID structure per > connector. This request is optional and if not supported by the > backend then visible area is still defined by the relevant > XenStore's "resolution" property. > If backend provides EDID with XENDISPL_OP_GET_EDID request then > its values must take precedence over the resolutions defined in > XenStore." > I will send this as a dedicated patch. > > 2. Added missing CC stable for the patches with fixes > > Oleksandr Andrushchenko (5): >xen/gntdev: Fix dmabuf import with non-zero sgt offset >drm/xen-front: Fix misused IS_ERR_OR_NULL checks >drm/xen-front: Add YUYV to supported formats >xen: Sync up with the canonical protocol definition in Xen >drm/xen-front: Pass dumb buffer data offset to the backend > > drivers/gpu/drm/xen/xen_drm_front.c | 10 +-- > drivers/gpu/drm/xen/xen_drm_front.h | 2 +- > drivers/gpu/drm/xen/xen_drm_front_conn.c | 1 + > drivers/gpu/drm/xen/xen_drm_front_gem.c | 11 +-- > drivers/gpu/drm/xen/xen_drm_front_kms.c | 2 +- > drivers/xen/gntdev-dmabuf.c | 8 +++ > include/xen/interface/io/displif.h | 91 +++- > 7 files changed, 111 insertions(+), 14 deletions(-) > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/5] drm/xen-front: Fix misused IS_ERR_OR_NULL checks
From: Oleksandr Andrushchenko
The patch c575b7eeb89f: "drm/xen-front: Add support for Xen PV
display frontend" from Apr 3, 2018, leads to the following static
checker warning:
drivers/gpu/drm/xen/xen_drm_front_gem.c:140 xen_drm_front_gem_create()
warn: passing zero to 'ERR_CAST'
drivers/gpu/drm/xen/xen_drm_front_gem.c
133 struct drm_gem_object *xen_drm_front_gem_create(struct drm_device *dev,
134 size_t size)
135 {
136 struct xen_gem_object *xen_obj;
137
138 xen_obj = gem_create(dev, size);
139 if (IS_ERR_OR_NULL(xen_obj))
140 return ERR_CAST(xen_obj);
Fix this and the rest of misused places with IS_ERR_OR_NULL in the
driver.
Fixes: c575b7eeb89f: "drm/xen-front: Add support for Xen PV display frontend"
Signed-off-by: Oleksandr Andrushchenko
Reported-by: Dan Carpenter
Reviewed-by: Dan Carpenter
Cc:
---
drivers/gpu/drm/xen/xen_drm_front.c | 4 ++--
drivers/gpu/drm/xen/xen_drm_front_gem.c | 8
drivers/gpu/drm/xen/xen_drm_front_kms.c | 2 +-
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/xen/xen_drm_front.c
b/drivers/gpu/drm/xen/xen_drm_front.c
index 1fd458e877ca..51818e76facd 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.c
+++ b/drivers/gpu/drm/xen/xen_drm_front.c
@@ -400,8 +400,8 @@ static int xen_drm_drv_dumb_create(struct drm_file *filp,
args->size = args->pitch * args->height;
obj = xen_drm_front_gem_create(dev, args->size);
- if (IS_ERR_OR_NULL(obj)) {
- ret = PTR_ERR_OR_ZERO(obj);
+ if (IS_ERR(obj)) {
+ ret = PTR_ERR(obj);
goto fail;
}
diff --git a/drivers/gpu/drm/xen/xen_drm_front_gem.c
b/drivers/gpu/drm/xen/xen_drm_front_gem.c
index f0b85e094111..4ec8a49241e1 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_gem.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_gem.c
@@ -83,7 +83,7 @@ static struct xen_gem_object *gem_create(struct drm_device
*dev, size_t size)
size = round_up(size, PAGE_SIZE);
xen_obj = gem_create_obj(dev, size);
- if (IS_ERR_OR_NULL(xen_obj))
+ if (IS_ERR(xen_obj))
return xen_obj;
if (drm_info->front_info->cfg.be_alloc) {
@@ -117,7 +117,7 @@ static struct xen_gem_object *gem_create(struct drm_device
*dev, size_t size)
*/
xen_obj->num_pages = DIV_ROUND_UP(size, PAGE_SIZE);
xen_obj->pages = drm_gem_get_pages(_obj->base);
- if (IS_ERR_OR_NULL(xen_obj->pages)) {
+ if (IS_ERR(xen_obj->pages)) {
ret = PTR_ERR(xen_obj->pages);
xen_obj->pages = NULL;
goto fail;
@@ -136,7 +136,7 @@ struct drm_gem_object *xen_drm_front_gem_create(struct
drm_device *dev,
struct xen_gem_object *xen_obj;
xen_obj = gem_create(dev, size);
- if (IS_ERR_OR_NULL(xen_obj))
+ if (IS_ERR(xen_obj))
return ERR_CAST(xen_obj);
return _obj->base;
@@ -194,7 +194,7 @@ xen_drm_front_gem_import_sg_table(struct drm_device *dev,
size = attach->dmabuf->size;
xen_obj = gem_create_obj(dev, size);
- if (IS_ERR_OR_NULL(xen_obj))
+ if (IS_ERR(xen_obj))
return ERR_CAST(xen_obj);
ret = gem_alloc_pages_array(xen_obj, size);
diff --git a/drivers/gpu/drm/xen/xen_drm_front_kms.c
b/drivers/gpu/drm/xen/xen_drm_front_kms.c
index 78096bbcd226..ef11b1e4de39 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_kms.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_kms.c
@@ -60,7 +60,7 @@ fb_create(struct drm_device *dev, struct drm_file *filp,
int ret;
fb = drm_gem_fb_create_with_funcs(dev, filp, mode_cmd, _funcs);
- if (IS_ERR_OR_NULL(fb))
+ if (IS_ERR(fb))
return fb;
gem_obj = fb->obj[0];
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 3/5] drm/xen-front: Add YUYV to supported formats
From: Oleksandr Andrushchenko
Add YUYV to supported formats, so the frontend can work with the
formats used by cameras and other HW.
Signed-off-by: Oleksandr Andrushchenko
Acked-by: Noralf Trønnes
---
drivers/gpu/drm/xen/xen_drm_front_conn.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/xen/xen_drm_front_conn.c
b/drivers/gpu/drm/xen/xen_drm_front_conn.c
index 459702fa990e..44f1f70c0aed 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_conn.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_conn.c
@@ -33,6 +33,7 @@ static const u32 plane_formats[] = {
DRM_FORMAT_ARGB,
DRM_FORMAT_XRGB1555,
DRM_FORMAT_ARGB1555,
+ DRM_FORMAT_YUYV,
};
const u32 *xen_drm_front_conn_get_formats(int *format_count)
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 4/5] xen: Sync up with the canonical protocol definition in Xen
From: Oleksandr Andrushchenko
This is the sync up with the canonical definition of the
display protocol in Xen.
1. Add protocol version as an integer
Version string, which is in fact an integer, is hard to handle in the
code that supports different protocol versions. To simplify that
also add the version as an integer.
2. Pass buffer offset with XENDISPL_OP_DBUF_CREATE
There are cases when display data buffer is created with non-zero
offset to the data start. Handle such cases and provide that offset
while creating a display buffer.
3. Add XENDISPL_OP_GET_EDID command
Add an optional request for reading Extended Display Identification
Data (EDID) structure which allows better configuration of the
display connectors over the configuration set in XenStore.
With this change connectors may have multiple resolutions defined
with respect to detailed timing definitions and additional properties
normally provided by displays.
If this request is not supported by the backend then visible area
is defined by the relevant XenStore's "resolution" property.
If backend provides extended display identification data (EDID) with
XENDISPL_OP_GET_EDID request then EDID values must take precedence
over the resolutions defined in XenStore.
4. Bump protocol version to 2.
Signed-off-by: Oleksandr Andrushchenko
Reviewed-by: Juergen Gross
---
include/xen/interface/io/displif.h | 91 +-
1 file changed, 88 insertions(+), 3 deletions(-)
diff --git a/include/xen/interface/io/displif.h
b/include/xen/interface/io/displif.h
index fdc279dc4a88..d43ca0361f86 100644
--- a/include/xen/interface/io/displif.h
+++ b/include/xen/interface/io/displif.h
@@ -38,7 +38,8 @@
* Protocol version
**
*/
-#define XENDISPL_PROTOCOL_VERSION "1"
+#define XENDISPL_PROTOCOL_VERSION "2"
+#define XENDISPL_PROTOCOL_VERSION_INT 2
/*
**
@@ -202,6 +203,9 @@
* Width and height of the connector in pixels separated by
* XENDISPL_RESOLUTION_SEPARATOR. This defines visible area of the
* display.
+ * If backend provides extended display identification data (EDID) with
+ * XENDISPL_OP_GET_EDID request then EDID values must take precedence
+ * over the resolutions defined here.
*
*-- Connector Request Transport Parameters ---
*
@@ -349,6 +353,8 @@
#define XENDISPL_OP_FB_DETACH 0x13
#define XENDISPL_OP_SET_CONFIG 0x14
#define XENDISPL_OP_PG_FLIP0x15
+/* The below command is available in protocol version 2 and above. */
+#define XENDISPL_OP_GET_EDID 0x16
/*
**
@@ -377,6 +383,10 @@
#define XENDISPL_FIELD_BE_ALLOC"be-alloc"
#define XENDISPL_FIELD_UNIQUE_ID "unique-id"
+#define XENDISPL_EDID_BLOCK_SIZE 128
+#define XENDISPL_EDID_BLOCK_COUNT 256
+#define XENDISPL_EDID_MAX_SIZE (XENDISPL_EDID_BLOCK_SIZE *
XENDISPL_EDID_BLOCK_COUNT)
+
/*
**
* STATUS RETURN CODES
@@ -451,7 +461,9 @@
* +++++
* | gref_directory | 40
* +++++
- * | reserved | 44
+ * | data_ofs | 44
+ * +++++
+ * | reserved | 48
* +++++
* |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/|
* +++++
@@ -494,6 +506,7 @@
* buffer size (buffer_sz) exceeds what can be addressed by this single page,
* then reference to the next page must be supplied (see gref_dir_next_page
* below)
+ * data_ofs - uint32_t, offset of the data in the buffer, octets
*/
#define XENDISPL_DBUF_FLG_REQ_ALLOC(1 << 0)
@@ -506,6 +519,7 @@ struct xendispl_dbuf_create_req {
uint32_t buffer_sz;
uint32_t flags;
grant_ref_t gref_directory;
+ uint32_t data_ofs;
};
/*
@@ -731,6 +745,44 @@ struct xendispl_page_flip_req {
uint64_t fb_cookie;
};
+/*
+ * Request EDID - request EDID describing current connector:
+ * 01 2 3octet
+ * +++++
+ * |
[Intel-gfx] [PATCH v2 0/5] Fixes and improvements for Xen pvdrm
From: Oleksandr Andrushchenko Hello, This series contains an assorted set of fixes and improvements for the Xen para-virtualized display driver and grant device driver which I have collected over the last couple of months: 1. Minor fixes to grant device driver and drm/xen-front. 2. New format (YUYV) added to the list of the PV DRM supported formats which allows the driver to be used in zero-copying use-cases when a camera device is the source of the dma-bufs. 3. Synchronization with the latest para-virtualized protocol definition in Xen [1]. 4. SGT offset is now propagated to the backend: while importing a dmabuf it is possible that the data of the buffer is put with offset which is indicated by the SGT offset. This is needed for some GPUs which have non-zero offset. Thank you, Oleksandr Andrushchenko [1] https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=c27a184225eab54d20435c8cab5ad0ef384dc2c0 Changes since v1: = 1. Removed patch which adds EDID to PV DRM as it needs more time for review: "5. Version 2 of the Xen displif protocol adds XENDISPL_OP_GET_EDID request which allows frontends to request EDID structure per connector. This request is optional and if not supported by the backend then visible area is still defined by the relevant XenStore's "resolution" property. If backend provides EDID with XENDISPL_OP_GET_EDID request then its values must take precedence over the resolutions defined in XenStore." I will send this as a dedicated patch. 2. Added missing CC stable for the patches with fixes Oleksandr Andrushchenko (5): xen/gntdev: Fix dmabuf import with non-zero sgt offset drm/xen-front: Fix misused IS_ERR_OR_NULL checks drm/xen-front: Add YUYV to supported formats xen: Sync up with the canonical protocol definition in Xen drm/xen-front: Pass dumb buffer data offset to the backend drivers/gpu/drm/xen/xen_drm_front.c | 10 +-- drivers/gpu/drm/xen/xen_drm_front.h | 2 +- drivers/gpu/drm/xen/xen_drm_front_conn.c | 1 + drivers/gpu/drm/xen/xen_drm_front_gem.c | 11 +-- drivers/gpu/drm/xen/xen_drm_front_kms.c | 2 +- drivers/xen/gntdev-dmabuf.c | 8 +++ include/xen/interface/io/displif.h | 91 +++- 7 files changed, 111 insertions(+), 14 deletions(-) -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 5/5] drm/xen-front: Pass dumb buffer data offset to the backend
From: Oleksandr Andrushchenko
While importing a dmabuf it is possible that the data of the buffer
is put with offset which is indicated by the SGT offset.
Respect the offset value and forward it to the backend.
Signed-off-by: Oleksandr Andrushchenko
Acked-by: Noralf Trønnes
---
drivers/gpu/drm/xen/xen_drm_front.c | 6 --
drivers/gpu/drm/xen/xen_drm_front.h | 2 +-
drivers/gpu/drm/xen/xen_drm_front_gem.c | 3 ++-
3 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/xen/xen_drm_front.c
b/drivers/gpu/drm/xen/xen_drm_front.c
index 51818e76facd..3dd56794593a 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.c
+++ b/drivers/gpu/drm/xen/xen_drm_front.c
@@ -157,7 +157,8 @@ int xen_drm_front_mode_set(struct
xen_drm_front_drm_pipeline *pipeline,
int xen_drm_front_dbuf_create(struct xen_drm_front_info *front_info,
u64 dbuf_cookie, u32 width, u32 height,
- u32 bpp, u64 size, struct page **pages)
+ u32 bpp, u64 size, u32 offset,
+ struct page **pages)
{
struct xen_drm_front_evtchnl *evtchnl;
struct xen_drm_front_dbuf *dbuf;
@@ -194,6 +195,7 @@ int xen_drm_front_dbuf_create(struct xen_drm_front_info
*front_info,
req->op.dbuf_create.gref_directory =
xen_front_pgdir_shbuf_get_dir_start(>shbuf);
req->op.dbuf_create.buffer_sz = size;
+ req->op.dbuf_create.data_ofs = offset;
req->op.dbuf_create.dbuf_cookie = dbuf_cookie;
req->op.dbuf_create.width = width;
req->op.dbuf_create.height = height;
@@ -408,7 +410,7 @@ static int xen_drm_drv_dumb_create(struct drm_file *filp,
ret = xen_drm_front_dbuf_create(drm_info->front_info,
xen_drm_front_dbuf_to_cookie(obj),
args->width, args->height, args->bpp,
- args->size,
+ args->size, 0,
xen_drm_front_gem_get_pages(obj));
if (ret)
goto fail_backend;
diff --git a/drivers/gpu/drm/xen/xen_drm_front.h
b/drivers/gpu/drm/xen/xen_drm_front.h
index f92c258350ca..54486d89650e 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.h
+++ b/drivers/gpu/drm/xen/xen_drm_front.h
@@ -145,7 +145,7 @@ int xen_drm_front_mode_set(struct
xen_drm_front_drm_pipeline *pipeline,
int xen_drm_front_dbuf_create(struct xen_drm_front_info *front_info,
u64 dbuf_cookie, u32 width, u32 height,
- u32 bpp, u64 size, struct page **pages);
+ u32 bpp, u64 size, u32 offset, struct page
**pages);
int xen_drm_front_fb_attach(struct xen_drm_front_info *front_info,
u64 dbuf_cookie, u64 fb_cookie, u32 width,
diff --git a/drivers/gpu/drm/xen/xen_drm_front_gem.c
b/drivers/gpu/drm/xen/xen_drm_front_gem.c
index 4ec8a49241e1..39ff95b75357 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_gem.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_gem.c
@@ -210,7 +210,8 @@ xen_drm_front_gem_import_sg_table(struct drm_device *dev,
ret = xen_drm_front_dbuf_create(drm_info->front_info,
xen_drm_front_dbuf_to_cookie(_obj->base),
- 0, 0, 0, size, xen_obj->pages);
+ 0, 0, 0, size, sgt->sgl->offset,
+ xen_obj->pages);
if (ret < 0)
return ERR_PTR(ret);
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/5] xen/gntdev: Fix dmabuf import with non-zero sgt offset
From: Oleksandr Andrushchenko
It is possible that the scatter-gather table during dmabuf import has
non-zero offset of the data, but user-space doesn't expect that.
Fix this by failing the import, so user-space doesn't access wrong data.
Fixes: bf8dc55b1358 ("xen/gntdev: Implement dma-buf import functionality")
Signed-off-by: Oleksandr Andrushchenko
Acked-by: Juergen Gross
Cc:
---
drivers/xen/gntdev-dmabuf.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/xen/gntdev-dmabuf.c b/drivers/xen/gntdev-dmabuf.c
index 75d3bb948bf3..b1b6eebafd5d 100644
--- a/drivers/xen/gntdev-dmabuf.c
+++ b/drivers/xen/gntdev-dmabuf.c
@@ -613,6 +613,14 @@ dmabuf_imp_to_refs(struct gntdev_dmabuf_priv *priv, struct
device *dev,
goto fail_detach;
}
+ /* Check that we have zero offset. */
+ if (sgt->sgl->offset) {
+ ret = ERR_PTR(-EINVAL);
+ pr_debug("DMA buffer has %d bytes offset, user-space expects
0\n",
+sgt->sgl->offset);
+ goto fail_unmap;
+ }
+
/* Check number of pages that imported buffer has. */
if (attach->dmabuf->size != gntdev_dmabuf->nr_pages << PAGE_SHIFT) {
ret = ERR_PTR(-EINVAL);
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/6] xen/gntdev: Fix dmabuf import with non-zero sgt offset
On 8/4/20 9:11 AM, Jürgen Groß wrote:
> On 31.07.20 14:51, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> It is possible that the scatter-gather table during dmabuf import has
>> non-zero offset of the data, but user-space doesn't expect that.
>> Fix this by failing the import, so user-space doesn't access wrong data.
>>
>> Fixes: 37ccb44d0b00 ("xen/gntdev: Implement dma-buf import functionality")
>
> I can't find this commit in the tree. Did you mean bf8dc55b1358?
I'll double-check, thank you
>
> And don't you want to Cc stable for this patch, too?
Hm, yes, sounds reasonable
>
>>
>> Signed-off-by: Oleksandr Andrushchenko
>
> Acked-by: Juergen Gross
>
>
> Juergen
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/6] drm/xen-front: Fix misused IS_ERR_OR_NULL checks
On 8/4/20 9:12 AM, Jürgen Groß wrote:
> On 31.07.20 14:51, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> The patch c575b7eeb89f: "drm/xen-front: Add support for Xen PV
>> display frontend" from Apr 3, 2018, leads to the following static
>> checker warning:
>>
>> drivers/gpu/drm/xen/xen_drm_front_gem.c:140 xen_drm_front_gem_create()
>> warn: passing zero to 'ERR_CAST'
>>
>> drivers/gpu/drm/xen/xen_drm_front_gem.c
>> 133 struct drm_gem_object *xen_drm_front_gem_create(struct drm_device
>> *dev,
>> 134 size_t size)
>> 135 {
>> 136 struct xen_gem_object *xen_obj;
>> 137
>> 138 xen_obj = gem_create(dev, size);
>> 139 if (IS_ERR_OR_NULL(xen_obj))
>> 140 return ERR_CAST(xen_obj);
>>
>> Fix this and the rest of misused places with IS_ERR_OR_NULL in the
>> driver.
>>
>> Fixes: c575b7eeb89f: "drm/xen-front: Add support for Xen PV display
>> frontend"
>
> Again forgot to Cc stable?
I was just not sure if these minor fixes need to go the stable, but I will add
Thank you
>
>
> Juergen
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/6] xen/gntdev: Fix dmabuf import with non-zero sgt offset
From: Oleksandr Andrushchenko
It is possible that the scatter-gather table during dmabuf import has
non-zero offset of the data, but user-space doesn't expect that.
Fix this by failing the import, so user-space doesn't access wrong data.
Fixes: 37ccb44d0b00 ("xen/gntdev: Implement dma-buf import functionality")
Signed-off-by: Oleksandr Andrushchenko
---
drivers/xen/gntdev-dmabuf.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/xen/gntdev-dmabuf.c b/drivers/xen/gntdev-dmabuf.c
index 75d3bb948bf3..b1b6eebafd5d 100644
--- a/drivers/xen/gntdev-dmabuf.c
+++ b/drivers/xen/gntdev-dmabuf.c
@@ -613,6 +613,14 @@ dmabuf_imp_to_refs(struct gntdev_dmabuf_priv *priv, struct
device *dev,
goto fail_detach;
}
+ /* Check that we have zero offset. */
+ if (sgt->sgl->offset) {
+ ret = ERR_PTR(-EINVAL);
+ pr_debug("DMA buffer has %d bytes offset, user-space expects
0\n",
+sgt->sgl->offset);
+ goto fail_unmap;
+ }
+
/* Check number of pages that imported buffer has. */
if (attach->dmabuf->size != gntdev_dmabuf->nr_pages << PAGE_SHIFT) {
ret = ERR_PTR(-EINVAL);
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/6] drm/xen-front: Add support for EDID based configuration
From: Oleksandr Andrushchenko
Version 2 of the Xen displif protocol adds XENDISPL_OP_GET_EDID
request which allows frontends to request EDID structure per
connector. This request is optional and if not supported by the
backend then visible area is still defined by the relevant
XenStore's "resolution" property.
If backend provides EDID with XENDISPL_OP_GET_EDID request then
its values must take precedence over the resolutions defined in
XenStore.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/gpu/drm/xen/xen_drm_front.c | 62
drivers/gpu/drm/xen/xen_drm_front.h | 9 ++-
drivers/gpu/drm/xen/xen_drm_front_cfg.c | 82 +
drivers/gpu/drm/xen/xen_drm_front_cfg.h | 7 ++
drivers/gpu/drm/xen/xen_drm_front_conn.c| 26 ++-
drivers/gpu/drm/xen/xen_drm_front_evtchnl.c | 3 +
drivers/gpu/drm/xen/xen_drm_front_evtchnl.h | 3 +
drivers/gpu/drm/xen/xen_drm_front_kms.c | 5 ++
8 files changed, 194 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/xen/xen_drm_front.c
b/drivers/gpu/drm/xen/xen_drm_front.c
index 013c9e0e412c..cc5981bdbfb3 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.c
+++ b/drivers/gpu/drm/xen/xen_drm_front.c
@@ -381,6 +381,59 @@ void xen_drm_front_on_frame_done(struct xen_drm_front_info
*front_info,
fb_cookie);
}
+int xen_drm_front_get_edid(struct xen_drm_front_info *front_info,
+ int conn_idx, struct page **pages,
+ u32 buffer_sz, u32 *edid_sz)
+{
+ struct xen_drm_front_evtchnl *evtchnl;
+ struct xen_front_pgdir_shbuf_cfg buf_cfg;
+ struct xen_front_pgdir_shbuf shbuf;
+ struct xendispl_req *req;
+ unsigned long flags;
+ int ret;
+
+ if (unlikely(conn_idx >= front_info->num_evt_pairs))
+ return -EINVAL;
+
+ memset(_cfg, 0, sizeof(buf_cfg));
+ buf_cfg.xb_dev = front_info->xb_dev;
+ buf_cfg.num_pages = DIV_ROUND_UP(buffer_sz, PAGE_SIZE);
+ buf_cfg.pages = pages;
+ buf_cfg.pgdir =
+ buf_cfg.be_alloc = false;
+
+ ret = xen_front_pgdir_shbuf_alloc(_cfg);
+ if (ret < 0)
+ return ret;
+
+ evtchnl = _info->evt_pairs[conn_idx].req;
+
+ mutex_lock(>u.req.req_io_lock);
+
+ spin_lock_irqsave(_info->io_lock, flags);
+ req = be_prepare_req(evtchnl, XENDISPL_OP_GET_EDID);
+ req->op.get_edid.gref_directory =
+ xen_front_pgdir_shbuf_get_dir_start();
+ req->op.get_edid.buffer_sz = buffer_sz;
+
+ ret = be_stream_do_io(evtchnl, req);
+ spin_unlock_irqrestore(_info->io_lock, flags);
+
+ if (ret < 0)
+ goto fail;
+
+ ret = be_stream_wait_io(evtchnl);
+ if (ret < 0)
+ goto fail;
+
+ *edid_sz = evtchnl->u.req.resp.get_edid.edid_sz;
+
+fail:
+ mutex_unlock(>u.req.req_io_lock);
+ xen_front_pgdir_shbuf_free();
+ return ret;
+}
+
static int xen_drm_drv_dumb_create(struct drm_file *filp,
struct drm_device *dev,
struct drm_mode_create_dumb *args)
@@ -466,6 +519,7 @@ static void xen_drm_drv_release(struct drm_device *dev)
xenbus_switch_state(front_info->xb_dev,
XenbusStateInitialising);
+ xen_drm_front_cfg_free(front_info, _info->cfg);
kfree(drm_info);
}
@@ -562,6 +616,7 @@ static int xen_drm_drv_init(struct xen_drm_front_info
*front_info)
drm_mode_config_cleanup(drm_dev);
drm_dev_put(drm_dev);
fail:
+ xen_drm_front_cfg_free(front_info, _info->cfg);
kfree(drm_info);
return ret;
}
@@ -622,7 +677,14 @@ static int displback_initwait(struct xen_drm_front_info
*front_info)
static int displback_connect(struct xen_drm_front_info *front_info)
{
+ int ret;
+
xen_drm_front_evtchnl_set_state(front_info, EVTCHNL_STATE_CONNECTED);
+
+ /* We are all set to read additional configuration from the backend. */
+ ret = xen_drm_front_cfg_tail(front_info, _info->cfg);
+ if (ret < 0)
+ return ret;
return xen_drm_drv_init(front_info);
}
diff --git a/drivers/gpu/drm/xen/xen_drm_front.h
b/drivers/gpu/drm/xen/xen_drm_front.h
index 54486d89650e..be0c982f4d82 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.h
+++ b/drivers/gpu/drm/xen/xen_drm_front.h
@@ -112,9 +112,12 @@ struct xen_drm_front_drm_pipeline {
struct drm_simple_display_pipe pipe;
struct drm_connector conn;
- /* These are only for connector mode checking */
+ /* These are only for connector mode checking if no EDID present */
int width, height;
+ /* Is not NULL if EDID is used for connector configuration. */
+ struct edid *edid;
+
struct drm_pending_vblank_event *pending_event;
[Intel-gfx] [PATCH 0/6] Fixes and improvements for Xen pvdrm
From: Oleksandr Andrushchenko Hello, This series contains an assorted set of fixes and improvements for the Xen para-virtualized display driver and grant device driver which I have collected over the last couple of months: 1. Minor fixes to grant device driver and drm/xen-front. 2. New format (YUYV) added to the list of the PV DRM supported formats which allows the driver to be used in zero-copying use-cases when a camera device is the source of the dma-bufs. 3. Synchronization with the latest para-virtualized protocol definition in Xen [1]. 4. SGT offset is now propagated to the backend: while importing a dmabuf it is possible that the data of the buffer is put with offset which is indicated by the SGT offset. This is needed for some GPUs which have non-zero offset. 5. Version 2 of the Xen displif protocol adds XENDISPL_OP_GET_EDID request which allows frontends to request EDID structure per connector. This request is optional and if not supported by the backend then visible area is still defined by the relevant XenStore's "resolution" property. If backend provides EDID with XENDISPL_OP_GET_EDID request then its values must take precedence over the resolutions defined in XenStore. Thank you, Oleksandr Andrushchenko [1] https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=c27a184225eab54d20435c8cab5ad0ef384dc2c0 Oleksandr Andrushchenko (6): xen/gntdev: Fix dmabuf import with non-zero sgt offset drm/xen-front: Fix misused IS_ERR_OR_NULL checks drm/xen-front: Add YUYV to supported formats xen: Sync up with the canonical protocol definition in Xen drm/xen-front: Pass dumb buffer data offset to the backend drm/xen-front: Add support for EDID based configuration drivers/gpu/drm/xen/xen_drm_front.c | 72 +++- drivers/gpu/drm/xen/xen_drm_front.h | 11 ++- drivers/gpu/drm/xen/xen_drm_front_cfg.c | 82 +++ drivers/gpu/drm/xen/xen_drm_front_cfg.h | 7 ++ drivers/gpu/drm/xen/xen_drm_front_conn.c| 27 +- drivers/gpu/drm/xen/xen_drm_front_evtchnl.c | 3 + drivers/gpu/drm/xen/xen_drm_front_evtchnl.h | 3 + drivers/gpu/drm/xen/xen_drm_front_gem.c | 11 +-- drivers/gpu/drm/xen/xen_drm_front_kms.c | 7 +- drivers/xen/gntdev-dmabuf.c | 8 ++ include/xen/interface/io/displif.h | 91 - 11 files changed, 305 insertions(+), 17 deletions(-) -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/6] xen: Sync up with the canonical protocol definition in Xen
From: Oleksandr Andrushchenko
This is the sync up with the canonical definition of the
display protocol in Xen.
1. Add protocol version as an integer
Version string, which is in fact an integer, is hard to handle in the
code that supports different protocol versions. To simplify that
also add the version as an integer.
2. Pass buffer offset with XENDISPL_OP_DBUF_CREATE
There are cases when display data buffer is created with non-zero
offset to the data start. Handle such cases and provide that offset
while creating a display buffer.
3. Add XENDISPL_OP_GET_EDID command
Add an optional request for reading Extended Display Identification
Data (EDID) structure which allows better configuration of the
display connectors over the configuration set in XenStore.
With this change connectors may have multiple resolutions defined
with respect to detailed timing definitions and additional properties
normally provided by displays.
If this request is not supported by the backend then visible area
is defined by the relevant XenStore's "resolution" property.
If backend provides extended display identification data (EDID) with
XENDISPL_OP_GET_EDID request then EDID values must take precedence
over the resolutions defined in XenStore.
4. Bump protocol version to 2.
Signed-off-by: Oleksandr Andrushchenko
---
include/xen/interface/io/displif.h | 91 +-
1 file changed, 88 insertions(+), 3 deletions(-)
diff --git a/include/xen/interface/io/displif.h
b/include/xen/interface/io/displif.h
index fdc279dc4a88..c2d900186883 100644
--- a/include/xen/interface/io/displif.h
+++ b/include/xen/interface/io/displif.h
@@ -38,7 +38,8 @@
* Protocol version
**
*/
-#define XENDISPL_PROTOCOL_VERSION "1"
+#define XENDISPL_PROTOCOL_VERSION "2"
+#define XENDISPL_PROTOCOL_VERSION_INT 2
/*
**
@@ -202,6 +203,9 @@
* Width and height of the connector in pixels separated by
* XENDISPL_RESOLUTION_SEPARATOR. This defines visible area of the
* display.
+ * If backend provides extended display identification data (EDID) with
+ * XENDISPL_OP_GET_EDID request then EDID values must take precedence
+ * over the resolutions defined here.
*
*-- Connector Request Transport Parameters ---
*
@@ -349,6 +353,8 @@
#define XENDISPL_OP_FB_DETACH 0x13
#define XENDISPL_OP_SET_CONFIG 0x14
#define XENDISPL_OP_PG_FLIP0x15
+/* The below command is available in protocol version 2 and above. */
+#define XENDISPL_OP_GET_EDID 0x16
/*
**
@@ -377,6 +383,10 @@
#define XENDISPL_FIELD_BE_ALLOC"be-alloc"
#define XENDISPL_FIELD_UNIQUE_ID "unique-id"
+#define XENDISPL_EDID_BLOCK_SIZE 128
+#define XENDISPL_EDID_BLOCK_COUNT 256
+#define XENDISPL_EDID_MAX_SIZE (XENDISPL_EDID_BLOCK_SIZE *
XENDISPL_EDID_BLOCK_COUNT)
+
/*
**
* STATUS RETURN CODES
@@ -451,7 +461,9 @@
* +++++
* | gref_directory | 40
* +++++
- * | reserved | 44
+ * | data_ofs | 44
+ * +++++
+ * | reserved | 48
* +++++
* |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/|
* +++++
@@ -494,6 +506,7 @@
* buffer size (buffer_sz) exceeds what can be addressed by this single page,
* then reference to the next page must be supplied (see gref_dir_next_page
* below)
+ * data_ofs - uint32_t, offset of the data in the buffer, octets
*/
#define XENDISPL_DBUF_FLG_REQ_ALLOC(1 << 0)
@@ -506,6 +519,7 @@ struct xendispl_dbuf_create_req {
uint32_t buffer_sz;
uint32_t flags;
grant_ref_t gref_directory;
+ uint32_t data_ofs;
};
/*
@@ -731,6 +745,44 @@ struct xendispl_page_flip_req {
uint64_t fb_cookie;
};
+/*
+ * Request EDID - request EDID describing current connector:
+ * 01 2 3octet
+ * +++++
+ * |
[Intel-gfx] [PATCH 5/6] drm/xen-front: Pass dumb buffer data offset to the backend
From: Oleksandr Andrushchenko
While importing a dmabuf it is possible that the data of the buffer
is put with offset which is indicated by the SGT offset.
Respect the offset value and forward it to the backend.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/gpu/drm/xen/xen_drm_front.c | 6 --
drivers/gpu/drm/xen/xen_drm_front.h | 2 +-
drivers/gpu/drm/xen/xen_drm_front_gem.c | 3 ++-
3 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/xen/xen_drm_front.c
b/drivers/gpu/drm/xen/xen_drm_front.c
index 88db2726e8ce..013c9e0e412c 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.c
+++ b/drivers/gpu/drm/xen/xen_drm_front.c
@@ -157,7 +157,8 @@ int xen_drm_front_mode_set(struct
xen_drm_front_drm_pipeline *pipeline,
int xen_drm_front_dbuf_create(struct xen_drm_front_info *front_info,
u64 dbuf_cookie, u32 width, u32 height,
- u32 bpp, u64 size, struct page **pages)
+ u32 bpp, u64 size, u32 offset,
+ struct page **pages)
{
struct xen_drm_front_evtchnl *evtchnl;
struct xen_drm_front_dbuf *dbuf;
@@ -194,6 +195,7 @@ int xen_drm_front_dbuf_create(struct xen_drm_front_info
*front_info,
req->op.dbuf_create.gref_directory =
xen_front_pgdir_shbuf_get_dir_start(>shbuf);
req->op.dbuf_create.buffer_sz = size;
+ req->op.dbuf_create.data_ofs = offset;
req->op.dbuf_create.dbuf_cookie = dbuf_cookie;
req->op.dbuf_create.width = width;
req->op.dbuf_create.height = height;
@@ -408,7 +410,7 @@ static int xen_drm_drv_dumb_create(struct drm_file *filp,
ret = xen_drm_front_dbuf_create(drm_info->front_info,
xen_drm_front_dbuf_to_cookie(obj),
args->width, args->height, args->bpp,
- args->size,
+ args->size, 0,
xen_drm_front_gem_get_pages(obj));
if (ret)
goto fail_backend;
diff --git a/drivers/gpu/drm/xen/xen_drm_front.h
b/drivers/gpu/drm/xen/xen_drm_front.h
index f92c258350ca..54486d89650e 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.h
+++ b/drivers/gpu/drm/xen/xen_drm_front.h
@@ -145,7 +145,7 @@ int xen_drm_front_mode_set(struct
xen_drm_front_drm_pipeline *pipeline,
int xen_drm_front_dbuf_create(struct xen_drm_front_info *front_info,
u64 dbuf_cookie, u32 width, u32 height,
- u32 bpp, u64 size, struct page **pages);
+ u32 bpp, u64 size, u32 offset, struct page
**pages);
int xen_drm_front_fb_attach(struct xen_drm_front_info *front_info,
u64 dbuf_cookie, u64 fb_cookie, u32 width,
diff --git a/drivers/gpu/drm/xen/xen_drm_front_gem.c
b/drivers/gpu/drm/xen/xen_drm_front_gem.c
index 4ec8a49241e1..39ff95b75357 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_gem.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_gem.c
@@ -210,7 +210,8 @@ xen_drm_front_gem_import_sg_table(struct drm_device *dev,
ret = xen_drm_front_dbuf_create(drm_info->front_info,
xen_drm_front_dbuf_to_cookie(_obj->base),
- 0, 0, 0, size, xen_obj->pages);
+ 0, 0, 0, size, sgt->sgl->offset,
+ xen_obj->pages);
if (ret < 0)
return ERR_PTR(ret);
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/6] drm/xen-front: Fix misused IS_ERR_OR_NULL checks
From: Oleksandr Andrushchenko
The patch c575b7eeb89f: "drm/xen-front: Add support for Xen PV
display frontend" from Apr 3, 2018, leads to the following static
checker warning:
drivers/gpu/drm/xen/xen_drm_front_gem.c:140 xen_drm_front_gem_create()
warn: passing zero to 'ERR_CAST'
drivers/gpu/drm/xen/xen_drm_front_gem.c
133 struct drm_gem_object *xen_drm_front_gem_create(struct drm_device *dev,
134 size_t size)
135 {
136 struct xen_gem_object *xen_obj;
137
138 xen_obj = gem_create(dev, size);
139 if (IS_ERR_OR_NULL(xen_obj))
140 return ERR_CAST(xen_obj);
Fix this and the rest of misused places with IS_ERR_OR_NULL in the
driver.
Fixes: c575b7eeb89f: "drm/xen-front: Add support for Xen PV display frontend"
Signed-off-by: Oleksandr Andrushchenko
Reported-by: Dan Carpenter
---
drivers/gpu/drm/xen/xen_drm_front.c | 4 ++--
drivers/gpu/drm/xen/xen_drm_front_gem.c | 8
drivers/gpu/drm/xen/xen_drm_front_kms.c | 2 +-
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/xen/xen_drm_front.c
b/drivers/gpu/drm/xen/xen_drm_front.c
index 3e660fb111b3..88db2726e8ce 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.c
+++ b/drivers/gpu/drm/xen/xen_drm_front.c
@@ -400,8 +400,8 @@ static int xen_drm_drv_dumb_create(struct drm_file *filp,
args->size = args->pitch * args->height;
obj = xen_drm_front_gem_create(dev, args->size);
- if (IS_ERR_OR_NULL(obj)) {
- ret = PTR_ERR_OR_ZERO(obj);
+ if (IS_ERR(obj)) {
+ ret = PTR_ERR(obj);
goto fail;
}
diff --git a/drivers/gpu/drm/xen/xen_drm_front_gem.c
b/drivers/gpu/drm/xen/xen_drm_front_gem.c
index f0b85e094111..4ec8a49241e1 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_gem.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_gem.c
@@ -83,7 +83,7 @@ static struct xen_gem_object *gem_create(struct drm_device
*dev, size_t size)
size = round_up(size, PAGE_SIZE);
xen_obj = gem_create_obj(dev, size);
- if (IS_ERR_OR_NULL(xen_obj))
+ if (IS_ERR(xen_obj))
return xen_obj;
if (drm_info->front_info->cfg.be_alloc) {
@@ -117,7 +117,7 @@ static struct xen_gem_object *gem_create(struct drm_device
*dev, size_t size)
*/
xen_obj->num_pages = DIV_ROUND_UP(size, PAGE_SIZE);
xen_obj->pages = drm_gem_get_pages(_obj->base);
- if (IS_ERR_OR_NULL(xen_obj->pages)) {
+ if (IS_ERR(xen_obj->pages)) {
ret = PTR_ERR(xen_obj->pages);
xen_obj->pages = NULL;
goto fail;
@@ -136,7 +136,7 @@ struct drm_gem_object *xen_drm_front_gem_create(struct
drm_device *dev,
struct xen_gem_object *xen_obj;
xen_obj = gem_create(dev, size);
- if (IS_ERR_OR_NULL(xen_obj))
+ if (IS_ERR(xen_obj))
return ERR_CAST(xen_obj);
return _obj->base;
@@ -194,7 +194,7 @@ xen_drm_front_gem_import_sg_table(struct drm_device *dev,
size = attach->dmabuf->size;
xen_obj = gem_create_obj(dev, size);
- if (IS_ERR_OR_NULL(xen_obj))
+ if (IS_ERR(xen_obj))
return ERR_CAST(xen_obj);
ret = gem_alloc_pages_array(xen_obj, size);
diff --git a/drivers/gpu/drm/xen/xen_drm_front_kms.c
b/drivers/gpu/drm/xen/xen_drm_front_kms.c
index 78096bbcd226..ef11b1e4de39 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_kms.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_kms.c
@@ -60,7 +60,7 @@ fb_create(struct drm_device *dev, struct drm_file *filp,
int ret;
fb = drm_gem_fb_create_with_funcs(dev, filp, mode_cmd, _funcs);
- if (IS_ERR_OR_NULL(fb))
+ if (IS_ERR(fb))
return fb;
gem_obj = fb->obj[0];
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/6] drm/xen-front: Add YUYV to supported formats
From: Oleksandr Andrushchenko
Add YUYV to supported formats, so the frontend can work with the
formats used by cameras and other HW.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/gpu/drm/xen/xen_drm_front_conn.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/xen/xen_drm_front_conn.c
b/drivers/gpu/drm/xen/xen_drm_front_conn.c
index 459702fa990e..44f1f70c0aed 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_conn.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_conn.c
@@ -33,6 +33,7 @@ static const u32 plane_formats[] = {
DRM_FORMAT_ARGB,
DRM_FORMAT_XRGB1555,
DRM_FORMAT_ARGB1555,
+ DRM_FORMAT_YUYV,
};
const u32 *xen_drm_front_conn_get_formats(int *format_count)
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/52] drm: Set final_kfree in drm_dev_alloc
On 2/19/20 12:20 PM, Daniel Vetter wrote: > I also did a full review of all callers, and only the xen driver > forgot to call drm_dev_put in the failure path. Fix that up too. > > v2: I noticed that xen has a drm_driver.release hook, and uses > drm_dev_alloc(). We need to remove the kfree from > xen_drm_drv_release(). > > bochs also has a release hook, but leaked the drm_device ever since > > commit 0a6659bdc5e8221da99eebb176fd9591435e38de > Author: Gerd Hoffmann > Date: Tue Dec 17 18:04:46 2013 +0100 > > drm/bochs: new driver > > This patch here fixes that leak. > > Same for virtio, started leaking with > > commit b1df3a2b24a917f8853d43fe9683c0e360d2c33a > Author: Gerd Hoffmann > Date: Tue Feb 11 14:58:04 2020 +0100 > > drm/virtio: add drm_driver.release callback. > > Cc: Gerd Hoffmann > Cc: Oleksandr Andrushchenko > Cc: xen-de...@lists.xenproject.org > > Signed-off-by: Daniel Vetter Thank you, Reviewed-by: Oleksandr Andrushchenko > Cc: Maarten Lankhorst > Cc: Maxime Ripard > Cc: Thomas Zimmermann > Cc: David Airlie > Cc: Daniel Vetter > Cc: Oleksandr Andrushchenko > Cc: xen-de...@lists.xenproject.org > --- > drivers/gpu/drm/drm_drv.c | 3 +++ > drivers/gpu/drm/xen/xen_drm_front.c | 2 +- > 2 files changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c > index 3e5627d6eba6..9e62e28bbc62 100644 > --- a/drivers/gpu/drm/drm_drv.c > +++ b/drivers/gpu/drm/drm_drv.c > @@ -39,6 +39,7 @@ > #include > #include > #include > +#include > #include > #include > > @@ -819,6 +820,8 @@ struct drm_device *drm_dev_alloc(struct drm_driver > *driver, > return ERR_PTR(ret); > } > > + drmm_add_final_kfree(dev, dev); > + > return dev; > } > EXPORT_SYMBOL(drm_dev_alloc); > diff --git a/drivers/gpu/drm/xen/xen_drm_front.c > b/drivers/gpu/drm/xen/xen_drm_front.c > index 4be49c1aef51..d22b5da38935 100644 > --- a/drivers/gpu/drm/xen/xen_drm_front.c > +++ b/drivers/gpu/drm/xen/xen_drm_front.c > @@ -461,7 +461,6 @@ static void xen_drm_drv_release(struct drm_device *dev) > drm_mode_config_cleanup(dev); > > drm_dev_fini(dev); > - kfree(dev); > > if (front_info->cfg.be_alloc) > xenbus_switch_state(front_info->xb_dev, > @@ -561,6 +560,7 @@ static int xen_drm_drv_init(struct xen_drm_front_info > *front_info) > fail_modeset: > drm_kms_helper_poll_fini(drm_dev); > drm_mode_config_cleanup(drm_dev); > + drm_dev_put(drm_dev); > fail: > kfree(drm_info); > return ret; ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/8] drm/xen: Simplify fb_create
On 11/15/19 11:21 AM, Daniel Vetter wrote:
> The current code is a pretty good wtf moment, since we drop the
> reference before we use it. It's not a big deal, because a) we only
> use the pointer, so doesn't blow up and the real reason b) fb->obj[0]
> already holds a full reference for us.
>
> Might as well take the real pointer ins't of complicated games that
> baffle.
>
> Signed-off-by: Daniel Vetter
> Cc: Oleksandr Andrushchenko
> Cc: xen-de...@lists.xenproject.org
Reviewed-by: Oleksandr Andrushchenko
> ---
> drivers/gpu/drm/xen/xen_drm_front_kms.c | 9 +
> 1 file changed, 1 insertion(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/xen/xen_drm_front_kms.c
> b/drivers/gpu/drm/xen/xen_drm_front_kms.c
> index ff506bc99414..4f34c5208180 100644
> --- a/drivers/gpu/drm/xen/xen_drm_front_kms.c
> +++ b/drivers/gpu/drm/xen/xen_drm_front_kms.c
> @@ -63,14 +63,7 @@ fb_create(struct drm_device *dev, struct drm_file *filp,
> if (IS_ERR_OR_NULL(fb))
> return fb;
>
> - gem_obj = drm_gem_object_lookup(filp, mode_cmd->handles[0]);
> - if (!gem_obj) {
> - DRM_ERROR("Failed to lookup GEM object\n");
> - ret = -ENOENT;
> - goto fail;
> - }
> -
> - drm_gem_object_put_unlocked(gem_obj);
> + gem_obj = fb->obj[0];
>
> ret = xen_drm_front_fb_attach(drm_info->front_info,
> xen_drm_front_dbuf_to_cookie(gem_obj),
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Xen-devel] [PATCH 13/15] xen/gntdev-dmabuf: Ditch dummy map functions
On 11/18/19 12:35 PM, Daniel Vetter wrote:
There's no in-kernel users for the k(un)map stuff. And the mmap one is
actively harmful - return 0 and then _not_ actually mmaping can't end
well.
Signed-off-by: Daniel Vetter
Reviewed-by: Oleksandr Andrushchenko
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: xen-de...@lists.xenproject.org
--
Ack for merging this through drm trees very much appreciated.
-Daniel
---
drivers/xen/gntdev-dmabuf.c | 23 ---
1 file changed, 23 deletions(-)
diff --git a/drivers/xen/gntdev-dmabuf.c b/drivers/xen/gntdev-dmabuf.c
index 2c4f324f8626..fe7bd69d6955 100644
--- a/drivers/xen/gntdev-dmabuf.c
+++ b/drivers/xen/gntdev-dmabuf.c
@@ -342,35 +342,12 @@ static void dmabuf_exp_ops_release(struct dma_buf
*dma_buf)
mutex_unlock(>lock);
}
-static void *dmabuf_exp_ops_kmap(struct dma_buf *dma_buf,
-unsigned long page_num)
-{
- /* Not implemented. */
- return NULL;
-}
-
-static void dmabuf_exp_ops_kunmap(struct dma_buf *dma_buf,
- unsigned long page_num, void *addr)
-{
- /* Not implemented. */
-}
-
-static int dmabuf_exp_ops_mmap(struct dma_buf *dma_buf,
- struct vm_area_struct *vma)
-{
- /* Not implemented. */
- return 0;
-}
-
static const struct dma_buf_ops dmabuf_exp_ops = {
.attach = dmabuf_exp_ops_attach,
.detach = dmabuf_exp_ops_detach,
.map_dma_buf = dmabuf_exp_ops_map_dma_buf,
.unmap_dma_buf = dmabuf_exp_ops_unmap_dma_buf,
.release = dmabuf_exp_ops_release,
- .map = dmabuf_exp_ops_kmap,
- .unmap = dmabuf_exp_ops_kunmap,
- .mmap = dmabuf_exp_ops_mmap,
};
struct gntdev_dmabuf_export_args {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Xen-devel] [PATCH 38/59] drm/xen: Drop drm_gem_prime_export/import
On 6/14/19 11:35 PM, Daniel Vetter wrote:
They're the default.
Aside: Would be really nice to switch the others over to
drm_gem_object_funcs.
Signed-off-by: Daniel Vetter
Cc: Oleksandr Andrushchenko
Cc: xen-de...@lists.xenproject.org
Reviewed-by: Oleksandr Andrushchenko
---
drivers/gpu/drm/xen/xen_drm_front.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/xen/xen_drm_front.c
b/drivers/gpu/drm/xen/xen_drm_front.c
index aeffec82a5ce..051822ee5b36 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.c
+++ b/drivers/gpu/drm/xen/xen_drm_front.c
@@ -491,8 +491,6 @@ static struct drm_driver xen_drm_driver = {
.gem_free_object_unlocked = xen_drm_drv_free_object_unlocked,
.prime_handle_to_fd= drm_gem_prime_handle_to_fd,
.prime_fd_to_handle= drm_gem_prime_fd_to_handle,
- .gem_prime_import = drm_gem_prime_import,
- .gem_prime_export = drm_gem_prime_export,
.gem_prime_import_sg_table = xen_drm_front_gem_import_sg_table,
.gem_prime_get_sg_table= xen_drm_front_gem_get_sg_table,
.gem_prime_vmap= xen_drm_front_gem_prime_vmap,
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/2] drm/drv: drm_dev_unplug(): Move out drm_dev_put() call
On 2/8/19 4:01 PM, Noralf Trønnes wrote:
This makes it possible to use drm_dev_unplug() with the upcoming
devm_drm_dev_init() which will do drm_dev_put() in its release callback.
Cc: Alex Deucher
Cc: Christian König
Cc: David (ChunMing) Zhou
Cc: Dave Airlie
Cc: Sean Paul
Cc: Oleksandr Andrushchenko
Cc: Daniel Vetter
Signed-off-by: Noralf Trønnes
---
I will take this through drm-misc-next.
Noralf.
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 +
drivers/gpu/drm/drm_drv.c | 1 -
drivers/gpu/drm/udl/udl_drv.c | 1 +
drivers/gpu/drm/xen/xen_drm_front.c | 1 +
4 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index a1bb3773087b..d1f37ba3c118 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -971,6 +971,7 @@ amdgpu_pci_remove(struct pci_dev *pdev)
DRM_ERROR("Device removal is currently not supported outside of fbcon\n");
drm_dev_unplug(dev);
+ drm_dev_put(dev);
pci_disable_device(pdev);
pci_set_drvdata(pdev, NULL);
}
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 05bbc2b622fc..b04982101fcb 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -376,7 +376,6 @@ void drm_dev_unplug(struct drm_device *dev)
synchronize_srcu(_unplug_srcu);
drm_dev_unregister(dev);
- drm_dev_put(dev);
}
EXPORT_SYMBOL(drm_dev_unplug);
diff --git a/drivers/gpu/drm/udl/udl_drv.c b/drivers/gpu/drm/udl/udl_drv.c
index 22cd2d13e272..53b7b8c04bc6 100644
--- a/drivers/gpu/drm/udl/udl_drv.c
+++ b/drivers/gpu/drm/udl/udl_drv.c
@@ -107,6 +107,7 @@ static void udl_usb_disconnect(struct usb_interface
*interface)
udl_fbdev_unplug(dev);
udl_drop_usb(dev);
drm_dev_unplug(dev);
+ drm_dev_put(dev);
}
/*
diff --git a/drivers/gpu/drm/xen/xen_drm_front.c
b/drivers/gpu/drm/xen/xen_drm_front.c
index 3e78a832d7f9..84aa4d61dc42 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.c
+++ b/drivers/gpu/drm/xen/xen_drm_front.c
@@ -582,6 +582,7 @@ static void xen_drm_drv_fini(struct xen_drm_front_info
*front_info)
drm_kms_helper_poll_fini(dev);
drm_dev_unplug(dev);
+ drm_dev_put(dev);
Acked-by: Oleksandr Andrushchenko
front_info->drm_info = NULL;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/6] drm/drv: Remove drm_dev_unplug()
On 2/3/19 5:42 PM, Noralf Trønnes wrote:
> There are no users left.
>
> Signed-off-by: Noralf Trønnes
Reviewed-by: Oleksandr Andrushchenko
> ---
> drivers/gpu/drm/drm_drv.c | 17 -
> include/drm/drm_drv.h | 1 -
> 2 files changed, 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index e0941200edc6..87210d4a9e53 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -354,23 +354,6 @@ void drm_dev_exit(int idx)
> }
> EXPORT_SYMBOL(drm_dev_exit);
>
> -/**
> - * drm_dev_unplug - unplug a DRM device
> - * @dev: DRM device
> - *
> - * This unplugs a hotpluggable DRM device, which makes it inaccessible to
> - * userspace operations. Entry-points can use drm_dev_enter() and
> - * drm_dev_exit() to protect device resources in a race free manner. This
> - * essentially unregisters the device like drm_dev_unregister(), but can be
> - * called while there are still open users of @dev.
> - */
> -void drm_dev_unplug(struct drm_device *dev)
> -{
> - drm_dev_unregister(dev);
> - drm_dev_put(dev);
> -}
> -EXPORT_SYMBOL(drm_dev_unplug);
> -
> /*
>* DRM internal mount
>* We want to be able to allocate our own "struct address_space" to control
> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> index c50696c82a42..b8765a6fc092 100644
> --- a/include/drm/drm_drv.h
> +++ b/include/drm/drm_drv.h
> @@ -730,7 +730,6 @@ void drm_dev_put(struct drm_device *dev);
> void drm_put_dev(struct drm_device *dev);
> bool drm_dev_enter(struct drm_device *dev, int *idx);
> void drm_dev_exit(int idx);
> -void drm_dev_unplug(struct drm_device *dev);
>
> /**
>* drm_dev_is_unplugged - is a DRM device unplugged
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/6] drm/xen: Use drm_dev_unregister()
On 2/3/19 5:41 PM, Noralf Trønnes wrote: > drm_dev_unplug() has been stripped down and is going away. Open code its > 2 remaining function calls. > > Also remove the drm_dev_is_unplugged() check since this can't be true > before drm_dev_unregister() is called which happens after the check. > > Cc: Oleksandr Andrushchenko > Signed-off-by: Noralf Trønnes > --- > drivers/gpu/drm/xen/xen_drm_front.c | 7 ++- > 1 file changed, 2 insertions(+), 5 deletions(-) > > diff --git a/drivers/gpu/drm/xen/xen_drm_front.c > b/drivers/gpu/drm/xen/xen_drm_front.c > index 3e78a832d7f9..5c5eb24c6342 100644 > --- a/drivers/gpu/drm/xen/xen_drm_front.c > +++ b/drivers/gpu/drm/xen/xen_drm_front.c > @@ -576,12 +576,9 @@ static void xen_drm_drv_fini(struct xen_drm_front_info > *front_info) > if (!dev) > return; > > - /* Nothing to do if device is already unplugged */ > - if (drm_dev_is_unplugged(dev)) > - return; xen_drm_drv_fini is called when the backend changes its state [1], so I just use the check above to prevent possible race conditions here, e.g. do not allow to run unregister code if it is already in progress So, I think we should keep this and probably just add a comment why it is here > - > drm_kms_helper_poll_fini(dev); > - drm_dev_unplug(dev); > + drm_dev_unregister(dev); > + drm_dev_put(dev); > > front_info->drm_info = NULL; > [1] https://elixir.bootlin.com/linux/v5.0-rc5/ident/displback_disconnect ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/6] drm/drv: Prepare to remove drm_dev_unplug()
On 2/3/19 5:41 PM, Noralf Trønnes wrote:
> The only thing now that makes drm_dev_unplug() special is that it sets
> drm_device->unplugged. Move this code to drm_dev_unregister() so that we
> can remove drm_dev_unplug().
>
> Signed-off-by: Noralf Trønnes
Reviewed-by: Oleksandr Andrushchenko
> ---
>
> Maybe s/unplugged/unregistered/ ?
>
> I looked at drm_device->registered, but using that would mean that
> drm_dev_is_unplugged() would return before drm_device is registered.
> And given that its current purpose is to prevent race against connector
> registration, I stayed away from it.
>
> Noralf.
>
>
> drivers/gpu/drm/drm_drv.c | 27 +++
> include/drm/drm_drv.h | 10 --
> 2 files changed, 19 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 05bbc2b622fc..e0941200edc6 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -366,15 +366,6 @@ EXPORT_SYMBOL(drm_dev_exit);
>*/
> void drm_dev_unplug(struct drm_device *dev)
> {
> - /*
> - * After synchronizing any critical read section is guaranteed to see
> - * the new value of ->unplugged, and any critical section which might
> - * still have seen the old value of ->unplugged is guaranteed to have
> - * finished.
> - */
> - dev->unplugged = true;
> - synchronize_srcu(_unplug_srcu);
> -
> drm_dev_unregister(dev);
> drm_dev_put(dev);
> }
> @@ -832,11 +823,14 @@ EXPORT_SYMBOL(drm_dev_register);
>* drm_dev_register() but does not deallocate the device. The caller must
> call
>* drm_dev_put() to drop their final reference.
>*
> - * A special form of unregistering for hotpluggable devices is
> drm_dev_unplug(),
> - * which can be called while there are still open users of @dev.
> + * This function can be called while there are still open users of @dev as
> long
> + * as the driver protects its device resources using drm_dev_enter() and
> + * drm_dev_exit().
>*
>* This should be called first in the device teardown code to make sure
> - * userspace can't access the device instance any more.
> + * userspace can't access the device instance any more. Drivers that support
> + * device unplug will probably want to call drm_atomic_helper_shutdown()
> first
> + * in order to disable the hardware on regular driver module unload.
>*/
> void drm_dev_unregister(struct drm_device *dev)
> {
> @@ -845,6 +839,15 @@ void drm_dev_unregister(struct drm_device *dev)
> if (drm_core_check_feature(dev, DRIVER_LEGACY))
> drm_lastclose(dev);
>
> + /*
> + * After synchronizing any critical read section is guaranteed to see
> + * the new value of ->unplugged, and any critical section which might
> + * still have seen the old value of ->unplugged is guaranteed to have
> + * finished.
> + */
> + dev->unplugged = true;
> + synchronize_srcu(_unplug_srcu);
> +
> dev->registered = false;
>
> drm_client_dev_unregister(dev);
> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> index ca46a45a9cce..c50696c82a42 100644
> --- a/include/drm/drm_drv.h
> +++ b/include/drm/drm_drv.h
> @@ -736,13 +736,11 @@ void drm_dev_unplug(struct drm_device *dev);
>* drm_dev_is_unplugged - is a DRM device unplugged
>* @dev: DRM device
>*
> - * This function can be called to check whether a hotpluggable is unplugged.
> - * Unplugging itself is singalled through drm_dev_unplug(). If a device is
> - * unplugged, these two functions guarantee that any store before calling
> - * drm_dev_unplug() is visible to callers of this function after it completes
> + * This function can be called to check whether @dev is unregistered. This
> can
> + * be used to detect that the underlying parent device is gone.
>*
> - * WARNING: This function fundamentally races against drm_dev_unplug(). It is
> - * recommended that drivers instead use the underlying drm_dev_enter() and
> + * WARNING: This function fundamentally races against drm_dev_unregister().
> It
> + * is recommended that drivers instead use the underlying drm_dev_enter() and
>* drm_dev_exit() function pairs.
>*/
> static inline bool drm_dev_is_unplugged(struct drm_device *dev)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/6] drm: Fix drm_release() and device unplug
On 2/3/19 5:41 PM, Noralf Trønnes wrote:
> If userspace has open fd(s) when drm_dev_unplug() is run, it will result
> in drm_dev_unregister() being called twice. First in drm_dev_unplug() and
> then later in drm_release() through the call to drm_put_dev().
>
> Since userspace already holds a ref on drm_device through the drm_minor,
> it's not necessary to add extra ref counting based on no open file
> handles. Instead just drm_dev_put() unconditionally in drm_dev_unplug().
>
> We now has this:
s/has/have ?
> - Userpace holds a ref on drm_device as long as there's open fd(s)
> - The driver holds a ref on drm_device as long as it's bound to the
>struct device
>
> When both sides are done with drm_device, it is released.
>
> Signed-off-by: Noralf Trønnes
Reviewed-by: Oleksandr Andrushchenko
> ---
> drivers/gpu/drm/drm_drv.c | 6 +-
> drivers/gpu/drm/drm_file.c | 6 ++
> 2 files changed, 3 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 381581b01d48..05bbc2b622fc 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -376,11 +376,7 @@ void drm_dev_unplug(struct drm_device *dev)
> synchronize_srcu(_unplug_srcu);
>
> drm_dev_unregister(dev);
> -
> - mutex_lock(_global_mutex);
> - if (dev->open_count == 0)
> - drm_dev_put(dev);
> - mutex_unlock(_global_mutex);
> + drm_dev_put(dev);
> }
> EXPORT_SYMBOL(drm_dev_unplug);
>
> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> index 46f48f245eb5..3f20f598cd7c 100644
> --- a/drivers/gpu/drm/drm_file.c
> +++ b/drivers/gpu/drm/drm_file.c
> @@ -479,11 +479,9 @@ int drm_release(struct inode *inode, struct file *filp)
>
> drm_file_free(file_priv);
>
> - if (!--dev->open_count) {
> + if (!--dev->open_count)
> drm_lastclose(dev);
> - if (drm_dev_is_unplugged(dev))
> - drm_put_dev(dev);
> - }
> +
> mutex_unlock(_global_mutex);
>
> drm_minor_release(minor);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Split out drm_probe_helper.h
rs/gpu/drm/radeon/radeon_acpi.c | 1 + drivers/gpu/drm/radeon/radeon_connectors.c| 1 + drivers/gpu/drm/radeon/radeon_device.c| 1 + drivers/gpu/drm/radeon/radeon_display.c | 1 + drivers/gpu/drm/radeon/radeon_dp_mst.c| 1 + drivers/gpu/drm/radeon/radeon_drv.c | 1 + drivers/gpu/drm/radeon/radeon_irq_kms.c | 1 + drivers/gpu/drm/rcar-du/rcar_du_crtc.c| 2 +- drivers/gpu/drm/rcar-du/rcar_du_drv.c | 2 +- drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 2 +- drivers/gpu/drm/rcar-du/rcar_du_kms.c | 2 +- drivers/gpu/drm/rcar-du/rcar_du_plane.c | 2 +- drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 2 +- drivers/gpu/drm/rcar-du/rcar_lvds.c | 2 +- .../gpu/drm/rockchip/analogix_dp-rockchip.c | 2 +- drivers/gpu/drm/rockchip/cdn-dp-core.c| 2 +- drivers/gpu/drm/rockchip/cdn-dp-core.h| 2 +- drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 2 +- drivers/gpu/drm/rockchip/inno_hdmi.c | 2 +- drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 +- drivers/gpu/drm/rockchip/rockchip_drm_fb.c| 2 +- drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 2 +- drivers/gpu/drm/rockchip/rockchip_drm_psr.c | 2 +- drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 2 +- drivers/gpu/drm/rockchip/rockchip_lvds.c | 2 +- drivers/gpu/drm/rockchip/rockchip_rgb.c | 2 +- drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 1 + drivers/gpu/drm/shmobile/shmob_drm_drv.c | 1 + drivers/gpu/drm/shmobile/shmob_drm_kms.c | 1 + drivers/gpu/drm/sti/sti_crtc.c| 2 +- drivers/gpu/drm/sti/sti_drv.c | 2 +- drivers/gpu/drm/sti/sti_dvo.c | 2 +- drivers/gpu/drm/sti/sti_hda.c | 2 +- drivers/gpu/drm/sti/sti_hdmi.c| 2 +- drivers/gpu/drm/sti/sti_tvout.c | 2 +- drivers/gpu/drm/stm/drv.c | 2 +- drivers/gpu/drm/stm/ltdc.c| 2 +- drivers/gpu/drm/sun4i/sun4i_backend.c | 2 +- drivers/gpu/drm/sun4i/sun4i_crtc.c| 2 +- drivers/gpu/drm/sun4i/sun4i_drv.c | 2 +- drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c| 2 +- drivers/gpu/drm/sun4i/sun4i_lvds.c| 2 +- drivers/gpu/drm/sun4i/sun4i_rgb.c | 2 +- drivers/gpu/drm/sun4i/sun4i_tcon.c| 2 +- drivers/gpu/drm/sun4i/sun4i_tv.c | 2 +- drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c| 2 +- drivers/gpu/drm/sun4i/sun8i_mixer.c | 2 +- drivers/gpu/drm/sun4i/sun8i_ui_layer.c| 2 +- drivers/gpu/drm/sun4i/sun8i_vi_layer.c| 2 +- drivers/gpu/drm/tegra/drm.h | 2 +- drivers/gpu/drm/tegra/fb.c| 1 + drivers/gpu/drm/tegra/hdmi.c | 2 +- drivers/gpu/drm/tegra/hub.c | 2 +- drivers/gpu/drm/tilcdc/tilcdc_drv.c | 1 + drivers/gpu/drm/tilcdc/tilcdc_drv.h | 1 - drivers/gpu/drm/tilcdc/tilcdc_external.c | 1 + drivers/gpu/drm/tilcdc/tilcdc_panel.c | 1 + drivers/gpu/drm/tilcdc/tilcdc_tfp410.c| 1 + drivers/gpu/drm/tinydrm/core/tinydrm-core.c | 2 +- drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c | 2 +- drivers/gpu/drm/tve200/tve200_drv.c | 2 +- drivers/gpu/drm/udl/udl_connector.c | 1 + drivers/gpu/drm/udl/udl_drv.c | 1 + drivers/gpu/drm/udl/udl_main.c| 1 + drivers/gpu/drm/vc4/vc4_crtc.c| 2 +- drivers/gpu/drm/vc4/vc4_dpi.c | 2 +- drivers/gpu/drm/vc4/vc4_dsi.c | 2 +- drivers/gpu/drm/vc4/vc4_hdmi.c| 2 +- drivers/gpu/drm/vc4/vc4_kms.c | 2 +- drivers/gpu/drm/vc4/vc4_txp.c | 2 +- drivers/gpu/drm/vc4/vc4_vec.c | 2 +- drivers/gpu/drm/virtio/virtgpu_display.c | 2 +- drivers/gpu/drm/virtio/virtgpu_drv.h | 2 +- drivers/gpu/drm/vkms/vkms_crtc.c | 2 +- drivers/gpu/drm/vkms/vkms_drv.c | 2 +- drivers/gpu/drm/vkms/vkms_output.c| 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 2 +- drivers/gpu/drm/xen/xen_drm_front.c | 2 +- drivers/gpu/drm/xen/xen_drm_front_conn.c | 2 +- drivers/gpu/drm/xen/xen_drm_front_gem.c | 2 +- drivers/gpu/drm/xen/xen_drm_front_kms.c | 2 +- For Xen: Acked-by: Oleksandr Andrushchenko drivers/gpu/drm/zte/zx_drm_drv.c | 2 +- drivers/gpu/drm/zte/zx_hdmi.c | 2 +- drivers/gpu/drm/zte/zx_tvenc.c| 2 +- drivers/gpu/drm/zte/zx_vga.c | 2 +- drivers/gpu/drm/zte/zx_vou.c | 2 +- drivers/staging/vboxvideo/vbox_irq.c | 4 +- drivers/staging/vboxvideo/vbox_mode.c | 2 +- include/drm/drm_crtc_helper.h
Re: [Intel-gfx] [PATCH 6/7] drm/xen: Don't set the dpms hook
On 12/10/18 12:03 PM, Daniel Vetter wrote:
Doesn't do anything for atomic.
Signed-off-by: Daniel Vetter
Cc: Oleksandr Andrushchenko
Cc: xen-de...@lists.xen.org
---
drivers/gpu/drm/xen/xen_drm_front_conn.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/xen/xen_drm_front_conn.c
b/drivers/gpu/drm/xen/xen_drm_front_conn.c
index c91ae532fa55..54af2669b1b3 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_conn.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_conn.c
@@ -89,7 +89,6 @@ static const struct drm_connector_helper_funcs
connector_helper_funcs = {
};
static const struct drm_connector_funcs connector_funcs = {
- .dpms = drm_helper_connector_dpms,
.fill_modes = drm_helper_probe_single_connector_modes,
.destroy = drm_connector_cleanup,
.reset = drm_atomic_helper_connector_reset,
Reviewed-by: Oleksandr Andrushchenko
Thank you,
Oleksandr
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: build failure after merge of the drm-intel tree
On 05/08/2018 04:07 AM, Stephen Rothwell wrote:
Hi all,
After merging the drm-intel tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/gpu/drm/xen/xen_drm_front.c: In function 'xen_drv_probe':
drivers/gpu/drm/xen/xen_drm_front.c:740:10: error: 'struct bus_type' has no
member named 'force_dma'
dev->bus->force_dma = true;
^~
drivers/gpu/drm/xen/xen_drm_front.c:742:8: error: too few arguments to function
'of_dma_configure'
ret = of_dma_configure(dev, NULL);
^~~~
In file included from drivers/gpu/drm/xen/xen_drm_front.c:16:0:
include/linux/of_device.h:58:5: note: declared here
int of_dma_configure(struct device *dev,
^~~~
Caused by commit
c575b7eeb89f ("drm/xen-front: Add support for Xen PV display frontend")
interacting with commit
3d6ce86ee794 ("drivers: remove force dma flag from buses")
from the dma-mapping tree.
I have added the following merge fix patch:
From: Stephen Rothwell <s...@canb.auug.org.au>
Date: Tue, 8 May 2018 11:02:24 +1000
Subject: [PATCH] drm/xen-front: merge fix for "drivers: remove force dma flag from
buses"
Signed-off-by: Stephen Rothwell <s...@canb.auug.org.au>
Thank you,
Reviewed-by: Oleksandr Andrushchenko <oleksandr_andrushche...@epam.com>
---
drivers/gpu/drm/xen/xen_drm_front.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/xen/xen_drm_front.c
b/drivers/gpu/drm/xen/xen_drm_front.c
index 1b0ea9ac330e..0e486cb1c10c 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.c
+++ b/drivers/gpu/drm/xen/xen_drm_front.c
@@ -737,9 +737,8 @@ static int xen_drv_probe(struct xenbus_device *xb_dev,
* is not correct: to fix this call of_dma_configure() with a NULL
* node to set default DMA ops.
*/
- dev->bus->force_dma = true;
dev->coherent_dma_mask = DMA_BIT_MASK(32);
- ret = of_dma_configure(dev, NULL);
+ ret = of_dma_configure(dev, NULL, true);
if (ret < 0) {
DRM_ERROR("Cannot setup DMA ops, ret %d", ret);
return ret;
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Use srcu to protect drm_device.unplugged
On 03/28/2018 06:09 PM, Daniel Vetter wrote:
On Wed, Mar 28, 2018 at 10:38:35AM +0300, Oleksandr Andrushchenko wrote:
From: Noralf Trønnes <nor...@tronnes.org>
Use srcu to protect drm_device.unplugged in a race free manner.
Drivers can use drm_dev_enter()/drm_dev_exit() to protect and mark
sections preventing access to device resources that are not available
after the device is gone.
Suggested-by: Daniel Vetter <daniel.vet...@ffwll.ch>
Signed-off-by: Noralf Trønnes <nor...@tronnes.org>
Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushche...@epam.com>
Reviewed-by: Oleksandr Andrushchenko <oleksandr_andrushche...@epam.com>
Tested-by: Oleksandr Andrushchenko <oleksandr_andrushche...@epam.com>
Cc: intel-gfx@lists.freedesktop.org
Reviewed-by: Daniel Vetter <daniel.vet...@ffwll.ch>
Oleksandr, please push to drm-misc-next once you have dim tools setup up
and everything.
Pushed to drm-misc-next
Thanks, Daniel
Thank you,
Oleksandr
---
drivers/gpu/drm/drm_drv.c | 54 ++-
include/drm/drm_device.h | 9 +++-
include/drm/drm_drv.h | 15 +
3 files changed, 68 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index a1b9338736e3..32a83b41ab61 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
#include
@@ -75,6 +76,8 @@ static bool drm_core_init_complete = false;
static struct dentry *drm_debugfs_root;
+DEFINE_STATIC_SRCU(drm_unplug_srcu);
+
/*
* DRM Minors
* A DRM device can provide several char-dev interfaces on the DRM-Major. Each
@@ -318,18 +321,51 @@ void drm_put_dev(struct drm_device *dev)
}
EXPORT_SYMBOL(drm_put_dev);
-static void drm_device_set_unplugged(struct drm_device *dev)
+/**
+ * drm_dev_enter - Enter device critical section
+ * @dev: DRM device
+ * @idx: Pointer to index that will be passed to the matching drm_dev_exit()
+ *
+ * This function marks and protects the beginning of a section that should not
+ * be entered after the device has been unplugged. The section end is marked
+ * with drm_dev_exit(). Calls to this function can be nested.
+ *
+ * Returns:
+ * True if it is OK to enter the section, false otherwise.
+ */
+bool drm_dev_enter(struct drm_device *dev, int *idx)
+{
+ *idx = srcu_read_lock(_unplug_srcu);
+
+ if (dev->unplugged) {
+ srcu_read_unlock(_unplug_srcu, *idx);
+ return false;
+ }
+
+ return true;
+}
+EXPORT_SYMBOL(drm_dev_enter);
+
+/**
+ * drm_dev_exit - Exit device critical section
+ * @idx: index returned from drm_dev_enter()
+ *
+ * This function marks the end of a section that should not be entered after
+ * the device has been unplugged.
+ */
+void drm_dev_exit(int idx)
{
- smp_wmb();
- atomic_set(>unplugged, 1);
+ srcu_read_unlock(_unplug_srcu, idx);
}
+EXPORT_SYMBOL(drm_dev_exit);
/**
* drm_dev_unplug - unplug a DRM device
* @dev: DRM device
*
* This unplugs a hotpluggable DRM device, which makes it inaccessible to
- * userspace operations. Entry-points can use drm_dev_is_unplugged(). This
+ * userspace operations. Entry-points can use drm_dev_enter() and
+ * drm_dev_exit() to protect device resources in a race free manner. This
* essentially unregisters the device like drm_dev_unregister(), but can be
* called while there are still open users of @dev.
*/
@@ -338,10 +374,18 @@ void drm_dev_unplug(struct drm_device *dev)
drm_dev_unregister(dev);
mutex_lock(_global_mutex);
- drm_device_set_unplugged(dev);
if (dev->open_count == 0)
drm_dev_put(dev);
mutex_unlock(_global_mutex);
+
+ /*
+* After synchronizing any critical read section is guaranteed to see
+* the new value of ->unplugged, and any critical section which might
+* still have seen the old value of ->unplugged is guaranteed to have
+* finished.
+*/
+ dev->unplugged = true;
+ synchronize_srcu(_unplug_srcu);
}
EXPORT_SYMBOL(drm_dev_unplug);
diff --git a/include/drm/drm_device.h b/include/drm/drm_device.h
index 7c4fa32f3fc6..3a0eac2885b7 100644
--- a/include/drm/drm_device.h
+++ b/include/drm/drm_device.h
@@ -46,7 +46,14 @@ struct drm_device {
/* currently active master for this device. Protected by master_mutex */
struct drm_master *master;
- atomic_t unplugged; /**< Flag whether dev is dead */
+ /**
+* @unplugged:
+*
+* Flag to tell if the device has been unplugged.
+* See drm_dev_enter() and drm_dev_is_unplugged().
+*/
+ bool unplugged;
+
struct inode *anon_inode; /**< inode for private
address-space */
char *unique; /**< unique name of the device
[Intel-gfx] [PATCH] drm: Use srcu to protect drm_device.unplugged
From: Noralf Trønnes <nor...@tronnes.org>
Use srcu to protect drm_device.unplugged in a race free manner.
Drivers can use drm_dev_enter()/drm_dev_exit() to protect and mark
sections preventing access to device resources that are not available
after the device is gone.
Suggested-by: Daniel Vetter <daniel.vet...@ffwll.ch>
Signed-off-by: Noralf Trønnes <nor...@tronnes.org>
Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushche...@epam.com>
Reviewed-by: Oleksandr Andrushchenko <oleksandr_andrushche...@epam.com>
Tested-by: Oleksandr Andrushchenko <oleksandr_andrushche...@epam.com>
Cc: intel-gfx@lists.freedesktop.org
---
drivers/gpu/drm/drm_drv.c | 54 ++-
include/drm/drm_device.h | 9 +++-
include/drm/drm_drv.h | 15 +
3 files changed, 68 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index a1b9338736e3..32a83b41ab61 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
#include
@@ -75,6 +76,8 @@ static bool drm_core_init_complete = false;
static struct dentry *drm_debugfs_root;
+DEFINE_STATIC_SRCU(drm_unplug_srcu);
+
/*
* DRM Minors
* A DRM device can provide several char-dev interfaces on the DRM-Major. Each
@@ -318,18 +321,51 @@ void drm_put_dev(struct drm_device *dev)
}
EXPORT_SYMBOL(drm_put_dev);
-static void drm_device_set_unplugged(struct drm_device *dev)
+/**
+ * drm_dev_enter - Enter device critical section
+ * @dev: DRM device
+ * @idx: Pointer to index that will be passed to the matching drm_dev_exit()
+ *
+ * This function marks and protects the beginning of a section that should not
+ * be entered after the device has been unplugged. The section end is marked
+ * with drm_dev_exit(). Calls to this function can be nested.
+ *
+ * Returns:
+ * True if it is OK to enter the section, false otherwise.
+ */
+bool drm_dev_enter(struct drm_device *dev, int *idx)
+{
+ *idx = srcu_read_lock(_unplug_srcu);
+
+ if (dev->unplugged) {
+ srcu_read_unlock(_unplug_srcu, *idx);
+ return false;
+ }
+
+ return true;
+}
+EXPORT_SYMBOL(drm_dev_enter);
+
+/**
+ * drm_dev_exit - Exit device critical section
+ * @idx: index returned from drm_dev_enter()
+ *
+ * This function marks the end of a section that should not be entered after
+ * the device has been unplugged.
+ */
+void drm_dev_exit(int idx)
{
- smp_wmb();
- atomic_set(>unplugged, 1);
+ srcu_read_unlock(_unplug_srcu, idx);
}
+EXPORT_SYMBOL(drm_dev_exit);
/**
* drm_dev_unplug - unplug a DRM device
* @dev: DRM device
*
* This unplugs a hotpluggable DRM device, which makes it inaccessible to
- * userspace operations. Entry-points can use drm_dev_is_unplugged(). This
+ * userspace operations. Entry-points can use drm_dev_enter() and
+ * drm_dev_exit() to protect device resources in a race free manner. This
* essentially unregisters the device like drm_dev_unregister(), but can be
* called while there are still open users of @dev.
*/
@@ -338,10 +374,18 @@ void drm_dev_unplug(struct drm_device *dev)
drm_dev_unregister(dev);
mutex_lock(_global_mutex);
- drm_device_set_unplugged(dev);
if (dev->open_count == 0)
drm_dev_put(dev);
mutex_unlock(_global_mutex);
+
+ /*
+* After synchronizing any critical read section is guaranteed to see
+* the new value of ->unplugged, and any critical section which might
+* still have seen the old value of ->unplugged is guaranteed to have
+* finished.
+*/
+ dev->unplugged = true;
+ synchronize_srcu(_unplug_srcu);
}
EXPORT_SYMBOL(drm_dev_unplug);
diff --git a/include/drm/drm_device.h b/include/drm/drm_device.h
index 7c4fa32f3fc6..3a0eac2885b7 100644
--- a/include/drm/drm_device.h
+++ b/include/drm/drm_device.h
@@ -46,7 +46,14 @@ struct drm_device {
/* currently active master for this device. Protected by master_mutex */
struct drm_master *master;
- atomic_t unplugged; /**< Flag whether dev is dead */
+ /**
+* @unplugged:
+*
+* Flag to tell if the device has been unplugged.
+* See drm_dev_enter() and drm_dev_is_unplugged().
+*/
+ bool unplugged;
+
struct inode *anon_inode; /**< inode for private
address-space */
char *unique; /**< unique name of the device
*/
/*@} */
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index d23dcdd1bd95..7e545f5f94d3 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -624,6 +624,8 @@ void drm_dev_get(struct drm_device *dev);
void drm_dev_put(struct drm_device *dev);
void drm_dev_unref(struct drm_device *dev);
void drm_put_dev(stru
[Intel-gfx] [PATCH v4 1/2] drm: Use srcu to protect drm_device.unplugged
From: Noralf Trønnes <nor...@tronnes.org>
Use srcu to protect drm_device.unplugged in a race free manner.
Drivers can use drm_dev_enter()/drm_dev_exit() to protect and mark
sections preventing access to device resources that are not available
after the device is gone.
Suggested-by: Daniel Vetter <daniel.vet...@ffwll.ch>
Signed-off-by: Noralf Trønnes <nor...@tronnes.org>
Reviewed-by: Oleksandr Andrushchenko <oleksandr_andrushche...@epam.com>
Tested-by: Oleksandr Andrushchenko <oleksandr_andrushche...@epam.com>
Cc: intel-gfx@lists.freedesktop.org
---
drivers/gpu/drm/drm_drv.c | 54 ++-
include/drm/drm_device.h | 9 +++-
include/drm/drm_drv.h | 15 +
3 files changed, 68 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index a1b9338736e3..32a83b41ab61 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
#include
@@ -75,6 +76,8 @@ static bool drm_core_init_complete = false;
static struct dentry *drm_debugfs_root;
+DEFINE_STATIC_SRCU(drm_unplug_srcu);
+
/*
* DRM Minors
* A DRM device can provide several char-dev interfaces on the DRM-Major. Each
@@ -318,18 +321,51 @@ void drm_put_dev(struct drm_device *dev)
}
EXPORT_SYMBOL(drm_put_dev);
-static void drm_device_set_unplugged(struct drm_device *dev)
+/**
+ * drm_dev_enter - Enter device critical section
+ * @dev: DRM device
+ * @idx: Pointer to index that will be passed to the matching drm_dev_exit()
+ *
+ * This function marks and protects the beginning of a section that should not
+ * be entered after the device has been unplugged. The section end is marked
+ * with drm_dev_exit(). Calls to this function can be nested.
+ *
+ * Returns:
+ * True if it is OK to enter the section, false otherwise.
+ */
+bool drm_dev_enter(struct drm_device *dev, int *idx)
+{
+ *idx = srcu_read_lock(_unplug_srcu);
+
+ if (dev->unplugged) {
+ srcu_read_unlock(_unplug_srcu, *idx);
+ return false;
+ }
+
+ return true;
+}
+EXPORT_SYMBOL(drm_dev_enter);
+
+/**
+ * drm_dev_exit - Exit device critical section
+ * @idx: index returned from drm_dev_enter()
+ *
+ * This function marks the end of a section that should not be entered after
+ * the device has been unplugged.
+ */
+void drm_dev_exit(int idx)
{
- smp_wmb();
- atomic_set(>unplugged, 1);
+ srcu_read_unlock(_unplug_srcu, idx);
}
+EXPORT_SYMBOL(drm_dev_exit);
/**
* drm_dev_unplug - unplug a DRM device
* @dev: DRM device
*
* This unplugs a hotpluggable DRM device, which makes it inaccessible to
- * userspace operations. Entry-points can use drm_dev_is_unplugged(). This
+ * userspace operations. Entry-points can use drm_dev_enter() and
+ * drm_dev_exit() to protect device resources in a race free manner. This
* essentially unregisters the device like drm_dev_unregister(), but can be
* called while there are still open users of @dev.
*/
@@ -338,10 +374,18 @@ void drm_dev_unplug(struct drm_device *dev)
drm_dev_unregister(dev);
mutex_lock(_global_mutex);
- drm_device_set_unplugged(dev);
if (dev->open_count == 0)
drm_dev_put(dev);
mutex_unlock(_global_mutex);
+
+ /*
+* After synchronizing any critical read section is guaranteed to see
+* the new value of ->unplugged, and any critical section which might
+* still have seen the old value of ->unplugged is guaranteed to have
+* finished.
+*/
+ dev->unplugged = true;
+ synchronize_srcu(_unplug_srcu);
}
EXPORT_SYMBOL(drm_dev_unplug);
diff --git a/include/drm/drm_device.h b/include/drm/drm_device.h
index 7c4fa32f3fc6..3a0eac2885b7 100644
--- a/include/drm/drm_device.h
+++ b/include/drm/drm_device.h
@@ -46,7 +46,14 @@ struct drm_device {
/* currently active master for this device. Protected by master_mutex */
struct drm_master *master;
- atomic_t unplugged; /**< Flag whether dev is dead */
+ /**
+* @unplugged:
+*
+* Flag to tell if the device has been unplugged.
+* See drm_dev_enter() and drm_dev_is_unplugged().
+*/
+ bool unplugged;
+
struct inode *anon_inode; /**< inode for private
address-space */
char *unique; /**< unique name of the device
*/
/*@} */
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index d23dcdd1bd95..7e545f5f94d3 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -624,6 +624,8 @@ void drm_dev_get(struct drm_device *dev);
void drm_dev_put(struct drm_device *dev);
void drm_dev_unref(struct drm_device *dev);
void drm_put_dev(struct drm_device *dev);
+bool drm_dev_enter(struct drm_device *dev, int *idx);
