[Intel-gfx] [PATCH 0/3] Prepare error capture for asynchronous migration

This patch series prepares error capture for asynchronous migration, where the vma pages may not reflect the pages the GPU is currently executing from but may be several migrations ahead. The first patch deals with refcounting sg-list so that they don't disappear under the capture code, which typi

[Intel-gfx] [PATCH 1/3] drm/i915: Introduce refcounted sg-tables

As we start to introduce asynchronous failsafe object migration, where we update the object state and then submit asynchronous commands we need to record what memory resources are actually used by various part of the command stream. Initially for three purposes: 1) Error capture. 2) Asynchronous m

[Intel-gfx] [PATCH 2/3] drm/i915: Update error capture code to avoid using the current vma state

With asynchronous migrations, the vma state may be several migrations ahead of the state that matches the request we're capturing. Address that by introducing an i915_vma_snapshot structure that can be used to snapshot relevant state at request submission. In order to make sure we access the correc

[Intel-gfx] [PATCH 3/3] drm/i915: Initial introduction of vma resources

From: Thomas Hellström The vma resource are needed for asynchronous bind management and are similar to TTM resources. They contain the data needed for asynchronous unbinding (typically the vm range, any backend private information and a means to do refcounting and to hold the unbinding for error

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gem: Don't try to map and fence 8K/bigjoiner scanout buffers

== Series Details == Series: drm/i915/gem: Don't try to map and fence 8K/bigjoiner scanout buffers URL : https://patchwork.freedesktop.org/series/96279/ State : success == Summary == CI Bug Log - changes from CI_DRM_10788 -> Patchwork_21442

Re: [Intel-gfx] [PATCH] drm/i915/display: Remove check for low voltage sku for max dp source rate

On Tue, 26 Oct 2021, Ankit Nautiyal wrote: > The low voltage sku check can be ignored as OEMs need to consider that > when designing the board and then put any limits in VBT. > > Same is now changed in Bspec pages. > > v2: Added debug print for combo PHY procmon reference values > to get voltage c

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Prepare error capture for asynchronous migration

== Series Details == Series: Prepare error capture for asynchronous migration URL : https://patchwork.freedesktop.org/series/96281/ State : warning == Summary == $ dim checkpatch origin/drm-tip 75857b20e47c drm/i915: Introduce refcounted sg-tables 91f817d8b76b drm/i915: Update error capture co

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Allow engine reset failure to do a GT reset in hangcheck selftest

Hi, On 10/21/21 22:37, Matthew Brost wrote: On Thu, Oct 21, 2021 at 08:15:49AM +0200, Thomas Hellström wrote: Hi, Matthew, On Mon, 2021-10-11 at 16:47 -0700, Matthew Brost wrote: The hangcheck selftest blocks per engine resets by setting magic bits in the reset flags. This is incorrect for Gu

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/display: Remove check for low voltage sku for max dp source rate (rev4)

== Series Details == Series: drm/i915/display: Remove check for low voltage sku for max dp source rate (rev4) URL : https://patchwork.freedesktop.org/series/95444/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10788_full -> Patchwork_21441_full ===

[Intel-gfx] ✓ Fi.CI.BAT: success for Prepare error capture for asynchronous migration

== Series Details == Series: Prepare error capture for asynchronous migration URL : https://patchwork.freedesktop.org/series/96281/ State : success == Summary == CI Bug Log - changes from CI_DRM_10788 -> Patchwork_21443 Summary --- *

[Intel-gfx] [PATCH] drm/i915/dp: fix integer overflow in 128b/132b data rate calculation

The intermediate value 100 * 10 * 9671 overflows 32 bits, so force promotion to a bigger type. >From the logs: [drm:intel_dp_compute_config [i915]] DP link rate required 3657063 available -580783288 Fixes: 48efd014f0ea ("drm/i915/dp: add max data rate calculation for UHBR rates") Cc: Manas

Re: [Intel-gfx] [PATCH 00/47] GuC submission support

Quoting Matthew Brost (2021-10-25 18:15:09) > On Mon, Oct 25, 2021 at 12:37:02PM +0300, Joonas Lahtinen wrote: > > Quoting Matthew Brost (2021-10-22 19:42:19) > > > On Fri, Oct 22, 2021 at 12:35:04PM +0300, Joonas Lahtinen wrote: > > > > Hi Matt & John, > > > > > > > > Can you please queue patches

Re: [Intel-gfx] [PATCH] drm/i915/gem: Don't try to map and fence 8K/bigjoiner scanout buffers

On Mon, Oct 25, 2021 at 11:38:11PM -0700, Vivek Kasireddy wrote: > On platforms capable of allowing 8K (7680 x 4320) modes, pinning 2 or > more framebuffers/scanout buffers results in only one that is mappable/ > fenceable. Therefore, pageflipping between these 2 FBs where only one > is mappable/fe

Re: [Intel-gfx] [PATCH] drm/i915/trace: Hide backend specific fields behind Kconfig

Quoting John Harrison (2021-10-26 00:06:54) > On 10/25/2021 09:34, Matthew Brost wrote: > > Hide the guc_id and tail fields, for request trace points, behind > > CONFIG_DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig option. Trace points > > are ABI (maybe?) so don't change them without kernel developers Kc

Re: [Intel-gfx] [PATCH] drm/i915/dp: fix integer overflow in 128b/132b data rate calculation

On Tue, Oct 26, 2021 at 11:42:07AM +0300, Jani Nikula wrote: > The intermediate value 100 * 10 * 9671 overflows 32 bits, so force > promotion to a bigger type. > > >From the logs: > > [drm:intel_dp_compute_config [i915]] DP link rate required 3657063 available > -580783288 > > Fixes: 48efd0

Re: [Intel-gfx] [PATCH] drm/i915/guc: Fix recursive lock in GuC submission

Quoting Matthew Brost (2021-10-25 20:13:22) > On Mon, Oct 25, 2021 at 03:23:00PM +0300, Joonas Lahtinen wrote: > > Quoting Thomas Hellström (2021-10-21 08:39:48) > > > On Wed, 2021-10-20 at 12:21 -0700, Matthew Brost wrote: > > > > > > > > > > Fixes: 1a52faed31311 ("drm/i915/guc: Take engine PM

Re: [Intel-gfx] [PATCH 1/2] drm/i915/gtt: flush the scratch page

On 10/22/21 18:48, Matthew Auld wrote: The scratch page is directly visible in the users address space, and while this is forced as CACHE_LLC, by the kernel, we still have to contend with things like "Bypass-LLC" MOCS. So just flush no matter what. Signed-off-by: Matthew Auld Cc: Thomas Hells

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gem: Don't try to map and fence 8K/bigjoiner scanout buffers

== Series Details == Series: drm/i915/gem: Don't try to map and fence 8K/bigjoiner scanout buffers URL : https://patchwork.freedesktop.org/series/96279/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10788_full -> Patchwork_21442_full ===

[Intel-gfx] [PATCH v2] drm/i915/dp: fix integer overflow in 128b/132b data rate calculation

The intermediate value 100 * 10 * 9671 overflows 32 bits, so force promotion to a bigger type. >From the logs: [drm:intel_dp_compute_config [i915]] DP link rate required 3657063 available -580783288 v2: Use mul_u32_u32() (Ville) Fixes: 48efd014f0ea ("drm/i915/dp: add max data rate calculat

Re: [Intel-gfx] [PATCH 1/2] drm/i915/gtt: flush the scratch page

On 10/22/21 18:48, Matthew Auld wrote: The scratch page is directly visible in the users address space, and while this is forced as CACHE_LLC, by the kernel, we still have to contend with things like "Bypass-LLC" MOCS. So just flush no matter what. Signed-off-by: Matthew Auld Cc: Thomas Hells

Re: [Intel-gfx] [PATCH v2] drm/i915/dp: fix integer overflow in 128b/132b data rate calculation

On Tue, Oct 26, 2021 at 12:34:07PM +0300, Jani Nikula wrote: > The intermediate value 100 * 10 * 9671 overflows 32 bits, so force > promotion to a bigger type. > > >From the logs: > > [drm:intel_dp_compute_config [i915]] DP link rate required 3657063 available > -580783288 > > v2: Use mul_u

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/dp: fix integer overflow in 128b/132b data rate calculation (rev2)

== Series Details == Series: drm/i915/dp: fix integer overflow in 128b/132b data rate calculation (rev2) URL : https://patchwork.freedesktop.org/series/96289/ State : warning == Summary == $ dim checkpatch origin/drm-tip 5c2b81fc498b drm/i915/dp: fix integer overflow in 128b/132b data rate c

Re: [Intel-gfx] [PATCH 2/2] drm/i915/gtt: stop caching the scratch page

On 10/22/21 18:48, Matthew Auld wrote: Normal users shouldn't be hitting this, likely this would indicate a userspace bug. So don't bother caching, which should be safe now that we manually flush the page. Suggested-by: Chris Wilson Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Chris

[Intel-gfx] ✗ Fi.CI.IGT: failure for Prepare error capture for asynchronous migration

== Series Details == Series: Prepare error capture for asynchronous migration URL : https://patchwork.freedesktop.org/series/96281/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10788_full -> Patchwork_21443_full Summary --

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/dp: fix integer overflow in 128b/132b data rate calculation (rev2)

== Series Details == Series: drm/i915/dp: fix integer overflow in 128b/132b data rate calculation (rev2) URL : https://patchwork.freedesktop.org/series/96289/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10788 -> Patchwork_21444 ==

[Intel-gfx] [PATCH 0/2] Remove check for ComboPHY I/O voltage for DP source rate

This patch series is continuation of the discussion in: https://patchwork.freedesktop.org/patch/457398/?series=95444&rev=1 Along with a patch to add debug print voltage configuration for combo PHY ports. Ankit Nautiyal (2): drm/i915/display: Remove check for low voltage sku for max dp source

[Intel-gfx] [PATCH 1/2] drm/i915/display: Remove check for low voltage sku for max dp source rate

The low voltage sku check can be ignored as OEMs need to consider that when designing the board and then put any limits in VBT. Same is now changed in Bspec pages. Signed-off-by: Ankit Nautiyal --- drivers/gpu/drm/i915/display/intel_dp.c | 32 +++-- 1 file changed, 3 inserti

[Intel-gfx] [PATCH 2/2] drm/i915/intel_combo_phy: Print procmon ref values

Add debug print for Procmon Ref values, to help get the voltage configurations of combo PHYs. Signed-off-by: Ankit Nautiyal Suggested-by: Imre Deak --- drivers/gpu/drm/i915/display/intel_combo_phy.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_combo

Re: [Intel-gfx] [PATCH] drm/i915: Fix type1 DVI DP dual mode adapter heuristic for modern platforms

On Mon, 25 Oct 2021, Ville Syrjala wrote: > From: Ville Syrjälä > > Looks like we never updated intel_bios_is_port_dp_dual_mode() when > the VBT port mapping became erratic on modern platforms. This > is causing us to look up the wrong child device and thus throwing > the heuristic off (ie. we mi

Re: [Intel-gfx] [PATCH] drm/i915/display: Remove check for low voltage sku for max dp source rate

On 10/26/2021 1:23 PM, Jani Nikula wrote: On Tue, 26 Oct 2021, Ankit Nautiyal wrote: The low voltage sku check can be ignored as OEMs need to consider that when designing the board and then put any limits in VBT. Same is now changed in Bspec pages. v2: Added debug print for combo PHY procmo

[Intel-gfx] [PATCH v2 0/9] drm/i915: PREEMPT_RT related fixups.

the following patches are from the PREEMPT_RT queue. It is mostly about disabling interrupts/preemption which leads to problems. Patches 1-4 are independent of PREEMPT_RT. Unfortunately DRM_I915_LOW_LEVEL_TRACEPOINTS had to be disabled because it acquires locks from within trace points. It has bee

[Intel-gfx] [PATCH 2/9] drm/i915/gt: Queue and wait for the irq_work item.

Disabling interrupts and invoking the irq_work function directly breaks on PREEMPT_RT. PREEMPT_RT does not invoke all irq_work from hardirq context because some of the user have spinlock_t locking in the callback function. These locks are then turned into a sleeping locks which can not be acquired

[Intel-gfx] [PATCH 3/9] drm/i915/gt: Use spin_lock_irq() instead of local_irq_disable() + spin_lock()

execlists_dequeue() is invoked from a function which uses local_irq_disable() to disable interrupts so the spin_lock() behaves like spin_lock_irq(). This breaks PREEMPT_RT because local_irq_disable() + spin_lock() is not the same as spin_lock_irq(). execlists_dequeue_irq() and execlists_dequeue()

[Intel-gfx] [PATCH 4/9] drm/i915: Drop the irqs_disabled() check

The !irqs_disabled() check triggers on PREEMPT_RT even with i915_sched_engine::lock acquired. The reason is the lock is transformed into a sleeping lock on PREEMPT_RT and does not disable interrupts. There is no need to check for disabled interrupts. The lockdep annotation below already check if t

[Intel-gfx] [PATCH 1/9] drm/i915: Don't disable interrupts and pretend a lock as been acquired in __timeline_mark_lock().

This is a revert of commits d67739268cf0e ("drm/i915/gt: Mark up the nested engine-pm timeline lock as irqsafe") 6c69a45445af9 ("drm/i915/gt: Mark context->active_count as protected by timeline->mutex") The existing code leads to a different behaviour depending on whether lockdep is enable

[Intel-gfx] [PATCH 5/9] drm/i915: Use preempt_disable/enable_rt() where recommended

From: Mike Galbraith Mario Kleiner suggest in commit ad3543ede630f ("drm/intel: Push get_scanout_position() timestamping into kms driver.") a spots where preemption should be disabled on PREEMPT_RT. The difference is that on PREEMPT_RT the intel_uncore::lock disables neither preemption nor in

[Intel-gfx] [PATCH 8/9] drm/i915: Disable tracing points on PREEMPT_RT

Luca Abeni reported this: | BUG: scheduling while atomic: kworker/u8:2/15203/0x0003 | CPU: 1 PID: 15203 Comm: kworker/u8:2 Not tainted 4.19.1-rt3 #10 | Call Trace: | rt_spin_lock+0x3f/0x50 | gen6_read32+0x45/0x1d0 [i915] | g4x_get_vblank_counter+0x36/0x40 [i915] | trace_event_raw_event_i915

[Intel-gfx] [PATCH 9/9] drm/i915: skip DRM_I915_LOW_LEVEL_TRACEPOINTS with NOTRACE

The order of the header files is important. If this header file is included after tracepoint.h was included then the NOTRACE here becomes a nop. Currently this happens for two .c files which use the tracepoitns behind DRM_I915_LOW_LEVEL_TRACEPOINTS. Cc: Steven Rostedt Signed-off-by: Sebastian And

[Intel-gfx] [PATCH 6/9] drm/i915: Don't disable interrupts on PREEMPT_RT during atomic updates

From: Mike Galbraith Commit 8d7849db3eab7 ("drm/i915: Make sprite updates atomic") started disabling interrupts across atomic updates. This breaks on PREEMPT_RT because within this section the code attempt to acquire spinlock_t locks which are sleeping locks on PREEMPT_RT. According to the c

[Intel-gfx] [PATCH 7/9] drm/i915: Don't check for atomic context on PREEMPT_RT

The !in_atomic() check in _wait_for_atomic() triggers on PREEMPT_RT because the uncore::lock is a spinlock_t and does not disable preemption or interrupts. Changing the uncore:lock to a raw_spinlock_t doubles the worst case latency on an otherwise idle testbox during testing. Therefore I'm current

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/dp: fix integer overflow in 128b/132b data rate calculation (rev3)

== Series Details == Series: drm/i915/dp: fix integer overflow in 128b/132b data rate calculation (rev3) URL : https://patchwork.freedesktop.org/series/96289/ State : warning == Summary == $ dim checkpatch origin/drm-tip 4759ea7118a7 drm/i915/dp: fix integer overflow in 128b/132b data rate c

[Intel-gfx] [PATCH] drm/i915/dmabuf: include asm/smp.h for cache operations

From: Arnd Bergmann The x86 low-level cache management operations are declared in asm/smp.h, so drivers that call into this code need to include the header: drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c:248:3: error: implicit declaration of function 'wbinvd_on_all_cpus' [-Werror,-Wimplicit-functio

Re: [Intel-gfx] [PATCH 1/2] drm: Add Gamma and Degamma LUT sizes props to drm_crtc to validate.

Dear Mark, Thank you for your patch. On 13.10.21 20:12, Mark Yacoub wrote: From: Mark Yacoub [Why] 1. drm_atomic_helper_check doesn't check for the LUT sizes of either Gamma or Degamma props in the new CRTC state, allowing any invalid size to be passed on. 2. Each driver has its own LUT size

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

Hi Dave and Dan, Last pull request for me for v5.15 I hope. Out for vacation until the third week of november, Maxime offered to do the remainder of v5.15. ~Maarten drm-misc-fixes-2021-10-26: drm-misc-fixes for v5.15-rc8: - Fix fence leak in ttm_transfered_destroy. - Add quirk for Aya Neo 2021 -

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dp: fix integer overflow in 128b/132b data rate calculation (rev3)

== Series Details == Series: drm/i915/dp: fix integer overflow in 128b/132b data rate calculation (rev3) URL : https://patchwork.freedesktop.org/series/96289/ State : success == Summary == CI Bug Log - changes from CI_DRM_10789 -> Patchwork_21445 ==

[Intel-gfx] [PATCH v2 2/2] drm/i915/intel_combo_phy: Print procmon ref values

Add debug print for Procmon Ref values, to help get the voltage configurations of combo PHYs. v2: Corrected drm_dbg to drm_dbg_kms (Jani) Suggested-by: Imre Deak Signed-off-by: Ankit Nautiyal --- drivers/gpu/drm/i915/display/intel_combo_phy.c | 4 1 file changed, 4 insertions(+) diff --g

[Intel-gfx] ✓ Fi.CI.BAT: success for Remove check for ComboPHY I/O voltage for DP source rate

== Series Details == Series: Remove check for ComboPHY I/O voltage for DP source rate URL : https://patchwork.freedesktop.org/series/96293/ State : success == Summary == CI Bug Log - changes from CI_DRM_10789 -> Patchwork_21446 Summary

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: PREEMPT_RT related fixups. (rev3)

== Series Details == Series: drm/i915: PREEMPT_RT related fixups. (rev3) URL : https://patchwork.freedesktop.org/series/95463/ State : warning == Summary == $ dim checkpatch origin/drm-tip 8fdcd01953e1 drm/i915: Don't disable interrupts and pretend a lock as been acquired in __timeline_mark_l

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: PREEMPT_RT related fixups. (rev3)

== Series Details == Series: drm/i915: PREEMPT_RT related fixups. (rev3) URL : https://patchwork.freedesktop.org/series/95463/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +drivers/gpu/drm/i915/

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/dmabuf: include asm/smp.h for cache operations

== Series Details == Series: drm/i915/dmabuf: include asm/smp.h for cache operations URL : https://patchwork.freedesktop.org/series/96300/ State : warning == Summary == $ dim checkpatch origin/drm-tip a0c95634697f drm/i915/dmabuf: include asm/smp.h for cache operations -:25: WARNING:INCLUDE_LI

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: PREEMPT_RT related fixups. (rev3)

== Series Details == Series: drm/i915: PREEMPT_RT related fixups. (rev3) URL : https://patchwork.freedesktop.org/series/95463/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10789 -> Patchwork_21447 Summary --- **FAIL

[Intel-gfx] [PATCH] i915/selftest: Disable irq to calc eng timestamp

gt_pm selftest calculates engine ticks cycles and wall time cycles by delta of respective engine elapsed TIMESTAMP and ktime for period of 1000us. It compares the engine ticks cycles with wall time cycles. Disable local cpu interrupt so that interrupt handler should not preempt the measure_clocks(

Re: [Intel-gfx] [PATCH 4/9] drm/i915/dmabuf: add paranoid flush-on-acquire

On Mon, Oct 18, 2021 at 06:45:03PM +0100, Matthew Auld wrote: > As pointed out by Thomas, we likely need to flush the pages here if the > GPU can read the page contents directly from main memory. Underneath we > don't know what the sg_table is pointing to, so just add a > wbinvd_on_all_cpus() here,

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dmabuf: include asm/smp.h for cache operations

== Series Details == Series: drm/i915/dmabuf: include asm/smp.h for cache operations URL : https://patchwork.freedesktop.org/series/96300/ State : success == Summary == CI Bug Log - changes from CI_DRM_10789 -> Patchwork_21448 Summary -

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dp: fix integer overflow in 128b/132b data rate calculation (rev3)

== Series Details == Series: drm/i915/dp: fix integer overflow in 128b/132b data rate calculation (rev3) URL : https://patchwork.freedesktop.org/series/96289/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10789_full -> Patchwork_21445_full

[Intel-gfx] ✓ Fi.CI.BAT: success for Remove check for ComboPHY I/O voltage for DP source rate (rev2)

== Series Details == Series: Remove check for ComboPHY I/O voltage for DP source rate (rev2) URL : https://patchwork.freedesktop.org/series/96293/ State : success == Summary == CI Bug Log - changes from CI_DRM_10789 -> Patchwork_21449 Summa

[Intel-gfx] ✓ Fi.CI.BAT: success for i915/selftest: Disable irq to calc eng timestamp

== Series Details == Series: i915/selftest: Disable irq to calc eng timestamp URL : https://patchwork.freedesktop.org/series/96301/ State : success == Summary == CI Bug Log - changes from CI_DRM_10789 -> Patchwork_21450 Summary --- *

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dmabuf: include asm/smp.h for cache operations

== Series Details == Series: drm/i915/dmabuf: include asm/smp.h for cache operations URL : https://patchwork.freedesktop.org/series/96300/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10789_full -> Patchwork_21448_full Sum

Re: [Intel-gfx] [PATCH v2 14/17] uapi/drm/dg2: Format modifier for DG2 unified compression and clear color

On 2021-10-25 at 14:20:02 +0300, Juha-Pekka Heikkila wrote: > On 21.10.2021 17.35, Ville Syrjälä wrote: > > On Thu, Oct 21, 2021 at 07:56:24PM +0530, Ramalingam C wrote: > > > From: Matt Roper > > > > > > DG2 unifies render compression and media compression into a single > > > format for the firs

Re: [Intel-gfx] [PATCH 00/47] GuC submission support

On Tue, Oct 26, 2021 at 11:59:35AM +0300, Joonas Lahtinen wrote: > Quoting Matthew Brost (2021-10-25 18:15:09) > > On Mon, Oct 25, 2021 at 12:37:02PM +0300, Joonas Lahtinen wrote: > > > Quoting Matthew Brost (2021-10-22 19:42:19) > > > > On Fri, Oct 22, 2021 at 12:35:04PM +0300, Joonas Lahtinen wro

Re: [Intel-gfx] [PATCH 00/47] GuC submission support

On Tue, Oct 26, 2021 at 11:59:35AM +0300, Joonas Lahtinen wrote: > Quoting Matthew Brost (2021-10-25 18:15:09) > > On Mon, Oct 25, 2021 at 12:37:02PM +0300, Joonas Lahtinen wrote: > > > Quoting Matthew Brost (2021-10-22 19:42:19) > > > > On Fri, Oct 22, 2021 at 12:35:04PM +0300, Joonas Lahtinen wro

Re: [Intel-gfx] [PATCH v2 13/17] drm/i915/dg2: Tile 4 plane format support

On 2021-10-21 at 17:27:08 +0300, Lisovskiy, Stanislav wrote: > On Thu, Oct 21, 2021 at 07:56:23PM +0530, Ramalingam C wrote: > > From: Stanislav Lisovskiy > > > > TileF(Tile4 in bspec) format is 4K tile organized into > > 64B subtiles with same basic shape as for legacy TileY > > which will be su

[Intel-gfx] ✓ Fi.CI.IGT: success for Remove check for ComboPHY I/O voltage for DP source rate (rev2)

== Series Details == Series: Remove check for ComboPHY I/O voltage for DP source rate (rev2) URL : https://patchwork.freedesktop.org/series/96293/ State : success == Summary == CI Bug Log - changes from CI_DRM_10789_full -> Patchwork_21449_full =

[Intel-gfx] [PATCH 1/3] drm/i915/fb: Don't report MC CCS plane capability on GEN<12

Remove the MC CCS plane capability on GEN<12, since it's not present there. This didn't cause a problem, since the display version check filtered out the MC CCS modifiers before GEN12. Cc: Juha-Pekka Heikkila Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/display/skl_universal_plane.c | 3 ++

[Intel-gfx] [PATCH 3/3] drm/i915/fb: Fold modifier CCS type/tiling attribute to plane caps

By using the modifier plane capability flags to encode the modifiers' CCS type and tiling attributes, it becomes simpler to the check for any of these capabilities when providing the list of supported modifiers. This also allows distinguishing modifiers on future platforms where platforms with the

[Intel-gfx] [PATCH 0/3] drm/i915/fb: Simplify modifier handling more

To simplify the handling of modifiers on DG2 and future platforms it makes sense to fold the modifier tiling and CCS type attributes to the plane capabilities mask. This patchset does that, also including fixing two minor issues. Cc: Juha-Pekka Heikkila Imre Deak (3): drm/i915/fb: Don't report

[Intel-gfx] [PATCH 2/3] drm/i915/fb: Don't store bitmasks in the intel_plane_caps enum

Variables of enum types can contain only the values listed at the enums definition, so don't store bitmasks in intel_plane_caps enum variables. Cc: Juha-Pekka Heikkila Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/display/intel_fb.c| 4 ++-- drivers/gpu/drm/i915/display/intel_fb

[Intel-gfx] intel_dp_sync_state+oxeo/oxfo boot failures after 5.15-rc3

I have a MacBookPro6,2 that I'm running the mainline 5.15-rc3 ubuntu kernel on successfully. I installed the 5.15-rc5 kernel (the 5.15-rc4 didn't build) and the system wouldn't boot, erroring out with the error below. I also see the

Re: [Intel-gfx] intel_dp_sync_state+oxeo/oxfo boot failures after 5.15-rc3

On Tue, 26 Oct 2021, Satadru Pramanik wrote: > I have a MacBookPro6,2 that I'm running the mainline 5.15-rc3 ubuntu kernel > on successfully. I installed the 5.15-rc5 kernel > (the > 5.15-rc4 didn't build) and the system wouldn't bo

Re: [Intel-gfx] intel_dp_sync_state+oxeo/oxfo boot failures after 5.15-rc3

That appears to do the trick. Ubuntu's 5.15.0-051500rc6drmtip20211026-generic kernel boots successfully. Thanks, Satadru On Tue, Oct 26, 2021 at 12:41 PM Jani Nikula wrote: > On Tue, 26 Oct 2021, Satadru Pramanik wrote: > > I have a MacBookPro6,2 that I'm running the mainline 5.15-rc3 ubuntu

Re: [Intel-gfx] [PATCH v2] drm/i915/dp: fix integer overflow in 128b/132b data rate calculation

On Tue, 26 Oct 2021, Ville Syrjälä wrote: > On Tue, Oct 26, 2021 at 12:34:07PM +0300, Jani Nikula wrote: >> The intermediate value 100 * 10 * 9671 overflows 32 bits, so force >> promotion to a bigger type. >> >> >From the logs: >> >> [drm:intel_dp_compute_config [i915]] DP link rate required

[Intel-gfx] ✗ Fi.CI.IGT: failure for i915/selftest: Disable irq to calc eng timestamp

== Series Details == Series: i915/selftest: Disable irq to calc eng timestamp URL : https://patchwork.freedesktop.org/series/96301/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10789_full -> Patchwork_21450_full Summary --

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/display: Wait PSR2 get out of deep sleep to update pipe (rev3)

On Wed, 2021-10-06 at 06:49 +, Patchwork wrote: > Patch Details > Series: drm/i915/display: Wait PSR2 get out of deep sleep to update > pipe (rev3) > URL: https://patchwork.freedesktop.org/series/95309/ > State:failure > Details: > https://intel-gfx-ci.01.org/tree/drm-tip

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Initial introduction of vma resources

Hi "Thomas, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on drm-tip/drm-tip] [cannot apply to drm-intel/for-linux-next drm-exynos/exynos-drm-next tegra-drm/drm/tegra/for-next airlied/drm-next v5.15-rc7 next-20211026] [If your patch is applied to the wron

Re: [Intel-gfx] [PATCH 3/3] drm/i915/fb: Fold modifier CCS type/tiling attribute to plane caps

On Tue, 26 Oct 2021, Imre Deak wrote: > By using the modifier plane capability flags to encode the modifiers' > CCS type and tiling attributes, it becomes simpler to the check for > any of these capabilities when providing the list of supported > modifiers. > > This also allows distinguishing modi

Re: [Intel-gfx] intel_dp_sync_state+oxeo/oxfo boot failures after 5.15-rc3

On Tue, 26 Oct 2021, Satadru Pramanik wrote: > That appears to do the trick. Thanks for confirming. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [RFC v2 00/22] Add Support for Plane Color Lut and CSC features

On 2021-10-12 17:01, Shankar, Uma wrote: > > >> -Original Message- >> From: Pekka Paalanen >> Sent: Tuesday, October 12, 2021 5:25 PM >> To: Shankar, Uma >> Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; >> harry.wentl...@amd.com; ville.syrj...@linux.intel.com;

Re: [Intel-gfx] [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline

Thanks, Uma, for the updated patches. I'm finally finding time to go through them. On 2021-10-15 03:42, Pekka Paalanen wrote: > On Thu, 14 Oct 2021 19:44:25 + > "Shankar, Uma" wrote: > >>> -Original Message- >>> From: Pekka Paalanen >>> Sent: Wednesday, October 13, 2021 2:01 PM >>>

[Intel-gfx] [PATCH v3 1/3] drm: Rename lut check functions to lut channel checks

From: Mark Yacoub [Why] This function and enum do not do generic checking on the luts but they test color channels in the LUTs. Keeping the name explicit as more generic LUT checks will follow. Tested on Eldrid ChromeOS (TGL). Signed-off-by: Mark Yacoub --- drivers/gpu/drm/drm_color_mgmt.c

[Intel-gfx] [PATCH v3 2/3] drm: Add Gamma and Degamma LUT sizes props to drm_crtc to validate.

From: Mark Yacoub [Why] 1. drm_atomic_helper_check doesn't check for the LUT sizes of either Gamma or Degamma props in the new CRTC state, allowing any invalid size to be passed on. 2. Each driver has its own LUT size, which could also be different for legacy users. [How] 1. Create |degamma_lut_

Re: [Intel-gfx] [PATCH 1/2] drm: Add Gamma and Degamma LUT sizes props to drm_crtc to validate.

On Tue, Oct 26, 2021 at 8:02 AM Paul Menzel wrote: > > Dear Mark, > > > Thank you for your patch. > > On 13.10.21 20:12, Mark Yacoub wrote: > > From: Mark Yacoub > > > > [Why] > > 1. drm_atomic_helper_check doesn't check for the LUT sizes of either Gamma > > or Degamma props in the new CRTC state

Re: [Intel-gfx] [PATCH 1/2] drm: Add Gamma and Degamma LUT sizes props to drm_crtc to validate.

On Mon, Oct 25, 2021 at 9:26 PM Sean Paul wrote: > > On Wed, Oct 13, 2021 at 02:12:20PM -0400, Mark Yacoub wrote: > > From: Mark Yacoub > > > > [Why] > > 1. drm_atomic_helper_check doesn't check for the LUT sizes of either Gamma > > or Degamma props in the new CRTC state, allowing any invalid siz

Re: [Intel-gfx] [PATCH 1/2] drm: Add Gamma and Degamma LUT sizes props to drm_crtc to validate.

new patch: https://patchwork.freedesktop.org/series/96314/ On Tue, Oct 26, 2021 at 3:24 PM Mark Yacoub wrote: > > On Tue, Oct 26, 2021 at 8:02 AM Paul Menzel wrote: > > > > Dear Mark, > > > > > > Thank you for your patch. > > > > On 13.10.21 20:12, Mark Yacoub wrote: > > > From: Mark Yacoub > >

Re: [Intel-gfx] [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline

On 2021-10-14 15:44, Shankar, Uma wrote: > > >> -Original Message- >> From: Pekka Paalanen >> Sent: Wednesday, October 13, 2021 2:01 PM >> To: Shankar, Uma >> Cc: harry.wentl...@amd.com; ville.syrj...@linux.intel.com; intel- >> g...@lists.freedesktop.org; dri-de...@lists.freedesktop

Re: [Intel-gfx] [PATCH v2 2/9] Revert "drm/i915/display: Disable audio, DRRS and PSR before planes"

On Fri, 2021-10-22 at 13:32 +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > Disabling planes in the middle of the modeset seuqnece does not make > sense since userspace can anyway disable planes before the modeset > even starts. So when the modeset seuqence starts the set of enabled > plane

Re: [Intel-gfx] [PATCH v2 3/9] drm/i915: Disable all planes before modesetting any pipes

On Fri, 2021-10-22 at 13:32 +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > Let's disable planes on all pipes affected by the modeset before > we start doing the actual modeset. This means we have less > random planes enabled during the modeset, and it also mirrors > what we already do when

Re: [Intel-gfx] [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline

On 2021-10-12 16:58, Shankar, Uma wrote: > > >> -Original Message- >> From: Pekka Paalanen >> Sent: Tuesday, October 12, 2021 4:01 PM >> To: Shankar, Uma >> Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; >> harry.wentl...@amd.com; ville.syrj...@linux.intel.com

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Allow engine reset failure to do a GT reset in hangcheck selftest

On 10/11/2021 16:47, Matthew Brost wrote: The hangcheck selftest blocks per engine resets by setting magic bits in the reset flags. This is incorrect for GuC submission because if the GuC fails to reset an engine we would like to do a full GT reset. Do no set these magic bits when using GuC submi

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Allow engine reset failure to do a GT reset in hangcheck selftest

On 10/21/2021 23:23, Thomas Hellström wrote: On 10/21/21 22:37, Matthew Brost wrote: On Thu, Oct 21, 2021 at 08:15:49AM +0200, Thomas Hellström wrote: Hi, Matthew, On Mon, 2021-10-11 at 16:47 -0700, Matthew Brost wrote: The hangcheck selftest blocks per engine resets by setting magic bits in

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/fb: Simplify modifier handling more

== Series Details == Series: drm/i915/fb: Simplify modifier handling more URL : https://patchwork.freedesktop.org/series/96308/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10792 -> Patchwork_21451 Summary --- **FAI

Re: [Intel-gfx] [PATCH] drm/i915/execlists: Weak parallel submission support for execlists

On 10/20/2021 14:47, Matthew Brost wrote: A weak implementation of parallel submission (multi-bb execbuf IOCTL) for execlists. Doing as little as possible to support this interface for execlists - basically just passing submit fences between each request generated and virtual engines are not allo

Re: [Intel-gfx] [PATCH 0/4] drm/i915: (near)atomic gamma LUT updates via vblank workers

Hey! I'll try to review this tomorrow or the day after if you're still interested in me doing so :) On Thu, 2021-10-21 at 01:33 +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > Finally got around to refreshing my vblank worker gamma LUT series. > Since I started this (ahem, some years ago)

[Intel-gfx] [PATCH v4 0/5] drm/dp, drm/i915: Finish basic PWM support for VESA backlight helpers

When I originally moved all of the VESA backlight code in i915 into DRM helpers, one of the things I didn't have the hardware or time for testing was machines that used a combination of PWM and DPCD in order to control their backlights. This has since then caused some breakages and resulted in us d

[Intel-gfx] [PATCH v4 1/5] drm/i915: Add support for panels with VESA backlights with PWM enable/disable

This simply adds proper support for panel backlights that can be controlled via VESA's backlight control protocol, but which also require that we enable and disable the backlight via PWM instead of via the DPCD interface. We also enable this by default, in order to fix some people's backlights that

[Intel-gfx] [PATCH v4 3/5] drm/dp: Disable unsupported features in DP_EDP_BACKLIGHT_MODE_SET_REGISTER

As it turns out, apparently some machines will actually leave additional backlight functionality like dynamic backlight control on before the OS loads. Currently we don't take care to disable unsupported features when writing back the backlight mode, which can lead to some rather strange looking be

[Intel-gfx] [PATCH v4 2/5] drm/nouveau/kms/nv50-: Explicitly check DPCD backlights for aux enable/brightness

Since we don't support hybrid AUX/PWM backlights in nouveau right now, let's add some explicit checks so that we don't break nouveau once we enable support for these backlights in other drivers. Signed-off-by: Lyude Paul --- drivers/gpu/drm/nouveau/nouveau_backlight.c | 5 - 1 file changed,

[Intel-gfx] [PATCH v4 4/5] drm/dp, drm/i915: Add support for VESA backlights using PWM for brightness control

Now that we've added support to i915 for controlling panel backlights that need PWM to be enabled/disabled, let's finalize this and add support for controlling brightness levels via PWM as well. This should hopefully put us towards the path of supporting _ALL_ backlights via VESA's DPCD interface w

[Intel-gfx] [PATCH v4 5/5] drm/i915: Clarify probing order in intel_dp_aux_init_backlight_funcs()

Hooray! We've managed to hit enough bugs upstream that I've been able to come up with a pretty solid explanation for how backlight controls are actually supposed to be detected and used these days. As well, having the rest of the PWM bits in VESA's backlight interface implemented seems to have fixe

Re: [Intel-gfx] [PATCH v2 06/13] drm/exynos: replace drm_detect_hdmi_monitor() with drm_display_info.is_hdmi

Hi, 21. 10. 17. 오전 3:42에 Claudio Suarez 이(가) 쓴 글: > Once EDID is parsed, the monitor HDMI support information is available > through drm_display_info.is_hdmi. Retriving the same information with > drm_detect_hdmi_monitor() is less efficient. Change to > drm_display_info.is_hdmi > > Signed-off-by:

[Intel-gfx] [PATCH] drm/i915/adlp: Extend PSR2 support in transcoder B

PSR2 is supported in transcoder A and B on Alderlake-P. BSpec: 49185 Cc: Mika Kahola Cc: Jouni Hogander Signed-off-by: José Roberto de Souza --- drivers/gpu/drm/i915/display/intel_psr.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_ps

  1   2   >