From: Antti Palosaari <crope@iki.fi>
To: Andrew de Quincey <adq_dvb@lidskialf.net>
Cc: linux-media@vger.kernel.org
Subject: Re: [patch] Fix AF9015 Dual tuner i2c write failures
Date: Sat, 05 Mar 2011 00:59:22 +0200 [thread overview]
Message-ID: <4D716ECA.4060900@iki.fi> (raw)
In-Reply-To: <AANLkTimjC99zhJ=huHZiGgbENCoyHy5KT87iujjTT8w3@mail.gmail.com>
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;
> 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.
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.
Antti
--
http://palosaari.fi/
next prev parent reply other threads:[~2011-03-04 22:59 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-04 21:37 [patch] Fix AF9015 Dual tuner i2c write failures Andrew de Quincey
2011-03-04 22:13 ` Antti Palosaari
2011-03-04 22:44 ` Andrew de Quincey
2011-03-04 22:59 ` Antti Palosaari [this message]
2011-03-04 23:11 ` Andrew de Quincey
2011-03-05 1:43 ` adq
2011-03-05 1:51 ` adq
[not found] ` <AANLkTi=YMtTbgwxNA1O6zp03OoeGKJvn8oYDB9kHjti1@mail.gmail.com>
2011-03-05 9:23 ` Antti Palosaari
2011-03-05 11:56 ` Andrew de Quincey
2011-03-05 11:55 ` adq
2011-03-06 11:56 ` adq
2011-03-06 12:24 ` adq
2011-03-06 13:04 ` Antti Palosaari
2011-03-06 13:08 ` adq
2011-03-06 13:24 ` adq
2011-03-07 18:26 ` adq
2011-03-07 22:12 ` adq
2011-03-18 15:46 ` Antti Palosaari
2011-03-21 20:11 ` adq
2011-04-02 1:24 ` adq
2011-04-02 8:20 ` Antti Palosaari
2011-04-02 11:06 ` adq
2011-04-02 11:15 ` adq
2011-04-02 12:18 ` Antti Palosaari
2011-04-02 13:45 ` adq
2011-04-02 17:24 ` Antti Palosaari
2011-03-05 9:56 ` Antti Palosaari
2011-03-05 10:49 ` Antti Palosaari
2011-03-22 9:00 ` Mauro Carvalho Chehab
2011-03-22 18:26 ` adq
2011-03-22 18:36 ` Mauro Carvalho Chehab
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D716ECA.4060900@iki.fi \
--to=crope@iki.fi \
--cc=adq_dvb@lidskialf.net \
--cc=linux-media@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox