Perhaps it depends on the characteristics of the transmissions being received? I'm in the UK. 2011/3/5 Antti Palosaari <crope@xxxxxx>: > Switching channels for long time seems to hang device (no errors seen but it > does not lock anymore), I don't know why. It is not very easy to reproduce. > For me it will take generally few days just tune from channel to channel in > loop. > > Antti > > On 03/05/2011 10:56 AM, Juan Jesús García de Soria Lucena wrote: >> >> Hi, Andrew. >> >> This is what happens to me with both the KWorld dual tuner (when using >> only >> one tuner) and the Avermedia Volar Black (single tuner), both based on >> AF9015. >> >> I also got corrupted streams with the KWorld when capturing via both >> tuners >> (the video our the audio would show artifacts in mythtv each several >> seconds). >> >> As far as the loss of tuning ability goes, I think it's a problem related >> to >> tuning itself, since it wouldn't happen when you just left a channel tuned >> and streaming in a simple client, but would trigger after a random time >> when >> you left mythtv scanning the channels for EIT data. >> >> I don't think it's a problem with a specific HW implementation, since I >> got >> it with both AF9015-based cards. It could be either a chipset quirk our a >> bug in the driver. >> >> My informal and quick tests with Windows Media Center and these cards did >> not reproduce the problem, when trying to change channels as quickly as >> possible, admittedly for not so long a time. >> >> Best regards, >> Juan Jesus. >> El 05/03/2011 02:53, "adq"<adq@xxxxxxxxxxxxx> escribió: >>> >>> On 5 March 2011 01:43, adq<adq@xxxxxxxxxxxxx> wrote: >>>> >>>> On 4 March 2011 23:11, Andrew de Quincey<adq_dvb@xxxxxxxxxxxxx> wrote: >>>>> >>>>> On 4 March 2011 22:59, Antti Palosaari<crope@xxxxxx> wrote: >>>>>> >>>>>> On 03/05/2011 12:44 AM, Andrew de Quincey wrote: >>>>>>>>> >>>>>>>>> Adding a "bus lock" to af9015_i2c_xfer() will not work as >> >> demod/tuner >>>>>>>>> >>>>>>>>> accesses will take multiple i2c transactions. >>>>>>>>> >>>>>>>>> Therefore, the following patch overrides the dvb_frontend_ops >>>>>>>>> functions to add a per-device lock around them: only one frontend >> >> can >>>>>>>>> >>>>>>>>> now use the i2c bus at a time. Testing with the scripts above shows >>>>>>>>> this has eliminated the errors. >>>>>>>> >>>>>>>> This have annoyed me too, but since it does not broken functionality >> >> much >>>>>>>> >>>>>>>> I >>>>>>>> haven't put much effort for fixing it. I like that fix since it is >>>>>>>> in >>>>>>>> AF9015 >>>>>>>> driver where it logically belongs to. But it looks still rather >> >> complex. >>>>>>>> >>>>>>>> I >>>>>>>> see you have also considered "bus lock" to af9015_i2c_xfer() which >> >> could >>>>>>>> >>>>>>>> be >>>>>>>> much smaller in code size (that's I have tried to implement long >>>>>>>> time >>>>>>>> back). >>>>>>>> >>>>>>>> I would like to ask if it possible to check I2C gate open / close >> >> inside >>>>>>>> >>>>>>>> af9015_i2c_xfer() and lock according that? Something like: >>>>>>> >>>>>>> Hmm, I did think about that, but I felt overriding the functions was >>>>>>> just cleaner: I felt it was more obvious what it was doing. Doing >>>>>>> exactly this sort of tweaking was one of the main reasons we added >>>>>>> that function overriding feature. >>>>>>> >>>>>>> I don't like the idea of returning "error locked by FE" since that'll >>>>>>> mean the tuning will randomly fail sometimes in a way visible to >>>>>>> userspace (unless we change the core dvb_frontend code), which was >>>>>>> one >>>>>>> of the things I was trying to avoid. Unless, of course, I've >>>>>>> misunderstood your proposal. >>>>>> >>>>>> Not returning error, but waiting in lock like that: >>>>>> if (mutex_lock_interruptible(&d->i2c_mutex)< 0) >>>>>> return -EAGAIN; >>>>> >>>>> Ah k, sorry >>>>> >>>>>>> However, looking at the code again, I realise it is possible to >>>>>>> simplify it. Since its only the demod gates that cause a problem, we >>>>>>> only /actually/ need to lock the get_frontend() and set_frontend() >>>>>>> calls. >>>>>> >>>>>> I don't understand why .get_frontend() causes problem, since it does >> >> not >>>>>> >>>>>> access tuner at all. It only reads demod registers. The main problem >>>>>> is >>>>>> (like schema in af9015.c shows) that there is two tuners on same I2C >> >> bus >>>>>> >>>>>> using same address. And demod gate is only way to open access for >> >> desired >>>>>> >>>>>> tuner only. >>>>> >>>>> AFAIR /some/ tuner code accesses the tuner hardware to read the exact >>>>> tuned frequency back on a get_frontend(); was just being extra >>>>> paranoid :) >>>>> >>>>>> You should block traffic based of tuner not demod. And I think those >>>>>> callbacks which are needed for override are tuner driver callbacks. >> >> Consider >>>>>> >>>>>> situation device goes it v4l-core calls same time both tuner .sleep() >> >> == >>>>>> >>>>>> problem. >>>>> >>>>> Hmm, yeah, you're right, let me have another look tomorrow. >>>>> >>>> >>>> Hi, must admit I misunderstood your diagram originally, I thought it >>>> was the demods AND the tuners that had the same i2c addresses. >>>> >>>> As you say though. its just the tuners, so adding the locking into the >>>> gate ctrl as you suggested makes perfect sense. Attached is v3 >>>> implementing this; it seems to be working fine here. >>>> >>> >>> Unfortunately even with this fix, I'm still seeing the problem I was >>> trying to fix to begin with. >>> >>> Although I no longer get any i2c errors (or *any* reported errors), >>> after a bit, one of the frontends just.. stops working. All attempts >>> to tune it fail. I can even unload and reload the driver module, and >>> its stuck in the same state, indicating its a problem with the >>> hardware. :( >>> -- >>> To unsubscribe from this list: send the line "unsubscribe linux-media" in >>> the body of a message to majordomo@xxxxxxxxxxxxxxx >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > > > -- > http://palosaari.fi/ > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
