Dear Arunprivin,
Am 16.03.22 um 07:49 schrieb Arunpravin Paneer Selvam:
On 15/03/22 9:14 pm, Paul Menzel wrote:
Am 15.03.22 um 16:42 schrieb Arunpravin:
On 15/03/22 2:35 pm, Paul Menzel wrote:
Am 15.03.22 um 10:01 schrieb Arunpravin:
On 15/03/22 1:49 pm, Paul Menzel wrote:
Am 14.0
== Series Details ==
Series: i915: General multicast steering updates (rev2)
URL : https://patchwork.freedesktop.org/series/101367/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11365_full -> Patchwork_22574_full
Summary
--
Confirmed this is a regression caused by the patch. Will debug further.
From: Summers, Stuart
Sent: Tuesday, March 15, 2022 8:23 PM
To: intel-gfx@lists.freedesktop.org; Yang, Fei
Subject: Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: avoid concurrent
writes to aux_inv (rev5)
On Sat, 2022-
>> @@ -157,6 +163,9 @@ int gen11_emit_flush_rcs(struct i915_request *rq,
>> u32 mode)
>> intel_ring_advance(rq, cs);
>> }
>>
>> +/* hsdes: 1809175790. No fixup needed for gen11 rcs */
>> +rq->aux_inv_fixup = NULL;
>
> This is a little ugly to me. Can we just set this to
On Fri, 2022-03-04 at 14:14 -0800, fei.y...@intel.com wrote:
> From: Fei Yang
>
> GPU hangs have been observed when multiple engines write to the
> same aux_inv register at the same time. To avoid this each engine
> should only invalidate its own auxiliary table. The function
> gen12_emit_flush_x
== Series Details ==
Series: Add GuC Error Capture Support
URL : https://patchwork.freedesktop.org/series/101410/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11365_full -> Patchwork_22581_full
Summary
---
**FAILURE
On Sat, 2022-03-05 at 09:36 +, Patchwork wrote:
Patch Details
Series: drm/i915: avoid concurrent writes to aux_inv (rev5)
URL:https://patchwork.freedesktop.org/series/100772/
State: failure
Details:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22492/index.html
CI Bug Log - ch
== Series Details ==
Series: drm/i915/display/: Refactor hsw_crtc_enable for bigjoiner cleanup
URL : https://patchwork.freedesktop.org/series/101409/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11365_full -> Patchwork_22580_full
==
On Tue, Mar 15, 2022 at 05:10:28PM -0700, Matt Roper wrote:
> On Tue, Mar 15, 2022 at 11:39:41PM +, Patchwork wrote:
> > == Series Details ==
> >
> > Series: i915: General multicast steering updates (rev2)
> > URL : https://patchwork.freedesktop.org/series/101367/
> > State : failure
> >
>
== Series Details ==
Series: Add GuC Error Capture Support
URL : https://patchwork.freedesktop.org/series/101410/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11365 -> Patchwork_22581
Summary
---
**SUCCESS**
No r
== Series Details ==
Series: drm/i915: More DRRS work (rev2)
URL : https://patchwork.freedesktop.org/series/101390/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11365_full -> Patchwork_22579_full
Summary
---
**FAILU
== Series Details ==
Series: Add GuC Error Capture Support
URL : https://patchwork.freedesktop.org/series/101410/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: Add GuC Error Capture Support
URL : https://patchwork.freedesktop.org/series/101410/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
287e39ce2771 drm/i915/guc: Update GuC ADS size for error capture lists
-:40: WARNING:FILE_PATH_CHANGES: added, moved o
For the sake of better code readibility, change previous
relay logging function names with "capture_logs" to
"copy_debug_logs" to differentiate from error capture
functions that will use a different region of the same buffer.
Signed-off-by: Alan Previn
Reviewed-by: Matthew Brost
---
drivers/gpu
Add the ability for runtime allocation and freeing of
steered register list extentions that depend on the
detected HW config fuses.
Signed-off-by: Alan Previn
Reviewed-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h | 9 +
.../gpu/drm/i915/gt/uc/intel_guc_capture.c
Add intel_guc_capture_output_min_size_est function to
provide a reasonable minimum size for error-capture
region before allocating the shared buffer.
Signed-off-by: Alan Previn
Reviewed-by: Matthew Brost
---
.../gpu/drm/i915/gt/uc/intel_guc_capture.c| 48 +++
.../gpu/drm/i91
In the rare but possible scenario where we are in the midst of
multiple GuC error-capture (and engine reset) events and the
user also triggers a forced full GT reset or the internal watchdog
triggers the same, intel_guc_submission_reset_prepare's call
to flush_work(&guc->ct.requests.worker) can cau
Add GuC's error capture output structures and definitions as how
they would appear in GuC log buffer's error capture subregion after
an error state capture G2H event notification.
Signed-off-by: Alan Previn
Reviewed-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h | 47 ++
Abstract out a Gen9 register list as the default for all other
platforms we don't yet formally support GuC submission on.
Signed-off-by: Alan Previn
Reviewed-by: Umesh Nerlige Ramappa
---
.../gpu/drm/i915/gt/uc/intel_guc_capture.c| 82 +--
1 file changed, 59 insertions(+), 2
Add a flags parameter through all of the coredump creation
functions. Add a bitmask flag to indicate if the top
level gpu_coredump event is triggered in response to
a GuC context reset notification.
Using that flag, ensure all coredump functions that
read or print mmio-register values related to w
Add device specific tables and register lists to cover different engines
class types for GuC error state capture for XE_LP products.
Signed-off-by: Alan Previn
Reviewed-by: Umesh Nerlige Ramappa
---
.../gpu/drm/i915/gt/uc/intel_guc_capture.c| 116 ++
drivers/gpu/drm/i915/gt/
GuC log buffer regions for debug-log-events, crash-dumps and
error-state-capture are all part of a single bo allocation that
also includes the guc_log_buffer_state structures. Now that we
support it, increase the size allocation for error-capture.
Since the error-capture region is accessed at non-
Print the GuC captured error state register list (string names
and values) when gpu_coredump_state printout is invoked via
the i915 debugfs for flushing the gpu error-state that was
captured prior.
Since GuC could have reported multiple engine register dumps
in a single notification event, parse t
- Upon the G2H Notify-Err-Capture event, parse through the
GuC Log Buffer (error-capture-subregion) and generate one or
more capture-nodes. A single node represents a single "engine-
instance-capture-dump" and contains at least 3 register lists:
global, engine-class and engine-instance. An
Add additional DG2 registers for GuC error state capture.
Signed-off-by: Alan Previn
Reviewed-by: Umesh Nerlige Ramappa
---
.../gpu/drm/i915/gt/uc/intel_guc_capture.c| 80 ++-
1 file changed, 77 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc
This series:
1. Enables support of GuC to report error-state-capture
using a list of MMIO registers the driver registers
and GuC will dump, log and notify right before a GuC
triggered engine-reset event.
2. Updates the ADS blob creation to register said lists
of global, engi
Update GuC ADS size allocation to include space for
the lists of error state capture register descriptors.
Then, populate GuC ADS with the lists of registers we want
GuC to report back to host on engine reset events. This list
should include global, engine-class and engine-instance
registers for e
I shall fix the length line warnings.
However i shall not fix the " WARNING:OOM_MESSAGE: Possible unnecessary
'out of memory' message" warnings for reasons as stated because the
caller function is not reporting the OOM error and because if such an
error occurs, the ADS function that populates
== Series Details ==
Series: drm/i915/display/adlp: More voltage swing table updates
URL : https://patchwork.freedesktop.org/series/101404/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11365_full -> Patchwork_22578_full
Su
.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Alan-Previn/Add-GuC-Error-Capture-Support/20220315-010958
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: i386-allyesconfig
(https://download.01.org/0day-ci/archive/20220315/202203151007.myugtwwo-...@intel.
== Series Details ==
Series: drm/i915/display/: Refactor hsw_crtc_enable for bigjoiner cleanup
URL : https://patchwork.freedesktop.org/series/101409/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11365 -> Patchwork_22580
Su
== Series Details ==
Series: series starting with [CI,1/7] drm/i915/lmem: don't treat small BAR as
an error
URL : https://patchwork.freedesktop.org/series/101398/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11365_full -> Patchwork_22576_full
On Tue, Mar 15, 2022 at 11:39:41PM +, Patchwork wrote:
> == Series Details ==
>
> Series: i915: General multicast steering updates (rev2)
> URL : https://patchwork.freedesktop.org/series/101367/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_11365_full -> Patchwor
On Mon, Mar 14, 2022 at 04:42:03PM -0700, Matt Roper wrote:
Upcoming patches will need to steer writes to multicast registers as
well as reading them.
Although the setting of the 'multicast' bit should only really matter
for write operations (reads always operate in a unicast manner and give
us
On Mon, Mar 14, 2022 at 04:42:02PM -0700, Matt Roper wrote:
From: Daniele Ceraolo Spurio
GuC has its own steering mechanism and can't use the default set by i915,
so we need to provide the steering information that the FW will need to
save/restore registers while processing an engine reset. The
== Series Details ==
Series: i915: General multicast steering updates (rev2)
URL : https://patchwork.freedesktop.org/series/101367/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11365_full -> Patchwork_22574_full
Summary
--
This patch abstracts pieces of hsw_crtc_enable corresponding to different
Bspec enable sequence steps into separate functions.
This helps to call them in a specific order for bigjoiner master/slave
in a cleaner fashion.
Cc: Ville Syrjälä
Cc: Animesh Manna
Signed-off-by: Manasi Navare
---
drive
== Series Details ==
Series: Add GuC Error Capture Support (rev2)
URL : https://patchwork.freedesktop.org/series/101348/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11365_full -> Patchwork_22573_full
Summary
---
**
== Series Details ==
Series: drm/i915: More DRRS work (rev2)
URL : https://patchwork.freedesktop.org/series/101390/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11365 -> Patchwork_22579
Summary
---
**SUCCESS**
No
== Series Details ==
Series: drm/i915: More DRRS work (rev2)
URL : https://patchwork.freedesktop.org/series/101390/
State : warning
== Summary ==
$ make htmldocs 2>&1 > /dev/null | grep i915
./drivers/gpu/drm/i915/display/intel_drrs.c:230: warning: Excess function
parameter 'crtc_state' descr
== Series Details ==
Series: drm/i915/display/adlp: More voltage swing table updates
URL : https://patchwork.freedesktop.org/series/101404/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11365 -> Patchwork_22578
Summary
From: Ville Syrjälä
Let's just do a full DRRS disable/enable across all pipe updates.
This guarantees that the DRRS work doesn't interfere with anything
while the atomic commit is busy reprogramming the pipe.
Needed so that we can start reprogramming M/N seamlessly during
fastsets whenever possi
== Series Details ==
Series: Add CDCLK checks to atomic check phase (rev4)
URL : https://patchwork.freedesktop.org/series/101068/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11365 -> Patchwork_22577
Summary
---
**F
A few more updates in the alderlake-P voltage swing tables.
eDP HBR3 table was the same as icelake one but now it has changes for
voltage 0 and pre-emphasis 2 line.
And DP tables also had one line change in each.
Bspec: 49291
Signed-off-by: José Roberto de Souza
---
.../drm/i915/display/intel_d
== Series Details ==
Series: series starting with [CI,1/7] drm/i915/lmem: don't treat small BAR as
an error
URL : https://patchwork.freedesktop.org/series/101398/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11365 -> Patchwork_22576
==
== Series Details ==
Series: Add CDCLK checks to atomic check phase (rev4)
URL : https://patchwork.freedesktop.org/series/101068/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: Add CDCLK checks to atomic check phase (rev4)
URL : https://patchwork.freedesktop.org/series/101068/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
84e79f618db6 drm/i915/display: Add CDCLK actions to intel_cdclk_state
9ddce2b162f8 drm/i915/display: s
On Tue, Mar 15, 2022 at 06:54:21PM +, Souza, Jose wrote:
> On Tue, 2022-03-15 at 15:27 +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Rename the DRRS functiosn to say "(de)activate" rather than
> > "enable/disable". This let's us differentiate between the
> > logically enabled vs
On Tue, Mar 15, 2022 at 06:48:12PM +, Souza, Jose wrote:
> On Tue, 2022-03-15 at 15:27 +0200, Ville Syrjala wrote:
> > @@ -217,13 +216,12 @@ void intel_drrs_enable(const struct intel_crtc_state
> > *crtc_state)
> > void intel_drrs_disable(const struct intel_crtc_state *old_crtc_state)
> > {
== Series Details ==
Series: drm/i915: ttm for stolen
URL : https://patchwork.freedesktop.org/series/101396/
State : warning
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
CHK include/generated/compile.h
CC [M] drivers/gpu/drm/i915/display/int
== Series Details ==
Series: drm/i915: ttm for stolen
URL : https://patchwork.freedesktop.org/series/101396/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11365 -> Patchwork_22575
Summary
---
**FAILURE**
Serious u
== Series Details ==
Series: series starting with [CI,1/7] drm/i915/lmem: don't treat small BAR as
an error
URL : https://patchwork.freedesktop.org/series/101398/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be check
Apart from checking if squashing can be performed,
accommodate accessing in-flight cdclk state for any changes
that are needed during commit phase.
Cc: Jani Nikula
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 21 +++--
1 file changed, 11 insert
Apart from checking if crawling can be performed,
accommodate accessing in-flight cdclk state for any changes
that are needed during commit phase.
Cc: Jani Nikula
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 22 +++---
1 file changed, 11 insert
Checking cdclk conditions during atomic check and preparing
for commit phase so we can have atomic commit as simple
as possible. Add the specific steps to be taken during
cdclk changes, prepare for squashing, crawling and modeset
scenarios.
v2: Add intel_cdclk_modeset() similar to intel_cdclk_squa
This is a prep patch for what the rest of the series does.
Add existing actions that change cdclk - squash, crawl, modeset to
intel_cdclk_state so we have access to the cdclk values
that are in transition.
Cc: Jani Nikula
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/display/intel_cd
This version splits the original patch into simpler units.
The intention is to check for squashing, crawling conditions
at atomic check phase and prepare for commit phase. This basically
means the in-flight cdclk state is available. intel_cdclk_can_squash(),
intel_cdclk_can_crawl() and intel_cdclk
Checked the logs, a lot of machines not showing tests results even though
igt_run.txt shows as PASS for most. The boot log shows ACL errors in
/var/log/journal/ , sending the series again.
Anusha
From: Patchwork
Sent: Friday, March 11, 2022 12:55 AM
To: Srivatsa, Anusha
Cc: intel-gfx@lists.fr
== Series Details ==
Series: i915: General multicast steering updates (rev2)
URL : https://patchwork.freedesktop.org/series/101367/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11365 -> Patchwork_22574
Summary
---
*
== Series Details ==
Series: drm/i915: ttm for stolen
URL : https://patchwork.freedesktop.org/series/101396/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: drm/i915: ttm for stolen
URL : https://patchwork.freedesktop.org/series/101396/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
26eebf54d3e6 drm/i915: instantiate ttm ranger manager for stolen memory
-:7: WARNING:COMMIT_MESSAGE: Missing commit descrip
== Series Details ==
Series: Add GuC Error Capture Support (rev2)
URL : https://patchwork.freedesktop.org/series/101348/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11365 -> Patchwork_22573
Summary
---
**SUCCESS**
== Series Details ==
Series: i915: General multicast steering updates (rev2)
URL : https://patchwork.freedesktop.org/series/101367/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
On Tue, 2022-03-15 at 15:27 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Rename the DRRS functiosn to say "(de)activate" rather than
> "enable/disable". This let's us differentiate between the
> logically enabled vs. actually currently active cases.
>
> Signed-off-by: Ville Syrjälä
> -
== Series Details ==
Series: i915: General multicast steering updates (rev2)
URL : https://patchwork.freedesktop.org/series/101367/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
b9726a99fbeb drm/i915: Report steering details in debugfs
-:32: WARNING:STATIC_CONST_CHAR_ARRAY: sta
On Mon, Mar 14, 2022 at 6:12 PM Ville Syrjälä
wrote:
>
> On Fri, Feb 18, 2022 at 12:03:41PM +0200, Ville Syrjala wrote:
> > drm: Add drm_mode_init()
> > drm/bridge: Use drm_mode_copy()
> > drm/imx: Use drm_mode_duplicate()
> > drm/panel: Use drm_mode_duplicate()
> > drm/vc4: Use drm_mode
Applied. Thanks!
Alex
On Fri, Feb 18, 2022 at 11:32 AM Harry Wentland wrote:
>
>
>
> On 2022-02-18 05:03, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > struct drm_display_mode embeds a list head, so overwriting
> > the full struct with another one will corrupt the list
> > (if the desti
Applied. Thanks!
Alex
On Fri, Feb 18, 2022 at 5:04 AM Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> struct drm_display_mode embeds a list head, so overwriting
> the full struct with another one will corrupt the list
> (if the destination mode is on a list). Use drm_mode_copy()
> instead whi
On Tue, 2022-03-15 at 15:27 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Let's just do a full DRRS disable/enable across all pipe updates.
> This guarantees that the DRRS work doesn't interfere with anything
> while the atomic commit is busy reprogramming the pipe.
>
> Needed so that we
On Tue, 2022-03-15 at 15:27 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> With static DRRS the user might ask for the lowest possible refresh
> rate of the panel, in which case we're not going to find a suitable
> downclock mode for it and we should not try to enable seamless DRRS.
> This
On Tue, 2022-03-15 at 15:27 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Schedule the DRRS downclock work already from intel_drrs_enable()
> instead of waiting around for a frontbuffer flush that may or
> may not ever come.
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Ville
On Tue, 2022-03-15 at 15:27 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Skip all the DRRS work cancel/schedule stuff if the pipe's
> frontbuffer bits were not among those affected by the frontbuffer
> rendering.
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Ville Syrjälä
>
On Tue, 2022-03-15 at 15:27 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Pre-determine the frontbuffer_bits for the each pipe during
> intel_drrs_enable(). Will become useful for bigjoiner use cases
> soon.
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Ville Syrjälä
> ---
>
On Tue, 2022-03-15 at 15:27 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Now that DRRS can operate on multiple pipes we need to make sure
> one pipe doesn't throw away the other pipe's frontbuffer_bits before
> said pipe can handle them.
>
Reviewed-by: José Roberto de Souza
> Signed-
On Tue, 2022-03-15 at 15:27 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The DRRS refresh rate should be indented by one tab like the
> other per-crtc DRRS stuff.
>
Reviewed-by: José Roberto de Souza
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_display_
== Series Details ==
Series: Add GuC Error Capture Support (rev2)
URL : https://patchwork.freedesktop.org/series/101348/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: Add GuC Error Capture Support (rev2)
URL : https://patchwork.freedesktop.org/series/101348/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
41d2f067e825 drm/i915/guc: Update GuC ADS size for error capture lists
-:40: WARNING:FILE_PATH_CHANGES: added,
On Tue, Mar 15, 2022 at 03:27:51PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> DRRS operates on transcoder level, so we should only poke at it from
> the master crtc rather than letting every joined pipe give it
> potentially conflicting input.
>
> Signed-off-by: Ville Syrjälä
Looks
Add a generic interface for allocating an object at some specific
offset, and convert stolen over. Later we will want to hook this up to
different backends.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Nirmoy Das
---
.../drm/i915/display/intel_plane_initial.c| 4 +-
drive
From: Akeem G Abodunrin
On client platforms with reduced LMEM BAR, we should be able to continue
with driver load with reduced io_size. Instead of using the BAR size to
determine the how large stolen should be, we should instead use the
ADDR_RANGE register to figure this out(at least on platforms
For the ttm backend we can use existing placements fpfn and lpfn to
force the allocator to place the object at the requested offset,
potentially evicting stuff if the spot is currently occupied.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Nirmoy Das
---
.../gpu/drm/i915/gem/i
From: CQ Tang
When system does not have mappable aperture, ggtt->mappable_end=0. In
this case if we pass PIN_MAPPABLE when pinning vma, the pinning code
will return -ENOSPC. So conditionally set PIN_MAPPABLE if HAS_GMCH().
Suggested-by: Chris P Wilson
Signed-off-by: CQ Tang
Cc: Radhakrishna Sr
On integrated it looks like the GGTT base should always 1:1 maps to
somewhere within DSM. On discrete the base seems to be pre-programmed with
a normal lmem address, and is not 1:1 mapped with the base address. On
such devices probe the lmem address directly from the PTE.
v2(Ville):
- The base i
Keep the behaviour consistent with normal lmem, where we assume CPU
access if by default required.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Nirmoy Das
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm
Just pass along the probed io_size. The backend should be able to
utilize the entire range here, even if some of it is non-mappable.
It does leave open with what to do with stolen local-memory.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
Reviewed-by: Nirmoy D
Construct gem objects around stolen nodes.
This stops the abuse of interfaces and aids future patches that done use
drm nodes for stolen areas.
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/display/intel_fbc.c | 72 --
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 6
RFC: do we want this to become a generic interface in
ttm_resource_manager_func?
RFC: would we prefer a different interface? e.g.
for_each_resource_in_range or for_each_bo_in_range
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/ttm/ttm_range_manager.c | 21 +
include/drm/
RFC: should this become a generic interface in intel_memory_region_ops?
RFC: would we prefer an different interface? e.g. for_each_obj_in_range
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/intel_region_ttm.c | 19 +++
drivers/gpu/drm/i915/intel_region_ttm.h | 3 +++
2
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 385 ++---
drivers/gpu/drm/i915/gem/i915_gem_stolen.h | 9 -
drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 14 +-
drivers/gpu/drm/i915/gem/i915_gem_ttm.h| 7 +
4 files changed, 40 insertions(+),
remove i915->mm.stolen
remove i915->mm.stolen_lock
they are no longer needed.
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/display/intel_fbc.c | 4 ++--
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 2 --
drivers/gpu/drm/i915/gt/selftest_reset.c | 16 +---
drivers/gpu
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/gem/i915_gem_region.c | 55 ++
drivers/gpu/drm/i915/gem/i915_gem_region.h | 6 ++
drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 84 ++
drivers/gpu/drm/i915/intel_memory_region.h | 6 ++
4 files changed, 136 in
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/intel_region_ttm.c | 29 +++--
1 file changed, 22 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_region_ttm.c
b/drivers/gpu/drm/i915/intel_region_ttm.c
index 737ef3f4ab54..bb564b830c96 100644
--- a
Refactor stolen gem backend to use ttm.
While this series is finished off to handle CI issues, I would
appreciate a design review.
In particulare any opinions on the following would be appreciated:
1. display fbc code using gem objects instead of drm_mm_node. The intent
is rely on memory region a
== Series Details ==
Series: drm/i915/fbc: FBC frontbuffer stuff
URL : https://patchwork.freedesktop.org/series/101391/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11363_full -> Patchwork_22572_full
Summary
---
**S
On Tue, Mar 15, 2022 at 03:21:05PM +, Lee, Shawn C wrote:
> On Tuesday, March 15, 2022 8:33 PM, Nikula, Jani
> wrote:
> >On Mon, 14 Mar 2022, Drew Davenport wrote:
> >> On Mon, Mar 14, 2022 at 10:40:47AM +0200, Jani Nikula wrote:
> >>> On Sun, 13 Mar 2022, Lee Shawn C wrote:
> >>> > drm_fin
Add a new 'steering' node in each gt's debugfs directory that tells
whether we're using explicit steering for various types of MCR ranges
and, if so, what MMIO ranges it applies to.
We're going to be transitioning away from implicit steering, even for
slice/dss steering soon, so the information re
+Daniel for additional feedback!
On 2022-03-14 4:06 p.m., Michael Cheng wrote:
On 2022-03-08 10:58 a.m., Lucas De Marchi wrote:
On Tue, Feb 22, 2022 at 08:24:31PM +0100, Thomas Hellström (Intel)
wrote:
Hi, Michael,
On 2/22/22 18:26, Michael Cheng wrote:
This patch removes logic for wbinvd_
On Tue, Mar 15, 2022 at 03:47:11PM +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Reduce stack usage in debugfs due to SSEU (rev2)
> URL : https://patchwork.freedesktop.org/series/101369/
> State : success
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_11363_full
Filed https://gitlab.freedesktop.org/drm/intel/-/issues/5349
igt@kms_cursor_legacy@pipe-b-torture-bo - incomplete - No warnings/errors
Thanks,
Lakshmi.
-Original Message-
From: Matthew Auld
Sent: Tuesday, March 15, 2022 5:37 AM
To: Intel Graphics Development ; Vudum,
Lakshminarayana
Cc
Issue is related to https://gitlab.freedesktop.org/drm/intel/-/issues/3576
[ADL-P] KMS tests - dmesg-warn/dmesg-fail - *ERROR* CPU pipe A FIFO underrun:
(port|soft),transcoder,
And the latest reg from rev 2 is
https://gitlab.freedesktop.org/drm/intel/-/issues/5343
igt@i915_pm_dc@dc5-psr - crash
1 - 100 of 174 matches
Mail list logo
