Re: [Intel-gfx] [PATCH 2/2] drm/i915/gem: Migrate to system at dma-buf attach time (v5)

2021-07-14 Thread Daniel Vetter
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

[Intel-gfx] [PATCH 2/2] drm/i915/dmc: Change intel_get_stepping_info()

2021-07-14 Thread Anusha Srivatsa
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

[Intel-gfx] [PATCH 1/2] drm/i915/step: Add macro magic for handling steps

2021-07-14 Thread Anusha Srivatsa
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

[Intel-gfx] [PATCH 12/13] vfio/gvt: Fix open/close when multiple device FDs are open

2021-07-14 Thread Jason Gunthorpe
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

[Intel-gfx] [PATCH 05/13] vfio/fsl: Move to the device set infrastructure

2021-07-14 Thread Jason Gunthorpe
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

[Intel-gfx] [PATCH 10/13] vfio/mbochs: Fix close when multiple device FDs are open

2021-07-14 Thread Jason Gunthorpe
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

[Intel-gfx] [PATCH 04/13] vfio/samples: Delete useless open/close

2021-07-14 Thread Jason Gunthorpe
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 --

[Intel-gfx] [PATCH 07/13] vfio/pci: Move to the device set infrastructure

2021-07-14 Thread Jason Gunthorpe
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

[Intel-gfx] [PATCH 08/13] vfio/pci: Change vfio_pci_try_bus_reset() to use the dev_set

2021-07-14 Thread Jason Gunthorpe
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

[Intel-gfx] [PATCH 02/13] vfio: Introduce a vfio_uninit_group_dev() API call

2021-07-14 Thread Jason Gunthorpe
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.

[Intel-gfx] [PATCH 06/13] vfio/platform: Use open_device() instead of open coding a refcnt scheme

2021-07-14 Thread Jason Gunthorpe
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 ---

[Intel-gfx] [PATCH 11/13] vfio/ap, ccw: Fix open/close when multiple device FDs are open

2021-07-14 Thread Jason Gunthorpe
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

[Intel-gfx] [PATCH 00/13] Provide core infrastructure for managing open/release

2021-07-14 Thread Jason Gunthorpe
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 -

[Intel-gfx] [PATCH 13/13] vfio: Remove struct vfio_device_ops open/release

2021-07-14 Thread Jason Gunthorpe
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

[Intel-gfx] [PATCH 09/13] vfio/pci: Reorganize VFIO_DEVICE_PCI_HOT_RESET to use the device set

2021-07-14 Thread Jason Gunthorpe
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

[Intel-gfx] [PATCH 01/13] vfio/samples: Remove module get/put

2021-07-14 Thread Jason Gunthorpe
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:

[Intel-gfx] [PATCH 03/13] vfio: Provide better generic support for open/release vfio_device_ops

2021-07-14 Thread Jason Gunthorpe
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

[Intel-gfx] linux-next: Signed-off-by missing for commit in the drm-intel tree

2021-07-14 Thread Stephen Rothwell
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] [PULL] gvt-fixes

2021-07-14 Thread Zhenyu Wang
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

Re: [Intel-gfx] [PATCH v4 02/18] drm/sched: Barriers are needed for entity->last_scheduled

2021-07-14 Thread Andrey Grodzovsky
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

Re: [Intel-gfx] [PATCH 07/16] drm/i915/guc/slpc: Enable slpc and add related H2G events

2021-07-14 Thread Belgaumkar, Vinay
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

Re: [Intel-gfx] [PATCH 19/47] drm/i915/guc: Ensure request ordering via completion fences

2021-07-14 Thread Daniele Ceraolo Spurio
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

Re: [Intel-gfx] [PATCH 26/47] drm/i915/guc: GuC virtual engines

2021-07-14 Thread Daniele Ceraolo Spurio
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

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for Minor revid/stepping and workaround cleanup (rev5)

2021-07-14 Thread Matt Roper
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 ->

Re: [Intel-gfx] [PATCH 31/47] drm/i915/guc: Reset implementation for new GuC interface

2021-07-14 Thread Matthew Brost
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

Re: [Intel-gfx] [PATCH 47/47] drm/i915/guc: Unblock GuC submission on Gen11+

2021-07-14 Thread Matthew Brost
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

Re: [Intel-gfx] [PATCH 42/47] drm/i915/guc: Fix for error capture after full GPU reset with GuC

2021-07-14 Thread Matthew Brost
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

Re: [Intel-gfx] [PATCH 35/47] drm/i915/guc: Handle context reset notification

2021-07-14 Thread Matthew Brost
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

Re: [Intel-gfx] [PATCH 21/47] drm/i915/guc: Ensure G2H response has space in buffer

