-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge branch 'i2c/for-next' of git://git.kernel.org/pub/scm/linux/ker…
…nel/git/wsa/linux Pull i2c changes from Wolfram Sang: - an arbitration driver. While the driver is quite simple, it caused discussion if we need additional arbitration on top of the one specified in the I2C standard. Conclusion is that I accept a few generic mechanisms, but not very specific ones. - the core lost the detach_adapter() call. It has no users anymore and was in the way for other cleanups. attach_adapter() is sadly still there since there are users waiting to be converted. - the core gained a bus recovery infrastructure. I2C defines a way to recover if the data line is stalled. This mechanism is now in the core and drivers can now pass some data to make use of it. - bigger driver cleanups for designware, s3c2410 - removing superfluous refcounting from drivers - removing Ben Dooks as second maintainer due to inactivity. Thanks for all your work so far, Ben! - bugfixes, feature additions, devicetree fixups, simplifications... * 'i2c/for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: (38 commits) i2c: xiic: must always write 16-bit words to TX_FIFO i2c: octeon: use HZ in timeout value i2c: octeon: Fix i2c fail problem when a process is terminated by a signal i2c: designware-pci: drop superfluous {get|put}_device i2c: designware-plat: drop superfluous {get|put}_device i2c: davinci: drop superfluous {get|put}_device MAINTAINERS: Ben Dooks is inactive regarding I2C i2c: mux: Add i2c-arb-gpio-challenge 'mux' driver i2c: at91: convert to dma_request_slave_channel_compat() i2c: mxs: do error checking and handling in PIO mode i2c: mxs: remove races in PIO code i2c-designware: switch to use runtime PM autosuspend i2c-designware: use usleep_range() in the busy-loop i2c-designware: enable/disable the controller properly i2c-designware: use dynamic adapter numbering on Lynxpoint i2c-designware-pci: use managed functions pcim_* and devm_* i2c-designware-pci: use dev_err() instead of printk() i2c-designware: move to managed functions (devm_*) i2c: remove CONFIG_HOTPLUG ifdefs i2c: s3c2410: Add SMBus emulation for block read ...
- Loading branch information
Showing
42 changed files
with
960 additions
and
497 deletions.
There are no files selected for viewing
80 changes: 80 additions & 0 deletions
80
Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,80 @@ | ||
GPIO-based I2C Arbitration Using a Challenge & Response Mechanism | ||
================================================================= | ||
This uses GPIO lines and a challenge & response mechanism to arbitrate who is | ||
the master of an I2C bus in a multimaster situation. | ||
|
||
In many cases using GPIOs to arbitrate is not needed and a design can use | ||
the standard I2C multi-master rules. Using GPIOs is generally useful in | ||
the case where there is a device on the bus that has errata and/or bugs | ||
that makes standard multimaster mode not feasible. | ||
|
||
|
||
Algorithm: | ||
|
||
All masters on the bus have a 'bus claim' line which is an output that the | ||
others can see. These are all active low with pull-ups enabled. We'll | ||
describe these lines as: | ||
|
||
- OUR_CLAIM: output from us signaling to other hosts that we want the bus | ||
- THEIR_CLAIMS: output from others signaling that they want the bus | ||
|
||
The basic algorithm is to assert your line when you want the bus, then make | ||
sure that the other side doesn't want it also. A detailed explanation is best | ||
done with an example. | ||
|
||
Let's say we want to claim the bus. We: | ||
1. Assert OUR_CLAIM. | ||
2. Waits a little bit for the other sides to notice (slew time, say 10 | ||
microseconds). | ||
3. Check THEIR_CLAIMS. If none are asserted then the we have the bus and we are | ||
done. | ||
4. Otherwise, wait for a few milliseconds and see if THEIR_CLAIMS are released. | ||
5. If not, back off, release the claim and wait for a few more milliseconds. | ||
6. Go back to 1 (until retry time has expired). | ||
|
||
|
||
Required properties: | ||
- compatible: i2c-arb-gpio-challenge | ||
- our-claim-gpio: The GPIO that we use to claim the bus. | ||
- their-claim-gpios: The GPIOs that the other sides use to claim the bus. | ||
Note that some implementations may only support a single other master. | ||
- Standard I2C mux properties. See mux.txt in this directory. | ||
- Single I2C child bus node at reg 0. See mux.txt in this directory. | ||
|
||
Optional properties: | ||
- slew-delay-us: microseconds to wait for a GPIO to go high. Default is 10 us. | ||
- wait-retry-us: we'll attempt another claim after this many microseconds. | ||
Default is 3000 us. | ||
- wait-free-us: we'll give up after this many microseconds. Default is 50000 us. | ||
|
||
|
||
Example: | ||
i2c@12CA0000 { | ||
compatible = "acme,some-i2c-device"; | ||
#address-cells = <1>; | ||
#size-cells = <0>; | ||
}; | ||
|
||
i2c-arbitrator { | ||
compatible = "i2c-arb-gpio-challenge"; | ||
#address-cells = <1>; | ||
#size-cells = <0>; | ||
|
||
i2c-parent = <&{/i2c@12CA0000}>; | ||
|
||
our-claim-gpio = <&gpf0 3 1>; | ||
their-claim-gpios = <&gpe0 4 1>; | ||
slew-delay-us = <10>; | ||
wait-retry-us = <3000>; | ||
wait-free-us = <50000>; | ||
|
||
i2c@0 { | ||
reg = <0>; | ||
#address-cells = <1>; | ||
#size-cells = <0>; | ||
|
||
i2c@52 { | ||
// Normal I2C device | ||
}; | ||
}; | ||
}; |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file was deleted.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.