Re: [RFC v2 02/22] drm: Add Enhanced Gamma and color lut range attributes

On Wed, 10 Nov 2021 10:17:59 -0500 Harry Wentland wrote: > On 2021-11-10 06:55, Ville Syrjälä wrote: > > On Wed, Nov 10, 2021 at 10:49:24AM +0200, Pekka Paalanen wrote: > >> On Wed, 10 Nov 2021 00:02:16 +0200 > >> Ville Syrjälä wrote: > >> > >>> On Tue, Nov 09, 2021 at 03:47:58PM -0500, Harr

Re: printk deadlock due to double lock attempt on current CPU's runqueue

On 2021-11-10, Sultan Alsawaf wrote: > On Wed, Nov 10, 2021 at 11:13:37AM +0106, John Ogness wrote: >> Even after we introduce kthread printers, there will still be >> situations where direct printing is used: booting (before kthreads >> exist) and shutdown/suspend/crash situations, when the kthre

Re: [PATCH v2 0/8] Add new formats support to vkms

On Wed, 10 Nov 2021 14:32:26 -0300 Igor Torrente wrote: > Hi Pekka, > > On Tue, Nov 9, 2021 at 6:32 AM Pekka Paalanen wrote: > > > > On Tue, 26 Oct 2021 08:34:00 -0300 > > Igor Torrente wrote: > > > > > Summary > > > === > > > This series of patches refactor some vkms components in order

[PULL] drm-misc-fixes

Hi Dave and Daniel, here's this week's PR for drm-misc-fixes. I'm sending it as Maarten and Maxime are both on vacation this week. Best regards Thomas drm-misc-fixes-2021-11-11: * dma-buf: name_lock fixes * prime: Keep object ref during mmap * nouveau: Fix a refcount issue; Fix device removal

[PATCH] fbdev: Prevent probing generic drivers if a FB is already registered

The efifb and simplefb drivers just render to a pre-allocated frame buffer and rely on the display hardware being initialized before the kernel boots. But if another driver already probed correctly and registered a fbdev, the generic drivers shouldn't be probed since an actual driver for the displ

Re: [REGRESSION]: drivers/firmware: move x86 Generic System Framebuffers support

On 11/11/21 08:31, Javier Martinez Canillas wrote: [snip] >>> And for each check /proc/fb, the kernel boot log, and if Suspend-to-RAM >>> works. >>> >>> If the explanation above is correct, then I would expect (1) and (2) to >>> work and >>> (3) to also fail. >>> > > Your testing confirms my a

Re: printk deadlock due to double lock attempt on current CPU's runqueue

On Wed 2021-11-10 10:37:26, Daniel Vetter wrote: > On Tue, Nov 09, 2021 at 10:38:47PM +0100, Peter Zijlstra wrote: > > On Tue, Nov 09, 2021 at 12:06:48PM -0800, Sultan Alsawaf wrote: > > > Hi, > > > > > > I encountered a printk deadlock on 5.13 which appears to still affect the > > > latest > > >

Re: [PATCH v2 6/8] drm: vkms: Refactor the plane composer to accept new formats

On Wed, 10 Nov 2021 13:56:54 -0300 Igor Torrente wrote: > On Tue, Nov 9, 2021 at 8:40 AM Pekka Paalanen wrote: > > > > Hi Igor, > > > > again, that is a really nice speed-up. Unfortunately, I find the code > > rather messy and hard to follow. I hope my comments below help with > > re-designing i

[PATCH] drm/panel: panel-simple: Fix proper bpc for AM-1280800N3TZQW-T00H

AM-1280800N3TZQW-T00H panel support 8 bpc not 6 bpc as per recent testing in i.MX8MM platform. Fix it. Fixes: bca684e69c4c ("drm/panel: simple: Add AM-1280800N3TZQW-T00H") Signed-off-by: Jagan Teki --- drivers/gpu/drm/panel/panel-simple.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) d

Re: [PATCH] drm: document DRM_IOCTL_MODE_GETFB2

On Tue, 9 Nov 2021 10:24:33 +0100 Daniel Vetter wrote: > On Tue, Nov 09, 2021 at 08:56:10AM +, Simon Ser wrote: > > There are a few details specific to the GETFB2 IOCTL. > > > > It's not immediately clear how user-space should check for the > > number of planes. Suggest using the pitches fie

Re: [PATCH] fbdev: Prevent probing generic drivers if a FB is already registered

On Thu, Nov 11, 2021 at 10:20:53AM +0100, Javier Martinez Canillas wrote: > The efifb and simplefb drivers just render to a pre-allocated frame buffer > and rely on the display hardware being initialized before the kernel boots. > > But if another driver already probed correctly and registered a f

[PATCH] drm/amd/display: clean up some inconsistent indenting

Eliminate the follow smatch warning: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_debugfs.c:2245 dp_dsc_slice_bpg_offset_read() warn: inconsistent indenting. drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_debugfs.c:2044 dp_dsc_pic_width_read() warn: inconsistent indenting.

Re: [PATCH] fbdev: Prevent probing generic drivers if a FB is already registered