2021-07-14 Thread John Harrison
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:

Re: [Intel-gfx] [PATCH 20/47] drm/i915/guc: Disable semaphores when using GuC scheduling

2021-07-14 Thread Matthew Brost
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

Re: [Intel-gfx] [PATCH 21/47] drm/i915/guc: Ensure G2H response has space in buffer

2021-07-14 Thread Matthew Brost
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 > >

Re: [Intel-gfx] [PATCH 23/47] drm/i915/guc: Update GuC debugfs to support new GuC

2021-07-14 Thread Matthew Brost
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 > > --- > >

[Intel-gfx] [PATCH] drm/i915/display: Fix shared dpll mismatch for bigjoiner slave

2021-07-14 Thread Manasi Navare
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:

Re: [Intel-gfx] [PATCH 2/2] drm/i915/gem: Migrate to system at dma-buf attach time (v5)

2021-07-14 Thread Jason Ekstrand
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 > > > > > > >

[Intel-gfx] [PATCH] drm/i915: Check object_can_migrate from object_migrate

2021-07-14 Thread Jason Ekstrand
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

[Intel-gfx] [PATCH v2] drm/i915: Fix wm params for ccs

2021-07-14 Thread Juha-Pekka Heikkila
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

[Intel-gfx] [PATCH 3/5] drm/i915: Remove allow_alloc from i915_gem_object_get_sg*

2021-07-14 Thread Jason Ekstrand
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:

[Intel-gfx] [PATCH 4/5] drm/i915: Drop error handling from dma_fence_work

2021-07-14 Thread Jason Ekstrand
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 +---

[Intel-gfx] [PATCH 5/5] Revert "drm/i915: Skip over MI_NOOP when parsing"

2021-07-14 Thread Jason Ekstrand
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

[Intel-gfx] [PATCH 2/5] Revert "drm/i915: Propagate errors on awaiting already signaled fences"

2021-07-14 Thread Jason Ekstrand
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

[Intel-gfx] [PATCH 1/5] drm/i915: Revert "drm/i915/gem: Asynchronous cmdparser"

2021-07-14 Thread Jason Ekstrand
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

[Intel-gfx] [PATCH 0/5] drm/i915: Get rid of fence error propagation (v4)

2021-07-14 Thread Jason Ekstrand
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

Re: [Intel-gfx] [PATCH] drm/i915: Add TTM offset argument to mmap.

2021-07-14 Thread Jason Ekstrand
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

Re: [Intel-gfx] [PATCH v5 17/17] drm/amd/display: Add handling for new "Broadcast RGB" property

2021-07-14 Thread Werner Sembach
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

Re: [Intel-gfx] [PATCH v4 03/17] drm/uAPI: Add "active bpc" as feedback channel for "max bpc" drm property

2021-07-14 Thread Werner Sembach
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

Re: [Intel-gfx] [PATCH v4 12/17] drm/uAPI: Add "preferred color format" drm property as setting for userspace

2021-07-14 Thread Werner Sembach
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

[Intel-gfx] [PATCH v3 5/5] i915: map gvt pr_debug categories to bits in parameters/debug_gvt

2021-07-14 Thread Jim Cromie
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

[Intel-gfx] [PATCH v3 4/5] drm/print: move conditional deref into macro defn

2021-07-14 Thread Jim Cromie
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

[Intel-gfx] [PATCH v3 3/5] drm/print: RFC add choice to use dynamic debug in drm-debug

2021-07-14 Thread Jim Cromie
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

[Intel-gfx] [PATCH v3 2/5] drm_print.h: rewrap __DRM_DEFINE_DBG_RATELIMITED macro

2021-07-14 Thread Jim Cromie
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

[Intel-gfx] [PATCH v3 1/5] drm/print: fixup spelling in a comment

2021-07-14 Thread Jim Cromie
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 +++

[Intel-gfx] [PATCH v3 0/5] drm: use dyndbg in drm_print

2021-07-14 Thread Jim Cromie
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

Re: [Intel-gfx] [PATCH] drm/i915: Add TTM offset argument to mmap.

2021-07-14 Thread Maarten Lankhorst
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

Re: [Intel-gfx] [PATCH v4 3/4] drm/shmem-helpers: Allocate wc pages on x86

2021-07-14 Thread Christian König
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

Re: [Intel-gfx] [PATCH] drm/i915: Add TTM offset argument to mmap.

2021-07-14 Thread 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 the selftests as well. > > Document the struct as

Re: [Intel-gfx] [PATCH v4 3/4] drm/shmem-helpers: Allocate wc pages on x86

2021-07-14 Thread Daniel Vetter
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

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Fix wm params for ccs

2021-07-14 Thread Vudum, Lakshminarayana
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,

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Fix wm params for ccs

