[Intel-gfx] ✗ Fi.CI.BUILD: failure for DRM kmap() fixes and kmap_local_page() conversions (rev3)

== Series Details == Series: DRM kmap() fixes and kmap_local_page() conversions (rev3) URL : https://patchwork.freedesktop.org/series/97889/ State : failure == Summary == Applying: drm/i915: Replace kmap() with kmap_local_page() Using index info to reconstruct a base tree... M drivers/gp

[Intel-gfx] [PATCH V2] drm/i915: Replace kmap() with kmap_local_page()

From: Ira Weiny kmap() is being deprecated and these usages are all local to the thread so there is no reason kmap_local_page() can't be used. Replace kmap() calls with kmap_local_page(). Signed-off-by: Ira Weiny --- NOTE: I'm sending as a follow on to the V1 patch. Please let me know if you

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/guc: Check for wedged before doing stuff (rev2)

== Series Details == Series: drm/i915/guc: Check for wedged before doing stuff (rev2) URL : https://patchwork.freedesktop.org/series/98099/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11025_full -> Patchwork_21889_full Su

[Intel-gfx] ✓ Fi.CI.IGT: success for Update to GuC version 69.0.3 (rev2)

== Series Details == Series: Update to GuC version 69.0.3 (rev2) URL : https://patchwork.freedesktop.org/series/98249/ State : success == Summary == CI Bug Log - changes from CI_DRM_11025_full -> Patchwork_21888_full Summary --- **SU

[Intel-gfx] linux-next: manual merge of the drm tree with the drm-misc-fixes tree

Hi all, Today's linux-next merge of the drm tree got a conflict in: drivers/gpu/drm/nouveau/nouveau_fence.c between commit: 67f74302f45d ("drm/nouveau: wait for the exclusive fence after the shared ones v2") from the drm-misc-fixes tree and commit: 40298cb45071 ("drm/nouveau: use the n

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Asynchronous vma unbinding part1

== Series Details == Series: drm/i915: Asynchronous vma unbinding part1 URL : https://patchwork.freedesktop.org/series/98278/ State : success == Summary == CI Bug Log - changes from CI_DRM_11025_full -> Patchwork_21887_full Summary ---

[Intel-gfx] ✗ Fi.CI.IGT: failure for More preparation for multi gt patches (rev2)

== Series Details == Series: More preparation for multi gt patches (rev2) URL : https://patchwork.freedesktop.org/series/98215/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11025_full -> Patchwork_21886_full Summary --

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

On 12/20/2021 10:13, Zbigniew Kempczyński wrote: 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

Re: [Intel-gfx] [RFC 2/7] drm/i915/guc: Update GuC ADS size for error capture lists

Hi Michal - wrt to this comment: +struct intel_guc; > > > + > > > +struct __guc_mmio_reg_descr { > > > + i915_reg_t reg; > > > + u32 flags; > > > + u32 mask; > > > + char *regname; > > > > const char* ? > > > > but maybe instead of adding reg name to the GuC specific struct we > > should add gen

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 04/11] tests/i915/i915_hangman: Explicitly test per engine reset vs full GPU reset

On 12/21/2021 03:28, Dandamudi, Priyanka wrote: Does this test series cover to prove that it can survive killing one without killing all the others except RCS+CCS combination(killing one affects other and shows with the help of reset stats)? That is part of the purpose of i915_hangman - to test

[Intel-gfx] adding CRTC not allowed without modesets

FYI. I recently added a thunderbolt hub and it's basically working ok but I my log gets spammed with logs like this: adding CRTC not allowed without modesets: requested 0x2, affected 0xf Looking at the list it seems this is a known issue and there's work afoot in this area but I get the impressio

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Check for wedged before doing stuff (rev2)

== Series Details == Series: drm/i915/guc: Check for wedged before doing stuff (rev2) URL : https://patchwork.freedesktop.org/series/98099/ State : success == Summary == CI Bug Log - changes from CI_DRM_11025 -> Patchwork_21889 Summary

