From: Wolfram Sang <wsa@the-dreams.de>
To: Doug Anderson <dianders@chromium.org>
Cc: lee.jones@linaro.org, swarren@nvidia.com, abrestic@chromium.org,
dgreid@chromium.org, olof@lixom.net, sjg@chromium.org,
linux-samsung-soc@vger.kernel.org, linux-tegra@vger.kernel.org,
Vincent Palatin <vpalatin@chromium.org>,
robh+dt@kernel.org, pawel.moll@arm.com, mark.rutland@arm.com,
ijc+devicetree@hellion.org.uk, galak@codeaurora.org,
rdunlap@infradead.org, sameo@linux.intel.com, jdelvare@suse.de,
shane.huang@amd.com, maxime.ripard@free-electrons.com,
laurent.pinchart+renesas@ideasonboard.com,
u.kleine-koenig@pengutronix.de, bjorn.andersson@sonymobile.com,
kevin.strasser@linux.intel.com, linux@prisktech.co.nz,
andrew@lunn.ch, andriy.shevchenko@linux.intel.com,
schwidefsky@de.ibm.com, matt.porter@linaro.org,
ch.naveen@samsung.com, devicetree@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-i2c@vger.kernel.org
Subject: Re: [PATCH v2 6/7] i2c: ChromeOS EC tunnel driver
Date: Tue, 29 Apr 2014 14:33:28 +0200 [thread overview]
Message-ID: <20140429123328.GB3640@katana> (raw)
In-Reply-To: <1398185154-19404-7-git-send-email-dianders@chromium.org>
[-- Attachment #1: Type: text/plain, Size: 4674 bytes --]
Hi,
just a basic review to keep things rolling...
> On the original Samsung ARM Chromebook these devices were on an I2C
> bus that was shared between the AP and the EC and arbitrated using
> some extranal GPIOs (see i2c-arb-gpio-challenge).
>
> The original arbitration scheme worked well enough but had some
> downsides:
> * It was nonstandard (not using standard I2C multimaster)
> * It only worked if the EC-AP communication was I2C
> * It was relatively hard to debug problems (hard to tell if i2c issues
> were caused by the EC, the AP, or some device on the bus).
>
> On the HP Chromebook 11 the design was changed to:
This paragraph would be a nice update for the gpio-arbitration docs.
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt b/Documentation/devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt
The bindings should independently be sent to the devicetree list.
> new file mode 100644
> index 0000000..898f030
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt
> @@ -0,0 +1,39 @@
> +I2C bus that tunnels through the ChromeOS EC (cros-ec)
> +======================================================
> +On some ChromeOS board designs we've got a connection to the EC (embedded
> +controller) but no direct connection to some devices on the other side of
> +the EC (like a battery and PMIC). To get access to those devices we need
> +to tunnel our i2c commands through the EC.
> +
> +The node for this device should be under a cros-ec node like google,cros-ec-spi
> +or google,cros-ec-i2c.
> +
> +
> +Required properties:
> +- compatible: google,cros-ec-i2c-tunnel
> +- google,remote-bus: The EC bus we'd like to talk to.
> +
> +Optional child nodes:
> +- One node per I2C device connected to the tunnelled I2C bus.
> +
> +
> +Example:
> + cros-ec@0 {
> + compatible = "google,cros-ec-spi";
> +
> + ...
> +
> + i2c-tunnel {
> + compatible = "google,cros-ec-i2c-tunnel";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + google,remote-bus = <0>;
> +
> + battery: sbs-battery@b {
> + compatible = "sbs,sbs-battery";
> + reg = <0xb>;
> + sbs,poll-retry-count = <1>;
> + };
> + };
> + }
Can the tunnel have n busses? How to represent them then? I think the
remote-bus property should go in favor of proper sub-nodes? Wouldn't it
also be more generic to have the tunnel node seperate and reference the
tunnel-mechanism (spi here) as a phandle?
> +/**
> + * ec_i2c_construct_message - construct a message to go to the EC
> + *
> + * This function effectively stuffs the standard i2c_msg format of Linux into
> + * a format that the EC understands.
> + *
> + * @buf: The buffer to fill. Can pass NULL to count how many bytes the message
> + * would be.
I wonder about this NULL thing. That means the size is calculated twice.
Why not make two functions instead, one fir size calc, one for setting
up?
> +/**
> + * ec_i2c_parse_response - Parse a response from the EC
> + *
> + * We'll take the EC's response and copy it back into msgs.
> + *
> + * @buf: The buffer to parse. Can pass NULL to count how many bytes we expect
> + * the response to be. Otherwise we assume that the right number of
> + * bytes are available.
Ditto.
> + result = bus->ec->command_sendrecv(bus->ec, EC_CMD_I2C_PASSTHRU,
> + request, request_len,
> + response, response_len);
This function pointer should be checked against NULL in probe, I
think.
> +static int ec_i2c_probe(struct platform_device *pdev)
> +{
> + struct device_node *np = pdev->dev.of_node;
> + struct cros_ec_device *ec = dev_get_drvdata(pdev->dev.parent);
> + struct device *dev = &pdev->dev;
> + struct ec_i2c_device *bus = NULL;
> + u32 remote_bus;
> + int err;
> +
> + dev_dbg(dev, "Probing\n");
Drop. Device core has it already.
> +
> + if (!np) {
> + dev_err(dev, "no device node\n");
> + return -ENOENT;
> + }
Can this happen?
> +
> + bus = devm_kzalloc(dev, sizeof(*bus), GFP_KERNEL);
> + if (bus == NULL) {
> + dev_err(dev, "cannot allocate bus device\n");
No need for error strings when allocating.
> + return -ENOMEM;
> + }
> +
> + dev_dbg(dev, "ChromeOS EC I2C tunnel adapter\n");
Drop. Device core debug has it, too.
> +
> + return err;
> +}
> +
> +static int ec_i2c_remove(struct platform_device *dev)
> +{
> + struct ec_i2c_device *bus = platform_get_drvdata(dev);
> +
> + platform_set_drvdata(dev, NULL);
Not needed.
> +
> + i2c_del_adapter(&bus->adap);
> +
> + return 0;
> +}
> +
Regards,
Wolfram
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2014-04-29 12:33 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-22 16:45 [PATCH v2 0/7] Add cros_ec changes for newer boards Doug Anderson
2014-04-22 16:45 ` [PATCH v2 1/7] mfd: cros_ec: spi: calculate delay between transfers correctly Doug Anderson
2014-04-23 12:33 ` Lee Jones
2014-04-22 16:45 ` [PATCH v2 2/7] mfd: cros_ec: spi: Add mutex to cros_ec_spi Doug Anderson
2014-04-23 12:34 ` Lee Jones
2014-04-22 16:45 ` [PATCH v2 3/7] mfd: cros_ec: spi: Make the cros_ec_spi timeout more reliable Doug Anderson
2014-04-23 12:35 ` Lee Jones
2014-04-22 16:45 ` [PATCH v2 4/7] mfd: cros_ec: spi: Increase cros_ec_spi deadline from 5ms to 100ms Doug Anderson
2014-04-23 12:36 ` Lee Jones
2014-04-22 16:45 ` [PATCH v2 5/7] mfd: cros_ec: Sync to the latest cros_ec_commands.h from EC sources Doug Anderson
2014-04-23 12:36 ` Lee Jones
2014-04-22 16:45 ` [PATCH v2 6/7] i2c: ChromeOS EC tunnel driver Doug Anderson
2014-04-23 12:37 ` Lee Jones
2014-04-29 12:33 ` Wolfram Sang [this message]
2014-04-22 16:45 ` [PATCH v2 7/7] ARM: tegra: Add the EC i2c tunnel to tegra124-venice2 Doug Anderson
2014-04-23 12:32 ` [PATCH v2 0/7] Add cros_ec changes for newer boards Lee Jones
2014-04-23 16:20 ` Stephen Warren
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=20140429123328.GB3640@katana \
--to=wsa@the-dreams.de \
--cc=abrestic@chromium.org \
--cc=andrew@lunn.ch \
--cc=andriy.shevchenko@linux.intel.com \
--cc=bjorn.andersson@sonymobile.com \
--cc=ch.naveen@samsung.com \
--cc=devicetree@vger.kernel.org \
--cc=dgreid@chromium.org \
--cc=dianders@chromium.org \
--cc=galak@codeaurora.org \
--cc=ijc+devicetree@hellion.org.uk \
--cc=jdelvare@suse.de \
--cc=kevin.strasser@linux.intel.com \
--cc=laurent.pinchart+renesas@ideasonboard.com \
--cc=lee.jones@linaro.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=linux@prisktech.co.nz \
--cc=mark.rutland@arm.com \
--cc=matt.porter@linaro.org \
--cc=maxime.ripard@free-electrons.com \
--cc=olof@lixom.net \
--cc=pawel.moll@arm.com \
--cc=rdunlap@infradead.org \
--cc=robh+dt@kernel.org \
--cc=sameo@linux.intel.com \
--cc=schwidefsky@de.ibm.com \
--cc=shane.huang@amd.com \
--cc=sjg@chromium.org \
--cc=swarren@nvidia.com \
--cc=u.kleine-koenig@pengutronix.de \
--cc=vpalatin@chromium.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).