[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v1,1/1] drm/dp_mst: Use kHz as link rate units when settig source max link caps at init

== Series Details == Series: series starting with [v1,1/1] drm/dp_mst: Use kHz as link rate units when settig source max link caps at init URL : https://patchwork.freedesktop.org/series/89753/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10040_full -> Patchwork_20057_full

[Intel-gfx] ✗ Fi.CI.BAT: failure for Add support for querying engine cycles

== Series Details == Series: Add support for querying engine cycles URL : https://patchwork.freedesktop.org/series/89766/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10040 -> Patchwork_20059 Summary ---

[Intel-gfx] ✗ Fi.CI.DOCS: warning for Add support for querying engine cycles

== Series Details == Series: Add support for querying engine cycles URL : https://patchwork.freedesktop.org/series/89766/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 ./include/uapi/drm/i915_drm.h:2234: warning: Incorrect use of kernel-doc format: *

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gem: Use user_write_access_begin() instead of user_access_begin() (rev2)

== Series Details == Series: drm/i915/gem: Use user_write_access_begin() instead of user_access_begin() (rev2) URL : https://patchwork.freedesktop.org/series/87834/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10039_full -> Patchwork_20054_full

[Intel-gfx] [PATCH 0/1] Add support for querying engine cycles

This is just a refresh of the earlier patch along with cover letter for the IGT testing. The query provides the engine cs cycles counter. v2: Use GRAPHICS_VER() instead of IG_GEN() v3: Add R-b to the patch v4: Split cpu timestamp array into timestamp and delta for cleaner API v5: Add width of the

[Intel-gfx] [PATCH 1/1] i915/query: Correlate engine and cpu timestamps with better accuracy

Perf measurements rely on CPU and engine timestamps to correlate events of interest across these time domains. Current mechanisms get these timestamps separately and the calculated delta between these timestamps lack enough accuracy. To improve the accuracy of these time measurements to within a

Re: [Intel-gfx] [PATCH 3/4] Restructure output format computation for better expandability

Hi Werner, Thank you for the patch! Yet something to improve: [auto build test ERROR on drm-intel/for-linux-next] [also build test ERROR on next-20210503] [cannot apply to v5.12] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/tgl+: Add the missing MC CCS/XYUV8888 format support

== Series Details == Series: drm/i915/tgl+: Add the missing MC CCS/XYUV format support URL : https://patchwork.freedesktop.org/series/89721/ State : success == Summary == CI Bug Log - changes from CI_DRM_10038_full -> Patchwork_20052_full

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v1,1/1] drm/dp_mst: Use kHz as link rate units when settig source max link caps at init

== Series Details == Series: series starting with [v1,1/1] drm/dp_mst: Use kHz as link rate units when settig source max link caps at init URL : https://patchwork.freedesktop.org/series/89753/ State : success == Summary == CI Bug Log - changes from CI_DRM_10040 -> Patchwork_20057

[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/display Try YCbCr420 color when RGB fails

== Series Details == Series: drm/i915/display Try YCbCr420 color when RGB fails URL : https://patchwork.freedesktop.org/series/89760/ State : failure == Summary == Applying: New function to avoid duplicate code in upcomming commits error: unrecognized input error: could not build fake

Re: [Intel-gfx] [PATCH 2/3] drm/i915/csr: Add intel_csr_has_dmc_payload() helper

> -Original Message- > From: Jani Nikula > Sent: Monday, May 3, 2021 11:07 AM > To: Srivatsa, Anusha ; intel- > g...@lists.freedesktop.org > Cc: De Marchi, Lucas > Subject: Re: [Intel-gfx] [PATCH 2/3] drm/i915/csr: Add > intel_csr_has_dmc_payload() helper > > On Wed, 28 Apr 2021,

Re: [Intel-gfx] [PATCH 1/3] drm/i915/csr: s/DRM_ERROR/drm_err

> -Original Message- > From: Jani Nikula > Sent: Monday, May 3, 2021 11:04 AM > To: Srivatsa, Anusha ; intel- > g...@lists.freedesktop.org > Cc: De Marchi, Lucas > Subject: Re: [Intel-gfx] [PATCH 1/3] drm/i915/csr: s/DRM_ERROR/drm_err > > On Wed, 28 Apr 2021, Anusha Srivatsa wrote:

[Intel-gfx] PR for ADLP DMC Firmware

The following changes since commit 3f23f5125b1fef5ed2103c0236a5657966e30e4d: amdgpu: add new polaris 12 MC firmware (2021-05-03 09:26:38 -0400) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-firmware adlp_dmc_firmware for you to fetch changes up to

[Intel-gfx] ✓ Fi.CI.IGT: success for Simplify intel_setup_outputs (rev5)

== Series Details == Series: Simplify intel_setup_outputs (rev5) URL : https://patchwork.freedesktop.org/series/88988/ State : success == Summary == CI Bug Log - changes from CI_DRM_10038_full -> Patchwork_20051_full Summary ---

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v1,1/1] drm/dp_mst: Use kHz as link rate units when settig source max link caps at init

