From: wsa@the-dreams.de (Wolfram Sang)
To: linux-arm-kernel@lists.infradead.org
Subject: How to encode being an I2C slave in DT?
Date: Wed, 6 May 2015 18:17:12 +0200 [thread overview]
Message-ID: <20150506161712.GA4003@katana> (raw)
In-Reply-To: <554922EF.3050906@wwwdotorg.org>
> The container node has a #address-cells property for this very reason. It's
> perfectly well-defined how to split up a property containing a large number
> of cells into separate values, by using the value of #address-cells. Plus,
> the canonical formatting (albeit not enforced by the DT compiler) for a
> property that contains an array of entries, each 2 cells in size, would be:
>
> reg = <0 0x1a>, <0 0x40>, <0 0x48>;
>
> rather than:
>
> reg = <0 0x1a 0 0x40 0 0x48>;
>
> ... so it's quite simple to make it very human-readable too.
I give in to the flag idea. I also noticed that we'd need another flag
anyhow to mark 10 bit addresses. I am still thinking between using two
address-cells in that case (clean seperation between address and flags)
or to encode the flags as MSB in the current address (all busses will
have same address-cells and child description, less code paths and no
overhead in dtbs).
That being said, for the loopback testcase, the I2C slave framework will
need updates as well. I think I can cook up something. Will be
interesting to see if my hardware can do this. Has the loopback already
been tested on Tegra?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150506/faec8eb4/attachment-0001.sig>
next prev parent reply other threads:[~2015-05-06 16:17 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-30 20:00 [PATCH v2 0/4] arm: tegra: implement NVEC driver using tegra i2c Andrey Danin
2015-03-30 20:00 ` [PATCH v2 1/4] i2c: tegra: implement slave mode Andrey Danin
2015-04-03 19:46 ` Wolfram Sang
2015-07-20 9:50 ` Wolfram Sang
2015-03-30 20:00 ` [PATCH v2 2/4] staging/nvec: reimplement on top of tegra i2c driver Andrey Danin
2015-04-03 19:57 ` Wolfram Sang
2015-03-30 20:00 ` [PATCH v2 3/4] staging/nvec: remove old code Andrey Danin
2015-03-30 20:00 ` [PATCH v2 4/4] dt: paz00: define nvec as child of i2c bus Andrey Danin
2015-04-03 19:46 ` [PATCH v2 0/4] arm: tegra: implement NVEC driver using tegra i2c Wolfram Sang
2015-04-07 11:37 ` [PATCH v2 0/4] arm: tegra: implement NVEC driver using tegrai2c Marc Dietrich
2015-04-10 21:35 ` Wolfram Sang
[not found] ` <20150505105513.GA1841@katana>
2015-05-05 20:07 ` How to encode being an I2C slave in DT? Stephen Warren
2015-05-06 16:17 ` Wolfram Sang [this message]
2015-05-06 17:01 ` Stephen Warren
2015-05-19 0:37 ` Rob Herring
2015-05-19 6:16 ` Wolfram Sang
2015-07-16 9:03 ` Andrey Danin
2015-07-16 18:14 ` Wolfram Sang
2015-05-06 6:59 ` Uwe Kleine-König
2015-05-06 7:53 ` Marc Dietrich
2015-05-06 8:09 ` Uwe Kleine-König
2015-05-06 15:57 ` Stephen Warren
2015-05-06 17:47 ` Uwe Kleine-König
2015-05-06 18:35 ` 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=20150506161712.GA4003@katana \
--to=wsa@the-dreams.de \
--cc=linux-arm-kernel@lists.infradead.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).