Re: [Intel-gfx] [PATCH v2 07/11] vfio-iommufd: Support iommufd for physical VFIO devices

On 2022/11/8 14:10, Nicolin Chen wrote: On Mon, Nov 07, 2022 at 08:52:51PM -0400, Jason Gunthorpe wrote: @@ -795,6 +800,10 @@ static int vfio_device_first_open(struct vfio_device *device) ret = vfio_group_use_container(device->group); if (ret)

Re: [Intel-gfx] [PATCH 2/2] drm/i915/ttm: add some sanity checks for lmem_userfault_list

On 07.11.2022 17:54, Matthew Auld wrote: Rather than getting some hard to debug uaf, add some warns to hopefully catch issues with userfault_count being non-zero when destroying the object. Also if we somehow add an object to lmem_userfault_list that somehow doesn't map lmem. References: http

Re: [Intel-gfx] [PATCH 1/2] drm/i915/ttm: fix uaf with lmem_userfault_list handling

On 07.11.2022 17:54, Matthew Auld wrote: In the fault handler, make sure we check if the BO maps lmem after we schedule the migration, since the current resource might change from lmem to smem, if the pages are in the non-cpu visible portion of lmem. This then leads to adding the object to the

Re: [Intel-gfx] [PATCH 2/2] drm/i915/gvt: Remove the unused function get_pt_type()

On 2022.09.26 14:40:43 +0800, Jiapeng Chong wrote: > The function get_pt_type is defined in the gtt.c file, but not > called elsewhere, so delete this unused function. > > drivers/gpu/drm/i915/gvt/gtt.c:285:19: warning: unused function 'get_pt_type'. > > Link: https://bugzilla.openanolis.cn/show_

Re: [Intel-gfx] [PATCH] drm/i915: fix repeated words in comments

On 2022.10.22 14:13:27 +0800, wangjianli wrote: > Delete the redundant word 'the'. > > Signed-off-by: wangjianli > --- > drivers/gpu/drm/i915/gvt/gtt.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c > inde

[Intel-gfx] ✓ Fi.CI.IGT: success for drm: Use XArray instead of IDR for minors

== Series Details == Series: drm: Use XArray instead of IDR for minors URL : https://patchwork.freedesktop.org/series/110621/ State : success == Summary == CI Bug Log - changes from CI_DRM_12353_full -> Patchwork_110621v1_full Summary -

Re: [Intel-gfx] [PATCH] [next] i915/gvt: remove hardcoded value on crc32_start calculation

On 2022.10.30 16:36:28 +1300, Paulo Miguel Almeida wrote: > struct gvt_firmware_header has a crc32 member in which all members that > come after the that field are used to calculate it. The previous > implementation added the value '4' (crc32's u32 size) to calculate the > crc32_start offset which

Re: [Intel-gfx] [PATCH v2 07/11] vfio-iommufd: Support iommufd for physical VFIO devices

On Mon, Nov 07, 2022 at 08:52:51PM -0400, Jason Gunthorpe wrote: > @@ -795,6 +800,10 @@ static int vfio_device_first_open(struct vfio_device > *device) > ret = vfio_group_use_container(device->group); > if (ret) > goto err_module_put; > + } el

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/pxp: Separate PXP FW interface structures for

== Series Details == Series: drm/i915/pxp: Separate PXP FW interface structures for URL : https://patchwork.freedesktop.org/series/110652/ State : success == Summary == CI Bug Log - changes from CI_DRM_12353 -> Patchwork_110652v1 Summary --

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/pxp: Separate PXP FW interface structures for

== Series Details == Series: drm/i915/pxp: Separate PXP FW interface structures for URL : https://patchwork.freedesktop.org/series/110652/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +drivers/gpu/drm/i91

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/pxp: Separate PXP FW interface structures for

== Series Details == Series: drm/i915/pxp: Separate PXP FW interface structures for URL : https://patchwork.freedesktop.org/series/110652/ State : warning == Summary == Error: dim checkpatch failed 38692444dbfa drm/i915/pxp: Separate PXP FW interface structures for both v42 and 43 Traceback (

[Intel-gfx] ✗ Fi.CI.IGT: failure for Documentation/gpu: reduce verbosity in toc

== Series Details == Series: Documentation/gpu: reduce verbosity in toc URL : https://patchwork.freedesktop.org/series/110618/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12353_full -> Patchwork_110618v1_full Summary

[Intel-gfx] [PATCH v3 1/1] drm/i915/pxp: Separate PXP FW interface structures for both v42 and 43

Previously, we only used PXP FW interface version-42 structures for PXP arbitration session on ADL/TGL products and version-43 for HuC authentication on DG2. That worked fine despite not differentiating such versioning of the PXP firmware interaction structures. This was okay back then because the

[Intel-gfx] [PATCH v3 0/1] drm/i915/pxp: Separate PXP FW interface structures for

