Re: [EXT] Re: [PATCH v3 2/2] drm/panel: Add support for Raydium RM67191 panel driver
On Lu, 2019-06-24 at 13:12 -0300, Fabio Estevam wrote: > Caution: EXT Email > > Hi Robert, > > On Mon, Jun 24, 2019 at 4:44 AM Robert Chiras > wrote: > > > > > > > > > You did not handle the "power" regulator. > > There is no need for a power regulator. > I am sure the panel requires power to be applied so that it can work > :-) Yes, of course there are power lines to the panel. I will add them to the next revision. > > > > > > > > > Can't you simply remove them? > > The reset gpio pin is shared between the DSI display controller and > Looking at the imx8mq-evk schematics it is not clear for me what pin > in shared between the OLED display and touch screen. > > Could you please clarify which pin you are referring to? It's about the DSI_EN pin on the DSI LCD IF physical port J1501. This goes into RST_B_1V8 on the panel port which is used for both display and touch resets. > > > > > touch controller, both found on the same panel. Since, the touch > > driver > > also acceses this gpio pin, in some cases the display can be put to > > sleep, but the touch is still active. This is why, during suspend I > > release the gpio resource, and I have to take it back in resume. > > Without this release/acquire mechanism during suspend/resume, > > stress- > > tests showed some failures: the resume freezes completly. > Looking at the imx8mq-evk dts from the vendor tree I see that the > touchscreen is not supported in mainline yet. > > Maybe there is a better way to solve this, so what if you don't > introduce the suspend/resume hooks for now and then we revisit this > after the touchscreen driver is added? You are right. We can do this too. I will remove it for now.
Re: [PATCHv8 02/13] cec: add struct cec_connector_info support
On 6/24/19 6:03 PM, Hans Verkuil wrote:
> From: Dariusz Marcinkiewicz
>
> Define struct cec_connector_info in media/cec.h and define
> CEC_CAP_CONNECTOR_INFO. In a later patch this will be moved to
> uapi/linux/cec.h.
>
> For now just define this together with the cec_fill_conn_info_from_drm
> and cec_s_conn_info functions: this allows both drm and media to make
> use of this without requiring cross-subsystem changes.
>
> Signed-off-by: Dariusz Marcinkiewicz
> Co-developed-by: Hans Verkuil
> Signed-off-by: Hans Verkuil
> ---
> drivers/media/cec/cec-adap.c | 29 +++
> drivers/media/cec/cec-core.c | 5
> include/media/cec.h | 45 +++-
> 3 files changed, 78 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/cec/cec-adap.c b/drivers/media/cec/cec-adap.c
> index ac3683a7b2ab..451c61bde4d4 100644
> --- a/drivers/media/cec/cec-adap.c
> +++ b/drivers/media/cec/cec-adap.c
> @@ -16,7 +16,10 @@
> #include
> #include
>
> +#include
> +#include
> #include
> +#include
>
> #include "cec-priv.h"
>
> @@ -75,6 +78,16 @@ u16 cec_get_edid_phys_addr(const u8 *edid, unsigned int
> size,
> }
> EXPORT_SYMBOL_GPL(cec_get_edid_phys_addr);
>
> +void cec_fill_conn_info_from_drm(struct cec_connector_info *conn_info,
> + const struct drm_connector *connector)
> +{
> + memset(conn_info, 0, sizeof(*conn_info));
> + conn_info->type = CEC_CONNECTOR_TYPE_DRM;
> + conn_info->drm.card_no = connector->dev->primary->index;
> + conn_info->drm.connector_id = connector->base.id;
> +}
> +EXPORT_SYMBOL_GPL(cec_fill_conn_info_from_drm);
> +
> /*
> * Queue a new event for this filehandle. If ts == 0, then set it
> * to the current time.
> @@ -1598,6 +1611,22 @@ void cec_s_phys_addr_from_edid(struct cec_adapter
> *adap,
> }
> EXPORT_SYMBOL_GPL(cec_s_phys_addr_from_edid);
>
> +void cec_s_conn_info(struct cec_adapter *adap,
> + const struct cec_connector_info *conn_info)
> +{
> + if (!(adap->capabilities & CEC_CAP_CONNECTOR_INFO))
> + return;
> +
> + mutex_lock(&adap->lock);
> + if (conn_info)
> + adap->conn_info = *conn_info;
> + else
> + memset(&adap->conn_info, 0, sizeof(adap->conn_info));
> + cec_post_state_event(adap);
> + mutex_unlock(&adap->lock);
> +}
> +EXPORT_SYMBOL_GPL(cec_s_conn_info);
> +
> /*
> * Called from either the ioctl or a driver to set the logical addresses.
> *
> diff --git a/drivers/media/cec/cec-core.c b/drivers/media/cec/cec-core.c
> index db7adffcdc76..e45b792d26fb 100644
> --- a/drivers/media/cec/cec-core.c
> +++ b/drivers/media/cec/cec-core.c
> @@ -189,6 +189,11 @@ static void cec_cec_notify(struct cec_adapter *adap, u16
> pa)
> cec_s_phys_addr(adap, pa, false);
> }
>
> +void cec_notifier_register(struct cec_notifier *n,
> +struct cec_adapter *adap,
> +void (*callback)(struct cec_adapter *adap, u16 pa));
> +void cec_notifier_unregister(struct cec_notifier *n);
> +
> void cec_register_cec_notifier(struct cec_adapter *adap,
> struct cec_notifier *notifier)
> {
> diff --git a/include/media/cec.h b/include/media/cec.h
> index 707411ef8ba2..45f2c98ed75b 100644
> --- a/include/media/cec.h
> +++ b/include/media/cec.h
> @@ -17,7 +17,9 @@
> #include
> #include
> #include
> -#include
> +
> +/* CEC_ADAP_G_CONNECTOR_INFO is available */
> +#define CEC_CAP_CONNECTOR_INFO 0
>
> #define CEC_CAP_DEFAULTS (CEC_CAP_LOG_ADDRS | CEC_CAP_TRANSMIT | \
> CEC_CAP_PASSTHROUGH | CEC_CAP_RC)
> @@ -53,6 +55,7 @@ struct cec_devnode {
> struct cec_adapter;
> struct cec_data;
> struct cec_pin;
> +struct cec_notifier;
>
> struct cec_data {
> struct list_head list;
> @@ -144,6 +147,27 @@ struct cec_adap_ops {
> */
> #define CEC_MAX_MSG_TX_QUEUE_SZ (18 * 1)
>
> +/**
> + * struct cec_event_connector - tells if and which connector is associated
> + * with the CEC adapter.
> + * @card_no: drm card number
> + * @connector_id: drm connector ID
> + */
> +struct cec_drm_connector_info {
> + __u32 card_no;
> + __u32 connector_id;
> +};
> +
> +#define CEC_CONNECTOR_TYPE_NO_CONNECTOR 0
> +#define CEC_CONNECTOR_TYPE_DRM 1
> +struct cec_connector_info {
> + __u32 type;
> + union {
> + struct cec_drm_connector_info drm;
> + __u32 raw[16];
> + };
> +};
> +
> struct cec_adapter {
> struct module *owner;
> char name[32];
> @@ -182,6 +206,7 @@ struct cec_adapter {
> struct cec_fh *cec_initiator;
> bool passthrough;
> struct cec_log_addrs log_addrs;
> + struct cec_connector_info conn_info;
>
> u32 tx_timeouts;
>
> @@ -233,6 +258,7 @@ static inline bool cec_is_registered(const struct
> cec_adapter *adap)
> ((pa) >> 12), ((pa) >> 8) & 0xf, ((pa) >> 4) & 0xf, (pa) & 0xf
>
Re: drm/msm/dpu: Correct dpu encoder spinlock initialization
On 2019-06-25 03:56, Jeykumar Sankaran wrote: On 2019-06-23 23:27, Shubhashree Dhar wrote: dpu encoder spinlock should be initialized during dpu encoder init instead of dpu encoder setup which is part of commit. There are chances that vblank control uses the uninitialized spinlock if not initialized during encoder init. Not much can be done if someone is performing a vblank operation before encoder_setup is done. Can you point to the path where this lock is acquired before the encoder_setup? Thanks Jeykumar S. When running some dp usecase, we are hitting this callstack. Process kworker/u16:8 (pid: 215, stack limit = 0xdf9dd930) Call trace: spin_dump+0x84/0x8c spin_dump+0x0/0x8c do_raw_spin_lock+0x80/0xb0 _raw_spin_lock_irqsave+0x34/0x44 dpu_encoder_toggle_vblank_for_crtc+0x8c/0xe8 dpu_crtc_vblank+0x168/0x1a0 dpu_kms_enable_vblank+0[ 11.648998] vblank_ctrl_worker+0x3c/0x60 process_one_work+0x16c/0x2d8 worker_thread+0x1d8/0x2b0 kthread+0x124/0x134 Looks like vblank is getting enabled earlier causing this issue and we are using the spinlock without initializing it. Thanks, Shubhashree Change-Id: I5a18b95fa47397c834a266b22abf33a517b03a4e Signed-off-by: Shubhashree Dhar --- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c index 5f085b5..22938c7 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c @@ -2195,8 +2195,6 @@ int dpu_encoder_setup(struct drm_device *dev, struct drm_encoder *enc, if (ret) goto fail; - spin_lock_init(&dpu_enc->enc_spinlock); - atomic_set(&dpu_enc->frame_done_timeout, 0); timer_setup(&dpu_enc->frame_done_timer, dpu_encoder_frame_done_timeout, 0); @@ -2250,6 +2248,7 @@ struct drm_encoder *dpu_encoder_init(struct drm_device *dev, drm_encoder_helper_add(&dpu_enc->base, &dpu_encoder_helper_funcs); + spin_lock_init(&dpu_enc->enc_spinlock); dpu_enc->enabled = false; return &dpu_enc->base;
Re: [PATCH v4 5/7] lib/hexdump.c: Allow multiple groups to be separated by lines '|'
On Tue, 2019-06-25 at 13:17 +1000, Alastair D'Silva wrote:
> From: Alastair D'Silva
>
> With the wider display format, it can become hard to identify how many
> bytes into the line you are looking at.
>
> The patch adds new flags to hex_dump_to_buffer() and print_hex_dump() to
> print vertical lines to separate every N groups of bytes.
>
> eg.
> buf:: 454d414e 43415053|4e495f45 00584544 NAMESPAC|E_INDEX.
> buf:0010: 0002| |
>
> Signed-off-by: Alastair D'Silva
> ---
> include/linux/printk.h | 3 +++
> lib/hexdump.c | 59 --
> 2 files changed, 54 insertions(+), 8 deletions(-)
>
> diff --git a/include/linux/printk.h b/include/linux/printk.h
[]
> @@ -485,6 +485,9 @@ enum {
>
> #define HEXDUMP_ASCIIBIT(0)
> #define HEXDUMP_SUPPRESS_REPEATEDBIT(1)
> +#define HEXDUMP_2_GRP_LINES BIT(2)
> +#define HEXDUMP_4_GRP_LINES BIT(3)
> +#define HEXDUMP_8_GRP_LINES BIT(4)
These aren't really bits as only one value should be set
as 8 overrides 4 and 4 overrides 2.
I would also expect this to be a value of 2 in your above
example, rather than 8. It's described as groups not bytes.
The example is showing a what would normally be a space ' '
separator as a vertical bar '|' every 2nd grouping.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 4/7] lib/hexdump.c: Replace ascii bool in hex_dump_to_buffer with flags
On Tue, 2019-06-25 at 15:06 +1000, Alastair D'Silva wrote: > The change actions Jani's suggestion: > https://lkml.org/lkml/2019/6/20/343 I suggest not changing any of the existing uses of hex_dump_to_buffer and only use hex_dump_to_buffer_ext when necessary for your extended use cases. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 4/7] lib/hexdump.c: Replace ascii bool in hex_dump_to_buffer with flags
On Tue, 2019-06-25 at 15:06 +1000, Alastair D'Silva wrote: > On Mon, 2019-06-24 at 22:01 -0700, Joe Perches wrote: > > On Tue, 2019-06-25 at 13:17 +1000, Alastair D'Silva wrote: > > > From: Alastair D'Silva > > > > > > In order to support additional features, rename hex_dump_to_buffer > > > to > > > hex_dump_to_buffer_ext, and replace the ascii bool parameter with > > > flags. > > [] > > > diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c > > > b/drivers/gpu/drm/i915/intel_engine_cs.c > > [] > > > @@ -1338,9 +1338,8 @@ static void hexdump(struct drm_printer *m, > > > const void *buf, size_t len) > > > } > > > > > > WARN_ON_ONCE(hex_dump_to_buffer(buf + pos, len - pos, > > > - rowsize, sizeof(u32), > > > - line, sizeof(line), > > > - false) >= > > > sizeof(line)); > > > + rowsize, sizeof(u32), > > > line, > > > + sizeof(line)) >= > > > sizeof(line)); > > > > Huh? Why do this? [] > The change actions Jani's suggestion: > https://lkml.org/lkml/2019/6/20/343 I think you need to read this change again. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 0/7] Hexdump Enhancements
On Tue, 2019-06-25 at 13:17 +1000, Alastair D'Silva wrote: > From: Alastair D'Silva > > Apologies for the large CC list, it's a heads up for those responsible > for subsystems where a prototype change in generic code causes a change > in those subsystems. [] > The default behaviour of hexdump is unchanged, however, the prototype > for hex_dump_to_buffer() has changed, and print_hex_dump() has been > renamed to print_hex_dump_ext(), with a wrapper replacing it for > compatibility with existing code, which would have been too invasive to > change. I believe this cover letter is misleading. The point of the wrapper is to avoid unnecessary changes in existing code. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 4/7] lib/hexdump.c: Replace ascii bool in hex_dump_to_buffer with flags
On Tue, 2019-06-25 at 13:17 +1000, Alastair D'Silva wrote:
> From: Alastair D'Silva
>
> In order to support additional features, rename hex_dump_to_buffer to
> hex_dump_to_buffer_ext, and replace the ascii bool parameter with flags.
[]
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
> b/drivers/gpu/drm/i915/intel_engine_cs.c
[]
> @@ -1338,9 +1338,8 @@ static void hexdump(struct drm_printer *m, const void
> *buf, size_t len)
> }
>
> WARN_ON_ONCE(hex_dump_to_buffer(buf + pos, len - pos,
> - rowsize, sizeof(u32),
> - line, sizeof(line),
> - false) >= sizeof(line));
> + rowsize, sizeof(u32), line,
> + sizeof(line)) >= sizeof(line));
Huh? Why do this?
> diff --git a/drivers/isdn/hardware/mISDN/mISDNisar.c
> b/drivers/isdn/hardware/mISDN/mISDNisar.c
[]
> @@ -70,8 +70,9 @@ send_mbox(struct isar_hw *isar, u8 his, u8 creg, u8 len, u8
> *msg)
> int l = 0;
>
> while (l < (int)len) {
> - hex_dump_to_buffer(msg + l, len - l, 32, 1,
> -isar->log, 256, 1);
> + hex_dump_to_buffer_ext(msg + l, len - l, 32, 1,
> +isar->log, 256,
> +HEXDUMP_ASCII);
Again, why do any of these?
The point of the wrapper is to avoid changing these.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 2/2] drm/exynos: trigger build of all modules
Hi Inki. > > Alpha often needs one to pull in vmalloc.h - where all other > > architectures get it indirect via other headers. > > I have never bothered to find out why alpa needs more headers files, > > but I always make sure to test things using alpha so 0-day do not yell at > > me. > > I couldn't see any warning message while building your patch after dropping > above change. > Could you check it again on top of below git repo.? > git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git > exynos-drm-next > > I'm going to request GIT-PULL as soon as you get back to me. With the COMPILE_TEST patch, but without the extra fix I get: CC [M] drivers/gpu/drm/exynos/exynos_drm_fbdev.o /home/sam/kernel/drm-exynos/drivers/gpu/drm/exynos/exynos_drm_fbdev.c: In function ‘exynos_drm_fbdev_update’: /home/sam/kernel/drm-exynos/drivers/gpu/drm/exynos/exynos_drm_fbdev.c:94:40: error: implicit declaration of function ‘vmap’; did you mean ‘bmap’? [-Werror=implicit-function-declaration] exynos_gem->kvaddr = (void __iomem *) vmap(exynos_gem->pages, nr_pages, ^~~~ bmap /home/sam/kernel/drm-exynos/drivers/gpu/drm/exynos/exynos_drm_fbdev.c:95:5: error: ‘VM_MAP’ undeclared (first use in this function); did you mean ‘VM_MPX’? VM_MAP, pgprot_writecombine(PAGE_KERNEL)); ^~ VM_MPX /home/sam/kernel/drm-exynos/drivers/gpu/drm/exynos/exynos_drm_fbdev.c:95:5: note: each undeclared identifier is reported only once for each function it appears in /home/sam/kernel/drm-exynos/drivers/gpu/drm/exynos/exynos_drm_fbdev.c: In function ‘exynos_drm_fbdev_destroy’: /home/sam/kernel/drm-exynos/drivers/gpu/drm/exynos/exynos_drm_fbdev.c:243:2: error: implicit declaration of function ‘vunmap’; did you mean ‘iounmap’? [-Werror=implicit-function-declaration] vunmap(exynos_gem->kvaddr); ^~ iounmap cc1: some warnings being treated as errors This is with a freshly pulled tree from drm-exynos.git exynos-drm-next The warning only appear if you build for alpha. So the extra fix is indeed needed. But always good to double check - thanks for asking. Note: My gcc version for alpha: $ alpha-linux-gnu-gcc --version alpha-linux-gnu-gcc (Ubuntu 8.3.0-6ubuntu1) 8.3.0 Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: arm32 build failure after abe882a39a9c ("drm/amd/display: fix issue with eDP not detected on driver load")
Hi Alex,
please resolve this ASAP, I cannot pull your tree without this fixed
as it breaks my arm builds here.
an 8 second delay there seems pointless and arbitary, an 8 sec delay
there without a comment, seems like a lack of review.
Dave.
On Tue, 18 Jun 2019 at 11:12, Nathan Chancellor
wrote:
>
> Hi all,
>
> After commit abe882a39a9c ("drm/amd/display: fix issue with eDP not
> detected on driver load") in -next, arm32 allyesconfig builds start
> failing at link time:
>
> arm-linux-gnueabi-ld: drivers/gpu/drm/amd/display/dc/core/dc_link.o: in
> function `dc_link_detect':
> dc_link.c:(.text+0x260c): undefined reference to `__bad_udelay'
>
> arm32 only allows a udelay value of up to 2000, see
> arch/arm/include/asm/delay.h for more info.
>
> Please look into this when you have a chance!
> Nathan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 2/2] drm/exynos: trigger build of all modules
Hi Sam, On 19. 6. 25. 오전 12:29, Sam Ravnborg wrote: > Hi Inki > > From changelog: >>> >>> Include fix of exynos build for alpha. >>> > > >>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c >>> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c >>> index aefcd624fe32..b0877b97291c 100644 >>> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c >>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c >>> @@ -10,6 +10,7 @@ >>> >>> #include >>> #include >>> +#include >> >> Is this change related to this patch? > > This is the above mentioned fix. > Alpha often needs one to pull in vmalloc.h - where all other > architectures get it indirect via other headers. > I have never bothered to find out why alpa needs more headers files, > but I always make sure to test things using alpha so 0-day do not yell at me. I couldn't see any warning message while building your patch after dropping above change. Could you check it again on top of below git repo.? git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git exynos-drm-next I'm going to request GIT-PULL as soon as you get back to me. Thanks, Inki Dae > > Sam > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101325] UE4Editor crash after pressing "play" with radeon southern island card (7850 HD)
https://bugs.freedesktop.org/show_bug.cgi?id=101325 Timothy Arceri changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #25 from Timothy Arceri --- The apitrace runs fine on my Vega. Can you confirm if this is still an issue for you with recent Mesa or if we can close the bug report? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102965] glColor functions producing GL_INVALID_OPERATION
https://bugs.freedesktop.org/show_bug.cgi?id=102965 Timothy Arceri changed: What|Removed |Added Resolution|--- |NOTABUG Status|NEW |RESOLVED -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101749] sclk scales badly in war thunder
https://bugs.freedesktop.org/show_bug.cgi?id=101749 Timothy Arceri changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #3 from Timothy Arceri --- Reports from bug 100742 are that this issue has improved with recent kernel updates. Can you confirm is this is still an issue? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 98996] Counter Strike: Global Offensive performance on Radeon Polaris
https://bugs.freedesktop.org/show_bug.cgi?id=98996 Timothy Arceri changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #4 from Timothy Arceri --- There have been many performance improvements to the drivers since this was reported, and nobody else has since complained of performance issue with this game. I'm going to close this for now. Feel free to reopen with updated information if this is still an issue. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv8 09/13] dw-hdmi: use cec_notifier_conn_(un)register
Hi Hans, I love your patch! Yet something to improve: [auto build test ERROR on linuxtv-media/master] [also build test ERROR on v5.2-rc6 next-20190621] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Hans-Verkuil/cec-improve-notifier-support-add-connector-info/20190625-043917 base: git://linuxtv.org/media_tree.git master config: x86_64-randconfig-x014-201925 (attached as .config) compiler: gcc-7 (Debian 7.3.0-1) 7.3.0 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 If you fix the issue, kindly add following tag Reported-by: kbuild test robot All errors (new ones prefixed by >>): drivers/gpu/drm/bridge/synopsys/dw-hdmi.c: In function 'dw_hdmi_bridge_attach': >> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c:2154:30: error: passing argument 1 >> of 'cec_fill_conn_info_from_drm' from incompatible pointer type >> [-Werror=incompatible-pointer-types] cec_fill_conn_info_from_drm(&conn_info, connector); ^ In file included from include/media/cec-notifier.h:13:0, from drivers/gpu/drm/bridge/synopsys/dw-hdmi.c:36: include/media/cec.h:381:1: note: expected 'const struct drm_connector *' but argument is of type 'struct cec_connector_info *' cec_fill_conn_info_from_drm(const struct drm_connector *connector, ^~~ drivers/gpu/drm/bridge/synopsys/dw-hdmi.c:2154:42: error: passing argument 2 of 'cec_fill_conn_info_from_drm' from incompatible pointer type [-Werror=incompatible-pointer-types] cec_fill_conn_info_from_drm(&conn_info, connector); ^ In file included from include/media/cec-notifier.h:13:0, from drivers/gpu/drm/bridge/synopsys/dw-hdmi.c:36: include/media/cec.h:381:1: note: expected 'struct cec_connector_info *' but argument is of type 'struct drm_connector *' cec_fill_conn_info_from_drm(const struct drm_connector *connector, ^~~ Cyclomatic Complexity 1 include/linux/err.h:ERR_PTR Cyclomatic Complexity 1 include/linux/err.h:PTR_ERR Cyclomatic Complexity 1 include/linux/spinlock.h:spinlock_check Cyclomatic Complexity 1 include/linux/spinlock.h:spin_lock_irq Cyclomatic Complexity 1 include/linux/spinlock.h:spin_unlock_irq Cyclomatic Complexity 1 include/linux/spinlock.h:spin_unlock_irqrestore Cyclomatic Complexity 1 include/linux/completion.h:reinit_completion Cyclomatic Complexity 1 include/linux/kobject.h:kobject_name Cyclomatic Complexity 1 include/linux/device.h:dev_get_drvdata Cyclomatic Complexity 1 include/linux/device.h:dev_set_drvdata Cyclomatic Complexity 1 include/linux/i2c.h:i2c_get_adapdata Cyclomatic Complexity 1 include/linux/i2c.h:i2c_set_adapdata Cyclomatic Complexity 1 include/drm/drm_modeset_helper_vtables.h:drm_connector_helper_add Cyclomatic Complexity 1 include/media/cec-notifier.h:cec_notifier_conn_register Cyclomatic Complexity 1 include/media/cec-notifier.h:cec_notifier_conn_unregister Cyclomatic Complexity 1 include/media/cec-notifier.h:cec_notifier_set_phys_addr Cyclomatic Complexity 1 include/media/cec-notifier.h:cec_notifier_set_phys_addr_from_edid Cyclomatic Complexity 1 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c:dw_hdmi_i2c_func Cyclomatic Complexity 2 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c:hdmi_bus_fmt_is_rgb Cyclomatic Complexity 2 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c:hdmi_bus_fmt_is_yuv444 Cyclomatic Complexity 2 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c:hdmi_bus_fmt_is_yuv422 Cyclomatic Complexity 2 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c:hdmi_bus_fmt_is_yuv420 Cyclomatic Complexity 5 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c:hdmi_bus_fmt_color_depth Cyclomatic Complexity 1 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c:is_color_space_conversion Cyclomatic Complexity 6 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c:is_color_space_decimation Cyclomatic Complexity 6 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c:is_color_space_interpolation Cyclomatic Complexity 35 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c:hdmi_compute_n Cyclomatic Complexity 4 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c:dw_hdmi_audio_enable Cyclomatic Complexity 4 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c:dw_hdmi_audio_disable Cyclomatic Complexity 23 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c:dw_hdmi_support_scdc Cyclomatic Complexity 4 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c:dw_hdmi_poweroff Cyclomatic Complexity 4 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c:dw_hdmi_update_phy_mask Cyclomatic Complexity 7 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c:dw_hdmi_bridge_mode_valid Cyclomatic Complexity 4 include/linux/device.h:dev_name Cyclomatic Complexity 1 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c:hdmi_modb Cyclomatic Complexity 1 dri
Re: [v2 2/2] drm/panel: support for auo, kd101n80-45na wuxga dsi video mode panel
On Mon, Jun 24, 2019 at 4:00 PM Jitao Shi wrote:
>
> Auo,kd101n80-45na's connector is same as boe,tv101wum-nl6.
> The most codes can be reuse.
> So auo,kd101n80-45na and boe,tv101wum-nl6 use one driver file.
> Add the different parts in driver data.
>
> Signed-off-by: Jitao Shi
> ---
> .../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 40 +++
> 1 file changed, 40 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
> b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
> index 6e06c8506623..d1ee43cfcbe2 100644
> --- a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
> +++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
> @@ -372,6 +372,15 @@ static const struct panel_init_cmd boe_init_cmd[] = {
> {},
> };
>
> +static const struct panel_init_cmd auo_init_cmd[] = {
> + _INIT_DELAY_CMD(24),
> + _INIT_DCS_CMD(0x11),
> + _INIT_DELAY_CMD(120),
> + _INIT_DCS_CMD(0x29),
> + _INIT_DELAY_CMD(120),
> + {},
> +};
> +
> static inline struct boe_panel *to_boe_panel(struct drm_panel *panel)
> {
> return container_of(panel, struct boe_panel, base);
> @@ -572,6 +581,34 @@ static const struct panel_desc boe_tv101wum_nl6_desc = {
> .init_cmds = boe_init_cmd,
> };
>
> +static const struct drm_display_mode auo_default_mode = {
> + .clock = 157000,
> + .hdisplay = 1200,
> + .hsync_start = 1200 + 80,
> + .hsync_end = 1200 + 80 + 24,
> + .htotal = 1200 + 80 + 24 + 36,
> + .vdisplay = 1920,
> + .vsync_start = 1920 + 16,
> + .vsync_end = 1920 + 16 + 4,
> + .vtotal = 1920 + 16 + 4 + 16,
> + .vrefresh = 60,
> + .type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
> +};
> +
> +static const struct panel_desc auo_kd101n80_45na_desc = {
> + .modes = &auo_default_mode,
> + .bpc = 8,
> + .size = {
> + .width = 216,
> + .height = 135,
Same issue as the BOE panel:
This is wrong, as this is a portrait panel, should be: width=135, height=216.
> + },
> + .lanes = 4,
> + .format = MIPI_DSI_FMT_RGB888,
> + .mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
> + MIPI_DSI_MODE_LPM,
> + .init_cmds = auo_init_cmd,
> +};
> +
> static int boe_panel_get_modes(struct drm_panel *panel)
> {
> struct boe_panel *boe = to_boe_panel(panel);
> @@ -695,6 +732,9 @@ static const struct of_device_id boe_of_match[] = {
> { .compatible = "boe,tv101wum-nl6",
> .data = &boe_tv101wum_nl6_desc
> },
> + { .compatible = "auo,kd101n80-45na",
> + .data = &auo_kd101n80_45na_desc
> + },
> { /* sentinel */ }
> };
> MODULE_DEVICE_TABLE(of, boe_of_match);
> --
> 2.21.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v2 2/2] drm/panel: support for BOE tv101wum-nl6 wuxga dsi video mode panel
On Mon, Jun 24, 2019 at 4:25 PM Nicolas Boichat wrote:
>
> On Mon, Jun 24, 2019 at 2:04 PM Jitao Shi wrote:
> >
> > Add driver for BOE tv101wum-nl6 panel is a 10.1" 1200x1920 panel.
> >
> > Signed-off-by: Jitao Shi
> > ---
> > drivers/gpu/drm/panel/Kconfig | 10 +
> > drivers/gpu/drm/panel/Makefile| 1 +
> > .../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 715 ++
> > 3 files changed, 726 insertions(+)
> > create mode 100644 drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
> >
> > diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> > index e36dbb4df867..2b055ce0700b 100644
> > --- a/drivers/gpu/drm/panel/Kconfig
> > +++ b/drivers/gpu/drm/panel/Kconfig
> > @@ -17,6 +17,15 @@ config DRM_PANEL_ARM_VERSATILE
> > reference designs. The panel is detected using special registers
> > in the Versatile family syscon registers.
> >
> > +config DRM_PANEL_BOE_TV101WUM_NL6
> > + tristate "BOE TV101WUM 1200x1920 panel"
> > + depends on OF
> > + depends on DRM_MIPI_DSI
> > + depends on BACKLIGHT_CLASS_DEVICE
> > + help
> > + Say Y here if you want to support for BOE TV101WUM WUXGA PANEL
> > + DSI Video Mode panel
> > +
> > config DRM_PANEL_LVDS
> > tristate "Generic LVDS panel driver"
> > depends on OF
> > @@ -272,4 +281,5 @@ config DRM_PANEL_TRULY_NT35597_WQXGA
> > help
> > Say Y here if you want to enable support for Truly NT35597 WQXGA
> > Dual DSI
> > Video Mode panel
> > +
>
> Drop this change.
>
> > endmenu
> > diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> > index 78e3dc376bdd..8d009223c44e 100644
> > --- a/drivers/gpu/drm/panel/Makefile
> > +++ b/drivers/gpu/drm/panel/Makefile
> > @@ -1,5 +1,6 @@
> > # SPDX-License-Identifier: GPL-2.0
> > obj-$(CONFIG_DRM_PANEL_ARM_VERSATILE) += panel-arm-versatile.o
> > +obj-$(CONFIG_DRM_PANEL_BOE_TV101WUM_NL6) += panel-boe-tv101wum-nl6.o
> > obj-$(CONFIG_DRM_PANEL_LVDS) += panel-lvds.o
> > obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
> > obj-$(CONFIG_DRM_PANEL_FEIYANG_FY07024DI26A30D) +=
> > panel-feiyang-fy07024di26a30d.o
> > diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
> > b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
> > new file mode 100644
> > index ..6e06c8506623
> > --- /dev/null
> > +++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
> > @@ -0,0 +1,715 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (c) 2018 MediaTek Inc.
> > + * Author: Jitao Shi
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +
> > +struct panel_desc {
> > + const struct drm_display_mode *modes;
> > + unsigned int bpc;
> > +
> > + /**
> > +* @width: width (in millimeters) of the panel's active display area
> > +* @height: height (in millimeters) of the panel's active display
> > area
> > +*/
> > + struct {
> > + unsigned int width;
> > + unsigned int height;
> > + } size;
> > +
> > + unsigned long mode_flags;
> > + enum mipi_dsi_pixel_format format;
> > + const struct panel_init_cmd *init_cmds;
> > + unsigned int lanes;
> > +};
> > +
> > +struct boe_panel {
> > + struct drm_panel base;
> > + struct mipi_dsi_device *dsi;
> > +
> > + const struct panel_desc *desc;
> > +
> > + struct backlight_device *backlight;
> > + struct regulator *pp1800;
> > + struct regulator *avee;
> > + struct regulator *avdd;
> > + struct gpio_desc *enable_gpio;
> > +
> > + bool prepared;
> > + bool enabled;
> > +
> > + const struct drm_display_mode *mode;
> > +};
> > +
> > +enum dsi_cmd_type {
> > + INIT_DCS_CMD,
> > + DELAY_CMD,
> > +};
> > +
> > +struct panel_init_cmd {
> > + enum dsi_cmd_type type;
> > + size_t len;
> > + const char *data;
> > +};
> > +
> > +#define _INIT_DCS_CMD(...) { \
> > + .type = INIT_DCS_CMD, \
> > + .len = sizeof((char[]){__VA_ARGS__}), \
> > + .data = (char[]){__VA_ARGS__} }
> > +
> > +#define _INIT_DELAY_CMD(...) { \
> > + .type = DELAY_CMD,\
> > + .len = sizeof((char[]){__VA_ARGS__}), \
> > + .data = (char[]){__VA_ARGS__} }
> > +
> > +static const struct panel_init_cmd boe_init_cmd[] = {
> > + _INIT_DELAY_CMD(24),
> > + _INIT_DCS_CMD(0xB0, 0x05),
> > + _INIT_DCS_CMD(0xB1, 0xE5),
> > + _INIT_DCS_CMD(0xB3, 0x52),
> > + _INIT_DCS_CMD(0xB0, 0x00),
> > + _INIT_DCS_CMD(0xB3, 0x88),
> > + _INIT_DCS_CMD(0xB0, 0x04),
> > + _INIT_DCS_CMD(0xB8, 0x00),
> > + _INIT_DCS_CMD(0xB0, 0x00),
> > + _INIT_DCS_CMD(0xB6, 0x03),
> > + _INIT_DCS_CMD(0xBA, 0x8B),
> > + _INIT_DCS_CMD(0xBF, 0
Re: [PATCH 0/9] drm: meson: global clean-up (use proper macros, update comments ...)
Julien Masson writes: > This patch series aims to clean-up differents parts of the drm meson > code source. > > Couple macros have been defined and used to set several registers > instead of using magic constants. > > I also took the opportunity to: > - add/remove/update comments > - remove useless code > - minor fix/improvment Nice set of cleanups, thanks! I especially like the extra in-code comments. Could you also add to the cover-letter how this was tested, and on what platforms so we know it's not going to introduce any regressions. Thanks, Kevin ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 8/9] drm: meson: add macro used to enable HDMI PLL
Julien Masson writes: > This patch add new macro HHI_HDMI_PLL_CNTL_EN which is used to enable > HDMI PLL. > > Signed-off-by: Julien Masson > --- > drivers/gpu/drm/meson/meson_vclk.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/meson/meson_vclk.c > b/drivers/gpu/drm/meson/meson_vclk.c > index e7c2b439d0f7..be6e152fc75a 100644 > --- a/drivers/gpu/drm/meson/meson_vclk.c > +++ b/drivers/gpu/drm/meson/meson_vclk.c > @@ -96,6 +96,7 @@ > #define HHI_VDAC_CNTL1 0x2F8 /* 0xbe offset in data sheet */ > > #define HHI_HDMI_PLL_CNTL0x320 /* 0xc8 offset in data sheet */ > +#define HHI_HDMI_PLL_CNTL_EN BIT(30) > #define HHI_HDMI_PLL_CNTL2 0x324 /* 0xc9 offset in data sheet */ > #define HHI_HDMI_PLL_CNTL3 0x328 /* 0xca offset in data sheet */ > #define HHI_HDMI_PLL_CNTL4 0x32C /* 0xcb offset in data sheet */ > @@ -468,7 +469,7 @@ void meson_hdmi_pll_set_params(struct meson_drm *priv, > unsigned int m, > > /* Enable and unreset */ > regmap_update_bits(priv->hhi, HHI_HDMI_PLL_CNTL, > -0x7 << 28, 0x4 << 28); > +0x7 << 28, HHI_HDMI_PLL_CNTL_EN); still using a magic const for the mask. Can use GENMASK() for this? Kevin ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/9] drm: meson: vpp: use proper macros instead of magic constants
Julien Masson writes:
> This patch add new macros which are used to set the following
> registers:
> - VPP_OSD_SCALE_COEF_IDX
> - VPP_DOLBY_CTRL
> - VPP_OFIFO_SIZE
> - VPP_HOLD_LINES
> - VPP_SC_MISC
> - VPP_VADJ_CTRL
>
> Signed-off-by: Julien Masson
[...]
> @@ -97,20 +97,22 @@ void meson_vpp_init(struct meson_drm *priv)
> else if (meson_vpu_is_compatible(priv, "amlogic,meson-gxm-vpu")) {
> writel_bits_relaxed(0xff << 16, 0xff << 16,
> priv->io_base + _REG(VIU_MISC_CTRL1));
> - writel_relaxed(0x2, priv->io_base + _REG(VPP_DOLBY_CTRL));
> - writel_relaxed(0x1020080,
> + writel_relaxed(VPP_PPS_DUMMY_DATA_MODE,
> +priv->io_base + _REG(VPP_DOLBY_CTRL));
> + writel_relaxed(0x108080,
nit: still a magic constant here, and it's not obvious why it's
different from the current one.
Kevin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/4] drm/panel: set display info in panel attach
On Fri, Jun 21, 2019 at 8:41 PM Derek Basehore wrote:
>
> Devicetree systems can set panel orientation via a panel binding, but
> there's no way, as is, to propagate this setting to the connector,
> where the property need to be added.
> To address this, this patch sets orientation, as well as other fixed
> values for the panel, in the drm_panel_attach function. These values
> are stored from probe in the drm_panel struct.
>
> Signed-off-by: Derek Basehore
> ---
> drivers/gpu/drm/drm_panel.c | 28
> include/drm/drm_panel.h | 14 ++
> 2 files changed, 42 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
> index 507099af4b57..5690fca30236 100644
> --- a/drivers/gpu/drm/drm_panel.c
> +++ b/drivers/gpu/drm/drm_panel.c
> @@ -104,11 +104,23 @@ EXPORT_SYMBOL(drm_panel_remove);
> */
> int drm_panel_attach(struct drm_panel *panel, struct drm_connector
> *connector)
> {
> + struct drm_display_info *info;
> +
> if (panel->connector)
> return -EBUSY;
>
> panel->connector = connector;
> panel->drm = connector->dev;
> + info = &connector->display_info;
> + info->width_mm = panel->width_mm;
> + info->height_mm = panel->height_mm;
> + info->bpc = panel->bpc;
> + info->panel_orientation = panel->orientation;
> + info->bus_flags = panel->bus_flags;
> + if (panel->bus_formats)
> + drm_display_info_set_bus_formats(&connector->display_info,
> +panel->bus_formats,
> +panel->num_bus_formats);
>
> return 0;
> }
> @@ -128,6 +140,22 @@ EXPORT_SYMBOL(drm_panel_attach);
> */
> int drm_panel_detach(struct drm_panel *panel)
> {
> + struct drm_display_info *info;
> +
> + if (!panel->connector)
> + goto out;
> +
> + info = &panel->connector->display_info;
> + info->width_mm = 0;
> + info->height_mm = 0;
> + info->bpc = 0;
> + info->panel_orientation = DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
> + info->bus_flags = 0;
> + kfree(info->bus_formats);
> + info->bus_formats = NULL;
> + info->num_bus_formats = 0;
> +
> +out:
> panel->connector = NULL;
> panel->drm = NULL;
>
> diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
> index 3564952f1a4f..760ca5865962 100644
> --- a/include/drm/drm_panel.h
> +++ b/include/drm/drm_panel.h
> @@ -37,6 +37,8 @@ struct display_timing;
> * struct drm_panel_funcs - perform operations on a given panel
> * @disable: disable panel (turn off back light, etc.)
> * @unprepare: turn off panel
> + * @detach: detach panel->connector (clear internal state, etc.)
> + * @attach: attach panel->connector (update internal state, etc.)
> * @prepare: turn on panel and perform set up
> * @enable: enable panel (turn on back light, etc.)
> * @get_modes: add modes to the connector that the panel is attached to and
> @@ -93,6 +95,18 @@ struct drm_panel {
>
> const struct drm_panel_funcs *funcs;
>
> + /*
> +* panel information to be set in the connector when the panel is
> +* attached.
> +*/
> + unsigned int width_mm;
> + unsigned int height_mm;
> + unsigned int bpc;
> + int orientation;
> + const u32 *bus_formats;
> + unsigned int num_bus_formats;
> + u32 bus_flags;
Should probably put these in a struct to ensure the connector and
panel have the same data types. Will do in a following patch if we
stay with this.
> +
> struct list_head list;
> };
>
> --
> 2.22.0.410.gd8fdbe21b5-goog
>
Re: [PATCH v2 10/15] dt-bindings: display: Convert tpo,tpg110 panel to DT schema
On Mon, Jun 24, 2019 at 4:13 PM Linus Walleij wrote: > > On Mon, Jun 24, 2019 at 11:59 PM Rob Herring wrote: > > > Convert the tpo,tpg110 panel binding to DT schema. > > > > Cc: Linus Walleij > > Cc: Thierry Reding > > Cc: Sam Ravnborg > > Cc: Maxime Ripard > > Cc: Laurent Pinchart > > Cc: dri-devel@lists.freedesktop.org > > Signed-off-by: Rob Herring > > Awesome, fixed up the MAINATINERS entry and applied and > pushed for DRM next with my Reviewed-by. You shouldn't have because this is dependent on patch 2 and panel-common.yaml. So now 'make dt_binding_check' is broken. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH][next] drm/vmwgfx: remove redundant assignment to sub_res
From: Colin Ian King
Variable sub_res is initialized to a value that is never read and it
is re-assigned later in a for-loop. The initialization is redundant
and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
index 862ca44680ca..3257ba689d93 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
@@ -1914,7 +1914,7 @@ static void vmw_surface_tex_dirty_range_add(struct
vmw_resource *res,
} else {
/* Dirty range covers multiple sub-resources */
struct svga3dsurface_loc loc_min, loc_max;
- u32 sub_res = loc1.sub_resource;
+ u32 sub_res;
svga3dsurface_max_loc(cache, loc1.sub_resource, &loc_max);
vmw_subres_dirty_add(dirty, &loc1, &loc_max);
--
2.20.1
[PATCH] fbmem: remove redundant assignment to err
From: Colin Ian King
Variable err is initialized to a value that is never read and it
is re-assigned later. The initialization is redundant and can
be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King
---
drivers/video/fbdev/core/fbmem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index dd1a708df1a7..ae044a1325ca 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1987,7 +1987,7 @@ int fb_new_modelist(struct fb_info *info)
struct list_head *pos, *n;
struct fb_modelist *modelist;
struct fb_videomode *m, mode;
- int err = 1;
+ int err;
list_for_each_safe(pos, n, &info->modelist) {
modelist = list_entry(pos, struct fb_modelist, list);
--
2.20.1
Re: [PATCHv8 12/13] tda998x: use cec_notifier_conn_(un)register
Hi Hans,
I love your patch! Yet something to improve:
[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v5.2-rc6 next-20190621]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Hans-Verkuil/cec-improve-notifier-support-add-connector-info/20190625-043917
base: git://linuxtv.org/media_tree.git master
config: x86_64-rhel-7.2 (attached as .config)
compiler: clang version 9.0.0 (git://gitmirror/llvm_project
fb2bd4a9398b35ee4f732ea0847d9c1226fc4cf3)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
>> drivers/gpu//drm/i2c/tda998x_drv.c:1292:30: error: incompatible pointer
>> types passing 'struct cec_connector_info *' to parameter of type 'const
>> struct drm_connector *' [-Werror,-Wincompatible-pointer-types]
cec_fill_conn_info_from_drm(&conn_info, connector);
^~
include/media/cec.h:381:57: note: passing argument to parameter 'connector'
here
cec_fill_conn_info_from_drm(const struct drm_connector *connector,
^
>> drivers/gpu//drm/i2c/tda998x_drv.c:1292:42: error: incompatible pointer
>> types passing 'struct drm_connector *' to parameter of type 'struct
>> cec_connector_info *' [-Werror,-Wincompatible-pointer-types]
cec_fill_conn_info_from_drm(&conn_info, connector);
^
include/media/cec.h:382:35: note: passing argument to parameter 'conn_info'
here
struct cec_connector_info *conn_info)
^
2 errors generated.
vim +1292 drivers/gpu//drm/i2c/tda998x_drv.c
1251
1252 static int tda998x_connector_init(struct tda998x_priv *priv,
1253struct drm_device *drm)
1254 {
1255 struct drm_connector *connector = &priv->connector;
1256 struct cec_connector_info conn_info;
1257 struct i2c_board_info cec_info;
1258 int ret;
1259
1260 connector->interlace_allowed = 1;
1261
1262 if (priv->hdmi->irq)
1263 connector->polled = DRM_CONNECTOR_POLL_HPD;
1264 else
1265 connector->polled = DRM_CONNECTOR_POLL_CONNECT |
1266 DRM_CONNECTOR_POLL_DISCONNECT;
1267
1268 drm_connector_helper_add(connector,
&tda998x_connector_helper_funcs);
1269 ret = drm_connector_init(drm, connector,
&tda998x_connector_funcs,
1270 DRM_MODE_CONNECTOR_HDMIA);
1271 if (ret)
1272 return ret;
1273
1274 /*
1275 * Some TDA998x are actually two I2C devices merged onto one
piece
1276 * of silicon: TDA9989 and TDA19989 combine the HDMI transmitter
1277 * with a slightly modified TDA9950 CEC device. The CEC device
1278 * is at the TDA9950 address, with the address pins strapped
across
1279 * to the TDA998x address pins. Hence, it always has the same
1280 * offset.
1281 */
1282 memset(&cec_info, 0, sizeof(cec_info));
1283 strlcpy(cec_info.type, "tda9950", sizeof(cec_info.type));
1284 cec_info.addr = priv->cec_addr;
1285 cec_info.platform_data = &priv->cec_glue;
1286 cec_info.irq = priv->hdmi->irq;
1287
1288 priv->cec = i2c_new_device(priv->hdmi->adapter, &cec_info);
1289 if (!priv->cec)
1290 return -ENODEV;
1291
> 1292 cec_fill_conn_info_from_drm(&conn_info, connector);
1293
1294 priv->cec_notify =
cec_notifier_conn_register(priv->cec_glue.parent,
1295NULL, &conn_info);
1296 if (!priv->cec_notify)
1297 return -ENOMEM;
1298
1299 drm_connector_attach_encoder(&priv->connector,
1300 priv->bridge.encoder);
1301
1302 return 0;
1303 }
1304
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm/msm/dpu: Correct dpu encoder spinlock initialization
On 2019-06-23 23:27, Shubhashree Dhar wrote: dpu encoder spinlock should be initialized during dpu encoder init instead of dpu encoder setup which is part of commit. There are chances that vblank control uses the uninitialized spinlock if not initialized during encoder init. Not much can be done if someone is performing a vblank operation before encoder_setup is done. Can you point to the path where this lock is acquired before the encoder_setup? Thanks Jeykumar S. Change-Id: I5a18b95fa47397c834a266b22abf33a517b03a4e Signed-off-by: Shubhashree Dhar --- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c index 5f085b5..22938c7 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c @@ -2195,8 +2195,6 @@ int dpu_encoder_setup(struct drm_device *dev, struct drm_encoder *enc, if (ret) goto fail; - spin_lock_init(&dpu_enc->enc_spinlock); - atomic_set(&dpu_enc->frame_done_timeout, 0); timer_setup(&dpu_enc->frame_done_timer, dpu_encoder_frame_done_timeout, 0); @@ -2250,6 +2248,7 @@ struct drm_encoder *dpu_encoder_init(struct drm_device *dev, drm_encoder_helper_add(&dpu_enc->base, &dpu_encoder_helper_funcs); + spin_lock_init(&dpu_enc->enc_spinlock); dpu_enc->enabled = false; return &dpu_enc->base; -- Jeykumar S
Re: [PATCH v2 10/15] dt-bindings: display: Convert tpo,tpg110 panel to DT schema
On Mon, Jun 24, 2019 at 11:59 PM Rob Herring wrote: > Convert the tpo,tpg110 panel binding to DT schema. > > Cc: Linus Walleij > Cc: Thierry Reding > Cc: Sam Ravnborg > Cc: Maxime Ripard > Cc: Laurent Pinchart > Cc: dri-devel@lists.freedesktop.org > Signed-off-by: Rob Herring Awesome, fixed up the MAINATINERS entry and applied and pushed for DRM next with my Reviewed-by. Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/mcde: Fix uninitialized variable
On Tue, Jun 18, 2019 at 2:31 PM Dan Carpenter wrote: > Thanks! Recording this as Acked-by: when applying. Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] backlight: pwm_bl: Set pin to sleep state when powered down
On Fri, Jun 21, 2019 at 3:56 PM Thierry Reding wrote: > I'm not sure this would actually work because I think the way that > pinctrl handles states both "init" and "idle" would be the same pointer > values and therefore pinctrl_init_done() would think the driver didn't > change away from the "init" state because it is the same pointer value > as the "idle" state that the driver selected. Right. > One way to work around > that would be to duplicate the "idle" state definition and associate one > instance of it with the "idle" state and the other with the "init" > state. At that point both states should be different (different pointer > values) and we'd get the init state selected automatically before probe, > select "idle" during probe and then the core will leave it alone. That's > of course ugly because we duplicate the pinctrl state in DT, but perhaps > it's the least ugly solution. If something needs special mockery and is not generic, I'd just come up with whatever string PWM needs, like "pwm-idle", "pwm-sleep", "pwm-init" etc instead of complicating the stuff done before probe(). These states are only handled there to make probe() simple in simple cases. > Adding Linus for visibility. Perhaps he can share some insight. I think Paul hashed it out. Or will. > On that note, I'm wondering if perhaps it'd make sense for pinctrl to > support some mode where a device would start out in idle mode. That is, > where pinctrl_bind_pins() would select the "idle" mode as the default > before probe. With something like that we could easily support this > use-case without glitching. I would say the driver can come up with whatever state it need for that and handle it explicitly. When there are so many of them that it warrants growing the device core, we can move it into drivers/base/pinctrl.c. But no upfront design. > I suppose yet another variant would be for the PWM backlight to not use > any of the standard pinctrl states at all. Instead it could just define > custom states, say "active" and "inactive". I would suggest doing that. > Looking at the code that > would prevent pinctrl_bind_pins() from doing anything with pinctrl > states and given the driver exact control over when each of the states > will be selected. That's somewhat suboptimal because we can't make use > of the pinctrl PM helpers and it'd require more boilerplate. The helpers are just for the dirt-simple cases anyway. At one point one developer thought that the "default" set up before probe would be the only thing any system would ever want to do with pin control. It seems like not. Yours, Linus Walleij
[PATCH v2 15/15] dt-bindings: display: Convert sgd, gktw70sdae4se panel to DT schema
Convert the sgd,gktw70sdae4se LVDS panel binding to DT schema.
Cc: Neil Armstrong
Cc: Thierry Reding
Cc: Sam Ravnborg
Cc: Maxime Ripard
Cc: Laurent Pinchart
Signed-off-by: Rob Herring
---
.../display/panel/sgd,gktw70sdae4se.txt | 41
.../display/panel/sgd,gktw70sdae4se.yaml | 63 +++
2 files changed, 63 insertions(+), 41 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.txt
create mode 100644
Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.txt
b/Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.txt
deleted file mode 100644
index d06644b555bd..
--- a/Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.txt
+++ /dev/null
@@ -1,41 +0,0 @@
-Solomon Goldentek Display GKTW70SDAE4SE LVDS Display Panel
-==
-
-The GKTW70SDAE4SE is a 7" WVGA TFT-LCD display panel.
-
-These DT bindings follow the LVDS panel bindings defined in panel-lvds.txt
-with the following device-specific properties.
-
-Required properties:
-
-- compatible: Shall contain "sgd,gktw70sdae4se" and "panel-lvds", in that
order.
-
-Example
-
-panel {
- compatible = "sgd,gktw70sdae4se", "panel-lvds";
-
- width-mm = <153>;
- height-mm = <86>;
-
- data-mapping = "jeida-18";
-
- panel-timing {
- clock-frequency = <3200>;
- hactive = <800>;
- vactive = <480>;
- hback-porch = <39>;
- hfront-porch = <39>;
- vback-porch = <29>;
- vfront-porch = <13>;
- hsync-len = <47>;
- vsync-len = <2>;
- };
-
- port {
- panel_in: endpoint {
- remote-endpoint = <&lvds_encoder>;
- };
- };
-};
diff --git
a/Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.yaml
b/Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.yaml
new file mode 100644
index ..487283288cb0
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/sgd,gktw70sdae4se.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Solomon Goldentek Display GKTW70SDAE4SE 7" WVGA LVDS Display Panel
+
+maintainers:
+ - Neil Armstrong
+ - Thierry Reding
+
+allOf:
+ - $ref: lvds.yaml#
+
+properties:
+ compatible:
+items:
+ - const: sgd,gktw70sdae4se
+ - {} # panel-lvds, but not listed here to avoid false select
+
+ data-mapping:
+const: jeida-18
+
+ width-mm:
+const: 153
+
+ height-mm:
+const: 86
+
+required:
+ - compatible
+
+examples:
+ - |+
+panel {
+ compatible = "sgd,gktw70sdae4se", "panel-lvds";
+
+ width-mm = <153>;
+ height-mm = <86>;
+
+ data-mapping = "jeida-18";
+
+ panel-timing {
+clock-frequency = <3200>;
+hactive = <800>;
+vactive = <480>;
+hback-porch = <39>;
+hfront-porch = <39>;
+vback-porch = <29>;
+vfront-porch = <13>;
+hsync-len = <47>;
+vsync-len = <2>;
+ };
+
+ port {
+panel_in: endpoint {
+ remote-endpoint = <&lvds_encoder>;
+};
+ };
+};
+
+...
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 11/15] dt-bindings: display: Convert panel-lvds to DT schema
Convert the panel-lvds binding to use DT schema. The panel-lvds schema inherits from the panel-common.yaml schema and specific LVDS panel bindings should inherit from this schema. Cc: Thierry Reding Cc: Sam Ravnborg Cc: Laurent Pinchart Cc: dri-devel@lists.freedesktop.org Reviewed-by: Maxime Ripard Acked-by: Thierry Reding Signed-off-by: Rob Herring --- .../bindings/display/panel/lvds.yaml | 107 .../bindings/display/panel/panel-lvds.txt | 121 -- 2 files changed, 107 insertions(+), 121 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/panel/lvds.yaml delete mode 100644 Documentation/devicetree/bindings/display/panel/panel-lvds.txt diff --git a/Documentation/devicetree/bindings/display/panel/lvds.yaml b/Documentation/devicetree/bindings/display/panel/lvds.yaml new file mode 100644 index ..d0083301acbe --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/lvds.yaml @@ -0,0 +1,107 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/lvds.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: LVDS Display Panel + +maintainers: + - Laurent Pinchart + - Thierry Reding + +description: |+ + LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A. Multiple + incompatible data link layers have been used over time to transmit image data + to LVDS panels. This bindings supports display panels compatible with the + following specifications. + + [JEIDA] "Digital Interface Standards for Monitor", JEIDA-59-1999, February + 1999 (Version 1.0), Japan Electronic Industry Development Association (JEIDA) + [LDI] "Open LVDS Display Interface", May 1999 (Version 0.95), National + Semiconductor + [VESA] "VESA Notebook Panel Standard", October 2007 (Version 1.0), Video + Electronics Standards Association (VESA) + + Device compatible with those specifications have been marketed under the + FPD-Link and FlatLink brands. + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: +contains: + const: panel-lvds +description: + Shall contain "panel-lvds" in addition to a mandatory panel-specific + compatible string defined in individual panel bindings. The "panel-lvds" + value shall never be used on its own. + + data-mapping: +enum: + - jeida-18 + - jeida-24 + - vesa-24 +description: | + The color signals mapping order. + + LVDS data mappings are defined as follows. + + - "jeida-18" - 18-bit data mapping compatible with the [JEIDA], [LDI] and +[VESA] specifications. Data are transferred as follows on 3 LVDS lanes. + + Slot 0 1 2 3 4 5 6 + _ + Clock\___/ + __ __ __ __ __ __ __ + DATA0><__G0__><__R5__><__R4__><__R3__><__R2__><__R1__><__R0__>< + DATA1><__B1__><__B0__><__G5__><__G4__><__G3__><__G2__><__G1__>< + DATA2><_CTL2_><_CTL1_><_CTL0_><__B5__><__B4__><__B3__><__B2__>< + + - "jeida-24" - 24-bit data mapping compatible with the [DSIM] and [LDI] +specifications. Data are transferred as follows on 4 LVDS lanes. + + Slot 0 1 2 3 4 5 6 + _ + Clock\___/ + __ __ __ __ __ __ __ + DATA0><__G2__><__R7__><__R6__><__R5__><__R4__><__R3__><__R2__>< + DATA1><__B3__><__B2__><__G7__><__G6__><__G5__><__G4__><__G3__>< + DATA2><_CTL2_><_CTL1_><_CTL0_><__B7__><__B6__><__B5__><__B4__>< + DATA3><_CTL3_><__B1__><__B0__><__G1__><__G0__><__R1__><__R0__>< + + - "vesa-24" - 24-bit data mapping compatible with the [VESA] specification. +Data are transferred as follows on 4 LVDS lanes. + + Slot 0 1 2 3 4 5 6 + _ + Clock\___/ + __ __ __ __ __ __ __ + DATA0><__G0__><__R5__><__R4__><__R3__><__R2__><__R1__><__R0__>< + DATA1><__B1__><__B0__><__G5__><__G4__><__G3__><__G2__><__G1__>< + DATA2><_CTL2_><_CTL1_><_CTL0_><__B5__><__B4__><__B3__><__B2__>< + DATA3><_CTL3_><__B7__><__B6__><__G7__><__G6__><__R7__><__R6__>< + + Control signals are mapped as follows. + + CTL0: HSync + CTL1: VSync + CTL2: Data Enable + CTL3: 0 + + data-mirror: +type: boolean +description: + If set, reverse the bit order described in the data mappings below on all + data lanes, transmitting bits for slots 6 to 0 instead of 0 to 6.
[PATCH v2 09/15] dt-bindings: display: Convert tfc, s9700rtwv43tr-01b panel to DT schema
Convert the tfc,s9700rtwv43tr-01b panel binding to DT schema. Cc: Heiko Stuebner Cc: Thierry Reding Cc: Sam Ravnborg Cc: Maxime Ripard Cc: Laurent Pinchart Cc: dri-devel@lists.freedesktop.org Signed-off-by: Rob Herring --- .../display/panel/tfc,s9700rtwv43tr-01b.txt | 15 -- .../display/panel/tfc,s9700rtwv43tr-01b.yaml | 30 +++ 2 files changed, 30 insertions(+), 15 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/panel/tfc,s9700rtwv43tr-01b.txt create mode 100644 Documentation/devicetree/bindings/display/panel/tfc,s9700rtwv43tr-01b.yaml diff --git a/Documentation/devicetree/bindings/display/panel/tfc,s9700rtwv43tr-01b.txt b/Documentation/devicetree/bindings/display/panel/tfc,s9700rtwv43tr-01b.txt deleted file mode 100644 index dfb572f085eb.. --- a/Documentation/devicetree/bindings/display/panel/tfc,s9700rtwv43tr-01b.txt +++ /dev/null @@ -1,15 +0,0 @@ -TFC S9700RTWV43TR-01B 7" Three Five Corp 800x480 LCD panel with -resistive touch - -The panel is found on TI AM335x-evm. - -Required properties: -- compatible: should be "tfc,s9700rtwv43tr-01b" -- power-supply: See panel-common.txt - -Optional properties: -- enable-gpios: GPIO pin to enable or disable the panel, if there is one -- backlight: phandle of the backlight device attached to the panel - -This binding is compatible with the simple-panel binding, which is specified -in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/display/panel/tfc,s9700rtwv43tr-01b.yaml b/Documentation/devicetree/bindings/display/panel/tfc,s9700rtwv43tr-01b.yaml new file mode 100644 index ..614f4a8d8403 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/tfc,s9700rtwv43tr-01b.yaml @@ -0,0 +1,30 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/tfc,s9700rtwv43tr-01b.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TFC S9700RTWV43TR-01B 7" Three Five Corp 800x480 LCD panel with resistive touch + +maintainers: + - Jyri Sarha + - Thierry Reding + +description: |+ + The panel is found on TI AM335x-evm. + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: +const: tfc,s9700rtwv43tr-01b + + enable-gpios: true + backlight: true + +required: + - compatible + - power-supply + +... -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 08/15] dt-bindings: display: Convert raspberrypi,7inch-touchscreen panel to DT schema
Convert the raspberrypi,7inch-touchscreen panel binding to DT schema.
Cc: Eric Anholt
Cc: Thierry Reding
Cc: Sam Ravnborg
Cc: Maxime Ripard
Cc: Laurent Pinchart
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Rob Herring
---
.../panel/raspberrypi,7inch-touchscreen.txt | 49 -
.../panel/raspberrypi,7inch-touchscreen.yaml | 71 +++
2 files changed, 71 insertions(+), 49 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touchscreen.txt
create mode 100644
Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touchscreen.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touchscreen.txt
b/Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touchscreen.txt
deleted file mode 100644
index e9e19c059260..
---
a/Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touchscreen.txt
+++ /dev/null
@@ -1,49 +0,0 @@
-This binding covers the official 7" (800x480) Raspberry Pi touchscreen
-panel.
-
-This DSI panel contains:
-
-- TC358762 DSI->DPI bridge
-- Atmel microcontroller on I2C for power sequencing the DSI bridge and
- controlling backlight
-- Touchscreen controller on I2C for touch input
-
-and this binding covers the DSI display parts but not its touch input.
-
-Required properties:
-- compatible: Must be "raspberrypi,7inch-touchscreen-panel"
-- reg: Must be "45"
-- port:See panel-common.txt
-
-Example:
-
-dsi1: dsi@7e70 {
- #address-cells = <1>;
- #size-cells = <0>;
- <...>
-
- port {
- dsi_out_port: endpoint {
- remote-endpoint = <&panel_dsi_port>;
- };
- };
-};
-
-i2c_dsi: i2c {
- compatible = "i2c-gpio";
- #address-cells = <1>;
- #size-cells = <0>;
- gpios = <&gpio 28 0
-&gpio 29 0>;
-
- lcd@45 {
- compatible = "raspberrypi,7inch-touchscreen-panel";
- reg = <0x45>;
-
- port {
- panel_dsi_port: endpoint {
- remote-endpoint = <&dsi_out_port>;
- };
- };
- };
-};
diff --git
a/Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touchscreen.yaml
b/Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touchscreen.yaml
new file mode 100644
index ..22a083f7bc8e
--- /dev/null
+++
b/Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touchscreen.yaml
@@ -0,0 +1,71 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id:
http://devicetree.org/schemas/display/panel/raspberrypi,7inch-touchscreen.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: The official 7" (800x480) Raspberry Pi touchscreen
+
+maintainers:
+ - Eric Anholt
+ - Thierry Reding
+
+description: |+
+ This DSI panel contains:
+
+ - TC358762 DSI->DPI bridge
+ - Atmel microcontroller on I2C for power sequencing the DSI bridge and
+controlling backlight
+ - Touchscreen controller on I2C for touch input
+
+ and this binding covers the DSI display parts but not its touch input.
+
+properties:
+ compatible:
+const: raspberrypi,7inch-touchscreen-panel
+
+ reg:
+const: 0x45
+
+ port: true
+
+required:
+ - compatible
+ - reg
+ - port
+
+additionalProperties: false
+
+examples:
+ - |+
+dsi1: dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port {
+dsi_out_port: endpoint {
+ remote-endpoint = <&panel_dsi_port>;
+};
+ };
+};
+
+i2c_dsi: i2c {
+ compatible = "i2c-gpio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ scl-gpios = <&gpio 28 0>;
+ sda-gpios = <&gpio 29 0>;
+
+ lcd@45 {
+compatible = "raspberrypi,7inch-touchscreen-panel";
+reg = <0x45>;
+
+port {
+ panel_dsi_port: endpoint {
+remote-endpoint = <&dsi_out_port>;
+ };
+};
+ };
+};
+
+...
--
2.20.1
[PATCH v2 07/15] dt-bindings: display: Convert pda,91-00156-a0 panel to DT schema
Convert the pda,91-00156-a0 panel binding to DT schema. Cc: Thierry Reding Cc: Sam Ravnborg Cc: Maxime Ripard Cc: Laurent Pinchart Cc: dri-devel@lists.freedesktop.org Signed-off-by: Rob Herring --- .../display/panel/pda,91-00156-a0.txt | 14 --- .../display/panel/pda,91-00156-a0.yaml| 25 +++ 2 files changed, 25 insertions(+), 14 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/panel/pda,91-00156-a0.txt create mode 100644 Documentation/devicetree/bindings/display/panel/pda,91-00156-a0.yaml diff --git a/Documentation/devicetree/bindings/display/panel/pda,91-00156-a0.txt b/Documentation/devicetree/bindings/display/panel/pda,91-00156-a0.txt deleted file mode 100644 index 1639fb17a9f0.. --- a/Documentation/devicetree/bindings/display/panel/pda,91-00156-a0.txt +++ /dev/null @@ -1,14 +0,0 @@ -PDA 91-00156-A0 5.0" WVGA TFT LCD panel - -Required properties: -- compatible: should be "pda,91-00156-a0" -- power-supply: this panel requires a single power supply. A phandle to a -regulator needs to be specified here. Compatible with panel-common binding which -is specified in the panel-common.txt in this directory. -- backlight: this panel's backlight is controlled by an external backlight -controller. A phandle to this controller needs to be specified here. -Compatible with panel-common binding which is specified in the panel-common.txt -in this directory. - -This binding is compatible with the simple-panel binding, which is specified -in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/display/panel/pda,91-00156-a0.yaml b/Documentation/devicetree/bindings/display/panel/pda,91-00156-a0.yaml new file mode 100644 index ..cea5bcb3c455 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/pda,91-00156-a0.yaml @@ -0,0 +1,25 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/pda,91-00156-a0.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: PDA 91-00156-A0 5.0" WVGA TFT LCD panel + +maintainers: + - Cristian Birsan + - Thierry Reding + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: +const: pda,91-00156-a0 + +required: + - compatible + - power-supply + - backlight + +... -- 2.20.1
[PATCH v2 13/15] dt-bindings: display: Convert mitsubishi, aa104xd12 panel to DT schema
Convert the mitsubishi,aa104xd12 LVDS panel binding to DT schema.
Cc: Thierry Reding
Cc: Sam Ravnborg
Cc: Maxime Ripard
Cc: Laurent Pinchart
Signed-off-by: Rob Herring
---
.../display/panel/mitsubishi,aa104xd12.txt| 47
.../display/panel/mitsubishi,aa104xd12.yaml | 71 +++
2 files changed, 71 insertions(+), 47 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.txt
create mode 100644
Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.txt
b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.txt
deleted file mode 100644
index ced0121aed7d..
--- a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.txt
+++ /dev/null
@@ -1,47 +0,0 @@
-Mitsubishi AA204XD12 LVDS Display Panel
-===
-
-The AA104XD12 is a 10.4" XGA TFT-LCD display panel.
-
-These DT bindings follow the LVDS panel bindings defined in panel-lvds.txt
-with the following device-specific properties.
-
-
-Required properties:
-
-- compatible: Shall contain "mitsubishi,aa121td01" and "panel-lvds", in that
- order.
-- vcc-supply: Reference to the regulator powering the panel VCC pins.
-
-
-Example
-
-panel {
- compatible = "mitsubishi,aa104xd12", "panel-lvds";
- vcc-supply = <&vcc_3v3>;
-
- width-mm = <210>;
- height-mm = <158>;
-
- data-mapping = "jeida-24";
-
- panel-timing {
- /* 1024x768 @65Hz */
- clock-frequency = <6500>;
- hactive = <1024>;
- vactive = <768>;
- hsync-len = <136>;
- hfront-porch = <20>;
- hback-porch = <160>;
- vfront-porch = <3>;
- vback-porch = <29>;
- vsync-len = <6>;
- };
-
- port {
- panel_in: endpoint {
- remote-endpoint = <&lvds_encoder>;
- };
- };
-};
diff --git
a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml
b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml
new file mode 100644
index ..fd97ca49c104
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml
@@ -0,0 +1,71 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/mitsubishi,aa104xd12.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mitsubishi AA104XD12 10.4" XGA LVDS Display Panel
+
+maintainers:
+ - Laurent Pinchart
+ - Thierry Reding
+
+allOf:
+ - $ref: lvds.yaml#
+
+properties:
+ compatible:
+items:
+ - const: mitsubishi,aa104xd12
+ - {} # panel-lvds, but not listed here to avoid false select
+
+ vcc-supply:
+description: Reference to the regulator powering the panel VCC pins.
+
+ data-mapping:
+const: jeida-24
+
+ width-mm:
+const: 210
+
+ height-mm:
+const: 158
+
+
+required:
+ - compatible
+ - vcc-supply
+
+examples:
+ - |+
+
+panel {
+ compatible = "mitsubishi,aa104xd12", "panel-lvds";
+ vcc-supply = <&vcc_3v3>;
+
+ width-mm = <210>;
+ height-mm = <158>;
+
+ data-mapping = "jeida-24";
+
+ panel-timing {
+/* 1024x768 @65Hz */
+clock-frequency = <6500>;
+hactive = <1024>;
+vactive = <768>;
+hsync-len = <136>;
+hfront-porch = <20>;
+hback-porch = <160>;
+vfront-porch = <3>;
+vback-porch = <29>;
+vsync-len = <6>;
+ };
+
+ port {
+panel_in: endpoint {
+ remote-endpoint = <&lvds_encoder>;
+};
+ };
+};
+
+...
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 10/15] dt-bindings: display: Convert tpo, tpg110 panel to DT schema
Convert the tpo,tpg110 panel binding to DT schema.
Cc: Linus Walleij
Cc: Thierry Reding
Cc: Sam Ravnborg
Cc: Maxime Ripard
Cc: Laurent Pinchart
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Rob Herring
---
.../bindings/display/panel/tpo,tpg110.txt | 70
.../bindings/display/panel/tpo,tpg110.yaml| 101 ++
2 files changed, 101 insertions(+), 70 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/display/panel/tpo,tpg110.txt
create mode 100644
Documentation/devicetree/bindings/display/panel/tpo,tpg110.yaml
diff --git a/Documentation/devicetree/bindings/display/panel/tpo,tpg110.txt
b/Documentation/devicetree/bindings/display/panel/tpo,tpg110.txt
deleted file mode 100644
index 40f3d7c713bb..
--- a/Documentation/devicetree/bindings/display/panel/tpo,tpg110.txt
+++ /dev/null
@@ -1,70 +0,0 @@
-TPO TPG110 Panel
-
-
-This panel driver is a component that acts as an intermediary
-between an RGB output and a variety of panels. The panel
-driver is strapped up in electronics to the desired resolution
-and other properties, and has a control interface over 3WIRE
-SPI. By talking to the TPG110 over SPI, the strapped properties
-can be discovered and the hardware is therefore mostly
-self-describing.
-
- ++
-SPI -> | TPO | -> physical display
-RGB -> | TPG110 |
- ++
-
-If some electrical strap or alternate resolution is desired,
-this can be set up by taking software control of the display
-over the SPI interface. The interface can also adjust
-for properties of the display such as gamma correction and
-certain electrical driving levels.
-
-The TPG110 does not know the physical dimensions of the panel
-connected, so this needs to be specified in the device tree.
-
-It requires a GPIO line for control of its reset line.
-
-The serial protocol has line names that resemble I2C but the
-protocol is not I2C but 3WIRE SPI.
-
-Required properties:
-- compatible : one of:
- "ste,nomadik-nhk15-display", "tpo,tpg110"
- "tpo,tpg110"
-- grestb-gpios : panel reset GPIO
-- width-mm : see display/panel/panel-common.txt
-- height-mm : see display/panel/panel-common.txt
-
-The device needs to be a child of an SPI bus, see
-spi/spi-bus.txt. The SPI child must set the following
-properties:
-- spi-3wire
-- spi-max-frequency = <300>;
-as these are characteristics of this device.
-
-The device node can contain one 'port' child node with one child
-'endpoint' node, according to the bindings defined in
-media/video-interfaces.txt. This node should describe panel's video bus.
-
-Example
-
-panel: display@0 {
- compatible = "tpo,tpg110";
- reg = <0>;
- spi-3wire;
- /* 320 ns min period ~= 3 MHz */
- spi-max-frequency = <300>;
- /* Width and height from data sheet */
- width-mm = <116>;
- height-mm = <87>;
- grestb-gpios = <&foo_gpio 5 GPIO_ACTIVE_LOW>;
- backlight = <&bl>;
-
- port {
- nomadik_clcd_panel: endpoint {
- remote-endpoint = <&foo>;
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/display/panel/tpo,tpg110.yaml
b/Documentation/devicetree/bindings/display/panel/tpo,tpg110.yaml
new file mode 100644
index ..a51660b73f28
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/tpo,tpg110.yaml
@@ -0,0 +1,101 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/tpo,tpg110.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TPO TPG110 Panel
+
+maintainers:
+ - Linus Walleij
+ - Thierry Reding
+
+description: |+
+ This panel driver is a component that acts as an intermediary
+ between an RGB output and a variety of panels. The panel
+ driver is strapped up in electronics to the desired resolution
+ and other properties, and has a control interface over 3WIRE
+ SPI. By talking to the TPG110 over SPI, the strapped properties
+ can be discovered and the hardware is therefore mostly
+ self-describing.
+
+ ++
+ SPI -> | TPO | -> physical display
+ RGB -> | TPG110 |
+ ++
+
+ If some electrical strap or alternate resolution is desired,
+ this can be set up by taking software control of the display
+ over the SPI interface. The interface can also adjust
+ for properties of the display such as gamma correction and
+ certain electrical driving levels.
+
+ The TPG110 does not know the physical dimensions of the panel
+ connected, so this needs to be specified in the device tree.
+
+ It requires a GPIO line for control of its reset line.
+
+ The serial protocol has line names that resemble I2C but the
+ protocol is not I2C but 3WIRE SPI.
+
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+oneOf:
+ - items:
+ - enum:
+ - ste,nomadik-nhk15-display
+ - const: tpo,tpg110
[PATCH v2 14/15] dt-bindings: display: Convert mitsubishi,aa121td01 panel to DT schema
Convert the mitsubishi,aa121td01 LVDS panel binding to DT schema.
Cc: Thierry Reding
Cc: Sam Ravnborg
Cc: Maxime Ripard
Cc: Laurent Pinchart
Signed-off-by: Rob Herring
---
.../display/panel/mitsubishi,aa121td01.txt| 47 -
.../display/panel/mitsubishi,aa121td01.yaml | 69 +++
2 files changed, 69 insertions(+), 47 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.txt
create mode 100644
Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.txt
b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.txt
deleted file mode 100644
index d6e1097504fe..
--- a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.txt
+++ /dev/null
@@ -1,47 +0,0 @@
-Mitsubishi AA121TD01 LVDS Display Panel
-===
-
-The AA121TD01 is a 12.1" WXGA TFT-LCD display panel.
-
-These DT bindings follow the LVDS panel bindings defined in panel-lvds.txt
-with the following device-specific properties.
-
-
-Required properties:
-
-- compatible: Shall contain "mitsubishi,aa121td01" and "panel-lvds", in that
- order.
-- vcc-supply: Reference to the regulator powering the panel VCC pins.
-
-
-Example
-
-panel {
- compatible = "mitsubishi,aa121td01", "panel-lvds";
- vcc-supply = <&vcc_3v3>;
-
- width-mm = <261>;
- height-mm = <163>;
-
- data-mapping = "jeida-24";
-
- panel-timing {
- /* 1280x800 @60Hz */
- clock-frequency = <7100>;
- hactive = <1280>;
- vactive = <800>;
- hsync-len = <70>;
- hfront-porch = <20>;
- hback-porch = <70>;
- vsync-len = <5>;
- vfront-porch = <3>;
- vback-porch = <15>;
- };
-
- port {
- panel_in: endpoint {
- remote-endpoint = <&lvds_encoder>;
- };
- };
-};
diff --git
a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml
b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml
new file mode 100644
index ..68750d8f0aef
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml
@@ -0,0 +1,69 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/mitsubishi,aa121td01.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mitsubishi AA121TD01 12.1" WXGA LVDS Display Panel
+
+maintainers:
+ - Laurent Pinchart
+ - Thierry Reding
+
+allOf:
+ - $ref: lvds.yaml#
+
+properties:
+ compatible:
+items:
+ - const: mitsubishi,aa121td01
+ - {} # panel-lvds, but not listed here to avoid false select
+
+ vcc-supply:
+description: Reference to the regulator powering the panel VCC pins.
+
+ data-mapping:
+const: jeida-24
+
+ width-mm:
+const: 261
+
+ height-mm:
+const: 163
+
+required:
+ - compatible
+ - vcc-supply
+
+examples:
+ - |+
+panel {
+ compatible = "mitsubishi,aa121td01", "panel-lvds";
+ vcc-supply = <&vcc_3v3>;
+
+ width-mm = <261>;
+ height-mm = <163>;
+
+ data-mapping = "jeida-24";
+
+ panel-timing {
+/* 1280x800 @60Hz */
+clock-frequency = <7100>;
+hactive = <1280>;
+vactive = <800>;
+hsync-len = <70>;
+hfront-porch = <20>;
+hback-porch = <70>;
+vsync-len = <5>;
+vfront-porch = <3>;
+vback-porch = <15>;
+ };
+
+ port {
+panel_in: endpoint {
+ remote-endpoint = <&lvds_encoder>;
+};
+ };
+};
+
+...
--
2.20.1
[PATCH v2 12/15] dt-bindings: display: Convert innolux,ee101ia-01 panel to DT schema
Convert the innolux,ee101ia-01 LVDS panel binding to DT schema.
Cc: Thierry Reding
Cc: Sam Ravnborg
Cc: Laurent Pinchart
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Maxime Ripard
Acked-by: Thierry Reding
Signed-off-by: Rob Herring
---
.../display/panel/innolux,ee101ia-01d.txt | 7 --
.../display/panel/innolux,ee101ia-01d.yaml| 22 +++
2 files changed, 22 insertions(+), 7 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.txt
create mode 100644
Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.txt
b/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.txt
deleted file mode 100644
index e5ca4ccd55ed..
--- a/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.txt
+++ /dev/null
@@ -1,7 +0,0 @@
-Innolux Corporation 10.1" EE101IA-01D WXGA (1280x800) LVDS panel
-
-Required properties:
-- compatible: should be "innolux,ee101ia-01d"
-
-This binding is compatible with the lvds-panel binding, which is specified
-in panel-lvds.txt in this directory.
diff --git
a/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml
b/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml
new file mode 100644
index ..5cc97cbe17fa
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml
@@ -0,0 +1,22 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/innolux,ee101ia-01d.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Innolux Corporation 10.1" EE101IA-01D WXGA (1280x800) LVDS panel
+
+maintainers:
+ - Heiko Stuebner
+ - Thierry Reding
+
+allOf:
+ - $ref: lvds.yaml#
+
+properties:
+ compatible:
+items:
+ - const: innolux,ee101ia-01d
+ - {} # panel-lvds, but not listed here to avoid false select
+
+...
--
2.20.1
[PATCH v2 01/15] dt-bindings: display: rockchip-lvds: Remove panel references
The panel bindings are outside the scope of the Rockchip LVDS interface
binding. The references are about to change too, so rather than update
them just drop the section on the panel bindings.
Cc: Sandy Huang
Cc: "Heiko Stübner"
Cc: Maxime Ripard
Cc: dri-devel@lists.freedesktop.org
Cc: linux-rockc...@lists.infradead.org
Signed-off-by: Rob Herring
---
.../bindings/display/rockchip/rockchip-lvds.txt | 11 ---
1 file changed, 11 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt
b/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt
index da6939efdb43..7849ff039229 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt
@@ -32,17 +32,6 @@ Their connections are modeled using the OF graph bindings
specified in
- video port 0 for the VOP input, the remote endpoint maybe vopb or vopl
- video port 1 for either a panel or subsequent encoder
-the lvds panel described by
- Documentation/devicetree/bindings/display/panel/simple-panel.txt
-
-Panel required properties:
-- ports for remote LVDS output
-
-Panel optional properties:
-- data-mapping: should be "vesa-24","jeida-24" or "jeida-18".
-This describes decribed by:
- Documentation/devicetree/bindings/display/panel/panel-lvds.txt
-
Example:
lvds_panel: lvds-panel {
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 04/15] dt-bindings: display: Convert armadeus, st0700-adapt panel to DT schema
Convert the armadeus,st0700-adapt panel binding to DT schema. Cc: Thierry Reding Cc: Sam Ravnborg Cc: Maxime Ripard Cc: Laurent Pinchart Cc: dri-devel@lists.freedesktop.org Signed-off-by: Rob Herring --- .../display/panel/armadeus,st0700-adapt.txt | 9 --- .../display/panel/armadeus,st0700-adapt.yaml | 27 +++ 2 files changed, 27 insertions(+), 9 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/panel/armadeus,st0700-adapt.txt create mode 100644 Documentation/devicetree/bindings/display/panel/armadeus,st0700-adapt.yaml diff --git a/Documentation/devicetree/bindings/display/panel/armadeus,st0700-adapt.txt b/Documentation/devicetree/bindings/display/panel/armadeus,st0700-adapt.txt deleted file mode 100644 index a30d63db3c8f.. --- a/Documentation/devicetree/bindings/display/panel/armadeus,st0700-adapt.txt +++ /dev/null @@ -1,9 +0,0 @@ -Armadeus ST0700 Adapt. A Santek ST0700I5Y-RBSLW 7.0" WVGA (800x480) TFT with -an adapter board. - -Required properties: -- compatible: "armadeus,st0700-adapt" -- power-supply: see panel-common.txt - -Optional properties: -- backlight: see panel-common.txt diff --git a/Documentation/devicetree/bindings/display/panel/armadeus,st0700-adapt.yaml b/Documentation/devicetree/bindings/display/panel/armadeus,st0700-adapt.yaml new file mode 100644 index ..59376669442a --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/armadeus,st0700-adapt.yaml @@ -0,0 +1,27 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/armadeus,st0700-adapt.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Armadeus ST0700 Adapter + +description: + A Santek ST0700I5Y-RBSLW 7.0" WVGA (800x480) TFT with an adapter board. + +maintainers: + - '"Sébastien Szymanski" ' + - Thierry Reding + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: +const: armadeus,st0700-adapt + +required: + - compatible + - power-supply + +... -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 02/15] dt-bindings: display: Convert common panel bindings to DT schema
Convert the common panel bindings to DT schema consolidating scattered definitions to a single schema file. The 'simple-panel' binding just a collection of properties and not a complete binding itself. All of the 'simple-panel' properties are covered by the panel-common.txt binding with the exception of the 'no-hpd' property, so add that to the schema. As there are lots of references to simple-panel.txt, just keep the file with a reference to common.yaml for now until all the bindings are converted. Cc: Thierry Reding Cc: Laurent Pinchart Cc: dri-devel@lists.freedesktop.org Acked-by: Sam Ravnborg Reviewed-by: Maxime Ripard Reviewed-by: Thierry Reding Signed-off-by: Rob Herring --- .../display/panel/arm,versatile-tft-panel.txt | 2 +- .../bindings/display/panel/panel-common.txt | 101 .../bindings/display/panel/panel-common.yaml | 149 ++ .../bindings/display/panel/panel.txt | 4 - .../bindings/display/panel/simple-panel.txt | 29 +--- 5 files changed, 151 insertions(+), 134 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/panel/panel-common.txt create mode 100644 Documentation/devicetree/bindings/display/panel/panel-common.yaml delete mode 100644 Documentation/devicetree/bindings/display/panel/panel.txt diff --git a/Documentation/devicetree/bindings/display/panel/arm,versatile-tft-panel.txt b/Documentation/devicetree/bindings/display/panel/arm,versatile-tft-panel.txt index 248141c3c7e3..0601a9e34703 100644 --- a/Documentation/devicetree/bindings/display/panel/arm,versatile-tft-panel.txt +++ b/Documentation/devicetree/bindings/display/panel/arm,versatile-tft-panel.txt @@ -10,7 +10,7 @@ Required properties: - compatible: should be "arm,versatile-tft-panel" Required subnodes: -- port: see display/panel/panel-common.txt, graph.txt +- port: see display/panel/panel-common.yaml, graph.txt Example: diff --git a/Documentation/devicetree/bindings/display/panel/panel-common.txt b/Documentation/devicetree/bindings/display/panel/panel-common.txt deleted file mode 100644 index 5d2519af4bb5.. --- a/Documentation/devicetree/bindings/display/panel/panel-common.txt +++ /dev/null @@ -1,101 +0,0 @@ -Common Properties for Display Panel -=== - -This document defines device tree properties common to several classes of -display panels. It doesn't constitue a device tree binding specification by -itself but is meant to be referenced by device tree bindings. - -When referenced from panel device tree bindings the properties defined in this -document are defined as follows. The panel device tree bindings are -responsible for defining whether each property is required or optional. - - -Descriptive Properties --- - -- width-mm, -- height-mm: The width-mm and height-mm specify the width and height of the - physical area where images are displayed. These properties are expressed in - millimeters and rounded to the closest unit. - -- label: The label property specifies a symbolic name for the panel as a - string suitable for use by humans. It typically contains a name inscribed on - the system (e.g. as an affixed label) or specified in the system's - documentation (e.g. in the user's manual). - - If no such name exists, and unless the property is mandatory according to - device tree bindings, it shall rather be omitted than constructed of - non-descriptive information. For instance an LCD panel in a system that - contains a single panel shall not be labelled "LCD" if that name is not - inscribed on the system or used in a descriptive fashion in system - documentation. - - -Display Timings - -- panel-timing: Most display panels are restricted to a single resolution and - require specific display timings. The panel-timing subnode expresses those - timings as specified in the timing subnode section of the display timing - bindings defined in - Documentation/devicetree/bindings/display/panel/display-timing.txt. - - -Connectivity - - -- ports: Panels receive video data through one or multiple connections. While - the nature of those connections is specific to the panel type, the - connectivity is expressed in a standard fashion using ports as specified in - the device graph bindings defined in - Documentation/devicetree/bindings/graph.txt. - -- ddc-i2c-bus: Some panels expose EDID information through an I2C-compatible - bus such as DDC2 or E-DDC. For such panels the ddc-i2c-bus contains a - phandle to the system I2C controller connected to that bus. - - -Control I/Os - - -Many display panels can be controlled through pins driven by GPIOs. The nature -and timing of those control signals are device-specific and left for panel -device tree bindings to specify. The following GPIO specifiers can however be -used for panels that implement compatible control signals. - -- enable-gpios: Specifier for a GPIO connected to the pa
[PATCH v2 03/15] dt-bindings: display: Convert ampire, am-480272h3tmqw-t01h panel to DT schema
Convert the ampire,am-480272h3tmqw-t01h panel binding to DT schema.
Cc: Yannick Fertre
Cc: Thierry Reding
Cc: Sam Ravnborg
Cc: Laurent Pinchart
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Maxime Ripard
Acked-by: Thierry Reding
Signed-off-by: Rob Herring
---
.../panel/ampire,am-480272h3tmqw-t01h.txt | 26
.../panel/ampire,am-480272h3tmqw-t01h.yaml| 42 +++
2 files changed, 42 insertions(+), 26 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt
create mode 100644
Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt
b/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt
deleted file mode 100644
index 6812280cb109..
---
a/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt
+++ /dev/null
@@ -1,26 +0,0 @@
-Ampire AM-480272H3TMQW-T01H 4.3" WQVGA TFT LCD panel
-
-This binding is compatible with the simple-panel binding, which is specified
-in simple-panel.txt in this directory.
-
-Required properties:
-- compatible: should be "ampire,am-480272h3tmqw-t01h"
-
-Optional properties:
-- power-supply: regulator to provide the supply voltage
-- enable-gpios: GPIO pin to enable or disable the panel
-- backlight: phandle of the backlight device attached to the panel
-
-Optional nodes:
-- Video port for RGB input.
-
-Example:
- panel_rgb: panel-rgb {
- compatible = "ampire,am-480272h3tmqw-t01h";
- enable-gpios = <&gpioa 8 1>;
- port {
- panel_in_rgb: endpoint {
- remote-endpoint = <&controller_out_rgb>;
- };
- };
- };
diff --git
a/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.yaml
b/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.yaml
new file mode 100644
index ..c6e33e7f36d0
--- /dev/null
+++
b/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id:
http://devicetree.org/schemas/display/panel/ampire,am-480272h3tmqw-t01h.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Ampire AM-480272H3TMQW-T01H 4.3" WQVGA TFT LCD panel
+
+maintainers:
+ - Yannick Fertre
+ - Thierry Reding
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+const: ampire,am-480272h3tmqw-t01h
+
+ power-supply: true
+ enable-gpios: true
+ backlight: true
+ port: true
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+panel_rgb: panel {
+ compatible = "ampire,am-480272h3tmqw-t01h";
+ enable-gpios = <&gpioa 8 1>;
+ port {
+panel_in_rgb: endpoint {
+ remote-endpoint = <&controller_out_rgb>;
+};
+ };
+};
+
+...
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 05/15] dt-bindings: display: Convert bananapi, s070wv20-ct16 panel to DT schema
Convert the bananapi,s070wv20-ct16 panel binding to DT schema. Cc: Thierry Reding Cc: Sam Ravnborg Cc: Maxime Ripard Cc: Laurent Pinchart Cc: dri-devel@lists.freedesktop.org Signed-off-by: Rob Herring --- .../display/panel/bananapi,s070wv20-ct16.txt | 12 -- .../display/panel/bananapi,s070wv20-ct16.yaml | 24 +++ 2 files changed, 24 insertions(+), 12 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt create mode 100644 Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.yaml diff --git a/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt deleted file mode 100644 index 35bc0c839f49.. --- a/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt +++ /dev/null @@ -1,12 +0,0 @@ -Banana Pi 7" (S070WV20-CT16) TFT LCD Panel - -Required properties: -- compatible: should be "bananapi,s070wv20-ct16" -- power-supply: see ./panel-common.txt - -Optional properties: -- enable-gpios: see ./simple-panel.txt -- backlight: see ./simple-panel.txt - -This binding is compatible with the simple-panel binding, which is specified -in ./simple-panel.txt. diff --git a/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.yaml b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.yaml new file mode 100644 index ..2c1d3bf2baa0 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.yaml @@ -0,0 +1,24 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/bananapi,s070wv20-ct16.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Banana Pi 7" (S070WV20-CT16) TFT LCD Panel + +maintainers: + - Chen-Yu Tsai + - Thierry Reding + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: +const: bananapi,s070wv20-ct16 + +required: + - compatible + - power-supply + +... -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 00/15] Conversion of panel bindings to DT schema
This series converts the common panel bindings to DT schema format. Besides the conversion of common panel properties, a few panel bindings are converted here as well. These are all the ones with references to panel-common.txt or panel-lvds.txt. Rob Rob Herring (15): dt-bindings: display: rockchip-lvds: Remove panel references dt-bindings: display: Convert common panel bindings to DT schema dt-bindings: display: Convert ampire,am-480272h3tmqw-t01h panel to DT schema dt-bindings: display: Convert armadeus,st0700-adapt panel to DT schema dt-bindings: display: Convert bananapi,s070wv20-ct16 panel to DT schema dt-bindings: display: Convert dlc,dlc0700yzg-1 panel to DT schema dt-bindings: display: Convert pda,91-00156-a0 panel to DT schema dt-bindings: display: Convert raspberrypi,7inch-touchscreen panel to DT schema dt-bindings: display: Convert tfc,s9700rtwv43tr-01b panel to DT schema dt-bindings: display: Convert tpo,tpg110 panel to DT schema dt-bindings: display: Convert panel-lvds to DT schema dt-bindings: display: Convert innolux,ee101ia-01 panel to DT schema dt-bindings: display: Convert mitsubishi,aa104xd12 panel to DT schema dt-bindings: display: Convert mitsubishi,aa121td01 panel to DT schema dt-bindings: display: Convert sgd,gktw70sdae4se panel to DT schema .../panel/ampire,am-480272h3tmqw-t01h.txt | 26 --- .../panel/ampire,am-480272h3tmqw-t01h.yaml| 42 + .../display/panel/arm,versatile-tft-panel.txt | 2 +- .../display/panel/armadeus,st0700-adapt.txt | 9 -- .../display/panel/armadeus,st0700-adapt.yaml | 27 .../display/panel/bananapi,s070wv20-ct16.txt | 12 -- .../display/panel/bananapi,s070wv20-ct16.yaml | 24 +++ .../display/panel/dlc,dlc0700yzg-1.txt| 13 -- .../display/panel/dlc,dlc0700yzg-1.yaml | 28 .../display/panel/innolux,ee101ia-01d.txt | 7 - .../display/panel/innolux,ee101ia-01d.yaml| 22 +++ .../bindings/display/panel/lvds.yaml | 107 + .../display/panel/mitsubishi,aa104xd12.txt| 47 -- .../display/panel/mitsubishi,aa104xd12.yaml | 71 + .../display/panel/mitsubishi,aa121td01.txt| 47 -- .../display/panel/mitsubishi,aa121td01.yaml | 69 .../bindings/display/panel/panel-common.txt | 101 .../bindings/display/panel/panel-common.yaml | 149 ++ .../bindings/display/panel/panel-lvds.txt | 121 -- .../bindings/display/panel/panel.txt | 4 - .../display/panel/pda,91-00156-a0.txt | 14 -- .../display/panel/pda,91-00156-a0.yaml| 25 +++ .../panel/raspberrypi,7inch-touchscreen.txt | 49 -- .../panel/raspberrypi,7inch-touchscreen.yaml | 71 + .../display/panel/sgd,gktw70sdae4se.txt | 41 - .../display/panel/sgd,gktw70sdae4se.yaml | 63 .../bindings/display/panel/simple-panel.txt | 29 +--- .../display/panel/tfc,s9700rtwv43tr-01b.txt | 15 -- .../display/panel/tfc,s9700rtwv43tr-01b.yaml | 30 .../bindings/display/panel/tpo,tpg110.txt | 70 .../bindings/display/panel/tpo,tpg110.yaml| 101 .../display/rockchip/rockchip-lvds.txt| 11 -- 32 files changed, 831 insertions(+), 616 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt create mode 100644 Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.yaml delete mode 100644 Documentation/devicetree/bindings/display/panel/armadeus,st0700-adapt.txt create mode 100644 Documentation/devicetree/bindings/display/panel/armadeus,st0700-adapt.yaml delete mode 100644 Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt create mode 100644 Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.yaml delete mode 100644 Documentation/devicetree/bindings/display/panel/dlc,dlc0700yzg-1.txt create mode 100644 Documentation/devicetree/bindings/display/panel/dlc,dlc0700yzg-1.yaml delete mode 100644 Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.txt create mode 100644 Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml create mode 100644 Documentation/devicetree/bindings/display/panel/lvds.yaml delete mode 100644 Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.txt create mode 100644 Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml delete mode 100644 Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.txt create mode 100644 Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml delete mode 100644 Documentation/devicetree/bindings/display/panel/panel-common.txt create mode 100644 Documentation/devicetree/bindings/display/panel/panel-common.yaml delete mode 100644 Documentation/devicetree/bindings/display/panel/panel-lvds.txt delete mode 100644 Documentation
[PATCH v2 06/15] dt-bindings: display: Convert dlc,dlc0700yzg-1 panel to DT schema
Convert the dlc,dlc0700yzg-1 panel binding to DT schema. Cc: Philipp Zabel Cc: Thierry Reding Cc: Sam Ravnborg Cc: Maxime Ripard Cc: Laurent Pinchart Cc: dri-devel@lists.freedesktop.org Signed-off-by: Rob Herring --- .../display/panel/dlc,dlc0700yzg-1.txt| 13 - .../display/panel/dlc,dlc0700yzg-1.yaml | 28 +++ 2 files changed, 28 insertions(+), 13 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/panel/dlc,dlc0700yzg-1.txt create mode 100644 Documentation/devicetree/bindings/display/panel/dlc,dlc0700yzg-1.yaml diff --git a/Documentation/devicetree/bindings/display/panel/dlc,dlc0700yzg-1.txt b/Documentation/devicetree/bindings/display/panel/dlc,dlc0700yzg-1.txt deleted file mode 100644 index bf06bb025b08.. --- a/Documentation/devicetree/bindings/display/panel/dlc,dlc0700yzg-1.txt +++ /dev/null @@ -1,13 +0,0 @@ -DLC Display Co. DLC0700YZG-1 7.0" WSVGA TFT LCD panel - -Required properties: -- compatible: should be "dlc,dlc0700yzg-1" -- power-supply: See simple-panel.txt - -Optional properties: -- reset-gpios: See panel-common.txt -- enable-gpios: See simple-panel.txt -- backlight: See simple-panel.txt - -This binding is compatible with the simple-panel binding, which is specified -in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/display/panel/dlc,dlc0700yzg-1.yaml b/Documentation/devicetree/bindings/display/panel/dlc,dlc0700yzg-1.yaml new file mode 100644 index ..1b0b63d46f3e --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/dlc,dlc0700yzg-1.yaml @@ -0,0 +1,28 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/dlc,dlc0700yzg-1.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: DLC Display Co. DLC0700YZG-1 7.0" WSVGA TFT LCD panel + +maintainers: + - Philipp Zabel + - Thierry Reding + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: +const: dlc,dlc0700yzg-1 + + reset-gpios: true + enable-gpios: true + backlight: true + +required: + - compatible + - power-supply + +... -- 2.20.1
Re: [PATCH v2] libdrm: modetest: Allow selecting modes by index
On Mon, Jun 24, 2019 at 1:32 PM Ilia Mirkin wrote:
>
> Reviewed-by: Ilia Mirkin
>
> One minor comment below though:
>
> (Maybe let it sit on the list for a day in case anyone feels like
> objecting strenuously.)
Thanks so much for the review!
> > @@ -829,6 +830,16 @@ connector_find_mode(struct device *dev, uint32_t
> > con_id, const char *mode_str,
> > if (!connector || !connector->count_modes)
> > return NULL;
> >
> > + /* Pick by Index */
> > + if (mode_str[0] == '#') {
> > + int index = atoi(mode_str + 1);
> > +
> > + if (index >= connector->count_modes)
>
> || index < 0
Ok, added this bit in my tree. I'll resubmit in a few days to let
others have a chance to review as well.
thanks
-john
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 1/2] drm/vmwgfx: drop use of drmP.h in header files
Hi Sam,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.2-rc6 next-20190621]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Sam-Ravnborg/drm-vmwgfx-drop-use-of-drmP-h-in-header-files/20190622-234524
config: x86_64-randconfig-u0-06250015 (attached as .config)
compiler: gcc-5 (Debian 5.5.0-3) 5.4.1 20171010
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
drivers/gpu/drm/vmwgfx/vmwgfx_mob.c: In function 'vmw_mob_build_pt':
>> drivers/gpu/drm/vmwgfx/vmwgfx_mob.c:517:22: error: implicit declaration of
>> function 'kmap_atomic' [-Werror=implicit-function-declaration]
save_addr = addr = kmap_atomic(page);
^
drivers/gpu/drm/vmwgfx/vmwgfx_mob.c:517:20: warning: assignment makes
pointer from integer without a cast [-Wint-conversion]
save_addr = addr = kmap_atomic(page);
^
>> drivers/gpu/drm/vmwgfx/vmwgfx_mob.c:526:3: error: implicit declaration of
>> function 'kunmap_atomic' [-Werror=implicit-function-declaration]
kunmap_atomic(save_addr);
^
cc1: some warnings being treated as errors
vim +/kmap_atomic +517 drivers/gpu/drm/vmwgfx/vmwgfx_mob.c
3530bdc3 Thomas Hellstrom 2012-11-21 491
3530bdc3 Thomas Hellstrom 2012-11-21 492 /*
3530bdc3 Thomas Hellstrom 2012-11-21 493 * vmw_mob_build_pt - Build a
pagetable
3530bdc3 Thomas Hellstrom 2012-11-21 494 *
0fd53cfb Thomas Hellstrom 2013-10-24 495 * @data_addr: Array of DMA
addresses to the underlying buffer
3530bdc3 Thomas Hellstrom 2012-11-21 496 * object's data
pages.
3530bdc3 Thomas Hellstrom 2012-11-21 497 * @num_data_pages: Number of buffer
object data pages.
3530bdc3 Thomas Hellstrom 2012-11-21 498 * @pt_pages: Array of page
pointers to the page table pages.
3530bdc3 Thomas Hellstrom 2012-11-21 499 *
3530bdc3 Thomas Hellstrom 2012-11-21 500 * Returns the number of page table
pages actually used.
3530bdc3 Thomas Hellstrom 2012-11-21 501 * Uses atomic kmaps of highmem
pages to avoid TLB thrashing.
3530bdc3 Thomas Hellstrom 2012-11-21 502 */
0fd53cfb Thomas Hellstrom 2013-10-24 503 static unsigned long
vmw_mob_build_pt(struct vmw_piter *data_iter,
3530bdc3 Thomas Hellstrom 2012-11-21 504
unsigned long num_data_pages,
0fd53cfb Thomas Hellstrom 2013-10-24 505
struct vmw_piter *pt_iter)
3530bdc3 Thomas Hellstrom 2012-11-21 506 {
3530bdc3 Thomas Hellstrom 2012-11-21 507 unsigned long pt_size =
num_data_pages * VMW_PPN_SIZE;
3530bdc3 Thomas Hellstrom 2012-11-21 508 unsigned long num_pt_pages =
DIV_ROUND_UP(pt_size, PAGE_SIZE);
0fd53cfb Thomas Hellstrom 2013-10-24 509 unsigned long pt_page;
b9eb1a61 Thomas Hellstrom 2015-04-02 510 u32 *addr, *save_addr;
3530bdc3 Thomas Hellstrom 2012-11-21 511 unsigned long i;
0fd53cfb Thomas Hellstrom 2013-10-24 512 struct page *page;
3530bdc3 Thomas Hellstrom 2012-11-21 513
3530bdc3 Thomas Hellstrom 2012-11-21 514 for (pt_page = 0; pt_page <
num_pt_pages; ++pt_page) {
0fd53cfb Thomas Hellstrom 2013-10-24 515 page =
vmw_piter_page(pt_iter);
0fd53cfb Thomas Hellstrom 2013-10-24 516
0fd53cfb Thomas Hellstrom 2013-10-24 @517 save_addr = addr =
kmap_atomic(page);
3530bdc3 Thomas Hellstrom 2012-11-21 518
3530bdc3 Thomas Hellstrom 2012-11-21 519 for (i = 0; i <
PAGE_SIZE / VMW_PPN_SIZE; ++i) {
f2a0dcb1 Thomas Hellstrom 2014-01-15 520
vmw_mob_assign_ppn(&addr,
f2a0dcb1 Thomas Hellstrom 2014-01-15 521
vmw_piter_dma_addr(data_iter));
0fd53cfb Thomas Hellstrom 2013-10-24 522 if
(unlikely(--num_data_pages == 0))
3530bdc3 Thomas Hellstrom 2012-11-21 523 break;
0fd53cfb Thomas Hellstrom 2013-10-24 524
WARN_ON(!vmw_piter_next(data_iter));
3530bdc3 Thomas Hellstrom 2012-11-21 525 }
3530bdc3 Thomas Hellstrom 2012-11-21 @526
kunmap_atomic(save_addr);
0fd53cfb Thomas Hellstrom 2013-10-24 527 vmw_piter_next(pt_iter);
3530bdc3 Thomas Hellstrom 2012-11-21 528 }
3530bdc3 Thomas Hellstrom 2012-11-21 529
3530bdc3 Thomas Hellstrom 2012-11-21 530 return num_pt_pages;
3530bdc3 Thomas Hellstrom 2012-11-21 531 }
3530bdc3 Thomas Hellstrom 2012-11-21 532
:: The code at line 517 was first introduced by commit
:: 0fd53cfb09108c33b924b069fe2c62fa4e7b11a0 drm/vmwgfx: Use the linux DMA
api also for MOBs
:: TO: Thomas Hellstrom
:: CC: Thomas Hellstrom
---
0-DAY kernel test inf
Re: [PATCH v1 0/2] drm: drop uapi dependencies from include/drm
Hi Daniel. > > drm_file.h: > > - needs drm_magic_t > > drm_magic_t is a simple typedef, a simple unsigned int would do the trick > > I think we could switch over to unsigned int for this. OK, will send a v2 with this addressed. There is some preparatory patches to fix build breakage when the include file is dropped. > > > drm_legacy.h > > - needs drm_map_type and drm_map_flags. Seems legit. > > enum in uapi, sweet (never do this, it's not portable across compilers, > #defines all the way). But yeah seems legit, plus we don't care about > drm_legacy.h And this part I will happily ignore. Maybe one day I will check what other dependencies there are. On a rainy day or when there are no more users of drmP.h or so. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/4] drm/panel: Add helper for reading DT rotation
Hi Derek.
On Fri, Jun 21, 2019 at 08:41:02PM -0700, Derek Basehore wrote:
> This adds a helper function for reading the rotation (panel
> orientation) from the device tree.
>
> Signed-off-by: Derek Basehore
> ---
> drivers/gpu/drm/drm_panel.c | 42 +
> include/drm/drm_panel.h | 7 +++
> 2 files changed, 49 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
> index dbd5b873e8f2..507099af4b57 100644
> --- a/drivers/gpu/drm/drm_panel.c
> +++ b/drivers/gpu/drm/drm_panel.c
> @@ -172,6 +172,48 @@ struct drm_panel *of_drm_find_panel(const struct
> device_node *np)
> return ERR_PTR(-EPROBE_DEFER);
> }
> EXPORT_SYMBOL(of_drm_find_panel);
> +
> +/**
> + * of_drm_get_panel_orientation - look up the rotation of the panel using a
> + * device tree node
> + * @np: device tree node of the panel
> + * @orientation: orientation enum to be filled in
> + *
> + * Looks up the rotation of a panel in the device tree. The rotation in the
> + * device tree is counter clockwise.
> + *
> + * Return: 0 when a valid rotation value (0, 90, 180, or 270) is read or the
> + * rotation property doesn't exist. -EERROR otherwise.
> + */
This function should better spell out why it talks about rotation versus
orientation.
It happens that orientation, due to bad design choices is named rotation
in DT.
But then this function is all about orientation, that just happens to be
named rotation in DT.
And the comments associated to the function should reflect this.
something like:
/**
* of_drm_get_panel_orientation - look up the orientation of the panel using a
* device tree node
* @np: device tree node of the panel
* @orientation: orientation enum to be filled in
*
* Looks up the rotation property of a panel in the device tree.
* The orientation of the panel is expressed as a property named
* "rotation" in the device tree.
* The rotation in the device tree is counter clockwise.
*
* Return: 0 when a valid orientation value (0, 90, 180, or 270) is read or the
* rotation property doesn't exist. -EERROR otherwise.
*/
This would at least remove some of my confusiuon.
And then maybe add a bit more explanation to the binding property
description too.
Sam
> +int of_drm_get_panel_orientation(const struct device_node *np,
> + enum drm_panel_orientation *orientation)
> +{
> + int rotation, ret;
> +
> + ret = of_property_read_u32(np, "rotation", &rotation);
> + if (ret == -EINVAL) {
> + /* Don't return an error if there's no rotation property. */
> + *orientation = DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
> + return 0;
> + }
> +
> + if (ret < 0)
> + return ret;
> +
> + if (rotation == 0)
> + *orientation = DRM_MODE_PANEL_ORIENTATION_NORMAL;
> + else if (rotation == 90)
> + *orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP;
> + else if (rotation == 180)
> + *orientation = DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP;
> + else if (rotation == 270)
> + *orientation = DRM_MODE_PANEL_ORIENTATION_LEFT_UP;
> + else
> + return -EINVAL;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(of_drm_get_panel_orientation);
> #endif
>
> MODULE_AUTHOR("Thierry Reding ");
> diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
> index 8c738c0e6e9f..3564952f1a4f 100644
> --- a/include/drm/drm_panel.h
> +++ b/include/drm/drm_panel.h
> @@ -197,11 +197,18 @@ int drm_panel_detach(struct drm_panel *panel);
>
> #if defined(CONFIG_OF) && defined(CONFIG_DRM_PANEL)
> struct drm_panel *of_drm_find_panel(const struct device_node *np);
> +int of_drm_get_panel_orientation(const struct device_node *np,
> + enum drm_panel_orientation *orientation);
> #else
> static inline struct drm_panel *of_drm_find_panel(const struct device_node
> *np)
> {
> return ERR_PTR(-ENODEV);
> }
> +int of_drm_get_panel_orientation(const struct device_node *np,
> + enum drm_panel_orientation *orientation)
> +{
> + return -ENODEV;
> +}
> #endif
>
> #endif
> --
> 2.22.0.410.gd8fdbe21b5-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] libdrm: modetest: Allow selecting modes by index
Reviewed-by: Ilia Mirkin
One minor comment below though:
(Maybe let it sit on the list for a day in case anyone feels like
objecting strenuously.)
On Mon, Jun 24, 2019 at 4:27 PM John Stultz wrote:
>
> Often there are many similar modes, which cannot be selected
> via modetest due to its simple string matching.
>
> This change adds a mode index in the display output, which can
> then be used to specify a specific modeline to be set.
>
> Cc: Ilia Mirkin
> Cc: Rob Clark
> Cc: Bjorn Andersson
> Cc: Sumit Semwal
> Signed-off-by: John Stultz
> ---
> v2: Reworked mode_str check per Ilia's suggestion
> ---
> tests/modetest/modetest.c | 23 +--
> 1 file changed, 17 insertions(+), 6 deletions(-)
>
> diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
> index 9c85c07b..5a04190c 100644
> --- a/tests/modetest/modetest.c
> +++ b/tests/modetest/modetest.c
> @@ -204,9 +204,10 @@ static void dump_encoders(struct device *dev)
> printf("\n");
> }
>
> -static void dump_mode(drmModeModeInfo *mode)
> +static void dump_mode(drmModeModeInfo *mode, int index)
> {
> - printf(" %s %d %d %d %d %d %d %d %d %d %d",
> + printf(" #%i %s %d %d %d %d %d %d %d %d %d %d",
> + index,
>mode->name,
>mode->vrefresh,
>mode->hdisplay,
> @@ -443,10 +444,10 @@ static void dump_connectors(struct device *dev)
>
> if (connector->count_modes) {
> printf(" modes:\n");
> - printf("\tname refresh (Hz) hdisp hss hse htot vdisp "
> + printf("\tindex name refresh (Hz) hdisp hss hse htot
> vdisp "
>"vss vse vtot)\n");
> for (j = 0; j < connector->count_modes; j++)
> - dump_mode(&connector->modes[j]);
> + dump_mode(&connector->modes[j], j);
> }
>
> if (_connector->props) {
> @@ -478,7 +479,7 @@ static void dump_crtcs(struct device *dev)
>crtc->buffer_id,
>crtc->x, crtc->y,
>crtc->width, crtc->height);
> - dump_mode(&crtc->mode);
> + dump_mode(&crtc->mode, 0);
>
> if (_crtc->props) {
> printf(" props:\n");
> @@ -829,6 +830,16 @@ connector_find_mode(struct device *dev, uint32_t con_id,
> const char *mode_str,
> if (!connector || !connector->count_modes)
> return NULL;
>
> + /* Pick by Index */
> + if (mode_str[0] == '#') {
> + int index = atoi(mode_str + 1);
> +
> + if (index >= connector->count_modes)
|| index < 0
or maybe just make it unsigned. Either way.
> + return NULL;
> + return &connector->modes[index];
> + }
> +
> + /* Pick by Name */
> for (i = 0; i < connector->count_modes; i++) {
> mode = &connector->modes[i];
> if (!strcmp(mode->name, mode_str)) {
> @@ -1752,7 +1763,7 @@ static void usage(char *name)
>
> fprintf(stderr, "\n Test options:\n\n");
> fprintf(stderr, "\t-P
> @:x[++][*][@]\tset a plane\n");
> - fprintf(stderr, "\t-s
> [,][@]:[-][@]\tset
> a mode\n");
> + fprintf(stderr, "\t-s
> [,][@]:[# index>][-][@]\tset a mode\n");
> fprintf(stderr, "\t-C\ttest hw cursor\n");
> fprintf(stderr, "\t-v\ttest vsynced page flipping\n");
> fprintf(stderr, "\t-w ::\tset property\n");
> --
> 2.17.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/4] backlight: pwm_bl: Set scale type for CIE 1931 curves
For backlight curves calculated with the CIE 1931 algorithm set
the brightness scale type property accordingly. This makes the
scale type available to userspace via the 'scale' sysfs attribute.
Signed-off-by: Matthias Kaehlcke
Tested-by: Enric Balletbo i Serra
Acked-by: Daniel Thompson
---
Changes in v2:
- added Enric's 'Tested-by' tag
- added Daniel's 'Acked-by' tag
---
drivers/video/backlight/pwm_bl.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index fb45f866b923..f067fe7aa35d 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -553,6 +553,8 @@ static int pwm_backlight_probe(struct platform_device *pdev)
goto err_alloc;
}
+ memset(&props, 0, sizeof(struct backlight_properties));
+
if (data->levels) {
/*
* For the DT case, only when brightness levels is defined
@@ -591,6 +593,8 @@ static int pwm_backlight_probe(struct platform_device *pdev)
pb->levels = data->levels;
}
+
+ props.scale = BACKLIGHT_SCALE_CIE1931;
} else {
/*
* That only happens for the non-DT case, where platform data
@@ -601,7 +605,6 @@ static int pwm_backlight_probe(struct platform_device *pdev)
pb->lth_brightness = data->lth_brightness * (state.period / pb->scale);
- memset(&props, 0, sizeof(struct backlight_properties));
props.type = BACKLIGHT_RAW;
props.max_brightness = data->max_brightness;
bl = backlight_device_register(dev_name(&pdev->dev), &pdev->dev, pb,
--
2.22.0.410.gd8fdbe21b5-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/4] MAINTAINERS: Add entry for stable backlight sysfs ABI documentation
Add an entry for the stable backlight sysfs ABI to the MAINTAINERS file. Signed-off-by: Matthias Kaehlcke Acked-by: Daniel Thompson --- Changes in v2: - added Daniel's 'Acked-by' tag --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 57f496cff999..d51e74340870 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2857,6 +2857,7 @@ F:drivers/video/backlight/ F: include/linux/backlight.h F: include/linux/pwm_backlight.h F: Documentation/devicetree/bindings/leds/backlight +F: Documentation/ABI/stable/sysfs-class-backlight BATMAN ADVANCED M: Marek Lindner -- 2.22.0.410.gd8fdbe21b5-goog
[PATCH v2 4/4] backlight: pwm_bl: Set scale type for brightness curves specified in the DT
Check if a brightness curve specified in the device tree is linear or
not and set the corresponding property accordingly. This makes the
scale type available to userspace via the 'scale' sysfs attribute.
To determine if a curve is linear it is compared to a interpolated linear
curve between min and max brightness. The curve is considered linear if
no value deviates more than +/-5% of ${brightness_range} from their
interpolated value.
Signed-off-by: Matthias Kaehlcke
Acked-by: Daniel Thompson
---
Changes in v2:
- use 128 (power of two) instead of 100 as factor for the slope
- add comment about max quantization error
- added Daniel's 'Acked-by' tag
---
drivers/video/backlight/pwm_bl.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index f067fe7aa35d..2297fb4af49d 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -404,6 +404,31 @@ int pwm_backlight_brightness_default(struct device *dev,
}
#endif
+static bool pwm_backlight_is_linear(struct platform_pwm_backlight_data *data)
+{
+ unsigned int nlevels = data->max_brightness + 1;
+ unsigned int min_val = data->levels[0];
+ unsigned int max_val = data->levels[nlevels - 1];
+ /*
+* Multiplying by 128 means that even in pathological cases such
+* as (max_val - min_val) == nlevels the error at max_val is less
+* than 1%.
+*/
+ unsigned int slope = (128 * (max_val - min_val)) / nlevels;
+ unsigned int margin = (max_val - min_val) / 20; /* 5% */
+ int i;
+
+ for (i = 1; i < nlevels; i++) {
+ unsigned int linear_value = min_val + ((i * slope) / 128);
+ unsigned int delta = abs(linear_value - data->levels[i]);
+
+ if (delta > margin)
+ return false;
+ }
+
+ return true;
+}
+
static int pwm_backlight_initial_power_state(const struct pwm_bl_data *pb)
{
struct device_node *node = pb->dev->of_node;
@@ -567,6 +592,11 @@ static int pwm_backlight_probe(struct platform_device
*pdev)
pb->levels = data->levels;
}
+
+ if (pwm_backlight_is_linear(data))
+ props.scale = BACKLIGHT_SCALE_LINEAR;
+ else
+ props.scale = BACKLIGHT_SCALE_NON_LINEAR;
} else if (!data->max_brightness) {
/*
* If no brightness levels are provided and max_brightness is
--
2.22.0.410.gd8fdbe21b5-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/4] backlight: Expose brightness curve type through sysfs
Backlight brightness curves can have different shapes. The two main types are linear and non-linear curves. The human eye doesn't perceive linearly increasing/decreasing brightness as linear (see also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED linearly to human eye"), hence many backlights use non-linear (often logarithmic) brightness curves. The type of curve is currently opaque to userspace, so userspace often relies on more or less reliable heuristics (like the number of brightness levels) to decide whether to treat a backlight device as linear or non-linear. Export the type of the brightness curve via a new sysfs attribute. Matthias Kaehlcke (4): MAINTAINERS: Add entry for stable backlight sysfs ABI documentation backlight: Expose brightness curve type through sysfs backlight: pwm_bl: Set scale type for CIE 1931 curves backlight: pwm_bl: Set scale type for brightness curves specified in the DT .../ABI/testing/sysfs-class-backlight | 32 + MAINTAINERS | 2 ++ drivers/video/backlight/backlight.c | 21 +++ drivers/video/backlight/pwm_bl.c | 35 ++- include/linux/backlight.h | 10 ++ 5 files changed, 99 insertions(+), 1 deletion(-) create mode 100644 Documentation/ABI/testing/sysfs-class-backlight -- 2.22.0.410.gd8fdbe21b5-goog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/4] backlight: Expose brightness curve type through sysfs
Backlight brightness curves can have different shapes. The two main
types are linear and non-linear curves. The human eye doesn't
perceive linearly increasing/decreasing brightness as linear (see
also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED
linearly to human eye"), hence many backlights use non-linear (often
logarithmic) brightness curves. The type of curve currently is opaque
to userspace, so userspace often uses more or less reliable heuristics
(like the number of brightness levels) to decide whether to treat a
backlight device as linear or non-linear.
Export the type of the brightness curve via the new sysfs attribute
'scale'. The value of the attribute may be a simple string like
'linear' or 'non-linear', or a composite string similar to
'compatible' strings of the device tree. A composite string consists
of different elements separated by commas, starting with the
most-detailed description and ending with the least-detailed one. An
example for a composite string is "cie-1931,perceptual,non-linear"
This brightness curve was generated with the CIE 1931 algorithm, it
is perceptually linear, but not actually linear in terms of the
emitted light. If userspace doesn't know about 'cie-1931' or
'perceptual' it should at least be able to interpret the 'non-linear'
part.
For devices that don't provide information about the scale of their
brightness curve the value of the 'scale' attribute is 'unknown'.
Signed-off-by: Matthias Kaehlcke
---
Changes in v2:
- changed order of brightness scale enums, explicitly make 'unknown' zero
- minor update of commit message
- deleted excess blank line after 'backlight_scale_types'
- s/curves/curve/ in sysfs doc
---
.../ABI/testing/sysfs-class-backlight | 32 +++
MAINTAINERS | 1 +
drivers/video/backlight/backlight.c | 21
include/linux/backlight.h | 10 ++
4 files changed, 64 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-class-backlight
diff --git a/Documentation/ABI/testing/sysfs-class-backlight
b/Documentation/ABI/testing/sysfs-class-backlight
new file mode 100644
index ..da1ce9e5c55a
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-backlight
@@ -0,0 +1,32 @@
+What: /sys/class/backlight//scale
+Date: June 2019
+KernelVersion: 5.4
+Contact: Daniel Thompson
+Description:
+ Description of the scale of the brightness curve. The
+ description consists of one or more elements separated by
+ commas, from the most detailed to the least detailed
+ description.
+
+ Possible values are:
+
+ unknown
+ The scale of the brightness curve is unknown.
+
+ linear
+ The brightness changes linearly in terms of the emitted
+ light, changes are perceived as non-linear by the human eye.
+
+ non-linear
+ The brightness changes non-linearly in terms of the emitted
+ light, changes might be perceived as linear by the human eye.
+
+ perceptual,non-linear
+ The brightness changes non-linearly in terms of the emitted
+ light, changes should be perceived as linear by the human eye.
+
+ cie-1931,perceptual,non-linear
+ The brightness curve was calculated with the CIE 1931
+ algorithm. Brightness changes non-linearly in terms of the
+ emitted light, changes should be perceived as linear by the
+ human eye.
diff --git a/MAINTAINERS b/MAINTAINERS
index d51e74340870..c46812510ba5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2858,6 +2858,7 @@ F:include/linux/backlight.h
F: include/linux/pwm_backlight.h
F: Documentation/devicetree/bindings/leds/backlight
F: Documentation/ABI/stable/sysfs-class-backlight
+F: Documentation/ABI/testing/sysfs-class-backlight
BATMAN ADVANCED
M: Marek Lindner
diff --git a/drivers/video/backlight/backlight.c
b/drivers/video/backlight/backlight.c
index 1ef8b6fd62ac..86612ec42ed0 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -32,6 +32,14 @@ static const char *const backlight_types[] = {
[BACKLIGHT_FIRMWARE] = "firmware",
};
+static const char *const backlight_scale_types[] = {
+ [BACKLIGHT_SCALE_UNKNOWN] = "unknown",
+ [BACKLIGHT_SCALE_LINEAR]= "linear",
+ [BACKLIGHT_SCALE_NON_LINEAR]= "non-linear",
+ [BACKLIGHT_SCALE_PERCEPTUAL]= "perceptual,non-linear",
+ [BACKLIGHT_SCALE_CIE1931] = "cie-1931,perceptual,non-linear",
+};
+
#if defined(CONFIG_FB) || (defined(CONFIG_FB_MODULE) && \
defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE))
/* This callback gets called when something important happens inside a
@@ -
Re: [PATCH v7 0/6] Add support for Orange Pi 3
On Mon, Jun 24, 2019 at 01:24:56PM -0700, David Miller wrote: > From: Ondřej Jirman > Date: Mon, 24 Jun 2019 19:46:37 +0200 > > > This series was even longer before, with patches all around for various > > maintainers. I'd expect that relevant maintainers pick the range of patches > > meant for them. I don't know who's exactly responsible for what, but I > > think, > > this should work: > > > > - 2 stmmac patches should go together via some networking tree (is there > > something specific for stmmac?) > > - all DTS patches should go via sunxi > > - hdmi patches via some drm tree > > Thank you. So I'll merge the first two patches that touch the stmmac > driver via my net-next tree. Thank you. regards, Ondrej
[PATCH v2] libdrm: modetest: Allow selecting modes by index
Often there are many similar modes, which cannot be selected
via modetest due to its simple string matching.
This change adds a mode index in the display output, which can
then be used to specify a specific modeline to be set.
Cc: Ilia Mirkin
Cc: Rob Clark
Cc: Bjorn Andersson
Cc: Sumit Semwal
Signed-off-by: John Stultz
---
v2: Reworked mode_str check per Ilia's suggestion
---
tests/modetest/modetest.c | 23 +--
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 9c85c07b..5a04190c 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -204,9 +204,10 @@ static void dump_encoders(struct device *dev)
printf("\n");
}
-static void dump_mode(drmModeModeInfo *mode)
+static void dump_mode(drmModeModeInfo *mode, int index)
{
- printf(" %s %d %d %d %d %d %d %d %d %d %d",
+ printf(" #%i %s %d %d %d %d %d %d %d %d %d %d",
+ index,
mode->name,
mode->vrefresh,
mode->hdisplay,
@@ -443,10 +444,10 @@ static void dump_connectors(struct device *dev)
if (connector->count_modes) {
printf(" modes:\n");
- printf("\tname refresh (Hz) hdisp hss hse htot vdisp "
+ printf("\tindex name refresh (Hz) hdisp hss hse htot
vdisp "
"vss vse vtot)\n");
for (j = 0; j < connector->count_modes; j++)
- dump_mode(&connector->modes[j]);
+ dump_mode(&connector->modes[j], j);
}
if (_connector->props) {
@@ -478,7 +479,7 @@ static void dump_crtcs(struct device *dev)
crtc->buffer_id,
crtc->x, crtc->y,
crtc->width, crtc->height);
- dump_mode(&crtc->mode);
+ dump_mode(&crtc->mode, 0);
if (_crtc->props) {
printf(" props:\n");
@@ -829,6 +830,16 @@ connector_find_mode(struct device *dev, uint32_t con_id,
const char *mode_str,
if (!connector || !connector->count_modes)
return NULL;
+ /* Pick by Index */
+ if (mode_str[0] == '#') {
+ int index = atoi(mode_str + 1);
+
+ if (index >= connector->count_modes)
+ return NULL;
+ return &connector->modes[index];
+ }
+
+ /* Pick by Name */
for (i = 0; i < connector->count_modes; i++) {
mode = &connector->modes[i];
if (!strcmp(mode->name, mode_str)) {
@@ -1752,7 +1763,7 @@ static void usage(char *name)
fprintf(stderr, "\n Test options:\n\n");
fprintf(stderr, "\t-P
@:x[++][*][@]\tset a plane\n");
- fprintf(stderr, "\t-s
[,][@]:[-][@]\tset
a mode\n");
+ fprintf(stderr, "\t-s
[,][@]:[#][-][@]\tset a mode\n");
fprintf(stderr, "\t-C\ttest hw cursor\n");
fprintf(stderr, "\t-v\ttest vsynced page flipping\n");
fprintf(stderr, "\t-w ::\tset property\n");
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 0/6] Add support for Orange Pi 3
From: Ondřej Jirman Date: Mon, 24 Jun 2019 19:46:37 +0200 > This series was even longer before, with patches all around for various > maintainers. I'd expect that relevant maintainers pick the range of patches > meant for them. I don't know who's exactly responsible for what, but I think, > this should work: > > - 2 stmmac patches should go together via some networking tree (is there > something specific for stmmac?) > - all DTS patches should go via sunxi > - hdmi patches via some drm tree Thank you. So I'll merge the first two patches that touch the stmmac driver via my net-next tree.
Re: [PATCH v2 3/3] ARM: dts: rockchip: Add RK3288 VOP gamma LUT address
Hi, On Fri, Jun 21, 2019 at 2:14 PM Ezequiel Garcia wrote: > > RK3288 SoC VOPs have optional support Gamma LUT setting, > which requires specifying the Gamma LUT address in the devicetree. > > Signed-off-by: Ezequiel Garcia > --- > Changes from v1: > * Drop reg-names, as suggested by Doug. > --- > arch/arm/boot/dts/rk3288.dtsi | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Reviewed-by: Douglas Anderson
Re: [PATCH v2 2/3] drm/rockchip: Add optional support for CRTC gamma LUT
Hi, On Fri, Jun 21, 2019 at 2:14 PM Ezequiel Garcia wrote: > > Add an optional CRTC gamma LUT support, and enable it on RK3288. > This is currently enabled via a separate address resource, > which needs to be specified in the devicetree. > > The address resource is required because on some SoCs, such as > RK3288, the LUT address is after the MMU address, and the latter > is supported by a different driver. This prevents the DRM driver > from requesting an entire register space. > > The current implementation works for RGB 10-bit tables, as that > is what seems to work on RK3288. > > Signed-off-by: Ezequiel Garcia > --- > Changes from v1: > * drop explicit linear LUT after finding a proper > way to disable gamma correction. > * avoid setting gamma is the CRTC is not active. > * s/int/unsigned int as suggested by Jacopo. > * only enable color management and set gamma size > if gamma LUT is supported, suggested by Doug. > * drop the reg-names usage, and instead just use indexed reg > specifiers, suggested by Doug. > > Changes from RFC: > * Request (an optional) address resource for the LUT. > * Drop support for RK3399, which doesn't seem to work > out of the box and needs more research. > * Support pass-thru setting when GAMMA_LUT is NULL. > * Add a check for the gamma size, as suggested by Ilia. > * Move gamma setting to atomic_commit_tail, as pointed > out by Jacopo/Laurent, is the correct way. > --- > drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 3 + > drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 114 > drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 7 ++ > drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 2 + > 4 files changed, 126 insertions(+) Looks happy to me now. Since I'm not a DRM expert and almost certainly don't know much about gamma LUT, take this as you will: Reviewed-by: Douglas Anderson I'm not in front of my veyron device at the moment, so I can't re-test exactly this patch so I won't add a Tested-by tag. However, I'll note that earlier versions worked for the test app I was able to find in Chrome OS and I'd imagine this one does too. -Doug
[PATCH v6 2/5] dma-buf: heaps: Add heap helpers
Add generic helper dmabuf ops for dma heaps, so we can reduce
the amount of duplicative code for the exported dmabufs.
This code is an evolution of the Android ION implementation, so
thanks to its original authors and maintainters:
Rebecca Schultz Zavin, Colin Cross, Laura Abbott, and others!
Cc: Laura Abbott
Cc: Benjamin Gaignard
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Pratik Patel
Cc: Brian Starkey
Cc: Vincent Donnefort
Cc: Sudipto Paul
Cc: Andrew F. Davis
Cc: Xu YiPing
Cc: "Chenfeng (puck)"
Cc: butao
Cc: "Xiaqing (A)"
Cc: Yudongbin
Cc: Christoph Hellwig
Cc: Chenbo Feng
Cc: Alistair Strachan
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Benjamin Gaignard
Signed-off-by: John Stultz
Change-Id: I48d43656e7783f266d877e363116b5187639f996
---
v2:
* Removed cache management performance hack that I had
accidentally folded in.
* Removed stats code that was in helpers
* Lots of checkpatch cleanups
v3:
* Uninline INIT_HEAP_HELPER_BUFFER (suggested by Christoph)
* Switch to WARN on buffer destroy failure (suggested by Brian)
* buffer->kmap_cnt decrementing cleanup (suggested by Christoph)
* Extra buffer->vaddr checking in dma_heap_dma_buf_kmap
(suggested by Brian)
* Switch to_helper_buffer from macro to inline function
(suggested by Benjamin)
* Rename kmap->vmap (folded in from Andrew)
* Use vmap for vmapping - not begin_cpu_access (folded in from
Andrew)
* Drop kmap for now, as its optional (folded in from Andrew)
* Fold dma_heap_map_user into the single caller (foled in from
Andrew)
* Folded in patch from Andrew to track page list per heap not
sglist, which simplifies the tracking logic
v4:
* Moved dma-heap.h change out to previous patch
v6:
* Minor cleanups and typo fixes suggested by Brian
---
drivers/dma-buf/Makefile | 1 +
drivers/dma-buf/heaps/Makefile | 2 +
drivers/dma-buf/heaps/heap-helpers.c | 262 +++
drivers/dma-buf/heaps/heap-helpers.h | 54 ++
4 files changed, 319 insertions(+)
create mode 100644 drivers/dma-buf/heaps/Makefile
create mode 100644 drivers/dma-buf/heaps/heap-helpers.c
create mode 100644 drivers/dma-buf/heaps/heap-helpers.h
diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile
index 1cb3dd104825..e3e3dca29e46 100644
--- a/drivers/dma-buf/Makefile
+++ b/drivers/dma-buf/Makefile
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: GPL-2.0-only
obj-y := dma-buf.o dma-fence.o dma-fence-array.o dma-fence-chain.o \
reservation.o seqno-fence.o
+obj-$(CONFIG_DMABUF_HEAPS) += heaps/
obj-$(CONFIG_DMABUF_HEAPS) += dma-heap.o
obj-$(CONFIG_SYNC_FILE)+= sync_file.o
obj-$(CONFIG_SW_SYNC) += sw_sync.o sync_debug.o
diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile
new file mode 100644
index ..de49898112db
--- /dev/null
+++ b/drivers/dma-buf/heaps/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+obj-y += heap-helpers.o
diff --git a/drivers/dma-buf/heaps/heap-helpers.c
b/drivers/dma-buf/heaps/heap-helpers.c
new file mode 100644
index ..fba1895f3bf0
--- /dev/null
+++ b/drivers/dma-buf/heaps/heap-helpers.c
@@ -0,0 +1,262 @@
+// SPDX-License-Identifier: GPL-2.0
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "heap-helpers.h"
+
+void INIT_HEAP_HELPER_BUFFER(struct heap_helper_buffer *buffer,
+void (*free)(struct heap_helper_buffer *))
+{
+ buffer->private_flags = 0;
+ buffer->priv_virt = NULL;
+ mutex_init(&buffer->lock);
+ buffer->vmap_cnt = 0;
+ buffer->vaddr = NULL;
+ buffer->pagecount = 0;
+ buffer->pages = NULL;;
+ INIT_LIST_HEAD(&buffer->attachments);
+ buffer->free = free;
+}
+
+static void *dma_heap_map_kernel(struct heap_helper_buffer *buffer)
+{
+ void *vaddr;
+
+ vaddr = vmap(buffer->pages, buffer->pagecount, VM_MAP, PAGE_KERNEL);
+ if (!vaddr)
+ return ERR_PTR(-ENOMEM);
+
+ return vaddr;
+}
+
+static void dma_heap_buffer_destroy(struct dma_heap_buffer *heap_buffer)
+{
+ struct heap_helper_buffer *buffer = to_helper_buffer(heap_buffer);
+
+ if (buffer->vmap_cnt > 0) {
+ WARN("%s: buffer still mapped in the kernel\n",
+__func__);
+ vunmap(buffer->vaddr);
+ }
+
+ buffer->free(buffer);
+}
+
+static void *dma_heap_buffer_vmap_get(struct dma_heap_buffer *heap_buffer)
+{
+ struct heap_helper_buffer *buffer = to_helper_buffer(heap_buffer);
+ void *vaddr;
+
+ if (buffer->vmap_cnt) {
+ buffer->vmap_cnt++;
+ return buffer->vaddr;
+ }
+ vaddr = dma_heap_map_kernel(buffer);
+ if (WARN_ONCE(!vaddr,
+ "heap->ops->map_kernel should return ERR_PTR on error"))
+ return ERR_PTR(-EINVAL);
+ if (IS_ERR(vaddr))
+ return vaddr;
[PATCH v6 1/5] dma-buf: Add dma-buf heaps framework
From: "Andrew F. Davis" This framework allows a unified userspace interface for dma-buf exporters, allowing userland to allocate specific types of memory for use in dma-buf sharing. Each heap is given its own device node, which a user can allocate a dma-buf fd from using the DMA_HEAP_IOC_ALLOC. This code is an evoluiton of the Android ION implementation, and a big thanks is due to its authors/maintainers over time for their effort: Rebecca Schultz Zavin, Colin Cross, Benjamin Gaignard, Laura Abbott, and many other contributors! Cc: Laura Abbott Cc: Benjamin Gaignard Cc: Sumit Semwal Cc: Liam Mark Cc: Pratik Patel Cc: Brian Starkey Cc: Vincent Donnefort Cc: Sudipto Paul Cc: Andrew F. Davis Cc: Xu YiPing Cc: "Chenfeng (puck)" Cc: butao Cc: "Xiaqing (A)" Cc: Yudongbin Cc: Christoph Hellwig Cc: Chenbo Feng Cc: Alistair Strachan Cc: dri-devel@lists.freedesktop.org Reviewed-by: Benjamin Gaignard Signed-off-by: Andrew F. Davis Signed-off-by: John Stultz Change-Id: I4af43a137ad34ff6f7da4d6b2864f3cd86fb7652 --- v2: * Folded down fixes I had previously shared in implementing heaps * Make flags a u64 (Suggested by Laura) * Add PAGE_ALIGN() fix to the core alloc funciton * IOCTL fixups suggested by Brian * Added fixes suggested by Benjamin * Removed core stats mgmt, as that should be implemented by per-heap code * Changed alloc to return a dma-buf fd, rather than a buffer (as it simplifies error handling) v3: * Removed scare-quotes in MAINTAINERS email address * Get rid of .release function as it didn't do anything (from Christoph) * Renamed filp to file (suggested by Christoph) * Split out ioctl handling to separate function (suggested by Christoph) * Add comment documenting PAGE_ALIGN usage (suggested by Brian) * Switch from idr to Xarray (suggested by Brian) * Fixup cdev creation (suggested by Brian) * Avoid EXPORT_SYMBOL until we finalize modules (suggested by Brian) * Make struct dma_heap internal only (folded in from Andrew) * Small cleanups suggested by GregKH * Provide class->devnode callback to get consistent /dev/ subdirectory naming (Suggested by Bjorn) v4: * Folded down dma-heap.h change that was in a following patch * Added fd_flags entry to allocation structure and pass it through to heap code for use on dma-buf fd creation (suggested by Benjamin) v5: * Minor cleanups v6: * Improved error path handling, minor whitespace fixes, both suggested by Brian --- MAINTAINERS | 18 +++ drivers/dma-buf/Kconfig | 8 ++ drivers/dma-buf/Makefile | 1 + drivers/dma-buf/dma-heap.c| 249 ++ include/linux/dma-heap.h | 59 include/uapi/linux/dma-heap.h | 55 6 files changed, 390 insertions(+) create mode 100644 drivers/dma-buf/dma-heap.c create mode 100644 include/linux/dma-heap.h create mode 100644 include/uapi/linux/dma-heap.h diff --git a/MAINTAINERS b/MAINTAINERS index d0ed735994a5..851dbd006cdf 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4813,6 +4813,24 @@ F: include/linux/*fence.h F: Documentation/driver-api/dma-buf.rst T: git git://anongit.freedesktop.org/drm/drm-misc +DMA-BUF HEAPS FRAMEWORK +M: Sumit Semwal +R: Andrew F. Davis +R: Benjamin Gaignard +R: Liam Mark +R: Laura Abbott +R: Brian Starkey +R: John Stultz +S: Maintained +L: linux-me...@vger.kernel.org +L: dri-devel@lists.freedesktop.org +L: linaro-mm-...@lists.linaro.org (moderated for non-subscribers) +F: include/uapi/linux/dma-heap.h +F: include/linux/dma-heap.h +F: drivers/dma-buf/dma-heap.c +F: drivers/dma-buf/heaps/* +T: git git://anongit.freedesktop.org/drm/drm-misc + DMA GENERIC OFFLOAD ENGINE SUBSYSTEM M: Vinod Koul L: dmaeng...@vger.kernel.org diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig index d5f915830b68..9b93f86f597c 100644 --- a/drivers/dma-buf/Kconfig +++ b/drivers/dma-buf/Kconfig @@ -39,4 +39,12 @@ config UDMABUF A driver to let userspace turn memfd regions into dma-bufs. Qemu can use this to create host dmabufs for guest framebuffers. +menuconfig DMABUF_HEAPS + bool "DMA-BUF Userland Memory Heaps" + select DMA_SHARED_BUFFER + help + Choose this option to enable the DMA-BUF userland memory heaps, + this allows userspace to allocate dma-bufs that can be shared between + drivers. + endmenu diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile index e8c7310cb800..1cb3dd104825 100644 --- a/drivers/dma-buf/Makefile +++ b/drivers/dma-buf/Makefile @@ -1,6 +1,7 @@ # SPDX-License-Identifier: GPL-2.0-only obj-y := dma-buf.o dma-fence.o dma-fence-array.o dma-fence-chain.o \ reservation.o seqno-fence.o +obj-$(CONFIG_DMABUF_HEAPS) += dma-heap.o obj-$(CONFIG_SYNC_FILE)+= sync_file.o obj-$(CONFIG_SW_SYNC) += sw_sync.o sync_debug.o obj-$(CONFIG_UDMABUF) += udmabuf.o
[PATCH v6 5/5] kselftests: Add dma-heap test
Add very trivial allocation and import test for dma-heaps,
utilizing the vgem driver as a test importer.
A good chunk of this code taken from:
tools/testing/selftests/android/ion/ionmap_test.c
Originally by Laura Abbott
Cc: Benjamin Gaignard
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Pratik Patel
Cc: Brian Starkey
Cc: Vincent Donnefort
Cc: Sudipto Paul
Cc: Andrew F. Davis
Cc: Xu YiPing
Cc: "Chenfeng (puck)"
Cc: butao
Cc: "Xiaqing (A)"
Cc: Yudongbin
Cc: Christoph Hellwig
Cc: Chenbo Feng
Cc: Alistair Strachan
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Benjamin Gaignard
Signed-off-by: John Stultz
Change-Id: Ib98569fdda6378eb086b8092fb5d6bd419b8d431
---
v2:
* Switched to use reworked dma-heap apis
v3:
* Add simple mmap
* Utilize dma-buf testdev to test importing
v4:
* Rework to use vgem
* Pass in fd_flags to match interface changes
* Skip . and .. dirs
v6:
* Number of style/cleanups suggested by Brian
---
tools/testing/selftests/dmabuf-heaps/Makefile | 9 +
.../selftests/dmabuf-heaps/dmabuf-heap.c | 234 ++
2 files changed, 243 insertions(+)
create mode 100644 tools/testing/selftests/dmabuf-heaps/Makefile
create mode 100644 tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
diff --git a/tools/testing/selftests/dmabuf-heaps/Makefile
b/tools/testing/selftests/dmabuf-heaps/Makefile
new file mode 100644
index ..8c4c36e2972d
--- /dev/null
+++ b/tools/testing/selftests/dmabuf-heaps/Makefile
@@ -0,0 +1,9 @@
+# SPDX-License-Identifier: GPL-2.0
+CFLAGS += -static -O3 -Wl,-no-as-needed -Wall
+#LDLIBS += -lrt -lpthread -lm
+
+# these are all "safe" tests that don't modify
+# system time or require escalated privileges
+TEST_GEN_PROGS = dmabuf-heap
+
+include ../lib.mk
diff --git a/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
b/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
new file mode 100644
index ..1e93b6fbe459
--- /dev/null
+++ b/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
@@ -0,0 +1,234 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+
+#include "../../../../include/uapi/linux/dma-heap.h"
+
+#define DEVPATH "/dev/dma_heap"
+
+static int check_vgem(int fd)
+{
+ drm_version_t version = { 0 };
+ char name[5];
+ int ret;
+
+ version.name_len = 4;
+ version.name = name;
+
+ ret = ioctl(fd, DRM_IOCTL_VERSION, &version);
+ if (ret)
+ return 0;
+
+ return !strcmp(name, "vgem");
+}
+
+static int open_vgem(void)
+{
+ int i, fd;
+ const char *drmstr = "/dev/dri/card";
+
+ fd = -1;
+ for (i = 0; i < 16; i++) {
+ char name[80];
+
+ sprintf(name, "%s%u", drmstr, i);
+
+ fd = open(name, O_RDWR);
+ if (fd < 0)
+ continue;
+
+ if (!check_vgem(fd)) {
+ close(fd);
+ continue;
+ } else {
+ break;
+ }
+
+ }
+ return fd;
+}
+
+static int import_vgem_fd(int vgem_fd, int dma_buf_fd, uint32_t *handle)
+{
+ struct drm_prime_handle import_handle = {
+ .fd = dma_buf_fd,
+ .flags = 0,
+ .handle = 0,
+};
+ int ret;
+
+ ret = ioctl(vgem_fd, DRM_IOCTL_PRIME_FD_TO_HANDLE, &import_handle);
+ if (ret == 0)
+ *handle = import_handle.handle;
+ return ret;
+}
+
+static void close_handle(int vgem_fd, uint32_t handle)
+{
+ struct drm_gem_close close = {
+ .handle = handle,
+ };
+
+ ioctl(vgem_fd, DRM_IOCTL_GEM_CLOSE, &close);
+}
+
+
+static int dmabuf_heap_open(char *name)
+{
+ int ret, fd;
+ char buf[256];
+
+ ret = sprintf(buf, "%s/%s", DEVPATH, name);
+ if (ret < 0) {
+ printf("sprintf failed!\n");
+ return ret;
+ }
+
+ fd = open(buf, O_RDWR);
+ if (fd < 0)
+ printf("open %s failed!\n", buf);
+ return fd;
+}
+
+static int dmabuf_heap_alloc(int fd, size_t len, unsigned int flags, int
*dmabuf_fd)
+{
+ struct dma_heap_allocation_data data = {
+ .len = len,
+ .fd_flags = O_RDWR | O_CLOEXEC,
+ .heap_flags = flags,
+ };
+ int ret;
+
+ if (dmabuf_fd == NULL)
+ return -EINVAL;
+
+ ret = ioctl(fd, DMA_HEAP_IOC_ALLOC, &data);
+ if (ret < 0)
+ return ret;
+ *dmabuf_fd = (int)data.fd;
+ return ret;
+}
+
+static void dmabuf_sync(int fd, int start_stop)
+{
+ struct dma_buf_sync sync = {
+ .flags = start_stop | DMA_BUF_SYNC_RW,
+ };
+ int ret;
+
+ ret = ioctl(fd, DMA_BUF_IOCTL_SYNC, &sync);
+ if (ret)
+ printf("sync failed %d\n", errno);
+}
+
+#define ONE_MEG (1024*1024)
+
[PATCH v6 0/5] DMA-BUF Heaps (destaging ION)
Here is another pass at the dma-buf heaps patchset Andrew and I have been working on which tries to destage a fair chunk of ION functionality. The patchset implements per-heap devices which can be opened directly and then an ioctl is used to allocate a dmabuf from the heap. The interface is similar, but much simpler then IONs, only providing an ALLOC ioctl. Also, I've provided relatively simple system and cma heaps. I've booted and tested these patches with AOSP on the HiKey960 using the kernel tree here: https://git.linaro.org/people/john.stultz/android-dev.git/log/?h=dev/dma-buf-heap And the userspace changes here: https://android-review.googlesource.com/c/device/linaro/hikey/+/909436 Compared to ION, this patchset is missing the system-contig, carveout and chunk heaps, as I don't have a device that uses those, so I'm unable to do much useful validation there. Additionally we have no upstream users of chunk or carveout, and the system-contig has been deprecated in the common/andoid-* kernels, so this should be ok. I've also removed the stats accounting for now, since any such accounting should be implemented by dma-buf core or the heaps themselves. New in v6: * Number of cleanups and error path fixes suggested by Brian Starkey, many thanks for his close review and suggestions! Outstanding concerns: * Need to better understand various secure heap implementations. Some concern that heap private flags will be needed, but its also possible that dma-buf heaps can't solve everyone's needs, in which case, a vendor's secure buffer driver can implement their own dma-buf exporter. So I'm not too worried here. Thoughts and feedback would be greatly appreciated! thanks -john Cc: Laura Abbott Cc: Benjamin Gaignard Cc: Sumit Semwal Cc: Liam Mark Cc: Pratik Patel Cc: Brian Starkey Cc: Vincent Donnefort Cc: Sudipto Paul Cc: Andrew F. Davis Cc: Christoph Hellwig Cc: Chenbo Feng Cc: Alistair Strachan Cc: dri-devel@lists.freedesktop.org Andrew F. Davis (1): dma-buf: Add dma-buf heaps framework John Stultz (4): dma-buf: heaps: Add heap helpers dma-buf: heaps: Add system heap to dmabuf heaps dma-buf: heaps: Add CMA heap to dmabuf heaps kselftests: Add dma-heap test MAINTAINERS | 18 ++ drivers/dma-buf/Kconfig | 10 + drivers/dma-buf/Makefile | 2 + drivers/dma-buf/dma-heap.c| 249 + drivers/dma-buf/heaps/Kconfig | 14 + drivers/dma-buf/heaps/Makefile| 4 + drivers/dma-buf/heaps/cma_heap.c | 169 +++ drivers/dma-buf/heaps/heap-helpers.c | 262 ++ drivers/dma-buf/heaps/heap-helpers.h | 54 drivers/dma-buf/heaps/system_heap.c | 121 include/linux/dma-heap.h | 59 include/uapi/linux/dma-heap.h | 55 tools/testing/selftests/dmabuf-heaps/Makefile | 9 + .../selftests/dmabuf-heaps/dmabuf-heap.c | 234 14 files changed, 1260 insertions(+) create mode 100644 drivers/dma-buf/dma-heap.c create mode 100644 drivers/dma-buf/heaps/Kconfig create mode 100644 drivers/dma-buf/heaps/Makefile create mode 100644 drivers/dma-buf/heaps/cma_heap.c create mode 100644 drivers/dma-buf/heaps/heap-helpers.c create mode 100644 drivers/dma-buf/heaps/heap-helpers.h create mode 100644 drivers/dma-buf/heaps/system_heap.c create mode 100644 include/linux/dma-heap.h create mode 100644 include/uapi/linux/dma-heap.h create mode 100644 tools/testing/selftests/dmabuf-heaps/Makefile create mode 100644 tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c -- 2.17.1
[PATCH v6 4/5] dma-buf: heaps: Add CMA heap to dmabuf heaps
This adds a CMA heap, which allows userspace to allocate
a dma-buf of contiguous memory out of a CMA region.
This code is an evolution of the Android ION implementation, so
thanks to its original author and maintainters:
Benjamin Gaignard, Laura Abbott, and others!
Cc: Laura Abbott
Cc: Benjamin Gaignard
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Pratik Patel
Cc: Brian Starkey
Cc: Vincent Donnefort
Cc: Sudipto Paul
Cc: Andrew F. Davis
Cc: Xu YiPing
Cc: "Chenfeng (puck)"
Cc: butao
Cc: "Xiaqing (A)"
Cc: Yudongbin
Cc: Christoph Hellwig
Cc: Chenbo Feng
Cc: Alistair Strachan
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Benjamin Gaignard
Signed-off-by: John Stultz
Change-Id: Ic2b0c5dfc0dbaff5245bd1c50170c64b06c73051
---
v2:
* Switch allocate to return dmabuf fd
* Simplify init code
* Checkpatch fixups
v3:
* Switch to inline function for to_cma_heap()
* Minor cleanups suggested by Brian
* Fold in new registration style from Andrew
* Folded in changes from Andrew to use simplified page list
from the heap helpers
v4:
* Use the fd_flags when creating dmabuf fd (Suggested by
Benjamin)
* Use precalculated pagecount (Suggested by Andrew)
v6:
* Changed variable names to improve clarity, as suggested
by Brian
---
drivers/dma-buf/heaps/Kconfig| 8 ++
drivers/dma-buf/heaps/Makefile | 1 +
drivers/dma-buf/heaps/cma_heap.c | 169 +++
3 files changed, 178 insertions(+)
create mode 100644 drivers/dma-buf/heaps/cma_heap.c
diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
index 205052744169..a5eef06c4226 100644
--- a/drivers/dma-buf/heaps/Kconfig
+++ b/drivers/dma-buf/heaps/Kconfig
@@ -4,3 +4,11 @@ config DMABUF_HEAPS_SYSTEM
help
Choose this option to enable the system dmabuf heap. The system heap
is backed by pages from the buddy allocator. If in doubt, say Y.
+
+config DMABUF_HEAPS_CMA
+ bool "DMA-BUF CMA Heap"
+ depends on DMABUF_HEAPS && DMA_CMA
+ help
+ Choose this option to enable dma-buf CMA heap. This heap is backed
+ by the Contiguous Memory Allocator (CMA). If your system has these
+ regions, you should say Y here.
diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile
index d1808eca2581..6e54cdec3da0 100644
--- a/drivers/dma-buf/heaps/Makefile
+++ b/drivers/dma-buf/heaps/Makefile
@@ -1,3 +1,4 @@
# SPDX-License-Identifier: GPL-2.0
obj-y += heap-helpers.o
obj-$(CONFIG_DMABUF_HEAPS_SYSTEM) += system_heap.o
+obj-$(CONFIG_DMABUF_HEAPS_CMA) += cma_heap.o
diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c
new file mode 100644
index ..d2b10878b60b
--- /dev/null
+++ b/drivers/dma-buf/heaps/cma_heap.c
@@ -0,0 +1,169 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * DMABUF CMA heap exporter
+ *
+ * Copyright (C) 2012, 2019 Linaro Ltd.
+ * Author: for ST-Ericsson.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "heap-helpers.h"
+
+struct cma_heap {
+ struct dma_heap *heap;
+ struct cma *cma;
+};
+
+static void cma_heap_free(struct heap_helper_buffer *buffer)
+{
+ struct cma_heap *cma_heap = dma_heap_get_data(buffer->heap_buffer.heap);
+ unsigned long nr_pages = buffer->pagecount;
+ struct page *cma_pages = buffer->priv_virt;
+
+ /* free page list */
+ kfree(buffer->pages);
+ /* release memory */
+ cma_release(cma_heap->cma, cma_pages, nr_pages);
+ kfree(buffer);
+}
+
+/* dmabuf heap CMA operations functions */
+static int cma_heap_allocate(struct dma_heap *heap,
+ unsigned long len,
+ unsigned long fd_flags,
+ unsigned long heap_flags)
+{
+ struct cma_heap *cma_heap = dma_heap_get_data(heap);
+ struct heap_helper_buffer *helper_buffer;
+ struct page *cma_pages;
+ size_t size = PAGE_ALIGN(len);
+ unsigned long nr_pages = size >> PAGE_SHIFT;
+ unsigned long align = get_order(size);
+ DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
+ struct dma_buf *dmabuf;
+ int ret = -ENOMEM;
+ pgoff_t pg;
+
+ if (align > CONFIG_CMA_ALIGNMENT)
+ align = CONFIG_CMA_ALIGNMENT;
+
+ helper_buffer = kzalloc(sizeof(*helper_buffer), GFP_KERNEL);
+ if (!helper_buffer)
+ return -ENOMEM;
+
+ INIT_HEAP_HELPER_BUFFER(helper_buffer, cma_heap_free);
+ helper_buffer->heap_buffer.flags = heap_flags;
+ helper_buffer->heap_buffer.heap = heap;
+ helper_buffer->heap_buffer.size = len;
+
+ cma_pages = cma_alloc(cma_heap->cma, nr_pages, align, false);
+ if (!cma_pages)
+ goto free_buf;
+
+ if (PageHighMem(cma_pages)) {
+ unsigned long nr_clear_pages = nr_pages;
+ struct page *page = cma_pages;
+
+
[PATCH v6 3/5] dma-buf: heaps: Add system heap to dmabuf heaps
This patch adds system heap to the dma-buf heaps framework.
This allows applications to get a page-allocator backed dma-buf
for non-contiguous memory.
This code is an evolution of the Android ION implementation, so
thanks to its original authors and maintainters:
Rebecca Schultz Zavin, Colin Cross, Laura Abbott, and others!
Cc: Laura Abbott
Cc: Benjamin Gaignard
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Pratik Patel
Cc: Brian Starkey
Cc: Vincent Donnefort
Cc: Sudipto Paul
Cc: Andrew F. Davis
Cc: Xu YiPing
Cc: "Chenfeng (puck)"
Cc: butao
Cc: "Xiaqing (A)"
Cc: Yudongbin
Cc: Christoph Hellwig
Cc: Chenbo Feng
Cc: Alistair Strachan
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Benjamin Gaignard
Signed-off-by: John Stultz
Change-Id: I4dc5ff54ccb1f7ca3ac8675661114ca33813654b
---
v2:
* Switch allocate to return dmabuf fd
* Simplify init code
* Checkpatch fixups
* Droped dead system-contig code
v3:
* Whitespace fixups from Benjamin
* Make sure we're zeroing the allocated pages (from Liam)
* Use PAGE_ALIGN() consistently (suggested by Brian)
* Fold in new registration style from Andrew
* Avoid needless dynamic allocation of sys_heap (suggested by
Christoph)
* Minor cleanups
* Folded in changes from Andrew to use simplified page list
from the heap helpers
v4:
* Optimization to allocate pages in chunks, similar to old
pagepool code
* Use fd_flags when creating dmabuf fd (Suggested by Benjamin)
v5:
* Back out large order page allocations (was leaking memory,
as the page array didn't properly track order size)
v6:
* Minor whitespace change suggested by Brian
* Remove unused variable
---
drivers/dma-buf/Kconfig | 2 +
drivers/dma-buf/heaps/Kconfig | 6 ++
drivers/dma-buf/heaps/Makefile | 1 +
drivers/dma-buf/heaps/system_heap.c | 121
4 files changed, 130 insertions(+)
create mode 100644 drivers/dma-buf/heaps/Kconfig
create mode 100644 drivers/dma-buf/heaps/system_heap.c
diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig
index 9b93f86f597c..434cfe646dad 100644
--- a/drivers/dma-buf/Kconfig
+++ b/drivers/dma-buf/Kconfig
@@ -47,4 +47,6 @@ menuconfig DMABUF_HEAPS
this allows userspace to allocate dma-bufs that can be shared between
drivers.
+source "drivers/dma-buf/heaps/Kconfig"
+
endmenu
diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
new file mode 100644
index ..205052744169
--- /dev/null
+++ b/drivers/dma-buf/heaps/Kconfig
@@ -0,0 +1,6 @@
+config DMABUF_HEAPS_SYSTEM
+ bool "DMA-BUF System Heap"
+ depends on DMABUF_HEAPS
+ help
+ Choose this option to enable the system dmabuf heap. The system heap
+ is backed by pages from the buddy allocator. If in doubt, say Y.
diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile
index de49898112db..d1808eca2581 100644
--- a/drivers/dma-buf/heaps/Makefile
+++ b/drivers/dma-buf/heaps/Makefile
@@ -1,2 +1,3 @@
# SPDX-License-Identifier: GPL-2.0
obj-y += heap-helpers.o
+obj-$(CONFIG_DMABUF_HEAPS_SYSTEM) += system_heap.o
diff --git a/drivers/dma-buf/heaps/system_heap.c
b/drivers/dma-buf/heaps/system_heap.c
new file mode 100644
index ..6a16806181c2
--- /dev/null
+++ b/drivers/dma-buf/heaps/system_heap.c
@@ -0,0 +1,121 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * DMABUF System heap exporter
+ *
+ * Copyright (C) 2011 Google, Inc.
+ * Copyright (C) 2019 Linaro Ltd.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "heap-helpers.h"
+
+struct system_heap {
+ struct dma_heap *heap;
+} sys_heap;
+
+static void system_heap_free(struct heap_helper_buffer *buffer)
+{
+ pgoff_t pg;
+
+ for (pg = 0; pg < buffer->pagecount; pg++)
+ __free_page(buffer->pages[pg]);
+ kfree(buffer->pages);
+ kfree(buffer);
+}
+
+static int system_heap_allocate(struct dma_heap *heap,
+ unsigned long len,
+ unsigned long fd_flags,
+ unsigned long heap_flags)
+{
+ struct heap_helper_buffer *helper_buffer;
+ DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
+ struct dma_buf *dmabuf;
+ int ret = -ENOMEM;
+ pgoff_t pg;
+
+ helper_buffer = kzalloc(sizeof(*helper_buffer), GFP_KERNEL);
+ if (!helper_buffer)
+ return -ENOMEM;
+
+ INIT_HEAP_HELPER_BUFFER(helper_buffer, system_heap_free);
+ helper_buffer->heap_buffer.flags = heap_flags;
+ helper_buffer->heap_buffer.heap = heap;
+ helper_buffer->heap_buffer.size = len;
+
+ helper_buffer->pagecount = len / PAGE_SIZE;
+ helper_buffer->pages = kmalloc_array(helper_buffer->pagecount,
+sizeof(*helper_buffer->pages),
+GFP_KERNEL);
+ if (!helper_buffe
Re: [PATCH v2 1/3] dt-bindings: display: rockchip: document VOP gamma LUT address
Hi, On Fri, Jun 21, 2019 at 2:14 PM Ezequiel Garcia wrote: > > Add the register specifier description for an > optional gamma LUT address. > > Signed-off-by: Ezequiel Garcia > --- > Changes from v1: > * Drop reg-names, suggested by Doug. > --- > .../devicetree/bindings/display/rockchip/rockchip-vop.txt | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) Reviewed-by: Douglas Anderson ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] backlight: pwm_bl: Set scale type for brightness curves specified in the DT
Hi Daniel,
On Fri, Jun 21, 2019 at 02:10:19PM +0100, Daniel Thompson wrote:
> On 13/06/2019 20:43, Matthias Kaehlcke wrote:
> > Check if a brightness curve specified in the device tree is linear or
> > not and set the corresponding property accordingly. This makes the
> > scale type available to userspace via the 'scale' sysfs attribute.
> >
> > To determine if a curve is linear it is compared to a interpolated linear
> > curve between min and max brightness. The curve is considered linear if
> > no value deviates more than +/-5% of ${brightness_range} from their
> > interpolated value.
> >
> > Signed-off-by: Matthias Kaehlcke
> > ---
> > drivers/video/backlight/pwm_bl.c | 25 +
> > 1 file changed, 25 insertions(+)
> >
> > diff --git a/drivers/video/backlight/pwm_bl.c
> > b/drivers/video/backlight/pwm_bl.c
> > index f067fe7aa35d..912407b6d67f 100644
> > --- a/drivers/video/backlight/pwm_bl.c
> > +++ b/drivers/video/backlight/pwm_bl.c
> > @@ -404,6 +404,26 @@ int pwm_backlight_brightness_default(struct device
> > *dev,
> > }
> > #endif
> > +static bool pwm_backlight_is_linear(struct platform_pwm_backlight_data
> > *data)
> > +{
> > + unsigned int nlevels = data->max_brightness + 1;
> > + unsigned int min_val = data->levels[0];
> > + unsigned int max_val = data->levels[nlevels - 1];
> > + unsigned int slope = (100 * (max_val - min_val)) / nlevels;
>
> Why 100 (rather than a power of 2)?
I guess it came from the decimal part of my brain, I can change it to
128 ;-)
> It would also be good to have a comment here saying what the maximum
> quantization error is. Doesn't have to be over complex just mentioning
> something like the following (assuming you agree that its true ;-) ):
>
> Multiplying by XXX means that even in pathalogical cases such as
> (max_val - min_val) == nlevels then the error at max_val is less than
> 1%.
Sounds good, thanks for the suggestion!
> With a suitable comment in the fixed point code:
> Acked-by: Daniel Thompson
Thanks
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110984] Vulkan shows stuttering issues on Vega 10 w/ gnome-shell on Wayland
https://bugs.freedesktop.org/show_bug.cgi?id=110984
Bug ID: 110984
Summary: Vulkan shows stuttering issues on Vega 10 w/
gnome-shell on Wayland
Product: DRI
Version: DRI git
Hardware: Other
OS: All
Status: NEW
Severity: major
Priority: medium
Component: DRM/AMDgpu
Assignee: dri-devel@lists.freedesktop.org
Reporter: ly...@redhat.com
When testing the latest kernel from drm-tip (as of writing, this is
294d5056c1f3 ("drm-tip: 2019y-06m-24d-17h-20m-57s UTC integration manifest") ),
running vulkan-cube on a gnome-shell wayland session (so, since vulkan-cube
doesn't support native wayland this means it's running through Xwayland) shows
pretty significant stuttering issues. See the video here for what it looks
like:
https://people.freedesktop.org/~lyudess/archive/06-24-2019/VID_20190624_140614.mp4
This was reproduced with a Vega 10 Pro SSG:
26:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc.
[AMD/ATI] Vega 10 XT [Radeon PRO SSG] [1002:6862]
Mesa version: 19.0.6-1.fc30
gnome-shell version: 3.32.2-2.fc30
Xwayland version: 1.20.4-3.fc30
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 0/5] drm/panel-simple: Add panel parameters for ortustech-com37h3m05dtc/99dtc and sharp-lq070y3dg3b
Hi, > Am 07.06.2019 um 13:11 schrieb H. Nikolaus Schaller : > > V3: > * add bindings documentation (suggested by s...@ravnborg.org) > > V2 2019-06-05 07:07:05: > * fix typo in 99dtc panel compatible string (reported by imir...@alum.mit.edu) > > V1 2019-06-04 14:53:00: > > Since v5.2-rc1 OMAP is no longer using a special display driver architecture > for DPI panels, but uses the general drm/panel/panel-simple. > > So we finally can add SoC independent panel definitions for two panel models > which we already had worked on quite a while ago (before device tree was > introduced): > > https://patchwork.kernel.org/patch/2851295/ > > > > H. Nikolaus Schaller (5): > drm/panel: simple: Add Sharp LQ070Y3DG3B panel support > drm/panel: simple: Add Ortustech COM37H3M panel support > dt-bindings: drm/panel: simple: add ortustech,com37h3m05dtc panel > dt-bindings: drm/panel: simple: add ortustech,com37h3m99dtc panel > dt-bindings: drm/panel: simple: add sharp,lq070y3dg3b panel > > .../display/panel/ortustech,com37h3m05dtc.txt | 12 > .../display/panel/ortustech,com37h3m99dtc.txt | 12 > .../display/panel/sharp,lq070y3dg3b.txt | 12 > drivers/gpu/drm/panel/panel-simple.c | 63 +++ > 4 files changed, 99 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/panel/ortustech,com37h3m05dtc.txt > create mode 100644 > Documentation/devicetree/bindings/display/panel/ortustech,com37h3m99dtc.txt > create mode 100644 > Documentation/devicetree/bindings/display/panel/sharp,lq070y3dg3b.txt > > -- > 2.19.1 > any progress towards merging this somewhere? It did not yet arrive in linux-next. BTW: should also be applied to 5.2 BR and thanks, Nikolaus
Re: [PATCH 05/22] mm: export alloc_pages_vma
On Thu, Jun 20, 2019 at 12:17 PM Michal Hocko wrote: > > On Thu 13-06-19 11:43:08, Christoph Hellwig wrote: > > noveau is currently using this through an odd hmm wrapper, and I plan > > to switch it to the real thing later in this series. > > > > Signed-off-by: Christoph Hellwig > > --- > > mm/mempolicy.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/mm/mempolicy.c b/mm/mempolicy.c > > index 01600d80ae01..f9023b5fba37 100644 > > --- a/mm/mempolicy.c > > +++ b/mm/mempolicy.c > > @@ -2098,6 +2098,7 @@ alloc_pages_vma(gfp_t gfp, int order, struct > > vm_area_struct *vma, > > out: > > return page; > > } > > +EXPORT_SYMBOL_GPL(alloc_pages_vma); > > All allocator exported symbols are EXPORT_SYMBOL, what is a reason to > have this one special? I asked for this simply because it was not exported historically. In general I want to establish explicit export-type criteria so the community can spend less time debating when to use EXPORT_SYMBOL_GPL [1]. The thought in this instance is that it is not historically exported to modules and it is safer from a maintenance perspective to start with GPL-only for new symbols in case we don't want to maintain that interface long-term for out-of-tree modules. Yes, we always reserve the right to remove / change interfaces regardless of the export type, but history has shown that external pressure to keep an interface stable (contrary to Documentation/process/stable-api-nonsense.rst) tends to be less for GPL-only exports. [1]: https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2018-September/005688.html ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 0/6] Add support for Orange Pi 3
On Mon, Jun 24, 2019 at 10:29:27AM -0700, David Miller wrote: > From: meg...@megous.com > Date: Thu, 20 Jun 2019 15:47:42 +0200 > > > From: Ondrej Jirman > > > > This series implements support for Xunlong Orange Pi 3 board. > > > > - ethernet support (patches 1-3) > > - HDMI support (patches 4-6) > > > > For some people, ethernet doesn't work after reboot (but works on cold > > boot), when the stmmac driver is built into the kernel. It works when > > the driver is built as a module. It's either some timing issue, or power > > supply issue or a combination of both. Module build induces a power > > cycling of the phy. > > > > I encourage people with this issue, to build the driver into the kernel, > > and try to alter the reset timings for the phy in DTS or > > startup-delay-us and report the findings. > > This is a mixture of networking and non-networking changes so it really > can't go through my tree. > > I wonder how you expect this series to be merged? > > Thanks. This series was even longer before, with patches all around for various maintainers. I'd expect that relevant maintainers pick the range of patches meant for them. I don't know who's exactly responsible for what, but I think, this should work: - 2 stmmac patches should go together via some networking tree (is there something specific for stmmac?) - all DTS patches should go via sunxi - hdmi patches via some drm tree thank you and regards, o.
Re: [PATCH libdrm 0/9] amdgpu:
Patches #1 - #3 look good to me, but I'm not sure if the rest is such a good idea. Basically you not only want to use the same FD for CS, but also for basically all buffer functions and as far as I can see we break that here. I would rather add a new function to export the KMS handle for a certain BO/FD pair. Exporting the handle based on a type was also like trying to squeeze a round pig through a square hole in the first place. KMS, flink and DMA-buf fd are fundamentally different and shouldn't be handled by the same function in the first place. The only tricky part in this scenario is to know when to close the KMS handle again. Christian. Am 24.06.19 um 18:53 schrieb Michel Dänzer: From: Michel Dänzer The motivation for these patches is https://bugs.freedesktop.org/110903 . Patches 1-3 are preparatory. Patches 4 & 5 are the core patches allowing the issues discussed in the bug report to be fixed. Patches 6-8 are further optimizations / cleanups. Patch 9 is the Mesa patch making use of the new amdgpu_bo_handle_type_kms_user API to fix the user visible problem. Note that the libdrm patches need to land first, a libdrm release needs to be made, and the Mesa patch needs to bump the libdrm_amdgpu version requirement to that release's version before it can land. Michel Dänzer (9): amdgpu: Pass file descriptor directly to amdgpu_close_kms_handle amdgpu: Add BO handle to table in amdgpu_bo_create amdgpu: Rename fd_mutex/list to dev_mutex/list amdgpu: Add struct amdgpu_core_device and amdgpu_core_bo amdgpu: Add amdgpu_bo_handle_type_kms_user amdgpu: Re-use an existing amdgpu_device when possible amdgpu: Use normal integers for device / core BO reference counting amdgpu: Drop refcount member from struct amdgpu_core_bo/device winsys/amdgpu: Use amdgpu_bo_handle_type_kms_user for API KMS handles amdgpu/amdgpu.h | 14 +- amdgpu/amdgpu_asic_id.c | 4 +- amdgpu/amdgpu_bo.c| 367 ++ amdgpu/amdgpu_cs.c| 64 +++--- amdgpu/amdgpu_device.c| 281 +- amdgpu/amdgpu_gpu_info.c | 35 ++-- amdgpu/amdgpu_internal.h | 31 ++- amdgpu/amdgpu_vamgr.c | 9 +- amdgpu/amdgpu_vm.c| 4 +- tests/amdgpu/amdgpu_test.c| 2 +- tests/amdgpu/bo_tests.c | 2 +- tests/amdgpu/cs_tests.c | 8 +- tests/amdgpu/deadlock_tests.c | 8 +- tests/amdgpu/uvd_enc_tests.c | 2 +- tests/amdgpu/vce_tests.c | 12 +- tests/amdgpu/vcn_tests.c | 4 +- tests/amdgpu/vm_tests.c | 2 +- 17 files changed, 500 insertions(+), 349 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 0/6] Add support for Orange Pi 3
From: meg...@megous.com Date: Thu, 20 Jun 2019 15:47:42 +0200 > From: Ondrej Jirman > > This series implements support for Xunlong Orange Pi 3 board. > > - ethernet support (patches 1-3) > - HDMI support (patches 4-6) > > For some people, ethernet doesn't work after reboot (but works on cold > boot), when the stmmac driver is built into the kernel. It works when > the driver is built as a module. It's either some timing issue, or power > supply issue or a combination of both. Module build induces a power > cycling of the phy. > > I encourage people with this issue, to build the driver into the kernel, > and try to alter the reset timings for the phy in DTS or > startup-delay-us and report the findings. This is a mixture of networking and non-networking changes so it really can't go through my tree. I wonder how you expect this series to be merged? Thanks.
Re: [PATCH 4/4] drm/sun4i: Enable DRM InfoFrame support on H6
On 24.06.2019 18:07, Chen-Yu Tsai wrote:
> On Tue, Jun 25, 2019 at 12:03 AM Jernej Škrabec
> wrote:
>> Dne ponedeljek, 24. junij 2019 ob 17:56:30 CEST je Chen-Yu Tsai napisal(a):
>>> On Mon, Jun 24, 2019 at 11:49 PM Andrzej Hajda wrote:
On 24.06.2019 17:05, Jernej Škrabec wrote:
> Dne ponedeljek, 24. junij 2019 ob 17:03:31 CEST je Andrzej Hajda
>> napisal(a):
>> On 26.05.2019 23:20, Jonas Karlman wrote:
>>> This patch enables Dynamic Range and Mastering InfoFrame on H6.
>>>
>>> Cc: Maxime Ripard
>>> Cc: Jernej Skrabec
>>> Signed-off-by: Jonas Karlman
>>> ---
>>>
>>> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 2 ++
>>> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 1 +
>>> 2 files changed, 3 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
>>> b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c index
>>> 39d8509d96a0..b80164dd8ad8
>>> 100644
>>> --- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
>>> +++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
>>> @@ -189,6 +189,7 @@ static int sun8i_dw_hdmi_bind(struct device *dev,
>>> struct device *master,>
>>>
>>> sun8i_hdmi_phy_init(hdmi->phy);
>>>
>>> plat_data->mode_valid = hdmi->quirks->mode_valid;
>>>
>>> + plat_data->drm_infoframe = hdmi->quirks->drm_infoframe;
>>>
>>> sun8i_hdmi_phy_set_ops(hdmi->phy, plat_data);
>>>
>>> platform_set_drvdata(pdev, hdmi);
>>>
>>> @@ -255,6 +256,7 @@ static const struct sun8i_dw_hdmi_quirks
>>> sun8i_a83t_quirks = {>
>>>
>>> static const struct sun8i_dw_hdmi_quirks sun50i_h6_quirks = {
>>>
>>> .mode_valid = sun8i_dw_hdmi_mode_valid_h6,
>>>
>>> + .drm_infoframe = true,
>>>
>>> };
>>>
>>> static const struct of_device_id sun8i_dw_hdmi_dt_ids[] = {
>>>
>>> diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
>>> b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h index
>>> 720c5aa8adc1..2a0ec08ee236
>>> 100644
>>> --- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
>>> +++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
>>> @@ -178,6 +178,7 @@ struct sun8i_dw_hdmi_quirks {
>>>
>>> enum drm_mode_status (*mode_valid)(struct drm_connector
> *connector,
>
>>>const struct
> drm_display_mode *mode);
>
>>> unsigned int set_rate : 1;
>>>
>>> + unsigned int drm_infoframe : 1;
>> Again, drm_infoframe suggests it contains inforframe, but in fact it
>> just informs infoframe can be used, so again my suggestion
>> use_drm_infoframe.
>>
>> Moreover bool type seems more appropriate here.
> checkpatch will give warning if bool is used.
Then I would say "fix/ignore checkpatch" :)
But maybe there is a reason.
>>> Here's an old one from Linus: https://lkml.org/lkml/2013/9/1/154
>>>
>>> I'd say that bool in a struct is a waste of space compared to a 1 bit
>>> bitfield, especially when there already are other bitfields in the same
>>> struct.
Anyway I've tested and I do not see the warning, could you elaborate it.
>>> Maybe checkpatch.pl --strict?
>> It seems they removed that check:
>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?
>> id=7967656ffbfa493f5546c0f1
>>
>> After reading that block of text, I'm not sure what would be prefered way for
>> this case.
> This:
>
> +If a structure has many true/false values, consider consolidating them into a
> +bitfield with 1 bit members, or using an appropriate fixed width type, such
> as
> +u8.
>
> would suggest using a bitfield, or flags within a fixed width type?
OK, I have also guessed what kind of warning Jernej was writing about.
And IMO it rather does not fit here:
- no concurrent writes,
- no need for size/cache optimizations.
But since there are some controversies about bool in struct and file has
already convention of bitfield I do not insist on it, you can keep it as is.
Regards
Andrzej
>
> ChenYu
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm 2/9] amdgpu: Add BO handle to table in amdgpu_bo_create
From: Michel Dänzer
Simplifies its callers.
dev->bo_table_mutex is now always held when amdgpu_bo_create is called
(this was already the case in amdgpu_bo_import).
Signed-off-by: Michel Dänzer
---
amdgpu/amdgpu_bo.c | 32
1 file changed, 12 insertions(+), 20 deletions(-)
diff --git a/amdgpu/amdgpu_bo.c b/amdgpu/amdgpu_bo.c
index 6c0b8517..5bdb8fe8 100644
--- a/amdgpu/amdgpu_bo.c
+++ b/amdgpu/amdgpu_bo.c
@@ -53,11 +53,18 @@ static int amdgpu_bo_create(amdgpu_device_handle dev,
amdgpu_bo_handle *buf_handle)
{
struct amdgpu_bo *bo;
+ int r;
bo = calloc(1, sizeof(struct amdgpu_bo));
if (!bo)
return -ENOMEM;
+ r = handle_table_insert(&dev->bo_handles, handle, bo);
+ if (r) {
+ free(bo);
+ return r;
+ }
+
atomic_set(&bo->refcount, 1);
bo->dev = dev;
bo->alloc_size = size;
@@ -89,19 +96,14 @@ drm_public int amdgpu_bo_alloc(amdgpu_device_handle dev,
if (r)
goto out;
+ pthread_mutex_lock(&dev->bo_table_mutex);
r = amdgpu_bo_create(dev, alloc_buffer->alloc_size, args.out.handle,
buf_handle);
+ pthread_mutex_unlock(&dev->bo_table_mutex);
if (r) {
amdgpu_close_kms_handle(dev->fd, args.out.handle);
- goto out;
}
- pthread_mutex_lock(&dev->bo_table_mutex);
- r = handle_table_insert(&dev->bo_handles, (*buf_handle)->handle,
- *buf_handle);
- pthread_mutex_unlock(&dev->bo_table_mutex);
- if (r)
- amdgpu_bo_free(*buf_handle);
out:
return r;
}
@@ -363,15 +365,12 @@ drm_public int amdgpu_bo_import(amdgpu_device_handle dev,
if (r)
goto free_bo_handle;
- r = handle_table_insert(&dev->bo_handles, bo->handle, bo);
- if (r)
- goto free_bo_handle;
if (flink_name) {
bo->flink_name = flink_name;
r = handle_table_insert(&dev->bo_flink_names, flink_name,
bo);
if (r)
- goto remove_handle;
+ goto free_bo_handle;
}
@@ -380,8 +379,6 @@ drm_public int amdgpu_bo_import(amdgpu_device_handle dev,
pthread_mutex_unlock(&dev->bo_table_mutex);
return 0;
-remove_handle:
- handle_table_remove(&dev->bo_handles, bo->handle);
free_bo_handle:
if (flink_name && open_arg.handle)
amdgpu_close_kms_handle(dev->flink_fd, open_arg.handle);
@@ -597,18 +594,13 @@ drm_public int
amdgpu_create_bo_from_user_mem(amdgpu_device_handle dev,
if (r)
goto out;
+ pthread_mutex_lock(&dev->bo_table_mutex);
r = amdgpu_bo_create(dev, size, args.handle, buf_handle);
+ pthread_mutex_unlock(&dev->bo_table_mutex);
if (r) {
amdgpu_close_kms_handle(dev->fd, args.handle);
- goto out;
}
- pthread_mutex_lock(&dev->bo_table_mutex);
- r = handle_table_insert(&dev->bo_handles, (*buf_handle)->handle,
- *buf_handle);
- pthread_mutex_unlock(&dev->bo_table_mutex);
- if (r)
- amdgpu_bo_free(*buf_handle);
out:
return r;
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm 7/9] amdgpu: Use normal integers for device / core BO reference counting
From: Michel Dänzer
The dev_mutex / dev->bo_table_mutex is always locked when accessing the
reference counts, so no need for atomic operations.
Signed-off-by: Michel Dänzer
---
amdgpu/amdgpu_bo.c | 6 +++---
amdgpu/amdgpu_device.c | 18 ++
amdgpu/amdgpu_internal.h | 6 +++---
3 files changed, 16 insertions(+), 14 deletions(-)
diff --git a/amdgpu/amdgpu_bo.c b/amdgpu/amdgpu_bo.c
index 8d42db90..f40df484 100644
--- a/amdgpu/amdgpu_bo.c
+++ b/amdgpu/amdgpu_bo.c
@@ -65,7 +65,7 @@ static int amdgpu_core_bo_create(struct amdgpu_core_device
*dev,
return r;
}
- atomic_set(&bo->refcount, 1);
+ bo->refcount = 1;
bo->alloc_size = size;
bo->handle = handle;
pthread_mutex_init(&bo->cpu_access_mutex, NULL);
@@ -95,7 +95,7 @@ static int amdgpu_bo_create(amdgpu_device_handle user_dev,
goto out;
}
}
- atomic_inc(&bo->refcount);
+ bo->refcount++;
} else {
r = amdgpu_core_bo_create(dev, size, handle, &bo);
if (r)
@@ -467,7 +467,7 @@ static void amdgpu_core_bo_free(struct amdgpu_bo *user_bo)
struct amdgpu_core_device *dev = user_bo->dev->core;
struct amdgpu_core_bo *bo = user_bo->core;
- if (update_references(&bo->refcount, NULL)) {
+ if (--bo->refcount == 0) {
/* Remove the buffer from the hash tables. */
handle_table_remove(&dev->bo_handles, bo->handle);
diff --git a/amdgpu/amdgpu_device.c b/amdgpu/amdgpu_device.c
index 8d9a85c2..8a99b8bb 100644
--- a/amdgpu/amdgpu_device.c
+++ b/amdgpu/amdgpu_device.c
@@ -72,6 +72,9 @@ static int fd_compare(int fd1, int fd2)
static void amdgpu_device_free(struct amdgpu_core_device *dev)
{
+ if (--dev->refcount > 0)
+ return;
+
close(dev->fd);
amdgpu_vamgr_deinit(&dev->vamgr_32);
@@ -112,7 +115,7 @@ static int amdgpu_device_init(amdgpu_device_handle user_dev)
break;
if (dev_iter) {
- atomic_inc(&dev_iter->core->refcount);
+ dev_iter->core->refcount++;
user_dev->core = dev_iter->core;
return 0;
}
@@ -123,7 +126,7 @@ static int amdgpu_device_init(amdgpu_device_handle user_dev)
return -ENOMEM;
}
- atomic_set(&dev->refcount, 1);
+ dev->refcount = 1;
pthread_mutex_init(&dev->bo_table_mutex, NULL);
dev->fd = user_dev->user_fd;
@@ -199,7 +202,7 @@ drm_public int amdgpu_device_initialize(int fd,
for (user_dev = dev_list; user_dev; user_dev = user_dev->next) {
if (same_file_description(user_dev->user_fd, fd)) {
- atomic_inc(&user_dev->refcount);
+ user_dev->refcount++;
goto out;
}
}
@@ -233,7 +236,7 @@ drm_public int amdgpu_device_initialize(int fd,
goto cleanup;
}
- atomic_set(&user_dev->refcount, 1);
+ user_dev->refcount = 1;
user_dev->next = dev_list;
dev_list = user_dev;
@@ -248,7 +251,7 @@ out:
cleanup:
if (!user_dev->core || user_dev->user_fd != user_dev->core->fd)
close(user_dev->user_fd);
- if (user_dev->core && update_references(&user_dev->core->refcount,
NULL))
+ if (user_dev->core)
amdgpu_device_free(user_dev->core);
free(user_dev);
pthread_mutex_unlock(&dev_mutex);
@@ -261,7 +264,7 @@ drm_public int
amdgpu_device_deinitialize(amdgpu_device_handle user_dev)
pthread_mutex_lock(&dev_mutex);
- if (update_references(&user_dev->refcount, NULL)) {
+ if (--user_dev->refcount == 0) {
struct amdgpu_device **node = &dev_list;
while (*node != user_dev && (*node)->next)
@@ -271,8 +274,7 @@ drm_public int
amdgpu_device_deinitialize(amdgpu_device_handle user_dev)
if (user_dev->user_fd != dev->fd)
close(user_dev->user_fd);
- if (update_references(&dev->refcount, NULL))
- amdgpu_device_free(dev);
+ amdgpu_device_free(dev);
free(user_dev);
}
diff --git a/amdgpu/amdgpu_internal.h b/amdgpu/amdgpu_internal.h
index 686d50ec..70566f98 100644
--- a/amdgpu/amdgpu_internal.h
+++ b/amdgpu/amdgpu_internal.h
@@ -65,7 +65,7 @@ struct amdgpu_va {
};
struct amdgpu_core_device {
- atomic_t refcount;
+ int refcount;
int fd;
unsigned major_version;
unsigned minor_version;
@@ -90,14 +90,14 @@ struct amdgpu_core_device {
};
struct amdgpu_device {
- atomic_t refcount;
+ int refcount;
int user_fd;
struct amdgpu_core_device *core;
struct amdgpu_device *next;
};
struct amdgpu_core_bo {
- atomic_t refcount;
+ int refcount;
[PATCH libdrm 4/9] amdgpu: Add struct amdgpu_core_device and amdgpu_core_bo
From: Michel Dänzer
They can be referenced by any number of struct amdgpu_device/bo, which
are used for amdgpu_device/bo_handle in the public API.
This allows keeping track of the DRM file descriptor passed to
amdgpu_device_initialize and the one used for CS submission etc.
separately. The core structs hold the information relevant for the
latter.
Because we now always keep a duplicate of the file descriptor passed to
amdgpu_device_initialize, we can use that for flink, and we no longer
need to check its authentication status (flink could never be expected
to work after passing an unauthenticated file descriptor to
amdgpu_device_initialize).
Signed-off-by: Michel Dänzer
---
amdgpu/amdgpu_asic_id.c | 4 +-
amdgpu/amdgpu_bo.c| 251 ++
amdgpu/amdgpu_cs.c| 64 +
amdgpu/amdgpu_device.c| 219 -
amdgpu/amdgpu_gpu_info.c | 35 ++---
amdgpu/amdgpu_internal.h | 27 ++--
amdgpu/amdgpu_vamgr.c | 9 +-
amdgpu/amdgpu_vm.c| 4 +-
tests/amdgpu/amdgpu_test.c| 2 +-
tests/amdgpu/bo_tests.c | 2 +-
tests/amdgpu/cs_tests.c | 8 +-
tests/amdgpu/deadlock_tests.c | 8 +-
tests/amdgpu/uvd_enc_tests.c | 2 +-
tests/amdgpu/vce_tests.c | 12 +-
tests/amdgpu/vcn_tests.c | 4 +-
tests/amdgpu/vm_tests.c | 2 +-
16 files changed, 360 insertions(+), 293 deletions(-)
diff --git a/amdgpu/amdgpu_asic_id.c b/amdgpu/amdgpu_asic_id.c
index a5007ffc..356c8a59 100644
--- a/amdgpu/amdgpu_asic_id.c
+++ b/amdgpu/amdgpu_asic_id.c
@@ -34,7 +34,7 @@
#include "amdgpu_drm.h"
#include "amdgpu_internal.h"
-static int parse_one_line(struct amdgpu_device *dev, const char *line)
+static int parse_one_line(struct amdgpu_core_device *dev, const char *line)
{
char *buf, *saveptr;
char *s_did;
@@ -104,7 +104,7 @@ out:
return r;
}
-void amdgpu_parse_asic_ids(struct amdgpu_device *dev)
+void amdgpu_parse_asic_ids(struct amdgpu_core_device *dev)
{
FILE *fp;
char *line = NULL;
diff --git a/amdgpu/amdgpu_bo.c b/amdgpu/amdgpu_bo.c
index 5bdb8fe8..7fec1f15 100644
--- a/amdgpu/amdgpu_bo.c
+++ b/amdgpu/amdgpu_bo.c
@@ -47,15 +47,15 @@ static int amdgpu_close_kms_handle(int fd, uint32_t handle)
return drmIoctl(fd, DRM_IOCTL_GEM_CLOSE, &args);
}
-static int amdgpu_bo_create(amdgpu_device_handle dev,
- uint64_t size,
- uint32_t handle,
- amdgpu_bo_handle *buf_handle)
+static int amdgpu_core_bo_create(struct amdgpu_core_device *dev,
+uint64_t size,
+uint32_t handle,
+struct amdgpu_core_bo **out_bo)
{
- struct amdgpu_bo *bo;
+ struct amdgpu_core_bo *bo;
int r;
- bo = calloc(1, sizeof(struct amdgpu_bo));
+ bo = calloc(1, sizeof(struct amdgpu_core_bo));
if (!bo)
return -ENOMEM;
@@ -66,19 +66,64 @@ static int amdgpu_bo_create(amdgpu_device_handle dev,
}
atomic_set(&bo->refcount, 1);
- bo->dev = dev;
bo->alloc_size = size;
bo->handle = handle;
pthread_mutex_init(&bo->cpu_access_mutex, NULL);
- *buf_handle = bo;
+ *out_bo = bo;
return 0;
}
-drm_public int amdgpu_bo_alloc(amdgpu_device_handle dev,
+static int amdgpu_bo_create(amdgpu_device_handle user_dev,
+ uint64_t size,
+ uint32_t handle,
+ amdgpu_bo_handle *buf_handle)
+{
+ struct amdgpu_core_device *dev = user_dev->core;
+ struct amdgpu_bo *user_bo = NULL;
+ struct amdgpu_core_bo *bo;
+ int r;
+
+ bo = handle_table_lookup(&dev->bo_handles, handle);
+
+ if (bo) {
+ for (user_bo = bo->user_bos; user_bo; user_bo = user_bo->next) {
+ if (user_bo->dev == user_dev) {
+ /* Re-use existing buffer */
+ atomic_inc(&user_bo->refcount);
+ r = 0;
+ goto out;
+ }
+ }
+ atomic_inc(&bo->refcount);
+ } else {
+ r = amdgpu_core_bo_create(dev, size, handle, &bo);
+ if (r)
+ goto out;
+ }
+
+ user_bo = calloc(1, sizeof(struct amdgpu_bo));
+ if (!user_bo) {
+ r = -ENOMEM;
+ goto out;
+ }
+
+ atomic_set(&user_bo->refcount, 1);
+ user_bo->next = bo->user_bos;
+ bo->user_bos = user_bo;
+ user_bo->core = bo;
+ user_bo->dev = user_dev;
+
+out:
+ *buf_handle = user_bo;
+ return r;
+}
+
+drm_public int amdgpu_bo_alloc(amdgpu_device_handle user_dev,
struct amdgpu_bo_alloc_request *alloc_buffer,
[PATCH libdrm 1/9] amdgpu: Pass file descriptor directly to amdgpu_close_kms_handle
From: Michel Dänzer
And propagate drmIoctl's return value.
This allows replacing all remaining open-coded DRM_IOCTL_GEM_CLOSE
ioctl calls with amdgpu_close_kms_handle calls.
Signed-off-by: Michel Dänzer
---
amdgpu/amdgpu_bo.c | 35 +++
1 file changed, 15 insertions(+), 20 deletions(-)
diff --git a/amdgpu/amdgpu_bo.c b/amdgpu/amdgpu_bo.c
index 32ee358f..6c0b8517 100644
--- a/amdgpu/amdgpu_bo.c
+++ b/amdgpu/amdgpu_bo.c
@@ -39,13 +39,12 @@
#include "amdgpu_internal.h"
#include "util_math.h"
-static void amdgpu_close_kms_handle(amdgpu_device_handle dev,
-uint32_t handle)
+static int amdgpu_close_kms_handle(int fd, uint32_t handle)
{
struct drm_gem_close args = {};
args.handle = handle;
- drmIoctl(dev->fd, DRM_IOCTL_GEM_CLOSE, &args);
+ return drmIoctl(fd, DRM_IOCTL_GEM_CLOSE, &args);
}
static int amdgpu_bo_create(amdgpu_device_handle dev,
@@ -93,7 +92,7 @@ drm_public int amdgpu_bo_alloc(amdgpu_device_handle dev,
r = amdgpu_bo_create(dev, alloc_buffer->alloc_size, args.out.handle,
buf_handle);
if (r) {
- amdgpu_close_kms_handle(dev, args.out.handle);
+ amdgpu_close_kms_handle(dev->fd, args.out.handle);
goto out;
}
@@ -214,11 +213,8 @@ static int amdgpu_bo_export_flink(amdgpu_bo_handle bo)
bo->flink_name = flink.name;
- if (bo->dev->flink_fd != bo->dev->fd) {
- struct drm_gem_close args = {};
- args.handle = handle;
- drmIoctl(bo->dev->flink_fd, DRM_IOCTL_GEM_CLOSE, &args);
- }
+ if (bo->dev->flink_fd != bo->dev->fd)
+ amdgpu_close_kms_handle(bo->dev->flink_fd, handle);
pthread_mutex_lock(&bo->dev->bo_table_mutex);
r = handle_table_insert(&bo->dev->bo_flink_names, bo->flink_name, bo);
@@ -261,7 +257,6 @@ drm_public int amdgpu_bo_import(amdgpu_device_handle dev,
struct amdgpu_bo_import_result *output)
{
struct drm_gem_open open_arg = {};
- struct drm_gem_close close_arg = {};
struct amdgpu_bo *bo = NULL;
uint32_t handle = 0, flink_name = 0;
uint64_t alloc_size = 0;
@@ -345,12 +340,12 @@ drm_public int amdgpu_bo_import(amdgpu_device_handle dev,
close(dma_fd);
if (r)
goto free_bo_handle;
- close_arg.handle = open_arg.handle;
- r = drmIoctl(dev->flink_fd, DRM_IOCTL_GEM_CLOSE,
-&close_arg);
+ r = amdgpu_close_kms_handle(dev->flink_fd,
+ open_arg.handle);
if (r)
goto free_bo_handle;
}
+ open_arg.handle = 0;
break;
case amdgpu_bo_handle_type_dma_buf_fd:
@@ -388,14 +383,13 @@ drm_public int amdgpu_bo_import(amdgpu_device_handle dev,
remove_handle:
handle_table_remove(&dev->bo_handles, bo->handle);
free_bo_handle:
- if (flink_name && !close_arg.handle && open_arg.handle) {
- close_arg.handle = open_arg.handle;
- drmIoctl(dev->flink_fd, DRM_IOCTL_GEM_CLOSE, &close_arg);
- }
+ if (flink_name && open_arg.handle)
+ amdgpu_close_kms_handle(dev->flink_fd, open_arg.handle);
+
if (bo)
amdgpu_bo_free(bo);
else
- amdgpu_close_kms_handle(dev, handle);
+ amdgpu_close_kms_handle(dev->fd, handle);
unlock:
pthread_mutex_unlock(&dev->bo_table_mutex);
return r;
@@ -424,12 +418,13 @@ drm_public int amdgpu_bo_free(amdgpu_bo_handle buf_handle)
amdgpu_bo_cpu_unmap(bo);
}
- amdgpu_close_kms_handle(dev, bo->handle);
+ amdgpu_close_kms_handle(dev->fd, bo->handle);
pthread_mutex_destroy(&bo->cpu_access_mutex);
free(bo);
}
pthread_mutex_unlock(&dev->bo_table_mutex);
+
return 0;
}
@@ -604,7 +599,7 @@ drm_public int
amdgpu_create_bo_from_user_mem(amdgpu_device_handle dev,
r = amdgpu_bo_create(dev, size, args.handle, buf_handle);
if (r) {
- amdgpu_close_kms_handle(dev, args.handle);
+ amdgpu_close_kms_handle(dev->fd, args.handle);
goto out;
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm 3/9] amdgpu: Rename fd_mutex/list to dev_mutex/list
From: Michel Dänzer
Seems to better reflect what they're for.
Signed-off-by: Michel Dänzer
---
amdgpu/amdgpu_device.c | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/amdgpu/amdgpu_device.c b/amdgpu/amdgpu_device.c
index 362494b1..76b4e5eb 100644
--- a/amdgpu/amdgpu_device.c
+++ b/amdgpu/amdgpu_device.c
@@ -43,8 +43,8 @@
#define PTR_TO_UINT(x) ((unsigned)((intptr_t)(x)))
-static pthread_mutex_t fd_mutex = PTHREAD_MUTEX_INITIALIZER;
-static amdgpu_device_handle fd_list;
+static pthread_mutex_t dev_mutex = PTHREAD_MUTEX_INITIALIZER;
+static amdgpu_device_handle dev_list;
static int fd_compare(int fd1, int fd2)
{
@@ -95,13 +95,13 @@ static int amdgpu_get_auth(int fd, int *auth)
static void amdgpu_device_free_internal(amdgpu_device_handle dev)
{
- amdgpu_device_handle *node = &fd_list;
+ amdgpu_device_handle *node = &dev_list;
- pthread_mutex_lock(&fd_mutex);
+ pthread_mutex_lock(&dev_mutex);
while (*node != dev && (*node)->next)
node = &(*node)->next;
*node = (*node)->next;
- pthread_mutex_unlock(&fd_mutex);
+ pthread_mutex_unlock(&dev_mutex);
close(dev->fd);
if ((dev->flink_fd >= 0) && (dev->fd != dev->flink_fd))
@@ -155,16 +155,16 @@ drm_public int amdgpu_device_initialize(int fd,
*device_handle = NULL;
- pthread_mutex_lock(&fd_mutex);
+ pthread_mutex_lock(&dev_mutex);
r = amdgpu_get_auth(fd, &flag_auth);
if (r) {
fprintf(stderr, "%s: amdgpu_get_auth (1) failed (%i)\n",
__func__, r);
- pthread_mutex_unlock(&fd_mutex);
+ pthread_mutex_unlock(&dev_mutex);
return r;
}
- for (dev = fd_list; dev; dev = dev->next)
+ for (dev = dev_list; dev; dev = dev->next)
if (fd_compare(dev->fd, fd) == 0)
break;
@@ -173,7 +173,7 @@ drm_public int amdgpu_device_initialize(int fd,
if (r) {
fprintf(stderr, "%s: amdgpu_get_auth (2) failed (%i)\n",
__func__, r);
- pthread_mutex_unlock(&fd_mutex);
+ pthread_mutex_unlock(&dev_mutex);
return r;
}
if ((flag_auth) && (!flag_authexist)) {
@@ -182,14 +182,14 @@ drm_public int amdgpu_device_initialize(int fd,
*major_version = dev->major_version;
*minor_version = dev->minor_version;
amdgpu_device_reference(device_handle, dev);
- pthread_mutex_unlock(&fd_mutex);
+ pthread_mutex_unlock(&dev_mutex);
return 0;
}
dev = calloc(1, sizeof(struct amdgpu_device));
if (!dev) {
fprintf(stderr, "%s: calloc failed\n", __func__);
- pthread_mutex_unlock(&fd_mutex);
+ pthread_mutex_unlock(&dev_mutex);
return -ENOMEM;
}
@@ -265,9 +265,9 @@ drm_public int amdgpu_device_initialize(int fd,
*major_version = dev->major_version;
*minor_version = dev->minor_version;
*device_handle = dev;
- dev->next = fd_list;
- fd_list = dev;
- pthread_mutex_unlock(&fd_mutex);
+ dev->next = dev_list;
+ dev_list = dev;
+ pthread_mutex_unlock(&dev_mutex);
return 0;
@@ -275,7 +275,7 @@ cleanup:
if (dev->fd >= 0)
close(dev->fd);
free(dev);
- pthread_mutex_unlock(&fd_mutex);
+ pthread_mutex_unlock(&dev_mutex);
return r;
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm 6/9] amdgpu: Re-use an existing amdgpu_device when possible
From: Michel Dänzer
It's possible if amdgpu_device's user_fd references the same file
description as the fd passed to amdgpu_device_initialize.
Signed-off-by: Michel Dänzer
---
amdgpu/amdgpu_device.c | 76 +---
amdgpu/amdgpu_internal.h | 3 +-
2 files changed, 58 insertions(+), 21 deletions(-)
diff --git a/amdgpu/amdgpu_device.c b/amdgpu/amdgpu_device.c
index abf5f942..8d9a85c2 100644
--- a/amdgpu/amdgpu_device.c
+++ b/amdgpu/amdgpu_device.c
@@ -28,6 +28,11 @@
*
*/
+#ifdef __linux__
+#include
+#include
+#endif
+
#include
#include
#include
@@ -44,7 +49,7 @@
#define PTR_TO_UINT(x) ((unsigned)((intptr_t)(x)))
static pthread_mutex_t dev_mutex = PTHREAD_MUTEX_INITIALIZER;
-static struct amdgpu_core_device *dev_list;
+static amdgpu_device_handle dev_list;
static int fd_compare(int fd1, int fd2)
{
@@ -67,12 +72,6 @@ static int fd_compare(int fd1, int fd2)
static void amdgpu_device_free(struct amdgpu_core_device *dev)
{
- struct amdgpu_core_device **node = &dev_list;
-
- while (*node != dev && (*node)->next)
- node = &(*node)->next;
- *node = (*node)->next;
-
close(dev->fd);
amdgpu_vamgr_deinit(&dev->vamgr_32);
@@ -86,20 +85,35 @@ static void amdgpu_device_free(struct amdgpu_core_device
*dev)
free(dev);
}
+static bool same_file_description(int fd1, int fd2)
+{
+#ifdef __linux__
+ pid_t pid = getpid();
+
+ return syscall(SYS_kcmp, pid, pid, KCMP_FILE, fd1, fd2) == 0;
+#endif
+
+ /* NOTE: This is never true at this point, since we always duplicate the
+* fd passed to amdgpu_device_initialize
+*/
+ return fd1 == fd2;
+}
+
static int amdgpu_device_init(amdgpu_device_handle user_dev)
{
+ struct amdgpu_device *dev_iter;
struct amdgpu_core_device *dev;
drmVersionPtr version;
uint64_t start, max;
int r;
- for (dev = dev_list; dev; dev = dev->next)
- if (fd_compare(dev->fd, user_dev->user_fd) == 0)
+ for (dev_iter = dev_list; dev_iter; dev_iter = dev_iter->next)
+ if (fd_compare(dev_iter->core->fd, user_dev->user_fd) == 0)
break;
- if (dev) {
- atomic_inc(&dev->refcount);
- user_dev->core = dev;
+ if (dev_iter) {
+ atomic_inc(&dev_iter->core->refcount);
+ user_dev->core = dev_iter->core;
return 0;
}
@@ -115,9 +129,6 @@ static int amdgpu_device_init(amdgpu_device_handle user_dev)
dev->fd = user_dev->user_fd;
user_dev->core = dev;
- dev->next = dev_list;
- dev_list = dev;
-
version = drmGetVersion(dev->fd);
if (version->version_major != 3) {
fprintf(stderr, "%s: DRM version is %d.%d.%d but this driver is
"
@@ -184,6 +195,17 @@ drm_public int amdgpu_device_initialize(int fd,
*device_handle = NULL;
+ pthread_mutex_lock(&dev_mutex);
+
+ for (user_dev = dev_list; user_dev; user_dev = user_dev->next) {
+ if (same_file_description(user_dev->user_fd, fd)) {
+ atomic_inc(&user_dev->refcount);
+ goto out;
+ }
+ }
+
+ pthread_mutex_unlock(&dev_mutex);
+
user_dev = calloc(1, sizeof(struct amdgpu_device));
if (!user_dev) {
fprintf(stderr, "%s: calloc failed\n", __func__);
@@ -211,6 +233,11 @@ drm_public int amdgpu_device_initialize(int fd,
goto cleanup;
}
+ atomic_set(&user_dev->refcount, 1);
+ user_dev->next = dev_list;
+ dev_list = user_dev;
+
+out:
*major_version = user_dev->core->major_version;
*minor_version = user_dev->core->minor_version;
*device_handle = user_dev;
@@ -234,14 +261,23 @@ drm_public int
amdgpu_device_deinitialize(amdgpu_device_handle user_dev)
pthread_mutex_lock(&dev_mutex);
- if (user_dev->user_fd != dev->fd)
- close(user_dev->user_fd);
+ if (update_references(&user_dev->refcount, NULL)) {
+ struct amdgpu_device **node = &dev_list;
- if (update_references(&dev->refcount, NULL))
- amdgpu_device_free(dev);
+ while (*node != user_dev && (*node)->next)
+ node = &(*node)->next;
+ *node = (*node)->next;
+
+ if (user_dev->user_fd != dev->fd)
+ close(user_dev->user_fd);
+
+ if (update_references(&dev->refcount, NULL))
+ amdgpu_device_free(dev);
+
+ free(user_dev);
+ }
pthread_mutex_unlock(&dev_mutex);
- free(user_dev);
return 0;
}
diff --git a/amdgpu/amdgpu_internal.h b/amdgpu/amdgpu_internal.h
index a08a4ae8..686d50ec 100644
--- a/amdgpu/amdgpu_internal.h
+++ b/amdgpu/amdgpu_internal.h
@@ -70,7 +70,6 @@ struct amdgpu_core_device {
unsigned
[PATCH mesa 9/9] winsys/amdgpu: Use amdgpu_bo_handle_type_kms_user for API KMS handles
From: Michel Dänzer Gallium API callers expect the returned handles to be valid for the DRM file descriptor passed to the driver during initialization, which may not be the case with amdgpu_bo_handle_type_kms. Bugzilla: https://bugs.freedesktop.org/110903 Signed-off-by: Michel Dänzer --- src/gallium/winsys/amdgpu/drm/amdgpu_bo.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c b/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c index 37098ab305f..d4f7e1c7a95 100644 --- a/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c +++ b/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c @@ -1544,7 +1544,7 @@ static bool amdgpu_bo_get_handle(struct pb_buffer *buffer, type = amdgpu_bo_handle_type_dma_buf_fd; break; case WINSYS_HANDLE_TYPE_KMS: - type = amdgpu_bo_handle_type_kms; + type = amdgpu_bo_handle_type_kms_user; break; default: return false; -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm 5/9] amdgpu: Add amdgpu_bo_handle_type_kms_user
From: Michel Dänzer
amdgpu_bo_handle_type_kms returns the handle valid for the DRM file
descriptor (fd) used for CS submission etc. This is also valid for the
fd passed to amdgpu_device_initialize the first time for a specific
GPU, but in general not for fds passed to amdgpu_device_initialize
later for the same GPU.
Because some use-cases require a handle valid for the fd passed to
amdgpu_device_initialize, amdgpu_bo_handle_type_kms_user is added for
this purpose.
Signed-off-by: Michel Dänzer
---
amdgpu/amdgpu.h | 14 -
amdgpu/amdgpu_bo.c | 65 +++-
amdgpu/amdgpu_internal.h | 1 +
3 files changed, 59 insertions(+), 21 deletions(-)
diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
index 66e45f73..f95c0a36 100644
--- a/amdgpu/amdgpu.h
+++ b/amdgpu/amdgpu.h
@@ -81,7 +81,14 @@ enum amdgpu_bo_handle_type {
/** GEM flink name (needs DRM authentication, used by DRI2) */
amdgpu_bo_handle_type_gem_flink_name = 0,
- /** KMS handle which is used by all driver ioctls */
+ /** KMS handle which is used by all driver ioctls
+*
+* NOTE: The returned handle is valid for the DRM file description
+* used for command submission, which may be different from the one
+* referenced by the file descriptor passed to
+* amdgpu_device_initialize. Use amdgpu_bo_handle_type_kms_user to
+* get a handle valid for the latter.
+*/
amdgpu_bo_handle_type_kms = 1,
/** DMA-buf fd handle */
@@ -91,6 +98,11 @@ enum amdgpu_bo_handle_type {
* amdgpu_bo_handle_type_kms, use that instead of this
*/
amdgpu_bo_handle_type_kms_noimport = 3,
+
+ /** KMS handle valid for the DRM file description referenced by the
+* file descriptor passed to amdgpu_device_initialize.
+*/
+ amdgpu_bo_handle_type_kms_user = 4,
};
/** Define known types of GPU VM VA ranges */
diff --git a/amdgpu/amdgpu_bo.c b/amdgpu/amdgpu_bo.c
index 7fec1f15..8d42db90 100644
--- a/amdgpu/amdgpu_bo.c
+++ b/amdgpu/amdgpu_bo.c
@@ -229,42 +229,58 @@ drm_public int amdgpu_bo_query_info(amdgpu_bo_handle
user_bo,
return 0;
}
+static int amdgpu_bo_get_user_handle(struct amdgpu_bo *user_bo,
+uint32_t *user_handle)
+{
+ struct amdgpu_device *user_dev = user_bo->dev;
+ struct amdgpu_core_device *dev = user_dev->core;
+ struct amdgpu_core_bo *bo = user_bo->core;
+ int dma_fd;
+ int r;
+
+ if (user_dev->user_fd == dev->fd) {
+ *user_handle = bo->handle;
+ return 0;
+ }
+
+ if (user_bo->user_handle)
+ goto out;
+
+ r = drmPrimeHandleToFD(dev->fd, bo->handle, DRM_CLOEXEC, &dma_fd);
+ if (r)
+ return r;
+
+ r = drmPrimeFDToHandle(user_dev->user_fd, dma_fd,
&user_bo->user_handle);
+ close(dma_fd);
+ if (r)
+ return r;
+
+out:
+ *user_handle = user_bo->user_handle;
+ return 0;
+}
+
static int amdgpu_bo_export_flink(amdgpu_bo_handle user_bo)
{
struct amdgpu_core_device *dev = user_bo->dev->core;
struct amdgpu_core_bo *bo = user_bo->core;
- int user_fd = user_bo->dev->user_fd;
struct drm_gem_flink flink;
- int fd, dma_fd;
- uint32_t handle;
int r;
- fd = dev->fd;
- handle = bo->handle;
if (bo->flink_name)
return 0;
- if (user_fd != fd) {
- r = drmPrimeHandleToFD(fd, bo->handle, DRM_CLOEXEC, &dma_fd);
- if (!r) {
- r = drmPrimeFDToHandle(user_fd, dma_fd, &handle);
- close(dma_fd);
- }
- if (r)
- return r;
- fd = user_fd;
- }
memset(&flink, 0, sizeof(flink));
- flink.handle = handle;
- r = drmIoctl(fd, DRM_IOCTL_GEM_FLINK, &flink);
+ r = amdgpu_bo_get_user_handle(user_bo, &flink.handle);
if (r)
return r;
- bo->flink_name = flink.name;
+ r = drmIoctl(user_bo->dev->user_fd, DRM_IOCTL_GEM_FLINK, &flink);
+ if (r)
+ return r;
- if (user_fd != dev->fd)
- amdgpu_close_kms_handle(user_fd, handle);
+ bo->flink_name = flink.name;
pthread_mutex_lock(&dev->bo_table_mutex);
r = handle_table_insert(&dev->bo_flink_names, bo->flink_name, bo);
@@ -294,6 +310,9 @@ drm_public int amdgpu_bo_export(amdgpu_bo_handle user_bo,
*shared_handle = bo->handle;
return 0;
+ case amdgpu_bo_handle_type_kms_user:
+ return amdgpu_bo_get_user_handle(user_bo, shared_handle);
+
case amdgpu_bo_handle_type_dma_buf_fd:
return drmPrimeHandleToFD(user_bo->dev->core->fd, bo->handle,
DRM_CLOEXEC | DRM_RDWR,
@@ -355,6 +374,7 @@ drm_public int amd
[PATCH libdrm 8/9] amdgpu: Drop refcount member from struct amdgpu_core_bo/device
From: Michel Dänzer
We can just walk the lists of struct amdgpu_bo/device to find out if
there are any references left.
Signed-off-by: Michel Dänzer
---
amdgpu/amdgpu_bo.c | 14 +++---
amdgpu/amdgpu_device.c | 30 ++
amdgpu/amdgpu_internal.h | 2 --
3 files changed, 33 insertions(+), 13 deletions(-)
diff --git a/amdgpu/amdgpu_bo.c b/amdgpu/amdgpu_bo.c
index f40df484..332ce4be 100644
--- a/amdgpu/amdgpu_bo.c
+++ b/amdgpu/amdgpu_bo.c
@@ -65,7 +65,6 @@ static int amdgpu_core_bo_create(struct amdgpu_core_device
*dev,
return r;
}
- bo->refcount = 1;
bo->alloc_size = size;
bo->handle = handle;
pthread_mutex_init(&bo->cpu_access_mutex, NULL);
@@ -95,7 +94,6 @@ static int amdgpu_bo_create(amdgpu_device_handle user_dev,
goto out;
}
}
- bo->refcount++;
} else {
r = amdgpu_core_bo_create(dev, size, handle, &bo);
if (r)
@@ -466,8 +464,18 @@ static void amdgpu_core_bo_free(struct amdgpu_bo *user_bo)
{
struct amdgpu_core_device *dev = user_bo->dev->core;
struct amdgpu_core_bo *bo = user_bo->core;
+ struct amdgpu_bo *iter_bo;
- if (--bo->refcount == 0) {
+ /* Are there any other user BOs left referencing the same core BO? */
+ for (iter_bo = bo->user_bos; iter_bo; iter_bo = iter_bo->next) {
+ if (iter_bo == user_bo)
+ continue;
+
+ if (iter_bo->core == bo)
+ break;
+ }
+
+ if (!iter_bo) {
/* Remove the buffer from the hash tables. */
handle_table_remove(&dev->bo_handles, bo->handle);
diff --git a/amdgpu/amdgpu_device.c b/amdgpu/amdgpu_device.c
index 8a99b8bb..1709099e 100644
--- a/amdgpu/amdgpu_device.c
+++ b/amdgpu/amdgpu_device.c
@@ -72,9 +72,6 @@ static int fd_compare(int fd1, int fd2)
static void amdgpu_device_free(struct amdgpu_core_device *dev)
{
- if (--dev->refcount > 0)
- return;
-
close(dev->fd);
amdgpu_vamgr_deinit(&dev->vamgr_32);
@@ -102,6 +99,26 @@ static bool same_file_description(int fd1, int fd2)
return fd1 == fd2;
}
+static void amdgpu_device_unreference(amdgpu_device_handle user_dev)
+{
+ struct amdgpu_device *dev;
+
+ if (!user_dev->core)
+ return;
+
+ /* Are there any other user devices left referencing the core device? */
+ for (dev = dev_list; dev; dev = dev->next) {
+ if (dev == user_dev)
+ continue;
+
+ if (dev->core == user_dev->core)
+ break;
+ }
+
+ if (!dev)
+ amdgpu_device_free(user_dev->core);
+}
+
static int amdgpu_device_init(amdgpu_device_handle user_dev)
{
struct amdgpu_device *dev_iter;
@@ -115,7 +132,6 @@ static int amdgpu_device_init(amdgpu_device_handle user_dev)
break;
if (dev_iter) {
- dev_iter->core->refcount++;
user_dev->core = dev_iter->core;
return 0;
}
@@ -126,7 +142,6 @@ static int amdgpu_device_init(amdgpu_device_handle user_dev)
return -ENOMEM;
}
- dev->refcount = 1;
pthread_mutex_init(&dev->bo_table_mutex, NULL);
dev->fd = user_dev->user_fd;
@@ -251,8 +266,7 @@ out:
cleanup:
if (!user_dev->core || user_dev->user_fd != user_dev->core->fd)
close(user_dev->user_fd);
- if (user_dev->core)
- amdgpu_device_free(user_dev->core);
+ amdgpu_device_unreference(user_dev);
free(user_dev);
pthread_mutex_unlock(&dev_mutex);
return r;
@@ -274,7 +288,7 @@ drm_public int
amdgpu_device_deinitialize(amdgpu_device_handle user_dev)
if (user_dev->user_fd != dev->fd)
close(user_dev->user_fd);
- amdgpu_device_free(dev);
+ amdgpu_device_unreference(user_dev);
free(user_dev);
}
diff --git a/amdgpu/amdgpu_internal.h b/amdgpu/amdgpu_internal.h
index 70566f98..7110e30c 100644
--- a/amdgpu/amdgpu_internal.h
+++ b/amdgpu/amdgpu_internal.h
@@ -65,7 +65,6 @@ struct amdgpu_va {
};
struct amdgpu_core_device {
- int refcount;
int fd;
unsigned major_version;
unsigned minor_version;
@@ -97,7 +96,6 @@ struct amdgpu_device {
};
struct amdgpu_core_bo {
- int refcount;
amdgpu_bo_handle user_bos;
uint64_t alloc_size;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm 0/9] amdgpu:
From: Michel Dänzer The motivation for these patches is https://bugs.freedesktop.org/110903 . Patches 1-3 are preparatory. Patches 4 & 5 are the core patches allowing the issues discussed in the bug report to be fixed. Patches 6-8 are further optimizations / cleanups. Patch 9 is the Mesa patch making use of the new amdgpu_bo_handle_type_kms_user API to fix the user visible problem. Note that the libdrm patches need to land first, a libdrm release needs to be made, and the Mesa patch needs to bump the libdrm_amdgpu version requirement to that release's version before it can land. Michel Dänzer (9): amdgpu: Pass file descriptor directly to amdgpu_close_kms_handle amdgpu: Add BO handle to table in amdgpu_bo_create amdgpu: Rename fd_mutex/list to dev_mutex/list amdgpu: Add struct amdgpu_core_device and amdgpu_core_bo amdgpu: Add amdgpu_bo_handle_type_kms_user amdgpu: Re-use an existing amdgpu_device when possible amdgpu: Use normal integers for device / core BO reference counting amdgpu: Drop refcount member from struct amdgpu_core_bo/device winsys/amdgpu: Use amdgpu_bo_handle_type_kms_user for API KMS handles amdgpu/amdgpu.h | 14 +- amdgpu/amdgpu_asic_id.c | 4 +- amdgpu/amdgpu_bo.c| 367 ++ amdgpu/amdgpu_cs.c| 64 +++--- amdgpu/amdgpu_device.c| 281 +- amdgpu/amdgpu_gpu_info.c | 35 ++-- amdgpu/amdgpu_internal.h | 31 ++- amdgpu/amdgpu_vamgr.c | 9 +- amdgpu/amdgpu_vm.c| 4 +- tests/amdgpu/amdgpu_test.c| 2 +- tests/amdgpu/bo_tests.c | 2 +- tests/amdgpu/cs_tests.c | 8 +- tests/amdgpu/deadlock_tests.c | 8 +- tests/amdgpu/uvd_enc_tests.c | 2 +- tests/amdgpu/vce_tests.c | 12 +- tests/amdgpu/vcn_tests.c | 4 +- tests/amdgpu/vm_tests.c | 2 +- 17 files changed, 500 insertions(+), 349 deletions(-) -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC][PATCH] wake_up_var() memory ordering
Hi all,
I tried using wake_up_var() today and accidentally noticed that it
didn't imply an smp_mb() and specifically requires it through
wake_up_bit() / waitqueue_active().
Now, wake_up_bit() doesn't imply the barrier because it is assumed to be
used with the atomic bitops API which either implies (test_and_clear) or
only needs smp_mb__after_atomic(), which is 'much' cheaper than an
unconditional smp_mb().
Still, while auditing all that, I found a whole bunch of things that
could be improved. There were missing barriers, superfluous barriers and
a whole bunch of sites that could use clear_and_wake_up_bit().
So this fixes all wake_up_bit() usage without actually changing
semantics of it (which are unfortunate but understandable). This does
however change the semantics of wake_up_var(); even though wake_up_var()
is most often used with atomics and then the additional smp_mb() is most
often superfluous :/
There isn't really a good option here, comments (other than I need to
split this up)?
---
drivers/bluetooth/btmtksdio.c | 5 +
drivers/bluetooth/btmtkuart.c | 5 +
drivers/bluetooth/hci_mrvl.c| 8 ++--
drivers/gpu/drm/i915/i915_reset.c | 6 ++
drivers/md/dm-bufio.c | 10 ++
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c | 15 ---
fs/afs/fs_probe.c | 1 +
fs/afs/server.c | 1 +
fs/afs/vl_probe.c | 1 +
fs/afs/volume.c | 1 +
fs/aio.c| 4 +---
fs/block_dev.c | 1 +
fs/btrfs/extent_io.c| 4 +---
fs/cachefiles/namei.c | 1 +
fs/cifs/connect.c | 3 +--
fs/cifs/misc.c | 15 +--
fs/fscache/cookie.c | 2 ++
fs/fscache/object.c | 2 ++
fs/fscache/page.c | 3 +++
fs/gfs2/glock.c | 8 ++--
fs/gfs2/glops.c | 1 +
fs/gfs2/lock_dlm.c | 8 ++--
fs/gfs2/recovery.c | 4 +---
fs/gfs2/super.c | 1 +
fs/gfs2/sys.c | 4 +---
fs/nfs/nfs4state.c | 4 +---
fs/nfs/pnfs_nfs.c | 4 +---
fs/nfsd/nfs4recover.c | 4 +---
fs/orangefs/file.c | 2 +-
kernel/sched/wait_bit.c | 1 +
net/bluetooth/hci_event.c | 5 +
net/rds/ib_recv.c | 1 +
security/keys/gc.c | 5 ++---
33 files changed, 50 insertions(+), 90 deletions(-)
diff --git a/drivers/bluetooth/btmtksdio.c b/drivers/bluetooth/btmtksdio.c
index 813338288453..27523cfeac9a 100644
--- a/drivers/bluetooth/btmtksdio.c
+++ b/drivers/bluetooth/btmtksdio.c
@@ -356,11 +356,8 @@ static int btmtksdio_recv_event(struct hci_dev *hdev,
struct sk_buff *skb)
if (hdr->evt == HCI_EV_VENDOR) {
if (test_and_clear_bit(BTMTKSDIO_TX_WAIT_VND_EVT,
- &bdev->tx_state)) {
- /* Barrier to sync with other CPUs */
- smp_mb__after_atomic();
+ &bdev->tx_state))
wake_up_bit(&bdev->tx_state, BTMTKSDIO_TX_WAIT_VND_EVT);
- }
}
return 0;
diff --git a/drivers/bluetooth/btmtkuart.c b/drivers/bluetooth/btmtkuart.c
index f5dbeec8e274..7fe324df3799 100644
--- a/drivers/bluetooth/btmtkuart.c
+++ b/drivers/bluetooth/btmtkuart.c
@@ -340,11 +340,8 @@ static int btmtkuart_recv_event(struct hci_dev *hdev,
struct sk_buff *skb)
if (hdr->evt == HCI_EV_VENDOR) {
if (test_and_clear_bit(BTMTKUART_TX_WAIT_VND_EVT,
- &bdev->tx_state)) {
- /* Barrier to sync with other CPUs */
- smp_mb__after_atomic();
+ &bdev->tx_state))
wake_up_bit(&bdev->tx_state, BTMTKUART_TX_WAIT_VND_EVT);
- }
}
return 0;
diff --git a/drivers/bluetooth/hci_mrvl.c b/drivers/bluetooth/hci_mrvl.c
index 50212ac629e3..f03294d39d08 100644
--- a/drivers/bluetooth/hci_mrvl.c
+++ b/drivers/bluetooth/hci_mrvl.c
@@ -157,9 +157,7 @@ static int mrvl_recv_fw_req(struct hci_dev *hdev, struct
sk_buff *skb)
mrvl->tx_len = le16_to_cpu(pkt->lhs);
- clear_bit(STATE_FW_REQ_PENDING, &mrvl->flags);
- smp_mb__after_atomic();
- wake_up_bit(&mrvl->flags, STATE_FW_REQ_PENDING);
+ clear_and_wake_up_bit(STATE_FW_REQ_PENDING, &mrvl->flags);
done:
kfree_skb(skb);
@@ -192,9 +190,7 @@ static int mrvl_recv_chi
Re: [PATCH] drm/msm/a3xx: remove TPL1 regs from snapshot
On Mon, Jun 24, 2019 at 09:19:54AM -0700, Rob Clark wrote:
> From: Rob Clark
>
> These regs are write-only, and the hw throws a hissy-fit (ie. reboots)
> when we try to read them for GPU state snapshot, in response to a GPU
> hang. It is rather impolite when GPU recovery triggers an insta-
> reboot, so lets remove the TPL1 registers from the snapshot.
Not to mention that write only registers are incredibly uninteresting for a
snapshot :)
Reviewed-by: Jordan Crouse
> Fixes: 7198e6b03155 drm/msm: add a3xx gpu support
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 24 +++-
> 1 file changed, 11 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
> b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
> index c3b4bc6e4155..13078c4975ff 100644
> --- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
> @@ -395,19 +395,17 @@ static const unsigned int a3xx_registers[] = {
> 0x2200, 0x2212, 0x2214, 0x2217, 0x221a, 0x221a, 0x2240, 0x227e,
> 0x2280, 0x228b, 0x22c0, 0x22c0, 0x22c4, 0x22ce, 0x22d0, 0x22d8,
> 0x22df, 0x22e6, 0x22e8, 0x22e9, 0x22ec, 0x22ec, 0x22f0, 0x22f7,
> - 0x22ff, 0x22ff, 0x2340, 0x2343, 0x2348, 0x2349, 0x2350, 0x2356,
> - 0x2360, 0x2360, 0x2440, 0x2440, 0x2444, 0x2444, 0x2448, 0x244d,
> - 0x2468, 0x2469, 0x246c, 0x246d, 0x2470, 0x2470, 0x2472, 0x2472,
> - 0x2474, 0x2475, 0x2479, 0x247a, 0x24c0, 0x24d3, 0x24e4, 0x24ef,
> - 0x2500, 0x2509, 0x250c, 0x250c, 0x250e, 0x250e, 0x2510, 0x2511,
> - 0x2514, 0x2515, 0x25e4, 0x25e4, 0x25ea, 0x25ea, 0x25ec, 0x25ed,
> - 0x25f0, 0x25f0, 0x2600, 0x2612, 0x2614, 0x2617, 0x261a, 0x261a,
> - 0x2640, 0x267e, 0x2680, 0x268b, 0x26c0, 0x26c0, 0x26c4, 0x26ce,
> - 0x26d0, 0x26d8, 0x26df, 0x26e6, 0x26e8, 0x26e9, 0x26ec, 0x26ec,
> - 0x26f0, 0x26f7, 0x26ff, 0x26ff, 0x2740, 0x2743, 0x2748, 0x2749,
> - 0x2750, 0x2756, 0x2760, 0x2760, 0x300c, 0x300e, 0x301c, 0x301d,
> - 0x302a, 0x302a, 0x302c, 0x302d, 0x3030, 0x3031, 0x3034, 0x3036,
> - 0x303c, 0x303c, 0x305e, 0x305f,
> + 0x22ff, 0x22ff, 0x2340, 0x2343, 0x2440, 0x2440, 0x2444, 0x2444,
> + 0x2448, 0x244d, 0x2468, 0x2469, 0x246c, 0x246d, 0x2470, 0x2470,
> + 0x2472, 0x2472, 0x2474, 0x2475, 0x2479, 0x247a, 0x24c0, 0x24d3,
> + 0x24e4, 0x24ef, 0x2500, 0x2509, 0x250c, 0x250c, 0x250e, 0x250e,
> + 0x2510, 0x2511, 0x2514, 0x2515, 0x25e4, 0x25e4, 0x25ea, 0x25ea,
> + 0x25ec, 0x25ed, 0x25f0, 0x25f0, 0x2600, 0x2612, 0x2614, 0x2617,
> + 0x261a, 0x261a, 0x2640, 0x267e, 0x2680, 0x268b, 0x26c0, 0x26c0,
> + 0x26c4, 0x26ce, 0x26d0, 0x26d8, 0x26df, 0x26e6, 0x26e8, 0x26e9,
> + 0x26ec, 0x26ec, 0x26f0, 0x26f7, 0x26ff, 0x26ff, 0x2740, 0x2743,
> + 0x300c, 0x300e, 0x301c, 0x301d, 0x302a, 0x302a, 0x302c, 0x302d,
> + 0x3030, 0x3031, 0x3034, 0x3036, 0x303c, 0x303c, 0x305e, 0x305f,
> ~0 /* sentinel */
> };
>
> --
> 2.20.1
>
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH] drm/msm/a3xx: remove TPL1 regs from snapshot
From: Rob Clark
These regs are write-only, and the hw throws a hissy-fit (ie. reboots)
when we try to read them for GPU state snapshot, in response to a GPU
hang. It is rather impolite when GPU recovery triggers an insta-
reboot, so lets remove the TPL1 registers from the snapshot.
Fixes: 7198e6b03155 drm/msm: add a3xx gpu support
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 24 +++-
1 file changed, 11 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index c3b4bc6e4155..13078c4975ff 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -395,19 +395,17 @@ static const unsigned int a3xx_registers[] = {
0x2200, 0x2212, 0x2214, 0x2217, 0x221a, 0x221a, 0x2240, 0x227e,
0x2280, 0x228b, 0x22c0, 0x22c0, 0x22c4, 0x22ce, 0x22d0, 0x22d8,
0x22df, 0x22e6, 0x22e8, 0x22e9, 0x22ec, 0x22ec, 0x22f0, 0x22f7,
- 0x22ff, 0x22ff, 0x2340, 0x2343, 0x2348, 0x2349, 0x2350, 0x2356,
- 0x2360, 0x2360, 0x2440, 0x2440, 0x2444, 0x2444, 0x2448, 0x244d,
- 0x2468, 0x2469, 0x246c, 0x246d, 0x2470, 0x2470, 0x2472, 0x2472,
- 0x2474, 0x2475, 0x2479, 0x247a, 0x24c0, 0x24d3, 0x24e4, 0x24ef,
- 0x2500, 0x2509, 0x250c, 0x250c, 0x250e, 0x250e, 0x2510, 0x2511,
- 0x2514, 0x2515, 0x25e4, 0x25e4, 0x25ea, 0x25ea, 0x25ec, 0x25ed,
- 0x25f0, 0x25f0, 0x2600, 0x2612, 0x2614, 0x2617, 0x261a, 0x261a,
- 0x2640, 0x267e, 0x2680, 0x268b, 0x26c0, 0x26c0, 0x26c4, 0x26ce,
- 0x26d0, 0x26d8, 0x26df, 0x26e6, 0x26e8, 0x26e9, 0x26ec, 0x26ec,
- 0x26f0, 0x26f7, 0x26ff, 0x26ff, 0x2740, 0x2743, 0x2748, 0x2749,
- 0x2750, 0x2756, 0x2760, 0x2760, 0x300c, 0x300e, 0x301c, 0x301d,
- 0x302a, 0x302a, 0x302c, 0x302d, 0x3030, 0x3031, 0x3034, 0x3036,
- 0x303c, 0x303c, 0x305e, 0x305f,
+ 0x22ff, 0x22ff, 0x2340, 0x2343, 0x2440, 0x2440, 0x2444, 0x2444,
+ 0x2448, 0x244d, 0x2468, 0x2469, 0x246c, 0x246d, 0x2470, 0x2470,
+ 0x2472, 0x2472, 0x2474, 0x2475, 0x2479, 0x247a, 0x24c0, 0x24d3,
+ 0x24e4, 0x24ef, 0x2500, 0x2509, 0x250c, 0x250c, 0x250e, 0x250e,
+ 0x2510, 0x2511, 0x2514, 0x2515, 0x25e4, 0x25e4, 0x25ea, 0x25ea,
+ 0x25ec, 0x25ed, 0x25f0, 0x25f0, 0x2600, 0x2612, 0x2614, 0x2617,
+ 0x261a, 0x261a, 0x2640, 0x267e, 0x2680, 0x268b, 0x26c0, 0x26c0,
+ 0x26c4, 0x26ce, 0x26d0, 0x26d8, 0x26df, 0x26e6, 0x26e8, 0x26e9,
+ 0x26ec, 0x26ec, 0x26f0, 0x26f7, 0x26ff, 0x26ff, 0x2740, 0x2743,
+ 0x300c, 0x300e, 0x301c, 0x301d, 0x302a, 0x302a, 0x302c, 0x302d,
+ 0x3030, 0x3031, 0x3034, 0x3036, 0x303c, 0x303c, 0x305e, 0x305f,
~0 /* sentinel */
};
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vmwgfx: fix memory leak when too many retries have occurred
On 24/06/2019 17:10, Deepak Singh Rawat wrote:
> Hi Colin,
>
> Thanks for doing this.
>
> Reviewed-by: Deepak Rawat
>
> Do you want me to include this in vmwgfx-next or will you submit this
> via drm-mics?
Can you include it into vmwgfx-next?
Thanks
Colin
>
> On Fri, 2019-06-21 at 23:35 +0100, Colin King wrote:
>> From: Colin Ian King
>>
>> Currently when too many retries have occurred there is a memory
>> leak on the allocation for reply on the error return path. Fix
>> this by kfree'ing reply before returning.
>>
>> Addresses-Coverity: ("Resource leak")
>> Fixes: a9cd9c044aa9 ("drm/vmwgfx: Add a check to handle host message
>> failure")
>> Signed-off-by: Colin Ian King
>> ---
>> drivers/gpu/drm/vmwgfx/vmwgfx_msg.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
>> b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
>> index 8b9270f31409..8b61f16f50cf 100644
>> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
>> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
>> @@ -301,8 +301,10 @@ static int vmw_recv_msg(struct rpc_channel
>> *channel, void **msg,
>> break;
>> }
>>
>> -if (retries == RETRIES)
>> +if (retries == RETRIES) {
>> +kfree(reply);
>> return -EINVAL;
>> +}
>>
>> *msg_len = reply_len;
>> *msg = reply;
>
Re: [EXT] Re: [PATCH v3 2/2] drm/panel: Add support for Raydium RM67191 panel driver
Hi Robert, On Mon, Jun 24, 2019 at 4:44 AM Robert Chiras wrote: > > You did not handle the "power" regulator. > There is no need for a power regulator. I am sure the panel requires power to be applied so that it can work :-) > > Can't you simply remove them? > The reset gpio pin is shared between the DSI display controller and Looking at the imx8mq-evk schematics it is not clear for me what pin in shared between the OLED display and touch screen. Could you please clarify which pin you are referring to? > touch controller, both found on the same panel. Since, the touch driver > also acceses this gpio pin, in some cases the display can be put to > sleep, but the touch is still active. This is why, during suspend I > release the gpio resource, and I have to take it back in resume. > Without this release/acquire mechanism during suspend/resume, stress- > tests showed some failures: the resume freezes completly. Looking at the imx8mq-evk dts from the vendor tree I see that the touchscreen is not supported in mainline yet. Maybe there is a better way to solve this, so what if you don't introduce the suspend/resume hooks for now and then we revisit this after the touchscreen driver is added?
Re: [PATCH] drm/vmwgfx: fix memory leak when too many retries have occurred
Hi Colin,
Thanks for doing this.
Reviewed-by: Deepak Rawat
Do you want me to include this in vmwgfx-next or will you submit this
via drm-mics?
On Fri, 2019-06-21 at 23:35 +0100, Colin King wrote:
> From: Colin Ian King
>
> Currently when too many retries have occurred there is a memory
> leak on the allocation for reply on the error return path. Fix
> this by kfree'ing reply before returning.
>
> Addresses-Coverity: ("Resource leak")
> Fixes: a9cd9c044aa9 ("drm/vmwgfx: Add a check to handle host message
> failure")
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_msg.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
> index 8b9270f31409..8b61f16f50cf 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
> @@ -301,8 +301,10 @@ static int vmw_recv_msg(struct rpc_channel
> *channel, void **msg,
> break;
> }
>
> - if (retries == RETRIES)
> + if (retries == RETRIES) {
> + kfree(reply);
> return -EINVAL;
> + }
>
> *msg_len = reply_len;
> *msg = reply;
Re: [PATCH 4/4] drm/sun4i: Enable DRM InfoFrame support on H6
On Tue, Jun 25, 2019 at 12:03 AM Jernej Škrabec wrote:
>
> Dne ponedeljek, 24. junij 2019 ob 17:56:30 CEST je Chen-Yu Tsai napisal(a):
> > On Mon, Jun 24, 2019 at 11:49 PM Andrzej Hajda wrote:
> > > On 24.06.2019 17:05, Jernej Škrabec wrote:
> > > > Dne ponedeljek, 24. junij 2019 ob 17:03:31 CEST je Andrzej Hajda
> napisal(a):
> > > >> On 26.05.2019 23:20, Jonas Karlman wrote:
> > > >>> This patch enables Dynamic Range and Mastering InfoFrame on H6.
> > > >>>
> > > >>> Cc: Maxime Ripard
> > > >>> Cc: Jernej Skrabec
> > > >>> Signed-off-by: Jonas Karlman
> > > >>> ---
> > > >>>
> > > >>> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 2 ++
> > > >>> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 1 +
> > > >>> 2 files changed, 3 insertions(+)
> > > >>>
> > > >>> diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
> > > >>> b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c index
> > > >>> 39d8509d96a0..b80164dd8ad8
> > > >>> 100644
> > > >>> --- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
> > > >>> +++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
> > > >>> @@ -189,6 +189,7 @@ static int sun8i_dw_hdmi_bind(struct device *dev,
> > > >>> struct device *master,>
> > > >>>
> > > >>> sun8i_hdmi_phy_init(hdmi->phy);
> > > >>>
> > > >>> plat_data->mode_valid = hdmi->quirks->mode_valid;
> > > >>>
> > > >>> + plat_data->drm_infoframe = hdmi->quirks->drm_infoframe;
> > > >>>
> > > >>> sun8i_hdmi_phy_set_ops(hdmi->phy, plat_data);
> > > >>>
> > > >>> platform_set_drvdata(pdev, hdmi);
> > > >>>
> > > >>> @@ -255,6 +256,7 @@ static const struct sun8i_dw_hdmi_quirks
> > > >>> sun8i_a83t_quirks = {>
> > > >>>
> > > >>> static const struct sun8i_dw_hdmi_quirks sun50i_h6_quirks = {
> > > >>>
> > > >>> .mode_valid = sun8i_dw_hdmi_mode_valid_h6,
> > > >>>
> > > >>> + .drm_infoframe = true,
> > > >>>
> > > >>> };
> > > >>>
> > > >>> static const struct of_device_id sun8i_dw_hdmi_dt_ids[] = {
> > > >>>
> > > >>> diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
> > > >>> b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h index
> > > >>> 720c5aa8adc1..2a0ec08ee236
> > > >>> 100644
> > > >>> --- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
> > > >>> +++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
> > > >>> @@ -178,6 +178,7 @@ struct sun8i_dw_hdmi_quirks {
> > > >>>
> > > >>> enum drm_mode_status (*mode_valid)(struct drm_connector
> > > >
> > > > *connector,
> > > >
> > > >>>const struct
> > > >
> > > > drm_display_mode *mode);
> > > >
> > > >>> unsigned int set_rate : 1;
> > > >>>
> > > >>> + unsigned int drm_infoframe : 1;
> > > >>
> > > >> Again, drm_infoframe suggests it contains inforframe, but in fact it
> > > >> just informs infoframe can be used, so again my suggestion
> > > >> use_drm_infoframe.
> > > >>
> > > >> Moreover bool type seems more appropriate here.
> > > >
> > > > checkpatch will give warning if bool is used.
> > >
> > > Then I would say "fix/ignore checkpatch" :)
> > >
> > > But maybe there is a reason.
> >
> > Here's an old one from Linus: https://lkml.org/lkml/2013/9/1/154
> >
> > I'd say that bool in a struct is a waste of space compared to a 1 bit
> > bitfield, especially when there already are other bitfields in the same
> > struct.
> > > Anyway I've tested and I do not see the warning, could you elaborate it.
> >
> > Maybe checkpatch.pl --strict?
>
> It seems they removed that check:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?
> id=7967656ffbfa493f5546c0f1
>
> After reading that block of text, I'm not sure what would be prefered way for
> this case.
This:
+If a structure has many true/false values, consider consolidating them into a
+bitfield with 1 bit members, or using an appropriate fixed width type, such as
+u8.
would suggest using a bitfield, or flags within a fixed width type?
ChenYu
Re: [PATCH] backlight: pwm_bl: Set pin to sleep state when powered down
Le lun. 24 juin 2019 à 17:46, Daniel Thompson a écrit : On Mon, Jun 24, 2019 at 04:31:57PM +0200, Paul Cercueil wrote: Le lun. 24 juin 2019 à 13:28, Daniel Thompson a écrit : > On Fri, Jun 21, 2019 at 03:56:08PM +0200, Thierry Reding wrote: > > On Fri, Jun 21, 2019 at 01:41:45PM +0100, Daniel Thompson wrote: > > > On 22/05/2019 17:34, Paul Cercueil wrote: > > > > When the driver probes, the PWM pin is automatically configured > > to its > > > > default state, which should be the "pwm" function. > > > > > > At which point in the probe... and by who? > > > > The driver core will select the "default" state of a device right > > before > > calling the driver's probe, see: > > > > drivers/base/pinctrl.c: pinctrl_bind_pins() > > > > which is called from: > > > > drivers/base/dd.c: really_probe() > > > > Thanks. I assumed it would be something like that... although given > pwm-backlight is essentially a wrapper driver round a PWM I wondered why > the pinctrl was on the backlight node (rather than the PWM node). > > Looking at the DTs in the upstream kernel it looks like ~20% of the > backlight drivers have pinctrl on the backlight node. Others presumable > have none or have it on the PWM node (and it looks like support for > sleeping the pins is *very* rare amoung the PWM drivers). If your PWM driver has more than one channel and has the pinctrl node, you cannot fine-tune the state of individual pins. They all share the same state. Good point. Thanks. > > > > However, at this > > > > point we don't know the actual level of the pin, which may be > > active or > > > > inactive. As a result, if the driver probes without enabling the > > > > backlight, the PWM pin might be active, and the backlight would > > be > > > > lit way before being officially enabled. > > > > > > > > To work around this, if the probe function doesn't enable the > > backlight, > > > > the pin is set to its sleep state instead of the default one, > > until the > > > > backlight is enabled. Whenk the backlight is disabled, the pin > > is reset > > > > to its sleep state. > > > Doesn't this workaround result in a backlight flash between > > whatever enables > > > it and the new code turning it off again? > > > > Yeah, I think it would. I guess if you're very careful on how you > > set up > > the device tree you might be able to work around it. Besides the > > default > > and idle standard pinctrl states, there's also the "init" state. The > > core will select that instead of the default state if available. > > However > > there's also pinctrl_init_done() which will try again to switch to > > the > > default state after probe has finished and the driver didn't switch > > away > > from the init state. > > > > So you could presumably set up the device tree such that you have > > three > > states defined: "default" would be the one where the PWM pin is > > active, > > "idle" would be used when backlight is off (PWM pin inactive) and > > then > > another "init" state that would be the same as "idle" to be used > > during > > probe. During probe the driver could then switch to the "idle" > > state so > > that the pin shouldn't glitch. > > > > I'm not sure this would actually work because I think the way that > > pinctrl handles states both "init" and "idle" would be the same > > pointer > > values and therefore pinctrl_init_done() would think the driver > > didn't > > change away from the "init" state because it is the same pointer > > value > > as the "idle" state that the driver selected. One way to work around > > that would be to duplicate the "idle" state definition and > > associate one > > instance of it with the "idle" state and the other with the "init" > > state. At that point both states should be different (different > > pointer > > values) and we'd get the init state selected automatically before > > probe, > > select "idle" during probe and then the core will leave it alone. > > That's > > of course ugly because we duplicate the pinctrl state in DT, but > > perhaps > > it's the least ugly solution. > > Adding Linus for visibility. Perhaps he can share some insight. > > To be honest I'm happy to summarize in my head as "if it flashes then > it's not > a pwm_bl.c's problem" ;-). It does not flash. But the backlight lits way too early, so we have a 1-2 seconds of "white screen" before the panel driver starts. That's the current behaviour. What I original asked about is whether a panel that was dark before the driver probes could end up flashing after the patch because it is activated pre-probe and only goes to sleep afterwards. Anyhow I got an answer; if it flashes after the patch then the problem does not originate in pwm_bl.c and is likely a problem with the handling of the pinctrl idel state
[PATCHv8 11/13] tda9950: use cec_notifier_cec_adap_(un)register
From: Dariusz Marcinkiewicz
Use the new cec_notifier_cec_adap_(un)register() functions to
(un)register the notifier for the CEC adapter.
Signed-off-by: Dariusz Marcinkiewicz
Signed-off-by: Hans Verkuil
---
drivers/gpu/drm/i2c/tda9950.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda9950.c b/drivers/gpu/drm/i2c/tda9950.c
index 250b5e02a314..2f3381f0b2bf 100644
--- a/drivers/gpu/drm/i2c/tda9950.c
+++ b/drivers/gpu/drm/i2c/tda9950.c
@@ -423,7 +423,7 @@ static int tda9950_probe(struct i2c_client *client,
priv->hdmi = glue->parent;
priv->adap = cec_allocate_adapter(&tda9950_cec_ops, priv, "tda9950",
- CEC_CAP_DEFAULTS,
+ CEC_CAP_DEFAULTS |
CEC_CAP_CONNECTOR_INFO,
CEC_MAX_LOG_ADDRS);
if (IS_ERR(priv->adap))
return PTR_ERR(priv->adap);
@@ -460,13 +460,14 @@ static int tda9950_probe(struct i2c_client *client,
if (ret < 0)
return ret;
- priv->notify = cec_notifier_get(priv->hdmi);
+ priv->notify = cec_notifier_cec_adap_register(priv->hdmi, NULL,
+ priv->adap);
if (!priv->notify)
return -ENOMEM;
ret = cec_register_adapter(priv->adap, priv->hdmi);
if (ret < 0) {
- cec_notifier_put(priv->notify);
+ cec_notifier_cec_adap_unregister(priv->notify);
return ret;
}
@@ -476,8 +477,6 @@ static int tda9950_probe(struct i2c_client *client,
*/
devm_remove_action(dev, tda9950_cec_del, priv);
- cec_register_cec_notifier(priv->adap, priv->notify);
-
return 0;
}
@@ -485,8 +484,8 @@ static int tda9950_remove(struct i2c_client *client)
{
struct tda9950_priv *priv = i2c_get_clientdata(client);
+ cec_notifier_cec_adap_unregister(priv->notify);
cec_unregister_adapter(priv->adap);
- cec_notifier_put(priv->notify);
return 0;
}
--
2.20.1
[PATCHv8 12/13] tda998x: use cec_notifier_conn_(un)register
From: Dariusz Marcinkiewicz
Use the new cec_notifier_conn_(un)register() functions to
(un)register the notifier for the HDMI connector, and fill in
the cec_connector_info.
Signed-off-by: Dariusz Marcinkiewicz
Signed-off-by: Hans Verkuil
---
drivers/gpu/drm/i2c/tda998x_drv.c | 56 +++
1 file changed, 28 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index 7f34601bb515..019e1f2f008c 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -1253,6 +1253,8 @@ static int tda998x_connector_init(struct tda998x_priv
*priv,
struct drm_device *drm)
{
struct drm_connector *connector = &priv->connector;
+ struct cec_connector_info conn_info;
+ struct i2c_board_info cec_info;
int ret;
connector->interlace_allowed = 1;
@@ -1269,6 +1271,31 @@ static int tda998x_connector_init(struct tda998x_priv
*priv,
if (ret)
return ret;
+ /*
+* Some TDA998x are actually two I2C devices merged onto one piece
+* of silicon: TDA9989 and TDA19989 combine the HDMI transmitter
+* with a slightly modified TDA9950 CEC device. The CEC device
+* is at the TDA9950 address, with the address pins strapped across
+* to the TDA998x address pins. Hence, it always has the same
+* offset.
+*/
+ memset(&cec_info, 0, sizeof(cec_info));
+ strlcpy(cec_info.type, "tda9950", sizeof(cec_info.type));
+ cec_info.addr = priv->cec_addr;
+ cec_info.platform_data = &priv->cec_glue;
+ cec_info.irq = priv->hdmi->irq;
+
+ priv->cec = i2c_new_device(priv->hdmi->adapter, &cec_info);
+ if (!priv->cec)
+ return -ENODEV;
+
+ cec_fill_conn_info_from_drm(&conn_info, connector);
+
+ priv->cec_notify = cec_notifier_conn_register(priv->cec_glue.parent,
+ NULL, &conn_info);
+ if (!priv->cec_notify)
+ return -ENOMEM;
+
drm_connector_attach_encoder(&priv->connector,
priv->bridge.encoder);
@@ -1651,14 +1678,13 @@ static void tda998x_destroy(struct device *dev)
i2c_unregister_device(priv->cec);
if (priv->cec_notify)
- cec_notifier_put(priv->cec_notify);
+ cec_notifier_conn_unregister(priv->cec_notify);
}
static int tda998x_create(struct device *dev)
{
struct i2c_client *client = to_i2c_client(dev);
struct device_node *np = client->dev.of_node;
- struct i2c_board_info cec_info;
struct tda998x_priv *priv;
u32 video;
int rev_lo, rev_hi, ret;
@@ -1776,12 +1802,6 @@ static int tda998x_create(struct device *dev)
cec_write(priv, REG_CEC_RXSHPDINTENA, CEC_RXSHPDLEV_HPD);
}
- priv->cec_notify = cec_notifier_get(dev);
- if (!priv->cec_notify) {
- ret = -ENOMEM;
- goto fail;
- }
-
priv->cec_glue.parent = dev;
priv->cec_glue.data = priv;
priv->cec_glue.init = tda998x_cec_hook_init;
@@ -1789,26 +1809,6 @@ static int tda998x_create(struct device *dev)
priv->cec_glue.open = tda998x_cec_hook_open;
priv->cec_glue.release = tda998x_cec_hook_release;
- /*
-* Some TDA998x are actually two I2C devices merged onto one piece
-* of silicon: TDA9989 and TDA19989 combine the HDMI transmitter
-* with a slightly modified TDA9950 CEC device. The CEC device
-* is at the TDA9950 address, with the address pins strapped across
-* to the TDA998x address pins. Hence, it always has the same
-* offset.
-*/
- memset(&cec_info, 0, sizeof(cec_info));
- strlcpy(cec_info.type, "tda9950", sizeof(cec_info.type));
- cec_info.addr = priv->cec_addr;
- cec_info.platform_data = &priv->cec_glue;
- cec_info.irq = client->irq;
-
- priv->cec = i2c_new_device(client->adapter, &cec_info);
- if (!priv->cec) {
- ret = -ENODEV;
- goto fail;
- }
-
/* enable EDID read irq: */
reg_set(priv, REG_INT_FLAGS_2, INT_FLAGS_2_EDID_BLK_RD);
--
2.20.1
[PATCHv8 09/13] dw-hdmi: use cec_notifier_conn_(un)register
From: Dariusz Marcinkiewicz
Use the new cec_notifier_conn_(un)register() functions to
(un)register the notifier for the HDMI connector, and fill in
the cec_connector_info.
Signed-off-by: Dariusz Marcinkiewicz
Signed-off-by: Hans Verkuil
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 104 --
1 file changed, 58 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 045b1b13fd0e..fc4d3b5f71d0 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -133,6 +133,8 @@ struct dw_hdmi {
struct drm_connector connector;
struct drm_bridge bridge;
+ int irq;
+
unsigned int version;
struct platform_device *audio;
@@ -184,6 +186,7 @@ struct dw_hdmi {
void (*enable_audio)(struct dw_hdmi *hdmi);
void (*disable_audio)(struct dw_hdmi *hdmi);
+ bool cec_configured;
struct cec_notifier *cec_notifier;
};
@@ -2108,11 +2111,35 @@ static const struct drm_connector_helper_funcs
dw_hdmi_connector_helper_funcs =
.get_modes = dw_hdmi_connector_get_modes,
};
+static void dw_hdmi_cec_enable(struct dw_hdmi *hdmi)
+{
+ mutex_lock(&hdmi->mutex);
+ hdmi->mc_clkdis &= ~HDMI_MC_CLKDIS_CECCLK_DISABLE;
+ hdmi_writeb(hdmi, hdmi->mc_clkdis, HDMI_MC_CLKDIS);
+ mutex_unlock(&hdmi->mutex);
+}
+
+static void dw_hdmi_cec_disable(struct dw_hdmi *hdmi)
+{
+ mutex_lock(&hdmi->mutex);
+ hdmi->mc_clkdis |= HDMI_MC_CLKDIS_CECCLK_DISABLE;
+ hdmi_writeb(hdmi, hdmi->mc_clkdis, HDMI_MC_CLKDIS);
+ mutex_unlock(&hdmi->mutex);
+}
+
+static const struct dw_hdmi_cec_ops dw_hdmi_cec_ops = {
+ .write = hdmi_writeb,
+ .read = hdmi_readb,
+ .enable = dw_hdmi_cec_enable,
+ .disable = dw_hdmi_cec_disable,
+};
+
static int dw_hdmi_bridge_attach(struct drm_bridge *bridge)
{
struct dw_hdmi *hdmi = bridge->driver_private;
struct drm_encoder *encoder = bridge->encoder;
struct drm_connector *connector = &hdmi->connector;
+ struct cec_connector_info conn_info;
connector->interlace_allowed = 1;
connector->polled = DRM_CONNECTOR_POLL_HPD;
@@ -2124,6 +2151,33 @@ static int dw_hdmi_bridge_attach(struct drm_bridge
*bridge)
drm_connector_attach_encoder(connector, encoder);
+ cec_fill_conn_info_from_drm(&conn_info, connector);
+
+ hdmi->cec_notifier = cec_notifier_conn_register(hdmi->dev, NULL,
+ &conn_info);
+ if (!hdmi->cec_notifier)
+ return -ENOMEM;
+
+ if (hdmi->cec_configured) {
+ struct platform_device_info pdevinfo;
+ struct dw_hdmi_cec_data cec;
+
+ memset(&pdevinfo, 0, sizeof(pdevinfo));
+ pdevinfo.parent = hdmi->dev;
+ pdevinfo.id = PLATFORM_DEVID_AUTO;
+
+ cec.hdmi = hdmi;
+ cec.ops = &dw_hdmi_cec_ops;
+ cec.irq = hdmi->irq;
+
+ pdevinfo.name = "dw-hdmi-cec";
+ pdevinfo.data = &cec;
+ pdevinfo.size_data = sizeof(cec);
+ pdevinfo.dma_mask = 0;
+
+ hdmi->cec = platform_device_register_full(&pdevinfo);
+ }
+
return 0;
}
@@ -2393,29 +2447,6 @@ static int dw_hdmi_detect_phy(struct dw_hdmi *hdmi)
return -ENODEV;
}
-static void dw_hdmi_cec_enable(struct dw_hdmi *hdmi)
-{
- mutex_lock(&hdmi->mutex);
- hdmi->mc_clkdis &= ~HDMI_MC_CLKDIS_CECCLK_DISABLE;
- hdmi_writeb(hdmi, hdmi->mc_clkdis, HDMI_MC_CLKDIS);
- mutex_unlock(&hdmi->mutex);
-}
-
-static void dw_hdmi_cec_disable(struct dw_hdmi *hdmi)
-{
- mutex_lock(&hdmi->mutex);
- hdmi->mc_clkdis |= HDMI_MC_CLKDIS_CECCLK_DISABLE;
- hdmi_writeb(hdmi, hdmi->mc_clkdis, HDMI_MC_CLKDIS);
- mutex_unlock(&hdmi->mutex);
-}
-
-static const struct dw_hdmi_cec_ops dw_hdmi_cec_ops = {
- .write = hdmi_writeb,
- .read = hdmi_readb,
- .enable = dw_hdmi_cec_enable,
- .disable = dw_hdmi_cec_disable,
-};
-
static const struct regmap_config hdmi_regmap_8bit_config = {
.reg_bits = 32,
.val_bits = 8,
@@ -2438,7 +2469,6 @@ __dw_hdmi_probe(struct platform_device *pdev,
struct device_node *np = dev->of_node;
struct platform_device_info pdevinfo;
struct device_node *ddc_node;
- struct dw_hdmi_cec_data cec;
struct dw_hdmi *hdmi;
struct resource *iores = NULL;
int irq;
@@ -2588,6 +2618,7 @@ __dw_hdmi_probe(struct platform_device *pdev,
ret = irq;
goto err_iahb;
}
+ hdmi->irq = irq;
ret = devm_request_threaded_irq(dev, irq, dw_hdmi_hardirq,
dw_hdmi_irq, IRQF_SHARED,
@@ -2595,12 +2626,6 @@ __dw_hdmi_probe(struct platform_device *pdev,
if (
Re: [PATCH 4/4] drm/sun4i: Enable DRM InfoFrame support on H6
Dne ponedeljek, 24. junij 2019 ob 17:56:30 CEST je Chen-Yu Tsai napisal(a):
> On Mon, Jun 24, 2019 at 11:49 PM Andrzej Hajda wrote:
> > On 24.06.2019 17:05, Jernej Škrabec wrote:
> > > Dne ponedeljek, 24. junij 2019 ob 17:03:31 CEST je Andrzej Hajda
napisal(a):
> > >> On 26.05.2019 23:20, Jonas Karlman wrote:
> > >>> This patch enables Dynamic Range and Mastering InfoFrame on H6.
> > >>>
> > >>> Cc: Maxime Ripard
> > >>> Cc: Jernej Skrabec
> > >>> Signed-off-by: Jonas Karlman
> > >>> ---
> > >>>
> > >>> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 2 ++
> > >>> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 1 +
> > >>> 2 files changed, 3 insertions(+)
> > >>>
> > >>> diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
> > >>> b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c index
> > >>> 39d8509d96a0..b80164dd8ad8
> > >>> 100644
> > >>> --- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
> > >>> +++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
> > >>> @@ -189,6 +189,7 @@ static int sun8i_dw_hdmi_bind(struct device *dev,
> > >>> struct device *master,>
> > >>>
> > >>> sun8i_hdmi_phy_init(hdmi->phy);
> > >>>
> > >>> plat_data->mode_valid = hdmi->quirks->mode_valid;
> > >>>
> > >>> + plat_data->drm_infoframe = hdmi->quirks->drm_infoframe;
> > >>>
> > >>> sun8i_hdmi_phy_set_ops(hdmi->phy, plat_data);
> > >>>
> > >>> platform_set_drvdata(pdev, hdmi);
> > >>>
> > >>> @@ -255,6 +256,7 @@ static const struct sun8i_dw_hdmi_quirks
> > >>> sun8i_a83t_quirks = {>
> > >>>
> > >>> static const struct sun8i_dw_hdmi_quirks sun50i_h6_quirks = {
> > >>>
> > >>> .mode_valid = sun8i_dw_hdmi_mode_valid_h6,
> > >>>
> > >>> + .drm_infoframe = true,
> > >>>
> > >>> };
> > >>>
> > >>> static const struct of_device_id sun8i_dw_hdmi_dt_ids[] = {
> > >>>
> > >>> diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
> > >>> b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h index
> > >>> 720c5aa8adc1..2a0ec08ee236
> > >>> 100644
> > >>> --- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
> > >>> +++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
> > >>> @@ -178,6 +178,7 @@ struct sun8i_dw_hdmi_quirks {
> > >>>
> > >>> enum drm_mode_status (*mode_valid)(struct drm_connector
> > >
> > > *connector,
> > >
> > >>>const struct
> > >
> > > drm_display_mode *mode);
> > >
> > >>> unsigned int set_rate : 1;
> > >>>
> > >>> + unsigned int drm_infoframe : 1;
> > >>
> > >> Again, drm_infoframe suggests it contains inforframe, but in fact it
> > >> just informs infoframe can be used, so again my suggestion
> > >> use_drm_infoframe.
> > >>
> > >> Moreover bool type seems more appropriate here.
> > >
> > > checkpatch will give warning if bool is used.
> >
> > Then I would say "fix/ignore checkpatch" :)
> >
> > But maybe there is a reason.
>
> Here's an old one from Linus: https://lkml.org/lkml/2013/9/1/154
>
> I'd say that bool in a struct is a waste of space compared to a 1 bit
> bitfield, especially when there already are other bitfields in the same
> struct.
> > Anyway I've tested and I do not see the warning, could you elaborate it.
>
> Maybe checkpatch.pl --strict?
It seems they removed that check:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?
id=7967656ffbfa493f5546c0f1
After reading that block of text, I'm not sure what would be prefered way for
this case.
Best regards,
Jernej
[PATCHv8 04/13] cec: expose the new connector info API
From: Dariusz Marcinkiewicz
Until now the connector info API was a kernel-internal API only.
This moves it to the public API and adds the new ioctl to retrieve
this information.
Signed-off-by: Dariusz Marcinkiewicz
Signed-off-by: Hans Verkuil
---
drivers/media/cec/cec-adap.c | 2 ++
drivers/media/cec/cec-api.c | 16
drivers/media/cec/cec-core.c | 5 -
include/media/cec.h | 26 +-
include/uapi/linux/cec.h | 33 +
5 files changed, 52 insertions(+), 30 deletions(-)
diff --git a/drivers/media/cec/cec-adap.c b/drivers/media/cec/cec-adap.c
index 451c61bde4d4..059c83525024 100644
--- a/drivers/media/cec/cec-adap.c
+++ b/drivers/media/cec/cec-adap.c
@@ -319,6 +319,8 @@ static void cec_post_state_event(struct cec_adapter *adap)
ev.state_change.phys_addr = adap->phys_addr;
ev.state_change.log_addr_mask = adap->log_addrs.log_addr_mask;
+ ev.state_change.have_conn_info =
+ adap->conn_info.type != CEC_CONNECTOR_TYPE_NO_CONNECTOR;
cec_queue_event(adap, &ev);
}
diff --git a/drivers/media/cec/cec-api.c b/drivers/media/cec/cec-api.c
index 12d676484472..cba0099beab2 100644
--- a/drivers/media/cec/cec-api.c
+++ b/drivers/media/cec/cec-api.c
@@ -187,6 +187,17 @@ static long cec_adap_s_log_addrs(struct cec_adapter *adap,
struct cec_fh *fh,
return 0;
}
+static long cec_adap_g_connector_info(struct cec_adapter *adap,
+ struct cec_log_addrs __user *parg)
+{
+ if (!(adap->capabilities & CEC_CAP_CONNECTOR_INFO))
+ return -ENOTTY;
+ if (copy_to_user(parg, &adap->conn_info,
+sizeof(adap->conn_info)))
+ return -EFAULT;
+ return 0;
+}
+
static long cec_transmit(struct cec_adapter *adap, struct cec_fh *fh,
bool block, struct cec_msg __user *parg)
{
@@ -506,6 +517,9 @@ static long cec_ioctl(struct file *filp, unsigned int cmd,
unsigned long arg)
case CEC_ADAP_S_LOG_ADDRS:
return cec_adap_s_log_addrs(adap, fh, block, parg);
+ case CEC_ADAP_G_CONNECTOR_INFO:
+ return cec_adap_g_connector_info(adap, parg);
+
case CEC_TRANSMIT:
return cec_transmit(adap, fh, block, parg);
@@ -578,6 +592,8 @@ static int cec_open(struct inode *inode, struct file *filp)
/* Queue up initial state events */
ev.state_change.phys_addr = adap->phys_addr;
ev.state_change.log_addr_mask = adap->log_addrs.log_addr_mask;
+ ev.state_change.have_conn_info =
+ adap->conn_info.type != CEC_CONNECTOR_TYPE_NO_CONNECTOR;
cec_queue_event_fh(fh, &ev, 0);
#ifdef CONFIG_CEC_PIN
if (adap->pin && adap->pin->ops->read_hpd) {
diff --git a/drivers/media/cec/cec-core.c b/drivers/media/cec/cec-core.c
index e45b792d26fb..db7adffcdc76 100644
--- a/drivers/media/cec/cec-core.c
+++ b/drivers/media/cec/cec-core.c
@@ -189,11 +189,6 @@ static void cec_cec_notify(struct cec_adapter *adap, u16
pa)
cec_s_phys_addr(adap, pa, false);
}
-void cec_notifier_register(struct cec_notifier *n,
- struct cec_adapter *adap,
- void (*callback)(struct cec_adapter *adap, u16 pa));
-void cec_notifier_unregister(struct cec_notifier *n);
-
void cec_register_cec_notifier(struct cec_adapter *adap,
struct cec_notifier *notifier)
{
diff --git a/include/media/cec.h b/include/media/cec.h
index 45f2c98ed75b..2c30df40e2ce 100644
--- a/include/media/cec.h
+++ b/include/media/cec.h
@@ -17,9 +17,7 @@
#include
#include
#include
-
-/* CEC_ADAP_G_CONNECTOR_INFO is available */
-#define CEC_CAP_CONNECTOR_INFO 0
+#include
#define CEC_CAP_DEFAULTS (CEC_CAP_LOG_ADDRS | CEC_CAP_TRANSMIT | \
CEC_CAP_PASSTHROUGH | CEC_CAP_RC)
@@ -55,7 +53,6 @@ struct cec_devnode {
struct cec_adapter;
struct cec_data;
struct cec_pin;
-struct cec_notifier;
struct cec_data {
struct list_head list;
@@ -147,27 +144,6 @@ struct cec_adap_ops {
*/
#define CEC_MAX_MSG_TX_QUEUE_SZ(18 * 1)
-/**
- * struct cec_event_connector - tells if and which connector is associated
- * with the CEC adapter.
- * @card_no: drm card number
- * @connector_id: drm connector ID
- */
-struct cec_drm_connector_info {
- __u32 card_no;
- __u32 connector_id;
-};
-
-#define CEC_CONNECTOR_TYPE_NO_CONNECTOR0
-#define CEC_CONNECTOR_TYPE_DRM 1
-struct cec_connector_info {
- __u32 type;
- union {
- struct cec_drm_connector_info drm;
- __u32 raw[16];
- };
-};
-
struct cec_adapter {
struct module *owner;
char name[32];
diff --git a/include/uapi/linux/cec.h b/include/uapi/linux/cec.h
index 5704fa0292b5..414df75c0ab8 100644
--- a/include/uapi/linux/cec.h
+++ b/include/uapi/linux/cec.h
@@ -317,6 +317,8 @@ static inline int cec_i
[PATCHv8 03/13] cec: add new notifier functions
In order to support multiple CEC devices for an HDMI connector,
and to support cec_connector_info, drivers should use either a
cec_notifier_conn_(un)register pair of functions (HDMI drivers)
or a cec_notifier_cec_adap_(un)register pair (CEC adapter drivers).
This replaces cec_notifier_get_conn/cec_notifier_put.
For CEC adapters it is also no longer needed to call cec_notifier_register,
cec_register_cec_notifier and cec_notifier_unregister. This is now
all handled internally by the new functions.
The called_cec_notifier_register bool is needed to handle the case where
a CEC adapter driver called the old cec_notifier_register() function
instead of cec_notifier_cec_adap_unregister().
Once those old functions are removed in the future, that bool can also
be removed.
Signed-off-by: Hans Verkuil
---
drivers/media/cec/cec-notifier.c | 89
include/media/cec-notifier.h | 78
2 files changed, 167 insertions(+)
diff --git a/drivers/media/cec/cec-notifier.c b/drivers/media/cec/cec-notifier.c
index ce10dfd400bb..49d6ec198d38 100644
--- a/drivers/media/cec/cec-notifier.c
+++ b/drivers/media/cec/cec-notifier.c
@@ -22,9 +22,11 @@ struct cec_notifier {
struct list_head head;
struct kref kref;
struct device *hdmi_dev;
+ struct cec_connector_info conn_info;
const char *conn_name;
struct cec_adapter *cec_adap;
void (*callback)(struct cec_adapter *adap, u16 pa);
+ bool called_cec_notifier_register;
u16 phys_addr;
};
@@ -87,6 +89,85 @@ void cec_notifier_put(struct cec_notifier *n)
}
EXPORT_SYMBOL_GPL(cec_notifier_put);
+struct cec_notifier *
+cec_notifier_conn_register(struct device *hdmi_dev, const char *conn_name,
+ const struct cec_connector_info *conn_info)
+{
+ struct cec_notifier *n = cec_notifier_get_conn(hdmi_dev, conn_name);
+
+ if (!n)
+ return n;
+
+ mutex_lock(&n->lock);
+ n->phys_addr = CEC_PHYS_ADDR_INVALID;
+ if (conn_info)
+ n->conn_info = *conn_info;
+ else
+ memset(&n->conn_info, 0, sizeof(n->conn_info));
+ if (n->cec_adap) {
+ cec_phys_addr_invalidate(n->cec_adap);
+ cec_s_conn_info(n->cec_adap, conn_info);
+ }
+ mutex_unlock(&n->lock);
+ return n;
+}
+EXPORT_SYMBOL_GPL(cec_notifier_conn_register);
+
+void cec_notifier_conn_unregister(struct cec_notifier *n)
+{
+ if (!n)
+ return;
+
+ mutex_lock(&n->lock);
+ memset(&n->conn_info, 0, sizeof(n->conn_info));
+ n->phys_addr = CEC_PHYS_ADDR_INVALID;
+ if (n->cec_adap) {
+ cec_phys_addr_invalidate(n->cec_adap);
+ cec_s_conn_info(n->cec_adap, NULL);
+ }
+ mutex_unlock(&n->lock);
+ cec_notifier_put(n);
+}
+EXPORT_SYMBOL_GPL(cec_notifier_conn_unregister);
+
+struct cec_notifier *
+cec_notifier_cec_adap_register(struct device *hdmi_dev, const char *conn_name,
+ struct cec_adapter *adap)
+{
+ struct cec_notifier *n;
+
+ if (WARN_ON(!adap))
+ return NULL;
+
+ n = cec_notifier_get_conn(hdmi_dev, conn_name);
+ if (!n)
+ return n;
+
+ mutex_lock(&n->lock);
+ n->cec_adap = adap;
+ adap->conn_info = n->conn_info;
+ adap->notifier = n;
+ cec_s_phys_addr(adap, n->phys_addr, false);
+ mutex_unlock(&n->lock);
+ return n;
+}
+EXPORT_SYMBOL_GPL(cec_notifier_cec_adap_register);
+
+void cec_notifier_cec_adap_unregister(struct cec_notifier *n)
+{
+ if (!n)
+ return;
+
+ mutex_lock(&n->lock);
+ memset(&n->cec_adap->conn_info, 0, sizeof(n->cec_adap->conn_info));
+ n->cec_adap->notifier = NULL;
+ n->cec_adap = NULL;
+ n->callback = NULL;
+ mutex_unlock(&n->lock);
+ cec_notifier_put(n);
+}
+EXPORT_SYMBOL_GPL(cec_notifier_cec_adap_unregister);
+
void cec_notifier_set_phys_addr(struct cec_notifier *n, u16 pa)
{
if (n == NULL)
@@ -96,6 +177,8 @@ void cec_notifier_set_phys_addr(struct cec_notifier *n, u16
pa)
n->phys_addr = pa;
if (n->callback)
n->callback(n->cec_adap, n->phys_addr);
+ else if (n->cec_adap)
+ cec_s_phys_addr(n->cec_adap, n->phys_addr, false);
mutex_unlock(&n->lock);
}
EXPORT_SYMBOL_GPL(cec_notifier_set_phys_addr);
@@ -121,6 +204,7 @@ void cec_notifier_register(struct cec_notifier *n,
{
kref_get(&n->kref);
mutex_lock(&n->lock);
+ n->called_cec_notifier_register = true;
n->cec_adap = adap;
n->callback = callback;
n->callback(adap, n->phys_addr);
@@ -130,8 +214,13 @@ EXPORT_SYMBOL_GPL(cec_notifier_register);
void cec_notifier_unregister(struct cec_notifier *n)
{
+ /* Do nothing unless cec_notifier_register was called first */
+ if (!n->called_cec_notifier_register)
+
