Re: [patch][saa7134] do not change mute state for capturing audio
14.07.2011 02:00, Mauro Carvalho Chehab wrote: Now that we don't have the output mute switch, we allow the alsa driver to unmute not only the recording that it may need, but also the sound output that goes to the sound card! IMHO, this is the entirely unwanted side effect, so I blame the saa driver, and not the pulseaudio. Why this is unwanted? You shouldn't expect that the poor users to control each mute control. They just need to control one: the sound card outut. Controlling the sound card output makes no sense here: I don't want to mute the entire sound only when I want to mute the TV-tuner. On the other hand, why exactly would you unmute the output when capturing? Obviously to allow the capturing itself. Why, at the same time, would you enable the pass-through link to the sound card? Unwanted side-effect: it is not needed for capturing, and it gives the noise. That have to be fixed. So: even if pulseaudio wants to record the white noise for one reason or another, at least it doesn't output it to the sound card, so what it does is perfectly safe. Enabling the pass-through link to the sound card is a bug here. There are also other things to consider: 1. You can't record anything (except for the white noise) before some xawtv sets up everything. So what is the use-case of the current (mis)behaveur? So is there a use-case? If you're getting a white noise, then there's a bug either at xawtv, at the driver or both. It is likely board-specific, as, at least the last time I tested, saa7134 audio were working properly. I don't see your point, I described the bug precisely. The capture unmutes the pass-through link to the sound card, so whatever is captured (white noise), gets also immediately outputed to the speakers, even though pulseaudio does not feed that to the sound card. As I said before, the white noise bug should be fixed. With what xawtv versions are you noticing problems? Are you using xawtv 3.101? If so, xawtv 3.101 assumes that you're using digital There is nothing to do with xawtv here: as I said, the noise happens on xorg startup. Starting xawtv actually makes it to disappear, but I can't always start xawtv just for that. -- 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 1/9] stringify: add HEX_STRING()
Hi, On Wed, Jul 13, 2011 at 6:17 PM, Randy Dunlap wrote: > [...] >> > Sure, go for it. I'll ack it. ;) [or Review it :] >> > and test it. >> > >> it is already among the hunks in https://patchwork.kernel.org/patch/380601/ > > I realize that, but it looks like you may need to resubmit it. > I have an updated set of patches against -next, I still need to break them down by tree. As a lots of things I did today went completely south, I guess it would be better if I do this task early tomorrow :-) - Arnaud -- 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: Imon module Oops and kernel hang
On 14/07/11 08:11, Jarod Wilson wrote: > On Jul 13, 2011, at 1:42 AM, Chris W wrote: > Just noticed your report is for 2.6.39.x and 2.6.38.x only, but I'm > not aware of any relevant imon changes between 2.6.39 and 3.0. I just tried 3.0.0-rc7 with the same result (used defaults for new config items. I manually loaded both keymaps before imon. I looks like the mystery T889 has become a T886... compiler generated temporary name perhaps? > Looks like I'll probably have to give that a spin, since I'm not > seeing the problem here (I can also switch to an 0xffdc device, which > is actually handled a bit differently by the driver). I understand that the 0xffdc device covers a multitude of physical variants. Is there any information from the device itself that drives the selected keymap? If so, how do I extract it? Regards, Chris Jul 14 11:19:38 kepler BUG: unable to handle kernel Jul 14 11:19:38 kepler NULL pointer dereference Jul 14 11:19:38 kepler at 00dc Jul 14 11:19:38 kepler IP: Jul 14 11:19:38 kepler [] rc_g_keycode_from_table+0x1e/0xe0 [rc_core] Jul 14 11:19:38 kepler *pde = Jul 14 11:19:38 kepler Jul 14 11:19:38 kepler Oops: [#1] Jul 14 11:19:38 kepler PREEMPT Jul 14 11:19:38 kepler Jul 14 11:19:38 kepler Modules linked in: Jul 14 11:19:38 kepler imon(+) Jul 14 11:19:38 kepler rc_imon_pad Jul 14 11:19:38 kepler rc_imon_mce Jul 14 11:19:38 kepler netconsole Jul 14 11:19:38 kepler asb100 Jul 14 11:19:38 kepler hwmon_vid Jul 14 11:19:38 kepler cx22702 Jul 14 11:19:38 kepler dvb_pll Jul 14 11:19:38 kepler mt352 Jul 14 11:19:38 kepler cx88_dvb Jul 14 11:19:38 kepler cx88_vp3054_i2c Jul 14 11:19:38 kepler videobuf_dvb Jul 14 11:19:38 kepler snd_via82xx Jul 14 11:19:38 kepler snd_ac97_codec Jul 14 11:19:38 kepler cx8800 Jul 14 11:19:38 kepler cx8802 Jul 14 11:19:38 kepler cx88xx Jul 14 11:19:38 kepler ac97_bus Jul 14 11:19:38 kepler snd_mpu401_uart Jul 14 11:19:38 kepler snd_rawmidi Jul 14 11:19:38 kepler b44 Jul 14 11:19:38 kepler ssb Jul 14 11:19:38 kepler rc_core Jul 14 11:19:38 kepler i2c_algo_bit Jul 14 11:19:38 kepler mii Jul 14 11:19:38 kepler tveeprom Jul 14 11:19:38 kepler btcx_risc Jul 14 11:19:38 kepler i2c_viapro Jul 14 11:19:38 kepler videobuf_dma_sg Jul 14 11:19:38 kepler videobuf_core Jul 14 11:19:38 kepler [last unloaded: ir_nec_decoder] Jul 14 11:19:38 kepler Jul 14 11:19:38 kepler Jul 14 11:19:38 kepler Pid: 2885, comm: modprobe Not tainted 3.0.0-rc7 #1 Jul 14 11:19:38 kepler System Manufacturer System Name Jul 14 11:19:38 kepler /A7V8X Jul 14 11:19:38 kepler Jul 14 11:19:38 kepler EIP: 0060:[] EFLAGS: 00010002 CPU: 0 Jul 14 11:19:38 kepler EIP is at rc_g_keycode_from_table+0x1e/0xe0 [rc_core] Jul 14 11:19:38 kepler EAX: EBX: f5610800 ECX: 0008 EDX: Jul 14 11:19:38 kepler ESI: EDI: EBP: f7009e48 ESP: f7009e18 Jul 14 11:19:38 kepler DS: 007b ES: 007b FS: GS: 0033 SS: 0068 Jul 14 11:19:38 kepler Process modprobe (pid: 2885, ti=f7008000 task=f708ada0 task.ti=f5706000) Jul 14 11:19:38 kepler Stack: Jul 14 11:19:38 kepler f71cc8c0 Jul 14 11:19:38 kepler 0082 Jul 14 11:19:38 kepler 0002 Jul 14 11:19:38 kepler f7009e2c Jul 14 11:19:38 kepler c101eabb Jul 14 11:19:38 kepler f71cc8c0 Jul 14 11:19:38 kepler Jul 14 11:19:38 kepler 0086 Jul 14 11:19:38 kepler Jul 14 11:19:38 kepler 0086 Jul 14 11:19:38 kepler f5610800 Jul 14 11:19:38 kepler Jul 14 11:19:38 kepler Jul 14 11:19:38 kepler f7009e58 Jul 14 11:19:38 kepler f87be59c Jul 14 11:19:38 kepler f5610800 Jul 14 11:19:38 kepler f5610841 Jul 14 11:19:38 kepler Jul 14 11:19:38 kepler f7009edc Jul 14 11:19:38 kepler f87be6dc Jul 14 11:19:38 kepler f68c00a4 Jul 14 11:19:38 kepler f7009e6c Jul 14 11:19:38 kepler f68c5760 Jul 14 11:19:38 kepler f7009e74 Jul 14 11:19:38 kepler f68c00a4 Jul 14 11:19:38 kepler f7009e98 Jul 14 11:19:38 kepler Jul 14 11:19:38 kepler Call Trace: Jul 14 11:19:38 kepler [] ? T.886+0x1b/0x30 Jul 14 11:19:38 kepler [] imon_remote_key_lookup+0x1c/0x70 [imon] Jul 14 11:19:38 kepler [] imon_incoming_packet+0x5c/0xe20 [imon] Jul 14 11:19:38 kepler [] ? atapi_qc_complete+0x58/0x2b0 Jul 14 11:19:38 kepler [] ? __ata_qc_complete+0x73/0x110 Jul 14 11:19:38 kepler [] usb_rx_callback_intf0+0x63/0x70 [imon] Jul 14 11:19:38 kepler [] usb_hcd_giveback_urb+0x48/0xb0 Jul 14 11:19:38 kepler [] uhci_giveback_urb+0x8e/0x220 Jul 14 11:19:38 kepler [] uhci_scan_schedule+0x366/0x9e0 Jul 14 11:19:38 kepler [] uhci_irq+0x91/0x170 Jul 14 11:19:38 kepler [] usb_hcd_irq+0x21/0x50 Jul 14 11:19:38 kepler [] handle_irq_event_percpu+0x36/0x140 Jul 14 11:19:38 kepler [] ? __io_apic_modify_irq+0x80/0x90 Jul 14 11:19:38 kepler [] ? handle_edge_irq+0x100/0x100 Jul 14 11:19:38 kepler [] handle_irq_event+0x32/0x60 Jul 14 11:19:38 kepler [] handle_fasteoi_irq+0x45/0xc0 Jul 14 11:19:38 kepler Jul 14 11:19:38 kepler Jul 14 11:19:38 kepler [] ? do_IRQ+0x3a/0xb0 Jul 14 11:19:38 kepler [] ? zone_watermark_ok+0x23/0x30 Jul 14 11:19:38 kepler [] ? common_interrup
Re: [beagleboard] [RFC v1] mt9v113: VGA camera sensor driver and support for BeagleBoard
Hi Vaibhav, Thanks for your email. On Wed, Jul 13, 2011 at 2:55 PM, Hiremath, Vaibhav wrote: > >> -Original Message- >> From: beaglebo...@googlegroups.com [mailto:beaglebo...@googlegroups.com] >> On Behalf Of Joel A Fernandes >> Sent: Wednesday, July 13, 2011 11:52 PM >> To: beaglebo...@googlegroups.com >> Cc: Joel A Fernandes; Kridner, Jason; Javier Martin; >> laurent.pinch...@ideasonboard.com; linux-media@vger.kernel.org; Kooi, >> Koen; Prakash, Punya; Maupin, Chase; Kipisz, Steven; Aguirre, Sergio >> Subject: [beagleboard] [RFC v1] mt9v113: VGA camera sensor driver and >> support for BeagleBoard >> >> * Adds support for mt9v113 sensor by borrowing heavily from PSP 2.6.37 >> kernel patches >> * Adapted to changes in v4l2 framework and ISP driver >> >> Signed-off-by: Joel A Fernandes >> --- >> This patch will apply against the 2.6.39 kernel built from the OE- >> development tree (Which is essentially >> the v2.6.39 from the main tree with OE patches for BeagleBoard support and >> a few other features) >> >> If you have the Leapord imaging camera board with this particular sensor, >> I would apprecite it if anyone could >> try this patch out and provide any feedback/test results. >> >> To get the complete tree which works on a BeagleBoard-xM with all the OE >> patches and this patch, >> you can clone: https://github.com/joelagnel/linux-omap-2.6/tree/oedev- >> 2.6.39-mt9v113 >> >> It will compile and work on a BeagleBoard-xM with the defconfig at: >> http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/linux/linu >> x-omap-2.6.39/beagleboard/defconfig >> >> Also you will need to apply my media-ctl patch (or clone the tree) to >> setup the formats: >> https://github.com/joelagnel/media- >> ctl/commit/cdf24d1249ac1ff3cd6f70ad80c3b76ac28ba0d5 >> >> Binaries for quick testing on a BeagleBoard-xM: >> U-boot: http://utdallas.edu/~joel.fernandes/u-boot.bin >> U-boot: http://utdallas.edu/~joel.fernandes/MLO >> uEnv.txt: http://utdallas.edu/~joel.fernandes/uEnv.txt >> media-ctl: http://utdallas.edu/~joel.fernandes/media-ctl >> kernel: http://utdallas.edu/~joel.fernandes/uImage >> >> media-ctl/yavta commands you could use to get it to show a picture can be >> found at: >> http://utdallas.edu/~joel.fernandes/stream.sh >> >> Note: >> The BeagleBoard camera board file in this patch replaces the old one, so >> this will take away support for the 5M >> sensor (mt9p031), I hope this can be forgiven considering this is an >> RFC :). I am working on a common board file >> that will work for both sensors. >> > [Hiremath, Vaibhav] Joel, > > I am bit surprised by this patch submission, first of all, the patch has been > submitted without my knowledge. And I was not aware that you are targeting > linux-media for this code-snippet. > > This code needs lot of cleanup and changes to get to the level where we can > submit it to the linux-media, and I think I clearly mentioned about known > issues with this patch/driver in the commit itself. Please refer to the below > commit - > > http://arago-project.org/git/projects/?p=linux-omap3.git;a=commitdiff;h=c6174e0658b9aaa8f7a3ec9fe562619084d34f59 > > I agree that we had some internal discussion on this and I was under > assumption that this effort was only towards beagle openembedded and not for > linux-media. > [Joel] I'm sorry, actually the intent of the RFC was to get immediate VGA camera support to Beagle users and some testing with our kernel. The other intention was to help your team with the differences in what has changed across the kernels as a reference so that you reuse some of the work. Certainly I was not going to claim authorship or make the final submission. About Signed-off-by lines (if that's what you refer to about authorship), I intentionally didn't include it in my temporary git tree as I wanted to make sure if I could use it without permission. My intention was to rebase and include the relevant SOB lines after I got clarification on this. Could you suggest a general rule about SOB lines and whether these can be used without permission when you reuse/adapt a patch? I hoped that the words "borrowed from PSP" in the commit summary, the relevant links to the commits in your tree in the commit summaries and the retaining of copyright information in the code made it clear that I was not the original author. I understand that it is a bit frustrating to see someone take your code when its not yet complete, anyway I hope my commits help in some way. Atleast there might be a few people who test your code on the Beagle and give your team some valuable feedback. Thanks, Joel -- 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: [git:v4l-dvb/for_v3.1] [media] DVB: dvb_frontend: off by one in dtv_property_dump()
On 13.07.2011 23:28, Mauro Carvalho Chehab wrote:
> This is an automatic generated email to let you know that the following patch
> were queued at the
> http://git.linuxtv.org/media_tree.git tree:
>
> Subject: [media] DVB: dvb_frontend: off by one in dtv_property_dump()
> Author: Dan Carpenter
> Date:Thu May 26 05:44:52 2011 -0300
>
> If the tvp->cmd == DTV_MAX_COMMAND then we read past the end of the
> array.
That's wrong, because the array size is DTV_MAX_COMMAND + 1. Using the
ARRAY_SIZE macro instead might reduce the confusion.
Regards,
Andreas
> Signed-off-by: Dan Carpenter
> Signed-off-by: Mauro Carvalho Chehab
>
> drivers/media/dvb/dvb-core/dvb_frontend.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> ---
>
> http://git.linuxtv.org/media_tree.git?a=commitdiff;h=a3e4adf274f86b2363fedaa964297cb38526cef0
>
> diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c
> b/drivers/media/dvb/dvb-core/dvb_frontend.c
> index bed7bfe..c9c3c79 100644
> --- a/drivers/media/dvb/dvb-core/dvb_frontend.c
> +++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
> @@ -982,7 +982,7 @@ static void dtv_property_dump(struct dtv_property *tvp)
> {
> int i;
>
> - if (tvp->cmd <= 0 || tvp->cmd > DTV_MAX_COMMAND) {
> + if (tvp->cmd <= 0 || tvp->cmd >= DTV_MAX_COMMAND) {
> printk(KERN_WARNING "%s: tvp.cmd = 0x%08x undefined\n",
> __func__, tvp->cmd);
> return;
>
> ___
> linuxtv-commits mailing list
> linuxtv-comm...@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linuxtv-commits
--
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/3] redrat3 driver updates for 3.1
Em 13-07-2011 18:26, Jarod Wilson escreveu: > These changes make the redrat3 driver cooperate better with both in-kernel > and lirc userspace decoding of signals, tested with RC5, RC6 and NEC. > There's probably more we can do to make this a bit less hackish, but its > working quite well here for me right now. > > Jarod Wilson (3): > [media] redrat3: sending extra trailing space was useless > [media] redrat3: cap duration in the right place > [media] redrat3: improve compat with lirc userspace decode Applied, thanks. There's one small issue on it (32 bits compilation): drivers/media/rc/redrat3.c: In function ‘redrat3_init_rc_dev’: drivers/media/rc/redrat3.c:1106: warning: assignment from incompatible pointer type compilation succeeded > > drivers/media/rc/redrat3.c | 61 --- > 1 files changed, 28 insertions(+), 33 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 -- 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] pctv452e.c: switch rc handling to rc.core
On Wed, Jul 13, 2011 at 07:31:03PM -0300, Mauro Carvalho Chehab wrote: > Em 25-06-2011 16:34, Juergen Lock escreveu: > > This is on top of the submitted pctv452e.c driver and was done similar > > to how ttusb2 works. Tested with lirc (devinput) and ir-keytable(1). > > You should submit pctv452e driver first, otherwise I can't apply > this one ;) Heh well Hans last did that a little while ago iirc, tho of course he didn't write it. :) (Do I guess right it never got committed earlier because of stb0899 tuning problems for which the fix(es?) are still waiting to be committed? At least I think I still need patches here if I don't want w_scan to miss random transponders... I.e. it only finds like 70% of what's on Astra 19.2E and missed different ones each time I ran it without stb0899 patches.) Cheers, Juergen -- 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: 2.6.39 "tuner-core: remove usage of DIGITAL_TV" breaks saa7134 with mt2050
On 13/07/11 05:23, Mauro Carvalho Chehab wrote: > Em 12-07-2011 18:21, Simon Arlott escreveu: >> commit ad020dc2fe9039628cf6cef42cd1b76531ee8411 >> Author: Mauro Carvalho Chehab >> Date: Tue Feb 15 09:30:50 2011 -0200 >> >> [media] tuner-core: remove usage of DIGITAL_TV >> >> This breaks my Pinnacle PCTV 300i DVB-T cards as they can no longer tune >> DVB-T. >> >> [ 540.010030] tuner 3-0043: Tuner doesn't support mode 3. Putting tuner to >> sleep >> [ 540.011017] tuner 2-0043: Tuner doesn't support mode 3. Putting tuner to >> sleep >> [ 540.012012] tuner 3-0060: Tuner doesn't support mode 3. Putting tuner to >> sleep >> [ 540.013029] tuner 2-0060: Tuner doesn't support mode 3. Putting tuner to >> sleep >> >> saa7134 needs to indicate digital TV tuning to mt20xx but it looks like >> tuner-core no longer has any way to allow a tuner to indicate support >> for this? >> >> (mt2050_set_tv_freq in mt20xx.c uses V4L2_TUNER_DIGITAL_TV) > > Could you please try the enclosed patch? It should fix the issue. > I should probably rename T_ANALOG_TV to just T_TV, but I'll do it on > a next patch if this one works ok, as we don't want to send a renaming > patch to -stable. This fixes it. Tuner error messages could do with being error level - I didn't see the message initially as I have the debugging turned off. The -EINVAL never gets passed up to userspace. > --- > [media] Fix Digital TV breakage with mt20xx tuner > > The mt20xx tuner passes V4L2_TUNER_DIGITAL_TV to tuner core. However, the > check_mode code now doesn't handle it well. Change the logic there to > avoid the breakage, and fix a test for analog-only at g_tuner. Thanks, -- Simon Arlott -- 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: [RFC PATCH] capture-example: allow V4L2_PIX_FMT_GREY with USERPTR
Em 28-06-2011 11:23, Michael Jones escreveu:
> There is an assumption that the format coming from the device
> needs 2 bytes per pixel, which is not the case when the device
> delivers e.g. V4L2_PIX_FMT_GREY. This doesn't manifest itself with
> IO_METHOD_MMAP because init_mmap() (the default) doesn't take
> sizeimage as an argument.
>
> Signed-off-by: Michael Jones
> ---
>
> This same issue would apply to other formats which have 1 byte per pixel,
> this patch only fixes it for GREY. Is this OK for now, or does somebody
> have a better suggestion for supporting other formats as well?
Well, just rely on the bytesperline provided by the driver should be enough.
Devices should be returning it on a consistent way.
Regards,
Mauro
>
> contrib/test/capture-example.c |4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/contrib/test/capture-example.c b/contrib/test/capture-example.c
> index 3852c58..0eb5235 100644
> --- a/contrib/test/capture-example.c
> +++ b/contrib/test/capture-example.c
> @@ -416,6 +416,7 @@ static void init_device(void)
> struct v4l2_crop crop;
> struct v4l2_format fmt;
> unsigned int min;
> + unsigned int bytes_per_pixel;
>
> if (-1 == xioctl(fd, VIDIOC_QUERYCAP, &cap)) {
> if (EINVAL == errno) {
> @@ -519,7 +520,8 @@ static void init_device(void)
> }
>
> /* Buggy driver paranoia. */
> - min = fmt.fmt.pix.width * 2;
> + bytes_per_pixel = fmt.fmt.pix.pixelformat == V4L2_PIX_FMT_GREY ? 1 : 2;
> + min = fmt.fmt.pix.width * bytes_per_pixel;
> if (fmt.fmt.pix.bytesperline < min)
> fmt.fmt.pix.bytesperline = min;
> min = fmt.fmt.pix.bytesperline * fmt.fmt.pix.height;
--
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] pctv452e.c: switch rc handling to rc.core
Em 25-06-2011 16:34, Juergen Lock escreveu:
> This is on top of the submitted pctv452e.c driver and was done similar
> to how ttusb2 works. Tested with lirc (devinput) and ir-keytable(1).
You should submit pctv452e driver first, otherwise I can't apply
this one ;)
Regards,
Mauro
>
> Signed-off-by: Juergen Lock
>
> --- a/drivers/media/dvb/dvb-usb/pctv452e.c
> +++ b/drivers/media/dvb/dvb-usb/pctv452e.c
> @@ -98,6 +98,7 @@ struct pctv452e_state {
>
> u8 c; /* transaction counter, wraps around... */
> u8 initialized; /* set to 1 if 0x15 has been sent */
> + u16 last_rc_key;
> };
>
> static int
> @@ -535,83 +536,10 @@ int pctv452e_power_ctrl(struct dvb_usb_d
> return 0;
> }
>
> -/* Remote control stuff */
> -static struct rc_map_table pctv452e_rc_keys[] = {
> - {0x0700, KEY_MUTE},
> - {0x0701, KEY_VENDOR}, // pinnacle logo (top middle)
> - {0x0739, KEY_POWER},
> - {0x0703, KEY_VOLUMEUP},
> - {0x0709, KEY_VOLUMEDOWN},
> - {0x0706, KEY_CHANNELUP},
> - {0x070c, KEY_CHANNELDOWN},
> - {0x070f, KEY_1},
> - {0x0715, KEY_2},
> - {0x0710, KEY_3},
> - {0x0718, KEY_4},
> - {0x071b, KEY_5},
> - {0x071e, KEY_6},
> - {0x0711, KEY_7},
> - {0x0721, KEY_8},
> - {0x0712, KEY_9},
> - {0x0727, KEY_0},
> - {0x0724, KEY_TV}, // left of '0'
> - {0x072a, KEY_T}, // right of '0'
> - {0x072d, KEY_REWIND},
> - {0x0733, KEY_FORWARD},
> - {0x0730, KEY_PLAY},
> - {0x0736, KEY_RECORD},
> - {0x073c, KEY_STOP},
> - {0x073f, KEY_HELP}
> -};
> -
> -/* Remote Control Stuff fo S2-3600 (copied from TT-S1500): */
> -static struct rc_map_table tt_connect_s2_3600_rc_key[] = {
> - {0x1501, KEY_POWER},
> - {0x1502, KEY_SHUFFLE}, /* ? double-arrow key */
> - {0x1503, KEY_1},
> - {0x1504, KEY_2},
> - {0x1505, KEY_3},
> - {0x1506, KEY_4},
> - {0x1507, KEY_5},
> - {0x1508, KEY_6},
> - {0x1509, KEY_7},
> - {0x150a, KEY_8},
> - {0x150b, KEY_9},
> - {0x150c, KEY_0},
> - {0x150d, KEY_UP},
> - {0x150e, KEY_LEFT},
> - {0x150f, KEY_OK},
> - {0x1510, KEY_RIGHT},
> - {0x1511, KEY_DOWN},
> - {0x1512, KEY_INFO},
> - {0x1513, KEY_EXIT},
> - {0x1514, KEY_RED},
> - {0x1515, KEY_GREEN},
> - {0x1516, KEY_YELLOW},
> - {0x1517, KEY_BLUE},
> - {0x1518, KEY_MUTE},
> - {0x1519, KEY_TEXT},
> - {0x151a, KEY_MODE}, /* ? TV/Radio */
> - {0x1521, KEY_OPTION},
> - {0x1522, KEY_EPG},
> - {0x1523, KEY_CHANNELUP},
> - {0x1524, KEY_CHANNELDOWN},
> - {0x1525, KEY_VOLUMEUP},
> - {0x1526, KEY_VOLUMEDOWN},
> - {0x1527, KEY_SETUP},
> - {0x153a, KEY_RECORD},/* these keys are only in the black remote */
> - {0x153b, KEY_PLAY},
> - {0x153c, KEY_STOP},
> - {0x153d, KEY_REWIND},
> - {0x153e, KEY_PAUSE},
> - {0x153f, KEY_FORWARD}
> -};
> -
> -static int pctv452e_rc_query(struct dvb_usb_device *d, u32 *keyevent, int
> *keystate) {
> +static int pctv452e_rc_query(struct dvb_usb_device *d) {
> struct pctv452e_state *state = (struct pctv452e_state *)d->priv;
> u8 b[CMD_BUFFER_SIZE];
> u8 rx[PCTV_ANSWER_LEN];
> - u8 keybuf[5];
> int ret, i;
> u8 id = state->c++;
>
> @@ -621,8 +549,6 @@ static int pctv452e_rc_query(struct dvb_
> b[2] = PCTV_CMD_IR;
> b[3] = 0;
>
> - *keystate = REMOTE_NO_KEY_PRESSED;
> -
> /* send ir request */
> ret = dvb_usb_generic_rw(d, b, 4, rx, PCTV_ANSWER_LEN, 0);
> if (ret != 0) return ret;
> @@ -637,16 +563,14 @@ static int pctv452e_rc_query(struct dvb_
>
> if ((rx[3] == 9) && (rx[12] & 0x01)) {
> /* got a "press" event */
> + state->last_rc_key = (rx[7] << 8) | rx[6];
> if (debug > 2) {
> printk("%s: cmd=0x%02x sys=0x%02x\n", __func__, rx[6],
> rx[7]);
> }
> - keybuf[0] = 0x01;// DVB_USB_RC_NEC_KEY_PRESSED; why is this
> #define'd privately?
> - keybuf[1] = rx[7];
> - keybuf[2] = ~keybuf[1]; // fake checksum
> - keybuf[3] = rx[6];
> - keybuf[4] = ~keybuf[3]; // fake checksum
> - dvb_usb_nec_rc_key_to_event(d, keybuf, keyevent, keystate);
> -
> + rc_keydown(d->rc_dev, state->last_rc_key, 0);
> + } else if (state->last_rc_key) {
> + rc_keyup(d->rc_dev);
> + state->last_rc_key = 0;
> }
>
> return 0;
> @@ -1294,11 +1218,11 @@ static struct dvb_usb_device_properties
> /* Untested. */
> /* .read_mac_address = pctv452e_read_mac_address, */
>
> - .rc.legacy = {
> - .rc_map_table = pctv452e_rc_keys,
> - .rc_map_size = ARRAY_SIZE(pctv452e_rc_keys),
> + .rc.core = {
> + .rc_interval = 100, /* Less than IR_KEYPRESS_TIMEOUT */
> + .rc_codes = RC_MAP_DIB0700_RC5_TABLE,
> .rc_query = pctv452e_rc_query,
Re: [RFC v1] mt9v113: VGA camera sensor driver and support for BeagleBoard
Hi Joel,
On Wednesday 13 July 2011 20:22:27 Joel A Fernandes wrote:
> * Adds support for mt9v113 sensor by borrowing heavily from PSP 2.6.37
> kernel patches * Adapted to changes in v4l2 framework and ISP driver
Here are a few comments about the code. I've left political issues aside on
purpose.
> Signed-off-by: Joel A Fernandes
> ---
[snip]
> diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
> index 3a5bc57..7721aaa 100644
> --- a/drivers/media/video/Kconfig
> +++ b/drivers/media/video/Kconfig
> @@ -351,6 +351,13 @@ config VIDEO_MT9V032
> This is a Video4Linux2 sensor-level driver for the Micron
> MT9V032 752x480 CMOS sensor.
>
> +config VIDEO_MT9V113
> + tristate "Aptina MT9V113 VGA CMOS IMAGE SENSOR"
No need to shout :-)
> + depends on VIDEO_V4L2 && I2C
> + ---help---
> + This is a Video4Linux2 sensor-level driver for the Aptina MT9V113
> + image sensor.
> +
> config VIDEO_TCM825X
> tristate "TCM825x camera sensor support"
> depends on I2C && VIDEO_V4L2
[snip]
> diff --git a/drivers/media/video/mt9v113.c b/drivers/media/video/mt9v113.c
> new file mode 100644
> index 000..96512a4
> --- /dev/null
> +++ b/drivers/media/video/mt9v113.c
> @@ -0,0 +1,1027 @@
> +/*
> + * drivers/media/video/mt9v113.c
> + *
> + * Based on TI TVP5146/47 decoder driver
> + *
> + *
> + * This package is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "mt9v113_regs.h"
> +
> +/* Macro's */
> +#define I2C_RETRY_COUNT (5)
> +
> +#define MT9V113_DEF_WIDTH640
> +#define MT9V113_DEF_HEIGHT 480
> +
> +/* Debug functions */
> +static int debug = 1;
> +module_param(debug, bool, 0644);
> +MODULE_PARM_DESC(debug, "Debug level (0-1)");
> +
> +/*
> + * struct mt9v113 - sensor object
> + * @subdev: v4l2_subdev associated data
> + * @pad: media entity associated data
> + * @format: associated media bus format
> + * @rect: configured resolution/window
> + * @pdata: Board specific
> + * @ver: Chip version
> + * @power: Current power state (0: off, 1: on)
> + */
> +struct mt9v113 {
> + struct v4l2_subdev subdev;
> + struct media_pad pad;
> + struct v4l2_mbus_framefmt format;
> + struct v4l2_rect rect;
> +
> + struct v4l2_ctrl_handler ctrls;
> +
> + const struct mt9v113_platform_data *pdata;
> + unsigned int ver;
> + bool power;
> +};
> +
> +#define to_mt9v113(sd) container_of(sd, struct mt9v113, subdev)
> +/*
> + * struct mt9v113_fmt -
> + * @mbus_code: associated media bus code
> + * @fmt: format descriptor
> + */
> +struct mt9v113_fmt {
> + unsigned int mbus_code;
> + struct v4l2_fmtdesc fmt;
The fmt field is never used, you can remove it.
> +};
> +/*
> + * List of image formats supported by mt9v113
> + * Currently we are using 8 bit and 8x2 bit mode only, but can be
> + * extended to 10 bit mode.
> + */
> +static const struct mt9v113_fmt mt9v113_fmt_list[] = {
> + {
> + .mbus_code = V4L2_MBUS_FMT_UYVY8_2X8,
> + .fmt = {
> + .index = 0,
> + .type = V4L2_BUF_TYPE_VIDEO_CAPTURE,
> + .flags = 0,
> + .description = "8-bit UYVY 4:2:2 Format",
> + .pixelformat = V4L2_PIX_FMT_UYVY,
> + },
> + },
> + {
> + .mbus_code = V4L2_MBUS_FMT_YUYV8_2X8,
> + .fmt = {
> + .index = 1,
> + .type = V4L2_BUF_TYPE_VIDEO_CAPTURE,
> + .flags = 0,
> + .description = "8-bit YUYV 4:2:2 Format",
> + .pixelformat = V4L2_PIX_FMT_YUYV,
> + },
> + },
> + {
> + .mbus_code = V4L2_MBUS_FMT_RGB565_2X8_LE,
> + .fmt = {
> + .index = 2,
> + .type = V4L2_BUF_TYPE_VIDEO_CAPTURE,
> + .flags = 0,
> + .description = "16-bit RGB565 format",
> + .pixelformat = V4L2_PIX_FMT_RGB565,
> + },
> + },
> +};
> +
> +/* MT9V113 register set for VGA mode */
> +static struct mt9v113_reg mt9v113_vga_reg[] = {
> + {TOK_WRITE, 0x098C, 0x2739}, /* crop_X0_A */
> +
Re: [PATCH 1/9] stringify: add HEX_STRING()
On Wed, 13 Jul 2011 18:13:31 -0400 Arnaud Lacombe wrote: > Hi, > > On Wed, Jul 13, 2011 at 6:08 PM, Randy Dunlap wrote: > > On Wed, 13 Jul 2011 18:06:15 -0400 Arnaud Lacombe wrote: > > > >> Hi, > >> > >> On Wed, Jul 13, 2011 at 6:00 PM, Randy Dunlap wrote: > >> > On Wed, 13 Jul 2011 17:49:48 -0400 Arnaud Lacombe wrote: > >> > > >> >> Hi, > >> >> > >> >> On Sun, Jul 10, 2011 at 3:51 PM, Randy Dunlap > >> >> wrote: > >> >> > From: Randy Dunlap > >> >> > > >> >> > Add HEX_STRING(value) to stringify.h so that drivers can > >> >> > convert kconfig hex values (without leading "0x") to useful > >> >> > hex constants. > >> >> > > >> >> > Several drivers/media/radio/ drivers need this. I haven't > >> >> > checked if any other drivers need to do this. > >> >> > > >> >> > Alternatively, kconfig could produce hex config symbols with > >> >> > leading "0x". > >> >> > > >> >> Actually, I used to have a patch to make hex value have a mandatory > >> >> "0x" prefix, in the Kconfig. I even fixed all the issue in the tree, > >> >> it never make it to the tree (not sure why). Here's the relevant > >> >> thread: > >> >> > >> >> https://patchwork.kernel.org/patch/380591/ > >> >> https://patchwork.kernel.org/patch/380621/ > >> >> https://patchwork.kernel.org/patch/380601/ > >> >> > >> > > >> > I prefer that this be fixed in kconfig, so long as it won't cause > >> > any other issues. That's why I mentioned it. > >> > > >> >> > >> >> > Signed-off-by: Randy Dunlap > >> >> > --- > >> >> > include/linux/stringify.h | 7 +++ > >> >> > 1 file changed, 7 insertions(+) > >> >> > > >> >> > NOTE: The other 8 patches are on lkml and linux-media mailing lists. > >> >> > > >> >> > --- linux-next-20110707.orig/include/linux/stringify.h > >> >> > +++ linux-next-20110707/include/linux/stringify.h > >> >> > @@ -9,4 +9,11 @@ > >> >> > #define __stringify_1(x...) #x > >> >> > #define __stringify(x...) __stringify_1(x) > >> >> > > >> >> > +/* > >> >> > + * HEX_STRING(value) is useful for CONFIG_ values that are in hex, > >> >> > + * but kconfig does not put a leading "0x" on them. > >> >> > + */ > >> >> > +#define HEXSTRINGVALUE(h, value) h##value > >> >> > +#define HEX_STRING(value) HEXSTRINGVALUE(0x, value) > >> >> > + > >> >> that seems hackish... > >> > > >> > It's a common idiom for concatenating strings in the kernel. > >> > > >> I meant hackish not because *how* it is done, but because *why* it has > >> to be done, that is, because the Kconfig miss the prefix, which is > >> really no big deal. > >> > >> > How would you do it without (instead of) a kconfig fix/patch? > >> > > >> have the Kconfig use the "0x" prefix since the beginning. > > > > Sure, go for it. I'll ack it. ;) [or Review it :] > > and test it. > > > it is already among the hunks in https://patchwork.kernel.org/patch/380601/ I realize that, but it looks like you may need to resubmit it. I'll dig it out and test it, maybe even reply to your old patch(es). --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** -- 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 1/9] stringify: add HEX_STRING()
Hi, On Wed, Jul 13, 2011 at 6:08 PM, Randy Dunlap wrote: > On Wed, 13 Jul 2011 18:06:15 -0400 Arnaud Lacombe wrote: > >> Hi, >> >> On Wed, Jul 13, 2011 at 6:00 PM, Randy Dunlap wrote: >> > On Wed, 13 Jul 2011 17:49:48 -0400 Arnaud Lacombe wrote: >> > >> >> Hi, >> >> >> >> On Sun, Jul 10, 2011 at 3:51 PM, Randy Dunlap >> >> wrote: >> >> > From: Randy Dunlap >> >> > >> >> > Add HEX_STRING(value) to stringify.h so that drivers can >> >> > convert kconfig hex values (without leading "0x") to useful >> >> > hex constants. >> >> > >> >> > Several drivers/media/radio/ drivers need this. I haven't >> >> > checked if any other drivers need to do this. >> >> > >> >> > Alternatively, kconfig could produce hex config symbols with >> >> > leading "0x". >> >> > >> >> Actually, I used to have a patch to make hex value have a mandatory >> >> "0x" prefix, in the Kconfig. I even fixed all the issue in the tree, >> >> it never make it to the tree (not sure why). Here's the relevant >> >> thread: >> >> >> >> https://patchwork.kernel.org/patch/380591/ >> >> https://patchwork.kernel.org/patch/380621/ >> >> https://patchwork.kernel.org/patch/380601/ >> >> >> > >> > I prefer that this be fixed in kconfig, so long as it won't cause >> > any other issues. That's why I mentioned it. >> > >> >> >> >> > Signed-off-by: Randy Dunlap >> >> > --- >> >> > include/linux/stringify.h | 7 +++ >> >> > 1 file changed, 7 insertions(+) >> >> > >> >> > NOTE: The other 8 patches are on lkml and linux-media mailing lists. >> >> > >> >> > --- linux-next-20110707.orig/include/linux/stringify.h >> >> > +++ linux-next-20110707/include/linux/stringify.h >> >> > @@ -9,4 +9,11 @@ >> >> > #define __stringify_1(x...) #x >> >> > #define __stringify(x...) __stringify_1(x) >> >> > >> >> > +/* >> >> > + * HEX_STRING(value) is useful for CONFIG_ values that are in hex, >> >> > + * but kconfig does not put a leading "0x" on them. >> >> > + */ >> >> > +#define HEXSTRINGVALUE(h, value) h##value >> >> > +#define HEX_STRING(value) HEXSTRINGVALUE(0x, value) >> >> > + >> >> that seems hackish... >> > >> > It's a common idiom for concatenating strings in the kernel. >> > >> I meant hackish not because *how* it is done, but because *why* it has >> to be done, that is, because the Kconfig miss the prefix, which is >> really no big deal. >> >> > How would you do it without (instead of) a kconfig fix/patch? >> > >> have the Kconfig use the "0x" prefix since the beginning. > > Sure, go for it. I'll ack it. ;) [or Review it :] > and test it. > it is already among the hunks in https://patchwork.kernel.org/patch/380601/ - Arnaud -- 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: Imon module Oops and kernel hang
On Jul 13, 2011, at 1:42 AM, Chris W wrote: > > On 13/07/11 14:20, Jarod Wilson wrote: > >>> Chris W wrote: >>> The rc keymap modules have been built (en masse as a result of >>> CONFIG_RC_MAP=m) but I am not explicitly loading them and they do not >>> get automatically loaded. >> >> Huh. That's unexpected. They get auto-loaded here, last I knew. I'll >> have to give one of my devices a spin tomorrow, not sure exactly what >> the last kernel I tried one of them on was. Pretty sure they're >> working fine with the Fedora 15 2.6.38.x kernels and vanilla (but >> Fedora-configured) 3.0-rc kernels though. > > > I just ran depmod to make sure things were straight in this dept. > > kepler ~ # depmod -F System.map -e -av 2.6.39.3 > > There are no reported errors. The modules rc-imon-mce.ko, > rc-imon-pad.ko and imon.ko depend only on rc-core.ko according to the > output. There don't seem to be any explicit dependencies to the keymaps > (not a kernel dev so I don't know if there should be) Yeah, imon depends on rc-core, and requests its keymap via rc-core, so rc-core should then load up rc-imon-pad. Just tried on 3.0-rc7+ here, and everything is happy: [10791.866789] imon 3-2:1.0: usb_probe_interface [10791.868944] imon 3-2:1.0: usb_probe_interface - got id [10791.871332] input: iMON Panel, Knob and Mouse(15c2:0042) as /devices/pci:00/:00:03.1/usb3/3-2/3-2:1.0/input/input18 [10791.916037] Registered IR keymap rc-imon-pad [10791.918709] input: iMON Remote (15c2:0042) as /devices/pci:00/:00:03.1/usb3/3-2/3-2:1.0/rc/rc6/input19 [10791.921331] rc6: iMON Remote (15c2:0042) as /devices/pci:00/:00:03.1/usb3/3-2/3-2:1.0/rc/rc6 [10791.930038] imon 3-2:1.0: iMON device (15c2:0042, intf0) on usb<3:3> initialized [10791.932507] imon 3-2:1.1: usb_probe_interface [10791.934949] imon 3-2:1.1: usb_probe_interface - got id [10791.937416] imon 3-2:1.1: iMON device (15c2:0042, intf1) on usb<3:3> initialized [10791.939996] usbcore: registered new interface driver imon Just noticed your report is for 2.6.39.x and 2.6.38.x only, but I'm not aware of any relevant imon changes between 2.6.39 and 3.0. >>> Perhaps there something else in the kernel config that must be on in >>> order to support the keymaps? >>> >>> Any other thoughts? >> >> Not at the moment. That T.889 line is... odd. No clue what the heck >> that thing is. Lemme see what I can see tomorrow (just past midnight >> here at the moment), if I don't hit anything, I might need a copy of >> your kernel config to repro. > > I can only see the "T.889" string in the System.map, kernel binary and > kernel/sched.o (but not the source?). I have sent the config file > off-list to Jarod. Looks like I'll probably have to give that a spin, since I'm not seeing the problem here (I can also switch to an 0xffdc device, which is actually handled a bit differently by the driver). -- Jarod Wilson ja...@wilsonet.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
Re: [PATCH 1/9] stringify: add HEX_STRING()
On Wed, 13 Jul 2011 18:06:15 -0400 Arnaud Lacombe wrote: > Hi, > > On Wed, Jul 13, 2011 at 6:00 PM, Randy Dunlap wrote: > > On Wed, 13 Jul 2011 17:49:48 -0400 Arnaud Lacombe wrote: > > > >> Hi, > >> > >> On Sun, Jul 10, 2011 at 3:51 PM, Randy Dunlap wrote: > >> > From: Randy Dunlap > >> > > >> > Add HEX_STRING(value) to stringify.h so that drivers can > >> > convert kconfig hex values (without leading "0x") to useful > >> > hex constants. > >> > > >> > Several drivers/media/radio/ drivers need this. I haven't > >> > checked if any other drivers need to do this. > >> > > >> > Alternatively, kconfig could produce hex config symbols with > >> > leading "0x". > >> > > >> Actually, I used to have a patch to make hex value have a mandatory > >> "0x" prefix, in the Kconfig. I even fixed all the issue in the tree, > >> it never make it to the tree (not sure why). Here's the relevant > >> thread: > >> > >> https://patchwork.kernel.org/patch/380591/ > >> https://patchwork.kernel.org/patch/380621/ > >> https://patchwork.kernel.org/patch/380601/ > >> > > > > I prefer that this be fixed in kconfig, so long as it won't cause > > any other issues. That's why I mentioned it. > > > >> > >> > Signed-off-by: Randy Dunlap > >> > --- > >> > include/linux/stringify.h | 7 +++ > >> > 1 file changed, 7 insertions(+) > >> > > >> > NOTE: The other 8 patches are on lkml and linux-media mailing lists. > >> > > >> > --- linux-next-20110707.orig/include/linux/stringify.h > >> > +++ linux-next-20110707/include/linux/stringify.h > >> > @@ -9,4 +9,11 @@ > >> > #define __stringify_1(x...) #x > >> > #define __stringify(x...) __stringify_1(x) > >> > > >> > +/* > >> > + * HEX_STRING(value) is useful for CONFIG_ values that are in hex, > >> > + * but kconfig does not put a leading "0x" on them. > >> > + */ > >> > +#define HEXSTRINGVALUE(h, value) h##value > >> > +#define HEX_STRING(value) HEXSTRINGVALUE(0x, value) > >> > + > >> that seems hackish... > > > > It's a common idiom for concatenating strings in the kernel. > > > I meant hackish not because *how* it is done, but because *why* it has > to be done, that is, because the Kconfig miss the prefix, which is > really no big deal. > > > How would you do it without (instead of) a kconfig fix/patch? > > > have the Kconfig use the "0x" prefix since the beginning. Sure, go for it. I'll ack it. ;) [or Review it :] and test it. thanks, --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** -- 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 1/9] stringify: add HEX_STRING()
Hi, On Wed, Jul 13, 2011 at 6:00 PM, Randy Dunlap wrote: > On Wed, 13 Jul 2011 17:49:48 -0400 Arnaud Lacombe wrote: > >> Hi, >> >> On Sun, Jul 10, 2011 at 3:51 PM, Randy Dunlap wrote: >> > From: Randy Dunlap >> > >> > Add HEX_STRING(value) to stringify.h so that drivers can >> > convert kconfig hex values (without leading "0x") to useful >> > hex constants. >> > >> > Several drivers/media/radio/ drivers need this. I haven't >> > checked if any other drivers need to do this. >> > >> > Alternatively, kconfig could produce hex config symbols with >> > leading "0x". >> > >> Actually, I used to have a patch to make hex value have a mandatory >> "0x" prefix, in the Kconfig. I even fixed all the issue in the tree, >> it never make it to the tree (not sure why). Here's the relevant >> thread: >> >> https://patchwork.kernel.org/patch/380591/ >> https://patchwork.kernel.org/patch/380621/ >> https://patchwork.kernel.org/patch/380601/ >> > > I prefer that this be fixed in kconfig, so long as it won't cause > any other issues. That's why I mentioned it. > >> >> > Signed-off-by: Randy Dunlap >> > --- >> > include/linux/stringify.h | 7 +++ >> > 1 file changed, 7 insertions(+) >> > >> > NOTE: The other 8 patches are on lkml and linux-media mailing lists. >> > >> > --- linux-next-20110707.orig/include/linux/stringify.h >> > +++ linux-next-20110707/include/linux/stringify.h >> > @@ -9,4 +9,11 @@ >> > #define __stringify_1(x...) #x >> > #define __stringify(x...) __stringify_1(x) >> > >> > +/* >> > + * HEX_STRING(value) is useful for CONFIG_ values that are in hex, >> > + * but kconfig does not put a leading "0x" on them. >> > + */ >> > +#define HEXSTRINGVALUE(h, value) h##value >> > +#define HEX_STRING(value) HEXSTRINGVALUE(0x, value) >> > + >> that seems hackish... > > It's a common idiom for concatenating strings in the kernel. > I meant hackish not because *how* it is done, but because *why* it has to be done, that is, because the Kconfig miss the prefix, which is really no big deal. > How would you do it without (instead of) a kconfig fix/patch? > have the Kconfig use the "0x" prefix since the beginning. - Arnaud >> > #endif /* !__LINUX_STRINGIFY_H */ >> > -- > > > --- > ~Randy > *** Remember to use Documentation/SubmitChecklist when testing your code *** > -- 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 1/9] stringify: add HEX_STRING()
On Wed, 13 Jul 2011 18:05:45 -0300 Mauro Carvalho Chehab wrote: > Em 10-07-2011 16:51, Randy Dunlap escreveu: > > From: Randy Dunlap > > > > Add HEX_STRING(value) to stringify.h so that drivers can > > convert kconfig hex values (without leading "0x") to useful > > hex constants. > > > > Several drivers/media/radio/ drivers need this. I haven't > > checked if any other drivers need to do this. > > > > Alternatively, kconfig could produce hex config symbols with > > leading "0x". > > Hi Randy, > > After applying patch 1/9 and 2/9 over 3.0-rc7+media patches, I'm > now getting this error: > > drivers/media/radio/radio-aimslab.c:52:1: error: invalid suffix "x20f" on > integer constant > > $ grep 20f .config > CONFIG_RADIO_RTRACK_PORT=20f > > $ gcc --version > gcc (GCC) 4.4.5 20110214 (Red Hat 4.4.5-6) > > Before this patch, this were working (or, at least, weren't producing > any error). > > Perhaps the breakage on your compilation happened due to another > patch at the tree? If so, the better would be to apply this patch Do you suspect that? I built this patch series against the latest linux-next (20110707), so it should contain media patches as of that date. > series together with the ones that caused the breakage, to avoid > bisect troubles. Sure, if we know what patch it is (if there indeed is one). Can you do: $ make drivers/media/radio/radio-aimslab.i and tell me what this line contains for you? Mine says: static int io = 0x20f; > > > > Signed-off-by: Randy Dunlap > > --- > > include/linux/stringify.h |7 +++ > > 1 file changed, 7 insertions(+) > > > > NOTE: The other 8 patches are on lkml and linux-media mailing lists. > > > > --- linux-next-20110707.orig/include/linux/stringify.h > > +++ linux-next-20110707/include/linux/stringify.h > > @@ -9,4 +9,11 @@ > > #define __stringify_1(x...)#x > > #define __stringify(x...) __stringify_1(x) > > > > +/* > > + * HEX_STRING(value) is useful for CONFIG_ values that are in hex, > > + * but kconfig does not put a leading "0x" on them. > > + */ > > +#define HEXSTRINGVALUE(h, value) h##value > > +#define HEX_STRING(value) HEXSTRINGVALUE(0x, value) > > + > > #endif /* !__LINUX_STRINGIFY_H */ > > -- --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** -- 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 13-07-2011 18:11, Stas Sergeev escreveu: > 14.07.2011 00:53, Mauro Carvalho Chehab wrote: >>> When pulseaudio enables the audio capturing, the >>> driver unmutes the sound. But, if no app have properly >>> tuned the tuner yet, you get the white noise. >>> I think the capturing must not touch the mute state, >>> because, without tuning the tuner first, you can't capture >>> anything anyway. >>> Without this patch I am getting the white noise on every >>> xorg/pulseaudio startup, which made me to always think >>> that pulseaudio is a joke and will soon be removed. :) >> Nack. We shouldn't patch a kernel driver due to an userspace bad behavior. > But I really think that the driver behaves badly here. > Suppose we had 2 separate mute switches: the input > mute, that mutes the signal as it just enters the saa > chip, and the output mute, that mutes only the output > of the tuner card, that is connected to the sound card's > line input. > With that configuration, we'd allow the alsa driver to > unmute only the input switch, so that it can record, but > leave the output switch still muted, so that the sound > not to come to the sound card directly. Well, on such configuration, there are, in fact, 4 mutes: the two ones you've mentioned, plus the sound card LINE IN mute and the sound card master output. The media drivers should control the input that belongs to saa7134. The userspace applications like pulseaudio should control the sound card volume/mute, but the driver should control the saa7134 mute/audio switch. > Now that we don't have the output mute switch, we > allow the alsa driver to unmute not only the recording > that it may need, but also the sound output that goes > to the sound card! IMHO, this is the entirely unwanted > side effect, so I blame the saa driver, and not the pulseaudio. Why this is unwanted? You shouldn't expect that the poor users to control each mute control. They just need to control one: the sound card outut. > There are also other things to consider: > 1. You can't record anything (except for the white noise) > before some xawtv sets up everything. So what is the > use-case of the current (mis)behaveur? If you're getting a white noise, then there's a bug either at xawtv, at the driver or both. It is likely board-specific, as, at least the last time I tested, saa7134 audio were working properly. > 2. The alsa driver, trying to manage the mute state on > its own, badly interwinds with the mute state of the > (xawtv) program. 2 programs cannot control the same > mute state for good, and of course the xawtv must have > the preference, as the alsa driver have no slightest > idea about the card's state. There's no sense on keeping the device unmuted after stop streaming. > 3. The problem is very severe. Hearing the loud white > noise on every startup is not something the human can > easily tolerate. So deferring it for the unknown period > is simply not very productive. As I said before, the white noise bug should be fixed. With what xawtv versions are you noticing problems? Are you using xawtv 3.101? If so, xawtv 3.101 assumes that you're using digital streams. Maybe your board entry is broken for digital streams. > > Can you please name a few downsides of the approach > I proposed? -- 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 1/9] stringify: add HEX_STRING()
On Wed, 13 Jul 2011 17:49:48 -0400 Arnaud Lacombe wrote: > Hi, > > On Sun, Jul 10, 2011 at 3:51 PM, Randy Dunlap wrote: > > From: Randy Dunlap > > > > Add HEX_STRING(value) to stringify.h so that drivers can > > convert kconfig hex values (without leading "0x") to useful > > hex constants. > > > > Several drivers/media/radio/ drivers need this. I haven't > > checked if any other drivers need to do this. > > > > Alternatively, kconfig could produce hex config symbols with > > leading "0x". > > > Actually, I used to have a patch to make hex value have a mandatory > "0x" prefix, in the Kconfig. I even fixed all the issue in the tree, > it never make it to the tree (not sure why). Here's the relevant > thread: > > https://patchwork.kernel.org/patch/380591/ > https://patchwork.kernel.org/patch/380621/ > https://patchwork.kernel.org/patch/380601/ > I prefer that this be fixed in kconfig, so long as it won't cause any other issues. That's why I mentioned it. > > > Signed-off-by: Randy Dunlap > > --- > > include/linux/stringify.h | 7 +++ > > 1 file changed, 7 insertions(+) > > > > NOTE: The other 8 patches are on lkml and linux-media mailing lists. > > > > --- linux-next-20110707.orig/include/linux/stringify.h > > +++ linux-next-20110707/include/linux/stringify.h > > @@ -9,4 +9,11 @@ > > #define __stringify_1(x...) #x > > #define __stringify(x...) __stringify_1(x) > > > > +/* > > + * HEX_STRING(value) is useful for CONFIG_ values that are in hex, > > + * but kconfig does not put a leading "0x" on them. > > + */ > > +#define HEXSTRINGVALUE(h, value) h##value > > +#define HEX_STRING(value) HEXSTRINGVALUE(0x, value) > > + > that seems hackish... It's a common idiom for concatenating strings in the kernel. How would you do it without (instead of) a kconfig fix/patch? > > #endif /* !__LINUX_STRINGIFY_H */ > > -- --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** -- 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] [media] imon: rate-limit send_packet spew
There are folks with flaky imon hardware out there that doesn't always
respond to requests to write to their displays for some reason, which
can flood logs quickly when something like lcdproc is trying to
constantly update the display, so lets rate-limit all that error spew.
Signed-off-by: Jarod Wilson
---
drivers/media/rc/imon.c | 25 +
1 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/media/rc/imon.c b/drivers/media/rc/imon.c
index 6bc35ee..ba48c1e 100644
--- a/drivers/media/rc/imon.c
+++ b/drivers/media/rc/imon.c
@@ -516,19 +516,19 @@ static int send_packet(struct imon_context *ictx)
if (retval) {
ictx->tx.busy = false;
smp_rmb(); /* ensure later readers know we're not busy */
- pr_err("error submitting urb(%d)\n", retval);
+ pr_err_ratelimited("error submitting urb(%d)\n", retval);
} else {
/* Wait for transmission to complete (or abort) */
mutex_unlock(&ictx->lock);
retval = wait_for_completion_interruptible(
&ictx->tx.finished);
if (retval)
- pr_err("task interrupted\n");
+ pr_err_ratelimited("task interrupted\n");
mutex_lock(&ictx->lock);
retval = ictx->tx.status;
if (retval)
- pr_err("packet tx failed (%d)\n", retval);
+ pr_err_ratelimited("packet tx failed (%d)\n", retval);
}
kfree(control_req);
@@ -830,20 +830,20 @@ static ssize_t vfd_write(struct file *file, const char
*buf,
ictx = file->private_data;
if (!ictx) {
- pr_err("no context for device\n");
+ pr_err_ratelimited("no context for device\n");
return -ENODEV;
}
mutex_lock(&ictx->lock);
if (!ictx->dev_present_intf0) {
- pr_err("no iMON device present\n");
+ pr_err_ratelimited("no iMON device present\n");
retval = -ENODEV;
goto exit;
}
if (n_bytes <= 0 || n_bytes > 32) {
- pr_err("invalid payload size\n");
+ pr_err_ratelimited("invalid payload size\n");
retval = -EINVAL;
goto exit;
}
@@ -869,7 +869,7 @@ static ssize_t vfd_write(struct file *file, const char *buf,
retval = send_packet(ictx);
if (retval) {
- pr_err("send packet failed for packet #%d\n", seq / 2);
+ pr_err_ratelimited("send packet #%d failed\n", seq / 2);
goto exit;
} else {
seq += 2;
@@ -883,7 +883,7 @@ static ssize_t vfd_write(struct file *file, const char *buf,
ictx->usb_tx_buf[7] = (unsigned char) seq;
retval = send_packet(ictx);
if (retval)
- pr_err("send packet failed for packet #%d\n", seq / 2);
+ pr_err_ratelimited("send packet #%d failed\n", seq / 2);
exit:
mutex_unlock(&ictx->lock);
@@ -912,20 +912,21 @@ static ssize_t lcd_write(struct file *file, const char
*buf,
ictx = file->private_data;
if (!ictx) {
- pr_err("no context for device\n");
+ pr_err_ratelimited("no context for device\n");
return -ENODEV;
}
mutex_lock(&ictx->lock);
if (!ictx->display_supported) {
- pr_err("no iMON display present\n");
+ pr_err_ratelimited("no iMON display present\n");
retval = -ENODEV;
goto exit;
}
if (n_bytes != 8) {
- pr_err("invalid payload size: %d (expected 8)\n", (int)n_bytes);
+ pr_err_ratelimited("invalid payload size: %d (expected 8)\n",
+ (int)n_bytes);
retval = -EINVAL;
goto exit;
}
@@ -937,7 +938,7 @@ static ssize_t lcd_write(struct file *file, const char *buf,
retval = send_packet(ictx);
if (retval) {
- pr_err("send packet failed!\n");
+ pr_err_ratelimited("send packet failed!\n");
goto exit;
} else {
dev_dbg(ictx->dev, "%s: write %d bytes to LCD\n",
--
1.7.1
--
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 1/9] stringify: add HEX_STRING()
Hi, On Sun, Jul 10, 2011 at 3:51 PM, Randy Dunlap wrote: > From: Randy Dunlap > > Add HEX_STRING(value) to stringify.h so that drivers can > convert kconfig hex values (without leading "0x") to useful > hex constants. > > Several drivers/media/radio/ drivers need this. I haven't > checked if any other drivers need to do this. > > Alternatively, kconfig could produce hex config symbols with > leading "0x". > Actually, I used to have a patch to make hex value have a mandatory "0x" prefix, in the Kconfig. I even fixed all the issue in the tree, it never make it to the tree (not sure why). Here's the relevant thread: https://patchwork.kernel.org/patch/380591/ https://patchwork.kernel.org/patch/380621/ https://patchwork.kernel.org/patch/380601/ - Arnaud > Signed-off-by: Randy Dunlap > --- > include/linux/stringify.h | 7 +++ > 1 file changed, 7 insertions(+) > > NOTE: The other 8 patches are on lkml and linux-media mailing lists. > > --- linux-next-20110707.orig/include/linux/stringify.h > +++ linux-next-20110707/include/linux/stringify.h > @@ -9,4 +9,11 @@ > #define __stringify_1(x...) #x > #define __stringify(x...) __stringify_1(x) > > +/* > + * HEX_STRING(value) is useful for CONFIG_ values that are in hex, > + * but kconfig does not put a leading "0x" on them. > + */ > +#define HEXSTRINGVALUE(h, value) h##value > +#define HEX_STRING(value) HEXSTRINGVALUE(0x, value) > + that seems hackish... > #endif /* !__LINUX_STRINGIFY_H */ > -- > To unsubscribe from this list: send the line "unsubscribe linux-kbuild" 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
[PATCH 3/3] [media] redrat3: improve compat with lirc userspace decode
This is admittedly a bit of a hack, but if we change our timeout value
to something longer and fudge our synthesized trailing space sample
based on the initial pulse sample, rc-core decode continues to work just
fine with both rc-6 and rc-5, and now lirc userspace decode shows proper
repeats for both of those protocols as well. Also tested NEC
successfully with both decode options.
We do still need a reset timer callback using the hardware's timeout
value to make sure we actually process samples correctly, regardless of
our somewhat hacky timeout and synthesized trailer above.
This also adds a missing del_timer_sync call to the module unload path.
CC: Chris Dodge
CC: Andrew Vincer
CC: Stephen Cox
Signed-off-by: Jarod Wilson
---
drivers/media/rc/redrat3.c | 43 ---
1 files changed, 24 insertions(+), 19 deletions(-)
diff --git a/drivers/media/rc/redrat3.c b/drivers/media/rc/redrat3.c
index 5312e34..5fc2f05 100644
--- a/drivers/media/rc/redrat3.c
+++ b/drivers/media/rc/redrat3.c
@@ -205,6 +205,7 @@ struct redrat3_dev {
/* rx signal timeout timer */
struct timer_list rx_timeout;
+ u32 hw_timeout;
/* Is the device currently receiving? */
bool recv_in_progress;
@@ -428,7 +429,7 @@ static void redrat3_process_ir_data(struct redrat3_dev *rr3)
DEFINE_IR_RAW_EVENT(rawir);
struct redrat3_signal_header header;
struct device *dev;
- int i;
+ int i, trailer = 0;
unsigned long delay;
u32 mod_freq, single_len;
u16 *len_vals;
@@ -454,7 +455,8 @@ static void redrat3_process_ir_data(struct redrat3_dev *rr3)
if (!(header.length >= RR3_HEADER_LENGTH))
dev_warn(dev, "read returned less than rr3 header len\n");
- delay = usecs_to_jiffies(rr3->rc->timeout / 1000);
+ /* Make sure we reset the IR kfifo after a bit of inactivity */
+ delay = usecs_to_jiffies(rr3->hw_timeout);
mod_timer(&rr3->rx_timeout, jiffies + delay);
memcpy(&tmp32, sig_data + RR3_PAUSE_OFFSET, sizeof(tmp32));
@@ -503,6 +505,9 @@ static void redrat3_process_ir_data(struct redrat3_dev *rr3)
rawir.pulse = true;
rawir.duration = US_TO_NS(single_len);
+ /* Save initial pulse length to fudge trailer */
+ if (i == 0)
+ trailer = rawir.duration;
/* cap the value to IR_MAX_DURATION */
rawir.duration &= IR_MAX_DURATION;
@@ -515,7 +520,10 @@ static void redrat3_process_ir_data(struct redrat3_dev
*rr3)
if (i % 2) {
rawir.pulse = false;
/* this duration is made up, and may not be ideal... */
- rawir.duration = rr3->rc->timeout / 2;
+ if (trailer < US_TO_NS(1000))
+ rawir.duration = US_TO_NS(2800);
+ else
+ rawir.duration = trailer;
rr3_dbg(dev, "storing trailing space with duration %d\n",
rawir.duration);
ir_raw_event_store_with_filter(rr3->rc, &rawir);
@@ -619,36 +627,31 @@ static inline void redrat3_delete(struct redrat3_dev *rr3,
kfree(rr3);
}
-static u32 redrat3_get_timeout(struct device *dev,
- struct rc_dev *rc, struct usb_device *udev)
+static u32 redrat3_get_timeout(struct redrat3_dev *rr3)
{
u32 *tmp;
- u32 timeout = MS_TO_NS(150); /* a sane default, if things go haywire */
+ u32 timeout = MS_TO_US(150); /* a sane default, if things go haywire */
int len, ret, pipe;
len = sizeof(*tmp);
tmp = kzalloc(len, GFP_KERNEL);
if (!tmp) {
- dev_warn(dev, "Memory allocation faillure\n");
+ dev_warn(rr3->dev, "Memory allocation faillure\n");
return timeout;
}
- pipe = usb_rcvctrlpipe(udev, 0);
- ret = usb_control_msg(udev, pipe, RR3_GET_IR_PARAM,
+ pipe = usb_rcvctrlpipe(rr3->udev, 0);
+ ret = usb_control_msg(rr3->udev, pipe, RR3_GET_IR_PARAM,
USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_IN,
RR3_IR_IO_SIG_TIMEOUT, 0, tmp, len, HZ * 5);
if (ret != len) {
- dev_warn(dev, "Failed to read timeout from hardware\n");
+ dev_warn(rr3->dev, "Failed to read timeout from hardware\n");
return timeout;
}
- timeout = US_TO_NS(redrat3_len_to_us(be32_to_cpu(*tmp)));
- if (timeout < rc->min_timeout)
- timeout = rc->min_timeout;
- else if (timeout > rc->max_timeout)
- timeout = rc->max_timeout;
+ timeout = redrat3_len_to_us(be32_to_cpu(*tmp));
- rr3_dbg(dev, "Got timeout of %d ms\n", timeout / (1000 * 1000));
+ rr3_dbg(rr3->dev, "Got timeout of %d ms\n", timeout / 1000);
return timeout;
}
@@ -1100,9 +1103,7 @@ static
[PATCH 2/3] [media] redrat3: cap duration in the right place
Trying to cap duration before multiplying it was obviously wrong. CC: Chris Dodge CC: Andrew Vincer CC: Stephen Cox Signed-off-by: Jarod Wilson --- drivers/media/rc/redrat3.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/media/rc/redrat3.c b/drivers/media/rc/redrat3.c index 9134254..5312e34 100644 --- a/drivers/media/rc/redrat3.c +++ b/drivers/media/rc/redrat3.c @@ -496,9 +496,6 @@ static void redrat3_process_ir_data(struct redrat3_dev *rr3) u16 val = len_vals[data_vals[i]]; single_len = redrat3_len_to_us((u32)be16_to_cpu(val)); - /* cap the value to IR_MAX_DURATION */ - single_len &= IR_MAX_DURATION; - /* we should always get pulse/space/pulse/space samples */ if (i % 2) rawir.pulse = false; @@ -506,6 +503,9 @@ static void redrat3_process_ir_data(struct redrat3_dev *rr3) rawir.pulse = true; rawir.duration = US_TO_NS(single_len); + /* cap the value to IR_MAX_DURATION */ + rawir.duration &= IR_MAX_DURATION; + rr3_dbg(dev, "storing %s with duration %d (i: %d)\n", rawir.pulse ? "pulse" : "space", rawir.duration, i); ir_raw_event_store_with_filter(rr3->rc, &rawir); -- 1.7.1 -- 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 1/3] [media] redrat3: sending extra trailing space was useless
We already add a trailing space, this wasn't doing anything useful, and
actually confused lirc userspace a bit. Rip it out.
CC: Chris Dodge
CC: Andrew Vincer
CC: Stephen Cox
Signed-off-by: Jarod Wilson
---
drivers/media/rc/redrat3.c | 12 +---
1 files changed, 1 insertions(+), 11 deletions(-)
diff --git a/drivers/media/rc/redrat3.c b/drivers/media/rc/redrat3.c
index 5147767..9134254 100644
--- a/drivers/media/rc/redrat3.c
+++ b/drivers/media/rc/redrat3.c
@@ -414,20 +414,10 @@ static u32 redrat3_us_to_len(u32 microsec)
}
-/* timer callback to send long trailing space on receive timeout */
+/* timer callback to send reset event */
static void redrat3_rx_timeout(unsigned long data)
{
struct redrat3_dev *rr3 = (struct redrat3_dev *)data;
- DEFINE_IR_RAW_EVENT(rawir);
-
- rawir.pulse = false;
- rawir.duration = rr3->rc->timeout;
- rr3_dbg(rr3->dev, "storing trailing space with duration %d\n",
- rawir.duration);
- ir_raw_event_store_with_filter(rr3->rc, &rawir);
-
- rr3_dbg(rr3->dev, "calling ir_raw_event_handle\n");
- ir_raw_event_handle(rr3->rc);
rr3_dbg(rr3->dev, "calling ir_raw_event_reset\n");
ir_raw_event_reset(rr3->rc);
--
1.7.1
--
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 0/3] redrat3 driver updates for 3.1
These changes make the redrat3 driver cooperate better with both in-kernel and lirc userspace decoding of signals, tested with RC5, RC6 and NEC. There's probably more we can do to make this a bit less hackish, but its working quite well here for me right now. Jarod Wilson (3): [media] redrat3: sending extra trailing space was useless [media] redrat3: cap duration in the right place [media] redrat3: improve compat with lirc userspace decode drivers/media/rc/redrat3.c | 61 --- 1 files changed, 28 insertions(+), 33 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
Re: [PATCH 1/9] stringify: add HEX_STRING()
On Wed, 13 Jul 2011 18:05:45 -0300 Mauro Carvalho Chehab wrote: > Em 10-07-2011 16:51, Randy Dunlap escreveu: > > From: Randy Dunlap > > > > Add HEX_STRING(value) to stringify.h so that drivers can > > convert kconfig hex values (without leading "0x") to useful > > hex constants. > > > > Several drivers/media/radio/ drivers need this. I haven't > > checked if any other drivers need to do this. > > > > Alternatively, kconfig could produce hex config symbols with > > leading "0x". > > Hi Randy, > > After applying patch 1/9 and 2/9 over 3.0-rc7+media patches, I'm > now getting this error: > > drivers/media/radio/radio-aimslab.c:52:1: error: invalid suffix "x20f" on > integer constant Hi Mauro, I built all of these drivers with my patches applied, but I'll see if I can find where this error is coming from. Thanks for checking & letting me know. > $ grep 20f .config > CONFIG_RADIO_RTRACK_PORT=20f > > $ gcc --version > gcc (GCC) 4.4.5 20110214 (Red Hat 4.4.5-6) > > Before this patch, this were working (or, at least, weren't producing > any error). > > Perhaps the breakage on your compilation happened due to another > patch at the tree? If so, the better would be to apply this patch > series together with the ones that caused the breakage, to avoid > bisect troubles. > > > > > Signed-off-by: Randy Dunlap > > --- > > include/linux/stringify.h |7 +++ > > 1 file changed, 7 insertions(+) > > > > NOTE: The other 8 patches are on lkml and linux-media mailing lists. > > > > --- linux-next-20110707.orig/include/linux/stringify.h > > +++ linux-next-20110707/include/linux/stringify.h > > @@ -9,4 +9,11 @@ > > #define __stringify_1(x...)#x > > #define __stringify(x...) __stringify_1(x) > > > > +/* > > + * HEX_STRING(value) is useful for CONFIG_ values that are in hex, > > + * but kconfig does not put a leading "0x" on them. > > + */ > > +#define HEXSTRINGVALUE(h, value) h##value > > +#define HEX_STRING(value) HEXSTRINGVALUE(0x, value) > > + > > #endif /* !__LINUX_STRINGIFY_H */ > > -- --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** -- 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
14.07.2011 00:53, Mauro Carvalho Chehab wrote: When pulseaudio enables the audio capturing, the driver unmutes the sound. But, if no app have properly tuned the tuner yet, you get the white noise. I think the capturing must not touch the mute state, because, without tuning the tuner first, you can't capture anything anyway. Without this patch I am getting the white noise on every xorg/pulseaudio startup, which made me to always think that pulseaudio is a joke and will soon be removed. :) Nack. We shouldn't patch a kernel driver due to an userspace bad behavior. But I really think that the driver behaves badly here. Suppose we had 2 separate mute switches: the input mute, that mutes the signal as it just enters the saa chip, and the output mute, that mutes only the output of the tuner card, that is connected to the sound card's line input. With that configuration, we'd allow the alsa driver to unmute only the input switch, so that it can record, but leave the output switch still muted, so that the sound not to come to the sound card directly. Now that we don't have the output mute switch, we allow the alsa driver to unmute not only the recording that it may need, but also the sound output that goes to the sound card! IMHO, this is the entirely unwanted side effect, so I blame the saa driver, and not the pulseaudio. There are also other things to consider: 1. You can't record anything (except for the white noise) before some xawtv sets up everything. So what is the use-case of the current (mis)behaveur? 2. The alsa driver, trying to manage the mute state on its own, badly interwinds with the mute state of the (xawtv) program. 2 programs cannot control the same mute state for good, and of course the xawtv must have the preference, as the alsa driver have no slightest idea about the card's state. 3. The problem is very severe. Hearing the loud white noise on every startup is not something the human can easily tolerate. So deferring it for the unknown period is simply not very productive. Can you please name a few downsides of the approach I proposed? -- 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 v2] [media] rc-core support for Microsoft IR keyboard/mouse
This is a custom IR protocol decoder, for the RC-6-ish protocol used by the Microsoft Remote Keyboard, apparently developed internally at Microsoft, and officially dubbed MCIR-2, per their March 2011 remote and transceiver requirements and specifications document, which also touches on this IR keyboard/mouse device. http://www.amazon.com/Microsoft-Remote-Keyboard-Windows-ZV1-4/dp/B000AOAAN8 Its a standard keyboard with embedded thumb stick mouse pointer and mouse buttons, along with a number of media keys. The media keys are standard RC-6, identical to the signals from the stock MCE remotes, and will be handled as such. The keyboard and mouse signals will be decoded and delivered to the system by an input device registered specifically by this driver. Successfully tested with multiple mceusb-driven transceivers, as well as with fintek-cir and redrat3 hardware. Essentially, any raw IR hardware with enough sampling resolution should be able to use this decoder, nothing about it is at all receiver-hardware-specific. This work is inspired by lirc_mod_mce: http://mod-mce.sourceforge.net/ The documentation there and code aided in understanding and decoding the protocol, but the bulk of the code is actually borrowed more from the existing in-kernel decoders than anything. I did recycle the keyboard keycode table, a few defines, and some of the keyboard and mouse data parsing bits from lirc_mod_mce though. Special thanks to James Meyer for providing the hardware, and being patient with me as I took forever to get around to writing this. v2: now know its MCIR-2, updated accordingly, added a key release timer callback routine to ensure we don't get any stuck keys, and used symbolic names for the keytable. Also cc'ing Florian this time, who I believe is the original mod-mce author... CC: Florian Demski Signed-off-by: Jarod Wilson --- drivers/media/rc/Kconfig | 11 + drivers/media/rc/Makefile |1 + drivers/media/rc/ir-mce_kbd-decoder.c | 448 + drivers/media/rc/ir-raw.c |1 + drivers/media/rc/rc-core-priv.h | 18 ++ drivers/media/rc/rc-main.c|1 + include/media/rc-map.h|3 +- 7 files changed, 482 insertions(+), 1 deletions(-) create mode 100644 drivers/media/rc/ir-mce_kbd-decoder.c diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig index 7d4bbc2..899f783 100644 --- a/drivers/media/rc/Kconfig +++ b/drivers/media/rc/Kconfig @@ -87,6 +87,17 @@ config IR_RC5_SZ_DECODER uses an IR protocol that is almost standard RC-5, but not quite, as it uses an additional bit). +config IR_MCE_KBD_DECODER + tristate "Enable IR raw decoder for the MCE keyboard/mouse protocol" + depends on RC_CORE + select BITREVERSE + default y + + ---help--- + Enable this option if you have a Microsoft Remote Keyboard for + Windows Media Center Edition, which you would like to use with + a raw IR receiver in your system. + config IR_LIRC_CODEC tristate "Enable IR to LIRC bridge" depends on RC_CORE diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile index 52830e5..f224db0 100644 --- a/drivers/media/rc/Makefile +++ b/drivers/media/rc/Makefile @@ -10,6 +10,7 @@ obj-$(CONFIG_IR_RC6_DECODER) += ir-rc6-decoder.o obj-$(CONFIG_IR_JVC_DECODER) += ir-jvc-decoder.o obj-$(CONFIG_IR_SONY_DECODER) += ir-sony-decoder.o obj-$(CONFIG_IR_RC5_SZ_DECODER) += ir-rc5-sz-decoder.o +obj-$(CONFIG_IR_MCE_KBD_DECODER) += ir-mce_kbd-decoder.o obj-$(CONFIG_IR_LIRC_CODEC) += ir-lirc-codec.o # stand-alone IR receivers/transmitters diff --git a/drivers/media/rc/ir-mce_kbd-decoder.c b/drivers/media/rc/ir-mce_kbd-decoder.c new file mode 100644 index 000..fe96e54 --- /dev/null +++ b/drivers/media/rc/ir-mce_kbd-decoder.c @@ -0,0 +1,448 @@ +/* ir-mce_kbd-decoder.c - A decoder for the RC6-ish keyboard/mouse IR protocol + * used by the Microsoft Remote Keyboard for Windows Media Center Edition, + * referred to by Microsoft's Windows Media Center remote specification docs + * as "an internal protocol called MCIR-2". + * + * Copyright (C) 2011 by Jarod Wilson + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation version 2 of the License. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include "rc-core-priv.h" + +/* + * This decoder currently supports: + * - MCIR-2 29-bit IR signals used for mouse movement and buttons + * - MCIR-2 32-bit IR signals used for standard keyboard keys + * + * The media keys on the keyboard send RC-6 signals that are inditinguishable + * from the keys of
Re: [PATCH 1/9] stringify: add HEX_STRING()
Em 10-07-2011 16:51, Randy Dunlap escreveu: > From: Randy Dunlap > > Add HEX_STRING(value) to stringify.h so that drivers can > convert kconfig hex values (without leading "0x") to useful > hex constants. > > Several drivers/media/radio/ drivers need this. I haven't > checked if any other drivers need to do this. > > Alternatively, kconfig could produce hex config symbols with > leading "0x". Hi Randy, After applying patch 1/9 and 2/9 over 3.0-rc7+media patches, I'm now getting this error: drivers/media/radio/radio-aimslab.c:52:1: error: invalid suffix "x20f" on integer constant $ grep 20f .config CONFIG_RADIO_RTRACK_PORT=20f $ gcc --version gcc (GCC) 4.4.5 20110214 (Red Hat 4.4.5-6) Before this patch, this were working (or, at least, weren't producing any error). Perhaps the breakage on your compilation happened due to another patch at the tree? If so, the better would be to apply this patch series together with the ones that caused the breakage, to avoid bisect troubles. > > Signed-off-by: Randy Dunlap > --- > include/linux/stringify.h |7 +++ > 1 file changed, 7 insertions(+) > > NOTE: The other 8 patches are on lkml and linux-media mailing lists. > > --- linux-next-20110707.orig/include/linux/stringify.h > +++ linux-next-20110707/include/linux/stringify.h > @@ -9,4 +9,11 @@ > #define __stringify_1(x...) #x > #define __stringify(x...)__stringify_1(x) > > +/* > + * HEX_STRING(value) is useful for CONFIG_ values that are in hex, > + * but kconfig does not put a leading "0x" on them. > + */ > +#define HEXSTRINGVALUE(h, value) h##value > +#define HEX_STRING(value)HEXSTRINGVALUE(0x, value) > + > #endif /* !__LINUX_STRINGIFY_H */ -- 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] media, Micronas dvb-t: Fix mem leaks, don't needlessly zero mem, fix spelling
In drivers/media/dvb/frontends/drxd_hard.c::load_firmware() I see 3
small issues:
1) When the 'fw' variable goes out of scope we'll leak the memory
allocated to it by request_firmware() by neglecting to call
release_firmware().
2) After a successful request_firmware() we allocate fw->size bytes
of memory using kzalloc() only to immediately overwrite all that
memory with memcpy(), so asking for zeroed memory seems like wasted
effort - just use kmalloc().
3) In one of the error messages "no memory" lacks a space and is
written as "nomemory".
This patch fixes all 3 issues.
Signed-off-by: Jesper Juhl
---
drivers/media/dvb/frontends/drxd_hard.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/media/dvb/frontends/drxd_hard.c
b/drivers/media/dvb/frontends/drxd_hard.c
index f132e49..0266a83 100644
--- a/drivers/media/dvb/frontends/drxd_hard.c
+++ b/drivers/media/dvb/frontends/drxd_hard.c
@@ -909,14 +909,16 @@ static int load_firmware(struct drxd_state *state, const
char *fw_name)
return -EIO;
}
- state->microcode = kzalloc(fw->size, GFP_KERNEL);
+ state->microcode = kmalloc(fw->size, GFP_KERNEL);
if (state->microcode == NULL) {
- printk(KERN_ERR "drxd: firmware load failure: nomemory\n");
+ release_firmware(fw);
+ printk(KERN_ERR "drxd: firmware load failure: no memory\n");
return -ENOMEM;
}
memcpy(state->microcode, fw->data, fw->size);
state->microcode_length = fw->size;
+ release_firmware(fw);
return 0;
}
--
1.7.6
--
Jesper Juhlhttp://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.
--
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] [media] rc-rc6-mce: minor keymap updates
Microsoft's Windows Media Center specification and requirements doc from
2011.03.18 now refers to the former Power Toggle button as the Sleep
Toggle, and recommends using a new moon sleep icon for it. Its the same
key, but its apparently always been meant to put the system to sleep,
not power it off. Adjust accordingly. While we're here, lets also remove
the duplicate KEY_PLAYPAUSE entry.
Signed-off-by: Jarod Wilson
---
drivers/media/rc/keymaps/rc-rc6-mce.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/media/rc/keymaps/rc-rc6-mce.c
b/drivers/media/rc/keymaps/rc-rc6-mce.c
index 01b69bc..c3907e2 100644
--- a/drivers/media/rc/keymaps/rc-rc6-mce.c
+++ b/drivers/media/rc/keymaps/rc-rc6-mce.c
@@ -29,7 +29,7 @@ static struct rc_map_table rc6_mce[] = {
{ 0x800f040a, KEY_DELETE },
{ 0x800f040b, KEY_ENTER },
- { 0x800f040c, KEY_POWER }, /* PC Power */
+ { 0x800f040c, KEY_SLEEP }, /* Formerly PC Power */
{ 0x800f040d, KEY_MEDIA }, /* Windows MCE button */
{ 0x800f040e, KEY_MUTE },
{ 0x800f040f, KEY_INFO },
@@ -44,7 +44,6 @@ static struct rc_map_table rc6_mce[] = {
{ 0x800f0416, KEY_PLAY },
{ 0x800f0417, KEY_RECORD },
{ 0x800f0418, KEY_PAUSE },
- { 0x800f046e, KEY_PLAYPAUSE },
{ 0x800f0419, KEY_STOP },
{ 0x800f041a, KEY_NEXT },
{ 0x800f041b, KEY_PREVIOUS },
--
1.7.1
--
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 10-07-2011 13:27, Stas Sergeev escreveu: > Hi. > > When pulseaudio enables the audio capturing, the > driver unmutes the sound. But, if no app have properly > tuned the tuner yet, you get the white noise. > I think the capturing must not touch the mute state, > because, without tuning the tuner first, you can't capture > anything anyway. > Without this patch I am getting the white noise on every > xorg/pulseaudio startup, which made me to always think > that pulseaudio is a joke and will soon be removed. :) Nack. We shouldn't patch a kernel driver due to an userspace bad behavior. I've pinged Lennart about that and he is suggesting that we should use a non-standard name for the controls, in order to avoid pulseaudio to touch on them. We need first to double check if applications like tvtime and xawtv will work with a different name for the audio volumes. If the existing apps are ok, then maybe all we need to do is to rename all media volumes as something like " Grabber" or " V4L". Cheers, 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: Gigabyte 8300
Devin Heitmueller kernellabs.com> writes: > > On Fri, Sep 3, 2010 at 12:01 PM, Andy Walls md.metrocast.net> wrote: > > On Fri, 2010-09-03 at 10:55 +, Dagur Ammendrup wrote: > >> I tried it on a windows machine where it's identified as "Conextant > >> Polaris Video Capture" or > >> "oem17.inf:Conexant.NTx86:POLARIS.DVBTX.x86:6.113.1125.1210:usb\vid_1b80&pid_d41 6&mi_01" > >> if that tells you anything. > > > > > > Polaris refers to the series of CX2310[012] chips IIRC. > > > > Support would need changes to the cx231xx driver, and possibly changes > > to the cx25480 module, depending on how far the board differs from > > Conexant reference designs. > > I've been working with Conexant on this, and have their current tree here: > > https://www.kernellabs.com/hg/~dheitmueller/polaris4/ > > So if you feel the urge to do any new device support, I would suggest > using this as a starting point. > > Devin > Hello everyone, I'd like to refresh a little this thread as I have also bought this device and I'm willing to donate my time to make it working with Linux. The bad news is that I am not familiar with Linux API (and device programming at all), so I can only offer myself for testing and gathering informations. I have taken two high resolution pictures of this board. As you (propably) know, it has 3 chips: - Conexant 23102-11Z - Conexant 24232-11Z - NXP TDA18271 HDC2 The board is labeled UD412 if it makes any sense. Pictures are on Picasa account: https://picasaweb.google.com/kamilkaminski000/GigabyteU8300? authuser=0&authkey=Gv1sRgCID_5oOcsdXRpwE&feat=directlink Both are 10MPix, you can zoom-in. Device is still not recognized on Gentoo with 2.6.39-r3 (2.6.39.3) kernel. It has same vendor id and device id (1b80:d416). I have seen that there are drivers ready for tuner and for conexant chip. Is it really a problem to put them together? I do not know where to start, and this thread is the only one Google shows. I do not understand also the last message on thread, I have checked kernellabs code, but haven't seen my device in USB devices table for cx231xx. No cx2432 also. Best regards, Kamil Kaminski -- 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 2/3] Document 8-bit and 16-bit YCrCb media bus pixel codes
2011/7/11 Christian Gmeiner : > Hi Laurent, > > 2011/7/11 Laurent Pinchart : >> Hi Christian, >> >> On Sunday 10 July 2011 20:14:21 Christian Gmeiner wrote: >>> Signed-off-by: Christian Gmeiner >>> --- >>> diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml >>> b/Documentation/DocBook/media/v4l/subdev-formats.xml >>> index 49c532e..18e30b0 100644 >>> --- a/Documentation/DocBook/media/v4l/subdev-formats.xml >>> +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml >>> @@ -2565,5 +2565,43 @@ >>> >>> >>> >>> + >>> + >>> + YCrCb Formats >>> + >>> + YCbCr represents colors as a combination of three values: >>> + >>> + Y - the luminosity (roughly the >>> brightness) >>> + Cb - the chrominance of the blue >>> primary >>> + Cr - the chrominance of the red >>> primary >> >> How does that differ from YUV ? > > > I need to say that I am very new to this whole format stuff and so I > am not really sure. > In the data sheet > http://dxr3.sourceforge.net/download/hardware/ADV7175A_6A.pdf there is > on the > first page a FUNCTIONAL BLOCK DIAGRAM which shows that there is a > "YCrCb to YUV Matrix" > stage in the pipeline. I am also fine to use a YUV format for the media bus. > Any suggestions? Okay I think I have found the difference between YUV and YCrCb - see [1] YCbCr 4:2:2 (Redirected from YUV 4:2:2) FourCCs: YUY2, UYVY, YUV2 (Apple Component Video stored in MOV files) Samples: http://samples.mplayerhq.hu/V-codecs/YUV2/ (These FourCC names only reflect that the YCbCr of digital media is often falsely mixed up with analog PAL's YUV color space.) YCbCr 4:2:2 is a packed YCbCr format in which a pair of consecutive pixels is represented by 1 Y sample each but share a Cb sample and a Cr sample. This type of data may be packaged in a container format with a a FourCC of YUY2 which indicates the following byte formatting: [1] http://wiki.multimedia.cx/index.php?title=YUV_4:2:2 Greets, -- Christian Gmeiner, MSc -- 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: [RFC PATCH 1/8] davinci: vpfe: add dm3xx IPIPEIF hardware support module
Hi Manju,
Thanks for the patchset!
I have a few comments on this patch below. I haven't read the rest of the
patches yet so I may have more comments on this one when I do that.
On Thu, Jun 30, 2011 at 06:43:10PM +0530, Manjunath Hadli wrote:
> add support for dm3xx IPIPEIF hardware setup. This is the
> lowest software layer for the dm3x vpfe driver which directly
> accesses hardware. Add support for features like default
> pixel correction, dark frame substraction and hardware setup.
>
> Signed-off-by: Manjunath Hadli
> Signed-off-by: Nagabhushana Netagunte
> ---
> drivers/media/video/davinci/dm3xx_ipipeif.c | 368
> +++
> include/media/davinci/dm3xx_ipipeif.h | 292 +
> 2 files changed, 660 insertions(+), 0 deletions(-)
> create mode 100644 drivers/media/video/davinci/dm3xx_ipipeif.c
> create mode 100644 include/media/davinci/dm3xx_ipipeif.h
>
> diff --git a/drivers/media/video/davinci/dm3xx_ipipeif.c
> b/drivers/media/video/davinci/dm3xx_ipipeif.c
> new file mode 100644
> index 000..36cb61b
> --- /dev/null
> +++ b/drivers/media/video/davinci/dm3xx_ipipeif.c
> @@ -0,0 +1,368 @@
> +/*
> +* Copyright (C) 2011 Texas Instruments Inc
> +*
> +* This program is free software; you can redistribute it and/or
> +* modify it under the terms of the GNU General Public License as
> +* published by the Free Software Foundation version 2.
> +*
> +* This program is distributed in the hope that it will be useful,
> +* but WITHOUT ANY WARRANTY; without even the implied warranty of
> +* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> +* GNU General Public License for more details.
> +*
> +* You should have received a copy of the GNU General Public License
> +* along with this program; if not, write to the Free Software
> +* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> +*
> +* ipipe module to hold common functionality across DM355 and DM365
> +*/
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define DM3550
> +#define DM3651
> +
> +static void *__iomem ipipeif_base_addr;
This looks device specific. What about using dev_set/get_drvdata and remove
this one?
> +static int device_type;
Ditto. Both should be in a device specific struct.
> +static inline u32 regr_if(u32 offset)
> +{
> + return readl(ipipeif_base_addr + offset);
> +}
> +
> +static inline void regw_if(u32 val, u32 offset)
> +{
> + writel(val, ipipeif_base_addr + offset);
> +}
> +
> +void ipipeif_set_enable(char en, unsigned int mode)
> +{
> + regw_if(1, IPIPEIF_ENABLE);
> +}
> +
> +u32 ipipeif_get_enable(void)
> +{
> + return regr_if(IPIPEIF_ENABLE);
> +}
> +
> +int ipipeif_set_address(struct ipipeif *params, unsigned int address)
> +{
If address is a value for a register you should use u32.
> + unsigned int val1;
> + unsigned int val;
> +
> + if (params->source != 0) {
> + val = ((params->adofs >> 5) & IPIPEIF_ADOFS_LSB_MASK);
> + regw_if(val, IPIPEIF_ADOFS);
You may do without val as well.
> + /* lower sixteen bit */
> + val = ((address >> IPIPEIF_ADDRL_SHIFT) & IPIPEIF_ADDRL_MASK);
> + regw_if(val, IPIPEIF_ADDRL);
> +
> + /* upper next seven bit */
> + val1 =
> + ((address >> IPIPEIF_ADDRU_SHIFT) & IPIPEIF_ADDRU_MASK);
> + regw_if(val1, IPIPEIF_ADDRU);
> + } else
> + return -1;
What's -1? If this is an error, Ex codes should be used.
The error check should become first and the rest of the function may be
unindented by one tab stop.
> + return 0;
> +}
> +
> +static void ipipeif_config_dpc(struct ipipeif_dpc *dpc)
> +{
> + u32 val;
> +
> + if (dpc->en) {
> + val = ((dpc->en & 1) << IPIPEIF_DPC2_EN_SHIFT);
> + val |= (dpc->thr & IPIPEIF_DPC2_THR_MASK);
> + } else
> + val = 0;
> +
> + regw_if(val, IPIPEIF_DPC2);
> +}
> +
> +/* This function sets up IPIPEIF and is called from
> + * ipipe_hw_setup()
> + */
> +int ipipeif_hw_setup(struct ipipeif *params)
> +{
> + enum v4l2_mbus_pixelcode isif_port_if;
> + unsigned int val1 = 0x7;
7 looks like a magic number.
> + unsigned int val;
> +
> + if (NULL == params)
> + return -1;
Same here, and I can also see elsewhere.
> + /* Enable clock to IPIPEIF and IPIPE */
> + if (device_type == DM365)
> + vpss_enable_clock(VPSS_IPIPEIF_CLOCK, 1);
> +
> + /* Combine all the fields to make CFG1 register of IPIPEIF */
> + val = params->mode << ONESHOT_SHIFT;
> + val |= params->source << INPSRC_SHIFT;
> + val |= params->clock_select << CLKSEL_SHIFT;
> + val |= params->avg_filter << AVGFILT_SHIFT;
> + val |= params->decimation << DECIM_SHIFT;
> +
> + if (device_type == DM355) {
> + val |= params->var.if_base.ialaw << IALAW_SHIFT;
> + val |= params->va
[RFC v1] mt9v113: VGA camera sensor driver and support for BeagleBoard
* Adds support for mt9v113 sensor by borrowing heavily from PSP 2.6.37 kernel
patches
* Adapted to changes in v4l2 framework and ISP driver
Signed-off-by: Joel A Fernandes
---
This patch will apply against the 2.6.39 kernel built from the OE-development
tree (Which is essentially
the v2.6.39 from the main tree with OE patches for BeagleBoard support and a
few other features)
If you have the Leapord imaging camera board with this particular sensor, I
would apprecite it if anyone could
try this patch out and provide any feedback/test results.
To get the complete tree which works on a BeagleBoard-xM with all the OE
patches and this patch,
you can clone:
https://github.com/joelagnel/linux-omap-2.6/tree/oedev-2.6.39-mt9v113
It will compile and work on a BeagleBoard-xM with the defconfig at:
http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/linux/linux-omap-2.6.39/beagleboard/defconfig
Also you will need to apply my media-ctl patch (or clone the tree) to setup the
formats:
https://github.com/joelagnel/media-ctl/commit/cdf24d1249ac1ff3cd6f70ad80c3b76ac28ba0d5
Binaries for quick testing on a BeagleBoard-xM:
U-boot: http://utdallas.edu/~joel.fernandes/u-boot.bin
U-boot: http://utdallas.edu/~joel.fernandes/MLO
uEnv.txt: http://utdallas.edu/~joel.fernandes/uEnv.txt
media-ctl: http://utdallas.edu/~joel.fernandes/media-ctl
kernel: http://utdallas.edu/~joel.fernandes/uImage
media-ctl/yavta commands you could use to get it to show a picture can be found
at:
http://utdallas.edu/~joel.fernandes/stream.sh
Note:
The BeagleBoard camera board file in this patch replaces the old one, so this
will take away support for the 5M
sensor (mt9p031), I hope this can be forgiven considering this is an RFC :). I
am working on a common board file
that will work for both sensors.
arch/arm/mach-omap2/board-omap3beagle-camera.c | 218 --
drivers/media/video/Kconfig|7 +
drivers/media/video/Makefile |1 +
drivers/media/video/mt9v113.c | 1027
drivers/media/video/mt9v113_regs.h | 294 +++
drivers/media/video/omap3isp/ispccdc.c | 10 +-
drivers/media/video/omap3isp/ispvideo.c|7 +-
include/media/mt9v113.h| 70 ++
include/media/v4l2-chip-ident.h|1 +
9 files changed, 1577 insertions(+), 58 deletions(-)
create mode 100644 drivers/media/video/mt9v113.c
create mode 100644 drivers/media/video/mt9v113_regs.h
create mode 100644 include/media/mt9v113.h
diff --git a/arch/arm/mach-omap2/board-omap3beagle-camera.c
b/arch/arm/mach-omap2/board-omap3beagle-camera.c
index 2632557..3d3ae53 100644
--- a/arch/arm/mach-omap2/board-omap3beagle-camera.c
+++ b/arch/arm/mach-omap2/board-omap3beagle-camera.c
@@ -1,95 +1,203 @@
-#include
-#include
+/*
+ * BeagleXM: Driver for Leopard Module Board
+ *
+ * Copyright (C) 2011 Texas Instruments Inc
+ * Author: Vaibhav Hiremath
+ *
+ * This package is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+
+#include <../drivers/media/video/omap3isp/isp.h>
-#include
-
-#include
-#include
#include "devices.h"
-#include "../../../drivers/media/video/omap3isp/isp.h"
-#define MT9P031_RESET_GPIO 98
-#define MT9P031_XCLK ISP_XCLK_A
+#define CAM_USE_XCLKA 1
+#define LEOPARD_RESET_GPIO 98
+
+static struct regulator *beagle_1v8;
+static struct regulator *beagle_2v8;
-static struct regulator *reg_1v8, *reg_2v8;
+#define debg(msg) printk(KERN_ERR "BB Debug: " #msg)
-static int beagle_cam_set_xclk(struct v4l2_subdev *subdev, int hz)
+static int beagle_mt9v113_s_power(struct v4l2_subdev *subdev, int on)
{
struct isp_device *isp = v4l2_dev_to_isp_device(subdev->v4l2_dev);
- int ret;
- ret = isp->platform_cb.set_xclk(isp, hz, MT9P031_XCLK);
+ if (!beagle_1v8 || !beagle_2v8) {
+ dev_err(isp->dev, "No regulator available\n");
+ return -ENODEV;
+ }
+ if (on) {
+ debg(Powering on);
+ /*
+* Power Up Sequence
+*/
+ /* Set RESET_BAR to 0 */
+ gpio_set_value(LEOPARD_RESET_GPIO, 0);
+ /* Turn on VDD */
+ debg(Regulator 1v8 switching on);
+
[cron job] v4l-dvb daily build: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Wed Jul 13 19:00:39 CEST 2011 git hash:b0ee37889c11650f3df3417f3887f0a49b5fda5c gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 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: WARNINGS 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-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 spec-git: ERRORS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.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: [PATCH] uvcvideo: add fix suspend/resume quirk for Microdia camera
On Wed, 13 Jul 2011, Ming Lei wrote: > Hi, > > On Wed, Jul 13, 2011 at 11:20 PM, Alan Stern > wrote: > > > Why should system suspend be different from runtime suspend? �Have you > > This is also my puzzle, :-) > > > compared usbmon traces for the two types of suspend? > > Almost same. Come on. "Almost same" means they are different. That difference is clearly the important thing you need to track down. > If I add USB_QUIRK_RESET_RESUME quirk for the device, > the stream data will not be received from the device in runtime pm case, > same with that in system suspend. uvcvideo should be able to reinitialize the device so that it works correctly following a reset. If the device doesn't work then uvcvideo has a bug in its reset_resume handler. > Maybe buggy BIOS makes root hub send reset signal to the device during > system suspend time, not sure... That's entirely possible. Alan Stern -- 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] uvcvideo: add fix suspend/resume quirk for Microdia camera
Hi, On Wed, Jul 13, 2011 at 11:20 PM, Alan Stern wrote: > Why should system suspend be different from runtime suspend? Have you This is also my puzzle, :-) > compared usbmon traces for the two types of suspend? Almost same. If I add USB_QUIRK_RESET_RESUME quirk for the device, the stream data will not be received from the device in runtime pm case, same with that in system suspend. Maybe buggy BIOS makes root hub send reset signal to the device during system suspend time, not sure... thanks, -- Ming Lei -- 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] uvcvideo: add fix suspend/resume quirk for Microdia camera
On Wed, 13 Jul 2011, Ming Lei wrote: > Hi, > > On Tue, Jul 12, 2011 at 11:44 PM, Alan Stern > wrote: > > On Tue, 12 Jul 2011, Ming Lei wrote: > > > >> Hi Laurent, > >> > >> After resume from sleep, �all the ISO packets from camera are like below: > >> > >> 880122d9f400 3527230728 S Zi:1:004:1 -115:1:2568 32 -18:0:1600 > >> -18:1600:1600 -18:3200:1600 -18:4800:1600 -18:6400:1600 51200 < > >> 880122d9d400 3527234708 C Zi:1:004:1 0:1:2600:0 32 0:0:12 > >> 0:1600:12 0:3200:12 0:4800:12 0:6400:12 51200 = 0c8c fa7e > >> 012f1b05 > >> > >> All are headed with 0c8c, see attached usbmon captures. > > > > Maybe this device needs a USB_QUIRK_RESET_RESUME entry in quirks.c. > > I will try it, but seems unbind&bind driver don't produce extra usb reset > signal > to the device. > > Also, the problem didn't happen in runtime pm case, just happen in > wakeup from system suspend case. uvcvideo has enabled auto suspend > already at default. Why should system suspend be different from runtime suspend? Have you compared usbmon traces for the two types of suspend? Alan Stern -- 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] [media] tea5764: Fix module parameter permissions
Em 11-07-2011 09:25, Fabio Belavenuto escreveu:
> Hi,
>
> I'm the author. Sorry for my bad english, I'm from Brazil. :D
>
> Yes, the intent of the "1" is to set the default value, in case
> compile built-in.
>
> I like the module to be generic, decided to choose enabled by default.
>
> Fábio
>
> 2011/7/11 Jean Delvare :
>> Hi Andy,
>>
>> On Friday 08 July 2011 12:34:38 pm Andy Walls wrote:
>>> Jean Delvare wrote:
The third parameter of module_param is supposed to represent sysfs
file permissions. A value of "1" leads to the following:
$ ls -l /sys/module/radio_tea5764/parameters/
total 0
-x 1 root root 4096 Jul 8 09:17 use_xtal
I am changing it to "0" to align with the other module parameters in
this driver.
Signed-off-by: Jean Delvare
Cc: Mauro Carvalho Chehab
Cc: Fabio Belavenuto
---
drivers/media/radio/radio-tea5764.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
---
linux-3.0-rc6.orig/drivers/media/radio/radio-tea5764.c 2011-05-20
10:41:19.0 +0200
+++ linux-3.0-rc6/drivers/media/radio/radio-tea5764.c2011-07-08
09:15:16.0 +0200
@@ -596,7 +596,7 @@ MODULE_AUTHOR(DRIVER_AUTHOR);
MODULE_DESCRIPTION(DRIVER_DESC);
MODULE_LICENSE("GPL");
-module_param(use_xtal, int, 1);
+module_param(use_xtal, int, 0);
MODULE_PARM_DESC(use_xtal, "Chip have a xtal connected in board");
module_param(radio_nr, int, 0);
MODULE_PARM_DESC(radio_nr, "video4linux device number to use");
>>>
>>> To whomever might know:
>>>
>>> Was the intent of the "1" to set the default value of the parameter?
>>
>> My guess is yes, and as a matter of fact 1 is indeed the default value
>> of use_xtal. Only the author of the code (Fabio Belavenuto) could tell
>> for sure, but he seems to be no longer involved so I wouldn't wait for
>> him.
The value there is not the default value, but the permissions. From what
I understand, the xtal frequency should be set at boot time, so setting
it to 000 seems to do the work. So, I'm applying Jean's patch.
>>
>> --
>> Jean Delvare
>> Suse L3
>>
> --
> 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
USB DVR BOX - name AXD USB04V2A-T
Ubuntu 11.04 siedar@haven:~$ uname -a Linux haven 2.6.38-10-generic #46-Ubuntu SMP Tue Jun 28 15:05:41 UTC 2011 i686 i686 i386 GNU/Linux This card have 4xVideo, 2xaudio, 25cl/s H.264 Is not recognized by system. Darek [12033.092138] usb 1-3: new high speed USB device using ehci_hcd and address 6 [12033.273017] IR NEC protocol handler initialized [12033.276725] IR RC5(x) protocol handler initialized [12033.287991] Linux video capture interface: v2.00 [12033.294909] IR RC6 protocol handler initialized [12033.299655] IR JVC protocol handler initialized [12033.304295] IR Sony protocol handler initialized [12033.307742] em28xx: New device USB CAP Device @ 480 Mbps (eb1a:2861, interface 0, class 0) [12033.308732] em28xx #0: chip ID is em2860 [12033.312154] lirc_dev: IR Remote Control driver registered, major 249 [12033.314257] IR LIRC bridge handler initialized [12033.442096] em28xx #0: i2c eeprom 00: 1a eb 67 95 1a eb 61 28 d0 00 20 03 6a 20 00 00 [12033.442129] em28xx #0: i2c eeprom 10: 00 00 04 57 06 02 00 00 00 00 00 00 00 00 00 00 [12033.442159] em28xx #0: i2c eeprom 20: 02 00 01 00 f0 10 01 00 88 00 00 00 5b 00 00 00 [12033.442189] em28xx #0: i2c eeprom 30: 00 00 20 40 20 80 02 20 10 01 00 00 00 00 00 00 [12033.442218] em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [12033.442248] em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [12033.442277] em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 20 03 55 00 53 00 [12033.442306] em28xx #0: i2c eeprom 70: 42 00 20 00 43 00 41 00 50 00 20 00 44 00 65 00 [12033.442335] em28xx #0: i2c eeprom 80: 76 00 69 00 63 00 65 00 00 00 00 00 00 00 00 00 [12033.442365] em28xx #0: i2c eeprom 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [12033.442394] em28xx #0: i2c eeprom a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [12033.442423] em28xx #0: i2c eeprom b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [12033.442452] em28xx #0: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [12033.442481] em28xx #0: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [12033.442510] em28xx #0: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [12033.442539] em28xx #0: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [12033.442572] em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0xf4675b8a [12033.442577] em28xx #0: EEPROM info: [12033.442582] em28xx #0:AC97 audio (5 sample rates) [12033.442586] em28xx #0:500mA max power [12033.442592] em28xx #0:Table at 0x04, strings=0x206a, 0x, 0x [12033.478597] em28xx #0: found i2c device @ 0x88 [msp34xx] [12033.483080] em28xx #0: found i2c device @ 0xa0 [eeprom] [12033.483467] em28xx #0: found i2c device @ 0xa2 [???] [12033.500971] em28xx #0: Your board has no unique USB ID and thus need a hint to be detected. [12033.500980] em28xx #0: You may try to use card= insmod option to workaround that. [12033.500986] em28xx #0: Please send an email with this log to: [12033.500990] em28xx #0: V4L Mailing List [12033.500996] em28xx #0: Board eeprom hash is 0xf4675b8a [12033.501002] em28xx #0: Board i2c devicelist hash is 0x2fd10080 [12033.501007] em28xx #0: Here is a list of valid choices for the card= insmod option: [12033.501014] em28xx #0: card=0 -> Unknown EM2800 video grabber [12033.501020] em28xx #0: card=1 -> Unknown EM2750/28xx video grabber [12033.501026] em28xx #0: card=2 -> Terratec Cinergy 250 USB [12033.501032] em28xx #0: card=3 -> Pinnacle PCTV USB 2 [12033.501038] em28xx #0: card=4 -> Hauppauge WinTV USB 2 [12033.501044] em28xx #0: card=5 -> MSI VOX USB 2.0 [12033.501049] em28xx #0: card=6 -> Terratec Cinergy 200 USB [12033.501055] em28xx #0: card=7 -> Leadtek Winfast USB II [12033.501060] em28xx #0: card=8 -> Kworld USB2800 [12033.501066] em28xx #0: card=9 -> Pinnacle Dazzle DVC 90/100/101/107 / Kaiser Baas Video to DVD maker / Kworld DVD Maker 2 [12033.501073] em28xx #0: card=10 -> Hauppauge WinTV HVR 900 [12033.501079] em28xx #0: card=11 -> Terratec Hybrid XS [12033.501085] em28xx #0: card=12 -> Kworld PVR TV 2800 RF [12033.501091] em28xx #0: card=13 -> Terratec Prodigy XS [12033.501097] em28xx #0: card=14 -> SIIG AVTuner-PVR / Pixelview Prolink PlayTV USB 2.0 [12033.501103] em28xx #0: card=15 -> V-Gear PocketTV [12033.501109] em28xx #0: card=16 -> Hauppauge WinTV HVR 950 [12033.501115] em28xx #0: card=17 -> Pinnacle PCTV HD Pro Stick [12033.501121] em28xx #0: card=18 -> Hauppauge WinTV HVR 900 (R2) [12033.501127] em28xx #0: card=19 -> EM2860/SAA711X Reference Design [12033.501133] em28xx #0: card=20 -> AMD ATI TV Wonder HD 600 [12033.501139] em28xx #0: card=21 -> eMPIA Technology, Inc. GrabBeeX+ Video Encoder [12033.501145] em28xx #0: card=22 -> EM2710/EM2750/EM2751 webcam grabber [12033.501151] em28xx #0: card=23 -> Huaqi DLCW-130 [12033.501157] em28xx #0: card=24
Re: subscription request
Hi David, On Wed, Jul 13, 2011 at 03:08:02PM +0200, D. R. wrote: > please subscribe me to your email list > > > Kind Regards > David Rehle > -- > 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 The automatically added signature nearly has the information you need. Just remove all "un"s from it and there you go. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- 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
subscription request
Hi all, please subscribe me to your email list Kind Regards David Rehle -- 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] add support for the dvb-t part of CT-3650 v2
Em 06-07-2011 19:57, Jose Alberto Reguero escreveu:
> This patch add suport for the dvb-t part of CT-3650.
>
> Jose Alberto
>
> Signed-off-by: Jose Alberto Reguero
> patches/lmml_951522_add_support_for_the_dvb_t_part_of_ct_3650_v2.patch
> Content-Type: text/plain; charset="utf-8"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Subject: add support for the dvb-t part of CT-3650 v2
> Date: Wed, 06 Jul 2011 22:57:04 -
> From: Jose Alberto Reguero
> X-Patchwork-Id: 951522
> Message-Id: <201107070057.06317.jaregu...@telefonica.net>
> To: linux-media@vger.kernel.org
>
> This patch add suport for the dvb-t part of CT-3650.
>
> Jose Alberto
>
> Signed-off-by: Jose Alberto Reguero
>
>
> diff -ur linux/drivers/media/common/tuners/tda827x.c
> linux.new/drivers/media/common/tuners/tda827x.c
> --- linux/drivers/media/common/tuners/tda827x.c 2010-07-03
> 23:22:08.0 +0200
> +++ linux.new/drivers/media/common/tuners/tda827x.c 2011-07-04
> 12:00:29.931561053 +0200
> @@ -135,14 +135,29 @@
>
> static int tuner_transfer(struct dvb_frontend *fe,
> struct i2c_msg *msg,
> - const int size)
> + int size)
> {
> int rc;
> struct tda827x_priv *priv = fe->tuner_priv;
> + struct i2c_msg msgr[2];
>
> if (fe->ops.i2c_gate_ctrl)
> fe->ops.i2c_gate_ctrl(fe, 1);
> - rc = i2c_transfer(priv->i2c_adap, msg, size);
> + if (priv->cfg->i2cr && (msg->flags == I2C_M_RD)) {
> + msgr[0].addr = msg->addr;
> + msgr[0].flags = 0;
> + msgr[0].len = msg->len - 1;
> + msgr[0].buf = msg->buf;
> + msgr[1].addr = msg->addr;
> + msgr[1].flags = I2C_M_RD;
> + msgr[1].len = 1;
> + msgr[1].buf = msg->buf;
> + size = 2;
> + rc = i2c_transfer(priv->i2c_adap, msgr, size);
> + msg->buf[msg->len - 1] = msgr[1].buf[0];
> + } else {
> + rc = i2c_transfer(priv->i2c_adap, msg, size);
> + }
> if (fe->ops.i2c_gate_ctrl)
> fe->ops.i2c_gate_ctrl(fe, 0);
No. You should be applying such fix at the I2C adapter instead. This is the
code at the ttusb2 driver:
static int ttusb2_i2c_xfer(struct i2c_adapter *adap,struct i2c_msg msg[],int
num)
{
struct dvb_usb_device *d = i2c_get_adapdata(adap);
static u8 obuf[60], ibuf[60];
int i,read;
if (mutex_lock_interruptible(&d->i2c_mutex) < 0)
return -EAGAIN;
if (num > 2)
warn("more than 2 i2c messages at a time is not handled yet.
TODO.");
for (i = 0; i < num; i++) {
read = i+1 < num && (msg[i+1].flags & I2C_M_RD);
obuf[0] = (msg[i].addr << 1) | read;
obuf[1] = msg[i].len;
/* read request */
if (read)
obuf[2] = msg[i+1].len;
else
obuf[2] = 0;
memcpy(&obuf[3],msg[i].buf,msg[i].len);
if (ttusb2_msg(d, CMD_I2C_XFER, obuf, msg[i].len+3, ibuf,
obuf[2] + 3) < 0) {
err("i2c transfer failed.");
break;
}
if (read) {
memcpy(msg[i+1].buf,&ibuf[3],msg[i+1].len);
i++;
}
}
mutex_unlock(&d->i2c_mutex);
return i;
}
Clearly, this routine has issues, as it assumes that all transfers with reads
will
be broken into just two msgs, where the first one is a write, and a second one
is a
read, and that no transfers will be bigger than 2 messages.
It shouldn't be hard to adapt it to handle transfers on either way, and to
remove
the limit of 2 transfers.
>
> @@ -540,7 +555,7 @@
> if_freq = 500;
> break;
> }
> - tuner_freq = params->frequency + if_freq;
> + tuner_freq = params->frequency;
>
> if (fe->ops.info.type == FE_QAM) {
> dprintk("%s select tda827xa_dvbc\n", __func__);
> @@ -554,6 +569,8 @@
> i++;
> }
>
> + tuner_freq += if_freq;
> +
> N = ((tuner_freq + 31250) / 62500) << frequency_map[i].spd;
> buf[0] = 0;// subaddress
> buf[1] = N >> 8;
This seems to be a bug fix, but you're touching only at the DVB-C. If the table
lookup
should not consider if_freq, the same fix is needed on the other similar logics
at the
driver.
Also, please send such patch in separate.
> diff -ur linux/drivers/media/common/tuners/tda827x.h
> linux.new/drivers/media/common/tuners/tda827x.h
> --- linux/drivers/media/common/tuners/tda827x.h 2010-07-03
> 23:22:08.0 +0200
> +++ linux.new/drivers/media/common/tuners/tda827x.h 2011-05-21
> 22:48:31.484340005 +0200
> @@ -38,6 +38,8 @@
> int switch_addr;
>
> void (*agcf)(struct dvb_frontend *fe);
> +
> + u8 i2
[RFCv1 PATCH 5/6] videobuf2-core: also test for pending events.
From: Hans Verkuil
Signed-off-by: Hans Verkuil
---
drivers/media/video/videobuf2-core.c | 41 +++--
1 files changed, 28 insertions(+), 13 deletions(-)
diff --git a/drivers/media/video/videobuf2-core.c
b/drivers/media/video/videobuf2-core.c
index 1892bb8..1922bf8 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
@@ -19,6 +19,9 @@
#include
#include
+#include
+#include
+#include
#include
static int debug;
@@ -1360,15 +1363,28 @@ static int __vb2_cleanup_fileio(struct vb2_queue *q);
* For OUTPUT queues, if a buffer is ready to be dequeued, the file descriptor
* will be reported as available for writing.
*
+ * If the driver uses struct v4l2_fh, then vb2_poll() will also check for any
+ * pending events.
+ *
* The return values from this function are intended to be directly returned
* from poll handler in driver.
*/
unsigned int vb2_poll(struct vb2_queue *q, struct file *file, poll_table *wait)
{
+ struct video_device *vfd = video_devdata(file);
unsigned long req_events = poll_requested_events(wait);
- unsigned long flags;
- unsigned int ret;
struct vb2_buffer *vb = NULL;
+ unsigned int res = 0;
+ unsigned long flags;
+
+ if (test_bit(V4L2_FL_USES_V4L2_FH, &vfd->flags)) {
+ struct v4l2_fh *fh = file->private_data;
+
+ if (v4l2_event_pending(fh))
+ res = POLLPRI;
+ else if (req_events & POLLPRI)
+ poll_wait(file, &fh->wait, wait);
+ }
/*
* Start file I/O emulator only if streaming API has not been used yet.
@@ -1376,19 +1392,17 @@ unsigned int vb2_poll(struct vb2_queue *q, struct file
*file, poll_table *wait)
if (q->num_buffers == 0 && q->fileio == NULL) {
if (!V4L2_TYPE_IS_OUTPUT(q->type) && (q->io_modes & VB2_READ) &&
(req_events & (POLLIN | POLLRDNORM))) {
- ret = __vb2_init_fileio(q, 1);
- if (ret)
- return POLLERR;
+ if (__vb2_init_fileio(q, 1))
+ return res | POLLERR;
}
if (V4L2_TYPE_IS_OUTPUT(q->type) && (q->io_modes & VB2_WRITE) &&
(req_events & (POLLOUT | POLLWRNORM))) {
- ret = __vb2_init_fileio(q, 0);
- if (ret)
- return POLLERR;
+ if (__vb2_init_fileio(q, 0))
+ return res | POLLERR;
/*
* Write to OUTPUT queue can be done immediately.
*/
- return POLLOUT | POLLWRNORM;
+ return res | POLLOUT | POLLWRNORM;
}
}
@@ -1396,7 +1410,7 @@ unsigned int vb2_poll(struct vb2_queue *q, struct file
*file, poll_table *wait)
* There is nothing to wait for if no buffers have already been queued.
*/
if (list_empty(&q->queued_list))
- return POLLERR;
+ return res | POLLERR;
poll_wait(file, &q->done_wq, wait);
@@ -1411,10 +1425,11 @@ unsigned int vb2_poll(struct vb2_queue *q, struct file
*file, poll_table *wait)
if (vb && (vb->state == VB2_BUF_STATE_DONE
|| vb->state == VB2_BUF_STATE_ERROR)) {
- return (V4L2_TYPE_IS_OUTPUT(q->type)) ? POLLOUT | POLLWRNORM :
- POLLIN | POLLRDNORM;
+ return (V4L2_TYPE_IS_OUTPUT(q->type)) ?
+ res | POLLOUT | POLLWRNORM :
+ res | POLLIN | POLLRDNORM;
}
- return 0;
+ return res;
}
EXPORT_SYMBOL_GPL(vb2_poll);
--
1.7.1
--
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
[RFCv1 PATCH 6/6] vivi: let vb2_poll handle events.
From: Hans Verkuil
The vb2_poll function now tests for events and sets POLLPRI accordingly.
So there it is no longer necessary to test for it in the vivi driver.
Signed-off-by: Hans Verkuil
---
drivers/media/video/vivi.c |9 +
1 files changed, 1 insertions(+), 8 deletions(-)
diff --git a/drivers/media/video/vivi.c b/drivers/media/video/vivi.c
index a848bd2..fc3c88f 100644
--- a/drivers/media/video/vivi.c
+++ b/drivers/media/video/vivi.c
@@ -1039,17 +1039,10 @@ static unsigned int
vivi_poll(struct file *file, struct poll_table_struct *wait)
{
struct vivi_dev *dev = video_drvdata(file);
- struct v4l2_fh *fh = file->private_data;
struct vb2_queue *q = &dev->vb_vidq;
- unsigned int res;
dprintk(dev, 1, "%s\n", __func__);
- res = vb2_poll(q, file, wait);
- if (v4l2_event_pending(fh))
- res |= POLLPRI;
- else
- poll_wait(file, &fh->wait, wait);
- return res;
+ return vb2_poll(q, file, wait);
}
static int vivi_close(struct file *file)
--
1.7.1
--
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
[RFCv1 PATCH 4/6] videobuf: only start streaming in poll() if so requested by the poll mask.
From: Hans Verkuil
Signed-off-by: Hans Verkuil
---
drivers/media/video/videobuf-core.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/videobuf-core.c
b/drivers/media/video/videobuf-core.c
index de4fa4e..ffdf59c 100644
--- a/drivers/media/video/videobuf-core.c
+++ b/drivers/media/video/videobuf-core.c
@@ -1129,6 +1129,7 @@ unsigned int videobuf_poll_stream(struct file *file,
struct videobuf_queue *q,
poll_table *wait)
{
+ unsigned long req_events = poll_requested_events(wait);
struct videobuf_buffer *buf = NULL;
unsigned int rc = 0;
@@ -1137,7 +1138,7 @@ unsigned int videobuf_poll_stream(struct file *file,
if (!list_empty(&q->stream))
buf = list_entry(q->stream.next,
struct videobuf_buffer, stream);
- } else {
+ } else if (req_events & (POLLIN | POLLRDNORM)) {
if (!q->reading)
__videobuf_read_start(q);
if (!q->reading) {
--
1.7.1
--
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
[RFCv1 PATCH 2/6] ivtv: only start streaming in poll() if polling for input.
From: Hans Verkuil
Signed-off-by: Hans Verkuil
---
drivers/media/video/ivtv/ivtv-fileops.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/ivtv/ivtv-fileops.c
b/drivers/media/video/ivtv/ivtv-fileops.c
index 38f0522..a931ecf 100644
--- a/drivers/media/video/ivtv/ivtv-fileops.c
+++ b/drivers/media/video/ivtv/ivtv-fileops.c
@@ -744,8 +744,9 @@ unsigned int ivtv_v4l2_dec_poll(struct file *filp,
poll_table *wait)
return res;
}
-unsigned int ivtv_v4l2_enc_poll(struct file *filp, poll_table * wait)
+unsigned int ivtv_v4l2_enc_poll(struct file *filp, poll_table *wait)
{
+ unsigned long req_events = poll_requested_events(wait);
struct ivtv_open_id *id = fh2id(filp->private_data);
struct ivtv *itv = id->itv;
struct ivtv_stream *s = &itv->streams[id->type];
@@ -753,7 +754,8 @@ unsigned int ivtv_v4l2_enc_poll(struct file *filp,
poll_table * wait)
unsigned res = 0;
/* Start a capture if there is none */
- if (!eof && !test_bit(IVTV_F_S_STREAMING, &s->s_flags)) {
+ if (!eof && !test_bit(IVTV_F_S_STREAMING, &s->s_flags) &&
+ (req_events & (POLLIN | POLLRDNORM))) {
int rc;
mutex_lock(&itv->serialize_lock);
--
1.7.1
--
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
[RFCv1 PATCH 3/6] videobuf2: only start streaming in poll() if so requested by the poll mask.
From: Hans Verkuil
Signed-off-by: Hans Verkuil
---
drivers/media/video/videobuf2-core.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/videobuf2-core.c
b/drivers/media/video/videobuf2-core.c
index 3015e60..1892bb8 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
@@ -1365,6 +1365,7 @@ static int __vb2_cleanup_fileio(struct vb2_queue *q);
*/
unsigned int vb2_poll(struct vb2_queue *q, struct file *file, poll_table *wait)
{
+ unsigned long req_events = poll_requested_events(wait);
unsigned long flags;
unsigned int ret;
struct vb2_buffer *vb = NULL;
@@ -1373,12 +1374,14 @@ unsigned int vb2_poll(struct vb2_queue *q, struct file
*file, poll_table *wait)
* Start file I/O emulator only if streaming API has not been used yet.
*/
if (q->num_buffers == 0 && q->fileio == NULL) {
- if (!V4L2_TYPE_IS_OUTPUT(q->type) && (q->io_modes & VB2_READ)) {
+ if (!V4L2_TYPE_IS_OUTPUT(q->type) && (q->io_modes & VB2_READ) &&
+ (req_events & (POLLIN | POLLRDNORM))) {
ret = __vb2_init_fileio(q, 1);
if (ret)
return POLLERR;
}
- if (V4L2_TYPE_IS_OUTPUT(q->type) && (q->io_modes & VB2_WRITE)) {
+ if (V4L2_TYPE_IS_OUTPUT(q->type) && (q->io_modes & VB2_WRITE) &&
+ (req_events & (POLLOUT | POLLWRNORM))) {
ret = __vb2_init_fileio(q, 0);
if (ret)
return POLLERR;
--
1.7.1
--
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
[RFCv1 PATCH 1/6] poll: add poll_requested_events() function
From: Hans Verkuil
In some cases the poll() implementation in a driver has to do different
things depending on the events the caller wants to poll for. An example is
when a driver needs to start a DMA engine if the caller polls for POLLIN,
but doesn't want to do that if POLLIN is not requested but instead only
POLLOUT or POLLPRI is requested. This is something that can happen in the
video4linux subsystem.
Unfortunately, the current epoll/poll/select implementation doesn't provide
that information reliably. The poll_table_struct does have it: it has a key
field with the event mask. But once a poll() call matches one or more bits
of that mask any following poll() calls are passed a NULL poll_table_struct
pointer.
The solution is to set the qproc field to NULL in poll_table_struct once
poll() matches the events, not the poll_table_struct pointer itself. That
way drivers can obtain the mask through a new poll_requested_events inline.
The poll_table_struct can still be NULL since some kernel code calls it
internally (netfs_state_poll() in ./drivers/staging/pohmelfs/netfs.h). In
that case poll_requested_events() returns ~0 (i.e. all events).
Since eventpoll always leaves the key field at ~0 instead of using the
requested events mask, that source was changed as well to properly fill in
the key field.
Signed-off-by: Hans Verkuil
Reviewed-by: Jonathan Corbet
---
fs/eventpoll.c | 19 +++
fs/select.c | 38 +-
include/linux/poll.h |7 ++-
3 files changed, 38 insertions(+), 26 deletions(-)
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index f9cfd16..6a54a69 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -650,9 +650,12 @@ static int ep_read_events_proc(struct eventpoll *ep,
struct list_head *head,
void *priv)
{
struct epitem *epi, *tmp;
+ poll_table pt;
+ init_poll_funcptr(&pt, NULL);
list_for_each_entry_safe(epi, tmp, head, rdllink) {
- if (epi->ffd.file->f_op->poll(epi->ffd.file, NULL) &
+ pt.key = epi->event.events;
+ if (epi->ffd.file->f_op->poll(epi->ffd.file, &pt) &
epi->event.events)
return POLLIN | POLLRDNORM;
else {
@@ -946,6 +949,7 @@ static int ep_insert(struct eventpoll *ep, struct
epoll_event *event,
/* Initialize the poll table using the queue callback */
epq.epi = epi;
init_poll_funcptr(&epq.pt, ep_ptable_queue_proc);
+ epq.pt.key = event->events;
/*
* Attach the item to the poll hooks and get current event bits.
@@ -1027,20 +1031,23 @@ static int ep_modify(struct eventpoll *ep, struct
epitem *epi, struct epoll_even
{
int pwake = 0;
unsigned int revents;
+ poll_table pt;
+
+ init_poll_funcptr(&pt, NULL);
/*
* Set the new event interest mask before calling f_op->poll();
* otherwise we might miss an event that happens between the
* f_op->poll() call and the new event set registering.
*/
- epi->event.events = event->events;
+ epi->event.events = pt.key = event->events;
epi->event.data = event->data; /* protected by mtx */
/*
* Get current event bits. We can safely use the file* here because
* its usage count has been increased by the caller of this function.
*/
- revents = epi->ffd.file->f_op->poll(epi->ffd.file, NULL);
+ revents = epi->ffd.file->f_op->poll(epi->ffd.file, &pt);
/*
* If the item is "hot" and it is not registered inside the ready
@@ -1075,6 +1082,9 @@ static int ep_send_events_proc(struct eventpoll *ep,
struct list_head *head,
unsigned int revents;
struct epitem *epi;
struct epoll_event __user *uevent;
+ poll_table pt;
+
+ init_poll_funcptr(&pt, NULL);
/*
* We can loop without lock because we are passed a task private list.
@@ -1087,7 +1097,8 @@ static int ep_send_events_proc(struct eventpoll *ep,
struct list_head *head,
list_del_init(&epi->rdllink);
- revents = epi->ffd.file->f_op->poll(epi->ffd.file, NULL) &
+ pt.key = epi->event.events;
+ revents = epi->ffd.file->f_op->poll(epi->ffd.file, &pt) &
epi->event.events;
/*
diff --git a/fs/select.c b/fs/select.c
index d33418f..b6765cf 100644
--- a/fs/select.c
+++ b/fs/select.c
@@ -386,13 +386,11 @@ get_max:
static inline void wait_key_set(poll_table *wait, unsigned long in,
unsigned long out, unsigned long bit)
{
- if (wait) {
- wait->key = POLLEX_SET;
- if (in & bit)
- wait->key |= POLLIN_SET;
- if (out & bit)
- wait->key |= POLLOUT_SET;
- }
+ wait->key = POLLEX_SET;
+ if (in & bit)
[RFCv1 PATCH 0/6] Don't start streaming unless requested by the poll mask.
The patch adding core support for poll_requested_events() looks ready for v3.1, so this patch series builds on it to fix the vivi and ivtv drivers. It also uses it in videobuf. I think it makes sense to add it there as well, even though no videobuf-drivers use events (yet). If there are no comments, then I'd like to make a pull request for this by the end of the week. Regards, Hans PS: Note that I'm having vacation until July 25th, so I won't be very active on the mailinglist. These poll patches are the only thing that I'm working on since I really want to get these merged for v3.1. -- 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] uvcvideo: add fix suspend/resume quirk for Microdia camera
Hi, On Wed, Jul 13, 2011 at 4:59 PM, Laurent Pinchart wrote: > Sorry, I haven't been clear. If you remove the suspend/resume handlers from > the driver, the USB core will unbind and rebind the driver instead of > suspending/resuming the device properly. As this will affect other UVC devices > as well, that's not a good solution. I agree with you this is not a good solution, but seems there are no other solutions for the buggy device. You are uvc expert, could you give some suggestion about accepted solutions? thanks, -- Ming Lei -- 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] uvcvideo: add fix suspend/resume quirk for Microdia camera
On Wednesday 13 July 2011 10:51:11 Ming Lei wrote: > On Wed, Jul 13, 2011 at 4:38 PM, Laurent Pinchart wrote: > > They can still work, but not optimally, as they will be reset instead of > > suspended/resumed. That's not acceptable. > > If the "reset" you mentioned is usb bus reset signal, I think unbind&bind > will not produce the reset signal. Sorry, I haven't been clear. If you remove the suspend/resume handlers from the driver, the USB core will unbind and rebind the driver instead of suspending/resuming the device properly. As this will affect other UVC devices as well, that's not a good solution. -- Regards, Laurent Pinchart -- 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] uvcvideo: add fix suspend/resume quirk for Microdia camera
Am Mittwoch, 13. Juli 2011, 10:51:11 schrieb Ming Lei: > Hi, > > On Wed, Jul 13, 2011 at 4:38 PM, Laurent Pinchart > wrote: > > > They can still work, but not optimally, as they will be reset instead of > > suspended/resumed. That's not acceptable. > > If the "reset" you mentioned is usb bus reset signal, I think unbind&bind > will not produce the reset signal. You are correct. It will not. Regards Oliver -- - - - SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany - - - -- 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] uvcvideo: add fix suspend/resume quirk for Microdia camera
Hi, On Wed, Jul 13, 2011 at 4:38 PM, Laurent Pinchart wrote: > They can still work, but not optimally, as they will be reset instead of > suspended/resumed. That's not acceptable. If the "reset" you mentioned is usb bus reset signal, I think unbind&bind will not produce the reset signal. thanks, -- Ming Lei -- 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] uvcvideo: add fix suspend/resume quirk for Microdia camera
On Tuesday 12 July 2011 03:21:05 Ming Lei wrote: > On Mon, Jul 11, 2011 at 6:44 PM, Laurent Pinchart wrote: > > That's unfortunately not acceptable as-is. If two cameras are connected > > to the system, and only one of them doesn't support suspend/resume, the > > other will be affected by your patch. > > Yes, other cameras may be affected, but they still can work well, so > the patch still makes sense. They can still work, but not optimally, as they will be reset instead of suspended/resumed. That's not acceptable. > > Have you tried to investigate why suspend/resume fails for the > > above-mentioned camera, instead of working around the problem ? > > I have investigated the problem, and not found failures in the > suspend/resume path, > either .suspend or .resume callback return successful, but no stream > packets are received from camera any longer after resume from sleep. Once > doing a unbind& bind will make the camera work again. > > Could you give any suggestions to help to find the root cause of the > problem? -- Regards, Laurent Pinchart -- 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] uvcvideo: add fix suspend/resume quirk for Microdia camera
Hi, On Tue, Jul 12, 2011 at 11:44 PM, Alan Stern wrote: > Maybe this device needs a USB_QUIRK_RESET_RESUME entry in quirks.c. RESET_RESUME quirk makes things worse, now stream data is not received from the camera at all even in resume from runtime suspend case. So the quirk can make the device totally useless, :-) thanks, -- Ming Lei -- 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] uvcvideo: add fix suspend/resume quirk for Microdia camera
Hi, On Tue, Jul 12, 2011 at 11:44 PM, Alan Stern wrote: > On Tue, 12 Jul 2011, Ming Lei wrote: > >> Hi Laurent, >> >> After resume from sleep, all the ISO packets from camera are like below: >> >> 880122d9f400 3527230728 S Zi:1:004:1 -115:1:2568 32 -18:0:1600 >> -18:1600:1600 -18:3200:1600 -18:4800:1600 -18:6400:1600 51200 < >> 880122d9d400 3527234708 C Zi:1:004:1 0:1:2600:0 32 0:0:12 >> 0:1600:12 0:3200:12 0:4800:12 0:6400:12 51200 = 0c8c fa7e >> 012f1b05 >> >> All are headed with 0c8c, see attached usbmon captures. > > Maybe this device needs a USB_QUIRK_RESET_RESUME entry in quirks.c. I will try it, but seems unbind&bind driver don't produce extra usb reset signal to the device. Also, the problem didn't happen in runtime pm case, just happen in wakeup from system suspend case. uvcvideo has enabled auto suspend already at default. thanks, -- Ming Lei -- 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: Migrate from soc_camera to v4l2
On Wed, 13 Jul 2011, LBM wrote: > my dear Guennadi > I'm wrong about that "v4l2-int-device",maybe it just "V4L2". >Now i have a board of OMAP3530 and a cmos camera MT9M111,so i want to > get the image from the mt9m111. > and ,I want to use the V4L2 API. But in the linux kernel 2.6.38,the driver > of the mt9m111 is a soc_camera.I see some thing about how to convert the > soc_camera to V4L2,like "soc-camera: (partially) convert to v4l2-(sub)dev > API". > Can you tell me how to migrate from soc_camera to v4l2,and > or do you tell me some experience about that? Currently there's no standard way to make a driver to work with both soc-camera and (pure) v4l2-subdev APIs. It is being worked on: http://www.spinics.net/lists/linux-media/msg34878.html and, hopefully, beginning with the next kernel version 3.1 it will become at least theoretically possible. For now you just have to hack the driver yourself for your local uses by removing all soc-camera specific code and replacing it with your own glue, something along these lines: http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/11486/focus=11691 Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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
