webcam drivers and V4L2_MEMORY_USERPTR support
hi, I have implemented support for V4L2_MEMORY_USERPTR buffers in gstreamers v4l2src [1]. This allows to request shared memory buffers from xvideo, capture into those and therefore save a memcpy. This works great with the v4l2 driver on our embedded device. When I was testing this on my desktop, I noticed that almost no driver seems to support it. I tested zc0301 and uvcvideo, but also grepped the kernel driver sources. It seems that gspca might support it, but I ave not confirmed it. Is there a technical reason for it, or is it simply not implemented? Thanks Stefan [1] http://bugzilla.gnome.org/show_bug.cgi?id=583890 -- 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: [PULL] http://udev.netup.ru/hg/v4l-dvb-aospan
Em Wed, 27 May 2009 22:15:17 +0400 Abylai Ospan aos...@netup.ru escreveu: Mauro, Please pull from http://udev.netup.ru/hg/v4l-dvb-aospan/rev/e90b61dfd602 Transport Stream continuity check. Very usefull for debugging when broken transport stream received. Pulled, thanks. +/* + * uncomment this define for transport stream packets continuity counter check + * #define DVB_DEMUX_SECTION_TS_COUNTER_CHECK + */ It wouldn't be better to add it as a Kconfig or as a module option, in order to be easy for people to enable it? Also, it may make sense to change it to use printk_ratelimit, to avoid it to produce too much printk errors. 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: webcam drivers and V4L2_MEMORY_USERPTR support
On Mon, 1 Jun 2009, Stefan Kost wrote: I have implemented support for V4L2_MEMORY_USERPTR buffers in gstreamers v4l2src [1]. This allows to request shared memory buffers from xvideo, capture into those and therefore save a memcpy. This works great with the v4l2 driver on our embedded device. When I was testing this on my desktop, I noticed that almost no driver seems to support it. I tested zc0301 and uvcvideo, but also grepped the kernel driver sources. It seems that gspca might support it, but I ave not confirmed it. Is there a technical reason for it, or is it simply not implemented? userptr support is relatively new and so it has less support, especially with driver that pre-date it. Maybe USB cams use a compressed format and so userptr with xvideo would not work anyway since xv won't support the camera's native format. It certainly could be done for bt8xx, cx88, saa7134, etc. -- 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: webcam drivers and V4L2_MEMORY_USERPTR support
Trent Piepho schrieb: On Mon, 1 Jun 2009, Stefan Kost wrote: I have implemented support for V4L2_MEMORY_USERPTR buffers in gstreamers v4l2src [1]. This allows to request shared memory buffers from xvideo, capture into those and therefore save a memcpy. This works great with the v4l2 driver on our embedded device. When I was testing this on my desktop, I noticed that almost no driver seems to support it. I tested zc0301 and uvcvideo, but also grepped the kernel driver sources. It seems that gspca might support it, but I ave not confirmed it. Is there a technical reason for it, or is it simply not implemented? userptr support is relatively new and so it has less support, especially with driver that pre-date it. Maybe USB cams use a compressed format and so userptr with xvideo would not work anyway since xv won't support the camera's native format. It certainly could be done for bt8xx, cx88, saa7134, etc. -- 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 Yes, I am aware of the format issue. On the gstreamer side formats are negotiated. Plugins export e.g. wat colorpsaces they support and the zerocopy path can only be taken if e.g. both support UVYV. Luckily this is quite common. But thanks for the info. I have nver touched kernel code sofar, but if I find some free time, I can try to add support for it in one driver. Stefan -- 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
[SOLVED] Re: Mystique SaTiX DVB-S2 s2-liplianin Ubuntu 9.04 64 bit - modules load but tuning not successful
Thomas Kernen wrote: Dear team, I'm installing a Mystique SaTiX DVB-S2 PCI card (apparently an OEM version of KNC DVB Station S2) in a box running Ubuntu 9.04 64bit. (2.6.28-11-server #42-Ubuntu SMP Fri Apr 17 02:45:36 UTC 2009 x86_64 GNU/Linux) I've pulled the latest s2-liplianin code from: http://mercurial.intuxication.org/hg/s2-liplianin I was able to compile and the modules do load, but I don't seem to be able to tune to anything. Note that I've only tried to tune to DVB-S transponders for now. lspci -vvv shows the following: 11:09.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) Subsystem: KNC One Device 0019 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 123 (3750ns min, 9500ns max) Interrupt: pin A routed to IRQ 23 Region 0: Memory at d022 (32-bit, non-prefetchable) [size=512] Kernel driver in use: budget_av Kernel modules: budget-av From dmesg: [9.796943] budget_av :11:09.0: PCI INT A - GSI 23 (level, low) - IRQ 23 [9.796972] saa7146: found saa7146 @ mem c20001186000 (revision 1, irq 23) (0x1894,0x0019). [9.796976] saa7146 (0): dma buffer size 192512 [9.796977] DVB: registering new adapter (KNC1 DVB-S2) [9.853417] adapter failed MAC signature check [9.853419] encoded MAC from EEPROM was ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff [ 10.162850] KNC1-1: MAC addr = 00:09:d6:65:2d:91 [ 10.35] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer [ 10.424422] stb0899_attach: Attaching STB0899 [ 10.432541] tda8261_attach: Attaching TDA8261 8PSK/QPSK tuner [ 10.432543] DVB: registering adapter 1 frontend 0 (STB0899 Multistandard)... [ 10.432731] budget-av: ci interface initialised. dvbsnoop shows the following: dvbsnoop V1.4.50 -- http://dvbsnoop.sourceforge.net/ - FrontEnd Info... - Device: /dev/dvb/adapter1/frontend0 Basic capabilities: Name: STB0899 Multistandard Frontend-type: QPSK (DVB-S) Frequency (min): 950.000 MHz Frequency (max): 2150.000 MHz Frequency stepsiz: 0.000 MHz Frequency tolerance: 0.000 MHz Symbol rate (min): 1.00 MSym/s Symbol rate (max): 45.00 MSym/s Symbol rate tolerance: 0 ppm Notifier delay: 0 ms Frontend capabilities: auto inversion FEC AUTO QPSK Current parameters: Frequency: 1776.000 MHz Inversion: AUTO Symbol rate: 27.50 MSym/s FEC: FEC AUTO If I try to use scan-s2 I get the following output: API major 5, minor 0 ERROR: Cannot open rotor configuration file 'rotor.conf'. scanning /usr/share/dvb/dvb-s/Astra-19.2E using '/dev/dvb/adapter1/frontend0' and '/dev/dvb/adapter1/demux0' initial transponder DVB-S 12551500 V 2200 5/6 AUTO AUTO initial transponder DVB-S2 12551500 V 2200 5/6 AUTO AUTO -- Using DVB-S tune to: 12551:vC56S0:S0.0W:22000: DiSEqC: uncommitted switch pos 0 DiSEqC: e0 10 39 f0 00 00 DiSEqC: switch pos 0, 13V, hiband (index 2) DiSEqC: e0 10 38 f1 00 00 DVB-S IF freq is 1951500 tuning status == 0x00 tuning status == 0x00 tuning status == 0x00 tuning status == 0x00 tuning status == 0x00 tuning status == 0x00 tuning status == 0x00 tuning status == 0x00 tuning status == 0x00 tuning status == 0x00 WARNING: tuning failed!!! tune to: 12551:vC56S0:S0.0W:22000: (tuning failed) DiSEqC: uncommitted switch pos 0 DiSEqC: e0 10 39 f0 00 00 DiSEqC: switch pos 0, 13V, hiband (index 2) DiSEqC: e0 10 38 f1 00 00 DVB-S IF freq is 1951500 tuning status == 0x00 tuning status == 0x00 tuning status == 0x00 tuning status == 0x00 tuning status == 0x00 tuning status == 0x00 tuning status == 0x00 tuning status == 0x00 tuning status == 0x00 tuning status == 0x00 WARNING: tuning failed!!! -- Using DVB-S2 tune to: 12551:vC56S1:S0.0W:22000: DiSEqC: uncommitted switch pos 0 DiSEqC: e0 10 39 f0 00 00 DiSEqC: switch pos 0, 13V, hiband (index 2) DiSEqC: e0 10 38 f1 00 00 DVB-S IF freq is 1951500 tuning status == 0x00 tuning status == 0x00 tuning status == 0x00 tuning status == 0x00 tuning status == 0x00 tuning status == 0x00 tuning status == 0x00 tuning status == 0x00 tuning status == 0x00 tuning status == 0x00 WARNING: tuning failed!!! tune to: 12551:vC56S1:S0.0W:22000: (tuning failed) DiSEqC: uncommitted switch pos 0 DiSEqC: e0 10 39 f0 00 00 DiSEqC: switch pos 0, 13V, hiband (index 2) DiSEqC: e0 10 38 f1 00 00 DVB-S IF freq is 1951500 tuning status == 0x00 tuning status == 0x00 tuning status == 0x00 tuning status == 0x00 tuning status == 0x00 tuning status == 0x00 tuning status ==
Re: [PULL] http://udev.netup.ru/hg/v4l-dvb-aospan
Mauro, В Пнд, 01/06/2009 в 04:52 -0300, Mauro Carvalho Chehab пишет: + * uncomment this define for transport stream packets continuity counter check + * #define DVB_DEMUX_SECTION_TS_COUNTER_CHECK + */ It wouldn't be better to add it as a Kconfig or as a module option, in order to be easy for people to enable it? module option seems more flexible. Also, it may make sense to change it to use printk_ratelimit, to avoid it to produce too much printk errors. yes, this right. Please pulll new changes - http://udev.netup.ru/hg/v4l-dvb-aospan/rev/4acf883807a8 1. Module option dvb_demux_tscheck added. Can be changed on fly ( by echo 1 /sys/module/dvb_core/parameters/dvb_demux_tscheck). Check disabled by default. 2. printk_ratelimit used. 3. DVB_DEMUX_SECTION_TS_COUNTER_CHECK define removed -- Abylai Ospan aos...@netup.ru NetUP Inc. smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH] Leadtek WinFast DTV-1800H support
Em Mon, 01 Jun 2009 03:58:25 +0200 hermann pitton hermann-pit...@arcor.de escreveu: Am Sonntag, den 31.05.2009, 16:58 -0300 schrieb Mauro Carvalho Chehab: Em Sun, 31 May 2009 19:39:15 +0200 Miroslav Šustek sustmid...@centrum.cz escreveu: Trent Piepho xyzzy at speakeasy.org writes: Instead of raising the reset line here, why not change the gpio settings in the card definition to have it high? Change gpio1 for television to 0x7050 and radio to 0x7010. Personally, I don't know when these .gpioX members are used (before firmware loads or after...). But I assume that adding the high on reset pin shouldn't break anything, so we can do this. And shouldn't we put tuner reset pin to 0 when in composite and s-video mode? These inputs don't use tuner or do they? If I look in dmesg I can see that firmware is loaded into tuner even when these modes are used (I'm using MPlayer to select the input). And due to callbacks issued duting firmware loading, tuner is turned on (reset pin = 1) no matter if it was turned off by .gpioX setting. And shouldn't we use the mask bits [24:16] of MO_GPX_IO in .gpioX members too? I know only few GPIO pins and the other I don't know either what direction they should be. That means GPIO pins which I don't know are set as Hi-Z = inputs... Now, when I think of that, if it works it's safer when the other pins are in Hi-Z mode. Never mind. Then the reset can be done with: case XC2028_TUNER_RESET: /* GPIO 12 (xc3028 tuner reset) */ cx_write(MO_GP1_IO, 0x101000); mdelay(50); cx_write(MO_GP1_IO, 0x101010); mdelay(50); return 0; Earlier I was told to use 'cx_set' and 'cx_clear' because using 'cx_write' is risky. see here: http://www.spinics.net/lists/linux-dvb/msg29777.html And when you are using 'cx_set' and 'cx_clear' you need 3 calls. The first to set the direction bit, the second to set 0 on reset pin and the third to set 1 on reset pin. If you ask me which I think is nicer I'll tell you: that one with 'cx_write'. If you ask me which one I want to use, I'll tell: I don't care. :) Though I have to wonder why each card needs its own xc2028 reset function. Shouldn't they all be the same other than what gpio they change? My English goes lame here. Do you mean that reset function shouldn't use GPIO at all? @@ -2882,6 +2946,16 @@ cx_set(MO_GP0_IO, 0x0080); /* 702 out of reset */ udelay(1000); break; + + case CX88_BOARD_WINFAST_DTV1800H: + /* GPIO 12 (xc3028 tuner reset) */ + cx_set(MO_GP1_IO, 0x1010); + mdelay(50); + cx_clear(MO_GP1_IO, 0x10); + mdelay(50); + cx_set(MO_GP1_IO, 0x10); + mdelay(50); + break; } } Couldn't you replace this with: case CX88_BOARD_WINFAST_DTV1800H: cx88_xc3028_winfast1800h_callback(code, XC2028_TUNER_RESET, 0); break; Yes, this will do the same job. I think that 'cx88_card_setup_pre_i2c' is to be called before any I2C communication. The 'cx88_xc3028_winfast1800h_callback' (cx88_tuner_callback) is meant to be used when tuner code (during firmware loading) needs it. This is probably why others did it this way (these are separated issues even if they do the same thing) and I only obey existing form. I only want to finally add the support for this card. You know many people (not developers) don't care if this function is used or that function is used twice, instead. They just want to install they distro and watch the tv. I classify myself as an programmer rather than ordinary user, so I care how the code looks like. I'm open to the discussion about these things, but this can take long time and I just want the card to be supported asap. There are more cards which has code like this so if linuxtv developers realize eg. to not use callbacks or use only cx_set and cx_clear (instead of cx_write) they'll do it all at once (not every card separately). I attached modified patch: - .gpioX members of inputs which use tuner have reset pin 1 (tuner enabled) - .gpioX members of inputs which don't use tuner have reset pin 0 (tuner disabled) - resets (in callback and the one in pre_i2c) use only two 'cx_write' calls I'm keeping the tested-by lines even if this modified version of patch wasn't tested by those people (the previous version was). I trust this changes can't break the functionality. If you think it's too audacious then drop them. It's on linuxtv developers which of these two patches will be chosen. For the sake of not loosing this patch again, I've applied it as-is. I hope I got the latest version. It is hard to track patches that aren't got by patchwork. I agree with Trent's proposals for optimizing the code: It is better to just call
Re: [PULL] http://udev.netup.ru/hg/v4l-dvb-aospan
Em Mon, 01 Jun 2009 13:02:56 +0400 Abylai Ospan aos...@netup.ru escreveu: Mauro, В Пнд, 01/06/2009 в 04:52 -0300, Mauro Carvalho Chehab пишет: + * uncomment this define for transport stream packets continuity counter check + * #define DVB_DEMUX_SECTION_TS_COUNTER_CHECK + */ It wouldn't be better to add it as a Kconfig or as a module option, in order to be easy for people to enable it? module option seems more flexible. Also, it may make sense to change it to use printk_ratelimit, to avoid it to produce too much printk errors. yes, this right. Please pulll new changes - http://udev.netup.ru/hg/v4l-dvb-aospan/rev/4acf883807a8 # HG changeset patch # User Abylay Ospan aos...@netup.ru # Date 1243846636 -14400 # Node ID 4acf883807a8f9fcd82f7c45ee61513955b6a82b # Parent d55ec37bebfa91dfa0586393551382ba37355b56 TS continuity check: show error message when discontinuity detected or TEI flag detected in header Signed-off-by: Abylay Ospan aos...@netup.ru --- a/linux/drivers/media/dvb/dvb-core/dvb_demux.cMon Jun 01 05:22:37 2009 -0300 +++ b/linux/drivers/media/dvb/dvb-core/dvb_demux.cMon Jun 01 12:57:16 2009 +0400 @@ -37,6 +37,13 @@ ** #define DVB_DEMUX_SECTION_LOSS_LOG to monitor payload loss in the syslog */ // #define DVB_DEMUX_SECTION_LOSS_LOG + +static int dvb_demux_tscheck; +module_param(dvb_demux_tscheck, int, 0644); +MODULE_PARM_DESC(dvb_demux_tscheck, enable transport stream continuity and TEI check); + +#define dprintk_tscheck(x...) do { if (dvb_demux_tscheck printk_ratelimit()) printk(x); } while (0) Please check your patch against kernel codingstyle with checkpatch.pl. There are some CodingStyle violations here and on the code bellow. In this specific case, break it into one statement per line, like: #define dprintk_tscheck(x...) do { \ if (dvb_demux_tscheck printk_ratelimit())\ printk(x); \ } while (0) + /** * static inlined helper functions @@ -375,6 +382,24 @@ struct dvb_demux_feed *feed; u16 pid = ts_pid(buf); int dvr_done = 0; + + int cnt_pid; + + if(dvb_demux_tscheck){ CodingStyle. + /* check pkt counter */ + cnt_pid = ( (buf[1] 0x1f)8 ) | buf[2]; CodingStyle. + + if(cnt_pid != 0x1fff){ CodingStyle. + if( buf[1] 0x80 ) CodingStyle. + dprintk_tscheck(TEI detected. PID=0x%x data1=0x%x\n, cnt_pid, buf[1] ); CodingStyle. + + if( (buf[3] 0xf) != demux-cnt_storage[cnt_pid] ) CodingStyle. + dprintk_tscheck(TS packet counter mismatch. PID=0x%x expected 0x%x got 0x%x\n, cnt_pid, demux-cnt_storage[cnt_pid], buf[3] 0xf ); CodingStyle. + + demux-cnt_storage[cnt_pid] = ( (buf[3] 0xf) + 1) 0xf; CodingStyle. + }; + /* end check */ + }; list_for_each_entry(feed, demux-feed_list, list_head) { if ((feed-pid != pid) (feed-pid != 0x2000)) --- a/linux/drivers/media/dvb/dvb-core/dvb_demux.hMon Jun 01 05:22:37 2009 -0300 +++ b/linux/drivers/media/dvb/dvb-core/dvb_demux.hMon Jun 01 12:57:16 2009 +0400 @@ -128,6 +128,8 @@ struct mutex mutex; spinlock_t lock; + + uint8_t cnt_storage[0x1fff]; /// for TS continuity check Please, don't add the penalty of increasing the size of the struct to this amount of size if debug is disabled. You should instead add a pointer here and allocate it dynamically only if debug is enabled. }; int dvb_dmx_init(struct dvb_demux *dvbdemux); Also, as the previous changeset were already merged, do your patch against the current tree 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: [linux-dvb] SDMC DM1105N not being detected
Igor M. Liplianin wrote: On 30 May 2009 20:00:32 Igor M. Liplianin wrote: On 26 May 2009 23:02:57 Simon Kenyon wrote: Igor M. Liplianin wrote: The card is working with external LNB power supply, for example, through the loop out from another sat box. So, we need to know, which way to control LNB power on the board. Usually it is through GPIO pins. For example: Pins 112 and 111 for GPIO0, GPIO1. Also GPIO15 is at 65 pin. You can edit this lines in code: -*-*-*-*-*-*-*-*-*-*-*-*- /* GPIO's for LNB power control for Axess DM05 */ #define DM05_LNB_MASK 0xfffc // GPIO control #define DM05_LNB_13V0x3fffd // GPIO value #define DM05_LNB_18V0x3fffc // GPIO value -*-*-*-*-*-*-*-*-*-*-*-*- BTW: Bit value 0 for GPIOCTL means output, 1 - input. Bit value for GPIOVAL - read/write. GPIO pins count is 18. Bits over 18 affect nothing. i will try to work out the correct values when i have done so (or given up trying) i will let you know thank you very much for your help -- simon -- 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 against latest v4l-dvb. Please, test it. Patch version 2 the picture seems to be breaking up badly will revert to my version and see if that fixes it -- simon -- 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] xc2028: Add support for Taiwan 6 MHz DVB-T
On Sun, 2009-05-31 at 20:50 -0400, Andy Walls wrote^Wescreveu: On Sun, 2009-05-31 at 16:33 -0300, Mauro Carvalho Chehab wrote: Em Sun, 31 May 2009 13:39:18 -0400 Andy Walls awa...@radix.net escreveu: then I guess I'm OK with the change you have. Hmmm. Maybe not. So, the proper patch to tuner-xc3028 seems to be the enclosed one. If both of you and Terry agree, I'll apply this one at the tree. I have to do more looking. The + } else if (priv-cur_fw.type DTV6) { + /* For Taiwan DVB-T 6 MHz bandwidth - Terry Wu */ + offset = 175; offset part of Terry's patch is missing from yours. Based on what I now know, I think setting the offset is necessary for 6 MHz DVB-T (DTV6) to work. I'll try to resubmit something tonight. Regards, Andy Cheers, Mauro. diff --git a/linux/drivers/media/common/tuners/tuner-xc2028.c b/linux/drivers/media/common/tuners/tuner-xc2028.c --- a/linux/drivers/media/common/tuners/tuner-xc2028.c +++ b/linux/drivers/media/common/tuners/tuner-xc2028.c @@ -1026,21 +1026,20 @@ static int xc2028_set_params(struct dvb_ switch(fe-ops.info.type) { case FE_OFDM: bw = p-u.ofdm.bandwidth; - break; - case FE_QAM: - tuner_info(WARN: There are some reports that - QAM 6 MHz doesn't work.\n - If this works for you, please report by - e-mail to: v4l-dvb-maintai...@linuxtv.org\n); - bw = BANDWIDTH_6_MHZ; - type |= QAM; + /* +* The only countries with 6MHz seem to be Taiwan/Uruguay. +* Both seem to require QAM firmware for OFDM decoding +* Tested in Taiwan by Terry Wu terrywu2...@gmail.com +*/ + if (bw == BANDWIDTH_6_MHZ) + type |= QAM; break; case FE_ATSC: bw = BANDWIDTH_6_MHZ; /* The only ATSC firmware (at least on v2.7) is D2633 */ type |= ATSC | D2633; break; - /* DVB-S is not supported */ + /* DVB-S and pure QAM (FE_QAM) are not supported */ default: return -EINVAL; } 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 -- 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: Wiki software update
Hi Hermann, On Mon, Jun 01, 2009 at 02:08:07AM +0200, hermann pitton wrote: Am Montag, den 01.06.2009, 01:28 +0200 schrieb Johannes Stezenbach: I just updated the V4L-DVB Wiki and the old V4L Wiki to MediaWiki-1.14.0. Please let me know in case something broke. did not test all links, but on this one some older issues seem to still perpetuate. http://www.linuxtv.org/wiki/index.php?title=How_to_Perform_a_Bisectaction=edit I get, that I'm not allowed to do that. Well, you need to be logged in to create or edit pages. Or are you saying that you cannot edit this page even though you are logged in? Johannes -- 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
Zolid Hybrid TV Card wiki page
Hi, I've just created a wiki page for my tv card: http://www.linuxtv.org/wiki/index.php/Zolid_Hybrid_TV_Tuner/ . I hope it provides usable information to make my card supported by saa7134. -- Met vriendelijke groet, Sander Pientka -- 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: Wiki software update
On Mon, Jun 01, 2009 at 12:14:08PM +1000, Robin Perkins wrote: On 01/06/2009, at 9:28 AM, Johannes Stezenbach wrote: I just updated the V4L-DVB Wiki and the old V4L Wiki to MediaWiki-1.14.0. Please let me know in case something broke. Is there any possibility of renaming the v4l-dvb wiki to perhaps the Linux-media Wiki just to get some persistence in names ? (I have had people on irc ask if v4l-dvb can only do dvb.) Perhaps reflect that Linux-media does more than just DVB on the LinuxTV main page as well? I'd be fine with a rename, but I leave it up the Wiki power users to decide. The links on http://wiki.kernel.org/ should also be changed. Johannes -- 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: webcam drivers and V4L2_MEMORY_USERPTR support
On 06/01/2009 09:58 AM, Trent Piepho wrote: On Mon, 1 Jun 2009, Stefan Kost wrote: I have implemented support for V4L2_MEMORY_USERPTR buffers in gstreamers v4l2src [1]. This allows to request shared memory buffers from xvideo, capture into those and therefore save a memcpy. This works great with the v4l2 driver on our embedded device. When I was testing this on my desktop, I noticed that almost no driver seems to support it. I tested zc0301 and uvcvideo, but also grepped the kernel driver sources. It seems that gspca might support it, but I ave not confirmed it. Is there a technical reason for it, or is it simply not implemented? userptr support is relatively new and so it has less support, especially with driver that pre-date it. Maybe USB cams use a compressed format and so userptr with xvideo would not work anyway since xv won't support the camera's native format. It certainly could be done for bt8xx, cx88, saa7134, etc. Even in the webcam with custom compressed format case, userptr support could be useful to safe a memcpy, as libv4l currently fakes mmap buffers, so what happens is: cam direct transfer mmap buffer libv4l format conversion fake mmap buffer application-memcpy dest buffer So if libv4l would support userptr's (which it currently does not do) we could still safe a memcpy here. I would be willing to take *clean, non invasive* patches to libv4l to add userptr support, but I'm not sure if this can be done in a clean way (haven't tried). An alternative could be for the app to just use read() in the above case as then the app already provides the dest buffer. And the conversion will write directly to the application provided buffer. Regards, Hans -- 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
CAM initialisation failing
Dear community, After finally getting my Mystique SaTiX DVB-S2 PCI card (clone of KNC1 DVB Station S2), I'm now facing trouble with the CAM initialisation (KNC1 CA daughter card, PowerCam Pro CAM and Viaccess card) All of the hardware (DVB-S2 PCI card, sat card, CI, CAM) has been tested under Windows with any issues, hence I suspect this is a module related issue. To try and better understand the issue, I added some debug statements to the following modules: options dvb-core cam_debug=1 debug=1 options budget-core debug=1 And this is the output I'm getting: [9.146782] DVB: registering new adapter (KNC1 DVB-S2) [9.203364] adapter failed MAC signature check [9.203366] encoded MAC from EEPROM was ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff [9.410061] budget_av: saa7113_init(): saa7113 not found on KNC card [9.510352] KNC1-1: MAC addr = 00:09:d6:65:2d:91 [9.642505] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer [9.764427] stb0899_attach: Attaching STB0899 [9.776853] tda8261_attach: Attaching TDA8261 8PSK/QPSK tuner [9.776855] DVB: registering adapter 1 frontend 0 (STB0899 Multistandard)... [9.776888] dvb_ca_en50221_init [9.777048] budget-av: ci interface initialised. [9.777050] dvb_ca_en50221_thread snip [ 14.770017] budget-av: cam inserted A [ 14.770032] budget_av: ciintf_slot_reset(): ciintf_slot_reset [ 14.950033] TUPLE type:0x1d length:4 [ 14.950041] 0x00: 0x00 . [ 14.950048] 0x01: 0x61 a [ 14.950055] 0x02: 0x00 . [ 14.950063] 0x03: 0xff . [ 14.950076] TUPLE type:0x1c length:4 [ 14.950083] 0x00: 0x00 . [ 14.950091] 0x01: 0xd3 . [ 14.950098] 0x02: 0x00 . [ 14.950105] 0x03: 0xff . [ 14.950118] TUPLE type:0x15 length:11 [ 14.950126] 0x00: 0x05 . [ 14.950133] 0x01: 0x00 . [ 14.950140] 0x02: 0x47 G [ 14.950147] 0x03: 0x00 . [ 14.950154] 0x04: 0x4d M [ 14.950161] 0x05: 0x00 . [ 14.950168] 0x06: 0x4c L [ 14.950175] 0x07: 0x00 . [ 14.950182] 0x08: 0x4c L [ 14.950189] 0x09: 0x00 . [ 14.950196] 0x0a: 0xff . [ 14.950210] TUPLE type:0x20 length:4 [ 14.950217] 0x00: 0x02 . [ 14.950224] 0x01: 0xca . [ 14.950232] 0x02: 0x12 . [ 14.950239] 0x03: 0x60 ` [ 14.950252] TUPLE type:0x1a length:21 [ 14.950260] 0x00: 0x01 . [ 14.950267] 0x01: 0x0f . [ 14.950274] 0x02: 0x00 . [ 14.950281] 0x03: 0x02 . [ 14.950288] 0x04: 0x03 . [ 14.950295] 0x05: 0xc0 . [ 14.950302] 0x06: 0x0e . [ 14.950309] 0x07: 0x41 A [ 14.950316] 0x08: 0x02 . [ 14.950323] 0x09: 0x44 D [ 14.950330] 0x0a: 0x56 V [ 14.950337] 0x0b: 0x42 B [ 14.950344] 0x0c: 0x5f _ [ 14.950352] 0x0d: 0x43 C [ 14.950359] 0x0e: 0x49 I [ 14.950366] 0x0f: 0x5f _ [ 14.950373] 0x10: 0x56 V [ 14.950380] 0x11: 0x31 1 [ 14.950387] 0x12: 0x2e . [ 14.950394] 0x13: 0x30 0 [ 14.950401] 0x14: 0x30 0 [ 14.950415] TUPLE type:0x1b length:42 [ 14.950422] 0x00: 0xcf . [ 14.950429] 0x01: 0x04 . [ 14.950436] 0x02: 0x09 . [ 14.950443] 0x03: 0x7f . [ 14.950450] 0x04: 0x55 U [ 14.950458] 0x05: 0xcd . [ 14.950465] 0x06: 0x19 . [ 14.950472] 0x07: 0xd5 . [ 14.950479] 0x08: 0x19 . [ 14.950486] 0x09: 0x3d = [ 14.950493] 0x0a: 0x9e . [ 14.950500] 0x0b: 0x25 % [ 14.950507] 0x0c: 0x26 [ 14.950514] 0x0d: 0x54 T [ 14.950521] 0x0e: 0x22 [ 14.950528] 0x0f: 0xc0 . [ 14.950535] 0x10: 0x09 . [ 14.950542] 0x11: 0x44 D [ 14.950549] 0x12: 0x56 V [ 14.950557] 0x13: 0x42 B [ 14.950564] 0x14: 0x5f _ [ 14.950571] 0x15: 0x48 H [ 14.950578] 0x16: 0x4f O [ 14.950585] 0x17: 0x53 S [ 14.950592] 0x18: 0x54 T [ 14.950599] 0x19: 0x00 . [ 14.950606] 0x1a: 0xc1 . [ 14.950613] 0x1b: 0x0e . [ 14.950620] 0x1c: 0x44 D [ 14.950627] 0x1d: 0x56 V [ 14.950634] 0x1e: 0x42 B [ 14.950642] 0x1f: 0x5f _ [ 14.950649] 0x20: 0x43 C [ 14.950656] 0x21: 0x49 I [ 14.950663] 0x22: 0x5f _ [ 14.950670] 0x23: 0x4d M [ 14.950677] 0x24: 0x4f O [ 14.950684] 0x25: 0x44 D [ 14.950691] 0x26: 0x55 U [ 14.950698] 0x27: 0x4c L [ 14.950705] 0x28: 0x45 E [ 14.950712] 0x29: 0x00 . [ 14.950727] TUPLE type:0x14 length:0 [ 14.950734] END OF CHAIN TUPLE type:0xff [ 14.950735] Valid DVB CAM detected MANID:ca02 DEVID:6012 CONFIGBASE:0x200 CONFIGOPTION:0xf [ 14.950736] dvb_ca_en50221_set_configoption [ 14.950750] Set configoption 0xf, read configoption 0xf [ 14.950757] DVB CAM validated successfully snip [ 15.050023] dvb_ca_en50221_link_init [ 15.050030] dvb_ca_en50221_wait_if_status [ 15.050037] dvb_ca_en50221_wait_if_status succeeded timeout:0 [ 15.050038] dvb_ca_en50221_read_data [ 15.050084] dvb_ca adapter 1: DVB CAM link initialisation failed :( So if I understand correctly the CAM is ok but the en50221 module is times out when trying to read the card, is this correct? Any
Re: [PULL] http://udev.netup.ru/hg/v4l-dvb-aospan
В Пнд, 01/06/2009 в 06:38 -0300, Mauro Carvalho Chehab пишет: Please check your patch against kernel codingstyle with checkpatch.pl. There are some CodingStyle violations here and on the code bellow. Please pull new changes - http://udev.netup.ru/hg/v4l-dvb-aospan/rev/0d3e6c0695cc 1. checkpatch.pl don't show warnings/errors ( except printk line length ). 2. cnt_storage array dinamically allocated before doing checks. We can't allocate it in dvb_dmx_init routine because module option dvb_demux_tscheck can be enabled on running system ( not in module startup only ). -- Abylai Ospan aos...@netup.ru NetUP Inc. smime.p7s Description: S/MIME cryptographic signature
Re: [PULL] generic image bounds setting and alignment function
Trent Piepho xy...@speakeasy.org writes: Mauro, Please pull from http://linuxtv.org/hg/~tap/v4l-dvb This series adds a function for bounding and alignment image sizes and modifies a number of drivers to use it. It came up when the pxa patches to deal with the alignment issues for that driver were posted. I haven't tested these patches for pxa. Hi Trent, I didn't see the review of that serie, I'm curious what others said. As for my comments, I'll inline your code, sorry about that. 02/14: v4l2: Create helper function for bounding and aligning images http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=b4d3ec8d363d +static unsigned int clamp_align(unsigned int x, unsigned int min, + unsigned int max, unsigned int align) +{ + /* Bits that must be zero to be aligned */ + unsigned int mask = ~((1 align) - 1); + + /* Round to nearest aligned value */ + if (align) + x = (x + (1 (align - 1))) mask; If I'm not mistaken, these lines are an equivalent of : balign = 1 align; if (align) x = ALIGN(x + 1 - balign/2, balign); Isn't that simpler to read ? + + /* Clamp to aligned value of min and max */ + if (x min) + x = (min + ~mask) mask; + else if (x max) + x = max mask; + + return x; +} 03/14: pxa-camera: Use v4l bounding/alignment function http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=cb48209c1841 + /* Limit to pxa hardware capabilities. YUV422P planar format requires + * images size to be a multiple of 16 bytes. If not, zeros will be + * inserted between Y and U planes, and U and V planes, which violates + * the YUV422P standard. */ The multiple lines comment format, according to the Coding Style, would be rather : /* * */ That is a question for Guennadi, as he is the maintainer of pxa_camera. + v4l2_bound_align_image(pix-width, 48, 2048, 1, + pix-height, 32, 2048, 0, + xlate-host_fmt-fourcc == V4L2_PIX_FMT_YUV422P ? 4 : 0); Cheers. -- Robert -- 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 3/9] dm355 ccdc module for vpfe capture driver
Laurent, Thanks for reviewing this. I have not gone through all of your comments, but would like to respond to the following one first. I will respond to the rest as I do the rework. I've had a quick look at the DM355 and DM6446 datasheets. The CCDC and VPSS registers share the same memory block. Can't you use a single resource ? One nice (and better in my opinion) solution would be to declare a structure with all the VPSS/CCDC registers as they are implemented in hardware and access the structure fields with __raw_read/write*. You would then store a single pointer only. Check arch/powerpc/include/asm/immap_cpm2.h for an example. I think, a better solution will be to move the vpss system module part to the board specific file dm355.c or dm6446.c and export functions to configure them as needed by the different drivers. The vpss has evolved quite a lot from DM6446 to DM355 to DM365. Registers such as INTSEL and INTSTAT and others are applicable to other modules as well, not just the ccdc module. The VPBE and resizer drivers will need to configure them too. Also the vpss system module features available in DM365 is much more than that in DM355. Interrupts line to ARM are programmable in DM365 vpss and multiple vpss irq lines can be muxed to the ARM side. So I would imaging functions enable/disable irq line to arm, clearing irq bits, enabling various clocks etc can be done in a specific soc specific file (dm355.c, dm365.c or dm6446.c) and can be exported for use in specific drivers. I just want to get your feedback so that I can make this change. With this change, there is no need to use structures for holding register offsets as you have suggested. -- 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
New Driver for DaVinci DM355/DM365/DM6446
Hello, WE have a module(H3A) on Davinci DM6446,DM355 and DM365. Customers require a way to collect the data required to perform the Auto Exposure (AE), Auto Focus(AF), and Auto White balance (AWB) in hardware as opposed to software. This is primarily for performance reasons as there is not enough software processing MIPS (to do 3A statistics) available in an imaging/video system. Including this block in hardware reduces the load on the processor and bandwidth to the memory as the data is collected on the fly from the imager. This modules collects statistics and we currently implement it as a character driver. Which mailing list would be the most appropriate mailing list to submit patches for review? Thanks, Sandeep -- 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] em28xx device mode detection based on endpoints
On Sat, May 23, 2009 at 11:05 AM, Markus Rechberger mrechber...@gmail.com wrote: Hi, On Sat, May 23, 2009 at 4:49 PM, Markus Rechberger mrechber...@gmail.com wrote: On Sat, May 23, 2009 at 4:04 PM, Markus Rechberger mrechber...@gmail.com wrote: Hi, for em28xx devices the device node detection can be based on the encoded endpoint address, for example EP 0x81 (USB IN, Interrupt), 0x82 (analog video EP), 0x83 (analog audio ep), 0x84 (mpeg-ts input EP). It is not necessary that digital TV devices have a frontend, the em28xx chip only specifies an MPEG-TS input EP. Following patch adds a check based on the Endpoints, although it might be extended that all devices match the possible devicenodes based on the endpoints, currently the driver registers an analog TV node by default for all unknown devices which is not necessarily correct, this patch disables the ATV node if no analog TV endpoint is available. attached patch fixes the deregistration, as well loads the em28xx-dvb module automatically as soon as an MPEG-TS endpoint was found. Signed-off-by: Markus Rechberger mrechber...@gmail.com best regards, Markus Hello Markus, I spent some time reviewing this patch, and the patch's content does not seem to match your description of its functionality. Further, this patch appears to be a combination of a number of several different changes, rather than being broken into separate patches. First off, I totally agree that the analog subsystem should not be loaded on devices such as em287[0-4]. I was going to do this work (using the chip id to determine analog support) but just had not had a chance to doing the necessary testing to ensure it did not break anything. The patch appears to be primarily for devices that are not supported in the kernel. In fact, the logic as written *only* gets used for unknown devices. Further, the code that doesn't create the frontend device has no application in the kernel. All devices currently in the kernel make use of the dvb frontend interface, so there is no practical application to loading the driver and setting up the isoc handlers but blocking access to the dvb frontend device. Aside from the code that selectively disables analog support, the patch only seems to advance compatibility with your userland em28xx framework while providing no benefit to the in-kernel driver. Regarding the possibility of custom firmware, we currently do not have any devices in the in-kernel driver that make use of custom firmware. If you could tell me how to check for custom firmware versus the default vendor firmware, I could potentially do a patch that uses the vendor registers unless custom firmware is installed, at which point we could have custom logic (such as using the endpoint definition). However, given there are no such devices in-kernel, this is not a high priority as far as I am concerned. For what it's worth, I did add an additional patch to allow the user to disable the 480Mbps check via a modprobe option (to avoid a regression for any of your existing customers), and I will be checking in the code to properly compute the isoc size for em2874/em2884 based on the vendor registers (even though there are currently no supported devices in the kernel that require it currently). However, I do not believe the patch you have proposed is appropriate for inclusion in the mainline kernel. Regards, 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] em28xx device mode detection based on endpoints
On Mon, Jun 1, 2009 at 5:19 PM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: On Sat, May 23, 2009 at 11:05 AM, Markus Rechberger mrechber...@gmail.com wrote: Hi, On Sat, May 23, 2009 at 4:49 PM, Markus Rechberger mrechber...@gmail.com wrote: On Sat, May 23, 2009 at 4:04 PM, Markus Rechberger mrechber...@gmail.com wrote: Hi, for em28xx devices the device node detection can be based on the encoded endpoint address, for example EP 0x81 (USB IN, Interrupt), 0x82 (analog video EP), 0x83 (analog audio ep), 0x84 (mpeg-ts input EP). It is not necessary that digital TV devices have a frontend, the em28xx chip only specifies an MPEG-TS input EP. Following patch adds a check based on the Endpoints, although it might be extended that all devices match the possible devicenodes based on the endpoints, currently the driver registers an analog TV node by default for all unknown devices which is not necessarily correct, this patch disables the ATV node if no analog TV endpoint is available. attached patch fixes the deregistration, as well loads the em28xx-dvb module automatically as soon as an MPEG-TS endpoint was found. Signed-off-by: Markus Rechberger mrechber...@gmail.com best regards, Markus Hello Markus, I spent some time reviewing this patch, and the patch's content does not seem to match your description of its functionality. Further, this patch appears to be a combination of a number of several different changes, rather than being broken into separate patches. what doesn't match the description? First off, I totally agree that the analog subsystem should not be loaded on devices such as em287[0-4]. I was going to do this work (using the chip id to determine analog support) but just had not had a chance to doing the necessary testing to ensure it did not break anything. The patch appears to be primarily for devices that are not supported in the kernel. In fact, the logic as written *only* gets used for unknown devices. Further, the code that doesn't create the frontend device has no application in the kernel. this is wrong, there are devices without a tuner frontend, mpeg encoders (as written earlier already) The em28xx chip only defines an mpeg-ts input, whenever a customer wants to add a frontend or mpeg encoder is up to him. All devices currently in the kernel make use of the dvb frontend interface, so there is no practical application to loading the driver and setting up the isoc handlers but blocking access to the dvb frontend device. Aside from the code that selectively disables analog support, the patch only seems to advance compatibility with your userland em28xx framework while providing no benefit to the in-kernel driver. There's also a tuner customization option in the kernel module (eg set tuner ID manually). This more or less can be seen as a cleanup, further patches would come up. The next step would be to add customization support for various chips this would allow me to just drop in a demod for certain customers who are aware that they are not allowed to forward their modules. The application is mainly for business customers who don't ship to endusers and make up a direct deal with eg. Micronas. There is no reason to punish one company because the other one denies it. Regarding the possibility of custom firmware, we currently do not have any devices in the in-kernel driver that make use of custom firmware. If you could tell me how to check for custom firmware versus the default vendor firmware, I could potentially do a patch that uses the vendor registers unless custom firmware is installed, at which point we could have custom logic (such as using the endpoint definition). However, given there are no such devices in-kernel, this is not a high priority as far as I am concerned. endpoint size as mentioned already, old firmware shows up the endpoint size of 0 newer one shows up a certain size. For what it's worth, I did add an additional patch to allow the user to disable the 480Mbps check via a modprobe option (to avoid a regression for any of your existing customers) All my customers are using the other kernel driver since the existing one is too limited right now best regards, Markus -- 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] em28xx device mode detection based on endpoints
Hello Devin, On Mon, 1 Jun 2009 11:19:22 -0400 Devin Heitmueller dheitmuel...@kernellabs.com wrote: On Sat, May 23, 2009 at 11:05 AM, Markus Rechberger mrechber...@gmail.com wrote: Hi, On Sat, May 23, 2009 at 4:49 PM, Markus Rechberger mrechber...@gmail.com wrote: On Sat, May 23, 2009 at 4:04 PM, Markus Rechberger mrechber...@gmail.com wrote: Hi, for em28xx devices the device node detection can be based on the encoded endpoint address, for example EP 0x81 (USB IN, Interrupt), 0x82 (analog video EP), 0x83 (analog audio ep), 0x84 (mpeg-ts input EP). It is not necessary that digital TV devices have a frontend, the em28xx chip only specifies an MPEG-TS input EP. Following patch adds a check based on the Endpoints, although it might be extended that all devices match the possible devicenodes based on the endpoints, currently the driver registers an analog TV node by default for all unknown devices which is not necessarily correct, this patch disables the ATV node if no analog TV endpoint is available. attached patch fixes the deregistration, as well loads the em28xx-dvb module automatically as soon as an MPEG-TS endpoint was found. Signed-off-by: Markus Rechberger mrechber...@gmail.com best regards, Markus Hello Markus, I spent some time reviewing this patch, and the patch's content does not seem to match your description of its functionality. Further, this patch appears to be a combination of a number of several different changes, rather than being broken into separate patches. First off, I totally agree that the analog subsystem should not be loaded on devices such as em287[0-4]. I was going to do this work (using the chip id to determine analog support) but just had not had a chance to doing the necessary testing to ensure it did not break anything. The patch appears to be primarily for devices that are not supported in the kernel. In fact, the logic as written *only* gets used for unknown devices. Further, the code that doesn't create the frontend device has no application in the kernel. All devices currently in the kernel make use of the dvb frontend interface, so there is no practical application to loading the driver and setting up the isoc handlers but blocking access to the dvb frontend device. Aside from the code that selectively disables analog support, the patch only seems to advance compatibility with your userland em28xx framework while providing no benefit to the in-kernel driver. Regarding the possibility of custom firmware, we currently do not have any devices in the in-kernel driver that make use of custom firmware. If you could tell me how to check for custom firmware versus the default vendor firmware, I could potentially do a patch that uses the vendor registers unless custom firmware is installed, at which point we could have custom logic (such as using the endpoint definition). However, given there are no such devices in-kernel, this is not a high priority as far as I am concerned. For what it's worth, I did add an additional patch to allow the user to disable the 480Mbps check via a modprobe option (to avoid a regression for any of your existing customers), and I will be checking in the code to properly compute the isoc size for em2874/em2884 based on the vendor registers (even though there are currently no supported devices in the kernel that require it currently). However, I do not believe the patch you have proposed is appropriate for inclusion in the mainline kernel. Agree with you Devin. Also, the patch does a lot of changes instead of break it in several patches. Cheers, Douglas -- 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] em28xx device mode detection based on endpoints
On Mon, Jun 1, 2009 at 6:04 PM, Douglas Schilling Landgraf dougsl...@gmail.com wrote: Hello Devin, On Mon, 1 Jun 2009 11:19:22 -0400 Devin Heitmueller dheitmuel...@kernellabs.com wrote: On Sat, May 23, 2009 at 11:05 AM, Markus Rechberger mrechber...@gmail.com wrote: Hi, On Sat, May 23, 2009 at 4:49 PM, Markus Rechberger mrechber...@gmail.com wrote: On Sat, May 23, 2009 at 4:04 PM, Markus Rechberger mrechber...@gmail.com wrote: Hi, for em28xx devices the device node detection can be based on the encoded endpoint address, for example EP 0x81 (USB IN, Interrupt), 0x82 (analog video EP), 0x83 (analog audio ep), 0x84 (mpeg-ts input EP). It is not necessary that digital TV devices have a frontend, the em28xx chip only specifies an MPEG-TS input EP. Following patch adds a check based on the Endpoints, although it might be extended that all devices match the possible devicenodes based on the endpoints, currently the driver registers an analog TV node by default for all unknown devices which is not necessarily correct, this patch disables the ATV node if no analog TV endpoint is available. attached patch fixes the deregistration, as well loads the em28xx-dvb module automatically as soon as an MPEG-TS endpoint was found. Signed-off-by: Markus Rechberger mrechber...@gmail.com best regards, Markus Hello Markus, I spent some time reviewing this patch, and the patch's content does not seem to match your description of its functionality. Further, this patch appears to be a combination of a number of several different changes, rather than being broken into separate patches. First off, I totally agree that the analog subsystem should not be loaded on devices such as em287[0-4]. I was going to do this work (using the chip id to determine analog support) but just had not had a chance to doing the necessary testing to ensure it did not break anything. The patch appears to be primarily for devices that are not supported in the kernel. In fact, the logic as written *only* gets used for unknown devices. Further, the code that doesn't create the frontend device has no application in the kernel. All devices currently in the kernel make use of the dvb frontend interface, so there is no practical application to loading the driver and setting up the isoc handlers but blocking access to the dvb frontend device. Aside from the code that selectively disables analog support, the patch only seems to advance compatibility with your userland em28xx framework while providing no benefit to the in-kernel driver. Regarding the possibility of custom firmware, we currently do not have any devices in the in-kernel driver that make use of custom firmware. If you could tell me how to check for custom firmware versus the default vendor firmware, I could potentially do a patch that uses the vendor registers unless custom firmware is installed, at which point we could have custom logic (such as using the endpoint definition). However, given there are no such devices in-kernel, this is not a high priority as far as I am concerned. For what it's worth, I did add an additional patch to allow the user to disable the 480Mbps check via a modprobe option (to avoid a regression for any of your existing customers), and I will be checking in the code to properly compute the isoc size for em2874/em2884 based on the vendor registers (even though there are currently no supported devices in the kernel that require it currently). However, I do not believe the patch you have proposed is appropriate for inclusion in the mainline kernel. Agree with you Devin. Also, the patch does a lot of changes instead of break it in several patches. do you want smaller patches? regards, Markus -- 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] em28xx device mode detection based on endpoints
Em Mon, 1 Jun 2009 18:07:24 +0200 Markus Rechberger mrechber...@gmail.com escreveu: I spent some time reviewing this patch, and the patch's content does not seem to match your description of its functionality. Further, this patch appears to be a combination of a number of several different changes, rather than being broken into separate patches. First off, I totally agree that the analog subsystem should not be loaded on devices such as em287[0-4]. I was going to do this work (using the chip id to determine analog support) but just had not had a chance to doing the necessary testing to ensure it did not break anything. The patch appears to be primarily for devices that are not supported in the kernel. In fact, the logic as written *only* gets used for unknown devices. Further, the code that doesn't create the frontend device has no application in the kernel. All devices currently in the kernel make use of the dvb frontend interface, so there is no practical application to loading the driver and setting up the isoc handlers but blocking access to the dvb frontend device. Aside from the code that selectively disables analog support, the patch only seems to advance compatibility with your userland em28xx framework while providing no benefit to the in-kernel driver. Regarding the possibility of custom firmware, we currently do not have any devices in the in-kernel driver that make use of custom firmware. If you could tell me how to check for custom firmware versus the default vendor firmware, I could potentially do a patch that uses the vendor registers unless custom firmware is installed, at which point we could have custom logic (such as using the endpoint definition). However, given there are no such devices in-kernel, this is not a high priority as far as I am concerned. For what it's worth, I did add an additional patch to allow the user to disable the 480Mbps check via a modprobe option (to avoid a regression for any of your existing customers), and I will be checking in the code to properly compute the isoc size for em2874/em2884 based on the vendor registers (even though there are currently no supported devices in the kernel that require it currently). However, I do not believe the patch you have proposed is appropriate for inclusion in the mainline kernel. Agree with you Devin. Also, the patch does a lot of changes instead of break it in several patches. do you want smaller patches? Markus, Please break it into smaller patches, being one patch per change. This makes easier for me to review and for people to comment each one of the addressed issues. 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: New Driver for DaVinci DM355/DM365/DM6446
Em Mon, 1 Jun 2009 09:56:40 -0500 Paulraj, Sandeep s-paul...@ti.com escreveu: Hello, WE have a module(H3A) on Davinci DM6446,DM355 and DM365. Customers require a way to collect the data required to perform the Auto Exposure (AE), Auto Focus(AF), and Auto White balance (AWB) in hardware as opposed to software. This is primarily for performance reasons as there is not enough software processing MIPS (to do 3A statistics) available in an imaging/video system. Including this block in hardware reduces the load on the processor and bandwidth to the memory as the data is collected on the fly from the imager. This modules collects statistics and we currently implement it as a character driver. Which mailing list would be the most appropriate mailing list to submit patches for review? You should send they to: LMML linux-media@vger.kernel.org If you are proposing API changes, please submit they first. Thanks, Sandeep -- 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 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: New Driver for DaVinci DM355/DM365/DM6446
-Original Message- From: Mauro Carvalho Chehab [mailto:mche...@infradead.org] Sent: Monday, June 01, 2009 12:35 PM To: Paulraj, Sandeep Cc: linux-media@vger.kernel.org; linux-ker...@vger.kernel.org; Grosen, Mark Subject: Re: New Driver for DaVinci DM355/DM365/DM6446 Em Mon, 1 Jun 2009 09:56:40 -0500 Paulraj, Sandeep s-paul...@ti.com escreveu: Hello, WE have a module(H3A) on Davinci DM6446,DM355 and DM365. Customers require a way to collect the data required to perform the Auto Exposure (AE), Auto Focus(AF), and Auto White balance (AWB) in hardware as opposed to software. This is primarily for performance reasons as there is not enough software processing MIPS (to do 3A statistics) available in an imaging/video system. Including this block in hardware reduces the load on the processor and bandwidth to the memory as the data is collected on the fly from the imager. This modules collects statistics and we currently implement it as a character driver. Which mailing list would be the most appropriate mailing list to submit patches for review? You should send they to: LMML linux-media@vger.kernel.org If you are proposing API changes, please submit they first. [Sandeep] WE don't propose any API changes. This module for which we want to submit patches is a TI proprietary IP. We currently implement this as a character device and have a few IOCTL's. We do not follow the V4L2 framework and do not use any V4L2 IOCTLs. Can we continue to use it as a character driver? Thanks, Sandeep -- 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 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: New Driver for DaVinci DM355/DM365/DM6446
Em Mon, 1 Jun 2009 11:54:37 -0500 Paulraj, Sandeep s-paul...@ti.com escreveu: -Original Message- From: Mauro Carvalho Chehab [mailto:mche...@infradead.org] Sent: Monday, June 01, 2009 12:35 PM To: Paulraj, Sandeep Cc: linux-media@vger.kernel.org; linux-ker...@vger.kernel.org; Grosen, Mark Subject: Re: New Driver for DaVinci DM355/DM365/DM6446 Em Mon, 1 Jun 2009 09:56:40 -0500 Paulraj, Sandeep s-paul...@ti.com escreveu: Hello, WE have a module(H3A) on Davinci DM6446,DM355 and DM365. Customers require a way to collect the data required to perform the Auto Exposure (AE), Auto Focus(AF), and Auto White balance (AWB) in hardware as opposed to software. This is primarily for performance reasons as there is not enough software processing MIPS (to do 3A statistics) available in an imaging/video system. Including this block in hardware reduces the load on the processor and bandwidth to the memory as the data is collected on the fly from the imager. This modules collects statistics and we currently implement it as a character driver. Which mailing list would be the most appropriate mailing list to submit patches for review? You should send they to: LMML linux-media@vger.kernel.org If you are proposing API changes, please submit they first. [Sandeep] WE don't propose any API changes. This module for which we want to submit patches is a TI proprietary IP. We currently implement this as a character device and have a few IOCTL's. We do not follow the V4L2 framework and do not use any V4L2 IOCTLs. Can we continue to use it as a character driver? In this case, I don't see why you want it to be upstream. 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
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Mon Jun 1 19:00:06 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 11918:e6a8672631a0 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: WARNINGS linux-2.6.28-armv5: WARNINGS linux-2.6.29.1-armv5: OK linux-2.6.30-rc7-armv5: OK linux-2.6.27-armv5-ixp: WARNINGS linux-2.6.28-armv5-ixp: WARNINGS linux-2.6.29.1-armv5-ixp: WARNINGS linux-2.6.30-rc7-armv5-ixp: WARNINGS linux-2.6.28-armv5-omap2: WARNINGS linux-2.6.29.1-armv5-omap2: WARNINGS linux-2.6.30-rc7-armv5-omap2: WARNINGS linux-2.6.22.19-i686: WARNINGS linux-2.6.23.12-i686: WARNINGS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.11-i686: WARNINGS linux-2.6.26-i686: WARNINGS linux-2.6.27-i686: WARNINGS linux-2.6.28-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30-rc7-i686: WARNINGS linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29.1-m32r: OK linux-2.6.30-rc7-m32r: OK linux-2.6.22.19-mips: ERRORS linux-2.6.26-mips: ERRORS linux-2.6.27-mips: ERRORS linux-2.6.28-mips: ERRORS linux-2.6.29.1-mips: ERRORS linux-2.6.30-rc7-mips: ERRORS linux-2.6.27-powerpc64: WARNINGS linux-2.6.28-powerpc64: WARNINGS linux-2.6.29.1-powerpc64: WARNINGS linux-2.6.30-rc7-powerpc64: WARNINGS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.12-x86_64: WARNINGS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.11-x86_64: WARNINGS linux-2.6.26-x86_64: WARNINGS linux-2.6.27-x86_64: WARNINGS linux-2.6.28-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-rc7-x86_64: WARNINGS sparse (linux-2.6.29.1): OK sparse (linux-2.6.30-rc7): OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS 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: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS 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/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2 The V4L2 specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- 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: New Driver for DaVinci DM355/DM365/DM6446
From: linux-media-ow...@vger.kernel.org [linux-media-ow...@vger.kernel.org] On Behalf Of Paulraj, Sandeep Sent: Monday, June 01, 2009 5:56 PM To: linux-media@vger.kernel.org Cc: linux-ker...@vger.kernel.org; Grosen, Mark Subject: New Driver for DaVinci DM355/DM365/DM6446 Hello, WE have a module(H3A) on Davinci DM6446,DM355 and DM365. Customers require a way to collect the data required to perform the Auto Exposure (AE), Auto Focus(AF), and Auto White balance (AWB) in hardware as opposed to software. This is primarily for performance reasons as there is not enough software processing MIPS (to do 3A statistics) available in an imaging/video system. Including this block in hardware reduces the load on the processor and bandwidth to the memory as the data is collected on the fly from the imager. This modules collects statistics and we currently implement it as a character driver. This also exists in OMAP3 chips, and is part of the ISP module. I maintain, along with Sakari Ailus, a V4L2 camera driver, which is currently just shared through a gitorious repository: http://gitorious.org/omap3camera The way we offer an interface for the user to be able to request this statistics is with the usage of private IOCTLs declared inside the same V4L2 capturing device driver. So, that way we have a V4L2 driver which has a private call, instead of having it separately from the capture driver. Regards, Sergio Which mailing list would be the most appropriate mailing list to submit patches for review? Thanks, Sandeep -- 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: New Driver for DaVinci DM355/DM365/DM6446
Mauro, Please see inline -Original Message- From: Mauro Carvalho Chehab [mailto:mche...@infradead.org] Sent: Monday, June 01, 2009 1:57 PM To: Paulraj, Sandeep Cc: linux-media@vger.kernel.org; linux-ker...@vger.kernel.org; Grosen, Mark Subject: Re: New Driver for DaVinci DM355/DM365/DM6446 Em Mon, 1 Jun 2009 11:54:37 -0500 Paulraj, Sandeep s-paul...@ti.com escreveu: -Original Message- From: Mauro Carvalho Chehab [mailto:mche...@infradead.org] Sent: Monday, June 01, 2009 12:35 PM To: Paulraj, Sandeep Cc: linux-media@vger.kernel.org; linux-ker...@vger.kernel.org; Grosen, Mark Subject: Re: New Driver for DaVinci DM355/DM365/DM6446 Em Mon, 1 Jun 2009 09:56:40 -0500 Paulraj, Sandeep s-paul...@ti.com escreveu: Hello, WE have a module(H3A) on Davinci DM6446,DM355 and DM365. Customers require a way to collect the data required to perform the Auto Exposure (AE), Auto Focus(AF), and Auto White balance (AWB) in hardware as opposed to software. This is primarily for performance reasons as there is not enough software processing MIPS (to do 3A statistics) available in an imaging/video system. Including this block in hardware reduces the load on the processor and bandwidth to the memory as the data is collected on the fly from the imager. This modules collects statistics and we currently implement it as a character driver. Which mailing list would be the most appropriate mailing list to submit patches for review? You should send they to: LMML linux-media@vger.kernel.org If you are proposing API changes, please submit they first. [Sandeep] WE don't propose any API changes. This module for which we want to submit patches is a TI proprietary IP. We currently implement this as a character device and have a few IOCTL's. We do not follow the V4L2 framework and do not use any V4L2 IOCTLs. Can we continue to use it as a character driver? In this case, I don't see why you want it to be upstream. [Sandeep] TI customers and TI itself want to see this driver part of open source trees. Considering this we would like to submit our patches to the linux-media mailing list. IS this OK? 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: New Driver for DaVinci DM355/DM365/DM6446
Sergio, Is it part of the patches Vaibhav others from TI are submitting to open source ? I know that there is an ongoing effort at TI India to submit the resizer driver to open source for OMAP3? As per the email exchanges I had with Vaibhav (TI India) on this, it is part of the ISP module. We plan to submit the patches to open source for H3A and was trying to see which is the right way to do it. We will investigate the tree you mentioned below and let you know if we have additional questions. The plan is to align with OMAP3 for the implementation. regards, Murali Karicheri email: m-kariche...@ti.com -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Aguirre Rodriguez, Sergio Alberto Sent: Monday, June 01, 2009 2:39 PM To: Paulraj, Sandeep; linux-media@vger.kernel.org Cc: linux-ker...@vger.kernel.org; Grosen, Mark Subject: RE: New Driver for DaVinci DM355/DM365/DM6446 From: linux-media-ow...@vger.kernel.org [linux-media- ow...@vger.kernel.org] On Behalf Of Paulraj, Sandeep Sent: Monday, June 01, 2009 5:56 PM To: linux-media@vger.kernel.org Cc: linux-ker...@vger.kernel.org; Grosen, Mark Subject: New Driver for DaVinci DM355/DM365/DM6446 Hello, WE have a module(H3A) on Davinci DM6446,DM355 and DM365. Customers require a way to collect the data required to perform the Auto Exposure (AE), Auto Focus(AF), and Auto White balance (AWB) in hardware as opposed to software. This is primarily for performance reasons as there is not enough software processing MIPS (to do 3A statistics) available in an imaging/video system. Including this block in hardware reduces the load on the processor and bandwidth to the memory as the data is collected on the fly from the imager. This modules collects statistics and we currently implement it as a character driver. This also exists in OMAP3 chips, and is part of the ISP module. I maintain, along with Sakari Ailus, a V4L2 camera driver, which is currently just shared through a gitorious repository: http://gitorious.org/omap3camera The way we offer an interface for the user to be able to request this statistics is with the usage of private IOCTLs declared inside the same V4L2 capturing device driver. So, that way we have a V4L2 driver which has a private call, instead of having it separately from the capture driver. Regards, Sergio Which mailing list would be the most appropriate mailing list to submit patches for review? Thanks, Sandeep -- 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: New Driver for DaVinci DM355/DM365/DM6446
Em Mon, 1 Jun 2009 13:39:17 -0500 Paulraj, Sandeep s-paul...@ti.com escreveu: [Sandeep] WE don't propose any API changes. This module for which we want to submit patches is a TI proprietary IP. We currently implement this as a character device and have a few IOCTL's. We do not follow the V4L2 framework and do not use any V4L2 IOCTLs. Can we continue to use it as a character driver? In this case, I don't see why you want it to be upstream. [Sandeep] TI customers and TI itself want to see this driver part of open source trees. Considering this we would like to submit our patches to the linux-media mailing list. IS this OK? If you're just providing a character API with some protocol protected by IP, you're not providing the source code of the driver, but something else. It is not ok to provide such driver. Also, even if you disclosure your protocol, it makes no sense to create another API for userspace communication, for features that already exists or can easily expand to accommodate your needs. So, you should really use the V4L2 API for the driver, expanding it where required, if you want it to be considered for upstream addition. 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: New Driver for DaVinci DM355/DM365/DM6446
Em Mon, 1 Jun 2009 13:38:37 -0500 Aguirre Rodriguez, Sergio Alberto saagui...@ti.com escreveu: From: linux-media-ow...@vger.kernel.org [linux-media-ow...@vger.kernel.org] On Behalf Of Paulraj, Sandeep Sent: Monday, June 01, 2009 5:56 PM To: linux-media@vger.kernel.org Cc: linux-ker...@vger.kernel.org; Grosen, Mark Subject: New Driver for DaVinci DM355/DM365/DM6446 Hello, WE have a module(H3A) on Davinci DM6446,DM355 and DM365. Customers require a way to collect the data required to perform the Auto Exposure (AE), Auto Focus(AF), and Auto White balance (AWB) in hardware as opposed to software. This is primarily for performance reasons as there is not enough software processing MIPS (to do 3A statistics) available in an imaging/video system. Including this block in hardware reduces the load on the processor and bandwidth to the memory as the data is collected on the fly from the imager. This modules collects statistics and we currently implement it as a character driver. This also exists in OMAP3 chips, and is part of the ISP module. I maintain, along with Sakari Ailus, a V4L2 camera driver, which is currently just shared through a gitorious repository: http://gitorious.org/omap3camera The way we offer an interface for the user to be able to request this statistics is with the usage of private IOCTLs declared inside the same V4L2 capturing device driver. So, that way we have a V4L2 driver which has a private call, instead of having it separately from the capture driver. This seems to be a much better approach, provided that the private IOCTL's will be properly documented on a public document. If there are enough usage for they, we may even add them as an optional part of V4L2 API. 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: New Driver for DaVinci DM355/DM365/DM6446
From: Karicheri, Muralidharan Sent: Monday, June 01, 2009 9:58 PM To: Aguirre Rodriguez, Sergio Alberto; Paulraj, Sandeep; linux-media@vger.kernel.org Cc: linux-ker...@vger.kernel.org; Grosen, Mark Subject: RE: New Driver for DaVinci DM355/DM365/DM6446 Sergio, Is it part of the patches Vaibhav others from TI are submitting to open source ? Yes, currently I have been sharing this codebase with Vaibhav, which he is taking for the 3530 EVM, which uses the camera ISP to receive images from a video decoder using a parallel BT656 output. I know that there is an ongoing effort at TI India to submit the resizer driver to open source for OMAP3? I guess this is still on hold, as the current internal approach is not acceptable in the V4L2 standards. As per the email exchanges I had with Vaibhav (TI India) on this, it is part of the ISP module. That's correct. We plan to submit the patches to open source for H3A and was trying to see which is the right way to do it. The ISP driver core that we are sharing, it already has the H3A driver on it, which is accessed through Private IOCTLs declared inside the driver. We will investigate the tree you mentioned below and let you know if we have additional questions. Vaibhav should be already familiar with this codebase, so maybe it could be easier for you to talk with him about this. The plan is to align with OMAP3 for the implementation. Although the current code maintenance is on hold because i've been busy with some other custormer requirements, i havent been able to continue working on the pending TODOs so far. But as this strategy on a better collaboration with the community is attempted, i'm trying ot find my way to get back wit hthe maintenance of this driver to meet at least the required changes for acceptance of the driver. It'll be definitively good to align on this, so we can avoid rewriting the same thing over again. Regards, Sergio regards, Murali Karicheri email: m-kariche...@ti.com -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Aguirre Rodriguez, Sergio Alberto Sent: Monday, June 01, 2009 2:39 PM To: Paulraj, Sandeep; linux-media@vger.kernel.org Cc: linux-ker...@vger.kernel.org; Grosen, Mark Subject: RE: New Driver for DaVinci DM355/DM365/DM6446 From: linux-media-ow...@vger.kernel.org [linux-media- ow...@vger.kernel.org] On Behalf Of Paulraj, Sandeep Sent: Monday, June 01, 2009 5:56 PM To: linux-media@vger.kernel.org Cc: linux-ker...@vger.kernel.org; Grosen, Mark Subject: New Driver for DaVinci DM355/DM365/DM6446 Hello, WE have a module(H3A) on Davinci DM6446,DM355 and DM365. Customers require a way to collect the data required to perform the Auto Exposure (AE), Auto Focus(AF), and Auto White balance (AWB) in hardware as opposed to software. This is primarily for performance reasons as there is not enough software processing MIPS (to do 3A statistics) available in an imaging/video system. Including this block in hardware reduces the load on the processor and bandwidth to the memory as the data is collected on the fly from the imager. This modules collects statistics and we currently implement it as a character driver. This also exists in OMAP3 chips, and is part of the ISP module. I maintain, along with Sakari Ailus, a V4L2 camera driver, which is currently just shared through a gitorious repository: http://gitorious.org/omap3camera The way we offer an interface for the user to be able to request this statistics is with the usage of private IOCTLs declared inside the same V4L2 capturing device driver. So, that way we have a V4L2 driver which has a private call, instead of having it separately from the capture driver. Regards, Sergio Which mailing list would be the most appropriate mailing list to submit patches for review? Thanks, Sandeep -- 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: [PULL] http://udev.netup.ru/hg/v4l-dvb-aospan
Em Mon, 01 Jun 2009 17:42:24 +0400 Abylai Ospan aos...@netup.ru escreveu: В Пнд, 01/06/2009 в 06:38 -0300, Mauro Carvalho Chehab пишет: Please check your patch against kernel codingstyle with checkpatch.pl. There are some CodingStyle violations here and on the code bellow. Please pull new changes - http://udev.netup.ru/hg/v4l-dvb-aospan/rev/0d3e6c0695cc 1. checkpatch.pl don't show warnings/errors ( except printk line length ). 2. cnt_storage array dinamically allocated before doing checks. We can't allocate it in dvb_dmx_init routine because module option dvb_demux_tscheck can be enabled on running system ( not in module startup only ). Ok, we're close to a final version. TS continuity check: show error message when discontinuity detected or TEI flag detected in header Signed-off-by: Abylay Ospan aos...@netup.ru --- a/linux/drivers/media/dvb/dvb-core/dvb_demux.cMon Jun 01 05:22:37 2009 -0300 +++ b/linux/drivers/media/dvb/dvb-core/dvb_demux.cMon Jun 01 17:36:33 2009 +0400 @@ -37,6 +37,15 @@ ** #define DVB_DEMUX_SECTION_LOSS_LOG to monitor payload loss in the syslog */ // #define DVB_DEMUX_SECTION_LOSS_LOG + +static int dvb_demux_tscheck; +module_param(dvb_demux_tscheck, int, 0644); +MODULE_PARM_DESC(dvb_demux_tscheck, \ + enable transport stream continuity and TEI check); Please remove the backslash on the above line. Just do: MODULE_PARM_DESC(dvb_demux_tscheck, enable transport stream continuity and TEI check); + +#define dprintk_tscheck(x...) do { \ + if (dvb_demux_tscheck printk_ratelimit()) printk(x); } while (0) checkpatch.pl is not perfect. The better is to break the macro as I've shown on my previous email, breaking one statement per line: #define dprintk_tscheck(x...) do { \ if (dvb_demux_tscheck printk_ratelimit())\ printk(x); \ } while (0) This allows a faster reading of the line. PS.: The defines are the only places at the source code where the backslashes are needed. + /** * static inlined helper functions @@ -375,6 +384,29 @@ struct dvb_demux_feed *feed; u16 pid = ts_pid(buf); int dvr_done = 0; + No need for an empty line here. Please remove to keep all vars together. + int cnt_pid; unsigned cnt_pid; + + if (dvb_demux_tscheck) { + No need for an empty line here. + if (!demux-cnt_storage) + demux-cnt_storage = vmalloc(0x1fff); Please add a define for 0x1fff and use the define, instead of using a magic value at vmalloc, like: #define MAX_PID 0x1ffe ... if (!demux-cnt_storage) demux-cnt_storage = vmalloc(MAX_PID + 1); You need to add a check to see if the vmalloc really worked. Also, if you don't have memory for the first packet, it doesn't make sense to keep insisting on allocating memory. Better just to disable the check. So, I would code it like: if (!demux-cnt_storage) { WARN(Couldn't allocate memory for TS/TEI check. Disabling it\n); dvb_demux_tscheck = 0; goto no_dvb_demux_tscheck; } + + /* check pkt counter */ + cnt_pid = ((buf[1] 0x1f)8) | buf[2]; + + if (cnt_pid != 0x1fff) { if (cnt_pid = MAX_PID) { This will make clear that there's no chance of writing outside the array limit, after changing cnt_pid to unsigned. + if (buf[1] 0x80) + dprintk_tscheck(TEI detected. PID=0x%x data1=0x%x\n, cnt_pid, buf[1]); + + if ((buf[3] 0xf) != demux-cnt_storage[cnt_pid]) + dprintk_tscheck(TS packet counter mismatch. PID=0x%x expected 0x%x got 0x%x\n,\ + cnt_pid, demux-cnt_storage[cnt_pid], buf[3] 0xf); Please, don't add the backslash. Also, in order to have it 80-line compliant, you could break the strings as: dprintk_tscheck(TS packet counter mismatch. PID=0x%x expected 0x%x got 0x%x\n, cnt_pid, demux-cnt_storage[cnt_pid], buf[3] 0xf); + + demux-cnt_storage[cnt_pid] = ((buf[3] 0xf) + 1)0xf; + }; + /* end check */ + }; In order to work with the lack of memory, you'll need a label here: no_dvb_demux_tscheck: Another alternative would be to convert the debug logic into a static function. The source code will look cleaner, and the gcc optimizer will tranform it into inline and produce the same binary. Something like: if (demux-cnt_storage)
Re: Terratec DT USB XS Diversity/DiB0070+vdr: URB status: Value too large for defined data type+USB reset
Hi folks. Sorry but I'm unable to reply to my previous message, because I just don't have this message. Now I'm registered to both lists... I played a little bit with my problem and tried the latest source from the repository, but EOVERFLOW still occurs seconds after starting vdr. I activated the debug options of all, I hope, relevant modules now and got a more detailed kern.log. Maybe some expert can help me and take look at it. Interesting section: Jun 1 23:16:14 vdr kernel: function : dvb_dvr_poll Jun 1 23:16:14 vdr kernel: function : dvb_dvr_poll Jun 1 23:16:14 vdr kernel: function : dvb_dvr_poll Jun 1 23:16:14 vdr kernel: dmxdev: section callback 4e f2 6c 40 0a e7 Jun 1 23:16:14 vdr kernel: dmxdev: section callback 50 f2 55 40 13 e1 Jun 1 23:16:14 vdr kernel: dmxdev: section callback 00 b0 1d 03 01 d1 Jun 1 23:16:14 vdr kernel: stop pid: 0x00a0, feedtype: 1 Jun 1 23:16:14 vdr kernel: setting pid (no): 160 00a0 at index 7 'off' Jun 1 23:16:14 vdr kernel: function : dvb_dmxdev_filter_set Jun 1 23:16:14 vdr kernel: start pid: 0x00e0, feedtype: 1 Jun 1 23:16:14 vdr kernel: setting pid (no): 224 00e0 at index 7 'on' Jun 1 23:16:14 vdr kernel: function : dvb_dvr_poll Jun 1 23:16:14 vdr kernel: function : dvb_dvr_poll BOOM - Jun 1 23:16:14 vdr kernel: urb completition error -75. The whole logfile is available here: http://www.retrodesignfan.eu/dvb/dib0700-usb-hangup.log Greetings, Marco Borm Marco Borm wrote: Hi folks, yesterday I bought a Terratec Cinergy DT USB XS Diversity and the device works just plugplay and without problems under Windows AND linux mplayer+ tzap but resets the whole USB bus very shortly after I starting vdr. I don't think this has something to do with vdr itself, so I posting here. My configuration is Debian on testing, kernel is 2.6.29-4.slh.1-sidux-686, DVB drivers aren't self compiled, vdr is (1.6.0-2/1.6.0), device info: ID 0ccd:0081 TerraTec Electronic GmbH. log entries: Jun 1 01:14:47 vdr kernel: dib0700: loaded with support for 8 different device-types Jun 1 01:14:47 vdr kernel: dvb-usb: found a 'Terratec Cinergy DT USB XS Diversity' in warm state. Jun 1 01:14:47 vdr kernel: dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. Jun 1 01:14:47 vdr kernel: DVB: registering new adapter (Terratec Cinergy DT USB XS Diversity) Jun 1 01:14:47 vdr kernel: DVB: registering adapter 1 frontend 0 (DiBcom 7000PC)... Jun 1 01:14:47 vdr kernel: DiB0070: successfully identified Jun 1 01:14:47 vdr kernel: dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. Jun 1 01:14:47 vdr kernel: DVB: registering new adapter (Terratec Cinergy DT USB XS Diversity) Jun 1 01:14:47 vdr kernel: DVB: registering adapter 2 frontend 0 (DiBcom 7000PC)... Jun 1 01:14:47 vdr kernel: DiB0070: successfully identified Jun 1 01:14:47 vdr kernel: dvb-usb: Terratec Cinergy DT USB XS Diversity successfully initialized and connected. Jun 1 01:14:47 vdr kernel: usbcore: registered new interface driver dvb_usb_dib0700 vdr start - Jun 1 01:16:24 vdr logger: runvdr get_modulenames: dvb_usb#012videobuf_dvb#012cx88_dvb dvb_core USB reset - Jun 1 01:18:00 vdr kernel: usb 1-2: USB disconnect, [... all devices reconnecting to the bus ] Jun 1 01:18:28 vdr kernel: DiB0070 I2C write failed Jun 1 01:18:28 vdr kernel: DiB0070 I2C read failed Jun 1 01:18:28 vdr kernel: DiB0070 I2C write failed Jun 1 01:18:28 vdr kernel: DiB0070 I2C write failed Jun 1 01:18:28 vdr kernel: DiB0070 I2C write failed [...] This logs aren't very helpful, but I find something interesting with Wireshark and usbmon: device - host URB type: URB_COMPLETE ('C') URB transfer type: URB_BULK (3) Endpoint: 0x83 Device: 13 Data: present (0) URB status: Value too large for defined data type (-EOVERFLOW) (-75) URB length [bytes]: 39424 Data length [bytes]: 39424 after this URB I get a URB transfer type: URB_INTERRUPT (1) and all goes to hell. Its also interesting that the URB+data length in the failure package is 39424 but URB length [bytes]: 39480 in every package before that. As I know this device works without problems under linux for other people, so I'm wondering why. I searched but found nothing about such a problem. The wireshark capturefile is downloadable here: http://rapidshare.com/files/239429647/terratec-xs-usb-overflow.html Thanks for hints, Marco Borm -- 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] Leadtek WinFast DTV-1800H support
Am Montag, den 01.06.2009, 06:07 -0300 schrieb Mauro Carvalho Chehab: Em Mon, 01 Jun 2009 03:58:25 +0200 hermann pitton hermann-pit...@arcor.de escreveu: Am Sonntag, den 31.05.2009, 16:58 -0300 schrieb Mauro Carvalho Chehab: Em Sun, 31 May 2009 19:39:15 +0200 Miroslav Šustek sustmid...@centrum.cz escreveu: Trent Piepho xyzzy at speakeasy.org writes: Instead of raising the reset line here, why not change the gpio settings in the card definition to have it high? Change gpio1 for television to 0x7050 and radio to 0x7010. Personally, I don't know when these .gpioX members are used (before firmware loads or after...). But I assume that adding the high on reset pin shouldn't break anything, so we can do this. And shouldn't we put tuner reset pin to 0 when in composite and s-video mode? These inputs don't use tuner or do they? If I look in dmesg I can see that firmware is loaded into tuner even when these modes are used (I'm using MPlayer to select the input). And due to callbacks issued duting firmware loading, tuner is turned on (reset pin = 1) no matter if it was turned off by .gpioX setting. And shouldn't we use the mask bits [24:16] of MO_GPX_IO in .gpioX members too? I know only few GPIO pins and the other I don't know either what direction they should be. That means GPIO pins which I don't know are set as Hi-Z = inputs... Now, when I think of that, if it works it's safer when the other pins are in Hi-Z mode. Never mind. Then the reset can be done with: case XC2028_TUNER_RESET: /* GPIO 12 (xc3028 tuner reset) */ cx_write(MO_GP1_IO, 0x101000); mdelay(50); cx_write(MO_GP1_IO, 0x101010); mdelay(50); return 0; Earlier I was told to use 'cx_set' and 'cx_clear' because using 'cx_write' is risky. see here: http://www.spinics.net/lists/linux-dvb/msg29777.html And when you are using 'cx_set' and 'cx_clear' you need 3 calls. The first to set the direction bit, the second to set 0 on reset pin and the third to set 1 on reset pin. If you ask me which I think is nicer I'll tell you: that one with 'cx_write'. If you ask me which one I want to use, I'll tell: I don't care. :) Though I have to wonder why each card needs its own xc2028 reset function. Shouldn't they all be the same other than what gpio they change? My English goes lame here. Do you mean that reset function shouldn't use GPIO at all? @@ -2882,6 +2946,16 @@ cx_set(MO_GP0_IO, 0x0080); /* 702 out of reset */ udelay(1000); break; + + case CX88_BOARD_WINFAST_DTV1800H: + /* GPIO 12 (xc3028 tuner reset) */ + cx_set(MO_GP1_IO, 0x1010); + mdelay(50); + cx_clear(MO_GP1_IO, 0x10); + mdelay(50); + cx_set(MO_GP1_IO, 0x10); + mdelay(50); + break; } } Couldn't you replace this with: case CX88_BOARD_WINFAST_DTV1800H: cx88_xc3028_winfast1800h_callback(code, XC2028_TUNER_RESET, 0); break; Yes, this will do the same job. I think that 'cx88_card_setup_pre_i2c' is to be called before any I2C communication. The 'cx88_xc3028_winfast1800h_callback' (cx88_tuner_callback) is meant to be used when tuner code (during firmware loading) needs it. This is probably why others did it this way (these are separated issues even if they do the same thing) and I only obey existing form. I only want to finally add the support for this card. You know many people (not developers) don't care if this function is used or that function is used twice, instead. They just want to install they distro and watch the tv. I classify myself as an programmer rather than ordinary user, so I care how the code looks like. I'm open to the discussion about these things, but this can take long time and I just want the card to be supported asap. There are more cards which has code like this so if linuxtv developers realize eg. to not use callbacks or use only cx_set and cx_clear (instead of cx_write) they'll do it all at once (not every card separately). I attached modified patch: - .gpioX members of inputs which use tuner have reset pin 1 (tuner enabled) - .gpioX members of inputs which don't use tuner have reset pin 0 (tuner disabled) - resets (in callback and the one in pre_i2c) use only two 'cx_write' calls I'm keeping the tested-by lines even if this modified version of patch wasn't tested by those people (the previous version was). I trust this changes can't break the functionality. If you think it's too audacious then drop them. It's on linuxtv developers which of these two patches will be chosen. For the sake of not loosing this patch again, I've
Re: Wiki software update
Hi Johannes, Am Montag, den 01.06.2009, 13:41 +0200 schrieb Johannes Stezenbach: Hi Hermann, On Mon, Jun 01, 2009 at 02:08:07AM +0200, hermann pitton wrote: Am Montag, den 01.06.2009, 01:28 +0200 schrieb Johannes Stezenbach: I just updated the V4L-DVB Wiki and the old V4L Wiki to MediaWiki-1.14.0. Please let me know in case something broke. did not test all links, but on this one some older issues seem to still perpetuate. http://www.linuxtv.org/wiki/index.php?title=How_to_Perform_a_Bisectaction=edit I get, that I'm not allowed to do that. Well, you need to be logged in to create or edit pages. Or are you saying that you cannot edit this page even though you are logged in? Johannes sorry, my bad. Thought it means also a site on the wiki, but it obviously only tries to provide the external link. Thanks, 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: [PULL] http://udev.netup.ru/hg/v4l-dvb-aospan
Hi, I missed the original mail, so I am replying to this one. See below. @@ -375,6 +384,29 @@ struct dvb_demux_feed *feed; u16 pid = ts_pid(buf); int dvr_done = 0; + No need for an empty line here. Please remove to keep all vars together. +int cnt_pid; unsigned cnt_pid; There's no need for cnt_pid at all, because pid already contains the PID value. Please add a define for 0x1fff and use the define, instead of using a magic value at vmalloc, like: #define MAX_PID 0x1ffe One would assume MAX_PID to be 0x1fff. Maybe it would be better to have two definitions to improve readability. for dvb_dmx_swfilter_packet(): #define NULL_PID 0x1fff for vmalloc: #define MAX_PID 0x1fff or #define NUM_PIDS 0x2000 ... and use (NUM_PIDS - 1) to make clear that no memory for the NULL PID is allocated. Regards, Andreas -- 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: webcam drivers and V4L2_MEMORY_USERPTR support
Hi Stefan, On Monday 01 June 2009 09:26:10 Stefan Kost wrote: hi, I have implemented support for V4L2_MEMORY_USERPTR buffers in gstreamers v4l2src [1]. This allows to request shared memory buffers from xvideo, capture into those and therefore save a memcpy. This works great with the v4l2 driver on our embedded device. When I was testing this on my desktop, I noticed that almost no driver seems to support it. I tested zc0301 and uvcvideo, but also grepped the kernel driver sources. It seems that gspca might support it, but I ave not confirmed it. Is there a technical reason for it, or is it simply not implemented? For the uvcvideo driver it's simply not implemented. I was about to give it a try when I found out a mismatch between the V4L2 specification and the videobuf implementation (which I wanted to use as the reference implementation). The V4L2 specification states, in section 3.3, that The driver must be switched into user pointer I/O mode by calling the VIDIOC_REQBUFS with the desired buffer type. No buffers are allocated beforehands, consequently they are not indexed and cannot be queried like mapped buffers with the VIDIOC_QUERYBUF ioctl. Example 3-2 shows that v4l2_requestbuffers::count is not used when using USERPTR. However, videobuf pre-allocates v4l2_requestbuffers::count kernel-side buffer descriptors when VIDIOC_REQBUFS is called with USERPTR. If someone could clarify which of the V4L2 specification or the videobuf implementation is right I could give USERPTR a try in the uvcvideo driver. Best 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: [hg:v4l-dvb] Fix firmware load for DVB-T @ 6MHz
On Mon, 2009-06-01 at 17:20 +0200, Patch from Mauro Carvalho Chehab wrote: The patch number 11917 was added via Mauro Carvalho Chehab mche...@redhat.com to http://linuxtv.org/hg/v4l-dvb master development tree. Kernel patches in this development tree may be modified to be backward compatible with older kernels. Compatibility modifications will be removed before inclusion into the mainstream Kernel If anyone has any objections, please let us know by sending a message to: Linux Media Mailing List linux-media@vger.kernel.org -- From: Mauro Carvalho Chehab mche...@redhat.com Fix firmware load for DVB-T @ 6MHz bandwidth for xc3028/xc3028L The only two countries that are known to use 6MHz bandwidth are Taiwan and Uruguay. Both use QAM subcarriers at OFTM. This patch fixes the firmware load for such countries, where the required firmware is the QAM one. This also confirms the previous tests where it was noticed that the 6MHz QAM firmware doesn't work for cable. So, this patch also removes support for DVB-C, instead of just printing a warning. Thanks to Terry Wu terrywu2...@gmail.com for pointing this issue and to Andy Walls awa...@radix.net for an initial patch for this fix. Priority: normal CC: Terry Wu terrywu2...@gmail.com CC: Andy Walls awa...@radix.net Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com Acked-by: Andy Walls awa...@radix.net I looks like it accomplishes the 6 MHz DVB-T support in xc2028_set_params() that Terry needed. I personally wouldn't have disabled the FE_QAM stuff. However it doesn't matter as far as current Linux driver use of the XC3028 is concerned - no driver currently sets up the XC3028 with a DVB-C demod. Regards, Andy --- linux/drivers/media/common/tuners/tuner-xc2028.c | 17 +++ 1 file changed, 8 insertions(+), 9 deletions(-) diff -r d55ec37bebfa -r c78c18fe3dc9 linux/drivers/media/common/tuners/tuner-xc2028.c --- a/linux/drivers/media/common/tuners/tuner-xc2028.cMon Jun 01 05:22:37 2009 -0300 +++ b/linux/drivers/media/common/tuners/tuner-xc2028.cMon Jun 01 11:46:08 2009 -0300 @@ -1026,21 +1026,20 @@ static int xc2028_set_params(struct dvb_ switch(fe-ops.info.type) { case FE_OFDM: bw = p-u.ofdm.bandwidth; - break; - case FE_QAM: - tuner_info(WARN: There are some reports that -QAM 6 MHz doesn't work.\n -If this works for you, please report by -e-mail to: v4l-dvb-maintai...@linuxtv.org\n); - bw = BANDWIDTH_6_MHZ; - type |= QAM; + /* + * The only countries with 6MHz seem to be Taiwan/Uruguay. + * Both seem to require QAM firmware for OFDM decoding + * Tested in Taiwan by Terry Wu terrywu2...@gmail.com + */ + if (bw == BANDWIDTH_6_MHZ) + type |= QAM; break; case FE_ATSC: bw = BANDWIDTH_6_MHZ; /* The only ATSC firmware (at least on v2.7) is D2633 */ type |= ATSC | D2633; break; - /* DVB-S is not supported */ + /* DVB-S and pure QAM (FE_QAM) are not supported */ default: return -EINVAL; } --- Patch is available at: http://linuxtv.org/hg/v4l-dvb/rev/c78c18fe3dc9f1338a589130c4eeed14c1d90b44 -- 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: [hg:v4l-dvb] tuner-xc2028: Fix offset frequencies for DVB @ 6MHz
On Mon, 2009-06-01 at 17:20 +0200, Patch from Mauro Carvalho Chehab wrote: The patch number 11918 was added via Mauro Carvalho Chehab mche...@redhat.com to http://linuxtv.org/hg/v4l-dvb master development tree. Kernel patches in this development tree may be modified to be backward compatible with older kernels. Compatibility modifications will be removed before inclusion into the mainstream Kernel If anyone has any objections, please let us know by sending a message to: Linux Media Mailing List linux-media@vger.kernel.org -- From: Mauro Carvalho Chehab mche...@redhat.com tuner-xc2028: Fix offset frequencies for DVB @ 6MHz Both ATSC and DVB @ 6MHz bandwidth require the same offset. While we're fixing it, let's cleanup the bandwidth setup to better reflect the fact that it is a function of the bandwidth. Thanks to Terry Wu terrywu2...@gmail.com for pointing this issue and to Andy Walls awa...@radix.net for an initial patch for this fix. Priority: normal CC: Terry Wu terrywu2...@gmail.com CC: Andy Walls awa...@radix.net Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com Acked-by: Andy Walls awa...@radix.net You may want to emphasize with a comment that 'offset = 0' is used for T_ANALOG_TV. It's somewhat hidden by its initialization early in the function. Italy also appears to use 7 MHz VHF and 8 MHz UHF. Regards, Andy --- linux/drivers/media/common/tuners/tuner-xc2028.c | 32 --- 1 file changed, 19 insertions(+), 13 deletions(-) diff -r c78c18fe3dc9 -r e6a8672631a0 linux/drivers/media/common/tuners/tuner-xc2028.c --- a/linux/drivers/media/common/tuners/tuner-xc2028.cMon Jun 01 11:46:08 2009 -0300 +++ b/linux/drivers/media/common/tuners/tuner-xc2028.cMon Jun 01 12:18:10 2009 -0300 @@ -921,22 +921,28 @@ static int generic_set_freq(struct dvb_f * that xc2028 will be in a safe state. * Maybe this might also be needed for DTV. */ - if (new_mode == T_ANALOG_TV) { + if (new_mode == T_ANALOG_TV) rc = send_seq(priv, {0x00, 0x00}); - } else if (priv-cur_fw.type ATSC) { - offset = 175; - } else { - offset = 275; + + /* + * Digital modes require an offset to adjust to the + * proper frequency + */ + if (new_mode != T_ANALOG_TV) { + /* Sets the offset according with firmware */ + if (priv-cur_fw.type DTV6) + offset = 175; + if (priv-cur_fw.type DTV7) + offset = 225; + else/* DTV8 or DTV78 */ + offset = 275; + /* - * We must adjust the offset by 500kHz in two cases in order - * to correctly center the IF output: - * 1) When the ZARLINK456 or DIBCOM52 tables were explicitly - *selected and a 7MHz channel is tuned; - * 2) When tuning a VHF channel with DTV78 firmware. + * We must adjust the offset by 500kHz when + * tuning a 7MHz VHF channel with DTV78 firmware + * (used in Australia) */ - if (((priv-cur_fw.type DTV7) - (priv-cur_fw.scode_table (ZARLINK456 | DIBCOM52))) || - ((priv-cur_fw.type DTV78) freq 47000)) + if ((priv-cur_fw.type DTV78) freq 47000) offset -= 50; } --- Patch is available at: http://linuxtv.org/hg/v4l-dvb/rev/e6a8672631a0f5f549f5ee5db3acac4f35013942 -- 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 3/9] dm355 ccdc module for vpfe capture driver
Karicheri, Muralidharan m-kariche...@ti.com writes: Laurent, Thanks for reviewing this. I have not gone through all of your comments, but would like to respond to the following one first. I will respond to the rest as I do the rework. I've had a quick look at the DM355 and DM6446 datasheets. The CCDC and VPSS registers share the same memory block. Can't you use a single resource ? One nice (and better in my opinion) solution would be to declare a structure with all the VPSS/CCDC registers as they are implemented in hardware and access the structure fields with __raw_read/write*. You would then store a single pointer only. Check arch/powerpc/include/asm/immap_cpm2.h for an example. I think, a better solution will be to move the vpss system module part to the board specific file dm355.c or dm6446.c Just to clarify, the files you mention are SoC specific files, not board-specific files... and export functions to configure them as needed by the different drivers. My first reaction to this is... no. I'm reluctant to have a bunch of driver specific hooks in the core davinci SoC specific code. I'd much rather see this stuff kept along with the driver in drivers/media/* and abstracted as necessary there. The vpss has evolved quite a lot from DM6446 to DM355 to DM365. Registers such as INTSEL and INTSTAT and others are applicable to other modules as well, not just the ccdc module. The VPBE and resizer drivers will need to configure them too. Also the vpss system module features available in DM365 is much more than that in DM355. Based on this, it sounds to me that this driver needs to be broken up a little bit more and some of the shared pieces need to be abstracted out so they can be shared among the modules. Interrupts line to ARM are programmable in DM365 vpss and multiple vpss irq lines can be muxed to the ARM side. So I would imaging functions enable/disable irq line to arm, clearing irq bits, enabling various clocks etc can be done in a specific soc specific file (dm355.c, dm365.c or dm6446.c) and can be exported for use in specific drivers. I just want to get your feedback so that I can make this change. With this change, there is no need to use structures for holding register offsets as you have suggested. Kevin -- 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