Re: [Intel-gfx] [PATCH 11/11] video/aperture: Only remove sysfb on the default vga pci device

On 1/12/23 08:55, Thomas Zimmermann wrote: [...] >> Thanks Daniel and Javier! >> >> I wasn't able to reproduce the original problem on my hybrid laptop >> since it refuses to boot with the console on an external display, but I >> was able to reproduce it by switching the configuration around: b

Re: [Intel-gfx] [PATCH 03/27] drm/i915/gvt: Incorporate KVM memslot info into check for 2MiB GTT entry

> > > > Note, KVM may also restrict the mapping size for reasons that aren't > > > > relevant to KVMGT, e.g. for KVM's iTLB multi-hit workaround or if the > > > > gfn > > > Will iTLB multi-hit affect DMA? > > > > I highly doubt it, I can't imagine an IOMMU would have a dedicated > > instruction

Re: [Intel-gfx] [OA][RFC] Exposing low-resolution engine business via sysfs

Hi, On 12/01/2023 07:50, FlightlessMango wrote: Hi, I am the developer of MangoHud[1], a Vulkan and OpenGL overlay for monitoring FPS / temperatures / CPU/GPU load and more. I would like to add support for i915 (and xe in the future) but I am currently unable to do this easily because not

Re: [Intel-gfx] [PATCH 02/11] drm/gma500: Use drm_aperture_remove_conflicting_pci_framebuffers

Hi Am 11.01.23 um 16:41 schrieb Daniel Vetter: This one nukes all framebuffers, which is a bit much. In reality gma500 is igpu and never shipped with anything discrete, so there should not be any difference. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/gma500/psb_drv.c | 2 +- 1 file ch

Re: [Intel-gfx] [RFC PATCH 04/20] drm/sched: Convert drm scheduler to use a work queue rather than kthread

Hi Daniel, On Wed, 11 Jan 2023 22:47:02 +0100 Daniel Vetter wrote: > On Tue, 10 Jan 2023 at 09:46, Boris Brezillon > wrote: > > > > Hi Daniel, > > > > On Mon, 9 Jan 2023 21:40:21 +0100 > > Daniel Vetter wrote: > > > > > On Mon, Jan 09, 2023 at 06:17:48PM +0100, Boris Brezillon wrote: > > >

[Intel-gfx] [RFC 0/2] Add new CDCLK step for RPL-U

A new step of 480MHz has been added on SKUs that have an RPL-U device id. This particular step is to support 120Hz panels more efficiently. This patchset adds a new table to include this new CDCLK step. Details can be found in BSpec entry 55409. Create a new sub-platform to identify RPL-U which

[Intel-gfx] [RFC v2 1/2] drm/i915: Add sub platform for 480MHz CDCLK step

Add a new sub platform INTEL_SUBPLATFORM_480CDCLK to identify device ids that need the 480MHz CDCLK step. Separate out RPLU device ids and add them to both RPL and 480CDCLK subplatforms. v2: (Matt) - Sort PCI-IDs numerically - Name the sub-platform to accurately depict what it is for - Make

[Intel-gfx] [RFC 2/2] drm/i915/display: Add 480 MHz CDCLK steps for RPL-U

A new step of 480MHz has been added on SKUs that have a RPL-U device id to support 120Hz displays more efficiently. Use a new quirk to identify the machine for which this change needs to be applied. BSpec: 55409 v2: (Matt) - Add missing clock steps - Correct reference clock typo Signed-o

Re: [Intel-gfx] [RFC PATCH 04/20] drm/sched: Convert drm scheduler to use a work queue rather than kthread

On Thu, Jan 12, 2023 at 10:10:53AM +0100, Boris Brezillon wrote: > Hi Daniel, > > On Wed, 11 Jan 2023 22:47:02 +0100 > Daniel Vetter wrote: > > > On Tue, 10 Jan 2023 at 09:46, Boris Brezillon > > wrote: > > > > > > Hi Daniel, > > > > > > On Mon, 9 Jan 2023 21:40:21 +0100 > > > Daniel Vetter wr

[Intel-gfx] [PATCH] drm/i915/display: Fix typo for reference clock

Fix typo for reference clock from 24400 to 24000 Signed-off-by: Chaitanya Kumar Borah --- drivers/gpu/drm/i915/display/intel_cdclk.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c b/drivers/gpu/drm/i915/display/intel_cdclk.c index

Re: [Intel-gfx] [PATCH 01/11] drm/ast: Use drm_aperture_remove_conflicting_pci_framebuffers

Am 11.01.23 um 16:41 schrieb Daniel Vetter: It's just open coded and matches. Note that Thomas said that his version apparently failed for some reason, but hey maybe we should try again. It apparently worked this time. Tested on an AST2100 chip. Signed-off-by: Daniel Vetter Cc: Dave Airl

Re: [Intel-gfx] [RFC 1/2] drm/i915: Add rplu sub platform

Hello Matt, > -Original Message- > From: Roper, Matthew D > Sent: Tuesday, January 10, 2023 6:32 AM > To: Borah, Chaitanya Kumar > Cc: intel-gfx@lists.freedesktop.org; jani.nik...@linux.intel.com; Shankar, > Uma ; Syrjala, Ville ; > Srivatsa, Anusha ; Atwood, Matthew S > > Subject: Re:

