Re: [Intel-gfx] [PATCH v3 4/9] drm: fix potential null ptr dereferences in drm_{auth, ioctl}

On 19/8/21 12:33 am, Daniel Vetter wrote: On Wed, Aug 18, 2021 at 5:37 PM Desmond Cheong Zhi Xi wrote: On 18/8/21 6:11 pm, Daniel Vetter wrote: On Wed, Aug 18, 2021 at 03:38:19PM +0800, Desmond Cheong Zhi Xi wrote: There are three areas where we dereference struct drm_master without

Re: [Intel-gfx] [PATCH 3/8] drm/i915/display: Move DRRS code its own file

On Wed, 2021-08-18 at 10:24 +0300, Jani Nikula wrote: > On Tue, 17 Aug 2021, José Roberto de Souza wrote: > > intel_dp.c is a 5k lines monster, so moving DRRS out of it to reduce > > some lines from it. > > The functions in a file should be named after the file prefix, > i.e. intel_drrs_*()

Re: [Intel-gfx] [PATCH 0/8] drm + usb-type-c: Add support for out-of-band hotplug notification (v4 resend)

This looks great to me! Wasn't much to comment on here as most of this looks fine to me. For the whole series: Reviewed-by: Lyude Paul This will be quite interesting to try getting working for nouveau On Tue, 2021-08-17 at 23:51 +0200, Hans de Goede wrote: > Hi all, > > Here is a

Re: [Intel-gfx] [PATCH v5 8/9] drm/i915/dg2: Maintain backward-compatible nested batch behavior

> -Original Message- > From: Intel-gfx On Behalf Of Matt > Roper > Sent: Thursday, August 5, 2021 9:37 AM > To: intel-gfx@lists.freedesktop.org > Cc: Roper, Matthew D ; Harrison, John C > > Subject: [Intel-gfx] [PATCH v5 8/9] drm/i915/dg2: Maintain backward- > compatible nested batch

Re: [Intel-gfx] [PATCH 1/8] drm/connector: Give connector sysfs devices there own device_type

On Tue, 2021-08-17 at 23:51 +0200, Hans de Goede wrote: > Give connector sysfs devices there own device_type, this allows us to > check if a device passed to functions dealing with generic devices is > a drm_connector or not. > > A check like this is necessary in the

Re: [Intel-gfx] [PATCH] drm/i915/adl_p: Also disable underrun recovery with MSO

On Mon, 2021-08-16 at 13:41 -0700, Matt Roper wrote: > One of the cases that the bspec lists for when underrun recovery must be > disabled is "COG;" that note actually refers to eDP multi-segmented > operation (MSO). Let's ensure the this additional restriction is > honored by the driver.

[Intel-gfx] [PULL] drm-intel-fixes

Hi Dave and Daniel, Here goes drm-intel-fixes-2021-08-18: - Expand a tweaked display workaround for all PCHs. (Anshuman) - Fix eDP MSO pipe sanity checks for ADL-P. (Jani) - Remove superfluous EXPORT_SYMBOL(). (Jani) Thanks, Rodrigo. The following changes since commit

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dp: dp 2.0 enabling prep work

== Series Details == Series: drm/i915/dp: dp 2.0 enabling prep work URL : https://patchwork.freedesktop.org/series/93800/ State : success == Summary == CI Bug Log - changes from CI_DRM_10497 -> Patchwork_20850 Summary ---

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/dp: dp 2.0 enabling prep work

== Series Details == Series: drm/i915/dp: dp 2.0 enabling prep work URL : https://patchwork.freedesktop.org/series/93800/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. -

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/dp: dp 2.0 enabling prep work

== Series Details == Series: drm/i915/dp: dp 2.0 enabling prep work URL : https://patchwork.freedesktop.org/series/93800/ State : warning == Summary == $ dim checkpatch origin/drm-tip 098494421cf3 drm/dp: add DP 2.0 UHBR link rate and bw code conversions 15972d4824f6 drm/dp: use more of the

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/dp: Use max params for panels < eDP 1.4

== Series Details == Series: drm/i915/dp: Use max params for panels < eDP 1.4 URL : https://patchwork.freedesktop.org/series/93794/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10497 -> Patchwork_20849 Summary ---

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gt: Potential error pointer dereference in pinned_context() (rev2)

== Series Details == Series: drm/i915/gt: Potential error pointer dereference in pinned_context() (rev2) URL : https://patchwork.freedesktop.org/series/93670/ State : success == Summary == CI Bug Log - changes from CI_DRM_10496_full -> Patchwork_20847_full

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm + usb-type-c: Add support for out-of-band hotplug notification (v4 resend)

Hi, On 8/18/21 2:08 AM, Patchwork wrote: > *Patch Details* > *Series:* drm + usb-type-c: Add support for out-of-band hotplug > notification (v4 resend) > *URL:*https://patchwork.freedesktop.org/series/93762/ > > *State:* failure

