Re: [PATCH v3 0/8] R-Car DU: Support CRC calculation

t > case we do a topic branch or something like that (since I guess you'll > do a pull request anyway on the v4l side). Acked-by: me. Oops, Acked-by: Dave Airlie <airl...@redhat.com> Dave.

Re: [Linaro-mm-sig] [PATCH] dma-buf: avoid scheduling on fence status query v2

On 28 April 2017 at 07:27, Gustavo Padovan wrote: > 2017-04-26 Christian König : > >> Am 26.04.2017 um 16:46 schrieb Andres Rodriguez: >> > When a timeout of zero is specified, the caller is only interested in >> > the fence status. >> > >> > In the

Re: [PATCH] dma-buf: avoid scheduling on fence status query

On 26 April 2017 at 17:20, Christian König wrote: > NAK, I'm wondering how often I have to reject that change. We should > probably add a comment here. > > Even with a zero timeout we still need to enable signaling, otherwise some > fence will never signal if userspace

Re: [PATCH 0/2] Renesas R-Car Gen3 DU alpha and z-order support

related to the > DU driver for v4.7. If you're fine with that, could you ack the patches ? > > Laurent Pinchart (2): > drm: rcar-du: Add Z-order support for VSP planes > drm: rcar-du: Add alpha support for VSP planes > Seems fine, Acked-by: Dave AIrlie <airl...@

Re: [PATCH] v4l2: Change call of function in videobuf2-core.c

On 4 August 2014 13:25, Nicholas Krause xerofo...@gmail.com wrote: This patch changes the call of vb2_buffer_core to use VB2_BUFFER_STATE_ACTIVE inside the for instead of not setting in correctly to VB2_BUFFER_STATE_ERROR. Please go back and read every mail sent to you in the last few weeks.

Re: [PATCH] v4l2: Change call of function in videobuf2-core.c

On 4 August 2014 15:03, Hans Verkuil hverk...@xs4all.nl wrote: On 08/04/2014 05:25 AM, Nicholas Krause wrote: This patch changes the call of vb2_buffer_core to use VB2_BUFFER_STATE_ACTIVE inside the for instead of not setting in correctly to VB2_BUFFER_STATE_ERROR. Signed-off-by: Nicholas

Re: [PATCH] v4l2: Change call of function in videobuf2-core.c

Dave, I understand your issues with my programming. I need to try and understand the kernel first before programming for it. Why do you insist on sending more patches then, every day you try and send another one or two, despite been told multiple times to a) understand what you are writing,

Re: [REPOST PATCH 1/8] fence: dma-buf cross-device synchronization (v17)

On 20 June 2014 04:19, Greg KH gre...@linuxfoundation.org wrote: On Thu, Jun 19, 2014 at 01:45:30PM -0400, Rob Clark wrote: On Thu, Jun 19, 2014 at 1:00 PM, Greg KH gre...@linuxfoundation.org wrote: On Thu, Jun 19, 2014 at 10:00:18AM -0400, Rob Clark wrote: On Wed, Jun 18, 2014 at 9:13 PM,

Re: [PATCH] drm/udl: avoid swiotlb for imported vmap buffers.

On Tue, May 7, 2013 at 1:59 AM, Daniel Vetter dan...@ffwll.ch wrote: On Mon, May 06, 2013 at 10:35:35AM +1000, Dave Airlie wrote: However if we don't set a dma mask on the usb device, the mapping ends up using swiotlb on machines that have it enabled, which is less than desireable

Re: [PATCH] drm/udl: avoid swiotlb for imported vmap buffers.

One that appears the same as a GEM object created by userspace. i.e. mmap works. Oh, we have an mmap interface in the dma_buf thing for that, and iirc Rob Clark even bothered to implement the gem-dma_buf mmap forwarding somewhere. And iirc android's ion-on-dma_buf stuff is even using the

Re: [PATCH] drm/udl: avoid swiotlb for imported vmap buffers.

