Re: [Intel-gfx] [PATCH v2 09/20] drm/i915: Remove references to struct drm_device.pdev

ping for a review of the i915 patches Am 01.12.20 um 11:35 schrieb Thomas Zimmermann: Using struct drm_device.pdev is deprecated. Convert i915 to struct drm_device.dev. No functional changes. v2: * move gt/ and gvt/ changes into separate patches Signed-off-by: Thomas Zimmermann Cc:

[Intel-gfx] [PATCH v4 16/16] drm/i915: Enable PCON configuration for Color Conversion for TGL

This patch enables PCON configuration for color space conversion for TGL+ platfrom. This will help in supporting 8k@60 YUV420 modes common in HDMI 8k panels, through a capable PCON. Also allow 8k@60 YUV420 modes, only if PCON claims to support the color space conversion. Signed-off-by: Ankit

[Intel-gfx] [PATCH v4 15/16] drm/i915: Let PCON convert from RGB to YUV if it can

If PCON has capability to convert RGB->YUV colorspace and also to 444->420 downsampling then for any YUV420 only mode, we can let the PCON do all the conversion. Signed-off-by: Ankit Nautiyal --- .../drm/i915/display/intel_display_types.h| 1 + drivers/gpu/drm/i915/display/intel_dp.c

[Intel-gfx] [PATCH v4 14/16] drm/i915/display: Configure PCON for DSC1.1 to DSC1.2 encoding

When a source supporting DSC1.1 is connected to DSC1.2 HDMI2.1 sink via DP HDMI2.1 PCON, the PCON can be configured to decode the DSC1.1 compressed stream and encode to DSC1.2. It then sends the DSC1.2 compressed stream to the HDMI2.1 sink. This patch configures the PCON for DSC1.1 to DSC1.2

[Intel-gfx] [PATCH v4 13/16] drm/i915: Add helper functions for calculating DSC parameters for HDMI2.1

The DP-HDMI2.1 PCON spec provides way for a source to set PPS parameters: slice height, slice width and bits_per_pixel, based on the HDMI2.1 sink capabilities. The DSC encoder of the PCON will respect these parameters, while preparing the 128 byte PPS. This patch adds helper functions to

[Intel-gfx] [PATCH v4 12/16] drm/i915: Read DSC capabilities of the HDMI2.1 PCON encoder

This patch adds support to read and store the DSC capabilities of the HDMI2.1 PCon encoder. It also adds a new field to store these caps, The caps are read during dfp update and can later be used to get the PPS parameters for PCON-HDMI2.1 sink pair. Which inturn will be used to take a call to

[Intel-gfx] [PATCH v4 10/16] drm/i915: Check for FRL training before DP Link training

This patch calls functions to check FRL training requirements for an HDMI2.1 sink, when connected through PCON. The call is made before the DP link training. In case FRL is not required or failure during FRL training, the TMDS mode is selected for the pcon. v2: moved check_frl_training() just

[Intel-gfx] [PATCH v4 11/16] drm/i915: Add support for enabling link status and recovery

From: Swati Sharma In this patch enables support for detecting link failures between PCON and HDMI sink in i915 driver. HDMI link loss indication to upstream DP source is indicated via IRQ_HPD. This is followed by reading of HDMI link configuration status (HDMI_TX_LINK_ACTIVE_STATUS). If the

[Intel-gfx] [PATCH v4 09/16] drm/i915: Add support for starting FRL training for HDMI2.1 via PCON

This patch adds functions to start FRL training for an HDMI2.1 sink, connected via a PCON as a DP branch device. This patch also adds a new structure for storing frl training related data, when FRL training is completed. v2: As suggested by Uma Shankar: -renamed couple of variables for better

[Intel-gfx] [PATCH v4 08/16] drm/i915: Capture max frl rate for PCON in dfp cap structure

HDMI2.1 PCON advertises Max FRL bandwidth supported by the PCON and by the sink. This patch captures these in dfp cap structure in intel_dp and uses these to prune connector modes that cannot be supported by the PCON and sink FRL bandwidth. v2: Addressed review comments from Uma Shankar:

[Intel-gfx] [PATCH v4 07/16] drm/dp_helper: Add helpers to configure PCONs RGB-YCbCr Conversion