Re: [Intel-gfx] [PATCH 7/8] drm/i915/display/skl+: Drop frontbuffer rendering support

On Wed, 2021-08-18 at 17:55 +0300, Ville Syrjälä wrote: > On Tue, Aug 17, 2021 at 05:42:15PM -0700, José Roberto de Souza wrote: > > By now all the userspace applications should have migrated to atomic > > or at least be calling DRM_IOCTL_MODE_DIRTYFB. > > > > With that we can kill frontbuffer

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/dp: Use max params for panels < eDP 1.4

== Series Details == Series: drm/i915/dp: Use max params for panels < eDP 1.4 URL : https://patchwork.freedesktop.org/series/93794/ State : warning == Summary == $ dim checkpatch origin/drm-tip 33297386de4a drm/i915/dp: Use max params for panels < eDP 1.4 -:9: ERROR:GIT_COMMIT_ID: Please use

[Intel-gfx] [PULL] drm-misc-fixes

Hi Dave and Daniel, here's the drm-misc-fixes PR for this week. The vblank fix is a UAPI change that unifies the behaviour of the regular and compat ioctl. Best regards Thomas drm-misc-fixes-2021-08-18: Short summary of fixes pull: * UAPI: Return results for failed drm_wait_vblank_ioctl() *

Re: [Intel-gfx] [PATCH 2/4] drm/i915/guc: Print error name on CTB (de)registration failure

On 18.08.2021 18:35, Daniel Vetter wrote: > On Wed, Aug 18, 2021 at 5:11 PM Michal Wajdeczko > wrote: >> >> >> >> On 18.08.2021 16:20, Daniel Vetter wrote: >>> On Thu, Jul 01, 2021 at 05:55:11PM +0200, Michal Wajdeczko wrote: Instead of plain error value (%d) print more user friendly

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/ttm: ensure we release the intel_memory_region

== Series Details == Series: drm/i915/ttm: ensure we release the intel_memory_region URL : https://patchwork.freedesktop.org/series/93791/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10496 -> Patchwork_20848 Summary

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Potential error pointer dereference in pinned_context() (rev2)

== Series Details == Series: drm/i915/gt: Potential error pointer dereference in pinned_context() (rev2) URL : https://patchwork.freedesktop.org/series/93670/ State : success == Summary == CI Bug Log - changes from CI_DRM_10496 -> Patchwork_20847

[Intel-gfx] [PATCH 17/17] drm/i915/dg2: update link training for 128b/132b

The 128b/132b channel coding link training uses more straightforward TX FFE preset values. Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/display/intel_ddi.c | 13 ++- .../drm/i915/display/intel_dp_link_training.c | 86 +-- 2 files changed, 70 insertions(+), 29

[Intel-gfx] [PATCH 16/17] drm/i915/dg2: configure TRANS_DP2_VFREQ{HIGH, LOW} for 128b/132b

There's a new register pair for 128b/132b mode where you need to set the pixel clock in Hz. Bspec: 54128 Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/display/intel_dp_mst.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c

[Intel-gfx] [PATCH 15/17] drm/i915/dg2: use 128b/132b transcoder DDI mode

128b/132b has a separate transcoder DDI mode, which also requires the MST transport select to be set. Note that we'll use DP MST also for single-stream 128b/132b. Having the FDI and 128b/132b modes share the register mode value complicates things a bit. Bspec: 50493 Signed-off-by: Jani Nikula

[Intel-gfx] [PATCH 14/17] drm/i915/dg2: configure TRANS_DP2_CTL for DP 2.0

Set the DP 2.0 128b/132b channel encoding for UHBR rates. Bspec: 54128 Reviewed-by: Manasi Navare Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/display/intel_ddi.c | 17 - 1 file changed, 16 insertions(+), 1 deletion(-) diff --git

[Intel-gfx] [PATCH 13/17] drm/i915/dp: select 128b/132b channel encoding for UHBR rates

UHBR rates and 128b/132b channel encoding go hand in hand. Reviewed-by: Manasi Navare Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/display/intel_dp_link_training.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c

[Intel-gfx] [PATCH 12/17] drm/i915/dp: use 128b/132b TPS2 for UHBR+ link rates

128b/132b channel encoding has separate TPS1 and TPS2, although the DPCD register values coincide with 8b/10b TPS1 and TPS2 values. Use 128b/132b TPS2 for channel equalization. Reviewed-by: Manasi Navare Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/display/intel_dp_link_training.c | 10

[Intel-gfx] [PATCH 11/17] drm/i915/dp: add max data rate calculation for UHBR rates

DP 2.0 UHBR link rates always use 128b/132b channel encoding, which has a different data bandwidth efficiency from 8b/10b. The computation is slightly convoluted due to the units we use; this is all explained in the added comment. v2: Clarified comment (Manasi) Reviewed-by: Manasi Navare

