From: Emil Velikov <emil.l.velikov@gmail.com>
To: "Jan Sebastian Götte" <linux@jaseg.net>
Cc: dri-devel@lists.freedesktop.org, David Airlie <airlied@linux.ie>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 5/6] drm: uapi: add gdepaper uapi header
Date: Tue, 30 Jul 2019 15:08:52 +0100 [thread overview]
Message-ID: <20190730140852.GB12424@arch-x1c3> (raw)
In-Reply-To: <0e22c86a-3998-c2fd-cb14-203df547eb5c@jaseg.net>
Hi Jan,
On 2019/07/30, Jan Sebastian Götte wrote:
> Signed-off-by: Jan Sebastian Götte <linux@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
next prev parent reply other threads:[~2019-07-30 14:09 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-30 13:46 [RFC PATCH 0/6] tiny: Add driver for gooddisplay epaper panels Jan Sebastian Götte
2019-07-30 13:47 ` [PATCH 1/6] drm: tiny: gdepaper: add TINYDRM_GDEPAPER config option Jan Sebastian Götte
2019-07-30 13:48 ` [PATCH 2/6] dt-bindings: add gooddisplay vendor prefix Jan Sebastian Götte
2019-07-30 13:48 ` [PATCH 3/6] dt-bindings: add good display epaper header Jan Sebastian Götte
2019-07-30 13:48 ` [PATCH 4/6] dt-bindings: add gdepaper documentation Jan Sebastian Götte
2019-07-30 13:48 ` [PATCH 5/6] drm: uapi: add gdepaper uapi header Jan Sebastian Götte
2019-07-30 14:08 ` Emil Velikov [this message]
2019-07-30 16:21 ` Jan Sebastian Götte
2019-07-30 16:49 ` Emil Velikov
2019-07-31 2:01 ` Jan Sebastian Götte
2019-07-31 6:47 ` Daniel Vetter
2019-07-30 13:48 ` [PATCH 6/6] drm: tiny: gdepaper: add driver for 2/3 color epaper displays Jan Sebastian Götte
2019-08-06 16:06 ` Noralf Trønnes
2019-08-10 5:17 ` Jan Sebastian Götte
2019-07-30 14:26 ` [RFC PATCH 0/6] tiny: Add driver for gooddisplay epaper panels Daniel Vetter
2019-07-30 16:24 ` Jan Sebastian Götte
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190730140852.GB12424@arch-x1c3 \
--to=emil.l.velikov@gmail.com \
--cc=airlied@linux.ie \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@jaseg.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).