From: Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>
To: "Frank Schäfer" <fschaefer.oss-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: Q: i2c block write emulation / handling of i2c message size constraints of a bus ?
Date: Sun, 28 Oct 2012 16:33:42 +0100 [thread overview]
Message-ID: <20121028163342.48bc40aa@endymion.delvare> (raw)
In-Reply-To: <508D33E0.6070808-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
Hi Frank,
On Sun, 28 Oct 2012 15:32:16 +0200, Frank Schäfer wrote:
> Am 28.10.2012 14:03, schrieb Jean Delvare:
> > On Sat, 27 Oct 2012 18:41:19 +0300, Frank Schäfer wrote:
> >> What are the correct functionality flags to use in this case ?
> >> I2C_FUNC_I2C | I2C_FUNC_SMBUS_READ_BYTE | I2C_FUNC_SMBUS_WRITE_WORD_DATA ?
> > If your controller is limited then I2C_FUNC_I2C is most certainly
> > wrong. From what you described, I'd say:
> >
> > I2C_FUNC_SMBUS_READ_BYTE | I2C_FUNC_SMBUS_WRITE_BYTE_DATA
> >
> > This doesn't match what Laurent said about SCCB 4 months ago though:
> >
> > "The read transaction transmits 2 2-byte messages (addr/w, reg,
> > followed by addr/r, data)."
> >
> > You can take a look at Documentation/i2c/smbus-protocol to match
> > transactions to function names (and from there to I2C_FUNC flags.)
>
> Ok, I've been digging deeper into this but still don't understand the
> meaning of the functionality flags I2C_FUNC_*** with regards to the
> capabilites of an master_xfer implemetation in struct i2c_algortihm...
> Are they supposed to describe the smbus operations/methods that can be
> successfully emulated by the smbus layer using i2c_xfer or do they
> describe the actual capabilities of function master_xfer / the i2c adapter ?
Most I2C_FUNC_* flags actual refer to the smbus_xfer method. A driver
implementing master_xfer is typically fully I2C capable and can thus
run almost any I2C or SMBus transaction. Such a driver will set
functionality flags to I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL. The rest of
the flags are for SMBus-only controllers. Each flag basically
corresponds to an i2c_smbus_*() function, which in turn corresponds to
the combination of an SMBus transaction type or size and a direction
(read or write).
The mapping between i2c_smbus_*() functions and functionality flags is
rather obvious, but for clarity I'll update
Documentation/i2c/smbus-protocol to mention it. Patch follows.
Also see Documentation/i2c/functionality for a detailed explanation of
how functionality flags work both on the I2C/SMBus adapter driver and
the I2C device driver sides.
--
Jean Delvare
next prev parent reply other threads:[~2012-10-28 15:33 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-27 14:17 Q: i2c block write emulation / handling of i2c message size constraints of a bus ? Frank Schäfer
[not found] ` <508BECFE.2010302-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
2012-10-27 15:50 ` Jean Delvare
[not found] ` <20121027175030.0474249b-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
2012-10-27 15:41 ` Frank Schäfer
[not found] ` <508C009F.30107-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
2012-10-28 12:03 ` Jean Delvare
[not found] ` <20121028130301.64f032ff-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
2012-10-28 13:32 ` Frank Schäfer
[not found] ` <508D33E0.6070808-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
2012-10-28 15:33 ` Jean Delvare [this message]
[not found] ` <20121028163342.48bc40aa-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
2012-10-28 15:25 ` Frank Schäfer
[not found] ` <508D4E5F.4070209-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
2012-10-28 17:39 ` Jean Delvare
[not found] ` <20121028183913.79ad5ae3-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
2012-10-29 15:24 ` Frank Schäfer
[not found] ` <508E9FA0.4000505-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
2012-10-29 17:27 ` Jean Delvare
2012-10-28 15:11 ` Laurent Pinchart
2012-10-28 14:37 ` Frank Schäfer
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=20121028163342.48bc40aa@endymion.delvare \
--to=khali-puyad+kwke1g9huczpvpmw@public.gmane.org \
--cc=fschaefer.oss-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org \
--cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.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;
as well as URLs for NNTP newsgroup(s).