From: Antti Palosaari <crope@iki.fi>
To: Peter Rosin <peda@lysator.liu.se>, linux-media@vger.kernel.org
Cc: Peter Rosin <peda@axentia.se>, linux-i2c@vger.kernel.org
Subject: Re: [PATCH] si2168: use i2c controlled mux interface
Date: Tue, 5 Apr 2016 17:50:43 +0300 [thread overview]
Message-ID: <5703D0C3.7010201@iki.fi> (raw)
In-Reply-To: <56F2CB4D.4030104@lysator.liu.se>
On 03/23/2016 06:58 PM, Peter Rosin wrote:
> On 2016-01-06 06:42, Antti Palosaari wrote:
>> Recent i2c mux locking update offers support for i2c controlled i2c
>> muxes. Use it and get the rid of homemade hackish i2c adapter
>> locking code.
>
> [actual patch elided]
>
> I had a 2nd look and it seems that the saa7164 driver has support for
> a HVR2055 card with dual si2168 chips. These two chips appear to sit
> on the same i2c-bus with different i2c-addresses (0x64 and 0x66) and
> with gates (implemented as muxes) to two identical tuners with the
> same i2c-address (0x60). Do I read it right?
saa7164 has 3 different I2C adapters.
saa7164 I2C bus #0:
* eeprom
* Si2157 #1
saa7164 I2C bus #1:
* Si2157 #2
saa7164 I2C bus #2:
* Si2168 #1
* Si2168 #2
So both of the Si2157 tuners could have same addresses.
(It is Hauppauge WinTV-HVR2205, not HVR-2055).
> With the current i2c-mux-locking (parent-locked muxes), this works
> fine as an access to one of the tuners locks the root i2c adapter
> and thus the other tuner is also locked out. But with the upcoming
> i2c-mux-locking for i2c-controlled muxes (self-locked muxes), the
> root i2c adapter would no longer be locked for the full transaction
> when one of the tuners is accessed. This means that accesses to the
> two tuners may interleave and cause all kinds of trouble, should
> both gates be open at the same time. So, is it really correct and
> safe to change the si2168 driver to use a self-locked mux?
>
> Unless there is some other mechanism that prevents the two tuners
> from being accessed in parallel, I think not. But maybe there is such
> a mechanism?
Good point. Actually there is pretty often this kind of configuration
used for those dual tuner devices and it will cause problems...
Currently all of those implements hackish i2c_gate_ctrl() callback to
switch mux.
____________ ____________ ____________
|I2C-adapter | | I2C-mux | | I2C-client |
|------------| |------------| |------------|
| | | addr 0x1c | | addr 0x60 |
| | | | | |
| |-+-I2C---|-----/ -----|---I2C---| |
|____________| | |____________| |____________|
| ____________ ____________
| | I2C-mux | | I2C-client |
| |------------| |------------|
| | addr 0x1d | | addr 0x60 |
| | | | |
+-I2C---|-----/ -----|---I2C---| |
|____________| |____________|
regards
Antti
--
http://palosaari.fi/
next prev parent reply other threads:[~2016-04-05 14:50 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1452058920-9797-1-git-send-email-crope@iki.fi>
2016-03-23 16:58 ` [PATCH] si2168: use i2c controlled mux interface Peter Rosin
2016-04-05 14:50 ` Antti Palosaari [this message]
2016-04-05 15:38 ` Peter Rosin
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=5703D0C3.7010201@iki.fi \
--to=crope@iki.fi \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=peda@axentia.se \
--cc=peda@lysator.liu.se \
/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;
as well as URLs for NNTP newsgroup(s).