[GIT PATCHES FOR 3.2] NetUP Dual DVB-T/C CI RF: fix card hardware revision detection and PID filter for second demux
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 RF: fix card hardware revision detect NetUP Dual DVB-T/C CI RF: connect hardware PID filtering for second demux/dvr drivers/media/video/cx23885/altera-ci.c | 48 ++- drivers/media/video/cx23885/altera-ci.h |2 +- drivers/media/video/cx23885/cx23885-cards.c |2 +- drivers/media/video/cx23885/cx23885-dvb.c |3 +- 4 files changed, 36 insertions(+), 19 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Media Build Git Master is Broke
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.txt Second error then is: File not found: ./../linux/drivers/staging/tm6000/Kconfig at ./scripts/make_kconfig.pl line 284, line 36. Im stumped as how to fix this, it almost seems this should be in the git or created automatically. Hope someone can help. Thanks. Scott -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap_vout: Add poll() support
> -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
> ---
> drivers/media/video/omap/omap_vout.c | 10 ++
> 1 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/media/video/omap/omap_vout.c
> b/drivers/media/video/omap/omap_vout.c
> index a1f3c0f..cfc1705 100644
> --- a/drivers/media/video/omap/omap_vout.c
> +++ b/drivers/media/video/omap/omap_vout.c
> @@ -1184,6 +1184,15 @@ static void omap_vout_buffer_release(struct
> videobuf_queue *q,
> /*
> * File operations
> */
> +static unsigned int omap_vout_poll(struct file *file,
> +struct poll_table_struct *wait)
> +{
> + struct omap_vout_device *vout = file->private_data;
> + struct videobuf_queue *q = &vout->vbq;
> +
> + return videobuf_poll_stream(file, q, wait);
> +}
> +
> static void omap_vout_vm_open(struct vm_area_struct *vma)
> {
> struct omap_vout_device *vout = vma->vm_private_data;
> @@ -2175,6 +2184,7 @@ static const struct v4l2_ioctl_ops vout_ioctl_ops =
> {
>
> static const struct v4l2_file_operations omap_vout_fops = {
> .owner = THIS_MODULE,
> + .poll = omap_vout_poll,
> .unlocked_ioctl = video_ioctl2,
> .mmap = omap_vout_mmap,
> .open = omap_vout_open,
Acked-By: Vaibhav Hiremath
Thanks,
Vaibhav
> --
> 1.7.3.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] EM28xx - fix deadlock when unplugging and replugging a DVB adapter
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 adapter is replugged.
For DVB devices, the device lock must now *not* be held when adding/removing
either a device or an extension to the respective lists. (Because
em28xx_init_dvb() will want to take the lock instead).
Conversely, for Audio-Only devices, the device lock *must* be held when
adding/removing either a device or an extension to the respective lists.
Signed-off-by: Chris Rankin
Cheers,
Chris
--- linux/drivers/media/video/em28xx/em28xx-cards.c.orig 2011-09-24 21:42:43.0 +0100
+++ linux/drivers/media/video/em28xx/em28xx-cards.c 2011-09-24 21:48:56.0 +0100
@@ -3005,7 +3005,9 @@
goto fail;
}
+ mutex_unlock(&dev->lock);
em28xx_init_extension(dev);
+ mutex_lock(&dev->lock);
/* Save some power by putting tuner to sleep */
v4l2_device_call_all(&dev->v4l2_dev, 0, core, s_power, 0);
@@ -3301,10 +3303,10 @@
em28xx_release_resources(dev);
}
- em28xx_close_extension(dev);
-
mutex_unlock(&dev->lock);
+ em28xx_close_extension(dev);
+
if (!dev->users) {
kfree(dev->alt_max_pkt_size);
kfree(dev);
[PATCH v2] EM28xx - fix deadlock when unplugging and replugging a DVB adapter
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 a device or an extension to the respective lists. (Because
em28xx_init_dvb() will want to take the lock instead).
Conversely, for Audio-Only devices, the device lock *must* be held when
adding/removing either a device or an extension to the respective lists.
Signed-off-by: Chris Rankin
Cheers,
Chris
--- linux/drivers/media/video/em28xx/em28xx-cards.c.orig 2011-09-24 21:25:01.0 +0100
+++ linux/drivers/media/video/em28xx/em28xx-cards.c 2011-09-24 21:37:42.0 +0100
@@ -3005,9 +3005,7 @@
goto fail;
}
- mutex_unlock(&dev->lock);
em28xx_init_extension(dev);
- mutex_lock(&dev->lock);
/* Save some power by putting tuner to sleep */
v4l2_device_call_all(&dev->v4l2_dev, 0, core, s_power, 0);
@@ -3303,10 +3301,10 @@
em28xx_release_resources(dev);
}
- mutex_unlock(&dev->lock);
-
em28xx_close_extension(dev);
+ mutex_unlock(&dev->lock);
+
if (!dev->users) {
kfree(dev->alt_max_pkt_size);
kfree(dev);
Re: af9015/tda18218: Multiples (separates) usb devices errors/conflicts
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), everything works fine. When I'm plugging another module, at first it looks like everything's ok (/dev/dvb/adapter1) and if I try to use this module while the adapter0 is not been used, it works - but if try to use both modules at the same time, I get garbage output on both cards (error: warning: discontinuity for PID... with dvblast on both cards. Does anyone have any idea on how to fix this problem? Feel free to fix it. I am too busy currently. Well, it looks like if I put 2 devices on different USB buses (on the same machine), they work fine, but if they're on the same USB bus, I get the problem... I think the driver may get raw data from the USB bus - and the way it identifies the device is not the proper way (I have 2 exactly identical devices) => when both devices send data, the driver catches all the data from the bus, which is a corrupt mix of both streams...) Unfortunately, I don't think that I'm capable of fixing the problem by myself, I don't even know which part of the driver to look for... if someone can give me a hint, I might *try* to *attempt* to fix it :)... -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Status of the patches under review at LMML (28 patches)
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 Manu Abraham review == > > Jun, 1 2011: stv090x: set status bits when there is no lock > http://patchwork.linuxtv.org/patch/6804 Guy Martin > Patch looks okay, but untested at my side. Acked-by: Manu Abraham -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Status of the patches under review at LMML (28 patches)
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 Manu Abraham review == > > May,24 2011: Fix the derot zig-zag to work with TT-USB2.0 TechnoTrend. > http://patchwork.linuxtv.org/patch/6777 Hans Petter Selasky > Patch doesn't make any sense. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Status of the patches under review at LMML (28 patches)
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 Manu Abraham review == > > Jun, 8 2011: Add remote control support for mantis > http://patchwork.linuxtv.org/patch/7217 Christoph Pinkl > Haven't tested this patch. Please hold on with this patch. Best Regards, Manu -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Status of the patches under review at LMML (28 patches)
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 Manu Abraham review == > > May,23 2011: Increase a timeout, so that bad scheduling does not > accidentially caus http://patchwork.linuxtv.org/patch/7178 Hans Petter > Selasky Haven't heard timeout issues recently though ... but still; Acked-by: Manu Abraham -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Status of the patches under review at LMML (28 patches)
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 Manu Abraham review == > > May,21 2011: Disable dynamic current limit for ttpci budget cards > http://patchwork.linuxtv.org/patch/6669 Guy Martin > Strictly, the patch is incorrect. - Dynamic Current Limiting is nothing but a PWM operation where Ton = 20mS, Toff = 900mS. In fact, DCL is much more preferred, since it can protect the Power tracks to the PCI slot in case the fuse on the card doesn't blow out. This *might* prove problematic with some DiSEqC switches. Only in such a case, it might be wise to disable DCL. But I haven't yet seen anyone complain on the same, otherwise incorrect DiSEqC commands ? Regards, Manu -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Status of the patches under review at LMML (28 patches)
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 Manu Abraham review == > > Aug, 7 2010: Refactor Mantis DMA transfer to deliver 16Kb TS data per > interrupt http://patchwork.linuxtv.org/patch/4104 Marko Ristola > I did test this patch. It doesn't bring in any side effects in general. It increases the latency, which it is expected. On some PCI-PCI chipset the patch makes the TS handling worser. But in other cases, it looks okay. Reviewed-by: Manu Abraham -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Status of the patches under review at LMML (28 patches)
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 Manu Abraham review == > > Jun,11 2010: stb0899: Removed an extra byte sent at init on DiSEqC bus > http://patchwork.linuxtv.org/patch/3639 Florent AUDEBERT > A single byte doesn't make much of a difference, but well it is still a difference. The DiSEqC has some known issues and has some tricky workarounds for different Silicon cuts. This patch *might* be good on some chips while have an adverse effect. But that said I have not tested this patch. If general users would like to have this patch and is proven good on different versions, I have no objection for this patch to go in. In which case; Acked-by: Manu Abraham -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx231xx: DMA problem on ARM
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 comparison. > I am actually confused why set interface fails in the > log. The device is very simple one with no firmware and is totally > controlled by hardware itself. So far we had never seen any issue, > though never tried with any other ARM based devices. Not sure if > anybody had tried already. Seems like nobody ever tried to use this device on an ARM platform, unfortunately. Regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: ERRORS
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 (GCC) 4.6.1 host hardware:x86_64 host os: 3.0-4.slh.3-amd64 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: ERRORS linux-2.6.33-i686: ERRORS linux-2.6.34-i686: ERRORS linux-2.6.35.3-i686: ERRORS linux-2.6.36-i686: ERRORS linux-2.6.37-i686: ERRORS linux-2.6.38.2-i686: ERRORS linux-2.6.39.1-i686: ERRORS linux-3.0-i686: ERRORS linux-3.1-rc1-i686: ERRORS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: ERRORS linux-2.6.33-x86_64: ERRORS linux-2.6.34-x86_64: ERRORS linux-2.6.35.3-x86_64: ERRORS linux-2.6.36-x86_64: ERRORS linux-2.6.37-x86_64: ERRORS linux-2.6.38.2-x86_64: ERRORS linux-2.6.39.1-x86_64: ERRORS linux-3.0-x86_64: ERRORS linux-3.1-rc1-x86_64: ERRORS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RC6 decoding
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 bit) and > > > > mode 6A. In mode 6A the decoder supports either 32-bit data (for > > > > Microsoft's MCE RC) or 24 bit. > > > > > > > > I would like to support a Sky/Sky+ standard RC which transmits RC6-6-20 > > > > i.e. 20 bit data. The transmitted frame format is identical to the 24 > > > > bit form so I'm curious as to what remotes transmit 24 bit data or was > > > > this an error and it should be 20? > > > > > > > > RC6-6-20 is explained here: > > > > http://www.guiott.com/wrc/RC6-6.html > > > > > > > > If 24-bit mode is in use, is there a way to select between 20 and 24 bit > > > > operation? > > > > > > You'll need to figure out a way to detect between them. It is probably not > > > hard to detect, and add support for both at the decider. > > > Maybe you can find something useful here: > > > http://www.sbprojects.com/knowledge/ir/rc6.php > > > > Lawrence: > > > > Some RC-6 explanations with more detail could be found here: > > > > http://slycontrol.ru/scr/kb/rc6.htm (dead; not in the Wayback machine :( ) > > I found where the above website moved: :) > > http://slydiman.narod.ru/scr/kb/rc6.htm > > -Andy > > > http://www.picbasic.nl/info_rc6_uk.htm > > > > You might also find this thread of interest for some history: > > http://www.spinics.net/lists/linux-input/msg07983.html > > > > The take away is that the data length is, in theory, OEM dependent for > > RC-6 Mode 6A, limited to a max of 24 bits (3 bytes) after a short > > customer code and 128 bits (16 bytes) after a long customer code. > > > > In that previous thread, I suggested it might be better to look for the > > signal free time of 6 RC6_UNITs to declare the end of reception, instead > > of a bit count. Maybe that is a way to deal with the current problem. Andy, Many thanks for the pointers - they confirm that the Sky RC is just using a shortened but permissible form of 24 bit. So your suggestion of looking for a stop sequence is probably the only/best way. In fact it would actually correct the current implementation which assumes a fixed length of 24 or 32 bits. If I wrote a patch that handles variable data lengths (up to 24 or 128 bits) would you be willing to review it? I can test with a Sky RC and I also have a MCEUSB RC on order which should hopefully arrive next week. So that should test the current 32-bit case. -- Lawrence -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Patches at patchwork.linuxtv.org (127 patches)
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 Sylwester >>> Nawrocki >> not really a patch > > This patchwork version is capable of getting git pull requests, when > generated with git request-pull. > > I'm planning to change my scripts to recognize those requests and use it. > An unique queue helps me to apply patches at the arrival order. All right, that's a cool improvement. Everything is on the (public) record now, in easy searchable database. I'd like to thank you for the huge effort on your side to create the backup process and re-reviewing all the patches again. -- Regards, Sylwester -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch][saa7134] do not change mute state for capturing audio
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 both udev and pulseaudio opens the device, and these might initialize the audio thread. The driver should be able to work the same way with or without the first open by udev/pulseaudio. But the first scan I was referring to, and am going to remove, happens not on the device open, but on the driver init (modprobe time). open()s are safe, fortunately. The autounmute is not a hack. It is a logic to suppress audio when the audio carrier is not detected. It should not be removed. You are confusing the automute and autoUNmute. Autounmute is a must-die hack, and we only need to fix mplayer first. Automute just needs a fix. Though I'd personally remove the automute too, by exporting some interface for an app to query the signal strength... but that's another story. :) I'm not sure if it is safe to make mplayer to use the audio mixer. Why, if otherwise it already uses alsa in our case? The mixer control is just another part of an alsa interface, and it is already exported to the v4l apps, so... It is probably a good idea doing that, as it will also work fine with webcams that provide alsa inputs. And will make pulseaudio happy, that's for sure. :) -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] EM28xx patches for 3.2
- 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 much work here... OK, then I'd probably better resubmit my final patch as well then. Cheers, Chris -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Status of the patches under review at LMML (28 patches)
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 remaining patches. > >> == Patches for Andy Walls > > review == >> >> May,25 2011: ivtv: use display information in info not in var for panning >>http://patchwork.linuxtv.org/patch/6706 Laurent Pinchart >> > > You committed this one from one of my pull requests. The subject line > changed a little (ivtv: -> ivtvfb:) > > http://www.gossamer-threads.com/lists/ivtv/devel/41425 > http://git.linuxtv.org/media_tree.git?a=commitdiff;h=5d9c08dea0c13c09408f97fe61d34c198c4f3277 > http://lkml.org/lkml/2011/6/7/311 Ok. Patch updated. > >> == Waiting for Andy Walls >> double-check == >> >> Dec,19 2010: [RESEND, for, 2.6.37] cx23885, cx25840: Provide IR Rx timeout >> event re http://patchwork.linuxtv.org/patch/5133 Andy Walls >> > > By inspection, this one is still OK. It is still relevant and looks > like it still should apply cleanly. I have not compile tested it > recently. Thanks! Applied. > > >> == waiting for Michael Krufky review == >> >> Sep, 4 2011: Medion 95700 analog video support >>http://patchwork.linuxtv.org/patch/7767 Maciej Szmigiero >> > > I need to comment on the cx25840 portion of this patch. I plan to make > time to do that in a few hours. Thank you! Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] EM28xx patches for 3.2
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 one were already applied. Just applied the second one. > > It is possible that the first patch has been applied already. However, I > cannot be sure because I cannot find a URL anywhere that will show me the > current "HEAD" of the "pending for 3.2" tree. http://git.linuxtv.org/media_tree.git/shortlog/refs/heads/staging/for_v3.2 > 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 much work here... Regards, Mauro > > Cheers, > Chris -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch][saa7134] do not change mute state for capturing audio
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. Dirty tricks to try solving it >> are not good, as they'll do the wrong thing on some situations. > Well, if we assume the first scan can be removed, > then we also assume the previous "dirty trick" is > harmless, as it affects only the first scan. But I'll > better remove both the trick and the first scan then, > as the fewer the hacks, the better the code. Yes. >> 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 both udev and pulseaudio opens the device, and these might initialize the audio thread. The driver should be able to work the same way with or without the first open by udev/pulseaudio. >> Well, if you think that this would solve, then just write a patch >> exporting the mute control via ALSA. I have no problems with that. > That would solve all the problems, but only if: > 1. The mplayer is then moved to the use of that new > control to not depend on the autounmute hack. > I can write the patch for that too. The autounmute is not a hack. It is a logic to suppress audio when the audio carrier is not detected. It should not be removed. I'm not sure if it is safe to make mplayer to use the audio mixer. It is probably a good idea doing that, as it will also work fine with webcams that provide alsa inputs. > 2. Make sure all the other apps are fixed the same way > (I hope there are none though) > 3. The autounmute hack is then removed. (no > regressions if steps 1 and 2 are carefully done) > > If you are fine with that plan, then I'll try to find > the time and do the things that way. Otherwise, > I'll remove the first scan, and that will do the trick > in a simpler, though less cleaner way. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] EM28xx - fix race on disconnect
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. However, this
left a (brief, theoretical, highly unlikely ;-)) window between these two calls
during which a new module could call em28xx_register_extension(). The result
would have been that the em28xx_usb_disconnect() function would also have passed
the device to the new extension's fini() function, despite never having called
the extension's init() function.
This patch also restores em28xx_close_extension()'s symmetry with
em28xx_init_extension(), and establishes the property that every device in the
device list must have been initialised for every extension in the extension list.
Signed-off-by: Chris Rankin
--- linux/drivers/media/video/em28xx/em28xx-core.c.orig 2011-09-24 14:56:05.0 +0100
+++ linux/drivers/media/video/em28xx/em28xx-core.c 2011-09-24 15:01:23.0 +0100
@@ -1184,18 +1184,6 @@
static DEFINE_MUTEX(em28xx_devlist_mutex);
/*
- * em28xx_realease_resources()
- * unregisters the v4l2,i2c and usb devices
- * called when the device gets disconected or at module unload
-*/
-void em28xx_remove_from_devlist(struct em28xx *dev)
-{
- mutex_lock(&em28xx_devlist_mutex);
- list_del(&dev->devlist);
- mutex_unlock(&em28xx_devlist_mutex);
-};
-
-/*
* Extension interface
*/
@@ -1245,14 +1233,13 @@
void em28xx_close_extension(struct em28xx *dev)
{
- struct em28xx_ops *ops = NULL;
+ const struct em28xx_ops *ops = NULL;
mutex_lock(&em28xx_devlist_mutex);
- if (!list_empty(&em28xx_extension_devlist)) {
- list_for_each_entry(ops, &em28xx_extension_devlist, next) {
- if (ops->fini)
-ops->fini(dev);
- }
+ list_for_each_entry(ops, &em28xx_extension_devlist, next) {
+ if (ops->fini)
+ ops->fini(dev);
}
+ list_del(&dev->devlist);
mutex_unlock(&em28xx_devlist_mutex);
}
--- linux/drivers/media/video/em28xx/em28xx-cards.c.orig 2011-09-24 15:19:28.0 +0100
+++ linux/drivers/media/video/em28xx/em28xx-cards.c 2011-09-24 15:19:33.0 +0100
@@ -2800,9 +2800,9 @@
#endif /* CONFIG_MODULES */
/*
- * em28xx_realease_resources()
+ * em28xx_release_resources()
* unregisters the v4l2,i2c and usb devices
- * called when the device gets disconected or at module unload
+ * called when the device gets disconnected or at module unload
*/
void em28xx_release_resources(struct em28xx *dev)
{
@@ -2816,8 +2816,6 @@
em28xx_release_analog_resources(dev);
- em28xx_remove_from_devlist(dev);
-
em28xx_i2c_unregister(dev);
v4l2_device_unregister(&dev->v4l2_dev);
@@ -3255,7 +3253,7 @@
/*
* em28xx_usb_disconnect()
- * called when the device gets diconencted
+ * called when the device gets disconnected
* video device will be unregistered on v4l2_close in case it is still open
*/
static void em28xx_usb_disconnect(struct usb_interface *interface)
[PATCH 1/2] use atomic bit operations for devices-in-use mask
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(DRIVER_NAME " This is an anciliary " "interface not used by the driver\n"); -em28xx_devused &= ~(1<
[PATCH 0/2] EM28xx patches for 3.2
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 already. However, I cannot be sure because I cannot find a URL anywhere that will show me the current "HEAD" of the "pending for 3.2" tree. 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(). Cheers, Chris -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Status of the patches under review at LMML (28 patches)
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 Andy Walls > review == > > May,25 2011: ivtv: use display information in info not in var for panning > http://patchwork.linuxtv.org/patch/6706 Laurent Pinchart > You committed this one from one of my pull requests. The subject line changed a little (ivtv: -> ivtvfb:) http://www.gossamer-threads.com/lists/ivtv/devel/41425 http://git.linuxtv.org/media_tree.git?a=commitdiff;h=5d9c08dea0c13c09408f97fe61d34c198c4f3277 http://lkml.org/lkml/2011/6/7/311 > == Waiting for Andy Walls > double-check == > > Dec,19 2010: [RESEND, for, 2.6.37] cx23885, cx25840: Provide IR Rx timeout > event re http://patchwork.linuxtv.org/patch/5133 Andy Walls > By inspection, this one is still OK. It is still relevant and looks like it still should apply cleanly. I have not compile tested it recently. > == waiting for Michael Krufky review == > > Sep, 4 2011: Medion 95700 analog video support > http://patchwork.linuxtv.org/patch/7767 Maciej Szmigiero I need to comment on the cx25840 portion of this patch. I plan to make time to do that in a few hours. Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RC6 decoding
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 either 32-bit data (for > > > Microsoft's MCE RC) or 24 bit. > > > > > > I would like to support a Sky/Sky+ standard RC which transmits RC6-6-20 > > > i.e. 20 bit data. The transmitted frame format is identical to the 24 > > > bit form so I'm curious as to what remotes transmit 24 bit data or was > > > this an error and it should be 20? > > > > > > RC6-6-20 is explained here: > > > http://www.guiott.com/wrc/RC6-6.html > > > > > > If 24-bit mode is in use, is there a way to select between 20 and 24 bit > > > operation? > > > > You'll need to figure out a way to detect between them. It is probably not > > hard to detect, and add support for both at the decider. > > Maybe you can find something useful here: > > http://www.sbprojects.com/knowledge/ir/rc6.php > > Lawrence: > > Some RC-6 explanations with more detail could be found here: > > http://slycontrol.ru/scr/kb/rc6.htm (dead; not in the Wayback machine :( ) I found where the above website moved: :) http://slydiman.narod.ru/scr/kb/rc6.htm -Andy > http://www.picbasic.nl/info_rc6_uk.htm > > You might also find this thread of interest for some history: > http://www.spinics.net/lists/linux-input/msg07983.html > > The take away is that the data length is, in theory, OEM dependent for > RC-6 Mode 6A, limited to a max of 24 bits (3 bytes) after a short > customer code and 128 bits (16 bytes) after a long customer code. > > In that previous thread, I suggested it might be better to look for the > signal free time of 6 RC6_UNITs to declare the end of reception, instead > of a bit count. Maybe that is a way to deal with the current problem. > > Regards, > Andy > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch][saa7134] do not change mute state for capturing audio
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 wrong thing on some situations. Well, if we assume the first scan can be removed, then we also assume the previous "dirty trick" is harmless, as it affects only the first scan. But I'll better remove both the trick and the first scan then, as the fewer the hacks, the better the code. > 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? > Well, if you think that this would solve, then just write a patch > exporting the mute control via ALSA. I have no problems with that. That would solve all the problems, but only if: 1. The mplayer is then moved to the use of that new control to not depend on the autounmute hack. I can write the patch for that too. 2. Make sure all the other apps are fixed the same way (I hope there are none though) 3. The autounmute hack is then removed. (no regressions if steps 1 and 2 are carefully done) If you are fine with that plan, then I'll try to find the time and do the things that way. Otherwise, I'll remove the first scan, and that will do the trick in a simpler, though less cleaner way. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RC6 decoding
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.
> >
> > I would like to support a Sky/Sky+ standard RC which transmits RC6-6-20
> > i.e. 20 bit data. The transmitted frame format is identical to the 24
> > bit form so I'm curious as to what remotes transmit 24 bit data or was
> > this an error and it should be 20?
> >
> > RC6-6-20 is explained here:
> > http://www.guiott.com/wrc/RC6-6.html
> >
> > If 24-bit mode is in use, is there a way to select between 20 and 24 bit
> > operation?
>
> You'll need to figure out a way to detect between them. It is probably not
> hard to detect, and add support for both at the decider.
> Maybe you can find something useful here:
> http://www.sbprojects.com/knowledge/ir/rc6.php
Lawrence:
Some RC-6 explanations with more detail could be found here:
http://slycontrol.ru/scr/kb/rc6.htm (dead; not in the Wayback machine :( )
http://www.picbasic.nl/info_rc6_uk.htm
You might also find this thread of interest for some history:
http://www.spinics.net/lists/linux-input/msg07983.html
The take away is that the data length is, in theory, OEM dependent for
RC-6 Mode 6A, limited to a max of 24 bits (3 bytes) after a short
customer code and 128 bits (16 bytes) after a long customer code.
In that previous thread, I suggested it might be better to look for the
signal free time of 6 RC6_UNITs to declare the end of reception, instead
of a bit count. Maybe that is a way to deal with the current problem.
Regards,
Andy
> >
> > I made the following simple mod to ir-rc6-decoder.c and my Sky/Sky+ RCs
> > decode correctly (with a custom keytable):
> >
> > --- a/drivers/media/rc/ir-rc6-decoder.c 2011-05-19 06:06:34.0
> > +0200
> > +++ b/drivers/media/rc/ir-rc6-decoder.c 2011-09-19 13:02:35.0
> > +0200
> > @@ -17,14 +17,14 @@
> > /*
> > * This decoder currently supports:
> > * RC6-0-16(standard toggle bit in header)
> > - * RC6-6A-24 (no toggle bit)
> > + * RC6-6A-20 (no toggle bit)
> > * RC6-6A-32 (MCE version with toggle bit in body)
> > */
> >
> > #define RC6_UNIT 44 /* us */
> > #define RC6_HEADER_NBITS 4 /* not including toggle bit */
> > #define RC6_0_NBITS16
> > -#define RC6_6A_SMALL_NBITS 24
> > +#define RC6_6A_SMALL_NBITS 20
> > #define RC6_6A_LARGE_NBITS 32
> > #define RC6_PREFIX_PULSE (6 * RC6_UNIT)
> > #define RC6_PREFIX_SPACE (2 * RC6_UNIT)
> > @@ -231,7 +231,7 @@ again:
> > scancode = data->body & ~RC6_6A_MCE_TOGGLE_MASK;
> > } else {
> > toggle = 0;
> > - scancode = data->body & 0xff;
> > + scancode = data->body;
> > }
> >
> > IR_dprintk(1, "RC6(6A) scancode 0x%08x (toggle: %u)\n",
> >
> >
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch][saa7134] do not change mute state for capturing audio
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, and a long one, too. > Do we need it at all? It seems to me the results > of that scan are not even used, or what am I > missing? A first scan at driver's init can be removed, IMO. The thing is that newer versions of udev will open the device, to do a VIDIOC_QUERYCAP. Not sure if this will wake up the tvaudio kthread to do a scan. Regards, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch][saa7134] do not change mute state for capturing audio
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 57e646b..a61ed1e 100644
>> --- a/drivers/media/video/saa7134/saa7134-tvaudio.c
>> +++ b/drivers/media/video/saa7134/saa7134-tvaudio.c
>> @@ -332,6 +332,12 @@ static int tvaudio_checkcarrier(struct saa7134_dev
>> *dev, struct mainscan *scan)
>> {
>> __s32 left,right,value;
>>
>> +if (!dev->tvnorm->id& scan->std)) {
> Missing open bracket?
Yes. patch were of course not tested ;)
I meant to say:
if (!(dev->tvnorm->id & scan->std)) {
>
>>> @@ -546,6 +546,7 @@ static int tvaudio_thread(void *data)
>>> dev->tvnorm->name, carrier/1000, carrier%1000,
>>> max1, max2);
>>> dev->last_carrier = carrier;
>>> +dev->automute = !(dev->thread.scan1> 1);
>> Why?
> Unfortunately, that's the trick. :(
>
>>
>> If the carrier is good, this should be enough:
>>
>> dev->automute = 0;
> Unfortunately, sometimes it misdetects.
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 wrong
thing on some situations.
> Testing dev->thread.scan1 means that at least
> the first scan, done on the driver init, won't
> unmute.
> So either that, or this whole patch is unhelpful.
> I realize that this is a dirty hack, yes.
This is a dirty hack, and it assumes that the first scan
should be discarded. This is true only on certain environments.
If someone is using the board on an environment without udev and
pulseaudio, this trick will break the first tuning.
>> The rest looked sane on my eyes, but I didn't double-checked it by running
>> on my cards. Had you test calling it with just a single standard, and with a
>> multiple standards mask?
> With just a single standard. That's the problem too.
> There are the fallbacks, like last_carrier etc, and do we
> need to unmute there or not? :(
>
>> The right fix that pulseaudio should not touch at the audio mixers for the
>> video boards.
> That's where we disagree.
> I wonder what other people think.
> I don't see the compelling reason for making the
> alsa interface to the v4l devs a special case. If there
> is just a mute control exported, there is no more a special
> case, and no more hacks and problems.
>
>> Not all boards have an audio carrier detection like saa7134.
> Having the mute control exported would make this
> not a problem.
Well, if you think that this would solve, then just write a patch
exporting the mute control via ALSA. I have no problems with that.
Regards,
Mauro.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch][saa7134] do not change mute state for capturing audio
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 the results of that scan are not even used, or what am I missing? -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Status of the patches under review at LMML (28 patches)
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 at init on DiSEqC bus
http://patchwork.linuxtv.org/patch/3639 Florent AUDEBERT
Aug, 7 2010: Refactor Mantis DMA transfer to deliver 16Kb TS data per interrupt
http://patchwork.linuxtv.org/patch/4104 Marko Ristola
May,21 2011: Disable dynamic current limit for ttpci budget cards
http://patchwork.linuxtv.org/patch/6669 Guy Martin
May,23 2011: Increase a timeout, so that bad scheduling does not accidentially
caus http://patchwork.linuxtv.org/patch/7178 Hans Petter Selasky
Jun, 8 2011: Add remote control support for mantis
http://patchwork.linuxtv.org/patch/7217 Christoph Pinkl
May,24 2011: Fix the derot zig-zag to work with TT-USB2.0 TechnoTrend.
http://patchwork.linuxtv.org/patch/6777 Hans Petter Selasky
Jun, 1 2011: stv090x: set status bits when there is no lock
http://patchwork.linuxtv.org/patch/6804 Guy Martin
== Patches for Dmitri Belimov review ==
Apr,23 2009: FM1216ME_MK3 AUX byte for FM mode
http://patchwork.linuxtv.org/patch/764Dmitri Belimov
== Patches waiting for Morimoto
Kuninori check ==
Feb, 2 2010: [2/3] soc-camera: mt9t112: modify delay time after initialize
http://patchwork.linuxtv.org/patch/2553 Kuninori Morimoto
== Patches waiting Mauro Carvalho Chehab
tests with mb86a20s/ISDB-T ==
May,19 2011: saa7134-dvb.c kworld_sbtvd
http://patchwork.linuxtv.org/patch/6649 Manoel PN
== Patches waiting for Hans de Goede
review ==
Jun, 4 2011: Increase max exposure value to 255 from 26.
http://patchwork.linuxtv.org/patch/6850 Marco Diego Aurélio Mesquita
== Patches waiting for Laurent Pinchart
review ==
Jun,22 2011: Improve UVC buffering with regard to USB. Add checks to avoid
division http://patchwork.linuxtv.org/patch/7290 Hans Petter Selasky
Jul,11 2011: Error routes through omap3isp ccdc.
http://patchwork.linuxtv.org/patch/7428 Jonathan Cameron
Jul,14 2011: uvcvideo: add fix suspend/resume quirk for Microdia camera
http://patchwork.linuxtv.org/patch/186Ming Lei
Jul,13 2011: [RFC, v1] mt9v113: VGA camera sensor driver and support for
BeagleBoar http://patchwork.linuxtv.org/patch/184Joel A Fernandes
Sep, 6 2011: mt9p031: Do not use PLL if external frequency is the same as
target fr http://patchwork.linuxtv.org/patch/7783 Javier Martin
== Patches for Andy Walls > review ==
May,25 2011: ivtv: use display information in info not in var for panning
http://patchwork.linuxtv.org/patch/6706 Laurent Pinchart
== Waiting for Andy Walls
double-check ==
Dec,19 2010: [RESEND, for, 2.6.37] cx23885, cx25840: Provide IR Rx timeout
event re http://patchwork.linuxtv.org/patch/5133 Andy Walls
== Waiting for Jarod Wilson review ==
Apr,28 2011: [10/10] rc-core: move timeout and checks to lirc
http://patchwork.linuxtv.org/patch/6468 David Härdeman
== Waiting for Pawel Osiak review ==
Jul,12 2011: v4l: mem2mem: add wait_{prepare,finish} ops to m2m_testdev
http://patchwork.linuxtv.org/patch/7431 Michael Olbrich
== waiting for Michael Krufky review ==
Sep, 4 2011: Medion 95700 analog video support
http://patchwork.linuxtv.org/patch/7767 Maciej Szmigiero
== Patches waiting for Guennadi Liakhovetski
review ==
Sep,19 2011: [1/4,v2,FOR,3.1] v4l2: add vb2_get_unmapped_area in vb2 core
http://patchwork.linuxtv.org/patch/7870 Scott Jiang
Sep,19 2011: [2/4,v2,FOR,3.1] v4l2: add adv7183 decoder driver
http://patchwork.linuxtv.org/patch/7872 Scott Jiang
Sep,19 2011: [3/4,v2,FOR,3.1] v4l2: add vs6624 sensor driver
http://patchwork.linuxtv.org/patch/7871 Scott Jiang
Sep,19 2011: [4/4,v2,FOR,3.1] v4l2: add blackfin capture bridge driver
http://patchwork.linuxtv.org/patch/7869 Scott Jiang
Sep,22 2011: [v3,1/2,media] Add code to enable/disable ISI_MCK clock.
http://patchwork.linuxtv.org/patch/7917 Josh Wu
Sep,22 2011: [v3, 2/2] at91: add Atmel ISI and ov2640 support on
sam9m10/sam9g45 bo http://patchwork.linuxtv.org/patch/7918 Josh Wu
== waiting for Eddi De Pieri feedback ==
Sep,23 2011: [v2] xc5000: Add support for get_if_frequency
Re: [patch][saa7134] do not change mute state for capturing audio
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/saa7134-tvaudio.c
+++ b/drivers/media/video/saa7134/saa7134-tvaudio.c
@@ -332,6 +332,12 @@ static int tvaudio_checkcarrier(struct saa7134_dev *dev,
struct mainscan *scan)
{
__s32 left,right,value;
+ if (!dev->tvnorm->id& scan->std)) {
Missing open bracket?
@@ -546,6 +546,7 @@ static int tvaudio_thread(void *data)
dev->tvnorm->name, carrier/1000, carrier%1000,
max1, max2);
dev->last_carrier = carrier;
+ dev->automute = !(dev->thread.scan1> 1);
Why?
Unfortunately, that's the trick. :(
If the carrier is good, this should be enough:
dev->automute = 0;
Unfortunately, sometimes it misdetects.
Testing dev->thread.scan1 means that at least
the first scan, done on the driver init, won't
unmute.
So either that, or this whole patch is unhelpful.
I realize that this is a dirty hack, yes.
The rest looked sane on my eyes, but I didn't double-checked it by
running on my cards. Had you test calling it with just a single
standard, and with a multiple standards mask?
With just a single standard. That's the problem too.
There are the fallbacks, like last_carrier etc, and do we
need to unmute there or not? :(
> The right fix that pulseaudio should not touch at the audio mixers
for the video boards.
That's where we disagree.
I wonder what other people think.
I don't see the compelling reason for making the
alsa interface to the v4l devs a special case. If there
is just a mute control exported, there is no more a special
case, and no more hacks and problems.
> Not all boards have an audio carrier detection like saa7134.
Having the mute control exported would make this
not a problem.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch][saa7134] do not change mute state for capturing audio
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.linuxtv.org/patch/7941/ >> >> I don't see any sense on it. Video standard selection is done by software, >> when a standards mask is passed via VIDIOC_S_STD ioctl. Drivers should not >> mess it with modprobe hacks. > Yes, but we already have "secam=" option, and > also the first scan, that is being done on driver > init, scans too much without that option, and > sometimes, unfortunately, detects the PAL carrier > for me. > By limiting it to secam, I avoid the problem and > shorten the scan time. > But this patch is not very important, so do whatever > you think necessary with it. The scan audio logic only enables multiple audio standard detection if the userspace application tells it to do. The right fix here is to fix the application. The secam hack is due to a problem related to Secam L and Secam L'. > >> I'll comment later http://patchwork.linuxtv.org/patch/7940/. It seems to be >> going into the right direction, but I need to take a deeper code inspection >> and maybe do some tests here. > Thanks! > Of course, in my view, the _only_ right direction is > to export the mute control to the alsa mixer and then > fix mplayer. But at least I'm glad I've managed to > find the hack that satisfies your opinion and works > around the problem at the same time. The right fix that pulseaudio should not touch at the audio mixers for the video boards. Not all boards have an audio carrier detection like saa7134. Regards, Mauro. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch][saa7134] do not change mute state for capturing audio
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 scan list, resulting in a faster scan.
> It is completely unrelated to the automute one, it is
> here just in case.
> What do you think?
>
> Content-Type: text/plain; charset="utf-8"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Subject: [1/2,saa7134] do not change mute state for capturing audio
> Date: Sun, 18 Sep 2011 14:18:34 -
> From: Stas Sergeev
> X-Patchwork-Id: 7940
> Message-Id: <4e760bca.6080900-pat...@list.ru>
> To: Mauro Carvalho Chehab
> Cc: linux-media@vger.kernel.org, "Nickolay V. Shmyrev" ,
> Lennart Poettering ,
> ALSA devel
>
> 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 scan list, resulting in a faster scan.
> It is completely unrelated to the automute one, it is
> here just in case.
> What do you think?
>
>
> >From ccdfa126e98b5484f4a08de591ac8d89f775251c Mon Sep 17 00:00:00 2001
> From: Stas Sergeev
> Date: Sun, 18 Sep 2011 19:06:21 +0400
> Subject: [PATCH 1/2] saa7134: fix automute
>
> ---
> drivers/media/video/saa7134/saa7134-tvaudio.c |7 +--
> 1 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/video/saa7134/saa7134-tvaudio.c
> b/drivers/media/video/saa7134/saa7134-tvaudio.c
> index 57e646b..62a6287 100644
> --- a/drivers/media/video/saa7134/saa7134-tvaudio.c
> +++ b/drivers/media/video/saa7134/saa7134-tvaudio.c
> @@ -332,7 +332,7 @@ static int tvaudio_checkcarrier(struct saa7134_dev *dev,
> struct mainscan *scan)
> {
> __s32 left,right,value;
>
> - if (audio_debug > 1) {
> + if (audio_debug > 1 && (dev->tvnorm->id & scan->std)) {
> int i;
> dprintk("debug %d:",scan->carr);
> for (i = -150; i <= 150; i += 30) {
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/saa7134-tvaudio.c
+++ b/drivers/media/video/saa7134/saa7134-tvaudio.c
@@ -332,6 +332,12 @@ static int tvaudio_checkcarrier(struct saa7134_dev *dev,
struct mainscan *scan)
{
__s32 left,right,value;
+ if (!dev->tvnorm->id & scan->std)) {
+ dprintk("skipping %d.%03d MHz [%4s]\n",
+ scan->carr / 1000, scan->carr % 1000, scan->name);
+ return 0;
+ }
+
if (audio_debug > 1) {
int i;
dprintk("debug %d:",scan->carr);
@@ -348,30 +354,25 @@ static int tvaudio_checkcarrier(struct saa7134_dev *dev,
struct mainscan *scan)
}
printk("\n");
}
- if (dev->tvnorm->id & scan->std) {
- tvaudio_setcarrier(dev,scan->carr-90,scan->carr-90);
- saa_readl(SAA7134_LEVEL_READOUT1 >> 2);
- if (tvaudio_sleep(dev,SCAN_SAMPLE_DELAY))
- return -1;
- left = saa_readl(SAA7134_LEVEL_READOUT1 >> 2);
-
- tvaudio_setcarrier(dev,scan->carr+90,scan->carr+90);
- saa_readl(SAA7134_LEVEL_READOUT1 >> 2);
- if (tvaudio_sleep(dev,SCAN_SAMPLE_DELAY))
- return -1;
- right = saa_readl(SAA7134_LEVEL_READOUT1 >> 2);
-
- left >>= 16;
- right >>= 16;
- value = left > right ? left - right : right - left;
- dprintk("scanning %d.%03d MHz [%4s] => dc is %5d [%d/%d]\n",
- scan->carr / 1000, scan->carr % 1000,
- scan->name, value, left, right);
- } else {
- value = 0;
- dprintk("skipping %d.%03d MHz [%4s]\n",
- scan->carr / 1000, scan->carr % 1000, scan->name);
- }
+ tvaudio_setcarrier(dev,scan->carr-90,scan->carr-90);
+ saa_readl(SAA7134_LEVEL_READOUT1 >> 2);
+ if (tvaudio_sleep(dev,SCAN_SAMPLE_DELAY))
+ return -1;
+ left = saa_readl(SAA7134_LEVEL_READOUT1 >> 2);
+
+ tvaudio_setcarrier(dev,scan->carr+90,scan->carr+90);
+ saa_readl(SAA7134_LEVEL_READOUT1 >> 2);
+ if (tvaudio_sleep(dev,SCAN_SAMPLE_DELAY))
+ return -1;
+ right = saa_readl(SAA7134_LEVEL_READOUT1 >> 2);
+
+ left >>= 16;
+ right >>= 16;
+ value = left > right ? left - right : right - left;
+ dprintk("scanning %d.%03d MHz [%4s] => dc is %5d [%d/%d]\n",
+ scan->carr / 1000, scan->carr % 1000,
+ scan->name, va
Re: [patch][saa7134] do not change mute state for capturing audio
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 standard selection is done by software, when a standards mask is passed via VIDIOC_S_STD ioctl. Drivers should not mess it with modprobe hacks. Yes, but we already have "secam=" option, and also the first scan, that is being done on driver init, scans too much without that option, and sometimes, unfortunately, detects the PAL carrier for me. By limiting it to secam, I avoid the problem and shorten the scan time. But this patch is not very important, so do whatever you think necessary with it. I'll comment later http://patchwork.linuxtv.org/patch/7940/. It seems to be going into the right direction, but I need to take a deeper code inspection and maybe do some tests here. Thanks! Of course, in my view, the _only_ right direction is to export the mute control to the alsa mixer and then fix mplayer. But at least I'm glad I've managed to find the hack that satisfies your opinion and works around the problem at the same time. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch][saa7134] do not change mute state for capturing audio
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 scan list, resulting in a faster scan. > It is completely unrelated to the automute one, it is > here just in case. > What do you think? Please, one patch per email. Patchwork (or any kernel maintainer script) won't catch more than one patch per email. See: http://patchwork.linuxtv.org/patch/7862/ As those are the two last patches marked as new at patchwork, I've manually uploaded it as two separate emails, in order to allow me to queue them: http://patchwork.linuxtv.org/patch/7940/ http://patchwork.linuxtv.org/patch/7941/ With respect to this patch: http://patchwork.linuxtv.org/patch/7941/ I don't see any sense on it. Video standard selection is done by software, when a standards mask is passed via VIDIOC_S_STD ioctl. Drivers should not mess it with modprobe hacks. I'll comment later http://patchwork.linuxtv.org/patch/7940/. It seems to be going into the right direction, but I need to take a deeper code inspection and maybe do some tests here. Regards, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
