[PATCH v4 03/79] drm.h: use __kernel_size_t instead of size_t

[PATCH v4 03/79] drm.h: use __kernel_size_t instead of size_t

[Mikko Rapeli]

Fall back to size_t for non Linux platforms.

Fixes userspace compilation error:

drm/drm.h:132:2: error: unknown type name ‘size_t’

Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
---
 include/uapi/drm/drm.h | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 3801584..b4e92eb 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -54,6 +54,7 @@ typedef int32_t  __s32;
 typedef uint32_t __u32;
 typedef int64_t  __s64;
 typedef uint64_t __u64;
+typedef size_t   __kernel_size_t;
 typedef unsigned long drm_handle_t;
 
 #endif
@@ -129,11 +130,11 @@ struct drm_version {
 	int version_major;	  /**< Major version */
 	int version_minor;	  /**< Minor version */
 	int version_patchlevel;	  /**< Patch level */
-	size_t name_len;	  /**< Length of name buffer */
+	__kernel_size_t name_len;	  /**< Length of name buffer */
 	char __user *name;	  /**< Name of driver */
-	size_t date_len;	  /**< Length of date buffer */
+	__kernel_size_t date_len;	  /**< Length of date buffer */
 	char __user *date;	  /**< User-space buffer to hold date */
-	size_t desc_len;	  /**< Length of desc buffer */
+	__kernel_size_t desc_len;	  /**< Length of desc buffer */
 	char __user *desc;	  /**< User-space buffer to hold desc */
 };
 
