On 1/29/2024 11:25 PM, Imre Deak wrote:
Add a workaround to fix BS (blank start) to BS jitter fixes on non-UHBR
MST/FEC and UHBR links. Bspec doesn't provide an actual WA ID for this.
Bspec: 65448, 50054
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_display.c | 3 +++
LGTM.
Reviewed-by: Ankit Nautiyal
On 1/29/2024 11:25 PM, Imre Deak wrote:
Disable the workaround inserting an SF symbol between the last DSC EOC
symbol and the subsequent BS symbol. The WA is enabled by default -
based on the register's reset value - and Bspec requires disabling it
On 1/29/2024 11:25 PM, Imre Deak wrote:
Add a workaround to fix timing issues on links with DSC enabled -
presumedly related to the audio functionality.
Bspec requires enabling this workaround if audio is enabled on ADLP,
however Windows enables it whenever DSC is enabled ADLP onwards; follow
Hello Richard,
Hope you are doing well. I am Chaitanya from the Linux graphics team in Intel.
This mail is regarding a regression we are seeing in our CI runs[1] on
drm-tip[2] repository.
These are captured by gitlab issues[3].
We bisected the issue and have found the following commit to be
On 1/29/2024 11:25 PM, Imre Deak wrote:
Add a workaround to fix BS-BS jitter issues on MST links, aligning
DPT/DPTP MTPs.
Bspec: 50050, 55424
Signed-off-by: Imre Deak
LGTM.
As an aside, with these WAs do we also need to re-visit the transcoder
Data M and N values.
There is a note too
On 1/29/2024 11:25 PM, Imre Deak wrote:
Add a workaround to fix BS jitter issues on MST links if the HBLANK
period is less than 1 MTP. The WA applies only to UHBR rates while on
non-UHBR the specification requires disabling it explicitly - presumedly
because the register's reset value has the
On 1/30/2024 7:35 PM, Imre Deak wrote:
On Tue, Jan 30, 2024 at 07:18:25PM +0530, Nautiyal, Ankit K wrote:
On 1/29/2024 11:25 PM, Imre Deak wrote:
Add a workaround to fix BS (blank start) to BS jitter issues on MST
links when FEC is enabled. Neither Bspec requires this nor Windows
clears the
The following changes since commit 1a9518c73c4b54854c9cd8f416fd3b8f8e3456e7:
Merge branch 'mlimonci/amd-2024-01-30.2' into 'main' (2024-01-30 15:55:30
+)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-firmware guc_70.19.2
for you to fetch changes up to
On Mon, Jan 22, 2024 at 03:12:01PM +, Shankar, Uma wrote:
>
>
> > -Original Message-
> > From: Intel-gfx On Behalf Of Ville
> > Syrjala
> > Sent: Tuesday, January 16, 2024 1:27 PM
> > To: intel-gfx@lists.freedesktop.org
> > Subject: [PATCH v3 16/16] drm/i915: Annotate more of the
On Tue, Jan 16, 2024 at 09:56:35AM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> On MTL the GOP (for whatever reason) likes to bind its framebuffer
> high up in the ggtt address space. This can conflict with whatever
> ggtt_reserve_guc_top() is trying to do, and the result is that
>
On Tue, Jan 16, 2024 at 09:56:34AM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Currently we assume that we bind the BIOS fb exactly into the same
> ggtt address where the BIOS left it. That is about to change, and
> in order to keep intel_reuse_initial_plane_obj() working as intended
>
On Tue, Jan 16, 2024 at 09:56:33AM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The "io" address of an object is its dma address minus the
> region.start. Subtract the latter to make smem_start correct.
> The current code happens to work for genuine LMEM objects
> as LMEM
On Tue, Jan 16, 2024 at 09:56:32AM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> There's no reason the caller of intel_initial_plane_config() should
> have to loop over the CRTCs. Pull the loop into the function to
> make life simpler for the caller.
>
> Cc: Paz Zcharya
> Reviewed-by:
On Tue, Jan 16, 2024 at 09:56:31AM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Declutter initial_plane_vma() a bit by pulling the lmem and smem
> readout paths into their own functions.
>
> TODO: the smem path should still be fixed to get and validate
> the dma address from the
On Tue, Jan 16, 2024 at 09:56:30AM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The address we read from the PTE is a dma address, not a physical
> address. Rename the variable to say so.
>
> Cc: Paz Zcharya
> Reviewed-by: Andrzej Hajda
> Signed-off-by: Ville Syrjälä
Hi Ville,
On Mon, Jan 22, 2024 at 03:09:23PM +, Shankar, Uma wrote:
>
>
> > -Original Message-
> > From: Intel-gfx On Behalf Of Ville
> > Syrjala
> > Sent: Tuesday, January 16, 2024 1:26 PM
> > To: intel-gfx@lists.freedesktop.org
> > Subject: [PATCH v3 09/16] drm/i915: Fix MTL initial plane
On Mon, Jan 22, 2024 at 03:07:52PM +, Shankar, Uma wrote:
>
>
> > -Original Message-
> > From: Intel-gfx On Behalf Of Ville
> > Syrjala
> > Sent: Tuesday, January 16, 2024 1:26 PM
> > To: intel-gfx@lists.freedesktop.org
> > Subject: [PATCH v3 08/16] drm/i915: Fix region start during
On Tue, Jan 16, 2024 at 11:46:13AM +0100, Nirmoy Das wrote:
>
> On 1/16/2024 8:56 AM, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > When multiple pipes are enabled by the BIOS we try to read out each
> > in turn. But we do the readout for the second only after the inherited
> > vma for
On Thu, Jan 25, 2024 at 12:28:04PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> 0x108100 and 0x1080c0 have been around since snb. Rename the
> defines appropriately.
>
> v2: Rebase
>
> Cc: Paz Zcharya
> Reviewed-by: Andrzej Hajda
> Signed-off-by: Ville Syrjälä
Hi Ville,
Thank you
On Thu, Jan 25, 2024 at 12:27:36PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Now that the GGTT PTE updates go straight to GSMBASE (bypassing
> GTTMMADR) there should be no more risk of system hangs? So the
> "binder" (ie. update the PTEs via MI_UPDATE_GTT) is no longer
> necessary,
On Thu, Jan 25, 2024 at 12:27:14PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> On MTL accessing stolen memory via the BARs is somehow borked,
> and it can hang the machine. As a workaround let's bypass the
> BARs and just go straight to DSMBASE/GSMBASE instead.
>
> Note that on every
On Tue, Jan 16, 2024 at 11:23:37AM +0100, Nirmoy Das wrote:
>
> On 1/16/2024 8:56 AM, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Now that intel_memory_regions_hw_probe() prints out each and every
> > memory region there's no reason to have ad-hoc debugs to do similar
> > things
On Tue, Jan 16, 2024 at 11:20:37AM +0100, Nirmoy Das wrote:
>
> On 1/16/2024 8:56 AM, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Dump the details about every memory region into dmesg at probe time.
> > Avoids having to dig those out from random places when debugging stuff.
> >
> >
On Tue, Jan 16, 2024 at 11:23:00AM +0100, Nirmoy Das wrote:
>
> On 1/16/2024 8:56 AM, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > mem->region is a struct resource, but mem->io_start and
> > mem->io_size are not for whatever reason. Let's unify this
> > and convert the io stuff into a
With Xe2 always treat tile4 as if it was using flat ccs.
Signed-off-by: Juha-Pekka Heikkila
Reviewed-by: Mika Kahola
---
drivers/gpu/drm/i915/display/skl_universal_plane.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c
Display engine support ccs only with tile4, prevent other modifiers
from using compressed memory.
Signed-off-by: Juha-Pekka Heikkila
---
drivers/gpu/drm/xe/display/xe_fb_pin.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/xe/display/xe_fb_pin.c
Add BO bind time pat index member to xe_bo structure and store
pat index from xe_vma to xe_bo.
Signed-off-by: Juha-Pekka Heikkila
---
drivers/gpu/drm/xe/xe_bo_types.h | 12
drivers/gpu/drm/xe/xe_pt.c | 22 ++
2 files changed, 30 insertions(+), 4
From: Matthew Auld
In a future patch we need to be able to determine if a given pat_index
enables compression on xe2. Simplest is to annotate the PAT index table
with this information.
Signed-off-by: Matthew Auld
Reviewed-by: Juha-Pekka Heikkila
Signed-off-by: Juha-Pekka Heikkila
---
This patch set touches Xe and i915 drivers. On i915 is checked if
running on Xe2 hardware and enable framebuffer ccs decompression
unconditionally for tile4 framebuffers. On Xe driver with Xe2
hardware check if ccs compression is in use and behave accordingly;
attempt to use ccs with linear and
Quoting Ville Syrjälä (2024-01-26 07:26:52-03:00)
>On Tue, Jan 23, 2024 at 10:42:46AM -0300, Gustavo Sousa wrote:
>> Quoting Ville Syrjala (2024-01-23 06:00:51-03:00)
>> >From: Ville Syrjälä
>> >
>> >Move all DPFC_CHICKEN programming into intel_fbc_program_workarounds().
>> >We already have one
Quoting Coelho, Luciano (2024-01-26 06:24:29-03:00)
>On Wed, 2024-01-24 at 10:22 -0300, Gustavo Sousa wrote:
>> Hi, Luca!
>
>Hi Gustavo!
>
>
>> Quoting Luca Coelho (2024-01-24 05:52:29-03:00)
>> > The pipes that can be used for eDP MSO are limited to pipe A (and
>> > sometimes also pipe B) only
On 29.1.2024 14.02, Matthew Auld wrote:
On 26/01/2024 21:08, Juha-Pekka Heikkila wrote:
Display engine support ccs only with tile4, prevent other modifiers
from using compressed memory. Store pin time pat index to xe_bo.
Signed-off-by: Juha-Pekka Heikkila
---
On 29.1.2024 13.33, Matthew Auld wrote:
On 26/01/2024 21:08, Juha-Pekka Heikkila wrote:
Store pat index from xe_vma to xe_bo and check if bo was pinned
as framebuffer and verify pat index is not changing for pinned
framebuffers.
Signed-off-by: Juha-Pekka Heikkila
---
On 30/01/2024 16:12, Alex Deucher wrote:
Switch to using the new gem shared memory stats helper
rather than hand rolling it.
Link:
https://lore.kernel.org/all/20231207180225.439482-1-alexander.deuc...@amd.com/
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/i915/i915_drm_client.c | 2 +-
On 30/01/2024 16:12, Alex Deucher wrote:
Add a helper so that drm drivers can consistently report
shared status via the fdinfo shared memory stats interface.
In addition to handle count, show buffers as shared if they
are shared via dma-buf as well (e.g., shared with v4l or some
other
On 30/01/2024 16:12, Alex Deucher wrote:
Show buffers as shared if they are shared via dma-buf as well
(e.g., shared with v4l or some other subsystem).
v2: switch to gem helper
Link:
https://lore.kernel.org/all/20231207180225.439482-1-alexander.deuc...@amd.com/
Reviewed-by: Rob Clark (v1)
On 30/01/2024 16:12, Alex Deucher wrote:
Clarify the documentaiton in preparation for updated
helpers which check the handle count as well as whether
a dma-buf has been attached.
Link:
https://lore.kernel.org/all/20231207180225.439482-1-alexander.deuc...@amd.com/
Signed-off-by: Alex Deucher
On 1/30/24 11:12, Alex Deucher wrote:
Add a helper so that drm drivers can consistently report
shared status via the fdinfo shared memory stats interface.
In addition to handle count, show buffers as shared if they
are shared via dma-buf as well (e.g., shared with v4l or some
other subsystem).
Switch to using the new gem shared memory stats helper
rather than hand rolling it.
Link:
https://lore.kernel.org/all/20231207180225.439482-1-alexander.deuc...@amd.com/
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/i915/i915_drm_client.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Switch to using the new gem shared memory stats helper
rather than hand rolling it.
Link:
https://lore.kernel.org/all/20231207180225.439482-1-alexander.deuc...@amd.com/
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/xe/xe_drm_client.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Add a helper so that drm drivers can consistently report
shared status via the fdinfo shared memory stats interface.
In addition to handle count, show buffers as shared if they
are shared via dma-buf as well (e.g., shared with v4l or some
other subsystem).
Link:
Clarify the documentaiton in preparation for updated
helpers which check the handle count as well as whether
a dma-buf has been attached.
Link:
https://lore.kernel.org/all/20231207180225.439482-1-alexander.deuc...@amd.com/
Signed-off-by: Alex Deucher
---
Documentation/gpu/drm-usage-stats.rst |
Show buffers as shared if they are shared via dma-buf as well
(e.g., shared with v4l or some other subsystem).
v2: switch to gem helper
Link:
https://lore.kernel.org/all/20231207180225.439482-1-alexander.deuc...@amd.com/
Reviewed-by: Rob Clark (v1)
Signed-off-by: Alex Deucher
Cc: Rob Clark
Add shared stats. Useful for seeing shared memory.
v2: take dma-buf into account as well
v3: use the new gem helper
Link:
https://lore.kernel.org/all/20231207180225.439482-1-alexander.deuc...@amd.com/
Signed-off-by: Alex Deucher
Cc: Rob Clark
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c |
We had a request to add shared buffer stats to fdinfo for amdgpu and
while implementing that, Christian mentioned that just looking at
the GEM handle count doesn't take into account buffers shared with other
subsystems like V4L or RDMA. Those subsystems don't use GEM, so it
doesn't really matter
On Tue, Jan 30, 2024 at 07:18:25PM +0530, Nautiyal, Ankit K wrote:
>
> On 1/29/2024 11:25 PM, Imre Deak wrote:
> > Add a workaround to fix BS (blank start) to BS jitter issues on MST
> > links when FEC is enabled. Neither Bspec requires this nor Windows
> > clears the WA when disabling the output
On Tue, Jan 30, 2024 at 07:56:26AM +, Lin, Charlton wrote:
> On 1/27/2024 12:06 PM, Arun R Murthy wrote:
> > With DP2.1, multistream packetization and the underneth MST protocol
> > will be required for SST. So check for MSTM_CAP to see if MST is really
> > required and skip the MSTM_CTRL
On 1/29/2024 11:25 PM, Imre Deak wrote:
Add a workaround to fix BS (blank start) to BS jitter issues on MST
links when FEC is enabled. Neither Bspec requires this nor Windows
clears the WA when disabling the output - presumedly because
CHICKEN_MISC_3 gets reset after disabling the
== Series Details ==
Series: ALPM AUX Wake Configuration (rev3)
URL : https://patchwork.freedesktop.org/series/127954/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_14193 -> Patchwork_127954v3
Summary
---
Hi folks,
Here's a small but a different set of patches for making two relatively
minor changes to runtime PM API. I restarted version numbering as this is
meaningfully different from the previous set.
pm_runtime_get_if_active() loses its second argument as it only made sense
to have
There are two ways to opportunistically increment a device's runtime PM
usage count, calling either pm_runtime_get_if_active() or
pm_runtime_get_if_in_use(). The former has an argument to tell whether to
ignore the usage count or not, and the latter simply calls the former with
ign_usage_count set
ALPM Entry Check represents the number of lines needed to put the main link
to sleep and keep it in the sleep state before it can be taken out of the
SLEEP state (eDP requires the main link to be in the SLEEP state for a
minimum of 5us).
Bspec: 71477
v2: move display version check into
Lunarlake has some configurations in ALPM_CTL register for legacy ALPM as
well. Write these.
Bspec: 71477
v2: move version check to lnl_alpm_configure
Signed-off-by: Jouni Högander
---
drivers/gpu/drm/i915/display/intel_psr.c | 17 +
1 file changed, 17 insertions(+)
diff
Add new alpm_parameters struct into intel_psr for all calculated
alpm parameters.
v2: Move alpm_parameters struct definition to intel_psr struct
Signed-off-by: Jouni Högander
---
.../drm/i915/display/intel_display_types.h| 8 --
drivers/gpu/drm/i915/display/intel_psr.c | 28
Add ALPM register definitions for Lunar Lake.
v3:
- Fix ALPM_CTL2_A address
- Remove duplicate defines
v2:
- Use REG_BIT instead of BIT
- Add commit message
Cc: Jani Nikula
Signed-off-by: Jouni Högander
---
drivers/gpu/drm/i915/display/intel_psr_regs.h | 57 +++
1
This patch set is adding some missing AUX wake related configuration
for Lunar Lake.
Also ALPM parameters are moved to separate struct because amount of
parameters is about to increase in upcoming patches.
Additionally all ALPM related register definitions are added for
Lunar Lake.
v3:
- Fix
On Tue, 2024-01-16 at 15:07 +0200, Jani Nikula wrote:
> With few users for drm_err_printer(), it's still feasible to convert it
> to be device specific. Use drm_err() under the hood.
>
> While at it, make the prefix optional.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_print.c
On Tue, 2024-01-16 at 15:07 +0200, Jani Nikula wrote:
> Avoid forward declarations in subsequent changes, but separate this
> movement to an independent change.
>
> Signed-off-by: Jani Nikula
> ---
> include/drm/drm_print.h | 190
> 1 file changed, 95
On Tue, 2024-01-16 at 15:07 +0200, Jani Nikula wrote:
> Convert the remaining drm_debug_printer users over to drm_dbg_printer,
> as it can handle the cases without struct drm_device pointer, and also
> provides drm debug category and prefix support. Remove drm_debug_printer
> altogether.
>
>
On Tue, 2024-01-16 at 15:07 +0200, Jani Nikula wrote:
> Prefer the device specific debug printer.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/xe/xe_gt.c | 2 +-
> drivers/gpu/drm/xe/xe_gt_topology.c | 4 +++-
> drivers/gpu/drm/xe/xe_reg_sr.c | 2 +-
> 3 files changed, 5
On Tue, 2024-01-16 at 15:07 +0200, Jani Nikula wrote:
> There's already a related drm_printer. Use it to preserve the context
> instead of a separate pr_err().
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/gt/selftest_engine_heartbeat.c | 6 +++---
>
On Tue, 2024-01-16 at 15:07 +0200, Jani Nikula wrote:
> Prefer the device specific debug printer.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_display_driver.c | 3 ++-
> drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c| 3 ++-
>
On Tue, 2024-01-16 at 15:07 +0200, Jani Nikula wrote:
> Use the existing drm printer infrastructure instead of local macros.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/display/drm_dp_helper.c | 17 +---
> .../drm/i915/display/intel_crtc_state_dump.c | 5 ++--
>
On Tue, 2024-01-16 at 15:07 +0200, Jani Nikula wrote:
> Prefer the device specific debug printer.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_mode_config.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_mode_config.c
>
On Tue, 2024-01-16 at 15:07 +0200, Jani Nikula wrote:
> Prefer the device specific debug printer.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/display/drm_dp_mst_topology.c | 23 +++
> 1 file changed, 14 insertions(+), 9 deletions(-)
>
> diff --git
On Tue, 2024-01-16 at 15:07 +0200, Jani Nikula wrote:
> We've lacked a device specific debug printer. Add one. Take category
> into account too.
>
> __builtin_return_address(0) is inaccurate here, so don't use it. If
> necessary, we can later pass __func__ to drm_dbg_printer() by wrapping
> it
On Tue, 2024-01-30 at 08:28 +, Murthy, Arun R wrote:
>
>
> > -Original Message-
> > From: Intel-gfx On Behalf
> > Of Jouni
> > Högander
> > Sent: Friday, January 5, 2024 7:45 PM
> > To: intel-gfx@lists.freedesktop.org
> > Subject: [PATCH v2 4/4] drm/i915/alpm: Alpm aux wake
On 1/27/2024 12:46 PM, Suraj Kandpal wrote:
We see some monitors and docks report incorrect hdcp version
and capability in first few reads so we read rx_caps three times
before we conclude the monitor's or docks HDCP capability
Signed-off-by: Suraj Kandpal
---
On 1/27/2024 12:46 PM, Suraj Kandpal wrote:
Now that we have moved back to direct reads the additional timing
is not required hence this can be removed.
Signed-off-by: Suraj Kandpal
Add fixes tag. With that, this is:
Reviewed-by: Ankit Nautiyal
---
On 1/12/2024 1:11 PM, Suraj Kandpal wrote:
Now that we have moved back to direct reads the additional timing
is not required hence this can be removed.
Signed-off-by: Suraj Kandpal
Add fixes tag. With that this is,
Reviewed-by: Ankit Nautiyal
---
LGTM.
Reviewed-by: Ankit Nautiyal
On 1/27/2024 12:46 PM, Suraj Kandpal wrote:
Even for MST scenarios we need to do direct reads only on the
immediate downstream device the rest of the authentication is taken
care by that device. Remote reads will only be used to check
capability of the
On 1/27/2024 12:14 PM, Kandpal, Suraj wrote:
=
On 1/24/2024 6:50 PM, Nautiyal, Ankit K wrote:
On 1/12/2024 1:11 PM, Suraj Kandpal wrote:
Currently we are only checking capability of remote device and not
immediate downstream device but during capability check we need are
concerned with only
> -Original Message-
> From: Intel-gfx On Behalf Of Jouni
> Högander
> Sent: Friday, January 5, 2024 7:45 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH v2 4/4] drm/i915/alpm: Alpm aux wake configuration for lnl
>
> Lunarlake has some configurations in ALPM_CTL register for
73 matches
Mail list logo
