On Wed, 2021-01-13 at 17:04 +0200, Imre Deak wrote:
> On Fri, Aug 21, 2020 at 11:48:37PM -0700, Khaled Almahallawy wrote:
> > Source needs to write DPCD 103-106 after receiving a PHY request to
> > change
> > swing/pre-emphasis after reading DPCD 206-207. This is especially
> > needed if
> > there
From: Bommu Krishnaiah
Same old gem_create but with now with extensions support. This is needed
to support various upcoming usecases. For now we use the extensions
mechanism to support PAVP.
rev21:
- Fix "Fi.CI.CHECKPATCH" warnings
Signed-off-by: Bommu Krishnaiah
Signed-off-by: Matthew Aul
From: Vitaly Lubart
Export PAVP client to work with i915_cp driver,
for binding it uses kernel component framework.
Signed-off-by: Vitaly Lubart
Signed-off-by: Tomas Winkler
---
drivers/misc/mei/Kconfig | 2 +
drivers/misc/mei/Makefile | 1 +
drivers/misc/mei/pxp/Kconfig | 1
Implement the funcs to create the TEE channel, so kernel can
send the TEE commands directly to TEE for creating the arbitrary
(default) session.
rev21:
- Remove debug print_hex_dump() from intel_pxp_tee_io_message()
- In struct i915_pxp_component_ops, change "receive" to "recv"
Signed-off
Create the irq worker that serves as callback handler, those
callback stubs should be called while the hardware key teardown
occurs.
rev21:
- Fix bug, access i915 pointer before assigning the value at
intel_pxp_irq_handler()
- Writing register GEN11_CRYPTO_RSVD_INTR_ENABLE to enable
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 protected buffer
creation. This arbitrary session n
During the power event S3+ sleep/resume, hardware will lose all the
encryption keys for every hardware session, even though the
software session state was marked as alive after resume. So to
handle such case, PXP should terminate all the hardware sessions
and cleanup all the software states after t
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.
rev21:
In intel_pxp_cmd.c:
- Remove the debug print as well as print_hex_dump()
- Should call i915_gem_object_flush_map(
Teardown is triggered when the display topology changes and no
long meets the secure playback requirement, and hardware trashes
all the encryption keys for display. So as a result, PXP should
handle such case and terminate the type0 sessions, which including
arb session
rev21:
- Bug fixing, we
From: Anshuman Gupta
Add support to enable/disable PLANE_SURF Decryption Request bit.
It requires only to enable plane decryption support when following
condition met.
1. PXP session is enabled.
2. Buffer object is protected.
v2:
- Rebased to libva_cp-drm-tip_tgl_cp tree.
- Used gen fb obj user_
PXP (Protected Xe Path) is an i915 component, available on
GEN12+ that helps to establish the hardware protected session
and manage the status of the alive software session, as well
as its life cycle.
This patch series is to allow the kernel space to create and
manage a single hardware session (a.
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.
rev21:
- Remove "#define KCR_INIT_MASK_SHIFT (16)", but still keep the
macro in this .c file
- Write KCR_INIT reg inly for gen1
Implement the intel_pxp_gem_object_status() to allow i915 display
querying the current PXP session state. In the design, display
should not perform protection flip on the protected buffers if
there is no PXP session alive. And Implement the funciton to set
the protected flag for gem context.
rev23
PXP (Protected Xe Path) is an i915 componment, available on GEN12+,
that helps to establish the hardware protected session and manage
the status of the alive software session, as well as its life cycle.
This patch series is to allow the kernel space to create and
manage a single hardware session (
From: Bommu Krishnaiah
This api allow user mode to create Protected buffer and context creation.
rev21:
- Only allow set I915_CONTEXT_PARAM_PROTECTED_CONTENT during context
creation (i915_gem_context_create_ioctl), but not allow during
context set param (i915_gem_context_setparam
tree: git://anongit.freedesktop.org/drm-intel drm-intel-next
head: d5a0d4b9380a499cc140c7ee04ec80e15a8d49e5
commit: 2a743b7b8a8be8c8fc7c130c304c1243f6bbe9b7 [8/19] drm/i915/hdcp:
Configure HDCP1.4 MST steram encryption status
config: x86_64-randconfig-m001-20210115 (attached as .config)
compil
Anshuman Gupta (2):
drm/i915/hdcp: Fix WARN_ON(data->k > INTEL_NUM_PIPES)
drm/i915/hdcp: Fix uninitialized symbol
drivers/gpu/drm/i915/display/intel_hdcp.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
--
2.26.2
_
Move (num_hdcp_streams > 0) condition to stream_encryption()
code block, where it actually belongs.
This fixes the static analysis error of uninitialized symbol 'ret'.
Cc: Ramalingam C
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 20 ++--
1 file
Initialize no. of streams transmitted on a port to zero
such that intel_hdcp_required_content_stream() can
prepared the content stream after subsequemt attmept to
enable hdcp after a HDCP failure.
v2:
- Initialize k at top level instead of else branch. [Jani]
Cc: Ramalingam C
Signed-off-by: Ansh
On Mon, 2021-01-18 at 20:31 +0200, Imre Deak wrote:
> Atm, the driver programs explicitly the default transparent link
> training mode (0x55) to DP_PHY_REPEATER_MODE even if no LTTPRs are
> detected.
>
> This conforms to the spec (3.6.6.1):
> "DP upstream devices that do not enable the Non-transpa
== Series Details ==
Series: drm/i915/gt: One more flush for Baytrail clear residuals (rev2)
URL : https://patchwork.freedesktop.org/series/86008/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9636_full -> Patchwork_19401_full
==
Hi Lionel,
I'm glad to hear the good news, thank you!
Best regards,
Sean
-Original Message-
From: Lionel Landwerlin
Sent: Monday, January 18, 2021 5:17 AM
To: Huang, Sean Z ; Intel-gfx@lists.freedesktop.org
Cc: Gaurav, Kumar
Subject: Re: [Intel-gfx] [RFC-v21 00/13] Introduce Intel PXP
== Series Details ==
Series: drm/i915/dp: Prevent setting the LTTPR LT mode if no LTTPRs are detected
URL : https://patchwork.freedesktop.org/series/86007/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9636_full -> Patchwork_19399_full
=
== Series Details ==
Series: drm/i915: Disable TRAINING_PATTERN_SET before stopping the TPS
transmission
URL : https://patchwork.freedesktop.org/series/86002/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9636_full -> Patchwork_19397_full
=
== Series Details ==
Series: drm: Move struct drm_device.pdev to legacy (rev4)
URL : https://patchwork.freedesktop.org/series/84205/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9636_full -> Patchwork_19395_full
Summary
--
== Series Details ==
Series: drm/i915/gt: One more flush for Baytrail clear residuals (rev2)
URL : https://patchwork.freedesktop.org/series/86008/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9636 -> Patchwork_19401
Summar
== Series Details ==
Series: drm/i915/display: Apply interactive priority to explicit flip fences
(rev2)
URL : https://patchwork.freedesktop.org/series/85989/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9636_full -> Patchwork_19393_full
=
CI reports that Baytail requires one more invalidate after CACHE_MODE
for it to be happy.
Fixes: ace44e13e577 ("drm/i915/gt: Clear CACHE_MODE prior to clearing
residuals")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Akeem G Abodunrin
---
drivers/gpu/drm/i915/gt/gen7_renderclear.c | 9 ++
== Series Details ==
Series: series starting with [1/2] drm/i915/gt: Do not suspend bonded requests
if one hangs
URL : https://patchwork.freedesktop.org/series/85991/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9636_full -> Patchwork_19392_full
=
== Series Details ==
Series: drm/i915/gt: One more flush for Baytrail clear residuals
URL : https://patchwork.freedesktop.org/series/86008/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9636 -> Patchwork_19400
Summary
-
== Series Details ==
Series: drm/i915/dp: Prevent setting the LTTPR LT mode if no LTTPRs are detected
URL : https://patchwork.freedesktop.org/series/86007/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9636 -> Patchwork_19399
===
== Series Details ==
Series: drm/i915/gem: Remove per-client stats from debugfs/i915_gem_objects
URL : https://patchwork.freedesktop.org/series/85987/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9634_full -> Patchwork_19391_full
==
== Series Details ==
Series: series starting with [1/3] drm/i915: Fix the sgt.pfn sanity check
URL : https://patchwork.freedesktop.org/series/86003/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9636 -> Patchwork_19398
Summ
> On Jan 18, 2021, at 08:14, Thomas Zimmermann wrote:
>
> Using struct drm_device.pdev is deprecated in favor of drm_device.dev.
> The reference to the field was reintroduced during a rebase.
>
> Signed-off-by: Thomas Zimmermann
> Fixes: 9703bb329206 ("drm/vmwgfx: Switch to a managed drm devi
On Fri, 2021-01-08 at 11:53 +0200, Gwan-gyeong Mun wrote:
> It is a preliminary work for supporting multiple EDP PSR and
> DP PanelReplay. And it refactors singleton PSR to Multi Transcoder
> supportable PSR.
> And this moves and renames the i915_psr structure of drm_i915_private's to
> intel_dp's
== Series Details ==
Series: series starting with [1/3] drm/i915: Fix the sgt.pfn sanity check
URL : https://patchwork.freedesktop.org/series/86003/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
957475c12689 drm/i915: Fix the sgt.pfn sanity check
871aa9992e36 drm/i915/error: Fi
== Series Details ==
Series: drm/i915: Disable TRAINING_PATTERN_SET before stopping the TPS
transmission
URL : https://patchwork.freedesktop.org/series/86002/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9636 -> Patchwork_19397
===
== Series Details ==
Series: x86/gpu: add JSL stolen memory support
URL : https://patchwork.freedesktop.org/series/85983/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9634_full -> Patchwork_19389_full
Summary
---
**
CI reports that Baytail requires one more invalidate after CACHE_MODE
for it to be happy.
Fixes: ace44e13e577 ("drm/i915/gt: Clear CACHE_MODE prior to clearing
residuals")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Akeem G Abodunrin
---
drivers/gpu/drm/i915/gt/gen7_renderclear.c | 1 +
Atm, the driver programs explicitly the default transparent link
training mode (0x55) to DP_PHY_REPEATER_MODE even if no LTTPRs are
detected.
This conforms to the spec (3.6.6.1):
"DP upstream devices that do not enable the Non-transparent mode of
LTTPRs shall program the PHY_REPEATER_MODE registe
== Series Details ==
Series: drm: Move struct drm_device.pdev to legacy (rev4)
URL : https://patchwork.freedesktop.org/series/84205/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9636 -> Patchwork_19395
Summary
---
*
== Series Details ==
Series: series starting with [1/3] drm/i915: Fix the sgt.pfn sanity check (rev2)
URL : https://patchwork.freedesktop.org/series/85997/
State : failure
== Summary ==
Applying: drm/i915: Fix the sgt.pfn sanity check
Applying: drm/i915: prefer FORCE_WC for the blitter routine
== Series Details ==
Series: drm/i915/display: Apply interactive priority to explicit flip fences
(rev2)
URL : https://patchwork.freedesktop.org/series/85989/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9636 -> Patchwork_19393
===
== Series Details ==
Series: series starting with [1/2] drm/i915: Strip out internal priorities
URL : https://patchwork.freedesktop.org/series/85992/
State : failure
== Summary ==
Applying: drm/i915: Strip out internal priorities
Applying: drm/i915: Remove I915_USER_PRIORITY_SHIFT
error: sha1
On Mon, Jan 18, 2021 at 03:09:45PM +, Lee Jones wrote:
> On Mon, 18 Jan 2021, Daniel Vetter wrote:
>
> > On Fri, Jan 15, 2021 at 06:27:15PM +, Zack Rusin wrote:
> > >
> > > > On Jan 15, 2021, at 13:15, Lee Jones wrote:
> > > >
> > > > This set is part of a larger effort attempting to cl
== Series Details ==
Series: series starting with [1/2] drm/i915/gt: Do not suspend bonded requests
if one hangs
URL : https://patchwork.freedesktop.org/series/85991/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9636 -> Patchwork_19392
===
In a few places we always end up mapping the pool object with the FORCE
constraint(to prevent hitting -EBUSY) which will destroy the cached
mapping if it has a different type. As a simple first step, make the
mapping type part of the pool interface, where the behaviour is to only
give out pool obje
From: CQ Tang
io_mapping_map_wc() expects the offset to be relative to the iomapping
base address. Currently we just pass in the physical address for the
page which only works if the region.start starts at zero.
Signed-off-by: CQ Tang
Signed-off-by: Matthew Auld
Reviewed-by: Chris Wilson
---
From: Kui Wen
For the device local-memory case, sgt.pfn will always be equal to zero,
since we instead use sgt.dma. Also, for device local-memory it is
perfectly valid for it to start from zero anyway, so no need to add a
new check for that either.
Signed-off-by: Kui Wen
Signed-off-by: Matthew
On Mon, Jan 18, 2021 at 06:21:07PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> DP spec says:
> "The Source device shall start sending the idle pattern after
> it has cleared the Training_Pattern byte in the DPCD."
>
> Currently we do these in operations in the opposite order.
> Swap t
== Series Details ==
Series: series starting with [1/2] drm/i915/gt: Do not suspend bonded requests
if one hangs
URL : https://patchwork.freedesktop.org/series/85991/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
cf42e636b946 drm/i915/gt: Do not suspend bonded requests if one
From: Ville Syrjälä
DP spec says:
"The Source device shall start sending the idle pattern after
it has cleared the Training_Pattern byte in the DPCD."
Currently we do these in operations in the opposite order.
Swap them around to match the spec.
Cc: Imre Deak
Signed-off-by: Ville Syrjälä
---
Op 14-01-2021 om 13:06 schreef Tvrtko Ursulin:
>
> On 05/01/2021 15:34, Maarten Lankhorst wrote:
>> Instead of sharing pages with breadcrumbs, give each timeline a
>> single page. This allows unrelated timelines not to share locks
>> any more during command submission.
>>
>> As an additional benefi
Quoting Matthew Auld (2021-01-18 15:55:31)
> On Mon, 18 Jan 2021 at 14:54, Chris Wilson wrote:
> >
> > Quoting Matthew Auld (2021-01-18 14:17:31)
> > > From: CQ Tang
> > >
> > > The pool is shared and so we might find that there is a pool object with
> > > an existing mapping, but is mapped with
On Mon, 18 Jan 2021 at 14:54, Chris Wilson wrote:
>
> Quoting Matthew Auld (2021-01-18 14:17:31)
> > From: CQ Tang
> >
> > The pool is shared and so we might find that there is a pool object with
> > an existing mapping, but is mapped with different underlying type, which
> > will result in -EBUS
From: Ville Syrjälä
Let's not enable the 4:4:4->4:2:0 conversion bit in the DFP unless we're
actually outputting YCbCr 4:4:4. It would appear some protocol
converters blindy consult this bit even when the source is outputting
RGB, resulting in a visual mess.
Cc: sta...@vger.kernel.org
Closes: ht
Op 18-01-2021 om 16:05 schreef Thomas Hellström:
>
> On 1/18/21 3:46 PM, Maarten Lankhorst wrote:
>> Op 18-01-2021 om 14:28 schreef Thomas Hellström:
>>> On 1/18/21 2:22 PM, Thomas Hellström wrote:
On 1/18/21 1:01 PM, Maarten Lankhorst wrote:
> Op 18-01-2021 om 12:11 schreef Thomas Hellstr
On Thu, Jan 14, 2021 at 10:50:45PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> I accidentally added the compliance test hacks only to
> intel_dp_hotplug() which doesn't even get used on any DDI
> platform. Put the same crap into intel_ddi_hotplug().
>
> Cc: Imre Deak
> Fixes: 193af12c
On Mon, 18 Jan 2021, Daniel Vetter wrote:
> On Fri, Jan 15, 2021 at 06:27:15PM +, Zack Rusin wrote:
> >
> > > On Jan 15, 2021, at 13:15, Lee Jones wrote:
> > >
> > > This set is part of a larger effort attempting to clean-up W=1
> > > kernel builds, which are currently overwhelmingly riddle
On Mon, Jan 18, 2021 at 10:27:53AM +0800, Lee Shawn C wrote:
> There are two CSC on pipeline on gen11 and later platform.
> User space application is allowed to enable CTM and RGB
> to YCbCr coversion at the same time now.
>
> v2: check csc capability in {}_color_check function.
> v3: can't suppor
On 1/18/21 3:46 PM, Maarten Lankhorst wrote:
Op 18-01-2021 om 14:28 schreef Thomas Hellström:
On 1/18/21 2:22 PM, Thomas Hellström wrote:
On 1/18/21 1:01 PM, Maarten Lankhorst wrote:
Op 18-01-2021 om 12:11 schreef Thomas Hellström:
On 1/5/21 4:35 PM, Maarten Lankhorst wrote:
We get a lockde
Hi
Am 18.01.21 um 15:56 schrieb Daniel Vetter:
On Mon, Jan 18, 2021 at 3:40 PM Thomas Zimmermann wrote:
Hi
Am 18.01.21 um 14:50 schrieb Christian König:
Hi Thomas,
this patch unfortunately completely broke amdgpu.
See the splat below:
[ 74.553881]
==
== Series Details ==
Series: drm/i915/gem: Remove per-client stats from debugfs/i915_gem_objects
URL : https://patchwork.freedesktop.org/series/85987/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9634 -> Patchwork_19391
Su
On Mon, Jan 18, 2021 at 3:40 PM Thomas Zimmermann wrote:
>
> Hi
>
> Am 18.01.21 um 14:50 schrieb Christian König:
> > Hi Thomas,
> >
> > this patch unfortunately completely broke amdgpu.
> >
> > See the splat below:
> >
> > [ 74.553881]
> > ===
Quoting Matthew Auld (2021-01-18 14:17:32)
> From: CQ Tang
>
> io_mapping_map_wc() expects the offset to be relative to the iomapping
> base address. Currently we just pass in the physical address for the
> page which only works if the region.start starts at zero.
>
> Signed-off-by: CQ Tang
> S
Quoting Matthew Auld (2021-01-18 14:17:31)
> From: CQ Tang
>
> The pool is shared and so we might find that there is a pool object with
> an existing mapping, but is mapped with different underlying type, which
> will result in -EBUSY.
>
> Signed-off-by: CQ Tang
> Signed-off-by: Matthew Auld
>
On Fri, Jan 15, 2021 at 06:27:15PM +, Zack Rusin wrote:
>
> > On Jan 15, 2021, at 13:15, Lee Jones wrote:
> >
> > This set is part of a larger effort attempting to clean-up W=1
> > kernel builds, which are currently overwhelmingly riddled with
> > niggly little warnings.
> >
> > Last set!
Hi
Am 18.01.21 um 14:38 schrieb Chris Wilson:
Quoting Thomas Zimmermann (2021-01-18 13:14:17)
Using struct drm_device.pdev is deprecated. Convert i915 to struct
drm_device.dev. No functional changes.
This needs to be before or in the previous patch, as that patch removed
assignment of i915->d
Op 18-01-2021 om 14:28 schreef Thomas Hellström:
>
> On 1/18/21 2:22 PM, Thomas Hellström wrote:
>>
>> On 1/18/21 1:01 PM, Maarten Lankhorst wrote:
>>> Op 18-01-2021 om 12:11 schreef Thomas Hellström:
On 1/5/21 4:35 PM, Maarten Lankhorst wrote:
> We get a lockdep splat when the reset mutex
Quoting Matthew Auld (2021-01-18 14:17:31)
> From: CQ Tang
First patch hasn't arrive, so excuse this misplaced reply.
- if (GEM_WARN_ON(!r->sgt.pfn))
+ if (GEM_WARN_ON(!use_dma(r->iobase) && !r->sgt.pfn))
return -EINVAL;
The better check would be if (GEM_WARN_ON(!r->
Op 18-01-2021 om 13:55 schreef Thomas Hellström (Intel):
>
> On 1/18/21 1:43 PM, Maarten Lankhorst wrote:
>> Op 18-01-2021 om 12:30 schreef Thomas Hellström (Intel):
>>> Hi,
>>>
>>> On 1/5/21 4:35 PM, Maarten Lankhorst wrote:
Instead of doing what we do currently, which will never work with
>>
Hi
Am 18.01.21 um 14:50 schrieb Christian König:
Hi Thomas,
this patch unfortunately completely broke amdgpu.
See the splat below:
[ 74.553881]
==
[ 74.554060] BUG: KASAN: null-ptr-deref in
drm_pci_set_busid+0x38/0x100 [drm
== Series Details ==
Series: x86/gpu: add JSL stolen memory support
URL : https://patchwork.freedesktop.org/series/85983/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9634 -> Patchwork_19389
Summary
---
**SUCCESS**
== Series Details ==
Series: drm/i915: Check for rq->hwsp validity after acquiring RCU lock (rev2)
URL : https://patchwork.freedesktop.org/series/85618/
State : failure
== Summary ==
Applying: drm/i915/gt: Prevent use of engine->wa_ctx after error
Using index info to reconstruct a base tree...
From: CQ Tang
The pool is shared and so we might find that there is a pool object with
an existing mapping, but is mapped with different underlying type, which
will result in -EBUSY.
Signed-off-by: CQ Tang
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_object_blt.c | 4 ++--
From: CQ Tang
io_mapping_map_wc() expects the offset to be relative to the iomapping
base address. Currently we just pass in the physical address for the
page which only works if the region.start starts at zero.
Signed-off-by: CQ Tang
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_
From: Kui Wen
For the device local-memory case, sgt.pfn will always be equal to zero,
since we instead use sgt.dma. Also, for device local-memory it is
perfectly valid for it to start from zero anyway, so no need to add a
new check for that either.
Signed-off-by: Kui Wen
Signed-off-by: Matthew
Hi Thomas,
this patch unfortunately completely broke amdgpu.
See the splat below:
[ 74.553881]
==
[ 74.554060] BUG: KASAN: null-ptr-deref in
drm_pci_set_busid+0x38/0x100 [drm]
[ 74.554393] Read of size 4 at addr 00
Quoting Thomas Zimmermann (2021-01-18 13:14:17)
> Using struct drm_device.pdev is deprecated. Convert i915 to struct
> drm_device.dev. No functional changes.
This needs to be before or in the previous patch, as that patch removed
assignment of i915->drm.pdev.
Or the removal of the assignment move
On Mon, Jan 18, 2021 at 02:14:15PM +0100, Thomas Zimmermann wrote:
> We have DRM drivers based on USB, SPI and platform devices. All of them
> are fine with storing their device reference in struct drm_device.dev.
> PCI devices should be no exception. Therefore struct drm_device.pdev is
> deprecate
On 1/18/21 2:22 PM, Thomas Hellström wrote:
On 1/18/21 1:01 PM, Maarten Lankhorst wrote:
Op 18-01-2021 om 12:11 schreef Thomas Hellström:
On 1/5/21 4:35 PM, Maarten Lankhorst wrote:
We get a lockdep splat when the reset mutex is held, because it can be
taken from fence_wait. This conflicts w
On Fri, Jan 15, 2021 at 07:52:53PM +0100, Christian König wrote:
> Am 15.01.21 um 17:47 schrieb Daniel Vetter:
> > We have too many people abusing the struct page they can get at but
> > really shouldn't in importers. Aside from that the backing page might
> > simply not exist (for dynamic p2p mapp
On 1/18/21 1:01 PM, Maarten Lankhorst wrote:
Op 18-01-2021 om 12:11 schreef Thomas Hellström:
On 1/5/21 4:35 PM, Maarten Lankhorst wrote:
We get a lockdep splat when the reset mutex is held, because it can be
taken from fence_wait. This conflicts with the mmu notifier we have,
because we recur
Hi Sean,
FYI, I updated our Mesa drivers with the new
I915_CONTEXT_PARAM_PROTECTED_CONTENT requirement to be only at creation
time [1] [2] and gave a try to this series.
It all works fine :
Tested-by: Lionel Landwerlin
Cheers,
-Lionel
[1] : https://gitlab.freedesktop.org/mesa/mesa/-/merge
Using struct drm_device.pdev is deprecated in favor of drm_device.dev.
The reference to the field was reintroduced during a rebase.
Signed-off-by: Thomas Zimmermann
Fixes: 9703bb329206 ("drm/vmwgfx: Switch to a managed drm device")
Cc: Zack Rusin
Cc: Martin Krastev
Cc: Roland Scheidegger
Cc: V
Using struct drm_device.pdev is deprecated. Convert i915 to struct
drm_device.dev. No functional changes.
Signed-off-by: Thomas Zimmermann
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
drivers/gpu/drm/i915/gt/intel_ggtt.c | 10
Using struct drm_device.pdev is deprecated. Convert i915 to struct
drm_device.dev. No functional changes.
Signed-off-by: Thomas Zimmermann
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
---
drivers/gpu/drm/i915/gvt/cfg_space.c | 5 +++--
drivers/gpu/drm/i915/gvt/firmware.c | 10 +-
We have DRM drivers based on USB, SPI and platform devices. All of them
are fine with storing their device reference in struct drm_device.dev.
PCI devices should be no exception. Therefore struct drm_device.pdev is
deprecated.
Instead upcast from struct drm_device.dev with to_pci_dev(). PCI-specif
Using struct drm_device.pdev is deprecated. Convert i915 to struct
drm_device.dev. No functional changes.
v3:
* rebased
v2:
* move gt/ and gvt/ changes into separate patches
Signed-off-by: Thomas Zimmermann
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
---
drivers/gpu/
Struct drm_device.pdev is being moved to legacy status as only legacy
DRM drivers use it. A possible follow-up patchset could remove pdev
entirely.
v4:
* rebased
Signed-off-by: Thomas Zimmermann
Acked-by: Sam Ravnborg
---
include/drm/drm_device.h | 6 +++---
1 file changed, 3 insertion
I merged more patches into drm-misc-next. I'm mostly sending out v4 of
this patchset to split the final patch into the core changes and the
patch for moving pdev behind CONFIG_DRM_LEGACY. The former are required
to fix a reported bug. [1] There's also a fix to vmwgfx.
The pdev field in struct drm_
As we do not have any internal priority levels, the priority can be set
directed from the user values.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/display/intel_display.c | 4 +-
drivers/gpu/drm/i915/gem/i915_gem_context.c | 6 +--
.../i915/gem/selftests/i915_gem_object_blt.c | 4
Since we are not using any internal priority levels, and in the next few
patches will introduce a new index for which the optimisation is not so
lear cut, discard the small table within the priolist.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gt/intel_engine_heartbeat.c | 2 +-
.../drm/i
Currently, if a modeset/pageflip needs to wait for render completion to
an object, we boost the priority of that rendering above all other work.
We can apply the same interactive priority boosting to explicit fences
that we can unwrap into a native i915_request (i.e. sync_file).
Signed-off-by: Chr
On 1/18/21 1:43 PM, Maarten Lankhorst wrote:
Op 18-01-2021 om 12:30 schreef Thomas Hellström (Intel):
Hi,
On 1/5/21 4:35 PM, Maarten Lankhorst wrote:
Instead of doing what we do currently, which will never work with
PROVE_LOCKING, do the same as AMD does, and something similar to
relocation s
Now that we are careful to always force-restore contexts upon rewinding
(where necessary), we can restore our optimisation to skip over
completed active execlists when dequeuing.
Referenecs: 35f3fd8182ba ("drm/i915/execlists: Workaround switching back to a
completed context")
References: 8ab3a381
Treat the dependency between bonded requests as weak and leave the
remainder of the pair on the GPU if one hangs.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists
Op 18-01-2021 om 12:30 schreef Thomas Hellström (Intel):
> Hi,
>
> On 1/5/21 4:35 PM, Maarten Lankhorst wrote:
>> Instead of doing what we do currently, which will never work with
>> PROVE_LOCKING, do the same as AMD does, and something similar to
>> relocation slowpath. When all locks are dropped,
On Mon, 18 Jan 2021, Chris Wilson wrote:
> Since we allow removing the timeline map at runtime, there is a risk
> that rq->hwsp points into a stale page. To control that risk, we hold
> the RCU read lock while reading *rq->hwsp, but we missed a couple of
> important barriers. First, the unpinning
On 17/01/2021 11:04, Chris Wilson wrote:
Similar to commit 49b20dbf7497 ("drm/i915/gt: Perform an arbitration
check before busywaiting"), also add a check prior to the busywait
on gen8+, as we have now seen (because we added a selftest to add fault
injection into the engine resets) the same eng
1 - 100 of 128 matches
Mail list logo
