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,
Laurent Pinchart
<laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
Subject: Re: Q: i2c block write emulation / handling of i2c message size constraints of a bus ?
Date: Sun, 28 Oct 2012 13:03:01 +0100 [thread overview]
Message-ID: <20121028130301.64f032ff@endymion.delvare> (raw)
In-Reply-To: <508C009F.30107-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
Hi Frank,
On Sat, 27 Oct 2012 18:41:19 +0300, Frank Schäfer wrote:
> Am 27.10.2012 18:50, schrieb Jean Delvare:
> > On Sat, 27 Oct 2012 17:17:34 +0300, Frank Schäfer wrote:
> >> the i2c interface of my device is capable of writing 2 bytes (reg +
> >> data) and reading a single data byte only.
> > Are you talking about an I2C master (controller) here, or a slave
> > device?
>
> It's an em2765 USB-video-bridge with an OV2640 sensor slave.
> The i2c transfer functions I'm currently working on are not yet in the
> em28xx driver.
>
> I don't know yet if it is a general bus limitation or a client limitiation.
> The procedures are based on reverse-engineering work and the OV2640 is
> the only device we have seen so far.
> Maybe it has something to do with the fact that the OV2640 uses SCCB.
Yes SCCB is apparently very limited in terms of supported transaction
types. Plus it diverges from the equivalent SMBus transactions in the
details. Note that we do have support for SCCB since kernel v3.6
(commit d47726c52122d64253ae56e0fafdb7d0b954e97c by Laurent Pinchart.)
> (...)
> Yes, emulating block reads/writes internally (the em28xx driver in this
> case) is not the problem.
> My question was if it makes sense to export the emulation through the
> i2c subsystem.
If you do, you'll have to make it flexible enough that it can be used
by other drivers, such as at24 and eeprom.
> >> What's the right error code to return from the drivers master_xfer
> >> function if the message length is not supported ? -EMSGSIZE ?
> > -EOPNOTSUPP, per Documentation/i2c/fault-codes.
> >
> > Note that ideally, the slave driver should check the bus functionality
> > and not try transactions which aren't supported. So returning
> > -EOPNOTSUPP normally never happens.
>
> 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.)
--
Jean Delvare
next prev parent reply other threads:[~2012-10-28 12:03 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 [this message]
[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
[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=20121028130301.64f032ff@endymion.delvare \
--to=khali-puyad+kwke1g9huczpvpmw@public.gmane.org \
--cc=fschaefer.oss-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org \
--cc=laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@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).