Re: [Intel-gfx] [PATCH v4 9/9] vfio/pci: Allow passing zero-length fd array in VFIO_DEVICE_PCI_HOT_RESET

> From: Tian, Kevin > Sent: Thursday, April 27, 2023 2:54 PM > > > From: Liu, Yi L > > Sent: Wednesday, April 26, 2023 10:54 PM > > > > +static bool vfio_dev_in_iommufd_ctx(struct vfio_pci_core_device *vdev, > > + struct iommufd_ctx *iommufd_ctx) > > +{ > > + stru

Re: [Intel-gfx] [PATCH v4 1/9] vfio: Determine noiommu in vfio_device registration

> From: Tian, Kevin > Sent: Thursday, April 27, 2023 2:36 PM > > > From: Liu, Yi L > > Sent: Wednesday, April 26, 2023 10:54 PM > > > > -static inline bool vfio_device_is_noiommu(struct vfio_device *vdev) > > +static inline int vfio_device_set_noiommu(struct vfio_device *device) > > { > > - r

Re: [Intel-gfx] [PATCH v4 6/9] iommufd: Reserved -1 in the iommufd xarray

> From: Tian, Kevin > Sent: Thursday, April 27, 2023 2:42 PM > > > From: Liu, Yi L > > Sent: Wednesday, April 26, 2023 10:54 PM > > > > VFIO needs two reserved values. 0 is already reserved by initializing > > xarray with XA_FLAGS_ALLOC1. This reserves -1 by limiting the xa alloc > > range. > >

Re: [Intel-gfx] [PATCH v4 7/9] vfio-iommufd: Add helper to retrieve iommufd_ctx and devid for vfio_device

> From: Tian, Kevin > Sent: Thursday, April 27, 2023 2:46 PM > > > From: Yi Liu > > Sent: Wednesday, April 26, 2023 10:54 PM > > + > > +/* > > + * Return devid for devices that have been bound with iommufd, > > + * returns 0 if not bound yet. > > + */ > > +u32 vfio_iommufd_physical_devid(struct v

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Hugepage manager and test for MTL (rev2)

On 27.04.2023 00:29, Patchwork wrote: *Patch Details* *Series:* drm/i915: Hugepage manager and test for MTL (rev2) *URL:* https://patchwork.freedesktop.org/series/116995/ *State:*failure *Details:* https://intel-gfx-ci.01.org/tre

Re: [Intel-gfx] [PATCH 06/13] drm/i915/mtl: For DP2.0 10G and 20G rates use MPLLA

> -Original Message- > From: Intel-gfx On Behalf Of Mika > Kahola > Sent: Thursday, April 20, 2023 6:11 PM > To: intel-gfx@lists.freedesktop.org > Subject: [Intel-gfx] [PATCH 06/13] drm/i915/mtl: For DP2.0 10G and 20G rates > use MPLLA > > Use MPLLA for DP2.0 rates 20G and 20G, when ss

Re: [Intel-gfx] [PATCH v6 1/2] drm/i915/guc/slpc: Provide sysfs for efficient freq

Hi Vinay, On Tue, Apr 25, 2023 at 05:39:41PM -0700, Vinay Belgaumkar wrote: > SLPC enables use of efficient freq at init by default. It is > possible for GuC to request frequencies that are higher than > the 'software' max if user has set it lower than the efficient > level. > > Scenarios/tests t

Re: [Intel-gfx] [PATCH v6 2/2] drm/i915/selftest: Update the SLPC selftest

Hi Vinay, On Tue, Apr 25, 2023 at 05:39:42PM -0700, Vinay Belgaumkar wrote: > Use the new efficient frequency toggling interface. Also > create a helper function to restore the frequencies after > the test is done. > > v2: Restore max freq first and then min. > > Signed-off-by: Vinay Belgaumkar

Re: [Intel-gfx] [PATCH 02/13] drm/i915/mtl: C20 HW readout

> -Original Message- > From: Murthy, Arun R > Sent: Thursday, April 27, 2023 6:31 AM > To: Kahola, Mika ; intel-gfx@lists.freedesktop.org > Cc: Nautiyal, Ankit K > Subject: RE: [PATCH 02/13] drm/i915/mtl: C20 HW readout > > > -Original Message- > > From: Kahola, Mika > > Sent: T

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

Hi Dave & Daniel, Just one Cc stable SKL+ pipe source size fix for #8357: CML-U: external 5120x2160 monitor can't play video. Best Regards, Joonas *** drm-intel-next-fixes-2023-04-27: One cc stable for pipe source size check on SKL+ The following changes since commit 2c69679626d5daa680d71c77a

Re: [Intel-gfx] [Intel-xe] [PATCH] drm/xe/display: Do not use i915 frontbuffer tracking implementation

On Thu, 2023-03-09 at 14:34 +0200, Ville Syrjälä wrote: > On Thu, Mar 09, 2023 at 12:09:55PM +0100, Maarten Lankhorst wrote: > > > > On 2023-03-09 12:04, Hogander, Jouni wrote: > > > On Mon, 2023-03-06 at 22:58 +0200, Ville Syrjälä wrote: > > > > On Mon, Mar 06, 2023 at 09:23:50PM +0100, Maarten L

Re: [Intel-gfx] [PATCH v4 6/9] iommufd: Reserved -1 in the iommufd xarray

On Thu, Apr 27, 2023 at 07:09:38AM +, Liu, Yi L wrote: > > > @@ -50,7 +53,7 @@ struct iommufd_object *_iommufd_object_alloc(struct > > > iommufd_ctx *ictx, > > >* before calling iommufd_object_finalize(). > > >*/ > > > rc = xa_alloc(&ictx->objects, &obj->id, XA_ZERO_ENTRY, > > > -

[Intel-gfx] [RFC 0/4] Expose RPS thresholds in sysfs

From: Tvrtko Ursulin >From patch 4: User feedback indicates significant performance gains are possible in specific games with non default RPS up/down thresholds. Expose these tunables via sysfs which will allow users to achieve best performance when running games and best power

[Intel-gfx] [RFC 1/4] drm/i915: Move setting of rps thresholds to init

From: Tvrtko Ursulin Since 36d516be867c ("drm/i915/gt: Switch to manual evaluation of RPS") thresholds are invariant so lets move their setting to init time. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/gt/intel_rps.c | 27 --- 1 file changed, 16 insertions(+)

[Intel-gfx] [RFC 2/4] drm/i915: Record default rps threshold values

From: Tvrtko Ursulin Record the default values as preparation for exposing the sysfs controls. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 +++ drivers/gpu/drm/i915/gt/intel_rps.c | 2 ++ 2 files changed, 5 insertions(+) diff --git a/drivers/gpu/drm/i91

[Intel-gfx] [RFC 4/4] drm/i915: Expose RPS thresholds in sysfs

From: Tvrtko Ursulin User feedback indicates significant performance gains are possible in specific games with non default RPS up/down thresholds. Expose these tunables via sysfs which will allow users to achieve best performance when running games and best power efficiency elsewhere. Note this

[Intel-gfx] [RFC 3/4] drm/i915: Add helpers for managing rps thresholds

From: Tvrtko Ursulin In preparation for exposing via sysfs add helpers for managing rps thresholds. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/gt/intel_rps.c | 36 + drivers/gpu/drm/i915/gt/intel_rps.h | 4 2 files changed, 40 insertions(+) diff -

[Intel-gfx] [PATCH 0/6] Introduce sink_format and other fixes

This patch series is part of a previous series: https://patchwork.freedesktop.org/series/109470/ This adds new member sink_format to store the final format that the sink will be using, which might be different than the output format, and thus might need color/format conversion performed by the PCO

[Intel-gfx] [PATCH 1/6] drm/i915/display: Add new member to configure PCON color conversion

The decision to use DFP output format conversion capabilities should be during compute_config phase. This patch adds new member to crtc_state to represent the final output_format to the sink. In case of a DFP this can be different than the output_format, as per the format conversion done via the P

[Intel-gfx] [PATCH 4/6] drm/i915/display: Use sink_format instead of ycbcr420_output flag

Start passing the sink_format, to all functions that take a bool ycbcr420_output as parameter. This will make the functions generic, and will serve as a slight step towards 4:2:2 support later. v2: Rebased. v3: Correct the checks in places concerned with pipe output. (Ville) Other minor styling a

[Intel-gfx] [PATCH 3/6] drm/i915/dp: Configure PCON for conversion of output_format to YCbCr444

Handle the case with DP to HDMI PCON, where sink_format is set to YCbCr444. In that case PCON is required to be configured to convert from given output_format to YCbCR444. v2: Drop drm_WARN for invalid case, let MISSING_CASE catch it. (Ville) Signed-off-by: Ankit Nautiyal Reviewed-by: Ville Syrj

[Intel-gfx] [PATCH 2/6] drm/i915/dp: Replace intel_dp.dfp members with the new crtc_state sink_format

The decision to use DFP output format conversion capabilities should be during compute_config phase. This patch uses the members of intel_dp->dfp to only store the format conversion capabilities of the DP device and uses the crtc_state sink_format member, to program the protocol-converter for colo

[Intel-gfx] [PATCH 6/6] drm/i915/dp: Rearrange check for illegal mode and comments in mode_valid

Check for MODE_H_ILLEGAL before calculating max rates, lanes etc. Move comments about compressed bpp U6.4 format closer to where it is used. Signed-off-by: Ankit Nautiyal Reviewed-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_dp.c | 14 +++--- 1 file changed, 7 insertions(+),

[Intel-gfx] [PATCH 5/6] drm/i915/dp: Add helper to get sink_format

Common function to get the sink format for a given mode for DP. Signed-off-by: Ankit Nautiyal Reviewed-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_dp.c | 30 - 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel

[Intel-gfx] [PATCH v3 0/8] mtl: add support for pmdeman

pmdemand support patches for MTL SAGV configuration support for MTL v2: added one missing patch in the previous version v3: chekcpatch warning fixes update index handling for the icl/tgl QGV point handling program pmdemand code simplified v4: update to debufs and pipe values pmdemand re

[Intel-gfx] [PATCH v3 1/8] drm/i915: fix the derating percentage for MTL

Follow the values from bspec for the percentage overhead for efficiency in MTL BW calculations. Bspec: 64631 Signed-off-by: Vinod Govindapillai --- drivers/gpu/drm/i915/display/intel_bw.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_bw.c

[Intel-gfx] [PATCH v3 2/8] drm/i915: update the QGV point frequency calculations

>From MTL onwwards, pcode locks the QGV point based on peak BW of the intended QGV point passed by the driver. So the peak BW calculation must match the value expected by the pcode. Update the calculations as per the Bspec. Bspec: 64636 Signed-off-by: Vinod Govindapillai --- drivers/gpu/drm/i91

[Intel-gfx] [PATCH v3 3/8] drm/i915: store the peak bw per QGV point

In MTL onwards, pcode locks the GV point based on the peak BW of a QGV point. So store the peak BW of all the QGV points. Bspec: 64636 Signed-off-by: Vinod Govindapillai --- drivers/gpu/drm/i915/display/intel_bw.c | 7 +-- drivers/gpu/drm/i915/display/intel_display_core.h | 2 ++

[Intel-gfx] [PATCH v3 5/8] drm/i915: modify max_bw to return index to intel_bw_info

MTL uses the peak BW of a QGV point to lock the required QGV point instead of the QGV index. Instead of passing the deratedbw of the selected bw_info, return the index to the selected bw_info so that either deratedbw or peakbw can be used based on the platform. v2: use idx to store index returned

[Intel-gfx] [PATCH v3 4/8] drm/i915: extract intel_bw_check_qgv_points()

Extract intel_bw_check_qgv_points() from intel_bw_atomic_check to facilitate future platform variations in handling SAGV configurations. Signed-off-by: Vinod Govindapillai --- drivers/gpu/drm/i915/display/intel_bw.c | 235 +--- 1 file changed, 130 insertions(+), 105 deletions

[Intel-gfx] [PATCH v3 7/8] drm/i915/mtl: Add support for PM DEMAND

From: Mika Kahola Display14 introduces a new way to instruct the PUnit with power and bandwidth requirements of DE. Add the functionality to program the registers and handle waits using interrupts. The current wait time for timeouts is programmed for 10 msecs to factor in the worst case scenarios

[Intel-gfx] [PATCH v3 8/8] drm/i915/display: provision to suppress drm_warn in intel_get_crtc_new_encoder

While configuring pmdemand parameters, there could be intel_get_crtc_new_encoder call where encoders could be 0. To avoid invoking drm_warn in such cases, use a parameter to indicate drm_warn should be suppressed. v2: checkpatch warning fixes Signed-off-by: Vinod Govindapillai --- drivers/gpu/d

[Intel-gfx] [PATCH v3 6/8] drm/i915/mtl: find best QGV point and configure sagv

>From MTL onwards, we need to find the best QGV point based on the required data rate and pass the peak BW of that point to the punit to lock the corresponding QGV point. Bspec: 64636 Signed-off-by: Vinod Govindapillai --- drivers/gpu/drm/i915/display/intel_bw.c | 87 -

Re: [Intel-gfx] [PATCH v2 0/5] drm/i915: Allow user to set cache at BO creation

On 26/04/2023 16:41, Yang, Fei wrote: > On 26/04/2023 07:24, fei.y...@intel.com wrote: >> From: Fei Yang >> >> The first three patches in this series are taken from >> https://patchwork.freedesktop.org/series/116868/ >> These patches are included here because the last patch >> has depen

[Intel-gfx] [PATCH v3 1/8] drm/i915: fix the derating percentage for MTL

Follow the values from bspec for the percentage overhead for efficiency in MTL BW calculations. Bspec: 64631 Signed-off-by: Vinod Govindapillai --- drivers/gpu/drm/i915/display/intel_bw.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_bw.c

[Intel-gfx] [PATCH v3 0/8] mtl: add support for pmdemand

pmdemand support patches for MTL SAGV configuration support for MTL v2: added one missing patch in the previous version v3: chekcpatch warning fixes update index handling for the icl/tgl QGV point handling program pmdemand code simplified v4: update to debufs and pipe values pmdemand re

[Intel-gfx] [PATCH v3 2/8] drm/i915: update the QGV point frequency calculations

>From MTL onwwards, pcode locks the QGV point based on peak BW of the intended QGV point passed by the driver. So the peak BW calculation must match the value expected by the pcode. Update the calculations as per the Bspec. Bspec: 64636 Signed-off-by: Vinod Govindapillai --- drivers/gpu/drm/i91

[Intel-gfx] [PATCH v3 3/8] drm/i915: store the peak bw per QGV point

In MTL onwards, pcode locks the GV point based on the peak BW of a QGV point. So store the peak BW of all the QGV points. Bspec: 64636 Signed-off-by: Vinod Govindapillai --- drivers/gpu/drm/i915/display/intel_bw.c | 7 +-- drivers/gpu/drm/i915/display/intel_display_core.h | 2 ++

[Intel-gfx] [PATCH v3 4/8] drm/i915: extract intel_bw_check_qgv_points()

Extract intel_bw_check_qgv_points() from intel_bw_atomic_check to facilitate future platform variations in handling SAGV configurations. Signed-off-by: Vinod Govindapillai --- drivers/gpu/drm/i915/display/intel_bw.c | 235 +--- 1 file changed, 130 insertions(+), 105 deletions

[Intel-gfx] [PATCH v3 5/8] drm/i915: modify max_bw to return index to intel_bw_info

MTL uses the peak BW of a QGV point to lock the required QGV point instead of the QGV index. Instead of passing the deratedbw of the selected bw_info, return the index to the selected bw_info so that either deratedbw or peakbw can be used based on the platform. v2: use idx to store index returned

[Intel-gfx] [PATCH v3 6/8] drm/i915/mtl: find best QGV point and configure sagv

>From MTL onwards, we need to find the best QGV point based on the required data rate and pass the peak BW of that point to the punit to lock the corresponding QGV point. Bspec: 64636 Signed-off-by: Vinod Govindapillai --- drivers/gpu/drm/i915/display/intel_bw.c | 87 -

[Intel-gfx] [PATCH v3 7/8] drm/i915/mtl: Add support for PM DEMAND

From: Mika Kahola Display14 introduces a new way to instruct the PUnit with power and bandwidth requirements of DE. Add the functionality to program the registers and handle waits using interrupts. The current wait time for timeouts is programmed for 10 msecs to factor in the worst case scenarios

[Intel-gfx] [PATCH v3 8/8] drm/i915/display: provision to suppress drm_warn in intel_get_crtc_new_encoder

While configuring pmdemand parameters, there could be intel_get_crtc_new_encoder call where encoders could be 0. To avoid invoking drm_warn in such cases, use a parameter to indicate drm_warn should be suppressed. v2: checkpatch warning fixes Signed-off-by: Vinod Govindapillai --- drivers/gpu/d

Re: [Intel-gfx] [PATCH v3 2/8] drm/i915: update the QGV point frequency calculations

On Thu, Apr 27, 2023 at 06:00:10PM +0300, Vinod Govindapillai wrote: > >From MTL onwwards, pcode locks the QGV point based on peak BW of > the intended QGV point passed by the driver. So the peak BW > calculation must match the value expected by the pcode. Update > the calculations as per the Bspec

Re: [Intel-gfx] [PATCH 13/13] drm/i915/mtl: Enable TC ports

On 4/20/23 05:40, Mika Kahola wrote: Finally, we can enable TC ports for Meteorlake. Signed-off-by: Mika Kahola --- drivers/gpu/drm/i915/display/intel_display.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/g

Re: [Intel-gfx] [PATCH v10 00/10] drm/hdcp: Pull HDCP auth/exchange/check into helpers

On 26/04/2023 19:29, Doug Anderson wrote: Hi, On Wed, Apr 19, 2023 at 8:43 AM Mark Yacoub wrote: Hi all, This is v10 of the HDCP patches. The patches are authored by Sean Paul. I rebased and addressed the review comments in v6-v10. Main change in v10 is handling the kernel test bot warnings.

Re: [Intel-gfx] [PATCH v2 0/5] drm/i915: Allow user to set cache at BO creation

> On 26/04/2023 16:41, Yang, Fei wrote: >>> On 26/04/2023 07:24, fei.y...@intel.com wrote: From: Fei Yang The first three patches in this series are taken from https://patchwork.freedesktop.org/series/116868/ These patches are included here because the last patch has

Re: [Intel-gfx] [PATCH 10/13] drm/i915/mtl: Power up TCSS

On Thu, Apr 20, 2023 at 03:40:47PM +0300, Mika Kahola wrote: > Add register writes to enable powering up Type-C subsystem i.e. TCSS. > For MeteorLake we need to request TCSS to power up and check the TCSS > power state after 500 us. > > In addition, for PICA we need to set/clear the Type-C PHY own

Re: [Intel-gfx] [PATCH 11/13] drm/i915/mtl: TypeC HPD live status query

On Thu, Apr 20, 2023 at 03:40:48PM +0300, Mika Kahola wrote: > From: Imre Deak > > The HPD live status for MTL has to be read from different set of > registers. MTL deserves a new function for this purpose > and cannot reuse the existing HPD live status detection > Reviewed-by: Matt Atwood > S

[Intel-gfx] ✗ Fi.CI.BUILD: failure for Expose RPS thresholds in sysfs

== Series Details == Series: Expose RPS thresholds in sysfs URL : https://patchwork.freedesktop.org/series/117054/ State : failure == Summary == Error: make failed CALLscripts/checksyscalls.sh DESCEND objtool INSTALL libsubcmd_headers CC [M] drivers/gpu/drm/i915/gt/intel_rps.o In

Re: [Intel-gfx] [PATCH 12/13] drm/i915/mtl: Pin assignment for TypeC

On Thu, Apr 20, 2023 at 03:40:49PM +0300, Mika Kahola wrote: > From: Anusha Srivatsa > > Unlike previous platforms that used PORT_TX_DFLEXDPSP > for max_lane calculation, MTL uses only PORT_TX_DFLEXPA1 > from which the max_lanes has to be calculated. > > Bspec: 50235, 65380 > Reviewed-by: Matt

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 3/4] i915_pm_freq_api: Add some basic SLPC igt tests

Hi Ashutosh, On 2023-04-26 at 13:40:28 -0700, Dixit, Ashutosh wrote: > On Tue, 25 Apr 2023 09:24:04 -0700, Vinay Belgaumkar wrote: > > > > diff --git a/tests/i915/i915_pm_freq_api.c b/tests/i915/i915_pm_freq_api.c > > new file mode 100644 > > index ..17adacbc > > --- /dev/null > > +++ b/te

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 3/4] i915_pm_freq_api: Add some basic SLPC igt tests

On Thu, 27 Apr 2023 09:24:58 -0700, Kamil Konieczny wrote: > > Hi Ashutosh, > > On 2023-04-26 at 13:40:28 -0700, Dixit, Ashutosh wrote: > > On Tue, 25 Apr 2023 09:24:04 -0700, Vinay Belgaumkar wrote: > > > > > > diff --git a/tests/i915/i915_pm_freq_api.c b/tests/i915/i915_pm_freq_api.c > > > new fi

Re: [Intel-gfx] [PATCH 02/13] drm/i915/mtl: C20 HW readout

> -Original Message- > From: Kahola, Mika > Sent: Wednesday, April 26, 2023 4:43 AM > To: Sripada, Radhakrishna > Cc: intel-gfx@lists.freedesktop.org > Subject: RE: [Intel-gfx] [PATCH 02/13] drm/i915/mtl: C20 HW readout > > > -Original Message- > > From: Sripada, Radhakrishna

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dsi: Use unconditional msleep() instead of intel_dsi_msleep() (rev2)

== Series Details == Series: drm/i915/dsi: Use unconditional msleep() instead of intel_dsi_msleep() (rev2) URL : https://patchwork.freedesktop.org/series/116947/ State : success == Summary == CI Bug Log - changes from CI_DRM_13071 -> Patchwork_116947v2

Re: [Intel-gfx] [PATCH] drm/i915/guc: Fix error capture for virtual engines

On Fri, 2023-04-14 at 17:27 -0700, john.c.harri...@intel.com wrote: > From: John Harrison > > GuC based register dumps in error capture logs were basically broken > for virtual engines. This can be seen in igt@gem_exec_balancer@hang: > [IGT] gem_exec_balancer: starting subtest hang > [drm] GP

Re: [Intel-gfx] [PATCH v8 6/8] drm/i915/uapi/pxp: Add a GET_PARAM for PXP

On Wed, 2023-04-26 at 15:35 -0700, Justen, Jordan L wrote: > On 2023-04-26 11:17:16, Teres Alexis, Alan Previn wrote: alan:snip > > > - Jordan still wants the extension query > Yes, I do, but so far it doesn't appear that any kernel devs think > it's a reasonable request. > > As I read through y

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Introduce sink_format and other fixes

== Series Details == Series: Introduce sink_format and other fixes URL : https://patchwork.freedesktop.org/series/117056/ 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: failure for Introduce sink_format and other fixes

== Series Details == Series: Introduce sink_format and other fixes URL : https://patchwork.freedesktop.org/series/117056/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13071 -> Patchwork_117056v1 Summary --- **FAILUR

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for mtl: add support for pmdemand (rev4)

== Series Details == Series: mtl: add support for pmdemand (rev4) URL : https://patchwork.freedesktop.org/series/116949/ State : warning == Summary == Error: dim checkpatch failed 874300201d54 drm/i915: fix the derating percentage for MTL 0351498e12a8 drm/i915: update the QGV point frequency c

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for mtl: add support for pmdemand (rev4)

== Series Details == Series: mtl: add support for pmdemand (rev4) URL : https://patchwork.freedesktop.org/series/116949/ 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 v8 6/8] drm/i915/uapi/pxp: Add a GET_PARAM for PXP

(fixed email addresses again - why is my Evolution client deteorating??) On Thu, 2023-04-27 at 17:18 +, Teres Alexis, Alan Previn wrote: > On Wed, 2023-04-26 at 15:35 -0700, Justen, Jordan L wrote: > > On 2023-04-26 11:17:16, Teres Alexis, Alan Previn wrote: > alan:snip > > Can you tell that p

[Intel-gfx] ✓ Fi.CI.BAT: success for mtl: add support for pmdemand (rev4)

== Series Details == Series: mtl: add support for pmdemand (rev4) URL : https://patchwork.freedesktop.org/series/116949/ State : success == Summary == CI Bug Log - changes from CI_DRM_13071 -> Patchwork_116949v4 Summary --- **SUCCESS

Re: [Intel-gfx] [PATCH v8 6/8] drm/i915/uapi/pxp: Add a GET_PARAM for PXP

On 27/04/2023 21:19, Teres Alexis, Alan Previn wrote: (fixed email addresses again - why is my Evolution client deteorating??) On Thu, 2023-04-27 at 17:18 +, Teres Alexis, Alan Previn wrote: On Wed, 2023-04-26 at 15:35 -0700, Justen, Jordan L wrote: On 2023-04-26 11:17:16, Teres Alexis, Al

Re: [Intel-gfx] [PATCH v4 2/9] vfio-iommufd: Create iommufd_access for noiommu devices

On Thu, 27 Apr 2023 06:59:17 + "Liu, Yi L" wrote: > > From: Tian, Kevin > > Sent: Thursday, April 27, 2023 2:39 PM > > > > > From: Liu, Yi L > > > Sent: Wednesday, April 26, 2023 10:54 PM > > > @@ -121,7 +128,8 @@ static void vfio_emulated_unmap(void *data, > > > unsigned long iova, > >

Re: [Intel-gfx] [PATCH v4 1/9] vfio: Determine noiommu in vfio_device registration

On Thu, 27 Apr 2023 07:05:37 + "Liu, Yi L" wrote: > > From: Tian, Kevin > > Sent: Thursday, April 27, 2023 2:36 PM > > > > > From: Liu, Yi L > > > Sent: Wednesday, April 26, 2023 10:54 PM > > > > > > -static inline bool vfio_device_is_noiommu(struct vfio_device *vdev) > > > +static inlin

Re: [Intel-gfx] [PATCH v4 5/9] vfio: Mark cdev usage in vfio_device

On Wed, 26 Apr 2023 07:54:15 -0700 Yi Liu wrote: > Use it to differentiate whether to report group_id or dev_id in revised > VFIO_DEVICE_GET_PCI_HOT_RESET_INFO ioctl. Though it is not set at this > moment introducing it now allows us to get hot reset ready for cdev. > > Signed-off-by: Yi Liu >

Re: [Intel-gfx] [PATCH 1/2] i915/pmu: Add support for total context runtime for GuC back-end

On Wed, Apr 26, 2023 at 05:51:24PM -0700, Dixit, Ashutosh wrote: On Wed, 26 Apr 2023 17:11:27 -0700, Umesh Nerlige Ramappa wrote: Hi Umesh, On Mon, Apr 24, 2023 at 10:41:41AM -0700, Dixit, Ashutosh wrote: > On Tue, 04 Apr 2023 17:14:32 -0700, Umesh Nerlige Ramappa wrote: > >> GPU accumulate

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Hugepage manager and test for MTL (rev3)

== Series Details == Series: drm/i915: Hugepage manager and test for MTL (rev3) URL : https://patchwork.freedesktop.org/series/116995/ State : success == Summary == CI Bug Log - changes from CI_DRM_13071 -> Patchwork_116995v3 Summary --

Re: [Intel-gfx] [PATCH v4 8/9] vfio/pci: Extend VFIO_DEVICE_GET_PCI_HOT_RESET_INFO for vfio device cdev

On Wed, 26 Apr 2023 07:54:18 -0700 Yi Liu wrote: > This makes VFIO_DEVICE_GET_PCI_HOT_RESET_INFO ioctl to use the bound > iommufd of the cdev device to check the ownership of the other affected > devices and set a flag to tell user if the cdev device is resettable > with a zero-length fd array. >

Re: [Intel-gfx] [PATCH v4 8/9] vfio/pci: Extend VFIO_DEVICE_GET_PCI_HOT_RESET_INFO for vfio device cdev

On Thu, 27 Apr 2023 14:04:05 -0600 Alex Williamson wrote: > On Wed, 26 Apr 2023 07:54:18 -0700 > Yi Liu wrote: > > > This makes VFIO_DEVICE_GET_PCI_HOT_RESET_INFO ioctl to use the bound > > iommufd of the cdev device to check the ownership of the other affected > > devices and set a flag to tel

Re: [Intel-gfx] [PATCH v3 7/8] drm/i915/mtl: Add support for PM DEMAND

Quoting Vinod Govindapillai (2023-04-27 12:00:15) >From: Mika Kahola > >Display14 introduces a new way to instruct the PUnit with >power and bandwidth requirements of DE. Add the functionality >to program the registers and handle waits using interrupts. >The current wait time for timeouts is progr

Re: [Intel-gfx] [PATCH v4 9/9] vfio/pci: Allow passing zero-length fd array in VFIO_DEVICE_PCI_HOT_RESET

On Wed, 26 Apr 2023 07:54:19 -0700 Yi Liu wrote: > This is the way user to invoke hot-reset for the devices opened by cdev > interface. User should check the flag VFIO_PCI_HOT_RESET_FLAG_RESETTABLE > in the output of VFIO_DEVICE_GET_PCI_HOT_RESET_INFO ioctl before doing > hot-reset for cdev devic

[Intel-gfx] [PATCH 2/2] drm/i915/fdinfo: Enable fdinfo for GuC backends

Enable fdinfo for GuC based platforms with the exception that long running contexts will not provide reliable busyness data unless they switch out at some reasonable point in time. Link: https://gitlab.freedesktop.org/drm/intel/issues/8303 Signed-off-by: Umesh Nerlige Ramappa --- drivers/gpu/drm

[Intel-gfx] [PATCH 0/2] fdinfo: Enable some support for GuC based client busyness

Export context runtime into the fdinfo framework to enable per client busyness for GuC back-end. v2: Fix zeroed busyness values v3: Include review comments from Ashutosh Signed-off-by: Umesh Nerlige Ramappa Umesh Nerlige Ramappa (2): i915/pmu: Add support for total context runtime for GuC bac

[Intel-gfx] [PATCH 1/2] i915/pmu: Add support for total context runtime for GuC back-end

GPU accumulates the context runtime in a 32 bit counter - CTX_TIMESTAMP in the context image. This value is saved/restored on context switches. KMD accumulates these values into a 64 bit counter taking care of any overflows as needed. This count provides the basis for client specific busyness in th

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dsi: Use unconditional msleep() instead of intel_dsi_msleep() (rev2)

== Series Details == Series: drm/i915/dsi: Use unconditional msleep() instead of intel_dsi_msleep() (rev2) URL : https://patchwork.freedesktop.org/series/116947/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13071_full -> Patchwork_116947v2_full ==

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v6,1/2] drm/i915/guc/slpc: Provide sysfs for efficient freq (rev3)

== Series Details == Series: series starting with [v6,1/2] drm/i915/guc/slpc: Provide sysfs for efficient freq (rev3) URL : https://patchwork.freedesktop.org/series/116957/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be check

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v6,1/2] drm/i915/guc/slpc: Provide sysfs for efficient freq (rev3)

== Series Details == Series: series starting with [v6,1/2] drm/i915/guc/slpc: Provide sysfs for efficient freq (rev3) URL : https://patchwork.freedesktop.org/series/116957/ State : success == Summary == CI Bug Log - changes from CI_DRM_13071 -> Patchwork_116957v3 =

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for fdinfo: Enable some support for GuC based client busyness (rev2)

== Series Details == Series: fdinfo: Enable some support for GuC based client busyness (rev2) URL : https://patchwork.freedesktop.org/series/116120/ 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 v9 4/8] drm/i915/pxp: Add GSC-CS backend to send GSC fw messages

Add GSC engine based method for sending PXP firmware packets to the GSC firmware for MTL (and future) products. Use the newly added helpers to populate the GSC-CS memory header and send the message packet to the FW by dispatching the GSC_HECI_CMD_PKT instruction on the GSC engine. We use non-priv

[Intel-gfx] [PATCH v9 0/8] drm/i915/pxp: Add MTL PXP Support

This series enables PXP on MTL. On ADL/TGL platforms, we rely on the mei driver via the i915-mei PXP component interface to establish a connection to the security firmware via the HECI device interface. That interface is used to create and teardown the PXP ARB session. PXP ARB session is created wh

[Intel-gfx] [PATCH v9 6/8] drm/i915/uapi/pxp: Add a GET_PARAM for PXP

Because of the additional firmware, component-driver and initialization depedencies required on MTL platform before a PXP context can be created, UMD calling for PXP creation as a way to get-caps can take a long time. An actual real world customer stack has seen this happen in the 4-to-8 second ran

[Intel-gfx] [PATCH v9 3/8] drm/i915/pxp: Add MTL helpers to submit Heci-Cmd-Packet to GSC

Add helper functions into a new file for heci-packet-submission. The helpers will handle generating the MTL GSC-CS Memory-Header and submission of the Heci-Cmd-Packet instructions to the engine. NOTE1: These common functions for heci-packet-submission will be used by different i915 callers: 1

[Intel-gfx] [PATCH v9 1/8] drm/i915/pxp: Add GSC-CS back-end resource init and cleanup

For MTL, the PXP back-end transport uses the GSC engine to submit HECI packets through the HW to the GSC firmware for PXP arb session management. This submission uses a non-priveleged batch buffer, a buffer for the command packet and of course a context targeting the GSC-CS. Thus for MTL, we need

[Intel-gfx] [PATCH v9 2/8] drm/i915/pxp: Add MTL hw-plumbing enabling for KCR operation

Add MTL hw-plumbing enabling for KCR operation under PXP which includes: 1. Updating 'pick-gt' to get the media tile for KCR interrupt handling 2. Adding MTL's KCR registers for PXP operation (init, status-checking, etc.). While doing #2, lets create a separate registers header file for PXP

[Intel-gfx] [PATCH v9 7/8] drm/i915/pxp: On MTL, KCR enabling doesn't wait on tee component

On legacy platforms, KCR HW enabling is done at the time the mei component interface is bound. It's also disabled during unbind. However, for MTL onwards, we don't depend on a tee component to start sending GSC-CS firmware messages. Thus, immediately enable (or disable) KCR HW on PXP's init, fini

[Intel-gfx] [PATCH v9 8/8] drm/i915/pxp: Enable PXP with MTL-GSC-CS

Enable PXP with MTL-GSC-CS: add the has_pxp into device info and increase the debugfs teardown timeouts to align with new GSC-CS + firmware specs. Now that we have 3 places that are selecting pxp timeouts based on tee vs gsccs back-end, let's add a helper. Signed-off-by: Alan Previn Reviewed-by:

[Intel-gfx] [PATCH v9 5/8] drm/i915/pxp: Add ARB session creation and cleanup

Add MTL's function for ARB session creation using PXP firmware version 4.3 ABI structure format. While relooking at the ARB session creation flow in intel_pxp_start, let's address missing UAPI documentation. Without actually changing backward compatible behavior, update i915's drm-uapi comments th

[Intel-gfx] ✓ Fi.CI.BAT: success for fdinfo: Enable some support for GuC based client busyness (rev2)

== Series Details == Series: fdinfo: Enable some support for GuC based client busyness (rev2) URL : https://patchwork.freedesktop.org/series/116120/ State : success == Summary == CI Bug Log - changes from CI_DRM_13071 -> Patchwork_116120v2

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/pxp: Add MTL PXP Support (rev9)

== Series Details == Series: drm/i915/pxp: Add MTL PXP Support (rev9) URL : https://patchwork.freedesktop.org/series/112647/ State : warning == Summary == Error: dim checkpatch failed e93c6f73e145 drm/i915/pxp: Add GSC-CS back-end resource init and cleanup Traceback (most recent call last):

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/pxp: Add MTL PXP Support (rev9)

== Series Details == Series: drm/i915/pxp: Add MTL PXP Support (rev9) URL : https://patchwork.freedesktop.org/series/112647/ 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 v9 3/8] drm/i915/pxp: Add MTL helpers to submit Heci-Cmd-Packet to GSC

On Thu, 2023-04-27 at 16:48 -0700, Teres Alexis, Alan Previn wrote: > Add helper functions into a new file for heci-packet-submission. > The helpers will handle generating the MTL GSC-CS Memory-Header > and submission of the Heci-Cmd-Packet instructions to the engine. > > alan: I accidentally for

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/pxp: Add MTL PXP Support (rev9)

== Series Details == Series: drm/i915/pxp: Add MTL PXP Support (rev9) URL : https://patchwork.freedesktop.org/series/112647/ State : success == Summary == CI Bug Log - changes from CI_DRM_13071 -> Patchwork_112647v9 Summary --- **SUC

[Intel-gfx] ✗ Fi.CI.IGT: failure for mtl: add support for pmdemand (rev4)

== Series Details == Series: mtl: add support for pmdemand (rev4) URL : https://patchwork.freedesktop.org/series/116949/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13071_full -> Patchwork_116949v4_full Summary ---

[Intel-gfx] [CI] PR for HuC v8.4.5 for MTL

The following changes since commit fab149657d8d029c06179dd006b59b2f3594f916: Group all Conexant V4L devices together (2023-04-27 09:15:55 -0400) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-firmware mtl_huc_8.4.5 for you to fetch changes up to 2cae62ee3cc08a

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Hugepage manager and test for MTL (rev3)

== Series Details == Series: drm/i915: Hugepage manager and test for MTL (rev3) URL : https://patchwork.freedesktop.org/series/116995/ State : success == Summary == CI Bug Log - changes from CI_DRM_13071_full -> Patchwork_116995v3_full Summ

[Intel-gfx] [PATCH 1/8] DO NOT REVIEW: drm/i915: Add support for MTL GSC SW Proxy

This is a squash of the GSC proxy series, which is being reviewed separately [1]. It's being included here because some of the patches in this series depend on it. This is not a functional dependencies, the patches just touch the same code and the proxy patches are planned to be merged first, so it

[Intel-gfx] [PATCH 2/8] drm/i915/uc: perma-pin firmwares

Now that each FW has its own reserved area, we can keep them always pinned and skip the pin/unpin dance on reset. This will make things easier for the 2-step HuC authentication, which requires the FW to be pinned in GGTT after the xfer is completed. Given that we use dummy vmas for the pinning, we

[Intel-gfx] [PATCH 3/8] drm/i915/huc: Parse the GSC-enabled HuC binary

The new binaries that support the 2-step authentication have contain the legacy-style binary, which we can use for loading the HuC via DMA. To find out where this is located in the image, we need to parse the meu manifest of the GSC binary. The manifest consist of a partition header followed by ent

  1   2   >