[Intel-gfx] [PATCH v12 6/6] drm/i915/mtl: Add HDCP GSC interface

MTL uses GSC command streamer i.e gsc cs to send HDCP/PXP commands to GSC f/w. It requires to keep hdcp display driver agnostic to content protection f/w (ME/GSC fw) in the form of i915_hdcp_fw_ops generic ops. Adding HDCP GSC CS interface by leveraging the i915_hdcp_fw_ops generic ops instead of

[Intel-gfx] [PATCH v12 5/6] drm/i915/mtl: Add function to send command to GSC CS

Add function that takes care of sending command to gsc cs. We start of with allocation of memory for our command intel_hdcp_gsc_message that contains gsc cs memory header as directed in specs followed by the actual payload hdcp message that we want to send. Spec states that we need to poll pending

[Intel-gfx] [PATCH v12 4/6] drm/i915/hdcp: Refactor HDCP API structures

It requires to move intel specific HDCP API structures to i915_hdcp_interface.h from driver/misc/mei/hdcp/mei_hdcp.h so that any content protection fw interfaces can use these structures. Cc: Tomas Winkler Cc: Rodrigo Vivi Cc: Uma Shankar Cc: Ankit Nautiyal Signed-off-by: Anshuman Gupta

[Intel-gfx] [PATCH v12 3/6] drm/i915/hdcp: HDCP2.x Refactoring to agnostic hdcp

As now we have more then one type of content protection secrity firmware. %s/_mei_/_ --v3 -Changing names to drop cp_fw to make naming more agnostic[Jani] --v4 -remove header reference in intel_display_core.h [Uma] -fix commit message and prefix drm [Uma] Cc: Tomas Winkler Cc: Rodrigo Vivi

[Intel-gfx] [PATCH v12 2/6] drm/i915/hdcp: Use generic names for HDCP helpers and structs

From: Anshuman Gupta pre MTL we interact with mei interface to talk to firmware and enable CP but going forward we will talk to gsc cs because of which we are making all names for HDCP helpers and structures generic as either mei or gsc cs maybe used. Change the

[Intel-gfx] [PATCH v12 1/6] drm/i915/gsc: Create GSC request submission mechanism

HDCP and PXP will require a common function to allow it to submit commands to the gsc cs. Also adding the gsc mtl header that needs to be added on to the existing payloads of HDCP and PXP. --v4 -Seprate gsc load and heci cmd submission into different functions in different files for better

[Intel-gfx] [PATCH v12 0/6] Enable HDCP2.x via GSC CS

These patches enable HDCP2.x on machines MTL and above. >From MTL onwards CSME is spilt into GSC and CSC and now we use GSC CS instead of MEI to talk to firmware to start HDCP authentication --v2 -Fixing some checkpatch changes which I forgot before sending out the series --v3 -Drop cp and fw to

Re: [Intel-gfx] [PATCH v2] drm/i915/gt: prevent forcewake releases during BAR resize

On 08.03.2023 18:29, Das, Nirmoy wrote: On 3/8/2023 2:36 PM, Andrzej Hajda wrote: Tests on DG2 machines show that releasing forcewakes during BAR resize results later in forcewake ack timeouts. Do we have a fdo/issues url for that? Having that as References would be nice. The patch is

Re: [Intel-gfx] [PATCH v10 6/6] drm/i915/mtl: Add HDCP GSC interface

> -Original Message- > From: Shankar, Uma > Sent: Tuesday, March 7, 2023 12:15 PM > To: Kandpal, Suraj ; intel- > g...@lists.freedesktop.org > Cc: Nautiyal, Ankit K ; Winkler, Tomas > ; Vivi, Rodrigo ; Gupta, > Anshuman > Subject: RE: [PATCH v10 6/6] drm/i915/mtl: Add HDCP GSC

Re: [Intel-gfx] [PATCH v2 3/7] drm/ttm: Use the BIT macro for the TTM_TT_FLAGs

Hi, Christian, Thanks for reviewing these. Ack to merge reviewed patches through drm-misc-next? Thanks, Thomas On 3/8/23 09:49, Christian König wrote: Am 07.03.23 um 15:46 schrieb Thomas Hellström: New code is recommended to use the BIT macro instead of the explicit shifts. Change the

[Intel-gfx] ✓ Fi.CI.BAT: success for Enable YCbCr420 format for VDSC (rev3)

== Series Details == Series: Enable YCbCr420 format for VDSC (rev3) URL : https://patchwork.freedesktop.org/series/114246/ State : success == Summary == CI Bug Log - changes from CI_DRM_12829 -> Patchwork_114246v3 Summary ---

[Intel-gfx] [PATCH v3 7/7] drm/i915/dsc: Add debugfs entry to validate DSC output formats

From: Swati Sharma DSC_Output_Format_Sink_Support entry is added to i915_dsc_fec_support_show to depict if sink supports DSC output formats (RGB/YCbCr420/YCbCr444). Also, new debugfs entry is created to enforce output format. This is required because of our driver policy. For ex. if a mode is

