Re: [Intel-gfx] [PATCH] drm/i915: pps_lock moved to encoder to support dual EDP

2021-12-20 Thread Jani Nikula
On Mon, 20 Dec 2021, Animesh Manna wrote: > @@ -359,7 +359,7 @@ static void intel_pps_get_registers(struct intel_dp > *intel_dp, > struct pps_registers *regs) > { > struct drm_i915_private *dev_priv = dp_to_i915(intel_dp); > - int pps_idx = 0; > +

Re: [Intel-gfx] [PATCH 1/3] drm/i915/guc: Temporarily bump the GuC load timeout

2021-12-20 Thread Matthew Brost
On Mon, Dec 20, 2021 at 04:52:19PM -0800, john.c.harri...@intel.com wrote: > From: John Harrison > > There is a known (but exceedingly unlikely) race condition where the > asynchronous frequency management code could reduce the GT clock while > a GuC reload is in progress (during a full GT reset)

[Intel-gfx] ✗ Fi.CI.BUILD: failure for Update to GuC version 69.0.3

2021-12-20 Thread Patchwork
== Series Details == Series: Update to GuC version 69.0.3 URL : https://patchwork.freedesktop.org/series/98249/ State : failure == Summary == Applying: drm/i915/guc: Temporarily bump the GuC load timeout Applying: drm/i915/guc: Update to GuC version 69.0.3 Using index info to reconstruct a bas

[Intel-gfx] [PATCH 3/3] drm/i915/guc: Improve GuC loading status check/error reports

2021-12-20 Thread John . C . Harrison
From: John Harrison If the GuC fails to load, it is useful to know what firmware file / version was attempted. So move the version info report to before the load attempt rather than only after a successful load. If the GuC does fail to load, then make the error messages visible rather than being

[Intel-gfx] [PATCH 2/3] drm/i915/guc: Update to GuC version 69.0.3

2021-12-20 Thread John . C . Harrison
From: John Harrison Update to the latest GuC release. The latest GuC firmware introduces a number of interface changes: GuC may return NO_RESPONSE_RETRY message for requests sent over CTB. Add support for this reply and try resending the request again as a new CTB message. A KLV (key-length-va

[Intel-gfx] [PATCH 0/3] Update to GuC version 69.0.3

2021-12-20 Thread John . C . Harrison
From: John Harrison Update to the latest GuC version. This includes a suite of interface changes and new features with corresponding i915 side changes. Signed-off-by: John Harrison John Harrison (3): drm/i915/guc: Temporarily bump the GuC load timeout drm/i915/guc: Update to GuC version

[Intel-gfx] [PATCH 1/3] drm/i915/guc: Temporarily bump the GuC load timeout

2021-12-20 Thread John . C . Harrison
From: John Harrison There is a known (but exceedingly unlikely) race condition where the asynchronous frequency management code could reduce the GT clock while a GuC reload is in progress (during a full GT reset). A fix is in progress but there are complex locking issues to be resolved. In the me

[Intel-gfx] [CI] PR for new GuC v69.0.3

2021-12-20 Thread John . C . Harrison
The following changes since commit b0e898fbaf377c99a36aac6fdeb7250003648ca4: linux-firmware: Update firmware file for Intel Bluetooth 9462 (2021-11-23 12:31:45 -0500) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-firmware guc_v69.0.3 for you to fetch changes

Re: [Intel-gfx] [PATCH] drm/i915/guc: Request RP0 before loading firmware

2021-12-20 Thread Sundaresan, Sujaritha
On 12/16/2021 3:30 PM, Vinay Belgaumkar wrote: By default, GT (and GuC) run at RPn. Requesting for RP0 before firmware load can speed up DMA and HuC auth as well. In addition to writing to 0xA008, we also need to enable swreq in 0xA024 so that Punit will pay heed to our request. SLPC will rest

[Intel-gfx] [CI] PR for new GuC v69.0.3

2021-12-20 Thread John . C . Harrison
The following changes since commit b0e898fbaf377c99a36aac6fdeb7250003648ca4: linux-firmware: Update firmware file for Intel Bluetooth 9462 (2021-11-23 12:31:45 -0500) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-firmware guc_v69.0.3 for you to fetch changes

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/pxp: Hold RPM wakelock during PXP unbind

2021-12-20 Thread Patchwork
== Series Details == Series: drm/i915/pxp: Hold RPM wakelock during PXP unbind URL : https://patchwork.freedesktop.org/series/98245/ State : success == Summary == CI Bug Log - changes from CI_DRM_11016_full -> Patchwork_21881_full Summary -

Re: [Intel-gfx] How to fix screen resolution detection?

2021-12-20 Thread Alan Stern
On Mon, Dec 20, 2021 at 12:14:48PM +0200, Jani Nikula wrote: > On Fri, 17 Dec 2021, Alan Stern wrote: > > The screen resolution on my laptop is not reported accurately. Here's > > an extract from the output of xdpyinfo: > > > > screen #0: > > dimensions:3200x1800 pixels (847x476 millimeter

Re: [Intel-gfx] [PATCH] drm/i915: pps_lock moved to encoder to support dual EDP

2021-12-20 Thread Ville Syrjälä
On Mon, Dec 20, 2021 at 12:05:40PM +0530, Animesh Manna wrote: > Currently dev_priv->pps_lock is used for locking mechanism and one > instance of pps registers are used for pps register programming. > Second instance enabled as per port number and pps_lock is moved > under encoder. Nak. Please rea

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/pxp: Hold RPM wakelock during PXP unbind

2021-12-20 Thread Patchwork
== Series Details == Series: drm/i915/pxp: Hold RPM wakelock during PXP unbind URL : https://patchwork.freedesktop.org/series/98245/ State : success == Summary == CI Bug Log - changes from CI_DRM_11016 -> Patchwork_21881 Summary ---

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Fix possible uninitialized variable in parallel extension (rev2)

2021-12-20 Thread Patchwork
== Series Details == Series: drm/i915: Fix possible uninitialized variable in parallel extension (rev2) URL : https://patchwork.freedesktop.org/series/98207/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11016_full -> Patchwork_21880_full =

[Intel-gfx] [PATCH] drm/i915/pxp: Hold RPM wakelock during PXP unbind

2021-12-20 Thread Juston Li
Similar to commit b8d8436840ca ("drm/i915/gt: Hold RPM wakelock during PXP suspend") but to fix the same warning for unbind during shutdown: [ cut here ] RPM wakelock ref not held during HW access WARNING: CPU: 0 PID: 4139 at drivers/gpu/drm/i915/intel_runtime_pm.h:115 gen1

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/vlv_dsi: Add DMI quirk for wrong panel modeline in BIOS on Asus TF103C

2021-12-20 Thread Patchwork
== Series Details == Series: drm/i915/vlv_dsi: Add DMI quirk for wrong panel modeline in BIOS on Asus TF103C URL : https://patchwork.freedesktop.org/series/98239/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11016_full -> Patchwork_21879_full

Re: [Intel-gfx] [PATCH] drm/i915/guc: Log engine resets

2021-12-20 Thread John Harrison
On 12/20/2021 07:00, Tvrtko Ursulin wrote: On 17/12/2021 16:22, Matthew Brost wrote: On Fri, Dec 17, 2021 at 12:15:53PM +, Tvrtko Ursulin wrote: On 14/12/2021 15:07, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Log engine resets done by the GuC firmware in the similar way it is done by

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 08/11] lib/store: Refactor common store code into helper function

2021-12-20 Thread Zbigniew Kempczyński
On Thu, Dec 16, 2021 at 02:40:21PM -0800, John Harrison wrote: > On 12/15/2021 23:46, Zbigniew Kempczyński wrote: > > On Mon, Dec 13, 2021 at 03:29:11PM -0800, john.c.harri...@intel.com wrote: > > > From: John Harrison > > > > > > A lot of tests use almost identical code for creating a batch buff

Re: [Intel-gfx] [PATCH] drm/i915/guc: Log engine resets

2021-12-20 Thread Matthew Brost
On Mon, Dec 20, 2021 at 03:00:53PM +, Tvrtko Ursulin wrote: > > On 17/12/2021 16:22, Matthew Brost wrote: > > On Fri, Dec 17, 2021 at 12:15:53PM +, Tvrtko Ursulin wrote: > > > > > > On 14/12/2021 15:07, Tvrtko Ursulin wrote: > > > > From: Tvrtko Ursulin > > > > > > > > Log engine resets

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix possible uninitialized variable in parallel extension (rev2)

2021-12-20 Thread Patchwork
== Series Details == Series: drm/i915: Fix possible uninitialized variable in parallel extension (rev2) URL : https://patchwork.freedesktop.org/series/98207/ State : success == Summary == CI Bug Log - changes from CI_DRM_11016 -> Patchwork_21880 ===

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gem: Use local pointer ttm for __i915_ttm_move (rev3)

2021-12-20 Thread Patchwork
== Series Details == Series: drm/i915/gem: Use local pointer ttm for __i915_ttm_move (rev3) URL : https://patchwork.freedesktop.org/series/97572/ State : success == Summary == CI Bug Log - changes from CI_DRM_10984 -> Patchwork_21803 Summar

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gt: reset RING_HEAD during intel_gt_unset_wedged

2021-12-20 Thread Patchwork
== Series Details == Series: drm/i915/gt: reset RING_HEAD during intel_gt_unset_wedged URL : https://patchwork.freedesktop.org/series/98230/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11015_full -> Patchwork_21878_full S

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/vlv_dsi: Add DMI quirk for wrong panel modeline in BIOS on Asus TF103C

2021-12-20 Thread Patchwork
== Series Details == Series: drm/i915/vlv_dsi: Add DMI quirk for wrong panel modeline in BIOS on Asus TF103C URL : https://patchwork.freedesktop.org/series/98239/ State : success == Summary == CI Bug Log - changes from CI_DRM_11016 -> Patchwork_21879 ==

[Intel-gfx] [PATCH] drm/i915/vlv_dsi: Add DMI quirk for wrong panel modeline in BIOS on Asus TF103C

2021-12-20 Thread Hans de Goede
Vtotal is wrong in the BIOS supplied modeline for the DSI panel on the Asus TF103C leading to the last line of the display being shown as the first line. The factory installed Android has a hardcoded modeline in its kernel, causing it to not suffer from this BIOS bug; and the Android boot-splash

Re: [Intel-gfx] [PATCH] drm/i915/guc: Log engine resets

2021-12-20 Thread Tvrtko Ursulin
On 17/12/2021 16:22, Matthew Brost wrote: On Fri, Dec 17, 2021 at 12:15:53PM +, Tvrtko Ursulin wrote: On 14/12/2021 15:07, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Log engine resets done by the GuC firmware in the similar way it is done by the execlists backend. This way we have not

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: reset RING_HEAD during intel_gt_unset_wedged

2021-12-20 Thread Patchwork
== Series Details == Series: drm/i915/gt: reset RING_HEAD during intel_gt_unset_wedged URL : https://patchwork.freedesktop.org/series/98230/ State : success == Summary == CI Bug Log - changes from CI_DRM_11015 -> Patchwork_21878 Summary ---

Re: [Intel-gfx] [PATCH 1/4] drm/i915/guc: Speed up GuC log dumps

2021-12-20 Thread Daniele Ceraolo Spurio
On 12/10/2021 10:58 PM, john.c.harri...@intel.com wrote: From: John Harrison Add support for telling the debugfs interface the size of the GuC log dump in advance. Without that, the underlying framework keeps calling the 'show' function with larger and larger buffer allocations until it fits

[Intel-gfx] [PATCH] drm/i915/gt: reset RING_HEAD during intel_gt_unset_wedged

2021-12-20 Thread Tejas Upadhyay
During repeated wedged-unwedged, it is found that i915_request_retire zaps the old request with 0x6b6b6b6b. On unwedged, we write a new request at RING_TAIL, expecting to start executuing from that position, but execution resumes from RING_HEAD (preserved from an earlier wakeup before wedging) and

Re: [Intel-gfx] How to fix screen resolution detection?

2021-12-20 Thread Jani Nikula
On Fri, 17 Dec 2021, Alan Stern wrote: > The screen resolution on my laptop is not reported accurately. Here's > an extract from the output of xdpyinfo: > > screen #0: > dimensions:3200x1800 pixels (847x476 millimeters) > resolution:96x96 dots per inch > > The number of pixels is cor

Re: [Intel-gfx] [Linaro-mm-sig] [RFC PATCH 1/2] dma-fence: Avoid establishing a locking order between fence classes

2021-12-20 Thread Daniel Vetter
On Tue, Dec 07, 2021 at 09:46:47PM +0100, Thomas Hellström wrote: > > On 12/7/21 19:08, Daniel Vetter wrote: > > Once more an entire week behind on mails, but this looked interesting > > enough. > > > > On Fri, Dec 03, 2021 at 03:18:01PM +0100, Thomas Hellström wrote: > > > On Fri, 2021-12-03 at