[Intel-gfx] [PATCH 10/17] drm/i915/dg2: add DG2 UHBR source rates

DG2 supports DP 2.0 UHBR and 128b/132b channel encoding. Bspec: 53657, 54034 Acked-by: Manasi Navare Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/display/intel_dp.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_dp.c

[Intel-gfx] [PATCH 09/17] drm/i915/dg2: add TRANS_DP2_VFREQHIGH and TRANS_DP2_VFREQLOW

Add the registers for specifying the lower and higher 24 bits of the DP 2.0 pixel clock frequency in Hz. Bspec: 53326 Reviewed-by: Manasi Navare Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/i915_reg.h | 14 ++ 1 file changed, 14 insertions(+) diff --git

[Intel-gfx] [PATCH 08/17] drm/i915/dg2: add DG2+ TRANS_DDI_FUNC_CTL DP 2.0 128b/132b mode

Unfortunately, the DP 2.0 128b/132b DDI mode selection in the register conflicts with FDI. Since we have to deal with both meanings in the same code, for different platforms, clarify the macro name so we don't forget. Bspec: 50493 Signed-off-by: Jani Nikula ---

[Intel-gfx] [PATCH 07/17] drm/i915/dg2: add TRANS_DP2_CTL register definition

This register controls the DP 2.0 datapath. Bspec: 69967 Reviewed-by: Manasi Navare Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/i915_reg.h | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index

[Intel-gfx] [PATCH 06/17] drm/i915/dp: read sink UHBR rates

See if sink supports DP 2.0 128b/132b channel encoding, and update sink rates accordingly. FIXME: Also take LTTPR 128b/132b into account. Reviewed-by: Manasi Navare Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/display/intel_dp.c | 18 ++ 1 file changed, 18 insertions(+)

[Intel-gfx] [PATCH 05/17] drm/i915/dp: use actual link rate values in struct link_config_limits

The MST code uses actual link rates in the limits struct, while the DP code in general uses indexes to the ->common_rates[] array. Fix the confusion by using actual link rate values everywhere. This is a better abstraction than some obscure index. Rename the struct members while at it to ensure

[Intel-gfx] [PATCH 03/17] drm/dp: add LTTPR DP 2.0 DPCD addresses

DP 2.0 brings some new DPCD addresses for PHY repeaters. Cc: dri-de...@lists.freedesktop.org Reviewed-by: Manasi Navare Signed-off-by: Jani Nikula --- include/drm/drm_dp_helper.h | 4 1 file changed, 4 insertions(+) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h

[Intel-gfx] [PATCH 04/17] drm/dp: add helper for extracting adjust 128b/132b TX FFE preset

The DP 2.0 128b/132b channel coding uses TX FFE presets instead of vswing and pre-emphasis. Cc: dri-de...@lists.freedesktop.org Signed-off-by: Jani Nikula --- drivers/gpu/drm/drm_dp_helper.c | 14 ++ include/drm/drm_dp_helper.h | 2 ++ 2 files changed, 16 insertions(+) diff

[Intel-gfx] [PATCH 02/17] drm/dp: use more of the extended receiver cap

Extend the use of extended receiver cap at 0x2200 to cover MAIN_LINK_CHANNEL_CODING_CAP in 0x2206, in case an implementation hides the DP 2.0 128b/132b channel encoding cap. Cc: dri-de...@lists.freedesktop.org Reviewed-by: Manasi Navare Signed-off-by: Jani Nikula ---

[Intel-gfx] [PATCH 01/17] drm/dp: add DP 2.0 UHBR link rate and bw code conversions

The bw code equals link_rate / 0.27 Gbps only for 8b/10b link rates. Handle DP 2.0 UHBR rates as special cases, though this is not pretty. Cc: dri-de...@lists.freedesktop.org Signed-off-by: Jani Nikula --- drivers/gpu/drm/drm_dp_helper.c | 26 ++ 1 file changed, 22

[Intel-gfx] [PATCH 00/17] drm/i915/dp: dp 2.0 enabling prep work

Start enabling DP 2.0 features. It's not complete, but it's a good start, and should not conflict with anything existing. Jani Nikula (17): drm/dp: add DP 2.0 UHBR link rate and bw code conversions drm/dp: use more of the extended receiver cap drm/dp: add LTTPR DP 2.0 DPCD addresses

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/buddy: add some pretty printing

== Series Details == Series: series starting with [1/2] drm/i915/buddy: add some pretty printing URL : https://patchwork.freedesktop.org/series/93790/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10496 -> Patchwork_20846

Re: [Intel-gfx] [PATCH V3] drm/i915/adl_s: Update ADL-S PCI IDs

