Hi Tvrtko,
On 9/15/20 4:31 PM, Tvrtko Ursulin wrote:
With the previous version of the series I hit a problem on Ivybridge
where apparently the dma engine width is not respected. At least that
is my layman interpretation of the errors. From the older thread:
<3> [209.526605] DMAR:
== Series Details ==
Series: Remove DPCD Aux Backlight Control PWM_PIN check
URL : https://patchwork.freedesktop.org/series/82041/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9045_full -> Patchwork_18560_full
Summary
== Series Details ==
Series: Fix NULL pointer found by static analysis (rev2)
URL : https://patchwork.freedesktop.org/series/81999/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9045_full -> Patchwork_18559_full
Summary
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Thursday, July 16, 2020 10:21 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 14/14] drm/i915: Sort EHL/JSL PCI IDs
>
> From: Ville Syrjälä
>
> Sort the EHL/JSL PCI IDs numerically.
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Thursday, July 16, 2020 10:21 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 13/14] drm/i915: Sort ICL PCI IDs
>
> From: Ville Syrjälä
>
> Sort the ICL PCI IDs numerically. Some order
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Thursday, July 16, 2020 10:21 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 12/14] drm/i915: Sort CNL PCI IDs
>
> From: Ville Syrjälä
>
> Sort the CNL PCI IDs numerically. Some order
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Thursday, July 16, 2020 10:21 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 11/14] drm/i915: Sort CFL PCI IDs
>
> From: Ville Syrjälä
>
> Sort the CFL PCI IDs numerically. Some order
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Thursday, July 16, 2020 10:21 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 10/14] drm/i915: Sort CML PCI IDs
>
> From: Ville Syrjälä
>
> Sort the CML PCI IDs numerically. Some order
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Thursday, July 16, 2020 10:21 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 09/14] drm/i915: Sort KBL PCI IDs
>
> From: Ville Syrjälä
>
> Sort the KBL PCI IDs numerically. Some order
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Thursday, July 16, 2020 10:21 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 08/14] drm/i915: Sort SKL PCI IDs
>
> From: Ville Syrjälä
>
> Sort the SKL PCI IDs numerically. Some order
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Thursday, July 16, 2020 10:21 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 07/14] drm/i915: Sort HSW PCI IDs
>
> From: Ville Syrjälä
>
> Sort the HSW PCI IDs numerically. Some order
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Thursday, July 16, 2020 10:21 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 06/14] drm/i915: Ocd the HSW PCI ID hex
> numbers
>
> From: Ville Syrjälä
>
> Most of the HSW PCI IDs are
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Thursday, July 16, 2020 10:21 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 05/14] drm/i915: Try to fix the SKL GT3/4 vs.
> GT3e/4e comments
>
> From: Ville Syrjälä
>
> Bunch of the
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Thursday, July 16, 2020 10:21 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 04/14] drm/i915: Add SKL GT1.5 PCI IDs
>
> From: Alexei Podtelezhnikov
>
> Add three new devices 0x1913,
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Thursday, July 16, 2020 10:21 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 03/14] drm/i915: Reclassify SKL 0x1923 and
> 0x1927 as ULT
>
> From: Alexei Podtelezhnikov
>
> Reclassify
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Thursday, July 16, 2020 10:21 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 01/14] drm/i915: Update Haswell PCI IDs
>
> From: Alexei Podtelezhnikov
>
> Reclassify 0x0426 as GT3 (GT2+)
On Thu, Sep 03, 2020 at 09:38:31PM +0300, Ville Syrjälä wrote:
> On Wed, Jul 15, 2020 at 03:42:16PM -0700, Manasi Navare wrote:
> > From: Maarten Lankhorst
> >
> > When the clock is higher than the dotclock, try with 2 pipes enabled.
> > If we can enable 2, then we will go into big joiner
== Series Details ==
Series: Remove DPCD Aux Backlight Control PWM_PIN check
URL : https://patchwork.freedesktop.org/series/82041/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9045 -> Patchwork_18560
Summary
---
== Series Details ==
Series: Fix NULL pointer found by static analysis (rev2)
URL : https://patchwork.freedesktop.org/series/81999/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9045 -> Patchwork_18559
Summary
---
The Google Pixel Slate/Nocturne device uses a DPCD backlight
which requires Aux Backlight Control to be enabled. This is
enabled in the ChromeOS kernel trees via disabling the PWM_PIN
check and also an extended heuristic, which was upstreamed
in 2017, but reverted shortly thereafter due to a
Google Pixel Slate/Nocturne needs intel_dp_aux_display_control_capable
set for the DPCD backlight to work. (The display exposes PWM_PIN
capability, but the pin is not connected.) Disabling the check allows
backlight adjustment to work.
Signed-off-by: Satadru Pramanik
---
== Series Details ==
Series: Fix NULL pointer found by static analysis (rev2)
URL : https://patchwork.freedesktop.org/series/81999/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
3a559b7eb929 Fix NULL pointer found by static analysis
-:9: WARNING:COMMIT_LOG_LONG_LINE: Possible
Never mind. This is a false positive.
-Original Message-
From: Intel-gfx On Behalf Of Steve
Hampson
Sent: Tuesday, September 22, 2020 9:41 PM
To: intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH] Fix NULL pointer found by static analysis
A static analysis tool has reveiled
On Wed, 23 Sep 2020 22:55:54 +0200
Thomas Gleixner wrote:
> > Perhaps make migrate_disable() an anonymous local_lock()?
> >
> > This should lower the SHC in theory, if you can't have stacked migrate
> > disables on the same CPU.
>
> I'm pretty sure this ends up in locking hell pretty fast and
On Wed, Sep 23 2020 at 11:52, Steven Rostedt wrote:
> On Wed, 23 Sep 2020 10:40:32 +0200
> pet...@infradead.org wrote:
>
>> However, with migrate_disable() we can have each task preempted in a
>> migrate_disable() region, worse we can stack them all on the _same_ CPU
>> (super ridiculous odds,
== Series Details ==
Series: HDCP misc (rev4)
URL : https://patchwork.freedesktop.org/series/73345/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9043_full -> Patchwork_18557_full
Summary
---
**SUCCESS**
No
On Wed, Sep 23, 2020 at 9:17 PM Marius Vlad wrote:
>
> On Wed, Sep 23, 2020 at 05:18:52PM +0200, Daniel Vetter wrote:
> > When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
> > pull in arbitrary other resources, including CRTCs (e.g. when
> > reconfiguring global resources).
>
On Wed, Sep 23, 2020 at 05:18:52PM +0200, Daniel Vetter wrote:
> When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
> pull in arbitrary other resources, including CRTCs (e.g. when
> reconfiguring global resources).
>
> But in nonblocking mode userspace has then no idea this
== Series Details ==
Series: dma-buf: Flag vmap'ed memory as system or I/O memory (rev2)
URL : https://patchwork.freedesktop.org/series/81647/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9042_full -> Patchwork_18556_full
On Wed, 2020-09-23 at 10:10 -0700, José Roberto de Souza wrote:
> On Wed, 2020-09-23 at 14:02 +0100, Mun, Gwan-gyeong wrote:
> > On Thu, 2020-09-17 at 18:02 -0700, José Roberto de Souza wrote:
> > > Another step towards PSR2 selective fetch, here programming plane
> > > selective fetch registers
On Wed, 2020-09-23 at 14:02 +0100, Mun, Gwan-gyeong wrote:
> On Thu, 2020-09-17 at 18:02 -0700, José Roberto de Souza wrote:
> > Another step towards PSR2 selective fetch, here programming plane
> > selective fetch registers and MAN_TRK_CTL enabling selective fetch
> > but
> > for now it is
== Series Details ==
Series: drm/i915/selftests: Switch 4k kmalloc to use get_free_page for alignment
URL : https://patchwork.freedesktop.org/series/82028/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9042_full -> Patchwork_18555_full
== Series Details ==
Series: series starting with drm/atomic: document and enforce rules around
"spurious" EBUSY (rev2)
URL : https://patchwork.freedesktop.org/series/82023/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9043 -> Patchwork_18558
On Wed, 23 Sep 2020 10:40:32 +0200
pet...@infradead.org wrote:
> However, with migrate_disable() we can have each task preempted in a
> migrate_disable() region, worse we can stack them all on the _same_ CPU
> (super ridiculous odds, sure). And then we end up only able to run one
> task, with the
== Series Details ==
Series: series starting with drm/atomic: document and enforce rules around
"spurious" EBUSY (rev2)
URL : https://patchwork.freedesktop.org/series/82023/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
2ae63b2182d7 drm/atomic: document and enforce rules
On Wed, Sep 23, 2020 at 02:32:05PM +0200, Thomas Zimmermann wrote:
> This patch updates dma_buf_vunmap() and dma-buf's vunmap callback to
> use struct dma_buf_map. The interfaces used to receive a buffer address.
> This address is now given in an instance of the structure.
>
> Users of the
On Wed, Sep 23, 2020 at 02:32:04PM +0200, Thomas Zimmermann wrote:
> This patch updates dma_buf_vmap() and dma-buf's vmap callback to use
> struct dma_buf_map.
>
> The interfaces used to return a buffer address. This address now gets
> stored in an instance of the structure that is given as an
On Wed, Sep 23, 2020 at 04:27:04PM +0200, Christian König wrote:
> Am 23.09.20 um 14:32 schrieb Thomas Zimmermann:
> > The new type struct dma_buf_map represents a mapping of dma-buf memory
> > into kernel space. It contains a flag, is_iomem, that signals users to
> > access the mapped memory with
== Series Details ==
Series: Gen12 HDCP 1.4 support on DP MST (rev2)
URL : https://patchwork.freedesktop.org/series/81289/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9042_full -> Patchwork_18554_full
Summary
---
When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
pull in arbitrary other resources, including CRTCs (e.g. when
reconfiguring global resources).
But in nonblocking mode userspace has then no idea this happened,
which can lead to spurious EBUSY calls, both:
- when that other
Hi Ville,
So to confirm I am skipping this patch completely.
So basically keeping hw.mode as well
Manasi
On Tue, Sep 22, 2020 at 11:52:09AM -0700, Navare, Manasi wrote:
> On Tue, Sep 22, 2020 at 01:19:15PM +0300, Ville Syrjälä wrote:
> > On Mon, Sep 21, 2020 at 02:01:25PM -0700, Navare, Manasi
== Series Details ==
Series: HDCP misc (rev4)
URL : https://patchwork.freedesktop.org/series/73345/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9043 -> Patchwork_18557
Summary
---
**SUCCESS**
No regressions
On Wed, Sep 23, 2020 at 02:58:43PM +0100, Tvrtko Ursulin wrote:
>>> Series did not get a CI run from our side because of a different base so I
>>> don't know if you would like to have a run there? If so you would need to
>>> rebase against git://anongit.freedesktop.org/drm-tip drm-tip and you
Feel free to add an Acked-by: Christian König
to all patches which I haven't explicitly reviewed.
I would say we should just push this to drm-misc-next now.
Thanks for the nice cleanup,
Christian.
Am 23.09.20 um 12:21 schrieb Thomas Zimmermann:
The GEM and PRIME related callbacks in struct
== Series Details ==
Series: series starting with [1/2] drm/atomic: document and enforce rules
around "spurious" EBUSY
URL : https://patchwork.freedesktop.org/series/82023/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9042_full -> Patchwork_18553_full
On Mon, Sep 21 2020 at 21:27, Thomas Gleixner wrote:
> On Mon, Sep 21 2020 at 09:24, Linus Torvalds wrote:
>> On Mon, Sep 21, 2020 at 12:39 AM Thomas Gleixner wrote:
>> Maybe we really *could* call this new kmap functionality something
>> like "kmap_percpu()" (or maybe "local" is good enough),
Am 23.09.20 um 14:32 schrieb Thomas Zimmermann:
This patch updates dma_buf_vmap() and dma-buf's vmap callback to use
struct dma_buf_map.
The interfaces used to return a buffer address. This address now gets
stored in an instance of the structure that is given as an additional
argument. The
Am 23.09.20 um 14:32 schrieb Thomas Zimmermann:
The new type struct dma_buf_map represents a mapping of dma-buf memory
into kernel space. It contains a flag, is_iomem, that signals users to
access the mapped memory with I/O operations instead of regular loads
and stores.
It was assumed that DMA
On 23/09/2020 14:41, Christoph Hellwig wrote:
On Wed, Sep 23, 2020 at 10:52:33AM +0100, Tvrtko Ursulin wrote:
On 18/09/2020 17:37, Christoph Hellwig wrote:
i915_gem_object_map implements fairly low-level vmap functionality in
a driver. Split it into two helpers, one for remapping kernel
== Series Details ==
Series: dma-buf: Flag vmap'ed memory as system or I/O memory (rev2)
URL : https://patchwork.freedesktop.org/series/81647/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9042 -> Patchwork_18556
Summary
== Series Details ==
Series: Convert all remaining drivers to GEM object functions (rev3)
URL : https://patchwork.freedesktop.org/series/80593/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9042_full -> Patchwork_18552_full
On Wed, Sep 23, 2020 at 10:52:33AM +0100, Tvrtko Ursulin wrote:
>
> On 18/09/2020 17:37, Christoph Hellwig wrote:
>> i915_gem_object_map implements fairly low-level vmap functionality in
>> a driver. Split it into two helpers, one for remapping kernel memory
>> which can use vmap, and one for I/O
On Wed, Sep 23 2020 at 10:40, peterz wrote:
> Right, so I'm concerned. migrate_disable() wrecks pretty much all
> Real-Time scheduler theory we have, and PREEMPRT_RT bringing it in is
> somewhat ironic.
It's even more ironic that the approach of PREEMPT_RT has been
'pragmatic ignorance of theory'
From: Ramalingam C
When roll over detected for seq_num_m, we shouldn't continue with stream
management with rolled over value.
So we are terminating the stream management retry, on roll over of the
seq_num_m.
v2:
using drm_dbg_kms instead of DRM_DEBUG_KMS [Anshuman]
v3:
dev_priv is used as
From: Ramalingam C
As per the HDCP2.2 compliance test 1B-10 expectation, when stream
management for a repeater fails, we retry thrice and when it fails
in all retries, HDCP2.2 reauthentication aborted at kernel.
v2:
seq_num_m++ is extended for steam management failures too.[Anshuman]
v3:
Rebased of a older series which has been pending to merge.
original series : https://patchwork.freedesktop.org/series/73345/
Ramalingam C (2):
drm/i915: terminate reauth at stream management failure
drm/i915: dont retry stream management at seq_num_m roll over
== Series Details ==
Series: dma-buf: Flag vmap'ed memory as system or I/O memory (rev2)
URL : https://patchwork.freedesktop.org/series/81647/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
757ce74a1b9b dma-buf: Add struct dma-buf-map for storing struct
dma_buf.vaddr_ptr
-:52:
On Thu, 2020-09-17 at 18:02 -0700, José Roberto de Souza wrote:
> Another step towards PSR2 selective fetch, here programming plane
> selective fetch registers and MAN_TRK_CTL enabling selective fetch
> but
> for now it is fetching the whole area of the planes.
> The damaged area calculation will
== Series Details ==
Series: drm/i915/selftests: Switch 4k kmalloc to use get_free_page for alignment
URL : https://patchwork.freedesktop.org/series/82028/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9042 -> Patchwork_18555
Acked-by: Guo Ren
On Sat, Sep 19, 2020 at 5:50 PM Thomas Gleixner wrote:
>
> Signed-off-by: Thomas Gleixner
> Cc: Guo Ren
> Cc: linux-c...@vger.kernel.org
> ---
> Note: Completely untested
> ---
> arch/csky/Kconfig |1
> arch/csky/include/asm/highmem.h |4 +-
>
On Wed, Sep 23 2020 at 12:19, peterz wrote:
> On Mon, Sep 21, 2020 at 09:27:57PM +0200, Thomas Gleixner wrote:
>> Alternatively this could of course be solved with per CPU page tables
>> which will come around some day anyway I fear.
>
> Previously (with PTI) we looked at making the entire kernel
This patch updates dma_buf_vunmap() and dma-buf's vunmap callback to
use struct dma_buf_map. The interfaces used to receive a buffer address.
This address is now given in an instance of the structure.
Users of the functions are updated accordingly. This is only an interface
change. It is
Dma-buf provides vmap() and vunmap() for retrieving and releasing mappings
of dma-buf memory in kernel address space. The functions operate with plain
addresses and the assumption is that the memory can be accessed with load
and store operations. This is not the case on some architectures (e.g.,
This patch updates dma_buf_vmap() and dma-buf's vmap callback to use
struct dma_buf_map.
The interfaces used to return a buffer address. This address now gets
stored in an instance of the structure that is given as an additional
argument. The functions return an errno code on errors.
Users of
The new type struct dma_buf_map represents a mapping of dma-buf memory
into kernel space. It contains a flag, is_iomem, that signals users to
access the mapped memory with I/O operations instead of regular loads
and stores.
It was assumed that DMA buffer memory can be accessed with regular load
On Mi, 2020-09-23 at 12:21 +0200, Thomas Zimmermann wrote:
> GEM object functions deprecate several similar callback interfaces in
> struct drm_driver. This patch replaces the per-driver callbacks with
> per-instance callbacks in etnaviv. The only exception is gem_prime_mmap,
> which is
== Series Details ==
Series: Gen12 HDCP 1.4 support on DP MST (rev2)
URL : https://patchwork.freedesktop.org/series/81289/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9042 -> Patchwork_18554
Summary
---
In generating the reference LRC, we want a page-aligned address for
simplicity in computing the offsets within. This then shares the
computation for the HW LRC which is mapped and so page aligned, making
the comparison straightforward. It seems that kmalloc(4k) is not always
returning from a
> -Original Message-
> From: Ville Syrjälä
> Sent: Wednesday, September 23, 2020 4:05 PM
> To: Kulkarni, Vandita
> Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani
> Subject: Re: [V13 5/5] drm/i915/dsi: Enable software vblank counter
>
> On Wed, Sep 23, 2020 at 10:16:05AM +,
== Series Details ==
Series: Gen12 HDCP 1.4 support on DP MST (rev2)
URL : https://patchwork.freedesktop.org/series/81289/
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: Gen12 HDCP 1.4 support on DP MST (rev2)
URL : https://patchwork.freedesktop.org/series/81289/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
da72c67c9825 drm/i915/hdcp: DP MST transcoder for link and stream
f9f8c1ab6f3a drm/i915/hdcp: Move HDCP enc
On Wed, Sep 23, 2020 at 01:16:42PM +0200, Daniel Vetter wrote:
> On Wed, Sep 23, 2020 at 1:14 PM Marius Vlad wrote:
> >
> > On Wed, Sep 23, 2020 at 12:58:30PM +0200, Daniel Vetter wrote:
> > > On Tue, Sep 22, 2020 at 3:36 PM Marius Vlad
> > > wrote:
> > > >
> > > > On Fri, Jan 31, 2020 at
== Series Details ==
Series: series starting with [1/2] drm/atomic: document and enforce rules
around "spurious" EBUSY
URL : https://patchwork.freedesktop.org/series/82023/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9042 -> Patchwork_18553
Hi Thomas,
On Wed, Sep 23, 2020 at 12:21:44PM +0200, Thomas Zimmermann wrote:
> The i.MX DCSS driver uses CMA helpers with default callback functions.
> Initialize the driver structure with the rsp CMA helper macro. The
> driver is being converted to use GEM object functions as part of
> this
Both HDCP_{1.x,2.x} requires to select/deselect Multistream HDCP bit
in TRANS_DDI_FUNC_CTL in order to enable/disable stream HDCP
encryption over DP MST Transport Link.
HDCP 1.4 stream encryption requires to validate the stream encryption
status in HDCP_STATUS_{TRANSCODER,PORT} register driving
On Wed, Sep 23, 2020 at 1:14 PM Marius Vlad wrote:
>
> On Wed, Sep 23, 2020 at 12:58:30PM +0200, Daniel Vetter wrote:
> > On Tue, Sep 22, 2020 at 3:36 PM Marius Vlad
> > wrote:
> > >
> > > On Fri, Jan 31, 2020 at 07:34:00AM +, Daniel Stone wrote:
> > > > On Thu, 5 Jul 2018 at 11:21, Daniel
DP MST stream encryption status requires time of a link frame
in order to change its status, but as there were some HDCP
encryption timeout observed earlier, it is safer to use
ENCRYPT_STATUS_CHANGE_TIMEOUT_MS timeout for stream status too,
it requires to move the macro to a header.
It will be
Gen12 has H/W delta with respect to HDCP{1.x,2.x} display engine
instances lies in Transcoder instead of DDI as in Gen11.
This requires hdcp driver to use mst_master_transcoder for link
authentication and stream transcoder for stream encryption
separately.
This will be used for both HDCP 1.4 and
Enable HDCP 1.4 over DP MST for Gen12.
This also enable the stream encryption support for
older generations, which was missing earlier.
v2:
- Added debug print for stream encryption.
- Disable the hdcp on port after disabling last stream
encryption.
Cc: Ramalingam C
Signed-off-by: Anshuman
This is the v2 version after testing DP with some rough
changes in kms_content_protection IGT in order to test stream
encryption with multiple streams.
DP MST link authentication, stream encryption and link integrity
check has been tested with this series on TGL platform.
Anshuman Gupta (4):
On Wed, Sep 23, 2020 at 12:58:30PM +0200, Daniel Vetter wrote:
> On Tue, Sep 22, 2020 at 3:36 PM Marius Vlad wrote:
> >
> > On Fri, Jan 31, 2020 at 07:34:00AM +, Daniel Stone wrote:
> > > On Thu, 5 Jul 2018 at 11:21, Daniel Vetter wrote:
> > > > When doing an atomic modeset with
== Series Details ==
Series: series starting with [1/2] drm/atomic: document and enforce rules
around "spurious" EBUSY
URL : https://patchwork.freedesktop.org/series/82023/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
a59f0f6c784d drm/atomic: document and enforce rules
== Series Details ==
Series: Convert all remaining drivers to GEM object functions (rev3)
URL : https://patchwork.freedesktop.org/series/80593/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9042 -> Patchwork_18552
Summary
When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
pull in arbitrary other resources, including CRTCs (e.g. when
reconfiguring global resources).
But in nonblocking mode userspace has then no idea this happened,
which can lead to spurious EBUSY calls, both:
- when that other
On Tue, Sep 22, 2020 at 3:36 PM Marius Vlad wrote:
>
> On Fri, Jan 31, 2020 at 07:34:00AM +, Daniel Stone wrote:
> > On Thu, 5 Jul 2018 at 11:21, Daniel Vetter wrote:
> > > When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
> > > pull in arbitrary other resources,
Hopefully we'll have the drm crash recorder RSN, but meanwhile
compositors would like to know a bit better why they get an EBUSY.
Cc: Sean Paul
Cc: Daniel Stone
Cc: Pekka Paalanen
Cc: Simon Ser
Cc: Ville Syrjälä
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic.c| 4 ++--
On Wed, Sep 23, 2020 at 12:31 PM Ville Syrjälä
wrote:
>
> On Tue, Sep 22, 2020 at 08:18:34PM +0200, Daniel Vetter wrote:
> > When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
> > pull in arbitrary other resources, including CRTCs (e.g. when
> > reconfiguring global
On Wed, Sep 23, 2020 at 10:16:05AM +, Kulkarni, Vandita wrote:
> > -Original Message-
> > From: Ville Syrjälä
> > Sent: Wednesday, September 23, 2020 3:30 PM
> > To: Kulkarni, Vandita
> > Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani
> > Subject: Re: [V13 5/5] drm/i915/dsi:
== Series Details ==
Series: Convert all remaining drivers to GEM object functions (rev3)
URL : https://patchwork.freedesktop.org/series/80593/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e68833e29f33 drm/amdgpu: Introduce GEM object functions
c2ca03d5a2f6 drm/armada:
On Wed, Sep 23, 2020 at 10:02:49AM +, Kulkarni, Vandita wrote:
> > -Original Message-
> > From: Ville Syrjälä
> > Sent: Wednesday, September 23, 2020 3:30 PM
> > To: Kulkarni, Vandita
> > Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani
> > Subject: Re: [V13 4/5] drm/i915/dsi:
On Tue, Sep 22, 2020 at 08:18:34PM +0200, Daniel Vetter wrote:
> When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
> pull in arbitrary other resources, including CRTCs (e.g. when
> reconfiguring global resources).
>
> But in nonblocking mode userspace has then no idea this
The xlnx driver uses CMA helpers with default callback functions.
Initialize the driver structure with the rsp CMA helper macro. The
driver is being converted to use GEM object functions as part of
this change.
Two callbacks, .dumb_destroy and .gem_prime_import, were initialized
to their default
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in vgem. The only exception is gem_prime_mmap,
which is non-trivial to convert.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Melissa
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in xen. The only exception is gem_prime_mmap,
which is non-trivial to convert.
v2:
* convert xen_drm_drv_free_object_unlocked()
Several GEM and PRIME callbacks have been deprecated in favor of
per-instance GEM object functions. Remove the callbacks as they are
now unused. The only exception is .gem_prime_mmap, which is still
in use by several drivers.
What is also gone is gem_vm_ops in struct drm_driver. All drivers now
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in vc4. The only exception is gem_prime_mmap,
which is non-trivial to convert.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Eric
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in vkms.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Melissa Wen
---
drivers/gpu/drm/vkms/vkms_drv.c | 8
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in tegra.
Signed-off-by: Thomas Zimmermann
Acked-by: Thierry Reding
---
drivers/gpu/drm/tegra/drm.c | 4
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in msm. The only exception is gem_prime_mmap,
which is non-trivial to convert.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces virtgpu's per-driver PRIME export
function with a per-object function.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/virtio/virtgpu_drv.c| 1 -
1 - 100 of 133 matches
Mail list logo
