From: Jean Delvare <khali@linux-fr.org>
To: Krzysztof Halasa <khc@pm.waw.pl>
Cc: LM Sensors <lm-sensors@lm-sensors.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: I2C block reads with i2c-viapro: testers wanted
Date: Thu, 11 Aug 2005 23:49:46 +0200 [thread overview]
Message-ID: <20050811234946.0106afbe.khali@linux-fr.org> (raw)
In-Reply-To: <m3iryctaou.fsf@defiant.localdomain>
Hi Krzysztof,
> > However,
> > EEPROMs are also often found on SMBus busses, those controller only
> > implement a subset of all possible I2C commands.
>
> You mean one can't drive clock and data lines at will, and the
> controller (some hardware) does it instead, based on commands received
> from the program (and, for example, the program interface is parallel,
> not 2-wire serial). Right?
Partly right. Actually, most SMBus controllers work the following way:
you program a number of registers (typically SMBus transaction type,
target chip address, target register address or command, and the data to
send in the case of a write transaction), then you tell the chip to
initiate the transaction. Then you poll for the transaction to be over
(or use an interupt, but most our SMBus drivers use polling), and read
the result in some register in the case of a read transaction.
> But wait, even then does the controller really know anything about
> I^2C commands? How would it differentiate between, say, 8-bit and
> 16-bit reads? Or is it just an 8-bit EEPROM bus?
No, it is still physically a 2-wire serial bus. The limitation is due to
the fast that the SMBus controller knows of a limited number of
transactions, such as Send Byte, Read Byte, Read Word etc. If the SMBus
controller doesn't know of the SMBus command you want to use (in my
case, I2C block read), then there is no way to do it, because we have no
direct control over the serial line.
> Does it do START and STOP automatically as well?
Absolutely. The good thing is that SMBus masters are not CPU intensive,
contrary to bit-banging I2C adapters.
--
Jean Delvare
next prev parent reply other threads:[~2005-08-11 21:49 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-09 21:13 I2C block reads with i2c-viapro: testers wanted Jean Delvare
2005-08-10 20:31 ` Hinko Kocevar
2005-08-10 21:06 ` Jean Delvare
2005-08-10 22:23 ` [lm-sensors] " Martin Drab
2005-08-11 17:12 ` Jean Delvare
2005-08-10 23:13 ` Hinko Kocevar
2005-08-11 16:56 ` Jean Delvare
2005-08-11 19:13 ` Krzysztof Halasa
2005-08-11 19:59 ` Jean Delvare
2005-08-11 21:39 ` Krzysztof Halasa
2005-08-11 21:49 ` Jean Delvare [this message]
2005-08-11 22:08 ` Krzysztof Halasa
2005-08-12 6:26 ` Jean Delvare
2005-08-12 15:29 ` Krzysztof Halasa
2005-08-12 17:58 ` Jean Delvare
2005-08-12 1:07 ` [lm-sensors] " Mark M. Hoffman
2005-08-12 6:02 ` Jean Delvare
-- strict thread matches above, loose matches on Subject: below --
2005-08-10 1:55 Salah Coronya
2005-08-10 10:06 ` Jean Delvare
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=20050811234946.0106afbe.khali@linux-fr.org \
--to=khali@linux-fr.org \
--cc=khc@pm.waw.pl \
--cc=linux-kernel@vger.kernel.org \
--cc=lm-sensors@lm-sensors.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