Hello Thomas Hellstrom,
The patch ae2a104058e2: "vmwgfx: Implement fence objects" from Sep 1,
2011, leads to the following
Smatch static checker warning:
drivers/dma-buf/dma-fence.c:790 dma_fence_default_wait()
warn: user controlled unbound timeout
drivers/gpu/drm/vmwgfx/vmwgfx_f
Hi,
On 9/9/21 4:56 PM, Matthew Auld wrote:
Hi Christian,
We are looking into using shmem as a ttm_tt backend in i915 for cached
system memory objects. We would also like to make such objects visible
to the i915-gem shrinker, so that they may be swapped out or discarded
when under memory pressur
Am 09.09.21 um 18:56 schrieb Matthew Auld:
On Thu, 9 Sept 2021 at 17:43, Koenig, Christian
wrote:
Hi Matthew,
this doesn't work, I've already tried something similar.
TTM uses the reverse lookup functionality when migrating BOs between system and
device memory. And that doesn't seem to work
Perhaps some background and goal is worth mentioning here.
On Thu, 2021-09-09 at 17:56 +0100, Matthew Auld wrote:
> On Thu, 9 Sept 2021 at 17:43, Koenig, Christian
> wrote:
> >
> > Hi Matthew,
> >
> > this doesn't work, I've already tried something similar.
> >
> > TTM uses the reverse lookup
On 9/9/2021 2:07 PM, Rodrigo Vivi wrote:
On Thu, Sep 09, 2021 at 05:29:08AM -0700, Daniele Ceraolo Spurio wrote:
This api allow user mode to create protected buffers and to mark
contexts as making use of such objects. Only when using contexts
marked in such a way is the execution guaranteed t
Ensure i915_vma_pin_iomap and vma_unpin are done with dpt->obj lock held.
I don't think there's much of a point in merging intel_dpt_pin() with
intel_pin_fb_obj_dpt(), they touch different objects.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/display/intel_dpt.c | 40 ++
Am 10.09.21 um 10:08 schrieb Thomas Hellström:
Perhaps some background and goal is worth mentioning here.
On Thu, 2021-09-09 at 17:56 +0100, Matthew Auld wrote:
On Thu, 9 Sept 2021 at 17:43, Koenig, Christian
wrote:
Hi Matthew,
this doesn't work, I've already tried something similar.
TT
Abstract the complexity of iterating over all the fences
in a dma_resv object.
The new loop handles the whole RCU and retry dance and
returns only fences where we can be sure we grabbed the
right one.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-resv.c | 63 +++
A simpler version of the iterator to be used when the dma_resv object is
locked.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-resv.c | 38 ++
include/linux/dma-resv.h | 18 ++
2 files changed, 56 insertions(+)
diff --git a/drivers/
This makes the function much simpler since the complex
retry logic is now handled else where.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-resv.c | 81 +++---
1 file changed, 32 insertions(+), 49 deletions(-)
diff --git a/drivers/dma-buf/dma-resv.c b/dr
This makes the function much simpler since the complex
retry logic is now handled elsewhere.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-resv.c | 110 +
1 file changed, 37 insertions(+), 73 deletions(-)
diff --git a/drivers/dma-buf/dma-resv.c b/dri
This makes the function much simpler since the complex
retry logic is now handled else where.
Signed-off-by: Christian König
---
drivers/gpu/drm/i915/gem/i915_gem_busy.c | 30 +++-
1 file changed, 9 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_ge
This makes the function much simpler since the complex
retry logic is now handled elsewhere.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-resv.c | 54 +-
1 file changed, 7 insertions(+), 47 deletions(-)
diff --git a/drivers/dma-buf/dma-resv.c b/driv
This makes the function much simpler since the complex
retry logic is now handled elsewhere.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-resv.c | 64 +-
1 file changed, 7 insertions(+), 57 deletions(-)
diff --git a/drivers/dma-buf/dma-resv.c b/driv
This is probably a fix since we didn't even grabed a reference to the
fences.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 0a3127
Simplifying the code a bit.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c | 44
1 file changed, 14 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c
index 862eb3
Instead of hand rolling the logic.
Signed-off-by: Christian König
---
drivers/gpu/drm/etnaviv/etnaviv_gem.c | 27 +--
1 file changed, 9 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
index b8fa6e
Simplifying the code a bit.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_sync.c | 22 +++---
1 file changed, 3 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_sync.c
b/drivers/gpu/drm/radeon/radeon_sync.c
index 9257b60144c4..14a4d81
Simplifying the code a bit.
Signed-off-by: Christian König
---
drivers/gpu/drm/nouveau/nouveau_fence.c | 48 +++--
1 file changed, 12 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c
b/drivers/gpu/drm/nouveau/nouveau_fence.c
index 05d0b3eb
Simplifying the code a bit.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 489e22190e29..0a9270
Simplifying the code a bit. Also drop the RCU read side lock since the
object is locked anyway.
Untested since I can't get the driver to compile on !ARM.
Signed-off-by: Christian König
---
drivers/gpu/drm/msm/msm_gem.c | 19 +--
1 file changed, 5 insertions(+), 14 deletions(-)
On 20/08/2021 23:44, Matthew Brost wrote:
Sometimes it is desirable to queue work up for later if the GT PM isn't
held and run that work on next GT PM unpark.
Sounds maybe plausible, but it depends how much work can happen on
unpark and whether it can have too much of a negative impact on la
On Fri, 2021-09-10 at 10:25 +0200, Christian König wrote:
>
>
> Am 10.09.21 um 10:08 schrieb Thomas Hellström:
> > Perhaps some background and goal is worth mentioning here.
> >
> >
> > On Thu, 2021-09-09 at 17:56 +0100, Matthew Auld wrote:
> > > On Thu, 9 Sept 2021 at 17:43, Koenig, Christian
[Public]
Hi Christian and Xinhui,
Thanks for your suggestion. The cause is I saw data corruption in several
proprietary use cases. BUILD_BUG_ON will have build variation per gcc
difference?
Anyway, WARN_ON is fine to me, and I will send a new patch set soon to address
this.
Regards,
Guchun
Am 10.09.21 um 10:40 schrieb Thomas Hellström:
On Fri, 2021-09-10 at 10:25 +0200, Christian König wrote:
Am 10.09.21 um 10:08 schrieb Thomas Hellström:
Perhaps some background and goal is worth mentioning here.
On Thu, 2021-09-09 at 17:56 +0100, Matthew Auld wrote:
On Thu, 9 Sept 2021 at 17
On 9/9/2021 2:25 PM, Rodrigo Vivi wrote:
On Thu, Sep 09, 2021 at 05:29:14AM -0700, Daniele Ceraolo Spurio wrote:
Now that all the pieces are in place we can add a description of how the
feature works. Also modify the comments in struct intel_pxp into
kerneldoc.
Signed-off-by: Daniele Ceraolo
Vendor will define their own memory types on top of TTM_PL_PRIV,
but call ttm_set_driver_manager directly without checking mem_type
value when setting up memory manager. So add such check to aware
the case when array bounds.
v2: lower check level to WARN_ON
Signed-off-by: Leslie Shi
Signed-off-b
Hi,
We've encountered an issue with the RaspberryPi DSI panel that prevented the
whole display driver from probing.
The issue is described in detail in the commit 7213246a803f ("drm/vc4: dsi:
Only register our component once a DSI device is attached"), but the basic idea
is that since the panel i
The bridge documentation overview is quite packed already, and we'll add
some more documentation that isn't part of an overview at all.
Let's add some sections to the documentation to separate each bits.
Reviewed-by: Andrzej Hajda
Reviewed-by: Sam Ravnborg
Signed-off-by: Maxime Ripard
---
Doc
Interactions between bridges, panels, MIPI-DSI host and the component
framework are not trivial and can lead to probing issues when
implementing a display driver. Let's document the various cases we need
too consider, and the solution to support all the cases.
Signed-off-by: Maxime Ripard
---
Do
Devices that take their data through the MIPI-DSI bus but are controlled
through a secondary bus like I2C have to register a secondary device on
the MIPI-DSI bus through the mipi_dsi_device_register_full() function.
At removal or when an error occurs, that device needs to be removed
through a call
MIPI-DSI devices need to call mipi_dsi_attach() when their probe is done
to attach against their host.
However, at removal or when an error occurs, that attachment needs to be
undone through a call to mipi_dsi_detach().
Let's create a device-managed variant of the attachment function that
will au
Let's switch to the new devm MIPI-DSI function to register and attach
our secondary device. This also avoids leaking the device when we detach
the bridge.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/adv7511/adv7511.h | 1 -
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 2 --
d
In order to avoid any probe ordering issue, the best practice is to move
the secondary MIPI-DSI device registration and attachment to the
MIPI-DSI host at probe time. Let's do this.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 13 ++---
1 file changed,
Let's switch to the new devm MIPI-DSI function to register and attach
our secondary device.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 20 +---
1 file changed, 5 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625
In order to avoid any probe ordering issue, the best practice is to move
the secondary MIPI-DSI device registration and attachment to the
MIPI-DSI host at probe time. Let's do this.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 20 ++--
1 file chang
Let's switch to the new devm MIPI-DSI function to register and attach
our secondary device.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/lontium-lt8912b.c | 20
1 file changed, 4 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/bridge/lontium-lt8912b.c
In order to avoid any probe ordering issue, the best practice is to move
the secondary MIPI-DSI device registration and attachment to the
MIPI-DSI host at probe time. Let's do this.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/lontium-lt8912b.c | 11 +++
1 file changed, 7 inse
Let's switch to the new devm MIPI-DSI function to register and attach
our secondary device.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/lontium-lt9611.c | 24
1 file changed, 4 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/bridge/lontium-lt9611
In order to avoid any probe ordering issue, the best practice is to move
the secondary MIPI-DSI device registration and attachment to the
MIPI-DSI host at probe time. Let's do this.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/lontium-lt9611.c | 38 -
1 file ch
Let's switch to the new devm MIPI-DSI function to register and attach
our secondary device.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 38 +-
1 file changed, 8 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/bridge/lontium-lt961
In order to avoid any probe ordering issue, the best practice is to move
the secondary MIPI-DSI device registration and attachment to the
MIPI-DSI host at probe time. Let's do this.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 31 +-
1 file ch
Let's switch to the new devm MIPI-DSI function to register and attach
our secondary device. This also avoids leaking the device on removal.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/parade-ps8640.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drive
In order to avoid any probe ordering issue, the best practice is to move
the secondary MIPI-DSI device registration and attachment to the
MIPI-DSI host at probe time. Let's do this.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/parade-ps8640.c | 97 +++---
1 file ch
Let's switch to the new devm MIPI-DSI function to register and attach
our secondary device. This also avoids leaking the device when we detach
the bridge but don't remove its driver.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/ti-sn65dsi83.c | 12 +++-
1 file changed, 3 inser
In order to avoid any probe ordering issue, the best practice is to move
the secondary MIPI-DSI device registration and attachment to the
MIPI-DSI host at probe time. Let's do this.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/ti-sn65dsi83.c | 80 +++
1 file ch
Let's switch to the new devm MIPI-DSI function to register and attach
our secondary device. This also avoids leaking the device when we detach
the bridge.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 22 +++---
1 file changed, 7 insertions(+), 15 delet
Let's switch to the new devm MIPI-DSI function to register and attach
our secondary device. This also avoids leaking the device when we detach
the bridge.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/tc358775.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff
In order to avoid any probe ordering issue, the best practice is to move
the secondary MIPI-DSI device registration and attachment to the
MIPI-DSI host at probe time. Let's do this.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 74 ++-
1 file ch
In order to avoid any probe ordering issue, the best practice is to move
the secondary MIPI-DSI device registration and attachment to the
MIPI-DSI host at probe time. Let's do this.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/tc358775.c | 37 +--
1 file ch
Without proper care and an agreement between how DSI hosts and devices
drivers register their MIPI-DSI entities and potential components, we can
end up in a situation where the drivers can never probe.
Most drivers were taking evasive maneuvers to try to workaround this,
but not all of them were f
Without proper care and an agreement between how DSI hosts and devices
drivers register their MIPI-DSI entities and potential components, we can
end up in a situation where the drivers can never probe.
Most drivers were taking evasive maneuvers to try to workaround this,
but not all of them were f
On 20/08/2021 23:44, Matthew Brost wrote:
Add logical engine mapping. This is required for split-frame, as
workloads need to be placed on engines in a logically contiguous manner.
v2:
(Daniel Vetter)
- Add kernel doc for new fields
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915
On 20/08/2021 23:44, Matthew Brost wrote:
For some users of multi-lrc, e.g. split frame, it isn't safe to preempt
mid BB. To safely enable preemption at the BB boundary, a handshake
between to parent and child is needed. This is implemented via custom
emit_bb_start & emit_fini_breadcrumb functi
On 03.09.2021 16:28, Janusz Krzysztofik wrote:
GPU wedged flag now set on driver unregister to prevent from further
using the GPU can be then cleared unintentionally when calling
__intel_gt_unset_wedged() still before the flag is finally marked
unrecoverable. We need to have it marked unrecovera
https://bugzilla.kernel.org/show_bug.cgi?id=213391
--- Comment #36 from Lahfa Samy (s...@lahfa.xyz) ---
Did anyone test whether this has been fixed in newer firmware updates, or
should we still stay on version 20210315.3568f96-3 ?
--
You may reply to this email to add a comment.
You are receivi
On 10/09/2021 06:33, Matt Roper wrote:
Consolidate down to just a single 'fwtable' implementation. For reads
we don't need to worry about shadow tables. Also, the
NEEDS_FORCE_WAKE() check we previously had in the fwtable implementation
can be dropped --- if a register is outside that range on
On 10/09/2021 06:33, Matt Roper wrote:
On gen6-gen8 (except vlv/chv) we don't use a forcewake lookup table; we
simply check whether the register offset is < 0x4, and return
FORCEWAKE_RENDER if it is. To prepare for upcoming refactoring, let's
define a single-entry forcewake table from [0x
On 10/09/2021 06:33, Matt Roper wrote:
Our uncore MMIO functions for reading/writing registers have become very
complicated over time. There's significant macro magic used to generate
several nearly-identical functions that only really differ in terms of
which platform-specific shadow register
On Fri, 10 Sep 2021 13:42:45 +0300, Mikko Perttunen wrote:
> Add YAML device tree bindings for NVDEC, now in a more appropriate
> place compared to the old textual Host1x bindings.
>
> Signed-off-by: Mikko Perttunen
> ---
> v5:
> * Changed from nvidia,instance to nvidia,host1x-class optional
>
Hi,
This series used to be part of the DSI probe order series, but got removed
since it wasn't useful there anymore.
However, I still believe there is value in moving towards merging bridges and
panels by only making encoder (or upstream bridges) manipulate bridges.
The first patch creates a new
Display drivers so far need to have a lot of boilerplate to first
retrieve either the panel or bridge that they are connected to using
drm_of_find_panel_or_bridge(), and then either deal with each with ad-hoc
functions or create a drm panel bridge through drm_panel_bridge_add.
In order to reduce t
The new devm_drm_of_get_bridge removes most of the boilerplate we
have to deal with. Let's switch to it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_dpi.c | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_dpi.c b/drivers/gpu
The new devm_drm_of_get_bridge removes most of the boilerplate we
have to deal with. Let's switch to it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_drv.c | 2 ++
drivers/gpu/drm/vc4/vc4_dsi.c | 28
2 files changed, 6 insertions(+), 24 deletions(-)
dif
Both the provider (resource manager) and the consumer (the TTM driver)
want to subclass struct ttm_resource. Since this is left for the resource
manager, we need to provide a private pointer for the TTM driver.
Provide a struct ttm_resource_private for the driver to subclass for
data with the same
On 9/6/21 6:55 PM, Thomas Hellström wrote:
Just evict unpinned objects to system. For pinned LMEM objects,
make a backup system object and blit the contents to that.
Backup is performed in three steps,
1: Opportunistically evict evictable objects using the gpu blitter.
2: After gt idle, evict
https://bugzilla.kernel.org/show_bug.cgi?id=213391
--- Comment #37 from Michel Dänzer (mic...@daenzer.net) ---
(In reply to Lahfa Samy from comment #36)
> Did anyone test whether this has been fixed in newer firmware updates, or
> should we still stay on version 20210315.3568f96-3 ?
It's fixed in
On 09/09/2021 17:17, Rodrigo Vivi wrote:
On Thu, Sep 09, 2021 at 12:44:48PM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Usage of Transparent Hugepages was disabled in 9987da4b5dcf
("drm/i915: Disable THP until we have a GPU read BW W/A"), but since it
appears majority of performance re
On Fri, Sep 10, 2021 at 01:10:46PM +0100, Christoph Hellwig wrote:
> On Thu, Sep 09, 2021 at 04:38:45PM -0300, Jason Gunthorpe wrote:
> > Every driver just emits a static string, simply feed it through the ops
> > and provide a standard sysfs show function.
>
> Looks sensible. But can you make th
On Thu, 19 Aug 2021 at 14:59, Maxime Ripard wrote:
>
> We already depend on runtime PM to get the power domains and clocks for
> most of the devices supported by the vc4 driver, so let's just select it
> to make sure it's there, and remove the ifdef.
>
> Signed-off-by: Maxime Ripard
Reviewed-by:
On Thu, 19 Aug 2021 at 15:08, Maxime Ripard wrote:
>
> Commitc7d30623540b ("drm/vc4: hdmi: Remove unused struct") removed the
> references to the vc4_hdmi_audio_widgets and vc4_hdmi_audio_routes
> structures, but not the structures themselves resulting in two warnings.
> Remove it.
>
> Fixes: c7d3
On Fri, Sep 10, 2021 at 02:03:44PM +0100, Tvrtko Ursulin wrote:
>
> On 10/09/2021 06:33, Matt Roper wrote:
> > Our uncore MMIO functions for reading/writing registers have become very
> > complicated over time. There's significant macro magic used to generate
> > several nearly-identical function
Am 10.09.21 um 15:15 schrieb Thomas Hellström:
Both the provider (resource manager) and the consumer (the TTM driver)
want to subclass struct ttm_resource. Since this is left for the resource
manager, we need to provide a private pointer for the TTM driver.
Provide a struct ttm_resource_priva
Add a device tree node for NVDEC on Tegra186, and
device tree nodes for NVDEC and NVDEC1 on Tegra194.
Signed-off-by: Mikko Perttunen
---
v5:
* Change from nvidia,instance to nvidia,host1x-class
v4:
* Add dma-coherent markers
v3:
* Change read2 to read-1
v2:
* Add NVDECSRD1 memory client
* Add als
Add support for booting and using NVDEC on Tegra210, Tegra186
and Tegra194 to the Host1x and TegraDRM drivers. Booting in
secure mode is not currently supported.
Signed-off-by: Mikko Perttunen
---
v5:
* Remove num_instances
* Change from nvidia,instance to nvidia,host1x-class
v3:
* Change num_ins
Add YAML device tree bindings for NVDEC, now in a more appropriate
place compared to the old textual Host1x bindings.
Signed-off-by: Mikko Perttunen
---
v5:
* Changed from nvidia,instance to nvidia,host1x-class optional
property.
* Added dma-coherent
v4:
* Fix incorrect compatibility string in
Here's the v5 of the NVDEC support series, containing the
following changes:
* Changed from nvidia,instance property to nvidia,host1x-class
property.
* Set additionalProperties to false in DT bindings.
* Added dma-coherent property to DT bindings.
NVDEC hardware documentation can be found at
ht
On Wed, Sep 08, 2021 at 05:58:33PM -0500, Tom Lendacky wrote:
> In prep for other confidential computing technologies, introduce a generic
preparation
> helper function, cc_platform_has(), that can be used to check for specific
> active confidential computing attributes, like memory encryption. T
To print stack entries into a buffer, users of stackdepot,
first get a list of stack entries using stack_depot_fetch
and then print this list into a buffer using stack_trace_snprint.
Provide a helper in stackdepot for this purpose.
Also change above mentioned users to use this helper.
Signed-off-b
This change is in response to discussion at [1].
The patch has been created on top of my earlier changes [2] and [3].
If needed I can resend all of these patches together, though my
earlier patches have been Acked.
[1] https://lore.kernel.org/lkml/e6f6fb85-1d83-425b-9e36-b5784cc9e...@suse.cz/
[2]
On 10/09/2021 15:24, Matt Roper wrote:
On Fri, Sep 10, 2021 at 02:03:44PM +0100, Tvrtko Ursulin wrote:
On 10/09/2021 06:33, Matt Roper wrote:
Our uncore MMIO functions for reading/writing registers have become very
complicated over time. There's significant macro magic used to generate
seve
On Thu, Sep 09, 2021 at 11:32:18AM +0200, Maarten Lankhorst wrote:
> diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
> index d456579d0952..791c28005eef 100644
> --- a/kernel/locking/mutex.c
> +++ b/kernel/locking/mutex.c
> @@ -736,6 +736,44 @@ __ww_mutex_lock(struct mutex *lock, unsign
On Fri, Sep 10, 2021 at 04:03:50PM +0100, Tvrtko Ursulin wrote:
>
> On 10/09/2021 15:24, Matt Roper wrote:
> > On Fri, Sep 10, 2021 at 02:03:44PM +0100, Tvrtko Ursulin wrote:
> > >
> > > On 10/09/2021 06:33, Matt Roper wrote:
> > > > Our uncore MMIO functions for reading/writing registers have be
Hi Zheyu,
On Mon, Jul 26, 2021 at 12:04 PM Zheyu Ma wrote:
> The userspace program could pass any values to the driver through
> ioctl() interface. If the driver doesn't check the value of 'pixclock',
> it may cause divide error.
>
> Fix this by checking whether 'pixclock' is zero first.
>
> The
On Fri, 2021-09-10 at 16:40 +0200, Christian König wrote:
>
>
> Am 10.09.21 um 15:15 schrieb Thomas Hellström:
> > Both the provider (resource manager) and the consumer (the TTM
> > driver)
> > want to subclass struct ttm_resource. Since this is left for the
> > resource
> > manager, we need to p
PXP (Protected Xe Path) is an i915 component, available on
GEN12i and newer platforms, that helps to establish the hardware
protected session and manage the status of the alive software session,
as well as its life cycle.
changes from v8:
- comments/docs improvements
- remove rpm put race (pxp_inv
This will be used for communication between the i915 driver and the mei
one. Defining it in a stand-alone patch to avoid circualr dependedencies
between the patches modifying the 2 drivers.
Split out from an original patch from Huang, Sean Z
v2: rename the component struct (Rodrigo)
Signed-off-
From: Vitaly Lubart
Export PAVP client to work with i915 driver,
for binding it uses kernel component framework.
v2:drop debug prints, refactor match code to match mei_hdcp (Tomas)
Signed-off-by: Vitaly Lubart
Signed-off-by: Tomas Winkler
Signed-off-by: Daniele Ceraolo Spurio
Reviewed-by: Ro
Ahead of the PXP implementation, define the relevant define flag and
kconfig option.
v2: flip kconfig default to N. Some machines have IFWIs that do not
support PXP, so we need it to be an opt-in until we add support to query
the caps from the mei device.
Signed-off-by: Daniele Ceraolo Spurio
Re
The context is required to send the session termination commands to the
VCS, which will be implemented in a follow-up patch. We can also use the
presence of the context as a check of pxp initialization completion.
v2: use perma-pinned context (Chris)
v3: rename pinned_context functions (Chris)
v4:
From: "Huang, Sean Z"
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. T
From: "Huang, Sean Z"
Implement the funcs to create the TEE channel, so kernel can
send the TEE commands directly to TEE for creating the arbitrary
(default) session.
v2: fix locking, don't pollute dev_priv (Chris)
v3: wait for mei PXP component to be bound.
v4: drop the wait, as the component
The setting is required by hardware to allow us doing further protection
operation such as sending commands to GPU or TEE. The register needs to
be re-programmed on resume, so for simplicitly we bundle the programming
with the component binding, which is automatically called on resume.
Further HW
From: "Huang, Sean Z"
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. Additionally, we want to emit a
teardown operation to make sure we're clean on boot and resume
v2: emit in th
This api allow user mode to create protected buffers and to mark
contexts as making use of such objects. Only when using contexts
marked in such a way is the execution guaranteed to work as expected.
Contexts can only be marked as using protected content at creation time
(i.e. the parameter is imm
From: Anshuman Gupta
When protected sufaces has flipped and pxp session is disabled,
display black pixels by using plane color CTM correction.
v2:
- Display black pixels in async flip too.
v3:
- Removed the black pixels logic for async flip. [Ville]
- Used plane state to force black pixels. [Vi
Note that discrete cards can support PXP as well, but we haven't tested
on those yet so keeping it disabled for now.
Signed-off-by: Daniele Ceraolo Spurio
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_pci.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i91
Now that we can handle destruction and re-creation of the arb session,
we can postpone the start of the session to the first submission that
requires it, to avoid keeping it running with no user.
Signed-off-by: Daniele Ceraolo Spurio
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/gem/i915_g
From: "Huang, Sean Z"
The HW will generate a teardown interrupt when session termination is
required, which requires i915 to submit a terminating batch. Once the HW
is done with the termination it will generate another interrupt, at
which point it is safe to re-create the session.
Since the term
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:
- Used gen fb obj user_flags instead gem_object_metadata. [Krishna
1 - 100 of 144 matches
Mail list logo
