Eric Lavarde wrote:
> On 12/12/11 03:29, Jonathan Nieder wrote:
>> Does suspend-to-disk ("echo
>> disk>/sys/power/state") work fine in general?
>
> No idea in general, but I made some tests.
Thanks for this, and sorry for the slow response.
> First, it kind of worked: after restarting the comput
This adds support for the Terratec Cinergy HTC USB XS which is similar to
the Terratec H5 by adding the USB-ids to the table. According to
http://linux.terratec.de it uses the same ICs and DVB-C works for me
using the firmware of the H5.
Signed-off-by: Holger Nelson
---
diff --git a/drivers/me
dw2102_properties et al refer to entries in the USB-id table using
hard-coded indices, as in "&dw2102_table[6]", which means adding new
entries before the end of the list has the potential to introduce bugs
in code elsewhere in the file.
Use C99-style initializers with symbolic names for each inde
On 12/23/2011 03:38 PM, Andreas Oberritter wrote:
On 22.12.2011 22:30, Antti Palosaari wrote:
@@ -201,6 +205,9 @@ typedef enum fe_guard_interval {
GUARD_INTERVAL_1_128,
GUARD_INTERVAL_19_128,
GUARD_INTERVAL_19_256,
+GUARD_INTERVAL_PN420,
+GUARD_INTERVAL_PN595,
+GUAR
On 23.12.2011 22:54, Antti Palosaari wrote:
> On 12/23/2011 12:55 PM, Mauro Carvalho Chehab wrote:
>> On 22-12-2011 19:30, Antti Palosaari wrote:
>>> Rename DMB-TH to DTMB.
>>
>> Patrick seems to believe that CTTB is a better name. In any case,
>> whatever name we pick, I think that the DocBook spe
On 12/23/2011 12:55 PM, Mauro Carvalho Chehab wrote:
On 22-12-2011 19:30, Antti Palosaari wrote:
Rename DMB-TH to DTMB.
Patrick seems to believe that CTTB is a better name. In any case,
whatever name we pick, I think that the DocBook specs (and
maybe a comment at the header file) should point
Hi,
I am trying to implement v4l2 slave driver for ML86V76654 digital
video decoder that converts NTSC, PAL, SECAM analog video signals into
the YCbCr standard digital format. This codec takes 4 analog inputs(2
analog camera + 2 ext video in) and encodes in to digital(only one at
a time).
The dr
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:Fri Dec 23 19:00:18 CET 2011
git hash:875e2e3edf48a206c64195666cf408dd3d119137
gcc version: i686-linux-gcc (GCC
Linus,
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
v4l_for_linus
For a last time fix for the omap3 driver.
Thanks and Happy Seasons!
Mauro
Latest commit at the branch:
c070e38e4ee005f55895df177a9e14d90d6204b3 [media] omap3isp: Fix crash caused by
su
The conditional after the kzalloc says that the tested expression should
never be true, but if it were, the allocated data would have to be freed.
This change just moves the allocation below the test, to avoid any
possibility of the problem.
A simplified version of the semantic match that finds th
vpbe_dev needs to be freed before leaving the function in an error case.
A simplified version of the semantic match that finds the problem is as
follows: (http://coccinelle.lip6.fr)
//
@r exists@
local idexpression x;
statement S;
identifier f1;
position p1,p2;
expression *ptr != NULL;
@@
x@p1
On Fri, Dec 23, 2011 at 4:08 AM, Semwal, Sumit wrote:
> On Wed, Dec 21, 2011 at 1:50 AM, Dave Airlie wrote:
>
>>>
>>> I think this is a really good v1 version of dma_buf. It contains all the
>>> required bits (with well-specified semantics in the doc patch) to
>>> implement some basic use-cases
On Fri, Dec 23, 2011 at 4:00 AM, Semwal, Sumit wrote:
> On Wed, Dec 21, 2011 at 10:57 PM, Arnd Bergmann wrote:
>> On Tuesday 20 December 2011, Daniel Vetter wrote:
>>> > I'm thinking for a first version, we can get enough mileage out of it by
>>> > saying:
>>> > 1) only exporter can mmap to user
Hi Laurent,
On 12/23/2011 12:54 PM, Laurent Pinchart wrote:
> diff --git a/drivers/media/video/videobuf2-core.c
> b/drivers/media/video/videobuf2-core.c
> index 1250662..7d8a88b 100644
> --- a/drivers/media/video/videobuf2-core.c
> +++ b/drivers/media/video/videobuf2-core.c
>>>
On 22.12.2011 22:30, Antti Palosaari wrote:
> @@ -201,6 +205,9 @@ typedef enum fe_guard_interval {
> GUARD_INTERVAL_1_128,
> GUARD_INTERVAL_19_128,
> GUARD_INTERVAL_19_256,
> +GUARD_INTERVAL_PN420,
> +GUARD_INTERVAL_PN595,
> +GUARD_INTERVAL_PN945,
> } fe_guard_interval_t
On 22.12.2011 22:30, Antti Palosaari wrote:
> Rename DMB-TH to DTMB.
>
> Add few new values for existing parameters.
>
> Add two new parameters, interleaving and carrier.
> DTMB supports interleavers: 240 and 720.
> DTMB supports carriers: 1 and 3780.
>
> Signed-off-by: Antti Palosaari
> ---
>
Hi,
On Fri, Dec 23, 2011 at 6:38 PM, Marek Szyprowski
wrote:
> Hello,
>
> On Friday, December 23, 2011 10:51 AM Ming Lei wrote:
>
>> On Fri, Dec 23, 2011 at 5:34 PM, Marek Szyprowski
>> wrote:
>>
>> >> For example, on ARM, there is very limited kernel virtual address space
>> >> reserved
>> >>
Marek Szyprowski wrote:
>Hello,
>
>On Friday, December 23, 2011 12:29 PM Laurent Pinchart wrote:
>> On Friday 23 December 2011 08:09:25 Marek Szyprowski wrote:
>> > On Thursday, December 22, 2011 3:34 PM Javier Martin wrote:
>> > > we have a processing chain composed of three v4l2 devices:
>> > >
Hi Marek,
On Friday 23 December 2011 12:35:09 Marek Szyprowski wrote:
> On Friday, December 23, 2011 12:29 PM Laurent Pinchart wrote:
> > On Friday 23 December 2011 08:09:25 Marek Szyprowski wrote:
> > > On Thursday, December 22, 2011 3:34 PM Javier Martin wrote:
> > > > we have a processing chain
Hello,
On Friday, December 23, 2011 12:29 PM Laurent Pinchart wrote:
> On Friday 23 December 2011 08:09:25 Marek Szyprowski wrote:
> > On Thursday, December 22, 2011 3:34 PM Javier Martin wrote:
> > > we have a processing chain composed of three v4l2 devices:
> > >
> > > -
Hi Marek,
On Friday 23 December 2011 08:09:25 Marek Szyprowski wrote:
> On Thursday, December 22, 2011 3:34 PM Javier Martin wrote:
> > we have a processing chain composed of three v4l2 devices:
> >
> > - ---
> > --
> >
> > |
On 22-12-2011 19:30, Antti Palosaari wrote:
> Rename DMB-TH to DTMB.
Patrick seems to believe that CTTB is a better name. In any case,
whatever name we pick, I think that the DocBook specs (and
maybe a comment at the header file) should point all the known
ways to call this standard. So, I'm fine
On 23 December 2011 10:07, Guennadi Liakhovetski wrote:
> On Fri, 23 Dec 2011, javier Martin wrote:
>
>> Hi Guennadi,
>> thank you for your comments.
>>
>> On 23 December 2011 00:17, Guennadi Liakhovetski
>> wrote:
>> > On Thu, 22 Dec 2011, Javier Martin wrote:
>> >
>> >> To properly detect fram
Hello,
On Friday, December 23, 2011 10:51 AM Ming Lei wrote:
> On Fri, Dec 23, 2011 at 5:34 PM, Marek Szyprowski
> wrote:
>
> >> For example, on ARM, there is very limited kernel virtual address space
> >> reserved
> >> for DMA coherent buffer mapping, the default size is about 2M if I
> >> do
On Wed, Dec 21, 2011 at 1:50 AM, Dave Airlie wrote:
>>
>> I think this is a really good v1 version of dma_buf. It contains all the
>> required bits (with well-specified semantics in the doc patch) to
>> implement some basic use-cases and start fleshing out the integration with
>> various subsyste
On Wed, Dec 21, 2011 at 10:57 PM, Arnd Bergmann wrote:
> On Tuesday 20 December 2011, Daniel Vetter wrote:
>> > I'm thinking for a first version, we can get enough mileage out of it by
>> > saying:
>> > 1) only exporter can mmap to userspace
>> > 2) only importers that do not need CPU access to b
Hi Konrad,
On Tue, Dec 20, 2011 at 10:06 PM, Konrad Rzeszutek Wilk
wrote:
> On Mon, Dec 19, 2011 at 02:03:30PM +0530, 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
>> shar
Hi,
On Fri, Dec 23, 2011 at 5:34 PM, Marek Szyprowski
wrote:
>> For example, on ARM, there is very limited kernel virtual address space
>> reserved
>> for DMA coherent buffer mapping, the default size is about 2M if I
>> don't remember mistakenly.
>
> It can be easily increased for particular b
Hello,
On Friday, December 23, 2011 10:22 AM Ming Lei wrote:
> On Thu, Dec 22, 2011 at 5:28 PM, Marek Szyprowski
> wrote:
> >> DMA contig memory resource is very limited and precious, also
> >> accessing to it from CPU is very slow on some platform.
> >>
> >> For some cases(such as the comming f
On Thu, Dec 22, 2011 at 5:28 PM, Marek Szyprowski
wrote:
> Hello,
>
> On Wednesday, December 14, 2011 3:00 PM Ming Lei wrote:
>
>> DMA contig memory resource is very limited and precious, also
>> accessing to it from CPU is very slow on some platform.
>>
>> For some cases(such as the comming face
On Fri, 23 Dec 2011, javier Martin wrote:
> Hi Guennadi,
> thank you for your comments.
>
> On 23 December 2011 00:17, Guennadi Liakhovetski
> wrote:
> > On Thu, 22 Dec 2011, Javier Martin wrote:
> >
> >> To properly detect frame loss the driver must keep
> >> track of a frame_count.
> >>
> >>
On 12/23/2011 10:14 AM, Antti Palosaari wrote:
On 12/23/2011 01:45 AM, Miroslav Slugeň wrote:
This patch is wrong, please use 8971 instead.
Could you explain which is wrong? Your old code or that new override
version I explained?
fe->ops.read_signal_strength = fe->ops.tuner_ops.get_rf_strengt
On 12/23/2011 01:45 AM, Miroslav Slugeň wrote:
This patch is wrong, please use 8971 instead.
Could you explain which is wrong? Your old code or that new override
version I explained?
fe->ops.read_signal_strength = fe->ops.tuner_ops.get_rf_strength;
Antti
--
http://palosaari.fi/
--
To uns
33 matches
Mail list logo
