Re: [PATCH v2 1/9] mm: Introduce new vm_insert_range API
On Mon, Dec 03, 2018 at 09:51:45AM +0530, Souptick Joarder wrote:
> Hi Mike,
>
> On Sun, Dec 2, 2018 at 4:43 PM Mike Rapoport wrote:
> >
> > On Sun, Dec 02, 2018 at 11:49:44AM +0530, Souptick Joarder wrote:
> > > Previouly drivers have their own way of mapping range of
> > > kernel pages/memory into user vma and this was done by
> > > invoking vm_insert_page() within a loop.
> > >
> > > As this pattern is common across different drivers, it can
> > > be generalized by creating a new function and use it across
> > > the drivers.
> > >
> > > vm_insert_range is the new API which will be used to map a
> > > range of kernel memory/pages to user vma.
> > >
> > > This API is tested by Heiko for Rockchip drm driver, on rk3188,
> > > rk3288, rk3328 and rk3399 with graphics.
> > >
> > > Signed-off-by: Souptick Joarder
> > > Reviewed-by: Matthew Wilcox
> > > Tested-by: Heiko Stuebner
> > > ---
> > > include/linux/mm_types.h | 3 +++
> > > mm/memory.c | 38 ++
> > > mm/nommu.c | 7 +++
> > > 3 files changed, 48 insertions(+)
> > >
> > > diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> > > index 5ed8f62..15ae24f 100644
> > > --- a/include/linux/mm_types.h
> > > +++ b/include/linux/mm_types.h
> > > @@ -523,6 +523,9 @@ extern void tlb_gather_mmu(struct mmu_gather *tlb,
> > > struct mm_struct *mm,
> > > extern void tlb_finish_mmu(struct mmu_gather *tlb,
> > > unsigned long start, unsigned long end);
> > >
> > > +int vm_insert_range(struct vm_area_struct *vma, unsigned long addr,
> > > + struct page **pages, unsigned long page_count);
> > > +
> >
> > This seem to belong to include/linux/mm.h, near vm_insert_page()
>
> Ok, I will change it. Apart from this change does it looks good ?
With this change you can add
Reviewed-by: Mike Rapoport
> >
> > > static inline void init_tlb_flush_pending(struct mm_struct *mm)
> > > {
> > > atomic_set(&mm->tlb_flush_pending, 0);
> > > diff --git a/mm/memory.c b/mm/memory.c
> > > index 15c417e..84ea46c 100644
> > > --- a/mm/memory.c
> > > +++ b/mm/memory.c
> > > @@ -1478,6 +1478,44 @@ static int insert_page(struct vm_area_struct *vma,
> > > unsigned long addr,
> > > }
> > >
> > > /**
> > > + * vm_insert_range - insert range of kernel pages into user vma
> > > + * @vma: user vma to map to
> > > + * @addr: target user address of this page
> > > + * @pages: pointer to array of source kernel pages
> > > + * @page_count: number of pages need to insert into user vma
> > > + *
> > > + * This allows drivers to insert range of kernel pages they've allocated
> > > + * into a user vma. This is a generic function which drivers can use
> > > + * rather than using their own way of mapping range of kernel pages into
> > > + * user vma.
> > > + *
> > > + * If we fail to insert any page into the vma, the function will return
> > > + * immediately leaving any previously-inserted pages present. Callers
> > > + * from the mmap handler may immediately return the error as their caller
> > > + * will destroy the vma, removing any successfully-inserted pages. Other
> > > + * callers should make their own arrangements for calling unmap_region().
> > > + *
> > > + * Context: Process context. Called by mmap handlers.
> > > + * Return: 0 on success and error code otherwise
> > > + */
> > > +int vm_insert_range(struct vm_area_struct *vma, unsigned long addr,
> > > + struct page **pages, unsigned long page_count)
> > > +{
> > > + unsigned long uaddr = addr;
> > > + int ret = 0, i;
> > > +
> > > + for (i = 0; i < page_count; i++) {
> > > + ret = vm_insert_page(vma, uaddr, pages[i]);
> > > + if (ret < 0)
> > > + return ret;
> > > + uaddr += PAGE_SIZE;
> > > + }
> > > +
> > > + return ret;
> > > +}
> > > +EXPORT_SYMBOL(vm_insert_range);
> > > +
> > > +/**
> > > * vm_insert_page - insert single page into user vma
> > > * @vma: user vma to map to
> > > * @addr: target user address of this page
> > > diff --git a/mm/nommu.c b/mm/nommu.c
> > > index 749276b..d6ef5c7 100644
> > > --- a/mm/nommu.c
> > > +++ b/mm/nommu.c
> > > @@ -473,6 +473,13 @@ int vm_insert_page(struct vm_area_struct *vma,
> > > unsigned long addr,
> > > }
> > > EXPORT_SYMBOL(vm_insert_page);
> > >
> > > +int vm_insert_range(struct vm_area_struct *vma, unsigned long addr,
> > > + struct page **pages, unsigned long page_count)
> > > +{
> > > + return -EINVAL;
> > > +}
> > > +EXPORT_SYMBOL(vm_insert_range);
> > > +
> > > /*
> > > * sys_brk() for the most part doesn't need the global kernel
> > > * lock, except when an application is doing something nasty
> > > --
> > > 1.9.1
> > >
> >
> > --
> > Sincerely yours,
> > Mike.
> >
>
--
Sincerely yours,
Mike.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://l
Re: [PATCH v2 1/9] mm: Introduce new vm_insert_range API
Hi Mike,
On Sun, Dec 2, 2018 at 4:43 PM Mike Rapoport wrote:
>
> On Sun, Dec 02, 2018 at 11:49:44AM +0530, Souptick Joarder wrote:
> > Previouly drivers have their own way of mapping range of
> > kernel pages/memory into user vma and this was done by
> > invoking vm_insert_page() within a loop.
> >
> > As this pattern is common across different drivers, it can
> > be generalized by creating a new function and use it across
> > the drivers.
> >
> > vm_insert_range is the new API which will be used to map a
> > range of kernel memory/pages to user vma.
> >
> > This API is tested by Heiko for Rockchip drm driver, on rk3188,
> > rk3288, rk3328 and rk3399 with graphics.
> >
> > Signed-off-by: Souptick Joarder
> > Reviewed-by: Matthew Wilcox
> > Tested-by: Heiko Stuebner
> > ---
> > include/linux/mm_types.h | 3 +++
> > mm/memory.c | 38 ++
> > mm/nommu.c | 7 +++
> > 3 files changed, 48 insertions(+)
> >
> > diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> > index 5ed8f62..15ae24f 100644
> > --- a/include/linux/mm_types.h
> > +++ b/include/linux/mm_types.h
> > @@ -523,6 +523,9 @@ extern void tlb_gather_mmu(struct mmu_gather *tlb,
> > struct mm_struct *mm,
> > extern void tlb_finish_mmu(struct mmu_gather *tlb,
> > unsigned long start, unsigned long end);
> >
> > +int vm_insert_range(struct vm_area_struct *vma, unsigned long addr,
> > + struct page **pages, unsigned long page_count);
> > +
>
> This seem to belong to include/linux/mm.h, near vm_insert_page()
Ok, I will change it. Apart from this change does it looks good ?
>
> > static inline void init_tlb_flush_pending(struct mm_struct *mm)
> > {
> > atomic_set(&mm->tlb_flush_pending, 0);
> > diff --git a/mm/memory.c b/mm/memory.c
> > index 15c417e..84ea46c 100644
> > --- a/mm/memory.c
> > +++ b/mm/memory.c
> > @@ -1478,6 +1478,44 @@ static int insert_page(struct vm_area_struct *vma,
> > unsigned long addr,
> > }
> >
> > /**
> > + * vm_insert_range - insert range of kernel pages into user vma
> > + * @vma: user vma to map to
> > + * @addr: target user address of this page
> > + * @pages: pointer to array of source kernel pages
> > + * @page_count: number of pages need to insert into user vma
> > + *
> > + * This allows drivers to insert range of kernel pages they've allocated
> > + * into a user vma. This is a generic function which drivers can use
> > + * rather than using their own way of mapping range of kernel pages into
> > + * user vma.
> > + *
> > + * If we fail to insert any page into the vma, the function will return
> > + * immediately leaving any previously-inserted pages present. Callers
> > + * from the mmap handler may immediately return the error as their caller
> > + * will destroy the vma, removing any successfully-inserted pages. Other
> > + * callers should make their own arrangements for calling unmap_region().
> > + *
> > + * Context: Process context. Called by mmap handlers.
> > + * Return: 0 on success and error code otherwise
> > + */
> > +int vm_insert_range(struct vm_area_struct *vma, unsigned long addr,
> > + struct page **pages, unsigned long page_count)
> > +{
> > + unsigned long uaddr = addr;
> > + int ret = 0, i;
> > +
> > + for (i = 0; i < page_count; i++) {
> > + ret = vm_insert_page(vma, uaddr, pages[i]);
> > + if (ret < 0)
> > + return ret;
> > + uaddr += PAGE_SIZE;
> > + }
> > +
> > + return ret;
> > +}
> > +EXPORT_SYMBOL(vm_insert_range);
> > +
> > +/**
> > * vm_insert_page - insert single page into user vma
> > * @vma: user vma to map to
> > * @addr: target user address of this page
> > diff --git a/mm/nommu.c b/mm/nommu.c
> > index 749276b..d6ef5c7 100644
> > --- a/mm/nommu.c
> > +++ b/mm/nommu.c
> > @@ -473,6 +473,13 @@ int vm_insert_page(struct vm_area_struct *vma,
> > unsigned long addr,
> > }
> > EXPORT_SYMBOL(vm_insert_page);
> >
> > +int vm_insert_range(struct vm_area_struct *vma, unsigned long addr,
> > + struct page **pages, unsigned long page_count)
> > +{
> > + return -EINVAL;
> > +}
> > +EXPORT_SYMBOL(vm_insert_range);
> > +
> > /*
> > * sys_brk() for the most part doesn't need the global kernel
> > * lock, except when an application is doing something nasty
> > --
> > 1.9.1
> >
>
> --
> Sincerely yours,
> Mike.
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/2] Two AST driver fixes
Hello, Here are two (attempted) fixes for the AST DRM driver. The issues they fix are both seen when the ast driver is unloaded (tested on Power9, although it looks like the second one is architecture independent). I'm fairly confident about the first fix, as it looks pretty straight forward. The second seems reasonable, but I don't know this area of the kernel very well. Cheers, Sam. Patch set changelog follows: Patch set v2: Patch 1/2: drm/ast: Fix incorrect free on ioregs Patch 2/2: drm/ast: Fix connector leak during driver unload * Changed to use drm_crtc_force_disable_all(). Patch set v1: Patch 1/2: drm/ast: Fix incorrect free on ioregs Patch 2/2: drm/ast: Fix connector leak during driver unload Sam Bobroff (2): drm/ast: Fix incorrect free on ioregs drm/ast: Fix connector leak during driver unload drivers/gpu/drm/ast/ast_fb.c | 1 + drivers/gpu/drm/ast/ast_main.c | 3 ++- 2 files changed, 3 insertions(+), 1 deletion(-) -- 2.19.0.2.gcad72f5712 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] udlfb: fix potential NULL pointer dereference in dlfb_usb_probe
This patch fixes a possible null pointer dereference in
dlfb_usb_probe, detected by the semantic patch deref_null.cocci,
with the following warning:
drivers/video/fbdev/udlfb.c:1704:11-15: ERROR: dlfb is NULL but dereferenced.
The following code has potential null pointer references:
1597 /* usb initialization */
1598 dlfb = kzalloc(sizeof(*dlfb), GFP_KERNEL);
1599 if (!dlfb) {
...
1601 goto error;
1602 }
...
1703 error:
1704 if (dlfb->info) {
1705 dlfb_ops_destroy(dlfb->info);
1706 } else if (dlfb) {
1707 usb_put_dev(dlfb->udev);
1708 kfree(dlfb);
1709 }
Signed-off-by: Wen Yang
CC: Bernie Thompson
CC: Bartlomiej Zolnierkiewicz
CC: linux-fb...@vger.kernel.org
CC: dri-devel@lists.freedesktop.org
CC: linux-ker...@vger.kernel.org
---
drivers/video/fbdev/udlfb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/udlfb.c b/drivers/video/fbdev/udlfb.c
index 070026a7e55a..df37cfaa2362 100644
--- a/drivers/video/fbdev/udlfb.c
+++ b/drivers/video/fbdev/udlfb.c
@@ -1701,7 +1701,7 @@ static int dlfb_usb_probe(struct usb_interface *intf,
return 0;
error:
- if (dlfb->info) {
+ if (dlfb && dlfb->info) {
dlfb_ops_destroy(dlfb->info);
} else if (dlfb) {
usb_put_dev(dlfb->udev);
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/ast: Fix connector leak during driver unload
On Fri, Nov 30, 2018 at 10:41:08AM +0100, Daniel Vetter wrote:
> On Fri, Nov 30, 2018 at 11:17:51AM +1100, Sam Bobroff wrote:
> > On Thu, Nov 29, 2018 at 09:56:53AM +0100, Daniel Vetter wrote:
> > > On Thu, Nov 29, 2018 at 9:05 AM Sam Bobroff
> > > wrote:
> > > >
> > > > On Thu, Nov 29, 2018 at 09:40:53AM +1000, Dave Airlie wrote:
> > > > > On Mon, 5 Nov 2018 at 15:59, Sam Bobroff
> > > > > wrote:
> > > > > >
> > > > > > When unloading the ast driver, a warning message is printed by
> > > > > > drm_mode_config_cleanup() because a reference is still held to one
> > > > > > of
> > > > > > the drm_connector structs.
> > > > > >
> > > > > > Correct this by calling drm_framebuffer_remove() in
> > > > > > ast_fbdev_destroy().
> > > > > >
> > > > > > Signed-off-by: Sam Bobroff
> > > > > > ---
> > > > > > drivers/gpu/drm/ast/ast_fb.c | 4
> > > > > > 1 file changed, 4 insertions(+)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/ast/ast_fb.c
> > > > > > b/drivers/gpu/drm/ast/ast_fb.c
> > > > > > index 0cd827e11fa2..655372ea81e9 100644
> > > > > > --- a/drivers/gpu/drm/ast/ast_fb.c
> > > > > > +++ b/drivers/gpu/drm/ast/ast_fb.c
> > > > > > @@ -263,6 +263,10 @@ static void ast_fbdev_destroy(struct
> > > > > > drm_device *dev,
> > > > > > {
> > > > > > struct ast_framebuffer *afb = &afbdev->afb;
> > > > > >
> > > > > > + /* drm_framebuffer_remove() expects us to hold a ref, which
> > > > > > it
> > > > > > +* will drop, so take one: */
> > > > > > + drm_framebuffer_get(&afb->base);
> > > > > > + drm_framebuffer_remove(&afb->base);
> > > > >
> > > > > This doesn't seem corret, no other driver does this pattern, and I
> > > > > can't believe ast is special here.
> > > > >
> > > > > The get just doesn't make sense.
> > > >
> > > > Thanks for having a look at this, as I said in the cover letter I was
> > > > concerned that it might not be a good fix.
> > > >
> > > > But the AST driver does seem to be special (or just old?) because it
> > > > embeds the drm_framebuffer directly into ast_fbdev and (almost all)
> > > > other drivers dynamically allocate and reference count theirs.
> > > >
> > > > The drm_framebuffer_get() certainly looks weird but it is there in order
> > > > to cause drm_framebuffer_remove() to call legacy_remove_fb(), which it
> > > > won't do unless the refcount is at least 2. (And because the
> > > > drm_framebuffer isn't dynamically allocated in this case we don't really
> > > > care about the reference count anyway.)
> > > >
> > > > An alternative might be to call legacy_remove_fb() directly, but it's
> > > > declared static. Do you think it would be better to expose it and call
> > > > it directly from the AST driver code? Or is there some other better way
> > > > to put the drm_connectors?
> > >
> > > Your problem isn't the dynamic fb vs. embedded fb for fbdev (you're
> > > already using drm_framebuffer_unregister_private to handle that). Your
> > > problem is you're not shutting down stuff on driver unload, which
> > > means the fb is still in use. drm_atomic_helper_shutdown() takes care
> > > of that for atomic drivers.
> > >
> > > No idea anymore what to do for legacy code, probably need to open code
> > > a shutdown sequence. Definitely not the above.
> > > -Daniel
> >
> > Well, it looks like drm_crtc_force_disable_all() would also do the job,
> > and from looking at nouveau_display_fini() it's used there as an
> > alternative to drm_atomic_helper_shutdown().
>
> Ah right, I tried looking for that one but didn't find it with a quick
> scan.
>
> > Would it be reasonable to call that at the start of
> > ast_fbdev_destroy() instead? (Testing shows that it does allow the
> > drm_connector to be released. Is it enough/correct though?)
>
> Yes.
> -Daniel
Great, I'll post a v2 with that change.
Cheers,
Sam.
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amdgpu: NULL check before some freeing functions is not needed.
NULL check before some freeing functions is not needed.
Signed-off-by: Thomas Meyer
---
diff -u -p a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
@@ -816,6 +816,5 @@ out:
void amdgpu_acpi_fini(struct amdgpu_device *adev)
{
unregister_acpi_notifier(&adev->acpi_nb);
- if (adev->atif)
- kfree(adev->atif);
+ kfree(adev->atif);
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/2] drm/ast: Fix connector leak during driver unload
When unloading the ast driver, a warning message is printed by
drm_mode_config_cleanup() because a reference is still held to one of
the drm_connector structs.
Correct this by calling drm_crtc_force_disable_all() in
ast_fbdev_destroy().
Signed-off-by: Sam Bobroff
---
v2 * Changed to use drm_crtc_force_disable_all().
drivers/gpu/drm/ast/ast_fb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/ast/ast_fb.c b/drivers/gpu/drm/ast/ast_fb.c
index 0cd827e11fa2..de26df0c6044 100644
--- a/drivers/gpu/drm/ast/ast_fb.c
+++ b/drivers/gpu/drm/ast/ast_fb.c
@@ -263,6 +263,7 @@ static void ast_fbdev_destroy(struct drm_device *dev,
{
struct ast_framebuffer *afb = &afbdev->afb;
+ drm_crtc_force_disable_all(dev);
drm_fb_helper_unregister_fbi(&afbdev->helper);
if (afb->obj) {
--
2.19.0.2.gcad72f5712
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/2] drm/ast: Fix incorrect free on ioregs
If the platform has no IO space, ioregs is placed next to the already
allocated regs. In this case, it should not be separately freed.
This prevents a kernel warning from __vunmap "Trying to vfree()
nonexistent vm area" when unloading the driver.
Fixes: 0dd68309b9c5 ("drm/ast: Try to use MMIO registers when PIO isn't
supported")
Signed-off-by: Sam Bobroff
---
drivers/gpu/drm/ast/ast_main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
index dac355812adc..373700c05a00 100644
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -583,7 +583,8 @@ void ast_driver_unload(struct drm_device *dev)
drm_mode_config_cleanup(dev);
ast_mm_fini(ast);
- pci_iounmap(dev->pdev, ast->ioregs);
+ if (ast->ioregs != ast->regs + AST_IO_MM_OFFSET)
+ pci_iounmap(dev->pdev, ast->ioregs);
pci_iounmap(dev->pdev, ast->regs);
kfree(ast);
}
--
2.19.0.2.gcad72f5712
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] fbdev: fsl-diu: remove redundant null check on cmap
The null check on &info->cmap is redundant since cmap is a struct inside fb_info and can never be null, so the check is always true. we may remove it. Signed-off-by: Wen Yang CC: Timur Tabi CC: Bartlomiej Zolnierkiewicz CC: linux-fb...@vger.kernel.org CC: dri-devel@lists.freedesktop.org CC: linux-ker...@vger.kernel.org --- drivers/video/fbdev/fsl-diu-fb.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/video/fbdev/fsl-diu-fb.c b/drivers/video/fbdev/fsl-diu-fb.c index 332a56b6811f..9a5451ba4d44 100644 --- a/drivers/video/fbdev/fsl-diu-fb.c +++ b/drivers/video/fbdev/fsl-diu-fb.c @@ -1575,8 +1575,7 @@ static void uninstall_fb(struct fb_info *info) unregister_framebuffer(info); unmap_video_memory(info); - if (&info->cmap) - fb_dealloc_cmap(&info->cmap); + fb_dealloc_cmap(&info->cmap); mfbi->registered = 0; } -- 2.19.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 198669] Driver crash at radeon_ring_backup+0xd3/0x140 [radeon]
https://bugzilla.kernel.org/show_bug.cgi?id=198669 --- Comment #15 from ro...@beardandsandals.co.uk (ro...@beardandsandals.co.uk) --- For information. I enventually tracked the hardware fault to bad solder flow in the area of the dvi-d socket. I still stick by my original comments about usability. To me an outcome of a recovery process that will leave 99.9% of end users clueless of how to safely restart their system is not a good outcome from an end user perspective. This is my last word on this topic. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 198669] Driver crash at radeon_ring_backup+0xd3/0x140 [radeon]
https://bugzilla.kernel.org/show_bug.cgi?id=198669 ro...@beardandsandals.co.uk (ro...@beardandsandals.co.uk) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |OBSOLETE -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108917] gamma adjustments cause stuttering with amdgpu.dc=1, especially problematic with RedShift etc.
https://bugs.freedesktop.org/show_bug.cgi?id=108917 --- Comment #3 from tempel.jul...@gmail.com --- (In reply to Alex Deucher from comment #2) > Possibly the same issue as bug 106175. Do you suspect the mouse cursor issue? That's not the case here: The gamma adjustment stutter also occurs without vsync or any other fullscreen vsync application running. I will give a Wayland session a try this evening. Wouldn't be surprised if this issue is completely unrelated to Xorg specific things. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 1/4] drm/panel: simple: Add AUO G101EVN010 panel support
On Tue, Oct 30, 2018 at 11:05:19PM +, Rob Herring wrote: >On Thu, 25 Oct 2018 17:09:30 +0200, Alex Gonzalez wrote: >> The change adds support for the AU Optronics G101EVN010 10.1" TFT LCD >> panel. >> >> Signed-off-by: Alex Gonzalez >> --- >> .../bindings/display/panel/auo,g101evn010 | 12 ++ >> drivers/gpu/drm/panel/panel-simple.c | 27 >> ++ >> 2 files changed, 39 insertions(+) >> create mode 100644 >> Documentation/devicetree/bindings/display/panel/auo,g101evn010 >> > >Reviewed-by: Rob Herring Ping? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108689] new version of intel_gpu_top lost option of output log to stdio or file
https://bugs.freedesktop.org/show_bug.cgi?id=108689 Tvrtko Ursulin changed: What|Removed |Added Priority|medium |low Severity|major |enhancement Status|NEEDINFO|NEW Whiteboard||ReadyForDev --- Comment #4 from Tvrtko Ursulin --- Sorry it slipped from my radar. We could add some form of non-interactive stdio output I guess, shouldn't be too difficult. Will see how it fits against the higher priority work. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [alsa-devel] [Xen-devel][PATCH v2 3/3] ALSA: xen-front: Use Xen common shared buffer implementation
On Fri, 30 Nov 2018 08:42:05 +0100, Oleksandr Andrushchenko wrote: > > From: Oleksandr Andrushchenko > > Use page directory based shared buffer implementation > now available as common code for Xen frontend drivers. > > Signed-off-by: Oleksandr Andrushchenko For the sound bits, Reviewed-by: Takashi Iwai I suppose the whole patchset will be taken through xen or other tree? thanks, Takashi ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [alsa-devel] [Xen-devel][PATCH v2 3/3] ALSA: xen-front: Use Xen common shared buffer implementation
On 12/3/18 11:36 AM, Takashi Iwai wrote: On Fri, 30 Nov 2018 08:42:05 +0100, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko Use page directory based shared buffer implementation now available as common code for Xen frontend drivers. Signed-off-by: Oleksandr Andrushchenko For the sound bits, Reviewed-by: Takashi Iwai Thank you I suppose the whole patchset will be taken through xen or other tree? Xen tree thanks, Takashi Thank you, Oleksandr ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm_gem_get_pages and proper flushing/coherency
On 11/26/18 2:15 PM, Oleksandr Andrushchenko wrote: Hello, all! My driver (Xen para-virtualized frontend) in some scenarios uses drm_gem_get_pages for allocating backing storage for dumb buffers. There are use-cases which showed some artifacts on the screen (modetest, other) which were worked around by flushing pages of the buffer on page flip with drm_clflush_pages. But, the problem here is that drm_clflush_pages is not available on ARM platforms (it is a NOP) and doing flushes on every page flip seems to be non-optimal. Other drivers that use drm_gem_get_pages seem to use DMA map/unmap on the shmem backed buffer (this is from where drm_gem_get_pages allocates the pages) and this is an obvious approach as the buffer needs to be shared with real HW for DMA - please correct me if my understanding here is wrong. I have created a patch which implements DMA mapping [1] and this does solve artifacts problem for me. Is this the right way to go? This is the part I missed in my implementation as I don't really have a HW device which needs DMA, but a backend running in a different Xen domain. Thus, as the buffer is backed with cachable pages the backend may see artifacts on its side. I am looking for some advices on what would be the best option to make sure dumb buffers are not flushed every page flip and still the memory remains coherent to the backend. I have implemented a DMA map/unmap of the shmem pages on GEM object creation/destruction and this does solve the problem, but as the backend is not really a DMA device this is a bit misleading. Is there any other (more?) suitable/preferable way(s) to achieve the same? Thank you, Oleksandr Thank you, Oleksandr [1] https://patchwork.freedesktop.org/series/53069/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108917] gamma adjustments cause stuttering with amdgpu.dc=1, especially problematic with RedShift etc.
https://bugs.freedesktop.org/show_bug.cgi?id=108917 Michel Dänzer changed: What|Removed |Added Attachment #142686|text/x-log |text/plain mime type|| -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108917] gamma adjustments cause stuttering with amdgpu.dc=1, especially problematic with RedShift etc.
https://bugs.freedesktop.org/show_bug.cgi?id=108917 Michel Dänzer changed: What|Removed |Added Attachment #142685|text/x-log |text/plain mime type|| -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/imx: ipuv3-plane: add zpos property
Add a zpos property to planes. Call drm_atomic_helper_check() instead of
calling drm_atomic_helper_check_modeset() and drm_atomic_check_planes()
manually. This effectively adds a call to drm_atoimic_normalize_zpos()
before checking planes. Reorder atomic update to allow changing plane
zpos without modeset.
Note that the initial zpos is set in ipu_plane_state_reset(). The
initial value set in ipu_plane_init() is just for show. The zpos
parameter of drm_plane_create_zpos_property() is ignored because
the newly created plane do not have state yet.
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/imx/imx-drm-core.c | 7 ++--
drivers/gpu/drm/imx/ipuv3-plane.c | 56 +-
2 files changed, 33 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/imx/imx-drm-core.c
b/drivers/gpu/drm/imx/imx-drm-core.c
index 820c7e3878f0..687cfb9d410e 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -49,11 +49,7 @@ static int imx_drm_atomic_check(struct drm_device *dev,
{
int ret;
- ret = drm_atomic_helper_check_modeset(dev, state);
- if (ret)
- return ret;
-
- ret = drm_atomic_helper_check_planes(dev, state);
+ ret = drm_atomic_helper_check(dev, state);
if (ret)
return ret;
@@ -229,6 +225,7 @@ static int imx_drm_bind(struct device *dev)
drm->mode_config.funcs = &imx_drm_mode_config_funcs;
drm->mode_config.helper_private = &imx_drm_mode_config_helpers;
drm->mode_config.allow_fb_modifiers = true;
+ drm->mode_config.normalize_zpos = true;
drm_mode_config_init(drm);
diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c
b/drivers/gpu/drm/imx/ipuv3-plane.c
index d6d9ab5b33db..508ce655d638 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -273,6 +273,7 @@ static void ipu_plane_destroy(struct drm_plane *plane)
static void ipu_plane_state_reset(struct drm_plane *plane)
{
+ unsigned int zpos = (plane->type == DRM_PLANE_TYPE_PRIMARY) ? 0 : 1;
struct ipu_plane_state *ipu_state;
if (plane->state) {
@@ -284,8 +285,11 @@ static void ipu_plane_state_reset(struct drm_plane *plane)
ipu_state = kzalloc(sizeof(*ipu_state), GFP_KERNEL);
- if (ipu_state)
+ if (ipu_state) {
__drm_atomic_helper_plane_reset(plane, &ipu_state->base);
+ ipu_state->base.zpos = zpos;
+ ipu_state->base.normalized_zpos = zpos;
+ }
}
static struct drm_plane_state *
@@ -560,6 +564,25 @@ static void ipu_plane_atomic_update(struct drm_plane
*plane,
if (ipu_plane->dp_flow == IPU_DP_FLOW_SYNC_FG)
ipu_dp_set_window_pos(ipu_plane->dp, dst->x1, dst->y1);
+ switch (ipu_plane->dp_flow) {
+ case IPU_DP_FLOW_SYNC_BG:
+ if (state->normalized_zpos == 1) {
+ ipu_dp_set_global_alpha(ipu_plane->dp,
+ !fb->format->has_alpha, 0xff,
+ true);
+ } else {
+ ipu_dp_set_global_alpha(ipu_plane->dp, true, 0, true);
+ }
+ break;
+ case IPU_DP_FLOW_SYNC_FG:
+ if (state->normalized_zpos == 1) {
+ ipu_dp_set_global_alpha(ipu_plane->dp,
+ !fb->format->has_alpha, 0xff,
+ false);
+ }
+ break;
+ }
+
eba = drm_plane_state_to_eba(state, 0);
/*
@@ -596,34 +619,11 @@ static void ipu_plane_atomic_update(struct drm_plane
*plane,
switch (ipu_plane->dp_flow) {
case IPU_DP_FLOW_SYNC_BG:
ipu_dp_setup_channel(ipu_plane->dp, ics, IPUV3_COLORSPACE_RGB);
- ipu_dp_set_global_alpha(ipu_plane->dp, true, 0, true);
break;
case IPU_DP_FLOW_SYNC_FG:
ipu_dp_setup_channel(ipu_plane->dp, ics,
IPUV3_COLORSPACE_UNKNOWN);
- /* Enable local alpha on partial plane */
- switch (fb->format->format) {
- case DRM_FORMAT_ARGB1555:
- case DRM_FORMAT_ABGR1555:
- case DRM_FORMAT_RGBA5551:
- case DRM_FORMAT_BGRA5551:
- case DRM_FORMAT_ARGB:
- case DRM_FORMAT_ARGB:
- case DRM_FORMAT_ABGR:
- case DRM_FORMAT_RGBA:
- case DRM_FORMAT_BGRA:
- case DRM_FORMAT_RGB565_A8:
- case DRM_FORMAT_BGR565_A8:
- case DRM_FORMAT_RGB888_A8:
- case DRM_FORMAT_BGR888_A8:
- case DRM_FORMAT_RGBX_A8:
- case DRM_FORMAT_BGRX_A8:
- ipu_dp_set_global_alpha(ipu_plane->dp, false, 0, false);
- break;
-
Re: [PATCH 0/4] HDCP1.4 fixes
Sean and Daniel, Could you please help me with the review these changes? --Ram On 11/27/2018 7:32 PM, Ramalingam C wrote: Couple of more HDCP1.4 fixes on - Key load process for CFL - Encryption status change time - debug log addition - active platform coverage Ramalingam C (4): drm/i915: Fix GEN9 HDCP1.4 key load process drm/i915: Fix platform coverage for HDCP1.4 drm/i915: debug log for REPLY_ACK missing drm/i915: Increase timeout for Encrypt status change drivers/gpu/drm/i915/intel_dp.c | 6 +- drivers/gpu/drm/i915/intel_hdcp.c | 17 ++--- 2 files changed, 15 insertions(+), 8 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/meson: Fix an Alpha Primary Plane bug on Meson GXL/GXM SoCs
On 03/12/2018 10:04, Maxime Jourdan wrote: > Hi Neil, > On Wed, Nov 28, 2018 at 11:07 AM Neil Armstrong > wrote: >> >> On the Amlogic GXL & GXM SoCs, a bug occurs on the primary plane when >> alpha is used where the alpha is not aligned with the pixel content. >> >> The woraround Amlogic implemented is to reset the OSD1 plane hardware >> block each time the plane is (re)enabled, solving the issue. >> > > typo: woraround -> workaround I'll fix when applying ! > >> In the reset, we still need to save the content of 2 registers which >> depends on the status of the plane, in addition to reload the scaler >> conversion matrix at the same time. >> >> Signed-off-by: Neil Armstrong >> --- >> Changes since v1 at [1]: >> - Fix flickering and shaking by moving reset when plane is disabled >> >> [1] https://patchwork.freedesktop.org/patch/263550/ >> >> drivers/gpu/drm/meson/meson_plane.c | 12 >> drivers/gpu/drm/meson/meson_viu.c | 27 +++ >> drivers/gpu/drm/meson/meson_viu.h | 1 + >> 3 files changed, 40 insertions(+) >> > > I can confirm the fix works on GXL (aml-s905x-cc), tested with > LibreElec, 1080p resolution. > > Anything using alpha on the primary plane used to be randomly > "shifted" with black patches, and this was particularly visible with > subtitles. > > Things seem OK now. Thanks! > > Tested-by: Maxime Jourdan > Reviewed-by: Maxime Jourdan > Thanks, Applied on drm-misc-next Neil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 02/11] dma-buf: add new dma_fence_chain container v2
Am 03.12.18 um 06:25 schrieb zhoucm1:
On 2018年11月28日 22:50, Christian König wrote:
Lockless container implementation similar to a dma_fence_array, but with
only two elements per node and automatic garbage collection.
v2: properly document dma_fence_chain_for_each, add
dma_fence_chain_find_seqno,
drop prev reference during garbage collection if it's not a
chain fence.
Signed-off-by: Christian König
---
drivers/dma-buf/Makefile | 3 +-
drivers/dma-buf/dma-fence-chain.c | 235
++
include/linux/dma-fence-chain.h | 79 +
3 files changed, 316 insertions(+), 1 deletion(-)
create mode 100644 drivers/dma-buf/dma-fence-chain.c
create mode 100644 include/linux/dma-fence-chain.h
diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile
index 0913a6ccab5a..1f006e083eb9 100644
--- a/drivers/dma-buf/Makefile
+++ b/drivers/dma-buf/Makefile
@@ -1,4 +1,5 @@
-obj-y := dma-buf.o dma-fence.o dma-fence-array.o reservation.o
seqno-fence.o
+obj-y := dma-buf.o dma-fence.o dma-fence-array.o dma-fence-chain.o \
+ reservation.o seqno-fence.o
obj-$(CONFIG_SYNC_FILE) += sync_file.o
obj-$(CONFIG_SW_SYNC) += sw_sync.o sync_debug.o
obj-$(CONFIG_UDMABUF) += udmabuf.o
diff --git a/drivers/dma-buf/dma-fence-chain.c
b/drivers/dma-buf/dma-fence-chain.c
new file mode 100644
index ..de05101fc48d
--- /dev/null
+++ b/drivers/dma-buf/dma-fence-chain.c
@@ -0,0 +1,235 @@
+/*
+ * fence-chain: chain fences together in a timeline
+ *
+ * Copyright (C) 2018 Advanced Micro Devices, Inc.
+ * Authors:
+ * Christian König
+ *
+ * This program is free software; you can redistribute it and/or
modify it
+ * under the terms of the GNU General Public License version 2 as
published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public
License for
+ * more details.
+ */
+
+#include
+
+static bool dma_fence_chain_enable_signaling(struct dma_fence *fence);
+
+/**
+ * dma_fence_chain_get_prev - use RCU to get a reference to the
previous fence
+ * @chain: chain node to get the previous node from
+ *
+ * Use dma_fence_get_rcu_safe to get a reference to the previous
fence of the
+ * chain node.
+ */
+static struct dma_fence *dma_fence_chain_get_prev(struct
dma_fence_chain *chain)
+{
+ struct dma_fence *prev;
+
+ rcu_read_lock();
+ prev = dma_fence_get_rcu_safe(&chain->prev);
+ rcu_read_unlock();
+ return prev;
+}
+
+/**
+ * dma_fence_chain_walk - chain walking function
+ * @fence: current chain node
+ *
+ * Walk the chain to the next node. Returns the next fence or NULL
if we are at
+ * the end of the chain. Garbage collects chain nodes which are already
+ * signaled.
+ */
+struct dma_fence *dma_fence_chain_walk(struct dma_fence *fence)
+{
+ struct dma_fence_chain *chain, *prev_chain;
+ struct dma_fence *prev, *replacement, *tmp;
+
+ chain = to_dma_fence_chain(fence);
+ if (!chain) {
+ dma_fence_put(fence);
+ return NULL;
+ }
+
+ while ((prev = dma_fence_chain_get_prev(chain))) {
+
+ prev_chain = to_dma_fence_chain(prev);
+ if (prev_chain) {
+ if (!dma_fence_is_signaled(prev_chain->fence))
+ break;
+
+ replacement = dma_fence_chain_get_prev(prev_chain);
+ } else {
+ if (!dma_fence_is_signaled(prev))
+ break;
+
+ replacement = NULL;
+ }
+
+ tmp = cmpxchg(&chain->prev, prev, replacement);
+ if (tmp == prev)
+ dma_fence_put(tmp);
+ else
+ dma_fence_put(replacement);
+ dma_fence_put(prev);
+ }
+
+ dma_fence_put(fence);
+ return prev;
+}
+EXPORT_SYMBOL(dma_fence_chain_walk);
+
+/**
+ * dma_fence_chain_find_seqno - find fence chain node by seqno
+ * @pfence: pointer to the chain node where to start
+ * @seqno: the sequence number to search for
+ *
+ * Advance the fence pointer to the chain node which will signal
this sequence
+ * number. If no sequence number is provided then this is a no-op.
+ *
+ * Returns EINVAL if the fence is not a chain node or the sequence
number has
+ * not yet advanced far enough.
+ */
+int dma_fence_chain_find_seqno(struct dma_fence **pfence, uint64_t
seqno)
+{
+ struct dma_fence_chain *chain;
+
+ if (!seqno)
+ return 0;
+
+ chain = to_dma_fence_chain(*pfence);
+ if (!chain || chain->base.seqno < seqno)
+ return -EINVAL;
+
+ dma_fence_chain_for_each(*pfence) {
+ if ((*pfence)->context != chain->base.context ||
+ to_dma_fence_chain(*pfence)->prev_seqno < seqno)
+ break;
+ }
+ dma_fence_put(&chain->base);
+
+ return 0;
+}
+EXPORT_SYMBOL(dma_fence_chain_find_seqno);
+
+static const char *dma_fence_chain_get_driver
Re: [PATCH] of/device: add blacklist for iommu dma_ops
Hi Tomasz,
On 2018-12-03 01:10, Tomasz Figa wrote:
> On Sat, Dec 1, 2018 at 8:54 AM Rob Clark wrote:
>> This solves a problem we see with drm/msm, caused by getting
>> iommu_dma_ops while we attach our own domain and manage it directly at
>> the iommu API level:
>>
>> [0038] user address but active_mm is swapper
>> Internal error: Oops: 9605 [#1] PREEMPT SMP
>> Modules linked in:
>> CPU: 7 PID: 70 Comm: kworker/7:1 Tainted: GW 4.19.3 #90
>> Hardware name: xxx (DT)
>> Workqueue: events deferred_probe_work_func
>> pstate: 80c9 (Nzcv daif +PAN +UAO)
>> pc : iommu_dma_map_sg+0x7c/0x2c8
>> lr : iommu_dma_map_sg+0x40/0x2c8
>> sp : ff80095eb4f0
>> x29: ff80095eb4f0 x28:
>> x27: ffc0f9431578 x26:
>> x25: x24: 0003
>> x23: 0001 x22: ffc0fa9ac010
>> x21: x20: ffc0fab40980
>> x19: ffc0fab40980 x18: 0003
>> x17: 01c4 x16: 0007
>> x15: 000e x14:
>> x13: x12: 0028
>> x11: 0101010101010101 x10: 7f7f7f7f7f7f7f7f
>> x9 : x8 : ffc0fab409a0
>> x7 : x6 : 0002
>> x5 : 0001 x4 :
>> x3 : 0001 x2 : 0002
>> x1 : ffc0f9431578 x0 :
>> Process kworker/7:1 (pid: 70, stack limit = 0x17d08ffb)
>> Call trace:
>>iommu_dma_map_sg+0x7c/0x2c8
>>__iommu_map_sg_attrs+0x70/0x84
>>get_pages+0x170/0x1e8
>>msm_gem_get_iova+0x8c/0x128
>>_msm_gem_kernel_new+0x6c/0xc8
>>msm_gem_kernel_new+0x4c/0x58
>>dsi_tx_buf_alloc_6g+0x4c/0x8c
>>msm_dsi_host_modeset_init+0xc8/0x108
>>msm_dsi_modeset_init+0x54/0x18c
>>_dpu_kms_drm_obj_init+0x430/0x474
>>dpu_kms_hw_init+0x5f8/0x6b4
>>msm_drm_bind+0x360/0x6c8
>>try_to_bring_up_master.part.7+0x28/0x70
>>component_master_add_with_match+0xe8/0x124
>>msm_pdev_probe+0x294/0x2b4
>>platform_drv_probe+0x58/0xa4
>>really_probe+0x150/0x294
>>driver_probe_device+0xac/0xe8
>>__device_attach_driver+0xa4/0xb4
>>bus_for_each_drv+0x98/0xc8
>>__device_attach+0xac/0x12c
>>device_initial_probe+0x24/0x30
>>bus_probe_device+0x38/0x98
>>deferred_probe_work_func+0x78/0xa4
>>process_one_work+0x24c/0x3dc
>>worker_thread+0x280/0x360
>>kthread+0x134/0x13c
>>ret_from_fork+0x10/0x18
>> Code: d284 91000725 6b17039f 5400048a (f9401f40)
>> ---[ end trace f22dda57f3648e2c ]---
>> Kernel panic - not syncing: Fatal exception
>> SMP: stopping secondary CPUs
>> Kernel Offset: disabled
>> CPU features: 0x0,22802a18
>> Memory Limit: none
>>
>> The problem is that when drm/msm does it's own iommu_attach_device(),
>> now the domain returned by iommu_get_domain_for_dev() is drm/msm's
>> domain, and it doesn't have domain->iova_cookie.
>>
>> We kind of avoided this problem prior to sdm845/dpu because the iommu
>> was attached to the mdp node in dt, which is a child of the toplevel
>> mdss node (which corresponds to the dev passed in dma_map_sg()). But
>> with sdm845, now the iommu is attached at the mdss level so we hit the
>> iommu_dma_ops in dma_map_sg().
>>
>> But auto allocating/attaching a domain before the driver is probed was
>> already a blocking problem for enabling per-context pagetables for the
>> GPU. This problem is also now solved with this patch.
>>
>> Fixes: 97890ba9289c dma-mapping: detect and configure IOMMU in
>> of_dma_configure
>> Tested-by: Douglas Anderson
>> Signed-off-by: Rob Clark
>> ---
>> This is an alternative/replacement for [1]. What it lacks in elegance
>> it makes up for in practicality ;-)
>>
>> [1] https://patchwork.freedesktop.org/patch/264930/
>>
>> drivers/of/device.c | 22 ++
>> 1 file changed, 22 insertions(+)
>>
>> diff --git a/drivers/of/device.c b/drivers/of/device.c
>> index 5957cd4fa262..15ffee00fb22 100644
>> --- a/drivers/of/device.c
>> +++ b/drivers/of/device.c
>> @@ -72,6 +72,14 @@ int of_device_add(struct platform_device *ofdev)
>> return device_add(&ofdev->dev);
>> }
>>
>> +static const struct of_device_id iommu_blacklist[] = {
>> + { .compatible = "qcom,mdp4" },
>> + { .compatible = "qcom,mdss" },
>> + { .compatible = "qcom,sdm845-mdss" },
>> + { .compatible = "qcom,adreno" },
>> + {}
>> +};
>> +
>> /**
>> * of_dma_configure - Setup DMA configuration
>> * @dev: Device to apply DMA configuration
>> @@ -164,6 +172,20 @@ int of_dma_configure(struct device *dev, struct
>> device_node *np, bool force_dma)
>> dev_dbg(dev, "device is%sbehind an iommu\n",
>> iommu ? " " : " not ");
>>
>> + /*
>> +* There is at least one case where the driver wants to directly
>> +* manage the IOMMU, but if we end up with iommu dma_ops, that
>> +* int
[GIT PULL] drm/imx: update image-convert with fixes for multi-tiled scaling
Hi Dave, please consider merging this update for the ipu-v3 mem2mem image conversion code together with a few small cleanups and fixes. regards Philipp The following changes since commit 651022382c7f8da46cb4872a545ee1da6d097d2a: Linux 4.20-rc1 (2018-11-04 15:37:52 -0800) are available in the Git repository at: git://git.pengutronix.de/git/pza/linux.git tags/imx-drm-next-2018-12-03 for you to fetch changes up to 97c78f4d07e5033717c08b650462b3087ecfe8e8: drm/imx: ipuv3-plane: add IDMAC timeout warning (2018-11-05 14:56:04 +0100) drm/imx: update image-convert with fixes for multi-tiled scaling Update the ipu-v3 mem2mem image-convert code, with some fixes for race conditions, alignment issues, and visual artifacts due to tile alignment and scaling factor issues when scaling images larger than hardware limitations in multiple tiles. This will allow the V4L2 mem2mem scaler driver to write output images larger than 1024x1024 pixels. Also switch drm/imx source files to SPDX license identifiers, constify struct clk_ops in imx-tve, and add a timeout warning to the busy wait in ipu_plane_disable(). Fabio Estevam (1): drm/imx: Switch to SPDX identifier Julia Lawall (1): drm/imx: imx-tve: constify clk_ops structure Philipp Zabel (15): gpu: ipu-v3: ipu-ic: allow to manually set resize coefficients gpu: ipu-v3: image-convert: prepare for per-tile configuration gpu: ipu-v3: image-convert: calculate per-tile resize coefficients gpu: ipu-v3: image-convert: reconfigure IC per tile gpu: ipu-v3: image-convert: store tile top/left position gpu: ipu-v3: image-convert: calculate tile dimensions and offsets outside fill_image gpu: ipu-v3: image-convert: move tile alignment helpers gpu: ipu-v3: image-convert: select optimal seam positions gpu: ipu-v3: image-convert: fix debug output for varying tile sizes gpu: ipu-v3: image-convert: relax alignment restrictions gpu: ipu-v3: image-convert: fix bytesperline adjustment gpu: ipu-v3: image-convert: add some ASCII art to the exposition gpu: ipu-v3: image-convert: disable double buffering if necessary gpu: ipu-v3: image-convert: allow three rows or columns drm/imx: ipuv3-plane: add IDMAC timeout warning Steve Longerbeam (7): gpu: ipu-cpmem: add WARN_ON_ONCE() for unaligned dma buffers gpu: ipu-v3: Add chroma plane offset overrides to ipu_cpmem_set_image() gpu: ipu-v3: image-convert: Prevent race between run and unprepare gpu: ipu-v3: image-convert: Only wait for abort completion if active run gpu: ipu-v3: image-convert: Allow reentrancy into abort gpu: ipu-v3: image-convert: Remove need_abort flag gpu: ipu-v3: image-convert: Catch unaligned tile offsets drivers/gpu/drm/imx/dw_hdmi-imx.c |5 +- drivers/gpu/drm/imx/imx-drm-core.c | 11 +- drivers/gpu/drm/imx/imx-ldb.c | 10 +- drivers/gpu/drm/imx/imx-tve.c | 12 +- drivers/gpu/drm/imx/ipuv3-crtc.c | 10 +- drivers/gpu/drm/imx/ipuv3-plane.c | 18 +- drivers/gpu/drm/imx/parallel-display.c | 10 +- drivers/gpu/ipu-v3/ipu-cpmem.c | 52 +++-- drivers/gpu/ipu-v3/ipu-ic.c| 52 +++-- drivers/gpu/ipu-v3/ipu-image-convert.c | 1019 ++ include/video/imx-ipu-v3.h |9 + 11 files changed, 940 insertions(+), 268 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 198669] Driver crash at radeon_ring_backup+0xd3/0x140 [radeon]
https://bugzilla.kernel.org/show_bug.cgi?id=198669 --- Comment #16 from Christian König (christian.koe...@amd.com) --- (In reply to Dave Airlie from comment #14) > Should we at least push this patch to improve resiliance a little? We could, but I don't see much value in that. E.g. we would need to code the software in a way which also works if the hardware is damaged. That is possible, but I grepped a bit over the source and in this particular case we would need to manually audit 2201 registers accesses so that they also work when the hardware suddenly goes up in flames. That is totally unrealistic and just fixing this one case doesn't gives us much. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v2, 1/8] drm: Add optional COLOR_ENCODING and COLOR_RANGE properties to drm_plane
On 30.11.2018 15:48, Hans Verkuil wrote: > On 11/30/18 15:29, Ville Syrjälä wrote: >> On Fri, Nov 30, 2018 at 03:20:59PM +0100, Andrzej Hajda wrote: >>> Hi Ville, >>> >>> As Christoph cannot respond till middle next week I can try to respond >>> in his absence, as I am familiar with the subject. >>> >>> On 30.11.2018 14:25, Ville Syrjälä wrote: On Fri, Nov 30, 2018 at 02:08:11PM +0100, Christoph Manszewski wrote: > Hi, > > I am looking for a way to export the color encoding and range selection > to user space. I came across those properties and am wondering, why > they are meant only for non RGB color encodings. Would it be okay, to > modify them and use with RGB formats as well? What you trying to do? Input limited range RGB data and expand to full range? >>> >>> For example. But there are two more general questions, which >>> surprisingly we have not found answer for. >>> >>> 1. What color encoding and range drm should expect on its input RGB >>> buffers by default? >> RGB is just RGB. There is no encoding. OK, Now I see I have confused encoding with colorspace, Hans thanks for the documentation. As I understand drm by default should expect sRGB colorspace, also for Y'CbCr buffers, and currently there are no standard ways to specify buffer colorspace. Looking at current users of drm_plane_create_color_properties for Y'CbCr buffers it seems default range should be LIMITED. But default encoding is different: mali, armada, nouveau use DRM_COLOR_YCBCR_BT601, i915 uses DRM_COLOR_YCBCR_BT709 - shouldn't this be somehow standardized? What I still do not understand is colorspace conversion(not encoding!) - between pipeline input (framebuffers) and output (HDMI connector for example): 1. Since sRGB, SMPTE170M/BT.601, BT.709 colorspaces are 'almost identical in coverage' (according to wikipedia[1]) no colorspace conversion is performed at all. 2. It is performed somewhere by HW, just my IP documentation is not clear about it. Another thing which still bothers me is RGB range in case of HDMI - CEA-861 expects than on CEA modes limited RGB range should be sent, but the pipeline on the particular hardware I have do not perform any conversion of input buffers. So only limited range RGB buffers are displayed correctly. In such case property describing plane with limited RGB would be useful. [1]: https://en.wikipedia.org/wiki/Rec._709#Primary_chromaticities > It's assumed to be full range >> because no one really uses anything else. > For simple desktop usage that's true. When dealing with video inputs, > this becomes much more complicated. As I said earlier there are cases where output stream should be limited RGB, and no conversion in pipeline - thus framebuffers also should be 'limited RGB'. Regards Andrzej > >>> 2. How userspace should inform drm that given buffer has specified >>> non-default color encoding and range? >>> >>> >>> Hopefully this patch introduces such properties but only for YCbCr >>> formats, the question is what should be the best way to expand it to RGB >>> formats: >>> >>> A. Add another enums: DRM_COLOR_RGB_BT601 and friends. >> BT.601 specifies how to encoder RGB data as YCbCr. So without >> YCbCr BT.601 does not mean anything. Well, the standard does >> contain other things as well I suppose, but for the purposes >> of the color encoding prop only that one part is relevant. > Ah, I misunderstood the meaning of DRM_COLOR_RGB_BT601. > This is the equivalent of V4L2_YCBCR_ENC_601, and that's indeed > only defined for Y'CbCr. But it is often (ab)used as an alias for > the SMPTE170M colorspace (used by SDTV). > > V4L2 has the following defines for colorspaces, transfer functions, > Y'CbCr (and HSV) encodings and quantization ranges: > > https://hverkuil.home.xs4all.nl/spec/uapi/v4l/colorspaces-defs.html > > Missing in this list is the color encoding (RGB vs YCbCr vs HSV) which > is set through the pixelformat fourcc. > > And indeed, we don't have an RGB encoding define since RGB is just RGB :-) > > Regards, > > Hans > >>> B. Reuse current enums, but remove format information from them: >>> DRM_COLOR_YCBCR_BT601 => DRM_COLOR_BT601. >>> >>> >>> Regards >>> >>> Andrzej >>> ... ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v3 AFBC 04/12] drm/arm/malidp: Set the AFBC register bits if the framebuffer has AFBC modifier
Added the AFBC decoder registers for DP500 , DP550 and DP650.
These registers control the processing of AFBC buffers. It controls various
features like AFBC decoder enable, lossless transformation and block split
as well as setting of the left, right, top and bottom cropping of AFBC buffers
(in number of pixels).
All the layers (except DE_SMART) support framebuffers with AFBC modifiers.
One needs to set the pixel values of the top, left, bottom and right cropping
for the AFBC framebuffer.
Cropping an AFBC framebuffer is controlled by the AFBC crop registers.
In that case, the layer input size registers should be configured with
framebuffer's dimensions and not with drm_plane_state source width/height
values (which is used for non AFBC framebuffer to denote cropping).
Changes from v1:
- Removed the "if (fb->modifier)" check from malidp_de_plane_update()
and added it in malidp_de_set_plane_afbc(). This will consolidate all the
AFBC specific register configurations in a single function ie
malidp_de_set_plane_afbc().
Changes from v2:
- For AFBC framebuffer, layer input size register should be set to
framebuffer's
width and height
Signed-off-by: Ayan Kumar Halder
---
drivers/gpu/drm/arm/malidp_hw.c | 25 +
drivers/gpu/drm/arm/malidp_hw.h | 2 +
drivers/gpu/drm/arm/malidp_planes.c | 109 +++-
drivers/gpu/drm/arm/malidp_regs.h | 20 +++
4 files changed, 130 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index b9bed11..87b7b12 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -94,11 +94,12 @@ static const struct malidp_layer malidp500_layers[] = {
* yuv2rgb matrix offset, mmu control register offset,
rotation_features
*/
{ DE_VIDEO1, MALIDP500_DE_LV_BASE, MALIDP500_DE_LV_PTR_BASE,
- MALIDP_DE_LV_STRIDE0, MALIDP500_LV_YUV2RGB, 0, ROTATE_ANY },
+ MALIDP_DE_LV_STRIDE0, MALIDP500_LV_YUV2RGB, 0, ROTATE_ANY,
+ MALIDP500_DE_LV_AD_CTRL },
{ DE_GRAPHICS1, MALIDP500_DE_LG1_BASE, MALIDP500_DE_LG1_PTR_BASE,
- MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY },
+ MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY, MALIDP500_DE_LG1_AD_CTRL
},
{ DE_GRAPHICS2, MALIDP500_DE_LG2_BASE, MALIDP500_DE_LG2_PTR_BASE,
- MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY },
+ MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY, MALIDP500_DE_LG2_AD_CTRL
},
};
static const struct malidp_layer malidp550_layers[] = {
@@ -106,13 +107,15 @@ static const struct malidp_layer malidp550_layers[] = {
* yuv2rgb matrix offset, mmu control register offset,
rotation_features
*/
{ DE_VIDEO1, MALIDP550_DE_LV1_BASE, MALIDP550_DE_LV1_PTR_BASE,
- MALIDP_DE_LV_STRIDE0, MALIDP550_LV_YUV2RGB, 0, ROTATE_ANY },
+ MALIDP_DE_LV_STRIDE0, MALIDP550_LV_YUV2RGB, 0, ROTATE_ANY,
+ MALIDP550_DE_LV1_AD_CTRL },
{ DE_GRAPHICS1, MALIDP550_DE_LG_BASE, MALIDP550_DE_LG_PTR_BASE,
- MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY },
+ MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY, MALIDP550_DE_LG_AD_CTRL
},
{ DE_VIDEO2, MALIDP550_DE_LV2_BASE, MALIDP550_DE_LV2_PTR_BASE,
- MALIDP_DE_LV_STRIDE0, MALIDP550_LV_YUV2RGB, 0, ROTATE_ANY },
+ MALIDP_DE_LV_STRIDE0, MALIDP550_LV_YUV2RGB, 0, ROTATE_ANY,
+ MALIDP550_DE_LV2_AD_CTRL },
{ DE_SMART, MALIDP550_DE_LS_BASE, MALIDP550_DE_LS_PTR_BASE,
- MALIDP550_DE_LS_R1_STRIDE, 0, 0, ROTATE_NONE },
+ MALIDP550_DE_LS_R1_STRIDE, 0, 0, ROTATE_NONE, 0 },
};
static const struct malidp_layer malidp650_layers[] = {
@@ -122,16 +125,16 @@ static const struct malidp_layer malidp650_layers[] = {
*/
{ DE_VIDEO1, MALIDP550_DE_LV1_BASE, MALIDP550_DE_LV1_PTR_BASE,
MALIDP_DE_LV_STRIDE0, MALIDP550_LV_YUV2RGB,
- MALIDP650_DE_LV_MMU_CTRL, ROTATE_ANY },
+ MALIDP650_DE_LV_MMU_CTRL, ROTATE_ANY, MALIDP550_DE_LV1_AD_CTRL
},
{ DE_GRAPHICS1, MALIDP550_DE_LG_BASE, MALIDP550_DE_LG_PTR_BASE,
MALIDP_DE_LG_STRIDE, 0, MALIDP650_DE_LG_MMU_CTRL,
- ROTATE_COMPRESSED },
+ ROTATE_COMPRESSED, MALIDP550_DE_LG_AD_CTRL },
{ DE_VIDEO2, MALIDP550_DE_LV2_BASE, MALIDP550_DE_LV2_PTR_BASE,
MALIDP_DE_LV_STRIDE0, MALIDP550_LV_YUV2RGB,
- MALIDP650_DE_LV_MMU_CTRL, ROTATE_ANY },
+ MALIDP650_DE_LV_MMU_CTRL, ROTATE_ANY, MALIDP550_DE_LV2_AD_CTRL
},
{ DE_SMART, MALIDP550_DE_LS_BASE, MALIDP550_DE_LS_PTR_BASE,
MALIDP550_DE_LS_R1_STRIDE, 0, MALIDP650_DE_LS_MMU_CTRL,
- ROTATE_NONE },
+ ROTATE_NONE, 0 },
};
#define SE_N_SCALING_COEFFS96
diff --git a/drivers/gpu/drm/arm/malidp_hw.h b/drivers/gpu/drm/arm/malidp_hw.h
index 40155e2..651558f 100644
---
[RFC AFBC 02/12] drm: Added a new format DRM_FORMAT_XVYU2101010
We have added a new format ie DRM_FORMAT_XVYU2101010 which is supported
by mali display driver.
Signed-off-by: Ayan Kumar halder
---
drivers/gpu/drm/drm_fourcc.c | 1 +
include/uapi/drm/drm_fourcc.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 6b7a62e..d31e1ae 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -229,6 +229,7 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_VUY888, .depth = 0,
.num_planes = 1, .cpp = { 3, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_Y410,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true,
.is_yuv = true },
{ .format = DRM_FORMAT_AYUV,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true,
.is_yuv = true },
+ { .format = DRM_FORMAT_XVYU2101010, .depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_P010,.depth = 0,
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true },
{ .format = DRM_FORMAT_P012,.depth = 0,
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true },
{ .format = DRM_FORMAT_P016,.depth = 0,
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true },
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 71b2bc7..75c4b5a 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -153,6 +153,7 @@ extern "C" {
#define DRM_FORMAT_AYUVfourcc_code('A', 'Y', 'U', 'V') /*
[31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
#define DRM_FORMAT_XYUVfourcc_code('X', 'Y', 'U', 'V') /* [31:0]
X:Y:Cb:Cr 8:8:8:8 little endian */
+#define DRM_FORMAT_XVYU2101010 fourcc_code('X', 'V', '3', '0') /* [31:0]
X:Cr:Y:Cb 2:10:10:10 little endian */
#define DRM_FORMAT_VUY888 fourcc_code('V', 'U', '2', '4') /* [23:0]
Cr:Cb:Y 8:8:8 little endian */
#define DRM_FORMAT_Y410fourcc_code('Y', '4', '1', '0') /*
[31:0] A:Cr:Y:Cb 2:10:10:10 little endian */
#define DRM_FORMAT_VUY101010 fourcc_code('V', 'U', '3', '0') /* Y followed
by U then V, 10:10:10. Non-linear modifier only */
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC AFBC 05/12] drm/arm/malidp:- Define a common list of AFBC format modifiers supported for DP500, DP550 and DP650
We need to define a common list of format modifiers supported by each of the
Mali
display processors. The difference between DP500 from DP550/650 is that DP500
does not support block split mode (ie AFBC_FORMAT_MOD_SPLIT) and DP550 supports
YUV420 with split mode. We noted these special cases by defining
MALIDP_DEVICE_AFBC_SUPPORT_SPLIT
and AFBC_SUPPORT_SPLIT_WITH_YUV_420_10 for malidp_hw_regmap.features
Also we have defined a set of meaningful macros to shorten the modifier names
Signed-off-by: Ayan Kumar halder
Change-Id: I09fba2032a7474e6ce45af230e0ed18fc1f4c1df
---
drivers/gpu/drm/arm/malidp_drv.c | 8
drivers/gpu/drm/arm/malidp_hw.c | 30 --
drivers/gpu/drm/arm/malidp_hw.h | 20 +++-
3 files changed, 47 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 505f316..b8db92f 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -293,8 +293,8 @@ malidp_verify_afbc_framebuffer_caps(struct drm_device *dev,
return false;
}
- switch (mode_cmd->modifier[0] & AFBC_FORMAT_MOD_BLOCK_SIZE_MASK) {
- case AFBC_FORMAT_MOD_BLOCK_SIZE_16x16:
+ switch (mode_cmd->modifier[0] & AFBC_SIZE_MASK) {
+ case AFBC_SIZE_16X16:
if ((mode_cmd->width % 16) || (mode_cmd->height % 16)) {
DRM_DEBUG_KMS("AFBC buffers must be aligned to 16
pixels\n");
return false;
@@ -319,8 +319,8 @@ malidp_verify_afbc_framebuffer_size(struct drm_device *dev,
u32 afbc_superblock_size = 0, afbc_superblock_height = 0;
u32 afbc_superblock_width = 0, afbc_size = 0;
- switch (mode_cmd->modifier[0] & AFBC_FORMAT_MOD_BLOCK_SIZE_MASK) {
- case AFBC_FORMAT_MOD_BLOCK_SIZE_16x16:
+ switch (mode_cmd->modifier[0] & AFBC_SIZE_MASK) {
+ case AFBC_SIZE_16X16:
afbc_superblock_height = 16;
afbc_superblock_width = 16;
break;
diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index 87b7b12..55d379b 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -137,6 +137,32 @@ static const struct malidp_layer malidp650_layers[] = {
ROTATE_NONE, 0 },
};
+const u64 malidp_format_modifiers[] = {
+ /* All RGB formats (except XRGB, RGBX, XBGR, BGRX) */
+ DRM_FORMAT_MOD_ARM_AFBC(AFBC_SIZE_16X16 | AFBC_YTR | AFBC_SPARSE),
+ DRM_FORMAT_MOD_ARM_AFBC(AFBC_SIZE_16X16 | AFBC_YTR),
+
+ /* All RGB formats > 16bpp (except XRGB, RGBX, XBGR, BGRX) */
+ DRM_FORMAT_MOD_ARM_AFBC(AFBC_SIZE_16X16 | AFBC_YTR | AFBC_SPARSE |
AFBC_SPLIT),
+
+ /* All 8 or 10 bit YUV 444 formats. */
+ /* In DP550, 10 bit YUV 420 format also supported */
+ DRM_FORMAT_MOD_ARM_AFBC(AFBC_SIZE_16X16 | AFBC_SPARSE | AFBC_SPLIT),
+
+ /* YUV 420, 422 P1 8 bit and YUV 444 8 bit/10 bit formats */
+ DRM_FORMAT_MOD_ARM_AFBC(AFBC_SIZE_16X16 | AFBC_SPARSE),
+ DRM_FORMAT_MOD_ARM_AFBC(AFBC_SIZE_16X16),
+
+ /* YUV 420, 422 P1 8, 10 bit formats */
+ DRM_FORMAT_MOD_ARM_AFBC(AFBC_SIZE_16X16 | AFBC_CBR | AFBC_SPARSE),
+ DRM_FORMAT_MOD_ARM_AFBC(AFBC_SIZE_16X16 | AFBC_CBR),
+
+ /* All formats */
+ DRM_FORMAT_MOD_LINEAR,
+
+ DRM_FORMAT_MOD_INVALID
+};
+
#define SE_N_SCALING_COEFFS96
static const u16 dp500_se_scaling_coeffs[][SE_N_SCALING_COEFFS] = {
[MALIDP_UPSCALING_COEFFS - 1] = {
@@ -841,7 +867,7 @@ const struct malidp_hw malidp_device[MALIDP_MAX_DEVICES] = {
.se_base = MALIDP550_SE_BASE,
.dc_base = MALIDP550_DC_BASE,
.out_depth_base = MALIDP550_DE_OUTPUT_DEPTH,
- .features = MALIDP_REGMAP_HAS_CLEARIRQ,
+ .features = MALIDP_REGMAP_HAS_CLEARIRQ |
MALIDP_DEVICE_AFBC_SUPPORT_SPLIT | AFBC_SUPPORT_SPLIT_WITH_YUV_420_10,
.n_layers = ARRAY_SIZE(malidp550_layers),
.layers = malidp550_layers,
.de_irq_map = {
@@ -887,7 +913,7 @@ const struct malidp_hw malidp_device[MALIDP_MAX_DEVICES] = {
.se_base = MALIDP550_SE_BASE,
.dc_base = MALIDP550_DC_BASE,
.out_depth_base = MALIDP550_DE_OUTPUT_DEPTH,
- .features = MALIDP_REGMAP_HAS_CLEARIRQ,
+ .features = MALIDP_REGMAP_HAS_CLEARIRQ |
MALIDP_DEVICE_AFBC_SUPPORT_SPLIT,
.n_layers = ARRAY_SIZE(malidp650_layers),
.layers = malidp650_layers,
.de_irq_map = {
diff --git a/drivers/gpu/drm/arm/malidp_hw.h b/drivers/gpu/drm/arm/malidp_hw.h
index 651558f..27b907f 100644
--- a/drivers/gpu/drm/arm/malidp_hw.h
+++ b/drivers/gpu/drm/arm/malidp_hw.h
@@ -95,7 +95,9 @@ struct malidp_se_config {
};
/* regm
[RFC AFBC 06/12] drm/arm/malidp:- Added support for new YUV formats for DP500, DP550 and DP650
We have added some new formats to be supported on DP500/DP550/DP650.
Signed-off-by: Ayan Kumar Halder
Depends on :- https://patchwork.kernel.org/patch/10460063/
---
drivers/gpu/drm/arm/malidp_hw.c | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index 55d379b..25ac5890 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -49,6 +49,12 @@ static const struct malidp_format_id malidp500_de_formats[]
= {
{ DRM_FORMAT_YUYV, DE_VIDEO1, 13 },
{ DRM_FORMAT_NV12, DE_VIDEO1 | SE_MEMWRITE, 14 },
{ DRM_FORMAT_YUV420, DE_VIDEO1, 15 },
+ { DRM_FORMAT_XYUV, DE_VIDEO1, 16 },
+ /* These are supported with AFBC only */
+ { DRM_FORMAT_YUV420_8BIT, DE_VIDEO1, 14 },
+ { DRM_FORMAT_VUY888, DE_VIDEO1, 16 },
+ { DRM_FORMAT_VUY101010, DE_VIDEO1, 17 },
+ { DRM_FORMAT_YUV420_10BIT, DE_VIDEO1, 18 }
};
#define MALIDP_ID(__group, __format) \
@@ -74,11 +80,25 @@ static const struct malidp_format_id malidp500_de_formats[]
= {
{ DRM_FORMAT_ABGR1555, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2,
MALIDP_ID(4, 1) }, \
{ DRM_FORMAT_RGB565, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2, MALIDP_ID(4,
2) }, \
{ DRM_FORMAT_BGR565, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2, MALIDP_ID(4,
3) }, \
+ /* This is only supported with linear modifier */ \
+ { DRM_FORMAT_XYUV, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 0) },\
+ /* This is only supported with AFBC modifier */ \
+ { DRM_FORMAT_VUY888, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 0) }, \
{ DRM_FORMAT_YUYV, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 2) },\
+ /* This is only supported with linear modifier */ \
{ DRM_FORMAT_UYVY, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 3) },\
{ DRM_FORMAT_NV12, DE_VIDEO1 | DE_VIDEO2 | SE_MEMWRITE, MALIDP_ID(5, 6)
}, \
+ /* This is only supported with AFBC modifier */ \
+ { DRM_FORMAT_YUV420_8BIT, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 6) }, \
{ DRM_FORMAT_YUV420, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 7) }, \
- { DRM_FORMAT_X0L2, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 6)}
+ /* This is only supported with linear modifier */ \
+ { DRM_FORMAT_XVYU2101010, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 0)}, \
+ /* This is only supported with AFBC modifier */ \
+ { DRM_FORMAT_VUY101010, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 0)}, \
+ { DRM_FORMAT_X0L2, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 6)}, \
+ /* This is only supported with AFBC modifier */ \
+ { DRM_FORMAT_YUV420_10BIT, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 7)}, \
+ { DRM_FORMAT_P010, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 7)}
static const struct malidp_format_id malidp550_de_formats[] = {
MALIDP_COMMON_FORMATS,
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v3 AFBC 12/12] drm/arm/malidp: Added support for AFBC modifiers for all layers except DE_SMART
The list of modifiers to be supported for each plane has been dynamically
generated
from 'malidp_format_modifiers[]' and 'malidp_hw_regmap->features'.
Changes from v1:-
1. Replaced DRM_ERROR() with DRM_DEBUG_KMS() in malidp_format_mod_supported()
to report unsupported modifiers.
Changes from v2:-
1. Removed malidp_format_mod_supported() from the current patch. This has been
added
in "PATCH 7/12"
2. Dynamically generate the list of modifiers (to be supported for each plane)
from
'malidp_format_modifiers' and features.
Signed-off-by: Ayan Kumar halder
---
drivers/gpu/drm/arm/malidp_drv.c| 1 +
drivers/gpu/drm/arm/malidp_planes.c | 28 ++--
2 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index b2b97db..be45703 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -388,6 +388,7 @@ static int malidp_init(struct drm_device *drm)
drm->mode_config.max_height = hwdev->max_line_size;
drm->mode_config.funcs = &malidp_mode_config_funcs;
drm->mode_config.helper_private = &malidp_mode_config_helpers;
+ drm->mode_config.allow_fb_modifiers = true;
ret = malidp_crtc_init(drm);
if (ret)
diff --git a/drivers/gpu/drm/arm/malidp_planes.c
b/drivers/gpu/drm/arm/malidp_planes.c
index eec0442..01037d0 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -934,6 +934,25 @@ int malidp_de_planes_init(struct drm_device *drm)
BIT(DRM_MODE_BLEND_COVERAGE);
u32 *formats;
int ret, i, j, n;
+ u64 supported_modifiers[MODIFIERS_COUNT_MAX];
+ const u64 *modifiers;
+
+ modifiers = malidp_format_modifiers;
+
+ if (!(map->features & MALIDP_DEVICE_AFBC_SUPPORT_SPLIT)) {
+ /*
+* Since our hardware does not support SPLIT, so build the list
of
+* supported modifiers excluding SPLIT ones.
+*/
+ while (*modifiers != DRM_FORMAT_MOD_INVALID) {
+ if (!(*modifiers & AFBC_SPLIT))
+ supported_modifiers[j++] = *modifiers;
+
+ modifiers++;
+ }
+ supported_modifiers[j++] = DRM_FORMAT_MOD_INVALID;
+ modifiers = supported_modifiers;
+ }
formats = kcalloc(map->n_pixel_formats, sizeof(*formats), GFP_KERNEL);
if (!formats) {
@@ -958,9 +977,14 @@ int malidp_de_planes_init(struct drm_device *drm)
plane_type = (i == 0) ? DRM_PLANE_TYPE_PRIMARY :
DRM_PLANE_TYPE_OVERLAY;
+
+ /*
+* All the layers except smart layer supports AFBC modifiers.
+*/
ret = drm_universal_plane_init(drm, &plane->base, crtcs,
- &malidp_de_plane_funcs, formats,
- n, NULL, plane_type, NULL);
+ &malidp_de_plane_funcs, formats, n,
+ (id == DE_SMART) ? NULL : modifiers,
plane_type, NULL);
+
if (ret < 0)
goto cleanup;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC AFBC 01/12] drm/fourcc: Add AFBC yuv fourccs for Mali
From: Brian Starkey As we look to enable AFBC using DRM format modifiers, we run into problems which we've historically handled via vendor-private details (i.e. gralloc, on Android). AFBC (as an encoding) is fully flexible, and for example YUV data can be encoded into 1, 2 or 3 encoded "planes", much like the linear equivalents. Component order is also meaningful, as AFBC doesn't necessarily care about what each "channel" of the data it encodes contains. Therefore ABGR and RGBA can be encoded in AFBC with different representations. Similarly, 'X' components may be encoded into AFBC streams in cases where a decoder expects to decode a 4th component. In addition, AFBC is a licensable IP, meaning that to support the ecosystem we need to ensure that _all_ AFBC users are able to describe the encodings that they need. This is much better achieved by preserving meaning in the fourcc codes when they are combined with an AFBC modifier. In essence, we want to use the modifier to describe the parameters of the AFBC encode/decode, and use the fourcc code to describe the data being encoded/decoded. To do anything different would be to introduce redundancy - we would need to duplicate in the modifier information which is _already_ conveyed clearly and non-ambigiously by a fourcc code. I hope that for RGB this is non-controversial. (BGRA + MODIFIER_AFBC) is a different format from (RGBA + MODIFIER_AFBC). Possibly more controversial is that (XBGR + MODIFIER_AFBC) is different from (BGR888 + MODIFIER_AFBC). I understand that in some schemes it is not the case - but in AFBC it is so. Where we run into problems is where there are not already fourcc codes which represent the data which the AFBC encoder/decoder is processing. To that end, we want to introduce new fourcc codes to describe the data being encoded/decoded, in the places where none of the existing fourcc codes are applicable. Where we don't support an equivalent non-compressed layout, or where no "obvious" linear layout exists, we are proposing adding fourcc codes which have no associated linear layout - because any layout we proposed would be completely arbitrary. Some formats are following the naming conventions from [2]. The summary of the new formats is: DRM_FORMAT_VUY888 - Packed 8-bit YUV 444. Y followed by U then V. DRM_FORMAT_VUY101010 - Packed 10-bit YUV 444. Y followed by U then V. No defined linear encoding. DRM_FORMAT_Y210 - Packed 10-bit YUV 422. Y followed by U (then Y) then V. 10-bit samples in 16-bit words. DRM_FORMAT_Y410 - Packed 10-bit YUV 444, with 2-bit alpha. DRM_FORMAT_P210 - Semi-planar 10-bit YUV 422. Y plane, followed by interleaved U-then-V plane. 10-bit samples in 16-bit words. DRM_FORMAT_YUV420_8BIT - Packed 8-bit YUV 420. Y followed by U then V. No defined linear encoding DRM_FORMAT_YUV420_10BIT - Packed 10-bit YUV 420. Y followed by U then V. No defined linear encoding Please also note that in the absence of AFBC, we would still need to add Y410, Y210 and P210. Full rationale follows: YUV 444 8-bit, 1-plane -- The currently defined AYUV format encodes a 4th alpha component, which makes it unsuitable for representing a 3-component YUV 444 AFBC stream. The proposed[1] XYUV format which is supported by Mali-DP in linear layout is also unsuitable, because the component order is the opposite of the AFBC version, and it encodes a 4th 'X' component. DRM_FORMAT_VUY888 is the "obvious" format for a 3-component, packed, YUV 444 8-bit format, with the component order which our HW expects to encode/decode. It conforms to the same naming convention as the existing packed YUV 444 format. The naming here is meant to be consistent with DRM_FORMAT_AYUV and DRM_FORMAT_XYUV[1] YUV 444 10-bit, 1-plane --- There is no currently-defined YUV 444 10-bit format in drm_fourcc.h, irrespective of number of planes. The proposed[1] XVYU2101010 format which is supported by Mali-DP in linear layout uses the wrong component order, and also encodes a 4th 'X' component, which doesn't match the AFBC version of YUV 444 10-bit which we support. DRM_FORMAT_Y410 is the same layout as XVYU2101010, but with 2 bits of alpha. This format is supported with linear layout by Mali GPUs. The naming follows[2]. There is no "obvious" linear encoding for a 3-component 10:10:10 packed format, and so DRM_FORMAT_VUY101010 defines a component order, but not a bit encoding. Again, the naming is meant to be consistent with DRM_FORMAT_AYUV. YUV 422 8-bit, 1-plane -- The existing DRM_FORMAT_YUYV (and the other component orders) are single-planar YUV 422 8-bit formats. Following the convention of the component orders of the RGB formats, YUYV has the correct component order for our AFBC encoding (Y followed by U followed by V)
[RFC AFBC 03/12] drm/afbc: Add AFBC modifier usage documentation
From: Brian Starkey AFBC is a flexible, proprietary, lossless compression protocol and format, with a number of defined DRM format modifiers. To facilitate consistency and compatibility between different AFBC producers and consumers, document the expectations for usage of the AFBC DRM format modifiers in a new .rst chapter. Signed-off-by: Brian Starkey Reviewed-by: Liviu Dudau --- Documentation/gpu/afbc.rst| 233 ++ Documentation/gpu/drivers.rst | 1 + MAINTAINERS | 1 + include/uapi/drm/drm_fourcc.h | 3 + 4 files changed, 238 insertions(+) create mode 100644 Documentation/gpu/afbc.rst diff --git a/Documentation/gpu/afbc.rst b/Documentation/gpu/afbc.rst new file mode 100644 index 000..922d955 --- /dev/null +++ b/Documentation/gpu/afbc.rst @@ -0,0 +1,233 @@ +=== + Arm Framebuffer Compression (AFBC) +=== + +AFBC is a proprietary lossless image compression protocol and format. +It provides fine-grained random access and minimizes the amount of +data transferred between IP blocks. + +AFBC can be enabled on drivers which support it via use of the AFBC +format modifiers defined in drm_fourcc.h. See DRM_FORMAT_MOD_ARM_AFBC(*). + +All users of the AFBC modifiers must follow the usage guidelines laid +out in this document, to ensure compatibility across different AFBC +producers and consumers. + +Components and Ordering +=== + +AFBC streams can contain several components - where a component +corresponds to a color channel (i.e. R, G, B, X, A, Y, Cb, Cr). +The assignment of input/output color channels must be consistent +between the encoder and the decoder for correct operation, otherwise +the consumer will interpret the decoded data incorrectly. + +Furthermore, when the lossless colorspace transform is used +(AFBC_FORMAT_MOD_YTR, which should be enabled for RGB buffers for +maximum compression efficiency), the component order must be: + + * Component 0: R + * Component 1: G + * Component 2: B + +The component ordering is communicated via the fourcc code in the +fourcc:modifier pair. In general, component '0' is considered to +reside in the least-significant bits of the corresponding linear +format. For example, COMP(bits): + + * DRM_FORMAT_ABGR + + * Component 0: R(8) + * Component 1: G(8) + * Component 2: B(8) + * Component 3: A(8) + + * DRM_FORMAT_BGR888 + + * Component 0: R(8) + * Component 1: G(8) + * Component 2: B(8) + + * DRM_FORMAT_YUYV + + * Component 0: Y(8) + * Component 1: Cb(8, 2x1 subsampled) + * Component 2: Cr(8, 2x1 subsampled) + +In AFBC, 'X' components are not treated any differently from any other +component. Therefore, an AFBC buffer with fourcc DRM_FORMAT_XBGR +encodes with 4 components, like so: + + * DRM_FORMAT_XBGR + + * Component 0: R(8) + * Component 1: G(8) + * Component 2: B(8) + * Component 3: X(8) + +Please note, however, that the inclusion of a "wasted" 'X' channel is +bad for compression efficiency, and so it's recommended to avoid +formats containing 'X' bits. If a fourth component is +required/expected by the encoder/decoder, then it is recommended to +instead use an equivalent format with alpha, setting all alpha bits to +'1'. If there is no requirement for a fourth component, then a format +which doesn't include alpha can be used, e.g. DRM_FORMAT_BGR888. + +Number of Planes + + +Formats which are typically multi-planar in linear layouts (e.g. YUV +420), can be encoded into one, or multiple, AFBC planes. As with +component order, the encoder and decoder must agree about the number +of planes in order to correctly decode the buffer. The fourcc code is +used to determine the number of encoded planes in an AFBC buffer, +matching the number of planes for the linear (unmodified) format. +Within each plane, the component ordering also follows the fourcc +code: + +For example: + + * DRM_FORMAT_YUYV: nplanes = 1 + + * Plane 0: + + * Component 0: Y(8) + * Component 1: Cb(8, 2x1 subsampled) + * Component 2: Cr(8, 2x1 subsampled) + + * DRM_FORMAT_NV12: nplanes = 2 + + * Plane 0: + + * Component 0: Y(8) + + * Plane 1: + + * Component 0: Cb(8, 2x1 subsampled) + * Component 1: Cr(8, 2x1 subsampled) + +Cross-device interoperability += + +For maximum compatibility across devices, the table below defines +canonical formats for use between AFBC-enabled devices. Formats which +are listed here must be used exactly as specified when using the AFBC +modifiers. Formats which are not listed should be avoided. + +.. flat-table:: AFBC formats + + * - Fourcc code + - Description + - Planes/Components + + * - DRM_FORMAT_ABGR2101010 + - 10-bit per component RGB, with 2-bit alpha + - Plane 0: 4 components + * Component 0: R(10) + * Component 1: G(10) + * Component 2: B(10) +
[RFC AFBC v2 00/12] Add support for Arm Framebuffer Compression(AFBC) in mali display driver
This patchset aims to add support for AFBC in mali display driver with the help of format modifiers. AFBC modifiers adds some constraints to framebuffer size, alignment, pitch, formats, etc In the previous patchset ie https://lists.freedesktop.org/archives/dri-devel/2018-June/180124.html I had illustrated how to add support for one format (ie BGR888) with one valid combination of AFBC modifiers ie AFBC_SIZE_16X16 | AFBC_YTR | AFBC_SPARSE Changes from v1:- In this current patchset, I have enabled the support for all AFBC modifiers (which are supported on DP500, DP550 and DP650) with all the pixel formats. Also, we have introduced some new pixel formats which are supported with AFBC modifiers only as well some other pixel formats which are supported with LINEAR only. Please feel free to let me know your thoughts. Depends on :- https://patchwork.kernel.org/patch/10460063/ Ayan Kumar Halder (10): drm: Added a new format DRM_FORMAT_XVYU2101010 drm/arm/malidp: Set the AFBC register bits if the framebuffer has AFBC modifier drm/arm/malidp:- Define a common list of AFBC format modifiers supported for DP500, DP550 and DP650 drm/arm/malidp:- Added support for new YUV formats for DP500, DP550 and DP650 drm/arm/malidp: Define the constraints on each supported drm_fourcc format for the AFBC modifiers. drm/arm/malidp: Specified the rotation memory requirements for AFBC YUV formats drm/arm/malidp:- Writeback framebuffer does not support any modifiers drm/arm/malidp:- Use the newly introduced malidp_format_get_bpp() instead of relying on cpp for calculating framebuffer size drm/arm/malidp:- Disregard the pitch alignment constraint for AFBC framebuffer. drm/arm/malidp: Added support for AFBC modifiers for all layers except DE_SMART Brian Starkey (2): drm/fourcc: Add AFBC yuv fourccs for Mali drm/afbc: Add AFBC modifier usage documentation Documentation/gpu/afbc.rst | 233 +++ Documentation/gpu/drivers.rst | 1 + MAINTAINERS | 1 + drivers/gpu/drm/arm/malidp_drv.c| 45 ++ drivers/gpu/drm/arm/malidp_drv.h| 6 + drivers/gpu/drm/arm/malidp_hw.c | 245 drivers/gpu/drm/arm/malidp_hw.h | 30 +++- drivers/gpu/drm/arm/malidp_mw.c | 7 +- drivers/gpu/drm/arm/malidp_planes.c | 268 +--- drivers/gpu/drm/arm/malidp_regs.h | 20 +++ drivers/gpu/drm/drm_fourcc.c| 11 ++ include/uapi/drm/drm_fourcc.h | 20 ++- 12 files changed, 799 insertions(+), 88 deletions(-) create mode 100644 Documentation/gpu/afbc.rst -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC AFBC 07/12] drm/arm/malidp: Define the constraints on each supported drm_fourcc format for the AFBC modifiers.
The constraints are as follows (for Mali-DP 500, 550, 650) :-
1. AFBC is not supported for the formats defined in
malidp_hw_format_is_linear_only()
2. Some of the formats are supported only with AFBC modifiers. Thus we have
introduced a new function 'malidp_hw_format_is_afbc_only()' which verifies the
same.
3. AFBC_FORMAT_MOD_YTR needs to be provided for any RGB format.
4. Formats <= 16bpp cannot support AFBC_FORMAT_MOD_SPLIT.
5. CBR should not be set for non-subsampled formats.
6. SMART layer does not support framebuffer with AFBC modifiers.
Return -EINVAL for such a scenario.
7. AFBC_FORMAT_MOD_YTR is not supported for any YUV formats.
8. Formats which are subsampled cannot support AFBC_FORMAT_MOD_SPLIT. However in
DP550, YUV_420_10BIT is supported with AFBC_FORMAT_MOD_SPLIT. This feature has
been identified with MALIDP_DEVICE_AFBC_YUV_420_10_SUPPORT_SPLIT.
9. In DP550 and DP650, for YUYV, the hardware supports different format-ids to
be used with and without AFBC modifier. We have used the feature
'MALIDP_DEVICE_AFBC_YUYV_USE_422_P2' to identify this characteristic.
Signed-off-by: Ayan Kumar halder
---
drivers/gpu/drm/arm/malidp_drv.c| 23 +--
drivers/gpu/drm/arm/malidp_drv.h| 6 ++
drivers/gpu/drm/arm/malidp_hw.c | 71 +++--
drivers/gpu/drm/arm/malidp_hw.h | 5 +-
drivers/gpu/drm/arm/malidp_mw.c | 2 +-
drivers/gpu/drm/arm/malidp_planes.c | 124 +++-
6 files changed, 199 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index b8db92f..2f0b553 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -264,29 +264,8 @@ static bool
malidp_verify_afbc_framebuffer_caps(struct drm_device *dev,
const struct drm_mode_fb_cmd2 *mode_cmd)
{
- const struct drm_format_info *info;
-
- if ((mode_cmd->modifier[0] >> 56) != DRM_FORMAT_MOD_VENDOR_ARM) {
- DRM_DEBUG_KMS("Unknown modifier (not Arm)\n");
+ if (malidp_format_mod_supported(dev, mode_cmd->pixel_format,
mode_cmd->modifier[0]) == false)
return false;
- }
-
- if (mode_cmd->modifier[0] &
- ~DRM_FORMAT_MOD_ARM_AFBC(AFBC_MOD_VALID_BITS)) {
- DRM_DEBUG_KMS("Unsupported modifiers\n");
- return false;
- }
-
- info = drm_get_format_info(dev, mode_cmd);
- if (!info) {
- DRM_DEBUG_KMS("Unable to get the format information\n");
- return false;
- }
-
- if (info->num_planes != 1) {
- DRM_DEBUG_KMS("AFBC buffers expect one plane\n");
- return false;
- }
if (mode_cmd->offsets[0] != 0) {
DRM_DEBUG_KMS("AFBC buffers' plane offset should be 0\n");
diff --git a/drivers/gpu/drm/arm/malidp_drv.h b/drivers/gpu/drm/arm/malidp_drv.h
index b76c86f..019a682 100644
--- a/drivers/gpu/drm/arm/malidp_drv.h
+++ b/drivers/gpu/drm/arm/malidp_drv.h
@@ -90,6 +90,12 @@ struct malidp_crtc_state {
int malidp_de_planes_init(struct drm_device *drm);
int malidp_crtc_init(struct drm_device *drm);
+bool malidp_hw_format_is_linear_only(u32 format);
+bool malidp_hw_format_is_afbc_only(u32 format);
+
+bool malidp_format_mod_supported(struct drm_device *drm,
+u32 format, u64 modifier);
+
#ifdef CONFIG_DEBUG_FS
void malidp_error(struct malidp_drm *malidp,
struct malidp_error_stats *error_stats, u32 status,
diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index 25ac5890..4a774be 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -60,6 +60,8 @@ static const struct malidp_format_id malidp500_de_formats[] =
{
#define MALIDP_ID(__group, __format) \
__group) & 0x7) << 3) | ((__format) & 0x7))
+#define AFBC_YUV_422_FORMAT_ID MALIDP_ID(5, 1)
+
#define MALIDP_COMMON_FORMATS \
/*fourcc, layers supporting the format, internal id */ \
{ DRM_FORMAT_ARGB2101010, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2 |
SE_MEMWRITE, MALIDP_ID(0, 0) }, \
@@ -887,7 +889,10 @@ const struct malidp_hw malidp_device[MALIDP_MAX_DEVICES] =
{
.se_base = MALIDP550_SE_BASE,
.dc_base = MALIDP550_DC_BASE,
.out_depth_base = MALIDP550_DE_OUTPUT_DEPTH,
- .features = MALIDP_REGMAP_HAS_CLEARIRQ |
MALIDP_DEVICE_AFBC_SUPPORT_SPLIT | AFBC_SUPPORT_SPLIT_WITH_YUV_420_10,
+ .features = MALIDP_REGMAP_HAS_CLEARIRQ |
+ MALIDP_DEVICE_AFBC_SUPPORT_SPLIT |
+ MALIDP_DEVICE_AFBC_YUV_420_10_SUPPORT_SPLIT
|
+ MALIDP_DEVICE_AFBC_YUYV_USE_422_P2,
.n_layers = ARRAY_SIZE(malidp550_layers),
.layers = malidp550_layers,
[RFC AFBC 11/12] drm/arm/malidp:- Disregard the pitch alignment constraint for AFBC framebuffer.
Considering the fact that some of the AFBC specific pixel formats are expressed
in bits per pixel (ie bpp which is not byte aligned), the pitch (ie width * bpp)
is not guaranteed to be aligned to burst size (ie 8 or 16 bytes).
For example, DRM_FORMAT_VUY101010 is 30 bits per pixel. For a framebuffer of
width 32 pixels, the pitch will be 120 bytes which is not aligned to burst size
(ie 16 bytes) for DP650.
Signed-off-by: Ayan Kumar halder
---
drivers/gpu/drm/arm/malidp_planes.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_planes.c
b/drivers/gpu/drm/arm/malidp_planes.c
index d0a00ee..eec0442 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -529,8 +529,8 @@ static int malidp_de_plane_check(struct drm_plane *plane,
for (i = 0; i < ms->n_planes; i++) {
u8 alignment = malidp_hw_get_pitch_align(mp->hwdev, rotated);
- if ((fb->pitches[i] * drm_format_info_block_height(fb->format,
i))
- & (alignment - 1)) {
+ if (((fb->pitches[i] * drm_format_info_block_height(fb->format,
i))
+ & (alignment - 1)) && !(fb->modifier)) {
DRM_DEBUG_KMS("Invalid pitch %u for plane %d\n",
fb->pitches[i], i);
return -EINVAL;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC AFBC 08/12] drm/arm/malidp: Specified the rotation memory requirements for AFBC YUV formats
The newly supported AFBC YUV formats have the following rotation memory
constraints (in DP550/DP650).
1. DRM_FORMAT_VUY888/DRM_FORMAT_VUY101010 :- It can rotate upto 8
horizontal lines in the AFBC output buffer.
2. DRM_FORMAT_YUV420_8BIT :- It can rotate upto 16 horizontal lines
in the AFBC output buffer.
Also some of the pixel formats are specified in bits per pixel (rather
than bytes per pixel), so the calculation needs to take note of this.
Besides there are some difference between DP550 and DP650 and these are
as follows:-
1. DRM_FORMAT_X0L2 (in uncompressed format) does not support rotation in DP550.
For DP650, it can rotate upto 16 horizontal lines in the AFBC output buffer,
whereas in DP550 (with AFBC), it can rotate upto 8 horizontal lines.
2. DRM_FORMAT_YUV420_10BIT :- It can rotate upto 8 horizontal lines in
dp550 and 16 horizontal lines in DP650.
Signed-off-by: Ayan Kumar halder
---
drivers/gpu/drm/arm/malidp_hw.c | 101
drivers/gpu/drm/arm/malidp_hw.h | 5 +-
drivers/gpu/drm/arm/malidp_planes.c | 3 +-
3 files changed, 98 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index 4a774be..d9866a8 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -375,14 +375,39 @@ static void malidp500_modeset(struct malidp_hw_device
*hwdev, struct videomode *
malidp_hw_clearbits(hwdev, MALIDP_DISP_FUNC_ILACED,
MALIDP_DE_DISPLAY_FUNC);
}
-static int malidp500_rotmem_required(struct malidp_hw_device *hwdev, u16 w,
u16 h, u32 fmt)
+int malidp_format_get_bpp(u32 fmt)
+{
+ int bpp = drm_format_plane_cpp(fmt, 0) * 8;
+
+ if (bpp == 0) {
+ switch (fmt) {
+ case DRM_FORMAT_VUY101010:
+ bpp = 30;
+ case DRM_FORMAT_YUV420_10BIT:
+ bpp = 15;
+ break;
+ case DRM_FORMAT_YUV420_8BIT:
+ bpp = 12;
+ break;
+ default:
+ bpp = 0;
+ }
+ }
+
+ return bpp;
+}
+
+static int malidp500_rotmem_required(struct malidp_hw_device *hwdev, u16 w,
+u16 h, u32 fmt, bool has_modifier)
{
/*
* Each layer needs enough rotation memory to fit 8 lines
* worth of pixel data. Required size is then:
*size = rotated_width * (bpp / 8) * 8;
*/
- return w * drm_format_plane_cpp(fmt, 0) * 8;
+ int bpp = malidp_format_get_bpp(fmt);
+
+ return w * bpp;
}
static void malidp500_se_write_pp_coefftab(struct malidp_hw_device *hwdev,
@@ -660,9 +685,9 @@ static void malidp550_modeset(struct malidp_hw_device
*hwdev, struct videomode *
malidp_hw_clearbits(hwdev, MALIDP_DISP_FUNC_ILACED,
MALIDP_DE_DISPLAY_FUNC);
}
-static int malidp550_rotmem_required(struct malidp_hw_device *hwdev, u16 w,
u16 h, u32 fmt)
+static int malidpx50_get_bytes_per_column(u32 fmt)
{
- u32 bytes_per_col;
+ u32 bytes_per_column;
switch (fmt) {
/* 8 lines at 4 bytes per pixel */
@@ -688,19 +713,77 @@ static int malidp550_rotmem_required(struct
malidp_hw_device *hwdev, u16 w, u16
case DRM_FORMAT_UYVY:
case DRM_FORMAT_YUYV:
case DRM_FORMAT_X0L0:
- case DRM_FORMAT_X0L2:
- bytes_per_col = 32;
+ bytes_per_column = 32;
break;
/* 16 lines at 1.5 bytes per pixel */
case DRM_FORMAT_NV12:
case DRM_FORMAT_YUV420:
- bytes_per_col = 24;
+ /* 8 lines at 3 bytes per pixel */
+ case DRM_FORMAT_VUY888:
+ /* 16 lines at 12 bits per pixel */
+ case DRM_FORMAT_YUV420_8BIT:
+ /* 8 lines at 3 bytes per pixel */
+ case DRM_FORMAT_P010:
+ bytes_per_column = 24;
+ break;
+ /* 8 lines at 30 bits per pixel */
+ case DRM_FORMAT_VUY101010:
+ /* 16 lines at 15 bits per pixel */
+ case DRM_FORMAT_YUV420_10BIT:
+ bytes_per_column = 30;
break;
default:
return -EINVAL;
}
- return w * bytes_per_col;
+ return bytes_per_column;
+}
+
+static int malidp550_rotmem_required(struct malidp_hw_device *hwdev, u16 w,
+u16 h, u32 fmt, bool has_modifier)
+{
+ int bytes_per_column = 0;
+
+ switch (fmt) {
+ /* 8 lines at 15 bits per pixel */
+ case DRM_FORMAT_YUV420_10BIT:
+ bytes_per_column = 15;
+ break;
+ /* Uncompressed YUV 420 10 bit single plane cannot be rotated */
+ case DRM_FORMAT_X0L2:
+ if (has_modifier)
+ bytes_per_column = 8;
+ else
+ return -EINVAL;
+ break;
+ default:
+ bytes_per_column = malidpx50
[RFC AFBC 10/12] drm/arm/malidp:- Use the newly introduced malidp_format_get_bpp() instead of relying on cpp for calculating framebuffer size
Formats like DRM_FORMAT_VUY101010, DRM_FORMAT_YUV420_8BIT and
DRM_FORMAT_YUV420_10BIT are expressed in bits per pixel as they have a non
integer value of cpp (thus denoted as '0' in drm_format_info[]). Therefore,
the calculation of AFBC framebuffer size needs to use malidp_format_get_bpp().
Signed-off-by: Ayan Kumar halder
---
drivers/gpu/drm/arm/malidp_drv.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 2f0b553..b2b97db 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -297,6 +297,7 @@ malidp_verify_afbc_framebuffer_size(struct drm_device *dev,
struct drm_gem_object *objs = NULL;
u32 afbc_superblock_size = 0, afbc_superblock_height = 0;
u32 afbc_superblock_width = 0, afbc_size = 0;
+ int bpp = 0;
switch (mode_cmd->modifier[0] & AFBC_SIZE_MASK) {
case AFBC_SIZE_16X16:
@@ -313,15 +314,17 @@ malidp_verify_afbc_framebuffer_size(struct drm_device
*dev,
n_superblocks = (mode_cmd->width / afbc_superblock_width) *
(mode_cmd->height / afbc_superblock_height);
- afbc_superblock_size = info->cpp[0] * afbc_superblock_width *
- afbc_superblock_height;
+ bpp = malidp_format_get_bpp(info->format);
+
+ afbc_superblock_size = (bpp * afbc_superblock_width *
afbc_superblock_height) / BITS_PER_BYTE;
afbc_size = ALIGN(n_superblocks * AFBC_HEADER_SIZE,
AFBC_SUPERBLK_ALIGNMENT);
afbc_size += n_superblocks * ALIGN(afbc_superblock_size,
AFBC_SUPERBLK_ALIGNMENT);
- if (mode_cmd->width * info->cpp[0] != mode_cmd->pitches[0]) {
- DRM_DEBUG_KMS("Invalid value of pitch (=%u) should be same as
width (=%u) * cpp (=%u)\n",
- mode_cmd->pitches[0], mode_cmd->width,
info->cpp[0]);
+ if ((mode_cmd->width * bpp) != (mode_cmd->pitches[0] * BITS_PER_BYTE)) {
+ DRM_DEBUG_KMS("Invalid value of (pitch * BITS_PER_BYTE) (=%u) "
+ "should be same as width (=%u) * bpp (=%u)\n",
+ (mode_cmd->pitches[0] * BITS_PER_BYTE),
mode_cmd->width, bpp);
return false;
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC AFBC 09/12] drm/arm/malidp:- Writeback framebuffer does not support any modifiers
In malidp, the writeback pipeline does not support writing crtc output
to a framebuffer with modifiers ie the memory writeback content is
devoid of any compression or tiling, etc.
So we have added a commit check in memory writeback encoder helper function
to validate if the framebuffer has any modifier and if so, return EINVAL.
Signed-off-by: Ayan Kumar halder
---
drivers/gpu/drm/arm/malidp_mw.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/arm/malidp_mw.c b/drivers/gpu/drm/arm/malidp_mw.c
index 0484744..90c964a 100644
--- a/drivers/gpu/drm/arm/malidp_mw.c
+++ b/drivers/gpu/drm/arm/malidp_mw.c
@@ -141,6 +141,11 @@ malidp_mw_encoder_atomic_check(struct drm_encoder *encoder,
return -EINVAL;
}
+ if (fb->modifier) {
+ DRM_DEBUG_KMS("Writeback framebuffer does not support
modifiers\n");
+ return -EINVAL;
+ }
+
mw_state->format =
malidp_hw_get_format_id(&malidp->dev->hw->map, SE_MEMWRITE,
fb->format->format, !!fb->modifier);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdgpu: NULL check before some freeing functions is not needed.
Am 02.12.18 um 21:52 schrieb Thomas Meyer:
> NULL check before some freeing functions is not needed.
>
> Signed-off-by: Thomas Meyer
Reviewed-by: Christian König
> ---
>
> diff -u -p a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> @@ -816,6 +816,5 @@ out:
> void amdgpu_acpi_fini(struct amdgpu_device *adev)
> {
> unregister_acpi_notifier(&adev->acpi_nb);
> - if (adev->atif)
> - kfree(adev->atif);
> + kfree(adev->atif);
> }
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v2, 1/8] drm: Add optional COLOR_ENCODING and COLOR_RANGE properties to drm_plane
On 12/03/2018 12:23 PM, Andrzej Hajda wrote: > On 30.11.2018 15:48, Hans Verkuil wrote: >> On 11/30/18 15:29, Ville Syrjälä wrote: >>> On Fri, Nov 30, 2018 at 03:20:59PM +0100, Andrzej Hajda wrote: Hi Ville, As Christoph cannot respond till middle next week I can try to respond in his absence, as I am familiar with the subject. On 30.11.2018 14:25, Ville Syrjälä wrote: > On Fri, Nov 30, 2018 at 02:08:11PM +0100, Christoph Manszewski wrote: >> Hi, >> >> I am looking for a way to export the color encoding and range selection >> to user space. I came across those properties and am wondering, why >> they are meant only for non RGB color encodings. Would it be okay, to >> modify them and use with RGB formats as well? > What you trying to do? Input limited range RGB data and expand to full > range? For example. But there are two more general questions, which surprisingly we have not found answer for. 1. What color encoding and range drm should expect on its input RGB buffers by default? >>> RGB is just RGB. There is no encoding. > > > OK, Now I see I have confused encoding with colorspace, Hans thanks for > the documentation. > > As I understand drm by default should expect sRGB colorspace, also for > Y'CbCr buffers, and currently there are no standard ways to specify > buffer colorspace. > > Looking at current users of drm_plane_create_color_properties for Y'CbCr > buffers it seems default range should be LIMITED. Right. There is support for YCbCr quantization range signaling in HDMI, but that is for all intents and purposes broken in the standard. Don't use it, just output limited range YCbCr. On the other hand, RGB Quantization range signaling should *always* be used if the EDID signals support for it. I believe that's what drm does today already (this certainly works for i915). > > But default encoding is different: mali, armada, nouveau use > DRM_COLOR_YCBCR_BT601, i915 uses DRM_COLOR_YCBCR_BT709 - shouldn't this > be somehow standardized? According to CEA-861 bt.601 should be used for SDTV (PAL/NTSC), 709 for everything else. So this is resolution dependent. Although strictly speaking it is only userspace that knows the right encoding, since it depends on the source material. You can have SDTV video encoded with 709, or HDTV encoded with 601. But in the absence of any information, the default rule above is what should be used. > > > What I still do not understand is colorspace conversion(not encoding!) - > between pipeline input (framebuffers) and output (HDMI connector for > example): > > 1. Since sRGB, SMPTE170M/BT.601, BT.709 colorspaces are 'almost > identical in coverage' (according to wikipedia[1]) no colorspace > conversion is performed at all. That's correct. There is a slight difference between SMPTE170M and sRGB/Rec709, but basically invisible to the naked eye unless you see it side-by-side, and even then it's is hard to detect. However, sRGB uses a different transfer function compared to SMPTE170M and Rec709, and that difference *is* quite visible. Not all hardware (certainly not video capture hardware) is capable of converting between different transfer functions, though. I gather that this is more common for HDMI output hardware. > > 2. It is performed somewhere by HW, just my IP documentation is not > clear about it. > > > Another thing which still bothers me is RGB range in case of HDMI - > CEA-861 expects than on CEA modes limited RGB range should be sent, but > the pipeline on the particular hardware I have do not perform any > conversion of input buffers. So only limited range RGB buffers are > displayed correctly. In such case property describing plane with limited > RGB would be useful. Are you sure? Usually the same block that does YCbCr encoding conversion (601 to 709 or vice versa), also deals with limited/full range conversion. It is typically a 3x3 matrix + a vector adding the needed offsets. It is dead cheap to implement in hardware, so it would be very unusual if there is no support for this. > > > [1]: https://en.wikipedia.org/wiki/Rec._709#Primary_chromaticities > > >> It's assumed to be full range >>> because no one really uses anything else. >> For simple desktop usage that's true. When dealing with video inputs, >> this becomes much more complicated. > > > As I said earlier there are cases where output stream should be limited > RGB, and no conversion in pipeline - thus framebuffers also should be > 'limited RGB'. Whether RGB output should be full or limited range depends entirely on the resolution and the EDID. I have tested i915 w.r.t. RGB quantization range, and that does it right. The reality with RGB Quantization Range handling is that 50% of all devices do this wrong. So if the EDID signals selectable quantization range support, then use it and signal full range RGB. If it is not available, then the i915 implementation is one I can point to
Re: [Intel-gfx] [PATCH v2 01/11] drm/i915: Disable PSR in Apple panels
On Thu, 29 Nov 2018, José Roberto de Souza wrote:
> i915 yet don't support PSR in Apple panels, so lets keep it disabled
> while we work on that.
>
> v2: Renamed DP_DPCD_QUIRK_PSR_NOT_CURRENTLY_SUPPORTED to
> DP_DPCD_QUIRK_NO_PSR (Ville)
>
> Fixes: 598c6cfe0690 (drm/i915/psr: Enable PSR1 on gen-9+ HW)
> Cc: Ville Syrjälä
> Cc: Rodrigo Vivi
> Cc: Dhinakaran Pandiyan
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/drm_dp_helper.c | 2 ++
> drivers/gpu/drm/i915/intel_psr.c | 6 ++
> include/drm/drm_dp_helper.h | 1 +
> 3 files changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 2d6c491a0542..b00fd5ced0a0 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -1273,6 +1273,8 @@ static const struct dpcd_quirk dpcd_quirk_list[] = {
> { OUI(0x00, 0x22, 0xb9), DEVICE_ID_ANY, true,
> BIT(DP_DPCD_QUIRK_CONSTANT_N) },
> /* LG LP140WF6-SPM1 eDP panel */
> { OUI(0x00, 0x22, 0xb9), DEVICE_ID('s', 'i', 'v', 'a', 'r', 'T'),
> false, BIT(DP_DPCD_QUIRK_CONSTANT_N) },
> + /* Apple panels needs some additional handling to support PSR */
nitpick "panels needs"
> + { OUI(0x00, 0x10, 0xfa), DEVICE_ID_ANY, false,
> BIT(DP_DPCD_QUIRK_NO_PSR) }
> };
>
> #undef OUI
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index 2084784f320d..40ca6cc43cc4 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -278,6 +278,12 @@ void intel_psr_init_dpcd(struct intel_dp *intel_dp)
> DRM_DEBUG_KMS("Panel lacks power state control, PSR cannot be
> enabled\n");
> return;
> }
> +
> + if (drm_dp_has_quirk(&intel_dp->desc, DP_DPCD_QUIRK_NO_PSR)) {
> + DRM_DEBUG_KMS("PSR support not currently available for this
> panel\n");
> + return;
> + }
> +
> dev_priv->psr.sink_support = true;
> dev_priv->psr.sink_sync_latency =
> intel_dp_get_sink_sync_latency(intel_dp);
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 5736c942c85b..047314ce25d6 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -1365,6 +1365,7 @@ enum drm_dp_quirk {
>* to 16 bits. So will give a constant value (0x8000) for compatability.
>*/
> DP_DPCD_QUIRK_CONSTANT_N,
Please add a proper comment here, similar to above
DP_DPCD_QUIRK_CONSTANT_N.
BR,
Jani.
> + DP_DPCD_QUIRK_NO_PSR,
> };
>
> /**
--
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/omap: fix bus_flags for panel-dpi
Hi Tomi,
Thank you for the patch.
On Monday, 26 November 2018 11:24:47 EET Tomi Valkeinen wrote:
> panel-dpi used to convey the bus-flags via the videomode, but recent
> changes changed the use of videomode to DRM's drm_display_mode which
> does not contain bus-flags. This broke panel-dpi, which didn't
> explicitly store the bus-flags into dssdev->bus_flags.
>
> Fix this by setting dssdev->bus_flags. Also change the bus_flags type to
> u32, as that is the type used in the DRM framework, and we would get a
> warning with drm_bus_flags_from_videomode() otherwise.
>
> Fixes: 3fbda31e814868d8477ddf52d74b7b8f596578e8 ("drm/omap: Split mode fixup
> and mode set from encoder enable")
> Signed-off-by: Tomi Valkeinen
> Reported-by: H. Nikolaus Schaller
This looks good to me. Sorry for having overlooked that flags were parsed from
DT in the first place.
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/omapdrm/displays/panel-dpi.c | 1 +
> drivers/gpu/drm/omapdrm/dss/omapdss.h| 2 +-
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
> b/drivers/gpu/drm/omapdrm/displays/panel-dpi.c index
> 1f8161b041be..465120809eb3 100644
> --- a/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
> +++ b/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
> @@ -177,6 +177,7 @@ static int panel_dpi_probe(struct platform_device *pdev)
> dssdev->type = OMAP_DISPLAY_TYPE_DPI;
> dssdev->owner = THIS_MODULE;
> dssdev->of_ports = BIT(0);
> + drm_bus_flags_from_videomode(&ddata->vm, &dssdev->bus_flags);
>
> omapdss_display_init(dssdev);
> omapdss_device_register(dssdev);
> diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h
> b/drivers/gpu/drm/omapdrm/dss/omapdss.h index 1f698a95a94a..33e15cb77efa
> 100644
> --- a/drivers/gpu/drm/omapdrm/dss/omapdss.h
> +++ b/drivers/gpu/drm/omapdrm/dss/omapdss.h
> @@ -432,7 +432,7 @@ struct omap_dss_device {
> const struct omap_dss_driver *driver;
> const struct omap_dss_device_ops *ops;
> unsigned long ops_flags;
> - unsigned long bus_flags;
> + u32 bus_flags;
>
> /* helper variable for driver suspend/resume */
> bool activate_after_resume;
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5] fbdev: Remove depends on HAS_DMA in case of platform dependency
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST". In most cases this other symbol is an architecture or platform specific symbol, or PCI. Generic symbols and drivers without platform dependencies keep their dependencies on HAS_DMA, to prevent compiling subsystems or drivers that cannot work anyway. This simplifies the dependencies, and allows to improve compile-testing. Signed-off-by: Geert Uytterhoeven Reviewed-by: Mark Brown Acked-by: Robin Murphy Acked-by: Bartlomiej Zolnierkiewicz --- v5: - Rebase to v4.20-rc5, v4: - Rebase to v4.18-rc1, v3: - Add Acked-by, - Rebase to v4.17-rc1, v2: - Add Reviewed-by, Acked-by, - Drop RFC state, - Split per subsystem. --- drivers/video/fbdev/Kconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig index e413f54208f4b038..23f991340e3faccd 100644 --- a/drivers/video/fbdev/Kconfig +++ b/drivers/video/fbdev/Kconfig @@ -2037,7 +2037,8 @@ config FB_XILINX config FB_GOLDFISH tristate "Goldfish Framebuffer" - depends on FB && HAS_DMA && (GOLDFISH || COMPILE_TEST) + depends on FB + depends on GOLDFISH || COMPILE_TEST select FB_CFB_FILLRECT select FB_CFB_COPYAREA select FB_CFB_IMAGEBLIT -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] dt-bindings: gpu: add Allwinner H6 Mali Midgard binding
Am Dienstag, 27. November 2018, 08:42:49 CET schrieb Icenowy Zheng: > Allwinner H6 SoC uses a Mali T720 GPU, which is one of the GPUs in the > Midgard GPU product line. > > Add binding for the H6 Mali Midgard GPU. > > Signed-off-by: Icenowy Zheng > --- > .../devicetree/bindings/gpu/arm,mali-midgard.txt| 13 + > 1 file changed, 13 insertions(+) > > diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt > b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt > index 02f870cd60e6..c897dd7be48f 100644 > --- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt > +++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt > @@ -18,6 +18,7 @@ Required properties: > + "amlogic,meson-gxm-mali" > + "rockchip,rk3288-mali" > + "rockchip,rk3399-mali" > ++ "allwinner,sun50i-h6-mali" I'd think you might want to keep an alphabetical sorting here, aka above amlogic, otherwise the list will probably become hard to read at some later point. > - reg : Physical base address of the device and length of the register area. > > @@ -44,6 +45,18 @@ Optional properties: >for details. > > > +Vendor-specific bindings > + > + > +The Mali GPU is integrated very differently from one SoC to > +another. In order to accomodate those differences, you have the option > +to specify one more vendor-specific compatible, among: > + > + - allwinner,sun50i-h6-mali > +Required properties: > + * resets: phandle to the reset line for the GPU While this paragraph is similar to how it is done in Utgard, I'm wondering why we cannot just describe the "resets" as regular optional property above that. Heiko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] dt-bindings: gpu: add Allwinner H6 Mali Midgard binding
On Mon, Dec 03, 2018 at 01:25:21PM +0100, Heiko Stuebner wrote: > > - reg : Physical base address of the device and length of the register > > area. > > > > @@ -44,6 +45,18 @@ Optional properties: > >for details. > > > > > > +Vendor-specific bindings > > + > > + > > +The Mali GPU is integrated very differently from one SoC to > > +another. In order to accomodate those differences, you have the option > > +to specify one more vendor-specific compatible, among: > > + > > + - allwinner,sun50i-h6-mali > > +Required properties: > > + * resets: phandle to the reset line for the GPU > > While this paragraph is similar to how it is done in Utgard, I'm > wondering why we cannot just describe the "resets" as regular > optional property above that. Because it's not really optional, it's mandatory on some platforms (like this one) and has no significance on others. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] of/device: add blacklist for iommu dma_ops
Hi Rob,
On 01/12/2018 16:53, Rob Clark wrote:
This solves a problem we see with drm/msm, caused by getting
iommu_dma_ops while we attach our own domain and manage it directly at
the iommu API level:
[0038] user address but active_mm is swapper
Internal error: Oops: 9605 [#1] PREEMPT SMP
Modules linked in:
CPU: 7 PID: 70 Comm: kworker/7:1 Tainted: GW 4.19.3 #90
Hardware name: xxx (DT)
Workqueue: events deferred_probe_work_func
pstate: 80c9 (Nzcv daif +PAN +UAO)
pc : iommu_dma_map_sg+0x7c/0x2c8
lr : iommu_dma_map_sg+0x40/0x2c8
sp : ff80095eb4f0
x29: ff80095eb4f0 x28:
x27: ffc0f9431578 x26:
x25: x24: 0003
x23: 0001 x22: ffc0fa9ac010
x21: x20: ffc0fab40980
x19: ffc0fab40980 x18: 0003
x17: 01c4 x16: 0007
x15: 000e x14:
x13: x12: 0028
x11: 0101010101010101 x10: 7f7f7f7f7f7f7f7f
x9 : x8 : ffc0fab409a0
x7 : x6 : 0002
x5 : 0001 x4 :
x3 : 0001 x2 : 0002
x1 : ffc0f9431578 x0 :
Process kworker/7:1 (pid: 70, stack limit = 0x17d08ffb)
Call trace:
iommu_dma_map_sg+0x7c/0x2c8
__iommu_map_sg_attrs+0x70/0x84
get_pages+0x170/0x1e8
msm_gem_get_iova+0x8c/0x128
_msm_gem_kernel_new+0x6c/0xc8
msm_gem_kernel_new+0x4c/0x58
dsi_tx_buf_alloc_6g+0x4c/0x8c
msm_dsi_host_modeset_init+0xc8/0x108
msm_dsi_modeset_init+0x54/0x18c
_dpu_kms_drm_obj_init+0x430/0x474
dpu_kms_hw_init+0x5f8/0x6b4
msm_drm_bind+0x360/0x6c8
try_to_bring_up_master.part.7+0x28/0x70
component_master_add_with_match+0xe8/0x124
msm_pdev_probe+0x294/0x2b4
platform_drv_probe+0x58/0xa4
really_probe+0x150/0x294
driver_probe_device+0xac/0xe8
__device_attach_driver+0xa4/0xb4
bus_for_each_drv+0x98/0xc8
__device_attach+0xac/0x12c
device_initial_probe+0x24/0x30
bus_probe_device+0x38/0x98
deferred_probe_work_func+0x78/0xa4
process_one_work+0x24c/0x3dc
worker_thread+0x280/0x360
kthread+0x134/0x13c
ret_from_fork+0x10/0x18
Code: d284 91000725 6b17039f 5400048a (f9401f40)
---[ end trace f22dda57f3648e2c ]---
Kernel panic - not syncing: Fatal exception
SMP: stopping secondary CPUs
Kernel Offset: disabled
CPU features: 0x0,22802a18
Memory Limit: none
The problem is that when drm/msm does it's own iommu_attach_device(),
now the domain returned by iommu_get_domain_for_dev() is drm/msm's
domain, and it doesn't have domain->iova_cookie.
Does this crash still happen with 4.20-rc? Because as of 6af588fed391 it
really shouldn't.
We kind of avoided this problem prior to sdm845/dpu because the iommu
was attached to the mdp node in dt, which is a child of the toplevel
mdss node (which corresponds to the dev passed in dma_map_sg()). But
with sdm845, now the iommu is attached at the mdss level so we hit the
iommu_dma_ops in dma_map_sg().
But auto allocating/attaching a domain before the driver is probed was
already a blocking problem for enabling per-context pagetables for the
GPU. This problem is also now solved with this patch.
s/solved/worked around/
If you want a guarantee of actually getting a specific hardware context
allocated for a given domain, there needs to be code in the IOMMU driver
to understand and honour that. Implicitly depending on whatever happens
to fall out of current driver behaviour on current systems is not a real
solution.
Fixes: 97890ba9289c dma-mapping: detect and configure IOMMU in of_dma_configure
That's rather misleading, since the crash described above depends on at
least two other major changes which came long after that commit.
It's not that I don't understand exactly what you want here - just that
this commit message isn't a coherent justification for that ;)
Tested-by: Douglas Anderson
Signed-off-by: Rob Clark
---
This is an alternative/replacement for [1]. What it lacks in elegance
it makes up for in practicality ;-)
[1] https://patchwork.freedesktop.org/patch/264930/
drivers/of/device.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/of/device.c b/drivers/of/device.c
index 5957cd4fa262..15ffee00fb22 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -72,6 +72,14 @@ int of_device_add(struct platform_device *ofdev)
return device_add(&ofdev->dev);
}
+static const struct of_device_id iommu_blacklist[] = {
+ { .compatible = "qcom,mdp4" },
+ { .compatible = "qcom,mdss" },
+ { .compatible = "qcom,sdm845-mdss" },
+ { .compatible = "qcom,adreno" },
+ {}
+};
+
/**
* of_dma_configure - Setup DMA configuration
* @dev: Device to apply DMA configurati
Re: [v2, 1/8] drm: Add optional COLOR_ENCODING and COLOR_RANGE properties to drm_plane
On 03.12.2018 12:52, Hans Verkuil wrote: > On 12/03/2018 12:23 PM, Andrzej Hajda wrote: >> On 30.11.2018 15:48, Hans Verkuil wrote: >>> On 11/30/18 15:29, Ville Syrjälä wrote: On Fri, Nov 30, 2018 at 03:20:59PM +0100, Andrzej Hajda wrote: > Hi Ville, > > As Christoph cannot respond till middle next week I can try to respond > in his absence, as I am familiar with the subject. > > On 30.11.2018 14:25, Ville Syrjälä wrote: >> On Fri, Nov 30, 2018 at 02:08:11PM +0100, Christoph Manszewski wrote: >>> Hi, >>> >>> I am looking for a way to export the color encoding and range selection >>> to user space. I came across those properties and am wondering, why >>> they are meant only for non RGB color encodings. Would it be okay, to >>> modify them and use with RGB formats as well? >> What you trying to do? Input limited range RGB data and expand to full >> range? > For example. But there are two more general questions, which > surprisingly we have not found answer for. > > 1. What color encoding and range drm should expect on its input RGB > buffers by default? RGB is just RGB. There is no encoding. >> >> OK, Now I see I have confused encoding with colorspace, Hans thanks for >> the documentation. >> >> As I understand drm by default should expect sRGB colorspace, also for >> Y'CbCr buffers, and currently there are no standard ways to specify >> buffer colorspace. >> >> Looking at current users of drm_plane_create_color_properties for Y'CbCr >> buffers it seems default range should be LIMITED. > Right. There is support for YCbCr quantization range signaling in HDMI, > but that is for all intents and purposes broken in the standard. Don't > use it, just output limited range YCbCr. > > On the other hand, RGB Quantization range signaling should *always* be > used if the EDID signals support for it. I believe that's what drm does > today already (this certainly works for i915). > >> But default encoding is different: mali, armada, nouveau use >> DRM_COLOR_YCBCR_BT601, i915 uses DRM_COLOR_YCBCR_BT709 - shouldn't this >> be somehow standardized? > According to CEA-861 bt.601 should be used for SDTV (PAL/NTSC), 709 for > everything else. So this is resolution dependent. > > Although strictly speaking it is only userspace that knows the right > encoding, since it depends on the source material. You can have SDTV > video encoded with 709, or HDTV encoded with 601. But in the absence > of any information, the default rule above is what should be used. Since drm plane is not tied to specific crtc default encoding will not be always known prior to setting mode on crtc and attaching plane to crtc, probably DRM_COLOR_YCBCR_DEFAULT or similar would solve the issue. > >> >> What I still do not understand is colorspace conversion(not encoding!) - >> between pipeline input (framebuffers) and output (HDMI connector for >> example): >> >> 1. Since sRGB, SMPTE170M/BT.601, BT.709 colorspaces are 'almost >> identical in coverage' (according to wikipedia[1]) no colorspace >> conversion is performed at all. > That's correct. There is a slight difference between SMPTE170M and > sRGB/Rec709, but basically invisible to the naked eye unless you see > it side-by-side, and even then it's is hard to detect. > > However, sRGB uses a different transfer function compared to SMPTE170M > and Rec709, and that difference *is* quite visible. Not all hardware > (certainly not video capture hardware) is capable of converting between > different transfer functions, though. I gather that this is more common > for HDMI output hardware. > >> 2. It is performed somewhere by HW, just my IP documentation is not >> clear about it. >> >> >> Another thing which still bothers me is RGB range in case of HDMI - >> CEA-861 expects than on CEA modes limited RGB range should be sent, but >> the pipeline on the particular hardware I have do not perform any >> conversion of input buffers. So only limited range RGB buffers are >> displayed correctly. In such case property describing plane with limited >> RGB would be useful. > Are you sure? Usually the same block that does YCbCr encoding conversion > (601 to 709 or vice versa), also deals with limited/full range conversion. > > It is typically a 3x3 matrix + a vector adding the needed offsets. It is > dead cheap to implement in hardware, so it would be very unusual if there > is no support for this. Yay, I have unusual hardware :) There is register in HDMI output block for RGB->YCbCr conversion and I can specify there input RGB range and encoding, but it is only for cases where output is YCbCr4:4:4, In case RGB -> RGB no conversion is performed. Regards Andrzej >> >> [1]: https://en.wikipedia.org/wiki/Rec._709#Primary_chromaticities >> >> >>> It's assumed to be full range because no one really uses anything else. >>> For simple desktop usage that's true. When dealing with video inputs, >>> this becomes much more compli
[Bug 108920] [AMDGPU][TAHITI XT] linux unable to boot since rc3 rebase
https://bugs.freedesktop.org/show_bug.cgi?id=108920 Sylvain BERTRAND changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Sylvain BERTRAND --- the patch fixes it thx -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/syncobj: use dma_fence_get_stub
Extract of useful code from the timeline work. Let's use just a single
stub fence instance instead of allocating a new one all the time.
Signed-off-by: Chunming Zhou
Signed-off-by: Christian König
---
drivers/gpu/drm/drm_syncobj.c | 58 +++
1 file changed, 14 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index e2c5b3ca4824..5c5ba1f14307 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -56,22 +56,6 @@
#include "drm_internal.h"
#include
-struct drm_syncobj_stub_fence {
- struct dma_fence base;
- spinlock_t lock;
-};
-
-static const char *drm_syncobj_stub_fence_get_name(struct dma_fence *fence)
-{
-return "syncobjstub";
-}
-
-static const struct dma_fence_ops drm_syncobj_stub_fence_ops = {
- .get_driver_name = drm_syncobj_stub_fence_get_name,
- .get_timeline_name = drm_syncobj_stub_fence_get_name,
-};
-
-
/**
* drm_syncobj_find - lookup and reference a sync object.
* @file_private: drm file private pointer
@@ -190,23 +174,18 @@ void drm_syncobj_replace_fence(struct drm_syncobj
*syncobj,
}
EXPORT_SYMBOL(drm_syncobj_replace_fence);
-static int drm_syncobj_assign_null_handle(struct drm_syncobj *syncobj)
+/**
+ * drm_syncobj_assign_null_handle - assign a stub fence to the sync object
+ * @syncobj: sync object to assign the fence on
+ *
+ * Assign a already signaled stub fence to the sync object.
+ */
+static void drm_syncobj_assign_null_handle(struct drm_syncobj *syncobj)
{
- struct drm_syncobj_stub_fence *fence;
- fence = kzalloc(sizeof(*fence), GFP_KERNEL);
- if (fence == NULL)
- return -ENOMEM;
+ struct dma_fence *fence = dma_fence_get_stub();
- spin_lock_init(&fence->lock);
- dma_fence_init(&fence->base, &drm_syncobj_stub_fence_ops,
- &fence->lock, 0, 0);
- dma_fence_signal(&fence->base);
-
- drm_syncobj_replace_fence(syncobj, 0, &fence->base);
-
- dma_fence_put(&fence->base);
-
- return 0;
+ drm_syncobj_replace_fence(syncobj, 0, fence);
+ dma_fence_put(fence);
}
/**
@@ -274,7 +253,6 @@ EXPORT_SYMBOL(drm_syncobj_free);
int drm_syncobj_create(struct drm_syncobj **out_syncobj, uint32_t flags,
struct dma_fence *fence)
{
- int ret;
struct drm_syncobj *syncobj;
syncobj = kzalloc(sizeof(struct drm_syncobj), GFP_KERNEL);
@@ -285,13 +263,8 @@ int drm_syncobj_create(struct drm_syncobj **out_syncobj,
uint32_t flags,
INIT_LIST_HEAD(&syncobj->cb_list);
spin_lock_init(&syncobj->lock);
- if (flags & DRM_SYNCOBJ_CREATE_SIGNALED) {
- ret = drm_syncobj_assign_null_handle(syncobj);
- if (ret < 0) {
- drm_syncobj_put(syncobj);
- return ret;
- }
- }
+ if (flags & DRM_SYNCOBJ_CREATE_SIGNALED)
+ drm_syncobj_assign_null_handle(syncobj);
if (fence)
drm_syncobj_replace_fence(syncobj, 0, fence);
@@ -982,11 +955,8 @@ drm_syncobj_signal_ioctl(struct drm_device *dev, void
*data,
if (ret < 0)
return ret;
- for (i = 0; i < args->count_handles; i++) {
- ret = drm_syncobj_assign_null_handle(syncobjs[i]);
- if (ret < 0)
- break;
- }
+ for (i = 0; i < args->count_handles; i++)
+ drm_syncobj_assign_null_handle(syncobjs[i]);
drm_syncobj_array_free(syncobjs, args->count_handles);
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/amdgpu: fix NULL fence handling in amdgpu_cs_fence_to_handle_ioctl
When the fence is already signaled it is perfectly normal to get a NULL
fence here. But since we can't export that we need to use a stub fence.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 024dfbd87f11..fe6bec2075c4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -1421,6 +1421,9 @@ int amdgpu_cs_fence_to_handle_ioctl(struct drm_device
*dev, void *data,
if (IS_ERR(fence))
return PTR_ERR(fence);
+ if (!fence)
+ fence = dma_fence_get_stub();
+
switch (info->in.what) {
case AMDGPU_FENCE_TO_HANDLE_GET_SYNCOBJ:
r = drm_syncobj_create(&syncobj, 0, fence);
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] dma-buf: add dma_fence_get_stub
Extract of useful code from the timeline work. This provides a function
to return a stub or dummy fence which is always signaled.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-fence.c | 36 +++-
include/linux/dma-fence.h | 1 +
2 files changed, 36 insertions(+), 1 deletion(-)
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 1551ca7df394..136ec04d683f 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -30,13 +30,16 @@
EXPORT_TRACEPOINT_SYMBOL(dma_fence_emit);
EXPORT_TRACEPOINT_SYMBOL(dma_fence_enable_signal);
+static DEFINE_SPINLOCK(dma_fence_stub_lock);
+static struct dma_fence dma_fence_stub;
+
/*
* fence context counter: each execution context should have its own
* fence context, this allows checking if fences belong to the same
* context or not. One device can have multiple separate contexts,
* and they're used if some engine can run independently of another.
*/
-static atomic64_t dma_fence_context_counter = ATOMIC64_INIT(0);
+static atomic64_t dma_fence_context_counter = ATOMIC64_INIT(1);
/**
* DOC: DMA fences overview
@@ -68,6 +71,37 @@ static atomic64_t dma_fence_context_counter =
ATOMIC64_INIT(0);
* &dma_buf.resv pointer.
*/
+static const char *dma_fence_stub_get_name(struct dma_fence *fence)
+{
+return "stub";
+}
+
+static const struct dma_fence_ops dma_fence_stub_ops = {
+ .get_driver_name = dma_fence_stub_get_name,
+ .get_timeline_name = dma_fence_stub_get_name,
+};
+
+/**
+ * dma_fence_get_stub - return a signaled fence
+ *
+ * Return a stub fence which is already signaled.
+ */
+struct dma_fence *dma_fence_get_stub(void)
+{
+ spin_lock(&dma_fence_stub_lock);
+ if (!dma_fence_stub.ops) {
+ dma_fence_init(&dma_fence_stub,
+ &dma_fence_stub_ops,
+ &dma_fence_stub_lock,
+ 0, 0);
+ dma_fence_signal_locked(&dma_fence_stub);
+ }
+ spin_unlock(&dma_fence_stub_lock);
+
+ return dma_fence_get(&dma_fence_stub);
+}
+EXPORT_SYMBOL(dma_fence_get_stub);
+
/**
* dma_fence_context_alloc - allocate an array of fence contexts
* @num: amount of contexts to allocate
diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
index 02dba8cd033d..999e4b104410 100644
--- a/include/linux/dma-fence.h
+++ b/include/linux/dma-fence.h
@@ -541,6 +541,7 @@ static inline signed long dma_fence_wait(struct dma_fence
*fence, bool intr)
return ret < 0 ? ret : 0;
}
+struct dma_fence *dma_fence_get_stub(void);
u64 dma_fence_context_alloc(unsigned num);
#define DMA_FENCE_TRACE(f, fmt, args...) \
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108781] 4.19 Regression - Hawaii (R9 390) boot failure - Invalid PCC GPIO / invalid powerlevel state / Fatal error during GPU init
https://bugs.freedesktop.org/show_bug.cgi?id=108781 alex...@tut.by changed: What|Removed |Added CC||alex...@tut.by --- Comment #34 from alex...@tut.by --- (In reply to Alex Deucher from comment #33) > (In reply to alex.vl from comment #31) > > Comment on attachment 142687 [details] [review] [review] > > Patch to workaround FATAL issue on VCE2.0 ringtest initialization . > > > > Note: Its just workaround . > > > > I see 2 problems : > > - Issue with HW initialization. ( why VCE2.0 ringtest not pass ) > > - Driver-cleanup issue : cause ( Memory manager not clean during takedown.) > > Likely a duplicate of bug 108608. Have you tried the patch there (also > mentioned in comment 22)? FYI : No success (applying patch :https://patchwork.freedesktop.org/patch/259364/) ( seems isn't bug 108608 -- something else ) Notes My case is : (HW config: CPU:FX-9590 ; MB:M5A99Fx pro r2.0 ; GPU:R9 290 4G ) kernel v linux-4.19.6: - Boot normal till amdgpu module load - Then "black screen" - after ~5..10 sec fallbacked to VESA mode. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 02/11] dma-buf: add new dma_fence_chain container v2
在 2018/12/3 19:00, Christian König 写道:
> Am 03.12.18 um 06:25 schrieb zhoucm1:
>>
>>
>> On 2018年11月28日 22:50, Christian König wrote:
>>> Lockless container implementation similar to a dma_fence_array, but
>>> with
>>> only two elements per node and automatic garbage collection.
>>>
>>> v2: properly document dma_fence_chain_for_each, add
>>> dma_fence_chain_find_seqno,
>>> drop prev reference during garbage collection if it's not a
>>> chain fence.
>>>
>>> Signed-off-by: Christian König
>>> ---
>>> drivers/dma-buf/Makefile | 3 +-
>>> drivers/dma-buf/dma-fence-chain.c | 235
>>> ++
>>> include/linux/dma-fence-chain.h | 79 +
>>> 3 files changed, 316 insertions(+), 1 deletion(-)
>>> create mode 100644 drivers/dma-buf/dma-fence-chain.c
>>> create mode 100644 include/linux/dma-fence-chain.h
>>>
>>> diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile
>>> index 0913a6ccab5a..1f006e083eb9 100644
>>> --- a/drivers/dma-buf/Makefile
>>> +++ b/drivers/dma-buf/Makefile
>>> @@ -1,4 +1,5 @@
>>> -obj-y := dma-buf.o dma-fence.o dma-fence-array.o reservation.o
>>> seqno-fence.o
>>> +obj-y := dma-buf.o dma-fence.o dma-fence-array.o dma-fence-chain.o \
>>> + reservation.o seqno-fence.o
>>> obj-$(CONFIG_SYNC_FILE) += sync_file.o
>>> obj-$(CONFIG_SW_SYNC) += sw_sync.o sync_debug.o
>>> obj-$(CONFIG_UDMABUF) += udmabuf.o
>>> diff --git a/drivers/dma-buf/dma-fence-chain.c
>>> b/drivers/dma-buf/dma-fence-chain.c
>>> new file mode 100644
>>> index ..de05101fc48d
>>> --- /dev/null
>>> +++ b/drivers/dma-buf/dma-fence-chain.c
>>> @@ -0,0 +1,235 @@
>>> +/*
>>> + * fence-chain: chain fences together in a timeline
>>> + *
>>> + * Copyright (C) 2018 Advanced Micro Devices, Inc.
>>> + * Authors:
>>> + * Christian König
>>> + *
>>> + * This program is free software; you can redistribute it and/or
>>> modify it
>>> + * under the terms of the GNU General Public License version 2 as
>>> published by
>>> + * the Free Software Foundation.
>>> + *
>>> + * This program is distributed in the hope that it will be useful,
>>> but WITHOUT
>>> + * ANY WARRANTY; without even the implied warranty of
>>> MERCHANTABILITY or
>>> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public
>>> License for
>>> + * more details.
>>> + */
>>> +
>>> +#include
>>> +
>>> +static bool dma_fence_chain_enable_signaling(struct dma_fence *fence);
>>> +
>>> +/**
>>> + * dma_fence_chain_get_prev - use RCU to get a reference to the
>>> previous fence
>>> + * @chain: chain node to get the previous node from
>>> + *
>>> + * Use dma_fence_get_rcu_safe to get a reference to the previous
>>> fence of the
>>> + * chain node.
>>> + */
>>> +static struct dma_fence *dma_fence_chain_get_prev(struct
>>> dma_fence_chain *chain)
>>> +{
>>> + struct dma_fence *prev;
>>> +
>>> + rcu_read_lock();
>>> + prev = dma_fence_get_rcu_safe(&chain->prev);
>>> + rcu_read_unlock();
>>> + return prev;
>>> +}
>>> +
>>> +/**
>>> + * dma_fence_chain_walk - chain walking function
>>> + * @fence: current chain node
>>> + *
>>> + * Walk the chain to the next node. Returns the next fence or NULL
>>> if we are at
>>> + * the end of the chain. Garbage collects chain nodes which are
>>> already
>>> + * signaled.
>>> + */
>>> +struct dma_fence *dma_fence_chain_walk(struct dma_fence *fence)
>>> +{
>>> + struct dma_fence_chain *chain, *prev_chain;
>>> + struct dma_fence *prev, *replacement, *tmp;
>>> +
>>> + chain = to_dma_fence_chain(fence);
>>> + if (!chain) {
>>> + dma_fence_put(fence);
>>> + return NULL;
>>> + }
>>> +
>>> + while ((prev = dma_fence_chain_get_prev(chain))) {
>>> +
>>> + prev_chain = to_dma_fence_chain(prev);
>>> + if (prev_chain) {
>>> + if (!dma_fence_is_signaled(prev_chain->fence))
>>> + break;
>>> +
>>> + replacement = dma_fence_chain_get_prev(prev_chain);
>>> + } else {
>>> + if (!dma_fence_is_signaled(prev))
>>> + break;
>>> +
>>> + replacement = NULL;
>>> + }
>>> +
>>> + tmp = cmpxchg(&chain->prev, prev, replacement);
>>> + if (tmp == prev)
>>> + dma_fence_put(tmp);
>>> + else
>>> + dma_fence_put(replacement);
>>> + dma_fence_put(prev);
>>> + }
>>> +
>>> + dma_fence_put(fence);
>>> + return prev;
>>> +}
>>> +EXPORT_SYMBOL(dma_fence_chain_walk);
>>> +
>>> +/**
>>> + * dma_fence_chain_find_seqno - find fence chain node by seqno
>>> + * @pfence: pointer to the chain node where to start
>>> + * @seqno: the sequence number to search for
>>> + *
>>> + * Advance the fence pointer to the chain node which will signal
>>> this sequence
>>> + * number. If no sequence number is provided then this is a no-op.
>>> + *
>>> + * Returns EINVAL if the fence is not a chain node or the sequence
>>> number has
>>> + * not yet advanced far enou
[Bug 108781] 4.19 Regression - Hawaii (R9 390) boot failure - Invalid PCC GPIO / invalid powerlevel state / Fatal error during GPU init
https://bugs.freedesktop.org/show_bug.cgi?id=108781 --- Comment #35 from alex...@tut.by --- Created attachment 142701 --> https://bugs.freedesktop.org/attachment.cgi?id=142701&action=edit Full dmesg && lspci (failure) on linux-4.19.6 + pcifix (https://patchwork.freedesktop.org/patch/259364/) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 02/11] dma-buf: add new dma_fence_chain container v2
Am 03.12.18 um 14:18 schrieb Chunming Zhou:
在 2018/12/3 19:00, Christian König 写道:
Am 03.12.18 um 06:25 schrieb zhoucm1:
On 2018年11月28日 22:50, Christian König wrote:
Lockless container implementation similar to a dma_fence_array, but
with
only two elements per node and automatic garbage collection.
v2: properly document dma_fence_chain_for_each, add
dma_fence_chain_find_seqno,
drop prev reference during garbage collection if it's not a
chain fence.
Signed-off-by: Christian König
---
drivers/dma-buf/Makefile | 3 +-
drivers/dma-buf/dma-fence-chain.c | 235
++
include/linux/dma-fence-chain.h | 79 +
3 files changed, 316 insertions(+), 1 deletion(-)
create mode 100644 drivers/dma-buf/dma-fence-chain.c
create mode 100644 include/linux/dma-fence-chain.h
diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile
index 0913a6ccab5a..1f006e083eb9 100644
--- a/drivers/dma-buf/Makefile
+++ b/drivers/dma-buf/Makefile
@@ -1,4 +1,5 @@
-obj-y := dma-buf.o dma-fence.o dma-fence-array.o reservation.o
seqno-fence.o
+obj-y := dma-buf.o dma-fence.o dma-fence-array.o dma-fence-chain.o \
+ reservation.o seqno-fence.o
obj-$(CONFIG_SYNC_FILE) += sync_file.o
obj-$(CONFIG_SW_SYNC) += sw_sync.o sync_debug.o
obj-$(CONFIG_UDMABUF) += udmabuf.o
diff --git a/drivers/dma-buf/dma-fence-chain.c
b/drivers/dma-buf/dma-fence-chain.c
new file mode 100644
index ..de05101fc48d
--- /dev/null
+++ b/drivers/dma-buf/dma-fence-chain.c
@@ -0,0 +1,235 @@
+/*
+ * fence-chain: chain fences together in a timeline
+ *
+ * Copyright (C) 2018 Advanced Micro Devices, Inc.
+ * Authors:
+ * Christian König
+ *
+ * This program is free software; you can redistribute it and/or
modify it
+ * under the terms of the GNU General Public License version 2 as
published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public
License for
+ * more details.
+ */
+
+#include
+
+static bool dma_fence_chain_enable_signaling(struct dma_fence *fence);
+
+/**
+ * dma_fence_chain_get_prev - use RCU to get a reference to the
previous fence
+ * @chain: chain node to get the previous node from
+ *
+ * Use dma_fence_get_rcu_safe to get a reference to the previous
fence of the
+ * chain node.
+ */
+static struct dma_fence *dma_fence_chain_get_prev(struct
dma_fence_chain *chain)
+{
+ struct dma_fence *prev;
+
+ rcu_read_lock();
+ prev = dma_fence_get_rcu_safe(&chain->prev);
+ rcu_read_unlock();
+ return prev;
+}
+
+/**
+ * dma_fence_chain_walk - chain walking function
+ * @fence: current chain node
+ *
+ * Walk the chain to the next node. Returns the next fence or NULL
if we are at
+ * the end of the chain. Garbage collects chain nodes which are
already
+ * signaled.
+ */
+struct dma_fence *dma_fence_chain_walk(struct dma_fence *fence)
+{
+ struct dma_fence_chain *chain, *prev_chain;
+ struct dma_fence *prev, *replacement, *tmp;
+
+ chain = to_dma_fence_chain(fence);
+ if (!chain) {
+ dma_fence_put(fence);
+ return NULL;
+ }
+
+ while ((prev = dma_fence_chain_get_prev(chain))) {
+
+ prev_chain = to_dma_fence_chain(prev);
+ if (prev_chain) {
+ if (!dma_fence_is_signaled(prev_chain->fence))
+ break;
+
+ replacement = dma_fence_chain_get_prev(prev_chain);
+ } else {
+ if (!dma_fence_is_signaled(prev))
+ break;
+
+ replacement = NULL;
+ }
+
+ tmp = cmpxchg(&chain->prev, prev, replacement);
+ if (tmp == prev)
+ dma_fence_put(tmp);
+ else
+ dma_fence_put(replacement);
+ dma_fence_put(prev);
+ }
+
+ dma_fence_put(fence);
+ return prev;
+}
+EXPORT_SYMBOL(dma_fence_chain_walk);
+
+/**
+ * dma_fence_chain_find_seqno - find fence chain node by seqno
+ * @pfence: pointer to the chain node where to start
+ * @seqno: the sequence number to search for
+ *
+ * Advance the fence pointer to the chain node which will signal
this sequence
+ * number. If no sequence number is provided then this is a no-op.
+ *
+ * Returns EINVAL if the fence is not a chain node or the sequence
number has
+ * not yet advanced far enough.
+ */
+int dma_fence_chain_find_seqno(struct dma_fence **pfence, uint64_t
seqno)
+{
+ struct dma_fence_chain *chain;
+
+ if (!seqno)
+ return 0;
+
+ chain = to_dma_fence_chain(*pfence);
+ if (!chain || chain->base.seqno < seqno)
+ return -EINVAL;
+
+ dma_fence_chain_for_each(*pfence) {
+ if ((*pfence)->context != chain->base.context ||
+ to_dma_fence_chain(*pfence)->prev_seqno < seqno)
+ break;
+ }
+ dma_fence_put(&chain->base);
+
+ return 0;
+}
+EXPORT_SYMBOL(dma_fence_ch
[PATCH] drm/vc4: Add support for X/Y reflection
Add support for X/Y reflection when the plane is using linear or T-tiled
formats. X/Y reflection hasn't been tested on SAND formats, so we reject
them until proper testing/debugging has been done.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/vc4/vc4_plane.c | 55 ++---
1 file changed, 44 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index 75db62cbe468..bdcccf65cde0 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -492,7 +492,7 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
bool mix_plane_alpha;
bool covers_screen;
u32 scl0, scl1, pitch0;
- u32 tiling;
+ u32 tiling, src_y;
u32 hvs_format = format->hvs;
int ret, i;
@@ -520,6 +520,11 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
h_subsample = drm_format_horz_chroma_subsampling(format->drm);
v_subsample = drm_format_vert_chroma_subsampling(format->drm);
+ /* We must point to the last line when Y reflection is enabled. */
+ src_y = vc4_state->src_y;
+ if (state->rotation & DRM_MODE_REFLECT_Y)
+ src_y += vc4_state->src_h[0] - 1;
+
switch (base_format_mod) {
case DRM_FORMAT_MOD_LINEAR:
tiling = SCALER_CTL0_TILING_LINEAR;
@@ -529,9 +534,10 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
* out.
*/
for (i = 0; i < num_planes; i++) {
- vc4_state->offsets[i] += vc4_state->src_y /
+ vc4_state->offsets[i] += src_y /
(i ? v_subsample : 1) *
fb->pitches[i];
+
vc4_state->offsets[i] += vc4_state->src_x /
(i ? h_subsample : 1) *
fb->format->cpp[i];
@@ -557,22 +563,38 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
u32 tiles_w = fb->pitches[0] >> (tile_size_shift -
tile_h_shift);
u32 tiles_l = vc4_state->src_x >> tile_w_shift;
u32 tiles_r = tiles_w - tiles_l;
- u32 tiles_t = vc4_state->src_y >> tile_h_shift;
+ u32 tiles_t = src_y >> tile_h_shift;
/* Intra-tile offsets, which modify the base address (the
* SCALER_PITCH0_TILE_Y_OFFSET tells HVS how to walk from that
* base address).
*/
- u32 tile_y = (vc4_state->src_y >> 4) & 1;
- u32 subtile_y = (vc4_state->src_y >> 2) & 3;
- u32 utile_y = vc4_state->src_y & 3;
+ u32 tile_y = (src_y >> 4) & 1;
+ u32 subtile_y = (src_y >> 2) & 3;
+ u32 utile_y = src_y & 3;
u32 x_off = vc4_state->src_x & tile_w_mask;
- u32 y_off = vc4_state->src_y & tile_h_mask;
+ u32 y_off = src_y & tile_h_mask;
+
+ /* When Y reflection is requested we must set the
+* SCALER_PITCH0_TILE_LINE_DIR flag to tell HVS that all lines
+* after the initial one should be fetched in descending order,
+* which makes sense since we start from the last line and go
+* backward.
+* Don't know why we need y_off = max_y_off - y_off, but it's
+* definitely required (I guess it's also related to the "going
+* backward" situation).
+*/
+ if (state->rotation & DRM_MODE_REFLECT_Y) {
+ y_off = tile_h_mask - y_off;
+ pitch0 = SCALER_PITCH0_TILE_LINE_DIR;
+ } else {
+ pitch0 = 0;
+ }
tiling = SCALER_CTL0_TILING_256B_OR_T;
- pitch0 = (VC4_SET_FIELD(x_off, SCALER_PITCH0_SINK_PIX) |
- VC4_SET_FIELD(y_off, SCALER_PITCH0_TILE_Y_OFFSET) |
- VC4_SET_FIELD(tiles_l, SCALER_PITCH0_TILE_WIDTH_L) |
- VC4_SET_FIELD(tiles_r, SCALER_PITCH0_TILE_WIDTH_R));
+ pitch0 |= (VC4_SET_FIELD(x_off, SCALER_PITCH0_SINK_PIX) |
+ VC4_SET_FIELD(y_off, SCALER_PITCH0_TILE_Y_OFFSET) |
+ VC4_SET_FIELD(tiles_l, SCALER_PITCH0_TILE_WIDTH_L) |
+ VC4_SET_FIELD(tiles_r, SCALER_PITCH0_TILE_WIDTH_R));
vc4_state->offsets[0] += tiles_t * (tiles_w << tile_size_shift);
vc4_state->offsets[0] += subtile_y << 8;
vc4_state->offsets[0] += utile_y << 4;
@@ -611,6 +633,11 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
}
}
+ if (state->rotation & DRM_MODE_REFLECT_MASK) {
+ DRM_DEBUG_K
Re: [PATCH 1/3] dma-buf: add dma_fence_get_stub
The series is Reviewed-by: Chunming Zhou
for patch#2, please remove my Signed-off-by, it's new when using stub
from dma-fence.
-David
在 2018/12/3 21:07, Christian König 写道:
> Extract of useful code from the timeline work. This provides a function
> to return a stub or dummy fence which is always signaled.
>
> Signed-off-by: Christian König
> ---
> drivers/dma-buf/dma-fence.c | 36 +++-
> include/linux/dma-fence.h | 1 +
> 2 files changed, 36 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> index 1551ca7df394..136ec04d683f 100644
> --- a/drivers/dma-buf/dma-fence.c
> +++ b/drivers/dma-buf/dma-fence.c
> @@ -30,13 +30,16 @@
> EXPORT_TRACEPOINT_SYMBOL(dma_fence_emit);
> EXPORT_TRACEPOINT_SYMBOL(dma_fence_enable_signal);
>
> +static DEFINE_SPINLOCK(dma_fence_stub_lock);
> +static struct dma_fence dma_fence_stub;
> +
> /*
>* fence context counter: each execution context should have its own
>* fence context, this allows checking if fences belong to the same
>* context or not. One device can have multiple separate contexts,
>* and they're used if some engine can run independently of another.
>*/
> -static atomic64_t dma_fence_context_counter = ATOMIC64_INIT(0);
> +static atomic64_t dma_fence_context_counter = ATOMIC64_INIT(1);
>
> /**
>* DOC: DMA fences overview
> @@ -68,6 +71,37 @@ static atomic64_t dma_fence_context_counter =
> ATOMIC64_INIT(0);
>* &dma_buf.resv pointer.
>*/
>
> +static const char *dma_fence_stub_get_name(struct dma_fence *fence)
> +{
> +return "stub";
> +}
> +
> +static const struct dma_fence_ops dma_fence_stub_ops = {
> + .get_driver_name = dma_fence_stub_get_name,
> + .get_timeline_name = dma_fence_stub_get_name,
> +};
> +
> +/**
> + * dma_fence_get_stub - return a signaled fence
> + *
> + * Return a stub fence which is already signaled.
> + */
> +struct dma_fence *dma_fence_get_stub(void)
> +{
> + spin_lock(&dma_fence_stub_lock);
> + if (!dma_fence_stub.ops) {
> + dma_fence_init(&dma_fence_stub,
> +&dma_fence_stub_ops,
> +&dma_fence_stub_lock,
> +0, 0);
> + dma_fence_signal_locked(&dma_fence_stub);
> + }
> + spin_unlock(&dma_fence_stub_lock);
> +
> + return dma_fence_get(&dma_fence_stub);
> +}
> +EXPORT_SYMBOL(dma_fence_get_stub);
> +
> /**
>* dma_fence_context_alloc - allocate an array of fence contexts
>* @num: amount of contexts to allocate
> diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
> index 02dba8cd033d..999e4b104410 100644
> --- a/include/linux/dma-fence.h
> +++ b/include/linux/dma-fence.h
> @@ -541,6 +541,7 @@ static inline signed long dma_fence_wait(struct dma_fence
> *fence, bool intr)
> return ret < 0 ? ret : 0;
> }
>
> +struct dma_fence *dma_fence_get_stub(void);
> u64 dma_fence_context_alloc(unsigned num);
>
> #define DMA_FENCE_TRACE(f, fmt, args...) \
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] dma-buf: add dma_fence_get_stub
Am 03.12.18 um 14:33 schrieb Chunming Zhou:
The series is Reviewed-by: Chunming Zhou
for patch#2, please remove my Signed-off-by, it's new when using stub
from dma-fence.
Yeah, ok. There is indeed nothing left from your original code.
Alex, Daniel, Chris any objections that I push the first two patches in
this series to drm-misc-next?
Shouldn't be any functional change,
Christian.
-David
在 2018/12/3 21:07, Christian König 写道:
Extract of useful code from the timeline work. This provides a function
to return a stub or dummy fence which is always signaled.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-fence.c | 36 +++-
include/linux/dma-fence.h | 1 +
2 files changed, 36 insertions(+), 1 deletion(-)
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 1551ca7df394..136ec04d683f 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -30,13 +30,16 @@
EXPORT_TRACEPOINT_SYMBOL(dma_fence_emit);
EXPORT_TRACEPOINT_SYMBOL(dma_fence_enable_signal);
+static DEFINE_SPINLOCK(dma_fence_stub_lock);
+static struct dma_fence dma_fence_stub;
+
/*
* fence context counter: each execution context should have its own
* fence context, this allows checking if fences belong to the same
* context or not. One device can have multiple separate contexts,
* and they're used if some engine can run independently of another.
*/
-static atomic64_t dma_fence_context_counter = ATOMIC64_INIT(0);
+static atomic64_t dma_fence_context_counter = ATOMIC64_INIT(1);
/**
* DOC: DMA fences overview
@@ -68,6 +71,37 @@ static atomic64_t dma_fence_context_counter =
ATOMIC64_INIT(0);
* &dma_buf.resv pointer.
*/
+static const char *dma_fence_stub_get_name(struct dma_fence *fence)
+{
+return "stub";
+}
+
+static const struct dma_fence_ops dma_fence_stub_ops = {
+ .get_driver_name = dma_fence_stub_get_name,
+ .get_timeline_name = dma_fence_stub_get_name,
+};
+
+/**
+ * dma_fence_get_stub - return a signaled fence
+ *
+ * Return a stub fence which is already signaled.
+ */
+struct dma_fence *dma_fence_get_stub(void)
+{
+ spin_lock(&dma_fence_stub_lock);
+ if (!dma_fence_stub.ops) {
+ dma_fence_init(&dma_fence_stub,
+ &dma_fence_stub_ops,
+ &dma_fence_stub_lock,
+ 0, 0);
+ dma_fence_signal_locked(&dma_fence_stub);
+ }
+ spin_unlock(&dma_fence_stub_lock);
+
+ return dma_fence_get(&dma_fence_stub);
+}
+EXPORT_SYMBOL(dma_fence_get_stub);
+
/**
* dma_fence_context_alloc - allocate an array of fence contexts
* @num: amount of contexts to allocate
diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
index 02dba8cd033d..999e4b104410 100644
--- a/include/linux/dma-fence.h
+++ b/include/linux/dma-fence.h
@@ -541,6 +541,7 @@ static inline signed long dma_fence_wait(struct dma_fence
*fence, bool intr)
return ret < 0 ? ret : 0;
}
+struct dma_fence *dma_fence_get_stub(void);
u64 dma_fence_context_alloc(unsigned num);
#define DMA_FENCE_TRACE(f, fmt, args...) \
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 02/11] dma-buf: add new dma_fence_chain container v2
在 2018/12/3 21:28, Christian König 写道:
> Am 03.12.18 um 14:18 schrieb Chunming Zhou:
>>
>> 在 2018/12/3 19:00, Christian König 写道:
>>> Am 03.12.18 um 06:25 schrieb zhoucm1:
On 2018年11月28日 22:50, Christian König wrote:
> Lockless container implementation similar to a dma_fence_array, but
> with
> only two elements per node and automatic garbage collection.
>
> v2: properly document dma_fence_chain_for_each, add
> dma_fence_chain_find_seqno,
> drop prev reference during garbage collection if it's not a
> chain fence.
>
> Signed-off-by: Christian König
> ---
> drivers/dma-buf/Makefile | 3 +-
> drivers/dma-buf/dma-fence-chain.c | 235
> ++
> include/linux/dma-fence-chain.h | 79 +
> 3 files changed, 316 insertions(+), 1 deletion(-)
> create mode 100644 drivers/dma-buf/dma-fence-chain.c
> create mode 100644 include/linux/dma-fence-chain.h
>
> diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile
> index 0913a6ccab5a..1f006e083eb9 100644
> --- a/drivers/dma-buf/Makefile
> +++ b/drivers/dma-buf/Makefile
> @@ -1,4 +1,5 @@
> -obj-y := dma-buf.o dma-fence.o dma-fence-array.o reservation.o
> seqno-fence.o
> +obj-y := dma-buf.o dma-fence.o dma-fence-array.o dma-fence-chain.o \
> + reservation.o seqno-fence.o
> obj-$(CONFIG_SYNC_FILE) += sync_file.o
> obj-$(CONFIG_SW_SYNC) += sw_sync.o sync_debug.o
> obj-$(CONFIG_UDMABUF) += udmabuf.o
> diff --git a/drivers/dma-buf/dma-fence-chain.c
> b/drivers/dma-buf/dma-fence-chain.c
> new file mode 100644
> index ..de05101fc48d
> --- /dev/null
> +++ b/drivers/dma-buf/dma-fence-chain.c
> @@ -0,0 +1,235 @@
> +/*
> + * fence-chain: chain fences together in a timeline
> + *
> + * Copyright (C) 2018 Advanced Micro Devices, Inc.
> + * Authors:
> + * Christian König
> + *
> + * This program is free software; you can redistribute it and/or
> modify it
> + * under the terms of the GNU General Public License version 2 as
> published by
> + * the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of
> MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public
> License for
> + * more details.
> + */
> +
> +#include
> +
> +static bool dma_fence_chain_enable_signaling(struct dma_fence
> *fence);
> +
> +/**
> + * dma_fence_chain_get_prev - use RCU to get a reference to the
> previous fence
> + * @chain: chain node to get the previous node from
> + *
> + * Use dma_fence_get_rcu_safe to get a reference to the previous
> fence of the
> + * chain node.
> + */
> +static struct dma_fence *dma_fence_chain_get_prev(struct
> dma_fence_chain *chain)
> +{
> + struct dma_fence *prev;
> +
> + rcu_read_lock();
> + prev = dma_fence_get_rcu_safe(&chain->prev);
> + rcu_read_unlock();
> + return prev;
> +}
> +
> +/**
> + * dma_fence_chain_walk - chain walking function
> + * @fence: current chain node
> + *
> + * Walk the chain to the next node. Returns the next fence or NULL
> if we are at
> + * the end of the chain. Garbage collects chain nodes which are
> already
> + * signaled.
> + */
> +struct dma_fence *dma_fence_chain_walk(struct dma_fence *fence)
> +{
> + struct dma_fence_chain *chain, *prev_chain;
> + struct dma_fence *prev, *replacement, *tmp;
> +
> + chain = to_dma_fence_chain(fence);
> + if (!chain) {
> + dma_fence_put(fence);
> + return NULL;
> + }
> +
> + while ((prev = dma_fence_chain_get_prev(chain))) {
> +
> + prev_chain = to_dma_fence_chain(prev);
> + if (prev_chain) {
> + if (!dma_fence_is_signaled(prev_chain->fence))
> + break;
> +
> + replacement = dma_fence_chain_get_prev(prev_chain);
> + } else {
> + if (!dma_fence_is_signaled(prev))
> + break;
> +
> + replacement = NULL;
> + }
> +
> + tmp = cmpxchg(&chain->prev, prev, replacement);
> + if (tmp == prev)
> + dma_fence_put(tmp);
> + else
> + dma_fence_put(replacement);
> + dma_fence_put(prev);
> + }
> +
> + dma_fence_put(fence);
> + return prev;
> +}
> +EXPORT_SYMBOL(dma_fence_chain_walk);
> +
> +/**
> + * dma_fence_chain_find_seqno - find fence chain node by seqno
> + * @pfence: pointer to the chain n
Re: [PATCH] drm/vc4: Add support for X/Y reflection
On Mon, Dec 03, 2018 at 02:34:12PM +0100, Boris Brezillon wrote:
> Add support for X/Y reflection when the plane is using linear or T-tiled
> formats. X/Y reflection hasn't been tested on SAND formats, so we reject
> them until proper testing/debugging has been done.
BTW you could also expose 180 degress easily. See
drm_rotation_simplify().
>
> Signed-off-by: Boris Brezillon
> ---
> drivers/gpu/drm/vc4/vc4_plane.c | 55 ++---
> 1 file changed, 44 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
> index 75db62cbe468..bdcccf65cde0 100644
> --- a/drivers/gpu/drm/vc4/vc4_plane.c
> +++ b/drivers/gpu/drm/vc4/vc4_plane.c
> @@ -492,7 +492,7 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
> bool mix_plane_alpha;
> bool covers_screen;
> u32 scl0, scl1, pitch0;
> - u32 tiling;
> + u32 tiling, src_y;
> u32 hvs_format = format->hvs;
> int ret, i;
>
> @@ -520,6 +520,11 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
> h_subsample = drm_format_horz_chroma_subsampling(format->drm);
> v_subsample = drm_format_vert_chroma_subsampling(format->drm);
>
> + /* We must point to the last line when Y reflection is enabled. */
> + src_y = vc4_state->src_y;
> + if (state->rotation & DRM_MODE_REFLECT_Y)
> + src_y += vc4_state->src_h[0] - 1;
> +
> switch (base_format_mod) {
> case DRM_FORMAT_MOD_LINEAR:
> tiling = SCALER_CTL0_TILING_LINEAR;
> @@ -529,9 +534,10 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
>* out.
>*/
> for (i = 0; i < num_planes; i++) {
> - vc4_state->offsets[i] += vc4_state->src_y /
> + vc4_state->offsets[i] += src_y /
>(i ? v_subsample : 1) *
>fb->pitches[i];
> +
> vc4_state->offsets[i] += vc4_state->src_x /
>(i ? h_subsample : 1) *
>fb->format->cpp[i];
> @@ -557,22 +563,38 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
> u32 tiles_w = fb->pitches[0] >> (tile_size_shift -
> tile_h_shift);
> u32 tiles_l = vc4_state->src_x >> tile_w_shift;
> u32 tiles_r = tiles_w - tiles_l;
> - u32 tiles_t = vc4_state->src_y >> tile_h_shift;
> + u32 tiles_t = src_y >> tile_h_shift;
> /* Intra-tile offsets, which modify the base address (the
>* SCALER_PITCH0_TILE_Y_OFFSET tells HVS how to walk from that
>* base address).
>*/
> - u32 tile_y = (vc4_state->src_y >> 4) & 1;
> - u32 subtile_y = (vc4_state->src_y >> 2) & 3;
> - u32 utile_y = vc4_state->src_y & 3;
> + u32 tile_y = (src_y >> 4) & 1;
> + u32 subtile_y = (src_y >> 2) & 3;
> + u32 utile_y = src_y & 3;
> u32 x_off = vc4_state->src_x & tile_w_mask;
> - u32 y_off = vc4_state->src_y & tile_h_mask;
> + u32 y_off = src_y & tile_h_mask;
> +
> + /* When Y reflection is requested we must set the
> + * SCALER_PITCH0_TILE_LINE_DIR flag to tell HVS that all lines
> + * after the initial one should be fetched in descending order,
> + * which makes sense since we start from the last line and go
> + * backward.
> + * Don't know why we need y_off = max_y_off - y_off, but it's
> + * definitely required (I guess it's also related to the "going
> + * backward" situation).
> + */
> + if (state->rotation & DRM_MODE_REFLECT_Y) {
> + y_off = tile_h_mask - y_off;
> + pitch0 = SCALER_PITCH0_TILE_LINE_DIR;
> + } else {
> + pitch0 = 0;
> + }
>
> tiling = SCALER_CTL0_TILING_256B_OR_T;
> - pitch0 = (VC4_SET_FIELD(x_off, SCALER_PITCH0_SINK_PIX) |
> - VC4_SET_FIELD(y_off, SCALER_PITCH0_TILE_Y_OFFSET) |
> - VC4_SET_FIELD(tiles_l, SCALER_PITCH0_TILE_WIDTH_L) |
> - VC4_SET_FIELD(tiles_r, SCALER_PITCH0_TILE_WIDTH_R));
> + pitch0 |= (VC4_SET_FIELD(x_off, SCALER_PITCH0_SINK_PIX) |
> +VC4_SET_FIELD(y_off, SCALER_PITCH0_TILE_Y_OFFSET) |
> +VC4_SET_FIELD(tiles_l, SCALER_PITCH0_TILE_WIDTH_L) |
> +VC4_SET_FIELD(tiles_r, SCALER_PITCH0_TILE_WIDTH_R));
> vc4_state->offsets[0] += tiles_t * (tiles_w << tile_size_shift);
> vc4_state->offsets[0] += subtile_y << 8;
> vc4_state->offsets[0] += utile_y << 4;
> @@ -611,6 +633,11 @@ static
Re: [PATCH 02/11] dma-buf: add new dma_fence_chain container v2
Am 03.12.18 um 14:44 schrieb Chunming Zhou:
在 2018/12/3 21:28, Christian König 写道:
Am 03.12.18 um 14:18 schrieb Chunming Zhou:
在 2018/12/3 19:00, Christian König 写道:
Am 03.12.18 um 06:25 schrieb zhoucm1:
On 2018年11月28日 22:50, Christian König wrote:
Lockless container implementation similar to a dma_fence_array, but
with
only two elements per node and automatic garbage collection.
v2: properly document dma_fence_chain_for_each, add
dma_fence_chain_find_seqno,
drop prev reference during garbage collection if it's not a
chain fence.
Signed-off-by: Christian König
---
drivers/dma-buf/Makefile | 3 +-
drivers/dma-buf/dma-fence-chain.c | 235
++
include/linux/dma-fence-chain.h | 79 +
3 files changed, 316 insertions(+), 1 deletion(-)
create mode 100644 drivers/dma-buf/dma-fence-chain.c
create mode 100644 include/linux/dma-fence-chain.h
diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile
index 0913a6ccab5a..1f006e083eb9 100644
--- a/drivers/dma-buf/Makefile
+++ b/drivers/dma-buf/Makefile
@@ -1,4 +1,5 @@
-obj-y := dma-buf.o dma-fence.o dma-fence-array.o reservation.o
seqno-fence.o
+obj-y := dma-buf.o dma-fence.o dma-fence-array.o dma-fence-chain.o \
+ reservation.o seqno-fence.o
obj-$(CONFIG_SYNC_FILE) += sync_file.o
obj-$(CONFIG_SW_SYNC) += sw_sync.o sync_debug.o
obj-$(CONFIG_UDMABUF) += udmabuf.o
diff --git a/drivers/dma-buf/dma-fence-chain.c
b/drivers/dma-buf/dma-fence-chain.c
new file mode 100644
index ..de05101fc48d
--- /dev/null
+++ b/drivers/dma-buf/dma-fence-chain.c
@@ -0,0 +1,235 @@
+/*
+ * fence-chain: chain fences together in a timeline
+ *
+ * Copyright (C) 2018 Advanced Micro Devices, Inc.
+ * Authors:
+ * Christian König
+ *
+ * This program is free software; you can redistribute it and/or
modify it
+ * under the terms of the GNU General Public License version 2 as
published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public
License for
+ * more details.
+ */
+
+#include
+
+static bool dma_fence_chain_enable_signaling(struct dma_fence
*fence);
+
+/**
+ * dma_fence_chain_get_prev - use RCU to get a reference to the
previous fence
+ * @chain: chain node to get the previous node from
+ *
+ * Use dma_fence_get_rcu_safe to get a reference to the previous
fence of the
+ * chain node.
+ */
+static struct dma_fence *dma_fence_chain_get_prev(struct
dma_fence_chain *chain)
+{
+ struct dma_fence *prev;
+
+ rcu_read_lock();
+ prev = dma_fence_get_rcu_safe(&chain->prev);
+ rcu_read_unlock();
+ return prev;
+}
+
+/**
+ * dma_fence_chain_walk - chain walking function
+ * @fence: current chain node
+ *
+ * Walk the chain to the next node. Returns the next fence or NULL
if we are at
+ * the end of the chain. Garbage collects chain nodes which are
already
+ * signaled.
+ */
+struct dma_fence *dma_fence_chain_walk(struct dma_fence *fence)
+{
+ struct dma_fence_chain *chain, *prev_chain;
+ struct dma_fence *prev, *replacement, *tmp;
+
+ chain = to_dma_fence_chain(fence);
+ if (!chain) {
+ dma_fence_put(fence);
+ return NULL;
+ }
+
+ while ((prev = dma_fence_chain_get_prev(chain))) {
+
+ prev_chain = to_dma_fence_chain(prev);
+ if (prev_chain) {
+ if (!dma_fence_is_signaled(prev_chain->fence))
+ break;
+
+ replacement = dma_fence_chain_get_prev(prev_chain);
+ } else {
+ if (!dma_fence_is_signaled(prev))
+ break;
+
+ replacement = NULL;
+ }
+
+ tmp = cmpxchg(&chain->prev, prev, replacement);
+ if (tmp == prev)
+ dma_fence_put(tmp);
+ else
+ dma_fence_put(replacement);
+ dma_fence_put(prev);
+ }
+
+ dma_fence_put(fence);
+ return prev;
+}
+EXPORT_SYMBOL(dma_fence_chain_walk);
+
+/**
+ * dma_fence_chain_find_seqno - find fence chain node by seqno
+ * @pfence: pointer to the chain node where to start
+ * @seqno: the sequence number to search for
+ *
+ * Advance the fence pointer to the chain node which will signal
this sequence
+ * number. If no sequence number is provided then this is a no-op.
+ *
+ * Returns EINVAL if the fence is not a chain node or the sequence
number has
+ * not yet advanced far enough.
+ */
+int dma_fence_chain_find_seqno(struct dma_fence **pfence, uint64_t
seqno)
+{
+ struct dma_fence_chain *chain;
+
+ if (!seqno)
+ return 0;
+
+ chain = to_dma_fence_chain(*pfence);
+ if (!chain || chain->base.seqno < seqno)
+ return -EINVAL;
+
+ dma_fence_chain_for_each(*pfence) {
+ if ((*pfence)->context != chain->base.context ||
+ to_dma_fence_chain(*pfence)->prev_seqno < seqno)
+ b
Re: [PATCH] of/device: add blacklist for iommu dma_ops
On Mon, Dec 3, 2018 at 7:45 AM Robin Murphy wrote: > > Hi Rob, > > On 01/12/2018 16:53, Rob Clark wrote: > > This solves a problem we see with drm/msm, caused by getting > > iommu_dma_ops while we attach our own domain and manage it directly at > > the iommu API level: > > > >[0038] user address but active_mm is swapper > >Internal error: Oops: 9605 [#1] PREEMPT SMP > >Modules linked in: > >CPU: 7 PID: 70 Comm: kworker/7:1 Tainted: GW 4.19.3 #90 > >Hardware name: xxx (DT) > >Workqueue: events deferred_probe_work_func > >pstate: 80c9 (Nzcv daif +PAN +UAO) > >pc : iommu_dma_map_sg+0x7c/0x2c8 > >lr : iommu_dma_map_sg+0x40/0x2c8 > >sp : ff80095eb4f0 > >x29: ff80095eb4f0 x28: > >x27: ffc0f9431578 x26: > >x25: x24: 0003 > >x23: 0001 x22: ffc0fa9ac010 > >x21: x20: ffc0fab40980 > >x19: ffc0fab40980 x18: 0003 > >x17: 01c4 x16: 0007 > >x15: 000e x14: > >x13: x12: 0028 > >x11: 0101010101010101 x10: 7f7f7f7f7f7f7f7f > >x9 : x8 : ffc0fab409a0 > >x7 : x6 : 0002 > >x5 : 0001 x4 : > >x3 : 0001 x2 : 0002 > >x1 : ffc0f9431578 x0 : > >Process kworker/7:1 (pid: 70, stack limit = 0x17d08ffb) > >Call trace: > > iommu_dma_map_sg+0x7c/0x2c8 > > __iommu_map_sg_attrs+0x70/0x84 > > get_pages+0x170/0x1e8 > > msm_gem_get_iova+0x8c/0x128 > > _msm_gem_kernel_new+0x6c/0xc8 > > msm_gem_kernel_new+0x4c/0x58 > > dsi_tx_buf_alloc_6g+0x4c/0x8c > > msm_dsi_host_modeset_init+0xc8/0x108 > > msm_dsi_modeset_init+0x54/0x18c > > _dpu_kms_drm_obj_init+0x430/0x474 > > dpu_kms_hw_init+0x5f8/0x6b4 > > msm_drm_bind+0x360/0x6c8 > > try_to_bring_up_master.part.7+0x28/0x70 > > component_master_add_with_match+0xe8/0x124 > > msm_pdev_probe+0x294/0x2b4 > > platform_drv_probe+0x58/0xa4 > > really_probe+0x150/0x294 > > driver_probe_device+0xac/0xe8 > > __device_attach_driver+0xa4/0xb4 > > bus_for_each_drv+0x98/0xc8 > > __device_attach+0xac/0x12c > > device_initial_probe+0x24/0x30 > > bus_probe_device+0x38/0x98 > > deferred_probe_work_func+0x78/0xa4 > > process_one_work+0x24c/0x3dc > > worker_thread+0x280/0x360 > > kthread+0x134/0x13c > > ret_from_fork+0x10/0x18 > >Code: d284 91000725 6b17039f 5400048a (f9401f40) > >---[ end trace f22dda57f3648e2c ]--- > >Kernel panic - not syncing: Fatal exception > >SMP: stopping secondary CPUs > >Kernel Offset: disabled > >CPU features: 0x0,22802a18 > >Memory Limit: none > > > > The problem is that when drm/msm does it's own iommu_attach_device(), > > now the domain returned by iommu_get_domain_for_dev() is drm/msm's > > domain, and it doesn't have domain->iova_cookie. > > Does this crash still happen with 4.20-rc? Because as of 6af588fed391 it > really shouldn't. for this hw, I'm still on 4.19, although that does look like it would avoid the issue. > > We kind of avoided this problem prior to sdm845/dpu because the iommu > > was attached to the mdp node in dt, which is a child of the toplevel > > mdss node (which corresponds to the dev passed in dma_map_sg()). But > > with sdm845, now the iommu is attached at the mdss level so we hit the > > iommu_dma_ops in dma_map_sg(). > > > > But auto allocating/attaching a domain before the driver is probed was > > already a blocking problem for enabling per-context pagetables for the > > GPU. This problem is also now solved with this patch. > > s/solved/worked around/ > > If you want a guarantee of actually getting a specific hardware context > allocated for a given domain, there needs to be code in the IOMMU driver > to understand and honour that. Implicitly depending on whatever happens > to fall out of current driver behaviour on current systems is not a real > solution. ok, fair.. but I'll settle for "works" in the absence of better options.. At some level, it would be nice to be able to optionally specify a context-bank in the iommu bindings. But not sure how to make that fit w/ cb allocated per domain. And I assume I'm the only one who has this problem? > > Fixes: 97890ba9289c dma-mapping: detect and configure IOMMU in > > of_dma_configure > > That's rather misleading, since the crash described above depends on at > least two other major changes which came long after that commit. Fair, when I realized it was the difference in where the iommu attaches between dpu1 (sdm845) and everything coming before, I should have removed the tag. BR, -R > It's not that I don't understand exactly what you want here - just that > this commit message isn't a coheren
Re: [Freedreno] [PATCH v2 5/5] drm/msm: subclass work object for vblank events
On Fri, Nov 30, 2018 at 04:21:15PM -0800, Jeykumar Sankaran wrote: > On 2018-11-30 12:07, Sean Paul wrote: > > On Fri, Nov 30, 2018 at 11:45:55AM -0800, Jeykumar Sankaran wrote: > > > On 2018-11-29 14:15, Sean Paul wrote: > > > > On Tue, Nov 20, 2018 at 02:04:14PM -0800, Jeykumar Sankaran wrote: > > > > > On 2018-11-07 07:55, Sean Paul wrote: > > > > > > On Tue, Nov 06, 2018 at 02:36:30PM -0800, Jeykumar Sankaran wrote: > > > > > > > msm maintains a separate structure to define vblank > > > > > > > work definitions and a list to track events submitted > > > > > > > to the workqueue. We can avoid this redundant list > > > > > > > and its protection mechanism, if we subclass the > > > > > > > work object to encapsulate vblank event parameters. > > > > > > > > > > > > > > changes in v2: > > > > > > > - subclass optimization on system wq (Sean Paul) > > > > > > > > > > > > I wouldn't do it like this, tbh. One problem is that you've lost > > your > > > > > > flush() on > > > > > > unbind, so there's no way to know if you have workers in the wild > > > > > > waiting > > > > > > to > > > > > > enable/disable vblank. > > > > > > > > > > > > Another issues is that AFAICT, we don't need a queue of > > > > > > enables/disables, > > > > > > but > > > > > > rather just the last requested state (ie: should we be on or off). > > So > > > > > > things > > > > > > don't need to be this complicated (and we're possibly thrashing > > vblank > > > > > > on/off > > > > > > for no reason). > > > > > > > > > > > > I'm still of the mind that you should just make this synchronous > > and > > > > be > > > > > > done > > > > > > with the threads (especially since we're still > > uncovering/introducing > > > > > > races!). > > > > > > > > > > > While scoping out the effort to make vblank events synchronous, I > > > > > found > > > > > that the spinlock locking order of vblank request sequence and > > vblank > > > > > callback > > > > > sequences are the opposite. > > > > > > > > > > In DPU, drm_vblank_enable acquires vblank_time_lock before > > registering > > > > > the crtc to encoder which happens after acquiring encoder_spinlock. > > > > > But > > > > > the vblank_callback acquires encoder_spinlock before accessing the > > > > > registered > > > > > crtc and calling into drm_vblank_handler which tries to acquire > > > > > vblank_time_lock. > > > > > Acquiring both vblank_time_lock and encoder_spinlock in the same > > > > > thread > > > > > is leading to deadlock. > > > > > > > > Hmm, I'm not sure I follow. Are you seeing issues where irq overlaps > > > > with > > > > enable/disable? I hacked in sync vblank enable/disable quickly to see > > if > > > > I > > > > could > > > > reproduce what you're seeing, but things seemed well behaved. > > > > > > > > > > The race is between drm_vblank_get/put and vblank_handler contexts. > > > > > > When made synchronous: > > > > > > while calling drm_vblank_get, the callstack looks like below: > > > drm_vblank_get -> drm_vblank_enable (acquires vblank_time_lock) -> > > > __enable_vblank -> dpu_crtc_vblank -> > > > dpu_encoder_toggle_vblank_for_crtc > > > (tries to acquire enc_spinlock) > > > > > > In vblank handler, the call stack will be: > > > dpu_encoder_phys_vid_vblank_irq -> dpu_encoder_vblank_callback > > > (acquires > > > enc_spinlock) -> dpu_crtc_vblank_callback -> drm_handle_vblank > > > (tries to > > > acquire vblank_time_lock) > > > > Hmm, I'm not sure how this can happen. We acquire and release the > > enc_spinlock > > before enabling the irq, yes we will hold on to the vbl_time_lock, but > > we > > shouldn't be trying to reacquire an encoder's spinlock after we've > > enabled > > it. > In the synchronous approach dpu_encoder_toggle_vblank_for_crtc(which > acquires the enc_spinlock) will be called while we > are holding the vbl_time_lock. > > > I don't know how that can deadlock, since we should never be running > > enable and > > the handler concurrently. > > > I agree that vblank_irq handler should not be running before the enable > sequence. But > don't you expect the handler to be running while calling the vblank_disable > sequence? This is an entirely different problem though. It's also one that is easier to fix. I think we could probably grab the enc_spinlock in disable and clear the crtc pointer. What I'm getting at is that there's no fundamental reason why we need to have async vblank enable/disable. Sean > vbl disable will try to acquire the locks in the opposite order to that of > irq_handler and the > same issue is bound to happen. > > With your patch, you should be able to simulate this deadlock if you can > inject a delay > by adding a pr_err log in vblank_ctrl_queue_work > > Thanks, > Jeykumar S. > > > The only thing I can think of is that the vblank interrupts are firing > > after > > vblank has been disabled? In that case, it seems like we should properly > > flush > > them. > > > > Sean > > > > > > > > > > > > > > I do see that there is a chance to
Re: [Intel-gfx] [PATCH 1/4] drm/i915: Fix GEN9 HDCP1.4 key load process
On Tue, Nov 27, 2018 at 07:32:56PM +0530, Ramalingam C wrote:
> HDCP1.4 key load process varies between Intel platform to platform.
>
> For Gen9 platforms except BXT and GLK, HDCP1.4 key is loaded using
> the GT Driver Mailbox interface. Instead of listing all the platforms
> for this method, adopted this method for all Gen9 platforms with
> exceptions. In this way we need not extent check for new GEN9 platforms
> like CFL.
>
> Signed-off-by: Ramalingam C
Reviewed-by: Sean Paul
> ---
> drivers/gpu/drm/i915/intel_hdcp.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
> b/drivers/gpu/drm/i915/intel_hdcp.c
> index 1bf487f94254..beacfbb6e5e1 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -157,10 +157,12 @@ static int intel_hdcp_load_keys(struct drm_i915_private
> *dev_priv)
> /*
>* Initiate loading the HDCP key from fuses.
>*
> - * BXT+ platforms, HDCP key needs to be loaded by SW. Only SKL and KBL
> - * differ in the key load trigger process from other platforms.
> + * BXT+ platforms, HDCP key needs to be loaded by SW. Only Gen 9
> + * platforms except BXT and GLK, differ in the key load trigger process
> + * from other platforms.
>*/
> - if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv)) {
> + if (IS_GEN9(dev_priv) &&
> + (!IS_BROXTON(dev_priv) && !IS_GEMINILAKE(dev_priv))) {
> mutex_lock(&dev_priv->pcu_lock);
> ret = sandybridge_pcode_write(dev_priv,
> SKL_PCODE_LOAD_HDCP_KEYS, 1);
> --
> 2.7.4
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 2/4] drm/i915: Fix platform coverage for HDCP1.4
On Tue, Nov 27, 2018 at 07:32:57PM +0530, Ramalingam C wrote:
> HDCP1.4 is enabled and validated only on GEN9+ platforms.
>
> Signed-off-by: Ramalingam C
Reviewed-by: Sean Paul
> ---
> drivers/gpu/drm/i915/intel_hdcp.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
> b/drivers/gpu/drm/i915/intel_hdcp.c
> index beacfbb6e5e1..bd60d0e7bbfa 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -770,8 +770,7 @@ static void intel_hdcp_prop_work(struct work_struct *work)
> bool is_hdcp_supported(struct drm_i915_private *dev_priv, enum port port)
> {
> /* PORT E doesn't have HDCP, and PORT F is disabled */
> - return ((INTEL_GEN(dev_priv) >= 8 || IS_HASWELL(dev_priv)) &&
> - !IS_CHERRYVIEW(dev_priv) && port < PORT_E);
> + return ((INTEL_GEN(dev_priv) >= 9) && port < PORT_E);
> }
>
> int intel_hdcp_init(struct intel_connector *connector,
> --
> 2.7.4
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] drm/i915: debug log for REPLY_ACK missing
On Tue, Nov 27, 2018 at 07:32:58PM +0530, Ramalingam C wrote:
> Adding a debug log when the DP_AUX_NATIVE_REPLY_ACK is missing
> for aksv write. This helps to locate the possible non responding
> DP HDCP sinks.
>
> Signed-off-by: Ramalingam C
> ---
> drivers/gpu/drm/i915/intel_dp.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 70ae3d57316b..18e3a5a3d873 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -5390,7 +5390,11 @@ int intel_dp_hdcp_write_an_aksv(struct
> intel_digital_port *intel_dig_port,
> }
>
> reply = (rxbuf[0] >> 4) & DP_AUX_NATIVE_REPLY_MASK;
> - return reply == DP_AUX_NATIVE_REPLY_ACK ? 0 : -EIO;
> + ret = reply == DP_AUX_NATIVE_REPLY_ACK ? 0 : -EIO;
> + if (ret)
> + DRM_DEBUG_KMS("Aksv write: DP_AUX_NATIVE_REPLY_ACK missing\n");
This is pretty hard to read. Could you please change to:
if (reply != DP_AUX_NATIVE_REPLY_ACK) {
DRM_DEBUG_KMS("Aksv write: no DP_AUX_NATIVE_REPLY_ACK %x\n",
reply);
return -EIO
}
return 0;
With this change,
Reviewed-by: Sean Paul
> +
> + return ret;
> }
>
> static int intel_dp_hdcp_read_bksv(struct intel_digital_port *intel_dig_port,
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] of/device: add blacklist for iommu dma_ops
On Mon, Dec 3, 2018 at 7:45 AM Robin Murphy wrote: > > Hi Rob, > > On 01/12/2018 16:53, Rob Clark wrote: > > This solves a problem we see with drm/msm, caused by getting > > iommu_dma_ops while we attach our own domain and manage it directly at > > the iommu API level: > > > >[0038] user address but active_mm is swapper > >Internal error: Oops: 9605 [#1] PREEMPT SMP > >Modules linked in: > >CPU: 7 PID: 70 Comm: kworker/7:1 Tainted: GW 4.19.3 #90 > >Hardware name: xxx (DT) > >Workqueue: events deferred_probe_work_func > >pstate: 80c9 (Nzcv daif +PAN +UAO) > >pc : iommu_dma_map_sg+0x7c/0x2c8 > >lr : iommu_dma_map_sg+0x40/0x2c8 > >sp : ff80095eb4f0 > >x29: ff80095eb4f0 x28: > >x27: ffc0f9431578 x26: > >x25: x24: 0003 > >x23: 0001 x22: ffc0fa9ac010 > >x21: x20: ffc0fab40980 > >x19: ffc0fab40980 x18: 0003 > >x17: 01c4 x16: 0007 > >x15: 000e x14: > >x13: x12: 0028 > >x11: 0101010101010101 x10: 7f7f7f7f7f7f7f7f > >x9 : x8 : ffc0fab409a0 > >x7 : x6 : 0002 > >x5 : 0001 x4 : > >x3 : 0001 x2 : 0002 > >x1 : ffc0f9431578 x0 : > >Process kworker/7:1 (pid: 70, stack limit = 0x17d08ffb) > >Call trace: > > iommu_dma_map_sg+0x7c/0x2c8 > > __iommu_map_sg_attrs+0x70/0x84 > > get_pages+0x170/0x1e8 > > msm_gem_get_iova+0x8c/0x128 > > _msm_gem_kernel_new+0x6c/0xc8 > > msm_gem_kernel_new+0x4c/0x58 > > dsi_tx_buf_alloc_6g+0x4c/0x8c > > msm_dsi_host_modeset_init+0xc8/0x108 > > msm_dsi_modeset_init+0x54/0x18c > > _dpu_kms_drm_obj_init+0x430/0x474 > > dpu_kms_hw_init+0x5f8/0x6b4 > > msm_drm_bind+0x360/0x6c8 > > try_to_bring_up_master.part.7+0x28/0x70 > > component_master_add_with_match+0xe8/0x124 > > msm_pdev_probe+0x294/0x2b4 > > platform_drv_probe+0x58/0xa4 > > really_probe+0x150/0x294 > > driver_probe_device+0xac/0xe8 > > __device_attach_driver+0xa4/0xb4 > > bus_for_each_drv+0x98/0xc8 > > __device_attach+0xac/0x12c > > device_initial_probe+0x24/0x30 > > bus_probe_device+0x38/0x98 > > deferred_probe_work_func+0x78/0xa4 > > process_one_work+0x24c/0x3dc > > worker_thread+0x280/0x360 > > kthread+0x134/0x13c > > ret_from_fork+0x10/0x18 > >Code: d284 91000725 6b17039f 5400048a (f9401f40) > >---[ end trace f22dda57f3648e2c ]--- > >Kernel panic - not syncing: Fatal exception > >SMP: stopping secondary CPUs > >Kernel Offset: disabled > >CPU features: 0x0,22802a18 > >Memory Limit: none > > > > The problem is that when drm/msm does it's own iommu_attach_device(), > > now the domain returned by iommu_get_domain_for_dev() is drm/msm's > > domain, and it doesn't have domain->iova_cookie. > > Does this crash still happen with 4.20-rc? Because as of 6af588fed391 it > really shouldn't. > > > We kind of avoided this problem prior to sdm845/dpu because the iommu > > was attached to the mdp node in dt, which is a child of the toplevel > > mdss node (which corresponds to the dev passed in dma_map_sg()). But > > with sdm845, now the iommu is attached at the mdss level so we hit the > > iommu_dma_ops in dma_map_sg(). > > > > But auto allocating/attaching a domain before the driver is probed was > > already a blocking problem for enabling per-context pagetables for the > > GPU. This problem is also now solved with this patch. > > s/solved/worked around/ > > If you want a guarantee of actually getting a specific hardware context > allocated for a given domain, there needs to be code in the IOMMU driver > to understand and honour that. Implicitly depending on whatever happens > to fall out of current driver behaviour on current systems is not a real > solution. > > > Fixes: 97890ba9289c dma-mapping: detect and configure IOMMU in > > of_dma_configure > > That's rather misleading, since the crash described above depends on at > least two other major changes which came long after that commit. > > It's not that I don't understand exactly what you want here - just that > this commit message isn't a coherent justification for that ;) > > > Tested-by: Douglas Anderson > > Signed-off-by: Rob Clark > > --- > > This is an alternative/replacement for [1]. What it lacks in elegance > > it makes up for in practicality ;-) > > > > [1] https://patchwork.freedesktop.org/patch/264930/ > > > > drivers/of/device.c | 22 ++ > > 1 file changed, 22 insertions(+) > > > > diff --git a/drivers/of/device.c b/drivers/of/device.c > > index 5957cd4fa262..15ffee00fb22 100644 > > --- a/drivers/of/device.c > > +++ b/drivers/of/device.c > >
Re: [PATCH 4/4] drm/i915: Increase timeout for Encrypt status change
On Tue, Nov 27, 2018 at 07:32:59PM +0530, Ramalingam C wrote:
> At enable/disable of the HDCP encryption, for encryption status change
> we need minimum one frame duration. And we might program this bit any
> point(start/End) in the previous frame.
>
> With 20mSec, observed the timeout for change in encryption status.
> Since this is not time critical operation and we need to hold on
> until the status is changed, fixing the timeout to 50mSec. (Based on
> trial and error method!)
>
> Signed-off-by: Ramalingam C
> ---
> drivers/gpu/drm/i915/intel_hdcp.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
> b/drivers/gpu/drm/i915/intel_hdcp.c
> index bd60d0e7bbfa..156b14d19e09 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -15,6 +15,7 @@
> #include "i915_reg.h"
>
> #define KEY_LOAD_TRIES 5
> +#define TIME_FOR_ENCRYPT_STATUS_CHANGE 50
ENCRYPT_STATUS_CHANGE_TIMEOUT_MS please
with that fixed,
Reviewed-by: Sean Paul
>
> static
> bool intel_hdcp_is_ksv_valid(u8 *ksv)
> @@ -638,7 +639,8 @@ static int intel_hdcp_auth(struct intel_digital_port
> *intel_dig_port,
>
> /* Wait for encryption confirmation */
> if (intel_wait_for_register(dev_priv, PORT_HDCP_STATUS(port),
> - HDCP_STATUS_ENC, HDCP_STATUS_ENC, 20)) {
> + HDCP_STATUS_ENC, HDCP_STATUS_ENC,
> + TIME_FOR_ENCRYPT_STATUS_CHANGE)) {
> DRM_ERROR("Timed out waiting for encryption\n");
> return -ETIMEDOUT;
> }
> @@ -668,7 +670,7 @@ static int _intel_hdcp_disable(struct intel_connector
> *connector)
>
> I915_WRITE(PORT_HDCP_CONF(port), 0);
> if (intel_wait_for_register(dev_priv, PORT_HDCP_STATUS(port), ~0, 0,
> - 20)) {
> + TIME_FOR_ENCRYPT_STATUS_CHANGE)) {
> DRM_ERROR("Failed to disable HDCP, timeout clearing status\n");
> return -ETIMEDOUT;
> }
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 85791] nouveau: errors on boot, can't use discrete gpu
https://bugzilla.kernel.org/show_bug.cgi?id=85791 Aleksandr Mezin (mezin.alexan...@gmail.com) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |CODE_FIX -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/3] drm/connector: Add generic underscan properties
On Thu, Nov 22, 2018 at 12:23:29PM +0100, Boris Brezillon wrote:
> @@ -924,6 +978,29 @@ struct drm_connector {
>*/
> struct drm_property_blob *path_blob_ptr;
>
> + /**
> + * @underscan_mode_property: Optional connector underscan mode. Used by
> + * the driver to scale the output image and compensate an overscan done
> + * on the display side.
> + */
> + struct drm_property *underscan_mode_property;
> +
> + /**
> + * @underscan_hborder_property: Optional connector underscan horizontal
> + * border (expressed in pixels). Used by the driver to adjust the
> + * output image position and compensate an overscan done on the display
> + * side.
> + */
> + struct drm_property *underscan_hborder_property;
> +
> + /**
> + * @underscan_hborder_property: Optional connector underscan vertical
> + * border (expressed in pixels). Used by the driver to adjust the
> + * output image position and compensate an overscan done on the display
> + * side.
> + */
> + struct drm_property *underscan_vborder_property;
I'm wondering why we're adding these new props when we already have the
(slightly more flexible) margin properties for TV out. We could just
reuse those AFAICS.
> +
> #define DRM_CONNECTOR_POLL_HPD (1 << 0)
> #define DRM_CONNECTOR_POLL_CONNECT (1 << 1)
> #define DRM_CONNECTOR_POLL_DISCONNECT (1 << 2)
> @@ -1180,6 +1257,9 @@ int drm_mode_create_dvi_i_properties(struct drm_device
> *dev);
> int drm_mode_create_tv_properties(struct drm_device *dev,
> unsigned int num_modes,
> const char * const modes[]);
> +int drm_connector_attach_underscan_properties(struct drm_connector
> *connector,
> + u32 mode_mask, u64 max_hborder,
> + u64 max_vborder);
> int drm_mode_create_scaling_mode_property(struct drm_device *dev);
> int drm_connector_attach_content_type_property(struct drm_connector *dev);
> int drm_connector_attach_scaling_mode_property(struct drm_connector
> *connector,
> --
> 2.17.1
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH v2] drm/msm/dpu: add display port support in DPU
On Tue, Nov 27, 2018 at 02:28:30PM -0800, Jeykumar Sankaran wrote:
> Add display port support in DPU by creating hooks
> for DP encoder enumeration and encoder mode
> initialization.
>
> This change is based on the SDM845 Display port
> driver changes[1].
>
> changes in v2:
> - rebase on [2] (Sean Paul)
> - remove unwanted error checks and
> switch cases (Jordan Crouse)
>
> [1] https://lwn.net/Articles/768265/
> [2] https://lkml.org/lkml/2018/11/17/87
>
> Signed-off-by: Jeykumar Sankaran
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 8 ++---
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 47
> +
> 2 files changed, 45 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> index d3f4501..1f6b4b1 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> @@ -2015,7 +2015,7 @@ static int dpu_encoder_setup_display(struct
> dpu_encoder_virt *dpu_enc,
> {
> int ret = 0;
> int i = 0;
> - enum dpu_intf_type intf_type;
> + enum dpu_intf_type intf_type = INTF_NONE;
dpu_intf_type seems unnecessary, you could just use the DRM_MODE_ENCODER_* value
directly?
> struct dpu_enc_phys_init_params phys_params;
>
> if (!dpu_enc || !dpu_kms) {
> @@ -2038,9 +2038,9 @@ static int dpu_encoder_setup_display(struct
> dpu_encoder_virt *dpu_enc,
> case DRM_MODE_ENCODER_DSI:
> intf_type = INTF_DSI;
> break;
> - default:
> - DPU_ERROR_ENC(dpu_enc, "unsupported display interface type\n");
> - return -EINVAL;
> + case DRM_MODE_ENCODER_TMDS:
> + intf_type = INTF_DP;
> + break;
> }
>
> WARN_ON(disp_info->num_of_h_tiles < 1);
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> index 985c855..7d931ae 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> @@ -473,6 +473,32 @@ static void _dpu_kms_initialize_dsi(struct drm_device
> *dev,
> }
> }
>
> +static void _dpu_kms_initialize_displayport(struct drm_device *dev,
> + struct msm_drm_private *priv,
> + struct dpu_kms *dpu_kms)
> +{
> + struct drm_encoder *encoder = NULL;
> + int rc;
> +
> + if (!priv->dp)
> + return;
> +
> + encoder = dpu_encoder_init(dev, DRM_MODE_ENCODER_TMDS);
> + if (IS_ERR(encoder)) {
> + DPU_ERROR("encoder init failed for dsi display\n");
> + return;
> + }
> +
> + rc = msm_dp_modeset_init(priv->dp, dev, encoder);
> + if (rc) {
> + DPU_ERROR("modeset_init failed for DP, rc = %d\n", rc);
> + drm_encoder_cleanup(encoder);
> + return;
> + }
> +
> + priv->encoders[priv->num_encoders++] = encoder;
No need to keep track of drm resources at the driver level, the core will do
this for you. So can you please add a patch preceding this one to remove the
priv->encoders/crtc/planes/connectors arrays?
> +}
> +
> /**
> * _dpu_kms_setup_displays - create encoders, bridges and connectors
> * for underlying displays
> @@ -487,6 +513,8 @@ static void _dpu_kms_setup_displays(struct drm_device
> *dev,
Why are these functions voids? Seems like there are plenty of places for them to
fail :)
Let's add a patch to the beginning of this series to properly handle failures in
setup_displays and initialize_dsi
> {
> _dpu_kms_initialize_dsi(dev, priv, dpu_kms);
>
> + _dpu_kms_initialize_displayport(dev, priv, dpu_kms);
> +
> /**
>* Extend this function to initialize other
>* types of displays
> @@ -723,13 +751,20 @@ static void _dpu_kms_set_encoder_mode(struct msm_kms
> *kms,
> info.capabilities = cmd_mode ? MSM_DISPLAY_CAP_CMD_MODE :
> MSM_DISPLAY_CAP_VID_MODE;
>
> - /* TODO: No support for DSI swap */
> - for (i = 0; i < ARRAY_SIZE(priv->dsi); i++) {
> - if (priv->dsi[i]) {
> - info.h_tile_instance[info.num_of_h_tiles] = i;
> - info.num_of_h_tiles++;
> + switch (info.intf_type) {
> + case DRM_MODE_ENCODER_DSI:
> + /* TODO: No support for DSI swap */
> + for (i = 0; i < ARRAY_SIZE(priv->dsi); i++) {
> + if (priv->dsi[i]) {
> + info.h_tile_instance[info.num_of_h_tiles] = i;
> + info.num_of_h_tiles++;
> + }
> }
> - }
> + break;
> + case DRM_MODE_ENCODER_TMDS:
> + info.num_of_h_tiles = 1;
> + break;
> + };
>
> rc = dpu_encoder_setup(encoder->dev, encoder, &info);
> if (rc)
> --
> The Qualcomm Innovatio
Re: [PATCH] fbdev: fsl-diu: remove redundant null check on cmap
On 12/3/18 12:43 AM, Wen Yang wrote: The null check on &info->cmap is redundant since cmap is a struct inside fb_info and can never be null, so the check is always true. we may remove it. Signed-off-by: Wen Yang Acked-by: Timur Tabi ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vc4: Add support for X/Y reflection
On Mon, 3 Dec 2018 15:50:26 +0200 Ville Syrjälä wrote: > On Mon, Dec 03, 2018 at 02:34:12PM +0100, Boris Brezillon wrote: > > Add support for X/Y reflection when the plane is using linear or T-tiled > > formats. X/Y reflection hasn't been tested on SAND formats, so we reject > > them until proper testing/debugging has been done. > > BTW you could also expose 180 degress easily. See > drm_rotation_simplify(). Thanks for the tip. I'll add it in v2. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108917] gamma adjustments cause stuttering with amdgpu.dc=1, especially problematic with RedShift etc.
https://bugs.freedesktop.org/show_bug.cgi?id=108917 --- Comment #4 from Alex Deucher --- DC is atomic. gamma updates may go through a full atomic codepath similar to cursor. They may also need a similar fast path to avoid a full atomic update. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/tegra: sor: Support for audio over HDMI
From: Thierry Reding
This code is very similar to the audio over HDMI support on older chips.
Interoperation with the audio codec is done via a pair of codec scratch
registers and an interrupt that is raised at the SOR when the codec has
written those registers.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/sor.c | 229
drivers/gpu/drm/tegra/sor.h | 68 +++
2 files changed, 297 insertions(+)
diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
index b129da2e5afd..22a54434a757 100644
--- a/drivers/gpu/drm/tegra/sor.c
+++ b/drivers/gpu/drm/tegra/sor.c
@@ -19,6 +19,8 @@
#include
+#include
+
#include
#include
#include
@@ -407,6 +409,7 @@ struct tegra_sor {
const struct tegra_sor_soc *soc;
void __iomem *regs;
unsigned int index;
+ unsigned int irq;
struct reset_control *rst;
struct clk *clk_parent;
@@ -433,6 +436,11 @@ struct tegra_sor {
struct delayed_work scdc;
bool scdc_enabled;
+
+ struct {
+ unsigned int sample_rate;
+ unsigned int channels;
+ } audio;
};
struct tegra_sor_state {
@@ -2139,6 +2147,144 @@ tegra_sor_hdmi_setup_avi_infoframe(struct tegra_sor
*sor,
return 0;
}
+static void tegra_sor_write_eld(struct tegra_sor *sor)
+{
+ size_t length = drm_eld_size(sor->output.connector.eld), i;
+
+ for (i = 0; i < length; i++)
+ tegra_sor_writel(sor, i << 8 | sor->output.connector.eld[i],
+SOR_AUDIO_HDA_ELD_BUFWR);
+
+ /*
+* The HDA codec will always report an ELD buffer size of 96 bytes and
+* the HDA codec driver will check that each byte read from the buffer
+* is valid. Therefore every byte must be written, even if no 96 bytes
+* were parsed from EDID.
+*/
+ for (i = length; i < 96; i++)
+ tegra_sor_writel(sor, i << 8 | 0, SOR_AUDIO_HDA_ELD_BUFWR);
+}
+
+static void tegra_sor_audio_prepare(struct tegra_sor *sor)
+{
+ u32 value;
+
+ tegra_sor_write_eld(sor);
+
+ value = SOR_AUDIO_HDA_PRESENSE_ELDV | SOR_AUDIO_HDA_PRESENSE_PD;
+ tegra_sor_writel(sor, value, SOR_AUDIO_HDA_PRESENSE);
+}
+
+static void tegra_sor_audio_unprepare(struct tegra_sor *sor)
+{
+ tegra_sor_writel(sor, 0, SOR_AUDIO_HDA_PRESENSE);
+}
+
+static int tegra_sor_hdmi_enable_audio_infoframe(struct tegra_sor *sor)
+{
+ u8 buffer[HDMI_INFOFRAME_SIZE(AUDIO)];
+ struct hdmi_audio_infoframe frame;
+ u32 value;
+ int err;
+
+ err = hdmi_audio_infoframe_init(&frame);
+ if (err < 0) {
+ dev_err(sor->dev, "failed to setup audio infoframe: %d\n", err);
+ return err;
+ }
+
+ frame.channels = sor->audio.channels;
+
+ err = hdmi_audio_infoframe_pack(&frame, buffer, sizeof(buffer));
+ if (err < 0) {
+ dev_err(sor->dev, "failed to pack audio infoframe: %d\n", err);
+ return err;
+ }
+
+ tegra_sor_hdmi_write_infopack(sor, buffer, err);
+
+ value = tegra_sor_readl(sor, SOR_HDMI_AUDIO_INFOFRAME_CTRL);
+ value |= INFOFRAME_CTRL_CHECKSUM_ENABLE;
+ value |= INFOFRAME_CTRL_ENABLE;
+ tegra_sor_writel(sor, value, SOR_HDMI_AUDIO_INFOFRAME_CTRL);
+
+ return 0;
+}
+
+static void tegra_sor_hdmi_audio_enable(struct tegra_sor *sor)
+{
+ u32 value;
+
+ value = tegra_sor_readl(sor, SOR_AUDIO_CNTRL);
+
+ /* select HDA audio input */
+ value &= ~SOR_AUDIO_CNTRL_SOURCE_SELECT(SOURCE_SELECT_MASK);
+ value |= SOR_AUDIO_CNTRL_SOURCE_SELECT(SOURCE_SELECT_HDA);
+
+ /* inject null samples */
+ if (sor->audio.channels != 2)
+ value &= ~SOR_AUDIO_CNTRL_INJECT_NULLSMPL;
+ else
+ value |= SOR_AUDIO_CNTRL_INJECT_NULLSMPL;
+
+ value |= SOR_AUDIO_CNTRL_AFIFO_FLUSH;
+
+ tegra_sor_writel(sor, value, SOR_AUDIO_CNTRL);
+
+ /* enable advertising HBR capability */
+ tegra_sor_writel(sor, SOR_AUDIO_SPARE_HBR_ENABLE, SOR_AUDIO_SPARE);
+
+ tegra_sor_writel(sor, 0, SOR_HDMI_ACR_CTRL);
+
+ value = SOR_HDMI_SPARE_ACR_PRIORITY_HIGH |
+ SOR_HDMI_SPARE_CTS_RESET(1) |
+ SOR_HDMI_SPARE_HW_CTS_ENABLE;
+ tegra_sor_writel(sor, value, SOR_HDMI_SPARE);
+
+ /* enable HW CTS */
+ value = SOR_HDMI_ACR_SUBPACK_LOW_SB1(0);
+ tegra_sor_writel(sor, value, SOR_HDMI_ACR_0441_SUBPACK_LOW);
+
+ /* allow packet to be sent */
+ value = SOR_HDMI_ACR_SUBPACK_HIGH_ENABLE;
+ tegra_sor_writel(sor, value, SOR_HDMI_ACR_0441_SUBPACK_HIGH);
+
+ /* reset N counter and enable lookup */
+ value = SOR_HDMI_AUDIO_N_RESET | SOR_HDMI_AUDIO_N_LOOKUP;
+ tegra_sor_writel(sor, value, SOR_HDMI_AUDIO_N);
+
+ value = (24000 * 4096) / (128 * sor->audio.sample_rate / 1000);
+ tegra_sor_writel(sor, value, SOR_AUDIO_AVAL_0320)
Re: [PATCH v3 1/3] drm/connector: Add generic underscan properties
On Mon, 3 Dec 2018 16:40:11 +0200
Ville Syrjälä wrote:
> On Thu, Nov 22, 2018 at 12:23:29PM +0100, Boris Brezillon wrote:
> > @@ -924,6 +978,29 @@ struct drm_connector {
> > */
> > struct drm_property_blob *path_blob_ptr;
> >
> > + /**
> > +* @underscan_mode_property: Optional connector underscan mode. Used by
> > +* the driver to scale the output image and compensate an overscan done
> > +* on the display side.
> > +*/
> > + struct drm_property *underscan_mode_property;
> > +
> > + /**
> > +* @underscan_hborder_property: Optional connector underscan horizontal
> > +* border (expressed in pixels). Used by the driver to adjust the
> > +* output image position and compensate an overscan done on the display
> > +* side.
> > +*/
> > + struct drm_property *underscan_hborder_property;
> > +
> > + /**
> > +* @underscan_hborder_property: Optional connector underscan vertical
> > +* border (expressed in pixels). Used by the driver to adjust the
> > +* output image position and compensate an overscan done on the display
> > +* side.
> > +*/
> > + struct drm_property *underscan_vborder_property;
>
> I'm wondering why we're adding these new props when we already have the
> (slightly more flexible) margin properties for TV out. We could just
> reuse those AFAICS.
I'm not against the idea, but I can't use
drm_mode_create_tv_properties() directly, as most props created by this
function are not applicable to an HDMI displays. Should I move the
margins props out of the tv_connector_state and provide new helpers to
create those props?
>
> > +
> > #define DRM_CONNECTOR_POLL_HPD (1 << 0)
> > #define DRM_CONNECTOR_POLL_CONNECT (1 << 1)
> > #define DRM_CONNECTOR_POLL_DISCONNECT (1 << 2)
> > @@ -1180,6 +1257,9 @@ int drm_mode_create_dvi_i_properties(struct
> > drm_device *dev);
> > int drm_mode_create_tv_properties(struct drm_device *dev,
> > unsigned int num_modes,
> > const char * const modes[]);
> > +int drm_connector_attach_underscan_properties(struct drm_connector
> > *connector,
> > + u32 mode_mask, u64 max_hborder,
> > + u64 max_vborder);
> > int drm_mode_create_scaling_mode_property(struct drm_device *dev);
> > int drm_connector_attach_content_type_property(struct drm_connector *dev);
> > int drm_connector_attach_scaling_mode_property(struct drm_connector
> > *connector,
> > --
> > 2.17.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/edid: Quirk Sensics, 3 Glasses HMD as non-desktop.
On Sat, 2018-10-20 at 20:42 +0100, Ryan Pavlik wrote:
> Two of the EDID vendor/product pairs are used across a variety of
> Sensics products, as well as the OSVR HDK and HDK 2.
>
> The third is for the "3 Glasses" brand "D3" HMD.
>
> Signed-off-by: Ryan Pavlik
> ---
> drivers/gpu/drm/drm_edid.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 3c9fc9964..68b7bc007 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -187,6 +187,15 @@ static const struct edid_quirk {
>
> /* Sony PlayStation VR Headset */
> { "SNY", 0x0704, EDID_QUIRK_NON_DESKTOP },
> +
> + /* Sensics VR Headsets */
> + { "SEN", 0x1019, EDID_QUIRK_NON_DESKTOP },
> +
> + /* Sensics, OSVR HDK and HDK2 VR Headsets */
> + { "SVR", 0x1019, EDID_QUIRK_NON_DESKTOP },
This looks good to me. These are indeed HMDs, and I can confirm
"SVR"/0x1019 is correct for the HDK2.
> + /* 3Glasses D3 VR Headset */
> + { "TSB", 0x, EDID_QUIRK_NON_DESKTOP },
This looks a lot like the vendor has not bothered to set a custom
vendor/product id in the Toshiba HDMI-to-DSI bridge chip. I would
argue that it is safer to mark such displays as non-desktop, though.
> };
>
> /*
Reviewed-by: Philipp Zabel
Can we take this into drm-misc?
regards
Philipp
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/3] drm/connector: Add generic underscan properties
Boris Brezillon writes:
> On Mon, 3 Dec 2018 16:40:11 +0200
> Ville Syrjälä wrote:
>
>> On Thu, Nov 22, 2018 at 12:23:29PM +0100, Boris Brezillon wrote:
>> > @@ -924,6 +978,29 @@ struct drm_connector {
>> > */
>> >struct drm_property_blob *path_blob_ptr;
>> >
>> > + /**
>> > + * @underscan_mode_property: Optional connector underscan mode. Used by
>> > + * the driver to scale the output image and compensate an overscan done
>> > + * on the display side.
>> > + */
>> > + struct drm_property *underscan_mode_property;
>> > +
>> > + /**
>> > + * @underscan_hborder_property: Optional connector underscan horizontal
>> > + * border (expressed in pixels). Used by the driver to adjust the
>> > + * output image position and compensate an overscan done on the display
>> > + * side.
>> > + */
>> > + struct drm_property *underscan_hborder_property;
>> > +
>> > + /**
>> > + * @underscan_hborder_property: Optional connector underscan vertical
>> > + * border (expressed in pixels). Used by the driver to adjust the
>> > + * output image position and compensate an overscan done on the display
>> > + * side.
>> > + */
>> > + struct drm_property *underscan_vborder_property;
>>
>> I'm wondering why we're adding these new props when we already have the
>> (slightly more flexible) margin properties for TV out. We could just
>> reuse those AFAICS.
>
> I'm not against the idea, but I can't use
> drm_mode_create_tv_properties() directly, as most props created by this
> function are not applicable to an HDMI displays. Should I move the
> margins props out of the tv_connector_state and provide new helpers to
> create those props?
TV margin props look good to me, FWIW.
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] dma-buf: add dma_fence_get_stub
On Mon, Dec 3, 2018 at 8:40 AM Christian König
wrote:
>
> Am 03.12.18 um 14:33 schrieb Chunming Zhou:
> > The series is Reviewed-by: Chunming Zhou
> >
> > for patch#2, please remove my Signed-off-by, it's new when using stub
> > from dma-fence.
>
> Yeah, ok. There is indeed nothing left from your original code.
>
> Alex, Daniel, Chris any objections that I push the first two patches in
> this series to drm-misc-next?
No objections from me. Does Intel want to run it through their CI?
Alex
>
> Shouldn't be any functional change,
> Christian.
>
> >
> >
> > -David
> >
> >
> > 在 2018/12/3 21:07, Christian König 写道:
> >> Extract of useful code from the timeline work. This provides a function
> >> to return a stub or dummy fence which is always signaled.
> >>
> >> Signed-off-by: Christian König
> >> ---
> >>drivers/dma-buf/dma-fence.c | 36 +++-
> >>include/linux/dma-fence.h | 1 +
> >>2 files changed, 36 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> >> index 1551ca7df394..136ec04d683f 100644
> >> --- a/drivers/dma-buf/dma-fence.c
> >> +++ b/drivers/dma-buf/dma-fence.c
> >> @@ -30,13 +30,16 @@
> >>EXPORT_TRACEPOINT_SYMBOL(dma_fence_emit);
> >>EXPORT_TRACEPOINT_SYMBOL(dma_fence_enable_signal);
> >>
> >> +static DEFINE_SPINLOCK(dma_fence_stub_lock);
> >> +static struct dma_fence dma_fence_stub;
> >> +
> >>/*
> >> * fence context counter: each execution context should have its own
> >> * fence context, this allows checking if fences belong to the same
> >> * context or not. One device can have multiple separate contexts,
> >> * and they're used if some engine can run independently of another.
> >> */
> >> -static atomic64_t dma_fence_context_counter = ATOMIC64_INIT(0);
> >> +static atomic64_t dma_fence_context_counter = ATOMIC64_INIT(1);
> >>
> >>/**
> >> * DOC: DMA fences overview
> >> @@ -68,6 +71,37 @@ static atomic64_t dma_fence_context_counter =
> >> ATOMIC64_INIT(0);
> >> * &dma_buf.resv pointer.
> >> */
> >>
> >> +static const char *dma_fence_stub_get_name(struct dma_fence *fence)
> >> +{
> >> +return "stub";
> >> +}
> >> +
> >> +static const struct dma_fence_ops dma_fence_stub_ops = {
> >> +.get_driver_name = dma_fence_stub_get_name,
> >> +.get_timeline_name = dma_fence_stub_get_name,
> >> +};
> >> +
> >> +/**
> >> + * dma_fence_get_stub - return a signaled fence
> >> + *
> >> + * Return a stub fence which is already signaled.
> >> + */
> >> +struct dma_fence *dma_fence_get_stub(void)
> >> +{
> >> +spin_lock(&dma_fence_stub_lock);
> >> +if (!dma_fence_stub.ops) {
> >> +dma_fence_init(&dma_fence_stub,
> >> + &dma_fence_stub_ops,
> >> + &dma_fence_stub_lock,
> >> + 0, 0);
> >> +dma_fence_signal_locked(&dma_fence_stub);
> >> +}
> >> +spin_unlock(&dma_fence_stub_lock);
> >> +
> >> +return dma_fence_get(&dma_fence_stub);
> >> +}
> >> +EXPORT_SYMBOL(dma_fence_get_stub);
> >> +
> >>/**
> >> * dma_fence_context_alloc - allocate an array of fence contexts
> >> * @num: amount of contexts to allocate
> >> diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
> >> index 02dba8cd033d..999e4b104410 100644
> >> --- a/include/linux/dma-fence.h
> >> +++ b/include/linux/dma-fence.h
> >> @@ -541,6 +541,7 @@ static inline signed long dma_fence_wait(struct
> >> dma_fence *fence, bool intr)
> >> return ret < 0 ? ret : 0;
> >>}
> >>
> >> +struct dma_fence *dma_fence_get_stub(void);
> >>u64 dma_fence_context_alloc(unsigned num);
> >>
> >>#define DMA_FENCE_TRACE(f, fmt, args...) \
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/vc4: Add a debugfs entry to disable/enable the load tracker
Boris Brezillon writes: > On Fri, 30 Nov 2018 12:30:52 -0800 > Eric Anholt wrote: > >> Paul Kocialkowski writes: >> >> > In order to test whether the load tracker is working as expected, we >> > need the ability to compare the commit result with the underrun >> > indication. With the load tracker always enabled, commits that are >> > expected to trigger an underrun are always rejected, so userspace >> > cannot get the actual underrun indication from the hardware. >> > >> > Add a debugfs entry to disable/enable the load tracker, so that a DRM >> > commit expected to trigger an underrun can go through with the load >> > tracker disabled. The underrun indication is then available to >> > userspace and can be checked against the commit result with the load >> > tracker enabled. >> > >> > Signed-off-by: Paul Kocialkowski >> >> Given that the load tracker is going to be conservative and say things >> will underrun even when they might not in practice, will this actually >> be useful for automated testing? Or is the intent to make it easier to >> tune the load tracker by disabling it so that you can experiment freely? > > Yes, that's one goal, though I'm not sure IGT is supposed to contain > such debugging tools. But the main benefit is being able to track > regressions in the load tracking algo that makes it more (too?) > conservative. I think people won't like this sort of regressions. The > idea would be to settle on an acceptable load tracking algo (maybe > after refining the proposed one), record the results (both good and too > conservative predictions) and use that as a reference for the IGT > test. Yeah, I think I'm sold on it at this point -- having a tool that isn't an automated regression test, but an automated thing that can help a developer see how accurate the estimate is, would be useful and is worth a bit of kernel code to support. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vc4: Add support for X/Y reflection
Boris Brezillon writes: > Add support for X/Y reflection when the plane is using linear or T-tiled > formats. X/Y reflection hasn't been tested on SAND formats, so we reject > them until proper testing/debugging has been done. Reviewed-by: Eric Anholt signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/tegra: sor: Support for audio over HDMI
On Mon, 03 Dec 2018, Thierry Reding wrote:
> From: Thierry Reding
>
> This code is very similar to the audio over HDMI support on older chips.
> Interoperation with the audio codec is done via a pair of codec scratch
> registers and an interrupt that is raised at the SOR when the codec has
> written those registers.
>
> Signed-off-by: Thierry Reding
> ---
> drivers/gpu/drm/tegra/sor.c | 229
> drivers/gpu/drm/tegra/sor.h | 68 +++
> 2 files changed, 297 insertions(+)
>
> diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
> index b129da2e5afd..22a54434a757 100644
> --- a/drivers/gpu/drm/tegra/sor.c
> +++ b/drivers/gpu/drm/tegra/sor.c
> @@ -19,6 +19,8 @@
>
> #include
>
> +#include
> +
> #include
> #include
> #include
> @@ -407,6 +409,7 @@ struct tegra_sor {
> const struct tegra_sor_soc *soc;
> void __iomem *regs;
> unsigned int index;
> + unsigned int irq;
>
> struct reset_control *rst;
> struct clk *clk_parent;
> @@ -433,6 +436,11 @@ struct tegra_sor {
>
> struct delayed_work scdc;
> bool scdc_enabled;
> +
> + struct {
> + unsigned int sample_rate;
> + unsigned int channels;
> + } audio;
> };
>
> struct tegra_sor_state {
> @@ -2139,6 +2147,144 @@ tegra_sor_hdmi_setup_avi_infoframe(struct tegra_sor
> *sor,
> return 0;
> }
>
> +static void tegra_sor_write_eld(struct tegra_sor *sor)
> +{
> + size_t length = drm_eld_size(sor->output.connector.eld), i;
This caught my eye, can't be right?
BR,
Jani.
> +
> + for (i = 0; i < length; i++)
> + tegra_sor_writel(sor, i << 8 | sor->output.connector.eld[i],
> + SOR_AUDIO_HDA_ELD_BUFWR);
> +
> + /*
> + * The HDA codec will always report an ELD buffer size of 96 bytes and
> + * the HDA codec driver will check that each byte read from the buffer
> + * is valid. Therefore every byte must be written, even if no 96 bytes
> + * were parsed from EDID.
> + */
> + for (i = length; i < 96; i++)
> + tegra_sor_writel(sor, i << 8 | 0, SOR_AUDIO_HDA_ELD_BUFWR);
> +}
> +
> +static void tegra_sor_audio_prepare(struct tegra_sor *sor)
> +{
> + u32 value;
> +
> + tegra_sor_write_eld(sor);
> +
> + value = SOR_AUDIO_HDA_PRESENSE_ELDV | SOR_AUDIO_HDA_PRESENSE_PD;
> + tegra_sor_writel(sor, value, SOR_AUDIO_HDA_PRESENSE);
> +}
> +
> +static void tegra_sor_audio_unprepare(struct tegra_sor *sor)
> +{
> + tegra_sor_writel(sor, 0, SOR_AUDIO_HDA_PRESENSE);
> +}
> +
> +static int tegra_sor_hdmi_enable_audio_infoframe(struct tegra_sor *sor)
> +{
> + u8 buffer[HDMI_INFOFRAME_SIZE(AUDIO)];
> + struct hdmi_audio_infoframe frame;
> + u32 value;
> + int err;
> +
> + err = hdmi_audio_infoframe_init(&frame);
> + if (err < 0) {
> + dev_err(sor->dev, "failed to setup audio infoframe: %d\n", err);
> + return err;
> + }
> +
> + frame.channels = sor->audio.channels;
> +
> + err = hdmi_audio_infoframe_pack(&frame, buffer, sizeof(buffer));
> + if (err < 0) {
> + dev_err(sor->dev, "failed to pack audio infoframe: %d\n", err);
> + return err;
> + }
> +
> + tegra_sor_hdmi_write_infopack(sor, buffer, err);
> +
> + value = tegra_sor_readl(sor, SOR_HDMI_AUDIO_INFOFRAME_CTRL);
> + value |= INFOFRAME_CTRL_CHECKSUM_ENABLE;
> + value |= INFOFRAME_CTRL_ENABLE;
> + tegra_sor_writel(sor, value, SOR_HDMI_AUDIO_INFOFRAME_CTRL);
> +
> + return 0;
> +}
> +
> +static void tegra_sor_hdmi_audio_enable(struct tegra_sor *sor)
> +{
> + u32 value;
> +
> + value = tegra_sor_readl(sor, SOR_AUDIO_CNTRL);
> +
> + /* select HDA audio input */
> + value &= ~SOR_AUDIO_CNTRL_SOURCE_SELECT(SOURCE_SELECT_MASK);
> + value |= SOR_AUDIO_CNTRL_SOURCE_SELECT(SOURCE_SELECT_HDA);
> +
> + /* inject null samples */
> + if (sor->audio.channels != 2)
> + value &= ~SOR_AUDIO_CNTRL_INJECT_NULLSMPL;
> + else
> + value |= SOR_AUDIO_CNTRL_INJECT_NULLSMPL;
> +
> + value |= SOR_AUDIO_CNTRL_AFIFO_FLUSH;
> +
> + tegra_sor_writel(sor, value, SOR_AUDIO_CNTRL);
> +
> + /* enable advertising HBR capability */
> + tegra_sor_writel(sor, SOR_AUDIO_SPARE_HBR_ENABLE, SOR_AUDIO_SPARE);
> +
> + tegra_sor_writel(sor, 0, SOR_HDMI_ACR_CTRL);
> +
> + value = SOR_HDMI_SPARE_ACR_PRIORITY_HIGH |
> + SOR_HDMI_SPARE_CTS_RESET(1) |
> + SOR_HDMI_SPARE_HW_CTS_ENABLE;
> + tegra_sor_writel(sor, value, SOR_HDMI_SPARE);
> +
> + /* enable HW CTS */
> + value = SOR_HDMI_ACR_SUBPACK_LOW_SB1(0);
> + tegra_sor_writel(sor, value, SOR_HDMI_ACR_0441_SUBPACK_LOW);
> +
> + /* allow packet to be sent */
> + value = SOR_HDMI_ACR_SUBPACK_HIGH_ENABLE;
> + tegra_sor_writel(sor, value, SOR_HDMI_ACR_0441_SUBPACK_HIGH);
> +
> + /* reset N counter and enable lookup */
> +
Re: [PATCH 1/3] dma-buf: add dma_fence_get_stub
Quoting Christian König (2018-12-03 13:07:57) > Extract of useful code from the timeline work. This provides a function > to return a stub or dummy fence which is always signaled. > > Signed-off-by: Christian König Reviewed-by: Chris Wilson -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/syncobj: use dma_fence_get_stub
Quoting Christian König (2018-12-03 13:07:58) > Extract of useful code from the timeline work. Let's use just a single > stub fence instance instead of allocating a new one all the time. > > Signed-off-by: Chunming Zhou > Signed-off-by: Christian König Reviewed-by: Chris Wilson -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] dma-buf: add dma_fence_get_stub
Quoting Alex Deucher (2018-12-03 15:53:21) > On Mon, Dec 3, 2018 at 8:40 AM Christian König > wrote: > > > > Am 03.12.18 um 14:33 schrieb Chunming Zhou: > > > The series is Reviewed-by: Chunming Zhou > > > > > > for patch#2, please remove my Signed-off-by, it's new when using stub > > > from dma-fence. > > > > Yeah, ok. There is indeed nothing left from your original code. > > > > Alex, Daniel, Chris any objections that I push the first two patches in > > this series to drm-misc-next? > > No objections from me. Does Intel want to run it through their CI? Gut feeling says we have no test coverage for SYNCOBJ_CREATE_SIGNALED. -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 1/4] drm/panel: simple: Add AUO G101EVN010 panel support
On Thu, Oct 25, 2018 at 05:09:30PM +0200, Alex Gonzalez wrote: > The change adds support for the AU Optronics G101EVN010 10.1" TFT LCD > panel. > > Signed-off-by: Alex Gonzalez > --- > .../bindings/display/panel/auo,g101evn010 | 12 ++ > drivers/gpu/drm/panel/panel-simple.c | 27 > ++ > 2 files changed, 39 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/panel/auo,g101evn010 Two things to keep in mind for next time: please split up DT bindings and driver changes into two separate patches (checkpatch.pl warns about this) and keep entries in panel-simple sorted alphabetically. I fixed the sorting myself and also added a .txt suffix to the DT binding documentation for consistency with other files in that directory. Applied to drm-misc-next, thanks. Thierry signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] dma-buf: add dma_fence_get_stub
Christian König writes: > Extract of useful code from the timeline work. This provides a function > to return a stub or dummy fence which is always signaled. > > Signed-off-by: Christian König > --- > drivers/dma-buf/dma-fence.c | 36 +++- > include/linux/dma-fence.h | 1 + > 2 files changed, 36 insertions(+), 1 deletion(-) > > diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c > index 1551ca7df394..136ec04d683f 100644 > --- a/drivers/dma-buf/dma-fence.c > +++ b/drivers/dma-buf/dma-fence.c > /* > * fence context counter: each execution context should have its own > * fence context, this allows checking if fences belong to the same > * context or not. One device can have multiple separate contexts, > * and they're used if some engine can run independently of another. > */ > -static atomic64_t dma_fence_context_counter = ATOMIC64_INIT(0); > +static atomic64_t dma_fence_context_counter = ATOMIC64_INIT(1); What's this change for? I don't see a context allocation in patch #2 where the stub fence is being moved from, so this seems out of place. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] dma-buf: add dma_fence_get_stub
Am 03.12.18 um 17:08 schrieb Eric Anholt: Christian König writes: Extract of useful code from the timeline work. This provides a function to return a stub or dummy fence which is always signaled. Signed-off-by: Christian König --- drivers/dma-buf/dma-fence.c | 36 +++- include/linux/dma-fence.h | 1 + 2 files changed, 36 insertions(+), 1 deletion(-) diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c index 1551ca7df394..136ec04d683f 100644 --- a/drivers/dma-buf/dma-fence.c +++ b/drivers/dma-buf/dma-fence.c /* * fence context counter: each execution context should have its own * fence context, this allows checking if fences belong to the same * context or not. One device can have multiple separate contexts, * and they're used if some engine can run independently of another. */ -static atomic64_t dma_fence_context_counter = ATOMIC64_INIT(0); +static atomic64_t dma_fence_context_counter = ATOMIC64_INIT(1); What's this change for? I don't see a context allocation in patch #2 where the stub fence is being moved from, so this seems out of place. The stub fence is using context 0 and seqno 0, but since it is always signaled this actually shouldn't matter. So this is just to be on the extra clean side I made sure that nobody else is using context 0. Alternatively we could also just allocate one when we initialize it for the first time. Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] dt-bindings: panel: Add missing .txt suffix
From: Thierry Reding
All other files in that directory have a .txt suffix, so add one for
consistency.
Signed-off-by: Thierry Reding
---
I meant to make this change while applying but was too quick on the
trigger. Sorry for the extra noise.
Thierry
.../bindings/display/panel/{auo,g101evn010 => auo,g101evn010.txt} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename Documentation/devicetree/bindings/display/panel/{auo,g101evn010 =>
auo,g101evn010.txt} (100%)
diff --git a/Documentation/devicetree/bindings/display/panel/auo,g101evn010
b/Documentation/devicetree/bindings/display/panel/auo,g101evn010.txt
similarity index 100%
rename from Documentation/devicetree/bindings/display/panel/auo,g101evn010
rename to Documentation/devicetree/bindings/display/panel/auo,g101evn010.txt
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] dma-buf: add dma_fence_get_stub
Quoting Eric Anholt (2018-12-03 16:08:40) > Christian König writes: > > > Extract of useful code from the timeline work. This provides a function > > to return a stub or dummy fence which is always signaled. > > > > Signed-off-by: Christian König > > --- > > drivers/dma-buf/dma-fence.c | 36 +++- > > include/linux/dma-fence.h | 1 + > > 2 files changed, 36 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c > > index 1551ca7df394..136ec04d683f 100644 > > --- a/drivers/dma-buf/dma-fence.c > > +++ b/drivers/dma-buf/dma-fence.c > > > /* > > * fence context counter: each execution context should have its own > > * fence context, this allows checking if fences belong to the same > > * context or not. One device can have multiple separate contexts, > > * and they're used if some engine can run independently of another. > > */ > > -static atomic64_t dma_fence_context_counter = ATOMIC64_INIT(0); > > +static atomic64_t dma_fence_context_counter = ATOMIC64_INIT(1); > > What's this change for? I don't see a context allocation in patch #2 > where the stub fence is being moved from, so this seems out of place. I looked as it as being recognition that the stub-fence already exists on context 0, and so we should reserve that context for private use. -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm: add non-desktop quirks to Sensics and OSVR headsets.
Add two EDID vendor/product pairs used across a variety of
Sensics products, as well as the OSVR HDK and HDK 2.
Signed-off-by: Ryan Pavlik
---
Replaces the earlier patch:
drm/edid: Quirk Sensics, 3 Glasses HMD as non-desktop.
Changed:
Drops the 3 Glasses HMD, because it is using a "default" ID
shared between a number of products using a Toshiba video bridge.
drivers/gpu/drm/drm_edid.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 3c9fc99648b7..a1a785b1b8f2 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -187,6 +187,12 @@ static const struct edid_quirk {
/* Sony PlayStation VR Headset */
{ "SNY", 0x0704, EDID_QUIRK_NON_DESKTOP },
+
+ /* Sensics VR Headsets */
+ { "SEN", 0x1019, EDID_QUIRK_NON_DESKTOP },
+
+ /* OSVR HDK and HDK2 VR Headsets */
+ { "SVR", 0x1019, EDID_QUIRK_NON_DESKTOP },
};
/*
--
2.19.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] dma-buf: add dma_fence_get_stub
Christian König writes: > Am 03.12.18 um 17:08 schrieb Eric Anholt: >> Christian König writes: >> >>> Extract of useful code from the timeline work. This provides a function >>> to return a stub or dummy fence which is always signaled. >>> >>> Signed-off-by: Christian König >>> --- >>> drivers/dma-buf/dma-fence.c | 36 +++- >>> include/linux/dma-fence.h | 1 + >>> 2 files changed, 36 insertions(+), 1 deletion(-) >>> >>> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c >>> index 1551ca7df394..136ec04d683f 100644 >>> --- a/drivers/dma-buf/dma-fence.c >>> +++ b/drivers/dma-buf/dma-fence.c >>> /* >>>* fence context counter: each execution context should have its own >>>* fence context, this allows checking if fences belong to the same >>>* context or not. One device can have multiple separate contexts, >>>* and they're used if some engine can run independently of another. >>>*/ >>> -static atomic64_t dma_fence_context_counter = ATOMIC64_INIT(0); >>> +static atomic64_t dma_fence_context_counter = ATOMIC64_INIT(1); >> What's this change for? I don't see a context allocation in patch #2 >> where the stub fence is being moved from, so this seems out of place. > > The stub fence is using context 0 and seqno 0, but since it is always > signaled this actually shouldn't matter. > > So this is just to be on the extra clean side I made sure that nobody > else is using context 0. > > Alternatively we could also just allocate one when we initialize it for > the first time. I like the allocate at init idea. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: add non-desktop quirks to Sensics and OSVR headsets.
On Mon, 2018-12-03 at 10:46 -0600, Ryan Pavlik wrote:
> Add two EDID vendor/product pairs used across a variety of
> Sensics products, as well as the OSVR HDK and HDK 2.
>
> Signed-off-by: Ryan Pavlik
Reviewed-by: Philipp Zabel
> ---
>
> Replaces the earlier patch:
> drm/edid: Quirk Sensics, 3 Glasses HMD as non-desktop.
>
> Changed:
> Drops the 3 Glasses HMD, because it is using a "default" ID
> shared between a number of products using a Toshiba video bridge.
>
> drivers/gpu/drm/drm_edid.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 3c9fc99648b7..a1a785b1b8f2 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -187,6 +187,12 @@ static const struct edid_quirk {
>
> /* Sony PlayStation VR Headset */
> { "SNY", 0x0704, EDID_QUIRK_NON_DESKTOP },
> +
> + /* Sensics VR Headsets */
> + { "SEN", 0x1019, EDID_QUIRK_NON_DESKTOP },
> +
> + /* OSVR HDK and HDK2 VR Headsets */
> + { "SVR", 0x1019, EDID_QUIRK_NON_DESKTOP },
> };
>
> /*
regards
Philipp
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] dma-buf: add dma_fence_get_stub
Quoting Christian König (2018-12-03 16:12:14) > Am 03.12.18 um 17:08 schrieb Eric Anholt: > > Christian König writes: > > > >> Extract of useful code from the timeline work. This provides a function > >> to return a stub or dummy fence which is always signaled. > >> > >> Signed-off-by: Christian König > >> --- > >> drivers/dma-buf/dma-fence.c | 36 +++- > >> include/linux/dma-fence.h | 1 + > >> 2 files changed, 36 insertions(+), 1 deletion(-) > >> > >> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c > >> index 1551ca7df394..136ec04d683f 100644 > >> --- a/drivers/dma-buf/dma-fence.c > >> +++ b/drivers/dma-buf/dma-fence.c > >> /* > >>* fence context counter: each execution context should have its own > >>* fence context, this allows checking if fences belong to the same > >>* context or not. One device can have multiple separate contexts, > >>* and they're used if some engine can run independently of another. > >>*/ > >> -static atomic64_t dma_fence_context_counter = ATOMIC64_INIT(0); > >> +static atomic64_t dma_fence_context_counter = ATOMIC64_INIT(1); > > What's this change for? I don't see a context allocation in patch #2 > > where the stub fence is being moved from, so this seems out of place. > > The stub fence is using context 0 and seqno 0, but since it is always > signaled this actually shouldn't matter. > > So this is just to be on the extra clean side I made sure that nobody > else is using context 0. I would like to be able to reserve 0 for NO_CONTEXT! The stub being but one example. -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108919] Parkitect (Unity Game) dispalys artifacts and black screens with Vega hardware
https://bugs.freedesktop.org/show_bug.cgi?id=108919 --- Comment #2 from Andreas Backx --- I am the creator of the reddit post mentioned in the opening comment of the issue. The 3 images (1 on the reddit post, and the 2 attachments posted) show exactly what I get when I start the game, depending on what settings are used. I cannot get it to any playable state though. I'm running Arch Linux 4.19.4, mesa 18.2.5-1 (along with the same lib32 version), and running on i3 (Xorg) with xf86-video-amdgpu 18.1.0-1. Here are also some logs from when I started the game: https://paste.ubuntu.com/p/fRt54ftVD4/ -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] dma-buf: add dma_fence_get_stub
Am 03.12.18 um 18:06 schrieb Chris Wilson: Quoting Christian König (2018-12-03 16:12:14) Am 03.12.18 um 17:08 schrieb Eric Anholt: Christian König writes: Extract of useful code from the timeline work. This provides a function to return a stub or dummy fence which is always signaled. Signed-off-by: Christian König --- drivers/dma-buf/dma-fence.c | 36 +++- include/linux/dma-fence.h | 1 + 2 files changed, 36 insertions(+), 1 deletion(-) diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c index 1551ca7df394..136ec04d683f 100644 --- a/drivers/dma-buf/dma-fence.c +++ b/drivers/dma-buf/dma-fence.c /* * fence context counter: each execution context should have its own * fence context, this allows checking if fences belong to the same * context or not. One device can have multiple separate contexts, * and they're used if some engine can run independently of another. */ -static atomic64_t dma_fence_context_counter = ATOMIC64_INIT(0); +static atomic64_t dma_fence_context_counter = ATOMIC64_INIT(1); What's this change for? I don't see a context allocation in patch #2 where the stub fence is being moved from, so this seems out of place. The stub fence is using context 0 and seqno 0, but since it is always signaled this actually shouldn't matter. So this is just to be on the extra clean side I made sure that nobody else is using context 0. I would like to be able to reserve 0 for NO_CONTEXT! The stub being but one example. I'm slightly leaning into this direction as well and additional to that I've already pushed the patches to drm-misc-next. The only thing we should avoid is to over use 0 as NO_context, e.g. with complicated sequence numbers or similar. Christian. -Chris ___ amd-gfx mailing list amd-...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH RFC 2/5] cgroup: Add mechanism to register vendor specific DRM devices
On Mon, Dec 03, 2018 at 06:46:01AM +, Ho, Kenny wrote: > Hey Matt, > > On Fri, Nov 30, 2018 at 5:22 PM Matt Roper wrote: > > I think Joonas is describing something closer in > > design to the cgroup-v2 "cpu" controller, which partitions the general > > time/usage allocated to via cgroup; afaiu, "cpu" doesn't really care > > which specific core the tasks run on, just the relative weights that > > determine how much time they get to run on any of the cores. > > Depending on the level of optimization one wants to do, I think people > care about which cpu core a task runs on. Modern processors are no > longer a monolithic 'thing'. At least for AMD, there are multiple > cpus on a core complex (CCX), multiple CCX on a die, and multiple dies > on a processor. A task running on cpu 0 and cpu 1 on die 0 will > behave very differently from a task running on core 0s on die 0 and > die 1 on the same socket. > (https://en.wikichip.org/wiki/amd/microarchitectures/zen#Die-die_memory_latencies) > > It's not just an AMD thing either. Here is an open issue on Intel's > architecture: > https://github.com/kubernetes/kubernetes/issues/67355 > > and a proposed solution using cpu affinity > https://github.com/kubernetes/community/blob/630acc487c80e4981a232cdd8400eb8207119788/keps/sig-node/0030-qos-class-cpu-affinity.md#proposal > (by one of your colleagues.) Right, I didn't mean to imply that the use case wasn't valid, I was just referring to how I believe the cgroup-v2 'cpu' controller (i.e., cpu_cgrp_subsys) currently behaves, as a contrast to the behavior of the cgroup-v1 'cpuset' controller. I can definitely understand your motivation for wanting something along the lines of a "gpuset" controller, but as far as I know, that just isn't something that's possible to implement on a lot of GPU's. > > The time-based sharing below is also something we are thinking about, > but it's personally not as exciting as the resource-based sharing for > me because the time-share use case has already been addressed by our > SRIOV/virtualization products. We can potentially have different > level of time sharing using cgroup though (in addition to SRIOV), > potentially trading efficiency against isolation. That said, I think > the time-based approach maybe orthogonal to the resource-based > approach (orthogonal in the sense that both are needed depending on > the usage.) Makes sense. Matt > > Regards, > Kenny > > > > It sounds like with your hardware, your kernel driver is able to specify > > exactly which subset of GPU EU's a specific GPU context winds up running > > on. However I think there are a lot of platforms that don't allow that > > kind of low-level control. E.g., I don't think we can do that on Intel > > hardware; we have a handful of high-level GPU engines that we can submit > > different types of batchbuffers to (render, blitter, media, etc.). What > > we can do is use GPU preemption to limit how much time specific GPU > > contexts get to run on the render engine before the engine is reclaimed > > for use by a different context. > > > > Using a %gputime approach like Joonas is suggesting could be handled in > > a driver by reserving specific subsets of EU's on hardware like yours > > that's capable of doing that, whereas it could be mostly handled on > > other types of hardware via GPU engine preemption. > > > > I think either approach "gpu_euset" or "%gputime" should map well to a > > cgroup controller implementation. Granted, neither one solves the > > specific use case I was working on earlier this year where we need > > unfair (starvation-okay) scheduling that will run contexts strictly > > according to priority (i.e., lower priority contexts will never run at > > all unless all higher priority contexts have completed all of their > > submitted work), but that's a pretty specialized use case that we'll > > probably need to handle in a different manner anyway. > > > > > > Matt > > > > > > > Regards, > > > Kennny > > > > > > > > > > > > That combined with the "GPU memory usable" property should be a good > > > > > > starting point to start subdividing the GPU resources for multiple > > > > > > users. > > > > > > > > > > > > Regards, Joonas > > > > > > > > > > > > > > > > > > > > Your feedback is highly appreciated. > > > > > > > > > > > > > > Best Regards, > > > > > > > Harish > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: amd-gfx on behalf > > > > > > > of Tejun Heo > > > > > > > Sent: Tuesday, November 20, 2018 5:30 PM > > > > > > > To: Ho, Kenny > > > > > > > Cc: cgro...@vger.kernel.org; intel-...@lists.freedesktop.org; > > > > > > > y2ke...@gmail.com; amd-...@lists.freedesktop.org; > > > > > > > dri-devel@lists.freedesktop.org > > > > > > > Subject: Re: [PATCH RFC 2/5] cgroup: Add mechanism to register > > > > > > > vendor specific DRM devices > > > > > > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > On Tue, Nov 20, 2018 at 10:21:14PM +, Ho, Kenny wr
Re: [PATCH V2] mm: Replace all open encodings for NUMA_NO_NODE
On Mon, 2018-11-26 at 17:56 +0530, Anshuman Khandual wrote: > At present there are multiple places where invalid node number is encoded > as -1. Even though implicitly understood it is always better to have macros > in there. Replace these open encodings for an invalid node number with the > global macro NUMA_NO_NODE. This helps remove NUMA related assumptions like > 'invalid node' from various places redirecting them to a common definition. > > Signed-off-by: Anshuman Khandual > --- > Changes in V2: > > - Added inclusion of 'numa.h' header at various places per Andrew > - Updated 'dev_to_node' to use NUMA_NO_NODE instead per Vinod > > Changes in V1: (https://lkml.org/lkml/2018/11/23/485) > > - Dropped OCFS2 changes per Joseph > - Dropped media/video drivers changes per Hans > > RFC - https://patchwork.kernel.org/patch/10678035/ > > Build tested this with multiple cross compiler options like alpha, sparc, > arm64, x86, powerpc, powerpc64le etc with their default config which might > not have compiled tested all driver related changes. I will appreciate > folks giving this a test in their respective build environment. > > All these places for replacement were found by running the following grep > patterns on the entire kernel code. Please let me know if this might have > missed some instances. This might also have replaced some false positives. > I will appreciate suggestions, inputs and review. > > 1. git grep "nid == -1" > 2. git grep "node == -1" > 3. git grep "nid = -1" > 4. git grep "node = -1" > > drivers/infiniband/hw/hfi1/affinity.c | 3 ++- > drivers/infiniband/hw/hfi1/init.c | 3 ++- For the drivers/infiniband changes, Acked-by: Doug Ledford -- Doug Ledford GPG KeyID: B826A3330E572FDD Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD signature.asc Description: This is a digitally signed message part ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