[Intel-gfx] ✓ Fi.CI.BAT: success for Update to GuC version 69.0.3 (rev2)

== Series Details == Series: Update to GuC version 69.0.3 (rev2) URL : https://patchwork.freedesktop.org/series/98249/ State : success == Summary == CI Bug Log - changes from CI_DRM_11025 -> Patchwork_21888 Summary --- **SUCCESS**

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Update to GuC version 69.0.3 (rev2)

== Series Details == Series: Update to GuC version 69.0.3 (rev2) URL : https://patchwork.freedesktop.org/series/98249/ 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 Update to GuC version 69.0.3 (rev2)

== Series Details == Series: Update to GuC version 69.0.3 (rev2) URL : https://patchwork.freedesktop.org/series/98249/ State : warning == Summary == $ dim checkpatch origin/drm-tip d990ee618ad6 drm/i915/guc: Temporarily bump the GuC load timeout 0caa66133472 drm/i915/guc: Update to GuC version

Re: [Intel-gfx] [RFC 2/7] drm/i915/guc: Update GuC ADS size for error capture lists

Michal, wrt this one: +/ FIXME: Populate tables for other devices in subsequent patch / > > > + > > > +static struct __guc_mmio_reg_descr_group * > > > +guc_capture_get_device_reglist(struct drm_i915_private *dev_priv) > > > > in new code we are using "i915" instead of "d

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Asynchronous vma unbinding part1

== Series Details == Series: drm/i915: Asynchronous vma unbinding part1 URL : https://patchwork.freedesktop.org/series/98278/ State : success == Summary == CI Bug Log - changes from CI_DRM_11025 -> Patchwork_21887 Summary --- **SUCCE

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm: Always include the debugfs dentry in drm_crtc

== Series Details == Series: series starting with [1/2] drm: Always include the debugfs dentry in drm_crtc URL : https://patchwork.freedesktop.org/series/98276/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11024_full -> Patchwork_21885_full ==

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Asynchronous vma unbinding part1

== Series Details == Series: drm/i915: Asynchronous vma unbinding part1 URL : https://patchwork.freedesktop.org/series/98278/ State : warning == Summary == $ dim checkpatch origin/drm-tip 135b8658be47 drm/i915: Avoid using the i915_fence_array when collecting dependencies 1f9c56b98070 drm/i91

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Asynchronous vma unbinding part1

== Series Details == Series: drm/i915: Asynchronous vma unbinding part1 URL : https://patchwork.freedesktop.org/series/98278/ 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.BAT: success for More preparation for multi gt patches (rev2)

== Series Details == Series: More preparation for multi gt patches (rev2) URL : https://patchwork.freedesktop.org/series/98215/ State : success == Summary == CI Bug Log - changes from CI_DRM_11025 -> Patchwork_21886 Summary --- **SUC

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

On 12/21/2021 05:37, Tvrtko Ursulin wrote: On 20/12/2021 18:34, John Harrison wrote: 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 U

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for More preparation for multi gt patches (rev2)

== Series Details == Series: More preparation for multi gt patches (rev2) URL : https://patchwork.freedesktop.org/series/98215/ 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 More preparation for multi gt patches (rev2)

== Series Details == Series: More preparation for multi gt patches (rev2) URL : https://patchwork.freedesktop.org/series/98215/ State : warning == Summary == $ dim checkpatch origin/drm-tip 5769c7bdc47d drm/i915/gt: Use to_gt() helper for GGTT accesses 8678fc77a7bf drm/i915: Use to_gt() helper

[Intel-gfx] [PATCH v2] drm/i915/guc: Check for wedged before doing stuff

From: John Harrison A fault injection probe test hit a BUG_ON in a GuC error path. It showed that the GuC code could potentially attempt to do many things when the device is actually wedged. So, add a check in to prevent that. v2: Use intel_gt_is_wedged instead of testing bits directly in the Gu

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

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

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 1/3] drm/i915/guc: Temporarily bump the GuC load timeout

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] [PATCH 0/3] Update to GuC version 69.0.3

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] ✓ Fi.CI.BAT: success for series starting with [1/2] drm: Always include the debugfs dentry in drm_crtc

