Re: [Intel-gfx] [PATCH] drm/i915/lspcon: Limits to 8 bpc for RGB/YCbCr444
> On Sep 1, 2020, at 03:48, Ville Syrjälä wrote:
>
> On Thu, Aug 27, 2020 at 01:04:54PM +0800, Kai Heng Feng wrote:
>> Hi Ville,
>>
>>> On Aug 27, 2020, at 12:24 AM, Ville Syrjälä
>>> wrote:
>>>
>>> On Wed, Aug 26, 2020 at 01:21:15PM +0800, Kai-Heng Feng wrote:
LSPCON only supports 8 bpc for RGB/YCbCr444.
Set the correct bpp otherwise it renders blank screen.
>>>
>>> Hmm. Does
>>> git://github.com/vsyrjala/linux.git dp_downstream_ports_5
>>> work?
>>>
>>> Actually better make that dp_downstream_ports_5^^^ aka.
>>> 54d846ce62a2 ("drm/i915: Do YCbCr 444->420 conversion via DP protocol
>>> converters") to avoid the experiments and hacks I have sitting on top.
>>
>> Can you please rebase it to mainline master or drm-tip?
>
> git://github.com/vsyrjala/linux.git dp_downstream_ports_6
Yes this solves the issue. Thanks a lot!
Any timeline this will get merged?
Kai-Heng
>
> I threw out the hacks/experimental stuff.
>
>>
>> I am getting errors on the branch:
>>
>> DESCEND objtool
>> CALLscripts/atomic/check-atomics.sh
>> CALLscripts/checksyscalls.sh
>> CHK include/generated/compile.h
>> Building modules, stage 2.
>> MODPOST 166 modules
>> LD arch/x86/boot/compressed/vmlinux
>> ld: arch/x86/boot/compressed/pgtable_64.o:(.bss+0x0): multiple definition of
>> `__force_order'; arch/x86/boot/compressed/kaslr_64.o:(.bss+0x0): first
>> defined here
>> ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only
>> section `.head.text'
>> ld: warning: creating DT_TEXTREL in a PIE
>> make[2]: *** [arch/x86/boot/compressed/Makefile:119:
>> arch/x86/boot/compressed/vmlinux] Error 1
>> make[1]: *** [arch/x86/boot/Makefile:113: arch/x86/boot/compressed/vmlinux]
>> Error 2
>> make: *** [arch/x86/Makefile:284: bzImage] Error 2
>> make: *** Waiting for unfinished jobs
>>
>> Kai-Heng
>>
>>>
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2195
Signed-off-by: Kai-Heng Feng
---
drivers/gpu/drm/i915/display/intel_lspcon.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c
b/drivers/gpu/drm/i915/display/intel_lspcon.c
index b781bf469644..c7a44fcaade8 100644
--- a/drivers/gpu/drm/i915/display/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
@@ -196,7 +196,8 @@ void lspcon_ycbcr420_config(struct drm_connector
*connector,
crtc_state->port_clock /= 2;
crtc_state->output_format = INTEL_OUTPUT_FORMAT_YCBCR444;
crtc_state->lspcon_downsampling = true;
- }
+ } else
+ crtc_state->pipe_bpp = 24;
}
static bool lspcon_probe(struct intel_lspcon *lspcon)
--
2.17.1
>>>
>>> --
>>> Ville Syrjälä
>>> Intel
>
> --
> Ville Syrjälä
> Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: manual merge of the drm-misc tree with Linus' tree
Hi all,
On Wed, 26 Aug 2020 10:01:13 +1000 Stephen Rothwell
wrote:
>
> Hi all,
>
> Today's linux-next merge of the drm-misc tree got conflicts in:
>
> drivers/video/fbdev/arcfb.c
> drivers/video/fbdev/atmel_lcdfb.c
> drivers/video/fbdev/savage/savagefb_driver.c
>
> between commit:
>
> df561f6688fe ("treewide: Use fallthrough pseudo-keyword")
>
> from Linus' tree and commit:
>
> ad04fae0de07 ("fbdev: Use fallthrough pseudo-keyword")
>
> from the drm-misc tree.
>
> I fixed it up (they are much the same, I just used the version from Linus'
> tree) and can carry the fix as necessary. This is now fixed as far as
> linux-next is concerned, but any non trivial conflicts should be mentioned
> to your upstream maintainer when your tree is submitted for merging.
> You may also want to consider cooperating with the maintainer of the
> conflicting tree to minimise any particularly complex conflicts.
These conflicts now appear in the merge between the drm tree and Linus'
tree.
--
Cheers,
Stephen Rothwell
pgp4LkGLcCJoa.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: build failure after merge of the drm-misc tree
Hi all,
On Wed, 26 Aug 2020 10:55:47 +1000 Stephen Rothwell
wrote:
>
> After merging the drm-misc tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/gpu/drm/qxl/qxl_display.c: In function
> 'qxl_display_read_client_monitors_config':
> include/drm/drm_modeset_lock.h:167:7: error: implicit declaration of function
> 'drm_drv_uses_atomic_modeset' [-Werror=implicit-function-declaration]
> 167 | if (!drm_drv_uses_atomic_modeset(dev))\
> | ^~~
> drivers/gpu/drm/qxl/qxl_display.c:187:2: note: in expansion of macro
> 'DRM_MODESET_LOCK_ALL_BEGIN'
> 187 | DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx,
> DRM_MODESET_ACQUIRE_INTERRUPTIBLE, ret);
> | ^~
> drivers/gpu/drm/qxl/qxl_display.c:189:35: error: macro
> "DRM_MODESET_LOCK_ALL_END" requires 3 arguments, but only 2 given
> 189 | DRM_MODESET_LOCK_ALL_END(ctx, ret);
> | ^
> In file included from include/drm/drm_crtc.h:36,
> from include/drm/drm_atomic.h:31,
> from drivers/gpu/drm/qxl/qxl_display.c:29:
> include/drm/drm_modeset_lock.h:194: note: macro "DRM_MODESET_LOCK_ALL_END"
> defined here
> 194 | #define DRM_MODESET_LOCK_ALL_END(dev, ctx, ret)\
> |
> drivers/gpu/drm/qxl/qxl_display.c:189:2: error: 'DRM_MODESET_LOCK_ALL_END'
> undeclared (first use in this function)
> 189 | DRM_MODESET_LOCK_ALL_END(ctx, ret);
> | ^~~~
> drivers/gpu/drm/qxl/qxl_display.c:189:2: note: each undeclared identifier is
> reported only once for each function it appears in
> drivers/gpu/drm/qxl/qxl_display.c:187:2: error: label 'modeset_lock_fail'
> used but not defined
> 187 | DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx,
> DRM_MODESET_ACQUIRE_INTERRUPTIBLE, ret);
> | ^~
> In file included from include/drm/drm_crtc.h:36,
> from include/drm/drm_atomic.h:31,
> from drivers/gpu/drm/qxl/qxl_display.c:29:
> include/drm/drm_modeset_lock.h:170:1: warning: label 'modeset_lock_retry'
> defined but not used [-Wunused-label]
> 170 | modeset_lock_retry: \
> | ^~
> drivers/gpu/drm/qxl/qxl_display.c:187:2: note: in expansion of macro
> 'DRM_MODESET_LOCK_ALL_BEGIN'
> 187 | DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx,
> DRM_MODESET_ACQUIRE_INTERRUPTIBLE, ret);
> | ^~
> drivers/gpu/drm/qxl/qxl_display.c: In function
> 'qxl_framebuffer_surface_dirty':
> drivers/gpu/drm/qxl/qxl_display.c:434:35: error: macro
> "DRM_MODESET_LOCK_ALL_END" requires 3 arguments, but only 2 given
> 434 | DRM_MODESET_LOCK_ALL_END(ctx, ret);
> | ^
> In file included from include/drm/drm_crtc.h:36,
> from include/drm/drm_atomic.h:31,
> from drivers/gpu/drm/qxl/qxl_display.c:29:
> include/drm/drm_modeset_lock.h:194: note: macro "DRM_MODESET_LOCK_ALL_END"
> defined here
> 194 | #define DRM_MODESET_LOCK_ALL_END(dev, ctx, ret)\
> |
> drivers/gpu/drm/qxl/qxl_display.c:434:2: error: 'DRM_MODESET_LOCK_ALL_END'
> undeclared (first use in this function)
> 434 | DRM_MODESET_LOCK_ALL_END(ctx, ret);
> | ^~~~
> drivers/gpu/drm/qxl/qxl_display.c:411:2: error: label 'modeset_lock_fail'
> used but not defined
> 411 | DRM_MODESET_LOCK_ALL_BEGIN(fb->dev, ctx,
> DRM_MODESET_ACQUIRE_INTERRUPTIBLE, ret);
> | ^~
> In file included from include/drm/drm_crtc.h:36,
> from include/drm/drm_atomic.h:31,
> from drivers/gpu/drm/qxl/qxl_display.c:29:
> include/drm/drm_modeset_lock.h:170:1: warning: label 'modeset_lock_retry'
> defined but not used [-Wunused-label]
> 170 | modeset_lock_retry: \
> | ^~
> drivers/gpu/drm/qxl/qxl_display.c:411:2: note: in expansion of macro
> 'DRM_MODESET_LOCK_ALL_BEGIN'
> 411 | DRM_MODESET_LOCK_ALL_BEGIN(fb->dev, ctx,
> DRM_MODESET_ACQUIRE_INTERRUPTIBLE, ret);
> | ^~
>
> Caused by commit
>
> bbaac1354cc9 ("drm/qxl: Replace deprecated function in qxl_display")
>
> interacting with commit
>
> 77ef38574beb ("drm/modeset-lock: Take the modeset BKL for legacy drivers")
>
> from the drm-misc-fixes tree.
>
> drivers/gpu/drm/qxl/qxl_display.c manages to include
> drm/drm_modeset_lock.h by some indirect route, but fails to have
> drm/drm_drv.h similarly included. In fact, drm/drm_modeset_lock.h should
> have included drm/drm_drv.h since it uses things declared there, and
> drivers/gpu/drm/qxl/qxl_display.c should include drm/drm_modeset_lock.h
> similarly.
>
> I have added the following hack patch for today.
>
> From: Stephen Rothwell
> Date: Wed, 26 Aug 2020 10:40:18 +1000
> Subject: [PATCH] fix interaction with drm-misc-fix commit
>
> Signed-off-by: Stephen Rothwell
> ---
> drivers/gpu/drm/qxl/qxl_display.c | 5 +++--
>
Re: [Intel-gfx] [PATCH v9 08/32] drm: i915: fix common struct sg_table related issues
>-Original Message-
>From: Robin Murphy
>Sent: Tuesday, September 1, 2020 3:54 PM
>To: Ruhl, Michael J ; Marek Szyprowski
>; dri-de...@lists.freedesktop.org;
>io...@lists.linux-foundation.org; linaro-mm-...@lists.linaro.org; linux-
>ker...@vger.kernel.org
>Cc: Bartlomiej Zolnierkiewicz ; David Airlie
>; intel-gfx@lists.freedesktop.org; Christoph Hellwig
>; linux-arm-ker...@lists.infradead.org
>Subject: Re: [Intel-gfx] [PATCH v9 08/32] drm: i915: fix common struct
>sg_table related issues
>
>On 2020-09-01 20:38, Ruhl, Michael J wrote:
>>> -Original Message-
>>> From: Intel-gfx On Behalf Of
>>> Marek Szyprowski
>>> Sent: Wednesday, August 26, 2020 2:33 AM
>>> To: dri-de...@lists.freedesktop.org; io...@lists.linux-foundation.org;
>>> linaro-mm-...@lists.linaro.org; linux-ker...@vger.kernel.org
>>> Cc: Bartlomiej Zolnierkiewicz ; David Airlie
>>> ; intel-gfx@lists.freedesktop.org; Robin Murphy
>>> ; Christoph Hellwig ; linux-arm-
>>> ker...@lists.infradead.org; Marek Szyprowski
>>>
>>> Subject: [Intel-gfx] [PATCH v9 08/32] drm: i915: fix common struct sg_table
>>> related issues
>>>
>>> The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg()
>>> function
>>> returns the number of the created entries in the DMA address space.
>>> However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
>>> dma_unmap_sg must be called with the original number of the entries
>>> passed to the dma_map_sg().
>>>
>>> struct sg_table is a common structure used for describing a non-contiguous
>>> memory buffer, used commonly in the DRM and graphics subsystems. It
>>> consists of a scatterlist with memory pages and DMA addresses (sgl entry),
>>> as well as the number of scatterlist entries: CPU pages (orig_nents entry)
>>> and DMA mapped pages (nents entry).
>>>
>>> It turned out that it was a common mistake to misuse nents and orig_nents
>>> entries, calling DMA-mapping functions with a wrong number of entries or
>>> ignoring the number of mapped entries returned by the dma_map_sg()
>>> function.
>>>
>>> This driver creatively uses sg_table->orig_nents to store the size of the
>>> allocated scatterlist and ignores the number of the entries returned by
>>> dma_map_sg function. The sg_table->orig_nents is (mis)used to properly
>>> free the (over)allocated scatterlist.
>>>
>>> This patch only introduces the common DMA-mapping wrappers operating
>>> directly on the struct sg_table objects to the dmabuf related functions,
>>> so the other drivers, which might share buffers with i915 could rely on
>>> the properly set nents and orig_nents values.
>>>
>>> Signed-off-by: Marek Szyprowski
>>> ---
>>> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 11 +++
>>> drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c | 7 +++
>>> 2 files changed, 6 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>>> b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>>> index 2679380159fc..8a988592715b 100644
>>> --- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>>> @@ -48,12 +48,9 @@ static struct sg_table
>*i915_gem_map_dma_buf(struct
>>> dma_buf_attachment *attachme
>>> src = sg_next(src);
>>> }
>>>
>>> - if (!dma_map_sg_attrs(attachment->dev,
>>> - st->sgl, st->nents, dir,
>>> - DMA_ATTR_SKIP_CPU_SYNC)) {
>>> - ret = -ENOMEM;
>>
>> You have dropped this error value.
>>
>> Do you now if this is a benign loss?
>
>True, dma_map_sgtable() will return -EINVAL rather than -ENOMEM for
>failure. A quick look through other .map_dma_buf callbacks suggests
>they're returning a motley mix of error values and NULL for failure
>cases, so I'd imagine that importers shouldn't be too sensitive to the
>exact value.
I followed some of our code through to see if anyone is checking for -ENOMEM...
I have found in some test paths... However, it is not clear to me if we can get
to those paths from here.
Anyways,
Reviewed-by: Michael J. Ruhl
Mike
>Robin.
>
>>
>> M
>>
>>> + ret = dma_map_sgtable(attachment->dev, st, dir,
>>> DMA_ATTR_SKIP_CPU_SYNC);
>>> + if (ret)
>>> goto err_free_sg;
>>> - }
>>>
>>> return st;
>>>
>>> @@ -73,9 +70,7 @@ static void i915_gem_unmap_dma_buf(struct
>>> dma_buf_attachment *attachment,
>>> {
>>> struct drm_i915_gem_object *obj = dma_buf_to_obj(attachment-
dmabuf);
>>>
>>> - dma_unmap_sg_attrs(attachment->dev,
>>> - sg->sgl, sg->nents, dir,
>>> - DMA_ATTR_SKIP_CPU_SYNC);
>>> + dma_unmap_sgtable(attachment->dev, sg, dir,
>>> DMA_ATTR_SKIP_CPU_SYNC);
>>> sg_free_table(sg);
>>> kfree(sg);
>>>
>>> diff --git a/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
>>> b/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
>>> index debaf7b18ab5..be30b27e2926 100644
>>> --- a/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
>>> +++
Re: [Intel-gfx] [PATCH v9 08/32] drm: i915: fix common struct sg_table related issues
On 2020-09-01 20:38, Ruhl, Michael J wrote:
-Original Message-
From: Intel-gfx On Behalf Of
Marek Szyprowski
Sent: Wednesday, August 26, 2020 2:33 AM
To: dri-de...@lists.freedesktop.org; io...@lists.linux-foundation.org;
linaro-mm-...@lists.linaro.org; linux-ker...@vger.kernel.org
Cc: Bartlomiej Zolnierkiewicz ; David Airlie
; intel-gfx@lists.freedesktop.org; Robin Murphy
; Christoph Hellwig ; linux-arm-
ker...@lists.infradead.org; Marek Szyprowski
Subject: [Intel-gfx] [PATCH v9 08/32] drm: i915: fix common struct sg_table
related issues
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg()
function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_map_sg().
struct sg_table is a common structure used for describing a non-contiguous
memory buffer, used commonly in the DRM and graphics subsystems. It
consists of a scatterlist with memory pages and DMA addresses (sgl entry),
as well as the number of scatterlist entries: CPU pages (orig_nents entry)
and DMA mapped pages (nents entry).
It turned out that it was a common mistake to misuse nents and orig_nents
entries, calling DMA-mapping functions with a wrong number of entries or
ignoring the number of mapped entries returned by the dma_map_sg()
function.
This driver creatively uses sg_table->orig_nents to store the size of the
allocated scatterlist and ignores the number of the entries returned by
dma_map_sg function. The sg_table->orig_nents is (mis)used to properly
free the (over)allocated scatterlist.
This patch only introduces the common DMA-mapping wrappers operating
directly on the struct sg_table objects to the dmabuf related functions,
so the other drivers, which might share buffers with i915 could rely on
the properly set nents and orig_nents values.
Signed-off-by: Marek Szyprowski
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 11 +++
drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c | 7 +++
2 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index 2679380159fc..8a988592715b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -48,12 +48,9 @@ static struct sg_table *i915_gem_map_dma_buf(struct
dma_buf_attachment *attachme
src = sg_next(src);
}
- if (!dma_map_sg_attrs(attachment->dev,
- st->sgl, st->nents, dir,
- DMA_ATTR_SKIP_CPU_SYNC)) {
- ret = -ENOMEM;
You have dropped this error value.
Do you now if this is a benign loss?
True, dma_map_sgtable() will return -EINVAL rather than -ENOMEM for
failure. A quick look through other .map_dma_buf callbacks suggests
they're returning a motley mix of error values and NULL for failure
cases, so I'd imagine that importers shouldn't be too sensitive to the
exact value.
Robin.
M
+ ret = dma_map_sgtable(attachment->dev, st, dir,
DMA_ATTR_SKIP_CPU_SYNC);
+ if (ret)
goto err_free_sg;
- }
return st;
@@ -73,9 +70,7 @@ static void i915_gem_unmap_dma_buf(struct
dma_buf_attachment *attachment,
{
struct drm_i915_gem_object *obj = dma_buf_to_obj(attachment-
dmabuf);
- dma_unmap_sg_attrs(attachment->dev,
- sg->sgl, sg->nents, dir,
- DMA_ATTR_SKIP_CPU_SYNC);
+ dma_unmap_sgtable(attachment->dev, sg, dir,
DMA_ATTR_SKIP_CPU_SYNC);
sg_free_table(sg);
kfree(sg);
diff --git a/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
b/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
index debaf7b18ab5..be30b27e2926 100644
--- a/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
@@ -28,10 +28,9 @@ static struct sg_table *mock_map_dma_buf(struct
dma_buf_attachment *attachment,
sg = sg_next(sg);
}
- if (!dma_map_sg(attachment->dev, st->sgl, st->nents, dir)) {
- err = -ENOMEM;
+ err = dma_map_sgtable(attachment->dev, st, dir, 0);
+ if (err)
goto err_st;
- }
return st;
@@ -46,7 +45,7 @@ static void mock_unmap_dma_buf(struct
dma_buf_attachment *attachment,
struct sg_table *st,
enum dma_data_direction dir)
{
- dma_unmap_sg(attachment->dev, st->sgl, st->nents, dir);
+ dma_unmap_sgtable(attachment->dev, st, dir, 0);
sg_free_table(st);
kfree(st);
}
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Re: [Intel-gfx] [PATCH v9 08/32] drm: i915: fix common struct sg_table related issues
>-Original Message-
>From: Intel-gfx On Behalf Of
>Marek Szyprowski
>Sent: Wednesday, August 26, 2020 2:33 AM
>To: dri-de...@lists.freedesktop.org; io...@lists.linux-foundation.org;
>linaro-mm-...@lists.linaro.org; linux-ker...@vger.kernel.org
>Cc: Bartlomiej Zolnierkiewicz ; David Airlie
>; intel-gfx@lists.freedesktop.org; Robin Murphy
>; Christoph Hellwig ; linux-arm-
>ker...@lists.infradead.org; Marek Szyprowski
>
>Subject: [Intel-gfx] [PATCH v9 08/32] drm: i915: fix common struct sg_table
>related issues
>
>The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg()
>function
>returns the number of the created entries in the DMA address space.
>However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
>dma_unmap_sg must be called with the original number of the entries
>passed to the dma_map_sg().
>
>struct sg_table is a common structure used for describing a non-contiguous
>memory buffer, used commonly in the DRM and graphics subsystems. It
>consists of a scatterlist with memory pages and DMA addresses (sgl entry),
>as well as the number of scatterlist entries: CPU pages (orig_nents entry)
>and DMA mapped pages (nents entry).
>
>It turned out that it was a common mistake to misuse nents and orig_nents
>entries, calling DMA-mapping functions with a wrong number of entries or
>ignoring the number of mapped entries returned by the dma_map_sg()
>function.
>
>This driver creatively uses sg_table->orig_nents to store the size of the
>allocated scatterlist and ignores the number of the entries returned by
>dma_map_sg function. The sg_table->orig_nents is (mis)used to properly
>free the (over)allocated scatterlist.
>
>This patch only introduces the common DMA-mapping wrappers operating
>directly on the struct sg_table objects to the dmabuf related functions,
>so the other drivers, which might share buffers with i915 could rely on
>the properly set nents and orig_nents values.
>
>Signed-off-by: Marek Szyprowski
>---
> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 11 +++
> drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c | 7 +++
> 2 files changed, 6 insertions(+), 12 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>index 2679380159fc..8a988592715b 100644
>--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>@@ -48,12 +48,9 @@ static struct sg_table *i915_gem_map_dma_buf(struct
>dma_buf_attachment *attachme
> src = sg_next(src);
> }
>
>- if (!dma_map_sg_attrs(attachment->dev,
>-st->sgl, st->nents, dir,
>-DMA_ATTR_SKIP_CPU_SYNC)) {
>- ret = -ENOMEM;
You have dropped this error value.
Do you now if this is a benign loss?
M
>+ ret = dma_map_sgtable(attachment->dev, st, dir,
>DMA_ATTR_SKIP_CPU_SYNC);
>+ if (ret)
> goto err_free_sg;
>- }
>
> return st;
>
>@@ -73,9 +70,7 @@ static void i915_gem_unmap_dma_buf(struct
>dma_buf_attachment *attachment,
> {
> struct drm_i915_gem_object *obj = dma_buf_to_obj(attachment-
>>dmabuf);
>
>- dma_unmap_sg_attrs(attachment->dev,
>- sg->sgl, sg->nents, dir,
>- DMA_ATTR_SKIP_CPU_SYNC);
>+ dma_unmap_sgtable(attachment->dev, sg, dir,
>DMA_ATTR_SKIP_CPU_SYNC);
> sg_free_table(sg);
> kfree(sg);
>
>diff --git a/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
>b/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
>index debaf7b18ab5..be30b27e2926 100644
>--- a/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
>+++ b/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
>@@ -28,10 +28,9 @@ static struct sg_table *mock_map_dma_buf(struct
>dma_buf_attachment *attachment,
> sg = sg_next(sg);
> }
>
>- if (!dma_map_sg(attachment->dev, st->sgl, st->nents, dir)) {
>- err = -ENOMEM;
>+ err = dma_map_sgtable(attachment->dev, st, dir, 0);
>+ if (err)
> goto err_st;
>- }
>
> return st;
>
>@@ -46,7 +45,7 @@ static void mock_unmap_dma_buf(struct
>dma_buf_attachment *attachment,
> struct sg_table *st,
> enum dma_data_direction dir)
> {
>- dma_unmap_sg(attachment->dev, st->sgl, st->nents, dir);
>+ dma_unmap_sgtable(attachment->dev, st, dir, 0);
> sg_free_table(st);
> kfree(st);
> }
>--
>2.17.1
>
>___
>Intel-gfx mailing list
>Intel-gfx@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/i915/display: Ignore IGNORE_PSR2_HW_TRACKING for platforms without sel fetch
On Mon, Aug 31, 2020 at 06:09:21PM -0700, José Roberto de Souza wrote: > For platforms without selective fetch this register is reserved so > do not write 0 to it. > > Cc: Gwan-gyeong Mun > Cc: Ville Syrjälä > Signed-off-by: José Roberto de Souza Reviewed-by: Rodrigo Vivi > --- > drivers/gpu/drm/i915/display/intel_psr.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c > b/drivers/gpu/drm/i915/display/intel_psr.c > index 8a9d0bdde1bf..4e09ae61d4aa 100644 > --- a/drivers/gpu/drm/i915/display/intel_psr.c > +++ b/drivers/gpu/drm/i915/display/intel_psr.c > @@ -942,7 +942,7 @@ static void intel_psr_enable_source(struct intel_dp > *intel_dp, > intel_de_write(dev_priv, EXITLINE(cpu_transcoder), val); > } > > - if (HAS_PSR_HW_TRACKING(dev_priv)) > + if (HAS_PSR_HW_TRACKING(dev_priv) && HAS_PSR2_SEL_FETCH(dev_priv)) > intel_de_rmw(dev_priv, CHICKEN_PAR1_1, IGNORE_PSR2_HW_TRACKING, >dev_priv->psr.psr2_sel_fetch_enabled ? >IGNORE_PSR2_HW_TRACKING : 0); > -- > 2.28.0 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/pll: Centralize PLL_ENABLE register lookup
On Tue, Sep 01, 2020 at 11:27:58AM -0700, Anusha Srivatsa wrote:
> We currenty check for platform at multiple parts in the driver
> to grab the correct PLL. Let us begin to centralize it through a
> helper function.
>
> v2: s/intel_get_pll_enable_reg()/intel_combo_pll_enable_reg() (Ville)
>
> Suggested-by: Matt Roper
> Cc: Ville Syrjälä
> Cc: Matt Roper
> Signed-off-by: Anusha Srivatsa
> ---
> drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 25 +++
> 1 file changed, 15 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> index c9013f8f766f..7440836c5e44 100644
> --- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> @@ -147,6 +147,18 @@ void assert_shared_dpll(struct drm_i915_private
> *dev_priv,
> pll->info->name, onoff(state), onoff(cur_state));
> }
>
> +static
> +i915_reg_t intel_combo_pll_enable_reg(struct drm_i915_private *dev_priv,
> + struct intel_shared_dpll *pll)
> +{
> +
> + if (IS_ELKHARTLAKE(dev_priv) && (pll->info->id == DPLL_ID_EHL_DPLL4))
> + return MG_PLL_ENABLE(0);
> +
> + return CNL_DPLL_ENABLE(pll->info->id);
> +
> +
> +}
> /**
> * intel_prepare_shared_dpll - call a dpll's prepare hook
> * @crtc_state: CRTC, and its state, which has a shared dpll
> @@ -3842,12 +3854,7 @@ static bool combo_pll_get_hw_state(struct
> drm_i915_private *dev_priv,
> struct intel_shared_dpll *pll,
> struct intel_dpll_hw_state *hw_state)
> {
> - i915_reg_t enable_reg = CNL_DPLL_ENABLE(pll->info->id);
> -
> - if (IS_ELKHARTLAKE(dev_priv) &&
> - pll->info->id == DPLL_ID_EHL_DPLL4) {
> - enable_reg = MG_PLL_ENABLE(0);
> - }
> + i915_reg_t enable_reg = intel_combo_pll_enable_reg(dev_priv, pll);
>
> return icl_pll_get_hw_state(dev_priv, pll, hw_state, enable_reg);
> }
> @@ -4045,11 +4052,10 @@ static void icl_pll_enable(struct drm_i915_private
> *dev_priv,
> static void combo_pll_enable(struct drm_i915_private *dev_priv,
>struct intel_shared_dpll *pll)
> {
> - i915_reg_t enable_reg = CNL_DPLL_ENABLE(pll->info->id);
> + i915_reg_t enable_reg = intel_combo_pll_enable_reg(dev_priv, pll);
>
> if (IS_ELKHARTLAKE(dev_priv) &&
> pll->info->id == DPLL_ID_EHL_DPLL4) {
there's probably something else that we can do now with the power_{put,get}
to get rid of the, now, doubled if checks...
> - enable_reg = MG_PLL_ENABLE(0);
>
> /*
>* We need to disable DC states when this DPLL is enabled.
> @@ -4157,11 +4163,10 @@ static void icl_pll_disable(struct drm_i915_private
> *dev_priv,
> static void combo_pll_disable(struct drm_i915_private *dev_priv,
> struct intel_shared_dpll *pll)
> {
> - i915_reg_t enable_reg = CNL_DPLL_ENABLE(pll->info->id);
> + i915_reg_t enable_reg = intel_combo_pll_enable_reg(dev_priv, pll);
>
> if (IS_ELKHARTLAKE(dev_priv) &&
> pll->info->id == DPLL_ID_EHL_DPLL4) {
> - enable_reg = MG_PLL_ENABLE(0);
> icl_pll_disable(dev_priv, pll, enable_reg);
but here, at least, let's clean this function now...
move this call above and out of the if and delete the one below
and keep just the power_put inside the if...
>
> intel_display_power_put(dev_priv, POWER_DOMAIN_DPLL_DC_OFF,
> --
> 2.25.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/pll: Centralize PLL_ENABLE register lookup (rev2)
== Series Details ==
Series: drm/i915/pll: Centralize PLL_ENABLE register lookup (rev2)
URL : https://patchwork.freedesktop.org/series/81150/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8951 -> Patchwork_18430
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_18430 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_18430, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18430/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_18430:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@gem_contexts:
- fi-skl-guc: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8951/fi-skl-guc/igt@i915_selftest@live@gem_contexts.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18430/fi-skl-guc/igt@i915_selftest@live@gem_contexts.html
Known issues
Here are the changes found in Patchwork_18430 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_module_load@reload:
- fi-tgl-u2: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8951/fi-tgl-u2/igt@i915_module_l...@reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18430/fi-tgl-u2/igt@i915_module_l...@reload.html
Possible fixes
* igt@i915_selftest@live@gem_contexts:
- fi-cml-s: [INCOMPLETE][5] ([i915#2418]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8951/fi-cml-s/igt@i915_selftest@live@gem_contexts.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18430/fi-cml-s/igt@i915_selftest@live@gem_contexts.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2418]: https://gitlab.freedesktop.org/drm/intel/issues/2418
Participating hosts (38 -> 32)
--
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y
fi-byt-clapper
Build changes
-
* Linux: CI_DRM_8951 -> Patchwork_18430
CI-20190529: 20190529
CI_DRM_8951: 5f8c53e35ef01a1d5e97db6005d3c308d3734bac @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5775: 58cb0aea18fa471af43c11ee9f587554721a7815 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_18430: 2b838e80247e21b2c7fb1bdfcae4454a3931d563 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
2b838e80247e drm/i915/pll: Centralize PLL_ENABLE register lookup
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18430/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/pll: Centralize PLL_ENABLE register lookup (rev2)
== Series Details ==
Series: drm/i915/pll: Centralize PLL_ENABLE register lookup (rev2)
URL : https://patchwork.freedesktop.org/series/81150/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
2b838e80247e drm/i915/pll: Centralize PLL_ENABLE register lookup
-:30: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#30: FILE: drivers/gpu/drm/i915/display/intel_dpll_mgr.c:152:
+i915_reg_t intel_combo_pll_enable_reg(struct drm_i915_private *dev_priv,
+ struct intel_shared_dpll *pll)
-:32: CHECK:BRACES: Blank lines aren't necessary after an open brace '{'
#32: FILE: drivers/gpu/drm/i915/display/intel_dpll_mgr.c:154:
+{
+
-:33: WARNING:SUSPECT_CODE_INDENT: suspect code indent for conditional
statements (8, 24)
#33: FILE: drivers/gpu/drm/i915/display/intel_dpll_mgr.c:155:
+ if (IS_ELKHARTLAKE(dev_priv) && (pll->info->id == DPLL_ID_EHL_DPLL4))
+ return MG_PLL_ENABLE(0);
-:33: CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around
'pll->info->id == DPLL_ID_EHL_DPLL4'
#33: FILE: drivers/gpu/drm/i915/display/intel_dpll_mgr.c:155:
+ if (IS_ELKHARTLAKE(dev_priv) && (pll->info->id == DPLL_ID_EHL_DPLL4))
-:38: CHECK:LINE_SPACING: Please don't use multiple blank lines
#38: FILE: drivers/gpu/drm/i915/display/intel_dpll_mgr.c:160:
+
+
-:39: CHECK:BRACES: Blank lines aren't necessary before a close brace '}'
#39: FILE: drivers/gpu/drm/i915/display/intel_dpll_mgr.c:161:
+
+}
total: 0 errors, 1 warnings, 5 checks, 55 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 08/32] drm: i915: fix common struct sg_table related issues
On 2020-08-26 07:32, Marek Szyprowski wrote:
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_map_sg().
struct sg_table is a common structure used for describing a non-contiguous
memory buffer, used commonly in the DRM and graphics subsystems. It
consists of a scatterlist with memory pages and DMA addresses (sgl entry),
as well as the number of scatterlist entries: CPU pages (orig_nents entry)
and DMA mapped pages (nents entry).
It turned out that it was a common mistake to misuse nents and orig_nents
entries, calling DMA-mapping functions with a wrong number of entries or
ignoring the number of mapped entries returned by the dma_map_sg()
function.
This driver creatively uses sg_table->orig_nents to store the size of the
allocated scatterlist and ignores the number of the entries returned by
dma_map_sg function. The sg_table->orig_nents is (mis)used to properly
free the (over)allocated scatterlist.
This patch only introduces the common DMA-mapping wrappers operating
directly on the struct sg_table objects to the dmabuf related functions,
so the other drivers, which might share buffers with i915 could rely on
the properly set nents and orig_nents values.
This one looks mechanical enough :)
Reviewed-by: Robin Murphy
Signed-off-by: Marek Szyprowski
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 11 +++
drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c | 7 +++
2 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index 2679380159fc..8a988592715b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -48,12 +48,9 @@ static struct sg_table *i915_gem_map_dma_buf(struct
dma_buf_attachment *attachme
src = sg_next(src);
}
- if (!dma_map_sg_attrs(attachment->dev,
- st->sgl, st->nents, dir,
- DMA_ATTR_SKIP_CPU_SYNC)) {
- ret = -ENOMEM;
+ ret = dma_map_sgtable(attachment->dev, st, dir, DMA_ATTR_SKIP_CPU_SYNC);
+ if (ret)
goto err_free_sg;
- }
return st;
@@ -73,9 +70,7 @@ static void i915_gem_unmap_dma_buf(struct dma_buf_attachment *attachment,
{
struct drm_i915_gem_object *obj = dma_buf_to_obj(attachment->dmabuf);
- dma_unmap_sg_attrs(attachment->dev,
- sg->sgl, sg->nents, dir,
- DMA_ATTR_SKIP_CPU_SYNC);
+ dma_unmap_sgtable(attachment->dev, sg, dir, DMA_ATTR_SKIP_CPU_SYNC);
sg_free_table(sg);
kfree(sg);
diff --git a/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c b/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
index debaf7b18ab5..be30b27e2926 100644
--- a/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
@@ -28,10 +28,9 @@ static struct sg_table *mock_map_dma_buf(struct
dma_buf_attachment *attachment,
sg = sg_next(sg);
}
- if (!dma_map_sg(attachment->dev, st->sgl, st->nents, dir)) {
- err = -ENOMEM;
+ err = dma_map_sgtable(attachment->dev, st, dir, 0);
+ if (err)
goto err_st;
- }
return st;
@@ -46,7 +45,7 @@ static void mock_unmap_dma_buf(struct dma_buf_attachment *attachment,
struct sg_table *st,
enum dma_data_direction dir)
{
- dma_unmap_sg(attachment->dev, st->sgl, st->nents, dir);
+ dma_unmap_sgtable(attachment->dev, st, dir, 0);
sg_free_table(st);
kfree(st);
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/pll: Centralize PLL_ENABLE register lookup
We currenty check for platform at multiple parts in the driver
to grab the correct PLL. Let us begin to centralize it through a
helper function.
v2: s/intel_get_pll_enable_reg()/intel_combo_pll_enable_reg() (Ville)
Suggested-by: Matt Roper
Cc: Ville Syrjälä
Cc: Matt Roper
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 25 +++
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
index c9013f8f766f..7440836c5e44 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
@@ -147,6 +147,18 @@ void assert_shared_dpll(struct drm_i915_private *dev_priv,
pll->info->name, onoff(state), onoff(cur_state));
}
+static
+i915_reg_t intel_combo_pll_enable_reg(struct drm_i915_private *dev_priv,
+ struct intel_shared_dpll *pll)
+{
+
+ if (IS_ELKHARTLAKE(dev_priv) && (pll->info->id == DPLL_ID_EHL_DPLL4))
+ return MG_PLL_ENABLE(0);
+
+ return CNL_DPLL_ENABLE(pll->info->id);
+
+
+}
/**
* intel_prepare_shared_dpll - call a dpll's prepare hook
* @crtc_state: CRTC, and its state, which has a shared dpll
@@ -3842,12 +3854,7 @@ static bool combo_pll_get_hw_state(struct
drm_i915_private *dev_priv,
struct intel_shared_dpll *pll,
struct intel_dpll_hw_state *hw_state)
{
- i915_reg_t enable_reg = CNL_DPLL_ENABLE(pll->info->id);
-
- if (IS_ELKHARTLAKE(dev_priv) &&
- pll->info->id == DPLL_ID_EHL_DPLL4) {
- enable_reg = MG_PLL_ENABLE(0);
- }
+ i915_reg_t enable_reg = intel_combo_pll_enable_reg(dev_priv, pll);
return icl_pll_get_hw_state(dev_priv, pll, hw_state, enable_reg);
}
@@ -4045,11 +4052,10 @@ static void icl_pll_enable(struct drm_i915_private
*dev_priv,
static void combo_pll_enable(struct drm_i915_private *dev_priv,
struct intel_shared_dpll *pll)
{
- i915_reg_t enable_reg = CNL_DPLL_ENABLE(pll->info->id);
+ i915_reg_t enable_reg = intel_combo_pll_enable_reg(dev_priv, pll);
if (IS_ELKHARTLAKE(dev_priv) &&
pll->info->id == DPLL_ID_EHL_DPLL4) {
- enable_reg = MG_PLL_ENABLE(0);
/*
* We need to disable DC states when this DPLL is enabled.
@@ -4157,11 +4163,10 @@ static void icl_pll_disable(struct drm_i915_private
*dev_priv,
static void combo_pll_disable(struct drm_i915_private *dev_priv,
struct intel_shared_dpll *pll)
{
- i915_reg_t enable_reg = CNL_DPLL_ENABLE(pll->info->id);
+ i915_reg_t enable_reg = intel_combo_pll_enable_reg(dev_priv, pll);
if (IS_ELKHARTLAKE(dev_priv) &&
pll->info->id == DPLL_ID_EHL_DPLL4) {
- enable_reg = MG_PLL_ENABLE(0);
icl_pll_disable(dev_priv, pll, enable_reg);
intel_display_power_put(dev_priv, POWER_DOMAIN_DPLL_DC_OFF,
--
2.25.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/5] drm_dp_cec: add plumbing in preparation for MST support
Super minor nitpicks:
On Tue, 2020-09-01 at 16:22 +1000, Sam McNally wrote:
> From: Hans Verkuil
>
> Signed-off-by: Hans Verkuil
> [sa...@chromium.org:
> - rebased
> - removed polling-related changes
> - moved the calls to drm_dp_cec_(un)set_edid() into the next patch
> ]
> Signed-off-by: Sam McNally
> ---
>
> .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 +-
> drivers/gpu/drm/drm_dp_cec.c | 22 ++-
> drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
> drivers/gpu/drm/nouveau/nouveau_connector.c | 2 +-
> include/drm/drm_dp_helper.h | 6 +++--
> 5 files changed, 19 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> index 461fa4da0a34..6e7075893ec9 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> @@ -419,7 +419,7 @@ void amdgpu_dm_initialize_dp_connector(struct
> amdgpu_display_manager *dm,
>
> drm_dp_aux_init(>dm_dp_aux.aux);
> drm_dp_cec_register_connector(>dm_dp_aux.aux,
> - >base);
> + >base, false);
>
> if (aconnector->base.connector_type == DRM_MODE_CONNECTOR_eDP)
> return;
> diff --git a/drivers/gpu/drm/drm_dp_cec.c b/drivers/gpu/drm/drm_dp_cec.c
> index 3ab2609f9ec7..04ab7b88055c 100644
> --- a/drivers/gpu/drm/drm_dp_cec.c
> +++ b/drivers/gpu/drm/drm_dp_cec.c
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
>
> /*
> * Unfortunately it turns out that we have a chicken-and-egg situation
> @@ -338,8 +339,6 @@ void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const
> struct edid *edid)
> if (aux->cec.adap) {
> if (aux->cec.adap->capabilities == cec_caps &&
> aux->cec.adap->available_log_addrs == num_las) {
> - /* Unchanged, so just set the phys addr */
> - cec_s_phys_addr_from_edid(aux->cec.adap, edid);
> goto unlock;
> }
May as well drop the braces here
> /*
> @@ -364,15 +363,16 @@ void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const
> struct edid *edid)
> if (cec_register_adapter(aux->cec.adap, connector->dev->dev)) {
> cec_delete_adapter(aux->cec.adap);
> aux->cec.adap = NULL;
> - } else {
> - /*
> - * Update the phys addr for the new CEC adapter. When called
> - * from drm_dp_cec_register_connector() edid == NULL, so in
> - * that case the phys addr is just invalidated.
> - */
> - cec_s_phys_addr_from_edid(aux->cec.adap, edid);
> }
> unlock:
> + /*
> + * Update the phys addr for the new CEC adapter. When called
> + * from drm_dp_cec_register_connector() edid == NULL, so in
> + * that case the phys addr is just invalidated.
> + */
> + if (aux->cec.adap && edid) {
> + cec_s_phys_addr_from_edid(aux->cec.adap, edid);
> + }
And here
> mutex_unlock(>cec.lock);
> }
> EXPORT_SYMBOL(drm_dp_cec_set_edid);
> @@ -418,6 +418,7 @@ EXPORT_SYMBOL(drm_dp_cec_unset_edid);
> * drm_dp_cec_register_connector() - register a new connector
> * @aux: DisplayPort AUX channel
> * @connector: drm connector
> + * @is_mst: set to true if this is an MST branch
> *
> * A new connector was registered with associated CEC adapter name and
> * CEC adapter parent device. After registering the name and parent
> @@ -425,12 +426,13 @@ EXPORT_SYMBOL(drm_dp_cec_unset_edid);
> * CEC and to register a CEC adapter if that is the case.
> */
> void drm_dp_cec_register_connector(struct drm_dp_aux *aux,
> -struct drm_connector *connector)
> +struct drm_connector *connector, bool is_mst)
> {
> WARN_ON(aux->cec.adap);
> if (WARN_ON(!aux->transfer))
> return;
> aux->cec.connector = connector;
> + aux->cec.is_mst = is_mst;
Also JFYI, you can also check aux->is_remote, but maybe you've got another
reason for copying this here
Either way:
Reviewed-by: Lyude Paul
...Also, maybe this is just a coincidence - but do I know your name from
somewhere? Perhaps an IRC community from long ago?
> INIT_DELAYED_WORK(>cec.unregister_work,
> drm_dp_cec_unregister_work);
> }
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 82b9de274f65..744cb55572f9 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -6261,7 +6261,7 @@ intel_dp_connector_register(struct drm_connector
> *connector)
> intel_dp->aux.dev = connector->kdev;
> ret = drm_dp_aux_register(_dp->aux);
> if
Re: [Intel-gfx] [PATCH] drm/dp: start using more of the extended receiver caps
On Tue, 01 Sep 2020, Lyude Paul wrote:
> On Tue, 2020-09-01 at 15:32 +0300, Jani Nikula wrote:
>> In the future, we'll be needing more of the extended receiver capability
>> field starting at DPCD address 0x2200. (Specifically, we'll need main
>> link channel coding cap for DP 2.0.) Start using it now to not miss out
>> later on.
>>
>> Cc: Lyude Paul
>> Signed-off-by: Jani Nikula
>>
>> ---
>>
>> I guess this can be merged after the topic branch to drm-misc-next or
>> so, but I'd prefer to have this fairly early on to catch any potential
>> issues.
>> ---
>> drivers/gpu/drm/drm_dp_helper.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/drm_dp_helper.c
>> b/drivers/gpu/drm/drm_dp_helper.c
>> index 1e7c638873c8..3a3c238452df 100644
>> --- a/drivers/gpu/drm/drm_dp_helper.c
>> +++ b/drivers/gpu/drm/drm_dp_helper.c
>> @@ -436,7 +436,7 @@ static u8 drm_dp_downstream_port_count(const u8
>> dpcd[DP_RECEIVER_CAP_SIZE])
>> static int drm_dp_read_extended_dpcd_caps(struct drm_dp_aux *aux,
>>u8 dpcd[DP_RECEIVER_CAP_SIZE])
>> {
>> -u8 dpcd_ext[6];
>> +u8 dpcd_ext[DP_RECEIVER_CAP_SIZE];
>
> Not 100% sure this is right? It's not clear at first glance of the 2.0 spec,
> but
> my assumption would be that on < DP2.0 devices that everything but those
> first 6
> bytes are zeroed out in the extended DPRX field. Since we memcpy() dpcd_ext
> using sizeof(dpcd_ext), we'd potentially end up zeroing out all of the DPCD
> caps
> that comes after those 6 bytes.
Re-reading stuff... AFAICT everything in 0x2200..0x220F should be
valid. They should match what's in 0x..0x000F except for 0x,
0x0001, and 0x0005, for backwards compatibility.
Apparently there are no such backwards compatibility concerns with the
other receiver cap fields then.
But it gives me an uneasy feeling that many places in the spec refer to
0x2200+ even though they should per spec be the same in 0x+.
I guess we can try without the change, and fix later if we hit issues.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/dp: start using more of the extended receiver caps
On Tue, 2020-09-01 at 15:32 +0300, Jani Nikula wrote:
> In the future, we'll be needing more of the extended receiver capability
> field starting at DPCD address 0x2200. (Specifically, we'll need main
> link channel coding cap for DP 2.0.) Start using it now to not miss out
> later on.
>
> Cc: Lyude Paul
> Signed-off-by: Jani Nikula
>
> ---
>
> I guess this can be merged after the topic branch to drm-misc-next or
> so, but I'd prefer to have this fairly early on to catch any potential
> issues.
> ---
> drivers/gpu/drm/drm_dp_helper.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 1e7c638873c8..3a3c238452df 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -436,7 +436,7 @@ static u8 drm_dp_downstream_port_count(const u8
> dpcd[DP_RECEIVER_CAP_SIZE])
> static int drm_dp_read_extended_dpcd_caps(struct drm_dp_aux *aux,
> u8 dpcd[DP_RECEIVER_CAP_SIZE])
> {
> - u8 dpcd_ext[6];
> + u8 dpcd_ext[DP_RECEIVER_CAP_SIZE];
Not 100% sure this is right? It's not clear at first glance of the 2.0 spec, but
my assumption would be that on < DP2.0 devices that everything but those first 6
bytes are zeroed out in the extended DPRX field. Since we memcpy() dpcd_ext
using sizeof(dpcd_ext), we'd potentially end up zeroing out all of the DPCD caps
that comes after those 6 bytes.
> int ret;
>
> /*
--
Sincerely,
Lyude Paul (she/her)
Software Engineer at Red Hat
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/4] drm/i915/display: Ignore IGNORE_PSR2_HW_TRACKING for platforms without sel fetch
On Tue, 2020-09-01 at 09:59 +, Patchwork wrote: > Patch Details > Series: series starting with [1/4] drm/i915/display: Ignore > IGNORE_PSR2_HW_TRACKING for platforms without sel fetch > URL: https://patchwork.freedesktop.org/series/81201/ > State:failure > Details: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18426/index.html > CI Bug Log - changes from CI_DRM_8948_full -> Patchwork_18426_full > Summary > FAILURE > > Serious unknown changes coming with Patchwork_18426_full absolutely need to be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_18426_full, please notify your bug team to allow them > to document this new failure mode, which will reduce false positives in CI. > > Possible new issues > Here are the unknown changes that may have been introduced in > Patchwork_18426_full: > > IGT changes > Possible regressions > igt@runner@aborted: > shard-tglb: NOTRUN -> (FAIL, FAIL, FAIL, FAIL, FAIL, FAIL, FAIL, FAIL, FAIL, > FAIL, FAIL, FAIL, FAIL, FAIL, FAIL, FAIL, FAIL, FAIL, FAIL, FAIL, FAIL, FAIL, > FAIL, FAIL, FAIL) Okay, so it is a valid a state that have CRTC enabled with all planes not visible.Will fix it for next version. > Known issues > Here are the changes found in Patchwork_18426_full that come from known > issues: > > IGT changes > Issues hit > igt@gem_exec_whisper@basic-contexts-all: > > shard-glk: PASS -> TIMEOUT (i915#1958) +2 similar issues > igt@gem_partial_pwrite_pread@reads-display: > > shard-glk: PASS -> FAIL (i915#2261) +1 similar issue > igt@gem_sync@basic-store-all: > > shard-glk: PASS -> FAIL (i915#2356) > igt@i915_selftest@mock@contexts: > > shard-apl: PASS -> INCOMPLETE (i915#1635 / i915#2278) > igt@kms_big_fb@linear-64bpp-rotate-180: > > shard-glk: PASS -> DMESG-FAIL (i915#118 / i915#95) > igt@kms_color@pipe-c-ctm-0-25: > > shard-skl: PASS -> DMESG-WARN (i915#1982) +5 similar issues > igt@kms_flip@plain-flip-ts-check@a-dp1: > > shard-kbl: PASS -> DMESG-WARN (i915#1982) +1 similar issue > igt@kms_frontbuffer_tracking@fbc-suspend: > > shard-kbl: PASS -> DMESG-WARN (i915#180) +3 similar issues > igt@kms_hdr@bpc-switch-dpms: > > shard-skl: PASS -> FAIL (i915#1188) +1 similar issue > igt@kms_plane@plane-panning-bottom-right-pipe-a-planes: > > shard-iclb: PASS -> FAIL (i915#1036) > igt@kms_plane_cursor@pipe-b-primary-size-64: > > shard-apl: PASS -> DMESG-WARN (i915#1635 / i915#1982) > igt@kms_psr@psr2_sprite_mmap_gtt: > > shard-iclb: PASS -> SKIP (fdo#109441) +1 similar issue > igt@kms_setmode@basic: > > shard-kbl: PASS -> FAIL (i915#31) > Possible fixes > igt@gem_exec_gttfill@basic: > > shard-glk: DMESG-WARN (i915#118 / i915#95) -> PASS > igt@gem_exec_reloc@basic-concurrent0: > > shard-skl: TIMEOUT (i915#1958) -> PASS > igt@gem_exec_whisper@basic-fds-forked-all: > > shard-kbl: TIMEOUT (i915#1958) -> PASS > igt@gem_exec_whisper@basic-forked: > > shard-glk: TIMEOUT (i915#1958) -> PASS > igt@gem_exec_whisper@basic-queues-forked: > > shard-skl: DMESG-WARN (i915#1982) -> PASS +8 similar issues > igt@i915_pm_dc@dc6-psr: > > shard-skl: FAIL (i915#454) -> PASS > igt@kms_draw_crc@draw-method-rgb565-blt-xtiled: > > shard-apl: DMESG-WARN (i915#1635 / i915#1982) -> PASS +1 similar issue > igt@kms_plane@plane-panning-bottom-right-pipe-a-planes: > > shard-glk: FAIL (i915#1036) -> PASS > igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes: > > shard-kbl: DMESG-WARN (i915#180) -> PASS +2 similar issues > igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes: > > shard-skl: INCOMPLETE (i915#198) -> PASS > igt@kms_plane_alpha_blend@pipe-a-coverage-7efc: > > shard-skl: FAIL (fdo#108145 / i915#265) -> PASS > igt@kms_plane_scaling@pipe-c-scaler-with-clipping-clamping: > > shard-iclb: DMESG-WARN (i915#1982) -> PASS > igt@kms_psr@psr2_cursor_plane_onoff: > > shard-iclb: SKIP (fdo#109441) -> PASS +1 similar issue > Warnings > igt@kms_flip@flip-vs-expired-vblank@a-edp1: > > shard-skl: DMESG-WARN (i915#1982) -> DMESG-FAIL (i915#1982 / i915#79) > igt@runner@aborted: > > shard-skl: FAIL (i915#1436) -> (FAIL, FAIL) (i915#1436 / i915#1814 / > i915#2029) > Participating hosts (10 -> 10) > No changes in participating hosts > > Build changes > Linux: CI_DRM_8948 -> Patchwork_18426 > CI-20190529: 20190529 > CI_DRM_8948: 4a551ee5aa0f402a647f797437b69af12ce78642 @ > git://anongit.freedesktop.org/gfx-ci/linux > IGT_5774: 2a5db9f60241383272aeec176e1b97b3f487209f @ > git://anongit.freedesktop.org/xorg/app/intel-gpu-tools > Patchwork_18426: 8316e2705e8f88f7a0b59150fe3ce4bb99edc616 @ > git://anongit.freedesktop.org/gfx-ci/linux > piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ > git://anongit.freedesktop.org/piglit > > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Various problems for the Xen for XenGT code and guide.
Hi Mario, Sorry to make you feel uncomfortable. I think it is not setup guide problem, the main reason is the Xen code is very old (We are upgrading GVT-g code on Linux kernel side and we haven’t upgraded the Xen and Qemu source for XenGT for at least 2 years) but your GCC is new (You are using Ubuntu 20.4, the gcc version is 9+). I have a way to workaround it, as below: 1. apt-get install gcc-7 2. ln -fs gcc-7 /usr/bin/gcc Any more problem just let us know! Thanks Terrence From: Mario Marietto Sent: Thursday, August 27, 2020 9:52 PM To: Xu, Terrence ; igv...@lists.01.org; xen-de...@lists.xenproject.org; xen-de...@lists.xen.org; intel-gfx@lists.freedesktop.org; linux-ker...@vger.kernel.org; Li, Susie ; Tian, Kevin ; Lv, Zhiyuan ; Li, Weinan Z ; Downs, Mike Subject: Various problems for the Xen for XenGT code and guide. Hello. I would like to pass the integrated gpu from the host os (ubuntu 20.04) to the windows 10 guest os with xen. This is because xen works great for me,better than qemu-kvm for my specific needs and because I have only two graphic cards. The nvidia rtx 2080 ti that I have already passed to the guest,and the intel UHD 630,that can be duplicated from the host to the guest so that it can be used in both places without interruptions. So I'm trying to build this repository : https://github.com/intel/gvt-linux/wiki/GVTg_Setup_Guide#332-build-qemu--xen-for-xengt I have to say that this guide is totally not very well written. And the code is full of unpatched bugs. It's a month that I'm working on that,trying to fix the bugs that are came out from the 2015 until today. This is not my job. This is my hobby. But,I need to activate the pass through for my integrated GPU so I don't to give up. I'm also very angry with those coders who do not do their job well and with those coders who do not respond to help messages. It is not enough to write good code to be a good programmer. It is also important to keep the documentation updated, to help those who cannot get the code to work. Anyway,I've documented every step that I did to make it work here : https://github.com/intel/gvt-linux/issues/168 right now I'm trying to fix the bug n. 434544,that you can see below. CC util/qemu-error.o /etc/xen/igvtg-xen/tools/qemu-xen-dir/util/qemu-error.c: In function ‘vreport’: /etc/xen/igvtg-xen/tools/qemu-xen-dir/util/qemu-error.c:201:5: error: ‘GTimeVal’ is deprecated: Use 'GDateTime' instead [-Werror=deprecated-declarations] 201 | GTimeVal tv; | ^~~~ In file included from /usr/include/glib-2.0/glib/galloca.h:32, from /usr/include/glib-2.0/glib.h:30, from /etc/xen/igvtg-xen/tools/qemu-xen-dir/include/glib-compat.h:19, from /etc/xen/igvtg-xen/tools/qemu-xen-dir/include/qemu/osdep.h:107, from /etc/xen/igvtg-xen/tools/qemu-xen-dir/util/qemu-error.c:13: /usr/include/glib-2.0/glib/gtypes.h:547:8: note: declared here 547 | struct GTimeVal | ^ /etc/xen/igvtg-xen/tools/qemu-xen-dir/util/qemu-error.c:205:9: error: ‘g_get_current_time’ is deprecated: Use 'g_get_real_time' instead [-Werror=deprecated-declarations] 205 | g_get_current_time(); | ^~ In file included from /usr/include/glib-2.0/glib/giochannel.h:33, from /usr/include/glib-2.0/glib.h:54, from /etc/xen/igvtg-xen/tools/qemu-xen-dir/include/glib-compat.h:19, from /etc/xen/igvtg-xen/tools/qemu-xen-dir/include/qemu/osdep.h:107, from /etc/xen/igvtg-xen/tools/qemu-xen-dir/util/qemu-error.c:13: /usr/include/glib-2.0/glib/gmain.h:679:8: note: declared here 679 | void g_get_current_time (GTimeVal result); | ^~ /etc/xen/igvtg-xen/tools/qemu-xen-dir/util/qemu-error.c:206:9: error: ‘g_time_val_to_iso8601’ is deprecated: Use 'g_date_time_format' instead [-Werror=deprecated-declarations] 206 | timestr = g_time_val_to_iso8601(); | ^~~ In file included from /usr/include/glib-2.0/glib.h:88, from /etc/xen/igvtg-xen/tools/qemu-xen-dir/include/glib-compat.h:19, from /etc/xen/igvtg-xen/tools/qemu-xen-dir/include/qemu/osdep.h:107, from /etc/xen/igvtg-xen/tools/qemu-xen-dir/util/qemu-error.c:13: /usr/include/glib-2.0/glib/gtimer.h:73:10: note: declared here 73 | gchar g_time_val_to_iso8601 (GTimeVal *time) G_GNUC_MALLOC; | ^ cc1: all warnings being treated as errors any help is appreciated. Someone must help me, thanking me for all the efforts I am making to make work a code full of errors. I would also know if I can activate the passthrough of the intel integrated gpu using the precompiled xen-hypervisor package that's on ubuntu. Right now I tried to compile it from scratch because I've thought that it was a necessary step,as described on the guide. But Im not sure on this point. -- Mario. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: fix regression leading to display audio probe failure on GLK
== Series Details ==
Series: drm/i915: fix regression leading to display audio probe failure on GLK
URL : https://patchwork.freedesktop.org/series/81227/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8951 -> Patchwork_18429
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18429/index.html
Known issues
Here are the changes found in Patchwork_18429 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_parallel@engines@contexts:
- fi-apl-guc: [PASS][1] -> [INCOMPLETE][2] ([i915#1635] /
[i915#2398])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8951/fi-apl-guc/igt@gem_exec_parallel@engi...@contexts.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18429/fi-apl-guc/igt@gem_exec_parallel@engi...@contexts.html
* igt@gem_exec_parallel@engines@fds:
- fi-kbl-7500u: [PASS][3] -> [INCOMPLETE][4] ([i915#2398] /
[i915#794])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8951/fi-kbl-7500u/igt@gem_exec_parallel@engi...@fds.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18429/fi-kbl-7500u/igt@gem_exec_parallel@engi...@fds.html
- fi-skl-lmem:[PASS][5] -> [INCOMPLETE][6] ([i915#2398])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8951/fi-skl-lmem/igt@gem_exec_parallel@engi...@fds.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18429/fi-skl-lmem/igt@gem_exec_parallel@engi...@fds.html
* igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1:
- fi-icl-u2: [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) +1 similar
issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8951/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18429/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
* igt@kms_flip@basic-flip-vs-wf_vblank@c-hdmi-a2:
- fi-skl-guc: [PASS][9] -> [DMESG-WARN][10] ([i915#2203])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8951/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18429/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html
Possible fixes
* igt@i915_selftest@live@gem_contexts:
- fi-cml-s: [INCOMPLETE][11] -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8951/fi-cml-s/igt@i915_selftest@live@gem_contexts.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18429/fi-cml-s/igt@i915_selftest@live@gem_contexts.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1635]: https://gitlab.freedesktop.org/drm/intel/issues/1635
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2203]: https://gitlab.freedesktop.org/drm/intel/issues/2203
[i915#2398]: https://gitlab.freedesktop.org/drm/intel/issues/2398
[i915#794]: https://gitlab.freedesktop.org/drm/intel/issues/794
Participating hosts (38 -> 33)
--
Missing(5): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-byt-clapper
Build changes
-
* Linux: CI_DRM_8951 -> Patchwork_18429
CI-20190529: 20190529
CI_DRM_8951: 5f8c53e35ef01a1d5e97db6005d3c308d3734bac @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5775: 58cb0aea18fa471af43c11ee9f587554721a7815 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_18429: 7db2227d72fdf96d49b2fbb535732d0f0d442f87 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
7db2227d72fd drm/i915: fix regression leading to display audio probe failure on
GLK
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18429/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/9] drm/i915: Expose list of clients in sysfs
On 01/09/2020 16:09, Tvrtko Ursulin wrote:
Hi,
On 26/08/2020 02:11, Lucas De Marchi wrote:
Hi,
Any update on this? It now conflicts in a few places so it needs a
rebase.
I don't see any previous email on the topic - what kind of update, where
and how, are you looking for? Rebase against drm-tip so you pull it in?
Rebase against some internal in progress branch?
Clearly you were after an update against drm-tip.. :) Problem here was
no userspace but I can try to respin it.
Regards,
Tvrtko
Regards,
Tvrtko
Lucas De Marchi
On Wed, Apr 15, 2020 at 3:11 AM Tvrtko Ursulin
wrote:
From: Tvrtko Ursulin
Expose a list of clients with open file handles in sysfs.
This will be a basis for a top-like utility showing per-client and per-
engine GPU load.
Currently we only expose each client's pid and name under opaque
numbered
directories in /sys/class/drm/card0/clients/.
For instance:
/sys/class/drm/card0/clients/3/name: Xorg
/sys/class/drm/card0/clients/3/pid: 5664
v2:
Chris Wilson:
* Enclose new members into dedicated structs.
* Protect against failed sysfs registration.
v3:
* sysfs_attr_init.
v4:
* Fix for internal clients.
v5:
* Use cyclic ida for client id. (Chris)
* Do not leak pid reference. (Chris)
* Tidy code with some locals.
v6:
* Use xa_alloc_cyclic to simplify locking. (Chris)
* No need to unregister individial sysfs files. (Chris)
* Rebase on top of fpriv kref.
* Track client closed status and reflect in sysfs.
v7:
* Make drm_client more standalone concept.
v8:
* Simplify sysfs show. (Chris)
* Always track name and pid.
v9:
* Fix cyclic id assignment.
v10:
* No need for a mutex around xa_alloc_cyclic.
* Refactor sysfs into own function.
* Unregister sysfs before freeing pid and name.
* Move clients setup into own function.
v11:
* Call clients init directly from driver init. (Chris)
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/Makefile | 3 +-
drivers/gpu/drm/i915/i915_drm_client.c | 179 +
drivers/gpu/drm/i915/i915_drm_client.h | 64 +
drivers/gpu/drm/i915/i915_drv.c | 3 +
drivers/gpu/drm/i915/i915_drv.h | 5 +
drivers/gpu/drm/i915/i915_gem.c | 25 +++-
drivers/gpu/drm/i915/i915_sysfs.c | 8 ++
7 files changed, 283 insertions(+), 4 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_drm_client.c
create mode 100644 drivers/gpu/drm/i915/i915_drm_client.h
diff --git a/drivers/gpu/drm/i915/Makefile
b/drivers/gpu/drm/i915/Makefile
index 44c506b7e117..b30f3d51c66a 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -33,7 +33,8 @@ subdir-ccflags-y += -I$(srctree)/$(src)
# Please keep these build lists sorted!
# core driver code
-i915-y += i915_drv.o \
+i915-y += i915_drm_client.o \
+ i915_drv.o \
i915_irq.o \
i915_getparam.o \
i915_params.o \
diff --git a/drivers/gpu/drm/i915/i915_drm_client.c
b/drivers/gpu/drm/i915/i915_drm_client.c
new file mode 100644
index ..2067fbcdb795
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_drm_client.c
@@ -0,0 +1,179 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2020 Intel Corporation
+ */
+
+#include
+#include
+#include
+
+#include "i915_drm_client.h"
+#include "i915_gem.h"
+#include "i915_utils.h"
+
+void i915_drm_clients_init(struct i915_drm_clients *clients)
+{
+ clients->next_id = 0;
+ xa_init_flags(>xarray, XA_FLAGS_ALLOC);
+}
+
+static ssize_t
+show_client_name(struct device *kdev, struct device_attribute *attr,
char *buf)
+{
+ struct i915_drm_client *client =
+ container_of(attr, typeof(*client), attr.name);
+
+ return snprintf(buf, PAGE_SIZE,
+ READ_ONCE(client->closed) ? "<%s>" : "%s",
+ client->name);
+}
+
+static ssize_t
+show_client_pid(struct device *kdev, struct device_attribute *attr,
char *buf)
+{
+ struct i915_drm_client *client =
+ container_of(attr, typeof(*client), attr.pid);
+
+ return snprintf(buf, PAGE_SIZE,
+ READ_ONCE(client->closed) ? "<%u>" : "%u",
+ pid_nr(client->pid));
+}
+
+static int
+__client_register_sysfs(struct i915_drm_client *client)
+{
+ const struct {
+ const char *name;
+ struct device_attribute *attr;
+ ssize_t (*show)(struct device *dev,
+ struct device_attribute *attr,
+ char *buf);
+ } files[] = {
+ { "name", >attr.name, show_client_name },
+ { "pid", >attr.pid, show_client_pid },
+ };
+ unsigned int i;
+ char buf[16];
+ int ret;
+
+ ret = scnprintf(buf, sizeof(buf), "%u", client->id);
+ if (ret == sizeof(buf))
+ return -EINVAL;
+
+ client->root =
[Intel-gfx] [PATCH] drm/i915: fix regression leading to display audio probe failure on GLK
In commit 4f0b4352bd26 ("drm/i915: Extract cdclk requirements checking
to separate function") the order of force_min_cdclk_changed check and
intel_modeset_checks(), was reversed. This broke the mechanism to
immediately force a new CDCLK minimum, and lead to driver probe
errors for display audio on GLK platform with 5.9-rc1 kernel. Fix
the issue by moving intel_modeset_checks() call later.
Fixes: 4f0b4352bd26 ("drm/i915: Extract cdclk requirements checking to separate
function)"
BugLink: https://github.com/thesofproject/linux/issues/2410
Signed-off-by: Kai Vehmanen
---
drivers/gpu/drm/i915/display/intel_display.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 7d50b7177d40..8caeed23037c 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -15009,12 +15009,6 @@ static int intel_atomic_check(struct drm_device *dev,
if (dev_priv->wm.distrust_bios_wm)
any_ms = true;
- if (any_ms) {
- ret = intel_modeset_checks(state);
- if (ret)
- goto fail;
- }
-
intel_fbc_choose_crtc(dev_priv, state);
ret = calc_watermark_data(state);
if (ret)
@@ -15029,6 +15023,10 @@ static int intel_atomic_check(struct drm_device *dev,
goto fail;
if (any_ms) {
+ ret = intel_modeset_checks(state);
+ if (ret)
+ goto fail;
+
ret = intel_modeset_calc_cdclk(state);
if (ret)
return ret;
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/9] drm/i915: Expose list of clients in sysfs
Hi,
On 26/08/2020 02:11, Lucas De Marchi wrote:
Hi,
Any update on this? It now conflicts in a few places so it needs a rebase.
I don't see any previous email on the topic - what kind of update, where
and how, are you looking for? Rebase against drm-tip so you pull it in?
Rebase against some internal in progress branch?
Regards,
Tvrtko
Lucas De Marchi
On Wed, Apr 15, 2020 at 3:11 AM Tvrtko Ursulin
wrote:
From: Tvrtko Ursulin
Expose a list of clients with open file handles in sysfs.
This will be a basis for a top-like utility showing per-client and per-
engine GPU load.
Currently we only expose each client's pid and name under opaque numbered
directories in /sys/class/drm/card0/clients/.
For instance:
/sys/class/drm/card0/clients/3/name: Xorg
/sys/class/drm/card0/clients/3/pid: 5664
v2:
Chris Wilson:
* Enclose new members into dedicated structs.
* Protect against failed sysfs registration.
v3:
* sysfs_attr_init.
v4:
* Fix for internal clients.
v5:
* Use cyclic ida for client id. (Chris)
* Do not leak pid reference. (Chris)
* Tidy code with some locals.
v6:
* Use xa_alloc_cyclic to simplify locking. (Chris)
* No need to unregister individial sysfs files. (Chris)
* Rebase on top of fpriv kref.
* Track client closed status and reflect in sysfs.
v7:
* Make drm_client more standalone concept.
v8:
* Simplify sysfs show. (Chris)
* Always track name and pid.
v9:
* Fix cyclic id assignment.
v10:
* No need for a mutex around xa_alloc_cyclic.
* Refactor sysfs into own function.
* Unregister sysfs before freeing pid and name.
* Move clients setup into own function.
v11:
* Call clients init directly from driver init. (Chris)
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/Makefile | 3 +-
drivers/gpu/drm/i915/i915_drm_client.c | 179 +
drivers/gpu/drm/i915/i915_drm_client.h | 64 +
drivers/gpu/drm/i915/i915_drv.c| 3 +
drivers/gpu/drm/i915/i915_drv.h| 5 +
drivers/gpu/drm/i915/i915_gem.c| 25 +++-
drivers/gpu/drm/i915/i915_sysfs.c | 8 ++
7 files changed, 283 insertions(+), 4 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_drm_client.c
create mode 100644 drivers/gpu/drm/i915/i915_drm_client.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 44c506b7e117..b30f3d51c66a 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -33,7 +33,8 @@ subdir-ccflags-y += -I$(srctree)/$(src)
# Please keep these build lists sorted!
# core driver code
-i915-y += i915_drv.o \
+i915-y += i915_drm_client.o \
+ i915_drv.o \
i915_irq.o \
i915_getparam.o \
i915_params.o \
diff --git a/drivers/gpu/drm/i915/i915_drm_client.c
b/drivers/gpu/drm/i915/i915_drm_client.c
new file mode 100644
index ..2067fbcdb795
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_drm_client.c
@@ -0,0 +1,179 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2020 Intel Corporation
+ */
+
+#include
+#include
+#include
+
+#include "i915_drm_client.h"
+#include "i915_gem.h"
+#include "i915_utils.h"
+
+void i915_drm_clients_init(struct i915_drm_clients *clients)
+{
+ clients->next_id = 0;
+ xa_init_flags(>xarray, XA_FLAGS_ALLOC);
+}
+
+static ssize_t
+show_client_name(struct device *kdev, struct device_attribute *attr, char *buf)
+{
+ struct i915_drm_client *client =
+ container_of(attr, typeof(*client), attr.name);
+
+ return snprintf(buf, PAGE_SIZE,
+ READ_ONCE(client->closed) ? "<%s>" : "%s",
+ client->name);
+}
+
+static ssize_t
+show_client_pid(struct device *kdev, struct device_attribute *attr, char *buf)
+{
+ struct i915_drm_client *client =
+ container_of(attr, typeof(*client), attr.pid);
+
+ return snprintf(buf, PAGE_SIZE,
+ READ_ONCE(client->closed) ? "<%u>" : "%u",
+ pid_nr(client->pid));
+}
+
+static int
+__client_register_sysfs(struct i915_drm_client *client)
+{
+ const struct {
+ const char *name;
+ struct device_attribute *attr;
+ ssize_t (*show)(struct device *dev,
+ struct device_attribute *attr,
+ char *buf);
+ } files[] = {
+ { "name", >attr.name, show_client_name },
+ { "pid", >attr.pid, show_client_pid },
+ };
+ unsigned int i;
+ char buf[16];
+ int ret;
+
+ ret = scnprintf(buf, sizeof(buf), "%u", client->id);
+ if (ret == sizeof(buf))
+ return -EINVAL;
+
+ client->root = kobject_create_and_add(buf, client->clients->root);
+ if (!client->root)
+ return -ENOMEM;
+
+ for (i = 0; i < ARRAY_SIZE(files); i++) {
+ struct device_attribute *attr =
Re: [Intel-gfx] [RFC] drm/i915/hdcp: Gen12 HDCP 1.4 support over DP MST
On Tue, Sep 1, 2020 at 8:22 AM Anshuman Gupta wrote:
>
Hi Anshuman,
Thank you for sending this along! I have a few comments below.
> Gen12 has measure changes with respect to HDCP display
> engine instaces lies in Trascoder insead of DDI as in Gen11.
*instances
*transcoder
*instead
>
> This requires hdcp driver to use mst_master_transcoder for link
> authentication and stream trascoder for stream encryption
*transcoder
> separately.
>
> It also requires to validate the stream encryption status
> in HDCP_STATUS_{TRANSCODER,PORT} driving that link register.
>
> There is also some changes over existing HDCP 1.4 DP MST Gen11
> implementation, related to Multistream HDCP Select bit in
> TRANS_DDI_FUNC_CTL need to be required with respect to B.Spec
> Documentation.
>
> Cc: Ramalingam C
> Signed-off-by: Anshuman Gupta
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 12 +--
> drivers/gpu/drm/i915/display/intel_ddi.h | 6 +-
> .../drm/i915/display/intel_display_types.h| 9 +++
> drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 73 ---
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 4 +-
> drivers/gpu/drm/i915/display/intel_hdcp.c | 35 ++---
> drivers/gpu/drm/i915/display/intel_hdcp.h | 4 +-
> drivers/gpu/drm/i915/display/intel_hdmi.c | 16 ++--
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> 9 files changed, 121 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index a2b7dcf84430..5d6e4fd7bccd 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -1849,9 +1849,9 @@ void intel_ddi_disable_transcoder_func(const struct
> intel_crtc_state *crtc_state
> }
> }
>
> -int intel_ddi_toggle_hdcp_signalling(struct intel_encoder *intel_encoder,
> -enum transcoder cpu_transcoder,
> -bool enable)
> +int intel_ddi_toggle_hdcp_bits(struct intel_encoder *intel_encoder,
> + enum transcoder cpu_transcoder,
> + bool enable, u32 hdcp_mask)
> {
> struct drm_device *dev = intel_encoder->base.dev;
> struct drm_i915_private *dev_priv = to_i915(dev);
> @@ -1866,9 +1866,9 @@ int intel_ddi_toggle_hdcp_signalling(struct
> intel_encoder *intel_encoder,
>
> tmp = intel_de_read(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder));
> if (enable)
> - tmp |= TRANS_DDI_HDCP_SIGNALLING;
> + tmp |= hdcp_mask;
> else
> - tmp &= ~TRANS_DDI_HDCP_SIGNALLING;
> + tmp &= ~hdcp_mask;
> intel_de_write(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder), tmp);
> intel_display_power_put(dev_priv, intel_encoder->power_domain,
> wakeref);
> return ret;
> @@ -3967,7 +3967,7 @@ static void intel_enable_ddi(struct intel_atomic_state
> *state,
> if (conn_state->content_protection ==
> DRM_MODE_CONTENT_PROTECTION_DESIRED)
> intel_hdcp_enable(to_intel_connector(conn_state->connector),
> - crtc_state->cpu_transcoder,
> + crtc_state,
> (u8)conn_state->hdcp_content_type);
> }
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.h
> b/drivers/gpu/drm/i915/display/intel_ddi.h
> index f5fb62fc9400..69d9e495992c 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.h
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.h
> @@ -43,9 +43,9 @@ void intel_ddi_compute_min_voltage_level(struct
> drm_i915_private *dev_priv,
> struct intel_crtc_state *crtc_state);
> u32 bxt_signal_levels(struct intel_dp *intel_dp);
> u32 ddi_signal_levels(struct intel_dp *intel_dp);
> -int intel_ddi_toggle_hdcp_signalling(struct intel_encoder *intel_encoder,
> -enum transcoder cpu_transcoder,
> -bool enable);
> +int intel_ddi_toggle_hdcp_bits(struct intel_encoder *intel_encoder,
> + enum transcoder cpu_transcoder,
> + bool enable, u32 hdcp_mask);
> void icl_sanitize_encoder_pll_mapping(struct intel_encoder *encoder);
>
> #endif /* __INTEL_DDI_H__ */
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 413b60337a0b..dc71ee4d314a 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -317,6 +317,13 @@ struct intel_hdcp_shim {
> enum transcoder cpu_transcoder,
> bool enable);
>
> + /* Select/Deselect HDCP stream on the port DP MST Transport Link */
> + int (*toggle_select_hdcp)(struct intel_digital_port
Re: [Intel-gfx] [PATCH 1/2] drm/i915/opregion: add support for mailbox #5 EDID
On Mon, 31 Aug 2020, Jani Nikula wrote:
> On Mon, 31 Aug 2020, Ville Syrjälä wrote:
>> On Fri, Aug 28, 2020 at 09:19:40AM +0300, Jani Nikula wrote:
>>> The ACPI OpRegion Mailbox #5 ASLE extension may contain an EDID to be
>>> used for the embedded display. Add support for using it via the EDID
>>> override mechanism.
>>
>> Abusing the override for this feels a bit odd.
>
> It's the least intrusive way to make this work across the drm and driver
> EDID code that I could think of.
>
> BR,
> Jani.
>
>
>>
>> Also I have a vague recollection that there was perhaps some
>> linkage between the mailbox and the ACPI _DDC stuff:
>> git://github.com/vsyrjala/linux.git acpi_edid
Only looked at this now. The patch at hand is for actually overriding
the EDID from the panel, because the panel EDID is readable but bogus. I
have no idea how the ACPI _DDC stuff would work in this case. Would it
return the EDID from the panel or from mailbox #5 or something
completely different? Who knows.
Using drm_do_get_edid() would of course be doable for reading mailbox #5
directly as well, but you'd have to make that the "primary" method and
fall back to the usual drm_get_edid(). Note that this completely
prevents you from ever reading the actual panel EDID. Using
edid_override lets you get at the panel EDID too.
BR,
Jani.
>>
>>>
>>> Note that the override EDID may be later reset or changed via debugfs,
>>> as usual.
>>>
>>> Cc: Uma Shankar
>>> Signed-off-by: Jani Nikula
>>> ---
>>> drivers/gpu/drm/i915/display/intel_opregion.c | 46 ++-
>>> drivers/gpu/drm/i915/display/intel_opregion.h | 8
>>> 2 files changed, 53 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/display/intel_opregion.c
>>> b/drivers/gpu/drm/i915/display/intel_opregion.c
>>> index de995362f428..13485969fafa 100644
>>> --- a/drivers/gpu/drm/i915/display/intel_opregion.c
>>> +++ b/drivers/gpu/drm/i915/display/intel_opregion.c
>>> @@ -196,6 +196,8 @@ struct opregion_asle_ext {
>>> #define ASLE_IUER_WINDOWS_BTN (1 << 1)
>>> #define ASLE_IUER_POWER_BTN(1 << 0)
>>>
>>> +#define ASLE_PHED_EDID_VALID_MASK 0x3
>>> +
>>> /* Software System Control Interrupt (SWSCI) */
>>> #define SWSCI_SCIC_INDICATOR (1 << 0)
>>> #define SWSCI_SCIC_MAIN_FUNCTION_SHIFT 1
>>> @@ -909,8 +911,10 @@ int intel_opregion_setup(struct drm_i915_private
>>> *dev_priv)
>>> opregion->asle->ardy = ASLE_ARDY_NOT_READY;
>>> }
>>>
>>> - if (mboxes & MBOX_ASLE_EXT)
>>> + if (mboxes & MBOX_ASLE_EXT) {
>>> drm_dbg(_priv->drm, "ASLE extension supported\n");
>>> + opregion->asle_ext = base + OPREGION_ASLE_EXT_OFFSET;
>>> + }
>>>
>>> if (intel_load_vbt_firmware(dev_priv) == 0)
>>> goto out;
>>> @@ -1041,6 +1045,45 @@ intel_opregion_get_panel_type(struct
>>> drm_i915_private *dev_priv)
>>> return ret - 1;
>>> }
>>>
>>> +void intel_opregion_edid_override(struct intel_connector *intel_connector)
>>> +{
>>> + struct drm_connector *connector = _connector->base;
>>> + struct drm_i915_private *i915 = to_i915(connector->dev);
>>> + struct intel_opregion *opregion = >opregion;
>>> + const void *in_edid;
>>> + const struct edid *edid;
>>> + int len, ret;
>>> +
>>> + if (!opregion->asle_ext)
>>> + return;
>>> +
>>> + in_edid = opregion->asle_ext->bddc;
>>> +
>>> + /* Validity corresponds to number of 128-byte blocks */
>>> + len = (opregion->asle_ext->phed & ASLE_PHED_EDID_VALID_MASK) * 128;
>>> + if (!len || !memchr_inv(in_edid, 0, len))
>>> + return;
>>> +
>>> + edid = in_edid;
>>> +
>>> + /*
>>> +* FIXME: Might also check drm_edid_is_valid(edid) here but that
>>> +* requires mutable edid.
>>> +*/
>>> + if (len < EDID_LENGTH * (1 + edid->extensions)) {
>>> + drm_dbg_kms(>drm, "Invalid EDID in ACPI OpRegion (Mailbox
>>> #5)\n");
>>> + return;
>>> + }
>>> +
>>> + connector->override_edid = false;
>>> + ret = drm_connector_update_edid_property(connector, edid);
>>> + if (ret)
>>> + return;
>>> +
>>> + drm_dbg_kms(>drm, "Using OpRegion EDID for [CONNECTOR:%d:%s]\n",
>>> + connector->base.id, connector->name);
>>> +}
>>> +
>>> void intel_opregion_register(struct drm_i915_private *i915)
>>> {
>>> struct intel_opregion *opregion = >opregion;
>>> @@ -1131,6 +1174,7 @@ void intel_opregion_unregister(struct
>>> drm_i915_private *i915)
>>> opregion->acpi = NULL;
>>> opregion->swsci = NULL;
>>> opregion->asle = NULL;
>>> + opregion->asle_ext = NULL;
>>> opregion->vbt = NULL;
>>> opregion->lid_state = NULL;
>>> }
>>> diff --git a/drivers/gpu/drm/i915/display/intel_opregion.h
>>> b/drivers/gpu/drm/i915/display/intel_opregion.h
>>> index 4aa68ffbd30e..b407a0744c40 100644
>>> --- a/drivers/gpu/drm/i915/display/intel_opregion.h
>>> +++ b/drivers/gpu/drm/i915/display/intel_opregion.h
>>> @@ -29,12 +29,14 @@
>>>
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/dp: start using more of the extended receiver caps
== Series Details == Series: drm/dp: start using more of the extended receiver caps URL : https://patchwork.freedesktop.org/series/81223/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8951 -> Patchwork_18428 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18428 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18428, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18428/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_18428: ### IGT changes ### Possible regressions * igt@i915_selftest@live@gem_contexts: - fi-cfl-8109u: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8951/fi-cfl-8109u/igt@i915_selftest@live@gem_contexts.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18428/fi-cfl-8109u/igt@i915_selftest@live@gem_contexts.html Known issues Here are the changes found in Patchwork_18428 that come from known issues: ### IGT changes ### Issues hit * igt@i915_pm_rpm@basic-pci-d3-state: - fi-bsw-kefka: [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8951/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18428/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-byt-j1900: [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8951/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18428/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html - fi-icl-u2: [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8951/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18428/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html Possible fixes * igt@i915_selftest@live@execlists: - fi-icl-y: [INCOMPLETE][9] ([i915#2276]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8951/fi-icl-y/igt@i915_selftest@l...@execlists.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18428/fi-icl-y/igt@i915_selftest@l...@execlists.html * igt@i915_selftest@live@gem_contexts: - fi-cml-s: [INCOMPLETE][11] -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8951/fi-cml-s/igt@i915_selftest@live@gem_contexts.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18428/fi-cml-s/igt@i915_selftest@live@gem_contexts.html Warnings * igt@i915_pm_rpm@module-reload: - fi-kbl-guc: [DMESG-WARN][13] ([i915#2203]) -> [DMESG-FAIL][14] ([i915#2203]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8951/fi-kbl-guc/igt@i915_pm_...@module-reload.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18428/fi-kbl-guc/igt@i915_pm_...@module-reload.html [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982 [i915#2203]: https://gitlab.freedesktop.org/drm/intel/issues/2203 [i915#2276]: https://gitlab.freedesktop.org/drm/intel/issues/2276 Participating hosts (38 -> 33) -- Missing(5): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-byt-clapper Build changes - * Linux: CI_DRM_8951 -> Patchwork_18428 CI-20190529: 20190529 CI_DRM_8951: 5f8c53e35ef01a1d5e97db6005d3c308d3734bac @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5775: 58cb0aea18fa471af43c11ee9f587554721a7815 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_18428: 62d31449302e19443041547501eb72010c72d679 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 62d31449302e drm/dp: start using more of the extended receiver caps == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18428/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/hdcp: Gen12 HDCP 1.4 support over DP MST
== Series Details ==
Series: drm/i915/hdcp: Gen12 HDCP 1.4 support over DP MST
URL : https://patchwork.freedesktop.org/series/81222/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
DESCEND objtool
CHK include/generated/compile.h
CC [M] drivers/gpu/drm/i915/display/intel_hdcp.o
drivers/gpu/drm/i915/display/intel_hdcp.c: In function ‘_intel_hdcp_disable’:
drivers/gpu/drm/i915/display/intel_hdcp.c:805:6: error: ‘intel_dig_port’
undeclared (first use in this function); did you mean ‘intel_digital_port’?
if (intel_dig_port->num_hdcp_streams > 0) {
^~
intel_digital_port
drivers/gpu/drm/i915/display/intel_hdcp.c:805:6: note: each undeclared
identifier is reported only once for each function it appears in
scripts/Makefile.build:283: recipe for target
'drivers/gpu/drm/i915/display/intel_hdcp.o' failed
make[4]: *** [drivers/gpu/drm/i915/display/intel_hdcp.o] Error 1
scripts/Makefile.build:500: recipe for target 'drivers/gpu/drm/i915' failed
make[3]: *** [drivers/gpu/drm/i915] Error 2
scripts/Makefile.build:500: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:500: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
Makefile:1788: recipe for target 'drivers' failed
make: *** [drivers] Error 2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/dp: start using more of the extended receiver caps
In the future, we'll be needing more of the extended receiver capability
field starting at DPCD address 0x2200. (Specifically, we'll need main
link channel coding cap for DP 2.0.) Start using it now to not miss out
later on.
Cc: Lyude Paul
Signed-off-by: Jani Nikula
---
I guess this can be merged after the topic branch to drm-misc-next or
so, but I'd prefer to have this fairly early on to catch any potential
issues.
---
drivers/gpu/drm/drm_dp_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 1e7c638873c8..3a3c238452df 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -436,7 +436,7 @@ static u8 drm_dp_downstream_port_count(const u8
dpcd[DP_RECEIVER_CAP_SIZE])
static int drm_dp_read_extended_dpcd_caps(struct drm_dp_aux *aux,
u8 dpcd[DP_RECEIVER_CAP_SIZE])
{
- u8 dpcd_ext[6];
+ u8 dpcd_ext[DP_RECEIVER_CAP_SIZE];
int ret;
/*
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC] drm/i915/hdcp: Gen12 HDCP 1.4 support over DP MST
Gen12 has measure changes with respect to HDCP display
engine instaces lies in Trascoder insead of DDI as in Gen11.
This requires hdcp driver to use mst_master_transcoder for link
authentication and stream trascoder for stream encryption
separately.
It also requires to validate the stream encryption status
in HDCP_STATUS_{TRANSCODER,PORT} driving that link register.
There is also some changes over existing HDCP 1.4 DP MST Gen11
implementation, related to Multistream HDCP Select bit in
TRANS_DDI_FUNC_CTL need to be required with respect to B.Spec
Documentation.
Cc: Ramalingam C
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_ddi.c | 12 +--
drivers/gpu/drm/i915/display/intel_ddi.h | 6 +-
.../drm/i915/display/intel_display_types.h| 9 +++
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 73 ---
drivers/gpu/drm/i915/display/intel_dp_mst.c | 4 +-
drivers/gpu/drm/i915/display/intel_hdcp.c | 35 ++---
drivers/gpu/drm/i915/display/intel_hdcp.h | 4 +-
drivers/gpu/drm/i915/display/intel_hdmi.c | 16 ++--
drivers/gpu/drm/i915/i915_reg.h | 1 +
9 files changed, 121 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index a2b7dcf84430..5d6e4fd7bccd 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -1849,9 +1849,9 @@ void intel_ddi_disable_transcoder_func(const struct
intel_crtc_state *crtc_state
}
}
-int intel_ddi_toggle_hdcp_signalling(struct intel_encoder *intel_encoder,
-enum transcoder cpu_transcoder,
-bool enable)
+int intel_ddi_toggle_hdcp_bits(struct intel_encoder *intel_encoder,
+ enum transcoder cpu_transcoder,
+ bool enable, u32 hdcp_mask)
{
struct drm_device *dev = intel_encoder->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -1866,9 +1866,9 @@ int intel_ddi_toggle_hdcp_signalling(struct intel_encoder
*intel_encoder,
tmp = intel_de_read(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder));
if (enable)
- tmp |= TRANS_DDI_HDCP_SIGNALLING;
+ tmp |= hdcp_mask;
else
- tmp &= ~TRANS_DDI_HDCP_SIGNALLING;
+ tmp &= ~hdcp_mask;
intel_de_write(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder), tmp);
intel_display_power_put(dev_priv, intel_encoder->power_domain, wakeref);
return ret;
@@ -3967,7 +3967,7 @@ static void intel_enable_ddi(struct intel_atomic_state
*state,
if (conn_state->content_protection ==
DRM_MODE_CONTENT_PROTECTION_DESIRED)
intel_hdcp_enable(to_intel_connector(conn_state->connector),
- crtc_state->cpu_transcoder,
+ crtc_state,
(u8)conn_state->hdcp_content_type);
}
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.h
b/drivers/gpu/drm/i915/display/intel_ddi.h
index f5fb62fc9400..69d9e495992c 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.h
+++ b/drivers/gpu/drm/i915/display/intel_ddi.h
@@ -43,9 +43,9 @@ void intel_ddi_compute_min_voltage_level(struct
drm_i915_private *dev_priv,
struct intel_crtc_state *crtc_state);
u32 bxt_signal_levels(struct intel_dp *intel_dp);
u32 ddi_signal_levels(struct intel_dp *intel_dp);
-int intel_ddi_toggle_hdcp_signalling(struct intel_encoder *intel_encoder,
-enum transcoder cpu_transcoder,
-bool enable);
+int intel_ddi_toggle_hdcp_bits(struct intel_encoder *intel_encoder,
+ enum transcoder cpu_transcoder,
+ bool enable, u32 hdcp_mask);
void icl_sanitize_encoder_pll_mapping(struct intel_encoder *encoder);
#endif /* __INTEL_DDI_H__ */
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 413b60337a0b..dc71ee4d314a 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -317,6 +317,13 @@ struct intel_hdcp_shim {
enum transcoder cpu_transcoder,
bool enable);
+ /* Select/Deselect HDCP stream on the port DP MST Transport Link */
+ int (*toggle_select_hdcp)(struct intel_digital_port *intel_dig_port,
+ bool enable);
+
+ /* Enable HDCP stream encyption on DP MST Transport Link */
+ int (*stream_encryption)(struct intel_digital_port *intel_dig_port);
+
/* Ensures the link is still protected */
bool (*check_link)(struct intel_digital_port *dig_port,
struct intel_connector
Re: [Intel-gfx] 5.9-rc1: graphics regression moved from -next to mainline
Still (rc3) doesn't work without the three reverts. I'm not sure how to proceed, I cannot capture any oops, and see nothing obvious in any logs. -- Hilsen Harald ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 1/7] drm/i915: Add enable/disable flip done and flip done handler
On Fri, Aug 07, 2020 at 03:05:45PM +0530, Karthik B S wrote:
> Add enable/disable flip done functions and the flip done handler
> function which handles the flip done interrupt.
>
> Enable the flip done interrupt in IER.
>
> Enable flip done function is called before writing the
> surface address register as the write to this register triggers
> the flip done interrupt
>
> Flip done handler is used to send the page flip event as soon as the
> surface address is written as per the requirement of async flips.
> The interrupt is disabled after the event is sent.
>
> v2: -Change function name from icl_* to skl_* (Paulo)
> -Move flip handler to this patch (Paulo)
> -Remove vblank_put() (Paulo)
> -Enable flip done interrupt for gen9+ only (Paulo)
> -Enable flip done interrupt in power_well_post_enable hook (Paulo)
> -Removed the event check in flip done handler to handle async
> flips without pageflip events.
>
> v3: -Move skl_disable_flip_done out of interrupt handler (Paulo)
> -Make the pending vblank event NULL in the beginning of
> flip_done_handler to remove sporadic WARN_ON that is seen.
>
> v4: -Calculate timestamps using flip done time stamp and current
> timestamp for async flips (Ville)
>
> v5: -Fix the sparse warning by making the function 'g4x_get_flip_counter'
> static.(Reported-by: kernel test robot )
> -Fix the typo in commit message.
>
> v6: -Revert back to old time stamping code.
> -Remove the break while calling skl_enable_flip_done. (Paulo)
>
> Signed-off-by: Karthik B S
> Signed-off-by: Vandita Kulkarni
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 8 +++
> drivers/gpu/drm/i915/i915_irq.c | 52
> drivers/gpu/drm/i915/i915_irq.h | 2 +
> 3 files changed, 62 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 522c772a2111..1ac2e6f27597 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -15562,6 +15562,11 @@ static void intel_atomic_commit_tail(struct
> intel_atomic_state *state)
>
> intel_dbuf_pre_plane_update(state);
>
> + for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
> + if (new_crtc_state->uapi.async_flip)
> + skl_enable_flip_done(>base);
> + }
> +
> /* Now enable the clocks, plane, pipe, and connectors that we set up. */
> dev_priv->display.commit_modeset_enables(state);
>
> @@ -15583,6 +15588,9 @@ static void intel_atomic_commit_tail(struct
> intel_atomic_state *state)
> drm_atomic_helper_wait_for_flip_done(dev, >base);
>
> for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
> + if (new_crtc_state->uapi.async_flip)
> + skl_disable_flip_done(>base);
> +
> if (new_crtc_state->hw.active &&
> !needs_modeset(new_crtc_state) &&
> !new_crtc_state->preload_luts &&
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index f113fe44572b..6cc129b031d3 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1296,6 +1296,23 @@ display_pipe_crc_irq_handler(struct drm_i915_private
> *dev_priv,
>u32 crc4) {}
> #endif
>
> +static void flip_done_handler(struct drm_i915_private *dev_priv,
> + unsigned int pipe)
> +{
> + struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
> + struct drm_crtc_state *crtc_state = crtc->base.state;
> + struct drm_pending_vblank_event *e = crtc_state->event;
> + struct drm_device *dev = _priv->drm;
> + unsigned long irqflags;
> +
> + spin_lock_irqsave(>event_lock, irqflags);
> +
> + crtc_state->event = NULL;
> +
> + drm_crtc_send_vblank_event(>base, e);
The timestamp is going to be wrong here. We should perhaps just sample
the current time+frame counter here.
> +
> + spin_unlock_irqrestore(>event_lock, irqflags);
> +}
>
> static void hsw_pipe_crc_irq_handler(struct drm_i915_private *dev_priv,
>enum pipe pipe)
> @@ -2390,6 +2407,9 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv,
> u32 master_ctl)
> if (iir & GEN8_PIPE_VBLANK)
> intel_handle_vblank(dev_priv, pipe);
>
> + if (iir & GEN9_PIPE_PLANE1_FLIP_DONE)
> + flip_done_handler(dev_priv, pipe);
> +
> if (iir & GEN8_PIPE_CDCLK_CRC_DONE)
> hsw_pipe_crc_irq_handler(dev_priv, pipe);
>
> @@ -2711,6 +2731,19 @@ int bdw_enable_vblank(struct drm_crtc *crtc)
> return 0;
> }
>
> +void skl_enable_flip_done(struct drm_crtc *crtc)
> +{
> + struct drm_i915_private *dev_priv = to_i915(crtc->dev);
> + enum pipe pipe =
Re: [Intel-gfx] [PATCH v6 5/7] drm/i915: Add dedicated plane hook for async flip case
On Fri, Aug 07, 2020 at 03:05:49PM +0530, Karthik B S wrote:
> This hook is added to avoid writing other plane registers in case of
> async flips, so that we do not write the double buffered registers
> during async surface address update.
>
> Signed-off-by: Karthik B S
> Signed-off-by: Vandita Kulkarni
> ---
> drivers/gpu/drm/i915/display/intel_sprite.c | 25 +
> 1 file changed, 25 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
> b/drivers/gpu/drm/i915/display/intel_sprite.c
> index 2b2d96c59d7f..1c03546a4d2a 100644
> --- a/drivers/gpu/drm/i915/display/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/display/intel_sprite.c
> @@ -609,6 +609,24 @@ icl_program_input_csc(struct intel_plane *plane,
> PLANE_INPUT_CSC_POSTOFF(pipe, plane_id, 2), 0x0);
> }
>
> +static void
> +skl_program_async_surface_address(struct drm_i915_private *dev_priv,
> + const struct intel_plane_state *plane_state,
> + enum pipe pipe, enum plane_id plane_id,
> + u32 surf_addr)
> +{
> + unsigned long irqflags;
> + u32 plane_ctl = plane_state->ctl;
Need the bits from skl_plane_ctl_crtc() too.
> +
> + spin_lock_irqsave(_priv->uncore.lock, irqflags);
> +
> + intel_de_write_fw(dev_priv, PLANE_CTL(pipe, plane_id), plane_ctl);
> + intel_de_write_fw(dev_priv, PLANE_SURF(pipe, plane_id),
> + intel_plane_ggtt_offset(plane_state) + surf_addr);
> +
> + spin_unlock_irqrestore(_priv->uncore.lock, irqflags);
> +}
> +
> static void
> skl_program_plane(struct intel_plane *plane,
> const struct intel_crtc_state *crtc_state,
> @@ -637,6 +655,13 @@ skl_program_plane(struct intel_plane *plane,
> u32 keymsk, keymax;
> u32 plane_ctl = plane_state->ctl;
>
> + /* During Async flip, no other updates are allowed */
> + if (crtc_state->uapi.async_flip) {
> + skl_program_async_surface_address(dev_priv, plane_state,
> + pipe, plane_id, surf_addr);
> + return;
> + }
I'd suggest adding a vfunc for this. Should be able to call it from
intel_update_plane(). That way we don't need to patch it into each
and every .update_plane() implementation.
> +
> plane_ctl |= skl_plane_ctl_crtc(crtc_state);
>
> if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
> --
> 2.22.0
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 4/7] drm/i915: Do not call drm_crtc_arm_vblank_event in async flips
On Fri, Aug 07, 2020 at 03:05:48PM +0530, Karthik B S wrote:
> Since the flip done event will be sent in the flip_done_handler,
> no need to add the event to the list and delay it for later.
>
> v2: -Moved the async check above vblank_get as it
> was causing issues for PSR.
>
> v3: -No need to wait for vblank to pass, as this wait was causing a
> 16ms delay once every few flips.
>
> v4: -Rebased.
>
> v5: -Rebased.
>
> v6: -Rebased.
>
> Signed-off-by: Karthik B S
> Signed-off-by: Vandita Kulkarni
> ---
> drivers/gpu/drm/i915/display/intel_sprite.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
> b/drivers/gpu/drm/i915/display/intel_sprite.c
> index c26ca029fc0a..2b2d96c59d7f 100644
> --- a/drivers/gpu/drm/i915/display/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/display/intel_sprite.c
> @@ -93,6 +93,9 @@ void intel_pipe_update_start(const struct intel_crtc_state
> *new_crtc_state)
> DEFINE_WAIT(wait);
> u32 psr_status;
>
> + if (new_crtc_state->uapi.async_flip)
> + goto irq_disable;
We shouldn't really need the irq disable at all if we don't do the
vblank evade. And if we only write ctl+surf then atomicity is already
guaranteed by the hw.
> +
> vblank_start = adjusted_mode->crtc_vblank_start;
> if (adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE)
> vblank_start = DIV_ROUND_UP(vblank_start, 2);
> @@ -206,7 +209,7 @@ void intel_pipe_update_end(struct intel_crtc_state
> *new_crtc_state)
>* Would be slightly nice to just grab the vblank count and arm the
>* event outside of the critical section - the spinlock might spin for a
>* while ... */
> - if (new_crtc_state->uapi.event) {
> + if (new_crtc_state->uapi.event && !new_crtc_state->uapi.async_flip) {
> drm_WARN_ON(_priv->drm,
> drm_crtc_vblank_get(>base) != 0);
>
> @@ -220,6 +223,9 @@ void intel_pipe_update_end(struct intel_crtc_state
> *new_crtc_state)
>
> local_irq_enable();
>
> + if (new_crtc_state->uapi.async_flip)
> + return;
> +
> if (intel_vgpu_active(dev_priv))
> return;
>
> --
> 2.22.0
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 3/7] drm/i915: Add checks specific to async flips
On Fri, Aug 07, 2020 at 03:05:47PM +0530, Karthik B S wrote:
> If flip is requested on any other plane, reject it.
>
> Make sure there is no change in fbc, offset and framebuffer modifiers
> when async flip is requested.
>
> If any of these are modified, reject async flip.
>
> v2: -Replace DRM_ERROR (Paulo)
> -Add check for changes in OFFSET, FBC, RC(Paulo)
>
> v3: -Removed TODO as benchmarking tests have been run now.
>
> v4: -Added more state checks for async flip (Ville)
> -Moved intel_atomic_check_async to the end of intel_atomic_check
> as the plane checks needs to pass before this. (Ville)
> -Removed crtc_state->enable_fbc check. (Ville)
> -Set the I915_MODE_FLAG_GET_SCANLINE_FROM_TIMESTAMP flag for async
> flip case as scanline counter is not reliable here.
>
> v5: -Fix typo and other check patch errors seen in CI
> in 'intel_atomic_check_async' function.
>
> v6: -Don't call intel_atomic_check_async multiple times. (Ville)
> -Remove the check for n_planes in intel_atomic_check_async
> -Added documentation for async flips. (Paulo)
>
> Signed-off-by: Karthik B S
> Signed-off-by: Vandita Kulkarni
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 113 +++
> 1 file changed, 113 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index ce2b0c14a073..9629c751d2af 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -14832,6 +14832,110 @@ static bool
> intel_cpu_transcoders_need_modeset(struct intel_atomic_state *state,
> return false;
> }
>
> +/**
> + * DOC: asynchronous flip implementation
> + *
> + * Asynchronous page flip is the implementation for the
> DRM_MODE_PAGE_FLIP_ASYNC
> + * flag. Currently async flip is only supported via the drmModePageFlip
> IOCTL.
> + * Correspondingly, support is currently added for primary plane only.
> + *
> + * Async flip can only change the plane surface address, so anything else
> + * changing is rejected from the intel_atomic_check_async() function.
> + * Once this check is cleared, flip done interrupt is enabled using
> + * the skl_enable_flip_done() function.
> + *
> + * As soon as the surface address register is written, flip done interrupt is
> + * generated and the requested events are sent to the usersapce in the
> interrupt
> + * handler itself. The timestamp and sequence sent during the flip done event
> + * correspond to the last vblank and have no relation to the actual time when
> + * the flip done event was sent.
> + */
> +
> +static int intel_atomic_check_async(struct intel_atomic_state *state)
> +{
> + struct intel_crtc_state *old_crtc_state, *new_crtc_state;
> + struct intel_plane_state *new_plane_state, *old_plane_state;
> + struct intel_crtc *crtc;
> + struct intel_plane *intel_plane;
s/intel_plane/plane/
> + int i;
> +
> + for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
> + new_crtc_state, i) {
> + if (needs_modeset(new_crtc_state)) {
> + DRM_DEBUG_KMS("Modeset Required. Async flip not
> supported\n");
> + return -EINVAL;
> + }
> +
> + if (!new_crtc_state->uapi.active) {
> + DRM_DEBUG_KMS("CRTC inactive\n");
> + return -EINVAL;
> + }
All the uapi.foo stuff should be hw.foo most likely.
> + if (old_crtc_state->active_planes !=
> new_crtc_state->active_planes) {
> + DRM_DEBUG_KMS("Active planes cannot be changed during
> async flip\n");
> + return -EINVAL;
> + }
> + }
> +
> + for_each_oldnew_intel_plane_in_state(state, intel_plane,
> old_plane_state,
> + new_plane_state, i) {
> + /*TODO: Async flip is only supported through the page flip IOCTL
> + * as of now. So support currently added for primary plane only.
> + * Support for other planes should be added when async flip is
> + * enabled in the atomic IOCTL path.
> + */
> + if (intel_plane->id != PLANE_PRIMARY)
> + return -EINVAL;
> +
> + if (old_plane_state->color_plane[0].x !=
> + new_plane_state->color_plane[0].x ||
> + old_plane_state->color_plane[0].y !=
> + new_plane_state->color_plane[0].y) {
> + DRM_DEBUG_KMS("Offsets cannot be changed in async
> flip\n");
> + return -EINVAL;
> + }
> +
> + if (old_plane_state->uapi.fb->modifier !=
> + new_plane_state->uapi.fb->modifier) {
> + DRM_DEBUG_KMS("Framebuffer modifiers cannot be changed
> in async flip\n");
> + return -EINVAL;
> +
Re: [Intel-gfx] [PATCH v6 2/7] drm/i915: Add support for async flips in I915
On Fri, Aug 07, 2020 at 03:05:46PM +0530, Karthik B S wrote:
> Set the Async Address Update Enable bit in plane ctl
> when async flip is requested.
>
> v2: -Move the Async flip enablement to individual patch (Paulo)
>
> v3: -Rebased.
>
> v4: -Add separate plane hook for async flip case (Ville)
>
> v5: -Rebased.
>
> v6: -Move the plane hook to separate patch. (Paulo)
> -Remove the early return in skl_plane_ctl. (Paulo)
>
> Signed-off-by: Karthik B S
> Signed-off-by: Vandita Kulkarni
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 3 +++
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> 2 files changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 1ac2e6f27597..ce2b0c14a073 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -4768,6 +4768,9 @@ u32 skl_plane_ctl(const struct intel_crtc_state
> *crtc_state,
>
> plane_ctl = PLANE_CTL_ENABLE;
>
> + if (crtc_state->uapi.async_flip)
> + plane_ctl |= PLANE_CTL_ASYNC_FLIP;
Hmm. We might want to put that into skl_plane_ctl_crtc() since it's
a crtc-wide thing,
> +
> if (INTEL_GEN(dev_priv) < 10 && !IS_GEMINILAKE(dev_priv)) {
> plane_ctl |= skl_plane_ctl_alpha(plane_state);
> plane_ctl |= PLANE_CTL_PLANE_GAMMA_DISABLE;
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index e85c6fc1f3cb..3f88d9ac90a8 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6924,6 +6924,7 @@ enum {
> #define PLANE_CTL_TILED_X (1 << 10)
> #define PLANE_CTL_TILED_Y (4 << 10)
> #define PLANE_CTL_TILED_YF (5 << 10)
> +#define PLANE_CTL_ASYNC_FLIP (1 << 9)
> #define PLANE_CTL_FLIP_HORIZONTAL (1 << 8)
> #define PLANE_CTL_MEDIA_DECOMPRESSION_ENABLE (1 << 4) /* TGL+ */
> #define PLANE_CTL_ALPHA_MASK (0x3 << 4) /* Pre-GLK */
> --
> 2.22.0
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 1/7] drm/i915: Add enable/disable flip done and flip done handler
On Fri, Aug 07, 2020 at 03:05:45PM +0530, Karthik B S wrote:
> Add enable/disable flip done functions and the flip done handler
> function which handles the flip done interrupt.
>
> Enable the flip done interrupt in IER.
>
> Enable flip done function is called before writing the
> surface address register as the write to this register triggers
> the flip done interrupt
>
> Flip done handler is used to send the page flip event as soon as the
> surface address is written as per the requirement of async flips.
> The interrupt is disabled after the event is sent.
>
> v2: -Change function name from icl_* to skl_* (Paulo)
> -Move flip handler to this patch (Paulo)
> -Remove vblank_put() (Paulo)
> -Enable flip done interrupt for gen9+ only (Paulo)
> -Enable flip done interrupt in power_well_post_enable hook (Paulo)
> -Removed the event check in flip done handler to handle async
> flips without pageflip events.
>
> v3: -Move skl_disable_flip_done out of interrupt handler (Paulo)
> -Make the pending vblank event NULL in the beginning of
> flip_done_handler to remove sporadic WARN_ON that is seen.
>
> v4: -Calculate timestamps using flip done time stamp and current
> timestamp for async flips (Ville)
>
> v5: -Fix the sparse warning by making the function 'g4x_get_flip_counter'
> static.(Reported-by: kernel test robot )
> -Fix the typo in commit message.
>
> v6: -Revert back to old time stamping code.
> -Remove the break while calling skl_enable_flip_done. (Paulo)
>
> Signed-off-by: Karthik B S
> Signed-off-by: Vandita Kulkarni
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 8 +++
> drivers/gpu/drm/i915/i915_irq.c | 52
> drivers/gpu/drm/i915/i915_irq.h | 2 +
> 3 files changed, 62 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 522c772a2111..1ac2e6f27597 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -15562,6 +15562,11 @@ static void intel_atomic_commit_tail(struct
> intel_atomic_state *state)
>
> intel_dbuf_pre_plane_update(state);
>
> + for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
> + if (new_crtc_state->uapi.async_flip)
> + skl_enable_flip_done(>base);
> + }
> +
> /* Now enable the clocks, plane, pipe, and connectors that we set up. */
> dev_priv->display.commit_modeset_enables(state);
>
> @@ -15583,6 +15588,9 @@ static void intel_atomic_commit_tail(struct
> intel_atomic_state *state)
> drm_atomic_helper_wait_for_flip_done(dev, >base);
>
> for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
> + if (new_crtc_state->uapi.async_flip)
> + skl_disable_flip_done(>base);
Where do we wait for the flip done? Can't see such code anywhere.
> +
> if (new_crtc_state->hw.active &&
> !needs_modeset(new_crtc_state) &&
> !new_crtc_state->preload_luts &&
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index f113fe44572b..6cc129b031d3 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1296,6 +1296,23 @@ display_pipe_crc_irq_handler(struct drm_i915_private
> *dev_priv,
>u32 crc4) {}
> #endif
>
> +static void flip_done_handler(struct drm_i915_private *dev_priv,
> + unsigned int pipe)
> +{
> + struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
> + struct drm_crtc_state *crtc_state = crtc->base.state;
> + struct drm_pending_vblank_event *e = crtc_state->event;
> + struct drm_device *dev = _priv->drm;
> + unsigned long irqflags;
> +
> + spin_lock_irqsave(>event_lock, irqflags);
> +
> + crtc_state->event = NULL;
> +
> + drm_crtc_send_vblank_event(>base, e);
> +
> + spin_unlock_irqrestore(>event_lock, irqflags);
> +}
>
> static void hsw_pipe_crc_irq_handler(struct drm_i915_private *dev_priv,
>enum pipe pipe)
> @@ -2390,6 +2407,9 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv,
> u32 master_ctl)
> if (iir & GEN8_PIPE_VBLANK)
> intel_handle_vblank(dev_priv, pipe);
>
> + if (iir & GEN9_PIPE_PLANE1_FLIP_DONE)
> + flip_done_handler(dev_priv, pipe);
> +
> if (iir & GEN8_PIPE_CDCLK_CRC_DONE)
> hsw_pipe_crc_irq_handler(dev_priv, pipe);
>
> @@ -2711,6 +2731,19 @@ int bdw_enable_vblank(struct drm_crtc *crtc)
> return 0;
> }
>
> +void skl_enable_flip_done(struct drm_crtc *crtc)
> +{
> + struct drm_i915_private *dev_priv = to_i915(crtc->dev);
> + enum pipe pipe = to_intel_crtc(crtc)->pipe;
> + unsigned long irqflags;
> +
Re: [Intel-gfx] [PATCH v3 16/16] drm: Replace mode->export_head with a boolean
On Thu, Apr 30, 2020 at 02:50:52PM +0100, Emil Velikov wrote: > Hi Ville > > I don't fully grok the i915 changes to provide meaningful review. > There are couple of small comments below, but regardless of those Sorry, forgot to reply to this in a timely manner. > > Patches 01-11 and 14-16 are: > Reviewed-by: Emil Velikov > > On Tue, 28 Apr 2020 at 18:20, Ville Syrjala > wrote: > > > The downside is that drm_mode_expose_to_userspace() gets to > > iterate a few more modes. It already was O(n^2), now it's > > a slightly worse O(n^2). > > > Personally I'd drop the O() sentence, or change it to > It already was O(n^2), now it's slightly worse O((n+y)^2). Dropped. > > > Another alternative would be a temp bitmask so we wouldn't have > > to have anything in the mode struct itself. The main issue is > > how large of a bitmask do we need? I guess we could allocate > > it dynamically but that means an extra kcalloc() and an extra > > loop through the modes to count them first (or grow the bitmask > > with krealloc() as needed). > > > If the walk is even remotely close to being an issue, we could > consider the bitmask. > I don't think that's the case yet. > > > Hmm the original code never discards any entries from export_head. > I wonder if there's some corner case where we could end with an "old" > mode showing in the list? No. export_list starts out empty so only the modes we explicitly add to the list can be reached. Thus any dangling pointers in some other mode's export_head are of no concern. Pushed the last few patches to drm-misc-next. Thanks for the reviews everyone. > > For example: > - creates a user mode via drmModeCreatePropertyBlob() > - calls drmModeGetConnector() and sees their mode > - optional (?) does a modeset to and away from said mode > - removes their blob drmModeDestroyPropertyBlob() > - calls drmModeGetConnector() and still sees their removed mode. > > If this is a bug (?) that we care about, we might want to add an igt > test for it. > Conversely, if this is a behaviour we want to keep this patch needs some work. > > HTH > > Emil -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/4] drm/i915/display: Ignore IGNORE_PSR2_HW_TRACKING for platforms without sel fetch
== Series Details == Series: series starting with [1/4] drm/i915/display: Ignore IGNORE_PSR2_HW_TRACKING for platforms without sel fetch URL : https://patchwork.freedesktop.org/series/81201/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8948_full -> Patchwork_18426_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18426_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18426_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_18426_full: ### IGT changes ### Possible regressions * igt@runner@aborted: - shard-tglb: NOTRUN -> ([FAIL][1], [FAIL][2], [FAIL][3], [FAIL][4], [FAIL][5], [FAIL][6], [FAIL][7], [FAIL][8], [FAIL][9], [FAIL][10], [FAIL][11], [FAIL][12], [FAIL][13], [FAIL][14], [FAIL][15], [FAIL][16], [FAIL][17], [FAIL][18], [FAIL][19], [FAIL][20], [FAIL][21], [FAIL][22], [FAIL][23], [FAIL][24], [FAIL][25]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18426/shard-tglb8/igt@run...@aborted.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18426/shard-tglb7/igt@run...@aborted.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18426/shard-tglb1/igt@run...@aborted.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18426/shard-tglb5/igt@run...@aborted.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18426/shard-tglb7/igt@run...@aborted.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18426/shard-tglb3/igt@run...@aborted.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18426/shard-tglb8/igt@run...@aborted.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18426/shard-tglb1/igt@run...@aborted.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18426/shard-tglb2/igt@run...@aborted.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18426/shard-tglb2/igt@run...@aborted.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18426/shard-tglb5/igt@run...@aborted.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18426/shard-tglb2/igt@run...@aborted.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18426/shard-tglb1/igt@run...@aborted.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18426/shard-tglb5/igt@run...@aborted.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18426/shard-tglb3/igt@run...@aborted.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18426/shard-tglb1/igt@run...@aborted.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18426/shard-tglb2/igt@run...@aborted.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18426/shard-tglb7/igt@run...@aborted.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18426/shard-tglb3/igt@run...@aborted.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18426/shard-tglb3/igt@run...@aborted.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18426/shard-tglb5/igt@run...@aborted.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18426/shard-tglb5/igt@run...@aborted.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18426/shard-tglb8/igt@run...@aborted.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18426/shard-tglb7/igt@run...@aborted.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18426/shard-tglb1/igt@run...@aborted.html Known issues Here are the changes found in Patchwork_18426_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_whisper@basic-contexts-all: - shard-glk: [PASS][26] -> [TIMEOUT][27] ([i915#1958]) +2 similar issues [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8948/shard-glk5/igt@gem_exec_whis...@basic-contexts-all.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18426/shard-glk2/igt@gem_exec_whis...@basic-contexts-all.html * igt@gem_partial_pwrite_pread@reads-display: - shard-glk: [PASS][28] -> [FAIL][29] ([i915#2261]) +1 similar issue [28]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8948/shard-glk7/igt@gem_partial_pwrite_pr...@reads-display.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18426/shard-glk3/igt@gem_partial_pwrite_pr...@reads-display.html * igt@gem_sync@basic-store-all: - shard-glk: [PASS][30] -> [FAIL][31] ([i915#2356]) [30]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8948/shard-glk8/igt@gem_s...@basic-store-all.html [31]:
Re: [Intel-gfx] [PATCH v8 06/17] pwm: lpss: Use pwm_lpss_restore() when restoring state on resume
On Mon, Aug 31, 2020 at 07:57:30PM +0200, Hans de Goede wrote:
> On 8/31/20 3:15 PM, Thierry Reding wrote:
> > On Mon, Aug 31, 2020 at 01:46:28PM +0200, Hans de Goede wrote:
> > > On 8/31/20 1:10 PM, Thierry Reding wrote:
> > > > On Sun, Aug 30, 2020 at 02:57:42PM +0200, Hans de Goede wrote:
> > > > > Before this commit a suspend + resume of the LPSS PWM controller
> > > > > would result in the controller being reset to its defaults of
> > > > > output-freq = clock/256, duty-cycle=100%, until someone changes
> > > > > to the output-freq and/or duty-cycle are made.
> > > > >
> > > > > This problem has been masked so far because the main consumer
> > > > > (the i915 driver) was always making duty-cycle changes on resume.
> > > > > With the conversion of the i915 driver to the atomic PWM API the
> > > > > driver now only disables/enables the PWM on suspend/resume leaving
> > > > > the output-freq and duty as is, triggering this problem.
> > > >
> > > > Doesn't this imply that there's another bug at play here? At the PWM API
> > > > level you're applying a state and it's up to the driver to ensure that
> > > > the hardware state after ->apply() is what the software has requested.
> > > >
> > > > If you only switch the enable state and that doesn't cause period and
> > > > duty cycle to be updated it means that your driver isn't writing those
> > > > registers when it should be.
> > >
> > > Right, the driver was not committing those as it should *on resume*,
> > > that and it skips setting the update bit on the subsequent enable,
> > > which is an optimization which gets removed in 7/17.
> > >
> > > Before switching the i915 driver over to atomic, when the LPSS-PWM
> > > was used for the backlight we got the following order on suspend/resume
> > >
> > > 1. Set duty-cycle to 0%
> > > 2. Set enabled to 0
> > > 3. Save ctrl reg
> > > 4. Power-off PWM controller, it now looses all its state
> > > 5. Power-on PWM ctrl
> > > 6. Restore ctrl reg (as a single reg write)
> > > 7. Set enabled to 1, at this point one would expect the
> > > duty/freq from the restored ctrl-reg to apply, but:
> > > a) The resume code never sets the update bit (which this commit fixes);
> > > and
> > > b) On applying the pwm_state with enabled=1 the code applying the
> > > state does this (before setting the enabled bit in the ctrl reg):
> > >
> > > if (orig_ctrl != ctrl) {
> > > pwm_lpss_write(pwm, ctrl);
> > > pwm_lpss_write(pwm, ctrl | PWM_SW_UPDATE);
> > > }
> > > and since the restore of the ctrl reg set the old duty/freq the
> > > writes are skipped, so the update bit never gets set.
> > >
> > > 8. Set duty-cycle to the pre-suspend value (which is not 0)
> > > this does cause a change in the ctrl-reg, so now the update flag
> > > does get set.
> > >
> > > Note that 1-2 and 7-8 are both done by the non atomic i915 code,
> > > when moving the i915 code to atomic I decided that having these
> > > 2 separate steps here is non-sense, so the new i915 code just
> > > toggles the enable bit. So in essence the new atomic PWM
> > > i915 code drops step 1 and 8.
> > >
> > > Dropping steps 8 means that the update bit never gets set and we
> > > end up with the PWM running at its power-on-reset duty cycle.
> > >
> > > You are correct in your remark to patch 7/17 that since that removes
> > > the if (orig_ctrl != ctrl) for the writes that now step 7 will be
> > > sufficient to get the PWM to work again. But that only takes the i915
> > > usage into account.
> > >
> > > What if the PWM is used through the sysfs userspace API?
> > > Then only steps 3-6 will happen on suspend-resume and without
> > > fixing step 6 to properly restore the PWM controller in its
> > > pre-resume state (this patch) it will once again be running at
> > > its power-on-reset defaults instead of the values from the
> > > restored control register.
> >
> > Actually PWM's sysfs code has suspend/resume callbacks that basically
> > make sysfs just a regular consumer of PWMs. So they do end up doing a
> > pwm_apply_state() on the PWM as well on suspend and restore the state
> > from before suspend on resume.
> >
> > This was done very specifically because the suspend/resume order can be
> > unexpected under some circumstances, so for PWM we really want for the
> > consumer to always have ultimate control over when precisely the PWM is
> > restored on resume.
> >
> > The reason why we did this was because people observed weird glitches on
> > suspend/resume with different severity. In some cases a backlight would
> > be resumed before the display controller had had a chance to start
> > sending frames, causing on-screen corruption in some cases (such as
> > smart displays) and in other cases a PWM-controller regulator would be
> > resumed too late or too early, which I think was causing some issue with
> > the CPUs not working properly on resume.
> >
> > So I'd prefer not to have any PWM driver save and restore its own
> > context on
Re: [Intel-gfx] [PATCH v8 00/17] drm/i915: Add support for HDCP 1.4 over MST
On 2020-08-18 at 11:38:48 -0400, Sean Paul wrote: > From: Sean Paul > > Only one functional change, reversed the hdcp_1x/2x_present bits in the > QUERY_STREAM_ENCRYPTION_STATUS parsing with a comment explaining my > confusion. > > Other than that, lots of rebasing, the most notable being the > s/intel_dig_port/dig_port/ rename. > > Every patch now has a Reviewed-by tag now, I've done build tests on each > patch and tested the set as a whole. Hopefully we can get this landed. Thanks for the change. Merged into dinq. Ram > > Sean > > Sean Paul (17): > drm/i915: Fix sha_text population code > drm/i915: Clear the repeater bit on HDCP disable > drm/i915: WARN if HDCP signalling is enabled upon disable > drm/i915: Intercept Aksv writes in the aux hooks > drm/i915: Use the cpu_transcoder in intel_hdcp to toggle HDCP > signalling > drm/i915: Factor out hdcp->value assignments > drm/i915: Protect workers against disappearing connectors > drm/i915: Clean up intel_hdcp_disable > drm/i915: Don't fully disable HDCP on a port if multiple pipes are > using it > drm/i915: Support DP MST in enc_to_dig_port() function > drm/i915: Use ddi_update_pipe in intel_dp_mst > drm/i915: Factor out HDCP shim functions from dp for use by dp_mst > drm/i915: Plumb port through hdcp init > drm/i915: Add connector to hdcp_shim->check_link() > drm/mst: Add support for QUERY_STREAM_ENCRYPTION_STATUS MST sideband > message > drm/i915: Print HDCP version info for all connectors > drm/i915: Add HDCP 1.4 support for MST connectors > > drivers/gpu/drm/drm_dp_mst_topology.c | 150 > drivers/gpu/drm/i915/Makefile | 1 + > drivers/gpu/drm/i915/display/intel_ddi.c | 29 +- > drivers/gpu/drm/i915/display/intel_ddi.h | 2 + > .../drm/i915/display/intel_display_debugfs.c | 21 +- > .../drm/i915/display/intel_display_types.h| 30 +- > drivers/gpu/drm/i915/display/intel_dp.c | 646 +--- > drivers/gpu/drm/i915/display/intel_dp.h | 9 + > drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 703 ++ > drivers/gpu/drm/i915/display/intel_dp_mst.c | 19 + > drivers/gpu/drm/i915/display/intel_hdcp.c | 217 -- > drivers/gpu/drm/i915/display/intel_hdcp.h | 2 +- > drivers/gpu/drm/i915/display/intel_hdmi.c | 30 +- > .../drm/selftests/test-drm_dp_mst_helper.c| 17 + > include/drm/drm_dp_helper.h | 3 + > include/drm/drm_dp_mst_helper.h | 44 ++ > include/drm/drm_hdcp.h| 3 + > 17 files changed, 1202 insertions(+), 724 deletions(-) > create mode 100644 drivers/gpu/drm/i915/display/intel_dp_hdcp.c > > -- > Sean Paul, Software Engineer, Google / Chromium OS > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v3] drm/nouveau: utilize subconnector property for DP
Hi Ben Skeggs,
Gentle Reminder, Can you please take a look at the patch and provide your ack.
Thanks
Jeevan B
>-Original Message-
>From: B, Jeevan
>Sent: Sunday, August 16, 2020 12:22 PM
>To: nouv...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org; dri-
>de...@lists.freedesktop.org
>Cc: bske...@redhat.com; airl...@redhat.com;
>maarten.lankho...@linux.intel.com; Nikula, Jani ;
>Shankar, Uma ; Oleg Vasilev
>; B, Jeevan
>Subject: [v3] drm/nouveau: utilize subconnector property for DP
>
>From: Oleg Vasilev
>
>Since DP-specific information is stored in driver's structures, every driver
>needs to implement subconnector property by itself.
>
>v2: rebase
>
>v3: renamed a function call
>
>Cc: Ben Skeggs
>Cc: nouv...@lists.freedesktop.org
>Signed-off-by: Jeevan B
>Signed-off-by: Oleg Vasilev
>Reviewed-by: Emil Velikov
>---
> drivers/gpu/drm/nouveau/nouveau_connector.c | 13 +
> drivers/gpu/drm/nouveau/nouveau_dp.c| 9 +
> drivers/gpu/drm/nouveau/nouveau_encoder.h | 1 +
> 3 files changed, 23 insertions(+)
>
>diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
>b/drivers/gpu/drm/nouveau/nouveau_connector.c
>index 7674025..955afed 100644
>--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
>+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
>@@ -654,6 +654,17 @@ nouveau_connector_detect(struct drm_connector
>*connector, bool force)
> pm_runtime_mark_last_busy(dev->dev);
> pm_runtime_put_autosuspend(dev->dev);
>
>+ if (connector->connector_type ==
>DRM_MODE_CONNECTOR_DisplayPort ||
>+ connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
>+ enum drm_mode_subconnector subconnector =
>+DRM_MODE_SUBCONNECTOR_Unknown;
>+
>+ if (conn_status == connector_status_connected &&
>nv_encoder)
>+ subconnector = nv_encoder->dp.subconnector;
>+ drm_object_property_set_value(>base,
>+ connector->dev-
>>mode_config.dp_subconnector_property,
>+ subconnector);
>+ }
>+
> return conn_status;
> }
>
>@@ -1390,6 +1401,8 @@ nouveau_connector_create(struct drm_device *dev,
> kfree(nv_connector);
> return ERR_PTR(ret);
> }
>+
>+
> drm_connector_attach_dp_subconnector_property(connector);
> funcs = _connector_funcs;
> break;
> default:
>diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
>b/drivers/gpu/drm/nouveau/nouveau_dp.c
>index 8a0f799..3eff884 100644
>--- a/drivers/gpu/drm/nouveau/nouveau_dp.c
>+++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
>@@ -62,6 +62,7 @@ nouveau_dp_detect(struct nouveau_encoder
>*nv_encoder)
> struct nouveau_drm *drm = nouveau_drm(dev);
> struct nvkm_i2c_aux *aux;
> u8 dpcd[8];
>+ u8 port_cap[DP_MAX_DOWNSTREAM_PORTS] = {};
> int ret;
>
> aux = nv_encoder->aux;
>@@ -72,6 +73,14 @@ nouveau_dp_detect(struct nouveau_encoder
>*nv_encoder)
> if (ret)
> return ret;
>
>+ if (dpcd[DP_DPCD_REV] > 0x10) {
>+ ret = nvkm_rdaux(aux, DP_DOWNSTREAM_PORT_0,
>+ port_cap, DP_MAX_DOWNSTREAM_PORTS);
>+ if (ret)
>+ memset(port_cap, 0,
>DP_MAX_DOWNSTREAM_PORTS);
>+ }
>+ nv_encoder->dp.subconnector = drm_dp_subconnector_type(dpcd,
>+port_cap);
>+
> nv_encoder->dp.link_bw = 27000 * dpcd[1];
> nv_encoder->dp.link_nr = dpcd[2] & DP_MAX_LANE_COUNT_MASK;
>
>diff --git a/drivers/gpu/drm/nouveau/nouveau_encoder.h
>b/drivers/gpu/drm/nouveau/nouveau_encoder.h
>index a72c412..49b5c10 100644
>--- a/drivers/gpu/drm/nouveau/nouveau_encoder.h
>+++ b/drivers/gpu/drm/nouveau/nouveau_encoder.h
>@@ -64,6 +64,7 @@ struct nouveau_encoder {
> struct nv50_mstm *mstm;
> int link_nr;
> int link_bw;
>+ enum drm_mode_subconnector subconnector;
> } dp;
> };
>
>--
>2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/5] drm_dp_cec: add plumbing in preparation for MST support
From: Hans Verkuil
Signed-off-by: Hans Verkuil
[sa...@chromium.org:
- rebased
- removed polling-related changes
- moved the calls to drm_dp_cec_(un)set_edid() into the next patch
]
Signed-off-by: Sam McNally
---
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 +-
drivers/gpu/drm/drm_dp_cec.c | 22 ++-
drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_connector.c | 2 +-
include/drm/drm_dp_helper.h | 6 +++--
5 files changed, 19 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 461fa4da0a34..6e7075893ec9 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -419,7 +419,7 @@ void amdgpu_dm_initialize_dp_connector(struct
amdgpu_display_manager *dm,
drm_dp_aux_init(>dm_dp_aux.aux);
drm_dp_cec_register_connector(>dm_dp_aux.aux,
- >base);
+ >base, false);
if (aconnector->base.connector_type == DRM_MODE_CONNECTOR_eDP)
return;
diff --git a/drivers/gpu/drm/drm_dp_cec.c b/drivers/gpu/drm/drm_dp_cec.c
index 3ab2609f9ec7..04ab7b88055c 100644
--- a/drivers/gpu/drm/drm_dp_cec.c
+++ b/drivers/gpu/drm/drm_dp_cec.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
/*
* Unfortunately it turns out that we have a chicken-and-egg situation
@@ -338,8 +339,6 @@ void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const
struct edid *edid)
if (aux->cec.adap) {
if (aux->cec.adap->capabilities == cec_caps &&
aux->cec.adap->available_log_addrs == num_las) {
- /* Unchanged, so just set the phys addr */
- cec_s_phys_addr_from_edid(aux->cec.adap, edid);
goto unlock;
}
/*
@@ -364,15 +363,16 @@ void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const
struct edid *edid)
if (cec_register_adapter(aux->cec.adap, connector->dev->dev)) {
cec_delete_adapter(aux->cec.adap);
aux->cec.adap = NULL;
- } else {
- /*
-* Update the phys addr for the new CEC adapter. When called
-* from drm_dp_cec_register_connector() edid == NULL, so in
-* that case the phys addr is just invalidated.
-*/
- cec_s_phys_addr_from_edid(aux->cec.adap, edid);
}
unlock:
+ /*
+* Update the phys addr for the new CEC adapter. When called
+* from drm_dp_cec_register_connector() edid == NULL, so in
+* that case the phys addr is just invalidated.
+*/
+ if (aux->cec.adap && edid) {
+ cec_s_phys_addr_from_edid(aux->cec.adap, edid);
+ }
mutex_unlock(>cec.lock);
}
EXPORT_SYMBOL(drm_dp_cec_set_edid);
@@ -418,6 +418,7 @@ EXPORT_SYMBOL(drm_dp_cec_unset_edid);
* drm_dp_cec_register_connector() - register a new connector
* @aux: DisplayPort AUX channel
* @connector: drm connector
+ * @is_mst: set to true if this is an MST branch
*
* A new connector was registered with associated CEC adapter name and
* CEC adapter parent device. After registering the name and parent
@@ -425,12 +426,13 @@ EXPORT_SYMBOL(drm_dp_cec_unset_edid);
* CEC and to register a CEC adapter if that is the case.
*/
void drm_dp_cec_register_connector(struct drm_dp_aux *aux,
- struct drm_connector *connector)
+ struct drm_connector *connector, bool is_mst)
{
WARN_ON(aux->cec.adap);
if (WARN_ON(!aux->transfer))
return;
aux->cec.connector = connector;
+ aux->cec.is_mst = is_mst;
INIT_DELAYED_WORK(>cec.unregister_work,
drm_dp_cec_unregister_work);
}
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 82b9de274f65..744cb55572f9 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -6261,7 +6261,7 @@ intel_dp_connector_register(struct drm_connector
*connector)
intel_dp->aux.dev = connector->kdev;
ret = drm_dp_aux_register(_dp->aux);
if (!ret)
- drm_dp_cec_register_connector(_dp->aux, connector);
+ drm_dp_cec_register_connector(_dp->aux, connector, false);
return ret;
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 49dd0cbc332f..671a70e95cd1 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -1414,7 +1414,7 @@ nouveau_connector_create(struct drm_device *dev,
switch (type) {
case
