From: Peter Rosin <peda@lysator.liu.se>
To: Antti Palosaari <crope@iki.fi>, 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: Wed, 23 Mar 2016 17:58:53 +0100 [thread overview]
Message-ID: <56F2CB4D.4030104@lysator.liu.se> (raw)
In-Reply-To: <1452058920-9797-1-git-send-email-crope@iki.fi>
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?
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?
Cheers,
Peter
next parent reply other threads:[~2016-03-23 16:59 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 ` Peter Rosin [this message]
2016-04-05 14:50 ` [PATCH] si2168: use i2c controlled mux interface Antti Palosaari
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=56F2CB4D.4030104@lysator.liu.se \
--to=peda@lysator.liu.se \
--cc=crope@iki.fi \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=peda@axentia.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).