However if we don't set a dma mask on the usb device, the mapping ends up using swiotlb on machines that have it enabled, which is less than desireable. Signed-off-by: Dave Airlie airl...@redhat.com Fyi for everyone else who was not on irc when DaveI discussed this: This really shouldn't

Re: [PATCH] dma-buf: Add debugfs support

On Fri, Dec 14, 2012 at 7:36 PM, sumit.sem...@ti.com wrote: From: Sumit Semwal sumit.sem...@linaro.org Add debugfs support to make it easier to print debug information about the dma-buf buffers. I like thie idea, /home/airlied/devel/kernel/drm-2.6/drivers/base/dma-buf.c: In function

Re: [PATCH] dma-buf: Add debugfs support

On Thu, Dec 20, 2012 at 11:26 AM, Dave Airlie airl...@gmail.com wrote: On Fri, Dec 14, 2012 at 7:36 PM, sumit.sem...@ti.com wrote: From: Sumit Semwal sumit.sem...@linaro.org Add debugfs support to make it easier to print debug information about the dma-buf buffers. I've attached two

Re: [RFC v2 0/5] Common Display Framework

Many developers showed interest in the first RFC, and I've had the opportunity to discuss it with most of them. I would like to thank (in no particular order) Tomi Valkeinen for all the time he spend helping me to draft v2, Marcus Lorentzon for his useful input during Linaro Connect Q4 2012,

Re: [Linaro-mm-sig] [PATCH] dma-buf: Use EXPORT_SYMBOL

Unlikely as most of the code I've written belongs to Intel or Red Hat. I also have better things to do with life than sue Nvidia and start an all out copyright and patent war in Linuxspace. I forgot to ask, but after your petty G+ trolling, if most of the code belings to Intel or Red Hat, why

Re: [Linaro-mm-sig] [PATCH] dma-buf: Use EXPORT_SYMBOL

On Wed, Oct 17, 2012 at 7:53 PM, Alan Cox a...@lxorguk.ukuu.org.uk wrote: I believe that the developers and maintainers of dma-buf have provided the needed signoff, both in person and in this thread. If there are any objections from that group, I'm happy to discuss any changes necessary to get

Re: [Linaro-mm-sig] [PATCH] dma-buf: Use EXPORT_SYMBOL

Please go and discuss estoppel, wilful infringement and re-licensing with your corporate attorneys. If you want to relicense components of the code then please take the matter up with the corporate attorneys of the rights holders concerned. Alan please stick with the facts. This isn't a

Re: [Linaro-mm-sig] [PATCH] dma-buf: Use EXPORT_SYMBOL

b Alan please stick with the facts. This isn't a relicense of anything. EXPORT_SYMBOL_GPL isn't a license its nothing like a license. Its a totally pointless thing, it should be EXPORT_SYMBOL_USERS_MIGHT_BE_DERIVED_CONSULT_YOUR_LAWYER, but it really should be EXPORT_SYMBOL, and really consult

Re: [Linaro-mm-sig] [PATCH] dma-buf: Use EXPORT_SYMBOL

On Wed, Oct 17, 2012 at 8:25 PM, Alan Cox a...@lxorguk.ukuu.org.uk wrote: Please go and discuss estoppel, wilful infringement and re-licensing with your corporate attorneys. If you want to relicense components of the code then please take the matter up with the corporate attorneys of the

Re: [Linaro-mm-sig] [PATCH] dma-buf: Use EXPORT_SYMBOL

From the fact this patch keeps getting resubmitted despite repeated objection I deduce they are in fact of the view it does matter and that therefore it is a licensing change and they are scared of the consequences of ignoring it. No I think they just want to have to write a pointless hack

Re: [Linaro-mm-sig] [PATCH] dma-buf: Use EXPORT_SYMBOL

