From: Oleksandr Andrushchenko oleksandr_andrushchenko@epam.com
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=c27a184225eab54d20435c8...
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(-)
From: Oleksandr Andrushchenko oleksandr_andrushchenko@epam.com
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 oleksandr_andrushchenko@epam.com Acked-by: Juergen Gross jgross@suse.com Cc: stable@vger.kernel.org --- 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);
From: Oleksandr Andrushchenko oleksandr_andrushchenko@epam.com
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 oleksandr_andrushchenko@epam.com Reported-by: Dan Carpenter dan.carpenter@oracle.com Reviewed-by: Dan Carpenter dan.carpenter@oracle.com Cc: stable@vger.kernel.org --- 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(&xen_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 &xen_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, &fb_funcs); - if (IS_ERR_OR_NULL(fb)) + if (IS_ERR(fb)) return fb;
gem_obj = fb->obj[0];
Hi
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag fixing commit: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display frontend").
The bot has tested the following trees: v5.8.1, v5.7.15, v5.4.58, v4.19.139.
v5.8.1: Build OK! v5.7.15: Build OK! v5.4.58: Failed to apply! Possible dependencies: 4c1cb04e0e7a ("drm/xen: fix passing zero to 'PTR_ERR' warning") 93adc0c2cb72 ("drm/xen: Simplify fb_create")
v4.19.139: Failed to apply! Possible dependencies: 4c1cb04e0e7a ("drm/xen: fix passing zero to 'PTR_ERR' warning") 93adc0c2cb72 ("drm/xen: Simplify fb_create")
NOTE: The patch will not be queued to stable trees until it is upstream.
How should we proceed with this patch?
Hi,
On 8/20/20 2:56 AM, Sasha Levin wrote:
Hi
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag fixing commit: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display frontend").
The bot has tested the following trees: v5.8.1, v5.7.15, v5.4.58, v4.19.139.
v5.8.1: Build OK! v5.7.15: Build OK! v5.4.58: Failed to apply! Possible dependencies: 4c1cb04e0e7a ("drm/xen: fix passing zero to 'PTR_ERR' warning") 93adc0c2cb72 ("drm/xen: Simplify fb_create")
v4.19.139: Failed to apply! Possible dependencies: 4c1cb04e0e7a ("drm/xen: fix passing zero to 'PTR_ERR' warning") 93adc0c2cb72 ("drm/xen: Simplify fb_create")
NOTE: The patch will not be queued to stable trees until it is upstream.
How should we proceed with this patch?
This is because of commit 4c1cb04e0e7ac4ba1ef5457929ef9b5671d9eed3
was not CCed to stable. So, if we want the patch to be applied to older stable
kernels we also need this patch as well.
Thank you,
Oleksandr
From: Oleksandr Andrushchenko oleksandr_andrushchenko@epam.com
Add YUYV to supported formats, so the frontend can work with the formats used by cameras and other HW.
Signed-off-by: Oleksandr Andrushchenko oleksandr_andrushchenko@epam.com Acked-by: Noralf Trønnes noralf@tronnes.org --- 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_ARGB4444, DRM_FORMAT_XRGB1555, DRM_FORMAT_ARGB1555, + DRM_FORMAT_YUYV, };
const u32 *xen_drm_front_conn_get_formats(int *format_count)
From: Oleksandr Andrushchenko oleksandr_andrushchenko@epam.com
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 oleksandr_andrushchenko@epam.com Reviewed-by: Juergen Gross jgross@suse.com --- 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_FLIP 0x15 +/* 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: + * 0 1 2 3 octet + * +----------------+----------------+----------------+----------------+ + * | id | _OP_GET_EDID | reserved | 4 + * +----------------+----------------+----------------+----------------+ + * | buffer_sz | 8 + * +----------------+----------------+----------------+----------------+ + * | gref_directory | 12 + * +----------------+----------------+----------------+----------------+ + * | reserved | 16 + * +----------------+----------------+----------------+----------------+ + * |//////////////////////////////////| + * +----------------+----------------+----------------+----------------+ + * | reserved | 64 + * +----------------+----------------+----------------+----------------+ + * + * Notes: + * - This command is not available in protocol version 1 and should be + * ignored. + * - This request is optional and if not supported then visible area + * is defined by the relevant XenStore's "resolution" property. + * - Shared buffer, allocated for EDID storage, must not be less then + * XENDISPL_EDID_MAX_SIZE octets. + * + * buffer_sz - uint32_t, buffer size to be allocated, octets + * gref_directory - grant_ref_t, a reference to the first shared page + * describing EDID buffer references. See XENDISPL_OP_DBUF_CREATE for + * grant page directory structure (struct xendispl_page_directory). + * + * See response format for this request. + */ + +struct xendispl_get_edid_req { + uint32_t buffer_sz; + grant_ref_t gref_directory; +}; + /* *---------------------------------- Responses -------------------------------- * @@ -753,6 +805,35 @@ struct xendispl_page_flip_req { * id - uint16_t, private guest value, echoed from request * status - int32_t, response status, zero on success and -XEN_EXX on failure * + * + * Get EDID response - response for XENDISPL_OP_GET_EDID: + * 0 1 2 3 octet + * +----------------+----------------+----------------+----------------+ + * | id | operation | reserved | 4 + * +----------------+----------------+----------------+----------------+ + * | status | 8 + * +----------------+----------------+----------------+----------------+ + * | edid_sz | 12 + * +----------------+----------------+----------------+----------------+ + * | reserved | 16 + * +----------------+----------------+----------------+----------------+ + * |//////////////////////////////////| + * +----------------+----------------+----------------+----------------+ + * | reserved | 64 + * +----------------+----------------+----------------+----------------+ + * + * Notes: + * - This response is not available in protocol version 1 and should be + * ignored. + * + * edid_sz - uint32_t, size of the EDID, octets + */ + +struct xendispl_get_edid_resp { + uint32_t edid_sz; +}; + +/* *----------------------------------- Events ---------------------------------- * * Events are sent via a shared page allocated by the front and propagated by @@ -804,6 +885,7 @@ struct xendispl_req { struct xendispl_fb_detach_req fb_detach; struct xendispl_set_config_req set_config; struct xendispl_page_flip_req pg_flip; + struct xendispl_get_edid_req get_edid; uint8_t reserved[56]; } op; }; @@ -813,7 +895,10 @@ struct xendispl_resp { uint8_t operation; uint8_t reserved; int32_t status; - uint8_t reserved1[56]; + union { + struct xendispl_get_edid_resp get_edid; + uint8_t reserved1[56]; + } op; };
struct xendispl_evt {
From: Oleksandr Andrushchenko oleksandr_andrushchenko@epam.com
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 oleksandr_andrushchenko@epam.com Acked-by: Noralf Trønnes noralf@tronnes.org --- 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(&dbuf->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(&xen_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);
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 oleksandr_andrushchenko@epam.com
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:
Minor fixes to grant device driver and drm/xen-front.
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.
- Synchronization with the latest para-virtualized protocol definition
in Xen [1].
- 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=comm... [xenbits[.]xen[.]org]
Changes since v1:
- 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.
- 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(-)
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.
Juergen
Thank you,
Oleksandr
On 8/13/20 9:21 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko oleksandr_andrushchenko@epam.com
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:
Minor fixes to grant device driver and drm/xen-front.
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.
- Synchronization with the latest para-virtualized protocol definition
in Xen [1].
- 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=comm... [xenbits[.]xen[.]org]
Changes since v1:
- 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.
- 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(-)
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 oleksandr_andrushchenko@epam.com
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:
Minor fixes to grant device driver and drm/xen-front.
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.
- Synchronization with the latest para-virtualized protocol definition
in Xen [1].
- 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=comm... [xenbits[.]xen[.]org]
Changes since v1:
- 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.
- 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(-)
On 13.08.20 08:21, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko oleksandr_andrushchenko@epam.com
Series pushed to:
xen/tip.git for-linus-5.9
Juergen
On 8/13/20 6:02 PM, Jürgen Groß wrote:
On 13.08.20 08:21, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko oleksandr_andrushchenko@epam.com
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
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 oleksandr_andrushchenko@epam.com
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.
Juergen
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 oleksandr_andrushchenko@epam.com
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
dri-devel@lists.freedesktop.org
-
Jürgen Groß -
Oleksandr Andrushchenko -
Oleksandr Andrushchenko -
Sasha Levin