The following changes since commit 4e2c53fde651be6225d9f940c02b2eabc2f9591c:
[media] dvb: Add support for pctv452e (2011-09-24 00:07:42 -0300)
are available in the git repository at:
http://linuxtv.org/git/liplianin/media_tree.git netup_patches
Abylay Ospan (2):
NetUP Dual DVB-T/C CI R
Im trying to build the master for the build media git (specifically for
the driver for the hdpvr).
First error is from a patch is (altera patch):
1 out of 1 hunk FAILED -- saving rejects to file
drivers/media/video/cx23885/cx23885-cards.c.rej
I commented out the patch from backports/backports
> -Original Message-
> From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
> Sent: Wednesday, August 24, 2011 3:58 PM
> To: Hiremath, Vaibhav
> Cc: linux-media@vger.kernel.org
> Subject: [PATCH] omap_vout: Add poll() support
>
> Signed-off-by: Laurent Pinchart
> ---
> driv
Mauro,
Excuse me - I put my brain in backwards today and sent you a reverse diff by
accident! Reresending...
This fixes the deadlock that occurs with either multiple PCTV 290e adapters or
when a single PCTV 290e adap
Mauro,
Pending the complete rethink about how USB devices manage their resources, I am
resubmitting my fix for the PCTV 290e deadlock that occurs with either multiple
adapters or when an adapter is replugged.
For DVB devices, the device lock must now *not* be held when adding/removing
either
On 9/24/11 12:06 AM, Antti Palosaari wrote:
On 09/24/2011 12:06 AM, Jin Kazama wrote:
Hello,
I've been testing af9015/tda18218 based usb DVB-T tuners on a 2.6.39.4
kernel with the latest v4l drivers avaiable (from git).
When I'm using a single USB module, (listed as /dev/dvb/adapter0),
everythin
On Sat, Sep 24, 2011 at 6:04 PM, Mauro Carvalho Chehab
wrote:
> Everything at patchwork were reviewed by me, and I've applied all patches
> that I didn't notice any review by the drivers maintainers.
>
> Driver maintainers:
> Please review the remaining patches.
>
> == Patches for M
On Sat, Sep 24, 2011 at 6:04 PM, Mauro Carvalho Chehab
wrote:
> Everything at patchwork were reviewed by me, and I've applied all patches
> that I didn't notice any review by the drivers maintainers.
>
> Driver maintainers:
> Please review the remaining patches.
>
> == Patches for M
On Sat, Sep 24, 2011 at 6:04 PM, Mauro Carvalho Chehab
wrote:
> Everything at patchwork were reviewed by me, and I've applied all patches
> that I didn't notice any review by the drivers maintainers.
>
> Driver maintainers:
> Please review the remaining patches.
>
> == Patches for M
On Sat, Sep 24, 2011 at 6:04 PM, Mauro Carvalho Chehab
wrote:
> Everything at patchwork were reviewed by me, and I've applied all patches
> that I didn't notice any review by the drivers maintainers.
>
> Driver maintainers:
> Please review the remaining patches.
>
> == Patches for M
On Sat, Sep 24, 2011 at 6:04 PM, Mauro Carvalho Chehab
wrote:
> Everything at patchwork were reviewed by me, and I've applied all patches
> that I didn't notice any review by the drivers maintainers.
>
> Driver maintainers:
> Please review the remaining patches.
>
> == Patches for M
On Sat, Sep 24, 2011 at 6:04 PM, Mauro Carvalho Chehab
wrote:
> Everything at patchwork were reviewed by me, and I've applied all patches
> that I didn't notice any review by the drivers maintainers.
>
> Driver maintainers:
> Please review the remaining patches.
>
> == Patches for M
On Sat, Sep 24, 2011 at 6:04 PM, Mauro Carvalho Chehab
wrote:
> Everything at patchwork were reviewed by me, and I've applied all patches
> that I didn't notice any review by the drivers maintainers.
>
> Driver maintainers:
> Please review the remaining patches.
>
> == Patches for M
Hello Srinivasa,
Le Fri, 23 Sep 2011 05:26:07 -0700,
"Sri Deevi" a écrit :
> Do you have USB Analyzer (hardware) ? If so, Is it possible to take a
> trace and compare it with x86 trace to see for any obvious
> differences ?
Unfortunately, I don't have an hardware USB analyzer to do such a
compa
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 Sep 24 19:00:17 CEST 2011
git hash:d7222e7d6fb06ca3e7aa7a1ab07f8e6c6adb1d22
gcc version: i686-linux-gcc (GC
On Sat, 2011-09-24 at 09:39 -0400, Andy Walls wrote:
> On Sat, 2011-09-24 at 09:16 -0400, Andy Walls wrote:
> > On Fri, 2011-09-23 at 20:43 -0300, Mauro Carvalho Chehab wrote:
> > > Em 19-09-2011 08:12, Lawrence Rust escreveu:
> > > > The current decoder for the RC6 IR protocol supports mode 0 (16
On 09/22/2011 12:09 AM, Mauro Carvalho Chehab wrote:
> Em 21-09-2011 18:09, Sylwester Nawrocki escreveu:
>> Hi Mauro,
>>
>
> Updated accordingly, thanks!
>
>>> Sep,19 2011: [GIT,PATCHES,FOR,3.2] noon010pc30 conversion to the pad level
>>> ops http://patchwork.linuxtv.org/patch/7877 Sylwes
24.09.2011 19:09, Mauro Carvalho Chehab wrote:
If someone is using the board on an environment
without udev and pulseaudio, this trick will break the first tuning.
I feel this somehow contradicts with your suggestion
to remove the first scan, so could you clarify?
What I meant to say is that bo
- Original Message -
>> BTW, did you implement a different solution for the DVB module trying to
>> retake the dev->lock mutex?
>> Because it looks as if both em28xx_dvb_init() and em28xx_usb_probe() are
>> still calling mutex_lock().
> No, I didn't find any time to look into it. Too mu
Em 24-09-2011 11:52, Andy Walls escreveu:
> On Sat, 2011-09-24 at 09:34 -0300, Mauro Carvalho Chehab wrote:
>> Everything at patchwork were reviewed by me, and I've applied all patches
>> that I didn't notice any review by the drivers maintainers.
>>
>> Driver maintainers:
>> Please review the rema
Em 24-09-2011 11:54, Chris Rankin escreveu:
> Mauro,
>
> I am resending the two patches for the em28xx driver which seem to have been
> missed for 3.2. The first one simply removes a stray bit
> operation on em28xx_devused, whereas the second tidies up the
> device/extension list handling.
This
Em 24-09-2011 10:20, Stas Sergeev escreveu:
> 24.09.2011 16:48, Mauro Carvalho Chehab wrote:
>> A first scan at driver's init can be removed, IMO.
> OK, that's the great news.
> Will write a new patch then.
OK.
>
>> There's nothing the driver can do if the hardware
>> missdetects a carrier. Dirt
This patch closes the race on the device and extension lists at USB disconnect
time. Previously, the device was removed from the device list during
em28xx_release_resources(), and then passed to the em28xx_close_extension()
function so that all extensions could run their fini() operations. Howev
This line was probably missed in the merge.
Signed-off-by: Chris Rankin
--- linux/drivers/media/video/em28xx/em28xx-cards.c.orig.0 2011-09-24 15:30:02.0 +0100
+++ linux/drivers/media/video/em28xx/em28xx-cards.c 2011-09-24 15:19:28.0 +0100
@@ -3114,7 +3114,6 @@
em28xx_err(DRI
Mauro,
I am resending the two patches for the em28xx driver which seem to have been
missed for 3.2. The first one simply removes a stray bit operation on
em28xx_devused, whereas the second tidies up the device/extension list handling.
It is possible that the first patch has been applied alrea
On Sat, 2011-09-24 at 09:34 -0300, Mauro Carvalho Chehab wrote:
> Everything at patchwork were reviewed by me, and I've applied all patches
> that I didn't notice any review by the drivers maintainers.
>
> Driver maintainers:
> Please review the remaining patches.
> == Patches for A
On Sat, 2011-09-24 at 09:16 -0400, Andy Walls wrote:
> On Fri, 2011-09-23 at 20:43 -0300, Mauro Carvalho Chehab wrote:
> > Em 19-09-2011 08:12, Lawrence Rust escreveu:
> > > The current decoder for the RC6 IR protocol supports mode 0 (16 bit) and
> > > mode 6A. In mode 6A the decoder supports eith
24.09.2011 16:48, Mauro Carvalho Chehab wrote:
A first scan at driver's init can be removed, IMO.
OK, that's the great news.
Will write a new patch then.
> There's nothing the driver can do if the hardware
> missdetects a carrier. Dirty tricks to try solving it
> are not good, as they'll do the
On Fri, 2011-09-23 at 20:43 -0300, Mauro Carvalho Chehab wrote:
> Em 19-09-2011 08:12, Lawrence Rust escreveu:
> > The current decoder for the RC6 IR protocol supports mode 0 (16 bit) and
> > mode 6A. In mode 6A the decoder supports either 32-bit data (for
> > Microsoft's MCE RC) or 24 bit.
> >
>
Em 24-09-2011 09:36, Stas Sergeev escreveu:
> 24.09.2011 16:12, Mauro Carvalho Chehab wrote:
>> The scan audio logic only enables multiple audio standard detection if the
>> userspace
>> application tells it to do.
> No: the _first_ scan is done on the driver init.
> It is a multi-standard one, an
Em 24-09-2011 09:33, Stas Sergeev escreveu:
> 24.09.2011 16:05, Mauro Carvalho Chehab wrote:
>>
>> Better to post it as a separate patch, and to simplify the code with:
>>
>> diff --git a/drivers/media/video/saa7134/saa7134-tvaudio.c
>> b/drivers/media/video/saa7134/saa7134-tvaudio.c
>> index 57e6
24.09.2011 16:12, Mauro Carvalho Chehab wrote:
The scan audio logic only enables multiple audio standard detection if the
userspace
application tells it to do.
No: the _first_ scan is done on the driver init.
It is a multi-standard one, and a long one, too.
Do we need it at all? It seems to me
Everything at patchwork were reviewed by me, and I've applied all patches
that I didn't notice any review by the drivers maintainers.
Driver maintainers:
Please review the remaining patches.
== Patches for Manu Abraham review ==
Jun,11 2010: stb0899: Removed an extra byte sent
24.09.2011 16:05, Mauro Carvalho Chehab wrote:
Better to post it as a separate patch, and to simplify the code with:
diff --git a/drivers/media/video/saa7134/saa7134-tvaudio.c
b/drivers/media/video/saa7134/saa7134-tvaudio.c
index 57e646b..a61ed1e 100644
--- a/drivers/media/video/saa7134/saa713
Em 24-09-2011 08:12, Stas Sergeev escreveu:
> 24.09.2011 14:57, Mauro Carvalho Chehab wrote:
>> Please, one patch per email. Patchwork (or any kernel maintainer script)
>> won't catch more than one patch per email. See:
> Sorry about that.
>
>> With respect to this patch:
>> http://patchwork.linux
Em 18-09-2011 12:18, Stas Sergeev escreveu:
> Hi Mauro, I've finally found the time (and an energy)
> to go look into the automute breakage.
> With the attached automute fix I no longer have
> any problems with pulseaudio.
> I also attached the patch that introduces an "std"
> option to limit the s
24.09.2011 14:57, Mauro Carvalho Chehab wrote:
Please, one patch per email. Patchwork (or any kernel maintainer script)
won't catch more than one patch per email. See:
Sorry about that.
With respect to this patch:
http://patchwork.linuxtv.org/patch/7941/
I don't see any sense on it. Video sta
Em 18-09-2011 12:18, Stas Sergeev escreveu:
> Hi Mauro, I've finally found the time (and an energy)
> to go look into the automute breakage.
> With the attached automute fix I no longer have
> any problems with pulseaudio.
> I also attached the patch that introduces an "std"
> option to limit the s
38 matches
Mail list logo
