Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
Hi Dmitry, on 03 Dec 09 at 14:12, Dmitry Torokhov wrote: [...] >> Consider passing the decoded data through lirc_dev. [...] > I believe it was agreed that lirc-dev should be used mainly for decoding > protocols that are more conveniently decoded in userspace and the > results would be looped back into input layer through evdev which will > be the main interface for consumer applications to use. Quoting myself: > Currently I would tend to an approach like this: > - raw interface to userspace using LIRC For me this includes both the pulse/space data and also the scan codes when hardware does the decoding. Consider cases like this: http://lirc.sourceforge.net/remotes/lg/6711A20015N This is an air-conditioner remote. The entries that you see in this config file are not really separate buttons. Instead the remote just sends the current settings for e.g. temperature encoded in the protocol when you press some up/down key. You really don't want to map all possible temperature settings to KEY_* events. For such cases it would be nice to have access at the raw scan codes from user space to do interpretation of the data. The default would still be to pass the data to the input layer, but it won't hurt to have the possibility to access the raw data somehow. Christoph -- 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: Fwd: DVB-APPS patch for uk-WinterHill
On Thu, 3 Dec 2009, Justin Hornsby wrote: > Since 02 Dec 2009 the UK WinterHill transmitter site has been > broadcasting on different frequencies & in a different mode with > different modulation. Channels have been re-arranged to occupy five > multiplexes and the original BBC 'B' mux is now broadcasting DVB-T2 > for high definition services (which of course cannot yet be tuned by > mere mortals). The 'WinterHill B' transmitter stopped broadcasting on > 02 Dec. > > The attached file is a patch to reflect these changes. > +T 74600 8MHz 2/3 NONE QAM64 8k 1/32 NONE > +T 77000 8MHz 2/3 NONE QAM64 8k 1/32 NONE > +T 77800 8MHz 2/3 NONE QAM64 8k 1/32 NONE > +T 79400 8MHz 2/3 NONE QAM64 8k 1/32 NONE > +T 801833000 8MHz 2/3 NONE QAM64 8k 1/32 NONE While the DVB-T2 multiplex (MUX B) cannot be tuned by existing DVB-T-only devices, and I don't know if the dvb-apps are being prepared for DVB-T2 (there don't appear to be any of the known DVB-S2 transponders listed in a couple positions), the modulation parameters, for future reference, are probably something like +# T2 73800 8MHz 2/3 NONE QAM256 32k 1/128 NONE #E54 DVB-T2 HD MUX B There may need to be additional details specified, I'm no expert. These values are, of course, unconfirmed. The same would be true for Crystal Palace at 10kW, but on channel E31, or 55400, no offset. barry bouwsma -- 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
linux-next i386 allmodconfig
ERROR: "__divdf3" [drivers/media/dvb/frontends/atbm8830.ko] undefined! ERROR: "__adddf3" [drivers/media/dvb/frontends/atbm8830.ko] undefined! ERROR: "__fixunsdfsi" [drivers/media/dvb/frontends/atbm8830.ko] undefined! ERROR: "__udivdi3" [drivers/media/dvb/frontends/atbm8830.ko] undefined! ERROR: "__floatsidf" [drivers/media/dvb/frontends/atbm8830.ko] undefined! ERROR: "__muldf3" [drivers/media/dvb/frontends/atbm8830.ko] undefined! ERROR: "__adddf3" [drivers/media/common/tuners/max2165.ko] undefined! ERROR: "__fixunsdfsi" [drivers/media/common/tuners/max2165.ko] undefined! ERROR: "__floatsidf" [drivers/media/common/tuners/max2165.ko] undefined! would be nice to get that fixed up before merging. -- 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 v0 1/2] V4L - vpfe capture - convert ccdc drivers to platform drivers
On Fri, Dec 04, 2009 at 01:21:43, Karicheri, Muralidharan wrote: > [...] > > > >> + if (!res) { > >> + status = -EBUSY; > >> + goto fail_nores; > >> + } > >> + > >> + ccdc_base_addr = ioremap_nocache(res->start, res_len); > >> + if (!ccdc_base_addr) { > >> + status = -EBUSY; > >[Hiremath, Vaibhav] Is -EBUSY right return value, I think it should be - > >ENXIO or -ENOMEM. > > > I see -ENXIO & -ENOMEM being used by drivers. -ENXIO stands for "No such > device or address". ENOMEM stands for "Out of memory" . Since we are trying > to map the address here, -ENXIO looks reasonable to me. Same if > request_mem_region() fails. > Sergei had posted on this earlier[1]. Quoting him here: " > What are the proper error codes when platform_get_resource, -ENODEV. > request_mem_region -EBUSY. > and ioremap functions fail?. -ENOMEM. " Not sure if ioremap failure can relate to absence of a device. Thanks, Sekhar [1] http://www.mail-archive.com/davinci-linux-open-sou...@linux.davincidsp.com/msg14973.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: saa7134 (not very) new board 5168:0307
Hi hermann, we are this results : with &tda827x_cfg_0, &tda827x_cfg_1 or &tda827x_cfg_2 we have a perfect image without sound on the analogic part (test with mplayer), a partial result with dvb-t : we need to initialize first with analogic (with cold boot, the card doesn't work on dvb) but only for few seconds(sound and image are ok) then re-initialize with analogic, work for few seconds on dvb and then nothing maybe i am wrong but, the sound part for analogic is a problem of redirection, isn't it ? here are our configuration for this card : in saa7134-dvb.c static struct tda1004x_config tda827x_flydvbtduo_medion_config = { .demod_address = 0x08, .invert= 1, .invert_oclk = 0, .xtal_freq = TDA10046_XTAL_16M, .agc_config= TDA10046_AGC_TDA827X, .gpio_config = TDA10046_GP01_I, .if_freq = TDA10046_FREQ_045, .i2c_gate = 0x4b, .tuner_address = 0x61, .antenna_switch = 2, .request_firmware = philips_tda1004x_request_firmware }; case SAA7134_BOARD_FLYDVBTDUO_MEDION: if (configure_tda827x_fe(dev, &tda827x_flydvbtduo_medion_config, &tda827x_cfg_2) < 0) goto dettach_frontend; break; default: wprintk("Huh? unknown DVB card?\n"); break; in saa7134-cards.c [SAA7134_BOARD_FLYDVBTDUO_MEDION] = { .name = "LifeView FlyDVB-T DUO Medion", .audio_clock= 0x00187de7, .tuner_type = TUNER_PHILIPS_TDA8290, .radio_type = UNSET, .tuner_addr= ADDR_UNSET, .radio_addr= ADDR_UNSET, .gpiomask= 0x0020, .mpeg = SAA7134_MPEG_DVB, .inputs = {{ .name = name_tv, .vmux = 1, .amux = TV, .gpio = 0x20, /* GPIO21=High for TV input */ .tv = 1, },{ .name = name_comp1,/* Composite signal on S-Video input */ .vmux = 3, .amux = LINE1, },{ .name = name_svideo,/* S-Video signal on S-Video input */ .vmux = 8, .amux = LINE1, }}, .radio = { .name = name_radio, .amux = TV, .gpio = 0x00,/* GPIO21=Low for FM radio antenna */ }, .vendor = PCI_VENDOR_ID_PHILIPS, .device = PCI_DEVICE_ID_PHILIPS_SAA7133, .subvendor= 0x5168, .subdevice= 0x0307, /* LR307-N */ .driver_data = SAA7134_BOARD_FLYDVBTDUO_MEDION, case SAA7134_BOARD_FLYDVBTDUO_MEDION: { /* this is a hybrid board, initialize to analog mode * and configure firmware eeprom address */ u8 data[] = { 0x3c, 0x33, 0x60}; struct i2c_msg msg = {.addr=0x08, .flags=0, .buf=data, .len = sizeof(data)}; i2c_transfer(&dev->i2c_adap, &msg, 1); break; What can we do to have dvb fully supported ? thanks in advance, Cheers, Thomas -- 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: Hauppage hvr-950q au0828 transfer problem affecting audio and perhaps video
On Thu, Dec 3, 2009 at 11:21 PM, Devin Heitmueller wrote: > On Thu, Dec 3, 2009 at 11:00 PM, John S Gruber wrote: >> I have problems with my audio that I've tracked down to the transfer >> of audio from the au0828 >> in my hvr-950Q. I spotted the following comment about green screen >> detection and I wonder >> if it might be related. >> >> drivers/media/video/au0828/au0828-video.c: >> >> /* Workaround for a bug in the au0828 hardware design that sometimes >> results in the colorspace being inverted */ >> >> The problem is that sound/usb/usbaudio.c assumes that each urb data >> field contains an integer >> number of audio frames (aka audio slots), in this case a integer >> number of left channel-right >> channel pairs. About 12 times a second for my device a urb doesn't. >> This causes a flutter noise >> with non-quiet audio that contains a difference between the channels. >> >> I found this by using audacity to look at wave forms and a usb trace >> to see the problematic urb's. >> I've confirmed by relaxing the constraint in sound/usb/usbaudio.c with >> a patch and can confirm that >> it clears up the audio. >> >> >> Is the code comment at the top related to my problem? >> >> More importantly, is there the possibility of setting up the transfer >> differently so that >> audio slots aren't split between urbs? >> >> >> From what I have read in the spec I believe the split of the audio >> slots between urb's is non- >> conformant. Therefore I think it would be a mistake to change the >> default behaviour of >> usbaudio.c since, as it is now,usbaudio.c won't swap channels in the >> case of dropped urbs. >> It would be optimal if the hvr-950q could be set up to conform by not >> splitting audio slots. >> >> I think the problem also occurs for video when blue will turn to pink >> for a flash until the top >> of frame resyncs things up--because of the corresponding swap of UY >> with VY. This seems >> to be related to how busy my system is and what usb slot I'm using on >> my laptop. Again >> I could see in a usb trace the urb's with data_lengths such that UY >> would be split from the >> corresponding VY. The video transfer is a straight byte copy so >> ordinarily this isn't a >> problem but would be if an abnormally sized urb were dropped and the >> device and host >> were to get out of sync regarding V and U. >> >> I also have caught an occasional odd number of bytes transferred in >> traces, which requires >> the drop of incomplete samples in usbaudio.c. I wonder if this is >> related to the green screen >> problem on video from the top comment. >> >> The easiest way to reproduce the audio problem is to use the composite >> video input but only >> hook up either the left or the right audio. With earphonesyou can hear >> the audio rapidly >> go from ear to ear. >> >> Thanks for those on the list for their hard work on getting devices >> such as this to work. I'd >> appreciate any answers, comments, corrections, or information. > > Hi John, > > I have actually actively debugging the au0828 audio this evening. The > comment you referred to (which I wrote) has to do with the delivery of > the UYVY data from the demodulator to the au0828 bridge, which can > cause the start of the stream to be off-by-one (the pink/green you see > is the colorspace inverted when the decoder loses sync). > > It is unrelated to audio. > > I'm working an issue now where the audio keeps dropping out. If you > want to show me the code change you did to usbaudio.c, it might give > me a better understand the issue. I am definitely seeing what you are saying with regards to the channel flipping back and forth. Do you know what size URBs are being delivered? If you've got a hacked up version of usbaudio.c, how about adding a printk() line which dumps out the URB size and send me a dump? Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.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
drivers/media/video/gspca/ov534.c warning
drivers/media/video/gspca/ov534.c: In function 'setsharpness_96': drivers/media/video/gspca/ov534.c:1539: warning: comparison is always false due to limited range of data type this code can't ever have worked. -- 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 another YUYV format GUID
On 12/03/09 18:05, Daniel Ritz wrote: Hi Laurent On Thu, 2009-12-03 at 21:15 +0100, Laurent Pinchart wrote: Hi Daniel, On Wednesday 02 December 2009 00:48:44 Daniel Ritz wrote: For some unknown reason, on a MacBookPro5,3 the iSight Could you please send me the output of lsusb -v both with the correct and wrong GUID ? sure. i attached three files: isight-good.txt, isight-bad.txt, isight-good2.txt this is three reboots in a row from like 10 minutes ago. the first boot into linux was actually rebooting from OSX...first cold boot today directly into linux had the right GUID. _sometimes_ report a different video format GUID. Sometimes only ? Now that's weird. Is that completely random ? yes, sometimes only. it seems to be related to reboots, but i don't know what exactly triggers it. rmmod/modprobe doesn't trigger it. also, when the wrong GUID is reported, the only way of fixing it is to reboot. it really is just the GUID. even when the wrong one is reported, the device works just fine. i started with a plain ubuntu 9.10, kernel 2.6.31 which was supposed to fail, so i upgraded to a 2.6.32-rc8 to fix the iSight and some other things, just to see it fail again. a reboot later and it worked, some time and reboot later it failed again... rgds -daniel This patch add the other (wrong) GUID to the format table, making the iSight work always w/o other problems. What it should report: 32595559--0010-8000-00aa00389b71 What it often reports: 32595559--0010-8000-00389b71 Signed-off-by: Daniel Ritz -- Regards, Laurent Pinchart I get weiredness whenever I shutdown the machine and then boot. If I boot, then reboot things work. Justin P. Mattock -- 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: Hauppage hvr-950q au0828 transfer problem affecting audio and perhaps video
On Thu, Dec 3, 2009 at 11:00 PM, John S Gruber wrote: > I have problems with my audio that I've tracked down to the transfer > of audio from the au0828 > in my hvr-950Q. I spotted the following comment about green screen > detection and I wonder > if it might be related. > > drivers/media/video/au0828/au0828-video.c: > > /* Workaround for a bug in the au0828 hardware design that sometimes > results in the colorspace being inverted */ > > The problem is that sound/usb/usbaudio.c assumes that each urb data > field contains an integer > number of audio frames (aka audio slots), in this case a integer > number of left channel-right > channel pairs. About 12 times a second for my device a urb doesn't. > This causes a flutter noise > with non-quiet audio that contains a difference between the channels. > > I found this by using audacity to look at wave forms and a usb trace > to see the problematic urb's. > I've confirmed by relaxing the constraint in sound/usb/usbaudio.c with > a patch and can confirm that > it clears up the audio. > > > Is the code comment at the top related to my problem? > > More importantly, is there the possibility of setting up the transfer > differently so that > audio slots aren't split between urbs? > > > From what I have read in the spec I believe the split of the audio > slots between urb's is non- > conformant. Therefore I think it would be a mistake to change the > default behaviour of > usbaudio.c since, as it is now,usbaudio.c won't swap channels in the > case of dropped urbs. > It would be optimal if the hvr-950q could be set up to conform by not > splitting audio slots. > > I think the problem also occurs for video when blue will turn to pink > for a flash until the top > of frame resyncs things up--because of the corresponding swap of UY > with VY. This seems > to be related to how busy my system is and what usb slot I'm using on > my laptop. Again > I could see in a usb trace the urb's with data_lengths such that UY > would be split from the > corresponding VY. The video transfer is a straight byte copy so > ordinarily this isn't a > problem but would be if an abnormally sized urb were dropped and the > device and host > were to get out of sync regarding V and U. > > I also have caught an occasional odd number of bytes transferred in > traces, which requires > the drop of incomplete samples in usbaudio.c. I wonder if this is > related to the green screen > problem on video from the top comment. > > The easiest way to reproduce the audio problem is to use the composite > video input but only > hook up either the left or the right audio. With earphonesyou can hear > the audio rapidly > go from ear to ear. > > Thanks for those on the list for their hard work on getting devices > such as this to work. I'd > appreciate any answers, comments, corrections, or information. Hi John, I have actually actively debugging the au0828 audio this evening. The comment you referred to (which I wrote) has to do with the delivery of the UYVY data from the demodulator to the au0828 bridge, which can cause the start of the stream to be off-by-one (the pink/green you see is the colorspace inverted when the decoder loses sync). It is unrelated to audio. I'm working an issue now where the audio keeps dropping out. If you want to show me the code change you did to usbaudio.c, it might give me a better understand the issue. Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.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/2 v4] v4l: add a media-bus API for configuring v4l2 subdev pixel and frame formats
On Thursday 03 December 2009 15:16:56 Guennadi Liakhovetski wrote: > Video subdevices, like cameras, decoders, connect to video bridges over > specialised busses. Data is being transferred over these busses in various > formats, which only loosely correspond to fourcc codes, describing how video > data is stored in RAM. This is not a one-to-one correspondence, therefore we > cannot use fourcc codes to configure subdevice output data formats. This patch > adds codes for several such on-the-bus formats and an API, similar to the > familiar .s_fmt(), .g_fmt(), .try_fmt(), .enum_fmt() API for configuring those > codes. After all users of the old API in struct v4l2_subdev_video_ops are > converted, it will be removed. Also add helper routines to support generic > pass-through mode for the soc-camera framework. > > Signed-off-by: Guennadi Liakhovetski > --- > > v3 -> v4: more comments addressed - thanks! Now based on the current > linux-next. Hans, as for _nXk suffixes, I preferred to preserve them to > keep all notation explicit. Without them a format like > V4L2_MBUS_FMT_SBGGR10 would be ambiguous, whether one of > V4L2_MBUS_FMT_SBGGR10_2X8_PAD*_?E or the V4L2_MBUS_FMT_SBGGR10_1X10 is > meant. I also removed struct soc_mbus_datafmt and soc_mbus_find_datafmt() > upon your request, although I'm not happy having to open-code it in about > 4 drivers. But we can extract that code in a generic routine later. One of > the important advantages of that struct and function was, that they > allowed to keep supported formats in drivers centrally at just one > location, thus being able to add new or remove deprecated formats easily, > and to avoid long switch-case blocks by just calling one function to > search in the array. > > Thanks > Guennadi > > drivers/media/video/Makefile |2 +- > drivers/media/video/soc_mediabus.c | 157 > > include/media/soc_mediabus.h | 65 +++ > include/media/v4l2-mediabus.h | 61 ++ > include/media/v4l2-subdev.h| 19 - > 5 files changed, 302 insertions(+), 2 deletions(-) > create mode 100644 drivers/media/video/soc_mediabus.c > create mode 100644 include/media/soc_mediabus.h > create mode 100644 include/media/v4l2-mediabus.h > > diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile > index 7a2dcc3..e7bc8da 100644 > --- a/drivers/media/video/Makefile > +++ b/drivers/media/video/Makefile > @@ -149,7 +149,7 @@ obj-$(CONFIG_VIDEO_VIVI) += vivi.o > obj-$(CONFIG_VIDEO_CX23885) += cx23885/ > > obj-$(CONFIG_VIDEO_OMAP2)+= omap2cam.o > -obj-$(CONFIG_SOC_CAMERA) += soc_camera.o > +obj-$(CONFIG_SOC_CAMERA) += soc_camera.o soc_mediabus.o > obj-$(CONFIG_SOC_CAMERA_PLATFORM)+= soc_camera_platform.o > # soc-camera host drivers have to be linked after camera drivers > obj-$(CONFIG_VIDEO_MX1) += mx1_camera.o > diff --git a/drivers/media/video/soc_mediabus.c > b/drivers/media/video/soc_mediabus.c > new file mode 100644 > index 000..c54cae7 > --- /dev/null > +++ b/drivers/media/video/soc_mediabus.c > @@ -0,0 +1,157 @@ > +/* > + * soc-camera media bus helper routines > + * > + * Copyright (C) 2009, Guennadi Liakhovetski > + * > + * This program 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. > + */ > + > +#include > +#include > + > +#include > +#include > +#include > + > +#define MBUS_IDX(f) (V4L2_MBUS_FMT_ ## f - V4L2_MBUS_FMT_FIXED - 1) > + > +static const struct soc_mbus_pixelfmt mbus_fmt[] = { > + [MBUS_IDX(YUYV8_2X8)] = { > + .fourcc = V4L2_PIX_FMT_YUYV, > + .name = "YUYV", > + .bits_per_sample= 8, > + .packing= SOC_MBUS_PACKING_2X8_PADHI, > + .order = SOC_MBUS_ORDER_LE, > + }, [MBUS_IDX(YVYU8_2X8)] = { > + .fourcc = V4L2_PIX_FMT_YVYU, > + .name = "YVYU", > + .bits_per_sample= 8, > + .packing= SOC_MBUS_PACKING_2X8_PADHI, > + .order = SOC_MBUS_ORDER_LE, > + }, [MBUS_IDX(UYVY8_2X8)] = { > + .fourcc = V4L2_PIX_FMT_UYVY, > + .name = "UYVY", > + .bits_per_sample= 8, > + .packing= SOC_MBUS_PACKING_2X8_PADHI, > + .order = SOC_MBUS_ORDER_LE, > + }, [MBUS_IDX(VYUY8_2X8)] = { > + .fourcc = V4L2_PIX_FMT_VYUY, > + .name = "VYUY", > + .bits_per_sample= 8, > + .packing= SOC_MBUS_PACKING_2X8_PADHI, > + .order = SOC_MBUS_ORDER_LE, > +
Hauppage hvr-950q au0828 transfer problem affecting audio and perhaps video
I have problems with my audio that I've tracked down to the transfer of audio from the au0828 in my hvr-950Q. I spotted the following comment about green screen detection and I wonder if it might be related. drivers/media/video/au0828/au0828-video.c: /* Workaround for a bug in the au0828 hardware design that sometimes results in the colorspace being inverted */ The problem is that sound/usb/usbaudio.c assumes that each urb data field contains an integer number of audio frames (aka audio slots), in this case a integer number of left channel-right channel pairs. About 12 times a second for my device a urb doesn't. This causes a flutter noise with non-quiet audio that contains a difference between the channels. I found this by using audacity to look at wave forms and a usb trace to see the problematic urb's. I've confirmed by relaxing the constraint in sound/usb/usbaudio.c with a patch and can confirm that it clears up the audio. Is the code comment at the top related to my problem? More importantly, is there the possibility of setting up the transfer differently so that audio slots aren't split between urbs? >From what I have read in the spec I believe the split of the audio slots between urb's is non- conformant. Therefore I think it would be a mistake to change the default behaviour of usbaudio.c since, as it is now,usbaudio.c won't swap channels in the case of dropped urbs. It would be optimal if the hvr-950q could be set up to conform by not splitting audio slots. I think the problem also occurs for video when blue will turn to pink for a flash until the top of frame resyncs things up--because of the corresponding swap of UY with VY. This seems to be related to how busy my system is and what usb slot I'm using on my laptop. Again I could see in a usb trace the urb's with data_lengths such that UY would be split from the corresponding VY. The video transfer is a straight byte copy so ordinarily this isn't a problem but would be if an abnormally sized urb were dropped and the device and host were to get out of sync regarding V and U. I also have caught an occasional odd number of bytes transferred in traces, which requires the drop of incomplete samples in usbaudio.c. I wonder if this is related to the green screen problem on video from the top comment. The easiest way to reproduce the audio problem is to use the composite video input but only hook up either the left or the right audio. With earphonesyou can hear the audio rapidly go from ear to ear. Thanks for those on the list for their hard work on getting devices such as this to work. I'd appreciate any answers, comments, corrections, or information. -- 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 another YUYV format GUID
Hi Laurent On Thu, 2009-12-03 at 21:15 +0100, Laurent Pinchart wrote: > Hi Daniel, > > On Wednesday 02 December 2009 00:48:44 Daniel Ritz wrote: > > For some unknown reason, on a MacBookPro5,3 the iSight > > Could you please send me the output of lsusb -v both with the correct and > wrong GUID ? sure. i attached three files: isight-good.txt, isight-bad.txt, isight-good2.txt this is three reboots in a row from like 10 minutes ago. the first boot into linux was actually rebooting from OSX...first cold boot today directly into linux had the right GUID. > > > _sometimes_ report a different video format GUID. > > Sometimes only ? Now that's weird. Is that completely random ? yes, sometimes only. it seems to be related to reboots, but i don't know what exactly triggers it. rmmod/modprobe doesn't trigger it. also, when the wrong GUID is reported, the only way of fixing it is to reboot. it really is just the GUID. even when the wrong one is reported, the device works just fine. i started with a plain ubuntu 9.10, kernel 2.6.31 which was supposed to fail, so i upgraded to a 2.6.32-rc8 to fix the iSight and some other things, just to see it fail again. a reboot later and it worked, some time and reboot later it failed again... rgds -daniel > > This patch add the other (wrong) GUID to the format table, making the iSight > > work always w/o other problems. > > > > What it should report: 32595559--0010-8000-00aa00389b71 > > What it often reports: 32595559--0010-8000-00389b71 > > > > Signed-off-by: Daniel Ritz > > -- > Regards, > > Laurent Pinchart Bus 001 Device 002: ID 05ac:8507 Apple, Inc. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 239 Miscellaneous Device bDeviceSubClass 2 ? bDeviceProtocol 1 Interface Association bMaxPacketSize064 idVendor 0x05ac Apple, Inc. idProduct 0x8507 bcdDevice4.19 iManufacturer 1 Apple Inc. iProduct2 Built-in iSight iSerial 3 8H99R02BW8DD3A1A bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 642 bNumInterfaces 3 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Association: bLength 8 bDescriptorType11 bFirstInterface 0 bInterfaceCount 2 bFunctionClass 14 Video bFunctionSubClass 3 Video Interface Collection bFunctionProtocol 0 iFunction 2 Built-in iSight Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass14 Video bInterfaceSubClass 1 Video Control bInterfaceProtocol 0 iInterface 2 Built-in iSight VideoControl Interface Descriptor: bLength13 bDescriptorType36 bDescriptorSubtype 1 (HEADER) bcdUVC 1.00 wTotalLength 51 dwClockFrequency4.00MHz bInCollection 1 baInterfaceNr( 0) 1 VideoControl Interface Descriptor: bLength18 bDescriptorType36 bDescriptorSubtype 2 (INPUT_TERMINAL) bTerminalID 1 wTerminalType 0x0201 Camera Sensor bAssocTerminal 0 iTerminal 0 wObjectiveFocalLengthMin 0 wObjectiveFocalLengthMax 0 wOcularFocalLength0 bControlSize 3 bmControls 0x000a Auto-Exposure Mode Exposure Time (Absolute) VideoControl Interface Descriptor: bLength 9 bDescriptorType36 bDescriptorSubtype 3 (OUTPUT_TERMINAL) bTerminalID 2 wTerminalType 0x0101 USB Streaming bAssocTerminal 0 bSourceID 3 iTerminal 0 VideoControl Interface Descriptor: bLength11 bDescriptorType36 bDescriptorSubtype 5 (PROCESSING_UNIT) Warning: Descriptor too short bUnitID 3 bSourceID 1 wMaxMultiplier 0 bControlSize2 bmControls 0x157f Brightness Contrast Hue Saturation Sharpness Gamma White Balance Temperature Backlight Compensation Power Line Frequency White Balance Temperature, Au
Re: V4L1 compatibility broken for VIDIOCGTUNER with radio
Am Donnerstag, den 03.12.2009, 21:04 -0200 schrieb Herton Ronaldo Krzesinski: > Em Qui 03 Dez 2009, às 19:54:29, hermann pitton escreveu: > > Hi, > > > > Am Donnerstag, den 03.12.2009, 16:56 -0200 schrieb Herton Ronaldo > > Krzesinski: > > > Hi, > > > > > > After commit 9bedc7f ("V4L/DVB (12429): v4l2-ioctl: fix G_STD and G_PARM > > > default handlers"), radio software using V4L1 stopped to work on a > > > saa7134 > > > card, a git bisect pointed to this commit introducing the regression. All > > > VIDIOCGTUNER calls on a v4l1 application are returning -EINVAL after this > > > commit. > > > > > > Investigating the issue, it turns out that v4l1_compat_get_tuner calls > > > VIDIOC_G_STD ioctl, but as it is a radio device (saa7134-radio) it now is > > > returning -EINVAL to user space applications which are being confused > > > about > > > this. > > > > > > May be VIDIOC_G_STD change in the commit above should be reverted, or > > > v4l1_compat_get_tuner changed to not return error with G_STD, or not call > > > G_STD ioctl for a radio device? > > > > > > -- > > > []'s > > > Herton > > > > it was fixed here. > > > > http://linuxtv.org/hg/v4l-dvb/rev/58ecda742a70 > > Indeed, thanks for the pointer. I forgot to check latest v4l1-compat.c /o\ > > > > > Maybe it was not ported to stable? > > Not on latest stable (2.6.31.6), perhaps it should be forwarded. > Yes, for sure. It's our fault. Seems we had an "internal server error" :( I came across it by accident. > The only other issue I'm aware of is that radio is broken since guessed > 8 weeks on my tuners, only realized when testing on enabling external > active antenna voltage for DVB-T on a/some 310i. I did the bisect with some delay and Hans marked the fix with priority "high", but we missed to point Mike at it for stable explicitly. Mike, please review and forward. Sorry, Hermann -- 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 another YUYV format GUID
Hi Daniel, On Wednesday 02 December 2009 00:48:44 Daniel Ritz wrote: > For some unknown reason, on a MacBookPro5,3 the iSight Could you please send me the output of lsusb -v both with the correct and wrong GUID ? > _sometimes_ report a different video format GUID. Sometimes only ? Now that's weird. Is that completely random ? > This patch add the other (wrong) GUID to the format table, making the iSight > work always w/o other problems. > > What it should report: 32595559--0010-8000-00aa00389b71 > What it often reports: 32595559--0010-8000-00389b71 > > Signed-off-by: Daniel Ritz -- 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: Replace Mercurial with GIT as SCM
Em Thu, 3 Dec 2009 22:42:38 +0100 (CET) Guennadi Liakhovetski escreveu: > On Thu, 3 Dec 2009, Hans Verkuil wrote: > > > On Wednesday 02 December 2009 04:55:00 Andy Walls wrote: > > > On Tue, 2009-12-01 at 15:59 +0100, Patrick Boettcher wrote: > > > > Hi all, > > > > > > > > I would like to start a discussion which ideally results in either > > > > changing the SCM of v4l-dvb to git _or_ leaving everything as it is > > > > today > > > > with mercurial. > > > > > > > > > > > > I'm waiting for comments. GIT. However, just using what we have in -hg at -git won't give much benefits. We should really move forward and use a clone of Linus tree. I intend to work on a way to allow us to move to -git, while preserving our building system. My target is to do it at the beginning of the next year. > > > > > > I only have one requirement: reduce bandwidth usage between the server > > > and my home. > > > > > > The less I have to clone out 65 M of history to start a new series of > > > patches the better. I suppose that would include a rebase... The first clone of the Linus -git tree will be more painful than 65 Mb of downloads Well, -git supports partial clone, were it discards the old history: $git help clone ... --depth Create a shallow clone with a history truncated to the specified number of revisions. A shallow repository has a number of limitations (you cannot clone or fetch from it, nor push from nor into it), but is adequate if you are only interested in the recent history of a large project with a long history, and would want to send in fixes as patches. ... I never used it, so I can't tell if this works properly. However, the big advantage with -git is that, once you have one local clone, you may do other clones that will use a shared repository of objects. Here, I use one git full clone of the Linus tree, created with: git clone --bare master-git-repo.git Being a bare tree, it will only contain the objects (we generally name bare repos with .git extension). Then, my -git working dirs are created with: git clone -s git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6.git This clone is very fast, since it is local and is sharing the bare objects. I then add, at myclone/.git/config two remote repositories, like: [remote "linus"] URL = /home/myhome/tokernel/bare/linus.git/ fetch = +refs/tags/*:refs/remotes/linus/* fetch = +refs/heads/master:refs/remotes/linus/upstream tagopt = --no-tags [remote "origin"] URL = ssh://my.remote.site.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git fetch = +refs/heads/*:refs/remotes/linux-2.6.git/* Push = refs/heads/*:refs/heads/* This way, every time I want to update from upstream or from my remote repo, I run a script with something like: $ (cd linux-2.6.git && git fetch) $ (cd myclone && git remote update) And, every time I want to push to my remote repo, i do: $ git push origin The advantage of having a bare directory is that I can have several other local git trees, each completely independent from the bare, and all with all the files checked-out. If you're doing lots of things at the same time, this is a way safer than using branches. Btw, git branch work really really well. Also, as git revlog provides a changelog history, you can do rollbacks if needed. Ah, with respect to rebase, the better way, IMHO, to rebase your directory is to create a new branch based on the latest upstream, pull the patches there, and then rebase. The big advantage is that you'll keep your old work untouched, so, if you do something wrong, you can simply delete the new branch an do it again. > > > > Unfortunately, one reason for moving to git would be to finally be able to > > make changes to the arch directory tree. The fact that that part is > > unavailable in v4l-dvb is a big problem when working with SoCs. And these > > will > > become much more important in the near future. > > FWIW, tomorrow (or a day or two later) I'll have to spend time again > back-porting arch changes from git to hg, to be able to push my current > patches... My current maintainership live is to do ports/backports between hg and git. This is very time demanding those days... Moving to git will be really great. 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: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Thu, 2009-12-03 at 19:10 -0200, Mauro Carvalho Chehab wrote: > Gerd Hoffmann wrote: > > > One final pass over the lirc interface would be good, taking the chance > > to fixup anything before the ABI is set in stone with the mainline > > merge. Things to look at: > > (3) Someone suggested a 'commit' ioctl which would activate > > the parameters set in (multiple) previous ioctls. Makes sense? > > A better approach is to create an ioctl that can send a group of > value/attribute pairs > at the same time. We used this estrategy for V4L extended controls to do > things like > setting an mpeg encoder (were we need to adjust several parameters at the > same time, > and adding all of them on one struct would be hard, since you can't specify > all > of them sa the same time). The same strategy is also used by DVB API to allow > it > to use any arbitrary protocol. It was conceived to support DVB-S2. Gerd, I mentioned it. The reason that I mentioned it is that partial configuration, before all the IOCTLs are done, of the IR chips that I work with *may* cause: 1. Unnecessary, extra I2C bus operations leading to delay on configuration. That's no big deal as it would really only matter for a genuine discrete CX2584x chip with IR implemented using the integrated IR controller. I do not know of any TV capture cards wired up like that. 2. If the Low Pass Filter gets turned off, or set to very short time interval, bad ambient light conditions could create an "interrupt storm". As soon as all the IOCTLs complete, the storm would stop. We can probably do without the change in lirc_dev ioctl() altogether, since it only *really* affects one set of chips that I work with, and only during configuration. I could instead implement interrupt storm detection and interrupt rate limiting for those devices. BTW IIRC, LIRC likes to resend the ioctl() to set the carrier frequency over again when it goes to transmit. That's kind of annoying, but I can work around that too by caching a copy of the carrier freq LIRC set the last time. Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: V4L1 compatibility broken for VIDIOCGTUNER with radio
Em Qui 03 Dez 2009, às 19:54:29, hermann pitton escreveu: > Hi, > > Am Donnerstag, den 03.12.2009, 16:56 -0200 schrieb Herton Ronaldo > Krzesinski: > > Hi, > > > > After commit 9bedc7f ("V4L/DVB (12429): v4l2-ioctl: fix G_STD and G_PARM > > default handlers"), radio software using V4L1 stopped to work on a saa7134 > > card, a git bisect pointed to this commit introducing the regression. All > > VIDIOCGTUNER calls on a v4l1 application are returning -EINVAL after this > > commit. > > > > Investigating the issue, it turns out that v4l1_compat_get_tuner calls > > VIDIOC_G_STD ioctl, but as it is a radio device (saa7134-radio) it now is > > returning -EINVAL to user space applications which are being confused about > > this. > > > > May be VIDIOC_G_STD change in the commit above should be reverted, or > > v4l1_compat_get_tuner changed to not return error with G_STD, or not call > > G_STD ioctl for a radio device? > > > > -- > > []'s > > Herton > > it was fixed here. > > http://linuxtv.org/hg/v4l-dvb/rev/58ecda742a70 Indeed, thanks for the pointer. I forgot to check latest v4l1-compat.c /o\ > > Maybe it was not ported to stable? Not on latest stable (2.6.31.6), perhaps it should be forwarded. > > Cheers, > Hermann -- []'s Herton -- 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: acks needed for arch/sh parts of the patches
On Thu, Dec 03, 2009 at 10:58:08PM +0100, Guennadi Liakhovetski wrote: > unfortunately 3 of my V4L patches for 2.6.33 have to touch arch/sh > simultaneously with drivers and headers. Therefore I need your acks to > them for arch parts. All those patches have already been posted to the > list at different times, here are links to them (perhaps, with some minor > differences): > > http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/13307 > http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/11492 > http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/11504 > > I will also send patches directly to you without cc-ing the list for > easier review. If you have no objections, you can just reply to this mail > confirming your 3 acks, if you have any comments, please reply to > respective mails, and then, please, add the v4l list back to cc. > Looks good to me. Acked-by: Paul Mundt -- 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] What are the goals for the architecture of an in-kernel IR system?
On Thu, Dec 03, 2009 at 10:51:00PM +0100, Christoph Bartelmus wrote: > Hi Mauro, > > on 03 Dec 09 at 19:10, Mauro Carvalho Chehab wrote: > [...] > >>> So the lirc_imon I submitted supports all device types, with the > >>> onboard decode devices defaulting to operating as pure input devices, > >>> but an option to pass hex values out via the lirc interface (which is > >>> how they've historically been used -- the pure input stuff I hacked > >>> together just a few weeks ago), to prevent functional setups from > >>> being broken for those who prefer the lirc way. > >> > >> Hmm. I'd tend to limit the lirc interface to the 'raw samples' case. > > >> Historically it has also been used to pass decoded data (i.e. rc5) from > >> devices with onboard decoding, but for that in-kernel mapping + input > >> layer really fits better. > > > I agree. > > Consider passing the decoded data through lirc_dev. > - there's a large user base already that uses this mode through lirc and > would be forced to switch to input layer if it disappears. I believe it was agreed that lirc-dev should be used mainly for decoding protocols that are more conveniently decoded in userspace and the results would be looped back into input layer through evdev which will be the main interface for consumer applications to use. -- Dmitry -- 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
Endless loop with error messages
Hello all After some uptime, I allways get an endless loop of these messages: Dec 3 21:55:21 mediaserv kernel: [118604.764577] saa7146: interrupt_hw(): warning: interrupt enabled, but not handled properly.(0xe7fcfbb7) Dec 3 21:55:21 mediaserv kernel: [118604.764580] saa7146: interrupt_hw(): disabling interrupt source(s)! Dec 3 21:55:21 mediaserv kernel: [118604.764591] saa7146 (1): unexpected i2c irq: isr e7fffbb7 psr ssr Dec 3 21:55:21 mediaserv kernel: [118604.764594] saa7146: interrupt_hw(): warning: interrupt enabled, but not handled properly.(0xe7fcfbb7) Dec 3 21:55:21 mediaserv kernel: [118604.764597] saa7146: interrupt_hw(): disabling interrupt source(s)! Dec 3 21:55:21 mediaserv kernel: [118604.765299] saa7146 (1): unexpected i2c irq: isr e7fffbb7 psr ssr Dec 3 21:55:21 mediaserv kernel: [118604.765302] saa7146: interrupt_hw(): warning: interrupt enabled, but not handled properly.(0xe7fcfbb7) Dec 3 21:55:21 mediaserv kernel: [118604.765305] saa7146: interrupt_hw(): disabling interrupt source(s)! Dec 3 21:55:21 mediaserv kernel: [118604.767852] saa7146 (3): unexpected i2c irq: isr e7fffbb7 psr ssr Dec 3 21:55:21 mediaserv kernel: [118604.767855] saa7146: interrupt_hw(): warning: interrupt enabled, but not handled properly.(0xe7fcfbb7) Dec 3 21:55:21 mediaserv kernel: [118604.767858] saa7146: interrupt_hw(): disabling interrupt source(s)! Dec 3 21:55:21 mediaserv kernel: [118604.775192] saa7146 (1): unexpected i2c irq: isr e7fffbb7 psr ssr Dec 3 21:55:21 mediaserv kernel: [118604.775194] saa7146: interrupt_hw(): warning: interrupt enabled, but not handled properly.(0xe7fcfbb7) Dec 3 21:55:21 mediaserv kernel: [118604.775197] saa7146: interrupt_hw(): disabling interrupt source(s)! Dec 3 21:55:21 mediaserv kernel: [118604.777377] saa7146 (3): unexpected i2c irq: isr e7fffbb7 psr ssr The CPU usage is 100% in both cores, and the machine is really locked. Login in console takes about 5minutes. Each keystroke around 20sec. I unloaded these modules budget_av budget_ci budget_core saa7146_vv saa7146 The the machine is usable again. Linux x 2.6.31.4 #3 SMP Mon Nov 16 12:29:18 CET 2009 x86_64 GNU/Linux -Ivo Steinmann -- 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: V4L1 compatibility broken for VIDIOCGTUNER with radio
Hi, Am Donnerstag, den 03.12.2009, 16:56 -0200 schrieb Herton Ronaldo Krzesinski: > Hi, > > After commit 9bedc7f ("V4L/DVB (12429): v4l2-ioctl: fix G_STD and G_PARM > default handlers"), radio software using V4L1 stopped to work on a saa7134 > card, a git bisect pointed to this commit introducing the regression. All > VIDIOCGTUNER calls on a v4l1 application are returning -EINVAL after this > commit. > > Investigating the issue, it turns out that v4l1_compat_get_tuner calls > VIDIOC_G_STD ioctl, but as it is a radio device (saa7134-radio) it now is > returning -EINVAL to user space applications which are being confused about > this. > > May be VIDIOC_G_STD change in the commit above should be reverted, or > v4l1_compat_get_tuner changed to not return error with G_STD, or not call > G_STD ioctl for a radio device? > > -- > []'s > Herton it was fixed here. http://linuxtv.org/hg/v4l-dvb/rev/58ecda742a70 Maybe it was not ported to stable? Cheers, Hermann -- 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: af9015: tuner id:179 not supported, please report!
On Thu, Dec 3, 2009 at 4:47 PM, Bert Massop wrote: > Hi Jan, > > The datasheet for the TDA18218 can be obtained from NXP: > http://www.nxp.com/documents/data_sheet/TDA18218HN.pdf > > That's all the information I have at the moment, maybe Mike has some > other information (like the Application Note mentioned in the > datasheet, that claims to contain information on writing drivers, but > cannot be found anywhere). > > Best regards, > > Bert Took a quick look at that datasheet. I would guess between that datasheet and a usbsnoop, there is probably enough there to write a driver that basically works for your particular hardware if you know what you are doing. The register map is abbreviated, but probably good enough... Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.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
acks needed for arch/sh parts of the patches
Hi Paul unfortunately 3 of my V4L patches for 2.6.33 have to touch arch/sh simultaneously with drivers and headers. Therefore I need your acks to them for arch parts. All those patches have already been posted to the list at different times, here are links to them (perhaps, with some minor differences): http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/13307 http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/11492 http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/11504 I will also send patches directly to you without cc-ing the list for easier review. If you have no objections, you can just reply to this mail confirming your 3 acks, if you have any comments, please reply to respective mails, and then, please, add the v4l list back to cc. 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
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
Hi Mauro, on 03 Dec 09 at 19:10, Mauro Carvalho Chehab wrote: [...] >>> So the lirc_imon I submitted supports all device types, with the >>> onboard decode devices defaulting to operating as pure input devices, >>> but an option to pass hex values out via the lirc interface (which is >>> how they've historically been used -- the pure input stuff I hacked >>> together just a few weeks ago), to prevent functional setups from >>> being broken for those who prefer the lirc way. >> >> Hmm. I'd tend to limit the lirc interface to the 'raw samples' case. >> Historically it has also been used to pass decoded data (i.e. rc5) from >> devices with onboard decoding, but for that in-kernel mapping + input >> layer really fits better. > I agree. Consider passing the decoded data through lirc_dev. - there's a large user base already that uses this mode through lirc and would be forced to switch to input layer if it disappears. - that way all IR drivers would consistently use lirc interface and all PnP hooks could be implemented there in one place. - drivers like lirc_imon that have to support both raw and decoded mode, currently have to implement both the lirc and the input interface. Complexity could be reduced in such cases. But maybe this is necessary anyway for lirc_imon that also includes mouse functionality. Jarod? Christoph -- 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: af9015: tuner id:179 not supported, please report!
Hi Jan, The datasheet for the TDA18218 can be obtained from NXP: http://www.nxp.com/documents/data_sheet/TDA18218HN.pdf That's all the information I have at the moment, maybe Mike has some other information (like the Application Note mentioned in the datasheet, that claims to contain information on writing drivers, but cannot be found anywhere). Best regards, Bert On Thu, Dec 3, 2009 at 22:15, Jan Sundman wrote: > > Hi Bert and Mike, > > The information that you have regarding the TDA18218, where can I get my > hands on that? It would be interesting to take a shot at writing the > driver, but I guess I would need some pointers in the right direction. > > Would it be possible to get the information from you, or is such > information freely available on the internet? Where should I start > looking? > > Best regards, > > //Jan > > On Wed, 2009-12-02 at 18:08 -0500, Michael Krufky wrote: > > On Wed, Dec 2, 2009 at 5:06 PM, Bert Massop wrote: > > > Jan Sundman aland.net> writes: > > > > > >> > > >> Hi, > > >> > > >> I just received a usb DVB-T card and have been trying to get it to work > > >> under Ubuntu 9.10, but to no avail. dmesg shows the following when > > >> plugging in the card: > > >> > > >> [ 35.280024] usb 2-1: new high speed USB device using ehci_hcd and > > >> address 4 > > >> [ 35.435978] usb 2-1: configuration #1 chosen from 1 choice > > >> [ 35.450176] af9015: tuner id:179 not supported, please report! > > >> [ 35.452891] Afatech DVB-T 2: Fixing fullspeed to highspeed interval: > > >> 10 -> 7 > > >> [ 35.453097] input: Afatech DVB-T 2 > > >> as /devices/pci:00/:00:13.2/usb2/2-1/2-1:1.1/input/input8 > > >> [ 35.453141] generic-usb 0003:15A4:9016.0005: input,hidraw3: USB HID > > >> v1.01 Keyboard [Afatech DVB-T 2] on usb-:00:13.2-1/input1 > > >> > > >> lsusb shows: > > >> Bus 002 Device 005: ID 15a4:9016 > > >> > > >> and finally lsmod | grep dvb > > >> dvb_usb_af9015 37152 0 > > >> dvb_usb 22892 1 dvb_usb_af9015 > > >> dvb_core 109716 1 dvb_usb > > >> > > >> While googling for an answer to my troubles I came across > > >> http://ubuntuforums.org/showthread.php?t=606487&page=5 which hints that > > >> the card may use the TDA18218HK tuner chip which does not seem to be > > >> supported currently. > > >> > > >> Does anyone have any experience regarding this chip and know what to do > > >> to get it working. > > >> > > >> Best regards, > > >> > > >> //Jan > > >> > > >> > > > > > > Hi Jan, > > > > > > As stated in the Ubuntuforums thread, there doesn't seem to be any > > > support for > > > this chip at the moment. I don't know how hard it is to code support for a > > > specific tuner, but I'm looking into that right now. > > > > > > Hopefully some more experienced coders will join in writing something > > > usable, as > > > I don't think I will be able to do it myself. > > > > > > Please drop a message if anyone finds something useful. > > > > > > Best regards, > > > > > > Bert > > > > The TDA18218 is not currently supported under Linux. I have the > > information needed to write a driver to support it, but I do not have > > any devices that use it, nor any interest (as of now) to write the > > driver on my own time. > > > > For me, it would not be very difficult to get this done, as I have > > done work to support a similar family of tuners -- TDA18271 / > > TDA18211. The TDA18218 tuner is not supported by the current driver. > > > > In the past, I would have gone ahead and written a driver for the > > sheer enjoyment of doing so... but nowadays, I actually have other > > projects of a higher priority that need my attention instead. > > > > If, in the future, any commercial entity has interest in seeing this > > tuner silicon supported under Linux, they should contact me -- perhaps > > my desire to write this driver can be increased ;-) > > > > Regards, > > > > Mike Krufky > > kernellabs.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 > > > -- > 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: How to help with RTL2832U based TV?
On 12/03/2009 10:09 PM, Peter Rasmussen wrote: as mentioned in the welcome email of this list, but it isn't apparent to me what the status in Linux of using a device based on this chip is? I have got today device having this chip (thanks to verkkokauppa.com for sponsoring) and I am going to implement the driver. I am in hope I can share some code from the old RTL2831U chip driver. I haven't looked driver code yet nor taken any sniffs. I will do that during next week. Anyhow, there is Realtek released driver spreading over the net for that chip, you can use it. Antti -- http://palosaari.fi/ -- 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: Replace Mercurial with GIT as SCM
On Thu, 3 Dec 2009, Hans Verkuil wrote: > On Wednesday 02 December 2009 04:55:00 Andy Walls wrote: > > On Tue, 2009-12-01 at 15:59 +0100, Patrick Boettcher wrote: > > > Hi all, > > > > > > I would like to start a discussion which ideally results in either > > > changing the SCM of v4l-dvb to git _or_ leaving everything as it is today > > > with mercurial. > > > > > > > > > I'm waiting for comments. > > > > I only have one requirement: reduce bandwidth usage between the server > > and my home. > > > > The less I have to clone out 65 M of history to start a new series of > > patches the better. I suppose that would include a rebase... > > Unfortunately, one reason for moving to git would be to finally be able to > make changes to the arch directory tree. The fact that that part is > unavailable in v4l-dvb is a big problem when working with SoCs. And these > will > become much more important in the near future. FWIW, tomorrow (or a day or two later) I'll have to spend time again back-porting arch changes from git to hg, to be able to push my current patches... 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
soc-camera: what's in the queue for 2.6.33
Hi all while waiting for (hopefully) an approval from Hans of my last mediabus version, and taking into account the freshly released 2.6.32, here are patches pending for 2.6.33: Guennadi Liakhovetski (14): soc-camera: remove no longer needed struct members v4l: add new v4l2-subdev sensor operations, use g_skip_top_lines in soc-camera soc-camera: fix multi-line comment coding style sh_mobile_ceu_camera: do not mark host occupied, when adding a client fails v4l: Add a 10-bit monochrome and missing 8- and 10-bit Bayer fourcc codes soc-camera: add a private field to struct soc_camera_link soc-camera: switch drivers and platforms to use .priv in struct soc_camera_link sh_mobile_ceu_camera: document the scaling and cropping algorithm mx3: add support for the mt9v022 camera sensor to pcm037 platform v4l: add a media-bus API for configuring v4l2 subdev pixel and frame formats soc-camera: convert to the new mediabus API rj54n1cb0c: Add cropping, auto white balance, restrict sizes, add platform data mt9t031: make the use of the soc-camera client API optional soc-camera: Add mt9t112 camera driver Kuninori Morimoto (14): tw9910: The driver can also handle revision 1 of the chip tw9910: Add revision control tw9910: simplify chip ID calculation tw9910: Tri-state pins when idle tw9910: Add power control tw9910: tw9910_set_hsync clean up tw9910: Add revision control to tw9910_set_hsync sh_mobile_ceu: Add V4L2_FIELD_INTERLACED_BT/TB support tw9910: use V4L2_FIELD_INTERLACED_BT sh_mobile_ceu_camera: Add support for sync polarity selection tw9910: modify V/H outpit pin setting to use VALID tw9910: modify output format tw9910: remove cropping tw9910: Add sync polarity support Please, everybody, have a look and let me know if anything is missing. The stack is also available for download from http://download.open-technology.de/soc-camera/20091203/ based on linux-next of today. Morimoto-san: I modified a bit your mt9t112 driver, apart from just porting it to the current mediabus version. Please check, if you agree with all changes and if it still works:-) Marek, I enabled the RGB555 and RGB565 formats in your ov9640 driver, would be cool if you could test it. 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
test
test -- 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: af9015: tuner id:179 not supported, please report!
Hi Bert and Mike, The information that you have regarding the TDA18218, where can I get my hands on that? It would be interesting to take a shot at writing the driver, but I guess I would need some pointers in the right direction. Would it be possible to get the information from you, or is such information freely available on the internet? Where should I start looking? Best regards, //Jan On Wed, 2009-12-02 at 18:08 -0500, Michael Krufky wrote: > On Wed, Dec 2, 2009 at 5:06 PM, Bert Massop wrote: > > Jan Sundman aland.net> writes: > > > >> > >> Hi, > >> > >> I just received a usb DVB-T card and have been trying to get it to work > >> under Ubuntu 9.10, but to no avail. dmesg shows the following when > >> plugging in the card: > >> > >> [ 35.280024] usb 2-1: new high speed USB device using ehci_hcd and > >> address 4 > >> [ 35.435978] usb 2-1: configuration #1 chosen from 1 choice > >> [ 35.450176] af9015: tuner id:179 not supported, please report! > >> [ 35.452891] Afatech DVB-T 2: Fixing fullspeed to highspeed interval: > >> 10 -> 7 > >> [ 35.453097] input: Afatech DVB-T 2 > >> as /devices/pci:00/:00:13.2/usb2/2-1/2-1:1.1/input/input8 > >> [ 35.453141] generic-usb 0003:15A4:9016.0005: input,hidraw3: USB HID > >> v1.01 Keyboard [Afatech DVB-T 2] on usb-:00:13.2-1/input1 > >> > >> lsusb shows: > >> Bus 002 Device 005: ID 15a4:9016 > >> > >> and finally lsmod | grep dvb > >> dvb_usb_af9015 37152 0 > >> dvb_usb22892 1 dvb_usb_af9015 > >> dvb_core 109716 1 dvb_usb > >> > >> While googling for an answer to my troubles I came across > >> http://ubuntuforums.org/showthread.php?t=606487&page=5 which hints that > >> the card may use the TDA18218HK tuner chip which does not seem to be > >> supported currently. > >> > >> Does anyone have any experience regarding this chip and know what to do > >> to get it working. > >> > >> Best regards, > >> > >> //Jan > >> > >> > > > > Hi Jan, > > > > As stated in the Ubuntuforums thread, there doesn't seem to be any support > > for > > this chip at the moment. I don't know how hard it is to code support for a > > specific tuner, but I'm looking into that right now. > > > > Hopefully some more experienced coders will join in writing something > > usable, as > > I don't think I will be able to do it myself. > > > > Please drop a message if anyone finds something useful. > > > > Best regards, > > > > Bert > > The TDA18218 is not currently supported under Linux. I have the > information needed to write a driver to support it, but I do not have > any devices that use it, nor any interest (as of now) to write the > driver on my own time. > > For me, it would not be very difficult to get this done, as I have > done work to support a similar family of tuners -- TDA18271 / > TDA18211. The TDA18218 tuner is not supported by the current driver. > > In the past, I would have gone ahead and written a driver for the > sheer enjoyment of doing so... but nowadays, I actually have other > projects of a higher priority that need my attention instead. > > If, in the future, any commercial entity has interest in seeing this > tuner silicon supported under Linux, they should contact me -- perhaps > my desire to write this driver can be increased ;-) > > Regards, > > Mike Krufky > kernellabs.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 -- 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] What are the goals for the architecture of an in-kernel IR system?
Gerd Hoffmann wrote: > One final pass over the lirc interface would be good, taking the chance > to fixup anything before the ABI is set in stone with the mainline > merge. Things to look at: > > (1) Make sure ioctl structs are 32/64 bit invariant. > (2) Maybe add some reserved fields to allow extending later > without breaking the ABI. > (3) Someone suggested a 'commit' ioctl which would activate > the parameters set in (multiple) previous ioctls. Makes sense? A better approach is to create an ioctl that can send a group of value/attribute pairs at the same time. We used this estrategy for V4L extended controls to do things like setting an mpeg encoder (were we need to adjust several parameters at the same time, and adding all of them on one struct would be hard, since you can't specify all of them sa the same time). The same strategy is also used by DVB API to allow it to use any arbitrary protocol. It was conceived to support DVB-S2. > (4) Add a ioctl to enable/disable evdev event submission for > evdev/lirc hybrid drivers. Yes, all above makes sense. > >> I'm still on the fence over what to do about lirc_imon. The driver >> supports essentially 3 generations of devices. First-gen is very old >> imon parts that don't do onboard decoding. Second-gen is the devices >> that all got (insanely stupidly) tagged with the exact same usb >> device ID (0x15c2:0xffdc), some of which have an attached VFD, some >> with an attached LCD, some with neither, some that are actually RF >> parts, but all (I think) of which do onboard decoding. Third-gen is >> the latest stuff, which is all pretty sane, unique device IDs for >> unique devices, onboard decoding, etc. > > Do have second-gen and third-gen devices have a 'raw mode'? If so, then > there should be a lirc interface for raw data access. > >> So the lirc_imon I submitted supports all device types, with the >> onboard decode devices defaulting to operating as pure input devices, >> but an option to pass hex values out via the lirc interface (which is >> how they've historically been used -- the pure input stuff I hacked >> together just a few weeks ago), to prevent functional setups from >> being broken for those who prefer the lirc way. > > Hmm. I'd tend to limit the lirc interface to the 'raw samples' case. > Historically it has also been used to pass decoded data (i.e. rc5) from > devices with onboard decoding, but for that in-kernel mapping + input > layer really fits better. I agree. > >> What I'm debating is whether this should be split into two drivers, >> one for the older devices that don't do onboard decoding (which would >> use the lirc_dev interface) called 'lirc_imon' or 'lirc_imon_legacy', >> and one that is a pure input driver, not unlike the ati_remote{,2} >> drivers, with no lirc_dev dependency at all, probably called simply >> 'imon'. > > i.e. lirc_imon would support first+second gen, and imon third-gen > devices, without overlap? > >> But if I split it out, there may end up being a >> fair amount of code duplication, > > You could try to split common code into a third module used by the other > two. Or have one module for all devices which is a evdev/lirc hybrid. > Splitting it into a core driver and two different drivers for raw/non-raw device makes sense to me. An alternative would be to have just one module, but splitting the code into 3 parts. This allows an easier understanding, IMHO. 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: [Bugme-new] [Bug 14564] New: capture-example sleeping function called from invalid context at arch/x86/mm/fault.c
On Wed, 2 Dec 2009, Sean wrote: > Is there anything I can do to help? This is a show stopping bug for me. Here's a patch you can try. It will add a _lot_ of debugging information to the system log. Maybe it will help pin down the source of the problem. Alan Stern Index: 2.6.31/drivers/usb/host/ohci-hcd.c === --- 2.6.31.orig/drivers/usb/host/ohci-hcd.c +++ 2.6.31/drivers/usb/host/ohci-hcd.c @@ -197,7 +197,7 @@ static int ohci_urb_enqueue ( /* allocate the TDs (deferring hash chain updates) */ for (i = 0; i < size; i++) { - urb_priv->td [i] = td_alloc (ohci, mem_flags); + urb_priv->td [i] = td_alloc (ohci, mem_flags, urb->dev, urb->ep); if (!urb_priv->td [i]) { urb_priv->length = i; urb_free_priv (ohci, urb_priv); Index: 2.6.31/drivers/usb/host/ohci-mem.c === --- 2.6.31.orig/drivers/usb/host/ohci-mem.c +++ 2.6.31/drivers/usb/host/ohci-mem.c @@ -82,7 +82,8 @@ dma_to_td (struct ohci_hcd *hc, dma_addr /* TDs ... */ static struct td * -td_alloc (struct ohci_hcd *hc, gfp_t mem_flags) +td_alloc (struct ohci_hcd *hc, gfp_t mem_flags, struct usb_device *udev, + struct usb_host_endpoint *ep) { dma_addr_t dma; struct td *td; @@ -94,6 +95,8 @@ td_alloc (struct ohci_hcd *hc, gfp_t mem td->hwNextTD = cpu_to_hc32 (hc, dma); td->td_dma = dma; /* hashed in td_fill */ + ohci_info(hc, "td alloc for %s ep%x: %p\n", + udev->devpath, ep->desc.bEndpointAddress, td); } return td; } @@ -103,8 +106,14 @@ td_free (struct ohci_hcd *hc, struct td { struct td **prev = &hc->td_hash [TD_HASH_FUNC (td->td_dma)]; - while (*prev && *prev != td) + ohci_info(hc, "td free %p\n", td); + while (*prev && *prev != td) { + if ((unsigned long) *prev == 0xa7a7a7a7) { + ohci_info(hc, "poisoned hash at %p\n", prev); + return; + } prev = &(*prev)->td_hash; + } if (*prev) *prev = td->td_hash; else if ((td->hwINFO & cpu_to_hc32(hc, TD_DONE)) != 0) Index: 2.6.31/drivers/usb/host/ohci-q.c === --- 2.6.31.orig/drivers/usb/host/ohci-q.c +++ 2.6.31/drivers/usb/host/ohci-q.c @@ -403,7 +403,7 @@ static struct ed *ed_get ( } /* dummy td; end of td list for ed */ - td = td_alloc (ohci, GFP_ATOMIC); + td = td_alloc (ohci, GFP_ATOMIC, udev, ep); if (!td) { /* out of memory */ ed_free (ohci, ed); -- 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 v2] Another approach to IR
Krzysztof Halasa wrote: > Mauro Carvalho Chehab writes: > >> Btw, looking at that code, while it is not impossible to split the >> IR pulse/space measures from the NEC decoder itself, and make it generic >> to support other protocols, it is not a trivial task, and may result on >> a less stable driver. > > And it's not needed at all. > Protocol decoders can be easily run in parallel, I've done it on saa713x > and this is trivial at least there. Can do that when the lirc interface > is available. >> The advantage of the NEC decoding approach on saa7134 is that you know for >> sure how much time it is required to get the entire code. So, the code >> can easily abort the reception of a bad code. The disadvantage is that >> only one protocol can be decoded at the same time. > > This isn't a hard thing to fix. Good to know. We're open to patches to improve it. The point is that we've got in the past several complains about saa713x machines hanging due to IRQ's generated by IR sensor port. We ended by adding an option to disable IR and a code at the driver that disables IR IRQ if it happens too often. > >> The same problem also happens with almost all in-kernel drivers: the decoders >> for raw mode were constructed to work with just one pulse/space code at the >> same time. A conversion into a generic code can happen, but it will require >> several tests to be sure that they won't cause undesirable side-effects. > > IOW any such receiver has to be tested, sure. > >> The advantage of hardware decoders is that you don't need to be polling the >> IR serial port at a high rate, as you'll get directly the code. So, you'll >> free the CPU to do something else. > > Which device requires polling the port? > Most are IRQ-driven, aren't they? Most of the devices that have a hardware IR decodes needs polling. Most of they simply outputs the scan code on some set of GPIO pins. In general, the devices with the IR sensor connected to a GPIO pin are IRQ-driven. 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
How to help with RTL2832U based TV?
I looked around in the archives of: http://dir.gmane.org/gmane.linux.drivers.video-input-infrastructure http://www.spinics.net/lists/linux-media/ as mentioned in the welcome email of this list, but it isn't apparent to me what the status in Linux of using a device based on this chip is? When inserting the USB dongle I get the following: Dec 3 20:56:22 kultorvet kernel: usb 1-1: new high speed USB device using ehci_hcd and address 5 Dec 3 20:56:22 kultorvet kernel: usb 1-1: New USB device found, idVendor=1d19, idProduct=1102 Dec 3 20:56:22 kultorvet kernel: usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Dec 3 20:56:22 kultorvet kernel: usb 1-1: Product: Rtl2832UDVB Dec 3 20:56:22 kultorvet kernel: usb 1-1: Manufacturer: Realtek Dec 3 20:56:22 kultorvet kernel: usb 1-1: SerialNumber: 1 Dec 3 20:56:22 kultorvet kernel: usb 1-1: configuration #1 chosen from 1 choice In Windows Vista it runs fine, showing TV using both MPEG2 and MPEG4 encoded signals, but I would much rather run it with Linux. I am also developing software for a living, but not this close to hardware, however I would like to help out the way I can. Thanks, Peter -- 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 - v1 1/2] V4L - vpfe capture - make clocks configurable
Hans, Please hold on to this. I will send you an updated patch. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com >-Original Message- >From: Karicheri, Muralidharan >Sent: Tuesday, December 01, 2009 12:22 PM >To: 'Hans Verkuil' >Cc: Hiremath, Vaibhav; linux-media@vger.kernel.org >Subject: FW: [PATCH - v1 1/2] V4L - vpfe capture - make clocks configurable > >Hans, > >Could you please add this to your hg tree and send a pull >request to Mauro? This was reviewed by Vaibhav and tested on >DM355, DM6446, AM3517 & DM365. I will request Kevin to pull >the Architecture part of this patch. > >Thanks. > >Murali Karicheri >Software Design Engineer >Texas Instruments Inc. >Germantown, MD 20874 >phone: 301-407-9583 >email: m-kariche...@ti.com > >>-Original Message- >>From: Karicheri, Muralidharan >>Sent: Tuesday, December 01, 2009 12:19 PM >>To: linux-media@vger.kernel.org; hverk...@xs4all.nl; >>khil...@deeprootsystems.com >>Cc: davinci-linux-open-sou...@linux.davincidsp.com; Hiremath, Vaibhav; >>Karicheri, Muralidharan >>Subject: [PATCH - v1 1/2] V4L - vpfe capture - make clocks configurable >> >>From: Muralidharan Karicheri >> >>v1 - updated based on comments from Vaibhav Hiremath. >> >>On DM365 we use only vpss master clock, where as on DM355 and >>DM6446, we use vpss master and slave clocks for vpfe capture and AM3517 >>we use internal clock and pixel clock. So this patch makes it configurable >>on a per platform basis. This is needed for supporting DM365 for which >>patches >>will be available soon. >> >>Tested-by: Vaibhav Hiremath , Muralidharan Karicheri >kariche...@ti.com> >>Acked-by: Vaibhav Hiremath >>Signed-off-by: Muralidharan Karicheri >>--- >> drivers/media/video/davinci/vpfe_capture.c | 98 +-- >- >>--- >> include/media/davinci/vpfe_capture.h | 11 ++- >> 2 files changed, 70 insertions(+), 39 deletions(-) >> >>diff --git a/drivers/media/video/davinci/vpfe_capture.c >>b/drivers/media/video/davinci/vpfe_capture.c >>index 12a1b3d..c3468ee 100644 >>--- a/drivers/media/video/davinci/vpfe_capture.c >>+++ b/drivers/media/video/davinci/vpfe_capture.c >>@@ -1787,61 +1787,87 @@ static struct vpfe_device *vpfe_initialize(void) >> return vpfe_dev; >> } >> >>+/** >>+ * vpfe_disable_clock() - Disable clocks for vpfe capture driver >>+ * @vpfe_dev - ptr to vpfe capture device >>+ * >>+ * Disables clocks defined in vpfe configuration. >>+ */ >> static void vpfe_disable_clock(struct vpfe_device *vpfe_dev) >> { >> struct vpfe_config *vpfe_cfg = vpfe_dev->cfg; >>+ int i; >> >>- clk_disable(vpfe_cfg->vpssclk); >>- clk_put(vpfe_cfg->vpssclk); >>- clk_disable(vpfe_cfg->slaveclk); >>- clk_put(vpfe_cfg->slaveclk); >>- v4l2_info(vpfe_dev->pdev->driver, >>- "vpfe vpss master & slave clocks disabled\n"); >>+ for (i = 0; i < vpfe_cfg->num_clocks; i++) { >>+ clk_disable(vpfe_dev->clks[i]); >>+ clk_put(vpfe_dev->clks[i]); >>+ } >>+ kfree(vpfe_dev->clks); >>+ v4l2_info(vpfe_dev->pdev->driver, "vpfe capture clocks disabled\n"); >> } >> >>+/** >>+ * vpfe_enable_clock() - Enable clocks for vpfe capture driver >>+ * @vpfe_dev - ptr to vpfe capture device >>+ * >>+ * Enables clocks defined in vpfe configuration. The function >>+ * assumes that at least one clock is to be defined which is >>+ * true as of now. re-visit this if this assumption is not true >>+ */ >> static int vpfe_enable_clock(struct vpfe_device *vpfe_dev) >> { >> struct vpfe_config *vpfe_cfg = vpfe_dev->cfg; >>- int ret = -ENOENT; >>+ int i; >> >>- vpfe_cfg->vpssclk = clk_get(vpfe_dev->pdev, "vpss_master"); >>- if (NULL == vpfe_cfg->vpssclk) { >>- v4l2_err(vpfe_dev->pdev->driver, "No clock defined for" >>- "vpss_master\n"); >>- return ret; >>- } >>+ if (!vpfe_cfg->num_clocks) >>+ return 0; >> >>- if (clk_enable(vpfe_cfg->vpssclk)) { >>- v4l2_err(vpfe_dev->pdev->driver, >>- "vpfe vpss master clock not enabled\n"); >>- goto out; >>- } >>- v4l2_info(vpfe_dev->pdev->driver, >>- "vpfe vpss master clock enabled\n"); >>+ vpfe_dev->clks = kzalloc(vpfe_cfg->num_clocks * >>+sizeof(struct clock *), GFP_KERNEL); >> >>- vpfe_cfg->slaveclk = clk_get(vpfe_dev->pdev, "vpss_slave"); >>- if (NULL == vpfe_cfg->slaveclk) { >>- v4l2_err(vpfe_dev->pdev->driver, >>- "No clock defined for vpss slave\n"); >>- goto out; >>+ if (NULL == vpfe_dev->clks) { >>+ v4l2_err(vpfe_dev->pdev->driver, "Memory allocation failed\n"); >>+ return -ENOMEM; >> } >> >>- if (clk_enable(vpfe_cfg->slaveclk)) { >>- v4l2_err(vpfe_dev->pdev->driver, >>- "vpfe vpss slave clock not enabled\n"); >>-
[PATCH -v2] Adding helper function to get dv preset description
From: Muralidharan Karicheri Updated based on comments against v1 of the patch This patch adds a helper function to get description of a digital video preset added by the video timing API. This will be usefull for drivers implementing the above API. NOTE: depends on the patch that adds video timing API. Signed-off-by: Muralidharan Karicheri Reviewed-by: Hans Verkuil --- Applies to V4L-DVB linux-next branch drivers/media/video/v4l2-common.c | 47 + include/media/v4l2-common.h |2 +- 2 files changed, 48 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/v4l2-common.c b/drivers/media/video/v4l2-common.c index e8e5aff..36b5cb8 100644 --- a/drivers/media/video/v4l2-common.c +++ b/drivers/media/video/v4l2-common.c @@ -1024,3 +1024,50 @@ void v4l_bound_align_image(u32 *w, unsigned int wmin, unsigned int wmax, } } EXPORT_SYMBOL_GPL(v4l_bound_align_image); + +/** + * v4l_fill_dv_preset_info - fill description of a digital video preset + * @preset - preset value + * @info - pointer to struct v4l2_dv_enum_preset + * + * drivers can use this helper function to fill description of dv preset + * in info. + */ +int v4l_fill_dv_preset_info(u32 preset, struct v4l2_dv_enum_preset *info) +{ + static const struct v4l2_dv_preset_info { + u16 width; + u16 height; + const char *name; + } dv_presets[] = { + { 0, 0, "Invalid" },/* V4L2_DV_INVALID */ + { 720, 480, "4...@59.94" },/* V4L2_DV_480P59_94 */ + { 720, 576, "5...@50" }, /* V4L2_DV_576P50 */ + { 1280, 720, "7...@24" }, /* V4L2_DV_720P24 */ + { 1280, 720, "7...@25" }, /* V4L2_DV_720P25 */ + { 1280, 720, "7...@30" }, /* V4L2_DV_720P30 */ + { 1280, 720, "7...@50" }, /* V4L2_DV_720P50 */ + { 1280, 720, "7...@59.94" },/* V4L2_DV_720P59_94 */ + { 1280, 720, "7...@60" }, /* V4L2_DV_720P60 */ + { 1920, 1080, "10...@29.97" }, /* V4L2_DV_1080I29_97 */ + { 1920, 1080, "10...@30" }, /* V4L2_DV_1080I30 */ + { 1920, 1080, "10...@25" }, /* V4L2_DV_1080I25 */ + { 1920, 1080, "10...@50" }, /* V4L2_DV_1080I50 */ + { 1920, 1080, "10...@60" }, /* V4L2_DV_1080I60 */ + { 1920, 1080, "10...@24" }, /* V4L2_DV_1080P24 */ + { 1920, 1080, "10...@25" }, /* V4L2_DV_1080P25 */ + { 1920, 1080, "10...@30" }, /* V4L2_DV_1080P30 */ + { 1920, 1080, "10...@50" }, /* V4L2_DV_1080P50 */ + { 1920, 1080, "10...@60" }, /* V4L2_DV_1080P60 */ + }; + + if (info == NULL || preset >= ARRAY_SIZE(dv_presets)) + return -EINVAL; + + info->preset = preset; + info->width = dv_presets[preset].width; + info->height = dv_presets[preset].height; + strlcpy(info->name, dv_presets[preset].name, sizeof(info->name)); + return 0; +} +EXPORT_SYMBOL_GPL(v4l_fill_dv_preset_info); diff --git a/include/media/v4l2-common.h b/include/media/v4l2-common.h index 1c25b10..1c7b259 100644 --- a/include/media/v4l2-common.h +++ b/include/media/v4l2-common.h @@ -212,5 +212,5 @@ void v4l_bound_align_image(unsigned int *w, unsigned int wmin, unsigned int *h, unsigned int hmin, unsigned int hmax, unsigned int halign, unsigned int salign); - +int v4l_fill_dv_preset_info(u32 preset, struct v4l2_dv_enum_preset *info); #endif /* V4L2_COMMON_H_ */ -- 1.6.0.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v0 1/2] V4L - vpfe capture - convert ccdc drivers to platform drivers
>> +#include >[Hiremath, Vaibhav] This should not be here, this should get handled in >board file. The driver should be generic. > See my comments against the platform part of this patch. >> #include >> #include >> #include "dm355_ccdc_regs.h" >> @@ -105,7 +106,6 @@ static struct ccdc_params_ycbcr >> ccdc_hw_params_ycbcr = { >> >> static enum vpfe_hw_if_type ccdc_if_type; >> static void *__iomem ccdc_base_addr; >> -static int ccdc_addr_size; >> >> /* Raw Bayer formats */ >> static u32 ccdc_raw_bayer_pix_formats[] = >> @@ -126,12 +126,6 @@ static inline void regw(u32 val, u32 offset) >> __raw_writel(val, ccdc_base_addr + offset); >> } >> >> -static void ccdc_set_ccdc_base(void *addr, int size) >> -{ >> -ccdc_base_addr = addr; >> -ccdc_addr_size = size; >> -} >> - >> static void ccdc_enable(int en) >> { >> unsigned int temp; >> @@ -938,7 +932,6 @@ static struct ccdc_hw_device ccdc_hw_dev = { >> .hw_ops = { >> .open = ccdc_open, >> .close = ccdc_close, >> -.set_ccdc_base = ccdc_set_ccdc_base, >> .enable = ccdc_enable, >> .enable_out_to_sdram = ccdc_enable_output_to_sdram, >> .set_hw_if_params = ccdc_set_hw_if_params, >> @@ -959,19 +952,89 @@ static struct ccdc_hw_device ccdc_hw_dev = { >> }, >> }; >> >> -static int __init dm355_ccdc_init(void) >> +static int __init dm355_ccdc_probe(struct platform_device *pdev) >> { >> -printk(KERN_NOTICE "dm355_ccdc_init\n"); >> -if (vpfe_register_ccdc_device(&ccdc_hw_dev) < 0) >> -return -1; >> +static resource_size_t res_len; >> +struct resource *res; >> +int status = 0; >> + >> +/** >> + * first try to register with vpfe. If not correct platform, >> then we >> + * don't have to iomap >> + */ >> +status = vpfe_register_ccdc_device(&ccdc_hw_dev); >> +if (status < 0) >> +return status; >> + >> +res = platform_get_resource(pdev, IORESOURCE_MEM, 0); >> +if (!res) { >> +status = -ENOENT; >[Hiremath, Vaibhav] I think right return value is -ENODEV. > Right. I will change it. >> +goto fail_nores; >> +} >> +res_len = res->end - res->start + 1; >> + >> +res = request_mem_region(res->start, res_len, res->name); >[Hiremath, Vaibhav] You should use "resource_size" here for res_len here. Ok. I didn't know about such a function :( Will change res_len -> resource_size(res) > >> +if (!res) { >> +status = -EBUSY; >> +goto fail_nores; >> +} >> + >> +ccdc_base_addr = ioremap_nocache(res->start, res_len); >> +if (!ccdc_base_addr) { >> +status = -EBUSY; >[Hiremath, Vaibhav] Is -EBUSY right return value, I think it should be - >ENXIO or -ENOMEM. > I see -ENXIO & -ENOMEM being used by drivers. -ENXIO stands for "No such device or address". ENOMEM stands for "Out of memory" . Since we are trying to map the address here, -ENXIO looks reasonable to me. Same if request_mem_region() fails. >> +goto fail; >> +} >> +/** >> + * setup Mux configuration for vpfe input and register >> + * vpfe capture platform device >> + */ >> +davinci_cfg_reg(DM355_VIN_PCLK); >> +davinci_cfg_reg(DM355_VIN_CAM_WEN); >> +davinci_cfg_reg(DM355_VIN_CAM_VD); >> +davinci_cfg_reg(DM355_VIN_CAM_HD); >> +davinci_cfg_reg(DM355_VIN_YIN_EN); >> +davinci_cfg_reg(DM355_VIN_CINL_EN); >> +davinci_cfg_reg(DM355_VIN_CINH_EN); >> + >[Hiremath, Vaibhav] This should not be here, this code must be generic and >might get used in another SoC. yes. See my suggestion against the architecture part. will be replaced with a setup_pinmux() fuction from platform_data. > >> printk(KERN_NOTICE "%s is registered with vpfe.\n", >> ccdc_hw_dev.name); >> return 0; >> +fail: >> +release_mem_region(res->start, res_len); >> +fail_nores: >> +vpfe_unregister_ccdc_device(&ccdc_hw_dev); >> +return status; >> } >> >> -static void __exit dm355_ccdc_exit(void) >> +static int dm355_ccdc_remove(struct platform_device *pdev) >> { >> +struct resource *res; >> + >> +iounmap(ccdc_base_addr); >> +res = platform_get_resource(pdev, IORESOURCE_MEM, 0); >> +if (res) >> +release_mem_region(res->start, res->end - res->start + >> 1); >[Hiremath, Vaibhav] Please use "resource_size" here for size. Ok. > >> vpfe_unregister_ccdc_device(&ccdc_hw_dev); >> +return 0; >> +} >> + >> +static struct platform_driver dm355_ccdc_driver = { >> +.driver = { >> +.name = "dm355_ccdc", >> +.owner = THIS_MODULE, >> +}, >> +.remove = __devexit_p(dm355_ccdc_remove), >> +.probe = dm355_ccdc_probe, >> +}; >> + >> +static int __init dm355_ccdc_init(void) >> +{ >> +return platform_driver_register(&dm355_ccdc_driver); >> +} >> + >> +static void __exit dm355_ccdc_exit(void) >> +{ >> +platform_driver_unregister(&dm355_ccdc_driver); >> } >>
[cron job] v4l-dvb daily build 2.6.22 and up: WARNINGS, 2.6.16-2.6.21: WARNINGS
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:Thu Dec 3 19:00:03 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 13538:e0cd9a337600 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.30-armv5: OK linux-2.6.31-armv5: OK linux-2.6.32-rc8-armv5: OK linux-2.6.32-rc8-armv5-davinci: OK linux-2.6.30-armv5-ixp: OK linux-2.6.31-armv5-ixp: OK linux-2.6.32-rc8-armv5-ixp: OK linux-2.6.30-armv5-omap2: OK linux-2.6.31-armv5-omap2: OK linux-2.6.32-rc8-armv5-omap2: OK linux-2.6.22.19-i686: OK linux-2.6.23.12-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30-i686: OK linux-2.6.31-i686: OK linux-2.6.32-rc8-i686: OK linux-2.6.30-m32r: OK linux-2.6.31-m32r: OK linux-2.6.32-rc8-m32r: OK linux-2.6.30-mips: OK linux-2.6.31-mips: OK linux-2.6.32-rc8-mips: OK linux-2.6.30-powerpc64: OK linux-2.6.31-powerpc64: OK linux-2.6.32-rc8-powerpc64: OK linux-2.6.22.19-x86_64: OK linux-2.6.23.12-x86_64: OK linux-2.6.24.7-x86_64: OK linux-2.6.25.11-x86_64: OK linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-x86_64: OK linux-2.6.31-x86_64: OK linux-2.6.32-rc8-x86_64: OK spec: OK sparse (linux-2.6.31): ERRORS sparse (linux-2.6.32-rc8): ERRORS linux-2.6.16.61-i686: WARNINGS linux-2.6.17.14-i686: WARNINGS linux-2.6.18.8-i686: WARNINGS linux-2.6.19.5-i686: WARNINGS linux-2.6.20.21-i686: WARNINGS linux-2.6.21.7-i686: WARNINGS linux-2.6.16.61-x86_64: WARNINGS linux-2.6.17.14-x86_64: WARNINGS linux-2.6.18.8-x86_64: WARNINGS linux-2.6.19.5-x86_64: WARNINGS linux-2.6.20.21-x86_64: WARNINGS linux-2.6.21.7-x86_64: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.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: [RFC v2] Another approach to IR
Quoting Jon Smirl : Now I understand that if 2 remotes send completely identical signals we won't be able to separate them, but in cases when we can I think we should. I don't have a problem with that, if its a truly desired feature. But for the most part, I don't see the point. Generally, you go from having multiple remotes, one per device (where "device" is your TV, amplifier, set top box, htpc, etc), to having a single universal remote that controls all of those devices. But for each device (IR receiver), *one* IR command set. The desire to use multiple distinct remotes with a single IR receiver doesn't make sense to me. Perhaps I'm just not creative enough in my use of IR. :) From a hobbiest's perspective there's likely rarely any reason to be able to do the same thing with two different remotes that send different signals, but i could see it come up - For example if you wanted to have both a feature-rich, busy/complicated remote but also wanted to provide a simpler remote with a relatively small number of large buttons on it for basic functions, as for children or people with poor eyesight or poor motor control. From a business perspective, I've worked for a company that sold turn-key video training systems, and depending on the whims of our so-called business partners and the desires of customers, there were as many as three distinct remotes that might get shipped with the training system, and they all sent different signals. That was a less than ideal situation, and if we had been really on top of things we'd have just declined to use any of those remotes and bought custom remotes from any of the numerous vendors that sell them which would allow us to have one set of IR signals used by remotes with different features - but for whatever reason that wasn't how management decided to do things. -- 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/2] DaVinci - vpfe capture - converting ccdc to platform driver
>> -/* >> - * setup Mux configuration for vpfe input and register >> - * vpfe capture platform device >> - */ >> -davinci_cfg_reg(DM355_VIN_PCLK); >> -davinci_cfg_reg(DM355_VIN_CAM_WEN); >> -davinci_cfg_reg(DM355_VIN_CAM_VD); >> -davinci_cfg_reg(DM355_VIN_CAM_HD); >> -davinci_cfg_reg(DM355_VIN_YIN_EN); >> -davinci_cfg_reg(DM355_VIN_CINL_EN); >> -davinci_cfg_reg(DM355_VIN_CINH_EN); >[Hiremath, Vaibhav] Why have you removed mux configuration from here and >moved to CCDC driver? Any specific reason? > Good catch. I wanted to do this clean up, but missed it. Actually platform data should have a function setup_pinmux() to set up the pin mux for the ccdc input. This function will be defined in the platform file and will be called during probe() Murali >> +platform_device_register(&dm355_ccdc_dev); >> platform_device_register(&vpfe_capture_dev); >> >> return 0; >> diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach- >> davinci/dm644x.c >> index 2cd0081..982be1f 100644 >> --- a/arch/arm/mach-davinci/dm644x.c >> +++ b/arch/arm/mach-davinci/dm644x.c >> @@ -612,6 +612,11 @@ static struct resource vpfe_resources[] = { >> .end= IRQ_VDINT1, >> .flags = IORESOURCE_IRQ, >> }, >> +}; >> + >> +static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32); >> +static struct resource dm644x_ccdc_resource[] = { >> +/* CCDC Base address */ >> { >> .start = 0x01c70400, >> .end= 0x01c70400 + 0xff, >> @@ -619,7 +624,17 @@ static struct resource vpfe_resources[] = { >> }, >> }; >> >> -static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32); >> +static struct platform_device dm644x_ccdc_dev = { >> +.name = "dm644x_ccdc", >> +.id = -1, >> +.num_resources = ARRAY_SIZE(dm644x_ccdc_resource), >> +.resource = dm644x_ccdc_resource, >> +.dev = { >> +.dma_mask = &vpfe_capture_dma_mask, >> +.coherent_dma_mask = DMA_BIT_MASK(32), >> +}, >> +}; >> + >> static struct platform_device vpfe_capture_dev = { >> .name = CAPTURE_DRV_NAME, >> .id = -1, >> @@ -772,6 +787,7 @@ static int __init dm644x_init_devices(void) >> platform_device_register(&dm644x_edma_device); >> platform_device_register(&dm644x_emac_device); >> platform_device_register(&dm644x_vpss_device); >> +platform_device_register(&dm644x_ccdc_dev); >> platform_device_register(&vpfe_capture_dev); >> >> return 0; >> -- >> 1.6.0.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFC] Document the videobuf layer
Jonathan Corbet wrote: > I've taken the liberty of dropping this into my docs-next tree, and > will send it upward unless there are objections. Hopefully it's > useful... Hi Jon, Thanks for the doc! I'll take a more detailed review, but I've added already some bits about videobuf at: Documentation/video4linux/v4l2-framework.txt Your documentation seems more complete on a very quick view, but it also seemed to have some duplicated info. Cheers, Mauro > > jon > --- > V4L2: Add a document describing the videobuf layer > > Videobuf is a moderately complex API which most V4L2 drivers should use, > but its documentation is...sparse. This document attempts to improve the > situation. > > Signed-off-by: Jonathan Corbet > > diff --git a/Documentation/video4linux/videobuf > b/Documentation/video4linux/videobuf > new file mode 100644 > index 000..4e21ea7 > --- /dev/null > +++ b/Documentation/video4linux/videobuf > @@ -0,0 +1,341 @@ > +An introduction to the videobuf layer > +Jonathan Corbet > +Current as of 2.6.32 > + > +The videobuf layer functions as a sort of glue layer between a V4L2 driver > +and user space. It handles the allocation and management of buffers for > +the storage of video frames. There is a set of functions which can be used > +to implement many of the standard POSIX I/O system calls, including read(), > +poll(), and, happily, mmap(). Another set of functions can be used to > +implement the bulk of the V4L2 ioctl() calls related to streaming I/O, > +including buffer allocation, queueing and dequeueing, and streaming > +control. Using videobuf imposes a few design decisions on the driver > +author, but the payback comes in the form of reduced code in the driver and > +a consistent implementation of the V4L2 user-space API. > + > +Buffer types > + > +Not all video devices use the same kind of buffers. In fact, there are (at > +least) three common variations: > + > + - Buffers which are scattered in both the physical and (kernel) virtual > + address spaces. All user-space buffers are like this, but it makes > + great sense to allocate kernel-space buffers this way as well when it is > + possible. Unfortunately, it is not always possible; working with this > + kind of buffer normally requires hardware which can do scatter/gather > + DMA operations. > + > + - Buffers which are physically scattered, but which are virtually > + contiguous; buffers allocated with vmalloc(), in other words. These > + buffers are just as hard to use for DMA operations, but they can be > + useful in situations where DMA is not available but virtually-contiguous > + buffers are convenient. > + > + - Buffers which are physically contiguous. Allocation of this kind of > + buffer can be unreliable on fragmented systems, but simpler DMA > + controllers cannot deal with anything else. > + > +Videobuf can work with all three types of buffers, but the driver author > +must pick one at the outset and design the driver around that decision. > + > +Data structures, callbacks, and initialization > + > +Depending on which type of buffers are being used, the driver should > +include one of the following files: > + > +/* Physically scattered */ > + /* vmalloc() buffers*/ > +/* Physically contiguous */ > + > +The driver's data structure describing a V4L2 device should include a > +struct videobuf_queue instance for the management of the buffer queue, > +along with a list_head for the queue of available buffers. There will also > +need to be an interrupt-safe spinlock which is used to protect (at least) > +the queue. > + > +The next step is to write four simple callbacks to help videobuf deal with > +the management of buffers: > + > +struct videobuf_queue_ops { > + int (*buf_setup)(struct videobuf_queue *q, > + unsigned int *count, unsigned int *size); > + int (*buf_prepare)(struct videobuf_queue *q, > +struct videobuf_buffer *vb, > +enum v4l2_field field); > + void (*buf_queue)(struct videobuf_queue *q, > + struct videobuf_buffer *vb); > + void (*buf_release)(struct videobuf_queue *q, > + struct videobuf_buffer *vb); > +}; > + > +buf_setup() is called early in the I/O process, when streaming is being > +initiated; its purpose is to tell videobuf about the I/O stream. The count > +parameter will be a suggested number of buffers to use; the driver should > +check it for rationality and adjust it if need be. As a practical rule, a > +minimum of two buffers are needed for proper streaming, and there is > +usually a maximum (which cannot exceed 32) which makes sense for each > +device. The size parameter should be set to the expected (maximum) size > +for each frame of data. > + > +Each buffer (in the form of a struct videobuf_buffer pointer) will be > +passed to buf_prepare(), which should set the buffer'
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Thu, Dec 3, 2009 at 12:55 PM, Dmitry Torokhov wrote: > On Thu, Dec 03, 2009 at 01:09:14PM +0100, Gerd Hoffmann wrote: >> On 12/03/09 05:29, Jarod Wilson wrote: >>> On Dec 1, 2009, at 10:28 AM, Gerd Hoffmann wrote: >>> > Anyway, we shouldn't postpone lirc drivers addition due to that. > There are still lots of work to do before we'll be able to split > the tables from the kernel drivers. Indeed. The sysfs bits are future work for both lirc and evdev drivers. There is no reason to make the lirc merge wait for it. >>> >>> At this point, my plan is to try to finish cleaning up lirc_dev and >>> lirc_mceusb at least over the weekend while at FUDCon up in Toronto, >>> and resubmit them next week. >> >> Good plan IMHO. Having lirc_dev merged quickly allows in-kernel drivers >> start supporting lirc. > > No, please, wait just a minute. I know it is tempting to just merge > lirc_dev and start working, but can we first agree on the overall > subsystem structure before doing so. It is still quite inclear to me. > > The open questions (for me at least): Great list, good starting point for evaluating the design alternatives. Have the various use cases all been enumerated? > - do we create a new class infrastructure for all receivers or only for > ones plugged into lirc_dev? Remember that classifying objects affects > how udev and friemds see them and may either help or hurt writing PnP > rules. > > - do we intend to support in-kernel sotfware decoders? What is the > structure? Do we organize them as a module to be used by driver > directly or the driver "streams" the data to IR core and the core > applies decoders (in the same fashion input events from drivers flow > into input core and then distributed to all bound interfaces for > processing/conversion/transmission to userspace)? > > - how do we control which decoder should handle particular > receiver/remote? Is it driver's decision, decoder's decision, user's > or all of the above? > > - do we allow to have several decoders active at once for a receiver? > > - who decides that we want to utilize lirc_dev? Driver's themselves, IR > core (looking at the driver/device "capabilities"), something else? Is the lirc device protocol documented? The lirc device only allows a single app to read from it, it that ok? What about the problem the mouse driver had with reading partial messages in one read and by the time you came back around to read the second half the first read was overwritten? That led to the transactions in evdev. > > - do we recognize and create input devices "on-fly" or require user > intervention? Semantics for splitting into several input/event > devices? Complete on-the-fly is not going to do what you want it to. For example Sony TVs use three variations of the Sony protocol in a single TV. A slick solution would have unknown IR events trigger a mapping definition app via udev. The mapping app would ask you to hit a few more keys until it locates the corresponding device profile in the IR database. Then it could write a script which will load create a new evdev device for this device and load the keycode map for it at boot. The big IR profile database from All-In-One is published. For this application you'd need to add entries mapping each IR code to a Linux keycode. This is the same problem you have with scancodes and various languages on keyboards. I'll bet the guys at http://www.openremote.org would help with this. > > Could anyone please draw me a picture, starting with a "receiver" > piece of hardware. I am not concerned much with how exactly receiver is > plugged into a particular subsystem (DVB/V4L etc) since it would be > _their_ implementation detail, but with the flow in/out of that > "receiver" device. > > Now as far as input core goes I see very limited number of changes that > may be needed: > > - Allow to extend size of "scancode" in EVIOC{S,G}KEYCODE if we are > unable to limit ourselves to 32 bits (keeping compatibility of course) > > - Maybe adding new ioctl to "zap" the keymap table > > - Adding more key EV_KEY/KEY_* definitons, if needed Aren't EV_IR events needed so that an app for building keymaps can be written? Normal apps would not use EV_IR events. -- Jon Smirl jonsm...@gmail.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
V4L1 compatibility broken for VIDIOCGTUNER with radio
Hi, After commit 9bedc7f ("V4L/DVB (12429): v4l2-ioctl: fix G_STD and G_PARM default handlers"), radio software using V4L1 stopped to work on a saa7134 card, a git bisect pointed to this commit introducing the regression. All VIDIOCGTUNER calls on a v4l1 application are returning -EINVAL after this commit. Investigating the issue, it turns out that v4l1_compat_get_tuner calls VIDIOC_G_STD ioctl, but as it is a radio device (saa7134-radio) it now is returning -EINVAL to user space applications which are being confused about this. May be VIDIOC_G_STD change in the commit above should be reverted, or v4l1_compat_get_tuner changed to not return error with G_STD, or not call G_STD ioctl for a radio device? -- []'s Herton -- 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] What are the goals for the architecture of an in-kernel IR system?
Let me draw my view: Em Thu, 3 Dec 2009 09:55:31 -0800 Dmitry Torokhov escreveu: > No, please, wait just a minute. I know it is tempting to just merge > lirc_dev and start working, but can we first agree on the overall > subsystem structure before doing so. It is still quite inclear to me. > > The open questions (for me at least): > > - do we create a new class infrastructure for all receivers or only for > ones plugged into lirc_dev? Remember that classifying objects affects > how udev and friemds see them and may either help or hurt writing PnP > rules. IMO, I would create it as /sys/class/input/IR (just like the /mice). I don't see why do we need to different lirc than no-lirc drivers in the case of sysfs class. As devices with raw input capabilities will have another dev to communicate, this means that we'll need a /lirc node there to point to lirc dev. > > - do we intend to support in-kernel sotfware decoders? Yes. > - What is the structure? Do we organize them as a module to be used by driver > directly or the driver "streams" the data to IR core and the core > applies decoders (in the same fashion input events from drivers flow > into input core and then distributed to all bound interfaces for > processing/conversion/transmission to userspace)? My plan is to expand ir-common.ko module and rename it to ir-core, to be the IR core module for the evdev interface. I'm already working on it. My idea for an architecture is that the lirc-core module will use ir-common where the IR decoders will be, and the evdev interface. IMO, we should move them from /drivers/media/common to /drivers/input/ir. It makes sense to use kfifo to send the data to the in-kernel decoders. > - how do we control which decoder should handle particular > receiver/remote? Is it driver's decision, decoder's decision, user's > or all of the above? It should be all the above, since some hardware will only work with certain decoders (hardware limitation) or they may have already a raw mode->scancode legacy decoder. In the latter case, those decoders will be removed from the existing drivers, but this action will take some time. Some sysfs attributes are needed to specify a list of the supported protocols and the currently used one. I'll prepare a proposed patch for it, after we finish aligning the requirements. > - do we allow to have several decorers active at once for a receiver? Yes, as an optional requirement, since some hardware won't support it. > - who decides that we want to utilize lirc_dev? Driver's themselves, IR > core (looking at the driver/device "capabilities"), something else? Drivers that support raw mode, should interface via lirc-core, that will, in turn use ir-core. Drivers that have in-hardware decode will directly use ir-core. > - do we recognize and create input devices "on-fly" or require user > intervention? Semantics for splitting into several input/event > devices? I don't have a strong opinion here. I don't see any way for doing it, except with very few protocols that sends vendor IDs. I don't care if this feature can be used by the drivers/decoders that could support it. > Could anyone please draw me a picture, starting with a "receiver" > piece of hardware. I am not concerned much with how exactly receiver is > plugged into a particular subsystem (DVB/V4L etc) since it would be > _their_ implementation detail, but with the flow in/out of that > "receiver" device. Not sure if I got your idea. Basically, what I see is: For device drivers that work in raw mode: [IR physical device] ==> [IR receiver driver] ==> [lirc-core] ==> [decoder] ==> [ir-core] ==> [evdev] (eventually, we can merge decoder and ir-core into one module at the beginning, depending on the size of the decoders) For device drivers that work only in evdev mode (those with hardware decoders): [IR physical device] ==> [IR receiver driver] ==> [ir-core] ==> [evdev] > > Now as far as input core goes I see very limited number of changes that > may be needed: > > - Allow to extend size of "scancode" in EVIOC{S,G}KEYCODE if we are > unable to limit ourselves to 32 bits (keeping compatibility of course) Yes, but the way EVIOC{S,G}KEYCODE currently works, it performs poorly when you have a table with 2^64 size. The table is very sparsed, but, as the key to get/set a code is the scancode, it is very hard to enumberate what are the actual entries there. The better is to use an index parameter for they, instead of using the scancode as such. > - Maybe adding new ioctl to "zap" the keymap table Yes, this is needed. > - Adding more key EV_KEY/KEY_* definitons, if needed Probably. -- 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
[PATCH, RFC] Document the videobuf layer
I've taken the liberty of dropping this into my docs-next tree, and will send it upward unless there are objections. Hopefully it's useful... jon --- V4L2: Add a document describing the videobuf layer Videobuf is a moderately complex API which most V4L2 drivers should use, but its documentation is...sparse. This document attempts to improve the situation. Signed-off-by: Jonathan Corbet diff --git a/Documentation/video4linux/videobuf b/Documentation/video4linux/videobuf new file mode 100644 index 000..4e21ea7 --- /dev/null +++ b/Documentation/video4linux/videobuf @@ -0,0 +1,341 @@ +An introduction to the videobuf layer +Jonathan Corbet +Current as of 2.6.32 + +The videobuf layer functions as a sort of glue layer between a V4L2 driver +and user space. It handles the allocation and management of buffers for +the storage of video frames. There is a set of functions which can be used +to implement many of the standard POSIX I/O system calls, including read(), +poll(), and, happily, mmap(). Another set of functions can be used to +implement the bulk of the V4L2 ioctl() calls related to streaming I/O, +including buffer allocation, queueing and dequeueing, and streaming +control. Using videobuf imposes a few design decisions on the driver +author, but the payback comes in the form of reduced code in the driver and +a consistent implementation of the V4L2 user-space API. + +Buffer types + +Not all video devices use the same kind of buffers. In fact, there are (at +least) three common variations: + + - Buffers which are scattered in both the physical and (kernel) virtual + address spaces. All user-space buffers are like this, but it makes + great sense to allocate kernel-space buffers this way as well when it is + possible. Unfortunately, it is not always possible; working with this + kind of buffer normally requires hardware which can do scatter/gather + DMA operations. + + - Buffers which are physically scattered, but which are virtually + contiguous; buffers allocated with vmalloc(), in other words. These + buffers are just as hard to use for DMA operations, but they can be + useful in situations where DMA is not available but virtually-contiguous + buffers are convenient. + + - Buffers which are physically contiguous. Allocation of this kind of + buffer can be unreliable on fragmented systems, but simpler DMA + controllers cannot deal with anything else. + +Videobuf can work with all three types of buffers, but the driver author +must pick one at the outset and design the driver around that decision. + +Data structures, callbacks, and initialization + +Depending on which type of buffers are being used, the driver should +include one of the following files: + + /* Physically scattered */ + /* vmalloc() buffers*/ + /* Physically contiguous */ + +The driver's data structure describing a V4L2 device should include a +struct videobuf_queue instance for the management of the buffer queue, +along with a list_head for the queue of available buffers. There will also +need to be an interrupt-safe spinlock which is used to protect (at least) +the queue. + +The next step is to write four simple callbacks to help videobuf deal with +the management of buffers: + +struct videobuf_queue_ops { + int (*buf_setup)(struct videobuf_queue *q, +unsigned int *count, unsigned int *size); + int (*buf_prepare)(struct videobuf_queue *q, + struct videobuf_buffer *vb, + enum v4l2_field field); + void (*buf_queue)(struct videobuf_queue *q, + struct videobuf_buffer *vb); + void (*buf_release)(struct videobuf_queue *q, + struct videobuf_buffer *vb); +}; + +buf_setup() is called early in the I/O process, when streaming is being +initiated; its purpose is to tell videobuf about the I/O stream. The count +parameter will be a suggested number of buffers to use; the driver should +check it for rationality and adjust it if need be. As a practical rule, a +minimum of two buffers are needed for proper streaming, and there is +usually a maximum (which cannot exceed 32) which makes sense for each +device. The size parameter should be set to the expected (maximum) size +for each frame of data. + +Each buffer (in the form of a struct videobuf_buffer pointer) will be +passed to buf_prepare(), which should set the buffer's size, width, height, +and field fields properly. If the buffer's state field is +VIDEOBUF_NEEDS_INIT, the driver should pass it to: + +int videobuf_iolock(struct videobuf_queue* q, struct videobuf_buffer *vb, + struct v4l2_framebuffer *fbuf); + +Among other things, this call will usually allocate memory for the buffer. +Finally, the buf_setup() function should set the buffer's state to +VIDEOBUF_PREPARED. + +When a buffer is queued for I/O, it is passed to buf_queue(), which
Re: [RFC v2] Another approach to IR
Mauro Carvalho Chehab writes: > Btw, looking at that code, while it is not impossible to split the > IR pulse/space measures from the NEC decoder itself, and make it generic > to support other protocols, it is not a trivial task, and may result on > a less stable driver. And it's not needed at all. Protocol decoders can be easily run in parallel, I've done it on saa713x and this is trivial at least there. Can do that when the lirc interface is available. > The advantage of the NEC decoding approach on saa7134 is that you know for > sure how much time it is required to get the entire code. So, the code > can easily abort the reception of a bad code. The disadvantage is that > only one protocol can be decoded at the same time. This isn't a hard thing to fix. > The same problem also happens with almost all in-kernel drivers: the decoders > for raw mode were constructed to work with just one pulse/space code at the > same time. A conversion into a generic code can happen, but it will require > several tests to be sure that they won't cause undesirable side-effects. IOW any such receiver has to be tested, sure. > The advantage of hardware decoders is that you don't need to be polling the > IR serial port at a high rate, as you'll get directly the code. So, you'll > free the CPU to do something else. Which device requires polling the port? Most are IRQ-driven, aren't they? -- Krzysztof Halasa -- 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 v2] Another approach to IR
Jarod Wilson writes: > Perhaps we should clarify something here. Are we intending to > auto-create a new input device for every IR command set we see arrive > at the IR receiver? We don't want this, and we aren't really able to do this, because we never know if two different scan codes are part of the same or different command set. Sharing the protocol and e.g. group code doesn't mean it's the same remote. Different protocol doesn't mean it's a different remote and what's more important, doesn't mean the user wants it to be a different logical remote. -- Krzysztof Halasa -- 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 v2] Another approach to IR
On Thu, Dec 03, 2009 at 02:33:56PM -0200, Mauro Carvalho Chehab wrote: > Ferenc Wagner wrote: > > Mauro Carvalho Chehab writes: > > We should not forget that simple IR's don't have any key to select the address, > so the produced codes there will never have KEY_TV/KEY_DVD, etc. Wait, wait, KEY_TV, KEY_DVD, KEY_TAPE - they should be used to select media inputs in a device/application. My receiver accepts codees like that. Yes, it seem that there is confusion here. Forget my proposition. It is a corner case that could be handled later if needed. Cheers, Emmanuel. -- 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 v2] Another approach to IR
Em Thu, 3 Dec 2009 11:50:04 -0500 Jon Smirl escreveu: > On Thu, Dec 3, 2009 at 11:33 AM, Mauro Carvalho Chehab > wrote: > > Ferenc Wagner wrote: > >> Mauro Carvalho Chehab writes: > >> > >>> Dmitry Torokhov wrote: > >>> > > > >> The interesting thing is that input.h defines KEY_TV, KEY_PC, KEY_SAT, > >> KEY_CD, KEY_TAPE etc., but no corresponding scan codes will ever be sent > >> by any remote (ok, I'm stretching it a bit). > > > > Unfortunately, this is not true. Some IR's do send a keycode for TV/PC/SAT/CD, etc. > > > > On those remotes, if you press TV and then press for example Channel UP > > and press Radio, then press Channel UP, the channel UP code will be the same. > > > > For example, on Hauppauge Grey IR, we have: > > > > > > [13425.128525] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e1c keycode 0x179 > > [13425.136733] ir_input_key_event: em28xx IR (em28xx #0): key event code=377 down=1 > > [13425.144170] ir_input_key_event: em28xx IR (em28xx #0): key event code=377 down=0 > > > > > > [13428.350223] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e20 keycode 0x192 > > [13428.358434] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 down=1 > > [13428.365871] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 down=0 > > > > > > [13430.672266] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e0c keycode 0x181 > > [13430.680473] ir_input_key_event: em28xx IR (em28xx #0): key event code=385 down=1 > > [13430.687913] ir_input_key_event: em28xx IR (em28xx #0): key event code=385 down=0 > > > > > > [13433.697268] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e20 keycode 0x192 > > [13433.705480] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 down=1 > > [13433.712916] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 down=0 > > > > In this IR, the address is bogus: it is always 0x1e. This scenario is very common with the > > shipped IR's. > > The remote is treating everything as a single integrated device which > is not inconsistent with what has been said. In this case there really > is only one multi-function device not two independent ones. > > If you want to control two independent devices you need to buy a > different remote. Remotes are cheap so that's not a big deal. > > If you really want to use this remote to control two independent > devices you need user space scripting to split the single device into > two devices and then inject new events into the input layer. This is a > complex case and not in the goal of getting 90% of users to "just > work". This remote is a typical example of the IR's that are provided together with media boards. On all such IR's I know, it does generate one key event for TV, SAT, DVB, DVD... keys and this event doesn't change the status of subsequent keys. 100% of the users of such boards will have the shipped IR. Some amount will be happy of just using the provided IR to control different applications at their computer or embedded hardware, and some amount will prefer to buy a multi-purpose IR that will allow him to control not only his computer, but also, his TV, his Air conditioning, etc. Both usages should be supported. All I'm saying is that, in the case where people have only the shipped IR, if he wants to see TV, the produced keycode will be KEY_TV, and then to change a channel, it will receive KEY_CHANNELUP, to control his TV app. When the user decides to switch to DVB, he will press KEY_DVB and then KEY_PLAY to play his movie. So, an application like MythTV should be able to work with those keys. Eeeerrrkkk, what a .. device . For such quirky device, we could imagine a special mapping support: We could maps scancode 0x1e1c and 0x1e0c special keycode wich inform the input layer to surcharge the vendor or device with a specific value/mask for following keypresses of such remote. The mask could be choose to generate out of bound value in regards of the used protocol for the vendor or the device part to not overlap with another existing remote. Generate a complete map and so a device for each special key and you're done. No special case on the application side. In kernel states are a bit ugly, but this particular case is not too complicated and your dumb shitty remote is promoted to first class one. Regards, Emmanuel. -- 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] What are the goals for the architecture of an in-kernel IR system?
On Thu, Dec 03, 2009 at 01:09:14PM +0100, Gerd Hoffmann wrote: > On 12/03/09 05:29, Jarod Wilson wrote: >> On Dec 1, 2009, at 10:28 AM, Gerd Hoffmann wrote: >> Anyway, we shouldn't postpone lirc drivers addition due to that. There are still lots of work to do before we'll be able to split the tables from the kernel drivers. >>> >>> Indeed. The sysfs bits are future work for both lirc and evdev >>> drivers. There is no reason to make the lirc merge wait for it. >> >> At this point, my plan is to try to finish cleaning up lirc_dev and >> lirc_mceusb at least over the weekend while at FUDCon up in Toronto, >> and resubmit them next week. > > Good plan IMHO. Having lirc_dev merged quickly allows in-kernel drivers > start supporting lirc. No, please, wait just a minute. I know it is tempting to just merge lirc_dev and start working, but can we first agree on the overall subsystem structure before doing so. It is still quite inclear to me. The open questions (for me at least): - do we create a new class infrastructure for all receivers or only for ones plugged into lirc_dev? Remember that classifying objects affects how udev and friemds see them and may either help or hurt writing PnP rules. - do we intend to support in-kernel sotfware decoders? What is the structure? Do we organize them as a module to be used by driver directly or the driver "streams" the data to IR core and the core applies decoders (in the same fashion input events from drivers flow into input core and then distributed to all bound interfaces for processing/conversion/transmission to userspace)? - how do we control which decoder should handle particular receiver/remote? Is it driver's decision, decoder's decision, user's or all of the above? - do we allow to have several decorers active at once for a receiver? - who decides that we want to utilize lirc_dev? Driver's themselves, IR core (looking at the driver/device "capabilities"), something else? - do we recognize and create input devices "on-fly" or require user intervention? Semantics for splitting into several input/event devices? Could anyone please draw me a picture, starting with a "receiver" piece of hardware. I am not concerned much with how exactly receiver is plugged into a particular subsystem (DVB/V4L etc) since it would be _their_ implementation detail, but with the flow in/out of that "receiver" device. Now as far as input core goes I see very limited number of changes that may be needed: - Allow to extend size of "scancode" in EVIOC{S,G}KEYCODE if we are unable to limit ourselves to 32 bits (keeping compatibility of course) - Maybe adding new ioctl to "zap" the keymap table - Adding more key EV_KEY/KEY_* definitons, if needed Thanks. -- Dmitry -- 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] What are the goals for the architecture of an in-kernel IR system?
Gerd Hoffmann writes: > I'd pick a more descriptive name like 'bundled_remote'. > Maybe an additional attribute could say which protocol the bundled > remote speaks (rc5, ...), so userspace could do something sensible by > default even if it has no data about the bundled remote. This is problematic since there can be more that one remote bundled. If we export the sensor (tuner etc) name, userspace can make some decision (or ask the user etc). The protocol alone won't help - the user will have to teach the system about the remote anyway. This should be made trivial at least for common protocols, though. > Name them by the hardware they are bundled with should work reasonable > well. I guess udev can look at parent PCI vendor/device and subsystem vendor/device for most PCI cases. Ditto with USB. For generic stuff like TSOP* coupled with a resistor and connected to RS232 port, we can't guess anyway. > We also could also provide a list of possible remotes directly via > sysfs The kernel has no way to _know_ this information. The policy is better handled in userland. >> Anyway, we shouldn't postpone lirc drivers addition due to that. Actually merging lirc is a prerequisite for a number of changes. -- Krzysztof Halasa -- 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] What are the goals for the architecture of an in-kernel IR system?
l...@bartelmus.de (Christoph Bartelmus) writes: > Currently I would tend to an approach like this: > - raw interface to userspace using LIRC > - fixed set of in-kernel decoders that can handle bundled remotes I'd modify it a bit: - raw interface to userspace using LIRC - fixed set of in-kernel decoders Longer term: Removing the key assignment tables from the kernel. Plug-and-play can be then achieved with udev. The only thing needed from the kernel is indicating the tuner/sensor type, udev can guess the bundled remote type. Porting the in-kernel drivers (such as ir-common) to LIRC interface (while not removing the input layer mode). -- Krzysztof Halasa -- 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 v2] Another approach to IR
On Thu, Dec 03, 2009 at 02:33:56PM -0200, Mauro Carvalho Chehab wrote: > Ferenc Wagner wrote: > > Mauro Carvalho Chehab writes: > > We should not forget that simple IR's don't have any key to select the > address, > so the produced codes there will never have KEY_TV/KEY_DVD, etc. Wait, wait, KEY_TV, KEY_DVD, KEY_TAPE - they should be used to select media inputs in a device/application. My receiver accepts codees like that. -- Dmitry -- 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 v2] Another approach to IR
Jon Smirl wrote: > On Wed, Dec 2, 2009 at 11:13 PM, Jarod Wilson wrote: >> On Dec 2, 2009, at 9:48 PM, Trent Piepho wrote: >> ... >> Now I understand that if 2 remotes send completely identical signals we >> won't be able to separate them, but in cases when we can I think we >> should. > I don't have a problem with that, if its a truly desired feature. But > for the most part, I don't see the point. Generally, you go from > having multiple remotes, one per device (where "device" is your TV, > amplifier, set top box, htpc, etc), to having a single universal remote > that controls all of those devices. But for each device (IR receiver), > *one* IR command set. The desire to use multiple distinct remotes with > a single IR receiver doesn't make sense to me. Perhaps I'm just not > creative enough in my use of IR. :) >>> Most universal remotes I'm familiar with emulate multiple remotes. I.e. >>> my tv remote generates one set of scancodes for the numeric keys. The DVD >>> remote generates a different set. The amplifier remote in "tv mode" >>> generates the same codes as the tv remote, and in "dvd mode" the same codes >>> as the dvd remote. From the perspective of the IR receiver there is no >>> difference between having both the DVD and TV remotes, or using the >>> aplifier remote to control both devices. >> Okay, in the above scenario, you've still got a single input device... >> >>> Now, my aplifier remote has a number of modes. Some control devices I >>> have, like "vcr mode", and there is nothing I can do about that. Some, >>> like "md mode" don't control devices I have. That means they are free to >>> do things on the computer. Someone else with the same remote (or any >>> number of remotes that use the same protocol and scancodes) might have >>> different devices. >>> >>> So I want my computer to do stuff when I push "JVC MD #xx" keys, but ignore >>> "JVC VCR #yyy" yets. Someone with an MD player and not a VCR would want to >>> opposite. Rather than force everyone to create custom keymaps, it's much >>> easier if we can use the standard keymaps from a database of common remotes >>> and simply tell mythtv to only use remote #xxx or not to use remote #yyy. >> Sure, but the key is that this can't be done automagically. The IR driver has no way of knowing that user A wants JVC MD keys handled and JVC VCR keys ignored, and user B wants vice versa, while user C wants both ignored, etc. This is somewhat tangential to whether or not there's a separate input device per "remote" though. You can use multiple remotes/protocols with a single input device or lirc device already (if the hardware doesn't have to be put explicitly into a mode to listen for that proto, of course, but then its a hardware decoding device feeding a single input device anyway, so...). >> >>> It sounds like you're thinking of a receiver that came bundled with a >>> remote and that's it. Not someone with a number of remotes that came with >>> different pieces of AV gear that they want to use with their computer. >> No, I just pick *one* remote and use it for everything, not schizophrenically hopping from one remote to another, expecting them all the be able to control everything. :) Its a hell of a lot easier to find buttons w/o looking at the remote if you always use the same one for everything, for one. >> >> Anyway, I think I'm talking myself in circles. Supporting multiple remotes via multiple input devices (or even via a single input device) isn't at all interesting to me for my own use, but if there really is demand for such support (and it appears there is), then fine, lets do it. > > Simple use case: > > You have a multifunction remote. Press the CABLE key - it sends out > commands that control the cable box, press the TV key - now the > commands control the TV, press CD - now the CD player, etc. > > Now imagine a headless Linux box running a music server and a home > automation app. Press the CD key - commands get routed to the music > server, press the AUX key - commands get routed to the home automation > app. > > This is accomplished by recognizing the device code part of the IR > signal and figuring out that there are two different device codes in > use. The commands of then routed to two evdev devices corresponding to > the two different device codes. > > Using things like Alt-Tab to switch apps is impossible. There's no > screen to look at. This usecase makes sense to me. With the risk of repeating myself, you don't have two physical remotes. The needed feature is a way to split one source of input events (that happens to be an infrared remote, but it could also be any other type of input device, like a bluetooth remote) into several different evdev interfaces, based on scancode groups. In real world you generally have two physical remote. In this particular case you simply have a sort of semi-universal remote, a two or tree in one remote. Mo
Re: [PATCH] atbm8830: replace 64-bit division and floating point usage
On Thu, 03 Dec 2009 21:57:02 +0800 David T. L. Wong wrote: > Randy Dunlap wrote: > > On Mon, 30 Nov 2009 10:07:21 -0800 Randy Dunlap wrote: > > > >> Stephen Rothwell wrote: > >>> Hi all, > >>> > >>> Changes since 20091127: > >>> > >>> The v4l-dvb tree lost its conflict. > >> > >> on i386 (X86_32): > >> > >> a 'double' variable is used, causing: > >> > >> ERROR: "__floatunsidf" [drivers/media/common/tuners/max2165.ko] undefined! > >> ERROR: "__adddf3" [drivers/media/common/tuners/max2165.ko] undefined! > >> ERROR: "__fixunsdfsi" [drivers/media/common/tuners/max2165.ko] undefined! > > > > > > linux-next-20091202: > > > > still have this one (above) and similar with > > drivers/media/dvb/frontends/atbm8830.c: > > > > drivers/built-in.o: In function `atbm8830_init': > > atbm8830.c:(.text+0x9012f9): undefined reference to `__udivdi3' > > atbm8830.c:(.text+0x901384): undefined reference to `__floatunsidf' > > atbm8830.c:(.text+0x901395): undefined reference to `__muldf3' > > atbm8830.c:(.text+0x9013a5): undefined reference to `__floatunsidf' > > atbm8830.c:(.text+0x9013b2): undefined reference to `__divdf3' > > atbm8830.c:(.text+0x9013c3): undefined reference to `__muldf3' > > atbm8830.c:(.text+0x9013cd): undefined reference to `__fixunsdfsi' > > > > --- > This patch replace 64-bit division by do_div() macro and remove usage of > floating point variable > > Signed-off-by: David T. L. Wong Acked-by: Randy Dunlap --- ~Randy -- 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] max2165 32bit build patch
On Thu, 03 Dec 2009 21:54:25 +0800 David T. L. Wong wrote: > Randy Dunlap wrote: > > On Mon, 30 Nov 2009 10:07:21 -0800 Randy Dunlap wrote: > > > >> Stephen Rothwell wrote: > >>> Hi all, > >>> > >>> Changes since 20091127: > >>> > >>> The v4l-dvb tree lost its conflict. > >> > >> on i386 (X86_32): > >> > >> a 'double' variable is used, causing: > >> > >> ERROR: "__floatunsidf" [drivers/media/common/tuners/max2165.ko] undefined! > >> ERROR: "__adddf3" [drivers/media/common/tuners/max2165.ko] undefined! > >> ERROR: "__fixunsdfsi" [drivers/media/common/tuners/max2165.ko] undefined! > > > > > > linux-next-20091202: > > > > still have this one (above) and similar with > > drivers/media/dvb/frontends/atbm8830.c: > > > > drivers/built-in.o: In function `atbm8830_init': > > atbm8830.c:(.text+0x9012f9): undefined reference to `__udivdi3' > > atbm8830.c:(.text+0x901384): undefined reference to `__floatunsidf' > > atbm8830.c:(.text+0x901395): undefined reference to `__muldf3' > > atbm8830.c:(.text+0x9013a5): undefined reference to `__floatunsidf' > > atbm8830.c:(.text+0x9013b2): undefined reference to `__divdf3' > > atbm8830.c:(.text+0x9013c3): undefined reference to `__muldf3' > > atbm8830.c:(.text+0x9013cd): undefined reference to `__fixunsdfsi' > > > > --- > > This patch drops usage of floating point variable for 32bit build > > Signed-off-by: David T. L. Wong Acked-by: Randy Dunlap Please generate patches so that they can be applied by using $ patch -p1 at the top of the kernel source tree. Thanks. --- ~Randy -- 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 v2] Another approach to IR
Em Thu, 3 Dec 2009 11:50:04 -0500 Jon Smirl escreveu: > On Thu, Dec 3, 2009 at 11:33 AM, Mauro Carvalho Chehab > wrote: > > Ferenc Wagner wrote: > >> Mauro Carvalho Chehab writes: > >> > >>> Dmitry Torokhov wrote: > >>> > > > >> The interesting thing is that input.h defines KEY_TV, KEY_PC, KEY_SAT, > >> KEY_CD, KEY_TAPE etc., but no corresponding scan codes will ever be sent > >> by any remote (ok, I'm stretching it a bit). > > > > Unfortunately, this is not true. Some IR's do send a keycode for > > TV/PC/SAT/CD, etc. > > > > On those remotes, if you press TV and then press for example Channel UP > > and press Radio, then press Channel UP, the channel UP code will be the > > same. > > > > For example, on Hauppauge Grey IR, we have: > > > > > > [13425.128525] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode > > 0x1e1c keycode 0x179 > > [13425.136733] ir_input_key_event: em28xx IR (em28xx #0): key event > > code=377 down=1 > > [13425.144170] ir_input_key_event: em28xx IR (em28xx #0): key event > > code=377 down=0 > > > > > > [13428.350223] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode > > 0x1e20 keycode 0x192 > > [13428.358434] ir_input_key_event: em28xx IR (em28xx #0): key event > > code=402 down=1 > > [13428.365871] ir_input_key_event: em28xx IR (em28xx #0): key event > > code=402 down=0 > > > > > > [13430.672266] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode > > 0x1e0c keycode 0x181 > > [13430.680473] ir_input_key_event: em28xx IR (em28xx #0): key event > > code=385 down=1 > > [13430.687913] ir_input_key_event: em28xx IR (em28xx #0): key event > > code=385 down=0 > > > > > > [13433.697268] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode > > 0x1e20 keycode 0x192 > > [13433.705480] ir_input_key_event: em28xx IR (em28xx #0): key event > > code=402 down=1 > > [13433.712916] ir_input_key_event: em28xx IR (em28xx #0): key event > > code=402 down=0 > > > > In this IR, the address is bogus: it is always 0x1e. This scenario is very > > common with the > > shipped IR's. > > The remote is treating everything as a single integrated device which > is not inconsistent with what has been said. In this case there really > is only one multi-function device not two independent ones. > > If you want to control two independent devices you need to buy a > different remote. Remotes are cheap so that's not a big deal. > > If you really want to use this remote to control two independent > devices you need user space scripting to split the single device into > two devices and then inject new events into the input layer. This is a > complex case and not in the goal of getting 90% of users to "just > work". This remote is a typical example of the IR's that are provided together with media boards. On all such IR's I know, it does generate one key event for TV, SAT, DVB, DVD... keys and this event doesn't change the status of subsequent keys. 100% of the users of such boards will have the shipped IR. Some amount will be happy of just using the provided IR to control different applications at their computer or embedded hardware, and some amount will prefer to buy a multi-purpose IR that will allow him to control not only his computer, but also, his TV, his Air conditioning, etc. Both usages should be supported. All I'm saying is that, in the case where people have only the shipped IR, if he wants to see TV, the produced keycode will be KEY_TV, and then to change a channel, it will receive KEY_CHANNELUP, to control his TV app. When the user decides to switch to DVB, he will press KEY_DVB and then KEY_PLAY to play his movie. So, an application like MythTV should be able to work with those keys. I don't see the need to create a separate code for KEY_PLAYDVB, as this can be simply mapped as KEY_DVB and KEY_PLAY. -- 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: [RFC v2] Another approach to IR
On Thu, Dec 3, 2009 at 11:33 AM, Mauro Carvalho Chehab wrote: > Ferenc Wagner wrote: >> Mauro Carvalho Chehab writes: >> >>> Dmitry Torokhov wrote: >>> > >> The interesting thing is that input.h defines KEY_TV, KEY_PC, KEY_SAT, >> KEY_CD, KEY_TAPE etc., but no corresponding scan codes will ever be sent >> by any remote (ok, I'm stretching it a bit). > > Unfortunately, this is not true. Some IR's do send a keycode for > TV/PC/SAT/CD, etc. > > On those remotes, if you press TV and then press for example Channel UP > and press Radio, then press Channel UP, the channel UP code will be the same. > > For example, on Hauppauge Grey IR, we have: > > > [13425.128525] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode > 0x1e1c keycode 0x179 > [13425.136733] ir_input_key_event: em28xx IR (em28xx #0): key event code=377 > down=1 > [13425.144170] ir_input_key_event: em28xx IR (em28xx #0): key event code=377 > down=0 > > > [13428.350223] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode > 0x1e20 keycode 0x192 > [13428.358434] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 > down=1 > [13428.365871] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 > down=0 > > > [13430.672266] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode > 0x1e0c keycode 0x181 > [13430.680473] ir_input_key_event: em28xx IR (em28xx #0): key event code=385 > down=1 > [13430.687913] ir_input_key_event: em28xx IR (em28xx #0): key event code=385 > down=0 > > > [13433.697268] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode > 0x1e20 keycode 0x192 > [13433.705480] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 > down=1 > [13433.712916] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 > down=0 > > In this IR, the address is bogus: it is always 0x1e. This scenario is very > common with the > shipped IR's. The remote is treating everything as a single integrated device which is not inconsistent with what has been said. In this case there really is only one multi-function device not two independent ones. If you want to control two independent devices you need to buy a different remote. Remotes are cheap so that's not a big deal. If you really want to use this remote to control two independent devices you need user space scripting to split the single device into two devices and then inject new events into the input layer. This is a complex case and not in the goal of getting 90% of users to "just work". > >> Instead, a multifunction >> remote (or two distinct remotes) would send different scan codes[1], >> which should be mapped to KEY_PLAYCD and KEY_PLAYDVD for example. >> Btw. the former is already defined, besides the generic KEY_PLAY. >> >> Even if all this worked, user space would need integration with >> hal/devicekit to open the new input devices appearing on the fly (if >> it's initiated by the arrival of a scan code belonging to some new >> protocol), and also be able to decide whether the new event source is >> for it or not. >> >> Given that commodity home appliances manage not to be confused by >> multiple or multifunction remotes, decent software should be able to do >> so as well. >> >> [1] scan codes in the broadest possible sense, containing vendor, >> address and whatever, and only treating the case which is possible to >> handle in principle. > > I see two alternatives for it: > 1) to map a multifunction scancode Address=TV/command=channel up as two > separate events: KEY_TV | KEY_CHANNELUP and let some userspace program to > handle it (lirc or other programs that knows IR keycodes); > > 2) to implement Jon's filter idea of splitting one evdev interface into > several evdevs interface, one for each address. > > We should not forget that simple IR's don't have any key to select the > address, > so the produced codes there will never have KEY_TV/KEY_DVD, etc. > > Cheers, > Mauro. > -- Jon Smirl jonsm...@gmail.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: [RFC v2] Another approach to IR
Ferenc Wagner wrote: > Mauro Carvalho Chehab writes: > >> Dmitry Torokhov wrote: >> > The interesting thing is that input.h defines KEY_TV, KEY_PC, KEY_SAT, > KEY_CD, KEY_TAPE etc., but no corresponding scan codes will ever be sent > by any remote (ok, I'm stretching it a bit). Unfortunately, this is not true. Some IR's do send a keycode for TV/PC/SAT/CD, etc. On those remotes, if you press TV and then press for example Channel UP and press Radio, then press Channel UP, the channel UP code will be the same. For example, on Hauppauge Grey IR, we have: [13425.128525] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e1c keycode 0x179 [13425.136733] ir_input_key_event: em28xx IR (em28xx #0): key event code=377 down=1 [13425.144170] ir_input_key_event: em28xx IR (em28xx #0): key event code=377 down=0 [13428.350223] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e20 keycode 0x192 [13428.358434] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 down=1 [13428.365871] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 down=0 [13430.672266] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e0c keycode 0x181 [13430.680473] ir_input_key_event: em28xx IR (em28xx #0): key event code=385 down=1 [13430.687913] ir_input_key_event: em28xx IR (em28xx #0): key event code=385 down=0 [13433.697268] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e20 keycode 0x192 [13433.705480] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 down=1 [13433.712916] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 down=0 In this IR, the address is bogus: it is always 0x1e. This scenario is very common with the shipped IR's. > Instead, a multifunction > remote (or two distinct remotes) would send different scan codes[1], > which should be mapped to KEY_PLAYCD and KEY_PLAYDVD for example. > Btw. the former is already defined, besides the generic KEY_PLAY. > > Even if all this worked, user space would need integration with > hal/devicekit to open the new input devices appearing on the fly (if > it's initiated by the arrival of a scan code belonging to some new > protocol), and also be able to decide whether the new event source is > for it or not. > > Given that commodity home appliances manage not to be confused by > multiple or multifunction remotes, decent software should be able to do > so as well. > > [1] scan codes in the broadest possible sense, containing vendor, > address and whatever, and only treating the case which is possible to > handle in principle. I see two alternatives for it: 1) to map a multifunction scancode Address=TV/command=channel up as two separate events: KEY_TV | KEY_CHANNELUP and let some userspace program to handle it (lirc or other programs that knows IR keycodes); 2) to implement Jon's filter idea of splitting one evdev interface into several evdevs interface, one for each address. We should not forget that simple IR's don't have any key to select the address, so the produced codes there will never have KEY_TV/KEY_DVD, etc. 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
[PATCH - v1] V4L - Documentation:Adds EBUSY error code for S_STD and QUERYSTD ioctls
From: Muralidharan Karicheri During review of Video Timing API documentation, Hans Verkuil had a comment on adding EBUSY error code for VIDIOC_S_STD and VIDIOC_QUERYSTD ioctls. This patch updates the document for this. Signed-off-by: Muralidharan Karicheri --- diff -uNr v4l-dvb-e0cd9a337600_master/linux/Documentation/DocBook/v4l/vidioc-g-std.xml v4l-dvb_patch1/linux/Documentation/DocBook/v4l/vidioc-g-std.xml --- v4l-dvb-e0cd9a337600_master/linux/Documentation/DocBook/v4l/vidioc-g-std.xml 2009-12-01 17:02:04.0 -0500 +++ v4l-dvb_patch1/linux/Documentation/DocBook/v4l/vidioc-g-std.xml 2009-12-03 11:18:34.0 -0500 @@ -86,6 +86,12 @@ VIDIOC_S_STD parameter was unsuitable. + + EBUSY + + The device is busy and therefore can not change the standard + + diff -uNr v4l-dvb-e0cd9a337600_master/linux/Documentation/DocBook/v4l/vidioc-querystd.xml v4l-dvb_patch1/linux/Documentation/DocBook/v4l/vidioc-querystd.xml --- v4l-dvb-e0cd9a337600_master/linux/Documentation/DocBook/v4l/vidioc-querystd.xml 2009-12-01 17:02:04.0 -0500 +++ v4l-dvb_patch1/linux/Documentation/DocBook/v4l/vidioc-querystd.xml 2009-12-03 11:18:44.0 -0500 @@ -70,6 +70,12 @@ This ioctl is not supported. + + EBUSY + + The device is busy and therefore can not detect the standard + + -- 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: [linux-dvb] ds3000.c driver question (Tevii S660 USB DVB-S/S2 tuner)
Dear Michael, We have update Linux driver released today; you can find it from the link below http://www.tevii.com/Support.asp TeVii Support -Original Message- From: linux-dvb-boun...@linuxtv.org [mailto:linux-dvb-boun...@linuxtv.org] On Behalf Of Michael Durket Sent: Wednesday, December 02, 2009 10:39 PM To: linux-...@linuxtv.org Subject: [linux-dvb] ds3000.c driver question (Tevii S660 USB DVB-S/S2 tuner) I have some questions about the ds3000.c driver. I (and also someone at Tevii at my request) have attempted to contact the driver author to no avail. Is there anyone here familiar enough with that driver (and the firmware) that can answer some detailed questions about the device? ___ linux-dvb users mailing list For V4L/DVB development, please use instead linux-media@vger.kernel.org linux-...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb -- 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] V4L/DVB: pms: KERNEL_VERSION requires version.h
On Thu, 3 Dec 2009 12:48:27 +0300 Alexander Beregalov wrote: > Fix this build error: > drivers/media/video/pms.c:682: error: implicit declaration of function > 'KERNEL_VERSION' > > Signed-off-by: Alexander Beregalov I've already sent this patch, so I can also ack it... Acked-by: Randy Dunlap > --- > drivers/media/video/pms.c |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/drivers/media/video/pms.c b/drivers/media/video/pms.c > index 00228d5..a118bb1 100644 > --- a/drivers/media/video/pms.c > +++ b/drivers/media/video/pms.c > @@ -35,6 +35,7 @@ > #include > #include > #include > +#include > > #include > > -- --- ~Randy -- 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 v2] Another approach to IR
Mauro Carvalho Chehab writes: > Dmitry Torokhov wrote: > > On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote: > >> Now I understand that if 2 remotes send completely identical >> signals we won't be able to separete them, but in cases when we >> can I think we should. >> >> They are the same key events (Lets's say KEY_PLAY) but one is >> supposed to affect CD player while another DVD player >> application. Evdev will not be able to distinguish them but if we had >> 2 separate devices then applications could read from the one thet >> user assigned to them. > > This is clear, but the point is that the two distinguish scancodes can > (and, in practice, will) be generated by the same IR. For example, my > Satellite IR produces two different sets of codes. if you press , > all keys you press after that will have the "sat" address. If you > press , they'll get a different address. The interesting thing is that input.h defines KEY_TV, KEY_PC, KEY_SAT, KEY_CD, KEY_TAPE etc., but no corresponding scan codes will ever be sent by any remote (ok, I'm stretching it a bit). Instead, a multifunction remote (or two distinct remotes) would send different scan codes[1], which should be mapped to KEY_PLAYCD and KEY_PLAYDVD for example. Btw. the former is already defined, besides the generic KEY_PLAY. Even if all this worked, user space would need integration with hal/devicekit to open the new input devices appearing on the fly (if it's initiated by the arrival of a scan code belonging to some new protocol), and also be able to decide whether the new event source is for it or not. Given that commodity home appliances manage not to be confused by multiple or multifunction remotes, decent software should be able to do so as well. [1] scan codes in the broadest possible sense, containing vendor, address and whatever, and only treating the case which is possible to handle in principle. -- Regards, Feri. -- 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 - v0 2/2] DaVinci - vpfe capture - Make clocks configurable
>I was talking to Sekhar about this and actually he made some good points >about this implementation. > >If we consider specific IP, then the required clocks would remain always be >the same. There might be some devices which may not be using some clocks >(so as that specific feature). > >Actually we are trying to create one more wrapper for clock configuration. >Just to illustrate I am putting some other generic drivers examples - > >Omap-hsmmc.c - > >This driver requires 2 clocks, interface and functional. The devices which >would be using this driver have to define clock with names "ick" and "fck". > >VPFE-Capture (Considering only current implementation) - > >Currently we have vpfe_capture.c file (master/bridge driver) which is >handling clk_get/put, and platform data is providing the details about it. >Ideally we should handle it in respective ccdc driver file, since he has >all the knowledge about required number of clocks and its name. This way we >don't have to maintain/pass clock information in platform data. > >I would appreciate any comments/thoughts/pointers here. > Though I agree that this clock could be set by the ccdc driver, I am not sure if the same clock is used by an IP on different SOCs. For example take the case of ccdc on DM6446 which is also used on OMAP 35xx SOC. Do they use vpss master and slave clocks as is done on DM6446? If this is true, then we could set the clock inside ccdc driver. Let me know so that I can re-work the patch and send it to the list. Murali >Thanks, >Vaibhav > >> }; >> >> static struct platform_device *davinci_evm_devices[] __initdata = { >> diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c >> b/arch/arm/mach-davinci/board-dm644x-evm.c >> index fd0398b..45beb99 100644 >> --- a/arch/arm/mach-davinci/board-dm644x-evm.c >> +++ b/arch/arm/mach-davinci/board-dm644x-evm.c >> @@ -250,6 +250,8 @@ static struct vpfe_config vpfe_cfg = { >> .sub_devs = vpfe_sub_devs, >> .card_name = "DM6446 EVM", >> .ccdc = "DM6446 CCDC", >> +.num_clocks = 2, >> +.clocks = {"vpss_master", "vpss_slave"}, >> }; >> >> static struct platform_device rtc_dev = { >> -- >> 1.6.0.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Syncing videobuf buffers before an operation
Hello! We have been facing the problem of sync()ing buffers before performing operations on them. This is the current buffer life cycle in videobuf (for streaming, slightly simplified): - qbuf: buf_prepare, from which drivers call videobuf_iolock() if the state is VIDEOBUF_NEEDS_INIT (i.e. once per streamon) - dqbuf: where per-memory method sync() is called - streamoff: where buffers are released (i.e. iolock is "released") We are working with devices that have a non-coherent cache (ARM-based). For them sync()ing means flushing CPU cache for the physical memory to contain valid data. We require syncing buffers not only after, but before running the operation as well. For CAPTURE devices this prevents corruption in case a flush occurs after the operation has finished and overwrites the results with old data (from before the operation). For OUTPUT-type devices sync()ing is even more important, as the source data may be completely invalid before the operation - before DMA can be started, CPU cache has to be flushed. We have divided sync operations into the following types: - sync CAPTURE buffers before the operation - sync CAPTURE buffers after the operation - sync OUTPUT buffers before the operation Our idea is to add an additional sync() call to videobuf_qbuf and a parameter that would allow differentiating between syncs before and after the operation. Alternatively, an additional function for that could be added, if we don't want to change the API. Please note that this is different from iolock(). Iolock is performed once per streamon and what we need is a sync (which should also be more lightweight than a full iolock) per each qbuf. I would be grateful for your opinions on this topic. We'd like to propose a patch if we come to an agreement on this as well. Thank you! Best regards -- Pawel Osciak Linux Platform Group Samsung Poland R&D Center -- 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
Fwd: DVB-APPS patch for uk-WinterHill
Since 02 Dec 2009 the UK WinterHill transmitter site has been broadcasting on different frequencies & in a different mode with different modulation. Channels have been re-arranged to occupy five multiplexes and the original BBC 'B' mux is now broadcasting DVB-T2 for high definition services (which of course cannot yet be tuned by mere mortals). The 'WinterHill B' transmitter stopped broadcasting on 02 Dec. The attached file is a patch to reflect these changes. NOTE: All UK DVB-T services will eventually be moving to 8k mode in 64QAM & other local frequencies will be changing once DSO (digital switch over) is complete in each area. Hope this info is of use to you folks :-) Regards, Justin uk-WinterHill.patch --- uk-WinterHill 2009-12-03 14:30:32.0 + +++ uk-WinterHill.new 2009-12-03 14:26:05.0 + @@ -1,13 +1,11 @@ # UK, Winter Hill -# Auto-generated from http://www.dtg.org.uk/retailer/dtt_channels.html -# and http://www.ofcom.org.uk/static/reception_advice/index.asp.html +# Populated by J. Hornsby from a scan of active multiplexes # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy -T 754167000 8MHz 3/4 NONE QAM16 2k 1/32 NONE -T 834167000 8MHz 2/3 NONE QAM64 2k 1/32 NONE -T 850167000 8MHz 2/3 NONE QAM64 2k 1/32 NONE -T 842167000 8MHz 3/4 NONE QAM16 2k 1/32 NONE -T 786167000 8MHz 3/4 NONE QAM16 2k 1/32 NONE -T 810167000 8MHz 3/4 NONE QAM16 2k 1/32 NONE -# UK, Winter Hill B -T 65000 8MHz 3/4 NONE QAM16 2k 1/32 NONE -T 62600 8MHz 3/4 NONE QAM16 2k 1/32 NONE +T 74600 8MHz 2/3 NONE QAM64 8k 1/32 NONE +T 77000 8MHz 2/3 NONE QAM64 8k 1/32 NONE +T 77800 8MHz 2/3 NONE QAM64 8k 1/32 NONE +T 79400 8MHz 2/3 NONE QAM64 8k 1/32 NONE +T 801833000 8MHz 2/3 NONE QAM64 8k 1/32 NONE + +# UK, Winter Hill B Ceased broadcasting on 02 December 2009 + --- uk-WinterHill 2009-12-03 14:30:32.0 + +++ uk-WinterHill.new 2009-12-03 14:26:05.0 + @@ -1,13 +1,11 @@ # UK, Winter Hill -# Auto-generated from http://www.dtg.org.uk/retailer/dtt_channels.html -# and http://www.ofcom.org.uk/static/reception_advice/index.asp.html +# Populated by J. Hornsby from a scan of active multiplexes # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy -T 754167000 8MHz 3/4 NONE QAM16 2k 1/32 NONE -T 834167000 8MHz 2/3 NONE QAM64 2k 1/32 NONE -T 850167000 8MHz 2/3 NONE QAM64 2k 1/32 NONE -T 842167000 8MHz 3/4 NONE QAM16 2k 1/32 NONE -T 786167000 8MHz 3/4 NONE QAM16 2k 1/32 NONE -T 810167000 8MHz 3/4 NONE QAM16 2k 1/32 NONE -# UK, Winter Hill B -T 65000 8MHz 3/4 NONE QAM16 2k 1/32 NONE -T 62600 8MHz 3/4 NONE QAM16 2k 1/32 NONE +T 74600 8MHz 2/3 NONE QAM64 8k 1/32 NONE +T 77000 8MHz 2/3 NONE QAM64 8k 1/32 NONE +T 77800 8MHz 2/3 NONE QAM64 8k 1/32 NONE +T 79400 8MHz 2/3 NONE QAM64 8k 1/32 NONE +T 801833000 8MHz 2/3 NONE QAM64 8k 1/32 NONE + +# UK, Winter Hill B Ceased broadcasting on 02 December 2009 +
RE: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-timings
Hans, Thanks for sending this pull request. No problem in my name being mentioned in the spec. Thanks. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com >-Original Message- >From: Hans Verkuil [mailto:hverk...@xs4all.nl] >Sent: Wednesday, December 02, 2009 11:40 PM >To: linux-media@vger.kernel.org >Cc: Mauro Carvalho Chehab; Karicheri, Muralidharan >Subject: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-timings > >Hi Mauro, > >Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-timings for >the following: > >- v4l: Adding Digital Video Timings APIs >- v4l2-spec: Digital Video Timings API documentation >- v4l2-spec: updated revision history, updated version to 2.6.33. > >Murali, I've added you as one of the authors of the v4l2-spec (you did this >timings API after all) and included your email as well. If that is a >problem >for you (either being mentioned at all, or that your email is mentioned), >then >let me know asap and I'll remove it. I don't expect it to be a problem >since >all this information is already public. > >Mauro, before adding these documentation patches it is probably a good idea >to build and release a final 2.6.32 version of the documentation on >http://www.linuxtv.org/docs.php. > >If you want to see an example of this api being used, then take a look at >the >tvp7002 driver patches that have been posted recently. I expect that driver >to be merged soon after this pull request is merged. > >Thanks, > >Hans > >diffstat: > b/linux/Documentation/DocBook/v4l/vidioc-enum-dv-presets.xml | 238 >+++ > b/linux/Documentation/DocBook/v4l/vidioc-g-dv-preset.xml | 111 + > b/linux/Documentation/DocBook/v4l/vidioc-g-dv-timings.xml| 224 >++ > b/linux/Documentation/DocBook/v4l/vidioc-query-dv-preset.xml | 85 +++ > linux/Documentation/DocBook/media-entities.tmpl | 18 > linux/Documentation/DocBook/media-indices.tmpl |4 > linux/Documentation/DocBook/v4l/common.xml | 35 + > linux/Documentation/DocBook/v4l/compat.xml | 16 > linux/Documentation/DocBook/v4l/v4l2.xml | 26 + > linux/Documentation/DocBook/v4l/videodev2.h.xml | 116 + > linux/Documentation/DocBook/v4l/vidioc-enuminput.xml | 36 + > linux/Documentation/DocBook/v4l/vidioc-enumoutput.xml| 36 + > linux/drivers/media/video/v4l2-compat-ioctl32.c |6 > linux/drivers/media/video/v4l2-ioctl.c | 147 ++ > linux/include/linux/videodev2.h | 116 + > linux/include/media/v4l2-ioctl.h | 15 > linux/include/media/v4l2-subdev.h| 21 > media-specs/Makefile | 14 > 18 files changed, 1252 insertions(+), 12 deletions(-)
[PULL] http://kernellabs.com/hg/~mkrufky/hcw-ids
Mauro, Please pull from: http://kernellabs.com/hg/~mkrufky/hcw-ids for: - smsusb: add autodetection support for five additional Hauppauge USB IDs smsusb.c | 10 ++ 1 file changed, 10 insertions(+) Regards, Mike -- 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] atbm8830: replace 64-bit division and floating point usage
Randy Dunlap wrote: On Mon, 30 Nov 2009 10:07:21 -0800 Randy Dunlap wrote: Stephen Rothwell wrote: Hi all, Changes since 20091127: The v4l-dvb tree lost its conflict. on i386 (X86_32): a 'double' variable is used, causing: ERROR: "__floatunsidf" [drivers/media/common/tuners/max2165.ko] undefined! ERROR: "__adddf3" [drivers/media/common/tuners/max2165.ko] undefined! ERROR: "__fixunsdfsi" [drivers/media/common/tuners/max2165.ko] undefined! linux-next-20091202: still have this one (above) and similar with drivers/media/dvb/frontends/atbm8830.c: drivers/built-in.o: In function `atbm8830_init': atbm8830.c:(.text+0x9012f9): undefined reference to `__udivdi3' atbm8830.c:(.text+0x901384): undefined reference to `__floatunsidf' atbm8830.c:(.text+0x901395): undefined reference to `__muldf3' atbm8830.c:(.text+0x9013a5): undefined reference to `__floatunsidf' atbm8830.c:(.text+0x9013b2): undefined reference to `__divdf3' atbm8830.c:(.text+0x9013c3): undefined reference to `__muldf3' atbm8830.c:(.text+0x9013cd): undefined reference to `__fixunsdfsi' --- ~Randy -- 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 This patch replace 64-bit division by do_div() macro and remove usage of floating point variable Signed-off-by: David T. L. Wong diff --git a/linux/drivers/media/dvb/frontends/atbm8830.c b/linux/drivers/media/dvb/frontends/atbm8830.c --- a/linux/drivers/media/dvb/frontends/atbm8830.c +++ b/linux/drivers/media/dvb/frontends/atbm8830.c @@ -19,6 +19,7 @@ *Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. */ +#include #include "dvb_frontend.h" #include "atbm8830.h" @@ -102,8 +103,12 @@ static int set_osc_freq(struct atbm_state *priv, u32 freq /*in kHz*/) { u32 val; + u64 t; - val = (u64)0x10 * freq / 30400; + /* 0x10 * freq / 30.4MHz */ + t = (u64)0x10 * freq; + do_div(t, 30400); + val = t; atbm8830_write_reg(priv, REG_OSC_CLK, val); atbm8830_write_reg(priv, REG_OSC_CLK + 1, val >> 8); @@ -116,14 +121,18 @@ { u32 fs = priv->config->osc_clk_freq; - double t; + u64 t; u32 val; u8 dat; - t = 2 * 3.141593 * (freq - fs) / fs * (1 << 22); - val = t; + if (freq != 0) { + /* 2 * PI * (freq - fs) / fs * (2 ^ 22) */ + t = (u64) 2 * 31416 * (freq - fs); + t <<= 22; + do_div(t, fs); + do_div(t, 1000); + val = t; - if (freq != 0) { atbm8830_write_reg(priv, REG_TUNER_BASEBAND, 1); atbm8830_write_reg(priv, REG_IF_FREQ, val); atbm8830_write_reg(priv, REG_IF_FREQ+1, val >> 8);
[PATCH] max2165 32bit build patch
Randy Dunlap wrote: On Mon, 30 Nov 2009 10:07:21 -0800 Randy Dunlap wrote: Stephen Rothwell wrote: Hi all, Changes since 20091127: The v4l-dvb tree lost its conflict. on i386 (X86_32): a 'double' variable is used, causing: ERROR: "__floatunsidf" [drivers/media/common/tuners/max2165.ko] undefined! ERROR: "__adddf3" [drivers/media/common/tuners/max2165.ko] undefined! ERROR: "__fixunsdfsi" [drivers/media/common/tuners/max2165.ko] undefined! linux-next-20091202: still have this one (above) and similar with drivers/media/dvb/frontends/atbm8830.c: drivers/built-in.o: In function `atbm8830_init': atbm8830.c:(.text+0x9012f9): undefined reference to `__udivdi3' atbm8830.c:(.text+0x901384): undefined reference to `__floatunsidf' atbm8830.c:(.text+0x901395): undefined reference to `__muldf3' atbm8830.c:(.text+0x9013a5): undefined reference to `__floatunsidf' atbm8830.c:(.text+0x9013b2): undefined reference to `__divdf3' atbm8830.c:(.text+0x9013c3): undefined reference to `__muldf3' atbm8830.c:(.text+0x9013cd): undefined reference to `__fixunsdfsi' --- ~Randy -- 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 This patch drops usage of floating point variable for 32bit build Signed-off-by: David T. L. Wong diff --git a/linux/drivers/media/common/tuners/max2165.c b/linux/drivers/media/common/tuners/max2165.c --- a/linux/drivers/media/common/tuners/max2165.c +++ b/linux/drivers/media/common/tuners/max2165.c @@ -193,7 +193,7 @@ { u8 tf; u8 tf_ntch; - double t; + u32 t; u32 quotient, fraction; /* Set PLL divider according to RF frequency */ @@ -217,9 +217,6 @@ t += (priv->tf_balun_hi_ref - priv->tf_balun_low_ref) * (freq / 1000 - 47) / (78 - 47); -#if 0 - tf = t + 0.5; /* round up */ -#endif tf = t; dprintk("tf = %X\n", tf); tf |= tf_ntch << 4;
[PATCH v2 3/3] radio-si470x: support PM functions
This patch is to support PM of the si470x i2c driver. Signed-off-by: Joonyoung Shim --- drivers/media/radio/si470x/radio-si470x-i2c.c | 40 + 1 files changed, 40 insertions(+), 0 deletions(-) diff --git a/drivers/media/radio/si470x/radio-si470x-i2c.c b/drivers/media/radio/si470x/radio-si470x-i2c.c index 77532e6..4c6e586 100644 --- a/drivers/media/radio/si470x/radio-si470x-i2c.c +++ b/drivers/media/radio/si470x/radio-si470x-i2c.c @@ -486,6 +486,44 @@ static __devexit int si470x_i2c_remove(struct i2c_client *client) } +#ifdef CONFIG_PM +/* + * si470x_i2c_suspend - suspend the device + */ +static int si470x_i2c_suspend(struct i2c_client *client, pm_message_t mesg) +{ + struct si470x_device *radio = i2c_get_clientdata(client); + + /* power down */ + radio->registers[POWERCFG] |= POWERCFG_DISABLE; + if (si470x_set_register(radio, POWERCFG) < 0) + return -EIO; + + return 0; +} + + +/* + * si470x_i2c_resume - resume the device + */ +static int si470x_i2c_resume(struct i2c_client *client) +{ + struct si470x_device *radio = i2c_get_clientdata(client); + + /* power up : need 110ms */ + radio->registers[POWERCFG] |= POWERCFG_ENABLE; + if (si470x_set_register(radio, POWERCFG) < 0) + return -EIO; + msleep(110); + + return 0; +} +#else +#define si470x_i2c_suspend NULL +#define si470x_i2c_resume NULL +#endif + + /* * si470x_i2c_driver - i2c driver interface */ @@ -496,6 +534,8 @@ static struct i2c_driver si470x_i2c_driver = { }, .probe = si470x_i2c_probe, .remove = __devexit_p(si470x_i2c_remove), + .suspend= si470x_i2c_suspend, + .resume = si470x_i2c_resume, .id_table = si470x_i2c_id, }; -- 1.6.3.3 -- 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 2/3] radio-si470x: support RDS on si470x i2c driver
This patch is to support RDS on si470x i2c driver. The routine of RDS operation is almost same with thing of usb driver, but this uses RDS interrupt. Signed-off-by: Joonyoung Shim --- drivers/media/radio/si470x/radio-si470x-i2c.c | 164 +++-- drivers/media/radio/si470x/radio-si470x.h |1 + 2 files changed, 155 insertions(+), 10 deletions(-) diff --git a/drivers/media/radio/si470x/radio-si470x-i2c.c b/drivers/media/radio/si470x/radio-si470x-i2c.c index 6a40db8..5466015 100644 --- a/drivers/media/radio/si470x/radio-si470x-i2c.c +++ b/drivers/media/radio/si470x/radio-si470x-i2c.c @@ -22,22 +22,17 @@ */ -/* - * ToDo: - * - RDS support - */ - - /* driver definitions */ #define DRIVER_AUTHOR "Joonyoung Shim "; -#define DRIVER_KERNEL_VERSION KERNEL_VERSION(1, 0, 0) +#define DRIVER_KERNEL_VERSION KERNEL_VERSION(1, 0, 1) #define DRIVER_CARD "Silicon Labs Si470x FM Radio Receiver" #define DRIVER_DESC "I2C radio driver for Si470x FM Radio Receivers" -#define DRIVER_VERSION "1.0.0" +#define DRIVER_VERSION "1.0.1" /* kernel includes */ #include #include +#include #include "radio-si470x.h" @@ -62,6 +57,20 @@ static int radio_nr = -1; module_param(radio_nr, int, 0444); MODULE_PARM_DESC(radio_nr, "Radio Nr"); +/* RDS buffer blocks */ +static unsigned int rds_buf = 100; +module_param(rds_buf, uint, 0444); +MODULE_PARM_DESC(rds_buf, "RDS buffer entries: *100*"); + +/* RDS maximum block errors */ +static unsigned short max_rds_errors = 1; +/* 0 means 0 errors requiring correction */ +/* 1 means 1-2 errors requiring correction (used by original USBRadio.exe) */ +/* 2 means 3-5 errors requiring correction */ +/* 3 means 6+ errors or errors in checkword, correction not possible */ +module_param(max_rds_errors, ushort, 0644); +MODULE_PARM_DESC(max_rds_errors, "RDS maximum block errors: *1*"); + /** @@ -181,12 +190,21 @@ int si470x_fops_open(struct file *file) mutex_lock(&radio->lock); radio->users++; - if (radio->users == 1) + if (radio->users == 1) { /* start radio */ retval = si470x_start(radio); + if (retval < 0) + goto done; + + /* enable RDS interrupt */ + radio->registers[SYSCONFIG1] |= SYSCONFIG1_RDSIEN; + radio->registers[SYSCONFIG1] &= ~SYSCONFIG1_GPIO2; + radio->registers[SYSCONFIG1] |= 0x1 << 2; + retval = si470x_set_register(radio, SYSCONFIG1); + } +done: mutex_unlock(&radio->lock); - return retval; } @@ -242,6 +260,105 @@ int si470x_vidioc_querycap(struct file *file, void *priv, **/ /* + * si470x_i2c_interrupt_work - rds processing function + */ +static void si470x_i2c_interrupt_work(struct work_struct *work) +{ + struct si470x_device *radio = container_of(work, + struct si470x_device, radio_work); + unsigned char regnr; + unsigned char blocknum; + unsigned short bler; /* rds block errors */ + unsigned short rds; + unsigned char tmpbuf[3]; + int retval = 0; + + /* safety checks */ + if ((radio->registers[SYSCONFIG1] & SYSCONFIG1_RDS) == 0) + return; + + /* Update RDS registers */ + for (regnr = 0; regnr < RDS_REGISTER_NUM; regnr++) { + retval = si470x_get_register(radio, STATUSRSSI + regnr); + if (retval < 0) + return; + } + + /* get rds blocks */ + if ((radio->registers[STATUSRSSI] & STATUSRSSI_RDSR) == 0) + /* No RDS group ready, better luck next time */ + return; + + for (blocknum = 0; blocknum < 4; blocknum++) { + switch (blocknum) { + default: + bler = (radio->registers[STATUSRSSI] & + STATUSRSSI_BLERA) >> 9; + rds = radio->registers[RDSA]; + break; + case 1: + bler = (radio->registers[READCHAN] & + READCHAN_BLERB) >> 14; + rds = radio->registers[RDSB]; + break; + case 2: + bler = (radio->registers[READCHAN] & + READCHAN_BLERC) >> 12; + rds = radio->registers[RDSC]; + break; + case 3: + bler = (radio->registers[READCHAN] & + READCHAN_BLERD) >> 10; + rds = radio->registers[RDSD]; + break; + }; + + /* Fill the V4L2 RDS buffer */ + put_unaligned_le16(rds, &tmpbuf); + tmpbuf
[PATCH v2 1/3] radio-si470x: move some file operations to common file
The read and poll file operations of the si470x usb driver can be used also equally on the si470x i2c driver, so they go to the common file. Signed-off-by: Joonyoung Shim --- drivers/media/radio/si470x/radio-si470x-common.c | 98 ++ drivers/media/radio/si470x/radio-si470x-i2c.c| 15 +--- drivers/media/radio/si470x/radio-si470x-usb.c| 97 +- drivers/media/radio/si470x/radio-si470x.h|3 +- 4 files changed, 104 insertions(+), 109 deletions(-) diff --git a/drivers/media/radio/si470x/radio-si470x-common.c b/drivers/media/radio/si470x/radio-si470x-common.c index 7296cf4..f4645d4 100644 --- a/drivers/media/radio/si470x/radio-si470x-common.c +++ b/drivers/media/radio/si470x/radio-si470x-common.c @@ -426,6 +426,104 @@ int si470x_rds_on(struct si470x_device *radio) /** + * File Operations Interface + **/ + +/* + * si470x_fops_read - read RDS data + */ +static ssize_t si470x_fops_read(struct file *file, char __user *buf, + size_t count, loff_t *ppos) +{ + struct si470x_device *radio = video_drvdata(file); + int retval = 0; + unsigned int block_count = 0; + + /* switch on rds reception */ + if ((radio->registers[SYSCONFIG1] & SYSCONFIG1_RDS) == 0) + si470x_rds_on(radio); + + /* block if no new data available */ + while (radio->wr_index == radio->rd_index) { + if (file->f_flags & O_NONBLOCK) { + retval = -EWOULDBLOCK; + goto done; + } + if (wait_event_interruptible(radio->read_queue, + radio->wr_index != radio->rd_index) < 0) { + retval = -EINTR; + goto done; + } + } + + /* calculate block count from byte count */ + count /= 3; + + /* copy RDS block out of internal buffer and to user buffer */ + mutex_lock(&radio->lock); + while (block_count < count) { + if (radio->rd_index == radio->wr_index) + break; + + /* always transfer rds complete blocks */ + if (copy_to_user(buf, &radio->buffer[radio->rd_index], 3)) + /* retval = -EFAULT; */ + break; + + /* increment and wrap read pointer */ + radio->rd_index += 3; + if (radio->rd_index >= radio->buf_size) + radio->rd_index = 0; + + /* increment counters */ + block_count++; + buf += 3; + retval += 3; + } + mutex_unlock(&radio->lock); + +done: + return retval; +} + + +/* + * si470x_fops_poll - poll RDS data + */ +static unsigned int si470x_fops_poll(struct file *file, + struct poll_table_struct *pts) +{ + struct si470x_device *radio = video_drvdata(file); + int retval = 0; + + /* switch on rds reception */ + if ((radio->registers[SYSCONFIG1] & SYSCONFIG1_RDS) == 0) + si470x_rds_on(radio); + + poll_wait(file, &radio->read_queue, pts); + + if (radio->rd_index != radio->wr_index) + retval = POLLIN | POLLRDNORM; + + return retval; +} + + +/* + * si470x_fops - file operations interface + */ +static const struct v4l2_file_operations si470x_fops = { + .owner = THIS_MODULE, + .read = si470x_fops_read, + .poll = si470x_fops_poll, + .ioctl = video_ioctl2, + .open = si470x_fops_open, + .release= si470x_fops_release, +}; + + + +/** * Video4Linux Interface **/ diff --git a/drivers/media/radio/si470x/radio-si470x-i2c.c b/drivers/media/radio/si470x/radio-si470x-i2c.c index 2d53b6a..4816a6d 100644 --- a/drivers/media/radio/si470x/radio-si470x-i2c.c +++ b/drivers/media/radio/si470x/radio-si470x-i2c.c @@ -173,7 +173,7 @@ int si470x_disconnect_check(struct si470x_device *radio) /* * si470x_fops_open - file open */ -static int si470x_fops_open(struct file *file) +int si470x_fops_open(struct file *file) { struct si470x_device *radio = video_drvdata(file); int retval = 0; @@ -194,7 +194,7 @@ static int si470x_fops_open(struct file *file) /* * si470x_fops_release - file release */ -static int si470x_fops_release(struct file *file) +int si470x_fops_release(struct file *file) { struct si470x_device *radio = video_drvdata(file); int retval = 0; @@ -215,17 +215,6 @@ static int si470x_fops_release(struct file *file) } -/* - * si470x_fops - file operations interface -
[PATCH v2 0/3] patches for radio-si470x-i2c driver
Hi, I post patches v2 for radio-si470x-i2c driver. [PATCH v2 1/3] radio-si470x: move some file operations to common file [PATCH v2 2/3] radio-si470x: support RDS on si470x i2c driver [PATCH v2 3/3] radio-si470x: support PM functions 1/3 patch is same with v1. 2/3 patch is updated the RDS interrupt enable code by review of Tobias. 3/3 patch is to support PM. And first patch of v1 is unnecessary by 2/3 patch of v2. Thanks. -- 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: /dev/dvb/adapter0/net0 <-- what is this for and how to use it?
Leszek Koltunski wrote, On 12/03/2009 09:21 AM: > Hello DVB gurus, > > I've got a TwinHan DVB-S2 card. I compiled the 'liplianin' drivers and > it's working nicely; thanks for all your work! > > One question: in /dev/dvb/adapter0 I can see > > les...@satellite:~$ ls -l /dev/dvb/adapter0/ > total 0 > crw-rw+ 1 root video 212, 4 2009-12-02 18:22 ca0 > crw-rw+ 1 root video 212, 0 2009-12-02 18:22 demux0 > crw-rw+ 1 root video 212, 1 2009-12-02 18:22 dvr0 > crw-rw+ 1 root video 212, 3 2009-12-02 18:22 frontend0 > crw-rw+ 1 root video 212, 2 2009-12-02 18:22 net0 > > What is this 'net0' device and how do I use it? Can I use it to > directly multicast my (FTA) satellite stream to my lan by any chance? You can use MuMuDVB for this: http://mumudvb.braice.net/ And net0 is related to network over dvb. look at the dvbnet tool (in dvb-apps package) Pierre > > I have found no documentation about this... -- 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] What are the goals for the architecture of an in-kernel IR system?
On 12/03/09 05:29, Jarod Wilson wrote: On Dec 1, 2009, at 10:28 AM, Gerd Hoffmann wrote: Anyway, we shouldn't postpone lirc drivers addition due to that. There are still lots of work to do before we'll be able to split the tables from the kernel drivers. Indeed. The sysfs bits are future work for both lirc and evdev drivers. There is no reason to make the lirc merge wait for it. At this point, my plan is to try to finish cleaning up lirc_dev and lirc_mceusb at least over the weekend while at FUDCon up in Toronto, and resubmit them next week. Good plan IMHO. Having lirc_dev merged quickly allows in-kernel drivers start supporting lirc. One final pass over the lirc interface would be good, taking the chance to fixup anything before the ABI is set in stone with the mainline merge. Things to look at: (1) Make sure ioctl structs are 32/64 bit invariant. (2) Maybe add some reserved fields to allow extending later without breaking the ABI. (3) Someone suggested a 'commit' ioctl which would activate the parameters set in (multiple) previous ioctls. Makes sense? (4) Add a ioctl to enable/disable evdev event submission for evdev/lirc hybrid drivers. I'm still on the fence over what to do about lirc_imon. The driver supports essentially 3 generations of devices. First-gen is very old imon parts that don't do onboard decoding. Second-gen is the devices that all got (insanely stupidly) tagged with the exact same usb device ID (0x15c2:0xffdc), some of which have an attached VFD, some with an attached LCD, some with neither, some that are actually RF parts, but all (I think) of which do onboard decoding. Third-gen is the latest stuff, which is all pretty sane, unique device IDs for unique devices, onboard decoding, etc. Do have second-gen and third-gen devices have a 'raw mode'? If so, then there should be a lirc interface for raw data access. So the lirc_imon I submitted supports all device types, with the onboard decode devices defaulting to operating as pure input devices, but an option to pass hex values out via the lirc interface (which is how they've historically been used -- the pure input stuff I hacked together just a few weeks ago), to prevent functional setups from being broken for those who prefer the lirc way. Hmm. I'd tend to limit the lirc interface to the 'raw samples' case. Historically it has also been used to pass decoded data (i.e. rc5) from devices with onboard decoding, but for that in-kernel mapping + input layer really fits better. What I'm debating is whether this should be split into two drivers, one for the older devices that don't do onboard decoding (which would use the lirc_dev interface) called 'lirc_imon' or 'lirc_imon_legacy', and one that is a pure input driver, not unlike the ati_remote{,2} drivers, with no lirc_dev dependency at all, probably called simply 'imon'. i.e. lirc_imon would support first+second gen, and imon third-gen devices, without overlap? > But if I split it out, there may end up being a fair amount of code duplication, You could try to split common code into a third module used by the other two. Or have one module for all devices which is a evdev/lirc hybrid. cheers, Gerd -- 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 v2] Another approach to IR
On Thu, 2009-12-03 at 08:00 -0200, Mauro Carvalho Chehab wrote: > Andy Walls wrote: > > On Wed, 2009-12-02 at 14:55 -0500, Jarod Wilson wrote: > >> On Dec 2, 2009, at 2:33 PM, Mauro Carvalho Chehab wrote: > > Both of those IR devices are/will be encapsulated in a v4l2_subdevice > > object internally. I was going to write lirc_v4l glue between the > > v4l2_device/v4l2_subdev_ir_ops and lirc_dev. > > > > As for the the I2C chips, I was going to go back and encapsulate those > > in the v4l2_subdevice object as well, so then my notional lirc_v4l could > > pick those up too. The I2C subsystem only allows one binding to an I2C > > client address/name on a bus. So without some new glue like a notional > > lirc_v4l, it *may* be hard to share between ir-kbd-i2c and lirc_i2c and > > lirc_zilog. > > Maybe you're having a bad time because you may be trying to integrate lirc > at the wrong place. These were just ideas. I haven't done *anything* yet. ;) > All devices at V4L tree including ir-kbd-i2c use ir-common.ko > (at /drivers/media/common tree) module to communicate to IR's. > I'm preparing some patches to extend this also to dvb-usb devices > (that uses a close enough infrastructure). > > Also, most of the decoding code are there, in a form of helper routines. > > As the idea is to provide lirc interface to all devices that can work with > raw pulse/space, the proper place is to write a subroutine there that, once > called, will make those pulse/space raw codes available to lirc and will > call the needed decoders to export them also to evdev. > > The code at ir-common module was originally built to be used by V4L, but I'm > porting the code there to be generic enough to be a library that can be used > by other drivers. So, lirc_zilog and other lirc devices that will need to open > evdev interfaces after running a decoder can use them. I think I see what you are saying (I wish could see look at a whiteboard somewhere...). Wherever we come through internally to split to 2 different userspace interfaces is fine, if you've got a big picture plan you think is feasible. That seems like a bit of perturbation to lirc_zilog and lirc_i2c. My thought was that lirc_v4l using the standardized v4l2_subdev_ir_ops interface, and maybe some new calls associted with v4l2_device, could subsume/unify all the functionality of lirc_i2c, lirc_zilog, ... lirc_whatever. Maybe that's just a poorly thought out dream though... > Due to that, we shouldn't add v4l2_subdevice there. Nothing prevents to create > a v4l2-ir-subdev glue if you want to see the IR's as subdevices, but this > should > be implemented as a separate module. The v4l_subdevice just abstracted the IR hardware into a nice (mental) box for me -- easier to keep hardware separate from software decoders and userspace interface logic. Also, since v4l2_subdevices may have per subdevice /dev nodes and the /dev/../mcN nodes providing a discovery mechanism due to the Meda Controller framework, wrapping things in v4l2_subdevice may be handy for development and debug. Or ... as an additional operational interface to userspace. :D *ducks and runs for cover* Regards, Andy > 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: Replace Mercurial with GIT as SCM
On Thursday 03 December 2009 09:04:48 Hans de Goede wrote: > +1 for git, I really really really miss being able to do > a simple "git rebase", and no rebase is not evil not as long > as you don't use it for anything but local patches. For what it's worth, I second that. "git rebase -i" is one of git's killer features (I personally learned about it during Linus' talk at the LPC 2009, so if you haven't heard about "git rebase -i" before, take a look at it). -- 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: [RFC v2] Another approach to IR
Jon Smirl wrote: > On Wed, Dec 2, 2009 at 11:13 PM, Jarod Wilson wrote: >> On Dec 2, 2009, at 9:48 PM, Trent Piepho wrote: >> ... >> Now I understand that if 2 remotes send completely identical signals we >> won't be able to separate them, but in cases when we can I think we >> should. > I don't have a problem with that, if its a truly desired feature. But > for the most part, I don't see the point. Generally, you go from > having multiple remotes, one per device (where "device" is your TV, > amplifier, set top box, htpc, etc), to having a single universal remote > that controls all of those devices. But for each device (IR receiver), > *one* IR command set. The desire to use multiple distinct remotes with > a single IR receiver doesn't make sense to me. Perhaps I'm just not > creative enough in my use of IR. :) >>> Most universal remotes I'm familiar with emulate multiple remotes. I.e. >>> my tv remote generates one set of scancodes for the numeric keys. The DVD >>> remote generates a different set. The amplifier remote in "tv mode" >>> generates the same codes as the tv remote, and in "dvd mode" the same codes >>> as the dvd remote. From the perspective of the IR receiver there is no >>> difference between having both the DVD and TV remotes, or using the >>> aplifier remote to control both devices. >> Okay, in the above scenario, you've still got a single input device... >> >>> Now, my aplifier remote has a number of modes. Some control devices I >>> have, like "vcr mode", and there is nothing I can do about that. Some, >>> like "md mode" don't control devices I have. That means they are free to >>> do things on the computer. Someone else with the same remote (or any >>> number of remotes that use the same protocol and scancodes) might have >>> different devices. >>> >>> So I want my computer to do stuff when I push "JVC MD #xx" keys, but ignore >>> "JVC VCR #yyy" yets. Someone with an MD player and not a VCR would want to >>> opposite. Rather than force everyone to create custom keymaps, it's much >>> easier if we can use the standard keymaps from a database of common remotes >>> and simply tell mythtv to only use remote #xxx or not to use remote #yyy. >> Sure, but the key is that this can't be done automagically. The IR driver >> has no way of knowing that user A wants JVC MD keys handled and JVC VCR keys >> ignored, and user B wants vice versa, while user C wants both ignored, etc. >> This is somewhat tangential to whether or not there's a separate input >> device per "remote" though. You can use multiple remotes/protocols with a >> single input device or lirc device already (if the hardware doesn't have to >> be put explicitly into a mode to listen for that proto, of course, but then >> its a hardware decoding device feeding a single input device anyway, so...). >> >>> It sounds like you're thinking of a receiver that came bundled with a >>> remote and that's it. Not someone with a number of remotes that came with >>> different pieces of AV gear that they want to use with their computer. >> No, I just pick *one* remote and use it for everything, not >> schizophrenically hopping from one remote to another, expecting them all the >> be able to control everything. :) Its a hell of a lot easier to find buttons >> w/o looking at the remote if you always use the same one for everything, for >> one. >> >> Anyway, I think I'm talking myself in circles. Supporting multiple remotes >> via multiple input devices (or even via a single input device) isn't at all >> interesting to me for my own use, but if there really is demand for such >> support (and it appears there is), then fine, lets do it. > > Simple use case: > > You have a multifunction remote. Press the CABLE key - it sends out > commands that control the cable box, press the TV key - now the > commands control the TV, press CD - now the CD player, etc. > > Now imagine a headless Linux box running a music server and a home > automation app. Press the CD key - commands get routed to the music > server, press the AUX key - commands get routed to the home automation > app. > > This is accomplished by recognizing the device code part of the IR > signal and figuring out that there are two different device codes in > use. The commands of then routed to two evdev devices corresponding to > the two different device codes. > > Using things like Alt-Tab to switch apps is impossible. There's no > screen to look at. This usecase makes sense to me. With the risk of repeating myself, you don't have two physical remotes. The needed feature is a way to split one source of input events (that happens to be an infrared remote, but it could also be any other type of input device, like a bluetooth remote) into several different evdev interfaces, based on scancode groups. Also, as you're thinking on 64 bits scancodes, this also means that the current evdev KABI and API will require changes t
Re: [RFC v2] Another approach to IR
Jon Smirl wrote: > On Wed, Dec 2, 2009 at 9:22 PM, Mauro Carvalho Chehab > wrote: >> Jon Smirl wrote: >>> On Wed, Dec 2, 2009 at 3:04 PM, Jarod Wilson wrote: On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote: > On Wed, Dec 02, 2009 at 02:22:18PM -0500, Jarod Wilson wrote: >> On 12/2/09 12:30 PM, Jon Smirl wrote: >> (for each remote/substream that they can recognize). >>> I'm assuming that, by remote, you're referring to a remote receiver >>> (and not to >>> the remote itself), right? > If we could separate by remote transmitter that would be the best I > think, but I understand that it is rarely possible? >>> The code I posted using configfs did that. Instead of making apps IR >>> aware it mapped the vendor/device/command triplets into standard Linux >>> keycodes. Each remote was its own evdev device. >> Note, of course, that you can only do that iff each remote uses distinct >> triplets. A good portion of mythtv users use a universal of some sort, >> programmed to emulate another remote, such as the mce remote bundled >> with mceusb transceivers, or the imon remote bundled with most imon >> receivers. I do just that myself. >> >> Personally, I've always considered the driver/interface to be the >> receiver, not the remote. The lirc drivers operate at the receiver >> level, anyway, and the distinction between different remotes is made by >> the lirc daemon. > The fact that lirc does it this way does not necessarily mean it is the > most corerct way. No, I know that, I'm just saying that's how I've always looked at it, and that's how lirc does it right now, not that it must be that way. > Do you expect all bluetooth input devices be presented > as a single blob just because they happen to talk to the sane receiver > in yoru laptop? Do you expect your USB mouse and keyboard be merged > together just because they end up being serviced by the same host > controller? If not why remotes should be any different? A bluetooth remote has a specific device ID that the receiver has to pair with. Your usb mouse and keyboard each have specific device IDs. A usb IR *receiver* has a specific device ID, the remotes do not. So there's the major difference from your examples. >>> Actually remotes do have an ID. They all transmit vendor/device pairs >>> which is exactly how USB works. >>> >> Well, the description of NEC and RC5 protocol at >> http://www.sbprojects.com/knowledge/ir/rc5.htm >> doesn't mention any vendor/device pair, nor I'm able to get them with the IR >> hardware decoders >> I have. > > Some of the protocols were not intended to be multi-vendor - the > vendor is implicit in the protocol encoding. You don't have to split > the IR codes into vendor/device/command triplets. I just do that > because it is convenient to think of them that way. It is equally > valid to treat them as a 64b integers and use four bits of the int to > encode the protocol. It should really be a quad > protocol/vendor/device/command and some of the fields may be missing. > Bottom line, you are looking for unique codes how the fields are split > up doesn't really matter. Currently, there aren't any in-kernel driver that support 64 bit IR's. They support only up to 16 bits. So, we have only address (device)/command. As I said before, AFAIK, only RC6 mode 6 remotes support 64 bits. As pointed by Andy, it is risky to support such protocol in kernel, since you won't be able to ship the kernel to countries where RC6 patents got accepted, or you would need. > A fixed protocol receiver is more of a challenge. You have to figure > out how to make a universal remote transmit device codes for a device > you don't already own that is also encoded in the protocol your > hardware supports. > There's nothing we can do about that problem in > Linux, its a side effect of fixed protocol decode hardware. With hardware decoders, you're limited to the supported protocols, but yet, you can use a different scancode than the one that comes with the shipped device. If you take a look, for example, at the NEC protocol decoder we have on drivers/media/video/saa7134/saa7134-input.c [1], you'll see that the tasklet (nec_task) holds CPU control up to 76.5 ms, in order to be able to receive the entire sequence at the GPIO port. Fortunately, on the device where this decoder is called (Avermedia M135A), we can trigger the start of the IR code via IRQ. [1]http://git.kernel.org/?p=linux/kernel/git/mchehab/linux-2.6.git;a=blob;f=drivers/media/video/saa7134/saa7134-input.c;h=6e219c2db8419013ab3ced30470ad1c19431974a;hb=HEAD In this specific decoder I've implemented it some time ago. I think I tried first to get the pulse/space width using just IRQ without the tasklet, but the lengths weren't precise enough for decoding. Also, if you have a bad contact at the IR sensor conn
Re: [RFC v2] Another approach to IR
Andy Walls wrote: > On Wed, 2009-12-02 at 14:55 -0500, Jarod Wilson wrote: >> On Dec 2, 2009, at 2:33 PM, Mauro Carvalho Chehab wrote: >> >>> Dmitry Torokhov wrote: >> ... >> (for each remote/substream that they can recognize). > I'm assuming that, by remote, you're referring to a remote receiver (and > not to > the remote itself), right? If we could separate by remote transmitter that would be the best I think, but I understand that it is rarely possible? >>> IMHO, the better is to use a separate interface for the IR transmitters, >>> on the devices that support this feature. There are only a few devices >>> I'm aware of that are able to transmit IR codes. >> If I'm thinking clearly, there are only three lirc kernel drivers that >> support transmit, lirc_mceusb, lirc_zilog and lirc_serial. The mceusb >> driver was posted, so I won't rehash what it is here. The zilog driver >> binds to a Zilog z80 microprocessor thingy (iirc) exposed via i2c, >> found on many Hauppauge v4l/dvb devices (PVR-150, HVR-1600, HD-PVR, >> etc). The serial driver is fairly self-explanatory as well. >> >> There are also a few userspace-driven devices that do transmit, but >> I'm assuming they're (currently) irrelevant to this discussion. > > > I've got the CX23888 integrated IR Rx done and Tx nearly done. I was > waiting to see how kfifo and lirc_dev panned out before making the > interface to userspace. > > The CX23885, CX23418, and CX2584x integrated IR is essentially the same. > I hope to have CX23885 IR done by Christmas. > > Both of those IR devices are/will be encapsulated in a v4l2_subdevice > object internally. I was going to write lirc_v4l glue between the > v4l2_device/v4l2_subdev_ir_ops and lirc_dev. > > As for the the I2C chips, I was going to go back and encapsulate those > in the v4l2_subdevice object as well, so then my notional lirc_v4l could > pick those up too. The I2C subsystem only allows one binding to an I2C > client address/name on a bus. So without some new glue like a notional > lirc_v4l, it *may* be hard to share between ir-kbd-i2c and lirc_i2c and > lirc_zilog. The better is to add the lirc glue at ir-common module. There, we have the support functions used by all V4L devices, and they'll be expanded to cover also dvb-usb, as soon as I can find some time to do a patch for it. 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
cx2388x driver appears broken
Hi, I have successfully been running Ubuntu 9.10 on an old Pentium4 test-box. The machine has two PCI cards, both of which worked with stock 9.10 and with a slightly upgraded kernel (2.6.31-14-generic-pae and 2.6.31-15-generic-pae). These cards, have, in the past also worked on Ubuntu 6.10 so have been supported for a long time. The output on the 2.6.31-15-generic-pae gives: [6.173285] cx88/0: cx2388x v4l2 driver version 0.0.7 loaded [6.173349] cx8800 :02:0b.0: PCI INT A -> GSI 23 (level, low) -> IRQ 23 [6.174531] cx88[0]: subsystem: 18ac:db10, board: DViCO FusionHDTV DVB-T Plus [card=21,insmod option], frontend(s): 1 [6.174537] cx88[0]: TV tuner type 4, Radio tuner type -1 [6.183548] cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.7 loaded [6.340041] cx88[0]/0: found at :02:0b.0, rev: 5, irq: 23, latency: 32, mmio: 0xef00 [6.340065] IRQ 23/cx88[0]: IRQF_DISABLED is not guaranteed on shared IRQs [6.340191] cx88[0]/0: registered device video0 [v4l2] [6.340237] cx88[0]/0: registered device vbi0 [6.340313] cx88[0]/2: cx2388x 8802 Driver Manager [6.340335] cx88-mpeg driver manager :02:0b.2: PCI INT A -> GSI 23 (level, low) -> IRQ 23 [6.340349] cx88[0]/2: found at :02:0b.2, rev: 5, irq: 23, latency: 32, mmio: 0xee00 [6.340358] IRQ 23/cx88[0]: IRQF_DISABLED is not guaranteed on shared IRQs [6.340395] cx8800 :02:0c.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20 [6.341628] cx88[1]: subsystem: 17de:a8a6, board: Conexant DVB-T reference design [card=19,insmod option], frontend(s): 1 [6.341635] cx88[1]: TV tuner type 4, Radio tuner type -1 [6.504094] cx88[1]/0: found at :02:0c.0, rev: 5, irq: 20, latency: 32, mmio: 0xed00 [6.504166] IRQ 20/cx88[1]: IRQF_DISABLED is not guaranteed on shared IRQs [6.504294] cx88[1]/0: registered device video1 [v4l2] [6.504342] cx88[1]/0: registered device vbi1 [6.506583] cx88[1]/2: cx2388x 8802 Driver Manager [6.506609] cx88-mpeg driver manager :02:0c.2: PCI INT A -> GSI 20 (level, low) -> IRQ 20 [6.506625] cx88[1]/2: found at :02:0c.2, rev: 5, irq: 20, latency: 32, mmio: 0xec00 [6.506638] IRQ 20/cx88[1]: IRQF_DISABLED is not guaranteed on shared IRQs [6.609088] alloc irq_desc for 18 on node -1 [6.609095] alloc kstat_irqs on node -1 [6.609108] C-Media PCI :02:0d.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 [6.873923] EXT4-fs (sda11): internal journal on sda11:8 [7.011870] cx88/2: cx2388x dvb driver version 0.0.7 loaded [7.011877] cx88/2: registering cx8802 driver, type: dvb access: shared [7.011884] cx88[0]/2: subsystem: 18ac:db10, board: DViCO FusionHDTV DVB-T Plus [card=21] [7.011889] cx88[0]/2: cx2388x based DVB/ATSC card [7.011893] cx8802_alloc_frontends() allocating 1 frontend(s) [7.092877] ip_tables: (C) 2000-2006 Netfilter Core Team [7.397447] DVB: registering new adapter (cx88[0]) [7.397457] DVB: registering adapter 0 frontend 0 (Zarlink ZL10353 DVB-T)... [7.398038] cx88[1]/2: subsystem: 17de:a8a6, board: Conexant DVB-T reference design [card=19] [7.398046] cx88[1]/2: cx2388x based DVB/ATSC card [7.398050] cx8802_alloc_frontends() allocating 1 frontend(s) [7.434445] DVB: registering new adapter (cx88[1]) [7.434456] DVB: registering adapter 1 frontend 0 (Conexant CX22702 DVB-T)... In order to debug a problem with a new dual tuner USB module, I grabbed the latest v4l-dvb and built all the modules from source (sans FireTV) and installed them using the provided makefile targets. This results in the following: [5.831860] cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.7 loaded [5.833100] cx88[0]: subsystem: 18ac:db10, board: DViCO FusionHDTV DVB-T Plus [card=21,insmod option], frontend(s): 1 [5.833107] cx88[0]: TV tuner type 4, Radio tuner type -1 [5.846548] cx88/0: cx2388x v4l2 driver version 0.0.7 loaded [5.884782] EXT4-fs (sda11): internal journal on sda11:8 [6.012069] BUG: unable to handle kernel NULL pointer dereference at (null) [6.012313] IP: [] ir_input_free+0x16/0x40 [ir_common] [6.012490] *pdpt = 1e550001 *pde = [6.012725] Oops: [#1] SMP [6.012957] last sysfs file: /sys/devices/virtual/dmi/id/sys_vendor [6.013048] Modules linked in: snd_opl3_lib snd_timer x_tables snd_hwdep cx8800(+) cx8802(+) snd_mpu401_uart cx88xx ir_common i2c_algo_bit snd_rawmidi v4l2_common snd_seq_device tveeprom videodev v4l1_compat videobuf_dma_sg btcx_risc snd videobuf_core soundcore ppdev parport_pc shpchp lp intel_agp parport agpgart psmouse serio_raw e100 mii natsemi floppy [6.015697] [6.015784] Pid: 534, comm: modprobe Not tainted (2.6.31-15-generic-pae #50-Ubuntu) System Name [6.015886] EIP: 0060:[] EFLAGS: 00010246 CPU: 0 [6.015983] EIP is at ir_input_free+0x16/0x40 [ir_common] [6.016013] EAX: EBX: ECX: ffed EDX: de08778c [6.016013] ESI: de0870
Re: [RFC v2] Another approach to IR
Andy Walls wrote: > On Wed, 2009-12-02 at 14:55 -0500, Jarod Wilson wrote: >> On Dec 2, 2009, at 2:33 PM, Mauro Carvalho Chehab wrote: >> >>> Dmitry Torokhov wrote: >> ... >> (for each remote/substream that they can recognize). > I'm assuming that, by remote, you're referring to a remote receiver (and > not to > the remote itself), right? If we could separate by remote transmitter that would be the best I think, but I understand that it is rarely possible? >>> IMHO, the better is to use a separate interface for the IR transmitters, >>> on the devices that support this feature. There are only a few devices >>> I'm aware of that are able to transmit IR codes. >> If I'm thinking clearly, there are only three lirc kernel drivers that >> support transmit, lirc_mceusb, lirc_zilog and lirc_serial. The mceusb >> driver was posted, so I won't rehash what it is here. The zilog driver >> binds to a Zilog z80 microprocessor thingy (iirc) exposed via i2c, >> found on many Hauppauge v4l/dvb devices (PVR-150, HVR-1600, HD-PVR, >> etc). The serial driver is fairly self-explanatory as well. >> >> There are also a few userspace-driven devices that do transmit, but >> I'm assuming they're (currently) irrelevant to this discussion. > > > I've got the CX23888 integrated IR Rx done and Tx nearly done. I was > waiting to see how kfifo and lirc_dev panned out before making the > interface to userspace. > > The CX23885, CX23418, and CX2584x integrated IR is essentially the same. > I hope to have CX23885 IR done by Christmas. > > Both of those IR devices are/will be encapsulated in a v4l2_subdevice > object internally. I was going to write lirc_v4l glue between the > v4l2_device/v4l2_subdev_ir_ops and lirc_dev. > > As for the the I2C chips, I was going to go back and encapsulate those > in the v4l2_subdevice object as well, so then my notional lirc_v4l could > pick those up too. The I2C subsystem only allows one binding to an I2C > client address/name on a bus. So without some new glue like a notional > lirc_v4l, it *may* be hard to share between ir-kbd-i2c and lirc_i2c and > lirc_zilog. Maybe you're having a bad time because you may be trying to integrate lirc at the wrong place. All devices at V4L tree including ir-kbd-i2c use ir-common.ko (at /drivers/media/common tree) module to communicate to IR's. I'm preparing some patches to extend this also to dvb-usb devices (that uses a close enough infrastructure). Also, most of the decoding code are there, in a form of helper routines. As the idea is to provide lirc interface to all devices that can work with raw pulse/space, the proper place is to write a subroutine there that, once called, will make those pulse/space raw codes available to lirc and will call the needed decoders to export them also to evdev. The code at ir-common module was originally built to be used by V4L, but I'm porting the code there to be generic enough to be a library that can be used by other drivers. So, lirc_zilog and other lirc devices that will need to open evdev interfaces after running a decoder can use them. Due to that, we shouldn't add v4l2_subdevice there. Nothing prevents to create a v4l2-ir-subdev glue if you want to see the IR's as subdevices, but this should be implemented as a separate module. 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
[PATCH] V4L/DVB: pms: KERNEL_VERSION requires version.h
Fix this build error: drivers/media/video/pms.c:682: error: implicit declaration of function 'KERNEL_VERSION' Signed-off-by: Alexander Beregalov --- drivers/media/video/pms.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/pms.c b/drivers/media/video/pms.c index 00228d5..a118bb1 100644 --- a/drivers/media/video/pms.c +++ b/drivers/media/video/pms.c @@ -35,6 +35,7 @@ #include #include #include +#include #include -- 1.6.5.3 -- 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/2 v4] v4l: add a media-bus API for configuring v4l2 subdev pixel and frame formats
Video subdevices, like cameras, decoders, connect to video bridges over specialised busses. Data is being transferred over these busses in various formats, which only loosely correspond to fourcc codes, describing how video data is stored in RAM. This is not a one-to-one correspondence, therefore we cannot use fourcc codes to configure subdevice output data formats. This patch adds codes for several such on-the-bus formats and an API, similar to the familiar .s_fmt(), .g_fmt(), .try_fmt(), .enum_fmt() API for configuring those codes. After all users of the old API in struct v4l2_subdev_video_ops are converted, it will be removed. Also add helper routines to support generic pass-through mode for the soc-camera framework. Signed-off-by: Guennadi Liakhovetski --- v3 -> v4: more comments addressed - thanks! Now based on the current linux-next. Hans, as for _nXk suffixes, I preferred to preserve them to keep all notation explicit. Without them a format like V4L2_MBUS_FMT_SBGGR10 would be ambiguous, whether one of V4L2_MBUS_FMT_SBGGR10_2X8_PAD*_?E or the V4L2_MBUS_FMT_SBGGR10_1X10 is meant. I also removed struct soc_mbus_datafmt and soc_mbus_find_datafmt() upon your request, although I'm not happy having to open-code it in about 4 drivers. But we can extract that code in a generic routine later. One of the important advantages of that struct and function was, that they allowed to keep supported formats in drivers centrally at just one location, thus being able to add new or remove deprecated formats easily, and to avoid long switch-case blocks by just calling one function to search in the array. Thanks Guennadi drivers/media/video/Makefile |2 +- drivers/media/video/soc_mediabus.c | 157 include/media/soc_mediabus.h | 65 +++ include/media/v4l2-mediabus.h | 61 ++ include/media/v4l2-subdev.h| 19 - 5 files changed, 302 insertions(+), 2 deletions(-) create mode 100644 drivers/media/video/soc_mediabus.c create mode 100644 include/media/soc_mediabus.h create mode 100644 include/media/v4l2-mediabus.h diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index 7a2dcc3..e7bc8da 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -149,7 +149,7 @@ obj-$(CONFIG_VIDEO_VIVI) += vivi.o obj-$(CONFIG_VIDEO_CX23885) += cx23885/ obj-$(CONFIG_VIDEO_OMAP2) += omap2cam.o -obj-$(CONFIG_SOC_CAMERA) += soc_camera.o +obj-$(CONFIG_SOC_CAMERA) += soc_camera.o soc_mediabus.o obj-$(CONFIG_SOC_CAMERA_PLATFORM) += soc_camera_platform.o # soc-camera host drivers have to be linked after camera drivers obj-$(CONFIG_VIDEO_MX1)+= mx1_camera.o diff --git a/drivers/media/video/soc_mediabus.c b/drivers/media/video/soc_mediabus.c new file mode 100644 index 000..c54cae7 --- /dev/null +++ b/drivers/media/video/soc_mediabus.c @@ -0,0 +1,157 @@ +/* + * soc-camera media bus helper routines + * + * Copyright (C) 2009, Guennadi Liakhovetski + * + * This program 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. + */ + +#include +#include + +#include +#include +#include + +#define MBUS_IDX(f) (V4L2_MBUS_FMT_ ## f - V4L2_MBUS_FMT_FIXED - 1) + +static const struct soc_mbus_pixelfmt mbus_fmt[] = { + [MBUS_IDX(YUYV8_2X8)] = { + .fourcc = V4L2_PIX_FMT_YUYV, + .name = "YUYV", + .bits_per_sample= 8, + .packing= SOC_MBUS_PACKING_2X8_PADHI, + .order = SOC_MBUS_ORDER_LE, + }, [MBUS_IDX(YVYU8_2X8)] = { + .fourcc = V4L2_PIX_FMT_YVYU, + .name = "YVYU", + .bits_per_sample= 8, + .packing= SOC_MBUS_PACKING_2X8_PADHI, + .order = SOC_MBUS_ORDER_LE, + }, [MBUS_IDX(UYVY8_2X8)] = { + .fourcc = V4L2_PIX_FMT_UYVY, + .name = "UYVY", + .bits_per_sample= 8, + .packing= SOC_MBUS_PACKING_2X8_PADHI, + .order = SOC_MBUS_ORDER_LE, + }, [MBUS_IDX(VYUY8_2X8)] = { + .fourcc = V4L2_PIX_FMT_VYUY, + .name = "VYUY", + .bits_per_sample= 8, + .packing= SOC_MBUS_PACKING_2X8_PADHI, + .order = SOC_MBUS_ORDER_LE, + }, [MBUS_IDX(RGB555_2X8_PADHI_LE)] = { + .fourcc = V4L2_PIX_FMT_RGB555, + .name = "RGB555", + .bits_per_sample= 8, + .pa
Re: Problem on RJ54N1CB0C
Hi Uwe On Thu, 3 Dec 2009, Uwe Taeubert wrote: > Hello Guennadi, > now our driver is working. I found the registers to fix and manipulate the > exposure values. So, now, if I switch from preview to heigher resolution > pictures, the taken photo is as bright as the preview. I read out the preview > exposure data, modify it according to the desired divider settings and then I > switch to the new mode. > Now it is also possible to change exposure values in case of flashlight use > depending on AF values to prevent over exposure of near objects. But, it is > not done, yet. > The resolution depending divider switching is not tested in all details, yet. > It is done for our preferred resolutions. cool! Thanks for sharing your success! I'm currently busy with getting ready for the approaching merge window, but it would be good to get your functionality integrated in the mainline driver. I think, it would also be good for you to migrate to the in-tree version, so, would be cool, if you could try the mainstream version and send us patches against it. > I'm using the English version. Hm, good to know... Thanks Guennadi > > Regard > Uwe > > Am Tuesday 17 November 2009 09:28:18 schrieben Sie: > > Hi Uwe > > > > On Mon, 16 Nov 2009, Uwe Taeubert wrote: > > > Hi Guennadi > > > You will find the driver sources for our Sharp module in lz0p39ha.c and > > > the initialization data in lz0p39ha_init.c. In lz0p35du_set_fmt_cap() you > > > can see the resolution depending change of the divider. In our system we > > > get correct pictures in all resolution mensioned there. But FYI, if no > > > flashlight is desired, we do not switch to still mode - only still mode > > > generates flash controll signals. > > > We are working with the Technical Manual Ver. 2.2C, also under NDA. > > > > May I ask you if you have an English or a Japanese version?:-) I've got a > > 2.3C Japanese... > > > > > Concerning the exposure control, I know the use of the registers 0x04d8 > > > and 0x04d9 is more a hack but a solution. And the result is unsatisfying > > > - it was a try.divide > > > > > > At the moment I'm checking the influence of RAMPCLK- TGCLK-ratio. I was > > > able to get higher exposer by changing RAMPCLK but I wasn't able to > > > calculate a well doing relation between all clocks and to have a fast > > > frame rate. > > > > > > The driver content is in a preliminary state. I'm working on > > > lz0p35du_set_fmt_cap function. We do not diffenrentialte between preview > > > and still mode. It makes it easier to handle buffers in VFL at the > > > moment. > > > > Thanks for the code. I looked briefly at it and one essential difference > > that occurred to me is, that you're setting the RESIZE registers at the > > beginning of the format-change function (lz0p35du_set_fmt_cap()), and I am > > doing this following code examples, that I had in the end, followed by a > > killer delay of 230ms... You might try to do that in the end, but it might > > only become worse, because, as I said, my version of the driver has > > problems with bigger images. > > > > My driver also doesn't set autofocus ATM, as there had been errors in > > examples that I had and I didn't have time to experiment with those > > values. I'm also relying on the automatic exposure area selection (0x58c > > bit 7) instead of setting it automatically. You also don't seem to > > dynamically adjust INC_USE_SEL registers, instead you just initialise them > > to 0xff. And in my experience that register does make a difference, so, > > you might try to play with it a bit. Have a look at my driver, although, I > > don't think values I configure there are perfect either. > > > > In fact, it might indeed become a problem for you, that you're updating > > the RESIZE registers too early and not pausing after that. > > > > Unfortunately, I do not have time now to look at the driver in detail ATM, > > let me know your results when you fix your problem. > > > > Thanks > > Guennadi > > --- > > Guennadi Liakhovetski, Ph.D. > > Freelance Open-Source Software Developer > > http://www.open-technology.de/ > > > --- 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
/dev/dvb/adapter0/net0 <-- what is this for and how to use it?
Hello DVB gurus, I've got a TwinHan DVB-S2 card. I compiled the 'liplianin' drivers and it's working nicely; thanks for all your work! One question: in /dev/dvb/adapter0 I can see les...@satellite:~$ ls -l /dev/dvb/adapter0/ total 0 crw-rw+ 1 root video 212, 4 2009-12-02 18:22 ca0 crw-rw+ 1 root video 212, 0 2009-12-02 18:22 demux0 crw-rw+ 1 root video 212, 1 2009-12-02 18:22 dvr0 crw-rw+ 1 root video 212, 3 2009-12-02 18:22 frontend0 crw-rw+ 1 root video 212, 2 2009-12-02 18:22 net0 What is this 'net0' device and how do I use it? Can I use it to directly multicast my (FTA) satellite stream to my lan by any chance? I have found no documentation about this... -- 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
saa7134 and µPD61151 MPEG2 encoder
Hi All Our new TV card has MPEG-2 encoder NEC µPD61151. This encoder hasn't I2C bus, only SPI. I wrote SPI bitbang master for saa7134. [ 74.482290] Linux video capture interface: v2.00 [ 74.534047] saa7130/34: v4l2 driver version 0.2.15 loaded [ 74.534081] saa7134 :04:01.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19 [ 74.534086] saa7133[0]: found at :04:01.0, rev: 209, irq: 19, latency: 32, mmio: 0xe510 [ 74.534092] saa7133[0]: subsystem: 5ace:7595, board: Beholder BeholdTV X7 [card=171,autodetected] [ 74.534101] saa7133[0]: board init: gpio is 20 [ 74.534108] IRQ 19/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs [ 74.684510] saa7133[0]: i2c eeprom 00: ce 5a 95 75 54 20 00 00 00 00 00 00 00 00 00 01 [ 74.684531] saa7133[0]: i2c eeprom 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 74.684548] saa7133[0]: i2c eeprom 20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 74.684565] saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 74.684582] saa7133[0]: i2c eeprom 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 74.684599] saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 74.684616] saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 74.684633] saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 74.684650] saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 74.684667] saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 74.684684] saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 74.684701] saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 74.684709] saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 74.684717] saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 74.684725] saa7133[0]: i2c eeprom e0: 00 00 00 00 ff ff ff ff ff ff ff ff ff ff ff ff [ 74.684733] saa7133[0]: i2c eeprom f0: 42 54 56 30 30 30 30 ff ff ff ff ff ff ff ff ff [ 74.684743] i2c-adapter i2c-7: Invalid 7-bit address 0x7a [ 74.712024] tuner 7-0061: chip found @ 0xc2 (saa7133[0]) [ 74.819118] xc5000 7-0061: creating new instance [ 74.828015] xc5000: Successfully identified at address 0x61 [ 74.828019] xc5000: Firmware has not been loaded previously [ 103.120811] input: i2c IR (BeholdTV) as /class/input/input5 [ 103.120847] ir-kbd-i2c: i2c IR (BeholdTV) detected at i2c-7/7-002d/ir0 [saa7133[0]] [ 103.152055] saa7133[0]: found muPD61151 MPEG encoder [ 103.152216] saa7134 :04:01.0: spi master registered: bus_num=32766 num_chipselect=1 [ 103.152322] saa7133[0]: registered device video0 [v4l2] [ 103.152340] saa7133[0]: registered device vbi0 [ 103.152358] saa7133[0]: registered device radio0 [ 103.168060] saa7133[0]: registered device video1 [mpeg] [ 103.196503] saa7134 ALSA driver for DMA sound loaded [ 103.196514] IRQ 19/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs [ 103.196531] saa7133[0]/alsa: saa7133[0] at 0xe510 irq 19 registered as card -1 [ 103.198892] xc5000: I2C write failed (len=4) [ 103.300018] xc5000: I2C write failed (len=4) [ 103.304799] xc5000: I2C read failed [ 103.304808] xc5000: I2C read failed [ 103.304810] xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... [ 103.304813] saa7134 :04:01.0: firmware: requesting dvb-fe-xc5000-1.6.114.fw [ 103.347409] xc5000: firmware read 12401 bytes. [ 103.347413] xc5000: firmware uploading... [ 106.676008] xc5000: firmware upload complete... Next point I think is write v4l2 workaround for SPI like I2C bus. Functions: v4l2_i2c_new_subdev -> v4l2_spi_new_subdev v4l2_i2c_new_subdev_cfg -> v4l2_spi_new_subdev_cfg v4l2_i2c_new_subdev_board -> v4l2_spi_new_subdev_board v4l2_i2c_subdev_init -> v4l2_spi_subdev_init i2c_set_clientdata -> spi_set_clientdata Who can do it?? Or help me with it?? With my best regards, Dmitry. -- 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