All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab@redhat.com>
To: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: dri-devel@lists.freedesktop.org, linux-media@vger.kernel.org,
	Jesse Barker <jesse.barker@linaro.org>
Subject: Re: Summary of the V4L2 discussions during LDS - was: Re: Embedded Linux memory management interest group list
Date: Tue, 17 May 2011 13:46:54 -0300	[thread overview]
Message-ID: <4DD2A67E.1030401@redhat.com> (raw)
In-Reply-To: <Pine.LNX.4.64.1105162238500.29373@axis700.grange>

Em 16-05-2011 17:45, Guennadi Liakhovetski escreveu:
> On Sat, 14 May 2011, Mauro Carvalho Chehab wrote:
> 
>> Em 18-04-2011 17:15, Jesse Barker escreveu:
>>> One of the big issues we've been faced with at Linaro is around GPU
>>> and multimedia device integration, in particular the memory management
>>> requirements for supporting them on ARM.  This next cycle, we'll be
>>> focusing on driving consensus around a unified memory management
>>> solution for embedded systems that support multiple architectures and
>>> SoCs.  This is listed as part of our working set of requirements for
>>> the next six-month cycle (in spite of the URL, this is not being
>>> treated as a graphics-specific topic - we also have participation from
>>> multimedia and kernel working group folks):
>>>
>>>   https://wiki.linaro.org/Cycles/1111/TechnicalTopics/Graphics
>>
>> As part of the memory management needs, Linaro organized several discussions
>> during Linaro Development Summit (LDS), at Budapest, and invited me and other
>> members of the V4L and DRI community to discuss about the requirements.
>> I wish to thank Linaro for its initiative.
> 
> [snip]
> 
>> Btw, the need of managing buffers is currently being covered by the proposal
>> for new ioctl()s to support multi-sized video-buffers [1].
>>
>> [1] http://www.spinics.net/lists/linux-media/msg30869.html
>>
>> It makes sense to me to discuss such proposal together with the above discussions, 
>> in order to keep the API consistent.
> 
> The author of that RFC would have been thankful, if he had been put on 
> Cc: ;) 

If I had added everybody interested on this summary, probably most smtp servers would
refuse to deliver the message thinking that it is a SPAM ;) My intention were to submit
a feedback about it when analysing your rfc patches, if you weren't able to see it
before.

> But anyway, yes, consistency is good, but is my understanding 
> correct, that functionally these two extensions - multi-size and 
> buffer-forwarding/reuse are independent?

Yes.

> We have to think about making the 
> APIs consistent, e.g., by reusing data structures. But it's also good to 
> make incremental smaller changes where possible, isn't it? So, yes, we 
> should think about consistency, but develop and apply those two extensions 
> separately?

True, but one discussion can benefit the other. IMO, we should not rush new
userspace API merges, to avoid merging a code that weren't reasonably discussed,
as otherwise, the API will become too messy.

Thanks,
Mauro.

      reply	other threads:[~2011-05-17 16:47 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-18 15:15 Embedded Linux memory management interest group list Jesse Barker
2011-05-14 10:19 ` Summary of the V4L2 discussions during LDS - was: " Mauro Carvalho Chehab
2011-05-14 11:02   ` Hans Verkuil
2011-05-14 11:46     ` Mauro Carvalho Chehab
2011-05-15 21:10       ` Hans Verkuil
2011-05-15 21:27         ` Alan Cox
2011-05-15 23:44           ` Rob Clark
2011-05-17 12:49         ` Mauro Carvalho Chehab
2011-05-17 12:57           ` Mauro Carvalho Chehab
2011-05-18 19:46         ` Sakari Ailus
2011-05-19 10:56           ` Mauro Carvalho Chehab
2011-05-16 20:45   ` Guennadi Liakhovetski
2011-05-17 16:46     ` Mauro Carvalho Chehab [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4DD2A67E.1030401@redhat.com \
    --to=mchehab@redhat.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=g.liakhovetski@gmx.de \
    --cc=jesse.barker@linaro.org \
    --cc=linux-media@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.