Re: [Intel-gfx] [RFC 2/2] drm/i915/display: Add 480 MHz CDCLK steps for RPL-U

Hello Matt, > -Original Message- > From: Roper, Matthew D > Sent: Tuesday, January 10, 2023 6:38 AM > To: Borah, Chaitanya Kumar > Cc: intel-gfx@lists.freedesktop.org; jani.nik...@linux.intel.com; Shankar, > Uma ; Syrjala, Ville ; > Srivatsa, Anusha ; Atwood, Matthew S > > Subject: Re:

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Add new CDCLK step for RPL-U (rev4)

== Series Details == Series: Add new CDCLK step for RPL-U (rev4) URL : https://patchwork.freedesktop.org/series/111472/ State : warning == Summary == Error: dim checkpatch failed 5f2b67ffb5e8 drm/i915: Add sub platform for 480MHz CDCLK step -:90: ERROR:COMPLEX_MACRO: Macros with complex values

Re: [Intel-gfx] [RFC PATCH 00/20] Initial Xe driver submission

On Thu, Jan 05, 2023 at 09:27:57PM +, Matthew Brost wrote: On Tue, Jan 03, 2023 at 12:21:08PM +, Tvrtko Ursulin wrote: On 22/12/2022 22:21, Matthew Brost wrote: > Hello, > > This is a submission for Xe, a new driver for Intel GPUs that supports both > integrated and discrete platforms s

Re: [Intel-gfx] [PATCH 02/11] drm/gma500: Use drm_aperture_remove_conflicting_pci_framebuffers

On Thu, Jan 12, 2023 at 10:04:48AM +0100, Thomas Zimmermann wrote: > Hi > > Am 11.01.23 um 16:41 schrieb Daniel Vetter: > > This one nukes all framebuffers, which is a bit much. In reality > > gma500 is igpu and never shipped with anything discrete, so there should > > not be any difference. > >

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: implement async_flip mode per plane tracking (rev2)

On 11.01.2023 18:40, Patchwork wrote: *Patch Details* *Series:* drm/i915: implement async_flip mode per plane tracking (rev2) *URL:* https://patchwork.freedesktop.org/series/108371/ *State:*failure *Details:* https://intel-gfx-ci

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Allow error capture without a request

On 12/01/2023 02:53, john.c.harri...@intel.com wrote: From: John Harrison There was a report of error captures occurring without any hung context being indicated despite the capture being initiated by a 'hung context notification' from GuC. The problem was not reproducible. However, it is pos

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Allow error capture of a pending request

On 12/01/2023 02:53, john.c.harri...@intel.com wrote: From: John Harrison A hang situation has been observed where the only requests on the context were either completed or not yet started according to the breaadcrumbs. However, the register state claimed a batch was (maybe) in progress. So,

Re: [Intel-gfx] [PATCH v2] drm/i915: Fix CFI violations in gt_sysfs