DP Specification for DP2.0 to HDMI2.1 Pcon specifies support for conversion of colorspace from RGB to YCbCr. https://groups.vesa.org/wg/DP/document/previewpdf/15651 This patch adds the relavant registers and helper functions to get the capability and set the color conversion bits for rgb->ycbcr

[Intel-gfx] [PATCH v4 06/16] drm/dp_helper: Add support for Configuring DSC for HDMI2.1 Pcon

This patch adds registers for getting DSC encoder capability for a HDMI2.1 PCon. It also addes helper functions to configure DSC between the PCON and HDMI2.1 sink. v2: Corrected offset for DSC encoder bpc and minor changes. Also added helper functions for getting pcon dsc encoder capabilities as

[Intel-gfx] [PATCH v4 05/16] drm/dp_helper: Add support for link failure detection

From: Swati Sharma There are specific DPCDs defined for detecting link failures between the PCON and HDMI sink and check the link status. In case of link failure, PCON will communicate the same using an IRQ_HPD to source. HDMI sink would have indicated the same to PCON using SCDC interrupt

[Intel-gfx] [PATCH v4 04/16] drm/dp_helper: Add Helpers for FRL Link Training support for DP-HDMI2.1 PCON

This patch adds support for configuring a PCON device, connected as a DP branched device to enable FRL Link training with a HDMI2.1 + sink. v2: Fixed typos and addressed other review comments from Uma Shankar. -changed the commit message for better clarity (Uma Shankar) -removed unnecessary

[Intel-gfx] [PATCH v4 03/16] drm/edid: Parse DSC1.2 cap fields from HFVSDB block

This patch parses HFVSDB fields for DSC1.2 capabilities of an HDMI2.1 sink. These fields are required by a source to understand the DSC capability of the sink, to set appropriate PPS parameters, before transmitting compressed data stream. v2: Addressed following issues as suggested by Uma

[Intel-gfx] [PATCH v4 02/16] drm/edid: Parse MAX_FRL field from HFVSDB block

From: Swati Sharma This patch parses MAX_FRL field to get the MAX rate in Gbps that the HDMI 2.1 panel can support in FRL mode. Source need this field to determine the optimal rate between the source and sink during FRL training. v2: Fixed minor bugs, and removed extra wrapper function (Uma

[Intel-gfx] [PATCH v4 01/16] drm/edid: Add additional HFVSDB fields for HDMI2.1

From: Swati Sharma The HDMI2.1 extends HFVSDB (HDMI Forum Vendor Specific Data block) to have fields related to newly defined methods of FRL (Fixed Rate Link) levels, number of lanes supported, DSC Color bit depth, VRR min/max, FVA (Fast Vactive), ALLM etc. This patch adds the new HFVSDB fields

[Intel-gfx] [PATCH v4 00/16] Add support for DP-HDMI2.1 PCON

This patch series attempts to add support for a DP-HDMI2.1 Protocol Convertor. The VESA spec for the HDMI2.1 PCON are proposed in Errata E5 to DisplayPort_v2.0: https://vesa.org/join-vesamemberships/member-downloads/?action=stamp=42299 The details are mentioned in: VESA DP-to-HDMI PCON

Re: [Intel-gfx] [RFC-v1 02/16] drm/i915/pxp: Enable PXP irq worker and callback stub

Hi Joonas, All the modification will be included in rev2. Thanks! > We should take >pxp as the first parameter and keep a tight scope. DONE > Again, we should be taking intel_pxp as parameter to tighten the scope. DONE >Instead of writing to register that is indicated to be "reserved" (RSVD),

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [01/20] drm/i915/gem: Drop false !i915_vma_is_closed assertion

== Series Details == Series: series starting with [01/20] drm/i915/gem: Drop false !i915_vma_is_closed assertion URL : https://patchwork.freedesktop.org/series/84649/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9456_full -> Patchwork_19076_full

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915: Fix ICL MG PHY vswing handling

== Series Details == Series: series starting with [1/2] drm/i915: Fix ICL MG PHY vswing handling URL : https://patchwork.freedesktop.org/series/84651/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9456 -> Patchwork_19077

[Intel-gfx] [PATCH 2/2] drm/i915: Unify the sanity checks for the buf trans tables

From: Ville Syrjälä Get rid of the "I like my random new style best" approach and unify the handling for the DDI buf trans table sanity checks once again. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_ddi.c | 23 ++- 1 file changed, 10 insertions(+),

[Intel-gfx] [PATCH 1/2] drm/i915: Fix ICL MG PHY vswing handling

From: Ville Syrjälä The MH PHY vswing table does have all the entries these days. Get rid of the old hacks in the code which claim otherwise. This hack was totally bogus anyway. The correct way to handle the lack of those two entries would have been to declare our max vswing and pre-emph to

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/20] drm/i915/gem: Drop false !i915_vma_is_closed assertion

