== Series Details ==
Series: drm/i915: Reduce stack usage in debugfs due to SSEU (rev2)
URL : https://patchwork.freedesktop.org/series/101369/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11363_full -> Patchwork_22567_full
Hi Tvrtko, Daniel,
>
> On 11/03/2022 09:39, Daniel Vetter wrote:
> > On Mon, 7 Mar 2022 at 21:38, Vivek Kasireddy
> > wrote:
> >>
> >> On platforms capable of allowing 8K (7680 x 4320) modes, pinning 2 or
> >> more framebuffers/scanout buffers results in only one that is mappable/
> >> fenceabl
Just curious, what is the state of this seris? It would be good to
have it ready early on for the next merge window as there is quite
a backlog that depends on it.
The low voltage sku check can be ignored as OEMs need to consider that
when designing the board and then put any limits in VBT.
Same is now changed in Bspec pages.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5272
Signed-off-by: Ankit Nautiyal
Reviewed-by: Imre Deak
---
drivers/g
This patch series is continuation of the discussion in:
https://patchwork.freedesktop.org/patch/457398/?series=95444&rev=1
along with a patch to add debug print voltage configuration for
combo PHY ports.
Rev3: Added names for voltage levels (Imre)
Ankit Nautiyal (2):
drm/i915/display: Remove c
Add debug print for Procmon Ref values, to help get the
voltage configurations of combo PHYs.
v2: Used drm_dbg_kms for logs. (Jani)
Added names for different voltage levels. (Imre)
Suggested-by: Imre Deak
Signed-off-by: Ankit Nautiyal
---
.../gpu/drm/i915/display/intel_combo_phy.c| 36
On 3/10/2022 8:55 PM, Imre Deak wrote:
On Tue, Oct 26, 2021 at 11:08:21AM +0530, Ankit Nautiyal wrote:
The low voltage sku check can be ignored as OEMs need to consider that
when designing the board and then put any limits in VBT.
Same is now changed in Bspec pages.
v2: Added debug print for
Dear Arunpravin,
Am 14.03.22 um 20:40 schrieb Arunpravin:
handle a situation in the condition order-- == min_order,
when order = 0, leading to order = -1, it now won't exit
the loop. To avoid this problem, added a order check in
the same condition, (i.e) when order is 0, we return
-ENOSPC
Sign
On Tue, 15 Mar 2022, Ankit Nautiyal wrote:
> Add debug print for Procmon Ref values, to help get the
> voltage configurations of combo PHYs.
>
> v2: Used drm_dbg_kms for logs. (Jani)
> Added names for different voltage levels. (Imre)
>
> Suggested-by: Imre Deak
> Signed-off-by: Ankit Nautiyal
>
On Tue, 15 Mar 2022, Christoph Hellwig wrote:
> Just curious, what is the state of this seris? It would be good to
> have it ready early on for the next merge window as there is quite
> a backlog that depends on it.
Can't speak for the status of the series, but for drm the deadline for
changes h
On Tue, Mar 15, 2022 at 10:46:53AM +0200, Jani Nikula wrote:
> On Tue, 15 Mar 2022, Christoph Hellwig wrote:
> > Just curious, what is the state of this seris? It would be good to
> > have it ready early on for the next merge window as there is quite
> > a backlog that depends on it.
>
> Can't s
== Series Details ==
Series: Remove check for ComboPHY I/O voltage for DP source rate (rev3)
URL : https://patchwork.freedesktop.org/series/96293/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11363 -> Patchwork_22568
Summa
I was actually testing it for almost two weeks, but still I met some hang and I
was trying to figure where the problem is as this is quite a big change. Let's
see if I can figure it out this week.
Thanks,
Zhi.
On 3/15/22 8:48 AM, Christoph Hellwig wrote:
> On Tue, Mar 15, 2022 at 10:46:53AM +02
Dear Arunpravin,
Am 15.03.22 um 10:01 schrieb Arunpravin:
On 15/03/22 1:49 pm, Paul Menzel wrote:
Am 14.03.22 um 20:40 schrieb Arunpravin:
handle a situation in the condition order-- == min_order,
when order = 0, leading to order = -1, it now won't exit
the loop. To avoid this problem, add
On Tue, 15 Mar 2022, Christoph Hellwig wrote:
> I know. I meant the next one, not the one ending now. And I don't
> want to miss another one.
Ok, good, thanks.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
On 15/03/2022 07:28, Kasireddy, Vivek wrote:
Hi Tvrtko, Daniel,
On 11/03/2022 09:39, Daniel Vetter wrote:
On Mon, 7 Mar 2022 at 21:38, Vivek Kasireddy wrote:
On platforms capable of allowing 8K (7680 x 4320) modes, pinning 2 or
more framebuffers/scanout buffers results in only one that i
Add debug print for Procmon Ref values, to help get the
voltage configurations of combo PHYs.
v2: Used drm_dbg_kms for logs. (Jani)
Added names for different voltage levels. (Imre)
v3: Used const char * for names. (Jani)
Suggested-by: Imre Deak
Signed-off-by: Ankit Nautiyal
---
.../gpu/drm/i9
On 3/15/2022 2:08 PM, Jani Nikula wrote:
On Tue, 15 Mar 2022, Ankit Nautiyal wrote:
Add debug print for Procmon Ref values, to help get the
voltage configurations of combo PHYs.
v2: Used drm_dbg_kms for logs. (Jani)
Added names for different voltage levels. (Imre)
Suggested-by: Imre Deak
S
== Series Details ==
Series: Remove check for ComboPHY I/O voltage for DP source rate (rev3)
URL : https://patchwork.freedesktop.org/series/96293/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11363_full -> Patchwork_22568_full
=
On Sun, 13 Mar 2022, Lee Shawn C wrote:
> According to HDMI 2.1 spec.
>
> "The HDMI Forum EDID Extension Override Data Block (HF-EEODB)
> is utilized by Sink Devices to provide an alternate method to
> indicate an EDID Extension Block count larger than 1, while
> avoiding the need to present a VES
|This seems more natural to me than the previous version. Acked-by:
Nirmoy Das |
Nirmoy
On 14/03/2022 12:28, Matthew Auld wrote:
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
== Series Details ==
Series: Remove check for ComboPHY I/O voltage for DP source rate (rev4)
URL : https://patchwork.freedesktop.org/series/96293/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11363 -> Patchwork_22569
Summa
On Mon, 14 Mar 2022 at 19:32, Arunpravin
wrote:
>
> handle instances when size is not aligned with the min_page_size.
> Unigine Heaven has allocation requests for example required pages
> are 161 and alignment request is 128. To allocate the left over
> 33 pages, continues the iteration to find th
On 14/03/2022 19:40, Arunpravin wrote:
handle a situation in the condition order-- == min_order,
when order = 0, leading to order = -1, it now won't exit
the loop. To avoid this problem, added a order check in
the same condition, (i.e) when order is 0, we return
-ENOSPC
Signed-off-by: Arunpravin
Hi Matt,
Also feel free to upgrade my a-b to r-b for the series.
Regards,
Nirmoy
On 14/03/2022 12:28, Matthew Auld wrote:
The leftover bits around dealing with stolen-local memory + small BAR, plus
some related fixes.
v2: some tweaks based on feedback from Ville
v3: directly probe the PTE t
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_find_cea_extension() always look for a top level CEA block. Pass
>> > ext_index from caller then this function to search next available
>>
== Series Details ==
Series: Remove check for ComboPHY I/O voltage for DP source rate (rev4)
URL : https://patchwork.freedesktop.org/series/96293/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11363_full -> Patchwork_22569_full
=
On Mon, 14 Mar 2022 at 16:49, Patchwork
wrote:
>
> Patch Details
> Series:Some more bits for small BAR enabling (rev4)
> URL:https://patchwork.freedesktop.org/series/101052/
> State:failure
> Details:https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22555/index.html
>
> CI Bug Log - changes from
GSC is a graphics system controller, it provides
a chassis controller for graphics discrete cards.
There are two MEI interfaces in GSC: HECI1 and HECI2.
This series includes instantiation of the auxiliary devices for HECI2
and mei-gsc auxiliary device driver that binds to the auxiliary device.
T
From: Tomas Winkler
GSC is a graphics system controller, it provides
a chassis controller for graphics discrete cards.
There are two MEI interfaces in GSC: HECI1 and HECI2.
Both interfaces are on the BAR0 at offsets 0x00258000 and 0x00259000.
GSC is a GT Engine (class 4: instance 6). HECI1 inte
From: Tomas Winkler
GSC is a graphics system controller, based on CSE, it provides
a chassis controller for graphics discrete cards, as well as it
supports media protection on selected devices.
mei_gsc binds to a auxiliary devices exposed by Intel discrete
driver i915.
Signed-off-by: Alexander
Setup char device in spite of firmware handshake failure.
In order to provide host access to the firmware status registers and other
information required for the manufacturing process.
Signed-off-by: Alexander Usyskin
Signed-off-by: Tomas Winkler
Reviewed-by: Daniele Ceraolo Spurio
---
V5: Reba
From: Tomas Winkler
Implement runtime handlers for mei-gsc, to track
idle state of the device properly.
CC: Rodrigo Vivi
Signed-off-by: Tomas Winkler
Signed-off-by: Alexander Usyskin
---
V4: drop debug prints
V5: Rebase
V6: Rebase
V7: add Greg KH Reviewed-by
V8: Rebase
V9: Rebase
V11: Rebase
Add a hook to retrieve the firmware version of the
GSC devices to bus-fixup.
GSC has a different MKHI clients GUIDs but the same message structure
to retrieve the firmware version as MEI so mei_fwver() can be reused.
CC: Ashutosh Dixit
Signed-off-by: Alexander Usyskin
Signed-off-by: Tomas Winkle
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 will in fact oops.
We used to check for the presence of the downcl
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.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_drrs.c | 6 --
1 file changed, 4 insertio
From: Ville Syrjälä
A few more DRRS things:
* fix an oops I accidentally introduced
* avoid DRRS racing with regular atomic commits
* deal with bigjoiner
* other misc things
Ville Syrjälä (9):
drm/i915: Put the downclock_mode check back into can_enable_drrs()
drm/i915: Add missing tab to DRR
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.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display_types.h | 1 +
drivers/gpu/drm/i915/display/intel_drrs.c |
From: Ville Syrjälä
The DRRS refresh rate should be indented by one tab like the
other per-crtc DRRS stuff.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display_debugfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/int
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.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_drrs.c | 17 -
1 file changed, 8 insertions(+), 9 dele
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.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_drrs.c | 10 --
1 file changed, 8 insertions(+), 2
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
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ä
---
drivers/gpu/drm/i915/display/intel_drrs.c | 16 +++-
1 file changed
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ä
---
drivers/gpu/drm/i915/display/intel_display.c | 4 ++--
.../drm/i91
On Fri, 2022-03-11 at 10:51 -0800, José Roberto de Souza wrote:
> If a error happens and sink_not_reliable is set, PSR should be
> disabled
> for good but that is not happening.
> It would be disabled by the function handling the PSR error but then
> on the next fastset it would be enabled again in
== Series Details ==
Series: Add driver for GSC controller (rev11)
URL : https://patchwork.freedesktop.org/series/98066/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
396d56c025e8 drm/i915/gsc: add gsc as a mei auxiliary device
-:64: WARNING:FILE_PATH_CHANGES: added, moved or d
== Series Details ==
Series: Add driver for GSC controller (rev11)
URL : https://patchwork.freedesktop.org/series/98066/
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 Tuesday, March 15, 2022 7:03 PM, Nikula, Jani wrote:
>On Sun, 13 Mar 2022, Lee Shawn C wrote:
>> According to HDMI 2.1 spec.
>>
>> "The HDMI Forum EDID Extension Override Data Block (HF-EEODB) is
>> utilized by Sink Devices to provide an alternate method to indicate an
>> EDID Extension Bloc
From: Ville Syrjälä
Not sure what the point of this fbc->possible_frontbuffer_bits is.
And especially don't see why it's returning all the bits when
fbc is not even enabled. So let's just get rid of this and only
say we are interested in the plane's frontbuffer bits when fbc
is actually enabled.
From: Ville Syrjälä
Avoid all the FBC frontbuffer vs. atomic commit raciness
by not doing any FBC nukes while a flip is pending. Allows
us to remove the last locks from the i9xx plane code.
I also want to explore the idea of always generating DSB
batches for pipe commits and just excuting them o
From: Ville Syrjälä
Now that fbc no longer nukes while a flip is pending we can
remove the last uncore.lock from the i9xx plane code.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/i9xx_plane.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/gpu/drm/i915
From: Ville Syrjälä
By the time intel_fbc_global_disable() gets called during driver
teardown we should have already disabled all the crtcs, so
no way FBC should be enabled at this point.
And I have no idea what the other user (i915_restore_display())
is even trying to achieve.
So let's just th
From: Ville Syrjälä
If the frontbuffer bits say this fbc instance isn't affected just
skip the whole thing.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fbc.c | 28 +++-
1 file changed, 18 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i
From: Ville Syrjälä
Don't issue a nuke from frontbuffer flush while a flip is pending.
This avoids the DSPADDR/DSPSURF rmw abuse from the pre-snb nuke
from racing with the DSPADDR/DSPSURF write being performed by
the flip/plane update. The flip itself will already cause the nuke
so a double nuke
From: Ville Syrjälä
Let's make sure FBC is always disabled when we start to take
over the hardware state.
I suspect this should never really happen, since the only time
when we really should be taking over with the display already
active is when the previous state was progammed by the BIOS,
whic
From: Ville Syrjälä
Remove the pointless detour via __intel_fbc_post_update() during
frontbuffer flush.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fbc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
b/driv
== Series Details ==
Series: drm/i915: More DRRS work
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' description
== Series Details ==
Series: Add driver for GSC controller (rev11)
URL : https://patchwork.freedesktop.org/series/98066/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11363 -> Patchwork_22570
Summary
---
**SUCCESS**
== Series Details ==
Series: drm/i915/fbc: FBC frontbuffer stuff
URL : https://patchwork.freedesktop.org/series/101391/
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, 15 Mar 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Not sure what the point of this fbc->possible_frontbuffer_bits is.
> And especially don't see why it's returning all the bits when
> fbc is not even enabled. So let's just get rid of this and only
> say we are interested in the p
== Series Details ==
Series: drm/i915: More DRRS work
URL : https://patchwork.freedesktop.org/series/101390/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11363 -> Patchwork_22571
Summary
---
**WARNING**
Minor unk
On 15/03/22 4:56 pm, Matthew Auld wrote:
> On Mon, 14 Mar 2022 at 19:32, Arunpravin
> wrote:
>>
>> handle instances when size is not aligned with the min_page_size.
>> Unigine Heaven has allocation requests for example required pages
>> are 161 and alignment request is 128. To allocate the left
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_find_cea_extension() always look for a top level CEA block.
>>> > Pass ext_in
== 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 -> Patchwork_22572
Summary
---
**SUCCESS**
On Mon, Mar 14, 2022 at 10:09:42AM -0700, Alan Previn wrote:
> 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
== Series Details ==
Series: Add driver for GSC controller (rev11)
URL : https://patchwork.freedesktop.org/series/98066/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11363_full -> Patchwork_22570_full
Summary
---
**
Dear Arunpravin,
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.03.22 um 20:40 schrieb Arunpravin:
handle a situation in the condition order-- == min_order,
when or
== 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 -> Patchwork_22567_full
== Series Details ==
Series: Some more bits for small BAR enabling (rev4)
URL : https://patchwork.freedesktop.org/series/101052/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11358_full -> Patchwork_22555_full
Summary
-
Applied. Thanks!
Alex
On Fri, Feb 18, 2022 at 11:28 AM Harry Wentland wrote:
>
>
>
> On 2022-02-18 05:03, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > These on stack copies of the modes appear to be pointless.
> > Just look at the originals directly.
> >
> > Cc: Harry Wentland
> > Cc:
Thanks Matt! :)
On 3/15/2022 8:17 AM, Matthew Brost wrote:
On Mon, Mar 14, 2022 at 10:09:42AM -0700, Alan Previn wrote:
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 r
On Mon, 2022-03-14 at 19:08 -0700, Matt Roper wrote:
> From: John Harrison
>
> sseu_dev_info is already a pretty large structure which will likely
> continue to grow when future platforms increase potential DSS and EU
> counts. Let's switch the stack placement of this structure in debugfs
> with
On Mon, 2022-03-14 at 16:42 -0700, Matt Roper wrote:
> 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 st
== Series Details ==
Series: drm/i915: More DRRS work
URL : https://patchwork.freedesktop.org/series/101390/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11363_full -> Patchwork_22571_full
Summary
---
**SUCCESS**
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
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
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
+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_
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
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
== 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
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
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
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
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/
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
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
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
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
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
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: 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
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
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
== 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,
== 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.
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_
1 - 100 of 174 matches
Mail list logo
