[Intel-gfx] [PATCH v6 20/23] 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:

[Intel-gfx] [PATCH v6 23/23] 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. Acked-by: Noralf Trønnes Reviewed-by: Jernej Skrabec Signed-off-by: Maxime Ripard --- Changes in v6: - Convert to new get_modes helper Changes in v5: - Removed the count

[Intel-gfx] [PATCH v6 15/23] 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 --- Changes in v6: - Renamed the tests to follow DRM test naming convention Changes in v5: -

[Intel-gfx] [PATCH v6 17/23] 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

[Intel-gfx] [PATCH v6 19/23] 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 v6 16/23] drm/probe-helper: Provide a TV get_modes helper

Most of the TV connectors will need a similar get_modes implementation that will, depending on the drivers' capabilities, register the 480i and 576i modes. That implementation will also need to set the preferred flag and order the modes based on the driver and users preferrence. This is

[Intel-gfx] [PATCH v6 18/23] 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 ---

[Intel-gfx] [PATCH v6 14/23] 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,

[Intel-gfx] [PATCH v6 12/23] 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 v6 10/23] 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

[Intel-gfx] [PATCH v6 13/23] 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.

[Intel-gfx] [PATCH v6 09/23] 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 ---

[Intel-gfx] [PATCH v6 11/23] 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 v6 08/23] 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 ---

[Intel-gfx] [PATCH v6 06/23] 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

[Intel-gfx] [PATCH v6 05/23] 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 v6 03/23] 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 ---

[Intel-gfx] [PATCH v6 00/23] 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: *

[Intel-gfx] [PATCH v6 07/23] 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. Acked-by: Noralf Trønnes Signed-off-by: Maxime Ripard --- Changes

[Intel-gfx] [PATCH v6 02/23] 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 v6 04/23] 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

[Intel-gfx] [PATCH v6 01/23] 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. Reviewed-by:

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/slpc: Optmize waitboost for SLPC (rev7)

== Series Details == Series: drm/i915/slpc: Optmize waitboost for SLPC (rev7) URL : https://patchwork.freedesktop.org/series/109840/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12294_full -> Patchwork_109840v7_full

[Intel-gfx] ✗ Fi.CI.BAT: failure for Fix Guc-Err-Capture sizing warning

== Series Details == Series: Fix Guc-Err-Capture sizing warning URL : https://patchwork.freedesktop.org/series/110176/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12297 -> Patchwork_110176v1 Summary ---

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Fix Guc-Err-Capture sizing warning

== Series Details == Series: Fix Guc-Err-Capture sizing warning URL : https://patchwork.freedesktop.org/series/110176/ State : warning == Summary == Error: dim checkpatch failed 7872137a691b drm/i915/guc: Fix GuC error capture sizing estimation and reporting -:24: WARNING:BAD_FIXES_TAG:

[Intel-gfx] ✗ Fi.CI.BAT: failure for freezer, sched: Rewrite core freezer logic fix

== Series Details == Series: freezer, sched: Rewrite core freezer logic fix URL : https://patchwork.freedesktop.org/series/110173/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12297 -> Patchwork_110173v1 Summary ---

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for freezer, sched: Rewrite core freezer logic fix

== Series Details == Series: freezer, sched: Rewrite core freezer logic fix URL : https://patchwork.freedesktop.org/series/110173/ State : warning == Summary == Error: dim checkpatch failed 873d9a285e35 freezer, sched: Rewrite core freezer logic fix -:12: WARNING:COMMIT_LOG_LONG_LINE:

[Intel-gfx] [PATCH v5 1/1] drm/i915/guc: Fix GuC error capture sizing estimation and reporting

