[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Embedded-pv-devel] [PATCH] drmif: add ABI for para-virtual DRM/KMS
Hi Oleksandr, On 24/11/16 11:30, Oleksandr Andrushchenko wrote: This is the ABI for the two halves of a para-virtualized DRM/KMS driver. Signed-off-by: Oleksandr Andrushchenko <andr2000@xxxxxxxxx> Signed-off-by: Oleksandr Grytsov <al1img@xxxxxxxxx> --- include/xen/interface/io/drmif.h | 505 +++++++++++++++++++++++++++++++++ include/xen/interface/io/drmif_linux.h | 142 +++++++++ Same question as for sndif, any people who wants to use the PV driver for other OS than Linux will have to do it. So, may I ask why don't you write a platform agnostic header? [...] diff --git a/include/xen/interface/io/drmif_linux.h b/include/xen/interface/io/drmif_linux.h new file mode 100644 index 0000000..7244148 --- /dev/null +++ b/include/xen/interface/io/drmif_linux.h @@ -0,0 +1,142 @@ +/****************************************************************************** + * drmif_linux.h + * + * Unified DRM-device I/O interface for Xen guest OSes + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this software and associated documentation files (the "Software"), to + * deal in the Software without restriction, including without limitation the + * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or + * sell copies of the Software, and to permit persons to whom the Software is + * furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER + * DEALINGS IN THE SOFTWARE. + * + * Copyright (C) 2016 EPAM Systems Inc. + * + * Authors: Oleksandr Andrushchenko <andr2000@xxxxxxxxx> + * Oleksandr Grytsov <al1img@xxxxxxxxx> + */ + +#ifndef __XEN_PUBLIC_IO_XENSND_LINUX_H__ +#define __XEN_PUBLIC_IO_XENSND_LINUX_H__ + +#include <xen/interface/io/ring.h> +#include <xen/interface/io/drmif.h> +#include <xen/interface/grant_table.h> + +struct xendrm_dumb_create_req { + uint64_t dumb_cookie; If I am not mistaken, this field will not be aligned to 64-bit in the final structure (xendrm_req). Which means that you will do an unaligned access. At best the processor will do an unaligned access but slowly (some processors will do 2 memory access), at worst the kernel will crash if alignment check was enabled. So please re-order the field to avoid this drawbacks. + uint32_t width; + uint32_t height; + uint32_t bpp; + grant_ref_t gref_directory_start; +} __packed; + +struct xendrm_dumb_destroy_req { + uint64_t dumb_cookie; Ditto, although here it could be solved by adding a padding before hand. +} __packed; + +struct xendrm_fb_create_req { + uint64_t dumb_cookie; Ditto. + uint64_t fb_cookie; Ditto. + uint32_t width; + uint32_t height; + uint32_t pixel_format; +} __packed; + +struct xendrm_fb_destroy_req { + uint64_t fb_cookie; Ditto, although there it could be solved by adding a padding before hand. +} __packed; + +struct xendrm_set_config_req { + uint64_t fb_cookie; Ditto. + uint32_t x; + uint32_t y; + uint32_t width; + uint32_t height; + uint32_t bpp; +} __packed; Regards, -- Julien Grall _______________________________________________ Embedded-pv-devel mailing list Embedded-pv-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/cgi-bin/mailman/listinfo/embedded-pv-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |