Re: [PATCH] get_maintainer: Add email addresses from .yaml files

2020-04-26 Thread Sam Ravnborg
Hi Joe. On Sun, Apr 26, 2020 at 10:40:52PM -0700, Joe Perches wrote: > .yaml files can contain maintainer/author addresses and it seems > unlikely or unnecessary that individual MAINTAINER file section > entries for each .yaml file will be created. > > So dd the email addresses found in .yaml

[PATCH] get_maintainer: Add email addresses from .yaml files

2020-04-26 Thread Joe Perches
.yaml files can contain maintainer/author addresses and it seems unlikely or unnecessary that individual MAINTAINER file section entries for each .yaml file will be created. So dd the email addresses found in .yaml files to the default get_maintainer output. The email addresses are marked with

Re: [PATCH] drm/radeon: cleanup coding style a bit

2020-04-26 Thread Joe Perches
btw: the debugging macros in atom.c are not good. It could be something like the below as the output logging is at best poorly formatted due to the many individual printks without KERN_ that are emitted on separate lines. #define ATOM_DEBUG should probably be commented out. The debugging

Re: [PATCH] drm/radeon: cleanup coding style a bit

2020-04-26 Thread Joe Perches
On Sun, 2020-04-26 at 15:18 +0200, Christian König wrote: > Am 26.04.20 um 15:12 schrieb Bernard Zhao: > > Maybe no need to check ws before kmalloc, kmalloc will check > > itself, kmalloc`s logic is if ptr is NULL, kmalloc will just > > return > > > > Signed-off-by: Bernard Zhao > >

Re: [PATCH] drm/edid: Fix off-by-one in DispID DTD pixel clock

2020-04-26 Thread Sasha Levin
Hi [This is an automated email] This commit has been processed because it contains a -stable tag. The stable tag indicates that it's relevant for the following trees: all The bot has tested the following trees: v5.6.7, v5.4.35, v4.19.118, v4.14.177, v4.9.220, v4.4.220. v5.6.7: Build OK!

Re: [PATCH] drm/radeon: cleanup coding style a bit

2020-04-26 Thread Christian König
Am 26.04.20 um 15:12 schrieb Bernard Zhao: Maybe no need to check ws before kmalloc, kmalloc will check itself, kmalloc`s logic is if ptr is NULL, kmalloc will just return Signed-off-by: Bernard Zhao Reviewed-by: Christian König I'm wondering why the automated scripts haven't found that

[PATCH] drm/msm/dpu: remove set but not used 'topology'

2020-04-26 Thread Jason Yan
Fix the following gcc warning: drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c:958:30: warning: variable ‘topology’ set but not used [-Wunused-but-set-variable] struct msm_display_topology topology; ^~~~ Reported-by: Hulk Robot Signed-off-by: Jason Yan ---

[PATCH] drm/exynos: remove no need devm_kfree in probe

2020-04-26 Thread Bernard Zhao
Remove no need devm_kfree in probe. The change is to make the code a bit more readable Signed-off-by: Bernard Zhao --- drivers/gpu/drm/exynos/exynos_drm_dpi.c | 10 +++--- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c

[PATCH] drm: Replace drm_modeset_lock/unlock_all with DRM_MODESET_LOCK_ALL_* helpers

2020-04-26 Thread Michal Orzel
As suggested by the TODO list for the kernel DRM subsystem, replace the deprecated functions that take/drop modeset locks with new helpers. Signed-off-by: Michal Orzel --- drivers/gpu/drm/drm_mode_object.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git

Re: [PATCH v3 1/6] drm/bridge: ti-sn65dsi86: Export bridge GPIOs to Linux

2020-04-26 Thread Stephen Boyd
Quoting Douglas Anderson (2020-04-23 09:25:43) > The ti-sn65dsi86 MIPI DSI to eDP bridge chip has 4 pins on it that can > be used as GPIOs in a system. Each pin can be configured as input, > output, or a special function for the bridge chip. These are: > - GPIO1: SUSPEND Input > - GPIO2: DSIA

Re: [PATCH 1/1] drm/qxl: add mutex_lock/mutex_unlock to ensure the order in which resources are released

2020-04-26 Thread Vasily Averin
On 4/18/20 9:39 AM, Caicai wrote: > When a qxl resource is released, the list that needs to be released is > fetched from the linked list ring and cleared. When you empty the list, > instead of trying to determine whether the ttm buffer object for each > qxl in the list is locked, you release the

[PATCH] dt-bindings: gpu: add power-domains #cooling-cells to arm, mali-bifrost.yaml