== Series Details == Series: series starting with [1/2] drm: Always include the debugfs dentry in drm_crtc URL : https://patchwork.freedesktop.org/series/98276/ State : success == Summary == CI Bug Log - changes from CI_DRM_11024 -> Patchwork_21885

[Intel-gfx] [PATCH v4 4/4] drm/i915: Require the vm mutex for i915_vma_bind()

Protect updates of struct i915_vma flags and async binding / unbinding with the vm::mutex. This means that i915_vma_bind() needs to assert vm::mutex held. In order to make that possible drop the caching of kmap_atomic() maps around i915_vma_bind(). An alternative would be to use kmap_local() but s

[Intel-gfx] [PATCH v4 2/4] drm/i915: remove questionable fence optimization during copy

From: Christian König First of all as discussed multiple times now kernel copies *must* always wait for all fences in a BO before actually doing the copy. This is mandatory. Additional to that drop the handling when there can't be a shared slot allocated on the source BO and just properly return

[Intel-gfx] [PATCH v4 3/4] drm/i915: Break out the i915_deps utility

Since it's starting to be used outside the i915 TTM move code, move it to a separate set of files. v2: - Update the documentation. v4: - Rebase. Signed-off-by: Thomas Hellström Reviewed-by: Matthew Auld --- drivers/gpu/drm/i915/Makefile| 1 + drivers/gpu/drm/i915/gem/i915_gem

[Intel-gfx] [PATCH v4 1/4] drm/i915: Avoid using the i915_fence_array when collecting dependencies

Since the gt migration code was using only a single fence for dependencies, these were collected in a dma_fence_array. However, it turns out that it's illegal to use some dma_fences in a dma_fence_array, in particular other dma_fence_arrays and dma_fence_chains, and this causes trouble for us movin

[Intel-gfx] [PATCH v4 0/4] drm/i915: Asynchronous vma unbinding part1

This is the first three already reviewed patches from the patch series titled "Asynchronous vma unbinding", with an additional cleanup patch from Christian, which would otherwise conflict heavily with this series. Christian König (1): drm/i915: remove questionable fence optimization during copy

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm: Always include the debugfs dentry in drm_crtc

== Series Details == Series: series starting with [1/2] drm: Always include the debugfs dentry in drm_crtc URL : https://patchwork.freedesktop.org/series/98276/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked

[Intel-gfx] [PATCH v10 1/6] drm/i915/gt: Use to_gt() helper for GGTT accesses