== Series Details == Series: series starting with [01/20] drm/i915/gem: Drop false !i915_vma_is_closed assertion URL : https://patchwork.freedesktop.org/series/84649/ State : success == Summary == CI Bug Log - changes from CI_DRM_9456 -> Patchwork_19076

Re: [Intel-gfx] [PATCH v3 3/4] tpm_tis: Disable interrupts if interrupt storm detected

On Mon, 2020-12-07 at 15:28 -0400, Jason Gunthorpe wrote: > On Sun, Dec 06, 2020 at 08:26:16PM +0100, Thomas Gleixner wrote: > > Just as a side note. I was looking at tpm_tis_probe_irq_single() > > and that function is leaking the interrupt request if any of the > > checks afterwards fails, except

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [01/20] drm/i915/gem: Drop false !i915_vma_is_closed assertion

== Series Details == Series: series starting with [01/20] drm/i915/gem: Drop false !i915_vma_is_closed assertion URL : https://patchwork.freedesktop.org/series/84649/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be

[Intel-gfx] [PATCH 15/20] drm/i915/gt: Wrap intel_timeline.has_initial_breadcrumb

In preparation for removing the has_initial_breadcrumb field, add a helper function for the existing callers. Signed-off-by: Chris Wilson Reviewed-by: Mika Kuoppala --- drivers/gpu/drm/i915/gt/intel_lrc.c | 2 +- drivers/gpu/drm/i915/gt/intel_ring_submission.c | 4 ++--

[Intel-gfx] [PATCH 19/20] drm/i915/selftests: Exercise relative timeline modes

A quick test to verify that the backend accepts each type of timeline and can use them to track and control request emission. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gt/selftest_timeline.c | 93 + 1 file changed, 93 insertions(+) diff --git

[Intel-gfx] [PATCH 01/20] drm/i915/gem: Drop false !i915_vma_is_closed assertion

Closed vma are protected by the GT wakeref held as we lookup the vma, so we know that the vma will not be freed as we process it for the execbuf. Instead we expect to catch the closed status of the context, and simply allow the close-race on an individual vma to be washed away. Longer term, the

[Intel-gfx] [PATCH 02/20] drm/i915/gt: Replace direct submit with direct call to tasklet

Rather than having special case code for opportunistically calling process_csb() and performing a direct submit while holding the engine spinlock for submitting the request, simply call the tasklet directly. This allows us to retain the direct submission path, including the CS draining to allow

[Intel-gfx] [PATCH 12/20] drm/i915/gt: Track the overall awake/busy time

Since we wake the GT up before executing a request, and go to sleep as soon as it is retired, the GT wake time not only represents how long the device is powered up, but also provides a summary, albeit an overestimate, of the device runtime (i.e. the rc0 time to compare against rc6 time). v2:

[Intel-gfx] [PATCH 18/20] drm/i915/gt: Use indices for writing into relative timelines

Relative timelines are relative to either the global or per-process HWSP, and so we can replace the absolute addressing with store-index variants for position invariance. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gt/intel_lrc.c | 114 ---

[Intel-gfx] [PATCH 07/20] drm/i915/gt: Shrink the critical section for irq signaling

Let's only wait for the list iterator when decoupling the virtual breadcrumb, as the signaling of all the requests may take a long time, during which we do not want to keep the tasklet spinning. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 2 ++

[Intel-gfx] [PATCH 09/20] drm/i915/gt: Simplify virtual engine handling for execlists_hold()