On Thu, Oct 11, 2012 at 9:34 PM, Alan Cox a...@lxorguk.ukuu.org.uk wrote: The whole purpose of this API is to let DRM and V4L drivers share buffers for zero-copy pipelines. Unfortunately it is a fact that several popular DRM drivers are closed source. So we have a choice between keeping the

Re: [PATCH] dma-buf: Use EXPORT_SYMBOL

On Thu, Oct 11, 2012 at 4:17 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote: On Wed, 10 Oct 2012 08:56:32 -0700 Robert Morell rmor...@nvidia.com wrote: EXPORT_SYMBOL_GPL is intended to be used for an internal implementation issue, and not really an interface. The dma-buf infrastructure is

Re: [PATCH] dma-buf: Use EXPORT_SYMBOL

On Thu, Oct 11, 2012 at 4:17 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote: On Wed, 10 Oct 2012 08:56:32 -0700 Robert Morell rmor...@nvidia.com wrote: EXPORT_SYMBOL_GPL is intended to be used for an internal implementation issue, and not really an interface. The dma-buf infrastructure is

Re: [PATCH] dma-buf: add get_dma_buf()

On Tue, May 22, 2012 at 4:05 PM, Daniel Vetter dan...@ffwll.ch wrote: On Tue, May 22, 2012 at 5:00 PM, Tomasz Stanislawski t.stanisl...@samsung.com wrote: On 05/22/2012 04:32 PM, Daniel Vetter wrote: On Tue, May 22, 2012 at 03:47:12PM +0200, Tomasz Stanislawski wrote: Hi, I think I

Re: [Linaro-mm-sig] [PATCH 4/4] dma-buf: document fd flags and O_CLOEXEC requirement

On Sun, Mar 18, 2012 at 11:34 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote: Otherwise subsystems will get this wrong and end up with and second export ioctl with the flag and O_CLOEXEC support added. Its not actually dma_buf_export that takes the O_CLOEXEC flag its dma_buf_fd I'm not sure

Re: [Linaro-mm-sig] [PATCH] dma-buf: add get_dma_buf()

other similar cases. Signed-off-by: Rob Clark r...@ti.com Reviewed-by: Dave Airlie airl...@redhat.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism

On Mon, Jan 9, 2012 at 8:10 AM, Daniel Vetter dan...@ffwll.ch wrote: On Mon, Jan 09, 2012 at 03:20:48PM +0900, InKi Dae wrote: I has test dmabuf based drm gem module for exynos and I found one problem. you can refer to this test repository:

Re: [Linaro-mm-sig] [RFC v3 0/2] Introduce DMA buffer sharing mechanism

: Reviewed-by: Dave Airlie airl...@redhat.com Dave. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [Linaro-mm-sig] [RFC 1/2] dma-buf: Introduce dma buffer sharing mechanism

+struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf, +                                               struct device *dev) +{ +       struct dma_buf_attachment *attach; +       int ret; + +       BUG_ON(!dmabuf || !dev); + +       mutex_lock(dmabuf-lock); + +       attach =

Re: [Linaro-mm-sig] [RFC 1/2] dma-buf: Introduce dma buffer sharing mechanism

I've rebuilt my PRIME interface on top of dmabuf to see how it would work, I've got primed gears running again on top, but I expect all my object lifetime and memory ownership rules need fixing up (i.e. leaks like a sieve). http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-prime-dmabuf has

Re: [Linaro-mm-sig] [RFC 1/2] dma-buf: Introduce dma buffer sharing mechanism

On Tue, Oct 11, 2011 at 10:23 AM, Sumit Semwal sumit.sem...@ti.com wrote: This is the first step in defining a dma buffer sharing mechanism. A new buffer object dma_buf is added, with operations and API to allow easy sharing of this buffer object across devices. The framework allows: - a

Re: [Linaro-mm-sig] [RFC 1/2] dma-buf: Introduce dma buffer sharing mechanism

well, the mmap is actually implemented by the buffer allocator (v4l/drm).. although not sure if this was the point Then why not use the correct interface? doing some sort of not-quite generic interface isn't really helping anyone except adding an ABI that we have to support. If someone wants

Re: [Linaro-mm-sig] [RFC 1/2] dma-buf: Introduce dma buffer sharing mechanism

But then we'd need a different set of accessors for every different drm/v4l/etc driver, wouldn't we? Not any more different than you need for this, you just have a new interface that you request a sw object from, then mmap that object, and underneath it knows who owns it in the kernel. mmap

Re: [Linaro-mm-sig] [RFC 1/2] dma-buf: Introduce dma buffer sharing mechanism

On Wed, Oct 12, 2011 at 3:24 PM, Rob Clark robdcl...@gmail.com wrote: On Wed, Oct 12, 2011 at 9:01 AM, Dave Airlie airl...@gmail.com wrote: But then we'd need a different set of accessors for every different drm/v4l/etc driver, wouldn't we? Not any more different than you need for this, you

Re: [RFC PATCH] HDMI:Support for EDID parsing in kernel.

On Wed, Mar 23, 2011 at 3:32 AM, Mythri P K mythr...@ti.com wrote: Adding support for common EDID parsing in kernel. EDID - Extended display identification data is a data structure provided by a digital display to describe its capabilities to a video source, This a standard supported by CEA

Re: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do

On Tue, Oct 19, 2010 at 11:26 PM, Arnd Bergmann a...@arndb.de wrote: On Tuesday 19 October 2010, Arnd Bergmann wrote: On Tuesday 19 October 2010 06:52:32 Dave Airlie wrote: I might be able to find some hardware still lying around here that uses an i810. Not sure unless I go hunting

Re: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do

On Tue, Oct 19, 2010 at 4:43 AM, Greg KH g...@kroah.com wrote: On Mon, Oct 18, 2010 at 05:42:06PM +0200, Arnd Bergmann wrote: Out of the remaining modules, I guess i810/i830, adfs, hpfs and ufs might end up not getting fixed at all, we can either mark them non-SMP or move them to

Re: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do

On Tue, Oct 19, 2010 at 10:40 AM, Greg KH g...@kroah.com wrote: On Tue, Oct 19, 2010 at 09:00:09AM +1000, Dave Airlie wrote: On Tue, Oct 19, 2010 at 4:43 AM, Greg KH g...@kroah.com wrote: On Mon, Oct 18, 2010 at 05:42:06PM +0200, Arnd Bergmann wrote: Out of the remaining modules, I guess

Re: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do

On Tue, Oct 19, 2010 at 12:24 PM, Greg KH g...@kroah.com wrote: On Tue, Oct 19, 2010 at 10:57:43AM +1000, Dave Airlie wrote: On Tue, Oct 19, 2010 at 10:40 AM, Greg KH g...@kroah.com wrote: On Tue, Oct 19, 2010 at 09:00:09AM +1000, Dave Airlie wrote: On Tue, Oct 19, 2010 at 4:43 AM, Greg KH g

Re: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do

like I'm sure the intersection of this driver and reality are getting quite limited, but its still a userspace ABI change and needs to be treated as such. Xorg 6.7 and XFree86 4.3 were the last users of the old driver/API. Thus, you are saying that this will break for people with older user

Re: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do

I might be able to find some hardware still lying around here that uses an i810. Not sure unless I go hunting it. But I get the impression that if the kernel is a single-CPU kernel there is not any problem anyway? Don't distros offer a non-smp kernel as an installation option in case the user

Re: Idea of a v4l - fb interface driver

On Sat, May 29, 2010 at 6:06 AM, Ville Syrjälä syrj...@sci.fi wrote: On Fri, May 28, 2010 at 03:41:46PM -0400, Alex Deucher wrote: On Fri, May 28, 2010 at 3:15 PM, Florian Tobias Schandinat If he wants different (independent) content on each output, just provide multiple /dev/fbX devices. I