Hi Krzysztof,
On 2025-03-05 at 17:31:49 +0100, Krzysztof Niemiec wrote:
> Don't we run into the same issue as in V1, meaning we use an unknown
> current->active_mm (since we run in a kthread, and cannot control it) to
> use as the current->mm? Maybe a better approach would be to create a new
> mm
Hi Janusz,
throughout the series you modify the code right after
introducing it. How about changing the order of things a bit:
1) order the functions in a symmetrical way between
register/unregister steps and group them as you see necessary,
(At that point you would not be fixing the issue ye
From: Ville Syrjälä
I'll need to move the wm readout to an earlier point in the
sequence (since the bw state readout will need ddb information
from the wm readout). But (at least for now) the wm sanitation
will need to stay put as it needs to also sanitize things for
any pipes/planes we disable l
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Monday, March 3, 2025 6:10 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 2/2] drm/i915: Program CURSOR_PROGRAM and
> COEFF_POLARITY for icl+ combo PHYs
>
> From: Ville Syrjälä
>
> Bspec asks us to
From: Ville Syrjälä
We only compute bw_state->data_rate and bw_state->num_active_planes
on icl+. Do the same during readout so that we don't leave random
junk inside the state.
v2: Skip the whole intel_bw_crtc_update() (Vinod)
Reviewed-by: Vinod Govindapillai
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Instead of hand rolling the cdclk state disabling for a
pipe in noatomic() let's just recompute the whole thing
from scratch. Less code we have to remember to keep in sync.
Reviewed-by: Vinod Govindapillai
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel
== Series Details ==
Series: drm/i915: Increase I915_PARAM_MMAP_GTT_VERSION version to indicate
support for partial mmaps
URL : https://patchwork.freedesktop.org/series/145945/
State : warning
== Summary ==
Error: dim checkpatch failed
480d0b877d0c drm/i915: Increase I915_PARAM_MMAP_GTT_VERSI
Give the scheduler a chance to breath by adding delay of 10ms
as some of the loops may take some time on old machines (like apl/bsw/pnv),
and so catch the attention of the watchdogs.
v1: Instead of cond_resched(), use more generic call like
fsleep().
Closes: https://gitlab.freedesktop.org/dr
== Series Details ==
Series: drm/i915/selftests: Refactor RC6 power measurement and error handling
(rev2)
URL : https://patchwork.freedesktop.org/series/145766/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_16237 -> Patchwork_145766v2
=
== Series Details ==
Series: drm/i915: cdclk/bw/dbuf readout/sanitation cleanup (rev2)
URL : https://patchwork.freedesktop.org/series/145045/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
Hi Dave and Sima,
Here goes our xe fixes for this round, with
many fixes around userptr.
Thanks,
Rodrigo.
drm-xe-fixes-2025-03-06:
- Remove double page flip on initial plane (Maarten)
- Properly setup userptr pfn_flags_mask (Auld)
- Fix GT "for each engine" workarounds (Tvrtko)
- Fix userptr rac
== Series Details ==
Series: drm/i915: Increase I915_PARAM_MMAP_GTT_VERSION version to indicate
support for partial mmaps
URL : https://patchwork.freedesktop.org/series/145945/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_16237 -> Patchwork_145945v1
=
== Series Details ==
Series: series starting with [v2,1/2] drm/i915/dp: Reject HBR3 when sink
doesn't support TPS4 (rev2)
URL : https://patchwork.freedesktop.org/series/145716/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_16237 -> Patchwork_145716v2
=
== Series Details ==
Series: series starting with [v2,1/2] drm/i915/dp: Reject HBR3 when sink
doesn't support TPS4 (rev2)
URL : https://patchwork.freedesktop.org/series/145716/
State : warning
== Summary ==
Error: dim checkpatch failed
73f6a99232eb drm/i915/dp: Reject HBR3 when sink doesn't s
From: Ville Syrjälä
According to the DP spec TPS4 is mandatory for HBR3. We have
however seen some broken eDP sinks that violate this and
declare support for HBR3 without TPS4 support.
At least in the case of the icl Dell XPS 13 7390 this results
in an unstable output.
Reject HBR3 when TPS4 sup
For platforms for which vrr timing generator is always set, VRR_CTL
enable bit does not need to toggle, so modify the vrr_{enable/disable}
for this.
At the moment the helper intel_vrr_always_use_vrr_tg() return false for
all cases. This will be set later when all other bits are in place.
Signed-of
VRR with joiner is currently disabled as it still needs some work to
correctly sequence the primary and secondary transcoders. However, we can
still use VRR Timing generator in fixed refresh rate for joiner and since
it just need to program vrr timings once and does not involve changing
timings on
On Fri, Mar 07, 2025 at 01:08:01AM +0900, Vincent Mailhol wrote:
> On 06/03/2025 à 22:08, Andy Shevchenko wrote:
> > On Thu, Mar 06, 2025 at 08:29:53PM +0900, Vincent Mailhol via B4 Relay
> > wrote:
...
> Does this mean I get your Reviewed-by tag? Or will you wait the v6 to
> formally give it?
Hi Dave, Sima,
here's the PR for drm-misc-next. It includes two new drivers for Apple
Touch Bar displays. There are new helpers for TTM's shrinker, which xe
now uses. There are a number of changes to the rockchip driver.
There are also cross-subsystem changes for drivers/base and fbdev. The
latte
On Wed, 05 Mar 2025, Ryszard Knop wrote:
> On Wed, 2025-03-05 at 19:52 +0200, Jani Nikula wrote:
>> I think eventually we will want to consider accepting contributions via
>> gitlab merge requests directly.
>>
>> It would also be interesting if maintainers/committers could merge the
>> contributi
From: Sk Anirban
Refactor power measurement logic to store and compare energy values.
Introduce a threshold check to ensure the GPU enters RC6 properly.
v2:
- Improved commit message (Badal)
v3:
- Reorder threshold check (Badal)
Signed-off-by: Sk Anirban
---
drivers/gpu/drm/i915/gt/selfte
On Fri, Mar 07, 2025 at 01:08:15AM +0900, Vincent Mailhol wrote:
> On 06/03/2025 at 22:11, Andy Shevchenko wrote:
> > On Thu, Mar 06, 2025 at 08:29:58PM +0900, Vincent Mailhol via B4 Relay
> > wrote:
> >> From: Vincent Mailhol
> >>
> >> Add some additional tests in lib/test_bits.c to cover the ex
== Series Details ==
Series: drm/i915: cdclk/bw/dbuf readout/sanitation cleanup (rev2)
URL : https://patchwork.freedesktop.org/series/145045/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_16236 -> Patchwork_145045v2
Summary
== Series Details ==
Series: dma-buf: Take a breath during dma-fence-chain subtests (rev2)
URL : https://patchwork.freedesktop.org/series/145497/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_16236 -> Patchwork_145497v2
Sum
Hi Dave and Sima,
Here goes the only i915 fix for this round.
Thanks,
Rodrigo.
drm-intel-fixes-2025-03-06:
- DP MST fix (Jani)
The following changes since commit 7eb172143d5508b4da468ed59ee857c6e5e01da6:
Linux 6.14-rc5 (2025-03-02 11:48:20 -0800)
are available in the Git repository at:
ht
On Fri, Mar 07, 2025 at 12:07:45AM +0900, Vincent Mailhol wrote:
> On 06/03/2025 at 22:05, Andy Shevchenko wrote:
> > On Thu, Mar 06, 2025 at 08:29:52PM +0900, Vincent Mailhol via B4 Relay
> > wrote:
> >> From: Vincent Mailhol
...
> >> -/*
> >> - * BUILD_BUG_ON_ZERO is not available in h files
On Thu, Mar 06, 2025 at 06:40:54PM +0530, Ankit Nautiyal wrote:
> During modeset enable sequence, program the fixed timings, and turn on the
> VRR Timing Generator (VRR TG) for platforms that always use VRR TG.
>
> For this intel_vrr_set_transcoder now always programs fixed timings.
> Later if vrr
On Thu, Mar 06, 2025 at 06:40:55PM +0530, Ankit Nautiyal wrote:
> For fixed refresh rate use fixed timings for all platforms that support
> VRR. For this add checks to avoid computing and reading VRR for
> platforms that do not support VRR.
>
> v2: Avoid touching check for VRR_CTL_FLIP_LINE_EN. (V
From: Ville Syrjälä
Hoist the cdclk stuff into a separate function from
intel_modeset_readout_hw_state() so that the details
are better hidden inside intel_cdclk.c.
Reviewed-by: Vinod Govindapillai
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_cdclk.c| 29 +++
On Thu, Mar 06, 2025 at 06:40:52PM +0530, Ankit Nautiyal wrote:
> LRR and Vmax can be computed only if VRR is supported and vrr.in_range
> is set. Currently we proceed with vrr timings only for VRR supporting
> panels and return otherwise. For using VRR TG with fix timings, need to
> continue even
From: Ville Syrjälä
intel_bw_crtc_update() is only used by the readout path, so relocate
the function next its only caller. Easier to read the code when related
things are nearby.
Reviewed-by: Vinod Govindapillai
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_bw.c | 36 ++
From: Ville Syrjälä
Move the wm readout to happen earlier. This is needed because
the bw_state readout will need ddb information populated by
the wm readout.
For now limit this to skl+ as I've not really analyzed the
implications of doing this on other platforms.
Reviewed-by: Vinod Govindapilla
From: Ville Syrjälä
intel_crtc_calculate_min_cdclk() can't return an error
(since commit 5ac860cc5254 ("drm/i915: Fix DBUF bandwidth vs.
cdclk handling")) so there is no point in checking for one.
Also we can just call it unconditionally since it itself
checks crtc_state->hw.enabled. We are curr
From: Ville Syrjälä
Update bw_state->active_pipes during readout.
This was completely missing from the current readout code.
Reviewed-by: Vinod Govindapillai
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_bw.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/dri
From: Ville Syrjälä
Hoist the dbuf stuff into a separate function from
intel_crtc_disable_noatomic_complete() so that the details
are better hidden inside skl_watermark.c.
We can also skip the whole thing on pre-skl since the dbuf state
isn't actually used on those platforms. The readout path do
From: Ville Syrjälä
Add skl_wm_plane_disable_noatomic() which will clear out all
the ddb and wm state for the plane. And let's do this _before_
we call plane->disable_arm() so that it'll actually clear out
the state in the hardware as well.
Currently this won't do anything new for most of the
in
From: Ville Syrjälä
Update the ddb tracking information when we disable a pipe
during sanitization. Avoids leaving stale junk in the states.
Currently this doesn't do anything as we haven't read out this
state yet when we do the sanitization, but that will change soon.
Reviewed-by: Vinod Govind
From: Ville Syrjälä
Hoist the cdclk stuff into a separate function from
intel_crtc_disable_noatomic_complete() so that the details
are better hidden inside intel_cdclk.c.
Reviewed-by: Vinod Govindapillai
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 12
From: Ville Syrjälä
Inactive crtcs are supposed to have their crtc_state completely
cleared. Currently we are clobbering crtc_state->cpu_transcoder
before determining whether it's actually enabled or not. Don't
do that.
I want to rework the inherited flag handling for inactive crtcs
a bit, and h
From: Ville Syrjälä
I want to clean up the messy interactions between
cdclk/bw/dbuf/etc. code. Start to making the state
handling during readout/sanitation a bit more sane.
v2: Rebase due to intel_display changes
Rework the intel_bw_crtc_update() stuff a bit (Vinod)
Ville Syrjälä (18):
dr
From: Ville Syrjälä
The crtc state is expected to be fully cleared before readout,
so there is no need to clear the shared_dpll pointers by hand.
Reviewed-by: Vinod Govindapillai
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 4
1 file changed, 4 deletion
Quoting Krzysztof Karas (2025-03-06 16:07:02)
> > - remove the selftest and completely forget about the HW issue, or
> Can we do anything about that HW issue? :)
The root cause was found.
> > - hide the selftest and stop it running on known bad platforms?
> This seems like it could be a solution
On Tue, Mar 04, 2025 at 03:04:07PM +, Govindapillai, Vinod wrote:
> On Tue, 2025-02-18 at 23:19 +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Instead of hand rolling the cdclk state disabling for a
> > pipe in noatomic() let's just recompute the whole thing
> > from scratch. Les
On Tue, Mar 04, 2025 at 02:20:51PM +, Govindapillai, Vinod wrote:
> On Tue, 2025-02-18 at 23:19 +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > We only compute bw_state->data_rate and bw_state->num_active_planes
> > on icl+. Do the same during readout so that we don't leave random
On Thu, Mar 06, 2025 at 06:22:33PM +0900, Vincent Mailhol wrote:
> On 06/03/2025 at 04:45, Andy Shevchenko wrote:
> >>> But GENMASK_U128() becomes a special case now.
> >>> The 128-bit GENMASK is unsued, but it's exported in uapi. Is there any
> >>> simple way to end up with a common implementation
On Tue, Mar 04, 2025 at 02:04:02PM +, Govindapillai, Vinod wrote:
> On Tue, 2025-02-18 at 23:19 +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Hoist the cdclk stuff into a separate function from
> > intel_modeset_readout_hw_state() so that the details
> > are better hidden inside
On Thu, Mar 06, 2025 at 08:29:58PM +0900, Vincent Mailhol via B4 Relay wrote:
> From: Vincent Mailhol
>
> Add some additional tests in lib/test_bits.c to cover the expected
> results of the fixed type BIT_U*() macros.
Still would be good to have a small assembly test case for GENMASK*() as they
Hi,
> Quoting Tvrtko Ursulin (2025-03-04 16:43:45)
> >
> > On 04/03/2025 13:09, Mikolaj Wasiak wrote:
> > > This test exposes bug in tigerlake hardware which prevents it from
> > > succeeding. Since the tested feature is only available on bugged hardware
> > > and we won't support any new hardwar
For fixed refresh rate use fixed timings for all platforms that support
VRR. For this add checks to avoid computing and reading VRR for
platforms that do not support VRR.
v2: Avoid touching check for VRR_CTL_FLIP_LINE_EN. (Ville)
v3: Avoid redundant statements in vrr_{compute/get}_config. (Ville)
Am 06.03.25 um 16:11 schrieb Nitin Gote:
> Give the scheduler a chance to breath by adding delay of 10ms
> as some of the loops may take some time on old machines (like apl/bsw/pnv),
> and so catch the attention of the watchdogs.
>
> v1: Instead of cond_resched(), use more generic call like
> f
On Wed, Mar 05, 2025 at 11:38:19PM +0900, Vincent Mailhol wrote:
On 05/03/2025 at 23:30, Andy Shevchenko wrote:
On Wed, Mar 05, 2025 at 10:00:15PM +0900, Vincent Mailhol via B4 Relay wrote:
From: Yury Norov
Add __GENMASK_t() which generalizes __GENMASK() to support different
Is it with doub
== Series Details ==
Series: Use VRR timing generator for fixed refresh rate modes (rev12)
URL : https://patchwork.freedesktop.org/series/134383/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_16234 -> Patchwork_134383v12
Su
On Thu, Mar 06, 2025 at 08:29:52PM +0900, Vincent Mailhol via B4 Relay wrote:
From: Vincent Mailhol
In an upcoming change, GENMASK() and its friends will indirectly
depend on sizeof() which is not available in asm.
Instead of adding further complexity to __GENMASK() to make it work
for both as
Hi Yuichiro,
On Mon, Feb 24, 2025 at 05:56:37PM +0900, Yuichiro Tsuji wrote:
> Fix typo in a comment.
>
> explaination -> explanation
>
> Signed-off-by: Yuichiro Tsuji
reviewed and merged, thanks.
Andi
On Wed, Mar 05, 2025 at 05:00:26PM +, Sebastian Brzezinka wrote:
> Hi Ville
>
> On Wed Mar 5, 2025 at 3:26 PM UTC, Ville Syrjälä wrote:
> > On Wed, Mar 05, 2025 at 02:49:46PM +, Sebastian Brzezinka wrote:
> >> This reverts commit 0ddae025ab6cefa9aba757da3cd1d27908d70b0e.
> >>
> >> Accordi
== Series Details ==
Series: Use VRR timing generator for fixed refresh rate modes (rev12)
URL : https://patchwork.freedesktop.org/series/134383/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+./arch/x86/i
Currently we always compute the timings as if vrr is enabled.
With this approach the state checker becomes complicated when we
introduce fixed refresh rate mode with vrr timing generator.
To avoid the complications, instead of always computing vrr timings, we
compute vrr timings based on uapi.vrr_
Hi Janusz,
thanks for a quick response.
> > throughout the series you modify the code right after
> > introducing it.
>
> Yes, that split among patches reflects my way of getting to a solution that
> not only resolves the issue but also tries to address comments I got and take
> care of resul
Add fixed refresh rate mode in crtc_state dump.
VRR Timing Generator is running in fixed refresh rate mode when
vrr.enable is unset and vrr.vmin = vrr.vmax = vrr.flipline.
v2: Add check for vrr.enable.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_crtc_state_dump.c | 3 ++
MSA Ignore Timing PAR enable is set in the DP sink when we enable variable
refresh rate.
Currently for link training we depend on flipline to decide whether we
want to ignore the msa timings. With fixed refresh rate we will still
fill the flipline in all cases whether panel supports VRR or not.
C
Switching between variable and fixed timings is possible as for that we
just need to flip between VRR timings. However for CMRR along with the
timings, few other bits also need to be changed on the fly, which might
cause issues. So disable CMRR for now, till we have variable and fixed
timings sorte
In intel_post_plane_update() there are things which might need to do
vblank waits, so enabling PSR as early as we do now is simply
counter-productive. Therefore move intel_psr_post_plane_update() at the
last of intel_post_plane_update().
Signed-off-by: Ankit Nautiyal
Suggested-by: Ville Syrjälä
As per bspec 49268: Disable PSR before disabling VRR.
Signed-off-by: Ankit Nautiyal
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm
To have fixed refresh rate with VRR timing generator the
guardband/pipeline full can't be programmed on the fly. So we need to
ensure that the values satisfy both the fixed and variable refresh
rates.
Since we compute these value based on vmin, lets set the vmin to
crtc_vtotal for both fixed and v
== Series Details ==
Series: drm/xe/compat: cleanup (rev2)
URL : https://patchwork.freedesktop.org/series/145854/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_16234 -> Patchwork_145854v2
Summary
---
**SUCCESS**
N
Even though the VRR timing generator (TG) is primarily used for
variable refresh rates, it can be used for fixed refresh rates as
well. For a fixed refresh rate the Flip Line and Vmax must be equal
(TRANS_VRR_FLIPLINE = TRANS_VRR_VMAX). Beyond that, there are some
dependencies between the VRR timin
Make helpers to compute vmin and vmax.
v2: Make the adjusted mode const (Ville)
Use reverse xmas tree order of declarations. (Ville)
Signed-off-by: Ankit Nautiyal
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_vrr.c | 38 +++-
1 file changed, 30 insertion
The comment about fixed average vtotal is incorrect.
Remove it.
Signed-off-by: Ankit Nautiyal
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_vrr.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c
b/drivers/gpu/drm/i915/display/
On Thu, Mar 06, 2025 at 08:29:53PM +0900, Vincent Mailhol via B4 Relay wrote:
> From: Yury Norov
>
> Add GENMASK_TYPE() which generalizes __GENMASK() to support different
> types, and implement fixed-types versions of GENMASK() based on it.
> The fixed-type version allows more strict checks to th
On Thu, Mar 06, 2025 at 08:29:52PM +0900, Vincent Mailhol via B4 Relay wrote:
> From: Vincent Mailhol
>
> In an upcoming change, GENMASK() and its friends will indirectly
> depend on sizeof() which is not available in asm.
>
> Instead of adding further complexity to __GENMASK() to make it work
>
On Thu, Mar 06, 2025 at 08:29:51PM +0900, Vincent Mailhol via B4 Relay wrote:
> Introduce some fixed width variant of the GENMASK() and the BIT()
> macros in bits.h. Note that the main goal is not to get the correct
> type, but rather to enforce more checks at compile time. For example:
>
> GENM
== Series Details ==
Series: drm/xe/compat: cleanup (rev2)
URL : https://patchwork.freedesktop.org/series/145854/
State : warning
== Summary ==
Error: patch
https://patchwork.freedesktop.org/api/1.0/series/145854/revisions/2/mbox/ not
found
== Series Details ==
Series: drm/xe/compat: cleanup (rev2)
URL : https://patchwork.freedesktop.org/series/145854/
State : warning
== Summary ==
Error: patch
https://patchwork.freedesktop.org/api/1.0/series/145854/revisions/2/mbox/ not
found
== Series Details ==
Series: drm/xe/compat: cleanup (rev2)
URL : https://patchwork.freedesktop.org/series/145854/
State : warning
== Summary ==
Error: patch
https://patchwork.freedesktop.org/api/1.0/series/145854/revisions/2/mbox/ not
found
Hi,
https://patchwork.freedesktop.org/series/144436/- Re-reported.
i915.CI.FULL - Re-reported.
Thanks,
Ravali.
-Original Message-
From: I915-ci-infra On Behalf Of
Janusz Krzysztofik
Sent: 06 March 2025 15:22
To: i915-ci-in...@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org
Su
Hi Jani,
On Thursday, 6 March 2025 11:25:52 CET Jani Nikula wrote:
> On Wed, 05 Mar 2025, Janusz Krzysztofik
> wrote:
> > Starting with commit ec3e00b4ee27 ("drm/i915: stop registering if
> > drm_dev_register() fails"), we return from i915_driver_register()
> > immediately if drm_dev_register()
On Wed, 05 Mar 2025, Konstantin Ryabitsev
wrote:
> On Wed, Mar 05, 2025 at 07:52:31PM +0200, Jani Nikula wrote:
>> > - For each new series on lore.kernel.org a bridge would create a PR by
>> > taking the latest mirrored drm-tip source, then applying a new series
>> > with `b4 shazam`.
>>
>> Ther
Quoting Tvrtko Ursulin (2025-03-04 16:43:45)
>
> On 04/03/2025 13:09, Mikolaj Wasiak wrote:
> > This test exposes bug in tigerlake hardware which prevents it from
> > succeeding. Since the tested feature is only available on bugged hardware
> > and we won't support any new hardware, this test is o
Hi,
Here's this week drm-misc-fixes PR.
Maxime
drm-misc-fixes-2025-03-06:
A Kconfig fix for nouveau, locking and timestamp fixes for imagination,
a header guard fix for sched and a DPMS regression fix for bochs.
The following changes since commit 3603996432997f7c88da37a97062a46cda01ac9d:
drm/
On Wed, Mar 05, 2025 at 09:50:27PM +, David Laight wrote:
> On Wed, 5 Mar 2025 21:56:22 +0200
> Andy Shevchenko wrote:
> > On Thu, Mar 06, 2025 at 02:17:18AM +0900, Vincent Mailhol wrote:
> > > On 06/03/2025 at 00:48, Andy Shevchenko wrote:
> > > > On Wed, Mar 05, 2025 at 11:48:10PM +0900, V
On Wed, 05 Mar 2025, Janusz Krzysztofik
wrote:
> Starting with commit ec3e00b4ee27 ("drm/i915: stop registering if
> drm_dev_register() fails"), we return from i915_driver_register()
> immediately if drm_dev_register() fails, skipping remaining registration
> steps. However, the _unregister() co
Hi Asbjorn,
On Sat, Jun 29, 2024 at 06:25:06PM +, Asbjørn Sloth Tønnesen wrote:
> Implement i915_gem_vmap_object() and i915_gem_vunmap_object(),
> based on i915_gem_dmabuf_vmap() and i915_gem_dmabuf_vunmap().
>
> This enables a drm_client to use drm_client_buffer_vmap() and
> drm_client_buffe
On Wed, 05 Mar 2025, David Laight wrote:
> So it is even questionable whether BIT8() and BIT16() should even
> exist at all.
If nothing else, they do provide compile time checks for the bit being
0..7 and 0..15, respectively.
BR,
Jani.
--
Jani Nikula, Intel
On Wed, 05 Mar 2025, Lucas De Marchi wrote:
> On Wed, Mar 05, 2025 at 07:52:31PM +0200, Jani Nikula wrote:
>>There's a small catch here. Patchwork is currently more clever about
>
> for some notion of clever. Try giving this kind of feedback in the
> mailing list:
>
> "oh, in addition to what you
84 matches
Mail list logo
