David Miller wrote:
On Thu, Aug 21, 2008 at 12:10:12AM -0700, David Miller wrote:
2) When CONFIG_SPARC, shift the device address down by one bit before
giving it to the Linux I2C layer.
Maybe we should distinguish by the type of I2C bus node instead.
How so? If a Sparc and a PowerPC system use similar I2C
controllers, we risk double matches.
It's not really an instruction-set architecture issue, it's a binding
issue. What if a non-OF embedded SPARC comes along that copies i2c from
a PowerPC DTS file, or we come across a real-OF PowerPC that does it the
SPARC way?
If we do come across two systems that claim their i2c bus nodes are
compatible but use different bindings, *then* we'll find some
out-of-band information to disambiguate.
If you guys created this format in your compressed openfirmware
trees, is it possible for you to "fix" it to match what Sparc
systems following the proper bindings do?
Possibly, though it'll cause some pain when old trees are used with a
kernel that expects the new binding.
You mentioned having an actual binding document for I2C on Open
Firmware; is it available online anywhere?
Don't PowerMACs and such have I2C controllers and devices?
How do they encode these I2C client device reg properties?
As far as I can tell from poking around
http://penguinppc.org/historical/dev-trees-html/, they don't include reg
at all for i2c clients.
-Scott
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
