From: Ville Syrjälä
Reinstate commit 88b065943cb5 ("drm/i915/dsi: Do display on
sequence later on icl+"), for the most part. Turns out some
machines (eg. Chuwi Minibook X) really do need that updated order.
It is also the order the Windows driver uses.
However we can't just undo the revert since
On Fri, Mar 01, 2024 at 04:35:53PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> In preparation for doing a more sensible pipe vs. transcoder
> handling for bigjoiner let's rename the crtc/crtc_state in the
> top level crtc_enable/disable and the DDI encoder hooks to
> include "master" in
On Fri, Mar 01, 2024 at 04:35:55PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Extract the "not-MST" stuff from intel_ddi_post_disable() so that
> the whole thing isn't so cluttered.
>
> The bigjoiner slave handling was outside of the !MST check,
> but it really should have been inside
From: Ville Syrjälä
Make the crtc disable more atomic (in terms of plane disable).
And also also track which pipes need disabling in the same way
as skl_commit_modeset_enables(), which should make the whole
thing bit less messy as we don't have to keep on checking the
same conditions multiple ti
From: Ville Syrjälä
Copy the pipe bitmask based approach skl_commit_modeset_enables()
into intel_commit_modeset_disables(). This avoids doing so many
duplicated checks in all the loops, and also let's us WARN at the
end if we screwed up somewhere and forgot to disable some pipe.
Signed-off-by: V
From: Ville Syrjälä
Follow in the footsteps of commit c610e841f19d ("drm/i915:
Do plane/etc. updates more atomically across pipes") and
do the plane disables back to back for all pipes also when
we are disabling pipes.
This should provide for a potentially more atomic user
experience, which migh
From: Ville Syrjälä
Stop passing in so much redundant stuff to
intel_old_crtc_state_disables(). Top level atomic state + crtc
is all we need.
And while at it constify the states to make it clear they should
not be mutated.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_di
On Fri, Mar 01, 2024 at 04:35:57PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Copy the pipe bitmask based approach skl_commit_modeset_enables()
> into intel_commit_modeset_disables(). This avoids doing so many
> duplicated checks in all the loops, and also let's us WARN at the
> end if
On Tue, Mar 05, 2024 at 10:41:49AM +0200, Lisovskiy, Stanislav wrote:
> On Fri, Mar 01, 2024 at 04:35:53PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > In preparation for doing a more sensible pipe vs. transcoder
> > handling for bigjoiner let's rename the crtc/crtc_state in the
>
On Wed, Feb 28, 2024 at 02:22:40PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> I will lose access to my @.*intel.com e-mail addresses soon so let me
> adjust the maintainers entry and update the mailmap too.
>
> While at it consolidate a few other of my old emails to point to the
> m
On Fri, Mar 01, 2024 at 04:35:58PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Follow in the footsteps of commit c610e841f19d ("drm/i915:
> Do plane/etc. updates more atomically across pipes") and
> do the plane disables back to back for all pipes also when
> we are disabling pipes.
>
On Fri, Mar 01, 2024 at 04:35:59PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Stop passing in so much redundant stuff to
> intel_old_crtc_state_disables(). Top level atomic state + crtc
> is all we need.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Stanislav Lisovskiy
> ---
> dr
Resend of [1] with an intent to merge after the CI results come in. This
is aiming for v6.10, so we'll have maximal time to find all the issues
my configs didn't catch.
I built this on x86-64 (both gcc and clang), arm and arm64, and
everything passed.
BR,
Jani.
[1] https://lore.kernel.org/all/co
At least the i915 and amd drivers enable a bunch more compiler warnings
than the kernel defaults.
Extend most of the W=1 warnings to the entire drm subsystem by
default. Use the copy-pasted warnings from scripts/Makefile.extrawarn
with s/KBUILD_CFLAGS/subdir-ccflags-y/ to make it easier to compare
Add kconfig to enable -Werror subsystem wide. This is useful for
development and CI to keep the subsystem warning free, while avoiding
issues outside of the subsystem that kernel wide CONFIG_WERROR=y might
hit.
v2: Don't depend on COMPILE_TEST
Reviewed-by: Hamza Mahfooz # v1
Signed-off-by: Jani
On Tue, Mar 05, 2024 at 10:50:01AM +0200, Ville Syrjälä wrote:
> On Tue, Mar 05, 2024 at 10:41:49AM +0200, Lisovskiy, Stanislav wrote:
> > On Fri, Mar 01, 2024 at 04:35:53PM +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > In preparation for doing a more sensible pipe vs. transco
On Thu, 15 Feb 2024, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Plumb the drm_printer to all the little helpers called
> by intel_crtc_state_dump() and use it there as well.
>
> The exceptions are the ELD and infoframe stuff as they
> call helpers outside of the drm and thus can't use
> drm_p
On Tue, Mar 05, 2024 at 11:08:56AM +0200, Lisovskiy, Stanislav wrote:
> On Tue, Mar 05, 2024 at 10:50:01AM +0200, Ville Syrjälä wrote:
> > On Tue, Mar 05, 2024 at 10:41:49AM +0200, Lisovskiy, Stanislav wrote:
> > > On Fri, Mar 01, 2024 at 04:35:53PM +0200, Ville Syrjala wrote:
> > > > From: Ville S
Jani Nikula writes:
Hello Jani,
> Add kconfig to enable -Werror subsystem wide. This is useful for
> development and CI to keep the subsystem warning free, while avoiding
> issues outside of the subsystem that kernel wide CONFIG_WERROR=y might
> hit.
>
> v2: Don't depend on COMPILE_TEST
>
> Revi
Quoting Andi Shyti (2024-03-01 01:28:56)
> For the upcoming changes we need a cleaner way to build the list
> of uabi engines.
>
> Suggested-by: Tvrtko Ursulin
> Signed-off-by: Andi Shyti
> ---
> drivers/gpu/drm/i915/gt/intel_engine_user.c | 29 -
> 1 file changed, 17 insert
Volteer devices in the collabora lab are categorized under the
asus-cx9400-volteer device type. The majority of these units
has an Intel Core i5-1130G7 CPU, while some of them have a
Intel Core i7-1160G7 CPU instead. So due to this difference,
new device type template is added for the Intel Core i5
Hi Joonas,
...
> > void intel_engines_driver_register(struct drm_i915_private *i915)
> > {
> > - u16 name_instance, other_instance = 0;
> > + u16 class_instance[I915_LAST_UABI_ENGINE_CLASS + 1] = { };
>
> Do you mean this to be size I915_LAST_UABI_ENGINE_CLASS + 2? Because ...
Yes
Hi,
Below is the pipeline with the job passing,
https://gitlab.freedesktop.org/vigneshraman/linux/-/pipelines/1119672
Regards,
Vignesh
On 05/03/24 15:46, Vignesh Raman wrote:
Volteer devices in the collabora lab are categorized under the
asus-cx9400-volteer device type. The majority of these u
To be able to handle list unlocking while traversing the LRU
list, we want the iterators not only to point to the next
position of the list traversal, but to insert themselves as
list nodes at that point to work around the fact that the
next node might otherwise disappear from the list while
the it
This patch-set is a prerequisite for a standalone TTM shrinker
and for exhaustive TTM eviction using sleeping dma_resv locks,
which is the motivation for it.
Currently when unlocking the TTM lru list lock, iteration needs
to be restarted from the beginning, rather from the next LRU list
node. This
Have iterators insert themselves into the list they are iterating
over using hitch list nodes. Since only the iterator owner
can remove these list nodes from the list, it's safe to unlock
the list and when continuing, use them as a starting point. Due to
the way LRU bumping works in TTM, newly adde
To address the problem with hitches moving when bulk move
sublists are lru-bumped, register the list cursors with the
ttm_lru_bulk_move structure when traversing its list, and
when lru-bumping the list, move the cursor hitch to the tail.
This also means it's mandatory for drivers to call
ttm_lru_bu
The -ENOSPC failure from ttm_bo_swapout() meant that the lru_lock
was dropped and simply restarting the iteration meant we'd likely
hit the same error again on the same resource. Now that we can
restart the iteration even if the lock was dropped, do that.
Cc: Christian König
Cc: Somalapuram Amara
Volteer devices in the collabora lab are categorized under the
asus-cx9400-volteer device type. The majority of these units
has an Intel Core i5-1130G7 CPU, while some of them have a
Intel Core i7-1160G7 CPU instead. So due to this difference,
new device type template is added for the Intel Core i5
As of now whenerver HDR is switched on we use the PWM to change the
backlight as opposed to AUX based backlight changes in terms of nits.
This patch writes to the appropriate DPCD registers to enable aux
based backlight using values in nits.
Signed-off-by: Suraj Kandpal
---
.../drm/i915/display/
This is a reminder that we are still looking for candidates for the
upcoming X.Org Board of Directors elections, and that membership
renewals are still open and will be needed to vote on those elections.
Please read below for more details.
Cheers,
Christopher Michael, on behalf of the X.Org
Hi Christian,
On 3/4/2024 10:09 PM, Christian König wrote:
Am 04.03.24 um 17:32 schrieb Arunpravin Paneer Selvam:
Add amdgpu driver as user for the drm buddy
defragmentation.
Signed-off-by: Arunpravin Paneer Selvam
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 17 +++--
On Tue, 05 Mar 2024, "Chauhan, Shekhar" wrote:
> On 2/26/2024 23:28, Jani Nikula wrote:
>> Add a function to return the expected child device size. Flip the if
>> ladder around and use the same versions as in documentation to make it
>> easier to verify. Return an error for unknown versions. No fu
On 3/5/2024 4:33 PM, Paneer Selvam, Arunpravin wrote:
Hi Christian,
On 3/4/2024 10:09 PM, Christian König wrote:
Am 04.03.24 um 17:32 schrieb Arunpravin Paneer Selvam:
Add amdgpu driver as user for the drm buddy
defragmentation.
Signed-off-by: Arunpravin Paneer Selvam
---
drivers/gpu/
On Tue, 5 Mar 2024 11:07:34 +0200, Jani Nikula wrote:
> Resend of [1] with an intent to merge after the CI results come in. This
> is aiming for v6.10, so we'll have maximal time to find all the issues
> my configs didn't catch.
>
> I built this on x86-64 (both gcc and clang), arm and arm64, and
>
This patch set is improving IO and fast wake lines calculation in PSR
code:
Use actual fast wake sync pulse count in calculation Implement getter
for IO buffer wake times and use that. Better presentation on how
these are calculated. Use calculation for display version < 12 as
well.
Also number
ALPM AUX-Wake fast wake sync pulse count is needed by PSR to calculate IO
wake and fast wake lines. Convert intel_dp_aux_fw_sync_len as non-static
to make it available for PSR code.
v2: use int instead of u8
Signed-off-by: Jouni Högander
---
drivers/gpu/drm/i915/display/intel_dp_aux.c | 2 +-
d
Current fast and IO wake lines calculation is assuming fast wake sync
length is 18 pulses. Let's improve this by checking actual length.
Add getter for IO buffer wake time and return 10 us there which was assumed
with static 42 us IO wake time. Upcoming patches will extent this for
different displ
Bspec mentions 50 us for IO wake time and 32 us for fast wake time. 32 us
is most probably wrong as it doesn't meet the specification as fast wake
time is calculated in Bspec like this:
10..16 us (precharge) + 8 us (preamble) + 4 us (phy_wake) + 20 us
(tfw_exit_latency)
Instead of using these con
IO buffer wake time used for IO wake calculation is dependent on port clock
on LunarLake and beyond. Take this into account in get_io_buffer_wake_time.
Bspec: 65450
Signed-off-by: Jouni Högander
---
drivers/gpu/drm/i915/display/intel_psr.c | 9 -
1 file changed, 8 insertions(+), 1 delet
Increasing number of fast wake sync pulses seem to fix problems with
certain PSR panels. This should be ok for other panels as well as the eDP
specification allows 10...16 precharge pulses and we are still within that
range.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9739
Signed-off
Am 05.03.24 um 12:14 schrieb Paneer Selvam, Arunpravin:
On 3/5/2024 4:33 PM, Paneer Selvam, Arunpravin wrote:
Hi Christian,
On 3/4/2024 10:09 PM, Christian König wrote:
Am 04.03.24 um 17:32 schrieb Arunpravin Paneer Selvam:
Add amdgpu driver as user for the drm buddy
defragmentation.
Signed-
On Thu, Feb 29, 2024 at 10:07:16AM +0530, Animesh Manna wrote:
> Move psr_init_dpcd() from init-connector to connector-detect
> function. The dpcd probe for checking panel replay capability
> for external dp connector is causing delay during boot which can
> be optimized by moving dpcd probe to con
Hi,
In order to prepare for the drm-misc migration that should happen next
week, Benjamin and I just migrated drm-tip to Gitlab.
It should be effective as of 5 minutes ago, the old cgit repo being
currently marked read-only, and will be setup as a mirror.
Thanks to the work done last week, we sh
On Tue, Feb 27, 2024 at 11:02:04AM +0530, Suraj Kandpal wrote:
Enable HDCP for Xe by defining functions which take care of
interaction of HDCP as a client with the GSC CS interface.
Add intel_hdcp_gsc_message to Makefile and add corresponding
changes to xe_hdcp_gsc.c to make it build.
--v2
-add
On Tue, Feb 27, 2024 at 11:02:00AM +0530, Suraj Kandpal wrote:
This patch series enables HDCP on XE.
Mainly includes rewriting functions that were responsible for
sending hdcp messages via gsc cs.
Signed-off-by: Suraj Kandpal
Suraj Kandpal (4):
drm/i915/hdcp: Move intel_hdcp_gsc_message def a
On Tue, 05 Mar 2024, Suraj Kandpal wrote:
> As of now whenerver HDR is switched on we use the PWM to change the
> backlight as opposed to AUX based backlight changes in terms of nits.
> This patch writes to the appropriate DPCD registers to enable aux
> based backlight using values in nits.
>
> Si
On Tue, 05 Mar 2024, Ville Syrjälä wrote:
> On Tue, Mar 05, 2024 at 10:41:49AM +0200, Lisovskiy, Stanislav wrote:
>> I also wonder whether should we really emphasize things like "master"/"slave"
>> in function names. I thought that one idea in our refactoring was to unify
>> joined pipes handling
On Tue, 05 Mar 2024, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Reinstate commit 88b065943cb5 ("drm/i915/dsi: Do display on
> sequence later on icl+"), for the most part. Turns out some
> machines (eg. Chuwi Minibook X) really do need that updated order.
> It is also the order the Windows dri
From: Maarten Lankhorst
In some cases we want to flush all vblank work, right before vblank_off
for example. Add a simple function to make this possible.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_vblank_work.c | 22 ++
include/drm/drm_vblank_work.h | 2 +
Fix legacy cursor updates on xe by enforcing wait between updating
registers and unpin.
In comparison with previous version, there was a small bug in the
atomic unpin path. In intel_plane_cleanup_fb we tried to deference
plane_state after calling vblank schedule. Remove plane from atomic
state imm
In case of legacy cursor update, the cursor VMA needs to be unpinned
only after vblank. This exceeds the lifetime of the whole atomic commit.
Any trick I attempted to keep the atomic commit alive didn't work, as
drm_atomic_helper_setup_commit() force throttles on any old commit that
wasn't cleaned
From: Ville Syrjälä
The cursor hardware only does sync updates, and thus the hardware
will be scanning out from the old fb until the next start of vblank.
So in order to make the legacy cursor fastpath actually safe we
should not unpin the old fb until we're sure the hardware has
ceased accessing
On Tue, Mar 05, 2024 at 04:07:45PM +0200, Jani Nikula wrote:
> On Tue, 05 Mar 2024, Ville Syrjälä wrote:
> > On Tue, Mar 05, 2024 at 10:41:49AM +0200, Lisovskiy, Stanislav wrote:
> >> I also wonder whether should we really emphasize things like
> >> "master"/"slave"
> >> in function names. I thou
Object debugging tools were sporadically reporting illegal attempts to
free a still active i915 VMA object when parking a GT believed to be idle.
[161.359441] ODEBUG: free active (active state 0) object: 88811643b958
object type: i915_active hint: __i915_vma_active+0x0/0x50 [i915]
[161.360082
There was an attempt to fix an issue of illegal attempts to free a still
active i915 VMA object when parking a GT believed to be idle, reported by
CI on 2-GT Meteor Lake. As a solution, an extra wakeref for a Primary GT
was acquired from i915_gem_do_execbuffer() -- see commit f56fe3e91787
("drm/i9
Object debugging tools were sporadically reporting illegal attempts to
free a still active i915 VMA object when parking a GT believed to be idle.
[161.359441] ODEBUG: free active (active state 0) object: 88811643b958
object type: i915_active hint: __i915_vma_active+0x0/0x50 [i915]
[161.360082
This reverts commit 7a2280e8dcd2f1f436db9631287c0b21cf6a92b0, obsoleted
by "drm/i915/vma: Fix UAF on destroy against retire race".
Signed-off-by: Janusz Krzysztofik
Cc: Nirmoy Das
---
drivers/gpu/drm/i915/i915_vma.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_
== Series Details ==
Series: drm/i915/dp: Fix the computation for compressed_bpp for DISPLAY < 13
URL : https://patchwork.freedesktop.org/series/130710/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_14388 -> Patchwork_130710v1
==
Quoting Matt Roper (2024-03-04 18:58:34-03:00)
>On Mon, Mar 04, 2024 at 03:30:21PM -0300, Gustavo Sousa wrote:
>> There will be future changes that rely on the source of the MDCLK. Let's
>> have xe2lpd_mdclk_source_sel() as the function responsible for reporting
>> that information.
>>
>> Bspec: 6
Quoting Matt Roper (2024-03-04 19:04:19-03:00)
>On Mon, Mar 04, 2024 at 03:30:22PM -0300, Gustavo Sousa wrote:
>> It is no use computing the squash waveform if we are not going to use
>> it. Move the call to cdclk_squash_waveform() inside the block guarded by
>> HAS_CDCLK_SQUASH(dev_priv).
>>
>> S
On Thu, Feb 29, 2024 at 10:03:54PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> ICL_AUX_ANAOVRD1 is actually ICL_PORT_TX_DW6_AUX. Give it its proper
> name, and relocate to the correct file (intel_combo_phy_regs.h).
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display
Quoting Matt Roper (2024-03-04 20:25:31-03:00)
>On Mon, Mar 04, 2024 at 03:30:24PM -0300, Gustavo Sousa wrote:
>> CDCLK programming Xe2LPD always selects the CDCLK PLL as source for the
>
>I think something got a bit muddled while rewriting this sentence.
>Maybe the first two words were supposed to
On Tue, 05 Mar 2024, Ville Syrjälä wrote:
> If the spec got updated then we should probably just do a full rename
> pass over the whole codebase instead of confusing things more by
> mixing up the terminology.
For example:
Bspec 54142 for display version 12+ has some mixed old/new terminology.
On 3/5/2024 3:35 PM, Janusz Krzysztofik wrote:
This reverts commit 7a2280e8dcd2f1f436db9631287c0b21cf6a92b0, obsoleted
by "drm/i915/vma: Fix UAF on destroy against retire race".
Signed-off-by: Janusz Krzysztofik
Cc: Nirmoy Das
Reviewed-by: Nirmoy Das
---
drivers/gpu/drm/i915/i915_vma.c |
On 3/5/2024 3:35 PM, Janusz Krzysztofik wrote:
Object debugging tools were sporadically reporting illegal attempts to
free a still active i915 VMA object when parking a GT believed to be idle.
[161.359441] ODEBUG: free active (active state 0) object: 88811643b958
object type: i915_active h
On 3/5/2024 3:35 PM, Janusz Krzysztofik wrote:
There was an attempt to fix an issue of illegal attempts to free a still
active i915 VMA object when parking a GT believed to be idle, reported by
CI on 2-GT Meteor Lake. As a solution, an extra wakeref for a Primary GT
was acquired from i915_gem_d
On Thu, Feb 29, 2024 at 10:03:56PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We don't actually know whether we should be picking the PHY
> simply based on the AUX_CH/power well, or based on the VBT
> defined AUX_CH->DDI->PHY relationship. At the moment we are
> doing the former for th
On Mon, Feb 19, 2024 at 11:22:55AM +0530, Ankit Nautiyal wrote:
> For Earlier platforms, the Pipe source size is 12-bits so
> max pipe source width and height is 4096. For newer platforms it is
> 13-bits so theoretically max height is 8192, but maximum width
> supported on a single pipe is 5120, be
This patch-set is a prerequisite for a standalone TTM shrinker
and for exhaustive TTM eviction using sleeping dma_resv locks,
which is the motivation for it.
Currently when unlocking the TTM lru list lock, iteration needs
to be restarted from the beginning, rather from the next LRU list
node. This
To address the problem with hitches moving when bulk move
sublists are lru-bumped, register the list cursors with the
ttm_lru_bulk_move structure when traversing its list, and
when lru-bumping the list, move the cursor hitch to the tail.
This also means it's mandatory for drivers to call
ttm_lru_bu
Have iterators insert themselves into the list they are iterating
over using hitch list nodes. Since only the iterator owner
can remove these list nodes from the list, it's safe to unlock
the list and when continuing, use them as a starting point. Due to
the way LRU bumping works in TTM, newly adde
To be able to handle list unlocking while traversing the LRU
list, we want the iterators not only to point to the next
position of the list traversal, but to insert themselves as
list nodes at that point to work around the fact that the
next node might otherwise disappear from the list while
the it
The -ENOSPC failure from ttm_bo_swapout() meant that the lru_lock
was dropped and simply restarting the iteration meant we'd likely
hit the same error again on the same resource. Now that we can
restart the iteration even if the lock was dropped, do that.
Cc: Christian König
Cc: Somalapuram Amara
On Fri, Mar 01, 2024 at 02:42:55PM +0100, Thomas Zimmermann wrote:
> Unregister all in-kernel clients before unloading the i915 driver. For
> other drivers, drm_dev_unregister() does this automatically. As i915
> does not use this helper, it has to perform the call by itself. For xe,
> do the same
On Tue, 05 Mar 2024, Rodrigo Vivi wrote:
> On Fri, Mar 01, 2024 at 02:42:55PM +0100, Thomas Zimmermann wrote:
>> Unregister all in-kernel clients before unloading the i915 driver. For
>> other drivers, drm_dev_unregister() does this automatically. As i915
>> does not use this helper, it has to per
On Wed, 28 Feb 2024, Juha-Pekka Heikkila wrote:
> AuxCCS framebuffers don't work on Xe driver hence disable them
> from plane capabilities until they are fixed. FlatCCS framebuffers
> work and they are left enabled. CCS is left untouched for i915
> driver.
>
> Closes: https://gitlab.freedesktop.or
Hi Janusz,
On Wed, Feb 28, 2024 at 04:24:41PM +0100, Janusz Krzysztofik wrote:
> While trying to reproduce some other issues reported by CI for i915
> hangcheck live selftest, I found them hidden behind timeout failures
> reported by igt_hang_sanitycheck -- the very first hangcheck test case
> exe
Hi Janusz,
On Thu, Feb 22, 2024 at 12:32:40PM +0100, Janusz Krzysztofik wrote:
> Third argument of i915_request_wait() accepts a timeout value in jiffies.
> Most users pass either a simple HZ based expression, or a result of
> msecs_to_jiffies(), or MAX_SCHEDULE_TIMEOUT, or a very small number not
On Tue, 05 Mar 2024, "Maxime Ripard" wrote:
> On Tue, 5 Mar 2024 11:07:34 +0200, Jani Nikula wrote:
>> Resend of [1] with an intent to merge after the CI results come in. This
>> is aiming for v6.10, so we'll have maximal time to find all the issues
>> my configs didn't catch.
>>
>> I built this
On Tue, Mar 05, 2024 at 07:43:07PM +0200, Jani Nikula wrote:
On Tue, 05 Mar 2024, "Maxime Ripard" wrote:
On Tue, 5 Mar 2024 11:07:34 +0200, Jani Nikula wrote:
Resend of [1] with an intent to merge after the CI results come in. This
is aiming for v6.10, so we'll have maximal time to find all th
On Tue, Mar 05, 2024 at 06:49:16AM +, Borah, Chaitanya Kumar wrote:
> Issue is still seen with the following changes
>
> void put_pages_list(struct list_head *pages)
>
> folio_batch_init(&fbatch);
> list_for_each_entry(folio, pages, lru) {
> - if (!folio_put_tes
On Tue, 05 Mar 2024, Lucas De Marchi wrote:
> On Tue, Mar 05, 2024 at 07:43:07PM +0200, Jani Nikula wrote:
>>Thanks everyone for acks and reviews, pushed to drm-misc-next.
>
> should we start removing the now duplicate ones in i915 and xe?
After the drm-misc-next to drm-next merge and subsequent
== Series Details ==
Series: drm/i915/dsi: Go back to the previous INIT_OTP/DISPLAY_ON order, mostly
URL : https://patchwork.freedesktop.org/series/130714/
State : warning
== Summary ==
Error: dim checkpatch failed
916e57569f78 drm/i915/dsi: Go back to the previous INIT_OTP/DISPLAY_ON order,
== Series Details ==
Series: drm/i915/dsi: Go back to the previous INIT_OTP/DISPLAY_ON order, mostly
URL : https://patchwork.freedesktop.org/series/130714/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_14392 -> Patchwork_130714v1
===
On Fri, Mar 01, 2024 at 08:00:41PM +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/dp: Fix connector DSC HW state readout (rev2)
> URL : https://patchwork.freedesktop.org/series/129540/
> State : failure
Thanks for the report/testing and review, patch is pushed to
drm-intel-
On Wed, Feb 28, 2024 at 10:02:12AM +0200, Stanislav Lisovskiy wrote:
> According to BSpec we need to do correspondent MBUS updates before
> or after DBUF reallocation, depending on whether we are reducing
> or increasing amount of pipes(typical scenario is swithing between
> multiple and single dis
On Wed, Feb 28, 2024 at 10:02:13AM +0200, Stanislav Lisovskiy wrote:
> Currently we can't change MBUS join status without doing a modeset,
> because we are lacking mechanism to synchronize those with vblank.
> However then this means that we can't do a fastset, if there is a need
> to change MBUS j
== Series Details ==
Series: drm/i915: Make crtc disable more atomic
URL : https://patchwork.freedesktop.org/series/130715/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_14392 -> Patchwork_130715v1
Summary
---
**FAIL
== Series Details ==
Series: drm/i915: Use drm_printer more (rev5)
URL : https://patchwork.freedesktop.org/series/129956/
State : warning
== Summary ==
Error: dim checkpatch failed
3de64739aac8 drm/i915: Indicate which pipe failed the fastset check overall
84cc770bca09 drm/i915: Include CRTC i
== Series Details ==
Series: drm/i915: Use drm_printer more (rev5)
URL : https://patchwork.freedesktop.org/series/129956/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: drm: enable W=1 warnings by default across the subsystem (rev4)
URL : https://patchwork.freedesktop.org/series/127072/
State : failure
== Summary ==
Error: patch
https://patchwork.freedesktop.org/api/1.0/series/127072/revisions/4/mbox/ not
applied
Applying: drm:
== Series Details ==
Series: drm/i915: Use drm_printer more (rev5)
URL : https://patchwork.freedesktop.org/series/129956/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_14393 -> Patchwork_129956v5
Summary
---
**FAILUR
On Fri, Mar 01, 2024 at 12:28:57AM +0100, Andi Shyti wrote:
> Some of the CCS engines are disabled. They should not be listed
> in the uabi_engine list, that is the list of engines that the
> user can see.
Fused off engines already aren't visible to userspace (or to the kernel
for that matter). F
== Series Details ==
Series: drm/ci: update device type for volteer devices (rev2)
URL : https://patchwork.freedesktop.org/series/130723/
State : warning
== Summary ==
Error: dim checkpatch failed
1f2ef535a742 drm/ci: update device type for volteer devices
-:16: WARNING:BAD_FIXES_TAG: Please u
== Series Details ==
Series: drm/ci: update device type for volteer devices (rev2)
URL : https://patchwork.freedesktop.org/series/130723/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_14393 -> Patchwork_130723v2
Summary
---
Hi Thomas,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on drm-intel/for-linux-next drm-tip/drm-tip]
[cannot apply to drm-intel/for-linux-next-fixes linus/master v6.8-rc7
next-20240305]
[If your patch is
On Mon, Mar 4, 2024, at 3:34 PM, Vinay Belgaumkar wrote:
> Allow user to provide a low latency context hint. When set, KMD
> sends a hint to GuC which results in special handling for this
> context. SLPC will ramp the GT frequency aggressively every time
> it switches to this context. The down freq
On Mon, Mar 04, 2024 at 03:34:50PM -0800, Vinay Belgaumkar wrote:
> Allow user to provide a low latency context hint. When set, KMD
> sends a hint to GuC which results in special handling for this
> context. SLPC will ramp the GT frequency aggressively every time
> it switches to this context. The
== Series Details ==
Series: drm/i915/dp: Enable AUX based backlight for HDR
URL : https://patchwork.freedesktop.org/series/130729/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_14393 -> Patchwork_130729v1
Summary
---
1 - 100 of 141 matches
Mail list logo
