Extend i915_lpsp_capability debugfs to DG2,ADLP and future platforms.
v2: commit log modification.
Cc: Animesh Manna
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_display_debugfs.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/inte
Hi Dave and Daniel,
these two fixes in drm-misc-fixes got lost during last cycle. Sending them
now.
Best regards
Thomas
drm-misc-fixes-2021-07-13:
Short summary of fixes pull:
* dma-buf: Fix fence leak in sync_file_merge() error code
* drm/panel: nt35510: Don't fail on DSI reads
The following
On 12/07/2021 17:12, Daniel Vetter wrote:
On Mon, Jul 12, 2021 at 04:51:42PM +0100, Tvrtko Ursulin wrote:
On 12/07/2021 15:42, Daniel Vetter wrote:
On Mon, Jul 12, 2021 at 01:17:12PM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Tracking DRM clients more explicitly will allow later pa
On 24.06.2021 09:04, Matthew Brost wrote:
> Update GuC debugfs to support the new GuC structures.
>
> Signed-off-by: John Harrison
> Signed-off-by: Matthew Brost
> ---
> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 22
> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 3 ++
> ..
Commit 375cca1cfeb5 ("drm/vgem: Implement mmap as GEM object function")
broke severla IGT tests in vgem_basic. [1] Attempts to fix the issue
have not worked out so far. [2][3] Revert the original patch for now.
Note that there is a patch that converts vgem to shmem helpers. [4]
Merging this change
On 24/06/2021 08:04, Matthew Brost wrote:
Add trace points for request dependencies and GuC submit. Extended
existing request trace points to include submit fence value,, guc_id,
and ring tail value.
Cc: John Harrison
Signed-off-by: Matthew Brost
---
.../gpu/drm/i915/gt/uc/intel_guc_submis
On Tue, Jul 13, 2021 at 9:25 AM Christian König
wrote:
> Am 13.07.21 um 08:50 schrieb Daniel Vetter:
> > On Tue, Jul 13, 2021 at 8:35 AM Christian König
> > wrote:
> >> Am 12.07.21 um 19:53 schrieb Daniel Vetter:
> >>> It might be good enough on x86 with just READ_ONCE, but the write side
> >>> s
== Series Details ==
Series: drm/i915/debugfs: xelpd lpsp capability (rev2)
URL : https://patchwork.freedesktop.org/series/92364/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10337 -> Patchwork_20583
Summary
---
**S
Ping for any reviewers? This fixes a customer issue on heavily loaded
transcode boxes by avoiding false GPU hang reports upon pressing Ctrl-C.
Regards,
Tvrtko
On 16/06/2021 11:09, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
When a non-persistent context exits we currently mark it as banne
== Series Details ==
Series: Revert "drm/vgem: Implement mmap as GEM object function"
URL : https://patchwork.freedesktop.org/series/92467/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
80530052a67f Revert "drm/vgem: Implement mmap as GEM object function"
-:17: WARNING:COMMIT_L
== Series Details ==
Series: Revert "drm/vgem: Implement mmap as GEM object function"
URL : https://patchwork.freedesktop.org/series/92467/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10337 -> Patchwork_20584
Summary
Am 12.07.21 um 19:53 schrieb Daniel Vetter:
It might be good enough on x86 with just READ_ONCE, but the write side
should then at least be WRITE_ONCE because x86 has total store order.
It's definitely not enough on arm.
Fix this proplery, which means
- explain the need for the barrier in both p
Am 12.07.21 um 19:53 schrieb Daniel Vetter:
This is a very confusingly named function, because not just does it
init an object, it arms it and provides a point of no return for
pushing a job into the scheduler. It would be nice if that's a bit
clearer in the interface.
But the real reason is tha
Before we can pull in the previous kernel doc for the caching bits, we
first get to add kernel doc for all of drm_i915_gem_object so this
actually builds.
Signed-off-by: Matthew Auld
Cc: Daniel Vetter
---
.../gpu/drm/i915/gem/i915_gem_object_types.h | 422 +++---
1 file changed, 36
Add some kernel doc for this. We can then just reference this later when
documenting madv in the kernel.
Signed-off-by: Matthew Auld
Cc: Daniel Vetter
---
include/uapi/drm/i915_drm.h | 50 +++--
1 file changed, 42 insertions(+), 8 deletions(-)
diff --git a/inclu
Try to document the object caching related bits, like cache_coherent and
cache_dirty.
Suggested-by: Daniel Vetter
Signed-off-by: Matthew Auld
---
.../gpu/drm/i915/gem/i915_gem_object_types.h | 135 +-
drivers/gpu/drm/i915/i915_drv.h | 9 --
2 files changed, 131
Pull in the kernel-doc for drm_i915_gem_object.
Signed-off-by: Matthew Auld
Cc: Daniel Vetter
---
Documentation/gpu/i915.rst | 7 +++
1 file changed, 7 insertions(+)
diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 204ebdaadb45..77558084e989 100644
--- a/Documenta
EHL and JSL add the 'Bypass LLC' MOCS entry, which should make it
possible for userspace to bypass the GTT caching bits set by the kernel,
as per the given object cache_level. This is troublesome since the heavy
flush we apply when first acquiring the pages is skipped if the kernel
thinks the objec
== Series Details ==
Series: drm/i915/debugfs: xelpd lpsp capability (rev2)
URL : https://patchwork.freedesktop.org/series/92364/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10337_full -> Patchwork_20583_full
Summary
== Series Details ==
Series: series starting with [1/5] drm/i915: document caching related bits
URL : https://patchwork.freedesktop.org/series/92469/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
2d424bc0390d drm/i915: document caching related bits
-:58: WARNING:TYPO_SPELLING:
Am 13.07.21 um 08:50 schrieb Daniel Vetter:
On Tue, Jul 13, 2021 at 8:35 AM Christian König
wrote:
Am 12.07.21 um 19:53 schrieb Daniel Vetter:
It might be good enough on x86 with just READ_ONCE, but the write side
should then at least be WRITE_ONCE because x86 has total store order.
It's defi
== Series Details ==
Series: series starting with [1/5] drm/i915: document caching related bits
URL : https://patchwork.freedesktop.org/series/92469/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10337 -> Patchwork_20585
Su
Matthew Auld writes:
> Try to document the object caching related bits, like cache_coherent and
> cache_dirty.
>
> Suggested-by: Daniel Vetter
> Signed-off-by: Matthew Auld
> ---
> .../gpu/drm/i915/gem/i915_gem_object_types.h | 135 +-
> drivers/gpu/drm/i915/i915_drv.h
== Series Details ==
Series: series starting with [1/5] drm/i915: document caching related bits
URL : https://patchwork.freedesktop.org/series/92469/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10337_full -> Patchwork_20585_full
==
We skip filling out the pt with scratch entries if the va range covers
the entire pt, since we later have to fill it with the PTEs for the
object pages anyway. However this might leave open a small window where
the PTEs don't point to anything valid for the HW to consume.
When for example using 2M
On Tue, Jul 13, 2021 at 02:04:31PM +0100, Matthew Auld wrote:
> We skip filling out the pt with scratch entries if the va range covers
> the entire pt, since we later have to fill it with the PTEs for the
> object pages anyway. However this might leave open a small window where
> the PTEs don't poi
On Thu, Jun 03, 2021 at 11:08:31PM +0200, Daniel Vetter wrote:
> We want to stop gup, which isn't the case if we use vmf_insert_page
> and VM_MIXEDMAP, because that does not set pte_special.
>
> v2: With this shmem gem helpers now definitely need CONFIG_MMU (0day)
>
> v3: add more depends on MMU.
On Tue, Jul 13, 2021 at 10:44:05AM +0200, Thomas Zimmermann wrote:
> Hi Dave and Daniel,
>
> these two fixes in drm-misc-fixes got lost during last cycle. Sending them
> now.
Applied to drm-fixes, thanks.
-Daniel
>
> Best regards
> Thomas
>
> drm-misc-fixes-2021-07-13:
> Short summary of fixes
== Series Details ==
Series: drm/i915/gtt: drop the page table optimisation
URL : https://patchwork.freedesktop.org/series/92474/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10339 -> Patchwork_20586
Summary
---
**S
Some vague evidences suggests this can go wrong. Try to prevent it by
holding the right mutex and clearing ->deferred_setup to make sure we
later on don't accidentally try to re-register the fbdev when the
driver thought it had it all cleaned up already.
v2: I realized that this is fundamentally b
On Mon, Jul 12, 2021 at 06:12:33PM -0500, Jason Ekstrand wrote:
> From: Thomas Hellström
>
> If our exported dma-bufs are imported by another instance of our driver,
> that instance will typically have the imported dma-bufs locked during
> dma_buf_map_attachment(). But the exporter also locks the
On Tue, Jul 13, 2021 at 9:40 AM Daniel Vetter wrote:
>
> On Mon, Jul 12, 2021 at 06:12:33PM -0500, Jason Ekstrand wrote:
> > From: Thomas Hellström
> >
> > If our exported dma-bufs are imported by another instance of our driver,
> > that instance will typically have the imported dma-bufs locked d
On Mon, Jul 12, 2021 at 06:12:34PM -0500, Jason Ekstrand wrote:
> From: Thomas Hellström
>
> Until we support p2p dma or as a complement to that, migrate data
> to system memory at dma-buf attach time if possible.
>
> v2:
> - Rebase on dynamic exporter. Update the igt_dmabuf_import_same_driver
>
On Tue, 13 Jul 2021 at 15:44, Daniel Vetter wrote:
>
> On Mon, Jul 12, 2021 at 06:12:34PM -0500, Jason Ekstrand wrote:
> > From: Thomas Hellström
> >
> > Until we support p2p dma or as a complement to that, migrate data
> > to system memory at dma-buf attach time if possible.
> >
> > v2:
> > - Re
Am 13.07.21 um 11:10 schrieb Daniel Vetter:
On Tue, Jul 13, 2021 at 9:25 AM Christian König
wrote:
Am 13.07.21 um 08:50 schrieb Daniel Vetter:
On Tue, Jul 13, 2021 at 8:35 AM Christian König
wrote:
Am 12.07.21 um 19:53 schrieb Daniel Vetter:
It might be good enough on x86 with just READ_ONC
On Tue, Jul 13, 2021 at 04:06:13PM +0100, Matthew Auld wrote:
> On Tue, 13 Jul 2021 at 15:44, Daniel Vetter wrote:
> >
> > On Mon, Jul 12, 2021 at 06:12:34PM -0500, Jason Ekstrand wrote:
> > > From: Thomas Hellström
> > >
> > > Until we support p2p dma or as a complement to that, migrate data
> >
On Tue, Jul 13, 2021 at 11:45:50AM +0100, Matthew Auld wrote:
> + /**
> + * @cache_coherent:
> + *
> + * Track whether the pages are coherent with the GPU if reading or
> + * writing through the CPU cache.
> + *
> + * This largely depends on the @cache_level, for e
On Tue, 13 Jul 2021 at 16:55, Ville Syrjälä
wrote:
>
> On Tue, Jul 13, 2021 at 11:45:50AM +0100, Matthew Auld wrote:
> > + /**
> > + * @cache_coherent:
> > + *
> > + * Track whether the pages are coherent with the GPU if reading or
> > + * writing through the CPU cache.
> >
Switch JSL/EHL to use a revid->stepping table as we're trying to do on
all platforms going forward.
v2:
- Use COMMON_STEPPING(). (Anusha)
Bspec: 29153
Cc: Anusha Srivatsa
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 2 +-
drivers/gpu/drm/i915/gt/intel_workaro
== Series Details ==
Series: drm/fb-helper: Try to protect cleanup against delayed setup
URL : https://patchwork.freedesktop.org/series/92478/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
b0ba74e0d5e3 drm/fb-helper: Try to protect cleanup against delayed setup
-:18: WARNING:CO
On Tue, Jul 13, 2021 at 6:11 PM Andrey Grodzovsky
wrote:
> On 2021-07-13 5:10 a.m., Daniel Vetter wrote:
> > On Tue, Jul 13, 2021 at 9:25 AM Christian König
> > wrote:
> >> Am 13.07.21 um 08:50 schrieb Daniel Vetter:
> >>> On Tue, Jul 13, 2021 at 8:35 AM Christian König
> >>> wrote:
> Am 12
On Tue, Jul 13, 2021 at 6:14 PM Matthew Auld
wrote:
> On Tue, 13 Jul 2021 at 16:55, Ville Syrjälä
> wrote:
> >
> > On Tue, Jul 13, 2021 at 11:45:50AM +0100, Matthew Auld wrote:
> > > + /**
> > > + * @cache_coherent:
> > > + *
> > > + * Track whether the pages are coherent with
On Mon, Jul 12, 2021 at 1:02 PM Daniel Vetter wrote:
>
> There's only one exclusive slot, and we must not break the ordering.
>
> Adding a new exclusive fence drops all previous fences from the
> dma_resv. To avoid violating the signalling order we err on the side of
> over-synchronizing by waitin
> -Original Message-
> From: Roper, Matthew D
> Sent: Tuesday, July 13, 2021 9:15 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Srivatsa, Anusha ; Roper, Matthew D
>
> Subject: [PATCH v3 08/12] drm/i915/jsl_ehl: Use revid->stepping tables
>
> Switch JSL/EHL to use a revid->stepping t
On Tue, Jul 13, 2021 at 6:51 PM Rob Clark wrote:
>
> On Mon, Jul 12, 2021 at 1:02 PM Daniel Vetter wrote:
> >
> > There's only one exclusive slot, and we must not break the ordering.
> >
> > Adding a new exclusive fence drops all previous fences from the
> > dma_resv. To avoid violating the signa
On Tue, 2021-07-13 at 03:31 +, Patchwork wrote:
Patch Details
Series: series starting with [CI,1/6] drm/i915/display: Settle on "adl-x" in WA
comments
URL:https://patchwork.freedesktop.org/series/92457/
State: success
Details:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_205
> -Original Message-
> From: Roper, Matthew D
> Sent: Monday, July 12, 2021 3:56 PM
> To: Srivatsa, Anusha
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [PATCH v2 09/12] drm/i915/rkl: Use revid->stepping tables
>
> On Mon, Jul 12, 2021 at 03:51:15PM -0700, Srivatsa, Anusha wrot
== Series Details ==
Series: drm/fb-helper: Try to protect cleanup against delayed setup
URL : https://patchwork.freedesktop.org/series/92478/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10341 -> Patchwork_20587
Summary
-
> -Original Message-
> From: Roper, Matthew D
> Sent: Friday, July 9, 2021 8:37 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Srivatsa, Anusha ; Roper, Matthew D
>
> Subject: [PATCH v2 10/12] drm/i915/dg1: Use revid->stepping tables
>
> Switch DG1 to use a revid->stepping table as we
> -Original Message-
> From: Roper, Matthew D
> Sent: Friday, July 9, 2021 8:37 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Srivatsa, Anusha ; Roper, Matthew D
>
> Subject: [PATCH v2 12/12] drm/i915/icl: Drop workarounds that only apply to
> pre-production steppings
>
> We're past
Hello All,
Very sorry to bother you all again. Kindly can you help so that we can close on
this please?
We have submitted both IGT and kernel patches. If none are okay, should we skip
the subtest for panels which have width not 64 byte aligned for Intel platforms?
https://patchwork.freedesktop.
> -Original Message-
> From: Roper, Matthew D
> Sent: Friday, July 9, 2021 8:37 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Srivatsa, Anusha ; Roper, Matthew D
>
> Subject: [PATCH v2 02/12] drm/i915: Make pre-production detection use
> direct revid comparison
>
> Although we're con
> -Original Message-
> From: Roper, Matthew D
> Sent: Friday, July 9, 2021 8:37 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Srivatsa, Anusha ; Roper, Matthew D
>
> Subject: [PATCH v2 04/12] drm/i915/kbl: Drop pre-production revision from
> stepping table
>
> We're long past the poi
== Series Details ==
Series: drm/i915/gtt: drop the page table optimisation
URL : https://patchwork.freedesktop.org/series/92474/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10339_full -> Patchwork_20586_full
Summary
Switch DG1 to use a revid->stepping table as we're trying to do on all
platforms going forward.
This removes the last use of IS_REVID() and REVID_FOREVER, so remove
those now-unused macros as well to prevent their accidental use on
future platforms.
v2:
- Use COMMON_STEPPING() macro in table. (
> -Original Message-
> From: Roper, Matthew D
> Sent: Tuesday, July 13, 2021 10:29 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Srivatsa, Anusha ; Roper, Matthew D
>
> Subject: [PATCH v3 10/12] drm/i915/dg1: Use revid->stepping tables
>
> Switch DG1 to use a revid->stepping table as
On Tue, Jul 13, 2021 at 9:58 AM Daniel Vetter wrote:
>
> On Tue, Jul 13, 2021 at 6:51 PM Rob Clark wrote:
> >
> > On Mon, Jul 12, 2021 at 1:02 PM Daniel Vetter
> > wrote:
> > >
> > > There's only one exclusive slot, and we must not break the ordering.
> > >
> > > Adding a new exclusive fence dr
On Tue, Jul 13, 2021 at 7:42 PM Rob Clark wrote:
> On Tue, Jul 13, 2021 at 9:58 AM Daniel Vetter wrote:
> >
> > On Tue, Jul 13, 2021 at 6:51 PM Rob Clark wrote:
> > >
> > > On Mon, Jul 12, 2021 at 1:02 PM Daniel Vetter
> > > wrote:
> > > >
> > > > There's only one exclusive slot, and we must n
On Tue, Jul 13, 2021 at 05:13:37PM +0100, Matthew Auld wrote:
> On Tue, 13 Jul 2021 at 16:55, Ville Syrjälä
> wrote:
> >
> > On Tue, Jul 13, 2021 at 11:45:50AM +0100, Matthew Auld wrote:
> > > + /**
> > > + * @cache_coherent:
> > > + *
> > > + * Track whether the pages are coher
On Fri, Jul 09, 2021 at 08:37:15PM -0700, Matt Roper wrote:
Switch SKL to use a revid->stepping table as we're trying to do on all
platforms going forward. Also drop the preproduction revisions and add
the newer steppings we hadn't already handled.
Note that SKL has a case where a newer revisio
On Monday, July 5, 2021 6:53:08 AM PDT Matthew Auld wrote:
> It's a noop on DG1, and in the future when need to support other devices
> which let us control the coherency, then it should be an immutable
> creation time property for the BO. This will likely be controlled
> through a new gem_create_e
On Tue, 13 Jul 2021 at 18:47, Ville Syrjälä
wrote:
>
> On Tue, Jul 13, 2021 at 05:13:37PM +0100, Matthew Auld wrote:
> > On Tue, 13 Jul 2021 at 16:55, Ville Syrjälä
> > wrote:
> > >
> > > On Tue, Jul 13, 2021 at 11:45:50AM +0100, Matthew Auld wrote:
> > > > + /**
> > > > + * @cache_coher
On 6/24/2021 00:04, Matthew Brost wrote:
Ensure G2H response has space in the buffer before sending H2G CTB as
the GuC can't handle any backpressure on the G2H interface.
Signed-off-by: John Harrison
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 13 +++-
d
skl_compute_plane_wm_params() didn't take into account ccs
modifiers on graphics ver >= 12
Signed-off-by: Juha-Pekka Heikkila
---
drivers/gpu/drm/i915/intel_pm.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel
On Tue, Jul 13, 2021 at 07:24:23PM +0100, Matthew Auld wrote:
> On Tue, 13 Jul 2021 at 18:47, Ville Syrjälä
> wrote:
> >
> > On Tue, Jul 13, 2021 at 05:13:37PM +0100, Matthew Auld wrote:
> > > On Tue, 13 Jul 2021 at 16:55, Ville Syrjälä
> > > wrote:
> > > >
> > > > On Tue, Jul 13, 2021 at 11:45:5
== Series Details ==
Series: Minor revid/stepping and workaround cleanup (rev4)
URL : https://patchwork.freedesktop.org/series/92299/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
62d758aadfe3 drm/i915/step: s/_revid_tbl/_revids
76bd03989163 drm/i915: Make pre-production detect
On Fri, 2021-07-09 at 20:37 -0700, Matt Roper wrote:
> Switch ICL to use a revid->stepping table as we're trying to do on all
> platforms going forward. While we're at it, let's include some
> additional steppings that have popped up, even if we don't yet have any
> workarounds tied to those stepp
Switch GLK to use a revid->stepping table as we're trying to do on all
platforms going forward. Pre-production and placeholder revisions are
omitted.
Although nothing in the code is using the data from this table at the
moment, we expect some upcoming DMC patches to start utilizing it.
Bspec: 19
We're long past the point where we need to care about pre-production
hardware, and we already warn the user and taint the kernel if we detect
the driver is being loaded on pre-production hardware.
Bspec: 18329
Signed-off-by: Matt Roper
Reviewed-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/intel
Switch BXT to use a revid->stepping table as we're trying to do on all
platforms going forward. Note that the REVID macros we had before
weren't being used anywhere in the code and weren't even correct; the
table values come from the bspec (and omits all the placeholder and
preproduction revisions
Although we're converting our workarounds to use a revid->stepping
lookup table, the function that detects pre-production hardware should
continue to compare against PCI revision ID values directly. These are
listed in the bspec as integers, so it's easier to confirm their
correctness if we just u
From: Anusha Srivatsa
Simplify the stepping info array name.
Cc: Jani Nikula
Signed-off-by: Anusha Srivatsa
Reviewed-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_step.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel
Switch RKL to use a revid->stepping table as we're trying to do on all
platforms going forward.
Bspec: 44501
Signed-off-by: Matt Roper
Reviewed-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/display/intel_psr.c | 4 ++--
drivers/gpu/drm/i915/i915_drv.h | 8 ++--
drivers/gpu/drm/i915/
Switch ICL to use a revid->stepping table as we're trying to do on all
platforms going forward. While we're at it, let's include some
additional steppings that have popped up, even if we don't yet have any
workarounds tied to those steppings (we probably need to audit our
workaround list soon to s
We're past the point at which we usually drop workarounds that were
never needed on production hardware. The driver will already print an
error and apply taint if loaded on pre-production hardware.
Signed-off-by: Matt Roper
Reviewed-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/gt/intel_workaro
Switch JSL/EHL to use a revid->stepping table as we're trying to do on
all platforms going forward.
v2:
- Use COMMON_STEP(). (Anusha)
Bspec: 29153
Cc: Anusha Srivatsa
Signed-off-by: Matt Roper
Reviewed-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 2 +-
drivers/gpu
PCI revision IDs don't always map to GT and display IP steppings in an
intuitive/sensible way. On many of our recent platforms we've switched
to using revid->stepping lookup tables with the infrastructure in
intel_step.c to handle stepping lookups and comparisons. This series
converts several of
All of the Cannon Lake hardware that came out had graphics fused off,
and our userspace drivers have already dropped their support for the
platform; CNL-specific code in i915 that isn't inherited by subsequent
platforms is effectively dead code. Let's remove all of the
CNL-specific workarounds as
Switch SKL to use a revid->stepping table as we're trying to do on all
platforms going forward. Also drop the preproduction revisions and add
the newer steppings we hadn't already handled.
Note that SKL has a case where a newer revision ID corresponds to an
older GT/disp stepping (0x9 -> STEP_J0,
Switch DG1 to use a revid->stepping table as we're trying to do on all
platforms going forward.
This removes the last use of IS_REVID() and REVID_FOREVER, so remove
those now-unused macros as well to prevent their accidental use on
future platforms.
v2:
- Use COMMON_STEP() macro in table. (Anus
== Series Details ==
Series: Minor revid/stepping and workaround cleanup (rev4)
URL : https://patchwork.freedesktop.org/series/92299/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10342 -> Patchwork_20588
Summary
---
On Fri, Jul 09, 2021 at 08:37:19PM -0700, Matt Roper wrote:
Switch ICL to use a revid->stepping table as we're trying to do on all
platforms going forward. While we're at it, let's include some
additional steppings that have popped up, even if we don't yet have any
workarounds tied to those step
On Thu, Jul 1, 2021 at 9:07 AM Maarten Lankhorst
wrote:
> Op 30-06-2021 om 18:44 schreef Ville Syrjala:
> > From: Ville Syrjälä
> >
> > The conversion to ww mutexes failed to address the fence code which
> > already returns -EDEADLK when we run out of fences. Ww mutexes on
> > the other hand trea
On Tue, Jul 13, 2021 at 9:58 PM Daniel Vetter wrote:
>
> On Thu, Jul 1, 2021 at 9:07 AM Maarten Lankhorst
> wrote:
> > Op 30-06-2021 om 18:44 schreef Ville Syrjala:
> > > From: Ville Syrjälä
> > >
> > > The conversion to ww mutexes failed to address the fence code which
> > > already returns -ED
On Tue, Jul 13, 2021 at 12:57:07PM -0700, Lucas De Marchi wrote:
> On Fri, Jul 09, 2021 at 08:37:19PM -0700, Matt Roper wrote:
> > Switch ICL to use a revid->stepping table as we're trying to do on all
> > platforms going forward. While we're at it, let's include some
> > additional steppings that
On Tue, Jul 13, 2021 at 12:59:53PM -0700, Matt Roper wrote:
On Tue, Jul 13, 2021 at 12:57:07PM -0700, Lucas De Marchi wrote:
On Fri, Jul 09, 2021 at 08:37:19PM -0700, Matt Roper wrote:
> Switch ICL to use a revid->stepping table as we're trying to do on all
> platforms going forward. While we'r
On Tue, Jul 13, 2021 at 12:36:26PM -0700, Matt Roper wrote:
Switch SKL to use a revid->stepping table as we're trying to do on all
platforms going forward. Also drop the preproduction revisions and add
the newer steppings we hadn't already handled.
Note that SKL has a case where a newer revisio
On 2021-07-13 5:10 a.m., Daniel Vetter wrote:
On Tue, Jul 13, 2021 at 9:25 AM Christian König
wrote:
Am 13.07.21 um 08:50 schrieb Daniel Vetter:
On Tue, Jul 13, 2021 at 8:35 AM Christian König
wrote:
Am 12.07.21 um 19:53 schrieb Daniel Vetter:
It might be good enough on x86 with just READ_
On Tue, Jul 13, 2021 at 09:44:21PM +0300, Juha-Pekka Heikkila wrote:
skl_compute_plane_wm_params() didn't take into account ccs
modifiers on graphics ver >= 12
Signed-off-by: Juha-Pekka Heikkila
Reviewed-by: Lucas De Marchi
Lucas De Marchi
---
drivers/gpu/drm/i915/intel_pm.c | 6 ++
1
On Tue, Jul 13, 2021 at 09:59:18PM +0200, Daniel Vetter wrote:
> On Tue, Jul 13, 2021 at 9:58 PM Daniel Vetter wrote:
> >
> > On Thu, Jul 1, 2021 at 9:07 AM Maarten Lankhorst
> > wrote:
> > > Op 30-06-2021 om 18:44 schreef Ville Syrjala:
> > > > From: Ville Syrjälä
> > > >
> > > > The conversion
Hi Daniel,
On Tue, Jul 13, 2021 at 03:59:22PM +0200, Daniel Vetter wrote:
> Some vague evidences suggests this can go wrong. Try to prevent it by
> holding the right mutex and clearing ->deferred_setup to make sure we
> later on don't accidentally try to re-register the fbdev when the
> driver tho
On Tue, Jul 13, 2021 at 09:59:18PM +0200, Daniel Vetter wrote:
> On Tue, Jul 13, 2021 at 9:58 PM Daniel Vetter wrote:
> >
> > On Thu, Jul 1, 2021 at 9:07 AM Maarten Lankhorst
> > wrote:
> > > Op 30-06-2021 om 18:44 schreef Ville Syrjala:
> > > > From: Ville Syrjälä
> > > >
> > > > The conversion
== Series Details ==
Series: drm/i915: Fix wm params for ccs
URL : https://patchwork.freedesktop.org/series/92491/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10342 -> Patchwork_20589
Summary
---
**SUCCESS**
No
MIPI DSI initialization on EHL can fail due to not enough header credits
available.
To resolve this failure, this patch adds a header count to the existing 100us
wait function.
It then adds a call to this modified function to request a single header credit
during initialization.
Reviewed-by:
On Tue, Jul 13, 2021 at 09:34:09AM +0800, Lu Baolu wrote:
> On 7/12/21 11:47 PM, Ville Syrjälä wrote:
> > On Mon, Jul 12, 2021 at 07:23:07AM +0800, Lu Baolu wrote:
> >> On 7/10/21 12:47 AM, Ville Syrjala wrote:
> >>> From: Ville Syrjälä
> >>>
> >>> While running "gem_exec_big --r single" from igt-g
Tested and confirmed working on TGL-H Dell platforms.
David Box
Linux Power Management
IAGS/SSE
From: Gupta, Anshuman
Sent: Monday, July 12, 2021 12:09 AM
To: intel-gfx@lists.freedesktop.org
Cc: Box, David E ; Gupta, Anshuman
; Roper, Matthew D ; Vivi,
Rodrigo
Hi all
I've found another potential issue, so lets try this again and see what
intel-gfx-ci says. Also Thomas tried to unify vgem more, which motivated
me to dig this all out again.
Test-with: 20210527140732.5762-1-daniel.vet...@ffwll.ch
Review very much welcome, as always!
Cheers, Daniel
Dani
tldr; DMA buffers aren't normal memory, expecting that you can use
them like that (like calling get_user_pages works, or that they're
accounting like any other normal memory) cannot be guaranteed.
Since some userspace only runs on integrated devices, where all
buffers are actually all resident sys
intel-gfx-ci realized that something is not quite coherent anymore on
some platforms for our i915+vgem tests, when I tried to switch vgem
over to shmem helpers.
After lots of head-scratching I realized that I've removed calls to
drm_clflush. And we need those. To make this a bit cleaner use the
sa
We want to stop gup, which isn't the case if we use vmf_insert_page
and VM_MIXEDMAP, because that does not set pte_special.
v2: With this shmem gem helpers now definitely need CONFIG_MMU (0day)
v3: add more depends on MMU. For usb drivers this is a bit awkward,
but really it's correct: To be able
1 - 100 of 167 matches
Mail list logo
