== Series Details ==
Series: Refactor MST DSC Determination Policy (rev3)
URL : https://patchwork.freedesktop.org/series/140832/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_15658 -> Patchwork_140832v3
Summary
---
*
== Series Details ==
Series: Refactor MST DSC Determination Policy (rev3)
URL : https://patchwork.freedesktop.org/series/140832/
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: Refactor MST DSC Determination Policy (rev3)
URL : https://patchwork.freedesktop.org/series/140832/
State : warning
== Summary ==
Error: dim checkpatch failed
4af0868951f8 drm/display/dsc: Refactor DRM MST DSC Determination Policy
-:11: WARNING:COMMIT_LOG_LONG_LINE
On Fri, Nov 08, 2024 at 03:25:30PM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/dmc_wl: Fixes and enablement for Xe3_LPD (rev4)
> URL : https://patchwork.freedesktop.org/series/140282/
> State : success
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_15658_full ->
The patch series is to refactor existing dsc determination policy for
dsc decompression and dsc passthrough given a mst output port.
Original routine was written based on different peer device types
which is not accurate and shows difficulty when expanding support of
products that do not fully com
[why]
How we determine the dsc_aux used for dsc decompression in
drm_dp_mst_dsc_aux_for_port() today has defects:
1. The method how we determine a connected peer device is virtual or not
in drm_dp_mst_is_virtual_dpcd() is not always correct. There are DP1.4
products
in the market which don'
[why]
Starting from dp2 where dsc passthrough is introduced, it is required to
identify
the dsc passthrough aux, apart from dsc decompression aux. Existing
drm_dp_mst_port function
that returns dsc_aux alone is not sufficient.
[how]
1. Interface change in drm_dp_mst_dsc_aux_for_port, and depende
== Series Details ==
Series: drm/i915: Potential boot oops fix and some cleanups (rev3)
URL : https://patchwork.freedesktop.org/series/141059/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_15658 -> Patchwork_141059v3
Summar
== Series Details ==
Series: drm/i915: Potential boot oops fix and some cleanups (rev3)
URL : https://patchwork.freedesktop.org/series/141059/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+./arch/x86/incl
== Series Details ==
Series: drm/i915: Potential boot oops fix and some cleanups (rev3)
URL : https://patchwork.freedesktop.org/series/141059/
State : warning
== Summary ==
Error: dim checkpatch failed
34f5e0cf0a95 drm/i915: Grab intel_display from the encoder to avoid potential
oopsies
d1f1d
Hi Dave and Simona,
drm-xe-fixes for 6.12-rc7. Still busier than I'd like for an rc7, but
needed particularly for LNL.
thanks,
Lucas De Marchi
drm-xe-fixes-2024-11-08:
Driver Changes:
- Fix ccs_mode setting for Xe2 and later (Balasubramani)
- Synchronize ccs_mode setting with client creation (B
Quoting Luca Coelho (2024-11-08 11:16:03-03:00)
>On Fri, 2024-11-08 at 09:57 -0300, Gustavo Sousa wrote:
>> Using the DMC wakelock is the official recommendation for Xe3_LPD. This
>> series apply fixes to the current DMC wakelock implementation and
>> enables it by default for Xe3_LPD. The series h
On Fri, 2024-11-08 at 09:57 -0300, Gustavo Sousa wrote:
> Using the DMC wakelock is the official recommendation for Xe3_LPD. This
> series apply fixes to the current DMC wakelock implementation and
> enables it by default for Xe3_LPD. The series has been tested with a PTL
> machine.
>
> This is th
== Series Details ==
Series: drm/i915/dmc_wl: Fixes and enablement for Xe3_LPD (rev4)
URL : https://patchwork.freedesktop.org/series/140282/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_15658 -> Patchwork_140282v4
Summary
== Series Details ==
Series: drm/i915/dmc_wl: Fixes and enablement for Xe3_LPD (rev4)
URL : https://patchwork.freedesktop.org/series/140282/
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/i915/dmc_wl: Fixes and enablement for Xe3_LPD (rev4)
URL : https://patchwork.freedesktop.org/series/140282/
State : warning
== Summary ==
Error: dim checkpatch failed
9e0a95a12b30 drm/i915/dmc_wl: Use i915_mmio_reg_offset() instead of reg.reg
cfd1589bb25d drm/x
Hi Dave, Simona,
Sorry for being late. I tried sending a pull request on monday, then noticed
the first compile fix was already in drm-next. There's one more in this tree,
mediatek no longer builds on arm64 without it.
I've lost my fiber connection on wednesday, and unfortunately it's still not
On Thu, 07 Nov 2024, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Rename a bunch of local variables to the preferred
> encoder/connector from intel_encoder/intel_connector.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_crt.c | 44
== Series Details ==
Series: drm/i915/dp: demote source OUI read/write failure logging to debug
(rev2)
URL : https://patchwork.freedesktop.org/series/141016/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_15657 -> Patchwork_141016v2
On Thu, 07 Nov 2024, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> crt->connector is never used, nuke it.
>
> Signed-off-by: Ville Syrjälä
I'll trust the compiler.
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_crt.c | 5 -
> 1 file changed, 5 deletions(-)
>
> dif
On Thu, 07 Nov 2024, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Remove a bunch of pointless 'struct drm_device *dev' local variables.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_crt.c | 15 +--
> 1 file changed, 5 insertions(+), 10 deletions(-)
>
On Thu, 07 Nov 2024, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Call the crtc state 'crtc_state' rather than 'pipe_config',
> as is the modern style.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_crt.c | 62
>
On Thu, 07 Nov 2024, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Move the analog port register definitions into their
> own file.
>
> Signed-off-by: Ville Syrjälä
'git show --color-moved' <3
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_crt.c | 1 +
> drivers/
On Thu, 07 Nov 2024, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> ADPA_HOTPLUG_BITS is defined in terms of the individual
> register bits and is defined in intel_crt.c, whereas the
> counterpart mask (ADPA_CRT_HOTPLUG_MASK) is just defined
> as a raw hex constant and lives in i915_reg.h. Just d
Quoting Luca Coelho (2024-11-08 06:57:11-03:00)
>On Thu, 2024-11-07 at 17:22 -0300, Gustavo Sousa wrote:
>> Quoting Gustavo Sousa (2024-11-07 17:14:36-03:00)
>> > Quoting Luca Coelho (2024-11-07 16:23:06-03:00)
>> > > On Thu, 2024-11-07 at 15:27 -0300, Gustavo Sousa wrote:
>> > > > There is a bit o
On Thu, 07 Nov 2024, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Follow the modern style and use REG_BIT() & co. for the analog
> port register definitions.
>
> Also throw out the ADPA_DPMS_... stuff as that's just an alias
> for the sync off bits.
I think you decided to split that to a separ
Enabling and disabling the DMC wakelock should be done as part of
enabling and disabling of dynamic DC states, respectively. We should not
enable or disable DMC wakelock independently of DC states, otherwise we
would risk ending up with an inconsistent state where dynamic DC states
are enabled and
Although Bspec doesn't explicitly mentions that, as of Xe3_LPD, using
DMC wakelock is the officially recommended way of accessing registers
that would be off during DC5/DC6 and the legacy method (where the DMC
intercepts MMIO to wake up the hardware) is to be avoided.
As such, update the driver to
In an upcoming change, we will add extra range tables for registers that
are touched by the DMC during DC states. The range table that we are
currently using is meant for registers that are powered off during DC
states. As such, let's rename the table to powered_off_ranges and also
add a comment re
Instead of checking for HAS_DMC_WAKELOCK() multiple times, let's use it
to sanitize the enable_dmc_wl parameter and use that variable when
necessary.
Reviewed-by: Luca Coelho
Signed-off-by: Gustavo Sousa
---
drivers/gpu/drm/i915/display/intel_dmc_wl.c | 21 ++---
1 file changed,
It is possible that there are active wakelock references at the time we
are disabling the DMC wakelock mechanism. We need to deal with that in
two ways:
(A) Implement the missing step from Bspec:
The Bspec instructs us to clear any existing wakelock request bit
after disabling the mechani
Allow simpler syntax for defining entries for single registers in range
tables. That makes them easier to type as well as to read, allowing one
to quickly tell whether a range actually refers to a single register or
a "true range".
Reviewed-by: Luca Coelho
Signed-off-by: Gustavo Sousa
---
drive
A HAS_DMC_WAKELOCK() macro gives more semantic than openly checking the
display version. Define it and use it where appropriate.
v2:
- Make this patch contain only the non-functional refactor. Functional
changes related to including HAS_DMC() in the macro are done in
upcoming changes. (J
There are extra registers that require the DMC wakelock when specific
dynamic DC states are in place. Those are registers that are touched by
the DMC and require DC exit for proper access. Add the range tables for
them and use the correct one depending on the enabled DC state.
v2:
- Do not look
The macro i915_mmio_reg_offset() is the proper interface to get a
register's offset. Use that instead of looking directly at reg.reg.
Reviewed-by: Jani Nikula
Reviewed-by: Luca Coelho
Signed-off-by: Gustavo Sousa
---
drivers/gpu/drm/i915/display/intel_dmc_wl.c | 11 ++-
1 file changed,
When the DMC wakelock refcount reaches zero, we know that there are no
users and that we can do the actual release operation on the hardware,
which is queued with a delayed work. The idea of the delayed work is to
avoid performing the release if a new lock user appears (i.e. refcount
gets increment
In upcoming display changes, we will modify the DMC wakelock MMIO
waiting code to choose a non-sleeping variant implementation, because
the wakelock is also taking in atomic context.
While xe provides an explicit parameter (namely "atomic") to prevent
xe_mmio_wait32() from sleeping, i915 does not
We will be using more than one range table in
intel_dmc_wl_check_range(). As such, move the logic to a new function
and name it intel_dmc_wl_reg_in_range().
Reviewed-by: Luca Coelho
Signed-off-by: Gustavo Sousa
---
drivers/gpu/drm/i915/display/intel_dmc_wl.c | 21 +++--
1 file c
We are currently using ARRAY_SIZE() to iterate address ranges in
intel_dmc_wl_check_range(). In upcoming changes, we will be using more
than a single table and will extract the range checking logic into a
dedicated function that takes a range table as argument. As we will not
able to use ARRAY_SIZE
Bspec says that disabling dynamic DC states require taking the DMC
wakelock to cause an DC exit before writing to DC_STATE_EN. Implement
that.
In fact, testing on PTL revealed we end up failing to exit DC5/6 without
this step.
Bspec: 71583
Reviewed-by: Luca Coelho
Signed-off-by: Gustavo Sousa
-
Some display MMIO transactions for offsets in the range that requires
the DMC wakelock happen in atomic context (this has been confirmed
during tests on PTL). That means that we need to use a non-sleeping
variant of MMIO waiting function.
Implement __intel_de_wait_for_register_atomic_nowl() and us
On Thu, 07 Nov 2024, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The ADPA_DPMS bit definitions aer just an alias for the
*are
> sync disable bits, and unused one at that. Drop the
> pointless definitions.
Pedantic mode, there's some singular/plural asymmetry going on here. :p
Reviewed-by:
Using the DMC wakelock is the official recommendation for Xe3_LPD. This
series apply fixes to the current DMC wakelock implementation and
enables it by default for Xe3_LPD. The series has been tested with a PTL
machine.
This is the v4 of the series. The only difference from v3 is that I decided to
On Thu, 07 Nov 2024, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Grab the intel_display from 'encoder' rather than 'state'
> in the encoder hooks to avoid the massive footgun that is
> intel_sanitize_encoder(), which passes NULL as the 'state'
> argument to encoder .disable() and .post_disable
On Thu, 07 Nov 2024, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Split an overly long line in the CRT code.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_crt.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git
== Series Details ==
Series: drm/i915/mst: cleanups, renames, clarifications (rev2)
URL : https://patchwork.freedesktop.org/series/141068/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_15656 -> Patchwork_141068v2
Summary
--
== Series Details ==
Series: drm/i915/mst: cleanups, renames, clarifications (rev2)
URL : https://patchwork.freedesktop.org/series/141068/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+./arch/x86/include/
== Series Details ==
Series: drm/i915/mst: cleanups, renames, clarifications (rev2)
URL : https://patchwork.freedesktop.org/series/141068/
State : warning
== Summary ==
Error: dim checkpatch failed
007f6f5fb61b drm/i915/mst: pass primary encoder to primary encoder hooks
-:21: WARNING:LONG_LINE
On Fri, 2024-11-08 at 07:56 +, Golani, Mitulkumar Ajitkumar wrote:
>
>
> > -Original Message-
> > From: Intel-gfx On Behalf
> > Of Jouni
> > Högander
> > Sent: 31 October 2024 13:40
> > To: intel-gfx@lists.freedesktop.org; intel...@lists.freedesktop.org
> > Cc: Hogander, Jouni
> > S
On Thu, 2024-11-07 at 17:47 -0300, Gustavo Sousa wrote:
> Quoting Gustavo Sousa (2024-11-07 17:14:36-03:00)
> > Quoting Luca Coelho (2024-11-07 16:23:06-03:00)
> >
> > > > Since we do not expect DC states (and consequently the wakelock
> > > > mechanism) to be enabled until DMC and DMC wakelock so
On Thu, 2024-11-07 at 17:22 -0300, Gustavo Sousa wrote:
> Quoting Gustavo Sousa (2024-11-07 17:14:36-03:00)
> > Quoting Luca Coelho (2024-11-07 16:23:06-03:00)
> > > On Thu, 2024-11-07 at 15:27 -0300, Gustavo Sousa wrote:
> > > > There is a bit of a chicken and egg situation where we depend on runt
== Series Details ==
Series: drm/i915/watermark: Modify latency programmed into PKG_C_LATENCY
URL : https://patchwork.freedesktop.org/series/141091/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_15656 -> Patchwork_141091v1
On Fri, 08 Nov 2024, "Golani, Mitulkumar Ajitkumar"
wrote:
>> -Original Message-
>> From: Intel-gfx On Behalf Of
>> Nemesa Garg
>> Sent: 08 November 2024 13:31
>> To: intel-gfx@lists.freedesktop.org
>> Cc: Garg, Nemesa ; kulka...@freedesktop.org;
>> Kulkarni, Vandita
>> Subject: [PATCH]
Making register macros platform or display version aware is not exactly
something I want to promote widely, but in this case it's the lesser of
two evils. hsw_chicken_trans_reg() is not pretty, and it doesn't have a
suitable home.
v2: Rebase
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/d
>> > That's the part that I'm not sure if I agree. if I remember from some
>> > experiments in the past,
>> > when you call to wake up the child, the parent will wakeup first anyway.
>> >
>> The child (mtd device) does not exist at this point of time.
>> To create MTD device, the partition table
== Series Details ==
Series: drm/i915/display: Add WA_14018221282
URL : https://patchwork.freedesktop.org/series/141087/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_15656 -> Patchwork_141087v1
Summary
---
**FAILURE
> -Original Message-
> From: Golani, Mitulkumar Ajitkumar
> Sent: Friday, November 8, 2024 1:47 PM
> To: Garg, Nemesa ; intel-gfx@lists.freedesktop.org
> Cc: Garg, Nemesa ; kulka...@freedesktop.org;
> Kulkarni, Vandita
> Subject: RE: [PATCH] drm/i915/display: Add WA_14018221282
>
>
>
Increase the latency programmed into PKG_C_LATENCY latency to be
a multiple of line time which is written into WM_LINETIME.
--v2
-Fix commit subject line [Sai Teja]
-Use individual DISPLAY_VER checks instead of range [Sai Teja]
-Initialize max_linetime [Sai Teja]
WA: 22020299601
Signed-off-by: Su
Hi Dave, Sima,
here's the drm-misc-fixes PR for this week. Apologies for being late.
Best regards
Thomas
drm-misc-fixes-2024-11-08:
Short summary of fixes pull:
imagination:
- Track PVR context per file
- Break ref-counting cycle
panel-orientation-quirks:
- Fix matching Lenovo Yoga Tab 3 X90F
> -Original Message-
> From: Intel-gfx On Behalf Of
> Nemesa Garg
> Sent: 08 November 2024 13:31
> To: intel-gfx@lists.freedesktop.org
> Cc: Garg, Nemesa ; kulka...@freedesktop.org;
> Kulkarni, Vandita
> Subject: [PATCH] drm/i915/display: Add WA_14018221282
>
> It was observed that th
It was observed that the first write to DKL DP Mode register
was not taking effect, hence rewrite this register.
Signed-off-by: Nemesa Garg
Signed-off-by: Kulkarni, Vandita
---
drivers/gpu/drm/i915/display/intel_ddi.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/g
61 matches
Mail list logo
