here too ?
References: https://bugzilla.kernel.org/show_bug.cgi?id=216303#c28
Signed-off-by: Daniel Vetter
Cc: Aaron Plattner
Cc: Javier Martinez Canillas
Cc: Thomas Zimmermann
Cc: Helge Deller
Cc: Sam Ravnborg
Cc: Alex Deucher
Cc: # v5.19+ (if someone else does the backport)
---
drivers/video/a
ier)
Fixes: ee7a69aa38d8 ("fbdev: Disable sysfb device registration when removing
conflicting FBs")
Tested-by: Aaron Plattner
Reviewed-by: Javier Martinez Canillas
References: https://bugzilla.kernel.org/show_bug.cgi?id=216303#c28
Signed-off-by: Daniel Vetter
Cc: Aaron Plattner
Cc:
On 09/08/2014 11:37 PM, Keith Packard wrote:
> With atomic mode setting in the kernel, I think you're probably right in
> proposing to eliminate explicit CRTC allocation from that. I do think
> you'll want to indicate the number of available CRTCs in the display
> engine, and the number of CRTCs ea
On 09/23/2014 01:29 PM, Benjamin Herrenschmidt wrote:
> On Mon, 2014-09-22 at 13:43 -0700, Linus Torvalds wrote:
>> Adding proper people and mailing lists..
>>
>> The PCI_CLASS_DISPLAY_VGA test goes back to the very beginning by
>> BenH, and I have no idea if adding PCI_CLASS_DISPLAY_3D is
>> appro
On 11/16/2012 01:14 PM, Jerome Glisse wrote:
> On Fri, Nov 16, 2012 at 12:05:40PM -0800, Aaron Plattner wrote:
>> At the suggestion of a few drm developers, I'm looking at abstracting the
>> buffer
>> sharing mechanism away from the individual drm drivers and tre
On 08/31/2012 08:00 PM, Dave Airlie wrote:
>> object interface, so that Optimus-based laptops can use our driver to drive
>> the discrete GPU and display on the integrated GPU. The good news is that
>> I've got a proof of concept working.
>
> Don't suppose you'll be interested in adding the other
At the suggestion of a few drm developers, I'm looking at abstracting the buffer
sharing mechanism away from the individual drm drivers and treating it as a
low-level interface that kernel subsystems use to communicate, rather than as
something drivers should be accessing directly. This would also
On 11/16/2012 01:14 PM, Jerome Glisse wrote:
On Fri, Nov 16, 2012 at 12:05:40PM -0800, Aaron Plattner wrote:
At the suggestion of a few drm developers, I'm looking at abstracting the buffer
sharing mechanism away from the individual drm drivers and treating it as a
low-level interface
d.
I haven't yet compile-tested the Exynos change since I don't have a toolchain
set up for that, but I'll try to do that today.
Aaron Plattner (4):
drm: add prime helpers
drm/nouveau: use prime helpers
drm/radeon: use prime helpers
drm/exynos: use prime helpers
drivers
.gem_prime_import and .gem_prime_export fields of
struct drm_driver.
Signed-off-by: Aaron Plattner
---
drivers/gpu/drm/drm_prime.c | 190 +++-
include/drm/drmP.h | 15
2 files changed, 204 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm
Simplify the Radeon prime implementation by using the default behavior provided
by drm_gem_prime_import and drm_gem_prime_export.
Signed-off-by: Aaron Plattner
---
drivers/gpu/drm/radeon/radeon_drv.c | 17 ++--
drivers/gpu/drm/radeon/radeon_prime.c | 169 +-
2
Simplify the Nouveau prime implementation by using the default behavior provided
by drm_gem_prime_import and drm_gem_prime_export.
Signed-off-by: Aaron Plattner
---
drivers/gpu/drm/nouveau/nouveau_bo.h| 1 -
drivers/gpu/drm/nouveau/nouveau_drm.c | 9 +-
drivers/gpu/drm/nouveau
Simplify the Exynos prime implementation by using the default behavior provided
by drm_gem_prime_import and drm_gem_prime_export.
Signed-off-by: Aaron Plattner
---
I still need to find a system to test this.
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 151
Simplify the Exynos prime implementation by using the default behavior provided
by drm_gem_prime_import and drm_gem_prime_export.
Signed-off-by: Aaron Plattner
---
v2: fix dumb mistakes now that I have a toolchain that can compile-test this
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 156
On 12/06/2012 10:36 PM, Inki Dae wrote:
Hi,
CCing media guys.
I agree with you but we should consider one issue released to v4l2.
As you may know, V4L2-based driver uses vb2 as buffer manager and the
vb2 includes dmabuf feature>(import and export) And v4l2 uses streaming
concept>(qbuf and dqb
On 12/06/2012 01:46 PM, Daniel Vetter wrote:
On Thu, Dec 06, 2012 at 10:07:48AM -0800, Aaron Plattner wrote:
Instead of reimplementing all of the dma_buf functionality in every driver,
create helpers drm_prime_import and drm_prime_export that implement them in
terms of new, lower-level hook
On 12/07/2012 10:48 AM, Daniel Vetter wrote:
On Fri, Dec 07, 2012 at 09:58:38AM -0800, Aaron Plattner wrote:
On 12/06/2012 01:46 PM, Daniel Vetter wrote:
- To make it a first-class helper and remove any and all midlayer stints
from this (I truly loath midlayers ...) maybe shovel this into a
On 12/07/2012 01:38 PM, Daniel Vetter wrote:
On Fri, Dec 7, 2012 at 9:33 PM, Aaron Plattner wrote:
Ah, I see what you mean. This would also need either a pointer to the drv
directly so the helpers can lock drv->struct_mutex, or a helper function to
convert from a drm_prime_helper_obj* t
. But this shouldn't be a problem
for exporters with statically allocated backing storage, and more
dynamic drivers have decent issues already anyway.
Inspired by some refactoring patches from Aaron Plattner, who
implemented the same idea, but only for drm/prime drivers.
v2: Check in dma_buf_re
. But this shouldn't be a problem
for exporters with statically allocated backing storage, and more
dynamic drivers have decent issues already anyway.
Inspired by some refactoring patches from Aaron Plattner, who
implemented the same idea, but only for drm/prime drivers.
v2: Check in dma_buf_re
o the dma-buf core code. It also drops
Exynos from the series since its driver diverged between when I first sent out
this series and now.
This series depends on commit 90b6e90cb03352a352015ca213ac9f4fab3308f3 of the
for-next branch of git://git.linaro.org/people/sumitsemwal/linux-dma-buf
Aaron Pla
idual functions from drmP.h, but the docproc / kernel-doc scripts
barf on that file, so hopefully this is good enough for now.
- apply refcount fix from commit be8a42ae60addd8b6092535c11b42d099d6470ec
("drm/prime: drop reference on imported dma-buf come from gem")
Signed-off-by: A
Simplify the Nouveau prime implementation by using the default behavior provided
by drm_gem_prime_import and drm_gem_prime_export.
v2: Rename functions to nouveau_gem_prime_get_sg_table and
nouveau_gem_prime_import_sg_table.
Signed-off-by: Aaron Plattner
Cc: Daniel Vetter
Cc: David Airlie
Simplify the Radeon prime implementation by using the default behavior provided
by drm_gem_prime_import and drm_gem_prime_export.
v2:
- Rename functions to radeon_gem_prime_get_sg_table and
radeon_gem_prime_import_sg_table.
- Delete the now-unused vmapping_count variable.
Signed-off-by: Aaron
On 01/16/2013 01:50 AM, Daniel Vetter wrote:
On Tue, Jan 15, 2013 at 12:47:42PM -0800, Aaron Plattner wrote:
Instead of reimplementing all of the dma_buf functionality in every driver,
create helpers drm_prime_import and drm_prime_export that implement them in
terms of new, lower-level hook
function.
This set is base on "exynos-drm-fixes" branch at
http://git.kernel.org/?p=linux/kernel/git/daeinki/drm-exynos.git
Signed-off-by: Rahul Sharma
Reviewed-by: Aaron Plattner
I also verified that this reduces my 2025-entry sg_table to 6 entries, so
Tested-by: Aaron Plattner
Signed-off-by: Aaron Plattner
---
Example output of dristat -C:
/dev/dri/card0
Device capabilities:
Dumb framebuffer: yes
VBlank high crtc: yes
Preferred depth: 24
Prefer shadow: yes
Prime: import export
tests/dristat.c | 69
So I've been experimenting with support for Dave Airlie's new RandR 1.4 provider
object interface, so that Optimus-based laptops can use our driver to drive the
discrete GPU and display on the integrated GPU. The good news is that I've got
a proof of concept working.
During a review of the curre
On 08/30/2012 10:31 AM, Aaron Plattner wrote:
So I've been experimenting with support for Dave Airlie's new RandR 1.4 provider
object interface, so that Optimus-based laptops can use our driver to drive the
discrete GPU and display on the integrated GPU. The good news is that I'
On 08/31/2012 08:00 PM, Dave Airlie wrote:
object interface, so that Optimus-based laptops can use our driver to drive
the discrete GPU and display on the integrated GPU. The good news is that
I've got a proof of concept working.
Don't suppose you'll be interested in adding the other method at
On 04/12/13 07:58, Daniel Vetter wrote:
On Tue, Jan 15, 2013 at 12:47:42PM -0800, Aaron Plattner wrote:
Instead of reimplementing all of the dma_buf functionality in every driver,
create helpers drm_prime_import and drm_prime_export that implement them in
terms of new, lower-level hook
On 05/20/2013 02:55 PM, Daniel Vetter wrote:
On Sat, May 18, 2013 at 12:39:14AM +0200, Jan Hinnerk Stosch wrote:
Hallo,
I hope this is the right place to ask, because I actually don't know
whether it is a bug or a feature that I'm experiencing since linux 3.9:
When I boot my system the backligh
On 06/03/2013 12:36 PM, Daniel Vetter wrote:
On Mon, Jun 03, 2013 at 09:13:18AM -0700, Aaron Plattner wrote:
On 05/20/2013 02:55 PM, Daniel Vetter wrote:
On Sat, May 18, 2013 at 12:39:14AM +0200, Jan Hinnerk Stosch wrote:
Hallo,
I hope this is the right place to ask, because I actually don
On 06/12/2013 06:16 AM, Joonyoung Shim wrote:
This adds to call low-level mmap() from prime helpers.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/drm_prime.c | 5 -
include/drm/drmP.h | 2 ++
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm
On 06/18/2013 04:08 PM, Laurent Pinchart wrote:
Hi Aaron,
A bit late, but here's a small question.
On Tuesday 15 January 2013 12:47:42 Aaron Plattner wrote:
Instead of reimplementing all of the dma_buf functionality in every driver,
create helpers drm_prime_import and drm_prime_export
On 06/18/2013 04:37 PM, Laurent Pinchart wrote:
Hi Aaron,
On Tuesday 18 June 2013 16:28:15 Aaron Plattner wrote:
On 06/18/2013 04:08 PM, Laurent Pinchart wrote:
Hi Aaron,
A bit late, but here's a small question.
On Tuesday 15 January 2013 12:47:42 Aaron Plattner wrote:
Inste
So I've been experimenting with support for Dave Airlie's new RandR 1.4 provider
object interface, so that Optimus-based laptops can use our driver to drive the
discrete GPU and display on the integrated GPU. The good news is that I've got
a proof of concept working.
During a review of the curren
On 08/30/2012 10:31 AM, Aaron Plattner wrote:
> So I've been experimenting with support for Dave Airlie's new RandR 1.4
> provider
> object interface, so that Optimus-based laptops can use our driver to drive
> the
> discrete GPU and display on the integrated GPU. T
d.
I haven't yet compile-tested the Exynos change since I don't have a toolchain
set up for that, but I'll try to do that today.
Aaron Plattner (4):
drm: add prime helpers
drm/nouveau: use prime helpers
drm/radeon: use prime helpers
drm/exynos: use prime helpers
drivers
.gem_prime_import and .gem_prime_export fields of
struct drm_driver.
Signed-off-by: Aaron Plattner
---
drivers/gpu/drm/drm_prime.c | 190 +++-
include/drm/drmP.h | 15
2 files changed, 204 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm
Simplify the Radeon prime implementation by using the default behavior provided
by drm_gem_prime_import and drm_gem_prime_export.
Signed-off-by: Aaron Plattner
---
drivers/gpu/drm/radeon/radeon_drv.c | 17 ++--
drivers/gpu/drm/radeon/radeon_prime.c | 169 +-
2
Simplify the Nouveau prime implementation by using the default behavior provided
by drm_gem_prime_import and drm_gem_prime_export.
Signed-off-by: Aaron Plattner
---
drivers/gpu/drm/nouveau/nouveau_bo.h| 1 -
drivers/gpu/drm/nouveau/nouveau_drm.c | 9 +-
drivers/gpu/drm/nouveau
Simplify the Exynos prime implementation by using the default behavior provided
by drm_gem_prime_import and drm_gem_prime_export.
Signed-off-by: Aaron Plattner
---
I still need to find a system to test this.
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 151
Simplify the Exynos prime implementation by using the default behavior provided
by drm_gem_prime_import and drm_gem_prime_export.
Signed-off-by: Aaron Plattner
---
v2: fix dumb mistakes now that I have a toolchain that can compile-test this
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 156
On 12/06/2012 10:36 PM, Inki Dae wrote:
>
> Hi,
>
> CCing media guys.
>
> I agree with you but we should consider one issue released to v4l2.
>
> As you may know, V4L2-based driver uses vb2 as buffer manager and the
> vb2 includes dmabuf feature>(import and export) And v4l2 uses streaming
> concept
On 12/06/2012 01:46 PM, Daniel Vetter wrote:
> On Thu, Dec 06, 2012 at 10:07:48AM -0800, Aaron Plattner wrote:
>> Instead of reimplementing all of the dma_buf functionality in every driver,
>> create helpers drm_prime_import and drm_prime_export that implement them in
>> term
On 12/07/2012 10:48 AM, Daniel Vetter wrote:
> On Fri, Dec 07, 2012 at 09:58:38AM -0800, Aaron Plattner wrote:
>> On 12/06/2012 01:46 PM, Daniel Vetter wrote:
>>> - To make it a first-class helper and remove any and all midlayer stints
>>>from this (I truly loath
On 12/07/2012 01:38 PM, Daniel Vetter wrote:
> On Fri, Dec 7, 2012 at 9:33 PM, Aaron Plattner
> wrote:
>> Ah, I see what you mean. This would also need either a pointer to the drv
>> directly so the helpers can lock drv->struct_mutex, or a helper function
w funny locking inversions. But this shouldn't be a problem
> for exporters with statically allocated backing storage, and more
> dynamic drivers have decent issues already anyway.
>
> Inspired by some refactoring patches from Aaron Plattner, who
> implemented the same idea, but only f
w funny locking inversions. But this shouldn't be a problem
> for exporters with statically allocated backing storage, and more
> dynamic drivers have decent issues already anyway.
>
> Inspired by some refactoring patches from Aaron Plattner, who
> implemented the same idea, but only f
em, and this change fixes it.
Tested-by: Aaron Plattner
Reviewed-by: Aaron Plattner
and since he just sent me an independently-developed identical change,
Reviewed-by: John Hubbard
> diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
> index 5736aaa7e86c..f7af69bcf3f4 10
On 05/03/2014 02:00 AM, Chris Wilson wrote:
> On Sat, May 03, 2014 at 07:08:02AM +1000, Dave Airlie wrote:
>> On 2 May 2014 18:52, Chris Wilson wrote:
>>> On Fri, May 02, 2014 at 02:39:37PM +1000, Dave Airlie wrote:
>> the GUID is only on DP 1.2 devices, so you don't get one for ever
>> port, also
On 05/07/2014 02:00 AM, Dave Airlie wrote:
> On 7 May 2014 17:16, Aaron Plattner wrote:
>> On 05/03/2014 02:00 AM, Chris Wilson wrote:
>>>
>>> On Sat, May 03, 2014 at 07:08:02AM +1000, Dave Airlie wrote:
>>>>
>>>> On 2 May 2014 18:52, Chris Wilso
On 05/07/2014 01:07 AM, Daniel Vetter wrote:
> On Wed, May 07, 2014 at 12:16:37AM -0700, Aaron Plattner wrote:
>> On 05/03/2014 02:00 AM, Chris Wilson wrote:
>>> On Sat, May 03, 2014 at 07:08:02AM +1000, Dave Airlie wrote:
>>>> On 2 May 2014 18:52, Chris Wilson wro
On 04/12/13 07:58, Daniel Vetter wrote:
> On Tue, Jan 15, 2013 at 12:47:42PM -0800, Aaron Plattner wrote:
>> Instead of reimplementing all of the dma_buf functionality in every driver,
>> create helpers drm_prime_import and drm_prime_export that implement them in
>> terms of
On 10/13/2014 08:23 PM, Dave Airlie wrote:
> Hi,
>
> So I've been hacking on mutter and the gnome pieces for tiling, and
> I've at least fixed mutter locally so maximise windows works and the
> heads are in the right order.
>
> Now I've strung all the pieces together using a single KMS property
> t
On 12/02/2014 07:04 PM, Dave Airlie wrote:
> On 3 December 2014 at 10:01, Aaron Plattner wrote:
>> On 10/13/2014 08:23 PM, Dave Airlie wrote:
>>>
>>> Hi,
>>>
>>> So I've been hacking on mutter and the gnome pieces for tiling, and
>>> I
Signed-off-by: Aaron Plattner
---
Example output of dristat -C:
/dev/dri/card0
Device capabilities:
Dumb framebuffer: yes
VBlank high crtc: yes
Preferred depth: 24
Prefer shadow: yes
Prime: import export
tests/dristat.c | 69
o the dma-buf core code. It also drops
Exynos from the series since its driver diverged between when I first sent out
this series and now.
This series depends on commit 90b6e90cb03352a352015ca213ac9f4fab3308f3 of the
for-next branch of git://git.linaro.org/people/sumitsemwal/linux-dma-buf
Aaron Pla
idual functions from drmP.h, but the docproc / kernel-doc scripts
barf on that file, so hopefully this is good enough for now.
- apply refcount fix from commit be8a42ae60addd8b6092535c11b42d099d6470ec
("drm/prime: drop reference on imported dma-buf come from gem")
Signed-off-by: A
Simplify the Nouveau prime implementation by using the default behavior provided
by drm_gem_prime_import and drm_gem_prime_export.
v2: Rename functions to nouveau_gem_prime_get_sg_table and
nouveau_gem_prime_import_sg_table.
Signed-off-by: Aaron Plattner
Cc: Daniel Vetter
Cc: David Airlie
Simplify the Radeon prime implementation by using the default behavior provided
by drm_gem_prime_import and drm_gem_prime_export.
v2:
- Rename functions to radeon_gem_prime_get_sg_table and
radeon_gem_prime_import_sg_table.
- Delete the now-unused vmapping_count variable.
Signed-off-by: Aaron
On 01/16/2013 01:50 AM, Daniel Vetter wrote:
> On Tue, Jan 15, 2013 at 12:47:42PM -0800, Aaron Plattner wrote:
>> Instead of reimplementing all of the dma_buf functionality in every driver,
>> create helpers drm_prime_import and drm_prime_export that implement them in
>> term
; supprot. NOUVEAU and RADEON platforms also depends on drm_prime_pages_to_sg
> helper function.
>
> This set is base on "exynos-drm-fixes" branch at
> http://git.kernel.org/?p=linux/kernel/git/daeinki/drm-exynos.git
>
> Signed-off-by: Rahul Sharma
Reviewed-by: Aaron Plattn
Signed-off-by: Aaron Plattner
---
Example output of dristat -C:
/dev/dri/card0
Device capabilities:
Dumb framebuffer: yes
VBlank high crtc: yes
Preferred depth: 24
Prefer shadow: yes
Prime: import export
tests/dristat.c | 69
At the suggestion of a few drm developers, I'm looking at abstracting the buffer
sharing mechanism away from the individual drm drivers and treating it as a
low-level interface that kernel subsystems use to communicate, rather than as
something drivers should be accessing directly. This would also
p://lists.freedesktop.org/archives/dri-devel/2014-December/073652.html
Signed-off-by: Aaron Plattner
---
Daniel, it looks like your change "[5/5] drm/irq: Don't call
->get_vblank_counter directly from irq_uninstall/cleanup" masks the immediate
problem, but it's not clear to
On 05/20/2013 02:55 PM, Daniel Vetter wrote:
> On Sat, May 18, 2013 at 12:39:14AM +0200, Jan Hinnerk Stosch wrote:
>> Hallo,
>>
>> I hope this is the right place to ask, because I actually don't know
>> whether it is a bug or a feature that I'm experiencing since linux 3.9:
>> When I boot my system
On 06/03/2013 12:36 PM, Daniel Vetter wrote:
> On Mon, Jun 03, 2013 at 09:13:18AM -0700, Aaron Plattner wrote:
>> On 05/20/2013 02:55 PM, Daniel Vetter wrote:
>>> On Sat, May 18, 2013 at 12:39:14AM +0200, Jan Hinnerk Stosch wrote:
>>>> Hallo,
>>>>
On 06/12/2013 06:16 AM, Joonyoung Shim wrote:
> This adds to call low-level mmap() from prime helpers.
>
> Signed-off-by: Joonyoung Shim
> ---
> drivers/gpu/drm/drm_prime.c | 5 -
> include/drm/drmP.h | 2 ++
> 2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drive
On 06/18/2013 04:08 PM, Laurent Pinchart wrote:
> Hi Aaron,
>
> A bit late, but here's a small question.
>
> On Tuesday 15 January 2013 12:47:42 Aaron Plattner wrote:
>> Instead of reimplementing all of the dma_buf functionality in every driver,
>> cre
On 06/18/2013 04:37 PM, Laurent Pinchart wrote:
> Hi Aaron,
>
> On Tuesday 18 June 2013 16:28:15 Aaron Plattner wrote:
>> On 06/18/2013 04:08 PM, Laurent Pinchart wrote:
>>> Hi Aaron,
>>>
>>> A bit late, but here's a small question.
>>>
>
72 matches
Mail list logo