Now that the tasklet completely controls scheduling of the requests, and we postpone scheduling out the old requests, we can keep a hanging virtual request bound to the engine on which it hung, and remove it from te queue. On release, it will be returned to the same engine and remain in its queue

[Intel-gfx] [PATCH 06/20] drm/i915/gt: Remove virtual breadcrumb before transfer

The issue with stale virtual breadcrumbs remain. Now we have the problem that if the irq-signaler is still referencing the stale breadcrumb as we transfer it to a new sibling, the list becomes spaghetti. This is a very small window, but that doesn't stop it being hit infrequently. To prevent the

[Intel-gfx] [PATCH 05/20] drm/i915/gt: Defer schedule_out until after the next dequeue

Inside schedule_out, we do extra work upon idling the context, such as updating the runtime, kicking off retires, kicking virtual engines. However, if we are in a series of processing single requests per contexts, we may find ourselves scheduling out the context, only to immediately schedule it

[Intel-gfx] [PATCH 03/20] drm/i915/gt: Use virtual_engine during execlists_dequeue

Rather than going back and forth between the rb_node entry and the virtual_engine type, store the ve local and reuse it. As the container_of conversion from rb_node to virtual_engine requires a variable offset, performing that conversion just once shaves off a bit of code. v2: Keep a single

[Intel-gfx] [PATCH 04/20] drm/i915/gt: Decouple inflight virtual engines

Once a virtual engine has been bound to a sibling, it will remain bound until we finally schedule out the last active request. We can not rebind the context to a new sibling while it is inflight as the context save will conflict, hence we wait. As we cannot then use any other sibliing while the

[Intel-gfx] [PATCH 16/20] drm/i915/gt: Track timeline GGTT offset separately from subpage offset

Currently we know that the timeline status page is at most a page in size, and so we can preserve the lower 12bits of the offset when relocating the status page in the GGTT. If we want to use a larger object, such as the context state, we may not necessarily use a position within the first page

[Intel-gfx] [PATCH 17/20] drm/i915/gt: Add timeline "mode"

Explicitly differentiate between the absolute and relative timelines, and the global HWSP and ppHWSP relative offsets. When using a timeline that is relative to a known status page, we can replace the absolute addressing in the commands with indexed variants. Signed-off-by: Chris Wilson ---

[Intel-gfx] [PATCH 14/20] drm/i915/gt: Track all timelines created using the HWSP

We assume that the contents of the HWSP are lost across suspend, and so upon resume we must restore critical values such as the timeline seqno. Keep track of every timeline allocated that uses the HWSP as its storage and so we can then reset all seqno values by walking that list. Signed-off-by:

[Intel-gfx] [PATCH 11/20] drm/i915/gem: Drop free_work for GEM contexts

The free_list and worker was introduced in commit 5f09a9c8ab6b ("drm/i915: Allow contexts to be unreferenced locklessly"), but subsequently made redundant by the removal of the last sleeping lock in commit 2935ed5339c4 ("drm/i915: Remove logical HW ID"). As we can now free the GEM context

[Intel-gfx] [PATCH 13/20] drm/i915: Encode fence specific waitqueue behaviour into the wait.flags

Use the wait_queue_entry.flags to denote the special fence behaviour (flattening continuations along fence chains, and for propagating errors) rather than trying to detect ordinary waiters by their functions. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_sw_fence.c | 25

[Intel-gfx] [PATCH 08/20] drm/i915/gt: Resubmit the virtual engine on schedule-out

Having recognised that we do not change the sibling until we schedule out, we can then defer the decision to resubmit the virtual engine from the unwind of the active queue to scheduling out of the virtual context. This improves our resilence in virtual engine scheduling, and should eliminate the

[Intel-gfx] [PATCH 10/20] drm/i915/gt: ce->inflight updates are now serialised

Since schedule-in and schedule-out are now both always under the tasklet bitlock, we can reduce the individual atomic operations to simple instructions and worry less. This notably eliminates the race observed with intel_context_inflight in __engine_unpark(). Closes:

[Intel-gfx] [PATCH 20/20] drm/i915/gt: Use ppHWSP for unshared non-semaphore related timelines

