linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Wolfram Sang <wsa@the-dreams.de>
To: linux-i2c@vger.kernel.org
Cc: linux-mips@linux-mips.org, Wolfram Sang <wsa@the-dreams.de>,
	linux-kernel@vger.kernel.org,
	Ludovic Desroches <ludovic.desroches@atmel.com>,
	Yingjoe Chen <yingjoe.chen@mediatek.com>,
	linuxppc-dev@lists.ozlabs.org,
	linux-arm-kernel@lists.infradead.org
Subject: [RFC 01/11] i2c: add quirk structure to describe adapter flaws
Date: Fri,  9 Jan 2015 18:21:31 +0100	[thread overview]
Message-ID: <1420824103-24169-2-git-send-email-wsa@the-dreams.de> (raw)
In-Reply-To: <1420824103-24169-1-git-send-email-wsa@the-dreams.de>

The number of I2C adapters which are not fully I2C compatible is rising,
sadly. Drivers usually do handle the flaws, still the user receives only
some errno for a transfer which normally can be expected to work. This
patch introduces a formal description of flaws. One advantage is that
the core can check before the actual transfer if the messages could be
transferred at all. This is done in the next patch. Another advantage is
that we can pass this information to the user so the restrictions are
exactly known and further actions can be based on that. This will be
done later after some stabilization period for this description.

Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
---
 include/linux/i2c.h | 35 +++++++++++++++++++++++++++++++++++
 1 file changed, 35 insertions(+)

diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index e3a1721c8354..f8a642713706 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -447,6 +447,40 @@ int i2c_recover_bus(struct i2c_adapter *adap);
 int i2c_generic_gpio_recovery(struct i2c_adapter *adap);
 int i2c_generic_scl_recovery(struct i2c_adapter *adap);
 
+/**
+ * struct i2c_adapter_quirks - describe flaws of an i2c adapter
+ * @flags: see I2C_ADAPTER_QUIRK_* for possible flags
+ * @max_num_msgs: maximum number of messages per transfer
+ * @max_write_len: maximum length of a write message
+ * @max_read_len: maximum length of a read message
+ * @max_comb_write_len: maximum length of a write in a combined message
+ * @max_comb_read_len: maximum length of a read in a combined message
+ *
+ * Note about combined messages: Some I2C controllers can only send one
+ * message per transfer, plus something called combined message or
+ * write-then-read. This is a (usually) small write message followed by
+ * a read message and barely enough to access register based slaves like
+ * EEPROMs. There is a flag to support this mode. It implies max_num_msg = 2
+ * and does the length checks with max_comb_*_len because combined message mode
+ * usually has its own limitations. Read/write flags of the messages are also
+ * checked to be proper. Because of HW implementation, some controllers can
+ * actually do write-then-anything. To support that, write-then-read has been
+ * broken out into write-first and read-second.
+ */
+struct i2c_adapter_quirks {
+	u64 flags;
+	int max_num_msgs;
+	u16 max_write_len;
+	u16 max_read_len;
+	u16 max_comb_write_len;
+	u16 max_comb_read_len;
+};
+
+#define I2C_ADAPTER_QUIRK_COMB_WRITE_FIRST	BIT(0)
+#define I2C_ADAPTER_QUIRK_COMB_READ_SECOND	BIT(1)
+#define I2C_ADAPTER_QUIRK_COMB_WRITE_THEN_READ	(I2C_ADAPTER_QUIRK_COMB_WRITE_FIRST | \
+						I2C_ADAPTER_QUIRK_COMB_READ_SECOND)
+
 /*
  * i2c_adapter is the structure used to identify a physical i2c bus along
  * with the access algorithms necessary to access it.
@@ -472,6 +506,7 @@ struct i2c_adapter {
 	struct list_head userspace_clients;
 
 	struct i2c_bus_recovery_info *bus_recovery_info;
+	struct i2c_adapter_quirks *quirks;
 };
 #define to_i2c_adapter(d) container_of(d, struct i2c_adapter, dev)
 
-- 
2.1.3

  reply	other threads:[~2015-01-09 17:22 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-09 17:21 [RFC 00/11] i2c: add generic quirk infrastructure Wolfram Sang
2015-01-09 17:21 ` Wolfram Sang [this message]
2015-01-16  5:50   ` [RFC 01/11] i2c: add quirk structure to describe adapter flaws Eddie Huang
2015-01-19 15:05     ` Wolfram Sang
2015-02-24 16:04       ` Wolfram Sang
2015-01-16  8:18   ` Yingjoe Chen
2015-01-19 15:00     ` Wolfram Sang
2015-01-09 17:21 ` [RFC 02/11] i2c: add quirk checks to core Wolfram Sang
2015-01-09 19:35   ` Sergei Shtylyov
2015-01-09 20:45     ` Wolfram Sang
2015-01-09 21:05       ` Sergei Shtylyov
2015-01-12  9:58   ` Ludovic Desroches
2015-01-12 10:13     ` Wolfram Sang
2015-01-12 12:08   ` Russell King - ARM Linux
2015-02-24 14:25     ` Wolfram Sang
2015-01-12 13:15   ` Matthias Brugger
2015-02-24 14:16     ` Wolfram Sang
2015-01-09 17:21 ` [RFC 03/11] i2c: at91: make use of the new infrastructure for quirks Wolfram Sang
2015-01-09 17:21 ` [RFC 04/11] i2c: opal: " Wolfram Sang
2015-01-09 17:21 ` [RFC 05/11] i2c: qup: " Wolfram Sang
2015-01-09 17:21 ` [RFC 06/11] i2c: cpm: " Wolfram Sang
2015-01-09 17:21 ` [RFC 07/11] i2c: axxia: " Wolfram Sang
2015-01-09 17:21 ` [RFC 08/11] i2c: dln2: " Wolfram Sang
2015-01-09 17:21 ` [RFC 09/11] i2c: powermac: " Wolfram Sang
2015-01-09 17:21 ` [RFC 10/11] i2c: viperboard: " Wolfram Sang
2015-01-09 17:21 ` [RFC 11/11] i2c: pmcmsp: " Wolfram Sang

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=1420824103-24169-2-git-send-email-wsa@the-dreams.de \
    --to=wsa@the-dreams.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=ludovic.desroches@atmel.com \
    --cc=yingjoe.chen@mediatek.com \
    /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).