Re: Status of RTL283xU support?
latest news on that seems to be that you were working on cleaning up the code of the Realtek-provided GPL driver, with the goal of eventually getting it into mainline. Ah, does the Realtek branch have support for DAB(+) and FM? In Windows the chip can do DAB+ and FM as well as DVB-T. The problem I think is that the DAB and FM demodulation has to be done in software so the driver would only tune the chip and provide the digitised baseband signal. If this could be done then throwing the data stream into something like OpenDAB's demodulator should work. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AF9015 Dual tuner i2c write failures
I concur. I have been using Malcolm Priestly's patches with both my AF9015 dual tuner cards (which are PCI but still look like USB to the kernel) for a few weeks now and have (finally!) got consistently perfect recordings in MythTV simultaneously with both tuners on a card. Malcolm, when do you think you'll submit these patches to the tree for inclusion? Is there anything else to test? I agree about the power cycling. Every time I reboot I disconnect the AC supply for 20secs to be sure the cards are power cycled properly - you do the same thing by pulling out the stick. On 12 November 2011 09:16, Josu Lazkano josu.lazk...@gmail.com wrote: 2011/11/11 Tim Draper veeh...@gmail.com: Hi all, i've recently bought an AF9015 usb module from ebay, and am struggling to get it working correctly. i've been recommended to post here on the mythtv MailingList. i'm running mytbuntu 11.04 x64, and the mythbackend service shows af9013: I2C read failed reg:d607 af9015: command failed:1 and will refuse to establish a lock. so far i've only been able to find a temporary fix to this by re-inserting the USB stick (ie: it has to loose power on the USB stick) i've been googling a fair bit, and i've only found somewhat old info reguarding (firmware?) source code that is no longer available (it has been merged into another codeset), and thus the patch file is not applicable to it http://ubuntuforums.org/showpost.php?p=9712937postcount=126 is what i'm working from. i am confident the device does work as if i test it immediately after being re-inserted i get both tuners working fine. after a while though i start seeing the above errors in the mythtv logs, and i am no longer able to tune into channels. just to be clear, i am sure the issue is down to a firmware/driver issue, and not a config or a problem is yet to be discovered as the last few nights of googling does show this as an issue on certain devices. how do i get this issue sorted? thanks for any help! -- 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 Hello Tim, Malcolm is working on a patch and it is working, maybe it is not finished but I am using it on MythTV. I can send it, but I prefer to wait a reply from Malcolm, he is great! Best regards. -- Josu Lazkano -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] af9013 Extended monitoring in set_frontend.
Trouble is, on a Nvidia motherboard I have it does not do it at all and all applications work without any troubles. This seems to suggest a USB motherboard driver issue. Right. Well, I can say with high confidence that my dual tuner worked flawlessly for 18 months using Ubuntu's kernel 2.6.32 up until some update around May. Some kernel (or other) update apparently made it all go pear shaped which prompted me to get another card then update the whole system to try fix the problem - I haven't gone back to an old 2.6.32 kernel. So I am wondering if some other non v4l related patch has affected us all. I am continuing to look into it. OK, well I am still running my system with your two patches, with corruptions alas, so if you'd like me to independently try stuff out let me know. Jason -- 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] af9013 Extended monitoring in set_frontend.
Playing with Kaffeine or Mplayer all the devices are fine on the same system. Right, admittedly most of my testing has been done with MythTV. I recall about a month ago I could also get corruption with mplayer. At the moment, I am going step by step what Myth TV is sending to the devices. Great. If you want I can replicate your tests here to see what I get. Antti, my AF9015 chips are integrated on PCI so I can't swap cables (alas, if only this was my problem!) Cheers Jason -- 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] af9013 Extended monitoring in set_frontend.
Which kernels are you all running? 2.6.38-11-generic #50-Ubuntu SMP (Mythbuntu 11.04) -- 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] af9013 Extended monitoring in set_frontend.
Try this patch, it should stop start up corruption on the same frontend. Thanks. I'll try it today. Have you been able to reproduce any of the corruption issues I and others are having? I noticed last night some recordings on the same card had different levels of corruption depending on the order of tuning Tuner A then tuner B : Tuner A was heavily corrupted. Tuner B was a fine. Tuner B then tuner A: Tuner A had a small corruption every few seconds and the show was watchable, Tuner B was fine. -- 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] af9013 frontend tuner bus lock
http://palosaari.fi/linux/v4l-dvb/firmware/af9015/5.1.0.0/dvb-usb-af9015.fw 5.1? OK, I might eventually try that one too. This morning I get a little pixeled playback, less than a second. OK, mine was fine for a few days then the pixellation started up in earnest. At the moment my symptoms were always: TunerA: Tuned - picture good TunerB: Idle Tuner B gets tuned, Tuner A starts to pixellate badly. I am sure this is the case too: TunerA: Idle TunerB: Tuned - picture good Tuner A gets tuned and has a bad recording. *Never* has Tuner B suffered from the pixellation in spite of whatever Tuner A is doing! Anyway, Malcolm has suggested there is a bug lurking in MythTV too causing problems with dual tuners so it's a bit hard to isolate the issue. -- 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] af9013 frontend tuner bus lock
http://dl.dropbox.com/u/1541853/VID_20111006_004447.3gp That looks very familiar! Does it occur on tuner A or B? I get this I2C messages: # tail -f /var/log/messages Oct 5 20:16:44 htpc kernel: [ 534.168957] af9013: I2C read failed reg:d330 As far as I know I never had any such messages. Maybe though the debugging isn't enabled properly. There are lots of ber and unc bits, I have connected the TV to the same wire and there is a good signal. Yes, your TV might have a better receiver though - I have the same problem, if my TV decoding is OK but the signal is weak then my DVB cards have problems. I have solved this signal problem by using quad-shield cable and F-connectors and proper metal can splitters so now everything gets a good signal. I am pretty sure my issues are not signal related because Tuner A is fine until tuner B is enabled and tuner B always records a very low error signal (usually not even one visible error). -- 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] af9013 frontend tuner bus lock
I have had some luck with this patch. I am still getting fouled
recordings with tuner A but it's not consistent. I have yet to
ascertain if the problem occurs depending on the order of tuning to
have both tuners recording different frquencies at the same time, ie
Tuner B then Tuner A or vice versa.
Malcolm, did you say there was a MythTV tubing bug? Do you have an
URL for the bug if it has been reported?
I fear I might have a multi-layered problem - not only the Afatech
tuners but perhaps some PCI issue too. It doesn't help if MythTV
isn't doing the right thing either.
On 5 October 2011 06:28, Josu Lazkano josu.lazk...@gmail.com wrote:
2011/9/28 tvboxspy tvbox...@gmail.com:
Frontend bus lock for af9015 devices.
Last week, I aqcuired a dual KWorld PlusTV Dual DVB-T Stick (DVB-T 399U).
The lock is intended for dual frontends that share the same tuner I2C address
to stop either frontend sending data while any gate is open. The patch
should have no effect on single devices or multiple single devices, well
not on the ones I have!
It also delays read_status call backs being sent while either gate is open, a
mostly like cause of corruption.
The lock also covers the attachment process of the tuner in case there is any
race condition, although unlikely.
Points about troubles with Myth TV;
Streaming corruptions are more likely to appear from the I2C noise generated
from setting either frontend. Afatech love their bits as bytes:-)
Latest version of Myth TV appears to have a bug where you can't select the
second
frontend independently and when it does it tunes to the same frequency as
the first frontend!
Signed-off-by: Malcolm Priestley tvbox...@gmail.com
---
drivers/media/dvb/dvb-usb/af9015.c | 7 ++-
drivers/media/dvb/frontends/af9013.c | 13 -
drivers/media/dvb/frontends/af9013.h | 5 +++--
3 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/af9015.c
b/drivers/media/dvb/dvb-usb/af9015.c
index c6c275b..0089858 100644
--- a/drivers/media/dvb/dvb-usb/af9015.c
+++ b/drivers/media/dvb/dvb-usb/af9015.c
@@ -43,6 +43,7 @@ MODULE_PARM_DESC(remote, select remote);
DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
static DEFINE_MUTEX(af9015_usb_mutex);
+static DEFINE_MUTEX(af9015_fe_mutex);
static struct af9015_config af9015_config;
static struct dvb_usb_device_properties af9015_properties[3];
@@ -1114,7 +1115,7 @@ static int af9015_af9013_frontend_attach(struct
dvb_usb_adapter *adap)
/* attach demodulator */
adap-fe_adap[0].fe = dvb_attach(af9013_attach,
af9015_af9013_config[adap-id],
- adap-dev-i2c_adap);
+ adap-dev-i2c_adap, af9015_fe_mutex);
return adap-fe_adap[0].fe == NULL ? -ENODEV : 0;
}
@@ -1187,6 +1188,9 @@ static int af9015_tuner_attach(struct dvb_usb_adapter
*adap)
int ret;
deb_info(%s:\n, __func__);
+ if (mutex_lock_interruptible(af9015_fe_mutex) 0)
+ return -EAGAIN;
+
switch (af9015_af9013_config[adap-id].tuner) {
case AF9013_TUNER_MT2060:
case AF9013_TUNER_MT2060_2:
@@ -1242,6 +1246,7 @@ static int af9015_tuner_attach(struct dvb_usb_adapter
*adap)
err(Unknown tuner id:%d,
af9015_af9013_config[adap-id].tuner);
}
+ mutex_unlock(af9015_fe_mutex);
return ret;
}
diff --git a/drivers/media/dvb/frontends/af9013.c
b/drivers/media/dvb/frontends/af9013.c
index 345311c..b220a87 100644
--- a/drivers/media/dvb/frontends/af9013.c
+++ b/drivers/media/dvb/frontends/af9013.c
@@ -50,6 +50,7 @@ struct af9013_state {
u16 snr;
u32 frequency;
unsigned long next_statistics_check;
+ struct mutex *fe_mutex;
};
static u8 regmask[8] = { 0x01, 0x03, 0x07, 0x0f, 0x1f, 0x3f, 0x7f, 0xff };
@@ -630,9 +631,14 @@ static int af9013_set_frontend(struct dvb_frontend *fe,
state-frequency = params-frequency;
/* program tuner */
+ if (mutex_lock_interruptible(state-fe_mutex) 0)
+ return -EAGAIN;
+
if (fe-ops.tuner_ops.set_params)
fe-ops.tuner_ops.set_params(fe, params);
+ mutex_unlock(state-fe_mutex);
+
/* program CFOE coefficients */
ret = af9013_set_coeff(state, params-u.ofdm.bandwidth);
if (ret)
@@ -1038,6 +1044,9 @@ static int af9013_read_status(struct dvb_frontend *fe,
fe_status_t *status)
u8 tmp;
*status = 0;
+ if (mutex_lock_interruptible(state-fe_mutex) 0)
+ return -EAGAIN;
+
/* MPEG2 lock */
ret = af9013_read_reg_bits(state, 0xd507, 6, 1, tmp);
if (ret)
@@ -1086,6 +1095,7 @@ static int af9013_read_status(struct dvb_frontend *fe,
fe_status_t *status)
ret = af9013_update_statistics(fe);
error:
+ mutex_unlock(state-fe_mutex);
return ret;
}
@@ -1446,7 +1456,7 @@ static void af9013_release(struct
Re: [PATCH] af9013 frontend tuner bus lock
Which Firmware are your using? 4.95 Yes, because it is also happening with other duo devices on Myth TV 0.24.1 OK, well that is what I am using so I guess I am stuck until it's fixed. Josu what software and versions are you using? -- 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] Re: Afatech AF9013 [TEST ONLY] AF9015 stream buffer size aligned with max packet size.
I think what might happening is that TS packets are getting chopped, as device seems to want to align to max packet size. Oh, I also noticed that the Linux driver uses a smaller USB packet count than Windows. Is there any discernible reason for this? Lag on DVB isn't an issue for me and probably everyone else due to the stream going to secondary storage first. Great, I'll try it out later. I have been studying the source code and noticed that the bus locking mechanism is TODOed and may be part of the problem. My symptom is that Tuner A fails when Tuner B is started and I have a theory that somehow the TDA18271 is getting some I2C data and being corrupted because of a gating problem with the I2C signal. The TDA18271 can change the last 2 bits of it's default I2C address by setting a voltage on its AS pin (presumably with resistor dividers) but I haven't delved in to determine if this what Leadtek have done - both tuners might be set to address 0xC0. I can only truly test this by putting CRO probe on and seeing if the I2C is going down the wrong path at the wrong time. I just wish ITE/Afa would release their data sheet to the public and make it as detailed and USEFUL as the TDA18271 data sheet. This obfuscation, need for NDAs and a half arsed data sheet and bloody sniffing Windows USB transactions for programming clues is such a waste of time and I fail to see how it benefits ITE to do this. The Afatech chips are 4+ years old anyway - what's the problem? If anyone wants to send me the data sheets and more importantly the DESIGN MANUAL from the devkit I'd be most grateful. -- 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: Afatech AF9013
I might have found one bug so far with the Afa9013 driver. As part of refactoring the code in http://git.linuxtv.org/linux-2.6.git/commitdiff/edb709b61abd3ba475e59d1ad81aab21ad025db6 I think one of the u32-u8 calculations is wrong. The think the second last u32 in the tables has to be changed. Here is the diff. I will try it later as I have run out of time to test it this morning. This may not fix the problems we are having but it might help... So patch the file af9013_priv.h with this in the latest git media_build and see what happens. I'll report back later with my results. af9013_priv.h.diff snip-- 74c74 0x29, 0x03, 0x5d, 0x7a, 0xec, 0x01, 0x45, 0x14, 0x14 } }, --- 0x29, 0x00, 0xa2, 0x85, 0x14, 0x01, 0x45, 0x14, 0x14 } }, 77c77 0xe4, 0x03, 0x71, 0xcb, 0xe8, 0x01, 0x1c, 0x71, 0x32 } }, --- 0xe4, 0x00, 0x8e, 0x34, 0x72, 0x01, 0x1c, 0x71, 0x32 } }, 80c80 0x9e, 0x03, 0x86, 0x1c, 0x31, 0x00, 0xf3, 0xcf, 0x0f } }, --- 0x9e, 0x00, 0x79, 0xe3, 0xcf, 0x00, 0xf3, 0xcf, 0x0f } }, 84c84 0x49, 0x03, 0x1b, 0x74, 0xdb, 0x01, 0xc9, 0x24, 0x25 } }, --- 0x49, 0x00, 0xe4, 0x8b, 0x25, 0x01, 0xc9, 0x24, 0x25 } }, 87c87 0x00, 0x03, 0x38, 0x06, 0x40, 0x01, 0x90, 0x00, 0x00 } }, --- 0x00, 0x00, 0xc7, 0xf9, 0xc0, 0x01, 0x90, 0x00, 0x00 } }, 90c90 0xb7, 0x03, 0x54, 0x97, 0xa4, 0x01, 0x56, 0xdb, 0x1c } }, --- 0xb7, 0x00, 0xab, 0x68, 0x5c, 0x01, 0x56, 0xdb, 0x1c } }, 94c94 0x05, 0x03, 0x58, 0xd6, 0x34, 0x01, 0x4e, 0x5e, 0x03 } }, --- 0x05, 0x00, 0xa7, 0x29, 0xcc, 0x01, 0x4e, 0x5e, 0x03 } }, 97c97 0x25, 0x03, 0x6d, 0xbb, 0x6e, 0x01, 0x24, 0x92, 0x12 } }, --- 0x25, 0x00, 0x92, 0x44, 0x92, 0x01, 0x24, 0x92, 0x12 } }, 100c100 0x44, 0x03, 0x82, 0xa0, 0xa7, 0x00, 0xfa, 0xc6, 0x22 } }, --- 0x44, 0x00, 0x7d, 0x5f, 0x59, 0x00, 0xfa, 0xc6, 0x22 } }, 104c104 0xe7, 0x03, 0x44, 0xc6, 0xf3, 0x01, 0x76, 0x7d, 0x34 } }, --- 0xe7, 0x00, 0xbb, 0x39, 0x0d, 0x01, 0x76, 0x7d, 0x34 } }, 107c107 0x0a, 0x03, 0x5c, 0x2e, 0x14, 0x01, 0x47, 0xae, 0x05 } }, --- 0x0a, 0x00, 0xa3, 0xd1, 0xec, 0x01, 0x47, 0xae, 0x05 } }, 110c110 0x2d, 0x03, 0x73, 0x95, 0x36, 0x01, 0x18, 0xde, 0x17 } }, --- 0x2d, 0x00, 0x8c, 0x6a, 0xca, 0x01, 0x18, 0xde, 0x17 } }, -- 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: Afatech AF9013
Damn, this patch didn't help so maybe forget this patch. Tuner A is still messed up. -- 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: Afatech AF9013
I just tried LiveCDs of Mythbuntu 10.04 and 10.10 but had limited luck with the former and some joy with the latter. Unfortunately the default framebuffer slowed things down. Anyway in LiveCD 10.10 I used mplayer to set up and view Tuner A and Tuner B and Tuner A only showed some slight errors when Tuner B was being set up. After that for some strange reason attempt at retuning with mplayer failed utterly so I suspect there is some problems with the older versions of mplayer. These cards have blue LEDs for each tuner and light up when in use. I did notice in my testing that the LED on tuner A would flicker off briefly (and presumably issue the errors) when Tuner B was being set up. I am wondering if there is a general setup problem or even a I2S timing problem. Could someone contact me off list about sending me the data sheets for the AF901x chips? -- 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: Afatech AF9013
I have a problem that may be related to the issues on this thread and it's driving me nuts. I have two dual tuner Afatech based cards, they are both Leadtek 2000DS cards, one made by Leadtek and the other branded as KWorld but they are otherwise identical in spite of different VID:PID. On each card tuner A is an AF9015 and tuner B is an AF9013. The KWorld card worked just fine for about 18 months in Mythbuntu 10.04 with the rebuilt and patched modules as described in the Wiki entry on the 2000DS. A few weeks ago tuner A started giving errors making the viewing unwatchable so figuring the card had died I bought the Leadtek. To my surprise it gave the same problem as the KWorld when using tuner A. It seems Tuner A is OK until Tuner B is used and then Tuner A gets a lot of errors. Tuner B never has errors. I did try using the latest media_build from V4L but that didn't help. So, I installed Mythbuntu 11.04 and with both cards I still get the same problem. Watching live TV with MythTV or with mplayer on tuner A gives errors and tuner B is always flawless even with media_build updates. I honestly can't recall if when the failure first occurred if I had done a routine kernel update at that time - though it would have just been the usual 2.6.32 update that is in line with 10.04 maintenance. I have tried everything imaginable to nail down the problem but can't seem to fix it. Even options dvb-usb force_pid_filter_usage=1 seems to improve the problem somewhat but the errors are still there. I have tried every firmware from 4.65 to 5.10, adjusting the PCI latency from 32 to 96, fed each card directly from the antenna (taking the splitter out of the loop), one card fitted, both cards fitted, kernel and system upgrades (Mythbuntu 10.04 to 11.04), mplayer vs MythTV but the results are always the same. Tuner B is perfect, tuner A corrupts when Tuner B is used. There are no errors or warnings in syslog or dmesg to suggest anything has failed. I'd appreciate any suggestions at this point as I am pretty unhappy with the situation considering it *used* to work. -- 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] Problem with saa7134: Asus Tiger revision 1.0, subsys 1043:4857
Hi Hermann, Hopefully it does help in that other case. I have it working now. I had to add a delay of 120 seconds in the mythtv backend script to allow the driver enough time to scan both cards and install the firmware properly. Previously the mythtv backend at startup was trying to talk to the cards before the firmware was loaded and so they'd fail to work. It's not a big hassle but it would seem in spite of a test in the startup script to ensure udev configuration was complete before mythbackend was loaded it would seem that udev device configuration was completing before the firmware was loaded. Is there the possibility of adding some feature into the driver to make sure it fails on opening if the firmware isn't properly loaded? Another general question, does V4L sequentially initialise hardware or does it run in parallel? It would seem to be a good time saver to have all DVB cards initialised in parallel to speed up booting of a system. I have reverted back to Mythbuntu 10.04 and kernel 2.6.32 and the cards work fine now (though with the latest v29 of the firmware for these cards). Cheers Jason -- 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: Problem with saa7134: Asus Tiger revision 1.0, subsys 1043:4857
I seem to have fixed the problem for now. It's the hoary old problem of Mythtv's backend coming up and accessing the cards before the firmware has loaded onto the cards. Adding in a startup delay to myth-backend's init script has solved the problem, for now. The firmware seems to load now on Mythbuntu 10.04 without a problem. Is there some way to put a lock in the driver or even speed up the process of loading the firmware with some command line arguments when the saa7134 driver is loaded? -- 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: [ANN] Agenda for the Warsaw meeting.
B) Use of V4L2 as a frontend for SW/DSP codecs (Laurent) This would be good. Realtek's RT2832U chip can tune to and possibly demodulate DAB/DAB+ and FM along with the usual DVB-T. Realtek does support DAB and FM in Windows with this part but not in Linux and in spite of promises from one of their developers I haven't seen anything from them. I think it'd be good to get this part talking to the DAB processing routines in OpenDAB or OpenMoko as I strongly suspect the part can tune to and provide a digital version of the bandband signal for demodulation of DAB or FM in user space. It might be a good opportunity to get a signal processing framework into the driver but I suspect an API to allow a user space demodulator to read ADC baseband data from such a device would be best and safest. -- 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
Problem with saa7134: Asus Tiger revision 1.0, subsys 1043:4857
I just bought a pair of what are a version of the My Cinema 7131 Hybrid cards. The kernel reports it as saa7134: Asus Tiger revision 1.0, subsys 1043:4857 I did inititially try Mythbuntu 10.04 but the firmware upload seemed to fail fairly consistently. Restarting with v10.10 the firmware loads but I can't seem to scan the channels with Mythbackend - it has a 0% signal and 100% signal to noise. I am using MythTV 0.24 with Avenard's latest patches. This version of the card has written on the silkscreen Tiger rev 3.02, a sticker that says Tiger_8M AA.F7.C0.01 (which would appear to be the latest firmware for this card on Asus's support site) but there is only one RF connector on CON1. CON2 is not fitted nor is the IR receiver. Now I saw mentioned on a list that to get DVB working on this card in Linux you need to connect the TV antenna to the FM port, which I suspect is the one not fitted. The latest Windows drivers for this card is circa 2009. Two questions: - Is there some sort of SAA7134 module argument I need to use to get this particular card working on the TV RF input? - Why does the kernel show the firmware is being reloaded every time MythTV seems to want to talk to the card? This slows down access as it seems to take about 30 seconds for the firmware to install each time. I am happy to provide whatever debug dumps or more info if need be. -- 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: Problem with saa7134: Asus Tiger revision 1.0, subsys 1043:4857
I'll add the following kernel debug info for what it's worth: - Mar 12 11:22:51 mythtv kernel: [ 14.025097] saa7130/34: v4l2 driver version 0.2.16 loaded Mar 12 11:22:51 mythtv kernel: [ 14.026609] saa7134 :00:09.0: PCI INT A - GSI 17 (level, low) - IRQ 17 Mar 12 11:22:51 mythtv kernel: [ 14.026617] saa7133[0]: found at :00:09.0, rev: 209, irq: 17, latency: 32, mmio: 0xec00 Mar 12 11:22:51 mythtv kernel: [ 14.026625] saa7133[0]: subsystem: 1043:4857, board: Asus Tiger Rev:1.00 [card=152,autodetected] Mar 12 11:22:51 mythtv kernel: [ 14.026649] saa7133[0]: board init: gpio is 0 Mar 12 11:22:51 mythtv kernel: [ 14.200257] saa7133[0]: i2c eeprom 00: 43 10 57 48 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 Mar 12 11:22:51 mythtv kernel: [ 14.200268] saa7133[0]: i2c eeprom 10: ff ff ff 0f ff 20 ff ff ff ff ff ff ff ff ff ff Mar 12 11:22:51 mythtv kernel: [ 14.200279] saa7133[0]: i2c eeprom 20: 01 40 01 02 03 01 01 03 08 ff 00 b6 ff ff ff ff Mar 12 11:22:51 mythtv kernel: [ 14.200288] saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Mar 12 11:22:51 mythtv kernel: [ 14.200298] saa7133[0]: i2c eeprom 40: ff 21 00 c2 96 10 03 32 15 00 ff ff ff ff ff ff Mar 12 11:22:51 mythtv kernel: [ 14.200307] saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Mar 12 11:22:51 mythtv kernel: [ 14.200316] saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Mar 12 11:22:51 mythtv kernel: [ 14.200326] saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Mar 12 11:22:51 mythtv kernel: [ 14.200335] saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Mar 12 11:22:51 mythtv kernel: [ 14.200344] saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Mar 12 11:22:51 mythtv kernel: [ 14.200354] saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Mar 12 11:22:51 mythtv kernel: [ 14.200363] saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Mar 12 11:22:51 mythtv kernel: [ 14.200372] saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Mar 12 11:22:51 mythtv kernel: [ 14.200382] saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Mar 12 11:22:51 mythtv kernel: [ 14.200391] saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Mar 12 11:22:51 mythtv kernel: [ 14.200400] saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Mar 12 11:22:51 mythtv kernel: [ 14.660189] tuner 1-004b: chip found @ 0x96 (saa7133[0]) Mar 12 11:22:56 mythtv kernel: [ 21.620280] saa7133[0]: registered device video0 [v4l2] Mar 12 11:22:56 mythtv kernel: [ 21.620403] saa7133[0]: registered device vbi0 Mar 12 11:22:56 mythtv kernel: [ 21.620513] saa7133[0]: registered device radio0 Mar 12 11:23:03 mythtv kernel: [ 28.860185] DVB: registering new adapter (saa7133[0]) - Now on the latest reboot I am getting the below. - Mar 12 11:24:13 mythtv kernel: [ 98.240211] DVB: registering adapter 0 frontend 0 (Philips TDA10046H DVB-T)... Mar 12 11:24:13 mythtv kernel: [ 98.48] tda1004x: setting up plls for 48MHz sampling clock Mar 12 11:24:15 mythtv kernel: [ 100.930007] tda1004x: found firmware revision 0 -- invalid Mar 12 11:24:15 mythtv kernel: [ 100.930012] tda1004x: trying to boot from eeprom Mar 12 11:24:16 mythtv kernel: [ 101.180011] tda1004x: found firmware revision 80 -- invalid Mar 12 11:24:16 mythtv kernel: [ 101.180017] tda1004x: firmware upload failed Mar 12 11:24:16 mythtv kernel: [ 102.14] tda1004x: setting up plls for 48MHz sampling clock Mar 12 11:24:18 mythtv kernel: [ 103.480013] tda1004x: found firmware revision 0 -- invalid Mar 12 11:24:18 mythtv kernel: [ 103.480018] tda1004x: waiting for firmware upload... Mar 12 11:24:19 mythtv kernel: [ 104.780010] tda1004x: found firmware revision 0 -- invalid Mar 12 11:24:19 mythtv kernel: [ 104.780015] tda1004x: trying to boot from eeprom Mar 12 11:24:22 mythtv kernel: [ 107.400011] tda1004x: found firmware revision 0 -- invalid Mar 12 11:24:22 mythtv kernel: [ 107.400016] tda1004x: waiting for firmware upload... Mar 12 11:25:22 mythtv kernel: [ 167.160013] tda1004x: found firmware revision 0 -- invalid Mar 12 11:25:22 mythtv kernel: [ 167.160021] tda1004x: firmware upload failed Mar 12 11:25:25 mythtv kernel: [ 170.840045] tda1004x: found firmware revision 80 -- invalid Mar 12 11:25:25 mythtv kernel: [ 170.840051] tda1004x: firmware upload failed -- A previous boot up had the card reporting: Nothing has changed between power cycles. - Mar 12 09:22:15 mythtv kernel: [ 67.010115] DVB: registering new adapter (saa7133[1]) Mar 12 09:22:15 mythtv kernel: [ 67.010121] DVB: registering adapter 0 frontend 0 (Philips TDA10046H DVB-T)... Mar 12 09:22:15 mythtv kernel: [ 67.170007] tda1004x: setting up plls for 48MHz sampling clock Mar 12 09:22:17
