t kind of settings do you have in the
"firmware" ?
> We have analysed this issue and hopefully there should be no
> request_firmware() calls from within probe(), as long as the host interface
> driver doesn't call s_power from it's probe() callback. I'm a
broader review.)
>
> > GPU is also a bit weird in some ways because while its normally
> > nonsensical to do things like use the capture facility one card to drive
> > part of another, it's actually rather useful (although not supported
> >
Hi Rob,
(CC'ing linux-media, as I believe this is very on-topic)
On Sunday 18 September 2011 18:14:26 Rob Clark wrote:
> On Sat, Sep 17, 2011 at 6:12 PM, Laurent Pinchart wrote:
> > On Thursday 15 September 2011 20:39:21 Florian Tobias Schandinat wrote:
> >> On 09/15/2011
l-archive.com/linux-samsung-
s...@vger.kernel.org/msg06292.html
[3] http://linuxtv.org/downloads/v4l-dvb-apis/media_common.html
[4] http://www.ideasonboard.org/media/omap3isp.ps
--
Regards,
Laurent Pinchart
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
M
platform and will allow applications to pass buffers around between device
drivers from different subsystems.
> In my semi-perfect world vision fb would be a legacy layer on top of DRM.
> DRM would get the silly recovery fail cases fixed, and a kernel console
> would be attachable to a GEM obje
solves all the
> embedded SoC problems (which involves use-cases optimized for no-copy
> cross media/drivers).
>
> Last but not least...
>
> On Linaro there is already discussions ongoing to solve one of the
> biggest issues from a SoC point of view and that is a "System Wide
> Memory manager" which manages buffer sharing and resolves no-copy use
> cases between devices/drivers. Read more on the following thread:
> http://lists.linaro.org/pipermail/linaro-dev/2011-March/003053.html.
--
Regards,
Laurent Pinchart
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
vendors and v4l2 persons.
> >
> > I hope several person are anticipated and made a small step for final
> > goal.
>
> I should be able to join, at least for the part related to buffer pools and
> related topics.
Same for me. I might not join for the whole week, so it
Hi Alex,
On Wednesday 16 March 2011 17:00:03 Alex Deucher wrote:
> On Wed, Mar 16, 2011 at 4:52 AM, Laurent Pinchart wrote:
> > On Tuesday 15 March 2011 17:47:47 Alex Deucher wrote:
> >
> > [snip]
> >
> >> FWIW, I have yet to see any v4l developers ever e
; necessary quirks for various hw, it may be bigger than you want.
> That's why we have GEM and TTM and driver specific memory management
> ioctls in the drm.
I agree that we might not be able to use the same memory buffers for all
devices, as they all have more or less complex requirements regarding the
memory properties (type, alignment, ...). However, having a common API to pass
buffers around between drivers and applications using a common ID would be
highly interesting. I'm not sure how complex that would be, I might not have
all the nasty small details in mind.
--
Regards,
Laurent Pinchart
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
be done this week, during
the V4L2 brainstorming meeting in Warsaw). We will then of course contact
DRM/DRI developers.
--
Regards,
Laurent Pinchart
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
On Tuesday 15 March 2011 17:07:10 Robert Fekete wrote:
> On 8 March 2011 20:23, Laurent Pinchart wrote:
> > On Tuesday 08 March 2011 20:12:45 Andy Walls wrote:
> >> On Tue, 2011-03-08 at 16:52 +0100, Laurent Pinchart wrote:
> >>
> >> [snip]
> >>
>
Hi Andy,
On Tuesday 08 March 2011 20:12:45 Andy Walls wrote:
> On Tue, 2011-03-08 at 16:52 +0100, Laurent Pinchart wrote:
>
> [snip]
>
> > > > It really shouldn't be that hard to get everyone involved together
> > > > and settle on a single solution (eit
...) and display it
on the GPU (OpenGL/ES). We need to be able to share a data buffer between the
ISP and the DSP, and another buffer between the DSP and the GPU. If processing
is not required, sharing a data buffer between the ISP and the GPU is
required. Achieving zero-copy requires a singl
On Monday 28 February 2011 11:21:52 Hans Verkuil wrote:
> On Monday, February 28, 2011 11:11:47 Laurent Pinchart wrote:
> > On Saturday 26 February 2011 13:12:42 Hans Verkuil wrote:
> > > On Friday, February 25, 2011 18:22:51 Linus Walleij wrote:
> > > > 2011/2/24 E
e time: CMA must be
*optional*. Not all hardware need contiguous memory. I'll have a look at the
next HWMEM version.
--
Regards,
Laurent Pinchart
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
gt;
> > I will be there and this was definitely a topic I intended to talk about.
> >
> > See you there.
>
> I'll also be there. Should we organize an official BOF session for this and
> invite more people?
Any chance of an IRC back
plement
> > > low power non(or minimal) CPU intervention pipelines where dedicated
> > > HW does the work most of the time(like full screen Video Playback).
> > >
> > > A common way of managing memory would of course also be n
is the global buffers
pool (see http://lwn.net/Articles/353044/ for instance, more information can
be found in the linux-media list archives).
[snip]
> > Let the discussion continue...
> >
> > On 17 February 2011 14:48, Laurent Pinchart wrote:
> >> On Thursday 10 Feb
end result is pretty much the same.
I think the biggest issue we will have here is that part of the inter-
processors communication stack lives in userspace in most recent SoCs (OMAP4
comes to mind for instance). This will make implementing a V4L2 driver that
re
vendors use the their own implementations.
> Our approach called it as CMA, others called it as cmem, carveout,
> hwmon and so on.
>
> I think Laurent's approaches is similar one.
Just for the record, my global buffers pool RFC didn't try to solve the
contiguous memory allocation problem. It aimed at providing drivers (and
applications) with an API to allocate and use buffers. How the memory is
allocated is outside the scope of the global buffers pool, CMA makes perfect
sense for that.
> We will try it again to merge CMA.
--
Regards,
Laurent Pinchart
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
> Linaro homepage:
>
> "Linaro™ brings together the open source community and the electronics
> industry to work on key projects, deliver great tools, reduce industry
> wide fragmentation and provide common foundations for Linux software
> distributions and stacks to land
hy not ask Hans Verkuil and Laurent Pinchart? Sorry for bringing you in
> like this but you are the true experts in v4l2.
No worries, I'm glad to be helpful.
> On 8 February 2011 13:42, SUBASH PATEL wrote:
> >
> > Thanks for sharing the slide. It was informative on OMA
22 matches
Mail list logo
