On Fri, Feb 3, 2012 at 8:18 PM, Marek Szyprowski
wrote:
> From: Michal Nazarewicz
>
> This commit exports some of the functions from compaction.c file
> outside of it adding their declaration into internal.h header
> file so that other mm related code can use them.
>
> This forced compaction.c to
On Fri, Feb 3, 2012 at 8:18 PM, Marek Szyprowski
wrote:
> The Contiguous Memory Allocator is a set of helper functions for DMA
> mapping framework that improves allocations of contiguous memory chunks.
>
> CMA grabs memory on system boot, marks it with CMA_MIGRATE_TYPE and
> gives back to the syst
# HG changeset patch
# User Jonathan McCrohan
# Date 1328407970 0
# Node ID 068772e2c579c9e8c32c81d2e7b5b6978e6afe7f
# Parent 69fc03702a6489ae46c50a3a5514df714d3832e8
add scan files for Ireland (ie-*)
Signed-off-by: Jonathan McCrohan
diff -r 69fc03702a64 -r 068772e2c579 util/scan/dvb-t/ie-Cair
On 02/05/2012 12:44 AM, Guennadi Liakhovetski wrote:
>> Yes, this is what I started with. What do you think about creating media
Actually now I have something like V4L2_MBUS_FMT_VYUY_JPEG_I1_1X8
(I1 indicating interleaving method), so it is not so tightly tied
to a particular sensor.
>> bus co
On Sat, 4 Feb 2012, Sakari Ailus wrote:
> Hi Sylwester,
>
> Sylwester Nawrocki wrote:
> > On 02/04/2012 12:22 PM, Sakari Ailus wrote:
[snip]
> >> I'd be much in favour or using a separate channel ID as Guennadi asked;
> >> that way you could quite probably save one memory copy as well. But if
>
On Sat, 4 Feb 2012, Sylwester Nawrocki wrote:
> Hi Sakari,
[snip]
> Yes, this is what I started with. What do you think about creating media
> bus codes directly corresponding the the user defined MIPI-CSI data types ?
We've discussed this before with Laurent, IIRC, and the decision was, that
Hi Sakari,
On 02/04/2012 09:30 PM, Sakari Ailus wrote:
>>> +#define V4L2_SUBDEV_SEL_FLAG_SIZE_GE (1<< 0)
>>> +#define V4L2_SUBDEV_SEL_FLAG_SIZE_LE (1<< 1)
>>> +#define V4L2_SUBDEV_SEL_FLAG_KEEP_CONFIG (1<< 2)
>>> +
>>> +/* active cropping
Hi Sylwester,
Thanks for the comments!!
Sylwester Nawrocki wrote:
> On 02/03/2012 12:54 AM, Sakari Ailus wrote:
>> Add support for VIDIOC_SUBDEV_S_SELECTION and VIDIOC_SUBDEV_G_SELECTION
>> IOCTLs. They replace functionality provided by VIDIOC_SUBDEV_S_CROP and
>> VIDIOC_SUBDEV_G_CROP IOCTLs and
Hi Sylwester,
Thanks for the review!
Sylwester Nawrocki wrote:
> On 02/03/2012 12:54 AM, Sakari Ailus wrote:
>> Add image source control class. This control class is intended to contain
>> low level controls which deal with control of the image capture process ---
>> the A/D converter in image se
On 02/03/2012 12:54 AM, Sakari Ailus wrote:
> Add support for VIDIOC_SUBDEV_S_SELECTION and VIDIOC_SUBDEV_G_SELECTION
> IOCTLs. They replace functionality provided by VIDIOC_SUBDEV_S_CROP and
> VIDIOC_SUBDEV_G_CROP IOCTLs and also add new functionality (composing).
>
> VIDIOC_SUBDEV_G_CROP and VID
This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.
Results of the daily build of media_tree:
date:Sat Feb 4 19:00:17 CET 2012
git hash:59b30294e14fa6a370fdd2bc2921cca1f977ef16
gcc version: i686-linux-gcc (GCC
Hi Sakari,
On 02/03/2012 12:54 AM, Sakari Ailus wrote:
> Add image source control class. This control class is intended to contain
> low level controls which deal with control of the image capture process ---
> the A/D converter in image sensors, for example.
>
> Signed-off-by: Sakari Ailus
> ---
Hi Sakari,
On 02/04/2012 04:43 PM, Sakari Ailus wrote:
>> As I explained above I suspect that the sensor sends each image data type
>> on separate channels (I'm not 100% sure) but the bridge is unable to DMA
>> it into separate memory regions.
>>
>> Currently we have no support in V4L2 for specify
Hi Laurent,
On 02/04/2012 12:34 PM, Laurent Pinchart wrote:
> On Thursday 02 February 2012 12:14:08 Sylwester Nawrocki wrote:
>> On 02/02/2012 10:55 AM, Laurent Pinchart wrote:
>>> Do all those sensors interleave the data in the same way ? This sounds
>>> quite
>> No, each one uses it's own interl
Hi Sylwester,
Sylwester Nawrocki wrote:
> On 02/04/2012 12:22 PM, Sakari Ailus wrote:
>> Sylwester Nawrocki wrote:
>>> On 02/01/2012 11:00 AM, Sakari Ailus wrote:
I'd guess that all the ISP would do to such formats is to write them to
memory since I don't see much use for either in ISPs
Hi Laurent,
On 02/04/2012 12:30 PM, Laurent Pinchart wrote:
>> I'd be much in favour or using a separate channel ID as Guennadi asked;
>> that way you could quite probably save one memory copy as well. But if
>> the hardware already exists and behaves badly there's usually not much
>> you can do a
Hi Sakari,
On 02/04/2012 12:22 PM, Sakari Ailus wrote:
> Sylwester Nawrocki wrote:
>> On 02/01/2012 11:00 AM, Sakari Ailus wrote:
>>> I'd guess that all the ISP would do to such formats is to write them to
>>> memory since I don't see much use for either in ISPs --- both typically are
>>> output o
On Sat, Feb 4, 2012 at 12:48 PM, Gary Thomas wrote:
> On 2012-01-30 10:30, Gary Thomas wrote:
>>
>> On 2012-01-20 05:19, Laurent Pinchart wrote:
>>>
>>> Hi Enrico,
>>>
>>> On Thursday 19 January 2012 15:17:57 Enrico wrote:
On Thu, Jan 19, 2012 at 2:52 PM, Gary Thomas wrote:
>
> O
Hi Jesper,
On Thu, Feb 02, 2012 at 10:15:06PM +0100, Jesper Juhl wrote:
> Signed-off-by: Jesper Juhl
> ---
> drivers/media/video/adp1653.c |1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> compile tested only.
>
> diff --git a/drivers/media/video/adp1653.c b/drivers/media/vide
On 2012-01-30 10:30, Gary Thomas wrote:
On 2012-01-20 05:19, Laurent Pinchart wrote:
Hi Enrico,
On Thursday 19 January 2012 15:17:57 Enrico wrote:
On Thu, Jan 19, 2012 at 2:52 PM, Gary Thomas wrote:
On 2012-01-19 06:35, Gary Thomas wrote:
My camera init code is attached. In the previous kern
Hi Rob,
Clark, Rob wrote:
> On Mon, Jan 30, 2012 at 4:01 PM, Sakari Ailus wrote:
>>
>>> So to summarize I understand your constraints - gpu drivers have worked
>>> like v4l a few years ago. The thing I'm trying to achieve with this
>>> constant yelling is just to raise awereness for these issues
Hi Guennadi,
On Thursday 02 February 2012 12:00:57 Guennadi Liakhovetski wrote:
> On Thu, 2 Feb 2012, Laurent Pinchart wrote:
> > Do all those sensors interleave the data in the same way ? This sounds
> > quite hackish and vendor-specific to me, I'm not sure if we should try to
> > generalize that
Hi Sylwester,
On Thursday 02 February 2012 12:14:08 Sylwester Nawrocki wrote:
> On 02/02/2012 10:55 AM, Laurent Pinchart wrote:
> > Do all those sensors interleave the data in the same way ? This sounds
> > quite
> No, each one uses it's own interleaving method.
>
> > hackish and vendor-specific
Hi Sakari,
On Saturday 04 February 2012 13:22:21 Sakari Ailus wrote:
> Sylwester Nawrocki wrote:
> > On 02/01/2012 11:00 AM, Sakari Ailus wrote:
> >> I'd guess that all the ISP would do to such formats is to write them to
> >> memory since I don't see much use for either in ISPs --- both typically
Hi Sylwester,
Sylwester Nawrocki wrote:
> On 02/01/2012 11:00 AM, Sakari Ailus wrote:
>> I'd guess that all the ISP would do to such formats is to write them to
>> memory since I don't see much use for either in ISPs --- both typically are
>> output of the ISP.
>
> Yep, correct. In fact in those
Am Dienstag, den 31.01.2012, 12:39 +0100 schrieb Jürgen Hein:
> Hallo,
>
> with the current drivers from media_build_experimental for hauppauge
> NOVA-S Plus (Conexant 2388x (bt878 successor) support (VIDEO_CX88)
> cx8800...)does this here not more. Picture and sound with significant
> dropouts.
>
2012/2/3 Michal Nazarewicz :
>>> +static inline bool migrate_async_suitable(int migratetype)
>
> On Fri, 03 Feb 2012 15:19:54 +0100, Hillf Danton wrote:
>>
>> Just nitpick, since the helper is not directly related to what async
>> means,
>> how about migrate_suitable(int migrate_type) ?
>
>
> I fe
27 matches
Mail list logo