When we are not using semaphores with a context/engine, we can simply reuse the same seqno location across wraps, but we still require each timeline to have its own address. For LRC submission, each context is prefixed by a per-process HWSP, which provides us with a unique location for each

Re: [Intel-gfx] [RFC-v1 01/16] drm/i915/pxp: Introduce Intel PXP component

>Repeating the same comment as on previous review, avoid including anything in >i915_drv.h and only include in the relevant files that require to touch the >internals of the structs. I would still need to include i915_drv.h for macro INTEL_GEN(), hopefully it's acceptable. -Original

Re: [Intel-gfx] [RFC-v1 01/16] drm/i915/pxp: Introduce Intel PXP component

Hi Joonas, Thanks for the details review. I have apply the modification according to the review, and will update as rev2. > Description is no more true for single-session only DONE > Same here, needs updating. DONE >Repeating the same comment as on previous review, avoid including anything in

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/selftests: Improve error reporting for igt_mock_max_segment (rev2)

== Series Details == Series: drm/i915/selftests: Improve error reporting for igt_mock_max_segment (rev2) URL : https://patchwork.freedesktop.org/series/84641/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9453_full -> Patchwork_19075_full

Re: [Intel-gfx] [PATCH 03/17] drivers/gpu: Convert to mem*_page()

On Sun, Dec 06 2020 at 22:46, Ira Weiny wrote: > On Fri, Dec 04, 2020 at 11:33:08PM +0100, Thomas Gleixner wrote: >> On Fri, Dec 04 2020 at 08:05, Ira Weiny wrote: >> > So I think I'm going to submit the base patch to Andrew today (with some >> > cleanups per the comments in this thread). >> >>

[Intel-gfx] [PATCH i-g-t 2/2] i915/query: Directly check query results against GETPARAM

Simplify the cross-check by asserting that the existence of an engine in the list matches the existence of the engine as reported by GETPARAM. By using the comparison, we check both directions at once. Signed-off-by: Chris Wilson Cc: Petri Latvala --- tests/i915/i915_query.c | 49

[Intel-gfx] [PATCH i-g-t 1/2] i915/query: Cross-check engine list against execbuf interface

Check that every engine listed can be used in execbuf. Signed-off-by: Chris Wilson Cc: Andi Shyti Cc: Tvrtko Ursulin --- tests/i915/i915_query.c | 35 ++- 1 file changed, 34 insertions(+), 1 deletion(-) diff --git a/tests/i915/i915_query.c

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gt: Fixing the error handling of shmem_pin_map

== Series Details == Series: drm/i915/gt: Fixing the error handling of shmem_pin_map URL : https://patchwork.freedesktop.org/series/84637/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9453_full -> Patchwork_19074_full

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Improve error reporting for igt_mock_max_segment (rev2)

== Series Details == Series: drm/i915/selftests: Improve error reporting for igt_mock_max_segment (rev2) URL : https://patchwork.freedesktop.org/series/84641/ State : success == Summary == CI Bug Log - changes from CI_DRM_9453 -> Patchwork_19075

Re: [Intel-gfx] [PATCH] drm/i915: Disable outputs during unregister

On Fri, Dec 04, 2020 at 04:14:05PM +, Chris Wilson wrote: > Quoting Ville Syrjälä (2020-12-04 16:01:11) > > On Tue, Dec 01, 2020 at 10:38:57PM +, Chris Wilson wrote: > > > Quoting Ville Syrjälä (2020-12-01 16:05:17) > > > > On Fri, Nov 27, 2020 at 10:05:48PM +, Chris Wilson wrote: > >

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Improve error reporting for igt_mock_max_segment

On 2020-12-07 at 13:03:46 +, Chris Wilson wrote: > When we fail to find a single block large enough to require splitting, > report the largest block we did find. > > Signed-off-by: Chris Wilson > Cc: Matthew Auld > Cc: Ramalingam C > --- > .../gpu/drm/i915/selftests/intel_memory_region.c

Re: [Intel-gfx] [RFC PATCH 113/162] drm/i915: Create stolen memory region from local memory