In preparation for MTL, we need to separate the PXP FW structure definitions for version 42 vs 43 for any commands we use. Details are included in patch 1. Changes from prior rev: v2: Fixed all the comments from Daniele and Jani. v1: Fixed build issue. Alan Previn (1): drm/i915/pxp: Sepa

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/tgl+: Enable DC power states on all eDP ports (rev2)

== Series Details == Series: drm/i915/tgl+: Enable DC power states on all eDP ports (rev2) URL : https://patchwork.freedesktop.org/series/110433/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12353_full -> Patchwork_110433v2_full ===

Re: [Intel-gfx] [PATCH 1/1] drm/i915/pxp: Separate PXP FW interface structures for both v42 and 43

Agreed on all comments - will fix them all. Thanks Daniele, Nikula. ...alan On Wed, 2022-11-02 at 11:35 +0200, Jani Nikula wrote: > On Tue, 01 Nov 2022, "Ceraolo Spurio, Daniele" > wrote: > > On 10/24/2022 11:40 AM, Alan Previn wrote: > > > Previously, we only used PXP FW interface version-42 st

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [CI,1/7] drm/i915/huc: only load HuC on GTs that have VCS engines

== Series Details == Series: series starting with [CI,1/7] drm/i915/huc: only load HuC on GTs that have VCS engines URL : https://patchwork.freedesktop.org/series/110646/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12353 -> Patchwork_110646v1 ===

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [CI,1/7] drm/i915/huc: only load HuC on GTs that have VCS engines

== Series Details == Series: series starting with [CI,1/7] drm/i915/huc: only load HuC on GTs that have VCS engines URL : https://patchwork.freedesktop.org/series/110646/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [CI,1/7] drm/i915/huc: only load HuC on GTs that have VCS engines

== Series Details == Series: series starting with [CI,1/7] drm/i915/huc: only load HuC on GTs that have VCS engines URL : https://patchwork.freedesktop.org/series/110646/ State : warning == Summary == Error: dim checkpatch failed 0fecd071b686 drm/i915/huc: only load HuC on GTs that have VCS e

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix some kernel-doc comments

== Series Details == Series: drm/i915: Fix some kernel-doc comments URL : https://patchwork.freedesktop.org/series/110644/ State : success == Summary == CI Bug Log - changes from CI_DRM_12353 -> Patchwork_110644v1 Summary --- **SUCCE

[Intel-gfx] ✗ Fi.CI.BUILD: failure for KUnit issues - Was: [igt-dev] [PATCH RFC v2 8/8] drm/i915: check if current->mm is not NULL (rev3)

== Series Details == Series: KUnit issues - Was: [igt-dev] [PATCH RFC v2 8/8] drm/i915: check if current->mm is not NULL (rev3) URL : https://patchwork.freedesktop.org/series/110492/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/110492/revisions/

[Intel-gfx] [CI 5/7] drm/i915/mtl: Handle wopcm per-GT and limit calculations.

From: Aravind Iddamsetty With MTL standalone media architecture the wopcm layout has changed, with separate partitioning in WOPCM for the root GT GuC and the media GT GuC. The size of WOPCM is 4MB with the lower 2MB reserved for the media GT and the upper 2MB for the root GT. Given that MTL has

[Intel-gfx] [CI 6/7] drm/i915/guc: define media GT GuC send regs

The media GT shares the G-unit with the root GT, so a second set of communication registers is required for the media GuC. Signed-off-by: Daniele Ceraolo Spurio Cc: John Harrison Cc: Alan Previn Reviewed-by: John Harrison --- drivers/gpu/drm/i915/gt/uc/intel_guc.c | 14 ++ dri

[Intel-gfx] [CI 3/7] drm/i915/uc: use different ggtt pin offsets for uc loads

Our current FW loading process is the same for all FWs: - Pin FW to GGTT at the start of the ggtt->uc_fw node - Load the FW - Unpin This worked because we didn't have a case where 2 FWs would be loaded on the same GGTT at the same time. On MTL, however, this can happen if both GTs are reset at th

[Intel-gfx] [CI 4/7] drm/i915/guc: Add GuC deprivilege feature to MTL

From: Stuart Summers MTL supports GuC deprivilege. Add the feature flag to this platform. Signed-off-by: Stuart Summers Cc: Radhakrishna Sripada Cc: John Harrison Cc: Alan Previn Reviewed-by: John Harrison --- drivers/gpu/drm/i915/i915_pci.c | 1 + 1 file changed, 1 insertion(+) diff --gi

[Intel-gfx] [CI 2/7] drm/i915/uc: fetch uc firmwares for each GT

The FW binaries are independently loaded on each GT. On MTL, the memory is shared so we could potentially re-use a single allocation, but on discrete multi-gt platforms we are going to need independent copies, so it is easier to do the same on MTL as well, given that the amount of duplicated memory

[Intel-gfx] [CI 7/7] drm/i915/guc: handle interrupts from media GuC

