From: Ville Syrjälä
Annotate a few more of the failure paths on the initial
BIOS fb takeover to avoid having to guess why things
aren't working the way we expect.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_plane_initial.c | 9 +++--
1 file changed, 7
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
ggtt_reserve_guc_top() fails and then we proceed to explode when
trying to tear
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
we need to compare the original ggtt offset (called 'base' here)
as
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: Andrzej Hajda
Signed-off-by: Ville Syrjälä
---
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 region.start==0, but for LMEMBAR stolen objects
region.start!=0.
TODO: perhaps just set
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 pte as well
Cc: Paz Zcharya
Reviewed-by: Andrzej Hajda
Signed-off-by:
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ä
---
.../gpu/drm/i915/display/intel_plane_initial.c| 15 ---
1 file changed, 8
From: Ville Syrjälä
MTL stolen memory looks more like local memory, so use the
(now fixed) lmem path when doing the initial plane readout.
Cc: Paz Zcharya
Signed-off-by: Ville Syrjälä
---
.../drm/i915/display/intel_plane_initial.c| 25 +--
1 file changed, 18
From: Ville Syrjälä
On MTL the stolen region starts at offset 8MiB from the start of
LMEMBAR. The dma addresses are thus also offset by 8MiB. However the
mm_node/etc. is zero based, and i915_pages_create_for_stolen() will
add the appropriate region.start into the sg dma address. So when
we do
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 the first has been rebound into its original place (and thus
the PTEs have been rewritten). Unlike the BIOS we set some high
From: Ville Syrjälä
0x108100 and 0x1080c0 have been around since snb. Rename the
defines appropriately.
Cc: Paz Zcharya
Reviewed-by: Andrzej Hajda
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 4 ++--
drivers/gpu/drm/i915/gt/intel_ggtt.c| 2 +-
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, disable it.
My main worry with the MI_UPDATE_GTT are:
- only used on this
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 other platform this itself would hang the
machine, but on MTL the system
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.
Cc: Paz Zcharya
Reviewed-by: Andrzej Hajda
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_memory_region.c | 18
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 elsewhere.
Cc: Paz Zcharya
Reviewed-by: Andrzej Hajda
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c
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 struct resource as well.
Should make life a little less annoying when you don't have
juggle between two different approaches all
From: Ville Syrjälä
Attempt to fix the mess around stolen memory, especially on MTL
with it's special (and apparenly broken) not-actually-lmem stolen.
The series is made up of roughtly three parts:
1. General refactoring/debug improvement for mem regions
2. Deal with the broken BAR stuff on MTL
The GuC handles the WA, the KMD just needs to set the flag to enable
it on the appropriate platforms.
v2: Fixed CI checkpatch warning, alignment should match open parenthesis.
Signed-off-by: Karthik Poosa
---
drivers/gpu/drm/xe/xe_guc.c| 13 +
== Series Details ==
Series: drm/xe/guc: Enable WA 14018913170
URL : https://patchwork.freedesktop.org/series/128781/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_14124_full -> Patchwork_128781v1_full
Summary
---
== Series Details ==
Series: drm/xe/guc: Enable WA 14018913170 (rev2)
URL : https://patchwork.freedesktop.org/series/128781/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_14125 -> Patchwork_128781v2
Summary
---
== Series Details ==
Series: drm/xe/guc: Enable WA 14018913170 (rev2)
URL : https://patchwork.freedesktop.org/series/128781/
State : warning
== Summary ==
Error: dim checkpatch failed
9e0d8f82fc08 drm/xe/guc: Enable WA 14018913170
-:42: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open
The GuC handles the WA, the KMD just needs to set the flag to enable
it on the appropriate platforms.
v2: Fixed CI checkpatch warning, alignment should match open parenthesis.
Signed-off-by: Karthik Poosa
---
drivers/gpu/drm/xe/xe_guc.c| 13 +
== Series Details ==
Series: drm/xe/guc: Enable WA 14018913170
URL : https://patchwork.freedesktop.org/series/128781/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_14124 -> Patchwork_128781v1
Summary
---
**SUCCESS**
== Series Details ==
Series: drm/xe/guc: Enable WA 14018913170
URL : https://patchwork.freedesktop.org/series/128781/
State : warning
== Summary ==
Error: dim checkpatch failed
15010c5d7f05 drm/xe/guc: Enable WA 14018913170
-:40: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open
The GuC handles the WA, the KMD just needs to set the flag to enable
it on the appropriate platforms.
Signed-off-by: Karthik Poosa
---
drivers/gpu/drm/xe/xe_guc.c| 13 +
drivers/gpu/drm/xe/xe_guc_fwif.h | 1 +
drivers/gpu/drm/xe/xe_wa_oob.rules | 5 +
3 files
On Mon, 2024-01-15 at 15:00 +0200, Jani Nikula wrote:
> On Fri, 12 Jan 2024, Rodrigo Vivi wrote:
> > On Fri, Jan 12, 2024 at 07:31:51AM -0500, Hogander, Jouni wrote:
> > > On Wed, 2024-01-10 at 15:09 -0500, Rodrigo Vivi wrote:
> > > > On Tue, Jan 09, 2024 at 08:40:24PM +, Souza, Jose wrote:
>
On Thu, Jan 11, 2024 at 05:17:46PM +, Andri Yngvason wrote:
> mið., 10. jan. 2024 kl. 13:26 skrifaði Daniel Stone :
> > >
> > > This thing here works entirely differently, and I think we need somewhat
> > > new semantics for this:
> > >
> > > - I agree it should be read-only for userspace, so
== Series Details ==
Series: drm/i915/opregion: better abstractions (rev2)
URL : https://patchwork.freedesktop.org/series/128683/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_14124 -> Patchwork_128683v2
Summary
---
== Series Details ==
Series: drm/i915/opregion: better abstractions (rev2)
URL : https://patchwork.freedesktop.org/series/128683/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
On Fri, 12 Jan 2024, Radhakrishna Sripada
wrote:
> On Fri, Jan 12, 2024 at 12:17:25PM +0200, Jani Nikula wrote:
>> On Thu, 11 Jan 2024, Radhakrishna Sripada
>> wrote:
>> > On Thu, Jan 11, 2024 at 07:21:17PM +0200, Jani Nikula wrote:
>> >> Add a function to check the opregion ASLE presence
On Fri, 12 Jan 2024, Rodrigo Vivi wrote:
> On Fri, Jan 12, 2024 at 07:31:51AM -0500, Hogander, Jouni wrote:
>> On Wed, 2024-01-10 at 15:09 -0500, Rodrigo Vivi wrote:
>> > On Tue, Jan 09, 2024 at 08:40:24PM +, Souza, Jose wrote:
>> > > On Mon, 2024-01-08 at 17:18 -0500, Rodrigo Vivi wrote:
>>
On Tue, Dec 19, 2023 at 03:07:56PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Pull all the state swap stuff into its own function to declutter
> intel_atomic_commit() a bit.
>
> Note that currently the state swap is spread across both
> sides of the unprepare branch in
On Fri, Jan 12, 2024 at 06:47:10PM +0200, Ville Syrjälä wrote:
> On Mon, Jan 08, 2024 at 02:07:25PM +0200, Stanislav Lisovskiy wrote:
> > Handle only bigjoiner masters in skl_commit_modeset_enables/disables,
> > slave crtcs should be handled by master hooks. Same for encoders.
> > That way we can
On Fri, Jan 12, 2024 at 06:42:15PM +0200, Ville Syrjälä wrote:
> On Mon, Jan 08, 2024 at 02:07:24PM +0200, Stanislav Lisovskiy wrote:
> > Don't call enabled_bigjoiner_pipes twice, lets just move
> > intel_get_bigjoiner_config earlier, because it is anyway
> > calling same function.
> > Also
On Fri, Jan 12, 2024 at 06:25:05PM +0200, Ville Syrjälä wrote:
> On Mon, Jan 08, 2024 at 02:07:23PM +0200, Stanislav Lisovskiy wrote:
> > For validation purposes, it might be useful to be able to
> > force Bigjoiner mode, even if current dotclock/resolution
> > do not require that.
> > Lets add
35 matches
Mail list logo
