RE: [PATCH 2/2] drm/virtio: Include modifier as part of set_scanout_blob

> -Original Message- > From: dri-devel On Behalf Of Gerd > Hoffmann > Sent: Wednesday, March 31, 2021 4:00 PM > To: Kasireddy, Vivek > Cc: dri-devel@lists.freedesktop.org; gurchetansi...@chromium.org > Subject: Re: [PATCH 2/2] drm/virtio: Include modifier as part of > set_scanout_blob

Re: [PATCH] zero-fill colormap in drivers/video/fbdev/core/fbcmap.c

On Thu, Apr 01, 2021 at 11:55:50AM +0200, Geert Uytterhoeven wrote: > On Thu, Apr 1, 2021 at 12:09 AM Phillip Potter wrote: > > Use kzalloc() rather than kmalloc() for the dynamically allocated parts > > of the colormap in fb_alloc_cmap_gfp, to prevent a leak of random kernel > > data to

Re: [PATCH] staging: fbtft: change snprintf() to scnprintf()

On Fri, Apr 02, 2021 at 09:05:01AM +, Carlis wrote: > From: Xuezhi Zhang > > show() must not use snprintf() when formatting the value to > be returned to user space. Why not? The code is just fine as-is. > > Signed-off-by: Xuezhi Zhang > --- > drivers/staging/fbtft/fbtft-sysfs.c | 2 +-

[PATCH] drm/amd: remove not needed conversion to bool

Fix coccicheck warning: drivers/gpu/drm/amd/amdgpu/mmhub_v2_3.c:573:39-44: WARNING: conversion to bool not needed here drivers/gpu/drm/amd/amdgpu/mmhub_v2_3.c:575:39-44: WARNING: conversion to bool not needed here Signed-off-by: Bernard Zhao --- drivers/gpu/drm/amd/amdgpu/mmhub_v2_3.c | 4

[PATCH] staging: fbtft: change snprintf() to scnprintf()

From: Xuezhi Zhang show() must not use snprintf() when formatting the value to be returned to user space. Signed-off-by: Xuezhi Zhang --- drivers/staging/fbtft/fbtft-sysfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/fbtft/fbtft-sysfs.c

[drm-intel:drm-intel-next 3/4] drivers/gpu/drm/i915/display/intel_dp_hdcp.c:582 intel_dp_hdcp2_read_msg() error: uninitialized symbol 'msg_end'.

tree: git://anongit.freedesktop.org/drm-intel drm-intel-next head: b29854ec3b9ca6512a783e2153465f27a777a654 commit: 989cf9a93892409cf8e84c30c0faaa522ac83807 [3/4] drm/i915/hdcp: Add DP HDCP2.2 timeout to read entire msg config: i386-randconfig-m031-20210401 (attached as .config) compiler:

Re: [PATCH v6 4/5] drm/bridge: anx7625: add HDCP support

Hi Xin, On Fri, Apr 02, 2021 at 10:27:08AM +0800, Xin Ji wrote: > On Mon, Mar 29, 2021 at 02:02:08PM -0400, Sean Paul wrote: > > On Mon, Mar 29, 2021 at 6:27 AM Xin Ji wrote: > > > > > > On Thu, Mar 25, 2021 at 02:19:23PM -0400, Sean Paul wrote: > > > > On Fri, Mar 19, 2021 at 2:35 AM Xin Ji

Re: [PATCH v6 4/5] drm/bridge: anx7625: add HDCP support

On Fri, Apr 02, 2021 at 11:59:39AM +0300, Laurent Pinchart wrote: > Hi Xin, > > On Fri, Apr 02, 2021 at 10:27:08AM +0800, Xin Ji wrote: > > On Mon, Mar 29, 2021 at 02:02:08PM -0400, Sean Paul wrote: > > > On Mon, Mar 29, 2021 at 6:27 AM Xin Ji wrote: > > > > > > > > On Thu, Mar 25, 2021 at

[PATCH] drm/nouveau: fix potential abnormal lock/unlock

Fix coccicheck warning: drivers/gpu/drm/nouveau/nvkm/engine/fifo/base.c:115:3-9: preceding lock on line 109 drivers/gpu/drm/nouveau/nvkm/engine/fifo/base.c:98:2-8: preceding lock on line 95 As we see, function nvkm_fifo_chan_inst & nvkm_fifo_chan_chid both use spin_lock_irqsave, but no

