From: Doug Anderson <dianders@chromium.org>
To: Lee Jones <lee.jones@linaro.org>,
Wolfram Sang <wsa@the-dreams.de>, Mark Brown <broonie@kernel.org>
Cc: Vincent Palatin <vpalatin@chromium.org>,
Bill Richardson <wfrichar@chromium.org>,
Randall Spangler <rspangler@chromium.org>,
sjg@chromium.org, afaerber@suse.de, stephan@synkhronix.com,
olof@lixom.net, Doug Anderson <dianders@chromium.org>,
linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH 3/3] i2c: cros_ec: Support a limited i2c tunnel for exynos5250-spring
Date: Fri, 27 Jun 2014 12:56:13 -0700 [thread overview]
Message-ID: <1403898973-19571-4-git-send-email-dianders@chromium.org> (raw)
In-Reply-To: <1403898973-19571-1-git-send-email-dianders@chromium.org>
On exynos5250-spring the battery and tps65090 regulator are sitting on
an i2c bus behind the EC (much like on exynos5420-peach-pit). However
on spring we don't have the full EC_CMD_I2C_PASSTHRU command.
For the production kernel of spring we used a solution like this:
- Fork the tps65090 driver and make a version that talks straight to
the cros_ec MFD driver and sends special EC commands for talking to
the regulator.
- Add code into the i2c tunnel to look for i2c transfers and convert
them into special EC commands for talking to the battery.
For reference:
* http://crosreview.com/66116
* https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/drivers/regulator/cros_ec-tps65090.c
The above solution works great but is a bunch of code. It appears
that we can make do with the limited i2c passthrough commands that
actually happened to be present on the exynos5250-spring EC. Doing
this we can present ourselves as supporting a small subset of smbus.
We might need to do a few extra transfers here and there but we don't
need any extra code.
Seriss-cc: linux-samsung-soc
Signed-off-by: Doug Anderson <dianders@chromium.org>
---
drivers/i2c/busses/i2c-cros-ec-tunnel.c | 92 ++++++++++++++++++++++++++++++++-
1 file changed, 91 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-cros-ec-tunnel.c b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
index 6d7d009..c52c491 100644
--- a/drivers/i2c/busses/i2c-cros-ec-tunnel.c
+++ b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
@@ -38,6 +38,76 @@ struct ec_i2c_device {
u8 response_buf[256];
};
+static int ec_smbus_xfer(struct i2c_adapter *adap, u16 addr,
+ unsigned short flags, char read_write,
+ u8 command, int size, union i2c_smbus_data *data)
+{
+ struct ec_i2c_device *bus = adap->algo_data;
+ struct cros_ec_command msg = {};
+ int result;
+
+ if (read_write == I2C_SMBUS_WRITE) {
+ struct ec_params_i2c_write params;
+
+ params.addr = addr << 1;
+ params.port = bus->remote_bus;
+ params.offset = command;
+
+ if (size == I2C_SMBUS_WORD_DATA) {
+ params.data = data->word;
+ params.write_size = 16;
+ } else if (size == I2C_SMBUS_BYTE_DATA) {
+ params.data = data->byte;
+ params.write_size = 8;
+ } else {
+ return -EINVAL;
+ }
+
+ msg.command = EC_CMD_I2C_WRITE;
+ msg.outdata = (uint8_t *)¶ms;
+ msg.outsize = sizeof(params);
+
+ result = bus->ec->cmd_xfer(bus->ec, &msg);
+ if (result < 0)
+ return -EIO;
+
+ return 0;
+ } else if (read_write == I2C_SMBUS_READ) {
+ struct ec_params_i2c_read params;
+ struct ec_response_i2c_read response;
+
+ params.addr = addr << 1;
+ params.port = bus->remote_bus;
+ params.offset = command;
+
+ if (size == I2C_SMBUS_WORD_DATA)
+ params.read_size = 16;
+ else if (size == I2C_SMBUS_BYTE_DATA)
+ params.read_size = 8;
+ else
+ return -EINVAL;
+
+ msg.command = EC_CMD_I2C_READ;
+ msg.outdata = (uint8_t *)¶ms;
+ msg.outsize = sizeof(params);
+ msg.indata = (uint8_t *)&response;
+ msg.insize = sizeof(response);
+
+ result = bus->ec->cmd_xfer(bus->ec, &msg);
+ if (result < 0)
+ return -EIO;
+
+ if (size == I2C_SMBUS_WORD_DATA)
+ data->word = response.data;
+ else
+ data->byte = response.data;
+
+ return 0;
+ }
+
+ return -EINVAL;
+}
+
/**
* ec_i2c_count_message - Count bytes needed for ec_i2c_construct_message
*
@@ -233,6 +303,11 @@ static int ec_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg i2c_msgs[],
if (result < 0)
goto exit;
+ if (msg.result == EC_RES_INVALID_COMMAND) {
+ result = -EINVAL;
+ goto exit;
+ }
+
result = ec_i2c_parse_response(response, i2c_msgs, &num);
if (result < 0)
goto exit;
@@ -258,6 +333,16 @@ static const struct i2c_algorithm ec_i2c_algorithm = {
.functionality = ec_i2c_functionality,
};
+static u32 ec_smbus_functionality(struct i2c_adapter *adap)
+{
+ return I2C_FUNC_SMBUS_BYTE_DATA | I2C_FUNC_SMBUS_WORD_DATA;
+}
+
+static const struct i2c_algorithm ec_i2c_limited_algorithm = {
+ .smbus_xfer = ec_smbus_xfer,
+ .functionality = ec_smbus_functionality,
+};
+
static int ec_i2c_probe(struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
@@ -288,11 +373,16 @@ static int ec_i2c_probe(struct platform_device *pdev)
bus->adap.owner = THIS_MODULE;
strlcpy(bus->adap.name, "cros-ec-i2c-tunnel", sizeof(bus->adap.name));
- bus->adap.algo = &ec_i2c_algorithm;
bus->adap.algo_data = bus;
bus->adap.dev.parent = &pdev->dev;
bus->adap.dev.of_node = np;
+ /* Test if we can support full passthrough or just limited */
+ if (ec_i2c_xfer(&bus->adap, NULL, 0) == 0)
+ bus->adap.algo = &ec_i2c_algorithm;
+ else
+ bus->adap.algo = &ec_i2c_limited_algorithm;
+
err = i2c_add_adapter(&bus->adap);
if (err) {
dev_err(dev, "cannot register i2c adapter\n");
--
2.0.0.526.g5318336
next prev parent reply other threads:[~2014-06-27 19:58 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-27 19:56 [PATCH 0/3] Add support for limited i2c tunnel for exynos5250-spring Doug Anderson
2014-06-27 19:56 ` [PATCH 1/3] regmap: cache: regcache_hw_init() should use regmap_bulk_read() Doug Anderson
2014-07-03 14:55 ` Mark Brown
2014-06-27 19:56 ` [PATCH 2/3] mfd: cros_ec: Use the proper size when looking at the cros_ec_i2c result Doug Anderson
2014-06-30 19:36 ` Simon Glass
2014-07-02 7:23 ` Lee Jones
2014-07-02 15:51 ` Doug Anderson
2014-07-03 6:38 ` Lee Jones
2014-06-27 19:56 ` Doug Anderson [this message]
2014-06-27 21:44 ` [PATCH 3/3] i2c: cros_ec: Support a limited i2c tunnel for exynos5250-spring Doug Anderson
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=1403898973-19571-4-git-send-email-dianders@chromium.org \
--to=dianders@chromium.org \
--cc=afaerber@suse.de \
--cc=broonie@kernel.org \
--cc=lee.jones@linaro.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=olof@lixom.net \
--cc=rspangler@chromium.org \
--cc=sjg@chromium.org \
--cc=stephan@synkhronix.com \
--cc=vpalatin@chromium.org \
--cc=wfrichar@chromium.org \
--cc=wsa@the-dreams.de \
/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).