[PATCH 5/6] drm: uapi: add gdepaper uapi header

[Emil Velikov]

Hi Jan,

On 2019/07/30, Jan Sebastian Götte wrote:
> Signed-off-by: Jan Sebastian Götte <linux at jaseg.net>
> ---
>  include/uapi/drm/gdepaper_drm.h | 62 +++++++++++++++++++++++++++++++++
>  1 file changed, 62 insertions(+)
>  create mode 100644 include/uapi/drm/gdepaper_drm.h
> 
> diff --git a/include/uapi/drm/gdepaper_drm.h b/include/uapi/drm/gdepaper_drm.h
> new file mode 100644
> index 000000000000..84ff6429bef5
> --- /dev/null
> +++ b/include/uapi/drm/gdepaper_drm.h
> @@ -0,0 +1,62 @@
> +/* SPDX-License-Identifier: GPL-2.0+ WITH Linux-syscall-note */
> +/* gdepaper_drm.h
> + *
> + * Copyright (c) 2019 Jan Sebastian Götte
> + */
> +
I'm glad to see more devices using upstream KMS interface. Usually
custom UAPI should not be needed for such devices.

Can you elaborate why this is required? Is there an open-source
userspace that uses these?


> +#ifndef _UAPI_GDEPAPER_DRM_H_
> +#define _UAPI_GDEPAPER_DRM_H_
> +
> +#include "drm.h"
> +
> +#if defined(__cplusplus)
> +extern "C" {
> +#endif
> +
> +enum drm_gdepaper_vghl_lv {
> +	DRM_GDEP_PWR_VGHL_16V = 0,
> +	DRM_GDEP_PWR_VGHL_15V = 1,
> +	DRM_GDEP_PWR_VGHL_14V = 2,
> +	DRM_GDEP_PWR_VGHL_13V = 3,
> +};
> +
> +struct gdepaper_refresh_params {
> +	enum drm_gdepaper_vghl_lv vg_lv; /* gate voltage level */
>From my experience, kernel drivers aim to avoid exposing voltage control
to userspace. AFAICT exceptions are present, but generally it's a no-go.


> +	__u32 vcom_sel; /* VCOM select bit according to datasheet */
> +	__s32 vdh_bw_mv; /* drive high level, b/w pixel (mV) */
> +	__s32 vdh_col_mv; /* drive high level, red/yellow pixel (mV) */
> +	__s32 vdl_mv; /* drive low level (mV) */
> +	__s32 vcom_dc_mv;
> +	__u32 vcom_data_ivl_hsync; /* data ivl len in hsync periods */
> +	__u32 border_data_sel; /* "vbd" in datasheet */
> +	__u32 data_polarity; /* "ddx" in datasheet */
These properties look like they should live in the device-tree bindings.

> +	__u32 use_otp_luts_flag; /* Use OTP LUTs */
> +	__u8 lut_vcom_dc[44];
> +	__u8 lut_ww[42];
> +	__u8 lut_bw[42];
> +	__u8 lut_bb[42];
> +	__u8 lut_wb[42];
There is UAPI to manage LUT (or was it WIP with patches on the list) via
the atomic API. Is that not flexible enough for your needs?

> +};
> +
> +/* Force a full display refresh */
> +#define DRM_GDEPAPER_FORCE_FULL_REFRESH		0x00
> +#define DRM_GDEPAPER_GET_REFRESH_PARAMS		0x01
> +#define DRM_GDEPAPER_SET_REFRESH_PARAMS		0x02
> +#define DRM_GDEPAPER_SET_PARTIAL_UPDATE_EN	0x03
> +
> +#define DRM_IOCTL_GDEPAPER_FORCE_FULL_REFRESH \
> +	DRM_IO(DRM_COMMAND_BASE + DRM_GDEPAPER_FORCE_FULL_REFRESH)
> +#define DRM_IOCTL_GDEPAPER_GET_REFRESH_PARAMS \
> +	DRM_IOR(DRM_COMMAND_BASE + DRM_GDEPAPER_GET_REFRESH_PARAMS, \
> +	struct gdepaper_refresh_params)
> +#define DRM_IOCTL_GDEPAPER_SET_REFRESH_PARAMS \
> +	DRM_IOR(DRM_COMMAND_BASE + DRM_GDEPAPER_SET_REFRESH_PARAMS, \
> +	struct gdepaper_refresh_params)
> +#define DRM_IOCTL_GDEPAPER_SET_PARTIAL_UPDATE_EN \
> +	DRM_IOR(DRM_COMMAND_BASE + DRM_GDEPAPER_SET_PARTIAL_UPDATE_EN, __u32)
> +
Similarly to the LUT above, the atomic UAPI has support for partial
updates. The property is called FB_DAMAGE_CLIPS and there is an example
in weston how to use it see 009b3cfa6f16bb361eb54efcc7435bfede4524bc.

HTH
Emil