On Fri, 27 Nov 2020, Matthew Auld wrote: > From: CQ Tang > > Add "REGION_STOLEN" device info to dg1, create stolen memory > region from upper portion of local device memory, starting > from DSMBASE. > > The memory region is marked with "is_devmem=true". > > Cc: Joonas Lahtinen > Cc: Matthew

Re: [Intel-gfx] [PATCH i-g-t v2] runner: Don't kill a test on taint if watching timeouts

On Mon, 2020-12-07 at 15:09 +0200, Petri Latvala wrote: > On Fri, Dec 04, 2020 at 08:50:07PM +0100, Janusz Krzysztofik wrote: > > We may still be interested in results of a test even if it has tainted > > the kernel. On the other hand, we need to kill the test on taint if no > > other means of

Re: [Intel-gfx] [PATCH i-g-t v2] runner: Don't kill a test on taint if watching timeouts

On Fri, Dec 04, 2020 at 08:50:07PM +0100, Janusz Krzysztofik wrote: > We may still be interested in results of a test even if it has tainted > the kernel. On the other hand, we need to kill the test on taint if no > other means of killing it on a jam is active. > > If abort on both kernel taint

[Intel-gfx] [PATCH] drm/i915/selftests: Improve error reporting for igt_mock_max_segment

When we fail to find a single block large enough to require splitting, report the largest block we did find. Signed-off-by: Chris Wilson Cc: Matthew Auld Cc: Ramalingam C --- .../gpu/drm/i915/selftests/intel_memory_region.c | 15 +++ 1 file changed, 7 insertions(+), 8

[Intel-gfx] [PATCH] drm/i915/selftests: Improve error reporting for igt_mock_max_segment

When we fail to find a single block large enough to require splitting, report the largest block we did find. Signed-off-by: Chris Wilson Cc: Matthew Auld Cc: Ramalingam C --- .../gpu/drm/i915/selftests/intel_memory_region.c | 15 +++ 1 file changed, 7 insertions(+), 8

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Fixing the error handling of shmem_pin_map

== Series Details == Series: drm/i915/gt: Fixing the error handling of shmem_pin_map URL : https://patchwork.freedesktop.org/series/84637/ State : success == Summary == CI Bug Log - changes from CI_DRM_9453 -> Patchwork_19074 Summary

Re: [Intel-gfx] [RFC-v1 09/16] drm/i915/pxp: Func to send hardware session termination

Quoting Huang, Sean Z (2020-12-07 02:21:27) > Implement the functions to allow PXP to send a GPU command, in > order to terminate the hardware session, so hardware can recycle > this session slot for the next usage. > > Signed-off-by: Huang, Sean Z As we only have a singleton session support in

Re: [Intel-gfx] [RFC-v1 08/16] drm/i915/pxp: Create the arbitrary session after boot

Quoting Huang, Sean Z (2020-12-07 02:21:26) > Create the arbitrary session, with the fixed session id 0xf, after > system boot, for the case that application allocates the protected > buffer without establishing any protection session. Because the > hardware requires at least one alive session for

Re: [Intel-gfx] [RFC-v1 07/16] drm/i915/pxp: Implement funcs to create the TEE channel

Quoting Huang, Sean Z (2020-12-07 02:21:25) > Currently ring3 driver sends the TEE commands directly to TEE, but > later, as our design, we would like to make ring3 sending the TEE > commands via the ring0 PXP ioctl action instead of TEE ioctl, so > we can centralize those protection operations at

Re: [Intel-gfx] [RFC-v1 06/16] drm/i915/pxp: Implement funcs to get/set PXP tag

Quoting Huang, Sean Z (2020-12-07 02:21:24) > Implement the functions to get/set the PXP tag, which is 32-bit > bitwise value containing the hardware session info, such as its > session id, protection mode or whether it's enabled. > > Signed-off-by: Huang, Sean Z By my understanding, this patch

Re: [Intel-gfx] [RFC-v1 05/16] drm/i915/pxp: Read register to check hardware session state

Quoting Huang, Sean Z (2020-12-07 02:21:23) > Implement the functions to check the hardware protected session > state via reading the hardware register session in play. > > Signed-off-by: Huang, Sean Z > +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h > @@ -12,6 +12,9 @@ > #define

