Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp4871438ybi; Tue, 30 Jul 2019 09:34:21 -0700 (PDT) X-Google-Smtp-Source: APXvYqwaCMcvi6+2BQQXKS7abzi/tUbDNVUj8CwkYfDW8gIjaMQK1JUatVYM1WqaJT95x1f7pmJ1 X-Received: by 2002:a63:ee08:: with SMTP id e8mr56142009pgi.70.1564504460881; Tue, 30 Jul 2019 09:34:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564504460; cv=none; d=google.com; s=arc-20160816; b=QwIXmog6qC5T9hDq5tCGQzBWDm+9bC7iirm5/GlsJ0uzmODof+FWVQnXol+8ZcW989 NfGj9OXQ1M5U9Hup2BnUqyjgzstB+huEzTNwyVW5VAleNbaU6+ihcQgFZnEAD8F5YK9K hTBwnPmvviUQ4Hq+PZEbBwY/mp0Cl3tGsk5qSz9rH8+KNVtJrYO/bBPtEotxa7y9rq8c AtDrdtMMExMkDVRZXRzWHMm1dCe5Yf9dZGkzcUBXbV0mhuktqp+VS2uOD0tzOOesObkM e/tqBrhH0bsnKpWXZSmd+jZ0+DcDE+jTDxOxSA35lUpbODHcl8Egj21GOEXJZRxPWowv nChw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=LZsG/s5jOtsbzlRKW8PKqAQkBM+xaVVYAfsSo2wPupA=; b=hPE961Xuopb5sTKdeH/VwKVQBsO3YrVuI2D8TcmkEdgaKYJaRxR5H5z6A2agx3dO0p kkfiFPPRPxa607K7hzrhbKt5XyuuBKQRiGD50Yr6kZUYR2Y6gqxOcjgZTn6z30fDIYRR vRGtRi5iO1l6kIZkkRJDiOR3iKSh/WYZEa5ahsRGi/gOWb+SCK+h0rcb5Oxt7IHmkvxj W0zfkyM8K+L8CEMyLo5LvzR9mwQI2YxfAfFj6yTBESCtSehcHXoa5dSG9N+KVHyHu2Ci ew9lffPDF6f0NYjcaUJiJZHDRXbaEeAr8onlxSkNWf72yP6ZirRPqszSn6gflKSLSbGz vsBg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=T0bXGO2X; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f5si29435042pgk.184.2019.07.30.09.34.05; Tue, 30 Jul 2019 09:34:20 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=T0bXGO2X; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730130AbfG3OJY (ORCPT + 99 others); Tue, 30 Jul 2019 10:09:24 -0400 Received: from mail-wr1-f68.google.com ([209.85.221.68]:42749 "EHLO mail-wr1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728769AbfG3OJY (ORCPT ); Tue, 30 Jul 2019 10:09:24 -0400 Received: by mail-wr1-f68.google.com with SMTP id x1so16042643wrr.9 for ; Tue, 30 Jul 2019 07:09:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=LZsG/s5jOtsbzlRKW8PKqAQkBM+xaVVYAfsSo2wPupA=; b=T0bXGO2XKLP4M7xqw5lCTKWqVX653o6KAihg4YH2utjTY7W8HvQFClzNjx+rRAwQfq BcZgRUsRyhpe1TXm4vmbFAK6UlT1BtFIdJ5s1/FIFnN26q/ATEWFjmSHY6qywRTKszvf V5NczzKud8EGdcbTZ8PaV0ei42m8Ix09VDdg2YWzFW1I140ajIuW+Ddq7fOg/SSBe+0G 9MQmLc+WG3O+23Iz7u4S2GZZcyPlTsSIIxJyJpTC7mtPRuHoZ8ywrqZyMLKUqE3Nsd/h iMgW2NcNV42PbBBA/U4XdA4ytGyM61xXbyh03yMrg7+rT57kOpMI57mdKsZPfIUk1AQD vV3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=LZsG/s5jOtsbzlRKW8PKqAQkBM+xaVVYAfsSo2wPupA=; b=g+SWEWnU0POiQmEaFYy068DQbcBz8Ycwn1qie3M4eXaQeDVSZXbZkvcJtrMqUDNDv3 txK2+JPECsjDloSPD6/GBxOBmitdVuvY2NOn9YmWKebn6fU9/fP/aeSPnw42ikWS/WrZ ag1rfMyjDi7uAp3miXPjFz1kzmFljpxn/9Mt92+Nmwg0tg3Svp33oVgv2bcK74PIwplA KKSQfEVoJ1E4+PEvVFel4KPC0xZyMGOF4+98+M/EaE6JC0tt0iQ96pP1rxC0VHKasXeq qRCksg2qLOXJm3VCwQp0uw6QNHh4OBfZkFCAM4U9IL5fbh2CW9kL/+Qwu57y08XBLZhw rl/g== X-Gm-Message-State: APjAAAUXgaWXQXHx8i3tdY3eJybHrzLjilpyQkCedrZJBqKwpDX3KrlC EWtfoeaDO8CgR25RAngwpRE= X-Received: by 2002:a5d:4085:: with SMTP id o5mr126346630wrp.101.1564495762176; Tue, 30 Jul 2019 07:09:22 -0700 (PDT) Received: from arch-x1c3 ([2a00:5f00:102:0:9665:9cff:feee:aa4d]) by smtp.gmail.com with ESMTPSA id f192sm67862071wmg.30.2019.07.30.07.09.21 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Tue, 30 Jul 2019 07:09:21 -0700 (PDT) Date: Tue, 30 Jul 2019 15:08:52 +0100 From: Emil Velikov To: Jan Sebastian =?iso-8859-1?Q?G=F6tte?= Cc: dri-devel@lists.freedesktop.org, David Airlie , linux-kernel@vger.kernel.org Subject: Re: [PATCH 5/6] drm: uapi: add gdepaper uapi header Message-ID: <20190730140852.GB12424@arch-x1c3> References: <3c8fccc9-63f7-18bb-dcb5-dcd0b9e151d2@jaseg.net> <0e22c86a-3998-c2fd-cb14-203df547eb5c@jaseg.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0e22c86a-3998-c2fd-cb14-203df547eb5c@jaseg.net> User-Agent: Mutt/1.11.4 (2019-03-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Jan, On 2019/07/30, Jan Sebastian G?tte wrote: > Signed-off-by: Jan Sebastian G?tte > --- > 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