The render and media GuCs share the same interrupt enable register, so we can no longer disable interrupts when we disable communication for one of the GuCs as this would impact the other GuC. Instead, we keep the interrupts always enabled in HW and use a variable in the GuC structure to determine

[Intel-gfx] [CI 1/7] drm/i915/huc: only load HuC on GTs that have VCS engines

On MTL the primary GT doesn't have any media capabilities, so no video engines and no HuC. We must therefore skip the HuC fetch and load on that specific case. Given that other multi-GT platforms might have HuC on the primary GT, we can't just check for that and it is easier to instead check for th

Re: [Intel-gfx] [CI 11/15] drm/i915/huc: track delayed HuC load with a fence

On 11/7/2022 5:41 PM, Brian Norris wrote: On Mon, Nov 07, 2022 at 10:38:14AM -0800, Ceraolo Spurio, Daniele wrote: Ok, I think I have an idea of what's happening: if HuC is not enabled, we skip the call to fence_fini, so we leak the debug object. Can you check if the below diff fixes the issu

Re: [Intel-gfx] [CI 11/15] drm/i915/huc: track delayed HuC load with a fence

On Mon, Nov 07, 2022 at 10:38:14AM -0800, Ceraolo Spurio, Daniele wrote: > Ok, I think I have an idea of what's happening: if HuC is not enabled, we > skip the call to fence_fini, so we leak the debug object. Can you check if > the below diff fixes the issue for you? Thanks for checking! This also

Re: [Intel-gfx] KUnit issues - Was: [igt-dev] [PATCH RFC v2 8/8] drm/i915: check if current->mm is not NULL

On Fri, Nov 4, 2022 at 12:20 PM Daniel Latypov wrote: > rm...@google.com was working on them and should hopefully be able to > send them out real soon. > You should get CC'd on those. > > I think the follow-up work is just crafting an example parser input > file and iterating until > $ ./tools/t

Re: [Intel-gfx] [PATCH v6 20/20] drm/i915/vm_bind: Async vm_unbind support

On Mon, 2022-11-07 at 00:52 -0800, Niranjana Vishwanathapura wrote: > Asynchronously unbind the vma upon vm_unbind call. > Fall back to synchronous unbind if backend doesn't support > async unbind or if async unbind fails. > > No need for vm_unbind out fence support as i915 will internally > handl

[Intel-gfx] [PATCH -next] drm/i915: Fix some kernel-doc comments

Fixs the function name in kernel-doc comments to clear the below warnings: drivers/gpu/drm/i915/gt/intel_engine_cs.c:1295: warning: expecting prototype for intel_engines_init_common(). Prototype was for engine_init_common() instead drivers/gpu/drm/i915/gt/intel_engine_cs.c:1377: warning: expectin

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Update workaround documentation

== Series Details == Series: drm/i915: Update workaround documentation URL : https://patchwork.freedesktop.org/series/110639/ State : success == Summary == CI Bug Log - changes from CI_DRM_12353 -> Patchwork_110639v1 Summary --- **SU

[Intel-gfx] ✗ Fi.CI.BUILD: failure for Connect VFIO to IOMMUFD (rev3)

== Series Details == Series: Connect VFIO to IOMMUFD (rev3) URL : https://patchwork.freedesktop.org/series/110133/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/110133/revisions/3/mbox/ not applied Applying: vfio: Move vfio_device driver open/clo

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Update workaround documentation

== Series Details == Series: drm/i915: Update workaround documentation URL : https://patchwork.freedesktop.org/series/110639/ State : warning == Summary == Error: dim checkpatch failed 834c980e8fe0 drm/i915: Update workaround documentation -:112: WARNING:BLOCK_COMMENT_STYLE: Block comments sho

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/perf: Fix kernel-doc warning

== Series Details == Series: drm/i915/perf: Fix kernel-doc warning URL : https://patchwork.freedesktop.org/series/110633/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12353 -> Patchwork_110633v1 Summary --- **FAILUR

[Intel-gfx] [PATCH v2 01/11] vfio: Move vfio_device driver open/close code to a function

This error unwind is getting complicated. Move all the code into two pair'd function. The functions should be called when the open_count == 1 after incrementing/before decrementing. Reviewed-by: Kevin Tian Reviewed-by: Yi Liu Tested-by: Nicolin Chen Signed-off-by: Jason Gunthorpe --- drivers/

[Intel-gfx] [PATCH v2 02/11] vfio: Move vfio_device_assign_container() into vfio_device_first_open()

The only thing this function does is assert the group has an assigned container and incrs refcounts. The overall model we have is that once a container_users refcount is incremented it cannot be de-assigned from the group - vfio_group_ioctl_unset_container() will fail and the group FD cannot be cl

[Intel-gfx] [PATCH v2 10/11] vfio: Make vfio_container optionally compiled