On Wed, 2021-08-18 at 10:31 +0530, Tejas Upadhyay wrote: > Sync PCI IDs with Bspec. > > Bspec:53655 > > Changes since V2: > - Upstream devices which are "POR" yes and > "Ok to upstream" yes - James Asmus > Changes since V1: > - All POR and Non POR Ids needs to be upstreamed

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gem: Avoid NULL dereference in __i915_gem_object_lock()

== Series Details == Series: drm/i915/gem: Avoid NULL dereference in __i915_gem_object_lock() URL : https://patchwork.freedesktop.org/series/93787/ State : success == Summary == CI Bug Log - changes from CI_DRM_10495_full -> Patchwork_20845_full

[Intel-gfx] [PATCH v2] drm/i915/dp: Use max params for panels < eDP 1.4

Users reported that after commit 2bbd6dba84d4 ("drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure"), the screen starts to have wobbly effect. Commit a5c936add6a2 ("drm/i915/dp: Use slow and wide link training for everything") doesn't help either,

[Intel-gfx] [PATCH] drm/i915/ttm: ensure we release the intel_memory_region

If the ttm_bo_init_reserved() call fails ensure we also release the region, otherwise we leak the reference, or worse hit some uaf, when we start using the objects.list. Also remove the make_unshrinkable call here, which doesn't do anything. Signed-off-by: Matthew Auld Cc: Thomas Hellström ---

Re: [Intel-gfx] [PATCH] drm/damage_helper: Fix handling of cursor dirty buffers

On Wed, 2021-08-18 at 11:54 +0200, Daniel Vetter wrote: > On Tue, Aug 17, 2021 at 04:26:04PM -0700, José Roberto de Souza wrote: > > Cursors don't have a framebuffer so the fb comparisson was always > > failing and atomic state was being committed without any plane state. > > > > So here checking

Re: [Intel-gfx] [PATCH 2/4] drm/i915/guc: Print error name on CTB (de)registration failure

On Wed, Aug 18, 2021 at 5:11 PM Michal Wajdeczko wrote: > > > > On 18.08.2021 16:20, Daniel Vetter wrote: > > On Thu, Jul 01, 2021 at 05:55:11PM +0200, Michal Wajdeczko wrote: > >> Instead of plain error value (%d) print more user friendly error > >> name (%pe). > >> > >> Signed-off-by: Michal

Re: [Intel-gfx] [PATCH v3 4/9] drm: fix potential null ptr dereferences in drm_{auth, ioctl}

On Wed, Aug 18, 2021 at 5:37 PM Desmond Cheong Zhi Xi wrote: > > On 18/8/21 6:11 pm, Daniel Vetter wrote: > > On Wed, Aug 18, 2021 at 03:38:19PM +0800, Desmond Cheong Zhi Xi wrote: > >> There are three areas where we dereference struct drm_master without > >> checking if the pointer is non-NULL.

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gem: Avoid NULL dereference in __i915_gem_object_lock()

== Series Details == Series: drm/i915/gem: Avoid NULL dereference in __i915_gem_object_lock() URL : https://patchwork.freedesktop.org/series/93787/ State : success == Summary == CI Bug Log - changes from CI_DRM_10495 -> Patchwork_20845

Re: [Intel-gfx] [PATCH] drm/i915/dp: return proper DPRX link training result

On Wed, Aug 18, 2021 at 06:09:43PM +0300, Lee, Shawn C wrote: > On Tue, 2021-07-07, Lee Shawn C wrote: > >On Tue, 2021-07-07, Almahallawy, Khaled wrote: > >>I believe Imre's LT fallback: > >>https://github.com/ideak/linux/commits/linktraining-fallback-fix and > >>Chrome user space fix: >

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gem: Avoid NULL dereference in __i915_gem_object_lock()

== Series Details == Series: drm/i915/gem: Avoid NULL dereference in __i915_gem_object_lock() URL : https://patchwork.freedesktop.org/series/93787/ State : warning == Summary == $ dim checkpatch origin/drm-tip c2b783f48fd3 drm/i915/gem: Avoid NULL dereference in __i915_gem_object_lock() -:9:

Re: [Intel-gfx] [PATCH v3 4/9] drm: fix potential null ptr dereferences in drm_{auth, ioctl}

On 18/8/21 6:11 pm, Daniel Vetter wrote: On Wed, Aug 18, 2021 at 03:38:19PM +0800, Desmond Cheong Zhi Xi wrote: There are three areas where we dereference struct drm_master without checking if the pointer is non-NULL. 1. drm_getmagic is called from the ioctl_handler. Since DRM_IOCTL_GET_MAGIC

Re: [Intel-gfx] [PATCH 2/4] drm/i915/guc: Print error name on CTB (de)registration failure

On 18.08.2021 16:20, Daniel Vetter wrote: > On Thu, Jul 01, 2021 at 05:55:11PM +0200, Michal Wajdeczko wrote: >> Instead of plain error value (%d) print more user friendly error >> name (%pe). >> >> Signed-off-by: Michal Wajdeczko >> --- >> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 8

Re: [Intel-gfx] [PATCH] drm/i915/dp: return proper DPRX link training result

On Tue, 2021-07-07, Lee Shawn C wrote: >On Tue, 2021-07-07, Almahallawy, Khaled wrote: >>I believe Imre's LT fallback: >>https://github.com/ideak/linux/commits/linktraining-fallback-fix and Chrome >>user space fix: >>https://chromium-review.googlesource.com/c/chromium/src/+/3003487 >>should

[Intel-gfx] [PATCH 1/2] drm/i915/buddy: add some pretty printing

Implement the debug hook for the buddy resource manager. For this we want to print out the status of the memory manager, including how much memory is still allocatable, what page sizes we have etc. This will be triggered when TTM is unable to fulfil an allocation request for device local-memory.

[Intel-gfx] [PATCH 2/2] drm/i915/debugfs: hook up ttm_resource_manager_debug

This should give a more complete view of the various bits of internal resource manager state, for device local-memory. Signed-off-by: Matthew Auld Cc: Thomas Hellström --- drivers/gpu/drm/i915/i915_debugfs.c | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git

Re: [Intel-gfx] [v4] drm/i915/dsi: Send proper brightness value via MIPI DCS command

On Wed, 18 Aug 2021, Jani Nikula wrote: >On Fri, 13 Aug 2021, Lee Shawn C wrote: >> Driver has to swap the endian before send brightness level value to >> tcon. >> >> v2: Use __be16 instead of u16 to fix sparse warning. >> >> Reported-by: kernel test robot >> Cc: Ville Syrjala >> Cc: Jani

Re: [Intel-gfx] [PATCH 7/8] drm/i915/display/skl+: Drop frontbuffer rendering support

On Tue, Aug 17, 2021 at 05:42:15PM -0700, José Roberto de Souza wrote: > By now all the userspace applications should have migrated to atomic > or at least be calling DRM_IOCTL_MODE_DIRTYFB. > > With that we can kill frontbuffer rendering support in i915 for > modern platforms. > > So here

[Intel-gfx] [PATCH] drm/i915/gem: Avoid NULL dereference in __i915_gem_object_lock()

Coverity warns of a possible NULL dereference: Both dma_resv_lock_interruptible() and dma_resv_lock() can return -EDEADLK. Protect against a NULL dereference by checking for NULL before saving the object pointer. This is consistent with previous checks for ww==NULL. Addresses-Coverity:

Re: [Intel-gfx] [PATCH v3 2/9] drm: hold master_lookup_lock when releasing a drm_file's master

On 18/8/21 6:05 pm, Daniel Vetter wrote: On Wed, Aug 18, 2021 at 03:38:17PM +0800, Desmond Cheong Zhi Xi wrote: When drm_file.master changes value, the corresponding drm_device.master_lookup_lock should be held. In drm_master_release, a call to drm_master_put sets the file_priv->master to

Re: [Intel-gfx] [PATCH V2 2/5] drm/i915/gt: Use cmd_cctl override for platforms >= gen12

-Original Message- From: Roper, Matthew D Sent: Tuesday, August 17, 2021 3:06 AM To: Siddiqui, Ayaz A Cc: intel-gfx@lists.freedesktop.org; S, Srinivasan ; Wilson, Chris P Subject: Re: [PATCH V2 2/5] drm/i915/gt: Use cmd_cctl override for platforms >= gen12 On Mon, Aug 16, 2021 at

Re: [Intel-gfx] [PATCH 4/4] drm/i915/guc: Move and improve error message for missed CTB reply

On Thu, Jul 01, 2021 at 05:55:13PM +0200, Michal Wajdeczko wrote: > If we timeout waiting for a CT reply we print very simple error > message. Improve that and by moving error reporting to the caller > we can use CT_ERROR instead of DRM_ERROR and report just fence > as error code will be reported

Re: [Intel-gfx] [PATCH 3/4] drm/i915/guc: Print error name on CTB send failure

On Thu, Jul 01, 2021 at 05:55:12PM +0200, Michal Wajdeczko wrote: > Instead of plain error value (%d) print more user friendly error > name (%pe). > > Signed-off-by: Michal Wajdeczko > --- > drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) >

Re: [Intel-gfx] [PATCH 1/4] drm/i915/guc: Verify result from CTB (de)register action

On Thu, Jul 01, 2021 at 05:55:10PM +0200, Michal Wajdeczko wrote: > In commit b839a869dfc9 ("drm/i915/guc: Add support for data > reporting in GuC responses") we missed the hypothetical case > that GuC might return positive non-zero value as success data. > > While that would be lucky treated as

Re: [Intel-gfx] [PATCH 2/4] drm/i915/guc: Print error name on CTB (de)registration failure

On Thu, Jul 01, 2021 at 05:55:11PM +0200, Michal Wajdeczko wrote: > Instead of plain error value (%d) print more user friendly error > name (%pe). > > Signed-off-by: Michal Wajdeczko > --- > drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 8 > 1 file changed, 4 insertions(+), 4

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm, kernel: update locking for DRM

== Series Details == Series: drm, kernel: update locking for DRM URL : https://patchwork.freedesktop.org/series/93782/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10495 -> Patchwork_20844 Summary --- **FAILURE**

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: header cleanups

== Series Details == Series: drm/i915: header cleanups URL : https://patchwork.freedesktop.org/series/93777/ State : success == Summary == CI Bug Log - changes from CI_DRM_10493_full -> Patchwork_20843_full Summary --- **SUCCESS**

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: header cleanups

== Series Details == Series: drm/i915: header cleanups URL : https://patchwork.freedesktop.org/series/93777/ State : success == Summary == CI Bug Log - changes from CI_DRM_10493 -> Patchwork_20843 Summary --- **SUCCESS** No

Re: [Intel-gfx] [PATCH v2] drm/i915: Ditch the i915_gem_ww_ctx loop member

On Mon, 16 Aug 2021 at 18:14, Thomas Hellström wrote: > > It's only used by the for_i915_gem_ww() macro and we can use > the (typically) on-stack _err variable in its place. > > v2: > - Don't clear the _err variable when entering the loop > (Matthew Auld, Maarten Lankhorst). > - Use parentheses

Re: [Intel-gfx] [PATCH v5 3/3] drm/i915/hdcp: reuse rx_info for mst stream type1 capability check

> -Original Message- > From: Li, Juston > Sent: Friday, August 13, 2021 12:14 AM > To: intel-gfx@lists.freedesktop.org > Cc: seanp...@chromium.org; Gupta, Anshuman ; > C, Ramalingam ; Vivi, Rodrigo > ; Li, Juston > Subject: [Intel-gfx] [PATCH v5 3/3] drm/i915/hdcp: reuse rx_info for

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: header cleanups

== Series Details == Series: drm/i915: header cleanups URL : https://patchwork.freedesktop.org/series/93777/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: header cleanups

== Series Details == Series: drm/i915: header cleanups URL : https://patchwork.freedesktop.org/series/93777/ State : warning == Summary == $ dim checkpatch origin/drm-tip ddebfe5d1496 drm/i915/irq: reduce inlines to reduce header dependencies e2382f06ea1f drm/i915: intel_runtime_pm.h does not

[Intel-gfx] [PATCH v3 6/9] drm: convert drm_device.master_mutex into a rwsem

drm_device.master_mutex currently protects the following: - drm_device.master - drm_file.master - drm_file.was_master - drm_file.is_master These attributes determine modesetting permissions for drm devices, and there is a clear separation between functions that read or change the permissions.

Re: [Intel-gfx] [BUG - BISECTED] display not detected anymore

On Sat, Aug 14, 2021 at 02:46:27PM +0200, Heiko Carstens wrote: > Hello, > > I have Fedora 33 running, and with the Fedore kernel update from 5.11 > series to 5.12 my external monitor was not detected anymore. Same is > true with the Fedora supplied 5.13 kernel version. > > So I tried with

[Intel-gfx] [PATCH v3 9/9] drm: avoid races with modesetting rights

In drm_client_modeset.c and drm_fb_helper.c, drm_master_internal_{acquire,release} are used to avoid races with DRM userspace. These functions hold onto drm_device.master_rwsem while committing, and bail if there's already a master. However, there are other places where modesetting rights can

[Intel-gfx] [PATCH v3 2/9] drm: hold master_lookup_lock when releasing a drm_file's master

When drm_file.master changes value, the corresponding drm_device.master_lookup_lock should be held. In drm_master_release, a call to drm_master_put sets the file_priv->master to NULL, so we protect this section with drm_device.master_lookup_lock. Signed-off-by: Desmond Cheong Zhi Xi ---

[Intel-gfx] [PATCH v3 4/9] drm: fix potential null ptr dereferences in drm_{auth, ioctl}

There are three areas where we dereference struct drm_master without checking if the pointer is non-NULL. 1. drm_getmagic is called from the ioctl_handler. Since DRM_IOCTL_GET_MAGIC has no ioctl flags, drm_getmagic is run without any check that drm_file.master has been set. 2. Similarly,

[Intel-gfx] [PATCH v3 8/9] kernel: export task_work_add

The task_work_add function is needed to prevent userspace races with DRM modesetting rights. Some DRM ioctls can change modesetting permissions while other concurrent users are performing modesetting. To prevent races with userspace, such functions should flush readers of old permissions before

