Re: [PATCH 10/10] drm/fb-helper: Acquire modeset lock around shadow-buffer flushing
Am 16.11.20 um 21:48 schrieb Daniel Vetter:
On Mon, Nov 16, 2020 at 09:04:37PM +0100, Thomas Zimmermann wrote:
Flushing the fbdev's shadow buffer requires vmap'ing the BO memory, which
in turn requires pinning the BO. While being pinned, the BO cannot be moved
into VRAM for scanout. Consequently, a concurrent modeset operation that
involves the fbdev framebuffer would likely fail.
Resolve this problem be acquiring the modeset lock of the planes that use
the fbdev framebuffer. On non-atomic drivers, also acquire the mode-config
lock. This serializes the flushing of the framebuffer with concurrent
modeset operations.
Signed-off-by: Thomas Zimmermann
I think this is the wrong lock. What you want is the buffer lock, the
dma_resv lock of the underlying gem_bo underneath the fb we have. And hold
that from _vmap to the end of _vunmap.
+1 Yes exactly that came to my mind as well while reading this.
If you want to prevent a BO from moving while inside the kernel taking
the reservation lock is usually the right thing to do.
Only when you need to return to userspace AND keep the BO in the same
place then it is valid to pin it.
Regards,
Christian.
Unfortuantely that's going to be one nasty refactoring adventure :-/
So I think for plan B we need something nasty like this, but this here has
disadvantage that fbdev activity in the background can seriously hurt the
native kms client (despite that you're trying to filter a bit, you're
creating a big lock across all planes and we've really worked hard to make
those stand-alone as much as possible).
I think we can do better here, since we're only worried about modesets
from fbdev itself. Nothing else needs to be able to pull the buffer from
system memory into vram while we have it pinned here.
Holding mutex_lock(fb_helper->lock) here instead, with a big comment
explaining why that's enough, and that the clean fix would be holding the
dma_resv_lock, should do the trick.
-Daniel
---
drivers/gpu/drm/drm_fb_helper.c | 43 +++--
1 file changed, 41 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 5a22c744378c..af485c71a42a 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -394,20 +394,59 @@ static void drm_fb_helper_damage_blit_real(struct
drm_fb_helper *fb_helper,
static int drm_fb_helper_damage_blit(struct drm_fb_helper *fb_helper,
struct drm_clip_rect *clip)
{
+ struct drm_device *dev = fb_helper->dev;
+ struct drm_framebuffer *fb = fb_helper->fb;
struct drm_client_buffer *buffer = fb_helper->buffer;
+ struct drm_modeset_acquire_ctx ctx;
+ struct drm_framebuffer *plane_fb;
+ struct drm_plane *plane;
struct dma_buf_map map, dst;
int ret;
+ if (!drm_drv_uses_atomic_modeset(dev))
+ mutex_lock(&dev->mode_config.mutex);
+
+ drm_modeset_acquire_init(&ctx, 0);
+
+retry:
+ drm_for_each_plane(plane, dev) {
+ ret = drm_modeset_lock(&plane->mutex, &ctx);
+ if (ret == -EDEADLK) {
+ ret = drm_modeset_backoff(&ctx);
+ if (!ret)
+ goto retry;
+ } else if (ret) {
+ goto out;
+ }
+
+ if (drm_drv_uses_atomic_modeset(dev))
+ plane_fb = plane->state->fb;
+ else
+ plane_fb = plane->fb;
+
+ if (plane_fb != fb) {
+ drm_modeset_unlock(&plane->mutex);
+ continue;
+ }
+ }
+
ret = drm_client_buffer_vmap(buffer, &map);
if (ret)
- return ret;
+ goto out;
dst = map;
drm_fb_helper_damage_blit_real(fb_helper, clip, &dst);
drm_client_buffer_vunmap(buffer);
- return 0;
+out:
+ drm_modeset_drop_locks(&ctx);
+ drm_modeset_acquire_fini(&ctx);
+
+ if (!drm_drv_uses_atomic_modeset(dev))
+ mutex_unlock(&dev->mode_config.mutex);
+
+ return ret;
}
static void drm_fb_helper_damage_work(struct work_struct *work)
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 29/42] drm/selftests/test-drm_dp_mst_helper: Place 'struct drm_dp_sideband_msg_req_body' onto the heap
On Mon, 16 Nov 2020, Lyude Paul wrote: > Huh-could have sworn I had reviewed this one already. > > Reviewed-by: Lyude Paul Yes, you're right. It was masked by the discussion with Ville. Apologies. > On Mon, 2020-11-16 at 17:40 +, Lee Jones wrote:V > > The stack is too full. > > > > Fixes the following W=1 kernel build warning(s): > > > > drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c: In function > > ‘sideband_msg_req_encode_decode’: > > drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c:161:1: warning: the > > frame size of 1176 bytes is larger than 1024 bytes [-Wframe-larger-than=] > > > > Cc: David Airlie > > Cc: Daniel Vetter > > Cc: Lyude Paul > > Cc: David Francis > > Cc: dri-devel@lists.freedesktop.org > > Signed-off-by: Lee Jones > > --- > > .../drm/selftests/test-drm_dp_mst_helper.c | 31 --- > > 1 file changed, 20 insertions(+), 11 deletions(-) -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 32/42] drm/ttm/ttm_tt: Demote kernel-doc header format abuses
On Mon, 16 Nov 2020, Christian König wrote: > Am 16.11.20 um 18:41 schrieb Lee Jones: > > Fixes the following W=1 kernel build warning(s): > > > > drivers/gpu/drm/ttm/ttm_tt.c:45: warning: Function parameter or member > > 'bo' not described in 'ttm_tt_create' > > drivers/gpu/drm/ttm/ttm_tt.c:45: warning: Function parameter or member > > 'zero_alloc' not described in 'ttm_tt_create' > > drivers/gpu/drm/ttm/ttm_tt.c:83: warning: Function parameter or member > > 'ttm' not described in 'ttm_tt_alloc_page_directory' > > Couldn't we rather describe the missing parameters? Shouldn't be much work. My rule is; if a substantial attempt has been made to document something, I'll patch it up. If little or no attempt has been made, then it gets demoted. Please feel free to document and upgrade them once more. Bear in mind however, there is a script that reports on all files which utilise kernel-doc notation but do not have matching references from the Documentation area. See: scripts/find-unused-docs.sh > > Cc: Christian Koenig > > Cc: Huang Rui > > Cc: David Airlie > > Cc: Daniel Vetter > > Cc: dri-devel@lists.freedesktop.org > > Signed-off-by: Lee Jones > > --- > > drivers/gpu/drm/ttm/ttm_tt.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c > > index cfd633c7e7643..da9eeffe0c6d7 100644 > > --- a/drivers/gpu/drm/ttm/ttm_tt.c > > +++ b/drivers/gpu/drm/ttm/ttm_tt.c > > @@ -38,7 +38,7 @@ > > #include > > #include > > -/** > > +/* > >* Allocates a ttm structure for the given BO. > >*/ > > int ttm_tt_create(struct ttm_buffer_object *bo, bool zero_alloc) > > @@ -73,7 +73,7 @@ int ttm_tt_create(struct ttm_buffer_object *bo, bool > > zero_alloc) > > return 0; > > } > > -/** > > +/* > >* Allocates storage for pointers to the pages that back the ttm. > >*/ > > static int ttm_tt_alloc_page_directory(struct ttm_tt *ttm) > -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/43] drm/radeon/atombios_encoders: Move 'radeon_atom_get_tv_timings()'s prototype into shared location
On Mon, 16 Nov 2020, Alex Deucher wrote: > On Mon, Nov 16, 2020 at 12:30 PM Lee Jones wrote: > > > > Fixes the following W=1 kernel build warning(s): > > > > drivers/gpu/drm/radeon/radeon_atombios.c:1791:6: warning: no previous > > prototype for ‘radeon_atom_get_tv_timings’ [-Wmissing-prototypes] > > 1791 | bool radeon_atom_get_tv_timings(struct radeon_device *rdev, int > > index, > > | ^~ > > > > Cc: Alex Deucher > > Cc: "Christian König" > > Cc: David Airlie > > Cc: Daniel Vetter > > Cc: amd-...@lists.freedesktop.org > > Cc: dri-devel@lists.freedesktop.org > > Signed-off-by: Lee Jones > > Applied. Thanks! Superstar! Thanks Alex. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/4] drm/meson: Module removal fixes
Hi Marc, On 16/11/2020 21:07, Marc Zyngier wrote: > Hi all, > > Having recently moved over to a top-of-the-tree u-boot on one of my > VIM3L systems in order to benefit from unrelated improvements > (automatic PCIe detection, EFI...), I faced the issue that my kernel > would hang like this: > > [ OK ] Finished Helper to synchronize boot up for ifupdown. > [ OK ] Started Rule-based Manager for Device Events and Files. > [7.114516] VDDCPU: supplied by regulator-dummy > [ OK ] Found device /dev/ttyAML0. > [7.146862] meson-drm ff90.vpu: Queued 2 outputs on vpu > [7.169630] fb0: switching to meson-drm-fb from simple > [7.169944] Console: switching to colour dummy device 80x25 > [7.179250] meson-drm ff90.vpu: CVBS Output connector not available > > and that's it. > > After some poking around, I figured out that it is in the > meson-dw-hdmi module that the CPU was hanging... I'll be interested in having your kernel config, I never had such report since I enabled HDMI support in U-Boot a few years ago. > > Reverting to the kernel DT instead of u-boot's papered over it > somehow, but it turned out that removing the module (modprobe -r) > resulted in a firework. And for every issue I was fixing, another > followed. Much fun for a rainy Monday in the basement! > > I ended up with the following 4 patches, which solve all my problems: > I can now boot with the u-boot provided DT, and the hdmi and DRM > drivers can be removed and re-inserted at will. > > The first patch is a straightforward use-after-free, causing a NULL > pointer dereference. Moving things around fixes it. > > The second patch shows that I have no clue about the DRM subsystem > whatsoever. I mimicked what my Rockchip systems are doing, and the two > warnings disappeared. It can't completely be wrong (famous last > words...). > > The third patch fixes a *very* common issue with regulators (I've > fixed at least 3 drivers with a similar issue). I guess the devm > subsystem needs to grow a new helper at some point. > > The last patch finally fixes the issue I was seeing: the HDMI driver > hangs when accessing a register with clocks disabled, which they are > on module removal. It also fixes my u-boot booting for similar > reasons, I guess. Anyway, thanks for fixing this ! > > I went as far as reaching out for a HDMI cable and verifying that I > was getting a working display. Total dedication. This is very appreciated :-) > > Feedback much appreciated. > > M. > > Marc Zyngier (4): > drm/meson: Free RDMA resources after tearing down DRM > drm/meson: Unbind all connectors on module removal > drm/meson: dw-hdmi: Register a callback to disable the regulator > drm/meson: dw-hdmi: Ensure that clocks are enabled before touching the > TOP registers > > drivers/gpu/drm/meson/meson_drv.c | 12 +++- > drivers/gpu/drm/meson/meson_dw_hdmi.c | 13 +++-- > 2 files changed, 18 insertions(+), 7 deletions(-) > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
BUG: unable to handle kernel NULL pointer dereference in fbcon_cursor
Hello, syzbot found the following issue on: HEAD commit:6dd65e60 Add linux-next specific files for 20201110 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=1276af6250 kernel config: https://syzkaller.appspot.com/x/.config?x=4fab43daf5c54712 dashboard link: https://syzkaller.appspot.com/bug?extid=b67aaae8d3a927f68d20 compiler: gcc (GCC) 10.1.0-syz 20200507 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+b67aaae8d3a927f68...@syzkaller.appspotmail.com BUG: kernel NULL pointer dereference, address: #PF: supervisor instruction fetch in kernel mode #PF: error_code(0x0010) - not-present page PGD 4e683067 P4D 4e683067 PUD 14850067 PMD 0 Oops: 0010 [#1] PREEMPT SMP KASAN CPU: 0 PID: 9433 Comm: syz-executor.5 Not tainted 5.10.0-rc3-next-20201110-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:0x0 Code: Unable to access opcode bytes at RIP 0xffd6. RSP: 0018:c9000bca7858 EFLAGS: 00010286 RAX: RBX: RCX: RDX: 0002 RSI: 888144509000 RDI: 888010079000 RBP: 888010079000 R08: R09: 8cecc387 R10: 0003 R11: R12: 888144509000 R13: R14: R15: 0720 FS: 7f5822bee700() GS:8880b9e0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: ffd6 CR3: 4e973000 CR4: 001506f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: fbcon_cursor+0x50e/0x620 drivers/video/fbdev/core/fbcon.c:1346 hide_cursor+0x85/0x280 drivers/tty/vt/vt.c:907 redraw_screen+0x5ed/0x790 drivers/tty/vt/vt.c:1012 vc_do_resize+0xed3/0x1150 drivers/tty/vt/vt.c:1326 fbcon_set_disp+0x831/0xda0 drivers/video/fbdev/core/fbcon.c:1413 con2fb_init_display drivers/video/fbdev/core/fbcon.c:816 [inline] set_con2fb_map+0x7a6/0xf80 drivers/video/fbdev/core/fbcon.c:887 fbcon_set_con2fb_map_ioctl+0x165/0x220 drivers/video/fbdev/core/fbcon.c:3072 do_fb_ioctl+0x5b6/0x690 drivers/video/fbdev/core/fbmem.c:1156 fb_ioctl+0xe7/0x150 drivers/video/fbdev/core/fbmem.c:1185 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl fs/ioctl.c:739 [inline] __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:739 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x45deb9 Code: 0d b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 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 0f 83 db b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7f5822bedc78 EFLAGS: 0246 ORIG_RAX: 0010 RAX: ffda RBX: e2c0 RCX: 0045deb9 RDX: 20c0 RSI: 4610 RDI: 0006 RBP: 0118bf60 R08: R09: R10: R11: 0246 R12: 0118bf2c R13: 7ffe024fb66f R14: 7f5822bee9c0 R15: 0118bf2c Modules linked in: CR2: BUG: kernel NULL pointer dereference, address: #PF: supervisor instruction fetch in kernel mode #PF: error_code(0x0010) - not-present page PGD 4e683067 P4D 4e683067 PUD 14850067 PMD 0 Oops: 0010 [#2] PREEMPT SMP KASAN CPU: 0 PID: 9433 Comm: syz-executor.5 Not tainted 5.10.0-rc3-next-20201110-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:0x0 Code: Unable to access opcode bytes at RIP 0xffd6. RSP: 0018:c9000bca7278 EFLAGS: 00010086 RAX: 0007 RBX: RCX: 0007 RDX: 0002 RSI: 888144509000 RDI: 888010079000 RBP: 888010079000 R08: R09: 8cecc387 R10: 0003 R11: 0001 R12: 888144509000 R13: R14: R15: 0720 FS: 7f5822bee700() GS:8880b9e0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: ffd6 CR3: 4e973000 CR4: 001506f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: fbcon_cursor+0x50e/0x620 drivers/video/fbdev/core/fbcon.c:1346 hide_cursor+0x85/0x280 drivers/tty/vt/vt.c:907 redraw_screen+0x5ed/0x790 drivers/tty/vt/vt.c:1012 fbcon_blank+0x8c5/0xc30 drivers/video/fbdev/core/fbcon.c:2248 do_unblank_screen+0x25b/0x470 drivers/tty/vt/vt.c:4406 bust_spinlocks+0x5b/0xe0 lib/bust_spinlocks.c:26 oops_end+0x2b/0xe0 arch/x86/kernel/dumpstack.c:346 no_context+0x5f2/0xa20 arch/x86/mm/fault.c:752 __bad_
[PATCH] drm/i915/selftests: Fix wrong return value of perf_request_latency()
If intel context create failed, the perf_request_latency() will return 0
rather than error, because we doesn't initialize the return value.
Fixes: 25c26f18ea79 ("drm/i915/selftests: Measure dispatch latency")
Reported-by: Hulk Robot
Signed-off-by: Zhang Xiaoxu
---
drivers/gpu/drm/i915/selftests/i915_request.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/selftests/i915_request.c
b/drivers/gpu/drm/i915/selftests/i915_request.c
index 64bbb8288249..6b512fc13ca7 100644
--- a/drivers/gpu/drm/i915/selftests/i915_request.c
+++ b/drivers/gpu/drm/i915/selftests/i915_request.c
@@ -2293,8 +2293,10 @@ static int perf_request_latency(void *arg)
struct intel_context *ce;
ce = intel_context_create(engine);
- if (IS_ERR(ce))
+ if (IS_ERR(ce)) {
+ err = PTR_ERR(ce);
goto out;
+ }
err = intel_context_pin(ce);
if (err) {
--
2.25.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND PATCH v2 4/5] drm/msm: add DRM_MSM_GEM_SYNC_CACHE for non-coherent cache maintenance
On 11/16/20 12:50 PM, Rob Clark wrote: On Mon, Nov 16, 2020 at 9:33 AM Christoph Hellwig wrote: On Sat, Nov 14, 2020 at 03:07:20PM -0500, Jonathan Marek wrote: qcom's vulkan driver has nonCoherentAtomSize=1, and it looks like dma_sync_single_for_cpu() does deal in some way with the partial cache line case, although I'm not sure that means we can have a nonCoherentAtomSize=1. No, it doesn't. You need to ensure ownership is managed at dma_get_cache_alignment() granularity. my guess is nonCoherentAtomSize=1 only works in the case of cache coherent buffers nonCoherentAtomSize doesn't apply to coherent memory (as the name implies), I guess qcom's driver is just wrong about having nonCoherentAtomSize=1. Jordan just mentioned there is at least one conformance test for this, I wonder if it just doesn't test it well enough, or just doesn't test the non-coherent memory type? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/mediatek: dsi: Calculate horizontal_backporch_byte by itself
Hi CK,
On Mon, 16 Nov 2020 07:12:55 +0800
Chun-Kuang Hu wrote:
> Hi, Bilal:
>
> Bilal Wasim 於 2020年11月16日 週一
> 上午3:25寫道：
> >
> > Hi CK,
> >
> > On Sun, 15 Nov 2020 08:53:24 +0800
> > Chun-Kuang Hu wrote:
> >
> > > Hi, Bilal:
> > >
> > > Please help to test this patch on your Chromebook elm, thanks.
> > >
> > > Regards,
> > > Chun-Kuang Hu
> >
> > Just tried this patch on the Chromebook Elm, and it doesn't work.
> > The HDMI screen remains black, though the rest of the system keeps
> > on operating normally.
>
> Could you print this information, so I could find out the solution for
> both small hbp and elm.
>
> vm->hfront_porch, vm->hback_porch, dsi_tmp_buf_bpp,
> data_phy_cycles_byte, and the final horizontal_frontporch_byte,
> horizontal_backporch_byte.
Here are the values I got,
[2.506400] [drm] vm->hfront_porch: 48
[2.506402] [drm] vm->hback_porch: 200
[2.506404] [drm] dsi_tmp_buf_bpp: 3
[2.506406] [drm] data_phy_cycles_byte: 180
[2.506408] [drm] horizontal_frontporch_byte: 110
[2.506409] [drm] horizontal_backporch_byte: 455
Please let me know if I can help debug this in any other way.
Thanks,
Bilal
>
> Regards,
> Chun-Kuang.
>
> >
> > >
> > > Chun-Kuang Hu 於 2020年11月15日 週日
> > > 上午8:14寫道：
> > > >
> > > > From: CK Hu
> > > >
> > > > Using vm->hfront_porch + vm->hback_porch to calculate
> > > > horizontal_backporch_byte would make it negtive, so
> > > > use horizontal_backporch_byte itself to make it positive.
> > > >
> > > > Fixes: 35bf948f1edb ("drm/mediatek: dsi: Fix scrolling of panel
> > > > with small hfp or hbp")
> > > >
> > > > Signed-off-by: CK Hu
> > > > Signed-off-by: Chun-Kuang Hu
> > > > ---
> > > > drivers/gpu/drm/mediatek/mtk_dsi.c | 53
> > > > ++ 1 file changed, 18
> > > > insertions(+), 35 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
> > > > b/drivers/gpu/drm/mediatek/mtk_dsi.c index
> > > > 4a188a942c38..2a64fdaed9a7 100644 ---
> > > > a/drivers/gpu/drm/mediatek/mtk_dsi.c +++
> > > > b/drivers/gpu/drm/mediatek/mtk_dsi.c @@ -444,7 +444,10 @@ static
> > > > void mtk_dsi_config_vdo_timing(struct mtk_dsi *dsi) u32
> > > > horizontal_sync_active_byte; u32 horizontal_backporch_byte;
> > > > u32 horizontal_frontporch_byte;
> > > > + u32 horizontal_front_back_byte;
> > > > + u32 data_phy_cycles_byte;
> > > > u32 dsi_tmp_buf_bpp, data_phy_cycles;
> > > > + u32 delta;
> > > > struct mtk_phy_timing *timing = &dsi->phy_timing;
> > > >
> > > > struct videomode *vm = &dsi->vm;
> > > > @@ -474,42 +477,22 @@ static void
> > > > mtk_dsi_config_vdo_timing(struct mtk_dsi *dsi) data_phy_cycles
> > > > = timing->lpx + timing->da_hs_prepare
> > > > + timing->da_hs_zero + timing->da_hs_exit;
> > > >
> > > > - if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) {
> > > > - if ((vm->hfront_porch + vm->hback_porch) *
> > > > dsi_tmp_buf_bpp >
> > > > - data_phy_cycles * dsi->lanes + 18) {
> > > > - horizontal_frontporch_byte =
> > > > - vm->hfront_porch *
> > > > dsi_tmp_buf_bpp -
> > > > - (data_phy_cycles * dsi->lanes +
> > > > 18) *
> > > > - vm->hfront_porch /
> > > > - (vm->hfront_porch +
> > > > vm->hback_porch); -
> > > > - horizontal_backporch_byte =
> > > > - horizontal_backporch_byte -
> > > > - (data_phy_cycles * dsi->lanes +
> > > > 18) *
> > > > - vm->hback_porch /
> > > > - (vm->hfront_porch +
> > > > vm->hback_porch);
> > > > - } else {
> > > > - DRM_WARN("HFP less than d-phy, FPS will
> > > > under 60Hz\n");
> > > > - horizontal_frontporch_byte =
> > > > vm->hfront_porch *
> > > > -
> > > > dsi_tmp_buf_bpp;
> > > > - }
> > > > + delta = dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST ?
> > > > 18 : 12; +
> > > > + horizontal_frontporch_byte = vm->hfront_porch *
> > > > dsi_tmp_buf_bpp;
> > > > + horizontal_front_back_byte = horizontal_frontporch_byte
> > > > + horizontal_backporch_byte;
> > > > + data_phy_cycles_byte = data_phy_cycles * dsi->lanes +
> > > > delta; +
> > > > + if (horizontal_front_back_byte > data_phy_cycles_byte) {
> > > > + horizontal_frontporch_byte -=
> > > > data_phy_cycles_byte * +
> > > > horizontal_frontporch_byte /
> > > > +
> > > > horizontal_front_back_byte; +
> > > > + horizontal_backporch_byte -=
> > > > data_phy_cycles_byte * +
> > > > horizontal_backporch_byte /
> > > > +
> > > > horizontal_front_back_byte; } else {
> > > > - if ((vm->hfront_porch + vm->hback_porch) *
> > > > dsi_tmp_buf_bpp >
> > > > - data_phy_cycles * dsi->lanes +
[PATCH] drm/omap: dmm_tiler: fix return error code in omap_dmm_probe()
Return -ENOMEM when allocating refill memory failed.
Fixes: 71e8831f6407 ("drm/omap: DMM/TILER support for OMAP4+ platform")
Reported-by: Hulk Robot
Signed-off-by: Yang Yingliang
---
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
index 42ec51bb7b1b..7f4317248812 100644
--- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
@@ -889,6 +889,7 @@ static int omap_dmm_probe(struct platform_device *dev)
&omap_dmm->refill_pa, GFP_KERNEL);
if (!omap_dmm->refill_va) {
dev_err(&dev->dev, "could not allocate refill memory\n");
+ ret = -ENOMEM;
goto fail;
}
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm/meson: Free RDMA resources after tearing down DRM
On 16/11/2020 21:07, Marc Zyngier wrote:
> Removing the meson DRM module results in the following splat:
>
> [ 2179.451346] Hardware name: , BIOS 2021.01-rc2-00012-gde865f7ee1 11/16/2020
> [ 2179.458316] Workqueue: events drm_mode_rmfb_work_fn [drm]
> [ 2179.463597] pstate: 80c9 (Nzcv daif +PAN +UAO -TCO BTYPE=--)
> [ 2179.469558] pc : meson_rdma_writel_sync+0x44/0xb0 [meson_drm]
> [ 2179.475243] lr : meson_g12a_afbcd_reset+0x34/0x60 [meson_drm]
> [ 2179.480930] sp : ffc01212bb70
> [ 2179.484207] x29: ffc01212bb70 x28: ff8044f66f00
> [ 2179.489469] x27: ff8045b13800 x26: 0001
> [ 2179.494730] x25: x24: 0001
> [ 2179.41] x23: x22:
> [ 2179.505252] x21: 0028 x20: 1a01
> [ 2179.510513] x19: ff8046029480 x18:
> [ 2179.515775] x17: x16:
> [ 2179.521036] x15: x14:
> [ 2179.526297] x13: 00400326 x12: 0309030303260300
> [ 2179.531558] x11: 0300054004a0 x10: 0418054004000400
> [ 2179.536820] x9 : ffc008fe4914 x8 : ff8040a1adc0
> [ 2179.542081] x7 : x6 : ff8042aa0080
> [ 2179.547342] x5 : ff8044f66f00 x4 : ffc008fe5bc8
> [ 2179.552603] x3 : 00010101 x2 : 0001
> [ 2179.557865] x1 : x0 :
> [ 2179.563127] Call trace:
> [ 2179.565548] meson_rdma_writel_sync+0x44/0xb0 [meson_drm]
> [ 2179.570894] meson_g12a_afbcd_reset+0x34/0x60 [meson_drm]
> [ 2179.576241] meson_plane_atomic_disable+0x38/0xb0 [meson_drm]
> [ 2179.581966] drm_atomic_helper_commit_planes+0x1e0/0x21c [drm_kms_helper]
> [ 2179.588684] drm_atomic_helper_commit_tail_rpm+0x68/0xb0 [drm_kms_helper]
> [ 2179.595410] commit_tail+0xac/0x190 [drm_kms_helper]
> [ 2179.600326] drm_atomic_helper_commit+0x16c/0x390 [drm_kms_helper]
> [ 2179.606484] drm_atomic_commit+0x58/0x70 [drm]
> [ 2179.610880] drm_framebuffer_remove+0x398/0x434 [drm]
> [ 2179.615881] drm_mode_rmfb_work_fn+0x68/0x8c [drm]
> [ 2179.620575] process_one_work+0x1cc/0x49c
> [ 2179.624538] worker_thread+0x200/0x444
> [ 2179.628246] kthread+0x14c/0x160
> [ 2179.631439] ret_from_fork+0x10/0x38
>
> caused by the fact that the RDMA buffer has already been freed,
> resulting in meson_rdma_writel_sync() getting a NULL pointer.
>
> Move the afbcd reset and meson_rdma_free calls after the DRM
> unregistration is complete so that the teardown can safely complete.
>
> Signed-off-by: Marc Zyngier
Fixes: d1b5e41e13a7 ("drm/meson: Add AFBCD module driver")
> ---
> drivers/gpu/drm/meson/meson_drv.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/meson/meson_drv.c
> b/drivers/gpu/drm/meson/meson_drv.c
> index 8b9c8dd788c4..324fa489f1c4 100644
> --- a/drivers/gpu/drm/meson/meson_drv.c
> +++ b/drivers/gpu/drm/meson/meson_drv.c
> @@ -389,15 +389,15 @@ static void meson_drv_unbind(struct device *dev)
> meson_canvas_free(priv->canvas, priv->canvas_id_vd1_2);
> }
>
> - if (priv->afbcd.ops) {
> - priv->afbcd.ops->reset(priv);
> - meson_rdma_free(priv);
> - }
> -
> drm_dev_unregister(drm);
> drm_irq_uninstall(drm);
> drm_kms_helper_poll_fini(drm);
> drm_dev_put(drm);
> +
> + if (priv->afbcd.ops) {
> + priv->afbcd.ops->reset(priv);
> + meson_rdma_free(priv);
> + }
> }
>
> static const struct component_master_ops meson_drv_master_ops = {
>
Acked-by: Neil Armstrong
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4] dt-bindings: display: panel: one file of all simple LVDS panels with dual ports
To complement panel-simple.yaml, create panel-simple-lvds-dual-ports.yaml.
panel-simple-lvds-dual-ports.yaml is for all simple LVDS panels that
have dual LVDS ports and require only a single power-supply.
The first port receives odd pixels, and the second port receives even pixels.
Optionally, a backlight and an enable GPIO can be specified as properties.
Panels with swapped pixel order, if any, need dedicated bindings.
Migrate 'auo,g133han01', 'auo,g185han01', 'auo,g190ean01',
'koe,tx26d202vm0bwa' and 'nlt,nl192108ac18-02d' over to the new file.
The objectives with one file for all the simple LVDS panels with dual ports are:
- Make it simpler to add bindings for this kind of LVDS panels
- Keep the number of bindings file lower
- Keep the binding documentation for this kind of LVDS panels more consistent
- Make it possible for drivers to get pixel order via
drm_of_lvds_get_dual_link_pixel_order(), as the optional 'ports' property is
allowed
Suggested-by: Sam Ravnborg
Cc: Thierry Reding
Cc: Sam Ravnborg
Cc: David Airlie
Cc: Daniel Vetter
Cc: Rob Herring
Cc: Lucas Stach
Cc: Sebastian Reichel
Signed-off-by: Liu Ying
---
v3->v4:
* Add type and descriptions for dual-lvds-{odd,even}-pixels properties.
Also, update descriptions for port@0 and port@1 properties accordingly. (Rob)
v2->v3:
* Do not allow 'port' property. (Rob)
* Define port number. (Rob)
* Specify 'dual-lvds-odd-pixels' and 'dual-lvds-even-pixels' properties. (Rob)
v1->v2:
* Correct pixel order in example LVDS panel node.
.../panel/panel-simple-lvds-dual-ports.yaml| 130 +
.../bindings/display/panel/panel-simple.yaml | 10 --
2 files changed, 130 insertions(+), 10 deletions(-)
create mode 100644
Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml
b/Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml
new file mode 100644
index ..38a789b
--- /dev/null
+++
b/Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml
@@ -0,0 +1,130 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id:
http://devicetree.org/schemas/display/panel/panel-simple-lvds-dual-ports.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Simple LVDS panels with one power supply and dual LVDS ports
+
+maintainers:
+ - Liu Ying
+ - Thierry Reding
+ - Sam Ravnborg
+
+description: |
+ This binding file is a collection of the LVDS panels that
+ has dual LVDS ports and requires only a single power-supply.
+ The first port receives odd pixels, and the second port receives even pixels.
+ There are optionally a backlight and an enable GPIO.
+ The panel may use an OF graph binding for the association to the display,
+ or it may be a direct child node of the display.
+
+ If the panel is more advanced a dedicated binding file is required.
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+
+ compatible:
+enum:
+# compatible must be listed in alphabetical order, ordered by compatible.
+# The description in the comment is mandatory for each compatible.
+
+# AU Optronics Corporation 13.3" FHD (1920x1080) TFT LCD panel
+ - auo,g133han01
+# AU Optronics Corporation 18.5" FHD (1920x1080) TFT LCD panel
+ - auo,g185han01
+# AU Optronics Corporation 19.0" (1280x1024) TFT LCD panel
+ - auo,g190ean01
+# Kaohsiung Opto-Electronics Inc. 10.1" WUXGA (1920 x 1200) LVDS TFT
LCD panel
+ - koe,tx26d202vm0bwa
+# NLT Technologies, Ltd. 15.6" FHD (1920x1080) LVDS TFT LCD panel
+ - nlt,nl192108ac18-02d
+
+ ports:
+type: object
+properties:
+ '#address-cells':
+const: 1
+
+ '#size-cells':
+const: 0
+
+ port@0:
+type: object
+description: The first sink port.
+properties:
+ reg:
+const: 0
+
+ dual-lvds-odd-pixels:
+type: boolean
+description: The first sink port for odd pixels.
+
+required:
+ - reg
+ - dual-lvds-odd-pixels
+
+ port@1:
+type: object
+description: The second sink port.
+properties:
+ reg:
+const: 1
+
+ dual-lvds-even-pixels:
+type: boolean
+description: The second sink port for even pixels.
+
+required:
+ - reg
+ - dual-lvds-even-pixels
+
+required:
+ - "#address-cells"
+ - "#size-cells"
+ - port@0
+ - port@1
+
+additionalProperties: false
+
+ backlight: true
+ enable-gpios: true
+ power-supply: true
+
+additionalProperties: false
+
+required:
+ - compatible
+ - power-supply
+
+examples:
+ - |
+panel: panel-lvds {
+ compatible = "koe,tx26d202vm0bwa";
+ power-supply = <&vdd_lcd_reg>;
+
+ ports {
+#address-
[PATCH] drm/i915/selftests: Fix wrong return value of perf_series_engines()
If intel context create failed, the perf_series_engines() will return 0
rather than error, because we doesn't initialize the return value.
Fixes: cbfd3a0c5a55 ("drm/i915/selftests: Add request throughput measurement to
perf")
Reported-by: Hulk Robot
Signed-off-by: Zhang Xiaoxu
---
drivers/gpu/drm/i915/selftests/i915_request.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/selftests/i915_request.c
b/drivers/gpu/drm/i915/selftests/i915_request.c
index 6b512fc13ca7..e424a6d1a68c 100644
--- a/drivers/gpu/drm/i915/selftests/i915_request.c
+++ b/drivers/gpu/drm/i915/selftests/i915_request.c
@@ -2469,8 +2469,10 @@ static int perf_series_engines(void *arg)
struct intel_context *ce;
ce = intel_context_create(engine);
- if (IS_ERR(ce))
+ if (IS_ERR(ce)) {
+ err = PTR_ERR(ce);
goto out;
+ }
err = intel_context_pin(ce);
if (err) {
--
2.25.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND PATCH 2/3] phy: mediatek: Move mtk_mipi_dsi_phy driver into drivers/phy/mediatek folder
Hi CK,
On Tue, 2020-11-17 at 07:14 +0800, Chun-Kuang Hu wrote:
> mtk_mipi_dsi_phy is currently placed inside mediatek drm driver, but it's
> more suitable to place a phy driver into phy driver folder, so move
> mtk_mipi_dsi_phy driver into phy driver folder.
>
> Signed-off-by: Chun-Kuang Hu
You forgot to add acked-by me
> ---
> drivers/gpu/drm/mediatek/Kconfig | 7 ---
> drivers/gpu/drm/mediatek/Makefile | 6 --
> drivers/phy/mediatek/Kconfig | 7 +++
> drivers/phy/mediatek/Makefile | 5 +
> .../mediatek/phy-mtk-mipi-dsi-mt8173.c}| 2 +-
> .../mediatek/phy-mtk-mipi-dsi-mt8183.c}| 2 +-
> .../mtk_mipi_tx.c => phy/mediatek/phy-mtk-mipi-dsi.c} | 2 +-
> .../mtk_mipi_tx.h => phy/mediatek/phy-mtk-mipi-dsi.h} | 0
> 8 files changed, 15 insertions(+), 16 deletions(-)
> rename drivers/{gpu/drm/mediatek/mtk_mt8173_mipi_tx.c =>
> phy/mediatek/phy-mtk-mipi-dsi-mt8173.c} (99%)
> rename drivers/{gpu/drm/mediatek/mtk_mt8183_mipi_tx.c =>
> phy/mediatek/phy-mtk-mipi-dsi-mt8183.c} (99%)
> rename drivers/{gpu/drm/mediatek/mtk_mipi_tx.c =>
> phy/mediatek/phy-mtk-mipi-dsi.c} (99%)
> rename drivers/{gpu/drm/mediatek/mtk_mipi_tx.h =>
> phy/mediatek/phy-mtk-mipi-dsi.h} (100%)
>
> diff --git a/drivers/gpu/drm/mediatek/Kconfig
> b/drivers/gpu/drm/mediatek/Kconfig
> index 24c4890a6e65..2976d21e9a34 100644
> --- a/drivers/gpu/drm/mediatek/Kconfig
> +++ b/drivers/gpu/drm/mediatek/Kconfig
> @@ -28,10 +28,3 @@ config DRM_MEDIATEK_HDMI
> select PHY_MTK_HDMI
> help
> DRM/KMS HDMI driver for Mediatek SoCs
> -
> -config PHY_MTK_MIPI_DSI
> - tristate "Mediatek MIPI-DSI-PHY Driver"
> - depends on ARCH_MEDIATEK && OF
> - select GENERIC_PHY
> - help
> - Support MIPI DSI PHY for Mediatek SoCs.
> diff --git a/drivers/gpu/drm/mediatek/Makefile
> b/drivers/gpu/drm/mediatek/Makefile
> index baa188000543..a892edec5563 100644
> --- a/drivers/gpu/drm/mediatek/Makefile
> +++ b/drivers/gpu/drm/mediatek/Makefile
> @@ -19,9 +19,3 @@ mediatek-drm-hdmi-objs := mtk_cec.o \
> mtk_hdmi_ddc.o
>
> obj-$(CONFIG_DRM_MEDIATEK_HDMI) += mediatek-drm-hdmi.o
> -
> -phy-mtk-mipi-dsi-drv-objs := mtk_mipi_tx.o \
> - mtk_mt8173_mipi_tx.o \
> - mtk_mt8183_mipi_tx.o
> -
> -obj-$(CONFIG_PHY_MTK_MIPI_DSI) += phy-mtk-mipi-dsi-drv.o
> diff --git a/drivers/phy/mediatek/Kconfig b/drivers/phy/mediatek/Kconfig
> index 50c5e9306e19..574b8e6398d2 100644
> --- a/drivers/phy/mediatek/Kconfig
> +++ b/drivers/phy/mediatek/Kconfig
> @@ -42,3 +42,10 @@ config PHY_MTK_HDMI
> select GENERIC_PHY
> help
> Support HDMI PHY for Mediatek SoCs.
> +
> +config PHY_MTK_MIPI_DSI
> + tristate "MediaTek MIPI-DSI Driver"
> + depends on ARCH_MEDIATEK && OF
> + select GENERIC_PHY
> + help
> + Support MIPI DSI for Mediatek SoCs.
> diff --git a/drivers/phy/mediatek/Makefile b/drivers/phy/mediatek/Makefile
> index 6325e38709ed..ace660fbed3a 100644
> --- a/drivers/phy/mediatek/Makefile
> +++ b/drivers/phy/mediatek/Makefile
> @@ -11,3 +11,8 @@ phy-mtk-hdmi-drv-y := phy-mtk-hdmi.o
> phy-mtk-hdmi-drv-y += phy-mtk-hdmi-mt2701.o
> phy-mtk-hdmi-drv-y += phy-mtk-hdmi-mt8173.o
> obj-$(CONFIG_PHY_MTK_HDMI) += phy-mtk-hdmi-drv.o
> +
> +phy-mtk-mipi-dsi-drv-y := phy-mtk-mipi-dsi.o
> +phy-mtk-mipi-dsi-drv-y += phy-mtk-mipi-dsi-mt8173.o
> +phy-mtk-mipi-dsi-drv-y += phy-mtk-mipi-dsi-mt8183.o
> +obj-$(CONFIG_PHY_MTK_MIPI_DSI) += phy-mtk-mipi-dsi-drv.o
> diff --git a/drivers/gpu/drm/mediatek/mtk_mt8173_mipi_tx.c
> b/drivers/phy/mediatek/phy-mtk-mipi-dsi-mt8173.c
> similarity index 99%
> rename from drivers/gpu/drm/mediatek/mtk_mt8173_mipi_tx.c
> rename to drivers/phy/mediatek/phy-mtk-mipi-dsi-mt8173.c
> index f18db14d8b63..7a847954594f 100644
> --- a/drivers/gpu/drm/mediatek/mtk_mt8173_mipi_tx.c
> +++ b/drivers/phy/mediatek/phy-mtk-mipi-dsi-mt8173.c
> @@ -4,7 +4,7 @@
> * Author: jitao.shi
> */
>
> -#include "mtk_mipi_tx.h"
> +#include "phy-mtk-mipi-dsi.h"
>
> #define MIPITX_DSI_CON 0x00
> #define RG_DSI_LDOCORE_ENBIT(0)
> diff --git a/drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c
> b/drivers/phy/mediatek/phy-mtk-mipi-dsi-mt8183.c
> similarity index 99%
> rename from drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c
> rename to drivers/phy/mediatek/phy-mtk-mipi-dsi-mt8183.c
> index 9f3e55aeebb2..99108426d57c 100644
> --- a/drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c
> +++ b/drivers/phy/mediatek/phy-mtk-mipi-dsi-mt8183.c
> @@ -4,7 +4,7 @@
> * Author: jitao.shi
> */
>
> -#include "mtk_mipi_tx.h"
> +#include "phy-mtk-mipi-dsi.h"
>
> #define MIPITX_LANE_CON 0x000c
> #define RG_DSI_CP
Re: [PATCH] drm/msm/dp: fix connect/disconnect handled at ir_hdp
Quoting Kuogee Hsieh (2020-11-13 14:26:39)
> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
> b/drivers/gpu/drm/msm/dp/dp_display.c
> index 27e7e27b8b90..4e84f500b721 100644
> --- a/drivers/gpu/drm/msm/dp/dp_display.c
> +++ b/drivers/gpu/drm/msm/dp/dp_display.c
> @@ -279,13 +279,25 @@ static void dp_display_send_hpd_event(struct msm_dp
> *dp_display)
> drm_helper_hpd_irq_event(connector->dev);
> }
>
> -static int dp_display_send_hpd_notification(struct dp_display_private *dp,
> - bool hpd)
> +
> +static void dp_display_set_encoder_mode(struct dp_display_private *dp)
> {
> - static bool encoder_mode_set;
> struct msm_drm_private *priv = dp->dp_display.drm_dev->dev_private;
> struct msm_kms *kms = priv->kms;
> + static bool encoder_mode_set;
Can this be stored in the dp_display_private structure instead? No
singletons please.
> +
> + if (!encoder_mode_set && dp->dp_display.encoder &&
> + kms->funcs->set_encoder_mode) {
> + kms->funcs->set_encoder_mode(kms,
> + dp->dp_display.encoder, false);
>
> + encoder_mode_set = true;
> + }
> +}
> +
> +static int dp_display_send_hpd_notification(struct dp_display_private *dp,
> + bool hpd)
> +{
> if ((hpd && dp->dp_display.is_connected) ||
> (!hpd && !dp->dp_display.is_connected)) {
> DRM_DEBUG_DP("HPD already %s\n", (hpd ? "on" : "off"));
> @@ -491,17 +487,29 @@ static int dp_display_usbpd_attention_cb(struct device
> *dev)
> if (!rc) {
> sink_request = dp->link->sink_request;
> if (sink_request & DS_PORT_STATUS_CHANGED) {
> - /* same as unplugged */
> - hpd->hpd_high = 0;
> - dp->hpd_state = ST_DISCONNECT_PENDING;
> - dp_add_event(dp, EV_USER_NOTIFICATION, false, 0);
> - }
> -
> - rc = dp_display_handle_irq_hpd(dp);
> -
> - if (!rc && (sink_request & DS_PORT_STATUS_CHANGED)) {
> - hpd->hpd_high = 1;
> - dp->hpd_state = ST_CONNECT_PENDING;
> + if (dp_display_is_sink_count_zero(dp)) {
> + DRM_DEBUG_DP("sink count is zero, nothing to
> do\n");
> + if (dp->hpd_state != ST_DISCONNECTED) {
> + hpd->hpd_high = 0;
> + dp->hpd_state = ST_DISCONNECT_PENDING;
> + dp_add_event(dp,
> EV_USER_NOTIFICATION, false, 0);
> + }
> + rc = -ENOTCONN;
> + } else {
> + if (dp->hpd_state == ST_DISCONNECTED) {
> + hpd->hpd_high = 1;
This else and then if can be an else if, right?
> + dp->hpd_state = ST_CONNECT_PENDING;
> +
> + rc = dp_display_process_hpd_high(dp);
> + if (rc) {
> + hpd->hpd_high = 0;
> + dp->hpd_state =
> ST_DISCONNECTED;
> + }
> + }
> + }
> + } else {
> + if (!dp_display_is_ds_bridge(dp->panel))
> + rc = dp_display_handle_irq_hpd(dp);
> }
> }
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/ingenic: depend on COMMON_CLK to fix compile tests
Hi Krzysztof, Le lun. 16 nov. 2020 à 18:53, Krzysztof Kozlowski a écrit : The Ingenic DRM uses Common Clock Framework thus it cannot be built on platforms without it (e.g. compile test on MIPS with RALINK and SOC_RT305X): /usr/bin/mips-linux-gnu-ld: drivers/gpu/drm/ingenic/ingenic-drm-drv.o: in function `ingenic_drm_bind.isra.0': ingenic-drm-drv.c:(.text+0x1600): undefined reference to `clk_get_parent' /usr/bin/mips-linux-gnu-ld: ingenic-drm-drv.c:(.text+0x16b0): undefined reference to `clk_get_parent' Reported-by: kernel test robot Signed-off-by: Krzysztof Kozlowski Acked-by: Paul Cercueil Cheers, -Paul --- drivers/gpu/drm/ingenic/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/ingenic/Kconfig b/drivers/gpu/drm/ingenic/Kconfig index 477d5387e43e..3b57f8be007c 100644 --- a/drivers/gpu/drm/ingenic/Kconfig +++ b/drivers/gpu/drm/ingenic/Kconfig @@ -4,6 +4,7 @@ config DRM_INGENIC depends on DRM depends on CMA depends on OF + depends on COMMON_CLK select DRM_BRIDGE select DRM_PANEL_BRIDGE select DRM_KMS_HELPER -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] dt-bindings: display: panel: one file of all simple LVDS panels with dual ports
On Mon, 2020-11-16 at 13:23 -0600, Rob Herring wrote: > On Thu, Nov 12, 2020 at 02:17:11PM +0800, Liu Ying wrote: > > To complement panel-simple.yaml, create panel-simple-lvds-dual- > > ports.yaml. > > panel-simple-lvds-dual-ports.yaml is for all simple LVDS panels > > that > > have dual LVDS ports and require only a single power-supply. > > The first port receives odd pixels, and the second port receives > > even pixels. > > Optionally, a backlight and an enable GPIO can be specified as > > properties. > > > > Panels with swapped pixel order, if any, need dedicated bindings. > > > > Migrate 'auo,g133han01', 'auo,g185han01', 'auo,g190ean01', > > 'koe,tx26d202vm0bwa' and 'nlt,nl192108ac18-02d' over to the new > > file. > > > > The objectives with one file for all the simple LVDS panels with > > dual ports are: > > - Make it simpler to add bindings for this kind of LVDS panels > > - Keep the number of bindings file lower > > - Keep the binding documentation for this kind of LVDS panels more > > consistent > > - Make it possible for drivers to get pixel order via > > drm_of_lvds_get_dual_link_pixel_order(), as the optional 'ports' > > property is > > allowed > > > > Suggested-by: Sam Ravnborg > > Cc: Thierry Reding > > Cc: Sam Ravnborg > > Cc: David Airlie > > Cc: Daniel Vetter > > Cc: Rob Herring > > Cc: Lucas Stach > > Cc: Sebastian Reichel > > Signed-off-by: Liu Ying > > --- > > v2->v3: > > * Do not allow 'port' property. (Rob) > > * Define port number. (Rob) > > * Specify 'dual-lvds-odd-pixels' and 'dual-lvds-even-pixels' > > properties. (Rob) > > > > v1->v2: > > * Correct pixel order in example LVDS panel node. > > > > .../panel/panel-simple-lvds-dual-ports.yaml| 126 > > + > > .../bindings/display/panel/panel-simple.yaml | 10 -- > > 2 files changed, 126 insertions(+), 10 deletions(-) > > create mode 100644 > > Documentation/devicetree/bindings/display/panel/panel-simple-lvds- > > dual-ports.yaml > > > > diff --git a/Documentation/devicetree/bindings/display/panel/panel- > > simple-lvds-dual-ports.yaml > > b/Documentation/devicetree/bindings/display/panel/panel-simple- > > lvds-dual-ports.yaml > > new file mode 100644 > > index ..d30ae82 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/display/panel/panel-simple- > > lvds-dual-ports.yaml > > @@ -0,0 +1,126 @@ > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: > > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevicetree.org%2Fschemas%2Fdisplay%2Fpanel%2Fpanel-simple-lvds-dual-ports.yaml%23&data=04%7C01%7Cvictor.liu%40nxp.com%7Ce8617e47af5e4d939a3708d88a652499%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637411514310871830%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2F5Jad81MpVVoRLGbEGAka5S4walK1UpsE8y6PGsgLiw%3D&reserved=0 > > +$schema: > > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevicetree.org%2Fmeta-schemas%2Fcore.yaml%23&data=04%7C01%7Cvictor.liu%40nxp.com%7Ce8617e47af5e4d939a3708d88a652499%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637411514310871830%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3maA8Yc%2FoDzjSY2njq0bkM6%2FFo4J%2BFv0bEH4IbknM1w%3D&reserved=0 > > + > > +title: Simple LVDS panels with one power supply and dual LVDS > > ports > > + > > +maintainers: > > + - Liu Ying > > + - Thierry Reding > > + - Sam Ravnborg > > + > > +description: | > > + This binding file is a collection of the LVDS panels that > > + has dual LVDS ports and requires only a single power-supply. > > + The first port receives odd pixels, and the second port receives > > even pixels. > > + There are optionally a backlight and an enable GPIO. > > + The panel may use an OF graph binding for the association to the > > display, > > + or it may be a direct child node of the display. > > + > > + If the panel is more advanced a dedicated binding file is > > required. > > + > > +allOf: > > + - $ref: panel-common.yaml# > > + > > +properties: > > + > > + compatible: > > +enum: > > +# compatible must be listed in alphabetical order, ordered by > > compatible. > > +# The description in the comment is mandatory for each > > compatible. > > + > > +# AU Optronics Corporation 13.3" FHD (1920x1080) TFT LCD > > panel > > + - auo,g133han01 > > +# AU Optronics Corporation 18.5" FHD (1920x1080) TFT LCD > > panel > > + - auo,g185han01 > > +# AU Optronics Corporation 19.0" (1280x1024) TFT LCD panel > > + - auo,g190ean01 > > +# Kaohsiung Opto-Electronics Inc. 10.1" WUXGA (1920 x > > 1200) LVDS TFT LCD panel > > + - koe,tx26d202vm0bwa > > +# NLT Technologies, Ltd. 15.6" FHD (1920x1080) LVDS TFT > > LCD panel > > + - nlt,nl192108ac18-02d > > + > > + ports: > > +type: object > > +properties: > > + '#address-
[PATCH] drm/msm/dpu: Fix error return code in dpu_mdss_init()
Fix to return a negative error code from the error handling case
instead of 0 in function dpu_mdss_init(), as done elsewhere in this
function.
Fixes: 070e64dc1bbc ("drm/msm/dpu: Convert to a chained irq chip")
Reported-by: Hulk Robot
Signed-off-by: Chen Zhou
---
drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
index cd4078807db1..6e600b4ca995 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
@@ -297,8 +297,10 @@ int dpu_mdss_init(struct drm_device *dev)
goto irq_domain_error;
irq = platform_get_irq(pdev, 0);
- if (irq < 0)
+ if (irq < 0) {
+ ret = irq;
goto irq_error;
+ }
irq_set_chained_handler_and_data(irq, dpu_mdss_irq,
dpu_mdss);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915/selftests: Fix wrong return value of perf_series_engines()
Zhang Xiaoxu writes:
> If intel context create failed, the perf_series_engines() will return 0
> rather than error, because we doesn't initialize the return value.
>
> Fixes: cbfd3a0c5a55 ("drm/i915/selftests: Add request throughput measurement
> to perf")
> Reported-by: Hulk Robot
> Signed-off-by: Zhang Xiaoxu
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/selftests/i915_request.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/selftests/i915_request.c
> b/drivers/gpu/drm/i915/selftests/i915_request.c
> index 6b512fc13ca7..e424a6d1a68c 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_request.c
> +++ b/drivers/gpu/drm/i915/selftests/i915_request.c
> @@ -2469,8 +2469,10 @@ static int perf_series_engines(void *arg)
> struct intel_context *ce;
>
> ce = intel_context_create(engine);
> - if (IS_ERR(ce))
> + if (IS_ERR(ce)) {
> + err = PTR_ERR(ce);
> goto out;
> + }
>
> err = intel_context_pin(ce);
> if (err) {
> --
> 2.25.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 00/56] Convert DSI code to use drm_mipi_dsi and drm_panel
Hi Tomi, I hope you had a good weekend. And I have added back the CC: list because I think we have progress after our internal discussion and only one issue remaining. > Am 13.11.2020 um 15:49 schrieb Tomi Valkeinen : > > On 13/11/2020 16:41, H. Nikolaus Schaller wrote: >> Hi Tomi, >> >>> Am 13.11.2020 um 14:38 schrieb Tomi Valkeinen : >>> >>> On 13/11/2020 15:35, H. Nikolaus Schaller wrote: >>> So I'd say dsi_vc_send_short() fails if dsi_vc_enable_hs(0, 0) and not dsi_vc_enable_hs(0, 1) >>> >>> Oh, forgot to mention this: remove MIPI_DSI_MODE_LPM from the panel driver. >> >> Yes! This makes sending the init sequence work. >> >> I just have failures from w677l_read() but that may be the panel driver >> wrapper code. > > Ok, great! It would be good to have reads working too. I have fixed it. The call to mipi_dsi_dcs_read() was wrong. > That way we can know for sure if the commands > go back and forth correctly (e.g. verify the panel version ID). I can now read registers. Panel version ID is nonsense but I know that it was before. Maybe they did not flash it during production since I only read 0x40,0x00,0x00. But we can read it. > >> If I remove all read commands (they are not necessary for operation), there >> are no error >> messages and everything succeeds. I have a /dev/fb0. >> >> But I have no picture yet. >> >> Initially I thought that it was just the missing code to handle an external >> PWM backlight. >> But even with (and backlight working), I have just a framebuffer with black >> screen. >> >> Anyways, I think we are very close. And this is a great step forwards so >> that I need a >> break... >> >> Maybe I manage to consolidate the panel driver code before v5.10-rc4 >> arrives. This >> would give a freshly merged letux tree. > > Usually backlight glow is visible even if there's no picture. Well, it did not turn the PWM on at all. Now this works as well. Still I have no picture. But the readout of the register 0x45 (scan line) shows varying values. Therefore I think the vsync is running and incrementing the scan line counter. > But a comparison between the old, working driver, with dsi debugs enabled, > may give some hints. A > DISPC & DSI reg dump for both cases may also give hints. I have a script to mount debugfs and dump registers. Results are attached. Significant difference seem to be in: DISPC_TIMING_H(LCD) DSI_CLK_CTRL DSI_VM_TIMING1 DSI_VM_TIMING6 DSI_VC_CTRL(0) DSI_VC_CTRL(1) DSI_DSIPHY_CFG2 The consolidated panel driver code is here: https://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/letux/boe-w677-dsi-panel-v2 Well, not yet clean for upstreaming but functionally much better than before. What I have hacked is to mask out MIPI_DSI_MODE_LPM in mipi_dsi_attach(). This can/will be replaced if your series can handle it. BR, Nikolaus root@letux:~# ./debugdsi - DSS - FCK = 19200 - DISPC - dispc fclk source = FCK fck 19200 - DISPC-CORE-CLK - lck 19200 lck div 1 - LCD - LCD clk source = PLL1:1 lck 15360 lck div 1 pck 7680pck div 2 - LCD2 - LCD2 clk source = FCK lck 4800lck div 4 pck 4800pck div 1 - LCD3 - LCD3 clk source = FCK lck 4800lck div 4 pck 4800pck div 1 DISPC_REVISION 0051 DISPC_SYSCONFIG2015 DISPC_SYSSTATUS0001 DISPC_IRQSTATUS00a2 DISPC_IRQENABLE0812d640 DISPC_CONTROL 00018309 DISPC_CONFIG 020c DISPC_CAPABLE DISPC_LINE_STATUS 03e3 DISPC_LINE_NUMBER DISPC_GLOBAL_ALPHA DISPC_CONTROL2 DISPC_CONFIG2 DISPC_CONTROL3 DISPC_CONFIG3 DISPC_GLOBAL_MFLAG_ATTRIBUTE 0001 DISPC_DEFAULT_COLOR(LCD) DISPC_TRANS_COLOR(LCD) DISPC_SIZE_MGR(LCD)04ff02cf DISPC_TIMING_H(LCD)0040a100 DISPC_TIMING_V(LCD)0320323b DISPC_POL_FREQ(LCD)0006 DISPC_DIVISORo(LCD)00010002 DISPC_DATA_CYCLE1(LCD) DISPC_DATA_CYCLE2(LCD) DISPC_DATA_CYCLE3(LCD) DISPC_CPR_COEF_R(LCD)
Re: [PATCH] drm/i915/selftests: Fix wrong return value of perf_request_latency()
Zhang Xiaoxu writes:
> If intel context create failed, the perf_request_latency() will return 0
> rather than error, because we doesn't initialize the return value.
>
> Fixes: 25c26f18ea79 ("drm/i915/selftests: Measure dispatch latency")
> Reported-by: Hulk Robot
> Signed-off-by: Zhang Xiaoxu
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/selftests/i915_request.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/selftests/i915_request.c
> b/drivers/gpu/drm/i915/selftests/i915_request.c
> index 64bbb8288249..6b512fc13ca7 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_request.c
> +++ b/drivers/gpu/drm/i915/selftests/i915_request.c
> @@ -2293,8 +2293,10 @@ static int perf_request_latency(void *arg)
> struct intel_context *ce;
>
> ce = intel_context_create(engine);
> - if (IS_ERR(ce))
> + if (IS_ERR(ce)) {
> + err = PTR_ERR(ce);
> goto out;
> + }
>
> err = intel_context_pin(ce);
> if (err) {
> --
> 2.25.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC v6 4/6] drm/sprd: add Unisoc's drm display controller driver
Hi Sam, Here is feedback of RFC V7 Sam Ravnborg 于2020年7月29日周三 上午5:14写道： > > Hi Kevin. > > Some feedback in the following. > I lost track of thing for the atomic modesettting stuff and I hope other > will review that. > > Sam > > On Tue, Jul 28, 2020 at 06:07:57PM +0800, Kevin Tang wrote: > > From: Kevin Tang > > > > Adds DPU(Display Processor Unit) support for the Unisoc's display subsystem. > > It's support multi planes, scaler, rotation, PQ(Picture Quality) and more. > > > > RFC v6: > > - Access registers via readl/writel > > - Checking for unsupported KMS properties (format, rotation, blend_mode, > > etc) on plane_check ops > > - Remove always true checks for dpu core ops > > > > Cc: Orson Zhai > > Cc: Chunyan Zhang > > Signed-off-by: Kevin Tang > > --- > > drivers/gpu/drm/sprd/Makefile | 5 +- > > drivers/gpu/drm/sprd/dpu/Makefile | 3 + > > drivers/gpu/drm/sprd/dpu/dpu_r2p0.c | 503 > > drivers/gpu/drm/sprd/sprd_dpu.c | 646 > > > > drivers/gpu/drm/sprd/sprd_dpu.h | 187 +++ > > drivers/gpu/drm/sprd/sprd_drm.c | 1 + > > drivers/gpu/drm/sprd/sprd_drm.h | 2 + > > 7 files changed, 1346 insertions(+), 1 deletion(-) > > create mode 100644 drivers/gpu/drm/sprd/dpu/Makefile > > create mode 100644 drivers/gpu/drm/sprd/dpu/dpu_r2p0.c > > create mode 100644 drivers/gpu/drm/sprd/sprd_dpu.c > > create mode 100644 drivers/gpu/drm/sprd/sprd_dpu.h > > > > diff --git a/drivers/gpu/drm/sprd/Makefile b/drivers/gpu/drm/sprd/Makefile > > index 86d95d9..88ab32a 100644 > > --- a/drivers/gpu/drm/sprd/Makefile > > +++ b/drivers/gpu/drm/sprd/Makefile > > @@ -2,4 +2,7 @@ > > > > subdir-ccflags-y += -I$(srctree)/$(src) > Not needed - drop. It has been fixed on RFC V7. > > > > > -obj-y := sprd_drm.o > > +obj-y := sprd_drm.o \ > > + sprd_dpu.o > > + > > +obj-y += dpu/ > > Until there are several DPU's there is no need for a separate directory. > Make it simpler by keeping it all in drm/sprd/* It has been fixed on RFC V7. > > > diff --git a/drivers/gpu/drm/sprd/dpu/Makefile > > b/drivers/gpu/drm/sprd/dpu/Makefile > > new file mode 100644 > > index 000..40278b6 > > --- /dev/null > > +++ b/drivers/gpu/drm/sprd/dpu/Makefile > > @@ -0,0 +1,3 @@ > > +# SPDX-License-Identifier: GPL-2.0 > > + > > +obj-y += dpu_r2p0.o > > diff --git a/drivers/gpu/drm/sprd/dpu/dpu_r2p0.c > > b/drivers/gpu/drm/sprd/dpu/dpu_r2p0.c > > new file mode 100644 > > index 000..4b9521d > > --- /dev/null > > +++ b/drivers/gpu/drm/sprd/dpu/dpu_r2p0.c > > @@ -0,0 +1,503 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +/* > > + * Copyright (C) 2020 Unisoc Inc. > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > + > > +#include "sprd_dpu.h" > > + > > +/* DPU registers size, 4 Bytes(32 Bits) */ > > +#define DPU_REG_SIZE 0x04 > > + > > +/* Layer registers offset */ > > +#define DPU_LAY_REG_OFFSET 0x0C > > + > > +#define DPU_LAY_REG(reg, index) \ > > + (reg + index * DPU_LAY_REG_OFFSET * DPU_REG_SIZE) > Use a static inline to get better typecheck. It has been fixed on RFC V7. > > > +#define DPU_REG_RD(reg) readl_relaxed(reg) > > + > > +#define DPU_REG_WR(reg, mask) writel_relaxed(mask, reg) > > + > > +#define DPU_REG_SET(reg, mask) \ > > + writel_relaxed(readl_relaxed(reg) | mask, reg) > > + > > +#define DPU_REG_CLR(reg, mask) \ > > + writel_relaxed(readl_relaxed(reg) & ~mask, reg) > I am no fan of macros used like this. > > Maybe use static inlines and add struct dpu_context * as first argument. > Then adding base can be hidden away. It has been fixed on RFC V7. > > > I had a hard time convincing myself that _relaxed was the right > variants. If I get it correct we may see writes re-ordered with the > _relaxed variants wich would be no good when dealign with interrupts. > But I may miss somethign here. I need to think about it > > > + > > +/* Global control registers */ > > +#define REG_DPU_CTRL 0x04 > > +#define REG_DPU_CFG0 0x08 > > +#define REG_DPU_CFG1 0x0C > > +#define REG_DPU_CFG2 0x10 > > +#define REG_PANEL_SIZE 0x20 > > +#define REG_BLEND_SIZE 0x24 > > +#define REG_BG_COLOR 0x2C > > + > > +/* Layer0 control registers */ > > +#define REG_LAY_BASE_ADDR0 0x30 > > +#define REG_LAY_BASE_ADDR1 0x34 > > +#define REG_LAY_BASE_ADDR2 0x38 > > +#define REG_LAY_CTRL 0x40 > > +#define REG_LAY_SIZE 0x44 > > +#define REG_LAY_PITCH0x48 > > +#define REG_LAY_POS 0x4C > > +#define REG_LAY_ALPHA0x50 > > +#define REG_LAY_PALLETE 0x58 > > +#define REG_LAY_CROP_START 0x5C > > + > > +/* Interrupt control registers */ > > +#define REG_DPU_INT_EN 0x1E0 > > +#define REG_DPU_INT_CLR 0x1E4 > > +#define REG_DPU_INT_STS 0x1E8 > > + > > +/* DPI control registers */ > > +#define REG_DPI_CTRL 0x1F0 > > +#define REG_DPI_H_TIMING 0x1F4 > > +#define REG_DPI_V_TIMING 0x1
[PATCH] drm/msm: Fix error return code in msm_drm_init()
When it fail to create crtc_event kthread, it just jump to err_msm_uninit,
while the 'ret' is not updated. So assign the return code before that.
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Reported-by: Hulk Robot
Signed-off-by: Wei Li
---
drivers/gpu/drm/msm/msm_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 49685571dc0e..37a373c5ced3 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -506,6 +506,7 @@ static int msm_drm_init(struct device *dev, struct
drm_driver *drv)
"crtc_event:%d", priv->event_thread[i].crtc_id);
if (IS_ERR(priv->event_thread[i].worker)) {
DRM_DEV_ERROR(dev, "failed to create crtc_event
kthread\n");
+ ret = PTR_ERR(priv->event_thread[i].worker);
goto err_msm_uninit;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND v7, PATCH 4/7] mtk-mmsys: add mt8183 mmsys support
On Sat, Aug 8, 2020 at 2:53 AM Yongqiang Niu wrote:
>
> add mt8183 mmsys support
>
> Signed-off-by: Yongqiang Niu
> ---
> drivers/soc/mediatek/mmsys/Makefile | 1 +
> drivers/soc/mediatek/mmsys/mt8183-mmsys.c | 154
> ++
> drivers/soc/mediatek/mtk-mmsys.c | 1 +
> 3 files changed, 156 insertions(+)
> create mode 100644 drivers/soc/mediatek/mmsys/mt8183-mmsys.c
>
> diff --git a/drivers/soc/mediatek/mmsys/Makefile
> b/drivers/soc/mediatek/mmsys/Makefile
> index 33b0dab..62cfedf 100644
> --- a/drivers/soc/mediatek/mmsys/Makefile
> +++ b/drivers/soc/mediatek/mmsys/Makefile
> @@ -1,2 +1,3 @@
> # SPDX-License-Identifier: GPL-2.0-only
> obj-y += mt2701-mmsys.o
> +obj-y += mt8183-mmsys.o
> diff --git a/drivers/soc/mediatek/mmsys/mt8183-mmsys.c
> b/drivers/soc/mediatek/mmsys/mt8183-mmsys.c
> new file mode 100644
> index 000..e5170b5
> --- /dev/null
> +++ b/drivers/soc/mediatek/mmsys/mt8183-mmsys.c
> @@ -0,0 +1,154 @@
> +// SPDX-License-Identifier: GPL-2.0
> +//
> +// Copyright (c) 2020 MediaTek Inc.
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define DISP_OVL0_MOUT_EN 0xf00
> +#define DISP_OVL0_2L_MOUT_EN 0xf04
> +#define DISP_OVL1_2L_MOUT_EN 0xf08
> +#define DISP_DITHER0_MOUT_EN 0xf0c
> +#define DISP_PATH0_SEL_IN 0xf24
> +#define DISP_DSI0_SEL_IN 0xf2c
> +#define DISP_DPI0_SEL_IN 0xf30
> +#define DISP_RDMA0_SOUT_SEL_IN 0xf50
> +#define DISP_RDMA1_SOUT_SEL_IN 0xf54
> +
> +#define OVL0_MOUT_EN_OVL0_2L BIT(4)
> +#define OVL0_2L_MOUT_EN_DISP_PATH0 BIT(0)
> +#define OVL1_2L_MOUT_EN_RDMA1 BIT(4)
> +#define DITHER0_MOUT_IN_DSI0 BIT(0)
> +#define DISP_PATH0_SEL_IN_OVL0_2L 0x1
> +#define DSI0_SEL_IN_RDMA0 0x1
> +#define DSI0_SEL_IN_RDMA1 0x3
> +#define DPI0_SEL_IN_RDMA0 0x1
> +#define DPI0_SEL_IN_RDMA1 0x2
> +#define RDMA0_SOUT_COLOR0 0x1
> +#define RDMA1_SOUT_DSI00x1
> +
> +struct mmsys_path_sel {
> + enum mtk_ddp_comp_id cur;
> + enum mtk_ddp_comp_id next;
> + u32 addr;
> + u32 val;
> +};
> +
> +static struct mmsys_path_sel mmsys_mout_en[] = {
> + {
> + DDP_COMPONENT_OVL0, DDP_COMPONENT_OVL_2L0,
> + DISP_OVL0_MOUT_EN, OVL0_MOUT_EN_OVL0_2L,
> + },
> + {
> + DDP_COMPONENT_OVL_2L0, DDP_COMPONENT_RDMA0,
> + DISP_OVL0_2L_MOUT_EN, OVL0_2L_MOUT_EN_DISP_PATH0,
> + },
> + {
> + DDP_COMPONENT_OVL_2L1, DDP_COMPONENT_RDMA1,
> + DISP_OVL1_2L_MOUT_EN, OVL1_2L_MOUT_EN_RDMA1,
> + },
> + {
> + DDP_COMPONENT_DITHER, DDP_COMPONENT_DSI0,
> + DISP_DITHER0_MOUT_EN, DITHER0_MOUT_IN_DSI0,
> + },
> +};
> +
> +static struct mmsys_path_sel mmsys_sel_in[] = {
> + {
> + DDP_COMPONENT_OVL_2L0, DDP_COMPONENT_RDMA0,
> + DISP_PATH0_SEL_IN, DISP_PATH0_SEL_IN_OVL0_2L,
> + },
> + {
> + DDP_COMPONENT_RDMA1, DDP_COMPONENT_DPI0,
> + DISP_DPI0_SEL_IN, DPI0_SEL_IN_RDMA1,
> + },
> +};
> +
> +static struct mmsys_path_sel mmsys_sout_sel[] = {
> + {
> + DDP_COMPONENT_RDMA0, DDP_COMPONENT_COLOR0,
> + DISP_RDMA0_SOUT_SEL_IN, RDMA0_SOUT_COLOR0,
> + },
> +};
> +
> +static unsigned int mtk_mmsys_ddp_mout_en(enum mtk_ddp_comp_id cur,
> + enum mtk_ddp_comp_id next,
> + unsigned int *addr)
> +{
> + u32 i;
> + struct mmsys_path_sel *path;
> +
> + for (i = 0; i < ARRAY_SIZE(mmsys_mout_en); i++) {
> + path = &mmsys_mout_en[i];
> + if (cur == path->cur && next == path->next) {
> + *addr = path->addr;
> + return path->val;
> + }
> + }
> +
> + return 0;
> +}
> +
> +static unsigned int mtk_mmsys_ddp_sel_in(enum mtk_ddp_comp_id cur,
> +enum mtk_ddp_comp_id next,
> +unsigned int *addr)
> +{
> + u32 i;
> + struct mmsys_path_sel *path;
> +
> + for (i = 0; i < ARRAY_SIZE(mmsys_sel_in); i++) {
> + path = &mmsys_sel_in[i];
> + if (cur == path->cur && next == path->next) {
> + *addr = path->addr;
> + return path->val;
> + }
> + }
> +
> + return 0;
> +}
> +
> +static void mtk_mmsys_ddp_sout_sel(void __iomem *config_regs,
> + enum mtk_ddp_comp_id cur,
> + enum mtk_ddp_comp_id next)
> +{
> + u32 i;
> + u32 val = 0;
This variable is
Re: [PATCH 2/4] drm/meson: Unbind all connectors on module removal
On 16/11/2020 21:07, Marc Zyngier wrote:
> Removing the meson DRM module results in the following splats:
>
> [ 42.689228] WARNING: CPU: 0 PID: 572 at drivers/gpu/drm/drm_irq.c:192
> drm_irq_uninstall+0x130/0x160 [drm]
> [...]
> [ 42.812820] Hardware name: , BIOS 2021.01-rc2-00012-gde865f7ee1 11/16/2020
> [ 42.819723] pstate: 80400089 (Nzcv daIf +PAN -UAO -TCO BTYPE=--)
> [ 42.825737] pc : drm_irq_uninstall+0x130/0x160 [drm]
> [ 42.830647] lr : drm_irq_uninstall+0xc4/0x160 [drm]
> [...]
> [ 42.917614] Call trace:
> [ 42.920086] drm_irq_uninstall+0x130/0x160 [drm]
> [ 42.924612] meson_drv_unbind+0x68/0xa4 [meson_drm]
> [ 42.929436] component_del+0xc0/0x180
> [ 42.933058] meson_dw_hdmi_remove+0x28/0x40 [meson_dw_hdmi]
> [ 42.938576] platform_drv_remove+0x38/0x60
> [ 42.942628] __device_release_driver+0x190/0x23c
> [ 42.947198] driver_detach+0xcc/0x160
> [ 42.950822] bus_remove_driver+0x68/0xe0
> [ 42.954702] driver_unregister+0x3c/0x6c
> [ 42.958583] platform_driver_unregister+0x20/0x2c
> [ 42.963243] meson_dw_hdmi_platform_driver_exit+0x18/0x4a8 [meson_dw_hdmi]
> [ 42.970057] __arm64_sys_delete_module+0x1bc/0x294
> [ 42.974801] el0_svc_common.constprop.0+0x80/0x240
> [ 42.979542] do_el0_svc+0x30/0xa0
> [ 42.982821] el0_svc+0x18/0x50
> [ 42.985839] el0_sync_handler+0x198/0x404
> [ 42.989806] el0_sync+0x158/0x180
>
> immediatelly followed by
>
> [ 43.002296] WARNING: CPU: 0 PID: 572 at
> drivers/gpu/drm/drm_mode_config.c:504 drm_mode_config_cleanup+0x2a8/0x304
> [drm]
> [...]
> [ 43.128150] Hardware name: , BIOS 2021.01-rc2-00012-gde865f7ee1 11/16/2020
> [ 43.135052] pstate: 8049 (Nzcv daif +PAN -UAO -TCO BTYPE=--)
> [ 43.141062] pc : drm_mode_config_cleanup+0x2a8/0x304 [drm]
> [ 43.146492] lr : drm_mode_config_cleanup+0xac/0x304 [drm]
> [...]
> [ 43.233979] Call trace:
> [ 43.236451] drm_mode_config_cleanup+0x2a8/0x304 [drm]
> [ 43.241538] drm_mode_config_init_release+0x1c/0x2c [drm]
> [ 43.246886] drm_managed_release+0xa8/0x120 [drm]
> [ 43.251543] drm_dev_put+0x94/0xc0 [drm]
> [ 43.255380] meson_drv_unbind+0x78/0xa4 [meson_drm]
> [ 43.260204] component_del+0xc0/0x180
> [ 43.263829] meson_dw_hdmi_remove+0x28/0x40 [meson_dw_hdmi]
> [ 43.269344] platform_drv_remove+0x38/0x60
> [ 43.273398] __device_release_driver+0x190/0x23c
> [ 43.277967] driver_detach+0xcc/0x160
> [ 43.281590] bus_remove_driver+0x68/0xe0
> [ 43.285471] driver_unregister+0x3c/0x6c
> [ 43.289352] platform_driver_unregister+0x20/0x2c
> [ 43.294011] meson_dw_hdmi_platform_driver_exit+0x18/0x4a8 [meson_dw_hdmi]
> [ 43.300826] __arm64_sys_delete_module+0x1bc/0x294
> [ 43.305570] el0_svc_common.constprop.0+0x80/0x240
> [ 43.310312] do_el0_svc+0x30/0xa0
> [ 43.313590] el0_svc+0x18/0x50
> [ 43.316608] el0_sync_handler+0x198/0x404
> [ 43.320574] el0_sync+0x158/0x180
> [ 43.323852] ---[ end trace d796a3072dab01da ]---
> [ 43.328561] [drm:drm_mode_config_cleanup [drm]] *ERROR* connector HDMI-A-1
> leaked!
>
> both triggered by the fact that the HDMI subsystem is still active,
> and the DRM removal doesn't result in the connectors being torn down.
>
> Call drm_atomic_helper_shutdown() and component_unbind_all() to safely
> tear the module down.
>
> Signed-off-by: Marc Zyngier
Fixes: 2d8f92897ad8 ("drm/meson: Uninstall IRQ handler")
> ---
> drivers/gpu/drm/meson/meson_drv.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/meson/meson_drv.c
> b/drivers/gpu/drm/meson/meson_drv.c
> index 324fa489f1c4..3d1de9cbb1c8 100644
> --- a/drivers/gpu/drm/meson/meson_drv.c
> +++ b/drivers/gpu/drm/meson/meson_drv.c
> @@ -390,8 +390,10 @@ static void meson_drv_unbind(struct device *dev)
> }
>
> drm_dev_unregister(drm);
> - drm_irq_uninstall(drm);
> drm_kms_helper_poll_fini(drm);
> + drm_atomic_helper_shutdown(drm);
> + component_unbind_all(dev, drm);
> + drm_irq_uninstall(drm);
> drm_dev_put(drm);
>
> if (priv->afbcd.ops) {
>
Acked-by: Neil Armstrong
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] drm/meson: dw-hdmi: Register a callback to disable the regulator
On 16/11/2020 21:07, Marc Zyngier wrote:
> Removing the meson-dw-hdmi module results in the following splat:
>
> i[ 43.340509] WARNING: CPU: 0 PID: 572 at drivers/regulator/core.c:2125
> _regulator_put.part.0+0x16c/0x174
> [...]
> [ 43.454870] CPU: 0 PID: 572 Comm: modprobe Tainted: GW E
> 5.10.0-rc4-00049-gd274813a4de3-dirty #2147
> [ 43.465042] Hardware name: , BIOS 2021.01-rc2-00012-gde865f7ee1 11/16/2020
> [ 43.471945] pstate: 8049 (Nzcv daif +PAN -UAO -TCO BTYPE=--)
> [ 43.477896] pc : _regulator_put.part.0+0x16c/0x174
> [ 43.482638] lr : regulator_put+0x44/0x60
> [...]
> [ 43.568715] Call trace:
> [ 43.571132] _regulator_put.part.0+0x16c/0x174
> [ 43.575529] regulator_put+0x44/0x60
> [ 43.579067] devm_regulator_release+0x20/0x2c
> [ 43.583380] release_nodes+0x1c8/0x2b4
> [ 43.587087] devres_release_all+0x44/0x6c
> [ 43.591056] __device_release_driver+0x1a0/0x23c
> [ 43.595626] driver_detach+0xcc/0x160
> [ 43.599249] bus_remove_driver+0x68/0xe0
> [ 43.603130] driver_unregister+0x3c/0x6c
> [ 43.607011] platform_driver_unregister+0x20/0x2c
> [ 43.611678] meson_dw_hdmi_platform_driver_exit+0x18/0x4a8 [meson_dw_hdmi]
> [ 43.618485] __arm64_sys_delete_module+0x1bc/0x294
>
> as the HDMI regulator is still enabled on release.
>
> In order to address this, register a callback that will deal with
> the disabling when the driver is unbound, solving the problem.
>
> Signed-off-by: Marc Zyngier
Fixes: 161a803fe32d ("drm/meson: dw_hdmi: Add support for an optional external
5V regulator")
> ---
> drivers/gpu/drm/meson/meson_dw_hdmi.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c
> b/drivers/gpu/drm/meson/meson_dw_hdmi.c
> index 29a8ff41595d..68826cf9993f 100644
> --- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
> +++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
> @@ -941,6 +941,11 @@ static void meson_dw_hdmi_init(struct meson_dw_hdmi
> *meson_dw_hdmi)
>
> }
>
> +static void meson_disable_regulator(void *data)
> +{
> + regulator_disable(data);
> +}
> +
> static int meson_dw_hdmi_bind(struct device *dev, struct device *master,
> void *data)
> {
> @@ -989,6 +994,10 @@ static int meson_dw_hdmi_bind(struct device *dev, struct
> device *master,
> ret = regulator_enable(meson_dw_hdmi->hdmi_supply);
> if (ret)
> return ret;
> + ret = devm_add_action_or_reset(dev, meson_disable_regulator,
> +meson_dw_hdmi->hdmi_supply);
> + if (ret)
> + return ret;
> }
>
> meson_dw_hdmi->hdmitx_apb = devm_reset_control_get_exclusive(dev,
>
Acked-by: Neil Armstrong
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] drm/meson: dw-hdmi: Ensure that clocks are enabled before touching the TOP registers
On 16/11/2020 21:07, Marc Zyngier wrote:
> Removing the meson-dw-hdmi module and re-inserting it results in a hang
> as the driver writes to HDMITX_TOP_SW_RESET. Similar effects can be seen
> when booting with mainline u-boot and using the u-boot provided DT (which
> is highly desirable).
>
> The reason for the hang seem to be that the clocks are not always
> enabled by the time we enter meson_dw_hdmi_init(). Moving this call
> *after* dw_hdmi_probe() ensures that the clocks are enabled.
>
> Signed-off-by: Marc Zyngier
Fixes: 1374b8375c2e ("drm/meson: dw_hdmi: add resume/suspend hooks")
> ---
> drivers/gpu/drm/meson/meson_dw_hdmi.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c
> b/drivers/gpu/drm/meson/meson_dw_hdmi.c
> index 68826cf9993f..7f8eea494147 100644
> --- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
> +++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
> @@ -1073,8 +1073,6 @@ static int meson_dw_hdmi_bind(struct device *dev,
> struct device *master,
>
> DRM_DEBUG_DRIVER("encoder initialized\n");
>
> - meson_dw_hdmi_init(meson_dw_hdmi);
> -
> /* Bridge / Connector */
>
> dw_plat_data->priv_data = meson_dw_hdmi;
> @@ -1097,6 +1095,8 @@ static int meson_dw_hdmi_bind(struct device *dev,
> struct device *master,
> if (IS_ERR(meson_dw_hdmi->hdmi))
> return PTR_ERR(meson_dw_hdmi->hdmi);
>
> + meson_dw_hdmi_init(meson_dw_hdmi);
> +
> next_bridge = of_drm_find_bridge(pdev->dev.of_node);
> if (next_bridge)
> drm_bridge_attach(encoder, next_bridge,
>
Acked-by: Neil Armstrong
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/4] drm/meson: Module removal fixes
Hi Neil,
On 2020-11-17 08:49, Neil Armstrong wrote:
Hi Marc,
On 16/11/2020 21:07, Marc Zyngier wrote:
Hi all,
Having recently moved over to a top-of-the-tree u-boot on one of my
VIM3L systems in order to benefit from unrelated improvements
(automatic PCIe detection, EFI...), I faced the issue that my kernel
would hang like this:
[ OK ] Finished Helper to synchronize boot up for ifupdown.
[ OK ] Started Rule-based Manager for Device Events and Files.
[7.114516] VDDCPU: supplied by regulator-dummy
[ OK ] Found device /dev/ttyAML0.
[7.146862] meson-drm ff90.vpu: Queued 2 outputs on vpu
[7.169630] fb0: switching to meson-drm-fb from simple
[7.169944] Console: switching to colour dummy device 80x25
[7.179250] meson-drm ff90.vpu: CVBS Output connector not
available
and that's it.
After some poking around, I figured out that it is in the
meson-dw-hdmi module that the CPU was hanging...
I'll be interested in having your kernel config, I never had such
report
since I enabled HDMI support in U-Boot a few years ago.
Yeah, I was pretty surprised too. I have a hunch that this is caused
by u-boot DT exposing an extra MMIO region (dubbed "hhi") that gets
picked up by the kernel driver. *Not* having the region in the DT
(as in the kernel's version of the same DT) makes the driver work
exactly once:
Decompiled u-boot DT:
hdmi-tx@0 {
compatible = "amlogic,meson-g12a-dw-hdmi";
reg = <0x00 0x00 0x00 0x1 0x00 0x3c000 0x00 0x1000>;
[...]
reg-names = "hdmitx\0hhi";
Decompiled kernel DT:
hdmi-tx@0 {
compatible = "amlogic,meson-g12a-dw-hdmi";
reg = <0x00 0x00 0x00 0x1>;
There seem to be some complex interactions between the HDMI driver
and the DRM driver, both using this MMIO region at any given time.
But I admit not having tried very hard to follow the DRM maze of
intricate callbacks. All I needed was this box to reliably boot with
the firmware-provided DT.
You can find a reasonably recent version of my config at [1].
M.
[1] http://www.loen.fr/tmp/Config.full-arm64
--
Jazz is not dead. It just smells funny...
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dt-bindings: display: Use OF graph schema
Hi Rob, Thank you for the patch. On Mon, Nov 16, 2020 at 07:37:03PM -0600, Rob Herring wrote: > Now that we have a graph schema, rework the display related schemas to use > it. Mostly this is adding a reference to graph.yaml and dropping duplicate > parts from schemas. > > Cc: Thierry Reding > Cc: Sam Ravnborg > Cc: Laurent Pinchart > Cc: Maxime Ripard > Cc: Maarten Lankhorst > Cc: Thomas Zimmermann > Signed-off-by: Rob Herring > --- > graph.yaml is in the dtschema repo, so this can go into drm-misc and > hopefully anything afterwards be fixed up to use graph.yaml. > > .../allwinner,sun4i-a10-display-backend.yaml | 14 +--- > .../allwinner,sun4i-a10-display-frontend.yaml | 16 + > .../display/allwinner,sun4i-a10-hdmi.yaml | 16 + > .../display/allwinner,sun4i-a10-tcon.yaml | 16 + > .../allwinner,sun4i-a10-tv-encoder.yaml | 2 +- > .../display/allwinner,sun6i-a31-drc.yaml | 16 + > .../display/allwinner,sun6i-a31-mipi-dsi.yaml | 6 +- > .../allwinner,sun8i-a83t-de2-mixer.yaml | 16 + > .../display/allwinner,sun8i-a83t-dw-hdmi.yaml | 16 + > .../display/allwinner,sun8i-r40-tcon-top.yaml | 19 +- > .../display/allwinner,sun9i-a80-deu.yaml | 16 + > .../bindings/display/brcm,bcm2835-dpi.yaml| 7 +- > .../display/bridge/analogix,anx7625.yaml | 5 +- > .../display/bridge/analogix,anx7814.yaml | 18 + > .../bindings/display/bridge/anx6345.yaml | 15 ++-- > .../display/bridge/cdns,mhdp8546.yaml | 18 + > .../display/bridge/chrontel,ch7033.yaml | 3 + > .../display/bridge/intel,keembay-dsi.yaml | 9 +-- > .../bindings/display/bridge/ite,it6505.yaml | 2 +- > .../display/bridge/lontium,lt9611.yaml| 68 ++- > .../bindings/display/bridge/lvds-codec.yaml | 15 +--- > .../bindings/display/bridge/nwl-dsi.yaml | 17 + > .../bindings/display/bridge/ps8640.yaml | 21 ++ > .../bindings/display/bridge/renesas,lvds.yaml | 15 +--- > .../display/bridge/simple-bridge.yaml | 15 +--- > .../display/bridge/snps,dw-mipi-dsi.yaml | 5 +- > .../display/bridge/thine,thc63lvd1024.yaml| 16 + > .../bindings/display/bridge/ti,sn65dsi86.yaml | 27 +--- > .../bindings/display/bridge/ti,tfp410.yaml| 15 +--- > .../display/bridge/toshiba,tc358762.yaml | 51 ++ > .../display/bridge/toshiba,tc358768.yaml | 11 +-- > .../display/bridge/toshiba,tc358775.yaml | 17 ++--- > .../connector/analog-tv-connector.yaml| 1 + > .../display/connector/dvi-connector.yaml | 1 + > .../display/connector/hdmi-connector.yaml | 1 + > .../display/connector/vga-connector.yaml | 1 + > .../bindings/display/imx/nxp,imx8mq-dcss.yaml | 2 +- > .../bindings/display/ingenic,lcd.yaml | 7 +- > .../display/intel,keembay-display.yaml| 2 +- > .../display/panel/advantech,idk-2121wr.yaml | 5 ++ > .../bindings/display/panel/panel-common.yaml | 11 +-- > .../rockchip/rockchip,rk3066-hdmi.yaml| 13 +--- > .../display/rockchip/rockchip-vop.yaml| 5 +- > .../bindings/display/st,stm32-dsi.yaml| 13 ++-- > .../bindings/display/st,stm32-ltdc.yaml | 7 +- > .../bindings/display/ti/ti,am65x-dss.yaml | 16 + > .../bindings/display/ti/ti,j721e-dss.yaml | 18 + > .../bindings/display/ti/ti,k2g-dss.yaml | 4 +- > 48 files changed, 121 insertions(+), 509 deletions(-) > > diff --git > a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-backend.yaml > > b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-backend.yaml > index 86057d541065..7e8798b43c2a 100644 > --- > a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-backend.yaml > +++ > b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-backend.yaml > @@ -85,17 +85,9 @@ properties: > >ports: > type: object Do we need to specify the type here (and in all the locations below), give that it's specified in /schemas/graph.yaml#/properties/ports ? > -description: | > - A ports node with endpoint definitions as defined in > - Documentation/devicetree/bindings/media/video-interfaces.txt. > +$ref: /schemas/graph.yaml#/properties/ports > > properties: > - "#address-cells": > -const: 1 > - > - "#size-cells": > -const: 0 > - >port@0: > type: object > description: | > @@ -107,12 +99,10 @@ properties: >Output endpoints of the controller. > > required: > - - "#address-cells" > - - "#size-cells" >- port@0 >- port@1 > > -additionalProperties: false > +unevaluatedProperties: false > > required: >- compatible > diff --git > a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-frontend.yaml > > b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-frontend
Re: [PATCH 0/4] drm/meson: Module removal fixes
On 17/11/2020 10:19, Marc Zyngier wrote:
> Hi Neil,
>
> On 2020-11-17 08:49, Neil Armstrong wrote:
>> Hi Marc,
>>
>> On 16/11/2020 21:07, Marc Zyngier wrote:
>>> Hi all,
>>>
>>> Having recently moved over to a top-of-the-tree u-boot on one of my
>>> VIM3L systems in order to benefit from unrelated improvements
>>> (automatic PCIe detection, EFI...), I faced the issue that my kernel
>>> would hang like this:
>>>
>>> [ OK ] Finished Helper to synchronize boot up for ifupdown.
>>> [ OK ] Started Rule-based Manager for Device Events and Files.
>>> [ 7.114516] VDDCPU: supplied by regulator-dummy
>>> [ OK ] Found device /dev/ttyAML0.
>>> [ 7.146862] meson-drm ff90.vpu: Queued 2 outputs on vpu
>>> [ 7.169630] fb0: switching to meson-drm-fb from simple
>>> [ 7.169944] Console: switching to colour dummy device 80x25
>>> [ 7.179250] meson-drm ff90.vpu: CVBS Output connector not available
>>>
>>> and that's it.
>>>
>>> After some poking around, I figured out that it is in the
>>> meson-dw-hdmi module that the CPU was hanging...
>>
>> I'll be interested in having your kernel config, I never had such report
>> since I enabled HDMI support in U-Boot a few years ago.
>
> Yeah, I was pretty surprised too. I have a hunch that this is caused
> by u-boot DT exposing an extra MMIO region (dubbed "hhi") that gets
> picked up by the kernel driver. *Not* having the region in the DT
> (as in the kernel's version of the same DT) makes the driver work
> exactly once:
Yeah, we used this to simplify our u-boot driver, the bindings were missing this
memory space, it should be fixed at some point and stop relying on the
main drm driver to get this memory space.
>
> Decompiled u-boot DT:
>
> hdmi-tx@0 {
> compatible = "amlogic,meson-g12a-dw-hdmi";
> reg = <0x00 0x00 0x00 0x1 0x00 0x3c000 0x00 0x1000>;
> [...]
> reg-names = "hdmitx\0hhi";
>
> Decompiled kernel DT:
>
> hdmi-tx@0 {
> compatible = "amlogic,meson-g12a-dw-hdmi";
> reg = <0x00 0x00 0x00 0x1>;
>
> There seem to be some complex interactions between the HDMI driver
> and the DRM driver, both using this MMIO region at any given time.
> But I admit not having tried very hard to follow the DRM maze of
> intricate callbacks. All I needed was this box to reliably boot with
> the firmware-provided DT.
Yes, the HDMI stuff has some dependencies on the DRM display subsystem.
I plan to reorganize stuff but I lack time...
Anyway, thanks.
Applying to drm-misc-next
Neil
>
> You can find a reasonably recent version of my config at [1].
>
> M.
>
> [1] http://www.loen.fr/tmp/Config.full-arm64
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/qxl: Remove fbcon acceleration leftovers
On Thu, Oct 29, 2020 at 02:33:47PM +0100, Daniel Vetter wrote:
> These are leftovers from 13aff184ed9f ("drm/qxl: remove dead qxl fbdev
> emulation code").
>
> v2: Somehow these structs provided the struct qxl_device pre-decl,
> reorder the header to not anger compilers.
>
> Acked-by: Gerd Hoffmann
> Signed-off-by: Daniel Vetter
> Cc: Dave Airlie
> Cc: Gerd Hoffmann
> Cc: virtualizat...@lists.linux-foundation.org
> Cc: spice-de...@lists.freedesktop.org
Entire series applied to drm-misc-next.
-Daniel
> ---
> drivers/gpu/drm/qxl/qxl_drv.h | 18 ++
> 1 file changed, 2 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h
> index 3602e8b34189..6239626503ef 100644
> --- a/drivers/gpu/drm/qxl/qxl_drv.h
> +++ b/drivers/gpu/drm/qxl/qxl_drv.h
> @@ -166,20 +166,6 @@ struct qxl_drm_image {
> struct list_head chunk_list;
> };
>
> -struct qxl_fb_image {
> - struct qxl_device *qdev;
> - uint32_t pseudo_palette[16];
> - struct fb_image fb_image;
> - uint32_t visual;
> -};
> -
> -struct qxl_draw_fill {
> - struct qxl_device *qdev;
> - struct qxl_rect rect;
> - uint32_t color;
> - uint16_t rop;
> -};
> -
> /*
> * Debugfs
> */
> @@ -188,8 +174,6 @@ struct qxl_debugfs {
> unsigned int num_files;
> };
>
> -int qxl_debugfs_fence_init(struct qxl_device *rdev);
> -
> struct qxl_device {
> struct drm_device ddev;
>
> @@ -271,6 +255,8 @@ struct qxl_device {
>
> #define to_qxl(dev) container_of(dev, struct qxl_device, ddev)
>
> +int qxl_debugfs_fence_init(struct qxl_device *rdev);
> +
> extern const struct drm_ioctl_desc qxl_ioctls[];
> extern int qxl_max_ioctl;
>
> --
> 2.28.0
>
--
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 v3 30/56] drm/omap: dsi: move panel refresh function to host
Hi,
On Mon, Nov 16, 2020 at 11:22:53AM +0200, Laurent Pinchart wrote:
> On Thu, Nov 12, 2020 at 10:08:21AM +0200, Tomi Valkeinen wrote:
> > On 11/11/2020 17:58, Laurent Pinchart wrote:
> >
> > diff --git a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
> > b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
> > index 030a8fa140db..1582960f9e90 100644
> > --- a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
> > +++ b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
> > @@ -177,27 +177,6 @@ static int dsicm_get_id(struct panel_drv_data
> > *ddata, u8 *id1, u8 *id2, u8 *id3)
> > return 0;
> > }
> >
> > -static int dsicm_set_update_window(struct panel_drv_data *ddata,
> > - u16 x, u16 y, u16 w, u16 h)
> > -{
> > - struct mipi_dsi_device *dsi = ddata->dsi;
> > - int r;
> > - u16 x1 = x;
> > - u16 x2 = x + w - 1;
> > - u16 y1 = y;
> > - u16 y2 = y + h - 1;
> > -
> > - r = mipi_dsi_dcs_set_column_address(dsi, x1, x2);
> > - if (r < 0)
> > - return r;
> > -
> > - r = mipi_dsi_dcs_set_page_address(dsi, y1, y2);
> > - if (r < 0)
> > - return r;
> > -
> > - return 0;
> > -}
> > -
> > >>>
> > >>> I can't tell whether this is common to all command-mode panels, or if
> > >>> there could be a need for panel-specific update procedures, so I can't
> > >>> really ack this patch.
> > >>
> > >> I can't say either, but all the command mode panels I know need and
> > >> support this. And, afaik, we
> > >> have only the single cmd mode panel driver which we add in this series.
> > >
> > > Now that I think about it again, isn't it a layering violation ?
> > > Shouldn't the DSI host handle DSI commands transfers, with the panel
> > > driver taking care of specific DSI commands ?
> >
> > Well, the DSI host (the HW) already handles specific DSI commands, as it
> > does the update with DCS
> > Write Start/Continue commands. The update is initiated from omap_crtc, via
> > dssdev->dsi_ops->update().
> >
> > We could perhaps add a new function to drm_panel_funcs, say,
> > prepare_update, which could then do the
> > above.
> >
> > Although I think the above code is not strictly speaking required, as the
> > panel should remember the
> > column and page address, and as such, they could be set just once at config
> > time.
> >
> > However, I remember debugging issues related to this. And with a quick
> > test, I can see that things
> > break down if I just do the above once in the panel's setup. But things
> > work if I send a DSI NOP
> > instead in the dsi host. So looks to me that either the OMAP DSI or the
> > panel I have need some
> > command transmitted there. It probably has to happen between two frame
> > transfers.
> >
> > There are also other things related to update which I'm not so happy about:
> > 1) the TE gpio irq is
> > handled in the dsi host driver now, even if it's a panel gpio, 2) the dsi
> > host driver snoops the DSI
> > packets sent by the panel, and catches TEAR_ON/OFF packets, and then change
> > internal state accordingly.
> >
> > So... I could change the dsi host driver to only send a NOP, and do the
> > page/column call from the
> > panel's setup. That simplifies the code.
> >
> > Or I could add the new function to drm_panel_funcs, and send a NOP from
> > there. But if this "needs a
> > NOP" is an OMAP DSI feature, the panel driver is not the right place for
> > it. I also think that
> > managing the TE cleanly needs more thought, and probably requires some more
> > interaction between the
> > dsi host and the panel. It might be better to look at both the update
> > callback and the TE at the
> > same time.
>
> I'm fine addressing both issues on top of this series. My concern is
> that an incorrect split of responsibilities between the panel driver and
> the DSI host driver will result in panel drivers being compatible only
> with specific DSI hosts. It's a difficult issue, but I think we need to
> extend the DSI API to handle this cleanly.
Just some background info, since I looked into this while moving
the driver to the common drm/dsi infrastructure (I used existing
DSI drivers as reference):
IIRC most DSI host drivers do not seem support command mode at all.
Some seemed to support it from within the host driver, though. I
remember Exynos getting the TE gpio in the host driver and using
the IRQ routine to self-refresh (which would effectively always
refresh wasting lots of power compared to only refreshing on page
flip).
Also there are some command mode panel drivers (can be found by
looking for drivers _not_ setting the MIPI_DSI_MODE_VIDEO flag):
* panel-novatek-nt35510.c
* panel-samsung-s6d16d0.c
* panel-samsung-s6e63j0x03.c
* panel-samsung-s6e3ha2.c
* panel-sharp-lq101r1sx01.c
* panel-sony-acx424akp.c
So extendin
Re: [PATCH 02/30] include: drm: drm_atomic: Artificially use 'crtc' to avoid 'not used' warning
On Fri, Nov 13, 2020 at 10:01:57PM +, Lee Jones wrote: > On Fri, 13 Nov 2020, 21:31 Daniel Vetter, wrote: > > > On Fri, Nov 13, 2020 at 9:53 PM Lee Jones wrote: > > > > > > > > > > > > On Fri, 13 Nov 2020, 20:50 Daniel Vetter, wrote: > > >> > > >> On Thu, Nov 12, 2020 at 09:25:16PM +0100, Sam Ravnborg wrote: > > >> > Hi Lee, > > >> > > > >> > On Thu, Nov 12, 2020 at 07:00:11PM +, Lee Jones wrote: > > >> > > The precedent has already been set by other macros in the same file. > > >> > > > > >> > > Fixes the following W=1 kernel build warning(s): > > >> > > > > >> > > drivers/gpu/drm/vkms/vkms_drv.c:55:19: warning: variable ‘crtc’ > > set but not used [-Wunused-but-set-variable] > > >> > > 55 | struct drm_crtc *crtc; > > >> > > | ^~~~ > > >> > > > > >> > > Cc: Maarten Lankhorst > > >> > > Cc: Maxime Ripard > > >> > > Cc: Thomas Zimmermann > > >> > > Cc: David Airlie > > >> > > Cc: Daniel Vetter > > >> > > Cc: Rob Clark > > >> > > Cc: dri-devel@lists.freedesktop.org > > >> > > Signed-off-by: Lee Jones > > >> > > > >> > Also applied to drm-misc-next. > > >> > This was the last patch from this batch I will process. > > >> > The others are left for the maintainers to pick up. > > >> > > >> btw for patches that maintainers don't pick up, the usual process is > > that > > >> we give them 2 weeks, then just mass apply. Now you're producing a lot > > of > > >> patches, too much for me to keep track, so please just ping me with a > > >> resend for those that expired and I'll go through and pick them all up. > > > > > > > > > That's great Daniel. Thanks for your support. > > > > > > I can do one better than that. > > > > > > Would a pull-request suit you? > > > > We have a few trees going on, and your patches are landing through all > > kinds of them. So this might be more coordination pain. If you can > > exclude patches for the separately and usually fairly well maintained > > drivers out of the pull it should work (drm/amd, drm/radeon, drm/i915, > > drm/nouveau, drm/msm and drm/omapdrm probably the usual ones). > > > > Or you just send the next pile and we'll see. > > > > Also I guess I can't really interest you in commit rights so this > > patch bombs get off my back again? :-) > > > > What does that mean? Merge my own patches? > > Not sure how that works with your group maintenance setup. > > Is it just a `git push`? It's a bunch of scripting and setup, might not be worth it for just one of. Plus we still take pull requests from submaintainers so it's all just if you feel like it. Some docs if you're curious: https://drm.pages.freedesktop.org/maintainer-tools/getting-started.html Cheers, 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 02/30] include: drm: drm_atomic: Artificially use 'crtc' to avoid 'not used' warning
Daniel, For some reason, you're not appearing in the recipents list when I reply to all. You're not in the Mail-Followup-To header. Any idea why this might be? Anyway, please see below: On Tue, 17 Nov 2020, Daniel Vetter wrote: > On Fri, Nov 13, 2020 at 10:01:57PM +, Lee Jones wrote: > > On Fri, 13 Nov 2020, 21:31 Daniel Vetter, wrote: > > > > > On Fri, Nov 13, 2020 at 9:53 PM Lee Jones wrote: > > > > > > > > > > > > > > > > On Fri, 13 Nov 2020, 20:50 Daniel Vetter, wrote: > > > >> > > > >> On Thu, Nov 12, 2020 at 09:25:16PM +0100, Sam Ravnborg wrote: > > > >> > Hi Lee, > > > >> > > > > >> > On Thu, Nov 12, 2020 at 07:00:11PM +, Lee Jones wrote: > > > >> > > The precedent has already been set by other macros in the same > > > >> > > file. > > > >> > > > > > >> > > Fixes the following W=1 kernel build warning(s): > > > >> > > > > > >> > > drivers/gpu/drm/vkms/vkms_drv.c:55:19: warning: variable ‘crtc’ > > > set but not used [-Wunused-but-set-variable] > > > >> > > 55 | struct drm_crtc *crtc; > > > >> > > | ^~~~ > > > >> > > > > > >> > > Cc: Maarten Lankhorst > > > >> > > Cc: Maxime Ripard > > > >> > > Cc: Thomas Zimmermann > > > >> > > Cc: David Airlie > > > >> > > Cc: Daniel Vetter > > > >> > > Cc: Rob Clark > > > >> > > Cc: dri-devel@lists.freedesktop.org > > > >> > > Signed-off-by: Lee Jones > > > >> > > > > >> > Also applied to drm-misc-next. > > > >> > This was the last patch from this batch I will process. > > > >> > The others are left for the maintainers to pick up. > > > >> > > > >> btw for patches that maintainers don't pick up, the usual process is > > > that > > > >> we give them 2 weeks, then just mass apply. Now you're producing a lot > > > of > > > >> patches, too much for me to keep track, so please just ping me with a > > > >> resend for those that expired and I'll go through and pick them all up. > > > > > > > > > > > > That's great Daniel. Thanks for your support. > > > > > > > > I can do one better than that. > > > > > > > > Would a pull-request suit you? > > > > > > We have a few trees going on, and your patches are landing through all > > > kinds of them. So this might be more coordination pain. If you can > > > exclude patches for the separately and usually fairly well maintained > > > drivers out of the pull it should work (drm/amd, drm/radeon, drm/i915, > > > drm/nouveau, drm/msm and drm/omapdrm probably the usual ones). > > > > > > Or you just send the next pile and we'll see. > > > > > > Also I guess I can't really interest you in commit rights so this > > > patch bombs get off my back again? :-) > > > > > > > What does that mean? Merge my own patches? > > > > Not sure how that works with your group maintenance setup. > > > > Is it just a `git push`? > > It's a bunch of scripting and setup, might not be worth it for just one > of. Plus we still take pull requests from submaintainers so it's all just > if you feel like it. Some docs if you're curious: > > https://drm.pages.freedesktop.org/maintainer-tools/getting-started.html As *fun* as that looks, I think I'll give it a miss, thanks. :) So for the final merge of the non-Radeon set [0] to date (Alex just pulled in all of the outstanding Radeon patches), we have a few options: 1. Take them directly from the most recent set [0] 2. I can rebase and resubmit again in a few days 3. I can submit a PR Whatever works for you. [0] "[PATCH v2 00/42] Rid W=1 warnings from GPU (non-Radeon)" -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 02/30] include: drm: drm_atomic: Artificially use 'crtc' to avoid 'not used' warning
On Tue, Nov 17, 2020 at 10:34:04AM +, Lee Jones wrote: > Daniel, > > For some reason, you're not appearing in the recipents list when I > reply to all. You're not in the Mail-Followup-To header. Any idea > why this might be? No idea either, could be my mutt not setting the reply headers like it should. I'm generally confused with how email works ... > > Anyway, please see below: > > On Tue, 17 Nov 2020, Daniel Vetter wrote: > > On Fri, Nov 13, 2020 at 10:01:57PM +, Lee Jones wrote: > > > On Fri, 13 Nov 2020, 21:31 Daniel Vetter, wrote: > > > > > > > On Fri, Nov 13, 2020 at 9:53 PM Lee Jones wrote: > > > > > > > > > > > > > > > > > > > > On Fri, 13 Nov 2020, 20:50 Daniel Vetter, wrote: > > > > >> > > > > >> On Thu, Nov 12, 2020 at 09:25:16PM +0100, Sam Ravnborg wrote: > > > > >> > Hi Lee, > > > > >> > > > > > >> > On Thu, Nov 12, 2020 at 07:00:11PM +, Lee Jones wrote: > > > > >> > > The precedent has already been set by other macros in the same > > > > >> > > file. > > > > >> > > > > > > >> > > Fixes the following W=1 kernel build warning(s): > > > > >> > > > > > > >> > > drivers/gpu/drm/vkms/vkms_drv.c:55:19: warning: variable ‘crtc’ > > > > set but not used [-Wunused-but-set-variable] > > > > >> > > 55 | struct drm_crtc *crtc; > > > > >> > > | ^~~~ > > > > >> > > > > > > >> > > Cc: Maarten Lankhorst > > > > >> > > Cc: Maxime Ripard > > > > >> > > Cc: Thomas Zimmermann > > > > >> > > Cc: David Airlie > > > > >> > > Cc: Daniel Vetter > > > > >> > > Cc: Rob Clark > > > > >> > > Cc: dri-devel@lists.freedesktop.org > > > > >> > > Signed-off-by: Lee Jones > > > > >> > > > > > >> > Also applied to drm-misc-next. > > > > >> > This was the last patch from this batch I will process. > > > > >> > The others are left for the maintainers to pick up. > > > > >> > > > > >> btw for patches that maintainers don't pick up, the usual process is > > > > that > > > > >> we give them 2 weeks, then just mass apply. Now you're producing a > > > > >> lot > > > > of > > > > >> patches, too much for me to keep track, so please just ping me with a > > > > >> resend for those that expired and I'll go through and pick them all > > > > >> up. > > > > > > > > > > > > > > > That's great Daniel. Thanks for your support. > > > > > > > > > > I can do one better than that. > > > > > > > > > > Would a pull-request suit you? > > > > > > > > We have a few trees going on, and your patches are landing through all > > > > kinds of them. So this might be more coordination pain. If you can > > > > exclude patches for the separately and usually fairly well maintained > > > > drivers out of the pull it should work (drm/amd, drm/radeon, drm/i915, > > > > drm/nouveau, drm/msm and drm/omapdrm probably the usual ones). > > > > > > > > Or you just send the next pile and we'll see. > > > > > > > > Also I guess I can't really interest you in commit rights so this > > > > patch bombs get off my back again? :-) > > > > > > > > > > What does that mean? Merge my own patches? > > > > > > Not sure how that works with your group maintenance setup. > > > > > > Is it just a `git push`? > > > > It's a bunch of scripting and setup, might not be worth it for just one > > of. Plus we still take pull requests from submaintainers so it's all just > > if you feel like it. Some docs if you're curious: > > > > https://drm.pages.freedesktop.org/maintainer-tools/getting-started.html > > As *fun* as that looks, I think I'll give it a miss, thanks. :) > > So for the final merge of the non-Radeon set [0] to date (Alex just > pulled in all of the outstanding Radeon patches), we have a few > options: > > 1. Take them directly from the most recent set [0] > 2. I can rebase and resubmit again in a few days > 3. I can submit a PR > > Whatever works for you. > > [0] "[PATCH v2 00/42] Rid W=1 warnings from GPU (non-Radeon)" I planned to go through that today and apply it all. Wanted to ping a few maintainers first whether they pick anything up, but aside from Alex they're non-committal so I think I just vacuum them all up so it's done. -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] drm/imx: depend on COMMON_CLK to fix compile tests
On Mon, 2020-11-16 at 19:14 +0100, Krzysztof Kozlowski wrote: > The iMX DRM drivers use Common Clock Framework thus they cannot be built > on platforms without it (e.g. compile test on MIPS with RALINK and > SOC_RT305X): > > /usr/bin/mips-linux-gnu-ld: drivers/gpu/drm/imx/imx-ldb.o: in function > `imx_ldb_encoder_disable': > imx-ldb.c:(.text+0x400): undefined reference to `clk_set_parent' > > Signed-off-by: Krzysztof Kozlowski Thank you, but could this be added to config DRM_IMX_LDB instead? The core DRM_IMX code does not use the Common Clock Framework directly. DRM_IMX_TVE already depends on COMMON_CLK because it implements a clock. regards Philipp ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 02/30] include: drm: drm_atomic: Artificially use 'crtc' to avoid 'not used' warning
On Tue, 17 Nov 2020, Daniel Vetter wrote: > On Tue, Nov 17, 2020 at 10:34:04AM +, Lee Jones wrote: > > Daniel, > > > > For some reason, you're not appearing in the recipents list when I > > reply to all. You're not in the Mail-Followup-To header. Any idea > > why this might be? > > No idea either, could be my mutt not setting the reply headers like it > should. I'm generally confused with how email works ... Yes, email is a mystery! > > Anyway, please see below: > > > > On Tue, 17 Nov 2020, Daniel Vetter wrote: > > > On Fri, Nov 13, 2020 at 10:01:57PM +, Lee Jones wrote: > > > > On Fri, 13 Nov 2020, 21:31 Daniel Vetter, wrote: > > > > > > > > > On Fri, Nov 13, 2020 at 9:53 PM Lee Jones > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > On Fri, 13 Nov 2020, 20:50 Daniel Vetter, wrote: > > > > > >> > > > > > >> On Thu, Nov 12, 2020 at 09:25:16PM +0100, Sam Ravnborg wrote: > > > > > >> > Hi Lee, > > > > > >> > > > > > > >> > On Thu, Nov 12, 2020 at 07:00:11PM +, Lee Jones wrote: > > > > > >> > > The precedent has already been set by other macros in the same > > > > > >> > > file. > > > > > >> > > > > > > > >> > > Fixes the following W=1 kernel build warning(s): > > > > > >> > > > > > > > >> > > drivers/gpu/drm/vkms/vkms_drv.c:55:19: warning: variable > > > > > >> > > ‘crtc’ > > > > > set but not used [-Wunused-but-set-variable] > > > > > >> > > 55 | struct drm_crtc *crtc; > > > > > >> > > | ^~~~ > > > > > >> > > > > > > > >> > > Cc: Maarten Lankhorst > > > > > >> > > Cc: Maxime Ripard > > > > > >> > > Cc: Thomas Zimmermann > > > > > >> > > Cc: David Airlie > > > > > >> > > Cc: Daniel Vetter > > > > > >> > > Cc: Rob Clark > > > > > >> > > Cc: dri-devel@lists.freedesktop.org > > > > > >> > > Signed-off-by: Lee Jones > > > > > >> > > > > > > >> > Also applied to drm-misc-next. > > > > > >> > This was the last patch from this batch I will process. > > > > > >> > The others are left for the maintainers to pick up. > > > > > >> > > > > > >> btw for patches that maintainers don't pick up, the usual process > > > > > >> is > > > > > that > > > > > >> we give them 2 weeks, then just mass apply. Now you're producing a > > > > > >> lot > > > > > of > > > > > >> patches, too much for me to keep track, so please just ping me > > > > > >> with a > > > > > >> resend for those that expired and I'll go through and pick them > > > > > >> all up. > > > > > > > > > > > > > > > > > > That's great Daniel. Thanks for your support. > > > > > > > > > > > > I can do one better than that. > > > > > > > > > > > > Would a pull-request suit you? > > > > > > > > > > We have a few trees going on, and your patches are landing through all > > > > > kinds of them. So this might be more coordination pain. If you can > > > > > exclude patches for the separately and usually fairly well maintained > > > > > drivers out of the pull it should work (drm/amd, drm/radeon, drm/i915, > > > > > drm/nouveau, drm/msm and drm/omapdrm probably the usual ones). > > > > > > > > > > Or you just send the next pile and we'll see. > > > > > > > > > > Also I guess I can't really interest you in commit rights so this > > > > > patch bombs get off my back again? :-) > > > > > > > > > > > > > What does that mean? Merge my own patches? > > > > > > > > Not sure how that works with your group maintenance setup. > > > > > > > > Is it just a `git push`? > > > > > > It's a bunch of scripting and setup, might not be worth it for just one > > > of. Plus we still take pull requests from submaintainers so it's all just > > > if you feel like it. Some docs if you're curious: > > > > > > https://drm.pages.freedesktop.org/maintainer-tools/getting-started.html > > > > As *fun* as that looks, I think I'll give it a miss, thanks. :) > > > > So for the final merge of the non-Radeon set [0] to date (Alex just > > pulled in all of the outstanding Radeon patches), we have a few > > options: > > > > 1. Take them directly from the most recent set [0] > > 2. I can rebase and resubmit again in a few days > > 3. I can submit a PR > > > > Whatever works for you. > > > > [0] "[PATCH v2 00/42] Rid W=1 warnings from GPU (non-Radeon)" > > I planned to go through that today and apply it all. Wanted to ping a few > maintainers first whether they pick anything up, but aside from Alex > they're non-committal so I think I just vacuum them all up so it's done. Okay, perfect. Thanks a bunch. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/imx: depend on COMMON_CLK to fix compile tests
On Tue, 17 Nov 2020 at 11:56, Philipp Zabel wrote: > > On Mon, 2020-11-16 at 19:14 +0100, Krzysztof Kozlowski wrote: > > The iMX DRM drivers use Common Clock Framework thus they cannot be built > > on platforms without it (e.g. compile test on MIPS with RALINK and > > SOC_RT305X): > > > > /usr/bin/mips-linux-gnu-ld: drivers/gpu/drm/imx/imx-ldb.o: in function > > `imx_ldb_encoder_disable': > > imx-ldb.c:(.text+0x400): undefined reference to `clk_set_parent' > > > > Signed-off-by: Krzysztof Kozlowski > > Thank you, but could this be added to > > config DRM_IMX_LDB > > instead? > > The core DRM_IMX code does not use the Common Clock Framework directly. > DRM_IMX_TVE already depends on COMMON_CLK because it implements a clock. You're right, I even wanted to add it there but somehow it landed in the main entry... Thanks, I'll send a v2. Best regards, Krzysztof ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 41/42] gpu/ipu-v3/ipu-di: Strip out 2 unused 'di_sync_config' entries
Hi Lee,
On Mon, 2020-11-16 at 17:41 +, Lee Jones wrote:
> They're taking up too much space on the stack.
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/ipu-v3/ipu-di.c: In function ‘ipu_di_sync_config_noninterlaced’:
> drivers/gpu/ipu-v3/ipu-di.c:391:1: warning: the frame size of 1064 bytes is
> larger than 1024 bytes [-Wframe-larger-than=]
>
> Cc: Philipp Zabel
> Cc: Sascha Hauer
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Lee Jones
> ---
> drivers/gpu/ipu-v3/ipu-di.c | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/drivers/gpu/ipu-v3/ipu-di.c b/drivers/gpu/ipu-v3/ipu-di.c
> index b4a31d506fccf..e617f60afeea3 100644
> --- a/drivers/gpu/ipu-v3/ipu-di.c
> +++ b/drivers/gpu/ipu-v3/ipu-di.c
> @@ -310,10 +310,6 @@ static void ipu_di_sync_config_noninterlaced(struct
> ipu_di *di,
> /* unused */
> } , {
> /* unused */
> - } , {
> - /* unused */
> - } , {
> - /* unused */
> },
> };
> /* can't use #7 and #8 for line active and pixel active counters */
Thank you, applied to imx-drm/next.
regards
Philipp
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH][next] drm/amd/pm: fix spelling mistakes in dev_warn messages
From: Colin Ian King
There are two spelling mistakes in dev_warn messages. Fix these.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
b/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
index afa542a5af5f..9a2f72f21ed8 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
@@ -689,14 +689,14 @@ static int vangogh_od_edit_dpm_table(struct smu_context
*smu, enum PP_OD_DPM_TAB
if (input[0] == 0) {
if (input[1] < smu->gfx_default_hard_min_freq) {
- dev_warn(smu->adev->dev, "Fine grain setting
minimun sclk (%ld) MHz is less than the minimum allowed (%d) MHz\n",
+ dev_warn(smu->adev->dev, "Fine grain setting
minimum sclk (%ld) MHz is less than the minimum allowed (%d) MHz\n",
input[1],
smu->gfx_default_hard_min_freq);
return -EINVAL;
}
smu->gfx_actual_hard_min_freq = input[1];
} else if (input[0] == 1) {
if (input[1] > smu->gfx_default_soft_max_freq) {
- dev_warn(smu->adev->dev, "Fine grain setting
maximun sclk (%ld) MHz is greater than the maximum allowed (%d) MHz\n",
+ dev_warn(smu->adev->dev, "Fine grain setting
maximum sclk (%ld) MHz is greater than the maximum allowed (%d) MHz\n",
input[1],
smu->gfx_default_soft_max_freq);
return -EINVAL;
}
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dt-bindings: display: Use OF graph schema
On Tue, Nov 17, 2020 at 3:43 AM Laurent Pinchart wrote: > > Hi Rob, > > Thank you for the patch. > > On Mon, Nov 16, 2020 at 07:37:03PM -0600, Rob Herring wrote: > > Now that we have a graph schema, rework the display related schemas to use > > it. Mostly this is adding a reference to graph.yaml and dropping duplicate > > parts from schemas. > > > > Cc: Thierry Reding > > Cc: Sam Ravnborg > > Cc: Laurent Pinchart > > Cc: Maxime Ripard > > Cc: Maarten Lankhorst > > Cc: Thomas Zimmermann > > Signed-off-by: Rob Herring > > --- > > graph.yaml is in the dtschema repo, so this can go into drm-misc and > > hopefully anything afterwards be fixed up to use graph.yaml. > > > > .../allwinner,sun4i-a10-display-backend.yaml | 14 +--- > > .../allwinner,sun4i-a10-display-frontend.yaml | 16 + > > .../display/allwinner,sun4i-a10-hdmi.yaml | 16 + > > .../display/allwinner,sun4i-a10-tcon.yaml | 16 + > > .../allwinner,sun4i-a10-tv-encoder.yaml | 2 +- > > .../display/allwinner,sun6i-a31-drc.yaml | 16 + > > .../display/allwinner,sun6i-a31-mipi-dsi.yaml | 6 +- > > .../allwinner,sun8i-a83t-de2-mixer.yaml | 16 + > > .../display/allwinner,sun8i-a83t-dw-hdmi.yaml | 16 + > > .../display/allwinner,sun8i-r40-tcon-top.yaml | 19 +- > > .../display/allwinner,sun9i-a80-deu.yaml | 16 + > > .../bindings/display/brcm,bcm2835-dpi.yaml| 7 +- > > .../display/bridge/analogix,anx7625.yaml | 5 +- > > .../display/bridge/analogix,anx7814.yaml | 18 + > > .../bindings/display/bridge/anx6345.yaml | 15 ++-- > > .../display/bridge/cdns,mhdp8546.yaml | 18 + > > .../display/bridge/chrontel,ch7033.yaml | 3 + > > .../display/bridge/intel,keembay-dsi.yaml | 9 +-- > > .../bindings/display/bridge/ite,it6505.yaml | 2 +- > > .../display/bridge/lontium,lt9611.yaml| 68 ++- > > .../bindings/display/bridge/lvds-codec.yaml | 15 +--- > > .../bindings/display/bridge/nwl-dsi.yaml | 17 + > > .../bindings/display/bridge/ps8640.yaml | 21 ++ > > .../bindings/display/bridge/renesas,lvds.yaml | 15 +--- > > .../display/bridge/simple-bridge.yaml | 15 +--- > > .../display/bridge/snps,dw-mipi-dsi.yaml | 5 +- > > .../display/bridge/thine,thc63lvd1024.yaml| 16 + > > .../bindings/display/bridge/ti,sn65dsi86.yaml | 27 +--- > > .../bindings/display/bridge/ti,tfp410.yaml| 15 +--- > > .../display/bridge/toshiba,tc358762.yaml | 51 ++ > > .../display/bridge/toshiba,tc358768.yaml | 11 +-- > > .../display/bridge/toshiba,tc358775.yaml | 17 ++--- > > .../connector/analog-tv-connector.yaml| 1 + > > .../display/connector/dvi-connector.yaml | 1 + > > .../display/connector/hdmi-connector.yaml | 1 + > > .../display/connector/vga-connector.yaml | 1 + > > .../bindings/display/imx/nxp,imx8mq-dcss.yaml | 2 +- > > .../bindings/display/ingenic,lcd.yaml | 7 +- > > .../display/intel,keembay-display.yaml| 2 +- > > .../display/panel/advantech,idk-2121wr.yaml | 5 ++ > > .../bindings/display/panel/panel-common.yaml | 11 +-- > > .../rockchip/rockchip,rk3066-hdmi.yaml| 13 +--- > > .../display/rockchip/rockchip-vop.yaml| 5 +- > > .../bindings/display/st,stm32-dsi.yaml| 13 ++-- > > .../bindings/display/st,stm32-ltdc.yaml | 7 +- > > .../bindings/display/ti/ti,am65x-dss.yaml | 16 + > > .../bindings/display/ti/ti,j721e-dss.yaml | 18 + > > .../bindings/display/ti/ti,k2g-dss.yaml | 4 +- > > 48 files changed, 121 insertions(+), 509 deletions(-) > > > > diff --git > > a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-backend.yaml > > > > b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-backend.yaml > > index 86057d541065..7e8798b43c2a 100644 > > --- > > a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-backend.yaml > > +++ > > b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-backend.yaml > > @@ -85,17 +85,9 @@ properties: > > > >ports: > > type: object > > Do we need to specify the type here (and in all the locations below), > give that it's specified in /schemas/graph.yaml#/properties/ports ? The metaschema enforces that we have 'type' if we have 'properties' (except at the top level), so yes. Now that I think about it more, maybe I can rework it such that we required at least 'type' or '$ref' when we have 'properties'. Though that's not going to remove 'type' for 'port@n' schemas. [...] > > diff --git > > a/Documentation/devicetree/bindings/display/panel/panel-common.yaml > > b/Documentation/devicetree/bindings/display/panel/panel-common.yaml > > index cd6dc5461721..5b38dc89cb21 100644 > > --- a/Documentation/devicetree/bindings/display/panel/panel-common.yaml > > +++ b/Documentation/devicetree/bindings/display/panel/panel-common.yaml > > @
[PATCH v3 1/2] drm/shmem-helper: Use cached mappings by default
SHMEM-buffer backing storage is allocated from system memory; which is
typically cachable. The default mode for SHMEM objects is writecombine
though.
Unify SHMEM semantics by defaulting to cached mappings. The exception
is pages imported via dma-buf. DMA memory is usually not cached.
DRM drivers that require write-combined mappings set the map_wc flag
in struct drm_gem_shmem_object to true. This currently affects lima,
panfrost and v3d.
The drivers mgag200, udl, virtio and vkms continue to use default
shmem mappings.
The drivers cirrus and gm12u320 change caching flags. Both used
writecombine and now switch over to shmem defaults. Both drivers use
SHMEM objects as shadow buffers for internal video memory, so cached
mappings will not affect them negatively.
v3:
* set value of shmem pointer before dereferencing it in
__drm_gem_shmem_create() (Dan, kernel test robot)
v2:
* recreate patch on top of latest SHMEM helpers
* update lima, panfrost, v3d to select writecombine (Daniel, Rob)
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 14 --
drivers/gpu/drm/lima/lima_gem.c | 2 +-
drivers/gpu/drm/panfrost/panfrost_gem.c | 2 +-
drivers/gpu/drm/v3d/v3d_bo.c| 2 +-
drivers/gpu/drm/virtio/virtgpu_object.c | 1 -
include/drm/drm_gem_shmem_helper.h | 4 ++--
6 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index 499189c48f0b..b1c7a316f232 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -51,13 +51,17 @@ __drm_gem_shmem_create(struct drm_device *dev, size_t size,
bool private)
if (!obj)
return ERR_PTR(-ENOMEM);
+ shmem = to_drm_gem_shmem_obj(obj);
+
if (!obj->funcs)
obj->funcs = &drm_gem_shmem_funcs;
- if (private)
+ if (private) {
drm_gem_private_object_init(dev, obj, size);
- else
+ shmem->map_wc = false; /* dma-buf mappings use always
writecombine */
+ } else {
ret = drm_gem_object_init(dev, obj, size);
+ }
if (ret)
goto err_free;
@@ -65,7 +69,6 @@ __drm_gem_shmem_create(struct drm_device *dev, size_t size,
bool private)
if (ret)
goto err_release;
- shmem = to_drm_gem_shmem_obj(obj);
mutex_init(&shmem->pages_lock);
mutex_init(&shmem->vmap_lock);
INIT_LIST_HEAD(&shmem->madv_list);
@@ -284,7 +287,7 @@ static int drm_gem_shmem_vmap_locked(struct
drm_gem_shmem_object *shmem, struct
if (ret)
goto err_zero_use;
- if (!shmem->map_cached)
+ if (shmem->map_wc)
prot = pgprot_writecombine(prot);
shmem->vaddr = vmap(shmem->pages, obj->size >> PAGE_SHIFT,
VM_MAP, prot);
@@ -497,7 +500,6 @@ drm_gem_shmem_create_object_cached(struct drm_device *dev,
size_t size)
shmem = kzalloc(sizeof(*shmem), GFP_KERNEL);
if (!shmem)
return NULL;
- shmem->map_cached = true;
return &shmem->base;
}
@@ -626,7 +628,7 @@ int drm_gem_shmem_mmap(struct drm_gem_object *obj, struct
vm_area_struct *vma)
vma->vm_flags |= VM_MIXEDMAP | VM_DONTEXPAND;
vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
- if (!shmem->map_cached)
+ if (shmem->map_wc)
vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
vma->vm_ops = &drm_gem_shmem_vm_ops;
diff --git a/drivers/gpu/drm/lima/lima_gem.c b/drivers/gpu/drm/lima/lima_gem.c
index 832e5280a6ed..de62966243cd 100644
--- a/drivers/gpu/drm/lima/lima_gem.c
+++ b/drivers/gpu/drm/lima/lima_gem.c
@@ -225,7 +225,7 @@ struct drm_gem_object *lima_gem_create_object(struct
drm_device *dev, size_t siz
mutex_init(&bo->lock);
INIT_LIST_HEAD(&bo->va);
-
+ bo->base.map_wc = true;
bo->base.base.funcs = &lima_gem_funcs;
return &bo->base.base;
diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.c
b/drivers/gpu/drm/panfrost/panfrost_gem.c
index 57a31dd0ffed..3e0723bc36bd 100644
--- a/drivers/gpu/drm/panfrost/panfrost_gem.c
+++ b/drivers/gpu/drm/panfrost/panfrost_gem.c
@@ -228,7 +228,7 @@ struct drm_gem_object *panfrost_gem_create_object(struct
drm_device *dev, size_t
INIT_LIST_HEAD(&obj->mappings.list);
mutex_init(&obj->mappings.lock);
obj->base.base.funcs = &panfrost_gem_funcs;
- obj->base.map_cached = pfdev->coherent;
+ obj->base.map_wc = !pfdev->coherent;
return &obj->base.base;
}
diff --git a/drivers/gpu/drm/v3d/v3d_bo.c b/drivers/gpu/drm/v3d/v3d_bo.c
index 8b52cb25877c..6a8731ab9d7d 100644
--- a/drivers/gpu/drm/v3d/v3d_bo.c
+++ b/drivers/gpu/drm/v3d/v3d_bo.c
@@ -78,7 +78,7 @@ struct drm_gem_object *v3d_create_object(st
[PATCH v3 0/2] Default to cachable mappings for GEM SHMEM
By default, SHMEM GEM helpers map pages using writecombine. Only a few drivers require this setting. Others revert it to default mappings flags. Some could benefit from caching, but don't care. Unify the behaviour by switching the SHMEM GEM code to use cached mappings (i.e., PAGE_KERNEL actually); just like regular shmem memory does. The 3 drivers that require write combining explicitly select it during GEM object creation. The exception is dma-buf imported pages, which are always mapped using writecombine mode. v3: * fix dereferencing of an uninitialized pointer (Dan, kernel test robot) v2: * recreate patches on top of latest SHMEM helpers * update lima, panfrost, v3d (Daniel, Rob) * udl has been updated before separately. Thomas Zimmermann (2): drm/shmem-helper: Use cached mappings by default drm/shmem-helper: Removed drm_gem_shmem_create_object_cached() drivers/gpu/drm/drm_gem_shmem_helper.c | 40 + drivers/gpu/drm/lima/lima_gem.c | 2 +- drivers/gpu/drm/mgag200/mgag200_drv.c | 1 - drivers/gpu/drm/panfrost/panfrost_gem.c | 2 +- drivers/gpu/drm/udl/udl_drv.c | 2 -- drivers/gpu/drm/v3d/v3d_bo.c| 2 +- drivers/gpu/drm/virtio/virtgpu_object.c | 1 - drivers/gpu/drm/vkms/vkms_drv.c | 1 - include/drm/drm_gem_shmem_helper.h | 7 ++--- 9 files changed, 13 insertions(+), 45 deletions(-) -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/2] drm/shmem-helper: Removed drm_gem_shmem_create_object_cached()
Cached page mappings are now the default for SHMEM GEM objects. Remove
the obsolete create function for cached mappings.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 26 --
drivers/gpu/drm/mgag200/mgag200_drv.c | 1 -
drivers/gpu/drm/udl/udl_drv.c | 2 --
drivers/gpu/drm/vkms/vkms_drv.c| 1 -
include/drm/drm_gem_shmem_helper.h | 3 ---
5 files changed, 33 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index b1c7a316f232..9825c378dfa6 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -479,32 +479,6 @@ bool drm_gem_shmem_purge(struct drm_gem_object *obj)
}
EXPORT_SYMBOL(drm_gem_shmem_purge);
-/**
- * drm_gem_shmem_create_object_cached - Create a shmem buffer object with
- * cached mappings
- * @dev: DRM device
- * @size: Size of the object to allocate
- *
- * By default, shmem buffer objects use writecombine mappings. This
- * function implements struct drm_driver.gem_create_object for shmem
- * buffer objects with cached mappings.
- *
- * Returns:
- * A struct drm_gem_shmem_object * on success or NULL negative on failure.
- */
-struct drm_gem_object *
-drm_gem_shmem_create_object_cached(struct drm_device *dev, size_t size)
-{
- struct drm_gem_shmem_object *shmem;
-
- shmem = kzalloc(sizeof(*shmem), GFP_KERNEL);
- if (!shmem)
- return NULL;
-
- return &shmem->base;
-}
-EXPORT_SYMBOL(drm_gem_shmem_create_object_cached);
-
/**
* drm_gem_shmem_dumb_create - Create a dumb shmem buffer object
* @file: DRM file structure to create the dumb buffer for
diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.c
b/drivers/gpu/drm/mgag200/mgag200_drv.c
index 0f07f259503d..a977c9f49719 100644
--- a/drivers/gpu/drm/mgag200/mgag200_drv.c
+++ b/drivers/gpu/drm/mgag200/mgag200_drv.c
@@ -37,7 +37,6 @@ static const struct drm_driver mgag200_driver = {
.major = DRIVER_MAJOR,
.minor = DRIVER_MINOR,
.patchlevel = DRIVER_PATCHLEVEL,
- .gem_create_object = drm_gem_shmem_create_object_cached,
DRM_GEM_SHMEM_DRIVER_OPS,
};
diff --git a/drivers/gpu/drm/udl/udl_drv.c b/drivers/gpu/drm/udl/udl_drv.c
index b5a8dd9fdf02..9269092697d8 100644
--- a/drivers/gpu/drm/udl/udl_drv.c
+++ b/drivers/gpu/drm/udl/udl_drv.c
@@ -38,8 +38,6 @@ static const struct drm_driver driver = {
.driver_features = DRIVER_ATOMIC | DRIVER_GEM | DRIVER_MODESET,
/* GEM hooks */
- .gem_create_object = drm_gem_shmem_create_object_cached,
-
.fops = &udl_driver_fops,
DRM_GEM_SHMEM_DRIVER_OPS,
diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
index 1a1b5bc8e121..d4d39227f2ed 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.c
+++ b/drivers/gpu/drm/vkms/vkms_drv.c
@@ -82,7 +82,6 @@ static const struct drm_driver vkms_driver = {
.driver_features= DRIVER_MODESET | DRIVER_ATOMIC | DRIVER_GEM,
.release= vkms_release,
.fops = &vkms_driver_fops,
- .gem_create_object = drm_gem_shmem_create_object_cached,
DRM_GEM_SHMEM_DRIVER_OPS,
.name = DRIVER_NAME,
diff --git a/include/drm/drm_gem_shmem_helper.h
b/include/drm/drm_gem_shmem_helper.h
index f32801db3203..434328d8a0d9 100644
--- a/include/drm/drm_gem_shmem_helper.h
+++ b/include/drm/drm_gem_shmem_helper.h
@@ -133,9 +133,6 @@ drm_gem_shmem_create_with_handle(struct drm_file *file_priv,
struct drm_device *dev, size_t size,
uint32_t *handle);
-struct drm_gem_object *
-drm_gem_shmem_create_object_cached(struct drm_device *dev, size_t size);
-
int drm_gem_shmem_dumb_create(struct drm_file *file, struct drm_device *dev,
struct drm_mode_create_dumb *args);
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/omap: dmm_tiler: fix return error code in omap_dmm_probe()
Hi
Am 17.11.20 um 07:10 schrieb Yang Yingliang:
> Return -ENOMEM when allocating refill memory failed.
>
> Fixes: 71e8831f6407 ("drm/omap: DMM/TILER support for OMAP4+ platform")
> Reported-by: Hulk Robot
> Signed-off-by: Yang Yingliang
> ---
> drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
> b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
> index 42ec51bb7b1b..7f4317248812 100644
> --- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
> +++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
> @@ -889,6 +889,7 @@ static int omap_dmm_probe(struct platform_device *dev)
> &omap_dmm->refill_pa, GFP_KERNEL);
> if (!omap_dmm->refill_va) {
> dev_err(&dev->dev, "could not allocate refill memory\n");
> + ret = -ENOMEM;
Reviewed-by: Thomas Zimmermann
Thanks for the patch. I'll add it to drm-misc-next. There are more such
errors here. If the very first allocation fails, the function returns
-EFAULT, which makes no sense.
Best regards
Thomas
> goto fail;
> }
>
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND PATCH 2/3] phy: mediatek: Move mtk_mipi_dsi_phy driver into drivers/phy/mediatek folder
Hi, Vinod:
Chunfeng Yun 於 2020年11月17日 週二 上午11:36寫道：
>
> Hi CK,
> On Tue, 2020-11-17 at 07:14 +0800, Chun-Kuang Hu wrote:
> > mtk_mipi_dsi_phy is currently placed inside mediatek drm driver, but it's
> > more suitable to place a phy driver into phy driver folder, so move
> > mtk_mipi_dsi_phy driver into phy driver folder.
> >
> > Signed-off-by: Chun-Kuang Hu
> You forgot to add acked-by me
If you apply this patch, please add acked-by tag of chunfeng [1], thanks.
[1]
https://patchwork.kernel.org/project/linux-mediatek/patch/20201029152702.533-3-chunkuang...@kernel.org/
Regards,
Chun-Kuang.
>
> > ---
> > drivers/gpu/drm/mediatek/Kconfig | 7 ---
> > drivers/gpu/drm/mediatek/Makefile | 6 --
> > drivers/phy/mediatek/Kconfig | 7 +++
> > drivers/phy/mediatek/Makefile | 5 +
> > .../mediatek/phy-mtk-mipi-dsi-mt8173.c}| 2 +-
> > .../mediatek/phy-mtk-mipi-dsi-mt8183.c}| 2 +-
> > .../mtk_mipi_tx.c => phy/mediatek/phy-mtk-mipi-dsi.c} | 2 +-
> > .../mtk_mipi_tx.h => phy/mediatek/phy-mtk-mipi-dsi.h} | 0
> > 8 files changed, 15 insertions(+), 16 deletions(-)
> > rename drivers/{gpu/drm/mediatek/mtk_mt8173_mipi_tx.c =>
> > phy/mediatek/phy-mtk-mipi-dsi-mt8173.c} (99%)
> > rename drivers/{gpu/drm/mediatek/mtk_mt8183_mipi_tx.c =>
> > phy/mediatek/phy-mtk-mipi-dsi-mt8183.c} (99%)
> > rename drivers/{gpu/drm/mediatek/mtk_mipi_tx.c =>
> > phy/mediatek/phy-mtk-mipi-dsi.c} (99%)
> > rename drivers/{gpu/drm/mediatek/mtk_mipi_tx.h =>
> > phy/mediatek/phy-mtk-mipi-dsi.h} (100%)
> >
> > diff --git a/drivers/gpu/drm/mediatek/Kconfig
> > b/drivers/gpu/drm/mediatek/Kconfig
> > index 24c4890a6e65..2976d21e9a34 100644
> > --- a/drivers/gpu/drm/mediatek/Kconfig
> > +++ b/drivers/gpu/drm/mediatek/Kconfig
> > @@ -28,10 +28,3 @@ config DRM_MEDIATEK_HDMI
> > select PHY_MTK_HDMI
> > help
> > DRM/KMS HDMI driver for Mediatek SoCs
> > -
> > -config PHY_MTK_MIPI_DSI
> > - tristate "Mediatek MIPI-DSI-PHY Driver"
> > - depends on ARCH_MEDIATEK && OF
> > - select GENERIC_PHY
> > - help
> > - Support MIPI DSI PHY for Mediatek SoCs.
> > diff --git a/drivers/gpu/drm/mediatek/Makefile
> > b/drivers/gpu/drm/mediatek/Makefile
> > index baa188000543..a892edec5563 100644
> > --- a/drivers/gpu/drm/mediatek/Makefile
> > +++ b/drivers/gpu/drm/mediatek/Makefile
> > @@ -19,9 +19,3 @@ mediatek-drm-hdmi-objs := mtk_cec.o \
> > mtk_hdmi_ddc.o
> >
> > obj-$(CONFIG_DRM_MEDIATEK_HDMI) += mediatek-drm-hdmi.o
> > -
> > -phy-mtk-mipi-dsi-drv-objs := mtk_mipi_tx.o \
> > - mtk_mt8173_mipi_tx.o \
> > - mtk_mt8183_mipi_tx.o
> > -
> > -obj-$(CONFIG_PHY_MTK_MIPI_DSI) += phy-mtk-mipi-dsi-drv.o
> > diff --git a/drivers/phy/mediatek/Kconfig b/drivers/phy/mediatek/Kconfig
> > index 50c5e9306e19..574b8e6398d2 100644
> > --- a/drivers/phy/mediatek/Kconfig
> > +++ b/drivers/phy/mediatek/Kconfig
> > @@ -42,3 +42,10 @@ config PHY_MTK_HDMI
> > select GENERIC_PHY
> > help
> > Support HDMI PHY for Mediatek SoCs.
> > +
> > +config PHY_MTK_MIPI_DSI
> > + tristate "MediaTek MIPI-DSI Driver"
> > + depends on ARCH_MEDIATEK && OF
> > + select GENERIC_PHY
> > + help
> > + Support MIPI DSI for Mediatek SoCs.
> > diff --git a/drivers/phy/mediatek/Makefile b/drivers/phy/mediatek/Makefile
> > index 6325e38709ed..ace660fbed3a 100644
> > --- a/drivers/phy/mediatek/Makefile
> > +++ b/drivers/phy/mediatek/Makefile
> > @@ -11,3 +11,8 @@ phy-mtk-hdmi-drv-y := phy-mtk-hdmi.o
> > phy-mtk-hdmi-drv-y += phy-mtk-hdmi-mt2701.o
> > phy-mtk-hdmi-drv-y += phy-mtk-hdmi-mt8173.o
> > obj-$(CONFIG_PHY_MTK_HDMI) += phy-mtk-hdmi-drv.o
> > +
> > +phy-mtk-mipi-dsi-drv-y := phy-mtk-mipi-dsi.o
> > +phy-mtk-mipi-dsi-drv-y += phy-mtk-mipi-dsi-mt8173.o
> > +phy-mtk-mipi-dsi-drv-y += phy-mtk-mipi-dsi-mt8183.o
> > +obj-$(CONFIG_PHY_MTK_MIPI_DSI) += phy-mtk-mipi-dsi-drv.o
> > diff --git a/drivers/gpu/drm/mediatek/mtk_mt8173_mipi_tx.c
> > b/drivers/phy/mediatek/phy-mtk-mipi-dsi-mt8173.c
> > similarity index 99%
> > rename from drivers/gpu/drm/mediatek/mtk_mt8173_mipi_tx.c
> > rename to drivers/phy/mediatek/phy-mtk-mipi-dsi-mt8173.c
> > index f18db14d8b63..7a847954594f 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_mt8173_mipi_tx.c
> > +++ b/drivers/phy/mediatek/phy-mtk-mipi-dsi-mt8173.c
> > @@ -4,7 +4,7 @@
> > * Author: jitao.shi
> > */
> >
> > -#include "mtk_mipi_tx.h"
> > +#include "phy-mtk-mipi-dsi.h"
> >
> > #define MIPITX_DSI_CON 0x00
> > #define RG_DSI_LDOCORE_ENBIT(0)
> > diff --git a/drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c
> > b/drivers/phy/mediatek/phy-mtk-mipi-dsi-mt8183.c
> > similari
Re: [RESEND PATCH 3/3] MAINTAINERS: add files for Mediatek DRM drivers
Hi, Vinod: Chun-Kuang Hu 於 2020年11月17日 週二 上午7:14寫道： > > Mediatek MIPI DSI phy driver is moved from drivers/gpu/drm/mediatek to > drivers/phy/mediatek, so add the new folder to the Mediatek DRM drivers' > information. > > Signed-off-by: Chun-Kuang Hu If you apply this patch, please add acked-by tag of chunfeng [1], thanks. [1] https://patchwork.kernel.org/project/linux-mediatek/patch/20201029152702.533-4-chunkuang...@kernel.org/ Regards, Chun-Kuang. > --- > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index e73636b75f29..14f5018c01b6 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -5867,6 +5867,7 @@ S:Supported > F: Documentation/devicetree/bindings/display/mediatek/ > F: drivers/gpu/drm/mediatek/ > F: drivers/phy/mediatek/phy-mtk-hdmi* > +F: drivers/phy/mediatek/phy-mtk-mipi* > > DRM DRIVERS FOR NVIDIA TEGRA > M: Thierry Reding > -- > 2.17.1 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/ttm: move memory accounting into vmwgfx
This is just another feature which is only used by VMWGFX, so move
it into the driver instead.
I've tried to add the accounting sysfs file to the kobject of the drm
minor, but I'm not 100% sure if this works as expected.
Signed-off-by: Christian König
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 16 +++--
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c| 8 +--
drivers/gpu/drm/drm_gem_vram_helper.c | 6 +-
drivers/gpu/drm/nouveau/nouveau_bo.c | 7 +-
drivers/gpu/drm/nouveau/nouveau_drv.h | 1 -
drivers/gpu/drm/qxl/qxl_object.c | 4 +-
drivers/gpu/drm/radeon/radeon_object.c| 8 +--
drivers/gpu/drm/ttm/Makefile | 6 +-
drivers/gpu/drm/ttm/ttm_bo.c | 65 ---
drivers/gpu/drm/ttm/ttm_bo_util.c | 1 -
drivers/gpu/drm/ttm/ttm_pool.c| 13 +---
drivers/gpu/drm/vmwgfx/Makefile | 2 +-
drivers/gpu/drm/{ttm => vmwgfx}/ttm_memory.c | 31 +++--
.../gpu/drm/vmwgfx}/ttm_memory.h | 5 +-
drivers/gpu/drm/vmwgfx/ttm_object.h | 3 +-
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c| 22 +--
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 5 ++
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c| 28 +++-
include/drm/ttm/ttm_bo_api.h | 11 +---
include/drm/ttm/ttm_bo_driver.h | 1 -
include/drm/ttm/ttm_tt.h | 1 +
21 files changed, 118 insertions(+), 126 deletions(-)
rename drivers/gpu/drm/{ttm => vmwgfx}/ttm_memory.c (94%)
rename {include/drm/ttm => drivers/gpu/drm/vmwgfx}/ttm_memory.h (97%)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 1755386470e6..4eec73da0a7b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -118,6 +118,16 @@ void amdgpu_amdkfd_gpuvm_init_mem_limits(void)
*/
#define ESTIMATE_PT_SIZE(mem_size) ((mem_size) >> 14)
+static size_t amdgpu_amdkfd_acc_size(uint64_t size)
+{
+ size >>= PAGE_SHIFT;
+ size *= sizeof(dma_addr_t) + sizeof(void *);
+
+ return __roundup_pow_of_two(sizeof(struct amdgpu_bo)) +
+ __rountup_pow_of_two(sizeof(struct ttm_tt)) +
+ PAGE_ALIGN(size);
+}
+
static int amdgpu_amdkfd_reserve_mem_limit(struct amdgpu_device *adev,
uint64_t size, u32 domain, bool sg)
{
@@ -126,8 +136,7 @@ static int amdgpu_amdkfd_reserve_mem_limit(struct
amdgpu_device *adev,
size_t acc_size, system_mem_needed, ttm_mem_needed, vram_needed;
int ret = 0;
- acc_size = ttm_bo_dma_acc_size(&adev->mman.bdev, size,
- sizeof(struct amdgpu_bo));
+ acc_size = amdgpu_amdkfd_acc_size(size);
vram_needed = 0;
if (domain == AMDGPU_GEM_DOMAIN_GTT) {
@@ -174,8 +183,7 @@ static void unreserve_mem_limit(struct amdgpu_device *adev,
{
size_t acc_size;
- acc_size = ttm_bo_dma_acc_size(&adev->mman.bdev, size,
- sizeof(struct amdgpu_bo));
+ acc_size = amdgpu_amdkfd_acc_size(size);
spin_lock(&kfd_mem_limit.mem_limit_lock);
if (domain == AMDGPU_GEM_DOMAIN_GTT) {
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index c6c9723d3d8a..b4ed0662ec5b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -523,7 +523,6 @@ static int amdgpu_bo_do_create(struct amdgpu_device *adev,
};
struct amdgpu_bo *bo;
unsigned long page_align, size = bp->size;
- size_t acc_size;
int r;
/* Note that GDS/GWS/OA allocates 1 page per byte/resource. */
@@ -546,9 +545,6 @@ static int amdgpu_bo_do_create(struct amdgpu_device *adev,
*bo_ptr = NULL;
- acc_size = ttm_bo_dma_acc_size(&adev->mman.bdev, size,
- sizeof(struct amdgpu_bo));
-
bo = kzalloc(sizeof(struct amdgpu_bo), GFP_KERNEL);
if (bo == NULL)
return -ENOMEM;
@@ -577,8 +573,8 @@ static int amdgpu_bo_do_create(struct amdgpu_device *adev,
bo->tbo.priority = 1;
r = ttm_bo_init_reserved(&adev->mman.bdev, &bo->tbo, size, bp->type,
-&bo->placement, page_align, &ctx, acc_size,
-NULL, bp->resv, &amdgpu_bo_destroy);
+&bo->placement, page_align, &ctx, NULL,
+bp->resv, &amdgpu_bo_destroy);
if (unlikely(r != 0))
return r;
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 02ca22e90290..5cf7797048e1 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -189,7 +189,6 @@ struct drm_gem_vram_object *drm_gem_vram_create(s
[PATCH 1/3] drm/ttm: rework ttm_tt page limit
TTM implements a rather extensive accounting of allocated memory.
There are two reasons for this:
1. It tries to block userspace allocating a huge number of very small
BOs without accounting for the kmalloced memory.
2. Make sure we don't over allocate and run into an OOM situation
during swapout while trying to handle the memory shortage.
This is only partially a good idea. First of all it is perfectly
valid for an application to use all of system memory, limiting it to
50% is not really acceptable.
What we need to take care of is that the application is held
accountable for the memory it allocated. This is what control
mechanisms like memcg and the normal Linux page accounting already do.
Making sure that we don't run into an OOM situation while trying to
cope with a memory shortage is still a good idea, but this is also
not very well implemented since it means another opportunity of
recursion from the driver back into TTM.
So start to rework all of this by accounting the memory before
allocating the pages and making sure that we never go over a certain
limit pages locked by TTM in the ttm_tt objects.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_memory.c | 17 -
drivers/gpu/drm/ttm/ttm_tt.c | 64 +---
include/drm/ttm/ttm_tt.h | 2 +
3 files changed, 77 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_memory.c b/drivers/gpu/drm/ttm/ttm_memory.c
index 5ed1fc8f2ace..c53136048630 100644
--- a/drivers/gpu/drm/ttm/ttm_memory.c
+++ b/drivers/gpu/drm/ttm/ttm_memory.c
@@ -38,6 +38,7 @@
#include
#include
#include
+#include
#define TTM_MEMORY_ALLOC_RETRIES 4
@@ -414,10 +415,11 @@ static int ttm_mem_init_dma32_zone(struct ttm_mem_global
*glob,
int ttm_mem_global_init(struct ttm_mem_global *glob)
{
+ uint64_t num_pages, num_dma32_pages;
+ struct ttm_mem_zone *zone;
struct sysinfo si;
int ret;
int i;
- struct ttm_mem_zone *zone;
spin_lock_init(&glob->lock);
glob->swap_queue = create_singlethread_workqueue("ttm_swap");
@@ -452,6 +454,19 @@ int ttm_mem_global_init(struct ttm_mem_global *glob)
zone->name, (unsigned long long)zone->max_mem >> 10);
}
ttm_pool_mgr_init(glob->zone_kernel->max_mem/(2*PAGE_SIZE));
+
+ /* We generally allow TTM to allocate a maximum of 50% of
+* the available system memory.
+*/
+ num_pages = (u64)si.totalram * si.mem_unit;
+ num_pages = (num_pages * 50 / 100) >> PAGE_SHIFT;
+
+ /* But for DMA32 we limit ourself to only use 2GiB maximum. */
+ num_dma32_pages = (u64)(si.totalram - si.totalhigh) * si.mem_unit;
+ num_dma32_pages = min(num_dma32_pages, 2ULL << 30) >> PAGE_SHIFT;
+
+ ttm_tt_mgr_init(num_pages, num_dma32_pages);
+
return 0;
out_no_zone:
ttm_mem_global_release(glob);
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index cfd633c7e764..c7b71c9861a6 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -38,6 +38,19 @@
#include
#include
+static unsigned long ttm_pages_limit;
+
+MODULE_PARM_DESC(pages_limit, "Limit for the allocated pages");
+module_param_named(pages_limit, ttm_pages_limit, ulong, 0644);
+
+static unsigned long ttm_dma32_pages_limit;
+
+MODULE_PARM_DESC(dma32_pages_limit, "Limit for the allocated DMA32 pages");
+module_param_named(dma32_pages_limit, ttm_dma32_pages_limit, ulong, 0644);
+
+static atomic_long_t ttm_pages_allocated;
+static atomic_long_t ttm_dma32_pages_allocated;
+
/**
* Allocates a ttm structure for the given BO.
*/
@@ -295,8 +308,8 @@ static void ttm_tt_add_mapping(struct ttm_bo_device *bdev,
struct ttm_tt *ttm)
ttm->pages[i]->mapping = bdev->dev_mapping;
}
-int ttm_tt_populate(struct ttm_bo_device *bdev,
- struct ttm_tt *ttm, struct ttm_operation_ctx *ctx)
+int ttm_tt_populate(struct ttm_bo_device *bdev, struct ttm_tt *ttm,
+ struct ttm_operation_ctx *ctx)
{
int ret;
@@ -306,12 +319,25 @@ int ttm_tt_populate(struct ttm_bo_device *bdev,
if (ttm_tt_is_populated(ttm))
return 0;
+ atomic_long_add(ttm->num_pages, &ttm_pages_allocated);
+ if (bdev->pool.use_dma32)
+ atomic_long_add(ttm->num_pages, &ttm_dma32_pages_allocated);
+
+ while (atomic_long_read(&ttm_pages_allocated) > ttm_pages_limit ||
+ atomic_long_read(&ttm_dma32_pages_allocated) >
+ ttm_dma32_pages_limit) {
+
+ ret = ttm_bo_swapout(ctx);
+ if (ret)
+ goto error;
+ }
+
if (bdev->driver->ttm_tt_populate)
ret = bdev->driver->ttm_tt_populate(bdev, ttm, ctx);
else
ret = ttm_pool_alloc(&bdev->pool, ttm, ctx);
if (ret)
- return ret;
+ goto error;
ttm_tt_add_mapping(b
[PATCH 3/3] drm/ttm: make up to 90% of system memory available
Increase the ammount of system memory drivers can use to about 90% of the total available. Signed-off-by: Christian König --- drivers/gpu/drm/ttm/ttm_bo.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index a958135cb3fe..0a93df93dba4 100644 --- a/drivers/gpu/drm/ttm/ttm_bo.c +++ b/drivers/gpu/drm/ttm/ttm_bo.c @@ -1267,7 +1267,7 @@ static int ttm_bo_global_init(void) * the available system memory. */ num_pages = (u64)si.totalram * si.mem_unit; - num_pages = (num_pages * 50 / 100) >> PAGE_SHIFT; + num_pages = (num_pages * 90 / 100) >> PAGE_SHIFT; /* But for DMA32 we limit ourself to only use 2GiB maximum. */ num_dma32_pages = (u64)(si.totalram - si.totalhigh) * si.mem_unit; -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdgpu: fix check oder in amdgpu_bo_move
Tested-by: Nirmoy Das Tested on commit 96fb3cbef165db97c999a02efe2287ba4b8c1ceb (HEAD,
drm-misc/drm-misc-next)
On 11/16/20 8:14 PM, Christian König wrote:
Reorder the code to fix checking if blitting is available.
Signed-off-by: Christian König
Fixes: f5a89a5cae81 drm/amdgpu/ttm: use multihop
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 53 +++--
1 file changed, 23 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 676fb520e044..c438d290a6db 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -551,25 +551,12 @@ static int amdgpu_bo_move(struct ttm_buffer_object *bo,
bool evict,
struct ttm_resource *old_mem = &bo->mem;
int r;
- if ((old_mem->mem_type == TTM_PL_SYSTEM &&
-new_mem->mem_type == TTM_PL_VRAM) ||
- (old_mem->mem_type == TTM_PL_VRAM &&
-new_mem->mem_type == TTM_PL_SYSTEM)) {
- hop->fpfn = 0;
- hop->lpfn = 0;
- hop->mem_type = TTM_PL_TT;
- hop->flags = 0;
- return -EMULTIHOP;
- }
-
if (new_mem->mem_type == TTM_PL_TT) {
r = amdgpu_ttm_backend_bind(bo->bdev, bo->ttm, new_mem);
if (r)
return r;
}
- amdgpu_bo_move_notify(bo, evict, new_mem);
-
/* Can't move a pinned BO */
abo = ttm_to_amdgpu_bo(bo);
if (WARN_ON_ONCE(abo->tbo.pin_count > 0))
@@ -579,24 +566,23 @@ static int amdgpu_bo_move(struct ttm_buffer_object *bo,
bool evict,
if (old_mem->mem_type == TTM_PL_SYSTEM && bo->ttm == NULL) {
ttm_bo_move_null(bo, new_mem);
- return 0;
+ goto out;
}
if (old_mem->mem_type == TTM_PL_SYSTEM &&
new_mem->mem_type == TTM_PL_TT) {
ttm_bo_move_null(bo, new_mem);
- return 0;
+ goto out;
}
-
if (old_mem->mem_type == TTM_PL_TT &&
new_mem->mem_type == TTM_PL_SYSTEM) {
r = ttm_bo_wait_ctx(bo, ctx);
if (r)
- goto fail;
+ return r;
amdgpu_ttm_backend_unbind(bo->bdev, bo->ttm);
ttm_resource_free(bo, &bo->mem);
ttm_bo_assign_mem(bo, new_mem);
- return 0;
+ goto out;
}
if (old_mem->mem_type == AMDGPU_PL_GDS ||
@@ -607,27 +593,37 @@ static int amdgpu_bo_move(struct ttm_buffer_object *bo,
bool evict,
new_mem->mem_type == AMDGPU_PL_OA) {
/* Nothing to save here */
ttm_bo_move_null(bo, new_mem);
- return 0;
+ goto out;
}
- if (!adev->mman.buffer_funcs_enabled) {
+ if (adev->mman.buffer_funcs_enabled) {
+ if (((old_mem->mem_type == TTM_PL_SYSTEM &&
+ new_mem->mem_type == TTM_PL_VRAM) ||
+(old_mem->mem_type == TTM_PL_VRAM &&
+ new_mem->mem_type == TTM_PL_SYSTEM))) {
+ hop->fpfn = 0;
+ hop->lpfn = 0;
+ hop->mem_type = TTM_PL_TT;
+ hop->flags = 0;
+ return -EMULTIHOP;
+ }
+
+ r = amdgpu_move_blit(bo, evict, new_mem, old_mem);
+ } else {
r = -ENODEV;
- goto memcpy;
}
- r = amdgpu_move_blit(bo, evict, new_mem, old_mem);
if (r) {
-memcpy:
/* Check that all memory is CPU accessible */
if (!amdgpu_mem_visible(adev, old_mem) ||
!amdgpu_mem_visible(adev, new_mem)) {
pr_err("Move buffer fallback to memcpy unavailable\n");
- goto fail;
+ return r;
}
r = ttm_bo_move_memcpy(bo, ctx, new_mem);
if (r)
- goto fail;
+ return r;
}
if (bo->type == ttm_bo_type_device &&
@@ -639,14 +635,11 @@ static int amdgpu_bo_move(struct ttm_buffer_object *bo,
bool evict,
abo->flags &= ~AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED;
}
+out:
/* update statistics */
atomic64_add((u64)bo->num_pages << PAGE_SHIFT, &adev->num_bytes_moved);
+ amdgpu_bo_move_notify(bo, evict, new_mem);
return 0;
-fail:
- swap(*new_mem, bo->mem);
- amdgpu_bo_move_notify(bo, false, new_mem);
- swap(*new_mem, bo->mem);
- return r;
}
/**
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 08/10] drm/fb-helper: Restore damage area upon errors
Hi,
On Mon, Nov 16, 2020 at 09:52:16PM +0100, Daniel Vetter wrote:
> On Mon, Nov 16, 2020 at 09:04:35PM +0100, Thomas Zimmermann wrote:
> > If the damage handling fails, restore the damage area. The next invocation
> > of the damage worker will then perform the update.
> >
> > Signed-off-by: Thomas Zimmermann
> > ---
> > drivers/gpu/drm/drm_fb_helper.c | 23 ---
> > 1 file changed, 20 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_fb_helper.c
> > b/drivers/gpu/drm/drm_fb_helper.c
> > index 2e1a335bafd2..13b65dad2ca8 100644
> > --- a/drivers/gpu/drm/drm_fb_helper.c
> > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > @@ -431,11 +431,28 @@ static void drm_fb_helper_damage_work(struct
> > work_struct *work)
> > if (helper->buffer) {
> > ret = drm_fb_helper_damage_blit(helper, &clip_copy);
> > if (ret)
> > - return;
> > + goto err;
> > }
> >
> > - if (helper->fb->funcs->dirty)
> > - helper->fb->funcs->dirty(helper->fb, NULL, 0, 0, &clip_copy, 1);
> > + if (helper->fb->funcs->dirty) {
> > + ret = helper->fb->funcs->dirty(helper->fb, NULL, 0, 0,
> > &clip_copy, 1);
> > + if (ret)
> > + goto err;
>
> I think this is unexpected enough that we should put some drm error
> printing here I think.
Note, that the dirty framebuffer routines are used by the
framebuffer console. Printing warnings means another line
in the framebuffer console and thus another call to the
dirty routines. Assuming the problem does not get solved
magically the system will be busy printing warnings forever.
I have been through that fun while working on the OMAP DSI
command mode patches and I suggest to only do ratelimited
logging in the code related to damage tracking.
-- Sebastian
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/ttm: fix DMA32 handling in the global page pool
When we have mixed DMA32 and non DMA32 device in one system
it could otherwise happen that the DMA32 device gets pages
it can't work with.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_pool.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
index 1b96780b4989..5455b2044759 100644
--- a/drivers/gpu/drm/ttm/ttm_pool.c
+++ b/drivers/gpu/drm/ttm/ttm_pool.c
@@ -63,6 +63,9 @@ static atomic_long_t allocated_pages;
static struct ttm_pool_type global_write_combined[MAX_ORDER];
static struct ttm_pool_type global_uncached[MAX_ORDER];
+static struct ttm_pool_type global_dma32_write_combined[MAX_ORDER];
+static struct ttm_pool_type global_dma32_uncached[MAX_ORDER];
+
static spinlock_t shrinker_lock;
static struct list_head shrinker_list;
static struct shrinker mm_shrinker;
@@ -290,8 +293,14 @@ static struct ttm_pool_type *ttm_pool_select_type(struct
ttm_pool *pool,
#ifdef CONFIG_X86
switch (caching) {
case ttm_write_combined:
+ if (pool->use_dma32)
+ return &global_dma32_write_combined[order];
+
return &global_write_combined[order];
case ttm_uncached:
+ if (pool->use_dma32)
+ return &global_dma32_uncached[order];
+
return &global_uncached[order];
default:
break;
@@ -570,6 +579,11 @@ int ttm_pool_debugfs(struct ttm_pool *pool, struct
seq_file *m)
seq_puts(m, "uc\t:");
ttm_pool_debugfs_orders(global_uncached, m);
+ seq_puts(m, "wc 32\t:");
+ ttm_pool_debugfs_orders(global_dma32_write_combined, m);
+ seq_puts(m, "uc 32\t:");
+ ttm_pool_debugfs_orders(global_dma32_uncached, m);
+
for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i) {
seq_puts(m, "DMA ");
switch (i) {
@@ -640,6 +654,11 @@ int ttm_pool_mgr_init(unsigned long num_pages)
ttm_pool_type_init(&global_write_combined[i], NULL,
ttm_write_combined, i);
ttm_pool_type_init(&global_uncached[i], NULL, ttm_uncached, i);
+
+ ttm_pool_type_init(&global_dma32_write_combined[i], NULL,
+ ttm_write_combined, i);
+ ttm_pool_type_init(&global_dma32_uncached[i], NULL,
+ ttm_uncached, i);
}
mm_shrinker.count_objects = ttm_pool_shrinker_count;
@@ -660,6 +679,9 @@ void ttm_pool_mgr_fini(void)
for (i = 0; i < MAX_ORDER; ++i) {
ttm_pool_type_fini(&global_write_combined[i]);
ttm_pool_type_fini(&global_uncached[i]);
+
+ ttm_pool_type_fini(&global_dma32_write_combined[i]);
+ ttm_pool_type_fini(&global_dma32_uncached[i]);
}
unregister_shrinker(&mm_shrinker);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4.19 082/101] drm/gma500: Fix out-of-bounds access to struct drm_device.vblank[]
From: Thomas Zimmermann
commit 06ad8d339524bf94b89859047822c31df6ace239 upstream.
The gma500 driver expects 3 pipelines in several it's IRQ functions.
Accessing struct drm_device.vblank[], this fails with devices that only
have 2 pipelines. An example KASAN report is shown below.
[ 62.267688]
==
[ 62.268856] BUG: KASAN: slab-out-of-bounds in
psb_irq_postinstall+0x250/0x3c0 [gma500_gfx]
[ 62.269450] Read of size 1 at addr 8880012bc6d0 by task
systemd-udevd/285
[ 62.269949]
[ 62.270192] CPU: 0 PID: 285 Comm: systemd-udevd Tainted: GE
5.10.0-rc1-1-default+ #572
[ 62.270807] Hardware name: /DN2800MT, BIOS
MTCDT10N.86A.0164.2012.1213.1024 12/13/2012
[ 62.271366] Call Trace:
[ 62.271705] dump_stack+0xae/0xe5
[ 62.272180] print_address_description.constprop.0+0x17/0xf0
[ 62.272987] ? psb_irq_postinstall+0x250/0x3c0 [gma500_gfx]
[ 62.273474] __kasan_report.cold+0x20/0x38
[ 62.273989] ? psb_irq_postinstall+0x250/0x3c0 [gma500_gfx]
[ 62.274460] kasan_report+0x3a/0x50
[ 62.274891] psb_irq_postinstall+0x250/0x3c0 [gma500_gfx]
[ 62.275380] drm_irq_install+0x131/0x1f0
<...>
[ 62.300751] Allocated by task 285:
[ 62.301223] kasan_save_stack+0x1b/0x40
[ 62.301731] __kasan_kmalloc.constprop.0+0xbf/0xd0
[ 62.302293] drmm_kmalloc+0x55/0x100
[ 62.302773] drm_vblank_init+0x77/0x210
Resolve the issue by only handling vblank entries up to the number of
CRTCs.
I'm adding a Fixes tag for reference, although the bug has been present
since the driver's initial commit.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
Fixes: 5c49fd3aa0ab ("gma500: Add the core DRM files and headers")
Cc: Alan Cox
Cc: Dave Airlie
Cc: Patrik Jakobsson
Cc: dri-devel@lists.freedesktop.org
Cc: sta...@vger.kernel.org#v3.3+
Link:
https://patchwork.freedesktop.org/patch/msgid/20201105190256.3893-1-tzimmerm...@suse.de
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/gma500/psb_irq.c | 34 --
1 file changed, 12 insertions(+), 22 deletions(-)
--- a/drivers/gpu/drm/gma500/psb_irq.c
+++ b/drivers/gpu/drm/gma500/psb_irq.c
@@ -350,6 +350,7 @@ int psb_irq_postinstall(struct drm_devic
{
struct drm_psb_private *dev_priv = dev->dev_private;
unsigned long irqflags;
+ unsigned int i;
spin_lock_irqsave(&dev_priv->irqmask_lock, irqflags);
@@ -362,20 +363,12 @@ int psb_irq_postinstall(struct drm_devic
PSB_WVDC32(dev_priv->vdc_irq_mask, PSB_INT_ENABLE_R);
PSB_WVDC32(0x, PSB_HWSTAM);
- if (dev->vblank[0].enabled)
- psb_enable_pipestat(dev_priv, 0, PIPE_VBLANK_INTERRUPT_ENABLE);
- else
- psb_disable_pipestat(dev_priv, 0, PIPE_VBLANK_INTERRUPT_ENABLE);
-
- if (dev->vblank[1].enabled)
- psb_enable_pipestat(dev_priv, 1, PIPE_VBLANK_INTERRUPT_ENABLE);
- else
- psb_disable_pipestat(dev_priv, 1, PIPE_VBLANK_INTERRUPT_ENABLE);
-
- if (dev->vblank[2].enabled)
- psb_enable_pipestat(dev_priv, 2, PIPE_VBLANK_INTERRUPT_ENABLE);
- else
- psb_disable_pipestat(dev_priv, 2, PIPE_VBLANK_INTERRUPT_ENABLE);
+ for (i = 0; i < dev->num_crtcs; ++i) {
+ if (dev->vblank[i].enabled)
+ psb_enable_pipestat(dev_priv, i,
PIPE_VBLANK_INTERRUPT_ENABLE);
+ else
+ psb_disable_pipestat(dev_priv, i,
PIPE_VBLANK_INTERRUPT_ENABLE);
+ }
if (dev_priv->ops->hotplug_enable)
dev_priv->ops->hotplug_enable(dev, true);
@@ -388,6 +381,7 @@ void psb_irq_uninstall(struct drm_device
{
struct drm_psb_private *dev_priv = dev->dev_private;
unsigned long irqflags;
+ unsigned int i;
spin_lock_irqsave(&dev_priv->irqmask_lock, irqflags);
@@ -396,14 +390,10 @@ void psb_irq_uninstall(struct drm_device
PSB_WVDC32(0x, PSB_HWSTAM);
- if (dev->vblank[0].enabled)
- psb_disable_pipestat(dev_priv, 0, PIPE_VBLANK_INTERRUPT_ENABLE);
-
- if (dev->vblank[1].enabled)
- psb_disable_pipestat(dev_priv, 1, PIPE_VBLANK_INTERRUPT_ENABLE);
-
- if (dev->vblank[2].enabled)
- psb_disable_pipestat(dev_priv, 2, PIPE_VBLANK_INTERRUPT_ENABLE);
+ for (i = 0; i < dev->num_crtcs; ++i) {
+ if (dev->vblank[i].enabled)
+ psb_disable_pipestat(dev_priv, i,
PIPE_VBLANK_INTERRUPT_ENABLE);
+ }
dev_priv->vdc_irq_mask &= _PSB_IRQ_SGX_FLAG |
_PSB_IRQ_MSVDX_FLAG |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4.14 54/85] drm/gma500: Fix out-of-bounds access to struct drm_device.vblank[]
From: Thomas Zimmermann
commit 06ad8d339524bf94b89859047822c31df6ace239 upstream.
The gma500 driver expects 3 pipelines in several it's IRQ functions.
Accessing struct drm_device.vblank[], this fails with devices that only
have 2 pipelines. An example KASAN report is shown below.
[ 62.267688]
==
[ 62.268856] BUG: KASAN: slab-out-of-bounds in
psb_irq_postinstall+0x250/0x3c0 [gma500_gfx]
[ 62.269450] Read of size 1 at addr 8880012bc6d0 by task
systemd-udevd/285
[ 62.269949]
[ 62.270192] CPU: 0 PID: 285 Comm: systemd-udevd Tainted: GE
5.10.0-rc1-1-default+ #572
[ 62.270807] Hardware name: /DN2800MT, BIOS
MTCDT10N.86A.0164.2012.1213.1024 12/13/2012
[ 62.271366] Call Trace:
[ 62.271705] dump_stack+0xae/0xe5
[ 62.272180] print_address_description.constprop.0+0x17/0xf0
[ 62.272987] ? psb_irq_postinstall+0x250/0x3c0 [gma500_gfx]
[ 62.273474] __kasan_report.cold+0x20/0x38
[ 62.273989] ? psb_irq_postinstall+0x250/0x3c0 [gma500_gfx]
[ 62.274460] kasan_report+0x3a/0x50
[ 62.274891] psb_irq_postinstall+0x250/0x3c0 [gma500_gfx]
[ 62.275380] drm_irq_install+0x131/0x1f0
<...>
[ 62.300751] Allocated by task 285:
[ 62.301223] kasan_save_stack+0x1b/0x40
[ 62.301731] __kasan_kmalloc.constprop.0+0xbf/0xd0
[ 62.302293] drmm_kmalloc+0x55/0x100
[ 62.302773] drm_vblank_init+0x77/0x210
Resolve the issue by only handling vblank entries up to the number of
CRTCs.
I'm adding a Fixes tag for reference, although the bug has been present
since the driver's initial commit.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
Fixes: 5c49fd3aa0ab ("gma500: Add the core DRM files and headers")
Cc: Alan Cox
Cc: Dave Airlie
Cc: Patrik Jakobsson
Cc: dri-devel@lists.freedesktop.org
Cc: sta...@vger.kernel.org#v3.3+
Link:
https://patchwork.freedesktop.org/patch/msgid/20201105190256.3893-1-tzimmerm...@suse.de
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/gma500/psb_irq.c | 34 --
1 file changed, 12 insertions(+), 22 deletions(-)
--- a/drivers/gpu/drm/gma500/psb_irq.c
+++ b/drivers/gpu/drm/gma500/psb_irq.c
@@ -350,6 +350,7 @@ int psb_irq_postinstall(struct drm_devic
{
struct drm_psb_private *dev_priv = dev->dev_private;
unsigned long irqflags;
+ unsigned int i;
spin_lock_irqsave(&dev_priv->irqmask_lock, irqflags);
@@ -362,20 +363,12 @@ int psb_irq_postinstall(struct drm_devic
PSB_WVDC32(dev_priv->vdc_irq_mask, PSB_INT_ENABLE_R);
PSB_WVDC32(0x, PSB_HWSTAM);
- if (dev->vblank[0].enabled)
- psb_enable_pipestat(dev_priv, 0, PIPE_VBLANK_INTERRUPT_ENABLE);
- else
- psb_disable_pipestat(dev_priv, 0, PIPE_VBLANK_INTERRUPT_ENABLE);
-
- if (dev->vblank[1].enabled)
- psb_enable_pipestat(dev_priv, 1, PIPE_VBLANK_INTERRUPT_ENABLE);
- else
- psb_disable_pipestat(dev_priv, 1, PIPE_VBLANK_INTERRUPT_ENABLE);
-
- if (dev->vblank[2].enabled)
- psb_enable_pipestat(dev_priv, 2, PIPE_VBLANK_INTERRUPT_ENABLE);
- else
- psb_disable_pipestat(dev_priv, 2, PIPE_VBLANK_INTERRUPT_ENABLE);
+ for (i = 0; i < dev->num_crtcs; ++i) {
+ if (dev->vblank[i].enabled)
+ psb_enable_pipestat(dev_priv, i,
PIPE_VBLANK_INTERRUPT_ENABLE);
+ else
+ psb_disable_pipestat(dev_priv, i,
PIPE_VBLANK_INTERRUPT_ENABLE);
+ }
if (dev_priv->ops->hotplug_enable)
dev_priv->ops->hotplug_enable(dev, true);
@@ -388,6 +381,7 @@ void psb_irq_uninstall(struct drm_device
{
struct drm_psb_private *dev_priv = dev->dev_private;
unsigned long irqflags;
+ unsigned int i;
spin_lock_irqsave(&dev_priv->irqmask_lock, irqflags);
@@ -396,14 +390,10 @@ void psb_irq_uninstall(struct drm_device
PSB_WVDC32(0x, PSB_HWSTAM);
- if (dev->vblank[0].enabled)
- psb_disable_pipestat(dev_priv, 0, PIPE_VBLANK_INTERRUPT_ENABLE);
-
- if (dev->vblank[1].enabled)
- psb_disable_pipestat(dev_priv, 1, PIPE_VBLANK_INTERRUPT_ENABLE);
-
- if (dev->vblank[2].enabled)
- psb_disable_pipestat(dev_priv, 2, PIPE_VBLANK_INTERRUPT_ENABLE);
+ for (i = 0; i < dev->num_crtcs; ++i) {
+ if (dev->vblank[i].enabled)
+ psb_disable_pipestat(dev_priv, i,
PIPE_VBLANK_INTERRUPT_ENABLE);
+ }
dev_priv->vdc_irq_mask &= _PSB_IRQ_SGX_FLAG |
_PSB_IRQ_MSVDX_FLAG |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4.9 49/78] drm/gma500: Fix out-of-bounds access to struct drm_device.vblank[]
From: Thomas Zimmermann
commit 06ad8d339524bf94b89859047822c31df6ace239 upstream.
The gma500 driver expects 3 pipelines in several it's IRQ functions.
Accessing struct drm_device.vblank[], this fails with devices that only
have 2 pipelines. An example KASAN report is shown below.
[ 62.267688]
==
[ 62.268856] BUG: KASAN: slab-out-of-bounds in
psb_irq_postinstall+0x250/0x3c0 [gma500_gfx]
[ 62.269450] Read of size 1 at addr 8880012bc6d0 by task
systemd-udevd/285
[ 62.269949]
[ 62.270192] CPU: 0 PID: 285 Comm: systemd-udevd Tainted: GE
5.10.0-rc1-1-default+ #572
[ 62.270807] Hardware name: /DN2800MT, BIOS
MTCDT10N.86A.0164.2012.1213.1024 12/13/2012
[ 62.271366] Call Trace:
[ 62.271705] dump_stack+0xae/0xe5
[ 62.272180] print_address_description.constprop.0+0x17/0xf0
[ 62.272987] ? psb_irq_postinstall+0x250/0x3c0 [gma500_gfx]
[ 62.273474] __kasan_report.cold+0x20/0x38
[ 62.273989] ? psb_irq_postinstall+0x250/0x3c0 [gma500_gfx]
[ 62.274460] kasan_report+0x3a/0x50
[ 62.274891] psb_irq_postinstall+0x250/0x3c0 [gma500_gfx]
[ 62.275380] drm_irq_install+0x131/0x1f0
<...>
[ 62.300751] Allocated by task 285:
[ 62.301223] kasan_save_stack+0x1b/0x40
[ 62.301731] __kasan_kmalloc.constprop.0+0xbf/0xd0
[ 62.302293] drmm_kmalloc+0x55/0x100
[ 62.302773] drm_vblank_init+0x77/0x210
Resolve the issue by only handling vblank entries up to the number of
CRTCs.
I'm adding a Fixes tag for reference, although the bug has been present
since the driver's initial commit.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
Fixes: 5c49fd3aa0ab ("gma500: Add the core DRM files and headers")
Cc: Alan Cox
Cc: Dave Airlie
Cc: Patrik Jakobsson
Cc: dri-devel@lists.freedesktop.org
Cc: sta...@vger.kernel.org#v3.3+
Link:
https://patchwork.freedesktop.org/patch/msgid/20201105190256.3893-1-tzimmerm...@suse.de
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/gma500/psb_irq.c | 34 --
1 file changed, 12 insertions(+), 22 deletions(-)
--- a/drivers/gpu/drm/gma500/psb_irq.c
+++ b/drivers/gpu/drm/gma500/psb_irq.c
@@ -350,6 +350,7 @@ int psb_irq_postinstall(struct drm_devic
{
struct drm_psb_private *dev_priv = dev->dev_private;
unsigned long irqflags;
+ unsigned int i;
spin_lock_irqsave(&dev_priv->irqmask_lock, irqflags);
@@ -362,20 +363,12 @@ int psb_irq_postinstall(struct drm_devic
PSB_WVDC32(dev_priv->vdc_irq_mask, PSB_INT_ENABLE_R);
PSB_WVDC32(0x, PSB_HWSTAM);
- if (dev->vblank[0].enabled)
- psb_enable_pipestat(dev_priv, 0, PIPE_VBLANK_INTERRUPT_ENABLE);
- else
- psb_disable_pipestat(dev_priv, 0, PIPE_VBLANK_INTERRUPT_ENABLE);
-
- if (dev->vblank[1].enabled)
- psb_enable_pipestat(dev_priv, 1, PIPE_VBLANK_INTERRUPT_ENABLE);
- else
- psb_disable_pipestat(dev_priv, 1, PIPE_VBLANK_INTERRUPT_ENABLE);
-
- if (dev->vblank[2].enabled)
- psb_enable_pipestat(dev_priv, 2, PIPE_VBLANK_INTERRUPT_ENABLE);
- else
- psb_disable_pipestat(dev_priv, 2, PIPE_VBLANK_INTERRUPT_ENABLE);
+ for (i = 0; i < dev->num_crtcs; ++i) {
+ if (dev->vblank[i].enabled)
+ psb_enable_pipestat(dev_priv, i,
PIPE_VBLANK_INTERRUPT_ENABLE);
+ else
+ psb_disable_pipestat(dev_priv, i,
PIPE_VBLANK_INTERRUPT_ENABLE);
+ }
if (dev_priv->ops->hotplug_enable)
dev_priv->ops->hotplug_enable(dev, true);
@@ -388,6 +381,7 @@ void psb_irq_uninstall(struct drm_device
{
struct drm_psb_private *dev_priv = dev->dev_private;
unsigned long irqflags;
+ unsigned int i;
spin_lock_irqsave(&dev_priv->irqmask_lock, irqflags);
@@ -396,14 +390,10 @@ void psb_irq_uninstall(struct drm_device
PSB_WVDC32(0x, PSB_HWSTAM);
- if (dev->vblank[0].enabled)
- psb_disable_pipestat(dev_priv, 0, PIPE_VBLANK_INTERRUPT_ENABLE);
-
- if (dev->vblank[1].enabled)
- psb_disable_pipestat(dev_priv, 1, PIPE_VBLANK_INTERRUPT_ENABLE);
-
- if (dev->vblank[2].enabled)
- psb_disable_pipestat(dev_priv, 2, PIPE_VBLANK_INTERRUPT_ENABLE);
+ for (i = 0; i < dev->num_crtcs; ++i) {
+ if (dev->vblank[i].enabled)
+ psb_disable_pipestat(dev_priv, i,
PIPE_VBLANK_INTERRUPT_ENABLE);
+ }
dev_priv->vdc_irq_mask &= _PSB_IRQ_SGX_FLAG |
_PSB_IRQ_MSVDX_FLAG |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5.9 230/255] drm/gma500: Fix out-of-bounds access to struct drm_device.vblank[]
From: Thomas Zimmermann
commit 06ad8d339524bf94b89859047822c31df6ace239 upstream.
The gma500 driver expects 3 pipelines in several it's IRQ functions.
Accessing struct drm_device.vblank[], this fails with devices that only
have 2 pipelines. An example KASAN report is shown below.
[ 62.267688]
==
[ 62.268856] BUG: KASAN: slab-out-of-bounds in
psb_irq_postinstall+0x250/0x3c0 [gma500_gfx]
[ 62.269450] Read of size 1 at addr 8880012bc6d0 by task
systemd-udevd/285
[ 62.269949]
[ 62.270192] CPU: 0 PID: 285 Comm: systemd-udevd Tainted: GE
5.10.0-rc1-1-default+ #572
[ 62.270807] Hardware name: /DN2800MT, BIOS
MTCDT10N.86A.0164.2012.1213.1024 12/13/2012
[ 62.271366] Call Trace:
[ 62.271705] dump_stack+0xae/0xe5
[ 62.272180] print_address_description.constprop.0+0x17/0xf0
[ 62.272987] ? psb_irq_postinstall+0x250/0x3c0 [gma500_gfx]
[ 62.273474] __kasan_report.cold+0x20/0x38
[ 62.273989] ? psb_irq_postinstall+0x250/0x3c0 [gma500_gfx]
[ 62.274460] kasan_report+0x3a/0x50
[ 62.274891] psb_irq_postinstall+0x250/0x3c0 [gma500_gfx]
[ 62.275380] drm_irq_install+0x131/0x1f0
<...>
[ 62.300751] Allocated by task 285:
[ 62.301223] kasan_save_stack+0x1b/0x40
[ 62.301731] __kasan_kmalloc.constprop.0+0xbf/0xd0
[ 62.302293] drmm_kmalloc+0x55/0x100
[ 62.302773] drm_vblank_init+0x77/0x210
Resolve the issue by only handling vblank entries up to the number of
CRTCs.
I'm adding a Fixes tag for reference, although the bug has been present
since the driver's initial commit.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
Fixes: 5c49fd3aa0ab ("gma500: Add the core DRM files and headers")
Cc: Alan Cox
Cc: Dave Airlie
Cc: Patrik Jakobsson
Cc: dri-devel@lists.freedesktop.org
Cc: sta...@vger.kernel.org#v3.3+
Link:
https://patchwork.freedesktop.org/patch/msgid/20201105190256.3893-1-tzimmerm...@suse.de
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/gma500/psb_irq.c | 34 --
1 file changed, 12 insertions(+), 22 deletions(-)
--- a/drivers/gpu/drm/gma500/psb_irq.c
+++ b/drivers/gpu/drm/gma500/psb_irq.c
@@ -347,6 +347,7 @@ int psb_irq_postinstall(struct drm_devic
{
struct drm_psb_private *dev_priv = dev->dev_private;
unsigned long irqflags;
+ unsigned int i;
spin_lock_irqsave(&dev_priv->irqmask_lock, irqflags);
@@ -359,20 +360,12 @@ int psb_irq_postinstall(struct drm_devic
PSB_WVDC32(dev_priv->vdc_irq_mask, PSB_INT_ENABLE_R);
PSB_WVDC32(0x, PSB_HWSTAM);
- if (dev->vblank[0].enabled)
- psb_enable_pipestat(dev_priv, 0, PIPE_VBLANK_INTERRUPT_ENABLE);
- else
- psb_disable_pipestat(dev_priv, 0, PIPE_VBLANK_INTERRUPT_ENABLE);
-
- if (dev->vblank[1].enabled)
- psb_enable_pipestat(dev_priv, 1, PIPE_VBLANK_INTERRUPT_ENABLE);
- else
- psb_disable_pipestat(dev_priv, 1, PIPE_VBLANK_INTERRUPT_ENABLE);
-
- if (dev->vblank[2].enabled)
- psb_enable_pipestat(dev_priv, 2, PIPE_VBLANK_INTERRUPT_ENABLE);
- else
- psb_disable_pipestat(dev_priv, 2, PIPE_VBLANK_INTERRUPT_ENABLE);
+ for (i = 0; i < dev->num_crtcs; ++i) {
+ if (dev->vblank[i].enabled)
+ psb_enable_pipestat(dev_priv, i,
PIPE_VBLANK_INTERRUPT_ENABLE);
+ else
+ psb_disable_pipestat(dev_priv, i,
PIPE_VBLANK_INTERRUPT_ENABLE);
+ }
if (dev_priv->ops->hotplug_enable)
dev_priv->ops->hotplug_enable(dev, true);
@@ -385,6 +378,7 @@ void psb_irq_uninstall(struct drm_device
{
struct drm_psb_private *dev_priv = dev->dev_private;
unsigned long irqflags;
+ unsigned int i;
spin_lock_irqsave(&dev_priv->irqmask_lock, irqflags);
@@ -393,14 +387,10 @@ void psb_irq_uninstall(struct drm_device
PSB_WVDC32(0x, PSB_HWSTAM);
- if (dev->vblank[0].enabled)
- psb_disable_pipestat(dev_priv, 0, PIPE_VBLANK_INTERRUPT_ENABLE);
-
- if (dev->vblank[1].enabled)
- psb_disable_pipestat(dev_priv, 1, PIPE_VBLANK_INTERRUPT_ENABLE);
-
- if (dev->vblank[2].enabled)
- psb_disable_pipestat(dev_priv, 2, PIPE_VBLANK_INTERRUPT_ENABLE);
+ for (i = 0; i < dev->num_crtcs; ++i) {
+ if (dev->vblank[i].enabled)
+ psb_disable_pipestat(dev_priv, i,
PIPE_VBLANK_INTERRUPT_ENABLE);
+ }
dev_priv->vdc_irq_mask &= _PSB_IRQ_SGX_FLAG |
_PSB_IRQ_MSVDX_FLAG |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4.4 38/64] drm/gma500: Fix out-of-bounds access to struct drm_device.vblank[]
From: Thomas Zimmermann
commit 06ad8d339524bf94b89859047822c31df6ace239 upstream.
The gma500 driver expects 3 pipelines in several it's IRQ functions.
Accessing struct drm_device.vblank[], this fails with devices that only
have 2 pipelines. An example KASAN report is shown below.
[ 62.267688]
==
[ 62.268856] BUG: KASAN: slab-out-of-bounds in
psb_irq_postinstall+0x250/0x3c0 [gma500_gfx]
[ 62.269450] Read of size 1 at addr 8880012bc6d0 by task
systemd-udevd/285
[ 62.269949]
[ 62.270192] CPU: 0 PID: 285 Comm: systemd-udevd Tainted: GE
5.10.0-rc1-1-default+ #572
[ 62.270807] Hardware name: /DN2800MT, BIOS
MTCDT10N.86A.0164.2012.1213.1024 12/13/2012
[ 62.271366] Call Trace:
[ 62.271705] dump_stack+0xae/0xe5
[ 62.272180] print_address_description.constprop.0+0x17/0xf0
[ 62.272987] ? psb_irq_postinstall+0x250/0x3c0 [gma500_gfx]
[ 62.273474] __kasan_report.cold+0x20/0x38
[ 62.273989] ? psb_irq_postinstall+0x250/0x3c0 [gma500_gfx]
[ 62.274460] kasan_report+0x3a/0x50
[ 62.274891] psb_irq_postinstall+0x250/0x3c0 [gma500_gfx]
[ 62.275380] drm_irq_install+0x131/0x1f0
<...>
[ 62.300751] Allocated by task 285:
[ 62.301223] kasan_save_stack+0x1b/0x40
[ 62.301731] __kasan_kmalloc.constprop.0+0xbf/0xd0
[ 62.302293] drmm_kmalloc+0x55/0x100
[ 62.302773] drm_vblank_init+0x77/0x210
Resolve the issue by only handling vblank entries up to the number of
CRTCs.
I'm adding a Fixes tag for reference, although the bug has been present
since the driver's initial commit.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
Fixes: 5c49fd3aa0ab ("gma500: Add the core DRM files and headers")
Cc: Alan Cox
Cc: Dave Airlie
Cc: Patrik Jakobsson
Cc: dri-devel@lists.freedesktop.org
Cc: sta...@vger.kernel.org#v3.3+
Link:
https://patchwork.freedesktop.org/patch/msgid/20201105190256.3893-1-tzimmerm...@suse.de
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/gma500/psb_irq.c | 34 --
1 file changed, 12 insertions(+), 22 deletions(-)
--- a/drivers/gpu/drm/gma500/psb_irq.c
+++ b/drivers/gpu/drm/gma500/psb_irq.c
@@ -350,6 +350,7 @@ int psb_irq_postinstall(struct drm_devic
{
struct drm_psb_private *dev_priv = dev->dev_private;
unsigned long irqflags;
+ unsigned int i;
spin_lock_irqsave(&dev_priv->irqmask_lock, irqflags);
@@ -362,20 +363,12 @@ int psb_irq_postinstall(struct drm_devic
PSB_WVDC32(dev_priv->vdc_irq_mask, PSB_INT_ENABLE_R);
PSB_WVDC32(0x, PSB_HWSTAM);
- if (dev->vblank[0].enabled)
- psb_enable_pipestat(dev_priv, 0, PIPE_VBLANK_INTERRUPT_ENABLE);
- else
- psb_disable_pipestat(dev_priv, 0, PIPE_VBLANK_INTERRUPT_ENABLE);
-
- if (dev->vblank[1].enabled)
- psb_enable_pipestat(dev_priv, 1, PIPE_VBLANK_INTERRUPT_ENABLE);
- else
- psb_disable_pipestat(dev_priv, 1, PIPE_VBLANK_INTERRUPT_ENABLE);
-
- if (dev->vblank[2].enabled)
- psb_enable_pipestat(dev_priv, 2, PIPE_VBLANK_INTERRUPT_ENABLE);
- else
- psb_disable_pipestat(dev_priv, 2, PIPE_VBLANK_INTERRUPT_ENABLE);
+ for (i = 0; i < dev->num_crtcs; ++i) {
+ if (dev->vblank[i].enabled)
+ psb_enable_pipestat(dev_priv, i,
PIPE_VBLANK_INTERRUPT_ENABLE);
+ else
+ psb_disable_pipestat(dev_priv, i,
PIPE_VBLANK_INTERRUPT_ENABLE);
+ }
if (dev_priv->ops->hotplug_enable)
dev_priv->ops->hotplug_enable(dev, true);
@@ -388,6 +381,7 @@ void psb_irq_uninstall(struct drm_device
{
struct drm_psb_private *dev_priv = dev->dev_private;
unsigned long irqflags;
+ unsigned int i;
spin_lock_irqsave(&dev_priv->irqmask_lock, irqflags);
@@ -396,14 +390,10 @@ void psb_irq_uninstall(struct drm_device
PSB_WVDC32(0x, PSB_HWSTAM);
- if (dev->vblank[0].enabled)
- psb_disable_pipestat(dev_priv, 0, PIPE_VBLANK_INTERRUPT_ENABLE);
-
- if (dev->vblank[1].enabled)
- psb_disable_pipestat(dev_priv, 1, PIPE_VBLANK_INTERRUPT_ENABLE);
-
- if (dev->vblank[2].enabled)
- psb_disable_pipestat(dev_priv, 2, PIPE_VBLANK_INTERRUPT_ENABLE);
+ for (i = 0; i < dev->num_crtcs; ++i) {
+ if (dev->vblank[i].enabled)
+ psb_disable_pipestat(dev_priv, i,
PIPE_VBLANK_INTERRUPT_ENABLE);
+ }
dev_priv->vdc_irq_mask &= _PSB_IRQ_SGX_FLAG |
_PSB_IRQ_MSVDX_FLAG |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5.4 134/151] drm/gma500: Fix out-of-bounds access to struct drm_device.vblank[]
From: Thomas Zimmermann
commit 06ad8d339524bf94b89859047822c31df6ace239 upstream.
The gma500 driver expects 3 pipelines in several it's IRQ functions.
Accessing struct drm_device.vblank[], this fails with devices that only
have 2 pipelines. An example KASAN report is shown below.
[ 62.267688]
==
[ 62.268856] BUG: KASAN: slab-out-of-bounds in
psb_irq_postinstall+0x250/0x3c0 [gma500_gfx]
[ 62.269450] Read of size 1 at addr 8880012bc6d0 by task
systemd-udevd/285
[ 62.269949]
[ 62.270192] CPU: 0 PID: 285 Comm: systemd-udevd Tainted: GE
5.10.0-rc1-1-default+ #572
[ 62.270807] Hardware name: /DN2800MT, BIOS
MTCDT10N.86A.0164.2012.1213.1024 12/13/2012
[ 62.271366] Call Trace:
[ 62.271705] dump_stack+0xae/0xe5
[ 62.272180] print_address_description.constprop.0+0x17/0xf0
[ 62.272987] ? psb_irq_postinstall+0x250/0x3c0 [gma500_gfx]
[ 62.273474] __kasan_report.cold+0x20/0x38
[ 62.273989] ? psb_irq_postinstall+0x250/0x3c0 [gma500_gfx]
[ 62.274460] kasan_report+0x3a/0x50
[ 62.274891] psb_irq_postinstall+0x250/0x3c0 [gma500_gfx]
[ 62.275380] drm_irq_install+0x131/0x1f0
<...>
[ 62.300751] Allocated by task 285:
[ 62.301223] kasan_save_stack+0x1b/0x40
[ 62.301731] __kasan_kmalloc.constprop.0+0xbf/0xd0
[ 62.302293] drmm_kmalloc+0x55/0x100
[ 62.302773] drm_vblank_init+0x77/0x210
Resolve the issue by only handling vblank entries up to the number of
CRTCs.
I'm adding a Fixes tag for reference, although the bug has been present
since the driver's initial commit.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
Fixes: 5c49fd3aa0ab ("gma500: Add the core DRM files and headers")
Cc: Alan Cox
Cc: Dave Airlie
Cc: Patrik Jakobsson
Cc: dri-devel@lists.freedesktop.org
Cc: sta...@vger.kernel.org#v3.3+
Link:
https://patchwork.freedesktop.org/patch/msgid/20201105190256.3893-1-tzimmerm...@suse.de
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/gma500/psb_irq.c | 34 --
1 file changed, 12 insertions(+), 22 deletions(-)
--- a/drivers/gpu/drm/gma500/psb_irq.c
+++ b/drivers/gpu/drm/gma500/psb_irq.c
@@ -337,6 +337,7 @@ int psb_irq_postinstall(struct drm_devic
{
struct drm_psb_private *dev_priv = dev->dev_private;
unsigned long irqflags;
+ unsigned int i;
spin_lock_irqsave(&dev_priv->irqmask_lock, irqflags);
@@ -349,20 +350,12 @@ int psb_irq_postinstall(struct drm_devic
PSB_WVDC32(dev_priv->vdc_irq_mask, PSB_INT_ENABLE_R);
PSB_WVDC32(0x, PSB_HWSTAM);
- if (dev->vblank[0].enabled)
- psb_enable_pipestat(dev_priv, 0, PIPE_VBLANK_INTERRUPT_ENABLE);
- else
- psb_disable_pipestat(dev_priv, 0, PIPE_VBLANK_INTERRUPT_ENABLE);
-
- if (dev->vblank[1].enabled)
- psb_enable_pipestat(dev_priv, 1, PIPE_VBLANK_INTERRUPT_ENABLE);
- else
- psb_disable_pipestat(dev_priv, 1, PIPE_VBLANK_INTERRUPT_ENABLE);
-
- if (dev->vblank[2].enabled)
- psb_enable_pipestat(dev_priv, 2, PIPE_VBLANK_INTERRUPT_ENABLE);
- else
- psb_disable_pipestat(dev_priv, 2, PIPE_VBLANK_INTERRUPT_ENABLE);
+ for (i = 0; i < dev->num_crtcs; ++i) {
+ if (dev->vblank[i].enabled)
+ psb_enable_pipestat(dev_priv, i,
PIPE_VBLANK_INTERRUPT_ENABLE);
+ else
+ psb_disable_pipestat(dev_priv, i,
PIPE_VBLANK_INTERRUPT_ENABLE);
+ }
if (dev_priv->ops->hotplug_enable)
dev_priv->ops->hotplug_enable(dev, true);
@@ -375,6 +368,7 @@ void psb_irq_uninstall(struct drm_device
{
struct drm_psb_private *dev_priv = dev->dev_private;
unsigned long irqflags;
+ unsigned int i;
spin_lock_irqsave(&dev_priv->irqmask_lock, irqflags);
@@ -383,14 +377,10 @@ void psb_irq_uninstall(struct drm_device
PSB_WVDC32(0x, PSB_HWSTAM);
- if (dev->vblank[0].enabled)
- psb_disable_pipestat(dev_priv, 0, PIPE_VBLANK_INTERRUPT_ENABLE);
-
- if (dev->vblank[1].enabled)
- psb_disable_pipestat(dev_priv, 1, PIPE_VBLANK_INTERRUPT_ENABLE);
-
- if (dev->vblank[2].enabled)
- psb_disable_pipestat(dev_priv, 2, PIPE_VBLANK_INTERRUPT_ENABLE);
+ for (i = 0; i < dev->num_crtcs; ++i) {
+ if (dev->vblank[i].enabled)
+ psb_disable_pipestat(dev_priv, i,
PIPE_VBLANK_INTERRUPT_ENABLE);
+ }
dev_priv->vdc_irq_mask &= _PSB_IRQ_SGX_FLAG |
_PSB_IRQ_MSVDX_FLAG |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/10] drm/fb-helper: Call dirty helper after writing to fbdev
On Mon, Nov 16, 2020 at 09:04:28PM +0100, Thomas Zimmermann wrote:
> If fbdev uses a shadow framebuffer, call the damage handler. Otherwise
> the update might not make it to the screen.
>
> Signed-off-by: Thomas Zimmermann
> Fixes: 222ec45f4c69 ("drm/fb_helper: Support framebuffers in I/O memory")
> Cc: Thomas Zimmermann
> Cc: Daniel Vetter
> Cc: Sam Ravnborg
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Gerd Hoffmann
> Cc: dri-devel@lists.freedesktop.org
> Cc: virtualizat...@lists.linux-foundation.org
> ---
> drivers/gpu/drm/drm_fb_helper.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 25edf670867c..ee1a19e22df2 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -2189,6 +2189,9 @@ static ssize_t drm_fbdev_fb_write(struct fb_info *info,
> const char __user *buf,
> if (ret > 0)
> *ppos += ret;
>
> + if (ret > 0)
> + drm_fb_helper_dirty(info, 0, 0, info->var.xres, info->var.yres);
Should that rather be 0->{x,y}res_virtual or {x,y}offset->{x,y}res?
> +
> return ret ? ret : err;
> }
>
> --
> 2.29.2
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/4] drm/ttm: add a debugfs file for the global page pools
Instead of printing this on the per device pool.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_pool.c | 70 --
1 file changed, 50 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
index 24ae7c23cfd0..5daf812551ee 100644
--- a/drivers/gpu/drm/ttm/ttm_pool.c
+++ b/drivers/gpu/drm/ttm/ttm_pool.c
@@ -42,6 +42,8 @@
#include
#include
+#include "ttm_module.h"
+
/**
* struct ttm_pool_dma - Helper object for coherent DMA mappings
*
@@ -533,6 +535,17 @@ EXPORT_SYMBOL(ttm_pool_fini);
#ifdef CONFIG_DEBUG_FS
+/* Print a nice header for the order */
+static void ttm_pool_debugfs_header(struct seq_file *m)
+{
+ unsigned int i;
+
+ seq_puts(m, "\t ");
+ for (i = 0; i < MAX_ORDER; ++i)
+ seq_printf(m, " ---%2u---", i);
+ seq_puts(m, "\n");
+}
+
/* Dump information about the different pool types */
static void ttm_pool_debugfs_orders(struct ttm_pool_type *pt,
struct seq_file *m)
@@ -544,6 +557,35 @@ static void ttm_pool_debugfs_orders(struct ttm_pool_type
*pt,
seq_puts(m, "\n");
}
+/* Dump the total amount of allocated pages */
+static void ttm_pool_debugfs_footer(struct seq_file *m)
+{
+ seq_printf(m, "\ntotal\t: %8lu of %8lu\n",
+ atomic_long_read(&allocated_pages), page_pool_size);
+}
+
+/* Dump the information for the global pools */
+static int ttm_pool_debugfs_globals_show(struct seq_file *m, void *data)
+{
+ ttm_pool_debugfs_header(m);
+
+ spin_lock(&shrinker_lock);
+ seq_puts(m, "wc\t:");
+ ttm_pool_debugfs_orders(global_write_combined, m);
+ seq_puts(m, "uc\t:");
+ ttm_pool_debugfs_orders(global_uncached, m);
+ seq_puts(m, "wc 32\t:");
+ ttm_pool_debugfs_orders(global_dma32_write_combined, m);
+ seq_puts(m, "uc 32\t:");
+ ttm_pool_debugfs_orders(global_dma32_uncached, m);
+ spin_unlock(&shrinker_lock);
+
+ ttm_pool_debugfs_footer(m);
+
+ return 0;
+}
+DEFINE_SHOW_ATTRIBUTE(ttm_pool_debugfs_globals);
+
/**
* ttm_pool_debugfs - Debugfs dump function for a pool
*
@@ -556,23 +598,9 @@ int ttm_pool_debugfs(struct ttm_pool *pool, struct
seq_file *m)
{
unsigned int i;
- spin_lock(&shrinker_lock);
-
- seq_puts(m, "\t ");
- for (i = 0; i < MAX_ORDER; ++i)
- seq_printf(m, " ---%2u---", i);
- seq_puts(m, "\n");
-
- seq_puts(m, "wc\t:");
- ttm_pool_debugfs_orders(global_write_combined, m);
- seq_puts(m, "uc\t:");
- ttm_pool_debugfs_orders(global_uncached, m);
-
- seq_puts(m, "wc 32\t:");
- ttm_pool_debugfs_orders(global_dma32_write_combined, m);
- seq_puts(m, "uc 32\t:");
- ttm_pool_debugfs_orders(global_dma32_uncached, m);
+ ttm_pool_debugfs_header(m);
+ spin_lock(&shrinker_lock);
for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i) {
seq_puts(m, "DMA ");
switch (i) {
@@ -588,12 +616,9 @@ int ttm_pool_debugfs(struct ttm_pool *pool, struct
seq_file *m)
}
ttm_pool_debugfs_orders(pool->caching[i].orders, m);
}
-
- seq_printf(m, "\ntotal\t: %8lu of %8lu\n",
- atomic_long_read(&allocated_pages), page_pool_size);
-
spin_unlock(&shrinker_lock);
+ ttm_pool_debugfs_footer(m);
return 0;
}
EXPORT_SYMBOL(ttm_pool_debugfs);
@@ -650,6 +675,11 @@ int ttm_pool_mgr_init(unsigned long num_pages)
ttm_uncached, i);
}
+#ifdef CONFIG_DEBUG_FS
+ debugfs_create_file("page_pool", 0444, ttm_debugfs_root, NULL,
+ &ttm_pool_debugfs_globals_fops);
+#endif
+
mm_shrinker.count_objects = ttm_pool_shrinker_count;
mm_shrinker.scan_objects = ttm_pool_shrinker_scan;
mm_shrinker.seeks = 1;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] drm/ttm/drivers: remove unecessary ttm_module.h include
ttm_module.h deals with internals of TTM and should never be include outside of it. Signed-off-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 - drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 1 - drivers/gpu/drm/nouveau/nouveau_drv.h | 1 - drivers/gpu/drm/qxl/qxl_drv.h | 1 - drivers/gpu/drm/qxl/qxl_ttm.c | 1 - drivers/gpu/drm/radeon/radeon.h | 1 - drivers/gpu/drm/radeon/radeon_ttm.c | 1 - drivers/gpu/drm/ttm/ttm_agp_backend.c | 1 - drivers/gpu/drm/ttm/ttm_bo_vm.c | 1 - drivers/gpu/drm/ttm/ttm_range_manager.c | 1 - drivers/gpu/drm/vmwgfx/ttm_object.c | 1 - drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 1 - drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 1 - drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 1 - drivers/gpu/drm/vmwgfx/vmwgfx_thp.c | 1 - include/drm/ttm/ttm_bo_driver.h | 1 - 16 files changed, 16 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h b/drivers/gpu/drm/amd/amdgpu/amdgpu.h index 183b09d71b64..6e042b4ed13d 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h @@ -55,7 +55,6 @@ #include #include #include -#include #include #include diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c index c438d290a6db..967859c6be3c 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c @@ -46,7 +46,6 @@ #include #include #include -#include #include #include diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h b/drivers/gpu/drm/nouveau/nouveau_drv.h index 8e90b3e47bbe..700fa0979d14 100644 --- a/drivers/gpu/drm/nouveau/nouveau_drv.h +++ b/drivers/gpu/drm/nouveau/nouveau_drv.h @@ -54,7 +54,6 @@ #include #include #include -#include #include diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h index 8bd0f916dfbc..83b54f0dad61 100644 --- a/drivers/gpu/drm/qxl/qxl_drv.h +++ b/drivers/gpu/drm/qxl/qxl_drv.h @@ -46,7 +46,6 @@ #include #include #include -#include #include #include "qxl_dev.h" diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c index 128c38c8a837..0cc661df2258 100644 --- a/drivers/gpu/drm/qxl/qxl_ttm.c +++ b/drivers/gpu/drm/qxl/qxl_ttm.c @@ -31,7 +31,6 @@ #include #include #include -#include #include #include "qxl_drv.h" diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h index 28cb8ced91b9..428c561a4e2c 100644 --- a/drivers/gpu/drm/radeon/radeon.h +++ b/drivers/gpu/drm/radeon/radeon.h @@ -75,7 +75,6 @@ #include #include #include -#include #include #include diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c index 0ca381b95d3d..2259d3811a45 100644 --- a/drivers/gpu/drm/radeon/radeon_ttm.c +++ b/drivers/gpu/drm/radeon/radeon_ttm.c @@ -46,7 +46,6 @@ #include #include #include -#include #include #include "radeon_reg.h" diff --git a/drivers/gpu/drm/ttm/ttm_agp_backend.c b/drivers/gpu/drm/ttm/ttm_agp_backend.c index 03c86628e4ac..8f9fa4188897 100644 --- a/drivers/gpu/drm/ttm/ttm_agp_backend.c +++ b/drivers/gpu/drm/ttm/ttm_agp_backend.c @@ -32,7 +32,6 @@ #define pr_fmt(fmt) "[TTM] " fmt -#include #include #include #include diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c index 2944fa0af493..144a4940b6b6 100644 --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c @@ -31,7 +31,6 @@ #define pr_fmt(fmt) "[TTM] " fmt -#include #include #include #include diff --git a/drivers/gpu/drm/ttm/ttm_range_manager.c b/drivers/gpu/drm/ttm/ttm_range_manager.c index ea77919569a2..4c0c756c9124 100644 --- a/drivers/gpu/drm/ttm/ttm_range_manager.c +++ b/drivers/gpu/drm/ttm/ttm_range_manager.c @@ -29,7 +29,6 @@ * Authors: Thomas Hellstrom */ -#include #include #include #include diff --git a/drivers/gpu/drm/vmwgfx/ttm_object.c b/drivers/gpu/drm/vmwgfx/ttm_object.c index 16077785ad47..0fe869d0fad1 100644 --- a/drivers/gpu/drm/vmwgfx/ttm_object.c +++ b/drivers/gpu/drm/vmwgfx/ttm_object.c @@ -59,7 +59,6 @@ #define pr_fmt(fmt) "[TTM] " fmt -#include #include #include #include diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c index 1310857879e7..e6de876a016a 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c @@ -35,7 +35,6 @@ #include #include #include -#include #include #include "ttm_object.h" diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h index b45becbb00f8..5b9a28157dd3 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h @@ -39,7 +39,6 @@ #include #include -#include #include "ttm_lock.h" #include "ttm_object.h" diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx
[PATCH 4/4] drm/ttm: optimize ttm pool shrinker a bit
Only initialize the DMA coherent pools if they are used.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_pool.c | 23 ---
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
index 5daf812551ee..54253aa09ffb 100644
--- a/drivers/gpu/drm/ttm/ttm_pool.c
+++ b/drivers/gpu/drm/ttm/ttm_pool.c
@@ -508,10 +508,12 @@ void ttm_pool_init(struct ttm_pool *pool, struct device
*dev,
pool->use_dma_alloc = use_dma_alloc;
pool->use_dma32 = use_dma32;
- for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i)
- for (j = 0; j < MAX_ORDER; ++j)
- ttm_pool_type_init(&pool->caching[i].orders[j],
- pool, i, j);
+ if (use_dma_alloc) {
+ for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i)
+ for (j = 0; j < MAX_ORDER; ++j)
+ ttm_pool_type_init(&pool->caching[i].orders[j],
+ pool, i, j);
+ }
}
EXPORT_SYMBOL(ttm_pool_init);
@@ -527,9 +529,11 @@ void ttm_pool_fini(struct ttm_pool *pool)
{
unsigned int i, j;
- for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i)
- for (j = 0; j < MAX_ORDER; ++j)
- ttm_pool_type_fini(&pool->caching[i].orders[j]);
+ if (pool->use_dma_alloc) {
+ for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i)
+ for (j = 0; j < MAX_ORDER; ++j)
+ ttm_pool_type_fini(&pool->caching[i].orders[j]);
+ }
}
EXPORT_SYMBOL(ttm_pool_fini);
@@ -598,6 +602,11 @@ int ttm_pool_debugfs(struct ttm_pool *pool, struct
seq_file *m)
{
unsigned int i;
+ if (!pool->use_dma_alloc) {
+ seq_puts(m, "unused\n");
+ return 0;
+ }
+
ttm_pool_debugfs_header(m);
spin_lock(&shrinker_lock);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/4] drm/ttm: replace sysfs with debugfs
As far as I can tell this has never been used by any
userspace application.
The number of BOs in the system is far better suited in
debugfs than sysfs and we now should be able to add other
information here as well.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 51 ++--
drivers/gpu/drm/ttm/ttm_module.c | 58 ++-
{include => drivers/gpu}/drm/ttm/ttm_module.h | 8 +--
include/drm/ttm/ttm_bo_driver.h | 1 -
4 files changed, 13 insertions(+), 105 deletions(-)
rename {include => drivers/gpu}/drm/ttm/ttm_module.h (94%)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 0a93df93dba4..cd1273c76c51 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -31,7 +31,6 @@
#define pr_fmt(fmt) "[TTM] " fmt
-#include
#include
#include
#include
@@ -43,7 +42,7 @@
#include
#include
-static void ttm_bo_global_kobj_release(struct kobject *kobj);
+#include "ttm_module.h"
/**
* ttm_global_mutex - protecting the global BO state
@@ -53,11 +52,6 @@ unsigned ttm_bo_glob_use_count;
struct ttm_bo_global ttm_bo_glob;
EXPORT_SYMBOL(ttm_bo_glob);
-static struct attribute ttm_bo_count = {
- .name = "bo_count",
- .mode = S_IRUGO
-};
-
/* default destructor */
static void ttm_bo_default_destroy(struct ttm_buffer_object *bo)
{
@@ -83,32 +77,6 @@ static void ttm_bo_mem_space_debug(struct ttm_buffer_object
*bo,
}
}
-static ssize_t ttm_bo_global_show(struct kobject *kobj,
- struct attribute *attr,
- char *buffer)
-{
- struct ttm_bo_global *glob =
- container_of(kobj, struct ttm_bo_global, kobj);
-
- return snprintf(buffer, PAGE_SIZE, "%d\n",
- atomic_read(&glob->bo_count));
-}
-
-static struct attribute *ttm_bo_global_attrs[] = {
- &ttm_bo_count,
- NULL
-};
-
-static const struct sysfs_ops ttm_bo_global_ops = {
- .show = &ttm_bo_global_show
-};
-
-static struct kobj_type ttm_bo_glob_kobj_type = {
- .release = &ttm_bo_global_kobj_release,
- .sysfs_ops = &ttm_bo_global_ops,
- .default_attrs = ttm_bo_global_attrs
-};
-
static void ttm_bo_add_mem_to_lru(struct ttm_buffer_object *bo,
struct ttm_resource *mem)
{
@@ -1216,14 +1184,6 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
}
EXPORT_SYMBOL(ttm_bo_init);
-static void ttm_bo_global_kobj_release(struct kobject *kobj)
-{
- struct ttm_bo_global *glob =
- container_of(kobj, struct ttm_bo_global, kobj);
-
- __free_page(glob->dummy_read_page);
-}
-
static void ttm_bo_global_release(void)
{
struct ttm_bo_global *glob = &ttm_bo_glob;
@@ -1233,9 +1193,8 @@ static void ttm_bo_global_release(void)
goto out;
ttm_pool_mgr_fini();
+ __free_page(glob->dummy_read_page);
- kobject_del(&glob->kobj);
- kobject_put(&glob->kobj);
memset(glob, 0, sizeof(*glob));
out:
mutex_unlock(&ttm_global_mutex);
@@ -1288,10 +1247,8 @@ static int ttm_bo_global_init(void)
INIT_LIST_HEAD(&glob->device_list);
atomic_set(&glob->bo_count, 0);
- ret = kobject_init_and_add(
- &glob->kobj, &ttm_bo_glob_kobj_type, ttm_get_kobj(),
"buffer_objects");
- if (unlikely(ret != 0))
- kobject_put(&glob->kobj);
+ debugfs_create_atomic_t("buffer_objects", 0444, ttm_debugfs_root,
+ &glob->bo_count);
out:
mutex_unlock(&ttm_global_mutex);
return ret;
diff --git a/drivers/gpu/drm/ttm/ttm_module.c b/drivers/gpu/drm/ttm/ttm_module.c
index 6ff40c041d79..ac295861a688 100644
--- a/drivers/gpu/drm/ttm/ttm_module.c
+++ b/drivers/gpu/drm/ttm/ttm_module.c
@@ -30,69 +30,21 @@
* Jerome Glisse
*/
#include
-#include
-#include
-#include
-#include
+#include
-static DECLARE_WAIT_QUEUE_HEAD(exit_q);
-static atomic_t device_released;
+#include "ttm_module.h"
-static struct device_type ttm_drm_class_type = {
- .name = "ttm",
- /**
-* Add pm ops here.
-*/
-};
-
-static void ttm_drm_class_device_release(struct device *dev)
-{
- atomic_set(&device_released, 1);
- wake_up_all(&exit_q);
-}
-
-static struct device ttm_drm_class_device = {
- .type = &ttm_drm_class_type,
- .release = &ttm_drm_class_device_release
-};
-
-struct kobject *ttm_get_kobj(void)
-{
- struct kobject *kobj = &ttm_drm_class_device.kobj;
- BUG_ON(kobj == NULL);
- return kobj;
-}
+struct dentry *ttm_debugfs_root;
static int __init ttm_init(void)
{
- int ret;
-
- ret = dev_set_name(&ttm_drm_class_device, "ttm");
- if (unlikely(ret != 0))
- return ret;
-
- atomic_set(&device_released, 0);
- ret = drm_class_device_register(&ttm_drm_class_device);
- if (unlikely(ret != 0
Re: [PATCH 3/3] drm/ttm: make up to 90% of system memory available
On 2020-11-17 3:06 p.m., Christian König wrote: Increase the ammount of system memory drivers can use to about 90% of the total available. Signed-off-by: Christian König --- drivers/gpu/drm/ttm/ttm_bo.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index a958135cb3fe..0a93df93dba4 100644 --- a/drivers/gpu/drm/ttm/ttm_bo.c +++ b/drivers/gpu/drm/ttm/ttm_bo.c @@ -1267,7 +1267,7 @@ static int ttm_bo_global_init(void) * the available system memory. */ num_pages = (u64)si.totalram * si.mem_unit; - num_pages = (num_pages * 50 / 100) >> PAGE_SHIFT; + num_pages = (num_pages * 90 / 100) >> PAGE_SHIFT; /* But for DMA32 we limit ourself to only use 2GiB maximum. */ num_dma32_pages = (u64)(si.totalram - si.totalhigh) * si.mem_unit; This should update the comment added in patch 1. -- 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
Re: [PATCH 08/10] drm/fb-helper: Restore damage area upon errors
On Tue, Nov 17, 2020 at 04:14:46PM +0100, Sebastian Reichel wrote:
> Hi,
>
> On Mon, Nov 16, 2020 at 09:52:16PM +0100, Daniel Vetter wrote:
> > On Mon, Nov 16, 2020 at 09:04:35PM +0100, Thomas Zimmermann wrote:
> > > If the damage handling fails, restore the damage area. The next invocation
> > > of the damage worker will then perform the update.
> > >
> > > Signed-off-by: Thomas Zimmermann
> > > ---
> > > drivers/gpu/drm/drm_fb_helper.c | 23 ---
> > > 1 file changed, 20 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_fb_helper.c
> > > b/drivers/gpu/drm/drm_fb_helper.c
> > > index 2e1a335bafd2..13b65dad2ca8 100644
> > > --- a/drivers/gpu/drm/drm_fb_helper.c
> > > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > > @@ -431,11 +431,28 @@ static void drm_fb_helper_damage_work(struct
> > > work_struct *work)
> > > if (helper->buffer) {
> > > ret = drm_fb_helper_damage_blit(helper, &clip_copy);
> > > if (ret)
> > > - return;
> > > + goto err;
> > > }
> > >
> > > - if (helper->fb->funcs->dirty)
> > > - helper->fb->funcs->dirty(helper->fb, NULL, 0, 0, &clip_copy, 1);
> > > + if (helper->fb->funcs->dirty) {
> > > + ret = helper->fb->funcs->dirty(helper->fb, NULL, 0, 0,
> > > &clip_copy, 1);
> > > + if (ret)
> > > + goto err;
> >
> > I think this is unexpected enough that we should put some drm error
> > printing here I think.
>
> Note, that the dirty framebuffer routines are used by the
> framebuffer console. Printing warnings means another line
> in the framebuffer console and thus another call to the
> dirty routines. Assuming the problem does not get solved
> magically the system will be busy printing warnings forever.
> I have been through that fun while working on the OMAP DSI
> command mode patches and I suggest to only do ratelimited
> logging in the code related to damage tracking.
Excellent point. Maybe _once is good enough even, perhaps with a dump of
the entire atomic state included for debugging (in case it's transient or
something like that). Past that there's nothing we can do anyway, and most
likely it's just hurting.
-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 v2 07/22] drm/msm: Do rpm get sooner in the submit path
On Thu, Nov 5, 2020 at 11:16 PM Viresh Kumar wrote:
>
> On 05-11-20, 11:24, Rob Clark wrote:
> > On Tue, Nov 3, 2020 at 7:04 PM Viresh Kumar wrote:
> > >
> > > On 03-11-20, 08:50, Rob Clark wrote:
> > > > sorry, it didn't apply cleanly (which I guess is due to some other
> > > > dependencies that need to be picked back to v5.4 product kernel), and
> > > > due to some other things I'm in middle of debugging I didn't have time
> > > > yet to switch to v5.10-rc or look at what else needs to
> > > > cherry-picked..
> > > >
> > > > If you could, pushing a branch with this patch somewhere would be a
> > > > bit easier to work with (ie. fetch && cherry-pick is easier to deal
> > > > with than picking things from list)
> > >
> > > It has been in linux-next for a few days. Here is the HEAD to pick
> > > from. There are few patches there since rc1.
> > >
> > > commit 203e29749cc0 ("opp: Allocate the OPP table outside of
> > > opp_table_lock")
> > >
> >
> > sorry for the delay, with that cherry-picked, I'm getting a whole lot of:
>
> Ahh, sorry about that and thanks for reporting it. Here is the fix:
>
> diff --git a/drivers/opp/of.c b/drivers/opp/of.c
> index c718092757d9..6b7f0066942d 100644
> --- a/drivers/opp/of.c
> +++ b/drivers/opp/of.c
> @@ -112,8 +112,6 @@ static struct opp_table *_find_table_of_opp_np(struct
> device_node *opp_np)
> struct opp_table *opp_table;
> struct device_node *opp_table_np;
>
> - lockdep_assert_held(&opp_table_lock);
> -
> opp_table_np = of_get_parent(opp_np);
> if (!opp_table_np)
> goto err;
> @@ -121,12 +119,15 @@ static struct opp_table *_find_table_of_opp_np(struct
> device_node *opp_np)
> /* It is safe to put the node now as all we need now is its address */
> of_node_put(opp_table_np);
>
> + mutex_lock(&opp_table_lock);
> list_for_each_entry(opp_table, &opp_tables, node) {
> if (opp_table_np == opp_table->np) {
> _get_opp_table_kref(opp_table);
> + mutex_unlock(&opp_table_lock);
> return opp_table;
> }
> }
> + mutex_unlock(&opp_table_lock);
>
> err:
> return ERR_PTR(-ENODEV);
>
With that on top of the previous patch,
[ 26.378245] ==
[ 26.384595] WARNING: possible circular locking dependency detected
[ 26.390947] 5.10.0-rc2+ #6 Not tainted
[ 26.394804] --
[ 26.401155] chrome/1886 is trying to acquire lock:
[ 26.406087] ffe5e264aa88 (opp_table_lock){+.+.}-{3:3}, at:
_find_opp_table+0x38/0x78
[ 26.414436]
[ 26.414436] but task is already holding lock:
[ 26.420423] ffb0283935b0
(reservation_ww_class_mutex){+.+.}-{3:3}, at:
submit_lock_objects+0x70/0x1ec
[ 26.430268]
[ 26.430268] which lock already depends on the new lock.
[ 26.430268]
[ 26.438661]
[ 26.438661] the existing dependency chain (in reverse order) is:
[ 26.446343]
[ 26.446343] -> #3 (reservation_ww_class_mutex){+.+.}-{3:3}:
[ 26.453603]lock_acquire+0x23c/0x30c
[ 26.457910]__mutex_lock_common+0xdc/0xbc4
[ 26.462743]ww_mutex_lock_interruptible+0x84/0xec
[ 26.468203]msm_gem_fault+0x30/0x138
[ 26.472507]__do_fault+0x44/0x184
[ 26.476541]handle_mm_fault+0x754/0xc50
[ 26.481117]do_page_fault+0x230/0x354
[ 26.485507]do_translation_fault+0x40/0x54
[ 26.490338]do_mem_abort+0x44/0xac
[ 26.494469]el0_sync_compat_handler+0x15c/0x190
[ 26.499756]el0_sync_compat+0x144/0x180
[ 26.504328]
[ 26.504328] -> #2 (&mm->mmap_lock){}-{3:3}:
[ 26.510511]lock_acquire+0x23c/0x30c
[ 26.514813]__might_fault+0x60/0x80
[ 26.519034]compat_filldir+0x118/0x4d0
[ 26.523519]dcache_readdir+0x74/0x1e0
[ 26.527907]iterate_dir+0xd4/0x198
[ 26.532037]__arm64_compat_sys_getdents+0x6c/0x168
[ 26.537583]el0_svc_common+0xa4/0x174
[ 26.541970]do_el0_svc_compat+0x20/0x30
[ 26.546543]el0_sync_compat_handler+0x124/0x190
[ 26.551828]el0_sync_compat+0x144/0x180
[ 26.556399]
[ 26.556399] -> #1 (&sb->s_type->i_mutex_key#2){}-{3:3}:
[ 26.563660]lock_acquire+0x23c/0x30c
[ 26.567963]down_write+0x80/0x1dc
[ 26.571997]simple_recursive_removal+0x48/0x238
[ 26.577288]debugfs_remove+0x5c/0x78
[ 26.581592]opp_debug_unregister+0x34/0x118
[ 26.586521]dev_pm_opp_put_opp_table+0xd0/0x14c
[ 26.591802]dev_pm_opp_put_clkname+0x40/0x54
[ 26.596820]msm_dsi_host_destroy+0xe0/0x108
[ 26.601748]dsi_destroy+0x40/0x58
[ 26.605789]dsi_bind+0x8c/0x16c
[ 26.609648]component_bind_all+0xf4/0x20c
[ 26.614399]msm_drm_init+0x180/0x588
[ 26.618696]msm_drm_bind+0x1c/0x24
[ 26.622822]try_to_bring
Re: [PATCH 3/3] drm/ttm: make up to 90% of system memory available
On Tue, Nov 17, 2020 at 03:06:15PM +0100, Christian König wrote: > Increase the ammount of system memory drivers can use to about 90% of > the total available. > > Signed-off-by: Christian König > --- > drivers/gpu/drm/ttm/ttm_bo.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c > index a958135cb3fe..0a93df93dba4 100644 > --- a/drivers/gpu/drm/ttm/ttm_bo.c > +++ b/drivers/gpu/drm/ttm/ttm_bo.c > @@ -1267,7 +1267,7 @@ static int ttm_bo_global_init(void) >* the available system memory. >*/ > num_pages = (u64)si.totalram * si.mem_unit; > - num_pages = (num_pages * 50 / 100) >> PAGE_SHIFT; > + num_pages = (num_pages * 90 / 100) >> PAGE_SHIFT; I don't think this is the design we want. As long as it was set at "half of system memory" it was clear that a) it's a hack b) precision didn't matter. But if you go to the limit and still want to keep the "we make sure there's no OOM", then precision starts to matter: - memory hotplug and hotunplug is a thing - userspace can mlock, and it's configureable - drivers can pin_user_pages for IO and random other stuff. Some of it is accounted as some subsystem specific mlock (like rdma does iirc), some is just yolo or short term enough (like) - none of what we do here takes into considerations any interactions with core mm tracking (like cgroups or numa or anything like that) If we want to drop the "half of system ram" limit (and yes that makes sense) I think the right design is: - we give up on the "no OOM" guarantee. - This means if you want real isolation of tasks, we need cgroups, and we need to integrate ttm cgroups with system memory cgroups somehow. Unlike randomly picked hardcoded limits this should work a lot more reliably and be a lot more useful in practical use in the field. - This also means that drivers start to fail in interesting ways. I think locking headaches are covered with all the lockdep annotations I've pushed, plus some of the things I still have in-flight (I have a might_alloc() annotations somewhere). That leaves validation of error paths for when allocations fail. Ime a very effective way we used in i915 is (ab)using EINTR restarting, which per drmIoctl uapi spec is requried. We could put a debug mode into ttm_tt which randomly fails with -EINTR to make sure it's all working correctly (plus anything else that allocates memory), and unlike real out-of-memory injection piglit and any other cts will complete without failure. Which gives us an excellent metric for "does it work". Actualy OOM, even injected one, tends to make stuff blow up in a way that's very hard to track and make sure you've got good coverage, since all your usual tests die pretty quickly. - ttm_tt needs to play fair with every other system memory user. We need to register a shrinker for each ttm_tt (so usually one per device I guess), which walks the lru (in shrink_count) and uses dma_resv_trylock for actual shrinking. We probably want to move it to SYSTEM first for that shrinker to pick up, so that there's some global fairness across all ttm_tt. - for GFP_DMA32 that means zone aware shrinkers. We've never used those, because thus far i915 didn't have any big need for low memory, so we haven't used this in practice. But it's supposed to be a thing. It's a bit more code than the oneliner above, but I also think it's a lot more solid. Plus it would resolve the last big issue where i915 gem is fairly fundamentally different compared to ttm. For that question I think once Maarten's locking rework for i915 has landed and all the other ttm rework from you and Dave is in, we've resolved them all. > /* But for DMA32 we limit ourself to only use 2GiB maximum. */ > num_dma32_pages = (u64)(si.totalram - si.totalhigh) * si.mem_unit; > -- > 2.25.1 > -- 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 03/42] drm/drm_dp_mst_topology: Remove set but never used variable 'len'
On Mon, Nov 16, 2020 at 05:40:33PM +, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> 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:3263:6: warning: variable ‘len’ set
> but not used [-Wunused-but-set-variable]
>
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Lee Jones
Going to apply this, but I noticed that the return value of the
build_query_stream_enc_status() is pointless. Can you pls follow up with
an additional patch to change that to void?
Thanks, Daniel
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index e875425336406..0401b2f475002 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -3260,7 +3260,7 @@ int drm_dp_send_query_stream_enc_status(struct
> drm_dp_mst_topology_mgr *mgr,
> {
> struct drm_dp_sideband_msg_tx *txmsg;
> u8 nonce[7];
> - int len, ret;
> + int ret;
>
> txmsg = kzalloc(sizeof(*txmsg), GFP_KERNEL);
> if (!txmsg)
> @@ -3281,7 +3281,7 @@ int drm_dp_send_query_stream_enc_status(struct
> drm_dp_mst_topology_mgr *mgr,
>*/
> txmsg->dst = mgr->mst_primary;
>
> - len = build_query_stream_enc_status(txmsg, port->vcpi.vcpi, nonce);
> + build_query_stream_enc_status(txmsg, port->vcpi.vcpi, nonce);
>
> drm_dp_queue_down_tx(mgr, txmsg);
>
> --
> 2.25.1
>
--
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 1/4] drm/ttm/drivers: remove unecessary ttm_module.h include
On Tue, Nov 17, 2020 at 05:33:35PM +0100, Christian König wrote: > ttm_module.h deals with internals of TTM and should never > be include outside of it. > > Signed-off-by: Christian König Maybe also move it to drivers/gpu/drm/ttm/ttm_internal.h. We're using the _interal.h suffix in a few other places for module internal functions already. Perhaps in a follow-up? Anyway this here is Acked-by: Daniel Vetter (I didn't bother compile testing it on everything, just to make that clear). -Daniel > --- > drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 - > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 1 - > drivers/gpu/drm/nouveau/nouveau_drv.h | 1 - > drivers/gpu/drm/qxl/qxl_drv.h | 1 - > drivers/gpu/drm/qxl/qxl_ttm.c | 1 - > drivers/gpu/drm/radeon/radeon.h | 1 - > drivers/gpu/drm/radeon/radeon_ttm.c | 1 - > drivers/gpu/drm/ttm/ttm_agp_backend.c | 1 - > drivers/gpu/drm/ttm/ttm_bo_vm.c | 1 - > drivers/gpu/drm/ttm/ttm_range_manager.c | 1 - > drivers/gpu/drm/vmwgfx/ttm_object.c | 1 - > drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 1 - > drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 1 - > drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 1 - > drivers/gpu/drm/vmwgfx/vmwgfx_thp.c | 1 - > include/drm/ttm/ttm_bo_driver.h | 1 - > 16 files changed, 16 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h > b/drivers/gpu/drm/amd/amdgpu/amdgpu.h > index 183b09d71b64..6e042b4ed13d 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h > @@ -55,7 +55,6 @@ > #include > #include > #include > -#include > #include > > #include > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c > index c438d290a6db..967859c6be3c 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c > @@ -46,7 +46,6 @@ > #include > #include > #include > -#include > > #include > #include > diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h > b/drivers/gpu/drm/nouveau/nouveau_drv.h > index 8e90b3e47bbe..700fa0979d14 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_drv.h > +++ b/drivers/gpu/drm/nouveau/nouveau_drv.h > @@ -54,7 +54,6 @@ > #include > #include > #include > -#include > > #include > > diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h > index 8bd0f916dfbc..83b54f0dad61 100644 > --- a/drivers/gpu/drm/qxl/qxl_drv.h > +++ b/drivers/gpu/drm/qxl/qxl_drv.h > @@ -46,7 +46,6 @@ > #include > #include > #include > -#include > #include > > #include "qxl_dev.h" > diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c > index 128c38c8a837..0cc661df2258 100644 > --- a/drivers/gpu/drm/qxl/qxl_ttm.c > +++ b/drivers/gpu/drm/qxl/qxl_ttm.c > @@ -31,7 +31,6 @@ > #include > #include > #include > -#include > #include > > #include "qxl_drv.h" > diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h > index 28cb8ced91b9..428c561a4e2c 100644 > --- a/drivers/gpu/drm/radeon/radeon.h > +++ b/drivers/gpu/drm/radeon/radeon.h > @@ -75,7 +75,6 @@ > #include > #include > #include > -#include > #include > > #include > diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c > b/drivers/gpu/drm/radeon/radeon_ttm.c > index 0ca381b95d3d..2259d3811a45 100644 > --- a/drivers/gpu/drm/radeon/radeon_ttm.c > +++ b/drivers/gpu/drm/radeon/radeon_ttm.c > @@ -46,7 +46,6 @@ > #include > #include > #include > -#include > #include > > #include "radeon_reg.h" > diff --git a/drivers/gpu/drm/ttm/ttm_agp_backend.c > b/drivers/gpu/drm/ttm/ttm_agp_backend.c > index 03c86628e4ac..8f9fa4188897 100644 > --- a/drivers/gpu/drm/ttm/ttm_agp_backend.c > +++ b/drivers/gpu/drm/ttm/ttm_agp_backend.c > @@ -32,7 +32,6 @@ > > #define pr_fmt(fmt) "[TTM] " fmt > > -#include > #include > #include > #include > diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c > index 2944fa0af493..144a4940b6b6 100644 > --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c > +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c > @@ -31,7 +31,6 @@ > > #define pr_fmt(fmt) "[TTM] " fmt > > -#include > #include > #include > #include > diff --git a/drivers/gpu/drm/ttm/ttm_range_manager.c > b/drivers/gpu/drm/ttm/ttm_range_manager.c > index ea77919569a2..4c0c756c9124 100644 > --- a/drivers/gpu/drm/ttm/ttm_range_manager.c > +++ b/drivers/gpu/drm/ttm/ttm_range_manager.c > @@ -29,7 +29,6 @@ > * Authors: Thomas Hellstrom > */ > > -#include > #include > #include > #include > diff --git a/drivers/gpu/drm/vmwgfx/ttm_object.c > b/drivers/gpu/drm/vmwgfx/ttm_object.c > index 16077785ad47..0fe869d0fad1 100644 > --- a/drivers/gpu/drm/vmwgfx/ttm_object.c > +++ b/drivers/gpu/drm/vmwgfx/ttm_object.c > @@ -59,7 +59,6 @@ > > #define pr_fmt(fmt) "[TTM] " fmt > > -#include > #includ
[PATCH v1 5/6] dt-bindings: vendor-prefixes: Add ys vendor prefix
Add prefix for Shenzhen Yashi Changhua Intelligent Technology Co., Ltd. Signed-off-by: Guido Günther --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index e40ee369f808..d0f3abf2f12c 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -1220,6 +1220,8 @@ patternProperties: description: Shenzhen Yangliming Electronic Technology Co., Ltd. "^yna,.*": description: YSH & ATIL + "^ys,.*": +description: Shenzhen Yashi Changhua Intelligent Technology Co., Ltd. "^yones-toptech,.*": description: Yones Toptech Co., Ltd. "^ysoft,.*": -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 0/6] drm/panel: mantix and st7703 fixes and additions
This adds new panel type to the mantix driver as found on the Librem 5 and fixes a glitch in the init sequence (affecting both panels). The fix is at the start of the series to make backporting simpler. It also adds a patch to make st7703 use dev_err_probe(). Guido Günther (6): drm/panel: st7703: Use dev_err_probe drm/panel: mantix: Tweak init sequence drm/panel: mantix: Allow to specify default mode for different panels drm/panel: mantix: Support panel from Shenzhen Yashi Changhua Intelligent Technology Co dt-bindings: vendor-prefixes: Add ys vendor prefix dt-binding: display: mantix: Add compatible for panel from YS .../display/panel/mantix,mlaf057we51-x.yaml | 1 + .../devicetree/bindings/vendor-prefixes.yaml | 2 + .../gpu/drm/panel/panel-mantix-mlaf057we51.c | 39 +++ drivers/gpu/drm/panel/panel-sitronix-st7703.c | 24 4 files changed, 43 insertions(+), 23 deletions(-) -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 1/6] drm/panel: st7703: Use dev_err_probe
Less code and easier probe deferral debugging.
Signed-off-by: Guido Günther
---
drivers/gpu/drm/panel/panel-sitronix-st7703.c | 24 +++
1 file changed, 8 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
index b30510b1696a..a2c303e5732c 100644
--- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
+++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
@@ -530,10 +530,8 @@ static int st7703_probe(struct mipi_dsi_device *dsi)
return -ENOMEM;
ctx->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
- if (IS_ERR(ctx->reset_gpio)) {
- dev_err(dev, "cannot get reset gpio\n");
- return PTR_ERR(ctx->reset_gpio);
- }
+ if (IS_ERR(ctx->reset_gpio))
+ return dev_err_probe(dev, PTR_ERR(ctx->reset_gpio), "Failed to
get reset gpio\n");
mipi_dsi_set_drvdata(dsi, ctx);
@@ -545,19 +543,13 @@ static int st7703_probe(struct mipi_dsi_device *dsi)
dsi->lanes = ctx->desc->lanes;
ctx->vcc = devm_regulator_get(dev, "vcc");
- if (IS_ERR(ctx->vcc)) {
- ret = PTR_ERR(ctx->vcc);
- if (ret != -EPROBE_DEFER)
- dev_err(dev, "Failed to request vcc regulator: %d\n",
ret);
- return ret;
- }
+ if (IS_ERR(ctx->vcc))
+ return dev_err_probe(dev, PTR_ERR(ctx->vcc), "Failed to request
vcc regulator\n");
+
ctx->iovcc = devm_regulator_get(dev, "iovcc");
- if (IS_ERR(ctx->iovcc)) {
- ret = PTR_ERR(ctx->iovcc);
- if (ret != -EPROBE_DEFER)
- dev_err(dev, "Failed to request iovcc regulator: %d\n",
ret);
- return ret;
- }
+ if (IS_ERR(ctx->iovcc))
+ return dev_err_probe(dev, PTR_ERR(ctx->iovcc),
+"Failed to request iovcc regulator\n");
drm_panel_init(&ctx->panel, dev, &st7703_drm_funcs,
DRM_MODE_CONNECTOR_DSI);
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 3/6] drm/panel: mantix: Allow to specify default mode for different panels
This can be used to use different modes for differnt panels via OF
device match.
Signed-off-by: Guido Günther
---
.../gpu/drm/panel/panel-mantix-mlaf057we51.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
index 624d17b96a69..b057857165b0 100644
--- a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
+++ b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
@@ -34,6 +35,8 @@ struct mantix {
struct regulator *avdd;
struct regulator *avee;
struct regulator *vddi;
+
+ const struct drm_display_mode *default_mode;
};
static inline struct mantix *panel_to_mantix(struct drm_panel *panel)
@@ -187,7 +190,7 @@ static int mantix_prepare(struct drm_panel *panel)
return 0;
}
-static const struct drm_display_mode default_mode = {
+static const struct drm_display_mode default_mode_mantix = {
.hdisplay= 720,
.hsync_start = 720 + 45,
.hsync_end = 720 + 45 + 14,
@@ -208,11 +211,11 @@ static int mantix_get_modes(struct drm_panel *panel,
struct mantix *ctx = panel_to_mantix(panel);
struct drm_display_mode *mode;
- mode = drm_mode_duplicate(connector->dev, &default_mode);
+ mode = drm_mode_duplicate(connector->dev, ctx->default_mode);
if (!mode) {
dev_err(ctx->dev, "Failed to add mode %ux%u@%u\n",
- default_mode.hdisplay, default_mode.vdisplay,
- drm_mode_vrefresh(&default_mode));
+ ctx->default_mode->hdisplay,
ctx->default_mode->vdisplay,
+ drm_mode_vrefresh(ctx->default_mode));
return -ENOMEM;
}
@@ -243,6 +246,7 @@ static int mantix_probe(struct mipi_dsi_device *dsi)
ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
if (!ctx)
return -ENOMEM;
+ ctx->default_mode = of_device_get_match_data(dev);
ctx->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
if (IS_ERR(ctx->reset_gpio)) {
@@ -293,8 +297,8 @@ static int mantix_probe(struct mipi_dsi_device *dsi)
}
dev_info(dev, "%ux%u@%u %ubpp dsi %udl - ready\n",
-default_mode.hdisplay, default_mode.vdisplay,
-drm_mode_vrefresh(&default_mode),
+ctx->default_mode->hdisplay, ctx->default_mode->vdisplay,
+drm_mode_vrefresh(ctx->default_mode),
mipi_dsi_pixel_format_to_bpp(dsi->format), dsi->lanes);
return 0;
@@ -321,7 +325,7 @@ static int mantix_remove(struct mipi_dsi_device *dsi)
}
static const struct of_device_id mantix_of_match[] = {
- { .compatible = "mantix,mlaf057we51-x" },
+ { .compatible = "mantix,mlaf057we51-x", .data = &default_mode_mantix },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, mantix_of_match);
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 6/6] dt-binding: display: mantix: Add compatible for panel from YS
This panel from Shenzhen Yashi Changhua Intelligent Technology Co uses the same driver IC but a different LCD. Signed-off-by: Guido Günther --- .../devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml b/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml index 51f423297ec8..9e78f2e60f99 100644 --- a/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml +++ b/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml @@ -20,6 +20,7 @@ properties: compatible: enum: - mantix,mlaf057we51-x + - ys,ys57pss36bh5gq port: true reg: -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 2/6] drm/panel: mantix: Tweak init sequence
We've seen some (non permanent) burn in and bad white balance
on some of the panels. Adding this bit from a vendor supplied
sequence fixes it.
Fixes: 72967d5616d3 ("drm/panel: Add panel driver for the Mantix MLAF057WE51-X
DSI panel")
Signed-off-by: Guido Günther
---
drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
index 0c5f22e95c2d..624d17b96a69 100644
--- a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
+++ b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
@@ -22,6 +22,7 @@
/* Manufacturer specific Commands send via DSI */
#define MANTIX_CMD_OTP_STOP_RELOAD_MIPI 0x41
#define MANTIX_CMD_INT_CANCEL 0x4C
+#define MANTIX_CMD_SPI_FINISH 0x90
struct mantix {
struct device *dev;
@@ -66,6 +67,10 @@ static int mantix_init_sequence(struct mantix *ctx)
dsi_generic_write_seq(dsi, 0x80, 0x64, 0x00, 0x64, 0x00, 0x00);
msleep(20);
+ dsi_generic_write_seq(dsi, MANTIX_CMD_SPI_FINISH, 0xA5);
+ dsi_generic_write_seq(dsi, MANTIX_CMD_OTP_STOP_RELOAD_MIPI, 0x00, 0x2F);
+ msleep(20);
+
dev_dbg(dev, "Panel init sequence done\n");
return 0;
}
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 4/6] drm/panel: mantix: Support panel from Shenzhen Yashi Changhua Intelligent Technology Co
The panel uses the same driver IC and has the same resolution but a
slightly different default mode. It seems it can work with the same
init sequence.
Signed-off-by: Guido Günther
---
drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
index b057857165b0..30f28ad4df6b 100644
--- a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
+++ b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
@@ -205,6 +205,21 @@ static const struct drm_display_mode default_mode_mantix =
{
.height_mm = 130,
};
+static const struct drm_display_mode default_mode_ys = {
+ .hdisplay= 720,
+ .hsync_start = 720 + 45,
+ .hsync_end = 720 + 45 + 14,
+ .htotal = 720 + 45 + 14 + 25,
+ .vdisplay= 1440,
+ .vsync_start = 1440 + 175,
+ .vsync_end = 1440 + 175 + 8,
+ .vtotal = 1440 + 175 + 8 + 50,
+ .clock = 85298,
+ .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+ .width_mm= 65,
+ .height_mm = 130,
+};
+
static int mantix_get_modes(struct drm_panel *panel,
struct drm_connector *connector)
{
@@ -326,6 +341,7 @@ static int mantix_remove(struct mipi_dsi_device *dsi)
static const struct of_device_id mantix_of_match[] = {
{ .compatible = "mantix,mlaf057we51-x", .data = &default_mode_mantix },
+ { .compatible = "ys,ys57pss36bh5gq", .data = &default_mode_ys },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, mantix_of_match);
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/mcde: Fix RGB/BGR bug
I was confused when the graphics came out with blue
penguins on the DPI panel.
It turns out that the so-called "packed RGB666" mode
on the DSI formatter is incorrect: this mode is the
actual RGB888 mode, and the mode called RGB888 is
BGR888.
The claims that the MCDE had inverse RGB/BGR buffer
formats was wrong, so correct this and the buggy
register and everything is much more consistent, and
graphics look good on all targets, both DPI and
DSI.
Cc: phone-de...@vger.kernel.org
Cc: Stephan Gerhold
Signed-off-by: Linus Walleij
---
drivers/gpu/drm/mcde/mcde_display.c | 23 +++
drivers/gpu/drm/mcde/mcde_display_regs.h | 4 ++--
2 files changed, 13 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/mcde/mcde_display.c
b/drivers/gpu/drm/mcde/mcde_display.c
index 14c76d3a8e5a..192e11c88d72 100644
--- a/drivers/gpu/drm/mcde/mcde_display.c
+++ b/drivers/gpu/drm/mcde/mcde_display.c
@@ -250,73 +250,70 @@ static int mcde_configure_extsrc(struct mcde *mcde, enum
mcde_extsrc src,
val = 0 << MCDE_EXTSRCXCONF_BUF_ID_SHIFT;
val |= 1 << MCDE_EXTSRCXCONF_BUF_NB_SHIFT;
val |= 0 << MCDE_EXTSRCXCONF_PRI_OVLID_SHIFT;
- /*
-* MCDE has inverse semantics from DRM on RBG/BGR which is why
-* all the modes are inversed here.
-*/
+
switch (format) {
case DRM_FORMAT_ARGB:
val |= MCDE_EXTSRCXCONF_BPP_ARGB <<
MCDE_EXTSRCXCONF_BPP_SHIFT;
- val |= MCDE_EXTSRCXCONF_BGR;
break;
case DRM_FORMAT_ABGR:
val |= MCDE_EXTSRCXCONF_BPP_ARGB <<
MCDE_EXTSRCXCONF_BPP_SHIFT;
+ val |= MCDE_EXTSRCXCONF_BGR;
break;
case DRM_FORMAT_XRGB:
val |= MCDE_EXTSRCXCONF_BPP_XRGB <<
MCDE_EXTSRCXCONF_BPP_SHIFT;
- val |= MCDE_EXTSRCXCONF_BGR;
break;
case DRM_FORMAT_XBGR:
val |= MCDE_EXTSRCXCONF_BPP_XRGB <<
MCDE_EXTSRCXCONF_BPP_SHIFT;
+ val |= MCDE_EXTSRCXCONF_BGR;
break;
case DRM_FORMAT_RGB888:
val |= MCDE_EXTSRCXCONF_BPP_RGB888 <<
MCDE_EXTSRCXCONF_BPP_SHIFT;
- val |= MCDE_EXTSRCXCONF_BGR;
break;
case DRM_FORMAT_BGR888:
val |= MCDE_EXTSRCXCONF_BPP_RGB888 <<
MCDE_EXTSRCXCONF_BPP_SHIFT;
+ val |= MCDE_EXTSRCXCONF_BGR;
break;
case DRM_FORMAT_ARGB:
val |= MCDE_EXTSRCXCONF_BPP_ARGB <<
MCDE_EXTSRCXCONF_BPP_SHIFT;
- val |= MCDE_EXTSRCXCONF_BGR;
break;
case DRM_FORMAT_ABGR:
val |= MCDE_EXTSRCXCONF_BPP_ARGB <<
MCDE_EXTSRCXCONF_BPP_SHIFT;
+ val |= MCDE_EXTSRCXCONF_BGR;
break;
case DRM_FORMAT_XRGB:
val |= MCDE_EXTSRCXCONF_BPP_RGB444 <<
MCDE_EXTSRCXCONF_BPP_SHIFT;
- val |= MCDE_EXTSRCXCONF_BGR;
break;
case DRM_FORMAT_XBGR:
val |= MCDE_EXTSRCXCONF_BPP_RGB444 <<
MCDE_EXTSRCXCONF_BPP_SHIFT;
+ val |= MCDE_EXTSRCXCONF_BGR;
break;
case DRM_FORMAT_XRGB1555:
val |= MCDE_EXTSRCXCONF_BPP_IRGB1555 <<
MCDE_EXTSRCXCONF_BPP_SHIFT;
- val |= MCDE_EXTSRCXCONF_BGR;
break;
case DRM_FORMAT_XBGR1555:
val |= MCDE_EXTSRCXCONF_BPP_IRGB1555 <<
MCDE_EXTSRCXCONF_BPP_SHIFT;
+ val |= MCDE_EXTSRCXCONF_BGR;
break;
case DRM_FORMAT_RGB565:
val |= MCDE_EXTSRCXCONF_BPP_RGB565 <<
MCDE_EXTSRCXCONF_BPP_SHIFT;
- val |= MCDE_EXTSRCXCONF_BGR;
break;
case DRM_FORMAT_BGR565:
val |= MCDE_EXTSRCXCONF_BPP_RGB565 <<
MCDE_EXTSRCXCONF_BPP_SHIFT;
+ val |= MCDE_EXTSRCXCONF_BGR;
break;
case DRM_FORMAT_YUV422:
val |= MCDE_EXTSRCXCONF_BPP_YCBCR422 <<
@@ -810,7 +807,9 @@ static void mcde_configure_dsi_formatter(struct mcde *mcde,
MCDE_DSICONF0_PACKING_SHIFT;
break;
case MIPI_DSI_FMT_RGB666_PACKED:
- val |= MCDE_DSICONF0_PACKING_RGB666_PACKED <<
+ dev_err(mcde->dev,
+ "we cannot handle the packed RGB666 format\n");
+ val |= MCDE_DSICONF0_PACKING_RGB666 <<
MCDE_DSICONF0_PACKING_SHIFT;
break;
case MIPI_DSI_FMT_RGB565:
diff --git a/drivers/gpu/drm/mcde/mcde_display_regs.h
b/drivers/gpu/drm/mcde/mcde_display_regs.h
index ae76da8a213
[PATCH 1/3] drm/panel: s6e63m0: Fix and extend MCS table
Fix up the format of the manufacturer command set table to be TAB-indented and lowercase. Add the MCS_TEMP_SWIRE command that we will make use of. Cc: Stephan Gerhold Cc: Paweł Chmiel Signed-off-by: Linus Walleij --- drivers/gpu/drm/panel/panel-samsung-s6e63m0.c | 17 + 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e63m0.c b/drivers/gpu/drm/panel/panel-samsung-s6e63m0.c index 210e70da3a15..8fce399fb97d 100644 --- a/drivers/gpu/drm/panel/panel-samsung-s6e63m0.c +++ b/drivers/gpu/drm/panel/panel-samsung-s6e63m0.c @@ -23,20 +23,21 @@ #include "panel-samsung-s6e63m0.h" /* Manufacturer Command Set */ -#define MCS_ELVSS_ON0xb1 -#define MCS_MIECTL10xc0 -#define MCS_BCMODE 0xc1 +#define MCS_ELVSS_ON 0xb1 +#define MCS_TEMP_SWIRE 0xb2 +#define MCS_MIECTL10xc0 +#define MCS_BCMODE 0xc1 #define MCS_ERROR_CHECK0xd5 #define MCS_READ_ID1 0xda #define MCS_READ_ID2 0xdb #define MCS_READ_ID3 0xdc #define MCS_LEVEL_2_KEY0xf0 #define MCS_MTP_KEY0xf1 -#define MCS_DISCTL 0xf2 -#define MCS_SRCCTL 0xf6 -#define MCS_IFCTL 0xf7 -#define MCS_PANELCTL 0xF8 -#define MCS_PGAMMACTL 0xfa +#define MCS_DISCTL 0xf2 +#define MCS_SRCCTL 0xf6 +#define MCS_IFCTL 0xf7 +#define MCS_PANELCTL 0xf8 +#define MCS_PGAMMACTL 0xfa #define S6E63M0_LCD_ID_VALUE_M20xA4 #define S6E63M0_LCD_ID_VALUE_SM2 0xB4 -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/panel: s6e63m0: Implement 28 backlight levels
A later version of the s6e63m0 driver in the Samsung
GT-I9070 vendor tree provides 28 different backlight
levels making use of elaborate control of the ACL
and ELVSS regulator. Implement this more fine-grained
backlight control.
Cc: Stephan Gerhold
Cc: Paweł Chmiel
Signed-off-by: Linus Walleij
---
drivers/gpu/drm/panel/panel-samsung-s6e63m0.c | 310 +++---
1 file changed, 257 insertions(+), 53 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e63m0.c
b/drivers/gpu/drm/panel/panel-samsung-s6e63m0.c
index 8fce399fb97d..0418d6f1530b 100644
--- a/drivers/gpu/drm/panel/panel-samsung-s6e63m0.c
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e63m0.c
@@ -43,57 +43,234 @@
#define S6E63M0_LCD_ID_VALUE_SM2 0xB4
#define S6E63M0_LCD_ID_VALUE_SM2_1 0xB6
-#define NUM_GAMMA_LEVELS 11
-#define GAMMA_TABLE_COUNT 23
+#define NUM_GAMMA_LEVELS 28
+#define GAMMA_TABLE_COUNT 23
-#define MAX_BRIGHTNESS (NUM_GAMMA_LEVELS - 1)
+#define MAX_BRIGHTNESS (NUM_GAMMA_LEVELS - 1)
/* array of gamma tables for gamma value 2.2 */
static u8 const s6e63m0_gamma_22[NUM_GAMMA_LEVELS][GAMMA_TABLE_COUNT] = {
- { MCS_PGAMMACTL, 0x00,
- 0x18, 0x08, 0x24, 0x78, 0xEC, 0x3D, 0xC8,
- 0xC2, 0xB6, 0xC4, 0xC7, 0xB6, 0xD5, 0xD7,
- 0xCC, 0x00, 0x39, 0x00, 0x36, 0x00, 0x51 },
- { MCS_PGAMMACTL, 0x00,
- 0x18, 0x08, 0x24, 0x73, 0x4A, 0x3D, 0xC0,
- 0xC2, 0xB1, 0xBB, 0xBE, 0xAC, 0xCE, 0xCF,
- 0xC5, 0x00, 0x5D, 0x00, 0x5E, 0x00, 0x82 },
- { MCS_PGAMMACTL, 0x00,
- 0x18, 0x08, 0x24, 0x70, 0x51, 0x3E, 0xBF,
- 0xC1, 0xAF, 0xB9, 0xBC, 0xAB, 0xCC, 0xCC,
- 0xC2, 0x00, 0x65, 0x00, 0x67, 0x00, 0x8D },
- { MCS_PGAMMACTL, 0x00,
- 0x18, 0x08, 0x24, 0x6C, 0x54, 0x3A, 0xBC,
- 0xBF, 0xAC, 0xB7, 0xBB, 0xA9, 0xC9, 0xC9,
- 0xBE, 0x00, 0x71, 0x00, 0x73, 0x00, 0x9E },
- { MCS_PGAMMACTL, 0x00,
- 0x18, 0x08, 0x24, 0x69, 0x54, 0x37, 0xBB,
- 0xBE, 0xAC, 0xB4, 0xB7, 0xA6, 0xC7, 0xC8,
- 0xBC, 0x00, 0x7B, 0x00, 0x7E, 0x00, 0xAB },
- { MCS_PGAMMACTL, 0x00,
- 0x18, 0x08, 0x24, 0x66, 0x55, 0x34, 0xBA,
- 0xBD, 0xAB, 0xB1, 0xB5, 0xA3, 0xC5, 0xC6,
- 0xB9, 0x00, 0x85, 0x00, 0x88, 0x00, 0xBA },
- { MCS_PGAMMACTL, 0x00,
- 0x18, 0x08, 0x24, 0x63, 0x53, 0x31, 0xB8,
- 0xBC, 0xA9, 0xB0, 0xB5, 0xA2, 0xC4, 0xC4,
- 0xB8, 0x00, 0x8B, 0x00, 0x8E, 0x00, 0xC2 },
- { MCS_PGAMMACTL, 0x00,
- 0x18, 0x08, 0x24, 0x62, 0x54, 0x30, 0xB9,
- 0xBB, 0xA9, 0xB0, 0xB3, 0xA1, 0xC1, 0xC3,
- 0xB7, 0x00, 0x91, 0x00, 0x95, 0x00, 0xDA },
- { MCS_PGAMMACTL, 0x00,
- 0x18, 0x08, 0x24, 0x66, 0x58, 0x34, 0xB6,
- 0xBA, 0xA7, 0xAF, 0xB3, 0xA0, 0xC1, 0xC2,
- 0xB7, 0x00, 0x97, 0x00, 0x9A, 0x00, 0xD1 },
- { MCS_PGAMMACTL, 0x00,
- 0x18, 0x08, 0x24, 0x64, 0x56, 0x33, 0xB6,
- 0xBA, 0xA8, 0xAC, 0xB1, 0x9D, 0xC1, 0xC1,
- 0xB7, 0x00, 0x9C, 0x00, 0x9F, 0x00, 0xD6 },
- { MCS_PGAMMACTL, 0x00,
- 0x18, 0x08, 0x24, 0x5f, 0x50, 0x2d, 0xB6,
- 0xB9, 0xA7, 0xAd, 0xB1, 0x9f, 0xbe, 0xC0,
- 0xB5, 0x00, 0xa0, 0x00, 0xa4, 0x00, 0xdb },
+ /* 30 cd */
+ { MCS_PGAMMACTL, 0x02,
+ 0x18, 0x08, 0x24, 0xA1, 0x51, 0x7B, 0xCE,
+ 0xCB, 0xC2, 0xC7, 0xCB, 0xBC, 0xDA, 0xDD,
+ 0xD3, 0x00, 0x53, 0x00, 0x52, 0x00, 0x6F, },
+ /* 40 cd */
+ { MCS_PGAMMACTL, 0x02,
+ 0x18, 0x08, 0x24, 0x97, 0x58, 0x71, 0xCC,
+ 0xCB, 0xC0, 0xC5, 0xC9, 0xBA, 0xD9, 0xDC,
+ 0xD1, 0x00, 0x5B, 0x00, 0x5A, 0x00, 0x7A, },
+ /* 50 cd */
+ { MCS_PGAMMACTL, 0x02,
+ 0x18, 0x08, 0x24, 0x96, 0x58, 0x72, 0xCB,
+ 0xCA, 0xBF, 0xC6, 0xC9, 0xBA, 0xD6, 0xD9,
+ 0xCD, 0x00, 0x61, 0x00, 0x61, 0x00, 0x83, },
+ /* 60 cd */
+ { MCS_PGAMMACTL, 0x02,
+ 0x18, 0x08, 0x24, 0x91, 0x5E, 0x6E, 0xC9,
+ 0xC9, 0xBD, 0xC4, 0xC9, 0xB8, 0xD3, 0xD7,
+ 0xCA, 0x00, 0x69, 0x00, 0x67, 0x00, 0x8D, },
+ /* 70 cd */
+ { MCS_PGAMMACTL, 0x02,
+ 0x18, 0x08, 0x24, 0x8E, 0x62, 0x6B, 0xC7,
+ 0xC9, 0xBB, 0xC3, 0xC7, 0xB7, 0xD3, 0xD7,
+ 0xCA, 0x00, 0x6E, 0x00, 0x6C, 0x00, 0x94, },
+ /* 80 cd */
+ { MCS_PGAMMACTL, 0x02,
+ 0x18, 0x08, 0x24, 0x89, 0x68, 0x65, 0xC9,
+ 0xC9, 0xBC, 0xC1, 0xC5, 0xB6, 0xD2, 0xD5,
+ 0xC9, 0x00, 0x73, 0x00, 0x72, 0x00, 0x9A, },
+ /* 90 cd */
+ { MCS_PGAMMACTL, 0x02,
+ 0x18, 0x08, 0x24, 0x89, 0x69, 0x64, 0xC7,
+ 0xC8, 0xBB, 0xC0, 0xC5, 0xB4, 0xD2, 0xD5,
+ 0xC9, 0x00, 0x77, 0x00, 0x76, 0x00, 0xA0, },
+ /* 100 cd */
+ { MCS_PGAMMACTL, 0x02,
+ 0x18, 0x08, 0x24, 0x86, 0x69, 0x60, 0xC6,
+ 0xC8, 0xBA, 0xBF, 0xC4, 0xB4, 0xD0, 0xD4,
+ 0xC6, 0x00, 0x7C, 0x00, 0x7A, 0x00, 0xA7, },
+ /* 110 cd */
+ { MCS_PGAMMACTL, 0x02,
[PATCH 3/3] drm/panel: s6e63m0: Fix init sequence
The init sequence consist of a number of unknown settings
for the display controller. This patch achieves two things:
- Fix an error that must have happened when the driver was
converted from the backlight subsystem: the 0xb8
configuration command was lost and added as a tail to
the previous command.
- Update some minor settings in some bytes here and there
according to changes in the Samsung GT-I9070 and
Samsung GT-S7710 code dumps. Since two other devices use
these settings they probably reflect trimmings later
found to be better for the display rather than
customizations for these devices.
Cc: Stephan Gerhold
Cc: Paweł Chmiel
Signed-off-by: Linus Walleij
---
drivers/gpu/drm/panel/panel-samsung-s6e63m0.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e63m0.c
b/drivers/gpu/drm/panel/panel-samsung-s6e63m0.c
index 0418d6f1530b..6b4e97bfd46e 100644
--- a/drivers/gpu/drm/panel/panel-samsung-s6e63m0.c
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e63m0.c
@@ -397,7 +397,7 @@ static void s6e63m0_init(struct s6e63m0 *ctx)
{
s6e63m0_dcs_write_seq_static(ctx, MCS_PANELCTL,
0x01, 0x27, 0x27, 0x07, 0x07, 0x54, 0x9f,
-0x63, 0x86, 0x1a, 0x33, 0x0d, 0x00, 0x00);
+0x63, 0x8f, 0x1a, 0x33, 0x0d, 0x00, 0x00);
s6e63m0_dcs_write_seq_static(ctx, MCS_DISCTL,
0x02, 0x03, 0x1c, 0x10, 0x10);
@@ -413,9 +413,8 @@ static void s6e63m0_init(struct s6e63m0 *ctx)
0x01);
s6e63m0_dcs_write_seq_static(ctx, MCS_SRCCTL,
-0x00, 0x8c, 0x07);
- s6e63m0_dcs_write_seq_static(ctx, 0xb3,
-0xc);
+0x00, 0x8e, 0x07);
+ s6e63m0_dcs_write_seq_static(ctx, 0xb3, 0x6c);
s6e63m0_dcs_write_seq_static(ctx, 0xb5,
0x2c, 0x12, 0x0c, 0x0a, 0x10, 0x0e, 0x17,
@@ -434,9 +433,12 @@ static void s6e63m0_init(struct s6e63m0 *ctx)
0x13, 0x1f, 0x1a, 0x2a, 0x24, 0x1f, 0x1b,
0x1a, 0x17, 0x2b, 0x26, 0x22, 0x20, 0x3a,
0x34, 0x30, 0x2c, 0x29, 0x26, 0x25, 0x23,
-0x21, 0x20, 0x1e, 0x1e, 0x00, 0x00, 0x11,
-0x22, 0x33, 0x44, 0x44, 0x44, 0x55, 0x55,
-0x66, 0x66, 0x66, 0x66, 0x66, 0x66);
+0x21, 0x20, 0x1e, 0x1e);
+
+ s6e63m0_dcs_write_seq_static(ctx, 0xb8,
+0x00, 0x00, 0x11, 0x22, 0x33, 0x44, 0x44,
+0x44, 0x55, 0x55, 0x66, 0x66, 0x66, 0x66,
+0x66, 0x66);
s6e63m0_dcs_write_seq_static(ctx, 0xb9,
0x2c, 0x12, 0x0c, 0x0a, 0x10, 0x0e, 0x17,
@@ -456,7 +458,7 @@ static void s6e63m0_init(struct s6e63m0 *ctx)
0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x06,
0x09, 0x0d, 0x0f, 0x12, 0x15, 0x18);
- s6e63m0_dcs_write_seq_static(ctx, 0xb2,
+ s6e63m0_dcs_write_seq_static(ctx, MCS_TEMP_SWIRE,
0x10, 0x10, 0x0b, 0x05);
s6e63m0_dcs_write_seq_static(ctx, MCS_MIECTL1,
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4] Add power/gpu_frequency tracepoint.
On 11/16/2020 10:05 PM, Steven Rostedt wrote: On Mon, 16 Nov 2020 12:55:29 -0800 Peiyong Lin wrote: Hi there, May I ask whether the merge window has passed? If so is it possible to ask for a review? This is up to the maintainers of power management to accept this. Rafael? I'd say up to the GPU people rather (dri-devel CCed) since that's where it is going to be used. Also it would be good to see at least one in-the-tree user of this (or a usage example at least). Cheers! ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4] Add power/gpu_frequency tracepoint.
On Tue, Nov 17, 2020 at 1:00 PM Rafael J. Wysocki wrote: > > On 11/16/2020 10:05 PM, Steven Rostedt wrote: > > On Mon, 16 Nov 2020 12:55:29 -0800 > > Peiyong Lin wrote: > > > >> Hi there, > >> > >> May I ask whether the merge window has passed? If so is it possible to > >> ask for a review? > > This is up to the maintainers of power management to accept this. > > > > Rafael? > > I'd say up to the GPU people rather (dri-devel CCed) since that's where > it is going to be used. > > Also it would be good to see at least one in-the-tree user of this (or a > usage example at least). Can you resend the patches and cc dri-devel or point out the previous patch discussion? Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 03/42] drm/drm_dp_mst_topology: Remove set but never used variable 'len'
On Tue, 17 Nov 2020, Daniel Vetter wrote: > On Mon, Nov 16, 2020 at 05:40:33PM +, Lee Jones wrote: > > Fixes the following W=1 kernel build warning(s): > > > > 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:3263:6: warning: variable ‘len’ set > > but not used [-Wunused-but-set-variable] > > > > Cc: Maarten Lankhorst > > Cc: Maxime Ripard > > Cc: Thomas Zimmermann > > Cc: David Airlie > > Cc: Daniel Vetter > > Cc: dri-devel@lists.freedesktop.org > > Signed-off-by: Lee Jones > > Going to apply this, but I noticed that the return value of the > build_query_stream_enc_status() is pointless. Can you pls follow up with > an additional patch to change that to void? I can. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 03/42] drm/drm_dp_mst_topology: Remove set but never used variable 'len'
On Tue, 17 Nov 2020, Lee Jones wrote: > On Tue, 17 Nov 2020, Daniel Vetter wrote: > > > On Mon, Nov 16, 2020 at 05:40:33PM +, Lee Jones wrote: > > > Fixes the following W=1 kernel build warning(s): > > > > > > 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:3263:6: warning: variable ‘len’ > > > set but not used [-Wunused-but-set-variable] > > > > > > Cc: Maarten Lankhorst > > > Cc: Maxime Ripard > > > Cc: Thomas Zimmermann > > > Cc: David Airlie > > > Cc: Daniel Vetter > > > Cc: dri-devel@lists.freedesktop.org > > > Signed-off-by: Lee Jones > > > > Going to apply this, but I noticed that the return value of the > > build_query_stream_enc_status() is pointless. Can you pls follow up with > > an additional patch to change that to void? > > I can. Looks like you're getting dropped again! -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/imx: depend on COMMON_CLK to fix compile tests
The iMX DRM LVDS driver uses Common Clock Framework thus it cannot be built on platforms without it (e.g. compile test on MIPS with RALINK and SOC_RT305X): /usr/bin/mips-linux-gnu-ld: drivers/gpu/drm/imx/imx-ldb.o: in function `imx_ldb_encoder_disable': imx-ldb.c:(.text+0x400): undefined reference to `clk_set_parent' Signed-off-by: Krzysztof Kozlowski --- Changes since v1: 1. Put depends in DRM_IMX_LDB option only. --- drivers/gpu/drm/imx/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/imx/Kconfig b/drivers/gpu/drm/imx/Kconfig index 6231048aa5aa..73fe2bc5633c 100644 --- a/drivers/gpu/drm/imx/Kconfig +++ b/drivers/gpu/drm/imx/Kconfig @@ -28,6 +28,7 @@ config DRM_IMX_TVE config DRM_IMX_LDB tristate "Support for LVDS displays" depends on DRM_IMX && MFD_SYSCON + depends on COMMON_CLK select DRM_PANEL help Choose this to enable the internal LVDS Display Bridge (LDB) -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 8/8] drm/amdgpu: Prevent any job recoveries after device is unplugged.
On 6/22/20 5:53 AM, Daniel Vetter wrote:
On Sun, Jun 21, 2020 at 02:03:08AM -0400, Andrey Grodzovsky wrote:
No point to try recovery if device is gone, just messes up things.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 16
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 8
2 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 6932d75..5d6d3d9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1129,12 +1129,28 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
return ret;
}
+static void amdgpu_cancel_all_tdr(struct amdgpu_device *adev)
+{
+ int i;
+
+ for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
+ struct amdgpu_ring *ring = adev->rings[i];
+
+ if (!ring || !ring->sched.thread)
+ continue;
+
+ cancel_delayed_work_sync(&ring->sched.work_tdr);
+ }
+}
I think this is a function that's supposed to be in drm/scheduler, not
here. Might also just be your cleanup code being ordered wrongly, or your
split in one of the earlier patches not done quite right.
-Daniel
This function iterates across all the schedulers per amdgpu device and accesses
amdgpu specific structures , drm/scheduler deals with single scheduler at most
so looks to me like this is the right place for this function
Andrey
+
static void
amdgpu_pci_remove(struct pci_dev *pdev)
{
struct drm_device *dev = pci_get_drvdata(pdev);
+ struct amdgpu_device *adev = dev->dev_private;
drm_dev_unplug(dev);
+ amdgpu_cancel_all_tdr(adev);
ttm_bo_unmap_virtual_address_space(&adev->mman.bdev);
amdgpu_driver_unload_kms(dev);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
index 4720718..87ff0c0 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
@@ -28,6 +28,8 @@
#include "amdgpu.h"
#include "amdgpu_trace.h"
+#include
+
static void amdgpu_job_timedout(struct drm_sched_job *s_job)
{
struct amdgpu_ring *ring = to_amdgpu_ring(s_job->sched);
@@ -37,6 +39,12 @@ static void amdgpu_job_timedout(struct drm_sched_job *s_job)
memset(&ti, 0, sizeof(struct amdgpu_task_info));
+ if (drm_dev_is_unplugged(adev->ddev)) {
+ DRM_INFO("ring %s timeout, but device unplugged, skipping.\n",
+ s_job->sched->name);
+ return;
+ }
+
if (amdgpu_ring_soft_recovery(ring, job->vmid, s_job->s_fence->parent))
{
DRM_ERROR("ring %s timeout, but soft recovered\n",
s_job->sched->name);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH][next] drm/amd/pm: fix spelling mistakes in dev_warn messages
On Tue, Nov 17, 2020 at 8:11 AM Colin King wrote:
>
> From: Colin Ian King
>
> There are two spelling mistakes in dev_warn messages. Fix these.
>
> Signed-off-by: Colin Ian King
Applied. Thanks!
Alex
> ---
> drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
> b/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
> index afa542a5af5f..9a2f72f21ed8 100644
> --- a/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
> +++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
> @@ -689,14 +689,14 @@ static int vangogh_od_edit_dpm_table(struct smu_context
> *smu, enum PP_OD_DPM_TAB
>
> if (input[0] == 0) {
> if (input[1] < smu->gfx_default_hard_min_freq) {
> - dev_warn(smu->adev->dev, "Fine grain setting
> minimun sclk (%ld) MHz is less than the minimum allowed (%d) MHz\n",
> + dev_warn(smu->adev->dev, "Fine grain setting
> minimum sclk (%ld) MHz is less than the minimum allowed (%d) MHz\n",
> input[1],
> smu->gfx_default_hard_min_freq);
> return -EINVAL;
> }
> smu->gfx_actual_hard_min_freq = input[1];
> } else if (input[0] == 1) {
> if (input[1] > smu->gfx_default_soft_max_freq) {
> - dev_warn(smu->adev->dev, "Fine grain setting
> maximun sclk (%ld) MHz is greater than the maximum allowed (%d) MHz\n",
> + dev_warn(smu->adev->dev, "Fine grain setting
> maximum sclk (%ld) MHz is greater than the maximum allowed (%d) MHz\n",
> input[1],
> smu->gfx_default_soft_max_freq);
> return -EINVAL;
> }
> --
> 2.28.0
>
> ___
> 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 v2 8/8] drm/amdgpu: Prevent any job recoveries after device is unplugged.
On Tue, Nov 17, 2020 at 01:38:14PM -0500, Andrey Grodzovsky wrote:
>
> On 6/22/20 5:53 AM, Daniel Vetter wrote:
> > On Sun, Jun 21, 2020 at 02:03:08AM -0400, Andrey Grodzovsky wrote:
> > > No point to try recovery if device is gone, just messes up things.
> > >
> > > Signed-off-by: Andrey Grodzovsky
> > > ---
> > > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 16
> > > drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 8
> > > 2 files changed, 24 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > > index 6932d75..5d6d3d9 100644
> > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > > @@ -1129,12 +1129,28 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
> > > return ret;
> > > }
> > > +static void amdgpu_cancel_all_tdr(struct amdgpu_device *adev)
> > > +{
> > > + int i;
> > > +
> > > + for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
> > > + struct amdgpu_ring *ring = adev->rings[i];
> > > +
> > > + if (!ring || !ring->sched.thread)
> > > + continue;
> > > +
> > > + cancel_delayed_work_sync(&ring->sched.work_tdr);
> > > + }
> > > +}
> > I think this is a function that's supposed to be in drm/scheduler, not
> > here. Might also just be your cleanup code being ordered wrongly, or your
> > split in one of the earlier patches not done quite right.
> > -Daniel
>
>
> This function iterates across all the schedulers per amdgpu device and
> accesses
> amdgpu specific structures , drm/scheduler deals with single scheduler at most
> so looks to me like this is the right place for this function
I guess we could keep track of all schedulers somewhere in a list in
struct drm_device and wrap this up. That was kinda the idea.
Minimally I think a tiny wrapper with docs for the
cancel_delayed_work_sync(&sched->work_tdr); which explains what you must
observe to make sure there's no race. I'm not exactly sure there's no
guarantee here we won't get a new tdr work launched right afterwards at
least, so this looks a bit like a hack.
-Daniel
>
> Andrey
>
>
> >
> > > +
> > > static void
> > > amdgpu_pci_remove(struct pci_dev *pdev)
> > > {
> > > struct drm_device *dev = pci_get_drvdata(pdev);
> > > + struct amdgpu_device *adev = dev->dev_private;
> > > drm_dev_unplug(dev);
> > > + amdgpu_cancel_all_tdr(adev);
> > > ttm_bo_unmap_virtual_address_space(&adev->mman.bdev);
> > > amdgpu_driver_unload_kms(dev);
> > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
> > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
> > > index 4720718..87ff0c0 100644
> > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
> > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
> > > @@ -28,6 +28,8 @@
> > > #include "amdgpu.h"
> > > #include "amdgpu_trace.h"
> > > +#include
> > > +
> > > static void amdgpu_job_timedout(struct drm_sched_job *s_job)
> > > {
> > > struct amdgpu_ring *ring = to_amdgpu_ring(s_job->sched);
> > > @@ -37,6 +39,12 @@ static void amdgpu_job_timedout(struct drm_sched_job
> > > *s_job)
> > > memset(&ti, 0, sizeof(struct amdgpu_task_info));
> > > + if (drm_dev_is_unplugged(adev->ddev)) {
> > > + DRM_INFO("ring %s timeout, but device unplugged, skipping.\n",
> > > + s_job->sched->name);
> > > + return;
> > > + }
> > > +
> > > if (amdgpu_ring_soft_recovery(ring, job->vmid,
> > > s_job->s_fence->parent)) {
> > > DRM_ERROR("ring %s timeout, but soft recovered\n",
> > > s_job->sched->name);
> > > --
> > > 2.7.4
> > >
--
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 21/42] drm/nouveau/nvkm/core/firmware: Fix formatting, provide missing param description
On Mon, Nov 16, 2020 at 05:40:51PM +, Lee Jones wrote: > ... and demote non-conformant kernel-doc header. > > Fixes the following W=1 kernel build warning(s): > > drivers/gpu/drm/nouveau/nvkm/core/firmware.c:71: warning: Function parameter > or member 'subdev' not described in 'nvkm_firmware_get' > drivers/gpu/drm/nouveau/nvkm/core/firmware.c:71: warning: Function parameter > or member 'fwname' not described in 'nvkm_firmware_get' > drivers/gpu/drm/nouveau/nvkm/core/firmware.c:71: warning: Function parameter > or member 'ver' not described in 'nvkm_firmware_get' > drivers/gpu/drm/nouveau/nvkm/core/firmware.c:71: warning: Function parameter > or member 'fw' not described in 'nvkm_firmware_get' > drivers/gpu/drm/nouveau/nvkm/core/firmware.c:106: warning: Function > parameter or member 'fw' not described in 'nvkm_firmware_put' > > Cc: Ben Skeggs Ben fyi I smashed this into drm-misc-next, seemed trivial enough to not be a bother. -Daniel > Cc: David Airlie > Cc: Daniel Vetter > Cc: dri-devel@lists.freedesktop.org > Cc: nouv...@lists.freedesktop.org > Signed-off-by: Lee Jones > --- > drivers/gpu/drm/nouveau/nvkm/core/firmware.c | 9 + > 1 file changed, 5 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/nouveau/nvkm/core/firmware.c > b/drivers/gpu/drm/nouveau/nvkm/core/firmware.c > index 8b25367917ca0..ca1f8463cff51 100644 > --- a/drivers/gpu/drm/nouveau/nvkm/core/firmware.c > +++ b/drivers/gpu/drm/nouveau/nvkm/core/firmware.c > @@ -58,9 +58,10 @@ nvkm_firmware_load_blob(const struct nvkm_subdev *subdev, > const char *base, > > /** > * nvkm_firmware_get - load firmware from the official nvidia/chip/ directory > - * @subdev subdevice that will use that firmware > - * @fwname name of firmware file to load > - * @fw firmware structure to load to > + * @subdev: subdevice that will use that firmware > + * @fwname: name of firmware file to load > + * @ver: firmware version to load > + * @fw: firmware structure to load to > * > * Use this function to load firmware files in the form > nvidia/chip/fwname.bin. > * Firmware files released by NVIDIA will always follow this format. > @@ -98,7 +99,7 @@ nvkm_firmware_get(const struct nvkm_subdev *subdev, const > char *fwname, int ver, > return -ENOENT; > } > > -/** > +/* > * nvkm_firmware_put - release firmware loaded with nvkm_firmware_get > */ > void > -- > 2.25.1 > -- 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: [Freedreno] [PATCH 17/42] drm/msm/disp/mdp5/mdp5_ctl: Demote non-conformant kernel-doc headers
On Mon, Nov 16, 2020 at 9:41 AM Lee Jones wrote: > > Very little attempt has been made to document these functions. > > Fixes the following W=1 kernel build warning(s): > > drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c:227: warning: Function parameter or > member 'ctl' not described in 'mdp5_ctl_set_encoder_state' > drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c:227: warning: Function parameter or > member 'pipeline' not described in 'mdp5_ctl_set_encoder_state' > drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c:227: warning: Function parameter or > member 'enabled' not described in 'mdp5_ctl_set_encoder_state' > drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c:227: warning: Excess function > parameter 'enable' description in 'mdp5_ctl_set_encoder_state' > drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c:529: warning: Function parameter or > member 'ctl' not described in 'mdp5_ctl_commit' > drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c:529: warning: Function parameter or > member 'pipeline' not described in 'mdp5_ctl_commit' > drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c:529: warning: Function parameter or > member 'flush_mask' not described in 'mdp5_ctl_commit' > drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c:529: warning: Function parameter or > member 'start' not described in 'mdp5_ctl_commit' > > Cc: Rob Clark > Cc: Sean Paul > Cc: David Airlie > Cc: Daniel Vetter > Cc: linux-arm-...@vger.kernel.org > Cc: dri-devel@lists.freedesktop.org > Cc: freedr...@lists.freedesktop.org > Signed-off-by: Lee Jones > Reviewed-by: Abhinav Kumar Thanks, this one I'll try to replace with actual doc fixes, but I'll pick up the rest (and possibly this one if I run out of time) in msm-next for v5.11 as soon as I switch back to my kernel hat (next day or two) BR, -R > --- > drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c > b/drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c > index 030279d7b64b7..b5c40f9773629 100644 > --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c > +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c > @@ -213,10 +213,10 @@ static void send_start_signal(struct mdp5_ctl *ctl) > spin_unlock_irqrestore(&ctl->hw_lock, flags); > } > > -/** > +/* > * mdp5_ctl_set_encoder_state() - set the encoder state > * > - * @enable: true, when encoder is ready for data streaming; false, otherwise. > + * @enabled: true, when encoder is ready for data streaming; false, > otherwise. > * > * Note: > * This encoder state is needed to trigger START signal (data path kickoff). > @@ -507,7 +507,7 @@ static void fix_for_single_flush(struct mdp5_ctl *ctl, > u32 *flush_mask, > } > } > > -/** > +/* > * mdp5_ctl_commit() - Register Flush > * > * The flush register is used to indicate several registers are all > -- > 2.25.1 > > ___ > Freedreno mailing list > freedr...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/freedreno ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 31/42] drm/ttm/ttm_bo: Fix one function header - demote lots of kernel-doc abuses
On Mon, Nov 16, 2020 at 09:33:48PM +0100, Christian König wrote: > Am 16.11.20 um 18:41 schrieb Lee Jones: > > Fixes the following W=1 kernel build warning(s): > > > > drivers/gpu/drm/ttm/ttm_bo.c:51: warning: Function parameter or member > > 'ttm_global_mutex' not described in 'DEFINE_MUTEX' > > drivers/gpu/drm/ttm/ttm_bo.c:286: warning: Function parameter or member > > 'bo' not described in 'ttm_bo_cleanup_memtype_use' > > drivers/gpu/drm/ttm/ttm_bo.c:359: warning: Function parameter or member > > 'bo' not described in 'ttm_bo_cleanup_refs' > > drivers/gpu/drm/ttm/ttm_bo.c:359: warning: Function parameter or member > > 'interruptible' not described in 'ttm_bo_cleanup_refs' > > drivers/gpu/drm/ttm/ttm_bo.c:359: warning: Function parameter or member > > 'no_wait_gpu' not described in 'ttm_bo_cleanup_refs' > > drivers/gpu/drm/ttm/ttm_bo.c:359: warning: Function parameter or member > > 'unlock_resv' not described in 'ttm_bo_cleanup_refs' > > drivers/gpu/drm/ttm/ttm_bo.c:424: warning: Function parameter or member > > 'bdev' not described in 'ttm_bo_delayed_delete' > > drivers/gpu/drm/ttm/ttm_bo.c:424: warning: Function parameter or member > > 'remove_all' not described in 'ttm_bo_delayed_delete' > > drivers/gpu/drm/ttm/ttm_bo.c:635: warning: Function parameter or member > > 'bo' not described in 'ttm_bo_evict_swapout_allowable' > > drivers/gpu/drm/ttm/ttm_bo.c:635: warning: Function parameter or member > > 'ctx' not described in 'ttm_bo_evict_swapout_allowable' > > drivers/gpu/drm/ttm/ttm_bo.c:635: warning: Function parameter or member > > 'locked' not described in 'ttm_bo_evict_swapout_allowable' > > drivers/gpu/drm/ttm/ttm_bo.c:635: warning: Function parameter or member > > 'busy' not described in 'ttm_bo_evict_swapout_allowable' > > drivers/gpu/drm/ttm/ttm_bo.c:769: warning: Function parameter or member > > 'bo' not described in 'ttm_bo_add_move_fence' > > drivers/gpu/drm/ttm/ttm_bo.c:769: warning: Function parameter or member > > 'man' not described in 'ttm_bo_add_move_fence' > > drivers/gpu/drm/ttm/ttm_bo.c:769: warning: Function parameter or member > > 'mem' not described in 'ttm_bo_add_move_fence' > > drivers/gpu/drm/ttm/ttm_bo.c:769: warning: Function parameter or member > > 'no_wait_gpu' not described in 'ttm_bo_add_move_fence' > > drivers/gpu/drm/ttm/ttm_bo.c:806: warning: Function parameter or member > > 'bo' not described in 'ttm_bo_mem_force_space' > > drivers/gpu/drm/ttm/ttm_bo.c:806: warning: Function parameter or member > > 'place' not described in 'ttm_bo_mem_force_space' > > drivers/gpu/drm/ttm/ttm_bo.c:806: warning: Function parameter or member > > 'mem' not described in 'ttm_bo_mem_force_space' > > drivers/gpu/drm/ttm/ttm_bo.c:806: warning: Function parameter or member > > 'ctx' not described in 'ttm_bo_mem_force_space' > > drivers/gpu/drm/ttm/ttm_bo.c:872: warning: Function parameter or member > > 'bo' not described in 'ttm_bo_mem_space' > > drivers/gpu/drm/ttm/ttm_bo.c:872: warning: Function parameter or member > > 'placement' not described in 'ttm_bo_mem_space' > > drivers/gpu/drm/ttm/ttm_bo.c:872: warning: Function parameter or member > > 'mem' not described in 'ttm_bo_mem_space' > > drivers/gpu/drm/ttm/ttm_bo.c:872: warning: Function parameter or member > > 'ctx' not described in 'ttm_bo_mem_space' > > drivers/gpu/drm/ttm/ttm_bo.c:1387: warning: Function parameter or member > > 'ctx' not described in 'ttm_bo_swapout' > > > > Cc: Christian Koenig > > Cc: Huang Rui > > Cc: David Airlie > > Cc: Daniel Vetter > > Cc: Sumit Semwal > > Cc: dri-devel@lists.freedesktop.org > > Cc: linux-me...@vger.kernel.org > > Cc: linaro-mm-...@lists.linaro.org > > Signed-off-by: Lee Jones > > Reviewed-by: Christian König > > Going to pick that one up for upstreaming. I mass applied this pile, so also this one. Thanks for patch&review. -Daniel > > Thanks, > Christian. > > > --- > > drivers/gpu/drm/ttm/ttm_bo.c | 23 --- > > 1 file changed, 12 insertions(+), 11 deletions(-) > > > > diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c > > index e6bcbfe530ecc..9a03c7834b1ed 100644 > > --- a/drivers/gpu/drm/ttm/ttm_bo.c > > +++ b/drivers/gpu/drm/ttm/ttm_bo.c > > @@ -45,7 +45,7 @@ > > static void ttm_bo_global_kobj_release(struct kobject *kobj); > > -/** > > +/* > >* ttm_global_mutex - protecting the global BO state > >*/ > > DEFINE_MUTEX(ttm_global_mutex); > > @@ -278,7 +278,7 @@ static int ttm_bo_handle_move_mem(struct > > ttm_buffer_object *bo, > > return ret; > > } > > -/** > > +/* > >* Call bo::reserved. > >* Will release GPU memory type usage on destruction. > >* This is the place to put in driver specific hooks to release > > @@ -352,9 +352,10 @@ static void ttm_bo_flush_all_fences(struct > > ttm_buffer_object *bo) > >* Must be called with lru_lock and reservation held, this function > >* will drop the lru lock and optionally the rese
Re: [PATCH 03/42] drm/drm_dp_mst_topology: Remove set but never used variable 'len'
On Tue, Nov 17, 2020 at 06:13:40PM +, Lee Jones wrote: > On Tue, 17 Nov 2020, Lee Jones wrote: > > > On Tue, 17 Nov 2020, Daniel Vetter wrote: > > > > > On Mon, Nov 16, 2020 at 05:40:33PM +, Lee Jones wrote: > > > > Fixes the following W=1 kernel build warning(s): > > > > > > > > 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:3263:6: warning: variable ‘len’ > > > > set but not used [-Wunused-but-set-variable] > > > > > > > > Cc: Maarten Lankhorst > > > > Cc: Maxime Ripard > > > > Cc: Thomas Zimmermann > > > > Cc: David Airlie > > > > Cc: Daniel Vetter > > > > Cc: dri-devel@lists.freedesktop.org > > > > Signed-off-by: Lee Jones > > > > > > Going to apply this, but I noticed that the return value of the > > > build_query_stream_enc_status() is pointless. Can you pls follow up with > > > an additional patch to change that to void? > > > > I can. > > Looks like you're getting dropped again! I get it on list. So not lost. tbh my personal cc: is such a disastrous mess it's actually easier to ping me with an interesting subject on dri-devel here ... -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 32/42] drm/ttm/ttm_tt: Demote kernel-doc header format abuses
On Tue, Nov 17, 2020 at 08:33:46AM +, Lee Jones wrote: > On Mon, 16 Nov 2020, Christian König wrote: > > > Am 16.11.20 um 18:41 schrieb Lee Jones: > > > Fixes the following W=1 kernel build warning(s): > > > > > > drivers/gpu/drm/ttm/ttm_tt.c:45: warning: Function parameter or member > > > 'bo' not described in 'ttm_tt_create' > > > drivers/gpu/drm/ttm/ttm_tt.c:45: warning: Function parameter or member > > > 'zero_alloc' not described in 'ttm_tt_create' > > > drivers/gpu/drm/ttm/ttm_tt.c:83: warning: Function parameter or member > > > 'ttm' not described in 'ttm_tt_alloc_page_directory' > > > > Couldn't we rather describe the missing parameters? Shouldn't be much work. > > My rule is; if a substantial attempt has been made to document > something, I'll patch it up. If little or no attempt has been made, > then it gets demoted. > > Please feel free to document and upgrade them once more. > > Bear in mind however, there is a script that reports on all files > which utilise kernel-doc notation but do not have matching references > from the Documentation area. > > See: scripts/find-unused-docs.sh ttm docs need some serious love anyway, so I think this is fine. I applied it. -Daniel > > > > Cc: Christian Koenig > > > Cc: Huang Rui > > > Cc: David Airlie > > > Cc: Daniel Vetter > > > Cc: dri-devel@lists.freedesktop.org > > > Signed-off-by: Lee Jones > > > --- > > > drivers/gpu/drm/ttm/ttm_tt.c | 4 ++-- > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c > > > index cfd633c7e7643..da9eeffe0c6d7 100644 > > > --- a/drivers/gpu/drm/ttm/ttm_tt.c > > > +++ b/drivers/gpu/drm/ttm/ttm_tt.c > > > @@ -38,7 +38,7 @@ > > > #include > > > #include > > > -/** > > > +/* > > >* Allocates a ttm structure for the given BO. > > >*/ > > > int ttm_tt_create(struct ttm_buffer_object *bo, bool zero_alloc) > > > @@ -73,7 +73,7 @@ int ttm_tt_create(struct ttm_buffer_object *bo, bool > > > zero_alloc) > > > return 0; > > > } > > > -/** > > > +/* > > >* Allocates storage for pointers to the pages that back the ttm. > > >*/ > > > static int ttm_tt_alloc_page_directory(struct ttm_tt *ttm) > > > > -- > Lee Jones [李琼斯] > Senior Technical Lead - Developer Services > Linaro.org │ Open source software for Arm SoCs > Follow Linaro: Facebook | Twitter | Blog -- 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 v2 8/8] drm/amdgpu: Prevent any job recoveries after device is unplugged.
On 11/17/20 1:52 PM, Daniel Vetter wrote:
On Tue, Nov 17, 2020 at 01:38:14PM -0500, Andrey Grodzovsky wrote:
On 6/22/20 5:53 AM, Daniel Vetter wrote:
On Sun, Jun 21, 2020 at 02:03:08AM -0400, Andrey Grodzovsky wrote:
No point to try recovery if device is gone, just messes up things.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 16
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 8
2 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 6932d75..5d6d3d9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1129,12 +1129,28 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
return ret;
}
+static void amdgpu_cancel_all_tdr(struct amdgpu_device *adev)
+{
+ int i;
+
+ for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
+ struct amdgpu_ring *ring = adev->rings[i];
+
+ if (!ring || !ring->sched.thread)
+ continue;
+
+ cancel_delayed_work_sync(&ring->sched.work_tdr);
+ }
+}
I think this is a function that's supposed to be in drm/scheduler, not
here. Might also just be your cleanup code being ordered wrongly, or your
split in one of the earlier patches not done quite right.
-Daniel
This function iterates across all the schedulers per amdgpu device and accesses
amdgpu specific structures , drm/scheduler deals with single scheduler at most
so looks to me like this is the right place for this function
I guess we could keep track of all schedulers somewhere in a list in
struct drm_device and wrap this up. That was kinda the idea.
Minimally I think a tiny wrapper with docs for the
cancel_delayed_work_sync(&sched->work_tdr); which explains what you must
observe to make sure there's no race.
Will do
I'm not exactly sure there's no
guarantee here we won't get a new tdr work launched right afterwards at
least, so this looks a bit like a hack.
Note that for any TDR work happening post amdgpu_cancel_all_tdr
amdgpu_job_timedout->drm_dev_is_unplugged
will return true and so it will return early. To make it water proof tight
against race
i can switch from drm_dev_is_unplugged to drm_dev_enter/exit
Andrey
-Daniel
Andrey
+
static void
amdgpu_pci_remove(struct pci_dev *pdev)
{
struct drm_device *dev = pci_get_drvdata(pdev);
+ struct amdgpu_device *adev = dev->dev_private;
drm_dev_unplug(dev);
+ amdgpu_cancel_all_tdr(adev);
ttm_bo_unmap_virtual_address_space(&adev->mman.bdev);
amdgpu_driver_unload_kms(dev);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
index 4720718..87ff0c0 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
@@ -28,6 +28,8 @@
#include "amdgpu.h"
#include "amdgpu_trace.h"
+#include
+
static void amdgpu_job_timedout(struct drm_sched_job *s_job)
{
struct amdgpu_ring *ring = to_amdgpu_ring(s_job->sched);
@@ -37,6 +39,12 @@ static void amdgpu_job_timedout(struct drm_sched_job *s_job)
memset(&ti, 0, sizeof(struct amdgpu_task_info));
+ if (drm_dev_is_unplugged(adev->ddev)) {
+ DRM_INFO("ring %s timeout, but device unplugged, skipping.\n",
+ s_job->sched->name);
+ return;
+ }
+
if (amdgpu_ring_soft_recovery(ring, job->vmid, s_job->s_fence->parent))
{
DRM_ERROR("ring %s timeout, but soft recovered\n",
s_job->sched->name);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/mcde: Fix RGB/BGR bug
Hi Linus On Tue, Nov 17, 2020 at 06:54:13PM +0100, Linus Walleij wrote: > I was confused when the graphics came out with blue > penguins on the DPI panel. > > It turns out that the so-called "packed RGB666" mode > on the DSI formatter is incorrect: this mode is the > actual RGB888 mode, and the mode called RGB888 is > BGR888. > > The claims that the MCDE had inverse RGB/BGR buffer > formats was wrong, so correct this and the buggy > register and everything is much more consistent, and > graphics look good on all targets, both DPI and > DSI. > > Cc: phone-de...@vger.kernel.org > Cc: Stephan Gerhold > Signed-off-by: Linus Walleij Fixes: ?? Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 38/42] drm/vc4/vc4_hdmi: Remove set but unused variable 'ret'
On Mon, Nov 16, 2020 at 05:41:08PM +, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/vc4/vc4_hdmi.c: In function ‘vc4_hdmi_set_audio_infoframe’:
> drivers/gpu/drm/vc4/vc4_hdmi.c:334:6: warning: variable ‘ret’ set but not
> used [-Wunused-but-set-variable]
>
> Cc: Eric Anholt
> Cc: Maxime Ripard
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Philipp Zabel
> Cc: Rob Clark
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Lee Jones
Hm this is another where I think the right thing to do is switch the
return value from int to void. All users are maintained in drm except
sound/soc, so probably good enough as a single patch. If you feel like,
otherwise I can type it up too.
Anyway applied this one here.
-Daniel
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 95779d50cca0b..b80eb9d3d9d5a 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -331,9 +331,8 @@ static void vc4_hdmi_set_audio_infoframe(struct
> drm_encoder *encoder)
> {
> struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
> union hdmi_infoframe frame;
> - int ret;
>
> - ret = hdmi_audio_infoframe_init(&frame.audio);
> + hdmi_audio_infoframe_init(&frame.audio);
>
> frame.audio.coding_type = HDMI_AUDIO_CODING_TYPE_STREAM;
> frame.audio.sample_frequency = HDMI_AUDIO_SAMPLE_FREQUENCY_STREAM;
> --
> 2.25.1
>
--
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 42/42] include/drm/drm_atomic: Make use of 'new_crtc_state'
On Mon, Nov 16, 2020 at 05:41:12PM +, Lee Jones wrote: > In the macro for_each_oldnew_crtc_in_state() 'crtc_state' is provided > as a container for state->crtcs[i].new_state, but is not utilised in > some use-cases, so we fake-use it instead. > > Fixes the following W=1 kernel build warning(s): > > drivers/gpu/drm/imx/ipuv3-plane.c: In function ‘ipu_planes_assign_pre’: > drivers/gpu/drm/imx/ipuv3-plane.c:746:42: warning: variable ‘crtc_state’ set > but not used [-Wunused-but-set-variable] > > Cc: Philipp Zabel > Cc: David Airlie > Cc: Daniel Vetter > Cc: Shawn Guo > Cc: Sascha Hauer > Cc: Pengutronix Kernel Team > Cc: Fabio Estevam > Cc: NXP Linux Team > Cc: dri-devel@lists.freedesktop.org > Signed-off-by: Lee Jones Ok I merged them all except: - drm/amd and drm/imx, should be picked up already by respective maintainers - drm/msm, Rob promised to take care Thanks a lot for your patches. -Daniel > --- > include/drm/drm_atomic.h | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h > index dc5e0fbecc04e..54e051a957dfc 100644 > --- a/include/drm/drm_atomic.h > +++ b/include/drm/drm_atomic.h > @@ -783,7 +783,8 @@ void drm_state_dump(struct drm_device *dev, struct > drm_printer *p); > (void)(crtc) /* Only to avoid > unused-but-set-variable warning */, \ >(old_crtc_state) = > (__state)->crtcs[__i].old_state, \ >(void)(old_crtc_state) /* Only to avoid > unused-but-set-variable warning */, \ > - (new_crtc_state) = > (__state)->crtcs[__i].new_state, 1)) > + (new_crtc_state) = > (__state)->crtcs[__i].new_state, \ > + (void)(new_crtc_state) /* Only to avoid > unused-but-set-variable warning */, 1)) > > /** > * for_each_old_crtc_in_state - iterate over all CRTCs in an atomic update > -- > 2.25.1 > -- 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 v2 8/8] drm/amdgpu: Prevent any job recoveries after device is unplugged.
On Tue, Nov 17, 2020 at 02:18:49PM -0500, Andrey Grodzovsky wrote:
>
> On 11/17/20 1:52 PM, Daniel Vetter wrote:
> > On Tue, Nov 17, 2020 at 01:38:14PM -0500, Andrey Grodzovsky wrote:
> > > On 6/22/20 5:53 AM, Daniel Vetter wrote:
> > > > On Sun, Jun 21, 2020 at 02:03:08AM -0400, Andrey Grodzovsky wrote:
> > > > > No point to try recovery if device is gone, just messes up things.
> > > > >
> > > > > Signed-off-by: Andrey Grodzovsky
> > > > > ---
> > > > >drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 16
> > > > >drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 8
> > > > >2 files changed, 24 insertions(+)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > > > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > > > > index 6932d75..5d6d3d9 100644
> > > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > > > > @@ -1129,12 +1129,28 @@ static int amdgpu_pci_probe(struct pci_dev
> > > > > *pdev,
> > > > > return ret;
> > > > >}
> > > > > +static void amdgpu_cancel_all_tdr(struct amdgpu_device *adev)
> > > > > +{
> > > > > + int i;
> > > > > +
> > > > > + for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
> > > > > + struct amdgpu_ring *ring = adev->rings[i];
> > > > > +
> > > > > + if (!ring || !ring->sched.thread)
> > > > > + continue;
> > > > > +
> > > > > + cancel_delayed_work_sync(&ring->sched.work_tdr);
> > > > > + }
> > > > > +}
> > > > I think this is a function that's supposed to be in drm/scheduler, not
> > > > here. Might also just be your cleanup code being ordered wrongly, or
> > > > your
> > > > split in one of the earlier patches not done quite right.
> > > > -Daniel
> > >
> > > This function iterates across all the schedulers per amdgpu device and
> > > accesses
> > > amdgpu specific structures , drm/scheduler deals with single scheduler at
> > > most
> > > so looks to me like this is the right place for this function
> > I guess we could keep track of all schedulers somewhere in a list in
> > struct drm_device and wrap this up. That was kinda the idea.
> >
> > Minimally I think a tiny wrapper with docs for the
> > cancel_delayed_work_sync(&sched->work_tdr); which explains what you must
> > observe to make sure there's no race.
>
>
> Will do
>
>
> > I'm not exactly sure there's no
> > guarantee here we won't get a new tdr work launched right afterwards at
> > least, so this looks a bit like a hack.
>
>
> Note that for any TDR work happening post amdgpu_cancel_all_tdr
> amdgpu_job_timedout->drm_dev_is_unplugged
> will return true and so it will return early. To make it water proof tight
> against race
> i can switch from drm_dev_is_unplugged to drm_dev_enter/exit
Hm that's confusing. You do a work_cancel_sync, so that at least looks
like "tdr work must not run after this point"
If you only rely on drm_dev_enter/exit check with the tdr work, then
there's no need to cancel anything.
For race free cancel_work_sync you need:
1. make sure whatever is calling schedule_work is guaranteed to no longer
call schedule_work.
2. call cancel_work_sync
Anything else is cargo-culted work cleanup:
- 1. without 2. means if a work got scheduled right before it'll still be
a problem.
- 2. without 1. means a schedule_work right after makes you calling
cancel_work_sync pointless.
So either both or nothing.
-Daniel
>
> Andrey
>
>
> > -Daniel
> >
> > > Andrey
> > >
> > >
> > > > > +
> > > > >static void
> > > > >amdgpu_pci_remove(struct pci_dev *pdev)
> > > > >{
> > > > > struct drm_device *dev = pci_get_drvdata(pdev);
> > > > > + struct amdgpu_device *adev = dev->dev_private;
> > > > > drm_dev_unplug(dev);
> > > > > + amdgpu_cancel_all_tdr(adev);
> > > > > ttm_bo_unmap_virtual_address_space(&adev->mman.bdev);
> > > > > amdgpu_driver_unload_kms(dev);
> > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
> > > > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
> > > > > index 4720718..87ff0c0 100644
> > > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
> > > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
> > > > > @@ -28,6 +28,8 @@
> > > > >#include "amdgpu.h"
> > > > >#include "amdgpu_trace.h"
> > > > > +#include
> > > > > +
> > > > >static void amdgpu_job_timedout(struct drm_sched_job *s_job)
> > > > >{
> > > > > struct amdgpu_ring *ring = to_amdgpu_ring(s_job->sched);
> > > > > @@ -37,6 +39,12 @@ static void amdgpu_job_timedout(struct
> > > > > drm_sched_job *s_job)
> > > > > memset(&ti, 0, sizeof(struct amdgpu_task_info));
> > > > > + if (drm_dev_is_unplugged(adev->ddev)) {
> > > > > + DRM_INFO("ring %s timeout, but device unplugged,
> > > > > skipping.\n",
> > > > > + s_job->sched->name);
> > > > > + return;
> > > > > + }
> > > > > +
> > > > > if (amdgpu
Re: [PATCH] drm/msm: Fix error return code in msm_drm_init()
On 2020-11-16 18:36, Wei Li wrote:
When it fail to create crtc_event kthread, it just jump to
err_msm_uninit,
while the 'ret' is not updated. So assign the return code before that.
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Reported-by: Hulk Robot
Signed-off-by: Wei Li
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/msm_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/msm/msm_drv.c
b/drivers/gpu/drm/msm/msm_drv.c
index 49685571dc0e..37a373c5ced3 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -506,6 +506,7 @@ static int msm_drm_init(struct device *dev, struct
drm_driver *drv)
"crtc_event:%d", priv->event_thread[i].crtc_id);
if (IS_ERR(priv->event_thread[i].worker)) {
DRM_DEV_ERROR(dev, "failed to create crtc_event
kthread\n");
+ ret = PTR_ERR(priv->event_thread[i].worker);
goto err_msm_uninit;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
