date:20211114

Backlight control broken on UM325 (OLED) on 5.15 (bisected)

2021-11-14 Thread Samuel Čavoj

Hello,

the backlight control no longer works on my ASUS UM325 (Ryzen 5700U)
OLED laptop. I have bisected the breakage to commit 7fd13baeb7a3a48.

commit 7fd13baeb7a3a48cae12c36c52f06bf4e9e7d728 (HEAD, refs/bisect/bad)
Author: Alex Deucher 
Date:   Thu Jul 8 16:31:10 2021 -0400
 
drm/amdgpu/display: add support for multiple backlights

On platforms that support multiple backlights, register
each one separately.  This lets us manage them independently
rather than registering a single backlight and applying the
same settings to both.

v2: fix typo:
Reported-by: kernel test robot 

Reviewed-by: Roman Li 
Signed-off-by: Alex Deucher 

I have encountered another user with the same issue on reddit[0].

The node in /sys/class/backlight exists, writing to it just does
nothing. I would be glad to help debugging the issue. Thank you very
much.

Regards,
Samuel Čavoj

[0]: 
https://www.reddit.com/r/AMDLaptops/comments/qst0fm/after_updating_to_linux_515_my_brightness/

Panic with linus/master and panfrost

2021-11-14 Thread Ondřej Jirman

Hello,

I'm getting some fence refcounting related panics with the current
Linus's master branch:

It happens immediately whenever I start Xorg or sway.

Anyone has any ideas where to start looking? It works fine with v5.15.

(sorry for the interleaved log, it's coming from multiple CPUs at once
I guess)

kind regards,
o.

[ cut here ]
refcount_t: underflow; use-after-free.
WARNING: CPU: 4 PID: 560 at lib/refcount.c:28 refcount_warn_saturate+0xec/0x140
Modules linked in:
CPU: 4 PID: 560 Comm: sway Not tainted 5.15.0-13547-g5169ae41ace0 #24
Hardware name: Pine64 PinePhonePro (DT)
pstate: 4005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : refcount_warn_saturate+0xec/0x140
lr : refcount_warn_saturate+0xec/0x140
sp : 8000127b3be0
x29: 8000127b3be0 x28: 8000127b3d50 x27: 1927e700
x26:  x25: 0001 x24: 0004
x23: 1e31da80 x22: 05497580 x21: 1e31da90
x20: 1e31da80 x19: 1e31da90 x18: 0003
x17:  x16:  x15: 8000127b3b68
x14:  x13: 2e656572662d7265 x12: 7466612d65737520
x11: 3b776f6c66726564 x10: 800011d7e8a0 x9 : 800010178a1c
x8 : efff x7 : 800011dd68a0 x6 : 0001
x5 : f778e788 x4 :  x3 : 0027
x2 : 0023 x1 : f778e790 x0 : 0026
Call trace:
 refcount_warn_saturate+0xec/0x140
 drm_syncobj_replace_fence+0x16c/0x17c
 panfrost_ioctl_submit+0x364/0x440
 drm_ioctl_kernel+0x9c/0x154
 drm_ioctl+0x1f0/0x410
 __arm64_sys_ioctl+0xb4/0xdc
 invoke_syscall+0x4c/0x110
 el0_svc_common.constprop.0+0x48/0xf0
 do_el0_svc+0x2c/0x90
 el0_svc+0x14/0x50
 el0t_64_sync_handler+0x9c/0x120
 el0t_64_sync+0x158/0x15c
---[ end trace 51cdc14807ba9222 ]---
[ cut here ]
Unable to handle kernel write to read-only memory at virtual address 
800010820b10
refcount_t: saturated; leaking memory.
Mem abort info:
WARNING: CPU: 1 PID: 223 at lib/refcount.c:22 refcount_warn_saturate+0x6c/0x140
  ESR = 0x964e
Modules linked in:
  EC = 0x25: DABT (current EL), IL = 32 bits

CPU: 1 PID: 223 Comm: pan_js Tainted: GW 
5.15.0-13547-g5169ae41ace0 #24
  SET = 0, FnV = 0
Hardware name: Pine64 PinePhonePro (DT)
  EA = 0, S1PTW = 0
pstate: 4005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
  FSC = 0x0e: level 2 permission fault
pc : refcount_warn_saturate+0x6c/0x140
Data abort info:
lr : refcount_warn_saturate+0x6c/0x140
  ISV = 0, ISS = 0x004e
sp : 800012a2bd90
  CM = 0, WnR = 1
x29: 800012a2bd90
swapper pgtable: 4k pages, 48-bit VAs, pgdp=019ba000
 x28: 
[800010820b10] pgd=1000f7fff003
 x27: 
, p4d=1000f7fff003

, pud=1000f7ffe003
x26: 
, pmd=004000a00781
 x25: 800011906000

 x24: 13ee7a20
