[PATCH rdma-next v2 0/2] SG fix together with update to RDMA umem
From: Leon Romanovsky Changelog: v2: * Changed implementation of first patch, based on our discussion with Christoph. https://lore.kernel.org/lkml/ynwavtt0qmqdx...@infradead.org/ v1: https://lore.kernel.org/lkml/cover.1624955710.git.leo...@nvidia.com/ * Fixed sg_page with a _dma_ API in the umem.c v0: https://lore.kernel.org/lkml/cover.1624361199.git.leo...@nvidia.com Maor Gottlieb (2): lib/scatterlist: Fix wrong update of orig_nents RDMA: Use dma_map_sgtable for map umem pages drivers/gpu/drm/drm_prime.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 2 +- drivers/infiniband/core/umem.c | 33 +++- drivers/infiniband/core/umem_dmabuf.c | 1 - drivers/infiniband/hw/mlx4/mr.c | 4 +- drivers/infiniband/hw/mlx5/mr.c | 3 +- drivers/infiniband/sw/rdmavt/mr.c | 2 +- drivers/infiniband/sw/rxe/rxe_mr.c | 3 +- include/linux/scatterlist.h | 3 +- include/rdma/ib_umem.h | 6 +- include/rdma/ib_verbs.h | 28 +++ lib/scatterlist.c | 88 ++--- tools/testing/scatterlist/main.c| 15 +++- 14 files changed, 128 insertions(+), 64 deletions(-) -- 2.31.1
[PATCH rdma-next v2 2/2] RDMA: Use dma_map_sgtable for map umem pages
From: Maor Gottlieb
In order to avoid incorrect usage of sg_table fields, change umem to
use dma_map_sgtable for map the pages for DMA. Since dma_map_sgtable
update the nents field (number of DMA entries), there is no need
anymore for nmap variable, hence do some cleanups accordingly.
Signed-off-by: Maor Gottlieb
Signed-off-by: Leon Romanovsky
---
drivers/infiniband/core/umem.c| 28 +++
drivers/infiniband/core/umem_dmabuf.c | 1 -
drivers/infiniband/hw/mlx4/mr.c | 4 ++--
drivers/infiniband/hw/mlx5/mr.c | 3 ++-
drivers/infiniband/sw/rdmavt/mr.c | 2 +-
drivers/infiniband/sw/rxe/rxe_mr.c| 3 ++-
include/rdma/ib_umem.h| 3 ++-
include/rdma/ib_verbs.h | 28 +++
8 files changed, 48 insertions(+), 24 deletions(-)
diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
index cf4197363346..77c2df1c91d1 100644
--- a/drivers/infiniband/core/umem.c
+++ b/drivers/infiniband/core/umem.c
@@ -51,11 +51,11 @@ static void __ib_umem_release(struct ib_device *dev, struct
ib_umem *umem, int d
struct scatterlist *sg;
unsigned int i;
- if (umem->nmap > 0)
- ib_dma_unmap_sg(dev, umem->sg_head.sgl, umem->sg_nents,
- DMA_BIDIRECTIONAL);
+ if (dirty)
+ ib_dma_unmap_sgtable_attrs(dev, &umem->sg_head,
+ DMA_BIDIRECTIONAL, 0);
- for_each_sg(umem->sg_head.sgl, sg, umem->sg_nents, i)
+ for_each_sgtable_sg(&umem->sg_head, sg, i)
unpin_user_page_range_dirty_lock(sg_page(sg),
DIV_ROUND_UP(sg->length, PAGE_SIZE), make_dirty);
@@ -111,7 +111,7 @@ unsigned long ib_umem_find_best_pgsz(struct ib_umem *umem,
/* offset into first SGL */
pgoff = umem->address & ~PAGE_MASK;
- for_each_sg(umem->sg_head.sgl, sg, umem->nmap, i) {
+ for_each_sgtable_dma_sg(&umem->sg_head, sg, i) {
/* Walk SGL and reduce max page size if VA/PA bits differ
* for any address.
*/
@@ -121,7 +121,7 @@ unsigned long ib_umem_find_best_pgsz(struct ib_umem *umem,
* the maximum possible page size as the low bits of the iova
* must be zero when starting the next chunk.
*/
- if (i != (umem->nmap - 1))
+ if (i != (umem->sg_head.nents - 1))
mask |= va;
pgoff = 0;
}
@@ -240,16 +240,10 @@ struct ib_umem *ib_umem_get(struct ib_device *device,
unsigned long addr,
if (access & IB_ACCESS_RELAXED_ORDERING)
dma_attr |= DMA_ATTR_WEAK_ORDERING;
- umem->nmap =
- ib_dma_map_sg_attrs(device, umem->sg_head.sgl, umem->sg_nents,
- DMA_BIDIRECTIONAL, dma_attr);
-
- if (!umem->nmap) {
- ret = -ENOMEM;
+ ret = ib_dma_map_sgtable_attrs(device, &umem->sg_head,
+ DMA_BIDIRECTIONAL, dma_attr);
+ if (ret)
goto umem_release;
- }
-
- ret = 0;
goto out;
umem_release:
@@ -309,8 +303,8 @@ int ib_umem_copy_from(void *dst, struct ib_umem *umem,
size_t offset,
return -EINVAL;
}
- ret = sg_pcopy_to_buffer(umem->sg_head.sgl, umem->sg_nents, dst, length,
-offset + ib_umem_offset(umem));
+ ret = sg_pcopy_to_buffer(umem->sg_head.sgl, umem->sg_head.orig_nents,
+dst, length, offset + ib_umem_offset(umem));
if (ret < 0)
return ret;
diff --git a/drivers/infiniband/core/umem_dmabuf.c
b/drivers/infiniband/core/umem_dmabuf.c
index c6e875619fac..2884e4526d78 100644
--- a/drivers/infiniband/core/umem_dmabuf.c
+++ b/drivers/infiniband/core/umem_dmabuf.c
@@ -57,7 +57,6 @@ int ib_umem_dmabuf_map_pages(struct ib_umem_dmabuf
*umem_dmabuf)
umem_dmabuf->umem.sg_head.sgl = umem_dmabuf->first_sg;
umem_dmabuf->umem.sg_head.nents = nmap;
- umem_dmabuf->umem.nmap = nmap;
umem_dmabuf->sgt = sgt;
wait_fence:
diff --git a/drivers/infiniband/hw/mlx4/mr.c b/drivers/infiniband/hw/mlx4/mr.c
index 50becc0e4b62..ab5dc8eac7f8 100644
--- a/drivers/infiniband/hw/mlx4/mr.c
+++ b/drivers/infiniband/hw/mlx4/mr.c
@@ -200,7 +200,7 @@ int mlx4_ib_umem_write_mtt(struct mlx4_ib_dev *dev, struct
mlx4_mtt *mtt,
mtt_shift = mtt->page_shift;
mtt_size = 1ULL << mtt_shift;
- for_each_sg(umem->sg_head.sgl, sg, umem->nmap, i) {
+ for_each_sgtable_dma_sg(&umem->sg_head, sg, i) {
if (cur_start_addr + len == sg_dma_address(sg)) {
/* still the same block */
len += sg_dma_len(sg);
@@ -273,7 +273,7 @@ int mlx4_ib_umem_calc_optimal_mtt_size(struct ib_umem
*umem, u64 start_va,
*num_of_mtts = ib_umem
[PATCH rdma-next v2 1/2] lib/scatterlist: Fix wrong update of orig_nents
From: Maor Gottlieb
orig_nents should represent the number of entries with pages,
but __sg_alloc_table_from_pages sets orig_nents as the number of
total entries in the table. This is wrong when the API is used for
dynamic allocation where not all the table entries are mapped with
pages. It wasn't observed until now, since RDMA umem who uses this
API in the dynamic form doesn't use orig_nents implicit or explicit
by the scatterlist APIs.
Fix it by:
1. Set orig_nents as number of entries with pages also in
__sg_alloc_table_from_pages.
2. To fix the release flow, add a new output argument to
__sg_alloc_table_from_pages which will be set to the
number of total entries in the table. User like umem that use
this function for dynamic allocation, should free the table by
calling to sg_free_table_entries and pass the number of entries.
Fixes: 07da1223ec93 ("lib/scatterlist: Add support in dynamic allocation of SG
table from pages")
Signed-off-by: Maor Gottlieb
Signed-off-by: Leon Romanovsky
---
drivers/gpu/drm/drm_prime.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 2 +-
drivers/infiniband/core/umem.c | 5 +-
include/linux/scatterlist.h | 3 +-
include/rdma/ib_umem.h | 3 +-
lib/scatterlist.c | 88 ++---
tools/testing/scatterlist/main.c| 15 +++-
8 files changed, 80 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 2a54f86856af..1739d10a2c55 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -821,7 +821,7 @@ struct sg_table *drm_prime_pages_to_sg(struct drm_device
*dev,
sge = __sg_alloc_table_from_pages(sg, pages, nr_pages, 0,
nr_pages << PAGE_SHIFT,
max_segment,
- NULL, 0, GFP_KERNEL);
+ NULL, 0, GFP_KERNEL, NULL);
if (IS_ERR(sge)) {
kfree(sg);
sg = ERR_CAST(sge);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
index 7487bab11f0b..c341d3e3386c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
@@ -155,7 +155,7 @@ static int i915_gem_userptr_get_pages(struct
drm_i915_gem_object *obj)
alloc_table:
sg = __sg_alloc_table_from_pages(st, pvec, num_pages, 0,
num_pages << PAGE_SHIFT, max_segment,
-NULL, 0, GFP_KERNEL);
+NULL, 0, GFP_KERNEL, NULL);
if (IS_ERR(sg)) {
ret = PTR_ERR(sg);
goto err;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
index 0488042fb287..2ad889272b0a 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
@@ -390,7 +390,7 @@ static int vmw_ttm_map_dma(struct vmw_ttm_tt *vmw_tt)
vsgt->num_pages, 0,
(unsigned long) vsgt->num_pages << PAGE_SHIFT,
dma_get_max_seg_size(dev_priv->drm.dev),
- NULL, 0, GFP_KERNEL);
+ NULL, 0, GFP_KERNEL, NULL);
if (IS_ERR(sg)) {
ret = PTR_ERR(sg);
goto out_sg_alloc_fail;
diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
index 0eb40025075f..cf4197363346 100644
--- a/drivers/infiniband/core/umem.c
+++ b/drivers/infiniband/core/umem.c
@@ -59,7 +59,7 @@ static void __ib_umem_release(struct ib_device *dev, struct
ib_umem *umem, int d
unpin_user_page_range_dirty_lock(sg_page(sg),
DIV_ROUND_UP(sg->length, PAGE_SIZE), make_dirty);
- sg_free_table(&umem->sg_head);
+ sg_free_table_entries(&umem->sg_head, umem->total_nents);
}
/**
@@ -229,8 +229,7 @@ struct ib_umem *ib_umem_get(struct ib_device *device,
unsigned long addr,
sg = __sg_alloc_table_from_pages(&umem->sg_head, page_list, ret,
0, ret << PAGE_SHIFT,
ib_dma_max_seg_size(device), sg, npages,
- GFP_KERNEL);
- umem->sg_nents = umem->sg_head.nents;
+ GFP_KERNEL, &umem->total_nents);
if (IS_ERR(sg)) {
unpin_user_pages_dirty_lock(page_list, ret, 0);
ret = PTR_ERR(sg);
diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
index ecf87484814f..c796c165d5ee 100644
--- a/include/linux/scatterlist.h
+++ b/include/linux/scatterli
Re: [PATCH 1/5] drm: Define DRM_FORMAT_MAX_PLANES
Hi Thomas,
I love your patch! Perhaps something to improve:
[auto build test WARNING on 4d00e2309398147acdbfefbe1deb4b0e78868466]
url:
https://github.com/0day-ci/linux/commits/Thomas-Zimmermann/drm-Provide-framebuffer-vmap-helpers/20210716-020508
base: 4d00e2309398147acdbfefbe1deb4b0e78868466
config: x86_64-randconfig-m001-20210718 (attached as .config)
compiler: gcc-10 (Ubuntu 10.3.0-1ubuntu1~20.04) 10.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
smatch warnings:
drivers/gpu/drm/drm_gem_framebuffer_helper.c:192 drm_gem_fb_init_with_funcs()
warn: always true condition '(i >= 0) => (0-u32max >= 0)'
drivers/gpu/drm/drm_gem_framebuffer_helper.c:192 drm_gem_fb_init_with_funcs()
warn: always true condition '(i >= 0) => (0-u32max >= 0)'
vim +192 drivers/gpu/drm/drm_gem_framebuffer_helper.c
4c3dbb2c312c9f Noralf Trønnes2017-08-13 119
4c3dbb2c312c9f Noralf Trønnes2017-08-13 120 /**
f2b816d78a9431 Andrzej Pietrasiewicz 2020-03-11 121 *
drm_gem_fb_init_with_funcs() - Helper function for implementing
4c3dbb2c312c9f Noralf Trønnes2017-08-13 122 *
&drm_mode_config_funcs.fb_create
f2b816d78a9431 Andrzej Pietrasiewicz 2020-03-11 123 *
callback in cases when the driver
f2b816d78a9431 Andrzej Pietrasiewicz 2020-03-11 124 *
allocates a subclass of
f2b816d78a9431 Andrzej Pietrasiewicz 2020-03-11 125 *
struct drm_framebuffer
4c3dbb2c312c9f Noralf Trønnes2017-08-13 126 * @dev: DRM device
f2b816d78a9431 Andrzej Pietrasiewicz 2020-03-11 127 * @fb: framebuffer object
2e187b2099034a Noralf Trønnes2017-09-22 128 * @file: DRM file that
holds the GEM handle(s) backing the framebuffer
2e187b2099034a Noralf Trønnes2017-09-22 129 * @mode_cmd: Metadata
from the userspace framebuffer creation request
4c3dbb2c312c9f Noralf Trønnes2017-08-13 130 * @funcs: vtable to be
used for the new framebuffer object
4c3dbb2c312c9f Noralf Trønnes2017-08-13 131 *
dbd62e16fd53d3 Noralf Trønnes2019-01-15 132 * This function can be
used to set &drm_framebuffer_funcs for drivers that need
dbd62e16fd53d3 Noralf Trønnes2019-01-15 133 * custom framebuffer
callbacks. Use drm_gem_fb_create() if you don't need to
dbd62e16fd53d3 Noralf Trønnes2019-01-15 134 * change
&drm_framebuffer_funcs. The function does buffer size validation.
f2b816d78a9431 Andrzej Pietrasiewicz 2020-03-11 135 * The buffer size
validation is for a general case, though, so users should
f2b816d78a9431 Andrzej Pietrasiewicz 2020-03-11 136 * pay attention to the
checks being appropriate for them or, at least,
f2b816d78a9431 Andrzej Pietrasiewicz 2020-03-11 137 * non-conflicting.
2e187b2099034a Noralf Trønnes2017-09-22 138 *
2e187b2099034a Noralf Trønnes2017-09-22 139 * Returns:
f2b816d78a9431 Andrzej Pietrasiewicz 2020-03-11 140 * Zero or a negative
error code.
4c3dbb2c312c9f Noralf Trønnes2017-08-13 141 */
f2b816d78a9431 Andrzej Pietrasiewicz 2020-03-11 142 int
drm_gem_fb_init_with_funcs(struct drm_device *dev,
f2b816d78a9431 Andrzej Pietrasiewicz 2020-03-11 143
struct drm_framebuffer *fb,
f2b816d78a9431 Andrzej Pietrasiewicz 2020-03-11 144
struct drm_file *file,
4c3dbb2c312c9f Noralf Trønnes2017-08-13 145
const struct drm_mode_fb_cmd2 *mode_cmd,
4c3dbb2c312c9f Noralf Trønnes2017-08-13 146
const struct drm_framebuffer_funcs *funcs)
4c3dbb2c312c9f Noralf Trønnes2017-08-13 147 {
4c3dbb2c312c9f Noralf Trønnes2017-08-13 148const struct
drm_format_info *info;
6065e7036e073e Thomas Zimmermann 2021-07-15 149struct drm_gem_object
*objs[DRM_FORMAT_MAX_PLANES];
6065e7036e073e Thomas Zimmermann 2021-07-15 150unsigned int i;
6065e7036e073e Thomas Zimmermann 2021-07-15 151int ret;
4c3dbb2c312c9f Noralf Trønnes2017-08-13 152
4c3dbb2c312c9f Noralf Trønnes2017-08-13 153info =
drm_get_format_info(dev, mode_cmd);
f7f525030854b1 Simon Ser 2021-05-03 154if (!info) {
f7f525030854b1 Simon Ser 2021-05-03 155
drm_dbg_kms(dev, "Failed to get FB format info\n");
f2b816d78a9431 Andrzej Pietrasiewicz 2020-03-11 156return -EINVAL;
f7f525030854b1 Simon Ser 2021-05-03 157}
4c3dbb2c312c9f Noralf Trønnes2017-08-13 158
4c3dbb2c312c9f Noralf Trønnes2017-08-13 159for (i = 0; i <
info->num_planes; i++) {
4c3dbb2c312c9f Noralf Trønnes2017-08-13 160unsigned int
width = mode_cmd->width / (i ? info->hsub : 1);
4c3dbb2c312c9f Noralf Trønnes2017-08
[PATCH] staging/fbtft: Remove all strcpy() uses
strcpy() performs no bounds checking on the destination buffer. This
could result in linear overflows beyond the end of the buffer, leading
to all kinds of misbehaviors. The safe replacement is strscpy() but in
this case it is simpler to add NULL to the first position since we want
to empty the string.
This is a previous step in the path to remove the strcpy() function.
Signed-off-by: Len Baker
---
drivers/staging/fbtft/fbtft-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/fbtft/fbtft-core.c
b/drivers/staging/fbtft/fbtft-core.c
index 3723269890d5..b8791806cb20 100644
--- a/drivers/staging/fbtft/fbtft-core.c
+++ b/drivers/staging/fbtft/fbtft-core.c
@@ -1037,7 +1037,7 @@ int fbtft_init_display(struct fbtft_par *par)
case -1:
i++;
/* make debug message */
- strcpy(msg, "");
+ msg[0] = 0;
j = i + 1;
while (par->init_sequence[j] >= 0) {
sprintf(str, "0x%02X ", par->init_sequence[j]);
--
2.25.1
Re: [PATCH] staging/fbtft: Remove all strcpy() uses
On Sun, Jul 18, 2021 at 4:43 PM Len Baker wrote:
>
> strcpy() performs no bounds checking on the destination buffer. This
> could result in linear overflows beyond the end of the buffer, leading
> to all kinds of misbehaviors. The safe replacement is strscpy() but in
> this case it is simpler to add NULL to the first position since we want
> to empty the string.
> This is a previous step in the path to remove the strcpy() function.
Any document behind this (something to read on the site(s) more or
less affiliated with what is going to happen in the kernel) to read
background?
...
> case -1:
> i++;
> /* make debug message */
> - strcpy(msg, "");
> + msg[0] = 0;
Strictly speaking it should be '\0'.
> j = i + 1;
> while (par->init_sequence[j] >= 0) {
> sprintf(str, "0x%02X ",
> par->init_sequence[j]);
--
With Best Regards,
Andy Shevchenko
Re: [PATCH v2 4/4] ARM: dts: add SKOV imx6q and imx6dl based boards
Hi Oleksij, On Wed, Jul 14, 2021 at 06:53:49AM +0200, Oleksij Rempel wrote: > From: Sam Ravnborg The real author one these dts files are Juergen Borleis IIRC. I made some internal refactoring / renaming which is why I thing git says otherwise. So onless Juergen says otherwise we should give him the author credit. Arnd - would it be OK if I take the bindings patches through drm-misc-next, and then you can take the DTS files via arm-soc? Sam > > Add SKOV imx6q/dl LT2, LT6 and mi1010ait-1cp1 boards. > > Signed-off-by: Sam Ravnborg > Signed-off-by: Søren Andersen > Signed-off-by: Juergen Borleis > Signed-off-by: Ulrich Ölmann > Signed-off-by: Michael Grzeschik > Signed-off-by: Marco Felsch > Signed-off-by: Lucas Stach > Signed-off-by: Oleksij Rempel > --- > arch/arm/boot/dts/Makefile| 5 + > arch/arm/boot/dts/imx6dl-skov-revc-lt2.dts| 13 + > arch/arm/boot/dts/imx6dl-skov-revc-lt6.dts| 108 > arch/arm/boot/dts/imx6q-skov-revc-lt2.dts | 36 ++ > arch/arm/boot/dts/imx6q-skov-revc-lt6.dts | 128 + > .../dts/imx6q-skov-reve-mi1010ait-1cp1.dts| 127 + > arch/arm/boot/dts/imx6qdl-skov-cpu-revc.dtsi | 54 ++ > arch/arm/boot/dts/imx6qdl-skov-cpu.dtsi | 475 ++ > 8 files changed, 946 insertions(+) > create mode 100644 arch/arm/boot/dts/imx6dl-skov-revc-lt2.dts > create mode 100644 arch/arm/boot/dts/imx6dl-skov-revc-lt6.dts > create mode 100644 arch/arm/boot/dts/imx6q-skov-revc-lt2.dts > create mode 100644 arch/arm/boot/dts/imx6q-skov-revc-lt6.dts > create mode 100644 arch/arm/boot/dts/imx6q-skov-reve-mi1010ait-1cp1.dts > create mode 100644 arch/arm/boot/dts/imx6qdl-skov-cpu-revc.dtsi > create mode 100644 arch/arm/boot/dts/imx6qdl-skov-cpu.dtsi ...
Re: [PATCH v18 0/2] Add memory bandwidth management to NVIDIA Tegra DRM driver
21.06.2021 14:43, Dmitry Osipenko пишет: > 21.06.2021 14:01, Thierry Reding пишет: >> On Mon, Jun 21, 2021 at 07:19:15AM +0300, Dmitry Osipenko wrote: >>> 07.06.2021 01:40, Dmitry Osipenko пишет: 01.06.2021 07:21, Dmitry Osipenko пишет: > This series adds memory bandwidth management to the NVIDIA Tegra DRM > driver, > which is done using interconnect framework. It fixes display corruption > that > happens due to insufficient memory bandwidth. > > Changelog: > > v18: - Moved total peak bandwidth from CRTC state to plane state and > removed >dummy plane bandwidth state initialization from T186+ plane hub. > This >was suggested by Thierry Reding to v17. > > - I haven't done anything about the cursor's plane bandwidth which >doesn't contribute to overlapping bandwidths for a small sized >window because it works okay as-is. Thierry, will you take these patches for 5.14? >>> >>> The display controller does _NOT_WORK_ properly without bandwidth >>> management. >> >> That's surprising. So either it has never worked before (which I think >> I'd know) or something has caused this regression recently. In the >> latter case we need to identify what that was and revert (or fix) it. > > The problem is caused by the support of dynamic memory frequency scaling > which does a good job at keeping memory in a low power state during idle > time. So display controller may not get enough bandwidth at the start of > scanout if it won't request BW beforehand. This problem existed for many > years on T124 and now T20/30 are also affected. The DC of T20 is the > least tolerant to memory bandwidth troubles. > > This problem is not critical, but it hurts user experience since high > resolution modes may not work at all and display output may become > distorted, requiring a DC reset. > >>> Can we get this patch into 5.14? What is the problem? >> >> There was not enough time to review and test this, so I didn't feel >> comfortable picking it up so close to the -rc6 cut-off. I plan to pick >> this up early in the v5.14 release cycle and target v5.15. > > Thank you for the explanation! It's not uncommon to forget about > patches, so the silence worries me. I hoped that both the dynamic freq > scaling and display BW support would be merged around the same time, but > apparently we got a disconnect here. > Reminder ping :)
[PATCH] backlight: pwm_bl: Avoid backlight flicker if backlight control GPIO is input
If the backlight enable GPIO is configured as input, the driver currently
unconditionally forces the GPIO to output-enable. This can cause backlight
flicker on boot e.g. in case the GPIO should not be enabled before the PWM
is configured and is correctly pulled low by external resistor.
Fix this by extending the current check to differentiate between backlight
GPIO enable set as input and set as direction unknown. In case of input,
read the GPIO value to determine the pull resistor placement, set the GPIO
as output, and drive that exact value it was pulled to. In case of unknown
direction, retain previous behavior, that is set the GPIO as output-enable.
Fixes: 3698d7e7d221 ("backlight: pwm_bl: Avoid backlight flicker when probed
from DT")
Signed-off-by: Marek Vasut
Cc: Christian Gmeiner
Cc: Daniel Thompson
Cc: Heiko Stuebner
Cc: Philipp Zabel
Cc: Thierry Reding
Cc: linux-...@vger.kernel.org
Cc: linux-fb...@vger.kernel.org
To: dri-devel@lists.freedesktop.org
---
NOTE: I think this whole auto-detection scheme should just be replaced by a
DT prop, because it is very fragile.
---
drivers/video/backlight/pwm_bl.c | 35 +++-
1 file changed, 25 insertions(+), 10 deletions(-)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index e48fded3e414..7ec992b722eb 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -445,7 +445,7 @@ static int pwm_backlight_probe(struct platform_device *pdev)
struct device_node *node = pdev->dev.of_node;
struct pwm_bl_data *pb;
struct pwm_state state;
- unsigned int i;
+ unsigned int i, dir, val;
int ret;
if (!data) {
@@ -487,16 +487,31 @@ static int pwm_backlight_probe(struct platform_device
*pdev)
}
/*
-* If the GPIO is not known to be already configured as output, that
-* is, if gpiod_get_direction returns either 1 or -EINVAL, change the
-* direction to output and set the GPIO as active.
-* Do not force the GPIO to active when it was already output as it
-* could cause backlight flickering or we would enable the backlight too
-* early. Leave the decision of the initial backlight state for later.
+* If the GPIO is not known to be already configured as output, then:
+* - if the GPIO direction is input, read its current value to find out
+* whether the pin is pulled high or low (it is backlight control, so
+* it cannot be floating), change the direction to output and set the
+* GPIO such that it drives this strapped value.
+* Do not force the GPIO to state which is different than that to
+* which the GPIO was pulled to, this could cause backlight flicker
+* on boot e.g. in case the PWM is not ready yet.
+* - if the GPIO direction is unknown, tahat is, if gpiod_get_direction
+* returns -EINVAL, change the direction to output and set the GPIO
+* as active.
+* Do not force the GPIO to active when it was already output as it
+* could cause backlight flickering or we would enable the backlight
+* too early. Leave the decision of the initial backlight state for
+* later.
*/
- if (pb->enable_gpio &&
- gpiod_get_direction(pb->enable_gpio) != 0)
- gpiod_direction_output(pb->enable_gpio, 1);
+ if (pb->enable_gpio) {
+ dir = gpiod_get_direction(pb->enable_gpio);
+ if (dir != 0) {
+ val = 1;
+ if (dir == 1)
+ val = gpiod_get_value_cansleep(pb->enable_gpio);
+ gpiod_direction_output(pb->enable_gpio, val);
+ }
+ }
pb->power_supply = devm_regulator_get(&pdev->dev, "power");
if (IS_ERR(pb->power_supply)) {
--
2.30.2
[Bug 213779] New: Screen stays blank on resume. from hibernate
https://bugzilla.kernel.org/show_bug.cgi?id=213779 Bug ID: 213779 Summary: Screen stays blank on resume. from hibernate Product: Drivers Version: 2.5 Kernel Version: 5.13 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: alex14...@yahoo.com Regression: No If I close my laptop lid and reopen it, the screen stays blank. Reverting the following commit fixes the issue: commit 9127daa0a8d88a6e6452eb8b7c9be4c3f42a867e Author: Stylon Wang Date: Tue Mar 2 19:25:56 2021 +0800 drm/amd/display: Guard ASSR with internal display flag [Why] ASSR enabling only considers capability declared in DPCD. We also need to check whether the connector is internal. [How] ASSR enabling need to check both DPCD capability and internal display flag. Signed-off-by: Stylon Wang Reviewed-by: Harry Wentland Acked-by: Anson Jacob Tested-by: Dan Wheeler Signed-off-by: Alex Deucher -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 213779] Screen stays blank on resume. from hibernate
https://bugzilla.kernel.org/show_bug.cgi?id=213779 --- Comment #1 from alex14...@yahoo.com --- The graphics card is a RX580. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH v1 01/10] dt-bindings: mediatek: add pseudo-ovl definition for mt8195
Hi, Nancy:
Nancy.Lin 於 2021年7月17日 週六 下午5:04寫道：
>
> 1. Add pseudo-ovl definition file for mt8195 display.
> 2. Add mediatek,pseudo-ovl.yaml to decribe pseudo-ovl module in details.
>
> Signed-off-by: Nancy.Lin
> ---
> .../display/mediatek/mediatek,disp.yaml | 5 +
> .../display/mediatek/mediatek,pseudo-ovl.yaml | 105 ++
> 2 files changed, 110 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/mediatek/mediatek,pseudo-ovl.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.yaml
> b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.yaml
> index aac1796e3f6b..bb6d28572b48 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.yaml
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.yaml
> @@ -230,6 +230,11 @@ properties:
>- items:
>- const: mediatek,mt8173-disp-od
>
> + # PSEUDO-OVL: see
> Documentation/devicetree/bindings/display/mediatek/mediatek,pseudo-ovl.yaml
> + # for details.
> + - items:
> + - const: mediatek,mt8195-disp-pseudo-ovl
> +
>reg:
> description: Physical base address and length of the function block
> register space.
>
> diff --git
> a/Documentation/devicetree/bindings/display/mediatek/mediatek,pseudo-ovl.yaml
> b/Documentation/devicetree/bindings/display/mediatek/mediatek,pseudo-ovl.yaml
> new file mode 100644
> index ..9059d96ce70e
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/display/mediatek/mediatek,pseudo-ovl.yaml
> @@ -0,0 +1,105 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/mediatek/mediatek,pseudo-ovl.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: mediatek pseudo ovl Device Tree Bindings
> +
> +maintainers:
> + - CK Hu
> + - Nancy.Lin
> +
> +description: |
> + The Mediatek pseudo ovl function block is composed of eight RDMA and
> + four MERGE devices. It's encapsulated as an overlay device, which supports
> + 4 layers.
> +
> +properties:
> + compatible:
> +oneOf:
> + # pseudo ovl controller
> + - items:
> + - const: mediatek,mt8195-disp-pseudo-ovl
> + # RDMA: read DMA
> + - items:
> + - const: mediatek,mt8195-vdo1-rdma
> + # MERGE: merge streams from two RDMA sources
> + - items:
> + - const: mediatek,mt8195-vdo1-merge
> + reg:
> +maxItems: 1
> + interrupts:
> +maxItems: 1
> + iommus:
> +description: The compatible property is DMA function blocks.
> + Should point to the respective IOMMU block with master port as
> argument,
> + see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for
> + details.
> +maxItems: 1
> + clocks:
> +maxItems: 2
> + clock-names:
> +maxItems: 2
> + power-domains:
> +maxItems: 1
> + mediatek,gce-client-reg:
> +$ref: /schemas/types.yaml#/definitions/phandle-array
> +description: The register of display function block to be set by gce.
> + There are 4 arguments in this property, gce node, subsys id, offset and
> + register size. The subsys id is defined in the gce header of each chips
> + include/include/dt-bindings/gce/-gce.h, mapping to the register
> of
> + display function block.
> +
> +allOf:
> + - if:
> + properties:
> +compatible:
> + contains:
> +const:
> + - mediatek,mt8195-vdo1-merge
> +
> +then:
> + properties:
> +clocks:
> + items:
> +- description: merge clock
> +- description: merge async clock
> +clock-names:
> + items:
> +- const: merge
> +- const: merge_async
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +
> +vdo1_rdma@1c104000 {
> +compatible = "mediatek,mt8195-vdo1-rdma",
> + "mediatek,mt8195-disp-pseudo-ovl";
Do not create pseudo or virtual device, so just leave the
"mediatek,mt8195-vdo1-rdma".
Regards,
Chun-Kuang.
> +reg = <0 0x1c104000 0 0x1000>;
> +interrupts = ;
> +clocks = <&vdosys1 CLK_VDO1_MDP_RDMA0>;
> +power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS1>;
> +iommus = <&iommu_vdo M4U_PORT_L2_MDP_RDMA0>;
> +mediatek,gce-client-reg = <&gce1 SUBSYS_1c10 0x4000 0x1000>;
> +};
> +
> +disp_vpp_merge@1c10c000 {
> +compatible = "mediatek,mt8195-vdo1-merge";
> +reg = <0 0x1c10c000 0 0x1000>;
> +interrupts = ;
> +clocks = <&vdosys1 CLK_VDO1_VPP_MERGE0>,
> + <&vdosys1 CLK_VDO1_MERGE0_DL_ASYNC>;
> +clock-names = "merge","merge_async";
> +power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS1>;
> +mediatek
Re: [PATCH v1 06/10] drm/mediatek: add ETHDR support for MT8195
Hi, Nancy:
Nancy.Lin 於 2021年7月17日 週六 下午5:04寫道：
>
> Add ETHDR module files:
> ETHDR is designed for HDR video and graphics conversion in the external
> display path. It handles multiple HDR input types and performs tone
> mapping, color space/color format conversion, and then combines
> different layers, output the required HDR or SDR signal to the
> subsequent display path.
>
> Signed-off-by: Nancy.Lin
> ---
> drivers/gpu/drm/mediatek/Makefile | 3 +-
> drivers/gpu/drm/mediatek/mtk_disp_drv.h | 8 +
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 11 +
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 +
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 4 +
> drivers/gpu/drm/mediatek/mtk_drm_drv.h | 1 +
> drivers/gpu/drm/mediatek/mtk_ethdr.c| 537
> drivers/gpu/drm/mediatek/mtk_ethdr.h| 20 +
> 8 files changed, 584 insertions(+), 1 deletion(-)
> create mode 100644 drivers/gpu/drm/mediatek/mtk_ethdr.c
> create mode 100644 drivers/gpu/drm/mediatek/mtk_ethdr.h
>
> diff --git a/drivers/gpu/drm/mediatek/Makefile
> b/drivers/gpu/drm/mediatek/Makefile
> index 27c89847d43b..fcce08710cef 100644
> --- a/drivers/gpu/drm/mediatek/Makefile
> +++ b/drivers/gpu/drm/mediatek/Makefile
> @@ -13,7 +13,8 @@ mediatek-drm-y := mtk_disp_ccorr.o \
> mtk_drm_gem.o \
> mtk_drm_plane.o \
> mtk_dsi.o \
> - mtk_dpi.o
> + mtk_dpi.o \
> + mtk_ethdr.o
>
> obj-$(CONFIG_DRM_MEDIATEK) += mediatek-drm.o
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> index 3e27ce7fef57..7227ffbc3eae 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> @@ -105,4 +105,12 @@ void mtk_rdma_enable_vblank(struct device *dev,
> void *vblank_cb_data);
> void mtk_rdma_disable_vblank(struct device *dev);
>
> +int mtk_ethdr_clk_enable(struct device *dev);
> +void mtk_ethdr_clk_disable(struct device *dev);
> +void mtk_ethdr_config(struct device *dev, unsigned int w,
> + unsigned int h, unsigned int vrefresh,
> + unsigned int bpc, struct cmdq_pkt *cmdq_pkt);
> +void mtk_ethdr_start(struct device *dev);
> +void mtk_ethdr_stop(struct device *dev);
> +
> #endif
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> index 9125d0f6352f..3fa86f12feb4 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> @@ -355,6 +355,14 @@ static const struct mtk_ddp_comp_funcs ddp_ufoe = {
> .start = mtk_ufoe_start,
> };
>
> +static const struct mtk_ddp_comp_funcs ddp_ethdr = {
> + .clk_enable = mtk_ethdr_clk_enable,
> + .clk_disable = mtk_ethdr_clk_disable,
> + .config = mtk_ethdr_config,
> + .start = mtk_ethdr_start,
> + .stop = mtk_ethdr_stop,
> +};
> +
> static const char * const mtk_ddp_comp_stem[MTK_DDP_COMP_TYPE_MAX] = {
> [MTK_DISP_OVL] = "ovl",
> [MTK_DISP_OVL_2L] = "ovl-2l",
> @@ -363,6 +371,7 @@ static const char * const
> mtk_ddp_comp_stem[MTK_DDP_COMP_TYPE_MAX] = {
> [MTK_DISP_COLOR] = "color",
> [MTK_DISP_CCORR] = "ccorr",
> [MTK_DISP_AAL] = "aal",
> + [MTK_DISP_ETHDR] = "ethdr",
> [MTK_DISP_GAMMA] = "gamma",
> [MTK_DISP_DITHER] = "dither",
> [MTK_DISP_UFOE] = "ufoe",
> @@ -399,6 +408,7 @@ static const struct mtk_ddp_comp_match
> mtk_ddp_matches[DDP_COMPONENT_ID_MAX] = {
> [DDP_COMPONENT_DSI1]= { MTK_DSI,1, &ddp_dsi },
> [DDP_COMPONENT_DSI2]= { MTK_DSI,2, &ddp_dsi },
> [DDP_COMPONENT_DSI3]= { MTK_DSI,3, &ddp_dsi },
> + [DDP_COMPONENT_ETHDR] = { MTK_DISP_ETHDR, 0, &ddp_ethdr},
> [DDP_COMPONENT_GAMMA] = { MTK_DISP_GAMMA, 0, &ddp_gamma },
> [DDP_COMPONENT_MERGE0] = { MTK_DISP_MERGE, 0, &ddp_merge },
> [DDP_COMPONENT_MERGE1] = { MTK_DISP_MERGE, 1, &ddp_merge },
> @@ -536,6 +546,7 @@ int mtk_ddp_comp_init(struct device_node *node, struct
> mtk_ddp_comp *comp,
> type == MTK_DISP_CCORR ||
> type == MTK_DISP_COLOR ||
> type == MTK_DISP_DSC ||
> + type == MTK_DISP_ETHDR ||
> type == MTK_DISP_GAMMA ||
> type == MTK_DISP_MERGE ||
> type == MTK_DISP_OVL ||
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> index 0afd78c0bc92..f55efba6e744 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> @@ -36,6 +36,7 @@ enum mtk_ddp_comp_type {
> MTK_DISP_BLS,
> MTK_DISP_DSC,
> MTK_DISP_MERGE,
> + MTK_DISP_ETHDR,
> MTK_DDP_COMP_TYPE_MAX,
> };
>
> diff --git a/drivers/gpu/d
[PATCH] fbdev: simplefb: limit its use to DRM_SIMPLEDRM=n
When DRM_SIMPLEDRM=m, all of FB_CFB_{FILLRECT,COPYAREA,IMAGEBLIT} are =m,
causing undefined references in fbdev/simplefb.o.
By restricting FB_SIMPLEFB to be set only when DRM_SIMPLEDRM is not set,
the FB_CFB_* symbols are =y and the build completes without these
undefined references.
IOW, really "disable simplefb if simpledrm has been selected".
or1k-linux-ld: drivers/video/fbdev/simplefb.o:(.rodata+0x2c): undefined
reference to `cfb_fillrect'
or1k-linux-ld: drivers/video/fbdev/simplefb.o:(.rodata+0x30): undefined
reference to `cfb_copyarea'
or1k-linux-ld: drivers/video/fbdev/simplefb.o:(.rodata+0x34): undefined
reference to `cfb_imageblit'
Fixes: 11e8f5fd223b ("drm: Add simpledrm driver")
Signed-off-by: Randy Dunlap
Reported-by: kernel test robot
Cc: Hans de Goede
Cc: linux-fb...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: Thomas Zimmermann
---
drivers/video/fbdev/Kconfig |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next-20210716.orig/drivers/video/fbdev/Kconfig
+++ linux-next-20210716/drivers/video/fbdev/Kconfig
@@ -2192,7 +2192,7 @@ config FB_HYPERV
config FB_SIMPLE
bool "Simple framebuffer support"
- depends on (FB = y) && !DRM_SIMPLEDRM
+ depends on (FB = y) && DRM_SIMPLEDRM=n
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
Re: [PATCH v3 0/2] allow simple{fb, drm} drivers to be used on non-x86 EFI platforms
On Thu, 15 Jul 2021 at 18:11, Thomas Zimmermann wrote:
>
> Hi
>
> Am 13.07.21 um 18:59 schrieb Javier Martinez Canillas:
> > On 6/25/21 3:09 PM, Javier Martinez Canillas wrote:
> >> The simplefb and simpledrm drivers match against a "simple-framebuffer"
> >> device, but for aarch64 this is only registered when using Device Trees
> >> and there's a node with a "simple-framebuffer" compatible string.
> >>
> >> There is no code to register a "simple-framebuffer" platform device when
> >> using EFI instead. In fact, the only platform device that's registered in
> >> this case is an "efi-framebuffer", which means that the efifb driver is
> >> the only driver supported to have an early console with EFI on aarch64.
> >>
> >> The x86 architecture platform has a Generic System Framebuffers (sysfb)
> >> support, that register a system frambuffer platform device. It either
> >> registers a "simple-framebuffer" for the simple{fb,drm} drivers or legacy
> >> VGA/EFI FB devices for the vgafb/efifb drivers.
> >>
> >> The sysfb is generic enough to be reused by other architectures and can be
> >> moved out of the arch/x86 directory to drivers/firmware, allowing the EFI
> >> logic used by non-x86 architectures to be folded into sysfb as well.
> >>
> >
> > Any more comments on this series? It would be nice for this to land so the
> > simpledrm driver could be used on aarch64 EFI systems as well.
> >
> > The patches have already been acked by x86 and DRM folks.
>
> Time to get this merged, I'd say. People are asking for these patches
> already.
Can we just merge via drm-misc and make sure the acks are present and
I'll deal with the fallout if any.
Dave.
[PATCH] dma_buf: remove dmabuf sysfs teardown before release/detach
From: Guangming Cao Dmabuf sysfs stat is used for dmabuf info track. but these file maybe still use after buffer release/detach, should clear it before buffer release/detach. Signed-off-by: Guangming Cao --- drivers/dma-buf/dma-buf.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index 510b42771974..9fa4620bd4bb 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -76,12 +76,12 @@ static void dma_buf_release(struct dentry *dentry) */ BUG_ON(dmabuf->cb_shared.active || dmabuf->cb_excl.active); + dma_buf_stats_teardown(dmabuf); dmabuf->ops->release(dmabuf); if (dmabuf->resv == (struct dma_resv *)&dmabuf[1]) dma_resv_fini(dmabuf->resv); - dma_buf_stats_teardown(dmabuf); module_put(dmabuf->owner); kfree(dmabuf->name); kfree(dmabuf); @@ -875,10 +875,11 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment *attach) dma_resv_lock(dmabuf->resv, NULL); list_del(&attach->node); dma_resv_unlock(dmabuf->resv); + + dma_buf_attach_stats_teardown(attach); if (dmabuf->ops->detach) dmabuf->ops->detach(dmabuf, attach); - dma_buf_attach_stats_teardown(attach); kfree(attach); } EXPORT_SYMBOL_GPL(dma_buf_detach); -- 2.17.1
Re: [git pull] drm fixes for 5.14-rc2
Am 17.07.21 um 23:43 schrieb Kirill A. Shutemov: On Fri, Jul 16, 2021 at 01:41:18PM +1000, Dave Airlie wrote: Hi Linus, Regular rc2 fixes though a bit more than usual at rc2 stage, people must have been testing early or else some fixes from last week got a bit laggy. There is one larger change in the amd fixes to amalgamate some power management code on the newer chips with the code from the older chips, it should only affects chips where support was introduced in rc1 and it should make future fixes easier to maintain probably a good idea to merge it now. Otherwise it's mostly fixes across the board. Dave. drm-fixes-2021-07-16: drm fixes for 5.14-rc2 Dave, Daniel, My fault, I've pushed it to drm-misc-next after the branch of. Just cherry-picked that to drm-misc-fixes. Should be in the next -rc Thanks for the notice, Christian. Looks like the fix[1] for nouveau regression[2] is missing. Hm? [1] https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fnouveau%2F20210609172902.1937-1-christian.koenig%40amd.com%2F&data=04%7C01%7Cchristian.koenig%40amd.com%7Cdfa76642807a4953a9dc08d9496bda6a%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637621549856073674%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8wYkOJYcSoLt3P6cFdTsaYrvX2UEhm7M5RKkaSn5dws%3D&reserved=0 [2] https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Flkml%2FYOC4uekpD7iA3xPi%40Red%2FT%2F%23u&data=04%7C01%7Cchristian.koenig%40amd.com%7Cdfa76642807a4953a9dc08d9496bda6a%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637621549856073674%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=h5QYbNjhPDAqioojBPTY7uVvfJx6XwEV7ic8rwuMxMc%3D&reserved=0
