On Fri, Jan 03, 2025 at 02:58:17PM +0200, Abel Vesa wrote:
> LTTPRs operating modes are defined by the DisplayPort standard and the
> generic framework now provides a helper to switch between them, which
> is handling the explicit disabling of non-transparent mode and its
> disable->enable sequence
== Series Details ==
Series: drm/i915/dmc_wl: Track pipe interrupt registers
URL : https://patchwork.freedesktop.org/series/143104/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_15899 -> Patchwork_143104v1
Summary
---
== Series Details ==
Series: drm/i915/dmc_wl: Track pipe interrupt registers
URL : https://patchwork.freedesktop.org/series/143104/
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/asm/bit
On Fri, Jan 03, 2025 at 02:58:15PM +0200, Abel Vesa wrote:
> According to the DisplayPort standard, LTTPRs have two operating
> modes:
> - non-transparent - it replies to DPCD LTTPR field specific AUX
>requests, while passes through all other AUX requests
> - transparent - it passes through a
On Fri, Jan 03, 2025 at 02:58:18PM +0200, Abel Vesa wrote:
> Link Training Tunable PHY Repeaters (LTTPRs) are defined in DisplayPort
> 1.4a specification. As the name suggests, these PHY repeaters are
> capable of adjusting their output for link training purposes.
>
> According to the DisplayPort
Pipe interrupt registers live in their respective pipes' power wells,
which are below PG0. That means that they must also be tracked as
registers that are powered-off during dynamic DC states.
There are probably more ranges that we need to track down and add to the
powered_off_ranges. However, let
The current display IRQ code calls some IRQ-specific helpers that use
intel_uncore_*() MMIO functions instead of the display-specific ones.
Wrap those helpers in intel_de.h and use them to ensure that the proper
display-specific hooks (currently only DMC wakelock handling) are
called.
Signed-off-b
Most of MMIO accesses from intel_display_irq.c are currently done via
uncore_*() functions instead of the display-specific ones, namely
intel_de_*(). Because of that, DMC wakelock ends up being ignored and
some invalid MMIO accesses are performed while display is in dynamic DC
states. Thus, update
Pipe interrupt registers live in their respective pipes' power wells,
which are below PG0. That means that they must also be tracked as
registers that are powered-off during dynamic DC states.
For that, we first convert the display IRQ code to use display-specific
MMIO functions so that DMC wakelo
== Series Details ==
Series: drm/i915/dp: 128b/132b uncompressed SST (rev4)
URL : https://patchwork.freedesktop.org/series/142547/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_15898 -> Patchwork_142547v4
Summary
---
== Series Details ==
Series: drm/i915/dp: 128b/132b uncompressed SST (rev4)
URL : https://patchwork.freedesktop.org/series/142547/
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/dp: 128b/132b uncompressed SST (rev4)
URL : https://patchwork.freedesktop.org/series/142547/
State : warning
== Summary ==
Error: dim checkpatch failed
30657eb66215 drm/mst: remove mgr parameter and debug logging from
drm_dp_get_vc_payload_bw()
deadc628a4
On Fri, Jan 03, 2025 at 03:52:35PM +0200, Jani Nikula wrote:
> Add ACT handling for 128b/132b SST enable/disable.
>
> This is preparation for enabling 128b/132b SST. This path is not
> reachable yet.
>
> v2:
> - Check for !is_hdmi (Imre)
> - Add disable sequence (Imre)
>
> Signed-off-by: Jani Ni
On Fri, Jan 03, 2025 at 03:52:33PM +0200, Jani Nikula wrote:
> Write the payload allocation table for 128b/132b SST. Use VCPID 1 and
> start from slot 0, with dp_m_n.tu slots.
>
> This is preparation for enabling 128b/132b SST. This path is not
> reachable yet. Indeed, we don't yet compute TU for
On Fri, Jan 03, 2025 at 03:52:34PM +0200, Jani Nikula wrote:
> Write the DP2 specific VFREQ registers.
>
> This is preparation for enabling 128b/132b SST. This path is not
> reachable yet.
>
> v2: Check for !is_hdmi (Imre)
>
> Reviewed-by: Imre Deak # v1
Reviewed-by: Imre Deak
> Signed-off-b
The callers of mst_stream_find_vcpi_slots_for_bpp() don't need the
returned slots for anything. On the contrary, they need to jump through
hoops to just distinguish between success and failure. Just return 0
instead of slots from mst_stream_find_vcpi_slots_for_bpp() for success,
and simplify the ca
On Fri, 03 Jan 2025, Aditya Garg wrote:
> Hello maintainers
>
> This bug has been there for a long time, and hasn't been fixed yet. In case
> the Intel GPU is used as boot GPU on Apple T2 MacBooks, the bottom and right
> edges of the tty are no longer seen, thus making some text not visible.
>
>
intel_dp_mst_bw_overhead() doesn't need the connector. Remove the
parameter.
Reviewed-by: Imre Deak
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_dp_mst.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/
Enable basic 128b/132b SST functionality without compression. Reuse
intel_dp_mtp_tu_compute_config() to figure out the TU after we've
determined we need to use an UHBR rate.
It's slightly complicated as the M/N computation is done in different
places in MST and SST paths, so we need to avoid trash
128b/1232b SST will have mst_master_transcoder set and matching
cpu_transcoder. Ensure disable also for 128b/132b SST.
Reviewed-by: Imre Deak
Co-developed-by: Imre Deak
Signed-off-by: Imre Deak
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_ddi.c | 4 +++-
1 file changed, 3
Add ACT handling for 128b/132b SST enable/disable.
This is preparation for enabling 128b/132b SST. This path is not
reachable yet.
v2:
- Check for !is_hdmi (Imre)
- Add disable sequence (Imre)
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_ddi.c | 29
We'll only ever get here in MST mode from MST stream encoders; the
primary encoder's ->get_config() won't be called when we've detected
it's MST.
v2: Read mst_master_transcoder in 128b/132b SST path (Imre)
Reviewed-by: Imre Deak
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel
We'll want to distinguish 128b/132b SST and MST modes at state
readout. There's a catch, though. From the hardware perspective,
128b/132b SST and MST programming are pretty much the same. And we can't
really ask the sink at this point.
If we have more than one transcoder in 128b/132b mode associat
It's not very clearly specified, and the hardware bit is ill-named, but
128b/132b SST also needs the MST mode set in the DP_TP_CTL register.
This is preparation for enabling 128b/132b SST. This path is not
reachable yet.
Reviewed-by: Imre Deak
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i91
Write the DP2 specific VFREQ registers.
This is preparation for enabling 128b/132b SST. This path is not
reachable yet.
v2: Check for !is_hdmi (Imre)
Reviewed-by: Imre Deak # v1
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_ddi.c | 15 ++-
1 file changed, 14 in
Handle 128b/132b SST in intel_dp_mtp_tu_compute_config(). The remote
bandwidth overhead and time slot allocation are only relevant for MST;
SST only needs the local bandwidth and a check that 64 slots isn't
exceeded.
Reviewed-by: Imre Deak
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/dis
Write the payload allocation table for 128b/132b SST. Use VCPID 1 and
start from slot 0, with dp_m_n.tu slots.
This is preparation for enabling 128b/132b SST. This path is not
reachable yet. Indeed, we don't yet compute TU for 128b/132b SST.
v2: Handle drm_dp_dpcd_write_payload() failures (Imre)
128b/132b SST needs 128b/132b mode enabled in the TRANS_DDI_FUNC_CTL
register.
This is preparation for enabling 128b/132b SST. This path is not
reachable yet.
v2: Use the MST path instead of SST to also set transport select (Imre)
Reviewed-by: Imre Deak
Signed-off-by: Jani Nikula
---
drivers/
Extract intel_dp_mtp_tu_compute_config() for figuring out the TU. Move
the link configuration and mst state access to the callers. This will be
easier to adapt to 128b/132b SST.
v2: Don't add SST stuff here yet
Reviewed-by: Imre Deak
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/
The struct drm_dp_mst_topology_mgr *mgr parameter is only used for debug
logging in case the passed in link rate or lane count are zero. There's
no further error checking as such, and the function returns 0.
There should be no case where the parameters are zero. The returned
value is generally use
intel_dp_mst_compute_m_n() doesn't need the connector. Remove the
parameter.
Reviewed-by: Imre Deak
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_dp_mst.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/dri
The crtc_state->pbn member is only used as a temporary variable within
mst_stream_find_vcpi_slots_for_bpp(). Remove it as unnecessary.
Suggested-by: Imre Deak
Reviewed-by: Imre Deak
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display_types.h | 2 --
drivers/gpu/drm/i915/d
This is v4 of [1], enabling uncompressed 128b/132b UHBR SST.
Address review comments from Imre.
[1] https://lore.kernel.org/r/cover.1734643485.git.jani.nik...@intel.com
Jani Nikula (16):
drm/mst: remove mgr parameter and debug logging from
drm_dp_get_vc_payload_bw()
drm/i915/mst: drop co
> -Original Message-
> From: Kandpal, Suraj
> Sent: Friday, January 3, 2025 2:15 PM
> To: intel...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org
> Cc: Bhadane, Dnyaneshwar ; Kandpal,
> Suraj
> Subject: [PATCH] Revert "drm/i915/hdcp: Don't enable HDCP1.4 directly from
> check_l
On 12/11/2024 2:40 AM, Ville Syrjala wrote:
From: Ville Syrjälä
Now that we know how to issue the push with the DSB we can
allow the DSB to drive the commits even when VRR is active.
Signed-off-by: Ville Syrjälä
Reviewed-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_disp
On 12/11/2024 2:40 AM, Ville Syrjala wrote:
From: Ville Syrjälä
We have at least two options for how to do the
TRANS_PUSH_SEND + commit completion signalling
with the DSB:
Option A)
1. trigger TRANS_PUSH_SEND
2. wait for "safe window"
3. signal the interrupt
In this cases step 2 shoul
On 12/11/2024 2:40 AM, Ville Syrjala wrote:
From: Ville Syrjälä
Plumb the DSB down into intel_vrr_send_push() so that we can
perform the opration on the DSB.
TRANS_PUSH, being a transcoder register, needs non-posted writes
to make it through.
Signed-off-by: Ville Syrjälä
Reviewed-by: Ank
On 12/11/2024 2:40 AM, Ville Syrjala wrote:
From: Ville Syrjälä
On ICL/TGL the VRR hardware injects an extra scanline just after
vactive. This essentically behaves the same as an extra line of
vblank delay, except it only appears in this one specific spot.
Considee our DSB interrupt signalli
On 12/11/2024 2:40 AM, Ville Syrjala wrote:
From: Ville Syrjälä
Turns out that TGL needs its vmin/vmax/flipling adjusted based
typo: flipline
on the vblank delay, otherwise the hardware pushes the vtotals
fiurther out. Make it so.
Typo: further
Signed-off-by: Ville Syrjälä
LGTM.
Revi
Quoting Jani Nikula (2025-01-03 08:11:59-03:00)
>On Tue, 31 Dec 2024, Gustavo Sousa wrote:
>> Quoting Jani Nikula (2024-12-31 08:45:56-03:00)
>>>On Tue, 24 Dec 2024, Gustavo Sousa wrote:
>>>I understand you're following patterns from elsewhere in the driver. But
>>
>> Correct.
>>
>>>I've always w
On 12/11/2024 2:40 AM, Ville Syrjala wrote:
From: Ville Syrjälä
Apparently on ICL/TGL need the annoying vmin adjustemnt. On
typo: adjustement
ADL+ we can program flipling==vmin and the hardware actually
typo: flipline
respects that properly.
I had tried to remove this earlier for ADL+,
On 12/11/2024 2:40 AM, Ville Syrjala wrote:
From: Ville Syrjälä
Introduce a VRR specific function for determining the current
vblank delay. Currently thus will give the same answer as
intel_mode_vblank_delay() but that will change later.
Signed-off-by: Ville Syrjälä
Reviewed-by: Ankit Nau
On 12/11/2024 2:40 AM, Ville Syrjala wrote:
From: Ville Syrjälä
Declutter intel_crtc_update_active_timings() a bit by
moving the code that determines the timings into a separate
function.
Signed-off-by: Ville Syrjälä
Reviewed-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel
On 12/11/2024 2:39 AM, Ville Syrjala wrote:
From: Ville Syrjälä
We have approximately two copies of pre_commit_crtc_state(),
one in the DSB code, the other in the vblank evasion code.
Combine them into one. The slight difference between the two
is that vblank evasion doesn't have a full atomi
On 12/11/2024 2:39 AM, Ville Syrjala wrote:
From: Ville Syrjälä
Dump the calculated vmin/vmax vtotal values in addition to the
raw vmin/vmax/flipline values. Makes it much easier to see what
kind of scanline values we should be expecting from the hardware.
Signed-off-by: Ville Syrjälä
Rev
On Thu, 02 Jan 2025, Imre Deak wrote:
> On Thu, Dec 19, 2024 at 11:34:05PM +0200, Jani Nikula wrote:
>> Enable basic 128b/132b SST functionality without compression. Reuse
>> intel_dp_mtp_tu_compute_config() to figure out the TU after we've
>> determined we need to use an UHBR rate.
>>
>> It's sl
On 12/11/2024 2:39 AM, Ville Syrjala wrote:
From: Ville Syrjälä
Extract the code that computes the hardware centric view
of the vblank delay into a helper. We;ll need a slightly
typo: we'll
different variant for VRR soon.
Signed-off-by: Ville Syrjälä
Reviewed-by: Ankit Nautiyal
-
On 12/11/2024 2:39 AM, Ville Syrjala wrote:
From: Ville Syrjälä
When looking at raw hardware scanline numbers it's helpful to
remember what the offset between the hardware values and our
more human readable numbers should be. Include that in the state dump.
Signed-off-by: Ville Syrjälä
Re
On 12/11/2024 2:39 AM, Ville Syrjala wrote:
From: Ville Syrjälä
While one can look at the crtc timings to determine the actual
vblank dealy, it seems nicer to provide a more human readable
dump of it to ease our lives.
Signed-off-by: Ville Syrjälä
Reviewed-by: Ankit Nautiyal
---
dri
On Thu, 02 Jan 2025, Imre Deak wrote:
> On Thu, Dec 19, 2024 at 11:34:02PM +0200, Jani Nikula wrote:
>> We'll want to distinguish 128b/132b SST and MST modes at state
>> readout. There's a catch, though. From the hardware perspective,
>> 128b/132b SST and MST programming are pretty much the same.
On 12/11/2024 2:39 AM, Ville Syrjala wrote:
From: Ville Syrjälä
Try to dump all the important stuff relating to the display timings
in one spot.
Signed-off-by: Ville Syrjälä
Reviewed-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_crtc_state_dump.c | 6 +++---
1 file chan
On 12/11/2024 2:39 AM, Ville Syrjala wrote:
From: Ville Syrjälä
On ICL/TGL vmin/vmax/flipline won't actually match the
vtotal valeues (currently they do, but that is wrong and
typo: values
needs to be fixed). Add a few helpers that will compute the
actual vtotal values for us.
Signed-of
On 12/11/2024 2:39 AM, Ville Syrjala wrote:
From: Ville Syrjälä
Include the headers in the correct alphabetical order.
Signed-off-by: Ville Syrjälä
Reviewed-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_vrr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -
On 12/11/2024 2:39 AM, Ville Syrjala wrote:
From: Ville Syrjälä
Make sure we have enough vblank for the computed vblank delay.
Supposedly we'd reject things anyway later if this gets violated,
but it seems niver to do some basic sanity checks early just
typo: nicer
so we can't be sure the b
On 12/11/2024 2:39 AM, Ville Syrjala wrote:
From: Ville Syrjälä
Pull the vblank delay computation into a separate function.
We'll need more logic here soon and we don't want to pollute
intel_crtc_compute_config() with low level details.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i91
On Tue, 31 Dec 2024, Gustavo Sousa wrote:
> Quoting Jani Nikula (2024-12-31 08:45:56-03:00)
>>On Tue, 24 Dec 2024, Gustavo Sousa wrote:
>>I understand you're following patterns from elsewhere in the driver. But
>
> Correct.
>
>>I've always wondered why we use a mixture of atomic state, global sta
On Tue, Dec 17, 2024 at 09:36:52PM +0530, Vignesh Raman wrote:
> Uprev IGT to the latest version and update expectation files.
>
> Signed-off-by: Vignesh Raman
> ---
>
> v1:
> - Pipeline link -
> https://gitlab.freedesktop.org/vigneshraman/linux/-/pipelines/1327810
> Will update the flake
== Series Details ==
Series: Revert "drm/i915/hdcp: Don't enable HDCP1.4 directly from check_link"
(rev2)
URL : https://patchwork.freedesktop.org/series/142871/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_15896 -> Patchwork_142871v2
=
On Fri, 03 Jan 2025, Suraj Kandpal wrote:
> A small optimization and cleanup for mtl_port_buf_ctl_program function
> which lets use intel_de_rmw instead of a intel_de_read and
> intel_de_write.
>
> Signed-off-by: Suraj Kandpal
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/inte
On Fri, 03 Jan 2025, Suraj Kandpal wrote:
> Use intel display instead of drm_i915_private in
> mtl_ddi_prepare_link_retrain & mtl_port_buf_ctl_program
> functions.
>
> Signed-off-by: Suraj Kandpal
This is a good direction, but I'd aim higher than just a few
functions...
Reviewed-by: Jani Nikula
On Fri, 03 Jan 2025, Ankit Nautiyal wrote:
> Currently, when bandwidth is insufficient for a given mode, we attempt
> to use DSC. This is indicated by a debug print, followed by a check for
> DSC support.
>
> The debug message states that we are trying DSC, but DSC might not be
> supported, which
+intel_de_write(display, DP_MIN_HBLANK_CTL(trans),
>> + pipe_config->min_hblank);
>> +
>> enable_bs_jitter_was(pipe_config);
>>
>> intel_ddi_enable_transcoder_func(encoder, pipe_config); diff --git
>> a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
>> index
>> 765e6c0528fb0b5a894395b77a5edbf0b0c80009..7bd783931199e2e5c7e1
>> 5358bb4d2c904f28176a 100644
>> --- a/drivers/gpu/drm/i915/i915_reg.h
>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>> @@ -3197,6 +3197,10 @@
>> #define _TRANS_DP2_VFREQLOW_D 0x630a8
>> #define TRANS_DP2_VFREQLOW(trans)
>> _MMIO_TRANS(trans, _TRANS_DP2_VFREQLOW_A,
>> _TRANS_DP2_VFREQLOW_B)
>>
>> +#define _DP_MIN_HBLANK_CTL_A0x600ac
>> +#define _DP_MIN_HBLANK_CTL_B0x610ac
>> +#define DP_MIN_HBLANK_CTL(trans)_MMIO_TRANS(trans,
>> _DP_MIN_HBLANK_CTL_A, _DP_MIN_HBLANK_CTL_B)
>> +
>> /* SNB eDP training params */
>> /* SNB A-stepping */
>> #define EDP_LINK_TRAIN_400MV_0DB_SNB_A (0x38 << 22)
>>
>> ---
>> base-commit: 048d83e7f9dae81c058d31c371634c1c317b3013
>> change-id: 20250103-hblank-cd7e78cbe178
>>
>> Best regards,
>> --
>> Arun R Murthy
>
--
Jani Nikula, Intel
== Series Details ==
Series: drm/i915/dp: Guarantee a minimum HBlank time (rev6)
URL : https://patchwork.freedesktop.org/series/139267/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_15896 -> Patchwork_139267v6
Summary
-
== Series Details ==
Series: drm/i915/gt: Prefer IS_ENABLED() instead of defined() on config option
(rev2)
URL : https://patchwork.freedesktop.org/series/143083/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_15896 -> Patchwork_143083v2
This reverts commit 483f7d94a0453564ad9295288c0242136c5f36a0.
This needs to be reverted since HDCP even after updating the connector
state HDCP property we don't reenable HDCP until the next commit
in which the CP Property is set causing compliance to fail.
--v2
-Fix build issue [Dnyaneshwar]
Sig
> -Original Message-
> From: Intel-xe On Behalf Of Suraj
> Kandpal
> Sent: Friday, December 20, 2024 10:32 AM
> To: intel...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org
> Cc: Nautiyal, Ankit K ; Kandpal, Suraj
>
> Subject: [PATCH] Revert "drm/i915/hdcp: Don't enable HDCP1.4
== Series Details ==
Series: drm/i915/dp: Guarantee a minimum HBlank time (rev6)
URL : https://patchwork.freedesktop.org/series/139267/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_15896 -> Patchwork_139267v6
Summary
-
== Series Details ==
Series: drm/i915/dp: Guarantee a minimum HBlank time (rev6)
URL : https://patchwork.freedesktop.org/series/139267/
State : warning
== Summary ==
Error: dim checkpatch failed
b95ef576d6a6 drm/i915/dp: Guarantee a minimum HBlank time
-:70: WARNING:LONG_LINE: line length of 1
== Series Details ==
Series: drm/i915/gt: Prefer IS_ENABLED() instead of defined() on config option
URL : https://patchwork.freedesktop.org/series/143083/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_15896 -> Patchwork_143083v1
69 matches
Mail list logo