Hi, This patch does also solve a kernel crash when reading /sys/class/drm/card1/gt/gt0/* on a skylake machine: https://bugzilla.redhat.com/show_bug.cgi?id=2154880 Do you think it can be backported to stable releases ? Conflicts are trivial on top of v6.0 at least. Thanks, -- Jocelyn On 13

Re: [Intel-gfx] [RFC PATCH 04/20] drm/sched: Convert drm scheduler to use a work queue rather than kthread

On Thu, 12 Jan 2023 10:32:18 +0100 Daniel Vetter wrote: > On Thu, Jan 12, 2023 at 10:10:53AM +0100, Boris Brezillon wrote: > > Hi Daniel, > > > > On Wed, 11 Jan 2023 22:47:02 +0100 > > Daniel Vetter wrote: > > > > > On Tue, 10 Jan 2023 at 09:46, Boris Brezillon > > > wrote: > > > > > > >

Re: [Intel-gfx] [PATCH 4/4] drm/i915/guc: Add a debug print on GuC triggered reset

On 12/01/2023 02:53, john.c.harri...@intel.com wrote: From: John Harrison For understanding bug reports, it can be useful to have an explicit dmesg print when a reset notification is received from GuC. As opposed to simply inferring that this happened from other messages. Signed-off-by: John

Re: [Intel-gfx] [PATCH 3/4] drm/i915/guc: Look for a guilty context when an engine reset fails

On 12/01/2023 02:53, john.c.harri...@intel.com wrote: From: John Harrison Engine resets are supposed to never fail. But in the case when one does (due to unknown reasons that normally come down to a missing w/a), it is useful to get as much information out of the system as possible. Given tha

Re: [Intel-gfx] [PATCH 02/11] drm/gma500: Use drm_aperture_remove_conflicting_pci_framebuffers

Hi Am 12.01.23 um 10:59 schrieb Daniel Vetter: On Thu, Jan 12, 2023 at 10:04:48AM +0100, Thomas Zimmermann wrote: Hi Am 11.01.23 um 16:41 schrieb Daniel Vetter: This one nukes all framebuffers, which is a bit much. In reality gma500 is igpu and never shipped with anything discrete, so there s

Re: [Intel-gfx] [RFC PATCH 04/20] drm/sched: Convert drm scheduler to use a work queue rather than kthread

On Thu, 12 Jan 2023 11:11:03 +0100 Boris Brezillon wrote: > On Thu, 12 Jan 2023 10:32:18 +0100 > Daniel Vetter wrote: > > > On Thu, Jan 12, 2023 at 10:10:53AM +0100, Boris Brezillon wrote: > > > Hi Daniel, > > > > > > On Wed, 11 Jan 2023 22:47:02 +0100 > > > Daniel Vetter wrote: > > >

Re: [Intel-gfx] [RFC PATCH 04/20] drm/sched: Convert drm scheduler to use a work queue rather than kthread

On Thu, 12 Jan 2023 11:11:03 +0100 Boris Brezillon wrote: > On Thu, 12 Jan 2023 10:32:18 +0100 > Daniel Vetter wrote: > > > On Thu, Jan 12, 2023 at 10:10:53AM +0100, Boris Brezillon wrote: > > > Hi Daniel, > > > > > > On Wed, 11 Jan 2023 22:47:02 +0100 > > > Daniel Vetter wrote: > > >

Re: [Intel-gfx] [RFC PATCH 04/20] drm/sched: Convert drm scheduler to use a work queue rather than kthread

On Thu, Jan 12, 2023 at 11:25:53AM +0100, Boris Brezillon wrote: > On Thu, 12 Jan 2023 11:11:03 +0100 > Boris Brezillon wrote: > > > On Thu, 12 Jan 2023 10:32:18 +0100 > > Daniel Vetter wrote: > > > > > On Thu, Jan 12, 2023 at 10:10:53AM +0100, Boris Brezillon wrote: > > > > Hi Daniel, > > >

Re: [Intel-gfx] [PATCH 02/11] drm/gma500: Use drm_aperture_remove_conflicting_pci_framebuffers

On Thu, Jan 12, 2023 at 11:24:13AM +0100, Thomas Zimmermann wrote: > Hi > > Am 12.01.23 um 10:59 schrieb Daniel Vetter: > > On Thu, Jan 12, 2023 at 10:04:48AM +0100, Thomas Zimmermann wrote: > > > Hi > > > > > > Am 11.01.23 um 16:41 schrieb Daniel Vetter: > > > > This one nukes all framebuffers,

Re: [Intel-gfx] [RFC v2 1/2] drm/i915: Add sub platform for 480MHz CDCLK step

On Thu, 12 Jan 2023, Chaitanya Kumar Borah wrote: > Add a new sub platform INTEL_SUBPLATFORM_480CDCLK to identify > device ids that need the 480MHz CDCLK step. Separate out RPLU > device ids and add them to both RPL and 480CDCLK subplatforms. > > v2: (Matt) > - Sort PCI-IDs numerically > - Na

Re: [Intel-gfx] [RFC v2 1/2] drm/i915: Add sub platform for 480MHz CDCLK step

On Thu, 12 Jan 2023, Jani Nikula wrote: > On Thu, 12 Jan 2023, Chaitanya Kumar Borah > wrote: >> Add a new sub platform INTEL_SUBPLATFORM_480CDCLK to identify >> device ids that need the 480MHz CDCLK step. Separate out RPLU >> device ids and add them to both RPL and 480CDCLK subplatforms. >> >>

[Intel-gfx] [PATCH v2] drm: Optimize drm buddy top-down allocation method

We are observing performance drop in many usecases which include games, 3D benchmark applications,etc.. To solve this problem, We are strictly not allowing top down flag enabled allocations to steal the memory space from cpu visible region. The idea is, we are sorting each order list entries in as

[Intel-gfx] [PULL] drm-intel-next

Hi Dave & Daniel - Here's the first i915 feature pull towards v6.3. drm-intel-next-2023-01-12: drm/i915 feature pull #1 for v6.3: Features and functionality: - Meteorlake display enabling (Animesh, Luca, Stan, Jouni, Anusha) - DP MST DSC support (Stan) - Gamma/degamma readout support for the s

Re: [Intel-gfx] [RFC PATCH 04/20] drm/sched: Convert drm scheduler to use a work queue rather than kthread

On Thu, 12 Jan 2023 11:42:57 +0100 Daniel Vetter wrote: > On Thu, Jan 12, 2023 at 11:25:53AM +0100, Boris Brezillon wrote: > > On Thu, 12 Jan 2023 11:11:03 +0100 > > Boris Brezillon wrote: > > > > > On Thu, 12 Jan 2023 10:32:18 +0100 > > > Daniel Vetter wrote: > > > > > > > On Thu, Jan 12

Re: [Intel-gfx] [PATCH 02/11] drm/gma500: Use drm_aperture_remove_conflicting_pci_framebuffers

Hi Am 12.01.23 um 11:45 schrieb Daniel Vetter: On Thu, Jan 12, 2023 at 11:24:13AM +0100, Thomas Zimmermann wrote: Hi Am 12.01.23 um 10:59 schrieb Daniel Vetter: On Thu, Jan 12, 2023 at 10:04:48AM +0100, Thomas Zimmermann wrote: Hi Am 11.01.23 um 16:41 schrieb Daniel Vetter: This one nukes

Re: [Intel-gfx] [PATCH 2/5] drm/amdgpu: Remove redundant framebuffer format check

Reviewed-by: Simon Ser

Re: [Intel-gfx] [PATCH 3/5] drm/i915: Remove redundant framebuffer format check

The Intel counterpart is also: Reviewed-by: Simon Ser

Re: [Intel-gfx] [PATCH 3/5] drm/i915: Remove redundant framebuffer format check

On Mon, Jan 09, 2023 at 07:58:06AM -0300, Maíra Canal wrote: > Now that framebuffer_check() verifies that the format is properly > supported, there is no need to check it again on i915's inside > helpers. > > Therefore, remove the redundant framebuffer format check from the > intel_framebuffer_ini

Re: [Intel-gfx] [PATCH 1/2] KVM: async kvm_destroy_vm for vfio devices

On Wed, Jan 11, 2023 at 08:53:34PM +, Sean Christopherson wrote: > On Wed, Jan 11, 2023, Jason Gunthorpe wrote: > > On Wed, Jan 11, 2023 at 07:54:51PM +, Sean Christopherson wrote: > > > > > Something feels off. If KVM's refcount is 0, then accessing > > > device->group->kvm > > > in vfi

[Intel-gfx] [PULL] drm-misc-next

Hi Dave and Daniel, here's the drm-misc-next PR for this week. Best regards Thomas drm-misc-next-2023-01-12: drm-misc-next for v6.3: UAPI Changes: * fourcc: Document Open Source user waiver Cross-subsystem Changes: * firmware: fix color-format selection for system framebuffers Core Change

[Intel-gfx] [PULL] drm-misc-fixes

Hi Dave, Daniel, Here's this week drm-misc-fixes PR Maxime drm-misc-fixes-2023-01-12: Several fixes for amdgpu (all addressing issues with fences), yet another orientation quirk for a Lenovo device, a use-after-free fix for virtio, a regression fix in TTM and a performance regression in drm budd

Re: [Intel-gfx] [PATCH 3/5] drm/i915: Remove redundant framebuffer format check

Hi, On 1/12/23 09:43, Ville Syrjälä wrote: On Mon, Jan 09, 2023 at 07:58:06AM -0300, Maíra Canal wrote: Now that framebuffer_check() verifies that the format is properly supported, there is no need to check it again on i915's inside helpers. Therefore, remove the redundant framebuffer format c

[Intel-gfx] ✓ Fi.CI.BAT: success for Add new CDCLK step for RPL-U (rev4)

== Series Details == Series: Add new CDCLK step for RPL-U (rev4) URL : https://patchwork.freedesktop.org/series/111472/ State : success == Summary == CI Bug Log - changes from CI_DRM_12575 -> Patchwork_111472v4 Summary --- **SUCCESS*

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: Fix typo for reference clock

== Series Details == Series: drm/i915/display: Fix typo for reference clock URL : https://patchwork.freedesktop.org/series/112729/ State : success == Summary == CI Bug Log - changes from CI_DRM_12575 -> Patchwork_112729v1 Summary ---

[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Optimize drm buddy top-down allocation method

== Series Details == Series: drm: Optimize drm buddy top-down allocation method URL : https://patchwork.freedesktop.org/series/112733/ State : success == Summary == CI Bug Log - changes from CI_DRM_12576 -> Patchwork_112733v1 Summary --

[Intel-gfx] [PULL] drm-intel-fixes

Hi Dave and Daniel, Here goes this week fix. There was only a small conflict in the multi-cast registers fix, but that's pretty trivial. Just go with the -gt-next version if needed on your side. drm-intel-fixes-2023-01-12: - Reserve enough fence slot for i915_vma_unbind_vsync (Nirmoy) - Fix pot

Re: [Intel-gfx] [PATCH 3/5] drm/i915: Remove redundant framebuffer format check

On Thu, Jan 12, 2023 at 11:07:59AM -0300, Maíra Canal wrote: > Hi, > > On 1/12/23 09:43, Ville Syrjälä wrote: > > On Mon, Jan 09, 2023 at 07:58:06AM -0300, Maíra Canal wrote: > >> Now that framebuffer_check() verifies that the format is properly > >> supported, there is no need to check it again o

[Intel-gfx] [PATCH] drm/i915: Reject < 1x1 pixel plane source size

From: Ville Syrjälä We don't have proper sub-pixel coordinate support (some platforms simply can't do it, for others we've not implemented it). This can cause us to treat a < 1 pixel source width/height as zero which is not valid for the hardware, and can also cause a div by zero in some cases.

Re: [Intel-gfx] [PATCH 02/11] drm/gma500: Use drm_aperture_remove_conflicting_pci_framebuffers

On Thu, 12 Jan 2023 at 13:15, Thomas Zimmermann wrote: > > Hi > > Am 12.01.23 um 11:45 schrieb Daniel Vetter: > > On Thu, Jan 12, 2023 at 11:24:13AM +0100, Thomas Zimmermann wrote: > >> Hi > >> > >> Am 12.01.23 um 10:59 schrieb Daniel Vetter: > >>> On Thu, Jan 12, 2023 at 10:04:48AM +0100, Thomas

Re: [Intel-gfx] [RFC PATCH 04/20] drm/sched: Convert drm scheduler to use a work queue rather than kthread

On Thu, 12 Jan 2023 at 13:08, Boris Brezillon wrote: > On Thu, 12 Jan 2023 11:42:57 +0100 > Daniel Vetter wrote: > > > On Thu, Jan 12, 2023 at 11:25:53AM +0100, Boris Brezillon wrote: > > > On Thu, 12 Jan 2023 11:11:03 +0100 > > > Boris Brezillon wrote: > > > > > > > On Thu, 12 Jan 2023 10:32:18

Re: [Intel-gfx] [PATCH v2] drm/i915: Fix CFI violations in gt_sysfs

Hi Jocelyn, On Thu, Jan 12, 2023 at 11:08:17AM +0100, Jocelyn Falempe wrote: > This patch does also solve a kernel crash when reading > /sys/class/drm/card1/gt/gt0/* on a skylake machine: > https://bugzilla.redhat.com/show_bug.cgi?id=2154880 Interesting, I wonder what aspect of this patch fixes t

Re: [Intel-gfx] [PATCH 2/2] drm/ttm: replace busy placement with flags

Am 11.01.23 um 16:18 schrieb Matthew Auld: [SNIP] Currently "dim rebuild-tip" doesn't work for me because of a conflict in i915_gem_execbuffer.c Seems to be working now. Nope. When I do a fresh install with "drm setup" in a different working directly I run into exactly this problem again.

Re: [Intel-gfx] [RFC PATCH 04/20] drm/sched: Convert drm scheduler to use a work queue rather than kthread

On Thu, 12 Jan 2023 16:38:18 +0100 Daniel Vetter wrote: > > > > > > Also if you do the allocation in ->prepare_job with dma_fence and not > > > run_job, then I think can sort out fairness issues (if they do pop up) in > > > the drm/sched code instead of having to think about this in each driver.

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Reject < 1x1 pixel plane source size

== Series Details == Series: drm/i915: Reject < 1x1 pixel plane source size URL : https://patchwork.freedesktop.org/series/112743/ State : success == Summary == CI Bug Log - changes from CI_DRM_12577 -> Patchwork_112743v1 Summary ---

[Intel-gfx] [RFC v3 00/12] DRM scheduling cgroup controller

From: Tvrtko Ursulin This series contains a proposal for a DRM scheduling cgroup controller which implements a weight based hierarchical GPU usage budget based controller similar in concept to some of the existing controllers. Motivation mostly comes from my earlier proposal where I identified t

[Intel-gfx] [RFC 01/12] drm: Track clients by tgid and not tid

From: Tvrtko Ursulin Thread group id (aka pid from userspace point of view) is a more interesting thing to show as an owner of a DRM fd, so track and show that instead of the thread id. In the next patch we will make the owner updated post file descriptor handover, which will also be tgid based

[Intel-gfx] [RFC 02/12] drm: Update file owner during use

From: Tvrtko Ursulin With the typical model where the display server opends the file descriptor and then hands it over to the client we were showing stale data in debugfs. Fix it by updating the drm_file->pid on ioctl access from a different process. The field is also made RCU protected to allo

[Intel-gfx] [RFC 03/12] cgroup: Add the DRM cgroup controller

From: Tvrtko Ursulin Skeleton controller without any functionality. Signed-off-by: Tvrtko Ursulin --- include/linux/cgroup_drm.h| 9 ++ include/linux/cgroup_subsys.h | 4 +++ init/Kconfig | 7 + kernel/cgroup/Makefile| 1 + kernel/cgroup/drm.c

[Intel-gfx] [RFC 04/12] drm/cgroup: Track clients per owning process

From: Tvrtko Ursulin To enable propagation of settings from the cgroup drm controller to drm we need to start tracking which processes own which drm clients. Implement that by tracking the struct pid pointer of the owning process in a new XArray, pointing to a structure containing a list of asso

[Intel-gfx] [RFC 05/12] drm/cgroup: Allow safe external access to file_priv

From: Tvrtko Ursulin Entry points from the cgroup subsystem into the drm cgroup controller will need to walk the file_priv structures associated with registered clients and since those are not RCU protected lets add a hack for now to make this safe. Signed-off-by: Tvrtko Ursulin --- drivers/gp

[Intel-gfx] [RFC 06/12] drm/cgroup: Add ability to query drm cgroup GPU time

From: Tvrtko Ursulin Add a driver callback and core helper which allow querying the time spent on GPUs for processes belonging to a group. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/drm_cgroup.c | 24 include/drm/drm_clients.h| 2 ++ include/drm/drm_drv.h

[Intel-gfx] [RFC 07/12] drm/cgroup: Add over budget signalling callback

From: Tvrtko Ursulin Add a new callback via which the drm cgroup controller is notifying the drm core that a certain process is above its allotted GPU time. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/drm_cgroup.c | 21 + include/drm/drm_clients.h| 1 + include/d

[Intel-gfx] [RFC 08/12] drm/cgroup: Only track clients which are providing drm_cgroup_ops

From: Tvrtko Ursulin To reduce the number of tracking going on, especially with drivers which will not support any sort of control from the drm cgroup controller side, lets express the funcionality as opt-in and use the presence of drm_cgroup_ops as activation criteria. Signed-off-by: Tvrtko Urs

[Intel-gfx] [RFC 09/12] cgroup/drm: Client exit hook

From: Tvrtko Ursulin We need the ability for DRM core to inform the cgroup controller when a client has closed a DRM file descriptor. This will allow us not needing to keep state relating to GPU time usage by tasks sets in the cgroup controller itself. Signed-off-by: Tvrtko Ursulin --- drivers

[Intel-gfx] [RFC 11/12] drm/i915: Wire up with drm controller GPU time query

From: Tvrtko Ursulin Implement the drm_cgroup_ops->active_time_us callback. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_driver.c | 10 drivers/gpu/drm/i915/i915_drm_client.c | 76 ++ drivers/gpu/drm/i915/i915_drm_client.h | 2 + 3 files changed

[Intel-gfx] [RFC 10/12] cgroup/drm: Introduce weight based drm cgroup control

From: Tvrtko Ursulin Similar to CPU scheduling, implement a concept of weight in the drm cgroup controller. Uses the same range and default as the CPU controller - CGROUP_WEIGHT_MIN, CGROUP_WEIGHT_DFL and CGROUP_WEIGHT_MAX. Later each cgroup is assigned a time budget proportionaly based on the

[Intel-gfx] [RFC 12/12] drm/i915: Implement cgroup controller over budget throttling

From: Tvrtko Ursulin When notified by the drm core we are over our allotted time budget, i915 instance will check if any of the GPU engines it is reponsible for is fully saturated. If it is, and the client in question is using that engine, it will throttle it. For now throttling is done simplist

Re: [Intel-gfx] [RFC PATCH 00/20] Initial Xe driver submission

On Thu, Jan 12, 2023 at 10:54:25AM +0100, Lucas De Marchi wrote: > On Thu, Jan 05, 2023 at 09:27:57PM +, Matthew Brost wrote: > > On Tue, Jan 03, 2023 at 12:21:08PM +, Tvrtko Ursulin wrote: > > > > > > On 22/12/2022 22:21, Matthew Brost wrote: > > > > Hello, > > > > > > > > This is a submi

Re: [Intel-gfx] [PATCH 1/2] KVM: async kvm_destroy_vm for vfio devices

On 1/12/23 7:45 AM, Jason Gunthorpe wrote: > On Wed, Jan 11, 2023 at 08:53:34PM +, Sean Christopherson wrote: >> On Wed, Jan 11, 2023, Jason Gunthorpe wrote: >>> On Wed, Jan 11, 2023 at 07:54:51PM +, Sean Christopherson wrote: >>> Something feels off. If KVM's refcount is 0, then acce

Re: [Intel-gfx] [PATCH 1/2] KVM: async kvm_destroy_vm for vfio devices

On Thu, Jan 12, 2023 at 12:21:17PM -0500, Matthew Rosato wrote: > So should I work up a v2 that does symbol gets for kvm_get_kvm_safe > and kvm_put_kvm from vfio_main and drop kvm_put_kvm_async? Or is > the patch Yi is working on changing things such that will also > address the deadlock issue?

Re: [Intel-gfx] [PATCH v4 6/6] drm/i915/pxp: Pxp hw init should be in resume_complete

On 1/11/2023 4:37 PM, Alan Previn wrote: During suspend flow, i915 currently achors' on the pm_suspend_prepare callback as the location where we quiesce the entire GPU and perform all necessary cleanup in order to go into suspend. PXP is also called during this time to perform the arbitration

Re: [Intel-gfx] [RFC v2 1/2] drm/i915: Add sub platform for 480MHz CDCLK step

On Thu, Jan 12, 2023 at 01:03:44PM +0200, Jani Nikula wrote: > On Thu, 12 Jan 2023, Chaitanya Kumar Borah > wrote: > > Add a new sub platform INTEL_SUBPLATFORM_480CDCLK to identify > > device ids that need the 480MHz CDCLK step. Separate out RPLU > > device ids and add them to both RPL and 480CDC

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for DRM scheduling cgroup controller (rev3)

== Series Details == Series: DRM scheduling cgroup controller (rev3) URL : https://patchwork.freedesktop.org/series/109902/ State : warning == Summary == Error: dim checkpatch failed d566e8fb02ed drm: Track clients by tgid and not tid 365d4dcce2b7 drm: Update file owner during use 617bddab81a7

Re: [Intel-gfx] [PATCH] drm/i915/display: Fix typo for reference clock

On Thu, Jan 12, 2023 at 03:11:31PM +0530, Chaitanya Kumar Borah wrote: > Fix typo for reference clock from 24400 to 24000 > > Signed-off-by: Chaitanya Kumar Borah Fixes: 626426ff9ce4 ("drm/i915/adl_p: Add cdclk support for ADL-P") Reviewed-by: Matt Roper > --- > drivers/gpu/drm/i915/display/i

Re: [Intel-gfx] [PATCH] drm/i915/display: Fix typo for reference clock

On Thu, Jan 12, 2023 at 09:40:42AM -0800, Matt Roper wrote: > On Thu, Jan 12, 2023 at 03:11:31PM +0530, Chaitanya Kumar Borah wrote: > > Fix typo for reference clock from 24400 to 24000 > > > > Signed-off-by: Chaitanya Kumar Borah > > Fixes: 626426ff9ce4 ("drm/i915/adl_p: Add cdclk support for A

[Intel-gfx] [PATCH i-g-t 0/4] Some intel_gpu_top tweaks

From: Tvrtko Ursulin Mostly by popular demand from https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/issues/109, although for some of these changes I'd like some second opinions. For instance is it user friendly to change the default aggregation mode for stdout and JSON output? Tvrtko Ursulin (

[Intel-gfx] [PATCH i-g-t 2/4] intel_gpu_top: Automatically enclose JSON output into brackets

From: Tvrtko Ursulin Parsers need the whole output enclosed into square brackets so every period sample becomes an array element. So far we have been suggesting this in the man page but we can trivially make the tool output that itself. Signed-off-by: Tvrtko Ursulin Cc: Eero Tamminen --- man

[Intel-gfx] [PATCH i-g-t 1/4] intel_gpu_top: Fix man page formatting

From: Tvrtko Ursulin New lines are not respected when rst2man generates the page so try to work around that by followin advice from the Internet. Signed-off-by: Tvrtko Ursulin --- man/intel_gpu_top.rst | 15 --- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/man/inte

[Intel-gfx] [PATCH i-g-t 3/4] intel_gpu_top: Add command line switch to start in physical engine mode

From: Tvrtko Ursulin Default mode is to aggreate engines per class but some users would prefer to be able to start in physical engine mode too. Signed-off-by: Tvrtko Ursulin Cc: Dmitry Rogozhkin --- man/intel_gpu_top.rst | 3 +++ tools/intel_gpu_top.c | 9 +++-- 2 files changed, 10 insert

[Intel-gfx] [PATCH i-g-t 4/4] intel_gpu_top: Aggregate engine classes in all output modes

From: Tvrtko Ursulin Use the same default for stdout and JSON output modes as it is for interactive. Previously added command line switch can be used to go back to showing all physical engines. Signed-off-by: Tvrtko Ursulin Cc: Dmitry Rogozhkin --- tools/intel_gpu_top.c | 3 ++- 1 file chang

[Intel-gfx] ✓ Fi.CI.BAT: success for DRM scheduling cgroup controller (rev3)

== Series Details == Series: DRM scheduling cgroup controller (rev3) URL : https://patchwork.freedesktop.org/series/109902/ State : success == Summary == CI Bug Log - changes from CI_DRM_12577 -> Patchwork_109902v3 Summary --- **SUCC

Re: [Intel-gfx] [RFC PATCH 04/20] drm/sched: Convert drm scheduler to use a work queue rather than kthread

On 11/01/2023 17:52, Matthew Brost wrote: On Wed, Jan 11, 2023 at 09:09:45AM +, Tvrtko Ursulin wrote: [snip] Anyway, since you are not buying any arguments on paper perhaps you are more open towards testing. If you would adapt gem_wsim for Xe you would be able to spawn N simulated tran

Re: [Intel-gfx] [PATCH] drm/i915/display: Check source height is > 0

On Mon, Dec 26, 2022 at 10:53:24PM -0700, Drew Davenport wrote: > The error message suggests that the height of the src rect must be at > least 1. Reject source with height of 0. > > Signed-off-by: Drew Davenport > > --- > I was investigating some divide-by-zero crash reports on ChromeOS which >

Re: [Intel-gfx] [PATCH] drm/i915: Reject < 1x1 pixel plane source size

On Thu, Jan 12, 2023 at 05:21:45PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > We don't have proper sub-pixel coordinate support (some platforms > simply can't do it, for others we've not implemented it). This > can cause us to treat a < 1 pixel source width/height as zero > which is no

Re: [Intel-gfx] [RFC PATCH 04/20] drm/sched: Convert drm scheduler to use a work queue rather than kthread

On 11/01/2023 19:40, Matthew Brost wrote: On Wed, Jan 11, 2023 at 08:50:37AM +, Tvrtko Ursulin wrote: [snip] This example is where it would hurt on large systems. Imagine only an even wider media transcode card... Second example is only a single engine class used (3d desktop?) but wit

[Intel-gfx] ✓ Fi.CI.IGT: success for Add new CDCLK step for RPL-U (rev4)

== Series Details == Series: Add new CDCLK step for RPL-U (rev4) URL : https://patchwork.freedesktop.org/series/111472/ State : success == Summary == CI Bug Log - changes from CI_DRM_12575_full -> Patchwork_111472v4_full Summary ---

[Intel-gfx] [CI] PR for ADLP DMC 2.18 and MTL DMC 2.11

The following changes since commit a1ad1d5b50626f2d126adf1964ce0e98cbb8b39d: amdgpu: add VCN4.0.4 firmware from amd-5.4 (2023-01-10 10:08:40 -0500) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-firmware dmc-adlp_2.18-mtl_2.11 for you to fetch changes up to f0

[Intel-gfx] ✗ Fi.CI.BUILD: failure for kvm/vfio: fix potential deadlock on vfio group lock (rev4)

== Series Details == Series: kvm/vfio: fix potential deadlock on vfio group lock (rev4) URL : https://patchwork.freedesktop.org/series/112568/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/112568/revisions/4/mbox/ not applied Applying: KVM: async

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/display: Fix typo for reference clock

== Series Details == Series: drm/i915/display: Fix typo for reference clock URL : https://patchwork.freedesktop.org/series/112729/ State : success == Summary == CI Bug Log - changes from CI_DRM_12575_full -> Patchwork_112729v1_full Summary

[Intel-gfx] [PATCH v2 0/3] drm: Generic fbdev and vga-switcheroo

(was: drm/fb-helper: Set framebuffer for vga-switcheroo clients) This patch has now turned into a little series. The first two patches are bug fixes for the existing code. The third patch cleans up the drivers. Patch 1 fixes i915 to do the correct thing if the device has not been initialized yet.

[Intel-gfx] [PATCH v2 3/3] drm: Call vga_switcheroo_process_delayed_switch() in drm_lastclose

Several lastclose helpers call vga_switcheroo_process_delayed_switch(). It's better to call the helper from drm_lastclose() after the kernel client's screen has been restored. This way, all drivers can benefit without having to implement their own lastclose helper. For drivers without vga-switchero

[Intel-gfx] [PATCH v2 1/3] drm/i915: Allow switching away via vga-switcheroo if uninitialized

Always allow switching away via vga-switcheroo if the display is uninitalized. Instead prevent switching to i915 if the device has not been initialized. This issue was introduced by commit 5df7bd130818 ("drm/i915: skip display initialization when there is no display") protected, which protects cod

[Intel-gfx] [PATCH v2 2/3] drm/fb-helper: Set framebuffer for vga-switcheroo clients

Set the framebuffer info for drivers that support VGA switcheroo. Only affects the amdgpu and nouveau drivers, which use VGA switcheroo and generic fbdev emulation. For other drivers, this does nothing. This fixes a potential regression in the console code. Both, amdgpu and nouveau, invoked vga_sw

[Intel-gfx] [PATCH v2] vfio: fix potential deadlock on vfio group lock

Currently it is possible that the final put of a KVM reference comes from vfio during its device close operation. This occurs while the vfio group lock is held; however, if the vfio device is still in the kvm device list, then the following call chain could result in a deadlock: kvm_put_kvm -> k

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Allow error capture without a request

On 1/12/2023 02:01, Tvrtko Ursulin wrote: On 12/01/2023 02:53, john.c.harri...@intel.com wrote: From: John Harrison There was a report of error captures occurring without any hung context being indicated despite the capture being initiated by a 'hung context notification' from GuC. The problem

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Allow error capture of a pending request

On 1/12/2023 02:06, Tvrtko Ursulin wrote: On 12/01/2023 02:53, john.c.harri...@intel.com wrote: From: John Harrison A hang situation has been observed where the only requests on the context were either completed or not yet started according to the breaadcrumbs. However, the register state clai

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm: Generic fbdev and vga-switcheroo

== Series Details == Series: drm: Generic fbdev and vga-switcheroo URL : https://patchwork.freedesktop.org/series/112754/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.

Re: [Intel-gfx] [PATCH 3/4] drm/i915/guc: Look for a guilty context when an engine reset fails

On 1/12/2023 02:15, Tvrtko Ursulin wrote: On 12/01/2023 02:53, john.c.harri...@intel.com wrote: From: John Harrison Engine resets are supposed to never fail. But in the case when one does (due to unknown reasons that normally come down to a missing w/a), it is useful to get as much information

Re: [Intel-gfx] [PATCH v2] vfio: fix potential deadlock on vfio group lock

On Thu, 12 Jan 2023 15:38:44 -0500 Matthew Rosato wrote: > Currently it is possible that the final put of a KVM reference comes from > vfio during its device close operation. This occurs while the vfio group > lock is held; however, if the vfio device is still in the kvm device list, > then the

[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Generic fbdev and vga-switcheroo

== Series Details == Series: drm: Generic fbdev and vga-switcheroo URL : https://patchwork.freedesktop.org/series/112754/ State : success == Summary == CI Bug Log - changes from CI_DRM_12578 -> Patchwork_112754v1 Summary --- **SUCCES

Re: [Intel-gfx] [PATCH 1/4] drm/i915/gt: Remove platform comments from workarounds

On Thu, Jan 05, 2023 at 01:35:52PM +, Tvrtko Ursulin wrote: Okay to sum it up below with some final notes.. On 04/01/2023 19:34, Matt Roper wrote: On Wed, Jan 04, 2023 at 09:58:13AM +, Tvrtko Ursulin wrote: On 23/12/2022 18:28, Lucas De Marchi wrote: On Fri, Dec 23, 2022 at 09:02:35

  1   2   >