[PATCH] drm/kmb: cleanup coding style a bit

Fix coccicheck warning: drivers/gpu/drm/kmb/kmb_dsi.c:284:3-4: Unneeded semicolon drivers/gpu/drm/kmb/kmb_dsi.c:304:3-4: Unneeded semicolon drivers/gpu/drm/kmb/kmb_dsi.c:321:3-4: Unneeded semicolon drivers/gpu/drm/kmb/kmb_dsi.c:340:3-4: Unneeded semicolon drivers/gpu/drm/kmb/kmb_dsi.c:364:2-3:

[PATCH] drm/gud: cleanup coding style a bit

Fix coccicheck warning: drivers/gpu/drm/gud/gud_internal.h:89:2-3: Unneeded semicolon drivers/gpu/drm/gud/gud_internal.h:107:2-3: Unneeded semicolon Signed-off-by: Bernard Zhao --- drivers/gpu/drm/gud/gud_internal.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH RFC 2/3] fpga: support loading from a pre-allocated buffer

Some systems are memory constrained but they need to load very large Configuration files. The FPGA subsystem allows drivers to request this Configuration image be loaded from the filesystem, but this requires that the entire configuration data be loaded into kernel memory first before it's

[PATCH RFC 0/3] Adds support to allow the bitstream configuration from pre-allocated dma-buffer

Nava kishore Manne (3): fpga: region: Add fpga-region property 'fpga-config-from-dmabuf' fpga: support loading from a pre-allocated buffer fpga: zynqmp: Use the scatterlist interface .../devicetree/bindings/fpga/fpga-region.txt | 2 + drivers/fpga/fpga-mgr.c | 126

[PATCH] apply: use DEFINE_SPINLOCK() instead of spin_lock_init().

From: Jiahua Yu spinlock can be initialized automatically with DEFINE_SPINLOCK() rather than explicitly calling spin_lock_init(). Signed-off-by: Jiahua Yu --- drivers/video/fbdev/omap2/omapfb/dss/apply.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git

[PATCH RFC 3/3] fpga: zynqmp: Use the scatterlist interface

Allows drivers to request the Configuration image be loaded from dma-able continuous buffer to avoid needless memory pressure and delays due to multiple copies. Signed-off-by: Nava kishore Manne --- drivers/fpga/zynqmp-fpga.c | 35 +++ 1 file changed, 35

[PATCH RFC 1/3] fpga: region: Add fpga-region property 'fpga-config-from-dmabuf'

Add "fpga-config-from-dmabuf" property to allow the bitstream configuration from pre-allocated dma-buffer. Signed-off-by: Nava kishore Manne --- Documentation/devicetree/bindings/fpga/fpga-region.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git

Re: [Freedreno] [v1] drm/msm/disp/dpu1: fix warn stack reported during dpu resume

On 2021-04-01 19:01, Dmitry Baryshkov wrote: On Thu, 1 Apr 2021 at 16:19, wrote: On 2021-04-01 07:37, Dmitry Baryshkov wrote: > On 01/04/2021 01:47, Rob Clark wrote: >> On Wed, Mar 31, 2021 at 9:03 AM Dmitry Baryshkov >> wrote: >>> >>> On 31/03/2021 14:27, Kalyan Thota wrote: WARN_ON

Re: [PATCH v1] drm/amdgpu: Try modify this line into a well-understood code

Am 02.04.21 um 04:55 schrieb ZhiJie.Zhang: Signed-off-by: ZhiJie.Zhang Good idea. Reviewed-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c

[PATCH] drm/connector: demote connector force-probes for non-master clients

Force-probing a connector can be slow and cause flickering. As this affects the global KMS state, let's make it so only the DRM master can force-probe a connector. Non-master DRM clients won't be able to force-probe a connector anymore. Instead, KMS will perform a regular read-only connector

[v1] drm/msm/disp/dpu1: program 3d_merge only if block is attached

Update the 3d merge as active in the data path only if the hw block is selected in the configuration. Reported-by: Stephen Boyd Signed-off-by: Kalyan Thota --- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git