On Thu, Nov 11, 2021 at 10:58:14AM +0100, Thorsten Leemhuis wrote: > On 11.11.21 10:20, Javier Martinez Canillas wrote: > > The efifb and simplefb drivers just render to a pre-allocated frame buffer > > and rely on the display hardware being initialized before the kernel boots. > > > > But if anot

[PATCH] drm/amd/display: Clean up some inconsistent indenting

Eliminate the follow smatch warning: drivers/gpu/drm/amd/amdgpu/../display/dmub/src/dmub_srv.c:622 dmub_srv_cmd_execute() warn: inconsistent indenting. Reported-by: Abaci Robot Signed-off-by: Jiapeng Chong --- drivers/gpu/drm/amd/display/dmub/src/dmub_srv.c | 2 +- 1 file changed, 1 insertion(

Re: [PATCH] drm/amd/display: clean up some inconsistent indenting

Am 11.11.21 um 10:58 schrieb Jiapeng Chong: Eliminate the follow smatch warning: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_debugfs.c:2245 dp_dsc_slice_bpg_offset_read() warn: inconsistent indenting. drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_debugfs.c:2044 dp_dsc_

Re: [PATCH] drm/amd/display: Clean up some inconsistent indenting

Am 11.11.21 um 11:03 schrieb Jiapeng Chong: Eliminate the follow smatch warning: drivers/gpu/drm/amd/amdgpu/../display/dmub/src/dmub_srv.c:622 dmub_srv_cmd_execute() warn: inconsistent indenting. Reported-by: Abaci Robot Signed-off-by: Jiapeng Chong Reviewed-by: Christian König ---

[PATCH] drm: pre-fill getfb2 modifier array with INVALID

User-space shouldn't look up the modifier array when the modifier flag is missing, but at the moment no docs make this clear (working on it). Right now the modifier array is pre-filled with zeroes, aka. LINEAR. Instead, pre-fill with INVALID to avoid footguns. This is a uAPI change, but OTOH any u

[RFC PATCH v2 0/3] arm64: imx8mm: Add MIPI DSI support

This series support MIPI DSI on i.MX8MM. The DSIM bridge still need to work to make it compatible for exynos drm dsi hardware block. This series work directly on to of linux-next with recent dispmix-blk-ctrl changes. Tested on i.Core MX8M Mini SoM with EDIMM2.2 and CTOUCH2 Carrier boards. Requi

[RFC PATCH v2 1/3] arm64: dts: imx8mm: Add eLCDIF node support

Add eLCDIF controller node for i.MX8MM. Signed-off-by: Jagan Teki --- arch/arm64/boot/dts/freescale/imx8mm.dtsi | 19 +++ 1 file changed, 19 insertions(+) diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi b/arch/arm64/boot/dts/freescale/imx8mm.dtsi index c2f3f118f82e..caeb

[RFC PATCH v2 2/3] arm64: dts: imx8mm: Add MIPI DSI pipeline

Add MIPI DSI pipeline for i.MX8MM. Video pipeline start from eLCDIF to MIPI DSI and respective Panel or Bridge on the backend side. Add support for it. Signed-off-by: Jagan Teki --- arch/arm64/boot/dts/freescale/imx8mm.dtsi | 55 +++ 1 file changed, 55 insertions(+) diff -

[RFC PATCH v2 3/3] arm64: dts: imx8mm-icore: Enable LVDS panel for EDIMM2.2

Enable LVDS Panel for Engicam i.Core MX8MMini EDIMM2.2 board. Signed-off-by: Jagan Teki --- .../freescale/imx8mm-icore-mx8mm-edimm2.2.dts | 85 +++ 1 file changed, 85 insertions(+) diff --git a/arch/arm64/boot/dts/freescale/imx8mm-icore-mx8mm-edimm2.2.dts b/arch/arm64/boot/dts/

Re: [RFC] arm64: dts: imx8mm: Add MIPI and LCDIF nodes

On Wed, Nov 10, 2021 at 11:58 PM Jagan Teki wrote: > > On Wed, Nov 10, 2021 at 2:24 AM Tim Harvey wrote: > > > > On Tue, Nov 9, 2021 at 12:39 PM Marek Vasut wrote: > > > > > > On 11/9/21 8:35 PM, Adam Ford wrote: > > > > > > [...] > > > > > > >> diff --git a/arch/arm64/boot/dts/freescale/imx8mm.

Re: [RFC PATCH v2 2/3] arm64: dts: imx8mm: Add MIPI DSI pipeline

On 11/11/21 11:14 AM, Jagan Teki wrote: [...] + dsi: dsi@32e1 { + compatible = "fsl,imx8mm-mipi-dsim"; + reg = <0x32e1 0x400>; + clocks = <&clk IMX8MM_CLK_DSI_CORE>, +

Re: [REGRESSION]: drivers/firmware: move x86 Generic System Framebuffers support

On Thu, Nov 11, 2021 at 10:24:56AM +0100, Javier Martinez Canillas wrote: > On 11/11/21 08:31, Javier Martinez Canillas wrote: > > [snip] > > >>> And for each check /proc/fb, the kernel boot log, and if Suspend-to-RAM > >>> works. > >>> > >>> If the explanation above is correct, then I would exp

Re: [PATCH] drm: pre-fill getfb2 modifier array with INVALID

On Thu, 11 Nov 2021 10:10:54 + Simon Ser wrote: > User-space shouldn't look up the modifier array when the modifier > flag is missing, but at the moment no docs make this clear (working > on it). Right now the modifier array is pre-filled with zeroes, aka. > LINEAR. Instead, pre-fill with INV

[PATCH v2] fbdev: Prevent probing generic drivers if a FB is already registered

The efifb and simplefb drivers just render to a pre-allocated frame buffer and rely on the display hardware being initialized before the kernel boots. But if another driver already probed correctly and registered a fbdev, the generic drivers shouldn't be probed since an actual driver for the displ

Re: [REGRESSION]: drivers/firmware: move x86 Generic System Framebuffers support

Hello Ilya, On 11/11/21 11:52, Ilya Trukhanov wrote: > On Thu, Nov 11, 2021 at 10:24:56AM +0100, Javier Martinez Canillas wrote: >> On 11/11/21 08:31, Javier Martinez Canillas wrote: >> >> [snip] >> > And for each check /proc/fb, the kernel boot log, and if Suspend-to-RAM > works. > >

Re: [PATCH] fbdev: Prevent probing generic drivers if a FB is already registered

Hello Daniel, On 11/11/21 10:54, Daniel Vetter wrote: > On Thu, Nov 11, 2021 at 10:20:53AM +0100, Javier Martinez Canillas wrote: >> The efifb and simplefb drivers just render to a pre-allocated frame buffer >> and rely on the display hardware being initialized before the kernel boots. >> >> But i

Re: [Intel-gfx] [PATCH 02/28] drm/i915: use new iterator in i915_gem_object_wait_reservation

Am 01.11.21 um 10:41 schrieb Tvrtko Ursulin: On 28/10/2021 16:30, Daniel Vetter wrote: On Thu, Oct 28, 2021 at 10:41:38AM +0200, Christian König wrote: Am 21.10.21 um 13:13 schrieb Tvrtko Ursulin: On 21/10/2021 12:06, Maarten Lankhorst wrote: Op 21-10-2021 om 12:38 schreef Christian König:

Re: [PATCH v2] fbdev: Prevent probing generic drivers if a FB is already registered

On Thu, Nov 11, 2021 at 12:11:20PM +0100, Javier Martinez Canillas wrote: > The efifb and simplefb drivers just render to a pre-allocated frame buffer > and rely on the display hardware being initialized before the kernel boots. > > But if another driver already probed correctly and registered a f

Re: [PATCH] drm: pre-fill getfb2 modifier array with INVALID

On Thu, 11 Nov 2021 at 10:11, Simon Ser wrote: > User-space shouldn't look up the modifier array when the modifier > flag is missing, but at the moment no docs make this clear (working > on it). Right now the modifier array is pre-filled with zeroes, aka. > LINEAR. Instead, pre-fill with INVALID t

Re: [PATCH] drm: document DRM_IOCTL_MODE_GETFB2

On Tue, 9 Nov 2021 at 08:56, Simon Ser wrote: > There are a few details specific to the GETFB2 IOCTL. > > It's not immediately clear how user-space should check for the > number of planes. Suggest using the pitches field. In fairness it is perfectly clear, it's just that I never considered callin

[PATCH v3] fbdev: Prevent probing generic drivers if a FB is already registered

The efifb and simplefb drivers just render to a pre-allocated frame buffer and rely on the display hardware being initialized before the kernel boots. But if another driver already probed correctly and registered a fbdev, the generic drivers shouldn't be probed since an actual driver for the displ

Re: [PATCH v3] fbdev: Prevent probing generic drivers if a FB is already registered

On Thu, Nov 11, 2021 at 12:57:57PM +0100, Javier Martinez Canillas wrote: > The efifb and simplefb drivers just render to a pre-allocated frame buffer > and rely on the display hardware being initialized before the kernel boots. > > But if another driver already probed correctly and registered a f

Re: [Intel-gfx] [PATCH 1/1] drm/i915/rpm: Enable runtime pm autosuspend by default

On Wed, Nov 10, 2021 at 05:24:22PM -0500, Rodrigo Vivi wrote: > On Wed, Nov 10, 2021 at 01:46:46PM +0200, Ville Syrjälä wrote: > > On Wed, Nov 10, 2021 at 10:59:26AM +0530, Tilak Tangudu wrote: > > > Enable runtime pm autosuspend by default for gen12 and > > > later versions. > > > > > > Signed-of

[PATCH v2 0/6] drm/i915/ttm: Async migration

This patch series deals with async migration and async vram management. It still leaves an important part out, which is async unbinding which will reduce latency further, at least when trying to migrate already active objects. Patches 1/6 and 2/6 deal with accessing and waiting for the TTM moving

[PATCH v2 1/6] drm/i915: Add functions to set/get moving fence

From: Maarten Lankhorst We want to get rid of i915_vma tracking to simplify the code and lifetimes. Add a way to set/put the moving fence, in preparation for removing the tracking. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/gem/i915_gem_object.c | 37 ++ driv

[PATCH v2 2/6] drm/i915: Add support for asynchronous moving fence waiting

From: Maarten Lankhorst For now, we will only allow async migration when TTM is used, so the paths we care about are related to TTM. The mmap path is handled by having the fence in ttm_bo->moving, when pinning, the binding only becomes available after the moving fence is signaled, and pinning a

[PATCH v2 3/6] drm/i915/ttm: Move the i915_gem_obj_copy_ttm() function

Move the i915_gem_obj_copy_ttm() function to i915_gem_ttm_move.h. This will help keep a number of functions static when introducing async moves. Signed-off-by: Thomas Hellström --- drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 47 --- drivers/gpu/drm/i915/gem/i915_gem_ttm.h |

[PATCH v2 4/6] drm/i915/ttm: Break refcounting loops at device region unref time

There is an interesting refcounting loop: struct intel_memory_region has a struct ttm_resource_manager, ttm_resource_manager->move may hold a reference to i915_request, i915_request may hold a reference to intel_context, intel_context may hold a reference to drm_i915_gem_object, drm_i915_gem_object

Re: [PATCH] drm: pre-fill getfb2 modifier array with INVALID

On Thu, Nov 11, 2021 at 10:10:54AM +, Simon Ser wrote: > User-space shouldn't look up the modifier array when the modifier > flag is missing, but at the moment no docs make this clear (working > on it). Right now the modifier array is pre-filled with zeroes, aka. > LINEAR. Instead, pre-fill wit

[PATCH v2 6/6] drm/i915/ttm: Update i915_gem_obj_copy_ttm() to be asynchronous

Update the copy function i915_gem_obj_copy_ttm() to be asynchronous for future users and update the only current user to sync the objects as needed after this function. Signed-off-by: Thomas Hellström --- drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 40 ++-- drivers/gpu/drm/i91

[PATCH v2 5/6] drm/i915/ttm: Implement asynchronous TTM moves

Don't wait sync while migrating, but rather make the GPU blit await the dependencies and add a moving fence to the object. This also enables asynchronous VRAM management in that on eviction, rather than waiting for the moving fence to expire before freeing VRAM, it is freed immediately and the fen

[PATCH v3] drm/i915: Skip error capture when wedged on init

From: Tvrtko Ursulin Trying to capture uninitialised engines when we wedged on init ends in tears. Skip that together with uC capture, since failure to initialise the latter can actually be one of the reasons for wedging on init. v2: * Use i915_disable_error_state when wedging on init/fini. v3

Re: [igt-dev] [RFC PATCH 0/1] drm: selftest: Convert to KUnit

On Wed, Nov 10, 2021 at 09:34:52PM -0300, André Almeida wrote: > Hi, > > This RFC is a preview of the progress we made in the KUnit hackathon[0]. > This patch, made by Maíra and Arthur, converts the damage helper test > from the original DRM selftest framework to use the KUnit framework. > > [0]

Re: [PATCH v2 6/8] drm: vkms: Refactor the plane composer to accept new formats

Hi Pekka, On Thu, Nov 11, 2021 at 6:33 AM Pekka Paalanen wrote: > > On Wed, 10 Nov 2021 13:56:54 -0300 > Igor Torrente wrote: > > > On Tue, Nov 9, 2021 at 8:40 AM Pekka Paalanen wrote: > > > > > > Hi Igor, > > > > > > again, that is a really nice speed-up. Unfortunately, I find the code > > > r

Re: [PATCH v2 6/8] drm: vkms: Refactor the plane composer to accept new formats

On Thu, 11 Nov 2021 11:07:21 -0300 Igor Torrente wrote: > Hi Pekka, > > On Thu, Nov 11, 2021 at 6:33 AM Pekka Paalanen wrote: > > > > On Wed, 10 Nov 2021 13:56:54 -0300 > > Igor Torrente wrote: > > > > > On Tue, Nov 9, 2021 at 8:40 AM Pekka Paalanen > > > wrote: > > > > > > > > Hi Igor,

Re: [PATCH v6 3/8] dt-bindings: display: Add ingenic, jz4780-dw-hdmi DT Schema

On Wed, 10 Nov 2021 20:43:28 +0100, H. Nikolaus Schaller wrote: > From: Sam Ravnborg > > Add DT bindings for the hdmi driver for the Ingenic JZ4780 SoC. > Based on .txt binding from Zubair Lutfullah Kakakhel > > We also add add generic ddc-i2c-bus to synopsys,dw-hdmi.yaml > > Signed-off-by: Sam

Re: [PATCH] drm/i915: Use per device iommu check

On 10/11/2021 12:35, Lu Baolu wrote: On 2021/11/10 20:08, Tvrtko Ursulin wrote: On 10/11/2021 12:04, Lu Baolu wrote: On 2021/11/10 17:30, Tvrtko Ursulin wrote: On 10/11/2021 07:12, Lu Baolu wrote: Hi Tvrtko, On 2021/11/9 20:17, Tvrtko Ursulin wrote: From: Tvrtko Ursulin On igfx + dgfx

Re: [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range struct for HDR planes

On 2021-09-06 17:38, Uma Shankar wrote: > Define the structure with XE_LPD degamma lut ranges. HDR and SDR > planes have different capabilities, implemented respective > structure for the HDR planes. > > Signed-off-by: Uma Shankar > --- > drivers/gpu/drm/i915/display/intel_color.c | 52 ++

Re: [PATCH] drm/i915: Use per device iommu check

On 10/11/2021 14:37, Robin Murphy wrote: On 2021-11-10 14:11, Tvrtko Ursulin wrote: On 10/11/2021 12:35, Lu Baolu wrote: On 2021/11/10 20:08, Tvrtko Ursulin wrote: On 10/11/2021 12:04, Lu Baolu wrote: On 2021/11/10 17:30, Tvrtko Ursulin wrote: On 10/11/2021 07:12, Lu Baolu wrote: Hi Tv

Re: [PATCH v4 07/13] drm/msm: Track "seqno" fences by idr

On 11/10/2021 10:25 PM, Rob Clark wrote: On Wed, Nov 10, 2021 at 7:28 AM Akhil P Oommen wrote: On 7/28/2021 6:36 AM, Rob Clark wrote: From: Rob Clark Previously the (non-fd) fence returned from submit ioctl was a raw seqno, which is scoped to the ring. But from UABI standpoint, the ioctls

Re: [PATCH 2/2] drm/sched: serialize job_timeout and scheduler

On 2021-11-10 8:24 a.m., Daniel Vetter wrote: On Wed, Nov 10, 2021 at 11:09:50AM +0100, Christian König wrote: Am 10.11.21 um 10:50 schrieb Daniel Vetter: On Tue, Nov 09, 2021 at 08:17:01AM -0800, Rob Clark wrote: On Tue, Nov 9, 2021 at 1:07 AM Daniel Vetter wrote: On Mon, Nov 08, 2021 at

[Bug 205089] amdgpu : drm:amdgpu_cs_ioctl : Failed to initialize parser -125

https://bugzilla.kernel.org/show_bug.cgi?id=205089 Joey Espinosa (jlouis.espin...@gmail.com) changed: What|Removed |Added CC||jlouis.espin..

[Bug 205089] amdgpu : drm:amdgpu_cs_ioctl : Failed to initialize parser -125

https://bugzilla.kernel.org/show_bug.cgi?id=205089 --- Comment #22 from Joey Espinosa (jlouis.espin...@gmail.com) --- Kernel version would help too probably :-/ 5.14.16-301.fc35.x86_64 -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the as

Re: [PATCH v5 1/2] drm/bridge: parade-ps8640: Enable runtime power management

Hi, On Thu, Oct 28, 2021 at 12:39 PM Doug Anderson wrote: > > Hi, > > On Thu, Oct 28, 2021 at 11:02 AM Philip Chen wrote: > > > > Add "Sam Ravnborg " to cc list for vis. > > Remove "Andrzej Hajda " from cc list as the > > address can't be found. > > Looking at >

Re: [RFC PATCH v2 2/3] arm64: dts: imx8mm: Add MIPI DSI pipeline

On Thu, Nov 11, 2021 at 3:51 PM Marek Vasut wrote: > > On 11/11/21 11:14 AM, Jagan Teki wrote: > > [...] > > > + dsi: dsi@32e1 { > > + compatible = "fsl,imx8mm-mipi-dsim"; > > + reg = <0x32e1 0x400>; > > +

Re: [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range struct for HDR planes

On Thu, Nov 11, 2021 at 10:17:17AM -0500, Harry Wentland wrote: > > > On 2021-09-06 17:38, Uma Shankar wrote: > > Define the structure with XE_LPD degamma lut ranges. HDR and SDR > > planes have different capabilities, implemented respective > > structure for the HDR planes. > > > > Signed-off-b

Re: [PATCH v4] drm/ttm: Clarify that the TTM_PL_SYSTEM is under TTMs control

On Wed, 2021-11-10 at 09:50 -0500, Zack Rusin wrote: > TTM takes full control over TTM_PL_SYSTEM placed buffers. This makes > driver internal usage of TTM_PL_SYSTEM prone to errors because it > requires the drivers to manually handle all interactions between TTM > which can swap out those buffers w

Re: [PATCH 2/5] drm/msm: Drop priv->lastctx

On 11/9/2021 11:41 PM, Rob Clark wrote: From: Rob Clark cur_ctx_seqno already does the same thing, but handles the edge cases where a refcnt'd context can live after lastclose. So let's not have two ways to do the same thing. Signed-off-by: Rob Clark --- drivers/gpu/drm/msm/adreno/a2xx_gpu

Re: [Intel-gfx] [PATCH] drm/i915/execlists: Weak parallel submission support for execlists

On Mon, Nov 01, 2021 at 10:35:09AM +, Tvrtko Ursulin wrote: > > On 27/10/2021 21:10, Matthew Brost wrote: > > On Wed, Oct 27, 2021 at 01:04:49PM -0700, John Harrison wrote: > > > On 10/27/2021 12:17, Matthew Brost wrote: > > > > On Tue, Oct 26, 2021 at 02:58:00PM -0700, John Harrison wrote: >

Re: [PATCH 4/5] drm/msm: Handle fence rollover

On 11/9/2021 11:41 PM, Rob Clark wrote: From: Rob Clark Add some helpers for fence comparision, which handle rollover properly, and stop open coding fence seqno comparisions. Signed-off-by: Rob Clark --- drivers/gpu/drm/msm/msm_fence.h | 12 drivers/gpu/drm/msm/msm_gpu.c |

Re: [PATCH 5/5] drm/msm: Add debugfs to disable hw err handling

On 11/9/2021 11:41 PM, Rob Clark wrote: From: Rob Clark Add a debugfs interface to ignore hw error irqs, in order to force fallback to sw hangcheck mechanism. Because the hw error detection is pretty good on newer gens, we need this for igt tests to test the sw hang detection. Signed-off-by:

Re: [Freedreno] [PATCH v4 07/13] drm/msm: Track "seqno" fences by idr

On Thu, Nov 11, 2021 at 7:54 AM Akhil P Oommen wrote: > > On 11/10/2021 10:25 PM, Rob Clark wrote: > > On Wed, Nov 10, 2021 at 7:28 AM Akhil P Oommen > > wrote: > >> > >> On 7/28/2021 6:36 AM, Rob Clark wrote: > >>> From: Rob Clark > >>> > >>> Previously the (non-fd) fence returned from submit

Re: [PATCH 3/3] drm/i915/dg2: Program recommended HW settings

Reviewed-by: Clint Taylor -Clint On 11/2/21 3:25 PM, Matt Roper wrote: The bspec's performance guide suggests programming specific values into a few registers for optimal performance. Although these aren't workarounds, it's easiest to handle them inside the GT workaround functions (which wil

Re: [PATCH] drm/v3d: pass null pointers using NULL

On 11/10, Colin Ian King wrote: > There are a couple of calls that are passing null pointers as > integer zeros rather than NULL. Fix this by using NULL instead. > > Fixes: 07c2a41658c4 ("drm/v3d: alloc and init job in one shot") > Signed-off-by: Colin Ian King > --- > drivers/gpu/drm/v3d/v3d_ge

[PATCH 0/2] drm/msm: wait_fence fixes

From: Rob Clark A couple of wait_fence related fixes. Rob Clark (2): drm/msm: Fix wait_fence submitqueue leak drm/msm: Restore error return on invalid fence drivers/gpu/drm/msm/msm_drv.c| 49 ++-- drivers/gpu/drm/msm/msm_gem_submit.c | 1 + drivers/gpu/drm/

[PATCH 1/2] drm/msm: Fix wait_fence submitqueue leak

From: Rob Clark We weren't dropping the submitqueue reference in all paths. In particular, when the fence has already been signalled. Split out a helper to simplify handling this in the various different return paths. Fixes: a61acbbe9cf8 ("drm/msm: Track "seqno" fences by idr") Signed-off-by: R

[PATCH 2/2] drm/msm: Restore error return on invalid fence

From: Rob Clark When converting to use an idr to map userspace fence seqno values back to a dma_fence, we lost the error return when userspace passes seqno that is larger than the last submitted fence. Restore this check. Reported-by: Akhil P Oommen Fixes: a61acbbe9cf8 ("drm/msm: Track "seqno"

Re: [Intel-gfx] [PATCH 1/1] drm/i915/rpm: Enable runtime pm autosuspend by default

On Thu, 2021-11-11 at 14:42 +0200, Ville Syrjälä wrote: > On Wed, Nov 10, 2021 at 05:24:22PM -0500, Rodrigo Vivi wrote: > > On Wed, Nov 10, 2021 at 01:46:46PM +0200, Ville Syrjälä wrote: > > > On Wed, Nov 10, 2021 at 10:59:26AM +0530, Tilak Tangudu wrote: > > > > Enable runtime pm autosuspend by de

Re: [Intel-gfx] [PATCH] drm/i915: Drop stealing of bits from i915_sw_fence function pointer

Hey Matt, apologies for the delay, went thru all the code, LGTM. Reviewed-by: Alan Previn P.S. - As a side note, would be interesting to replay the original reason behind the overloading of the func ptr bits to begin with... to see what the initial intention was. ...alan On Wed, 2021-09-22 a

RE: [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range struct for HDR planes

> -Original Message- > From: Ville Syrjälä > Sent: Thursday, November 11, 2021 10:13 PM > To: Harry Wentland > Cc: Shankar, Uma ; intel-...@lists.freedesktop.org; > dri- > de...@lists.freedesktop.org; ppaala...@gmail.com; brian.star...@arm.com; > sebast...@sebastianwick.net; shashank.

Re: regression with mainline kernel

Hi Linus, On Thu, Nov 11, 2021 at 2:03 PM Sudip Mukherjee wrote: > > Hi Linus, > > My testing has been failing for the last few days. Last good test was > with 6f2b76a4a384 and I started seeing the failure with ce840177930f5 > where boot timeout. > > Last good test - https://openqa.qa.codethink.c

Re: [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range struct for HDR planes

On 2021-11-11 15:42, Shankar, Uma wrote: > > >> -Original Message- >> From: Ville Syrjälä >> Sent: Thursday, November 11, 2021 10:13 PM >> To: Harry Wentland >> Cc: Shankar, Uma ; intel-...@lists.freedesktop.org; >> dri- >> de...@lists.freedesktop.org; ppaala...@gmail.com; brian.sta

Re: [RFC] arm64: dts: imx8mm: Add MIPI and LCDIF nodes

On Thu, Nov 11, 2021 at 2:19 AM Jagan Teki wrote: > > On Wed, Nov 10, 2021 at 11:58 PM Jagan Teki > wrote: > > > > On Wed, Nov 10, 2021 at 2:24 AM Tim Harvey wrote: > > > > > > On Tue, Nov 9, 2021 at 12:39 PM Marek Vasut wrote: > > > > > > > > On 11/9/21 8:35 PM, Adam Ford wrote: > > > > > > >

[PATCH] drm/i915/execlists: Weak parallel submission support for execlists

A weak implementation of parallel submission (multi-bb execbuf IOCTL) for execlists. Doing as little as possible to support this interface for execlists - basically just passing submit fences between each request generated and virtual engines are not allowed. This is on par with what is there for t

[PATCH 1/4] drm/i915/dg2: Add Wa_14010547955

This workaround is documented a bit strangely in the bspec; it's listed as an A0 workaround, but the description clarifies that the workaround is implicitly handled by the hardware and what the driver really needs to do is program a chicken bit to reenable some internal behavior. Signed-off-by: Ma

[PATCH 0/4] i915: Additional DG2 workarounds

We have a few more DG2 workarounds that weren't included in the initial batch. Matt Atwood (1): drm/i915/dg2: extend Wa_1409120013 to DG2 Matt Roper (2): drm/i915/dg2: Add Wa_14010547955 drm/i915/dg2: Add Wa_16011777198 Ramalingam C (1): drm/i915/dg2: Add Wa_16013000631 drivers/gpu/dr

[PATCH 4/4] drm/i915/dg2: extend Wa_1409120013 to DG2

From: Matt Atwood Extend existing workaround 1409120013 to DG2. Cc: José Roberto de Souza Signed-off-by: Matt Atwood Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/intel_pm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers

[PATCH 3/4] drm/i915/dg2: Add Wa_16013000631

From: Ramalingam C Invalidate IC cache through pipe control command as part of the ctx restore flow through indirect ctx pointer Cc: Chris Wilson Signed-off-by: Ramalingam C Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/gt/intel_lrc.c | 5 + 1 file changed, 5 insertions(+) diff --g

[PATCH 2/4] drm/i915/dg2: Add Wa_16011777198

Coarse power gating for render should not be enabled on some DG2 steppings. Bspec: 52698 Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/gt/intel_rc6.c | 15 +++ 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_rc6.c b/drivers/gpu/drm/i

RE: [RFC v2 05/22] drm/i915/xelpd: Define Degamma Lut range struct for HDR planes

> -Original Message- > From: Harry Wentland > Sent: Friday, November 12, 2021 2:41 AM > To: Shankar, Uma ; Ville Syrjälä > > Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; > ppaala...@gmail.com; brian.star...@arm.com; sebast...@sebastianwick.net; > shashank.sha...

[PATCH v10 00/10 RESEND] use DYNAMIC_DEBUG to implement DRM.debug & DRM.trace

Hi Jason, Greg, DRM-everyone, everyone, resend to add more people, after rebasing on master to pick up 306589856399 drm/print: Add deprecation notes to DRM_...() functions This patchset has 3 separate but related parts: 1. DEFINE_DYNAMIC_DEBUG_BITGRPS macro [patch 1/10] Declares DRM.debug st

[PATCH v10 01/10] dyndbg: add DEFINE_DYNAMIC_DEBUG_BITGRPS macro and callbacks

DEFINE_DYNAMIC_DEBUG_BITGRPS(fsname, var, bitmap_desc, bitmap) allows users to create a drm.debug style (bitmap) sysfs interface, mapping each bit to a group of pr_debugs, matching on their formats. This works well when the formats systematically include a prefix string such as ERR|WARN|INFO, etc.

[PATCH v10 02/10] drm: fix doc grammar

allocates and initializes ... Signed-off-by: Jim Cromie --- include/drm/drm_drv.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h index 0cd95953cdf5..4b29261c4537 100644 --- a/include/drm/drm_drv.h +++ b/include/drm/drm_drv.h @@ -

[PATCH v10 03/10] amdgpu: use dyndbg.BITGRPS to control existing pr_debugs

logger_types.h defines many DC_LOG_*() categorized debug wrappers. Most of these already use DRM debug API, so are controllable using drm.debug, but others use a bare pr_debug("$prefix: .."), with 1 of 13 different class-prefixes matching [:uppercase:] Use DEFINE_DYNAMIC_DEBUG_BITGRPS to create a

[PATCH v10 04/10] i915/gvt: trim spaces from pr_debug "gvt: core:" prefixes

Taking embedded spaces out of existing prefixes makes them more easily searchable; simplifying the extra quoting needed otherwise: $> echo format "^gvt: core:" +p >control Dropping the internal spaces means any trailing space in a query will more clearly terminate the prefix being searched for.

[PATCH v10 05/10] i915/gvt: use dyndbg.BITGRPS for existing pr_debugs

The gvt component of this driver has ~120 pr_debugs with formats using one of 9 fixed string prefixes, which are quite similar to those enumerated in DRM debug categories. Following the interface model of drm.debug, add a parameter to map bits to these format prefixes. static struct dyndbg_bitdes

[PATCH v10 08/10] dyndbg: add print-to-tracefs, selftest with it - RFC

Sean Paul proposed, in: https://patchwork.freedesktop.org/series/78133/ drm/trace: Mirror DRM debug logs to tracefs His patchset's objective is to be able to independently steer some of the drm.debug stream to an alternate tracing destination, by splitting drm_debug_enabled() into syslog & trace f

[PATCH v10 06/10] drm_print: add choice to use dynamic debug in drm-debug

drm's debug system writes 10 distinct categories of messages to syslog using a small API[1]: drm_dbg*(10 names), DRM_DEV_DEBUG*(3 names), DRM_DEBUG*(8 names). There are thousands of these callsites, each categorized in this systematized way. These callsites can be enabled at runtime by their cate

[PATCH v10 07/10] drm_print: instrument drm_debug_enabled

Duplicate drm_debug_enabled() code into both "basic" and "dyndbg" ifdef branches. Then add a pr_debug("todo: ...") into the "dyndbg" branch. Then convert the "dyndbg" branch's code to a macro, so that the pr_debug() get its callsite info from the invoking function, instead of from drm_debug_enabl

[PATCH v10 10/10] drm: use DEFINE_DYNAMIC_DEBUG_TRACE_GROUPS in 3 places

add sysfs knobs to enable modules' pr_debug()s ---> tracefs Signed-off-by: Jim Cromie --- drivers/gpu/drm/amd/display/dc/core/dc_debug.c | 8 drivers/gpu/drm/drm_print.c| 13 ++--- drivers/gpu/drm/i915/intel_gvt.c | 15 --- 3 files

[PATCH v10 09/10] dyndbg: create DEFINE_DYNAMIC_DEBUG_LOG|TRACE_GROUPS

With the recent addition of pr_debug to tracefs via +T flag, we now want to add drm.trace; like its model: drm.debug, it maps bits to pr_debug categories, but this one enables/disables writing to tracefs (iff CONFIG_TRACING). Do this by: 1. add flags to dyndbg_bitmap_param, holds "p" or "T" to wo

[PATCH] drm/msm: Make a6xx_gpu_set_freq() static

From: Rob Clark Reported-by: kernel test robot Signed-off-by: Rob Clark --- drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c index 8a2af3a27e33..dcde5eff931d

[PATCH] drm/msm: Demote debug message

From: Rob Clark Mesa attempts to allocate a cached-coherent buffer in order to determine if cached-coherent is supported. Resulting in seeing this error message once per process with newer mesa. But no reason for this to be more than a debug msg. Signed-off-by: Rob Clark --- drivers/gpu/drm/

Re: [PATCH v7 20/20] drm/mediatek: add mediatek-drm of vdosys1 support for MT8195

Hi, Nancy: Nancy.Lin 於 2021年10月29日 週五 下午3:52寫道： > > Add driver data of mt8195 vdosys1 to mediatek-drm and the sub driver. > > Signed-off-by: Nancy.Lin > --- > drivers/gpu/drm/mediatek/mtk_disp_merge.c | 4 ++ > drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 13 ++--- > drivers/gpu/drm/mediate

Re: [RFC PATCH v2 0/3] arm64: imx8mm: Add MIPI DSI support

On Thu, Nov 11, 2021 at 2:15 AM Jagan Teki wrote: > > This series support MIPI DSI on i.MX8MM. > > The DSIM bridge still need to work to make it compatible for > exynos drm dsi hardware block. > > This series work directly on to of linux-next with recent > dispmix-blk-ctrl changes. > Jagan, Than

[RESEND PATCH v2 01/13] backlight: qcom-wled: Validate enabled string indices in DT

The strings passed in DT may possibly cause out-of-bounds register accesses and should be validated before use. Fixes: 775d2ffb4af6 ("backlight: qcom-wled: Restructure the driver for WLED3") Signed-off-by: Marijn Suijten Reviewed-by: AngeloGioacchino Del Regno --- drivers/video/backlight/qcom-

[RESEND PATCH v2 04/13] backlight: qcom-wled: Fix off-by-one maximum with default num_strings

When not specifying num-strings in the DT the default is used, but +1 is added to it which turns WLED3 into 4 and WLED4/5 into 5 strings instead of 3 and 4 respectively, causing out-of-bounds reads and register read/writes. This +1 exists for a deficiency in the DT parsing code, and is simply omit

[RESEND PATCH v2 02/13] backlight: qcom-wled: Pass number of elements to read to read_u32_array

of_property_read_u32_array takes the number of elements to read as last argument. This does not always need to be 4 (sizeof(u32)) but should instead be the size of the array in DT as read just above with of_property_count_elems_of_size. To not make such an error go unnoticed again the driver now b

  1   2   >