Internal error: Oops: 964e [#1] SMP

Modules linked in:
x23: 8000108211e0

 x22: 800011906000
CPU: 2 PID: 222 Comm: pan_js Tainted: GW 
5.15.0-13547-g5169ae41ace0 #24
 x21: 251ef000
Hardware name: Pine64 PinePhonePro (DT)

pstate: 00c5 (nzcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
x20: 05497580
pc : dma_fence_add_callback+0xc8/0x120
 x19: 1532b4c0
lr : dma_fence_add_callback+0x78/0x120
 x18: 
sp : 800012a23d60

x29: 800012a23d60
x17: 00040044
 x28: 
 x16: 0032b5503510
 x27: 
 x15: 


x26: 
x14: 0550c380
 x25: 800011906000
 x13: 2e79726f6d656d20
 x24: 
 x12: 676e696b61656c20


x23: 
x11: 3b64657461727574
 x22: 8000108211e0
 x10: 6173203a745f746e
 x21: 054975d0
 x9 : 80001022e51c


x20: 1532b468
x8 : 0001
 x19: 05497580
 x7 : 0e08
 x18: 
 x6 : 0001


x17: 00040044
x5 : 
 x16: 0032b5503510
 x4 : f773a788
 x15: 
 x3 : f77466f0


x14: 0550d100
x2 : f773a788
 x13: 8000e5e4e000
 x1 : 8000e5e32000
 x12: 34d4d91d
 x0 : 0026


x11: 
Call trace:
 x10: 0002
 refcount_warn_saturate+0x6c/0x140
 x9 : 800010899578
 drm_sched_entity_pop_job+0x418/0x490
 
 drm_sched_main+0xb0/0x41c
x8 : 148dcd60
 kthread+0x14c/0x160
 x7 : 
 ret_from_fork+0x10/0x20
 x6 : 010a4760
---[ end trace 51cdc14807ba9223 ]---

x5 : 13ee79f8 x4 : 0001 x3 : 054975b0
x2 :  x1 : 800010820b10 x0 : 05497590
Call trace:
 dma_fence_add_callback+0xc8/0x120
 drm_sched_entity_pop_job+0xa4/0x490
 drm_sched_main+0xb0/0x41c
 kthread+0x14c/0x160
 ret_from_fork+0x10/0x20
Code: 91004260 f9400e61 f9000e74 a9000680 (f934)
---[ end trace 51cdc14807ba9224 ]---
Kernel panic - not syncing: Oops:

Re: [PATCH] drm/amd/amdgpu: remove useless break after return

2021-11-14 Thread Joe Perches

On Sun, 2021-11-14 at 23:14 -0800, Bernard Zhao wrote:
> This change is to remove useless break after return.
[]
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c 
> b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
[]
> @@ -2092,22 +2092,18 @@ static int dce_v8_0_pick_dig_encoder(struct 
> drm_encoder *encoder)
>   return 1;
>   else
>   return 0;
> - break;
>   case ENCODER_OBJECT_ID_INTERNAL_UNIPHY1:
>   if (dig->linkb)
>   return 3;
>   else
>   return 2;
> - break;
>   case ENCODER_OBJECT_ID_INTERNAL_UNIPHY2:
>   if (dig->linkb)
>   return 5;
>   else
>   return 4;
> - break;
>   case ENCODER_OBJECT_ID_INTERNAL_UNIPHY3:
>   return 6;
> - break;
>   default:
>   DRM_ERROR("invalid encoder_id: 0x%x\n", 
> amdgpu_encoder->encoder_id);
>   return 0;

Perhaps rewrite to make the sequential numbering more obvious.
---
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 19 +++
 1 file changed, 3 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
index b200b9e722d97..7307524b706b4 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
@@ -2088,26 +2088,13 @@ static int dce_v8_0_pick_dig_encoder(struct drm_encoder 
*encoder)
 
switch (amdgpu_encoder->encoder_id) {
case ENCODER_OBJECT_ID_INTERNAL_UNIPHY:
-   if (dig->linkb)
-   return 1;
-   else
-   return 0;
-   break;
+   return !dig->linkb ? 0 : 1;
case ENCODER_OBJECT_ID_INTERNAL_UNIPHY1:
-   if (dig->linkb)
-   return 3;
-   else
-   return 2;
-   break;
+   return !dig->linkb ? 2 : 3;
case ENCODER_OBJECT_ID_INTERNAL_UNIPHY2:
-   if (dig->linkb)
-   return 5;
-   else
-   return 4;
-   break;
+   return !dig->linkb ? 4 : 5;
case ENCODER_OBJECT_ID_INTERNAL_UNIPHY3:
return 6;
-   break;
default:
DRM_ERROR("invalid encoder_id: 0x%x\n", 
amdgpu_encoder->encoder_id);
return 0;

Re: Questions about KMS flip

2021-11-14 Thread Christian König

Am 12.11.21 um 17:10 schrieb Michel Dänzer:

On 2021-11-12 16:03, Christian König wrote:

Am 12.11.21 um 15:30 schrieb Michel Dänzer:

On 2021-11-12 15:29, Michel Dänzer wrote:

On 2021-11-12 13:47, Christian König wrote:

Anyway this unfortunately turned out to be work for Harray and Nicholas. In detail it's
about this bug report here:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.kernel.org%2Fshow_bug.cgi%3Fid%3D214621data=04%7C01%7Cchristian.koenig%40amd.com%7Cca557eab16864ab544a108d9a5f6f288%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637723302340621335%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=pvLGq%2FJRvVy0k5GMGF2UPotCSdbiQNfndtjI14luAUg%3Dreserved=0

Lang was able to reproduce the issue and narrow it down to the pin in
amdgpu_display_crtc_page_flip_target().

In other words we somehow have an unbalanced pinning of the scanout buffer in
DC.

DC doesn't use amdgpu_display_crtc_page_flip_target AFAICT. The corresponding
pin with DC would be in dm_plane_helper_prepare_fb, paired with the unpin in
dm_plane_helper_cleanup_fb.

With non-DC, the pin in amdgpu_display_crtc_page_flip_target is paired with the
unpin in dm_plane_helper_cleanup_fb

This should say amdgpu_display_unpin_work_func.

Ah! So that is the classic (e.g. non atomic) path?

Presumably.

& dce_v*_crtc_disable. One thing I notice is that the pin is guarded by if
(!adev->enable_virtual_display), but the unpins seem unconditional. So could this
be about virtual display, and the problem is actually trying to unpin a BO that was
never pinned?

Nope, my educated guess is rather that we free up the BO before
amdgpu_display_unpin_work_func is called.

E.g. not pin unbalance, but rather use after free.

amdgpu_display_crtc_page_flip_target calls amdgpu_bo_ref(work->old_abo), and
amdgpu_display_unpin_work_func calls amdgpu_bo_unref(>old_abo) only after
amdgpu_bo_unpin. So what you describe could only happen if there's an imbalance elsewhere such that
amdgpu_bo_unref is called more often than amdgpu_bo_ref, or maybe if amdgpu_bo_reserve fails in
amdgpu_display_unpin_work_func (in which case the "failed to reserve buffer after flip"
error message should appear in dmesg).

Yeah, seen that in the meantime as well.

But we also have a WARN_ON() when the pincount overruns, so that can't
be it either.

Long story short I have no idea what's going on here.

Regards,
Christian.

[PATCH] drm/exynos: remove useless type conversion

2021-11-14 Thread Bernard Zhao

This change is to cleanup the code a bit.

Signed-off-by: Bernard Zhao 
---
 drivers/gpu/drm/exynos/exynos_drm_fimc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index ecfd82d0afb7..023f54ee61a8 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -782,8 +782,8 @@ static int fimc_set_prescaler(struct fimc_context *ctx, 
struct fimc_scaler *sc,
 
sc->hratio = (src_w << 14) / (dst_w << hfactor);
sc->vratio = (src_h << 14) / (dst_h << vfactor);
-   sc->up_h = (dst_w >= src_w) ? true : false;
-   sc->up_v = (dst_h >= src_h) ? true : false;
+   sc->up_h = (dst_w >= src_w);
+   sc->up_v = (dst_h >= src_h);
DRM_DEV_DEBUG_KMS(ctx->dev, "hratio[%d]vratio[%d]up_h[%d]up_v[%d]\n",
  sc->hratio, sc->vratio, sc->up_h, sc->up_v);
 
-- 
2.33.1

Re: [git pull] drm fixes + one missed next for 5.16-rc1

2021-11-14 Thread Thomas Hellström




On 11/14/21 22:19, Linus Torvalds wrote:

On Sun, Nov 14, 2021 at 1:00 PM Dave Airlie  wrote:

i915 will no longer be x86-64 only in theory, since Intel now produces
PCIe graphics cards using the same hw designs.

Well, at least in my tree, it still has the "depends on X86", along
with several other x86-only things (like "select INTEL_GTT", which is
also x86-only)

So by the time that non-x86 theory becomes reality, hopefully the i915
people will also have figured out how to do the cache flushing
properly.

And hopefully that "do it properly" ends up being simply that the
particular configuration that ends up being portable simply doesn't
need to do it at all and can statically just not build it,
sidestepping the issue entirely.

Fingers crossed.


For non-x86 / discrete graphics, plan is only coherent mappings, 
although the "Just not build it" part hasn't been properly figured out 
yet I guess. But point taken.


Thanks,

/Thomas

[PATCH] drm/amd/amdgpu: remove useless break after return

2021-11-14 Thread Bernard Zhao

This change is to remove useless break after return.

Signed-off-by: Bernard Zhao 
---
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
index b200b9e722d9..8318ee8339f1 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
@@ -2092,22 +2092,18 @@ static int dce_v8_0_pick_dig_encoder(struct drm_encoder 
*encoder)
return 1;
else
return 0;
-   break;
case ENCODER_OBJECT_ID_INTERNAL_UNIPHY1:
if (dig->linkb)
return 3;
else
return 2;
-   break;
case ENCODER_OBJECT_ID_INTERNAL_UNIPHY2:
if (dig->linkb)
return 5;
else
return 4;
-   break;
case ENCODER_OBJECT_ID_INTERNAL_UNIPHY3:
return 6;
-   break;
default:
DRM_ERROR("invalid encoder_id: 0x%x\n", 
amdgpu_encoder->encoder_id);
return 0;
-- 
2.33.1

[PATCH] drm/amd/amdgpu: cleanup the code style a bit

2021-11-14 Thread Bernard Zhao

This change is to cleanup the code style a bit.

Signed-off-by: Bernard Zhao 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
index 04cf9b207e62..90070b41136a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
@@ -286,12 +286,14 @@ static int amdgpu_virt_init_ras_err_handler_data(struct 
amdgpu_device *adev)
return -ENOMEM;
 
bps = kmalloc_array(align_space, sizeof((*data)->bps), GFP_KERNEL);
+   if (!bps) {
+   kfree(*data);
+   return -ENOMEM;
+   }
bps_bo = kmalloc_array(align_space, sizeof((*data)->bps_bo), 
GFP_KERNEL);
-
-   if (!bps || !bps_bo) {
-   kfree(bps);
-   kfree(bps_bo);
+   if (!bps_bo) {
kfree(*data);
+   kfree(bps);
return -ENOMEM;
}
 
-- 
2.33.1

Re: [PATCH] fbdev: sh7760fb: document fallthrough cases

2021-11-14 Thread Gustavo A. R. Silva

On Sun, Nov 14, 2021 at 10:32:57PM -0800, Randy Dunlap wrote:
> Fix fallthrough warnings in sh776fb.c:
> 
> ../drivers/video/fbdev/sh7760fb.c: In function 'sh7760fb_get_color_info':
> ../drivers/video/fbdev/sh7760fb.c:138:23: warning: this statement may fall 
> through [-Wimplicit-fallthrough=]
>   138 | lgray = 1;
> ../drivers/video/fbdev/sh7760fb.c:143:23: warning: this statement may fall 
> through [-Wimplicit-fallthrough=]
>   143 | lgray = 1;
> 
> Just document the current state of code execution/flow.
> 
> Fixes: 4a25e41831ee ("video: sh7760fb: SH7760/SH7763 LCDC framebuffer driver")
> Signed-off-by: Randy Dunlap 
> Cc: "Gustavo A. R. Silva" 
> Cc: Nobuhiro Iwamatsu 
> Cc: Manuel Lauss 
> Cc: Yoshinori Sato 
> Cc: Rich Felker 
> Cc: linux...@vger.kernel.org
> Cc: linux-fb...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org

Reviewed-by: Gustavo A. R. Silva 

Thanks, Randy.
--
Gustavo

> ---
>  drivers/video/fbdev/sh7760fb.c |2 ++
>  1 file changed, 2 insertions(+)
> 
> --- linux-next-2022.orig/drivers/video/fbdev/sh7760fb.c
> +++ linux-next-2022/drivers/video/fbdev/sh7760fb.c
> @@ -136,11 +136,13 @@ static int sh7760fb_get_color_info(struc
>   break;
>   case LDDFR_4BPP_MONO:
>   lgray = 1;
> + fallthrough;
>   case LDDFR_4BPP:
>   lbpp = 4;
>   break;
>   case LDDFR_6BPP_MONO:
>   lgray = 1;
> + fallthrough;
>   case LDDFR_8BPP:
>   lbpp = 8;
>   break;

[PATCH] fbdev: sh7760fb: document fallthrough cases

2021-11-14 Thread Randy Dunlap

Fix fallthrough warnings in sh776fb.c:

../drivers/video/fbdev/sh7760fb.c: In function 'sh7760fb_get_color_info':
../drivers/video/fbdev/sh7760fb.c:138:23: warning: this statement may fall 
through [-Wimplicit-fallthrough=]
  138 | lgray = 1;
../drivers/video/fbdev/sh7760fb.c:143:23: warning: this statement may fall 
through [-Wimplicit-fallthrough=]
  143 | lgray = 1;

Just document the current state of code execution/flow.

Fixes: 4a25e41831ee ("video: sh7760fb: SH7760/SH7763 LCDC framebuffer driver")
Signed-off-by: Randy Dunlap 
Cc: "Gustavo A. R. Silva" 
Cc: Nobuhiro Iwamatsu 
Cc: Manuel Lauss 
Cc: Yoshinori Sato 
Cc: Rich Felker 
Cc: linux...@vger.kernel.org
Cc: linux-fb...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
---
 drivers/video/fbdev/sh7760fb.c |2 ++
 1 file changed, 2 insertions(+)

--- linux-next-2022.orig/drivers/video/fbdev/sh7760fb.c
+++ linux-next-2022/drivers/video/fbdev/sh7760fb.c
@@ -136,11 +136,13 @@ static int sh7760fb_get_color_info(struc
break;
case LDDFR_4BPP_MONO:
lgray = 1;
+   fallthrough;
case LDDFR_4BPP:
lbpp = 4;
break;
case LDDFR_6BPP_MONO:
lgray = 1;
+   fallthrough;
case LDDFR_8BPP:
lbpp = 8;
break;

[PATCH] drm/xen: fix potential memleak in error branch

2021-11-14 Thread Bernard Zhao

In function xen_drm_front_gem_import_sg_table, if in error branch,
there maybe potential memleak if not call gem_free_pages_array.

Signed-off-by: Bernard Zhao 
---
 drivers/gpu/drm/xen/xen_drm_front_gem.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/xen/xen_drm_front_gem.c 
b/drivers/gpu/drm/xen/xen_drm_front_gem.c
index b293c67230ef..732c3eec0666 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_gem.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_gem.c
@@ -222,15 +222,19 @@ xen_drm_front_gem_import_sg_table(struct drm_device *dev,
 
ret = drm_prime_sg_to_page_array(sgt, xen_obj->pages,
 xen_obj->num_pages);
-   if (ret < 0)
+   if (ret < 0) {
+   gem_free_pages_array(xen_obj);
return ERR_PTR(ret);
+   }
 
ret = xen_drm_front_dbuf_create(drm_info->front_info,

xen_drm_front_dbuf_to_cookie(_obj->base),
0, 0, 0, size, sgt->sgl->offset,
xen_obj->pages);
-   if (ret < 0)
+   if (ret < 0) {
+   gem_free_pages_array(xen_obj);
return ERR_PTR(ret);
+   }
 
DRM_DEBUG("Imported buffer of size %zu with nents %u\n",
  size, sgt->orig_nents);
-- 
2.33.1

[PATCH] backlight: ili922x: fix kernel-doc warnings & notation

2021-11-14 Thread Randy Dunlap

Convert function-like macro comments to kernel-doc notation and
fix other kernel-doc warnings:

drivers/video/backlight/ili922x.c:85: warning: This comment starts with '/**', 
but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
* START_BYTE(id, rs, rw)
drivers/video/backlight/ili922x.c:118: warning: expecting prototype for 
CHECK_FREQ_REG(spi_device s, spi_transfer x)(). Prototype was for 
CHECK_FREQ_REG() instead

ili922x.c:92: warning: contents before sections
ili922x.c:150: warning: No description found for return value of 
'ili922x_read_status'
ili922x.c:193: warning: No description found for return value of 'ili922x_read'
ili922x.c:247: warning: No description found for return value of 'ili922x_write'
ili922x.c:353: warning: No description found for return value of 
'ili922x_poweron'
ili922x.c:382: warning: No description found for return value of 
'ili922x_poweroff'

Fixes: 4cfbfa971478 ("video: backlight: add ili922x lcd driver")
Signed-off-by: Randy Dunlap 
Reported-by: kernel test robot 
Cc: Lee Jones 
Cc: Daniel Thompson 
Cc: Jingoo Han 
Cc: dri-devel@lists.freedesktop.org
Cc: Stefano Babic 
Cc: Anatolij Gustschin 
---
 drivers/video/backlight/ili922x.c |   29 ++--
 1 file changed, 19 insertions(+), 10 deletions(-)

--- linux-next-20211102.orig/drivers/video/backlight/ili922x.c
+++ linux-next-20211102/drivers/video/backlight/ili922x.c
@@ -82,13 +82,7 @@
 #define START_RW_READ  1
 
 /**
- * START_BYTE(id, rs, rw)
- *
- * Set the start byte according to the required operation.
- * The start byte is defined as:
- *   --
- *  | 0 | 1 | 1 | 1 | 0 | ID | RS | RW |
- *   --
+ * START_BYTE() - Set the start byte according to the required operation
  * @id: display's id as set by the manufacturer
  * @rs: operation type bit, one of:
  *   - START_RS_INDEX  set the index register
@@ -96,14 +90,19 @@
  * @rw: read/write operation
  *  - START_RW_WRITE   write
  *  - START_RW_READread
+ *
+ * The start byte is defined as:
+ *   --
+ *  | 0 | 1 | 1 | 1 | 0 | ID | RS | RW |
+ *   --
  */
 #define START_BYTE(id, rs, rw) \
(0x70 | (((id) & 0x01) << 2) | (((rs) & 0x01) << 1) | ((rw) & 0x01))
 
 /**
- * CHECK_FREQ_REG(spi_device s, spi_transfer x) - Check the frequency
- * for the SPI transfer. According to the datasheet, the controller
- * accept higher frequency for the GRAM transfer, but it requires
+ * CHECK_FREQ_REG() - Check the frequency for the SPI transfer
+ * According to the datasheet, the controller
+ * accepts higher frequency for the GRAM transfer, but it requires
  * lower frequency when the registers are read/written.
  * The macro sets the frequency in the spi_transfer structure if
  * the frequency exceeds the maximum value.
@@ -145,6 +144,8 @@ struct ili922x {
  * ili922x_read_status - read status register from display
  * @spi: spi device
  * @rs:  output value
+ *
+ * Return: %0 on success or a negative error code on failure
  */
 static int ili922x_read_status(struct spi_device *spi, u16 *rs)
 {
@@ -188,6 +189,8 @@ static int ili922x_read_status(struct sp
  * @spi: spi device
  * @reg: offset of the register to be read
  * @rx:  output value
+ *
+ * Return: %0 on success or a negative error code on failure
  */
 static int ili922x_read(struct spi_device *spi, u8 reg, u16 *rx)
 {
@@ -242,6 +245,8 @@ static int ili922x_read(struct spi_devic
  * @spi: struct spi_device *
  * @reg: offset of the register to be written
  * @value: value to be written
+ *
+ * Return: %0 on success or a negative error code on failure
  */
 static int ili922x_write(struct spi_device *spi, u8 reg, u16 value)
 {
@@ -348,6 +353,8 @@ static void set_write_to_gram_reg(struct
  * The sequence to turn on the display is taken from
  * the datasheet and/or the example code provided by the
  * manufacturer.
+ *
+ * Return: %0 on success or a negative value on failure
  */
 static int ili922x_poweron(struct spi_device *spi)
 {
@@ -377,6 +384,8 @@ static int ili922x_poweron(struct spi_de
 /**
  * ili922x_poweroff - turn the display off
  * @spi: spi device
+ *
+ * Return: %0 on success or a negative value on failure
  */
 static int ili922x_poweroff(struct spi_device *spi)
 {

[PATCH] drm/amd/amdgpu: fix potential memleak

2021-11-14 Thread Bernard Zhao

In function amdgpu_get_xgmi_hive, when kobject_init_and_add failed
There is a potential memleak if not call kobject_put.

Signed-off-by: Bernard Zhao 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
index 0fad2bf854ae..567df2db23ac 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
@@ -386,6 +386,7 @@ struct amdgpu_hive_info *amdgpu_get_xgmi_hive(struct 
amdgpu_device *adev)
"%s", "xgmi_hive_info");
if (ret) {
dev_err(adev->dev, "XGMI: failed initializing kobject for xgmi 
hive\n");
+   kobject_put(>kobj);
kfree(hive);
hive = NULL;
goto pro_end;
-- 
2.33.1

[Bug 211277] sometimes crash at s2ram-wake (Ryzen 3500U): amdgpu, drm, commit_tail, amdgpu_dm_atomic_commit_tail

2021-11-14 Thread bugzilla-daemon

https://bugzilla.kernel.org/show_bug.cgi?id=211277

--- Comment #73 from kolAflash (kolafl...@kolahilft.de) ---
(In reply to Jerome C from comment #72)
> Hi James,
> 
> I noticed the patch that you asked us to try from comment 52 were also
> submitted to kernel 5.14.7
> 
> tested it, all is good for now

Pleased to hear that :-)
I'm just compiling 5.15.2 to run a test myself.

@James
Will those patches be backported to the Linux-5.10 LTS kernel?

master and Linux-5.15
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f02abeb0779700c308e661a412451b38962b8a0b
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8066008482e533e91934bee49765bf8b4a7c40db
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=fefc01f042f44ede373ee66773b8238dd8fdcb55

Linux-5.14.7
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=fe232886fb710a4bf0532f61ebdb87463a780e7e
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=413a8644966a9b4709b114bdb102f64f505d57ef
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=64ca7170c9b17042dc63828b56681aaea88ca38e

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 215025] [amdgpu] Thinkpad A275 hangs on shutdown / screen does not turn on after reboot

2021-11-14 Thread bugzilla-daemon

https://bugzilla.kernel.org/show_bug.cgi?id=215025

--- Comment #2 from Bjoern Franke (b...@nord-west.org) ---
Tested 5.14.16 - ok
Tried 5.15.0 and 5.15.1 -> don't even boot, the first 3 lines look misarranged.

I will try to bisect between 5.14.16 and 5.15.2.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 215025] [amdgpu] Thinkpad A275 hangs on shutdown / screen does not turn on after reboot

2021-11-14 Thread bugzilla-daemon

https://bugzilla.kernel.org/show_bug.cgi?id=215025

--- Comment #1 from Bjoern Franke (b...@nord-west.org) ---
BTW, iommu is enabled:
[0.739887] perf/amd_iommu: Detected AMD IOMMU #0 (2 banks, 4
counters/bank).

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 215025] New: [amdgpu] Thinkpad A275 hangs on shutdown / screen does not turn on after reboot

2021-11-14 Thread bugzilla-daemon

https://bugzilla.kernel.org/show_bug.cgi?id=215025

Bug ID: 215025
   Summary: [amdgpu] Thinkpad A275 hangs on shutdown / screen does
not turn on after reboot
   Product: Drivers
   Version: 2.5
Kernel Version: 5.15.2
  Hardware: All
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-...@kernel-bugs.osdl.org
  Reporter: b...@nord-west.org
Regression: No

My Thinkpad A275 hangs while going into suspend. The screen turned off, but it
does not really enter suspend mode (according to journalctl it started
suspending). Even after reboots the screen does not turn on again, I have to
power off the Thinkpad and then power it on again. The issue did not exist with
5.14.x.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

Re: [PATCH v10, 00/19] Support multi hardware decode using of_platform_populate

2021-11-14 Thread Ezequiel Garcia

Hi Yunfei,

On Thu, 11 Nov 2021 at 01:15, Yunfei Dong  wrote:
>
> This series adds support for multi hardware decode into mtk-vcodec, by first 
> adding use
> of_platform_populate to manage each hardware information: interrupt, clock, 
> register
> bases and power. Secondly add core work queue to deal with core hardware 
> message,
> at the same time, add msg queue for different hardware share messages. 
> Lastly, the
> architecture of different specs are not the same, using specs type to 
> separate them.
>
> This series has been tested with both MT8183 and MT8173. Decoding was working 
> for both chips.
>

How are you testing Decoding? If you are running some test suite, it would
be good to add such information.

Are you testing some edge-cases such as parallel/concurrent decoding,
removing the driver while streaming, and so on? This should help catch
some typical issues.

Thanks,
Ezequiel

> Patches 1~3 rewrite get register bases and power on/off interface.
> Patches 4 export decoder pm interfaces.
> Patches 5 add to support 8192.
> Patch 6 support multi hardware.
> Patch 7 separate video encoder and decoder document
> Patch 8-17 add interfaces to support core hardware.
> Patch 18-19 remove mtk_vcodec_release_dec/enc_pm interfaces.
> ---
> changes compared with v9:
> - need not to build ko, just export pm interfaces for patch 04/19.
> - fix comments for patch 06/19
>
> changes compared with v8:
> - add new patch 18~19 to remove mtk_vcodec_release_de/enc_pm interfaces.
> - fix spelling mistakes for patch 17/19
> - fix yaml comments for patch 15/19
>
> Changes compared with v7:
> - add new patch 4 to build decoder pm file as module
> - add new patch 5 to support 8192
> - fix comments for patch 6/17
> - change some logic for using work queue instead of create thread for core 
> hardware decode for patch 10/17
> - using work queue for hardware decode instead of create thread for patch 
> 13/17
> - add returen value for patch 14/17
> - fix yaml check fail 15/17
>
> Changes compared with v6:
> - Use of_platform_populate to manage multi hardware, not component framework 
> for patch 4/15
> - Re-write dtsi document for hardware architecture changed for patch 13/15 
> -The dtsi will write like below in patch 13/15:
> vcodec_dec: vcodec_dec@1600 {
> compatible = "mediatek,mt8192-vcodec-dec";
> #address-cells = <2>;
> #size-cells = <2>;
> ranges;
> reg = <0 0x1600 0 0x1000>;  /* VDEC_SYS */
> mediatek,scp = <>;
> iommus = < M4U_PORT_L4_VDEC_MC_EXT>;
> dma-ranges = <0x1 0x0 0x0 0x4000 0x0 0xfff0>;
> vcodec_lat {
> compatible = "mediatek,mtk-vcodec-lat";
> reg = <0 0x1601 0 0x800>;   /* VDEC_MISC */
> reg-name = "reg-misc";
> interrupts = ;
> iommus = < M4U_PORT_L5_VDEC_LAT0_VLD_EXT>,
>  < M4U_PORT_L5_VDEC_LAT0_VLD2_EXT>,
>  < M4U_PORT_L5_VDEC_LAT0_AVC_MV_EXT>,
>  < M4U_PORT_L5_VDEC_LAT0_PRED_RD_EXT>,
>  < M4U_PORT_L5_VDEC_LAT0_TILE_EXT>,
>  < M4U_PORT_L5_VDEC_LAT0_WDMA_EXT>,
>  < M4U_PORT_L5_VDEC_LAT0_RG_CTRL_DMA_EXT>,
>  < M4U_PORT_L5_VDEC_UFO_ENC_EXT>;
> clocks = < CLK_TOP_VDEC_SEL>,
>  <_soc CLK_VDEC_SOC_VDEC>,
>  <_soc CLK_VDEC_SOC_LAT>,
>  <_soc CLK_VDEC_SOC_LARB1>,
>  < CLK_TOP_MAINPLL_D4>;
> clock-names = "vdec-sel", "vdec-soc-vdec", "vdec-soc-lat",
>   "vdec-vdec", "vdec-top";
> assigned-clocks = < CLK_TOP_VDEC_SEL>;
> assigned-clock-parents = < CLK_TOP_MAINPLL_D4>;
> power-domains = < MT8192_POWER_DOMAIN_VDEC>;
> };
>
> vcodec_core {
> compatible = "mediatek,mtk-vcodec-core";
> reg = <0 0x16025000 0 0x1000>;  /* VDEC_CORE_MISC */
> reg-names = "reg-misc";
> interrupts = ;
> iommus = < M4U_PORT_L4_VDEC_MC_EXT>,
>  < M4U_PORT_L4_VDEC_UFO_EXT>,
>  < M4U_PORT_L4_VDEC_PP_EXT>,
>  < M4U_PORT_L4_VDEC_PRED_RD_EXT>,
>  < M4U_PORT_L4_VDEC_PRED_WR_EXT>,
>  < M4U_PORT_L4_VDEC_PPWRAP_EXT>,
>  < M4U_PORT_L4_VDEC_TILE_EXT>,
>  < M4U_PORT_L4_VDEC_VLD_EXT>,
>  < M4U_PORT_L4_VDEC_VLD2_EXT>,
>  < M4U_PORT_L4_VDEC_AVC_MV_EXT>,
>  < M4U_PORT_L4_VDEC_RG_CTRL_DMA_EXT>;
> clocks = < CLK_TOP_VDEC_SEL>,
>  < CLK_VDEC_VDEC>,
>  < CLK_VDEC_LAT>,
>  < CLK_VDEC_LARB1>,
>  < CLK_TOP_MAINPLL_D4>;
> clock-names = "vdec-sel", "vdec-soc-vdec", "vdec-soc-lat",
>   "vdec-vdec", "vdec-top";
> assigned-clocks = < CLK_TOP_VDEC_SEL>;
>

Re: [PATCH v10, 15/19] dt-bindings: media: mtk-vcodec: Adds decoder dt-bindings for mt8192

2021-11-14 Thread Ezequiel Garcia

Yunfei,

On Thu, 11 Nov 2021 at 01:15, Yunfei Dong  wrote:
>
> Adds decoder dt-bindings for mt8192.
>
> Signed-off-by: Yunfei Dong 
> ---
>  .../media/mediatek,vcodec-subdev-decoder.yaml | 261 ++
>  1 file changed, 261 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml
>
> diff --git 
> a/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml 
> b/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml
> new file mode 100644
> index ..1886fae6e39d
> --- /dev/null
> +++ 
> b/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml
> @@ -0,0 +1,261 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +
> +%YAML 1.2
> +---
> +$id: 
> "http://devicetree.org/schemas/media/mediatek,vcodec-subdev-decoder.yaml#;
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#;
> +
> +title: Mediatek Video Decode Accelerator With Multi Hardware
> +
> +maintainers:
> +  - Yunfei Dong 
> +
> +description: |
> +  Mediatek Video Decode is the video decode hardware present in Mediatek
> +  SoCs which supports high resolution decoding functionalities. Required
> +  main and subdev device node.
> +
> +  About the Decoder Hardware Block Diagram, please check below:
> +
> ++-++
> +| ||
> +| input -> lat HW -> lat buffer --|--> lat buffer -> core HW -> output
 |

To be completely honest, I can't really understand what is the meaning
of the blocks
with input -> lat hw -> lat buffer, and how this means lat- and core-
are children of some parent.

> +|||   | || |
> ++||---+-||-+
> + ||   lat thread  |  core thread|| 
> +
> -||-||
> + || || 
> + \/ \/
> +   +--+
> +   |enable/disable|
> +   |   clk powerirqiommu port |
> +   | (lat/lat soc/core0/core1)|
> +   +--+
> +
> +  As above,  mean in main device,  mean in subdev device. The 
> information
> +  of each hardware will be stored in subdev device. There are two workqueues 
> in main device:
> +  lat and core. Enable/disable the lat clk/power/irq when lat need to work 
> through hardware
> +  index, core is the same.
> +
> +  Normally the smi common may not the same for each hardware, can't combine 
> all hardware in
> +  one node, or leading to iommu fault when access dram data.
> +

To what extent the lat- and core- devices are really "children"
or "subdevices" of the  video-codec@1600 device?

I.e. what resources do they share? What are the details of
their bus topology?

> +
> +examples:
> +  - |
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +video-codec@1600 {
> +compatible = "mediatek,mt8192-vcodec-dec";
> +reg = <0x1600 0x1000>; /* VDEC_SYS */
> +mediatek,scp = <>;
> +iommus = < M4U_PORT_L4_VDEC_MC_EXT>;
> +dma-ranges = <0x1 0x0 0x0 0x4000 0x0 0xfff0>;
> +#address-cells = <1>;
> +#size-cells = <1>;
> +ranges;
> +vcodec-lat@1601 {
> +compatible = "mediatek,mtk-vcodec-lat";
> +reg = <0x1601 0x800>;
> +interrupts = ;
> +iommus = < M4U_PORT_L5_VDEC_LAT0_VLD_EXT>,
> +< M4U_PORT_L5_VDEC_LAT0_VLD2_EXT>,
> +< M4U_PORT_L5_VDEC_LAT0_AVC_MV_EXT>,
> +< M4U_PORT_L5_VDEC_LAT0_PRED_RD_EXT>,
> +< M4U_PORT_L5_VDEC_LAT0_TILE_EXT>,
> +< M4U_PORT_L5_VDEC_LAT0_WDMA_EXT>,
> +< M4U_PORT_L5_VDEC_LAT0_RG_CTRL_DMA_EXT>,
> +< M4U_PORT_L5_VDEC_UFO_ENC_EXT>;
> +clocks = < CLK_TOP_VDEC_SEL>,
> +<_soc CLK_VDEC_SOC_VDEC>,
> +<_soc CLK_VDEC_SOC_LAT>,
> +<_soc CLK_VDEC_SOC_LARB1>,
> +< CLK_TOP_MAINPLL_D4>;
> +clock-names = "sel", "soc-vdec", "soc-lat", "vdec", "top";
> +assigned-clocks = < CLK_TOP_VDEC_SEL>;
> +assigned-clock-parents = < CLK_TOP_MAINPLL_D4>;
> +power-domains = < MT8192_POWER_DOMAIN_VDEC>;
> +};
> +
> +vcodec-core@16025000 {
> +compatible = "mediatek,mtk-vcodec-core";
> +reg = <0x16025000 0x1000>;

The children address space might

Re: [git pull] drm fixes + one missed next for 5.16-rc1

2021-11-14 Thread Linus Torvalds

On Sun, Nov 14, 2021 at 1:00 PM Dave Airlie  wrote:
>
> i915 will no longer be x86-64 only in theory, since Intel now produces
> PCIe graphics cards using the same hw designs.

Well, at least in my tree, it still has the "depends on X86", along
with several other x86-only things (like "select INTEL_GTT", which is
also x86-only)

So by the time that non-x86 theory becomes reality, hopefully the i915
people will also have figured out how to do the cache flushing
properly.

And hopefully that "do it properly" ends up being simply that the
particular configuration that ends up being portable simply doesn't
need to do it at all and can statically just not build it,
sidestepping the issue entirely.

Fingers crossed.

.. of course, I'm also sure some clueless hardware engineer is still
convinced that non-coherent IO is the way to go for graphics, and that
doing cross-CPU IPIs to write back all caches is somehow still a valid
model. Because some people were still convinced about that not _that_
long ago. Hopefully reality (perhaps in the form of Apple) has caused
people to finally reconsider.

 Linus

Re: [git pull] drm fixes + one missed next for 5.16-rc1

2021-11-14 Thread Dave Airlie

On Sat, 13 Nov 2021 at 06:16, Linus Torvalds
 wrote:
>
> On Thu, Nov 11, 2021 at 7:25 PM Dave Airlie  wrote:
> >
> > I missed a drm-misc-next pull for the main pull last week. It wasn't
> > that major and isn't the bulk of this at all. This has a bunch of
> > fixes all over, a lot for amdgpu and i915.
>
> Ugh.
>
> The i915 conflict was trivial, but made me aware of that absolutely
> disgusting "wbinvd_on_all_cpus()" hack.
>
> And that thing is much too ugly to survive. I made my merge resolution
> remove that disgusting thing.
>
> That driver is x86-only anyway, so it all seemed completely bogus in
> the first place.
>
> And if there is some actual non-x86 work in progress for i915, then
> that wbinvd_on_all_cpus() needs to be replaced with something proper
> and architecture-neutral anyway, most definitely involving a name
> change, and almost certainly also involving a range for the cache
> writeback.
>
> Because that "create broken macro on other architectures" thing is
> *NOT* acceptable.
>
> And I sincerely hope to the gods that no cache-incoherent i915 mess
> ever makes it out of the x86 world. Incoherent IO was always a
> historical mistake and should never ever happen again, so we should
> not spread that horrific pattern around.

i915 will no longer be x86-64 only in theory, since Intel now produces
PCIe graphics cards using the same hw designs. These shouldn't AFAIK
require the same incoherent architecture, though PCIe unsnooped
transactions are a thing in the real world.

The thing is the same driver needs to build/work for the integrated
and discrete cards, hence this hack, but I'm sure someone can Intel
can do better.

I'll leave it to Daniel to figure out who/how.

Dave.

[Bug 214921] amdgpu hangs HP Laptop on shutdown

2021-11-14 Thread bugzilla-daemon

https://bugzilla.kernel.org/show_bug.cgi?id=214921

spassw...@web.de changed:

   What|Removed |Added

 Kernel Version|5.15, 5.15.1|5.15, 5.15.1,
   ||5.15.0-next-2022

--- Comment #4 from spassw...@web.de ---
This still bug is still present in the 5.15.0-next-2022 where it breaks
suspend:

static int uvd_v6_0_suspend(void *handle)
{
int r;
struct amdgpu_device *adev = (struct amdgpu_device *)handle;

/*
 * Proper cleanups before halting the HW engine:
 *   - cancel the delayed idle work
 *   - enable powergating
 *   - enable clockgating
 *   - disable dpm
 *
 * TODO: to align with the VCN implementation, move the
 * jobs for clockgating/powergating/dpm setting to
 * ->set_powergating_state().
 */
#if 0
cancel_delayed_work_sync(>uvd.idle_work);

if (adev->pm.dpm_enabled) {
amdgpu_dpm_enable_uvd(adev, false);
} else {
amdgpu_asic_set_uvd_clocks(adev, 0, 0);
/* shutdown the UVD block */
amdgpu_device_ip_set_powergating_state(adev,
AMD_IP_BLOCK_TYPE_UVD,
   AMD_PG_STATE_GATE);
amdgpu_device_ip_set_clockgating_state(adev,
AMD_IP_BLOCK_TYPE_UVD,
   AMD_CG_STATE_GATE);
}
#endif

r = uvd_v6_0_hw_fini(adev);
if (r)
return r;

return amdgpu_uvd_suspend(adev);
}
This makes suspend work again.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

83 matches

Mail list logo