Hi,
Why:
While sharing buffers using dma-buf, currently there's no mechanism to let
devices share their memory access constraints with each other to allow for
delayed allocation of backing storage.
This RFC attempts to introduce the idea of memory constraints of a device,
and how these cons
At present, struct device lacks a mechanism of exposing memory
access constraints for the device.
Consequently, there is also no mechanism to share these constraints
while sharing buffers using dma-buf.
If we add support for sharing such constraints, we could use that
to try to collect requiremen
Devices sharing buffers using dma-buf could benefit from sharing their
constraints via struct device, and dma-buf framework would manage the
common constraints for all attached devices per buffer.
With that information, we could have a 'generic' allocator helper in
the form of a central dma-buf ex
Add the build files for cenalloc, the constraints-enabled allocation
helper framework for dma-buf.
Signed-off-by: Sumit Semwal
Cc: linux-kernel at vger.kernel.org
Cc: Greg Kroah-Hartman
Cc: linux-media at vger.kernel.org
Cc: dri-devel at lists.freedesktop.org
Cc: linaro-mm-sig at lists.linaro.or
From: Benjamin Gaignard
Signed-off-by: Benjamin Gaignard
Signed-off-by: Sumit Semwal
Cc: linux-kernel at vger.kernel.org
Cc: Greg Kroah-Hartman
Cc: linux-media at vger.kernel.org
Cc: dri-devel at lists.freedesktop.org
Cc: linaro-mm-sig at lists.linaro.org
---
drivers/cenalloc/Makefile
the device ID then.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141011/7f627881/attachment.html>
Daniel,
A while back you had a go at fixing the framebuffer reference counting.
Unfortunately, I'm still seeing leaks, particularly with the framebuffer
used with a mode set which is subsequently flipped. It is only this
framebuffer which is leaked, flips of an already flipped framebuffer do
not.
l/attachments/20141011/741cf50e/attachment.html>
On Sat, Oct 11, 2014 at 10:26:20AM +0100, Russell King - ARM Linux wrote:
> Daniel,
>
> A while back you had a go at fixing the framebuffer reference counting.
> Unfortunately, I'm still seeing leaks, particularly with the framebuffer
> used with a mode set which is subsequently flipped. It is on
L attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141011/13dda615/attachment.html>
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141011/e9dee99f/attachment.html>
On Thu, Oct 9, 2014 at 8:33 PM, Oded Gabbay wrote:
> Thanks for the input.
> I do _not_ intend to fork IOCTLs for new H/W generations, if possible.
> i.e, our driver now supports 2 h/w generations with the exact same set
> of IOCTLs and I don't see how that would change in the future..
>
> What I'
On Fri, Oct 10, 2014 at 05:59:19PM +0900, Michel D?nzer wrote:
> On 10.10.2014 17:51, Alan Swanson wrote:
> >On Fri, 2014-10-10 at 12:20 +0900, Michel D?nzer wrote:
> >>On 09.10.2014 19:22, Alan Swanson wrote:
> >>>On 2014-10-09 07:02, Michel D?nzer wrote:
> From: Michel D?nzer
>
> Th
On Fri, Oct 10, 2014 at 02:31:55PM +0200, Andrzej Hajda wrote:
> Before DPMS off driver disables vblank.
> It should be balanced by vblank enable after DPMS on.
> The patch fixes issue with page_flip ioctl not being able
> to acquire vblank counter introduced by patch:
> drm: Always reject drm_vbla
On Fri, Oct 10, 2014 at 04:09:00PM -0700, Greg Kroah-Hartman wrote:
> On Sat, Oct 11, 2014 at 01:37:56AM +0530, Sumit Semwal wrote:
> > Devices sharing buffers using dma-buf could benefit from sharing their
> > constraints via struct device, and dma-buf framework would manage the
> > common constra
On Sat, Oct 11, 2014 at 01:37:55AM +0530, Sumit Semwal wrote:
> At present, struct device lacks a mechanism of exposing memory
> access constraints for the device.
>
> Consequently, there is also no mechanism to share these constraints
> while sharing buffers using dma-buf.
>
> If we add support
On Sat, Oct 11, 2014 at 10:26:20AM +0100, Russell King - ARM Linux wrote:
> Daniel,
>
> A while back you had a go at fixing the framebuffer reference counting.
> Unfortunately, I'm still seeing leaks, particularly with the framebuffer
> used with a mode set which is subsequently flipped. It is on
On Sat, Oct 11, 2014 at 08:31:49PM +0200, Daniel Vetter wrote:
> On Fri, Oct 10, 2014 at 05:59:19PM +0900, Michel D?nzer wrote:
> > On 10.10.2014 17:51, Alan Swanson wrote:
> > >On Fri, 2014-10-10 at 12:20 +0900, Michel D?nzer wrote:
> > >>On 09.10.2014 19:22, Alan Swanson wrote:
> > >>>On 2014-10-
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141011/bf613b37/attachment.html>
---
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141011/d0bf6cd3/attachment.html>
Removing the unnecessary drm_err __func__ argument by using
the equivalent %pf and __builtin_return_address(0) makes the
code smaller for every use of the DRM_ERROR macro.
For instance: (allmodconfig)
$ size drivers/gpu/drm/i915/i915.o*
textdata bss dec hex filename
922447 19
21 matches
Mail list logo