2021-07-14 Thread Patchwork
== 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 ---

Re: [Intel-gfx] [PATCH v4 3/4] drm/shmem-helpers: Allocate wc pages on x86

2021-07-14 Thread Christian König
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

[Intel-gfx] ✓ Fi.CI.IGT: success for Begin enabling Xe_HP SDV and DG2 platforms (rev5)

2021-07-14 Thread Patchwork
== 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

Re: [Intel-gfx] [PATCH] drm/i915/debugfs: DISPLAY_VER 13 lpsp capability

2021-07-14 Thread Gupta, Anshuman
> -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 >

[Intel-gfx] [PATCH v2 3/4] iommu/vt-d: Disable superpage for Skylake igfx

2021-07-14 Thread Ville Syrjala
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.

[Intel-gfx] [PATCH v2 4/4] drm/i915/fbc: Allow FBC + VT-d on SKL/BXT

2021-07-14 Thread Ville Syrjala
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

[Intel-gfx] [PATCH v2 2/4] iommu/vt-d: Disable superpage for Broxton igfx

2021-07-14 Thread Ville Syrjala
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.

[Intel-gfx] [PATCH v2 1/4] iommu/vt-d: Disable superpage for Geminilake igfx

2021-07-14 Thread Ville Syrjala
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

[Intel-gfx] [PATCH v2 0/4] iommu/vt-d: Disable igfx iommu superpage on bxt/skl/glk

2021-07-14 Thread Ville Syrjala
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

Re: [Intel-gfx] [PATCH] drm/i915/debugfs: DISPLAY_VER 13 lpsp capability

2021-07-14 Thread Manna, Animesh
> -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

Re: [Intel-gfx] [PATCH 1/5] drm/i915: document caching related bits

2021-07-14 Thread Daniel Vetter
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

Re: [Intel-gfx] [PATCH v4 3/4] drm/shmem-helpers: Allocate wc pages on x86

2021-07-14 Thread 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 to shmem helpers. > > > > After

[Intel-gfx] [PATCH] drm/vgem: use shmem helpers

2021-07-14 Thread Daniel Vetter
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

Re: [Intel-gfx] [PATCH] drm/i915: Fix wm params for ccs

2021-07-14 Thread Imre Deak
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

[Intel-gfx] [PATCH v2 resent] drm/i915: Add TTM offset argument to mmap.

2021-07-14 Thread Maarten Lankhorst
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:

Re: [Intel-gfx] [PATCH 1/5] drm/i915: document caching related bits

2021-07-14 Thread Ville Syrjälä
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

Re: [Intel-gfx] [PATCH 1/5] drm/i915: document caching related bits

2021-07-14 Thread Ville Syrjälä
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

Re: [Intel-gfx] [PATCH 5/5] drm/i915/ehl: unconditionally flush the pages on acquire

2021-07-14 Thread Daniel Vetter
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

Re: [Intel-gfx] [PATCH 1/5] drm/i915: document caching related bits

2021-07-14 Thread Daniel Vetter
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,

Re: [Intel-gfx] [PATCH v15 06/12] swiotlb: Use is_swiotlb_force_bounce for swiotlb data bouncing

2021-07-14 Thread Konrad Rzeszutek Wilk
..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,

[Intel-gfx] [PATCH] drm/i915: Add TTM offset argument to mmap.

2021-07-14 Thread Maarten Lankhorst
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:

Re: [Intel-gfx] [v2] drm/i915/display/dsc: Force dsc BPP

2021-07-14 Thread Sharma, Swati2
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]

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] tests/kms_addfb_basic: pass the actual fd to gem_has_lmem

2021-07-14 Thread Ramalingam C
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

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/ehl: Resolve insufficient header credits in MIPI DSI

2021-07-14 Thread Patchwork
== 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

Re: [Intel-gfx] [PATCH v4 09/18] drm/v3d: Use scheduler dependency handling

2021-07-14 Thread Melissa Wen
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

Re: [Intel-gfx] [PATCH v4 08/18] drm/v3d: Move drm_sched_job_init to v3d_job_init

2021-07-14 Thread Melissa Wen
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 >

[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915: Tweaked Wa_14010685332 for all PCHs (rev5)

2021-07-14 Thread Patchwork
== 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

[Intel-gfx] ✗ Fi.CI.IGT: failure for Minor revid/stepping and workaround cleanup (rev5)

2021-07-14 Thread Patchwork
== 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

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Fix wm params for ccs

2021-07-14 Thread Juha-Pekka Heikkilä
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:* >

Re: [Intel-gfx] [REBASED v2] drm/i915: Tweaked Wa_14010685332 for all PCHs

2021-07-14 Thread Gupta, Anshuman
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