During GuC error capture initialization, we estimate the amount of size we need for the error-capture-region of the shared GuC-log-buffer. This calculation was incorrect so fix that. With the fixed calculation we can reduce the allocation of error-capture region from 4MB to 1MB (see note2 below

[Intel-gfx] [PATCH v5 0/1] Fix Guc-Err-Capture sizing warning

GuC Error capture initialization calculates an estimation buffer size for worst case scenario of all engines getting reset. Fix the calculation change from drm_warn to drm_dbg since its a corner case Changes from prior revs: v5: - Fixed "fixes" tag + added R-b that was received from v3. v3:

Re: [Intel-gfx] [PATCH 20/20] drm/i915/mtl: Pin assignment for TypeC

On Fri, Oct 14, 2022 at 03:47:40PM +0300, Mika Kahola wrote: > From: Anusha Srivatsa > > Unlike previous platforms that used PORT_TX_DFLEXDPSP > for max_lane calculation, MTL uses only PORT_TX_DFLEXPA1 > from which the max_lanes has to be calculated. > > Bspec: 50235, 65380 > Cc: Mika Kahola >

Re: [Intel-gfx] [PATCH v5 17/19] drm/i915/vm_bind: Limit vm_bind mode to non-recoverable contexts

On 25/10/2022 07:59, Niranjana Vishwanathapura wrote: Only support vm_bind mode with non-recoverable contexts. With new vm_bind mode with eb3 submission path, we need not support older recoverable contexts. Signed-off-by: Niranjana Vishwanathapura Reviewed-by: Matthew Auld

[Intel-gfx] [PATCH CI] freezer, sched: Rewrite core freezer logic fix

From: Peter Zijlstra On Wed, Oct 26, 2022 at 01:32:31PM +0300, Ville Syrjälä wrote: > Short form looks to be this: > <4>[ 355.437846] 1 lock held by rs:main Q:Reg/359: > <4>[ 355.438418] #0: 88844693b758 (>__lock){-.-.}-{2:2}, at: > raw_spin_rq_lock_nested+0x1b/0x30 > <4>[ 355.438432]

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/tgl+: Fix race conditions during DKL PHY accesses (rev5)

On Tue, Oct 25, 2022 at 08:04:12PM +, Patchwork wrote: > == Series Details == > > Series: drm/i915/tgl+: Fix race conditions during DKL PHY accesses (rev5) > URL : https://patchwork.freedesktop.org/series/109963/ > State : failure > > == Summary == > > CI Bug Log - changes from

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: More gamma work

== Series Details == Series: drm/i915: More gamma work URL : https://patchwork.freedesktop.org/series/110168/ State : success == Summary == CI Bug Log - changes from CI_DRM_12296 -> Patchwork_110168v1 Summary --- **SUCCESS** No

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Fix CFI violations in gt_sysfs (rev5)

== Series Details == Series: drm/i915: Fix CFI violations in gt_sysfs (rev5) URL : https://patchwork.freedesktop.org/series/108917/ State : success == Summary == CI Bug Log - changes from CI_DRM_12294_full -> Patchwork_108917v5_full

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: More gamma work

== Series Details == Series: drm/i915: More gamma work URL : https://patchwork.freedesktop.org/series/110168/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.

Re: [Intel-gfx] [PATCH v3 6/6] freezer, sched: Rewrite core freezer logic

On Wed, Oct 26, 2022 at 02:12:02PM +0200, Peter Zijlstra wrote: > On Wed, Oct 26, 2022 at 01:43:00PM +0200, Peter Zijlstra wrote: > > On Wed, Oct 26, 2022 at 01:32:31PM +0300, Ville Syrjälä wrote: > > > Short form looks to be this: > > > <4>[ 355.437846] 1 lock held by rs:main Q:Reg/359: > > >

Re: [Intel-gfx] [PATCH v3 6/6] freezer, sched: Rewrite core freezer logic

On Wed, Oct 26, 2022 at 01:43:00PM +0200, Peter Zijlstra wrote: > On Wed, Oct 26, 2022 at 01:32:31PM +0300, Ville Syrjälä wrote: > > Short form looks to be this: > > <4>[ 355.437846] 1 lock held by rs:main Q:Reg/359: > > <4>[ 355.438418] #0: 88844693b758 (>__lock){-.-.}-{2:2}, at: > >

Re: [Intel-gfx] [PATCH v3 3/7] drm/ivpu: Add GEM buffer object management

(cc: Thomas, Christian, intel-gfx) Hi Am 26.10.22 um 13:26 schrieb Jacek Lawrynowicz: Hi, On 10/25/2022 2:41 PM, Thomas Zimmermann wrote: Hi Am 24.09.22 um 17:11 schrieb Jacek Lawrynowicz: Adds four types of GEM-based BOs for the VPU:    - shmem    - userptr    - internal    - prime

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: stop abusing swiotlb_max_segment (rev7)

== Series Details == Series: drm/i915: stop abusing swiotlb_max_segment (rev7) URL : https://patchwork.freedesktop.org/series/109946/ State : success == Summary == CI Bug Log - changes from CI_DRM_12296 -> Patchwork_109946v7 Summary

Re: [Intel-gfx] [PATCH v3 6/6] freezer, sched: Rewrite core freezer logic

On Wed, Oct 26, 2022 at 01:32:31PM +0300, Ville Syrjälä wrote: > Short form looks to be this: > <4>[ 355.437846] 1 lock held by rs:main Q:Reg/359: > <4>[ 355.438418] #0: 88844693b758 (>__lock){-.-.}-{2:2}, at: > raw_spin_rq_lock_nested+0x1b/0x30 > <4>[ 355.438432] rs:main Q:Reg/359

[Intel-gfx] [PATCH 09/11] drm/i915: Reject YCbCr output with degamma+gamma on pre-icl

From: Ville Syrjälä Since the pipe CSC sits between the degamma and gamma LUTs there is no way to make us it for RGB->YCbCr conversion when both LUTs are also active. Simply reject such combos. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_color.c | 18 --

[Intel-gfx] [PATCH 10/11] drm/i915: Share {csc, gamma}_enable calculation for ilk/snb vs. ivb+

From: Ville Syrjälä ilk/snb vs. ivb+ hardware is mostly identical except for the addition of the split gamma mode on ivb. Thus we can share the csc_enable and gamma_enable calculation for both variants. Pull that stuff into a few helpers. Note that this also fills in the missing ctm/degamma

[Intel-gfx] [PATCH 02/11] drm/i915: Use _MMIO_PIPE() for SKL_BOTTOM_COLOR

From: Ville Syrjälä No need to use _MMIO_PIPE2() for SKL_BOTTOM_COLOR since all pipe registers are evenly spread on skl+. Switch to _MMIO_PIPE() and thus avoid the hidden dev_priv. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_reg.h | 3 ++- 1 file changed, 2 insertions(+), 1

[Intel-gfx] [PATCH 08/11] drm/i915: Reuse ilk_gamma_mode() on ivb+

From: Ville Syrjälä Apart from the split gamma mode ivb+ LUTs work just like ilk+ LUTs. So let's handle the special case, and then just fall back to ilk_gamma_mode() to avoid having to duplicate the same logic. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_color.c | 10

[Intel-gfx] [PATCH 11/11] drm/i915: Create resized LUTs for ivb+ split gamma mode

From: Ville Syrjälä Currently when opeating in split gamma mode we do the "skip ever other sw LUT entry" trick in the low level LUT programming/readout functions. That is very annoying and a big hinderance to revamping the color management uapi. Let's get rid of that problem by making half

[Intel-gfx] [PATCH 06/11] drm/i915: Deconfuse the ilk+ 12.4 LUT entry functions

From: Ville Syrjälä s/icl_lut_multi_seg_pack/ilk_lut_12p4_pack/ since that's what it is and group the corresponding "unpack" functions next to it. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_color.c | 38 +++--- 1 file changed, 19 insertions(+), 19

[Intel-gfx] [PATCH 07/11] drm/i915: Pass limited_range explicitly to ilk_csc_convert_ctm()

From: Ville Syrjälä Since pre-icl vs. icl+ handle the limited range output stuff a bit differently it's probably less confusing if we just pass that information explicitly into ilk_csc_convert_ctm(). Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_color.c | 8 1

[Intel-gfx] [PATCH 03/11] drm/i915: s/dev_priv/i915/ in intel_color.c

From: Ville Syrjälä Switch intel_color.c over to the modern 'i915' variable naming scehme. The only exceptions are the i9xx LUT access functions which still need the magic 'dev_priv' for the register macros. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_color.c | 278

[Intel-gfx] [PATCH 05/11] drm/i915: Split ivb_load_lut_ext_max() into two parts

From: Ville Syrjälä Split the EXT2_MAX register progrmaming into its own funciton. More in line with the whole "cobble together stuff from small pieces" approach used in this code. The EXT(2)_MAX registers are also not really part of the multi-segment section of the LUT, so hoise the calls to a

[Intel-gfx] [PATCH 04/11] drm/i915: s/icl_load_gcmax/ivb_load_lut_max/

From: Ville Syrjälä Unify icl_load_gcmax() with the rest of the function naming scheme by calling it ivb_load_lut_max() instead. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_color.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git

[Intel-gfx] [PATCH 01/11] drm/i915: Use sizeof(variable) instead sizeof(type)

From: Ville Syrjälä Use sizeof(variable) instead of sizeof(type) in the hopes of less chance of screwing things up. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_color.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git

[Intel-gfx] [PATCH 00/11] drm/i915: More gamma work

From: Ville Syrjälä Another serires of (mostly) cleanups to the color management code. The one functional thing in there is the last patch that reworks how we handle the split gamma mode now that we have a way to cook up internal LUTs. Still not full readout+state check I'm afraid. That will

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/sdvo: Fix LVDS fixed mode setup and clean up output setup

== Series Details == Series: drm/i915/sdvo: Fix LVDS fixed mode setup and clean up output setup URL : https://patchwork.freedesktop.org/series/110167/ State : success == Summary == CI Bug Log - changes from CI_DRM_12296 -> Patchwork_110167v1

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: stop abusing swiotlb_max_segment (rev7)

== Series Details == Series: drm/i915: stop abusing swiotlb_max_segment (rev7) URL : https://patchwork.freedesktop.org/series/109946/ 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: success for series starting with [1/4] drm/i915/display: Change terminology for cdclk actions

== Series Details == Series: series starting with [1/4] drm/i915/display: Change terminology for cdclk actions URL : https://patchwork.freedesktop.org/series/110135/ State : success == Summary == CI Bug Log - changes from CI_DRM_12294_full -> Patchwork_110135v1_full

Re: [Intel-gfx] [PATCH v3 6/6] freezer, sched: Rewrite core freezer logic

On Tue, Oct 25, 2022 at 12:49:13PM +0200, Peter Zijlstra wrote: > On Tue, Oct 25, 2022 at 07:52:07AM +0300, Ville Syrjälä wrote: > > On Fri, Oct 21, 2022 at 08:22:41PM +0300, Ville Syrjälä wrote: > > > On Mon, Aug 22, 2022 at 01:18:22PM +0200, Peter Zijlstra wrote: > > > > +#ifdef CONFIG_LOCKDEP >

[Intel-gfx] [PATCH 7/8] drm/i915/sdvo: Reduce copy-pasta in output setup

From: Ville Syrjälä Avoid having to call the output init function for each output type separately. We can just call the right one based on the "class" of the output. Technically we could just walk the bits of the bitmask but that could change the order in which we initialize the outputs. To

[Intel-gfx] [PATCH 3/8] drm/i915/sdvo: Grab mode_config.mutex during LVDS init to avoid WARNs

From: Ville Syrjälä drm_mode_probed_add() is unhappy about being called w/o mode_config.mutex. Grab it during LVDS fixed mode setup to silence the WARNs. Cc: sta...@vger.kernel.org Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7301 Fixes: aa2b88074a56 ("drm/i915/sdvo: Fix multi

[Intel-gfx] [PATCH 8/8] drm/i915/sdvo: Fix debug print

From: Ville Syrjälä Correctly indicate which outputs we support in the debug print. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_sdvo.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c

[Intel-gfx] [PATCH 6/8] drm/i915/sdvo: Get rid of the output type<->device index stuff

From: Ville Syrjälä Get rid of this silly output type<->device index back and forth and just pass the output type directly to the corresponding output init function. This was already being done for TV outputs anyway. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_sdvo.c |

[Intel-gfx] [PATCH 5/8] drm/i915/sdvo: Don't add DDC modes for LVDS

From: Ville Syrjälä Stop enumerating the DDC modes for SDVO LVDS outputs (outside the initial fixed mode setup). intel_panel_mode_valid() will just reject most of them anyway, and any left over are entirely pointless as they'll match the fixed mode hdisp+vdisp+vrefresh so no user visible effect

[Intel-gfx] [PATCH 4/8] drm/i915/sdvo: Simplify output setup debugs

From: Ville Syrjälä Get rid of this funny byte based dumping of invalid output flags and just dump it as a single hex numbers. Also do that early since all the rest is going to get skipped anyway of the thing is zero. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_sdvo.c

[Intel-gfx] [PATCH 1/8] drm/i915/sdvo: Filter out invalid outputs more sensibly

From: Ville Syrjälä We try to filter out the corresponding xxx1 output if the xxx0 output is not present. But the way that is being done is pretty awkward. Make it less so. Cc: sta...@vger.kernel.org Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_sdvo.c | 29

[Intel-gfx] [PATCH 2/8] drm/i915/sdvo: Setup DDC fully before output init

From: Ville Syrjälä Call intel_sdvo_select_ddc_bus() before initializing any of the outputs. And before that is functional (assuming no VBT) we have to set up the controlled_outputs thing. Otherwise DDC won't be functional during the output init but LVDS really needs it for the fixed mode setup.

[Intel-gfx] [PATCH 0/8] drm/i915/sdvo: Fix LVDS fixed mode setup and clean up output setup

From: Ville Syrjälä Try to fix the LVDS EDID based fixed mode setup a bit. It got broken when I moved it to happen during connector init rather than doing it in a roundabout way from .get_modes(). I also did a bunch of refactoring to the output setup code because the code was a mess. Note that

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/userptr: restore probe_range behaviour (rev2)

== Series Details == Series: drm/i915/userptr: restore probe_range behaviour (rev2) URL : https://patchwork.freedesktop.org/series/110083/ State : success == Summary == CI Bug Log - changes from CI_DRM_12296 -> Patchwork_110083v2 Summary

Re: [Intel-gfx] [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2)

Hi, On 10/26/22 01:40, Matthew Garrett wrote: > On Wed, Oct 26, 2022 at 01:27:25AM +0200, Hans de Goede wrote: > >> this code should actually set the ACPI_VIDEO_BACKLIGHT flag: >> drivers/acpi/scan.c: >> >> static acpi_status >> acpi_backlight_cap_match(acpi_handle handle, u32 level, void

Re: [Intel-gfx] mm/huge_memory: do not clobber swp_entry_t during THP split

On Tue, Oct 25, 2022 at 08:26:06AM -0700, Hugh Dickins wrote: > > > > > If so I > > > can temporarily put it in until it arrives via the next rc - assuming that > > > would be the flow from upstream pov? > > The right thing for now is for GregKH to drop Mel's from 6.0.4: > I've just sent a mail

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915/dg2: Introduce Wa_18018764978

== Series Details == Series: series starting with [1/2] drm/i915/dg2: Introduce Wa_18018764978 URL : https://patchwork.freedesktop.org/series/110131/ State : success == Summary == CI Bug Log - changes from CI_DRM_12294_full -> Patchwork_110131v1_full

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for Revert "drm/i915/uapi: expose GTT alignment"

On 26/10/2022 08:47, Patchwork wrote: *Patch Details* *Series:* Revert "drm/i915/uapi: expose GTT alignment" *URL:* https://patchwork.freedesktop.org/series/110041/ *State:*failure *Details:*

Re: [Intel-gfx] [PATCH v2 00/16] drm/edid: EDID override refactoring and fixes

On Mon, 24 Oct 2022, Jani Nikula wrote: > v2 of drm/edid: EDID override refactoring and fixes > > Address review comments, add patch 15. Thanks for the reviews, pushed the series to drm-misc-next. BR, Jani. > > BR, > Jani. > > > Jani Nikula (16): > drm/i915/hdmi: do dual mode detect only if

Re: [Intel-gfx] [linus:master] [i915] f683b9d613: igt.gem_userptr_blits.probe.fail

Hi Liam, On Mon, Oct 24, 2022 at 03:07:54PM +, Liam Howlett wrote: > * kernel test robot [221024 01:06]: > > > > Greeting, > > > > FYI, we noticed igt.gem_userptr_blits.probe.fail due to commit (built with > > gcc-11): > > > > commit: f683b9d613193362ceb954c216f663a43c027302 ("i915: use

Re: [Intel-gfx] [CI 1/4] drm/i915/display: Change terminology for cdclk actions

On Tue, 25 Oct 2022, Anusha Srivatsa wrote: > No functional changes. Changing terminology in some > print statements. s/has_cdclk_squasher/has_cdclk_squash, > s/crawler/crawl and s/squasher/squash. Any particular reason you re-sent this for CI? You know you can re-run tests from the patchwork

[Intel-gfx] ✗ Fi.CI.IGT: failure for Revert "drm/i915/uapi: expose GTT alignment"

== Series Details == Series: Revert "drm/i915/uapi: expose GTT alignment" URL : https://patchwork.freedesktop.org/series/110041/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12284_full -> Patchwork_110041v1_full Summary

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/xelp: Add Wa_1806527549 (rev2)

Filed a new issue and re-reported. Rest are known issues. https://gitlab.freedesktop.org/drm/intel/-/issues/7320 -Original Message- From: Sousa, Gustavo Sent: Tuesday, October 25, 2022 2:55 PM To: intel-gfx@lists.freedesktop.org Cc: Vudum, Lakshminarayana Subject: Re: ✗ Fi.CI.IGT:

[Intel-gfx] ✓ Fi.CI.BAT: success for Fix Guc-Err-Capture sizing warning

== Series Details == Series: Fix Guc-Err-Capture sizing warning URL : https://patchwork.freedesktop.org/series/110155/ State : success == Summary == CI Bug Log - changes from CI_DRM_12295 -> Patchwork_110155v1 Summary ---

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Fix Guc-Err-Capture sizing warning

== Series Details == Series: Fix Guc-Err-Capture sizing warning URL : https://patchwork.freedesktop.org/series/110155/ State : warning == Summary == Error: dim checkpatch failed 2590baca57ed drm/i915/guc: Fix GuC error capture sizing estimation and reporting -:24: WARNING:BAD_FIXES_TAG:

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/xelp: Add Wa_1806527549 (rev2)

== Series Details == Series: drm/i915/xelp: Add Wa_1806527549 (rev2) URL : https://patchwork.freedesktop.org/series/109885/ State : success == Summary == CI Bug Log - changes from CI_DRM_12261_full -> Patchwork_109885v2_full Summary

[Intel-gfx] [PATCH v4 1/1] drm/i915/guc: Fix GuC error capture sizing estimation and reporting

During GuC error capture initialization, we estimate the amount of size we need for the error-capture-region of the shared GuC-log-buffer. This calculation was incorrect so fix that. With the fixed calculation we can reduce the allocation of error-capture region from 4MB to 1MB (see note2 below

[Intel-gfx] [PATCH v4 0/1] Fix Guc-Err-Capture sizing warning

GuC Error capture initialization calculates an estimation buffer size for worst case scenario of all engines getting reset. Fix the calculation change from drm_warn to drm_dbg since its a corner case Changes from prior revs: v3: - Rebase on latest drm-tip v2: - Reduce the guc-log-buffer

<    1   2