== Series Details == Series: series starting with [v1,1/1] drm/dp_mst: Use kHz as link rate units when settig source max link caps at init URL : https://patchwork.freedesktop.org/series/89753/ State : warning == Summary == $ dim checkpatch origin/drm-tip 3ecf57dc853a drm/dp_mst: Use kHz as

Re: [Intel-gfx] [PATCH 3/4] Restructure output format computation for better expandability

Hi Werner, Thank you for the patch! Yet something to improve: [auto build test ERROR on drm-intel/for-linux-next] [also build test ERROR on next-20210503] [cannot apply to v5.12] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use

[Intel-gfx] ✗ Fi.CI.DOCS: warning for drm/i915/gem: ioctl clean-ups (rev4)

== Series Details == Series: drm/i915/gem: ioctl clean-ups (rev4) URL : https://patchwork.freedesktop.org/series/89443/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 ./drivers/gpu/drm/i915/gem/i915_gem_context_types.h:201: warning: Function parameter or member

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/gem: ioctl clean-ups (rev4)

== Series Details == Series: drm/i915/gem: ioctl clean-ups (rev4) URL : https://patchwork.freedesktop.org/series/89443/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. -

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gem: ioctl clean-ups (rev4)

== Series Details == Series: drm/i915/gem: ioctl clean-ups (rev4) URL : https://patchwork.freedesktop.org/series/89443/ State : warning == Summary == $ dim checkpatch origin/drm-tip 8d290e6238e7 drm/i915: Drop I915_CONTEXT_PARAM_RINGSIZE -:177: WARNING:FILE_PATH_CHANGES: added, moved or

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gem: Use user_write_access_begin() instead of user_access_begin() (rev2)

== Series Details == Series: drm/i915/gem: Use user_write_access_begin() instead of user_access_begin() (rev2) URL : https://patchwork.freedesktop.org/series/87834/ State : success == Summary == CI Bug Log - changes from CI_DRM_10039 -> Patchwork_20054

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

== Series Details == Series: drm + usb-type-c: Add support for out-of-band hotplug notification (rev2) URL : https://patchwork.freedesktop.org/series/89604/ State : failure == Summary == Applying: drm/connector: Give connector sysfs devices there own device_type Applying: drm/connector: Add

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v2,1/2] drm/i915: Don't include intel_de.h from intel_display_types.h (rev2)

== Series Details == Series: series starting with [v2,1/2] drm/i915: Don't include intel_de.h from intel_display_types.h (rev2) URL : https://patchwork.freedesktop.org/series/89698/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10039 -> Patchwork_20053

Re: [Intel-gfx] [PATCH 22/27] drm/i915/gem: Delay context creation

