Re: [PATCH 1/3] drm: use the lookup lock in drm_is_current_master
On Thu, Jul 22, 2021 at 09:02:41PM +0200, Daniel Vetter wrote:
> On Thu, Jul 22, 2021 at 6:00 PM Boqun Feng wrote:
> >
> > On Thu, Jul 22, 2021 at 12:38:10PM +0200, Daniel Vetter wrote:
> > > On Thu, Jul 22, 2021 at 05:29:27PM +0800, Desmond Cheong Zhi Xi wrote:
> > > > Inside drm_is_current_master, using the outer drm_device.master_mutex
> > > > to protect reads of drm_file.master makes the function prone to creating
> > > > lock hierarchy inversions. Instead, we can use the
> > > > drm_file.master_lookup_lock that sits at the bottom of the lock
> > > > hierarchy.
> > > >
> > > > Reported-by: Daniel Vetter
> > > > Signed-off-by: Desmond Cheong Zhi Xi
> > > > ---
> > > > drivers/gpu/drm/drm_auth.c | 9 +
> > > > 1 file changed, 5 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
> > > > index f00354bec3fb..9c24b8cc8e36 100644
> > > > --- a/drivers/gpu/drm/drm_auth.c
> > > > +++ b/drivers/gpu/drm/drm_auth.c
> > > > @@ -63,8 +63,9 @@
> > > >
> > > > static bool drm_is_current_master_locked(struct drm_file *fpriv)
> > > > {
> > > > - lockdep_assert_held_once(&fpriv->minor->dev->master_mutex);
> > > > -
> > > > + /* Either drm_device.master_mutex or drm_file.master_lookup_lock
> > > > +* should be held here.
> > > > +*/
> > >
> > > Disappointing that lockdep can't check or conditions for us, a
> > > lockdep_assert_held_either would be really neat in some cases.
> > >
> >
> > The implementation is not hard but I don't understand the usage, for
> > example, if we have a global variable x, and two locks L1 and L2, and
> > the function
> >
> > void do_something_to_x(void)
> > {
> > lockdep_assert_held_either(L1, L2);
> > x++;
> > }
> >
> > and two call sites:
> >
> > void f(void)
> > {
> > lock(L1);
> > do_something_to_x();
> > unlock(L1);
> > }
> >
> > void g(void)
> > {
> > lock(L2);
> > do_something_to_x();
> > unlock(L2);
> > }
> >
> > , wouldn't it be racy if f() and g() called by two threads at the same
> > time? Usually I would expect there exists a third synchronazition
> > mechanism (say M), which synchronizes the calls to f() and g(), and we
> > put M in the lockdep_assert_held() check inside do_something_to_x()
> > like:
> >
> > void do_something_to_x(void)
> > {
> > lockdep_assert_held_once(M);
> > x++;
> > }
> >
> > But of course, M may not be a lock, so we cannot put the assert there.
> >
> > My cscope failed to find ->master_lookup_lock in -rc2 and seems it's not
> > introduced in the patchset either, could you point me the branch this
> > patchset is based on, so that I could understand this better, and maybe
> > come up with a solution? Thanks ;-)
>
> The use case is essentially 2 nesting locks, and only the innermost is
> used to update a field. So when you only read this field, it's safe if
> either of these two locks are held. Essentially this is a read/write lock
> type of thing, except for various reasons the two locks might not be of
> the same type (like here where the write lock is a mutex, but the read
> lock is a spinlock).
>
> It's a bit like the rcu_derefence macro where it's ok to either be in a
> rcu_read_lock() section, or holding the relevant lock that's used to
> update the value. We do _not_ have two different locks that allow writing
> to the same X.
>
> Does that make it clearer what's the use-case here?
>
> In an example:
>
> void * interesting_pointer.
>
> do_update_interesting_pointer()
> {
> mutex_lock(A);
> /* do more stuff to prepare things */
> spin_lock(B);
> interesting_pointer = new_value;
> spin_unlock(B);
> mutex_unlock(A);
> }
>
> read_interesting_thing_locked()
> {
> lockdep_assert_held_either(A, B);
>
> return interesting_pointer->thing;
> }
>
> read_interesting_thing()
> {
> int thing;
> spin_lock(B);
> thing = interesting_pointer->thing;
> spin_unlock(B);
>
> return B;
> }
>
> spinlock might also be irqsafe here if this can be called from irq
> context.
>
Make sense, so we'd better also provide lockdep_assert_held_both(), I
think, to use it at the update side, something as below:
/*
* lockdep_assert_held_{both,either}().
*
* Sometimes users can use a combination of two locks to
* implement a rwlock-like lock, for example, say we have
* locks L1 and L2, and we only allow updates when two locks
* both held like:
*
* update()
* {
* lockdep_assert_held_both(L1, L2);
* x++; // update x
* }
*
* while for read-only accesses, either lock suffices (since
* holding either lock means othe
Re: [PATCH v3 1/3] drm/loongson: Add DRM Driver for Loongson 7A1000 bridge chip
On Fri, Jul 23, 2021 at 11:12:49AM +0800, lichenyang wrote:
> +static int loongson_drm_load(struct drm_device *dev)
> +{
> + struct loongson_device *ldev;
> + int ret;
> +
> + ldev = devm_kzalloc(dev->dev, sizeof(*ldev), GFP_KERNEL);
> + if (!ldev)
> + return -ENOMEM;
> +
> + dev->dev_private = ldev;
> + ldev->dev = dev;
> +
> + ret = loongson_device_init(dev);
> + if (ret)
> + goto err;
> +
> + ret = drmm_vram_helper_init(dev, ldev->vram_start, ldev->vram_size);
> + if (ret) {
> + drm_err(dev, "Error initializing vram %d\n", ret);
> + goto err;
> + }
> +
> + drm_mode_config_init(dev);
> + dev->mode_config.funcs = (void *)&loongson_mode_funcs;
> + dev->mode_config.min_width = 1;
> + dev->mode_config.min_height = 1;
> + dev->mode_config.max_width = 4096;
> + dev->mode_config.max_height = 4096;
> + dev->mode_config.preferred_depth = 32;
> + dev->mode_config.prefer_shadow = 1;
> + dev->mode_config.fb_base = ldev->vram_start;
> +
> + ret = loongson_modeset_init(ldev);
> + if (ret) {
> + drm_err(dev, "Fatal error during modeset init: %d\n", ret);
> + goto err;
> + }
> +
> + drm_kms_helper_poll_init(dev);
> + drm_mode_config_reset(dev);
> +
> + return 0;
> +
> +err:
> + kfree(ldev);
I'm sorry, in the earlier version I told you to add this kfree() but
this is devm_ allocated so the kfree() is wrong and will lead to a
double free. My bad. That's on me.
> + drm_err(dev, "failed to initialize drm driver: %d\n", ret);
> + return ret;
> +}
regards,
dan carpenter
Re: [Nouveau] nouveau broken again on Riva TNT2 in 5.14.0-rc2
On Thu, Jul 22, 2021 at 9:51 PM Karol Herbst wrote: > > hey thanks for the report. > > This is a known issue and the fix is pending in drm-mist-fixes and > should land in 5.14 soonish. It just landed in Linus' tree yesterday, please retest that or -rc3. If it's still broken it's something else. -Daniel > > On Thu, Jul 22, 2021 at 9:29 PM Ondrej Zary wrote: > > > > Hello, > > nouveau is broken again: > > > > [ 58.795794] BUG: kernel NULL pointer dereference, address: 017c > > [ 58.795835] #PF: supervisor read access in kernel mode > > [ 58.795844] #PF: error_code(0x) - not-present page > > [ 58.795851] *pde = > > [ 58.795862] Oops: [#1] SMP > > [ 58.795875] CPU: 0 PID: 1730 Comm: Xorg Not tainted 5.14.0-rc2+ #391 > > [ 58.795886] Hardware name: VIA Technologies, Inc. VT82C694X/694X, BIOS > > 6.00 PG 02/19/2002 > > [ 58.795894] EIP: nouveau_bo_wr16+0x8/0x27 [nouveau] > > [ 58.796716] Code: 85 ff 74 0d 80 7d f3 00 74 07 80 a6 c0 01 00 00 fe 89 > > f0 e8 e5 ee ff ff 8d 65 f4 89 f8 5b 5e 5f 5d c3 55 01 d2 89 e5 53 89 c3 > > <03> 93 7c 01 00 00 0f b7 c1 f6 83 84 01 00 00 80 74 07 e8 8a bc 72 > > [ 58.796728] EAX: EBX: ECX: EDX: > > [ 58.796736] ESI: 0020 EDI: c18bc600 EBP: c7c49d88 ESP: c7c49d84 > > [ 58.796744] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 EFLAGS: 00210246 > > [ 58.796754] CR0: 80050033 CR2: 017c CR3: 07e12000 CR4: 0690 > > [ 58.796762] Call Trace: > > [ 58.796774] nv04_crtc_cursor_set+0x148/0x1d8 [nouveau] > > [ 58.796952] ? ttm_bo_reserve.constprop.16+0x1c/0x1c [nouveau] > > [ 58.797122] drm_mode_cursor_common+0x13b/0x1ad > > [ 58.797150] ? ttm_bo_reserve.constprop.16+0x1c/0x1c [nouveau] > > [ 58.797322] drm_mode_cursor_ioctl+0x2e/0x36 > > [ 58.797335] ? drm_mode_setplane+0x203/0x203 > > [ 58.797346] drm_ioctl_kernel+0x66/0x99 > > [ 58.797366] drm_ioctl+0x211/0x2d8 > > [ 58.797377] ? drm_mode_setplane+0x203/0x203 > > [ 58.797389] ? __cond_resched+0x1e/0x22 > > [ 58.797409] ? mutex_lock+0xb/0x24 > > [ 58.797422] ? rpm_resume.part.14+0x6f/0x362 > > [ 58.797447] ? ktime_get_mono_fast_ns+0x5e/0xf2 > > [ 58.797469] ? __pm_runtime_resume+0x5b/0x63 > > [ 58.797480] nouveau_drm_ioctl+0x65/0x81 [nouveau] > > [ 58.797662] ? nouveau_cli_work+0xc3/0xc3 [nouveau] > > [ 58.797838] vfs_ioctl+0x1a/0x24 > > [ 58.797850] __ia32_sys_ioctl+0x6ea/0x704 > > [ 58.797861] ? doublefault_shim+0x120/0x120 > > [ 58.797872] ? exit_to_user_mode_prepare+0x9e/0x10c > > [ 58.797900] do_int80_syscall_32+0x53/0x6e > > [ 58.797910] entry_INT80_32+0xf0/0xf0 > > [ 58.797923] EIP: 0xb7f04092 > > [ 58.797932] Code: 00 00 00 e9 90 ff ff ff ff a3 24 00 00 00 68 30 00 00 > > 00 e9 80 ff ff ff ff a3 e8 ff ff ff 66 90 00 00 00 00 00 00 00 00 cd 80 > > 8d b4 26 00 00 00 00 8d b6 00 00 00 00 8b 1c 24 c3 8d b4 26 00 > > [ 58.797943] EAX: ffda EBX: 000e ECX: c01c64a3 EDX: bf9a15c0 > > [ 58.797952] ESI: 00997850 EDI: c01c64a3 EBP: 000e ESP: bf9a1574 > > [ 58.797959] DS: 007b ES: 007b FS: GS: 0033 SS: 007b EFLAGS: 00200292 > > [ 58.797972] Modules linked in: i2c_dev nouveau wmi hwmon drm_ttm_helper > > psmouse serio_raw via_agp sg parport_pc 8139cp parport > > [ 58.798016] CR2: 017c > > [ 58.798147] ---[ end trace 732829d39ed65de9 ]--- > > > > > > d02117f8efaa5fbc37437df1ae955a147a2a424a is the first bad commit > > > > -- > > Ondrej Zary > > > > ___ > Nouveau mailing list > nouv...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/nouveau -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH v4 2/4] drm/shmem-helper: Switch to vmf_insert_pfn
On Thu, Jul 22, 2021 at 08:22:43PM +0200, Thomas Zimmermann wrote:
> Hi,
>
> I'm not knowledgeable enougth to give this a full review. If you can just
> answer my questions, fell free to add an
>
> Acked-by: Thomas Zimmermann
>
> to the patch. :)
>
> Am 13.07.21 um 22:51 schrieb Daniel Vetter:
> > We want to stop gup, which isn't the case if we use vmf_insert_page
>
> What is gup?
get_user_pages. It pins memory wherever it is, which badly wreaks at least
ttm and could also cause trouble with cma allocations. In both cases
becaue we can't move/reuse these pages anymore.
Now get_user_pages fails when the memory isn't considered "normal", like
with VM_PFNMAP and using vm_insert_pfn. For consistency across all dma-buf
I'm trying (together with Christian König) to roll this out everywhere,
for fewer surprises.
E.g. for 5.14 iirc we merged a patch to do the same for ttm, where it
closes an actual bug (ttm gets really badly confused when there's suddenly
pinned pages where it thought it can move them).
cma allcoations already use VM_PFNMAP (because that's what dma_mmap is
using underneath), as is anything that's using remap_pfn_range. Worst case
we have to revert this patch for shmem helpers if it breaks something, but
I hope that's not the case. On the ttm side we've also had some fallout
that we needed to paper over with clever tricks.
I'll add the above explanation to the commit message.
>
> > and VM_MIXEDMAP, because that does not set pte_special.
> >
> > v2: With this shmem gem helpers now definitely need CONFIG_MMU (0day)
> >
> > v3: add more depends on MMU. For usb drivers this is a bit awkward,
> > but really it's correct: To be able to provide a contig mapping of
> > buffers to userspace on !MMU platforms we'd need to use the cma
> > helpers for these drivers on those platforms. As-is this wont work.
> >
> > Also not exactly sure why vm_insert_page doesn't go boom, because that
> > definitely wont fly in practice since the pages are non-contig to
> > begin with.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Maarten Lankhorst
> > Cc: Maxime Ripard
> > Cc: Thomas Zimmermann
> > Cc: David Airlie
> > Cc: Daniel Vetter
> > ---
> > drivers/gpu/drm/Kconfig| 2 +-
> > drivers/gpu/drm/drm_gem_shmem_helper.c | 4 ++--
> > drivers/gpu/drm/gud/Kconfig| 2 +-
> > drivers/gpu/drm/tiny/Kconfig | 4 ++--
> > drivers/gpu/drm/udl/Kconfig| 1 +
> > 5 files changed, 7 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> > index 0d372354c2d0..314eefa39892 100644
> > --- a/drivers/gpu/drm/Kconfig
> > +++ b/drivers/gpu/drm/Kconfig
> > @@ -211,7 +211,7 @@ config DRM_KMS_CMA_HELPER
> > config DRM_GEM_SHMEM_HELPER
> > bool
> > - depends on DRM
> > + depends on DRM && MMU
> > help
> > Choose this if you need the GEM shmem helper functions
> > diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
> > b/drivers/gpu/drm/drm_gem_shmem_helper.c
> > index d5e6d4568f99..296ab1b7c07f 100644
> > --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
> > +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
> > @@ -542,7 +542,7 @@ static vm_fault_t drm_gem_shmem_fault(struct vm_fault
> > *vmf)
> > } else {
> > page = shmem->pages[page_offset];
> > - ret = vmf_insert_page(vma, vmf->address, page);
> > + ret = vmf_insert_pfn(vma, vmf->address, page_to_pfn(page));
> > }
> > mutex_unlock(&shmem->pages_lock);
> > @@ -612,7 +612,7 @@ int drm_gem_shmem_mmap(struct drm_gem_object *obj,
> > struct vm_area_struct *vma)
> > return ret;
> > }
> > - vma->vm_flags |= VM_MIXEDMAP | VM_DONTEXPAND;
> > + vma->vm_flags |= VM_PFNMAP | VM_DONTEXPAND;
> > vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
> > if (shmem->map_wc)
> > vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
> > diff --git a/drivers/gpu/drm/gud/Kconfig b/drivers/gpu/drm/gud/Kconfig
> > index 1c8601bf4d91..9c1e61f9eec3 100644
> > --- a/drivers/gpu/drm/gud/Kconfig
> > +++ b/drivers/gpu/drm/gud/Kconfig
> > @@ -2,7 +2,7 @@
> > config DRM_GUD
> > tristate "GUD USB Display"
> > - depends on DRM && USB
> > + depends on DRM && USB && MMU
> > select LZ4_COMPRESS
> > select DRM_KMS_HELPER
> > select DRM_GEM_SHMEM_HELPER
>
> I'm a kconfig noob, so this is rather a question than a review comment:
>
>
>
> If DRM_GEM_SHMEM_HELPER already depends on MMU, this select will fail on
> non-MMU platforms? Why does the driver also depend on MMU? Simply to make
> the item disappear in menuconfig?
>
> Best regards
> Thomas
>
> > diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig
> > index 5593128eeff9..c11fb5be7d09 100644
> > --- a/drivers/gpu/drm/tiny/Kconfig
> > +++ b/drivers/gpu/drm/tiny/Kconfig
> > @@ -44,7 +44,7 @@ config DRM_CIRRUS_QEMU
> > config DRM_GM12U320
> > tristate "GM12U320 driver for USB projectors"
> > - depends on
Re: [PATCH v4 3/4] drm/shmem-helpers: Allocate wc pages on x86
On Thu, Jul 22, 2021 at 08:40:56PM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 13.07.21 um 22:51 schrieb Daniel Vetter:
> > intel-gfx-ci realized that something is not quite coherent anymore on
> > some platforms for our i915+vgem tests, when I tried to switch vgem
> > over to shmem helpers.
> >
> > After lots of head-scratching I realized that I've removed calls to
> > drm_clflush. And we need those. To make this a bit cleaner use the
> > same page allocation tooling as ttm, which does internally clflush
> > (and more, as neeeded on any platform instead of just the intel x86
> > cpus i915 can be combined with).
>
> Vgem would therefore not work correctly on non-X86 platforms?
Anything using shmem helpers doesn't work correctly on non-x86 platforms.
At least if they use wc.
vgem with intel-gfx-ci is simply running some very nasty tests that catch
the bugs.
I'm kinda hoping that someone from the armsoc world would care enough to
fix this there. But it's a tricky issue.
> >
> > Unfortunately this doesn't exist on arm, or as a generic feature. For
> > that I think only the dma-api can get at wc memory reliably, so maybe
> > we'd need some kind of GFP_WC flag to do this properly.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Christian König
> > Cc: "Thomas Hellström"
> > Cc: Maarten Lankhorst
> > Cc: Maxime Ripard
> > Cc: Thomas Zimmermann
> > Cc: David Airlie
> > Cc: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_gem_shmem_helper.c | 14 ++
> > 1 file changed, 14 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
> > b/drivers/gpu/drm/drm_gem_shmem_helper.c
> > index 296ab1b7c07f..657d2490aaa5 100644
> > --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
> > +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
> > @@ -10,6 +10,10 @@
> > #include
> > #include
> > +#ifdef CONFIG_X86
> > +#include
> > +#endif
> > +
> > #include
> > #include
> > #include
> > @@ -162,6 +166,11 @@ static int drm_gem_shmem_get_pages_locked(struct
> > drm_gem_shmem_object *shmem)
> > return PTR_ERR(pages);
> > }
> > +#ifdef CONFIG_X86
> > + if (shmem->map_wc)
> > + set_pages_array_wc(pages, obj->size >> PAGE_SHIFT);
> > +#endif
>
> I cannot comment much on the technical details of the caching of various
> architectures. If this patch goes in, there should be a longer comment that
> reflects the discussion in this thread. It's apparently a workaround.
>
> I think the call itself should be hidden behind a DRM API, which depends on
> CONFIG_X86. Something simple like
>
> ifdef CONFIG_X86
> drm_set_pages_array_wc()
> {
> set_pages_array_wc();
> }
> else
> drm_set_pages_array_wc()
> {
> }
> #endif
>
> Maybe in drm_cache.h?
We do have a bunch of this in drm_cache.h already, and architecture
maintainers hate us for it.
The real fix is to get at the architecture-specific wc allocator, which is
currently not something that's exposed, but hidden within the dma api. I
think having this stick out like this is better than hiding it behind fake
generic code (like we do with drm_clflush, which defacto also only really
works on x86).
Also note that ttm has the exact same ifdef in its page allocator, but it
does fall back to using dma_alloc_coherent on other platforms.
-Daniel
> Best regard
> Thomas
>
> > +
> > shmem->pages = pages;
> > return 0;
> > @@ -203,6 +212,11 @@ static void drm_gem_shmem_put_pages_locked(struct
> > drm_gem_shmem_object *shmem)
> > if (--shmem->pages_use_count > 0)
> > return;
> > +#ifdef CONFIG_X86
> > + if (shmem->map_wc)
> > + set_pages_array_wb(shmem->pages, obj->size >> PAGE_SHIFT);
> > +#endif
> > +
> > drm_gem_put_pages(obj, shmem->pages,
> > shmem->pages_mark_dirty_on_put,
> > shmem->pages_mark_accessed_on_put);
> >
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Felix Imendörffer
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH v4 4/4] drm/vgem: use shmem helpers
On Thu, Jul 22, 2021 at 08:50:48PM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 13.07.21 um 22:51 schrieb Daniel Vetter:
> > Aside from deleting lots of code the real motivation here is to switch
> > the mmap over to VM_PFNMAP, to be more consistent with what real gpu
> > drivers do. They're all VM_PFNMP, which means get_user_pages doesn't
> > work, and even if you try and there's a struct page behind that,
> > touching it and mucking around with its refcount can upset drivers
> > real bad.
> >
> > v2: Review from Thomas:
> > - sort #include
> > - drop more dead code that I didn't spot somehow
> >
> > v3: select DRM_GEM_SHMEM_HELPER to make it build (intel-gfx-ci)
> >
> > v4: I got tricked by 0cf2ef46c6c0 ("drm/shmem-helper: Use cached
> > mappings by default"), and we need WC in vgem because vgem doesn't
> > have explicit begin/end cpu access ioctls.
> >
> > Also add a comment why exactly vgem has to use wc.
> >
> > v5: Don't set obj->base.funcs, it will default to drm_gem_shmem_funcs
> > (Thomas)
> >
> > v6: vgem also needs an MMU for remapping
> >
> > Cc: Thomas Zimmermann
> > Acked-by: Thomas Zimmermann
> > Cc: John Stultz
> > Cc: Sumit Semwal
> > Cc: "Christian König"
> > Signed-off-by: Daniel Vetter
> > Cc: Melissa Wen
> > Cc: Chris Wilson
> > ---
> > drivers/gpu/drm/Kconfig | 5 +-
> > drivers/gpu/drm/vgem/vgem_drv.c | 315 ++--
> > 2 files changed, 15 insertions(+), 305 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> > index 314eefa39892..28f7d2006e8b 100644
> > --- a/drivers/gpu/drm/Kconfig
> > +++ b/drivers/gpu/drm/Kconfig
> > @@ -272,7 +272,8 @@ source "drivers/gpu/drm/kmb/Kconfig"
> > config DRM_VGEM
> > tristate "Virtual GEM provider"
> > - depends on DRM
> > + depends on DRM && MMU
> > + select DRM_GEM_SHMEM_HELPER
> > help
> > Choose this option to get a virtual graphics memory manager,
> > as used by Mesa's software renderer for enhanced performance.
> > @@ -280,7 +281,7 @@ config DRM_VGEM
> > config DRM_VKMS
> > tristate "Virtual KMS (EXPERIMENTAL)"
> > - depends on DRM
> > + depends on DRM && MMU
> > select DRM_KMS_HELPER
> > select DRM_GEM_SHMEM_HELPER
> > select CRC32
> > diff --git a/drivers/gpu/drm/vgem/vgem_drv.c
> > b/drivers/gpu/drm/vgem/vgem_drv.c
> > index bf38a7e319d1..ba410ba6b7f7 100644
> > --- a/drivers/gpu/drm/vgem/vgem_drv.c
> > +++ b/drivers/gpu/drm/vgem/vgem_drv.c
> > @@ -38,6 +38,7 @@
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -50,87 +51,11 @@
> > #define DRIVER_MAJOR 1
> > #define DRIVER_MINOR 0
> > -static const struct drm_gem_object_funcs vgem_gem_object_funcs;
> > -
> > static struct vgem_device {
> > struct drm_device drm;
> > struct platform_device *platform;
> > } *vgem_device;
> > -static void vgem_gem_free_object(struct drm_gem_object *obj)
> > -{
> > - struct drm_vgem_gem_object *vgem_obj = to_vgem_bo(obj);
> > -
> > - kvfree(vgem_obj->pages);
> > - mutex_destroy(&vgem_obj->pages_lock);
> > -
> > - if (obj->import_attach)
> > - drm_prime_gem_destroy(obj, vgem_obj->table);
> > -
> > - drm_gem_object_release(obj);
> > - kfree(vgem_obj);
> > -}
> > -
> > -static vm_fault_t vgem_gem_fault(struct vm_fault *vmf)
> > -{
> > - struct vm_area_struct *vma = vmf->vma;
> > - struct drm_vgem_gem_object *obj = vma->vm_private_data;
> > - /* We don't use vmf->pgoff since that has the fake offset */
> > - unsigned long vaddr = vmf->address;
> > - vm_fault_t ret = VM_FAULT_SIGBUS;
> > - loff_t num_pages;
> > - pgoff_t page_offset;
> > - page_offset = (vaddr - vma->vm_start) >> PAGE_SHIFT;
> > -
> > - num_pages = DIV_ROUND_UP(obj->base.size, PAGE_SIZE);
> > -
> > - if (page_offset >= num_pages)
> > - return VM_FAULT_SIGBUS;
> > -
> > - mutex_lock(&obj->pages_lock);
> > - if (obj->pages) {
> > - get_page(obj->pages[page_offset]);
> > - vmf->page = obj->pages[page_offset];
> > - ret = 0;
> > - }
> > - mutex_unlock(&obj->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;
> > -
[PATCH] dma-buf/poll: Get a file reference for outstanding fence callbacks
From: Michel Dänzer
This makes sure we don't hit the
BUG_ON(dmabuf->cb_in.active || dmabuf->cb_out.active);
in dma_buf_release, which could be triggered by user space closing the
dma-buf file description while there are outstanding fence callbacks
from dma_buf_poll.
Cc: sta...@vger.kernel.org
Signed-off-by: Michel Dänzer
---
drivers/dma-buf/dma-buf.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 6c520c9bd93c..ec25498a971f 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -65,12 +65,9 @@ static void dma_buf_release(struct dentry *dentry)
BUG_ON(dmabuf->vmapping_counter);
/*
-* Any fences that a dma-buf poll can wait on should be signaled
-* before releasing dma-buf. This is the responsibility of each
-* driver that uses the reservation objects.
-*
-* If you hit this BUG() it means someone dropped their ref to the
-* dma-buf while still having pending operation to the buffer.
+* If you hit this BUG() it could mean:
+* * There's a file reference imbalance in dma_buf_poll /
dma_buf_poll_cb or somewhere else
+* * dmabuf->cb_in/out.active are non-0 despite no pending fence
callback
*/
BUG_ON(dmabuf->cb_in.active || dmabuf->cb_out.active);
@@ -196,6 +193,7 @@ static loff_t dma_buf_llseek(struct file *file, loff_t
offset, int whence)
static void dma_buf_poll_cb(struct dma_fence *fence, struct dma_fence_cb *cb)
{
struct dma_buf_poll_cb_t *dcb = (struct dma_buf_poll_cb_t *)cb;
+ struct dma_buf *dmabuf = container_of(dcb->poll, struct dma_buf, poll);
unsigned long flags;
spin_lock_irqsave(&dcb->poll->lock, flags);
@@ -203,6 +201,8 @@ static void dma_buf_poll_cb(struct dma_fence *fence, struct
dma_fence_cb *cb)
dcb->active = 0;
spin_unlock_irqrestore(&dcb->poll->lock, flags);
dma_fence_put(fence);
+ /* Paired with get_file in dma_buf_poll */
+ fput(dmabuf->file);
}
static bool dma_buf_poll_shared(struct dma_resv *resv,
@@ -278,6 +278,9 @@ static __poll_t dma_buf_poll(struct file *file, poll_table
*poll)
spin_unlock_irq(&dmabuf->poll.lock);
if (events & EPOLLOUT) {
+ /* Paired with fput in dma_buf_poll_cb */
+ get_file(dmabuf->file);
+
if (!dma_buf_poll_shared(resv, dcb) &&
!dma_buf_poll_excl(resv, dcb))
/* No callback queued, wake up any other
waiters */
@@ -299,6 +302,9 @@ static __poll_t dma_buf_poll(struct file *file, poll_table
*poll)
spin_unlock_irq(&dmabuf->poll.lock);
if (events & EPOLLIN) {
+ /* Paired with fput in dma_buf_poll_cb */
+ get_file(dmabuf->file);
+
if (!dma_buf_poll_excl(resv, dcb))
/* No callback queued, wake up any other
waiters */
dma_buf_poll_cb(NULL, &dcb->cb);
--
2.32.0
Re: [PATCH v4 3/4] drm/shmem-helpers: Allocate wc pages on x86
Am 23.07.21 um 09:36 schrieb Daniel Vetter:
On Thu, Jul 22, 2021 at 08:40:56PM +0200, Thomas Zimmermann wrote:
Hi
Am 13.07.21 um 22:51 schrieb Daniel Vetter:
[SNIP]
+#ifdef CONFIG_X86
+ if (shmem->map_wc)
+ set_pages_array_wc(pages, obj->size >> PAGE_SHIFT);
+#endif
I cannot comment much on the technical details of the caching of various
architectures. If this patch goes in, there should be a longer comment that
reflects the discussion in this thread. It's apparently a workaround.
I think the call itself should be hidden behind a DRM API, which depends on
CONFIG_X86. Something simple like
ifdef CONFIG_X86
drm_set_pages_array_wc()
{
set_pages_array_wc();
}
else
drm_set_pages_array_wc()
{
}
#endif
Maybe in drm_cache.h?
We do have a bunch of this in drm_cache.h already, and architecture
maintainers hate us for it.
Yeah, for good reasons :)
The real fix is to get at the architecture-specific wc allocator, which is
currently not something that's exposed, but hidden within the dma api. I
think having this stick out like this is better than hiding it behind fake
generic code (like we do with drm_clflush, which defacto also only really
works on x86).
The DMA API also doesn't really touch that stuff as far as I know.
What we rather do on other architectures is to set the appropriate
caching flags on the CPU mappings, see function ttm_prot_from_caching().
Also note that ttm has the exact same ifdef in its page allocator, but it
does fall back to using dma_alloc_coherent on other platforms.
This works surprisingly well on non x86 architectures as well. We just
don't necessary update the kernel mappings everywhere which limits the
kmap usage.
In other words radeon and nouveau still work on PowerPC AGP systems as
far as I know for example.
Christian.
-Daniel
Best regard
Thomas
+
shmem->pages = pages;
return 0;
@@ -203,6 +212,11 @@ static void drm_gem_shmem_put_pages_locked(struct
drm_gem_shmem_object *shmem)
if (--shmem->pages_use_count > 0)
return;
+#ifdef CONFIG_X86
+ if (shmem->map_wc)
+ set_pages_array_wb(shmem->pages, obj->size >> PAGE_SHIFT);
+#endif
+
drm_gem_put_pages(obj, shmem->pages,
shmem->pages_mark_dirty_on_put,
shmem->pages_mark_accessed_on_put);
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
Re: [RESEND PATCH v6 00/14] drm/trace: Mirror DRM debug logs to tracefs
On Thu, 22 Jul 2021 09:48:00 -0400 Sean Paul wrote: > On Thu, Jul 22, 2021 at 3:49 AM Pekka Paalanen wrote: > > > > On Wed, 21 Jul 2021 13:55:07 -0400 > > Sean Paul wrote: > > > > > From: Sean Paul > > > > > > Hi all, > > > I just had the pleasure of rebasing this set on our CrOS downstream > > > kernel and wanted to resend it for consideration once again. There > > > hasn't been any resistence to the set AFAIK, just perhaps not enough > > > motivation for anyone to hit the go bit. There was some interest from > > > the msm folks about a month ago, and it has been an invaluable tool > > > on CrOS for the past ~year. Hopefully someone can dig into this and > > > provide some feedback so we can move this forward. > > > > > > Thanks! > > > > > > Sean > > > > > > Changes since last v6: > > > -Rebased on drm-tip > > > > > > Original v6 of the set available here: > > > https://patchwork.freedesktop.org/series/78133/ > > > https://lore.kernel.org/dri-devel/20200818210510.49730-1-s...@poorly.run/ > > > > > > > Woo! Yes! > > > > Do you have a link to your userspace? > > > > Hi Pekka, > Probably less interesting that you're hoping for, but here are the > CrOS patches to enable and collect tracing: > > https://chromium-review.googlesource.com/c/chromiumos/platform2/+/2354674 > https://chromium-review.googlesource.com/c/chromiumos/platform/crosutils/+/2354392 > > > > You wouldn't happen to have already written a privileged userspace > > service that would deliver on request the logs to non-privileged actors > > like a compositor to be dumped in an error report? > > Our feedback report generation (log_tool.cc above) collects the logs > (depending on user log preferences) from across the system and > packages them up for submission when requested by the user. For > drm_trace, we grab them from debugfs since we don't have tracefs > mounted. > > You could adapt this code to change the delivery method, but I'm not > sure how much value it would add beyond writing your own purpose-built > service. Indeed. Thanks anyway! :-) pq pgpqszLf9sWNt.pgp Description: OpenPGP digital signature
Re: [PATCH] dma-buf: fix and rework dma_buf_poll v7
On 2021-07-20 3:11 p.m., Christian König wrote: > Daniel pointed me towards this function and there are multiple obvious > problems > in the implementation. > > First of all the retry loop is not working as intended. In general the retry > makes only sense if you grab the reference first and then check the sequence > values. > > Then we should always also wait for the exclusive fence. > > It's also good practice to keep the reference around when installing callbacks > to fences you don't own. > > And last the whole implementation was unnecessary complex and rather hard to > understand which could lead to probably unexpected behavior of the IOCTL. > > Fix all this by reworking the implementation from scratch. Dropping the > whole RCU approach and taking the lock instead. > > Only mildly tested and needs a thoughtful review of the code. > > v2: fix the reference counting as well > v3: keep the excl fence handling as is for stable > v4: back to testing all fences, drop RCU > v5: handle in and out separately > v6: add missing clear of events > v7: change coding style as suggested by Michel, drop unused variables > > Signed-off-by: Christian König > CC: sta...@vger.kernel.org Working fine with https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880 Tested-by: Michel Dänzer -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer
Re: [PATCH] dma-buf/poll: Get a file reference for outstanding fence callbacks
Am 23.07.21 um 09:58 schrieb Michel Dänzer:
From: Michel Dänzer
This makes sure we don't hit the
BUG_ON(dmabuf->cb_in.active || dmabuf->cb_out.active);
in dma_buf_release, which could be triggered by user space closing the
dma-buf file description while there are outstanding fence callbacks
from dma_buf_poll.
I was also wondering the same thing while working on this, but then
thought that the poll interface would take care of this.
Cc: sta...@vger.kernel.org
Signed-off-by: Michel Dänzer
---
drivers/dma-buf/dma-buf.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 6c520c9bd93c..ec25498a971f 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -65,12 +65,9 @@ static void dma_buf_release(struct dentry *dentry)
BUG_ON(dmabuf->vmapping_counter);
/*
-* Any fences that a dma-buf poll can wait on should be signaled
-* before releasing dma-buf. This is the responsibility of each
-* driver that uses the reservation objects.
-*
-* If you hit this BUG() it means someone dropped their ref to the
-* dma-buf while still having pending operation to the buffer.
+* If you hit this BUG() it could mean:
+* * There's a file reference imbalance in dma_buf_poll /
dma_buf_poll_cb or somewhere else
+* * dmabuf->cb_in/out.active are non-0 despite no pending fence
callback
*/
BUG_ON(dmabuf->cb_in.active || dmabuf->cb_out.active);
@@ -196,6 +193,7 @@ static loff_t dma_buf_llseek(struct file *file, loff_t offset, int whence)
static void dma_buf_poll_cb(struct dma_fence *fence, struct dma_fence_cb *cb)
{
struct dma_buf_poll_cb_t *dcb = (struct dma_buf_poll_cb_t *)cb;
+ struct dma_buf *dmabuf = container_of(dcb->poll, struct dma_buf, poll);
unsigned long flags;
spin_lock_irqsave(&dcb->poll->lock, flags);
@@ -203,6 +201,8 @@ static void dma_buf_poll_cb(struct dma_fence *fence, struct
dma_fence_cb *cb)
dcb->active = 0;
spin_unlock_irqrestore(&dcb->poll->lock, flags);
dma_fence_put(fence);
+ /* Paired with get_file in dma_buf_poll */
+ fput(dmabuf->file);
Is calling fput() in interrupt context ok? IIRC that could potentially
sleep.
Regards,
Christian.
}
static bool dma_buf_poll_shared(struct dma_resv *resv,
@@ -278,6 +278,9 @@ static __poll_t dma_buf_poll(struct file *file, poll_table
*poll)
spin_unlock_irq(&dmabuf->poll.lock);
if (events & EPOLLOUT) {
+ /* Paired with fput in dma_buf_poll_cb */
+ get_file(dmabuf->file);
+
if (!dma_buf_poll_shared(resv, dcb) &&
!dma_buf_poll_excl(resv, dcb))
/* No callback queued, wake up any other
waiters */
@@ -299,6 +302,9 @@ static __poll_t dma_buf_poll(struct file *file, poll_table
*poll)
spin_unlock_irq(&dmabuf->poll.lock);
if (events & EPOLLIN) {
+ /* Paired with fput in dma_buf_poll_cb */
+ get_file(dmabuf->file);
+
if (!dma_buf_poll_excl(resv, dcb))
/* No callback queued, wake up any other
waiters */
dma_buf_poll_cb(NULL, &dcb->cb);
Re: [PATCH] dma-buf/poll: Get a file reference for outstanding fence callbacks
On 2021-07-23 10:04 a.m., Christian König wrote:
> Am 23.07.21 um 09:58 schrieb Michel Dänzer:
>> From: Michel Dänzer
>>
>> This makes sure we don't hit the
>>
>> BUG_ON(dmabuf->cb_in.active || dmabuf->cb_out.active);
>>
>> in dma_buf_release, which could be triggered by user space closing the
>> dma-buf file description while there are outstanding fence callbacks
>> from dma_buf_poll.
>
> I was also wondering the same thing while working on this, but then thought
> that the poll interface would take care of this.
I was able to hit the BUG_ON with
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880 .
>> Cc: sta...@vger.kernel.org
>> Signed-off-by: Michel Dänzer
>> ---
>> drivers/dma-buf/dma-buf.c | 18 --
>> 1 file changed, 12 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>> index 6c520c9bd93c..ec25498a971f 100644
>> --- a/drivers/dma-buf/dma-buf.c
>> +++ b/drivers/dma-buf/dma-buf.c
>> @@ -65,12 +65,9 @@ static void dma_buf_release(struct dentry *dentry)
>> BUG_ON(dmabuf->vmapping_counter);
>> /*
>> - * Any fences that a dma-buf poll can wait on should be signaled
>> - * before releasing dma-buf. This is the responsibility of each
>> - * driver that uses the reservation objects.
>> - *
>> - * If you hit this BUG() it means someone dropped their ref to the
>> - * dma-buf while still having pending operation to the buffer.
>> + * If you hit this BUG() it could mean:
>> + * * There's a file reference imbalance in dma_buf_poll /
>> dma_buf_poll_cb or somewhere else
>> + * * dmabuf->cb_in/out.active are non-0 despite no pending fence
>> callback
>> */
>> BUG_ON(dmabuf->cb_in.active || dmabuf->cb_out.active);
>> @@ -196,6 +193,7 @@ static loff_t dma_buf_llseek(struct file *file, loff_t
>> offset, int whence)
>> static void dma_buf_poll_cb(struct dma_fence *fence, struct dma_fence_cb
>> *cb)
>> {
>> struct dma_buf_poll_cb_t *dcb = (struct dma_buf_poll_cb_t *)cb;
>> + struct dma_buf *dmabuf = container_of(dcb->poll, struct dma_buf, poll);
>> unsigned long flags;
>> spin_lock_irqsave(&dcb->poll->lock, flags);
>> @@ -203,6 +201,8 @@ static void dma_buf_poll_cb(struct dma_fence *fence,
>> struct dma_fence_cb *cb)
>> dcb->active = 0;
>> spin_unlock_irqrestore(&dcb->poll->lock, flags);
>> dma_fence_put(fence);
>> + /* Paired with get_file in dma_buf_poll */
>> + fput(dmabuf->file);
>
> Is calling fput() in interrupt context ok? IIRC that could potentially sleep.
Looks fine AFAICT: It has
if (likely(!in_interrupt() && !(task->flags & PF_KTHREAD))) {
and as a fallback for that, it adds the file to a lock-less delayed_fput_list
which is processed by a workqueue.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
Re: [PATCH v3 1/1] drm/ttm: Fix COW check
On Wed, Jul 14, 2021 at 10:51 AM Christian König
wrote:
>
>
>
> Am 13.07.21 um 17:28 schrieb Alex Deucher:
> > On Tue, Jul 13, 2021 at 2:57 AM Christian König
> > wrote:
> >>
> >>
> >> Am 13.07.21 um 00:06 schrieb Felix Kuehling:
> >>> KFD Thunk maps invisible VRAM BOs with PROT_NONE, MAP_PRIVATE.
> >>> is_cow_mapping returns true for these mappings. Add a check for
> >>> vm_flags & VM_WRITE to avoid mmap failures on private read-only or
> >>> PROT_NONE mappings.
> >>>
> >>> v2: protect against mprotect making a mapping writable after the fact
> >>> v3: update driver-specific vm_operations_structs
> >>>
> >>> Fixes: f91142c62161 ("drm/ttm: nuke VM_MIXEDMAP on BO mappings v3")
> >>> Signed-off-by: Felix Kuehling
> >>> Signed-off-by: Alex Deucher
> >> Reviewed-by: Christian König
> > Are you planning to push this to drm-misc?
>
> Yes, just didn't found time yesterday.
This is pushed to the wrong tree drm-misc-next-fixes, should have been
in drm-misc-fixes. Please be careful with that because every time that
goes wrong the script gets confused about which the current tree is,
and pushes the wrong tree to linux-next branches.
I'm going to hard-reset drm-misc-next-fixes now and hope that's good
enough to fix things up (since Thomas is not around all the time for
this merge window).
-Daniel
>
> Christian.
>
> >
> > Alex
> >
> >>> ---
> >>>drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 3 ++-
> >>>drivers/gpu/drm/nouveau/nouveau_gem.c| 3 ++-
> >>>drivers/gpu/drm/radeon/radeon_gem.c | 3 ++-
> >>>drivers/gpu/drm/ttm/ttm_bo_vm.c | 14 +-
> >>>drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c | 1 +
> >>>include/drm/ttm/ttm_bo_api.h | 4
> >>>6 files changed, 24 insertions(+), 4 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> >>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> >>> index b3404c43a911..1aa750a6a5d2 100644
> >>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> >>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> >>> @@ -79,7 +79,8 @@ static const struct vm_operations_struct
> >>> amdgpu_gem_vm_ops = {
> >>>.fault = amdgpu_gem_fault,
> >>>.open = ttm_bo_vm_open,
> >>>.close = ttm_bo_vm_close,
> >>> - .access = ttm_bo_vm_access
> >>> + .access = ttm_bo_vm_access,
> >>> + .mprotect = ttm_bo_vm_mprotect
> >>>};
> >>>
> >>>static void amdgpu_gem_object_free(struct drm_gem_object *gobj)
> >>> diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
> >>> b/drivers/gpu/drm/nouveau/nouveau_gem.c
> >>> index 5b27845075a1..164ea564bb7a 100644
> >>> --- a/drivers/gpu/drm/nouveau/nouveau_gem.c
> >>> +++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
> >>> @@ -70,7 +70,8 @@ static const struct vm_operations_struct
> >>> nouveau_ttm_vm_ops = {
> >>>.fault = nouveau_ttm_fault,
> >>>.open = ttm_bo_vm_open,
> >>>.close = ttm_bo_vm_close,
> >>> - .access = ttm_bo_vm_access
> >>> + .access = ttm_bo_vm_access,
> >>> + .mprotect = ttm_bo_vm_mprotect
> >>>};
> >>>
> >>>void
> >>> diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
> >>> b/drivers/gpu/drm/radeon/radeon_gem.c
> >>> index 458f92a70887..c19ad07eb7b5 100644
> >>> --- a/drivers/gpu/drm/radeon/radeon_gem.c
> >>> +++ b/drivers/gpu/drm/radeon/radeon_gem.c
> >>> @@ -77,7 +77,8 @@ static const struct vm_operations_struct
> >>> radeon_gem_vm_ops = {
> >>>.fault = radeon_gem_fault,
> >>>.open = ttm_bo_vm_open,
> >>>.close = ttm_bo_vm_close,
> >>> - .access = ttm_bo_vm_access
> >>> + .access = ttm_bo_vm_access,
> >>> + .mprotect = ttm_bo_vm_mprotect
> >>>};
> >>>
> >>>static void radeon_gem_object_free(struct drm_gem_object *gobj)
> >>> diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> >>> b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> >>> index f56be5bc0861..fb325bad5db6 100644
> >>> --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> >>> +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> >>> @@ -542,17 +542,29 @@ int ttm_bo_vm_access(struct vm_area_struct *vma,
> >>> unsigned long addr,
> >>>}
> >>>EXPORT_SYMBOL(ttm_bo_vm_access);
> >>>
> >>> +int ttm_bo_vm_mprotect(struct vm_area_struct *vma, unsigned long start,
> >>> +unsigned long end, unsigned long newflags)
> >>> +{
> >>> + /* Enforce no COW since would have really strange behavior with it.
> >>> */
> >>> + if (is_cow_mapping(newflags) && (newflags & VM_WRITE))
> >>> + return -EINVAL;
> >>> +
> >>> + return 0;
> >>> +}
> >>> +EXPORT_SYMBOL(ttm_bo_vm_mprotect);
> >>> +
> >>>static const struct vm_operations_struct ttm_bo_vm_ops = {
> >>>.fault = ttm_bo_vm_fault,
> >>>.open = ttm_bo_vm_open,
> >>>.close = ttm_bo_vm_close,
> >>>.access = ttm_bo_vm_access,
> >>> + .mprotect = ttm_bo_vm_mprotect,
> >>>};
> >>>
> >>>int ttm_bo_mmap_obj(struct vm_area_struct *vma, struct
> >>> ttm_buffer_object *bo)
> >>>{
> >>>/* Enforce no CO
Re: [Linaro-mm-sig] [PATCH] dma-buf/poll: Get a file reference for outstanding fence callbacks
Am 23.07.21 um 10:19 schrieb Michel Dänzer:
On 2021-07-23 10:04 a.m., Christian König wrote:
Am 23.07.21 um 09:58 schrieb Michel Dänzer:
From: Michel Dänzer
This makes sure we don't hit the
BUG_ON(dmabuf->cb_in.active || dmabuf->cb_out.active);
in dma_buf_release, which could be triggered by user space closing the
dma-buf file description while there are outstanding fence callbacks
from dma_buf_poll.
I was also wondering the same thing while working on this, but then thought
that the poll interface would take care of this.
I was able to hit the BUG_ON with
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880 .
Cc: sta...@vger.kernel.org
Signed-off-by: Michel Dänzer
---
drivers/dma-buf/dma-buf.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 6c520c9bd93c..ec25498a971f 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -65,12 +65,9 @@ static void dma_buf_release(struct dentry *dentry)
BUG_ON(dmabuf->vmapping_counter);
/*
- * Any fences that a dma-buf poll can wait on should be signaled
- * before releasing dma-buf. This is the responsibility of each
- * driver that uses the reservation objects.
- *
- * If you hit this BUG() it means someone dropped their ref to the
- * dma-buf while still having pending operation to the buffer.
+ * If you hit this BUG() it could mean:
+ * * There's a file reference imbalance in dma_buf_poll / dma_buf_poll_cb
or somewhere else
+ * * dmabuf->cb_in/out.active are non-0 despite no pending fence callback
*/
BUG_ON(dmabuf->cb_in.active || dmabuf->cb_out.active);
@@ -196,6 +193,7 @@ static loff_t dma_buf_llseek(struct file *file, loff_t
offset, int whence)
static void dma_buf_poll_cb(struct dma_fence *fence, struct dma_fence_cb *cb)
{
struct dma_buf_poll_cb_t *dcb = (struct dma_buf_poll_cb_t *)cb;
+ struct dma_buf *dmabuf = container_of(dcb->poll, struct dma_buf, poll);
unsigned long flags;
spin_lock_irqsave(&dcb->poll->lock, flags);
@@ -203,6 +201,8 @@ static void dma_buf_poll_cb(struct dma_fence *fence, struct
dma_fence_cb *cb)
dcb->active = 0;
spin_unlock_irqrestore(&dcb->poll->lock, flags);
dma_fence_put(fence);
+ /* Paired with get_file in dma_buf_poll */
+ fput(dmabuf->file);
Is calling fput() in interrupt context ok? IIRC that could potentially sleep.
Looks fine AFAICT: It has
if (likely(!in_interrupt() && !(task->flags & PF_KTHREAD))) {
and as a fallback for that, it adds the file to a lock-less delayed_fput_list
which is processed by a workqueue.
Ah, yes that makes sense.
Fell free to add Reviewed-by: Christian König
Thanks,
Christian.
Re: [PATCH v2 0/9] PCI/VGA: Rework default VGA device selection
On Fri, Jul 23, 2021 at 06:51:59AM +0100, Christoph Hellwig wrote: > On Thu, Jul 22, 2021 at 04:29:11PM -0500, Bjorn Helgaas wrote: > > From: Bjorn Helgaas > > > > This is a little bit of rework and extension of Huacai's nice work at [1]. > > > > It moves the VGA arbiter to the PCI subsystem, fixes a few nits, and breaks > > a few pieces off Huacai's patch to make the main patch a little smaller. > > > > That last patch is still not very small, and it needs a commit log, as I > > mentioned at [2]. > > FYI, I have a bunch of changes to this code that the drm maintainers > picked up. They should show up in the next linux-next I think. Yeah I think for merging I think there'll be two options: - We also merge this series through drm-misc-next to avoid conflicts, but anything after that will (i.e. from 5.16-rc1 onwards) will go in through the pci tree. - You also merge Christoph's series, and we tell Linus to ignore the vgaarb changes that also come in through drm-next pull. It's a non-rebasing tree so taking them out isn't an option, and reverting feels silly. Either of the above is fine with me. Also I just noticed that the scrip has gone wrong for drm-misc-next and it's not actually yet in linux-next. I'll sort that out. Ok I just did sort that out while I forgot this reply draft here, one of our committers pushed a patch to the wrong branch. Luckily it was a broken one and the right fix is in the right branch (and already in Linus' tree), so a hard reset was all it took. So should be all in linux-next on the next update. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH v3 1/1] drm/ttm: Fix COW check
Am 23.07.21 um 10:21 schrieb Daniel Vetter:
On Wed, Jul 14, 2021 at 10:51 AM Christian König
wrote:
Am 13.07.21 um 17:28 schrieb Alex Deucher:
On Tue, Jul 13, 2021 at 2:57 AM Christian König
wrote:
Am 13.07.21 um 00:06 schrieb Felix Kuehling:
KFD Thunk maps invisible VRAM BOs with PROT_NONE, MAP_PRIVATE.
is_cow_mapping returns true for these mappings. Add a check for
vm_flags & VM_WRITE to avoid mmap failures on private read-only or
PROT_NONE mappings.
v2: protect against mprotect making a mapping writable after the fact
v3: update driver-specific vm_operations_structs
Fixes: f91142c62161 ("drm/ttm: nuke VM_MIXEDMAP on BO mappings v3")
Signed-off-by: Felix Kuehling
Signed-off-by: Alex Deucher
Reviewed-by: Christian König
Are you planning to push this to drm-misc?
Yes, just didn't found time yesterday.
This is pushed to the wrong tree drm-misc-next-fixes, should have been
in drm-misc-fixes. Please be careful with that because every time that
goes wrong the script gets confused about which the current tree is,
and pushes the wrong tree to linux-next branches.
I'm going to hard-reset drm-misc-next-fixes now and hope that's good
enough to fix things up (since Thomas is not around all the time for
this merge window).
STOP! I'm about to push a revert for this patch.
And yes that was pushed to the wrong branch, but it turned out that this
was fortunate since the patch doesn't work correctly.
Christian.
-Daniel
Christian.
Alex
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 3 ++-
drivers/gpu/drm/nouveau/nouveau_gem.c| 3 ++-
drivers/gpu/drm/radeon/radeon_gem.c | 3 ++-
drivers/gpu/drm/ttm/ttm_bo_vm.c | 14 +-
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c | 1 +
include/drm/ttm/ttm_bo_api.h | 4
6 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index b3404c43a911..1aa750a6a5d2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -79,7 +79,8 @@ static const struct vm_operations_struct amdgpu_gem_vm_ops = {
.fault = amdgpu_gem_fault,
.open = ttm_bo_vm_open,
.close = ttm_bo_vm_close,
- .access = ttm_bo_vm_access
+ .access = ttm_bo_vm_access,
+ .mprotect = ttm_bo_vm_mprotect
};
static void amdgpu_gem_object_free(struct drm_gem_object *gobj)
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index 5b27845075a1..164ea564bb7a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -70,7 +70,8 @@ static const struct vm_operations_struct nouveau_ttm_vm_ops =
{
.fault = nouveau_ttm_fault,
.open = ttm_bo_vm_open,
.close = ttm_bo_vm_close,
- .access = ttm_bo_vm_access
+ .access = ttm_bo_vm_access,
+ .mprotect = ttm_bo_vm_mprotect
};
void
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index 458f92a70887..c19ad07eb7b5 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -77,7 +77,8 @@ static const struct vm_operations_struct radeon_gem_vm_ops = {
.fault = radeon_gem_fault,
.open = ttm_bo_vm_open,
.close = ttm_bo_vm_close,
- .access = ttm_bo_vm_access
+ .access = ttm_bo_vm_access,
+ .mprotect = ttm_bo_vm_mprotect
};
static void radeon_gem_object_free(struct drm_gem_object *gobj)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index f56be5bc0861..fb325bad5db6 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -542,17 +542,29 @@ int ttm_bo_vm_access(struct vm_area_struct *vma, unsigned
long addr,
}
EXPORT_SYMBOL(ttm_bo_vm_access);
+int ttm_bo_vm_mprotect(struct vm_area_struct *vma, unsigned long start,
+unsigned long end, unsigned long newflags)
+{
+ /* Enforce no COW since would have really strange behavior with it. */
+ if (is_cow_mapping(newflags) && (newflags & VM_WRITE))
+ return -EINVAL;
+
+ return 0;
+}
+EXPORT_SYMBOL(ttm_bo_vm_mprotect);
+
static const struct vm_operations_struct ttm_bo_vm_ops = {
.fault = ttm_bo_vm_fault,
.open = ttm_bo_vm_open,
.close = ttm_bo_vm_close,
.access = ttm_bo_vm_access,
+ .mprotect = ttm_bo_vm_mprotect,
};
int ttm_bo_mmap_obj(struct vm_area_struct *vma, struct ttm_buffer_object
*bo)
{
/* Enforce no COW since would have really strange behavior with it. */
- if (is_cow_mapping(vma->vm_flags))
+ if (is_cow_mapping(vma->vm_flags) && (vma->vm_flags & VM_WRITE))
return -EINVAL;
ttm_bo_get(bo);
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
index e6b1f98ec99f..e4bf7dc99320 100644
--- a/drivers/gp
Re: [PATCH v4 3/4] drm/shmem-helpers: Allocate wc pages on x86
On Fri, Jul 23, 2021 at 10:02:39AM +0200, Christian König wrote:
> Am 23.07.21 um 09:36 schrieb Daniel Vetter:
> > On Thu, Jul 22, 2021 at 08:40:56PM +0200, Thomas Zimmermann wrote:
> > > Hi
> > >
> > > Am 13.07.21 um 22:51 schrieb Daniel Vetter:
> > > [SNIP]
> > > > +#ifdef CONFIG_X86
> > > > + if (shmem->map_wc)
> > > > + set_pages_array_wc(pages, obj->size >> PAGE_SHIFT);
> > > > +#endif
> > > I cannot comment much on the technical details of the caching of various
> > > architectures. If this patch goes in, there should be a longer comment
> > > that
> > > reflects the discussion in this thread. It's apparently a workaround.
> > >
> > > I think the call itself should be hidden behind a DRM API, which depends
> > > on
> > > CONFIG_X86. Something simple like
> > >
> > > ifdef CONFIG_X86
> > > drm_set_pages_array_wc()
> > > {
> > > set_pages_array_wc();
> > > }
> > > else
> > > drm_set_pages_array_wc()
> > > {
> > > }
> > > #endif
> > >
> > > Maybe in drm_cache.h?
> > We do have a bunch of this in drm_cache.h already, and architecture
> > maintainers hate us for it.
>
> Yeah, for good reasons :)
>
> > The real fix is to get at the architecture-specific wc allocator, which is
> > currently not something that's exposed, but hidden within the dma api. I
> > think having this stick out like this is better than hiding it behind fake
> > generic code (like we do with drm_clflush, which defacto also only really
> > works on x86).
>
> The DMA API also doesn't really touch that stuff as far as I know.
>
> What we rather do on other architectures is to set the appropriate caching
> flags on the CPU mappings, see function ttm_prot_from_caching().
This alone doesn't do cache flushes. And at least on some arm cpus having
inconsistent mappings can lead to interconnect hangs, so you have to at
least punch out the kernel linear map. Which on some arms isn't possible
(because the kernel map is a special linear map and not done with
pagetables). Which means you need to carve this out at boot and treat them
as GFP_HIGHMEM.
Afaik dma-api has that allocator somewhere which dtrt for
dma_alloc_coherent.
Also shmem helpers already set the caching pgprot.
> > Also note that ttm has the exact same ifdef in its page allocator, but it
> > does fall back to using dma_alloc_coherent on other platforms.
>
> This works surprisingly well on non x86 architectures as well. We just don't
> necessary update the kernel mappings everywhere which limits the kmap usage.
>
> In other words radeon and nouveau still work on PowerPC AGP systems as far
> as I know for example.
The thing is, on most cpus you get away with just pgprot set to wc, and on
many others it's only an issue while there's still some cpu dirt hanging
around because they don't prefetch badly enough. It's very few were it's a
persistent problem.
Really the only reason I've even caught this was because some of the
i915+vgem buffer sharing tests we have are very nasty and intentionally
try to provoke the worst case :-)
Anyway, since you're looking, can you pls review this and the previous
patch for shmem helpers?
The first one to make VM_PFNMAP standard for all dma-buf isn't ready yet,
because I need to audit all the driver still. And at least i915 dma-buf
mmap is still using gup-able memory too. So more work to do here.
-Danel
>
> Christian.
>
> > -Daniel
> >
> > > Best regard
> > > Thomas
> > >
> > > > +
> > > > shmem->pages = pages;
> > > > return 0;
> > > > @@ -203,6 +212,11 @@ static void drm_gem_shmem_put_pages_locked(struct
> > > > drm_gem_shmem_object *shmem)
> > > > if (--shmem->pages_use_count > 0)
> > > > return;
> > > > +#ifdef CONFIG_X86
> > > > + if (shmem->map_wc)
> > > > + set_pages_array_wb(shmem->pages, obj->size >>
> > > > PAGE_SHIFT);
> > > > +#endif
> > > > +
> > > > drm_gem_put_pages(obj, shmem->pages,
> > > > shmem->pages_mark_dirty_on_put,
> > > > shmem->pages_mark_accessed_on_put);
> > > >
> > > --
> > > Thomas Zimmermann
> > > Graphics Driver Developer
> > > SUSE Software Solutions Germany GmbH
> > > Maxfeldstr. 5, 90409 Nürnberg, Germany
> > > (HRB 36809, AG Nürnberg)
> > > Geschäftsführer: Felix Imendörffer
> > >
> >
> >
> >
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH 1/3] drm/plane: remove drm_helper_get_plane_damage_clips
It's not used. Drivers should instead use the helpers anyway.
Currently both vbox and i915 hand-roll this and it's not the greatest.
vbox looks buggy, and i915 does a bit much that helpers would take
care of I think.
Also improve the kerneldocs while we're at it.
Reviewed-by: José Roberto de Souza
Cc: Ville Syrjälä
Cc: Gwan-gyeong Mun
Cc: José Roberto de Souza
Cc: Hans de Goede
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_damage_helper.c | 2 +-
include/drm/drm_damage_helper.h | 17 -
include/drm/drm_plane.h | 10 +++---
include/drm/drm_rect.h | 3 +++
4 files changed, 11 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/drm_damage_helper.c
b/drivers/gpu/drm/drm_damage_helper.c
index 3a4126dc2520..eb69b7123af5 100644
--- a/drivers/gpu/drm/drm_damage_helper.c
+++ b/drivers/gpu/drm/drm_damage_helper.c
@@ -282,7 +282,7 @@ drm_atomic_helper_damage_iter_init(struct
drm_atomic_helper_damage_iter *iter,
if (!state || !state->crtc || !state->fb || !state->visible)
return;
- iter->clips = drm_helper_get_plane_damage_clips(state);
+ iter->clips = (struct drm_rect *)drm_plane_get_damage_clips(state);
iter->num_clips = drm_plane_get_damage_clips_count(state);
/* Round down for x1/y1 and round up for x2/y2 to catch all pixels */
diff --git a/include/drm/drm_damage_helper.h b/include/drm/drm_damage_helper.h
index 40c34a5bf149..1ae8bce6a5ce 100644
--- a/include/drm/drm_damage_helper.h
+++ b/include/drm/drm_damage_helper.h
@@ -82,21 +82,4 @@ bool drm_atomic_helper_damage_merged(const struct
drm_plane_state *old_state,
struct drm_plane_state *state,
struct drm_rect *rect);
-/**
- * drm_helper_get_plane_damage_clips - Returns damage clips in &drm_rect.
- * @state: Plane state.
- *
- * Returns plane damage rectangles in internal &drm_rect. Currently &drm_rect
- * can be obtained by simply typecasting &drm_mode_rect. This is because both
- * are signed 32 and during drm_atomic_check_only() it is verified that damage
- * clips are inside fb.
- *
- * Return: Clips in plane fb_damage_clips blob property.
- */
-static inline struct drm_rect *
-drm_helper_get_plane_damage_clips(const struct drm_plane_state *state)
-{
- return (struct drm_rect *)drm_plane_get_damage_clips(state);
-}
-
#endif
diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index 1294610e84f4..7f7d5148310c 100644
--- a/include/drm/drm_plane.h
+++ b/include/drm/drm_plane.h
@@ -186,6 +186,9 @@ struct drm_plane_state {
* since last plane update) as an array of &drm_mode_rect in framebuffer
* coodinates of the attached framebuffer. Note that unlike plane src,
* damage clips are not in 16.16 fixed point.
+*
+* See drm_plane_get_damage_clips() and
+* drm_plane_get_damage_clips_count() for accessing these.
*/
struct drm_property_blob *fb_damage_clips;
@@ -914,9 +917,10 @@ drm_plane_get_damage_clips_count(const struct
drm_plane_state *state)
* drm_plane_get_damage_clips - Returns damage clips.
* @state: Plane state.
*
- * Note that this function returns uapi type &drm_mode_rect. Drivers might
- * instead be interested in internal &drm_rect which can be obtained by calling
- * drm_helper_get_plane_damage_clips().
+ * Note that this function returns uapi type &drm_mode_rect. Drivers might want
+ * to use the helper functions drm_atomic_helper_damage_iter_init() and
+ * drm_atomic_helper_damage_iter_next() or drm_atomic_helper_damage_merged() if
+ * the driver can only handle a single damage region at most.
*
* Return: Damage clips in plane fb_damage_clips blob property.
*/
diff --git a/include/drm/drm_rect.h b/include/drm/drm_rect.h
index 39f2deee709c..6f6e19bd4dac 100644
--- a/include/drm/drm_rect.h
+++ b/include/drm/drm_rect.h
@@ -39,6 +39,9 @@
* @x2: horizontal ending coordinate (exclusive)
* @y1: vertical starting coordinate (inclusive)
* @y2: vertical ending coordinate (exclusive)
+ *
+ * Note that this must match the layout of struct drm_mode_rect or the damage
+ * helpers like drm_atomic_helper_damage_iter_init() break.
*/
struct drm_rect {
int x1, y1, x2, y2;
--
2.32.0
[PATCH 2/3] drm/plane: check that fb_damage is set up when used
There's two stages of manual upload/invalidate displays:
- just handling dirtyfb and uploading the entire fb all the time
- looking at damage clips
In the latter case we support it through fbdev emulation (with
fb_defio), atomic property, and with the dirtfy clip rects.
Make sure at least the atomic property is set up as the main official
interface for this. Ideally we'd also check that
drm_atomic_helper_dirtyfb() is used and that fbdev defio is set up,
but that's quite a bit harder to do. Ideas very much welcome.
>From a cursor audit drivers seem to be getting this right mostly, but
better to make sure. At least no one is bypassing the accessor
function.
v2:
- use drm_warn_once with a meaningful warning string (José)
- don't splat in the atomic check code for everyone (intel-gfx-ci)
Reviewed-by: José Roberto de Souza (v1)
Cc: Ville Syrjälä
Cc: Gwan-gyeong Mun
Cc: José Roberto de Souza
Cc: Hans de Goede
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_atomic.c| 2 +-
drivers/gpu/drm/drm_crtc_internal.h | 2 ++
drivers/gpu/drm/drm_plane.c | 50 +
include/drm/drm_plane.h | 36 +++--
4 files changed, 57 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index d820423fac32..c85dcfd69158 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -660,7 +660,7 @@ static int drm_atomic_plane_check(const struct
drm_plane_state *old_plane_state,
return -ENOSPC;
}
- clips = drm_plane_get_damage_clips(new_plane_state);
+ clips = __drm_plane_get_damage_clips(new_plane_state);
num_clips = drm_plane_get_damage_clips_count(new_plane_state);
/* Make sure damage clips are valid and inside the fb. */
diff --git a/drivers/gpu/drm/drm_crtc_internal.h
b/drivers/gpu/drm/drm_crtc_internal.h
index 1ca51addb589..edb772947cb4 100644
--- a/drivers/gpu/drm/drm_crtc_internal.h
+++ b/drivers/gpu/drm/drm_crtc_internal.h
@@ -262,6 +262,8 @@ int drm_plane_register_all(struct drm_device *dev);
void drm_plane_unregister_all(struct drm_device *dev);
int drm_plane_check_pixel_format(struct drm_plane *plane,
u32 format, u64 modifier);
+struct drm_mode_rect *
+__drm_plane_get_damage_clips(const struct drm_plane_state *state);
/* drm_bridge.c */
void drm_bridge_detach(struct drm_bridge *bridge);
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index b373958ecb30..f61315b61174 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -1397,6 +1397,56 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
return ret;
}
+/**
+ * drm_plane_get_damage_clips_count - Returns damage clips count.
+ * @state: Plane state.
+ *
+ * Simple helper to get the number of &drm_mode_rect clips set by user-space
+ * during plane update.
+ *
+ * Return: Number of clips in plane fb_damage_clips blob property.
+ */
+unsigned int
+drm_plane_get_damage_clips_count(const struct drm_plane_state *state)
+{
+ return (state && state->fb_damage_clips) ?
+ state->fb_damage_clips->length/sizeof(struct drm_mode_rect) : 0;
+}
+EXPORT_SYMBOL(drm_plane_get_damage_clips_count);
+
+struct drm_mode_rect *
+__drm_plane_get_damage_clips(const struct drm_plane_state *state)
+{
+ return (struct drm_mode_rect *)((state && state->fb_damage_clips) ?
+ state->fb_damage_clips->data : NULL);
+}
+
+/**
+ * drm_plane_get_damage_clips - Returns damage clips.
+ * @state: Plane state.
+ *
+ * Note that this function returns uapi type &drm_mode_rect. Drivers might want
+ * to use the helper functions drm_atomic_helper_damage_iter_init() and
+ * drm_atomic_helper_damage_iter_next() or drm_atomic_helper_damage_merged() if
+ * the driver can only handle a single damage region at most.
+ *
+ * Return: Damage clips in plane fb_damage_clips blob property.
+ */
+struct drm_mode_rect *
+drm_plane_get_damage_clips(const struct drm_plane_state *state)
+{
+ struct drm_device *dev = state->plane->dev;
+ struct drm_mode_config *config = &dev->mode_config;
+
+ /* check that drm_plane_enable_fb_damage_clips() was called */
+ if (!drm_mode_obj_find_prop_id(&state->plane->base,
+ config->prop_fb_damage_clips->base.id))
+ drm_warn_once(dev, "drm_plane_enable_fb_damage_clips() not
called\n");
+
+ return __drm_plane_get_damage_clips(state);
+}
+EXPORT_SYMBOL(drm_plane_get_damage_clips);
+
struct drm_property *
drm_create_scaling_filter_prop(struct drm_device *dev,
unsigned int supported_filters)
diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index 7f7d5148310c..a2684aab8372 100644
--- a/include/drm/drm_plane.h
+++ b/in
[PATCH 3/3] drm/plane: Move drm_plane_enable_fb_damage_clips into core
We're trying to have a fairly strict split between core functionality
that defines the uapi, including the docs, and the helper functions to
implement it.
Move drm_plane_enable_fb_damage_clips and associated kerneldoc into
drm_plane from drm_damage_helper.c to fix this.
Reviewed-by: José Roberto de Souza
Cc: Ville Syrjälä
Cc: Gwan-gyeong Mun
Cc: José Roberto de Souza
Cc: Hans de Goede
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
---
Documentation/gpu/drm-kms.rst | 4 +--
drivers/gpu/drm/drm_damage_helper.c | 54 -
drivers/gpu/drm/drm_plane.c | 54 +
include/drm/drm_damage_helper.h | 1 -
include/drm/drm_plane.h | 3 +-
5 files changed, 58 insertions(+), 58 deletions(-)
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 87e5023e3f55..7399f497e7e2 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -508,8 +508,8 @@ Plane Composition Properties
Damage Tracking Properties
--
-.. kernel-doc:: drivers/gpu/drm/drm_damage_helper.c
- :doc: overview
+.. kernel-doc:: drivers/gpu/drm/drm_plane.c
+ :doc: damage tracking
Color Management Properties
---
diff --git a/drivers/gpu/drm/drm_damage_helper.c
b/drivers/gpu/drm/drm_damage_helper.c
index eb69b7123af5..245959dad7bb 100644
--- a/drivers/gpu/drm/drm_damage_helper.c
+++ b/drivers/gpu/drm/drm_damage_helper.c
@@ -34,44 +34,6 @@
#include
#include
-/**
- * DOC: overview
- *
- * FB_DAMAGE_CLIPS is an optional plane property which provides a means to
- * specify a list of damage rectangles on a plane in framebuffer coordinates of
- * the framebuffer attached to the plane. In current context damage is the area
- * of plane framebuffer that has changed since last plane update (also called
- * page-flip), irrespective of whether currently attached framebuffer is same
as
- * framebuffer attached during last plane update or not.
- *
- * FB_DAMAGE_CLIPS is a hint to kernel which could be helpful for some drivers
- * to optimize internally especially for virtual devices where each framebuffer
- * change needs to be transmitted over network, usb, etc.
- *
- * Since FB_DAMAGE_CLIPS is a hint so it is an optional property. User-space
can
- * ignore damage clips property and in that case driver will do a full plane
- * update. In case damage clips are provided then it is guaranteed that the
area
- * inside damage clips will be updated to plane. For efficiency driver can do
- * full update or can update more than specified in damage clips. Since driver
- * is free to read more, user-space must always render the entire visible
- * framebuffer. Otherwise there can be corruptions. Also, if a user-space
- * provides damage clips which doesn't encompass the actual damage to
- * framebuffer (since last plane update) can result in incorrect rendering.
- *
- * FB_DAMAGE_CLIPS is a blob property with the layout of blob data is simply an
- * array of &drm_mode_rect. Unlike plane &drm_plane_state.src coordinates,
- * damage clips are not in 16.16 fixed point. Similar to plane src in
- * framebuffer, damage clips cannot be negative. In damage clip, x1/y1 are
- * inclusive and x2/y2 are exclusive. While kernel does not error for
overlapped
- * damage clips, it is strongly discouraged.
- *
- * Drivers that are interested in damage interface for plane should enable
- * FB_DAMAGE_CLIPS property by calling drm_plane_enable_fb_damage_clips().
- * Drivers implementing damage can use drm_atomic_helper_damage_iter_init() and
- * drm_atomic_helper_damage_iter_next() helper iterator function to get damage
- * rectangles clipped to &drm_plane_state.src.
- */
-
static void convert_clip_rect_to_rect(const struct drm_clip_rect *src,
struct drm_mode_rect *dest,
uint32_t num_clips, uint32_t src_inc)
@@ -87,22 +49,6 @@ static void convert_clip_rect_to_rect(const struct
drm_clip_rect *src,
}
}
-/**
- * drm_plane_enable_fb_damage_clips - Enables plane fb damage clips property.
- * @plane: Plane on which to enable damage clips property.
- *
- * This function lets driver to enable the damage clips property on a plane.
- */
-void drm_plane_enable_fb_damage_clips(struct drm_plane *plane)
-{
- struct drm_device *dev = plane->dev;
- struct drm_mode_config *config = &dev->mode_config;
-
- drm_object_attach_property(&plane->base, config->prop_fb_damage_clips,
- 0);
-}
-EXPORT_SYMBOL(drm_plane_enable_fb_damage_clips);
-
/**
* drm_atomic_helper_check_plane_damage - Verify plane damage on atomic_check.
* @state: The driver state object.
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index f61315b61174..f5fe8255597c 100644
--- a/drivers/gpu/drm/drm_plan
Re: [PATCH 1/5] drm/vmwgfx: unbind in vmw_ttm_unpopulate
On Thu, Jul 22, 2021 at 02:41:23PM +0200, Christian König wrote:
> Doing this in vmw_ttm_destroy() is to late.
>
> It turned out that this is not a good idea at all because it leaves pointers
> to freed up system memory pages in the GART tables of the drivers.
So I wanted to review this series, and I can't reconcile your claim here
with the demidlayering Dave has done. The driver patches here don't
ouright undo what Dave has done, but that means the bug has been
preexisting since forever (or is due to some other change?), and your
commit message is a bit confusing here.
The final patch just undoes the demidlayering from Dave, and I really
don't see where there's even a functional change there.
And even these patches here don't really change a hole lot with the
calling sequence for at least final teardown: ttm_tt_destroy_common calls
ttm_tt_unpopulate as the first thing, so at least there there's no change.
Can you pls elaborate more clearly what exactly you're fixing and what
exactly needs to be reordered and where this bug is from (commit sha1)? As
is I'm playing detective and the evidence presented is extremely since and
I can't reconcile it at all.
I mean I know you don't like typing commit message and documentation, but
it does get occasionally rather frustrating on the reviewer side if I have
to interpolate between some very sparse hints for this stuff :-/
-Daniel
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 9 +++--
> 1 file changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> index b0973c27e774..904031d03dbe 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> @@ -526,14 +526,9 @@ static void vmw_ttm_destroy(struct ttm_device *bdev,
> struct ttm_tt *ttm)
> struct vmw_ttm_tt *vmw_be =
> container_of(ttm, struct vmw_ttm_tt, dma_ttm);
>
> - vmw_ttm_unbind(bdev, ttm);
> ttm_tt_destroy_common(bdev, ttm);
> vmw_ttm_unmap_dma(vmw_be);
> - if (vmw_be->dev_priv->map_mode == vmw_dma_alloc_coherent)
> - ttm_tt_fini(&vmw_be->dma_ttm);
> - else
> - ttm_tt_fini(ttm);
> -
> + ttm_tt_fini(ttm);
> if (vmw_be->mob)
> vmw_mob_destroy(vmw_be->mob);
>
> @@ -578,6 +573,8 @@ static void vmw_ttm_unpopulate(struct ttm_device *bdev,
>dma_ttm);
> unsigned int i;
>
> + vmw_ttm_unbind(bdev, ttm);
> +
> if (vmw_tt->mob) {
> vmw_mob_destroy(vmw_tt->mob);
> vmw_tt->mob = NULL;
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH v3 1/3] drm/loongson: Add DRM Driver for Loongson 7A1000 bridge chip
On Fri, Jul 23, 2021 at 11:12:49AM +0800, lichenyang wrote: > From: Chenyang Li > > This patch adds an initial DRM driver for the Loongson LS7A1000 > bridge chip(LS7A). The LS7A bridge chip contains two display > controllers, support dual display output. The maximum support for > each channel display is to 1920x1080@60Hz. > At present, DC device detection and DRM driver registration are > completed, the crtc/plane/encoder/connector objects has been > implemented. > On Loongson 3A4000 CPU and 7A1000 system, we have achieved the use > of dual screen, and support dual screen clone mode and expansion > mode. > > v9: > - Optimize the error handling process. > - Remove the useless flags parameter. > - Fix some incorrect use of variables and constructs. > > v8: > - Update the atomic_update function interface. > > v7: > - The pixel clock is limited to less than 173000. > > v6: > - Remove spin_lock in mmio reg read and write. > - TO_UNCAC is replac with ioremap. > - Fix error arguments in crtc_atomic_enable/disable/mode_valid. > > v5: > - Change the name of the chip to LS7A. > - Change magic value in crtc to macros. > - Correct mistakes words. > - Change the register operation function prefix to ls7a. > > v4: > - Move the mode_valid function to the crtc. > > v3: > - Move the mode_valid function to the connector and optimize it. > - Fix num_crtc calculation method. > > v2: > - Complete the case of 32-bit color in CRTC. > > Signed-off-by: Chenyang Li Somehow this simple driver is at v9 and still not landed. Do you have someone from the drm maintainers/committers who's guiding you through all this? I'm not seeing you Cc: a specific person, without that there's good chances your contribution gets lost. I'm swamped myself, which is why I've ignored this and hope you'd fine someone else and stick to them. A few comments below. > --- > drivers/gpu/drm/Kconfig | 2 + > drivers/gpu/drm/Makefile | 1 + > drivers/gpu/drm/loongson/Kconfig | 14 + > drivers/gpu/drm/loongson/Makefile | 14 + > drivers/gpu/drm/loongson/loongson_connector.c | 46 +++ > drivers/gpu/drm/loongson/loongson_crtc.c | 249 > drivers/gpu/drm/loongson/loongson_device.c| 35 +++ > drivers/gpu/drm/loongson/loongson_drv.c | 278 ++ > drivers/gpu/drm/loongson/loongson_drv.h | 140 + > drivers/gpu/drm/loongson/loongson_encoder.c | 37 +++ > drivers/gpu/drm/loongson/loongson_plane.c | 97 ++ > 11 files changed, 913 insertions(+) > create mode 100644 drivers/gpu/drm/loongson/Kconfig > create mode 100644 drivers/gpu/drm/loongson/Makefile > create mode 100644 drivers/gpu/drm/loongson/loongson_connector.c > create mode 100644 drivers/gpu/drm/loongson/loongson_crtc.c > create mode 100644 drivers/gpu/drm/loongson/loongson_device.c > create mode 100644 drivers/gpu/drm/loongson/loongson_drv.c > create mode 100644 drivers/gpu/drm/loongson/loongson_drv.h > create mode 100644 drivers/gpu/drm/loongson/loongson_encoder.c > create mode 100644 drivers/gpu/drm/loongson/loongson_plane.c > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > index 7ff89690a976..08562d9be6e3 100644 > --- a/drivers/gpu/drm/Kconfig > +++ b/drivers/gpu/drm/Kconfig > @@ -365,6 +365,8 @@ source "drivers/gpu/drm/xen/Kconfig" > > source "drivers/gpu/drm/vboxvideo/Kconfig" > > +source "drivers/gpu/drm/loongson/Kconfig" > + > source "drivers/gpu/drm/lima/Kconfig" > > source "drivers/gpu/drm/panfrost/Kconfig" > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile > index a118692a6df7..29c05b8cf2ad 100644 > --- a/drivers/gpu/drm/Makefile > +++ b/drivers/gpu/drm/Makefile > @@ -119,6 +119,7 @@ obj-$(CONFIG_DRM_PL111) += pl111/ > obj-$(CONFIG_DRM_TVE200) += tve200/ > obj-$(CONFIG_DRM_XEN) += xen/ > obj-$(CONFIG_DRM_VBOXVIDEO) += vboxvideo/ > +obj-$(CONFIG_DRM_LOONGSON) += loongson/ > obj-$(CONFIG_DRM_LIMA) += lima/ > obj-$(CONFIG_DRM_PANFROST) += panfrost/ > obj-$(CONFIG_DRM_ASPEED_GFX) += aspeed/ > diff --git a/drivers/gpu/drm/loongson/Kconfig > b/drivers/gpu/drm/loongson/Kconfig > new file mode 100644 > index ..3cf42a4cca08 > --- /dev/null > +++ b/drivers/gpu/drm/loongson/Kconfig > @@ -0,0 +1,14 @@ > +# SPDX-License-Identifier: GPL-2.0-only > + > +config DRM_LOONGSON > + tristate "DRM support for LS7A bridge chipset" > + depends on DRM && PCI > + depends on CPU_LOONGSON64 > + select DRM_KMS_HELPER > + select DRM_VRAM_HELPER > + select DRM_TTM > + select DRM_TTM_HELPER > + default n > + help > + Support the display controllers found on the Loongson LS7A > + bridge. > diff --git a/drivers/gpu/drm/loongson/Makefile > b/drivers/gpu/drm/loongson/Makefile > new file mode 100644 > index ..22d063953b78 > --- /dev/null > +++ b/drivers/gpu/drm/loongson/Makefile > @@ -0,0 +1,14 @@ > +# SPDX-License-Identifier: GPL-2.0-only > +# > +# M
Re: [Intel-gfx] [PATCH v3 1/2] drm/i915: document caching related bits
On Thu, 22 Jul 2021 at 12:54, Daniel Vetter wrote:
>
> On Thu, Jul 22, 2021 at 12:34:55PM +0100, Matthew Auld wrote:
> > Try to document the object caching related bits, like cache_coherent and
> > cache_dirty.
> >
> > v2(Ville):
> > - As pointed out by Ville, fix the completely incorrect assumptions
> >about the "partial" coherency on shared LLC platforms.
> > v3(Daniel):
> > - Fix nonsense about "dirtying" the cache with reads.
> >
> > Suggested-by: Daniel Vetter
> > Signed-off-by: Matthew Auld
> > Cc: Ville Syrjälä
> > Cc: Mika Kuoppala
> > ---
> > .../gpu/drm/i915/gem/i915_gem_object_types.h | 176 +-
> > drivers/gpu/drm/i915/i915_drv.h | 9 -
> > 2 files changed, 172 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> > b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> > index afbadfc5516b..40cce816a7e3 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> > @@ -92,6 +92,76 @@ struct drm_i915_gem_object_ops {
> > const char *name; /* friendly name for debug, e.g. lockdep classes */
> > };
> >
> > +/**
> > + * enum i915_cache_level - The supported GTT caching values for system
> > memory
> > + * pages.
> > + *
> > + * These translate to some special GTT PTE bits when binding pages into
> > some
> > + * address space. It also determines whether an object, or rather its
> > pages are
> > + * coherent with the GPU, when also reading or writing through the CPU
> > cache
> > + * with those pages.
> > + *
> > + * Userspace can also control this through struct drm_i915_gem_caching.
> > + */
> > +enum i915_cache_level {
> > + /**
> > + * @I915_CACHE_NONE:
> > + *
> > + * Not coherent with the CPU cache. If the cache is dirty and we need
> > + * the underlying pages to be coherent with some later GPU access then
> > + * we need to manually flush the pages.
> > + *
> > + * Note that on shared LLC platforms reads and writes through the CPU
> > + * cache are still coherent even with this setting. See also
> > + * &drm_i915_gem_object.cache_coherent for more details.
> > + *
> > + * Note that on platforms with a shared LLC this should ideally only
> > be
>
> Merge this with the previous note and maybe explain it with "Due to this
> we should only use uncached for scanout surfaces on platforms with shared
> LLC, otherwise ..."
>
> As-is reads a bit awkward/repetive.
>
> > + * used for scanout surfaces, otherwise we end up over-flushing in
> > some
> > + * places.
>
> Maybe also note that on non-LLC platforms uncached is the default.
>
> > + */
> > + I915_CACHE_NONE = 0,
> > + /**
> > + * @I915_CACHE_LLC:
> > + *
> > + * Coherent with the CPU cache. If the cache is dirty, then the GPU
> > will
> > + * ensure that access remains coherent, when both reading and writing
> > + * through the CPU cache.
> > + *
> > + * Not used for scanout surfaces.
> > + *
> > + * Applies to both platforms with shared LLC(HAS_LLC), and snooping
> > + * based platforms(HAS_SNOOP).
> > + *
> > + * This should be the default for platforms which share the LLC with
> > the
> s/should/is/
>
> After all it _is_ the default at object creation time.
>
> > + * CPU. The only exception is scanout objects, where the display
> > engine
> > + * is not coherent with the LLC. For such objects I915_CACHE_NONE or
> > + * I915_CACHE_WT should be used.
>
> Maybe clarify that we automatically apply this transition upon
> pin_for_display if userspace hasn't done it.
>
> > + */
> > + I915_CACHE_LLC,
> > + /**
> > + * @I915_CACHE_L3_LLC:
> > + *
> > + * Explicitly enable the Gfx L3 cache, with snooped LLC.
> > + *
> > + * The Gfx L3 sits between the domain specific caches, e.g
> > + * sampler/render caches, and the larger LLC. LLC is coherent with the
> > + * GPU, but L3 is only visible to the GPU, so likely needs to be
> > flushed
> > + * when the workload completes.
> > + *
> > + * Not used for scanout surfaces.
> > + *
> > + * Only exposed on some gen7 + GGTT. More recent hardware has dropped
> > + * this.
>
> I think it's also the default on these?
I would say yes.
>
> > + */
> > + I915_CACHE_L3_LLC,
>
> > + /**
> > + * @I915_CACHE_WT:
> > + *
> > + * hsw:gt3e Write-through for scanout buffers.
>
> I haven't checked, but are we using this automatically?
Yes, if the HW supports it.
>
> > + */
> > + I915_CACHE_WT,
> > +};
> > +
> > enum i915_map_type {
> > I915_MAP_WB = 0,
> > I915_MAP_WC,
> > @@ -229,14 +299,112 @@ struct drm_i915_gem_object {
> > unsigned int mem_flags;
> > #define I915_BO_FLAG_STRUCT_PAGE BIT(0) /* Object backed by struct pages */
> > #define I915_BO_FLAG_IOMEM
Re: [PATCH v3 1/1] drm/ttm: Fix COW check
On Fri, Jul 23, 2021 at 10:33:48AM +0200, Christian König wrote:
>
>
> Am 23.07.21 um 10:21 schrieb Daniel Vetter:
> > On Wed, Jul 14, 2021 at 10:51 AM Christian König
> > wrote:
> > >
> > >
> > > Am 13.07.21 um 17:28 schrieb Alex Deucher:
> > > > On Tue, Jul 13, 2021 at 2:57 AM Christian König
> > > > wrote:
> > > > >
> > > > > Am 13.07.21 um 00:06 schrieb Felix Kuehling:
> > > > > > KFD Thunk maps invisible VRAM BOs with PROT_NONE, MAP_PRIVATE.
> > > > > > is_cow_mapping returns true for these mappings. Add a check for
> > > > > > vm_flags & VM_WRITE to avoid mmap failures on private read-only or
> > > > > > PROT_NONE mappings.
> > > > > >
> > > > > > v2: protect against mprotect making a mapping writable after the
> > > > > > fact
> > > > > > v3: update driver-specific vm_operations_structs
> > > > > >
> > > > > > Fixes: f91142c62161 ("drm/ttm: nuke VM_MIXEDMAP on BO mappings v3")
> > > > > > Signed-off-by: Felix Kuehling
> > > > > > Signed-off-by: Alex Deucher
> > > > > Reviewed-by: Christian König
> > > > Are you planning to push this to drm-misc?
> > > Yes, just didn't found time yesterday.
> > This is pushed to the wrong tree drm-misc-next-fixes, should have been
> > in drm-misc-fixes. Please be careful with that because every time that
> > goes wrong the script gets confused about which the current tree is,
> > and pushes the wrong tree to linux-next branches.
> >
> > I'm going to hard-reset drm-misc-next-fixes now and hope that's good
> > enough to fix things up (since Thomas is not around all the time for
> > this merge window).
>
> STOP! I'm about to push a revert for this patch.
>
> And yes that was pushed to the wrong branch, but it turned out that this was
> fortunate since the patch doesn't work correctly.
Well I just hard-reset, so you can push the right patch to the right
branch now. The trouble is that outside of the merge window no one is
allowed to push to drm-misc-next-fixes. If you do, then dim pushes
drm-misc-next-fixes to for-linux-next instead of drm-misc-next, and we
have bad surprises.
Which unfortunately happens like every merge window a few times and always
takes a few days/weeks to get caught.
-Danie
>
> Christian.
>
> > -Daniel
> >
> >
> > > Christian.
> > >
> > > > Alex
> > > >
> > > > > > ---
> > > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 3 ++-
> > > > > > drivers/gpu/drm/nouveau/nouveau_gem.c| 3 ++-
> > > > > > drivers/gpu/drm/radeon/radeon_gem.c | 3 ++-
> > > > > > drivers/gpu/drm/ttm/ttm_bo_vm.c | 14 +-
> > > > > > drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c | 1 +
> > > > > > include/drm/ttm/ttm_bo_api.h | 4
> > > > > > 6 files changed, 24 insertions(+), 4 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> > > > > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> > > > > > index b3404c43a911..1aa750a6a5d2 100644
> > > > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> > > > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> > > > > > @@ -79,7 +79,8 @@ static const struct vm_operations_struct
> > > > > > amdgpu_gem_vm_ops = {
> > > > > > .fault = amdgpu_gem_fault,
> > > > > > .open = ttm_bo_vm_open,
> > > > > > .close = ttm_bo_vm_close,
> > > > > > - .access = ttm_bo_vm_access
> > > > > > + .access = ttm_bo_vm_access,
> > > > > > + .mprotect = ttm_bo_vm_mprotect
> > > > > > };
> > > > > >
> > > > > > static void amdgpu_gem_object_free(struct drm_gem_object *gobj)
> > > > > > diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
> > > > > > b/drivers/gpu/drm/nouveau/nouveau_gem.c
> > > > > > index 5b27845075a1..164ea564bb7a 100644
> > > > > > --- a/drivers/gpu/drm/nouveau/nouveau_gem.c
> > > > > > +++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
> > > > > > @@ -70,7 +70,8 @@ static const struct vm_operations_struct
> > > > > > nouveau_ttm_vm_ops = {
> > > > > > .fault = nouveau_ttm_fault,
> > > > > > .open = ttm_bo_vm_open,
> > > > > > .close = ttm_bo_vm_close,
> > > > > > - .access = ttm_bo_vm_access
> > > > > > + .access = ttm_bo_vm_access,
> > > > > > + .mprotect = ttm_bo_vm_mprotect
> > > > > > };
> > > > > >
> > > > > > void
> > > > > > diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
> > > > > > b/drivers/gpu/drm/radeon/radeon_gem.c
> > > > > > index 458f92a70887..c19ad07eb7b5 100644
> > > > > > --- a/drivers/gpu/drm/radeon/radeon_gem.c
> > > > > > +++ b/drivers/gpu/drm/radeon/radeon_gem.c
> > > > > > @@ -77,7 +77,8 @@ static const struct vm_operations_struct
> > > > > > radeon_gem_vm_ops = {
> > > > > > .fault = radeon_gem_fault,
> > > > > > .open = ttm_bo_vm_open,
> > > > > > .close = ttm_bo_vm_close,
> > > > > > - .access = ttm_bo_vm_access
> > > > > > + .access = ttm_bo_vm_access,
> > > > > > + .mprotect = ttm_bo_vm_mprotect
> > > > > > };
> > > > > >
> > > > > > static void radeon_g
Re: [PATCH] dma-buf/poll: Get a file reference for outstanding fence callbacks
On Fri, Jul 23, 2021 at 10:19:49AM +0200, Michel Dänzer wrote:
> On 2021-07-23 10:04 a.m., Christian König wrote:
> > Am 23.07.21 um 09:58 schrieb Michel Dänzer:
> >> From: Michel Dänzer
> >>
> >> This makes sure we don't hit the
> >>
> >> BUG_ON(dmabuf->cb_in.active || dmabuf->cb_out.active);
> >>
> >> in dma_buf_release, which could be triggered by user space closing the
> >> dma-buf file description while there are outstanding fence callbacks
> >> from dma_buf_poll.
> >
> > I was also wondering the same thing while working on this, but then thought
> > that the poll interface would take care of this.
>
> I was able to hit the BUG_ON with
> https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880 .
igt test would be really lovely. Maybe base something off the
import/export igts from Jason?
-Daniel
>
>
> >> Cc: sta...@vger.kernel.org
> >> Signed-off-by: Michel Dänzer
> >> ---
> >> drivers/dma-buf/dma-buf.c | 18 --
> >> 1 file changed, 12 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> >> index 6c520c9bd93c..ec25498a971f 100644
> >> --- a/drivers/dma-buf/dma-buf.c
> >> +++ b/drivers/dma-buf/dma-buf.c
> >> @@ -65,12 +65,9 @@ static void dma_buf_release(struct dentry *dentry)
> >> BUG_ON(dmabuf->vmapping_counter);
> >> /*
> >> - * Any fences that a dma-buf poll can wait on should be signaled
> >> - * before releasing dma-buf. This is the responsibility of each
> >> - * driver that uses the reservation objects.
> >> - *
> >> - * If you hit this BUG() it means someone dropped their ref to the
> >> - * dma-buf while still having pending operation to the buffer.
> >> + * If you hit this BUG() it could mean:
> >> + * * There's a file reference imbalance in dma_buf_poll /
> >> dma_buf_poll_cb or somewhere else
> >> + * * dmabuf->cb_in/out.active are non-0 despite no pending fence
> >> callback
> >> */
> >> BUG_ON(dmabuf->cb_in.active || dmabuf->cb_out.active);
> >> @@ -196,6 +193,7 @@ static loff_t dma_buf_llseek(struct file *file,
> >> loff_t offset, int whence)
> >> static void dma_buf_poll_cb(struct dma_fence *fence, struct dma_fence_cb
> >> *cb)
> >> {
> >> struct dma_buf_poll_cb_t *dcb = (struct dma_buf_poll_cb_t *)cb;
> >> + struct dma_buf *dmabuf = container_of(dcb->poll, struct dma_buf,
> >> poll);
> >> unsigned long flags;
> >> spin_lock_irqsave(&dcb->poll->lock, flags);
> >> @@ -203,6 +201,8 @@ static void dma_buf_poll_cb(struct dma_fence *fence,
> >> struct dma_fence_cb *cb)
> >> dcb->active = 0;
> >> spin_unlock_irqrestore(&dcb->poll->lock, flags);
> >> dma_fence_put(fence);
> >> + /* Paired with get_file in dma_buf_poll */
> >> + fput(dmabuf->file);
> >
> > Is calling fput() in interrupt context ok? IIRC that could potentially
> > sleep.
>
> Looks fine AFAICT: It has
>
> if (likely(!in_interrupt() && !(task->flags & PF_KTHREAD))) {
>
> and as a fallback for that, it adds the file to a lock-less delayed_fput_list
> which is processed by a workqueue.
>
>
> --
> Earthling Michel Dänzer | https://redhat.com
> Libre software enthusiast | Mesa and X developer
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH v4 1/6] arm64: dts: mt8195: add display node for vdosys0
Add display node for vdosys0.
Signed-off-by: jason-jh.lin
---
This patch is based on [1][2][3][4]
[1]arm64: dts: Add Mediatek SoC MT8195 and evaluation board dts and Makefile
-
https://patchwork.kernel.org/project/linux-mediatek/patch/20210601075350.31515-2-seiya.w...@mediatek.com/
[2]arm64: dts: mt8195: add IOMMU and smi nodes
-
https://patchwork.kernel.org/project/linux-mediatek/patch/20210615173233.26682-15-tinghan.s...@mediatek.com/
[3]arm64: dts: mt8195: add gce node
-
https://patchwork.kernel.org/project/linux-mediatek/patch/20210705053429.4380-4-jason-jh@mediatek.com/
[4]add mt8195 SoC DRM binding
- https://patchwork.kernel.org/project/linux-mediatek/list/?series=519597
---
arch/arm64/boot/dts/mediatek/mt8195.dtsi | 111 +++
1 file changed, 111 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8195.dtsi
b/arch/arm64/boot/dts/mediatek/mt8195.dtsi
index 04d3e95175fa..aa2a7849b822 100644
--- a/arch/arm64/boot/dts/mediatek/mt8195.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8195.dtsi
@@ -1155,9 +1155,120 @@
#clock-cells = <1>;
};
+ ovl0: disp_ovl@1c00 {
+ compatible = "mediatek,mt8195-disp-ovl",
+"mediatek,mt8183-disp-ovl";
+ reg = <0 0x1c00 0 0x1000>;
+ interrupts = ;
+ power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS0>;
+ clocks = <&vdosys0 CLK_VDO0_DISP_OVL0>;
+ iommus = <&iommu_vdo M4U_PORT_L0_DISP_OVL0_RDMA0>;
+ mediatek,gce-client-reg =
+<&gce1 SUBSYS_1c00 0x 0x1000>;
+ };
+
+ rdma0: disp_rdma@1c002000 {
+ compatible = "mediatek,mt8195-disp-rdma";
+ reg = <0 0x1c002000 0 0x1000>;
+ interrupts = ;
+ power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS0>;
+ clocks = <&vdosys0 CLK_VDO0_DISP_RDMA0>;
+ iommus = <&iommu_vdo M4U_PORT_L0_DISP_RDMA0>;
+ mediatek,gce-client-reg =
+<&gce1 SUBSYS_1c00 0x2000 0x1000>;
+ };
+
+ color0: disp_color@1c003000 {
+ compatible = "mediatek,mt8195-disp-color",
+"mediatek,mt8173-disp-color";
+ reg = <0 0x1c003000 0 0x1000>;
+ interrupts = ;
+ power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS0>;
+ clocks = <&vdosys0 CLK_VDO0_DISP_COLOR0>;
+ mediatek,gce-client-reg =
+<&gce1 SUBSYS_1c00 0x3000 0x1000>;
+ };
+
+ ccorr0: disp_ccorr@1c004000 {
+ compatible = "mediatek,mt8195-disp-ccorr",
+"mediatek,mt8183-disp-ccorr";
+ reg = <0 0x1c004000 0 0x1000>;
+ interrupts = ;
+ power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS0>;
+ clocks = <&vdosys0 CLK_VDO0_DISP_CCORR0>;
+ mediatek,gce-client-reg =
+<&gce1 SUBSYS_1c00 0x4000 0x1000>;
+ };
+
+ aal0: disp_aal@1c005000 {
+ compatible = "mediatek,mt8195-disp-aal",
+"mediatek,mt8173-disp-aal";
+ reg = <0 0x1c005000 0 0x1000>;
+ interrupts = ;
+ power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS0>;
+ clocks = <&vdosys0 CLK_VDO0_DISP_AAL0>;
+ mediatek,gce-client-reg =
+<&gce1 SUBSYS_1c00 0x5000 0x1000>;
+ };
+
+ gamma0: disp_gamma@1c006000 {
+ compatible = "mediatek,mt8195-disp-gamma",
+"mediatek,mt8173-disp-gamma";
+ reg = <0 0x1c006000 0 0x1000>;
+ interrupts = ;
+ power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS0>;
+ clocks = <&vdosys0 CLK_VDO0_DISP_GAMMA0>;
+ mediatek,gce-client-reg =
+<&gce1 SUBSYS_1c00 0x6000 0x1000>;
+ };
+
+ dither0: disp_dither@1c007000 {
+ compatible = "mediatek,mt8195-disp-dither",
+"mediatek,mt8183-disp-dither";
+ reg = <0 0x1c007000 0 0x1000>;
+ interrupts = ;
+ power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS0>;
+ clocks = <&vdosys0 CLK_VDO0_DISP_DITHER0>;
+ mediatek,gce-clie
[PATCH v4 3/6] soc: mediatek: add mtk-mutex support for mt8195 vdosys0
Add mtk-mutex support for mt8195 vdosys0.
Signed-off-by: jason-jh.lin
---
This patch is base on [1]
[1]add mt8195 SoC DRM binding
- https://patchwork.kernel.org/project/linux-mediatek/list/?series=519597
---
drivers/soc/mediatek/mtk-mutex.c | 93 ++--
1 file changed, 90 insertions(+), 3 deletions(-)
diff --git a/drivers/soc/mediatek/mtk-mutex.c b/drivers/soc/mediatek/mtk-mutex.c
index 2e4bcc300576..cb8bbf7f3fd8 100644
--- a/drivers/soc/mediatek/mtk-mutex.c
+++ b/drivers/soc/mediatek/mtk-mutex.c
@@ -17,6 +17,9 @@
#define MT8183_MUTEX0_MOD0 0x30
#define MT8183_MUTEX0_SOF0 0x2c
+#define MT8195_DISP_MUTEX0_MOD00x30
+#define MT8195_DISP_MUTEX0_SOF 0x2c
+
#define DISP_REG_MUTEX_EN(n) (0x20 + 0x20 * (n))
#define DISP_REG_MUTEX(n) (0x24 + 0x20 * (n))
#define DISP_REG_MUTEX_RST(n) (0x28 + 0x20 * (n))
@@ -67,6 +70,36 @@
#define MT8173_MUTEX_MOD_DISP_PWM1 24
#define MT8173_MUTEX_MOD_DISP_OD 25
+#define MT8195_MUTEX_MOD_DISP_OVL0 0
+#define MT8195_MUTEX_MOD_DISP_WDMA01
+#define MT8195_MUTEX_MOD_DISP_RDMA02
+#define MT8195_MUTEX_MOD_DISP_COLOR0 3
+#define MT8195_MUTEX_MOD_DISP_CCORR0 4
+#define MT8195_MUTEX_MOD_DISP_AAL0 5
+#define MT8195_MUTEX_MOD_DISP_GAMMA0 6
+#define MT8195_MUTEX_MOD_DISP_DITHER0 7
+#define MT8195_MUTEX_MOD_DISP_DSI0 8
+#define MT8195_MUTEX_MOD_DISP_DSC_WRAP0_CORE0 9
+#define MT8195_MUTEX_MOD_DISP_OVL1 10
+#define MT8195_MUTEX_MOD_DISP_WDMA111
+#define MT8195_MUTEX_MOD_DISP_RDMA112
+#define MT8195_MUTEX_MOD_DISP_COLOR1 13
+#define MT8195_MUTEX_MOD_DISP_CCORR1 14
+#define MT8195_MUTEX_MOD_DISP_AAL1 15
+#define MT8195_MUTEX_MOD_DISP_GAMMA1 16
+#define MT8195_MUTEX_MOD_DISP_DITHER1 17
+#define MT8195_MUTEX_MOD_DISP_DSI1 18
+#define MT8195_MUTEX_MOD_DISP_DSC_WRAP0_CORE1 19
+#define MT8195_MUTEX_MOD_DISP_VPP_MERGE20
+#define MT8195_MUTEX_MOD_DISP_DP_INTF0 21
+#define MT8195_MUTEX_MOD_DISP_VPP1_DL_RELAY0 22
+#define MT8195_MUTEX_MOD_DISP_VPP1_DL_RELAY1 23
+#define MT8195_MUTEX_MOD_DISP_VDO1_DL_RELAY2 24
+#define MT8195_MUTEX_MOD_DISP_VDO0_DL_RELAY3 25
+#define MT8195_MUTEX_MOD_DISP_VDO0_DL_RELAY4 26
+#define MT8195_MUTEX_MOD_DISP_PWM0 27
+#define MT8195_MUTEX_MOD_DISP_PWM1 28
+
#define MT2712_MUTEX_MOD_DISP_PWM2 10
#define MT2712_MUTEX_MOD_DISP_OVL0 11
#define MT2712_MUTEX_MOD_DISP_OVL1 12
@@ -101,12 +134,27 @@
#define MT2712_MUTEX_SOF_DSI3 6
#define MT8167_MUTEX_SOF_DPI0 2
#define MT8167_MUTEX_SOF_DPI1 3
+
#define MT8183_MUTEX_SOF_DSI0 1
#define MT8183_MUTEX_SOF_DPI0 2
#define MT8183_MUTEX_EOF_DSI0 (MT8183_MUTEX_SOF_DSI0 << 6)
#define MT8183_MUTEX_EOF_DPI0 (MT8183_MUTEX_SOF_DPI0 << 6)
+#define MT8195_MUTEX_SOF_DSI0 1
+#define MT8195_MUTEX_SOF_DSI1 2
+#define MT8195_MUTEX_SOF_DP_INTF0 3
+#define MT8195_MUTEX_SOF_DP_INTF1 4
+#define MT8195_MUTEX_SOF_DPI0 6 /* for HDMI_TX */
+#define MT8195_MUTEX_SOF_DPI1 5 /* for digital video out */
+
+#define MT8195_MUTEX_EOF_DSI0 (MT8195_MUTEX_SOF_DSI0 << 7)
+#define MT8195_MUTEX_EOF_DSI1 (MT8195_MUTEX_SOF_DSI1 << 7)
+#define MT8195_MUTEX_EOF_DP_INTF0 (MT8195_MUTEX_SOF_DP_INTF0 << 7)
+#define MT8195_MUTEX_EOF_DP_INTF1 (MT8195_MUTEX_SOF_DP_INTF1 << 7)
+#define MT8195_MUTEX_EOF_DPI0 (MT8195_MUTEX_SOF_DPI0 << 7)
+#define MT8195_MUTEX_EOF_DPI1 (MT8195_MUTEX_SOF_DPI1 << 7)
+
struct mtk_mutex {
int id;
bool claimed;
@@ -120,6 +168,9 @@ enum mtk_mutex_sof_id {
MUTEX_SOF_DPI1,
MUTEX_SOF_DSI2,
MUTEX_SOF_DSI3,
+ MUTEX_SOF_DP_INTF0,
+ MUTEX_SOF_DP_INTF1,
+ DDP_MUTEX_SOF_MAX,
};
struct mtk_mutex_data {
@@ -214,7 +265,22 @@ static const unsigned int
mt8183_mutex_mod[DDP_COMPONENT_ID_MAX] = {
[DDP_COMPONENT_WDMA0] = MT8183_MUTEX_MOD_DISP_WDMA0,
};
-static const unsigned int mt2712_mutex_sof[MUTEX_SOF_DSI3 + 1] = {
+static const unsigned int mt8195_mutex_mod[DDP_COMPONENT_ID_MAX] = {
+ [DDP_COMPONENT_OVL0] = MT8195_MUTEX_MOD_DISP_OVL0,
+ [DDP_COMPONENT_WDMA0] = MT8195_MUTEX_MOD_DISP_WDMA0,
+ [DDP_COMPONENT_RDMA0] = MT8195_MUTEX_MOD_DISP_RDMA0,
+ [DDP_COMPONENT_COLOR0] = MT8195_MUTEX_MOD_DISP_COLOR0,
+ [DDP_COMPONENT_CCORR] = MT8195_MUTEX_MOD_DISP_CCORR0,
+ [DDP_COMPONENT_AAL0] = MT8195_MUTEX_MOD_DISP_AAL0,
+ [DDP_COMPONENT_GAMMA] = MT8195_MUTEX_MOD_DISP_GAMMA0,
+
[PATCH v4 5/6] drm/mediatek: add DSC support for mt8195
Add DSC into mtk_drm_ddp_comp to support for mt8195.
DSC is designed for real-time systems with real-time compression,
transmission, decompression and display.
The DSC standard is a specification of the algorithms used for
compressing and decompressing image display streams, including
the specification of the syntax and semantics of the compressed
video bit stream.
Signed-off-by: jason-jh.lin
---
This patch is base on [1]
[1]add mt8195 SoC DRM binding
- https://patchwork.kernel.org/project/linux-mediatek/list/?series=519597
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 46 +
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 +
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 +
3 files changed, 49 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 75bc00e17fc4..6f4a9b8c9914 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -65,6 +65,12 @@
#define DITHER_ADD_LSHIFT_G(x) (((x) & 0x7) << 4)
#define DITHER_ADD_RSHIFT_G(x) (((x) & 0x7) << 0)
+#define DISP_REG_DSC_CON 0x
+#define DSC_EN BIT(0)
+#define DSC_DUAL_INOUT BIT(2)
+#define DSC_BYPASS BIT(4)
+#define DSC_UFOE_SEL BIT(16)
+
struct mtk_ddp_comp_dev {
struct clk *clk;
void __iomem *regs;
@@ -246,6 +252,35 @@ static void mtk_dither_stop(struct device *dev)
writel_relaxed(0x0, priv->regs + DISP_DITHER_EN);
}
+static void mtk_dsc_config(struct device *dev, unsigned int w,
+ unsigned int h, unsigned int vrefresh,
+ unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
+{
+ struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
+
+ /* dsc bypass mode */
+ mtk_ddp_write_mask(cmdq_pkt, DSC_BYPASS, &priv->cmdq_reg, priv->regs,
+ DISP_REG_DSC_CON, DSC_BYPASS);
+ mtk_ddp_write_mask(cmdq_pkt, DSC_UFOE_SEL, &priv->cmdq_reg, priv->regs,
+ DISP_REG_DSC_CON, DSC_UFOE_SEL);
+ mtk_ddp_write_mask(cmdq_pkt, DSC_DUAL_INOUT, &priv->cmdq_reg,
priv->regs,
+ DISP_REG_DSC_CON, DSC_DUAL_INOUT);
+}
+
+static void mtk_dsc_start(struct device *dev)
+{
+ struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
+
+ writel_relaxed(DSC_EN, &priv->regs + DISP_REG_DSC_CON);
+}
+
+static void mtk_dsc_stop(struct device *dev)
+{
+ struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
+
+ writel_relaxed(0x0, priv->regs + DISP_REG_DSC_CON);
+}
+
static const struct mtk_ddp_comp_funcs ddp_aal = {
.clk_enable = mtk_ddp_clk_enable,
.clk_disable = mtk_ddp_clk_disable,
@@ -284,6 +319,14 @@ static const struct mtk_ddp_comp_funcs ddp_dpi = {
.stop = mtk_dpi_stop,
};
+static const struct mtk_ddp_comp_funcs ddp_dsc = {
+ .clk_enable = mtk_ddp_clk_enable,
+ .clk_disable = mtk_ddp_clk_disable,
+ .config = mtk_dsc_config,
+ .start = mtk_dsc_start,
+ .stop = mtk_dsc_stop,
+};
+
static const struct mtk_ddp_comp_funcs ddp_dsi = {
.start = mtk_dsi_ddp_start,
.stop = mtk_dsi_ddp_stop,
@@ -356,6 +399,7 @@ static const char * const
mtk_ddp_comp_stem[MTK_DDP_COMP_TYPE_MAX] = {
[MTK_DISP_MUTEX] = "mutex",
[MTK_DISP_OD] = "od",
[MTK_DISP_BLS] = "bls",
+ [MTK_DISP_DSC] = "dsc",
};
struct mtk_ddp_comp_match {
@@ -374,6 +418,8 @@ static const struct mtk_ddp_comp_match
mtk_ddp_matches[DDP_COMPONENT_ID_MAX] = {
[DDP_COMPONENT_DITHER] = { MTK_DISP_DITHER,0, &ddp_dither },
[DDP_COMPONENT_DPI0]= { MTK_DPI,0, &ddp_dpi },
[DDP_COMPONENT_DPI1]= { MTK_DPI,1, &ddp_dpi },
+ [DDP_COMPONENT_DSC0]= { MTK_DISP_DSC, 0, &ddp_dsc },
+ [DDP_COMPONENT_DSC1]= { MTK_DISP_DSC, 1, &ddp_dsc },
[DDP_COMPONENT_DSI0]= { MTK_DSI,0, &ddp_dsi },
[DDP_COMPONENT_DSI1]= { MTK_DSI,1, &ddp_dsi },
[DDP_COMPONENT_DSI2]= { MTK_DSI,2, &ddp_dsi },
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
index bb914d976cf5..661fb620e266 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
@@ -34,6 +34,7 @@ enum mtk_ddp_comp_type {
MTK_DISP_MUTEX,
MTK_DISP_OD,
MTK_DISP_BLS,
+ MTK_DISP_DSC,
MTK_DDP_COMP_TYPE_MAX,
};
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index d6f6d1bdad85..0f6bb4bdc58a 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -446,6 +446,8 @@ static const struct of_device_id mtk_ddp_comp_dt_ids[] = {
.data = (v
[PATCH v4 2/6] soc: mediatek: add mtk-mmsys support for mt8195 vdosys0
Add mt8195 vdosys0 clock driver name and routing table to the driver data of mtk-mmsys. Signed-off-by: jason-jh.lin --- This patch is base on [1] [1]add mt8195 SoC DRM binding - https://patchwork.kernel.org/project/linux-mediatek/list/?series=519597 --- drivers/soc/mediatek/mt8195-mmsys.h| 191 + drivers/soc/mediatek/mtk-mmsys.c | 11 ++ include/linux/soc/mediatek/mtk-mmsys.h | 9 ++ 3 files changed, 211 insertions(+) create mode 100644 drivers/soc/mediatek/mt8195-mmsys.h diff --git a/drivers/soc/mediatek/mt8195-mmsys.h b/drivers/soc/mediatek/mt8195-mmsys.h new file mode 100644 index ..73e9e8286d50 --- /dev/null +++ b/drivers/soc/mediatek/mt8195-mmsys.h @@ -0,0 +1,191 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ + +#ifndef __SOC_MEDIATEK_MT8195_MMSYS_H +#define __SOC_MEDIATEK_MT8195_MMSYS_H + +#define MT8195_VDO0_OVL_MOUT_EN0xf14 +#define MOUT_DISP_OVL0_TO_DISP_RDMA0 BIT(0) +#define MOUT_DISP_OVL0_TO_DISP_WDMA0 BIT(1) +#define MOUT_DISP_OVL0_TO_DISP_OVL1BIT(2) +#define MOUT_DISP_OVL1_TO_DISP_RDMA1 BIT(4) +#define MOUT_DISP_OVL1_TO_DISP_WDMA1 BIT(5) +#define MOUT_DISP_OVL1_TO_DISP_OVL0BIT(6) + +#define MT8195_VDO0_SEL_IN 0xf34 +#define SEL_IN_VPP_MERGE_FROM_DSC_WRAP0_OUT(0 << 0) +#define SEL_IN_VPP_MERGE_FROM_DISP_DITHER1 (1 << 0) +#define SEL_IN_VPP_MERGE_FROM_VDO1_VIRTUAL0(2 << 0) +#define SEL_IN_DSC_WRAP0_IN_FROM_DISP_DITHER0 (0 << 4) +#define SEL_IN_DSC_WRAP0_IN_FROM_VPP_MERGE (1 << 4) +#define SEL_IN_DSC_WRAP1_IN_FROM_DISP_DITHER1 (0 << 5) +#define SEL_IN_DSC_WRAP1_IN_FROM_VPP_MERGE (1 << 5) +#define SEL_IN_SINA_VIRTUAL0_FROM_VPP_MERGE(0 << 8) +#define SEL_IN_SINA_VIRTUAL0_FROM_DSC_WRAP1_OUT(1 << 8) +#define SEL_IN_SINB_VIRTUAL0_FROM_DSC_WRAP0_OUT(0 << 9) +#define SEL_IN_DP_INTF0_FROM_DSC_WRAP1_OUT (0 << 12) +#define SEL_IN_DP_INTF0_FROM_VPP_MERGE (1 << 12) +#define SEL_IN_DP_INTF0_FROM_VDO1_VIRTUAL0 (2 << 12) +#define SEL_IN_DSI0_FROM_DSC_WRAP0_OUT (0 << 16) +#define SEL_IN_DSI0_FROM_DISP_DITHER0 (1 << 16) +#define SEL_IN_DSI1_FROM_DSC_WRAP1_OUT (0 << 17) +#define SEL_IN_DSI1_FROM_VPP_MERGE (1 << 17) +#define SEL_IN_DISP_WDMA1_FROM_DISP_OVL1 (0 << 20) +#define SEL_IN_DISP_WDMA1_FROM_VPP_MERGE (1 << 20) +#define SEL_IN_DSC_WRAP1_OUT_FROM_DSC_WRAP1_IN (0 << 21) +#define SEL_IN_DSC_WRAP1_OUT_FROM_DISP_DITHER1 (1 << 21) +#define SEL_IN_DISP_WDMA0_FROM_DISP_OVL0 (0 << 22) +#define SEL_IN_DISP_WDMA0_FROM_VPP_MERGE (1 << 22) + +#define MT8195_VDO0_SEL_OUT0xf38 +#define SOUT_DISP_DITHER0_TO_DSC_WRAP0_IN (0 << 0) +#define SOUT_DISP_DITHER0_TO_DSI0 (1 << 0) +#define SOUT_DISP_DITHER1_TO_DSC_WRAP1_IN (0 << 1) +#define SOUT_DISP_DITHER1_TO_VPP_MERGE (1 << 1) +#define SOUT_DISP_DITHER1_TO_DSC_WRAP1_OUT (2 << 1) +#define SOUT_VDO1_VIRTUAL0_TO_VPP_MERGE(0 << 4) +#define SOUT_VDO1_VIRTUAL0_TO_DP_INTF0 (1 << 4) +#define SOUT_VPP_MERGE_TO_DSI1 (0 << 8) +#define SOUT_VPP_MERGE_TO_DP_INTF0 (1 << 8) +#define SOUT_VPP_MERGE_TO_SINA_VIRTUAL0(2 << 8) +#define SOUT_VPP_MERGE_TO_DISP_WDMA1 (3 << 8) +#define SOUT_VPP_MERGE_TO_DSC_WRAP0_IN (4 << 8) +#define SOUT_VPP_MERGE_TO_DSC_WRAP1_IN (0 << 11) +#define SOUT_VPP_MERGE_TO_DISP_WDMA0 (1 << 11) +#define SOUT_DSC_WRAP0_OUT_TO_DSI0 (0 << 12) +#define SOUT_DSC_WRAP0_OUT_TO_SINB_VIRTUAL0(1 << 12) +#define SOUT_DSC_WRAP0_OUT_TO_VPP_MERGE(2 << 12) +#define SOUT_DSC_WRAP1_OUT_TO_DSI1 (0 << 16) +#define SOUT_DSC_WRAP1_OUT_TO_DP_INTF0 (1 << 16) +#define SOUT_DSC_WRAP1_OUT_TO_SINA_VIRTUAL0(2 << 16) +#define SOUT_DSC_WRAP1_OUT_TO_VPP_MERGE(3 << 16) + +#define MT8195_VDO1_VPP3_ASYNC_SOUT0xf54 +#define SOUT_TO_VPP_MERGE0_P0_SEL (0 << 0) +#define SOUT_TO_VPP_MERGE0_P1_SEL
[PATCH v4 6/6] drm/mediatek: add MERGE support for mt8195
Add MERGE module file:
MERGE module is used to merge two slice-per-line inputs
into one side-by-side output.
Signed-off-by: jason-jh.lin
---
This patch is base on [1]
[1]add mt8195 SoC DRM binding
- https://patchwork.kernel.org/project/linux-mediatek/list/?series=519597
---
drivers/gpu/drm/mediatek/Makefile | 1 +
drivers/gpu/drm/mediatek/mtk_disp_drv.h | 8 +
drivers/gpu/drm/mediatek/mtk_disp_merge.c | 277
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 16 ++
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 +
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 6 +-
drivers/gpu/drm/mediatek/mtk_drm_drv.h | 1 +
7 files changed, 309 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/mediatek/mtk_disp_merge.c
diff --git a/drivers/gpu/drm/mediatek/Makefile
b/drivers/gpu/drm/mediatek/Makefile
index dc54a7a69005..538e0087a44c 100644
--- a/drivers/gpu/drm/mediatek/Makefile
+++ b/drivers/gpu/drm/mediatek/Makefile
@@ -3,6 +3,7 @@
mediatek-drm-y := mtk_disp_ccorr.o \
mtk_disp_color.o \
mtk_disp_gamma.o \
+ mtk_disp_merge.o \
mtk_disp_ovl.o \
mtk_disp_rdma.o \
mtk_drm_crtc.o \
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
index cafd9df2d63b..f407cd9d873e 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
@@ -46,6 +46,14 @@ void mtk_gamma_set_common(void __iomem *regs, struct
drm_crtc_state *state);
void mtk_gamma_start(struct device *dev);
void mtk_gamma_stop(struct device *dev);
+int mtk_merge_clk_enable(struct device *dev);
+void mtk_merge_clk_disable(struct device *dev);
+void mtk_merge_config(struct device *dev, unsigned int width,
+ unsigned int height, unsigned int vrefresh,
+ unsigned int bpc, struct cmdq_pkt *cmdq_pkt);
+void mtk_merge_start(struct device *dev);
+void mtk_merge_stop(struct device *dev);
+
void mtk_ovl_bgclr_in_on(struct device *dev);
void mtk_ovl_bgclr_in_off(struct device *dev);
void mtk_ovl_bypass_shadow(struct device *dev);
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_merge.c
b/drivers/gpu/drm/mediatek/mtk_disp_merge.c
new file mode 100644
index ..594d76ccd205
--- /dev/null
+++ b/drivers/gpu/drm/mediatek/mtk_disp_merge.c
@@ -0,0 +1,277 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2021 MediaTek Inc.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "mtk_drm_ddp_comp.h"
+#include "mtk_drm_drv.h"
+#include "mtk_disp_drv.h"
+
+#define DISP_REG_MERGE_CTRL0x000
+#define FLD_MERGE_EN BIT(0)
+#define FLD_MERGE_RST BIT(4)
+#define FLD_MERGE_LR_SWAP BIT(8)
+#define FLD_MERGE_DCM_DIS BIT(12)
+
+#define DISP_MERGE_CFG_0 0x010
+#define DISP_MERGE_CFG_4 0x020
+#define DISP_MERGE_CFG_10 0x038
+#define DISP_MERGE_CFG_12 0x040
+#define CFG_10_10_1PI_2PO_BUF_MODE 6
+#define CFG_10_10_2PI_2PO_BUF_MODE 8
+#define DISP_MERGE_CFG_24 0x070
+#define DISP_MERGE_CFG_25 0x074
+
+#define DISP_MERGE_CFG_36 0x0a0
+#define DISP_MERGE_CFG_36_FLD_ULTRA_EN GENMASK(0, 0)
+#define DISP_MERGE_CFG_36_FLD_PREULTRA_EN GENMASK(4, 4)
+#define DISP_MERGE_CFG_36_FLD_HALT_FOR_DVFS_EN GENMASK(8, 8)
+#define DISP_MERGE_CFG_37 0x0a4
+#define DISP_MERGE_CFG_37_FLD_BUFFER_MODE GENMASK(1, 0)
+#define DISP_MERGE_CFG_38 0x0a8
+#define DISP_MERGE_CFG_38_FLD_VDE_BLOCK_ULTRA GENMASK(0, 0)
+#define DISP_MERGE_CFG_38_FLD_VALID_TH_BLOCK_ULTRA GENMASK(4, 4)
+#define DISP_MERGE_CFG_38_FLD_ULTRA_FIFO_VALID_TH GENMASK(31, 16)
+#define DISP_MERGE_CFG_39 0x0ac
+#define DISP_MERGE_CFG_39_FLD_NVDE_FORCE_PREULTRA GENMASK(8, 8)
+#define DISP_MERGE_CFG_39_FLD_NVALID_TH_FORCE_PREULTRA GENMASK(12, 12)
+#define DISP_MERGE_CFG_39_FLD_PREULTRA_FIFO_VALID_TH GENMASK(31, 16)
+#define DISP_MERGE_CFG_40 0x0b0
+#define DISP_MERGE_CFG_40_FLD_ULTRA_TH_LOW GENMASK(15, 0)
+#define DISP_MERGE_CFG_40_FLD_ULTRA_TH_HIGH GENMASK(31, 16)
+#define DISP_MERGE_CFG_41 0x0b4
+#define DISP_MERGE_CFG_41_FLD_PREULTRA_TH_LOW GENMASK(15, 0)
+#define DISP_MERGE_CFG_41_FLD_PREULTRA_TH_HIGH GENMASK(31, 16)
+
+struct mtk_disp_merge {
+ void __iomem *regs;
+ struct clk *clk;
+ struct clk *async_clk;
+ struct cmdq_client_reg cmdq_reg;
+ boolfifo_en;
+};
+
+void mtk_merge_start(struct device *dev)
+{
+ struct mtk_disp_merge *priv = dev_get_drvdata(dev);
+
+ mtk_ddp_write(NULL, 0x1, &priv->cmdq_reg, priv->regs,
DISP_REG_MERGE_CTRL);
+}
+
+void mtk_merge_stop(struct device *dev)
+{
+ struct mtk_disp_merge *priv = dev_get_drvdata(dev);
+
+ mtk_ddp_write(NULL, 0x0, &priv->cmdq_reg, priv->regs,
DISP_REG_MERGE_CTRL);
+}
+
+static void mtk_merge_fifo_se
[PATCH v4 0/6] Add Mediatek Soc DRM (vdosys0) support for mt8195
The hardware path of vdosys0 with eDP panel output need to go through by several modules, such as, OVL, RDMA, COLOR, CCORR, AAL, GAMMA, DITHER, DSC and MERGE. Change in v4: - extract dt-binding patches to another patch series https://patchwork.kernel.org/project/linux-mediatek/list/?series=519597 - squash DSC module into mtk_drm_ddp_comp.c - add coment and simplify MERGE config function Change in v3: - change mmsys and display dt-bindings document from txt to yaml - add MERGE additional description in display dt-bindings document - fix mboxes-cells number of vdosys0 node in dts - drop mutex eof convert define - remove pm_runtime apis in DSC and MERGE - change DSC and MERGE enum to alphabetic order Change in v2: - add DSC yaml file - add mt8195 drm driver porting parts in to one patch - remove useless define, variable, structure member and function - simplify DSC and MERGE file and switch threre order jason-jh.lin (6): arm64: dts: mt8195: add display node for vdosys0 soc: mediatek: add mtk-mmsys support for mt8195 vdosys0 soc: mediatek: add mtk-mutex support for mt8195 vdosys0 drm/mediatek: add mediatek-drm of vdosys0 support for mt8195 drm/mediatek: add DSC support for mt8195 drm/mediatek: add MERGE support for mt8195 arch/arm64/boot/dts/mediatek/mt8195.dtsi| 111 drivers/gpu/drm/mediatek/Makefile | 1 + drivers/gpu/drm/mediatek/mtk_disp_drv.h | 8 + drivers/gpu/drm/mediatek/mtk_disp_merge.c | 277 drivers/gpu/drm/mediatek/mtk_disp_rdma.c| 6 + drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 62 + drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 2 + drivers/gpu/drm/mediatek/mtk_drm_drv.c | 32 ++- drivers/gpu/drm/mediatek/mtk_drm_drv.h | 1 + drivers/soc/mediatek/mt8195-mmsys.h | 191 ++ drivers/soc/mediatek/mtk-mmsys.c| 11 + drivers/soc/mediatek/mtk-mutex.c| 93 ++- include/linux/soc/mediatek/mtk-mmsys.h | 9 + 13 files changed, 800 insertions(+), 4 deletions(-) create mode 100644 drivers/gpu/drm/mediatek/mtk_disp_merge.c create mode 100644 drivers/soc/mediatek/mt8195-mmsys.h -- 2.18.0
[PATCH v4 4/6] drm/mediatek: add mediatek-drm of vdosys0 support for mt8195
Add driver data of mt8195 vdosys0 to mediatek-drm and the sub driver.
Signed-off-by: jason-jh.lin
---
This patch is base on [1]
[1]add mt8195 SoC DRM binding
- https://patchwork.kernel.org/project/linux-mediatek/list/?series=519597
---
drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 6 ++
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 24
2 files changed, 30 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
index 728aaadfea8c..00e9827acefe 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
@@ -355,6 +355,10 @@ static const struct mtk_disp_rdma_data
mt8183_rdma_driver_data = {
.fifo_size = 5 * SZ_1K,
};
+static const struct mtk_disp_rdma_data mt8195_rdma_driver_data = {
+ .fifo_size = 1920,
+};
+
static const struct of_device_id mtk_disp_rdma_driver_dt_match[] = {
{ .compatible = "mediatek,mt2701-disp-rdma",
.data = &mt2701_rdma_driver_data},
@@ -362,6 +366,8 @@ static const struct of_device_id
mtk_disp_rdma_driver_dt_match[] = {
.data = &mt8173_rdma_driver_data},
{ .compatible = "mediatek,mt8183-disp-rdma",
.data = &mt8183_rdma_driver_data},
+ { .compatible = "mediatek,mt8195-disp-rdma",
+ .data = &mt8195_rdma_driver_data},
{},
};
MODULE_DEVICE_TABLE(of, mtk_disp_rdma_driver_dt_match);
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index b46bdb8985da..d6f6d1bdad85 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -147,6 +147,19 @@ static const enum mtk_ddp_comp_id mt8183_mtk_ddp_ext[] = {
DDP_COMPONENT_DPI0,
};
+static const enum mtk_ddp_comp_id mt8195_mtk_ddp_main[] = {
+ DDP_COMPONENT_OVL0,
+ DDP_COMPONENT_RDMA0,
+ DDP_COMPONENT_COLOR0,
+ DDP_COMPONENT_CCORR,
+ DDP_COMPONENT_AAL0,
+ DDP_COMPONENT_GAMMA,
+ DDP_COMPONENT_DITHER,
+ DDP_COMPONENT_DSC0,
+ DDP_COMPONENT_MERGE0,
+ DDP_COMPONENT_DP_INTF0,
+};
+
static const struct mtk_mmsys_driver_data mt2701_mmsys_driver_data = {
.main_path = mt2701_mtk_ddp_main,
.main_len = ARRAY_SIZE(mt2701_mtk_ddp_main),
@@ -186,6 +199,11 @@ static const struct mtk_mmsys_driver_data
mt8183_mmsys_driver_data = {
.ext_len = ARRAY_SIZE(mt8183_mtk_ddp_ext),
};
+static const struct mtk_mmsys_driver_data mt8195_vdosys0_driver_data = {
+ .main_path = mt8195_mtk_ddp_main,
+ .main_len = ARRAY_SIZE(mt8195_mtk_ddp_main),
+};
+
static int mtk_drm_kms_init(struct drm_device *drm)
{
struct mtk_drm_private *private = drm->dev_private;
@@ -410,6 +428,8 @@ static const struct of_device_id mtk_ddp_comp_dt_ids[] = {
.data = (void *)MTK_DISP_RDMA },
{ .compatible = "mediatek,mt8183-disp-rdma",
.data = (void *)MTK_DISP_RDMA },
+ { .compatible = "mediatek,mt8195-disp-rdma",
+ .data = (void *)MTK_DISP_RDMA },
{ .compatible = "mediatek,mt8173-disp-wdma",
.data = (void *)MTK_DISP_WDMA },
{ .compatible = "mediatek,mt8183-disp-ccorr",
@@ -448,6 +468,8 @@ static const struct of_device_id mtk_ddp_comp_dt_ids[] = {
.data = (void *)MTK_DISP_MUTEX },
{ .compatible = "mediatek,mt8183-disp-mutex",
.data = (void *)MTK_DISP_MUTEX },
+ { .compatible = "mediatek,mt8195-disp-mutex",
+ .data = (void *)MTK_DISP_MUTEX },
{ .compatible = "mediatek,mt2701-disp-pwm",
.data = (void *)MTK_DISP_BLS },
{ .compatible = "mediatek,mt8173-disp-pwm",
@@ -468,6 +490,8 @@ static const struct of_device_id mtk_drm_of_ids[] = {
.data = &mt8173_mmsys_driver_data},
{ .compatible = "mediatek,mt8183-mmsys",
.data = &mt8183_mmsys_driver_data},
+ {.compatible = "mediatek,mt8195-vdosys0",
+ .data = &mt8195_vdosys0_driver_data},
{ }
};
MODULE_DEVICE_TABLE(of, mtk_drm_of_ids);
--
2.18.0
Re: [PATCH v3 1/1] drm/ttm: Fix COW check
Am 23.07.21 um 11:00 schrieb Daniel Vetter:
On Fri, Jul 23, 2021 at 10:33:48AM +0200, Christian König wrote:
Am 23.07.21 um 10:21 schrieb Daniel Vetter:
On Wed, Jul 14, 2021 at 10:51 AM Christian König
wrote:
Am 13.07.21 um 17:28 schrieb Alex Deucher:
On Tue, Jul 13, 2021 at 2:57 AM Christian König
wrote:
Am 13.07.21 um 00:06 schrieb Felix Kuehling:
KFD Thunk maps invisible VRAM BOs with PROT_NONE, MAP_PRIVATE.
is_cow_mapping returns true for these mappings. Add a check for
vm_flags & VM_WRITE to avoid mmap failures on private read-only or
PROT_NONE mappings.
v2: protect against mprotect making a mapping writable after the fact
v3: update driver-specific vm_operations_structs
Fixes: f91142c62161 ("drm/ttm: nuke VM_MIXEDMAP on BO mappings v3")
Signed-off-by: Felix Kuehling
Signed-off-by: Alex Deucher
Reviewed-by: Christian König
Are you planning to push this to drm-misc?
Yes, just didn't found time yesterday.
This is pushed to the wrong tree drm-misc-next-fixes, should have been
in drm-misc-fixes. Please be careful with that because every time that
goes wrong the script gets confused about which the current tree is,
and pushes the wrong tree to linux-next branches.
I'm going to hard-reset drm-misc-next-fixes now and hope that's good
enough to fix things up (since Thomas is not around all the time for
this merge window).
STOP! I'm about to push a revert for this patch.
And yes that was pushed to the wrong branch, but it turned out that this was
fortunate since the patch doesn't work correctly.
Well I just hard-reset, so you can push the right patch to the right
branch now. The trouble is that outside of the merge window no one is
allowed to push to drm-misc-next-fixes. If you do, then dim pushes
drm-misc-next-fixes to for-linux-next instead of drm-misc-next, and we
have bad surprises.
Could we then make the branch read-only for that time?
Which unfortunately happens like every merge window a few times and always
takes a few days/weeks to get caught.
Yeah, at least to me it's absolutely not obvious when the merge windows
for a certain version start/end.
Christian.
-Danie
Christian.
-Daniel
Christian.
Alex
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 3 ++-
drivers/gpu/drm/nouveau/nouveau_gem.c| 3 ++-
drivers/gpu/drm/radeon/radeon_gem.c | 3 ++-
drivers/gpu/drm/ttm/ttm_bo_vm.c | 14 +-
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c | 1 +
include/drm/ttm/ttm_bo_api.h | 4
6 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index b3404c43a911..1aa750a6a5d2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -79,7 +79,8 @@ static const struct vm_operations_struct amdgpu_gem_vm_ops = {
.fault = amdgpu_gem_fault,
.open = ttm_bo_vm_open,
.close = ttm_bo_vm_close,
- .access = ttm_bo_vm_access
+ .access = ttm_bo_vm_access,
+ .mprotect = ttm_bo_vm_mprotect
};
static void amdgpu_gem_object_free(struct drm_gem_object *gobj)
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index 5b27845075a1..164ea564bb7a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -70,7 +70,8 @@ static const struct vm_operations_struct nouveau_ttm_vm_ops =
{
.fault = nouveau_ttm_fault,
.open = ttm_bo_vm_open,
.close = ttm_bo_vm_close,
- .access = ttm_bo_vm_access
+ .access = ttm_bo_vm_access,
+ .mprotect = ttm_bo_vm_mprotect
};
void
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index 458f92a70887..c19ad07eb7b5 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -77,7 +77,8 @@ static const struct vm_operations_struct radeon_gem_vm_ops = {
.fault = radeon_gem_fault,
.open = ttm_bo_vm_open,
.close = ttm_bo_vm_close,
- .access = ttm_bo_vm_access
+ .access = ttm_bo_vm_access,
+ .mprotect = ttm_bo_vm_mprotect
};
static void radeon_gem_object_free(struct drm_gem_object *gobj)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index f56be5bc0861..fb325bad5db6 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -542,17 +542,29 @@ int ttm_bo_vm_access(struct vm_area_struct *vma, unsigned
long addr,
}
EXPORT_SYMBOL(ttm_bo_vm_access);
+int ttm_bo_vm_mprotect(struct vm_area_struct *vma, unsigned long start,
+unsigned long end, unsigned long newflags)
+{
+ /* Enforce no COW since would have really strange behavior with it. */
+ if (is_cow_mapping(newflags) && (newflags & VM_WRITE))
+ return -EINVAL;
+
+ return 0;
+}
+EXPORT_SYMBOL(ttm_bo_vm_mprotect);
+
st
Re: [PATCH] dma-buf/poll: Get a file reference for outstanding fence callbacks
On 2021-07-23 11:02 a.m., Daniel Vetter wrote: > On Fri, Jul 23, 2021 at 10:19:49AM +0200, Michel Dänzer wrote: >> On 2021-07-23 10:04 a.m., Christian König wrote: >>> Am 23.07.21 um 09:58 schrieb Michel Dänzer: From: Michel Dänzer This makes sure we don't hit the BUG_ON(dmabuf->cb_in.active || dmabuf->cb_out.active); in dma_buf_release, which could be triggered by user space closing the dma-buf file description while there are outstanding fence callbacks from dma_buf_poll. >>> >>> I was also wondering the same thing while working on this, but then thought >>> that the poll interface would take care of this. >> >> I was able to hit the BUG_ON with >> https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880 . > > igt test would be really lovely. Maybe base something off the > import/export igts from Jason? I'll see what I can do, busy with other stuff right now though. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer
Re: [PATCH 1/5] drm/vmwgfx: unbind in vmw_ttm_unpopulate
Am 23.07.21 um 10:47 schrieb Daniel Vetter:
On Thu, Jul 22, 2021 at 02:41:23PM +0200, Christian König wrote:
Doing this in vmw_ttm_destroy() is to late.
It turned out that this is not a good idea at all because it leaves pointers
to freed up system memory pages in the GART tables of the drivers.
So I wanted to review this series, and I can't reconcile your claim here
with the demidlayering Dave has done. The driver patches here don't
ouright undo what Dave has done, but that means the bug has been
preexisting since forever (or is due to some other change?), and your
commit message is a bit confusing here.
The final patch just undoes the demidlayering from Dave, and I really
don't see where there's even a functional change there.
And even these patches here don't really change a hole lot with the
calling sequence for at least final teardown: ttm_tt_destroy_common calls
ttm_tt_unpopulate as the first thing, so at least there there's no change.
Can you pls elaborate more clearly what exactly you're fixing and what
exactly needs to be reordered and where this bug is from (commit sha1)? As
is I'm playing detective and the evidence presented is extremely since and
I can't reconcile it at all.
I mean I know you don't like typing commit message and documentation, but
it does get occasionally rather frustrating on the reviewer side if I have
to interpolate between some very sparse hints for this stuff :-/
Yeah, when have seen the history it's rather obvious what's wrong here
and I expected Dave to review it himself.
Previously we had three states in TTM for a tt object: Allocated ->
Populated -> Bound which on destruction where done in the order unbind
-> unpopulate -> free.
Dave moved handling of the bound state into the drivers since it is
basically a driver decision and not a TTM decision what should be bound
and what not (that part perfectly makes sense).
The problem is that he also moved doing the unbind into the free
callback instead of the unpopulate callback. This result in stale page
pointers in the GART if that unpopulate operation isn't immediately
followed by a free.
Thinking more about it if we do populated->unpopulated->populated then
we would also have stale pointers to the old pages which is even worse.
This is also not de-midlayering since we already have a proper
ttm_tt_init()/ttm_tt_fini() functions which should work nicely for the
tt object.
Christian.
-Daniel
Signed-off-by: Christian König
---
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
index b0973c27e774..904031d03dbe 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
@@ -526,14 +526,9 @@ static void vmw_ttm_destroy(struct ttm_device *bdev,
struct ttm_tt *ttm)
struct vmw_ttm_tt *vmw_be =
container_of(ttm, struct vmw_ttm_tt, dma_ttm);
- vmw_ttm_unbind(bdev, ttm);
ttm_tt_destroy_common(bdev, ttm);
vmw_ttm_unmap_dma(vmw_be);
- if (vmw_be->dev_priv->map_mode == vmw_dma_alloc_coherent)
- ttm_tt_fini(&vmw_be->dma_ttm);
- else
- ttm_tt_fini(ttm);
-
+ ttm_tt_fini(ttm);
if (vmw_be->mob)
vmw_mob_destroy(vmw_be->mob);
@@ -578,6 +573,8 @@ static void vmw_ttm_unpopulate(struct ttm_device *bdev,
dma_ttm);
unsigned int i;
+ vmw_ttm_unbind(bdev, ttm);
+
if (vmw_tt->mob) {
vmw_mob_destroy(vmw_tt->mob);
vmw_tt->mob = NULL;
--
2.25.1
[PATCH] gpu: host1x: select CONFIG_SYNC_FILE
From: Arnd Bergmann
With the addition of the DMA fence, the host1x driver now fails to
build without the sync_file helper:
arm-linux-gnueabi-ld: drivers/gpu/host1x/fence.o: in function
`host1x_fence_create_fd':
fence.c:(.text+0x624): undefined reference to `sync_file_create'
Fixes: ad0529424def ("gpu: host1x: Add DMA fence implementation")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/host1x/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/host1x/Kconfig b/drivers/gpu/host1x/Kconfig
index 6dab94adf25e..6f7ea1720a39 100644
--- a/drivers/gpu/host1x/Kconfig
+++ b/drivers/gpu/host1x/Kconfig
@@ -3,6 +3,7 @@ config TEGRA_HOST1X
tristate "NVIDIA Tegra host1x driver"
depends on ARCH_TEGRA || (ARM && COMPILE_TEST)
select IOMMU_IOVA
+ select SYNC_FILE
help
Driver for the NVIDIA Tegra host1x hardware.
--
2.29.2
[PATCH] drm/nouveau/kms/nv50-: fix build failure with CONFIG_BACKLIGHT=n
From: Arnd Bergmann
When the backlight support is disabled, the driver fails to build:
drivers/gpu/drm/nouveau/dispnv50/disp.c: In function 'nv50_sor_atomic_disable':
drivers/gpu/drm/nouveau/dispnv50/disp.c:1665:59: error: 'struct
nouveau_connector' has no member named 'backlight'
1665 | struct nouveau_backlight *backlight = nv_connector->backlight;
| ^~
drivers/gpu/drm/nouveau/dispnv50/disp.c:1670:35: error: invalid use of
undefined type 'struct nouveau_backlight'
1670 | if (backlight && backlight->uses_dpcd) {
| ^~
drivers/gpu/drm/nouveau/dispnv50/disp.c:1671:64: error: invalid use of
undefined type 'struct nouveau_backlight'
1671 | ret = drm_edp_backlight_disable(aux,
&backlight->edp_info);
|^~
The patch that introduced the problem already contains some #ifdef
checks, so just add another one that makes it build again.
Fixes: 6eca310e8924 ("drm/nouveau/kms/nv50-: Add basic DPCD backlight support
for nouveau")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 093e1f7163b3..fcf53e24db21 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -1659,20 +1659,23 @@ static void
nv50_sor_atomic_disable(struct drm_encoder *encoder, struct drm_atomic_state
*state)
{
struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
- struct nouveau_drm *drm = nouveau_drm(nv_encoder->base.base.dev);
struct nouveau_crtc *nv_crtc = nouveau_crtc(nv_encoder->crtc);
struct nouveau_connector *nv_connector =
nv50_outp_get_old_connector(state, nv_encoder);
- struct nouveau_backlight *backlight = nv_connector->backlight;
struct drm_dp_aux *aux = &nv_connector->aux;
- int ret;
u8 pwr;
+#ifdef CONFIG_DRM_NOUVEAU_BACKLIGHT
+ struct nouveau_drm *drm = nouveau_drm(nv_encoder->base.base.dev);
+ struct nouveau_backlight *backlight = nv_connector->backlight;
+
if (backlight && backlight->uses_dpcd) {
- ret = drm_edp_backlight_disable(aux, &backlight->edp_info);
+ int ret = drm_edp_backlight_disable(aux, &backlight->edp_info);
+
if (ret < 0)
NV_ERROR(drm, "Failed to disable backlight on
[CONNECTOR:%d:%s]: %d\n",
nv_connector->base.base.id,
nv_connector->base.name, ret);
}
+#endif
if (nv_encoder->dcb->type == DCB_OUTPUT_DP) {
int ret = drm_dp_dpcd_readb(aux, DP_SET_POWER, &pwr);
--
2.29.2
[PATCH] drm/hisilicon/hibmc: remove an unused variable
From: Arnd Bergmann
A recent patch left an unused variable in place that needs to be
removed:
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c: In function 'hibmc_unload':
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c:252:35: error: unused variable
'priv' [-Werror=unused-variable]
252 | struct hibmc_drm_private *priv = to_hibmc_drm_private(dev);
Fixes: 39a364a19e03 ("drm/hisilicon/hibmc: Convert to Linux IRQ interfaces")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index f73a8e0ea12e..610fc8e135f9 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -249,7 +249,6 @@ static int hibmc_hw_init(struct hibmc_drm_private *priv)
static int hibmc_unload(struct drm_device *dev)
{
- struct hibmc_drm_private *priv = to_hibmc_drm_private(dev);
struct pci_dev *pdev = to_pci_dev(dev->dev);
drm_atomic_helper_shutdown(dev);
--
2.29.2
Re: [PATCH] gpu: host1x: select CONFIG_SYNC_FILE
Hi Arnd,
I think the best fix for this is to just remove that function -- it is
currently not used anywhere. I posted a patch to do that, but Thierry is
currently on vacation so it hasn't been picked up yet.
thanks,
Mikko
On 7/23/21 12:14 PM, Arnd Bergmann wrote:
From: Arnd Bergmann
With the addition of the DMA fence, the host1x driver now fails to
build without the sync_file helper:
arm-linux-gnueabi-ld: drivers/gpu/host1x/fence.o: in function
`host1x_fence_create_fd':
fence.c:(.text+0x624): undefined reference to `sync_file_create'
Fixes: ad0529424def ("gpu: host1x: Add DMA fence implementation")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/host1x/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/host1x/Kconfig b/drivers/gpu/host1x/Kconfig
index 6dab94adf25e..6f7ea1720a39 100644
--- a/drivers/gpu/host1x/Kconfig
+++ b/drivers/gpu/host1x/Kconfig
@@ -3,6 +3,7 @@ config TEGRA_HOST1X
tristate "NVIDIA Tegra host1x driver"
depends on ARCH_TEGRA || (ARM && COMPILE_TEST)
select IOMMU_IOVA
+ select SYNC_FILE
help
Driver for the NVIDIA Tegra host1x hardware.
Re: [PATCH] gpu: host1x: select CONFIG_SYNC_FILE
On 7/23/21 12:17 PM, Mikko Perttunen wrote:
Hi Arnd,
I think the best fix for this is to just remove that function -- it is
currently not used anywhere. I posted a patch to do that, but Thierry is
currently on vacation so it hasn't been picked up yet.
.. and sorry for the top post ..
Mikko
thanks,
Mikko
On 7/23/21 12:14 PM, Arnd Bergmann wrote:
From: Arnd Bergmann
With the addition of the DMA fence, the host1x driver now fails to
build without the sync_file helper:
arm-linux-gnueabi-ld: drivers/gpu/host1x/fence.o: in function
`host1x_fence_create_fd':
fence.c:(.text+0x624): undefined reference to `sync_file_create'
Fixes: ad0529424def ("gpu: host1x: Add DMA fence implementation")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/host1x/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/host1x/Kconfig b/drivers/gpu/host1x/Kconfig
index 6dab94adf25e..6f7ea1720a39 100644
--- a/drivers/gpu/host1x/Kconfig
+++ b/drivers/gpu/host1x/Kconfig
@@ -3,6 +3,7 @@ config TEGRA_HOST1X
tristate "NVIDIA Tegra host1x driver"
depends on ARCH_TEGRA || (ARM && COMPILE_TEST)
select IOMMU_IOVA
+ select SYNC_FILE
help
Driver for the NVIDIA Tegra host1x hardware.
Re: [PATCH 1/5] drm/vmwgfx: unbind in vmw_ttm_unpopulate
On Fri, Jul 23, 2021 at 11:13 AM Christian König
wrote:
>
> Am 23.07.21 um 10:47 schrieb Daniel Vetter:
> > On Thu, Jul 22, 2021 at 02:41:23PM +0200, Christian König wrote:
> >> Doing this in vmw_ttm_destroy() is to late.
> >>
> >> It turned out that this is not a good idea at all because it leaves
> >> pointers
> >> to freed up system memory pages in the GART tables of the drivers.
> > So I wanted to review this series, and I can't reconcile your claim here
> > with the demidlayering Dave has done. The driver patches here don't
> > ouright undo what Dave has done, but that means the bug has been
> > preexisting since forever (or is due to some other change?), and your
> > commit message is a bit confusing here.
> >
> > The final patch just undoes the demidlayering from Dave, and I really
> > don't see where there's even a functional change there.
> >
> > And even these patches here don't really change a hole lot with the
> > calling sequence for at least final teardown: ttm_tt_destroy_common calls
> > ttm_tt_unpopulate as the first thing, so at least there there's no change.
> >
> > Can you pls elaborate more clearly what exactly you're fixing and what
> > exactly needs to be reordered and where this bug is from (commit sha1)? As
> > is I'm playing detective and the evidence presented is extremely since and
> > I can't reconcile it at all.
> >
> > I mean I know you don't like typing commit message and documentation, but
> > it does get occasionally rather frustrating on the reviewer side if I have
> > to interpolate between some very sparse hints for this stuff :-/
>
> Yeah, when have seen the history it's rather obvious what's wrong here
> and I expected Dave to review it himself.
>
> Previously we had three states in TTM for a tt object: Allocated ->
> Populated -> Bound which on destruction where done in the order unbind
> -> unpopulate -> free.
>
> Dave moved handling of the bound state into the drivers since it is
> basically a driver decision and not a TTM decision what should be bound
> and what not (that part perfectly makes sense).
I haven't reviewed all the patches from Dave, only the one you pointed
at (in the last patch). And that one I still can't match up with your
description. If there's other commits relevant, can you pls dig them
out?
Like it all makes sense what you're saying and matches the code, I
just can't match it up with the commit you're referencing.
> The problem is that he also moved doing the unbind into the free
> callback instead of the unpopulate callback. This result in stale page
> pointers in the GART if that unpopulate operation isn't immediately
> followed by a free.
>
> Thinking more about it if we do populated->unpopulated->populated then
> we would also have stale pointers to the old pages which is even worse.
>
> This is also not de-midlayering since we already have a proper
> ttm_tt_init()/ttm_tt_fini() functions which should work nicely for the
> tt object.
Well you're last patch moves the ttm_tt_destroy_common stuff back into
ttm, which kinda is de-demidlayering. So I'm confused.
Other bit: I think it'd be good to document this properly in the
callbacks, and maybe ideally go about and kerneldoc-ify the entire
ttm_tt.h header. Otherwise when we eventually (never?) get around to
that, everyone has forgotten these semantic details and issues again.
-Daniel
> Christian.
>
> > -Daniel
> >
> >> Signed-off-by: Christian König
> >> ---
> >> drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 9 +++--
> >> 1 file changed, 3 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> >> b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> >> index b0973c27e774..904031d03dbe 100644
> >> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> >> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> >> @@ -526,14 +526,9 @@ static void vmw_ttm_destroy(struct ttm_device *bdev,
> >> struct ttm_tt *ttm)
> >> struct vmw_ttm_tt *vmw_be =
> >> container_of(ttm, struct vmw_ttm_tt, dma_ttm);
> >>
> >> -vmw_ttm_unbind(bdev, ttm);
> >> ttm_tt_destroy_common(bdev, ttm);
> >> vmw_ttm_unmap_dma(vmw_be);
> >> -if (vmw_be->dev_priv->map_mode == vmw_dma_alloc_coherent)
> >> -ttm_tt_fini(&vmw_be->dma_ttm);
> >> -else
> >> -ttm_tt_fini(ttm);
> >> -
> >> +ttm_tt_fini(ttm);
> >> if (vmw_be->mob)
> >> vmw_mob_destroy(vmw_be->mob);
> >>
> >> @@ -578,6 +573,8 @@ static void vmw_ttm_unpopulate(struct ttm_device *bdev,
> >> dma_ttm);
> >> unsigned int i;
> >>
> >> +vmw_ttm_unbind(bdev, ttm);
> >> +
> >> if (vmw_tt->mob) {
> >> vmw_mob_destroy(vmw_tt->mob);
> >> vmw_tt->mob = NULL;
> >> --
> >> 2.25.1
> >>
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH] drm/nouveau/kms/nv50-: fix build failure with CONFIG_BACKLIGHT=n
On Fri, Jul 23, 2021 at 11:15 AM Arnd Bergmann wrote:
>
> From: Arnd Bergmann
>
> When the backlight support is disabled, the driver fails to build:
>
> drivers/gpu/drm/nouveau/dispnv50/disp.c: In function
> 'nv50_sor_atomic_disable':
> drivers/gpu/drm/nouveau/dispnv50/disp.c:1665:59: error: 'struct
> nouveau_connector' has no member named 'backlight'
> 1665 | struct nouveau_backlight *backlight = nv_connector->backlight;
> | ^~
> drivers/gpu/drm/nouveau/dispnv50/disp.c:1670:35: error: invalid use of
> undefined type 'struct nouveau_backlight'
> 1670 | if (backlight && backlight->uses_dpcd) {
> | ^~
> drivers/gpu/drm/nouveau/dispnv50/disp.c:1671:64: error: invalid use of
> undefined type 'struct nouveau_backlight'
> 1671 | ret = drm_edp_backlight_disable(aux,
> &backlight->edp_info);
> |^~
>
> The patch that introduced the problem already contains some #ifdef
> checks, so just add another one that makes it build again.
>
> Fixes: 6eca310e8924 ("drm/nouveau/kms/nv50-: Add basic DPCD backlight support
> for nouveau")
> Signed-off-by: Arnd Bergmann
Can we just toss the idea that BACKTLIGHT=n is a reasonable config for
drm drivers using backlights, and add depends BACKLIGHT to all of
them?
I mean this is a perfect source of continued patch streams to keep us
all busy, but beyond that I really don't see the point ... I frankly
have better things to do, and especially with the big drivers we have
making backlight optional saves comparitively nothing.
-Daniel
> ---
> drivers/gpu/drm/nouveau/dispnv50/disp.c | 11 +++
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> index 093e1f7163b3..fcf53e24db21 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> @@ -1659,20 +1659,23 @@ static void
> nv50_sor_atomic_disable(struct drm_encoder *encoder, struct drm_atomic_state
> *state)
> {
> struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
> - struct nouveau_drm *drm = nouveau_drm(nv_encoder->base.base.dev);
> struct nouveau_crtc *nv_crtc = nouveau_crtc(nv_encoder->crtc);
> struct nouveau_connector *nv_connector =
> nv50_outp_get_old_connector(state, nv_encoder);
> - struct nouveau_backlight *backlight = nv_connector->backlight;
> struct drm_dp_aux *aux = &nv_connector->aux;
> - int ret;
> u8 pwr;
>
> +#ifdef CONFIG_DRM_NOUVEAU_BACKLIGHT
> + struct nouveau_drm *drm = nouveau_drm(nv_encoder->base.base.dev);
> + struct nouveau_backlight *backlight = nv_connector->backlight;
> +
> if (backlight && backlight->uses_dpcd) {
> - ret = drm_edp_backlight_disable(aux, &backlight->edp_info);
> + int ret = drm_edp_backlight_disable(aux,
> &backlight->edp_info);
> +
> if (ret < 0)
> NV_ERROR(drm, "Failed to disable backlight on
> [CONNECTOR:%d:%s]: %d\n",
> nv_connector->base.base.id,
> nv_connector->base.name, ret);
> }
> +#endif
>
> if (nv_encoder->dcb->type == DCB_OUTPUT_DP) {
> int ret = drm_dp_dpcd_readb(aux, DP_SET_POWER, &pwr);
> --
> 2.29.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH 1/5] drm/vmwgfx: unbind in vmw_ttm_unpopulate
Am 23.07.21 um 11:21 schrieb Daniel Vetter: On Fri, Jul 23, 2021 at 11:13 AM Christian König wrote: Am 23.07.21 um 10:47 schrieb Daniel Vetter: On Thu, Jul 22, 2021 at 02:41:23PM +0200, Christian König wrote: Doing this in vmw_ttm_destroy() is to late. It turned out that this is not a good idea at all because it leaves pointers to freed up system memory pages in the GART tables of the drivers. So I wanted to review this series, and I can't reconcile your claim here with the demidlayering Dave has done. The driver patches here don't ouright undo what Dave has done, but that means the bug has been preexisting since forever (or is due to some other change?), and your commit message is a bit confusing here. The final patch just undoes the demidlayering from Dave, and I really don't see where there's even a functional change there. And even these patches here don't really change a hole lot with the calling sequence for at least final teardown: ttm_tt_destroy_common calls ttm_tt_unpopulate as the first thing, so at least there there's no change. Can you pls elaborate more clearly what exactly you're fixing and what exactly needs to be reordered and where this bug is from (commit sha1)? As is I'm playing detective and the evidence presented is extremely since and I can't reconcile it at all. I mean I know you don't like typing commit message and documentation, but it does get occasionally rather frustrating on the reviewer side if I have to interpolate between some very sparse hints for this stuff :-/ Yeah, when have seen the history it's rather obvious what's wrong here and I expected Dave to review it himself. Previously we had three states in TTM for a tt object: Allocated -> Populated -> Bound which on destruction where done in the order unbind -> unpopulate -> free. Dave moved handling of the bound state into the drivers since it is basically a driver decision and not a TTM decision what should be bound and what not (that part perfectly makes sense). I haven't reviewed all the patches from Dave, only the one you pointed at (in the last patch). And that one I still can't match up with your description. If there's other commits relevant, can you pls dig them out? Like it all makes sense what you're saying and matches the code, I just can't match it up with the commit you're referencing. That is the patch directly following the one I've mentioned: commit 37bff6542c4e140a11657406c1bab50a40329cc1 Author: Dave Airlie Date: Thu Sep 17 13:24:50 2020 +1000 drm/ttm: move unbind into the tt destroy. This moves unbind into the driver side on destroy paths. I will add a Fixes tag to make that clear. But this patch also just moves the undbind from the TTM destroy path to the driver destroy path. To be honest I'm not 100% sure either when the when the unbind moved from the unpopulate path into the destroy path, but I think that this wasn't always the case. Let me try to dig that up. The problem is that he also moved doing the unbind into the free callback instead of the unpopulate callback. This result in stale page pointers in the GART if that unpopulate operation isn't immediately followed by a free. Thinking more about it if we do populated->unpopulated->populated then we would also have stale pointers to the old pages which is even worse. This is also not de-midlayering since we already have a proper ttm_tt_init()/ttm_tt_fini() functions which should work nicely for the tt object. Well you're last patch moves the ttm_tt_destroy_common stuff back into ttm, which kinda is de-demidlayering. So I'm confused. Ah, yes that is correct. I've also considered to move this in ttm_tt_fini instead of there. But that would be a larger change and I wanted to fix the problem at hand first, potentially even adding a CC stable tag. Other bit: I think it'd be good to document this properly in the callbacks, and maybe ideally go about and kerneldoc-ify the entire ttm_tt.h header. Otherwise when we eventually (never?) get around to that, everyone has forgotten these semantic details and issues again. Already working towards including more of the TTM headers and code files in kerneldoc. But not quite there yet. But you know, normal human: Only equipped with one head and two hands and not cloneable. Cheers, Christian. -Daniel Christian. -Daniel Signed-off-by: Christian König --- drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c index b0973c27e774..904031d03dbe 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c @@ -526,14 +526,9 @@ static void vmw_ttm_destroy(struct ttm_device *bdev, struct ttm_tt *ttm) struct vmw_ttm_tt *vmw_be = container_of(ttm, struct vmw_ttm_tt, dma_ttm); -vmw_ttm_unbind(bdev, ttm); ttm_tt_destroy_common(
Re: [PATCH v2 0/9] PCI/VGA: Rework default VGA device selection
Hi, Bjorn,
On Fri, Jul 23, 2021 at 5:29 AM Bjorn Helgaas wrote:
>
> From: Bjorn Helgaas
>
> This is a little bit of rework and extension of Huacai's nice work at [1].
>
> It moves the VGA arbiter to the PCI subsystem, fixes a few nits, and breaks
> a few pieces off Huacai's patch to make the main patch a little smaller.
>
> That last patch is still not very small, and it needs a commit log, as I
> mentioned at [2].
>
> All comments welcome!
>
> [1]
> https://lore.kernel.org/dri-devel/20210705100503.1120643-1-chenhua...@loongson.cn/
> [2] https://lore.kernel.org/r/20210720221923.GA43331@bjorn-Precision-5520
Thank you for your splitting. Your two questions are answered in the following.
(1) explain why your initcall ordering is unusual.
The original problem happens on MIPS. vga_arb_device_init() and
pcibios_init() are both wrapped by subsys_initcall(). The order of
functions in the same level depends on the Makefile.
TOP level Makefile:
drivers-y := drivers/ sound/
include arch/$(SRCARCH)/Makefile
drivers/Makefile:
obj-$(CONFIG_ACPI) += acpi/
obj-y += gpu/
arch/mips/Makefile:
drivers-$(CONFIG_PCI) += arch/mips/pci/
This makes pcibios_init() in arch/mips/pci/ placed after
vga_arb_device_init() in drivers/gpu. ACPI-based systems have no
problems because acpi_init() in drivers/acpi is placed before
vga_arb_device_init().
(2) explain the approach, which IIUC is basically to add the
vga_arb_select_default_device() functionality to
vga_arbiter_add_pci_device().
vga_arb_select_default_device() has only one chance to be called, we
want to make it be called every time a new vga device is added. So
rename it to vga_arb_update_default_device() and move the callsite to
vga_arbiter_add_pci_device().
I think you know all the information which you need now. And you can
reorganize the commit message based on the existing one. As English is
not my first language, the updated commit message written by me may
still not be as good as you want.:)
Huacai
>
>
> Bjorn Helgaas (4):
> PCI/VGA: Move vgaarb to drivers/pci
> PCI/VGA: Replace full MIT license text with SPDX identifier
> PCI/VGA: Use unsigned format string to print lock counts
> PCI/VGA: Remove empty vga_arb_device_card_gone()
>
> Huacai Chen (5):
> PCI/VGA: Move vga_arb_integrated_gpu() earlier in file
> PCI/VGA: Prefer vga_default_device()
> PCI/VGA: Split out vga_arb_update_default_device()
> PCI/VGA: Log bridge control messages when adding devices
> PCI/VGA: Rework default VGA device selection
>
> drivers/gpu/vga/Kconfig | 19 ---
> drivers/gpu/vga/Makefile | 1 -
> drivers/pci/Kconfig | 19 +++
> drivers/pci/Makefile | 1 +
> drivers/{gpu/vga => pci}/vgaarb.c | 269 --
> 5 files changed, 126 insertions(+), 183 deletions(-)
> rename drivers/{gpu/vga => pci}/vgaarb.c (90%)
>
> --
> 2.25.1
>
Re: [PATCH v4 2/6] soc: mediatek: add mtk-mmsys support for mt8195 vdosys0
Hi Jason, Thank you for your patch. Missatge de jason-jh.lin del dia dv., 23 de jul. 2021 a les 11:02: > > Add mt8195 vdosys0 clock driver name and routing table to > the driver data of mtk-mmsys. > > Signed-off-by: jason-jh.lin > --- > This patch is base on [1] > > [1]add mt8195 SoC DRM binding > - https://patchwork.kernel.org/project/linux-mediatek/list/?series=519597 > --- > drivers/soc/mediatek/mt8195-mmsys.h| 191 + > drivers/soc/mediatek/mtk-mmsys.c | 11 ++ > include/linux/soc/mediatek/mtk-mmsys.h | 9 ++ > 3 files changed, 211 insertions(+) > create mode 100644 drivers/soc/mediatek/mt8195-mmsys.h > > diff --git a/drivers/soc/mediatek/mt8195-mmsys.h > b/drivers/soc/mediatek/mt8195-mmsys.h > new file mode 100644 > index ..73e9e8286d50 > --- /dev/null > +++ b/drivers/soc/mediatek/mt8195-mmsys.h > @@ -0,0 +1,191 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > + > +#ifndef __SOC_MEDIATEK_MT8195_MMSYS_H > +#define __SOC_MEDIATEK_MT8195_MMSYS_H > + > +#define MT8195_VDO0_OVL_MOUT_EN0xf14 > +#define MOUT_DISP_OVL0_TO_DISP_RDMA0 BIT(0) This define and the others should use the MT8195_ prefix, as these are MT8195 afaik > +#define MOUT_DISP_OVL0_TO_DISP_WDMA0 BIT(1) > +#define MOUT_DISP_OVL0_TO_DISP_OVL1BIT(2) > +#define MOUT_DISP_OVL1_TO_DISP_RDMA1 BIT(4) > +#define MOUT_DISP_OVL1_TO_DISP_WDMA1 BIT(5) > +#define MOUT_DISP_OVL1_TO_DISP_OVL0BIT(6) > + > +#define MT8195_VDO0_SEL_IN 0xf34 > +#define SEL_IN_VPP_MERGE_FROM_DSC_WRAP0_OUT(0 << 0) > +#define SEL_IN_VPP_MERGE_FROM_DISP_DITHER1 (1 << 0) > +#define SEL_IN_VPP_MERGE_FROM_VDO1_VIRTUAL0(2 << 0) > +#define SEL_IN_DSC_WRAP0_IN_FROM_DISP_DITHER0 (0 << 4) > +#define SEL_IN_DSC_WRAP0_IN_FROM_VPP_MERGE (1 << 4) > +#define SEL_IN_DSC_WRAP1_IN_FROM_DISP_DITHER1 (0 << 5) > +#define SEL_IN_DSC_WRAP1_IN_FROM_VPP_MERGE (1 << 5) > +#define SEL_IN_SINA_VIRTUAL0_FROM_VPP_MERGE(0 << 8) > +#define SEL_IN_SINA_VIRTUAL0_FROM_DSC_WRAP1_OUT(1 << > 8) > +#define SEL_IN_SINB_VIRTUAL0_FROM_DSC_WRAP0_OUT(0 << > 9) > +#define SEL_IN_DP_INTF0_FROM_DSC_WRAP1_OUT (0 << 12) > +#define SEL_IN_DP_INTF0_FROM_VPP_MERGE (1 << 12) > +#define SEL_IN_DP_INTF0_FROM_VDO1_VIRTUAL0 (2 << 12) > +#define SEL_IN_DSI0_FROM_DSC_WRAP0_OUT (0 << 16) > +#define SEL_IN_DSI0_FROM_DISP_DITHER0 (1 << 16) > +#define SEL_IN_DSI1_FROM_DSC_WRAP1_OUT (0 << 17) > +#define SEL_IN_DSI1_FROM_VPP_MERGE (1 << 17) > +#define SEL_IN_DISP_WDMA1_FROM_DISP_OVL1 (0 << 20) > +#define SEL_IN_DISP_WDMA1_FROM_VPP_MERGE (1 << 20) > +#define SEL_IN_DSC_WRAP1_OUT_FROM_DSC_WRAP1_IN (0 << 21) > +#define SEL_IN_DSC_WRAP1_OUT_FROM_DISP_DITHER1 (1 << 21) > +#define SEL_IN_DISP_WDMA0_FROM_DISP_OVL0 (0 << 22) > +#define SEL_IN_DISP_WDMA0_FROM_VPP_MERGE (1 << 22) > + > +#define MT8195_VDO0_SEL_OUT0xf38 > +#define SOUT_DISP_DITHER0_TO_DSC_WRAP0_IN (0 << 0) > +#define SOUT_DISP_DITHER0_TO_DSI0 (1 << 0) > +#define SOUT_DISP_DITHER1_TO_DSC_WRAP1_IN (0 << 1) > +#define SOUT_DISP_DITHER1_TO_VPP_MERGE (1 << 1) > +#define SOUT_DISP_DITHER1_TO_DSC_WRAP1_OUT (2 << 1) > +#define SOUT_VDO1_VIRTUAL0_TO_VPP_MERGE(0 << > 4) > +#define SOUT_VDO1_VIRTUAL0_TO_DP_INTF0 (1 << 4) > +#define SOUT_VPP_MERGE_TO_DSI1 (0 << 8) > +#define SOUT_VPP_MERGE_TO_DP_INTF0 (1 << 8) > +#define SOUT_VPP_MERGE_TO_SINA_VIRTUAL0(2 << > 8) > +#define SOUT_VPP_MERGE_TO_DISP_WDMA1 (3 << 8) > +#define SOUT_VPP_MERGE_TO_DSC_WRAP0_IN (4 << 8) > +#define SOUT_VPP_MERGE_TO_DSC_WRAP1_IN (0 << 11) > +#define SOUT_VPP_MERGE_TO_DISP_WDMA0 (1 << 11) > +#define SOUT_DSC_WRAP0_OUT_TO_DSI0 (0 << 12) > +#define SOUT_DSC_WRAP0_OUT_TO_SINB_VIRTUAL0(1 << 12) > +#define SOUT_DSC_WRAP0_OUT_TO_VPP_MERGE(2 << > 12) > +#define SOUT_DSC_WRAP1_OUT_TO_DSI1 (0 << 16) > +#define SOUT_DSC_WRAP1_OUT_TO_DP_INTF0 (1
Re: [PATCH] drm/nouveau/kms/nv50-: fix build failure with CONFIG_BACKLIGHT=n
On Fri, Jul 23, 2021 at 11:24 AM Daniel Vetter wrote:
>
> On Fri, Jul 23, 2021 at 11:15 AM Arnd Bergmann wrote:
> >
> > From: Arnd Bergmann
> >
> > When the backlight support is disabled, the driver fails to build:
> >
> > drivers/gpu/drm/nouveau/dispnv50/disp.c: In function
> > 'nv50_sor_atomic_disable':
> > drivers/gpu/drm/nouveau/dispnv50/disp.c:1665:59: error: 'struct
> > nouveau_connector' has no member named 'backlight'
> > 1665 | struct nouveau_backlight *backlight =
> > nv_connector->backlight;
> > | ^~
> > drivers/gpu/drm/nouveau/dispnv50/disp.c:1670:35: error: invalid use of
> > undefined type 'struct nouveau_backlight'
> > 1670 | if (backlight && backlight->uses_dpcd) {
> > | ^~
> > drivers/gpu/drm/nouveau/dispnv50/disp.c:1671:64: error: invalid use of
> > undefined type 'struct nouveau_backlight'
> > 1671 | ret = drm_edp_backlight_disable(aux,
> > &backlight->edp_info);
> > |^~
> >
> > The patch that introduced the problem already contains some #ifdef
> > checks, so just add another one that makes it build again.
> >
> > Fixes: 6eca310e8924 ("drm/nouveau/kms/nv50-: Add basic DPCD backlight
> > support for nouveau")
> > Signed-off-by: Arnd Bergmann
>
> Can we just toss the idea that BACKTLIGHT=n is a reasonable config for
> drm drivers using backlights, and add depends BACKLIGHT to all of
> them?
>
> I mean this is a perfect source of continued patch streams to keep us
> all busy, but beyond that I really don't see the point ... I frankly
> have better things to do, and especially with the big drivers we have
> making backlight optional saves comparitively nothing.
> -Daniel
>
same, I'd just require BACKLIGHT as well tbh.
> > ---
> > drivers/gpu/drm/nouveau/dispnv50/disp.c | 11 +++
> > 1 file changed, 7 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > index 093e1f7163b3..fcf53e24db21 100644
> > --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > @@ -1659,20 +1659,23 @@ static void
> > nv50_sor_atomic_disable(struct drm_encoder *encoder, struct
> > drm_atomic_state *state)
> > {
> > struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
> > - struct nouveau_drm *drm = nouveau_drm(nv_encoder->base.base.dev);
> > struct nouveau_crtc *nv_crtc = nouveau_crtc(nv_encoder->crtc);
> > struct nouveau_connector *nv_connector =
> > nv50_outp_get_old_connector(state, nv_encoder);
> > - struct nouveau_backlight *backlight = nv_connector->backlight;
> > struct drm_dp_aux *aux = &nv_connector->aux;
> > - int ret;
> > u8 pwr;
> >
> > +#ifdef CONFIG_DRM_NOUVEAU_BACKLIGHT
> > + struct nouveau_drm *drm = nouveau_drm(nv_encoder->base.base.dev);
> > + struct nouveau_backlight *backlight = nv_connector->backlight;
> > +
> > if (backlight && backlight->uses_dpcd) {
> > - ret = drm_edp_backlight_disable(aux, &backlight->edp_info);
> > + int ret = drm_edp_backlight_disable(aux,
> > &backlight->edp_info);
> > +
> > if (ret < 0)
> > NV_ERROR(drm, "Failed to disable backlight on
> > [CONNECTOR:%d:%s]: %d\n",
> > nv_connector->base.base.id,
> > nv_connector->base.name, ret);
> > }
> > +#endif
> >
> > if (nv_encoder->dcb->type == DCB_OUTPUT_DP) {
> > int ret = drm_dp_dpcd_readb(aux, DP_SET_POWER, &pwr);
> > --
> > 2.29.2
> >
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
>
Re: [PATCH] drm/nouveau/kms/nv50-: fix build failure with CONFIG_BACKLIGHT=n
On Fri, Jul 23, 2021 at 12:10 PM Karol Herbst wrote:
>
> On Fri, Jul 23, 2021 at 11:24 AM Daniel Vetter wrote:
> >
> > On Fri, Jul 23, 2021 at 11:15 AM Arnd Bergmann wrote:
> > >
> > > From: Arnd Bergmann
> > >
> > > When the backlight support is disabled, the driver fails to build:
> > >
> > > drivers/gpu/drm/nouveau/dispnv50/disp.c: In function
> > > 'nv50_sor_atomic_disable':
> > > drivers/gpu/drm/nouveau/dispnv50/disp.c:1665:59: error: 'struct
> > > nouveau_connector' has no member named 'backlight'
> > > 1665 | struct nouveau_backlight *backlight =
> > > nv_connector->backlight;
> > > | ^~
> > > drivers/gpu/drm/nouveau/dispnv50/disp.c:1670:35: error: invalid use of
> > > undefined type 'struct nouveau_backlight'
> > > 1670 | if (backlight && backlight->uses_dpcd) {
> > > | ^~
> > > drivers/gpu/drm/nouveau/dispnv50/disp.c:1671:64: error: invalid use of
> > > undefined type 'struct nouveau_backlight'
> > > 1671 | ret = drm_edp_backlight_disable(aux,
> > > &backlight->edp_info);
> > > |^~
> > >
> > > The patch that introduced the problem already contains some #ifdef
> > > checks, so just add another one that makes it build again.
> > >
> > > Fixes: 6eca310e8924 ("drm/nouveau/kms/nv50-: Add basic DPCD backlight
> > > support for nouveau")
> > > Signed-off-by: Arnd Bergmann
> >
> > Can we just toss the idea that BACKTLIGHT=n is a reasonable config for
> > drm drivers using backlights, and add depends BACKLIGHT to all of
> > them?
> >
> > I mean this is a perfect source of continued patch streams to keep us
> > all busy, but beyond that I really don't see the point ... I frankly
> > have better things to do, and especially with the big drivers we have
> > making backlight optional saves comparitively nothing.
> > -Daniel
> >
>
> same, I'd just require BACKLIGHT as well tbh.
>
ehhh, get rid of DRM_NOUVEAU_BACKLIGHT I meant.
> > > ---
> > > drivers/gpu/drm/nouveau/dispnv50/disp.c | 11 +++
> > > 1 file changed, 7 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > > b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > > index 093e1f7163b3..fcf53e24db21 100644
> > > --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > > +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > > @@ -1659,20 +1659,23 @@ static void
> > > nv50_sor_atomic_disable(struct drm_encoder *encoder, struct
> > > drm_atomic_state *state)
> > > {
> > > struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
> > > - struct nouveau_drm *drm = nouveau_drm(nv_encoder->base.base.dev);
> > > struct nouveau_crtc *nv_crtc = nouveau_crtc(nv_encoder->crtc);
> > > struct nouveau_connector *nv_connector =
> > > nv50_outp_get_old_connector(state, nv_encoder);
> > > - struct nouveau_backlight *backlight = nv_connector->backlight;
> > > struct drm_dp_aux *aux = &nv_connector->aux;
> > > - int ret;
> > > u8 pwr;
> > >
> > > +#ifdef CONFIG_DRM_NOUVEAU_BACKLIGHT
> > > + struct nouveau_drm *drm = nouveau_drm(nv_encoder->base.base.dev);
> > > + struct nouveau_backlight *backlight = nv_connector->backlight;
> > > +
> > > if (backlight && backlight->uses_dpcd) {
> > > - ret = drm_edp_backlight_disable(aux,
> > > &backlight->edp_info);
> > > + int ret = drm_edp_backlight_disable(aux,
> > > &backlight->edp_info);
> > > +
> > > if (ret < 0)
> > > NV_ERROR(drm, "Failed to disable backlight on
> > > [CONNECTOR:%d:%s]: %d\n",
> > > nv_connector->base.base.id,
> > > nv_connector->base.name, ret);
> > > }
> > > +#endif
> > >
> > > if (nv_encoder->dcb->type == DCB_OUTPUT_DP) {
> > > int ret = drm_dp_dpcd_readb(aux, DP_SET_POWER, &pwr);
> > > --
> > > 2.29.2
> > >
> >
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
> >
Re: [PATCH] backlight: pwm_bl: Avoid backlight flicker if backlight control GPIO is input
On Thu, Jul 22, 2021 at 09:02:04PM +0200, Marek Vasut wrote: > On 7/22/21 1:28 PM, Daniel Thompson wrote: > > On Wed, Jul 21, 2021 at 08:46:42PM +0200, Marek Vasut wrote: > > > On 7/21/21 6:12 PM, Daniel Thompson wrote: > > > > On Wed, Jul 21, 2021 at 05:09:57PM +0200, Marek Vasut wrote: > > > > > On 7/21/21 12:49 PM, Daniel Thompson wrote: > > > > [...] > > > > This sails very close to the > > > > edge of what is in-scope for DT (at least it does it we can read > > > > the inherited state directly from the hardware). > > > > > > The problem with reading it out of hardware is that the hardware might be > > > in > > > undefined state and expects Linux to define that state, so that does not > > > always work. Hence my initial suggestion to add a DT property to define > > > the > > > state up front, instead of using these fragile heuristics. > > > > To achieve a flicker-free boot we must know the initial state of the > > backlight (not just the enable pin). > > The backlight hardware might be in uninitialized state and then Linux should > set the state, likely based on something in DT, because there is no previous > state to read. There is always a previous state. The kernel doesn't care whether that previous state was imposed by a power-on reset, the bootloader or a kexec. For the driver to come up flicker-free in all the different cases we need to know whether the backlight is currently emitting light or not and, if it is emitting light, then we need to know what the duty cycle is (currently we inherit require the PWM driver to correctly inherit the duty cycle from the hardware). So far, the previous state has been observable by the lower level drivers (GPIO, PWM, regulator). I remain reluctant to provide workarounds for cases where it is not observable without motivating hardware. I certainly wouldn't want to make such bindings mandatory since observable hardware registers are a far more reliable source of truth than what the DT tells us about what it thinks the bootloader (or power-on reset) actually did ;-). > > > > Overall I have fairly grave concerns that this simply moves > > > > fragility into the bootloader rather then reducing it. > > > > > > Wait a minute, I think we disconnected somewhere. I would rather prefer to > > > remove the fragility and bootloader dependency altogether, exactly to > > > avoid > > > depending on the state the bootloader left the hardware in. > > > > The two fully flicker-free cases we support in pwm_bl are: > > > > 1. Backlight off after bootloader has completed. Backlight must be > > off after the probe completes (and never flicker on/off during the > > probe). This allows the display to put a splash image on the screen > > before lighting up the backlight (this avoids a flicker if there are > > a few frames between backlight coming on and the splash image being > > drawn). Naturally this requires help from the display system (and > > that the display system is aware of the backlight to be able to start > > it). > > > > 2. Backlight on with a splash image after bootloader has completed. > > Backlight must be on after the probe completes (and never flicker > > off/on during the probe). This also requires that the display system > > can take over the frame buffer without a flicker but that is > > completely independent of backlight. > > > > There is also a simpler case which is not "flicker-free" since the > > backlight may change level during the boot and may light up before > > there is an image on the screen (although we'd still to minimise > > flicker by ensuring there is only one change of backlight state/level > > during the probe (something your work will see fixed?): > > Actually no, my usecase is the backlight is not initialized by the > bootloader at all, the pins are just strapped to default to the right > values, the init is left to the kernel to do. It doesn't matter to us who established the initial state. In this case the backlight is off at handover. That means you are either case #1 (display system will unblank" the backlight automatically when the reset of the display unblanks) or #3 (BL driver will "unblank" the backlight during the probe). Your changes should result in a fix to both these cases! > > 3. Backlight is on after the probe completes. This is default if > > we don't know the display system will activate the backlight. > > This is an important legacy case since few userspaces know how > > to change the backlight power-state at boot. > > > > One oddity here is that #3 *also* needs to know the state of the > > backlight (on/off) to turn the backlight on without flickering > > (so it can figure out how to handle power_pwm_on_delay correctly) > > even though the final state is unconditionally on. That is the main > > reason I proposed an alternative to your patch (since this is > > currently broken). > > > > The other oddity is that the difference between #1 and #3 is due
Re: [PATCH] drm/nouveau/kms/nv50-: fix build failure with CONFIG_BACKLIGHT=n
On Fri, Jul 23, 2021 at 11:25 AM Daniel Vetter wrote:
>
> On Fri, Jul 23, 2021 at 11:15 AM Arnd Bergmann wrote:
> >
> > From: Arnd Bergmann
> >
> > When the backlight support is disabled, the driver fails to build:
> >
> > drivers/gpu/drm/nouveau/dispnv50/disp.c: In function
> > 'nv50_sor_atomic_disable':
> > drivers/gpu/drm/nouveau/dispnv50/disp.c:1665:59: error: 'struct
> > nouveau_connector' has no member named 'backlight'
> > 1665 | struct nouveau_backlight *backlight =
> > nv_connector->backlight;
> > | ^~
> > drivers/gpu/drm/nouveau/dispnv50/disp.c:1670:35: error: invalid use of
> > undefined type 'struct nouveau_backlight'
> > 1670 | if (backlight && backlight->uses_dpcd) {
> > | ^~
> > drivers/gpu/drm/nouveau/dispnv50/disp.c:1671:64: error: invalid use of
> > undefined type 'struct nouveau_backlight'
> > 1671 | ret = drm_edp_backlight_disable(aux,
> > &backlight->edp_info);
> > |^~
> >
> > The patch that introduced the problem already contains some #ifdef
> > checks, so just add another one that makes it build again.
> >
> > Fixes: 6eca310e8924 ("drm/nouveau/kms/nv50-: Add basic DPCD backlight
> > support for nouveau")
> > Signed-off-by: Arnd Bergmann
>
> Can we just toss the idea that BACKTLIGHT=n is a reasonable config for
> drm drivers using backlights, and add depends BACKLIGHT to all of
> them?
>
> I mean this is a perfect source of continued patch streams to keep us
> all busy, but beyond that I really don't see the point ... I frankly
> have better things to do, and especially with the big drivers we have
> making backlight optional saves comparitively nothing.
> -Daniel
Yes! I'd definitely be in favor of that, I've wasted way too much time trying
to sort through dependency loops and other problems with backlight support.
Maybe we should leave the drivers/video/fbdev/ drivers untouched in this
regard, at least for the moment, but for the drivers/gpu/drm users of
backlight that would be a nice simplification, and even the smallest ones
are unlikely to be used on systems that are too memory constrained to
deal with 4KB extra .text.
Arnd
[PATCH 1/2] drm/msm/a6xx: Fix llcc configuration for a660 gpu
Add the missing scache_cntl0 register programing which is required for
a660 gpu.
Signed-off-by: Akhil P Oommen
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 46 ---
1 file changed, 27 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 9c5e461..183b9f9 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -1383,13 +1383,13 @@ static void a6xx_llc_activate(struct a6xx_gpu *a6xx_gpu)
{
struct adreno_gpu *adreno_gpu = &a6xx_gpu->base;
struct msm_gpu *gpu = &adreno_gpu->base;
- u32 cntl1_regval = 0;
+ u32 gpu_scid, cntl1_regval = 0;
if (IS_ERR(a6xx_gpu->llc_mmio))
return;
if (!llcc_slice_activate(a6xx_gpu->llc_slice)) {
- u32 gpu_scid = llcc_get_slice_id(a6xx_gpu->llc_slice);
+ gpu_scid = llcc_get_slice_id(a6xx_gpu->llc_slice);
gpu_scid &= 0x1f;
cntl1_regval = (gpu_scid << 0) | (gpu_scid << 5) | (gpu_scid <<
10) |
@@ -1409,26 +1409,34 @@ static void a6xx_llc_activate(struct a6xx_gpu *a6xx_gpu)
}
}
- if (cntl1_regval) {
+ if (!cntl1_regval)
+ return;
+
+ /*
+* Program the slice IDs for the various GPU blocks and GPU MMU
+* pagetables
+*/
+ if (!a6xx_gpu->have_mmu500) {
+ a6xx_llc_write(a6xx_gpu,
+ REG_A6XX_CX_MISC_SYSTEM_CACHE_CNTL_1, cntl1_regval);
+
/*
-* Program the slice IDs for the various GPU blocks and GPU MMU
-* pagetables
+* Program cacheability overrides to not allocate cache
+* lines on a write miss
*/
- if (a6xx_gpu->have_mmu500)
- gpu_rmw(gpu, REG_A6XX_GBIF_SCACHE_CNTL1, GENMASK(24, 0),
- cntl1_regval);
- else {
- a6xx_llc_write(a6xx_gpu,
- REG_A6XX_CX_MISC_SYSTEM_CACHE_CNTL_1,
cntl1_regval);
-
- /*
-* Program cacheability overrides to not allocate cache
-* lines on a write miss
-*/
- a6xx_llc_rmw(a6xx_gpu,
- REG_A6XX_CX_MISC_SYSTEM_CACHE_CNTL_0, 0xF,
0x03);
- }
+ a6xx_llc_rmw(a6xx_gpu,
+ REG_A6XX_CX_MISC_SYSTEM_CACHE_CNTL_0, 0xF, 0x03);
+ return;
}
+
+ gpu_rmw(gpu, REG_A6XX_GBIF_SCACHE_CNTL1, GENMASK(24, 0), cntl1_regval);
+
+ /* On A660, the SCID programming for UCHE traffic is done in
+* A6XX_GBIF_SCACHE_CNTL0[14:10]
+*/
+ if (adreno_is_a660(adreno_gpu))
+ gpu_rmw(gpu, REG_A6XX_GBIF_SCACHE_CNTL0, (0x1f << 10) |
+ (1 << 8), (gpu_scid << 10) | (1 << 8));
}
static void a6xx_llc_slices_destroy(struct a6xx_gpu *a6xx_gpu)
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation.
[PATCH 2/2] drm/msm/a6xx: Add support for Adreno 7c Gen 3 gpu
This patch adds support for the gpu found in the Snapdragon 7c Gen 3
compute platform. This gpu is similar to the exisiting a660 gpu with
minor delta in the programing sequence. As the Adreno GPUs are moving
away from a numeric chipid based naming scheme to a string, it was
decided to use 0x06030500 as the gpu id of this gpu to communicate
to the userspace driver.
Signed-off-by: Akhil P Oommen
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 20 ++-
drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 1 +
drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h | 2 ++
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 21 ++--
drivers/gpu/drm/msm/adreno/a6xx_hfi.c | 32 ++
drivers/gpu/drm/msm/adreno/adreno_device.c | 12 +++
drivers/gpu/drm/msm/adreno/adreno_gpu.h| 11 --
7 files changed, 90 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index b349692..332301f 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -933,6 +933,7 @@ int a6xx_gmu_resume(struct a6xx_gpu *a6xx_gpu)
/* Use a known rate to bring up the GMU */
clk_set_rate(gmu->core_clk, 2);
+ clk_set_rate(gmu->hub_clk, 15000);
ret = clk_bulk_prepare_enable(gmu->nr_clocks, gmu->clocks);
if (ret) {
pm_runtime_put(gmu->gxpd);
@@ -1094,6 +1095,7 @@ static void a6xx_gmu_shutdown(struct a6xx_gmu *gmu)
int a6xx_gmu_stop(struct a6xx_gpu *a6xx_gpu)
{
+ struct adreno_gpu *adreno_gpu = &a6xx_gpu->base;
struct a6xx_gmu *gmu = &a6xx_gpu->gmu;
struct msm_gpu *gpu = &a6xx_gpu->base.base;
@@ -1117,9 +1119,22 @@ int a6xx_gmu_stop(struct a6xx_gpu *a6xx_gpu)
* domain. Usually the GMU does this but only if the shutdown sequence
* was successful
*/
- if (!IS_ERR_OR_NULL(gmu->gxpd))
+ if (!IS_ERR_OR_NULL(gmu->gxpd)) {
+ /*
+* Toggle the loop_en bit, across disabling the gx gdsc,
+* with a delay of 10 XO cycles before disabling gx
+* gdsc. This is to prevent CPR measurements from
+* failing.
+*/
+ if (adreno_is_a660(adreno_gpu))
+ gmu_rmw(gmu, REG_A6XX_GPU_CPR_FSM_CTL, 1, 0);
+
pm_runtime_put_sync(gmu->gxpd);
+ if (adreno_is_a660(adreno_gpu))
+ gmu_rmw(gmu, REG_A6XX_GPU_CPR_FSM_CTL, 1, 1);
+ }
+
clk_bulk_disable_unprepare(gmu->nr_clocks, gmu->clocks);
pm_runtime_put_sync(gmu->dev);
@@ -1393,6 +1408,9 @@ static int a6xx_gmu_clocks_probe(struct a6xx_gmu *gmu)
gmu->core_clk = msm_clk_bulk_get_clock(gmu->clocks,
gmu->nr_clocks, "gmu");
+ gmu->hub_clk = msm_clk_bulk_get_clock(gmu->clocks,
+ gmu->nr_clocks, "hub");
+
return 0;
}
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
index 71dfa600..3c74f64 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
@@ -66,6 +66,7 @@ struct a6xx_gmu {
int nr_clocks;
struct clk_bulk_data *clocks;
struct clk *core_clk;
+ struct clk *hub_clk;
/* current performance index set externally */
int current_perf_index;
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h
index 8115892..d46733f 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h
@@ -479,5 +479,7 @@ static inline uint32_t A6XX_GMU_GPU_NAP_CTRL_SID(uint32_t
val)
#define REG_A6XX_RSCC_TCS3_DRV0_STATUS 0x053e
+#define REG_A6XX_GPU_CPR_FSM_CTL 0xc001
+
#endif /* A6XX_GMU_XML */
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 183b9f9..c0882536 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -694,6 +694,13 @@ static void a6xx_set_ubwc_config(struct msm_gpu *gpu)
uavflagprd_inv = 2;
}
+ if (adreno_is_7c3(adreno_gpu)) {
+ lower_bit = 1;
+ amsbc = 1;
+ rgb565_predicator = 1;
+ uavflagprd_inv = 2;
+ }
+
gpu_write(gpu, REG_A6XX_RB_NC_MODE_CNTL,
rgb565_predicator << 11 | amsbc << 4 | lower_bit << 1);
gpu_write(gpu, REG_A6XX_TPL1_NC_MODE_CNTL, lower_bit << 1);
@@ -950,10 +957,10 @@ static int a6xx_hw_init(struct msm_gpu *gpu)
/* Setting the primFifo thresholds default values,
* and vccCacheSkipDis=1 bit (0x200) for A640 and newer
*/
- if (adreno_is_a650(adreno_gpu) || adreno_is_a660(adreno_gpu))
- gpu_write(gpu, REG_A6XX_PC_DBG_ECO_CNTL, 0x00300200);
- else
[PATCH v4 1/2] drm/i915: document caching related bits
Try to document the object caching related bits, like cache_coherent and
cache_dirty.
v2(Ville):
- As pointed out by Ville, fix the completely incorrect assumptions
about the "partial" coherency on shared LLC platforms.
v3(Daniel):
- Fix nonsense about "dirtying" the cache with reads.
v4(Daniel):
- Various improvements, including adding some more details for WT.
Suggested-by: Daniel Vetter
Signed-off-by: Matthew Auld
Cc: Ville Syrjälä
Cc: Mika Kuoppala
Reviewed-by: Daniel Vetter
---
.../gpu/drm/i915/gem/i915_gem_object_types.h | 187 +-
drivers/gpu/drm/i915/i915_drv.h | 9 -
2 files changed, 183 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index afbadfc5516b..79de925aecfd 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -92,6 +92,86 @@ struct drm_i915_gem_object_ops {
const char *name; /* friendly name for debug, e.g. lockdep classes */
};
+/**
+ * enum i915_cache_level - The supported GTT caching values for system memory
+ * pages.
+ *
+ * These translate to some special GTT PTE bits when binding pages into some
+ * address space. It also determines whether an object, or rather its pages are
+ * coherent with the GPU, when also reading or writing through the CPU cache
+ * with those pages.
+ *
+ * Userspace can also control this through struct drm_i915_gem_caching.
+ */
+enum i915_cache_level {
+ /**
+* @I915_CACHE_NONE:
+*
+* GPU access is not coherent with the CPU cache. If the cache is dirty
+* and we need the underlying pages to be coherent with some later GPU
+* access then we need to manually flush the pages.
+*
+* On shared LLC platforms reads and writes through the CPU cache are
+* still coherent even with this setting. See also
+* &drm_i915_gem_object.cache_coherent for more details. Due to this we
+* should only ever use uncached for scanout surfaces, otherwise we end
+* up over-flushing in some places.
+*
+* This is the default on non-LLC platforms.
+*/
+ I915_CACHE_NONE = 0,
+ /**
+* @I915_CACHE_LLC:
+*
+* GPU access is coherent with the CPU cache. If the cache is dirty,
+* then the GPU will ensure that access remains coherent, when both
+* reading and writing through the CPU cache. GPU writes can dirty the
+* CPU cache.
+*
+* Not used for scanout surfaces.
+*
+* Applies to both platforms with shared LLC(HAS_LLC), and snooping
+* based platforms(HAS_SNOOP).
+*
+* This is the default on shared LLC platforms. The only exception is
+* scanout objects, where the display engine is not coherent with the
+* CPU cache. For such objects I915_CACHE_NONE or I915_CACHE_WT is
+* automatically applied by the kernel in pin_for_display, if userspace
+* has not done so already.
+*/
+ I915_CACHE_LLC,
+ /**
+* @I915_CACHE_L3_LLC:
+*
+* Explicitly enable the Gfx L3 cache, with coherent LLC.
+*
+* The Gfx L3 sits between the domain specific caches, e.g
+* sampler/render caches, and the larger LLC. LLC is coherent with the
+* GPU, but L3 is only visible to the GPU, so likely needs to be flushed
+* when the workload completes.
+*
+* Not used for scanout surfaces.
+*
+* Only exposed on some gen7 + GGTT. More recent hardware has dropped
+* this explicit setting, where it should now be enabled by default.
+*/
+ I915_CACHE_L3_LLC,
+ /**
+* @I915_CACHE_WT:
+*
+* Write-through. Used for scanout surfaces.
+*
+* The GPU can utilise the caches, while still having the display engine
+* be coherent with GPU writes, as a result we don't need to flush the
+* CPU caches when moving out of the render domain. This is the default
+* setting chosen by the kernel, if supported by the HW, otherwise we
+* fallback to I915_CACHE_NONE. On the CPU side writes through the CPU
+* cache still need to be flushed, to remain coherent with the display
+* engine.
+*/
+ I915_CACHE_WT,
+};
+
enum i915_map_type {
I915_MAP_WB = 0,
I915_MAP_WC,
@@ -229,14 +309,113 @@ struct drm_i915_gem_object {
unsigned int mem_flags;
#define I915_BO_FLAG_STRUCT_PAGE BIT(0) /* Object backed by struct pages */
#define I915_BO_FLAG_IOMEM BIT(1) /* Object backed by IO memory */
- /*
-* Is the object to be mapped as read-only to the GPU
-* Only honoured if hardware has relevant pte bit
+ /**
+* @cache_level: The desired GTT caching level.
+*
+* See enum i915_c
[PATCH v4 2/2] drm/i915/ehl: unconditionally flush the pages on acquire
EHL and JSL add the 'Bypass LLC' MOCS entry, which should make it
possible for userspace to bypass the GTT caching bits set by the kernel,
as per the given object cache_level. This is troublesome since the heavy
flush we apply when first acquiring the pages is skipped if the kernel
thinks the object is coherent with the GPU. As a result it might be
possible to bypass the cache and read the contents of the page directly,
which could be stale data. If it's just a case of userspace shooting
themselves in the foot then so be it, but since i915 takes the stance of
always zeroing memory before handing it to userspace, we need to prevent
this.
v2: this time actually set cache_dirty in put_pages()
v3: move to get_pages() which looks simpler
BSpec: 34007
References: 046091758b50 ("Revert "drm/i915/ehl: Update MOCS table for EHL"")
Signed-off-by: Matthew Auld
Cc: Tejas Upadhyay
Cc: Francisco Jerez
Cc: Lucas De Marchi
Cc: Jon Bloomfield
Cc: Chris Wilson
Cc: Matt Roper
Cc: Daniel Vetter
Reviewed-by: Daniel Vetter
---
.../gpu/drm/i915/gem/i915_gem_object_types.h | 6 ++
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 18 ++
2 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 79de925aecfd..2471f36aaff3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -415,6 +415,12 @@ struct drm_i915_gem_object {
* Note that on shared LLC platforms we still apply the heavy flush for
* I915_CACHE_NONE objects, under the assumption that this is going to
* be used for scanout.
+*
+* Update: On some hardware there is now also the 'Bypass LLC' MOCS
+* entry, which defeats our @cache_coherent tracking, since userspace
+* can freely bypass the CPU cache when touching the pages with the GPU,
+* where the kernel is completely unaware. On such platform we need
+* apply the sledgehammer-on-acquire regardless of the @cache_coherent.
*/
unsigned int cache_dirty:1;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
index 6a04cce188fc..11f072193f3b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
@@ -182,6 +182,24 @@ static int shmem_get_pages(struct drm_i915_gem_object *obj)
if (i915_gem_object_needs_bit17_swizzle(obj))
i915_gem_object_do_bit_17_swizzle(obj, st);
+ /*
+* EHL and JSL add the 'Bypass LLC' MOCS entry, which should make it
+* possible for userspace to bypass the GTT caching bits set by the
+* kernel, as per the given object cache_level. This is troublesome
+* since the heavy flush we apply when first gathering the pages is
+* skipped if the kernel thinks the object is coherent with the GPU. As
+* a result it might be possible to bypass the cache and read the
+* contents of the page directly, which could be stale data. If it's
+* just a case of userspace shooting themselves in the foot then so be
+* it, but since i915 takes the stance of always zeroing memory before
+* handing it to userspace, we need to prevent this.
+*
+* By setting cache_dirty here we make the clflush in set_pages
+* unconditional on such platforms.
+*/
+ if (IS_JSL_EHL(i915) && obj->flags & I915_BO_ALLOC_USER)
+ obj->cache_dirty = true;
+
__i915_gem_object_set_pages(obj, st, sg_page_sizes);
return 0;
--
2.26.3
Re: [PATCH v2 09/14] soc: mediatek: mmsys: Add reset controller support for MT8195 vdosys1
Hi Nancy,
Thank you for your patch.
Missatge de Nancy.Lin del dia dj., 22 de jul.
2021 a les 11:46:
>
> Among other features the mmsys driver should implement a reset
> controller to be able to reset different bits from their space.
>
I'm working on a series that does the same, it should be nice if we
can coordinate [1]
[1] https://patchwork.kernel.org/project/linux-mediatek/list/?series=515355
> Signed-off-by: Nancy.Lin
> ---
> drivers/soc/mediatek/mt8195-mmsys.h | 1 +
> drivers/soc/mediatek/mtk-mmsys.c| 77 +
> drivers/soc/mediatek/mtk-mmsys.h| 1 +
> 3 files changed, 79 insertions(+)
>
> diff --git a/drivers/soc/mediatek/mt8195-mmsys.h
> b/drivers/soc/mediatek/mt8195-mmsys.h
> index 4bdb2087250c..a7f6e275bfe5 100644
> --- a/drivers/soc/mediatek/mt8195-mmsys.h
> +++ b/drivers/soc/mediatek/mt8195-mmsys.h
> @@ -154,6 +154,7 @@
> #define DISP_DP_INTF0_SEL_IN_FROM_VDO0_MERGE_DL_ASYNC_MOUT (1 << 0)
> #define DISP_DP_INTF0_SEL_IN_FROM_VDO0_DSC_DL_ASYNC_MOUT (2 << 0)
>
> +#define MT8195_VDO1_SW0_RST_B 0x1d0
> #define MT8195_VDO1_MERGE0_ASYNC_CFG_WD0xe30
> #define MT8195_VDO1_MERGE1_ASYNC_CFG_WD0xe40
> #define MT8195_VDO1_MERGE2_ASYNC_CFG_WD0xe50
> diff --git a/drivers/soc/mediatek/mtk-mmsys.c
> b/drivers/soc/mediatek/mtk-mmsys.c
> index d0f4a407f8f8..1ae04efeadab 100644
> --- a/drivers/soc/mediatek/mtk-mmsys.c
> +++ b/drivers/soc/mediatek/mtk-mmsys.c
> @@ -4,10 +4,12 @@
> * Author: James Liao
> */
>
> +#include
> #include
> #include
> #include
> #include
> +#include
> #include
>
> #include "mtk-mmsys.h"
> @@ -15,6 +17,8 @@
> #include "mt8183-mmsys.h"
> #include "mt8195-mmsys.h"
>
> +#define MMSYS_SW_RESET_PER_REG 32
> +
> static const struct mtk_mmsys_driver_data mt2701_mmsys_driver_data = {
> .clk_driver = "clk-mt2701-mm",
> .routes = mmsys_default_routing_table,
> @@ -65,12 +69,15 @@ static const struct mtk_mmsys_driver_data
> mt8195_vdosys1_driver_data = {
> .num_routes = ARRAY_SIZE(mmsys_mt8195_routing_table),
> .config = mmsys_mt8195_config_table,
> .num_configs = ARRAY_SIZE(mmsys_mt8195_config_table),
> + .sw_reset_start = MT8195_VDO1_SW0_RST_B,
That change is interesting and I think I should also take it into
consideration with my series.
> };
>
> struct mtk_mmsys {
> void __iomem *regs;
> struct cmdq_client_reg cmdq_base;
> const struct mtk_mmsys_driver_data *data;
> + spinlock_t lock; /* protects mmsys_sw_rst_b reg */
Seems that mmsys_sw_rst_b reg has different names for different SoCs?
I mean I know that for MT8173 and MT8183 the register is called
mmsys_sw0_rst_b but looks like for MT8195 the name is vdo1_sw0_rst_b?
So maybe we should update this comment to be more generic.
> + struct reset_controller_dev rcdev;
> };
>
> void mtk_mmsys_ddp_connect(struct device *dev,
> @@ -148,6 +155,63 @@ void mtk_mmsys_ddp_config(struct device *dev, enum
> mtk_mmsys_config_type config,
> }
> EXPORT_SYMBOL_GPL(mtk_mmsys_ddp_config);
>
> +static int mtk_mmsys_reset_update(struct reset_controller_dev *rcdev,
> unsigned long id,
> + bool assert)
> +{
> + struct mtk_mmsys *mmsys = container_of(rcdev, struct mtk_mmsys,
> rcdev);
> + unsigned long flags;
> + u32 reg;
> + int i;
> + u32 offset;
> +
> + offset = (id / MMSYS_SW_RESET_PER_REG) * sizeof(u32);
> + id = 1 << (id % MMSYS_SW_RESET_PER_REG);
> +
> + spin_lock_irqsave(&mmsys->lock, flags);
> +
> + reg = readl_relaxed(mmsys->regs + mmsys->data->sw_reset_start +
> offset);
> +
> + if (assert)
> + reg &= ~BIT(id);
> + else
> + reg |= BIT(id);
> +
> + writel_relaxed(reg, mmsys->regs + mmsys->data->sw_reset_start +
> offset);
> +
> + spin_unlock_irqrestore(&mmsys->lock, flags);
> +
> + return 0;
> +}
> +
> +static int mtk_mmsys_reset_assert(struct reset_controller_dev *rcdev,
> unsigned long id)
> +{
> + return mtk_mmsys_reset_update(rcdev, id, true);
> +}
> +
> +static int mtk_mmsys_reset_deassert(struct reset_controller_dev *rcdev,
> unsigned long id)
> +{
> + return mtk_mmsys_reset_update(rcdev, id, false);
> +}
> +
> +static int mtk_mmsys_reset(struct reset_controller_dev *rcdev, unsigned long
> id)
> +{
> + int ret;
> +
> + ret = mtk_mmsys_reset_assert(rcdev, id);
> + if (ret)
> + return ret;
> +
> + usleep_range(1000, 1100);
> +
One question that I received in my series, and I couldn't answer
because I don't have the datasheet, is if
is this known to be enough for all IP cores that can be reset by this
controller? Is this time specified in the datasheet?
> + return mtk_mmsys_reset_deassert(rcdev, id);
> +}
> +
> +static const struct reset_control_ops mtk_mmsys_reset_ops = {
> + .assert = mtk_mmsys_reset_assert,
> + .deassert = mtk_mmsys_re
[PATCH v3] backlight: pwm_bl: Improve bootloader/kernel device handover
Currently there are (at least) two problems in the way pwm_bl starts
managing the enable_gpio pin. Both occur when the backlight is initially
off and the driver finds the pin not already in output mode and, as a
result, unconditionally switches it to output-mode and asserts the signal.
Problem 1: This could cause the backlight to flicker since, at this stage
in driver initialisation, we have no idea what the PWM and regulator are
doing (an unconfigured PWM could easily "rest" at 100% duty cycle).
Problem 2: This will cause us not to correctly honour the
post_pwm_on_delay (which also risks flickers).
Fix this by moving the code to configure the GPIO output mode until after
we have examines the handover state. That allows us to initialize
enable_gpio to off if the backlight is currently off and on if the
backlight is on.
There has also been lots of discussion recently about how pwm_bl inherits
the initial state established by the bootloader (or by power-on reset if
the bootloader doesn't do anything to the backlight). Let's take this
chance to document the four handover cases.
Reported-by: Marek Vasut
Signed-off-by: Daniel Thompson
Cc: sta...@vger.kernel.org
Fixes: 3698d7e7d221 ("backlight: pwm_bl: Avoid backlight flicker when probed
from DT")
Acked-by: Marek Vasut
Tested-by: Marek Vasut
---
Notes:
v3: Added better documentation of the different handover cases (thanks
Marek)
v2: Added Fixes: tag (sorry for the noise)
drivers/video/backlight/pwm_bl.c | 110 +++
1 file changed, 83 insertions(+), 27 deletions(-)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index e48fded3e414..5dda3f11129a 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -406,9 +406,90 @@ static bool pwm_backlight_is_linear(struct
platform_pwm_backlight_data *data)
return true;
}
+/*
+ * Inherit the initial power state from the hardware.
+ *
+ * This function provides the features necessary to achieve a flicker-free boot
+ * sequence regardless of the initial state of the backlight.
+ *
+ * There are two factors that affect the behaviour of this function.
+ *
+ * 1. Whether the backlight was on or off when the kernel was booted. We
+ *currently determine the state of the backlight by checking if the PWM is
+ *enabled, whether the regulator (if there is one) is enabled and whether
+ *the enable_gpio (if there is one) is asserted. All must be enabled for
+ *the backlight to be on.
+ *
+ * 2. Whether the backlight is linked to a display device. This matters because
+ *when there is a linked display is will automatically handle the
+ *backlight as part of its own blank/unblanking.
+ *
+ * This gives us four possible cases.
+ *
+ * Backlight initially off, display linked:
+ *
+ * The backlight must remain off (a.k.a. FB_BLANK_POWERDOWN) during and after
+ * the backlight probe. This allows a splash screen to be drawn before the
+ * backlight is enabled by the display driver. This avoids a flicker when the
+ * backlight comes on (which typically changes the black level slightly)
+ * before the splash image has been drawn.
+ *
+ * Backlight initially on, display linked:
+ *
+ * The backlight must remain on (a.k.a. FB_BLANK_UNBLANK) during and after
+ * the backlight probe. This allows a bootloader to show a splash screen and
+ * for the display system (including the backlight) to continue showing the
+ * splash image until the kernel is ready to take over the display and draw
+ * something else.
+ *
+ * Backlight initially off, no display:
+ *
+ * The backlight must transition from off to on (a.k.a. FB_BLANK_UNBLANK)
+ * during the backlight probe. This is largely a legacy case. We must
+ * unblank the backlight at boot because some userspaces are not
+ * capable of changing the power state of a free-standing backlight
+ * (they only know how to set the brightness level).
+ *
+ * Backlight initially on, no display:
+ *
+ * Identical to the initially on, display linked case.
+ *
+ * Note: In both cases where backlight is initially off then we must
+ * explicitly deassert the enable_gpio in order to ensure we
+ * honour the post_pwm_on_delay when the backlight is eventually
+ * activated. This is required regardless of both the initial state of
+ * the enable pin and whether we intend to activate the backlight during
+ * the probe.
+ */
static int pwm_backlight_initial_power_state(const struct pwm_bl_data *pb)
{
- struct device_node *node = pb->dev->of_node;
+ struct device_node *node = pb->dev->of_node; bool active = true;
+
+ /*
+* If the enable GPIO is present, observable (either as input
+* or output) and off then the backlight is not currently active.
+*/
+ if (pb->enable_gpio && gpiod_get_value_cansleep(pb->enable_gpio) == 0)
+ active = false;
+
+ if
Re: [PATCH v2 07/14] soc: mediatek: add mtk-mmsys support for mt8195 vdosys1
Hi Nancy,
Thank you for your patch.
Missatge de Nancy.Lin del dia dj., 22 de jul.
2021 a les 11:45:
>
> Add mt8195 vdosys1 clock driver name and routing table to
> the driver data of mtk-mmsys.
>
> Signed-off-by: Nancy.Lin
> ---
> drivers/soc/mediatek/mt8195-mmsys.h| 83 --
> drivers/soc/mediatek/mtk-mmsys.c | 10
> include/linux/soc/mediatek/mtk-mmsys.h | 2 +
> 3 files changed, 90 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/soc/mediatek/mt8195-mmsys.h
> b/drivers/soc/mediatek/mt8195-mmsys.h
> index 73e9e8286d50..104ba575f765 100644
> --- a/drivers/soc/mediatek/mt8195-mmsys.h
> +++ b/drivers/soc/mediatek/mt8195-mmsys.h
> @@ -64,16 +64,16 @@
> #define SOUT_TO_VPP_MERGE0_P1_SEL (1 << 0)
>
> #define MT8195_VDO1_MERGE0_ASYNC_SOUT_SEL 0xf40
> -#define SOUT_TO_HDR_VDO_FE0(0 << 0)
This definition was introduced in this patch [1] that didn't land yet.
And you're removing it now. Could you sync with Jason and only
introduce the bits that are needed for your patches. Also all the
comments I made to the Jason's patch apply here.
[1]
https://patchwork.kernel.org/project/linux-mediatek/patch/20210723090233.24007-3-jason-jh@mediatek.com/
> +#define SOUT_TO_MIXER_IN1_SEL (1 << 0)
>
> #define MT8195_VDO1_MERGE1_ASYNC_SOUT_SEL 0xf44
> -#define SOUT_TO_HDR_VDO_FE1(0 << 0)
> +#define SOUT_TO_MIXER_IN2_SEL (1 << 0)
>
> #define MT8195_VDO1_MERGE2_ASYNC_SOUT_SEL 0xf48
> -#define SOUT_TO_HDR_GFX_FE0(0 << 0)
> +#define SOUT_TO_MIXER_IN3_SEL (1 << 0)
>
> #define MT8195_VDO1_MERGE3_ASYNC_SOUT_SEL 0xf4c
> -#define SOUT_TO_HDR_GFX_FE1(0 << 0)
> +#define SOUT_TO_MIXER_IN4_SEL (1 << 0)
>
> #define MT8195_VDO1_MIXER_IN1_SOUT_SEL 0xf58
> #define MIXER_IN1_SOUT_TO_DISP_MIXER (0 << 0)
> @@ -88,7 +88,7 @@
> #define MIXER_IN4_SOUT_TO_DISP_MIXER (0 << 0)
>
> #define MT8195_VDO1_MIXER_OUT_SOUT_SEL 0xf34
> -#define MIXER_SOUT_TO_HDR_VDO_BE0 (0 << 0)
> +#define MIXER_SOUT_TO_MERGE4_ASYNC_SEL (1 << 0)
>
> #define MT8195_VDO1_MERGE4_SOUT_SEL0xf18
> #define MERGE4_SOUT_TO_VDOSYS0 (0 << 0)
> @@ -185,6 +185,79 @@ static const struct mtk_mmsys_routes
> mmsys_mt8195_routing_table[] = {
> }, {
> DDP_COMPONENT_DSC0, DDP_COMPONENT_MERGE0,
> MT8195_VDO0_SEL_OUT, SOUT_DSC_WRAP0_OUT_TO_VPP_MERGE
> + },
> + {
> + DDP_COMPONENT_PSEUDO_OVL, DDP_COMPONENT_MERGE5,
> + MT8195_VDO1_VPP_MERGE0_P0_SEL_IN,
> VPP_MERGE0_P0_SEL_IN_FROM_MDP_RDMA0
> + },
> + {
> + DDP_COMPONENT_PSEUDO_OVL, DDP_COMPONENT_MERGE5,
> + MT8195_VDO1_VPP_MERGE0_P1_SEL_IN,
> VPP_MERGE0_P1_SEL_IN_FROM_MDP_RDMA1
> + },
> + {
> + DDP_COMPONENT_PSEUDO_OVL, DDP_COMPONENT_MERGE5,
> + MT8195_VDO1_VPP_MERGE1_P0_SEL_IN,
> VPP_MERGE1_P0_SEL_IN_FROM_MDP_RDMA2
> + },
> + {
> + DDP_COMPONENT_PSEUDO_OVL, DDP_COMPONENT_MERGE5,
> + MT8195_VDO1_MERGE0_ASYNC_SOUT_SEL, SOUT_TO_MIXER_IN1_SEL
> + },
> + {
> + DDP_COMPONENT_PSEUDO_OVL, DDP_COMPONENT_MERGE5,
> + MT8195_VDO1_MERGE1_ASYNC_SOUT_SEL, SOUT_TO_MIXER_IN2_SEL
> + },
> + {
> + DDP_COMPONENT_PSEUDO_OVL, DDP_COMPONENT_MERGE5,
> + MT8195_VDO1_MERGE2_ASYNC_SOUT_SEL, SOUT_TO_MIXER_IN3_SEL
> + },
> + {
> + DDP_COMPONENT_PSEUDO_OVL, DDP_COMPONENT_MERGE5,
> + MT8195_VDO1_MERGE3_ASYNC_SOUT_SEL, SOUT_TO_MIXER_IN4_SEL
> + },
> + {
> + DDP_COMPONENT_PSEUDO_OVL, DDP_COMPONENT_MERGE5,
> + MT8195_VDO1_MIXER_OUT_SOUT_SEL, MIXER_SOUT_TO_MERGE4_ASYNC_SEL
> + },
> + {
> + DDP_COMPONENT_PSEUDO_OVL, DDP_COMPONENT_MERGE5,
> + MT8195_VDO1_MIXER_IN1_SEL_IN,
> MIXER_IN1_SEL_IN_FROM_MERGE0_ASYNC_SOUT
> + },
> + {
> + DDP_COMPONENT_PSEUDO_OVL, DDP_COMPONENT_MERGE5,
> + MT8195_VDO1_MIXER_IN2_SEL_IN,
> MIXER_IN2_SEL_IN_FROM_MERGE1_ASYNC_SOUT
> + },
> + {
> + DDP_COMPONENT_PSEUDO_OVL, DDP_COMPONENT_MERGE5,
> + MT8195_VDO1_MIXER_IN3_SEL_IN,
> MIXER_IN3_SEL_IN_FROM_MERGE2_ASYNC_SOUT
> + },
> + {
> + DDP_COMPONENT_PSEUDO_OVL, DDP_COMPONENT_MERGE5,
> + MT8195_VDO1_MIXER_IN4_SEL_IN,
> MIXER_IN4_SEL_IN_FROM_MERGE
Re: [PATCH] drm/panfrost: devfreq: Don't display error for EPROBE_DEFER
On 21/07/2021 22:48, Chris Morgan wrote:
> From: Chris Morgan
>
> Set a condition for the message of "Couldn't set OPP regulators" to not
> display if the error code is EPROBE_DEFER. Note that I used an if
> statement to capture the condition instead of the dev_err_probe
> function because I didn't want to change the DRM_DEV_ERROR usage.
Note that this file (panfost_devfreq.c) is actually the odd one out in
terms of using the DRM_DEV_xxx macros. The rest of the panfrost driver
uses the standard dev_xxx ones. So tidying this up to match the rest of
the driver would also allow us to use dev_err_probe(). But as a point
fix this patch is fine and correct. Thanks!
> Signed-off-by: Chris Morgan
Reviewed-by: Steven Price
I'll apply this to drm-misc-next.
Thanks,
Steve
> ---
> drivers/gpu/drm/panfrost/panfrost_devfreq.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> index 3644652f726f..194af7f607a6 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> @@ -106,7 +106,8 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
> if (ret) {
> /* Continue if the optional regulator is missing */
> if (ret != -ENODEV) {
> - DRM_DEV_ERROR(dev, "Couldn't set OPP regulators\n");
> + if (ret != -EPROBE_DEFER)
> + DRM_DEV_ERROR(dev, "Couldn't set OPP
> regulators\n");
> return ret;
> }
> }
>
Re: [PATCH v2 04/14] dt-bindings: reset: mt8195: Move reset controller constants into common location
Hi Nancy,
Thank you for your patch
Missatge de Nancy.Lin del dia dj., 22 de jul.
2021 a les 11:46:
>
> The DT binding includes for reset controllers are located in
> include/dt-bindings/reset/. Move the Mediatek reset constants in there.
>
I think that the patch that introduces mt8195-resets.h into the
reset-controller directory didn't land yet, please sync with the
author of that patch and just put it in the correct place the first
time.
Thanks,
Enric
> Signed-off-by: Nancy.Lin
> ---
> include/dt-bindings/{reset-controller => reset}/mt8195-resets.h | 0
> 1 file changed, 0 insertions(+), 0 deletions(-)
> rename include/dt-bindings/{reset-controller => reset}/mt8195-resets.h (100%)
>
> diff --git a/include/dt-bindings/reset-controller/mt8195-resets.h
> b/include/dt-bindings/reset/mt8195-resets.h
> similarity index 100%
> rename from include/dt-bindings/reset-controller/mt8195-resets.h
> rename to include/dt-bindings/reset/mt8195-resets.h
> --
> 2.18.0
>
Re: [PATCH v1 1/5] dt-bindings: arm: mediatek: mmsys: add mt8195 SoC binding
Hi Jason, Thank you for your patch. Missatge de jason-jh.lin del dia dj., 22 de jul. 2021 a les 11:26: > > There are 2 display hardware path in mt8195, namely vdosys0 and > vdosys1, so add their definition in mtk-mmsys documentation. > Just having 2 display hardware paths is not a reason to have two compatibles, isn't the IP block the same? Why do you need to introduce the two compatibles? Thanks, Enric > Signed-off-by: jason-jh.lin > --- > this patch is base on [1][2] > > [1] dt-bindings: arm: mediatek: mmsys: convert to YAML format > - > https://patchwork.kernel.org/project/linux-mediatek/patch/20210519161847.3747352-1-fpar...@baylibre.com/ > [2] dt-bindings: arm: mediatek: mmsys: add MT8365 SoC binding > - > https://patchwork.kernel.org/project/linux-mediatek/patch/20210519161847.3747352-2-fpar...@baylibre.com/ > --- > .../devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml| 2 ++ > 1 file changed, 2 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml > b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml > index 2d4ff0ce387b..0789a9614f12 100644 > --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml > +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml > @@ -30,6 +30,8 @@ properties: >- mediatek,mt8173-mmsys >- mediatek,mt8183-mmsys >- mediatek,mt8365-mmsys > + - mediatek,mt8195-vdosys0 > + - mediatek,mt8195-vdosys1 >- const: syscon >- items: >- const: mediatek,mt7623-mmsys > -- > 2.18.0 >
Re: [PATCH] backlight: pwm_bl: Avoid backlight flicker if backlight control GPIO is input
On Fri, Jul 23, 2021 at 11:15:10AM +0100, Daniel Thompson wrote: > On Thu, Jul 22, 2021 at 09:02:04PM +0200, Marek Vasut wrote: > > On 7/22/21 1:28 PM, Daniel Thompson wrote: > > > On Wed, Jul 21, 2021 at 08:46:42PM +0200, Marek Vasut wrote: > > > > On 7/21/21 6:12 PM, Daniel Thompson wrote: > > > > > On Wed, Jul 21, 2021 at 05:09:57PM +0200, Marek Vasut wrote: > > > > > > On 7/21/21 12:49 PM, Daniel Thompson wrote: > > > > > [...] > > > > > This sails very close to the > > > > > edge of what is in-scope for DT (at least it does it we can read > > > > > the inherited state directly from the hardware). > > > > > > > > The problem with reading it out of hardware is that the hardware might > > > > be in > > > > undefined state and expects Linux to define that state, so that does not > > > > always work. Hence my initial suggestion to add a DT property to define > > > > the > > > > state up front, instead of using these fragile heuristics. > > > > > > To achieve a flicker-free boot we must know the initial state of the > > > backlight (not just the enable pin). > > > > The backlight hardware might be in uninitialized state and then Linux should > > set the state, likely based on something in DT, because there is no previous > > state to read. > > There is always a previous state. The kernel doesn't care whether that > previous state was imposed by a power-on reset, the bootloader or a > kexec. > > For the driver to come up flicker-free in all the different cases we > need to know whether the backlight is currently emitting light or not > and, if it is emitting light, then we need to know what the duty cycle > is (currently we inherit require the PWM driver to correctly inherit the > duty cycle from the hardware). Oops... this is wrong (I think it is cross-talk from an old patch). We do not currently inherit the duty cycle. > So far, the previous state has been observable by the lower level > drivers (GPIO, PWM, regulator). I remain reluctant to provide > workarounds for cases where it is not observable without motivating > hardware. I certainly wouldn't want to make such bindings mandatory > since observable hardware registers are a far more reliable source of > truth than what the DT tells us about what it thinks the bootloader > (or power-on reset) actually did ;-). Which makes conclusion badly reasoned. However, until we can clearly articulate whether the problem we want to solve is describing the initial backlight state or specifying the default (post-probe) power state for the legacy cases I'm still content not to change things ;-). > > > [...] > > > Wow! That is *way* longer than I intended when I started writing it. > > > Anyhow I suspect any disconnect comes about due to the difference in > > > backlight state *after* probe being, in part, to software structure > > > rather than purely a hardware property. > > > > Maybe this should be added to documentation. > > I'll see what I can do. Done, see v3. I think it is better explained than the e-mail version. Daniel.
Re: [Intel-gfx] [RFC 0/8] Per client GPU stats
On 15/07/2021 10:18, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Same old work but now rebased and series ending with some DRM docs proposing the common specification which should enable nice common userspace tools to be written. For the moment I only have intel_gpu_top converted to use this and that seems to work okay. v2: * Added prototype of possible amdgpu changes and spec updates to align with the common spec. Not much interest for the common specification? For reference I've just posted the intel-gpu-top adaptation required to parse it here: https://patchwork.freedesktop.org/patch/446041/?series=90464&rev=2. Note that this is not attempting to be a vendor agnostic tool but is adding per client data to existing i915 tool which uses PMU counters for global stats. intel-gpu-top: Intel Skylake (Gen9) @ /dev/dri/card0 - 335/ 339 MHz; 10% RC6; 1.24/ 4.18 W; 527 irqs/s IMC reads: 3297 MiB/s IMC writes: 2767 MiB/s ENGINES BUSY MI_SEMA MI_WAIT Render/3D 78.74% |██▏ | 0% 0% Blitter0.00% | | 0% 0% Video0.00% | | 0% 0% VideoEnhance0.00% | | 0% 0% PID NAME Render/3DBlitter VideoVideoEnhance 10202 neverball |███▎ || || || | 5665 Xorg |███▍ || || || | 5679 xfce4-session | || || || | 5772 ibus-ui-gtk3 | || || || | 5775 ibus-extension- | || || || | 5777 ibus-x11 | || || || | 5823 xfwm4 | || || || | Regards, Tvrtko Tvrtko Ursulin (8): drm/i915: Explicitly track DRM clients drm/i915: Make GEM contexts track DRM clients drm/i915: Track runtime spent in closed and unreachable GEM contexts drm/i915: Track all user contexts per client drm/i915: Track context current active time drm: Document fdinfo format specification drm/i915: Expose client engine utilisation via fdinfo drm/amdgpu: Convert to common fdinfo format Documentation/gpu/amdgpu.rst | 26 Documentation/gpu/drm-usage-stats.rst | 108 + Documentation/gpu/i915.rst| 27 Documentation/gpu/index.rst | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c| 18 ++- drivers/gpu/drm/i915/Makefile | 5 +- drivers/gpu/drm/i915/gem/i915_gem_context.c | 42 - .../gpu/drm/i915/gem/i915_gem_context_types.h | 6 + drivers/gpu/drm/i915/gt/intel_context.c | 27 +++- drivers/gpu/drm/i915/gt/intel_context.h | 15 +- drivers/gpu/drm/i915/gt/intel_context_types.h | 24 ++- .../drm/i915/gt/intel_execlists_submission.c | 23 ++- .../gpu/drm/i915/gt/intel_gt_clock_utils.c| 4 + drivers/gpu/drm/i915/gt/intel_lrc.c | 27 ++-- drivers/gpu/drm/i915/gt/intel_lrc.h | 24 +++ drivers/gpu/drm/i915/gt/selftest_lrc.c| 10 +- drivers/gpu/drm/i915/i915_drm_client.c| 143 ++ drivers/gpu/drm/i915/i915_drm_client.h| 66 drivers/gpu/drm/i915/i915_drv.c | 9 ++ drivers/gpu/drm/i915/i915_drv.h | 5 + drivers/gpu/drm/i915/i915_gem.c | 21 ++- drivers/gpu/drm/i915/i915_gpu_error.c | 9 +- drivers/gpu/drm/i915/i915_gpu_error.h | 2 +- 23 files changed, 581 insertions(+), 61 deletions(-) create mode 100644 Documentation/gpu/drm-usage-stats.rst create mode 100644 drivers/gpu/drm/i915/i915_drm_client.c create mode 100644 drivers/gpu/drm/i915/i915_drm_client.h
[PATCH] arm64: dts: qcom: sc7280: Add gpu support
Add the necessary dt nodes for gpu support in sc7280.
Signed-off-by: Akhil P Oommen
---
This patch has dependency on the GPUCC bindings patch here:
https://patchwork.kernel.org/project/linux-arm-msm/patch/1619519590-3019-4-git-send-email-t...@codeaurora.org/
arch/arm64/boot/dts/qcom/sc7280.dtsi | 107 +++
1 file changed, 107 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index 029723a..beb313c 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -16,6 +16,8 @@
#include
#include
#include
+#include
+#include
/ {
interrupt-parent = <&intc>;
@@ -592,6 +594,111 @@
qcom,bcm-voters = <&apps_bcm_voter>;
};
+ gpu: gpu@3d0 {
+ compatible = "qcom,adreno-635.0", "qcom,adreno";
+ #stream-id-cells = <16>;
+ reg = <0 0x03d0 0 0x4>, <0 0x03d9e000 0 0x1000>,
+ <0 0x03d61000 0 0x800>;
+ reg-names = "kgsl_3d0_reg_memory", "cx_mem", "cx_dbgc";
+ interrupts = ;
+ iommus = <&adreno_smmu 0 0x401>;
+ operating-points-v2 = <&gpu_opp_table>;
+ qcom,gmu = <&gmu>;
+ interconnects = <&gem_noc MASTER_GFX3D 0 &mc_virt
SLAVE_EBI1 0>;
+ interconnect-names = "gfx-mem";
+
+ gpu_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-55000 {
+ opp-hz = /bits/ 64 <55000>;
+ opp-level =
;
+ opp-peak-kBps = <6832000>;
+ };
+
+ opp-45000 {
+ opp-hz = /bits/ 64 <45000>;
+ opp-level = ;
+ opp-peak-kBps = <4068000>;
+ };
+
+ opp-31500 {
+ opp-hz = /bits/ 64 <31500>;
+ opp-level =
;
+ opp-peak-kBps = <1804000>;
+ };
+ };
+ };
+
+ adreno_smmu: iommu@3da {
+ compatible = "qcom,sc7280-smmu-500",
"qcom,adreno-smmu", "arm,mmu-500";
+ reg = <0 0x03da 0 0x2>;
+ #iommu-cells = <2>;
+ #global-interrupts = <2>;
+ interrupts = ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ;
+
+ clocks = <&gcc GCC_GPU_MEMNOC_GFX_CLK>,
+ <&gcc GCC_GPU_SNOC_DVM_GFX_CLK>,
+ <&gpucc GPU_CC_AHB_CLK>,
+ <&gpucc GPU_CC_HLOS1_VOTE_GPU_SMMU_CLK>,
+ <&gpucc GPU_CC_CX_GMU_CLK>,
+ <&gpucc GPU_CC_HUB_CX_INT_CLK>,
+ <&gpucc GPU_CC_HUB_AON_CLK>;
+ clock-names = "gcc_gpu_memnoc_gfx_clk",
+ "gcc_gpu_snoc_dvm_gfx_clk",
+ "gpu_cc_ahb_clk",
+ "gpu_cc_hlos1_vote_gpu_smmu_clk",
+ "gpu_cc_cx_gmu_clk",
+ "gpu_cc_hub_cx_int_clk",
+ "gpu_cc_hub_aon_clk";
+
+ power-domains = <&gpucc GPU_CC_CX_GDSC>;
+ };
+
+ gmu: gmu@3d69000 {
+ compatible="qcom,adreno-gmu-635.0", "qcom,adreno-gmu";
+ reg = <0 0x03d6a000 0 0x34000>,
+ <0 0x3de 0 0x1>,
+ <0 0x0b29 0 0x1>;
+ reg-names = "gmu", "rscc", "gmu_pdc";
+ interrupts = ,
+ ;
+ interrupt-names = "hfi", "gmu";
+ clocks = <&gpucc GPU_CC_CX_GMU_CLK>,
+ <&gpucc GPU_CC_CXO_CLK>,
+
Re: [Intel-gfx] [RFC 0/8] Per client GPU stats
Am 23.07.21 um 13:21 schrieb Tvrtko Ursulin: On 15/07/2021 10:18, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Same old work but now rebased and series ending with some DRM docs proposing the common specification which should enable nice common userspace tools to be written. For the moment I only have intel_gpu_top converted to use this and that seems to work okay. v2: * Added prototype of possible amdgpu changes and spec updates to align with the common spec. Not much interest for the common specification? Well I would rather say not much opposition :) Of hand everything you do in this patch set sounds absolutely sane to me, just don't have any time to review it in detail. Regards, Christian. For reference I've just posted the intel-gpu-top adaptation required to parse it here: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.freedesktop.org%2Fpatch%2F446041%2F%3Fseries%3D90464%26rev%3D2&data=04%7C01%7Cchristian.koenig%40amd.com%7Cc967de8b8c2b499eb25b08d94dcbff2e%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637626360837958764%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=07hzP1RuVQkFi8AXWK8i%2Ffu9ajnldcF36PLRrey5wXA%3D&reserved=0. Note that this is not attempting to be a vendor agnostic tool but is adding per client data to existing i915 tool which uses PMU counters for global stats. intel-gpu-top: Intel Skylake (Gen9) @ /dev/dri/card0 - 335/ 339 MHz; 10% RC6; 1.24/ 4.18 W; 527 irqs/s IMC reads: 3297 MiB/s IMC writes: 2767 MiB/s ENGINES BUSY MI_SEMA MI_WAIT Render/3D 78.74% |██▏ | 0% 0% Blitter 0.00% | | 0% 0% Video 0.00% | | 0% 0% VideoEnhance 0.00% | | 0% 0% PID NAME Render/3D Blitter Video VideoEnhance 10202 neverball |███▎ || || || | 5665 Xorg |███▍ || || || | 5679 xfce4-session | || || || | 5772 ibus-ui-gtk3 | || || || | 5775 ibus-extension- | || || || | 5777 ibus-x11 | || || || | 5823 xfwm4 | || || || | Regards, Tvrtko Tvrtko Ursulin (8): drm/i915: Explicitly track DRM clients drm/i915: Make GEM contexts track DRM clients drm/i915: Track runtime spent in closed and unreachable GEM contexts drm/i915: Track all user contexts per client drm/i915: Track context current active time drm: Document fdinfo format specification drm/i915: Expose client engine utilisation via fdinfo drm/amdgpu: Convert to common fdinfo format Documentation/gpu/amdgpu.rst | 26 Documentation/gpu/drm-usage-stats.rst | 108 + Documentation/gpu/i915.rst | 27 Documentation/gpu/index.rst | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c | 18 ++- drivers/gpu/drm/i915/Makefile | 5 +- drivers/gpu/drm/i915/gem/i915_gem_context.c | 42 - .../gpu/drm/i915/gem/i915_gem_context_types.h | 6 + drivers/gpu/drm/i915/gt/intel_context.c | 27 +++- drivers/gpu/drm/i915/gt/intel_context.h | 15 +- drivers/gpu/drm/i915/gt/intel_context_types.h | 24 ++- .../drm/i915/gt/intel_execlists_submission.c | 23 ++- .../gpu/drm/i915/gt/intel_gt_clock_utils.c | 4 + drivers/gpu/drm/i915/gt/intel_lrc.c | 27 ++-- drivers/gpu/drm/i915/gt/intel_lrc.h | 24 +++ drivers/gpu/drm/i915/gt/selftest_lrc.c | 10 +- drivers/gpu/drm/i915/i915_drm_client.c | 143 ++ drivers/gpu/drm/i915/i915_drm_client.h | 66 drivers/gpu/drm/i915/i915_drv.c | 9 ++ drivers/gpu/drm/i915/i915_drv.h | 5 + drivers/gpu/drm/i915/i915_gem.c | 21 ++- drivers/gpu/drm/i915/i915_gpu_error.c | 9 +- drivers/gpu/drm/i915/i915_gpu_error.h | 2 +- 23 files changed, 581 insertions(+), 61 deletions(-) create mode 100644 Documentation/gpu/drm-usage-stats.rst create mode 100644 drivers/gpu/drm/i915/i915_drm_client.c create mode 100644 drivers/gpu/drm/i915/i915_drm_client.h
[PATCH] drm/i915/userptr: Probe existence of backing struct pages upon creation
From: Chris Wilson
Jason Ekstrand requested a more efficient method than userptr+set-domain
to determine if the userptr object was backed by a complete set of pages
upon creation. To be more efficient than simply populating the userptr
using get_user_pages() (as done by the call to set-domain or execbuf),
we can walk the tree of vm_area_struct and check for gaps or vma not
backed by struct page (VM_PFNMAP). The question is how to handle
VM_MIXEDMAP which may be either struct page or pfn backed...
With discrete we are going to drop support for set_domain(), so offering
a way to probe the pages, without having to resort to dummy batches has
been requested.
v2:
- add new query param for the PROBE flag, so userspace can easily
check if the kernel supports it(Jason).
- use mmap_read_{lock, unlock}.
- add some kernel-doc.
v3:
- In the docs also mention that PROBE doesn't guarantee that the pages
will remain valid by the time they are actually used(Tvrtko).
- Add a small comment for the hole finding logic(Jason).
- Move the param next to all the other params which just return true.
Testcase: igt/gem_userptr_blits/probe
Signed-off-by: Chris Wilson
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Maarten Lankhorst
Cc: Tvrtko Ursulin
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: Jason Ekstrand
Cc: Daniel Vetter
Cc: Ramalingam C
Reviewed-by: Tvrtko Ursulin
Acked-by: Kenneth Graunke
Reviewed-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 41 -
drivers/gpu/drm/i915/i915_getparam.c| 1 +
include/uapi/drm/i915_drm.h | 20 ++
3 files changed, 61 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
index 56edfeff8c02..468a7a617fbf 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
@@ -422,6 +422,34 @@ static const struct drm_i915_gem_object_ops
i915_gem_userptr_ops = {
#endif
+static int
+probe_range(struct mm_struct *mm, unsigned long addr, unsigned long len)
+{
+ const unsigned long end = addr + len;
+ struct vm_area_struct *vma;
+ int ret = -EFAULT;
+
+ mmap_read_lock(mm);
+ for (vma = find_vma(mm, addr); vma; vma = vma->vm_next) {
+ /* Check for holes, note that we also update the addr below */
+ if (vma->vm_start > addr)
+ break;
+
+ if (vma->vm_flags & (VM_PFNMAP | VM_MIXEDMAP))
+ break;
+
+ if (vma->vm_end >= end) {
+ ret = 0;
+ break;
+ }
+
+ addr = vma->vm_end;
+ }
+ mmap_read_unlock(mm);
+
+ return ret;
+}
+
/*
* Creates a new mm object that wraps some normal memory from the process
* context - user memory.
@@ -477,7 +505,8 @@ i915_gem_userptr_ioctl(struct drm_device *dev,
}
if (args->flags & ~(I915_USERPTR_READ_ONLY |
- I915_USERPTR_UNSYNCHRONIZED))
+ I915_USERPTR_UNSYNCHRONIZED |
+ I915_USERPTR_PROBE))
return -EINVAL;
if (i915_gem_object_size_2big(args->user_size))
@@ -504,6 +533,16 @@ i915_gem_userptr_ioctl(struct drm_device *dev,
return -ENODEV;
}
+ if (args->flags & I915_USERPTR_PROBE) {
+ /*
+* Check that the range pointed to represents real struct
+* pages and not iomappings (at this moment in time!)
+*/
+ ret = probe_range(current->mm, args->user_ptr, args->user_size);
+ if (ret)
+ return ret;
+ }
+
#ifdef CONFIG_MMU_NOTIFIER
obj = i915_gem_object_alloc();
if (obj == NULL)
diff --git a/drivers/gpu/drm/i915/i915_getparam.c
b/drivers/gpu/drm/i915/i915_getparam.c
index 24e18219eb50..bbb7cac43eb4 100644
--- a/drivers/gpu/drm/i915/i915_getparam.c
+++ b/drivers/gpu/drm/i915/i915_getparam.c
@@ -134,6 +134,7 @@ int i915_getparam_ioctl(struct drm_device *dev, void *data,
case I915_PARAM_HAS_EXEC_FENCE_ARRAY:
case I915_PARAM_HAS_EXEC_SUBMIT_FENCE:
case I915_PARAM_HAS_EXEC_TIMELINE_FENCES:
+ case I915_PARAM_HAS_USERPTR_PROBE:
/* For the time being all of these are always true;
* if some supported hardware does not have one of these
* features this value needs to be provided from
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 975087553ea0..0d290535a6e5 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -674,6 +674,9 @@ typedef struct drm_i915_irq_wait {
*/
#define I915_PARAM_HAS_EXEC_TIMELINE_FENCES 55
+/* Query if the kernel supports the I915_USERPTR_PROBE flag. */
+#define I915_PARAM_HAS_USERPTR_PROBE 56
+
/* Must be kept com
Re: [PATCH v6] Documentation: gpu: Mention the requirements for new properties
On Tue, Jul 20, 2021 at 04:35:44PM +0200, Maxime Ripard wrote: > New KMS properties come with a bunch of requirements to avoid each > driver from running their own, inconsistent, set of properties, > eventually leading to issues like property conflicts, inconsistencies > between drivers and semantics, etc. > > Let's document what we expect. > > Cc: Alexandre Belloni > Cc: Alexandre Torgue > Cc: Alex Deucher > Cc: Alison Wang > Cc: Alyssa Rosenzweig > Cc: Andrew Jeffery > Cc: Andrzej Hajda > Cc: Anitha Chrisanthus > Cc: Benjamin Gaignard > Cc: Ben Skeggs > Cc: Boris Brezillon > Cc: Brian Starkey > Cc: Chen Feng > Cc: Chen-Yu Tsai > Cc: Christian Gmeiner > Cc: "Christian König" > Cc: Chun-Kuang Hu > Cc: Edmund Dea > Cc: Eric Anholt > Cc: Fabio Estevam > Cc: Gerd Hoffmann > Cc: Haneen Mohammed > Cc: Hans de Goede > Cc: "Heiko Stübner" > Cc: Huang Rui > Cc: Hyun Kwon > Cc: Inki Dae > Cc: Jani Nikula > Cc: Jernej Skrabec > Cc: Jerome Brunet > Cc: John Stultz > Cc: Jonas Karlman > Cc: Jonathan Hunter > Cc: Joonas Lahtinen > Cc: Joonyoung Shim > Cc: Jyri Sarha > Cc: Kevin Hilman > Cc: Kieran Bingham > Cc: Krzysztof Kozlowski > Cc: Kyungmin Park > Cc: Laurent Pinchart > Cc: Linus Walleij > Cc: Liviu Dudau > Cc: Lucas Stach > Cc: Ludovic Desroches > Cc: Marek Vasut > Cc: Martin Blumenstingl > Cc: Matthias Brugger > Cc: Maxime Coquelin > Cc: Maxime Ripard > Cc: Melissa Wen > Cc: Neil Armstrong > Cc: Nicolas Ferre > Cc: "Noralf Trønnes" > Cc: NXP Linux Team > Cc: Oleksandr Andrushchenko > Cc: Patrik Jakobsson > Cc: Paul Cercueil > Cc: Pekka Paalanen > Cc: Pengutronix Kernel Team > Cc: Philippe Cornu > Cc: Philipp Zabel > Cc: Qiang Yu > Cc: Rob Clark > Cc: Robert Foss > Cc: Rob Herring > Cc: Rodrigo Siqueira > Cc: Rodrigo Vivi > Cc: Roland Scheidegger > Cc: Russell King > Cc: Sam Ravnborg > Cc: Sandy Huang > Cc: Sascha Hauer > Cc: Sean Paul > Cc: Seung-Woo Kim > Cc: Shawn Guo > Cc: Simon Ser > Cc: Stefan Agner > Cc: Steven Price > Cc: Sumit Semwal > Cc: Thierry Reding > Cc: Tian Tao > Cc: Tomeu Vizoso > Cc: Tomi Valkeinen > Cc: VMware Graphics > Cc: Xinliang Liu > Cc: Xinwei Kong > Cc: Yannick Fertre > Cc: Zack Rusin > Reviewed-by: Pekka Paalanen > Reviewed-by: Daniel Vetter > Signed-off-by: Maxime Ripard Applied with Dave's Ack (on IRC) Maxime signature.asc Description: PGP signature
Re: [PATCH v2 06/14] vfio/fsl: Move to the device set infrastructure
On Fri, Jul 23, 2021 at 09:44:35AM +0200, Christoph Hellwig wrote: > On Tue, Jul 20, 2021 at 02:42:52PM -0300, Jason Gunthorpe wrote: > > .write = vfio_fsl_mc_write, > > @@ -625,13 +526,15 @@ static int vfio_fsl_mc_probe(struct fsl_mc_device > > *mc_dev) > > vdev->mc_dev = mc_dev; > > mutex_init(&vdev->igate); > > > > + ret = vfio_assign_device_set(&vdev->vdev, is_fsl_mc_bus_dprc(mc_dev) ? > > + &mc_dev->dev : > > + mc_dev->dev.parent); > > A good old if/else would be much cleaner here. Ok > But do we even need the else part? Assingning &mc_dev->dev is > equivalent to the default per-device set anyway, isn't it? Not quite, the default is this: if (!device->dev_set) vfio_assign_device_set(device, device); Where 'device' is the vfio_device itself, the above is connecting to the struct fsl_mc_device. Thanks, Jason
Re: [PATCH v2 07/14] vfio/platform: Use open_device() instead of open coding a refcnt scheme
On Fri, Jul 23, 2021 at 09:45:21AM +0200, Christoph Hellwig wrote: > Looks good, > > Reviewed-by: Christoph Hellwig > > On Tue, Jul 20, 2021 at 02:42:53PM -0300, Jason Gunthorpe wrote: > > Platform simply wants to run some code when the device is first > > opened/last closed. Use the core framework and locking for this. Aside > > from removing a bit of code this narrows the locking scope from a global > > lock. > > > > Signed-off-by: Yishai Hadas > > Btw, this seems to miss the second from line for Yishai, which should > match the first signoff. Hum, I think we ended up co-developing this on, I can reorder the signed off's Jason
Re: [PATCH] backlight: pwm_bl: Avoid backlight flicker if backlight control GPIO is input
On 7/23/21 1:17 PM, Daniel Thompson wrote: On Fri, Jul 23, 2021 at 11:15:10AM +0100, Daniel Thompson wrote: On Thu, Jul 22, 2021 at 09:02:04PM +0200, Marek Vasut wrote: On 7/22/21 1:28 PM, Daniel Thompson wrote: On Wed, Jul 21, 2021 at 08:46:42PM +0200, Marek Vasut wrote: On 7/21/21 6:12 PM, Daniel Thompson wrote: On Wed, Jul 21, 2021 at 05:09:57PM +0200, Marek Vasut wrote: On 7/21/21 12:49 PM, Daniel Thompson wrote: [...] This sails very close to the edge of what is in-scope for DT (at least it does it we can read the inherited state directly from the hardware). The problem with reading it out of hardware is that the hardware might be in undefined state and expects Linux to define that state, so that does not always work. Hence my initial suggestion to add a DT property to define the state up front, instead of using these fragile heuristics. To achieve a flicker-free boot we must know the initial state of the backlight (not just the enable pin). The backlight hardware might be in uninitialized state and then Linux should set the state, likely based on something in DT, because there is no previous state to read. There is always a previous state. The kernel doesn't care whether that previous state was imposed by a power-on reset, the bootloader or a kexec. For the driver to come up flicker-free in all the different cases we need to know whether the backlight is currently emitting light or not and, if it is emitting light, then we need to know what the duty cycle is (currently we inherit require the PWM driver to correctly inherit the duty cycle from the hardware). Oops... this is wrong (I think it is cross-talk from an old patch). We do not currently inherit the duty cycle. There is that, and if you did, you would be telling PWM drivers not to reset/reinit the hardware in probe. I'm not sure whether that is a good idea. So far, the previous state has been observable by the lower level drivers (GPIO, PWM, regulator). I remain reluctant to provide workarounds for cases where it is not observable without motivating hardware. I certainly wouldn't want to make such bindings mandatory since observable hardware registers are a far more reliable source of truth than what the DT tells us about what it thinks the bootloader (or power-on reset) actually did ;-). Which makes conclusion badly reasoned. However, until we can clearly articulate whether the problem we want to solve is describing the initial backlight state or specifying the default (post-probe) power state for the legacy cases I'm still content not to change things ;-). For me, it was always about specifying well defined default state of the backlight. [...] Wow! That is *way* longer than I intended when I started writing it. Anyhow I suspect any disconnect comes about due to the difference in backlight state *after* probe being, in part, to software structure rather than purely a hardware property. Maybe this should be added to documentation. I'll see what I can do. Done, see v3. I think it is better explained than the e-mail version. Thanks
[PATCH] drm/prime: fix comment on PRIME Helpers
s/Exporting/Importing
Fixes: 805dc614d58a8 ("drm/prime: Update docs")
Cc: Daniel Vetter
Signed-off-by: Jose Maria Casanova Crespo
---
drivers/gpu/drm/drm_prime.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 2a54f86856af..178e18c28cab 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -549,7 +549,7 @@ int drm_prime_handle_to_fd_ioctl(struct drm_device *dev,
void *data,
*
* FIXME: The underlying helper functions are named rather inconsistently.
*
- * Exporting buffers
+ * Importing buffers
* ~
*
* Importing dma-bufs using drm_gem_prime_import() relies on
--
2.20.1
Re: [PATCH] dma-buf: WARN on dmabuf release with pending attachments
Am 23.07.21 um 14:31 schrieb Charan Teja Reddy: It is expected from the clients to follow the below steps on an imported dmabuf fd: a) dmabuf = dma_buf_get(fd) // Get the dmabuf from fd b) dma_buf_attach(dmabuf); // Clients attach to the dmabuf o Here the kernel does some slab allocations, say for dma_buf_attachment and may be some other slab allocation in the dmabuf->ops->attach(). c) Client may need to do dma_buf_map_attachment(). d) Accordingly dma_buf_unmap_attachment() should be called. e) dma_buf_detach () // Clients detach to the dmabuf. o Here the slab allocations made in b) are freed. f) dma_buf_put(dmabuf) // Can free the dmabuf if it is the last reference. Now say an erroneous client failed at step c) above thus it directly called dma_buf_put(), step f) above. Considering that it may be the last reference to the dmabuf, buffer will be freed with pending attachments left to the dmabuf which can show up as the 'memory leak'. This should at least be reported as the WARN(). Signed-off-by: Charan Teja Reddy Good idea. I would expect a crash immediately, but from such a backtrace it is quite hard to tell what the problem is. Patch is Reviewed-by: Christian König and I'm going to push this to drm-misc-next on Monday if nobody objects. Thanks, Christian. --- drivers/dma-buf/dma-buf.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index 511fe0d..733c8b1 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -79,6 +79,7 @@ static void dma_buf_release(struct dentry *dentry) if (dmabuf->resv == (struct dma_resv *)&dmabuf[1]) dma_resv_fini(dmabuf->resv); + WARN_ON(!list_empty(&dmabuf->attachments)); module_put(dmabuf->owner); kfree(dmabuf->name); kfree(dmabuf);
Re: [PATCH v2 08/14] vfio/pci: Move to the device set infrastructure
On Fri, Jul 23, 2021 at 09:47:49AM +0200, Christoph Hellwig wrote: > > @@ -2020,12 +2004,17 @@ static int vfio_pci_probe(struct pci_dev *pdev, > > const struct pci_device_id *id) > > INIT_LIST_HEAD(&vdev->vma_list); > > init_rwsem(&vdev->memory_lock); > > > > - ret = vfio_pci_reflck_attach(vdev); > > + if (pci_is_root_bus(pdev->bus)) > > + ret = vfio_assign_device_set(&vdev->vdev, vdev); > > + else if (!pci_probe_reset_slot(pdev->slot)) > > + ret = vfio_assign_device_set(&vdev->vdev, pdev->slot); > > + else > > + ret = vfio_assign_device_set(&vdev->vdev, pdev->bus); > > Maybe invert this and add a comment: > > if (pci_is_root_bus(pdev->bus)) > ret = vfio_assign_device_set(&vdev->vdev, vdev); > /* >* If there is no slot reset support for this device, the whole >* bus needs to be grouped together to support bus-wide resets. >*/ I like the comment > else if (pci_probe_reset_slot(pdev->slot) < 0) > ret = vfio_assign_device_set(&vdev->vdev, pdev->bus); > else > ret = vfio_assign_device_set(&vdev->vdev, pdev->slot); The consensus idiom here is the !: drivers/pci/pci.c: return (!pci_probe_reset_slot(pdev->slot)) ? drivers/vfio/pci/vfio_pci.c:if (!pci_probe_reset_slot(vdev->pdev->slot)) drivers/vfio/pci/vfio_pci.c:if (!pci_probe_reset_slot(vdev->pdev->slot)) drivers/vfio/pci/vfio_pci.c:bool slot = !pci_probe_reset_slot(vdev->pdev->slot); drivers/vfio/pci/vfio_pci.c:if (!pci_probe_reset_slot(vdev->pdev->slot)) It reads quite poorly either way, IMHO, I'd rather switch it to a readable bool, but not for this series Thanks, Jason
Re: [PATCH 06/14] drm/i915/guc/slpc: Enable SLPC and add related H2G events
Hi Vinay,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-tip/drm-tip]
[cannot apply to drm-intel/for-linux-next drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next drm/drm-next v5.14-rc2 next-20210723]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Vinay-Belgaumkar/drm-i915-guc-Enable-GuC-based-power-management-features/20210722-001528
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: x86_64-rhel-8.3-kselftests (attached as .config)
compiler: gcc-10 (Ubuntu 10.3.0-1ubuntu1~20.04) 10.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.3-341-g8af24329-dirty
#
https://github.com/0day-ci/linux/commit/14352081e4f18759e70413f3be4151d623c97b8c
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Vinay-Belgaumkar/drm-i915-guc-Enable-GuC-based-power-management-features/20210722-001528
git checkout 14352081e4f18759e70413f3be4151d623c97b8c
# save the attached .config to linux build tree
make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir
ARCH=x86_64 SHELL=/bin/bash drivers/gpu/drm/i915/
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
>> drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c:217:5: sparse: sparse: symbol
>> 'slpc_decode_min_freq' was not declared. Should it be static?
>> drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c:229:5: sparse: sparse: symbol
>> 'slpc_decode_max_freq' was not declared. Should it be static?
vim +/slpc_decode_min_freq +217 drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
216
> 217 u32 slpc_decode_min_freq(struct intel_guc_slpc *slpc)
218 {
219 struct slpc_shared_data *data = slpc->vaddr;
220
221 GEM_BUG_ON(!slpc->vma);
222
223 return DIV_ROUND_CLOSEST(
224 REG_FIELD_GET(SLPC_MIN_UNSLICE_FREQ_MASK,
225 data->task_state_data.freq) *
226 GT_FREQUENCY_MULTIPLIER, GEN9_FREQ_SCALER);
227 }
228
> 229 u32 slpc_decode_max_freq(struct intel_guc_slpc *slpc)
230 {
231 struct slpc_shared_data *data = slpc->vaddr;
232
233 GEM_BUG_ON(!slpc->vma);
234
235 return DIV_ROUND_CLOSEST(
236 REG_FIELD_GET(SLPC_MAX_UNSLICE_FREQ_MASK,
237 data->task_state_data.freq) *
238 GT_FREQUENCY_MULTIPLIER, GEN9_FREQ_SCALER);
239 }
240
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH v2 06/14] vfio/fsl: Move to the device set infrastructure
On Fri, Jul 23, 2021 at 02:29:03PM +0200, Christoph Hellwig wrote: > On Fri, Jul 23, 2021 at 09:22:27AM -0300, Jason Gunthorpe wrote: > > > But do we even need the else part? Assingning &mc_dev->dev is > > > equivalent to the default per-device set anyway, isn't it? > > > > Not quite, the default is this: > > > > if (!device->dev_set) > > vfio_assign_device_set(device, device); > > > > Where 'device' is the vfio_device itself, the above is connecting to > > the struct fsl_mc_device. > > Isn't there a 1:1 relation? Yes, but one is a struct device * and the other is a struct vfio_device *. They don't have the same pointer value. The above default code has the goal of creating a singleton dev_set because no other driver can reasonably obtain the 'struct vfio_device *'. FSL is using a 'struct device *' as the key and the interesting case is when two drivers are loaded such that: mc_dev->dev.parent == &mc_dev->dev Then they will have the same dev_set and the locking works out. The vfio_device * can never be == &mc_dev->dev because it is a different allocation. Jason
Re: [PATCH v2 09/14] vfio/pci: Change vfio_pci_try_bus_reset() to use the dev_set
On Fri, Jul 23, 2021 at 10:05:43AM +0200, Christoph Hellwig wrote:
> On Tue, Jul 20, 2021 at 02:42:55PM -0300, Jason Gunthorpe wrote:
> > Keep track of all the vfio_devices that have been added to the device set
> > and use this list in vfio_pci_try_bus_reset() instead of trying to work
> > backwards from the pci_device.
> >
> > The dev_set->lock directly prevents devices from joining/leaving the set,
> > which further implies the pci_device cannot change drivers or that the
> > vfio_device be freed, eliminating the need for get/put's.
> >
> > Completeness of the device set can be directly measured by checking if
> > every PCI device in the reset group is also in the device set - which
> > proves that VFIO drivers are attached to everything.
> >
> > This restructuring corrects a call to pci_dev_driver() without holding the
> > device_lock() and removes a hard wiring to &vfio_pci_driver.
> >
> > Signed-off-by: Jason Gunthorpe
>
> I think the addition of the list to the dev_set should be a different
> patch. Or maybe even go into the one adding the dev_set concept.
OK
> > +static int vfio_pci_check_all_devices_bound(struct pci_dev *pdev, void
> > *data)
> > {
> > + struct vfio_device_set *dev_set = data;
> > + struct vfio_device *cur;
> >
> > + lockdep_assert_held(&dev_set->lock);
> >
> > + list_for_each_entry(cur, &dev_set->device_list, dev_set_list)
> > + if (cur->dev == &pdev->dev)
> > + return 0;
> > + return -EBUSY;
>
> I don't understand this logic. If there is any device in the set that
> does now have the same struct device we're in trouble? Please clearly
> document what this is trying to do. If the bound in the name makes sense
> you probably want to check the driver instead.
The PCI reset this code is tring to do effects a set of PCI devices,
due to how the HW works.
Along with the vfio_pci_for_each_slot_or_bus() this is computing a set
wise 'is superset' between the list of pci_dev's the reset will affect
(the reset group) and the list of vfio_devices that we have locking
control over to sequence the reset (the dev_set).
If every PCI device we will reset is under the dev_set then we
directly know it is safe to trigger the reset. If any PCI device is
not in this dev_set then we cannot use the reset as we can't know what
will happen to the device that we don't control.
Let's use a different word than bound? vfio_pci_check_device_in_set()?
> > static void vfio_pci_try_bus_reset(struct vfio_pci_device *vdev)
> > {
> > + /* All VFIO devices have a closed FD */
> > + list_for_each_entry(cur, &dev_set->device_list, vdev.dev_set_list)
> > + if (cur->vdev.open_count)
> > + return;
> > +
> > + /* All devices in the group to be reset need VFIO devices */
> > + if (vfio_pci_for_each_slot_or_bus(
> > + vdev->pdev, vfio_pci_check_all_devices_bound, dev_set,
> > + !pci_probe_reset_slot(vdev->pdev->slot)))
> > + return;
> >
> > /* Does at least one need a reset? */
>
> These checks look a little strange, and the comments don't make much
> sense. What about an incremental patch like this?
Sure, it can go in a function
> diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
> index fbc20f6d2dd412..d8375a5e77e07c 100644
> +++ b/drivers/vfio/pci/vfio_pci.c
> @@ -2188,10 +2188,34 @@ static int vfio_pci_try_zap_and_vma_lock_cb(struct
> pci_dev *pdev, void *data)
> return 0;
> }
>
> +static struct pci_dev *vfio_pci_reset_target(struct vfio_pci_device *vdev)
> +{
> + struct vfio_device_set *dev_set = vdev->vdev.dev_set;
> + struct vfio_pci_device *cur;
> +
> + /* none of the device is allowed to be currently open: */
> + list_for_each_entry(cur, &dev_set->device_list, vdev.dev_set_list)
> + if (cur->vdev.open_count)
> + return NULL;
> +
> + /* all devices in the group to be reset need to be VFIO devices: */
It is not "need to be VFIO devices" it is "need to be in our
dev_set". Have the PCI dev bound to, say, a mdev VFIO device isn't
good enough.
Thanks,
Jason
Re: [PATCH v2 10/14] vfio/pci: Reorganize VFIO_DEVICE_PCI_HOT_RESET to use the device set
On Fri, Jul 23, 2021 at 10:12:08AM +0200, Christoph Hellwig wrote: > On Tue, Jul 20, 2021 at 02:42:56PM -0300, Jason Gunthorpe wrote: > > Like vfio_pci_try_bus_reset() this code wants to reset all of the devices > > in the "reset group" which is the same membership as the device set. > > > > Instead of trying to reconstruct the device set from the PCI list go > > directly from the device set's device list to execute the reset. > > > > The same basic structure as vfio_pci_try_bus_reset() is used. The > > 'vfio_devices' struct is replaced with the device set linked list and we > > simply sweep it multiple times under the lock. > > > > This eliminates a memory allocation and get/put traffic and another > > improperly locked test of pci_dev_driver(). > > Looks fine. But oh gad is that locking scheme awful.. I hope that the address space patches Alex has been working on will help this. And as I wrote it I was wondering if we can swap the dev_set lock for all these other locks and just delete the whole thing.. Thanks, Jason
Re: [Intel-gfx] [RFC 0/8] Per client GPU stats
On 23/07/2021 12:23, Christian König wrote: Am 23.07.21 um 13:21 schrieb Tvrtko Ursulin: On 15/07/2021 10:18, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Same old work but now rebased and series ending with some DRM docs proposing the common specification which should enable nice common userspace tools to be written. For the moment I only have intel_gpu_top converted to use this and that seems to work okay. v2: * Added prototype of possible amdgpu changes and spec updates to align with the common spec. Not much interest for the common specification? Well I would rather say not much opposition :) Hah, thanks, that's good to hear! Of hand everything you do in this patch set sounds absolutely sane to me, just don't have any time to review it in detail. That's fine - could you maybe suggest who on the AMD side could have a look at the relevant patches? Regards, Tvrtko For reference I've just posted the intel-gpu-top adaptation required to parse it here: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.freedesktop.org%2Fpatch%2F446041%2F%3Fseries%3D90464%26rev%3D2&data=04%7C01%7Cchristian.koenig%40amd.com%7Cc967de8b8c2b499eb25b08d94dcbff2e%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637626360837958764%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=07hzP1RuVQkFi8AXWK8i%2Ffu9ajnldcF36PLRrey5wXA%3D&reserved=0. Note that this is not attempting to be a vendor agnostic tool but is adding per client data to existing i915 tool which uses PMU counters for global stats. intel-gpu-top: Intel Skylake (Gen9) @ /dev/dri/card0 - 335/ 339 MHz; 10% RC6; 1.24/ 4.18 W; 527 irqs/s IMC reads: 3297 MiB/s IMC writes: 2767 MiB/s ENGINES BUSY MI_SEMA MI_WAIT Render/3D 78.74% |██▏ | 0% 0% Blitter 0.00% | | 0% 0% Video 0.00% | | 0% 0% VideoEnhance 0.00% | | 0% 0% PID NAME Render/3D Blitter Video VideoEnhance 10202 neverball |███▎ || || || | 5665 Xorg |███▍ || || || | 5679 xfce4-session | || || || | 5772 ibus-ui-gtk3 | || || || | 5775 ibus-extension- | || || || | 5777 ibus-x11 | || || || | 5823 xfwm4 | || || || | Regards, Tvrtko Tvrtko Ursulin (8): drm/i915: Explicitly track DRM clients drm/i915: Make GEM contexts track DRM clients drm/i915: Track runtime spent in closed and unreachable GEM contexts drm/i915: Track all user contexts per client drm/i915: Track context current active time drm: Document fdinfo format specification drm/i915: Expose client engine utilisation via fdinfo drm/amdgpu: Convert to common fdinfo format Documentation/gpu/amdgpu.rst | 26 Documentation/gpu/drm-usage-stats.rst | 108 + Documentation/gpu/i915.rst | 27 Documentation/gpu/index.rst | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c | 18 ++- drivers/gpu/drm/i915/Makefile | 5 +- drivers/gpu/drm/i915/gem/i915_gem_context.c | 42 - .../gpu/drm/i915/gem/i915_gem_context_types.h | 6 + drivers/gpu/drm/i915/gt/intel_context.c | 27 +++- drivers/gpu/drm/i915/gt/intel_context.h | 15 +- drivers/gpu/drm/i915/gt/intel_context_types.h | 24 ++- .../drm/i915/gt/intel_execlists_submission.c | 23 ++- .../gpu/drm/i915/gt/intel_gt_clock_utils.c | 4 + drivers/gpu/drm/i915/gt/intel_lrc.c | 27 ++-- drivers/gpu/drm/i915/gt/intel_lrc.h | 24 +++ drivers/gpu/drm/i915/gt/selftest_lrc.c | 10 +- drivers/gpu/drm/i915/i915_drm_client.c | 143 ++ drivers/gpu/drm/i915/i915_drm_client.h | 66 drivers/gpu/drm/i915/i915_drv.c | 9 ++ drivers/gpu/drm/i915/i915_drv.h | 5 + drivers/gpu/drm/i915/i915_gem.c | 21 ++- drivers/gpu/drm/i915/i915_gpu_error.c | 9 +- drivers/gpu/drm/i915/i915_gpu_error.h | 2 +- 23 files changed, 581 insertions(+), 61 deletions(-) create mode 100644 Documentation/gpu/drm-usage-stats.rst create mode 100644 drivers/gpu/drm/i915/i915_drm_client.c create mode 100644 drivers/gpu/drm/i915/i915_drm_client.h
Re: [Intel-gfx] [RFC 0/8] Per client GPU stats
On Fri, Jul 23, 2021 at 9:51 AM Tvrtko Ursulin wrote: > > > On 23/07/2021 12:23, Christian König wrote: > > Am 23.07.21 um 13:21 schrieb Tvrtko Ursulin: > >> > >> On 15/07/2021 10:18, Tvrtko Ursulin wrote: > >>> From: Tvrtko Ursulin > >>> > >>> Same old work but now rebased and series ending with some DRM docs > >>> proposing > >>> the common specification which should enable nice common userspace > >>> tools to be > >>> written. > >>> > >>> For the moment I only have intel_gpu_top converted to use this and > >>> that seems to > >>> work okay. > >>> > >>> v2: > >>> * Added prototype of possible amdgpu changes and spec updates to > >>> align with the > >>> common spec. > >> > >> Not much interest for the common specification? > > > > Well I would rather say not much opposition :) > > Hah, thanks, that's good to hear! > > > Of hand everything you do in this patch set sounds absolutely sane to > > me, just don't have any time to review it in detail. > > That's fine - could you maybe suggest who on the AMD side could have a > look at the relevant patches? Adding David and Roy who did the implementation for the AMD side. Can you take a look at these patches when you get a chance? Thanks, Alex > > Regards, > > Tvrtko > > >> For reference I've just posted the intel-gpu-top adaptation required > >> to parse it here: > >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.freedesktop.org%2Fpatch%2F446041%2F%3Fseries%3D90464%26rev%3D2&data=04%7C01%7Cchristian.koenig%40amd.com%7Cc967de8b8c2b499eb25b08d94dcbff2e%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637626360837958764%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=07hzP1RuVQkFi8AXWK8i%2Ffu9ajnldcF36PLRrey5wXA%3D&reserved=0. > >> > >> > >> Note that this is not attempting to be a vendor agnostic tool but is > >> adding per client data to existing i915 tool which uses PMU counters > >> for global stats. > >> > >> intel-gpu-top: Intel Skylake (Gen9) @ /dev/dri/card0 - 335/ 339 MHz; > >> 10% RC6; 1.24/ 4.18 W; 527 irqs/s > >> > >> IMC reads: 3297 MiB/s > >> IMC writes: 2767 MiB/s > >> > >> ENGINES BUSY MI_SEMA MI_WAIT > >>Render/3D 78.74% > >> |██▏ > >> | 0% 0% > >> Blitter0.00% | | 0% 0% > >>Video0.00% | | 0% 0% > >> VideoEnhance0.00% | | 0% 0% > >> > >>PID NAME Render/3D > >> Blitter VideoVideoEnhance > >> 10202 neverball |███▎ || || > >> || | > >> 5665 Xorg |███▍ || || > >> || | > >> 5679 xfce4-session | || || > >> || | > >> 5772 ibus-ui-gtk3 | || || > >> || | > >> 5775 ibus-extension- | || || > >> || | > >> 5777 ibus-x11 | || || > >> || | > >> 5823 xfwm4 | || || > >> || | > >> > >> > >> Regards, > >> > >> Tvrtko > >> > >>> Tvrtko Ursulin (8): > >>>drm/i915: Explicitly track DRM clients > >>>drm/i915: Make GEM contexts track DRM clients > >>>drm/i915: Track runtime spent in closed and unreachable GEM contexts > >>>drm/i915: Track all user contexts per client > >>>drm/i915: Track context current active time > >>>drm: Document fdinfo format specification > >>>drm/i915: Expose client engine utilisation via fdinfo > >>>drm/amdgpu: Convert to common fdinfo format > >>> > >>> Documentation/gpu/amdgpu.rst | 26 > >>> Documentation/gpu/drm-usage-stats.rst | 108 + > >>> Documentation/gpu/i915.rst| 27 > >>> Documentation/gpu/index.rst | 1 + > >>> drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c| 18 ++- > >>> drivers/gpu/drm/i915/Makefile | 5 +- > >>> drivers/gpu/drm/i915/gem/i915_gem_context.c | 42 - > >>> .../gpu/drm/i915/gem/i915_gem_context_types.h | 6 + > >>> drivers/gpu/drm/i915/gt/intel_context.c | 27 +++- > >>> drivers/gpu/drm/i915/gt/intel_context.h | 15 +- > >>> drivers/gpu/drm/i915/gt/intel_context_types.h | 24 ++- > >>> .../drm/i915/gt/intel_execlists_submission.c | 23 ++- > >>> .../gpu/drm/i915/gt/intel_gt_clock_utils.c| 4 + > >>> drivers/gpu/drm/i915/gt/intel_lrc.c | 27 ++-- > >>> drivers/gpu/drm/i915/gt/intel_lrc.h | 24 +++ > >>> drivers/gpu/drm/i915/gt/selftest_lrc.c| 10 +- > >>> drivers/gpu/drm/i915/i915_drm_client.c| 143 ++ > >>> drivers/gpu/drm/i915/
Re: [RFC 8/8] drm/amdgpu: Convert to common fdinfo format
+ David, Roy
On Thu, Jul 15, 2021 at 5:18 AM Tvrtko Ursulin
wrote:
>
> From: Tvrtko Ursulin
>
> Convert fdinfo format to one documented in drm-usage-stats.rst.
>
> Opens:
> * Does it work for AMD?
> * What are the semantics of AMD engine utilisation reported in percents?
>Can it align with what i915 does or needs to document the alternative
>in the specification document?
>
> Signed-off-by: Tvrtko Ursulin
> Cc: David M Nieto
> Cc: Christian König
> Cc: Daniel Vetter
> ---
> Documentation/gpu/amdgpu.rst | 26 ++
> Documentation/gpu/drm-usage-stats.rst | 7 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c | 18 ++-
> 3 files changed, 45 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/gpu/amdgpu.rst b/Documentation/gpu/amdgpu.rst
> index 364680cdad2e..b9b79c810f28 100644
> --- a/Documentation/gpu/amdgpu.rst
> +++ b/Documentation/gpu/amdgpu.rst
> @@ -322,3 +322,29 @@ smartshift_bias
>
> .. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c
> :doc: smartshift_bias
> +
> +.. _amdgpu-usage-stats:
> +
> +amdgpu DRM client usage stats implementation
> +
> +
> +The amdgpu driver implements the DRM client usage stats specification as
> +documented in :ref:`drm-client-usage-stats`.
> +
> +Example of the output showing the implemented key value pairs and entirety of
> +the currenly possible format options:
> +
> +::
> +
> + pos:0
> + flags: 012
> + mnt_id: 21
> + drm-driver: amdgpu
> + drm-pdev: :00:02.0
> + drm-client-id: 7
> + drm-engine-... TODO
> + drm-memory-... TODO
> +
> +Possible `drm-engine-` key names are: ``,... TODO.
> +
> +Possible `drm-memory-` key names are: ``,... TODO.
> diff --git a/Documentation/gpu/drm-usage-stats.rst
> b/Documentation/gpu/drm-usage-stats.rst
> index b87505438aaa..eaaa361805c0 100644
> --- a/Documentation/gpu/drm-usage-stats.rst
> +++ b/Documentation/gpu/drm-usage-stats.rst
> @@ -69,7 +69,7 @@ scope of each device, in which case `drm-pdev` shall be
> present as well.
> Userspace should make sure to not double account any usage statistics by
> using
> the above described criteria in order to associate data to individual
> clients.
>
> -- drm-engine-: ns
> +- drm-engine-: [ns|%]
>
> GPUs usually contain multiple execution engines. Each shall be given a stable
> and unique name (str), with possible values documented in the driver specific
> @@ -84,6 +84,9 @@ larger value within a reasonable period. Upon observing a
> value lower than what
> was previously read, userspace is expected to stay with that larger previous
> value until a monotonic update is seen.
>
> +Where time unit is given as a percentage...[AMD folks to fill the semantics
> +and interpretation of that]...
> +
> - drm-memory-: [KiB|MiB]
>
> Each possible memory type which can be used to store buffer objects by the
> @@ -101,3 +104,5 @@ Driver specific implementations
> ===
>
> :ref:`i915-usage-stats`
> +
> +:ref:`amdgpu-usage-stats`
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
> index d94c5419ec25..d6b011008fe9 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
> @@ -76,11 +76,19 @@ void amdgpu_show_fdinfo(struct seq_file *m, struct file
> *f)
> }
> amdgpu_vm_get_memory(&fpriv->vm, &vram_mem, >t_mem, &cpu_mem);
> amdgpu_bo_unreserve(fpriv->vm.root.bo);
> - seq_printf(m, "pdev:\t%04x:%02x:%02x.%d\npasid:\t%u\n", domain, bus,
> +
> + /*
> +* **
> +* For text output format description please see drm-usage-stats.rst!
> +* **
> +*/
> +
> + seq_puts(m, "drm-driver: amdgpu\n");
> + seq_printf(m, "drm-pdev:\t%04x:%02x:%02x.%d\npasid:\t%u\n", domain,
> bus,
> dev, fn, fpriv->vm.pasid);
> - seq_printf(m, "vram mem:\t%llu kB\n", vram_mem/1024UL);
> - seq_printf(m, "gtt mem:\t%llu kB\n", gtt_mem/1024UL);
> - seq_printf(m, "cpu mem:\t%llu kB\n", cpu_mem/1024UL);
> + seq_printf(m, "drm-memory-vram:\t%llu KiB\n", vram_mem/1024UL);
> + seq_printf(m, "drm-memory-gtt:\t%llu KiB\n", gtt_mem/1024UL);
> + seq_printf(m, "drm-memory-cpu:\t%llu KiB\n", cpu_mem/1024UL);
> for (i = 0; i < AMDGPU_HW_IP_NUM; i++) {
> uint32_t count = amdgpu_ctx_num_entities[i];
> int idx = 0;
> @@ -96,7 +104,7 @@ void amdgpu_show_fdinfo(struct seq_file *m, struct file *f)
> perc = div64_u64(1 * total, min);
> frac = perc % 100;
>
> - seq_printf(m, "%s%d:\t%d.%d%%\n",
> + seq_printf(m, "drm-engine-%s%d:\t%d.%d %%\n",
>
Re: [PATCH 1/3] drm/amdgpu: create amdgpu_vkms (v2)
On Wed, Jul 21, 2021 at 1:07 PM Ryan Taylor wrote:
>
> Modify the VKMS driver into an api that dce_virtual can use to create
> virtual displays that obey drm's atomic modesetting api.
>
> v2: Made local functions static.
>
> Reported-by: kernel test robot
> Signed-off-by: Ryan Taylor
> ---
> drivers/gpu/drm/amd/amdgpu/Makefile | 1 +
> drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 +
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c | 411 +++
> drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.h | 29 ++
> drivers/gpu/drm/amd/amdgpu/dce_virtual.c | 23 +-
> 7 files changed, 458 insertions(+), 11 deletions(-)
> create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
> create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.h
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile
> b/drivers/gpu/drm/amd/amdgpu/Makefile
> index f089794bbdd5..30cbcd5ce1cc 100644
> --- a/drivers/gpu/drm/amd/amdgpu/Makefile
> +++ b/drivers/gpu/drm/amd/amdgpu/Makefile
> @@ -120,6 +120,7 @@ amdgpu-y += \
> amdgpu-y += \
> dce_v10_0.o \
> dce_v11_0.o \
> + amdgpu_vkms.o \
> dce_virtual.o
>
> # add GFX block
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index 54cf647bd018..d0a2f2ed433d 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -919,6 +919,7 @@ struct amdgpu_device {
>
> /* display */
> boolenable_virtual_display;
> + struct amdgpu_vkms_output *amdgpu_vkms_output;
> struct amdgpu_mode_info mode_info;
> /* For pre-DCE11. DCE11 and later are in "struct amdgpu_device->dm" */
> struct work_struct hotplug_work;
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index d0c935cf4f0f..1b016e5bc75f 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -1230,7 +1230,7 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
> int ret, retry = 0;
> bool supports_atomic = false;
>
> - if (!amdgpu_virtual_display &&
> + if (amdgpu_virtual_display ||
> amdgpu_device_asic_has_dc_support(flags & AMD_ASIC_MASK))
> supports_atomic = true;
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
> index 09b048647523..5a143ca02cf9 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
> @@ -344,7 +344,7 @@ int amdgpu_fbdev_init(struct amdgpu_device *adev)
> }
>
> /* disable all the possible outputs/crtcs before entering KMS mode */
> - if (!amdgpu_device_has_dc_support(adev))
> + if (!amdgpu_device_has_dc_support(adev) && !amdgpu_virtual_display)
> drm_helper_disable_unused_functions(adev_to_drm(adev));
>
> drm_fb_helper_initial_config(&rfbdev->helper, bpp_sel);
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
> new file mode 100644
> index ..d5c1f1c58f5f
> --- /dev/null
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
> @@ -0,0 +1,411 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +
> +#include
> +#include
> +#include
> +
> +#include "amdgpu.h"
> +#include "amdgpu_vkms.h"
> +#include "amdgpu_display.h"
> +
> +/**
> + * DOC: amdgpu_vkms
> + *
> + * The amdgpu vkms interface provides a virtual KMS interface for several use
> + * cases: devices without display hardware, platforms where the actual
> display
> + * hardware is not useful (e.g., servers), SR-IOV virtual functions, device
> + * emulation/simulation, and device bring up prior to display hardware being
> + * usable. We previously emulated a legacy KMS interface, but there was a
> desire
> + * to move to the atomic KMS interface. The vkms driver did everything we
> + * needed, but we wanted KMS support natively in the driver without buffer
> + * sharing and the ability to support an instance of VKMS per device. We
> first
> + * looked at splitting vkms into a stub driver and a helper module that other
> + * drivers could use to implement a virtual display, but this strategy ended
> up
> + * being messy due to driver specific callbacks needed for buffer management.
> + * Ultimately, it proved easier to import the vkms code as it mostly used
> core
> + * drm helpers anyway.
> + */
> +
> +static const u32 amdgpu_vkms_formats[] = {
> + DRM_FORMAT_XRGB,
> +};
> +
> +static enum hrtimer_restart amdgpu_vkms_vblank_simulate(struct hrtimer
> *timer)
> +{
> + struct amdgpu_vkms_output *output = container_of(timer,
> +struct
> amdgpu_vkms_output,
> +vblank_
Re: [PATCH 3/3] drm/amdgpu: replace dce_virtual with amdgpu_vkms (v3)
On Wed, Jul 21, 2021 at 1:07 PM Ryan Taylor wrote:
>
> Move dce_virtual into amdgpu_vkms and update all references to
> dce_virtual with amdgpu_vkms.
>
> v2: Removed more references to dce_virtual.
>
> v3: Restored display modes from previous implementation.
>
> Reported-by: kernel test robot
> Suggested-by: Alex Deucher
> Signed-off-by: Ryan Taylor
> ---
> drivers/gpu/drm/amd/amdgpu/Makefile | 3 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c | 234 ++-
> drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.h | 5 +-
> drivers/gpu/drm/amd/amdgpu/cik.c | 10 +-
> drivers/gpu/drm/amd/amdgpu/dce_virtual.c | 223 -
> drivers/gpu/drm/amd/amdgpu/dce_virtual.h | 30 ---
> drivers/gpu/drm/amd/amdgpu/nv.c | 20 +-
> drivers/gpu/drm/amd/amdgpu/si.c | 8 +-
> drivers/gpu/drm/amd/amdgpu/soc15.c | 10 +-
> drivers/gpu/drm/amd/amdgpu/vi.c | 14 +-
> 10 files changed, 264 insertions(+), 293 deletions(-)
> delete mode 100644 drivers/gpu/drm/amd/amdgpu/dce_virtual.c
> delete mode 100644 drivers/gpu/drm/amd/amdgpu/dce_virtual.h
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile
> b/drivers/gpu/drm/amd/amdgpu/Makefile
> index 30cbcd5ce1cc..0d814c957461 100644
> --- a/drivers/gpu/drm/amd/amdgpu/Makefile
> +++ b/drivers/gpu/drm/amd/amdgpu/Makefile
> @@ -120,8 +120,7 @@ amdgpu-y += \
> amdgpu-y += \
> dce_v10_0.o \
> dce_v11_0.o \
> - amdgpu_vkms.o \
> - dce_virtual.o
> + amdgpu_vkms.o
>
> # add GFX block
> amdgpu-y += \
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
> index d5c1f1c58f5f..538d41ea 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
> @@ -5,6 +5,15 @@
> #include
>
> #include "amdgpu.h"
> +#ifdef CONFIG_DRM_AMDGPU_SI
> +#include "dce_v6_0.h"
> +#endif
> +#ifdef CONFIG_DRM_AMDGPU_CIK
> +#include "dce_v8_0.h"
> +#endif
> +#include "dce_v10_0.h"
> +#include "dce_v11_0.h"
> +#include "ivsrcid/ivsrcid_vislands30.h"
> #include "amdgpu_vkms.h"
> #include "amdgpu_display.h"
>
> @@ -180,12 +189,45 @@ static const struct drm_connector_funcs
> amdgpu_vkms_connector_funcs = {
>
> static int amdgpu_vkms_conn_get_modes(struct drm_connector *connector)
> {
> - int count;
> + struct drm_device *dev = connector->dev;
> + struct drm_display_mode *mode = NULL;
> + unsigned i;
> + static const struct mode_size {
> + int w;
> + int h;
> + } common_modes[] = {
> + { 640, 480},
> + { 720, 480},
> + { 800, 600},
> + { 848, 480},
> + {1024, 768},
> + {1152, 768},
> + {1280, 720},
> + {1280, 800},
> + {1280, 854},
> + {1280, 960},
> + {1280, 1024},
> + {1440, 900},
> + {1400, 1050},
> + {1680, 1050},
> + {1600, 1200},
> + {1920, 1080},
> + {1920, 1200},
> + {2560, 1440},
> + {4096, 3112},
> + {3656, 2664},
> + {3840, 2160},
> + {4096, 2160},
> + };
> +
> + for (i = 0; i < ARRAY_SIZE(common_modes); i++) {
> + mode = drm_cvt_mode(dev, common_modes[i].w,
> common_modes[i].h, 60, false, false, false);
> + drm_mode_probed_add(connector, mode);
> + }
>
> - count = drm_add_modes_noedid(connector, XRES_MAX, YRES_MAX);
> drm_set_preferred_mode(connector, XRES_DEF, YRES_DEF);
>
> - return count;
> + return ARRAY_SIZE(common_modes);
> }
>
> static const struct drm_connector_helper_funcs amdgpu_vkms_conn_helper_funcs
> = {
> @@ -409,3 +451,189 @@ int amdgpu_vkms_output_init(struct drm_device *dev,
>
> return ret;
> }
> +
> +const struct drm_mode_config_funcs amdgpu_vkms_mode_funcs = {
> + .fb_create = amdgpu_display_user_framebuffer_create,
> + .atomic_check = drm_atomic_helper_check,
> + .atomic_commit = drm_atomic_helper_commit,
> +};
> +
> +static int amdgpu_vkms_sw_init(void *handle)
> +{
> + int r, i;
> + struct amdgpu_device *adev = (struct amdgpu_device *)handle;
> +
> + adev_to_drm(adev)->max_vblank_count = 0;
> +
> + adev_to_drm(adev)->mode_config.funcs = &amdgpu_vkms_mode_funcs;
> +
> + adev_to_drm(adev)->mode_config.max_width = XRES_MAX;
> + adev_to_drm(adev)->mode_config.max_height = YRES_MAX;
> +
> + adev_to_drm(adev)->mode_config.preferred_depth = 24;
> + adev_to_drm(adev)->mode_config.prefer_shadow = 1;
> +
> + adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base;
> +
> + r = amdgpu_display_modeset_create_props(adev);
> + if (r)
> + return r;
> +
> + adev->amdgpu_vkms_output = kzalloc(sizeof(struct amdgpu_vkms_output)
>
Re: [PATCH v2 04/14] vfio: Provide better generic support for open/release vfio_device_ops
On Fri, Jul 23, 2021 at 09:39:14AM +0200, Christoph Hellwig wrote:
> This looks unessecarily complicated. We can just try to load first
> and then store it under the same lock, e.g.:
Yes indeed, I went with this:
int vfio_assign_device_set(struct vfio_device *device, void *set_id)
{
unsigned long idx = (unsigned long)set_id;
struct vfio_device_set *new_dev_set;
struct vfio_device_set *dev_set;
if (WARN_ON(!set_id))
return -EINVAL;
/*
* Atomically acquire a singleton object in the xarray for this set_id
*/
xa_lock(&vfio_device_set_xa);
dev_set = xa_load(&vfio_device_set_xa, idx);
if (dev_set)
goto found_get_ref;
xa_unlock(&vfio_device_set_xa);
new_dev_set = kzalloc(sizeof(*new_dev_set), GFP_KERNEL);
if (!new_dev_set)
return -ENOMEM;
mutex_init(&new_dev_set->lock);
new_dev_set->set_id = set_id;
xa_lock(&vfio_device_set_xa);
dev_set = __xa_cmpxchg(&vfio_device_set_xa, idx, NULL, new_dev_set,
GFP_KERNEL);
if (!dev_set) {
dev_set = new_dev_set;
goto found_get_ref;
}
kfree(new_dev_set);
if (xa_is_err(dev_set)) {
xa_unlock(&vfio_device_set_xa);
return xa_err(dev_set);
}
found_get_ref:
dev_set->device_count++;
xa_unlock(&vfio_device_set_xa);
device->dev_set = dev_set;
return 0;
}
I'm also half inclined to delete the xa_load() since I think the
common case here is to need the allocate...
> xa_lock(&vfio_device_set_xa);
> set = xa_load(&vfio_device_set_xa, idx);
> if (set) {
> kfree(new);
> goto found;
> }
> err = xa_err(__xa_store(&vfio_device_set_xa, idx, new, GFP_KERNEL));
AIUI this is subtly racy:
CPU1 CPU2
xa_lock()
xa_load() == NULL
xa_store()
__xas_nomem()
xa_unlock()
xa_lock()
xa_load() == NULL
xa_store()
__xas_nomem()
xa_unlock()
kmem_cache_alloc()
kmem_cache_alloc()
xa_lock()
[idx] = new1
xa_unlock()
xa_lock()
[idx] = new2// Woops, lost new1!
xa_unlock()
The hidden xa unlock is really tricky.
The __xa_cmpxchg is safe against this.
Jason
Re: [PATCH] dma-buf: WARN on dmabuf release with pending attachments
On Fri, Jul 23, 2021 at 02:34:13PM +0200, Christian König wrote: > Am 23.07.21 um 14:31 schrieb Charan Teja Reddy: > > It is expected from the clients to follow the below steps on an imported > > dmabuf fd: > > a) dmabuf = dma_buf_get(fd) // Get the dmabuf from fd > > b) dma_buf_attach(dmabuf); // Clients attach to the dmabuf > > o Here the kernel does some slab allocations, say for > > dma_buf_attachment and may be some other slab allocation in the > > dmabuf->ops->attach(). > > c) Client may need to do dma_buf_map_attachment(). > > d) Accordingly dma_buf_unmap_attachment() should be called. > > e) dma_buf_detach () // Clients detach to the dmabuf. > > o Here the slab allocations made in b) are freed. > > f) dma_buf_put(dmabuf) // Can free the dmabuf if it is the last > > reference. > > > > Now say an erroneous client failed at step c) above thus it directly > > called dma_buf_put(), step f) above. Considering that it may be the last > > reference to the dmabuf, buffer will be freed with pending attachments > > left to the dmabuf which can show up as the 'memory leak'. This should > > at least be reported as the WARN(). > > > > Signed-off-by: Charan Teja Reddy > > Good idea. I would expect a crash immediately, but from such a backtrace it > is quite hard to tell what the problem is. > > Patch is Reviewed-by: Christian König and I'm > going to push this to drm-misc-next on Monday if nobody objects. The boom only happens a lot later when the offending import uses the attachment again. This here has a good chance to catch that early drm_buf_put(), so I think it's a good improvement. We'll still Oops later on ofc, but meh. Acked-by: Daniel Vetter > > Thanks, > Christian. > > > --- > > drivers/dma-buf/dma-buf.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > > index 511fe0d..733c8b1 100644 > > --- a/drivers/dma-buf/dma-buf.c > > +++ b/drivers/dma-buf/dma-buf.c > > @@ -79,6 +79,7 @@ static void dma_buf_release(struct dentry *dentry) > > if (dmabuf->resv == (struct dma_resv *)&dmabuf[1]) > > dma_resv_fini(dmabuf->resv); > > + WARN_ON(!list_empty(&dmabuf->attachments)); > > module_put(dmabuf->owner); > > kfree(dmabuf->name); > > kfree(dmabuf); > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH] drm/nouveau/kms/nv50-: fix build failure with CONFIG_BACKLIGHT=n
On 7/23/21 2:15 AM, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> When the backlight support is disabled, the driver fails to build:
>
> drivers/gpu/drm/nouveau/dispnv50/disp.c: In function
> 'nv50_sor_atomic_disable':
> drivers/gpu/drm/nouveau/dispnv50/disp.c:1665:59: error: 'struct
> nouveau_connector' has no member named 'backlight'
> 1665 | struct nouveau_backlight *backlight = nv_connector->backlight;
> | ^~
> drivers/gpu/drm/nouveau/dispnv50/disp.c:1670:35: error: invalid use of
> undefined type 'struct nouveau_backlight'
> 1670 | if (backlight && backlight->uses_dpcd) {
> | ^~
> drivers/gpu/drm/nouveau/dispnv50/disp.c:1671:64: error: invalid use of
> undefined type 'struct nouveau_backlight'
> 1671 | ret = drm_edp_backlight_disable(aux,
> &backlight->edp_info);
> |^~
>
> The patch that introduced the problem already contains some #ifdef
> checks, so just add another one that makes it build again.
>
> Fixes: 6eca310e8924 ("drm/nouveau/kms/nv50-: Add basic DPCD backlight support
> for nouveau")
> Signed-off-by: Arnd Bergmann
> ---
> drivers/gpu/drm/nouveau/dispnv50/disp.c | 11 +++
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> index 093e1f7163b3..fcf53e24db21 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> @@ -1659,20 +1659,23 @@ static void
> nv50_sor_atomic_disable(struct drm_encoder *encoder, struct drm_atomic_state
> *state)
> {
> struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
> - struct nouveau_drm *drm = nouveau_drm(nv_encoder->base.base.dev);
> struct nouveau_crtc *nv_crtc = nouveau_crtc(nv_encoder->crtc);
> struct nouveau_connector *nv_connector =
> nv50_outp_get_old_connector(state, nv_encoder);
> - struct nouveau_backlight *backlight = nv_connector->backlight;
> struct drm_dp_aux *aux = &nv_connector->aux;
> - int ret;
> u8 pwr;
>
> +#ifdef CONFIG_DRM_NOUVEAU_BACKLIGHT
> + struct nouveau_drm *drm = nouveau_drm(nv_encoder->base.base.dev);
> + struct nouveau_backlight *backlight = nv_connector->backlight;
> +
> if (backlight && backlight->uses_dpcd) {
> - ret = drm_edp_backlight_disable(aux, &backlight->edp_info);
> + int ret = drm_edp_backlight_disable(aux, &backlight->edp_info);
> +
> if (ret < 0)
> NV_ERROR(drm, "Failed to disable backlight on
> [CONNECTOR:%d:%s]: %d\n",
>nv_connector->base.base.id,
> nv_connector->base.name, ret);
> }
> +#endif
>
> if (nv_encoder->dcb->type == DCB_OUTPUT_DP) {
> int ret = drm_dp_dpcd_readb(aux, DP_SET_POWER, &pwr);
>
Hm, only Lyude Paul replied to this patch:
https://lore.kernel.org/lkml/20210714171523.413-1-rdun...@infradead.org/
--
~Randy
Re: [PATCH] drm/nouveau/kms/nv50-: fix build failure with CONFIG_BACKLIGHT=n
On Fri, Jul 23, 2021 at 5:10 PM Randy Dunlap wrote:
>
> On 7/23/21 2:15 AM, Arnd Bergmann wrote:
> > From: Arnd Bergmann
> >
> > When the backlight support is disabled, the driver fails to build:
> >
> > drivers/gpu/drm/nouveau/dispnv50/disp.c: In function
> > 'nv50_sor_atomic_disable':
> > drivers/gpu/drm/nouveau/dispnv50/disp.c:1665:59: error: 'struct
> > nouveau_connector' has no member named 'backlight'
> > 1665 | struct nouveau_backlight *backlight =
> > nv_connector->backlight;
> > | ^~
> > drivers/gpu/drm/nouveau/dispnv50/disp.c:1670:35: error: invalid use of
> > undefined type 'struct nouveau_backlight'
> > 1670 | if (backlight && backlight->uses_dpcd) {
> > | ^~
> > drivers/gpu/drm/nouveau/dispnv50/disp.c:1671:64: error: invalid use of
> > undefined type 'struct nouveau_backlight'
> > 1671 | ret = drm_edp_backlight_disable(aux,
> > &backlight->edp_info);
> > |^~
> >
> > The patch that introduced the problem already contains some #ifdef
> > checks, so just add another one that makes it build again.
> >
> > Fixes: 6eca310e8924 ("drm/nouveau/kms/nv50-: Add basic DPCD backlight
> > support for nouveau")
> > Signed-off-by: Arnd Bergmann
> > ---
> > drivers/gpu/drm/nouveau/dispnv50/disp.c | 11 +++
> > 1 file changed, 7 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > index 093e1f7163b3..fcf53e24db21 100644
> > --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > @@ -1659,20 +1659,23 @@ static void
> > nv50_sor_atomic_disable(struct drm_encoder *encoder, struct
> > drm_atomic_state *state)
> > {
> > struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
> > - struct nouveau_drm *drm = nouveau_drm(nv_encoder->base.base.dev);
> > struct nouveau_crtc *nv_crtc = nouveau_crtc(nv_encoder->crtc);
> > struct nouveau_connector *nv_connector =
> > nv50_outp_get_old_connector(state, nv_encoder);
> > - struct nouveau_backlight *backlight = nv_connector->backlight;
> > struct drm_dp_aux *aux = &nv_connector->aux;
> > - int ret;
> > u8 pwr;
> >
> > +#ifdef CONFIG_DRM_NOUVEAU_BACKLIGHT
> > + struct nouveau_drm *drm = nouveau_drm(nv_encoder->base.base.dev);
> > + struct nouveau_backlight *backlight = nv_connector->backlight;
> > +
> > if (backlight && backlight->uses_dpcd) {
> > - ret = drm_edp_backlight_disable(aux, &backlight->edp_info);
> > + int ret = drm_edp_backlight_disable(aux,
> > &backlight->edp_info);
> > +
> > if (ret < 0)
> > NV_ERROR(drm, "Failed to disable backlight on
> > [CONNECTOR:%d:%s]: %d\n",
> >nv_connector->base.base.id,
> > nv_connector->base.name, ret);
> > }
> > +#endif
> >
> > if (nv_encoder->dcb->type == DCB_OUTPUT_DP) {
> > int ret = drm_dp_dpcd_readb(aux, DP_SET_POWER, &pwr);
> >
>
> Hm, only Lyude Paul replied to this patch:
>
> https://lore.kernel.org/lkml/20210714171523.413-1-rdun...@infradead.org/
>
what's actually the use case of compiling with
CONFIG_DRM_NOUVEAU_BACKLIGHT=n anyway?
>
>
> --
> ~Randy
>
Re: [PATCH] drm/prime: fix comment on PRIME Helpers
On 07/23, Jose Maria Casanova Crespo wrote:
> s/Exporting/Importing
>
> Fixes: 805dc614d58a8 ("drm/prime: Update docs")
Fixes flag here looks a little bit overkill. Anyway, this change lgtm
Reported-by: Rodrigo Siqueira
> Cc: Daniel Vetter
> Signed-off-by: Jose Maria Casanova Crespo
>
> ---
> drivers/gpu/drm/drm_prime.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index 2a54f86856af..178e18c28cab 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -549,7 +549,7 @@ int drm_prime_handle_to_fd_ioctl(struct drm_device *dev,
> void *data,
> *
> * FIXME: The underlying helper functions are named rather inconsistently.
> *
> - * Exporting buffers
> + * Importing buffers
> * ~
> *
> * Importing dma-bufs using drm_gem_prime_import() relies on
> --
> 2.20.1
>
--
Rodrigo Siqueira
https://siqueira.tech
Re: [PATCH] drm/nouveau/kms/nv50-: fix build failure with CONFIG_BACKLIGHT=n
On Fri, Jul 23, 2021 at 12:16:31PM +0200, Arnd Bergmann wrote:
> On Fri, Jul 23, 2021 at 11:25 AM Daniel Vetter wrote:
> >
> > On Fri, Jul 23, 2021 at 11:15 AM Arnd Bergmann wrote:
> > >
> > > From: Arnd Bergmann
> > >
> > > When the backlight support is disabled, the driver fails to build:
> > >
> > > drivers/gpu/drm/nouveau/dispnv50/disp.c: In function
> > > 'nv50_sor_atomic_disable':
> > > drivers/gpu/drm/nouveau/dispnv50/disp.c:1665:59: error: 'struct
> > > nouveau_connector' has no member named 'backlight'
> > > 1665 | struct nouveau_backlight *backlight =
> > > nv_connector->backlight;
> > > | ^~
> > > drivers/gpu/drm/nouveau/dispnv50/disp.c:1670:35: error: invalid use of
> > > undefined type 'struct nouveau_backlight'
> > > 1670 | if (backlight && backlight->uses_dpcd) {
> > > | ^~
> > > drivers/gpu/drm/nouveau/dispnv50/disp.c:1671:64: error: invalid use of
> > > undefined type 'struct nouveau_backlight'
> > > 1671 | ret = drm_edp_backlight_disable(aux,
> > > &backlight->edp_info);
> > > |^~
> > >
> > > The patch that introduced the problem already contains some #ifdef
> > > checks, so just add another one that makes it build again.
> > >
> > > Fixes: 6eca310e8924 ("drm/nouveau/kms/nv50-: Add basic DPCD backlight
> > > support for nouveau")
> > > Signed-off-by: Arnd Bergmann
> >
> > Can we just toss the idea that BACKTLIGHT=n is a reasonable config for
> > drm drivers using backlights, and add depends BACKLIGHT to all of
> > them?
> >
> > I mean this is a perfect source of continued patch streams to keep us
> > all busy, but beyond that I really don't see the point ... I frankly
> > have better things to do, and especially with the big drivers we have
> > making backlight optional saves comparitively nothing.
> > -Daniel
>
> Yes! I'd definitely be in favor of that, I've wasted way too much time trying
> to sort through dependency loops and other problems with backlight support.
>
> Maybe we should leave the drivers/video/fbdev/ drivers untouched in this
> regard, at least for the moment, but for the drivers/gpu/drm users of
> backlight that would be a nice simplification, and even the smallest ones
> are unlikely to be used on systems that are too memory constrained to
> deal with 4KB extra .text.
Yeah I think we can do this entirely ad-hoc, i.e. any time the backlight
wheel wobbles off again we nail it down for good for that driver with a
depends on BACKGLIGHT and remove any lingering #ifdef all over.
If you want maybe start out with the biggest drm drivers in a series, I
think if nouveau/amdgpu/i915 folks ack this you're good to go to just
convert as things get in the way.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Intel-gfx] [PATCH] drm/i915: Ditch i915 globals shrink infrastructure
On 21/07/2021 21:17, Jason Ekstrand wrote:
On Wed, Jul 21, 2021 at 1:32 PM Daniel Vetter wrote:
This essentially reverts
commit 84a1074920523430f9dc30ff907f4801b4820072
Author: Chris Wilson
Date: Wed Jan 24 11:36:08 2018 +
drm/i915: Shrink the GEM kmem_caches upon idling
mm/vmscan.c:do_shrink_slab() is a thing, if there's an issue with it
then we need to fix that there, not hand-roll our own slab shrinking
code in i915.
Noticed while reviewing a patch set from Jason to fix up some issues
in our i915_init() and i915_exit() module load/cleanup code. Now that
i915_globals.c isn't any different than normal init/exit functions, we
should convert them over to one unified table and remove
i915_globals.[hc] entirely.
Mind throwing in a comment somewhere about how i915 is one of only two
users of kmem_cache_shrink() in the entire kernel? That also seems to
be pretty good evidence that it's not useful.
Reviewed-by: Jason Ekstrand
FYI guys I've copied you on an thread with an mm expert which is
suggesting calling kmem_cache_shrink() is in fact probably a good idea
if it can be reasonably done.
Since that means the general principle is not invalid, as the commit
message and here suggest, we therefore could have had the discussion
purely in the realm of how much code complexity has this added to i915
and go from there.
Anyway at this point I can only repeat my plea not to rush things and
not to avoid copying people who were involved in discussions.
Regards,
Tvrtko
Feel free to land at-will and I'll deal with merge conflicts on my end.
Cc: David Airlie
Cc: Jason Ekstrand
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 6 --
drivers/gpu/drm/i915/gem/i915_gem_object.c | 6 --
drivers/gpu/drm/i915/gt/intel_context.c | 6 --
drivers/gpu/drm/i915/gt/intel_gt_pm.c | 4 -
drivers/gpu/drm/i915/i915_active.c | 6 --
drivers/gpu/drm/i915/i915_globals.c | 95 -
drivers/gpu/drm/i915/i915_globals.h | 3 -
drivers/gpu/drm/i915/i915_request.c | 7 --
drivers/gpu/drm/i915/i915_scheduler.c | 7 --
drivers/gpu/drm/i915/i915_vma.c | 6 --
10 files changed, 146 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 7d6f52d8a801..bf2a2319353a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -2280,18 +2280,12 @@ i915_gem_engines_iter_next(struct i915_gem_engines_iter
*it)
#include "selftests/i915_gem_context.c"
#endif
-static void i915_global_gem_context_shrink(void)
-{
- kmem_cache_shrink(global.slab_luts);
-}
-
static void i915_global_gem_context_exit(void)
{
kmem_cache_destroy(global.slab_luts);
}
static struct i915_global_gem_context global = { {
- .shrink = i915_global_gem_context_shrink,
.exit = i915_global_gem_context_exit,
} };
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 9da7b288b7ed..5c21cff33199 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -664,18 +664,12 @@ void i915_gem_init__objects(struct drm_i915_private *i915)
INIT_WORK(&i915->mm.free_work, __i915_gem_free_work);
}
-static void i915_global_objects_shrink(void)
-{
- kmem_cache_shrink(global.slab_objects);
-}
-
static void i915_global_objects_exit(void)
{
kmem_cache_destroy(global.slab_objects);
}
static struct i915_global_object global = { {
- .shrink = i915_global_objects_shrink,
.exit = i915_global_objects_exit,
} };
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index bd63813c8a80..c1338441cc1d 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -398,18 +398,12 @@ void intel_context_fini(struct intel_context *ce)
i915_active_fini(&ce->active);
}
-static void i915_global_context_shrink(void)
-{
- kmem_cache_shrink(global.slab_ce);
-}
-
static void i915_global_context_exit(void)
{
kmem_cache_destroy(global.slab_ce);
}
static struct i915_global_context global = { {
- .shrink = i915_global_context_shrink,
.exit = i915_global_context_exit,
} };
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
index aef3084e8b16..d86825437516 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
@@ -67,8 +67,6 @@ static int __gt_unpark(struct intel_wakeref *wf)
GT_TRACE(gt, "\n");
- i915_globals_unpark();
-
/*
* It seems that the DMC likes to transition between the DC states a
lot
* when there are no connected displays (no active power domains)
during
@@ -116,8 +114,6 @@ static int __g
[PATCH] drm: add logging for RMFB ioctl
We already have logging for ADDFB2. Add some logging for RMFB as well. This can be handy when trying to find out why a CRTC gets magically disabled. Signed-off-by: Simon Ser Cc: Daniel Vetter --- drivers/gpu/drm/drm_framebuffer.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/drm_framebuffer.c b/drivers/gpu/drm/drm_framebuffer.c index 4d01464b6f95..da77ceeb35e3 100644 --- a/drivers/gpu/drm/drm_framebuffer.c +++ b/drivers/gpu/drm/drm_framebuffer.c @@ -404,6 +404,7 @@ static void drm_mode_rmfb_work_fn(struct work_struct *w) struct drm_framebuffer *fb = list_first_entry(&arg->fbs, typeof(*fb), filp_head); + drm_dbg_kms(fb->dev, "Removing [FB:%d]\n", fb->base.id); list_del_init(&fb->filp_head); drm_framebuffer_remove(fb); } -- 2.32.0
Re: [PATCH 3/3] drm/amdgpu: replace dce_virtual with amdgpu_vkms (v3)
[AMD Official Use Only]
Thanks Alex! I will make these changes.
Best,
Ryan
From: Alex Deucher
Sent: Friday, July 23, 2021 7:33 AM
To: Taylor, Ryan
Cc: Maling list - DRI developers ; amd-gfx
list ; kernel test robot ;
Daniel Vetter ; Siqueira, Rodrigo
; Melissa Wen ; Deucher,
Alexander
Subject: Re: [PATCH 3/3] drm/amdgpu: replace dce_virtual with amdgpu_vkms (v3)
On Wed, Jul 21, 2021 at 1:07 PM Ryan Taylor wrote:
>
> Move dce_virtual into amdgpu_vkms and update all references to
> dce_virtual with amdgpu_vkms.
>
> v2: Removed more references to dce_virtual.
>
> v3: Restored display modes from previous implementation.
>
> Reported-by: kernel test robot
> Suggested-by: Alex Deucher
> Signed-off-by: Ryan Taylor
> ---
> drivers/gpu/drm/amd/amdgpu/Makefile | 3 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c | 234 ++-
> drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.h | 5 +-
> drivers/gpu/drm/amd/amdgpu/cik.c | 10 +-
> drivers/gpu/drm/amd/amdgpu/dce_virtual.c | 223 -
> drivers/gpu/drm/amd/amdgpu/dce_virtual.h | 30 ---
> drivers/gpu/drm/amd/amdgpu/nv.c | 20 +-
> drivers/gpu/drm/amd/amdgpu/si.c | 8 +-
> drivers/gpu/drm/amd/amdgpu/soc15.c | 10 +-
> drivers/gpu/drm/amd/amdgpu/vi.c | 14 +-
> 10 files changed, 264 insertions(+), 293 deletions(-)
> delete mode 100644 drivers/gpu/drm/amd/amdgpu/dce_virtual.c
> delete mode 100644 drivers/gpu/drm/amd/amdgpu/dce_virtual.h
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile
> b/drivers/gpu/drm/amd/amdgpu/Makefile
> index 30cbcd5ce1cc..0d814c957461 100644
> --- a/drivers/gpu/drm/amd/amdgpu/Makefile
> +++ b/drivers/gpu/drm/amd/amdgpu/Makefile
> @@ -120,8 +120,7 @@ amdgpu-y += \
> amdgpu-y += \
> dce_v10_0.o \
> dce_v11_0.o \
> - amdgpu_vkms.o \
> - dce_virtual.o
> + amdgpu_vkms.o
>
> # add GFX block
> amdgpu-y += \
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
> index d5c1f1c58f5f..538d41ea 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
> @@ -5,6 +5,15 @@
> #include
>
> #include "amdgpu.h"
> +#ifdef CONFIG_DRM_AMDGPU_SI
> +#include "dce_v6_0.h"
> +#endif
> +#ifdef CONFIG_DRM_AMDGPU_CIK
> +#include "dce_v8_0.h"
> +#endif
> +#include "dce_v10_0.h"
> +#include "dce_v11_0.h"
> +#include "ivsrcid/ivsrcid_vislands30.h"
> #include "amdgpu_vkms.h"
> #include "amdgpu_display.h"
>
> @@ -180,12 +189,45 @@ static const struct drm_connector_funcs
> amdgpu_vkms_connector_funcs = {
>
> static int amdgpu_vkms_conn_get_modes(struct drm_connector *connector)
> {
> - int count;
> + struct drm_device *dev = connector->dev;
> + struct drm_display_mode *mode = NULL;
> + unsigned i;
> + static const struct mode_size {
> + int w;
> + int h;
> + } common_modes[] = {
> + { 640, 480},
> + { 720, 480},
> + { 800, 600},
> + { 848, 480},
> + {1024, 768},
> + {1152, 768},
> + {1280, 720},
> + {1280, 800},
> + {1280, 854},
> + {1280, 960},
> + {1280, 1024},
> + {1440, 900},
> + {1400, 1050},
> + {1680, 1050},
> + {1600, 1200},
> + {1920, 1080},
> + {1920, 1200},
> + {2560, 1440},
> + {4096, 3112},
> + {3656, 2664},
> + {3840, 2160},
> + {4096, 2160},
> + };
> +
> + for (i = 0; i < ARRAY_SIZE(common_modes); i++) {
> + mode = drm_cvt_mode(dev, common_modes[i].w,
> common_modes[i].h, 60, false, false, false);
> + drm_mode_probed_add(connector, mode);
> + }
>
> - count = drm_add_modes_noedid(connector, XRES_MAX, YRES_MAX);
> drm_set_preferred_mode(connector, XRES_DEF, YRES_DEF);
>
> - return count;
> + return ARRAY_SIZE(common_modes);
> }
>
> static const struct drm_connector_helper_funcs amdgpu_vkms_conn_helper_funcs
> = {
> @@ -409,3 +451,189 @@ int amdgpu_vkms_output_init(struct drm_device *dev,
>
> return ret;
> }
> +
> +const struct drm_mode_config_funcs amdgpu_vkms_mode_funcs = {
> + .fb_create = amdgpu_display_user_framebuffer_create,
> + .atomic_check = drm_atomic_helper_check,
> + .atomic_commit = drm_atomic_helper_commit,
> +};
> +
> +static int amdgpu_vkms_sw_init(void *handle)
> +{
> + int r, i;
> + struct amdgpu_device *adev = (struct amdgpu_device *)handle;
> +
> + adev_to_drm(adev)->max_vblank_count = 0;
> +
> + adev_to_drm(adev)->mode_config.funcs = &amdgpu_vkms_mode_funcs;
> +
> + adev_to_drm(adev)->mode_config.max_width = XRES_MAX;
> + adev_to_drm(adev)->mode_config.max_height
Re: [Nouveau] nouveau broken again on Riva TNT2 in 5.14.0-rc2
On Friday 23 July 2021 09:26:10 Daniel Vetter wrote: > On Thu, Jul 22, 2021 at 9:51 PM Karol Herbst wrote: > > > > hey thanks for the report. > > > > This is a known issue and the fix is pending in drm-mist-fixes and > > should land in 5.14 soonish. > > It just landed in Linus' tree yesterday, please retest that or -rc3. > If it's still broken it's something else. > -Daniel Thanks, it works! -- Ondrej Zary
Re: [PATCH] drm/nouveau/kms/nv50-: fix build failure with CONFIG_BACKLIGHT=n
On Fri, 2021-07-23 at 11:24 +0200, Daniel Vetter wrote:
> On Fri, Jul 23, 2021 at 11:15 AM Arnd Bergmann wrote:
> >
> > From: Arnd Bergmann
> >
> > When the backlight support is disabled, the driver fails to build:
> >
> > drivers/gpu/drm/nouveau/dispnv50/disp.c: In function
> > 'nv50_sor_atomic_disable':
> > drivers/gpu/drm/nouveau/dispnv50/disp.c:1665:59: error: 'struct
> > nouveau_connector' has no member named 'backlight'
> > 1665 | struct nouveau_backlight *backlight = nv_connector-
> > >backlight;
> > | ^~
> > drivers/gpu/drm/nouveau/dispnv50/disp.c:1670:35: error: invalid use of
> > undefined type 'struct nouveau_backlight'
> > 1670 | if (backlight && backlight->uses_dpcd) {
> > | ^~
> > drivers/gpu/drm/nouveau/dispnv50/disp.c:1671:64: error: invalid use of
> > undefined type 'struct nouveau_backlight'
> > 1671 | ret = drm_edp_backlight_disable(aux, &backlight-
> > >edp_info);
> > | ^~
> >
> > The patch that introduced the problem already contains some #ifdef
> > checks, so just add another one that makes it build again.
> >
> > Fixes: 6eca310e8924 ("drm/nouveau/kms/nv50-: Add basic DPCD backlight
> > support for nouveau")
> > Signed-off-by: Arnd Bergmann
>
> Can we just toss the idea that BACKTLIGHT=n is a reasonable config for
> drm drivers using backlights, and add depends BACKLIGHT to all of
> them?
Yeah - I'm fine with this IMHO, at least for the drivers actually supporting
backlights in some manner (I assume this is most of them though)
>
> I mean this is a perfect source of continued patch streams to keep us
> all busy, but beyond that I really don't see the point ... I frankly
> have better things to do, and especially with the big drivers we have
> making backlight optional saves comparitively nothing.
> -Daniel
>
> > ---
> > drivers/gpu/drm/nouveau/dispnv50/disp.c | 11 +++
> > 1 file changed, 7 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > index 093e1f7163b3..fcf53e24db21 100644
> > --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > @@ -1659,20 +1659,23 @@ static void
> > nv50_sor_atomic_disable(struct drm_encoder *encoder, struct
> > drm_atomic_state *state)
> > {
> > struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
> > - struct nouveau_drm *drm = nouveau_drm(nv_encoder->base.base.dev);
> > struct nouveau_crtc *nv_crtc = nouveau_crtc(nv_encoder->crtc);
> > struct nouveau_connector *nv_connector =
> > nv50_outp_get_old_connector(state, nv_encoder);
> > - struct nouveau_backlight *backlight = nv_connector->backlight;
> > struct drm_dp_aux *aux = &nv_connector->aux;
> > - int ret;
> > u8 pwr;
> >
> > +#ifdef CONFIG_DRM_NOUVEAU_BACKLIGHT
> > + struct nouveau_drm *drm = nouveau_drm(nv_encoder->base.base.dev);
> > + struct nouveau_backlight *backlight = nv_connector->backlight;
> > +
> > if (backlight && backlight->uses_dpcd) {
> > - ret = drm_edp_backlight_disable(aux, &backlight-
> > >edp_info);
> > + int ret = drm_edp_backlight_disable(aux, &backlight-
> > >edp_info);
> > +
> > if (ret < 0)
> > NV_ERROR(drm, "Failed to disable backlight on
> > [CONNECTOR:%d:%s]: %d\n",
> > nv_connector->base.base.id, nv_connector-
> > >base.name, ret);
> > }
> > +#endif
> >
> > if (nv_encoder->dcb->type == DCB_OUTPUT_DP) {
> > int ret = drm_dp_dpcd_readb(aux, DP_SET_POWER, &pwr);
> > --
> > 2.29.2
> >
>
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
[PATCH] dma-buf: WARN on dmabuf release with pending attachments
It is expected from the clients to follow the below steps on an imported dmabuf fd: a) dmabuf = dma_buf_get(fd) // Get the dmabuf from fd b) dma_buf_attach(dmabuf); // Clients attach to the dmabuf o Here the kernel does some slab allocations, say for dma_buf_attachment and may be some other slab allocation in the dmabuf->ops->attach(). c) Client may need to do dma_buf_map_attachment(). d) Accordingly dma_buf_unmap_attachment() should be called. e) dma_buf_detach () // Clients detach to the dmabuf. o Here the slab allocations made in b) are freed. f) dma_buf_put(dmabuf) // Can free the dmabuf if it is the last reference. Now say an erroneous client failed at step c) above thus it directly called dma_buf_put(), step f) above. Considering that it may be the last reference to the dmabuf, buffer will be freed with pending attachments left to the dmabuf which can show up as the 'memory leak'. This should at least be reported as the WARN(). Signed-off-by: Charan Teja Reddy --- drivers/dma-buf/dma-buf.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index 511fe0d..733c8b1 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -79,6 +79,7 @@ static void dma_buf_release(struct dentry *dentry) if (dmabuf->resv == (struct dma_resv *)&dmabuf[1]) dma_resv_fini(dmabuf->resv); + WARN_ON(!list_empty(&dmabuf->attachments)); module_put(dmabuf->owner); kfree(dmabuf->name); kfree(dmabuf); -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation
[PATCH] drm/vc4: hdmi: Add debugfs prefix
Without prefix debugfs can't properly create component debug information tree when driver register more than one component per device, in this case two. Fix this. debugfs: Directory 'fef00700.hdmi' with parent 'vc4-hdmi-0' already present! Signed-off-by: Ivan T. Ivanov --- drivers/gpu/drm/vc4/vc4_hdmi.c | 13 + 1 file changed, 13 insertions(+) diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c index aab1b36ceb3c..62b057f88df5 100644 --- a/drivers/gpu/drm/vc4/vc4_hdmi.c +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c @@ -1523,6 +1523,9 @@ static int vc4_hdmi_audio_init(struct vc4_hdmi *vc4_hdmi) struct snd_soc_dai_link *dai_link = &vc4_hdmi->audio.link; struct snd_soc_card *card = &vc4_hdmi->audio.card; struct device *dev = &vc4_hdmi->pdev->dev; +#ifdef CONFIG_DEBUG_FS + struct snd_soc_component *comp; +#endif const __be32 *addr; int index; int ret; @@ -1577,6 +1580,16 @@ static int vc4_hdmi_audio_init(struct vc4_hdmi *vc4_hdmi) return ret; } +#ifdef CONFIG_DEBUG_FS + comp = snd_soc_lookup_component(dev, vc4_hdmi_audio_cpu_dai_comp.name); + if (comp) + comp->debugfs_prefix = "cpu"; + + comp = snd_soc_lookup_component(dev, vc4_hdmi_audio_component_drv.name); + if (comp) + comp->debugfs_prefix = "codec"; +#endif + dai_link->cpus = &vc4_hdmi->audio.cpu; dai_link->codecs= &vc4_hdmi->audio.codec; dai_link->platforms = &vc4_hdmi->audio.platform; -- 2.32.0
Re: [PATCH] drm/nouveau/kms/nv50-: fix build failure with CONFIG_BACKLIGHT=n
On 7/23/21 8:15 AM, Karol Herbst wrote:
> On Fri, Jul 23, 2021 at 5:10 PM Randy Dunlap wrote:
>>
>> On 7/23/21 2:15 AM, Arnd Bergmann wrote:
>>> From: Arnd Bergmann
>>>
>>> When the backlight support is disabled, the driver fails to build:
>>>
>>> drivers/gpu/drm/nouveau/dispnv50/disp.c: In function
>>> 'nv50_sor_atomic_disable':
>>> drivers/gpu/drm/nouveau/dispnv50/disp.c:1665:59: error: 'struct
>>> nouveau_connector' has no member named 'backlight'
>>> 1665 | struct nouveau_backlight *backlight =
>>> nv_connector->backlight;
>>> | ^~
>>> drivers/gpu/drm/nouveau/dispnv50/disp.c:1670:35: error: invalid use of
>>> undefined type 'struct nouveau_backlight'
>>> 1670 | if (backlight && backlight->uses_dpcd) {
>>> | ^~
>>> drivers/gpu/drm/nouveau/dispnv50/disp.c:1671:64: error: invalid use of
>>> undefined type 'struct nouveau_backlight'
>>> 1671 | ret = drm_edp_backlight_disable(aux,
>>> &backlight->edp_info);
>>> |^~
>>>
>>> The patch that introduced the problem already contains some #ifdef
>>> checks, so just add another one that makes it build again.
>>>
>>> Fixes: 6eca310e8924 ("drm/nouveau/kms/nv50-: Add basic DPCD backlight
>>> support for nouveau")
>>> Signed-off-by: Arnd Bergmann
>>> ---
>>> drivers/gpu/drm/nouveau/dispnv50/disp.c | 11 +++
>>> 1 file changed, 7 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
>>> b/drivers/gpu/drm/nouveau/dispnv50/disp.c
>>> index 093e1f7163b3..fcf53e24db21 100644
>>> --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
>>> +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
>>> @@ -1659,20 +1659,23 @@ static void
>>> nv50_sor_atomic_disable(struct drm_encoder *encoder, struct
>>> drm_atomic_state *state)
>>> {
>>> struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
>>> - struct nouveau_drm *drm = nouveau_drm(nv_encoder->base.base.dev);
>>> struct nouveau_crtc *nv_crtc = nouveau_crtc(nv_encoder->crtc);
>>> struct nouveau_connector *nv_connector =
>>> nv50_outp_get_old_connector(state, nv_encoder);
>>> - struct nouveau_backlight *backlight = nv_connector->backlight;
>>> struct drm_dp_aux *aux = &nv_connector->aux;
>>> - int ret;
>>> u8 pwr;
>>>
>>> +#ifdef CONFIG_DRM_NOUVEAU_BACKLIGHT
>>> + struct nouveau_drm *drm = nouveau_drm(nv_encoder->base.base.dev);
>>> + struct nouveau_backlight *backlight = nv_connector->backlight;
>>> +
>>> if (backlight && backlight->uses_dpcd) {
>>> - ret = drm_edp_backlight_disable(aux, &backlight->edp_info);
>>> + int ret = drm_edp_backlight_disable(aux,
>>> &backlight->edp_info);
>>> +
>>> if (ret < 0)
>>> NV_ERROR(drm, "Failed to disable backlight on
>>> [CONNECTOR:%d:%s]: %d\n",
>>>nv_connector->base.base.id,
>>> nv_connector->base.name, ret);
>>> }
>>> +#endif
>>>
>>> if (nv_encoder->dcb->type == DCB_OUTPUT_DP) {
>>> int ret = drm_dp_dpcd_readb(aux, DP_SET_POWER, &pwr);
>>>
>>
>> Hm, only Lyude Paul replied to this patch:
>>
>> https://lore.kernel.org/lkml/20210714171523.413-1-rdun...@infradead.org/
>>
>
> what's actually the use case of compiling with
> CONFIG_DRM_NOUVEAU_BACKLIGHT=n anyway?
Dunno. In this case it was just a randconfig. Still, it needs to be
handled in some way - such as the other suggestion in this thread.
Re: [PATCH] drm: add logging for RMFB ioctl
On Fri, Jul 23, 2021 at 5:46 PM Simon Ser wrote: > > We already have logging for ADDFB2. Add some logging for RMFB as > well. > > This can be handy when trying to find out why a CRTC gets magically > disabled. > > Signed-off-by: Simon Ser > Cc: Daniel Vetter > --- > drivers/gpu/drm/drm_framebuffer.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/drm_framebuffer.c > b/drivers/gpu/drm/drm_framebuffer.c > index 4d01464b6f95..da77ceeb35e3 100644 > --- a/drivers/gpu/drm/drm_framebuffer.c > +++ b/drivers/gpu/drm/drm_framebuffer.c > @@ -404,6 +404,7 @@ static void drm_mode_rmfb_work_fn(struct work_struct *w) > struct drm_framebuffer *fb = > list_first_entry(&arg->fbs, typeof(*fb), filp_head); > > + drm_dbg_kms(fb->dev, "Removing [FB:%d]\n", fb->base.id); I'd hammer more in what happens and why this happens. Maybe something like this? "Disabling [FB:¯from all active usage due to RMFB IOCTL\n" Also I wonder whether we could put some additional debug output into drm_framebuffer_remove when we either disable just the plane or the entire crtc as further clue. Like "Disabling CRTC|PLANE because FB is being removed from all active use\n" Also, because you're this great at typing docs: Kerneldoc for RMFB would be nice, but there's not even a struct to attach it to :-/ Any ideas for how to do that? -Daniel > list_del_init(&fb->filp_head); > drm_framebuffer_remove(fb); > } > -- > 2.32.0 > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH] drm/nouveau/kms/nv50-: fix build failure with CONFIG_BACKLIGHT=n
On Fri, Jul 23, 2021 at 6:31 PM Randy Dunlap wrote:
>
> On 7/23/21 8:15 AM, Karol Herbst wrote:
> > On Fri, Jul 23, 2021 at 5:10 PM Randy Dunlap wrote:
> >>
> >> On 7/23/21 2:15 AM, Arnd Bergmann wrote:
> >>> From: Arnd Bergmann
> >>>
> >>> When the backlight support is disabled, the driver fails to build:
> >>>
> >>> drivers/gpu/drm/nouveau/dispnv50/disp.c: In function
> >>> 'nv50_sor_atomic_disable':
> >>> drivers/gpu/drm/nouveau/dispnv50/disp.c:1665:59: error: 'struct
> >>> nouveau_connector' has no member named 'backlight'
> >>> 1665 | struct nouveau_backlight *backlight =
> >>> nv_connector->backlight;
> >>> | ^~
> >>> drivers/gpu/drm/nouveau/dispnv50/disp.c:1670:35: error: invalid use of
> >>> undefined type 'struct nouveau_backlight'
> >>> 1670 | if (backlight && backlight->uses_dpcd) {
> >>> | ^~
> >>> drivers/gpu/drm/nouveau/dispnv50/disp.c:1671:64: error: invalid use of
> >>> undefined type 'struct nouveau_backlight'
> >>> 1671 | ret = drm_edp_backlight_disable(aux,
> >>> &backlight->edp_info);
> >>> |^~
> >>>
> >>> The patch that introduced the problem already contains some #ifdef
> >>> checks, so just add another one that makes it build again.
> >>>
> >>> Fixes: 6eca310e8924 ("drm/nouveau/kms/nv50-: Add basic DPCD backlight
> >>> support for nouveau")
> >>> Signed-off-by: Arnd Bergmann
> >>> ---
> >>> drivers/gpu/drm/nouveau/dispnv50/disp.c | 11 +++
> >>> 1 file changed, 7 insertions(+), 4 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> >>> b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> >>> index 093e1f7163b3..fcf53e24db21 100644
> >>> --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> >>> +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> >>> @@ -1659,20 +1659,23 @@ static void
> >>> nv50_sor_atomic_disable(struct drm_encoder *encoder, struct
> >>> drm_atomic_state *state)
> >>> {
> >>> struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
> >>> - struct nouveau_drm *drm = nouveau_drm(nv_encoder->base.base.dev);
> >>> struct nouveau_crtc *nv_crtc = nouveau_crtc(nv_encoder->crtc);
> >>> struct nouveau_connector *nv_connector =
> >>> nv50_outp_get_old_connector(state, nv_encoder);
> >>> - struct nouveau_backlight *backlight = nv_connector->backlight;
> >>> struct drm_dp_aux *aux = &nv_connector->aux;
> >>> - int ret;
> >>> u8 pwr;
> >>>
> >>> +#ifdef CONFIG_DRM_NOUVEAU_BACKLIGHT
> >>> + struct nouveau_drm *drm = nouveau_drm(nv_encoder->base.base.dev);
> >>> + struct nouveau_backlight *backlight = nv_connector->backlight;
> >>> +
> >>> if (backlight && backlight->uses_dpcd) {
> >>> - ret = drm_edp_backlight_disable(aux, &backlight->edp_info);
> >>> + int ret = drm_edp_backlight_disable(aux,
> >>> &backlight->edp_info);
> >>> +
> >>> if (ret < 0)
> >>> NV_ERROR(drm, "Failed to disable backlight on
> >>> [CONNECTOR:%d:%s]: %d\n",
> >>>nv_connector->base.base.id,
> >>> nv_connector->base.name, ret);
> >>> }
> >>> +#endif
> >>>
> >>> if (nv_encoder->dcb->type == DCB_OUTPUT_DP) {
> >>> int ret = drm_dp_dpcd_readb(aux, DP_SET_POWER, &pwr);
> >>>
> >>
> >> Hm, only Lyude Paul replied to this patch:
> >>
> >> https://lore.kernel.org/lkml/20210714171523.413-1-rdun...@infradead.org/
> >>
> >
> > what's actually the use case of compiling with
> > CONFIG_DRM_NOUVEAU_BACKLIGHT=n anyway?
>
> Dunno. In this case it was just a randconfig. Still, it needs to be
> handled in some way - such as the other suggestion in this thread.
>
sure, I was just curious if there was a specific use case or just
something random as you mentioned.
Re: [RFC 6/8] drm: Document fdinfo format specification
Hi Tvrtko, Thanks for typing this up! On Thu, 15 Jul 2021 at 10:18, Tvrtko Ursulin wrote: > +Mandatory fully standardised keys > +- > + > +- drm-driver: > + > +String shall contain a fixed string uniquely identified the driver handling > +the device in question. For example name of the respective kernel module. I think let's be more prescriptive and just say that it is the module name. > +Optional fully standardised keys > + > + > +- drm-pdev: > + > +For PCI devices this should contain the PCI slot address of the device in > +question. How about just major:minor of the DRM render node device it's attached to? > +- drm-client-id: > + > +Unique value relating to the open DRM file descriptor used to distinguish > +duplicated and shared file descriptors. Conceptually the value should map 1:1 > +to the in kernel representation of `struct drm_file` instances. > + > +Uniqueness of the value shall be either globally unique, or unique within the > +scope of each device, in which case `drm-pdev` shall be present as well. > + > +Userspace should make sure to not double account any usage statistics by > using > +the above described criteria in order to associate data to individual > clients. > + > +- drm-engine-: ns > + > +GPUs usually contain multiple execution engines. Each shall be given a stable > +and unique name (str), with possible values documented in the driver specific > +documentation. > + > +Value shall be in specified time units which the respective GPU engine spent > +busy executing workloads belonging to this client. > + > +Values are not required to be constantly monotonic if it makes the driver > +implementation easier, but are required to catch up with the previously > reported > +larger value within a reasonable period. Upon observing a value lower than > what > +was previously read, userspace is expected to stay with that larger previous > +value until a monotonic update is seen. Yeah, that would work well for Mali/Panfrost. We can queue multiple jobs in the hardware, which can either be striped across multiple cores with an affinity mask (e.g. 3 cores for your client and 1 for your compositor), or picked according to priority, or ... The fine-grained performance counters (e.g. time spent waiting for sampler) are only GPU-global. So if you have two jobs running simultaneously, you have no idea who's responsible for what. But it does give us coarse-grained counters which are accounted per-job-slot, including exactly this metric: amount of 'GPU time' (whatever that means) occupied by that job slot during the sampling period. So we could support that nicely if we fenced job-slot updates with register reads/writes. Something I'm missing though is how we enable this information. Seems like it would be best to either only do it whilst fdinfo is open (and re-read it whenever you need an update), or on a per-driver sysfs toggle, or ... ? > +- drm-memory-: [KiB|MiB] > + > +Each possible memory type which can be used to store buffer objects by the > +GPU in question shall be given a stable and unique name to be returned as the > +string here. > + > +Value shall reflect the amount of storage currently consumed by the buffer > +object belong to this client, in the respective memory region. > + > +Default unit shall be bytes with optional unit specifiers of 'KiB' or 'MiB' > +indicating kibi- or mebi-bytes. I'm a bit wary of the accounting here. Is it buffer allocations originating from the client, in which case it conceptually clashes with gralloc? Is it the client which last wrote to the buffer? The client with the oldest open handle to the buffer? Other? Cheers, Daniel
Re: [RFC 6/8] drm: Document fdinfo format specification
On Fri, Jul 23, 2021 at 05:43:01PM +0100, Daniel Stone wrote: > Hi Tvrtko, > Thanks for typing this up! > > On Thu, 15 Jul 2021 at 10:18, Tvrtko Ursulin > wrote: > > +Mandatory fully standardised keys > > +- > > + > > +- drm-driver: > > + > > +String shall contain a fixed string uniquely identified the driver handling > > +the device in question. For example name of the respective kernel module. > > I think let's be more prescriptive and just say that it is the module name. Just a quick comment on this one. drm_driver.name is already uapi, so let's please not invent a new one. The shared code should probably make sure drivers don't get this wrong. Maybe good if we document the getverion ioctl, which also exposes this, and then link between the two. -Daniel > > > +Optional fully standardised keys > > + > > + > > +- drm-pdev: > > + > > +For PCI devices this should contain the PCI slot address of the device in > > +question. > > How about just major:minor of the DRM render node device it's attached to? > > > +- drm-client-id: > > + > > +Unique value relating to the open DRM file descriptor used to distinguish > > +duplicated and shared file descriptors. Conceptually the value should map > > 1:1 > > +to the in kernel representation of `struct drm_file` instances. > > + > > +Uniqueness of the value shall be either globally unique, or unique within > > the > > +scope of each device, in which case `drm-pdev` shall be present as well. > > + > > +Userspace should make sure to not double account any usage statistics by > > using > > +the above described criteria in order to associate data to individual > > clients. > > + > > +- drm-engine-: ns > > + > > +GPUs usually contain multiple execution engines. Each shall be given a > > stable > > +and unique name (str), with possible values documented in the driver > > specific > > +documentation. > > + > > +Value shall be in specified time units which the respective GPU engine > > spent > > +busy executing workloads belonging to this client. > > + > > +Values are not required to be constantly monotonic if it makes the driver > > +implementation easier, but are required to catch up with the previously > > reported > > +larger value within a reasonable period. Upon observing a value lower than > > what > > +was previously read, userspace is expected to stay with that larger > > previous > > +value until a monotonic update is seen. > > Yeah, that would work well for Mali/Panfrost. We can queue multiple > jobs in the hardware, which can either be striped across multiple > cores with an affinity mask (e.g. 3 cores for your client and 1 for > your compositor), or picked according to priority, or ... > > The fine-grained performance counters (e.g. time spent waiting for > sampler) are only GPU-global. So if you have two jobs running > simultaneously, you have no idea who's responsible for what. > > But it does give us coarse-grained counters which are accounted > per-job-slot, including exactly this metric: amount of 'GPU time' > (whatever that means) occupied by that job slot during the sampling > period. So we could support that nicely if we fenced job-slot updates > with register reads/writes. > > Something I'm missing though is how we enable this information. Seems > like it would be best to either only do it whilst fdinfo is open (and > re-read it whenever you need an update), or on a per-driver sysfs > toggle, or ... ? > > > +- drm-memory-: [KiB|MiB] > > + > > +Each possible memory type which can be used to store buffer objects by the > > +GPU in question shall be given a stable and unique name to be returned as > > the > > +string here. > > + > > +Value shall reflect the amount of storage currently consumed by the buffer > > +object belong to this client, in the respective memory region. > > + > > +Default unit shall be bytes with optional unit specifiers of 'KiB' or 'MiB' > > +indicating kibi- or mebi-bytes. > > I'm a bit wary of the accounting here. Is it buffer allocations > originating from the client, in which case it conceptually clashes > with gralloc? Is it the client which last wrote to the buffer? The > client with the oldest open handle to the buffer? Other? > > Cheers, > Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH v2 4/4] drm/vmwgfx: Use 2.19 version number to recognize mks-stats ioctls
To let the userspace recognize that it's running on top of a vmwgfx that supports mks-stat ioctls we need to bump the version number. Signed-off-by: Zack Rusin Reviewed-by: Martin Krastev Reviewed-by: Neha Bhende --- drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h index 375b01cccd1a..63437270cbca 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h @@ -54,10 +54,10 @@ #define VMWGFX_DRIVER_NAME "vmwgfx" -#define VMWGFX_DRIVER_DATE "20210218" +#define VMWGFX_DRIVER_DATE "20210722" #define VMWGFX_DRIVER_MAJOR 2 -#define VMWGFX_DRIVER_MINOR 18 -#define VMWGFX_DRIVER_PATCHLEVEL 1 +#define VMWGFX_DRIVER_MINOR 19 +#define VMWGFX_DRIVER_PATCHLEVEL 0 #define VMWGFX_FIFO_STATIC_SIZE (1024*1024) #define VMWGFX_MAX_RELOCATIONS 2048 #define VMWGFX_MAX_VALIDATIONS 2048 -- 2.30.2
[PATCH v2 1/4] drm/vmwgfx: Switch to using DRM_IOCTL_DEF_DRV
The macro has been accounting for DRM_COMMAND_BASE for a long time
now so there's no reason to still be duplicating it. Plus we were
leaving the name undefined which meant that all the DRM ioctl
warnings/errors were always listing "null" ioctl at the culprit.
This fixes the undefined ioctl name and removes duplicated code.
Signed-off-by: Zack Rusin
Reviewed-by: Martin Krastev
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 176 +---
1 file changed, 84 insertions(+), 92 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 40864ce19ae1..05d6705aa46a 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -159,110 +159,102 @@
DRM_IOW(DRM_COMMAND_BASE + DRM_VMW_MKSSTAT_REMOVE, \
struct drm_vmw_mksstat_remove_arg)
-/*
- * The core DRM version of this macro doesn't account for
- * DRM_COMMAND_BASE.
- */
-
-#define VMW_IOCTL_DEF(ioctl, func, flags) \
- [DRM_IOCTL_NR(DRM_IOCTL_##ioctl) - DRM_COMMAND_BASE] = {DRM_IOCTL_##ioctl,
flags, func}
-
/*
* Ioctl definitions.
*/
static const struct drm_ioctl_desc vmw_ioctls[] = {
- VMW_IOCTL_DEF(VMW_GET_PARAM, vmw_getparam_ioctl,
- DRM_RENDER_ALLOW),
- VMW_IOCTL_DEF(VMW_ALLOC_DMABUF, vmw_bo_alloc_ioctl,
- DRM_RENDER_ALLOW),
- VMW_IOCTL_DEF(VMW_UNREF_DMABUF, vmw_bo_unref_ioctl,
- DRM_RENDER_ALLOW),
- VMW_IOCTL_DEF(VMW_CURSOR_BYPASS,
- vmw_kms_cursor_bypass_ioctl,
- DRM_MASTER),
-
- VMW_IOCTL_DEF(VMW_CONTROL_STREAM, vmw_overlay_ioctl,
- DRM_MASTER),
- VMW_IOCTL_DEF(VMW_CLAIM_STREAM, vmw_stream_claim_ioctl,
- DRM_MASTER),
- VMW_IOCTL_DEF(VMW_UNREF_STREAM, vmw_stream_unref_ioctl,
- DRM_MASTER),
-
- VMW_IOCTL_DEF(VMW_CREATE_CONTEXT, vmw_context_define_ioctl,
- DRM_RENDER_ALLOW),
- VMW_IOCTL_DEF(VMW_UNREF_CONTEXT, vmw_context_destroy_ioctl,
- DRM_RENDER_ALLOW),
- VMW_IOCTL_DEF(VMW_CREATE_SURFACE, vmw_surface_define_ioctl,
- DRM_RENDER_ALLOW),
- VMW_IOCTL_DEF(VMW_UNREF_SURFACE, vmw_surface_destroy_ioctl,
- DRM_RENDER_ALLOW),
- VMW_IOCTL_DEF(VMW_REF_SURFACE, vmw_surface_reference_ioctl,
- DRM_RENDER_ALLOW),
- VMW_IOCTL_DEF(VMW_EXECBUF, vmw_execbuf_ioctl,
- DRM_RENDER_ALLOW),
- VMW_IOCTL_DEF(VMW_FENCE_WAIT, vmw_fence_obj_wait_ioctl,
- DRM_RENDER_ALLOW),
- VMW_IOCTL_DEF(VMW_FENCE_SIGNALED,
- vmw_fence_obj_signaled_ioctl,
- DRM_RENDER_ALLOW),
- VMW_IOCTL_DEF(VMW_FENCE_UNREF, vmw_fence_obj_unref_ioctl,
- DRM_RENDER_ALLOW),
- VMW_IOCTL_DEF(VMW_FENCE_EVENT, vmw_fence_event_ioctl,
- DRM_RENDER_ALLOW),
- VMW_IOCTL_DEF(VMW_GET_3D_CAP, vmw_get_cap_3d_ioctl,
- DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(VMW_GET_PARAM, vmw_getparam_ioctl,
+ DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(VMW_ALLOC_DMABUF, vmw_bo_alloc_ioctl,
+ DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(VMW_UNREF_DMABUF, vmw_bo_unref_ioctl,
+ DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(VMW_CURSOR_BYPASS,
+ vmw_kms_cursor_bypass_ioctl,
+ DRM_MASTER),
+
+ DRM_IOCTL_DEF_DRV(VMW_CONTROL_STREAM, vmw_overlay_ioctl,
+ DRM_MASTER),
+ DRM_IOCTL_DEF_DRV(VMW_CLAIM_STREAM, vmw_stream_claim_ioctl,
+ DRM_MASTER),
+ DRM_IOCTL_DEF_DRV(VMW_UNREF_STREAM, vmw_stream_unref_ioctl,
+ DRM_MASTER),
+
+ DRM_IOCTL_DEF_DRV(VMW_CREATE_CONTEXT, vmw_context_define_ioctl,
+ DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(VMW_UNREF_CONTEXT, vmw_context_destroy_ioctl,
+ DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(VMW_CREATE_SURFACE, vmw_surface_define_ioctl,
+ DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(VMW_UNREF_SURFACE, vmw_surface_destroy_ioctl,
+ DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(VMW_REF_SURFACE, vmw_surface_reference_ioctl,
+ DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(VMW_EXECBUF, vmw_execbuf_ioctl,
+ DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(VMW_FENCE_WAIT, vmw_fence_obj_wait_ioctl,
+ DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(VMW_FENCE_SIGNALED,
+ vmw_fence_obj_signaled_ioctl,
+ DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(VMW_FENCE_UNREF, vmw_fence_obj_unref_ioctl,
+ DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(VMW_FENCE_EVENT, vmw_fenc