2020-04-26 Thread Johan Jonker
A test with the command below gives this error: arch/arm64/boot/dts/rockchip/px30-evb.dt.yaml: gpu@ff40: '#cooling-cells', 'power-domains' do not match any of the regexes: 'pinctrl-[0-9]+' With the conversion to yaml it also filters things in a node that are used by other drivers like

Re: [PATCH v3] console: newport_con: fix an issue about leak related system resources

2020-04-26 Thread Dejin Zheng
On Fri, Apr 24, 2020 at 06:54:41PM +0200, Markus Elfring wrote: > > The corresponding system resources were not released then. > > How do you think about a wording variant like the following? > Markus, I think my commit comments is a sufficiently clear description for this patch. Someone has told

Re: [PATCH v5 6/6] drm/tegra: output: rgb: Wrap directly-connected panel into DRM bridge

2020-04-26 Thread Dmitry Osipenko
25.04.2020 20:02, Sam Ravnborg пишет: > Hi Dmitry > > On Sat, Apr 18, 2020 at 08:07:03PM +0300, Dmitry Osipenko wrote: >> Currently Tegra DRM driver manually manages display panel, but this >> management could be moved out into DRM core if we'll wrap panel into >> DRM bridge. This patch wraps RGB

[PATCH] drm/meson: viu: fix setting the OSD burst length in VIU_OSD1_FIFO_CTRL_STAT

2020-04-26 Thread Martin Blumenstingl
The burst length is configured in VIU_OSD1_FIFO_CTRL_STAT[31] and VIU_OSD1_FIFO_CTRL_STAT[11:10]. The public S905D3 datasheet describes this as: - 0x0 = up to 24 per burst - 0x1 = up to 32 per burst - 0x2 = up to 48 per burst - 0x3 = up to 64 per burst - 0x4 = up to 96 per burst - 0x5 = up to 128

[PATCH] drm/amd/display: remove conversion to bool amdgpu_dm.c

2020-04-26 Thread Jason Yan
The '==' expression itself is bool, no need to convert it to bool again. This fixes the following coccicheck warning: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:7230:16-21: WARNING: conversion to bool not needed here Signed-off-by: Jason Yan ---

[PATCH] drm/amd/powerplay: remove conversion to bool in navi10_ppt.c

2020-04-26 Thread Jason Yan
The '==' expression itself is bool, no need to convert it to bool again. This fixes the following coccicheck warning: drivers/gpu/drm/amd/powerplay/navi10_ppt.c:698:47-52: WARNING: conversion to bool not needed here Signed-off-by: Jason Yan --- drivers/gpu/drm/amd/powerplay/navi10_ppt.c | 2 +-

[PATCH] drm/exynos: make pointer to const data const type

2020-04-26 Thread Bernard Zhao
Maybe keep pointer which points to global const string data in const type is better, make sure not change const data. Signed-off-by: Bernard Zhao --- drivers/gpu/drm/exynos/exynos_drm_dsi.c | 2 +- drivers/gpu/drm/exynos/exynos_drm_mic.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)

Re: [PATCH -next] drm/mediatek: Fix Kconfig warning

2020-04-26 Thread Chun-Kuang Hu
Hi, YueHaibing: YueHaibing 於 2020年4月20日 週一 下午10:04寫道: > > WARNING: unmet direct dependencies detected for MTK_MMSYS > Depends on [n]: (ARCH_MEDIATEK [=y] || COMPILE_TEST [=n]) && > COMMON_CLK_MT8173_MMSYS [=n] > Selected by [y]: > - DRM_MEDIATEK [=y] && HAS_IOMEM [=y] && DRM [=y] &&

Re: [PATCH] drm/mediatek: stop iterating dma addresses when sg_dma_len() == 0

2020-04-26 Thread Chun-Kuang Hu
Hi, Anand: Anand K Mistry 於 2020年4月20日 週一 下午2:09寫道: > > If dma_map_sg() merges pages when creating the mapping, only the first > entries will have a valid sg_dma_address() and sg_dma_len(), followed by > entries with sg_dma_len() == 0. > > Signed-off-by: Anand K Mistry > --- >

Re: [PATCH v2 01/91] i2c: brcmstb: Allow to compile it on BCM2835

2020-04-26 Thread Wolfram Sang
On Fri, Apr 24, 2020 at 05:33:42PM +0200, Maxime Ripard wrote: > The BCM2711, supported by ARCH_BCM2835, also has a controller by the > brcmstb driver so let's allow it to be compiled on that platform. > > Cc: Kamal Dasu > Cc: Wolfram Sang > Cc: bcm-kernel-feedback-l...@broadcom.com > Cc: