[Intel-gfx] [PATCH 00/10] drm/i915: Prep work for finishing (de)gamma readout

From: Ville Syrjälä Add another layer of LUT blobs in order to make gamma state readout/check possible on ilk-skl. As a bonus we can also simplify the glk degamma vs. csc mess. The actual state readout/checker stuff that we're currently missing will follow later. Ville Syrjälä (10): drm/i915:

[Intel-gfx] [PATCH 03/10] drm/i915: Simplify the intel_color_init_hooks() if ladder

From: Ville Syrjälä Get rid of the funny hsw vs. ivb extra indentation level in intel_color_init_hooks(). Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_color.c | 11 +-- 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/display/int

[Intel-gfx] [PATCH 02/10] drm/i915: Split up intel_color_init()

From: Ville Syrjälä intel_color_init() does both device level and crtc level stuff. Split it up accordingly. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_color.c | 15 +-- drivers/gpu/drm/i915/display/intel_color.h | 4 +++- drivers/gpu/drm/i915/display/

[Intel-gfx] [PATCH 01/10] drm/i915: Remove PLL asserts from .load_luts()

From: Ville Syrjälä .load_luts() potentially runs from the vblank worker, and is under a deadline to complete within the vblank. Thus we can't do expesive stuff like talk to the Punit, etc. To that end get rid of the assert_dsi_pll_enabled() call for vlv/chv. We'll just have to trust that the PL

[Intel-gfx] [PATCH 05/10] drm/i915: Change glk_load_degamma_lut() calling convention

From: Ville Syrjälä Make glk_load_degamma_lut() more like most everyone else and pass in the LUT explicitly. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_color.c | 17 ++--- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/i915/d

[Intel-gfx] [PATCH 09/10] drm/i915: Get rid of glk_load_degamma_lut_linear()

From: Ville Syrjälä Since we now have a place (pre_csc_lut) to stuff a purely internal LUT we can replace glk_load_degamma_lut_linear() with such a thing and just rely on the normal glk_load_degamma_lut() to load it as well. drm_mode_config_cleanup() will clean this up for us. Signed-off-by: Vi

[Intel-gfx] [PATCH 08/10] drm/i915: Assert {pre, post}_csc_lut were assigned sensibly

From: Ville Syrjälä Since we now have the extra step from hw.(de)gamma_lut into {pre,post}_csc_lut let's make sure we didn't forget to assign them appropriately. Ie. basically making sure intel_color_check() was called when necessary (and that it did its job suitable well). Signed-off-by: Ville

[Intel-gfx] [PATCH 10/10] drm/i915: Stop loading linear degammma LUT on glk needlessly

From: Ville Syrjälä Make glk_load_luts() a bit lighter for the common case where neither the degamma LUT nor pipe CSC are enabled by not loading the linear degamma LUT. Making .load_luts() as lightweight as possible is a good idea since it may need to execute from a vblank worker under tight dead

[Intel-gfx] [PATCH 07/10] drm/i915: Introduce crtc_state->{pre, post}_csc_lut

From: Ville Syrjälä Add an extra remapping step between the logical state of the LUTs (hw.(de)gamma_lut) as specified via uapi/bigjoiner copy vs. the actual state of the LUTs programmed into the hardware. With this we should be finally able finish the (de)gamma readout/state checker support for

[Intel-gfx] [PATCH 06/10] drm/i915: Make ilk_load_luts() deal with degamma

From: Ville Syrjälä Make ilk_load_luts() ready for a degamma lut. Currently we never have one, but soon we may get one from readout, and I think we may want to change the state computation such that we may end up with one even when userspace has simply supplied a gamma lut. At least the code now

[Intel-gfx] [PATCH 04/10] drm/i915: Clean up intel_color_init_hooks()

From: Ville Syrjälä Remove a bunch of pointless curly brackets and do the s/dev_priv/i915/ while at it. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_color.c | 43 +++--- 1 file changed, 21 insertions(+), 22 deletions(-) diff --git a/drivers/gpu/drm/i915/

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for Add SLPC selftest live_slpc_power (rev2)

On 9/24/2022 7:31 AM, Patchwork wrote: *Patch Details* *Series:* Add SLPC selftest live_slpc_power (rev2) *URL:* https://patchwork.freedesktop.org/series/108900/ *State:*success *Details:* https://intel-gfx-ci.01.org/tree/drm-

Re: [Intel-gfx] [PATCH v4 1/4] drm/i915/guc: Limit scheduling properties to avoid overflow

On 29/09/2022 03:18, john.c.harri...@intel.com wrote: From: John Harrison GuC converts the pre-emption timeout and timeslice quantum values into clock ticks internally. That significantly reduces the point of 32bit overflow. On current platforms, worst case scenario is approximately 110 secon

Re: [Intel-gfx] [PATCH v4 3/4] drm/i915: Make the heartbeat play nice with long pre-emption timeouts

On 29/09/2022 03:18, john.c.harri...@intel.com wrote: From: John Harrison Compute workloads are inherently not pre-emptible for long periods on current hardware. As a workaround for this, the pre-emption timeout for compute capable engines was disabled. This is undesirable with GuC submission

Re: [Intel-gfx] [PATCH v4 4/4] drm/i915: Improve long running compute w/a for GuC submission

On 29/09/2022 03:18, john.c.harri...@intel.com wrote: From: John Harrison A workaround was added to the driver to allow compute workloads to run 'forever' by disabling pre-emption on the RCS engine for Gen12. It is not totally unbound as the heartbeat will kick in eventually and cause a reset

Re: [Intel-gfx] [PATCH] drm/i915/guc: do not capture error state on exiting context

On 28/09/2022 19:27, John Harrison wrote: On 9/28/2022 00:19, Tvrtko Ursulin wrote: On 27/09/2022 22:36, Ceraolo Spurio, Daniele wrote: On 9/27/2022 12:45 AM, Tvrtko Ursulin wrote: On 27/09/2022 07:49, Andrzej Hajda wrote: On 27.09.2022 01:34, Ceraolo Spurio, Daniele wrote: On 9/26/2022 3:

[Intel-gfx] ✓ Fi.CI.IGT: success for Fixes integer overflow or integer truncation issues in page lookups, ttm place configuration and scatterlist creation

== Series Details == Series: Fixes integer overflow or integer truncation issues in page lookups, ttm place configuration and scatterlist creation URL : https://patchwork.freedesktop.org/series/109169/ State : success == Summary == CI Bug Log - changes from CI_DRM_12193_full -> Patchwork_1091

Re: [Intel-gfx] [PATCH 05/16] drm/i915/vm_bind: Implement bind and unbind of object

On 29/09/2022 06:24, Niranjana Vishwanathapura wrote: On Wed, Sep 28, 2022 at 06:52:21PM +0100, Matthew Auld wrote: On 28/09/2022 07:19, Niranjana Vishwanathapura wrote: Add uapi and implement support for bind and unbind of an object at the specified GPU virtual addresses. The vm_bind mode is

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Prep work for finishing (de)gamma readout

== Series Details == Series: drm/i915: Prep work for finishing (de)gamma readout URL : https://patchwork.freedesktop.org/series/109229/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.

[Intel-gfx] ✗ Fi.CI.IGT: failure for iommu: Remove iova cpu hotplugging flushing (rev2)

== Series Details == Series: iommu: Remove iova cpu hotplugging flushing (rev2) URL : https://patchwork.freedesktop.org/series/108880/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12193_full -> Patchwork_108880v2_full Summ

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Prep work for finishing (de)gamma readout

== Series Details == Series: drm/i915: Prep work for finishing (de)gamma readout URL : https://patchwork.freedesktop.org/series/109229/ State : success == Summary == CI Bug Log - changes from CI_DRM_12197 -> Patchwork_109229v1 Summary -

Re: [Intel-gfx] [PATCH] drm/i915/guc: do not capture error state on exiting context

On 29.09.2022 10:22, Tvrtko Ursulin wrote: On 28/09/2022 19:27, John Harrison wrote: On 9/28/2022 00:19, Tvrtko Ursulin wrote: On 27/09/2022 22:36, Ceraolo Spurio, Daniele wrote: On 9/27/2022 12:45 AM, Tvrtko Ursulin wrote: On 27/09/2022 07:49, Andrzej Hajda wrote: On 27.09.2022 01:34, Cera

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Per-crtc/connector DRRS debugfs

== Series Details == Series: drm/i915: Per-crtc/connector DRRS debugfs URL : https://patchwork.freedesktop.org/series/109175/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12193_full -> Patchwork_109175v1_full Summary -

Re: [Intel-gfx] [PATCH] drm/i915/guc: do not capture error state on exiting context

On 29/09/2022 10:49, Andrzej Hajda wrote: On 29.09.2022 10:22, Tvrtko Ursulin wrote: On 28/09/2022 19:27, John Harrison wrote: On 9/28/2022 00:19, Tvrtko Ursulin wrote: On 27/09/2022 22:36, Ceraolo Spurio, Daniele wrote: On 9/27/2022 12:45 AM, Tvrtko Ursulin wrote: On 27/09/2022 07:49, And

Re: [Intel-gfx] [PATCH 02/10] drm/i915: Split up intel_color_init()

On Thu, 29 Sep 2022, Ville Syrjala wrote: > From: Ville Syrjälä > > intel_color_init() does both device level and crtc level stuff. > Split it up accordingly. > > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/display/intel_color.c | 15 +-- > drivers/gpu/drm/i915/displ

Re: [Intel-gfx] [PATCH 05/16] drm/i915/vm_bind: Implement bind and unbind of object

On 28/09/2022 07:19, Niranjana Vishwanathapura wrote: Add uapi and implement support for bind and unbind of an object at the specified GPU virtual addresses. The vm_bind mode is not supported in legacy execbuf2 ioctl. It will be supported only in the newer execbuf3 ioctl. Signed-off-by: Niranja

Re: [Intel-gfx] [PATCH 05/16] drm/i915/vm_bind: Implement bind and unbind of object

On 29/09/2022 10:03, Matthew Auld wrote: On 29/09/2022 06:24, Niranjana Vishwanathapura wrote: On Wed, Sep 28, 2022 at 06:52:21PM +0100, Matthew Auld wrote: On 28/09/2022 07:19, Niranjana Vishwanathapura wrote: Add uapi and implement support for bind and unbind of an object at the specified GP

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gt: Flush to global observation point before breadcrumb write

Hi, >Series: drm/i915/gt: Flush to global observation point before >breadcrumb write >URL: [1]https://patchwork.freedesktop.org/series/109133/ >State: failure >Details: >[2]https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109133v1/index.ht >ml > > CI Bug Log - c

[Intel-gfx] [PATCH 0/5] drm/i915/mtl: Add C10 support

PHY programming support for message bus and phy programming. Updates for HDMI programming and vswing tables. Radhakrishna Sripada (5): drm/i915/mtl: Add Support for C10,C20 PHY Message Bus drm/i915/mtl: Add PLL programming support for C10 phy drm/i915/mtl: Add support for C10 phy programming

[Intel-gfx] [PATCH 3/5] drm/i915/mtl: Add support for C10 phy programming

From: Radhakrishna Sripada Add sequences for C10 phy enable/disable phy lane reset, powerdown change sequence and phy lane programming. Bspec: 64539, 67636, 65451, 65450, 64568 Cc: Imre Deak Cc: Mika Kahola Cc: Uma Shankar Signed-off-by: Radhakrishna Sripada Signed-off-by: Mika Kahola (v9)

[Intel-gfx] [PATCH 5/5] drm/i915/mtl: Add vswing programming for C10 phys

From: Radhakrishna Sripada C10 phys uses direct mapping internally for voltage and pre-emphasis levels. Program the levels directly to the fields in the VDR Registers. Bspec: 65449 Cc: Imre Deak Cc: Mika Kahola Cc: Uma Shankar Signed-off-by: Clint Taylor Signed-off-by: Radhakrishna Sripada

[Intel-gfx] [PATCH 2/5] drm/i915/mtl: Add PLL programming support for C10 phy

From: Radhakrishna Sripada XELPDP has C10 phys to drive output to the EDP and the native output from the display engine. Add structures, programming hardware state readout logic. Port clock calculations are similar to DG2. Use the DG2 formulae to calculate the port clock but use the relevant pll

[Intel-gfx] [PATCH 4/5] drm/i915/mtl: Add C10 phy programming for HDMI

From: Radhakrishna Sripada Like DG2, we still don't have a proper algorithm that can be used for calculating PHY settings, but we do have tables of register values for a handful of the more common link rates. Some support is better than none, so let's go ahead and add/use these tables when we can

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for iommu: Remove iova cpu hotplugging flushing (rev2)

On Thursday, 29 September 2022 11:35:23 CEST Patchwork wrote: > == Series Details == > > Series: iommu: Remove iova cpu hotplugging flushing (rev2) > URL : https://patchwork.freedesktop.org/series/108880/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_12193_full -> Pa

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Fix a potential UAF at device unload

Hi Nirmoy, On Fri, Sep 23, 2022 at 09:35:14AM +0200, Nirmoy Das wrote: > i915_gem_drain_freed_objects() might not be enough to > free all the objects and RCU delayed work might get > scheduled after the i915 device struct gets freed. > > Call i915_gem_drain_workqueue() to catch all RCU delayed wo

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Fix a potential UAF at device unload

On 9/29/2022 1:32 PM, Andi Shyti wrote: Hi Nirmoy, On Fri, Sep 23, 2022 at 09:35:14AM +0200, Nirmoy Das wrote: i915_gem_drain_freed_objects() might not be enough to free all the objects and RCU delayed work might get scheduled after the i915 device struct gets freed. Call i915_gem_drain_work

[Intel-gfx] [PATCH v5] drm/i915/mtl: enable local stolen memory

As an integrated GPU, MTL does not have local memory and HAS_LMEM() returns false. However the platform's stolen memory is presented via BAR2 (i.e., the BAR we traditionally consider to be the GMADR on IGFX) and should be managed by the driver the same way that local memory is on dgpu platforms (w

Re: [Intel-gfx] [PATCH 01/10] drm/i915: Remove PLL asserts from .load_luts()

On Thu, 29 Sep 2022, Ville Syrjala wrote: > From: Ville Syrjälä > > .load_luts() potentially runs from the vblank worker, and is > under a deadline to complete within the vblank. Thus we can't > do expesive stuff like talk to the Punit, etc. > > To that end get rid of the assert_dsi_pll_enabled()

Re: [Intel-gfx] [PATCH 02/10] drm/i915: Split up intel_color_init()

On Thu, 29 Sep 2022, Jani Nikula wrote: > On Thu, 29 Sep 2022, Ville Syrjala wrote: >> From: Ville Syrjälä >> >> intel_color_init() does both device level and crtc level stuff. >> Split it up accordingly. >> >> Signed-off-by: Ville Syrjälä >> --- >> drivers/gpu/drm/i915/display/intel_color.c

Re: [Intel-gfx] [PATCH 03/10] drm/i915: Simplify the intel_color_init_hooks() if ladder

On Thu, 29 Sep 2022, Ville Syrjala wrote: > From: Ville Syrjälä > > Get rid of the funny hsw vs. ivb extra indentation level in > intel_color_init_hooks(). > > Signed-off-by: Ville Syrjälä Reviewed-by: Jani Nikula > --- > drivers/gpu/drm/i915/display/intel_color.c | 11 +-- > 1 file

Re: [Intel-gfx] [PATCH 04/10] drm/i915: Clean up intel_color_init_hooks()

On Thu, 29 Sep 2022, Ville Syrjala wrote: > From: Ville Syrjälä > > Remove a bunch of pointless curly brackets and do > the s/dev_priv/i915/ while at it. > > Signed-off-by: Ville Syrjälä Reviewed-by: Jani Nikula > --- > drivers/gpu/drm/i915/display/intel_color.c | 43 +++--- >

Re: [Intel-gfx] [PATCH 05/10] drm/i915: Change glk_load_degamma_lut() calling convention

On Thu, 29 Sep 2022, Ville Syrjala wrote: > From: Ville Syrjälä > > Make glk_load_degamma_lut() more like most everyone else and > pass in the LUT explicitly. > > Signed-off-by: Ville Syrjälä Reviewed-by: Jani Nikula > --- > drivers/gpu/drm/i915/display/intel_color.c | 17 ++--- >

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/mtl: enable local stolen memory (rev4)

== Series Details == Series: drm/i915/mtl: enable local stolen memory (rev4) URL : https://patchwork.freedesktop.org/series/109066/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12193_full -> Patchwork_109066v4_full Summary

[Intel-gfx] Information about XDC 2022 - next week!

Hi folks, We are excited to welcome you in person to the 2022 X.Org Developers Conference, held in conjunction with WineConf and FOSS XR conference. The conference will start officially on Tuesday morning, October 4th. The program is here: https://indico.freedesktop.org/event/2/timetable/

[Intel-gfx] [PATCH] drm/i915/gvt: fix double free bug in split_2MB_gtt_entry

If intel_gvt_dma_map_guest_page failed, it will call ppgtt_invalidate_spt, which will finally free the spt. But the caller does not notice that, it will free spt again in error path. Fix this by only freeing spt in ppgtt_invalidate_spt in good case. Fixes: b901b252b6cf ("drm/i915/gvt: Add 2M huge

Re: [Intel-gfx] [PATCH v3] drm/i915/psr: Fix PSR_IMR/IIR field handling

On Tue, 2022-09-27 at 14:09 +0300, Jouni Högander wrote: > Current PSR code is supposed to use TRANSCODER_EDP to force 0 shift for > bits in PSR_IMR/IIR registers: > > /* > * gen12+ has registers relative to transcoder and one per transcoder > * using the same bit definition: handle it as TRANSC

Re: [Intel-gfx] [PATCH v3] drm/i915/psr: Fix PSR_IMR/IIR field handling

On Thu, 2022-09-29 at 06:16 -0700, José Roberto de Souza wrote: > On Tue, 2022-09-27 at 14:09 +0300, Jouni Högander wrote: > > Current PSR code is supposed to use TRANSCODER_EDP to force 0 shift for > > bits in PSR_IMR/IIR registers: > > > > /* > > * gen12+ has registers relative to transcoder an

[Intel-gfx] [PATCH 0/5] drm/i915/mtl: Add C10 phy support

PHY programming support for message bus and phy programming. Updates for HDMI programming and vswing tables. Radhakrishna Sripada (5): drm/i915/mtl: Add Support for C10,C20 PHY Message Bus drm/i915/mtl: Add PLL programming support for C10 phy drm/i915/mtl: Add support for C10 phy programming

[Intel-gfx] [PATCH 2/5] drm/i915/mtl: Add PLL programming support for C10 phy

From: Radhakrishna Sripada XELPDP has C10 phys to drive output to the EDP and the native output from the display engine. Add structures, programming hardware state readout logic. Port clock calculations are similar to DG2. Use the DG2 formulae to calculate the port clock but use the relevant pll

[Intel-gfx] [PATCH 3/5] drm/i915/mtl: Add support for C10 phy programming

From: Radhakrishna Sripada Add sequences for C10 phy enable/disable phy lane reset, powerdown change sequence and phy lane programming. Bspec: 64539, 67636, 65451, 65450, 64568 Cc: Imre Deak Cc: Mika Kahola Cc: Uma Shankar Signed-off-by: Radhakrishna Sripada Signed-off-by: Mika Kahola (v9)

[Intel-gfx] [PATCH 4/5] drm/i915/mtl: Add C10 phy programming for HDMI

From: Radhakrishna Sripada Like DG2, we still don't have a proper algorithm that can be used for calculating PHY settings, but we do have tables of register values for a handful of the more common link rates. Some support is better than none, so let's go ahead and add/use these tables when we can

[Intel-gfx] [PATCH 1/5] drm/i915/mtl: Add Support for C10, C20 PHY Message Bus

From: Radhakrishna Sripada XELPDP has C10 and C20 phys from Synopsys to drive displays. Each phy has a dedicated PIPE 5.2 Message bus for configuration. This message bus is used to configure the phy internal registers. Bspec: 64599, 65100, 65101, 67610, 67636 Cc: Mika Kahola Cc: Imre Deak Cc:

[Intel-gfx] [PATCH 5/5] drm/i915/mtl: Add vswing programming for C10 phys

From: Radhakrishna Sripada C10 phys uses direct mapping internally for voltage and pre-emphasis levels. Program the levels directly to the fields in the VDR Registers. Bspec: 65449 Cc: Imre Deak Cc: Mika Kahola Cc: Uma Shankar Signed-off-by: Clint Taylor Signed-off-by: Radhakrishna Sripada

Re: [Intel-gfx] [PATCH] drm/i915/gt: Flush to global observation point before breadcrumb write

Hi Nirmoy, > From: Prathap Kumar Valsan > > Add flag to pipecontrol instruction to ensure in-flight writes are > flushed to global observation point. Also split the pipecontrol > instruction like we have in gen8. > > References: https://gitlab.freedesktop.org/drm/intel/-/issues/5886 > Signed-of

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Reject excessive dotclocks early (rev2)

== Series Details == Series: drm/i915: Reject excessive dotclocks early (rev2) URL : https://patchwork.freedesktop.org/series/109141/ State : success == Summary == CI Bug Log - changes from CI_DRM_12193_full -> Patchwork_109141v2_full Summa

Re: [Intel-gfx] [PATCH 05/16] drm/i915/vm_bind: Implement bind and unbind of object

On Thu, Sep 29, 2022 at 11:51:51AM +0100, Matthew Auld wrote: On 29/09/2022 10:03, Matthew Auld wrote: On 29/09/2022 06:24, Niranjana Vishwanathapura wrote: On Wed, Sep 28, 2022 at 06:52:21PM +0100, Matthew Auld wrote: On 28/09/2022 07:19, Niranjana Vishwanathapura wrote: Add uapi and impleme

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

Hi Dave, Daniel, A few fixes for the upcoming merge window. Not many but most are pretty important. Another rather important one is missing due being too conflicty, but will arrive via drm-intel-fixes (7738be973fc4 ("drm/i915/gt: Perf_limit_reasons are only available for Gen11+")). Regards, Tvr

Re: [Intel-gfx] [PATCH] drm/i915/guc: do not capture error state on exiting context

On 9/29/2022 3:40 AM, Tvrtko Ursulin wrote: On 29/09/2022 10:49, Andrzej Hajda wrote: On 29.09.2022 10:22, Tvrtko Ursulin wrote: On 28/09/2022 19:27, John Harrison wrote: On 9/28/2022 00:19, Tvrtko Ursulin wrote: On 27/09/2022 22:36, Ceraolo Spurio, Daniele wrote: On 9/27/2022 12:45 AM,

Re: [Intel-gfx] [PATCH 06/16] drm/i915/vm_bind: Support for VM private BOs

On Wed, Sep 28, 2022 at 06:54:27PM +0100, Matthew Auld wrote: On 28/09/2022 07:19, Niranjana Vishwanathapura wrote: Each VM creates a root_obj and shares it with all of its private objects to use it as dma_resv object. This has a performance advantage as it requires a single dma_resv object upda

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

Hi Dave and Daniel, this is the PR for drm-misc-fixes for this week. Best regards Thomas drm-misc-fixes-2022-09-29: Short summary of fixes pull: * bridge/analogix: Revert earlier suspend fix * bridge/lt8912b: Fix corrupt display output The following changes since commit d8a79c03054911c375a225

Re: [Intel-gfx] [PATCH 12/16] drm/i915/vm_bind: Implement I915_GEM_EXECBUFFER3 ioctl

On 28/09/2022 07:19, Niranjana Vishwanathapura wrote: Implement new execbuf3 ioctl (I915_GEM_EXECBUFFER3) which only works in vm_bind mode. The vm_bind mode only works with this new execbuf3 ioctl. The new execbuf3 ioctl will not have any list of objects to validate bind as all required objects

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/mtl: Define engine context layouts

== Series Details == Series: drm/i915/mtl: Define engine context layouts URL : https://patchwork.freedesktop.org/series/109190/ State : success == Summary == CI Bug Log - changes from CI_DRM_12193_full -> Patchwork_109190v1_full Summary ---

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

Hi Dave and Daniel, Here goes drm-intel-fixes-2022-09-29: - Restrict forced preemption to the active context (Chris) - Restrict perf_limit_reasons to the supported platforms - gen11+ (Ashutosh) Thanks, Rodrigo. The following changes since commit f76349cf41451c5c42a99f18a9163377e4b364ff: Linu

Re: [Intel-gfx] [PATCH 12/16] drm/i915/vm_bind: Implement I915_GEM_EXECBUFFER3 ioctl

On Thu, Sep 29, 2022 at 04:00:47PM +0100, Matthew Auld wrote: On 28/09/2022 07:19, Niranjana Vishwanathapura wrote: Implement new execbuf3 ioctl (I915_GEM_EXECBUFFER3) which only works in vm_bind mode. The vm_bind mode only works with this new execbuf3 ioctl. The new execbuf3 ioctl will not hav

Re: [Intel-gfx] [PATCH v4 3/4] drm/i915: Make the heartbeat play nice with long pre-emption timeouts

On 9/29/2022 00:42, Tvrtko Ursulin wrote: On 29/09/2022 03:18, john.c.harri...@intel.com wrote: From: John Harrison Compute workloads are inherently not pre-emptible for long periods on current hardware. As a workaround for this, the pre-emption timeout for compute capable engines was disabled

[Intel-gfx] [PATCH v4 00/30] drm: Analog TV Improvements

Hi, Here's a series aiming at improving the command line named modes support, and more importantly how we deal with all the analog TV variants. The named modes support were initially introduced to allow to specify the analog TV mode to be used. However, this was causing multiple issues: * The

[Intel-gfx] [PATCH v4 01/30] drm/docs: Remove unused TV Standard property

That property is not used or exposed by any driver in the kernel. Remove it from the documentation. Signed-off-by: Maxime Ripard --- Changes in v4: - New patch --- Documentation/gpu/kms-properties.csv | 1 - 1 file changed, 1 deletion(-) diff --git a/Documentation/gpu/kms-properties.csv b/Doc

[Intel-gfx] [PATCH v4 02/30] drm/tests: Order Kunit tests in Makefile

Since we've recently added a ton of tests, the list starts to be a bit of a mess and creates unneeded conflicts. Let's order it alphabetically. Acked-by: Thomas Zimmermann Reviewed-by: Noralf Trønnes Signed-off-by: Maxime Ripard --- drivers/gpu/drm/tests/Makefile | 14 +++--- 1 file c

[Intel-gfx] [PATCH v4 03/30] drm/tests: Add Kunit Helpers

As the number of kunit tests in KMS grows further, we start to have multiple test suites that, for example, need to register a mock DRM driver to interact with the KMS function they are supposed to test. Let's add a file meant to provide those kind of helpers to avoid duplication. Signed-off-by:

[Intel-gfx] [PATCH v4 04/30] drm/atomic-helper: Rename drm_atomic_helper_connector_tv_reset to avoid ambiguity

We currently have two sets of TV properties. The first one is there to deal with analog TV properties, creating properties such as the TV mode, subconnectors, saturation, hue and so on. It's created by calling the drm_mode_create_tv_properties() function. The second one is there to deal with prop

[Intel-gfx] [PATCH v4 05/30] drm/connector: Rename subconnector state variable

There is two TV subconnector related properties registered by drm_mode_create_tv_properties(): subconnector and select subconnector. While the select subconnector property is stored in the kernel by the drm_tv_connector_state structure, the subconnector property isn't stored anywhere. Worse, the

[Intel-gfx] [PATCH v4 06/30] drm/atomic: Add TV subconnector property to get/set_property

The subconnector property was created by drm_mode_create_tv_properties(), but wasn't exposed to the userspace through the generic atomic_get/set_property implementation, and wasn't stored in any generic state structure. Let's solve this. Reviewed-by: Noralf Trønnes Signed-off-by: Maxime Ripard

[Intel-gfx] [PATCH v4 07/30] drm/connector: Rename legacy TV property

The current tv_mode has driver-specific values that don't allow to easily share code using it, either at the userspace or kernel level. Since we're going to introduce a new, generic, property that fit the same purpose, let's rename this one to legacy_tv_mode to make it obvious we should move away

[Intel-gfx] [PATCH v4 12/30] drm/modes: Only consider bpp and refresh before options

Some video= options might have a value that contains a dash. However, the command line parsing mode considers all dashes as the separator between the mode and the bpp count. Let's rework the parsing code a bit to only consider a dash as the bpp separator if it before a comma, the options separator

[Intel-gfx] [PATCH v4 14/30] drm/client: Add some tests for drm_connector_pick_cmdline_mode()

drm_connector_pick_cmdline_mode() is in charge of finding a proper drm_display_mode from the definition we got in the video= command line argument. Let's add some unit tests to make sure we're not getting any regressions there. Signed-off-by: Maxime Ripard --- Changes in v4: - Removed MODULE ma

[Intel-gfx] [PATCH v4 08/30] drm/connector: Only register TV mode property if present

The drm_create_tv_properties() will create the TV mode property unconditionally. However, since we'll gradually phase it out, let's register it only if we have a list passed as an argument. This will make the transition easier. Acked-by: Noralf Trønnes Signed-off-by: Maxime Ripard --- drivers/

[Intel-gfx] [PATCH v4 11/30] drm/modes: Add a function to generate analog display modes

Multiple drivers (meson, vc4, sun4i) define analog TV 525-lines and 625-lines modes in their drivers. Since those modes are fairly standard, and that we'll need to use them in more places in the future, it makes sense to move their definition into the core framework. However, analog display usual

[Intel-gfx] [PATCH v4 09/30] drm/connector: Rename drm_mode_create_tv_properties

drm_mode_create_tv_properties(), among other things, will create the "mode" property that stores the analog TV mode that connector is supposed to output. However, that property is getting deprecated, so let's rename that function to mention it's deprecated. We'll introduce a new variant of that fu

[Intel-gfx] [PATCH v4 10/30] drm/connector: Add TV standard property

The TV mode property has been around for a while now to select and get the current TV mode output on an analog TV connector. Despite that property name being generic, its content isn't and has been driver-specific which makes it hard to build any generic behaviour on top of it, both in kernel and

[Intel-gfx] [PATCH v4 13/30] drm/modes: parse_cmdline: Add support for named modes containing dashes

From: Geert Uytterhoeven It is fairly common for named video modes to contain dashes (e.g. "tt-mid" on Atari, "dblntsc-ff" on Amiga). Currently such mode names are not recognized, as the dash is considered to be a separator between mode name and bpp. Fix this by skipping any dashes that are not

[Intel-gfx] [PATCH v4 18/30] drm/connector: Add pixel clock to cmdline mode

We'll need to get the pixel clock to generate proper display modes for all the current named modes. Let's add it to struct drm_cmdline_mode and fill it when parsing the named mode. Signed-off-by: Maxime Ripard --- drivers/gpu/drm/drm_modes.c | 9 ++--- include/drm/drm_connector.h | 7 +++

[Intel-gfx] [PATCH v4 15/30] drm/modes: Move named modes parsing to a separate function

The current construction of the named mode parsing doesn't allow to extend it easily. Let's move it to a separate function so we can add more parameters and modes. In order for the tests to still pass, some extra checks are needed, so it's not a 1:1 move. Signed-off-by: Maxime Ripard --- Change

[Intel-gfx] [PATCH v4 16/30] drm/modes: Switch to named mode descriptors

The current named mode parsing relies only the mode name, and doesn't allow to specify any other parameter. Let's convert that string list to an array of a custom structure that will hold the name and some additional parameters in the future. Signed-off-by: Maxime Ripard --- drivers/gpu/drm/drm

[Intel-gfx] [PATCH v4 25/30] drm/vc4: vec: Fix definition of PAL-M mode

From: Mateusz Kwiatkowski PAL-M is a Brazilian analog TV standard that uses a PAL-style chroma subcarrier at 3.575611[888111] MHz on top of 525-line (480i60) timings. This commit makes the driver actually use the proper VEC preset for this mode instead of just changing PAL subcarrier frequency.

[Intel-gfx] [PATCH v4 26/30] drm/vc4: vec: Use TV Reset implementation

The analog TV properties created by the drm_mode_create_tv_properties() are not properly initialised at reset. Let's switch our implementation to call drm_atomic_helper_connector_tv_reset(). Reviewed-by: Noralf Trønnes Signed-off-by: Maxime Ripard --- drivers/gpu/drm/vc4/vc4_vec.c | 8 +++-

[Intel-gfx] [PATCH v4 19/30] drm/connector: Add a function to lookup a TV mode by its name

As part of the command line parsing rework coming in the next patches, we'll need to lookup drm_connector_tv_mode values by their name, already defined in drm_tv_mode_enum_list. In order to avoid any code duplication, let's do a function that will perform a lookup of a TV mode name and return its

[Intel-gfx] [PATCH v4 28/30] drm/vc4: vec: Convert to the new TV mode property

Now that the core can deal fine with analog TV modes, let's convert the vc4 VEC driver to leverage those new features. We've added some backward compatibility to support the old TV mode property and translate it into the new TV norm property. We're also making use of the new analog TV atomic_check

[Intel-gfx] [PATCH v4 29/30] drm/vc4: vec: Add support for more analog TV standards

From: Mateusz Kwiatkowski Add support for the following composite output modes (all of them are somewhat more obscure than the previously defined ones): - NTSC_443 - NTSC-style signal with the chroma subcarrier shifted to 4.43361875 MHz (the PAL subcarrier frequency). Never used for broadcas

[Intel-gfx] [PATCH v4 20/30] drm/modes: Introduce the tv_mode property as a command-line option

Our new tv mode option allows to specify the TV mode from a property. However, it can still be useful, for example to avoid any boot time artifact, to set that property directly from the kernel command line. Let's add some code to allow it, and some unit tests to exercise that code. Signed-off-by

[Intel-gfx] [PATCH v4 21/30] drm/modes: Properly generate a drm_display_mode from a named mode

The framework will get the drm_display_mode from the drm_cmdline_mode it got by parsing the video command line argument by calling drm_connector_pick_cmdline_mode(). The heavy lifting will then be done by the drm_mode_create_from_cmdline_mode() function. In the case of the named modes though, the

[Intel-gfx] [PATCH v4 23/30] drm/atomic-helper: Add a TV properties reset helper

The drm_tv_create_properties() function will create a bunch of properties, but it's up to each and every driver using that function to properly reset the state of these properties leading to inconsistent behaviours. Let's create a helper that will take care of it. Reviewed-by: Noralf Trønnes Sig

[Intel-gfx] [PATCH v4 27/30] drm/vc4: vec: Check for VEC output constraints

From: Mateusz Kwiatkowski The VEC can accept pretty much any relatively reasonable mode, but still has a bunch of constraints to meet. Let's create an atomic_check() implementation that will make sure we don't end up accepting a non-functional mode. Acked-by: Noralf Trønnes Signed-off-by: Mate

[Intel-gfx] [PATCH v4 30/30] drm/sun4i: tv: Convert to the new TV mode property

Now that the core can deal fine with analog TV modes, let's convert the sun4i TV driver to leverage those new features. Signed-off-by: Maxime Ripard --- drivers/gpu/drm/sun4i/sun4i_tv.c | 148 ++- drivers/gpu/drm/vc4/vc4_vec.c| 5 +- 2 files changed, 54

[Intel-gfx] [PATCH v4 22/30] drm/modes: Introduce more named modes

Now that we can easily extend the named modes list, let's add a few more analog TV modes that were used in the wild, and some unit tests to make sure it works as intended. Signed-off-by: Maxime Ripard --- drivers/gpu/drm/drm_modes.c | 2 + drivers/gpu/drm/tests/drm_client_mo

[Intel-gfx] [PATCH v4 24/30] drm/atomic-helper: Add an analog TV atomic_check implementation

The analog TV connector drivers share some atomic_check logic, and the new TV standard property have created some boilerplate that can be be shared across drivers too. Let's create an atomic_check helper for those use cases. Reviewed-by: Noralf Trønnes Signed-off-by: Maxime Ripard --- drivers/

[Intel-gfx] [PATCH v4 17/30] drm/modes: Fill drm_cmdline mode from named modes

The current code to deal with named modes will only set the mode name, and then it's up to drivers to try to match that name to whatever mode or configuration they see fit. The plan is to remove that need and move the named mode handling out of drivers and into the core, and only rely on modes and

Re: [Intel-gfx] [PATCH 05/16] drm/i915/vm_bind: Implement bind and unbind of object

On Thu, Sep 29, 2022 at 11:49:30AM +0100, Matthew Auld wrote: On 28/09/2022 07:19, Niranjana Vishwanathapura wrote: Add uapi and implement support for bind and unbind of an object at the specified GPU virtual addresses. The vm_bind mode is not supported in legacy execbuf2 ioctl. It will be supp

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/gt: Flush to global observation point before breadcrumb write (rev2)

== Series Details == Series: drm/i915/gt: Flush to global observation point before breadcrumb write (rev2) URL : https://patchwork.freedesktop.org/series/109133/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2

Re: [Intel-gfx] [PATCH] drm/i915: Fix CFI violations in gt_sysfs

Hi Nathan, thanks for this refactoring... looks good even though i would have split it in more patches as this is doing quite many things. But I will not be stubborn, I understand that it's not trivial to have things split. I will give my r-b for now but I will check it again before applying it a

Re: [Intel-gfx] [PATCH] drm/i915/guc: do not capture error state on exiting context

On 9/29/2022 01:22, Tvrtko Ursulin wrote: On 28/09/2022 19:27, John Harrison wrote: On 9/28/2022 00:19, Tvrtko Ursulin wrote: On 27/09/2022 22:36, Ceraolo Spurio, Daniele wrote: On 9/27/2022 12:45 AM, Tvrtko Ursulin wrote: On 27/09/2022 07:49, Andrzej Hajda wrote: On 27.09.2022 01:34, Ceraol

  1   2   >