summaryrefslogtreecommitdiffstats
path: root/Documentation
diff options
context:
space:
mode:
authorDavid Brownell <david-b@pacbell.net>2006-01-21 13:21:43 -0800
committerGreg Kroah-Hartman <gregkh@suse.de>2006-02-06 12:17:17 -0800
commit9c1da3cb46316e40bac766ce45556dc4fd8df3ca (patch)
treed2ab578f2601383f39d316dfca0f00d12da21dba /Documentation
parent022f7b07bf2b384ece7fbd7edb90e54cd78db252 (diff)
downloadlinux-9c1da3cb46316e40bac766ce45556dc4fd8df3ca.tar.bz2
[PATCH] SPI: spi_butterfly, restore lost deltas
This resolves some minor version skew glitches that accumulated for the AVR Butterfly adapter driver, which caused among other things the existence of a duplicate Kconfig entry. Most of it boils down to comment updates, but in one case it removes some now-superfluous code that would be better if not copied into other controller-level drivers. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/spi/butterfly23
1 files changed, 17 insertions, 6 deletions
diff --git a/Documentation/spi/butterfly b/Documentation/spi/butterfly
index a2e8c8d90e35..9927af7a629c 100644
--- a/Documentation/spi/butterfly
+++ b/Documentation/spi/butterfly
@@ -12,13 +12,20 @@ You can make this adapter from an old printer cable and solder things
directly to the Butterfly. Or (if you have the parts and skills) you
can come up with something fancier, providing ciruit protection to the
Butterfly and the printer port, or with a better power supply than two
-signal pins from the printer port.
+signal pins from the printer port. Or for that matter, you can use
+similar cables to talk to many AVR boards, even a breadboard.
+
+This is more powerful than "ISP programming" cables since it lets kernel
+SPI protocol drivers interact with the AVR, and could even let the AVR
+issue interrupts to them. Later, your protocol driver should work
+easily with a "real SPI controller", instead of this bitbanger.
The first cable connections will hook Linux up to one SPI bus, with the
AVR and a DataFlash chip; and to the AVR reset line. This is all you
need to reflash the firmware, and the pins are the standard Atmel "ISP"
-connector pins (used also on non-Butterfly AVR boards).
+connector pins (used also on non-Butterfly AVR boards). On the parport
+side this is like "sp12" programming cables.
Signal Butterfly Parport (DB-25)
------ --------- ---------------
@@ -40,10 +47,14 @@ by clearing PORTB.[0-3]); (b) configure the mtd_dataflash driver; and
SELECT = J400.PB0/nSS = pin 17/C3,nSELECT
GND = J400.GND = pin 24/GND
-The "USI" controller, using J405, can be used for a second SPI bus. That
-would let you talk to the AVR over SPI, running firmware that makes it act
-as an SPI slave, while letting either Linux or the AVR use the DataFlash.
-There are plenty of spare parport pins to wire this one up, such as:
+Or you could flash firmware making the AVR into an SPI slave (keeping the
+DataFlash in reset) and tweak the spi_butterfly driver to make it bind to
+the driver for your custom SPI-based protocol.
+
+The "USI" controller, using J405, can also be used for a second SPI bus.
+That would let you talk to the AVR using custom SPI-with-USI firmware,
+while letting either Linux or the AVR use the DataFlash. There are plenty
+of spare parport pins to wire this one up, such as:
Signal Butterfly Parport (DB-25)
------ --------- ---------------