== Series Details ==
Series: drm/i915/guc: Test new GuC v70.35.1 for ADL-P, DG1, DG2, MTL, TGL
URL : https://patchwork.freedesktop.org/series/141037/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_15648 -> Patchwork_141037v1
== Series Details ==
Series: drm/i915/guc: Test new GuC v70.35.1 for ADL-P, DG1, DG2, MTL, TGL
URL : https://patchwork.freedesktop.org/series/141037/
State : warning
== Summary ==
Error: dim checkpatch failed
d44a9d257bd3 drm/i915/guc: Test new GuC v70.35.1 for ADL-P, DG1, DG2, MTL, TGL
-:7: W
== Series Details ==
Series: drm/i915/hdcp: Handle HDCP Line Rekeying for HDCP 1.4 (rev4)
URL : https://patchwork.freedesktop.org/series/140993/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_15648 -> Patchwork_140993v4
Summ
UAPI compatiblity version 1.16.1
This patch is for testing only. If testing is successful the binary
blobs will replace the major versioned '*_guc_70.bin' files for given
platforms.
Signed-off-by: Julia Filipchuk
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 12 ++--
1 file changed, 6
== Series Details ==
Series: drm/i915/dsi: Stop using pixel_format_from_register_bits() to parse VBT
URL : https://patchwork.freedesktop.org/series/141030/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_15648_full -> Patchwork_141030v1_full
=
TRANS_DDI_FUNC_CTL asks us to disable hdcp line rekeying when not in
hdcp 2.2 and we are not using an hdmi transcoder and it need to be
enabled when we are using an HDMI transcoder to enable HDCP 1.4.
We use intel_de_rmw cycles to update TRANS_DDI_FUNC_CTL register so
we cannot depend on the value
Hi Suraj,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on next-20241106]
[cannot apply to linus/master drm-intel/for-linux-next-fixes drm-tip/drm-tip
v6.12-rc6]
[If your patch is applied to the wrong git
== Series Details ==
Series: drm/i915/dsi: Stop using pixel_format_from_register_bits() to parse VBT
URL : https://patchwork.freedesktop.org/series/141030/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_15648 -> Patchwork_141030v1
===
== Series Details ==
Series: drm/i915/pps: Some PPS cleanups
URL : https://patchwork.freedesktop.org/series/141029/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_15648 -> Patchwork_141029v1
Summary
---
**FAILURE**
On Tue, Nov 05, 2024 at 09:16:00AM +0200, Vinod Govindapillai wrote:
> >From xe3 onwards, there is a provision to define and
> use min ddb and interim ddb allocations for async flip
> use case. Add the dbuf allocation status as part of
> i915_ddb_info as well to show if min or interim ddb
> is bein
== Series Details ==
Series: drm/i915/dmc_wl: Fixes and enablement for Xe3_LPD (rev2)
URL : https://patchwork.freedesktop.org/series/140282/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_15648 -> Patchwork_140282v2
Summary
On Tue, Nov 05, 2024 at 09:15:59AM +0200, Vinod Govindapillai wrote:
> From: Stanislav Lisovskiy
>
> Starting from xe3, hw now is capable of switching automatically to min
> ddb allocation(not using any extra blocks) or interim SAGV-adjusted
> allocation in case if async flip is used.
> For that
== Series Details ==
Series: drm/i915/pps: Some PPS cleanups
URL : https://patchwork.freedesktop.org/series/141029/
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/bitops.h:116:1: war
== Series Details ==
Series: drm/i915/pps: Some PPS cleanups
URL : https://patchwork.freedesktop.org/series/141029/
State : warning
== Summary ==
Error: dim checkpatch failed
7be5d99fa0f8 drm/i915/pps: Store the power cycle delay without the +1
6688c47ffde8 drm/i915/pps: Decouple pps delays fr
== Series Details ==
Series: drm/i915/dmc_wl: Fixes and enablement for Xe3_LPD (rev2)
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 (rev2)
URL : https://patchwork.freedesktop.org/series/140282/
State : warning
== Summary ==
Error: dim checkpatch failed
d03be180852b drm/i915/dmc_wl: Use i915_mmio_reg_offset() instead of reg.reg
8781d6c39354 drm/x
From: Ville Syrjälä
Introduce a proper VBT->enum mipi_dsi_pixel_format converter
instead of abusing pixel_format_from_register_bits() (whose
job is to parse the pixel format from some pre-ICL DSI
hardware register).
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dsi_vbt.c
From: Ville Syrjälä
Replace all the hand rolled *10 stuff with something a bit
more descriptive (msecs_to_pps_units()).
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_pps.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers
From: Ville Syrjälä
We currently lack a proper struct definition for the VBT power
squecing delays, and instead we use the same struct definition
(in intel_bios.h) for both the VBT layout and our driver side
state. Decouple those two things by moving the current struct
into intel_vbt_defs.h and a
From: Ville Syrjälä
Stop using the semi-random eDP spec T1,T3,... names for the
power sequencing delays, and instead call them by their human
readable names. Much easier to keep track what delay goes
where when you don't have to constantly cross reference against
the eDP spec.
Signed-off-by: Vil
From: Ville Syrjälä
We determine the "spec" eDP power sequencing delays
by refercing some max values from the eDP spec. Write
out each number from the spec explicitly instead
of precomputing the final number (that's the job of
the computer). Makes it a bit easier to see what the
supposed spec def
From: Ville Syrjälä
The code initializing the power sequencing delays is a bit
hard to follow. One confusing thing is that we keep doing the
+/-1 adjustment for the hardware register value in several places.
Simplify this a bit by doing the adjustment only when reading or
writing the actual regis
From: Ville Syrjälä
I just wanted to defuse the mess around struct
edp_power_seq, but ended up super confused by the PPS
delay initialization code and so ended up untangling
some of that mess as well.
Ville Syrjälä (8):
drm/i915/pps: Store the power cycle delay without the +1
drm/i915/pps: D
From: Ville Syrjälä
Add pps_units_to_msecs() as the counterpart to msecs_pps_units_to().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_pps.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_pps.c
b/drivers/gpu/
From: Ville Syrjälä
Reuse struct intel_pps_delays for the LVDS power
sequencing delays insteda of hand rolling it all.
Perhaps in the future we could reuse some of the
same PPS code for both LVDS and eDP (assuming we
can decouple the PPS code from intel_dp...).
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Now that we have pps_units_to_msecs(), get_delay() looks
rather pointless. Nuke it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_pps.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_
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
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
We should be able to use the DMC wakelock only if the display hardware
has support for DMC. We will add a check for that in an upcoming change.
Since info for DMC availability (HAS_DMC()) needs runtime device info,
move the call to intel_dmc_wl_init() to a place where we know we have
the hardware
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
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
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
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".
Signed-off-by: Gustavo Sousa
---
drivers/gpu/drm/i915/display/in
In order to be able to use the DMC wakelock, we also need to know that
the display hardware has support for DMC. For that, include HAS_DMC() in
the definition of HAS_DMC_WAKELOCK().
Cc: Jani Nikula
Signed-off-by: Gustavo Sousa
---
drivers/gpu/drm/i915/display/intel_display_device.h | 2 +-
1 fi
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,
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
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().
Signed-off-by: Gustavo Sousa
---
drivers/gpu/drm/i915/display/intel_dmc_wl.c | 21 +++--
1 file changed, 11 insertions(+),
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.
Gustavo Sousa (17):
drm/i915/dmc_wl: Use i915_mmio_reg_offset() instead of r
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.
Cc: Jani Nikula
Signed-off-by: Gustavo Sousa
---
drivers/gpu/drm/i915/display/intel_dmc_wl.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
d
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
Signed-off-by: Gustavo Sousa
---
.../drm/i915/display/i
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
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
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 Wed, 2024-11-06 at 09:29 -0300, Gustavo Sousa wrote:
> Quoting Luca Coelho (2024-11-06 09:23:32-03:00)
> > On Tue, 2024-11-05 at 10:42 -0300, Gustavo Sousa wrote:
> > > Quoting Luca Coelho (2024-11-01 09:58:33-03:00)
> > > > On Mon, 2024-10-21 at 19:27 -0300, Gustavo Sousa wrote:
> > > > > Allow
6.11-stable review patch. If anyone has any objections, please let me know.
--
From: Mitul Golani
commit eb53e5b933b9ff315087305b3dc931af3067d19c upstream.
AS SDP should be computed when VRR timing generator is also enabled.
Correct the compute condition to compute params of A
== Series Details ==
Series: drm/i915/hdcp: Handle HDCP Line Rekeying for HDCP 1.4 (rev3)
URL : https://patchwork.freedesktop.org/series/140993/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_15647 -> Patchwork_140993v3
Summ
== Series Details ==
Series: drm/i915/dp: demote source OUI read/write failure logging to debug
URL : https://patchwork.freedesktop.org/series/141016/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_15647 -> Patchwork_141016v1
On Mon, 2024-11-04 at 19:19 +0200, Jani Nikula wrote:
> Convert HAS_ULTRAJOINER() to struct intel_display. Do minimal drive-by
> conversions to struct intel_display in the callers while at it.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 10 ++
On Tue, 2024-11-05 at 09:44 -0300, Gustavo Sousa wrote:
> Quoting Luca Coelho (2024-11-01 09:24:08-03:00)
> > On Mon, 2024-10-21 at 19:27 -0300, Gustavo Sousa wrote:
> > > Bspec says that disabling dynamic DC states require taking the DMC
> > > wakelock to cause an DC exit before writing to DC_STAT
TRANS_DDI_FUNC_CTL asks us to disable hdcp line rekeying when not in
hdcp 2.2 and we are not using an hdmi transcoder and it need to be
enabled when we are using an HDMI transcoder to enable HDCP 1.4.
We use intel_de_rmw cycles to update TRANS_DDI_FUNC_CTL register so
we cannot depend on the value
== Series Details ==
Series: Refactor MST DSC Determination Policy (rev2)
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 (rev2)
URL : https://patchwork.freedesktop.org/series/140832/
State : warning
== Summary ==
Error: dim checkpatch failed
acf8c5365f33 drm/display/dsc: Refactor DRM MST DSC Determination Policy
-:11: WARNING:COMMIT_LOG_LONG_LINE
== Series Details ==
Series: Refactor MST DSC Determination Policy (rev2)
URL : https://patchwork.freedesktop.org/series/140832/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_15647 -> Patchwork_140832v2
Summary
---
*
On Wed, Nov 06, 2024 at 06:23:25PM +0200, Jani Nikula wrote:
> Commit 1f12d63a14d7 ("drm/i915/dp: Write the source OUI for non-eDP
> sinks as well") started writing source OUI for non-eDP sinks as well,
> increasing the possibilities of hitting read/write failures either due
> to the sink behaviour
Hi,
> -Original Message-
> From: Intel-gfx On Behalf Of
> Rodrigo Vivi
> Sent: Tuesday, 5 November 2024 4.34
> To: Coffin, Alexander ; Auld, Matthew
> ; Deak, Imre ; Syrjala, Ville
> ; Vishwanathapura, Niranjana
> ; andi.sh...@linux.intel.com
> Cc: intel-gfx@lists.freedesktop.org; Jani Ni
== Series Details ==
Series: series starting with [01/10] drm/xe: Remove double pageflip
URL : https://patchwork.freedesktop.org/series/141008/
State : failure
== Summary ==
Error: patch
https://patchwork.freedesktop.org/api/1.0/series/141008/revisions/1/mbox/ not
applied
Applying: drm/xe: R
On Mon, Nov 04, 2024 at 07:19:20PM +0200, Jani Nikula wrote:
> Convert HAS_GMBUS_BURST_READ() to struct intel_display. Do minimal
> drive-by conversions to struct intel_display in the callers while at it.
Reviewed-by: Rodrigo Vivi
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/di
On Mon, Nov 04, 2024 at 07:19:25PM +0200, Jani Nikula wrote:
> Convert HAS_ULTRAJOINER() to struct intel_display. Do minimal drive-by
> conversions to struct intel_display in the callers while at it.
Reviewed-by: Rodrigo Vivi
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display
On Mon, Nov 04, 2024 at 07:19:24PM +0200, Jani Nikula wrote:
> Convert HAS_HW_SAGV_WM() to struct intel_display. Do minimal drive-by
> conversions to struct intel_display in the callers while at it.
Reviewed-by: Rodrigo Vivi
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/
On Mon, Nov 04, 2024 at 07:19:23PM +0200, Jani Nikula wrote:
> Convert HAS_SAGV() to struct intel_display. Do minimal drive-by
> conversions to struct intel_display in the callers while at it.
Reviewed-by: Rodrigo Vivi
>
> Signed-off-by: Jani Nikula
> ---
> .../drm/i915/display/intel_display_
On Mon, Nov 04, 2024 at 07:19:22PM +0200, Jani Nikula wrote:
> Convert HAS_MBUS_JOINING() to struct intel_display. Do minimal drive-by
> conversions to struct intel_display in the callers while at it.
Reviewed-by: Rodrigo Vivi
>
> Signed-off-by: Jani Nikula
> ---
> .../drm/i915/display/intel_
On Mon, Nov 04, 2024 at 07:19:21PM +0200, Jani Nikula wrote:
> Convert HAS_IPS() to struct intel_display. Do minimal drive-by
> conversions to struct intel_display in the callers while at it.
Reviewed-by: Rodrigo Vivi
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/hsw_ips
> -Original Message-
> From: Nikula, Jani
> Sent: Wednesday, November 6, 2024 9:59 PM
> To: Kandpal, Suraj ; intel...@lists.freedesktop.org;
> intel-gfx@lists.freedesktop.org
> Cc: Roper, Matthew D ; Kandpal, Suraj
>
> Subject: Re: [PATCH] drm/i915/hdcp: Handle HDCP Line Rekeying for H
On Mon, Nov 04, 2024 at 07:19:16PM +0200, Jani Nikula wrote:
> Convert HAS_D12_PLANE_MINIMIZATION() to struct intel_display. Do minimal
> drive-by conversions to struct intel_display in the callers while at it.
Reviewed-by: Rodrigo Vivi
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i
On Mon, Nov 04, 2024 at 07:19:15PM +0200, Jani Nikula wrote:
> Identify discrete graphics separately in display, using the platform
> group mechanism. This enables dropping the dependency on i915_drv.h
> IS_DGFX() from display code.
>
> Start grouping platform groups separately in INTEL_DISPLAY_PL
On Mon, Nov 04, 2024 at 07:19:17PM +0200, Jani Nikula wrote:
> Convert HAS_4TILE() to struct intel_display. Do minimal drive-by
> conversions to struct intel_display in the callers while at it.
Reviewed-by: Rodrigo Vivi
>
> Signed-off-by: Jani Nikula
> ---
> .../gpu/drm/i915/display/intel_dis
On Mon, Nov 04, 2024 at 07:19:19PM +0200, Jani Nikula wrote:
> Convert HAS_DP20() to struct intel_display. Do minimal drive-by
> conversions to struct intel_display in the callers while at it.
Reviewed-by: Rodrigo Vivi
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_
On Mon, Nov 04, 2024 at 07:19:18PM +0200, Jani Nikula wrote:
> Convert HAS_DOUBLE_BUFFERED_M_N() to struct intel_display. Do minimal
> drive-by conversions to struct intel_display in the callers while at it.
Reviewed-by: Rodrigo Vivi
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915
On Mon, Nov 04, 2024 at 07:19:29PM +0200, Jani Nikula wrote:
> Identify mobile platforms separately in display, using the platform
> group mechanism. This enables dropping the dependency on i915_drv.h
> IS_MOBILE() from display code.
>
> Signed-off-by: Jani Nikula
> ---
> .../drm/i915/display/in
On Wed, 06 Nov 2024, Suraj Kandpal wrote:
> TRANS_DDI_FUNC_CTL asks us to disable hdcp line rekeying when not in
> hdcp 2.2 and we are not using an hdmi transcoder and it need to be
> enabled when we are using an HDMI transcoder to enable HDCP 1.4.
> We use intel_de_rmw cycles to update TRANS_DDI_
On Mon, Nov 04, 2024 at 04:24:24PM +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/dp_mst: Fix DDI function/DP2 config programming
> URL : https://patchwork.freedesktop.org/series/140732/
> State : failure
Thanks for the review, patchset is pushed to drm-intel-next.
The failures
Commit 1f12d63a14d7 ("drm/i915/dp: Write the source OUI for non-eDP
sinks as well") started writing source OUI for non-eDP sinks as well,
increasing the possibilities of hitting read/write failures either due
to the sink behaviour or hotplug or whatever.
Even before that, commit 3fb0501f0c07 ("drm
On Mon, 2024-11-04 at 19:19 +0200, Jani Nikula wrote:
> Convert HAS_GMBUS_BURST_READ() to struct intel_display. Do minimal
> drive-by conversions to struct intel_display in the callers while at it.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_display_device.h | 2 +-
On Thu, 2024-10-31 at 13:40 +0200, Imre Deak wrote:
> On Thu, Oct 31, 2024 at 12:49:22PM +0200, Luca Coelho wrote:
> > On Wed, 2024-10-30 at 21:23 +0200, Imre Deak wrote:
> > > On ADLP+ during modeset enabling configure the DDI function without
> > > enabling it for MST slave transcoders before pro
On Tue, 2024-11-05 at 12:17 +0200, Jani Nikula wrote:
> Convert intel_display_device.[ch] to struct intel_display, including
> callers, but excluding intel_display_device_probe() which will be
> handled in follow-up.
>
> v2: fix display->drm = display->drm goof-up
>
> Signed-off-by: Jani Nikula
== Series Details ==
Series: drm/i915/hdcp: Handle HDCP Line Rekeying for HDCP 1.4 (rev2)
URL : https://patchwork.freedesktop.org/series/140993/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_15642 -> Patchwork_140993v2
Summ
Quoting Jani Nikula (2024-11-06 06:25:52-03:00)
>On Tue, 05 Nov 2024, Gustavo Sousa wrote:
>> Quoting Gustavo Sousa (2024-10-22 08:03:39-03:00)
>>>Quoting Jani Nikula (2024-10-22 06:37:51-03:00)
On Mon, 21 Oct 2024, Gustavo Sousa wrote:
> In order to be able to use the DMC wakelock, we al
On Wed, 2024-11-06 at 16:06 +0200, Ville Syrjälä wrote:
> On Tue, Nov 05, 2024 at 11:08:40AM +0200, Jani Nikula wrote:
> > On Tue, 05 Nov 2024, Vinod Govindapillai
> > wrote:
> > > Avoid using struct drm_i915_private reference and use intel_display
> > > instead. This is in preparation for the re
On Wed, 2024-11-06 at 11:27 +0200, Jani Nikula wrote:
> Identify mobile platforms separately in display, using the platform
> group mechanism. This enables dropping the dependency on i915_drv.h
> IS_MOBILE() from display code.
>
> v2: Make snb_display static (kernel test robot)
>
> Signed-off-by:
On Mon, 2024-11-04 at 19:19 +0200, Jani Nikula wrote:
> Convert HAS_HW_SAGV_WM() to struct intel_display. Do minimal drive-by
> conversions to struct intel_display in the callers while at it.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_cursor.c | 5 ++-
> .../drm
6.11-stable review patch. If anyone has any objections, please let me know.
--
From: Matthew Auld
commit c55f79f317ab428ae6d005965bc07e37496f209f upstream.
On BMG-G21 we need to disable fbc due to complications around the WA.
v2:
- Try to handle with i915_drv.h and compat la
TRANS_DDI_FUNC_CTL asks us to disable hdcp line rekeying when not in
hdcp 2.2 and we are not using an hdmi transcoder and it need to be
enabled when we are using an HDMI transcoder to enable HDCP 1.4.
We use intel_de_rmw cycles to update TRANS_DDI_FUNC_CTL register so
we cannot depend on the value
On Mon, 2024-11-04 at 19:19 +0200, Jani Nikula wrote:
> Convert HAS_MBUS_JOINING() to struct intel_display. Do minimal drive-by
> conversions to struct intel_display in the callers while at it.
>
> Signed-off-by: Jani Nikula
> ---
> .../drm/i915/display/intel_display_device.h | 2 +-
> drive
On Tue, 2024-11-05 at 10:42 -0300, Gustavo Sousa wrote:
> Quoting Luca Coelho (2024-11-01 09:58:33-03:00)
> > On Mon, 2024-10-21 at 19:27 -0300, Gustavo Sousa wrote:
> > > Allow simpler syntax for defining entries for single registers in range
> > > tables. That makes them easier to type as well as
[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
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
Quoting Luca Coelho (2024-11-06 09:23:32-03:00)
>On Tue, 2024-11-05 at 10:42 -0300, Gustavo Sousa wrote:
>> Quoting Luca Coelho (2024-11-01 09:58:33-03:00)
>> > On Mon, 2024-10-21 at 19:27 -0300, Gustavo Sousa wrote:
>> > > Allow simpler syntax for defining entries for single registers in range
>>
On Wed, Nov 06, 2024 at 02:32:28PM +, Murthy, Arun R wrote:
> > -Original Message-
> > From: Ville Syrjälä
> > Sent: Wednesday, November 6, 2024 7:31 PM
> > To: Murthy, Arun R
> > Cc: intel...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org; dri-
> > de...@lists.freedesktop.org
After mcr_init_early, we need to be able to do VRAM and CCS probing
without hwconfig probe. Fortunately the relevant registers are all
instance 0, which fortunately means no dependencies on further initialisation
is required.
Signed-off-by: Maarten Lankhorst
Link:
https://patchwork.freedesktop.o
Now that we added the separate step of initialising GUC in
xe_gt_init_early, it should be ok to initialise the minimum during early
init, and the rest after allocations are allowed.
Signed-off-by: Maarten Lankhorst
Link:
https://patchwork.freedesktop.org/patch/msgid/20241105121857.17389-9-maarte
Add a 2-stage GuC init. An early one for everything that is needed
for VF, and a full one that loads GuC and is allowed to do allocations.
Signed-off-by: Maarten Lankhorst
Link:
https://patchwork.freedesktop.org/patch/msgid/20241105121857.17389-7-maarten.lankho...@linux.intel.com
Signed-off-by:
From: Maarten Lankhorst
---
drivers/gpu/drm/i915/display/intel_plane_initial.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_plane_initial.c
b/drivers/gpu/drm/i915/display/intel_plane_initial.c
index f0f4ec2b6cc98..77eb2b763be5e 100
This is already handled below by fixup_initial_plane_config.
Fixes: a8153627520a ("drm/i915: Try to relocate the BIOS fb to the start of
ggtt")
Cc: Ville Syrjälä
Reviewed-by: Vinod Govindapillai
Reviewed-by: Lucas De Marchi
Signed-off-by: Maarten Lankhorst
Link:
https://patchwork.freedesktop
Instead of 3 different calls, it should be safe to unify to a single
call now. This makes the init sequence cleaner, and display less
tangled.
Signed-off-by: Maarten Lankhorst
Link:
https://patchwork.freedesktop.org/patch/msgid/20241105121857.17389-5-maarten.lankho...@linux.intel.com
Signed-off-
We want to split up GUC init to an alloc and noalloc part to keep the
init path the same for VF and !VF as much as possible.
Everything in vf_guc_init should be done as early as possible, otherwise
VRAM probing becomes impossible.
Signed-off-by: Maarten Lankhorst
Link:
https://patchwork.freedes
No allocations should be done before we have had a chance to preserve
the display fb.
Signed-off-by: Maarten Lankhorst
Link:
https://patchwork.freedesktop.org/patch/msgid/20241105121857.17389-3-maarten.lankho...@linux.intel.com
Signed-off-by: Maarten Lankhorst,,,
---
drivers/gpu/drm/xe/xe_devi
Technically, I believe this means that xe_display_init_noirq and
xe_display_init_noaccel can be merged together now.
Signed-off-by: Maarten Lankhorst
Link:
https://patchwork.freedesktop.org/patch/msgid/20241105121857.17389-4-maarten.lankho...@linux.intel.com
Signed-off-by: Maarten Lankhorst,,,
We're changing the driver to have no interrupts during early init for
Xe, so we poll the PIPE_FRMSTMSMP counter instead.
Signed-off-by: Maarten Lankhorst
Link:
https://patchwork.freedesktop.org/patch/msgid/20241105121857.17389-2-maarten.lankho...@linux.intel.com
Signed-off-by: Maarten Lankhorst,
1 - 100 of 127 matches
Mail list logo