Add a kconfig CONFIG_VFIO_CONTAINER that controls compiling the container code. If 'n' then only iommufd will provide the container service. All the support for vfio iommu drivers, including type1, will not be built. This allows a compilation check that no inappropriate dependencies between the de

[Intel-gfx] [PATCH v2 04/11] vfio: Move storage of allow_unsafe_interrupts to vfio_main.c

This legacy module knob has become uAPI, when set on the vfio_iommu_type1 it disables some security protections in the iommu drivers. Move the storage for this knob to vfio_main.c so that iommufd can access it too. The may need enhancing as we learn more about how necessary allow_unsafe_interrupts

[Intel-gfx] [PATCH v2 09/11] vfio: Move container related MODULE_ALIAS statements into container.c

The miscdev is in container.c, so should these related MODULE_ALIAS statements. This is necessary for the next patch to be able to fully disable /dev/vfio/vfio. Fixes: cdc71fe4ecbf ("vfio: Move container code into drivers/vfio/container.c") Reported-by: "Liu, Yi L" Signed-off-by: Jason Gunthorpe

[Intel-gfx] [PATCH v2 05/11] vfio: Use IOMMU_CAP_ENFORCE_CACHE_COHERENCY for vfio_file_enforced_coherent()

iommufd doesn't establish the iommu_domains until after the device FD is opened, even if the container has been set. This design is part of moving away from the group centric iommu APIs. This is fine, except that the normal sequence of establishing the kvm wbinvd won't work: group = open("/dev

[Intel-gfx] [PATCH v2 00/11] Connect VFIO to IOMMUFD

This series provides an alternative container layer for VFIO implemented using iommufd. This is optional, if CONFIG_IOMMUFD is not set then it will not be compiled in. At this point iommufd can be injected by passing in a iommfd FD to VFIO_GROUP_SET_CONTAINER which will use the VFIO compat layer i

[Intel-gfx] [PATCH v2 06/11] vfio-iommufd: Allow iommufd to be used in place of a container fd

This makes VFIO_GROUP_SET_CONTAINER accept both a vfio container FD and an iommufd. In iommufd mode an IOAS will exist after the SET_CONTAINER, but it will not be attached to any groups. For VFIO this means that the VFIO_GROUP_GET_STATUS and VFIO_GROUP_FLAGS_VIABLE works subtly differently. With

[Intel-gfx] [PATCH v2 08/11] vfio-iommufd: Support iommufd for emulated VFIO devices

Emulated VFIO devices are calling vfio_register_emulated_iommu_dev() and consist of all the mdev drivers. Like the physical drivers, support for iommufd is provided by the driver supplying the correct standard ops. Provide ops from the core that duplicate what vfio_register_emulated_iommu_dev() do

[Intel-gfx] [PATCH v2 03/11] vfio: Rename vfio_device_assign/unassign_container()

These functions don't really assign anything anymore, they just increment some refcounts and do a sanity check. Call them vfio_group_[un]use_container() Reviewed-by: Kevin Tian Reviewed-by: Yi Liu Tested-by: Nicolin Chen Signed-off-by: Jason Gunthorpe --- drivers/vfio/container.c | 14 ++-

[Intel-gfx] [PATCH v2 07/11] vfio-iommufd: Support iommufd for physical VFIO devices

This creates the iommufd_device for the physical VFIO drivers. These are all the drivers that are calling vfio_register_group_dev() and expect the type1 code to setup a real iommu_domain against their parent struct device. The design gives the driver a choice in how it gets connected to iommufd by

[Intel-gfx] [PATCH v2 11/11] iommufd: Allow iommufd to supply /dev/vfio/vfio

If the VFIO container is compiled out, give a kconfig option for iommufd to provide the miscdev node with the same name and permissions as vfio uses. The compatibility node supports the same ioctls as VFIO and automatically enables the VFIO compatible pinned page accounting mode. Tested-by: Nicol

Re: [Intel-gfx] [PATCH 1/2] i915/uncore: Acquire fw before loop in intel_uncore_read64_2x32

On Mon, 07 Nov 2022 16:11:27 -0800, Umesh Nerlige Ramappa wrote: > > On Mon, Nov 07, 2022 at 01:23:19PM -0800, Dixit, Ashutosh wrote: > > On Mon, 07 Nov 2022 02:13:46 -0800, Tvrtko Ursulin wrote: > >> > >> On 05/11/2022 00:32, Umesh Nerlige Ramappa wrote: > >> > PMU reads the GT timestamp as a 2x32

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/perf: Fix kernel-doc warning

== Series Details == Series: drm/i915/perf: Fix kernel-doc warning URL : https://patchwork.freedesktop.org/series/110633/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.

[Intel-gfx] [PATCH] drm/i915: Update workaround documentation

There were several updates in the driver on how the workarounds are handled since its documentation was written. Update the documentation to reflect the current reality. Signed-off-by: Lucas De Marchi --- drivers/gpu/drm/i915/gt/intel_workarounds.c | 87 + 1 file changed, 56

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix audio/infroframes on g4x

== Series Details == Series: drm/i915: Fix audio/infroframes on g4x URL : https://patchwork.freedesktop.org/series/110629/ State : success == Summary == CI Bug Log - changes from CI_DRM_12353 -> Patchwork_110629v1 Summary --- **SUCCE

Re: [Intel-gfx] [PATCH 1/2] i915/uncore: Acquire fw before loop in intel_uncore_read64_2x32

On Mon, Nov 07, 2022 at 01:23:19PM -0800, Dixit, Ashutosh wrote: On Mon, 07 Nov 2022 02:13:46 -0800, Tvrtko Ursulin wrote: On 05/11/2022 00:32, Umesh Nerlige Ramappa wrote: > PMU reads the GT timestamp as a 2x32 mmio read and since upper and lower > 32 bit registers are read in a loop, there is

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915/ttm: fix uaf with lmem_userfault_list handling

== Series Details == Series: series starting with [1/2] drm/i915/ttm: fix uaf with lmem_userfault_list handling URL : https://patchwork.freedesktop.org/series/110613/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12351_full -> Patchwork_110613v1_full =

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Fix audio/infroframes on g4x

== Series Details == Series: drm/i915: Fix audio/infroframes on g4x URL : https://patchwork.freedesktop.org/series/110629/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +./arch/x86/include/asm/bitops.h:117

[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Use XArray instead of IDR for minors

== Series Details == Series: drm: Use XArray instead of IDR for minors URL : https://patchwork.freedesktop.org/series/110621/ State : success == Summary == CI Bug Log - changes from CI_DRM_12353 -> Patchwork_110621v1 Summary --- **SU

[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915: prepare for uC loading on MTL (rev6)

== Series Details == Series: drm/i915: prepare for uC loading on MTL (rev6) URL : https://patchwork.freedesktop.org/series/108925/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/108925/revisions/6/mbox/ not applied Applying: drm/i915/huc: only loa

Re: [Intel-gfx] [PATCH 06/10] vfio-iommufd: Allow iommufd to be used in place of a container fd

On Wed, Nov 02, 2022 at 03:28:20PM +0800, Yi Liu wrote: > On 2022/10/26 02:50, Jason Gunthorpe wrote: > > This makes VFIO_GROUP_SET_CONTAINER accept both a vfio container FD and an > > iommufd. > > > > In iommufd mode an IOAS will exist after the SET_CONTAINER, but it will > > not be attached to a

Re: [Intel-gfx] [PATCH] drm/i915/mtl: Media GT and Render GT share common GGTT

On Mon, Nov 07, 2022 at 07:43:59PM +0530, Iddamsetty, Aravind wrote: > > > On 31-10-2022 23:16, Matt Roper wrote: > > On Mon, Oct 31, 2022 at 06:01:11PM +0530, Aravind Iddamsetty wrote: > >> On XE_LPM+ platforms the media engines are carved out into a separate > >> GT but have a common GGTMMADR a

Re: [Intel-gfx] [PATCH 2/2] drm/i915/selftest: Bump up sample period for busy stats selftest

On Fri, 04 Nov 2022 17:32:35 -0700, Umesh Nerlige Ramappa wrote: > > Engine busyness samples around a 10ms period is failing with busyness > ranging approx. from 87% to 115%. The expected range is +/- 5% of the > sample period. > > When determining busyness of active engine, the GuC based engine >

[Intel-gfx] ✗ Fi.CI.DOCS: warning for drm: Use XArray instead of IDR for minors

== Series Details == Series: drm: Use XArray instead of IDR for minors URL : https://patchwork.freedesktop.org/series/110621/ State : warning == Summary == Error: make htmldocs had i915 warnings ./drivers/gpu/drm/i915/i915_perf_types.h:319: warning: Function parameter or member 'lock' not des

Re: [Intel-gfx] KUnit issues - Was: [igt-dev] [PATCH RFC v2 8/8] drm/i915: check if current->mm is not NULL

On Mon, Nov 7, 2022 at 10:38 AM Michał Winiarski wrote: > > On Thu, Nov 03, 2022 at 04:23:02PM +0100, Mauro Carvalho Chehab wrote: > > Hi, > > > > I'm facing a couple of issues when testing KUnit with the i915 driver. > > > > The DRM subsystem and the i915 driver has, for a long time, his own > >

[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915: use i915_sg_dma_sizes() for all backends

== Series Details == Series: drm/i915: use i915_sg_dma_sizes() for all backends URL : https://patchwork.freedesktop.org/series/110620/ State : failure == Summary == Error: make failed CALLscripts/checksyscalls.sh DESCEND objtool LD [M] drivers/gpu/drm/i915/i915.o CC [M] drivers/g

[Intel-gfx] ✓ Fi.CI.BAT: success for Documentation/gpu: reduce verbosity in toc

== Series Details == Series: Documentation/gpu: reduce verbosity in toc URL : https://patchwork.freedesktop.org/series/110618/ State : success == Summary == CI Bug Log - changes from CI_DRM_12353 -> Patchwork_110618v1 Summary --- **S

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/pxp: use <> instead of "" for headers in include/

== Series Details == Series: drm/i915/pxp: use <> instead of "" for headers in include/ URL : https://patchwork.freedesktop.org/series/110602/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12351_full -> Patchwork_110602v1_full ==

[Intel-gfx] ✗ Fi.CI.DOCS: warning for Documentation/gpu: reduce verbosity in toc

== Series Details == Series: Documentation/gpu: reduce verbosity in toc URL : https://patchwork.freedesktop.org/series/110618/ State : warning == Summary == Error: make htmldocs had i915 warnings ./drivers/gpu/drm/i915/i915_perf_types.h:319: warning: Function parameter or member 'lock' not de

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/tgl+: Enable DC power states on all eDP ports (rev2)

== Series Details == Series: drm/i915/tgl+: Enable DC power states on all eDP ports (rev2) URL : https://patchwork.freedesktop.org/series/110433/ State : success == Summary == CI Bug Log - changes from CI_DRM_12353 -> Patchwork_110433v2 Sum

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/tgl+: Enable DC power states on all eDP ports (rev2)

== Series Details == Series: drm/i915/tgl+: Enable DC power states on all eDP ports (rev2) URL : https://patchwork.freedesktop.org/series/110433/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/tgl+: Enable DC power states on all eDP ports (rev2)

== Series Details == Series: drm/i915/tgl+: Enable DC power states on all eDP ports (rev2) URL : https://patchwork.freedesktop.org/series/110433/ State : warning == Summary == Error: dim checkpatch failed 8e83b3cd5464 drm/i915: Allocate power domain set wakerefs dynamically -:88: CHECK:BRACES:

Re: [Intel-gfx] [PATCH 1/2] i915/uncore: Acquire fw before loop in intel_uncore_read64_2x32

On Mon, 07 Nov 2022 02:13:46 -0800, Tvrtko Ursulin wrote: > > On 05/11/2022 00:32, Umesh Nerlige Ramappa wrote: > > PMU reads the GT timestamp as a 2x32 mmio read and since upper and lower > > 32 bit registers are read in a loop, there is a latency involved between > > getting the GT timestamp and

Re: [Intel-gfx] [PATCH] drm/i915/perf: Fix kernel-doc warning

On Mon, 07 Nov 2022 12:24:10 -0800, Umesh Nerlige Ramappa wrote: > > Fix kernel-doc issue from a previous commit. Reviewed-by: Ashutosh Dixit > Signed-off-by: Umesh Nerlige Ramappa > Fixes: 2db609c01495 ("drm/i915/perf: Replace gt->perf.lock with stream->lock > for file ops") > --- > drivers/

Re: [Intel-gfx] [PATCH 26/26] drm/i915/gt: Remove #ifdef guards for PM related functions

On Mon, Nov 07, 2022 at 05:55:10PM +, Paul Cercueil wrote: > Instead of defining two versions of intel_sysfs_rc6_init(), one for each > value of CONFIG_PM, add a check on !IS_ENABLED(CONFIG_PM) early in the > function. This will allow the compiler to automatically drop the dead > code when CONF

[Intel-gfx] [PATCH] drm/i915/perf: Fix kernel-doc warning

Fix kernel-doc issue from a previous commit. Signed-off-by: Umesh Nerlige Ramappa Fixes: 2db609c01495 ("drm/i915/perf: Replace gt->perf.lock with stream->lock for file ops") --- drivers/gpu/drm/i915/i915_perf_types.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/driver

[Intel-gfx] [PATCH 4/5] drm/i915: Move has_hdmi_sink out from intel_hdmi_compute_config()

From: Ville Syrjälä We'll be wanting to compute has_hdmi_sink a bit differently for some platforms. To that end compute it in the encoder .compute_config_hook() before we call intel_hdmi_compute_config(). intel_hdmi_compute_has_hdmi_sink() will do the basic lifting beyond any platform specific st

[Intel-gfx] [PATCH 5/5] drm/i915: Pick one HDMI port for infoframe/audio transmission on g4x

From: Ville Syrjälä On g4x the hardware has only one audio/video DIP block. Thus only one HDMI port can transmit audio/infoframes at a time. Currently we pretend that multiple ports can do it at the same time, but that doesn't actually work for two reasons: - the state of the single hw block will

[Intel-gfx] [PATCH 3/5] drm/i915: Treat HDMI as DVI when cloning

From: Ville Syrjälä When doing HDMI+non-HDMI cloing the other sink can't get the inframes/etc. so stuff like limited range output is not a good idea. Similarly when doing HDMI+HDMI cloning on g4x (only platform where we allow it) only one of the ports can receive infoframes and so again using an

[Intel-gfx] [PATCH 2/5] drm/i915: Force RGB output for DVI sink

From: Ville Syrjälä YCbCr output requires infoframes and whatnot, so don't allow it when dealing with a DVI sink (or a HDMI sink we wishc to treat as DVI). Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_hdmi.c | 11 --- 1 file changed, 8 insertions(+), 3 deletions(

[Intel-gfx] [PATCH 1/5] drm/i915: Introduce g4x_hdmi_compute_config()

From: Ville Syrjälä Start pulling some of the more platform specific things out from intel_hdmi_compute_config(). has_pch_encoder is clearly one such thing. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/g4x_hdmi.c | 14 +- drivers/gpu/drm/i915/display/intel_hdmi.c

[Intel-gfx] [PATCH 0/5] drm/i915: Fix audio/infroframes on g4x

From: Ville Syrjälä Currently HDMI audio/infoframes is a bit borked on g4x on account of the hardware only having one audio/video DIP block which can't be shared among multiple HDMI ports simultanously. Fix that by selecting exactly one of the enabled HDMI ports for audio/infoframe transmission.

Re: [Intel-gfx] [PATCH] drm/i915: Don't wait forever in drop_caches

On 11/7/2022 06:09, Tvrtko Ursulin wrote: On 04/11/2022 17:45, John Harrison wrote: On 11/4/2022 03:01, Tvrtko Ursulin wrote: On 03/11/2022 19:16, John Harrison wrote: On 11/3/2022 02:38, Tvrtko Ursulin wrote: On 03/11/2022 09:18, Tvrtko Ursulin wrote: On 03/11/2022 01:33, John Harrison wrot

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/ttm: fix uaf with lmem_userfault_list handling

== Series Details == Series: series starting with [1/2] drm/i915/ttm: fix uaf with lmem_userfault_list handling URL : https://patchwork.freedesktop.org/series/110613/ State : success == Summary == CI Bug Log - changes from CI_DRM_12351 -> Patchwork_110613v1 ===

Re: [Intel-gfx] [PATCH v5 1/3] drm: Use XArray instead of IDR for minors

On Mon, Nov 7, 2022 at 6:20 PM Matthew Wilcox wrote: > > On Sun, Nov 06, 2022 at 04:51:39PM +0200, Oded Gabbay wrote: > > I tried executing the following code in a dummy driver I wrote: > > You don't need to write a dummy driver; you can write test-cases > entirely in userspace. Just add them to

Re: [Intel-gfx] [PATCH 1/2] drm/i915/gt: Add GT oriented dmesg output

On 11/7/2022 08:17, Tvrtko Ursulin wrote: On 07/11/2022 09:33, Tvrtko Ursulin wrote: On 05/11/2022 01:03, Ceraolo Spurio, Daniele wrote: On 11/4/2022 10:25 AM, john.c.harri...@intel.com wrote: From: John Harrison When trying to analyse bug reports from CI, customers, etc. it can be difficult

Re: [Intel-gfx] [PATCH 2/2] drm/i915/selftest: Bump up sample period for busy stats selftest

On Mon, Nov 07, 2022 at 10:16:20AM +, Tvrtko Ursulin wrote: On 05/11/2022 00:32, Umesh Nerlige Ramappa wrote: Engine busyness samples around a 10ms period is failing with busyness ranging approx. from 87% to 115%. The expected range is +/- 5% of the sample period. When determining busyness

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/pxp: use <> instead of "" for headers in include/

== Series Details == Series: drm/i915/pxp: use <> instead of "" for headers in include/ URL : https://patchwork.freedesktop.org/series/110602/ State : success == Summary == CI Bug Log - changes from CI_DRM_12351 -> Patchwork_110602v1 Summar

[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm: Analog TV Improvements (rev7)

== Series Details == Series: drm: Analog TV Improvements (rev7) URL : https://patchwork.freedesktop.org/series/107892/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/107892/revisions/7/mbox/ not applied Applying: drm/tests: Add Kunit Helpers Apply

Re: [Intel-gfx] [PATCH 04/10] vfio: Move storage of allow_unsafe_interrupts to vfio_main.c

On Mon, Nov 07, 2022 at 11:05:08AM -0700, Alex Williamson wrote: > After further consideration... I don't think the option on vfio-main > makes sense, basically for the same reason that the original option > existed on the IOMMU backend rather than vfio-core. The option > describes a means to rel

Re: [Intel-gfx] [CI 11/15] drm/i915/huc: track delayed HuC load with a fence

On 11/4/2022 6:27 PM, Brian Norris wrote: Hi, On Fri, Nov 04, 2022 at 05:49:54PM -0700, Ceraolo Spurio, Daniele wrote: On 11/4/2022 5:38 PM, Ceraolo Spurio, Daniele wrote: On 11/4/2022 4:26 PM, Brian Norris wrote: Did you track this down? Or consider reverting? This is tripping me up No.

Re: [Intel-gfx] KUnit issues - Was: [igt-dev] [PATCH RFC v2 8/8] drm/i915: check if current->mm is not NULL

On Thu, Nov 03, 2022 at 04:23:02PM +0100, Mauro Carvalho Chehab wrote: > Hi, > > I'm facing a couple of issues when testing KUnit with the i915 driver. > > The DRM subsystem and the i915 driver has, for a long time, his own > way to do unit tests, which seems to be added before KUnit. > > I'm no

Re: [Intel-gfx] [PATCH v2 3/5] drm/i915/mtl: add GSC CS interrupt support

On Wed, Nov 02, 2022 at 10:10:45AM -0700, Daniele Ceraolo Spurio wrote: > The GSC CS re-uses the same interrupt bits that the GSC used in older > platforms. This means that we can now have an engine interrupt coming > out of OTHER_CLASS, so we need to handle that appropriately. > > v2: clean up th

Re: [Intel-gfx] [mm-unstable PATCH v7 2/8] mm/hugetlb: make pud_huge() and follow_huge_pud() aware of non-present pud entry

On Sat, Nov 05, 2022 at 12:23:40AM +0200, Ville Syrjälä wrote: > On Sat, Nov 05, 2022 at 12:59:30AM +0900, Naoya Horiguchi wrote: > > On Wed, Nov 02, 2022 at 10:51:40PM +0200, Ville Syrjälä wrote: > > > On Thu, Jul 14, 2022 at 01:24:14PM +0900, Naoya Horiguchi wrote: > > > > +/* > > > > + * pud_hug

[Intel-gfx] [PATCH 26/26] drm/i915/gt: Remove #ifdef guards for PM related functions

Instead of defining two versions of intel_sysfs_rc6_init(), one for each value of CONFIG_PM, add a check on !IS_ENABLED(CONFIG_PM) early in the function. This will allow the compiler to automatically drop the dead code when CONFIG_PM is disabled, without having to use #ifdef guards. This has the a

Re: [Intel-gfx] [PATCH v7 16/23] drm/probe-helper: Provide a TV get_modes helper

Den 07.11.2022 15.16, skrev Maxime Ripard: > From: Noralf Trønnes > > Most of the TV connectors will need a similar get_modes implementation > that will, depending on the drivers' capabilities, register the 480i and > 576i modes. > > That implementation will also need to set the preferred fla

Re: [Intel-gfx] [PATCH 04/10] vfio: Move storage of allow_unsafe_interrupts to vfio_main.c

On Mon, 7 Nov 2022 11:32:40 -0400 Jason Gunthorpe wrote: > On Mon, Nov 07, 2022 at 08:18:53AM -0700, Alex Williamson wrote: > > On Mon, 7 Nov 2022 09:19:43 -0400 > > Jason Gunthorpe wrote: > > > > > On Mon, Oct 31, 2022 at 04:45:26PM -0600, Alex Williamson wrote: > > > > > > > > It is one

Re: [Intel-gfx] [PATCH v7 15/23] drm/modes: Introduce more named modes

Den 07.11.2022 15.16, skrev Maxime Ripard: > Now that we can easily extend the named modes list, let's add a few more > analog TV modes that were used in the wild, and some unit tests to make > sure it works as intended. > > Signed-off-by: Maxime Ripard > > --- > Changes in v6: > - Renamed th

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/ttm: never purge busy objects

== Series Details == Series: drm/i915/ttm: never purge busy objects URL : https://patchwork.freedesktop.org/series/110601/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12351 -> Patchwork_110601v1 Summary --- **FAILU

Re: [Intel-gfx] [PATCH v5 1/3] drm: Use XArray instead of IDR for minors

On Sun, Nov 06, 2022 at 04:51:39PM +0200, Oded Gabbay wrote: > On Wed, Nov 2, 2022 at 4:23 PM Oded Gabbay wrote: > > > > On Mon, Sep 12, 2022 at 12:17 AM Michał Winiarski > > wrote: > > > > > > IDR is deprecated, and since XArray manages its own state with internal > > > locking, it simplifies th

Re: [Intel-gfx] [PATCH v7 14/23] drm/modes: Properly generate a drm_display_mode from a named mode

Den 07.11.2022 15.16, skrev Maxime Ripard: > The framework will get the drm_display_mode from the drm_cmdline_mode it > got by parsing the video command line argument by calling > drm_connector_pick_cmdline_mode(). > > The heavy lifting will then be done by the drm_mode_create_from_cmdline_mode

[Intel-gfx] [PATCH v3] drm: Use XArray instead of IDR for minors

IDR is deprecated, and since XArray manages its own state with internal locking, it simplifies the locking on DRM side. Additionally, don't use the IRQ-safe variant, since operating on drm minor is not done in IRQ context. Signed-off-by: Michał Winiarski Suggested-by: Matthew Wilcox --- This was

  1   2   3   >