[PATCH] drm/panel: add rotation support for Elida KD35T133 panels

Update the panel to allow setting the rotation value in device tree. Tested on an Odroid Go Advance, where the panel is by default rotated 270 degrees. Signed-off-by: Chris Morgan --- drivers/gpu/drm/panel/panel-elida-kd35t133.c | 8 1 file changed, 8 insertions(+) diff --git

[PATCH] drm/panel: correct typo in comments for Elida KD35T133

Update the comments to state this is a 3.5" display and not a 5.5" display. Signed-off-by: Chris Morgan --- drivers/gpu/drm/panel/panel-elida-kd35t133.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/panel/panel-elida-kd35t133.c

Re: [PATCH v2] drm/msm: Drop mm_lock in scan loop

Hi, On Fri, Apr 2, 2021 at 2:08 PM Rob Clark wrote: > > From: Rob Clark > > lock_stat + mmm_donut[1] say that this reduces contention on mm_lock > significantly (~350x lower waittime-max, and ~100x lower waittime-avg) > > [1] >

[PATCH v3 06/12] drm/bridge: ti-sn65dsi86: Get rid of the useless detect() function

If we just leave the detect() function as NULL then the upper layers assume we're always connected. There's no reason for a stub. Signed-off-by: Douglas Anderson Reviewed-by: Andrzej Hajda --- (no changes since v1) drivers/gpu/drm/bridge/ti-sn65dsi86.c | 12 1 file changed, 12

[PATCH v3 04/12] drm/bridge: ti-sn65dsi86: Reorder remove()

Let's make the remove() function strictly the reverse of the probe() function so it's easier to reason about. This patch was created by code inspection and should move us closer to a proper remove. Signed-off-by: Douglas Anderson Reviewed-by: Andrzej Hajda --- Changes in v3: - Removed "NOTES"

[PATCH v3 02/12] drm/bridge: ti-sn65dsi86: Simplify refclk handling

The clock framework makes it simple to deal with an optional clock. You can call clk_get_optional() and if the clock isn't specified it'll just return NULL without complaint. It's valid to pass NULL to enable/disable/prepare/unprepare. Let's make use of this to simplify things a tiny bit.

[PATCH v3 07/12] drm/bridge: ti-sn65dsi86: Remove extra call: drm_connector_update_edid_property()

As of commit 5186421cbfe2 ("drm: Introduce epoch counter to drm_connector") the drm_get_edid() function calls drm_connector_update_edid_property() for us. There's no reason for us to call it again. Signed-off-by: Douglas Anderson Reviewed-by: Andrzej Hajda --- (no changes since v1)

[PATCH v3 08/12] drm/bridge: ti-sn65dsi86: Power things properly for reading the EDID

eDP panels won't provide their EDID unless they're powered on. Let's chain a power-on before we read the EDID. This roughly matches what was done in 'parade-ps8640.c'. NOTE: The old code attempted to call pm_runtime_get_sync() before reading the EDID. While that was enough to power the bridge

[PATCH v3 09/12] drm/bridge: ti-sn65dsi86: Fail aux transfers right away if not powered

If the bridge (and panel) haven't been powered on then AUX transfers just won't work. Let's just fail them instantly. Signed-off-by: Douglas Anderson --- If the patch ("drm/panel: panel-simple: Use runtime pm to avoid excessive unprepare / prepare") is accepted then we could consider actually

[PATCH v3 05/12] drm/bridge: ti-sn65dsi86: Move drm_panel_unprepare() to post_disable()

We prepared the panel in pre_enable() so we should unprepare it in post_disable() to match. This becomes important once we start using pre_enable() and post_disable() to make sure things are powered on (and then off again) when reading the EDID. Signed-off-by: Douglas Anderson Reviewed-by:

[PATCH v3 10/12] drm/bridge: ti-sn65dsi86: Read the EDID only if refclk was provided

Though I don't have access to any hardware that uses ti-sn65dsi86 and _doesn't_ provide a "refclk", I believe that we'll have trouble reading the EDID at bootup in that case. Specifically I believe that if there's no "refclk" we need the MIPI source clock to be active before we can successfully