[Intel-gfx] [PATCH v3 7/9] drm: update global mutex lock in the ioctl handler

In a future patch, a read lock on drm_device.master_rwsem is held in the ioctl handler before the check for ioctl permissions. However, this produces the following lockdep splat: == WARNING: possible circular locking dependency detected

[Intel-gfx] [PATCH v3 5/9] drm: protect magic_map, unique{_len} with master_lookup_lock

Currently, drm_device.master_mutex is used to serialize writes to the drm_master.magic_map idr and to protect drm_master.unique{_len}. In preparation for converting drm_device.master_mutex into an outer rwsem that might be read locked before entering some of these functions, we can instead

[Intel-gfx] [PATCH v3 0/9] drm, kernel: update locking for DRM

Hi, The patches in this series are largely fixes and prepwork leading up to the final patch which plugs races with modesetting rights. Most of the fixes don't have bug reports, so comments would be very appreciated. The biggest change from the previous version is that we convert

[Intel-gfx] [PATCH v3 1/9] drm: move master_lookup_lock into drm_device

The master_lookup_lock spinlock can be useful as an inner lock for other attributes that are currently protected by drm_device.master_mutex. However, since the spinlock belongs to struct drm_file, its use case is limited to serializing accesses by a single drm_file. Moving this lock into struct

[Intel-gfx] [PATCH v3 3/9] drm: check for null master in drm_is_current_master_locked

There is a window after calling drm_master_release, and before a file is freed, where drm_file can have is_master set to true, but both the drm_file and drm_device have no master. This could result in wrongly approving permissions in drm_is_current_master_locked. Add a check that fpriv->master is

Re: [Intel-gfx] [v4] drm/i915/dsi: Send proper brightness value via MIPI DCS command

On Fri, 13 Aug 2021, Lee Shawn C wrote: > Driver has to swap the endian before send brightness level value > to tcon. > > v2: Use __be16 instead of u16 to fix sparse warning. > > Reported-by: kernel test robot > Cc: Ville Syrjala > Cc: Jani Nikula > Cc: Vandita Kulkarni > Cc: Cooper Chiou >

Re: [Intel-gfx] [PATCH v3 8/9] kernel: export task_work_add

On Wed, Aug 18, 2021 at 03:38:23PM +0800, Desmond Cheong Zhi Xi wrote: > The task_work_add function is needed to prevent userspace races with > DRM modesetting rights. > > Some DRM ioctls can change modesetting permissions while other > concurrent users are performing modesetting. To prevent

Re: [Intel-gfx] [PATCH v3 7/9] drm: update global mutex lock in the ioctl handler

On Wed, Aug 18, 2021 at 03:38:22PM +0800, Desmond Cheong Zhi Xi wrote: > In a future patch, a read lock on drm_device.master_rwsem is > held in the ioctl handler before the check for ioctl > permissions. However, this produces the following lockdep splat: > >

Re: [Intel-gfx] [PATCH v3 5/9] drm: protect magic_map, unique{_len} with master_lookup_lock

On Wed, Aug 18, 2021 at 03:38:20PM +0800, Desmond Cheong Zhi Xi wrote: > Currently, drm_device.master_mutex is used to serialize writes to the > drm_master.magic_map idr and to protect drm_master.unique{_len}. > > In preparation for converting drm_device.master_mutex into an outer > rwsem that

[Intel-gfx] [PATCH 5/5] drm/i915/fdi: move intel_fdi_link_freq() to intel_fdi.[ch]

There's no performance reason to have it as static inline; move it out of intel_display_types.h to reduce clutter and dependency on i915_drv.h. Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/display/intel_display_types.h | 9 - drivers/gpu/drm/i915/display/intel_fdi.c | 9

[Intel-gfx] [PATCH 1/5] drm/i915/irq: reduce inlines to reduce header dependencies

Presumably if the compiler is smart, it does not generate an extra function call to the update functions that are now static. Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/i915_irq.c | 50 +--- drivers/gpu/drm/i915/i915_irq.h | 51

[Intel-gfx] [PATCH 4/5] drm/i915/panel: move intel_panel_use_ssc() out of headers

There's no performance reason to have it as static inline; move it out of intel_display_types.h to reduce clutter and dependency on i915_drv.h. Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/display/intel_display.c | 1 + drivers/gpu/drm/i915/display/intel_display_types.h | 8

[Intel-gfx] [PATCH 3/5] drm/i915/pm: use forward declaration to remove an include

The fewer includes the better. Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_pm.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_pm.h b/drivers/gpu/drm/i915/intel_pm.h index 91f23b7f0af2..941b3ae555c8 100644 ---

[Intel-gfx] [PATCH 2/5] drm/i915: intel_runtime_pm.h does not actually need intel_display.h

