[Bug 111244] amdgpu kernel 5.2 blank display after resume from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=111244 --- Comment #12 from csp...@verizon.net --- One thing to note, the problem doesn't seem to occur for me if a compositor isn't running. In my case, after disabling compton I could not reproduce the problem. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: fbdev: omapfb_main: Mark expected switch fall-throughs
On Fri, Aug 02, 2019 at 02:15:42PM -0500, Gustavo A. R. Silva wrote: > Mark switch cases where we are expecting to fall through. > > This patch fixes the following warning (Building: omap1_defconfig arm): > > drivers/video/fbdev/omap/omapfb_main.c:449:23: warning: this statement may > fall through [-Wimplicit-fallthrough=] > drivers/video/fbdev/omap/omapfb_main.c:1549:6: warning: this statement may > fall through [-Wimplicit-fallthrough=] > drivers/video/fbdev/omap/omapfb_main.c:1547:3: warning: this statement may > fall through [-Wimplicit-fallthrough=] > drivers/video/fbdev/omap/omapfb_main.c:1545:3: warning: this statement may > fall through [-Wimplicit-fallthrough=] > drivers/video/fbdev/omap/omapfb_main.c:1543:3: warning: this statement may > fall through [-Wimplicit-fallthrough=] > drivers/video/fbdev/omap/omapfb_main.c:1540:6: warning: this statement may > fall through [-Wimplicit-fallthrough=] > drivers/video/fbdev/omap/omapfb_main.c:1538:3: warning: this statement may > fall through [-Wimplicit-fallthrough=] > drivers/video/fbdev/omap/omapfb_main.c:1535:3: warning: this statement may > fall through [-Wimplicit-fallthrough=] > > Signed-off-by: Gustavo A. R. Silva Reviewed-by: Kees Cook -Kees > --- > drivers/video/fbdev/omap/omapfb_main.c | 8 > 1 file changed, 8 insertions(+) > > diff --git a/drivers/video/fbdev/omap/omapfb_main.c > b/drivers/video/fbdev/omap/omapfb_main.c > index 90eca64e3144..702cca59bda1 100644 > --- a/drivers/video/fbdev/omap/omapfb_main.c > +++ b/drivers/video/fbdev/omap/omapfb_main.c > @@ -447,6 +447,7 @@ static int set_color_mode(struct omapfb_plane_struct > *plane, > return 0; > case 12: > var->bits_per_pixel = 16; > + /* fall through */ > case 16: > if (plane->fbdev->panel->bpp == 12) > plane->color_mode = OMAPFB_COLOR_RGB444; > @@ -1534,20 +1535,27 @@ static void omapfb_free_resources(struct > omapfb_device *fbdev, int state) > case OMAPFB_ACTIVE: > for (i = 0; i < fbdev->mem_desc.region_cnt; i++) > unregister_framebuffer(fbdev->fb_info[i]); > + /* fall through */ > case 7: > omapfb_unregister_sysfs(fbdev); > + /* fall through */ > case 6: > if (fbdev->panel->disable) > fbdev->panel->disable(fbdev->panel); > + /* fall through */ > case 5: > omapfb_set_update_mode(fbdev, OMAPFB_UPDATE_DISABLED); > + /* fall through */ > case 4: > planes_cleanup(fbdev); > + /* fall through */ > case 3: > ctrl_cleanup(fbdev); > + /* fall through */ > case 2: > if (fbdev->panel->cleanup) > fbdev->panel->cleanup(fbdev->panel); > + /* fall through */ > case 1: > dev_set_drvdata(fbdev->dev, NULL); > kfree(fbdev); > -- > 2.22.0 > -- Kees Cook ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110214] Raven Ridge (2400G): xterm scrollback buffer disappears while Shift+PgUp and Shift+PgDn
https://bugs.freedesktop.org/show_bug.cgi?id=110214 --- Comment #100 from Diego Viola --- (In reply to Michel Dänzer from comment #99) > https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1554 has some fixes > for DPBB, might help for this as well. Unfortunately it doesn't help, I compiled mesa to /usr/local (from his dpbb_fixes branch) but the issue is still there. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH AUTOSEL 5.2 42/76] drm/msm: stop abusing dma_map/unmap for cache
Hi Sasha,
It's probably best *not* to backport this patch.. drm/msm abuses the
DMA API in a way that it is not intended be used, to work around the
lack of cache sync API exported to kernel modules on arm/arm64. I
couldn't really guarantee that this patch does the right thing on
older versions of DMA API, so best to leave things as they were.
BR,
-R
On Fri, Aug 2, 2019 at 6:21 AM Sasha Levin wrote:
>
> From: Rob Clark
>
> [ Upstream commit 0036bc73ccbe7e600a3468bf8e8879b122252274 ]
>
> Recently splats like this started showing up:
>
>WARNING: CPU: 4 PID: 251 at drivers/iommu/dma-iommu.c:451
> __iommu_dma_unmap+0xb8/0xc0
>Modules linked in: ath10k_snoc ath10k_core fuse msm ath mac80211 uvcvideo
> cfg80211 videobuf2_vmalloc videobuf2_memops vide
>CPU: 4 PID: 251 Comm: kworker/u16:4 Tainted: GW
> 5.2.0-rc5-next-20190619+ #2317
>Hardware name: LENOVO 81JL/LNVNB161216, BIOS 9UCN23WW(V1.06) 10/25/2018
>Workqueue: msm msm_gem_free_work [msm]
>pstate: 80c5 (Nzcv daif +PAN +UAO)
>pc : __iommu_dma_unmap+0xb8/0xc0
>lr : __iommu_dma_unmap+0x54/0xc0
>sp : 119abce0
>x29: 119abce0 x28:
>x27: 8001f9946648 x26: 8001ec271068
>x25: x24: 8001ea3580a8
>x23: 8001f95ba010 x22: 80018e83ba88
>x21: 8001e548f000 x20: f000
>x19: 1000 x18: c1fe
>x17: x16:
>x15: 15b70068 x14: 0005
>x13: 0003142cc1be1768 x12: 0001
>x11: 8001f6de9100 x10: 0009
>x9 : 15b78000 x8 :
>x7 : 0001 x6 : f000
>x5 : 0fff x4 : 1065dbc8
>x3 : 000d x2 : 1000
>x1 : f000 x0 :
>Call trace:
> __iommu_dma_unmap+0xb8/0xc0
> iommu_dma_unmap_sg+0x98/0xb8
> put_pages+0x5c/0xf0 [msm]
> msm_gem_free_work+0x10c/0x150 [msm]
> process_one_work+0x1e0/0x330
> worker_thread+0x40/0x438
> kthread+0x12c/0x130
> ret_from_fork+0x10/0x18
>---[ end trace afc0dc5ab81a06bf ]---
>
> Not quite sure what triggered that, but we really shouldn't be abusing
> dma_{map,unmap}_sg() for cache maint.
>
> Cc: Stephen Boyd
> Tested-by: Stephen Boyd
> Reviewed-by: Jordan Crouse
> Signed-off-by: Rob Clark
> Signed-off-by: Sean Paul
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20190630124735.27786-1-robdcl...@gmail.com
> Signed-off-by: Sasha Levin
> ---
> drivers/gpu/drm/msm/msm_gem.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
> index 49a019939ccdc..a3b5fe1a13944 100644
> --- a/drivers/gpu/drm/msm/msm_gem.c
> +++ b/drivers/gpu/drm/msm/msm_gem.c
> @@ -97,7 +97,7 @@ static struct page **get_pages(struct drm_gem_object *obj)
> * because display controller, GPU, etc. are not coherent:
> */
> if (msm_obj->flags & (MSM_BO_WC|MSM_BO_UNCACHED))
> - dma_map_sg(dev->dev, msm_obj->sgt->sgl,
> + dma_sync_sg_for_device(dev->dev, msm_obj->sgt->sgl,
> msm_obj->sgt->nents,
> DMA_BIDIRECTIONAL);
> }
>
> @@ -127,7 +127,7 @@ static void put_pages(struct drm_gem_object *obj)
> * GPU, etc. are not coherent:
> */
> if (msm_obj->flags & (MSM_BO_WC|MSM_BO_UNCACHED))
> - dma_unmap_sg(obj->dev->dev, msm_obj->sgt->sgl,
> + dma_sync_sg_for_cpu(obj->dev->dev,
> msm_obj->sgt->sgl,
> msm_obj->sgt->nents,
> DMA_BIDIRECTIONAL);
>
> --
> 2.20.1
>
Re: [PATCH 03/34] net/ceph: convert put_page() to put_user_page*()
On Thu, 2019-08-01 at 19:19 -0700, john.hubb...@gmail.com wrote:
> From: John Hubbard
>
> For pages that were retained via get_user_pages*(), release those pages
> via the new put_user_page*() routines, instead of via put_page() or
> release_pages().
>
> This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
> ("mm: introduce put_user_page*(), placeholder versions").
>
> Cc: Ilya Dryomov
> Cc: Sage Weil
> Cc: David S. Miller
> Cc: ceph-de...@vger.kernel.org
> Cc: net...@vger.kernel.org
> Signed-off-by: John Hubbard
> ---
> net/ceph/pagevec.c | 8 +---
> 1 file changed, 1 insertion(+), 7 deletions(-)
>
> diff --git a/net/ceph/pagevec.c b/net/ceph/pagevec.c
> index 64305e7056a1..c88fff2ab9bd 100644
> --- a/net/ceph/pagevec.c
> +++ b/net/ceph/pagevec.c
> @@ -12,13 +12,7 @@
>
> void ceph_put_page_vector(struct page **pages, int num_pages, bool dirty)
> {
> - int i;
> -
> - for (i = 0; i < num_pages; i++) {
> - if (dirty)
> - set_page_dirty_lock(pages[i]);
> - put_page(pages[i]);
> - }
> + put_user_pages_dirty_lock(pages, num_pages, dirty);
> kvfree(pages);
> }
> EXPORT_SYMBOL(ceph_put_page_vector);
This patch looks sane enough. Assuming that the earlier patches are OK:
Acked-by: Jeff Layton
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Bug 204407] New: Bad page state in process Xorg
(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Thu, 01 Aug 2019 22:34:16 + bugzilla-dae...@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=204407 > > Bug ID: 204407 >Summary: Bad page state in process Xorg >Product: Memory Management >Version: 2.5 > Kernel Version: 5.3.0-rc2-00013 > Hardware: All > OS: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: Page Allocator > Assignee: a...@linux-foundation.org > Reporter: p...@vandrovec.name > Regression: No > > Created attachment 284081 > --> https://bugzilla.kernel.org/attachment.cgi?id=284081=edit > dmesg > > I've upgraded from 5.3-rc1 to 5.3-rc2, and when I started X server, system > became unhappy: > > [259701.387365] BUG: Bad page state in process Xorg pfn:2a300 > [259701.393593] page:eaa8c000 refcount:0 mapcount:-128 > mapping: index:0x0 > [259701.402832] flags: 0x2000() > [259701.407426] raw: 2000 822ab778 eaa8f208 > > [259701.415900] raw: 0003 ff7f > > [259701.424373] page dumped because: nonzero mapcount > [259701.429847] Modules linked in: af_packet xt_REDIRECT nft_compat x_tables > nft_counter nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv4 nf_tables > nfnetlink ppdev parport fuse autofs4 binfmt_misc uinput twofish_generic > twofish_avx_x86_64 twofish_x86_64_3way twofish_x86_64 twofish_common > camellia_generic camellia_aesni_avx_x86_64 camellia_x86_64 serpent_avx_x86_64 > serpent_sse2_x86_64 serpent_generic blowfish_generic blowfish_x86_64 > blowfish_common cast5_avx_x86_64 cast5_generic cast_common des_generic cmac > xcbc rmd160 af_key xfrm_algo rpcsec_gss_krb5 nfsv4 nls_iso8859_2 cifs libarc4 > nfsv3 nfsd auth_rpcgss nfs_acl nfs lockd grace fscache sunrpc ipv6 crc_ccitt > nf_defrag_ipv6 snd_hda_codec_hdmi pktcdvd coretemp hwmon intel_rapl_common > iosf_mbi x86_pkg_temp_thermal snd_hda_codec_realtek snd_hda_codec_generic > ledtrig_audio snd_hda_intel snd_hda_codec crct10dif_pclmul crc32_pclmul > snd_hwdep crc32c_intel snd_hda_core ghash_clmulni_intel snd_pcm_oss uas > iTCO_wdt aesni_intel e1000e > [259701.429873] snd_mixer_oss iTCO_vendor_support aes_x86_64 snd_pcm > crypto_simd ptp mei_me dcdbas lpc_ich sr_mod cryptd usb_storage snd_timer > glue_helper mfd_core input_leds pps_core tpm_tis cdrom i2c_i801 snd mei > tpm_tis_core sg tpm [last unloaded: parport_pc] > [259701.539387] CPU: 10 PID: 4860 Comm: Xorg Tainted: GT > 5.3.0-rc2-64-00013-g03f05a670a3d #69 > [259701.549382] Hardware name: Dell Inc. Precision T3610/09M8Y8, BIOS A16 > 02/05/2018 > [259701.549382] Call Trace: > [259701.549382] dump_stack+0x46/0x60 > [259701.549382] bad_page.cold.28+0x81/0xb4 > [259701.549382] __free_pages_ok+0x236/0x240 > [259701.549382] __ttm_dma_free_page+0x2f/0x40 > [259701.549382] ttm_dma_unpopulate+0x29b/0x370 > [259701.549382] ttm_tt_destroy.part.6+0x44/0x50 > [259701.549382] ttm_bo_cleanup_memtype_use+0x29/0x70 > [259701.549382] ttm_bo_put+0x225/0x280 > [259701.549382] ttm_bo_vm_close+0x10/0x20 > [259701.549382] remove_vma+0x20/0x40 > [259701.549382] __do_munmap+0x2da/0x420 > [259701.549382] __vm_munmap+0x66/0xc0 > [259701.549382] __x64_sys_munmap+0x22/0x30 > [259701.549382] do_syscall_64+0x5e/0x1a0 > [259701.549382] ? prepare_exit_to_usermode+0x75/0xa0 > [259701.549382] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > [259701.549382] RIP: 0033:0x7f504d0ec1d7 > [259701.549382] Code: 10 e9 67 ff ff ff 0f 1f 44 00 00 48 8b 15 b1 6c 0c 00 f7 > d8 64 89 02 48 c7 c0 ff ff ff ff e9 6b ff ff ff b8 0b 00 00 00 0f 05 <48> 3d > 01 > f0 ff ff 73 01 c3 48 8b 0d 89 6c 0c 00 f7 d8 64 89 01 48 > [259701.549382] RSP: 002b:7ffe529db138 EFLAGS: 0206 ORIG_RAX: > 000b > [259701.549382] RAX: ffda RBX: 564a5eabce70 RCX: > 7f504d0ec1d7 > [259701.549382] RDX: 7ffe529db140 RSI: 0040 RDI: > 7f5044b65000 > [259701.549382] RBP: 564a5eafe460 R08: 000b R09: > 00010283e000 > [259701.549382] R10: 0001 R11: 0206 R12: > 564a5e475b08 > [259701.549382] R13: 564a5e475c80 R14: 7ffe529db190 R15: > 0c80 > [259701.707238] Disabling lock debugging due to kernel taint I assume the above is misbehaviour in the DRM code? > > Also - maybe related, maybe not - I've got three userspace crashes earlier on > this kernel (but never before): > > [77154.886836] iscons.py[12441]: segfault at 2c ip 080cf0b5 sp > f773fb60 error 4 in python[8048000+11a000] > [77154.898376] Code: 02 0f 84 4a 2e 00 00 8b 4d 08 8b bd 04 ff ff ff 8b 59 38 > 8b 57 20 8b 7b 10 85 ff 0f 84 ee 22 00 00 8b 8d 04 ff ff ff 8b 59 08 <8b> 43 > 2c > 85
[Bug 109538] VAAPI HEVC encoding is unstable and produces garbled output
https://bugs.freedesktop.org/show_bug.cgi?id=109538 --- Comment #2 from tempel.jul...@gmail.com --- Doesn't crash anymore, but there is still a garbled line at the bottom of video frames. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panfrost: Remove completed features still in TODO
On Fri, 2 Aug 2019 13:57:27 -0600 Rob Herring wrote: > There's a few features the driver supports which we forgot to remove, so > remove them now. > > Cc: Tomeu Vizoso > Cc: Boris Brezillon Reviewed-by: Boris Brezillon > Signed-off-by: Rob Herring > --- > drivers/gpu/drm/panfrost/TODO | 9 - > 1 file changed, 9 deletions(-) > > diff --git a/drivers/gpu/drm/panfrost/TODO b/drivers/gpu/drm/panfrost/TODO > index c2e44add37d8..2ac972a3469c 100644 > --- a/drivers/gpu/drm/panfrost/TODO > +++ b/drivers/gpu/drm/panfrost/TODO > @@ -1,15 +1,9 @@ > -- Thermal support. > - > - Bifrost support: >- DT bindings (Neil, WIP) >- MMU page table format and address space setup >- Bifrost specific feature and issue handling >- Coherent DMA support > > -- Support for 2MB pages. The io-pgtable code already supports this. Finishing > - support involves either copying or adapting the iommu API to handle passing > - aligned addresses and sizes to the io-pgtable code. > - > - Per FD address space support. The h/w supports multiple addresses spaces. >The hard part is handling when more address spaces are needed than what >the h/w provides. > @@ -22,6 +16,3 @@ > > - Compute job support. So called 'compute only' jobs need to be plumbed up to >userspace. > - > -- Performance counter support. (Boris) > - ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/panfrost: Remove completed features still in TODO
There's a few features the driver supports which we forgot to remove, so remove them now. Cc: Tomeu Vizoso Cc: Boris Brezillon Signed-off-by: Rob Herring --- drivers/gpu/drm/panfrost/TODO | 9 - 1 file changed, 9 deletions(-) diff --git a/drivers/gpu/drm/panfrost/TODO b/drivers/gpu/drm/panfrost/TODO index c2e44add37d8..2ac972a3469c 100644 --- a/drivers/gpu/drm/panfrost/TODO +++ b/drivers/gpu/drm/panfrost/TODO @@ -1,15 +1,9 @@ -- Thermal support. - - Bifrost support: - DT bindings (Neil, WIP) - MMU page table format and address space setup - Bifrost specific feature and issue handling - Coherent DMA support -- Support for 2MB pages. The io-pgtable code already supports this. Finishing - support involves either copying or adapting the iommu API to handle passing - aligned addresses and sizes to the io-pgtable code. - - Per FD address space support. The h/w supports multiple addresses spaces. The hard part is handling when more address spaces are needed than what the h/w provides. @@ -22,6 +16,3 @@ - Compute job support. So called 'compute only' jobs need to be plumbed up to userspace. - -- Performance counter support. (Boris) - -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 8/8] drm/panfrost: Bump driver version to 1.1
Increment the driver version to expose the new BO allocation flags.
Cc: Tomeu Vizoso
Cc: Boris Brezillon
Cc: Robin Murphy
Cc: Steven Price
Acked-by: Alyssa Rosenzweig
Signed-off-by: Rob Herring
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index a7126b5f8e5d..ecdbe2c9fd67 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -357,6 +357,11 @@ static const struct drm_ioctl_desc
panfrost_drm_driver_ioctls[] = {
DEFINE_DRM_GEM_SHMEM_FOPS(panfrost_drm_driver_fops);
+/*
+ * Panfrost driver version:
+ * - 1.0 - initial interface
+ * - 1.1 - adds HEAP and NOEXEC flags for CREATE_BO
+ */
static struct drm_driver panfrost_drm_driver = {
.driver_features= DRIVER_RENDER | DRIVER_GEM | DRIVER_SYNCOBJ,
.open = panfrost_open,
@@ -368,7 +373,7 @@ static struct drm_driver panfrost_drm_driver = {
.desc = "panfrost DRM",
.date = "20180908",
.major = 1,
- .minor = 0,
+ .minor = 1,
.gem_create_object = panfrost_gem_create_object,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 5/8] drm/panfrost: Add a no execute flag for BO allocations
Executable buffers have an alignment restriction that they can't cross
16MB boundary as the GPU program counter is 24-bits. This restriction is
currently not handled and we just get lucky. As current userspace
assumes all BOs are executable, that has to remain the default. So add a
new PANFROST_BO_NOEXEC flag to allow userspace to indicate which BOs are
not executable.
There is also a restriction that executable buffers cannot start or end
on a 4GB boundary. This is mostly avoided as there is only 4GB of space
currently and the beginning is already blocked out for NULL ptr
detection. Add support to handle this restriction fully regardless of
the current constraints.
For existing userspace, all created BOs remain executable, but the GPU
VA alignment will be increased to the size of the BO. This shouldn't
matter as there is plenty of GPU VA space.
Cc: Tomeu Vizoso
Cc: Boris Brezillon
Cc: Robin Murphy
Reviewed-by: Steven Price
Acked-by: Alyssa Rosenzweig
Signed-off-by: Rob Herring
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 30 -
drivers/gpu/drm/panfrost/panfrost_gem.c | 18 +--
drivers/gpu/drm/panfrost/panfrost_gem.h | 3 ++-
drivers/gpu/drm/panfrost/panfrost_mmu.c | 3 +++
include/uapi/drm/panfrost_drm.h | 2 ++
5 files changed, 52 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index d354b92964d5..7ebd82d8d570 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -49,7 +49,8 @@ static int panfrost_ioctl_create_bo(struct drm_device *dev,
void *data,
struct panfrost_gem_object *bo;
struct drm_panfrost_create_bo *args = data;
- if (!args->size || args->flags || args->pad)
+ if (!args->size || args->pad ||
+ (args->flags & ~PANFROST_BO_NOEXEC))
return -EINVAL;
bo = panfrost_gem_create_with_handle(file, dev, args->size, args->flags,
@@ -367,6 +368,32 @@ static struct drm_driver panfrost_drm_driver = {
.gem_prime_mmap = drm_gem_prime_mmap,
};
+#define PFN_4G (SZ_4G >> PAGE_SHIFT)
+#define PFN_4G_MASK(PFN_4G - 1)
+#define PFN_16M(SZ_16M >> PAGE_SHIFT)
+
+static void panfrost_drm_mm_color_adjust(const struct drm_mm_node *node,
+unsigned long color,
+u64 *start, u64 *end)
+{
+ /* Executable buffers can't start or end on a 4GB boundary */
+ if (!(color & PANFROST_BO_NOEXEC)) {
+ u64 next_seg;
+
+ if ((*start & PFN_4G_MASK) == 0)
+ (*start)++;
+
+ if ((*end & PFN_4G_MASK) == 0)
+ (*end)--;
+
+ next_seg = ALIGN(*start, PFN_4G);
+ if (next_seg - *start <= PFN_16M)
+ *start = next_seg + 1;
+
+ *end = min(*end, ALIGN(*start, PFN_4G) - 1);
+ }
+}
+
static int panfrost_probe(struct platform_device *pdev)
{
struct panfrost_device *pfdev;
@@ -394,6 +421,7 @@ static int panfrost_probe(struct platform_device *pdev)
/* 4G enough for now. can be 48-bit */
drm_mm_init(>mm, SZ_32M >> PAGE_SHIFT, (SZ_4G - SZ_32M) >>
PAGE_SHIFT);
+ pfdev->mm.color_adjust = panfrost_drm_mm_color_adjust;
pm_runtime_use_autosuspend(pfdev->dev);
pm_runtime_set_autosuspend_delay(pfdev->dev, 50); /* ~3 frames */
diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.c
b/drivers/gpu/drm/panfrost/panfrost_gem.c
index df70dcf3cb2f..63731f6c5223 100644
--- a/drivers/gpu/drm/panfrost/panfrost_gem.c
+++ b/drivers/gpu/drm/panfrost/panfrost_gem.c
@@ -66,11 +66,23 @@ static int panfrost_gem_map(struct panfrost_device *pfdev,
struct panfrost_gem_o
{
int ret;
size_t size = bo->base.base.size;
- u64 align = size >= SZ_2M ? SZ_2M >> PAGE_SHIFT : 0;
+ u64 align;
+ unsigned long color = bo->noexec ? PANFROST_BO_NOEXEC : 0;
+
+ /*
+* Executable buffers cannot cross a 16MB boundary as the program
+* counter is 24-bits. We assume executable buffers will be less than
+* 16MB and aligning executable buffers to their size will avoid
+* crossing a 16MB boundary.
+*/
+ if (!bo->noexec)
+ align = size >> PAGE_SHIFT;
+ else
+ align = size >= SZ_2M ? SZ_2M >> PAGE_SHIFT : 0;
spin_lock(>mm_lock);
ret = drm_mm_insert_node_generic(>mm, >node,
-size >> PAGE_SHIFT, align, 0, 0);
+size >> PAGE_SHIFT, align, color, 0);
spin_unlock(>mm_lock);
if (ret)
return ret;
@@ -96,6 +108,7 @@ panfrost_gem_create_with_handle(struct drm_file *file_priv,
return ERR_CAST(shmem);
bo = to_panfrost_bo(>base);
+ bo->noexec = !!(flags &
[PATCH v3 7/8] drm/panfrost: Add support for GPU heap allocations
The midgard/bifrost GPUs need to allocate GPU heap memory which is
allocated on GPU page faults and not pinned in memory. The vendor driver
calls this functionality GROW_ON_GPF.
This implementation assumes that BOs allocated with the
PANFROST_BO_NOEXEC flag are never mmapped or exported. Both of those may
actually work, but I'm unsure if there's some interaction there. It
would cause the whole object to be pinned in memory which would defeat
the point of this.
On faults, we map in 2MB at a time in order to utilize huge pages (if
enabled). Currently, once we've mapped pages in, they are only unmapped
if the BO is freed. Once we add shrinker support, we can unmap pages
with the shrinker.
Cc: Tomeu Vizoso
Cc: Boris Brezillon
Cc: Robin Murphy
Cc: Steven Price
Acked-by: Alyssa Rosenzweig
Signed-off-by: Rob Herring
---
drivers/gpu/drm/panfrost/TODO | 2 -
drivers/gpu/drm/panfrost/panfrost_drv.c | 11 +-
drivers/gpu/drm/panfrost/panfrost_gem.c | 36 ++-
drivers/gpu/drm/panfrost/panfrost_gem.h | 8 ++
drivers/gpu/drm/panfrost/panfrost_mmu.c | 129 ++--
include/uapi/drm/panfrost_drm.h | 1 +
6 files changed, 172 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/TODO b/drivers/gpu/drm/panfrost/TODO
index c2e44add37d8..64129bf73933 100644
--- a/drivers/gpu/drm/panfrost/TODO
+++ b/drivers/gpu/drm/panfrost/TODO
@@ -14,8 +14,6 @@
The hard part is handling when more address spaces are needed than what
the h/w provides.
-- Support pinning pages on demand (GPU page faults).
-
- Support userspace controlled GPU virtual addresses. Needed for Vulkan.
(Tomeu)
- Support for madvise and a shrinker.
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index 7ebd82d8d570..a7126b5f8e5d 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -50,7 +50,12 @@ static int panfrost_ioctl_create_bo(struct drm_device *dev,
void *data,
struct drm_panfrost_create_bo *args = data;
if (!args->size || args->pad ||
- (args->flags & ~PANFROST_BO_NOEXEC))
+ (args->flags & ~(PANFROST_BO_NOEXEC | PANFROST_BO_HEAP)))
+ return -EINVAL;
+
+ /* Heaps should never be executable */
+ if ((args->flags & PANFROST_BO_HEAP) &&
+ !(args->flags & PANFROST_BO_NOEXEC))
return -EINVAL;
bo = panfrost_gem_create_with_handle(file, dev, args->size, args->flags,
@@ -265,6 +270,10 @@ static int panfrost_ioctl_mmap_bo(struct drm_device *dev,
void *data,
return -ENOENT;
}
+ /* Don't allow mmapping of heap objects as pages are not pinned. */
+ if (to_panfrost_bo(gem_obj)->is_heap)
+ return -EINVAL;
+
ret = drm_gem_create_mmap_offset(gem_obj);
if (ret == 0)
args->offset = drm_vma_node_offset_addr(_obj->vma_node);
diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.c
b/drivers/gpu/drm/panfrost/panfrost_gem.c
index 63731f6c5223..f3d5f61714ae 100644
--- a/drivers/gpu/drm/panfrost/panfrost_gem.c
+++ b/drivers/gpu/drm/panfrost/panfrost_gem.c
@@ -27,13 +27,35 @@ static void panfrost_gem_free_object(struct drm_gem_object
*obj)
drm_mm_remove_node(>node);
spin_unlock(>mm_lock);
+ if (bo->sgts) {
+ int i;
+ int n_sgt = bo->base.base.size / SZ_2M;
+
+ for (i = 0; i < n_sgt; i++) {
+ if (bo->sgts[i].sgl) {
+ dma_unmap_sg(pfdev->dev, bo->sgts[i].sgl,
+bo->sgts[i].nents,
DMA_BIDIRECTIONAL);
+ sg_free_table(>sgts[i]);
+ }
+ }
+ kfree(bo->sgts);
+ }
+
drm_gem_shmem_free_object(obj);
}
+static int panfrost_gem_pin(struct drm_gem_object *obj)
+{
+ if (to_panfrost_bo(obj)->is_heap)
+ return -EINVAL;
+
+ return drm_gem_shmem_pin(obj);
+}
+
static const struct drm_gem_object_funcs panfrost_gem_funcs = {
.free = panfrost_gem_free_object,
.print_info = drm_gem_shmem_print_info,
- .pin = drm_gem_shmem_pin,
+ .pin = panfrost_gem_pin,
.unpin = drm_gem_shmem_unpin,
.get_sg_table = drm_gem_shmem_get_sg_table,
.vmap = drm_gem_shmem_vmap,
@@ -87,7 +109,10 @@ static int panfrost_gem_map(struct panfrost_device *pfdev,
struct panfrost_gem_o
if (ret)
return ret;
- return panfrost_mmu_map(bo);
+ if (!bo->is_heap)
+ ret = panfrost_mmu_map(bo);
+
+ return ret;
}
struct panfrost_gem_object *
@@ -101,7 +126,11 @@ panfrost_gem_create_with_handle(struct drm_file *file_priv,
struct drm_gem_shmem_object *shmem;
struct panfrost_gem_object *bo;
- size = roundup(size, PAGE_SIZE);
+ /* Round up heap allocations to 2MB to keep
[PATCH v3 6/8] drm/panfrost: Convert MMU IRQ handler to threaded handler
In preparation to handle mapping of page faults, we need the MMU handler
to be threaded as code paths take a mutex.
As the IRQ may be shared, we can't use the default handler and must
disable the MMU interrupts locally.
Cc: Tomeu Vizoso
Cc: Boris Brezillon
Cc: Robin Murphy
Cc: Steven Price
Cc: Alyssa Rosenzweig
Signed-off-by: Rob Herring
---
drivers/gpu/drm/panfrost/panfrost_mmu.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c
b/drivers/gpu/drm/panfrost/panfrost_mmu.c
index eba6ce785ef0..7d44328b280f 100644
--- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
@@ -300,12 +300,20 @@ static const char *access_type_name(struct
panfrost_device *pfdev,
static irqreturn_t panfrost_mmu_irq_handler(int irq, void *data)
{
struct panfrost_device *pfdev = data;
- u32 status = mmu_read(pfdev, MMU_INT_STAT);
- int i;
- if (!status)
+ if (!mmu_read(pfdev, MMU_INT_STAT))
return IRQ_NONE;
+ mmu_write(pfdev, MMU_INT_MASK, 0);
+ return IRQ_WAKE_THREAD;
+}
+
+static irqreturn_t panfrost_mmu_irq_handler_thread(int irq, void *data)
+{
+ struct panfrost_device *pfdev = data;
+ u32 status = mmu_read(pfdev, MMU_INT_RAWSTAT);
+ int i;
+
dev_err(pfdev->dev, "mmu irq status=%x\n", status);
for (i = 0; status; i++) {
@@ -350,6 +358,7 @@ static irqreturn_t panfrost_mmu_irq_handler(int irq, void
*data)
status &= ~mask;
}
+ mmu_write(pfdev, MMU_INT_MASK, ~0);
return IRQ_HANDLED;
};
@@ -368,8 +377,9 @@ int panfrost_mmu_init(struct panfrost_device *pfdev)
if (irq <= 0)
return -ENODEV;
- err = devm_request_irq(pfdev->dev, irq, panfrost_mmu_irq_handler,
- IRQF_SHARED, "mmu", pfdev);
+ err = devm_request_threaded_irq(pfdev->dev, irq,
panfrost_mmu_irq_handler,
+ panfrost_mmu_irq_handler_thread,
+ IRQF_SHARED, "mmu", pfdev);
if (err) {
dev_err(pfdev->dev, "failed to request mmu irq");
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/8] drm/panfrost: Add heap and no execute buffer allocation
This series adds new BO allocation flags PANFROST_BO_HEAP and PANFROST_BO_NOEXEC. The heap allocations are paged in on GPU page faults. Tomeu reports he has tested this in the panfrost CI. This is based on drm-misc-next. An updated branch is here[1]. v3: - Retain shared irq support, splitting IRQ changes to separate patch (6/8) - Stop leaking SG tables - Prevent mmap and pinning pages for heap BOs Rob [1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git panfrost/heap-noexec Rob Herring (8): drm/gem: Allow sparsely populated page arrays in drm_gem_put_pages drm/shmem: Put pages independent of a SG table being set drm/panfrost: Restructure the GEM object creation drm/panfrost: Split panfrost_mmu_map SG list mapping to its own function drm/panfrost: Add a no execute flag for BO allocations drm/panfrost: Convert MMU IRQ handler to threaded handler drm/panfrost: Add support for GPU heap allocations drm/panfrost: Bump driver version to 1.1 drivers/gpu/drm/drm_gem.c | 3 + drivers/gpu/drm/drm_gem_shmem_helper.c | 4 +- drivers/gpu/drm/panfrost/TODO | 2 - drivers/gpu/drm/panfrost/panfrost_drv.c | 65 ++-- drivers/gpu/drm/panfrost/panfrost_gem.c | 106 +++-- drivers/gpu/drm/panfrost/panfrost_gem.h | 16 +- drivers/gpu/drm/panfrost/panfrost_mmu.c | 200 include/uapi/drm/panfrost_drm.h | 3 + 8 files changed, 333 insertions(+), 66 deletions(-) -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/8] drm/panfrost: Restructure the GEM object creation
Setting the GPU VA when creating the GEM object doesn't allow for any
conditional adjustments. In preparation to support adjusting the
mapping, restructure the GEM object creation to map the GEM object after
we've created the base shmem object.
Cc: Tomeu Vizoso
Cc: Boris Brezillon
Cc: Robin Murphy
Reviewed-by: Steven Price
Acked-by: Alyssa Rosenzweig
Signed-off-by: Rob Herring
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 21 +++--
drivers/gpu/drm/panfrost/panfrost_gem.c | 58 -
drivers/gpu/drm/panfrost/panfrost_gem.h | 5 +++
3 files changed, 59 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index cb43ff4ebf4a..d354b92964d5 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -46,29 +46,20 @@ static int panfrost_ioctl_get_param(struct drm_device
*ddev, void *data, struct
static int panfrost_ioctl_create_bo(struct drm_device *dev, void *data,
struct drm_file *file)
{
- int ret;
- struct drm_gem_shmem_object *shmem;
+ struct panfrost_gem_object *bo;
struct drm_panfrost_create_bo *args = data;
if (!args->size || args->flags || args->pad)
return -EINVAL;
- shmem = drm_gem_shmem_create_with_handle(file, dev, args->size,
->handle);
- if (IS_ERR(shmem))
- return PTR_ERR(shmem);
-
- ret = panfrost_mmu_map(to_panfrost_bo(>base));
- if (ret)
- goto err_free;
+ bo = panfrost_gem_create_with_handle(file, dev, args->size, args->flags,
+>handle);
+ if (IS_ERR(bo))
+ return PTR_ERR(bo);
- args->offset = to_panfrost_bo(>base)->node.start << PAGE_SHIFT;
+ args->offset = bo->node.start << PAGE_SHIFT;
return 0;
-
-err_free:
- drm_gem_handle_delete(file, args->handle);
- return ret;
}
/**
diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.c
b/drivers/gpu/drm/panfrost/panfrost_gem.c
index 543ab1b81bd5..df70dcf3cb2f 100644
--- a/drivers/gpu/drm/panfrost/panfrost_gem.c
+++ b/drivers/gpu/drm/panfrost/panfrost_gem.c
@@ -23,7 +23,8 @@ static void panfrost_gem_free_object(struct drm_gem_object
*obj)
panfrost_mmu_unmap(bo);
spin_lock(>mm_lock);
- drm_mm_remove_node(>node);
+ if (drm_mm_node_allocated(>node))
+ drm_mm_remove_node(>node);
spin_unlock(>mm_lock);
drm_gem_shmem_free_object(obj);
@@ -50,10 +51,7 @@ static const struct drm_gem_object_funcs panfrost_gem_funcs
= {
*/
struct drm_gem_object *panfrost_gem_create_object(struct drm_device *dev,
size_t size)
{
- int ret;
- struct panfrost_device *pfdev = dev->dev_private;
struct panfrost_gem_object *obj;
- u64 align;
obj = kzalloc(sizeof(*obj), GFP_KERNEL);
if (!obj)
@@ -61,20 +59,52 @@ struct drm_gem_object *panfrost_gem_create_object(struct
drm_device *dev, size_t
obj->base.base.funcs = _gem_funcs;
- size = roundup(size, PAGE_SIZE);
- align = size >= SZ_2M ? SZ_2M >> PAGE_SHIFT : 0;
+ return >base.base;
+}
+
+static int panfrost_gem_map(struct panfrost_device *pfdev, struct
panfrost_gem_object *bo)
+{
+ int ret;
+ size_t size = bo->base.base.size;
+ u64 align = size >= SZ_2M ? SZ_2M >> PAGE_SHIFT : 0;
spin_lock(>mm_lock);
- ret = drm_mm_insert_node_generic(>mm, >node,
+ ret = drm_mm_insert_node_generic(>mm, >node,
size >> PAGE_SHIFT, align, 0, 0);
spin_unlock(>mm_lock);
+ if (ret)
+ return ret;
+
+ return panfrost_mmu_map(bo);
+}
+
+struct panfrost_gem_object *
+panfrost_gem_create_with_handle(struct drm_file *file_priv,
+struct drm_device *dev, size_t size,
+u32 flags,
+uint32_t *handle)
+{
+ int ret;
+ struct panfrost_device *pfdev = dev->dev_private;
+ struct drm_gem_shmem_object *shmem;
+ struct panfrost_gem_object *bo;
+
+ size = roundup(size, PAGE_SIZE);
+
+ shmem = drm_gem_shmem_create_with_handle(file_priv, dev, size, handle);
+ if (IS_ERR(shmem))
+ return ERR_CAST(shmem);
+
+ bo = to_panfrost_bo(>base);
+
+ ret = panfrost_gem_map(pfdev, bo);
if (ret)
goto free_obj;
- return >base.base;
+ return bo;
free_obj:
- kfree(obj);
+ drm_gem_handle_delete(file_priv, *handle);
return ERR_PTR(ret);
}
@@ -83,8 +113,10 @@ panfrost_gem_prime_import_sg_table(struct drm_device *dev,
struct dma_buf_attachment *attach,
struct sg_table *sgt)
{
+ int ret;
struct drm_gem_object
[PATCH v3 1/8] drm/gem: Allow sparsely populated page arrays in drm_gem_put_pages
Panfrost has a need for pages allocated on demand via GPU page faults.
When releasing the pages, the only thing preventing using
drm_gem_put_pages() is needing to skip over unpopulated pages, so allow
for skipping over NULL struct page pointers.
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Steven Price
Acked-by: Alyssa Rosenzweig
Signed-off-by: Rob Herring
---
drivers/gpu/drm/drm_gem.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 243f43d70f42..db373c945f16 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -633,6 +633,9 @@ void drm_gem_put_pages(struct drm_gem_object *obj, struct
page **pages,
pagevec_init();
for (i = 0; i < npages; i++) {
+ if (!pages[i])
+ continue;
+
if (dirty)
set_page_dirty(pages[i]);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 4/8] drm/panfrost: Split panfrost_mmu_map SG list mapping to its own function
In preparation to create partial GPU mappings of BOs on page faults,
split out the SG list handling of panfrost_mmu_map().
Cc: Tomeu Vizoso
Cc: Boris Brezillon
Cc: Robin Murphy
Cc: Steven Price
Acked-by: Alyssa Rosenzweig
Signed-off-by: Rob Herring
---
drivers/gpu/drm/panfrost/panfrost_mmu.c | 52 +++--
1 file changed, 31 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c
b/drivers/gpu/drm/panfrost/panfrost_mmu.c
index 92ac995dd9c6..b4ac149b2399 100644
--- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
@@ -145,27 +145,13 @@ static size_t get_pgsize(u64 addr, size_t size)
return SZ_2M;
}
-int panfrost_mmu_map(struct panfrost_gem_object *bo)
+static int mmu_map_sg(struct panfrost_device *pfdev, u64 iova,
+ int prot, struct sg_table *sgt)
{
- struct drm_gem_object *obj = >base.base;
- struct panfrost_device *pfdev = to_panfrost_device(obj->dev);
- struct io_pgtable_ops *ops = pfdev->mmu->pgtbl_ops;
- u64 iova = bo->node.start << PAGE_SHIFT;
unsigned int count;
struct scatterlist *sgl;
- struct sg_table *sgt;
- int ret;
-
- if (WARN_ON(bo->is_mapped))
- return 0;
-
- sgt = drm_gem_shmem_get_pages_sgt(obj);
- if (WARN_ON(IS_ERR(sgt)))
- return PTR_ERR(sgt);
-
- ret = pm_runtime_get_sync(pfdev->dev);
- if (ret < 0)
- return ret;
+ struct io_pgtable_ops *ops = pfdev->mmu->pgtbl_ops;
+ u64 start_iova = iova;
mutex_lock(>mmu->lock);
@@ -178,18 +164,42 @@ int panfrost_mmu_map(struct panfrost_gem_object *bo)
while (len) {
size_t pgsize = get_pgsize(iova | paddr, len);
- ops->map(ops, iova, paddr, pgsize, IOMMU_WRITE |
IOMMU_READ);
+ ops->map(ops, iova, paddr, pgsize, prot);
iova += pgsize;
paddr += pgsize;
len -= pgsize;
}
}
- mmu_hw_do_operation(pfdev, 0, bo->node.start << PAGE_SHIFT,
- bo->node.size << PAGE_SHIFT, AS_COMMAND_FLUSH_PT);
+ mmu_hw_do_operation(pfdev, 0, start_iova, iova - start_iova,
+ AS_COMMAND_FLUSH_PT);
mutex_unlock(>mmu->lock);
+ return 0;
+}
+
+int panfrost_mmu_map(struct panfrost_gem_object *bo)
+{
+ struct drm_gem_object *obj = >base.base;
+ struct panfrost_device *pfdev = to_panfrost_device(obj->dev);
+ struct sg_table *sgt;
+ int ret;
+ int prot = IOMMU_READ | IOMMU_WRITE;
+
+ if (WARN_ON(bo->is_mapped))
+ return 0;
+
+ sgt = drm_gem_shmem_get_pages_sgt(obj);
+ if (WARN_ON(IS_ERR(sgt)))
+ return PTR_ERR(sgt);
+
+ ret = pm_runtime_get_sync(pfdev->dev);
+ if (ret < 0)
+ return ret;
+
+ mmu_map_sg(pfdev, bo->node.start << PAGE_SHIFT, prot, sgt);
+
pm_runtime_mark_last_busy(pfdev->dev);
pm_runtime_put_autosuspend(pfdev->dev);
bo->is_mapped = true;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/8] drm/shmem: Put pages independent of a SG table being set
If a driver does its own management of pages, the shmem helper object's
pages array could be allocated when a SG table is not. There's not
really any good reason to tie putting pages with having a SG table when
freeing the object, so just put pages if the pages array is populated.
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
Cc: Eric Anholt
Reviewed-by: Steven Price
Acked-by: Alyssa Rosenzweig
Signed-off-by: Rob Herring
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index 2f64667ac805..477e4cc50f7a 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -118,11 +118,11 @@ void drm_gem_shmem_free_object(struct drm_gem_object *obj)
if (shmem->sgt) {
dma_unmap_sg(obj->dev->dev, shmem->sgt->sgl,
shmem->sgt->nents, DMA_BIDIRECTIONAL);
-
- drm_gem_shmem_put_pages(shmem);
sg_free_table(shmem->sgt);
kfree(shmem->sgt);
}
+ if (shmem->pages)
+ drm_gem_shmem_put_pages(shmem);
}
WARN_ON(shmem->pages_use_count);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/rockchip: Suspend DP late
On Fri, Aug 02, 2019 at 11:46:16AM -0700, Douglas Anderson wrote:
> In commit fe64ba5c6323 ("drm/rockchip: Resume DP early") we moved
> resume to be early but left suspend at its normal time. This seems
> like it could be OK, but casues problems if a suspend gets interrupted
> partway through. The OS only balances matching suspend/resume levels.
> ...so if suspend was called then resume will be called. If suspend
> late was called then resume early will be called. ...but if suspend
> was called resume early might not get called. This leads to an
> unbalance in the clock enables / disables.
>
> Lets take the simple fix and just move suspend to be late to match.
> This makes the PM core take proper care in keeping things balanced.
>
> Fixes: fe64ba5c6323 ("drm/rockchip: Resume DP early")
> Signed-off-by: Douglas Anderson
Reviewed-by: Sean Paul
This should go in -misc-fixes and due to some... administrative reasons... I
will leave it on the list until Maarten has a chance to ff to -rc4 on Monday.
I'll apply it then so as to not require a backmerge.
Sean
> ---
>
> drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> index 7d7cb57410fc..f38f5e113c6b 100644
> --- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> @@ -436,7 +436,7 @@ static int rockchip_dp_resume(struct device *dev)
>
> static const struct dev_pm_ops rockchip_dp_pm_ops = {
> #ifdef CONFIG_PM_SLEEP
> - .suspend = rockchip_dp_suspend,
> + .suspend_late = rockchip_dp_suspend,
> .resume_early = rockchip_dp_resume,
> #endif
> };
> --
> 2.22.0.770.g0f2c4a37fd-goog
>
--
Sean Paul, Software Engineer, Google / Chromium OS
[PATCH] video: fbdev: omapfb_main: Mark expected switch fall-throughs
Mark switch cases where we are expecting to fall through. This patch fixes the following warning (Building: omap1_defconfig arm): drivers/video/fbdev/omap/omapfb_main.c:449:23: warning: this statement may fall through [-Wimplicit-fallthrough=] drivers/video/fbdev/omap/omapfb_main.c:1549:6: warning: this statement may fall through [-Wimplicit-fallthrough=] drivers/video/fbdev/omap/omapfb_main.c:1547:3: warning: this statement may fall through [-Wimplicit-fallthrough=] drivers/video/fbdev/omap/omapfb_main.c:1545:3: warning: this statement may fall through [-Wimplicit-fallthrough=] drivers/video/fbdev/omap/omapfb_main.c:1543:3: warning: this statement may fall through [-Wimplicit-fallthrough=] drivers/video/fbdev/omap/omapfb_main.c:1540:6: warning: this statement may fall through [-Wimplicit-fallthrough=] drivers/video/fbdev/omap/omapfb_main.c:1538:3: warning: this statement may fall through [-Wimplicit-fallthrough=] drivers/video/fbdev/omap/omapfb_main.c:1535:3: warning: this statement may fall through [-Wimplicit-fallthrough=] Signed-off-by: Gustavo A. R. Silva --- drivers/video/fbdev/omap/omapfb_main.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/video/fbdev/omap/omapfb_main.c b/drivers/video/fbdev/omap/omapfb_main.c index 90eca64e3144..702cca59bda1 100644 --- a/drivers/video/fbdev/omap/omapfb_main.c +++ b/drivers/video/fbdev/omap/omapfb_main.c @@ -447,6 +447,7 @@ static int set_color_mode(struct omapfb_plane_struct *plane, return 0; case 12: var->bits_per_pixel = 16; + /* fall through */ case 16: if (plane->fbdev->panel->bpp == 12) plane->color_mode = OMAPFB_COLOR_RGB444; @@ -1534,20 +1535,27 @@ static void omapfb_free_resources(struct omapfb_device *fbdev, int state) case OMAPFB_ACTIVE: for (i = 0; i < fbdev->mem_desc.region_cnt; i++) unregister_framebuffer(fbdev->fb_info[i]); + /* fall through */ case 7: omapfb_unregister_sysfs(fbdev); + /* fall through */ case 6: if (fbdev->panel->disable) fbdev->panel->disable(fbdev->panel); + /* fall through */ case 5: omapfb_set_update_mode(fbdev, OMAPFB_UPDATE_DISABLED); + /* fall through */ case 4: planes_cleanup(fbdev); + /* fall through */ case 3: ctrl_cleanup(fbdev); + /* fall through */ case 2: if (fbdev->panel->cleanup) fbdev->panel->cleanup(fbdev->panel); + /* fall through */ case 1: dev_set_drvdata(fbdev->dev, NULL); kfree(fbdev); -- 2.22.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 204391] Overdrive on AMDGPU does not allow clocks above official clocks.
https://bugzilla.kernel.org/show_bug.cgi?id=204391 --- Comment #2 from Haxk20 (haxk...@gmail.com) --- Can somebody look at this please ? I know this isnt experience breaking but when the driver has support for overclocking then it should at least work. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-fixes for -rc3, part 2
Hi Linus, Dave sends his pull, everyone realizes they've been asleep at the wheel and hits send on their own pulls :-/ Normally I'd just ignore these all because w/e for me and Dave. But this time around the latecomers also included drm-intel-fixes, which failed to send out a -fixes pull thus far for this release (screwed up vacation coverage, despite that 2/3 maintainers were around ... they all look appropriately guilty), and that really is overdue to get landed. And since I had to do a pull request anyway I pulled the other two late ones too. Cheers, Daniel drm-fixes-2019-08-02-1: drm-fixes for 5.3-rc3, take 2 intel fixes (didn't have any ever since the main merge window pull): - gvt fixes (2 cc: stable) - fix gpu reset vs mm-shrinker vs wakeup fun (needed a few patches) - two gem locking fixes (one cc: stable) - pile of misc fixes all over with minor impact, 6 cc: stable, others from this window exynos: - misc minor fixes misc: - some build/Kconfig fixes - regression fix for vm scalability perf test which seems to mostly exercise dmesg/console logging ... - the vgem cache flush fix for arm64 broke the world on x86, so that's reverted again Cheers, Daniel The following changes since commit f8981e0309e9004c6e86d218049045700c79d740: Merge tag 'msm-fixes-2019_08_01' of https://gitlab.freedesktop.org/drm/msm into drm-fixes (2019-08-02 10:17:25 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-08-02-1 for you to fetch changes up to 9c8c9c7cdb4c8fb48a2bc70f41a07920f761d2cd: Merge tag 'exynos-drm-fixes-for-v5.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-fixes (2019-08-02 17:10:17 +0200) drm-fixes for 5.3-rc3, take 2 intel fixes (didn't have any ever since the main merge window pull): - gvt fixes (2 cc: stable) - fix gpu reset vs mm-shrinker vs wakeup fun (needed a few patches) - two gem locking fixes (one cc: stable) - pile of misc fixes all over with minor impact, 6 cc: stable, others from this window exynos: - misc minor fixes misc: - some build/Kconfig fixes - regression fix for vm scalability perf test which seems to mostly exercise dmesg/console logging ... - the vgem cache flush fix for arm64 broke the world on x86, so that's reverted again Arnd Bergmann (1): drm/exynos: add CONFIG_MMU dependency Chris Wilson (9): drm/i915: Keep rings pinned while the context is active drm/i915/gtt: Defer the free for alloc error paths drm/i915/gtt: Mark the freed page table entries with scratch drm/i915/userptr: Acquire the page lock around set_page_dirty() drm/i915: Lock the engine while dumping the active request drm/i915: Lift intel_engines_resume() to callers drm/i915: Add a wakeref getter for iff the wakeref is already active drm/i915: Only recover active engines Revert "drm/vgem: fix cache synchronization on arm/arm64" Colin Ian King (2): drm/exynos: remove redundant assignment to pointer 'node' drm/exynos: fix missing decrement of retry counter Colin Xu (1): drm/i915/gvt: Adding ppgtt to GVT GEM context after shadow pdps settled. Daniel Vetter (3): Merge tag 'drm-intel-fixes-2019-08-02' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes Merge tag 'drm-misc-fixes-2019-08-02' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Merge tag 'exynos-drm-fixes-for-v5.3-rc3' of git://git.kernel.org/.../daeinki/drm-exynos into drm-fixes Dhinakaran Pandiyan (1): drm/i915/vbt: Fix VBT parsing for the PSR section Fuqian Huang (1): drm/exynos: using dev_get_drvdata directly Imre Deak (1): drm/i915: Fix the TBT AUX power well enabling Jani Nikula (1): Merge tag 'gvt-fixes-2019-07-30' of https://github.com/intel/gvt-linux into drm-intel-fixes Kenneth Graunke (1): drm/i915: Disable SAMPLER_STATE prefetching on all Gen11 steppings. Lionel Landwerlin (6): drm/i915/perf: fix ICL perf register offsets drm/i915: fix whitelist selftests with readonly registers drm/i915: whitelist PS_(DEPTH|INVOCATION)_COUNT drm/i915/icl: whitelist PS_(DEPTH|INVOCATION)_COUNT drm/i915/perf: ensure we keep a reference on the driver drm/i915/perf: add missing delay for OA muxes configuration Maarten Lankhorst (1): Merge tag 'v5.3-rc2' into drm-misc-fixes Mika Kuoppala (1): drm/i915: Fix memleak in runtime wakeref tracking Rob Clark (1): drm/vgem: fix cache synchronization on arm/arm64 Thomas Gleixner (1): drm/i810: Use CONFIG_PREEMPTION Thomas Zimmermann (4): drm/client: Support unmapping of DRM client buffers drm/fb-helper: Map DRM client buffer only when required drm/fb-helper: Instanciate shadow FB if configured in device's mode_config drm/bochs:
[PATCH] drm/rockchip: Suspend DP late
In commit fe64ba5c6323 ("drm/rockchip: Resume DP early") we moved
resume to be early but left suspend at its normal time. This seems
like it could be OK, but casues problems if a suspend gets interrupted
partway through. The OS only balances matching suspend/resume levels.
...so if suspend was called then resume will be called. If suspend
late was called then resume early will be called. ...but if suspend
was called resume early might not get called. This leads to an
unbalance in the clock enables / disables.
Lets take the simple fix and just move suspend to be late to match.
This makes the PM core take proper care in keeping things balanced.
Fixes: fe64ba5c6323 ("drm/rockchip: Resume DP early")
Signed-off-by: Douglas Anderson
---
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 7d7cb57410fc..f38f5e113c6b 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -436,7 +436,7 @@ static int rockchip_dp_resume(struct device *dev)
static const struct dev_pm_ops rockchip_dp_pm_ops = {
#ifdef CONFIG_PM_SLEEP
- .suspend = rockchip_dp_suspend,
+ .suspend_late = rockchip_dp_suspend,
.resume_early = rockchip_dp_resume,
#endif
};
--
2.22.0.770.g0f2c4a37fd-goog
Re: [PATCH v2 2/8] drm/etnaviv: split out cmdbuf mapping into address space
Hi,
On Fri, Jul 05, 2019 at 07:17:21PM +0200, Lucas Stach wrote:
> This allows to decouple the cmdbuf suballocator create and mapping
> the region into the GPU address space. Allowing multiple AS to share
> a single cmdbuf suballoc.
>
> Signed-off-by: Lucas Stach
> ---
> drivers/gpu/drm/etnaviv/etnaviv_buffer.c | 23
> drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c | 35 ++--
> drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.h | 11 +++-
> drivers/gpu/drm/etnaviv/etnaviv_dump.c | 6 +-
> drivers/gpu/drm/etnaviv/etnaviv_gpu.c| 19 +--
> drivers/gpu/drm/etnaviv/etnaviv_gpu.h| 3 +-
> drivers/gpu/drm/etnaviv/etnaviv_mmu.c| 70 +++-
> drivers/gpu/drm/etnaviv/etnaviv_mmu.h| 12 ++--
> 8 files changed, 114 insertions(+), 65 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
> b/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
> index fe0d2d67007d..6400a88cd778 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
> @@ -118,7 +118,8 @@ static void etnaviv_buffer_dump(struct etnaviv_gpu *gpu,
> u32 *ptr = buf->vaddr + off;
>
> dev_info(gpu->dev, "virt %p phys 0x%08x free 0x%08x\n",
> - ptr, etnaviv_cmdbuf_get_va(buf) + off, size - len * 4 -
> off);
> + ptr, etnaviv_cmdbuf_get_va(buf, >cmdbuf_mapping) +
> + off, size - len * 4 - off);
>
> print_hex_dump(KERN_INFO, "cmd ", DUMP_PREFIX_OFFSET, 16, 4,
> ptr, len * 4, 0);
> @@ -151,7 +152,8 @@ static u32 etnaviv_buffer_reserve(struct etnaviv_gpu *gpu,
> if (buffer->user_size + cmd_dwords * sizeof(u64) > buffer->size)
> buffer->user_size = 0;
>
> - return etnaviv_cmdbuf_get_va(buffer) + buffer->user_size;
> + return etnaviv_cmdbuf_get_va(buffer, >cmdbuf_mapping) +
> +buffer->user_size;
> }
>
> u16 etnaviv_buffer_init(struct etnaviv_gpu *gpu)
> @@ -164,8 +166,8 @@ u16 etnaviv_buffer_init(struct etnaviv_gpu *gpu)
> buffer->user_size = 0;
>
> CMD_WAIT(buffer);
> - CMD_LINK(buffer, 2, etnaviv_cmdbuf_get_va(buffer) +
> - buffer->user_size - 4);
> + CMD_LINK(buffer, 2, etnaviv_cmdbuf_get_va(buffer, >cmdbuf_mapping)
> + + buffer->user_size - 4);
>
> return buffer->user_size / 8;
> }
> @@ -291,8 +293,8 @@ void etnaviv_sync_point_queue(struct etnaviv_gpu *gpu,
> unsigned int event)
>
> /* Append waitlink */
> CMD_WAIT(buffer);
> - CMD_LINK(buffer, 2, etnaviv_cmdbuf_get_va(buffer) +
> - buffer->user_size - 4);
> + CMD_LINK(buffer, 2, etnaviv_cmdbuf_get_va(buffer, >cmdbuf_mapping)
> + + buffer->user_size - 4);
>
> /*
>* Kick off the 'sync point' command by replacing the previous
> @@ -319,7 +321,7 @@ void etnaviv_buffer_queue(struct etnaviv_gpu *gpu, u32
> exec_state,
> if (drm_debug & DRM_UT_DRIVER)
> etnaviv_buffer_dump(gpu, buffer, 0, 0x50);
>
> - link_target = etnaviv_cmdbuf_get_va(cmdbuf);
> + link_target = etnaviv_cmdbuf_get_va(cmdbuf, >cmdbuf_mapping);
> link_dwords = cmdbuf->size / 8;
>
> /*
> @@ -412,12 +414,13 @@ void etnaviv_buffer_queue(struct etnaviv_gpu *gpu, u32
> exec_state,
> CMD_LOAD_STATE(buffer, VIVS_GL_EVENT, VIVS_GL_EVENT_EVENT_ID(event) |
> VIVS_GL_EVENT_FROM_PE);
> CMD_WAIT(buffer);
> - CMD_LINK(buffer, 2, etnaviv_cmdbuf_get_va(buffer) +
> - buffer->user_size - 4);
> + CMD_LINK(buffer, 2, etnaviv_cmdbuf_get_va(buffer, >cmdbuf_mapping)
> + + buffer->user_size - 4);
>
> if (drm_debug & DRM_UT_DRIVER)
> pr_info("stream link to 0x%08x @ 0x%08x %p\n",
> - return_target, etnaviv_cmdbuf_get_va(cmdbuf),
> + return_target,
> + etnaviv_cmdbuf_get_va(cmdbuf, >cmdbuf_mapping),
> cmdbuf->vaddr);
>
> if (drm_debug & DRM_UT_DRIVER) {
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c
> b/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c
> index 7b77992f31c4..8915d9d056a6 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c
> @@ -8,6 +8,7 @@
> #include
>
> #include "etnaviv_cmdbuf.h"
> +#include "etnaviv_gem.h"
> #include "etnaviv_gpu.h"
> #include "etnaviv_mmu.h"
>
> @@ -21,10 +22,6 @@ struct etnaviv_cmdbuf_suballoc {
> void *vaddr;
> dma_addr_t paddr;
>
> - /* GPU mapping */
> - u32 iova;
> - struct drm_mm_node vram_node; /* only used on MMUv2 */
> -
> /* allocation management */
> struct mutex lock;
> DECLARE_BITMAP(granule_map, SUBALLOC_GRANULES);
> @@ -53,26 +50,31 @@ etnaviv_cmdbuf_suballoc_new(struct etnaviv_gpu * gpu)
> goto free_suballoc;
> }
>
> - ret = etnaviv_iommu_get_suballoc_va(gpu, suballoc->paddr,
> -
[Bug 111021] [kernel 5.2.1][amdgpu][CIK] BUG: KASAN: null-ptr-deref in amdgpu_ib_schedule+0x82/0x790 [amdgpu]
https://bugs.freedesktop.org/show_bug.cgi?id=111021 --- Comment #7 from erhar...@mailbox.org --- Created attachment 144933 --> https://bugs.freedesktop.org/attachment.cgi?id=144933=edit kernel dmesg (5.3-rc2) [...] [ 214.315038] cp queue preemption time out [ 214.315406] Resetting wave fronts (nocpsch) on dev c3d0b577 [ 214.316011] == [ 214.316631] BUG: KASAN: null-ptr-deref in amdgpu_ib_schedule+0x7c/0x7f0 [amdgpu] [ 214.316664] Read of size 8 at addr 0038 by task xmr-stak/1130 [ 214.316724] CPU: 5 PID: 1130 Comm: xmr-stak Not tainted 5.3.0-rc2 #1 [ 214.316754] Hardware name: System manufacturer System Product Name/M5A78L-M LX3, BIOS 140105/05/2016 [ 214.316783] Call Trace: [ 214.316818] dump_stack+0x7c/0xc0 [ 214.317258] ? amdgpu_ib_schedule+0x7c/0x7f0 [amdgpu] [ 214.317696] ? amdgpu_ib_schedule+0x7c/0x7f0 [amdgpu] [ 214.317730] __kasan_report.cold.6+0x5/0x3c [ 214.318168] ? amdgpu_ib_schedule+0x7c/0x7f0 [amdgpu] [ 214.318606] amdgpu_ib_schedule+0x7c/0x7f0 [amdgpu] [ 214.318640] ? kasan_unpoison_shadow+0x30/0x40 [ 214.318672] ? __kasan_kmalloc.constprop.7+0xc1/0xd0 [ 214.319110] ? amdgpu_sync_create+0x32/0x50 [amdgpu] [ 214.319568] amdgpu_amdkfd_submit_ib+0x13c/0x230 [amdgpu] [ 214.320026] ? amdgpu_amdkfd_get_num_gws+0x20/0x20 [amdgpu] [ 214.320487] ? dbgdev_wave_control_diq+0x280/0x280 [amdgpu] [ 214.320520] ? wake_up_klogd+0x2b/0x30 [ 214.320550] ? vprintk_emit+0xdc/0x260 [ 214.320581] ? memset+0x1f/0x40 [ 214.321040] deallocate_vmid.isra.12+0x25a/0x270 [amdgpu] [ 214.321503] destroy_queue_nocpsch_locked+0x33d/0x360 [amdgpu] [ 214.321962] ? init_mqd_sdma+0x90/0x90 [amdgpu] [ 214.322424] process_termination_nocpsch+0xb1/0x280 [amdgpu] [ 214.322886] kfd_process_dequeue_from_all_devices+0x79/0xa0 [amdgpu] [ 214.323345] kfd_process_notifier_release+0x1ab/0x250 [amdgpu] [ 214.323382] __mmu_notifier_release+0x9d/0x1c0 [ 214.323414] ? check_chain_key+0x1d7/0x2e0 [ 214.323446] exit_mmap+0x7c/0x280 [ 214.323479] ? __ia32_sys_munmap+0x30/0x30 [ 214.323512] ? aio_poll_wake+0x3c0/0x3c0 [ 214.323543] ? lock_downgrade+0x390/0x390 [ 214.323574] ? up_read+0x12c/0x370 [ 214.323606] ? rwlock_bug.part.2+0x50/0x50 [ 214.323638] mmput+0x99/0x1f0 [ 214.323671] do_exit+0x3cc/0x12e0 [ 214.323703] ? queued_spin_lock_slowpath+0x366/0x420 [ 214.323735] ? check_chain_key+0x1d7/0x2e0 [ 214.323766] ? mm_update_next_owner+0x340/0x340 [ 214.323798] ? lock_downgrade+0x390/0x390 [ 214.323830] ? do_raw_spin_lock+0x10e/0x1d0 [ 214.323861] ? match_held_lock+0x2e/0x240 [ 214.323892] do_group_exit+0x86/0x130 [ 214.323925] get_signal+0x1bc/0xeb0 [ 214.323958] ? refcount_sub_and_test_checked+0xaf/0x150 [ 214.323992] do_signal+0x9e/0xad0 [ 214.324024] ? wake_up_q+0x72/0x90 [ 214.324054] ? rwsem_wake.isra.9+0xb3/0xf0 [ 214.324085] ? rwsem_mark_wake+0x4d0/0x4d0 [ 214.324116] ? setup_sigcontext+0x250/0x250 [ 214.324149] ? __x64_sys_futex+0x1d3/0x240 [ 214.324179] ? down_read_nested+0x2b0/0x2b0 [ 214.324211] ? trace_hardirqs_on_thunk+0x1a/0x20 [ 214.324242] ? mark_held_locks+0x29/0xa0 [ 214.324272] ? exit_to_usermode_loop+0x41/0x130 [ 214.324303] exit_to_usermode_loop+0x59/0x130 [ 214.324334] do_syscall_64+0x1fd/0x250 [ 214.324368] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 214.324398] RIP: 0033:0x7fd134c26f6c [ 214.324433] Code: Bad RIP value. [ 214.324462] RSP: 002b:7fd11b7fdd30 EFLAGS: 0246 ORIG_RAX: 00ca [ 214.324496] RAX: fe00 RBX: 7fd125838c48 RCX: 7fd134c26f6c [ 214.324525] RDX: RSI: 0080 RDI: 7fd125838c74 [ 214.324554] RBP: R08: R09: 7fd108000b20 [ 214.324582] R10: R11: 0246 R12: 0007 [ 214.324611] R13: 7fd125838c20 R14: R15: 7fd125838c74 [ 214.324640] == [ 214.324666] Disabling lock debugging due to kernel taint [ 214.324680] BUG: kernel NULL pointer dereference, address: 0038 [ 214.324691] #PF: supervisor read access in kernel mode [ 214.324700] #PF: error_code(0x) - not-present page [ 214.324708] PGD 0 P4D 0 [ 214.324722] Oops: [#1] SMP KASAN NOPTI [ 214.324736] CPU: 5 PID: 1130 Comm: xmr-stak Tainted: GB 5.3.0-rc2 #1 [ 214.324746] Hardware name: System manufacturer System Product Name/M5A78L-M LX3, BIOS 140105/05/2016 [ 214.325166] RIP: 0010:amdgpu_ib_schedule+0x7c/0x7f0 [amdgpu] [ 214.325180] Code: 00 00 49 8d 7d 70 e8 e3 d0 73 df 49 8b 45 70 49 8d 7d 10 48 89 44 24 38 e8 d1 d0 73 df 49 8b 6d 10 48 8d 7d 38 e8 c4 d0 73 df <48> 8b 45 38 48 89 44 24 20 45 84 e4 0f 84 e8 21 30 00 48 83 7c 24 [ 214.325191] RSP: 0018:888378a9f6b0 EFLAGS: 00010286 [ 214.325204] RAX: RBX: 88837a5884d8 RCX: a0105081 [
[Bug 111021] [kernel 5.2.1][amdgpu][CIK] BUG: KASAN: null-ptr-deref in amdgpu_ib_schedule+0x82/0x790 [amdgpu]
https://bugs.freedesktop.org/show_bug.cgi?id=111021 erhar...@mailbox.org changed: What|Removed |Added Attachment #144833|0 |1 is obsolete|| --- Comment #6 from erhar...@mailbox.org --- Created attachment 144932 --> https://bugs.freedesktop.org/attachment.cgi?id=144932=edit kernel .config (5.3-rc2) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111021] [kernel 5.2.1][amdgpu][CIK] BUG: KASAN: null-ptr-deref in amdgpu_ib_schedule+0x82/0x790 [amdgpu]
https://bugs.freedesktop.org/show_bug.cgi?id=111021 erhar...@mailbox.org changed: What|Removed |Added Attachment #144832|0 |1 is obsolete|| --- Comment #5 from erhar...@mailbox.org --- Created attachment 144931 --> https://bugs.freedesktop.org/attachment.cgi?id=144931=edit kernel dmesg (5.2.5) More detailed debug info with KASAN. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111021] [kernel 5.2.1][amdgpu][CIK] BUG: KASAN: null-ptr-deref in amdgpu_ib_schedule+0x82/0x790 [amdgpu]
https://bugs.freedesktop.org/show_bug.cgi?id=111021 erhar...@mailbox.org changed: What|Removed |Added Summary|[kernel 5.2.1][amdgpu][CIK] |[kernel 5.2.1][amdgpu][CIK] |cp queue preemption time|BUG: KASAN: null-ptr-deref |out, BUG: kernel NULL |in |pointer dereference,|amdgpu_ib_schedule+0x82/0x7 |address: 0038 |90 [amdgpu] -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/8] drm/etnaviv: split out cmdbuf mapping into address space
Hi, On Fri, Aug 02, 2019 at 04:21:53PM +0200, Philipp Zabel wrote: > Hi Guido, > > On Fri, 2019-08-02 at 15:39 +0200, Guido Günther wrote: > > Hi Lucas, > > On Fri, Jul 05, 2019 at 07:17:21PM +0200, Lucas Stach wrote: > > > This allows to decouple the cmdbuf suballocator create and mapping > > > the region into the GPU address space. Allowing multiple AS to share > > > a single cmdbuf suballoc. > > > > Can you tell me where this would apply? I tried 5.2 and next-20190726 > > with and without > > > >[PATCH 1/2] drm/etnaviv: fix etnaviv_cmdbuf_suballoc_new return value > > I have stacked > > drm/etnaviv: drop use of drmP.h > drm/etnaviv: Use > devm_platform_ioremap_resource() > drm/etnaviv: clean up includes > drm/etnaviv: fix > etnaviv_cmdbuf_suballoc_new return value > drm/etnaviv: remove unused function etnaviv_gem_mapping_reference > drm/etnaviv: dump only failing submit > drm/etnaviv: simplify unbind checks > > on top of v5.3-r1 and this patch applied with a bit of fuzz. That worked, thanks! -- Guido > > regards > Philipp > ___ > etnaviv mailing list > etna...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/etnaviv ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111244] amdgpu kernel 5.2 blank display after resume from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=111244 --- Comment #11 from csp...@verizon.net --- @Samuele Yes, after redoing the bisect I got the same result as you did. Thanks. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH AUTOSEL 4.14 11/30] drm/msm: stop abusing dma_map/unmap for cache
On Fri, Aug 2, 2019 at 9:24 AM Sasha Levin wrote:
>
> From: Rob Clark
>
> [ Upstream commit 0036bc73ccbe7e600a3468bf8e8879b122252274 ]
>
Hi Sasha,
FYI, this commit should be paired with
https://cgit.freedesktop.org/drm/drm/commit/?h=drm-fixes=3de433c5b38af49a5fc7602721e2ab5d39f1e69c
Sean
> Recently splats like this started showing up:
>
>WARNING: CPU: 4 PID: 251 at drivers/iommu/dma-iommu.c:451
> __iommu_dma_unmap+0xb8/0xc0
>Modules linked in: ath10k_snoc ath10k_core fuse msm ath mac80211 uvcvideo
> cfg80211 videobuf2_vmalloc videobuf2_memops vide
>CPU: 4 PID: 251 Comm: kworker/u16:4 Tainted: GW
> 5.2.0-rc5-next-20190619+ #2317
>Hardware name: LENOVO 81JL/LNVNB161216, BIOS 9UCN23WW(V1.06) 10/25/2018
>Workqueue: msm msm_gem_free_work [msm]
>pstate: 80c5 (Nzcv daif +PAN +UAO)
>pc : __iommu_dma_unmap+0xb8/0xc0
>lr : __iommu_dma_unmap+0x54/0xc0
>sp : 119abce0
>x29: 119abce0 x28:
>x27: 8001f9946648 x26: 8001ec271068
>x25: x24: 8001ea3580a8
>x23: 8001f95ba010 x22: 80018e83ba88
>x21: 8001e548f000 x20: f000
>x19: 1000 x18: c1fe
>x17: x16:
>x15: 15b70068 x14: 0005
>x13: 0003142cc1be1768 x12: 0001
>x11: 8001f6de9100 x10: 0009
>x9 : 15b78000 x8 :
>x7 : 0001 x6 : f000
>x5 : 0fff x4 : 1065dbc8
>x3 : 000d x2 : 1000
>x1 : f000 x0 :
>Call trace:
> __iommu_dma_unmap+0xb8/0xc0
> iommu_dma_unmap_sg+0x98/0xb8
> put_pages+0x5c/0xf0 [msm]
> msm_gem_free_work+0x10c/0x150 [msm]
> process_one_work+0x1e0/0x330
> worker_thread+0x40/0x438
> kthread+0x12c/0x130
> ret_from_fork+0x10/0x18
>---[ end trace afc0dc5ab81a06bf ]---
>
> Not quite sure what triggered that, but we really shouldn't be abusing
> dma_{map,unmap}_sg() for cache maint.
>
> Cc: Stephen Boyd
> Tested-by: Stephen Boyd
> Reviewed-by: Jordan Crouse
> Signed-off-by: Rob Clark
> Signed-off-by: Sean Paul
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20190630124735.27786-1-robdcl...@gmail.com
> Signed-off-by: Sasha Levin
> ---
> drivers/gpu/drm/msm/msm_gem.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
> index f2df718af370d..3a91ccd92c473 100644
> --- a/drivers/gpu/drm/msm/msm_gem.c
> +++ b/drivers/gpu/drm/msm/msm_gem.c
> @@ -108,7 +108,7 @@ static struct page **get_pages(struct drm_gem_object *obj)
> * because display controller, GPU, etc. are not coherent:
> */
> if (msm_obj->flags & (MSM_BO_WC|MSM_BO_UNCACHED))
> - dma_map_sg(dev->dev, msm_obj->sgt->sgl,
> + dma_sync_sg_for_device(dev->dev, msm_obj->sgt->sgl,
> msm_obj->sgt->nents,
> DMA_BIDIRECTIONAL);
> }
>
> @@ -138,7 +138,7 @@ static void put_pages(struct drm_gem_object *obj)
> * GPU, etc. are not coherent:
> */
> if (msm_obj->flags & (MSM_BO_WC|MSM_BO_UNCACHED))
> - dma_unmap_sg(obj->dev->dev, msm_obj->sgt->sgl,
> + dma_sync_sg_for_cpu(obj->dev->dev,
> msm_obj->sgt->sgl,
> msm_obj->sgt->nents,
> DMA_BIDIRECTIONAL);
>
> --
> 2.20.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] drm/syncobj: remove boring message
On Fri, Aug 2, 2019 at 12:33 PM Koenig, Christian
wrote:
>
>
> Am 02.08.2019 18:28 schrieb Jason Ekstrand :
>
> On Thu, Aug 1, 2019 at 9:05 AM Koenig, Christian
> wrote:
>
> Am 01.08.19 um 15:45 schrieb Lionel Landwerlin:
> > Just had a few exchanges with Chris about this.
> > Chris suggests that if we're about to add a point to the timeline in
> > an unordered fashion, actually better not add it at all.
> >
> > What's your take on this?
>
> That is a clear NAK. See not adding a point at all means we lose some
> synchronization and that is not something we can do here.
>
> In other words syncing to much if userspace does something nasty is ok
> and defensive programmed, but not syncing at all could have unforeseen
> consequences.
>
>
> So if process A signals 7, process B detects that and signals 3 and then
> process A tries to insert something which waits on 7 and signals 8, what
> happens? My understanding is that it "breaks" the timeline and so, from
> the perspective of process A, its signal operation on 7 is gone and it's
> attempt to wait on 7 will either -EINVAL because the kernel can't find the
> time point or else just sit there. Am I understanding this correctly?
>
>
> Nope, what happens is that we note the largest signaled seqno and wait for
> everything without returning an error.
>
> For example if we have signaled 7 and then 3 then any waiting for 7 we
> would wait for both 3 and 7.
>
Ok, that's reasonable behavior. I'm sorry, I'm a bit behind on the
implementation details right now and just had a scarry conversation on
IRC. If what you are describing is accurate, we should be ok. We should
also make sure that we have IGT tests which ensure this. :-)
FYI, at Lionel and Daniel's request, I just sent out a patch which adds
better design docs for the current sync file (assuming people think they're
actually better). We should review and land that and then someone should
extend it for the timeline stuff and ensure that all these behaviors are
well-documented.
--Jason
> If so, it sounds more like an attack vector than defensive programming
> to me.
>
>
> Yeah, completely agree. That's why I also rejected the idea to return an
> error on wait.
>
>
> Yes, more syncornization is generally better than less. However, if
> you're screwing up your syncronization from userspace and getting wrong
> rendering results, that's your fault. If you're causing your compositor to
> suddenly start seeing -EINVAL which gets turned into VK_ERROR_DEVICE_LOST,
> that's a lot worse IMO. I'm not saying that we shouldn't try to be robust
> in this case; I'm just concerned that the suggest solution isn't.
>
>
> Completely agree as well.
>
> The key point is we need to find a balance between keeping things working
> and signaling that something is wrong.
>
> I mean the two options we have is to either ignore such errors and do the
> most defensive thing we can. And the current solution is already pretty
> good at that.
>
> Or we can signal those errors but risk that it can be used for a deny of
> service.
>
> Regards,
> Christian.
>
>
> --Jason
>
>
>
> Another idea would be to add the fence, but also set an error flag and
> deny any further signaling on that syncobj.
>
> Regards,
> Christian.
>
> > I'm fine with this, but rather than add another variant of add_point()
> > maybe we change change the existing.
> >
> > Thanks,
> >
> > -Lionel
> >
> > On 29/07/2019 11:20, Chunming Zhou wrote:
> >> It is normal that binary syncobj replaces the underlying fence.
> >>
> >> Signed-off-by: Chunming Zhou
> >> ---
> >> drivers/gpu/drm/drm_syncobj.c | 3 ---
> >> 1 file changed, 3 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_syncobj.c
> >> b/drivers/gpu/drm/drm_syncobj.c
> >> index 929f7c64f9a2..bc7ec1679e4d 100644
> >> --- a/drivers/gpu/drm/drm_syncobj.c
> >> +++ b/drivers/gpu/drm/drm_syncobj.c
> >> @@ -151,9 +151,6 @@ void drm_syncobj_add_point(struct drm_syncobj
> >> *syncobj,
> >> spin_lock(>lock);
> >> prev = drm_syncobj_fence_get(syncobj);
> >> -/* You are adding an unorder point to timeline, which could
> >> cause payload returned from query_ioctl is 0! */
> >> -if (prev && prev->seqno >= point)
> >> -DRM_ERROR("You are adding an unorder point to timeline!\n");
> >> dma_fence_chain_init(chain, prev, fence, point);
> >> rcu_assign_pointer(syncobj->fence, >base);
> >
> >
>
> ___
> 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
[PATCH] drm/syncobj: Add better overview documentation for syncobj
This patch only brings the syncobj documentation up-to-date for the original form of syncobj. It does not contain any information about the design of timeline syncobjs. --- drivers/gpu/drm/drm_syncobj.c | 81 +++ 1 file changed, 73 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c index 1438dcb3ebb1..03cc888744fb 100644 --- a/drivers/gpu/drm/drm_syncobj.c +++ b/drivers/gpu/drm/drm_syncobj.c @@ -29,17 +29,82 @@ /** * DOC: Overview * - * DRM synchronisation objects (syncobj, see struct _syncobj) are - * persistent objects that contain an optional fence. The fence can be updated - * with a new fence, or be NULL. + * DRM synchronisation objects (syncobj, see struct _syncobj) provide a + * synchronization primitive which can be used by userspace to explicitly + * synchronize GPU commands, can be shared between userspace processes, and + * can be shared between different DRM drivers. + * Their primary use-case is to implement Vulkan fences and semaphores. + * The syncobj userspace API provides ioctls for several operations: * - * syncobj's can be waited upon, where it will wait for the underlying - * fence. + * - Creation and destruction of syncobjs + * - Import and export of syncobjs to/from a syncobj file descriptor + * - Import and export a syncobj's underlying fence to/from a sync file + * - Reset a syncobj (set its fence to NULL) + * - Signal a syncobj (set a trivially signaled fence) + * - Wait a syncobj's fence to be signaled * - * syncobj's can be export to fd's and back, these fd's are opaque and - * have no other use case, except passing the syncobj between processes. + * At it's core, a syncobj simply a wrapper around a pointer to a struct + * _fence which may be NULL. + * When GPU work which signals a syncobj is enqueued in a DRM driver, + * the syncobj fence is replaced with a fence which will be signaled by the + * completion of that work. + * When GPU work which waits on a syncobj is enqueued in a DRM driver, the + * driver retrieves syncobj's current fence at the time the work is enqueued + * waits on that fence before submitting the work to hardware. + * If the syncobj's fence is NULL, the enqueue operation is expected to fail. + * All manipulation of the syncobjs's fence happens in terms of the current + * fence at the time the ioctl is called by userspace regardless of whether + * that operation is an immediate host-side operation (signal or reset) or + * or an operation which is enqueued in some driver queue. * - * Their primary use-case is to implement Vulkan fences and semaphores. + * + * Host-side wait on syncobjs + * -- + * + * The userspace syncobj API provides an ioctl for waiting on a set of + * syncobjs. + * The wait ioctl takes an array of syncobj handles and a flag indicating + * whether it should return immediately once one syncobj has been signaled + * or if it should wait for all the syncobjs to be signaled. + * Unlike the enqueued GPU work dependencies, the host-side wait ioctl + * will also optionally wait for the syncobj to first receive a fence and + * then wait on that fence. + * Assuming the syncobj starts off with a NULL fence, this allows a client + * to do a host wait in one thread (or process) which waits on GPU work + * submitted in another thread (or process) without having to manually + * synchronize between the two. + * This requirement is inherited from the Vulkan fence API. + * + * + * Import/export of syncobjs + * - + * + * The userspace syncobj API provides two mechanisms for import/export of + * syncobjs. + * + * The first lets the client import or export an entire syncobj to a file + * descriptor. + * These fd's are opaque and have no other use case, except passing the + * syncobj between processes. + * All syncobj handles which are created as the result of such an import + * operation refer to the same underlying syncobj as was used for the + * export and the syncobj can be used persistently across all the processes + * with which it is shared. + * Unlike dma-buf, importing a syncobj creates a new handle for every + * import instead of de-duplicating. + * The primary use-case of this persistent import/export is for shared + * Vulkan fences and semaphores. + * + * The second import/export mechanism lets the client export the syncobj's + * current fence to/from a _file. + * When a syncobj is exported to a sync file, that sync file wraps the + * sycnobj's fence at the time of export and any later signal or reset + * operations on the syncobj will not affect the exported sync file. + * When a sync file is imported into a syncobj, the syncobj's fence is set + * to the fence wrapped by that sync file. + * Because sync files are immutable, resetting or signaling the syncobj + * will not affect any sync files whose fences have been imported into the + * syncobj. * * syncobj have a kref reference count, but
Re: [PATCH] drm/syncobj: remove boring message
Am 02.08.2019 18:28 schrieb Jason Ekstrand :
On Thu, Aug 1, 2019 at 9:05 AM Koenig, Christian
mailto:christian.koe...@amd.com>> wrote:
Am 01.08.19 um 15:45 schrieb Lionel Landwerlin:
> Just had a few exchanges with Chris about this.
> Chris suggests that if we're about to add a point to the timeline in
> an unordered fashion, actually better not add it at all.
>
> What's your take on this?
That is a clear NAK. See not adding a point at all means we lose some
synchronization and that is not something we can do here.
In other words syncing to much if userspace does something nasty is ok
and defensive programmed, but not syncing at all could have unforeseen
consequences.
So if process A signals 7, process B detects that and signals 3 and then
process A tries to insert something which waits on 7 and signals 8, what
happens? My understanding is that it "breaks" the timeline and so, from the
perspective of process A, its signal operation on 7 is gone and it's attempt to
wait on 7 will either -EINVAL because the kernel can't find the time point or
else just sit there. Am I understanding this correctly?
Nope, what happens is that we note the largest signaled seqno and wait for
everything without returning an error.
For example if we have signaled 7 and then 3 then any waiting for 7 we would
wait for both 3 and 7.
If so, it sounds more like an attack vector than defensive programming to me.
Yeah, completely agree. That's why I also rejected the idea to return an error
on wait.
Yes, more syncornization is generally better than less. However, if you're
screwing up your syncronization from userspace and getting wrong rendering
results, that's your fault. If you're causing your compositor to suddenly
start seeing -EINVAL which gets turned into VK_ERROR_DEVICE_LOST, that's a lot
worse IMO. I'm not saying that we shouldn't try to be robust in this case; I'm
just concerned that the suggest solution isn't.
Completely agree as well.
The key point is we need to find a balance between keeping things working and
signaling that something is wrong.
I mean the two options we have is to either ignore such errors and do the most
defensive thing we can. And the current solution is already pretty good at that.
Or we can signal those errors but risk that it can be used for a deny of
service.
Regards,
Christian.
--Jason
Another idea would be to add the fence, but also set an error flag and
deny any further signaling on that syncobj.
Regards,
Christian.
> I'm fine with this, but rather than add another variant of add_point()
> maybe we change change the existing.
>
> Thanks,
>
> -Lionel
>
> On 29/07/2019 11:20, Chunming Zhou wrote:
>> It is normal that binary syncobj replaces the underlying fence.
>>
>> Signed-off-by: Chunming Zhou
>> mailto:david1.z...@amd.com>>
>> ---
>> drivers/gpu/drm/drm_syncobj.c | 3 ---
>> 1 file changed, 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_syncobj.c
>> b/drivers/gpu/drm/drm_syncobj.c
>> index 929f7c64f9a2..bc7ec1679e4d 100644
>> --- a/drivers/gpu/drm/drm_syncobj.c
>> +++ b/drivers/gpu/drm/drm_syncobj.c
>> @@ -151,9 +151,6 @@ void drm_syncobj_add_point(struct drm_syncobj
>> *syncobj,
>> spin_lock(>lock);
>> prev = drm_syncobj_fence_get(syncobj);
>> -/* You are adding an unorder point to timeline, which could
>> cause payload returned from query_ioctl is 0! */
>> -if (prev && prev->seqno >= point)
>> -DRM_ERROR("You are adding an unorder point to timeline!\n");
>> dma_fence_chain_init(chain, prev, fence, point);
>> rcu_assign_pointer(syncobj->fence, >base);
>
>
___
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
[PATCH 2/3] drm/etnaviv: allow to request specific virtual address for gem mapping
Allow the mapping code to request a specific virtual address for the gem
mapping. If the virtual address is zero we fall back to the old mode of
allocating a virtual address for the mapping.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_gem.c | 2 +-
drivers/gpu/drm/etnaviv/etnaviv_gem.h | 2 +-
drivers/gpu/drm/etnaviv/etnaviv_mmu.c | 16 ++--
drivers/gpu/drm/etnaviv/etnaviv_mmu.h | 2 +-
4 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
index 74680c0254b6..5dde3e4c3949 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
@@ -308,7 +308,7 @@ struct etnaviv_vram_mapping *etnaviv_gem_mapping_get(
mapping->use = 1;
ret = etnaviv_iommu_map_gem(mmu, etnaviv_obj, mmu->global->memory_base,
- mapping);
+ mapping, 0);
if (ret < 0)
kfree(mapping);
else
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.h
b/drivers/gpu/drm/etnaviv/etnaviv_gem.h
index 175e6128c4bc..92f3090b8348 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.h
@@ -120,7 +120,7 @@ struct page **etnaviv_gem_get_pages(struct
etnaviv_gem_object *obj);
void etnaviv_gem_put_pages(struct etnaviv_gem_object *obj);
struct etnaviv_vram_mapping *etnaviv_gem_mapping_get(
- struct drm_gem_object *obj, struct etnaviv_iommu_context *mmu);
+ struct drm_gem_object *obj, struct etnaviv_iommu_context *mmu, u64 va);
void etnaviv_gem_mapping_unreference(struct etnaviv_vram_mapping *mapping);
#endif /* __ETNAVIV_GEM_H__ */
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
b/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
index 99c20094295c..c344dde2fa05 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
@@ -220,9 +220,16 @@ static int etnaviv_iommu_find_iova(struct
etnaviv_iommu_context *context,
return ret;
}
+static int etnaviv_iommu_insert_exact(struct etnaviv_iommu_context *context,
+ struct drm_mm_node *node, size_t size, u64 va)
+{
+ return drm_mm_insert_node_in_range(>mm, node, size, 0, 0, va,
+ va + size, DRM_MM_INSERT_LOW);
+}
+
int etnaviv_iommu_map_gem(struct etnaviv_iommu_context *context,
struct etnaviv_gem_object *etnaviv_obj, u32 memory_base,
- struct etnaviv_vram_mapping *mapping)
+ struct etnaviv_vram_mapping *mapping, u64 va)
{
struct sg_table *sgt = etnaviv_obj->sgt;
struct drm_mm_node *node;
@@ -248,7 +255,12 @@ int etnaviv_iommu_map_gem(struct etnaviv_iommu_context
*context,
node = >vram_node;
- ret = etnaviv_iommu_find_iova(context, node, etnaviv_obj->base.size);
+ if (va)
+ ret = etnaviv_iommu_insert_exact(context, node,
+etnaviv_obj->base.size, va);
+ else
+ ret = etnaviv_iommu_find_iova(context, node,
+ etnaviv_obj->base.size);
if (ret < 0)
goto unlock;
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_mmu.h
b/drivers/gpu/drm/etnaviv/etnaviv_mmu.h
index 3c219d306eab..e97ce8488286 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_mmu.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_mmu.h
@@ -85,7 +85,7 @@ struct etnaviv_gem_object;
int etnaviv_iommu_map_gem(struct etnaviv_iommu_context *context,
struct etnaviv_gem_object *etnaviv_obj, u32 memory_base,
- struct etnaviv_vram_mapping *mapping);
+ struct etnaviv_vram_mapping *mapping, u64 va);
void etnaviv_iommu_unmap_gem(struct etnaviv_iommu_context *context,
struct etnaviv_vram_mapping *mapping);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/3] etnaviv softpin support
Hi all, this implements the last missing bits for softpin aka putting userspace in charge of the GPU virtual address space. This builds on top of the per-process address space series. As this is quite a stack of patches now, I'm providing a git branch [1] with all the necessary patches. Please note that I have not yet worked in the feedback I got for the per-process address space patches. The corresponding userspace bits can be found at [2]. The Mesa changes always use softpin where possible and now finally allow GC7000 support to work with a non-horrible UAPI interface. Regards, Lucas [1] https://git.pengutronix.de/git/lst/linux etnaviv/experimental [2] https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1559 Lucas Stach (3): drm/etnaviv: skip command stream validation on PPAS capable GPUs drm/etnaviv: allow to request specific virtual address for gem mapping drm/etnaviv: implement softpin drivers/gpu/drm/etnaviv/etnaviv_drv.c| 2 +- drivers/gpu/drm/etnaviv/etnaviv_drv.h| 2 ++ drivers/gpu/drm/etnaviv/etnaviv_gem.c| 4 +-- drivers/gpu/drm/etnaviv/etnaviv_gem.h| 3 ++- drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 28 ++-- drivers/gpu/drm/etnaviv/etnaviv_gpu.c| 9 +++ drivers/gpu/drm/etnaviv/etnaviv_mmu.c| 16 +-- drivers/gpu/drm/etnaviv/etnaviv_mmu.h| 2 +- include/uapi/drm/etnaviv_drm.h | 5 +++- 9 files changed, 61 insertions(+), 10 deletions(-) -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/etnaviv: implement softpin
With softpin we allow the userspace to take control over the GPU virtual
address space. The new capability is relected by a bump of the minor DRM
version. There are a few restrictions for userspace to take into
account:
1. The kernel reserves a bit of the address space to implement zero page
faulting and mapping of the kernel internal ring buffer. Userspace can
query the kernel for the first usable GPU VM address via
ETNAVIV_PARAM_SOFTPIN_START_ADDR.
2. We only allow softpin on GPUs, which implement proper process
separation via PPAS. If softpin is not available the softpin start
address will be set to ~0.
3. Softpin is all or nothing. A submit using softpin must not use any
address fixups via relocs.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c| 2 +-
drivers/gpu/drm/etnaviv/etnaviv_drv.h| 2 ++
drivers/gpu/drm/etnaviv/etnaviv_gem.c| 4 ++--
drivers/gpu/drm/etnaviv/etnaviv_gem.h| 1 +
drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 25 +++-
drivers/gpu/drm/etnaviv/etnaviv_gpu.c| 9 +++
include/uapi/drm/etnaviv_drm.h | 5 +++-
7 files changed, 43 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index 8bcbd3fb02c6..e2e60cdf8741 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -529,7 +529,7 @@ static struct drm_driver etnaviv_drm_driver = {
.desc = "etnaviv DRM",
.date = "20151214",
.major = 1,
- .minor = 2,
+ .minor = 3,
};
/*
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
index a488cfdb6bbf..32cfa5a48d42 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
@@ -24,6 +24,8 @@ struct etnaviv_gem_object;
struct etnaviv_gem_submit;
struct etnaviv_iommu_global;
+#define ETNAVIV_SOFTPIN_START_ADDRESS SZ_4M /* must be >= SUBALLOC_SIZE */
+
struct etnaviv_file_private {
struct etnaviv_iommu_context*mmu;
struct drm_sched_entity sched_entity[ETNA_MAX_PIPES];
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
index 5dde3e4c3949..dd863bd858f8 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
@@ -248,7 +248,7 @@ void etnaviv_gem_mapping_unreference(struct
etnaviv_vram_mapping *mapping)
}
struct etnaviv_vram_mapping *etnaviv_gem_mapping_get(
- struct drm_gem_object *obj, struct etnaviv_iommu_context *mmu)
+ struct drm_gem_object *obj, struct etnaviv_iommu_context *mmu, u64 va)
{
struct etnaviv_gem_object *etnaviv_obj = to_etnaviv_bo(obj);
struct etnaviv_vram_mapping *mapping;
@@ -308,7 +308,7 @@ struct etnaviv_vram_mapping *etnaviv_gem_mapping_get(
mapping->use = 1;
ret = etnaviv_iommu_map_gem(mmu, etnaviv_obj, mmu->global->memory_base,
- mapping, 0);
+ mapping, va);
if (ret < 0)
kfree(mapping);
else
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.h
b/drivers/gpu/drm/etnaviv/etnaviv_gem.h
index 92f3090b8348..c64e93a6293b 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.h
@@ -77,6 +77,7 @@ static inline bool is_active(struct etnaviv_gem_object
*etnaviv_obj)
struct etnaviv_gem_submit_bo {
u32 flags;
+ u64 va;
struct etnaviv_gem_object *obj;
struct etnaviv_vram_mapping *mapping;
struct dma_fence *excl;
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
index 627c80ed63d8..09e38f78753c 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
@@ -72,6 +72,14 @@ static int submit_lookup_objects(struct etnaviv_gem_submit
*submit,
}
submit->bos[i].flags = bo->flags;
+ if (submit->flags & ETNA_SUBMIT_SOFTPIN) {
+ if (bo->presumed < ETNAVIV_SOFTPIN_START_ADDRESS) {
+ DRM_ERROR("invalid softpin address\n");
+ ret = -EINVAL;
+ goto out_unlock;
+ }
+ submit->bos[i].va = bo->presumed;
+ }
/* normally use drm_gem_object_lookup(), but for bulk lookup
* all under single table_lock just hit object_idr directly:
@@ -224,11 +232,16 @@ static int submit_pin_objects(struct etnaviv_gem_submit
*submit)
struct etnaviv_vram_mapping *mapping;
mapping = etnaviv_gem_mapping_get(_obj->base,
- submit->mmu);
+
[PATCH 1/3] drm/etnaviv: skip command stream validation on PPAS capable GPUs
With per-process address spaces in place, a rogue process submitting
bogus command streams can only hurt itself. There is no need to
validate the command stream before execution anymore.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
index 27a14a270a55..627c80ed63d8 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
@@ -517,7 +517,8 @@ int etnaviv_ioctl_gem_submit(struct drm_device *dev, void
*data,
if (ret)
goto err_submit_objects;
- if (!etnaviv_cmd_validate_one(gpu, stream, args->stream_size / 4,
+ if ((priv->mmu_global->version != ETNAVIV_IOMMU_V2) &&
+ !etnaviv_cmd_validate_one(gpu, stream, args->stream_size / 4,
relocs, args->nr_relocs)) {
ret = -EINVAL;
goto err_submit_objects;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/2] drm: drop DRM_AUTH from PRIME_TO/FROM_HANDLE ioctls
From: Emil Velikov
As mentioned by Christian, for drivers which support only primary nodes
this changes the returned error from -EACCES into -EOPNOTSUPP/-ENOSYS.
For others, this check in particular will be a noop. So let's remove it
as suggested by Christian.
Cc: Alex Deucher
Cc: amd-...@lists.freedesktop.org
Cc: Daniel Vetter
Acked-by: Christian König
Signed-off-by: Emil Velikov
---
drivers/gpu/drm/drm_ioctl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index f675a3bb2c88..867ab4e50374 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -647,8 +647,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETRESOURCES, drm_mode_getresources, 0),
- DRM_IOCTL_DEF(DRM_IOCTL_PRIME_HANDLE_TO_FD,
drm_prime_handle_to_fd_ioctl, DRM_AUTH|DRM_RENDER_ALLOW),
- DRM_IOCTL_DEF(DRM_IOCTL_PRIME_FD_TO_HANDLE,
drm_prime_fd_to_handle_ioctl, DRM_AUTH|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF(DRM_IOCTL_PRIME_HANDLE_TO_FD,
drm_prime_handle_to_fd_ioctl, DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF(DRM_IOCTL_PRIME_FD_TO_HANDLE,
drm_prime_fd_to_handle_ioctl, DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETPLANERESOURCES, drm_mode_getplane_res,
0),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETCRTC, drm_mode_getcrtc, 0),
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/2] drm/vmwgfx: add local DRM_AUTH check for PRIME TO/FROM HANDLE
From: Emil Velikov
Realistically no drivers, but vmwgfx care about the DRM_AUTH flag here.
Follow-up work in this driver will properly isolate primary clients from
different master realms, thus we'll no longer need to parse _any_ ioctl
flags.
Until that work lands, add a local workaround.
v2: Use bitwise or (Deepak)
Cc: VMware Graphics
Cc: Thomas Hellstrom
Cc: Deepak Singh Rawat
Signed-off-by: Emil Velikov
---
I'd like to merge this and the next patch hrough the drm-misc tree. Ack
and rb are appreciated.
Thanks
Emil
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index cd0d49d8a8da..53afb1d597e8 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -1134,6 +1134,15 @@ static long vmw_generic_ioctl(struct file *filp,
unsigned int cmd,
} else if (!drm_ioctl_flags(nr, ))
return -EINVAL;
+ /*
+* Little workaround until the vmwgfx patches providing isolation of
+* primary clients from different master realms land.
+* With that work, we'll no longer need to parse _any_ ioctl flags.
+*/
+ if (nr == 0x2d /* DRM_IOCTL_PRIME_HANDLE_TO_FD */ ||
+ nr == 0x2e /* DRM_IOCTL_PRIME_FD_TO_HANDLE */)
+ flags |= DRM_AUTH;
+
vmaster = vmw_master_check(dev, file_priv, flags);
if (IS_ERR(vmaster)) {
ret = PTR_ERR(vmaster);
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 2/6] udmabuf: add ability to set access flags on udmabuf
On Wed, Jul 31, 2019 at 11:40 PM Gerd Hoffmann wrote: > > On Wed, Jul 31, 2019 at 07:25:13PM -0700, Gurchetan Singh wrote: > > The main use for udmabuf is sending guest memory pages > > to the host. > > > > It's generally a bad idea to have to separate mappings with > > different attributes. For example, a WC mapping the guest > > kernel and cached mapping on the host is problematic. > > > > Add creation time flags so the user has responsibility for > > the specific use case. > > > -#define UDMABUF_FLAGS_CLOEXEC0x01 > > +#define UDMABUF_FLAGS_CLOEXEC0x01 > > +#define UDMABUF_FLAGS_PROT_NONE 0x02 > > +#define UDMABUF_FLAGS_PROT_READ 0x04 > > +#define UDMABUF_FLAGS_PROT_WRITE 0x08 > > [ didn't look at followup patches yet ] > > You can't have readonly/writeonly dmabufs. > So that isn't going to fly. > > The commit message suggests this is for cache attributes not protection, > so having the flags might make sense, but please don't name the flags > PROT_* then. Okay, I'll change the flags to CACHED / UNCACHED / WRITE_COMBINE (like msm_drm.h). And since the dma api doesn't work on x86 [1], we'll have to call drm_cflush_pages in the guest. Since caching is privileged on ARM and not on x86, that *should* get us write-combine guest buffers. [1] https://lists.freedesktop.org/archives/dri-devel/2019-August/229161.html > > cheers, > Gerd > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/syncobj: Convert syncobj_idr to XArray
Prior to making the syncobj lookup lockless, update the idr to the new
XArray API.
Based on a patch by Matthew Wilcox
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_syncobj.c | 64 ++-
include/drm/drm_file.h| 7 ++--
2 files changed, 21 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 1438dcb3ebb1..4fc71dc9fc43 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -86,14 +86,13 @@ struct drm_syncobj *drm_syncobj_find(struct drm_file
*file_private,
{
struct drm_syncobj *syncobj;
- spin_lock(_private->syncobj_table_lock);
+ xa_lock(_private->syncobjs);
- /* Check if we currently have a reference on the object */
- syncobj = idr_find(_private->syncobj_idr, handle);
+ syncobj = xa_load(_private->syncobjs, handle);
if (syncobj)
drm_syncobj_get(syncobj);
- spin_unlock(_private->syncobj_table_lock);
+ xa_unlock(_private->syncobjs);
return syncobj;
}
@@ -366,23 +365,14 @@ int drm_syncobj_get_handle(struct drm_file *file_private,
{
int ret;
- /* take a reference to put in the idr */
drm_syncobj_get(syncobj);
- idr_preload(GFP_KERNEL);
- spin_lock(_private->syncobj_table_lock);
- ret = idr_alloc(_private->syncobj_idr, syncobj, 1, 0, GFP_NOWAIT);
- spin_unlock(_private->syncobj_table_lock);
-
- idr_preload_end();
-
- if (ret < 0) {
+ ret = xa_alloc(_private->syncobjs, handle, syncobj,
+ xa_limit_32b, GFP_KERNEL);
+ if (ret < 0)
drm_syncobj_put(syncobj);
- return ret;
- }
- *handle = ret;
- return 0;
+ return ret;
}
EXPORT_SYMBOL(drm_syncobj_get_handle);
@@ -406,10 +396,7 @@ static int drm_syncobj_destroy(struct drm_file
*file_private,
{
struct drm_syncobj *syncobj;
- spin_lock(_private->syncobj_table_lock);
- syncobj = idr_remove(_private->syncobj_idr, handle);
- spin_unlock(_private->syncobj_table_lock);
-
+ syncobj = xa_erase(_private->syncobjs, handle);
if (!syncobj)
return -EINVAL;
@@ -492,20 +479,12 @@ static int drm_syncobj_fd_to_handle(struct drm_file
*file_private,
return -EINVAL;
}
- /* take a reference to put in the idr */
syncobj = f.file->private_data;
drm_syncobj_get(syncobj);
- idr_preload(GFP_KERNEL);
- spin_lock(_private->syncobj_table_lock);
- ret = idr_alloc(_private->syncobj_idr, syncobj, 1, 0, GFP_NOWAIT);
- spin_unlock(_private->syncobj_table_lock);
- idr_preload_end();
-
- if (ret > 0) {
- *handle = ret;
- ret = 0;
- } else
+ ret = xa_alloc(_private->syncobjs, handle, syncobj,
+ xa_limit_32b, GFP_KERNEL);
+ if (ret < 0)
drm_syncobj_put(syncobj);
fdput(f);
@@ -575,17 +554,7 @@ static int drm_syncobj_export_sync_file(struct drm_file
*file_private,
void
drm_syncobj_open(struct drm_file *file_private)
{
- idr_init_base(_private->syncobj_idr, 1);
- spin_lock_init(_private->syncobj_table_lock);
-}
-
-static int
-drm_syncobj_release_handle(int id, void *ptr, void *data)
-{
- struct drm_syncobj *syncobj = ptr;
-
- drm_syncobj_put(syncobj);
- return 0;
+ xa_init_flags(_private->syncobjs, XA_FLAGS_ALLOC1);
}
/**
@@ -599,9 +568,12 @@ drm_syncobj_release_handle(int id, void *ptr, void *data)
void
drm_syncobj_release(struct drm_file *file_private)
{
- idr_for_each(_private->syncobj_idr,
-_syncobj_release_handle, file_private);
- idr_destroy(_private->syncobj_idr);
+ struct drm_syncobj *syncobj;
+ unsigned long index;
+
+ xa_for_each(_private->syncobjs, index, syncobj)
+ drm_syncobj_put(syncobj);
+ xa_destroy(_private->syncobjs);
}
int
diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
index 67af60bb527a..c6efb5f83fcf 100644
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
#include
@@ -251,10 +252,8 @@ struct drm_file {
/** @table_lock: Protects @object_idr. */
spinlock_t table_lock;
- /** @syncobj_idr: Mapping of sync object handles to object pointers. */
- struct idr syncobj_idr;
- /** @syncobj_table_lock: Protects @syncobj_idr. */
- spinlock_t syncobj_table_lock;
+ /** @syncobjs: Mapping of sync object handles to object pointers. */
+ struct xarray syncobjs;
/** @filp: Pointer to the core file structure. */
struct file *filp;
--
2.23.0.rc0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/syncobj: Lookup the syncobj with RCU protection
Relax the spinlock used for looking up the handle in the XArray and
acquiring a reference to it to an RCU protected critical section. This
incurs the requirement that we protect the syncobj struct itself using
RCU, which we achieve by simply calling kfree_rcu() and being more
careful in acquiring our reference.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_syncobj.c | 12 +---
include/drm/drm_syncobj.h | 2 ++
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 4fc71dc9fc43..aafc03986a48 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -86,13 +86,11 @@ struct drm_syncobj *drm_syncobj_find(struct drm_file
*file_private,
{
struct drm_syncobj *syncobj;
- xa_lock(_private->syncobjs);
-
+ rcu_read_lock();
syncobj = xa_load(_private->syncobjs, handle);
- if (syncobj)
- drm_syncobj_get(syncobj);
-
- xa_unlock(_private->syncobjs);
+ if (syncobj && !kref_get_unless_zero(>refcount))
+ syncobj = NULL;
+ rcu_read_unlock();
return syncobj;
}
@@ -309,7 +307,7 @@ void drm_syncobj_free(struct kref *kref)
struct drm_syncobj,
refcount);
drm_syncobj_replace_fence(syncobj, NULL);
- kfree(syncobj);
+ kfree_rcu(syncobj, rcu);
}
EXPORT_SYMBOL(drm_syncobj_free);
diff --git a/include/drm/drm_syncobj.h b/include/drm/drm_syncobj.h
index 6cf7243a1dc5..7c1503d47abf 100644
--- a/include/drm/drm_syncobj.h
+++ b/include/drm/drm_syncobj.h
@@ -61,6 +61,8 @@ struct drm_syncobj {
* @file: A file backing for this syncobj.
*/
struct file *file;
+
+ struct rcu_head rcu;
};
void drm_syncobj_free(struct kref *kref);
--
2.23.0.rc0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110214] Raven Ridge (2400G): xterm scrollback buffer disappears while Shift+PgUp and Shift+PgDn
https://bugs.freedesktop.org/show_bug.cgi?id=110214 --- Comment #99 from Michel Dänzer --- https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1554 has some fixes for DPBB, might help for this as well. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/syncobj: remove boring message
On Thu, Aug 1, 2019 at 9:05 AM Koenig, Christian
wrote:
> Am 01.08.19 um 15:45 schrieb Lionel Landwerlin:
> > Just had a few exchanges with Chris about this.
> > Chris suggests that if we're about to add a point to the timeline in
> > an unordered fashion, actually better not add it at all.
> >
> > What's your take on this?
>
> That is a clear NAK. See not adding a point at all means we lose some
> synchronization and that is not something we can do here.
>
> In other words syncing to much if userspace does something nasty is ok
> and defensive programmed, but not syncing at all could have unforeseen
> consequences.
>
So if process A signals 7, process B detects that and signals 3 and then
process A tries to insert something which waits on 7 and signals 8, what
happens? My understanding is that it "breaks" the timeline and so, from
the perspective of process A, its signal operation on 7 is gone and it's
attempt to wait on 7 will either -EINVAL because the kernel can't find the
time point or else just sit there. Am I understanding this correctly? If
so, it sounds more like an attack vector than defensive programming to me.
Yes, more syncornization is generally better than less. However, if you're
screwing up your syncronization from userspace and getting wrong rendering
results, that's your fault. If you're causing your compositor to suddenly
start seeing -EINVAL which gets turned into VK_ERROR_DEVICE_LOST, that's a
lot worse IMO. I'm not saying that we shouldn't try to be robust in this
case; I'm just concerned that the suggest solution isn't.
--Jason
> Another idea would be to add the fence, but also set an error flag and
> deny any further signaling on that syncobj.
>
> Regards,
> Christian.
>
> > I'm fine with this, but rather than add another variant of add_point()
> > maybe we change change the existing.
> >
> > Thanks,
> >
> > -Lionel
> >
> > On 29/07/2019 11:20, Chunming Zhou wrote:
> >> It is normal that binary syncobj replaces the underlying fence.
> >>
> >> Signed-off-by: Chunming Zhou
> >> ---
> >> drivers/gpu/drm/drm_syncobj.c | 3 ---
> >> 1 file changed, 3 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_syncobj.c
> >> b/drivers/gpu/drm/drm_syncobj.c
> >> index 929f7c64f9a2..bc7ec1679e4d 100644
> >> --- a/drivers/gpu/drm/drm_syncobj.c
> >> +++ b/drivers/gpu/drm/drm_syncobj.c
> >> @@ -151,9 +151,6 @@ void drm_syncobj_add_point(struct drm_syncobj
> >> *syncobj,
> >> spin_lock(>lock);
> >> prev = drm_syncobj_fence_get(syncobj);
> >> -/* You are adding an unorder point to timeline, which could
> >> cause payload returned from query_ioctl is 0! */
> >> -if (prev && prev->seqno >= point)
> >> -DRM_ERROR("You are adding an unorder point to timeline!\n");
> >> dma_fence_chain_init(chain, prev, fence, point);
> >> rcu_assign_pointer(syncobj->fence, >base);
> >
> >
>
> ___
> 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
[Bug 111243] Installation of 19.20 Fails
https://bugs.freedesktop.org/show_bug.cgi?id=111243 jacque8...@gmail.com changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111287] Box crashes some time after installation
https://bugs.freedesktop.org/show_bug.cgi?id=111287 Bug ID: 111287 Summary: Box crashes some time after installation Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: jacque8...@gmail.com Created attachment 144930 --> https://bugs.freedesktop.org/attachment.cgi?id=144930=edit Logs Recommended by AMD Hi, my box crashed after I installed the AMD Open driver. Didn't have a problem with the Pro driver. I did a clean install of Ubuntu 18.04. Same thing. Please advise how to proceed. Logs are attached. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 20/34] xen: convert put_page() to put_user_page*()
>
> On 02.08.19 07:48, John Hubbard wrote:
> > On 8/1/19 9:36 PM, Juergen Gross wrote:
> >> On 02.08.19 04:19, john.hubb...@gmail.com wrote:
> >>> From: John Hubbard
> > ...
> >>> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c index
> >>> 2f5ce7230a43..29e461dbee2d 100644
> >>> --- a/drivers/xen/privcmd.c
> >>> +++ b/drivers/xen/privcmd.c
> >>> @@ -611,15 +611,10 @@ static int lock_pages(
> >>> static void unlock_pages(struct page *pages[], unsigned int
> >>> nr_pages)
> >>> {
> >>> - unsigned int i;
> >>> -
> >>> if (!pages)
> >>> return;
> >>> - for (i = 0; i < nr_pages; i++) {
> >>> - if (pages[i])
> >>> - put_page(pages[i]);
> >>> - }
> >>> + put_user_pages(pages, nr_pages);
> >>
> >> You are not handling the case where pages[i] is NULL here. Or am I
> >> missing a pending patch to put_user_pages() here?
> >>
> >
> > Hi Juergen,
> >
> > You are correct--this no longer handles the cases where pages[i] is
> > NULL. It's intentional, though possibly wrong. :)
> >
> > I see that I should have added my standard blurb to this commit
> > description. I missed this one, but some of the other patches have it.
> > It makes the following, possibly incorrect claim:
> >
> > "This changes the release code slightly, because each page slot in the
> > page_list[] array is no longer checked for NULL. However, that check
> > was wrong anyway, because the get_user_pages() pattern of usage here
> > never allowed for NULL entries within a range of pinned pages."
> >
> > The way I've seen these page arrays used with get_user_pages(), things
> > are either done single page, or with a contiguous range. So unless I'm
> > missing a case where someone is either
> >
> > a) releasing individual pages within a range (and thus likely messing
> > up their count of pages they have), or
> >
> > b) allocating two gup ranges within the same pages[] array, with a gap
> > between the allocations,
> >
> > ...then it should be correct. If so, then I'll add the above blurb to
> > this patch's commit description.
> >
> > If that's not the case (both here, and in 3 or 4 other patches in this
> > series, then as you said, I should add NULL checks to put_user_pages()
> > and put_user_pages_dirty_lock().
>
> In this case it is not correct, but can easily be handled. The NULL case can
> occur only in an error case with the pages array filled partially or not at
> all.
>
> I'd prefer something like the attached patch here.
I'm not an expert in this code and have not looked at it carefully but that
patch does seem to be the better fix than forcing NULL checks on everyone.
Ira
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v1 02/11] drm: drop uapi dependency from drm_print.h
Hi Jani.
> >> I mean is it useful to have this extra printing subsystem in DRM while
> >> the standard Linux one actually does a better job?
> > The added functionality of drm_xxx_err would be to keep the current
> > drm.debug=0x1f filtering on the command-line.
> > I do not think we can do this with the standard logging.
>
> Correct. I'd love the benefits of dynamic debug, but there's no support
> for the kind of message categories that we do with drm.debug.
>
> I've contemplated switching i915 over to using the variants where you
> pass the device, but I really really don't like the idea of:
>
> - DRM_DEBUG_KMS("hello\n");
> + DRM_DEV_DEBUG_KMS(i915->drm.dev, "hello\n");
>
> Where i915 is our private wrapper for drm_device. I think it's just too
> much ugly uppercase boilerplate, and a large portion of the debugs would
> have to span at least an extra line after that.
>
> I'd also very much prefer passing just struct *drm_device instead of
> struct *device. In that, I think the needs of the few have prevailed
> over the needs of the many. I'd definitely prefer drm_err(const struct
> drm_device *drm, ...) and friends over the current ones.
This is from my notes:
"
drm_err(const struct drm_device *drm, ...)
drm_info(const struct drm_device *drm, ...)
drm_kms_err(const struct drm_device *drm, ...)
drm_kms_info(const struct drm_device *drm, ...))
etc.
Then we could fish out relevant info from the drm device and present
this nicely.
For the cases where no drm_device is available the fallback is:
drm_dev_err(const struct drm_device *drm, ...)
drm_dev_info(const struct drm_device *drm, ...))
We could modify the existing UPPERCASE macros to be placeholders for
the more reader friendly lower cases variants.
"
So we seems to be aligned here.
In other words - if you throw time after this then try to add
the new logging variants to drm_print.h for the benefit of all.
The we can maybe later do some mass conversion if we want to get rid
of some of the older logging systems.
I have not yet found time/energy to throw after this myself.
Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL] exynos-drm-fixes
On Fri, Aug 02, 2019 at 05:33:11PM +0900, Inki Dae wrote: > Hi Dave, > >Just two fixups which fixes undefined reference error with NOMMU >configuration and potential infinite issue of scaler module, >and two trivial cleanups. > >Please kindly let me know if there is any problem. Please prep -fixes pull request on Thu latest, so this doesn't eat into w/e or in case there's an issue that needs to be fixed there's just no time otherwise to make the next -rc. > > Thanks, > Inki Dae > > The following changes since commit f8981e0309e9004c6e86d218049045700c79d740: > > Merge tag 'msm-fixes-2019_08_01' of https://gitlab.freedesktop.org/drm/msm > into drm-fixes (2019-08-02 10:17:25 +1000) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos > tags/exynos-drm-fixes-for-v5.3-rc3 Applied, thanks. -Daniel > > for you to fetch changes up to 1bbbab097a05276e312dd2462791d32b21ceb1ee: > > drm/exynos: fix missing decrement of retry counter (2019-08-02 16:50:18 > +0900) > > > - Two cleanup patches > . use dev_get_drvdata for readability instead of platform_get_drvdata > . remove redundant assignment to node. > - Two fixup patches > . fix undefined reference to 'vmf_insert_mixed' with NOMMU configuration. > . fix potential infinite spin issue by decrementing 'retry' variable in > scaler_reset function of exynos_drm_scaler.c > > > Arnd Bergmann (1): > drm/exynos: add CONFIG_MMU dependency > > Colin Ian King (2): > drm/exynos: remove redundant assignment to pointer 'node' > drm/exynos: fix missing decrement of retry counter > > Fuqian Huang (1): > drm/exynos: using dev_get_drvdata directly > > drivers/gpu/drm/exynos/Kconfig | 1 + > drivers/gpu/drm/exynos/exynos_drm_fimc.c | 2 +- > drivers/gpu/drm/exynos/exynos_drm_g2d.c| 2 +- > drivers/gpu/drm/exynos/exynos_drm_gsc.c| 2 +- > drivers/gpu/drm/exynos/exynos_drm_scaler.c | 4 ++-- > 5 files changed, 6 insertions(+), 5 deletions(-) > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- 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: [PULL] drm-misc-fixes
On Fri, Aug 02, 2019 at 03:43:48PM +0200, Maarten Lankhorst wrote: > Hey, > > Bit late, but fixes for v5.3-rc3. :) Yes, please try to prep and send out -fixes pull on Thu latest. Otherwise there's no time to fix things up and it eats into w/e ... > > drm-misc-fixes-2019-08-02: > drm-misc-fixes for v5.3-rc3: > - Fix some build errors in drm/bridge. > - Do not build i810 on CONFIG_PREEMPTION. > - Fix cache sync on arm in vgem. > - Allow mapping fb in drm_client only when required, and use it to fix bochs > fbdev. > The following changes since commit 609488bc979f99f805f34e9a32c1e3b71179d10b: > > Linux 5.3-rc2 (2019-07-28 12:47:02 -0700) > > are available in the Git repository at: > > git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2019-08-02 Pulled, thanks. -Daniel > > for you to fetch changes up to 58540594570778fd149cd8c9b2bff61f2cefa8c9: > > drm/bochs: Use shadow buffer for bochs framebuffer console (2019-08-01 > 15:01:42 +0200) > > > drm-misc-fixes for v5.3-rc3: > - Fix some build errors in drm/bridge. > - Do not build i810 on CONFIG_PREEMPTION. > - Fix cache sync on arm in vgem. > - Allow mapping fb in drm_client only when required, and use it to fix bochs > fbdev. > > > Maarten Lankhorst (1): > Merge tag 'v5.3-rc2' into drm-misc-fixes > > Rob Clark (1): > drm/vgem: fix cache synchronization on arm/arm64 > > Thomas Gleixner (1): > drm/i810: Use CONFIG_PREEMPTION > > Thomas Zimmermann (4): > drm/client: Support unmapping of DRM client buffers > drm/fb-helper: Map DRM client buffer only when required > drm/fb-helper: Instanciate shadow FB if configured in device's > mode_config > drm/bochs: Use shadow buffer for bochs framebuffer console > > YueHaibing (2): > drm/bridge: lvds-encoder: Fix build error while CONFIG_DRM_KMS_HELPER=m > drm/bridge: tc358764: Fix build error > > drivers/gpu/drm/Kconfig | 2 +- > drivers/gpu/drm/bochs/bochs_kms.c | 1 + > drivers/gpu/drm/bridge/Kconfig| 4 +- > drivers/gpu/drm/drm_client.c | 60 ++ > drivers/gpu/drm/drm_fb_helper.c | 51 +++ > drivers/gpu/drm/vgem/vgem_drv.c | 130 > -- > include/drm/drm_client.h | 2 + > include/drm/drm_mode_config.h | 7 ++ > 8 files changed, 186 insertions(+), 71 deletions(-) -- 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: [Intel-gfx] [PATCH] Revert "drm/vgem: fix cache synchronization on arm/arm64"
On Fri, Aug 02, 2019 at 10:18:10AM -0400, Sean Paul wrote:
> On Thu, Aug 01, 2019 at 01:44:58PM +0100, Chris Wilson wrote:
> > commit 7e9e5ead55be ("drm/vgem: fix cache synchronization on arm/arm64")
> > broke all of the !llc i915-vgem coherency tests in CI, and left the HW
> > very, very unhappy (which is even more scary).
> >
> > Fixes: 7e9e5ead55be ("drm/vgem: fix cache synchronization on arm/arm64")
> > Signed-off-by: Chris Wilson
>
> Acked-by: Sean Paul
Applied to drm-fixes directly.
Thanks, Daniel
>
> > Cc: Daniel Vetter
> > Cc: Rob Clark
> > Cc: Sean Paul
> > ---
> > drivers/gpu/drm/vgem/vgem_drv.c | 130
> > 1 file changed, 47 insertions(+), 83 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/vgem/vgem_drv.c
> > b/drivers/gpu/drm/vgem/vgem_drv.c
> > index b98689fb0d5d..5bd60ded3d81 100644
> > --- a/drivers/gpu/drm/vgem/vgem_drv.c
> > +++ b/drivers/gpu/drm/vgem/vgem_drv.c
> > @@ -54,16 +54,10 @@ static struct vgem_device {
> > struct platform_device *platform;
> > } *vgem_device;
> >
> > -static void sync_and_unpin(struct drm_vgem_gem_object *bo);
> > -static struct page **pin_and_sync(struct drm_vgem_gem_object *bo);
> > -
> > static void vgem_gem_free_object(struct drm_gem_object *obj)
> > {
> > struct drm_vgem_gem_object *vgem_obj = to_vgem_bo(obj);
> >
> > - if (!obj->import_attach)
> > - sync_and_unpin(vgem_obj);
> > -
> > kvfree(vgem_obj->pages);
> > mutex_destroy(_obj->pages_lock);
> >
> > @@ -91,15 +85,40 @@ static vm_fault_t vgem_gem_fault(struct vm_fault *vmf)
> > return VM_FAULT_SIGBUS;
> >
> > mutex_lock(>pages_lock);
> > - if (!obj->pages)
> > - pin_and_sync(obj);
> > if (obj->pages) {
> > get_page(obj->pages[page_offset]);
> > vmf->page = obj->pages[page_offset];
> > ret = 0;
> > }
> > mutex_unlock(>pages_lock);
> > + if (ret) {
> > + struct page *page;
> > +
> > + page = shmem_read_mapping_page(
> > + file_inode(obj->base.filp)->i_mapping,
> > + page_offset);
> > + if (!IS_ERR(page)) {
> > + vmf->page = page;
> > + ret = 0;
> > + } else switch (PTR_ERR(page)) {
> > + case -ENOSPC:
> > + case -ENOMEM:
> > + ret = VM_FAULT_OOM;
> > + break;
> > + case -EBUSY:
> > + ret = VM_FAULT_RETRY;
> > + break;
> > + case -EFAULT:
> > + case -EINVAL:
> > + ret = VM_FAULT_SIGBUS;
> > + break;
> > + default:
> > + WARN_ON(PTR_ERR(page));
> > + ret = VM_FAULT_SIGBUS;
> > + break;
> > + }
> >
> > + }
> > return ret;
> > }
> >
> > @@ -265,93 +284,32 @@ static const struct file_operations vgem_driver_fops
> > = {
> > .release= drm_release,
> > };
> >
> > -/* Called under pages_lock, except in free path (where it can't race): */
> > -static void sync_and_unpin(struct drm_vgem_gem_object *bo)
> > -{
> > - struct drm_device *dev = bo->base.dev;
> > -
> > - if (bo->table) {
> > - dma_sync_sg_for_cpu(dev->dev, bo->table->sgl,
> > - bo->table->nents, DMA_BIDIRECTIONAL);
> > - sg_free_table(bo->table);
> > - kfree(bo->table);
> > - bo->table = NULL;
> > - }
> > -
> > - if (bo->pages) {
> > - drm_gem_put_pages(>base, bo->pages, true, true);
> > - bo->pages = NULL;
> > - }
> > -}
> > -
> > -static struct page **pin_and_sync(struct drm_vgem_gem_object *bo)
> > -{
> > - struct drm_device *dev = bo->base.dev;
> > - int npages = bo->base.size >> PAGE_SHIFT;
> > - struct page **pages;
> > - struct sg_table *sgt;
> > -
> > - WARN_ON(!mutex_is_locked(>pages_lock));
> > -
> > - pages = drm_gem_get_pages(>base);
> > - if (IS_ERR(pages)) {
> > - bo->pages_pin_count--;
> > - mutex_unlock(>pages_lock);
> > - return pages;
> > - }
> > -
> > - sgt = drm_prime_pages_to_sg(pages, npages);
> > - if (IS_ERR(sgt)) {
> > - dev_err(dev->dev,
> > - "failed to allocate sgt: %ld\n",
> > - PTR_ERR(bo->table));
> > - drm_gem_put_pages(>base, pages, false, false);
> > - mutex_unlock(>pages_lock);
> > - return ERR_CAST(bo->table);
> > - }
> > -
> > - /*
> > -* Flush the object from the CPU cache so that importers
> > -* can rely on coherent indirect access via the exported
> > -* dma-address.
> > -*/
> > - dma_sync_sg_for_device(dev->dev, sgt->sgl,
> > - sgt->nents, DMA_BIDIRECTIONAL);
> > -
> > -
Re: drm/komeda: Add support for generation of CRC data per frame.
On Fri, Aug 2, 2019 at 4:50 PM Liviu Dudau wrote:
>
> On Fri, Aug 02, 2019 at 11:52:11AM +0200, Daniel Vetter wrote:
> > On Fri, Aug 2, 2019 at 11:39 AM Brian Starkey wrote:
> > >
> > > Hi Liviu,
> > >
> > > On Thu, Aug 01, 2019 at 11:42:31AM +0100, Liviu Dudau wrote:
> > > > Komeda has support to generate per-frame CRC values in the DOU
> > > > backend subsystem. Implement necessary hooks to expose the CRC
> > > > "control" and "data" file over debugfs and program the DOUx_BS
> > > > accordingly.
> > > >
> > > > This patch makes use of PL1 (programmable line 1) interrupt to
> > > > know when the CRC generation has finished.
> > > >
> > > > Patch is also dependent on the series that adds dual-link support
> > > > for komeda: https://patchwork.freedesktop.org/series/62280/
> > > >
> > > > Cc: "james qian wang (Arm Technology China)"
> > > > Signed-off-by: Liviu Dudau
> > > > ---
> > > > .../arm/display/komeda/d71/d71_component.c| 2 +-
> > > > .../gpu/drm/arm/display/komeda/d71/d71_dev.c | 29 -
> > > > .../gpu/drm/arm/display/komeda/komeda_crtc.c | 61 ++-
> > > > .../gpu/drm/arm/display/komeda/komeda_dev.h | 2 +
> > > > .../gpu/drm/arm/display/komeda/komeda_kms.h | 3 +
> > > > .../drm/arm/display/komeda/komeda_pipeline.h | 1 +
> > > > 6 files changed, 94 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> > > > b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> > > > index 55a8cc94808a1..3c45468848ee4 100644
> > > > --- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> > > > +++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> > > > @@ -1061,7 +1061,7 @@ static void d71_timing_ctrlr_update(struct
> > > > komeda_component *c,
> > > > malidp_write32(reg, BS_PREFETCH_LINE, D71_DEFAULT_PREPRETCH_LINE);
> > > >
> > > > /* configure bs control register */
> > > > - value = BS_CTRL_EN | BS_CTRL_VM;
> > > > + value = BS_CTRL_EN | BS_CTRL_VM | BS_CTRL_CRC;
> > > > if (c->pipeline->dual_link) {
> > > > malidp_write32(reg, BS_DRIFT_TO, hfront_porch + 16);
> > > > value |= BS_CTRL_DL;
> > > > diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
> > > > b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
> > > > index d567ab7ed314e..05bfd9891c540 100644
> > > > --- a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
> > > > +++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
> > > > @@ -115,6 +115,8 @@ static u64 get_dou_event(struct d71_pipeline
> > > > *d71_pipeline)
> > > > raw_status = malidp_read32(reg, BLK_IRQ_RAW_STATUS);
> > > > if (raw_status & DOU_IRQ_PL0)
> > > > evts |= KOMEDA_EVENT_VSYNC;
> > > > + if (raw_status & DOU_IRQ_PL1)
> > > > + evts |= KOMEDA_EVENT_CRCDONE;
> > > > if (raw_status & DOU_IRQ_UND)
> > > > evts |= KOMEDA_EVENT_URUN;
> > > >
> > > > @@ -149,7 +151,7 @@ static u64 get_dou_event(struct d71_pipeline
> > > > *d71_pipeline)
> > > >
> > > > static u64 get_pipeline_event(struct d71_pipeline *d71_pipeline, u32
> > > > gcu_status)
> > > > {
> > > > - u32 evts = 0ULL;
> > > > + u64 evts = 0ULL;
> > > >
> > > > if (gcu_status & (GLB_IRQ_STATUS_LPU0 | GLB_IRQ_STATUS_LPU1))
> > > > evts |= get_lpu_event(d71_pipeline);
> > > > @@ -163,6 +165,26 @@ static u64 get_pipeline_event(struct d71_pipeline
> > > > *d71_pipeline, u32 gcu_status)
> > > > return evts;
> > > > }
> > > >
> > > > +static void get_frame_crcs(struct d71_pipeline *d71_pipeline, u32 pipe,
> > > > +struct komeda_events *evts)
> > > > +{
> > > > + if (evts->pipes[pipe] & KOMEDA_EVENT_CRCDONE) {
> > > > + struct komeda_component *c;
> > > > +
> > > > + c = komeda_pipeline_get_component(_pipeline->base,
> > > > +
> > > > KOMEDA_COMPONENT_TIMING_CTRLR);
> > > > + if (!c)
> > > > + return;
> > > > +
> > > > + evts->crcs[pipe][0] = malidp_read32(c->reg, BS_CRC0_LOW);
> > > > + evts->crcs[pipe][1] = malidp_read32(c->reg, BS_CRC0_HIGH);
> > > > + if (d71_pipeline->base.dual_link) {
> > > > + evts->crcs[pipe][2] = malidp_read32(c->reg,
> > > > BS_CRC1_LOW);
> > > > + evts->crcs[pipe][3] = malidp_read32(c->reg,
> > > > BS_CRC1_HIGH);
> > > > + }
> > > > + }
> > > > +}
> > > > +
> > > > static irqreturn_t
> > > > d71_irq_handler(struct komeda_dev *mdev, struct komeda_events *evts)
> > > > {
> > > > @@ -195,6 +217,9 @@ d71_irq_handler(struct komeda_dev *mdev, struct
> > > > komeda_events *evts)
> > > > if (gcu_status & GLB_IRQ_STATUS_PIPE1)
> > > > evts->pipes[1] |= get_pipeline_event(d71->pipes[1],
> > > > gcu_status);
> > > >
> > > > + get_frame_crcs(d71->pipes[0], 0, evts);
> > > > +
Re: [PATCH 00/34] put_user_pages(): miscellaneous call sites
On Fri 02-08-19 07:24:43, Matthew Wilcox wrote: > On Fri, Aug 02, 2019 at 02:41:46PM +0200, Jan Kara wrote: > > On Fri 02-08-19 11:12:44, Michal Hocko wrote: > > > On Thu 01-08-19 19:19:31, john.hubb...@gmail.com wrote: > > > [...] > > > > 2) Convert all of the call sites for get_user_pages*(), to > > > > invoke put_user_page*(), instead of put_page(). This involves dozens of > > > > call sites, and will take some time. > > > > > > How do we make sure this is the case and it will remain the case in the > > > future? There must be some automagic to enforce/check that. It is simply > > > not manageable to do it every now and then because then 3) will simply > > > be never safe. > > > > > > Have you considered coccinele or some other scripted way to do the > > > transition? I have no idea how to deal with future changes that would > > > break the balance though. > > > > Yeah, that's why I've been suggesting at LSF/MM that we may need to create > > a gup wrapper - say vaddr_pin_pages() - and track which sites dropping > > references got converted by using this wrapper instead of gup. The > > counterpart would then be more logically named as unpin_page() or whatever > > instead of put_user_page(). Sure this is not completely foolproof (you can > > create new callsite using vaddr_pin_pages() and then just drop refs using > > put_page()) but I suppose it would be a high enough barrier for missed > > conversions... Thoughts? > > I think the API we really need is get_user_bvec() / put_user_bvec(), > and I know Christoph has been putting some work into that. That avoids > doing refcount operations on hundreds of pages if the page in question is > a huge page. Once people are switched over to that, they won't be tempted > to manually call put_page() on the individual constituent pages of a bvec. Well, get_user_bvec() is certainly a good API for one class of users but just looking at the above series, you'll see there are *many* places that just don't work with bvecs at all and you need something for those. Honza -- Jan Kara SUSE Labs, CR ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm/komeda: Add support for generation of CRC data per frame.
On Fri, Aug 02, 2019 at 11:52:11AM +0200, Daniel Vetter wrote:
> On Fri, Aug 2, 2019 at 11:39 AM Brian Starkey wrote:
> >
> > Hi Liviu,
> >
> > On Thu, Aug 01, 2019 at 11:42:31AM +0100, Liviu Dudau wrote:
> > > Komeda has support to generate per-frame CRC values in the DOU
> > > backend subsystem. Implement necessary hooks to expose the CRC
> > > "control" and "data" file over debugfs and program the DOUx_BS
> > > accordingly.
> > >
> > > This patch makes use of PL1 (programmable line 1) interrupt to
> > > know when the CRC generation has finished.
> > >
> > > Patch is also dependent on the series that adds dual-link support
> > > for komeda: https://patchwork.freedesktop.org/series/62280/
> > >
> > > Cc: "james qian wang (Arm Technology China)"
> > > Signed-off-by: Liviu Dudau
> > > ---
> > > .../arm/display/komeda/d71/d71_component.c| 2 +-
> > > .../gpu/drm/arm/display/komeda/d71/d71_dev.c | 29 -
> > > .../gpu/drm/arm/display/komeda/komeda_crtc.c | 61 ++-
> > > .../gpu/drm/arm/display/komeda/komeda_dev.h | 2 +
> > > .../gpu/drm/arm/display/komeda/komeda_kms.h | 3 +
> > > .../drm/arm/display/komeda/komeda_pipeline.h | 1 +
> > > 6 files changed, 94 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> > > b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> > > index 55a8cc94808a1..3c45468848ee4 100644
> > > --- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> > > +++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> > > @@ -1061,7 +1061,7 @@ static void d71_timing_ctrlr_update(struct
> > > komeda_component *c,
> > > malidp_write32(reg, BS_PREFETCH_LINE, D71_DEFAULT_PREPRETCH_LINE);
> > >
> > > /* configure bs control register */
> > > - value = BS_CTRL_EN | BS_CTRL_VM;
> > > + value = BS_CTRL_EN | BS_CTRL_VM | BS_CTRL_CRC;
> > > if (c->pipeline->dual_link) {
> > > malidp_write32(reg, BS_DRIFT_TO, hfront_porch + 16);
> > > value |= BS_CTRL_DL;
> > > diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
> > > b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
> > > index d567ab7ed314e..05bfd9891c540 100644
> > > --- a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
> > > +++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
> > > @@ -115,6 +115,8 @@ static u64 get_dou_event(struct d71_pipeline
> > > *d71_pipeline)
> > > raw_status = malidp_read32(reg, BLK_IRQ_RAW_STATUS);
> > > if (raw_status & DOU_IRQ_PL0)
> > > evts |= KOMEDA_EVENT_VSYNC;
> > > + if (raw_status & DOU_IRQ_PL1)
> > > + evts |= KOMEDA_EVENT_CRCDONE;
> > > if (raw_status & DOU_IRQ_UND)
> > > evts |= KOMEDA_EVENT_URUN;
> > >
> > > @@ -149,7 +151,7 @@ static u64 get_dou_event(struct d71_pipeline
> > > *d71_pipeline)
> > >
> > > static u64 get_pipeline_event(struct d71_pipeline *d71_pipeline, u32
> > > gcu_status)
> > > {
> > > - u32 evts = 0ULL;
> > > + u64 evts = 0ULL;
> > >
> > > if (gcu_status & (GLB_IRQ_STATUS_LPU0 | GLB_IRQ_STATUS_LPU1))
> > > evts |= get_lpu_event(d71_pipeline);
> > > @@ -163,6 +165,26 @@ static u64 get_pipeline_event(struct d71_pipeline
> > > *d71_pipeline, u32 gcu_status)
> > > return evts;
> > > }
> > >
> > > +static void get_frame_crcs(struct d71_pipeline *d71_pipeline, u32 pipe,
> > > +struct komeda_events *evts)
> > > +{
> > > + if (evts->pipes[pipe] & KOMEDA_EVENT_CRCDONE) {
> > > + struct komeda_component *c;
> > > +
> > > + c = komeda_pipeline_get_component(_pipeline->base,
> > > +
> > > KOMEDA_COMPONENT_TIMING_CTRLR);
> > > + if (!c)
> > > + return;
> > > +
> > > + evts->crcs[pipe][0] = malidp_read32(c->reg, BS_CRC0_LOW);
> > > + evts->crcs[pipe][1] = malidp_read32(c->reg, BS_CRC0_HIGH);
> > > + if (d71_pipeline->base.dual_link) {
> > > + evts->crcs[pipe][2] = malidp_read32(c->reg,
> > > BS_CRC1_LOW);
> > > + evts->crcs[pipe][3] = malidp_read32(c->reg,
> > > BS_CRC1_HIGH);
> > > + }
> > > + }
> > > +}
> > > +
> > > static irqreturn_t
> > > d71_irq_handler(struct komeda_dev *mdev, struct komeda_events *evts)
> > > {
> > > @@ -195,6 +217,9 @@ d71_irq_handler(struct komeda_dev *mdev, struct
> > > komeda_events *evts)
> > > if (gcu_status & GLB_IRQ_STATUS_PIPE1)
> > > evts->pipes[1] |= get_pipeline_event(d71->pipes[1],
> > > gcu_status);
> > >
> > > + get_frame_crcs(d71->pipes[0], 0, evts);
> > > + get_frame_crcs(d71->pipes[1], 1, evts);
> > > +
> > > return gcu_status ? IRQ_HANDLED : IRQ_NONE;
> > > }
> > >
> > > @@ -202,7 +227,7 @@ d71_irq_handler(struct komeda_dev *mdev, struct
> > > komeda_events *evts)
> > >GCU_IRQ_MODE |
[PATCH] drm/komeda: Add support for 'memory-region' DT node property
The 'memory-region' property of the komeda display driver DT binding
allows the use of a 'reserved-memory' node for buffer allocations. Add
the requisite of_reserved_mem_device_{init,release} calls to actually
make use of the memory if present.
Signed-off-by: Mihail Atanassov
---
drivers/gpu/drm/arm/display/komeda/komeda_drv.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
b/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
index cfa5068d9d1e..2ec877ad260a 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
@@ -6,6 +6,7 @@
*/
#include
#include
+#include
#include
#include
#include
@@ -32,6 +33,7 @@ static void komeda_unbind(struct device *dev)
return;
komeda_kms_detach(mdrv->kms);
+of_reserved_mem_device_release(dev);
komeda_dev_destroy(mdrv->mdev);
dev_set_drvdata(dev, NULL);
@@ -53,6 +55,11 @@ static int komeda_bind(struct device *dev)
goto free_mdrv;
}
+/* Get the optional framebuffer memory resource */
+err = of_reserved_mem_device_init(dev);
+if (err && err != -ENODEV)
+goto destroy_mdev;
+
mdrv->kms = komeda_kms_attach(mdrv->mdev);
if (IS_ERR(mdrv->kms)) {
err = PTR_ERR(mdrv->kms);
--
2.22.0
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 26/34] mm/gup_benchmark.c: convert put_page() to put_user_page*()
On Thu, Aug 01, 2019 at 07:19:57PM -0700, john.hubb...@gmail.com wrote:
> From: John Hubbard
>
> For pages that were retained via get_user_pages*(), release those pages
> via the new put_user_page*() routines, instead of via put_page() or
> release_pages().
>
> This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
> ("mm: introduce put_user_page*(), placeholder versions").
>
> Cc: Dan Carpenter
> Cc: Greg Kroah-Hartman
> Cc: Keith Busch
> Cc: Kirill A. Shutemov
> Cc: Michael S. Tsirkin
> Cc: YueHaibing
> Signed-off-by: John Hubbard
Looks fine.
Reviewed-by: Keith Busch
> mm/gup_benchmark.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/gup_benchmark.c b/mm/gup_benchmark.c
> index 7dd602d7f8db..515ac8eeb6ee 100644
> --- a/mm/gup_benchmark.c
> +++ b/mm/gup_benchmark.c
> @@ -79,7 +79,7 @@ static int __gup_benchmark_ioctl(unsigned int cmd,
> for (i = 0; i < nr_pages; i++) {
> if (!pages[i])
> break;
> - put_page(pages[i]);
> + put_user_page(pages[i]);
> }
> end_time = ktime_get();
> gup->put_delta_usec = ktime_us_delta(end_time, start_time);
> --
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/8] drm/etnaviv: split out cmdbuf mapping into address space
Hi Guido, On Fri, 2019-08-02 at 15:39 +0200, Guido Günther wrote: > Hi Lucas, > On Fri, Jul 05, 2019 at 07:17:21PM +0200, Lucas Stach wrote: > > This allows to decouple the cmdbuf suballocator create and mapping > > the region into the GPU address space. Allowing multiple AS to share > > a single cmdbuf suballoc. > > Can you tell me where this would apply? I tried 5.2 and next-20190726 > with and without > >[PATCH 1/2] drm/etnaviv: fix etnaviv_cmdbuf_suballoc_new return value I have stacked drm/etnaviv: drop use of drmP.h drm/etnaviv: Use devm_platform_ioremap_resource() drm/etnaviv: clean up includes drm/etnaviv: fix etnaviv_cmdbuf_suballoc_new return value drm/etnaviv: remove unused function etnaviv_gem_mapping_reference drm/etnaviv: dump only failing submit drm/etnaviv: simplify unbind checks on top of v5.3-r1 and this patch applied with a bit of fuzz. regards Philipp ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] drm/tiny/ili9341: Move driver to drm/panel
Den 01.08.2019 21.43, skrev David Lechner: > On 8/1/19 8:52 AM, Noralf Trønnes wrote: >> Move the driver to drm/panel and take advantage of the new panel support >> in drm_mipi_dbi. Change the file name to match the naming standard in >> drm/panel. The DRM driver name is kept since it is ABI. >> >> Add missing MAINTAINERS entry. >> >> Cc: David Lechner >> Signed-off-by: Noralf Trønnes >> --- > > Reviewed-by: David Lechner > > Although, I will say that the way the diff came out, it makes it a bit > hard to follow the patch, so more more details in the commit message about > the specific changes could be helpful. Oh, I actually liked how the diff came out, since I found it easy to see how the drivers differed. But then again, I have have the code fresh in my brain cache so that might make a difference in how it looks. I can expand the commit message. I also see that I have moved the device tables, maybe I should move them back where they where originally so they are closer to the configs they refer to. Noralf. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] Revert "drm/vgem: fix cache synchronization on arm/arm64"
On Thu, Aug 01, 2019 at 01:44:58PM +0100, Chris Wilson wrote:
> commit 7e9e5ead55be ("drm/vgem: fix cache synchronization on arm/arm64")
> broke all of the !llc i915-vgem coherency tests in CI, and left the HW
> very, very unhappy (which is even more scary).
>
> Fixes: 7e9e5ead55be ("drm/vgem: fix cache synchronization on arm/arm64")
> Signed-off-by: Chris Wilson
Acked-by: Sean Paul
> Cc: Daniel Vetter
> Cc: Rob Clark
> Cc: Sean Paul
> ---
> drivers/gpu/drm/vgem/vgem_drv.c | 130
> 1 file changed, 47 insertions(+), 83 deletions(-)
>
> diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
> index b98689fb0d5d..5bd60ded3d81 100644
> --- a/drivers/gpu/drm/vgem/vgem_drv.c
> +++ b/drivers/gpu/drm/vgem/vgem_drv.c
> @@ -54,16 +54,10 @@ static struct vgem_device {
> struct platform_device *platform;
> } *vgem_device;
>
> -static void sync_and_unpin(struct drm_vgem_gem_object *bo);
> -static struct page **pin_and_sync(struct drm_vgem_gem_object *bo);
> -
> static void vgem_gem_free_object(struct drm_gem_object *obj)
> {
> struct drm_vgem_gem_object *vgem_obj = to_vgem_bo(obj);
>
> - if (!obj->import_attach)
> - sync_and_unpin(vgem_obj);
> -
> kvfree(vgem_obj->pages);
> mutex_destroy(_obj->pages_lock);
>
> @@ -91,15 +85,40 @@ static vm_fault_t vgem_gem_fault(struct vm_fault *vmf)
> return VM_FAULT_SIGBUS;
>
> mutex_lock(>pages_lock);
> - if (!obj->pages)
> - pin_and_sync(obj);
> if (obj->pages) {
> get_page(obj->pages[page_offset]);
> vmf->page = obj->pages[page_offset];
> ret = 0;
> }
> mutex_unlock(>pages_lock);
> + if (ret) {
> + struct page *page;
> +
> + page = shmem_read_mapping_page(
> + file_inode(obj->base.filp)->i_mapping,
> + page_offset);
> + if (!IS_ERR(page)) {
> + vmf->page = page;
> + ret = 0;
> + } else switch (PTR_ERR(page)) {
> + case -ENOSPC:
> + case -ENOMEM:
> + ret = VM_FAULT_OOM;
> + break;
> + case -EBUSY:
> + ret = VM_FAULT_RETRY;
> + break;
> + case -EFAULT:
> + case -EINVAL:
> + ret = VM_FAULT_SIGBUS;
> + break;
> + default:
> + WARN_ON(PTR_ERR(page));
> + ret = VM_FAULT_SIGBUS;
> + break;
> + }
>
> + }
> return ret;
> }
>
> @@ -265,93 +284,32 @@ static const struct file_operations vgem_driver_fops = {
> .release= drm_release,
> };
>
> -/* Called under pages_lock, except in free path (where it can't race): */
> -static void sync_and_unpin(struct drm_vgem_gem_object *bo)
> -{
> - struct drm_device *dev = bo->base.dev;
> -
> - if (bo->table) {
> - dma_sync_sg_for_cpu(dev->dev, bo->table->sgl,
> - bo->table->nents, DMA_BIDIRECTIONAL);
> - sg_free_table(bo->table);
> - kfree(bo->table);
> - bo->table = NULL;
> - }
> -
> - if (bo->pages) {
> - drm_gem_put_pages(>base, bo->pages, true, true);
> - bo->pages = NULL;
> - }
> -}
> -
> -static struct page **pin_and_sync(struct drm_vgem_gem_object *bo)
> -{
> - struct drm_device *dev = bo->base.dev;
> - int npages = bo->base.size >> PAGE_SHIFT;
> - struct page **pages;
> - struct sg_table *sgt;
> -
> - WARN_ON(!mutex_is_locked(>pages_lock));
> -
> - pages = drm_gem_get_pages(>base);
> - if (IS_ERR(pages)) {
> - bo->pages_pin_count--;
> - mutex_unlock(>pages_lock);
> - return pages;
> - }
> -
> - sgt = drm_prime_pages_to_sg(pages, npages);
> - if (IS_ERR(sgt)) {
> - dev_err(dev->dev,
> - "failed to allocate sgt: %ld\n",
> - PTR_ERR(bo->table));
> - drm_gem_put_pages(>base, pages, false, false);
> - mutex_unlock(>pages_lock);
> - return ERR_CAST(bo->table);
> - }
> -
> - /*
> - * Flush the object from the CPU cache so that importers
> - * can rely on coherent indirect access via the exported
> - * dma-address.
> - */
> - dma_sync_sg_for_device(dev->dev, sgt->sgl,
> - sgt->nents, DMA_BIDIRECTIONAL);
> -
> - bo->pages = pages;
> - bo->table = sgt;
> -
> - return pages;
> -}
> -
> static struct page **vgem_pin_pages(struct drm_vgem_gem_object *bo)
> {
> - struct page **pages;
> -
> mutex_lock(>pages_lock);
> - if
Re: [4/4] drm/panel/ili9341: Support DPI panels
Den 01.08.2019 21.10, skrev David Lechner:
> On 8/1/19 8:52 AM, Noralf Trønnes wrote:
>> Add support for panels that use the DPI interface.
>> ILI9341 has onboard RAM so the assumption made here is that all such
>> panels support pixel upload over DBI.
>>
>> The presence/absense of the Device Tree 'port' node decides which
>> interface is used for pixel transfer.
>>
>> Signed-off-by: Noralf Trønnes
>> ---
>> drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 56
>> 1 file changed, 45 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
>> b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
>> index f6082fa2a389..7cbfd739c7fd 100644
>> --- a/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
>> +++ b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
>> @@ -11,6 +11,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -53,11 +54,13 @@
>> struct ili9341_config {
>> const struct drm_panel_funcs *funcs;
>> const struct drm_display_mode *mode;
>> + bool no_dpi;
>
> Can we invert this to use positive logic? i.e. use_dpi instead of
> no_dpi.
>
This is a capability flag. I could call it has_dpi and add a comment
about what it does.
Noralf.
>> };
>> struct ili9341 {
>> struct mipi_dbi_dev dbidev; /* This must be the first entry */
>> struct drm_panel panel;
>> + bool use_dpi;
>> struct regulator *regulator;
>> struct backlight_device *backlight;
>> const struct ili9341_config *conf;
>> @@ -174,6 +177,7 @@ static const struct drm_display_mode
>> yx240qv29_mode = {
>> static const struct ili9341_config yx240qv29_data = {
>> .funcs = _funcs,
>> .mode = _mode,
>> + .no_dpi = true,
>> };
>> static int mi0283qt_prepare(struct drm_panel *panel)
>> @@ -291,6 +295,7 @@ static const struct drm_display_mode mi0283qt_mode
>> = {
>> static const struct ili9341_config mi0283qt_data = {
>> .funcs = _drm_funcs,
>> .mode = _mode,
>> + .no_dpi = true,
>> };
>> /* Legacy, DRM driver name is ABI */
>> @@ -303,6 +308,7 @@ static int ili9341_probe(struct spi_device *spi)
>> const struct spi_device_id *spi_id;
>> struct device *dev = >dev;
>> struct drm_driver *driver;
>> + struct device_node *port;
>> struct mipi_dbi *dbi;
>> struct gpio_desc *dc;
>> struct ili9341 *ili;
>> @@ -357,21 +363,44 @@ static int ili9341_probe(struct spi_device *spi)
>> ili->panel.dev = dev;
>> ili->panel.funcs = ili->conf->funcs;
>> - if (ili->conf == _data)
>> - driver = _drm_driver;
>> - else
>> - driver = _drm_driver;
>> - return drm_mipi_dbi_panel_register(>panel, >dbidev,
>> driver,
>> - ili->conf->mode, rotation);
>> + port = of_get_child_by_name(dev->of_node, "port");
>> + if (port) {
>> + of_node_put(port);
>> + ili->use_dpi = true;
>> + }
>> +
>> + if (ili->conf->no_dpi)
>> + ili->use_dpi = false;
>
> then this can just be ili->use_dpi = ili->conf->use_dpi.
>
>> +
>> + if (ili->use_dpi) {
>> + ret = drm_panel_add(>panel);
>> + } else {
>> + if (ili->conf == _data)
>> + driver = _drm_driver;
>> + else
>> + driver = _drm_driver;
>> +
>> + ret = drm_mipi_dbi_panel_register(>panel, >dbidev,
>> driver,
>> + ili->conf->mode, rotation);
>> + }
>> +
>> + return ret;
>> }
>> static int ili9341_remove(struct spi_device *spi)
>> {
>> struct ili9341 *ili = spi_get_drvdata(spi);
>> - drm_dev_unplug(>dbidev.drm);
>> - drm_atomic_helper_shutdown(>dbidev.drm);
>> + if (ili->use_dpi) {
>> + drm_panel_remove(>panel);
>> + drm_panel_disable(>panel);
>> + drm_panel_unprepare(>panel);
>> + kfree(ili);
>> + } else {
>> + drm_dev_unplug(>dbidev.drm);
>> + drm_atomic_helper_shutdown(>dbidev.drm);
>> + }
>> return 0;
>> }
>> @@ -380,21 +409,26 @@ static void ili9341_shutdown(struct spi_device
>> *spi)
>> {
>> struct ili9341 *ili = spi_get_drvdata(spi);
>> - drm_atomic_helper_shutdown(>dbidev.drm);
>> + if (!ili->use_dpi)
>> + drm_atomic_helper_shutdown(>dbidev.drm);
>> }
>> static int __maybe_unused ili9341_pm_suspend(struct device *dev)
>> {
>> struct ili9341 *ili = dev_get_drvdata(dev);
>> - return drm_mode_config_helper_suspend(>dbidev.drm);
>> + if (!ili->use_dpi)
>> + return drm_mode_config_helper_suspend(>dbidev.drm);
>> +
>> + return 0;
>> }
>> static int __maybe_unused ili9341_pm_resume(struct device *dev)
>> {
>> struct ili9341 *ili = dev_get_drvdata(dev);
>> - drm_mode_config_helper_resume(>dbidev.drm);
>> + if (!ili->use_dpi)
>> + drm_mode_config_helper_resume(>dbidev.drm);
>> return 0;
>> }
>>
>
___
dri-devel
Re: drm/komeda: Add support for generation of CRC data per frame.
On Fri, Aug 02, 2019 at 10:13:03AM +, Brian Starkey wrote:
> Hi Daniel,
>
> On Fri, Aug 02, 2019 at 11:52:11AM +0200, Daniel Vetter wrote:
> > On Fri, Aug 2, 2019 at 11:39 AM Brian Starkey wrote:
> > >
> > > Hi Liviu,
> > >
> > > On Thu, Aug 01, 2019 at 11:42:31AM +0100, Liviu Dudau wrote:
> > > > Komeda has support to generate per-frame CRC values in the DOU
> > > > backend subsystem. Implement necessary hooks to expose the CRC
> > > > "control" and "data" file over debugfs and program the DOUx_BS
> > > > accordingly.
> > > >
> > > > This patch makes use of PL1 (programmable line 1) interrupt to
> > > > know when the CRC generation has finished.
> > > >
> > > > Patch is also dependent on the series that adds dual-link support
> > > > for komeda: https://patchwork.freedesktop.org/series/62280/
> > > >
> > > > Cc: "james qian wang (Arm Technology China)"
> > > > Signed-off-by: Liviu Dudau
> > > > ---
> > > > .../arm/display/komeda/d71/d71_component.c| 2 +-
> > > > .../gpu/drm/arm/display/komeda/d71/d71_dev.c | 29 -
> > > > .../gpu/drm/arm/display/komeda/komeda_crtc.c | 61 ++-
> > > > .../gpu/drm/arm/display/komeda/komeda_dev.h | 2 +
> > > > .../gpu/drm/arm/display/komeda/komeda_kms.h | 3 +
> > > > .../drm/arm/display/komeda/komeda_pipeline.h | 1 +
> > > > 6 files changed, 94 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> > > > b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> > > > index 55a8cc94808a1..3c45468848ee4 100644
> > > > --- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> > > > +++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> > > > @@ -1061,7 +1061,7 @@ static void d71_timing_ctrlr_update(struct
> > > > komeda_component *c,
> > > > malidp_write32(reg, BS_PREFETCH_LINE, D71_DEFAULT_PREPRETCH_LINE);
> > > >
> > > > /* configure bs control register */
> > > > - value = BS_CTRL_EN | BS_CTRL_VM;
> > > > + value = BS_CTRL_EN | BS_CTRL_VM | BS_CTRL_CRC;
> > > > if (c->pipeline->dual_link) {
> > > > malidp_write32(reg, BS_DRIFT_TO, hfront_porch + 16);
> > > > value |= BS_CTRL_DL;
> > > > diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
> > > > b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
> > > > index d567ab7ed314e..05bfd9891c540 100644
> > > > --- a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
> > > > +++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
> > > > @@ -115,6 +115,8 @@ static u64 get_dou_event(struct d71_pipeline
> > > > *d71_pipeline)
> > > > raw_status = malidp_read32(reg, BLK_IRQ_RAW_STATUS);
> > > > if (raw_status & DOU_IRQ_PL0)
> > > > evts |= KOMEDA_EVENT_VSYNC;
> > > > + if (raw_status & DOU_IRQ_PL1)
> > > > + evts |= KOMEDA_EVENT_CRCDONE;
> > > > if (raw_status & DOU_IRQ_UND)
> > > > evts |= KOMEDA_EVENT_URUN;
> > > >
> > > > @@ -149,7 +151,7 @@ static u64 get_dou_event(struct d71_pipeline
> > > > *d71_pipeline)
> > > >
> > > > static u64 get_pipeline_event(struct d71_pipeline *d71_pipeline, u32
> > > > gcu_status)
> > > > {
> > > > - u32 evts = 0ULL;
> > > > + u64 evts = 0ULL;
> > > >
> > > > if (gcu_status & (GLB_IRQ_STATUS_LPU0 | GLB_IRQ_STATUS_LPU1))
> > > > evts |= get_lpu_event(d71_pipeline);
> > > > @@ -163,6 +165,26 @@ static u64 get_pipeline_event(struct d71_pipeline
> > > > *d71_pipeline, u32 gcu_status)
> > > > return evts;
> > > > }
> > > >
> > > > +static void get_frame_crcs(struct d71_pipeline *d71_pipeline, u32 pipe,
> > > > +struct komeda_events *evts)
> > > > +{
> > > > + if (evts->pipes[pipe] & KOMEDA_EVENT_CRCDONE) {
> > > > + struct komeda_component *c;
> > > > +
> > > > + c = komeda_pipeline_get_component(_pipeline->base,
> > > > +
> > > > KOMEDA_COMPONENT_TIMING_CTRLR);
> > > > + if (!c)
> > > > + return;
> > > > +
> > > > + evts->crcs[pipe][0] = malidp_read32(c->reg, BS_CRC0_LOW);
> > > > + evts->crcs[pipe][1] = malidp_read32(c->reg, BS_CRC0_HIGH);
> > > > + if (d71_pipeline->base.dual_link) {
> > > > + evts->crcs[pipe][2] = malidp_read32(c->reg,
> > > > BS_CRC1_LOW);
> > > > + evts->crcs[pipe][3] = malidp_read32(c->reg,
> > > > BS_CRC1_HIGH);
> > > > + }
> > > > + }
> > > > +}
> > > > +
> > > > static irqreturn_t
> > > > d71_irq_handler(struct komeda_dev *mdev, struct komeda_events *evts)
> > > > {
> > > > @@ -195,6 +217,9 @@ d71_irq_handler(struct komeda_dev *mdev, struct
> > > > komeda_events *evts)
> > > > if (gcu_status & GLB_IRQ_STATUS_PIPE1)
> > > > evts->pipes[1] |= get_pipeline_event(d71->pipes[1],
> > > > gcu_status);
> > > >
> > > > + get_frame_crcs(d71->pipes[0],
Re: [PATCH v1 2/2] drm: Clear the fence pointer when writeback job signaled
On Fri, Aug 02, 2019 at 10:09:05AM +, Brian Starkey wrote: > Hi Daniel, > > On Fri, Aug 02, 2019 at 11:45:13AM +0200, Daniel Vetter wrote: > > On Fri, Aug 2, 2019 at 11:43 AM Daniel Vetter wrote: > > > > > > On Fri, Aug 2, 2019 at 11:29 AM Brian Starkey > > > wrote: > > > > > > > > Hi Lowry, > > > > > > > > On Thu, Aug 01, 2019 at 06:34:08AM +, Lowry Li (Arm Technology > > > > China) wrote: > > > > > Hi Brian, > > > > > > > > > > On Wed, Jul 31, 2019 at 09:20:04PM +0800, Brian Starkey wrote: > > > > > > Hi Lowry, > > > > > > > > > > > > Thanks for this cleanup. > > > > > > > > > > > > On Wed, Jul 31, 2019 at 11:04:45AM +, Lowry Li (Arm Technology > > > > > > China) wrote: > > > > > > > During it signals the completion of a writeback job, after > > > > > > > releasing > > > > > > > the out_fence, we'd clear the pointer. > > > > > > > > > > > > > > Check if fence left over in drm_writeback_cleanup_job(), release > > > > > > > it. > > > > > > > > > > > > > > Signed-off-by: Lowry Li (Arm Technology China) > > > > > > > --- > > > > > > > drivers/gpu/drm/drm_writeback.c | 23 +++ > > > > > > > 1 file changed, 15 insertions(+), 8 deletions(-) > > > > > > > > > > > > > > diff --git a/drivers/gpu/drm/drm_writeback.c > > > > > > > b/drivers/gpu/drm/drm_writeback.c > > > > > > > index ff138b6..43d9e3b 100644 > > > > > > > --- a/drivers/gpu/drm/drm_writeback.c > > > > > > > +++ b/drivers/gpu/drm/drm_writeback.c > > > > > > > @@ -324,6 +324,9 @@ void drm_writeback_cleanup_job(struct > > > > > > > drm_writeback_job *job) > > > > > > > if (job->fb) > > > > > > > drm_framebuffer_put(job->fb); > > > > > > > > > > > > > > + if (job->out_fence) > > > > > > > > > > > > I'm thinking it might be a good idea to signal the fence with an > > > > > > error > > > > > > here, if it's not already signaled. Otherwise, if there's someone > > > > > > waiting (which there shouldn't be), they're going to be waiting a > > > > > > very > > > > > > long time :-) > > > > > > > > > > > > Thanks, > > > > > > -Brian > > > > > > > > > > > Here it happened at atomic_check failed and test only commit. For both > > > > > cases, the commit has been dropped and it's only a clean up. So here > > > > > better > > > > > not be treated as an error case:) > > > > > > > > If anyone else has a reference on the fence, then IMO it absolutely is > > > > an error to reach this point without the fence being signaled - > > > > because it means that the fence will never be signaled. > > > > > > > > I don't think the API gives you a way to check if this is the last > > > > reference, so it's safest to just make sure the fence is signalled > > > > before dropping the reference. > > > > > > > > It just feels wrong to me to have the possibility of a dangling fence > > > > which is never going to get signalled; and it's an easy defensive step > > > > to make sure it can never happen. > > > > > > > > I know it _shouldn't_ happen, but we often put in handling for cases > > > > which shouldn't happen, because they frequently do happen :-) > > > > > > We're not as paranoid with the vblank fences either, so not sure why > > > we need to be this paranoid with writeback fences. If your driver > > > grabs anything from the atomic state in ->atomic_check it's buggy > > > anyway. > > > > > > If you want to fix this properly I think we need to move the call to > > > prepare_signalling() in between atomic_check and atomic_commit. Then I > > > think it makes sense to also force-complete the fence on error ... > > Well, fair enough. I'm struggling with "that's too paranoid" vs "fix > it properly" though? Is it a "problem" worth fixing or not? Up to you to decide that. > It seems natural to me to do the fence cleanup in the cleanup function > for the object which owns the fence. > > > > > > > > > Since for userspace, it should have been failed or a test only case, > > > > > so > > > > > writebace fence should not be signaled. > > > > > > > > It's not only userspace that can wait on fences (and in fact this > > > > fence will never even reach userspace if the commit fails), the driver > > > > may have taken a copy to use for "something". > > > > I forgot to add: you can check this by looking at the fence reference > > count. A WARN_ON if that's more than 1 on cleanup (but also for the > > out fences) could be a nice addition. > > Do we really want to be looking at the fence internals directly like > that? Wrap it up in a helper like dma_fence_release_private or whatever, which combines the check and (hopefully final) _put(). Might need a better name. -Daniel > > Cheers, > -Brian > > > -Daniel > > -- > > Daniel Vetter > > Software Engineer, Intel Corporation > > +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH 2/2] i915: do not leak module ref counter
Quoting Sergey Senozhatsky (2019-08-02 14:49:55)
> On (08/02/19 14:41), Chris Wilson wrote:
> [..]
> > struct vfsmount *kern_mount(struct file_system_type *type)
> > {
> > struct vfsmount *mnt;
> > mnt = vfs_kern_mount(type, SB_KERNMOUNT, type->name, NULL);
> > if (!IS_ERR(mnt)) {
> > /*
> > * it is a longterm mount, don't release mnt until
> > * we unmount before file sys is unregistered
> > */
> > real_mount(mnt)->mnt_ns = MNT_NS_INTERNAL;
> > }
> > return mnt;
> > }
> >
> > With the exception of fiddling with MNT_NS_INTERNAL, it seems
> > amenable for our needs.
>
> Sorry, not sure I understand. i915 use kern_mount() at the moment.
>
> Since we still need to put_filesystem(), I'd probably add one more
> patch
> - export put_filesystem()
>
> so then we can put_filesystem() in i915. Wonder what would happen
> if someone would do
> modprobe i915
> rmmod i916
> In a loop.
>
> So something like this (this is against current patch set).
Yes, that's what I in mind. I was thinking of whether we can replace our
kern_mount + fc->ops->reconfigure() into a single vfs_kern_mount(), and
whether or not that works with get_fs_type("tmpfs").
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] i915: do not leak module ref counter
On (08/02/19 14:41), Chris Wilson wrote:
[..]
> struct vfsmount *kern_mount(struct file_system_type *type)
> {
> struct vfsmount *mnt;
> mnt = vfs_kern_mount(type, SB_KERNMOUNT, type->name, NULL);
> if (!IS_ERR(mnt)) {
> /*
> * it is a longterm mount, don't release mnt until
> * we unmount before file sys is unregistered
> */
> real_mount(mnt)->mnt_ns = MNT_NS_INTERNAL;
> }
> return mnt;
> }
>
> With the exception of fiddling with MNT_NS_INTERNAL, it seems
> amenable for our needs.
Sorry, not sure I understand. i915 use kern_mount() at the moment.
Since we still need to put_filesystem(), I'd probably add one more
patch
- export put_filesystem()
so then we can put_filesystem() in i915. Wonder what would happen
if someone would do
modprobe i915
rmmod i916
In a loop.
So something like this (this is against current patch set).
---
drivers/gpu/drm/i915/gem/i915_gemfs.c | 5 ++---
fs/filesystems.c | 2 +-
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gemfs.c
b/drivers/gpu/drm/i915/gem/i915_gemfs.c
index d437188d1736..4ea7a6f750f4 100644
--- a/drivers/gpu/drm/i915/gem/i915_gemfs.c
+++ b/drivers/gpu/drm/i915/gem/i915_gemfs.c
@@ -24,10 +24,9 @@ int i915_gemfs_init(struct drm_i915_private *i915)
return -ENODEV;
gemfs = kern_mount(type);
- if (IS_ERR(gemfs)) {
- put_filesystem(type);
+ put_filesystem(type);
+ if (IS_ERR(gemfs))
return PTR_ERR(gemfs);
- }
/*
* Enable huge-pages for objects that are at least HPAGE_PMD_SIZE, most
diff --git a/fs/filesystems.c b/fs/filesystems.c
index 9135646e41ac..4837eda748b5 100644
--- a/fs/filesystems.c
+++ b/fs/filesystems.c
@@ -45,6 +45,7 @@ void put_filesystem(struct file_system_type *fs)
{
module_put(fs->owner);
}
+EXPORT_SYMBOL(put_filesystem);
static struct file_system_type **find_filesystem(const char *name, unsigned
len)
{
@@ -280,5 +281,4 @@ struct file_system_type *get_fs_type(const char *name)
}
return fs;
}
-
EXPORT_SYMBOL(get_fs_type);
Re: [Intel-gfx] [PATCH v1 02/11] drm: drop uapi dependency from drm_print.h
On Mon, 29 Jul 2019, Sam Ravnborg wrote:
> Hi Christian.
>
> On Mon, Jul 29, 2019 at 03:28:15PM +, Koenig, Christian wrote:
>> Am 29.07.19 um 16:35 schrieb Sam Ravnborg:
>> Even then it so useless (which drm driver is this message for???) that I
>> want to remove them all :(
>> >>> Yeah, agree. I mean it is nice if the core drm functions use a prefix
>> >>> for debug output.
>> >>>
>> >>> But I actually don't see the point for individual drivers.
>> >> We should all migrate to the versions with device...
>> > Just to do an xkdc.com/927 I have considered:
>> >
>> > drm_err(const struct drm_device *drm, ...)
>> > drm_info(const struct drm_device *drm, ...)
>> >
>> > drm_kms_err(const struct drm_device *drm, ...)
>> > drm_kms_info(const struct drm_device *drm, ...))
>>
>> Why not get completely rid of those and just use dev_err, dev_warn,
>> pr_err, pr_warn etc?
>>
>> I mean is it useful to have this extra printing subsystem in DRM while
>> the standard Linux one actually does a better job?
> The added functionality of drm_xxx_err would be to keep the current
> drm.debug=0x1f filtering on the command-line.
> I do not think we can do this with the standard logging.
Correct. I'd love the benefits of dynamic debug, but there's no support
for the kind of message categories that we do with drm.debug.
I've contemplated switching i915 over to using the variants where you
pass the device, but I really really don't like the idea of:
- DRM_DEBUG_KMS("hello\n");
+ DRM_DEV_DEBUG_KMS(i915->drm.dev, "hello\n");
Where i915 is our private wrapper for drm_device. I think it's just too
much ugly uppercase boilerplate, and a large portion of the debugs would
have to span at least an extra line after that.
I'd also very much prefer passing just struct *drm_device instead of
struct *device. In that, I think the needs of the few have prevailed
over the needs of the many. I'd definitely prefer drm_err(const struct
drm_device *drm, ...) and friends over the current ones.
Frankly, I've actually ended up thinking about adding our own, short
i915 wrappers for our needs. :(
BR,
Jani.
>
> And then we can prefix every logging with driver name and device name.
>
> The idea is to make a thin layer on top of the existing pr_xxx() functions.
> So not a full subsystem, only a wrapper on top of what we already have.
>
> Anyway, idle talk only. We need patches and sample output if we should
> discuss more.
>
> Sam
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-misc-fixes
Hey, Bit late, but fixes for v5.3-rc3. :) drm-misc-fixes-2019-08-02: drm-misc-fixes for v5.3-rc3: - Fix some build errors in drm/bridge. - Do not build i810 on CONFIG_PREEMPTION. - Fix cache sync on arm in vgem. - Allow mapping fb in drm_client only when required, and use it to fix bochs fbdev. The following changes since commit 609488bc979f99f805f34e9a32c1e3b71179d10b: Linux 5.3-rc2 (2019-07-28 12:47:02 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2019-08-02 for you to fetch changes up to 58540594570778fd149cd8c9b2bff61f2cefa8c9: drm/bochs: Use shadow buffer for bochs framebuffer console (2019-08-01 15:01:42 +0200) drm-misc-fixes for v5.3-rc3: - Fix some build errors in drm/bridge. - Do not build i810 on CONFIG_PREEMPTION. - Fix cache sync on arm in vgem. - Allow mapping fb in drm_client only when required, and use it to fix bochs fbdev. Maarten Lankhorst (1): Merge tag 'v5.3-rc2' into drm-misc-fixes Rob Clark (1): drm/vgem: fix cache synchronization on arm/arm64 Thomas Gleixner (1): drm/i810: Use CONFIG_PREEMPTION Thomas Zimmermann (4): drm/client: Support unmapping of DRM client buffers drm/fb-helper: Map DRM client buffer only when required drm/fb-helper: Instanciate shadow FB if configured in device's mode_config drm/bochs: Use shadow buffer for bochs framebuffer console YueHaibing (2): drm/bridge: lvds-encoder: Fix build error while CONFIG_DRM_KMS_HELPER=m drm/bridge: tc358764: Fix build error drivers/gpu/drm/Kconfig | 2 +- drivers/gpu/drm/bochs/bochs_kms.c | 1 + drivers/gpu/drm/bridge/Kconfig| 4 +- drivers/gpu/drm/drm_client.c | 60 ++ drivers/gpu/drm/drm_fb_helper.c | 51 +++ drivers/gpu/drm/vgem/vgem_drv.c | 130 -- include/drm/drm_client.h | 2 + include/drm/drm_mode_config.h | 7 ++ 8 files changed, 186 insertions(+), 71 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] i915: do not leak module ref counter
Quoting Sergey Senozhatsky (2019-08-02 14:35:03)
> On (08/02/19 22:15), Sergey Senozhatsky wrote:
> [..]
> > > > Looking around, it looks like we always need to drop type after
> > > > mounting. Should the
> > > > put_filesystem(type);
> > > > be here instead?
> > > >
> > > > Anyway, nice catch.
> > >
> > > Sigh. put_filesystem() is part of fs internals. I'd be tempted to add
> >
> > Good catch!
> >
> > So we can switch to vfs_kern_mount(), I guess, but pass different options,
> > depending on has_transparent_hugepage().
>
> Hmm. This doesn't look exactly right. It appears that vfs_kern_mount()
> has a slightly different purpose. It's for drivers which register their
> own fstype and fs_context/sb callbacks. A typical usage would be
>
> static struct file_system_type nfsd_fs_type = {
> .owner→ → = THIS_MODULE,
> .name→ → = "nfsd",
> .init_fs_context = nfsd_init_fs_context,
> .kill_sb→ = nfsd_umount,
> };
> MODULE_ALIAS_FS("nfsd");
>
> vfs_kern_mount(_fs_type, SB_KERNMOUNT, "nfsd", NULL);
>
> i915 is a different beast, it just wants to mount fs and reconfigure
> it, it doesn't want to be an fs. So it seems that current kern_mount()
> is actually right.
struct vfsmount *kern_mount(struct file_system_type *type)
{
struct vfsmount *mnt;
mnt = vfs_kern_mount(type, SB_KERNMOUNT, type->name, NULL);
if (!IS_ERR(mnt)) {
/*
* it is a longterm mount, don't release mnt until
* we unmount before file sys is unregistered
*/
real_mount(mnt)->mnt_ns = MNT_NS_INTERNAL;
}
return mnt;
}
With the exception of fiddling with MNT_NS_INTERNAL, it seems
amenable for our needs.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/8] drm/etnaviv: split out cmdbuf mapping into address space
Hi Lucas,
On Fri, Jul 05, 2019 at 07:17:21PM +0200, Lucas Stach wrote:
> This allows to decouple the cmdbuf suballocator create and mapping
> the region into the GPU address space. Allowing multiple AS to share
> a single cmdbuf suballoc.
Can you tell me where this would apply? I tried 5.2 and next-20190726
with and without
[PATCH 1/2] drm/etnaviv: fix etnaviv_cmdbuf_suballoc_new return value
applied.
Cheers,
-- Guido
> Signed-off-by: Lucas Stach
> ---
> drivers/gpu/drm/etnaviv/etnaviv_buffer.c | 23
> drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c | 35 ++--
> drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.h | 11 +++-
> drivers/gpu/drm/etnaviv/etnaviv_dump.c | 6 +-
> drivers/gpu/drm/etnaviv/etnaviv_gpu.c| 19 +--
> drivers/gpu/drm/etnaviv/etnaviv_gpu.h| 3 +-
> drivers/gpu/drm/etnaviv/etnaviv_mmu.c| 70 +++-
> drivers/gpu/drm/etnaviv/etnaviv_mmu.h| 12 ++--
> 8 files changed, 114 insertions(+), 65 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
> b/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
> index fe0d2d67007d..6400a88cd778 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
> @@ -118,7 +118,8 @@ static void etnaviv_buffer_dump(struct etnaviv_gpu *gpu,
> u32 *ptr = buf->vaddr + off;
>
> dev_info(gpu->dev, "virt %p phys 0x%08x free 0x%08x\n",
> - ptr, etnaviv_cmdbuf_get_va(buf) + off, size - len * 4 -
> off);
> + ptr, etnaviv_cmdbuf_get_va(buf, >cmdbuf_mapping) +
> + off, size - len * 4 - off);
>
> print_hex_dump(KERN_INFO, "cmd ", DUMP_PREFIX_OFFSET, 16, 4,
> ptr, len * 4, 0);
> @@ -151,7 +152,8 @@ static u32 etnaviv_buffer_reserve(struct etnaviv_gpu *gpu,
> if (buffer->user_size + cmd_dwords * sizeof(u64) > buffer->size)
> buffer->user_size = 0;
>
> - return etnaviv_cmdbuf_get_va(buffer) + buffer->user_size;
> + return etnaviv_cmdbuf_get_va(buffer, >cmdbuf_mapping) +
> +buffer->user_size;
> }
>
> u16 etnaviv_buffer_init(struct etnaviv_gpu *gpu)
> @@ -164,8 +166,8 @@ u16 etnaviv_buffer_init(struct etnaviv_gpu *gpu)
> buffer->user_size = 0;
>
> CMD_WAIT(buffer);
> - CMD_LINK(buffer, 2, etnaviv_cmdbuf_get_va(buffer) +
> - buffer->user_size - 4);
> + CMD_LINK(buffer, 2, etnaviv_cmdbuf_get_va(buffer, >cmdbuf_mapping)
> + + buffer->user_size - 4);
>
> return buffer->user_size / 8;
> }
> @@ -291,8 +293,8 @@ void etnaviv_sync_point_queue(struct etnaviv_gpu *gpu,
> unsigned int event)
>
> /* Append waitlink */
> CMD_WAIT(buffer);
> - CMD_LINK(buffer, 2, etnaviv_cmdbuf_get_va(buffer) +
> - buffer->user_size - 4);
> + CMD_LINK(buffer, 2, etnaviv_cmdbuf_get_va(buffer, >cmdbuf_mapping)
> + + buffer->user_size - 4);
>
> /*
>* Kick off the 'sync point' command by replacing the previous
> @@ -319,7 +321,7 @@ void etnaviv_buffer_queue(struct etnaviv_gpu *gpu, u32
> exec_state,
> if (drm_debug & DRM_UT_DRIVER)
> etnaviv_buffer_dump(gpu, buffer, 0, 0x50);
>
> - link_target = etnaviv_cmdbuf_get_va(cmdbuf);
> + link_target = etnaviv_cmdbuf_get_va(cmdbuf, >cmdbuf_mapping);
> link_dwords = cmdbuf->size / 8;
>
> /*
> @@ -412,12 +414,13 @@ void etnaviv_buffer_queue(struct etnaviv_gpu *gpu, u32
> exec_state,
> CMD_LOAD_STATE(buffer, VIVS_GL_EVENT, VIVS_GL_EVENT_EVENT_ID(event) |
> VIVS_GL_EVENT_FROM_PE);
> CMD_WAIT(buffer);
> - CMD_LINK(buffer, 2, etnaviv_cmdbuf_get_va(buffer) +
> - buffer->user_size - 4);
> + CMD_LINK(buffer, 2, etnaviv_cmdbuf_get_va(buffer, >cmdbuf_mapping)
> + + buffer->user_size - 4);
>
> if (drm_debug & DRM_UT_DRIVER)
> pr_info("stream link to 0x%08x @ 0x%08x %p\n",
> - return_target, etnaviv_cmdbuf_get_va(cmdbuf),
> + return_target,
> + etnaviv_cmdbuf_get_va(cmdbuf, >cmdbuf_mapping),
> cmdbuf->vaddr);
>
> if (drm_debug & DRM_UT_DRIVER) {
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c
> b/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c
> index 7b77992f31c4..8915d9d056a6 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c
> @@ -8,6 +8,7 @@
> #include
>
> #include "etnaviv_cmdbuf.h"
> +#include "etnaviv_gem.h"
> #include "etnaviv_gpu.h"
> #include "etnaviv_mmu.h"
>
> @@ -21,10 +22,6 @@ struct etnaviv_cmdbuf_suballoc {
> void *vaddr;
> dma_addr_t paddr;
>
> - /* GPU mapping */
> - u32 iova;
> - struct drm_mm_node vram_node; /* only used on MMUv2 */
> -
> /* allocation management */
> struct mutex lock;
> DECLARE_BITMAP(granule_map, SUBALLOC_GRANULES);
> @@
Re: [PULL] drm-intel-fixes
Hi, > I apologize for not having fixes for a couple of weeks, and then showing > up late with a bunch of them. I saw Dave make the fixes pull to Linus > for -rc3 already, but I must humbly ask you to accommodate an extra > fixes pull. If there is an extra -rc3 fixes pull anyway it would be nice to also pick up the drm-misc-fixes patches to unbreak qemu stdvga fbcon. thanks, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] i915: do not leak module ref counter
On (08/02/19 22:15), Sergey Senozhatsky wrote:
[..]
> > > Looking around, it looks like we always need to drop type after
> > > mounting. Should the
> > > put_filesystem(type);
> > > be here instead?
> > >
> > > Anyway, nice catch.
> >
> > Sigh. put_filesystem() is part of fs internals. I'd be tempted to add
>
> Good catch!
>
> So we can switch to vfs_kern_mount(), I guess, but pass different options,
> depending on has_transparent_hugepage().
Hmm. This doesn't look exactly right. It appears that vfs_kern_mount()
has a slightly different purpose. It's for drivers which register their
own fstype and fs_context/sb callbacks. A typical usage would be
static struct file_system_type nfsd_fs_type = {
.owner→ → = THIS_MODULE,
.name→ → = "nfsd",
.init_fs_context = nfsd_init_fs_context,
.kill_sb→ = nfsd_umount,
};
MODULE_ALIAS_FS("nfsd");
vfs_kern_mount(_fs_type, SB_KERNMOUNT, "nfsd", NULL);
i915 is a different beast, it just wants to mount fs and reconfigure
it, it doesn't want to be an fs. So it seems that current kern_mount()
is actually right.
Maybe we need to export put_filesystem() instead.
-ss
[Bug 111244] amdgpu kernel 5.2 blank display after resume from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=111244 Samuele Decarli changed: What|Removed |Added See Also||https://bugs.freedesktop.or ||g/show_bug.cgi?id=22 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111122] 2500U: Graphics corruption on kernel 5.2
https://bugs.freedesktop.org/show_bug.cgi?id=22 Samuele Decarli changed: What|Removed |Added See Also||https://bugs.freedesktop.or ||g/show_bug.cgi?id=111244 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111244] amdgpu kernel 5.2 blank display after resume from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=111244 --- Comment #10 from Samuele Decarli --- Interestingly the same commit is blamed for anther issue https://bugs.freedesktop.org/show_bug.cgi?id=22 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.9 07/22] drm/msm: stop abusing dma_map/unmap for cache
From: Rob Clark
[ Upstream commit 0036bc73ccbe7e600a3468bf8e8879b122252274 ]
Recently splats like this started showing up:
WARNING: CPU: 4 PID: 251 at drivers/iommu/dma-iommu.c:451
__iommu_dma_unmap+0xb8/0xc0
Modules linked in: ath10k_snoc ath10k_core fuse msm ath mac80211 uvcvideo
cfg80211 videobuf2_vmalloc videobuf2_memops vide
CPU: 4 PID: 251 Comm: kworker/u16:4 Tainted: GW
5.2.0-rc5-next-20190619+ #2317
Hardware name: LENOVO 81JL/LNVNB161216, BIOS 9UCN23WW(V1.06) 10/25/2018
Workqueue: msm msm_gem_free_work [msm]
pstate: 80c5 (Nzcv daif +PAN +UAO)
pc : __iommu_dma_unmap+0xb8/0xc0
lr : __iommu_dma_unmap+0x54/0xc0
sp : 119abce0
x29: 119abce0 x28:
x27: 8001f9946648 x26: 8001ec271068
x25: x24: 8001ea3580a8
x23: 8001f95ba010 x22: 80018e83ba88
x21: 8001e548f000 x20: f000
x19: 1000 x18: c1fe
x17: x16:
x15: 15b70068 x14: 0005
x13: 0003142cc1be1768 x12: 0001
x11: 8001f6de9100 x10: 0009
x9 : 15b78000 x8 :
x7 : 0001 x6 : f000
x5 : 0fff x4 : 1065dbc8
x3 : 000d x2 : 1000
x1 : f000 x0 :
Call trace:
__iommu_dma_unmap+0xb8/0xc0
iommu_dma_unmap_sg+0x98/0xb8
put_pages+0x5c/0xf0 [msm]
msm_gem_free_work+0x10c/0x150 [msm]
process_one_work+0x1e0/0x330
worker_thread+0x40/0x438
kthread+0x12c/0x130
ret_from_fork+0x10/0x18
---[ end trace afc0dc5ab81a06bf ]---
Not quite sure what triggered that, but we really shouldn't be abusing
dma_{map,unmap}_sg() for cache maint.
Cc: Stephen Boyd
Tested-by: Stephen Boyd
Reviewed-by: Jordan Crouse
Signed-off-by: Rob Clark
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20190630124735.27786-1-robdcl...@gmail.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/msm/msm_gem.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 795660e29b2ce..a472d4d902dde 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -106,7 +106,7 @@ static struct page **get_pages(struct drm_gem_object *obj)
* because display controller, GPU, etc. are not coherent:
*/
if (msm_obj->flags & (MSM_BO_WC|MSM_BO_UNCACHED))
- dma_map_sg(dev->dev, msm_obj->sgt->sgl,
+ dma_sync_sg_for_device(dev->dev, msm_obj->sgt->sgl,
msm_obj->sgt->nents, DMA_BIDIRECTIONAL);
}
@@ -124,7 +124,7 @@ static void put_pages(struct drm_gem_object *obj)
* GPU, etc. are not coherent:
*/
if (msm_obj->flags & (MSM_BO_WC|MSM_BO_UNCACHED))
- dma_unmap_sg(obj->dev->dev, msm_obj->sgt->sgl,
+ dma_sync_sg_for_cpu(obj->dev->dev,
msm_obj->sgt->sgl,
msm_obj->sgt->nents,
DMA_BIDIRECTIONAL);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.14 12/30] drm: silence variable 'conn' set but not used
From: Qian Cai [ Upstream commit bbb6fc43f131f77fcb7ae8081f6d7c51396a2120 ] The "struct drm_connector" iteration cursor from "for_each_new_connector_in_state" is never used in atomic_remove_fb() which generates a compilation warning, drivers/gpu/drm/drm_framebuffer.c: In function 'atomic_remove_fb': drivers/gpu/drm/drm_framebuffer.c:838:24: warning: variable 'conn' set but not used [-Wunused-but-set-variable] Silence it by marking "conn" __maybe_unused. Signed-off-by: Qian Cai Signed-off-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/1563822886-13570-1-git-send-email-...@lca.pw Signed-off-by: Sasha Levin --- drivers/gpu/drm/drm_framebuffer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_framebuffer.c b/drivers/gpu/drm/drm_framebuffer.c index c21e10c780ac5..af40189cdb60c 100644 --- a/drivers/gpu/drm/drm_framebuffer.c +++ b/drivers/gpu/drm/drm_framebuffer.c @@ -773,7 +773,7 @@ static int atomic_remove_fb(struct drm_framebuffer *fb) struct drm_device *dev = fb->dev; struct drm_atomic_state *state; struct drm_plane *plane; - struct drm_connector *conn; + struct drm_connector *conn __maybe_unused; struct drm_connector_state *conn_state; int i, ret = 0; unsigned plane_mask; -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.14 11/30] drm/msm: stop abusing dma_map/unmap for cache
From: Rob Clark
[ Upstream commit 0036bc73ccbe7e600a3468bf8e8879b122252274 ]
Recently splats like this started showing up:
WARNING: CPU: 4 PID: 251 at drivers/iommu/dma-iommu.c:451
__iommu_dma_unmap+0xb8/0xc0
Modules linked in: ath10k_snoc ath10k_core fuse msm ath mac80211 uvcvideo
cfg80211 videobuf2_vmalloc videobuf2_memops vide
CPU: 4 PID: 251 Comm: kworker/u16:4 Tainted: GW
5.2.0-rc5-next-20190619+ #2317
Hardware name: LENOVO 81JL/LNVNB161216, BIOS 9UCN23WW(V1.06) 10/25/2018
Workqueue: msm msm_gem_free_work [msm]
pstate: 80c5 (Nzcv daif +PAN +UAO)
pc : __iommu_dma_unmap+0xb8/0xc0
lr : __iommu_dma_unmap+0x54/0xc0
sp : 119abce0
x29: 119abce0 x28:
x27: 8001f9946648 x26: 8001ec271068
x25: x24: 8001ea3580a8
x23: 8001f95ba010 x22: 80018e83ba88
x21: 8001e548f000 x20: f000
x19: 1000 x18: c1fe
x17: x16:
x15: 15b70068 x14: 0005
x13: 0003142cc1be1768 x12: 0001
x11: 8001f6de9100 x10: 0009
x9 : 15b78000 x8 :
x7 : 0001 x6 : f000
x5 : 0fff x4 : 1065dbc8
x3 : 000d x2 : 1000
x1 : f000 x0 :
Call trace:
__iommu_dma_unmap+0xb8/0xc0
iommu_dma_unmap_sg+0x98/0xb8
put_pages+0x5c/0xf0 [msm]
msm_gem_free_work+0x10c/0x150 [msm]
process_one_work+0x1e0/0x330
worker_thread+0x40/0x438
kthread+0x12c/0x130
ret_from_fork+0x10/0x18
---[ end trace afc0dc5ab81a06bf ]---
Not quite sure what triggered that, but we really shouldn't be abusing
dma_{map,unmap}_sg() for cache maint.
Cc: Stephen Boyd
Tested-by: Stephen Boyd
Reviewed-by: Jordan Crouse
Signed-off-by: Rob Clark
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20190630124735.27786-1-robdcl...@gmail.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/msm/msm_gem.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index f2df718af370d..3a91ccd92c473 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -108,7 +108,7 @@ static struct page **get_pages(struct drm_gem_object *obj)
* because display controller, GPU, etc. are not coherent:
*/
if (msm_obj->flags & (MSM_BO_WC|MSM_BO_UNCACHED))
- dma_map_sg(dev->dev, msm_obj->sgt->sgl,
+ dma_sync_sg_for_device(dev->dev, msm_obj->sgt->sgl,
msm_obj->sgt->nents, DMA_BIDIRECTIONAL);
}
@@ -138,7 +138,7 @@ static void put_pages(struct drm_gem_object *obj)
* GPU, etc. are not coherent:
*/
if (msm_obj->flags & (MSM_BO_WC|MSM_BO_UNCACHED))
- dma_unmap_sg(obj->dev->dev, msm_obj->sgt->sgl,
+ dma_sync_sg_for_cpu(obj->dev->dev,
msm_obj->sgt->sgl,
msm_obj->sgt->nents,
DMA_BIDIRECTIONAL);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 10/42] drm/amd/display: Only enable audio if speaker allocation exists
From: Alvin Lee
[ Upstream commit 6ac25e6d5b2fbf251e9fa2f4131d42c815b43867 ]
[Why]
In dm_helpers_parse_edid_caps, there is a corner case where no speakers
can be allocated even though the audio mode count is greater than 0.
Enabling audio when no speaker allocations exists can cause issues in
the video stream.
[How]
Add a check to not enable audio unless one or more speaker allocations
exist (since doing this can cause issues in the video stream).
Signed-off-by: Alvin Lee
Reviewed-by: Jun Lei
Acked-by: Leo Li
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
index 19a951e5818ac..f0d68aa7c8fcc 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
@@ -1956,7 +1956,7 @@ enum dc_status resource_map_pool_resources(
/* TODO: Add check if ASIC support and EDID audio */
if (!stream->sink->converter_disable_audio &&
dc_is_audio_capable_signal(pipe_ctx->stream->signal) &&
- stream->audio_info.mode_count) {
+ stream->audio_info.mode_count && stream->audio_info.flags.all) {
pipe_ctx->stream_res.audio = find_first_free_audio(
>res_ctx, pool, pipe_ctx->stream_res.stream_enc->id);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 19/42] drm/msm: stop abusing dma_map/unmap for cache
From: Rob Clark
[ Upstream commit 0036bc73ccbe7e600a3468bf8e8879b122252274 ]
Recently splats like this started showing up:
WARNING: CPU: 4 PID: 251 at drivers/iommu/dma-iommu.c:451
__iommu_dma_unmap+0xb8/0xc0
Modules linked in: ath10k_snoc ath10k_core fuse msm ath mac80211 uvcvideo
cfg80211 videobuf2_vmalloc videobuf2_memops vide
CPU: 4 PID: 251 Comm: kworker/u16:4 Tainted: GW
5.2.0-rc5-next-20190619+ #2317
Hardware name: LENOVO 81JL/LNVNB161216, BIOS 9UCN23WW(V1.06) 10/25/2018
Workqueue: msm msm_gem_free_work [msm]
pstate: 80c5 (Nzcv daif +PAN +UAO)
pc : __iommu_dma_unmap+0xb8/0xc0
lr : __iommu_dma_unmap+0x54/0xc0
sp : 119abce0
x29: 119abce0 x28:
x27: 8001f9946648 x26: 8001ec271068
x25: x24: 8001ea3580a8
x23: 8001f95ba010 x22: 80018e83ba88
x21: 8001e548f000 x20: f000
x19: 1000 x18: c1fe
x17: x16:
x15: 15b70068 x14: 0005
x13: 0003142cc1be1768 x12: 0001
x11: 8001f6de9100 x10: 0009
x9 : 15b78000 x8 :
x7 : 0001 x6 : f000
x5 : 0fff x4 : 1065dbc8
x3 : 000d x2 : 1000
x1 : f000 x0 :
Call trace:
__iommu_dma_unmap+0xb8/0xc0
iommu_dma_unmap_sg+0x98/0xb8
put_pages+0x5c/0xf0 [msm]
msm_gem_free_work+0x10c/0x150 [msm]
process_one_work+0x1e0/0x330
worker_thread+0x40/0x438
kthread+0x12c/0x130
ret_from_fork+0x10/0x18
---[ end trace afc0dc5ab81a06bf ]---
Not quite sure what triggered that, but we really shouldn't be abusing
dma_{map,unmap}_sg() for cache maint.
Cc: Stephen Boyd
Tested-by: Stephen Boyd
Reviewed-by: Jordan Crouse
Signed-off-by: Rob Clark
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20190630124735.27786-1-robdcl...@gmail.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/msm/msm_gem.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index f59ca27a4a357..93b20ad23c23f 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -108,7 +108,7 @@ static struct page **get_pages(struct drm_gem_object *obj)
* because display controller, GPU, etc. are not coherent:
*/
if (msm_obj->flags & (MSM_BO_WC|MSM_BO_UNCACHED))
- dma_map_sg(dev->dev, msm_obj->sgt->sgl,
+ dma_sync_sg_for_device(dev->dev, msm_obj->sgt->sgl,
msm_obj->sgt->nents, DMA_BIDIRECTIONAL);
}
@@ -138,7 +138,7 @@ static void put_pages(struct drm_gem_object *obj)
* GPU, etc. are not coherent:
*/
if (msm_obj->flags & (MSM_BO_WC|MSM_BO_UNCACHED))
- dma_unmap_sg(obj->dev->dev, msm_obj->sgt->sgl,
+ dma_sync_sg_for_cpu(obj->dev->dev,
msm_obj->sgt->sgl,
msm_obj->sgt->nents,
DMA_BIDIRECTIONAL);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 20/42] drm: silence variable 'conn' set but not used
From: Qian Cai [ Upstream commit bbb6fc43f131f77fcb7ae8081f6d7c51396a2120 ] The "struct drm_connector" iteration cursor from "for_each_new_connector_in_state" is never used in atomic_remove_fb() which generates a compilation warning, drivers/gpu/drm/drm_framebuffer.c: In function 'atomic_remove_fb': drivers/gpu/drm/drm_framebuffer.c:838:24: warning: variable 'conn' set but not used [-Wunused-but-set-variable] Silence it by marking "conn" __maybe_unused. Signed-off-by: Qian Cai Signed-off-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/1563822886-13570-1-git-send-email-...@lca.pw Signed-off-by: Sasha Levin --- drivers/gpu/drm/drm_framebuffer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_framebuffer.c b/drivers/gpu/drm/drm_framebuffer.c index 781af1d42d766..b64a6ffc0aed7 100644 --- a/drivers/gpu/drm/drm_framebuffer.c +++ b/drivers/gpu/drm/drm_framebuffer.c @@ -793,7 +793,7 @@ static int atomic_remove_fb(struct drm_framebuffer *fb) struct drm_device *dev = fb->dev; struct drm_atomic_state *state; struct drm_plane *plane; - struct drm_connector *conn; + struct drm_connector *conn __maybe_unused; struct drm_connector_state *conn_state; int i, ret; unsigned plane_mask; -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 11/42] drm/amd/display: Increase size of audios array
From: Tai Man
[ Upstream commit 7352193a33dfc9b69ba3bf6a8caea925b96243b1 ]
[Why]
The audios array defined in "struct resource_pool" is only 6 (MAX_PIPES)
but the max number of audio devices (num_audio) is 7. In some projects,
it will run out of audios array.
[How]
Incraese the audios array size to 7.
Signed-off-by: Tai Man
Reviewed-by: Joshua Aberback
Acked-by: Leo Li
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/inc/core_types.h | 2 +-
drivers/gpu/drm/amd/display/dc/inc/hw/hw_shared.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/inc/core_types.h
b/drivers/gpu/drm/amd/display/dc/inc/core_types.h
index c0b9ca13393b6..f4469fa5afb55 100644
--- a/drivers/gpu/drm/amd/display/dc/inc/core_types.h
+++ b/drivers/gpu/drm/amd/display/dc/inc/core_types.h
@@ -159,7 +159,7 @@ struct resource_pool {
struct clock_source *clock_sources[MAX_CLOCK_SOURCES];
unsigned int clk_src_count;
- struct audio *audios[MAX_PIPES];
+ struct audio *audios[MAX_AUDIOS];
unsigned int audio_count;
struct audio_support audio_support;
diff --git a/drivers/gpu/drm/amd/display/dc/inc/hw/hw_shared.h
b/drivers/gpu/drm/amd/display/dc/inc/hw/hw_shared.h
index cf7433ebf91a0..71901743a9387 100644
--- a/drivers/gpu/drm/amd/display/dc/inc/hw/hw_shared.h
+++ b/drivers/gpu/drm/amd/display/dc/inc/hw/hw_shared.h
@@ -34,6 +34,7 @@
* Data types shared between different Virtual HW blocks
**/
+#define MAX_AUDIOS 7
#define MAX_PIPES 6
struct gamma_curve {
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 09/42] drm/amd/display: Fix dc_create failure handling and 666 color depths
From: Julian Parkin
[ Upstream commit 0905f32977268149f06e3ce6ea4bd6d374dd891f ]
[Why]
It is possible (but very unlikely) that constructing dc fails
before current_state is created.
We support 666 color depth in some scenarios, but this
isn't handled in get_norm_pix_clk. It uses exactly the
same pixel clock as the 888 case.
[How]
Check for non null current_state before destructing.
Add case for 666 color depth to get_norm_pix_clk to
avoid assertion.
Signed-off-by: Julian Parkin
Reviewed-by: Charlene Liu
Acked-by: Leo Li
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 6 --
drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 1 +
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index e3f5e5d6f0c18..f4b89d1ea6f6f 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -462,8 +462,10 @@ void dc_link_set_test_pattern(struct dc_link *link,
static void destruct(struct dc *dc)
{
- dc_release_state(dc->current_state);
- dc->current_state = NULL;
+ if (dc->current_state) {
+ dc_release_state(dc->current_state);
+ dc->current_state = NULL;
+ }
destroy_links(dc);
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
index 06d5988dff723..19a951e5818ac 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
@@ -1872,6 +1872,7 @@ static int get_norm_pix_clk(const struct dc_crtc_timing
*timing)
pix_clk /= 2;
if (timing->pixel_encoding != PIXEL_ENCODING_YCBCR422) {
switch (timing->display_color_depth) {
+ case COLOR_DEPTH_666:
case COLOR_DEPTH_888:
normalized_pix_clk = pix_clk;
break;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 07/42] drm/amd/display: Wait for backlight programming completion in set backlight level
From: SivapiriyanKumarasamy [ Upstream commit c7990daebe71d11a9e360b5c3b0ecd1846a3a4bb ] [WHY] Currently we don't wait for blacklight programming completion in DMCU when setting backlight level. Some sequences such as PSR static screen event trigger reprogramming requires it to be complete. [How] Add generic wait for dmcu command completion in set backlight level. Signed-off-by: SivapiriyanKumarasamy Reviewed-by: Anthony Koo Acked-by: Leo Li Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/dc/dce/dce_abm.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_abm.c b/drivers/gpu/drm/amd/display/dc/dce/dce_abm.c index 070ab56a8aca7..da8b198538e5f 100644 --- a/drivers/gpu/drm/amd/display/dc/dce/dce_abm.c +++ b/drivers/gpu/drm/amd/display/dc/dce/dce_abm.c @@ -242,6 +242,10 @@ static void dmcu_set_backlight_level( s2 |= (level << ATOM_S2_CURRENT_BL_LEVEL_SHIFT); REG_WRITE(BIOS_SCRATCH_2, s2); + + /* waitDMCUReadyForCmd */ + REG_WAIT(MASTER_COMM_CNTL_REG, MASTER_COMM_INTERRUPT, + 0, 1, 8); } static void dce_abm_init(struct abm *abm) -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 08/42] drm/amd/display: use encoder's engine id to find matched free audio device
From: Tai Man
[ Upstream commit 74eda776d7a4e69ec7aa1ce30a87636f14220fbb ]
[Why]
On some platforms, the encoder id 3 is not populated. So the encoders
are not stored in right order as index (id: 0, 1, 2, 4, 5) at pool. This
would cause encoders id 4 & id 5 to fail when finding corresponding
audio device, defaulting to the first available audio device. As result,
we cannot stream audio into two DP ports with encoders id 4 & id 5.
[How]
It need to create enough audio device objects (0 - 5) to perform matching.
Then use encoder engine id to find matched audio device.
Signed-off-by: Tai Man
Reviewed-by: Charlene Liu
Acked-by: Leo Li
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
index e0a96abb3c46c..06d5988dff723 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
@@ -222,7 +222,7 @@ bool resource_construct(
* PORT_CONNECTIVITY == 1 (as instructed by HW team).
*/
update_num_audio(, _audio, >audio_support);
- for (i = 0; i < pool->pipe_count && i < num_audio; i++) {
+ for (i = 0; i < caps->num_audio; i++) {
struct audio *aud = create_funcs->create_audio(ctx, i);
if (aud == NULL) {
@@ -1713,6 +1713,12 @@ static struct audio *find_first_free_audio(
return pool->audios[i];
}
}
+
+/* use engine id to find free audio */
+ if ((id < pool->audio_count) && (res_ctx->is_audio_acquired[id] ==
false)) {
+ return pool->audios[id];
+ }
+
/*not found the matching one, first come first serve*/
for (i = 0; i < pool->audio_count; i++) {
if (res_ctx->is_audio_acquired[i] == false) {
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.2 43/76] drm: silence variable 'conn' set but not used
From: Qian Cai [ Upstream commit bbb6fc43f131f77fcb7ae8081f6d7c51396a2120 ] The "struct drm_connector" iteration cursor from "for_each_new_connector_in_state" is never used in atomic_remove_fb() which generates a compilation warning, drivers/gpu/drm/drm_framebuffer.c: In function 'atomic_remove_fb': drivers/gpu/drm/drm_framebuffer.c:838:24: warning: variable 'conn' set but not used [-Wunused-but-set-variable] Silence it by marking "conn" __maybe_unused. Signed-off-by: Qian Cai Signed-off-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/1563822886-13570-1-git-send-email-...@lca.pw Signed-off-by: Sasha Levin --- drivers/gpu/drm/drm_framebuffer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_framebuffer.c b/drivers/gpu/drm/drm_framebuffer.c index d8d75e25f6fb8..45f6f11a88a74 100644 --- a/drivers/gpu/drm/drm_framebuffer.c +++ b/drivers/gpu/drm/drm_framebuffer.c @@ -830,7 +830,7 @@ static int atomic_remove_fb(struct drm_framebuffer *fb) struct drm_device *dev = fb->dev; struct drm_atomic_state *state; struct drm_plane *plane; - struct drm_connector *conn; + struct drm_connector *conn __maybe_unused; struct drm_connector_state *conn_state; int i, ret; unsigned plane_mask; -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.2 41/76] drm/msm/dpu: Correct dpu encoder spinlock initialization
From: Shubhashree Dhar [ Upstream commit 2e7b801eadbf327bf61041c943e5c44a5de4b0e5 ] dpu encoder spinlock should be initialized during dpu encoder init instead of dpu encoder setup which is part of modeset init. Signed-off-by: Shubhashree Dhar [seanpaul resolved conflict in old init removal and revised the commit message] Signed-off-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/1561357632-15361-1-git-send-email-d...@codeaurora.org Signed-off-by: Sasha Levin --- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c index 0ea1501966594..c62f7abcf509c 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c @@ -2226,8 +2226,6 @@ int dpu_encoder_setup(struct drm_device *dev, struct drm_encoder *enc, if (ret) goto fail; - spin_lock_init(_enc->enc_spinlock); - atomic_set(_enc->frame_done_timeout_ms, 0); timer_setup(_enc->frame_done_timer, dpu_encoder_frame_done_timeout, 0); @@ -2281,6 +2279,7 @@ struct drm_encoder *dpu_encoder_init(struct drm_device *dev, drm_encoder_helper_add(_enc->base, _encoder_helper_funcs); + spin_lock_init(_enc->enc_spinlock); dpu_enc->enabled = false; return _enc->base; -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.2 42/76] drm/msm: stop abusing dma_map/unmap for cache
From: Rob Clark
[ Upstream commit 0036bc73ccbe7e600a3468bf8e8879b122252274 ]
Recently splats like this started showing up:
WARNING: CPU: 4 PID: 251 at drivers/iommu/dma-iommu.c:451
__iommu_dma_unmap+0xb8/0xc0
Modules linked in: ath10k_snoc ath10k_core fuse msm ath mac80211 uvcvideo
cfg80211 videobuf2_vmalloc videobuf2_memops vide
CPU: 4 PID: 251 Comm: kworker/u16:4 Tainted: GW
5.2.0-rc5-next-20190619+ #2317
Hardware name: LENOVO 81JL/LNVNB161216, BIOS 9UCN23WW(V1.06) 10/25/2018
Workqueue: msm msm_gem_free_work [msm]
pstate: 80c5 (Nzcv daif +PAN +UAO)
pc : __iommu_dma_unmap+0xb8/0xc0
lr : __iommu_dma_unmap+0x54/0xc0
sp : 119abce0
x29: 119abce0 x28:
x27: 8001f9946648 x26: 8001ec271068
x25: x24: 8001ea3580a8
x23: 8001f95ba010 x22: 80018e83ba88
x21: 8001e548f000 x20: f000
x19: 1000 x18: c1fe
x17: x16:
x15: 15b70068 x14: 0005
x13: 0003142cc1be1768 x12: 0001
x11: 8001f6de9100 x10: 0009
x9 : 15b78000 x8 :
x7 : 0001 x6 : f000
x5 : 0fff x4 : 1065dbc8
x3 : 000d x2 : 1000
x1 : f000 x0 :
Call trace:
__iommu_dma_unmap+0xb8/0xc0
iommu_dma_unmap_sg+0x98/0xb8
put_pages+0x5c/0xf0 [msm]
msm_gem_free_work+0x10c/0x150 [msm]
process_one_work+0x1e0/0x330
worker_thread+0x40/0x438
kthread+0x12c/0x130
ret_from_fork+0x10/0x18
---[ end trace afc0dc5ab81a06bf ]---
Not quite sure what triggered that, but we really shouldn't be abusing
dma_{map,unmap}_sg() for cache maint.
Cc: Stephen Boyd
Tested-by: Stephen Boyd
Reviewed-by: Jordan Crouse
Signed-off-by: Rob Clark
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20190630124735.27786-1-robdcl...@gmail.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/msm/msm_gem.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 49a019939ccdc..a3b5fe1a13944 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -97,7 +97,7 @@ static struct page **get_pages(struct drm_gem_object *obj)
* because display controller, GPU, etc. are not coherent:
*/
if (msm_obj->flags & (MSM_BO_WC|MSM_BO_UNCACHED))
- dma_map_sg(dev->dev, msm_obj->sgt->sgl,
+ dma_sync_sg_for_device(dev->dev, msm_obj->sgt->sgl,
msm_obj->sgt->nents, DMA_BIDIRECTIONAL);
}
@@ -127,7 +127,7 @@ static void put_pages(struct drm_gem_object *obj)
* GPU, etc. are not coherent:
*/
if (msm_obj->flags & (MSM_BO_WC|MSM_BO_UNCACHED))
- dma_unmap_sg(obj->dev->dev, msm_obj->sgt->sgl,
+ dma_sync_sg_for_cpu(obj->dev->dev,
msm_obj->sgt->sgl,
msm_obj->sgt->nents,
DMA_BIDIRECTIONAL);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111244] amdgpu kernel 5.2 blank display after resume from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=111244 --- Comment #9 from Samuele Decarli --- Created attachment 144929 --> https://bugs.freedesktop.org/attachment.cgi?id=144929=edit Kernel log displaying issue Compressed here is my kernel log, which shows repeating stack traces -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.2 19/76] drm/amd/display: fix DMCU hang when going into Modern Standby
From: Zi Yu Liao
[ Upstream commit 1ca068ed34d6b39d336c1b0d618ed73ba8f04548 ]
[why]
When the system is going into suspend, set_backlight gets called
after the eDP got blanked. Since smooth brightness is enabled,
the driver will make a call into the DMCU to ramp the brightness.
The DMCU would try to enable ABM to do so. But since the display is
blanked, this ends up causing ABM1_ACE_DBUF_REG_UPDATE_PENDING to
get stuck at 1, which results in a dead lock in the DMCU firmware.
[how]
Disable brightness ramping when the eDP display is blanked.
Signed-off-by: Zi Yu Liao
Reviewed-by: Eric Yang
Acked-by: Anthony Koo
Acked-by: Leo Li
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index a3ff33ff6da16..adf39e3b8d29d 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -2284,7 +2284,7 @@ bool dc_link_set_backlight_level(const struct dc_link
*link,
if (core_dc->current_state->res_ctx.pipe_ctx[i].stream)
{
if (core_dc->current_state->res_ctx.
pipe_ctx[i].stream->link
- == link)
+ == link) {
/* DMCU -1 for all controller id values,
* therefore +1 here
*/
@@ -2292,6 +2292,13 @@ bool dc_link_set_backlight_level(const struct dc_link
*link,
core_dc->current_state->
res_ctx.pipe_ctx[i].stream_res.tg->inst +
1;
+
+ /* Disable brightness ramping when the
display is blanked
+* as it can hang the DMCU
+*/
+ if
(core_dc->current_state->res_ctx.pipe_ctx[i].plane_state == NULL)
+ frame_ramp = 0;
+ }
}
}
abm->funcs->set_backlight_level_pwm(
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.2 17/76] drm/amd/display: Clock does not lower in Updateplanes
From: Murton Liu
[ Upstream commit 492d9ec244923420af96db6b69ad7d575859aa92 ]
[why]
We reset the optimized_required in atomic_plane_disable
flag immediately after it is set in atomic_plane_disconnect, causing us to
never have flag set during next flip in UpdatePlanes.
[how]
Optimize directly after each time plane is removed.
Signed-off-by: Murton Liu
Reviewed-by: Tony Cheng
Acked-by: Leo Li
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
index 9e4d70a0055e1..c7b4c3048b71d 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
@@ -2416,6 +2416,12 @@ static void dcn10_apply_ctx_for_surface(
if (removed_pipe[i])
dcn10_disable_plane(dc,
>current_state->res_ctx.pipe_ctx[i]);
+ for (i = 0; i < dc->res_pool->pipe_count; i++)
+ if (removed_pipe[i]) {
+ dc->hwss.optimize_bandwidth(dc, context);
+ break;
+ }
+
if (dc->hwseq->wa.DEGVIDCN10_254)
hubbub1_wm_change_req_wa(dc->res_pool->hubbub);
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.2 25/76] drm/amd/display: Increase size of audios array
From: Tai Man
[ Upstream commit 7352193a33dfc9b69ba3bf6a8caea925b96243b1 ]
[Why]
The audios array defined in "struct resource_pool" is only 6 (MAX_PIPES)
but the max number of audio devices (num_audio) is 7. In some projects,
it will run out of audios array.
[How]
Incraese the audios array size to 7.
Signed-off-by: Tai Man
Reviewed-by: Joshua Aberback
Acked-by: Leo Li
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/inc/core_types.h | 2 +-
drivers/gpu/drm/amd/display/dc/inc/hw/hw_shared.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/inc/core_types.h
b/drivers/gpu/drm/amd/display/dc/inc/core_types.h
index 6f5ab05d64677..6f0cc718fbd75 100644
--- a/drivers/gpu/drm/amd/display/dc/inc/core_types.h
+++ b/drivers/gpu/drm/amd/display/dc/inc/core_types.h
@@ -169,7 +169,7 @@ struct resource_pool {
struct clock_source *clock_sources[MAX_CLOCK_SOURCES];
unsigned int clk_src_count;
- struct audio *audios[MAX_PIPES];
+ struct audio *audios[MAX_AUDIOS];
unsigned int audio_count;
struct audio_support audio_support;
diff --git a/drivers/gpu/drm/amd/display/dc/inc/hw/hw_shared.h
b/drivers/gpu/drm/amd/display/dc/inc/hw/hw_shared.h
index 4c8e2c6fb6dbc..72266efd826cf 100644
--- a/drivers/gpu/drm/amd/display/dc/inc/hw/hw_shared.h
+++ b/drivers/gpu/drm/amd/display/dc/inc/hw/hw_shared.h
@@ -34,6 +34,7 @@
* Data types shared between different Virtual HW blocks
**/
+#define MAX_AUDIOS 7
#define MAX_PIPES 6
struct gamma_curve {
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.2 20/76] drm/amd/display: use encoder's engine id to find matched free audio device
From: Tai Man
[ Upstream commit 74eda776d7a4e69ec7aa1ce30a87636f14220fbb ]
[Why]
On some platforms, the encoder id 3 is not populated. So the encoders
are not stored in right order as index (id: 0, 1, 2, 4, 5) at pool. This
would cause encoders id 4 & id 5 to fail when finding corresponding
audio device, defaulting to the first available audio device. As result,
we cannot stream audio into two DP ports with encoders id 4 & id 5.
[How]
It need to create enough audio device objects (0 - 5) to perform matching.
Then use encoder engine id to find matched audio device.
Signed-off-by: Tai Man
Reviewed-by: Charlene Liu
Acked-by: Leo Li
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
index eac7186e4f084..ad82906b99db9 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
@@ -254,7 +254,7 @@ bool resource_construct(
* PORT_CONNECTIVITY == 1 (as instructed by HW team).
*/
update_num_audio(, _audio, >audio_support);
- for (i = 0; i < pool->pipe_count && i < num_audio; i++) {
+ for (i = 0; i < caps->num_audio; i++) {
struct audio *aud = create_funcs->create_audio(ctx, i);
if (aud == NULL) {
@@ -1702,6 +1702,12 @@ static struct audio *find_first_free_audio(
return pool->audios[i];
}
}
+
+/* use engine id to find free audio */
+ if ((id < pool->audio_count) && (res_ctx->is_audio_acquired[id] ==
false)) {
+ return pool->audios[id];
+ }
+
/*not found the matching one, first come first serve*/
for (i = 0; i < pool->audio_count; i++) {
if (res_ctx->is_audio_acquired[i] == false) {
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.2 24/76] drm/amd/display: Only enable audio if speaker allocation exists
From: Alvin Lee
[ Upstream commit 6ac25e6d5b2fbf251e9fa2f4131d42c815b43867 ]
[Why]
In dm_helpers_parse_edid_caps, there is a corner case where no speakers
can be allocated even though the audio mode count is greater than 0.
Enabling audio when no speaker allocations exists can cause issues in
the video stream.
[How]
Add a check to not enable audio unless one or more speaker allocations
exist (since doing this can cause issues in the video stream).
Signed-off-by: Alvin Lee
Reviewed-by: Jun Lei
Acked-by: Leo Li
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
index b87e8d80bb6a8..0fd759d3a0e7d 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
@@ -2019,7 +2019,7 @@ enum dc_status resource_map_pool_resources(
/* TODO: Add check if ASIC support and EDID audio */
if (!stream->converter_disable_audio &&
dc_is_audio_capable_signal(pipe_ctx->stream->signal) &&
- stream->audio_info.mode_count) {
+ stream->audio_info.mode_count && stream->audio_info.flags.all) {
pipe_ctx->stream_res.audio = find_first_free_audio(
>res_ctx, pool, pipe_ctx->stream_res.stream_enc->id);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.2 18/76] drm/amd/display: Wait for backlight programming completion in set backlight level
From: SivapiriyanKumarasamy [ Upstream commit c7990daebe71d11a9e360b5c3b0ecd1846a3a4bb ] [WHY] Currently we don't wait for blacklight programming completion in DMCU when setting backlight level. Some sequences such as PSR static screen event trigger reprogramming requires it to be complete. [How] Add generic wait for dmcu command completion in set backlight level. Signed-off-by: SivapiriyanKumarasamy Reviewed-by: Anthony Koo Acked-by: Leo Li Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/dc/dce/dce_abm.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_abm.c b/drivers/gpu/drm/amd/display/dc/dce/dce_abm.c index 2959c3c9390b9..da30ae04e82bb 100644 --- a/drivers/gpu/drm/amd/display/dc/dce/dce_abm.c +++ b/drivers/gpu/drm/amd/display/dc/dce/dce_abm.c @@ -234,6 +234,10 @@ static void dmcu_set_backlight_level( s2 |= (backlight_8_bit << ATOM_S2_CURRENT_BL_LEVEL_SHIFT); REG_WRITE(BIOS_SCRATCH_2, s2); + + /* waitDMCUReadyForCmd */ + REG_WAIT(MASTER_COMM_CNTL_REG, MASTER_COMM_INTERRUPT, + 0, 1, 8); } static void dce_abm_init(struct abm *abm) -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.2 21/76] drm/amd/display: put back front end initialization sequence
From: Eric Yang
[ Upstream commit feb7eb522e0a7a22c1e60d386bd3c3bfa1d5e4f7 ]
[Why]
Seamless boot optimization removed proper front end power off sequence.
In driver disable enable case, this causes driver to power gate hubp
and dpp while there is still memory fetching going on, this can cause
invalid memory requests to be generated which will hang data fabric.
[How]
Put back proper front end power off sequence
Signed-off-by: Eric Yang
Reviewed-by: Anthony Koo
Acked-by: Leo Li
Acked-by: Tony Cheng
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 15 +--
1 file changed, 1 insertion(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
index c7b4c3048b71d..5cc5dabf4d652 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
@@ -1120,16 +1120,7 @@ static void dcn10_init_hw(struct dc *dc)
* everything down.
*/
if (dcb->funcs->is_accelerated_mode(dcb) ||
dc->config.power_down_display_on_boot) {
- for (i = 0; i < dc->res_pool->pipe_count; i++) {
- struct hubp *hubp = dc->res_pool->hubps[i];
- struct dpp *dpp = dc->res_pool->dpps[i];
-
- hubp->funcs->hubp_init(hubp);
- dc->res_pool->opps[i]->mpc_tree_params.opp_id =
dc->res_pool->opps[i]->inst;
- plane_atomic_power_down(dc, dpp, hubp);
- }
-
- apply_DEGVIDCN10_253_wa(dc);
+ dc->hwss.init_pipes(dc, dc->current_state);
}
for (i = 0; i < dc->res_pool->audio_count; i++) {
@@ -1298,10 +1289,6 @@ static bool dcn10_set_input_transfer_func(struct
pipe_ctx *pipe_ctx,
return result;
}
-
-
-
-
static bool
dcn10_set_output_transfer_func(struct pipe_ctx *pipe_ctx,
const struct dc_stream_state *stream)
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.2 16/76] drm/amd/display: No audio endpoint for Dell MST display
From: Harmanprit Tatla
[ Upstream commit 5b25e5f1a97284020abee7348427f89abdb674e8 ]
[Why]
There are certain MST displays (i.e. Dell P2715Q)
that although have the MST feature set to off may still
report it is a branch device and a non-zero
value for downstream port present.
This can lead to us incorrectly classifying a
dp dongle connection as being active and
disabling the audio endpoint for the display.
[How]
Modified the placement and
condition used to assign
the is_branch_dev bit.
Signed-off-by: Harmanprit Tatla
Reviewed-by: Aric Cyr
Acked-by: Anthony Koo
Acked-by: Leo Li
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
index 253311864cdd5..966aa3b754c5b 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
@@ -2218,11 +2218,18 @@ static void get_active_converter_info(
link->dpcd_caps.dongle_type = DISPLAY_DONGLE_NONE;
ddc_service_set_dongle_type(link->ddc,
link->dpcd_caps.dongle_type);
+ link->dpcd_caps.is_branch_dev = false;
return;
}
/* DPCD 0x5 bit 0 = 1, it indicate it's branch device */
- link->dpcd_caps.is_branch_dev = ds_port.fields.PORT_PRESENT;
+ if (ds_port.fields.PORT_TYPE == DOWNSTREAM_DP) {
+ link->dpcd_caps.is_branch_dev = false;
+ }
+
+ else {
+ link->dpcd_caps.is_branch_dev = ds_port.fields.PORT_PRESENT;
+ }
switch (ds_port.fields.PORT_TYPE) {
case DOWNSTREAM_VGA:
--
2.20.1
[PATCH AUTOSEL 5.2 22/76] drm/amd/display: allocate 4 ddc engines for RV2
From: Derek Lai
[ Upstream commit 67fd6c0d2de8e51e84ff3fa6e68bbd524f823e49 ]
[Why]
Driver will create 0, 1, and 2 ddc engines for RV2,
but some platforms used 0, 1, and 3.
[How]
Still allocate 4 ddc engines for RV2.
Signed-off-by: Derek Lai
Reviewed-by: Aric Cyr
Acked-by: Leo Li
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c
index 7eccb54c421d9..aac52eed6b2aa 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c
@@ -512,7 +512,7 @@ static const struct resource_caps rv2_res_cap = {
.num_audio = 3,
.num_stream_encoder = 3,
.num_pll = 3,
- .num_ddc = 3,
+ .num_ddc = 4,
};
#endif
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.2 23/76] drm/amd/display: Fix dc_create failure handling and 666 color depths
From: Julian Parkin
[ Upstream commit 0905f32977268149f06e3ce6ea4bd6d374dd891f ]
[Why]
It is possible (but very unlikely) that constructing dc fails
before current_state is created.
We support 666 color depth in some scenarios, but this
isn't handled in get_norm_pix_clk. It uses exactly the
same pixel clock as the 888 case.
[How]
Check for non null current_state before destructing.
Add case for 666 color depth to get_norm_pix_clk to
avoid assertion.
Signed-off-by: Julian Parkin
Reviewed-by: Charlene Liu
Acked-by: Leo Li
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 6 --
drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 1 +
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index ee6b646180b66..0a7adc2925e35 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -608,8 +608,10 @@ const struct dc_link_settings *dc_link_get_link_cap(
static void destruct(struct dc *dc)
{
- dc_release_state(dc->current_state);
- dc->current_state = NULL;
+ if (dc->current_state) {
+ dc_release_state(dc->current_state);
+ dc->current_state = NULL;
+ }
destroy_links(dc);
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
index ad82906b99db9..b87e8d80bb6a8 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
@@ -1872,6 +1872,7 @@ static int get_norm_pix_clk(const struct dc_crtc_timing
*timing)
pix_clk /= 2;
if (timing->pixel_encoding != PIXEL_ENCODING_YCBCR422) {
switch (timing->display_color_depth) {
+ case COLOR_DEPTH_666:
case COLOR_DEPTH_888:
normalized_pix_clk = pix_clk;
break;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111244] amdgpu kernel 5.2 blank display after resume from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=111244 --- Comment #8 from Samuele Decarli --- Created attachment 144928 --> https://bugs.freedesktop.org/attachment.cgi?id=144928=edit Result of git bisect Model: HP EliteBook 745 G5 CPU/GPU: AMD Ryzen 7 PRO 2700U I completed my bisection and this is the log. The first bad commit seems to be this one. It's actually a fairly innocent commit, so it's probably causing a bug somewhere else. df8368be1382b442384507a5147c89978cd60702 is the first bad commit commit df8368be1382b442384507a5147c89978cd60702 Author: Nicholas Kazlauskas Date: Wed Feb 27 12:56:36 2019 -0500 drm/amdgpu: Bump amdgpu version for per-flip plane tiling updates To help xf86-video-amdgpu and mesa know DC supports updating the tiling attributes for a framebuffer per-flip. Cc: Michel Dänzer Signed-off-by: Nicholas Kazlauskas Acked-by: Alex Deucher Reviewed-by: Marek Olšák Signed-off-by: Alex Deucher drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/8] drm/omap: OMAP_BO flags
On 01/08/2019 11:02, Tomi Valkeinen wrote: Hi JJ, On 08/07/2019 13:45, Jean-Jacques Hiblot wrote: A first version of this work had been sent by Tomi Valkeinen in may 2017 (https://www.spinics.net/lists/dri-devel/msg140663.html). This series adds a few new OMAP_BO flags to help the userspace manage situations where it needs to use lots of buffers, and would currently run out of TILER space. The TILER space is limited to mapping 128MB at any given time and some applications might need more. This seres is also the opportunity to do some cleanup in the flags and improve the comments describing them. The user-space patches for libdrm, although ready, haven't been posted yet. It will be be done when this series have been discussed and hopefully in the process of getting merged. JJ changes in v2: - fixed build error that crept in during rebase before sending (sorry about that) - rework the refcount part a bit. Jean-Jacques Hiblot (1): drm/omap: use refcount API to track the number of users of dma_addr Tomi Valkeinen (7): drm/omap: add omap_gem_unpin_locked() drm/omap: accept NULL for dma_addr in omap_gem_pin drm/omap: cleanup OMAP_BO flags drm/omap: remove OMAP_BO_TILED define drm/omap: cleanup OMAP_BO_SCANOUT use drm/omap: add omap_gem_validate_flags() drm/omap: add OMAP_BO flags to affect buffer allocation Were there any changes to these patches compared to the ones I sent a few years back? Yes they are a bit different. I took the patches from the TI tree no from ML. In thoses patches you had already taken in account most (all ?) of the comments, including a better description of the different flags and some changes in names. I only modified and reordered them to fix a build breakage. (this is related to OMAP_BO_TILED being removed) Also I added a patch to address Laurent's comment about the use of atomic If I recall right, one valid comment from Laurent was also about adding kernel-doc for include/uapi/drm/omap_drm.h. The OMAP_BO_* flags could have a bit more explanations in the form of kernel doc. OK I didn't address this one. I'll update the comments in a v3. Tomi ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
