Re: [PATCH] drm/vc4: hvs: Pull the state of all the CRTCs prior to PV muxing
Hi Maxime,
On 9/17/20 9:16 PM, Maxime Ripard wrote:
> The vc4 display engine has a first controller called the HVS that will
> perform the composition of the planes. That HVS has 3 FIFOs and can
> therefore compose planes for up to three outputs. The timings part is
> generated through a component called the Pixel Valve, and the BCM2711 has 6
> of them.
>
> Thus, the HVS has some bits to control which FIFO gets output to which
> Pixel Valve. The current code supports that muxing by looking at all the
> CRTCs in a new DRM atomic state in atomic_check, and given the set of
> contraints that we have, assigns FIFOs to CRTCs or reject the mode
> entirely. The actual muxing will occur during atomic_commit.
>
> However, that doesn't work if only a fraction of the CRTCs' state is
> updated in that state, since it will ignore the CRTCs that are kept running
> unmodified, and will thus unassign its associated FIFO, and later disable
> it.
>
> In order to make the code work as expected, let's pull the CRTC state of
> all the enabled CRTC in our atomic_check so that we can operate on all the
> running CRTCs, no matter whether they are affected by the new state or not.
>
> Cc: Hoegeun Kwon
> Fixes: 87ebcd42fb7b ("drm/vc4: crtc: Assign output to channel automatically")
> Signed-off-by: Maxime Ripard
Thanks for the quick patch and detailed explanation.
Tested-by: Hoegeun Kwon
Reviewed-by: Hoegeun Kwon
Best regards,
Hoegeun
> ---
> drivers/gpu/drm/vc4/vc4_kms.c | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
> index 16e233e1406e..af3ee3dcdab6 100644
> --- a/drivers/gpu/drm/vc4/vc4_kms.c
> +++ b/drivers/gpu/drm/vc4/vc4_kms.c
> @@ -620,6 +620,23 @@ vc4_atomic_check(struct drm_device *dev, struct
> drm_atomic_state *state)
> struct drm_crtc *crtc;
> int i, ret;
>
> + /*
> + * Since the HVS FIFOs are shared across all the pixelvalves and
> + * the TXP (and thus all the CRTCs), we need to pull the current
> + * state of all the enabled CRTCs so that an update to a single
> + * CRTC still keeps the previous FIFOs enabled and assigned to
> + * the same CRTCs, instead of evaluating only the CRTC being
> + * modified.
> + */
> + list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
> + if (!crtc->state->enable)
> + continue;
> +
> + crtc_state = drm_atomic_get_crtc_state(state, crtc);
> + if (IS_ERR(crtc_state))
> + return PTR_ERR(crtc_state);
> + }
> +
> for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
> struct vc4_crtc_state *vc4_crtc_state =
> to_vc4_crtc_state(crtc_state);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] dma-buf: Flag vmap'ed memory as system or I/O memory
Hello Thomas, On Mon, 14 Sep 2020 at 16:55, Thomas Zimmermann wrote: > > Dma-buf provides vmap() and vunmap() for retrieving and releasing mappings > of dma-buf memory in kernel address space. The functions operate with plain > addresses and the assumption is that the memory can be accessed with load > and store operations. This is not the case on some architectures (e.g., > sparc64) where I/O memory can only be accessed with dedicated instructions. > > This patchset introduces struct dma_buf_map, which contains the address of > a buffer and a flag that tells whether system- or I/O-memory instructions > are required. Thank you for the patchset - it is a really nice, clean bit to add! > > Some background: updating the DRM framebuffer console on sparc64 makes the > kernel panic. This is because the framebuffer memory cannot be accessed with > system-memory instructions. We currently employ a workaround in DRM to > address this specific problem. [1] > > To resolve the problem, we'd like to address it at the most common point, > which is the dma-buf framework. The dma-buf mapping ideally knows if I/O > instructions are required and exports this information to it's users. The > new structure struct dma_buf_map stores the buffer address and a flag that > signals I/O memory. Affected users of the buffer (e.g., drivers, frameworks) > can then access the memory accordingly. > > This patchset only introduces struct dma_buf_map, and updates struct dma_buf > and it's interfaces. Further patches can update dma-buf users. For example, > there's a prototype patchset for DRM that fixes the framebuffer problem. [2] > > Further work: TTM, one of DRM's memory managers, already exports an > is_iomem flag of its own. It could later be switched over to exporting struct > dma_buf_map, thus simplifying some code. Several DRM drivers expect their > fbdev console to operate on I/O memory. These could possibly be switched over > to the generic fbdev emulation, as soon as the generic code uses struct > dma_buf_map. > > [1] https://lore.kernel.org/dri-devel/20200725191012.ga434...@ravnborg.org/ > [2] > https://lore.kernel.org/dri-devel/20200806085239.4606-1-tzimmerm...@suse.de/ > > Thomas Zimmermann (3): > dma-buf: Add struct dma-buf-map for storing struct dma_buf.vaddr_ptr > dma-buf: Use struct dma_buf_map in dma_buf_vmap() interfaces > dma-buf: Use struct dma_buf_map in dma_buf_vunmap() interfaces FWIW, for the series, please feel free to add my Acked-by: Sumit Semwal > > Documentation/driver-api/dma-buf.rst | 3 + > drivers/dma-buf/dma-buf.c | 40 +++--- > drivers/gpu/drm/drm_gem_cma_helper.c | 16 ++- > drivers/gpu/drm/drm_gem_shmem_helper.c| 17 ++- > drivers/gpu/drm/drm_prime.c | 14 +- > drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 13 +- > drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 13 +- > .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 18 ++- > drivers/gpu/drm/tegra/gem.c | 23 ++-- > .../common/videobuf2/videobuf2-dma-contig.c | 17 ++- > .../media/common/videobuf2/videobuf2-dma-sg.c | 19 ++- > .../common/videobuf2/videobuf2-vmalloc.c | 21 ++- > include/drm/drm_prime.h | 5 +- > include/linux/dma-buf-map.h | 126 ++ > include/linux/dma-buf.h | 11 +- > 15 files changed, 274 insertions(+), 82 deletions(-) > create mode 100644 include/linux/dma-buf-map.h > > -- > 2.28.0 > Best, Sumit. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
linux-next: manual merge of the drm-msm tree with the drm tree
Hi all,
Today's linux-next merge of the drm-msm tree got a conflict in:
drivers/gpu/drm/msm/msm_gem.c
between commit:
7690a33f22ab ("drm: msm: fix common struct sg_table related issues")
from the drm tree and commit:
e1bf29e022fb ("drm/msm: drop cache sync hack")
from the drm-msm tree.
I fixed it up (see below) 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.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/msm/msm_gem.c
index e47958c3704a,3cb7aeb93fd3..
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@@ -52,23 -52,16 +52,14 @@@ static void sync_for_device(struct msm_
{
struct device *dev = msm_obj->base.dev->dev;
- if (get_dma_ops(dev) && IS_ENABLED(CONFIG_ARM64)) {
- dma_sync_sgtable_for_device(dev, msm_obj->sgt,
- DMA_BIDIRECTIONAL);
- } else {
- dma_map_sgtable(dev, msm_obj->sgt, DMA_BIDIRECTIONAL, 0);
- }
- dma_map_sg(dev, msm_obj->sgt->sgl,
- msm_obj->sgt->nents, DMA_BIDIRECTIONAL);
++ dma_map_sgtable(dev, msm_obj->sgt, DMA_BIDIRECTIONAL, 0);
}
static void sync_for_cpu(struct msm_gem_object *msm_obj)
{
struct device *dev = msm_obj->base.dev->dev;
- if (get_dma_ops(dev) && IS_ENABLED(CONFIG_ARM64)) {
- dma_sync_sgtable_for_cpu(dev, msm_obj->sgt, DMA_BIDIRECTIONAL);
- } else {
- dma_unmap_sgtable(dev, msm_obj->sgt, DMA_BIDIRECTIONAL, 0);
- }
- dma_unmap_sg(dev, msm_obj->sgt->sgl,
- msm_obj->sgt->nents, DMA_BIDIRECTIONAL);
++ dma_unmap_sgtable(dev, msm_obj->sgt, DMA_BIDIRECTIONAL, 0);
}
/* allocate pages from VRAM carveout, used when no IOMMU: */
pgp9y_D8etOKJ.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.4 31/64] drm/amdgpu: increase atombios cmd timeout
From: John Clements
[ Upstream commit 1b3460a8b19688ad3033b75237d40fa580a5a953 ]
mitigates race condition on BACO reset between GPU bootcode and driver reload
Reviewed-by: Hawking Zhang
Signed-off-by: John Clements
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/atom.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/atom.c
b/drivers/gpu/drm/amd/amdgpu/atom.c
index 1b50e6c13fb3f..5fbf99d600587 100644
--- a/drivers/gpu/drm/amd/amdgpu/atom.c
+++ b/drivers/gpu/drm/amd/amdgpu/atom.c
@@ -748,8 +748,8 @@ static void atom_op_jump(atom_exec_context *ctx, int *ptr,
int arg)
cjiffies = jiffies;
if (time_after(cjiffies, ctx->last_jump_jiffies)) {
cjiffies -= ctx->last_jump_jiffies;
- if ((jiffies_to_msecs(cjiffies) > 5000)) {
- DRM_ERROR("atombios stuck in loop for
more than 5secs aborting\n");
+ if ((jiffies_to_msecs(cjiffies) > 1)) {
+ DRM_ERROR("atombios stuck in loop for
more than 10secs aborting\n");
ctx->abort = true;
}
} else {
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.4 27/64] drm/omap: fix possible object reference leak
From: Wen Yang [ Upstream commit 47340e46f34a3b1d80e40b43ae3d7a8da34a3541 ] The call to of_find_matching_node returns a node pointer with refcount incremented thus it must be explicitly decremented after the last usage. Detected by coccinelle with the following warnings: drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c:212:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 209, but without a corresponding object release within this function. drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c:237:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 209, but without a corresponding object release within this function. Signed-off-by: Wen Yang Reviewed-by: Laurent Pinchart Reviewed-by: Mukesh Ojha Cc: Tomi Valkeinen Cc: David Airlie Cc: Daniel Vetter Cc: Sebastian Reichel Cc: Laurent Pinchart Cc: dri-devel@lists.freedesktop.org Cc: linux-ker...@vger.kernel.org Cc: Markus Elfring Signed-off-by: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/1554692313-28882-2-git-send-email-wen.yan...@zte.com.cn Signed-off-by: Sasha Levin --- drivers/video/fbdev/omap2/dss/omapdss-boot-init.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/video/fbdev/omap2/dss/omapdss-boot-init.c b/drivers/video/fbdev/omap2/dss/omapdss-boot-init.c index 8b6f6d5fdd68b..43186fa8a13c9 100644 --- a/drivers/video/fbdev/omap2/dss/omapdss-boot-init.c +++ b/drivers/video/fbdev/omap2/dss/omapdss-boot-init.c @@ -194,7 +194,7 @@ static int __init omapdss_boot_init(void) dss = of_find_matching_node(NULL, omapdss_of_match); if (dss == NULL || !of_device_is_available(dss)) - return 0; + goto put_node; omapdss_walk_device(dss, true); @@ -221,6 +221,8 @@ static int __init omapdss_boot_init(void) kfree(n); } +put_node: + of_node_put(dss); return 0; } -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.9 47/90] drm/amdgpu: increase atombios cmd timeout
From: John Clements
[ Upstream commit 1b3460a8b19688ad3033b75237d40fa580a5a953 ]
mitigates race condition on BACO reset between GPU bootcode and driver reload
Reviewed-by: Hawking Zhang
Signed-off-by: John Clements
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/atom.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/atom.c
b/drivers/gpu/drm/amd/amdgpu/atom.c
index 1b50e6c13fb3f..5fbf99d600587 100644
--- a/drivers/gpu/drm/amd/amdgpu/atom.c
+++ b/drivers/gpu/drm/amd/amdgpu/atom.c
@@ -748,8 +748,8 @@ static void atom_op_jump(atom_exec_context *ctx, int *ptr,
int arg)
cjiffies = jiffies;
if (time_after(cjiffies, ctx->last_jump_jiffies)) {
cjiffies -= ctx->last_jump_jiffies;
- if ((jiffies_to_msecs(cjiffies) > 5000)) {
- DRM_ERROR("atombios stuck in loop for
more than 5secs aborting\n");
+ if ((jiffies_to_msecs(cjiffies) > 1)) {
+ DRM_ERROR("atombios stuck in loop for
more than 10secs aborting\n");
ctx->abort = true;
}
} else {
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.4 03/64] gma/gma500: fix a memory disclosure bug due to uninitialized bytes
From: Kangjie Lu
[ Upstream commit 57a25a5f754ce27da2cfa6f413cfd366f878db76 ]
`best_clock` is an object that may be sent out. Object `clock`
contains uninitialized bytes that are copied to `best_clock`,
which leads to memory disclosure and information leak.
Signed-off-by: Kangjie Lu
Signed-off-by: Daniel Vetter
Link:
https://patchwork.freedesktop.org/patch/msgid/20191018042953.31099-1-k...@umn.edu
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/gma500/cdv_intel_display.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/gma500/cdv_intel_display.c
b/drivers/gpu/drm/gma500/cdv_intel_display.c
index 7d47b3d5cc0d0..54d554d720004 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_display.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_display.c
@@ -415,6 +415,8 @@ static bool cdv_intel_find_dp_pll(const struct gma_limit_t
*limit,
struct gma_crtc *gma_crtc = to_gma_crtc(crtc);
struct gma_clock_t clock;
+ memset(&clock, 0, sizeof(clock));
+
switch (refclk) {
case 27000:
if (target < 20) {
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.9 38/90] drm/omap: fix possible object reference leak
From: Wen Yang [ Upstream commit 47340e46f34a3b1d80e40b43ae3d7a8da34a3541 ] The call to of_find_matching_node returns a node pointer with refcount incremented thus it must be explicitly decremented after the last usage. Detected by coccinelle with the following warnings: drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c:212:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 209, but without a corresponding object release within this function. drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c:237:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 209, but without a corresponding object release within this function. Signed-off-by: Wen Yang Reviewed-by: Laurent Pinchart Reviewed-by: Mukesh Ojha Cc: Tomi Valkeinen Cc: David Airlie Cc: Daniel Vetter Cc: Sebastian Reichel Cc: Laurent Pinchart Cc: dri-devel@lists.freedesktop.org Cc: linux-ker...@vger.kernel.org Cc: Markus Elfring Signed-off-by: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/1554692313-28882-2-git-send-email-wen.yan...@zte.com.cn Signed-off-by: Sasha Levin --- drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c b/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c index 136d30484d023..46111e9ee9a25 100644 --- a/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c +++ b/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c @@ -194,7 +194,7 @@ static int __init omapdss_boot_init(void) dss = of_find_matching_node(NULL, omapdss_of_match); if (dss == NULL || !of_device_is_available(dss)) - return 0; + goto put_node; omapdss_walk_device(dss, true); @@ -219,6 +219,8 @@ static int __init omapdss_boot_init(void) kfree(n); } +put_node: + of_node_put(dss); return 0; } -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.9 03/90] gma/gma500: fix a memory disclosure bug due to uninitialized bytes
From: Kangjie Lu
[ Upstream commit 57a25a5f754ce27da2cfa6f413cfd366f878db76 ]
`best_clock` is an object that may be sent out. Object `clock`
contains uninitialized bytes that are copied to `best_clock`,
which leads to memory disclosure and information leak.
Signed-off-by: Kangjie Lu
Signed-off-by: Daniel Vetter
Link:
https://patchwork.freedesktop.org/patch/msgid/20191018042953.31099-1-k...@umn.edu
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/gma500/cdv_intel_display.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/gma500/cdv_intel_display.c
b/drivers/gpu/drm/gma500/cdv_intel_display.c
index 17db4b4749d5a..2e8479744ca4a 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_display.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_display.c
@@ -415,6 +415,8 @@ static bool cdv_intel_find_dp_pll(const struct gma_limit_t
*limit,
struct gma_crtc *gma_crtc = to_gma_crtc(crtc);
struct gma_clock_t clock;
+ memset(&clock, 0, sizeof(clock));
+
switch (refclk) {
case 27000:
if (target < 20) {
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.14 107/127] drm/nouveau/debugfs: fix runtime pm imbalance on error
From: Dinghao Liu
[ Upstream commit 00583fbe8031f69bba8b0a9a861efb75fb7131af ]
pm_runtime_get_sync() increments the runtime PM usage counter even
the call returns an error code. Thus a pairing decrement is needed
on the error handling path to keep the counter balanced.
Signed-off-by: Dinghao Liu
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nouveau_debugfs.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_debugfs.c
b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
index 9635704a1d864..4561a786fab07 100644
--- a/drivers/gpu/drm/nouveau/nouveau_debugfs.c
+++ b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
@@ -161,8 +161,11 @@ nouveau_debugfs_pstate_set(struct file *file, const char
__user *ubuf,
}
ret = pm_runtime_get_sync(drm->dev);
- if (ret < 0 && ret != -EACCES)
+ if (ret < 0 && ret != -EACCES) {
+ pm_runtime_put_autosuspend(drm->dev);
return ret;
+ }
+
ret = nvif_mthd(ctrl, NVIF_CONTROL_PSTATE_USER, &args, sizeof(args));
pm_runtime_put_autosuspend(drm->dev);
if (ret < 0)
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.14 060/127] drm/amdgpu: increase atombios cmd timeout
From: John Clements
[ Upstream commit 1b3460a8b19688ad3033b75237d40fa580a5a953 ]
mitigates race condition on BACO reset between GPU bootcode and driver reload
Reviewed-by: Hawking Zhang
Signed-off-by: John Clements
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/atom.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/atom.c
b/drivers/gpu/drm/amd/amdgpu/atom.c
index d69aa2e179bbe..e4874cc209ef4 100644
--- a/drivers/gpu/drm/amd/amdgpu/atom.c
+++ b/drivers/gpu/drm/amd/amdgpu/atom.c
@@ -742,8 +742,8 @@ static void atom_op_jump(atom_exec_context *ctx, int *ptr,
int arg)
cjiffies = jiffies;
if (time_after(cjiffies, ctx->last_jump_jiffies)) {
cjiffies -= ctx->last_jump_jiffies;
- if ((jiffies_to_msecs(cjiffies) > 5000)) {
- DRM_ERROR("atombios stuck in loop for
more than 5secs aborting\n");
+ if ((jiffies_to_msecs(cjiffies) > 1)) {
+ DRM_ERROR("atombios stuck in loop for
more than 10secs aborting\n");
ctx->abort = true;
}
} else {
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.14 047/127] drm/omap: fix possible object reference leak
From: Wen Yang [ Upstream commit 47340e46f34a3b1d80e40b43ae3d7a8da34a3541 ] The call to of_find_matching_node returns a node pointer with refcount incremented thus it must be explicitly decremented after the last usage. Detected by coccinelle with the following warnings: drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c:212:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 209, but without a corresponding object release within this function. drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c:237:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 209, but without a corresponding object release within this function. Signed-off-by: Wen Yang Reviewed-by: Laurent Pinchart Reviewed-by: Mukesh Ojha Cc: Tomi Valkeinen Cc: David Airlie Cc: Daniel Vetter Cc: Sebastian Reichel Cc: Laurent Pinchart Cc: dri-devel@lists.freedesktop.org Cc: linux-ker...@vger.kernel.org Cc: Markus Elfring Signed-off-by: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/1554692313-28882-2-git-send-email-wen.yan...@zte.com.cn Signed-off-by: Sasha Levin --- drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c b/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c index bf626acae2712..cd8e9b799b9a5 100644 --- a/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c +++ b/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c @@ -193,7 +193,7 @@ static int __init omapdss_boot_init(void) dss = of_find_matching_node(NULL, omapdss_of_match); if (dss == NULL || !of_device_is_available(dss)) - return 0; + goto put_node; omapdss_walk_device(dss, true); @@ -218,6 +218,8 @@ static int __init omapdss_boot_init(void) kfree(n); } +put_node: + of_node_put(dss); return 0; } -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.14 004/127] gma/gma500: fix a memory disclosure bug due to uninitialized bytes
From: Kangjie Lu
[ Upstream commit 57a25a5f754ce27da2cfa6f413cfd366f878db76 ]
`best_clock` is an object that may be sent out. Object `clock`
contains uninitialized bytes that are copied to `best_clock`,
which leads to memory disclosure and information leak.
Signed-off-by: Kangjie Lu
Signed-off-by: Daniel Vetter
Link:
https://patchwork.freedesktop.org/patch/msgid/20191018042953.31099-1-k...@umn.edu
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/gma500/cdv_intel_display.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/gma500/cdv_intel_display.c
b/drivers/gpu/drm/gma500/cdv_intel_display.c
index 17db4b4749d5a..2e8479744ca4a 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_display.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_display.c
@@ -415,6 +415,8 @@ static bool cdv_intel_find_dp_pll(const struct gma_limit_t
*limit,
struct gma_crtc *gma_crtc = to_gma_crtc(crtc);
struct gma_clock_t clock;
+ memset(&clock, 0, sizeof(clock));
+
switch (refclk) {
case 27000:
if (target < 20) {
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 172/206] drm/nouveau: fix runtime pm imbalance on error
From: Dinghao Liu
[ Upstream commit d7372dfb3f7f1602b87e0663e8b8646da23ebca7 ]
pm_runtime_get_sync() increments the runtime PM usage counter even
the call returns an error code. Thus a pairing decrement is needed
on the error handling path to keep the counter balanced.
Signed-off-by: Dinghao Liu
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nouveau_gem.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index 791f970714ed6..a98fccb0d32f9 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -82,8 +82,10 @@ nouveau_gem_object_open(struct drm_gem_object *gem, struct
drm_file *file_priv)
return ret;
ret = pm_runtime_get_sync(dev);
- if (ret < 0 && ret != -EACCES)
+ if (ret < 0 && ret != -EACCES) {
+ pm_runtime_put_autosuspend(dev);
goto out;
+ }
ret = nouveau_vma_new(nvbo, &cli->vmm, &vma);
pm_runtime_mark_last_busy(dev);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 171/206] drm/nouveau/debugfs: fix runtime pm imbalance on error
From: Dinghao Liu
[ Upstream commit 00583fbe8031f69bba8b0a9a861efb75fb7131af ]
pm_runtime_get_sync() increments the runtime PM usage counter even
the call returns an error code. Thus a pairing decrement is needed
on the error handling path to keep the counter balanced.
Signed-off-by: Dinghao Liu
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nouveau_debugfs.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_debugfs.c
b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
index 9635704a1d864..4561a786fab07 100644
--- a/drivers/gpu/drm/nouveau/nouveau_debugfs.c
+++ b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
@@ -161,8 +161,11 @@ nouveau_debugfs_pstate_set(struct file *file, const char
__user *ubuf,
}
ret = pm_runtime_get_sync(drm->dev);
- if (ret < 0 && ret != -EACCES)
+ if (ret < 0 && ret != -EACCES) {
+ pm_runtime_put_autosuspend(drm->dev);
return ret;
+ }
+
ret = nvif_mthd(ctrl, NVIF_CONTROL_PSTATE_USER, &args, sizeof(args));
pm_runtime_put_autosuspend(drm->dev);
if (ret < 0)
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 173/206] drm/nouveau/dispnv50: fix runtime pm imbalance on error
From: Dinghao Liu
[ Upstream commit dc455f4c888365595c0a13da445e092422d55b8d ]
pm_runtime_get_sync() increments the runtime PM usage counter even
the call returns an error code. Thus a pairing decrement is needed
on the error handling path to keep the counter balanced.
Signed-off-by: Dinghao Liu
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index e06ea8c8184cb..1bb0a9f6fa730 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -909,8 +909,10 @@ nv50_mstc_detect(struct drm_connector *connector, bool
force)
return connector_status_disconnected;
ret = pm_runtime_get_sync(connector->dev->dev);
- if (ret < 0 && ret != -EACCES)
+ if (ret < 0 && ret != -EACCES) {
+ pm_runtime_put_autosuspend(connector->dev->dev);
return connector_status_disconnected;
+ }
conn_status = drm_dp_mst_detect_port(connector, mstc->port->mgr,
mstc->port);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 132/206] PCI: Use ioremap(), not phys_to_virt() for platform ROM
From: Mikel Rychliski
[ Upstream commit 72e0ef0e5f067fd991f702f0b2635d911d0cf208 ]
On some EFI systems, the video BIOS is provided by the EFI firmware. The
boot stub code stores the physical address of the ROM image in pdev->rom.
Currently we attempt to access this pointer using phys_to_virt(), which
doesn't work with CONFIG_HIGHMEM.
On these systems, attempting to load the radeon module on a x86_32 kernel
can result in the following:
BUG: unable to handle page fault for address: 3e8ed03c
#PF: supervisor read access in kernel mode
#PF: error_code(0x) - not-present page
*pde =
Oops: [#1] PREEMPT SMP
CPU: 0 PID: 317 Comm: systemd-udevd Not tainted 5.6.0-rc3-next-20200228 #2
Hardware name: Apple Computer, Inc. MacPro1,1/Mac-F4208DC8, BIOS
MP11.88Z.005C.B08.0707021221 07/02/07
EIP: radeon_get_bios+0x5ed/0xe50 [radeon]
Code: 00 00 84 c0 0f 85 12 fd ff ff c7 87 64 01 00 00 00 00 00 00 8b 47 08 8b
55 b0 e8 1e 83 e1 d6 85 c0 74 1a 8b 55 c0 85 d2 74 13 <80> 38 55 75 0e 80 78 01
aa 0f 84 a4 03 00 00 8d 74 26 00 68 dc 06
EAX: 3e8ed03c EBX: ECX: 3e8ed03c EDX: 0001
ESI: 0004 EDI: eec04000 EBP: eef3fc60 ESP: eef3fbe0
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00010206
CR0: 80050033 CR2: 3e8ed03c CR3: 2ec77000 CR4: 06d0
Call Trace:
r520_init+0x26/0x240 [radeon]
radeon_device_init+0x533/0xa50 [radeon]
radeon_driver_load_kms+0x80/0x220 [radeon]
drm_dev_register+0xa7/0x180 [drm]
radeon_pci_probe+0x10f/0x1a0 [radeon]
pci_device_probe+0xd4/0x140
Fix the issue by updating all drivers which can access a platform provided
ROM. Instead of calling the helper function pci_platform_rom() which uses
phys_to_virt(), call ioremap() directly on the pdev->rom.
radeon_read_platform_bios() previously directly accessed an __iomem
pointer. Avoid this by calling memcpy_fromio() instead of kmemdup().
pci_platform_rom() now has no remaining callers, so remove it.
Link: https://lore.kernel.org/r/20200319021623.5426-1-mi...@mikelr.com
Signed-off-by: Mikel Rychliski
Signed-off-by: Bjorn Helgaas
Acked-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c | 31 +++
.../drm/nouveau/nvkm/subdev/bios/shadowpci.c | 17 --
drivers/gpu/drm/radeon/radeon_bios.c | 30 +++---
drivers/pci/rom.c | 17 --
include/linux/pci.h | 1 -
5 files changed, 52 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
index a5df80d50d447..6cf3dd5edffda 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
@@ -191,30 +191,35 @@ static bool amdgpu_read_bios_from_rom(struct
amdgpu_device *adev)
static bool amdgpu_read_platform_bios(struct amdgpu_device *adev)
{
- uint8_t __iomem *bios;
- size_t size;
+ phys_addr_t rom = adev->pdev->rom;
+ size_t romlen = adev->pdev->romlen;
+ void __iomem *bios;
adev->bios = NULL;
- bios = pci_platform_rom(adev->pdev, &size);
- if (!bios) {
+ if (!rom || romlen == 0)
return false;
- }
- adev->bios = kzalloc(size, GFP_KERNEL);
- if (adev->bios == NULL)
+ adev->bios = kzalloc(romlen, GFP_KERNEL);
+ if (!adev->bios)
return false;
- memcpy_fromio(adev->bios, bios, size);
+ bios = ioremap(rom, romlen);
+ if (!bios)
+ goto free_bios;
- if (!check_atom_bios(adev->bios, size)) {
- kfree(adev->bios);
- return false;
- }
+ memcpy_fromio(adev->bios, bios, romlen);
+ iounmap(bios);
- adev->bios_size = size;
+ if (!check_atom_bios(adev->bios, romlen))
+ goto free_bios;
+
+ adev->bios_size = romlen;
return true;
+free_bios:
+ kfree(adev->bios);
+ return false;
}
#ifdef CONFIG_ACPI
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c
index 9b91da09dc5f8..8d9812a51ef63 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c
@@ -101,9 +101,13 @@ platform_init(struct nvkm_bios *bios, const char *name)
else
return ERR_PTR(-ENODEV);
+ if (!pdev->rom || pdev->romlen == 0)
+ return ERR_PTR(-ENODEV);
+
if ((priv = kmalloc(sizeof(*priv), GFP_KERNEL))) {
+ priv->size = pdev->romlen;
if (ret = -ENODEV,
- (priv->rom = pci_platform_rom(pdev, &priv->size)))
+ (priv->rom = ioremap(pdev->rom, pdev->romlen)))
return priv;
kfree(priv);
}
@@ -111,11 +115,20 @@ platform_init(struct nvkm_bios *bios, const char *name)
r
[PATCH AUTOSEL 4.19 116/206] drm/msm/a5xx: Always set an OPP supported hardware value
From: Jordan Crouse
[ Upstream commit 0478b4fc5f37f4d494245fe7bcce3f531cf380e9 ]
If the opp table specifies opp-supported-hw as a property but the driver
has not set a supported hardware value the OPP subsystem will reject
all the table entries.
Set a "default" value that will match the default table entries but not
conflict with any possible real bin values. Also fix a small memory leak
and free the buffer allocated by nvmem_cell_read().
Signed-off-by: Jordan Crouse
Reviewed-by: Eric Anholt
Signed-off-by: Rob Clark
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 27 ---
1 file changed, 20 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index ba6f3c14495c0..dd298abc5f393 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -1474,18 +1474,31 @@ static const struct adreno_gpu_funcs funcs = {
static void check_speed_bin(struct device *dev)
{
struct nvmem_cell *cell;
- u32 bin, val;
+ u32 val;
+
+ /*
+* If the OPP table specifies a opp-supported-hw property then we have
+* to set something with dev_pm_opp_set_supported_hw() or the table
+* doesn't get populated so pick an arbitrary value that should
+* ensure the default frequencies are selected but not conflict with any
+* actual bins
+*/
+ val = 0x80;
cell = nvmem_cell_get(dev, "speed_bin");
- /* If a nvmem cell isn't defined, nothing to do */
- if (IS_ERR(cell))
- return;
+ if (!IS_ERR(cell)) {
+ void *buf = nvmem_cell_read(cell, NULL);
+
+ if (!IS_ERR(buf)) {
+ u8 bin = *((u8 *) buf);
- bin = *((u32 *) nvmem_cell_read(cell, NULL));
- nvmem_cell_put(cell);
+ val = (1 << bin);
+ kfree(buf);
+ }
- val = (1 << bin);
+ nvmem_cell_put(cell);
+ }
dev_pm_opp_set_supported_hw(dev, &val, 1);
}
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 090/206] drm/amd/display: dal_ddc_i2c_payloads_create can fail causing panic
From: Aric Cyr
[ Upstream commit 6a6c4a4d459ecacc9013c45dcbf2bc9747fdbdbd ]
[Why]
Since the i2c payload allocation can fail need to check return codes
[How]
Clean up i2c payload allocations and check for errors
Signed-off-by: Aric Cyr
Reviewed-by: Joshua Aberback
Acked-by: Rodrigo Siqueira
Acked-by: Harry Wentland
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../gpu/drm/amd/display/dc/core/dc_link_ddc.c | 52 +--
1 file changed, 25 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c
index 46c9cb47a96e5..145af3bb2dfcb 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c
@@ -127,22 +127,16 @@ struct aux_payloads {
struct vector payloads;
};
-static struct i2c_payloads *dal_ddc_i2c_payloads_create(struct dc_context
*ctx, uint32_t count)
+static bool dal_ddc_i2c_payloads_create(
+ struct dc_context *ctx,
+ struct i2c_payloads *payloads,
+ uint32_t count)
{
- struct i2c_payloads *payloads;
-
- payloads = kzalloc(sizeof(struct i2c_payloads), GFP_KERNEL);
-
- if (!payloads)
- return NULL;
-
if (dal_vector_construct(
&payloads->payloads, ctx, count, sizeof(struct i2c_payload)))
- return payloads;
-
- kfree(payloads);
- return NULL;
+ return true;
+ return false;
}
static struct i2c_payload *dal_ddc_i2c_payloads_get(struct i2c_payloads *p)
@@ -155,14 +149,12 @@ static uint32_t dal_ddc_i2c_payloads_get_count(struct
i2c_payloads *p)
return p->payloads.count;
}
-static void dal_ddc_i2c_payloads_destroy(struct i2c_payloads **p)
+static void dal_ddc_i2c_payloads_destroy(struct i2c_payloads *p)
{
- if (!p || !*p)
+ if (!p)
return;
- dal_vector_destruct(&(*p)->payloads);
- kfree(*p);
- *p = NULL;
+ dal_vector_destruct(&p->payloads);
}
static struct aux_payloads *dal_ddc_aux_payloads_create(struct dc_context
*ctx, uint32_t count)
@@ -580,9 +572,13 @@ bool dal_ddc_service_query_ddc_data(
uint32_t payloads_num = write_payloads + read_payloads;
+
if (write_size > EDID_SEGMENT_SIZE || read_size > EDID_SEGMENT_SIZE)
return false;
+ if (!payloads_num)
+ return false;
+
/*TODO: len of payload data for i2c and aux is uint8,
* but we want to read 256 over i2c*/
if (dal_ddc_service_is_in_aux_transaction_mode(ddc)) {
@@ -613,23 +609,25 @@ bool dal_ddc_service_query_ddc_data(
dal_ddc_aux_payloads_destroy(&payloads);
} else {
- struct i2c_payloads *payloads =
- dal_ddc_i2c_payloads_create(ddc->ctx, payloads_num);
+ struct i2c_command command = {0};
+ struct i2c_payloads payloads;
- struct i2c_command command = {
- .payloads = dal_ddc_i2c_payloads_get(payloads),
- .number_of_payloads = 0,
- .engine = DDC_I2C_COMMAND_ENGINE,
- .speed = ddc->ctx->dc->caps.i2c_speed_in_khz };
+ if (!dal_ddc_i2c_payloads_create(ddc->ctx, &payloads,
payloads_num))
+ return false;
+
+ command.payloads = dal_ddc_i2c_payloads_get(&payloads);
+ command.number_of_payloads = 0;
+ command.engine = DDC_I2C_COMMAND_ENGINE;
+ command.speed = ddc->ctx->dc->caps.i2c_speed_in_khz;
dal_ddc_i2c_payloads_add(
- payloads, address, write_size, write_buf, true);
+ &payloads, address, write_size, write_buf, true);
dal_ddc_i2c_payloads_add(
- payloads, address, read_size, read_buf, false);
+ &payloads, address, read_size, read_buf, false);
command.number_of_payloads =
- dal_ddc_i2c_payloads_get_count(payloads);
+ dal_ddc_i2c_payloads_get_count(&payloads);
ret = dm_helpers_submit_i2c(
ddc->ctx,
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 101/206] drm/amd/display: Stop if retimer is not available
From: Rodrigo Siqueira [ Upstream commit a0e40018dcc3f59a10ca21d58f8ea8ceb1b035ac ] Raven provides retimer feature support that requires i2c interaction in order to make it work well, all settings required for this configuration are loaded from the Atom bios which include the i2c address. If the retimer feature is not available, we should abort the attempt to set this feature, otherwise, it makes the following line return I2C_CHANNEL_OPERATION_NO_RESPONSE: i2c_success = i2c_write(pipe_ctx, slave_address, buffer, sizeof(buffer)); ... if (!i2c_success) ASSERT(i2c_success); This ends up causing problems with hotplugging HDMI displays on Raven, and causes retimer settings to warn like so: WARNING: CPU: 1 PID: 429 at drivers/gpu/drm/amd/amdgpu/../dal/dc/core/dc_link.c:1998 write_i2c_retimer_setting+0xc2/0x3c0 [amdgpu] Modules linked in: edac_mce_amd ccp kvm irqbypass binfmt_misc crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi snd_hda_intel amdgpu(+) snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi aesni_intel snd_seq amd_iommu_v2 gpu_sched aes_x86_64 crypto_simd cryptd glue_helper snd_seq_device ttm drm_kms_helper snd_timer eeepc_wmi wmi_bmof asus_wmi sparse_keymap drm mxm_wmi snd k10temp fb_sys_fops syscopyarea sysfillrect sysimgblt soundcore joydev input_leds mac_hid sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables autofs4 igb i2c_algo_bit hid_generic usbhid i2c_piix4 dca ahci hid libahci video wmi gpio_amdpt gpio_generic CPU: 1 PID: 429 Comm: systemd-udevd Tainted: GW 5.2.0-rc1sept162019+ #1 Hardware name: System manufacturer System Product Name/ROG STRIX B450-F GAMING, BIOS 2605 08/06/2019 RIP: 0010:write_i2c_retimer_setting+0xc2/0x3c0 [amdgpu] Code: ff 0f b6 4d ce 44 0f b6 45 cf 44 0f b6 c8 45 89 cf 44 89 e2 48 c7 c6 f0 34 bc c0 bf 04 00 00 00 e8 63 b0 90 ff 45 84 ff 75 02 <0f> 0b 42 0f b6 04 73 8d 50 f6 80 fa 02 77 8c 3c 0a 0f 85 c8 00 00 RSP: 0018:a99d02726fd0 EFLAGS: 00010246 RAX: RBX: a99d02727035 RCX: 0006 RDX: RSI: 0002 RDI: 976acc857440 RBP: a99d02727018 R08: 0002 R09: 0002a600 R10: e90610193680 R11: 05e3 R12: 005d R13: 976ac4b201b8 R14: 0001 R15: FS: 7f14f99e1680() GS:976acc84() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7fdf212843b8 CR3: 000408906000 CR4: 003406e0 Call Trace: core_link_enable_stream+0x626/0x680 [amdgpu] dce110_apply_ctx_to_hw+0x414/0x4e0 [amdgpu] dc_commit_state+0x331/0x5e0 [amdgpu] ? drm_calc_timestamping_constants+0xf9/0x150 [drm] amdgpu_dm_atomic_commit_tail+0x395/0x1e00 [amdgpu] ? dm_plane_helper_prepare_fb+0x20c/0x280 [amdgpu] commit_tail+0x42/0x70 [drm_kms_helper] drm_atomic_helper_commit+0x10c/0x120 [drm_kms_helper] amdgpu_dm_atomic_commit+0x95/0xa0 [amdgpu] drm_atomic_commit+0x4a/0x50 [drm] restore_fbdev_mode_atomic+0x1c0/0x1e0 [drm_kms_helper] restore_fbdev_mode+0x4c/0x160 [drm_kms_helper] ? _cond_resched+0x19/0x40 drm_fb_helper_restore_fbdev_mode_unlocked+0x4e/0xa0 [drm_kms_helper] drm_fb_helper_set_par+0x2d/0x50 [drm_kms_helper] fbcon_init+0x471/0x630 visual_init+0xd5/0x130 do_bind_con_driver+0x20a/0x430 do_take_over_console+0x7d/0x1b0 do_fbcon_takeover+0x5c/0xb0 fbcon_event_notify+0x6cd/0x8a0 notifier_call_chain+0x4c/0x70 blocking_notifier_call_chain+0x43/0x60 fb_notifier_call_chain+0x1b/0x20 register_framebuffer+0x254/0x360 __drm_fb_helper_initial_config_and_unlock+0x2c5/0x510 [drm_kms_helper] drm_fb_helper_initial_config+0x35/0x40 [drm_kms_helper] amdgpu_fbdev_init+0xcd/0x100 [amdgpu] amdgpu_device_init+0x1156/0x1930 [amdgpu] amdgpu_driver_load_kms+0x8d/0x2e0 [amdgpu] drm_dev_register+0x12b/0x1c0 [drm] amdgpu_pci_probe+0xd3/0x160 [amdgpu] local_pci_probe+0x47/0xa0 pci_device_probe+0x142/0x1b0 really_probe+0xf5/0x3d0 driver_probe_device+0x11b/0x130 device_driver_attach+0x58/0x60 __driver_attach+0xa3/0x140 ? device_driver_attach+0x60/0x60 ? device_driver_attach+0x60/0x60 bus_for_each_dev+0x74/0xb0 ? kmem_cache_alloc_trace+0x1a3/0x1c0 driver_attach+0x1e/0x20 bus_add_driver+0x147/0x220 ? 0xc0cb9000 driver_register+0x60/0x100 ? 0xc0cb9000 __pci_register_driver+0x5a/0x60 amdgpu_init+0x74/0x83 [amdgpu] do_one_initcall+0x4a/0x1fa ? _cond_resched+0x19/0x40 ? kmem_cache_alloc_trace+0x3f/0x1c0 ? __vunmap+0x1cc/0x200 do_init_module+0x5f/0x227 load_module+0x2330/0x2b40 __do_sys_finit_module+0xfc/0x120 ? __do_sys_finit_module+0xfc/0x120 __x64_sys_finit_module+0x1a/0x20 do_syscall_64+0x5a/0x130 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f14f9500839 Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 1f
[PATCH AUTOSEL 4.19 100/206] drm/amdgpu: increase atombios cmd timeout
From: John Clements
[ Upstream commit 1b3460a8b19688ad3033b75237d40fa580a5a953 ]
mitigates race condition on BACO reset between GPU bootcode and driver reload
Reviewed-by: Hawking Zhang
Signed-off-by: John Clements
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/atom.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/atom.c
b/drivers/gpu/drm/amd/amdgpu/atom.c
index e9934de1b9cf8..0222bb7ea49b4 100644
--- a/drivers/gpu/drm/amd/amdgpu/atom.c
+++ b/drivers/gpu/drm/amd/amdgpu/atom.c
@@ -742,8 +742,8 @@ static void atom_op_jump(atom_exec_context *ctx, int *ptr,
int arg)
cjiffies = jiffies;
if (time_after(cjiffies, ctx->last_jump_jiffies)) {
cjiffies -= ctx->last_jump_jiffies;
- if ((jiffies_to_msecs(cjiffies) > 5000)) {
- DRM_ERROR("atombios stuck in loop for
more than 5secs aborting\n");
+ if ((jiffies_to_msecs(cjiffies) > 1)) {
+ DRM_ERROR("atombios stuck in loop for
more than 10secs aborting\n");
ctx->abort = true;
}
} else {
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 115/206] drm/msm: fix leaks if initialization fails
From: Pavel Machek
[ Upstream commit 66be340f827554cb1c8a1ed7dea97920b4085af2 ]
We should free resources in unlikely case of allocation failure.
Signed-off-by: Pavel Machek
Signed-off-by: Rob Clark
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/msm/msm_drv.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 7f45486b6650b..3ba3ae9749bec 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -495,8 +495,10 @@ static int msm_drm_init(struct device *dev, struct
drm_driver *drv)
if (!dev->dma_parms) {
dev->dma_parms = devm_kzalloc(dev, sizeof(*dev->dma_parms),
GFP_KERNEL);
- if (!dev->dma_parms)
- return -ENOMEM;
+ if (!dev->dma_parms) {
+ ret = -ENOMEM;
+ goto err_msm_uninit;
+ }
}
dma_set_max_seg_size(dev, DMA_BIT_MASK(32));
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 076/206] drm/omap: fix possible object reference leak
From: Wen Yang [ Upstream commit 47340e46f34a3b1d80e40b43ae3d7a8da34a3541 ] The call to of_find_matching_node returns a node pointer with refcount incremented thus it must be explicitly decremented after the last usage. Detected by coccinelle with the following warnings: drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c:212:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 209, but without a corresponding object release within this function. drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c:237:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 209, but without a corresponding object release within this function. Signed-off-by: Wen Yang Reviewed-by: Laurent Pinchart Reviewed-by: Mukesh Ojha Cc: Tomi Valkeinen Cc: David Airlie Cc: Daniel Vetter Cc: Sebastian Reichel Cc: Laurent Pinchart Cc: dri-devel@lists.freedesktop.org Cc: linux-ker...@vger.kernel.org Cc: Markus Elfring Signed-off-by: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/1554692313-28882-2-git-send-email-wen.yan...@zte.com.cn Signed-off-by: Sasha Levin --- drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c b/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c index 3bfb95d230e0e..d8fb686c1fda9 100644 --- a/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c +++ b/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c @@ -193,7 +193,7 @@ static int __init omapdss_boot_init(void) dss = of_find_matching_node(NULL, omapdss_of_match); if (dss == NULL || !of_device_is_available(dss)) - return 0; + goto put_node; omapdss_walk_device(dss, true); @@ -218,6 +218,8 @@ static int __init omapdss_boot_init(void) kfree(n); } +put_node: + of_node_put(dss); return 0; } -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 019/206] drm/amdgpu/powerplay: fix AVFS handling with custom powerplay table
From: Alex Deucher [ Upstream commit 53dbc27ad5a93932ff1892a8e4ef266827d74a0f ] When a custom powerplay table is provided, we need to update the OD VDDC flag to avoid AVFS being enabled when it shouldn't be. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=205393 Reviewed-by: Evan Quan Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c index ce459ea4ec3ad..da9e6923fa659 100644 --- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c @@ -3591,6 +3591,13 @@ static int vega10_set_power_state_tasks(struct pp_hwmgr *hwmgr, PP_ASSERT_WITH_CODE(!result, "Failed to upload PPtable!", return result); + /* +* If a custom pp table is loaded, set DPMTABLE_OD_UPDATE_VDDC flag. +* That effectively disables AVFS feature. +*/ + if(hwmgr->hardcode_pp_table != NULL) + data->need_update_dpm_table |= DPMTABLE_OD_UPDATE_VDDC; + vega10_update_avfs(hwmgr); data->need_update_dpm_table &= DPMTABLE_OD_UPDATE_VDDC; -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 022/206] drm/amdgpu/powerplay/smu7: fix AVFS handling with custom powerplay table
From: Alex Deucher [ Upstream commit 901245624c7812b6c95d67177bae850e783b5212 ] When a custom powerplay table is provided, we need to update the OD VDDC flag to avoid AVFS being enabled when it shouldn't be. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=205393 Reviewed-by: Evan Quan Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c index 219440bebd052..420f7d15511a7 100644 --- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c @@ -3969,6 +3969,13 @@ static int smu7_set_power_state_tasks(struct pp_hwmgr *hwmgr, const void *input) "Failed to populate and upload SCLK MCLK DPM levels!", result = tmp_result); + /* +* If a custom pp table is loaded, set DPMTABLE_OD_UPDATE_VDDC flag. +* That effectively disables AVFS feature. +*/ + if (hwmgr->hardcode_pp_table != NULL) + data->need_update_smu7_dpm_table |= DPMTABLE_OD_UPDATE_VDDC; + tmp_result = smu7_update_avfs(hwmgr); PP_ASSERT_WITH_CODE((0 == tmp_result), "Failed to update avfs voltages!", -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 009/206] gma/gma500: fix a memory disclosure bug due to uninitialized bytes
From: Kangjie Lu
[ Upstream commit 57a25a5f754ce27da2cfa6f413cfd366f878db76 ]
`best_clock` is an object that may be sent out. Object `clock`
contains uninitialized bytes that are copied to `best_clock`,
which leads to memory disclosure and information leak.
Signed-off-by: Kangjie Lu
Signed-off-by: Daniel Vetter
Link:
https://patchwork.freedesktop.org/patch/msgid/20191018042953.31099-1-k...@umn.edu
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/gma500/cdv_intel_display.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/gma500/cdv_intel_display.c
b/drivers/gpu/drm/gma500/cdv_intel_display.c
index 17db4b4749d5a..2e8479744ca4a 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_display.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_display.c
@@ -415,6 +415,8 @@ static bool cdv_intel_find_dp_pll(const struct gma_limit_t
*limit,
struct gma_crtc *gma_crtc = to_gma_crtc(crtc);
struct gma_clock_t clock;
+ memset(&clock, 0, sizeof(clock));
+
switch (refclk) {
case 27000:
if (target < 20) {
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 003/206] dma-fence: Serialise signal enabling (dma_fence_enable_sw_signaling)
From: Chris Wilson
[ Upstream commit 9c98f021e4e717ffd9948fa65340ea3ef12b7935 ]
Make dma_fence_enable_sw_signaling() behave like its
dma_fence_add_callback() and dma_fence_default_wait() counterparts and
perform the test to enable signaling under the fence->lock, along with
the action to do so. This ensure that should an implementation be trying
to flush the cb_list (by signaling) on retirement before freeing the
fence, it can do so in a race-free manner.
See also 0fc89b6802ba ("dma-fence: Simply wrap dma_fence_signal_locked
with dma_fence_signal").
v2: Refactor all 3 enable_signaling paths to use a common function.
v3: Don't argue, just keep the tracepoint in the existing spot.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
Link:
https://patchwork.freedesktop.org/patch/msgid/20191004101140.32713-1-ch...@chris-wilson.co.uk
Signed-off-by: Sasha Levin
---
drivers/dma-buf/dma-fence.c | 78 +
1 file changed, 35 insertions(+), 43 deletions(-)
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 1551ca7df3941..8586cc05def17 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -244,6 +244,30 @@ void dma_fence_free(struct dma_fence *fence)
}
EXPORT_SYMBOL(dma_fence_free);
+static bool __dma_fence_enable_signaling(struct dma_fence *fence)
+{
+ bool was_set;
+
+ lockdep_assert_held(fence->lock);
+
+ was_set = test_and_set_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT,
+ &fence->flags);
+
+ if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))
+ return false;
+
+ if (!was_set && fence->ops->enable_signaling) {
+ trace_dma_fence_enable_signal(fence);
+
+ if (!fence->ops->enable_signaling(fence)) {
+ dma_fence_signal_locked(fence);
+ return false;
+ }
+ }
+
+ return true;
+}
+
/**
* dma_fence_enable_sw_signaling - enable signaling on fence
* @fence: the fence to enable
@@ -256,19 +280,12 @@ void dma_fence_enable_sw_signaling(struct dma_fence
*fence)
{
unsigned long flags;
- if (!test_and_set_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT,
- &fence->flags) &&
- !test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags) &&
- fence->ops->enable_signaling) {
- trace_dma_fence_enable_signal(fence);
-
- spin_lock_irqsave(fence->lock, flags);
-
- if (!fence->ops->enable_signaling(fence))
- dma_fence_signal_locked(fence);
+ if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))
+ return;
- spin_unlock_irqrestore(fence->lock, flags);
- }
+ spin_lock_irqsave(fence->lock, flags);
+ __dma_fence_enable_signaling(fence);
+ spin_unlock_irqrestore(fence->lock, flags);
}
EXPORT_SYMBOL(dma_fence_enable_sw_signaling);
@@ -302,7 +319,6 @@ int dma_fence_add_callback(struct dma_fence *fence, struct
dma_fence_cb *cb,
{
unsigned long flags;
int ret = 0;
- bool was_set;
if (WARN_ON(!fence || !func))
return -EINVAL;
@@ -314,25 +330,14 @@ int dma_fence_add_callback(struct dma_fence *fence,
struct dma_fence_cb *cb,
spin_lock_irqsave(fence->lock, flags);
- was_set = test_and_set_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT,
- &fence->flags);
-
- if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))
- ret = -ENOENT;
- else if (!was_set && fence->ops->enable_signaling) {
- trace_dma_fence_enable_signal(fence);
-
- if (!fence->ops->enable_signaling(fence)) {
- dma_fence_signal_locked(fence);
- ret = -ENOENT;
- }
- }
-
- if (!ret) {
+ if (__dma_fence_enable_signaling(fence)) {
cb->func = func;
list_add_tail(&cb->node, &fence->cb_list);
- } else
+ } else {
INIT_LIST_HEAD(&cb->node);
+ ret = -ENOENT;
+ }
+
spin_unlock_irqrestore(fence->lock, flags);
return ret;
@@ -432,7 +437,6 @@ dma_fence_default_wait(struct dma_fence *fence, bool intr,
signed long timeout)
struct default_wait_cb cb;
unsigned long flags;
signed long ret = timeout ? timeout : 1;
- bool was_set;
if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))
return ret;
@@ -444,21 +448,9 @@ dma_fence_default_wait(struct dma_fence *fence, bool intr,
signed long timeout)
goto out;
}
- was_set = test_and_set_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT,
- &fence->flags);
-
- if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))
+ if (!__dma_fence_enable_signaling(fence)
[PATCH AUTOSEL 5.4 279/330] drm/amdkfd: fix restore worker race condition
From: Philip Yang [ Upstream commit f7646585a30ed8ef5ab300d4dc3b0c1d6afbe71d ] In free memory of gpu path, remove bo from validate_list to make sure restore worker don't access the BO any more, then unregister bo MMU interval notifier. Otherwise, the restore worker will crash in the middle of validating BO user pages if MMU interval notifer is gone. Signed-off-by: Philip Yang Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c index edb561baf8b90..f3fa271e3394c 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c @@ -1247,15 +1247,15 @@ int amdgpu_amdkfd_gpuvm_free_memory_of_gpu( * be freed anyway */ - /* No more MMU notifiers */ - amdgpu_mn_unregister(mem->bo); - /* Make sure restore workers don't access the BO any more */ bo_list_entry = &mem->validate_list; mutex_lock(&process_info->lock); list_del(&bo_list_entry->head); mutex_unlock(&process_info->lock); + /* No more MMU notifiers */ + amdgpu_mn_unregister(mem->bo); + ret = reserve_bo_and_cond_vms(mem, NULL, BO_VM_ALL, &ctx); if (unlikely(ret)) return ret; -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 283/330] drm/nouveau/dispnv50: fix runtime pm imbalance on error
From: Dinghao Liu
[ Upstream commit dc455f4c888365595c0a13da445e092422d55b8d ]
pm_runtime_get_sync() increments the runtime PM usage counter even
the call returns an error code. Thus a pairing decrement is needed
on the error handling path to keep the counter balanced.
Signed-off-by: Dinghao Liu
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 419a02260bfa7..ee2b1e1199e09 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -1032,8 +1032,10 @@ nv50_mstc_detect(struct drm_connector *connector, bool
force)
return connector_status_disconnected;
ret = pm_runtime_get_sync(connector->dev->dev);
- if (ret < 0 && ret != -EACCES)
+ if (ret < 0 && ret != -EACCES) {
+ pm_runtime_put_autosuspend(connector->dev->dev);
return connector_status_disconnected;
+ }
conn_status = drm_dp_mst_detect_port(connector, mstc->port->mgr,
mstc->port);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 268/330] drm/exynos: dsi: Remove bridge node reference in error handling path in probe function
From: Christophe JAILLET
[ Upstream commit 547a7348633b1f9923551f94ac3157a613d2c9f2 ]
'exynos_dsi_parse_dt()' takes a reference to 'dsi->in_bridge_node'.
This must be released in the error handling path.
In order to do that, add an error handling path and move the
'exynos_dsi_parse_dt()' call from the beginning to the end of the probe
function to ease the error handling path.
This function only sets some variables which are used only in the
'transfer' function.
The call chain is:
.transfer
--> exynos_dsi_host_transfer
--> exynos_dsi_init
--> exynos_dsi_enable_clock (use burst_clk_rate and esc_clk_rate)
--> exynos_dsi_set_pll (use pll_clk_rate)
While at it, also handle cases where 'component_add()' fails.
This patch is similar to commit 70505c2ef94b ("drm/exynos: dsi: Remove bridge
node reference in removal")
which fixed the issue in the remove function.
Signed-off-by: Christophe JAILLET
Signed-off-by: Inki Dae
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 8ed94c9948008..b83acd696774b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1741,10 +1741,6 @@ static int exynos_dsi_probe(struct platform_device *pdev)
dsi->dev = dev;
dsi->driver_data = of_device_get_match_data(dev);
- ret = exynos_dsi_parse_dt(dsi);
- if (ret)
- return ret;
-
dsi->supplies[0].supply = "vddcore";
dsi->supplies[1].supply = "vddio";
ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(dsi->supplies),
@@ -1805,11 +1801,25 @@ static int exynos_dsi_probe(struct platform_device
*pdev)
return ret;
}
+ ret = exynos_dsi_parse_dt(dsi);
+ if (ret)
+ return ret;
+
platform_set_drvdata(pdev, &dsi->encoder);
pm_runtime_enable(dev);
- return component_add(dev, &exynos_dsi_component_ops);
+ ret = component_add(dev, &exynos_dsi_component_ops);
+ if (ret)
+ goto err_disable_runtime;
+
+ return 0;
+
+err_disable_runtime:
+ pm_runtime_disable(dev);
+ of_node_put(dsi->in_bridge_node);
+
+ return ret;
}
static int exynos_dsi_remove(struct platform_device *pdev)
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 281/330] drm/nouveau/debugfs: fix runtime pm imbalance on error
From: Dinghao Liu
[ Upstream commit 00583fbe8031f69bba8b0a9a861efb75fb7131af ]
pm_runtime_get_sync() increments the runtime PM usage counter even
the call returns an error code. Thus a pairing decrement is needed
on the error handling path to keep the counter balanced.
Signed-off-by: Dinghao Liu
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nouveau_debugfs.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_debugfs.c
b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
index 5c314f135dd10..3b13feca970f7 100644
--- a/drivers/gpu/drm/nouveau/nouveau_debugfs.c
+++ b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
@@ -183,8 +183,11 @@ nouveau_debugfs_pstate_set(struct file *file, const char
__user *ubuf,
}
ret = pm_runtime_get_sync(drm->dev);
- if (ret < 0 && ret != -EACCES)
+ if (ret < 0 && ret != -EACCES) {
+ pm_runtime_put_autosuspend(drm->dev);
return ret;
+ }
+
ret = nvif_mthd(ctrl, NVIF_CONTROL_PSTATE_USER, &args, sizeof(args));
pm_runtime_put_autosuspend(drm->dev);
if (ret < 0)
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 282/330] drm/nouveau: fix runtime pm imbalance on error
From: Dinghao Liu
[ Upstream commit d7372dfb3f7f1602b87e0663e8b8646da23ebca7 ]
pm_runtime_get_sync() increments the runtime PM usage counter even
the call returns an error code. Thus a pairing decrement is needed
on the error handling path to keep the counter balanced.
Signed-off-by: Dinghao Liu
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nouveau_gem.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index fbfe254227740..7d39d4949ee77 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -78,8 +78,10 @@ nouveau_gem_object_open(struct drm_gem_object *gem, struct
drm_file *file_priv)
return ret;
ret = pm_runtime_get_sync(dev);
- if (ret < 0 && ret != -EACCES)
+ if (ret < 0 && ret != -EACCES) {
+ pm_runtime_put_autosuspend(dev);
goto out;
+ }
ret = nouveau_vma_new(nvbo, vmm, &vma);
pm_runtime_mark_last_busy(dev);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 232/330] drm/amdgpu/sriov add amdgpu_amdkfd_pre_reset in gpu reset
From: Jack Zhang [ Upstream commit 04bef61e5da18c2b301c629a209ccdba4d4c6fbb ] kfd_pre_reset will free mem_objs allocated by kfd_gtt_sa_allocate Without this change, sriov tdr code path will never free those allocated memories and get memory leak. v2:add a bugfix for kiq ring test fail Signed-off-by: Jack Zhang Reviewed-by: Monk Liu Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c | 3 +++ drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c | 3 +++ drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 ++ 3 files changed, 8 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c index d10f483f5e273..ce30d4e8bf25f 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c @@ -644,6 +644,9 @@ static int kgd_hqd_destroy(struct kgd_dev *kgd, void *mqd, uint32_t temp; struct v10_compute_mqd *m = get_mqd(mqd); + if (amdgpu_sriov_vf(adev) && adev->in_gpu_reset) + return 0; + #if 0 unsigned long flags; int retry; diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c index e262f2ac07a35..92754cfb98086 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c @@ -540,6 +540,9 @@ int kgd_gfx_v9_hqd_destroy(struct kgd_dev *kgd, void *mqd, uint32_t temp; struct v9_mqd *m = get_mqd(mqd); + if (amdgpu_sriov_vf(adev) && adev->in_gpu_reset) + return 0; + if (adev->in_gpu_reset) return -EIO; diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c index 5e1dce4241547..4105fbf571674 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c @@ -3466,6 +3466,8 @@ static int amdgpu_device_reset_sriov(struct amdgpu_device *adev, if (r) return r; + amdgpu_amdkfd_pre_reset(adev); + /* Resume IP prior to SMC */ r = amdgpu_device_ip_reinit_early_sriov(adev); if (r) -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 265/330] drm/amd/powerplay: try to do a graceful shutdown on SW CTF
From: Evan Quan
[ Upstream commit 9495220577416632675959caf122e968469ffd16 ]
Normally this(SW CTF) should not happen. And by doing graceful
shutdown we can prevent further damage.
Signed-off-by: Evan Quan
Reviewed-by: Alex Deucher
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../gpu/drm/amd/powerplay/hwmgr/smu_helper.c | 21 +++
drivers/gpu/drm/amd/powerplay/smu_v11_0.c | 7 +++
2 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu_helper.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/smu_helper.c
index d09690fca4520..414added3d02c 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu_helper.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu_helper.c
@@ -22,6 +22,7 @@
*/
#include
+#include
#include "hwmgr.h"
#include "pp_debug.h"
@@ -593,12 +594,18 @@ int phm_irq_process(struct amdgpu_device *adev,
uint32_t src_id = entry->src_id;
if (client_id == AMDGPU_IRQ_CLIENTID_LEGACY) {
- if (src_id == VISLANDS30_IV_SRCID_CG_TSS_THERMAL_LOW_TO_HIGH)
+ if (src_id == VISLANDS30_IV_SRCID_CG_TSS_THERMAL_LOW_TO_HIGH) {
pr_warn("GPU over temperature range detected on PCIe
%d:%d.%d!\n",
PCI_BUS_NUM(adev->pdev->devfn),
PCI_SLOT(adev->pdev->devfn),
PCI_FUNC(adev->pdev->devfn));
- else if (src_id ==
VISLANDS30_IV_SRCID_CG_TSS_THERMAL_HIGH_TO_LOW)
+ /*
+* SW CTF just occurred.
+* Try to do a graceful shutdown to prevent further
damage.
+*/
+ dev_emerg(adev->dev, "System is going to shutdown due
to SW CTF!\n");
+ orderly_poweroff(true);
+ } else if (src_id ==
VISLANDS30_IV_SRCID_CG_TSS_THERMAL_HIGH_TO_LOW)
pr_warn("GPU under temperature range detected on PCIe
%d:%d.%d!\n",
PCI_BUS_NUM(adev->pdev->devfn),
PCI_SLOT(adev->pdev->devfn),
@@ -609,12 +616,18 @@ int phm_irq_process(struct amdgpu_device *adev,
PCI_SLOT(adev->pdev->devfn),
PCI_FUNC(adev->pdev->devfn));
} else if (client_id == SOC15_IH_CLIENTID_THM) {
- if (src_id == 0)
+ if (src_id == 0) {
pr_warn("GPU over temperature range detected on PCIe
%d:%d.%d!\n",
PCI_BUS_NUM(adev->pdev->devfn),
PCI_SLOT(adev->pdev->devfn),
PCI_FUNC(adev->pdev->devfn));
- else
+ /*
+* SW CTF just occurred.
+* Try to do a graceful shutdown to prevent further
damage.
+*/
+ dev_emerg(adev->dev, "System is going to shutdown due
to SW CTF!\n");
+ orderly_poweroff(true);
+ } else
pr_warn("GPU under temperature range detected on PCIe
%d:%d.%d!\n",
PCI_BUS_NUM(adev->pdev->devfn),
PCI_SLOT(adev->pdev->devfn),
diff --git a/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
b/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
index c4d8c52c6b9ca..6c4405622c9bb 100644
--- a/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
+++ b/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include "pp_debug.h"
#include "amdgpu.h"
@@ -1538,6 +1539,12 @@ static int smu_v11_0_irq_process(struct amdgpu_device
*adev,
PCI_BUS_NUM(adev->pdev->devfn),
PCI_SLOT(adev->pdev->devfn),
PCI_FUNC(adev->pdev->devfn));
+ /*
+* SW CTF just occurred.
+* Try to do a graceful shutdown to prevent further
damage.
+*/
+ dev_emerg(adev->dev, "System is going to shutdown due
to SW CTF!\n");
+ orderly_poweroff(true);
break;
case THM_11_0__SRCID__THM_DIG_THERM_H2L:
pr_warn("GPU under temperature range detected on PCIe
%d:%d.%d!\n",
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH AUTOSEL 5.4 001/330] drm/v3d: don't leak bin job if v3d_job_init fails.
On Thu, Sep 17, 2020 at 7:01 PM Sasha Levin wrote:
>
> From: Iago Toral Quiroga
>
> [ Upstream commit 0d352a3a8a1f26168d09f7073e61bb4b328e3bb9 ]
>
> If the initialization of the job fails we need to kfree() it
> before returning.
>
> Signed-off-by: Iago Toral Quiroga
> Signed-off-by: Eric Anholt
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20190916071125.5255-1-ito...@igalia.com
> Fixes: a783a09ee76d ("drm/v3d: Refactor job management.")
> Reviewed-by: Eric Anholt
> Signed-off-by: Sasha Levin
You're double freeing with this patch, the bug is already solved.
> ---
> drivers/gpu/drm/v3d/v3d_gem.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
> index 19c092d75266b..6316bf3646af5 100644
> --- a/drivers/gpu/drm/v3d/v3d_gem.c
> +++ b/drivers/gpu/drm/v3d/v3d_gem.c
> @@ -565,6 +565,7 @@ v3d_submit_cl_ioctl(struct drm_device *dev, void *data,
> ret = v3d_job_init(v3d, file_priv, &bin->base,
>v3d_job_free, args->in_sync_bcl);
> if (ret) {
> + kfree(bin);
> v3d_job_put(&render->base);
> kfree(bin);
> return ret;
> --
> 2.25.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 223/330] drm/amdgpu/vcn2.0: stall DPG when WPTR/RPTR reset
From: James Zhu [ Upstream commit ef563ff403404ef2f234abe79bdd9f04ab6481c9 ] Add vcn dpg harware synchronization to fix race condition issue between vcn driver and hardware. Signed-off-by: James Zhu Reviewed-by: Leo Liu Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c | 16 1 file changed, 16 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c b/drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c index 36ad0c0e8efbc..cd2cbe760e883 100644 --- a/drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c +++ b/drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c @@ -1026,6 +1026,10 @@ static int vcn_v2_0_start_dpg_mode(struct amdgpu_device *adev, bool indirect) tmp = REG_SET_FIELD(tmp, UVD_RBC_RB_CNTL, RB_RPTR_WR_EN, 1); WREG32_SOC15(UVD, 0, mmUVD_RBC_RB_CNTL, tmp); + /* Stall DPG before WPTR/RPTR reset */ + WREG32_P(SOC15_REG_OFFSET(UVD, 0, mmUVD_POWER_STATUS), + UVD_POWER_STATUS__STALL_DPG_POWER_UP_MASK, + ~UVD_POWER_STATUS__STALL_DPG_POWER_UP_MASK); /* set the write pointer delay */ WREG32_SOC15(UVD, 0, mmUVD_RBC_RB_WPTR_CNTL, 0); @@ -1048,6 +1052,9 @@ static int vcn_v2_0_start_dpg_mode(struct amdgpu_device *adev, bool indirect) WREG32_SOC15(UVD, 0, mmUVD_RBC_RB_WPTR, lower_32_bits(ring->wptr)); + /* Unstall DPG */ + WREG32_P(SOC15_REG_OFFSET(UVD, 0, mmUVD_POWER_STATUS), + 0, ~UVD_POWER_STATUS__STALL_DPG_POWER_UP_MASK); return 0; } @@ -1357,8 +1364,13 @@ static int vcn_v2_0_pause_dpg_mode(struct amdgpu_device *adev, UVD_DPG_PAUSE__NJ_PAUSE_DPG_ACK_MASK, UVD_DPG_PAUSE__NJ_PAUSE_DPG_ACK_MASK, ret_code); + /* Stall DPG before WPTR/RPTR reset */ + WREG32_P(SOC15_REG_OFFSET(UVD, 0, mmUVD_POWER_STATUS), + UVD_POWER_STATUS__STALL_DPG_POWER_UP_MASK, + ~UVD_POWER_STATUS__STALL_DPG_POWER_UP_MASK); /* Restore */ ring = &adev->vcn.inst->ring_enc[0]; + ring->wptr = 0; WREG32_SOC15(UVD, 0, mmUVD_RB_BASE_LO, ring->gpu_addr); WREG32_SOC15(UVD, 0, mmUVD_RB_BASE_HI, upper_32_bits(ring->gpu_addr)); WREG32_SOC15(UVD, 0, mmUVD_RB_SIZE, ring->ring_size / 4); @@ -1366,6 +1378,7 @@ static int vcn_v2_0_pause_dpg_mode(struct amdgpu_device *adev, WREG32_SOC15(UVD, 0, mmUVD_RB_WPTR, lower_32_bits(ring->wptr)); ring = &adev->vcn.inst->ring_enc[1]; + ring->wptr = 0; WREG32_SOC15(UVD, 0, mmUVD_RB_BASE_LO2, ring->gpu_addr); WREG32_SOC15(UVD, 0, mmUVD_RB_BASE_HI2, upper_32_bits(ring->gpu_addr)); WREG32_SOC15(UVD, 0, mmUVD_RB_SIZE2, ring->ring_size / 4); @@ -1374,6 +1387,9 @@ static int vcn_v2_0_pause_dpg_mode(struct amdgpu_device *adev, WREG32_SOC15(UVD, 0, mmUVD_RBC_RB_WPTR, RREG32_SOC15(UVD, 0, mmUVD_SCRATCH2) & 0x7FFF); + /* Unstall DPG */ + WREG32_P(SOC15_REG_OFFSET(UVD, 0, mmUVD_POWER_STATUS), + 0, ~UVD_POWER_STATUS__STALL_DPG_POWER_UP_MASK); SOC15_WAIT_ON_RREG(UVD, 0, mmUVD_POWER_STATUS, UVD_PGFSM_CONFIG__UVDM_UVDU_PWR_ON, -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 182/330] drm/msm/a5xx: Always set an OPP supported hardware value
From: Jordan Crouse
[ Upstream commit 0478b4fc5f37f4d494245fe7bcce3f531cf380e9 ]
If the opp table specifies opp-supported-hw as a property but the driver
has not set a supported hardware value the OPP subsystem will reject
all the table entries.
Set a "default" value that will match the default table entries but not
conflict with any possible real bin values. Also fix a small memory leak
and free the buffer allocated by nvmem_cell_read().
Signed-off-by: Jordan Crouse
Reviewed-by: Eric Anholt
Signed-off-by: Rob Clark
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 27 ---
1 file changed, 20 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index 7829247de60e0..de0ea1d09a54f 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -1407,18 +1407,31 @@ static const struct adreno_gpu_funcs funcs = {
static void check_speed_bin(struct device *dev)
{
struct nvmem_cell *cell;
- u32 bin, val;
+ u32 val;
+
+ /*
+* If the OPP table specifies a opp-supported-hw property then we have
+* to set something with dev_pm_opp_set_supported_hw() or the table
+* doesn't get populated so pick an arbitrary value that should
+* ensure the default frequencies are selected but not conflict with any
+* actual bins
+*/
+ val = 0x80;
cell = nvmem_cell_get(dev, "speed_bin");
- /* If a nvmem cell isn't defined, nothing to do */
- if (IS_ERR(cell))
- return;
+ if (!IS_ERR(cell)) {
+ void *buf = nvmem_cell_read(cell, NULL);
+
+ if (!IS_ERR(buf)) {
+ u8 bin = *((u8 *) buf);
- bin = *((u32 *) nvmem_cell_read(cell, NULL));
- nvmem_cell_put(cell);
+ val = (1 << bin);
+ kfree(buf);
+ }
- val = (1 << bin);
+ nvmem_cell_put(cell);
+ }
dev_pm_opp_set_supported_hw(dev, &val, 1);
}
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 216/330] PCI: Use ioremap(), not phys_to_virt() for platform ROM
From: Mikel Rychliski
[ Upstream commit 72e0ef0e5f067fd991f702f0b2635d911d0cf208 ]
On some EFI systems, the video BIOS is provided by the EFI firmware. The
boot stub code stores the physical address of the ROM image in pdev->rom.
Currently we attempt to access this pointer using phys_to_virt(), which
doesn't work with CONFIG_HIGHMEM.
On these systems, attempting to load the radeon module on a x86_32 kernel
can result in the following:
BUG: unable to handle page fault for address: 3e8ed03c
#PF: supervisor read access in kernel mode
#PF: error_code(0x) - not-present page
*pde =
Oops: [#1] PREEMPT SMP
CPU: 0 PID: 317 Comm: systemd-udevd Not tainted 5.6.0-rc3-next-20200228 #2
Hardware name: Apple Computer, Inc. MacPro1,1/Mac-F4208DC8, BIOS
MP11.88Z.005C.B08.0707021221 07/02/07
EIP: radeon_get_bios+0x5ed/0xe50 [radeon]
Code: 00 00 84 c0 0f 85 12 fd ff ff c7 87 64 01 00 00 00 00 00 00 8b 47 08 8b
55 b0 e8 1e 83 e1 d6 85 c0 74 1a 8b 55 c0 85 d2 74 13 <80> 38 55 75 0e 80 78 01
aa 0f 84 a4 03 00 00 8d 74 26 00 68 dc 06
EAX: 3e8ed03c EBX: ECX: 3e8ed03c EDX: 0001
ESI: 0004 EDI: eec04000 EBP: eef3fc60 ESP: eef3fbe0
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00010206
CR0: 80050033 CR2: 3e8ed03c CR3: 2ec77000 CR4: 06d0
Call Trace:
r520_init+0x26/0x240 [radeon]
radeon_device_init+0x533/0xa50 [radeon]
radeon_driver_load_kms+0x80/0x220 [radeon]
drm_dev_register+0xa7/0x180 [drm]
radeon_pci_probe+0x10f/0x1a0 [radeon]
pci_device_probe+0xd4/0x140
Fix the issue by updating all drivers which can access a platform provided
ROM. Instead of calling the helper function pci_platform_rom() which uses
phys_to_virt(), call ioremap() directly on the pdev->rom.
radeon_read_platform_bios() previously directly accessed an __iomem
pointer. Avoid this by calling memcpy_fromio() instead of kmemdup().
pci_platform_rom() now has no remaining callers, so remove it.
Link: https://lore.kernel.org/r/20200319021623.5426-1-mi...@mikelr.com
Signed-off-by: Mikel Rychliski
Signed-off-by: Bjorn Helgaas
Acked-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c | 31 +++
.../drm/nouveau/nvkm/subdev/bios/shadowpci.c | 17 --
drivers/gpu/drm/radeon/radeon_bios.c | 30 +++---
drivers/pci/rom.c | 17 --
include/linux/pci.h | 1 -
5 files changed, 52 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
index 50dff69a0f6e3..b1172d93c99c3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
@@ -192,30 +192,35 @@ static bool amdgpu_read_bios_from_rom(struct
amdgpu_device *adev)
static bool amdgpu_read_platform_bios(struct amdgpu_device *adev)
{
- uint8_t __iomem *bios;
- size_t size;
+ phys_addr_t rom = adev->pdev->rom;
+ size_t romlen = adev->pdev->romlen;
+ void __iomem *bios;
adev->bios = NULL;
- bios = pci_platform_rom(adev->pdev, &size);
- if (!bios) {
+ if (!rom || romlen == 0)
return false;
- }
- adev->bios = kzalloc(size, GFP_KERNEL);
- if (adev->bios == NULL)
+ adev->bios = kzalloc(romlen, GFP_KERNEL);
+ if (!adev->bios)
return false;
- memcpy_fromio(adev->bios, bios, size);
+ bios = ioremap(rom, romlen);
+ if (!bios)
+ goto free_bios;
- if (!check_atom_bios(adev->bios, size)) {
- kfree(adev->bios);
- return false;
- }
+ memcpy_fromio(adev->bios, bios, romlen);
+ iounmap(bios);
- adev->bios_size = size;
+ if (!check_atom_bios(adev->bios, romlen))
+ goto free_bios;
+
+ adev->bios_size = romlen;
return true;
+free_bios:
+ kfree(adev->bios);
+ return false;
}
#ifdef CONFIG_ACPI
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c
index 9b91da09dc5f8..8d9812a51ef63 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c
@@ -101,9 +101,13 @@ platform_init(struct nvkm_bios *bios, const char *name)
else
return ERR_PTR(-ENODEV);
+ if (!pdev->rom || pdev->romlen == 0)
+ return ERR_PTR(-ENODEV);
+
if ((priv = kmalloc(sizeof(*priv), GFP_KERNEL))) {
+ priv->size = pdev->romlen;
if (ret = -ENODEV,
- (priv->rom = pci_platform_rom(pdev, &priv->size)))
+ (priv->rom = ioremap(pdev->rom, pdev->romlen)))
return priv;
kfree(priv);
}
@@ -111,11 +115,20 @@ platform_init(struct nvkm_bios *bios, const char *name)
r
[PATCH AUTOSEL 5.4 181/330] drm/msm: fix leaks if initialization fails
From: Pavel Machek
[ Upstream commit 66be340f827554cb1c8a1ed7dea97920b4085af2 ]
We should free resources in unlikely case of allocation failure.
Signed-off-by: Pavel Machek
Signed-off-by: Rob Clark
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/msm/msm_drv.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 4558d66761b3c..108632a1f2438 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -444,8 +444,10 @@ static int msm_drm_init(struct device *dev, struct
drm_driver *drv)
if (!dev->dma_parms) {
dev->dma_parms = devm_kzalloc(dev, sizeof(*dev->dma_parms),
GFP_KERNEL);
- if (!dev->dma_parms)
- return -ENOMEM;
+ if (!dev->dma_parms) {
+ ret = -ENOMEM;
+ goto err_msm_uninit;
+ }
}
dma_set_max_seg_size(dev, DMA_BIT_MASK(32));
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 160/330] drm/amd/display: Stop if retimer is not available
From: Rodrigo Siqueira [ Upstream commit a0e40018dcc3f59a10ca21d58f8ea8ceb1b035ac ] Raven provides retimer feature support that requires i2c interaction in order to make it work well, all settings required for this configuration are loaded from the Atom bios which include the i2c address. If the retimer feature is not available, we should abort the attempt to set this feature, otherwise, it makes the following line return I2C_CHANNEL_OPERATION_NO_RESPONSE: i2c_success = i2c_write(pipe_ctx, slave_address, buffer, sizeof(buffer)); ... if (!i2c_success) ASSERT(i2c_success); This ends up causing problems with hotplugging HDMI displays on Raven, and causes retimer settings to warn like so: WARNING: CPU: 1 PID: 429 at drivers/gpu/drm/amd/amdgpu/../dal/dc/core/dc_link.c:1998 write_i2c_retimer_setting+0xc2/0x3c0 [amdgpu] Modules linked in: edac_mce_amd ccp kvm irqbypass binfmt_misc crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi snd_hda_intel amdgpu(+) snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi aesni_intel snd_seq amd_iommu_v2 gpu_sched aes_x86_64 crypto_simd cryptd glue_helper snd_seq_device ttm drm_kms_helper snd_timer eeepc_wmi wmi_bmof asus_wmi sparse_keymap drm mxm_wmi snd k10temp fb_sys_fops syscopyarea sysfillrect sysimgblt soundcore joydev input_leds mac_hid sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables autofs4 igb i2c_algo_bit hid_generic usbhid i2c_piix4 dca ahci hid libahci video wmi gpio_amdpt gpio_generic CPU: 1 PID: 429 Comm: systemd-udevd Tainted: GW 5.2.0-rc1sept162019+ #1 Hardware name: System manufacturer System Product Name/ROG STRIX B450-F GAMING, BIOS 2605 08/06/2019 RIP: 0010:write_i2c_retimer_setting+0xc2/0x3c0 [amdgpu] Code: ff 0f b6 4d ce 44 0f b6 45 cf 44 0f b6 c8 45 89 cf 44 89 e2 48 c7 c6 f0 34 bc c0 bf 04 00 00 00 e8 63 b0 90 ff 45 84 ff 75 02 <0f> 0b 42 0f b6 04 73 8d 50 f6 80 fa 02 77 8c 3c 0a 0f 85 c8 00 00 RSP: 0018:a99d02726fd0 EFLAGS: 00010246 RAX: RBX: a99d02727035 RCX: 0006 RDX: RSI: 0002 RDI: 976acc857440 RBP: a99d02727018 R08: 0002 R09: 0002a600 R10: e90610193680 R11: 05e3 R12: 005d R13: 976ac4b201b8 R14: 0001 R15: FS: 7f14f99e1680() GS:976acc84() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7fdf212843b8 CR3: 000408906000 CR4: 003406e0 Call Trace: core_link_enable_stream+0x626/0x680 [amdgpu] dce110_apply_ctx_to_hw+0x414/0x4e0 [amdgpu] dc_commit_state+0x331/0x5e0 [amdgpu] ? drm_calc_timestamping_constants+0xf9/0x150 [drm] amdgpu_dm_atomic_commit_tail+0x395/0x1e00 [amdgpu] ? dm_plane_helper_prepare_fb+0x20c/0x280 [amdgpu] commit_tail+0x42/0x70 [drm_kms_helper] drm_atomic_helper_commit+0x10c/0x120 [drm_kms_helper] amdgpu_dm_atomic_commit+0x95/0xa0 [amdgpu] drm_atomic_commit+0x4a/0x50 [drm] restore_fbdev_mode_atomic+0x1c0/0x1e0 [drm_kms_helper] restore_fbdev_mode+0x4c/0x160 [drm_kms_helper] ? _cond_resched+0x19/0x40 drm_fb_helper_restore_fbdev_mode_unlocked+0x4e/0xa0 [drm_kms_helper] drm_fb_helper_set_par+0x2d/0x50 [drm_kms_helper] fbcon_init+0x471/0x630 visual_init+0xd5/0x130 do_bind_con_driver+0x20a/0x430 do_take_over_console+0x7d/0x1b0 do_fbcon_takeover+0x5c/0xb0 fbcon_event_notify+0x6cd/0x8a0 notifier_call_chain+0x4c/0x70 blocking_notifier_call_chain+0x43/0x60 fb_notifier_call_chain+0x1b/0x20 register_framebuffer+0x254/0x360 __drm_fb_helper_initial_config_and_unlock+0x2c5/0x510 [drm_kms_helper] drm_fb_helper_initial_config+0x35/0x40 [drm_kms_helper] amdgpu_fbdev_init+0xcd/0x100 [amdgpu] amdgpu_device_init+0x1156/0x1930 [amdgpu] amdgpu_driver_load_kms+0x8d/0x2e0 [amdgpu] drm_dev_register+0x12b/0x1c0 [drm] amdgpu_pci_probe+0xd3/0x160 [amdgpu] local_pci_probe+0x47/0xa0 pci_device_probe+0x142/0x1b0 really_probe+0xf5/0x3d0 driver_probe_device+0x11b/0x130 device_driver_attach+0x58/0x60 __driver_attach+0xa3/0x140 ? device_driver_attach+0x60/0x60 ? device_driver_attach+0x60/0x60 bus_for_each_dev+0x74/0xb0 ? kmem_cache_alloc_trace+0x1a3/0x1c0 driver_attach+0x1e/0x20 bus_add_driver+0x147/0x220 ? 0xc0cb9000 driver_register+0x60/0x100 ? 0xc0cb9000 __pci_register_driver+0x5a/0x60 amdgpu_init+0x74/0x83 [amdgpu] do_one_initcall+0x4a/0x1fa ? _cond_resched+0x19/0x40 ? kmem_cache_alloc_trace+0x3f/0x1c0 ? __vunmap+0x1cc/0x200 do_init_module+0x5f/0x227 load_module+0x2330/0x2b40 __do_sys_finit_module+0xfc/0x120 ? __do_sys_finit_module+0xfc/0x120 __x64_sys_finit_module+0x1a/0x20 do_syscall_64+0x5a/0x130 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f14f9500839 Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 1f
[PATCH AUTOSEL 5.4 154/330] drm/amd/display: fix image corruption with ODM 2:1 DSC 2 slice
From: Wenjing Liu
[ Upstream commit df8e34ac27e8a0d8dce364628226c5619693c3fd ]
[why]
When combining two or more pipes in DSC mode, there will always be more
than 1 slice per line. In this case, as per DSC rules, the sink device
is expecting that the ICH is reset at the end of each slice line (i.e.
ICH_RESET_AT_END_OF_LINE must be configured based on the number of
slices at the output of ODM). It is recommended that software set
ICH_RESET_AT_END_OF_LINE = 0xF for each DSC in the ODM combine. However
the current code only set ICH_RESET_AT_END_OF_LINE = 0xF when number of
slice per DSC engine is greater than 1 instead of number of slice per
output after ODM combine.
[how]
Add is_odm in dsc config. Set ICH_RESET_AT_END_OF_LINE = 0xF if either
is_odm or number of slice per DSC engine is greater than 1.
Signed-off-by: Wenjing Liu
Reviewed-by: Nikola Cornij
Acked-by: Rodrigo Siqueira
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/core/dc_link_hwss.c| 2 ++
drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dsc.c | 2 +-
drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c | 1 +
drivers/gpu/drm/amd/display/dc/inc/hw/dsc.h | 1 +
4 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_hwss.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link_hwss.c
index 5d6cbaebebc03..5641a9477d291 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link_hwss.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_hwss.c
@@ -400,6 +400,7 @@ void dp_set_dsc_on_stream(struct pipe_ctx *pipe_ctx, bool
enable)
dsc_cfg.pic_height = stream->timing.v_addressable +
stream->timing.v_border_top + stream->timing.v_border_bottom;
dsc_cfg.pixel_encoding = stream->timing.pixel_encoding;
dsc_cfg.color_depth = stream->timing.display_color_depth;
+ dsc_cfg.is_odm = pipe_ctx->next_odm_pipe ? true : false;
dsc_cfg.dc_dsc_cfg = stream->timing.dsc_cfg;
ASSERT(dsc_cfg.dc_dsc_cfg.num_slices_h % opp_cnt == 0);
dsc_cfg.dc_dsc_cfg.num_slices_h /= opp_cnt;
@@ -504,6 +505,7 @@ bool dp_set_dsc_pps_sdp(struct pipe_ctx *pipe_ctx, bool
enable)
dsc_cfg.pic_height = stream->timing.v_addressable +
stream->timing.v_border_top + stream->timing.v_border_bottom;
dsc_cfg.pixel_encoding = stream->timing.pixel_encoding;
dsc_cfg.color_depth = stream->timing.display_color_depth;
+ dsc_cfg.is_odm = pipe_ctx->next_odm_pipe ? true : false;
dsc_cfg.dc_dsc_cfg = stream->timing.dsc_cfg;
DC_LOG_DSC(" ");
diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dsc.c
b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dsc.c
index 01040501d40e3..5c45c39662fbb 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dsc.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dsc.c
@@ -351,6 +351,7 @@ static bool dsc_prepare_config(const struct dsc_config
*dsc_cfg, struct dsc_reg_
dsc_reg_vals->pps.block_pred_enable =
dsc_cfg->dc_dsc_cfg.block_pred_enable;
dsc_reg_vals->pps.line_buf_depth = dsc_cfg->dc_dsc_cfg.linebuf_depth;
dsc_reg_vals->alternate_ich_encoding_en =
dsc_reg_vals->pps.dsc_version_minor == 1 ? 0 : 1;
+ dsc_reg_vals->ich_reset_at_eol = (dsc_cfg->is_odm ||
dsc_reg_vals->num_slices_h > 1) ? 0xF : 0;
// TODO: in addition to validating slice height (pic height must be
divisible by slice height),
// see what happens when the same condition doesn't apply for
slice_width/pic_width.
@@ -513,7 +514,6 @@ static void dsc_update_from_dsc_parameters(struct
dsc_reg_values *reg_vals, cons
reg_vals->pps.rc_buf_thresh[i] = reg_vals->pps.rc_buf_thresh[i]
>> 6;
reg_vals->rc_buffer_model_size = dsc_params->rc_buffer_model_size;
- reg_vals->ich_reset_at_eol = reg_vals->num_slices_h == 1 ? 0 : 0xf;
}
static void dsc_write_to_registers(struct display_stream_compressor *dsc,
const struct dsc_reg_values *reg_vals)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
index 05b98eadc2899..bfa01137f8e09 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
@@ -2275,6 +2275,7 @@ static bool dcn20_validate_dsc(struct dc *dc, struct
dc_state *new_ctx)
+ stream->timing.v_border_bottom;
dsc_cfg.pixel_encoding = stream->timing.pixel_encoding;
dsc_cfg.color_depth = stream->timing.display_color_depth;
+ dsc_cfg.is_odm = pipe_ctx->next_odm_pipe ? true : false;
dsc_cfg.dc_dsc_cfg = stream->timing.dsc_cfg;
dsc_cfg.dc_dsc_cfg.num_slices_h /= opp_cnt;
diff --git a/drivers/gpu/drm/amd/display/dc/inc/hw/dsc.h
b/drivers/gpu/drm/amd/display/dc/inc/hw/dsc.h
index 1ddb1c
[PATCH AUTOSEL 5.4 158/330] drm/amdgpu: increase atombios cmd timeout
From: John Clements
[ Upstream commit 1b3460a8b19688ad3033b75237d40fa580a5a953 ]
mitigates race condition on BACO reset between GPU bootcode and driver reload
Reviewed-by: Hawking Zhang
Signed-off-by: John Clements
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/atom.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/atom.c
b/drivers/gpu/drm/amd/amdgpu/atom.c
index dd30f4e61a8cd..cae426c7c0863 100644
--- a/drivers/gpu/drm/amd/amdgpu/atom.c
+++ b/drivers/gpu/drm/amd/amdgpu/atom.c
@@ -744,8 +744,8 @@ static void atom_op_jump(atom_exec_context *ctx, int *ptr,
int arg)
cjiffies = jiffies;
if (time_after(cjiffies, ctx->last_jump_jiffies)) {
cjiffies -= ctx->last_jump_jiffies;
- if ((jiffies_to_msecs(cjiffies) > 5000)) {
- DRM_ERROR("atombios stuck in loop for
more than 5secs aborting\n");
+ if ((jiffies_to_msecs(cjiffies) > 1)) {
+ DRM_ERROR("atombios stuck in loop for
more than 10secs aborting\n");
ctx->abort = true;
}
} else {
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 143/330] drm/amd/display: dal_ddc_i2c_payloads_create can fail causing panic
From: Aric Cyr
[ Upstream commit 6a6c4a4d459ecacc9013c45dcbf2bc9747fdbdbd ]
[Why]
Since the i2c payload allocation can fail need to check return codes
[How]
Clean up i2c payload allocations and check for errors
Signed-off-by: Aric Cyr
Reviewed-by: Joshua Aberback
Acked-by: Rodrigo Siqueira
Acked-by: Harry Wentland
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../gpu/drm/amd/display/dc/core/dc_link_ddc.c | 52 +--
1 file changed, 25 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c
index 51991bf26a93c..4c90d68db2307 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c
@@ -126,22 +126,16 @@ struct aux_payloads {
struct vector payloads;
};
-static struct i2c_payloads *dal_ddc_i2c_payloads_create(struct dc_context
*ctx, uint32_t count)
+static bool dal_ddc_i2c_payloads_create(
+ struct dc_context *ctx,
+ struct i2c_payloads *payloads,
+ uint32_t count)
{
- struct i2c_payloads *payloads;
-
- payloads = kzalloc(sizeof(struct i2c_payloads), GFP_KERNEL);
-
- if (!payloads)
- return NULL;
-
if (dal_vector_construct(
&payloads->payloads, ctx, count, sizeof(struct i2c_payload)))
- return payloads;
-
- kfree(payloads);
- return NULL;
+ return true;
+ return false;
}
static struct i2c_payload *dal_ddc_i2c_payloads_get(struct i2c_payloads *p)
@@ -154,14 +148,12 @@ static uint32_t dal_ddc_i2c_payloads_get_count(struct
i2c_payloads *p)
return p->payloads.count;
}
-static void dal_ddc_i2c_payloads_destroy(struct i2c_payloads **p)
+static void dal_ddc_i2c_payloads_destroy(struct i2c_payloads *p)
{
- if (!p || !*p)
+ if (!p)
return;
- dal_vector_destruct(&(*p)->payloads);
- kfree(*p);
- *p = NULL;
+ dal_vector_destruct(&p->payloads);
}
#define DDC_MIN(a, b) (((a) < (b)) ? (a) : (b))
@@ -521,9 +513,13 @@ bool dal_ddc_service_query_ddc_data(
uint32_t payloads_num = write_payloads + read_payloads;
+
if (write_size > EDID_SEGMENT_SIZE || read_size > EDID_SEGMENT_SIZE)
return false;
+ if (!payloads_num)
+ return false;
+
/*TODO: len of payload data for i2c and aux is uint8,
* but we want to read 256 over i2c*/
if (dal_ddc_service_is_in_aux_transaction_mode(ddc)) {
@@ -556,23 +552,25 @@ bool dal_ddc_service_query_ddc_data(
ret = dc_link_aux_transfer_with_retries(ddc, &read_payload);
} else {
- struct i2c_payloads *payloads =
- dal_ddc_i2c_payloads_create(ddc->ctx, payloads_num);
+ struct i2c_command command = {0};
+ struct i2c_payloads payloads;
+
+ if (!dal_ddc_i2c_payloads_create(ddc->ctx, &payloads,
payloads_num))
+ return false;
- struct i2c_command command = {
- .payloads = dal_ddc_i2c_payloads_get(payloads),
- .number_of_payloads = 0,
- .engine = DDC_I2C_COMMAND_ENGINE,
- .speed = ddc->ctx->dc->caps.i2c_speed_in_khz };
+ command.payloads = dal_ddc_i2c_payloads_get(&payloads);
+ command.number_of_payloads = 0;
+ command.engine = DDC_I2C_COMMAND_ENGINE;
+ command.speed = ddc->ctx->dc->caps.i2c_speed_in_khz;
dal_ddc_i2c_payloads_add(
- payloads, address, write_size, write_buf, true);
+ &payloads, address, write_size, write_buf, true);
dal_ddc_i2c_payloads_add(
- payloads, address, read_size, read_buf, false);
+ &payloads, address, read_size, read_buf, false);
command.number_of_payloads =
- dal_ddc_i2c_payloads_get_count(payloads);
+ dal_ddc_i2c_payloads_get_count(&payloads);
ret = dm_helpers_submit_i2c(
ddc->ctx,
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 144/330] drm/omap: dss: Cleanup DSS ports on initialisation failure
From: Laurent Pinchart
[ Upstream commit 2a0a3ae17d36fa86dcf7c8e8d7b7f056ebd6c064 ]
When the DSS initialises its output DPI and SDI ports, failures don't
clean up previous successfully initialised ports. This can lead to
resource leak or memory corruption. Fix it.
Reported-by: Hans Verkuil
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
Acked-by: Sam Ravnborg
Tested-by: Sebastian Reichel
Reviewed-by: Sebastian Reichel
Signed-off-by: Tomi Valkeinen
Link:
https://patchwork.freedesktop.org/patch/msgid/20200226112514.12455-22-laurent.pinch...@ideasonboard.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/omapdrm/dss/dss.c | 43 +++
1 file changed, 26 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/dss.c
b/drivers/gpu/drm/omapdrm/dss/dss.c
index 4bdd63b571002..ac93dae2a9c84 100644
--- a/drivers/gpu/drm/omapdrm/dss/dss.c
+++ b/drivers/gpu/drm/omapdrm/dss/dss.c
@@ -1151,46 +1151,38 @@ static const struct dss_features dra7xx_dss_feats = {
.has_lcd_clk_src= true,
};
-static int dss_init_ports(struct dss_device *dss)
+static void __dss_uninit_ports(struct dss_device *dss, unsigned int num_ports)
{
struct platform_device *pdev = dss->pdev;
struct device_node *parent = pdev->dev.of_node;
struct device_node *port;
unsigned int i;
- int r;
- for (i = 0; i < dss->feat->num_ports; i++) {
+ for (i = 0; i < num_ports; i++) {
port = of_graph_get_port_by_id(parent, i);
if (!port)
continue;
switch (dss->feat->ports[i]) {
case OMAP_DISPLAY_TYPE_DPI:
- r = dpi_init_port(dss, pdev, port, dss->feat->model);
- if (r)
- return r;
+ dpi_uninit_port(port);
break;
-
case OMAP_DISPLAY_TYPE_SDI:
- r = sdi_init_port(dss, pdev, port);
- if (r)
- return r;
+ sdi_uninit_port(port);
break;
-
default:
break;
}
}
-
- return 0;
}
-static void dss_uninit_ports(struct dss_device *dss)
+static int dss_init_ports(struct dss_device *dss)
{
struct platform_device *pdev = dss->pdev;
struct device_node *parent = pdev->dev.of_node;
struct device_node *port;
- int i;
+ unsigned int i;
+ int r;
for (i = 0; i < dss->feat->num_ports; i++) {
port = of_graph_get_port_by_id(parent, i);
@@ -1199,15 +1191,32 @@ static void dss_uninit_ports(struct dss_device *dss)
switch (dss->feat->ports[i]) {
case OMAP_DISPLAY_TYPE_DPI:
- dpi_uninit_port(port);
+ r = dpi_init_port(dss, pdev, port, dss->feat->model);
+ if (r)
+ goto error;
break;
+
case OMAP_DISPLAY_TYPE_SDI:
- sdi_uninit_port(port);
+ r = sdi_init_port(dss, pdev, port);
+ if (r)
+ goto error;
break;
+
default:
break;
}
}
+
+ return 0;
+
+error:
+ __dss_uninit_ports(dss, i);
+ return r;
+}
+
+static void dss_uninit_ports(struct dss_device *dss)
+{
+ __dss_uninit_ports(dss, dss->feat->num_ports);
}
static int dss_video_pll_probe(struct dss_device *dss)
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 119/330] drm/amd/display: fix workaround for incorrect double buffer register for DLG ADL and TTU
From: Tony Cheng
[ Upstream commit 85e148fb963d27152a14e6d399a47aed9bc99c15 ]
[Why]
these registers should have been double buffered. SW workaround we will have SW
program the more aggressive (lower) values
whenever we are upating this register, so we will not have underflow at expense
of less optimzal request pattern.
[How]
there is a driver bug where we don't check for 0, which is uninitialzed HW
default. since 0 is smaller than any value we need to program,
driver end up with not programming these registers
Signed-off-by: Tony Cheng
Reviewed-by: Yongqiang Sun
Acked-by: Bhawanpreet Lakha
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../gpu/drm/amd/display/dc/dcn21/dcn21_hubp.c | 35 +--
1 file changed, 25 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubp.c
b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubp.c
index a00af513aa2b0..c8f77bd0ce8a6 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubp.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubp.c
@@ -73,32 +73,47 @@ void apply_DEDCN21_142_wa_for_hostvm_deadline(
struct _vcs_dpi_display_dlg_regs_st *dlg_attr)
{
struct dcn21_hubp *hubp21 = TO_DCN21_HUBP(hubp);
- uint32_t cur_value;
+ uint32_t refcyc_per_vm_group_vblank;
+ uint32_t refcyc_per_vm_req_vblank;
+ uint32_t refcyc_per_vm_group_flip;
+ uint32_t refcyc_per_vm_req_flip;
+ const uint32_t uninitialized_hw_default = 0;
- REG_GET(VBLANK_PARAMETERS_5, REFCYC_PER_VM_GROUP_VBLANK, &cur_value);
- if (cur_value > dlg_attr->refcyc_per_vm_group_vblank)
+ REG_GET(VBLANK_PARAMETERS_5,
+ REFCYC_PER_VM_GROUP_VBLANK,
&refcyc_per_vm_group_vblank);
+
+ if (refcyc_per_vm_group_vblank == uninitialized_hw_default ||
+ refcyc_per_vm_group_vblank >
dlg_attr->refcyc_per_vm_group_vblank)
REG_SET(VBLANK_PARAMETERS_5, 0,
REFCYC_PER_VM_GROUP_VBLANK,
dlg_attr->refcyc_per_vm_group_vblank);
REG_GET(VBLANK_PARAMETERS_6,
- REFCYC_PER_VM_REQ_VBLANK,
- &cur_value);
- if (cur_value > dlg_attr->refcyc_per_vm_req_vblank)
+ REFCYC_PER_VM_REQ_VBLANK, &refcyc_per_vm_req_vblank);
+
+ if (refcyc_per_vm_req_vblank == uninitialized_hw_default ||
+ refcyc_per_vm_req_vblank >
dlg_attr->refcyc_per_vm_req_vblank)
REG_SET(VBLANK_PARAMETERS_6, 0,
REFCYC_PER_VM_REQ_VBLANK,
dlg_attr->refcyc_per_vm_req_vblank);
- REG_GET(FLIP_PARAMETERS_3, REFCYC_PER_VM_GROUP_FLIP, &cur_value);
- if (cur_value > dlg_attr->refcyc_per_vm_group_flip)
+ REG_GET(FLIP_PARAMETERS_3,
+ REFCYC_PER_VM_GROUP_FLIP, &refcyc_per_vm_group_flip);
+
+ if (refcyc_per_vm_group_flip == uninitialized_hw_default ||
+ refcyc_per_vm_group_flip >
dlg_attr->refcyc_per_vm_group_flip)
REG_SET(FLIP_PARAMETERS_3, 0,
REFCYC_PER_VM_GROUP_FLIP,
dlg_attr->refcyc_per_vm_group_flip);
- REG_GET(FLIP_PARAMETERS_4, REFCYC_PER_VM_REQ_FLIP, &cur_value);
- if (cur_value > dlg_attr->refcyc_per_vm_req_flip)
+ REG_GET(FLIP_PARAMETERS_4,
+ REFCYC_PER_VM_REQ_FLIP, &refcyc_per_vm_req_flip);
+
+ if (refcyc_per_vm_req_flip == uninitialized_hw_default ||
+ refcyc_per_vm_req_flip >
dlg_attr->refcyc_per_vm_req_flip)
REG_SET(FLIP_PARAMETERS_4, 0,
REFCYC_PER_VM_REQ_FLIP,
dlg_attr->refcyc_per_vm_req_flip);
REG_SET(FLIP_PARAMETERS_5, 0,
REFCYC_PER_PTE_GROUP_FLIP_C,
dlg_attr->refcyc_per_pte_group_flip_c);
+
REG_SET(FLIP_PARAMETERS_6, 0,
REFCYC_PER_META_CHUNK_FLIP_C,
dlg_attr->refcyc_per_meta_chunk_flip_c);
}
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 125/330] drm/omap: fix possible object reference leak
From: Wen Yang [ Upstream commit 47340e46f34a3b1d80e40b43ae3d7a8da34a3541 ] The call to of_find_matching_node returns a node pointer with refcount incremented thus it must be explicitly decremented after the last usage. Detected by coccinelle with the following warnings: drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c:212:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 209, but without a corresponding object release within this function. drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c:237:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 209, but without a corresponding object release within this function. Signed-off-by: Wen Yang Reviewed-by: Laurent Pinchart Reviewed-by: Mukesh Ojha Cc: Tomi Valkeinen Cc: David Airlie Cc: Daniel Vetter Cc: Sebastian Reichel Cc: Laurent Pinchart Cc: dri-devel@lists.freedesktop.org Cc: linux-ker...@vger.kernel.org Cc: Markus Elfring Signed-off-by: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/1554692313-28882-2-git-send-email-wen.yan...@zte.com.cn Signed-off-by: Sasha Levin --- drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c b/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c index 31502857f013d..ce67891eedd46 100644 --- a/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c +++ b/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c @@ -192,7 +192,7 @@ static int __init omapdss_boot_init(void) dss = of_find_matching_node(NULL, omapdss_of_match); if (dss == NULL || !of_device_is_available(dss)) - return 0; + goto put_node; omapdss_walk_device(dss, true); @@ -217,6 +217,8 @@ static int __init omapdss_boot_init(void) kfree(n); } +put_node: + of_node_put(dss); return 0; } -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 094/330] drm/amd/display: Initialize DSC PPS variables to 0
From: David Francis
[ Upstream commit b6adc57cff616da18ff8cff028d2ddf585c97334 ]
For DSC MST, sometimes monitors would break out
in full-screen static. The issue traced back to the
PPS generation code, where these variables were being used
uninitialized and were picking up garbage.
memset to 0 to avoid this
Reviewed-by: Nicholas Kazlauskas
Signed-off-by: David Francis
Signed-off-by: Mikita Lipski
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/core/dc_link_hwss.c | 3 +++
drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dsc.c | 3 +++
2 files changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_hwss.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link_hwss.c
index a519dbc5ecb65..5d6cbaebebc03 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link_hwss.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_hwss.c
@@ -496,6 +496,9 @@ bool dp_set_dsc_pps_sdp(struct pipe_ctx *pipe_ctx, bool
enable)
struct dsc_config dsc_cfg;
uint8_t dsc_packed_pps[128];
+ memset(&dsc_cfg, 0, sizeof(dsc_cfg));
+ memset(dsc_packed_pps, 0, 128);
+
/* Enable DSC hw block */
dsc_cfg.pic_width = stream->timing.h_addressable +
stream->timing.h_border_left + stream->timing.h_border_right;
dsc_cfg.pic_height = stream->timing.v_addressable +
stream->timing.v_border_top + stream->timing.v_border_bottom;
diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dsc.c
b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dsc.c
index 1b419407af942..01040501d40e3 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dsc.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dsc.c
@@ -207,6 +207,9 @@ static bool dsc2_get_packed_pps(struct
display_stream_compressor *dsc, const str
struct dsc_reg_values dsc_reg_vals;
struct dsc_optc_config dsc_optc_cfg;
+ memset(&dsc_reg_vals, 0, sizeof(dsc_reg_vals));
+ memset(&dsc_optc_cfg, 0, sizeof(dsc_optc_cfg));
+
DC_LOG_DSC("Getting packed DSC PPS for DSC Config:");
dsc_config_log(dsc, dsc_cfg);
DC_LOG_DSC("DSC Picture Parameter Set (PPS):");
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 085/330] drm/scheduler: Avoid accessing freed bad job.
From: Andrey Grodzovsky
[ Upstream commit 135517d3565b48f4def3b1b82008bc17eb5d1c90 ]
Problem:
Due to a race between drm_sched_cleanup_jobs in sched thread and
drm_sched_job_timedout in timeout work there is a possiblity that
bad job was already freed while still being accessed from the
timeout thread.
Fix:
Instead of just peeking at the bad job in the mirror list
remove it from the list under lock and then put it back later when
we are garanteed no race with main sched thread is possible which
is after the thread is parked.
v2: Lock around processing ring_mirror_list in drm_sched_cleanup_jobs.
v3: Rebase on top of drm-misc-next. v2 is not needed anymore as
drm_sched_get_cleanup_job already has a lock there.
v4: Fix comments to relfect latest code in drm-misc.
Signed-off-by: Andrey Grodzovsky
Reviewed-by: Christian König
Reviewed-by: Emily Deng
Tested-by: Emily Deng
Signed-off-by: Christian König
Link: https://patchwork.freedesktop.org/patch/342356
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/scheduler/sched_main.c | 27 ++
1 file changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index 30c5ddd6d081c..134e9106ebac1 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -284,10 +284,21 @@ static void drm_sched_job_timedout(struct work_struct
*work)
unsigned long flags;
sched = container_of(work, struct drm_gpu_scheduler, work_tdr.work);
+
+ /* Protects against concurrent deletion in drm_sched_get_cleanup_job */
+ spin_lock_irqsave(&sched->job_list_lock, flags);
job = list_first_entry_or_null(&sched->ring_mirror_list,
struct drm_sched_job, node);
if (job) {
+ /*
+* Remove the bad job so it cannot be freed by concurrent
+* drm_sched_cleanup_jobs. It will be reinserted back after
sched->thread
+* is parked at which point it's safe.
+*/
+ list_del_init(&job->node);
+ spin_unlock_irqrestore(&sched->job_list_lock, flags);
+
job->sched->ops->timedout_job(job);
/*
@@ -298,6 +309,8 @@ static void drm_sched_job_timedout(struct work_struct *work)
job->sched->ops->free_job(job);
sched->free_guilty = false;
}
+ } else {
+ spin_unlock_irqrestore(&sched->job_list_lock, flags);
}
spin_lock_irqsave(&sched->job_list_lock, flags);
@@ -369,6 +382,20 @@ void drm_sched_stop(struct drm_gpu_scheduler *sched,
struct drm_sched_job *bad)
kthread_park(sched->thread);
+ /*
+* Reinsert back the bad job here - now it's safe as
+* drm_sched_get_cleanup_job cannot race against us and release the
+* bad job at this point - we parked (waited for) any in progress
+* (earlier) cleanups and drm_sched_get_cleanup_job will not be called
+* now until the scheduler thread is unparked.
+*/
+ if (bad && bad->sched == sched)
+ /*
+* Add at the head of the queue to reflect it was the earliest
+* job extracted.
+*/
+ list_add(&bad->node, &sched->ring_mirror_list);
+
/*
* Iterate the job list from later to earlier one and either deactive
* their HW callbacks or remove them from mirror list if they already
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 069/330] drm/amdgpu: fix calltrace during kmd unload(v3)
From: Monk Liu
[ Upstream commit 82a829dc8c2bb03cc9b7e5beb1c5479aa3ba7831 ]
issue:
kernel would report a warning from a double unpin
during the driver unloading on the CSB bo
why:
we unpin it during hw_fini, and there will be another
unpin in sw_fini on CSB bo.
fix:
actually we don't need to pin/unpin it during
hw_init/fini since it is created with kernel pinned,
we only need to fullfill the CSB again during hw_init
to prevent CSB/VRAM lost after S3
v2:
get_csb in init_rlc so hw_init() will make CSIB content
back even after reset or s3
v3:
use bo_create_kernel instead of bo_create_reserved for CSB
otherwise the bo_free_kernel() on CSB is not aligned and
would lead to its internal reserve pending there forever
take care of gfx7/8 as well
Signed-off-by: Monk Liu
Reviewed-by: Hawking Zhang
Reviewed-by: Xiaojie Yuan
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_rlc.c | 10 +
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 58 +
drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 2 +
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 40 +
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 40 +
5 files changed, 6 insertions(+), 144 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_rlc.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_rlc.c
index c8793e6cc3c5d..6373bfb47d55d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_rlc.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_rlc.c
@@ -124,13 +124,12 @@ int amdgpu_gfx_rlc_init_sr(struct amdgpu_device *adev,
u32 dws)
*/
int amdgpu_gfx_rlc_init_csb(struct amdgpu_device *adev)
{
- volatile u32 *dst_ptr;
u32 dws;
int r;
/* allocate clear state block */
adev->gfx.rlc.clear_state_size = dws =
adev->gfx.rlc.funcs->get_csb_size(adev);
- r = amdgpu_bo_create_reserved(adev, dws * 4, PAGE_SIZE,
+ r = amdgpu_bo_create_kernel(adev, dws * 4, PAGE_SIZE,
AMDGPU_GEM_DOMAIN_VRAM,
&adev->gfx.rlc.clear_state_obj,
&adev->gfx.rlc.clear_state_gpu_addr,
@@ -141,13 +140,6 @@ int amdgpu_gfx_rlc_init_csb(struct amdgpu_device *adev)
return r;
}
- /* set up the cs buffer */
- dst_ptr = adev->gfx.rlc.cs_ptr;
- adev->gfx.rlc.funcs->get_csb_buffer(adev, dst_ptr);
- amdgpu_bo_kunmap(adev->gfx.rlc.clear_state_obj);
- amdgpu_bo_unpin(adev->gfx.rlc.clear_state_obj);
- amdgpu_bo_unreserve(adev->gfx.rlc.clear_state_obj);
-
return 0;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index 19876c90be0e1..d17edc850427a 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
@@ -993,39 +993,6 @@ static int gfx_v10_0_rlc_init(struct amdgpu_device *adev)
return 0;
}
-static int gfx_v10_0_csb_vram_pin(struct amdgpu_device *adev)
-{
- int r;
-
- r = amdgpu_bo_reserve(adev->gfx.rlc.clear_state_obj, false);
- if (unlikely(r != 0))
- return r;
-
- r = amdgpu_bo_pin(adev->gfx.rlc.clear_state_obj,
- AMDGPU_GEM_DOMAIN_VRAM);
- if (!r)
- adev->gfx.rlc.clear_state_gpu_addr =
- amdgpu_bo_gpu_offset(adev->gfx.rlc.clear_state_obj);
-
- amdgpu_bo_unreserve(adev->gfx.rlc.clear_state_obj);
-
- return r;
-}
-
-static void gfx_v10_0_csb_vram_unpin(struct amdgpu_device *adev)
-{
- int r;
-
- if (!adev->gfx.rlc.clear_state_obj)
- return;
-
- r = amdgpu_bo_reserve(adev->gfx.rlc.clear_state_obj, true);
- if (likely(r == 0)) {
- amdgpu_bo_unpin(adev->gfx.rlc.clear_state_obj);
- amdgpu_bo_unreserve(adev->gfx.rlc.clear_state_obj);
- }
-}
-
static void gfx_v10_0_mec_fini(struct amdgpu_device *adev)
{
amdgpu_bo_free_kernel(&adev->gfx.mec.hpd_eop_obj, NULL, NULL);
@@ -1787,25 +1754,7 @@ static void gfx_v10_0_enable_gui_idle_interrupt(struct
amdgpu_device *adev,
static int gfx_v10_0_init_csb(struct amdgpu_device *adev)
{
- int r;
-
- if (adev->in_gpu_reset) {
- r = amdgpu_bo_reserve(adev->gfx.rlc.clear_state_obj, false);
- if (r)
- return r;
-
- r = amdgpu_bo_kmap(adev->gfx.rlc.clear_state_obj,
- (void **)&adev->gfx.rlc.cs_ptr);
- if (!r) {
- adev->gfx.rlc.funcs->get_csb_buffer(adev,
- adev->gfx.rlc.cs_ptr);
- amdgpu_bo_kunmap(adev->gfx.rlc.clear_state_obj);
- }
-
- amdgpu_bo_unreserve(adev->gfx.rlc.clear_state_obj);
- if (r)
- return r;
- }
+ adev->gfx.rlc.funcs->get_csb_buffer(adev, adev->gfx.rlc.cs_ptr);
/* csib */
WREG32_SO
[PATCH AUTOSEL 5.4 083/330] drm/mcde: Handle pending vblank while disabling display
From: Stephan Gerhold
[ Upstream commit 97de863673f07f424dd0666aefb4b6ecaba10171 ]
Disabling the display using MCDE currently results in a warning
together with a delay caused by some timeouts:
mcde a035.mcde: MCDE display is disabled
[ cut here ]
WARNING: CPU: 0 PID: 20 at drivers/gpu/drm/drm_atomic_helper.c:2258
drm_atomic_helper_commit_hw_done+0xe0/0xe4
Hardware name: ST-Ericsson Ux5x0 platform (Device Tree Support)
Workqueue: events drm_mode_rmfb_work_fn
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0x84/0x98)
[] (dump_stack) from [] (__warn+0xb8/0xd4)
[] (__warn) from [] (warn_slowpath_fmt+0x64/0xc4)
[] (warn_slowpath_fmt) from []
(drm_atomic_helper_commit_hw_done+0xe0/0xe4)
[] (drm_atomic_helper_commit_hw_done) from []
(drm_atomic_helper_commit_tail_rpm+0x44/0x6c)
[] (drm_atomic_helper_commit_tail_rpm) from []
(commit_tail+0x50/0x10c)
[] (commit_tail) from []
(drm_atomic_helper_commit+0xbc/0x128)
[] (drm_atomic_helper_commit) from []
(drm_framebuffer_remove+0x390/0x428)
[] (drm_framebuffer_remove) from []
(drm_mode_rmfb_work_fn+0x38/0x48)
[] (drm_mode_rmfb_work_fn) from []
(process_one_work+0x1f0/0x43c)
[] (process_one_work) from []
(worker_thread+0x254/0x55c)
[] (worker_thread) from [] (kthread+0x124/0x150)
[] (kthread) from [] (ret_from_fork+0x14/0x2c)
Exception stack(0xeb14dfb0 to 0xeb14dff8)
dfa0:
dfc0:
dfe0: 0013
---[ end trace 314909bcd4c7d50c ]---
[drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:32:crtc-0]
flip_done timed out
[drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CONNECTOR:34:DSI-1]
flip_done timed out
[drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [PLANE:31:plane-0]
flip_done timed out
The reason for this is that there is a vblank event pending, but we
never handle it after disabling the vblank interrupts.
Check if there is an vblank event pending when disabling the display,
and clear it by sending a fake vblank event in that case.
Signed-off-by: Stephan Gerhold
Tested-by: Linus Walleij
Reviewed-by: Linus Walleij
Signed-off-by: Linus Walleij
Link:
https://patchwork.freedesktop.org/patch/msgid/20191106165835.2863-8-step...@gerhold.net
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/mcde/mcde_display.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/mcde/mcde_display.c
b/drivers/gpu/drm/mcde/mcde_display.c
index 751454ae3cd10..28ed506285018 100644
--- a/drivers/gpu/drm/mcde/mcde_display.c
+++ b/drivers/gpu/drm/mcde/mcde_display.c
@@ -946,6 +946,7 @@ static void mcde_display_disable(struct
drm_simple_display_pipe *pipe)
struct drm_crtc *crtc = &pipe->crtc;
struct drm_device *drm = crtc->dev;
struct mcde *mcde = drm->dev_private;
+ struct drm_pending_vblank_event *event;
if (mcde->te_sync)
drm_crtc_vblank_off(crtc);
@@ -953,6 +954,15 @@ static void mcde_display_disable(struct
drm_simple_display_pipe *pipe)
/* Disable FIFO A flow */
mcde_disable_fifo(mcde, MCDE_FIFO_A, true);
+ event = crtc->state->event;
+ if (event) {
+ crtc->state->event = NULL;
+
+ spin_lock_irq(&crtc->dev->event_lock);
+ drm_crtc_send_vblank_event(crtc, event);
+ spin_unlock_irq(&crtc->dev->event_lock);
+ }
+
dev_info(drm->dev, "MCDE display is disabled\n");
}
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 036/330] drm/amdgpu/powerplay: fix AVFS handling with custom powerplay table
From: Alex Deucher [ Upstream commit 53dbc27ad5a93932ff1892a8e4ef266827d74a0f ] When a custom powerplay table is provided, we need to update the OD VDDC flag to avoid AVFS being enabled when it shouldn't be. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=205393 Reviewed-by: Evan Quan Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c index beacfffbdc3eb..ecbc9daea57e0 100644 --- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c @@ -3691,6 +3691,13 @@ static int vega10_set_power_state_tasks(struct pp_hwmgr *hwmgr, PP_ASSERT_WITH_CODE(!result, "Failed to upload PPtable!", return result); + /* +* If a custom pp table is loaded, set DPMTABLE_OD_UPDATE_VDDC flag. +* That effectively disables AVFS feature. +*/ + if(hwmgr->hardcode_pp_table != NULL) + data->need_update_dpm_table |= DPMTABLE_OD_UPDATE_VDDC; + vega10_update_avfs(hwmgr); /* -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 040/330] drm/amdgpu/powerplay/smu7: fix AVFS handling with custom powerplay table
From: Alex Deucher [ Upstream commit 901245624c7812b6c95d67177bae850e783b5212 ] When a custom powerplay table is provided, we need to update the OD VDDC flag to avoid AVFS being enabled when it shouldn't be. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=205393 Reviewed-by: Evan Quan Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c index e6da53e9c3f46..edd6d4912edeb 100644 --- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c @@ -3986,6 +3986,13 @@ static int smu7_set_power_state_tasks(struct pp_hwmgr *hwmgr, const void *input) "Failed to populate and upload SCLK MCLK DPM levels!", result = tmp_result); + /* +* If a custom pp table is loaded, set DPMTABLE_OD_UPDATE_VDDC flag. +* That effectively disables AVFS feature. +*/ + if (hwmgr->hardcode_pp_table != NULL) + data->need_update_smu7_dpm_table |= DPMTABLE_OD_UPDATE_VDDC; + tmp_result = smu7_update_avfs(hwmgr); PP_ASSERT_WITH_CODE((0 == tmp_result), "Failed to update avfs voltages!", -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 018/330] gma/gma500: fix a memory disclosure bug due to uninitialized bytes
From: Kangjie Lu
[ Upstream commit 57a25a5f754ce27da2cfa6f413cfd366f878db76 ]
`best_clock` is an object that may be sent out. Object `clock`
contains uninitialized bytes that are copied to `best_clock`,
which leads to memory disclosure and information leak.
Signed-off-by: Kangjie Lu
Signed-off-by: Daniel Vetter
Link:
https://patchwork.freedesktop.org/patch/msgid/20191018042953.31099-1-k...@umn.edu
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/gma500/cdv_intel_display.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/gma500/cdv_intel_display.c
b/drivers/gpu/drm/gma500/cdv_intel_display.c
index f56852a503e8d..8b784947ed3b9 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_display.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_display.c
@@ -405,6 +405,8 @@ static bool cdv_intel_find_dp_pll(const struct gma_limit_t
*limit,
struct gma_crtc *gma_crtc = to_gma_crtc(crtc);
struct gma_clock_t clock;
+ memset(&clock, 0, sizeof(clock));
+
switch (refclk) {
case 27000:
if (target < 20) {
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 022/330] drm/amd/display: Free gamma after calculating legacy transfer function
From: Nicholas Kazlauskas [ Upstream commit 0e3a7c2ec93b15f43a2653e52e9608484391aeaf ] [Why] We're leaking memory by not freeing the gamma used to calculate the transfer function for legacy gamma. [How] Release the gamma after we're done with it. Signed-off-by: Nicholas Kazlauskas Reviewed-by: Leo Li Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c index b43bb7f90e4e9..2233d293a707a 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c @@ -210,6 +210,8 @@ static int __set_legacy_tf(struct dc_transfer_func *func, res = mod_color_calculate_regamma_params(func, gamma, true, has_rom, NULL); + dc_gamma_release(&gamma); + return res ? 0 : -ENOMEM; } -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 009/330] dma-fence: Serialise signal enabling (dma_fence_enable_sw_signaling)
From: Chris Wilson
[ Upstream commit 9c98f021e4e717ffd9948fa65340ea3ef12b7935 ]
Make dma_fence_enable_sw_signaling() behave like its
dma_fence_add_callback() and dma_fence_default_wait() counterparts and
perform the test to enable signaling under the fence->lock, along with
the action to do so. This ensure that should an implementation be trying
to flush the cb_list (by signaling) on retirement before freeing the
fence, it can do so in a race-free manner.
See also 0fc89b6802ba ("dma-fence: Simply wrap dma_fence_signal_locked
with dma_fence_signal").
v2: Refactor all 3 enable_signaling paths to use a common function.
v3: Don't argue, just keep the tracepoint in the existing spot.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
Link:
https://patchwork.freedesktop.org/patch/msgid/20191004101140.32713-1-ch...@chris-wilson.co.uk
Signed-off-by: Sasha Levin
---
drivers/dma-buf/dma-fence.c | 78 +
1 file changed, 35 insertions(+), 43 deletions(-)
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 2c136aee3e794..052a41e2451c1 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -273,6 +273,30 @@ void dma_fence_free(struct dma_fence *fence)
}
EXPORT_SYMBOL(dma_fence_free);
+static bool __dma_fence_enable_signaling(struct dma_fence *fence)
+{
+ bool was_set;
+
+ lockdep_assert_held(fence->lock);
+
+ was_set = test_and_set_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT,
+ &fence->flags);
+
+ if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))
+ return false;
+
+ if (!was_set && fence->ops->enable_signaling) {
+ trace_dma_fence_enable_signal(fence);
+
+ if (!fence->ops->enable_signaling(fence)) {
+ dma_fence_signal_locked(fence);
+ return false;
+ }
+ }
+
+ return true;
+}
+
/**
* dma_fence_enable_sw_signaling - enable signaling on fence
* @fence: the fence to enable
@@ -285,19 +309,12 @@ void dma_fence_enable_sw_signaling(struct dma_fence
*fence)
{
unsigned long flags;
- if (!test_and_set_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT,
- &fence->flags) &&
- !test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags) &&
- fence->ops->enable_signaling) {
- trace_dma_fence_enable_signal(fence);
-
- spin_lock_irqsave(fence->lock, flags);
-
- if (!fence->ops->enable_signaling(fence))
- dma_fence_signal_locked(fence);
+ if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))
+ return;
- spin_unlock_irqrestore(fence->lock, flags);
- }
+ spin_lock_irqsave(fence->lock, flags);
+ __dma_fence_enable_signaling(fence);
+ spin_unlock_irqrestore(fence->lock, flags);
}
EXPORT_SYMBOL(dma_fence_enable_sw_signaling);
@@ -331,7 +348,6 @@ int dma_fence_add_callback(struct dma_fence *fence, struct
dma_fence_cb *cb,
{
unsigned long flags;
int ret = 0;
- bool was_set;
if (WARN_ON(!fence || !func))
return -EINVAL;
@@ -343,25 +359,14 @@ int dma_fence_add_callback(struct dma_fence *fence,
struct dma_fence_cb *cb,
spin_lock_irqsave(fence->lock, flags);
- was_set = test_and_set_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT,
- &fence->flags);
-
- if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))
- ret = -ENOENT;
- else if (!was_set && fence->ops->enable_signaling) {
- trace_dma_fence_enable_signal(fence);
-
- if (!fence->ops->enable_signaling(fence)) {
- dma_fence_signal_locked(fence);
- ret = -ENOENT;
- }
- }
-
- if (!ret) {
+ if (__dma_fence_enable_signaling(fence)) {
cb->func = func;
list_add_tail(&cb->node, &fence->cb_list);
- } else
+ } else {
INIT_LIST_HEAD(&cb->node);
+ ret = -ENOENT;
+ }
+
spin_unlock_irqrestore(fence->lock, flags);
return ret;
@@ -461,7 +466,6 @@ dma_fence_default_wait(struct dma_fence *fence, bool intr,
signed long timeout)
struct default_wait_cb cb;
unsigned long flags;
signed long ret = timeout ? timeout : 1;
- bool was_set;
if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))
return ret;
@@ -473,21 +477,9 @@ dma_fence_default_wait(struct dma_fence *fence, bool intr,
signed long timeout)
goto out;
}
- was_set = test_and_set_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT,
- &fence->flags);
-
- if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))
+ if (!__dma_fence_enable_signaling(fence)
[PATCH AUTOSEL 5.4 008/330] drm/amdkfd: Fix race in gfx10 context restore handler
From: Jay Cornwall
[ Upstream commit c18cc2bb9e064d3a613d8276f2cab3984926a779 ]
Missing synchronization with VGPR restore leads to intermittent
VGPR trashing in the user shader.
Signed-off-by: Jay Cornwall
Reviewed-by: Yong Zhao
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../gpu/drm/amd/amdkfd/cwsr_trap_handler.h| 139 +-
.../amd/amdkfd/cwsr_trap_handler_gfx10.asm| 1 +
2 files changed, 71 insertions(+), 69 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/cwsr_trap_handler.h
b/drivers/gpu/drm/amd/amdkfd/cwsr_trap_handler.h
index 901fe35901656..d3400da6ab643 100644
--- a/drivers/gpu/drm/amd/amdkfd/cwsr_trap_handler.h
+++ b/drivers/gpu/drm/amd/amdkfd/cwsr_trap_handler.h
@@ -905,7 +905,7 @@ static const uint32_t cwsr_trap_gfx10_hex[] = {
0x7a5d, 0x807c817c,
0x807aff7a, 0x0080,
0xbf0a717c, 0xbf85fff8,
- 0xbf820141, 0xbef4037e,
+ 0xbf820142, 0xbef4037e,
0x8775ff7f, 0x,
0x8875ff75, 0x0004,
0xbef60380, 0xbef703ff,
@@ -967,7 +967,7 @@ static const uint32_t cwsr_trap_gfx10_hex[] = {
0x725d, 0xe0304080,
0x725d0100, 0xe0304100,
0x725d0200, 0xe0304180,
- 0x725d0300, 0xbf820031,
+ 0x725d0300, 0xbf820032,
0xbef603ff, 0x0100,
0xbef20378, 0x8078ff78,
0x0400, 0xbefc0384,
@@ -992,83 +992,84 @@ static const uint32_t cwsr_trap_gfx10_hex[] = {
0x725d, 0xe0304100,
0x725d0100, 0xe0304200,
0x725d0200, 0xe0304300,
- 0x725d0300, 0xb9782a05,
- 0x80788178, 0x907c9973,
- 0x877c817c, 0xbf06817c,
- 0xbf850002, 0x8f788978,
- 0xbf820001, 0x8f788a78,
- 0xb9721e06, 0x8f728a72,
- 0x80787278, 0x8078ff78,
- 0x0200, 0x80f8ff78,
- 0x0050, 0xbef603ff,
- 0x0100, 0xbefc03ff,
- 0x006c, 0x80f89078,
- 0xf429003a, 0xf000,
- 0xbf8cc07f, 0x80fc847c,
- 0xbf80, 0xbe803100,
- 0xbe823102, 0x80f8a078,
- 0xf42d003a, 0xf000,
- 0xbf8cc07f, 0x80fc887c,
- 0xbf80, 0xbe803100,
- 0xbe823102, 0xbe843104,
- 0xbe863106, 0x80f8c078,
- 0xf431003a, 0xf000,
- 0xbf8cc07f, 0x80fc907c,
- 0xbf80, 0xbe803100,
- 0xbe823102, 0xbe843104,
- 0xbe863106, 0xbe883108,
- 0xbe8a310a, 0xbe8c310c,
- 0xbe8e310e, 0xbf06807c,
- 0xbf84fff0, 0xb9782a05,
- 0x80788178, 0x907c9973,
- 0x877c817c, 0xbf06817c,
- 0xbf850002, 0x8f788978,
- 0xbf820001, 0x8f788a78,
- 0xb9721e06, 0x8f728a72,
- 0x80787278, 0x8078ff78,
- 0x0200, 0xbef603ff,
- 0x0100, 0xf4211bfa,
+ 0x725d0300, 0xbf8c3f70,
+ 0xb9782a05, 0x80788178,
+ 0x907c9973, 0x877c817c,
+ 0xbf06817c, 0xbf850002,
+ 0x8f788978, 0xbf820001,
+ 0x8f788a78, 0xb9721e06,
+ 0x8f728a72, 0x80787278,
+ 0x8078ff78, 0x0200,
+ 0x80f8ff78, 0x0050,
+ 0xbef603ff, 0x0100,
+ 0xbefc03ff, 0x006c,
+ 0x80f89078, 0xf429003a,
+ 0xf000, 0xbf8cc07f,
+ 0x80fc847c, 0xbf80,
+ 0xbe803100, 0xbe823102,
+ 0x80f8a078, 0xf42d003a,
+ 0xf000, 0xbf8cc07f,
+ 0x80fc887c, 0xbf80,
+ 0xbe803100, 0xbe823102,
+ 0xbe843104, 0xbe863106,
+ 0x80f8c078, 0xf431003a,
+ 0xf000, 0xbf8cc07f,
+ 0x80fc907c, 0xbf80,
+ 0xbe803100, 0xbe823102,
+ 0xbe843104, 0xbe863106,
+ 0xbe883108, 0xbe8a310a,
+ 0xbe8c310c, 0xbe8e310e,
+ 0xbf06807c, 0xbf84fff0,
+ 0xb9782a05, 0x80788178,
+ 0x907c9973, 0x877c817c,
+ 0xbf06817c, 0xbf850002,
+ 0x8f788978, 0xbf820001,
+ 0x8f788a78, 0xb9721e06,
+ 0x8f728a72, 0x80787278,
+ 0x8078ff78, 0x0200,
+ 0xbef603ff, 0x0100,
+ 0xf4211bfa, 0xf000,
+ 0x80788478, 0xf4211b3a,
0xf000, 0x80788478,
- 0xf4211b3a, 0xf000,
- 0x80788478, 0xf4211b7a,
+ 0xf4211b7a, 0xf000,
+ 0x80788478, 0xf4211eba,
0xf000, 0x80788478,
- 0xf4211eba, 0xf000,
- 0x80788478, 0xf4211efa,
+ 0xf4211efa, 0xf000,
+ 0x80788478, 0xf4211c3a,
0xf000, 0x80788478,
- 0xf4211c3a, 0xf000,
- 0x80788478, 0xf4211c7a,
+ 0xf4211c7a, 0xf000,
+ 0x80788478, 0xf4211e7a,
0xf000, 0x80788478,
- 0xf4211e7a, 0xf000,
- 0x80788478, 0xf4211cfa,
+ 0xf4211cfa, 0xf000,
+ 0x80788478, 0xf4211bba,
0xf000, 0x80788478,
+ 0xbf8cc07f, 0xb9eef814,
0xf4211bba, 0xf000,
0x80788478, 0xbf8cc07f,
- 0xb9eef814, 0xf4211bba,
- 0xf000, 0x80788478,
- 0xbf8cc07f, 0xb9eef815,
- 0xbef2036d, 0x876dff72,
- 0x, 0xbefc036f,
- 0xbefe037a, 0xbeff037b,
- 0x876f71ff, 0x03ff,
- 0xb9ef4803, 0xb9f9f816,
- 0x876f71ff, 0xf800,
- 0x906f8b6f, 0xb9efa
[PATCH AUTOSEL 5.4 007/330] drm/amd/display: Do not double-buffer DTO adjustments
From: Wesley Chalmers
[ Upstream commit 6bd0a112ec129615d23aa5d8d3dd0be0243989aa ]
[WHY]
When changing DPP global ref clock, DTO adjustments must take effect
immediately, or else underflow may occur.
It appears the original decision to double-buffer DTO adjustments was made to
prevent underflows that occur when raising DPP ref clock (which is not
double-buffered), but that same decision causes similar issues when
lowering DPP global ref clock. The better solution is to order the
adjustments according to whether clocks are being raised or lowered.
Signed-off-by: Wesley Chalmers
Reviewed-by: Dmytro Laktyushkin
Acked-by: Anthony Koo
Acked-by: Leo Li
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../gpu/drm/amd/display/dc/dcn20/dcn20_dccg.c | 26 ---
1 file changed, 26 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dccg.c
b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dccg.c
index 16476ed255363..2064366322755 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dccg.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dccg.c
@@ -119,32 +119,6 @@ void dccg2_get_dccg_ref_freq(struct dccg *dccg,
void dccg2_init(struct dccg *dccg)
{
- struct dcn_dccg *dccg_dcn = TO_DCN_DCCG(dccg);
-
- // Fallthrough intentional to program all available dpp_dto's
- switch (dccg_dcn->base.ctx->dc->res_pool->pipe_count) {
- case 6:
- REG_UPDATE(DPPCLK_DTO_CTRL, DPPCLK_DTO_DB_EN[5], 1);
- /* Fall through */
- case 5:
- REG_UPDATE(DPPCLK_DTO_CTRL, DPPCLK_DTO_DB_EN[4], 1);
- /* Fall through */
- case 4:
- REG_UPDATE(DPPCLK_DTO_CTRL, DPPCLK_DTO_DB_EN[3], 1);
- /* Fall through */
- case 3:
- REG_UPDATE(DPPCLK_DTO_CTRL, DPPCLK_DTO_DB_EN[2], 1);
- /* Fall through */
- case 2:
- REG_UPDATE(DPPCLK_DTO_CTRL, DPPCLK_DTO_DB_EN[1], 1);
- /* Fall through */
- case 1:
- REG_UPDATE(DPPCLK_DTO_CTRL, DPPCLK_DTO_DB_EN[0], 1);
- break;
- default:
- ASSERT(false);
- break;
- }
}
static const struct dccg_funcs dccg2_funcs = {
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 001/330] drm/v3d: don't leak bin job if v3d_job_init fails.
From: Iago Toral Quiroga
[ Upstream commit 0d352a3a8a1f26168d09f7073e61bb4b328e3bb9 ]
If the initialization of the job fails we need to kfree() it
before returning.
Signed-off-by: Iago Toral Quiroga
Signed-off-by: Eric Anholt
Link:
https://patchwork.freedesktop.org/patch/msgid/20190916071125.5255-1-ito...@igalia.com
Fixes: a783a09ee76d ("drm/v3d: Refactor job management.")
Reviewed-by: Eric Anholt
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/v3d/v3d_gem.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
index 19c092d75266b..6316bf3646af5 100644
--- a/drivers/gpu/drm/v3d/v3d_gem.c
+++ b/drivers/gpu/drm/v3d/v3d_gem.c
@@ -565,6 +565,7 @@ v3d_submit_cl_ioctl(struct drm_device *dev, void *data,
ret = v3d_job_init(v3d, file_priv, &bin->base,
v3d_job_free, args->in_sync_bcl);
if (ret) {
+ kfree(bin);
v3d_job_put(&render->base);
kfree(bin);
return ret;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/2] dt-bindings: display: ti,am65x-dss: add missing properties to dt-schema
Hi Tomi, Thank you for the patch. On Wed, Sep 16, 2020 at 04:10:08PM +0300, Tomi Valkeinen wrote: > Add assigned-clocks, assigned-clock-parents and dma-coherent optional > properties. > > Signed-off-by: Tomi Valkeinen > Reviewed-by: Rob Herring > --- > .../devicetree/bindings/display/ti/ti,am65x-dss.yaml | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml > b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml > index 4f9185462ed3..4dc30738ee57 100644 > --- a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml > +++ b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml > @@ -55,6 +55,14 @@ properties: >- const: vp1 >- const: vp2 > > + assigned-clocks: > +minItems: 1 > +maxItems: 3 > + > + assigned-clock-parents: > +minItems: 1 > +maxItems: 3 > + Those properties can occur in any node that has clocks. Do we need to specify them explicitly in every schema ? >interrupts: > maxItems: 1 > > @@ -62,6 +70,9 @@ properties: > maxItems: 1 > description: phandle to the associated power domain > > + dma-coherent: > +type: boolean > + >ports: > type: object > description: -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm fixes for 5.9-rc6
The pull request you sent on Fri, 18 Sep 2020 09:05:58 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-09-18 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/4c0449c906fe4d9631025bc11993009071094a9a Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915/dp: Tweak initial dpcd backlight.enabled value
From: Sean Paul
In commit 79946723092b ("drm/i915: Assume 100% brightness when not in
DPCD control mode"), we fixed the brightness level when DPCD control was
not active to max brightness. This is as good as we can guess since most
backlights go on full when uncontrolled.
However in doing so we changed the semantics of the initial
'backlight.enabled' value. At least on Pixelbooks, they were relying
on the brightness level in DP_EDP_BACKLIGHT_BRIGHTNESS_MSB to be 0 on
boot such that enabled would be false. This causes the device to be
enabled when the brightness is set. Without this, brightness control
doesn't work. So by changing brightness to max, we also flipped enabled
to be true on boot.
To fix this, make enabled a function of brightness and backlight control
mechanism.
Fixes: 79946723092b ("drm/i915: Assume 100% brightness when not in DPCD control
mode")
Cc: Lyude Paul
Cc: Jani Nikula
Cc: Juha-Pekka Heikkila
Cc: "Ville Syrjälä"
Cc: Rodrigo Vivi
Cc: Kevin Chowski >
Signed-off-by: Sean Paul
---
.../drm/i915/display/intel_dp_aux_backlight.c | 31 ---
1 file changed, 20 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index acbd7eb66cbe..036f504ac7db 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -52,17 +52,11 @@ static void set_aux_backlight_enable(struct intel_dp
*intel_dp, bool enable)
}
}
-/*
- * Read the current backlight value from DPCD register(s) based
- * on if 8-bit(MSB) or 16-bit(MSB and LSB) values are supported
- */
-static u32 intel_dp_aux_get_backlight(struct intel_connector *connector)
+static bool intel_dp_aux_backlight_dpcd_mode(struct intel_connector *connector)
{
struct intel_dp *intel_dp = intel_attached_dp(connector);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
- u8 read_val[2] = { 0x0 };
u8 mode_reg;
- u16 level = 0;
if (drm_dp_dpcd_readb(&intel_dp->aux,
DP_EDP_BACKLIGHT_MODE_SET_REGISTER,
@@ -70,15 +64,29 @@ static u32 intel_dp_aux_get_backlight(struct
intel_connector *connector)
drm_dbg_kms(&i915->drm,
"Failed to read the DPCD register 0x%x\n",
DP_EDP_BACKLIGHT_MODE_SET_REGISTER);
- return 0;
+ return false;
}
+ return (mode_reg & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) ==
+ DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
+}
+
+/*
+ * Read the current backlight value from DPCD register(s) based
+ * on if 8-bit(MSB) or 16-bit(MSB and LSB) values are supported
+ */
+static u32 intel_dp_aux_get_backlight(struct intel_connector *connector)
+{
+ struct intel_dp *intel_dp = intel_attached_dp(connector);
+ struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+ u8 read_val[2] = { 0x0 };
+ u16 level = 0;
+
/*
* If we're not in DPCD control mode yet, the programmed brightness
* value is meaningless and we should assume max brightness
*/
- if ((mode_reg & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) !=
- DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD)
+ if (!intel_dp_aux_backlight_dpcd_mode(connector))
return connector->panel.backlight.max;
if (drm_dp_dpcd_read(&intel_dp->aux, DP_EDP_BACKLIGHT_BRIGHTNESS_MSB,
@@ -319,7 +327,8 @@ static int intel_dp_aux_setup_backlight(struct
intel_connector *connector,
panel->backlight.min = 0;
panel->backlight.level = intel_dp_aux_get_backlight(connector);
- panel->backlight.enabled = panel->backlight.level != 0;
+ panel->backlight.enabled = intel_dp_aux_backlight_dpcd_mode(connector)
&&
+ panel->backlight.level != 0;
return 0;
}
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm fixes for 5.9-rc6
Hi Linus, A bunch of small fixes, some of the i915 ones have been out for a while and got better commit msg explaining some better reasoning behind them. (hopefully this trend continues). Otherwise there a few AMD related ones mostly small, one radeon PLL regression fix and a bunch of small mediatek fixes. I'm going to be offline for a couple of days in a few hours time, so if anything is wrong let Daniel know as well. Dave. drm-fixes-2020-09-18: drm fixes for 5.9-rc6 amdgpu: - Sienna Cichlid fixes - Navy Flounder fixes - DC fixes amdkfd: - Fix a GPU reset crash - Fix a memory leak radeon: - Revert a PLL fix that broke other boards i915: - Avoid exposing a partially constructed context - Use RCU instead of mutex for context termination list iteration - Avoid data race reported by KCSAN - Filter wake_flags passed to default_wake_function mediatek: - Fix scrolling of panel - Remove duplicated include - Use CPU when fail to get cmdq event - Add missing put_device() call The following changes since commit 856deb866d16e29bd65952e0289066f6078af773: Linux 5.9-rc5 (2020-09-13 16:06:00 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-09-18 for you to fetch changes up to 1f08fde70075784d28d1687d0e75871e81cc1173: Merge tag 'mediatek-drm-fixes-5.9' of https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux into drm-fixes (2020-09-18 08:52:06 +1000) drm fixes for 5.9-rc6 amdgpu: - Sienna Cichlid fixes - Navy Flounder fixes - DC fixes amdkfd: - Fix a GPU reset crash - Fix a memory leak radeon: - Revert a PLL fix that broke other boards i915: - Avoid exposing a partially constructed context - Use RCU instead of mutex for context termination list iteration - Avoid data race reported by KCSAN - Filter wake_flags passed to default_wake_function mediatek: - Fix scrolling of panel - Remove duplicated include - Use CPU when fail to get cmdq event - Add missing put_device() call Andrey Grodzovsky (1): drm/amdgpu: Include sienna_cichlid in USBC PD FW support. Bhawanpreet Lakha (2): drm/amd/display: Don't use DRM_ERROR() for DTM add topology drm/amd/display: Don't log hdcp module warnings in dmesg Chris Wilson (4): drm/i915/gem: Delay tracking the GEM context until it is registered drm/i915/gem: Reduce context termination list iteration guard to RCU drm/i915: Be wary of data races when reading the active execlists drm/i915: Filter wake_flags passed to default_wake_function Christian König (1): drm/radeon: revert "Prefer lower feedback dividers" Chun-Kuang Hu (1): drm/mediatek: Use CPU when fail to get cmdq event Dave Airlie (3): Merge tag 'amd-drm-fixes-5.9-2020-09-17' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Merge tag 'drm-intel-fixes-2020-09-17' of ssh://git.freedesktop.org/git/drm/drm-intel into drm-fixes Merge tag 'mediatek-drm-fixes-5.9' of https://git.kernel.org/.../chunkuang.hu/linux into drm-fixes Dennis Li (2): drm/kfd: fix a system crash issue during GPU recovery drm/amdkfd: fix a memory leak issue Jiansong Chen (2): drm/amd/pm: support runtime pptable update for sienna_cichlid etc. drm/amdgpu: declare ta firmware for navy_flounder Jitao Shi (1): drm/mediatek: dsi: Fix scrolling of panel with small hfp or hbp Jun Lei (1): drm/amd/display: update nv1x stutter latencies Michel Dänzer (1): drm/amdgpu/dc: Require primary plane to be enabled whenever the CRTC is Wang Hai (1): drm/mediatek: Remove duplicated include Yu Kuai (4): drm/mediatek: Add missing put_device() call in mtk_ddp_comp_init() drm/mediatek: Add exception handing in mtk_drm_probe() if component init fail drm/mediatek: Add missing put_device() call in mtk_drm_kms_init() drm/mediatek: Add missing put_device() call in mtk_hdmi_dt_parse_pdata() drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c| 2 +- drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 2 +- .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 4 +- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 32 +-- .../gpu/drm/amd/display/dc/dcn20/dcn20_resource.c | 4 +- .../gpu/drm/amd/display/modules/hdcp/hdcp_log.h| 2 +- .../gpu/drm/amd/display/modules/hdcp/hdcp_psp.c| 2 +- drivers/gpu/drm/amd/powerplay/amdgpu_smu.c | 12 -- drivers/gpu/drm/i915/gem/i915_gem_context.c| 48 ++ drivers/gpu/drm/i915/gt/intel_lrc.c| 15 +-- drivers/gpu/drm/i915/i915_request.c| 25 ++- drivers/gpu/drm/i915/i915_sw_fence.c | 10 +++-- drivers/gpu/drm/mediatek/mtk_drm_crtc.c| 20 + drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c| 1 + drivers/gpu/drm/mediatek/mtk_drm_drv.c
Re: [PATCH v3 09/19] drm/virtio: implement blob resources: probe for host visible region
On Thu, Sep 17, 2020 at 2:40 AM Gerd Hoffmann wrote:
> Hi,
>
> > + if (!devm_request_mem_region(&vgdev->vdev->dev,
> > +
> vgdev->host_visible_region.addr,
> > +
> vgdev->host_visible_region.len,
> > + dev_name(&vgdev->vdev->dev)))
> {
> > + DRM_ERROR("Could not reserve host visible
> region\n");
> > + goto err_vqs;
> > + }
>
> > + if (vgdev->has_host_visible) {
> > + devm_release_mem_region(&vgdev->vdev->dev,
> > + vgdev->host_visible_region.addr,
> > + vgdev->host_visible_region.len);
> > + }
>
> Hmm. isn't it the point of the managed apis that the release happens
> automatically? I think you don't need the devm_release_mem_region
> call (it doesn't break things though).
>
Ack, good catch. Fixed.
>
> take care,
> Gerd
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 09/19] drm/virtio: implement blob resources: probe for host visible region
From: Gerd Hoffmann
The availability of the host visible region means host 3D
allocations can be directly mapped in the guest.
Signed-off-by: Gerd Hoffmann
Co-developed-by: Gurchetan Singh
Signed-off-by: Gurchetan Singh
Acked-by: Tomeu Vizoso
---
drivers/gpu/drm/virtio/virtgpu_debugfs.c | 5 +
drivers/gpu/drm/virtio/virtgpu_drv.h | 2 ++
drivers/gpu/drm/virtio/virtgpu_kms.c | 20 ++--
3 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_debugfs.c
b/drivers/gpu/drm/virtio/virtgpu_debugfs.c
index 6b9b8376613f0..a2cdd267914ac 100644
--- a/drivers/gpu/drm/virtio/virtgpu_debugfs.c
+++ b/drivers/gpu/drm/virtio/virtgpu_debugfs.c
@@ -52,6 +52,11 @@ static int virtio_gpu_features(struct seq_file *m, void
*data)
virtio_add_bool(m, "blob resources", vgdev->has_resource_blob);
virtio_add_int(m, "cap sets", vgdev->num_capsets);
virtio_add_int(m, "scanouts", vgdev->num_scanouts);
+ if (vgdev->host_visible_region.len) {
+ seq_printf(m, "%-16s : 0x%lx +0x%lx\n", "host visible region",
+ (unsigned long)vgdev->host_visible_region.addr,
+ (unsigned long)vgdev->host_visible_region.len);
+ }
return 0;
}
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index b53478a6a3c08..391637f0b362d 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -209,6 +209,8 @@ struct virtio_gpu_device {
bool has_indirect;
bool has_resource_assign_uuid;
bool has_resource_blob;
+ bool has_host_visible;
+ struct virtio_shm_region host_visible_region;
struct work_struct config_changed_work;
diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c
b/drivers/gpu/drm/virtio/virtgpu_kms.c
index 0678e56100dae..e17d3f5a0b54e 100644
--- a/drivers/gpu/drm/virtio/virtgpu_kms.c
+++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
@@ -155,11 +155,27 @@ int virtio_gpu_init(struct drm_device *dev)
if (virtio_has_feature(vgdev->vdev, VIRTIO_GPU_F_RESOURCE_BLOB)) {
vgdev->has_resource_blob = true;
}
+ if (virtio_get_shm_region(vgdev->vdev, &vgdev->host_visible_region,
+ VIRTIO_GPU_SHM_ID_HOST_VISIBLE)) {
+ if (!devm_request_mem_region(&vgdev->vdev->dev,
+vgdev->host_visible_region.addr,
+vgdev->host_visible_region.len,
+dev_name(&vgdev->vdev->dev))) {
+ DRM_ERROR("Could not reserve host visible region\n");
+ goto err_vqs;
+ }
+
+ DRM_INFO("Host memory window: 0x%lx +0x%lx\n",
+(unsigned long)vgdev->host_visible_region.addr,
+(unsigned long)vgdev->host_visible_region.len);
+ vgdev->has_host_visible = true;
+ }
- DRM_INFO("features: %cvirgl %cedid %cresource_blob\n",
+ DRM_INFO("features: %cvirgl %cedid %cresource_blob %chost_visible\n",
vgdev->has_virgl_3d? '+' : '-',
vgdev->has_edid? '+' : '-',
-vgdev->has_resource_blob ? '+' : '-');
+vgdev->has_resource_blob ? '+' : '-',
+vgdev->has_host_visible ? '+' : '-');
ret = virtio_find_vqs(vgdev->vdev, 2, vqs, callbacks, names, NULL);
if (ret) {
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] Changing vma->vm_file in dma_buf_mmap()
On Thu, Sep 17, 2020 at 04:54:44PM +0200, Christian König wrote: > Am 17.09.20 um 16:35 schrieb Jason Gunthorpe: > > On Thu, Sep 17, 2020 at 02:24:29PM +0200, Christian König wrote: > > > Am 17.09.20 um 14:18 schrieb Jason Gunthorpe: > > > > On Thu, Sep 17, 2020 at 02:03:48PM +0200, Christian König wrote: > > > > > Am 17.09.20 um 13:31 schrieb Jason Gunthorpe: > > > > > > On Thu, Sep 17, 2020 at 10:09:12AM +0200, Daniel Vetter wrote: > > > > > > > > > > > > > Yeah, but it doesn't work when forwarding from the drm chardev to > > > > > > > the > > > > > > > dma-buf on the importer side, since you'd need a ton of different > > > > > > > address spaces. And you still rely on the core code picking up > > > > > > > your > > > > > > > pgoff mangling, which feels about as risky to me as the vma file > > > > > > > pointer wrangling - if it's not consistently applied the reverse > > > > > > > map > > > > > > > is toast and unmap_mapping_range doesn't work correctly for our > > > > > > > needs. > > > > > > I would think the pgoff has to be translated at the same time the > > > > > > vm->vm_file is changed? > > > > > > > > > > > > The owner of the dma_buf should have one virtual address space and > > > > > > FD, > > > > > > all its dma bufs should be linked to it, and all pgoffs translated > > > > > > to > > > > > > that space. > > > > > Yeah, that is exactly like amdgpu is doing it. > > > > > > > > > > Going to document that somehow when I'm done with TTM cleanups. > > > > BTW, while people are looking at this, is there a way to go from a VMA > > > > to a dma_buf that owns it? > > > Only a driver specific one. > > Sounds OK > > > > > For TTM drivers vma->vm_private_data points to the buffer object. Not sure > > > about the drivers using GEM only. > > Why are drivers in control of the vma? I would think dma_buf should be > > the vma owner. IIRC module lifetime correctness essentially hings on > > the module owner of the struct file > > Because the page fault handling is completely driver specific. > > We could install some DMA-buf vmops, but that would just be another layer of > redirection. If it is already taking a page fault I'm not sure the extra function call indirection is going to be a big deal. Having a uniform VMA sounds saner than every driver custom rolling something. When I unwound a similar mess in RDMA all the custom VMA stuff in the drivers turned out to be generally buggy, at least. Is vma->vm_file->private_data universally a dma_buf pointer at least? > > So, user VA -> find_vma -> dma_buf object -> dma_buf operations on the > > memory it represents > > Ah, yes we are already doing this in amdgpu as well. But only for DMA-bufs > or more generally buffers which are mmaped by this driver instance. So there is no general dma_buf service? That is a real bummer Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] i915: Introduce quirk for shifting eDP brightness.
(resending as plain-text, my last mail was rejected by lots of
addresses for some reason)
Thanks very much for the quick reply, Lyude!
I'm happy to make the requested changes, but I wanted to clarify
before falling down the wrong hole: are you suggesting that I move the
intel_dp_aux_set_backlight/intel_dp_aux_get_backlight routines to the
drm_dp_helper.c file?
On Thu, Sep 17, 2020 at 11:13 AM Lyude Paul wrote:
>
> Just an FYI, my plan for some of this eDP backlight code is to move as much of
> it into helpers as possible since we need to implement the same interface in
> nouveau. We probably can figure out some other solution for handling this
> quirk
> if this isn't possible, but could we maybe use the panel's OUI here and add a
> quirk to drm_dp_helper.c instead?
>
> On Thu, 2020-09-17 at 11:09 -0600, Kevin Chowski wrote:
> > We have observed that Google Pixelbook's backlight hardware is
> > interpretting these backlight bits from the most-significant side of the
> > 16 bit word (if DP_EDP_PWMGEN_BIT_COUNT < 16), whereas the driver code
> > assumes the peripheral cares about the least-significant bits.
> >
> > Testing was done from within Chrome OS's build environment when the
> > patch is backported to 5.4 (the version we are newly targeting for the
> > Pixelbook); for the record:
> >$ emerge-eve-kernelnext sys-kernel/chromeos-kernel-5_4 && \
> > ./update_kernel.sh --remote=$IP
> >
> > I used `/sys/kernel/debug/dri/0/eDP-1/i915_dpcd` on my laptop to verify
> > that the registers were being set according to what the actual hardware
> > expects; I also observe that the backlight is noticeably brighter with
> > this patch.
> >
> > Signed-off-by: Kevin Chowski
> > ---
> >
> > .../drm/i915/display/intel_dp_aux_backlight.c | 34 +++
> > drivers/gpu/drm/i915/display/intel_quirks.c | 13 +++
> > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > 3 files changed, 48 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > index acbd7eb66cbe3..99c98f217356d 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > @@ -91,6 +91,23 @@ static u32 intel_dp_aux_get_backlight(struct
> > intel_connector *connector)
> > if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT)
> > level = (read_val[0] << 8 | read_val[1]);
> >
> > + if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> > + if (!drm_dp_dpcd_readb(&intel_dp->aux,
> > DP_EDP_PWMGEN_BIT_COUNT,
> > + &read_val[0])) {
> > + DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
> > + DP_EDP_PWMGEN_BIT_COUNT);
> > + return 0;
> > + }
> > + // Only bits 4:0 are used, 7:5 are reserved.
> > + read_val[0] = read_val[0] & 0x1F;
> > + if (read_val[0] > 16) {
> > + DRM_DEBUG_KMS("Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X,
> > expected at most 16\n",
> > + read_val[0]);
> > + return 0;
> > + }
> > + level >>= 16 - read_val[0];
> > + }
> > +
> > return level;
> > }
> >
> > @@ -106,6 +123,23 @@ intel_dp_aux_set_backlight(const struct
> > drm_connector_state *conn_state, u32 lev
> > struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > u8 vals[2] = { 0x0 };
> >
> > + if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> > + if (!drm_dp_dpcd_readb(&intel_dp->aux,
> > DP_EDP_PWMGEN_BIT_COUNT,
> > + &vals[0])) {
> > + DRM_DEBUG_KMS("Failed to write aux backlight level:
> > Failed to read DPCD register 0x%x\n",
> > + DP_EDP_PWMGEN_BIT_COUNT);
> > + return;
> > + }
> > + // Only bits 4:0 are used, 7:5 are reserved.
> > + vals[0] = vals[0] & 0x1F;
> > + if (vals[0] > 16) {
> > + DRM_DEBUG_KMS("Failed to write aux backlight level:
> > Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X, expected at most 16\n",
> > + vals[0]);
> > + return;
> > + }
> > + level <<= (16 - vals[0]) & 0x;
> > + }
> > +
> > vals[0] = level;
> >
> > /* Write the MSB and/or LSB */
> > diff --git a/drivers/gpu/drm/i915/display/intel_quirks.c
> > b/drivers/gpu/drm/i915/display/intel_quirks.c
> > index 46beb155d835f..63b27d49b2864 100644
> > --- a/drivers/gpu/drm/i915/display/intel_quirks.c
> > +++ b/drivers/gpu/drm/i915/display/intel_quirks.c
> > @@ -53,6 +53,16 @@ static void quirk_increase_ddi_disabled_time(struct
> > drm_i915_private *i915)
[PATCH] i915: Introduce quirk for shifting eDP brightness.
We have observed that Google Pixelbook's backlight hardware is
interpretting these backlight bits from the most-significant side of the
16 bit word (if DP_EDP_PWMGEN_BIT_COUNT < 16), whereas the driver code
assumes the peripheral cares about the least-significant bits.
Testing was done from within Chrome OS's build environment when the
patch is backported to 5.4 (the version we are newly targeting for the
Pixelbook); for the record:
$ emerge-eve-kernelnext sys-kernel/chromeos-kernel-5_4 && \
./update_kernel.sh --remote=$IP
I used `/sys/kernel/debug/dri/0/eDP-1/i915_dpcd` on my laptop to verify
that the registers were being set according to what the actual hardware
expects; I also observe that the backlight is noticeably brighter with
this patch.
Signed-off-by: Kevin Chowski
---
.../drm/i915/display/intel_dp_aux_backlight.c | 34 +++
drivers/gpu/drm/i915/display/intel_quirks.c | 13 +++
drivers/gpu/drm/i915/i915_drv.h | 1 +
3 files changed, 48 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index acbd7eb66cbe3..99c98f217356d 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -91,6 +91,23 @@ static u32 intel_dp_aux_get_backlight(struct intel_connector
*connector)
if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT)
level = (read_val[0] << 8 | read_val[1]);
+ if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
+ if (!drm_dp_dpcd_readb(&intel_dp->aux, DP_EDP_PWMGEN_BIT_COUNT,
+ &read_val[0])) {
+ DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
+ DP_EDP_PWMGEN_BIT_COUNT);
+ return 0;
+ }
+ // Only bits 4:0 are used, 7:5 are reserved.
+ read_val[0] = read_val[0] & 0x1F;
+ if (read_val[0] > 16) {
+ DRM_DEBUG_KMS("Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X,
expected at most 16\n",
+ read_val[0]);
+ return 0;
+ }
+ level >>= 16 - read_val[0];
+ }
+
return level;
}
@@ -106,6 +123,23 @@ intel_dp_aux_set_backlight(const struct
drm_connector_state *conn_state, u32 lev
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
u8 vals[2] = { 0x0 };
+ if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
+ if (!drm_dp_dpcd_readb(&intel_dp->aux, DP_EDP_PWMGEN_BIT_COUNT,
+ &vals[0])) {
+ DRM_DEBUG_KMS("Failed to write aux backlight level:
Failed to read DPCD register 0x%x\n",
+ DP_EDP_PWMGEN_BIT_COUNT);
+ return;
+ }
+ // Only bits 4:0 are used, 7:5 are reserved.
+ vals[0] = vals[0] & 0x1F;
+ if (vals[0] > 16) {
+ DRM_DEBUG_KMS("Failed to write aux backlight level:
Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X, expected at most 16\n",
+ vals[0]);
+ return;
+ }
+ level <<= (16 - vals[0]) & 0x;
+ }
+
vals[0] = level;
/* Write the MSB and/or LSB */
diff --git a/drivers/gpu/drm/i915/display/intel_quirks.c
b/drivers/gpu/drm/i915/display/intel_quirks.c
index 46beb155d835f..63b27d49b2864 100644
--- a/drivers/gpu/drm/i915/display/intel_quirks.c
+++ b/drivers/gpu/drm/i915/display/intel_quirks.c
@@ -53,6 +53,16 @@ static void quirk_increase_ddi_disabled_time(struct
drm_i915_private *i915)
drm_info(&i915->drm, "Applying Increase DDI Disabled quirk\n");
}
+/*
+ * Some eDP backlight hardware uses the most-significant bits of the brightness
+ * register, so brightness values must be shifted first.
+ */
+static void quirk_shift_edp_backlight_brightness(struct drm_i915_private *i915)
+{
+ i915->quirks |= QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS;
+ DRM_INFO("Applying shift eDP backlight brightness quirk\n");
+}
+
struct intel_quirk {
int device;
int subsystem_vendor;
@@ -156,6 +166,9 @@ static struct intel_quirk intel_quirks[] = {
/* ASRock ITX*/
{ 0x3185, 0x1849, 0x2212, quirk_increase_ddi_disabled_time },
{ 0x3184, 0x1849, 0x2212, quirk_increase_ddi_disabled_time },
+
+ /* Google Pixelbook */
+ { 0x591E, 0x8086, 0x2212, quirk_shift_edp_backlight_brightness },
};
void intel_init_quirks(struct drm_i915_private *i915)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e4f7f6518945b..cc93bede4fab8 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_dr
[PATCH] dma-fence: add get_signaled_timestamp to fence ops
Add an optional fence ops to allow drivers to be able to set the
timestamp for a fence. Some drivers have hardware capability to get
the precise timestamp of certain events based on which the fences
are triggered. This allows it to set accurate timestamp factoring
out any software and IRQ latencies. The get_signaled_timestamp ops,
if defined by the driver would be used during fence signaling to set
the timestamp, before setting the flag DMA_FENCE_FLAG_TIMESTAMP_BIT.
If the callback is not defined, ktime_get is used to set the fence
timestamp.
Signed-off-by: Veera Sundaram Sankaran
---
drivers/dma-buf/dma-fence.c | 6 +-
include/linux/dma-fence.h | 13 +
2 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 43624b4..95c6ab0 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -4,6 +4,7 @@
*
* Copyright (C) 2012 Canonical Ltd
* Copyright (C) 2012 Texas Instruments
+ * Copyright (c) 2020 The Linux Foundation. All rights reserved.
*
* Authors:
* Rob Clark
@@ -340,7 +341,10 @@ int dma_fence_signal_locked(struct dma_fence *fence)
/* Stash the cb_list before replacing it with the timestamp */
list_replace(&fence->cb_list, &cb_list);
- fence->timestamp = ktime_get();
+ if (fence->ops->get_signaled_timestamp)
+ fence->timestamp = fence->ops->get_signaled_timestamp(fence);
+ else
+ fence->timestamp = ktime_get();
set_bit(DMA_FENCE_FLAG_TIMESTAMP_BIT, &fence->flags);
trace_dma_fence_signaled(fence);
diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
index 09e23ad..ce73aba 100644
--- a/include/linux/dma-fence.h
+++ b/include/linux/dma-fence.h
@@ -4,6 +4,7 @@
*
* Copyright (C) 2012 Canonical Ltd
* Copyright (C) 2012 Texas Instruments
+ * Copyright (c) 2020 The Linux Foundation. All rights reserved.
*
* Authors:
* Rob Clark
@@ -261,6 +262,18 @@ struct dma_fence_ops {
*/
void (*timeline_value_str)(struct dma_fence *fence,
char *str, int size);
+
+ /**
+* @get_signaled_timestamp:
+*
+* Allows the driver to fill in precise timestamp for a fence.
+* This ops would be used during fence signalling to set the timestamp,
+* before setting the flag DMA_FENCE_FLAG_TIMESTAMP_BIT.
+*
+* This callback is optional. If this callback is not present,
+* ktime_get is used to fill in the timestamp.
+*/
+ ktime_t (*get_signaled_timestamp)(struct dma_fence *fence);
};
void dma_fence_init(struct dma_fence *fence, const struct dma_fence_ops *ops,
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] Changing vma->vm_file in dma_buf_mmap()
On Thu, Sep 17, 2020 at 06:06:14PM +0200, Christian König wrote: > > > If it is already taking a page fault I'm not sure the extra function > > > call indirection is going to be a big deal. Having a uniform VMA > > > sounds saner than every driver custom rolling something. > > > > > > When I unwound a similar mess in RDMA all the custom VMA stuff in the > > > drivers turned out to be generally buggy, at least. > > > > > > Is vma->vm_file->private_data universally a dma_buf pointer at least? > > Nope. I think if you want this without some large scale rewrite of a > > lot of code we'd need a vmops->get_dmabuf or similar. Not pretty, but > > would get the job done. > > Yeah, agree that sounds like the simplest approach. I don't think that will fly, it is clearly only papering over a mess inside DRM/dma buf :\ Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] i915: Introduce quirk for shifting eDP brightness.
Thanks very much for the quick reply, Lyude!
I'm happy to make the requested changes, but I wanted to clarify before
falling down the wrong hole: are you suggesting that I move
the intel_dp_aux_set_backlight/intel_dp_aux_get_backlight routines to
the drm_dp_helper.c file?
On Thu, Sep 17, 2020 at 11:13 AM Lyude Paul wrote:
> Just an FYI, my plan for some of this eDP backlight code is to move as
> much of
> it into helpers as possible since we need to implement the same interface
> in
> nouveau. We probably can figure out some other solution for handling this
> quirk
> if this isn't possible, but could we maybe use the panel's OUI here and
> add a
> quirk to drm_dp_helper.c instead?
>
> On Thu, 2020-09-17 at 11:09 -0600, Kevin Chowski wrote:
> > We have observed that Google Pixelbook's backlight hardware is
> > interpretting these backlight bits from the most-significant side of the
> > 16 bit word (if DP_EDP_PWMGEN_BIT_COUNT < 16), whereas the driver code
> > assumes the peripheral cares about the least-significant bits.
> >
> > Testing was done from within Chrome OS's build environment when the
> > patch is backported to 5.4 (the version we are newly targeting for the
> > Pixelbook); for the record:
> >$ emerge-eve-kernelnext sys-kernel/chromeos-kernel-5_4 && \
> > ./update_kernel.sh --remote=$IP
> >
> > I used `/sys/kernel/debug/dri/0/eDP-1/i915_dpcd` on my laptop to verify
> > that the registers were being set according to what the actual hardware
> > expects; I also observe that the backlight is noticeably brighter with
> > this patch.
> >
> > Signed-off-by: Kevin Chowski
> > ---
> >
> > .../drm/i915/display/intel_dp_aux_backlight.c | 34 +++
> > drivers/gpu/drm/i915/display/intel_quirks.c | 13 +++
> > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > 3 files changed, 48 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > index acbd7eb66cbe3..99c98f217356d 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > @@ -91,6 +91,23 @@ static u32 intel_dp_aux_get_backlight(struct
> > intel_connector *connector)
> > if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT)
> > level = (read_val[0] << 8 | read_val[1]);
> >
> > + if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> > + if (!drm_dp_dpcd_readb(&intel_dp->aux,
> DP_EDP_PWMGEN_BIT_COUNT,
> > + &read_val[0])) {
> > + DRM_DEBUG_KMS("Failed to read DPCD register
> 0x%x\n",
> > + DP_EDP_PWMGEN_BIT_COUNT);
> > + return 0;
> > + }
> > + // Only bits 4:0 are used, 7:5 are reserved.
> > + read_val[0] = read_val[0] & 0x1F;
> > + if (read_val[0] > 16) {
> > + DRM_DEBUG_KMS("Invalid DP_EDP_PWNGEN_BIT_COUNT
> 0x%X,
> > expected at most 16\n",
> > + read_val[0]);
> > + return 0;
> > + }
> > + level >>= 16 - read_val[0];
> > + }
> > +
> > return level;
> > }
> >
> > @@ -106,6 +123,23 @@ intel_dp_aux_set_backlight(const struct
> > drm_connector_state *conn_state, u32 lev
> > struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > u8 vals[2] = { 0x0 };
> >
> > + if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> > + if (!drm_dp_dpcd_readb(&intel_dp->aux,
> DP_EDP_PWMGEN_BIT_COUNT,
> > + &vals[0])) {
> > + DRM_DEBUG_KMS("Failed to write aux backlight level:
> > Failed to read DPCD register 0x%x\n",
> > + DP_EDP_PWMGEN_BIT_COUNT);
> > + return;
> > + }
> > + // Only bits 4:0 are used, 7:5 are reserved.
> > + vals[0] = vals[0] & 0x1F;
> > + if (vals[0] > 16) {
> > + DRM_DEBUG_KMS("Failed to write aux backlight level:
> > Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X, expected at most 16\n",
> > + vals[0]);
> > + return;
> > + }
> > + level <<= (16 - vals[0]) & 0x;
> > + }
> > +
> > vals[0] = level;
> >
> > /* Write the MSB and/or LSB */
> > diff --git a/drivers/gpu/drm/i915/display/intel_quirks.c
> > b/drivers/gpu/drm/i915/display/intel_quirks.c
> > index 46beb155d835f..63b27d49b2864 100644
> > --- a/drivers/gpu/drm/i915/display/intel_quirks.c
> > +++ b/drivers/gpu/drm/i915/display/intel_quirks.c
> > @@ -53,6 +53,16 @@ static void quirk_increase_ddi_disabled_time(struct
> > drm_i915_private *i915)
> > drm_info(&i915->drm, "Applying Increase DDI Disabled quirk\n");
> > }
> >
> >
Re: [PATCH] i915: Introduce quirk for shifting eDP brightness.
The Lyude fde7266fb2f6 change is actually based on Chromium change
(https://crrev.com/c/1650325) that fixes the brightness for Samsung
Galaxy Chromebook. So currently we have 2 examples that use LSB
interpretation and 1 that use MSB.
On Thu, Sep 17, 2020 at 10:55 AM Kevin Chowski wrote:
>
> Apologies for being too vague. To be as precise I can be, here is the
> specific code delta I tested: https://crrev.com/c/2406616 . To answer
> your other question, the code I tested against is indeed including the
> fde7266fb2f6 (despite ostensibly being called 5.4 in my commit
> message): our current top-of-tree for our 5.4 branch includes the
> intel_dp_aux_calc_max_backlight logic. Further, I'll note that change
> is exactly the change which breaks my Pixelbook model: prior to the
> change, the max_brightness was hard-coded to 0x and the math
> worked out that it didn't matter that the hardware cared about the MSB
> despite the driver code caring about the LSB.
>
> To answer Ville's question: the fde7266fb2f6 change which fixes one
> laptop (I believe Thinkpad X1 extreme Gen 2, from some bug reports I
> dug up) and breaks another (Pixelbook); so unfortunately I believe we
> need a quirk at least for some laptop. Reading through the copy of the
> datasheet I have, it wasn't clear to me which was the correct
> interpretation. I'm cc'ing puthik@, who was leaning toward the current
> kernel code (caring about LSB) being the correct interpretation. I
> believe we have other chromebooks which do rely on LSB functionality,
> so unless we can find more examples of laptops wanting MSB it
> currently looks like Pixelbook is the outlier.
>
> On Thu, Sep 17, 2020 at 11:28 AM Jani Nikula
> wrote:
> >
> > On Thu, 17 Sep 2020, Kevin Chowski wrote:
> > > We have observed that Google Pixelbook's backlight hardware is
> > > interpretting these backlight bits from the most-significant side of the
> > > 16 bit word (if DP_EDP_PWMGEN_BIT_COUNT < 16), whereas the driver code
> > > assumes the peripheral cares about the least-significant bits.
> > >
> > > Testing was done from within Chrome OS's build environment when the
> > > patch is backported to 5.4 (the version we are newly targeting for the
> > > Pixelbook); for the record:
> > >$ emerge-eve-kernelnext sys-kernel/chromeos-kernel-5_4 && \
> > > ./update_kernel.sh --remote=$IP
> > >
> > > I used `/sys/kernel/debug/dri/0/eDP-1/i915_dpcd` on my laptop to verify
> > > that the registers were being set according to what the actual hardware
> > > expects; I also observe that the backlight is noticeably brighter with
> > > this patch.
> >
> > It's unclear to me what kernel version this is against, and what you've
> > actually tested.
> >
> > Have you tried v5.7 kernel with Lyude's fde7266fb2f6 ("drm/i915: Fix eDP
> > DPCD aux max backlight calculations")?
> >
> > I just want to make sure you've tested with all the relevant fixes
> > before adding quirks.
> >
> > BR,
> > Jani.
> >
> > >
> > > Signed-off-by: Kevin Chowski
> > > ---
> > >
> > > .../drm/i915/display/intel_dp_aux_backlight.c | 34 +++
> > > drivers/gpu/drm/i915/display/intel_quirks.c | 13 +++
> > > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > > 3 files changed, 48 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > index acbd7eb66cbe3..99c98f217356d 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > @@ -91,6 +91,23 @@ static u32 intel_dp_aux_get_backlight(struct
> > > intel_connector *connector)
> > > if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT)
> > > level = (read_val[0] << 8 | read_val[1]);
> > >
> > > + if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> > > + if (!drm_dp_dpcd_readb(&intel_dp->aux,
> > > DP_EDP_PWMGEN_BIT_COUNT,
> > > + &read_val[0])) {
> > > + DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
> > > + DP_EDP_PWMGEN_BIT_COUNT);
> > > + return 0;
> > > + }
> > > + // Only bits 4:0 are used, 7:5 are reserved.
> > > + read_val[0] = read_val[0] & 0x1F;
> > > + if (read_val[0] > 16) {
> > > + DRM_DEBUG_KMS("Invalid DP_EDP_PWNGEN_BIT_COUNT
> > > 0x%X, expected at most 16\n",
> > > + read_val[0]);
> > > + return 0;
> > > + }
> > > + level >>= 16 - read_val[0];
> > > + }
> > > +
> > > return level;
> > > }
> > >
> > > @@ -106,6 +123,23 @@ intel_dp_aux_set_backlight(const struct
> > > drm_connector_state *conn_state, u32 lev
> > > struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > > u8 va
Re: [Linaro-mm-sig] Changing vma->vm_file in dma_buf_mmap()
On Thu, Sep 17, 2020 at 02:24:29PM +0200, Christian König wrote: > Am 17.09.20 um 14:18 schrieb Jason Gunthorpe: > > On Thu, Sep 17, 2020 at 02:03:48PM +0200, Christian König wrote: > > > Am 17.09.20 um 13:31 schrieb Jason Gunthorpe: > > > > On Thu, Sep 17, 2020 at 10:09:12AM +0200, Daniel Vetter wrote: > > > > > > > > > Yeah, but it doesn't work when forwarding from the drm chardev to the > > > > > dma-buf on the importer side, since you'd need a ton of different > > > > > address spaces. And you still rely on the core code picking up your > > > > > pgoff mangling, which feels about as risky to me as the vma file > > > > > pointer wrangling - if it's not consistently applied the reverse map > > > > > is toast and unmap_mapping_range doesn't work correctly for our needs. > > > > I would think the pgoff has to be translated at the same time the > > > > vm->vm_file is changed? > > > > > > > > The owner of the dma_buf should have one virtual address space and FD, > > > > all its dma bufs should be linked to it, and all pgoffs translated to > > > > that space. > > > Yeah, that is exactly like amdgpu is doing it. > > > > > > Going to document that somehow when I'm done with TTM cleanups. > > BTW, while people are looking at this, is there a way to go from a VMA > > to a dma_buf that owns it? > > Only a driver specific one. Sounds OK > For TTM drivers vma->vm_private_data points to the buffer object. Not sure > about the drivers using GEM only. Why are drivers in control of the vma? I would think dma_buf should be the vma owner. IIRC module lifetime correctness essentially hings on the module owner of the struct file > Why are you asking? I'm thinking about using find_vma on something that is not get_user_pages()'able to go to the underlying object, in this case dma buf. So, user VA -> find_vma -> dma_buf object -> dma_buf operations on the memory it represents Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] i915: Introduce quirk for shifting eDP brightness.
Apologies for being too vague. To be as precise I can be, here is the
specific code delta I tested: https://crrev.com/c/2406616 . To answer
your other question, the code I tested against is indeed including the
fde7266fb2f6 (despite ostensibly being called 5.4 in my commit
message): our current top-of-tree for our 5.4 branch includes the
intel_dp_aux_calc_max_backlight logic. Further, I'll note that change
is exactly the change which breaks my Pixelbook model: prior to the
change, the max_brightness was hard-coded to 0x and the math
worked out that it didn't matter that the hardware cared about the MSB
despite the driver code caring about the LSB.
To answer Ville's question: the fde7266fb2f6 change which fixes one
laptop (I believe Thinkpad X1 extreme Gen 2, from some bug reports I
dug up) and breaks another (Pixelbook); so unfortunately I believe we
need a quirk at least for some laptop. Reading through the copy of the
datasheet I have, it wasn't clear to me which was the correct
interpretation. I'm cc'ing puthik@, who was leaning toward the current
kernel code (caring about LSB) being the correct interpretation. I
believe we have other chromebooks which do rely on LSB functionality,
so unless we can find more examples of laptops wanting MSB it
currently looks like Pixelbook is the outlier.
On Thu, Sep 17, 2020 at 11:28 AM Jani Nikula
wrote:
>
> On Thu, 17 Sep 2020, Kevin Chowski wrote:
> > We have observed that Google Pixelbook's backlight hardware is
> > interpretting these backlight bits from the most-significant side of the
> > 16 bit word (if DP_EDP_PWMGEN_BIT_COUNT < 16), whereas the driver code
> > assumes the peripheral cares about the least-significant bits.
> >
> > Testing was done from within Chrome OS's build environment when the
> > patch is backported to 5.4 (the version we are newly targeting for the
> > Pixelbook); for the record:
> >$ emerge-eve-kernelnext sys-kernel/chromeos-kernel-5_4 && \
> > ./update_kernel.sh --remote=$IP
> >
> > I used `/sys/kernel/debug/dri/0/eDP-1/i915_dpcd` on my laptop to verify
> > that the registers were being set according to what the actual hardware
> > expects; I also observe that the backlight is noticeably brighter with
> > this patch.
>
> It's unclear to me what kernel version this is against, and what you've
> actually tested.
>
> Have you tried v5.7 kernel with Lyude's fde7266fb2f6 ("drm/i915: Fix eDP
> DPCD aux max backlight calculations")?
>
> I just want to make sure you've tested with all the relevant fixes
> before adding quirks.
>
> BR,
> Jani.
>
> >
> > Signed-off-by: Kevin Chowski
> > ---
> >
> > .../drm/i915/display/intel_dp_aux_backlight.c | 34 +++
> > drivers/gpu/drm/i915/display/intel_quirks.c | 13 +++
> > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > 3 files changed, 48 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > index acbd7eb66cbe3..99c98f217356d 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > @@ -91,6 +91,23 @@ static u32 intel_dp_aux_get_backlight(struct
> > intel_connector *connector)
> > if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT)
> > level = (read_val[0] << 8 | read_val[1]);
> >
> > + if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> > + if (!drm_dp_dpcd_readb(&intel_dp->aux,
> > DP_EDP_PWMGEN_BIT_COUNT,
> > + &read_val[0])) {
> > + DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
> > + DP_EDP_PWMGEN_BIT_COUNT);
> > + return 0;
> > + }
> > + // Only bits 4:0 are used, 7:5 are reserved.
> > + read_val[0] = read_val[0] & 0x1F;
> > + if (read_val[0] > 16) {
> > + DRM_DEBUG_KMS("Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X,
> > expected at most 16\n",
> > + read_val[0]);
> > + return 0;
> > + }
> > + level >>= 16 - read_val[0];
> > + }
> > +
> > return level;
> > }
> >
> > @@ -106,6 +123,23 @@ intel_dp_aux_set_backlight(const struct
> > drm_connector_state *conn_state, u32 lev
> > struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > u8 vals[2] = { 0x0 };
> >
> > + if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> > + if (!drm_dp_dpcd_readb(&intel_dp->aux,
> > DP_EDP_PWMGEN_BIT_COUNT,
> > + &vals[0])) {
> > + DRM_DEBUG_KMS("Failed to write aux backlight level:
> > Failed to read DPCD register 0x%x\n",
> > + DP_EDP_PWMGEN_BIT_COUNT);
> > + return;
> > + }
> >
Re: [PATCHv2] dt-bindings: dp-connector: add binding for DisplayPort connector
On Thu, Sep 17, 2020 at 03:39:38PM +0300, Tomi Valkeinen wrote: > On 17/09/2020 14:22, Ville Syrjälä wrote: > > On Thu, Sep 17, 2020 at 08:52:10AM +0300, Tomi Valkeinen wrote: > >> Add binding for DisplayPort connector. A few notes: > >> > >> * Similar to hdmi-connector, it has hpd-gpios as an optional property, > >> as the HPD could also be handled by, e.g., the DP bridge. > >> > >> * dp-pwr-supply, which provides 3.3V on DP_PWR pin, is optional, as it > >> is not strictly required: standard DP cables do not even have the pin > >> connected. > >> > >> * Connector type. Full size and mini connectors are identical except for > >> the connector size and form, so I believe there is no functional need > >> for this property. But similar to 'label' property, it might be used > >> to present information about the connector to the userspace. > >> > >> * No eDP. There's really no "eDP connector", as it's always a custom > >> made connection between the DP and the DP panel. So possibly there is > >> no need for edp-connector binding, but even if there is, I don't want > >> to guess what it could look like, and could it be part of the > >> dp-connector binding. > >> > >> * No DP++. I'm not familiar with DP++, but I think it's all handled by > >> the DP bridge, and does not need any new properties to the dp-connector. > > > > You might need an i2c bus for this. It's up to the source device > > to either hook up just AUX CH, or both AUX CH and DDC to a DP++ > > connector. If just AUX CH is wired up you are limited to using > > only type2 DP dual mode adapters, whereas if you also have DDC > > the crappier type1 adapters will also work. > > Ok, thanks for the clarifications on this. > > > I guess it's possible some bridges might handle all that for you. > > But eg. on i915 we always set up both AUX CH and DDC, and some > > extra circuitry on the board will isolate one or the other > > depending on what kind of dongle/cable gets plugged in > > (identified via the CONFIG pins). > > Is that automatic on i915? I could imagine a gpio-controlled mux doing the > isolation, and then we > need some driver controlling the gpio. Yeah, we don't even get the state of that pin in the driver. We just blindly probe both DDC and AUX CH. Due to the isolation only one goes through, the other other just times out. > > I could add the ddc bus the same way as on hdmi-connector.yaml, but perhaps > it's better to leave > that for someone with a DP++ board. Afaics, there should be no problems > adding this later. Another option might be to declare both dp and hdmi connectors for the same physical connector. That's the approach we use for drm_connectors in i915. But dunno if that's a good idea for dt. -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] i915: Introduce quirk for shifting eDP brightness.
On Thu, Sep 17, 2020 at 09:25:35PM +0300, Ville Syrjälä wrote:
> On Thu, Sep 17, 2020 at 11:14:43AM -0700, Puthikorn Voravootivat wrote:
> > The Lyude fde7266fb2f6 change is actually based on Chromium change
> > (https://crrev.com/c/1650325) that fixes the brightness for Samsung
> > Galaxy Chromebook. So currently we have 2 examples that use LSB
> > interpretation and 1 that use MSB.
>
> "If field 4:0 of the EDP_PWMGEN_BIT_COUNT register represents a value
> of greater than 8 and the BACKLIGHT_BRIGHTNESS_BYTE_COUNT bit
> is cleared to 0, only the 8 MSB of the brightness control value can be
> controlled.
> (See Note below.)
> Assigned bits are allocated to the MSB of the enabled register
> combination."
>
> I think that's pretty clear the assigned bits are supposed to be
> msb aligned.
I guess there's some email issues happening, but just to clarify:
When the spec says MSB in caps here it clearly means
"most significant-bit(s)" since otherwise "8 MSB" would not make
any sense in the context of a 2 byte value.
Granted the spec is crap here since "Table 1-1: Acronyms and
Initialism" does claim "MSB" should be byte(s) and "msb" bit(s).
Also I can't imagine anyone would allocate the bits starting
from the lsb when the whole thing is clearly supposed to be a
16bit big endian integer. So with >8 assigned bits you'd end
up with crazy stuff like this:
[ 7 ... 0 ][7 ... 0]
[ 8 MSB ][][N LSB]
so you couldn't even treat the value as a regular big endian
thing. Instead, if you squint a bit, it now looks like a funky
little endian value. So we're deep into some mixed endian land
where nothing makes sense anymore.
Anyways I think the code should simply do this to match the spec:
u16 value = brightness << (16 - num_assigned_bits);
val[0] = value >> 8;
val[1] = value & 0xff;
>
> >
> >
> > On Thu, Sep 17, 2020 at 10:55 AM Kevin Chowski wrote:
> > >
> > > Apologies for being too vague. To be as precise I can be, here is the
> > > specific code delta I tested: https://crrev.com/c/2406616 . To answer
> > > your other question, the code I tested against is indeed including the
> > > fde7266fb2f6 (despite ostensibly being called 5.4 in my commit
> > > message): our current top-of-tree for our 5.4 branch includes the
> > > intel_dp_aux_calc_max_backlight logic. Further, I'll note that change
> > > is exactly the change which breaks my Pixelbook model: prior to the
> > > change, the max_brightness was hard-coded to 0x and the math
> > > worked out that it didn't matter that the hardware cared about the MSB
> > > despite the driver code caring about the LSB.
> > >
> > > To answer Ville's question: the fde7266fb2f6 change which fixes one
> > > laptop (I believe Thinkpad X1 extreme Gen 2, from some bug reports I
> > > dug up) and breaks another (Pixelbook); so unfortunately I believe we
> > > need a quirk at least for some laptop. Reading through the copy of the
> > > datasheet I have, it wasn't clear to me which was the correct
> > > interpretation. I'm cc'ing puthik@, who was leaning toward the current
> > > kernel code (caring about LSB) being the correct interpretation. I
> > > believe we have other chromebooks which do rely on LSB functionality,
> > > so unless we can find more examples of laptops wanting MSB it
> > > currently looks like Pixelbook is the outlier.
> > >
> > > On Thu, Sep 17, 2020 at 11:28 AM Jani Nikula
> > > wrote:
> > > >
> > > > On Thu, 17 Sep 2020, Kevin Chowski wrote:
> > > > > We have observed that Google Pixelbook's backlight hardware is
> > > > > interpretting these backlight bits from the most-significant side of
> > > > > the
> > > > > 16 bit word (if DP_EDP_PWMGEN_BIT_COUNT < 16), whereas the driver code
> > > > > assumes the peripheral cares about the least-significant bits.
> > > > >
> > > > > Testing was done from within Chrome OS's build environment when the
> > > > > patch is backported to 5.4 (the version we are newly targeting for the
> > > > > Pixelbook); for the record:
> > > > >$ emerge-eve-kernelnext sys-kernel/chromeos-kernel-5_4 && \
> > > > > ./update_kernel.sh --remote=$IP
> > > > >
> > > > > I used `/sys/kernel/debug/dri/0/eDP-1/i915_dpcd` on my laptop to
> > > > > verify
> > > > > that the registers were being set according to what the actual
> > > > > hardware
> > > > > expects; I also observe that the backlight is noticeably brighter with
> > > > > this patch.
> > > >
> > > > It's unclear to me what kernel version this is against, and what you've
> > > > actually tested.
> > > >
> > > > Have you tried v5.7 kernel with Lyude's fde7266fb2f6 ("drm/i915: Fix eDP
> > > > DPCD aux max backlight calculations")?
> > > >
> > > > I just want to make sure you've tested with all the relevant fixes
> > > > before adding quirks.
> > > >
> > > > BR,
> > > > Jani.
> > > >
> > > > >
> > > > > Signed-off-by: Kevin Chowski
> > > > > ---
> > > > >
> > > > > .../drm/i915/display/intel_dp_aux_backlight.c | 34
> > > > > +++
> > > > > drivers
Re: [trivial PATCH] treewide: Convert switch/case fallthrough; to break;
On 9/9/2020 1:55 PM, Keith Busch wrote:
> On Wed, Sep 09, 2020 at 01:06:39PM -0700, Joe Perches wrote:
>> diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
>> index eea0f453cfb6..8aac5bc60f4c 100644
>> --- a/crypto/tcrypt.c
>> +++ b/crypto/tcrypt.c
>> @@ -2464,7 +2464,7 @@ static int do_test(const char *alg, u32 type, u32
>> mask, int m, u32 num_mb)
>> test_hash_speed("streebog512", sec,
>> generic_hash_speed_template);
>> if (mode > 300 && mode < 400) break;
>> -fallthrough;
>> +break;
>> case 399:
>> break;
>
> Just imho, this change makes the preceding 'if' look even more
> pointless. Maybe the fallthrough was a deliberate choice? Not that my
> opinion matters here as I don't know this module, but it looked a bit
> odd to me.
>
Yea this does look very odd..
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fbcon: Remove the superfluous break
On 9/17/20 08:15, Jing Xiangfeng wrote:
> Remove the superfuous break, as there is a 'return' before it.
>
> Signed-off-by: Jing Xiangfeng
Reviewed-by: Gustavo A. R. Silva
Also, the following Fixes tag should be included in the changelog text:
Fixes: bad07ff74c32 ("fbcon: smart blitter usage for scrolling")
Thanks
--
Gustavo
> ---
> drivers/video/fbdev/core/fbcon.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fbcon.c
> b/drivers/video/fbdev/core/fbcon.c
> index 0b49b0f44edf..623359aadd1e 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -1727,7 +1727,6 @@ static bool fbcon_scroll(struct vc_data *vc, unsigned
> int t, unsigned int b,
> vc->vc_video_erase_char,
> vc->vc_size_row * count);
> return true;
> - break;
>
> case SCROLL_WRAP_MOVE:
> if (b - t - count > 3 * vc->vc_rows >> 2) {
> @@ -1818,7 +1817,6 @@ static bool fbcon_scroll(struct vc_data *vc, unsigned
> int t, unsigned int b,
> vc->vc_video_erase_char,
> vc->vc_size_row * count);
> return true;
> - break;
>
> case SCROLL_WRAP_MOVE:
> if (b - t - count > 3 * vc->vc_rows >> 2) {
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] i915: Introduce quirk for shifting eDP brightness.
On Thu, 2020-09-17 at 11:31 -0600, Kevin Chowski wrote:
> Thanks very much for the quick reply, Lyude!
>
> I'm happy to make the requested changes, but I wanted to clarify before
> falling down the wrong hole: are you suggesting that I move
> the intel_dp_aux_set_backlight/intel_dp_aux_get_backlight routines to
> the drm_dp_helper.c file?
You don't have to do that yet (although I wouldn't object either way), I was
just mostly implying using drm_dp_has_quirk()
> On Thu, Sep 17, 2020 at 11:13 AM Lyude Paul wrote:
> > Just an FYI, my plan for some of this eDP backlight code is to move as much
> > of
> >
> > it into helpers as possible since we need to implement the same interface in
> >
> > nouveau. We probably can figure out some other solution for handling this
> > quirk
> >
> > if this isn't possible, but could we maybe use the panel's OUI here and add
> > a
> >
> > quirk to drm_dp_helper.c instead?
> >
> >
> >
> > On Thu, 2020-09-17 at 11:09 -0600, Kevin Chowski wrote:
> >
> > > We have observed that Google Pixelbook's backlight hardware is
> >
> > > interpretting these backlight bits from the most-significant side of the
> >
> > > 16 bit word (if DP_EDP_PWMGEN_BIT_COUNT < 16), whereas the driver code
> >
> > > assumes the peripheral cares about the least-significant bits.
> >
> > >
> >
> > > Testing was done from within Chrome OS's build environment when the
> >
> > > patch is backported to 5.4 (the version we are newly targeting for the
> >
> > > Pixelbook); for the record:
> >
> > >$ emerge-eve-kernelnext sys-kernel/chromeos-kernel-5_4 && \
> >
> > > ./update_kernel.sh --remote=$IP
> >
> > >
> >
> > > I used `/sys/kernel/debug/dri/0/eDP-1/i915_dpcd` on my laptop to verify
> >
> > > that the registers were being set according to what the actual hardware
> >
> > > expects; I also observe that the backlight is noticeably brighter with
> >
> > > this patch.
> >
> > >
> >
> > > Signed-off-by: Kevin Chowski
> >
> > > ---
> >
> > >
> >
> > > .../drm/i915/display/intel_dp_aux_backlight.c | 34 +++
> >
> > > drivers/gpu/drm/i915/display/intel_quirks.c | 13 +++
> >
> > > drivers/gpu/drm/i915/i915_drv.h | 1 +
> >
> > > 3 files changed, 48 insertions(+)
> >
> > >
> >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> >
> > > b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> >
> > > index acbd7eb66cbe3..99c98f217356d 100644
> >
> > > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> >
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> >
> > > @@ -91,6 +91,23 @@ static u32 intel_dp_aux_get_backlight(struct
> >
> > > intel_connector *connector)
> >
> > > if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT)
> >
> > > level = (read_val[0] << 8 | read_val[1]);
> >
> > >
> >
> > > + if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> >
> > > + if (!drm_dp_dpcd_readb(&intel_dp->aux,
> > DP_EDP_PWMGEN_BIT_COUNT,
> >
> > > + &read_val[0])) {
> >
> > > + DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
> >
> > > + DP_EDP_PWMGEN_BIT_COUNT);
> >
> > > + return 0;
> >
> > > + }
> >
> > > + // Only bits 4:0 are used, 7:5 are reserved.
> >
> > > + read_val[0] = read_val[0] & 0x1F;
> >
> > > + if (read_val[0] > 16) {
> >
> > > + DRM_DEBUG_KMS("Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X,
> >
> > > expected at most 16\n",
> >
> > > + read_val[0]);
> >
> > > + return 0;
> >
> > > + }
> >
> > > + level >>= 16 - read_val[0];
> >
> > > + }
> >
> > > +
> >
> > > return level;
> >
> > > }
> >
> > >
> >
> > > @@ -106,6 +123,23 @@ intel_dp_aux_set_backlight(const struct
> >
> > > drm_connector_state *conn_state, u32 lev
> >
> > > struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> >
> > > u8 vals[2] = { 0x0 };
> >
> > >
> >
> > > + if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> >
> > > + if (!drm_dp_dpcd_readb(&intel_dp->aux,
> > DP_EDP_PWMGEN_BIT_COUNT,
> >
> > > + &vals[0])) {
> >
> > > + DRM_DEBUG_KMS("Failed to write aux backlight level:
> >
> > > Failed to read DPCD register 0x%x\n",
> >
> > > + DP_EDP_PWMGEN_BIT_COUNT);
> >
> > > + return;
> >
> > > + }
> >
> > > + // Only bits 4:0 are used, 7:5 are reserved.
> >
> > > + vals[0] = vals[0] & 0x1F;
> >
> > > + if (vals[0] > 16) {
> >
> > > + DRM_DEBUG_KMS("Failed to write aux backlight level:
> >
> > > Invalid DP_E
Re: [PATCH] i915: Introduce quirk for shifting eDP brightness.
On Thu, 2020-09-17 at 21:25 +0300, Ville Syrjälä wrote:
> On Thu, Sep 17, 2020 at 11:14:43AM -0700, Puthikorn Voravootivat wrote:
> > The Lyude fde7266fb2f6 change is actually based on Chromium change
> > (https://crrev.com/c/1650325) that fixes the brightness for Samsung
> > Galaxy Chromebook. So currently we have 2 examples that use LSB
> > interpretation and 1 that use MSB.
>
> "If field 4:0 of the EDP_PWMGEN_BIT_COUNT register represents a value
> of greater than 8 and the BACKLIGHT_BRIGHTNESS_BYTE_COUNT bit
> is cleared to 0, only the 8 MSB of the brightness control value can be
> controlled.
> (See Note below.)
> Assigned bits are allocated to the MSB of the enabled register
> combination."
>
> I think that's pretty clear the assigned bits are supposed to be
> msb aligned.
Are we sure that isn't just referring to the DP_EDP_BACKLIGHT_BRIGHTNESS_MSB
register, as opposed to alignment of the whole value in that register? My
understanding of this was just that if there wasn't a pwmgen bit count
specified, that the backlight level would just be written to
DP_EDP_BACKLIGHT_BRIGHTNESS_MSB and DP_EDP_BACKLIGHT_BRIGHTNESS_LSB would be
ignored.
Hopefully I'm not misunderstanding Ville, but I don't think so since the current
code we have already follows the understanding I just gave:
vals[0] = level;
/* Write the MSB and/or LSB */
if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT) {
vals[0] = (level & 0xFF00) >> 8;
vals[1] = (level & 0xFF);
}
(vals[0] == MSB)
>
> >
> > On Thu, Sep 17, 2020 at 10:55 AM Kevin Chowski wrote:
> > > Apologies for being too vague. To be as precise I can be, here is the
> > > specific code delta I tested: https://crrev.com/c/2406616 . To answer
> > > your other question, the code I tested against is indeed including the
> > > fde7266fb2f6 (despite ostensibly being called 5.4 in my commit
> > > message): our current top-of-tree for our 5.4 branch includes the
> > > intel_dp_aux_calc_max_backlight logic. Further, I'll note that change
> > > is exactly the change which breaks my Pixelbook model: prior to the
> > > change, the max_brightness was hard-coded to 0x and the math
> > > worked out that it didn't matter that the hardware cared about the MSB
> > > despite the driver code caring about the LSB.
> > >
> > > To answer Ville's question: the fde7266fb2f6 change which fixes one
> > > laptop (I believe Thinkpad X1 extreme Gen 2, from some bug reports I
> > > dug up) and breaks another (Pixelbook); so unfortunately I believe we
> > > need a quirk at least for some laptop. Reading through the copy of the
> > > datasheet I have, it wasn't clear to me which was the correct
> > > interpretation. I'm cc'ing puthik@, who was leaning toward the current
> > > kernel code (caring about LSB) being the correct interpretation. I
> > > believe we have other chromebooks which do rely on LSB functionality,
> > > so unless we can find more examples of laptops wanting MSB it
> > > currently looks like Pixelbook is the outlier.
> > >
> > > On Thu, Sep 17, 2020 at 11:28 AM Jani Nikula
> > > wrote:
> > > > On Thu, 17 Sep 2020, Kevin Chowski wrote:
> > > > > We have observed that Google Pixelbook's backlight hardware is
> > > > > interpretting these backlight bits from the most-significant side of
> > > > > the
> > > > > 16 bit word (if DP_EDP_PWMGEN_BIT_COUNT < 16), whereas the driver code
> > > > > assumes the peripheral cares about the least-significant bits.
> > > > >
> > > > > Testing was done from within Chrome OS's build environment when the
> > > > > patch is backported to 5.4 (the version we are newly targeting for the
> > > > > Pixelbook); for the record:
> > > > >$ emerge-eve-kernelnext sys-kernel/chromeos-kernel-5_4 && \
> > > > > ./update_kernel.sh --remote=$IP
> > > > >
> > > > > I used `/sys/kernel/debug/dri/0/eDP-1/i915_dpcd` on my laptop to
> > > > > verify
> > > > > that the registers were being set according to what the actual
> > > > > hardware
> > > > > expects; I also observe that the backlight is noticeably brighter with
> > > > > this patch.
> > > >
> > > > It's unclear to me what kernel version this is against, and what you've
> > > > actually tested.
> > > >
> > > > Have you tried v5.7 kernel with Lyude's fde7266fb2f6 ("drm/i915: Fix eDP
> > > > DPCD aux max backlight calculations")?
> > > >
> > > > I just want to make sure you've tested with all the relevant fixes
> > > > before adding quirks.
> > > >
> > > > BR,
> > > > Jani.
> > > >
> > > > > Signed-off-by: Kevin Chowski
> > > > > ---
> > > > >
> > > > > .../drm/i915/display/intel_dp_aux_backlight.c | 34
> > > > > +++
> > > > > drivers/gpu/drm/i915/display/intel_quirks.c | 13 +++
> > > > > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > > > > 3 files changed, 48 insertions(+)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > > > b/drive
Re: [PATCH] i915: Introduce quirk for shifting eDP brightness.
On Thu, Sep 17, 2020 at 11:14:43AM -0700, Puthikorn Voravootivat wrote:
> The Lyude fde7266fb2f6 change is actually based on Chromium change
> (https://crrev.com/c/1650325) that fixes the brightness for Samsung
> Galaxy Chromebook. So currently we have 2 examples that use LSB
> interpretation and 1 that use MSB.
"If field 4:0 of the EDP_PWMGEN_BIT_COUNT register represents a value
of greater than 8 and the BACKLIGHT_BRIGHTNESS_BYTE_COUNT bit
is cleared to 0, only the 8 MSB of the brightness control value can be
controlled.
(See Note below.)
Assigned bits are allocated to the MSB of the enabled register
combination."
I think that's pretty clear the assigned bits are supposed to be
msb aligned.
>
>
> On Thu, Sep 17, 2020 at 10:55 AM Kevin Chowski wrote:
> >
> > Apologies for being too vague. To be as precise I can be, here is the
> > specific code delta I tested: https://crrev.com/c/2406616 . To answer
> > your other question, the code I tested against is indeed including the
> > fde7266fb2f6 (despite ostensibly being called 5.4 in my commit
> > message): our current top-of-tree for our 5.4 branch includes the
> > intel_dp_aux_calc_max_backlight logic. Further, I'll note that change
> > is exactly the change which breaks my Pixelbook model: prior to the
> > change, the max_brightness was hard-coded to 0x and the math
> > worked out that it didn't matter that the hardware cared about the MSB
> > despite the driver code caring about the LSB.
> >
> > To answer Ville's question: the fde7266fb2f6 change which fixes one
> > laptop (I believe Thinkpad X1 extreme Gen 2, from some bug reports I
> > dug up) and breaks another (Pixelbook); so unfortunately I believe we
> > need a quirk at least for some laptop. Reading through the copy of the
> > datasheet I have, it wasn't clear to me which was the correct
> > interpretation. I'm cc'ing puthik@, who was leaning toward the current
> > kernel code (caring about LSB) being the correct interpretation. I
> > believe we have other chromebooks which do rely on LSB functionality,
> > so unless we can find more examples of laptops wanting MSB it
> > currently looks like Pixelbook is the outlier.
> >
> > On Thu, Sep 17, 2020 at 11:28 AM Jani Nikula
> > wrote:
> > >
> > > On Thu, 17 Sep 2020, Kevin Chowski wrote:
> > > > We have observed that Google Pixelbook's backlight hardware is
> > > > interpretting these backlight bits from the most-significant side of the
> > > > 16 bit word (if DP_EDP_PWMGEN_BIT_COUNT < 16), whereas the driver code
> > > > assumes the peripheral cares about the least-significant bits.
> > > >
> > > > Testing was done from within Chrome OS's build environment when the
> > > > patch is backported to 5.4 (the version we are newly targeting for the
> > > > Pixelbook); for the record:
> > > >$ emerge-eve-kernelnext sys-kernel/chromeos-kernel-5_4 && \
> > > > ./update_kernel.sh --remote=$IP
> > > >
> > > > I used `/sys/kernel/debug/dri/0/eDP-1/i915_dpcd` on my laptop to verify
> > > > that the registers were being set according to what the actual hardware
> > > > expects; I also observe that the backlight is noticeably brighter with
> > > > this patch.
> > >
> > > It's unclear to me what kernel version this is against, and what you've
> > > actually tested.
> > >
> > > Have you tried v5.7 kernel with Lyude's fde7266fb2f6 ("drm/i915: Fix eDP
> > > DPCD aux max backlight calculations")?
> > >
> > > I just want to make sure you've tested with all the relevant fixes
> > > before adding quirks.
> > >
> > > BR,
> > > Jani.
> > >
> > > >
> > > > Signed-off-by: Kevin Chowski
> > > > ---
> > > >
> > > > .../drm/i915/display/intel_dp_aux_backlight.c | 34 +++
> > > > drivers/gpu/drm/i915/display/intel_quirks.c | 13 +++
> > > > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > > > 3 files changed, 48 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > > b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > > index acbd7eb66cbe3..99c98f217356d 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > > @@ -91,6 +91,23 @@ static u32 intel_dp_aux_get_backlight(struct
> > > > intel_connector *connector)
> > > > if (intel_dp->edp_dpcd[2] &
> > > > DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT)
> > > > level = (read_val[0] << 8 | read_val[1]);
> > > >
> > > > + if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> > > > + if (!drm_dp_dpcd_readb(&intel_dp->aux,
> > > > DP_EDP_PWMGEN_BIT_COUNT,
> > > > + &read_val[0])) {
> > > > + DRM_DEBUG_KMS("Failed to read DPCD register
> > > > 0x%x\n",
> > > > + DP_EDP_PWMGEN_BIT_COUNT);
> > > > + return 0;
> > > > + }
> > > > + // Only bits 4:0 are used, 7:
Re: drm/ast something ate high-res modes (5.3->5.6 regression)
Hi, Yes, I can build custom kernels and test but I won't have time for that before the end of September so I'll do it only then. And thanks a lot :-). -- i. On Thu, 17 Sep 2020, Thomas Zimmermann wrote: > Hi > > Am 08.07.20 um 12:05 schrieb Ilpo Järvinen: > > Hi, > > > > After upgrading kernel from 5.3 series to 5.6.16 something seems to > > prevent me from achieving high resolutions with the ast driver. > > Are you able to build and run a test kernel? > > I'm seriously considering moving ast to the SHMEM memory manager, which > would restore the higher resolutions. > > If you're able to test, you need the git tree drm-tip/drm-tip and the > attached patch. > > Alternatively, I've pushed all to > > https://gitlab.freedesktop.org/tzimmermann/linux/-/tree/ast-shmem > > You'd have to checkout the tree and switch to the ast-shmem branch. > > Please report back if that solves the issue for you. > > Best regards > Thomas > > > > > With 5.6.16: > > > > $ xrandr > > Screen 0: minimum 320 x 200, current 1600 x 1200, maximum 1920 x 2048 > > VGA-1 connected primary 1600x1200+0+0 (normal left inverted right x axis y > > axis) 519mm x 324mm > >1600x1200 60.00* > >1680x1050 59.95 > >1280x1024 75.0260.02 > >1440x900 59.89 > >1280x800 59.81 > >1024x768 75.0360.00 > >800x600 75.0060.32 > >640x480 75.0059.94 > >1920x1200_60.0 59.95 > > > > If I try to change to that manually added high-res mode, I get: > > xrandr: Configure crtc 0 failed > > > > With 5.3 series I've this: > > > > Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 1920 x 2048 > > VGA-1 connected primary 1920x1200+0+0 (normal left inverted right x axis y > > axis) 519mm x 324mm > >1920x1200 59.95*+ > >1600x1200 60.00 > >1680x1050 59.95 > >1280x1024 75.0260.02 > >1440x900 59.89 > >1280x800 59.81 > >1024x768 75.0360.00 > >800x600 75.0060.32 > >640x480 75.0059.94 > >1920x1200_60.0 59.95 > > > > As I've had issues in getting EDID reliably from the monitor, I provide it > > on kernel command-line (the one dumped from the monitor I use). In > > addition, I've another workaround for past issues related to EDID which > > always adds that 1920x1200_60.0 mode but now I cannot use even it to > > enter a high-res mode. > > > > If you need some additional info or want me to test a patch, just let me > > know (but some delay is expected in testing patches). Thanks. > > > > > >___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] i915: Introduce quirk for shifting eDP brightness.
On Thu, 17 Sep 2020, Kevin Chowski wrote:
> We have observed that Google Pixelbook's backlight hardware is
> interpretting these backlight bits from the most-significant side of the
> 16 bit word (if DP_EDP_PWMGEN_BIT_COUNT < 16), whereas the driver code
> assumes the peripheral cares about the least-significant bits.
>
> Testing was done from within Chrome OS's build environment when the
> patch is backported to 5.4 (the version we are newly targeting for the
> Pixelbook); for the record:
>$ emerge-eve-kernelnext sys-kernel/chromeos-kernel-5_4 && \
> ./update_kernel.sh --remote=$IP
>
> I used `/sys/kernel/debug/dri/0/eDP-1/i915_dpcd` on my laptop to verify
> that the registers were being set according to what the actual hardware
> expects; I also observe that the backlight is noticeably brighter with
> this patch.
It's unclear to me what kernel version this is against, and what you've
actually tested.
Have you tried v5.7 kernel with Lyude's fde7266fb2f6 ("drm/i915: Fix eDP
DPCD aux max backlight calculations")?
I just want to make sure you've tested with all the relevant fixes
before adding quirks.
BR,
Jani.
>
> Signed-off-by: Kevin Chowski
> ---
>
> .../drm/i915/display/intel_dp_aux_backlight.c | 34 +++
> drivers/gpu/drm/i915/display/intel_quirks.c | 13 +++
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> 3 files changed, 48 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> index acbd7eb66cbe3..99c98f217356d 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> @@ -91,6 +91,23 @@ static u32 intel_dp_aux_get_backlight(struct
> intel_connector *connector)
> if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT)
> level = (read_val[0] << 8 | read_val[1]);
>
> + if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> + if (!drm_dp_dpcd_readb(&intel_dp->aux, DP_EDP_PWMGEN_BIT_COUNT,
> + &read_val[0])) {
> + DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
> + DP_EDP_PWMGEN_BIT_COUNT);
> + return 0;
> + }
> + // Only bits 4:0 are used, 7:5 are reserved.
> + read_val[0] = read_val[0] & 0x1F;
> + if (read_val[0] > 16) {
> + DRM_DEBUG_KMS("Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X,
> expected at most 16\n",
> + read_val[0]);
> + return 0;
> + }
> + level >>= 16 - read_val[0];
> + }
> +
> return level;
> }
>
> @@ -106,6 +123,23 @@ intel_dp_aux_set_backlight(const struct
> drm_connector_state *conn_state, u32 lev
> struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> u8 vals[2] = { 0x0 };
>
> + if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> + if (!drm_dp_dpcd_readb(&intel_dp->aux, DP_EDP_PWMGEN_BIT_COUNT,
> + &vals[0])) {
> + DRM_DEBUG_KMS("Failed to write aux backlight level:
> Failed to read DPCD register 0x%x\n",
> + DP_EDP_PWMGEN_BIT_COUNT);
> + return;
> + }
> + // Only bits 4:0 are used, 7:5 are reserved.
> + vals[0] = vals[0] & 0x1F;
> + if (vals[0] > 16) {
> + DRM_DEBUG_KMS("Failed to write aux backlight level:
> Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X, expected at most 16\n",
> + vals[0]);
> + return;
> + }
> + level <<= (16 - vals[0]) & 0x;
> + }
> +
> vals[0] = level;
>
> /* Write the MSB and/or LSB */
> diff --git a/drivers/gpu/drm/i915/display/intel_quirks.c
> b/drivers/gpu/drm/i915/display/intel_quirks.c
> index 46beb155d835f..63b27d49b2864 100644
> --- a/drivers/gpu/drm/i915/display/intel_quirks.c
> +++ b/drivers/gpu/drm/i915/display/intel_quirks.c
> @@ -53,6 +53,16 @@ static void quirk_increase_ddi_disabled_time(struct
> drm_i915_private *i915)
> drm_info(&i915->drm, "Applying Increase DDI Disabled quirk\n");
> }
>
> +/*
> + * Some eDP backlight hardware uses the most-significant bits of the
> brightness
> + * register, so brightness values must be shifted first.
> + */
> +static void quirk_shift_edp_backlight_brightness(struct drm_i915_private
> *i915)
> +{
> + i915->quirks |= QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS;
> + DRM_INFO("Applying shift eDP backlight brightness quirk\n");
> +}
> +
> struct intel_quirk {
> int device;
> int subsystem_vendor;
> @@ -156,6 +166,9 @@ static struct intel_quirk intel_quirks[] = {
> /* ASRock ITX*/
> { 0x3185, 0x1849, 0x
Re: [PATCH] i915: Introduce quirk for shifting eDP brightness.
On Thu, Sep 17, 2020 at 11:09:06AM -0600, Kevin Chowski wrote:
> We have observed that Google Pixelbook's backlight hardware is
> interpretting these backlight bits from the most-significant side of the
> 16 bit word (if DP_EDP_PWMGEN_BIT_COUNT < 16), whereas the driver code
> assumes the peripheral cares about the least-significant bits.
The spec seems to agree with the msb interpretation. So looks like
the current code is just broken?
>
> Testing was done from within Chrome OS's build environment when the
> patch is backported to 5.4 (the version we are newly targeting for the
> Pixelbook); for the record:
>$ emerge-eve-kernelnext sys-kernel/chromeos-kernel-5_4 && \
> ./update_kernel.sh --remote=$IP
>
> I used `/sys/kernel/debug/dri/0/eDP-1/i915_dpcd` on my laptop to verify
> that the registers were being set according to what the actual hardware
> expects; I also observe that the backlight is noticeably brighter with
> this patch.
>
> Signed-off-by: Kevin Chowski
> ---
>
> .../drm/i915/display/intel_dp_aux_backlight.c | 34 +++
> drivers/gpu/drm/i915/display/intel_quirks.c | 13 +++
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> 3 files changed, 48 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> index acbd7eb66cbe3..99c98f217356d 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> @@ -91,6 +91,23 @@ static u32 intel_dp_aux_get_backlight(struct
> intel_connector *connector)
> if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT)
> level = (read_val[0] << 8 | read_val[1]);
>
> + if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> + if (!drm_dp_dpcd_readb(&intel_dp->aux, DP_EDP_PWMGEN_BIT_COUNT,
> + &read_val[0])) {
> + DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
> + DP_EDP_PWMGEN_BIT_COUNT);
> + return 0;
> + }
> + // Only bits 4:0 are used, 7:5 are reserved.
> + read_val[0] = read_val[0] & 0x1F;
> + if (read_val[0] > 16) {
> + DRM_DEBUG_KMS("Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X,
> expected at most 16\n",
> + read_val[0]);
> + return 0;
> + }
> + level >>= 16 - read_val[0];
> + }
> +
> return level;
> }
>
> @@ -106,6 +123,23 @@ intel_dp_aux_set_backlight(const struct
> drm_connector_state *conn_state, u32 lev
> struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> u8 vals[2] = { 0x0 };
>
> + if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> + if (!drm_dp_dpcd_readb(&intel_dp->aux, DP_EDP_PWMGEN_BIT_COUNT,
> + &vals[0])) {
> + DRM_DEBUG_KMS("Failed to write aux backlight level:
> Failed to read DPCD register 0x%x\n",
> + DP_EDP_PWMGEN_BIT_COUNT);
> + return;
> + }
> + // Only bits 4:0 are used, 7:5 are reserved.
> + vals[0] = vals[0] & 0x1F;
> + if (vals[0] > 16) {
> + DRM_DEBUG_KMS("Failed to write aux backlight level:
> Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X, expected at most 16\n",
> + vals[0]);
> + return;
> + }
> + level <<= (16 - vals[0]) & 0x;
> + }
> +
> vals[0] = level;
>
> /* Write the MSB and/or LSB */
> diff --git a/drivers/gpu/drm/i915/display/intel_quirks.c
> b/drivers/gpu/drm/i915/display/intel_quirks.c
> index 46beb155d835f..63b27d49b2864 100644
> --- a/drivers/gpu/drm/i915/display/intel_quirks.c
> +++ b/drivers/gpu/drm/i915/display/intel_quirks.c
> @@ -53,6 +53,16 @@ static void quirk_increase_ddi_disabled_time(struct
> drm_i915_private *i915)
> drm_info(&i915->drm, "Applying Increase DDI Disabled quirk\n");
> }
>
> +/*
> + * Some eDP backlight hardware uses the most-significant bits of the
> brightness
> + * register, so brightness values must be shifted first.
> + */
> +static void quirk_shift_edp_backlight_brightness(struct drm_i915_private
> *i915)
> +{
> + i915->quirks |= QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS;
> + DRM_INFO("Applying shift eDP backlight brightness quirk\n");
> +}
> +
> struct intel_quirk {
> int device;
> int subsystem_vendor;
> @@ -156,6 +166,9 @@ static struct intel_quirk intel_quirks[] = {
> /* ASRock ITX*/
> { 0x3185, 0x1849, 0x2212, quirk_increase_ddi_disabled_time },
> { 0x3184, 0x1849, 0x2212, quirk_increase_ddi_disabled_time },
> +
> + /* Google Pixelbook */
> + { 0x591E, 0x8086, 0x221
Re: [PATCH] drm/doc: Document that modifiers are always required for fb
Acked-by: Bas Nieuwenhuizen
On Thu, Sep 17, 2020 at 6:48 PM Daniel Vetter wrote:
>
> Even for legacy userspace, since otherwise GETFB2 is broken and if you
> switch between modifier-less and modifier-aware compositors, smooth
> transitions break.
>
> Also it's just best practice to make sure modifiers are invariant for
> a given drm_fb, and that a modifier-aware kms drivers only has one
> place to store them, ignoring any old implicit bo flags or whatever
> else might float around.
>
> Motivated by some irc discussion with Bas about amdgpu modifier
> support.
>
> Acked-by: Simon Ser
> Acked-by: Daniel Stone
> Acked-by: Pekka Paalanen
> Fixes: 455e00f1412f ("drm: Add getfb2 ioctl")
> Cc: Daniel Stone
> Cc: Juston Li
> Cc: Daniel Vetter
> Cc: Ville Syrjälä
> Cc: Bas Nieuwenhuizen
> Cc: Marek Olšák
> Cc: "Wentland, Harry"
> Signed-off-by: Daniel Vetter
> ---
> Sending this out again to double-check there's no objections or concerns.
> From what I understand looking at the code the latest modifier patches for
> amdgpu follow this now.
>
> Cheers, Daniel
> ---
> include/drm/drm_mode_config.h | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index a18f73eb3cf6..5ffbb4ed5b35 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -58,6 +58,12 @@ struct drm_mode_config_funcs {
> * actual modifier used if the request doesn't have it specified,
> * ie. when (@mode_cmd->flags & DRM_MODE_FB_MODIFIERS) == 0.
> *
> +* IMPORTANT: These implied modifiers for legacy userspace must be
> +* stored in struct &drm_framebuffer, including all relevant metadata
> +* like &drm_framebuffer.pitches and &drm_framebuffer.offsets if the
> +* modifier enables additional planes beyond the fourcc pixel format
> +* code. This is required by the GETFB2 ioctl.
> +*
> * If the parameters are deemed valid and the backing storage objects
> in
> * the underlying memory manager all exist, then the driver allocates
> * a new &drm_framebuffer structure, subclassed to contain
> @@ -915,6 +921,13 @@ struct drm_mode_config {
> * @allow_fb_modifiers:
> *
> * Whether the driver supports fb modifiers in the ADDFB2.1 ioctl
> call.
> +*
> +* IMPORTANT:
> +*
> +* If this is set the driver must fill out the full implicit modifier
> +* information in their &drm_mode_config_funcs.fb_create hook for
> legacy
> +* userspace which does not set modifiers. Otherwise the GETFB2 ioctl
> is
> +* broken for modifier aware userspace.
> */
> bool allow_fb_modifiers;
>
> --
> 2.28.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] Changing vma->vm_file in dma_buf_mmap()
On Thu, Sep 17, 2020 at 6:39 PM Jason Gunthorpe wrote: > > On Thu, Sep 17, 2020 at 06:06:14PM +0200, Christian König wrote: > > > > If it is already taking a page fault I'm not sure the extra function > > > > call indirection is going to be a big deal. Having a uniform VMA > > > > sounds saner than every driver custom rolling something. > > > > > > > > When I unwound a similar mess in RDMA all the custom VMA stuff in the > > > > drivers turned out to be generally buggy, at least. > > > > > > > > Is vma->vm_file->private_data universally a dma_buf pointer at least? > > > Nope. I think if you want this without some large scale rewrite of a > > > lot of code we'd need a vmops->get_dmabuf or similar. Not pretty, but > > > would get the job done. > > > > Yeah, agree that sounds like the simplest approach. > > I don't think that will fly, it is clearly only papering over a mess > inside DRM/dma buf :\ dma-buf started out as something to paper over the disjoint mess of allocators, since it was pretty clear to anyone involved we're not going to unify them anytime soon, if ever. So the mess pretty much is bound to stay. I think most reasonable thing would be to throw a common vmops in there somehow, but even that means some large scale surgery across every driver/subsystem involved in dma-buf. It wouldn't unify anything, all it would give you is a constant vma->vm_ops to do some kind of upcasting. And that would still only give you a slightly less opaque pointer with a callback to upcast to a dma-buf in some driver/subsystem specific way. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] i915: Introduce quirk for shifting eDP brightness.
Just an FYI, my plan for some of this eDP backlight code is to move as much of
it into helpers as possible since we need to implement the same interface in
nouveau. We probably can figure out some other solution for handling this quirk
if this isn't possible, but could we maybe use the panel's OUI here and add a
quirk to drm_dp_helper.c instead?
On Thu, 2020-09-17 at 11:09 -0600, Kevin Chowski wrote:
> We have observed that Google Pixelbook's backlight hardware is
> interpretting these backlight bits from the most-significant side of the
> 16 bit word (if DP_EDP_PWMGEN_BIT_COUNT < 16), whereas the driver code
> assumes the peripheral cares about the least-significant bits.
>
> Testing was done from within Chrome OS's build environment when the
> patch is backported to 5.4 (the version we are newly targeting for the
> Pixelbook); for the record:
>$ emerge-eve-kernelnext sys-kernel/chromeos-kernel-5_4 && \
> ./update_kernel.sh --remote=$IP
>
> I used `/sys/kernel/debug/dri/0/eDP-1/i915_dpcd` on my laptop to verify
> that the registers were being set according to what the actual hardware
> expects; I also observe that the backlight is noticeably brighter with
> this patch.
>
> Signed-off-by: Kevin Chowski
> ---
>
> .../drm/i915/display/intel_dp_aux_backlight.c | 34 +++
> drivers/gpu/drm/i915/display/intel_quirks.c | 13 +++
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> 3 files changed, 48 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> index acbd7eb66cbe3..99c98f217356d 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> @@ -91,6 +91,23 @@ static u32 intel_dp_aux_get_backlight(struct
> intel_connector *connector)
> if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT)
> level = (read_val[0] << 8 | read_val[1]);
>
> + if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> + if (!drm_dp_dpcd_readb(&intel_dp->aux, DP_EDP_PWMGEN_BIT_COUNT,
> + &read_val[0])) {
> + DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
> + DP_EDP_PWMGEN_BIT_COUNT);
> + return 0;
> + }
> + // Only bits 4:0 are used, 7:5 are reserved.
> + read_val[0] = read_val[0] & 0x1F;
> + if (read_val[0] > 16) {
> + DRM_DEBUG_KMS("Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X,
> expected at most 16\n",
> + read_val[0]);
> + return 0;
> + }
> + level >>= 16 - read_val[0];
> + }
> +
> return level;
> }
>
> @@ -106,6 +123,23 @@ intel_dp_aux_set_backlight(const struct
> drm_connector_state *conn_state, u32 lev
> struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> u8 vals[2] = { 0x0 };
>
> + if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> + if (!drm_dp_dpcd_readb(&intel_dp->aux, DP_EDP_PWMGEN_BIT_COUNT,
> + &vals[0])) {
> + DRM_DEBUG_KMS("Failed to write aux backlight level:
> Failed to read DPCD register 0x%x\n",
> + DP_EDP_PWMGEN_BIT_COUNT);
> + return;
> + }
> + // Only bits 4:0 are used, 7:5 are reserved.
> + vals[0] = vals[0] & 0x1F;
> + if (vals[0] > 16) {
> + DRM_DEBUG_KMS("Failed to write aux backlight level:
> Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X, expected at most 16\n",
> + vals[0]);
> + return;
> + }
> + level <<= (16 - vals[0]) & 0x;
> + }
> +
> vals[0] = level;
>
> /* Write the MSB and/or LSB */
> diff --git a/drivers/gpu/drm/i915/display/intel_quirks.c
> b/drivers/gpu/drm/i915/display/intel_quirks.c
> index 46beb155d835f..63b27d49b2864 100644
> --- a/drivers/gpu/drm/i915/display/intel_quirks.c
> +++ b/drivers/gpu/drm/i915/display/intel_quirks.c
> @@ -53,6 +53,16 @@ static void quirk_increase_ddi_disabled_time(struct
> drm_i915_private *i915)
> drm_info(&i915->drm, "Applying Increase DDI Disabled quirk\n");
> }
>
> +/*
> + * Some eDP backlight hardware uses the most-significant bits of the
> brightness
> + * register, so brightness values must be shifted first.
> + */
> +static void quirk_shift_edp_backlight_brightness(struct drm_i915_private
> *i915)
> +{
> + i915->quirks |= QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS;
> + DRM_INFO("Applying shift eDP backlight brightness quirk\n");
> +}
> +
> struct intel_quirk {
> int device;
> int subsystem_vendor;
> @@ -156,6 +166,9 @@ static struct intel_quirk intel_quirks[] = {
[PATCH] drm/doc: Document that modifiers are always required for fb
Even for legacy userspace, since otherwise GETFB2 is broken and if you
switch between modifier-less and modifier-aware compositors, smooth
transitions break.
Also it's just best practice to make sure modifiers are invariant for
a given drm_fb, and that a modifier-aware kms drivers only has one
place to store them, ignoring any old implicit bo flags or whatever
else might float around.
Motivated by some irc discussion with Bas about amdgpu modifier
support.
Acked-by: Simon Ser
Acked-by: Daniel Stone
Acked-by: Pekka Paalanen
Fixes: 455e00f1412f ("drm: Add getfb2 ioctl")
Cc: Daniel Stone
Cc: Juston Li
Cc: Daniel Vetter
Cc: Ville Syrjälä
Cc: Bas Nieuwenhuizen
Cc: Marek Olšák
Cc: "Wentland, Harry"
Signed-off-by: Daniel Vetter
---
Sending this out again to double-check there's no objections or concerns.
From what I understand looking at the code the latest modifier patches for
amdgpu follow this now.
Cheers, Daniel
---
include/drm/drm_mode_config.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index a18f73eb3cf6..5ffbb4ed5b35 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -58,6 +58,12 @@ struct drm_mode_config_funcs {
* actual modifier used if the request doesn't have it specified,
* ie. when (@mode_cmd->flags & DRM_MODE_FB_MODIFIERS) == 0.
*
+* IMPORTANT: These implied modifiers for legacy userspace must be
+* stored in struct &drm_framebuffer, including all relevant metadata
+* like &drm_framebuffer.pitches and &drm_framebuffer.offsets if the
+* modifier enables additional planes beyond the fourcc pixel format
+* code. This is required by the GETFB2 ioctl.
+*
* If the parameters are deemed valid and the backing storage objects in
* the underlying memory manager all exist, then the driver allocates
* a new &drm_framebuffer structure, subclassed to contain
@@ -915,6 +921,13 @@ struct drm_mode_config {
* @allow_fb_modifiers:
*
* Whether the driver supports fb modifiers in the ADDFB2.1 ioctl call.
+*
+* IMPORTANT:
+*
+* If this is set the driver must fill out the full implicit modifier
+* information in their &drm_mode_config_funcs.fb_create hook for legacy
+* userspace which does not set modifiers. Otherwise the GETFB2 ioctl is
+* broken for modifier aware userspace.
*/
bool allow_fb_modifiers;
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v5 14/20] drm/nouveau/kms/nv50-: Use downstream DP clock limits for mode validation
On Wed, Aug 26, 2020 at 02:24:50PM -0400, Lyude Paul wrote:
> This adds support for querying the maximum clock rate of a downstream
> port on a DisplayPort connection. Generally, downstream ports refer to
> active dongles which can have their own pixel clock limits.
>
> Note as well, we also start marking the connector as disconnected if we
> can't read the DPCD, since we wouldn't be able to do anything without
> DPCD access anyway.
>
> Signed-off-by: Lyude Paul
> Reviewed-by: Ben Skeggs
> ---
> drivers/gpu/drm/nouveau/dispnv50/disp.c | 3 +++
> drivers/gpu/drm/nouveau/nouveau_dp.c | 15 +++
> drivers/gpu/drm/nouveau/nouveau_encoder.h | 1 +
> 3 files changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> index 8e1effb10425d..d2141ca16107b 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> @@ -1258,7 +1258,10 @@ nv50_mstc_detect(struct drm_connector *connector,
>
> ret = drm_dp_mst_detect_port(connector, ctx, mstc->port->mgr,
>mstc->port);
> + if (ret != connector_status_connected)
> + goto out;
>
> +out:
> pm_runtime_mark_last_busy(connector->dev->dev);
> pm_runtime_put_autosuspend(connector->dev->dev);
> return ret;
> diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
> b/drivers/gpu/drm/nouveau/nouveau_dp.c
> index 005750aeb6d4f..ad852e572cfec 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_dp.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
> @@ -61,6 +61,11 @@ nouveau_dp_probe_dpcd(struct nouveau_connector
> *nv_connector,
> mstm->can_mst = drm_dp_read_mst_cap(aux, dpcd);
> }
>
> + ret = drm_dp_read_downstream_info(aux, dpcd,
> + outp->dp.downstream_ports);
> + if (ret < 0)
> + return connector_status_disconnected;
> +
> return connector_status_connected;
> }
>
> @@ -176,8 +181,6 @@ void nouveau_dp_irq(struct nouveau_drm *drm,
> /* TODO:
> * - Use the minimum possible BPC here, once we add support for the max bpc
> * property.
> - * - Validate the mode against downstream port caps (see
> - * drm_dp_downstream_max_clock())
> * - Validate against the DP caps advertised by the GPU (we don't check these
> * yet)
> */
> @@ -188,15 +191,19 @@ nv50_dp_mode_valid(struct drm_connector *connector,
> unsigned *out_clock)
> {
> const unsigned min_clock = 25000;
> - unsigned max_clock, clock;
> + unsigned max_clock, ds_clock, clock;
> enum drm_mode_status ret;
>
> if (mode->flags & DRM_MODE_FLAG_INTERLACE && !outp->caps.dp_interlace)
> return MODE_NO_INTERLACE;
I stumbled on this code when applying my big DFP series (sorry that
I forgot to read this while it was on the list).
Anyways, this code appears somewhat confused about the different
clocks.
>
> max_clock = outp->dp.link_nr * outp->dp.link_bw;
That I presume is the max symbol rate of the link.
> - clock = mode->clock * (connector->display_info.bpc * 3) / 10;
> + ds_clock = drm_dp_downstream_max_clock(outp->dp.dpcd,
> +outp->dp.downstream_ports);
That is the maximum dotclock (also the max TMDS clock before my DFP
series landed) the DFP supports.
> + if (ds_clock)
> + max_clock = min(max_clock, ds_clock);
max() between the symbol rate and dotclock doesn't really
make sense. One is the amount of symbols (or data in other
words), the other is amount of pixels (which depending on
bpc can result in various amounts of symbols/data).
>
> + clock = mode->clock * (connector->display_info.bpc * 3) / 10;
I presume this trying to compute the symbol rate we require.
Due to the 8b/10b encoding each 10bit symbol carries 8 bits of
actual data, so the /10 should be /8. IIRC we had this same
bug in i915, but it was fixed years ago.
This is also calculating things based on display_info.bpc which
IIRC is the max bpc the display supports. Using the max may be
overly pessimistic in case a) the driver/hw doesn't even support
bpc that high, b) the driver can dynamically reduce the bpc in
order to fit the mode onto the link. In i915 we take the opposite
approach and just use the min bpc (==6) in mode_valid(). During
modeset we start from the max bpc and keep reducing it until
things fit.
So I suspect what you want here is something like:
max_clock = outp->dp.link_nr * outp->dp.link_bw;
clock = mode->clock * (connector->display_info.bpc * 3) / 8; // or maybe just
use 6 for bpc
if (clock > max_clock)
reurn CLOCK_HIGH;
ds_clock = drm_dp_downstream_max_dotclock();
if (ds_clock && mode->clock > ds_clock)
return CLOCK_HIGH;
+ a bit more if you want to also deal with the TMDS
clock limits sensibly. That also requires some though
as to which bpc to use. In i915 w
Re: [PATCHv2] dt-bindings: dp-connector: add binding for DisplayPort connector
On 17/09/2020 14:22, Ville Syrjälä wrote: > On Thu, Sep 17, 2020 at 08:52:10AM +0300, Tomi Valkeinen wrote: >> Add binding for DisplayPort connector. A few notes: >> >> * Similar to hdmi-connector, it has hpd-gpios as an optional property, >> as the HPD could also be handled by, e.g., the DP bridge. >> >> * dp-pwr-supply, which provides 3.3V on DP_PWR pin, is optional, as it >> is not strictly required: standard DP cables do not even have the pin >> connected. >> >> * Connector type. Full size and mini connectors are identical except for >> the connector size and form, so I believe there is no functional need >> for this property. But similar to 'label' property, it might be used >> to present information about the connector to the userspace. >> >> * No eDP. There's really no "eDP connector", as it's always a custom >> made connection between the DP and the DP panel. So possibly there is >> no need for edp-connector binding, but even if there is, I don't want >> to guess what it could look like, and could it be part of the >> dp-connector binding. >> >> * No DP++. I'm not familiar with DP++, but I think it's all handled by >> the DP bridge, and does not need any new properties to the dp-connector. > > You might need an i2c bus for this. It's up to the source device > to either hook up just AUX CH, or both AUX CH and DDC to a DP++ > connector. If just AUX CH is wired up you are limited to using > only type2 DP dual mode adapters, whereas if you also have DDC > the crappier type1 adapters will also work. Ok, thanks for the clarifications on this. > I guess it's possible some bridges might handle all that for you. > But eg. on i915 we always set up both AUX CH and DDC, and some > extra circuitry on the board will isolate one or the other > depending on what kind of dongle/cable gets plugged in > (identified via the CONFIG pins). Is that automatic on i915? I could imagine a gpio-controlled mux doing the isolation, and then we need some driver controlling the gpio. I could add the ddc bus the same way as on hdmi-connector.yaml, but perhaps it's better to leave that for someone with a DP++ board. Afaics, there should be no problems adding this later. Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [patch 00/13] preempt: Make preempt count unconditional
On Thu, Sep 17, 2020 at 09:52:30AM +0200, Daniel Vetter wrote: > On Thu, Sep 17, 2020 at 12:39 AM Paul E. McKenney wrote: > > > > On Wed, Sep 16, 2020 at 11:43:02PM +0200, Daniel Vetter wrote: > > > On Wed, Sep 16, 2020 at 10:58 PM Paul E. McKenney > > > wrote: > > > > > > > > On Wed, Sep 16, 2020 at 10:29:06PM +0200, Daniel Vetter wrote: > > > > > On Wed, Sep 16, 2020 at 5:29 PM Paul E. McKenney > > > > > wrote: > > > > > > > > > > > > On Wed, Sep 16, 2020 at 09:37:17AM +0200, Daniel Vetter wrote: > > > > > > > On Tue, Sep 15, 2020 at 7:35 PM Linus Torvalds > > > > > > > wrote: > > > > > > > > > > > > > > > > On Tue, Sep 15, 2020 at 1:39 AM Thomas Gleixner > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > OTOH, having a working 'preemptible()' or maybe better named > > > > > > > > > 'can_schedule()' check makes tons of sense to make decisions > > > > > > > > > about > > > > > > > > > allocation modes or other things. > > > > > > > > > > > > > > > > No. I think that those kinds of decisions about actual behavior > > > > > > > > are > > > > > > > > always simply fundamentally wrong. > > > > > > > > > > > > > > > > Note that this is very different from having warnings about > > > > > > > > invalid > > > > > > > > use. THAT is correct. It may not warn in all configurations, > > > > > > > > but that > > > > > > > > doesn't matter: what matters is that it warns in common enough > > > > > > > > configurations that developers will catch it. > > > > > > > > > > > > > > > > So having a warning in "might_sleep()" that doesn't always > > > > > > > > trigger, > > > > > > > > because you have a limited configuration that can't even detect > > > > > > > > the > > > > > > > > situation, that's fine and dandy and intentional. > > > > > > > > > > > > > > > > But having code like > > > > > > > > > > > > > > > >if (can_schedule()) > > > > > > > >.. do something different .. > > > > > > > > > > > > > > > > is fundamentally complete and utter garbage. > > > > > > > > > > > > > > > > It's one thing if you test for "am I in hardware interrupt > > > > > > > > context". > > > > > > > > Those tests aren't great either, but at least they make sense. > > > > > > > > > > > > > > > > But a driver - or some library routine - making a difference > > > > > > > > based on > > > > > > > > some nebulous "can I schedule" is fundamentally and basically > > > > > > > > WRONG. > > > > > > > > > > > > > > > > If some code changes behavior, it needs to be explicit to the > > > > > > > > *caller* > > > > > > > > of that code. > > > > > > > > > > > > > > > > So this is why GFP_ATOMIC is fine, but "if (!can_schedule()) > > > > > > > > do_something_atomic()" is pure shite. > > > > > > > > > > > > > > > > And I am not IN THE LEAST interested in trying to help people > > > > > > > > doing > > > > > > > > pure shite. We need to fix them. Like the crypto code is getting > > > > > > > > fixed. > > > > > > > > > > > > > > Just figured I'll throw my +1 in from reading too many (gpu) > > > > > > > drivers. > > > > > > > Code that tries to cleverly adjust its behaviour depending upon > > > > > > > the > > > > > > > context it's running in is harder to understand and blows up in > > > > > > > more > > > > > > > interesting ways. We still have drm_can_sleep() and it's mostly > > > > > > > just > > > > > > > used for debug code, and I've largely ended up just deleting > > > > > > > everything that used it because when you're driver is blowing up > > > > > > > the > > > > > > > last thing you want is to realize your debug code and output > > > > > > > can't be > > > > > > > relied upon. Or worse, that the only Oops you have is the one in > > > > > > > the > > > > > > > debug code, because the real one scrolled away - the original idea > > > > > > > behind drm_can_sleep was to make all the modeset code work > > > > > > > automagically both in normal ioctl/kworker context and in the > > > > > > > panic > > > > > > > handlers or kgdb callbacks. Wishful thinking at best. > > > > > > > > > > > > > > Also at least for me that extends to everything, e.g. I much > > > > > > > prefer > > > > > > > explicit spin_lock and spin_lock_irq vs magic spin_lock_irqsave > > > > > > > for > > > > > > > locks shared with interrupt handlers, since the former two gives > > > > > > > me > > > > > > > clear information from which contexts such function can be called. > > > > > > > Other end is the memalloc_no*_save/restore functions, where I > > > > > > > recently > > > > > > > made a real big fool of myself because I didn't realize how much > > > > > > > that > > > > > > > impacts everything that's run within - suddenly "GFP_KERNEL for > > > > > > > small > > > > > > > stuff never fails" is wrong everywhere. > > > > > > > > > > > > > > It's all great for debugging and sanity checks (and we run with > > > > > > > all > > > > > > > that stuff enabled in our CI), but really semantic changes > > > > > > > depending > > > > > > >
Re: [PATCH v2 00/18] drm/i915: Pimp DP DFP handling
On Tue, Sep 08, 2020 at 02:34:24PM -0400, Lyude Paul wrote: > With the nitpicks addressed (note there were a couple of other spots where we > wanted to use Return: in the kdocs, but I didn't bother pointing all of them > out), all but patch 07 is: > > Reviewed-by: Lyude Paul Thanks for the review. I fixed up the missing/bad docs and pushed the lot to drm-intel-next-queued (with Daniel's irc ack). PS. Had to s/drm_dp_downstream_max_clock/drm_dp_downstream_max_dotclock/ in nouveau_dp.c to keep it in a buildable shape. I hope I didn't step on too many toes with this... -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/dp: add a number of DP 2.0 DPCD definitions
Hi Jani, I love your patch! Perhaps something to improve: [auto build test WARNING on drm-intel/for-linux-next] [also build test WARNING on tegra-drm/drm/tegra/for-next drm-tip/drm-tip linus/master drm-exynos/exynos-drm-next v5.9-rc5 next-20200917] [cannot apply to drm/drm-next] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Jani-Nikula/drm-dp-add-subheadings-to-DPCD-address-definitions/20200917-185206 base: git://anongit.freedesktop.org/drm-intel for-linux-next config: nds32-randconfig-p001-20200917 (attached as .config) compiler: nds32le-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=nds32 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): In file included from drivers/gpu/drm/drm_crtc_helper_internal.h:31, from drivers/gpu/drm/drm_crtc_helper.c:51: >> include/drm/drm_dp_helper.h:640: warning: >> "DP_ADJUST_TX_FFE_PRESET_LANE0_MASK" redefined 640 | # define DP_ADJUST_TX_FFE_PRESET_LANE0_MASK (0xf << 4) | include/drm/drm_dp_helper.h:638: note: this is the location of the previous definition 638 | # define DP_ADJUST_TX_FFE_PRESET_LANE0_MASK (0xf << 0) | >> include/drm/drm_dp_helper.h:641: warning: >> "DP_ADJUST_TX_FFE_PRESET_LANE0_SHIFT" redefined 641 | # define DP_ADJUST_TX_FFE_PRESET_LANE0_SHIFT 4 | include/drm/drm_dp_helper.h:639: note: this is the location of the previous definition 639 | # define DP_ADJUST_TX_FFE_PRESET_LANE0_SHIFT 0 | -- In file included from include/drm/drm_dp_mst_helper.h:26, from drivers/gpu/drm/drm_dp_mst_topology.c:43: >> include/drm/drm_dp_helper.h:640: warning: >> "DP_ADJUST_TX_FFE_PRESET_LANE0_MASK" redefined 640 | # define DP_ADJUST_TX_FFE_PRESET_LANE0_MASK (0xf << 4) | include/drm/drm_dp_helper.h:638: note: this is the location of the previous definition 638 | # define DP_ADJUST_TX_FFE_PRESET_LANE0_MASK (0xf << 0) | >> include/drm/drm_dp_helper.h:641: warning: >> "DP_ADJUST_TX_FFE_PRESET_LANE0_SHIFT" redefined 641 | # define DP_ADJUST_TX_FFE_PRESET_LANE0_SHIFT 4 | include/drm/drm_dp_helper.h:639: note: this is the location of the previous definition 639 | # define DP_ADJUST_TX_FFE_PRESET_LANE0_SHIFT 0 | drivers/gpu/drm/drm_dp_mst_topology.c: In function 'drm_dp_send_query_stream_enc_status': drivers/gpu/drm/drm_dp_mst_topology.c:3261:6: warning: variable 'len' set but not used [-Wunused-but-set-variable] 3261 | int len, ret; | ^~~ -- In file included from drivers/gpu/drm/bridge/analogix/analogix_dp_core.h:13, from drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c:17: >> include/drm/drm_dp_helper.h:640: warning: >> "DP_ADJUST_TX_FFE_PRESET_LANE0_MASK" redefined 640 | # define DP_ADJUST_TX_FFE_PRESET_LANE0_MASK (0xf << 4) | include/drm/drm_dp_helper.h:638: note: this is the location of the previous definition 638 | # define DP_ADJUST_TX_FFE_PRESET_LANE0_MASK (0xf << 0) | >> include/drm/drm_dp_helper.h:641: warning: >> "DP_ADJUST_TX_FFE_PRESET_LANE0_SHIFT" redefined 641 | # define DP_ADJUST_TX_FFE_PRESET_LANE0_SHIFT 4 | include/drm/drm_dp_helper.h:639: note: this is the location of the previous definition 639 | # define DP_ADJUST_TX_FFE_PRESET_LANE0_SHIFT 0 | drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c:527:5: warning: no previous prototype for 'analogix_dp_start_aux_transaction' [-Wmissing-prototypes] 527 | int analogix_dp_start_aux_transaction(struct analogix_dp_device *dp) | ^ drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c:571:5: warning: no previous prototype for 'analogix_dp_write_byte_to_dpcd' [-Wmissing-prototypes] 571 | int analogix_dp_write_byte_to_dpcd(struct analogix_dp_device *dp, | ^~ # https://github.com/0day-ci/linux/commit/ee700fcadff2b9f1f941cd4af77242e51a139649 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Jani-Nikula/drm-dp-add-subheadings-to-DPCD-address-definitions/20200917-185206 git checkout ee700fcadff2b
Re: [Linaro-mm-sig] Changing vma->vm_file in dma_buf_mmap()
Am 17.09.20 um 17:37 schrieb Daniel Vetter: On Thu, Sep 17, 2020 at 5:24 PM Jason Gunthorpe wrote: On Thu, Sep 17, 2020 at 04:54:44PM +0200, Christian König wrote: Am 17.09.20 um 16:35 schrieb Jason Gunthorpe: On Thu, Sep 17, 2020 at 02:24:29PM +0200, Christian König wrote: Am 17.09.20 um 14:18 schrieb Jason Gunthorpe: On Thu, Sep 17, 2020 at 02:03:48PM +0200, Christian König wrote: Am 17.09.20 um 13:31 schrieb Jason Gunthorpe: On Thu, Sep 17, 2020 at 10:09:12AM +0200, Daniel Vetter wrote: Yeah, but it doesn't work when forwarding from the drm chardev to the dma-buf on the importer side, since you'd need a ton of different address spaces. And you still rely on the core code picking up your pgoff mangling, which feels about as risky to me as the vma file pointer wrangling - if it's not consistently applied the reverse map is toast and unmap_mapping_range doesn't work correctly for our needs. I would think the pgoff has to be translated at the same time the vm->vm_file is changed? The owner of the dma_buf should have one virtual address space and FD, all its dma bufs should be linked to it, and all pgoffs translated to that space. Yeah, that is exactly like amdgpu is doing it. Going to document that somehow when I'm done with TTM cleanups. BTW, while people are looking at this, is there a way to go from a VMA to a dma_buf that owns it? Only a driver specific one. Sounds OK For TTM drivers vma->vm_private_data points to the buffer object. Not sure about the drivers using GEM only. Why are drivers in control of the vma? I would think dma_buf should be the vma owner. IIRC module lifetime correctness essentially hings on the module owner of the struct file Because the page fault handling is completely driver specific. We could install some DMA-buf vmops, but that would just be another layer of redirection. Uh geez I didn't know amdgpu was doing that :-/ Since this is on, I guess the inverse of trying to convert a userptr into a dma-buf is properly rejected? My fault, I wasn't specific enough in my description :) Amdgpu is NOT doing this with mmaped DMA-bufs, but rather with it's own mmaped BOs. In other words when userspace call the userptr IOCTL and we get an error because we can't make an userptr from some random device memory we instead check all CPU mappings if the application was brain dead enough to provide us our own pointer back. IIRC this is even done in userspace and not the kernel. But we talked about doing it in the kernel with the private_data as well. If it is already taking a page fault I'm not sure the extra function call indirection is going to be a big deal. Having a uniform VMA sounds saner than every driver custom rolling something. When I unwound a similar mess in RDMA all the custom VMA stuff in the drivers turned out to be generally buggy, at least. Is vma->vm_file->private_data universally a dma_buf pointer at least? Nope. I think if you want this without some large scale rewrite of a lot of code we'd need a vmops->get_dmabuf or similar. Not pretty, but would get the job done. Yeah, agree that sounds like the simplest approach. Regards, Christian. So, user VA -> find_vma -> dma_buf object -> dma_buf operations on the memory it represents Ah, yes we are already doing this in amdgpu as well. But only for DMA-bufs or more generally buffers which are mmaped by this driver instance. So there is no general dma_buf service? That is a real bummer Mostly historical reasons and "it's complicated". One problem is that dma-buf isn't a powerful enough interface that drivers could use it for all their native objects, e.g. userptr doesn't pass through it, and clever cache flushing tricks aren't allowed and a bunch of other things. So there's some serious roadblocks before we could have a common allocator (or set of allocators) behind dma-buf. -Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/i915: Fix the race between the GEM close and debugfs
Hi
[This is an automated email]
This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: all
The bot has tested the following trees: v5.8.9, v5.4.65, v4.19.145, v4.14.198,
v4.9.236, v4.4.236.
v5.8.9: Build OK!
v5.4.65: Failed to apply! Possible dependencies:
061489c65ff5 ("drm/i915/dsb: single register write function for DSB.")
11988e393813 ("drm/i915/execlists: Try rearranging breadcrumb flush")
2850748ef876 ("drm/i915: Pull i915_vma_pin under the vm->mutex")
5a90606df7cb ("drm/i915: Replace obj->pin_global with obj->frontbuffer")
67f3b58f3bac ("drm/i915/dsb: DSB context creation.")
8a9a982767b7 ("drm/i915: use a separate context for gpu relocs")
a4e7ccdac38e ("drm/i915: Move context management under GEM")
b27a96ad72fd ("drm/i915/dsb: Indexed register write function for DSB.")
bb120e1171a9 ("drm/i915: Show the logical context ring state on dumping")
c210e85b8f33 ("drm/i915/tgl: Extend MI_SEMAPHORE_WAIT")
d19d71fc2b15 ("drm/i915: Mark i915_request.timeline as a volatile, rcu
pointer")
e8f6b4952ec5 ("drm/i915/execlists: Flush the post-sync breadcrumb write
harder")
v4.19.145: Failed to apply! Possible dependencies:
0258404f9d38 ("drm/i915: start moving runtime device info to a separate
struct")
026844460743 ("drm/i915: Remove intel_context.active_link")
07d805721938 ("drm/i915: Introduce intel_runtime_pm_disable to pair
intel_runtime_pm_enable")
13f1bfd3b332 ("drm/i915: Make object/vma allocation caches global")
1c71bc565cdb ("drm/i915/perf: simplify configure all context function")
2cc8376fd350 ("drm/i915: rename dev_priv info to __info to avoid usage")
2cd9a689e97b ("drm/i915: Refactor intel_display_set_init_power() logic")
37d7c9cc2eb6 ("drm/i915: Check engine->default_state mapping on module
load")
55ac5a1614f9 ("drm/i915: Attach the pci match data to the device upon
creation")
666424abfb86 ("drm/i915/execlists: Use coherent writes into the context
image")
6dfc4a8f134f ("drm/i915: Verify power domains after enabling them")
722f3de39e03 ("i915/oa: Simplify updating contexts")
900ccf30f9e1 ("drm/i915: Only force GGTT coherency w/a on required
chipsets")
c4d52feb2c46 ("drm/i915: Move over to intel_context_lookup()")
f6e8aa387171 ("drm/i915: Report the number of closed vma held by each
context in debugfs")
fa9f668141f4 ("drm/i915: Export intel_context_instance()")
v4.14.198: Failed to apply! Possible dependencies:
3bd4073524fa ("drm/i915: Consolidate get_fence with pin_fence")
465c403cb508 ("drm/i915: introduce simple gemfs")
66df1014efba ("drm/i915: Keep a small stash of preallocated WC pages")
67b48040255b ("drm/i915: Assert that the handle->vma lut is empty on object
close")
73ebd503034c ("drm/i915: make mappable struct resource centric")
7789422665f5 ("drm/i915: make dsm struct resource centric")
82ad6443a55e ("drm/i915/gtt: Rename i915_hw_ppgtt base member")
969b0950a188 ("drm/i915: Add interface to reserve fence registers for vGPU")
a65adaf8a834 ("drm/i915: Track user GTT faulting per-vma")
b4563f595ed4 ("drm/i915: Pin fence for iomap")
e91ef99b9543 ("drm/i915/selftests: Remember to create the fake preempt
context")
f6e8aa387171 ("drm/i915: Report the number of closed vma held by each
context in debugfs")
f773568b6ff8 ("drm/i915: nuke the duplicated stolen discovery")
v4.9.236: Failed to apply! Possible dependencies:
0e70447605f4 ("drm/i915: Move common code out of i915_gpu_error.c")
1b36595ffb35 ("drm/i915: Show RING registers through debugfs")
28a60dee2ce6 ("drm/i915/gvt: vGPU HW resource management")
3b3f1650b1ca ("drm/i915: Allocate intel_engine_cs structure only for the
enabled engines")
82ad6443a55e ("drm/i915/gtt: Rename i915_hw_ppgtt base member")
85fd4f58d7ef ("drm/i915: Mark all non-vma being inserted into the address
spaces")
9c870d03674f ("drm/i915: Use RPM as the barrier for controlling user mmap
access")
bb6dc8d96b68 ("drm/i915: Implement pread without struct-mutex")
d636951ec01b ("drm/i915: Cleanup instdone collection")
e007b19d7ba7 ("drm/i915: Use the MRU stack search after evicting")
f6e8aa387171 ("drm/i915: Report the number of closed vma held by each
context in debugfs")
f9e613728090 ("drm/i915: Try to print INSTDONE bits for all slice/subslice")
v4.4.236: Failed to apply! Possible dependencies:
1b683729e7ac ("drm/i915: Remove redundant check in i915_gem_obj_to_vma")
1c7f4bca5a6f ("drm/i915: Rename vma->*_list to *_link for consistency")
3272db53136f ("drm/i915: Combine all i915_vma bitfields into a single set
of flags")
596c5923197b ("drm/i915: Reduce the pointer dance of i915_is_ggtt()")
c1a415e261aa ("drm/i915: Disable shrinker for non-swapped backed objects")
d0710abbcd88 ("drm/i915: Set the map-and-fenceable flag for preallocated
objects")
Re: [Linaro-mm-sig] Changing vma->vm_file in dma_buf_mmap()
On Thu, Sep 17, 2020 at 5:24 PM Jason Gunthorpe wrote: > > On Thu, Sep 17, 2020 at 04:54:44PM +0200, Christian König wrote: > > Am 17.09.20 um 16:35 schrieb Jason Gunthorpe: > > > On Thu, Sep 17, 2020 at 02:24:29PM +0200, Christian König wrote: > > > > Am 17.09.20 um 14:18 schrieb Jason Gunthorpe: > > > > > On Thu, Sep 17, 2020 at 02:03:48PM +0200, Christian König wrote: > > > > > > Am 17.09.20 um 13:31 schrieb Jason Gunthorpe: > > > > > > > On Thu, Sep 17, 2020 at 10:09:12AM +0200, Daniel Vetter wrote: > > > > > > > > > > > > > > > Yeah, but it doesn't work when forwarding from the drm chardev > > > > > > > > to the > > > > > > > > dma-buf on the importer side, since you'd need a ton of > > > > > > > > different > > > > > > > > address spaces. And you still rely on the core code picking up > > > > > > > > your > > > > > > > > pgoff mangling, which feels about as risky to me as the vma file > > > > > > > > pointer wrangling - if it's not consistently applied the > > > > > > > > reverse map > > > > > > > > is toast and unmap_mapping_range doesn't work correctly for our > > > > > > > > needs. > > > > > > > I would think the pgoff has to be translated at the same time the > > > > > > > vm->vm_file is changed? > > > > > > > > > > > > > > The owner of the dma_buf should have one virtual address space > > > > > > > and FD, > > > > > > > all its dma bufs should be linked to it, and all pgoffs > > > > > > > translated to > > > > > > > that space. > > > > > > Yeah, that is exactly like amdgpu is doing it. > > > > > > > > > > > > Going to document that somehow when I'm done with TTM cleanups. > > > > > BTW, while people are looking at this, is there a way to go from a VMA > > > > > to a dma_buf that owns it? > > > > Only a driver specific one. > > > Sounds OK > > > > > > > For TTM drivers vma->vm_private_data points to the buffer object. Not > > > > sure > > > > about the drivers using GEM only. > > > Why are drivers in control of the vma? I would think dma_buf should be > > > the vma owner. IIRC module lifetime correctness essentially hings on > > > the module owner of the struct file > > > > Because the page fault handling is completely driver specific. > > > > We could install some DMA-buf vmops, but that would just be another layer of > > redirection. Uh geez I didn't know amdgpu was doing that :-/ Since this is on, I guess the inverse of trying to convert a userptr into a dma-buf is properly rejected? > If it is already taking a page fault I'm not sure the extra function > call indirection is going to be a big deal. Having a uniform VMA > sounds saner than every driver custom rolling something. > > When I unwound a similar mess in RDMA all the custom VMA stuff in the > drivers turned out to be generally buggy, at least. > > Is vma->vm_file->private_data universally a dma_buf pointer at least? Nope. I think if you want this without some large scale rewrite of a lot of code we'd need a vmops->get_dmabuf or similar. Not pretty, but would get the job done. > > > So, user VA -> find_vma -> dma_buf object -> dma_buf operations on the > > > memory it represents > > > > Ah, yes we are already doing this in amdgpu as well. But only for DMA-bufs > > or more generally buffers which are mmaped by this driver instance. > > So there is no general dma_buf service? That is a real bummer Mostly historical reasons and "it's complicated". One problem is that dma-buf isn't a powerful enough interface that drivers could use it for all their native objects, e.g. userptr doesn't pass through it, and clever cache flushing tricks aren't allowed and a bunch of other things. So there's some serious roadblocks before we could have a common allocator (or set of allocators) behind dma-buf. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1] powerplay:hwmgr - modify the return value
On Thu, Sep 17, 2020 at 4:28 AM Christian König
wrote:
>
> Am 17.09.20 um 05:46 schrieb Xiaoliang Pang:
> > modify the return value is -EINVAL
>
> Maybe better write something like "The correct return value should be
> -EINVAL." With that done feel free to add my acked-by.
Applied with updated commit message.
Thanks!
Alex
>
> Christian.
>
> >
> > Fixes: f83a9991648bb("drm/amd/powerplay: add Vega10 powerplay support (v5)")
> > Fixes: 2cac05dee6e30("drm/amd/powerplay: add the hw manager for vega12
> > (v4)")
> > Cc: Eric Huang
> > Cc: Evan Quan
> > Signed-off-by: Xiaoliang Pang
> > ---
> > drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 2 +-
> > drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c | 2 +-
> > 2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
> > b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
> > index c378a000c934..7eada3098ffc 100644
> > --- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
> > +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
> > @@ -4659,7 +4659,7 @@ static int
> > vega10_display_configuration_changed_task(struct pp_hwmgr *hwmgr)
> > if ((data->water_marks_bitmap & WaterMarksExist) &&
> > !(data->water_marks_bitmap & WaterMarksLoaded)) {
> > result = smum_smc_table_manager(hwmgr, (uint8_t *)wm_table,
> > WMTABLE, false);
> > - PP_ASSERT_WITH_CODE(result, "Failed to update WMTABLE!",
> > return EINVAL);
> > + PP_ASSERT_WITH_CODE(result, "Failed to update WMTABLE!",
> > return -EINVAL);
> > data->water_marks_bitmap |= WaterMarksLoaded;
> > }
> >
> > diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c
> > b/drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c
> > index a678a67f1c0d..04da52cea824 100644
> > --- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c
> > +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c
> > @@ -2390,7 +2390,7 @@ static int
> > vega12_display_configuration_changed_task(struct pp_hwmgr *hwmgr)
> > !(data->water_marks_bitmap & WaterMarksLoaded)) {
> > result = smum_smc_table_manager(hwmgr,
> > (uint8_t *)wm_table,
> > TABLE_WATERMARKS, false);
> > - PP_ASSERT_WITH_CODE(result, "Failed to update WMTABLE!",
> > return EINVAL);
> > + PP_ASSERT_WITH_CODE(result, "Failed to update WMTABLE!",
> > return -EINVAL);
> > data->water_marks_bitmap |= WaterMarksLoaded;
> > }
> >
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/8] drm/vram-helper: don't use ttm bo->offset v4
Hi
Am 17.09.20 um 14:32 schrieb Christian König:
> Am 17.09.20 um 14:29 schrieb Thomas Zimmermann:
>> Hi Christian
>>
>> Am 17.09.20 um 13:12 schrieb Christian König:
>>> Hi Thomas,
>>>
>>> Am 17.09.20 um 12:51 schrieb Thomas Zimmermann:
Hi
Am 24.06.20 um 20:26 schrieb Nirmoy Das:
> Calculate GEM VRAM bo's offset within vram-helper without depending on
> bo->offset.
>
> Signed-off-by: Nirmoy Das
> Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_gem_vram_helper.c | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
> b/drivers/gpu/drm/drm_gem_vram_helper.c
> index 0023ce1d2cf7..ad096600d89f 100644
> --- a/drivers/gpu/drm/drm_gem_vram_helper.c
> +++ b/drivers/gpu/drm/drm_gem_vram_helper.c
> @@ -281,6 +281,15 @@ u64 drm_gem_vram_mmap_offset(struct
> drm_gem_vram_object *gbo)
> }
> EXPORT_SYMBOL(drm_gem_vram_mmap_offset);
> +static u64 drm_gem_vram_pg_offset(struct drm_gem_vram_object *gbo)
> +{
> + /* Keep TTM behavior for now, remove when drivers are audited */
> + if (WARN_ON_ONCE(!gbo->bo.mem.mm_node))
At this line I got
>>> Sounds like ast forgot to pin the cursor to VRAM.
>>>
>>> If you look at ast_cursor_page_flip(), you see:
off = drm_gem_vram_offset(gbo);
if (drm_WARN_ON_ONCE(dev, off < 0))
return; /* Bug: we didn't pin the cursor HW BO to
VRAM. */
>>> The drm_WARN_ON_ONCE() just never triggered before because it checks for
>>> the wrong condition (off < 0).
>> GEM VRAM BOs have a pin counter. drm_gem_vram_offset() returns -ENODEV
>> if the BO's pin count is 0 (i.e., the BO has not been pinned anywhere).
>> That's what we're testing here. Two cursor BOs are permanently pinned to
>> the top of VRAM memory by ast_cursor_init(). If perma-pinning in
>> ast_cursor_init() fails, driver initialization should fail entirely.
>>
>> These cursor BOs do some sort of double buffering, On successful
>> initialization, the actual cursor image is later blit-ed into one of the
>> BOs.
>>
>> All this used to work from what I can tell. Is there any chance that the
>> recent TTM refactoring broke this?
>
> Yeah, certainly possible. If you have time please bisect.
FYI the bug is not in c44264f9f729 ("Merge tag 'v5.8' into drm-next")
from Aug 11. I'll try to bisect.
Best regards
Thomas
>
> Thanks,
> Christian.
>
>>
>> Best regards
>> Thomas
>>
>>> Regards,
>>> Christian.
>>>
[ 146.133821] [ cut here ]
[ 146.133872] WARNING: CPU: 6 PID: 7 at
drivers/gpu/drm/drm_gem_vram_helper.c:284 drm_gem_vram_offset+0x59/0x60
[drm_vram_helper]
[ 146.133880] Modules linked in: fuse(E) af_packet(E)
ebtable_filter(E)
ebtables(E) ip6table_filter(E) ip6_tables(E) iptable_filter(E)
ip_tables(E) x_tables(E) bpfilter(E) rfkill(E) dmi_sysfs(E) msr(E)
intel_powerclamp(E) coretemp(E) kv)
[ 146.134051] scsi_dh_emc(E) scsi_dh_alua(E)
[ 146.134074] CPU: 6 PID: 7 Comm: kworker/u48:0 Tainted:
G E
5.9.0-rc4-1-default+ #492
[ 146.134083] Hardware name: Sun Microsystems SUN FIRE X2270 M2/SUN
FIRE X2270 M2, BIOS 2.05 07/01/2010
[ 146.134099] Workqueue: events_unbound commit_work
[ 146.134116] RIP: 0010:drm_gem_vram_offset+0x59/0x60
[drm_vram_helper]
[ 146.134128] Code: 02 00 00 00 74 24 48 8d bb 80 02 00 00 e8 ef 27 17
d7 48 8b 83 80 02 00 00 5b 48 c1 e0 0c c3 0f 0b 48 c7 c0 ed ff ff ff 5b
c3 <0f> 0b 31 c0 5b c3 90 66 66 66 66 90 41 56 41 55 49 89 d5 41 54 49
[ 146.134137] RSP: 0018:c9107c38 EFLAGS: 00010246
[ 146.134149] RAX: RBX: 88855000 RCX:
c032323b
[ 146.134158] RDX: dc00 RSI: 88810e236300 RDI:
88855278
[ 146.134168] RBP: 88810909 R08: c0323225 R09:
0002
[ 146.134177] R10: ed1020675020 R11: 0001 R12:
888109091050
[ 146.134187] R13: 88810e236300 R14: 88810909 R15:
[ 146.134197] FS: () GS:88811600()
knlGS:
[ 146.134206] CS: 0010 DS: ES: CR0: 80050033
[ 146.134215] CR2: 7f60547d9100 CR3: 29216002 CR4:
000206e0
[ 146.134223] Call Trace:
[ 146.134245] ast_cursor_page_flip+0x3e/0x150 [ast]
[ 146.134272] ast_cursor_plane_helper_atomic_update+0x8a/0xc0 [ast]
[ 146.134300] drm_atomic_helper_commit_planes+0x197/0x4c0
[ 146.134341] drm_atomic_helper_commit_tail_rpm+0x51/0x90
[ 146.134357] commit_tail+0x103/0x1c0
[ 146.134390] process_one_work+0x56a/0xa60
[ 146.134431] ? __lock_acquired+0x1ca/0x3d0
[ 146.134447] ? pwq_dec_nr_in_flight+0x110/0x110
[ 146.134460] ?
Re: [Linaro-mm-sig] Changing vma->vm_file in dma_buf_mmap()
Am 17.09.20 um 16:35 schrieb Jason Gunthorpe: On Thu, Sep 17, 2020 at 02:24:29PM +0200, Christian König wrote: Am 17.09.20 um 14:18 schrieb Jason Gunthorpe: On Thu, Sep 17, 2020 at 02:03:48PM +0200, Christian König wrote: Am 17.09.20 um 13:31 schrieb Jason Gunthorpe: On Thu, Sep 17, 2020 at 10:09:12AM +0200, Daniel Vetter wrote: Yeah, but it doesn't work when forwarding from the drm chardev to the dma-buf on the importer side, since you'd need a ton of different address spaces. And you still rely on the core code picking up your pgoff mangling, which feels about as risky to me as the vma file pointer wrangling - if it's not consistently applied the reverse map is toast and unmap_mapping_range doesn't work correctly for our needs. I would think the pgoff has to be translated at the same time the vm->vm_file is changed? The owner of the dma_buf should have one virtual address space and FD, all its dma bufs should be linked to it, and all pgoffs translated to that space. Yeah, that is exactly like amdgpu is doing it. Going to document that somehow when I'm done with TTM cleanups. BTW, while people are looking at this, is there a way to go from a VMA to a dma_buf that owns it? Only a driver specific one. Sounds OK For TTM drivers vma->vm_private_data points to the buffer object. Not sure about the drivers using GEM only. Why are drivers in control of the vma? I would think dma_buf should be the vma owner. IIRC module lifetime correctness essentially hings on the module owner of the struct file Because the page fault handling is completely driver specific. We could install some DMA-buf vmops, but that would just be another layer of redirection. Why are you asking? I'm thinking about using find_vma on something that is not get_user_pages()'able to go to the underlying object, in this case dma buf. So, user VA -> find_vma -> dma_buf object -> dma_buf operations on the memory it represents Ah, yes we are already doing this in amdgpu as well. But only for DMA-bufs or more generally buffers which are mmaped by this driver instance. Some applications are braindead enough to mmap() a buffer and then give us back the CPU pointer and request to make it a handle (userptr) again. That is clearly forbidden by OpenGL, OpenCL and Vulkan, but they use it anyway. Christian. Jason ___ Linaro-mm-sig mailing list linaro-mm-...@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-mm-sig ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Why can't ttm_tt_swapout() handle uncached or WC BOs?
Am 17.09.20 um 16:44 schrieb Michel Dänzer: On 2020-09-17 2:20 p.m., Christian König wrote: Hi guys, Michel once submitted a patch to fix triggering this BUG_ON in ttm_tt_swapout(): BUG_ON(ttm->caching_state != tt_cached); Now my question is does anybody know why we have that in the first place? The only problematic thing I can see is calling copy_highpage() and that one is just doing a kmap_atomic()/kunmap_atomic() on the source and destination. I can't see why it should be problematic for this temporary mapping to be cached instead of uncached or WC? Does anybody has any idea? One thing is that AFAIK some (ARM?) CPUs can get very upset when there's both a cached and uncacheable mapping for the same physical page. Good point, but I already considered this. If there is another mapping for that page left we are completely busted anyway since we are currently changing the underlying storage. In other words nobody else should have a mapping because we are about to copy and then free up the memory. Any other idea? It is the only place where we actually have to change the caching attributes. Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Why can't ttm_tt_swapout() handle uncached or WC BOs?
On 2020-09-17 2:20 p.m., Christian König wrote: Hi guys, Michel once submitted a patch to fix triggering this BUG_ON in ttm_tt_swapout(): BUG_ON(ttm->caching_state != tt_cached); Now my question is does anybody know why we have that in the first place? The only problematic thing I can see is calling copy_highpage() and that one is just doing a kmap_atomic()/kunmap_atomic() on the source and destination. I can't see why it should be problematic for this temporary mapping to be cached instead of uncached or WC? Does anybody has any idea? One thing is that AFAIK some (ARM?) CPUs can get very upset when there's both a cached and uncacheable mapping for the same physical page. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
