Op 31-08-2021 om 17:14 schreef Daniel Vetter:
> On Tue, Aug 31, 2021 at 02:16:56PM +0200, Daniel Vetter wrote:
>> On Tue, Aug 31, 2021 at 11:38:27AM +0200, Maarten Lankhorst wrote:
>>> Op 14-08-2021 om 12:43 schreef Daniel Vetter:
The only reason for this really is the i915_gem_engines->fence
Driver should wait for free header or payload buffer in FIFO.
It would be good to wait a while for HW to release credit before
give it up to write to HW. Without sending initailize command
sets completely. It would caused MIPI display can't light up properly.
Cc: Ville Syrjala
Cc: Jani Nikula
Cc
v2: Get data length of brightness value more easily while driver try to
read/write MIPI_DCS_DISPLAY_BRIGHTNESS command.
Signed-off-by: Lee Shawn C
Lee Shawn C (5):
drm/i915/dsi: wait for header and payload credit available
drm/i915/dsi: refine send MIPI DCS command sequence
drm/i915: G
According to chapter "Sending Commands to the Panel" in bspec #29738
and #49188. If driver try to send DCS long pakcet, we have to program
TX payload register at first. And configure TX header HW register later.
DSC long packet would not be sent properly if we don't follow this
sequence.
Cc: Ville
VDSC engine can process only 1 pixel per Cd clock. In case
VDSC is used and max slice count == 1, max supported pixel
clock should be 100% of CD clock. Then do min_cdclk and
pixel clock comparison to get proper min cdclk.
v2:
- Check for dsc enable and slice count ==1 then allow to
double confir
So far, DCS backlight driver hardcode (0xFF) for max brightness level.
MIPI DCS spec allow max 0x for set_display_brightness (51h) command.
And VBT brightness precision bits can support 8 ~ 16 bits.
We should set correct precision bits in VBT that meet panel's request.
Driver can refer to this
Driver has to swap the endian before send brightness level value
to tcon.
v2: Use __be16 instead of u16 to fix sparse warning.
v3: Send one or two bytes brightness value depend on the precision.
v4: get data length of brightness value more easily.
Reported-by: kernel test robot
Cc: Ville Syrjala
== Series Details ==
Series: DSI driver improvement (rev2)
URL : https://patchwork.freedesktop.org/series/94237/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
91a7056b2b41 drm/i915/dsi: wait for header and payload credit available
c7f311aa2adf drm/i915/dsi: refine send MIPI DCS
== Series Details ==
Series: DSI driver improvement (rev2)
URL : https://patchwork.freedesktop.org/series/94237/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/i915/gem/i915_gem
== Series Details ==
Series: DSI driver improvement (rev2)
URL : https://patchwork.freedesktop.org/series/94237/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10545 -> Patchwork_20941
Summary
---
**SUCCESS**
No re
> -Original Message-
> From: Ville Syrjälä
> Sent: 01 September 2021 19:19
> To: Surendrakumar Upadhyay, TejaskumarX
>
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH V4] drm/i915/gen11: Disable cursor clock
> gating in HDR mode
>
> On Tue, Jun 22, 2021 at 03:0
On Wed, 01 Sep 2021, Imre Deak wrote:
> On Wed, Sep 01, 2021 at 02:28:15PM +0300, Jani Nikula wrote:
>> Accidentally dropped the else in a rebase fail, causing the DG2 max rate
>> to be overwritten later in the if ladder.
>>
>> Fixes: e752d1f9c14a ("drm/i915/dg2: add DG2 UHBR source rates")
>> Cc
On Wed, 01 Sep 2021, Rodrigo Vivi wrote:
> On Mon, Aug 30, 2021 at 03:53:41PM +0300, Jani Nikula wrote:
>> Clean up the LPSP capability printout. No functional changes.
>>
>> Signed-off-by: Jani Nikula
>
> Reviewed-by: Rodrigo Vivi
Thanks, pushed the first two for starters.
BR,
Jani.
>
>> -
On Thu, 02 Sep 2021, Lee Shawn C wrote:
> Driver has to swap the endian before send brightness level value
> to tcon.
>
> v2: Use __be16 instead of u16 to fix sparse warning.
> v3: Send one or two bytes brightness value depend on the precision.
> v4: get data length of brightness value more easily
Implement backup and restore of LMEM during suspend / resume.
What complicates things a bit is handling of pinned LMEM memory during
suspend and the fact that we might be dealing with unmappable LMEM in
the future, which makes us want to restrict the number of pinned objects that
need memcpy resume
When backing up or restoring contents of pinned objects at suspend /
resume time we need to allocate a new object as the backup. Add a function
to facilitate copies between the two. Some data needs to be copied before
the migration context is ready for operation, so make sure we can
disable acceler
An upcoming common pattern is to traverse the region object list and
perform certain actions on all objects in a region. It's a little tricky
to get the list locking right, in particular since a gem object may
change region unless it's pinned or the object lock is held.
Define a function that does
Just evict unpinned objects to system. For pinned LMEM objects,
make a backup system object and blit the contents to that.
For now, for pinned objects, backup using gpu blits and restore using
memcpy except for occasional user-space objects which are restored
using gpu blits once the migration con
Pinned contexts, like the migrate contexts need reset after resume
since their context image may have been lost. Also the GuC needs to
register pinned contexts.
Add a list to struct intel_engine_cs where we add all pinned contexts on
creation, and traverse that list at resume time to reset the pin
Pinned context images are now reset during resume. Don't back them up,
and assuming that rings can be assumed empty at suspend, don't back them
up either.
Introduce a new object flag, I915_BO_ALLOC_PM_VOLATILE meaning that an
object is allowed to lose its content on suspend.
Signed-off-by: Thomas
We really only need memcpy restore for objects that affect the
operability of the migrate context. That is, primarily the page-table
objects of the migrate VM.
Add an object flag, I915_BO_ALLOC_PM_EARLY for objects that need early
restores using memcpy and a way to assign LMEM page-table object fl
On Thu, 02 Sep 2021, Patchwork wrote:
> == Series Details ==
>
> Series: DSI driver improvement (rev2)
> URL : https://patchwork.freedesktop.org/series/94237/
> State : warning
>
> == Summary ==
>
> $ dim checkpatch origin/drm-tip
> 91a7056b2b41 drm/i915/dsi: wait for header and payload credit a
> -Original Message-
> From: Roper, Matthew D
> Sent: Thursday, September 2, 2021 2:55 AM
> To: Siddiqui, Ayaz A
> Cc: intel-gfx@lists.freedesktop.org; S, Srinivasan ;
> Wilson, Chris P
> Subject: Re: [PATCH V3 2/8] drm/i915/gt: Add support of mocs auxiliary
> registers programming
>
v2: Get data length of brightness value more easily while driver try to
read/write MIPI_DCS_DISPLAY_BRIGHTNESS command.
v3: fix checkpatch warning.
Signed-off-by: Lee Shawn C
Lee Shawn C (5):
drm/i915/dsi: wait for header and payload credit available
drm/i915/dsi: refine send MIPI DCS co
Driver should wait for free header or payload buffer in FIFO.
It would be good to wait a while for HW to release credit before
give it up to write to HW. Without sending initailize command
sets completely. It would caused MIPI display can't light up properly.
Cc: Ville Syrjala
Cc: Jani Nikula
Cc
VDSC engine can process only 1 pixel per Cd clock. In case
VDSC is used and max slice count == 1, max supported pixel
clock should be 100% of CD clock. Then do min_cdclk and
pixel clock comparison to get proper min cdclk.
v2:
- Check for dsc enable and slice count ==1 then allow to
double confir
According to chapter "Sending Commands to the Panel" in bspec #29738
and #49188. If driver try to send DCS long pakcet, we have to program
TX payload register at first. And configure TX header HW register later.
DSC long packet would not be sent properly if we don't follow this
sequence.
Cc: Ville
So far, DCS backlight driver hardcode (0xFF) for max brightness level.
MIPI DCS spec allow max 0x for set_display_brightness (51h) command.
And VBT brightness precision bits can support 8 ~ 16 bits.
We should set correct precision bits in VBT that meet panel's request.
Driver can refer to this
Driver has to swap the endian before send brightness level value
to tcon.
v2: Use __be16 instead of u16 to fix sparse warning.
v3: Send one or two bytes brightness value depend on the precision.
v4: get data length of brightness value more easily.
Reported-by: kernel test robot
Cc: Ville Syrjala
On Wed, 2021-09-01 at 20:02 +0300, Jani Nikula wrote:
> On Wed, 01 Sep 2021, Rodrigo Vivi wrote:
> > On Mon, Aug 30, 2021 at 03:53:43PM +0300, Jani Nikula wrote:
> > > Failures to register debugfs should be ignored anyway, so stop
> > > propagating errors altogether for clarity and simplicity. No
== Series Details ==
Series: drm/i915: Suspend / resume backup- and restore of LMEM.
URL : https://patchwork.freedesktop.org/series/94278/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e3f2d82e684e drm/i915/ttm: Implement a function to copy the contents of two
TTM-base objects
On 13/08/2021 21:30, Daniel Vetter wrote:
The only reason for this really is the i915_gem_engines->fence
callback engines_notify(), which exists purely as a fairly funky
reference counting scheme for that. Otherwise all other callers are
from process context, and generally fairly benign locking
== Series Details ==
Series: DSI driver improvement (rev2)
URL : https://patchwork.freedesktop.org/series/94237/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10545_full -> Patchwork_20941_full
Summary
---
**SUCCESS*
Hi,
On Wed, Sep 01, 2021 at 11:04:46PM +, Patchwork wrote:
> == Series Details ==
>
> Series: Fix in max source calculation for dp/edp (rev3)
> URL : https://patchwork.freedesktop.org/series/93622/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_10544_full -> Patc
== Series Details ==
Series: drm/i915: Suspend / resume backup- and restore of LMEM.
URL : https://patchwork.freedesktop.org/series/94278/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10546 -> Patchwork_20942
Summary
-
On Thu, Sep 02, 2021 at 11:07:06AM +, Surendrakumar Upadhyay, TejaskumarX
wrote:
>
>
> > -Original Message-
> > From: Ville Syrjälä
> > Sent: 01 September 2021 19:19
> > To: Surendrakumar Upadhyay, TejaskumarX
> >
> > Cc: intel-gfx@lists.freedesktop.org
> > Subject: Re: [Intel-gfx]
> -Original Message-
> From: Ville Syrjälä
> Sent: 02 September 2021 18:29
> To: Surendrakumar Upadhyay, TejaskumarX
>
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH V4] drm/i915/gen11: Disable cursor clock
> gating in HDR mode
>
> On Thu, Sep 02, 2021 at 11:0
+ Hariom
> -Original Message-
> From: Surendrakumar Upadhyay, TejaskumarX
> Sent: 02 September 2021 18:34
> To: Ville Syrjälä
> Cc: intel-gfx@lists.freedesktop.org; Souza, Jose
> Subject: RE: [Intel-gfx] [PATCH V4] drm/i915/gen11: Disable cursor clock
> gating in HDR mode
>
>
>
> > --
> -Original Message-
> From: Li, Juston
> Sent: Friday, August 20, 2021 12:19 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: seanp...@chromium.org; Gupta, Anshuman ;
> C, Ramalingam ; Vivi, Rodrigo
> ; Li, Juston
> Subject: [Intel-gfx] [PATCH v6 1/3] drm/i915/hdcp: update cp_irq_count_
> -Original Message-
> From: Li, Juston
> Sent: Friday, August 20, 2021 12:19 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: seanp...@chromium.org; Gupta, Anshuman ;
> C, Ramalingam ; Vivi, Rodrigo
> ; Li, Juston
> Subject: [Intel-gfx] [PATCH v6 2/3] drm/i915/hdcp: read RxInfo once whe
> -Original Message-
> From: Li, Juston
> Sent: Friday, August 20, 2021 12:19 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: seanp...@chromium.org; Gupta, Anshuman ;
> C, Ramalingam ; Vivi, Rodrigo
> ; Li, Juston
> Subject: [Intel-gfx] [PATCH v6 3/3] drm/i915/hdcp: reuse rx_info for ms
The only reason for this really is the i915_gem_engines->fence
callback engines_notify(), which exists purely as a fairly funky
reference counting scheme for that. Otherwise all other callers are
from process context, and generally fairly benign locking context.
Unfortunately untangling that requi
gem context refcounting is another exercise in least locking design it
seems, where most things get destroyed upon context closure (which can
race with anything really). Only the actual memory allocation and the
locks survive while holding a reference.
This tripped up Jason when reimplementing the
Changing the vm from a finalized gem ctx is no longer possible, which
means we don't have to check for that anymore.
I was pondering whether to keep the check as a WARN_ON, but things go
boom real bad real fast if the vm of a vma is wrong. Plus we'd need to
also get the ggtt vm for !full-ppgtt pla
The comment added in
commit b81dde719439c8f09bb61e742ed95bfc4b33946b
Author: Chris Wilson
Date: Tue May 21 22:11:29 2019 +0100
drm/i915: Allow userspace to clone contexts on creation
and moved in
commit 27dbae8f36c1c25008b7885fc07c57054b7dfba3
Author: Chris Wilson
The important part isn't so much that this does an rcu lookup - that's
more an implementation detail, which will also be removed.
The thing that makes this different from other functions is that it's
gettting you the vm that batchbuffers will run in for that gem
context, which is either a full ppg
And use it anywhere we have open-coded checks for ctx->vm that really
only check for full ppgtt.
Plus for paranoia add a GEM_BUG_ON that checks it's really only set
when we have full ppgtt, just in case. gem_context->vm is different
since it's NULL in ggtt mode, unlike intel_context->vm or gt->vm,
Consolidates the "which is the vm my execbuf runs in" code a bit. We
do some get/put which isn't really required, but all the other users
want the refcounting, and I figured doing a function just for this
getparam to avoid 2 atomis is a bit much.
Reviewed-by: Maarten Lankhorst
Signed-off-by: Dani
Since
commit ccbc1b97948ab671335e950271e39766729736c3
Author: Jason Ekstrand
Date: Thu Jul 8 10:48:30 2021 -0500
drm/i915/gem: Don't allow changing the VM on running contexts (v4)
the gem_ctx->vm can't change anymore. Plus we always set the
intel_context->vm, so might as well use the help
It's been invariant since
commit ccbc1b97948ab671335e950271e39766729736c3
Author: Jason Ekstrand
Date: Thu Jul 8 10:48:30 2021 -0500
drm/i915/gem: Don't allow changing the VM on running contexts (v4)
this just completes the deed. I've tried to split out prep work for
more
We don't need the absolute speed of rcu for this. And
i915_address_space in general dont need rcu protection anywhere else,
after we've made gem contexts and engines a lot more immutable.
Note that this semantically reverts
commit aabbe344dc3ca5f7d8263a02608ba6179e8a4499
Author: Chris Wilson
Dat
The full audit is quite a bit of work:
- i915_dpt has very simple lifetime (somehow we create a display pagetable vm
per object, so its _very_ simple, there's only ever a single vma in there),
and uses i915_vm_close(), which internally does a i915_vm_put(). No rcu.
Aside: wtf is i915_dpt do
On Tue, Aug 31, 2021 at 02:18:15PM +0100, Tvrtko Ursulin wrote:
>
> On 31/08/2021 13:43, Daniel Vetter wrote:
> > On Tue, Aug 31, 2021 at 10:15:03AM +0100, Tvrtko Ursulin wrote:
> > >
> > > On 30/08/2021 09:26, Daniel Vetter wrote:
> > > > On Fri, Aug 27, 2021 at 03:44:42PM +0100, Tvrtko Ursulin
On 02/09/2021 15:20, Daniel Vetter wrote:
And use it anywhere we have open-coded checks for ctx->vm that really
only check for full ppgtt.
Plus for paranoia add a GEM_BUG_ON that checks it's really only set
when we have full ppgtt, just in case. gem_context->vm is different
since it's NULL in
On 02/09/2021 15:33, Daniel Vetter wrote:
On Tue, Aug 31, 2021 at 02:18:15PM +0100, Tvrtko Ursulin wrote:
On 31/08/2021 13:43, Daniel Vetter wrote:
On Tue, Aug 31, 2021 at 10:15:03AM +0100, Tvrtko Ursulin wrote:
On 30/08/2021 09:26, Daniel Vetter wrote:
On Fri, Aug 27, 2021 at 03:44:42PM
On Thu, Sep 2, 2021 at 2:42 PM Tvrtko Ursulin
wrote:
>
>
> On 13/08/2021 21:30, Daniel Vetter wrote:
> > The only reason for this really is the i915_gem_engines->fence
> > callback engines_notify(), which exists purely as a fairly funky
> > reference counting scheme for that. Otherwise all other c
== Series Details ==
Series: drm/i915: Suspend / resume backup- and restore of LMEM.
URL : https://patchwork.freedesktop.org/series/94278/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10546_full -> Patchwork_20942_full
Sum
== Series Details ==
Series: DSI driver improvement (rev3)
URL : https://patchwork.freedesktop.org/series/94237/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/i915/gem/i915_gem
On 8/25/21 3:58 AM, José Roberto de Souza wrote:
It started as a code style fix for the lines above 100 col but it
turned out to simplifications to intel_drrs_set_state().
Now it receives the desired refresh rate type, high or low.
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i
On Thu, Sep 02, 2021 at 03:54:36PM +0100, Tvrtko Ursulin wrote:
> On 02/09/2021 15:20, Daniel Vetter wrote:
> > And use it anywhere we have open-coded checks for ctx->vm that really
> > only check for full ppgtt.
> >
> > Plus for paranoia add a GEM_BUG_ON that checks it's really only set
> > when
== Series Details ==
Series: DSI driver improvement (rev3)
URL : https://patchwork.freedesktop.org/series/94237/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10548 -> Patchwork_20943
Summary
---
**SUCCESS**
No re
On 8/25/21 3:58 AM, José Roberto de Souza wrote:
Both functions are pretty much equal, with minor changes that can be
handled by a single parameter.
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_drrs.c | 82 +--
1 file changed, 32 insertio
On Thu, Sep 02, 2021 at 04:56:18AM -0700, Siddiqui, Ayaz A wrote:
...
> > > +static int check_aux_regs(struct intel_engine_cs *engine,
> > > + const struct drm_i915_aux_table *r,
> > > + u32 **vaddr)
> >
> > One other concern (which is part of why I didn't re
Looks good to me.
Reviewed-by: Gwan-gyeong Mun
On 8/25/21 3:58 AM, José Roberto de Souza wrote:
Frontbuffer rendering will be dropped for modern platforms but
before that we to prepare DRRS for it.
intel_drrs_flush and intel_drrs_invalidate will not be called
for platforms that will not suppor
On 02/09/2021 16:05, Daniel Vetter wrote:
On Thu, Sep 2, 2021 at 2:42 PM Tvrtko Ursulin
wrote:
On 13/08/2021 21:30, Daniel Vetter wrote:
The only reason for this really is the i915_gem_engines->fence
callback engines_notify(), which exists purely as a fairly funky
reference counting scheme
On 02/09/2021 16:22, Daniel Vetter wrote:
On Thu, Sep 02, 2021 at 03:54:36PM +0100, Tvrtko Ursulin wrote:
On 02/09/2021 15:20, Daniel Vetter wrote:
And use it anywhere we have open-coded checks for ctx->vm that really
only check for full ppgtt.
Plus for paranoia add a GEM_BUG_ON that checks
== Series Details ==
Series: series starting with [01/11] drm/i915: Release i915_gem_context from a
worker
URL : https://patchwork.freedesktop.org/series/94285/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
54d95644f2a9 drm/i915: Release i915_gem_context from a worker
-:109: W
== Series Details ==
Series: series starting with [01/11] drm/i915: Release i915_gem_context from a
worker
URL : https://patchwork.freedesktop.org/series/94285/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked
On 9/1/2021 17:50, Daniele Ceraolo Spurio wrote:
From: Matthew Brost
Add GuC kernel doc for all structures added thus far for GuC submission
and update the main GuC submission section with the new interface
details.
v2:
- Drop guc_active.lock DOC
v3:
- Fixup a few kernel doc comments (Dani
> -Original Message-
> From: Tvrtko Ursulin
> Sent: Thursday, September 2, 2021 9:42 AM
> To: Daniel Vetter
> Cc: Daniel Vetter ; DRI Development de...@lists.freedesktop.org>; Intel Graphics Development g...@lists.freedesktop.org>; Maarten Lankhorst
> ; Vetter, Daniel
> ; Bloomfield, Jo
On 9/2/2021 10:01 AM, John Harrison wrote:
On 9/1/2021 17:50, Daniele Ceraolo Spurio wrote:
From: Matthew Brost
Add GuC kernel doc for all structures added thus far for GuC submission
and update the main GuC submission section with the new interface
details.
v2:
- Drop guc_active.lock DO
== Series Details ==
Series: series starting with [01/11] drm/i915: Release i915_gem_context from a
worker
URL : https://patchwork.freedesktop.org/series/94285/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10548 -> Patchwork_20944
== Series Details ==
Series: series starting with [01/11] drm/i915: Release i915_gem_context from a
worker (rev2)
URL : https://patchwork.freedesktop.org/series/94285/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
64372bd0168a drm/i915: Release i915_gem_context from a worker
-
> -Original Message-
> From: Roper, Matthew D
> Sent: Thursday, September 2, 2021 5:47 AM
> To: Siddiqui, Ayaz A
> Cc: intel-gfx@lists.freedesktop.org; Telukuntla, Sreedhar
>
> Subject: Re: [Intel-gfx] [PATCH V3 7/8] drm/i915/gt: Initialize L3CC table in
> mocs init
>
> On Mon, Aug 3
== Series Details ==
Series: series starting with [01/11] drm/i915: Release i915_gem_context from a
worker (rev2)
URL : https://patchwork.freedesktop.org/series/94285/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be
On 8/25/21 3:58 AM, José Roberto de Souza wrote:
By now all the userspace applications should have migrated to atomic
or at least be calling DRM_IOCTL_MODE_DIRTYFB.
With that we can kill frontbuffer rendering support in i915 for
modern platforms.
So here converting legacy APIs into atomic co
> -Original Message-
> From: Roper, Matthew D
> Sent: Thursday, September 2, 2021 9:36 PM
> To: Siddiqui, Ayaz A
> Cc: intel-gfx@lists.freedesktop.org; S, Srinivasan ;
> Wilson, Chris P
> Subject: Re: [PATCH V3 2/8] drm/i915/gt: Add support of mocs auxiliary
> registers programming
>
== Series Details ==
Series: series starting with [01/11] drm/i915: Release i915_gem_context from a
worker (rev2)
URL : https://patchwork.freedesktop.org/series/94285/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10548 -> Patchwork_20945
=
Cache-control registers for Command Stream(CMD_CCTL) are used
to set catchability for memory writes and reads outputted by
Command Streamers on Gen12 onward platforms.
These registers need to point un-cached(UC) MOCS index.
Cc: Matt Roper
Signed-off-by: Ayaz A Siddiqui
---
drivers/gpu/drm/i915
Now there are lots of Command and registers that require mocs index
programming.
So propagating mocs_index from mocs to gt so that it can be
used directly without having platform-specific checks.
Cc: CQ Tang
Cc: Matt Roper
Signed-off-by: Ayaz A Siddiqui
---
drivers/gpu/drm/i915/gt/intel_gt.c
Blitter commands which do not have MOCS fields rely on
cacheability of BlitterCacheControlRegister which was mapped
to index 0 by default.Once we changed the MOCS value of
index 0 to L3 WB, tests like gem_linear_blits started failing
due to a change in cacheability from UC to WB.
Program and place
Historically we've initialized all undefined/reserved entries in
a platform's MOCS table to the contents of table entry #1 (i.e.,
I915_MOCS_PTE).
Going forward, we can't assume that table entry #1 will always
contain suitable values to use for undefined/reserved table
indices. We'll allow a platfor
From: Sreedhar Telukuntla
Initialize the L3CC table as part of mocs initialization to program
LNCFCMOCSx registers so that the mocs settings are available for
selection for subsequent memory transactions in the driver load path.
Apart from the above requirement, this patch is also needed for pla
Gen >= 12 onwards MOCS table doesn't have a setting for PTE
so I915_MOCS_PTE is not a valid index and it will have different
MOCS values are based on the platform.
To detect these kinds of misprogramming, all the unspecified and
reserved MOCS indexes are set to WB_L3. TGL/RKL unspecified MOCS
inde
Some platform like XEHPSVD does not have Renderer engines. since
read_l3cc_table() is guarded by renderer class due to that check
of L3CC table was not being performed on those platforms.
Signed-off-by: Ayaz A Siddiqui
---
drivers/gpu/drm/i915/gt/selftest_mocs.c | 4 ++--
1 file changed, 2 inser
== Series Details ==
Series: DSI driver improvement (rev3)
URL : https://patchwork.freedesktop.org/series/94237/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10548_full -> Patchwork_20943_full
Summary
---
**FAILURE*
On 9/1/2021 17:50, Daniele Ceraolo Spurio wrote:
From: Matthew Brost
When the GuC does a media reset, it copies a golden context state back
into the corrupted context's state. The address of the golden context
and the size of the engine state restore are passed in via the GuC ADS.
The i915 had
== Series Details ==
Series: drm/i915/gt: Initialize unused MOCS entries to L3_WB
URL : https://patchwork.freedesktop.org/series/94295/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gp
On Thu, Sep 02, 2021 at 05:05:05PM +, Bloomfield, Jon wrote:
> > -Original Message-
> > From: Tvrtko Ursulin
> > Sent: Thursday, September 2, 2021 9:42 AM
> > To: Daniel Vetter
> > Cc: Daniel Vetter ; DRI Development > de...@lists.freedesktop.org>; Intel Graphics Development > g...@
On Wed, Sep 1, 2021 at 5:15 PM Janusz Krzysztofik
wrote:
>
> GPU wedged flag now set on driver unregister to prevent from further
> using the GPU can be then cleared unintentionally when calling
> __intel_gt_unset_wedged() still before the flag is finally marked
> unrecoverable. We need to have i
On Thu, Sep 2, 2021 at 6:20 PM Tvrtko Ursulin
wrote:
> On 02/09/2021 16:05, Daniel Vetter wrote:
> > On Thu, Sep 2, 2021 at 2:42 PM Tvrtko Ursulin
> > wrote:
> >>
> >>
> >> On 13/08/2021 21:30, Daniel Vetter wrote:
> >>> The only reason for this really is the i915_gem_engines->fence
> >>> callbac
== Series Details ==
Series: drm/i915/gt: Initialize unused MOCS entries to L3_WB
URL : https://patchwork.freedesktop.org/series/94295/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10548 -> Patchwork_20946
Summary
---
On Fri, Sep 03, 2021 at 12:26:30AM +0530, Ayaz A Siddiqui wrote:
> Now there are lots of Command and registers that require mocs index
> programming.
> So propagating mocs_index from mocs to gt so that it can be
> used directly without having platform-specific checks.
>
> Cc: CQ Tang
> Cc: Matt Ro
On Fri, Sep 03, 2021 at 12:26:31AM +0530, Ayaz A Siddiqui wrote:
> Cache-control registers for Command Stream(CMD_CCTL) are used
> to set catchability for memory writes and reads outputted by
> Command Streamers on Gen12 onward platforms.
>
> These registers need to point un-cached(UC) MOCS index.
On Fri, Sep 03, 2021 at 12:26:32AM +0530, Ayaz A Siddiqui wrote:
> Blitter commands which do not have MOCS fields rely on
> cacheability of BlitterCacheControlRegister which was mapped
> to index 0 by default.Once we changed the MOCS value of
> index 0 to L3 WB, tests like gem_linear_blits started
On Fri, Sep 03, 2021 at 12:26:33AM +0530, Ayaz A Siddiqui wrote:
> Historically we've initialized all undefined/reserved entries in
> a platform's MOCS table to the contents of table entry #1 (i.e.,
> I915_MOCS_PTE).
> Going forward, we can't assume that table entry #1 will always
> contain suitabl
On Fri, Sep 03, 2021 at 12:26:34AM +0530, Ayaz A Siddiqui wrote:
> From: Sreedhar Telukuntla
>
> Initialize the L3CC table as part of mocs initialization to program
> LNCFCMOCSx registers so that the mocs settings are available for
> selection for subsequent memory transactions in the driver load
On Fri, Sep 03, 2021 at 12:26:35AM +0530, Ayaz A Siddiqui wrote:
> Some platform like XEHPSVD does not have Renderer engines. since
> read_l3cc_table() is guarded by renderer class due to that check
> of L3CC table was not being performed on those platforms.
>
Yeah, Xe_HP SDV doesn't have an RCS
From: Colin Ian King
There is a statement that is indented one character too deeply,
clean this up.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists
On 9/1/2021 17:49, Daniele Ceraolo Spurio wrote:
From: Matthew Brost
A small race that could result in incorrect accounting of the number
of outstanding G2H. Basically prior to this patch we did not increment
the number of outstanding G2H if we encoutered a GT reset while sending
a H2G. This wa
1 - 100 of 116 matches
Mail list logo