Reduce includes. Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_runtime_pm.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.h b/drivers/gpu/drm/i915/intel_runtime_pm.h index 183ea2b187fe..47a85fab4130 100644 ---

[Intel-gfx] [PATCH 0/5] drm/i915: header cleanups

Some header cleanups I've had around but never posted. Jani Nikula (5): drm/i915/irq: reduce inlines to reduce header dependencies drm/i915: intel_runtime_pm.h does not actually need intel_display.h drm/i915/pm: use forward declaration to remove an include drm/i915/panel: move

Re: [Intel-gfx] [PATCH v3 4/9] drm: fix potential null ptr dereferences in drm_{auth, ioctl}

On Wed, Aug 18, 2021 at 03:38:19PM +0800, Desmond Cheong Zhi Xi wrote: > There are three areas where we dereference struct drm_master without > checking if the pointer is non-NULL. > > 1. drm_getmagic is called from the ioctl_handler. Since > DRM_IOCTL_GET_MAGIC has no ioctl flags, drm_getmagic

Re: [Intel-gfx] [PATCH v3 2/9] drm: hold master_lookup_lock when releasing a drm_file's master

On Wed, Aug 18, 2021 at 03:38:17PM +0800, Desmond Cheong Zhi Xi wrote: > When drm_file.master changes value, the corresponding > drm_device.master_lookup_lock should be held. > > In drm_master_release, a call to drm_master_put sets the > file_priv->master to NULL, so we protect this section with

Re: [Intel-gfx] [PATCH v3 3/9] drm: check for null master in drm_is_current_master_locked

On Wed, Aug 18, 2021 at 03:38:18PM +0800, Desmond Cheong Zhi Xi wrote: > There is a window after calling drm_master_release, and before a file > is freed, where drm_file can have is_master set to true, but both the > drm_file and drm_device have no master. > > This could result in wrongly

Re: [Intel-gfx] [PATCH] drm/i915: Use designated initializers for init/exit table

On Tue, Aug 17, 2021 at 04:33:57PM -0700, Kees Cook wrote: > The kernel builds with -Werror=designated-init, and __designated_init > is used by CONFIG_GCC_PLUGIN_RANDSTRUCT for automatically selected (all > function pointer) structures. Include the field names in the init/exit > table. Avoids

Re: [Intel-gfx] [PATCH] drm/damage_helper: Fix handling of cursor dirty buffers

On Tue, Aug 17, 2021 at 04:26:04PM -0700, José Roberto de Souza wrote: > Cursors don't have a framebuffer so the fb comparisson was always > failing and atomic state was being committed without any plane state. > > So here checking if objects match when checking cursors. This looks extremely

Re: [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gt: Initialize unused MOCS entries to L3_WB

> -Original Message- > From: Jani Nikula > Sent: Friday, August 13, 2021 1:25 PM > To: Patchwork ; Siddiqui, Ayaz A > > Cc: intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gt: > Initialize unused MOCS entries to L3_WB > > > These

Re: [Intel-gfx] [PATCH 0/1] Fix gem_ctx_persistence failures with GuC submission

On Tue, Aug 17, 2021 at 05:08:02PM -0700, John Harrison wrote: > On 8/9/2021 23:38, Daniel Vetter wrote: > > On Wed, Jul 28, 2021 at 05:33:59PM -0700, Matthew Brost wrote: > > > Should fix below failures with GuC submission for the following tests: > > > gem_exec_balancer --r noheartbeat > > >

Re: [Intel-gfx] [PATCH 1/1] drm/i915: Check if engine has heartbeat when closing a context

On Wed, Aug 18, 2021 at 2:28 AM John Harrison wrote: > On 8/9/2021 23:36, Daniel Vetter wrote: > > On Mon, Aug 09, 2021 at 04:12:52PM -0700, John Harrison wrote: > >> On 8/6/2021 12:46, Daniel Vetter wrote: > >>> Seen this fly by and figured I dropped a few thoughts in here. At the > >>> likely

Re: [Intel-gfx] [PATCH 3/8] drm/i915/display: Move DRRS code its own file

On Tue, 17 Aug 2021, José Roberto de Souza wrote: > intel_dp.c is a 5k lines monster, so moving DRRS out of it to reduce > some lines from it. The functions in a file should be named after the file prefix, i.e. intel_drrs_*() here. The renames don't need to be in the same patch, but I think we

Re: [Intel-gfx] 5.13-rc6 on thinkpad X220: graphics hangs with recent mainline

Hi! > > I'm getting graphics problems with 5.13-rc: > > > > Debian 10.9, X, chromium and flightgear is in use. Things were more > > stable than this with previous kernels. > > > > Any ideas? > > The error you are seeing: > > > [185300.784992] i915 :00:02.0: [drm] Resetting chip for stopped

  1   2   >