== Series Details ==
Series: Introduce i915_sched_engine object (rev5)
URL : https://patchwork.freedesktop.org/series/90630/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10226_full -> Patchwork_20378_full
Summary
---
On Wed, Jun 16, 2021 at 01:10:02PM +0800, Claire Chang wrote:
> On Wed, Jun 16, 2021 at 12:59 PM Christoph Hellwig wrote:
> >
> > On Wed, Jun 16, 2021 at 12:04:16PM +0800, Claire Chang wrote:
> > > Just noticed that after propagating swiotlb_force setting into
> > > io_tlb_default_mem->force, the
On Wed, Jun 16, 2021 at 12:59 PM Christoph Hellwig wrote:
>
> On Wed, Jun 16, 2021 at 12:04:16PM +0800, Claire Chang wrote:
> > Just noticed that after propagating swiotlb_force setting into
> > io_tlb_default_mem->force, the memory allocation behavior for
> > swiotlb_force will change (i.e.
On Wed, Jun 16, 2021 at 12:04:16PM +0800, Claire Chang wrote:
> Just noticed that after propagating swiotlb_force setting into
> io_tlb_default_mem->force, the memory allocation behavior for
> swiotlb_force will change (i.e. always skipping arch_dma_alloc and
> dma_direct_alloc_from_pool).
Yes, I
On Wed, Jun 16, 2021 at 11:54 AM Claire Chang wrote:
>
> Add the functions, swiotlb_{alloc,free} to support the memory allocation
> from restricted DMA pool.
>
> The restricted DMA pool is preferred if available.
>
> Note that since coherent allocation needs remapping, one must set up
> another
v11 https://lore.kernel.org/patchwork/cover/1447216/
On Tue, Jun 15, 2021 at 9:27 PM Claire Chang wrote:
>
> This series implements mitigations for lack of DMA access control on
> systems without an IOMMU, which could result in the DMA accessing the
> system memory at unexpected times and/or
If a device is not behind an IOMMU, we look up the device node and set
up the restricted DMA when the restricted-dma-pool is presented.
Signed-off-by: Claire Chang
---
drivers/of/address.c| 33 +
drivers/of/device.c | 3 +++
drivers/of/of_private.h | 6
Introduce the new compatible string, restricted-dma-pool, for restricted
DMA. One can specify the address and length of the restricted DMA memory
region by restricted-dma-pool in the reserved-memory node.
Signed-off-by: Claire Chang
---
.../reserved-memory/reserved-memory.txt | 36
Add the initialization function to create restricted DMA pools from
matching reserved-memory nodes.
Regardless of swiotlb setting, the restricted DMA pool is preferred if
available.
The restricted DMA pools provide a basic level of protection against the
DMA overwriting buffer contents at
Add the functions, swiotlb_{alloc,free} to support the memory allocation
from restricted DMA pool.
The restricted DMA pool is preferred if available.
Note that since coherent allocation needs remapping, one must set up
another device coherent pool by shared-dma-pool and use
Add a new function, swiotlb_release_slots, to make the code reusable for
supporting different bounce buffer pools.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
---
kernel/dma/swiotlb.c | 35 ---
1 file changed, 20 insertions(+), 15 deletions(-)
Rename find_slots to swiotlb_find_slots and move the maintenance of
alloc_size to it for better code reusability later.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
---
kernel/dma/swiotlb.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git
Propagate the swiotlb_force setting into io_tlb_default_mem->force and
use it to determine whether to bounce the data or not. This will be
useful later to allow for different pools.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
---
include/linux/swiotlb.h | 11 +++
Update is_swiotlb_active to add a struct device argument. This will be
useful later to allow for different pools.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gem/i915_gem_internal.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_ttm.c| 2 +-
Update is_swiotlb_buffer to add a struct device argument. This will be
useful later to allow for different pools.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
---
drivers/iommu/dma-iommu.c | 12 ++--
drivers/xen/swiotlb-xen.c | 2 +-
include/linux/swiotlb.h | 7
Always have the pointer to the swiotlb pool used in struct device. This
could help simplify the code for other pools.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
---
drivers/base/core.c| 4
include/linux/device.h | 4
kernel/dma/swiotlb.c | 8
3 files
Split the debugfs creation to make the code reusable for supporting
different bounce buffer pools.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
---
kernel/dma/swiotlb.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/kernel/dma/swiotlb.c
Add a new function, swiotlb_init_io_tlb_mem, for the io_tlb_mem struct
initialization to make the code reusable.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
---
kernel/dma/swiotlb.c | 49 ++--
1 file changed, 24 insertions(+), 25
This series implements mitigations for lack of DMA access control on
systems without an IOMMU, which could result in the DMA accessing the
system memory at unexpected times and/or unexpected addresses, possibly
leading to data leakage or corruption.
For example, we plan to use the PCI-e bus for
On Tue, Jun 15, 2021 at 05:35:15PM -0300, Jason Gunthorpe wrote:
> Yes, the rest of the drivers will get converted eventually too. There
> is no reason to hold things back. Depending on timelines we might be
> able to get AP into this cycle too...
And I have a WIP tree to get rid of the weird
== Series Details ==
Series: Explicity steer l3bank multicast reads when necessary (rev3)
URL : https://patchwork.freedesktop.org/series/91485/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10226 -> Patchwork_20380
Summary
== Series Details ==
Series: Explicity steer l3bank multicast reads when necessary (rev3)
URL : https://patchwork.freedesktop.org/series/91485/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
7ba06b9980dc drm/i915: extract steered reg access to common function
-:90:
== Series Details ==
Series: Update firmware to v62.0.0 (rev4)
URL : https://patchwork.freedesktop.org/series/91106/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10226 -> Patchwork_20379
Summary
---
**SUCCESS**
Because Render Power Gating restricts us to just a single subslice as a
valid steering target for reads of multicast registers in a SUBSLICE
range, the default steering we setup at init may not lead to a suitable
target for L3BANK multicast register. In cases where it does not, use
explicit
We've recently learned that when steering reads of multicast registers
that use 'subslice' replication, it's not only important to steer to a
subslice that isn't fused off, but also to steer to the lowest-numbered
subslice. This is because when Render Power Gating is enabled, grabbing
forcewake
From: Daniele Ceraolo Spurio
New steering cases will be added in the follow-up patches, so prepare a
common helper to avoid code duplication.
Cc: Tvrtko Ursulin
Signed-off-by: Daniele Ceraolo Spurio
Signed-off-by: Matt Roper
Reviewed-by: Rodrigo Vivi
---
Although most of our multicast registers are replicated per-subslice, we
also have a small number of multicast registers that are replicated
per-l3 bank instead. For both types of multicast registers we need to
make sure we steer reads of these registers to a valid instance.
Ideally we'd like to
== Series Details ==
Series: Update firmware to v62.0.0 (rev4)
URL : https://patchwork.freedesktop.org/series/91106/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
== Series Details ==
Series: Update firmware to v62.0.0 (rev4)
URL : https://patchwork.freedesktop.org/series/91106/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
20bd5d817f52 drm/i915/guc: Introduce unified HXG messages
899d9ce395b2 drm/i915/guc: Update firmware to v62.0.0
On 6/15/2021 1:59 PM, Matthew Brost wrote:
The submission tasklet operates on i915_sched_engine, thus it is the
correct place for it.
v3:
(Jason Ekstrand)
Change sched_engine->engine to a void* private data pointer
Add kernel doc
v4:
(Daniele)
Update private_data comment
Set
From: Michal Wajdeczko
GuC ABI documentation is now ready to be included in i915.rst
Signed-off-by: Michal Wajdeczko
Signed-off-by: Matthew Brost
Cc: Piotr Piórkowski
Reviewed-by: Matthew Brost
---
Documentation/gpu/i915.rst | 8
1 file changed, 8 insertions(+)
diff --git
From: Michal Wajdeczko
New GuC firmware will unify format of MMIO and CTB H2G messages.
Introduce their definitions now to allow gradual transition of
our code to match new changes.
Signed-off-by: Matthew Brost
Signed-off-by: Michal Wajdeczko
Cc: Michał Winiarski
Reviewed-by: Daniele Ceraolo
From: Michal Wajdeczko
Most of the changes to the 62.0.0 firmware revolved around CTB
communication channel. Conform to the new (stable) CTB protocol.
v2:
(Michal)
Add values back to kernel DOC for actions
(Docs)
Add 'CT buffer' back in to fix warning
Signed-off-by: John Harrison
As part of enabling GuC submission [1] we need to update to the latest
and greatest firmware. This series does that. All backwards
compatibility breaking changes squashed into a single patch #2. Same
series sent to trybot [2] forcing GuC to be enabled to ensure we haven't
broke something.
v2:
== Series Details ==
Series: New uAPI drm properties for color management
URL : https://patchwork.freedesktop.org/series/91523/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10225_full -> Patchwork_20374_full
Summary
== Series Details ==
Series: Introduce i915_sched_engine object (rev5)
URL : https://patchwork.freedesktop.org/series/90630/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10226 -> Patchwork_20378
Summary
---
Rather passing around an intel_engine_cs in the scheduling code, pass
around a i915_sched_engine.
v3:
(Jason Ekstrand)
Add READ_ONCE around rq->engine in lock_sched_engine
Signed-off-by: Matthew Brost
Reviewed-by: Jason Ekstrand
---
.../drm/i915/gt/intel_execlists_submission.c | 11 +++--
The submission tasklet operates on i915_sched_engine, thus it is the
correct place for it.
v3:
(Jason Ekstrand)
Change sched_engine->engine to a void* private data pointer
Add kernel doc
v4:
(Daniele)
Update private_data comment
Set queue_priority_hint in kick_execlists
v5:
(CI)
Move active request tracking and its lock to i915_sched_engine. This
lock is also the submission lock so having it in the i915_sched_engine
is the correct place.
v3:
(Jason Ekstrand)
Add kernel doc
Signed-off-by: Matthew Brost
Reviewed-by: Daniele Ceraolo Spurio
---
Rather than touching schedule state in the generic PM code, reset the
priolist allocation when empty in the submission code. Add a wrapper
function to do this and update the backends to call it in the correct
place.
v3:
(Jason Ekstrand)
Update patch commit message with a better description
The schedule function should be in the schedule object.
v3:
(Jason Ekstrand)
Add kernel doc
Signed-off-by: Matthew Brost
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gem/i915_gem_wait.c | 4 ++--
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 3 ---
Not all back-ends require a kick after a scheduling update, so make the
kick a call-back function that the back-end can opt-in to. Also move
the current kick function from the scheduler to the execlists file as it
is specific to that back-end.
Signed-off-by: Matthew Brost
Reviewed-by: Daniele
As discussed in [1] we are breaking that large series into a several
smaller ones. This series is stand alone patch part of step #4 which has
no other dependencies or patches relevant to it.
v2:
(Daniel Vetter):
- Split into several smaller patches
- Add kernel doc for i915_sched_engine
Add wrapper function around RB tree to determine if i915_sched_engine is
empty.
Signed-off-by: Matthew Brost
Reviewed-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 2 +-
drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 6 +++---
Introduce i915_sched_engine object which is lower level data structure
that i915_scheduler / generic code can operate on without touching
execlist specific structures. This allows additional submission backends
to be added without breaking the layering. Currently the execlists
backend uses 1 of
On Tue, Jun 15, 2021 at 09:27:02PM +0800, Claire Chang wrote:
> Always have the pointer to the swiotlb pool used in struct device. This
> could help simplify the code for other pools.
Applying: swiotlb: Set dev->dma_io_tlb_mem to the swiotlb pool used
error: patch failed: kernel/dma/swiotlb.c:339
== Series Details ==
Series: Introduce i915_sched_engine object (rev4)
URL : https://patchwork.freedesktop.org/series/90630/
State : failure
== Summary ==
Applying: drm/i915: Move priolist to new i915_sched_engine object
Applying: drm/i915: Add i915_sched_engine_is_empty function
Applying:
== Series Details ==
Series: Explicity steer l3bank multicast reads when necessary (rev2)
URL : https://patchwork.freedesktop.org/series/91485/
State : failure
== Summary ==
Applying: drm/i915: extract steered reg access to common function
Applying: drm/i915: Add GT support for multiple types
== Series Details ==
Series: series starting with [01/10] driver core: Pull required checks into
driver_probe_device()
URL : https://patchwork.freedesktop.org/series/91520/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10225_full -> Patchwork_20373_full
== Series Details ==
Series: i915 TTM sync accelerated migration and clear (rev3)
URL : https://patchwork.freedesktop.org/series/91463/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10225_full -> Patchwork_20371_full
The submission tasklet operates on i915_sched_engine, thus it is the
correct place for it.
v3:
(Jason Ekstrand)
Change sched_engine->engine to a void* private data pointer
Add kernel doc
v4:
(Daniele)
Update private_data comment
Set queue_priority_hint in kick_execlists
Signed-off-by:
Rather than touching schedule state in the generic PM code, reset the
priolist allocation when empty in the submission code. Add a wrapper
function to do this and update the backends to call it in the correct
place.
v3:
(Jason Ekstrand)
Update patch commit message with a better description
Move active request tracking and its lock to i915_sched_engine. This
lock is also the submission lock so having it in the i915_sched_engine
is the correct place.
v3:
(Jason Ekstrand)
Add kernel doc
Signed-off-by: Matthew Brost
Reviewed-by: Daniele Ceraolo Spurio
---
Add wrapper function around RB tree to determine if i915_sched_engine is
empty.
Signed-off-by: Matthew Brost
Reviewed-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 2 +-
drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 6 +++---
Not all back-ends require a kick after a scheduling update, so make the
kick a call-back function that the back-end can opt-in to. Also move
the current kick function from the scheduler to the execlists file as it
is specific to that back-end.
Signed-off-by: Matthew Brost
Reviewed-by: Daniele
Rather passing around an intel_engine_cs in the scheduling code, pass
around a i915_sched_engine.
v3:
(Jason Ekstrand)
Add READ_ONCE around rq->engine in lock_sched_engine
Signed-off-by: Matthew Brost
Reviewed-by: Jason Ekstrand
---
.../drm/i915/gt/intel_execlists_submission.c | 11 +++--
Introduce i915_sched_engine object which is lower level data structure
that i915_scheduler / generic code can operate on without touching
execlist specific structures. This allows additional submission backends
to be added without breaking the layering. Currently the execlists
backend uses 1 of
The schedule function should be in the schedule object.
v3:
(Jason Ekstrand)
Add kernel doc
Signed-off-by: Matthew Brost
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gem/i915_gem_wait.c | 4 ++--
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 3 ---
As discussed in [1] we are breaking that large series into a several
smaller ones. This series is stand alone patch part of step #4 which has
no other dependencies or patches relevant to it.
v2:
(Daniel Vetter):
- Split into several smaller patches
- Add kernel doc for i915_sched_engine
On Wed, 2021-06-09 at 00:09 +, Patchwork wrote:
Patch Details
Series: drm/i915/adl_p: Add initial ADL_P Workarounds (rev2)
URL:https://patchwork.freedesktop.org/series/91127/
State: success
Details:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20314/index.html
CI Bug Log -
== Series Details ==
Series: drm/i915/ttm: Fix memory leaks
URL : https://patchwork.freedesktop.org/series/91512/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10225_full -> Patchwork_20370_full
Summary
---
From: Daniele Ceraolo Spurio
New steering cases will be added in the follow-up patches, so prepare a
common helper to avoid code duplication.
Cc: Tvrtko Ursulin
Signed-off-by: Daniele Ceraolo Spurio
Signed-off-by: Matt Roper
Reviewed-by: Rodrigo Vivi
---
Although most of our multicast registers are replicated per-subslice, we
also have a small number of multicast registers that are replicated
per-l3 bank instead. For both types of multicast registers we need to
make sure we steer reads of these registers to a valid instance.
Ideally we'd like to
We've recently learned that when steering reads of multicast registers
that use 'subslice' replication, it's not only important to steer to a
subslice that isn't fused off, but also to steer to the lowest-numbered
subslice. This is because when Render Power Gating is enabled, grabbing
forcewake
Because Render Power Gating restricts us to just a single subslice as a
valid steering target for reads of multicast registers in a SUBSLICE
range, the default steering we setup at init may not lead to a suitable
target for L3BANK multicast register. In cases where it does not, use
explicit
On Tue, Jun 15, 2021 at 03:48:32PM -0400, Rodrigo Vivi wrote:
> On Tue, Jun 15, 2021 at 08:30:23AM -0700, Matt Roper wrote:
> > On Tue, Jun 15, 2021 at 05:11:04AM -0400, Rodrigo Vivi wrote:
> > > On Tue, Jun 15, 2021 at 05:08:20AM -0400, Rodrigo Vivi wrote:
> > > > On Mon, Jun 14, 2021 at
== Series Details ==
Series: drm/i915: Perform execbuffer object locking as a separate step
URL : https://patchwork.freedesktop.org/series/91506/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10225_full -> Patchwork_20369_full
On Tue, Jun 15, 2021 at 08:30:23AM -0700, Matt Roper wrote:
> On Tue, Jun 15, 2021 at 05:11:04AM -0400, Rodrigo Vivi wrote:
> > On Tue, Jun 15, 2021 at 05:08:20AM -0400, Rodrigo Vivi wrote:
> > > On Mon, Jun 14, 2021 at 08:34:32PM -0700, Matt Roper wrote:
> > > > Although most of our multicast
On Tue, 15 Jun 2021 15:35:13 +0200
Christoph Hellwig wrote:
> @@ -547,10 +538,9 @@ static int call_driver_probe(struct device *dev, struct
> device_driver *drv)
>
> static int really_probe(struct device *dev, struct device_driver *drv)
> {
> - int local_trigger_count =
On Tue, 15 Jun 2021 15:35:09 +0200
Christoph Hellwig wrote:
> This is my alternative take on this series from Jason:
>
> https://lore.kernel.org/dri-devel/87czsszi9i@redhat.com/T/
>
> The mdev/vfio parts are exactly the same, but this solves the driver core
> changes for the direct probing
== Series Details ==
Series: drm/i915/jsl: Add W/A 1409054076 for JSL (rev6)
URL : https://patchwork.freedesktop.org/series/90129/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10225_full -> Patchwork_20368_full
Summary
== Series Details ==
Series: drm/i915: Be more gentle with exiting non-persistent context (rev4)
URL : https://patchwork.freedesktop.org/series/89644/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10225_full -> Patchwork_20366_full
Am 15.06.21 um 16:14 schrieb Werner Sembach:
Add a new general drm property "active bpc" which can be used by graphic drivers
to report the applied bit depth per pixel back to userspace.
While "max bpc" can be used to change the color depth, there was no way to check
which one actually got
On Tue, Jun 15, 2021 at 06:44:38PM +0200, Michal Wajdeczko wrote:
>
>
> On 15.06.2021 17:52, Matthew Brost wrote:
> > On Tue, Jun 15, 2021 at 11:00:09AM +0200, Michal Wajdeczko wrote:
> >>
> >>
> >> On 14.06.2021 21:42, Matthew Brost wrote:
> >>> From: Michal Wajdeczko
> >>>
> >>> Most of the
On 15.06.2021 17:52, Matthew Brost wrote:
> On Tue, Jun 15, 2021 at 11:00:09AM +0200, Michal Wajdeczko wrote:
>>
>>
>> On 14.06.2021 21:42, Matthew Brost wrote:
>>> From: Michal Wajdeczko
>>>
>>> Most of the changes to the 62.0.0 firmware revolved around CTB
>>> communication channel. Conform
On Tue, Jun 15, 2021 at 11:00:09AM +0200, Michal Wajdeczko wrote:
>
>
> On 14.06.2021 21:42, Matthew Brost wrote:
> > From: Michal Wajdeczko
> >
> > Most of the changes to the 62.0.0 firmware revolved around CTB
> > communication channel. Conform to the new (stable) CTB protocol.
> >
> >
On Tue, Jun 15, 2021 at 05:11:04AM -0400, Rodrigo Vivi wrote:
> On Tue, Jun 15, 2021 at 05:08:20AM -0400, Rodrigo Vivi wrote:
> > On Mon, Jun 14, 2021 at 08:34:32PM -0700, Matt Roper wrote:
> > > Although most of our multicast registers are replicated per-subslice, we
> > > also have a small
On Tue, Jun 15, 2021 at 07:50:21AM +0200, Christoph Hellwig wrote:
> On Tue, Jun 15, 2021 at 07:21:57AM +0200, Greg Kroah-Hartman wrote:
> > This looks much better as far as the driver core changes go, thank you
> > for doing this.
> >
> > I'm guessing there will be at least one more revision of
== Series Details ==
Series: New uAPI drm properties for color management
URL : https://patchwork.freedesktop.org/series/91523/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10225 -> Patchwork_20374
Summary
---
== Series Details ==
Series: drm/i915: Remove duplicate include of intel_region_lmem.h
URL : https://patchwork.freedesktop.org/series/91525/
State : failure
== Summary ==
Applying: drm/i915: Remove duplicate include of intel_region_lmem.h
Using index info to reconstruct a base tree...
M
Fix the following checkinclude.pl warning:
drivers/gpu/drm/i915/gt/intel_region_lmem.c
8 #include "intel_region_lmem.h"
12 #include "intel_region_lmem.h"
Signed-off-by: Wan Jiabing
---
drivers/gpu/drm/i915/gt/intel_region_lmem.c | 1 -
1 file changed, 1 deletion(-)
diff --git
== Series Details ==
Series: New uAPI drm properties for color management
URL : https://patchwork.freedesktop.org/series/91523/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
On 14/06/2021 17:26, Thomas Hellström wrote:
From: Chris Wilson
Update the PTE and emit a clear within a single unpreemptible packet
such that we can schedule and pipeline clears.
Signed-off-by: Chris Wilson
Co-developed-by: Thomas Hellström
Signed-off-by: Thomas Hellström
Reviewed-by:
== Series Details ==
Series: New uAPI drm properties for color management
URL : https://patchwork.freedesktop.org/series/91523/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
3ad7ae056858 drm/amd/display: Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A check
-:11:
On 14/06/2021 17:26, Thomas Hellström wrote:
From: Chris Wilson
If we pipeline the PTE updates and then do the copy of those pages
within a single unpreemptible command packet, we can submit the copies
and leave them to be scheduled without having to synchronously wait
under a global lock. In
== Series Details ==
Series: series starting with [01/10] driver core: Pull required checks into
driver_probe_device()
URL : https://patchwork.freedesktop.org/series/91520/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10225 -> Patchwork_20373
== Series Details ==
Series: series starting with [01/10] driver core: Pull required checks into
driver_probe_device()
URL : https://patchwork.freedesktop.org/series/91520/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit
This commit implements the "preferred color format" drm property for the AMD GPU
driver.
Signed-off-by: Werner Sembach
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 24 ++-
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 4
2 files changed, 22 insertions(+), 6
This commit implements the "preferred color format" drm property for the Intel
GPU
driver.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/i915/display/intel_dp.c | 7 ++-
drivers/gpu/drm/i915/display/intel_dp_mst.c | 5 +
drivers/gpu/drm/i915/display/intel_hdmi.c | 5 +
3
This commit implements the "active color format" drm property for the Intel GPU
driver.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/i915/display/intel_display.c | 21 +++-
drivers/gpu/drm/i915/display/intel_dp.c | 2 ++
drivers/gpu/drm/i915/display/intel_dp_mst.c |
This commit implements the "active color range" drm property for the AMD GPU
driver.
Signed-off-by: Werner Sembach
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 32 +++
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 4 +++
2 files changed, 36 insertions(+)
diff --git
Add a new general drm property "preferred color format" which can be used by
userspace to tell the graphic drivers to which color format to use.
Possible options are:
- auto (default/current behaviour)
- rgb
- ycbcr444
- ycbcr422 (not supported by both amdgpu and i915)
-
This commit implements the "active color format" drm property for the AMD GPU
driver.
Signed-off-by: Werner Sembach
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 28 +--
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 4 +++
2 files changed, 30 insertions(+), 2
This commit implements the "active bpc" drm property for the Intel GPU driver.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/i915/display/intel_display.c | 14 ++
drivers/gpu/drm/i915/display/intel_dp.c | 8 ++--
drivers/gpu/drm/i915/display/intel_dp_mst.c | 5 +
This commit implements the "active color range" drm property for the Intel GPU
driver.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/i915/display/intel_display.c | 4
drivers/gpu/drm/i915/display/intel_dp.c | 2 ++
drivers/gpu/drm/i915/display/intel_dp_mst.c | 5 +
Add a new general drm property "active bpc" which can be used by graphic drivers
to report the applied bit depth per pixel back to userspace.
While "max bpc" can be used to change the color depth, there was no way to check
which one actually got used. While in theory the driver chooses the
Add a new general drm property "active color range" which can be used by graphic
drivers to report the used color range back to userspace.
There was no way to check which color range got actually used on a given
monitor. To surely predict this, one must know the exact capabilities of the
monitor
Add a new general drm property "active color format" which can be used by
graphic drivers to report the used color format back to userspace.
There was no way to check which color format got actually used on a given
monitor. To surely predict this, one must know the exact capabilities of the
This commit implements the "active bpc" drm property for the AMD GPU driver.
Signed-off-by: Werner Sembach
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 19 ++-
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 4
2 files changed, 22 insertions(+), 1 deletion(-)
diff
Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A check that was performed in the
drm_mode_is_420_only() case, but not in the drm_mode_is_420_also() &&
force_yuv420_output case.
Without further knowledge if YCbCr 4:2:0 is supported outside of HDMI, there is
no reason to use RGB when the display reports
1 - 100 of 203 matches
Mail list logo
