guess you'll
> do a pull request anyway on the v4l side). Acked-by: me.
Oops,
Acked-by: Dave Airlie
Dave.
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 current implementation, dma_fence_default_wait w
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 just polls on them.
>
> If a
. 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
for inclusion via media.
Dave.
> drivers/gp
>
> 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 writi
On 4 August 2014 15:03, Hans Verkuil 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 Krause
>
> D
On 4 August 2014 13:25, 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.
>
Please go back and read every mail sent to you in the last few weeks.
then read them aga
On 20 June 2014 04:19, Greg KH 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 wrote:
>> > On Thu, Jun 19, 2014 at 10:00:18AM -0400, Rob Clark wrote:
>> >> On Wed, Jun 18, 2014 at 9:13 PM, Greg KH
>> >> wrote:
>> >> > On Wed, Jun 1
>>> 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 eve
On Tue, May 7, 2013 at 1:59 AM, Daniel Vetter 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
>>
>> 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
>
> Fyi for everyone else who was not on irc when Da
>> > Hi!
>> >
>> > There was still no maintainer, that commented, ack'd, nack'd, apply'd the
>> > series. So, this is just a resend.
>> > The patches were tested with:
>> >
>> > - v15 on Tegra by Thierry
>> > - sh-mobile-lcdcfb by Laurent
>> > - MX53QSB by Marek
>> >
On Thu, Dec 20, 2012 at 11:26 AM, Dave Airlie wrote:
> On Fri, Dec 14, 2012 at 7:36 PM, wrote:
>> From: Sumit Semwal
>>
>> Add debugfs support to make it easier to print debug information
>> about the dma-buf buffers.
>>
I've attached two patches that
On Fri, Dec 14, 2012 at 7:36 PM, wrote:
> From: Sumit Semwal
>
> 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
‘dma_buf_describe’:
/home/airlied/devel/kern
>
> 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 20
> 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, wh
> 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 ha
On Wed, Oct 17, 2012 at 8:25 PM, Alan Cox 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 rights
>> > holders
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 rea
>> 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
On Wed, Oct 17, 2012 at 7:53 PM, Alan Cox 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
>> this merged.
>
On Thu, Oct 11, 2012 at 9:34 PM, Alan Cox 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 export symbols GPL
>> On Thu, Oct 11, 2012 at 4:17 AM, Alan Cox wrote:
>> > On Wed, 10 Oct 2012 08:56:32 -0700
>> > Robert Morell wrote:
>> >
>> >> EXPORT_SYMBOL_GPL is intended to be used for "an internal implementation
>> >> issue, and not really an interface". The dma-buf infrastructure is
>> >> explicitly inte
On Thu, Oct 11, 2012 at 4:17 AM, Alan Cox wrote:
> On Wed, 10 Oct 2012 08:56:32 -0700
> Robert Morell wrote:
>
>> EXPORT_SYMBOL_GPL is intended to be used for "an internal implementation
>> issue, and not really an interface". The dma-buf infrastructure is
>> explicitly intended as an interface
On Tue, May 22, 2012 at 4:05 PM, Daniel Vetter wrote:
> On Tue, May 22, 2012 at 5:00 PM, Tomasz Stanislawski
> 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 discovered an interesting issue wi
On Sun, Mar 18, 2012 at 11:34 PM, Daniel Vetter 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 how blindly we should b
similar
> cases.
>
> Signed-off-by: Rob Clark
Reviewed-by: Dave Airlie
--
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
On Mon, Jan 9, 2012 at 8:10 AM, Daniel Vetter 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:
>> http://git.infradead.org/users/kmpark/linux-samsung/shortlog/r
sic
> use-case is really minimal, so I think it'd be great if this could go into
> 3.3 (maybe as some kind of staging/experimental infrastructure).
>
> Hence for both patches:
> Reviewed-by: Daniel Vetter
Yeah I'm with Daniel, I like this one, I can definitely build the drm
buffer sharing layer on top of this.
How do we see this getting merged? I'm quite happy to push it to Linus
if we don't have an identified path, though it could go via a Linaro
tree as well.
so feel free to add:
Reviewed-by: Dave Airlie
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
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 t
> +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);
> +
> +
On Tue, Oct 11, 2011 at 10:23 AM, Sumit Semwal 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 new buffer-obje
On Wed, Oct 12, 2011 at 3:24 PM, Rob Clark wrote:
> On Wed, Oct 12, 2011 at 9:01 AM, Dave Airlie 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
> 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 j
>
> 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 want
On Tue, Oct 11, 2011 at 10:23 AM, Sumit Semwal 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 new buffer-obje
On Wed, Mar 23, 2011 at 3:32 AM, Mythri P K 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 and VESA.
>
>
>> > Having the kms/fb/v4l2 drivers on top definitely makes sense, so
>> > these should all be able to be standalone loadable modules.
>> > I do not understand why you have a v4l2 driver at all, or why
>> > you need both fb and kms drivers, but that is probably because
>> > of my ignorance of dis
On Tue, Oct 19, 2010 at 11:26 PM, Arnd Bergmann 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
>>
> 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 us
>>
>> 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
On Tue, Oct 19, 2010 at 12:24 PM, Greg KH 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 wrote:
>> > On Tue, Oct 19, 2010 at 09:00:09AM +1000, Dave Airlie wrote:
>> >> On Tue, Oct 19, 2010 at 4:43
On Tue, Oct 19, 2010 at 10:40 AM, Greg KH 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 wrote:
>> > On Mon, Oct 18, 2010 at 05:42:06PM +0200, Arnd Bergmann wrote:
>> >>
>> >> Out of the
On Tue, Oct 19, 2010 at 4:43 AM, Greg KH 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 drivers/staging on
On Sat, May 29, 2010 at 6:06 AM, Ville Syrjälä 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 admit
45 matches
Mail list logo