From: Michał Winiarski GGTT is currently available both through i915->ggtt and gt->ggtt, and we eventually want to get rid of the i915->ggtt one. Use to_gt() for all i915->ggtt accesses to help with the future refactoring. During the probe of i915 the early intiialization of the gt (intel_gt_ini

Re: [Intel-gfx] [PATCH v9 2/6] drm/i915: Use to_gt() helper for GGTT accesses

Hi Matt, > > diff --git a/drivers/gpu/drm/i915/i915_perf.c > > b/drivers/gpu/drm/i915/i915_perf.c > > index 170bba913c30..128315aec517 100644 > > --- a/drivers/gpu/drm/i915/i915_perf.c > > +++ b/drivers/gpu/drm/i915/i915_perf.c > > @@ -1630,7 +1630,7 @@ static int alloc_noa_wait(struct i915_perf_

[Intel-gfx] [PATCH 2/2] drm/dbi: Use a static inline stub for mipi_dbi_debugfs_init()

From: Ville Syrjälä Replace the slightly odd "#define NULL" thing with a standard static inline stub. Cc: Noralf Trønnes Cc: Sam Ravnborg Signed-off-by: Ville Syrjälä --- include/drm/drm_mipi_dbi.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/drm/drm_mipi_dbi.

[Intel-gfx] [PATCH 1/2] drm: Always include the debugfs dentry in drm_crtc

From: Ville Syrjälä Remove the counterproductive CONFIG_DEBUG_FS ifdef and just include the debugfs dentry in drm_crtc always. This way we don't need annoying ifdefs in the actual code with DEBUGFS=n. Also we don't have these ifdefs around any of the other debugfs dentries either so can't see why

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

On 12/21/2021 10:11 AM, Ewins, Jon wrote: On 12/20/2021 3:52 PM, Sundaresan, Sujaritha wrote: 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,

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

On 12/20/2021 3:52 PM, Sundaresan, Sujaritha wrote: 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 th

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

On Tue, 2021-12-21 at 07:09 -0800, Daniele Ceraolo Spurio wrote: > > > On 12/20/2021 12:40 PM, Juston Li wrote: > > Similar to commit b8d8436840ca ("drm/i915/gt: Hold RPM wakelock > > during > > PXP suspend") but to fix the same warning for unbind during > > shutdown: > > > > [ cut h

Re: [Intel-gfx] [PATCH v3 6/7] drm/i915: Use vma resources for async unbinding

On 21/12/2021 16:07, Thomas Hellström wrote: On Tue, 2021-12-21 at 14:02 +, Matthew Auld wrote: On 17/12/2021 14:52, Thomas Hellström wrote: Implement async (non-blocking) unbinding by not syncing the vma before calling unbind on the vma_resource. Add the resulting unbind fence to the objec

Re: [Intel-gfx] [PATCH v9 2/6] drm/i915: Use to_gt() helper for GGTT accesses

On Sun, Dec 19, 2021 at 11:24:56PM +0200, Andi Shyti wrote: > From: Michał Winiarski > > GGTT is currently available both through i915->ggtt and gt->ggtt, and we > eventually want to get rid of the i915->ggtt one. > Use to_gt() for all i915->ggtt accesses to help with the future > refactoring. >

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/bios: fix slab-out-of-bounds access

== Series Details == Series: drm/i915/bios: fix slab-out-of-bounds access URL : https://patchwork.freedesktop.org/series/98263/ State : success == Summary == CI Bug Log - changes from CI_DRM_11023_full -> Patchwork_21883_full Summary --

Re: [Intel-gfx] [PATCH v9 1/6] drm/i915/gt: Use to_gt() helper for GGTT accesses

On Sun, Dec 19, 2021 at 11:24:55PM +0200, Andi Shyti wrote: > From: Michał Winiarski > > GGTT is currently available both through i915->ggtt and gt->ggtt, and we > eventually want to get rid of the i915->ggtt one. > Use to_gt() for all i915->ggtt accesses to help with the future > refactoring. >

Re: [Intel-gfx] [PATCH v3 6/7] drm/i915: Use vma resources for async unbinding

On Tue, 2021-12-21 at 14:02 +, Matthew Auld wrote: > On 17/12/2021 14:52, Thomas Hellström wrote: > > Implement async (non-blocking) unbinding by not syncing the vma > > before > > calling unbind on the vma_resource. > > Add the resulting unbind fence to the object's dma_resv from where > > it

Re: [Intel-gfx] [PATCH v3 4/4] drm/i915/fbc: Register per-crtc debugfs files

On Sat, Dec 18, 2021 at 06:00:47PM -0700, Nathan Chancellor wrote: > Hi Ville, > > On Mon, Dec 13, 2021 at 05:14:35PM +0200, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > Expose FBC debugfs files for each crtc. These may or may not point > > to the same FBC instance depending on the platf

Re: [Intel-gfx] [PATCH] drm/i915: remove questionable fence optimization during copy

Hi, Christian, On Tue, 2021-12-21 at 15:07 +0100, Christian König wrote: > First of all as discussed multiple times now kernel copies *must* > always wait > for all fences in a BO before actually doing the copy. This is > mandatory. This patch looks ok to me.  Regarding the discussion I was just

[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/pxp: Hold RPM wakelock during PXP unbind (rev2)

== Series Details == Series: drm/i915/pxp: Hold RPM wakelock during PXP unbind (rev2) URL : https://patchwork.freedesktop.org/series/98245/ State : failure == Summary == Applying: drm/i915/pxp: Hold RPM wakelock during PXP unbind error: sha1 information is lacking or useless (drivers/gpu/drm/

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

On 12/20/2021 12:40 PM, Juston Li wrote: 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 dr

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/bios: fix slab-out-of-bounds access

== Series Details == Series: drm/i915/bios: fix slab-out-of-bounds access URL : https://patchwork.freedesktop.org/series/98263/ State : success == Summary == CI Bug Log - changes from CI_DRM_11023 -> Patchwork_21883 Summary --- **SUC

Re: [Intel-gfx] [PATCH v3 6/7] drm/i915: Use vma resources for async unbinding

On 17/12/2021 14:52, Thomas Hellström wrote: Implement async (non-blocking) unbinding by not syncing the vma before calling unbind on the vma_resource. Add the resulting unbind fence to the object's dma_resv from where it is picked up by the ttm migration code. Ideally these unbind fences should

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

On 20/12/2021 18:34, John Harrison wrote: 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

Re: [Intel-gfx] [PATCH] drm/i915/bios: fix slab-out-of-bounds access

On 12/21/21 14:08, Jani Nikula wrote: If VBT size is not a multiple of 4, the last 4-byte store will be out of bounds of the allocated buffer. Spotted with KASAN. Round up the allocation size. Reported-by: Thomas Hellström Fixes: a36e7dc0af1c ("drm/i915/dg1: Read OPROM via SPI controller") Cc

[Intel-gfx] [PATCH] drm/i915/bios: fix slab-out-of-bounds access

If VBT size is not a multiple of 4, the last 4-byte store will be out of bounds of the allocated buffer. Spotted with KASAN. Round up the allocation size. Reported-by: Thomas Hellström Fixes: a36e7dc0af1c ("drm/i915/dg1: Read OPROM via SPI controller") Cc: Clint Taylor Cc: Lucas De Marchi Signe

Re: [Intel-gfx] [PATCH v3 3/7] drm/i915: Require the vm mutex for i915_vma_bind()

On 17/12/2021 14:52, Thomas Hellström wrote: Protect updates of struct i915_vma flags and async binding / unbinding with the vm::mutex. This means that i915_vma_bind() needs to assert vm::mutex held. In order to make that possible drop the caching of kmap_atomic() maps around i915_vma_bind(). An

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 04/11] tests/i915/i915_hangman: Explicitly test per engine reset vs full GPU reset

Does this test series cover to prove that it can survive killing one without killing all the others except RCS+CCS combination(killing one affects other and shows with the help of reset stats)? -Original Message- From: igt-dev On Behalf Of john.c.harri...@intel.com Sent: 14 December 2

Re: [Intel-gfx] [PATCH v3 2/7] drm/i915: Break out the i915_deps utility

On 17/12/2021 14:52, Thomas Hellström wrote: Since it's starting to be used outside the i915 TTM move code, move it to a separate set of files. v2: - Update the documentation. Signed-off-by: Thomas Hellström Reviewed-by: Matthew Auld

Re: [Intel-gfx] [PATCH v3 1/7] drm/i915: Avoid using the i915_fence_array when collecting dependencies

On 17/12/2021 14:52, Thomas Hellström wrote: Since the gt migration code was using only a single fence for dependencies, these were collected in a dma_fence_array. However, it turns out that it's illegal to use some dma_fences in a dma_fence_array, in particular other dma_fence_arrays and dma_fen

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

Hi, On 12/20/21 20:58, Patchwork wrote: > *Patch 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

Re: [Intel-gfx] [PATCH] drm/i915/display: Move cdclk checks to atomic check

On Fri, 17 Dec 2021, Anusha Srivatsa wrote: > Checking cdclk conditions during atomic check and preparing > for commit phase so we can have atomic commit as simple > as possible. Add the specific steps to be taken during > cdclk changes, prepare for squashing, crawling and modeset > scenarios. > R