Re: [Intel-gfx] [RFC-v1 04/16] drm/i915/pxp: set KCR reg init during the boot time

Quoting Huang, Sean Z (2020-12-07 02:21:22) > Set the KCR init during the boot time, which is required by > hardware, to allow us doing further protection operation such > as sending commands to GPU or TEE > > Signed-off-by: Huang, Sean Z > +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c > @@ -6,6

Re: [Intel-gfx] [PATCH] drm/i915/gt: Fixing the error handling of shmem_pin_map

In that case can we merge the series http://intel-gfx-pw.fi.intel.com/series/6611/ ? If so please provide your R-b/Ack > -Original Message- > From: Chris Wilson > Sent: Monday, December 7, 2020 4:17 PM > To: C, Ramalingam ; intel-gfx g...@lists.freedesktop.org> > Subject: Re:

Re: [Intel-gfx] [RFC-v1 03/16] drm/i915/pxp: Add PXP context for logical hardware states.

Quoting Huang, Sean Z (2020-12-07 02:21:21) > Add PXP context which represents combined view > of driver and logical HW states. > > Signed-off-by: Huang, Sean Z > +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c > @@ -5,6 +5,7 @@ > > #include "i915_drv.h" > #include "intel_pxp.h" > +#include

Re: [Intel-gfx] [PATCH] drm/i915/gt: Fixing the error handling of shmem_pin_map

Quoting Ramalingam C (2020-12-07 10:28:12) > Since i was size_t, at error handling if i is 0, then --i >= 0. > Making i as int. The problem here is that size_t is 64b, but int 32b. There's a patch by Colin King that does the trick. -Chris ___ Intel-gfx

[Intel-gfx] [PATCH] drm/i915/gt: Fixing the error handling of shmem_pin_map

Since i was size_t, at error handling if i is 0, then --i >= 0. Making i as int. Signed-off-by: Ramalingam C cc: Chris Wilson --- drivers/gpu/drm/i915/gt/shmem_utils.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/shmem_utils.c

Re: [Intel-gfx] [RFC-v1 02/16] drm/i915/pxp: Enable PXP irq worker and callback stub

Quoting Huang, Sean Z (2020-12-07 02:21:20) > Create the irq worker that serves as callback handler, those > callback stubs should be called while the hardware key teardown > occurs. > > Signed-off-by: Huang, Sean Z > +++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c > @@ -13,6 +13,7 @@ >

Re: [Intel-gfx] [PATCH] drm/i915/rkl: Remove require_force_probe protection

Hi Chris, Are below results satisfying? Thanks, Tejas > -Original Message- > From: Kattamanchi, JaswanthX > Sent: 04 December 2020 15:11 > To: Surendrakumar Upadhyay, TejaskumarX > ; Chris Wilson > ; Pandey, Hariom ; > intel-gfx@lists.freedesktop.org > Cc: Naramasetti, LaxminarayanaX

Re: [Intel-gfx] [RFC-v1 01/16] drm/i915/pxp: Introduce Intel PXP component

Quoting Huang, Sean Z (2020-12-07 02:21:19) > PXP (Protected Xe Path) is an i915 componment, available on GEN12+, > that helps user space to establish the hardware protected session > and manage the status of each alive software session, as well as > the life cycle of each session. > > By design

Re: [Intel-gfx] [PATCH] drm/i915/display/dp: Compute the correct slice count for VDSC on DP

On 12/5/2020 2:28 AM, Manasi Navare wrote: This patch fixes the slice count computation algorithm for calculating the slice count based on Peak pixel rate and the max slice width allowed on the DSC engines. We need to ensure slice count > min slice count req as per DP spec based on peak pixel

Re: [Intel-gfx] [RFC 2/2] drm/i915/display: Protect pipe_update against dc3co exit

On 2020-12-04 at 17:51:34 +0200, Ville Syrjälä wrote: > On Fri, Dec 04, 2020 at 01:40:03PM +0530, Anshuman Gupta wrote: > > On 2020-11-30 at 17:28:32 +0200, Imre Deak wrote: > > > On Mon, Nov 30, 2020 at 02:46:46PM +0530, Anshuman Gupta wrote: > > > > At usual case DC3CO exit happen automatically