Re: cx18, s5h1409: chronic bit errors, only under Linux
On 06/10/2009 10:32 AM, Steven Toth wrote: David Ward wrote: Comcast checked the outlet on channels 2 (41 dB) and 83 (39 dB). I looked afterwards and saw that the first of those is analog programming, but the second just appears as analog noise on my TV set. (??) I asked them to check a specific ATSC channel, but it seems that their meter was fixed to those two frequencies, which doesn't really help. The ATSC rebroadcasts by Comcast are on high frequencies; the program I am testing primarily is on channel 79 (tunes at 555 MHz). I need to make a correction here. I am receiving all programming over digital cable. I mistakenly thought that rebroadcasts of over-the-air signals on a cable network followed all the ATSC specifications (including the modulation scheme) over the particular carrier frequency. Now I understand that like all other digital cable channels, local channels are broadcasted using QAM rather than 8VSB (but then they also include PSIP data as required by the FCC). So the SNR requirements for QAM-256 are the ones that should apply to my situation. That's a big misunderstanding on my part...my bad. Which of these three values is UNC/BER and which is snr? I don't understand, I need you to be more specific. Sorry for not being clear. I tested again thoroughly under both Linux and Windows before writing this response. Linux is tuning almost all channels at a SNR approximately 3 dB less than under Windows. That is why I now believe this is a tuner driver problem. I composed a table for myself with average SNRs per channel while running both Windows and Linux to determine this, both with the tuner card connected directly to the household cable, and connected behind the splitter in my house. Under Windows, channels with low frequencies have an SNR of ~35 dB, and channels with high frequency have an SNR of ~33 dB, when connected directly to the household input. The splitter at most gives me a loss of 1 dB but often makes no difference. Again, sorry for not making that clear. I think the 3 dB difference is the real issue at play here, and is the reason I'm writing this message to this list, rather than one intended for household wiring issues. Did you get a chance to review the signal monitor to determine whether it was 64 or 256? All channels are 256-QAM -- reported as such by both Linux and Windows. If you have any way to attenuate the signal then you'll find that very quickly the windows 30.5 will drop just a little and you'll begin to see real uncorrectable errors. I alluded to this yesterday. With 30.5 your just a fraction above 'working' reliably. If you were to insert attenuation through some barrel connectors, or join some other cables together to impede the RF, you'd see that 30.5 drop quickly and the errors would begin to appear. I suspect this will still occur, as I mentioned yesterday. The windows drivers is working slightly better for you but it's still no where near good enough RF for reliable 24x7x365 viewing. You'll find the RF on your local cable rings varies during an average day. It certainly does for me on various products. What looks great today (when you're on the edge) can look ugly at 9pm in the evening or 7am thursday morning. I wouldn't expect pristine recordings with Microsoft MCE (or other apps) (for any random moment in the week) with a 30.5 reading. Based on our discussion until now, the difference between 30.5 dB and 33.5 dB should be very significant, and I hope would warrant an investigation into the cause (possibly asking Hauppauge/Conexant to compare details of your tuner drivers against theirs? I understand they provide support to the Linux community). As you said, if Windows was only picking up the channels at 30.5 dB, then I shouldn't expect much more than I am getting now, as I would be riding on a thin line between errors and no errors. Sorry for not being accurate in some of my earlier messages, and thanks for being patient with me. David -- 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: cx18, s5h1409: chronic bit errors, only under Linux
On 06/09/2009 03:26 PM, Steven Toth wrote: 30db for the top end of ATSC sounds about right. David, when you ran the windows signal monitor - did it claim QAM64 or 256 when it was reporting 30db? Steven and Devin, All the digital signals are 256 QAM. 39 is very good, exceptional. And did they do as I suggested, which is measure db across the high channels? ... and ideally against your problematic channel? I assume not. Comcast checked the outlet on channels 2 (41 dB) and 83 (39 dB). I looked afterwards and saw that the first of those is analog programming, but the second just appears as analog noise on my TV set. (??) I asked them to check a specific ATSC channel, but it seems that their meter was fixed to those two frequencies, which doesn't really help. The ATSC rebroadcasts by Comcast are on high frequencies; the program I am testing primarily is on channel 79 (tunes at 555 MHz). Under Windows I'm now seeing 34.5-34.8 dB for lower frequency QAM, 32.5-32.7 dB for higher frequency QAM, and about 30.5 dB for ATSC. Under Linux with azap, the corresponding BER/UNC values are 0x0140, 0x0134, and 0x0132. I'm not exactly sure what numbers I should be going by here...again, wish I had my own meter. I admit that I ruled out the idea of RF issues too soon, which I really should know better than. After reading the thread at http://forums.gbpvr.com/showthread.php?t=36049 I'm now realizing why reception on the TV and tuner card isn't going to be equal, due to limited size and shielding of tuner circuitry on a PCI form factor card vs. on a TV set. Makes sense. Still, I am continuing to see uncorrectable bit errors at the same rate as before under Linux, while Windows sees errors but corrects them. I would think that both drivers should be receiving identical streams of data from the chipset, and should be able to process them the same way? That's what is confusing me. Ideally I would like to have access to a lot more equipment to control all the variables and make it easier to reproduce what I am seeing...but I don't here... Or do you guys think that this is still primarily an RF problem? I don't know what else I could do about that though. Since the SNR did not improve when I hooked the tuner card directly into the cable input from the street, I'm concerned that putting an amplifier would not help and could just make things worse. And clearly Comcast now considers me to be within their quality thresholds. I really appreciate your help and patience with me, especially to the extent that this is going outside the realm of DVB drivers. David -- 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: cx18, s5h1409: chronic bit errors, only under Linux
On 06/09/2009 10:24 AM, Steven Toth wrote: David has called out Comcast to review his installation. After replacing all the connectors and some cables from the pole all the way to the outlet, their meter ultimately showed 39-40dB at the outlet. My card is showing the same SNR values as before. Go figure. -- 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
cx18, s5h1409: chronic bit errors, only under Linux
I have a Hauppauge WinTV-HVR-1600 that I am using to capture ATSC and clear QAM programming from cable television (Comcast of Chattanooga). This card uses the cx18 and s5h1409 kernel modules. There are frequent bursts of bit errors occurring every few seconds in the incoming transport stream, when I have the card tuned under Linux. This causes artifacts in the received video as well as skipping in the received audio, to the point that it is practically unwatchable. However, under Windows on the same system/capture card, I can tune to the same programs with nearly perfect reception (no bit errors). Also these programs appear on my TV with great quality as well. The problem is happening on all of several different frequencies/programs that I have tried, although it is more pronounced on some programs (particularly ATSC) than others. I have tried the latest v4l-dvb development sources under both kernel 2.6.24 and kernel 2.6.29, and additionally I have tried to use the unmodified v4l-dvb from kernel 2.6.29. Additionally, I have tried both the recommended cx23418 firmware from linuxtv.org, as well as the newer firmware provided by latest the Hauppauge drivers for Windows (which I am using successfully under Windows). Unfortunately they all produce the same results. I primarily use MythTV to capture the programs to a file, and the resulting file exhibits these problems. However, I can also see the bit errors when I simply use the 'azap' application to tune the card directly (and also read the dvr0 device into a file). The BER and UNC values reported by 'azap' are non-zero approximately one out of every five samples; then they are usually around 0x200, though this varies. The BER and UNC values are almost always identical, i.e., no error correction is taking place, only error detection. Additionally I am not seeing any TS continuity or TEI flag errors, as detectable in the system log with the latest changeset. I have tried to rule out other possible causes such as a weak input signal (by hooking the capture card directly to the household cable television input, bypassing all coaxial splitters) and system-specific issues (by trying this on three different systems). However, to me it seems that the problem must be originating from an issue in the kernel modules for this card. I understand that having some errors in the transport stream is unavoidable, and I have tried postprocessing with an application such as Project-X. However, it does not magically take care of this -- the length of the video is reduced by about 20% and the resulting video jumps around constantly. Please let me know how I should proceed in solving this. I would be happy to provide samples of captured video, results from new tests, etc. Thanks, David Ward -- 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: cx18, s5h1409: chronic bit errors, only under Linux
On 06/08/2009 10:17 AM, Devin Heitmueller wrote: On Mon, Jun 8, 2009 at 10:14 AM, Steven Tothst...@kernellabs.com wrote: Please let me know how I should proceed in solving this. I would be happy to provide samples of captured video, results from new tests, etc. When you tune using azap, and you can see UNC and BER values, what is the SNR value and does it move over the course of 30 seconds? -- Steven Toth - Kernel Labs http://www.kernellabs.com Also, I believe UNC and BER display garbage when signal lock is lost, so do you see the status field change when the BER/UNC fields show data? Devin Steven, Devin, Thanks for your replies. The signal and SNR are usually in the range 0x0128 - 0x0140. They may increment or decrement on a per-second basis but otherwise remain steady. The status field does not change most of the time when bit errors occur, but it does lose the lock from time to time for a second. Here is a representative sample: da...@delldimension:~$ azap -r RTN using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' tuning to 55500 Hz video pid 0x0051, audio pid 0x0052 status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 1f | signal 012e | snr 012e | ber 1b04 | unc 1b04 | FE_HAS_LOCK status 1f | signal 012c | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber 0269 | unc 0269 | FE_HAS_LOCK status 1f | signal 012e | snr 012c | ber | unc | FE_HAS_LOCK status 1f | signal 012c | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012c | snr 012c | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber 0266 | unc 0266 | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber 0002 | unc 0002 | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber 0150 | unc 0150 | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber 0273 | unc 0273 | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber 0001 | unc 0001 | FE_HAS_LOCK status 1f | signal 012c | snr 012c | ber | unc | FE_HAS_LOCK status 07 | signal 012c | snr 012c | ber | unc | status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012c | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012c | snr 012c | ber | unc | FE_HAS_LOCK status 1f | signal 012c | snr 012e | ber 0263 | unc 0263 | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK status 1f | signal 012e | snr 012e | ber | unc | FE_HAS_LOCK -- 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: cx18, s5h1409: chronic bit errors, only under Linux
On 06/08/2009 12:31 PM, Steven Toth wrote: Your SNR is very low, 0x12c is 30db. I assume you're using digital cable this is borderline. Oh okay ... I wasn't sure how to translate those values before. I like my cable system at home to be atleast 32db (0x140) bare minimum, it's typically 0x160 (36db) for comfort. In your opinion, would I have enough justification for asking Comcast to increase the signal strength coming to my house? I'd like to avoid calling someone to come out to my house to say your TV works fine, what's the problem? and get slapped with a repair fee. I wasn't sure how well I could trust the SNR values reported by the card either... I wish I had a meter or something to test it on my own. When I move the computer directly to the input for the entire house, I get an increase of about 0.1dB. FYI, the signal strength is about 1dB higher for clear QAM signals. (The values I sent are for ATSC.) It's possible that the tuner and 1409 driver are a little more optimized under windows. How much attenuation can you add under windows with signal loss? It's probably reasonably close to the edge also. I tuned to the same channel under Windows, and I used the Signal Strength Indicator application from Hauppauge (downloadable under the Accessories page in the Support section). It's reporting a SNR of 29-30 dB, and the value for 'correctable' errors goes to a single-digit value about every 5 seconds -- following the same pattern seen with 'azap'. However, the difference is that 'uncorrectable' errors stays at 0. Under Linux, it seems that all errors are 'uncorrectable'. Does the error correction occur in the driver or in the chipset? Seems to me like maybe error correction is either not enabled or not implemented correctly by the driver? I agree that the SNR could be better, and if you think it is worth a try, I'll see what Comcast will do. However, because Windows and my TV work almost flawlessly, the Linux driver would ideally handle the signals at least as well as them... Let me know what else is helpful from me, and thanks again for your help. David -- 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: cx18, s5h1409: chronic bit errors, only under Linux
On 06/08/2009 04:36 PM, Devin Heitmueller wrote: On Mon, Jun 8, 2009 at 4:20 PM, Steven Tothst...@kernellabs.com wrote: We're getting into the realm of 'do you need to amplify and/or debug your cable network', and out of the realm of driver development. Comcast is coming tomorrow to check out the signal quality. They said that they expect to deliver SNR in the range of 33dB - 45dB to the premises. I will let you know how that affects Linux captures. Steven, One thing that is interesting is that he is getting BER/UNC errors even on ATSC, when he has a 30.2 dB signal. While I agree that the cable company could be sending a weak signal, 30 dB should be plenty for ATSC. Also, it's possible that the playback application/codec in question poorly handles recovery from MPEG errors such as discontinuity, which results in the experience appearing to be worse under Linux. I am actually comparing the TS files captured under both Linux and Windows side-by-side in the same environment, copying the files to other computers in my home. I can demux the video with Project-X which prints out the errors in the bitstream as it reads them. I can also observe the overall quality by playing it back with VLC, WinDVD, etc. When I use TMPGEnc Authoring Works 4 to read the file, the errors in the bitstream even seem to crash the application -- though obviously TMPGEnc is to blame for that. I'm going to see if I can find some cycles to do some testing here with s5h1409/s5h1411 and see if I can reproduce what David is seeing. Devin, I would really really appreciate this. I hesitated to e-mail this list for several weeks, because I wanted to investigate thoroughly first and avoid wasting anyone's time as much as possible. I hope you are able to reproduce this. David -- 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] cx18: Use do_div for 64-bit division to fix 32-bit kernels
On 05/29/2009 07:09 AM, Andy Walls wrote:
On Thu, 2009-05-28 at 20:27 -0400, David Ward wrote:
Use the do_div macro for 64-bit division. Otherwise, the module will
reference __udivdi3 under 32-bit kernels, which is not allowed in kernel
space. Follows style used in cx88 module.
Ooopsie. Thanks for catching this and providing a fix. :)
(FYI, You would have caught my attention earlier if you had put cx18:
in the subject line of the initital report.)
I'll test it tonight on my 64 bit machine, commit it, and ask Mauro to
pull it. I assume you've tested it on your 32 bit machine.
Regards,
Andy
Thanks Andy. Yes it's running on my 32-bit system. Until Michael
pointed out the offending line of code, I didn't realize that the
problem I was seeing was specific to the cx18 module -- I figured that
the problem could just as easily have been in an include somewhere and
affected multiple modules, perhaps only under older kernels -- so that's
why my original subject line was generic. But I'll keep that in mind in
the future.
David
Signed-off-by: David Warddavid.w...@gatech.edu
diff -r 65ec132f20df -r 91b89f13adb7
linux/drivers/media/video/cx18/cx18-av-core.c
--- a/linux/drivers/media/video/cx18/cx18-av-core.cWed May 27
15:53:00 2009 -0300
+++ b/linux/drivers/media/video/cx18/cx18-av-core.cThu May 28
19:16:10 2009 -0400
@@ -447,6 +447,7 @@ void cx18_av_std_setup(struct cx18 *cx)
if (pll_post) {
int fsc, pll;
+u64 tmp64;
pll = (28636360L * u64)pll_int) 25) + pll_frac)) 25;
pll /= pll_post;
@@ -459,7 +460,9 @@ void cx18_av_std_setup(struct cx18 *cx)
= %d.%03d\n, src_decimation / 256,
((src_decimation % 256) * 1000) / 256);
-fsc = u64)sc) * 28636360)/src_decimation) 13L;
+tmp64 = ((u64)sc) * 28636360;
+do_div(tmp64, src_decimation);
+fsc = ((u32)(tmp64 13L));
CX18_DEBUG_INFO_DEV(sd,
Chroma sub-carrier initial freq = %d.%06d
MHz\n, fsc / 100, fsc % 100)
--
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: Unknown symbol __udivdi3 with rev = 11873
On 05/28/2009 03:12 PM, Michael Krufky wrote: On Thu, May 28, 2009 at 12:05 AM, David Warddavid.w...@gatech.edu wrote: Revision 11873 (committed earlier today) has broken the cx18 driver for me, with the line cx18: Unknown symbol __udivdi3 appearing in dmesg when the module tries to load. I'm using Ubuntu 8.04.2 which uses kernel 2.6.24 and gcc 4.2.4. I also wanted to express my appreciation to Mauro for fixing the build for older kernels today, as it is very desirable for me to use a distribution/kernel which has long-term support and updates, but I simply need to add a DVB driver that wasn't part of the older kernel. Thanks so much. David Ward Let it be known that this issue only affects 32bit kernels. I believe the offending line of code is here: fsc = u64)sc) * 28636360)/src_decimation) 13L; (cc added to Andy Walls) -Mike Krufky Some Google searching seems to suggest that the correct thing to do here is to use the 'do_div' macro for the division, which is declared in asm/div64.h: http://www.captain.at/howto-udivdi3-umoddi3.php David -- 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] cx18: Use do_div for 64-bit division to fix 32-bit kernels
Use the do_div macro for 64-bit division. Otherwise, the module will
reference __udivdi3 under 32-bit kernels, which is not allowed in kernel
space. Follows style used in cx88 module.
Signed-off-by: David Ward david.w...@gatech.edu
diff -r 65ec132f20df -r 91b89f13adb7
linux/drivers/media/video/cx18/cx18-av-core.c
--- a/linux/drivers/media/video/cx18/cx18-av-core.cWed May 27
15:53:00 2009 -0300
+++ b/linux/drivers/media/video/cx18/cx18-av-core.cThu May 28
19:16:10 2009 -0400
@@ -447,6 +447,7 @@ void cx18_av_std_setup(struct cx18 *cx)
if (pll_post) {
int fsc, pll;
+u64 tmp64;
pll = (28636360L * u64)pll_int) 25) + pll_frac)) 25;
pll /= pll_post;
@@ -459,7 +460,9 @@ void cx18_av_std_setup(struct cx18 *cx)
= %d.%03d\n, src_decimation / 256,
((src_decimation % 256) * 1000) / 256);
-fsc = u64)sc) * 28636360)/src_decimation) 13L;
+tmp64 = ((u64)sc) * 28636360;
+do_div(tmp64, src_decimation);
+fsc = ((u32)(tmp64 13L));
CX18_DEBUG_INFO_DEV(sd,
Chroma sub-carrier initial freq = %d.%06d
MHz\n, fsc / 100, fsc % 100);
--
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
Unknown symbol __udivdi3 with rev = 11873
Revision 11873 (committed earlier today) has broken the cx18 driver for me, with the line cx18: Unknown symbol __udivdi3 appearing in dmesg when the module tries to load. I'm using Ubuntu 8.04.2 which uses kernel 2.6.24 and gcc 4.2.4. I also wanted to express my appreciation to Mauro for fixing the build for older kernels today, as it is very desirable for me to use a distribution/kernel which has long-term support and updates, but I simply need to add a DVB driver that wasn't part of the older kernel. Thanks so much. David Ward -- 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: v4l-dvb rev 11757 broke building under Ubuntu Hardy
On 05/14/2009 07:53 PM, Andy Walls wrote:
David Ward wrote:
I am using v4l-dvb in order to add the cx18 driver under Ubuntu Hardy
(8.04).
The build is currently broken under Hardy, which uses kernel 2.6.24. I
have traced the origin of the problem to revision 11757. As seen in
the latest cron job output, the build produces the error when trying
to compile adv7343.c:
/usr/local/src/v4l-dvb/v4l/adv7343.c:506: error: array type has incomplete
element type
/usr/local/src/v4l-dvb/v4l/adv7343.c:518: warning: initialization from
incompatible pointer type
/usr/local/src/v4l-dvb/v4l/adv7343.c:520: error: unknown field 'id_table'
specified in initializer
Thanks for resolving this.
David Ward
David,
Please try the patch below.
Chaithrika,
Please review (and test if it is OK) the patch below. It modifies
adv7343.c to what the cs5345.c file does for backward compatability.
It adds some checks against kernel version, which would not go into the
actual kernel, and changes some code to use the v4l2 i2c module template
from v4l2-i2c-drv.h, which *would* go into the actual kenrel.
Regards,
Andy
Andy and Chaithrika, sorry for the late reply. Is a different patch
being created to replace the ones you posted already, for adv7343.c and
ths7303.c? This is still broken in the repository.
Andy, your initial patch at least did resolve the build errors for
adv7343.c under the Ubuntu Hardy kernel (2.6.24).
Thanks,
David
Signed-off-by: Andy Wallsawa...@radix.net
diff -r 0018ed9bbca3 linux/drivers/media/video/adv7343.c
--- a/linux/drivers/media/video/adv7343.c Tue May 12 16:13:13 2009 +
+++ b/linux/drivers/media/video/adv7343.c Thu May 14 19:51:10 2009 -0400
@@ -29,6 +29,8 @@
#includemedia/adv7343.h
#includemedia/v4l2-device.h
#includemedia/v4l2-chip-ident.h
+#includemedia/v4l2-i2c-drv.h
+#include compat.h
#include adv7343_regs.h
@@ -503,6 +505,7 @@
return 0;
}
+#if LINUX_VERSION_CODE= KERNEL_VERSION(2, 6, 26)
static const struct i2c_device_id adv7343_id[] = {
{adv7343, 0},
{},
@@ -510,25 +513,12 @@
MODULE_DEVICE_TABLE(i2c, adv7343_id);
-static struct i2c_driver adv7343_driver = {
- .driver = {
- .owner = THIS_MODULE,
- .name = adv7343,
- },
+#endif
+static struct v4l2_i2c_driver_data v4l2_i2c_data = {
+ .name = adv7343,
.probe = adv7343_probe,
.remove = adv7343_remove,
+#if LINUX_VERSION_CODE= KERNEL_VERSION(2, 6, 26)
.id_table = adv7343_id,
+#endif
};
-
-static __init int init_adv7343(void)
-{
- return i2c_add_driver(adv7343_driver);
-}
-
-static __exit void exit_adv7343(void)
-{
- i2c_del_driver(adv7343_driver);
-}
-
-module_init(init_adv7343);
-module_exit(exit_adv7343)
--
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: videodev: Unknown symbol i2c_unregister_device (in kernels older than 2.6.26)
On 05/24/2009 07:10 PM, Matt Doran wrote: Hi there, I tried using the latest v4l code on an Mythtv box running 2.6.20, but the v4l videodev module fails to load with the following warnings: videodev: Unknown symbol i2c_unregister_device v4l2_common: Unknown symbol v4l2_device_register_subdev It seems the i2c_unregister_device function was added in 2.6.26. References to this function in v4l2-common.c are enclosed in an ifdef like: #if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 26) However in v4l2_device_unregister() in v4l2-device.c, there is a reference to i2c_unregister_device without any ifdefs. I am running a pretty old kernel, but I'd guess anyone running 2.6.25 or earlier will have this problem. It seems this code was added by Mauro 3 weeks ago in this rev: http://linuxtv.org/hg/v4l-dvb/rev/87afa7a4ccdf I also had some other compile problems, but don't have all the details (sorry!). I had to disable the following drivers to get it to compile: * CONFIG_VIDEO_PVRUSB2 * CONFIG_VIDEO_THS7303 * CONFIG_VIDEO_ADV7343 * CONFIG_DVB_SIANO_SMS1XXX Regards, Matt Matt, I checked out v4l-dvb today and am using it under 2.6.24 and so far so good. When did the error appear -- when you were trying to load the module? I have been seeing the errors compiling adv7343.c and ths7303.c under 2.6.24 as well. Andy Walls and Chaithrika Subrahmanya had written patches for those two modules respectively, but there were some comments during the review of the patches, so I think they are still being worked on. David -- 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: OpenSuse 11.1 + v4l
On 05/13/2009 03:27 AM, Peter Forstmeier wrote: Hi, i tried to build v4l and did tho following: pe...@linux-d9lb:~ hg clone http://linuxtv.org/hg/v4l-dvb destination directory: v4l-dvb requesting all changes adding changesets adding manifests adding file changes added 11759 changesets with 29793 changes to 2019 files updating working directory 1448 files updated, 0 files merged, 0 files removed, 0 files unresolved pe...@linux-d9lb:~ hg clone http://linuxtv.org/hg/dvb-apps destination directory: dvb-apps requesting all changes adding changesets adding manifests adding file changes added 1275 changesets with 5390 changes to 1814 files updating working directory 1315 files updated, 0 files merged, 0 files removed, 0 files unresolved pe...@linux-d9lb:~ cd v4l-dvb pe...@linux-d9lb:~/v4l-dvb hg pull -u http://linuxtv.org/hg/v4l-dvb pulling from http://linuxtv.org/hg/v4l-dvb searching for changes no changes found Doing 'make' make make -C /home/peter/v4l-dvb/v4l make[1]: Entering directory `/home/peter/v4l-dvb/v4l' No version yet, using 2.6.27.7-9-pae make[1]: Leaving directory `/home/peter/v4l-dvb/v4l' make[1]: Entering directory `/home/peter/v4l-dvb/v4l' scripts/make_makefile.pl Updating/Creating .config Preparing to compile for kernel version 2.6.27 File not found: /lib/modules/2.6.27.7-9-pae/build/.config at ./scripts/make_kconfig.pl line 32,IN line 4. make[1]: Leaving directory `/home/peter/v4l-dvb/v4l' make[1]: Entering directory `/home/peter/v4l-dvb/v4l' Updating/Creating .config Preparing to compile for kernel version 2.6.27 File not found: /lib/modules/2.6.27.7-9-pae/build/.config at ./scripts/make_kconfig.pl line 32,IN line 4. make[1]: *** Keine Regel vorhanden, um das Target ».myconfig«, benötigt von »config-compat.h«, zu erstellen. Schluss. make[1]: Leaving directory `/home/peter/v4l-dvb/v4l' make: *** [all] Fehler 2 pe...@linux-d9lb:~/v4l-dvb Any idea's about that. Thanks Peter I believe you do not have the kernel header files installed. Under OpenSUSE it looks like there isn't a separate package for the kernel headers, so you just need to install the full kernel sources instead (the kernel-source RPM). -- 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
v4l-dvb rev 11757 broke building under Ubuntu Hardy
I am using v4l-dvb in order to add the cx18 driver under Ubuntu Hardy (8.04). The build is currently broken under Hardy, which uses kernel 2.6.24. I have traced the origin of the problem to revision 11757. As seen in the latest cron job output, the build produces the error when trying to compile adv7343.c: /usr/local/src/v4l-dvb/v4l/adv7343.c:506: error: array type has incomplete element type /usr/local/src/v4l-dvb/v4l/adv7343.c:518: warning: initialization from incompatible pointer type /usr/local/src/v4l-dvb/v4l/adv7343.c:520: error: unknown field 'id_table' specified in initializer Thanks for resolving this. David Ward -- 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