Hi Jason, Thank you for the patch! Yet something to improve: [auto build test ERROR on drm-intel/for-linux-next] [also build test ERROR on drm-tip/drm-tip drm-exynos/exynos-drm-next next-20210503] [cannot apply to tegra-drm/drm/tegra/for-next v5.12] [If your patch is applied to the wrong git

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Use correct downstream caps for check Src-Ctl mode for PCON

== Series Details == Series: drm/i915: Use correct downstream caps for check Src-Ctl mode for PCON URL : https://patchwork.freedesktop.org/series/89639/ State : success == Summary == CI Bug Log - changes from CI_DRM_10027_full -> Patchwork_20030_full

Re: [Intel-gfx] [PATCH 23/27] drm/i915/gem: Don't allow changing the VM on running contexts

Hi Jason, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on drm-intel/for-linux-next] [also build test WARNING on drm-tip/drm-tip drm-exynos/exynos-drm-next next-20210503] [cannot apply to tegra-drm/drm/tegra/for-next drm/drm-next v5.12] [If your patch

Re: [Intel-gfx] [PATCH 1/1] i915/query: Correlate engine and cpu timestamps with better accuracy

On Sat, May 01, 2021 at 10:27:03AM -0500, Jason Ekstrand wrote: On April 30, 2021 23:01:44 "Dixit, Ashutosh" wrote: On Fri, 30 Apr 2021 19:19:59 -0700, Umesh Nerlige Ramappa wrote: On Fri, Apr 30, 2021 at 07:35:41PM -0500, Jason Ekstrand wrote: On April 30, 2021

[Intel-gfx] [PATCH 3/4] Restructure output format computation for better expandability

Couples the decission between RGB and YCbCr420 mode and the check if the port clock can archive the required frequency. Other checks and configuration steps that where previously done in between can also be done before or after. This allows for are cleaner implementation of retrying different

[Intel-gfx] [PATCH 1/4] New function to avoid duplicate code in upcomming commits

Moves some checks that later will be performed 2 times to an own fuction. This avoids duplicate code later on. Signed-off-by: Werner Sembach --- >From 1c529783eb2ec02099d1ed2ab9257b008cb6f040 Mon Sep 17 00:00:00 2001 From: Werner Sembach Date: Mon, 3 May 2021 14:35:39 +0200 Subject: [PATCH

[Intel-gfx] [PATCH 2/4] Add missing check

Add a missing check that could potentially lead to an unarchivable mode being validated. Signed-off-by: Werner Sembach --- >From 54fa706f0a5f260a32af5d18b9622ceebb94c12e Mon Sep 17 00:00:00 2001 From: Werner Sembach Date: Mon, 3 May 2021 14:42:36 +0200 Subject: [PATCH 2/4] Add missing check

[Intel-gfx] [PATCH 4/4] Use YCbCr420 as fallback when RGB fails

When encoder validation of a display mode fails, retry with less bandwidth heavy YCbCr420 color mode, if available. This enables some HDMI 1.4 setups to support 4k60Hz output, which previously failed silently. AMDGPU had nearly the exact same issue. This problem description is therefore copied

[Intel-gfx] [PATCH 0/4] drm/i915/display Try YCbCr420 color when RGB fails

When encoder validation of a display mode fails, retry with less bandwidth heavy YCbCr420 color mode, if available. This enables some HDMI 1.4 setups to support 4k60Hz output, which previously failed silently. AMDGPU had nearly the exact same issue. This problem description is therefore copied

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/tgl+: Add the missing MC CCS/XYUV8888 format support

== Series Details == Series: drm/i915/tgl+: Add the missing MC CCS/XYUV format support URL : https://patchwork.freedesktop.org/series/89721/ State : success == Summary == CI Bug Log - changes from CI_DRM_10038 -> Patchwork_20052

Re: [Intel-gfx] [PATCH 0/3] Pipe DMC Prep patches

On Wed, 28 Apr 2021, Anusha Srivatsa wrote: > This series adds the prep work needed before the > actual Pipe DMC implementation. When should we rename csr to dmc all over the place? BR, Jani. > > Anusha Srivatsa (3): > drm/i915/csr: s/DRM_ERROR/drm_err > drm/i915/csr: Add

[Intel-gfx] [PATCH 0/4] drm/i915/display Try YCbCr420 color when RGB fails

When encoder validation of a display mode fails, retry with less bandwidth heavy YCbCr420 color mode, if available. This enables some HDMI 1.4 setups to support 4k60Hz output, which previously failed silently. AMDGPU had nearly the exact same issue. This problem description is therefore copied

Re: [Intel-gfx] [PATCH 2/3] drm/i915/csr: Add intel_csr_has_dmc_payload() helper

On Wed, 28 Apr 2021, Anusha Srivatsa wrote: > We check for dmc_payload being there at various points in the driver. > Replace it with the helper. Yes please! > > While at it moving bits related to CSR to intel_csr.h > > Cc: Lucas De Marchi > Signed-off-by: Anusha Srivatsa > --- >

Re: [Intel-gfx] [PATCH 1/3] drm/i915/csr: s/DRM_ERROR/drm_err

On Wed, 28 Apr 2021, Anusha Srivatsa wrote: > Use new format of debug messages across intel_csr. > > While at it, change some function definitions which now > need dev_priv for drm_err and drm_info etc. > > Cc: Lucas De Marchi > Suggested-by: Lucas De Marchi > Signed-off-by: Anusha Srivatsa >

Re: [Intel-gfx] [PATCH v2 1/2] drm/i915: Don't include intel_de.h from intel_display_types.h

On Fri, 30 Apr 2021, Ville Syrjala wrote: > From: Ville Syrjälä > > Hoist the intel_de.h include from intel_display_types.h one > level up. I need this in order to untangle the include order > so that I can add tracepoints into intel_de.h. Wonder why this isn't getting test results. > > This

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

On Fri, 30 Apr 2021, Ville Syrjala wrote: > From: Ville Syrjälä > > A few easy cleanups to the cdclk code. On the series, Reviewed-by: Jani Nikula > > Ville Syrjälä (5): > drm/i915: Extract some helpers to compute cdclk register values > drm/i915: Use intel_de_rmw() in bdw cdclk

Re: [Intel-gfx] [PATCH 2/5] drm/i915: Use intel_de_rmw() in bdw cdclk programming

On Fri, 30 Apr 2021, Ville Syrjala wrote: > From: Ville Syrjälä > > Replace the hand rolled rmw sequences with intel_de_rmw(). > > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/display/intel_cdclk.c | 17 ++--- > 1 file changed, 6 insertions(+), 11 deletions(-) > > diff

Re: [Intel-gfx] [PATCH] drm/i915: Fix wrong name announced on FB driver switching

On Thu, 29 Apr 2021, Janusz Krzysztofik wrote: > Commit 7a0f9ef9703d ("drm/i915: Use drm_fb_helper_fill_info") > effectively changed our FB driver name from "inteldrmfb" to > "i915drmfb". However, we are still using the old name when kicking out > a firmware fbdev driver potentially bound to

Re: [Intel-gfx] [PATCH] drm/i915: Use correct downstream caps for check Src-Ctl mode for PCON

On Thu, 29 Apr 2021, Ankit Nautiyal wrote: > Fix the typo in DPCD caps used for checking SRC CTL mode of > HDMI2.1 PCON > > Fixes: 04b6603d13be (drm/i915/display: Configure HDMI2.1 Pcon for FRL > only if Src-Ctl mode is available) Correct format for Fixes: is this: Fixes: 04b6603d13be

Re: [Intel-gfx] [PATCH v1 1/1] drm/dp_mst: Use kHz as link rate units when settig source max link caps at init

On Mon, 03 May 2021, Nikola Cornij wrote: > [why] > Link rate in kHz is what is eventually required to calculate the link > bandwidth, which makes kHz a more generic unit. This should also make > forward-compatibility with new DP standards easier. > > [how] > - Replace 'link rate DPCD code' with

[Intel-gfx] [PATCH v1 1/1] drm/dp_mst: Use kHz as link rate units when settig source max link caps at init

[why] Link rate in kHz is what is eventually required to calculate the link bandwidth, which makes kHz a more generic unit. This should also make forward-compatibility with new DP standards easier. [how] - Replace 'link rate DPCD code' with 'link rate in kHz' when used with

[Intel-gfx] ✓ Fi.CI.BAT: success for Simplify intel_setup_outputs (rev5)

== Series Details == Series: Simplify intel_setup_outputs (rev5) URL : https://patchwork.freedesktop.org/series/88988/ State : success == Summary == CI Bug Log - changes from CI_DRM_10038 -> Patchwork_20051 Summary --- **SUCCESS**

Re: [Intel-gfx] drm/i915: v5.11 stable backport request

On Mon, May 03, 2021 at 06:53:43PM +0200, Greg KH wrote: > On Mon, May 03, 2021 at 07:40:01PM +0300, Imre Deak wrote: > > Stable team, please backport the upstream commits > > > > 7962893ecb85 ("drm/i915: Disable runtime power management during shutdown") > > > > to the v5.11 stable kernel, they

Re: [Intel-gfx] drm/i915: v5.11 stable backport request

On Mon, May 03, 2021 at 07:40:01PM +0300, Imre Deak wrote: > Stable team, please backport the upstream commits > > 7962893ecb85 ("drm/i915: Disable runtime power management during shutdown") > > to the v5.11 stable kernel, they fix a system shutdown failure. > > References: >

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/dp: Handle zeroed port counts in drm_dp_read_downstream_info()

== Series Details == Series: series starting with [1/2] drm/dp: Handle zeroed port counts in drm_dp_read_downstream_info() URL : https://patchwork.freedesktop.org/series/89719/ State : success == Summary == CI Bug Log - changes from CI_DRM_10036_full -> Patchwork_20050_full

[Intel-gfx] drm/i915: v5.11 stable backport request

Stable team, please backport the upstream commits 7962893ecb85 ("drm/i915: Disable runtime power management during shutdown") to the v5.11 stable kernel, they fix a system shutdown failure. References: https://lore.kernel.org/intel-gfx/042237f49ed1fd719126a3407d7c909e49addbea.ca...@gmx.net

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Use correct downstream caps for check Src-Ctl mode for PCON

Re-reported successfully. From: Nautiyal, Ankit K Sent: Friday, April 30, 2021 4:24 AM To: intel-gfx@lists.freedesktop.org; Vudum, Lakshminarayana Subject: RE: ✗ Fi.CI.IGT: failure for drm/i915: Use correct downstream caps for check Src-Ctl mode for PCON Hi Lakshmi, The given possible

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Fix wrong name announced on FB driver switching

Re-reported successfully. -Original Message- From: Janusz Krzysztofik Sent: Friday, April 30, 2021 1:18 AM To: intel-gfx@lists.freedesktop.org Cc: Vudum, Lakshminarayana Subject: Re: ✗ Fi.CI.IGT: failure for drm/i915: Fix wrong name announced on FB driver switching On piątek, 30

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/display/tgl+: Add new sequence step for MST + FEC

== Series Details == Series: drm/i915/display/tgl+: Add new sequence step for MST + FEC URL : https://patchwork.freedesktop.org/series/89714/ State : success == Summary == CI Bug Log - changes from CI_DRM_10036_full -> Patchwork_20048_full

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Use correct downstream caps for check Src-Ctl mode for PCON

== Series Details == Series: drm/i915: Use correct downstream caps for check Src-Ctl mode for PCON URL : https://patchwork.freedesktop.org/series/89639/ State : success == Summary == CI Bug Log - changes from CI_DRM_10027_full -> Patchwork_20030_full

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Fix wrong name announced on FB driver switching

== Series Details == Series: drm/i915: Fix wrong name announced on FB driver switching URL : https://patchwork.freedesktop.org/series/89663/ State : success == Summary == CI Bug Log - changes from CI_DRM_10027_full -> Patchwork_20039_full

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Use correct downstream caps for check Src-Ctl mode for PCON

== Series Details == Series: drm/i915: Use correct downstream caps for check Src-Ctl mode for PCON URL : https://patchwork.freedesktop.org/series/89639/ State : success == Summary == CI Bug Log - changes from CI_DRM_10027 -> Patchwork_20030

[Intel-gfx] [PATCH 27/27] drm/i915/gem: Roll all of context creation together

Now that we have the whole engine set and VM at context creation time, we can just assign those fields instead of creating first and handling the VM and engines later. This lets us avoid creating useless VMs and engine sets and lets us get rid of the complex VM setting code. Signed-off-by: Jason

[Intel-gfx] [PATCH 25/27] drm/i915/selftests: Take a VM in kernel_context()

This better models where we want to go with contexts in general where things like the VM and engine set are create parameters instead of being set after the fact. Signed-off-by: Jason Ekstrand --- .../drm/i915/gem/selftests/i915_gem_context.c | 4 ++--

[Intel-gfx] [PATCH 26/27] i915/gem/selftests: Assign the VM at context creation in igt_shared_ctx_exec

We want to delete __assign_ppgtt and, generally, stop setting the VM after context creation. This is the one place I could find in the selftests where we set a VM after the fact. Signed-off-by: Jason Ekstrand --- drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c | 6 +- 1 file changed,

[Intel-gfx] [PATCH 24/27] drm/i915/gem: Don't allow changing the engine set on running contexts

Signed-off-by: Jason Ekstrand --- drivers/gpu/drm/i915/gem/i915_gem_context.c | 304 1 file changed, 304 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c b/drivers/gpu/drm/i915/gem/i915_gem_context.c index ad6e98d8a4fbd..6e5828fe1a792 100644 ---

[Intel-gfx] [PATCH 22/27] drm/i915/gem: Delay context creation

The current context uAPI allows for two methods of setting context parameters: SET_CONTEXT_PARAM and CONTEXT_CREATE_EXT_SETPARAM. The former is allowed to be called at any time while the later happens as part of GEM_CONTEXT_CREATE. Currently, everything settable via one is settable via the

[Intel-gfx] [PATCH 23/27] drm/i915/gem: Don't allow changing the VM on running contexts

Signed-off-by: Jason Ekstrand --- drivers/gpu/drm/i915/gem/i915_gem_context.c | 267 -- .../gpu/drm/i915/gem/i915_gem_context_types.h | 2 +- .../drm/i915/gem/selftests/i915_gem_context.c | 119 .../drm/i915/selftests/i915_mock_selftests.h | 1 - 4 files changed,

[Intel-gfx] [PATCH 20/27] drm/i915/gem: Return an error ptr from context_lookup

We're about to start doing lazy context creation which means contexts get created in i915_gem_context_lookup and we may start having more errors than -ENOENT. Signed-off-by: Jason Ekstrand Reviewed-by: Daniel Vetter --- drivers/gpu/drm/i915/gem/i915_gem_context.c| 12 ++--

[Intel-gfx] [PATCH 21/27] drm/i915/gt: Drop i915_address_space::file (v2)

There's a big comment saying how useful it is but no one is using this for anything anymore. It was added in 2bfa996e031b ("drm/i915: Store owning file on the i915_address_space") and used for debugfs at the time as well as telling the difference between the global GTT and a PPGTT. In

[Intel-gfx] [PATCH 19/27] drm/i915/gem: Use the proto-context to handle create parameters

This means that the proto-context needs to grow support for engine configuration information as well as setparam logic. Fortunately, we'll be deleting a lot of setparam logic on the primary context shortly so it will hopefully balance out. Signed-off-by: Jason Ekstrand ---

[Intel-gfx] [PATCH 18/27] drm/i915/gem: Optionally set SSEU in intel_context_set_gem

For now this is a no-op because everyone passes in a null SSEU but it lets us get some of the error handling and selftest refactoring plumbed through. Signed-off-by: Jason Ekstrand --- drivers/gpu/drm/i915/gem/i915_gem_context.c | 41 +++

[Intel-gfx] [PATCH 17/27] drm/i915/gem: Rework error handling in default_engines

Since free_engines works for partially constructed engine sets, we can use the usual goto pattern. Signed-off-by: Jason Ekstrand --- drivers/gpu/drm/i915/gem/i915_gem_context.c | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git

[Intel-gfx] [PATCH 16/27] drm/i915/gem: Add an intermediate proto_context struct

The current context uAPI allows for two methods of setting context parameters: SET_CONTEXT_PARAM and CONTEXT_CREATE_EXT_SETPARAM. The former is allowed to be called at any time while the later happens as part of GEM_CONTEXT_CREATE. Currently, everything settable via one is settable via the

[Intel-gfx] [PATCH 15/27] drm/i915: Add gem/i915_gem_context.h to the docs

In order to prevent kernel doc warnings, also fill out docs for any missing fields and fix those that forgot the "@". Signed-off-by: Jason Ekstrand --- Documentation/gpu/i915.rst| 2 + .../gpu/drm/i915/gem/i915_gem_context_types.h | 43 --- 2 files changed,

[Intel-gfx] [PATCH 14/27] drm/i915/gem: Add a separate validate_priority helper

With the proto-context stuff added later in this series, we end up having to duplicate set_priority. This lets us avoid duplicating the validation logic. Signed-off-by: Jason Ekstrand Reviewed-by: Daniel Vetter --- drivers/gpu/drm/i915/gem/i915_gem_context.c | 42 + 1 file

[Intel-gfx] [PATCH 13/27] drm/i915: Stop manually RCU banging in reset_stats_ioctl (v2)

As far as I can tell, the only real reason for this is to avoid taking a reference to the i915_gem_context. The cost of those two atomics probably pales in comparison to the cost of the ioctl itself so we're really not buying ourselves anything here. We're about to make context lookup a tiny bit

[Intel-gfx] [PATCH 12/27] drm/i915/gem: Disallow creating contexts with too many engines

There's no sense in allowing userspace to create more engines than it can possibly access via execbuf. Signed-off-by: Jason Ekstrand Reviewed-by: Daniel Vetter --- drivers/gpu/drm/i915/gem/i915_gem_context.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git

[Intel-gfx] [PATCH 11/27] drm/i915/request: Remove the hook from await_execution

This was only ever used for FENCE_SUBMIT automatic engine selection which was removed in the previous commit. Signed-off-by: Jason Ekstrand --- .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 3 +- drivers/gpu/drm/i915/i915_request.c | 42 ---

[Intel-gfx] [PATCH 10/27] drm/i915/gem: Remove engine auto-magic with FENCE_SUBMIT

Even though FENCE_SUBMIT is only documented to wait until the request in the in-fence starts instead of waiting until it completes, it has a bit more magic than that. If FENCE_SUBMIT is used to submit something to a balanced engine, we would wait to assign engines until the primary request was

[Intel-gfx] [PATCH 09/27] drm/i915/gem: Disallow bonding of virtual engines (v3)

This adds a bunch of complexity which the media driver has never actually used. The media driver does technically bond a balanced engine to another engine but the balanced engine only has one engine in the sibling set. This doesn't actually result in a virtual engine. This functionality was

[Intel-gfx] [PATCH 07/27] drm/i915: Implement SINGLE_TIMELINE with a syncobj (v4)

This API is entirely unnecessary and I'd love to get rid of it. If userspace wants a single timeline across multiple contexts, they can either use implicit synchronization or a syncobj, both of which existed at the time this feature landed. The justification given at the time was that it would

[Intel-gfx] [PATCH 08/27] drm/i915: Drop getparam support for I915_CONTEXT_PARAM_ENGINES

This has never been used by any userspace except IGT and provides no real functionality beyond parroting back parameters userspace passed in as part of context creation or via setparam. If the context is in legacy mode (where you use I915_EXEC_RENDER and friends), it returns success with zero

[Intel-gfx] [PATCH 06/27] drm/i915: Drop the CONTEXT_CLONE API

This API allows one context to grab bits out of another context upon creation. It can be used as a short-cut for setparam(getparam()) for things like I915_CONTEXT_PARAM_VM. However, it's never been used by any real userspace. It's used by a few IGT tests and that's it. Since it doesn't add any

[Intel-gfx] [PATCH 05/27] drm/i915/gem: Return void from context_apply_all

None of the callbacks we use with it return an error code anymore; they all return 0 unconditionally. Signed-off-by: Jason Ekstrand Reviewed-by: Daniel Vetter --- drivers/gpu/drm/i915/gem/i915_gem_context.c | 26 +++-- 1 file changed, 8 insertions(+), 18 deletions(-) diff

[Intel-gfx] [PATCH 04/27] drm/i915/gem: Set the watchdog timeout directly in intel_context_set_gem (v2)

Instead of handling it like a context param, unconditionally set it when intel_contexts are created. For years we've had the idea of a watchdog uAPI floating about. The aim was for media, so that they could set very tight deadlines for their transcodes jobs, so that if you have a corrupt

[Intel-gfx] [PATCH 03/27] drm/i915: Drop I915_CONTEXT_PARAM_NO_ZEROMAP

The idea behind this param is to support OpenCL drivers with relocations because OpenCL reserves 0x0 for NULL and, if we placed memory there, it would confuse CL kernels. It was originally sent out as part of a patch series including libdrm [1] and Beignet [2] support. However, the libdrm and

[Intel-gfx] [PATCH 02/27] drm/i915: Stop storing the ring size in the ring pointer

Previously, we were storing the ring size in the ring pointer before it was actually allocated. We would then guard setting the ring size on checking for CONTEXT_ALLOC_BIT. This is error-prone at best and really only saves us a few bytes on something that already burns at least 4K. Instead, this

[Intel-gfx] [PATCH 01/27] drm/i915: Drop I915_CONTEXT_PARAM_RINGSIZE

This reverts commit 88be76cdafc7 ("drm/i915: Allow userspace to specify ringsize on construction"). This API was originally added for OpenCL but the compute-runtime PR has sat open for a year without action so we can still pull it out if we want. I argue we should drop it for three reasons: 1.

[Intel-gfx] [PATCH 00/27] drm/i915/gem: ioctl clean-ups (v5)

Overview: - This patch series attempts to clean up some of the IOCTL mess we've created over the last few years. The most egregious bit being context mutability. In summary, this series: 1. Drops two never-used context params: RINGSIZE and NO_ZEROMAP 2. Drops the entire CONTEXT_CLONE

[Intel-gfx] [PATCH 9/9] platform/x86/intel_cht_int33fe: Correct "displayport" fwnode reference

The Type-C connector on these devices is connected to DP-2 not DP-1, so the reference must be to the DD04 child-node of the GPU, rather then the DD02 child-node. Signed-off-by: Hans de Goede --- drivers/platform/x86/intel_cht_int33fe_typec.c | 4 ++-- 1 file changed, 2 insertions(+), 2

[Intel-gfx] [PATCH 8/9] usb: typec: altmodes/displayport: Notify drm subsys of hotplug events

Use the new drm_connector_find_by_fwnode() and drm_connector_oob_hotplug_event() functions to let drm/kms drivers know about DisplayPort over Type-C hotplug events. Signed-off-by: Hans de Goede --- Changes in v2: - Add missing depends on DRM to TYPEC_DP_ALTMODE Kconfig entry ---

[Intel-gfx] [PATCH 7/9] usb: typec: altmodes/displayport: Make dp_altmode_notify() more generic

Make dp_altmode_notify() handle the dp->data.conf == 0 case too, rather then having separate code-paths for this in various places which call it. Signed-off-by: Hans de Goede --- drivers/usb/typec/altmodes/displayport.c | 35 +--- 1 file changed, 13 insertions(+), 22

[Intel-gfx] [PATCH 6/9] drm/i915/dp: Add support for out-of-bound hotplug events

On some Cherry Trail devices, DisplayPort over Type-C is supported through a USB-PD microcontroller (e.g. a fusb302) + a mux to switch the superspeed datalines between USB-3 and DP (e.g. a pi3usb30532). The kernel in this case does the PD/alt-mode negotiation itself, rather then everything being

[Intel-gfx] [PATCH 5/9] drm/i915: Associate ACPI connector nodes with connector entries

From: Heikki Krogerus On Intel platforms we know that the ACPI connector device node order will follow the order the driver (i915) decides. The decision is made using the custom Intel ACPI OpRegion (intel_opregion.c), though the driver does not actually know that the values it sends to ACPI

[Intel-gfx] [PATCH 3/9] drm/connector: Add drm_connector_find_by_fwnode() function (v2)

Add a function to find a connector based on a fwnode. This will be used by the new drm_connector_oob_hotplug_event() function which is added by the next patch in this patch-set. Changes in v2: - Complete rewrite to use a global connector list in drm_connector.c rather then using a

[Intel-gfx] [PATCH 4/9] drm/connector: Add support for out-of-band hotplug notification (v2)

Add a new drm_connector_oob_hotplug_event() function and oob_hotplug_event drm_connector_funcs member. On some hardware a hotplug event notification may come from outside the display driver / device. An example of this is some USB Type-C setups where the hardware muxes the DisplayPort data and

[Intel-gfx] [PATCH 2/9] drm/connector: Add a fwnode pointer to drm_connector and register with ACPI

Add a fwnode pointer to struct drm_connector and register an acpi_bus_type for the connectors with the ACPI subsystem (when CONFIG_ACPI is enabled). The adding of the fwnode pointer allows drivers to associate a fwnode that represents a connector with that connector. When the new fwnode pointer

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

Hi All, Here is v2 of my work on making DP over Type-C work on devices where the Type-C controller does not drive the HPD pin on the GPU, but instead we need to forward HPD events from the Type-C controller to the DRM driver. Changes in v2: - Replace the bogus "drm/connector: Make the drm_sysfs

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

Give connector sysfs devices there own device_type, this allows us to check if a device passed to functions dealing with generic devices is a drm_connector or not. A check like this is necessary in the drm_connector_acpi_bus_match() function added in the next patch in this series. Signed-off-by:

Re: [Intel-gfx] [PATCH] drm/i915/display Try YCbCr420 color when RGB fails

On Mon, May 03, 2021 at 01:39:04PM +0200, Werner Sembach wrote: > Thanks for the feedback. I got some questions below. > > On Thu, Apr 29, 2021 at 02:05:53PM +0200, Werner Sembach wrote: > >> When encoder validation of a display mode fails, retry with less bandwidth > >> heavy YCbCr420 color mode,

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

== Series Details == Series: drm/i915: cdclk cleanups URL : https://patchwork.freedesktop.org/series/89700/ State : success == Summary == CI Bug Log - changes from CI_DRM_10036_full -> Patchwork_20046_full Summary --- **SUCCESS**

Re: [Intel-gfx] [PATCH 4/9] drm/connector: Add support for out-of-band hotplug notification

Hi, On 5/3/21 10:00 AM, Heikki Krogerus wrote: > Hi Hans, > > On Wed, Apr 28, 2021 at 11:52:52PM +0200, Hans de Goede wrote: >> +/** >> + * struct drm_connector_oob_hotplug_event_data: OOB hotplug event data >> + * >> + * Contains data about out-of-band hotplug events, signalled through >> + *

Re: [Intel-gfx] [PATCH] drm/i915/tgl+: Add the missing MC CCS/XYUV8888 format support

Reviewed-by: Juha-Pekka Heikkila On 1.5.2021 3.28, Imre Deak wrote: Make sure that the XYUV format is handled correctly when it's used with a MC_CCS modifier framebuffer. Besides this format not working, the driver will also return an incorrect error value when trying to use it, indicating

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/dp: Handle zeroed port counts in drm_dp_read_downstream_info()

== Series Details == Series: series starting with [1/2] drm/dp: Handle zeroed port counts in drm_dp_read_downstream_info() URL : https://patchwork.freedesktop.org/series/89719/ State : success == Summary == CI Bug Log - changes from CI_DRM_10036 -> Patchwork_20050

Re: [Intel-gfx] [PATCH v5 14/16] dma-direct: Allocate memory from restricted DMA pool if available

On Fri, Apr 23, 2021 at 9:46 PM Robin Murphy wrote: > > On 2021-04-22 09:15, Claire Chang wrote: > > The restricted DMA pool is preferred if available. > > > > The restricted DMA pools provide a basic level of protection against the > > DMA overwriting buffer contents at unexpected times.

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display/tgl+: Add new sequence step for MST + FEC

== Series Details == Series: drm/i915/display/tgl+: Add new sequence step for MST + FEC URL : https://patchwork.freedesktop.org/series/89714/ State : success == Summary == CI Bug Log - changes from CI_DRM_10036 -> Patchwork_20048 Summary

Re: [Intel-gfx] [RFC v2] drm/i915: lpsp with hdmi/dp outputs

> -Original Message- > From: Ville Syrjälä > Sent: Friday, April 30, 2021 11:10 PM > To: Gupta, Anshuman > Cc: intel-gfx@lists.freedesktop.org; Kai Vehmanen > ; Shankar, Uma > Subject: Re: [RFC v2] drm/i915: lpsp with hdmi/dp outputs > > On Fri, Apr 30, 2021 at 05:23:55PM +0530,

  1   2   >