[PATCH v3 12/12] drm/panel: panel-simple: Use runtime pm to avoid excessive unprepare / prepare

Unpreparing and re-preparing a panel can be a really heavy operation. Panels datasheets often specify something on the order of 500ms as the delay you should insert after turning off the panel before turning it on again. In addition, turning on a panel can have delays on the order of 100ms - 200ms

[PATCH v3 00/12] drm: Fix EDID reading on ti-sn65dsi86

The primary goal of this series is to try to properly fix EDID reading for eDP panels using the ti-sn65dsi86 bridge. Previously we had a patch that added EDID reading but it turned out not to work at bootup. This caused some extra churn at bootup as we tried (and failed) to read the EDID several

[PATCH v3 01/12] drm/bridge: Fix the stop condition of drm_bridge_chain_pre_enable()

The drm_bridge_chain_pre_enable() is not the proper opposite of drm_bridge_chain_post_disable(). It continues along the chain to _before_ the starting bridge. Let's fix that. Fixes: 05193dc38197 ("drm/bridge: Make the bridge chain a double-linked list") Signed-off-by: Douglas Anderson

[PATCH v3 03/12] drm/bridge: ti-sn65dsi86: Remove incorrectly tagged kerneldoc comment

A random comment inside a function had "/**" in front of it. That doesn't make sense. Remove. Signed-off-by: Douglas Anderson Reviewed-by: Andrzej Hajda --- (no changes since v1) drivers/gpu/drm/bridge/ti-sn65dsi86.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH v3 11/12] drm/bridge: ti-sn65dsi86: Print an error if we fallback to panel modes

Now that we can properly read the EDID for modes there should be no reason to fallback to the fixed modes that our downstream panel driver provides us. Let's make that clear by: - Putting an error message in the logs if we fall back. - Putting a comment in saying what's going on. Signed-off-by:

Re: [PATCH] drm/amdgpu: Fix a potential sdma invalid access

Hi Christian, On 2021/4/3 0:25, Christian König wrote: Hi Qu, Am 02.04.21 um 05:18 schrieb Qu Huang: Before dma_resv_lock(bo->base.resv, NULL) in amdgpu_bo_release_notify(), the bo->base.resv lock may be held by ttm_mem_evict_first(), That can't happen since when bo_release_notify is called

Re: [PATCH] drm/msm/a6xx: fix for kernels without CONFIG_NVMEM

On 4/2/2021 3:19 AM, Rob Clark wrote: On Thu, Apr 1, 2021 at 2:03 PM Dmitry Baryshkov wrote: On Thu, 1 Apr 2021 at 23:09, Rob Clark wrote: On Mon, Feb 22, 2021 at 8:06 AM Rob Clark wrote: On Mon, Feb 22, 2021 at 7:45 AM Akhil P Oommen wrote: On 2/19/2021 9:30 PM, Rob Clark wrote: On

[PATCH v2] drm/msm: Drop mm_lock in scan loop

From: Rob Clark lock_stat + mmm_donut[1] say that this reduces contention on mm_lock significantly (~350x lower waittime-max, and ~100x lower waittime-avg) [1] https://chromium.googlesource.com/chromiumos/platform/microbenchmarks/+/refs/heads/main/mmm_donut.py Signed-off-by: Rob Clark ---

Re: [PATCH] drm/amdgpu: Fix a potential sdma invalid access

Hi Christian, On 2021/4/3 0:25, Christian König wrote: Hi Qu, Am 02.04.21 um 05:18 schrieb Qu Huang: Before dma_resv_lock(bo->base.resv, NULL) in amdgpu_bo_release_notify(), the bo->base.resv lock may be held by ttm_mem_evict_first(), That can't happen since when bo_release_notify is called

Re: [Freedreno] [PATCH 1/2] drm/msm: Fix a5xx/a6xx timestamps

On Wed, Mar 24, 2021 at 06:23:52PM -0700, Rob Clark wrote: > From: Rob Clark > > They were reading a counter that was configured to ALWAYS_COUNT (ie. > cycles that the GPU is doing something) rather than ALWAYS_ON. This > isn't the thing that userspace is looking for. Acked-by: Jordan Crouse

Re: [v1] drm/msm/disp/dpu1: program 3d_merge only if block is attached