@@ -143,7 +144,7 @@ struct drm_version {
  * \sa drmGetBusid() and drmSetBusId().
  */
 struct drm_unique {
-	size_t unique_len;	  /**< Length of unique */
+	__kernel_size_t unique_len;	  /**< Length of unique */
 	char __user *unique;	  /**< Unique name for driver instantiation */
 };
 
-- 
2.5.0

[PATCH v4 04/79] drm_mode.h: use __u32 and __u64 from linux/types.h

[Mikko Rapeli]

Fixes userspace compilation error:

drm/drm_mode.h:472:2: error: unknown type name ‘uint32_t’

Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
---
 include/uapi/drm/drm_mode.h | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 359107a..0ed8d9d 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -508,14 +508,14 @@ struct drm_mode_crtc_page_flip {
 
 /* create a dumb scanout buffer */
 struct drm_mode_create_dumb {
-	uint32_t height;
-	uint32_t width;
-	uint32_t bpp;
-	uint32_t flags;
+	__u32 height;
+	__u32 width;
+	__u32 bpp;
+	__u32 flags;
 	/* handle, pitch, size will be returned */
-	uint32_t handle;
-	uint32_t pitch;
-	uint64_t size;
+	__u32 handle;
+	__u32 pitch;
+	__u64 size;
 };
 
 /* set up for mmap of a dumb scanout buffer */
@@ -532,7 +532,7 @@ struct drm_mode_map_dumb {
 };
 
 struct drm_mode_destroy_dumb {
-	uint32_t handle;
+	__u32 handle;
 };
 
 /* page-flip flags are valid, plus: */
-- 
2.5.0

[PATCH v4 05/79] exynos_drm.h: use __u64 from linux/types.h

[Mikko Rapeli]

Fixes userspace compilation error:

drm/exynos_drm.h:30:2: error: unknown type name ‘uint64_t’

Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
---
 include/uapi/drm/exynos_drm.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/uapi/drm/exynos_drm.h b/include/uapi/drm/exynos_drm.h
index 5575ed1..cf431b7 100644
--- a/include/uapi/drm/exynos_drm.h
+++ b/include/uapi/drm/exynos_drm.h
@@ -27,7 +27,7 @@
  *	- this handle will be set by gem module of kernel side.
  */
 struct drm_exynos_gem_create {
-	uint64_t size;
+	__u64 size;
 	unsigned int flags;
 	unsigned int handle;
 };
@@ -44,7 +44,7 @@ struct drm_exynos_gem_create {
 struct drm_exynos_gem_info {
 	unsigned int handle;
 	unsigned int flags;
-	uint64_t size;
+	__u64 size;
 };
 
 /**
@@ -58,7 +58,7 @@ struct drm_exynos_gem_info {
 struct drm_exynos_vidi_connection {
 	unsigned int connection;
 	unsigned int extensions;
-	uint64_t edid;
+	__u64 edid;
 };
 
 /* memory type definitions. */
-- 
2.5.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v4 06/79] nouveau_drm.h: use __u32 and __u64 from linux/types.h

[Mikko Rapeli]

Fixes userspace compilation errors like:

drm/nouveau_drm.h:41:2: error: unknown type name ‘uint32_t’

Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
---
 include/uapi/drm/nouveau_drm.h | 86 +++++++++++++++++++++---------------------
 1 file changed, 44 insertions(+), 42 deletions(-)

diff --git a/include/uapi/drm/nouveau_drm.h b/include/uapi/drm/nouveau_drm.h
index 5507eea..3a0a2f1 100644
--- a/include/uapi/drm/nouveau_drm.h
+++ b/include/uapi/drm/nouveau_drm.h
@@ -35,6 +35,8 @@
 #define NOUVEAU_ABI16_DEVICE   0xdddddddd
 #define NOUVEAU_ABI16_CHAN(n) (0xcccc0000 | (n))
 
+#include <drm/drm.h>
+
 #define NOUVEAU_GEM_DOMAIN_CPU       (1 << 0)
 #define NOUVEAU_GEM_DOMAIN_VRAM      (1 << 1)
 #define NOUVEAU_GEM_DOMAIN_GART      (1 << 2)
@@ -49,34 +51,34 @@
 #define NOUVEAU_GEM_TILE_NONCONTIG   0x00000008
 
 struct drm_nouveau_gem_info {
-	uint32_t handle;
-	uint32_t domain;
-	uint64_t size;
-	uint64_t offset;
-	uint64_t map_handle;
-	uint32_t tile_mode;
-	uint32_t tile_flags;
+	__u32 handle;
+	__u32 domain;
+	__u64 size;
+	__u64 offset;
+	__u64 map_handle;
+	__u32 tile_mode;
+	__u32 tile_flags;
 };
 
 struct drm_nouveau_gem_new {
 	struct drm_nouveau_gem_info info;
-	uint32_t channel_hint;
-	uint32_t align;
+	__u32 channel_hint;
+	__u32 align;
 };
 
 #define NOUVEAU_GEM_MAX_BUFFERS 1024
 struct drm_nouveau_gem_pushbuf_bo_presumed {
-	uint32_t valid;
-	uint32_t domain;
-	uint64_t offset;
+	__u32 valid;
+	__u32 domain;
+	__u64 offset;
 };
 
 struct drm_nouveau_gem_pushbuf_bo {
-	uint64_t user_priv;
-	uint32_t handle;
-	uint32_t read_domains;
-	uint32_t write_domains;
-	uint32_t valid_domains;
+	__u64 user_priv;
+	__u32 handle;
+	__u32 read_domains;
+	__u32 write_domains;
+	__u32 valid_domains;
 	struct drm_nouveau_gem_pushbuf_bo_presumed presumed;
 };
 
@@ -85,46 +87,46 @@ struct drm_nouveau_gem_pushbuf_bo {
 #define NOUVEAU_GEM_RELOC_OR   (1 << 2)
 #define NOUVEAU_GEM_MAX_RELOCS 1024
 struct drm_nouveau_gem_pushbuf_reloc {
-	uint32_t reloc_bo_index;
-	uint32_t reloc_bo_offset;
-	uint32_t bo_index;
-	uint32_t flags;
-	uint32_t data;
-	uint32_t vor;
-	uint32_t tor;
+	__u32 reloc_bo_index;
+	__u32 reloc_bo_offset;
+	__u32 bo_index;
+	__u32 flags;
+	__u32 data;
+	__u32 vor;
+	__u32 tor;
 };
 
 #define NOUVEAU_GEM_MAX_PUSH 512
 struct drm_nouveau_gem_pushbuf_push {
-	uint32_t bo_index;
-	uint32_t pad;
-	uint64_t offset;
-	uint64_t length;
+	__u32 bo_index;
+	__u32 pad;
+	__u64 offset;
+	__u64 length;
 };
 
 struct drm_nouveau_gem_pushbuf {
-	uint32_t channel;
-	uint32_t nr_buffers;
-	uint64_t buffers;
-	uint32_t nr_relocs;
-	uint32_t nr_push;
-	uint64_t relocs;
-	uint64_t push;
-	uint32_t suffix0;
-	uint32_t suffix1;
-	uint64_t vram_available;
-	uint64_t gart_available;
+	__u32 channel;
+	__u32 nr_buffers;
+	__u64 buffers;
+	__u32 nr_relocs;
+	__u32 nr_push;
+	__u64 relocs;
+	__u64 push;
+	__u32 suffix0;
+	__u32 suffix1;
+	__u64 vram_available;
+	__u64 gart_available;
 };
 
 #define NOUVEAU_GEM_CPU_PREP_NOWAIT                                  0x00000001
 #define NOUVEAU_GEM_CPU_PREP_WRITE                                   0x00000004
 struct drm_nouveau_gem_cpu_prep {
-	uint32_t handle;
-	uint32_t flags;
+	__u32 handle;
+	__u32 flags;
 };
 
 struct drm_nouveau_gem_cpu_fini {
-	uint32_t handle;
+	__u32 handle;
 };
 
 #define DRM_NOUVEAU_GETPARAM           0x00 /* deprecated */
-- 
2.5.0

[PATCH v4 07/79] radeon_drm.h: use __u32 and __u64 from linux/types.h

[Mikko Rapeli]

Fixes userspace compiler error:

drm/radeon_drm.h:794:2: error: unknown type name ‘uint64_t’

Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
---
 include/uapi/drm/radeon_drm.h | 128 +++++++++++++++++++++---------------------
 1 file changed, 64 insertions(+), 64 deletions(-)

diff --git a/include/uapi/drm/radeon_drm.h b/include/uapi/drm/radeon_drm.h
index 01aa2a8..ccb9bcd 100644
--- a/include/uapi/drm/radeon_drm.h
+++ b/include/uapi/drm/radeon_drm.h
@@ -793,9 +793,9 @@ typedef struct drm_radeon_surface_free {
 #define RADEON_GEM_DOMAIN_VRAM		0x4
 
 struct drm_radeon_gem_info {
-	uint64_t	gart_size;
-	uint64_t	vram_size;
-	uint64_t	vram_visible;
+	__u64	gart_size;
+	__u64	vram_size;
+	__u64	vram_visible;
 };
 
 #define RADEON_GEM_NO_BACKING_STORE	(1 << 0)
@@ -807,11 +807,11 @@ struct drm_radeon_gem_info {
 #define RADEON_GEM_NO_CPU_ACCESS	(1 << 4)
 
 struct drm_radeon_gem_create {
-	uint64_t	size;
-	uint64_t	alignment;
-	uint32_t	handle;
-	uint32_t	initial_domain;
-	uint32_t	flags;
+	__u64	size;
+	__u64	alignment;
+	__u32	handle;
+	__u32	initial_domain;
+	__u32	flags;
 };
 
 /*
@@ -825,10 +825,10 @@ struct drm_radeon_gem_create {
 #define RADEON_GEM_USERPTR_REGISTER	(1 << 3)
 
 struct drm_radeon_gem_userptr {
-	uint64_t		addr;
-	uint64_t		size;
-	uint32_t		flags;
-	uint32_t		handle;
+	__u64		addr;
+	__u64		size;
+	__u32		flags;
+	__u32		handle;
 };
 
 #define RADEON_TILING_MACRO				0x1
@@ -850,72 +850,72 @@ struct drm_radeon_gem_userptr {
 #define RADEON_TILING_EG_STENCIL_TILE_SPLIT_MASK	0xf
 
 struct drm_radeon_gem_set_tiling {
-	uint32_t	handle;
-	uint32_t	tiling_flags;
-	uint32_t	pitch;
+	__u32	handle;
+	__u32	tiling_flags;
+	__u32	pitch;
 };
 
 struct drm_radeon_gem_get_tiling {
-	uint32_t	handle;
-	uint32_t	tiling_flags;
-	uint32_t	pitch;
+	__u32	handle;
+	__u32	tiling_flags;
+	__u32	pitch;
 };
 
 struct drm_radeon_gem_mmap {
-	uint32_t	handle;
-	uint32_t	pad;
-	uint64_t	offset;
-	uint64_t	size;
-	uint64_t	addr_ptr;
+	__u32	handle;
+	__u32	pad;
+	__u64	offset;
+	__u64	size;
+	__u64	addr_ptr;
 };
 
 struct drm_radeon_gem_set_domain {
-	uint32_t	handle;
-	uint32_t	read_domains;
-	uint32_t	write_domain;
+	__u32	handle;
+	__u32	read_domains;
+	__u32	write_domain;
 };
 
 struct drm_radeon_gem_wait_idle {
-	uint32_t	handle;
-	uint32_t	pad;
+	__u32	handle;
+	__u32	pad;
 };
 
 struct drm_radeon_gem_busy {
-	uint32_t	handle;
-	uint32_t        domain;
+	__u32	handle;
+	__u32        domain;
 };
 
 struct drm_radeon_gem_pread {
 	/** Handle for the object being read. */
-	uint32_t handle;
-	uint32_t pad;
+	__u32 handle;
+	__u32 pad;
 	/** Offset into the object to read from */
-	uint64_t offset;
+	__u64 offset;
 	/** Length of data to read */
-	uint64_t size;
+	__u64 size;
 	/** Pointer to write the data into. */
 	/* void *, but pointers are not 32/64 compatible */
-	uint64_t data_ptr;
+	__u64 data_ptr;
 };
 
 struct drm_radeon_gem_pwrite {
 	/** Handle for the object being written to. */
-	uint32_t handle;
-	uint32_t pad;
+	__u32 handle;
+	__u32 pad;
 	/** Offset into the object to write to */
-	uint64_t offset;
+	__u64 offset;
 	/** Length of data to write */
-	uint64_t size;
+	__u64 size;
 	/** Pointer to read the data from. */
 	/* void *, but pointers are not 32/64 compatible */
-	uint64_t data_ptr;
+	__u64 data_ptr;
 };
 
 /* Sets or returns a value associated with a buffer. */
 struct drm_radeon_gem_op {
-	uint32_t	handle; /* buffer */
-	uint32_t	op;     /* RADEON_GEM_OP_* */
-	uint64_t	value;  /* input or return value */
+	__u32	handle; /* buffer */
+	__u32	op;     /* RADEON_GEM_OP_* */
+	__u64	value;  /* input or return value */
 };
 
 #define RADEON_GEM_OP_GET_INITIAL_DOMAIN	0
@@ -935,11 +935,11 @@ struct drm_radeon_gem_op {
 #define RADEON_VM_PAGE_SNOOPED		(1 << 4)
 
 struct drm_radeon_gem_va {
-	uint32_t		handle;
-	uint32_t		operation;
-	uint32_t		vm_id;
-	uint32_t		flags;
-	uint64_t		offset;
+	__u32		handle;
+	__u32		operation;
+	__u32		vm_id;
+	__u32		flags;
+	__u64		offset;
 };
 
 #define RADEON_CHUNK_ID_RELOCS	0x01
@@ -961,29 +961,29 @@ struct drm_radeon_gem_va {
 /* 0 = normal, + = higher priority, - = lower priority */
 
 struct drm_radeon_cs_chunk {
-	uint32_t		chunk_id;
-	uint32_t		length_dw;
-	uint64_t		chunk_data;
+	__u32		chunk_id;
+	__u32		length_dw;
+	__u64		chunk_data;
 };
 
 /* drm_radeon_cs_reloc.flags */
 #define RADEON_RELOC_PRIO_MASK		(0xf << 0)
 
 struct drm_radeon_cs_reloc {
-	uint32_t		handle;
-	uint32_t		read_domains;
-	uint32_t		write_domain;
-	uint32_t		flags;
+	__u32		handle;
+	__u32		read_domains;
+	__u32		write_domain;
+	__u32		flags;
 };
 
 struct drm_radeon_cs {
-	uint32_t		num_chunks;
-	uint32_t		cs_id;
-	/* this points to uint64_t * which point to cs chunks */
-	uint64_t		chunks;
+	__u32		num_chunks;
+	__u32		cs_id;
+	/* this points to __u64 * which point to cs chunks */
+	__u64		chunks;
 	/* updates to the limits after this CS ioctl */
-	uint64_t		gart_limit;
-	uint64_t		vram_limit;
+	__u64		gart_limit;
+	__u64		vram_limit;
 };
 
 #define RADEON_INFO_DEVICE_ID		0x00
@@ -1042,9 +1042,9 @@ struct drm_radeon_cs {
 #define RADEON_INFO_GPU_RESET_COUNTER	0x26
 
 struct drm_radeon_info {
-	uint32_t		request;
-	uint32_t		pad;
-	uint64_t		value;
+	__u32		request;
+	__u32		pad;
+	__u64		value;
 };
 
 /* Those correspond to the tile index to use, this is to explicitly state
-- 
2.5.0

[PATCH v4 08/79] r128_drm.h: include drm/drm.h

[Mikko Rapeli]

Fixes compile error:

drm/r128_drm.h:156:23: error: array type has incomplete element type
  struct drm_clip_rect boxes[R128_NR_SAREA_CLIPRECTS];

Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
---
 include/uapi/drm/r128_drm.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/uapi/drm/r128_drm.h b/include/uapi/drm/r128_drm.h
index 8d8878b..76b0aa3 100644
--- a/include/uapi/drm/r128_drm.h
+++ b/include/uapi/drm/r128_drm.h
@@ -33,6 +33,8 @@
 #ifndef __R128_DRM_H__
 #define __R128_DRM_H__
 
+#include <drm/drm.h>
+
 /* WARNING: If you change any of these defines, make sure to change the
  * defines in the X server file (r128_sarea.h)
  */
-- 
2.5.0

[PATCH v4 09/79] via_drm.h: don't include non-existing via_drmclient.h

[Mikko Rapeli]

Fixes compiler error:

drm/via_drm.h:36:27: fatal error: via_drmclient.h: No such file or directory

Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
---
 include/uapi/drm/via_drm.h | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/include/uapi/drm/via_drm.h b/include/uapi/drm/via_drm.h
index 8b0533c..d19c0e2 100644
--- a/include/uapi/drm/via_drm.h
+++ b/include/uapi/drm/via_drm.h
@@ -33,9 +33,6 @@
 #ifndef _VIA_DEFINES_
 #define _VIA_DEFINES_
 
-#ifndef __KERNEL__
-#include "via_drmclient.h"
-#endif
 
 #define VIA_NR_SAREA_CLIPRECTS		8
 #define VIA_NR_XVMC_PORTS               10
-- 
2.5.0

[PATCH v4 10/79] via_drm.h: move struct via_file_private definition to drivers/gpu/drm/via/via_drv.h

[Mikko Rapeli]

Fixes userspace compile error since list_head is not exported to userspace
headers.

Suggested by Emil Velikov <emil.l.velikov@gmail.com> at
https://lkml.org/lkml/2015/6/3/792

Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
---
 drivers/gpu/drm/via/via_drv.h | 4 ++++
 include/uapi/drm/via_drm.h    | 4 ----
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/via/via_drv.h b/drivers/gpu/drm/via/via_drv.h
index ef8c500..875e65a 100644
--- a/drivers/gpu/drm/via/via_drv.h
+++ b/drivers/gpu/drm/via/via_drv.h
@@ -102,6 +102,10 @@ typedef struct drm_via_private {
 	uint32_t dma_diff;
 } drm_via_private_t;
 
+struct via_file_private {
+	struct list_head obj_list;
+};
+
 enum via_family {
   VIA_OTHER = 0,     /* Baseline */
   VIA_PRO_GROUP_A,   /* Another video engine and DMA commands */
diff --git a/include/uapi/drm/via_drm.h b/include/uapi/drm/via_drm.h
index d19c0e2..c8c053a 100644
--- a/include/uapi/drm/via_drm.h
+++ b/include/uapi/drm/via_drm.h
@@ -271,8 +271,4 @@ typedef struct drm_via_dmablit {
 	drm_via_blitsync_t sync;
 } drm_via_dmablit_t;
 
-struct via_file_private {
-	struct list_head obj_list;
-};
-
 #endif				/* _VIA_DRM_H_ */
-- 
2.5.0

[PATCH v4 11/79] savage_drm.h: include <drm/drm.h>

[Mikko Rapeli]

Fixes compiler error:

drm/savage_drm.h:50:24: error: array type has incomplete element type
  struct drm_tex_region texList[SAVAGE_NR_TEX_HEAPS][SAVAGE_NR_TEX_REGIONS +

Signed-off-by: Mikko Rapeli <mikko.rapeli-X3B1VOXEql0@public.gmane.org>
---
 include/uapi/drm/savage_drm.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/uapi/drm/savage_drm.h b/include/uapi/drm/savage_drm.h
index 818d49b..9dc9dc1 100644
--- a/include/uapi/drm/savage_drm.h
+++ b/include/uapi/drm/savage_drm.h
@@ -26,6 +26,8 @@
 #ifndef __SAVAGE_DRM_H__
 #define __SAVAGE_DRM_H__
 
+#include <drm/drm.h>
+
 #ifndef __SAVAGE_SAREA_DEFINES__
 #define __SAVAGE_SAREA_DEFINES__
 
-- 
2.5.0

[PATCH v4 12/79] include/uapi/drm/sis_drm.h: move sis_file_private to drivers/gpu/drm/sis/sis_drv.h

[Mikko Rapeli]

Fixes userspace compile error:

drm/sis_drm.h:68:19: error: field ‘obj_list’ has incomplete type
  struct list_head obj_list;

Suggested by Emil Velikov <emil.l.velikov@gmail.com> at
https://lkml.org/lkml/2015/6/3/792

Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
---
 drivers/gpu/drm/sis/sis_drv.h | 4 ++++
 include/uapi/drm/sis_drm.h    | 4 ----
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/sis/sis_drv.h b/drivers/gpu/drm/sis/sis_drv.h
index 16f972b..328f8a7 100644
--- a/drivers/gpu/drm/sis/sis_drv.h
+++ b/drivers/gpu/drm/sis/sis_drv.h
@@ -67,6 +67,10 @@ typedef struct drm_sis_private {
 	struct idr object_idr;
 } drm_sis_private_t;
 
+struct sis_file_private {
+	struct list_head obj_list;
+};
+
 extern int sis_idle(struct drm_device *dev);
 extern void sis_reclaim_buffers_locked(struct drm_device *dev,
 				       struct drm_file *file_priv);
diff --git a/include/uapi/drm/sis_drm.h b/include/uapi/drm/sis_drm.h
index df37632..374858c 100644
--- a/include/uapi/drm/sis_drm.h
+++ b/include/uapi/drm/sis_drm.h
@@ -64,8 +64,4 @@ typedef struct {
 	unsigned long offset, size;
 } drm_sis_fb_t;
 
-struct sis_file_private {
-	struct list_head obj_list;
-};
-
 #endif				/* __SIS_DRM_H__ */
-- 
2.5.0

[PATCH v4 13/79] drm/i810_drm.h: include drm/drm.h

[Mikko Rapeli]

Fixes userspace compilation error:

error: array type has incomplete element type
struct drm_clip_rect boxes[I810_NR_SAREA_CLIPRECTS];

Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
---
 include/uapi/drm/i810_drm.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/uapi/drm/i810_drm.h b/include/uapi/drm/i810_drm.h
index 7a10bb6..34736ef 100644
--- a/include/uapi/drm/i810_drm.h
+++ b/include/uapi/drm/i810_drm.h
@@ -1,6 +1,8 @@
 #ifndef _I810_DRM_H_
 #define _I810_DRM_H_
 
+#include <drm/drm.h>
+
 /* WARNING: These defines must be the same as what the Xserver uses.
  * if you change them, you must change the defines in the Xserver.
  */
-- 
2.5.0

[PATCH v4 14/79] include/uapi/drm/vmwgfx_drm.h: use __s32, __u32 and __u64 from linux/types.h

[Mikko Rapeli]

Fixes userspace compilation errors like:

error: unknown type name ‘uint32_t’

Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
---
 include/uapi/drm/vmwgfx_drm.h | 264 +++++++++++++++++++++---------------------
 1 file changed, 132 insertions(+), 132 deletions(-)

diff --git a/include/uapi/drm/vmwgfx_drm.h b/include/uapi/drm/vmwgfx_drm.h
index 05b2049..ef31f44 100644
--- a/include/uapi/drm/vmwgfx_drm.h
+++ b/include/uapi/drm/vmwgfx_drm.h
@@ -111,9 +111,9 @@ enum drm_vmw_handle_type {
  */
 
 struct drm_vmw_getparam_arg {
-	uint64_t value;
-	uint32_t param;
-	uint32_t pad64;
+	__u64 value;
+	__u32 param;
+	__u32 pad64;
 };
 
 /*************************************************************************/
@@ -134,8 +134,8 @@ struct drm_vmw_getparam_arg {
  */
 
 struct drm_vmw_context_arg {
-	int32_t cid;
-	uint32_t pad64;
+	__s32 cid;
+	__u32 pad64;
 };
 
 /*************************************************************************/
@@ -165,7 +165,7 @@ struct drm_vmw_context_arg {
  * @mip_levels: Number of mip levels for each face.
  * An unused face should have 0 encoded.
  * @size_addr: Address of a user-space array of sruct drm_vmw_size
- * cast to an uint64_t for 32-64 bit compatibility.
+ * cast to an __u64 for 32-64 bit compatibility.
  * The size of the array should equal the total number of mipmap levels.
  * @shareable: Boolean whether other clients (as identified by file descriptors)
  * may reference this surface.
@@ -177,12 +177,12 @@ struct drm_vmw_context_arg {
  */
 
 struct drm_vmw_surface_create_req {
-	uint32_t flags;
-	uint32_t format;
-	uint32_t mip_levels[DRM_VMW_MAX_SURFACE_FACES];
-	uint64_t size_addr;
-	int32_t shareable;
-	int32_t scanout;
+	__u32 flags;
+	__u32 format;
+	__u32 mip_levels[DRM_VMW_MAX_SURFACE_FACES];
+	__u64 size_addr;
+	__s32 shareable;
+	__s32 scanout;
 };
 
 /**
@@ -197,7 +197,7 @@ struct drm_vmw_surface_create_req {
  */
 
 struct drm_vmw_surface_arg {
-	int32_t sid;
+	__s32 sid;
 	enum drm_vmw_handle_type handle_type;
 };
 
@@ -213,10 +213,10 @@ struct drm_vmw_surface_arg {
  */
 
 struct drm_vmw_size {
-	uint32_t width;
-	uint32_t height;
-	uint32_t depth;
-	uint32_t pad64;
+	__u32 width;
+	__u32 height;
+	__u32 depth;
+	__u32 pad64;
 };
 
 /**
@@ -284,13 +284,13 @@ union drm_vmw_surface_reference_arg {
 /**
  * struct drm_vmw_execbuf_arg
  *
- * @commands: User-space address of a command buffer cast to an uint64_t.
+ * @commands: User-space address of a command buffer cast to an __u64.
  * @command-size: Size in bytes of the command buffer.
  * @throttle-us: Sleep until software is less than @throttle_us
  * microseconds ahead of hardware. The driver may round this value
  * to the nearest kernel tick.
  * @fence_rep: User-space address of a struct drm_vmw_fence_rep cast to an
- * uint64_t.
+ * __u64.
  * @version: Allows expanding the execbuf ioctl parameters without breaking
  * backwards compatibility, since user-space will always tell the kernel
  * which version it uses.
@@ -302,14 +302,14 @@ union drm_vmw_surface_reference_arg {
 #define DRM_VMW_EXECBUF_VERSION 2
 
 struct drm_vmw_execbuf_arg {
-	uint64_t commands;
-	uint32_t command_size;
-	uint32_t throttle_us;
-	uint64_t fence_rep;
-	uint32_t version;
-	uint32_t flags;
-	uint32_t context_handle;
-	uint32_t pad64;
+	__u64 commands;
+	__u32 command_size;
+	__u32 throttle_us;
+	__u64 fence_rep;
+	__u32 version;
+	__u32 flags;
+	__u32 context_handle;
+	__u32 pad64;
 };
 
 /**
@@ -338,12 +338,12 @@ struct drm_vmw_execbuf_arg {
  */
 
 struct drm_vmw_fence_rep {
-	uint32_t handle;
-	uint32_t mask;
-	uint32_t seqno;
-	uint32_t passed_seqno;
-	uint32_t pad64;
-	int32_t error;
+	__u32 handle;
+	__u32 mask;
+	__u32 seqno;
+	__u32 passed_seqno;
+	__u32 pad64;
+	__s32 error;
 };
 
 /*************************************************************************/
@@ -373,8 +373,8 @@ struct drm_vmw_fence_rep {
  */
 
 struct drm_vmw_alloc_dmabuf_req {
-	uint32_t size;
-	uint32_t pad64;
+	__u32 size;
+	__u32 pad64;
 };
 
 /**
@@ -391,11 +391,11 @@ struct drm_vmw_alloc_dmabuf_req {
  */
 
 struct drm_vmw_dmabuf_rep {
-	uint64_t map_handle;
-	uint32_t handle;
-	uint32_t cur_gmr_id;
-	uint32_t cur_gmr_offset;
-	uint32_t pad64;
+	__u64 map_handle;
+	__u32 handle;
+	__u32 cur_gmr_id;
+	__u32 cur_gmr_offset;
+	__u32 pad64;
 };
 
 /**
@@ -428,8 +428,8 @@ union drm_vmw_alloc_dmabuf_arg {
  */
 
 struct drm_vmw_unref_dmabuf_arg {
-	uint32_t handle;
-	uint32_t pad64;
+	__u32 handle;
+	__u32 pad64;
 };
 
 /*************************************************************************/
@@ -452,10 +452,10 @@ struct drm_vmw_unref_dmabuf_arg {
  */
 
 struct drm_vmw_rect {
-	int32_t x;
-	int32_t y;
-	uint32_t w;
-	uint32_t h;
+	__s32 x;
+	__s32 y;
+	__u32 w;
+	__u32 h;
 };
 
 /**
@@ -477,21 +477,21 @@ struct drm_vmw_rect {
  */
 
 struct drm_vmw_control_stream_arg {
-	uint32_t stream_id;
-	uint32_t enabled;
+	__u32 stream_id;
+	__u32 enabled;
 
-	uint32_t flags;
-	uint32_t color_key;
+	__u32 flags;
+	__u32 color_key;
 
-	uint32_t handle;
-	uint32_t offset;
-	int32_t format;
-	uint32_t size;
-	uint32_t width;
-	uint32_t height;
-	uint32_t pitch[3];
+	__u32 handle;
+	__u32 offset;
+	__s32 format;
+	__u32 size;
+	__u32 width;
+	__u32 height;
+	__u32 pitch[3];
 
-	uint32_t pad64;
+	__u32 pad64;
 	struct drm_vmw_rect src;
 	struct drm_vmw_rect dst;
 };
@@ -519,12 +519,12 @@ struct drm_vmw_control_stream_arg {
  */
 
 struct drm_vmw_cursor_bypass_arg {
-	uint32_t flags;
-	uint32_t crtc_id;
-	int32_t xpos;
-	int32_t ypos;
-	int32_t xhot;
-	int32_t yhot;
+	__u32 flags;
+	__u32 crtc_id;
+	__s32 xpos;
+	__s32 ypos;
+	__s32 xhot;
+	__s32 yhot;
 };
 
 /*************************************************************************/
@@ -542,8 +542,8 @@ struct drm_vmw_cursor_bypass_arg {
  */
 
 struct drm_vmw_stream_arg {
-	uint32_t stream_id;
-	uint32_t pad64;
+	__u32 stream_id;
+	__u32 pad64;
 };
 
 /*************************************************************************/
@@ -565,7 +565,7 @@ struct drm_vmw_stream_arg {
 /**
  * struct drm_vmw_get_3d_cap_arg
  *
- * @buffer: Pointer to a buffer for capability data, cast to an uint64_t
+ * @buffer: Pointer to a buffer for capability data, cast to an __u64
  * @size: Max size to copy
  *
  * Input argument to the DRM_VMW_GET_3D_CAP_IOCTL
@@ -573,9 +573,9 @@ struct drm_vmw_stream_arg {
  */
 
 struct drm_vmw_get_3d_cap_arg {
-	uint64_t buffer;
-	uint32_t max_size;
-	uint32_t pad64;
+	__u64 buffer;
+	__u32 max_size;
+	__u32 pad64;
 };
 
 /*************************************************************************/
@@ -624,14 +624,14 @@ struct drm_vmw_get_3d_cap_arg {
  */
 
 struct drm_vmw_fence_wait_arg {
-	uint32_t handle;
-	int32_t  cookie_valid;
-	uint64_t kernel_cookie;
-	uint64_t timeout_us;
-	int32_t lazy;
-	int32_t flags;
-	int32_t wait_options;
-	int32_t pad64;
+	__u32 handle;
+	__s32  cookie_valid;
+	__u64 kernel_cookie;
+	__u64 timeout_us;
+	__s32 lazy;
+	__s32 flags;
+	__s32 wait_options;
+	__s32 pad64;
 };
 
 /*************************************************************************/
@@ -655,12 +655,12 @@ struct drm_vmw_fence_wait_arg {
  */
 
 struct drm_vmw_fence_signaled_arg {
-	 uint32_t handle;
-	 uint32_t flags;
-	 int32_t signaled;
-	 uint32_t passed_seqno;
-	 uint32_t signaled_flags;
-	 uint32_t pad64;
+	 __u32 handle;
+	 __u32 flags;
+	 __s32 signaled;
+	 __u32 passed_seqno;
+	 __u32 signaled_flags;
+	 __u32 pad64;
 };
 
 /*************************************************************************/
@@ -681,8 +681,8 @@ struct drm_vmw_fence_signaled_arg {
  */
 
 struct drm_vmw_fence_arg {
-	 uint32_t handle;
-	 uint32_t pad64;
+	 __u32 handle;
+	 __u32 pad64;
 };
 
 
@@ -703,9 +703,9 @@ struct drm_vmw_fence_arg {
 
 struct drm_vmw_event_fence {
 	struct drm_event base;
-	uint64_t user_data;
-	uint32_t tv_sec;
-	uint32_t tv_usec;
+	__u64 user_data;
+	__u32 tv_sec;
+	__u32 tv_usec;
 };
 
 /*
@@ -717,17 +717,17 @@ struct drm_vmw_event_fence {
 /**
  * struct drm_vmw_fence_event_arg
  *
- * @fence_rep: Pointer to fence_rep structure cast to uint64_t or 0 if
+ * @fence_rep: Pointer to fence_rep structure cast to __u64 or 0 if
  * the fence is not supposed to be referenced by user-space.
  * @user_info: Info to be delivered with the event.
  * @handle: Attach the event to this fence only.
  * @flags: A set of flags as defined above.
  */
 struct drm_vmw_fence_event_arg {
-	uint64_t fence_rep;
-	uint64_t user_data;
-	uint32_t handle;
-	uint32_t flags;
+	__u64 fence_rep;
+	__u64 user_data;
+	__u32 handle;
+	__u32 flags;
 };
 
 
@@ -747,7 +747,7 @@ struct drm_vmw_fence_event_arg {
  * @sid: Surface id to present from.
  * @dest_x: X placement coordinate for surface.
  * @dest_y: Y placement coordinate for surface.
- * @clips_ptr: Pointer to an array of clip rects cast to an uint64_t.
+ * @clips_ptr: Pointer to an array of clip rects cast to an __u64.
  * @num_clips: Number of cliprects given relative to the framebuffer origin,
  * in the same coordinate space as the frame buffer.
  * @pad64: Unused 64-bit padding.
@@ -756,13 +756,13 @@ struct drm_vmw_fence_event_arg {
  */
 
 struct drm_vmw_present_arg {
-	uint32_t fb_id;
-	uint32_t sid;
-	int32_t dest_x;
-	int32_t dest_y;
-	uint64_t clips_ptr;
-	uint32_t num_clips;
-	uint32_t pad64;
+	__u32 fb_id;
+	__u32 sid;
+	__s32 dest_x;
+	__s32 dest_y;
+	__u64 clips_ptr;
+	__u32 num_clips;
+	__u32 pad64;
 };
 
 
@@ -780,16 +780,16 @@ struct drm_vmw_present_arg {
  * struct drm_vmw_present_arg
  * @fb_id: fb_id to present / read back from.
  * @num_clips: Number of cliprects.
- * @clips_ptr: Pointer to an array of clip rects cast to an uint64_t.
- * @fence_rep: Pointer to a struct drm_vmw_fence_rep, cast to an uint64_t.
+ * @clips_ptr: Pointer to an array of clip rects cast to an __u64.
+ * @fence_rep: Pointer to a struct drm_vmw_fence_rep, cast to an __u64.
  * If this member is NULL, then the ioctl should not return a fence.
  */
 
 struct drm_vmw_present_readback_arg {
-	 uint32_t fb_id;
-	 uint32_t num_clips;
-	 uint64_t clips_ptr;
-	 uint64_t fence_rep;
+	 __u32 fb_id;
+	 __u32 num_clips;
+	 __u64 clips_ptr;
+	 __u64 fence_rep;
 };
 
 /*************************************************************************/
@@ -805,14 +805,14 @@ struct drm_vmw_present_readback_arg {
  * struct drm_vmw_update_layout_arg
  *
  * @num_outputs: number of active connectors
- * @rects: pointer to array of drm_vmw_rect cast to an uint64_t
+ * @rects: pointer to array of drm_vmw_rect cast to an __u64
  *
  * Input argument to the DRM_VMW_UPDATE_LAYOUT Ioctl.
  */
 struct drm_vmw_update_layout_arg {
-	uint32_t num_outputs;
-	uint32_t pad64;
-	uint64_t rects;
+	__u32 num_outputs;
+	__u32 pad64;
+	__u64 rects;
 };
 
 
@@ -849,10 +849,10 @@ enum drm_vmw_shader_type {
  */
 struct drm_vmw_shader_create_arg {
 	enum drm_vmw_shader_type shader_type;
-	uint32_t size;
-	uint32_t buffer_handle;
-	uint32_t shader_handle;
-	uint64_t offset;
+	__u32 size;
+	__u32 buffer_handle;
+	__u32 shader_handle;
+	__u64 offset;
 };
 
 /*************************************************************************/
@@ -871,8 +871,8 @@ struct drm_vmw_shader_create_arg {
  * Input argument to the DRM_VMW_UNREF_SHADER ioctl.
  */
 struct drm_vmw_shader_arg {
-	uint32_t handle;
-	uint32_t pad64;
+	__u32 handle;
+	__u32 pad64;
 };
 
 /*************************************************************************/
@@ -918,14 +918,14 @@ enum drm_vmw_surface_flags {
  * Part of output argument for the DRM_VMW_GB_SURFACE_REF Ioctl.
  */
 struct drm_vmw_gb_surface_create_req {
-	uint32_t svga3d_flags;
-	uint32_t format;
-	uint32_t mip_levels;
+	__u32 svga3d_flags;
+	__u32 format;
+	__u32 mip_levels;
 	enum drm_vmw_surface_flags drm_surface_flags;
-	uint32_t multisample_count;
-	uint32_t autogen_filter;
-	uint32_t buffer_handle;
-	uint32_t array_size;
+	__u32 multisample_count;
+	__u32 autogen_filter;
+	__u32 buffer_handle;
+	__u32 array_size;
 	struct drm_vmw_size base_size;
 };
 
@@ -944,11 +944,11 @@ struct drm_vmw_gb_surface_create_req {
  * Output argument for the DRM_VMW_GB_SURFACE_CREATE ioctl.
  */
 struct drm_vmw_gb_surface_create_rep {
-	uint32_t handle;
-	uint32_t backup_size;
-	uint32_t buffer_handle;
-	uint32_t buffer_size;
-	uint64_t buffer_map_handle;
+	__u32 handle;
+	__u32 backup_size;
+	__u32 buffer_handle;
+	__u32 buffer_size;
+	__u64 buffer_map_handle;
 };
 
 /**
@@ -1061,8 +1061,8 @@ enum drm_vmw_synccpu_op {
 struct drm_vmw_synccpu_arg {
 	enum drm_vmw_synccpu_op op;
 	enum drm_vmw_synccpu_flags flags;
-	uint32_t handle;
-	uint32_t pad64;
+	__u32 handle;
+	__u32 pad64;
 };
 
 /*************************************************************************/
-- 
2.5.0

[PATCH v4 15/79] include/uapi/drm/qxl_drm.h: use __s32, __u32 and __u64 from linux/types.h

[Mikko Rapeli]

Fixes userspace compilation errors like:

error: unknown type name ‘uint32_t’

Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
---
 include/uapi/drm/qxl_drm.h | 74 +++++++++++++++++++++++-----------------------
 1 file changed, 37 insertions(+), 37 deletions(-)

diff --git a/include/uapi/drm/qxl_drm.h b/include/uapi/drm/qxl_drm.h
index ebebd36..dface36 100644
--- a/include/uapi/drm/qxl_drm.h
+++ b/include/uapi/drm/qxl_drm.h
@@ -30,7 +30,7 @@
 /* Please note that modifications to all structs defined here are
  * subject to backwards-compatibility constraints.
  *
- * Do not use pointers, use uint64_t instead for 32 bit / 64 bit user/kernel
+ * Do not use pointers, use __u64 instead for 32 bit / 64 bit user/kernel
  * compatibility Keep fields aligned to their size
  */
 
@@ -48,14 +48,14 @@
 #define DRM_QXL_ALLOC_SURF  0x06
 
 struct drm_qxl_alloc {
-	uint32_t size;
-	uint32_t handle; /* 0 is an invalid handle */
+	__u32 size;
+	__u32 handle; /* 0 is an invalid handle */
 };
 
 struct drm_qxl_map {
-	uint64_t offset; /* use for mmap system call */
-	uint32_t handle;
-	uint32_t pad;
+	__u64 offset; /* use for mmap system call */
+	__u32 handle;
+	__u32 pad;
 };
 
 /*
@@ -68,59 +68,59 @@ struct drm_qxl_map {
 #define QXL_RELOC_TYPE_SURF 2
 
 struct drm_qxl_reloc {
-	uint64_t src_offset; /* offset into src_handle or src buffer */
-	uint64_t dst_offset; /* offset in dest handle */
-	uint32_t src_handle; /* dest handle to compute address from */
-	uint32_t dst_handle; /* 0 if to command buffer */
-	uint32_t reloc_type;
-	uint32_t pad;
+	__u64 src_offset; /* offset into src_handle or src buffer */
+	__u64 dst_offset; /* offset in dest handle */
+	__u32 src_handle; /* dest handle to compute address from */
+	__u32 dst_handle; /* 0 if to command buffer */
+	__u32 reloc_type;
+	__u32 pad;
 };
 
 struct drm_qxl_command {
-	uint64_t	 __user command; /* void* */
-	uint64_t	 __user relocs; /* struct drm_qxl_reloc* */
-	uint32_t		type;
-	uint32_t		command_size;
-	uint32_t		relocs_num;
-	uint32_t                pad;
+	__u64	 __user command; /* void* */
+	__u64	 __user relocs; /* struct drm_qxl_reloc* */
+	__u32		type;
+	__u32		command_size;
+	__u32		relocs_num;
+	__u32                pad;
 };
 
 /* XXX: call it drm_qxl_commands? */
 struct drm_qxl_execbuffer {
-	uint32_t		flags;		/* for future use */
-	uint32_t		commands_num;
-	uint64_t	 __user commands;	/* struct drm_qxl_command* */
+	__u32		flags;		/* for future use */
+	__u32		commands_num;
+	__u64	 __user commands;	/* struct drm_qxl_command* */
 };
 
 struct drm_qxl_update_area {
-	uint32_t handle;
-	uint32_t top;
-	uint32_t left;
-	uint32_t bottom;
-	uint32_t right;
-	uint32_t pad;
+	__u32 handle;
+	__u32 top;
+	__u32 left;
+	__u32 bottom;
+	__u32 right;
+	__u32 pad;
 };
 
 #define QXL_PARAM_NUM_SURFACES 1 /* rom->n_surfaces */
 #define QXL_PARAM_MAX_RELOCS 2
 struct drm_qxl_getparam {
-	uint64_t param;
-	uint64_t value;
+	__u64 param;
+	__u64 value;
 };
 
 /* these are one bit values */
 struct drm_qxl_clientcap {
-	uint32_t index;
-	uint32_t pad;
+	__u32 index;
+	__u32 pad;
 };
 
 struct drm_qxl_alloc_surf {
-	uint32_t format;
-	uint32_t width;
-	uint32_t height;
-	int32_t stride;
-	uint32_t handle;
-	uint32_t pad;
+	__u32 format;
+	__u32 width;
+	__u32 height;
+	__s32 stride;
+	__u32 handle;
+	__u32 pad;
 };
 
 #define DRM_IOCTL_QXL_ALLOC \
-- 
2.5.0

Re: [PATCH v4 11/79] savage_drm.h: include <drm/drm.h>

[Daniel Vetter]

On Thu, Oct 15, 2015 at 07:55:49AM +0200, Mikko Rapeli wrote:
> Fixes compiler error:
> 
> drm/savage_drm.h:50:24: error: array type has incomplete element type
>   struct drm_tex_region texList[SAVAGE_NR_TEX_HEAPS][SAVAGE_NR_TEX_REGIONS +
> 
> Signed-off-by: Mikko Rapeli <mikko.rapeli-X3B1VOXEql0@public.gmane.org>

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

> ---
>  include/uapi/drm/savage_drm.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/include/uapi/drm/savage_drm.h b/include/uapi/drm/savage_drm.h
> index 818d49b..9dc9dc1 100644
> --- a/include/uapi/drm/savage_drm.h
> +++ b/include/uapi/drm/savage_drm.h
> @@ -26,6 +26,8 @@
>  #ifndef __SAVAGE_DRM_H__
>  #define __SAVAGE_DRM_H__
>  
> +#include <drm/drm.h>
> +
>  #ifndef __SAVAGE_SAREA_DEFINES__
>  #define __SAVAGE_SAREA_DEFINES__
>  
> -- 
> 2.5.0
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [PATCH v4 08/79] r128_drm.h: include drm/drm.h

[Daniel Vetter]

On Thu, Oct 15, 2015 at 07:55:46AM +0200, Mikko Rapeli wrote:
> Fixes compile error:
> 
> drm/r128_drm.h:156:23: error: array type has incomplete element type
>   struct drm_clip_rect boxes[R128_NR_SAREA_CLIPRECTS];
> 
> Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>

Applied to drm-misc, thanks.
-Daniel

> ---
>  include/uapi/drm/r128_drm.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/include/uapi/drm/r128_drm.h b/include/uapi/drm/r128_drm.h
> index 8d8878b..76b0aa3 100644
> --- a/include/uapi/drm/r128_drm.h
> +++ b/include/uapi/drm/r128_drm.h
> @@ -33,6 +33,8 @@
>  #ifndef __R128_DRM_H__
>  #define __R128_DRM_H__
>  
> +#include <drm/drm.h>
> +
>  /* WARNING: If you change any of these defines, make sure to change the
>   * defines in the X server file (r128_sarea.h)
>   */
> -- 
> 2.5.0
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 13/79] drm/i810_drm.h: include drm/drm.h

[Daniel Vetter]

On Thu, Oct 15, 2015 at 07:55:51AM +0200, Mikko Rapeli wrote:
> Fixes userspace compilation error:
> 
> error: array type has incomplete element type
> struct drm_clip_rect boxes[I810_NR_SAREA_CLIPRECTS];
> 
> Signed-off-by: Mikko Rapeli <mikko.rapeli-X3B1VOXEql0@public.gmane.org>

Applied to drm-misc, thanks.
-Daniel

> ---
>  include/uapi/drm/i810_drm.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/include/uapi/drm/i810_drm.h b/include/uapi/drm/i810_drm.h
> index 7a10bb6..34736ef 100644
> --- a/include/uapi/drm/i810_drm.h
> +++ b/include/uapi/drm/i810_drm.h
> @@ -1,6 +1,8 @@
>  #ifndef _I810_DRM_H_
>  #define _I810_DRM_H_
>  
> +#include <drm/drm.h>
> +
>  /* WARNING: These defines must be the same as what the Xserver uses.
>   * if you change them, you must change the defines in the Xserver.
>   */
> -- 
> 2.5.0
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [PATCH v4 04/79] drm_mode.h: use __u32 and __u64 from linux/types.h

[Alex Deucher]

On Thu, Oct 15, 2015 at 1:55 AM, Mikko Rapeli <mikko.rapeli-X3B1VOXEql0@public.gmane.org> wrote:
> Fixes userspace compilation error:
>
> drm/drm_mode.h:472:2: error: unknown type name ‘uint32_t’
>
> Signed-off-by: Mikko Rapeli <mikko.rapeli-X3B1VOXEql0@public.gmane.org>

NACK on all these type conversions.  This has not been a problem for
years and years and the result looks terrible.

Alex

> ---
>  include/uapi/drm/drm_mode.h | 16 ++++++++--------
>  1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 359107a..0ed8d9d 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -508,14 +508,14 @@ struct drm_mode_crtc_page_flip {
>
>  /* create a dumb scanout buffer */
>  struct drm_mode_create_dumb {
> -       uint32_t height;
> -       uint32_t width;
> -       uint32_t bpp;
> -       uint32_t flags;
> +       __u32 height;
> +       __u32 width;
> +       __u32 bpp;
> +       __u32 flags;
>         /* handle, pitch, size will be returned */
> -       uint32_t handle;
> -       uint32_t pitch;
> -       uint64_t size;
> +       __u32 handle;
> +       __u32 pitch;
> +       __u64 size;
>  };
>
>  /* set up for mmap of a dumb scanout buffer */
> @@ -532,7 +532,7 @@ struct drm_mode_map_dumb {
>  };
>
>  struct drm_mode_destroy_dumb {
> -       uint32_t handle;
> +       __u32 handle;
>  };
>
>  /* page-flip flags are valid, plus: */
> --
> 2.5.0
>
> _______________________________________________
> dri-devel mailing list
> dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 04/79] drm_mode.h: use __u32 and __u64 from linux/types.h

[Mikko Rapeli]

On Thu, Oct 15, 2015 at 09:32:10AM -0400, Alex Deucher wrote:
> On Thu, Oct 15, 2015 at 1:55 AM, Mikko Rapeli <mikko.rapeli@iki.fi> wrote:
> > Fixes userspace compilation error:
> >
> > drm/drm_mode.h:472:2: error: unknown type name ‘uint32_t’
> >
> > Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
> 
> NACK on all these type conversions.  This has not been a problem for
> years and years and the result looks terrible.

Documentation/CodingStyle, section 5

 (e) Types safe for use in userspace.

     In certain structures which are visible to userspace, we cannot
     require C99 types and cannot use the 'u32' form above. Thus, we
     use __u32 and similar types in all structures which are shared
     with userspace.

I have only been looking at kernel headers from userspace occationally in
the past 10 years and had a several cases where the provided headers did
not compile when included into trivial programs trying to use the structs
for an ioctl() for example. This long lasting problem triggered me to write
a test for this and provide these fixes too. In previous reviews usage
of <stdint.h> and its types in kernel headers was already NACK'ed
so I changed several places from uint32_t's to __u32.

With these changes it is btw trivial now to add a grep test the there
are no uint32_t's in include/uapi/ anymore, thus enforcing that coding style
rule.

-Mikko

> Alex
> 
> > ---
> >  include/uapi/drm/drm_mode.h | 16 ++++++++--------
> >  1 file changed, 8 insertions(+), 8 deletions(-)
> >
> > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > index 359107a..0ed8d9d 100644
> > --- a/include/uapi/drm/drm_mode.h
> > +++ b/include/uapi/drm/drm_mode.h
> > @@ -508,14 +508,14 @@ struct drm_mode_crtc_page_flip {
> >
> >  /* create a dumb scanout buffer */
> >  struct drm_mode_create_dumb {
> > -       uint32_t height;
> > -       uint32_t width;
> > -       uint32_t bpp;
> > -       uint32_t flags;
> > +       __u32 height;
> > +       __u32 width;
> > +       __u32 bpp;
> > +       __u32 flags;
> >         /* handle, pitch, size will be returned */
> > -       uint32_t handle;
> > -       uint32_t pitch;
> > -       uint64_t size;
> > +       __u32 handle;
> > +       __u32 pitch;
> > +       __u64 size;
> >  };
> >
> >  /* set up for mmap of a dumb scanout buffer */
> > @@ -532,7 +532,7 @@ struct drm_mode_map_dumb {
> >  };
> >
> >  struct drm_mode_destroy_dumb {
> > -       uint32_t handle;
> > +       __u32 handle;
> >  };
> >
> >  /* page-flip flags are valid, plus: */
> > --
> > 2.5.0
> >
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 05/79] exynos_drm.h: use __u64 from linux/types.h

[Gustavo Padovan]

2015-10-15 Mikko Rapeli <mikko.rapeli@iki.fi>:

> Fixes userspace compilation error:
> 
> drm/exynos_drm.h:30:2: error: unknown type name ‘uint64_t’
> 
> Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
> ---
>  include/uapi/drm/exynos_drm.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>

	Gustavo
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 10/79] via_drm.h: move struct via_file_private definition to drivers/gpu/drm/via/via_drv.h

[Emil Velikov]

On 15 October 2015 at 06:55, Mikko Rapeli <mikko.rapeli@iki.fi> wrote:
> Fixes userspace compile error since list_head is not exported to userspace
> headers.
>
> Suggested by Emil Velikov <emil.l.velikov@gmail.com> at
> https://lkml.org/lkml/2015/6/3/792
>
> Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
We're safe as the only users of the struct already include via_drv.h.

Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>

Daniel can you pick this up (esp. since you added it with commit
c828e20456301b0f5192a1f75e8bf8a6afd15551)

Thanks
Emil
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 12/79] include/uapi/drm/sis_drm.h: move sis_file_private to drivers/gpu/drm/sis/sis_drv.h

[Emil Velikov]

On 15 October 2015 at 06:55, Mikko Rapeli <mikko.rapeli@iki.fi> wrote:
> Fixes userspace compile error:
>
> drm/sis_drm.h:68:19: error: field ‘obj_list’ has incomplete type
>   struct list_head obj_list;
>
> Suggested by Emil Velikov <emil.l.velikov@gmail.com> at
> https://lkml.org/lkml/2015/6/3/792
>
> Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
> ---
Analogous to the via patch. Daniel can you please pick this one as well ?

Hunk was added with commit fdc0b8a63c1124bb025a2846d41531a123845740

Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>

Thanks
Emil

Re: [PATCH v4 09/79] via_drm.h: don't include non-existing via_drmclient.h

[Emil Velikov]

On 15 October 2015 at 06:55, Mikko Rapeli <mikko.rapeli@iki.fi> wrote:
> Fixes compiler error:
>
> drm/via_drm.h:36:27: fatal error: via_drmclient.h: No such file or directory
>
> Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
> ---
>  include/uapi/drm/via_drm.h | 3 ---
>  1 file changed, 3 deletions(-)
>
> diff --git a/include/uapi/drm/via_drm.h b/include/uapi/drm/via_drm.h
> index 8b0533c..d19c0e2 100644
> --- a/include/uapi/drm/via_drm.h
> +++ b/include/uapi/drm/via_drm.h
> @@ -33,9 +33,6 @@
>  #ifndef _VIA_DEFINES_
>  #define _VIA_DEFINES_
>
> -#ifndef __KERNEL__
> -#include "via_drmclient.h"
> -#endif
>
Now this one is messy. If we remove it, existing userspace [0] won't
be able to build. As they don't include the above header where needed,
but instead rely on via_drm.h. Despite the fact that each user
provides its own copy of via_drmclient.h.
There is some very old hardware/software involved so I'm not sure how
much of a real issue this patch will be. If the maintainers decide to
pick it up, let me know and I'll roll a fix for the ddx.

-Emil

[0] There are two users afaict - the via dri mesa module and
xf86-video-via. With the former nuked some 5 years ago with mesa
commit e4344161bde2e24fcfba65d30d58f087bd8bf94d
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 04/79] drm_mode.h: use __u32 and __u64 from linux/types.h

[Emil Velikov]

Hi Alex,

On 15 October 2015 at 14:48, Mikko Rapeli <mikko.rapeli-X3B1VOXEql0@public.gmane.org> wrote:
> On Thu, Oct 15, 2015 at 09:32:10AM -0400, Alex Deucher wrote:
>> On Thu, Oct 15, 2015 at 1:55 AM, Mikko Rapeli <mikko.rapeli-X3B1VOXEql0@public.gmane.org> wrote:
>> > Fixes userspace compilation error:
>> >
>> > drm/drm_mode.h:472:2: error: unknown type name ‘uint32_t’
>> >
>> > Signed-off-by: Mikko Rapeli <mikko.rapeli-X3B1VOXEql0@public.gmane.org>
>>
>> NACK on all these type conversions.  This has not been a problem for
>> years and years and the result looks terrible.
>
> Documentation/CodingStyle, section 5
>
>  (e) Types safe for use in userspace.
>
>      In certain structures which are visible to userspace, we cannot
>      require C99 types and cannot use the 'u32' form above. Thus, we
>      use __u32 and similar types in all structures which are shared
>      with userspace.
>
> I have only been looking at kernel headers from userspace occationally in
> the past 10 years and had a several cases where the provided headers did
> not compile when included into trivial programs trying to use the structs
> for an ioctl() for example. This long lasting problem triggered me to write
> a test for this and provide these fixes too. In previous reviews usage
> of <stdint.h> and its types in kernel headers was already NACK'ed
> so I changed several places from uint32_t's to __u32.
>
> With these changes it is btw trivial now to add a grep test the there
> are no uint32_t's in include/uapi/ anymore, thus enforcing that coding style
> rule.
>
Based of the reply from Mikko, can you please elaborate your concern ?
Are you thinking about some corner case where this may cause breakage,
or it's solely on stylistic point of view ?

Over the last few years we've been doing some ad-hoc 'synchronisation'
with the headers in libdrm, and this will get us one step closer to
doing things properly.

Fwiw I fully support these changes, as does Gustavo for exynos and Rob for msm.
Reviewed-by: Emil Velikov <emil.l.velikov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

Thanks
Emil

Re: [PATCH v4 04/79] drm_mode.h: use __u32 and __u64 from linux/types.h

[Alex Deucher]

On Wed, Oct 21, 2015 at 11:09 AM, Emil Velikov <emil.l.velikov@gmail.com> wrote:
> Hi Alex,
>
> On 15 October 2015 at 14:48, Mikko Rapeli <mikko.rapeli@iki.fi> wrote:
>> On Thu, Oct 15, 2015 at 09:32:10AM -0400, Alex Deucher wrote:
>>> On Thu, Oct 15, 2015 at 1:55 AM, Mikko Rapeli <mikko.rapeli@iki.fi> wrote:
>>> > Fixes userspace compilation error:
>>> >
>>> > drm/drm_mode.h:472:2: error: unknown type name ‘uint32_t’
>>> >
>>> > Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
>>>
>>> NACK on all these type conversions.  This has not been a problem for
>>> years and years and the result looks terrible.
>>
>> Documentation/CodingStyle, section 5
>>
>>  (e) Types safe for use in userspace.
>>
>>      In certain structures which are visible to userspace, we cannot
>>      require C99 types and cannot use the 'u32' form above. Thus, we
>>      use __u32 and similar types in all structures which are shared
>>      with userspace.
>>
>> I have only been looking at kernel headers from userspace occationally in
>> the past 10 years and had a several cases where the provided headers did
>> not compile when included into trivial programs trying to use the structs
>> for an ioctl() for example. This long lasting problem triggered me to write
>> a test for this and provide these fixes too. In previous reviews usage
>> of <stdint.h> and its types in kernel headers was already NACK'ed
>> so I changed several places from uint32_t's to __u32.
>>
>> With these changes it is btw trivial now to add a grep test the there
>> are no uint32_t's in include/uapi/ anymore, thus enforcing that coding style
>> rule.
>>
> Based of the reply from Mikko, can you please elaborate your concern ?
> Are you thinking about some corner case where this may cause breakage,
> or it's solely on stylistic point of view ?

Style.

>
> Over the last few years we've been doing some ad-hoc 'synchronisation'
> with the headers in libdrm, and this will get us one step closer to
> doing things properly.

How does this affect libdrm one way or another?

Alex

>
> Fwiw I fully support these changes, as does Gustavo for exynos and Rob for msm.
> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
>
> Thanks
> Emil
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 10/79] via_drm.h: move struct via_file_private definition to drivers/gpu/drm/via/via_drv.h

[Daniel Vetter]

On Wed, Oct 21, 2015 at 03:36:22PM +0100, Emil Velikov wrote:
> On 15 October 2015 at 06:55, Mikko Rapeli <mikko.rapeli-X3B1VOXEql0@public.gmane.org> wrote:
> > Fixes userspace compile error since list_head is not exported to userspace
> > headers.
> >
> > Suggested by Emil Velikov <emil.l.velikov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> at
> > https://lkml.org/lkml/2015/6/3/792
> >
> > Signed-off-by: Mikko Rapeli <mikko.rapeli-X3B1VOXEql0@public.gmane.org>
> We're safe as the only users of the struct already include via_drv.h.
> 
> Reviewed-by: Emil Velikov <emil.l.velikov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> 
> Daniel can you pick this up (esp. since you added it with commit
> c828e20456301b0f5192a1f75e8bf8a6afd15551)

Dave already applied it.
-Daniel

> 
> Thanks
> Emil

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

Re: [PATCH v4 12/79] include/uapi/drm/sis_drm.h: move sis_file_private to drivers/gpu/drm/sis/sis_drv.h

[Daniel Vetter]

On Wed, Oct 21, 2015 at 03:39:07PM +0100, Emil Velikov wrote:
> On 15 October 2015 at 06:55, Mikko Rapeli <mikko.rapeli@iki.fi> wrote:
> > Fixes userspace compile error:
> >
> > drm/sis_drm.h:68:19: error: field ‘obj_list’ has incomplete type
> >   struct list_head obj_list;
> >
> > Suggested by Emil Velikov <emil.l.velikov@gmail.com> at
> > https://lkml.org/lkml/2015/6/3/792
> >
> > Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
> > ---
> Analogous to the via patch. Daniel can you please pick this one as well ?
> 
> Hunk was added with commit fdc0b8a63c1124bb025a2846d41531a123845740
> 
> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>

Same deal, already merged.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 04/79] drm_mode.h: use __u32 and __u64 from linux/types.h

[Emil Velikov]

On 21 October 2015 at 16:18, Alex Deucher <alexdeucher@gmail.com> wrote:
> On Wed, Oct 21, 2015 at 11:09 AM, Emil Velikov <emil.l.velikov@gmail.com> wrote:
>> Hi Alex,
>>
>> On 15 October 2015 at 14:48, Mikko Rapeli <mikko.rapeli@iki.fi> wrote:
>>> On Thu, Oct 15, 2015 at 09:32:10AM -0400, Alex Deucher wrote:
>>>> On Thu, Oct 15, 2015 at 1:55 AM, Mikko Rapeli <mikko.rapeli@iki.fi> wrote:
>>>> > Fixes userspace compilation error:
>>>> >
>>>> > drm/drm_mode.h:472:2: error: unknown type name ‘uint32_t’
>>>> >
>>>> > Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
>>>>
>>>> NACK on all these type conversions.  This has not been a problem for
>>>> years and years and the result looks terrible.
>>>
>>> Documentation/CodingStyle, section 5
>>>
>>>  (e) Types safe for use in userspace.
>>>
>>>      In certain structures which are visible to userspace, we cannot
>>>      require C99 types and cannot use the 'u32' form above. Thus, we
>>>      use __u32 and similar types in all structures which are shared
>>>      with userspace.
>>>
>>> I have only been looking at kernel headers from userspace occationally in
>>> the past 10 years and had a several cases where the provided headers did
>>> not compile when included into trivial programs trying to use the structs
>>> for an ioctl() for example. This long lasting problem triggered me to write
>>> a test for this and provide these fixes too. In previous reviews usage
>>> of <stdint.h> and its types in kernel headers was already NACK'ed
>>> so I changed several places from uint32_t's to __u32.
>>>
>>> With these changes it is btw trivial now to add a grep test the there
>>> are no uint32_t's in include/uapi/ anymore, thus enforcing that coding style
>>> rule.
>>>
>> Based of the reply from Mikko, can you please elaborate your concern ?
>> Are you thinking about some corner case where this may cause breakage,
>> or it's solely on stylistic point of view ?
>
> Style.
>
In that case shouldn't the kernel coding style (not to mention the
issues with stdint.h types Linus has brought a while back) be
considered/prevail ?

>>
>> Over the last few years we've been doing some ad-hoc 'synchronisation'
>> with the headers in libdrm, and this will get us one step closer to
>> doing things properly.
>
> How does this affect libdrm one way or another?
>
In a strange way. Some (most?) distributions do not ship the uapi
headers from the kernel, but rely on the ones in libdrm. Due to
various issues (as addressed in the series) we have not synchronised
the headers, thus users such as the gallium radeon winsys has ended up
redefining/duplicating internally.

Thanks
Emil
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 10/79] via_drm.h: move struct via_file_private definition to drivers/gpu/drm/via/via_drv.h

[Emil Velikov]

On 21 October 2015 at 16:33, Daniel Vetter <daniel-/w4YWyX8dFk@public.gmane.org> wrote:
> On Wed, Oct 21, 2015 at 03:36:22PM +0100, Emil Velikov wrote:
>> On 15 October 2015 at 06:55, Mikko Rapeli <mikko.rapeli-X3B1VOXEql0@public.gmane.org> wrote:
>> > Fixes userspace compile error since list_head is not exported to userspace
>> > headers.
>> >
>> > Suggested by Emil Velikov <emil.l.velikov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> at
>> > https://lkml.org/lkml/2015/6/3/792
>> >
>> > Signed-off-by: Mikko Rapeli <mikko.rapeli-X3B1VOXEql0@public.gmane.org>
>> We're safe as the only users of the struct already include via_drv.h.
>>
>> Reviewed-by: Emil Velikov <emil.l.velikov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>
>> Daniel can you pick this up (esp. since you added it with commit
>> c828e20456301b0f5192a1f75e8bf8a6afd15551)
>
> Dave already applied it.
Did not notice. Sorry for the noise.

-Emil

Re: [PATCH v4 04/79] drm_mode.h: use __u32 and __u64 from linux/types.h

[Alex Deucher]

On Wed, Oct 21, 2015 at 12:21 PM, Emil Velikov <emil.l.velikov@gmail.com> wrote:
> On 21 October 2015 at 16:18, Alex Deucher <alexdeucher@gmail.com> wrote:
>> On Wed, Oct 21, 2015 at 11:09 AM, Emil Velikov <emil.l.velikov@gmail.com> wrote:
>>> Hi Alex,
>>>
>>> On 15 October 2015 at 14:48, Mikko Rapeli <mikko.rapeli@iki.fi> wrote:
>>>> On Thu, Oct 15, 2015 at 09:32:10AM -0400, Alex Deucher wrote:
>>>>> On Thu, Oct 15, 2015 at 1:55 AM, Mikko Rapeli <mikko.rapeli@iki.fi> wrote:
>>>>> > Fixes userspace compilation error:
>>>>> >
>>>>> > drm/drm_mode.h:472:2: error: unknown type name ‘uint32_t’
>>>>> >
>>>>> > Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
>>>>>
>>>>> NACK on all these type conversions.  This has not been a problem for
>>>>> years and years and the result looks terrible.
>>>>
>>>> Documentation/CodingStyle, section 5
>>>>
>>>>  (e) Types safe for use in userspace.
>>>>
>>>>      In certain structures which are visible to userspace, we cannot
>>>>      require C99 types and cannot use the 'u32' form above. Thus, we
>>>>      use __u32 and similar types in all structures which are shared
>>>>      with userspace.
>>>>
>>>> I have only been looking at kernel headers from userspace occationally in
>>>> the past 10 years and had a several cases where the provided headers did
>>>> not compile when included into trivial programs trying to use the structs
>>>> for an ioctl() for example. This long lasting problem triggered me to write
>>>> a test for this and provide these fixes too. In previous reviews usage
>>>> of <stdint.h> and its types in kernel headers was already NACK'ed
>>>> so I changed several places from uint32_t's to __u32.
>>>>
>>>> With these changes it is btw trivial now to add a grep test the there
>>>> are no uint32_t's in include/uapi/ anymore, thus enforcing that coding style
>>>> rule.
>>>>
>>> Based of the reply from Mikko, can you please elaborate your concern ?
>>> Are you thinking about some corner case where this may cause breakage,
>>> or it's solely on stylistic point of view ?
>>
>> Style.
>>
> In that case shouldn't the kernel coding style (not to mention the
> issues with stdint.h types Linus has brought a while back) be
> considered/prevail ?

I don't really have a strong opinion one way or another at this point.
The types just look ugly.

>
>>>
>>> Over the last few years we've been doing some ad-hoc 'synchronisation'
>>> with the headers in libdrm, and this will get us one step closer to
>>> doing things properly.
>>
>> How does this affect libdrm one way or another?
>>
> In a strange way. Some (most?) distributions do not ship the uapi
> headers from the kernel, but rely on the ones in libdrm. Due to
> various issues (as addressed in the series) we have not synchronised
> the headers, thus users such as the gallium radeon winsys has ended up
> redefining/duplicating internally.

The problem is that you generally need the latest headers to support
the latest features in the user mode stacks, so if the user tries to
build against an older kernel, they will be missing definitions.

Alex
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 04/79] drm_mode.h: use __u32 and __u64 from linux/types.h

[Emil Velikov]

On 21 October 2015 at 17:27, Alex Deucher <alexdeucher-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Wed, Oct 21, 2015 at 12:21 PM, Emil Velikov <emil.l.velikov@gmail.com> wrote:
>> On 21 October 2015 at 16:18, Alex Deucher <alexdeucher-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> On Wed, Oct 21, 2015 at 11:09 AM, Emil Velikov <emil.l.velikov@gmail.com> wrote:
>>>> Hi Alex,
>>>>
>>>> On 15 October 2015 at 14:48, Mikko Rapeli <mikko.rapeli-X3B1VOXEql0@public.gmane.org> wrote:
>>>>> On Thu, Oct 15, 2015 at 09:32:10AM -0400, Alex Deucher wrote:
>>>>>> On Thu, Oct 15, 2015 at 1:55 AM, Mikko Rapeli <mikko.rapeli@iki.fi> wrote:
>>>>>> > Fixes userspace compilation error:
>>>>>> >
>>>>>> > drm/drm_mode.h:472:2: error: unknown type name ‘uint32_t’
>>>>>> >
>>>>>> > Signed-off-by: Mikko Rapeli <mikko.rapeli-X3B1VOXEql0@public.gmane.org>
>>>>>>
>>>>>> NACK on all these type conversions.  This has not been a problem for
>>>>>> years and years and the result looks terrible.
>>>>>
>>>>> Documentation/CodingStyle, section 5
>>>>>
>>>>>  (e) Types safe for use in userspace.
>>>>>
>>>>>      In certain structures which are visible to userspace, we cannot
>>>>>      require C99 types and cannot use the 'u32' form above. Thus, we
>>>>>      use __u32 and similar types in all structures which are shared
>>>>>      with userspace.
>>>>>
>>>>> I have only been looking at kernel headers from userspace occationally in
>>>>> the past 10 years and had a several cases where the provided headers did
>>>>> not compile when included into trivial programs trying to use the structs
>>>>> for an ioctl() for example. This long lasting problem triggered me to write
>>>>> a test for this and provide these fixes too. In previous reviews usage
>>>>> of <stdint.h> and its types in kernel headers was already NACK'ed
>>>>> so I changed several places from uint32_t's to __u32.
>>>>>
>>>>> With these changes it is btw trivial now to add a grep test the there
>>>>> are no uint32_t's in include/uapi/ anymore, thus enforcing that coding style
>>>>> rule.
>>>>>
>>>> Based of the reply from Mikko, can you please elaborate your concern ?
>>>> Are you thinking about some corner case where this may cause breakage,
>>>> or it's solely on stylistic point of view ?
>>>
>>> Style.
>>>
>> In that case shouldn't the kernel coding style (not to mention the
>> issues with stdint.h types Linus has brought a while back) be
>> considered/prevail ?
>
> I don't really have a strong opinion one way or another at this point.
> The types just look ugly.
>
Fwiw I don't find them too appealing either. But the alternative did
not fare so well :(

>>
>>>>
>>>> Over the last few years we've been doing some ad-hoc 'synchronisation'
>>>> with the headers in libdrm, and this will get us one step closer to
>>>> doing things properly.
>>>
>>> How does this affect libdrm one way or another?
>>>
>> In a strange way. Some (most?) distributions do not ship the uapi
>> headers from the kernel, but rely on the ones in libdrm. Due to
>> various issues (as addressed in the series) we have not synchronised
>> the headers, thus users such as the gallium radeon winsys has ended up
>> redefining/duplicating internally.
>
> The problem is that you generally need the latest headers to support
> the latest features in the user mode stacks, so if the user tries to
> build against an older kernel, they will be missing definitions.
>
Pretty much that's why we have the loose release criteria for libdrm.
Get the functionality upstream (mainline or -next), pull the changes
(sync) and release. As the sync has been busted for a while, people
are forced to do unpleasant things.

-Emil