[Intel-gfx] [PATCH v3 5/7] drm/i915/dsc: Fill in native_420 field

Now that we have laid the groundwork for YUV420 Enablement we fill up native_420 field in vdsc_cfg and add appropriate checks wherever required. ---v2 -adding native_422 field as 0 [Vandita] -filling in second_line_bpg_offset, second_line_offset_adj and nsl_bpg_offset in vds_cfg when native_420

[Intel-gfx] [PATCH v3 6/7] drm/i915/vdsc: Check slice design requirement

Add function to check if slice design requirements are being met as defined in Bspec: 49259 in the section Slice Design Requirement --v7 -remove full bspec link [Jani] -rename intel_dsc_check_slice_design_req to intel_dsc_slice_dimensions_valid [Jani] --v8 -fix condition to check if slice width

[Intel-gfx] [PATCH v3 4/7] drm/i915/dsc: Enable YCbCr420 for VDSC

Implementation of VDSC for YCbCr420. Add QP tables for 8,10,12 BPC from rc_tables.h in intel_qp_tables.c (Derived from C-Model, which is given along with DSC1.2a Spec from Vesa) intel_lookup_range_min/max_qp functons need to take into account the output format. Based on that appropriate qp table

[Intel-gfx] [PATCH v3 3/7] drm/i915/dsc: Adding the new registers for DSC

Adding new DSC register which are introducted MTL onwards Signed-off-by: Suraj Kandpal Reviewed-by: Vandita Kulkarni Reviewed-by: Uma Shankar --- .../gpu/drm/i915/display/intel_vdsc_regs.h| 28 +++ 1 file changed, 28 insertions(+) diff --git

[Intel-gfx] [PATCH v3 2/7] drm/i915/dp: Check if DSC supports the given output_format

From: Ankit Nautiyal Go with DSC only if the given output_format is supported. v2: Use drm helper to get DSC format support for sink. v3: remove drm_dp_dsc_compute_bpp. Cc: Uma Shankar Signed-off-by: Ankit Nautiyal Reviewed-by: Uma Shankar --- drivers/gpu/drm/i915/display/intel_dp.c | 28

[Intel-gfx] [PATCH v3 1/7] drm/dp_helper: Add helper to check DSC support with given o/p format

From: Ankit Nautiyal Add helper to check if the DP sink supports DSC with the given o/p format. v2: Add documentation for the helper. (Uma Shankar) v3: /** instead of /* (Uma Shankar) Signed-off-by: Ankit Nautiyal Reviewed-by: Uma Shankar --- include/drm/display/drm_dp_helper.h | 13

[Intel-gfx] [PATCH v3 0/7] Enable YCbCr420 format for VDSC

This patch series aims to enable the YCbCr420 format for DSC. Changes are mostly compute params related for hdmi,dp and dsi along with the addition of new rc_tables for native_420 and corresponding changes to macros used to fetch them. There have been discussions prior to this series in which some

Re: [Intel-gfx] [PATCH v2] drm/i915/gvt: Make use of idr_find and idr_for_each_entry in dmabuf

On 2023.03.03 22:07:18 +0800, Cai Huoqing wrote: > This patch uses the already existing IDR mechanism to simplify > and improve the dmabuf code. > > Using 'vgpu.object_idr' directly instead of 'dmabuf_obj_list_head' > or 'dmabuf.list', because the dmabuf_obj can be found by 'idr_find' > or

Re: [Intel-gfx] [PATCH 1/2] Revert "drm/i915/mtl: Add Wa_14017073508 for SAMedia"

On 08-03-2023 20:55, Nilawar, Badal wrote: Hi Jani, On 08-03-2023 16:48, Jani Nikula wrote: On Wed, 08 Mar 2023, Badal Nilawar wrote: This reverts commit 8f70f1ec587da0b0d52d768fd8c3defbc5e5b55c. Reverts need a commit message too. The why. The cover letter is not recorded in git

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/pmu: Use common freq functions with sysfs (rev2)

== Series Details == Series: drm/i915/pmu: Use common freq functions with sysfs (rev2) URL : https://patchwork.freedesktop.org/series/114814/ State : success == Summary == CI Bug Log - changes from CI_DRM_12829 -> Patchwork_114814v2

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/pmu: Use common freq functions with sysfs (rev2)

== Series Details == Series: drm/i915/pmu: Use common freq functions with sysfs (rev2) URL : https://patchwork.freedesktop.org/series/114814/ State : warning == Summary == Error: dim checkpatch failed b9a3eb1e49e1 drm/i915/pmu: Use functions common with sysfs to read actual freq -:15:

Re: [Intel-gfx] [PATCH 3/3] drm/i915/pmu: Use common freq functions with sysfs

On Tue, 07 Mar 2023 22:12:49 -0800, Belgaumkar, Vinay wrote: > Hi Vinay, > On 3/7/2023 9:33 PM, Ashutosh Dixit wrote: > > Using common freq functions with sysfs in PMU (but without taking > > forcewake) solves the following issues (a) missing support for MTL (b) > > For the requested_freq, we

[Intel-gfx] [PATCH 2/2] drm/i915/pmu: Remove fallback to requested freq for SLPC

The fallback to requested freq does not work for SLPC because SLPC does not use 'struct intel_rps'. Also for SLPC requested freq can only be obtained from a hw register after acquiring forcewake which we don't want to do for PMU. Therefore remove fallback to requested freq for SLPC. The actual

[Intel-gfx] [PATCH 0/2] drm/i915/pmu: Use common freq functions with sysfs

Expose intel_rps_read_actual_frequency_fw to read the actual freq without taking forcewake for use by PMU. The code is refactored to use a common set of functions across sysfs and PMU. Using common functions with sysfs in PMU solves the issues of missing support for MTL and missing support for

[Intel-gfx] [PATCH 1/2] drm/i915/pmu: Use functions common with sysfs to read actual freq

Expose intel_rps_read_actual_frequency_fw to read the actual freq without taking forcewake for use by PMU. The code is refactored to use a common set of functions across sysfs and PMU. Using common functions with sysfs in PMU solves the issues of missing support for MTL and missing support for

[Intel-gfx] ✓ Fi.CI.BAT: success for cpumask: fix incorrect cpumask scanning result checks

== Series Details == Series: cpumask: fix incorrect cpumask scanning result checks URL : https://patchwork.freedesktop.org/series/114882/ State : success == Summary == CI Bug Log - changes from CI_DRM_12829 -> Patchwork_114882v1 Summary

[Intel-gfx] [PATCH CI] cpumask: fix incorrect cpumask scanning result checks

From: Linus Torvalds It turns out that commit 596ff4a09b89 ("cpumask: re-introduce constant-sized cpumask optimizations") exposed a number of cases of drivers not checking the result of "cpumask_next()" and friends correctly. The documented correct check for "no more cpus in the cpumask" is to

Re: [Intel-gfx] [PATCH v2] drm/i915/gt: prevent forcewake releases during BAR resize

Hi Andrzej, On Wed, Mar 08, 2023 at 02:36:24PM +0100, Andrzej Hajda wrote: > Tests on DG2 machines show that releasing forcewakes during BAR resize > results later in forcewake ack timeouts. Since forcewakes can be realeased > asynchronously the simplest way to prevent it is to get all forcewakes

Re: [Intel-gfx] [PATCH v5 3/4] drm/i915/selftests: use nop_clear_range instead of local function

Hi Andrzej, On Wed, Mar 08, 2023 at 04:39:05PM +0100, Andrzej Hajda wrote: > Since nop_clear_range is visible it can be used here. > > Signed-off-by: Andrzej Hajda Reviewed-by: Andi Shyti Thanks, Andi

Re: [Intel-gfx] [PATCH v5 2/4] drm/i915/display: use nop_clear_range instead of local function

Hi Andrzej, On Wed, Mar 08, 2023 at 04:39:04PM +0100, Andrzej Hajda wrote: > Since nop_clear_range is visible it can be used here. > > Signed-off-by: Andrzej Hajda Reviewed-by: Andi Shyti Thanks, Andi

Re: [Intel-gfx] [PATCH v5 1/4] drm/i915/gt: make nop_clear_range public

Hi Andrzej, On Wed, Mar 08, 2023 at 04:39:03PM +0100, Andrzej Hajda wrote: > Function nop_clear_range can be used instead of local implementations. > > Signed-off-by: Andrzej Hajda Reviewed-by: Andi Shyti Andi

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: vblank stuff (rev6)

== Series Details == Series: drm/i915: vblank stuff (rev6) URL : https://patchwork.freedesktop.org/series/112170/ State : success == Summary == CI Bug Log - changes from CI_DRM_12829 -> Patchwork_112170v6 Summary --- **SUCCESS**

[Intel-gfx] [PATCH] drm/i915/selftests: keep same cache settings as timeline

From: Fei Yang On MTL, objects allocated through i915_gem_object_create_internal() are mapped as uncached in GPU by default because HAS_LLC is false. However in the live_hwsp_read selftest these watcher objects are mapped as WB on CPU side. The conseqence is that the updates done by the GPU are

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Fix idle pattern enabling

On Thu, Mar 09, 2023 at 12:19:09AM +0200, Imre Deak wrote: > On Wed, Mar 08, 2023 at 11:28:07PM +0200, Ville Syrjälä wrote: > > On Thu, Mar 02, 2023 at 09:03:42PM +0200, Imre Deak wrote: > > > On Tue, Feb 14, 2023 at 03:43:48PM +0200, Ville Syrjala wrote: > > > > From: Ville Syrjälä > > > > > >

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Fix idle pattern enabling

On Wed, Mar 08, 2023 at 11:28:07PM +0200, Ville Syrjälä wrote: > On Thu, Mar 02, 2023 at 09:03:42PM +0200, Imre Deak wrote: > > On Tue, Feb 14, 2023 at 03:43:48PM +0200, Ville Syrjala wrote: > > > From: Ville Syrjälä > > > > > > Currently we are always switching to the idle pattern after the > >

Re: [Intel-gfx] [PATCH v2 3/3] drm/i915: Include timeline seqno in error capture

On Wed, 2023-03-08 at 14:02 -0800, Teres Alexis, Alan Previn wrote: > On Thu, 2023-02-16 at 18:24 -0800, john.c.harri...@intel.com wrote: > > From: John Harrison > > > > The seqno value actually written out to memory is no longer in the > > regular HWSP. Instead, it is now in its own private

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/3] drm/i915/opregion: Fix opregion setup during system resume on platforms without display

== Series Details == Series: series starting with [CI,1/3] drm/i915/opregion: Fix opregion setup during system resume on platforms without display URL : https://patchwork.freedesktop.org/series/114866/ State : success == Summary == CI Bug Log - changes from CI_DRM_12829 -> Patchwork_114866v1

Re: [Intel-gfx] [PATCH 1/2] drm/i915/display: Restore dsparb_lock.

On Wed, Mar 08, 2023 at 11:58:58AM -0500, Rodrigo Vivi wrote: > uncore->lock only protects the forcewake domain itself, > not the register accesses. > > uncore's _fw alternatives are for cases where the domains > are not needed because we are sure that they are already > awake. > > So the move

Re: [Intel-gfx] [PATCH v2 3/3] drm/i915: Include timeline seqno in error capture

On Thu, 2023-02-16 at 18:24 -0800, john.c.harri...@intel.com wrote: > From: John Harrison > > The seqno value actually written out to memory is no longer in the > regular HWSP. Instead, it is now in its own private timeline buffer. > Thus, it is no longer visible in an error capture. So,

Re: [Intel-gfx] [PATCH 2/2] drm/i915/i9xx_wm: Prefer intel_de functions over intel_uncore.

On Wed, Mar 08, 2023 at 08:18:52PM +0200, Ville Syrjälä wrote: > On Wed, Mar 08, 2023 at 12:56:28PM -0500, Rodrigo Vivi wrote: > > On Wed, Mar 08, 2023 at 07:50:27PM +0200, Ville Syrjälä wrote: > > > On Wed, Mar 08, 2023 at 11:58:59AM -0500, Rodrigo Vivi wrote: > > > > } else if

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [CI,1/3] drm/i915/opregion: Fix opregion setup during system resume on platforms without display

== Series Details == Series: series starting with [CI,1/3] drm/i915/opregion: Fix opregion setup during system resume on platforms without display URL : https://patchwork.freedesktop.org/series/114866/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Fix idle pattern enabling

On Thu, Mar 02, 2023 at 09:03:42PM +0200, Imre Deak wrote: > On Tue, Feb 14, 2023 at 03:43:48PM +0200, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > Currently we are always switching to the idle pattern after the > > link training, but we don't always wait for the minimum number > > of

[Intel-gfx] [PATCH v2 1/2] drm/i915: Don't switch to TPS1 when disabling DP_TP_CTL

From: Ville Syrjälä AFAICS Bspec has never asked us to switch to TPS1 when *disabling* DP_TP_CTL. Let's stop doing that in case it confuses something. We do have to switch before we *enable* DP_TP_CTL, but that is already being handled correctly. v2: Do the same for FDI v3: Rebase Reviewed-by:

[Intel-gfx] [PATCH v2 2/2] drm/i915: Don't send idle pattern after DP2.0 link training

From: Ville Syrjälä Bspec calls us to select pattern 2 after link training for DP 2.0. Let's do that... by doing nothing because we will be transmitting pattern 2 at the end of the link training already. Reviewed-by: Imre Deak Signed-off-by: Ville Syrjälä ---

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/debugfs: move IPS debugfs to hsw_ips.c (rev4)

== Series Details == Series: drm/i915/debugfs: move IPS debugfs to hsw_ips.c (rev4) URL : https://patchwork.freedesktop.org/series/114578/ State : success == Summary == CI Bug Log - changes from CI_DRM_12829 -> Patchwork_114578v4 Summary

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: add guard page to ggtt->error_capture (rev7)

== Series Details == Series: drm/i915: add guard page to ggtt->error_capture (rev7) URL : https://patchwork.freedesktop.org/series/113560/ State : success == Summary == CI Bug Log - changes from CI_DRM_12829 -> Patchwork_113560v7 Summary

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [RFC,1/2] drm/i915: Add a function to mmap framebuffer obj

== Series Details == Series: series starting with [RFC,1/2] drm/i915: Add a function to mmap framebuffer obj URL : https://patchwork.freedesktop.org/series/114775/ State : success == Summary == CI Bug Log - changes from CI_DRM_12821_full -> Patchwork_114775v1_full

[Intel-gfx] ✓ Fi.CI.BAT: success for MAINTAINERS: update the 01.org website entries

== Series Details == Series: MAINTAINERS: update the 01.org website entries URL : https://patchwork.freedesktop.org/series/114854/ State : success == Summary == CI Bug Log - changes from CI_DRM_12829 -> Patchwork_114854v1 Summary ---

Re: [Intel-gfx] [PATCH 2/2] drm/i915/i9xx_wm: Prefer intel_de functions over intel_uncore.

On Wed, Mar 08, 2023 at 12:56:28PM -0500, Rodrigo Vivi wrote: > On Wed, Mar 08, 2023 at 07:50:27PM +0200, Ville Syrjälä wrote: > > On Wed, Mar 08, 2023 at 11:58:59AM -0500, Rodrigo Vivi wrote: > > > } else if (IS_I915GM(dev_priv)) { > > > /* > > >* FIXME can't find a bit

Re: [Intel-gfx] [PATCH v4 8/9] drm/i915/perf: Add engine class instance parameters to perf

On Tue, 07 Mar 2023 12:16:10 -0800, Umesh Nerlige Ramappa wrote: > Hi Umesh, > One or more engines map to a specific OA unit. All reports from these > engines are captured in the OA buffer managed by this OA unit. > > Current i915 OA implementation supports only the OAG unit. OAG primarily >

Re: [Intel-gfx] [PATCH 2/2] drm/i915/i9xx_wm: Prefer intel_de functions over intel_uncore.

On Wed, Mar 08, 2023 at 07:50:27PM +0200, Ville Syrjälä wrote: > On Wed, Mar 08, 2023 at 11:58:59AM -0500, Rodrigo Vivi wrote: > > } else if (IS_I915GM(dev_priv)) { > > /* > > * FIXME can't find a bit like this for 915G, and > > * yet it does have the

Re: [Intel-gfx] [PATCH 2/2] drm/i915/i9xx_wm: Prefer intel_de functions over intel_uncore.

On Wed, Mar 08, 2023 at 11:58:59AM -0500, Rodrigo Vivi wrote: > } else if (IS_I915GM(dev_priv)) { > /* >* FIXME can't find a bit like this for 915G, and >* yet it does have the related watermark in >* FW_BLC_SELF. What's going on?

Re: [Intel-gfx] [PATCH v2] drm/i915/gt: prevent forcewake releases during BAR resize

On Wed, Mar 08, 2023 at 02:36:24PM +0100, Andrzej Hajda wrote: > Tests on DG2 machines show that releasing forcewakes during BAR resize > results later in forcewake ack timeouts. Since forcewakes can be realeased > asynchronously the simplest way to prevent it is to get all forcewakes > for

Re: [Intel-gfx] [PATCH v2] drm/i915/gt: prevent forcewake releases during BAR resize

On 3/8/2023 2:36 PM, Andrzej Hajda wrote: Tests on DG2 machines show that releasing forcewakes during BAR resize results later in forcewake ack timeouts. Do we have a fdo/issues url for that? Having that as References would be nice. Since forcewakes can be realeased asynchronously the

[Intel-gfx] [PATCH 1/2] drm/i915/display: Restore dsparb_lock.

uncore->lock only protects the forcewake domain itself, not the register accesses. uncore's _fw alternatives are for cases where the domains are not needed because we are sure that they are already awake. So the move towards the uncore's _fw alternatives seems right, however using the

[Intel-gfx] [PATCH 2/2] drm/i915/i9xx_wm: Prefer intel_de functions over intel_uncore.

Let's get rid of the intel_uncore calls on display side. Cc: Jani Nikula Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/display/i9xx_wm.c | 238 drivers/gpu/drm/i915/display/intel_de.h | 12 ++ 2 files changed, 131 insertions(+), 119 deletions(-) diff --git

Re: [Intel-gfx] [PATCH v2 06/10] drm/display/dsc: split DSC 1.2 and DSC 1.1 (pre-SCR) parameters

On Wed, 8 Mar 2023 at 15:19, Jani Nikula wrote: > > On Wed, 08 Mar 2023, Dmitry Baryshkov wrote: > > On Wed, 8 Mar 2023 at 12:14, Jani Nikula > > wrote: > >> > >> On Tue, 07 Mar 2023, Dmitry Baryshkov wrote: > >> > The array of rc_parameters contains a mixture of parameters from DSC 1.1 > >>

[Intel-gfx] [CI 3/3] drm/i915/opregion: Register display debugfs later, after initialization steps

Move the display debugfs registration later, after initializing steps for opregion/acpi/audio. These latter ones don't depend on the debugfs entries, OTOH some debugfs entries may depend on the initialized state. Reviewed-by: Jani Nikula Signed-off-by: Imre Deak ---

[Intel-gfx] [CI 2/3] drm/i915/opregion: Cleanup opregion after errors during driver loading

Clean up the opregion state if something fails after intel_opregion_setup() is called. Reviewed-by: Jani Nikula Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/display/intel_opregion.c | 8 drivers/gpu/drm/i915/display/intel_opregion.h | 1 + drivers/gpu/drm/i915/i915_driver.c

[Intel-gfx] [CI 1/3] drm/i915/opregion: Fix opregion setup during system resume on platforms without display

Atm, during system resume, the driver updates the display connector information required by the opregion video extensions during system resume, on platforms both with and without display being present. On !HAS_DISPLAY platforms this will result in the crash with the stack trace below, since the

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gt: prevent forcewake releases during BAR resize (rev3)

On 08.03.2023 16:44, Patchwork wrote: *Patch Details* *Series:* drm/i915/gt: prevent forcewake releases during BAR resize (rev3) *URL:* https://patchwork.freedesktop.org/series/114836/ *State:*failure *Details:*

Re: [Intel-gfx] [PATCH v5 00/19] Add vfio_device cdev for iommufd support

> -Original Message- > From: Nicolin Chen [mailto:nicol...@nvidia.com] > Sent: 04 March 2023 07:01 > To: Shameerali Kolothum Thodi > Cc: Xu, Terrence ; Liu, Yi L ; > Jason Gunthorpe ; alex.william...@redhat.com; Tian, > Kevin ; j...@8bytes.org; robin.mur...@arm.com; >

[Intel-gfx] [PATCH v10 15/15] drm/i915: Add deadline based boost support

From: Rob Clark I expect this patch to be replaced by someone who knows i915 better. Signed-off-by: Rob Clark --- drivers/gpu/drm/i915/i915_request.c | 20 1 file changed, 20 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_request.c

[Intel-gfx] [PATCH v10 13/15] drm/msm: Add wait-boost support

From: Rob Clark Add a way for various userspace waits to signal urgency. Signed-off-by: Rob Clark --- drivers/gpu/drm/msm/msm_drv.c | 12 drivers/gpu/drm/msm/msm_gem.c | 5 + include/uapi/drm/msm_drm.h| 14 -- 3 files changed, 25 insertions(+), 6 deletions(-)

[Intel-gfx] [PATCH v10 14/15] drm/msm/atomic: Switch to vblank_start helper

From: Rob Clark Drop our custom thing and switch to drm_crtc_next_vblank_start() for calculating the time of the start of the next vblank period. Signed-off-by: Rob Clark --- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 15 --- drivers/gpu/drm/msm/msm_atomic.c| 8 +---

[Intel-gfx] [PATCH v10 12/15] drm/msm: Add deadline based boost support

From: Rob Clark Track the nearest deadline on a fence timeline and set a timer to expire shortly before to trigger boost if the fence has not yet been signaled. v2: rebase Signed-off-by: Rob Clark --- drivers/gpu/drm/msm/msm_fence.c | 74 +

[Intel-gfx] [PATCH v10 09/15] drm/syncobj: Add deadline support for syncobj waits

From: Rob Clark Add a new flag to let userspace provide a deadline as a hint for syncobj and timeline waits. This gives a hint to the driver signaling the backing fences about how soon userspace needs it to compete work, so it can addjust GPU frequency accordingly. An immediate deadline can be

[Intel-gfx] [PATCH v10 10/15] drm/vblank: Add helper to get next vblank time

From: Rob Clark Will be used in the next commit to set a deadline on fences that an atomic update is waiting on. v2: Calculate time at *start* of vblank period, not end v3: Fix kbuild complaints Signed-off-by: Rob Clark Reviewed-by: Mario Kleiner --- drivers/gpu/drm/drm_vblank.c | 53

[Intel-gfx] [PATCH v10 11/15] drm/atomic-helper: Set fence deadline for vblank

From: Rob Clark For an atomic commit updating a single CRTC (ie. a pageflip) calculate the next vblank time, and inform the fence(s) of that deadline. v2: Comment typo fix (danvet) v3: If there are multiple CRTCs, consider the time of the soonest vblank Signed-off-by: Rob Clark Reviewed-by:

[Intel-gfx] [PATCH v10 06/15] dma-buf/sync_file: Add SET_DEADLINE ioctl

From: Rob Clark The initial purpose is for igt tests, but this would also be useful for compositors that wait until close to vblank deadline to make decisions about which frame to show. The igt tests can be found at:

[Intel-gfx] [PATCH v10 07/15] dma-buf/sw_sync: Add fence deadline support

From: Rob Clark This consists of simply storing the most recent deadline, and adding an ioctl to retrieve the deadline. This can be used in conjunction with the SET_DEADLINE ioctl on a fence fd for testing. Ie. create various sw_sync fences, merge them into a fence-array, set deadline on the

[Intel-gfx] [PATCH v10 08/15] drm/scheduler: Add fence deadline support

As the finished fence is the one that is exposed to userspace, and therefore the one that other operations, like atomic update, would block on, we need to propagate the deadline from from the finished fence to the actual hw fence. v2: Split into drm_sched_fence_set_parent() (ckoenig) v3: Ensure a

[Intel-gfx] [PATCH v10 03/15] dma-buf/fence-chain: Add fence deadline support

From: Rob Clark Propagate the deadline to all the fences in the chain. v2: Use dma_fence_chain_contained [Tvrtko] Signed-off-by: Rob Clark Reviewed-by: Christian König for this one. --- drivers/dma-buf/dma-fence-chain.c | 12 1 file changed, 12 insertions(+) diff --git

[Intel-gfx] [PATCH v10 05/15] dma-buf/sync_file: Surface sync-file uABI

From: Rob Clark We had all of the internal driver APIs, but not the all important userspace uABI, in the dma-buf doc. Fix that. And re-arrange the comments slightly as otherwise the comments for the ioctl nr defines would not show up. v2: Fix docs build warning coming from newly including the

[Intel-gfx] [PATCH v10 04/15] dma-buf/dma-resv: Add a way to set fence deadline

From: Rob Clark Add a way to set a deadline on remaining resv fences according to the requested usage. Signed-off-by: Rob Clark Reviewed-by: Christian König --- drivers/dma-buf/dma-resv.c | 22 ++ include/linux/dma-resv.h | 2 ++ 2 files changed, 24 insertions(+) diff

[Intel-gfx] [PATCH v10 02/15] dma-buf/fence-array: Add fence deadline support

From: Rob Clark Propagate the deadline to all the fences in the array. Signed-off-by: Rob Clark Reviewed-by: Christian König --- drivers/dma-buf/dma-fence-array.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/drivers/dma-buf/dma-fence-array.c

[Intel-gfx] [PATCH v10 01/15] dma-buf/dma-fence: Add deadline awareness

From: Rob Clark Add a way to hint to the fence signaler of an upcoming deadline, such as vblank, which the fence waiter would prefer not to miss. This is to aid the fence signaler in making power management decisions, like boosting frequency as the deadline approaches and awareness of missing

[Intel-gfx] [PATCH v10 00/15] dma-fence: Deadline awareness

From: Rob Clark This series adds a deadline hint to fences, so realtime deadlines such as vblank can be communicated to the fence signaller for power/ frequency management decisions. This is partially inspired by a trick i915 does, but implemented via dma-fence for a couple of reasons: 1) To

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gt: prevent forcewake releases during BAR resize (rev3)

== Series Details == Series: drm/i915/gt: prevent forcewake releases during BAR resize (rev3) URL : https://patchwork.freedesktop.org/series/114836/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12827 -> Patchwork_114836v3

[Intel-gfx] [PATCH v5 4/4] drm/i915: add guard page to ggtt->error_capture

Write-combining memory allows speculative reads by CPU. ggtt->error_capture is WC mapped to CPU, so CPU/MMU can try to prefetch memory beyond the error_capture, ie it tries to read memory pointed by next PTE in GGTT. If this PTE points to invalid address DMAR errors will occur. This behaviour was

[Intel-gfx] [PATCH v5 2/4] drm/i915/display: use nop_clear_range instead of local function

Since nop_clear_range is visible it can be used here. Signed-off-by: Andrzej Hajda --- drivers/gpu/drm/i915/display/intel_dpt.c | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c b/drivers/gpu/drm/i915/display/intel_dpt.c index

[Intel-gfx] [PATCH v5 3/4] drm/i915/selftests: use nop_clear_range instead of local function

Since nop_clear_range is visible it can be used here. Signed-off-by: Andrzej Hajda --- drivers/gpu/drm/i915/selftests/mock_gtt.c | 9 ++--- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/i915/selftests/mock_gtt.c b/drivers/gpu/drm/i915/selftests/mock_gtt.c

[Intel-gfx] [PATCH v5 1/4] drm/i915/gt: make nop_clear_range public

Function nop_clear_range can be used instead of local implementations. Signed-off-by: Andrzej Hajda --- drivers/gpu/drm/i915/gt/intel_ggtt.c | 3 +-- drivers/gpu/drm/i915/gt/intel_gtt.h | 2 ++ 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c

[Intel-gfx] [PATCH v5 0/4] drm/i915: add guard page to ggtt->error_capture

u/drm/i915/gt/intel_ggtt.c | 38 ++- drivers/gpu/drm/i915/gt/intel_gtt.h | 2 ++ drivers/gpu/drm/i915/selftests/mock_gtt.c | 9 ++-- 4 files changed, 37 insertions(+), 19 deletions(-) --- base-commit: 3cd6c251f39c14df9ab711e3eb56e703b359ff54 change

Re: [Intel-gfx] [PATCH v10 03/13] drm/i915/dp: Add Scaler constraint for YCbCr420 output

On Wed, Mar 08, 2023 at 05:10:57PM +0200, Ville Syrjälä wrote: > On Mon, Feb 27, 2023 at 09:33:14AM +0530, Ankit Nautiyal wrote: > > For YCbCr420 output, scaler is required for downsampling. > > Scaler can be used only when source size smaller than max_src_w and > > max_src_h as defined by for the

Re: [Intel-gfx] [PATCH 1/2] Revert "drm/i915/mtl: Add Wa_14017073508 for SAMedia"

Hi Jani, On 08-03-2023 16:48, Jani Nikula wrote: On Wed, 08 Mar 2023, Badal Nilawar wrote: This reverts commit 8f70f1ec587da0b0d52d768fd8c3defbc5e5b55c. Reverts need a commit message too. The why. The cover letter is not recorded in git history. I will add commit message. Regards, Badal

Re: [Intel-gfx] [PATCH 2/2] drm/i915/mtl: Disable MC6 for MTL A step

Hi Rodrigo, On 08-03-2023 18:59, Rodrigo Vivi wrote: On Wed, Mar 08, 2023 at 03:51:09PM +0530, Badal Nilawar wrote: The Wa_14017073508 require to send Media Busy/Idle mailbox while accessing Media tile. As of now it is getting handled while __gt_unpark, __gt_park. But there are various

Re: [Intel-gfx] [PATCH v10 03/13] drm/i915/dp: Add Scaler constraint for YCbCr420 output

On Mon, Feb 27, 2023 at 09:33:14AM +0530, Ankit Nautiyal wrote: > For YCbCr420 output, scaler is required for downsampling. > Scaler can be used only when source size smaller than max_src_w and > max_src_h as defined by for the platform. > So go for native YCbCr420 only if there are no scaler

Re: [Intel-gfx] [PATCH v5 09/19] vfio/pci: Allow passing zero-length fd array in VFIO_DEVICE_PCI_HOT_RESET

On Wed, Mar 08, 2023 at 07:26:08AM +, Tian, Kevin wrote: > * Userspace requests hot reset for the devices it uses. Due to the > * underlying topology, multiple devices can be affected in the reset > * while some might be opened by another user. To avoid interference > * the calling user

[Intel-gfx] ✗ Fi.CI.BAT: failure for vfio: Make emulated devices prepared for vfio device cdev

== Series Details == Series: vfio: Make emulated devices prepared for vfio device cdev URL : https://patchwork.freedesktop.org/series/114846/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12827 -> Patchwork_114846v1

Re: [Intel-gfx] [Intel-xe] [PATCH] drm/xe/display: Do not use i915 frontbuffer tracking implementation

On Wed, Mar 08, 2023 at 03:29:45PM +0100, Maarten Lankhorst wrote: > Hey, > > > On 2023-03-08 14:36, Ville Syrjälä wrote: > > On Wed, Mar 08, 2023 at 01:47:12PM +0100, Maarten Lankhorst wrote: > >> On 2023-03-06 21:58, Ville Syrjälä wrote: > >>> On Mon, Mar 06, 2023 at 09:23:50PM +0100, Maarten

Re: [Intel-gfx] [Intel-xe] [PATCH] drm/xe/display: Do not use i915 frontbuffer tracking implementation

Hey, On 2023-03-08 14:36, Ville Syrjälä wrote: On Wed, Mar 08, 2023 at 01:47:12PM +0100, Maarten Lankhorst wrote: On 2023-03-06 21:58, Ville Syrjälä wrote: On Mon, Mar 06, 2023 at 09:23:50PM +0100, Maarten Lankhorst wrote: Hey, On 2023-03-06 16:23, Souza, Jose wrote: On Mon, 2023-03-06 at

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for vfio: Make emulated devices prepared for vfio device cdev

== Series Details == Series: vfio: Make emulated devices prepared for vfio device cdev URL : https://patchwork.freedesktop.org/series/114846/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. -

[Intel-gfx] [PATCH] MAINTAINERS: update the 01.org website entries

The 01.org links in MAINTAINERS now forward to different other pages or do not resolve. The link https://01.org/linuxgraphics/ resolves to the Intel Graphics for Linux - Programmer's Reference Manuals. Update this webpage entry. The link

[Intel-gfx] [PATCH v2] drm/i915/gt: prevent forcewake releases during BAR resize

Tests on DG2 machines show that releasing forcewakes during BAR resize results later in forcewake ack timeouts. Since forcewakes can be realeased asynchronously the simplest way to prevent it is to get all forcewakes for duration of BAR resizing. v2: hold rpm as well during resizing (Rodrigo)

Re: [Intel-gfx] [Intel-xe] [PATCH] drm/xe/display: Do not use i915 frontbuffer tracking implementation

On Wed, Mar 08, 2023 at 01:47:12PM +0100, Maarten Lankhorst wrote: > > On 2023-03-06 21:58, Ville Syrjälä wrote: > > On Mon, Mar 06, 2023 at 09:23:50PM +0100, Maarten Lankhorst wrote: > >> Hey, > >> > >> On 2023-03-06 16:23, Souza, Jose wrote: > >>> On Mon, 2023-03-06 at 15:16 +0100, Maarten

[Intel-gfx] [PATCH] drm/i915/gt: prevent forcewake releases during BAR resize

Tests on DG2 machines show that releasing forcewakes during BAR resize results later in forcewake ack timeouts. Since forcewakes can be realeased asynchronously the simplest way to prevent it is to get all forcewakes for duration of BAR resizing. Signed-off-by: Andrzej Hajda ---

[Intel-gfx] [PATCH v6 24/24] docs: vfio: Add vfio device cdev description

This gives notes for userspace applications on device cdev usage. Signed-off-by: Yi Liu --- Documentation/driver-api/vfio.rst | 125 ++ 1 file changed, 125 insertions(+) diff --git a/Documentation/driver-api/vfio.rst b/Documentation/driver-api/vfio.rst index

  1   2   >