On Wed, Jul 14, 2021 at 10:05:07PM -0700, Anusha Srivatsa wrote:
Lets use RUNTIME_INFO->step since all platforms now have their
stepping info in intel_step.c. This makes intel_get_stepping_info()
a lot simpler.
Cc: Lucas De Marchi
Signed-off-by: Anusha Srivatsa
Given the patches from Matt we
On Wed, Jul 14, 2021 at 10:05:06PM -0700, Anusha Srivatsa wrote:
With the addition of stepping info for
all platforms, lets use macros for handling them
and autogenerating code for all steps at a time.
Suggested-by: Matt Roper
Cc: Lucas De Marchi
Signed-off-by: Anusha Srivatsa
Reviewed-by:
On Wed, Jul 14, 2021 at 11:01 PM Jason Ekstrand wrote:
>
> On Tue, Jul 13, 2021 at 10:23 AM Daniel Vetter wrote:
> >
> > 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
Lets use RUNTIME_INFO->step since all platforms now have their
stepping info in intel_step.c. This makes intel_get_stepping_info()
a lot simpler.
Cc: Lucas De Marchi
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/display/intel_dmc.c | 50
1 file changed, 8 inse
With the addition of stepping info for
all platforms, lets use macros for handling them
and autogenerating code for all steps at a time.
Suggested-by: Matt Roper
Cc: Lucas De Marchi
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/intel_step.c | 14
drivers/gpu/drm/i915/int
The user can open multiple device FDs if it likes, however the open
function calls vfio_register_notifier() on device global state. Calling
vfio_register_notifier() twice will trigger a WARN_ON from
notifier_chain_register() and the first close will wrongly delete the
notifier and more.
Since thes
FSL uses the internal reflck to implement the open_device() functionality,
conversion to the core code is straightforward.
The decision on which set to be part of is trivially based on the
is_fsl_mc_bus_dprc() and we use a 'struct device *' pointer as the set_id.
It isn't entirely clear what the
mbochs_close() iterates over global device state and frees it. Currently
this is done every time a device FD is closed, but if multiple device FDs
are open this could corrupt other still active FDs.
Change this to use close_device() so it only runs on the last close.
Signed-off-by: Jason Gunthorp
The core code no longer requires these ops to be defined, so delete these
empty functions and leave the op as NULL. mtty's functions only log a
pointless message, delete that entirely.
Signed-off-by: Yishai Hadas
Signed-off-by: Jason Gunthorpe
---
samples/vfio-mdev/mbochs.c | 6 --
samples
From: Yishai Hadas
PCI wants to have the usual open/close_device() logic with the slight
twist that the open/close_device() must be done under a singelton lock
shared by all of the vfio_devices that are in the PCI "reset group".
The reset group, and thus the device set, is determined by what dev
Keep track of all the vfio_devices that have been added to the device set
and use this list in vfio_pci_try_bus_reset() instead of trying to work
backwards from the pci_device.
The dev_set->lock directly prevents devices from joining/leaving the set,
which further implies the pci_device cannot cha
From: Max Gurtovoy
This pairs with vfio_init_group_dev() and allows undoing any state that is
stored in the vfio_device unrelated to registration. Add appropriately
placed calls to all the drivers.
The following patch will use this to add pre-registration state for the
device set.
Signed-off-by
Platform simply wants to run some code when the device is first
opened/last closed. Use the core framework and locking for this. Aside
from removing a bit of code this narrows the locking scope from a global
lock.
Signed-off-by: Yishai Hadas
Signed-off-by: Jason Gunthorpe
---
drivers/vfio/plat
The user can open multiple device FDs if it likes, however these open()
functions call vfio_register_notifier() on some device global
state. Calling vfio_register_notifier() twice in will trigger a WARN_ON
from notifier_chain_register() and the first close will wrongly delete the
notifier and more.
Prologue:
This is the first series of three to send the "mlx5_vfio_pci" driver that has
been discussed on the list for a while now.
- Reorganize reflck to support splitting vfio_pci
- Split vfio_pci into vfio_pci/vfio_pci_core and provide infrastructure
for non-generic VFIO PCI drivers
- The
Nothing uses this anymore, delete it.
Signed-off-by: Yishai Hadas
Signed-off-by: Jason Gunthorpe
---
drivers/vfio/mdev/vfio_mdev.c | 22 --
drivers/vfio/vfio.c | 14 +-
include/linux/mdev.h | 7 ---
include/linux/vfio.h | 4
Like vfio_pci_try_bus_reset() this code wants to reset all of the devices
in the "reset group" which is the same membership as the device set.
Instead of trying to reconstruct the device set from the PCI list go
directly from the device set's device list to execute the reset.
The same basic struc
The patch to move the get/put to core and the patch to convert the samples
to use vfio_device crossed in a way that this was missed. When both
patches are together the samples do not need their own get/put.
Fixes: 437e41368c01 ("vfio/mdpy: Convert to use vfio_register_group_dev()")
Fixes: 681c1615
Currently the driver ops have an open/release pair that is called once
each time a device FD is opened or closed. Add an additional set of
open/close_device() ops which are called when the device FD is opened for
the first time and closed for the last time.
An analysis shows that all of the driver
Hi all,
Commit
db47fe727e1f ("drm/i915/step: s/_revid_tbl/_revids")
is missing a Signed-off-by from its committer.
--
Cheers,
Stephen Rothwell
pgpibXSRKsvDB.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.fre
Hi,
Here's one fix of shadow ppgtt invalidation with proper vGPU D3 state tracking.
Thanks
--
The following changes since commit 62fb9874f5da54fdb243003b386128037319b219:
Linux 5.13 (2021-06-27 15:21:11 -0700)
are available in the Git repository at:
https://github.com/intel/gvt-linux tags
On 2021-07-13 12:45 p.m., Daniel Vetter wrote:
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
On 7/10/2021 10:37 AM, Michal Wajdeczko wrote:
On 10.07.2021 03:20, Vinay Belgaumkar wrote:
Add methods for interacting with guc for enabling SLPC. Enable
SLPC after guc submission has been established. GuC load will
s/guc/GuC
fail if SLPC cannot be successfully initialized. Add various
On 6/24/2021 12:04 AM, Matthew Brost wrote:
If two requests are on the same ring, they are explicitly ordered by the
HW. So, a submission fence is sufficient to ensure ordering when using
the new GuC submission interface. Conversely, if two requests share a
timeline and are on the same physical
On 6/24/2021 12:04 AM, Matthew Brost wrote:
Implement GuC virtual engines. Rather simple implementation, basically
just allocate an engine, setup context enter / exit function to virtual
engine specific functions, set all other variables / functions to guc
versions, and set the engine mask to t
On Wed, Jul 14, 2021 at 08:48:12AM +, Patchwork wrote:
> == Series Details ==
>
> Series: Minor revid/stepping and workaround cleanup (rev5)
> URL : https://patchwork.freedesktop.org/series/92299/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_10343_full -> Patchw
On Mon, Jul 12, 2021 at 12:58:45PM -0700, John Harrison wrote:
> On 6/24/2021 00:05, Matthew Brost wrote:
> > Reset implementation for new GuC interface. This is the legacy reset
> > implementation which is called when the i915 owns the engine hang check.
> > Future patches will offload the engine
On Thu, Jun 24, 2021 at 12:05:16AM -0700, Matthew Brost wrote:
> From: Daniele Ceraolo Spurio
>
> Unblock GuC submission on Gen11+ platforms.
>
> Signed-off-by: Michal Wajdeczko
> Signed-off-by: Daniele Ceraolo Spurio
> Signed-off-by: Matthew Brost
Updating debug message per feedback, with t
On Thu, Jun 24, 2021 at 12:05:11AM -0700, Matthew Brost wrote:
> From: John Harrison
>
> In the case of a full GPU reset (e.g. because GuC has died or because
> GuC's hang detection has been disabled), the driver can't rely on GuC
> reporting the guilty context. Instead, the driver needs to scan
On Mon, Jul 12, 2021 at 03:58:12PM -0700, John Harrison wrote:
> On 6/24/2021 00:05, Matthew Brost wrote:
> > GuC will issue a reset on detecting an engine hang and will notify
> > the driver via a G2H message. The driver will service the notification
> > by resetting the guilty context to a simple
On 7/14/2021 17:06, Matthew Brost wrote:
On Tue, Jul 13, 2021 at 11:36:05AM -0700, John Harrison wrote:
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
On Fri, Jul 09, 2021 at 04:53:37PM -0700, John Harrison wrote:
> On 6/24/2021 00:04, Matthew Brost wrote:
> > Semaphores are an optimization and not required for basic GuC submission
> > to work properly. Disable until we have time to do the implementation to
> > enable semaphores and tune them for
On Tue, Jul 13, 2021 at 11:36:05AM -0700, John Harrison wrote:
> 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-b
On Tue, Jul 13, 2021 at 10:51:35AM +0200, Michal Wajdeczko wrote:
>
>
> 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
Currently when we do the HW state readout, we dont set the shared dpll to NULL
for the bigjoiner slave which should not have a DPLL assigned. So it has
some garbage while the HW state readout is NULL. So explicitly reset
the shared dpll for bigjoiner slave pipe.
Bug: https://gitlab.freedesktop.org
On Tue, Jul 13, 2021 at 10:23 AM Daniel Vetter wrote:
>
> 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
> > > >
> > >
We don't roll them together entirely because there are still a couple
cases where we want a separate can_migrate check. For instance, the
display code checks that you can migrate a buffer to LMEM before it
accepts it in fb_create. The dma-buf import code also uses it to do an
early check and retu
skl_compute_wm_params() didn't take into account ccs modifiers
on graphics ver >= 12
v2 (Imre): Don't set rc_surface flag for mc ccs.
Signed-off-by: Juha-Pekka Heikkila
---
drivers/gpu/drm/i915/intel_pm.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm
This reverts the rest of 0edbb9ba1bfe ("drm/i915: Move cmd parser
pinning to execbuffer"). Now that the only user of i915_gem_object_get_sg
without allow_alloc has been removed, we can drop the parameter. This
portion of the revert was broken into its own patch to aid review.
Signed-off-by: Jaso
Asynchronous command parsing was the only thing which ever returned a
non-zero error. With that gone, we can drop the error handling from
dma_fence_work.
Signed-off-by: Jason Ekstrand
Reviewed-by: Jon Bloomfield
Acked-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_clflush.c | 4 +---
This reverts a6c5e2aea704 ("drm/i915: Skip over MI_NOOP when parsing").
It complicates the batch parsing code a bit and increases indentation
for no reason other than fast-skipping a command that userspace uses
only rarely. Sure, there may be IGT tests that fill batches with NOOPs
but that's not a
This reverts commit 9e31c1fe45d555a948ff66f1f0e3fe1f83ca63f7. Ever
since that commit, we've been having issues where a hang in one client
can propagate to another. In particular, a hang in an app can propagate
to the X server which causes the whole desktop to lock up.
Error propagation along fen
This reverts 686c7c35abc2 ("drm/i915/gem: Asynchronous cmdparser"). The
justification for this commit in the git history was a vague comment
about getting it out from under the struct_mutex. While this may
improve perf for some workloads on Gen7 platforms where we rely on the
command parser for f
Fence error propagation is sketchy at best. Instead of explicitly handling
fences which might have errors set in the code which is aware of errors, we
just kick them down the line and hope that userspace knows what to do when
a wait eventually fails. This is sketchy at best because most userspace
On Wed, Jul 14, 2021 at 12:05 PM Maarten Lankhorst
wrote:
>
> Op 14-07-2021 om 18:17 schreef Jason Ekstrand:
> > On Wed, Jul 14, 2021 at 5:03 AM Maarten Lankhorst
> > wrote:
> >> The FIXED mapping is only used for ttm, and tells userspace that the
> >> mapping type is pre-defined. This disables t
Am 30.06.21 um 17:10 schrieb Werner Sembach:
This commit implements the "Broadcast RGB" drm property for the AMD GPU
driver.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 14 +++---
.../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c| 4
Am 01.07.21 um 13:30 schrieb Werner Sembach:
Am 01.07.21 um 09:42 schrieb Pekka Paalanen:
On Wed, 30 Jun 2021 11:42:10 +0200
Werner Sembach wrote:
Am 30.06.21 um 10:21 schrieb Pekka Paalanen:
On Tue, 29 Jun 2021 13:02:05 +0200
Werner Sembach wrote:
Am 28.06.21 um 19:03 schrieb Werner Se
Am 06.07.21 um 09:09 schrieb Pekka Paalanen:
On Mon, 5 Jul 2021 17:49:42 +0200
Werner Sembach wrote:
Am 01.07.21 um 15:24 schrieb Pekka Paalanen:
On Thu, 1 Jul 2021 14:50:13 +0200
Werner Sembach wrote:
Am 01.07.21 um 10:07 schrieb Pekka Paalanen:
On Wed, 30 Jun 2021 11:20:18 +0200
We
The gvt component of this driver has ~120 pr_debugs, in 9 "classes".
Following the interface model of drm.debug, add a parameter to map
bits to these classes.
If CONFIG_DRM_USE_DYNAMIC_DEBUG=y (and CONFIG_DYNAMIC_DEBUG_CORE), add
-DDYNAMIC_DEBUG_MODULE into Makefile. TBD: maybe add a separate
CON
commit 7911902129a8 ("drm/print: Handle potentially NULL drm_devices
in drm_dbg_*") added a maybe(deref) to 6 macro invocations of
drm_dev_dbg().
Commit 01ff672190bd("drm: RFC add choice to use dynamic debug in
drm-debug") then renamed that fn to _drm_dev_dbg(), and redefined
drm_dev_dbg() as a ma
drm's debug system uses distinct categories of debug messages, encoded
in an enum (DRM_UT_), which are mapped to bits in drm.debug.
drm_debug_enabled() does a lot of unlikely bit-mask checks on
drm.debug; we can use dynamic debug instead, and get all that
static_key/jump_label goodness.
Dynamic de
whitespace only, to minimize the diff of a later commit.
no functional changes
Signed-off-by: Jim Cromie
---
include/drm/drm_print.h | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index 15a089a87c22..ff5
s/prink/printk/ - no functional changes
Signed-off-by: Jim Cromie
---
include/drm/drm_print.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index 9b66be54dd16..15a089a87c22 100644
--- a/include/drm/drm_print.h
+++ b/include/
hi dri-devel,
Im pretty new in this particular playground.
Im using this to send, is it too spammy ? too --to ?
git send-email --dry-run \
--to-cmd='scripts/get_maintainer.pl --no-rolestats v3-000*.patch' \
--to=jba...@akamai.com v3-000*.patch
drm_debug_enabled() is called a lot (by drm_
Op 14-07-2021 om 18:17 schreef Jason Ekstrand:
> On Wed, Jul 14, 2021 at 5:03 AM Maarten Lankhorst
> wrote:
>> The FIXED mapping is only used for ttm, and tells userspace that the
>> mapping type is pre-defined. This disables the other type of mmap
>> offsets when discrete memory is used, so fix t
Am 14.07.21 um 14:48 schrieb Daniel Vetter:
On Wed, Jul 14, 2021 at 01:54:50PM +0200, Christian König wrote:
Am 13.07.21 um 22:51 schrieb Daniel Vetter:
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
On Wed, Jul 14, 2021 at 5:03 AM Maarten Lankhorst
wrote:
>
> The FIXED mapping is only used for ttm, and tells userspace that the
> mapping type is pre-defined. This disables the other type of mmap
> offsets when discrete memory is used, so fix the selftests as well.
>
> Document the struct as wel
On Wed, Jul 14, 2021 at 02:58:26PM +0200, Christian König wrote:
> Am 14.07.21 um 14:48 schrieb Daniel Vetter:
> > On Wed, Jul 14, 2021 at 01:54:50PM +0200, Christian König wrote:
> > > Am 13.07.21 um 22:51 schrieb Daniel Vetter:
> > > > intel-gfx-ci realized that something is not quite coherent an
Re-reported.
From: Juha-Pekka Heikkilä
Sent: Wednesday, July 14, 2021 12:58 AM
To: intel-gfx@lists.freedesktop.org; Vudum, Lakshminarayana
Subject: Re: ✗ Fi.CI.IGT: failure for drm/i915: Fix wm params for ccs
Hi Lakshmi,
Here would be again one false positive result.
/Juha-Pekka
On Wed, Jul
== 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_full -> Patchwork_20589_full
Summary
---
**SUCCES
Am 13.07.21 um 22:51 schrieb Daniel Vetter:
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 nee
== Series Details ==
Series: Begin enabling Xe_HP SDV and DG2 platforms (rev5)
URL : https://patchwork.freedesktop.org/series/92135/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10344_full -> Patchwork_20594_full
Summary
-
> -Original Message-
> From: Manna, Animesh
> Sent: Wednesday, July 14, 2021 6:30 PM
> To: Gupta, Anshuman ; intel-
> g...@lists.freedesktop.org
> Subject: RE: [PATCH] drm/i915/debugfs: DISPLAY_VER 13 lpsp capability
>
>
>
> > -Original Message-
> > From: Gupta, Anshuman
> >
From: Ville Syrjälä
Skylake has known issues with VT-d superpage. Namely frame buffer
compression (FBC) can't be safely used when superpage is enabled.
Currently we're disabling FBC entirely when VT-d is active, but
I think just disabling superpage would be better since FBC can
save some power.
From: Ville Syrjälä
With the iommu driver disabling VT-d superpage it should be
safe to use FBC on SKL/BXT with VT-d otherwise enabled.
Cc: David Woodhouse
Cc: Lu Baolu
Cc: io...@lists.linux-foundation.org
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fbc.c | 16 ---
From: Ville Syrjälä
Broxton has known issues with VT-d superpage. Namely frame buffer
compression (FBC) can't be safely used when superpage is enabled.
Currently we're disabling FBC entirely when VT-d is active, but
I think just disabling superpage would be better since FBC can
save some power.
From: Ville Syrjälä
While running "gem_exec_big --r single" from igt-gpu-tools on
Geminilake as soon as a 2M mapping is made I tend to get a DMAR
write fault. Strangely the faulting address is always a 4K page
and usually very far away from the 2M page that got mapped.
But if no 2M mappings get u
From: Ville Syrjälä
I ran into some kind of fail with VT-d superpage on Geminlake igfx,
so without any better ideas let's just disable it.
Additionally Skylake/Broxton igfx have known issues with VT-d
superpage as well, so let's disable it there as well. This should
let us re-enable frame buffer
> -Original Message-
> From: Gupta, Anshuman
> Sent: Tuesday, July 13, 2021 1:28 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Gupta, Anshuman ; Manna, Animesh
>
> Subject: [PATCH] drm/i915/debugfs: DISPLAY_VER 13 lpsp capability
>
> Extend i915_lpsp_capability debugfs to DG2,ADLP an
On Wed, Jul 14, 2021 at 02:42:53PM +0300, Ville Syrjälä wrote:
> On Wed, Jul 14, 2021 at 01:16:57PM +0200, Daniel Vetter wrote:
> > On Tue, Jul 13, 2021 at 09:46:30PM +0300, Ville Syrjälä wrote:
> > > On Tue, Jul 13, 2021 at 07:24:23PM +0100, Matthew Auld wrote:
> > > > On Tue, 13 Jul 2021 at 18:47
On Wed, Jul 14, 2021 at 01:54:50PM +0200, Christian König wrote:
> Am 13.07.21 um 22:51 schrieb Daniel Vetter:
> > 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
Aside from deleting lots of code the real motivation here is to switch
the mmap over to VM_PFNMAP, to be more consistent with what real gpu
drivers do. They're all VM_PFNMP, which means get_user_pages doesn't
work, and even if you try and there's a struct page behind that,
touching it and mucking a
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
> ---
> drivers/gpu/drm/i915/intel_pm.c | 6 ++
> 1 file changed, 2 insertions(+), 4 dele
The FIXED mapping is only used for ttm, and tells userspace that the
mapping type is pre-defined. This disables the other type of mmap
offsets when discrete memory is used, so fix the selftests as well.
Document the struct as well, so it shows up in docbook.
Cc: Jason Ekstrand
Reviewed-by: Danie
On Wed, Jul 14, 2021 at 02:42:53PM +0300, Ville Syrjälä wrote:
> On Wed, Jul 14, 2021 at 01:16:57PM +0200, Daniel Vetter wrote:
> > On Tue, Jul 13, 2021 at 09:46:30PM +0300, Ville Syrjälä wrote:
> > > On Tue, Jul 13, 2021 at 07:24:23PM +0100, Matthew Auld wrote:
> > > > On Tue, 13 Jul 2021 at 18:47
On Wed, Jul 14, 2021 at 01:16:57PM +0200, Daniel Vetter wrote:
> On Tue, Jul 13, 2021 at 09:46:30PM +0300, Ville Syrjälä wrote:
> > 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 0
On Tue, Jul 13, 2021 at 11:45:54AM +0100, Matthew Auld wrote:
> 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 wh
On Tue, Jul 13, 2021 at 09:46:30PM +0300, Ville Syrjälä wrote:
> 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,
..snip..
> > > I think the main question I have is how would you like to see patches for
> > > 5.15? i.e. as patches on top of devel/for-linus-5.14 or something else?
> >
> > Yes that would be perfect. If there are any dependencies on the rc1, I
> > can rebase it on top of that.
>
> Yes, please,
The FIXED mapping is only used for ttm, and tells userspace that the
mapping type is pre-defined. This disables the other type of mmap
offsets when discrete memory is used, so fix the selftests as well.
Document the struct as well, so it shows up in docbook.
Cc: Jason Ekstrand
Reviewed-by: Danie
With both review comments by Jani N addressed,
Reviewed-by: Swati Sharma
Thanks and Regards,
Swati
-Original Message-
From: Intel-gfx On Behalf Of Vandita
Kulkarni
Sent: Thursday, July 8, 2021 7:31 PM
To: intel-gfx@lists.freedesktop.org
Cc: Nikula, Jani
Subject: [Intel-gfx] [v2] drm/i
On 2021-07-07 at 11:52:38 +0100, Matthew Auld wrote:
> Currently we pass the devid as if it were the fd, which doesn't work.
>
> Signed-off-by: Matthew Auld
LGTM.
Reviewed-by: Ramalingam C
> Cc: Mohammed Khajapasha
> Cc: Latvala Petri
> Cc: Michael J. Ruhl
> ---
> tests/kms_addfb_basic.c |
== Series Details ==
Series: drm/i915/ehl: Resolve insufficient header credits in MIPI DSI
URL : https://patchwork.freedesktop.org/series/92498/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10343_full -> Patchwork_20591_full
===
On 07/12, Daniel Vetter wrote:
> With the prep work out of the way this isn't tricky anymore.
>
> Aside: The chaining of the various jobs is a bit awkward, with the
> possibility of failure in bad places. I think with the
> drm_sched_job_init/arm split and maybe preloading the
> job->dependencies
On 07/12, Daniel Vetter wrote:
> Prep work for using the scheduler dependency handling. We need to call
> drm_sched_job_init earlier so we can use the new drm_sched_job_await*
> functions for dependency handling here.
>
> v2: Slightly better commit message and rebase to include the
> drm_sched_job
== Series Details ==
Series: drm/i915: Tweaked Wa_14010685332 for all PCHs (rev5)
URL : https://patchwork.freedesktop.org/series/88435/
State : failure
== Summary ==
Applying: drm/i915: Tweaked Wa_14010685332 for all PCHs
error: corrupt patch at line 6
error: could not build fake ancestor
hint
== Series Details ==
Series: Minor revid/stepping and workaround cleanup (rev5)
URL : https://patchwork.freedesktop.org/series/92299/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10343_full -> Patchwork_20590_full
Summary
Hi Lakshmi,
Here would be again one false positive result.
/Juha-Pekka
On Wed, Jul 14, 2021 at 7:38 AM Patchwork
wrote:
> *Patch Details*
> *Series:* drm/i915: Fix wm params for ccs
> *URL:* https://patchwork.freedesktop.org/series/92491/
> *State:* failure
> *Details:*
> https://intel-gfx-ci.
Thanks David for providing Ack on it.
Shall I use your " Tested-by: David E. Box " tag for
this patch ?
Br,
Anshuman Gupta.
From: Box, David E
Sent: Wednesday, July 14, 2021 2:02 AM
To: Gupta, Anshuman ; intel-gfx@lists.freedesktop.org
Cc: Roper, Matthew D ; Vivi, Rodrigo
; Deak, Imre
Subject
89 matches
Mail list logo