On Fri, Apr 2, 2021 at 4:55 AM Kalyan Thota wrote: > > Update the 3d merge as active in the data path only if > the hw block is selected in the configuration. > > Reported-by: Stephen Boyd Thanks, I've added: Fixes: 73bfb790ac78 ("msm:disp:dpu1: setup display datapath for SC7180 target") >

[PATCH] drm/amdgpu: fix semicolon.cocci warnings

From: kernel test robot Remove unneeded semicolon. Generated by: scripts/coccinelle/misc/semicolon.cocci Fixes: 37439a51ff17 ("drm/amdgpu: Add mode2 reset support for aldebaran") CC: Lijo Lazar Reported-by: kernel test robot Signed-off-by: kernel test robot Signed-off-by: Julia Lawall ---

Re: [PATCH 2/2] drm/virtio: Include modifier as part of set_scanout_blob

On Fri, Apr 2, 2021 at 12:56 AM Zhang, Tina wrote: > > > > -Original Message- > > From: dri-devel On Behalf Of > Gerd > > Hoffmann > > Sent: Wednesday, March 31, 2021 4:00 PM > > To: Kasireddy, Vivek > > Cc: dri-devel@lists.freedesktop.org; gurchetansi...@chromium.org > > Subject: Re:

Re: [PATCH v5 03/21] gpu: host1x: Show number of pending waiters in debugfs

02.04.2021 00:19, Michał Mirosław пишет: > On Fri, Mar 26, 2021 at 04:34:13PM +0200, Mikko Perttunen wrote: >> On 3/23/21 12:16 PM, Thierry Reding wrote: >>> On Mon, Jan 11, 2021 at 03:00:01PM +0200, Mikko Perttunen wrote: Show the number of pending waiters in the debugfs status file.

Re: [pull] amdgpu, radeon, ttm, sched drm-next-5.13

Hey Alex, the TTM and scheduler changes should already be in the drm-misc-next branch (not 100% sure about the TTM patch, need to double check next week). Could that cause problems when both are merged into drm-next? Thanks, Christian. Am 02.04.21 um 00:29 schrieb Alex Deucher: Hi Dave,

Re: [PATCH RFC 0/3] Adds support to allow the bitstream configuration from pre-allocated dma-buffer

Please add to this patch cover letter what you want to discuss. Got this new feature, not sure about ... Tom On 4/2/21 2:09 AM, Nava kishore Manne wrote: > Nava kishore Manne (3): > fpga: region: Add fpga-region property 'fpga-config-from-dmabuf' > fpga: support loading from a pre-allocated

Re: [Freedreno] [PATCH 2/2] drm/msm: Add param for userspace to query suspend count

On Wed, Mar 24, 2021 at 06:23:53PM -0700, Rob Clark wrote: > From: Rob Clark > > Performance counts, and ALWAYS_ON counters used for capturing GPU > timestamps, lose their state across suspend/resume cycles. Userspace > tooling for performance monitoring needs to be aware of this. For >

Re: [PATCH] zero-fill colormap in drivers/video/fbdev/core/fbcmap.c

On Wed, Mar 31, 2021 at 11:07:19PM +0100, Phillip Potter wrote: > Use kzalloc() rather than kmalloc() for the dynamically allocated parts > of the colormap in fb_alloc_cmap_gfp, to prevent a leak of random kernel > data to userspace under certain circumstances. > > Fixes a KMSAN-found infoleak

Re: [PATCH] drm/amdgpu: Fix a potential sdma invalid access

Hi Qu, Am 02.04.21 um 05:18 schrieb Qu Huang: Before dma_resv_lock(bo->base.resv, NULL) in amdgpu_bo_release_notify(), the bo->base.resv lock may be held by ttm_mem_evict_first(), That can't happen since when bo_release_notify is called the BO has not more references and is therefore

[pull] drm/msm: drm-msm-fixes-2021-04-02 for v5.12-rc6

Hi Dave & Daniel, A couple more small fixes for v5.12 The following changes since commit 627dc55c273dab308303a5217bd3e767d7083ddb: drm/msm/disp/dpu1: icc path needs to be set before dpu runtime resume (2021-03-22 18:52:34 -0700) are available in the Git repository at: