From 6171b5eff2ef3f84333af652e8c7b0838bf72945 Mon Sep 17 00:00:00 2001 From: Mark Haverkamp Date: Wed, 11 Jan 2006 09:28:57 -0800 Subject: [SCSI] aacraid: README update Received From Mark Salyzyn. Move the README from the driver directory to the Documentation directory. Updated the documentation, added descriptions for cards that were missing. Signed-off-by: Mark Haverkamp Signed-off-by: James Bottomley --- Documentation/scsi/aacraid.txt | 108 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 108 insertions(+) create mode 100644 Documentation/scsi/aacraid.txt (limited to 'Documentation') diff --git a/Documentation/scsi/aacraid.txt b/Documentation/scsi/aacraid.txt new file mode 100644 index 0000000000000..820fd07935026 --- /dev/null +++ b/Documentation/scsi/aacraid.txt @@ -0,0 +1,108 @@ +AACRAID Driver for Linux (take two) + +Introduction +------------------------- +The aacraid driver adds support for Adaptec (http://www.adaptec.com) +RAID controllers. This is a major rewrite from the original +Adaptec supplied driver. It has signficantly cleaned up both the code +and the running binary size (the module is less than half the size of +the original). + +Supported Cards/Chipsets +------------------------- + PCI ID (pci.ids) OEM Product + 9005:0285:9005:028a Adaptec 2020ZCR (Skyhawk) + 9005:0285:9005:028e Adaptec 2020SA (Skyhawk) + 9005:0285:9005:028b Adaptec 2025ZCR (Terminator) + 9005:0285:9005:028f Adaptec 2025SA (Terminator) + 9005:0285:9005:0286 Adaptec 2120S (Crusader) + 9005:0286:9005:028d Adaptec 2130S (Lancer) + 9005:0285:9005:0285 Adaptec 2200S (Vulcan) + 9005:0285:9005:0287 Adaptec 2200S (Vulcan-2m) + 9005:0286:9005:028c Adaptec 2230S (Lancer) + 9005:0286:9005:028c Adaptec 2230SLP (Lancer) + 9005:0285:9005:0296 Adaptec 2240S (SabreExpress) + 9005:0285:9005:0290 Adaptec 2410SA (Jaguar) + 9005:0285:9005:0293 Adaptec 21610SA (Corsair-16) + 9005:0285:103c:3227 Adaptec 2610SA (Bearcat) + 9005:0285:9005:0292 Adaptec 2810SA (Corsair-8) + 9005:0285:9005:0294 Adaptec Prowler + 9005:0286:9005:029d Adaptec 2420SA (Intruder) + 9005:0286:9005:029c Adaptec 2620SA (Intruder) + 9005:0286:9005:029b Adaptec 2820SA (Intruder) + 9005:0286:9005:02a7 Adaptec 2830SA (Skyray) + 9005:0286:9005:02a8 Adaptec 2430SA (Skyray) + 9005:0285:9005:0288 Adaptec 3230S (Harrier) + 9005:0285:9005:0289 Adaptec 3240S (Tornado) + 9005:0285:9005:0298 Adaptec 4000SAS (BlackBird) + 9005:0285:9005:0297 Adaptec 4005SAS (AvonPark) + 9005:0285:9005:0299 Adaptec 4800SAS (Marauder-X) + 9005:0285:9005:029a Adaptec 4805SAS (Marauder-E) + 9005:0286:9005:02a2 Adaptec 4810SAS (Hurricane) + 1011:0046:9005:0364 Adaptec 5400S (Mustang) + 1011:0046:9005:0365 Adaptec 5400S (Mustang) + 9005:0283:9005:0283 Adaptec Catapult (3210S with arc firmware) + 9005:0284:9005:0284 Adaptec Tomcat (3410S with arc firmware) + 9005:0287:9005:0800 Adaptec Themisto (Jupiter) + 9005:0200:9005:0200 Adaptec Themisto (Jupiter) + 9005:0286:9005:0800 Adaptec Callisto (Jupiter) + 1011:0046:9005:1364 Dell PERC 2/QC (Quad Channel, Mustang) + 1028:0001:1028:0001 Dell PERC 2/Si (Iguana) + 1028:0003:1028:0003 Dell PERC 3/Si (SlimFast) + 1028:0002:1028:0002 Dell PERC 3/Di (Opal) + 1028:0004:1028:0004 Dell PERC 3/DiF (Iguana) + 1028:0002:1028:00d1 Dell PERC 3/DiV (Viper) + 1028:0002:1028:00d9 Dell PERC 3/DiL (Lexus) + 1028:000a:1028:0106 Dell PERC 3/DiJ (Jaguar) + 1028:000a:1028:011b Dell PERC 3/DiD (Dagger) + 1028:000a:1028:0121 Dell PERC 3/DiB (Boxster) + 9005:0285:1028:0287 Dell PERC 320/DC (Vulcan) + 9005:0285:1028:0291 Dell CERC 2 (DellCorsair) + 1011:0046:103c:10c2 HP NetRAID-4M (Mustang) + 9005:0285:17aa:0286 Legend S220 (Crusader) + 9005:0285:17aa:0287 Legend S230 (Vulcan) + 9005:0285:9005:0290 IBM ServeRAID 7t (Jaguar) + 9005:0285:1014:02F2 IBM ServeRAID 8i (AvonPark) + 9005:0285:1014:0312 IBM ServeRAID 8i (AvonParkLite) + 9005:0286:1014:9580 IBM ServeRAID 8k/8k-l8 (Aurora) + 9005:0286:1014:9540 IBM ServeRAID 8k/8k-l4 (AuroraLite) + 9005:0286:9005:029f ICP ICP9014R0 (Lancer) + 9005:0286:9005:029e ICP ICP9024R0 (Lancer) + 9005:0286:9005:02a0 ICP ICP9047MA (Lancer) + 9005:0286:9005:02a1 ICP ICP9087MA (Lancer) + 9005:0286:9005:02a4 ICP ICP9085LI (Marauder-X) + 9005:0286:9005:02a5 ICP ICP5085BR (Marauder-E) + 9005:0286:9005:02a3 ICP ICP5085AU (Hurricane) + 9005:0286:9005:02a6 ICP ICP9067MA (Intruder-6) + 9005:0286:9005:02a9 ICP ICP5087AU (Skyray) + 9005:0286:9005:02aa ICP ICP5047AU (Skyray) + +People +------------------------- +Alan Cox +Christoph Hellwig (updates for new-style PCI probing and SCSI host registration, + small cleanups/fixes) +Matt Domsch (revision ioctl, adapter messages) +Deanna Bonds (non-DASD support, PAE fibs and 64 bit, added new adaptec controllers + added new ioctls, changed scsi interface to use new error handler, + increased the number of fibs and outstanding commands to a container) + + (fixed 64bit and 64G memory model, changed confusing naming convention + where fibs that go to the hardware are consistently called hw_fibs and + not just fibs like the name of the driver tracking structure) +Mark Salyzyn Fixed panic issues and added some new product ids for upcoming hbas. Performance tuning, card failover and bug mitigations. + +Original Driver +------------------------- +Adaptec Unix OEM Product Group + +Mailing List +------------------------- +linux-scsi@vger.kernel.org (Interested parties troll here) +Also note this is very different to Brian's original driver +so don't expect him to support it. +Adaptec does support this driver. Contact Adaptec tech support or +aacraid@adaptec.com + +Original by Brian Boerner February 2001 +Rewritten by Alan Cox, November 2001 -- cgit 1.2.3-korg From 8ae12a0d85987dc138f8c944cb78a92bf466cea0 Mon Sep 17 00:00:00 2001 From: David Brownell Date: Sun, 8 Jan 2006 13:34:19 -0800 Subject: [PATCH] spi: simple SPI framework This is the core of a small SPI framework, implementing the model of a queue of messages which complete asynchronously (with thin synchronous wrappers on top). - It's still less than 2KB of ".text" (ARM). If there's got to be a mid-layer for something so simple, that's the right size budget. :) - The guts use board-specific SPI device tables to build the driver model tree. (Hardware probing is rarely an option.) - This version of Kconfig includes no drivers. At this writing there are two known master controller drivers (PXA/SSP, OMAP MicroWire) and three protocol drivers (CS8415a, ADS7846, DataFlash) with LKML mentions of other drivers in development. - No userspace API. There are several implementations to compare. Implement them like any other driver, and bind them with sysfs. The changes from last version posted to LKML (on 11-Nov-2005) are minor, and include: - One bugfix (removes a FIXME), with the visible effect of making device names be "spiB.C" where B is the bus number and C is the chipselect. - The "caller provides DMA mappings" mechanism now has kerneldoc, for DMA drivers that want to be fancy. - Hey, the framework init can be subsys_init. Even though board init logic fires earlier, at arch_init ... since the framework init is for driver support, and the board init support uses static init. - Various additional spec/doc clarifications based on discussions with other folk. It adds a brief "thank you" at the end, for folk who've helped nudge this framework into existence. As I've said before, I think that "protocol tweaking" is the main support that this driver framework will need to evolve. From: Mark Underwood Update the SPI framework to remove a potential priority inversion case by reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available. Signed-off-by: David Brownell Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman --- Documentation/spi/spi-summary | 416 +++++++++++++++++++++++++++++++ arch/arm/Kconfig | 2 + drivers/Kconfig | 2 + drivers/Makefile | 1 + drivers/spi/Kconfig | 76 ++++++ drivers/spi/Makefile | 23 ++ drivers/spi/spi.c | 568 ++++++++++++++++++++++++++++++++++++++++++ include/linux/spi/spi.h | 542 ++++++++++++++++++++++++++++++++++++++++ 8 files changed, 1630 insertions(+) create mode 100644 Documentation/spi/spi-summary create mode 100644 drivers/spi/Kconfig create mode 100644 drivers/spi/Makefile create mode 100644 drivers/spi/spi.c create mode 100644 include/linux/spi/spi.h (limited to 'Documentation') diff --git a/Documentation/spi/spi-summary b/Documentation/spi/spi-summary new file mode 100644 index 0000000000000..00497f95ca4bb --- /dev/null +++ b/Documentation/spi/spi-summary @@ -0,0 +1,416 @@ +Overview of Linux kernel SPI support +==================================== + +22-Nov-2005 + +What is SPI? +------------ +The "Serial Peripheral Interface" (SPI) is a four-wire point-to-point +serial link used to connect microcontrollers to sensors and memory. + +The three signal wires hold a clock (SCLK, often on the order of 10 MHz), +and parallel data lines with "Master Out, Slave In" (MOSI) or "Master In, +Slave Out" (MISO) signals. (Other names are also used.) There are four +clocking modes through which data is exchanged; mode-0 and mode-3 are most +commonly used. + +SPI masters may use a "chip select" line to activate a given SPI slave +device, so those three signal wires may be connected to several chips +in parallel. All SPI slaves support chipselects. Some devices have +other signals, often including an interrupt to the master. + +Unlike serial busses like USB or SMBUS, even low level protocols for +SPI slave functions are usually not interoperable between vendors +(except for cases like SPI memory chips). + + - SPI may be used for request/response style device protocols, as with + touchscreen sensors and memory chips. + + - It may also be used to stream data in either direction (half duplex), + or both of them at the same time (full duplex). + + - Some devices may use eight bit words. Others may different word + lengths, such as streams of 12-bit or 20-bit digital samples. + +In the same way, SPI slaves will only rarely support any kind of automatic +discovery/enumeration protocol. The tree of slave devices accessible from +a given SPI master will normally be set up manually, with configuration +tables. + +SPI is only one of the names used by such four-wire protocols, and +most controllers have no problem handling "MicroWire" (think of it as +half-duplex SPI, for request/response protocols), SSP ("Synchronous +Serial Protocol"), PSP ("Programmable Serial Protocol"), and other +related protocols. + +Microcontrollers often support both master and slave sides of the SPI +protocol. This document (and Linux) currently only supports the master +side of SPI interactions. + + +Who uses it? On what kinds of systems? +--------------------------------------- +Linux developers using SPI are probably writing device drivers for embedded +systems boards. SPI is used to control external chips, and it is also a +protocol supported by every MMC or SD memory card. (The older "DataFlash" +cards, predating MMC cards but using the same connectors and card shape, +support only SPI.) Some PC hardware uses SPI flash for BIOS code. + +SPI slave chips range from digital/analog converters used for analog +sensors and codecs, to memory, to peripherals like USB controllers +or Ethernet adapters; and more. + +Most systems using SPI will integrate a few devices on a mainboard. +Some provide SPI links on expansion connectors; in cases where no +dedicated SPI controller exists, GPIO pins can be used to create a +low speed "bitbanging" adapter. Very few systems will "hotplug" an SPI +controller; the reasons to use SPI focus on low cost and simple operation, +and if dynamic reconfiguration is important, USB will often be a more +appropriate low-pincount peripheral bus. + +Many microcontrollers that can run Linux integrate one or more I/O +interfaces with SPI modes. Given SPI support, they could use MMC or SD +cards without needing a special purpose MMC/SD/SDIO controller. + + +How do these driver programming interfaces work? +------------------------------------------------ +The header file includes kerneldoc, as does the +main source code, and you should certainly read that. This is just +an overview, so you get the big picture before the details. + +There are two types of SPI driver, here called: + + Controller drivers ... these are often built in to System-On-Chip + processors, and often support both Master and Slave roles. + These drivers touch hardware registers and may use DMA. + + Protocol drivers ... these pass messages through the controller + driver to communicate with a Slave or Master device on the + other side of an SPI link. + +So for example one protocol driver might talk to the MTD layer to export +data to filesystems stored on SPI flash like DataFlash; and others might +control audio interfaces, present touchscreen sensors as input interfaces, +or monitor temperature and voltage levels during industrial processing. +And those might all be sharing the same controller driver. + +A "struct spi_device" encapsulates the master-side interface between +those two types of driver. At this writing, Linux has no slave side +programming interface. + +There is a minimal core of SPI programming interfaces, focussing on +using driver model to connect controller and protocol drivers using +device tables provided by board specific initialization code. SPI +shows up in sysfs in several locations: + + /sys/devices/.../CTLR/spiB.C ... spi_device for on bus "B", + chipselect C, accessed through CTLR. + + /sys/bus/spi/devices/spiB.C ... symlink to the physical + spiB-C device + + /sys/bus/spi/drivers/D ... driver for one or more spi*.* devices + + /sys/class/spi_master/spiB ... class device for the controller + managing bus "B". All the spiB.* devices share the same + physical SPI bus segment, with SCLK, MOSI, and MISO. + +The basic I/O primitive submits an asynchronous message to an I/O queue +maintained by the controller driver. A completion callback is issued +asynchronously when the data transfer(s) in that message completes. +There are also some simple synchronous wrappers for those calls. + + +How does board-specific init code declare SPI devices? +------------------------------------------------------ +Linux needs several kinds of information to properly configure SPI devices. +That information is normally provided by board-specific code, even for +chips that do support some of automated discovery/enumeration. + +DECLARE CONTROLLERS + +The first kind of information is a list of what SPI controllers exist. +For System-on-Chip (SOC) based boards, these will usually be platform +devices, and the controller may need some platform_data in order to +operate properly. The "struct platform_device" will include resources +like the physical address of the controller's first register and its IRQ. + +Platforms will often abstract the "register SPI controller" operation, +maybe coupling it with code to initialize pin configurations, so that +the arch/.../mach-*/board-*.c files for several boards can all share the +same basic controller setup code. This is because most SOCs have several +SPI-capable controllers, and only the ones actually usable on a given +board should normally be set up and registered. + +So for example arch/.../mach-*/board-*.c files might have code like: + + #include /* for mysoc_spi_data */ + + /* if your mach-* infrastructure doesn't support kernels that can + * run on multiple boards, pdata wouldn't benefit from "__init". + */ + static struct mysoc_spi_data __init pdata = { ... }; + + static __init board_init(void) + { + ... + /* this board only uses SPI controller #2 */ + mysoc_register_spi(2, &pdata); + ... + } + +And SOC-specific utility code might look something like: + + #include + + static struct platform_device spi2 = { ... }; + + void mysoc_register_spi(unsigned n, struct mysoc_spi_data *pdata) + { + struct mysoc_spi_data *pdata2; + + pdata2 = kmalloc(sizeof *pdata2, GFP_KERNEL); + *pdata2 = pdata; + ... + if (n == 2) { + spi2->dev.platform_data = pdata2; + register_platform_device(&spi2); + + /* also: set up pin modes so the spi2 signals are + * visible on the relevant pins ... bootloaders on + * production boards may already have done this, but + * developer boards will often need Linux to do it. + */ + } + ... + } + +Notice how the platform_data for boards may be different, even if the +same SOC controller is used. For example, on one board SPI might use +an external clock, where another derives the SPI clock from current +settings of some master clock. + + +DECLARE SLAVE DEVICES + +The second kind of information is a list of what SPI slave devices exist +on the target board, often with some board-specific data needed for the +driver to work correctly. + +Normally your arch/.../mach-*/board-*.c files would provide a small table +listing the SPI devices on each board. (This would typically be only a +small handful.) That might look like: + + static struct ads7846_platform_data ads_info = { + .vref_delay_usecs = 100, + .x_plate_ohms = 580, + .y_plate_ohms = 410, + }; + + static struct spi_board_info spi_board_info[] __initdata = { + { + .modalias = "ads7846", + .platform_data = &ads_info, + .mode = SPI_MODE_0, + .irq = GPIO_IRQ(31), + .max_speed_hz = 120000 /* max sample rate at 3V */ * 16, + .bus_num = 1, + .chip_select = 0, + }, + }; + +Again, notice how board-specific information is provided; each chip may need +several types. This example shows generic constraints like the fastest SPI +clock to allow (a function of board voltage in this case) or how an IRQ pin +is wired, plus chip-specific constraints like an important delay that's +changed by the capacitance at one pin. + +(There's also "controller_data", information that may be useful to the +controller driver. An example would be peripheral-specific DMA tuning +data or chipselect callbacks. This is stored in spi_device later.) + +The board_info should provide enough information to let the system work +without the chip's driver being loaded. The most troublesome aspect of +that is likely the SPI_CS_HIGH bit in the spi_device.mode field, since +sharing a bus with a device that interprets chipselect "backwards" is +not possible. + +Then your board initialization code would register that table with the SPI +infrastructure, so that it's available later when the SPI master controller +driver is registered: + + spi_register_board_info(spi_board_info, ARRAY_SIZE(spi_board_info)); + +Like with other static board-specific setup, you won't unregister those. + + +NON-STATIC CONFIGURATIONS + +Developer boards often play by different rules than product boards, and one +example is the potential need to hotplug SPI devices and/or controllers. + +For those cases you might need to use use spi_busnum_to_master() to look +up the spi bus master, and will likely need spi_new_device() to provide the +board info based on the board that was hotplugged. Of course, you'd later +call at least spi_unregister_device() when that board is removed. + + +How do I write an "SPI Protocol Driver"? +---------------------------------------- +All SPI drivers are currently kernel drivers. A userspace driver API +would just be another kernel driver, probably offering some lowlevel +access through aio_read(), aio_write(), and ioctl() calls and using the +standard userspace sysfs mechanisms to bind to a given SPI device. + +SPI protocol drivers are normal device drivers, with no more wrapper +than needed by platform devices: + + static struct device_driver CHIP_driver = { + .name = "CHIP", + .bus = &spi_bus_type, + .probe = CHIP_probe, + .remove = __exit_p(CHIP_remove), + .suspend = CHIP_suspend, + .resume = CHIP_resume, + }; + +The SPI core will autmatically attempt to bind this driver to any SPI +device whose board_info gave a modalias of "CHIP". Your probe() code +might look like this unless you're creating a class_device: + + static int __init CHIP_probe(struct device *dev) + { + struct spi_device *spi = to_spi_device(dev); + struct CHIP *chip; + struct CHIP_platform_data *pdata = dev->platform_data; + + /* get memory for driver's per-chip state */ + chip = kzalloc(sizeof *chip, GFP_KERNEL); + if (!chip) + return -ENOMEM; + dev_set_drvdata(dev, chip); + + ... etc + return 0; + } + +As soon as it enters probe(), the driver may issue I/O requests to +the SPI device using "struct spi_message". When remove() returns, +the driver guarantees that it won't submit any more such messages. + + - An spi_message is a sequence of of protocol operations, executed + as one atomic sequence. SPI driver controls include: + + + when bidirectional reads and writes start ... by how its + sequence of spi_transfer requests is arranged; + + + optionally defining short delays after transfers ... using + the spi_transfer.delay_usecs setting; + + + whether the chipselect becomes inactive after a transfer and + any delay ... by using the spi_transfer.cs_change flag; + + + hinting whether the next message is likely to go to this same + device ... using the spi_transfer.cs_change flag on the last + transfer in that atomic group, and potentially saving costs + for chip deselect and select operations. + + - Follow standard kernel rules, and provide DMA-safe buffers in + your messages. That way controller drivers using DMA aren't forced + to make extra copies unless the hardware requires it (e.g. working + around hardware errata that force the use of bounce buffering). + + If standard dma_map_single() handling of these buffers is inappropriate, + you can use spi_message.is_dma_mapped to tell the controller driver + that you've already provided the relevant DMA addresses. + + - The basic I/O primitive is spi_async(). Async requests may be + issued in any context (irq handler, task, etc) and completion + is reported using a callback provided with the message. + + - There are also synchronous wrappers like spi_sync(), and wrappers + like spi_read(), spi_write(), and spi_write_then_read(). These + may be issued only in contexts that may sleep, and they're all + clean (and small, and "optional") layers over spi_async(). + + - The spi_write_then_read() call, and convenience wrappers around + it, should only be used with small amounts of data where the + cost of an extra copy may be ignored. It's designed to support + common RPC-style requests, such as writing an eight bit command + and reading a sixteen bit response -- spi_w8r16() being one its + wrappers, doing exactly that. + +Some drivers may need to modify spi_device characteristics like the +transfer mode, wordsize, or clock rate. This is done with spi_setup(), +which would normally be called from probe() before the first I/O is +done to the device. + +While "spi_device" would be the bottom boundary of the driver, the +upper boundaries might include sysfs (especially for sensor readings), +the input layer, ALSA, networking, MTD, the character device framework, +or other Linux subsystems. + + +How do I write an "SPI Master Controller Driver"? +------------------------------------------------- +An SPI controller will probably be registered on the platform_bus; write +a driver to bind to the device, whichever bus is involved. + +The main task of this type of driver is to provide an "spi_master". +Use spi_alloc_master() to allocate the master, and class_get_devdata() +to get the driver-private data allocated for that device. + + struct spi_master *master; + struct CONTROLLER *c; + + master = spi_alloc_master(dev, sizeof *c); + if (!master) + return -ENODEV; + + c = class_get_devdata(&master->cdev); + +The driver will initialize the fields of that spi_master, including the +bus number (maybe the same as the platform device ID) and three methods +used to interact with the SPI core and SPI protocol drivers. It will +also initialize its own internal state. + + master->setup(struct spi_device *spi) + This sets up the device clock rate, SPI mode, and word sizes. + Drivers may change the defaults provided by board_info, and then + call spi_setup(spi) to invoke this routine. It may sleep. + + master->transfer(struct spi_device *spi, struct spi_message *message) + This must not sleep. Its responsibility is arrange that the + transfer happens and its complete() callback is issued; the two + will normally happen later, after other transfers complete. + + master->cleanup(struct spi_device *spi) + Your controller driver may use spi_device.controller_state to hold + state it dynamically associates with that device. If you do that, + be sure to provide the cleanup() method to free that state. + +The bulk of the driver will be managing the I/O queue fed by transfer(). + +That queue could be purely conceptual. For example, a driver used only +for low-frequency sensor acess might be fine using synchronous PIO. + +But the queue will probably be very real, using message->queue, PIO, +often DMA (especially if the root filesystem is in SPI flash), and +execution contexts like IRQ handlers, tasklets, or workqueues (such +as keventd). Your driver can be as fancy, or as simple, as you need. + + +THANKS TO +--------- +Contributors to Linux-SPI discussions include (in alphabetical order, +by last name): + +David Brownell +Russell King +Dmitry Pervushin +Stephen Street +Mark Underwood +Andrew Victor +Vitaly Wool + diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 50b9afa8ae6d0..3cfd82a05b20b 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -729,6 +729,8 @@ source "drivers/char/Kconfig" source "drivers/i2c/Kconfig" +source "drivers/spi/Kconfig" + source "drivers/hwmon/Kconfig" #source "drivers/l3/Kconfig" diff --git a/drivers/Kconfig b/drivers/Kconfig index 48f446d3c671a..283c089537bcd 100644 --- a/drivers/Kconfig +++ b/drivers/Kconfig @@ -44,6 +44,8 @@ source "drivers/char/Kconfig" source "drivers/i2c/Kconfig" +source "drivers/spi/Kconfig" + source "drivers/w1/Kconfig" source "drivers/hwmon/Kconfig" diff --git a/drivers/Makefile b/drivers/Makefile index 7fc3f0f08b29e..7c45050ecd03c 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -41,6 +41,7 @@ obj-$(CONFIG_FUSION) += message/ obj-$(CONFIG_IEEE1394) += ieee1394/ obj-y += cdrom/ obj-$(CONFIG_MTD) += mtd/ +obj-$(CONFIG_SPI) += spi/ obj-$(CONFIG_PCCARD) += pcmcia/ obj-$(CONFIG_DIO) += dio/ obj-$(CONFIG_SBUS) += sbus/ diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig new file mode 100644 index 0000000000000..d3105104a2970 --- /dev/null +++ b/drivers/spi/Kconfig @@ -0,0 +1,76 @@ +# +# SPI driver configuration +# +# NOTE: the reason this doesn't show SPI slave support is mostly that +# nobody's needed a slave side API yet. The master-role API is not +# fully appropriate there, so it'd need some thought to do well. +# +menu "SPI support" + +config SPI + bool "SPI support" + help + The "Serial Peripheral Interface" is a low level synchronous + protocol. Chips that support SPI can have data transfer rates + up to several tens of Mbit/sec. Chips are addressed with a + controller and a chipselect. Most SPI slaves don't support + dynamic device discovery; some are even write-only or read-only. + + SPI is widely used by microcontollers to talk with sensors, + eeprom and flash memory, codecs and various other controller + chips, analog to digital (and d-to-a) converters, and more. + MMC and SD cards can be accessed using SPI protocol; and for + DataFlash cards used in MMC sockets, SPI must always be used. + + SPI is one of a family of similar protocols using a four wire + interface (select, clock, data in, data out) including Microwire + (half duplex), SSP, SSI, and PSP. This driver framework should + work with most such devices and controllers. + +config SPI_DEBUG + boolean "Debug support for SPI drivers" + depends on SPI && DEBUG_KERNEL + help + Say "yes" to enable debug messaging (like dev_dbg and pr_debug), + sysfs, and debugfs support in SPI controller and protocol drivers. + +# +# MASTER side ... talking to discrete SPI slave chips including microcontrollers +# + +config SPI_MASTER +# boolean "SPI Master Support" + boolean + default SPI + help + If your system has an master-capable SPI controller (which + provides the clock and chipselect), you can enable that + controller and the protocol drivers for the SPI slave chips + that are connected. + +comment "SPI Master Controller Drivers" + depends on SPI_MASTER + + +# +# Add new SPI master controllers in alphabetical order above this line +# + + +# +# There are lots of SPI device types, with sensors and memory +# being probably the most widely used ones. +# +comment "SPI Protocol Masters" + depends on SPI_MASTER + + +# +# Add new SPI protocol masters in alphabetical order above this line +# + + +# (slave support would go here) + +endmenu # "SPI support" + diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile new file mode 100644 index 0000000000000..afd2321753b3c --- /dev/null +++ b/drivers/spi/Makefile @@ -0,0 +1,23 @@ +# +# Makefile for kernel SPI drivers. +# + +ifeq ($(CONFIG_SPI_DEBUG),y) +EXTRA_CFLAGS += -DDEBUG +endif + +# small core, mostly translating board-specific +# config declarations into driver model code +obj-$(CONFIG_SPI_MASTER) += spi.o + +# SPI master controller drivers (bus) +# ... add above this line ... + +# SPI protocol drivers (device/link on bus) +# ... add above this line ... + +# SPI slave controller drivers (upstream link) +# ... add above this line ... + +# SPI slave drivers (protocol for that link) +# ... add above this line ... diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c new file mode 100644 index 0000000000000..7cd356b176442 --- /dev/null +++ b/drivers/spi/spi.c @@ -0,0 +1,568 @@ +/* + * spi.c - SPI init/core code + * + * Copyright (C) 2005 David Brownell + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + */ + +#include +#include +#include +#include +#include +#include + + +/* SPI bustype and spi_master class are registered during early boot, + * usually before board init code provides the SPI device tables, and + * are available later when driver init code needs them. + * + * Drivers for SPI devices started out like those for platform bus + * devices. But both have changed in 2.6.15; maybe this should get + * an "spi_driver" structure at some point (not currently needed) + */ +static void spidev_release(struct device *dev) +{ + const struct spi_device *spi = to_spi_device(dev); + + /* spi masters may cleanup for released devices */ + if (spi->master->cleanup) + spi->master->cleanup(spi); + + class_device_put(&spi->master->cdev); + kfree(dev); +} + +static ssize_t +modalias_show(struct device *dev, struct device_attribute *a, char *buf) +{ + const struct spi_device *spi = to_spi_device(dev); + + return snprintf(buf, BUS_ID_SIZE + 1, "%s\n", spi->modalias); +} + +static struct device_attribute spi_dev_attrs[] = { + __ATTR_RO(modalias), + __ATTR_NULL, +}; + +/* modalias support makes "modprobe $MODALIAS" new-style hotplug work, + * and the sysfs version makes coldplug work too. + */ + +static int spi_match_device(struct device *dev, struct device_driver *drv) +{ + const struct spi_device *spi = to_spi_device(dev); + + return strncmp(spi->modalias, drv->name, BUS_ID_SIZE) == 0; +} + +static int spi_uevent(struct device *dev, char **envp, int num_envp, + char *buffer, int buffer_size) +{ + const struct spi_device *spi = to_spi_device(dev); + + envp[0] = buffer; + snprintf(buffer, buffer_size, "MODALIAS=%s", spi->modalias); + envp[1] = NULL; + return 0; +} + +#ifdef CONFIG_PM + +/* Suspend/resume in "struct device_driver" don't really need that + * strange third parameter, so we just make it a constant and expect + * SPI drivers to ignore it just like most platform drivers do. + * + * NOTE: the suspend() method for an spi_master controller driver + * should verify that all its child devices are marked as suspended; + * suspend requests delivered through sysfs power/state files don't + * enforce such constraints. + */ +static int spi_suspend(struct device *dev, pm_message_t message) +{ + int value; + + if (!dev->driver || !dev->driver->suspend) + return 0; + + /* suspend will stop irqs and dma; no more i/o */ + value = dev->driver->suspend(dev, message); + if (value == 0) + dev->power.power_state = message; + return value; +} + +static int spi_resume(struct device *dev) +{ + int value; + + if (!dev->driver || !dev->driver->resume) + return 0; + + /* resume may restart the i/o queue */ + value = dev->driver->resume(dev); + if (value == 0) + dev->power.power_state = PMSG_ON; + return value; +} + +#else +#define spi_suspend NULL +#define spi_resume NULL +#endif + +struct bus_type spi_bus_type = { + .name = "spi", + .dev_attrs = spi_dev_attrs, + .match = spi_match_device, + .uevent = spi_uevent, + .suspend = spi_suspend, + .resume = spi_resume, +}; +EXPORT_SYMBOL_GPL(spi_bus_type); + +/*-------------------------------------------------------------------------*/ + +/* SPI devices should normally not be created by SPI device drivers; that + * would make them board-specific. Similarly with SPI master drivers. + * Device registration normally goes into like arch/.../mach.../board-YYY.c + * with other readonly (flashable) information about mainboard devices. + */ + +struct boardinfo { + struct list_head list; + unsigned n_board_info; + struct spi_board_info board_info[0]; +}; + +static LIST_HEAD(board_list); +static DECLARE_MUTEX(board_lock); + + +/* On typical mainboards, this is purely internal; and it's not needed + * after board init creates the hard-wired devices. Some development + * platforms may not be able to use spi_register_board_info though, and + * this is exported so that for example a USB or parport based adapter + * driver could add devices (which it would learn about out-of-band). + */ +struct spi_device *__init_or_module +spi_new_device(struct spi_master *master, struct spi_board_info *chip) +{ + struct spi_device *proxy; + struct device *dev = master->cdev.dev; + int status; + + /* NOTE: caller did any chip->bus_num checks necessary */ + + if (!class_device_get(&master->cdev)) + return NULL; + + proxy = kzalloc(sizeof *proxy, GFP_KERNEL); + if (!proxy) { + dev_err(dev, "can't alloc dev for cs%d\n", + chip->chip_select); + goto fail; + } + proxy->master = master; + proxy->chip_select = chip->chip_select; + proxy->max_speed_hz = chip->max_speed_hz; + proxy->irq = chip->irq; + proxy->modalias = chip->modalias; + + snprintf(proxy->dev.bus_id, sizeof proxy->dev.bus_id, + "%s.%u", master->cdev.class_id, + chip->chip_select); + proxy->dev.parent = dev; + proxy->dev.bus = &spi_bus_type; + proxy->dev.platform_data = (void *) chip->platform_data; + proxy->controller_data = chip->controller_data; + proxy->controller_state = NULL; + proxy->dev.release = spidev_release; + + /* drivers may modify this default i/o setup */ + status = master->setup(proxy); + if (status < 0) { + dev_dbg(dev, "can't %s %s, status %d\n", + "setup", proxy->dev.bus_id, status); + goto fail; + } + + /* driver core catches callers that misbehave by defining + * devices that already exist. + */ + status = device_register(&proxy->dev); + if (status < 0) { + dev_dbg(dev, "can't %s %s, status %d\n", + "add", proxy->dev.bus_id, status); +fail: + class_device_put(&master->cdev); + kfree(proxy); + return NULL; + } + dev_dbg(dev, "registered child %s\n", proxy->dev.bus_id); + return proxy; +} +EXPORT_SYMBOL_GPL(spi_new_device); + +/* + * Board-specific early init code calls this (probably during arch_initcall) + * with segments of the SPI device table. Any device nodes are created later, + * after the relevant parent SPI controller (bus_num) is defined. We keep + * this table of devices forever, so that reloading a controller driver will + * not make Linux forget about these hard-wired devices. + * + * Other code can also call this, e.g. a particular add-on board might provide + * SPI devices through its expansion connector, so code initializing that board + * would naturally declare its SPI devices. + * + * The board info passed can safely be __initdata ... but be careful of + * any embedded pointers (platform_data, etc), they're copied as-is. + */ +int __init +spi_register_board_info(struct spi_board_info const *info, unsigned n) +{ + struct boardinfo *bi; + + bi = kmalloc (sizeof (*bi) + n * sizeof (*info), GFP_KERNEL); + if (!bi) + return -ENOMEM; + bi->n_board_info = n; + memcpy(bi->board_info, info, n * sizeof (*info)); + + down(&board_lock); + list_add_tail(&bi->list, &board_list); + up(&board_lock); + return 0; +} +EXPORT_SYMBOL_GPL(spi_register_board_info); + +/* FIXME someone should add support for a __setup("spi", ...) that + * creates board info from kernel command lines + */ + +static void __init_or_module +scan_boardinfo(struct spi_master *master) +{ + struct boardinfo *bi; + struct device *dev = master->cdev.dev; + + down(&board_lock); + list_for_each_entry(bi, &board_list, list) { + struct spi_board_info *chip = bi->board_info; + unsigned n; + + for (n = bi->n_board_info; n > 0; n--, chip++) { + if (chip->bus_num != master->bus_num) + continue; + /* some controllers only have one chip, so they + * might not use chipselects. otherwise, the + * chipselects are numbered 0..max. + */ + if (chip->chip_select >= master->num_chipselect + && master->num_chipselect) { + dev_dbg(dev, "cs%d > max %d\n", + chip->chip_select, + master->num_chipselect); + continue; + } + (void) spi_new_device(master, chip); + } + } + up(&board_lock); +} + +/*-------------------------------------------------------------------------*/ + +static void spi_master_release(struct class_device *cdev) +{ + struct spi_master *master; + + master = container_of(cdev, struct spi_master, cdev); + put_device(master->cdev.dev); + master->cdev.dev = NULL; + kfree(master); +} + +static struct class spi_master_class = { + .name = "spi_master", + .owner = THIS_MODULE, + .release = spi_master_release, +}; + + +/** + * spi_alloc_master - allocate SPI master controller + * @dev: the controller, possibly using the platform_bus + * @size: how much driver-private data to preallocate; a pointer to this + * memory in the class_data field of the returned class_device + * + * This call is used only by SPI master controller drivers, which are the + * only ones directly touching chip registers. It's how they allocate + * an spi_master structure, prior to calling spi_add_master(). + * + * This must be called from context that can sleep. It returns the SPI + * master structure on success, else NULL. + * + * The caller is responsible for assigning the bus number and initializing + * the master's methods before calling spi_add_master(), or else (on error) + * calling class_device_put() to prevent a memory leak. + */ +struct spi_master * __init_or_module +spi_alloc_master(struct device *dev, unsigned size) +{ + struct spi_master *master; + + master = kzalloc(size + sizeof *master, SLAB_KERNEL); + if (!master) + return NULL; + + master->cdev.class = &spi_master_class; + master->cdev.dev = get_device(dev); + class_set_devdata(&master->cdev, &master[1]); + + return master; +} +EXPORT_SYMBOL_GPL(spi_alloc_master); + +/** + * spi_register_master - register SPI master controller + * @master: initialized master, originally from spi_alloc_master() + * + * SPI master controllers connect to their drivers using some non-SPI bus, + * such as the platform bus. The final stage of probe() in that code + * includes calling spi_register_master() to hook up to this SPI bus glue. + * + * SPI controllers use board specific (often SOC specific) bus numbers, + * and board-specific addressing for SPI devices combines those numbers + * with chip select numbers. Since SPI does not directly support dynamic + * device identification, boards need configuration tables telling which + * chip is at which address. + * + * This must be called from context that can sleep. It returns zero on + * success, else a negative error code (dropping the master's refcount). + */ +int __init_or_module +spi_register_master(struct spi_master *master) +{ + static atomic_t dyn_bus_id = ATOMIC_INIT(0); + struct device *dev = master->cdev.dev; + int status = -ENODEV; + int dynamic = 0; + + /* convention: dynamically assigned bus IDs count down from the max */ + if (master->bus_num == 0) { + master->bus_num = atomic_dec_return(&dyn_bus_id); + dynamic = 0; + } + + /* register the device, then userspace will see it. + * registration fails if the bus ID is in use. + */ + snprintf(master->cdev.class_id, sizeof master->cdev.class_id, + "spi%u", master->bus_num); + status = class_device_register(&master->cdev); + if (status < 0) { + class_device_put(&master->cdev); + goto done; + } + dev_dbg(dev, "registered master %s%s\n", master->cdev.class_id, + dynamic ? " (dynamic)" : ""); + + /* populate children from any spi device tables */ + scan_boardinfo(master); + status = 0; +done: + return status; +} +EXPORT_SYMBOL_GPL(spi_register_master); + + +static int __unregister(struct device *dev, void *unused) +{ + /* note: before about 2.6.14-rc1 this would corrupt memory: */ + device_unregister(dev); + return 0; +} + +/** + * spi_unregister_master - unregister SPI master controller + * @master: the master being unregistered + * + * This call is used only by SPI master controller drivers, which are the + * only ones directly touching chip registers. + * + * This must be called from context that can sleep. + */ +void spi_unregister_master(struct spi_master *master) +{ + class_device_unregister(&master->cdev); + (void) device_for_each_child(master->cdev.dev, NULL, __unregister); +} +EXPORT_SYMBOL_GPL(spi_unregister_master); + +/** + * spi_busnum_to_master - look up master associated with bus_num + * @bus_num: the master's bus number + * + * This call may be used with devices that are registered after + * arch init time. It returns a refcounted pointer to the relevant + * spi_master (which the caller must release), or NULL if there is + * no such master registered. + */ +struct spi_master *spi_busnum_to_master(u16 bus_num) +{ + if (bus_num) { + char name[8]; + struct kobject *bus; + + snprintf(name, sizeof name, "spi%u", bus_num); + bus = kset_find_obj(&spi_master_class.subsys.kset, name); + if (bus) + return container_of(bus, struct spi_master, cdev.kobj); + } + return NULL; +} +EXPORT_SYMBOL_GPL(spi_busnum_to_master); + + +/*-------------------------------------------------------------------------*/ + +/** + * spi_sync - blocking/synchronous SPI data transfers + * @spi: device with which data will be exchanged + * @message: describes the data transfers + * + * This call may only be used from a context that may sleep. The sleep + * is non-interruptible, and has no timeout. Low-overhead controller + * drivers may DMA directly into and out of the message buffers. + * + * Note that the SPI device's chip select is active during the message, + * and then is normally disabled between messages. Drivers for some + * frequently-used devices may want to minimize costs of selecting a chip, + * by leaving it selected in anticipation that the next message will go + * to the same chip. (That may increase power usage.) + * + * The return value is a negative error code if the message could not be + * submitted, else zero. When the value is zero, then message->status is + * also defined: it's the completion code for the transfer, either zero + * or a negative error code from the controller driver. + */ +int spi_sync(struct spi_device *spi, struct spi_message *message) +{ + DECLARE_COMPLETION(done); + int status; + + message->complete = (void (*)(void *)) complete; + message->context = &done; + status = spi_async(spi, message); + if (status == 0) + wait_for_completion(&done); + message->context = NULL; + return status; +} +EXPORT_SYMBOL_GPL(spi_sync); + +#define SPI_BUFSIZ (SMP_CACHE_BYTES) + +static u8 *buf; + +/** + * spi_write_then_read - SPI synchronous write followed by read + * @spi: device with which data will be exchanged + * @txbuf: data to be written (need not be dma-safe) + * @n_tx: size of txbuf, in bytes + * @rxbuf: buffer into which data will be read + * @n_rx: size of rxbuf, in bytes (need not be dma-safe) + * + * This performs a half duplex MicroWire style transaction with the + * device, sending txbuf and then reading rxbuf. The return value + * is zero for success, else a negative errno status code. + * + * Parameters to this routine are always copied using a small buffer, + * large transfers should use use spi_{async,sync}() calls with + * dma-safe buffers. + */ +int spi_write_then_read(struct spi_device *spi, + const u8 *txbuf, unsigned n_tx, + u8 *rxbuf, unsigned n_rx) +{ + static DECLARE_MUTEX(lock); + + int status; + struct spi_message message; + struct spi_transfer x[2]; + u8 *local_buf; + + /* Use preallocated DMA-safe buffer. We can't avoid copying here, + * (as a pure convenience thing), but we can keep heap costs + * out of the hot path ... + */ + if ((n_tx + n_rx) > SPI_BUFSIZ) + return -EINVAL; + + /* ... unless someone else is using the pre-allocated buffer */ + if (down_trylock(&lock)) { + local_buf = kmalloc(SPI_BUFSIZ, GFP_KERNEL); + if (!local_buf) + return -ENOMEM; + } else + local_buf = buf; + + memset(x, 0, sizeof x); + + memcpy(local_buf, txbuf, n_tx); + x[0].tx_buf = local_buf; + x[0].len = n_tx; + + x[1].rx_buf = local_buf + n_tx; + x[1].len = n_rx; + + /* do the i/o */ + message.transfers = x; + message.n_transfer = ARRAY_SIZE(x); + status = spi_sync(spi, &message); + if (status == 0) { + memcpy(rxbuf, x[1].rx_buf, n_rx); + status = message.status; + } + + if (x[0].tx_buf == buf) + up(&lock); + else + kfree(local_buf); + + return status; +} +EXPORT_SYMBOL_GPL(spi_write_then_read); + +/*-------------------------------------------------------------------------*/ + +static int __init spi_init(void) +{ + buf = kmalloc(SPI_BUFSIZ, SLAB_KERNEL); + if (!buf) + return -ENOMEM; + + bus_register(&spi_bus_type); + class_register(&spi_master_class); + return 0; +} +/* board_info is normally registered in arch_initcall(), + * but even essential drivers wait till later + */ +subsys_initcall(spi_init); + diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h new file mode 100644 index 0000000000000..51a6769114dff --- /dev/null +++ b/include/linux/spi/spi.h @@ -0,0 +1,542 @@ +/* + * Copyright (C) 2005 David Brownell + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + */ + +#ifndef __LINUX_SPI_H +#define __LINUX_SPI_H + +/* + * INTERFACES between SPI master drivers and infrastructure + * (There's no SPI slave support for Linux yet...) + * + * A "struct device_driver" for an spi_device uses "spi_bus_type" and + * needs no special API wrappers (much like platform_bus). These drivers + * are bound to devices based on their names (much like platform_bus), + * and are available in dev->driver. + */ +extern struct bus_type spi_bus_type; + +/** + * struct spi_device - Master side proxy for an SPI slave device + * @dev: Driver model representation of the device. + * @master: SPI controller used with the device. + * @max_speed_hz: Maximum clock rate to be used with this chip + * (on this board); may be changed by the device's driver. + * @chip-select: Chipselect, distinguishing chips handled by "master". + * @mode: The spi mode defines how data is clocked out and in. + * This may be changed by the device's driver. + * @bits_per_word: Data transfers involve one or more words; word sizes + * like eight or 12 bits are common. In-memory wordsizes are + * powers of two bytes (e.g. 20 bit samples use 32 bits). + * This may be changed by the device's driver. + * @irq: Negative, or the number passed to request_irq() to receive + * interrupts from this device. + * @controller_state: Controller's runtime state + * @controller_data: Static board-specific definitions for controller, such + * as FIFO initialization parameters; from board_info.controller_data + * + * An spi_device is used to interchange data between an SPI slave + * (usually a discrete chip) and CPU memory. + * + * In "dev", the platform_data is used to hold information about this + * device that's meaningful to the device's protocol driver, but not + * to its controller. One example might be an identifier for a chip + * variant with slightly different functionality. + */ +struct spi_device { + struct device dev; + struct spi_master *master; + u32 max_speed_hz; + u8 chip_select; + u8 mode; +#define SPI_CPHA 0x01 /* clock phase */ +#define SPI_CPOL 0x02 /* clock polarity */ +#define SPI_MODE_0 (0|0) +#define SPI_MODE_1 (0|SPI_CPHA) +#define SPI_MODE_2 (SPI_CPOL|0) +#define SPI_MODE_3 (SPI_CPOL|SPI_CPHA) +#define SPI_CS_HIGH 0x04 /* chipselect active high? */ + u8 bits_per_word; + int irq; + void *controller_state; + const void *controller_data; + const char *modalias; + + // likely need more hooks for more protocol options affecting how + // the controller talks to its chips, like: + // - bit order (default is wordwise msb-first) + // - memory packing (12 bit samples into low bits, others zeroed) + // - priority + // - chipselect delays + // - ... +}; + +static inline struct spi_device *to_spi_device(struct device *dev) +{ + return container_of(dev, struct spi_device, dev); +} + +/* most drivers won't need to care about device refcounting */ +static inline struct spi_device *spi_dev_get(struct spi_device *spi) +{ + return (spi && get_device(&spi->dev)) ? spi : NULL; +} + +static inline void spi_dev_put(struct spi_device *spi) +{ + if (spi) + put_device(&spi->dev); +} + +/* ctldata is for the bus_master driver's runtime state */ +static inline void *spi_get_ctldata(struct spi_device *spi) +{ + return spi->controller_state; +} + +static inline void spi_set_ctldata(struct spi_device *spi, void *state) +{ + spi->controller_state = state; +} + + +struct spi_message; + + +/** + * struct spi_master - interface to SPI master controller + * @cdev: class interface to this driver + * @bus_num: board-specific (and often SOC-specific) identifier for a + * given SPI controller. + * @num_chipselects: chipselects are used to distinguish individual + * SPI slaves, and are numbered from zero to num_chipselects. + * each slave has a chipselect signal, but it's common that not + * every chipselect is connected to a slave. + * @setup: updates the device mode and clocking records used by a + * device's SPI controller; protocol code may call this. + * @transfer: adds a message to the controller's transfer queue. + * @cleanup: frees controller-specific state + * + * Each SPI master controller can communicate with one or more spi_device + * children. These make a small bus, sharing MOSI, MISO and SCK signals + * but not chip select signals. Each device may be configured to use a + * different clock rate, since those shared signals are ignored unless + * the chip is selected. + * + * The driver for an SPI controller manages access to those devices through + * a queue of spi_message transactions, copyin data between CPU memory and + * an SPI slave device). For each such message it queues, it calls the + * message's completion function when the transaction completes. + */ +struct spi_master { + struct class_device cdev; + + /* other than zero (== assign one dynamically), bus_num is fully + * board-specific. usually that simplifies to being SOC-specific. + * example: one SOC has three SPI controllers, numbered 1..3, + * and one board's schematics might show it using SPI-2. software + * would normally use bus_num=2 for that controller. + */ + u16 bus_num; + + /* chipselects will be integral to many controllers; some others + * might use board-specific GPIOs. + */ + u16 num_chipselect; + + /* setup mode and clock, etc (spi driver may call many times) */ + int (*setup)(struct spi_device *spi); + + /* bidirectional bulk transfers + * + * + The transfer() method may not sleep; its main role is + * just to add the message to the queue. + * + For now there's no remove-from-queue operation, or + * any other request management + * + To a given spi_device, message queueing is pure fifo + * + * + The master's main job is to process its message queue, + * selecting a chip then transferring data + * + If there are multiple spi_device children, the i/o queue + * arbitration algorithm is unspecified (round robin, fifo, + * priority, reservations, preemption, etc) + * + * + Chipselect stays active during the entire message + * (unless modified by spi_transfer.cs_change != 0). + * + The message transfers use clock and SPI mode parameters + * previously established by setup() for this device + */ + int (*transfer)(struct spi_device *spi, + struct spi_message *mesg); + + /* called on release() to free memory provided by spi_master */ + void (*cleanup)(const struct spi_device *spi); +}; + +/* the spi driver core manages memory for the spi_master classdev */ +extern struct spi_master * +spi_alloc_master(struct device *host, unsigned size); + +extern int spi_register_master(struct spi_master *master); +extern void spi_unregister_master(struct spi_master *master); + +extern struct spi_master *spi_busnum_to_master(u16 busnum); + +/*---------------------------------------------------------------------------*/ + +/* + * I/O INTERFACE between SPI controller and protocol drivers + * + * Protocol drivers use a queue of spi_messages, each transferring data + * between the controller and memory buffers. + * + * The spi_messages themselves consist of a series of read+write transfer + * segments. Those segments always read the same number of bits as they + * write; but one or the other is easily ignored by passing a null buffer + * pointer. (This is unlike most types of I/O API, because SPI hardware + * is full duplex.) + * + * NOTE: Allocation of spi_transfer and spi_message memory is entirely + * up to the protocol driver, which guarantees the integrity of both (as + * well as the data buffers) for as long as the message is queued. + */ + +/** + * struct spi_transfer - a read/write buffer pair + * @tx_buf: data to be written (dma-safe address), or NULL + * @rx_buf: data to be read (dma-safe address), or NULL + * @tx_dma: DMA address of buffer, if spi_message.is_dma_mapped + * @rx_dma: DMA address of buffer, if spi_message.is_dma_mapped + * @len: size of rx and tx buffers (in bytes) + * @cs_change: affects chipselect after this transfer completes + * @delay_usecs: microseconds to delay after this transfer before + * (optionally) changing the chipselect status, then starting + * the next transfer or completing this spi_message. + * + * SPI transfers always write the same number of bytes as they read. + * Protocol drivers should always provide rx_buf and/or tx_buf. + * In some cases, they may also want to provide DMA addresses for + * the data being transferred; that may reduce overhead, when the + * underlying driver uses dma. + * + * All SPI transfers start with the relevant chipselect active. Drivers + * can change behavior of the chipselect after the transfer finishes + * (including any mandatory delay). The normal behavior is to leave it + * selected, except for the last transfer in a message. Setting cs_change + * allows two additional behavior options: + * + * (i) If the transfer isn't the last one in the message, this flag is + * used to make the chipselect briefly go inactive in the middle of the + * message. Toggling chipselect in this way may be needed to terminate + * a chip command, letting a single spi_message perform all of group of + * chip transactions together. + * + * (ii) When the transfer is the last one in the message, the chip may + * stay selected until the next transfer. This is purely a performance + * hint; the controller driver may need to select a different device + * for the next message. + */ +struct spi_transfer { + /* it's ok if tx_buf == rx_buf (right?) + * for MicroWire, one buffer must be null + * buffers must work with dma_*map_single() calls + */ + const void *tx_buf; + void *rx_buf; + unsigned len; + + dma_addr_t tx_dma; + dma_addr_t rx_dma; + + unsigned cs_change:1; + u16 delay_usecs; +}; + +/** + * struct spi_message - one multi-segment SPI transaction + * @transfers: the segements of the transaction + * @n_transfer: how many segments + * @spi: SPI device to which the transaction is queued + * @is_dma_mapped: if true, the caller provided both dma and cpu virtual + * addresses for each transfer buffer + * @complete: called to report transaction completions + * @context: the argument to complete() when it's called + * @actual_length: how many bytes were transferd + * @status: zero for success, else negative errno + * @queue: for use by whichever driver currently owns the message + * @state: for use by whichever driver currently owns the message + */ +struct spi_message { + struct spi_transfer *transfers; + unsigned n_transfer; + + struct spi_device *spi; + + unsigned is_dma_mapped:1; + + /* REVISIT: we might want a flag affecting the behavior of the + * last transfer ... allowing things like "read 16 bit length L" + * immediately followed by "read L bytes". Basically imposing + * a specific message scheduling algorithm. + * + * Some controller drivers (message-at-a-time queue processing) + * could provide that as their default scheduling algorithm. But + * others (with multi-message pipelines) would need a flag to + * tell them about such special cases. + */ + + /* completion is reported through a callback */ + void FASTCALL((*complete)(void *context)); + void *context; + unsigned actual_length; + int status; + + /* for optional use by whatever driver currently owns the + * spi_message ... between calls to spi_async and then later + * complete(), that's the spi_master controller driver. + */ + struct list_head queue; + void *state; +}; + +/** + * spi_setup -- setup SPI mode and clock rate + * @spi: the device whose settings are being modified + * + * SPI protocol drivers may need to update the transfer mode if the + * device doesn't work with the mode 0 default. They may likewise need + * to update clock rates or word sizes from initial values. This function + * changes those settings, and must be called from a context that can sleep. + */ +static inline int +spi_setup(struct spi_device *spi) +{ + return spi->master->setup(spi); +} + + +/** + * spi_async -- asynchronous SPI transfer + * @spi: device with which data will be exchanged + * @message: describes the data transfers, including completion callback + * + * This call may be used in_irq and other contexts which can't sleep, + * as well as from task contexts which can sleep. + * + * The completion callback is invoked in a context which can't sleep. + * Before that invocation, the value of message->status is undefined. + * When the callback is issued, message->status holds either zero (to + * indicate complete success) or a negative error code. + * + * Note that although all messages to a spi_device are handled in + * FIFO order, messages may go to different devices in other orders. + * Some device might be higher priority, or have various "hard" access + * time requirements, for example. + */ +static inline int +spi_async(struct spi_device *spi, struct spi_message *message) +{ + message->spi = spi; + return spi->master->transfer(spi, message); +} + +/*---------------------------------------------------------------------------*/ + +/* All these synchronous SPI transfer routines are utilities layered + * over the core async transfer primitive. Here, "synchronous" means + * they will sleep uninterruptibly until the async transfer completes. + */ + +extern int spi_sync(struct spi_device *spi, struct spi_message *message); + +/** + * spi_write - SPI synchronous write + * @spi: device to which data will be written + * @buf: data buffer + * @len: data buffer size + * + * This writes the buffer and returns zero or a negative error code. + * Callable only from contexts that can sleep. + */ +static inline int +spi_write(struct spi_device *spi, const u8 *buf, size_t len) +{ + struct spi_transfer t = { + .tx_buf = buf, + .rx_buf = NULL, + .len = len, + .cs_change = 0, + }; + struct spi_message m = { + .transfers = &t, + .n_transfer = 1, + }; + + return spi_sync(spi, &m); +} + +/** + * spi_read - SPI synchronous read + * @spi: device from which data will be read + * @buf: data buffer + * @len: data buffer size + * + * This writes the buffer and returns zero or a negative error code. + * Callable only from contexts that can sleep. + */ +static inline int +spi_read(struct spi_device *spi, u8 *buf, size_t len) +{ + struct spi_transfer t = { + .tx_buf = NULL, + .rx_buf = buf, + .len = len, + .cs_change = 0, + }; + struct spi_message m = { + .transfers = &t, + .n_transfer = 1, + }; + + return spi_sync(spi, &m); +} + +extern int spi_write_then_read(struct spi_device *spi, + const u8 *txbuf, unsigned n_tx, + u8 *rxbuf, unsigned n_rx); + +/** + * spi_w8r8 - SPI synchronous 8 bit write followed by 8 bit read + * @spi: device with which data will be exchanged + * @cmd: command to be written before data is read back + * + * This returns the (unsigned) eight bit number returned by the + * device, or else a negative error code. Callable only from + * contexts that can sleep. + */ +static inline ssize_t spi_w8r8(struct spi_device *spi, u8 cmd) +{ + ssize_t status; + u8 result; + + status = spi_write_then_read(spi, &cmd, 1, &result, 1); + + /* return negative errno or unsigned value */ + return (status < 0) ? status : result; +} + +/** + * spi_w8r16 - SPI synchronous 8 bit write followed by 16 bit read + * @spi: device with which data will be exchanged + * @cmd: command to be written before data is read back + * + * This returns the (unsigned) sixteen bit number returned by the + * device, or else a negative error code. Callable only from + * contexts that can sleep. + * + * The number is returned in wire-order, which is at least sometimes + * big-endian. + */ +static inline ssize_t spi_w8r16(struct spi_device *spi, u8 cmd) +{ + ssize_t status; + u16 result; + + status = spi_write_then_read(spi, &cmd, 1, (u8 *) &result, 2); + + /* return negative errno or unsigned value */ + return (status < 0) ? status : result; +} + +/*---------------------------------------------------------------------------*/ + +/* + * INTERFACE between board init code and SPI infrastructure. + * + * No SPI driver ever sees these SPI device table segments, but + * it's how the SPI core (or adapters that get hotplugged) grows + * the driver model tree. + * + * As a rule, SPI devices can't be probed. Instead, board init code + * provides a table listing the devices which are present, with enough + * information to bind and set up the device's driver. There's basic + * support for nonstatic configurations too; enough to handle adding + * parport adapters, or microcontrollers acting as USB-to-SPI bridges. + */ + +/* board-specific information about each SPI device */ +struct spi_board_info { + /* the device name and module name are coupled, like platform_bus; + * "modalias" is normally the driver name. + * + * platform_data goes to spi_device.dev.platform_data, + * controller_data goes to spi_device.platform_data, + * irq is copied too + */ + char modalias[KOBJ_NAME_LEN]; + const void *platform_data; + const void *controller_data; + int irq; + + /* slower signaling on noisy or low voltage boards */ + u32 max_speed_hz; + + + /* bus_num is board specific and matches the bus_num of some + * spi_master that will probably be registered later. + * + * chip_select reflects how this chip is wired to that master; + * it's less than num_chipselect. + */ + u16 bus_num; + u16 chip_select; + + /* ... may need additional spi_device chip config data here. + * avoid stuff protocol drivers can set; but include stuff + * needed to behave without being bound to a driver: + * - chipselect polarity + * - quirks like clock rate mattering when not selected + */ +}; + +#ifdef CONFIG_SPI +extern int +spi_register_board_info(struct spi_board_info const *info, unsigned n); +#else +/* board init code may ignore whether SPI is configured or not */ +static inline int +spi_register_board_info(struct spi_board_info const *info, unsigned n) + { return 0; } +#endif + + +/* If you're hotplugging an adapter with devices (parport, usb, etc) + * use spi_new_device() to describe each device. You can also call + * spi_unregister_device() to get start making that device vanish, + * but normally that would be handled by spi_unregister_master(). + */ +extern struct spi_device * +spi_new_device(struct spi_master *, struct spi_board_info *); + +static inline void +spi_unregister_device(struct spi_device *spi) +{ + if (spi) + device_unregister(&spi->dev); +} + +#endif /* __LINUX_SPI_H */ -- cgit 1.2.3-korg From b885244eb2628e0b8206e7edaaa6a314da78e9a4 Mon Sep 17 00:00:00 2001 From: David Brownell Date: Sun, 8 Jan 2006 13:34:23 -0800 Subject: [PATCH] spi: add spi_driver to SPI framework This is a refresh of the "Simple SPI Framework" found in 2.6.15-rc3-mm1 which makes the following changes: * There's now a "struct spi_driver". This increase the footprint of the core a bit, since it now includes code to do what the driver core was previously handling directly. Documentation and comments were updated to match. * spi_alloc_master() now does class_device_initialize(), so it can at least be refcounted before spi_register_master(). To match, spi_register_master() switched over to class_device_add(). * States explicitly that after transfer errors, spi_devices will be deselected. We want fault recovery procedures to work the same for all controller drivers. * Minor tweaks: controller_data no longer points to readonly data; prevent some potential cast-from-null bugs with container_of calls; clarifies some existing kerneldoc, And a few small cleanups. Signed-off-by: David Brownell Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman --- Documentation/spi/spi-summary | 52 ++++++++++++------- drivers/spi/spi.c | 118 ++++++++++++++++++++++++++++++------------ include/linux/spi/spi.h | 75 +++++++++++++++++++-------- 3 files changed, 170 insertions(+), 75 deletions(-) (limited to 'Documentation') diff --git a/Documentation/spi/spi-summary b/Documentation/spi/spi-summary index 00497f95ca4bb..c6152d1ff2b01 100644 --- a/Documentation/spi/spi-summary +++ b/Documentation/spi/spi-summary @@ -1,18 +1,19 @@ Overview of Linux kernel SPI support ==================================== -22-Nov-2005 +02-Dec-2005 What is SPI? ------------ -The "Serial Peripheral Interface" (SPI) is a four-wire point-to-point -serial link used to connect microcontrollers to sensors and memory. +The "Serial Peripheral Interface" (SPI) is a synchronous four wire serial +link used to connect microcontrollers to sensors, memory, and peripherals. The three signal wires hold a clock (SCLK, often on the order of 10 MHz), and parallel data lines with "Master Out, Slave In" (MOSI) or "Master In, Slave Out" (MISO) signals. (Other names are also used.) There are four clocking modes through which data is exchanged; mode-0 and mode-3 are most -commonly used. +commonly used. Each clock cycle shifts data out and data in; the clock +doesn't cycle except when there is data to shift. SPI masters may use a "chip select" line to activate a given SPI slave device, so those three signal wires may be connected to several chips @@ -79,11 +80,18 @@ The header file includes kerneldoc, as does the main source code, and you should certainly read that. This is just an overview, so you get the big picture before the details. +SPI requests always go into I/O queues. Requests for a given SPI device +are always executed in FIFO order, and complete asynchronously through +completion callbacks. There are also some simple synchronous wrappers +for those calls, including ones for common transaction types like writing +a command and then reading its response. + There are two types of SPI driver, here called: Controller drivers ... these are often built in to System-On-Chip processors, and often support both Master and Slave roles. These drivers touch hardware registers and may use DMA. + Or they can be PIO bitbangers, needing just GPIO pins. Protocol drivers ... these pass messages through the controller driver to communicate with a Slave or Master device on the @@ -116,11 +124,6 @@ shows up in sysfs in several locations: managing bus "B". All the spiB.* devices share the same physical SPI bus segment, with SCLK, MOSI, and MISO. -The basic I/O primitive submits an asynchronous message to an I/O queue -maintained by the controller driver. A completion callback is issued -asynchronously when the data transfer(s) in that message completes. -There are also some simple synchronous wrappers for those calls. - How does board-specific init code declare SPI devices? ------------------------------------------------------ @@ -263,33 +266,40 @@ would just be another kernel driver, probably offering some lowlevel access through aio_read(), aio_write(), and ioctl() calls and using the standard userspace sysfs mechanisms to bind to a given SPI device. -SPI protocol drivers are normal device drivers, with no more wrapper -than needed by platform devices: +SPI protocol drivers somewhat resemble platform device drivers: + + static struct spi_driver CHIP_driver = { + .driver = { + .name = "CHIP", + .bus = &spi_bus_type, + .owner = THIS_MODULE, + }, - static struct device_driver CHIP_driver = { - .name = "CHIP", - .bus = &spi_bus_type, .probe = CHIP_probe, - .remove = __exit_p(CHIP_remove), + .remove = __devexit_p(CHIP_remove), .suspend = CHIP_suspend, .resume = CHIP_resume, }; -The SPI core will autmatically attempt to bind this driver to any SPI +The driver core will autmatically attempt to bind this driver to any SPI device whose board_info gave a modalias of "CHIP". Your probe() code might look like this unless you're creating a class_device: - static int __init CHIP_probe(struct device *dev) + static int __devinit CHIP_probe(struct spi_device *spi) { - struct spi_device *spi = to_spi_device(dev); struct CHIP *chip; - struct CHIP_platform_data *pdata = dev->platform_data; + struct CHIP_platform_data *pdata; + + /* assuming the driver requires board-specific data: */ + pdata = &spi->dev.platform_data; + if (!pdata) + return -ENODEV; /* get memory for driver's per-chip state */ chip = kzalloc(sizeof *chip, GFP_KERNEL); if (!chip) return -ENOMEM; - dev_set_drvdata(dev, chip); + dev_set_drvdata(&spi->dev, chip); ... etc return 0; @@ -328,6 +338,8 @@ the driver guarantees that it won't submit any more such messages. - The basic I/O primitive is spi_async(). Async requests may be issued in any context (irq handler, task, etc) and completion is reported using a callback provided with the message. + After any detected error, the chip is deselected and processing + of that spi_message is aborted. - There are also synchronous wrappers like spi_sync(), and wrappers like spi_read(), spi_write(), and spi_write_then_read(). These diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c index 7cd356b176442..2ecb86cb36892 100644 --- a/drivers/spi/spi.c +++ b/drivers/spi/spi.c @@ -26,13 +26,9 @@ #include -/* SPI bustype and spi_master class are registered during early boot, - * usually before board init code provides the SPI device tables, and - * are available later when driver init code needs them. - * - * Drivers for SPI devices started out like those for platform bus - * devices. But both have changed in 2.6.15; maybe this should get - * an "spi_driver" structure at some point (not currently needed) +/* SPI bustype and spi_master class are registered after board init code + * provides the SPI device tables, ensuring that both are present by the + * time controller driver registration causes spi_devices to "enumerate". */ static void spidev_release(struct device *dev) { @@ -83,10 +79,7 @@ static int spi_uevent(struct device *dev, char **envp, int num_envp, #ifdef CONFIG_PM -/* Suspend/resume in "struct device_driver" don't really need that - * strange third parameter, so we just make it a constant and expect - * SPI drivers to ignore it just like most platform drivers do. - * +/* * NOTE: the suspend() method for an spi_master controller driver * should verify that all its child devices are marked as suspended; * suspend requests delivered through sysfs power/state files don't @@ -94,13 +87,14 @@ static int spi_uevent(struct device *dev, char **envp, int num_envp, */ static int spi_suspend(struct device *dev, pm_message_t message) { - int value; + int value; + struct spi_driver *drv = to_spi_driver(dev->driver); - if (!dev->driver || !dev->driver->suspend) + if (!drv || !drv->suspend) return 0; /* suspend will stop irqs and dma; no more i/o */ - value = dev->driver->suspend(dev, message); + value = drv->suspend(to_spi_device(dev), message); if (value == 0) dev->power.power_state = message; return value; @@ -108,13 +102,14 @@ static int spi_suspend(struct device *dev, pm_message_t message) static int spi_resume(struct device *dev) { - int value; + int value; + struct spi_driver *drv = to_spi_driver(dev->driver); - if (!dev->driver || !dev->driver->resume) + if (!drv || !drv->resume) return 0; /* resume may restart the i/o queue */ - value = dev->driver->resume(dev); + value = drv->resume(to_spi_device(dev)); if (value == 0) dev->power.power_state = PMSG_ON; return value; @@ -135,6 +130,41 @@ struct bus_type spi_bus_type = { }; EXPORT_SYMBOL_GPL(spi_bus_type); + +static int spi_drv_probe(struct device *dev) +{ + const struct spi_driver *sdrv = to_spi_driver(dev->driver); + + return sdrv->probe(to_spi_device(dev)); +} + +static int spi_drv_remove(struct device *dev) +{ + const struct spi_driver *sdrv = to_spi_driver(dev->driver); + + return sdrv->remove(to_spi_device(dev)); +} + +static void spi_drv_shutdown(struct device *dev) +{ + const struct spi_driver *sdrv = to_spi_driver(dev->driver); + + sdrv->shutdown(to_spi_device(dev)); +} + +int spi_register_driver(struct spi_driver *sdrv) +{ + sdrv->driver.bus = &spi_bus_type; + if (sdrv->probe) + sdrv->driver.probe = spi_drv_probe; + if (sdrv->remove) + sdrv->driver.remove = spi_drv_remove; + if (sdrv->shutdown) + sdrv->driver.shutdown = spi_drv_shutdown; + return driver_register(&sdrv->driver); +} +EXPORT_SYMBOL_GPL(spi_register_driver); + /*-------------------------------------------------------------------------*/ /* SPI devices should normally not be created by SPI device drivers; that @@ -208,13 +238,15 @@ spi_new_device(struct spi_master *master, struct spi_board_info *chip) if (status < 0) { dev_dbg(dev, "can't %s %s, status %d\n", "add", proxy->dev.bus_id, status); -fail: - class_device_put(&master->cdev); - kfree(proxy); - return NULL; + goto fail; } dev_dbg(dev, "registered child %s\n", proxy->dev.bus_id); return proxy; + +fail: + class_device_put(&master->cdev); + kfree(proxy); + return NULL; } EXPORT_SYMBOL_GPL(spi_new_device); @@ -237,11 +269,11 @@ spi_register_board_info(struct spi_board_info const *info, unsigned n) { struct boardinfo *bi; - bi = kmalloc (sizeof (*bi) + n * sizeof (*info), GFP_KERNEL); + bi = kmalloc(sizeof(*bi) + n * sizeof *info, GFP_KERNEL); if (!bi) return -ENOMEM; bi->n_board_info = n; - memcpy(bi->board_info, info, n * sizeof (*info)); + memcpy(bi->board_info, info, n * sizeof *info); down(&board_lock); list_add_tail(&bi->list, &board_list); @@ -330,6 +362,7 @@ spi_alloc_master(struct device *dev, unsigned size) if (!master) return NULL; + class_device_initialize(&master->cdev); master->cdev.class = &spi_master_class; master->cdev.dev = get_device(dev); class_set_devdata(&master->cdev, &master[1]); @@ -366,7 +399,7 @@ spi_register_master(struct spi_master *master) /* convention: dynamically assigned bus IDs count down from the max */ if (master->bus_num == 0) { master->bus_num = atomic_dec_return(&dyn_bus_id); - dynamic = 0; + dynamic = 1; } /* register the device, then userspace will see it. @@ -374,11 +407,9 @@ spi_register_master(struct spi_master *master) */ snprintf(master->cdev.class_id, sizeof master->cdev.class_id, "spi%u", master->bus_num); - status = class_device_register(&master->cdev); - if (status < 0) { - class_device_put(&master->cdev); + status = class_device_add(&master->cdev); + if (status < 0) goto done; - } dev_dbg(dev, "registered master %s%s\n", master->cdev.class_id, dynamic ? " (dynamic)" : ""); @@ -491,6 +522,7 @@ static u8 *buf; * This performs a half duplex MicroWire style transaction with the * device, sending txbuf and then reading rxbuf. The return value * is zero for success, else a negative errno status code. + * This call may only be used from a context that may sleep. * * Parameters to this routine are always copied using a small buffer, * large transfers should use use spi_{async,sync}() calls with @@ -553,16 +585,38 @@ EXPORT_SYMBOL_GPL(spi_write_then_read); static int __init spi_init(void) { + int status; + buf = kmalloc(SPI_BUFSIZ, SLAB_KERNEL); - if (!buf) - return -ENOMEM; + if (!buf) { + status = -ENOMEM; + goto err0; + } + + status = bus_register(&spi_bus_type); + if (status < 0) + goto err1; - bus_register(&spi_bus_type); - class_register(&spi_master_class); + status = class_register(&spi_master_class); + if (status < 0) + goto err2; return 0; + +err2: + bus_unregister(&spi_bus_type); +err1: + kfree(buf); + buf = NULL; +err0: + return status; } + /* board_info is normally registered in arch_initcall(), * but even essential drivers wait till later + * + * REVISIT only boardinfo really needs static linking. the rest (device and + * driver registration) _could_ be dynamically linked (modular) ... costs + * include needing to have boardinfo data structures be much more public. */ subsys_initcall(spi_init); diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h index 51a6769114dff..c851b3d132080 100644 --- a/include/linux/spi/spi.h +++ b/include/linux/spi/spi.h @@ -20,13 +20,8 @@ #define __LINUX_SPI_H /* - * INTERFACES between SPI master drivers and infrastructure + * INTERFACES between SPI master-side drivers and SPI infrastructure. * (There's no SPI slave support for Linux yet...) - * - * A "struct device_driver" for an spi_device uses "spi_bus_type" and - * needs no special API wrappers (much like platform_bus). These drivers - * are bound to devices based on their names (much like platform_bus), - * and are available in dev->driver. */ extern struct bus_type spi_bus_type; @@ -46,8 +41,8 @@ extern struct bus_type spi_bus_type; * @irq: Negative, or the number passed to request_irq() to receive * interrupts from this device. * @controller_state: Controller's runtime state - * @controller_data: Static board-specific definitions for controller, such - * as FIFO initialization parameters; from board_info.controller_data + * @controller_data: Board-specific definitions for controller, such as + * FIFO initialization parameters; from board_info.controller_data * * An spi_device is used to interchange data between an SPI slave * (usually a discrete chip) and CPU memory. @@ -63,31 +58,32 @@ struct spi_device { u32 max_speed_hz; u8 chip_select; u8 mode; -#define SPI_CPHA 0x01 /* clock phase */ -#define SPI_CPOL 0x02 /* clock polarity */ +#define SPI_CPHA 0x01 /* clock phase */ +#define SPI_CPOL 0x02 /* clock polarity */ #define SPI_MODE_0 (0|0) -#define SPI_MODE_1 (0|SPI_CPHA) +#define SPI_MODE_1 (0|SPI_CPHA) /* (original MicroWire) */ #define SPI_MODE_2 (SPI_CPOL|0) #define SPI_MODE_3 (SPI_CPOL|SPI_CPHA) -#define SPI_CS_HIGH 0x04 /* chipselect active high? */ +#define SPI_CS_HIGH 0x04 /* chipselect active high? */ u8 bits_per_word; int irq; void *controller_state; - const void *controller_data; + void *controller_data; const char *modalias; // likely need more hooks for more protocol options affecting how - // the controller talks to its chips, like: + // the controller talks to each chip, like: // - bit order (default is wordwise msb-first) // - memory packing (12 bit samples into low bits, others zeroed) // - priority + // - drop chipselect after each word // - chipselect delays // - ... }; static inline struct spi_device *to_spi_device(struct device *dev) { - return container_of(dev, struct spi_device, dev); + return dev ? container_of(dev, struct spi_device, dev) : NULL; } /* most drivers won't need to care about device refcounting */ @@ -117,12 +113,38 @@ static inline void spi_set_ctldata(struct spi_device *spi, void *state) struct spi_message; + +struct spi_driver { + int (*probe)(struct spi_device *spi); + int (*remove)(struct spi_device *spi); + void (*shutdown)(struct spi_device *spi); + int (*suspend)(struct spi_device *spi, pm_message_t mesg); + int (*resume)(struct spi_device *spi); + struct device_driver driver; +}; + +static inline struct spi_driver *to_spi_driver(struct device_driver *drv) +{ + return drv ? container_of(drv, struct spi_driver, driver) : NULL; +} + +extern int spi_register_driver(struct spi_driver *sdrv); + +static inline void spi_unregister_driver(struct spi_driver *sdrv) +{ + if (!sdrv) + return; + driver_unregister(&sdrv->driver); +} + + + /** * struct spi_master - interface to SPI master controller * @cdev: class interface to this driver * @bus_num: board-specific (and often SOC-specific) identifier for a * given SPI controller. - * @num_chipselects: chipselects are used to distinguish individual + * @num_chipselect: chipselects are used to distinguish individual * SPI slaves, and are numbered from zero to num_chipselects. * each slave has a chipselect signal, but it's common that not * every chipselect is connected to a slave. @@ -275,7 +297,8 @@ struct spi_transfer { * addresses for each transfer buffer * @complete: called to report transaction completions * @context: the argument to complete() when it's called - * @actual_length: how many bytes were transferd + * @actual_length: the total number of bytes that were transferred in all + * successful segments * @status: zero for success, else negative errno * @queue: for use by whichever driver currently owns the message * @state: for use by whichever driver currently owns the message @@ -295,7 +318,7 @@ struct spi_message { * * Some controller drivers (message-at-a-time queue processing) * could provide that as their default scheduling algorithm. But - * others (with multi-message pipelines) would need a flag to + * others (with multi-message pipelines) could need a flag to * tell them about such special cases. */ @@ -346,6 +369,13 @@ spi_setup(struct spi_device *spi) * FIFO order, messages may go to different devices in other orders. * Some device might be higher priority, or have various "hard" access * time requirements, for example. + * + * On detection of any fault during the transfer, processing of + * the entire message is aborted, and the device is deselected. + * Until returning from the associated message completion callback, + * no other spi_message queued to that device will be processed. + * (This rule applies equally to all the synchronous transfer calls, + * which are wrappers around this core asynchronous primitive.) */ static inline int spi_async(struct spi_device *spi, struct spi_message *message) @@ -484,12 +514,12 @@ struct spi_board_info { * "modalias" is normally the driver name. * * platform_data goes to spi_device.dev.platform_data, - * controller_data goes to spi_device.platform_data, + * controller_data goes to spi_device.controller_data, * irq is copied too */ char modalias[KOBJ_NAME_LEN]; const void *platform_data; - const void *controller_data; + void *controller_data; int irq; /* slower signaling on noisy or low voltage boards */ @@ -525,9 +555,8 @@ spi_register_board_info(struct spi_board_info const *info, unsigned n) /* If you're hotplugging an adapter with devices (parport, usb, etc) - * use spi_new_device() to describe each device. You can also call - * spi_unregister_device() to get start making that device vanish, - * but normally that would be handled by spi_unregister_master(). + * use spi_new_device() to describe each device. You would then call + * spi_unregister_device() to start making that device vanish. */ extern struct spi_device * spi_new_device(struct spi_master *, struct spi_board_info *); -- cgit 1.2.3-korg From 0c868461fcb8413cb9f691d68e5b99b0fd3c0737 Mon Sep 17 00:00:00 2001 From: David Brownell Date: Sun, 8 Jan 2006 13:34:25 -0800 Subject: [PATCH] SPI core tweaks, bugfix This includes various updates to the SPI core: - Fixes a driver model refcount bug in spi_unregister_master() paths. - The spi_master structures now have wrappers which help keep drivers from needing class-level get/put for device data or for refcounts. - Check for a few setup errors that would cause oopsing later. - Docs say more about memory management. Highlights the use of DMA-safe i/o buffers, and zero-initializing spi_message and such metadata. - Provide a simple alloc/free for spi_message and its spi_transfer; this is only one of the possible memory management policies. Nothing to break code that already works. Signed-off-by: David Brownell Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman --- Documentation/spi/spi-summary | 16 +++++++++ drivers/spi/spi.c | 45 ++++++++++++++++---------- include/linux/spi/spi.h | 75 +++++++++++++++++++++++++++++++++++++++---- 3 files changed, 113 insertions(+), 23 deletions(-) (limited to 'Documentation') diff --git a/Documentation/spi/spi-summary b/Documentation/spi/spi-summary index c6152d1ff2b01..761debf748e91 100644 --- a/Documentation/spi/spi-summary +++ b/Documentation/spi/spi-summary @@ -363,6 +363,22 @@ upper boundaries might include sysfs (especially for sensor readings), the input layer, ALSA, networking, MTD, the character device framework, or other Linux subsystems. +Note that there are two types of memory your driver must manage as part +of interacting with SPI devices. + + - I/O buffers use the usual Linux rules, and must be DMA-safe. + You'd normally allocate them from the heap or free page pool. + Don't use the stack, or anything that's declared "static". + + - The spi_message and spi_transfer metadata used to glue those + I/O buffers into a group of protocol transactions. These can + be allocated anywhere it's convenient, including as part of + other allocate-once driver data structures. Zero-init these. + +If you like, spi_message_alloc() and spi_message_free() convenience +routines are available to allocate and zero-initialize an spi_message +with several transfers. + How do I write an "SPI Master Controller Driver"? ------------------------------------------------- diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c index 2ecb86cb36892..3ecedccdb96cc 100644 --- a/drivers/spi/spi.c +++ b/drivers/spi/spi.c @@ -38,7 +38,7 @@ static void spidev_release(struct device *dev) if (spi->master->cleanup) spi->master->cleanup(spi); - class_device_put(&spi->master->cdev); + spi_master_put(spi->master); kfree(dev); } @@ -90,7 +90,7 @@ static int spi_suspend(struct device *dev, pm_message_t message) int value; struct spi_driver *drv = to_spi_driver(dev->driver); - if (!drv || !drv->suspend) + if (!drv->suspend) return 0; /* suspend will stop irqs and dma; no more i/o */ @@ -105,7 +105,7 @@ static int spi_resume(struct device *dev) int value; struct spi_driver *drv = to_spi_driver(dev->driver); - if (!drv || !drv->resume) + if (!drv->resume) return 0; /* resume may restart the i/o queue */ @@ -198,7 +198,7 @@ spi_new_device(struct spi_master *master, struct spi_board_info *chip) /* NOTE: caller did any chip->bus_num checks necessary */ - if (!class_device_get(&master->cdev)) + if (!spi_master_get(master)) return NULL; proxy = kzalloc(sizeof *proxy, GFP_KERNEL); @@ -244,7 +244,7 @@ spi_new_device(struct spi_master *master, struct spi_board_info *chip) return proxy; fail: - class_device_put(&master->cdev); + spi_master_put(master); kfree(proxy); return NULL; } @@ -324,8 +324,6 @@ static void spi_master_release(struct class_device *cdev) struct spi_master *master; master = container_of(cdev, struct spi_master, cdev); - put_device(master->cdev.dev); - master->cdev.dev = NULL; kfree(master); } @@ -339,8 +337,9 @@ static struct class spi_master_class = { /** * spi_alloc_master - allocate SPI master controller * @dev: the controller, possibly using the platform_bus - * @size: how much driver-private data to preallocate; a pointer to this - * memory in the class_data field of the returned class_device + * @size: how much driver-private data to preallocate; the pointer to this + * memory is in the class_data field of the returned class_device, + * accessible with spi_master_get_devdata(). * * This call is used only by SPI master controller drivers, which are the * only ones directly touching chip registers. It's how they allocate @@ -350,14 +349,17 @@ static struct class spi_master_class = { * master structure on success, else NULL. * * The caller is responsible for assigning the bus number and initializing - * the master's methods before calling spi_add_master(), or else (on error) - * calling class_device_put() to prevent a memory leak. + * the master's methods before calling spi_add_master(); and (after errors + * adding the device) calling spi_master_put() to prevent a memory leak. */ struct spi_master * __init_or_module spi_alloc_master(struct device *dev, unsigned size) { struct spi_master *master; + if (!dev) + return NULL; + master = kzalloc(size + sizeof *master, SLAB_KERNEL); if (!master) return NULL; @@ -365,7 +367,7 @@ spi_alloc_master(struct device *dev, unsigned size) class_device_initialize(&master->cdev); master->cdev.class = &spi_master_class; master->cdev.dev = get_device(dev); - class_set_devdata(&master->cdev, &master[1]); + spi_master_set_devdata(master, &master[1]); return master; } @@ -387,6 +389,8 @@ EXPORT_SYMBOL_GPL(spi_alloc_master); * * This must be called from context that can sleep. It returns zero on * success, else a negative error code (dropping the master's refcount). + * After a successful return, the caller is responsible for calling + * spi_unregister_master(). */ int __init_or_module spi_register_master(struct spi_master *master) @@ -396,6 +400,9 @@ spi_register_master(struct spi_master *master) int status = -ENODEV; int dynamic = 0; + if (!dev) + return -ENODEV; + /* convention: dynamically assigned bus IDs count down from the max */ if (master->bus_num == 0) { master->bus_num = atomic_dec_return(&dyn_bus_id); @@ -425,7 +432,7 @@ EXPORT_SYMBOL_GPL(spi_register_master); static int __unregister(struct device *dev, void *unused) { /* note: before about 2.6.14-rc1 this would corrupt memory: */ - device_unregister(dev); + spi_unregister_device(to_spi_device(dev)); return 0; } @@ -440,8 +447,9 @@ static int __unregister(struct device *dev, void *unused) */ void spi_unregister_master(struct spi_master *master) { - class_device_unregister(&master->cdev); (void) device_for_each_child(master->cdev.dev, NULL, __unregister); + class_device_unregister(&master->cdev); + master->cdev.dev = NULL; } EXPORT_SYMBOL_GPL(spi_unregister_master); @@ -487,6 +495,9 @@ EXPORT_SYMBOL_GPL(spi_busnum_to_master); * by leaving it selected in anticipation that the next message will go * to the same chip. (That may increase power usage.) * + * Also, the caller is guaranteeing that the memory associated with the + * message will not be freed before this call returns. + * * The return value is a negative error code if the message could not be * submitted, else zero. When the value is zero, then message->status is * also defined: it's the completion code for the transfer, either zero @@ -524,9 +535,9 @@ static u8 *buf; * is zero for success, else a negative errno status code. * This call may only be used from a context that may sleep. * - * Parameters to this routine are always copied using a small buffer, - * large transfers should use use spi_{async,sync}() calls with - * dma-safe buffers. + * Parameters to this routine are always copied using a small buffer; + * performance-sensitive or bulk transfer code should instead use + * spi_{async,sync}() calls with dma-safe buffers. */ int spi_write_then_read(struct spi_device *spi, const u8 *txbuf, unsigned n_tx, diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h index c851b3d132080..6a41e2650b2ee 100644 --- a/include/linux/spi/spi.h +++ b/include/linux/spi/spi.h @@ -60,8 +60,8 @@ struct spi_device { u8 mode; #define SPI_CPHA 0x01 /* clock phase */ #define SPI_CPOL 0x02 /* clock polarity */ -#define SPI_MODE_0 (0|0) -#define SPI_MODE_1 (0|SPI_CPHA) /* (original MicroWire) */ +#define SPI_MODE_0 (0|0) /* (original MicroWire) */ +#define SPI_MODE_1 (0|SPI_CPHA) #define SPI_MODE_2 (SPI_CPOL|0) #define SPI_MODE_3 (SPI_CPOL|SPI_CPHA) #define SPI_CS_HIGH 0x04 /* chipselect active high? */ @@ -209,6 +209,30 @@ struct spi_master { void (*cleanup)(const struct spi_device *spi); }; +static inline void *spi_master_get_devdata(struct spi_master *master) +{ + return class_get_devdata(&master->cdev); +} + +static inline void spi_master_set_devdata(struct spi_master *master, void *data) +{ + class_set_devdata(&master->cdev, data); +} + +static inline struct spi_master *spi_master_get(struct spi_master *master) +{ + if (!master || !class_device_get(&master->cdev)) + return NULL; + return master; +} + +static inline void spi_master_put(struct spi_master *master) +{ + if (master) + class_device_put(&master->cdev); +} + + /* the spi driver core manages memory for the spi_master classdev */ extern struct spi_master * spi_alloc_master(struct device *host, unsigned size); @@ -271,11 +295,17 @@ extern struct spi_master *spi_busnum_to_master(u16 busnum); * stay selected until the next transfer. This is purely a performance * hint; the controller driver may need to select a different device * for the next message. + * + * The code that submits an spi_message (and its spi_transfers) + * to the lower layers is responsible for managing its memory. + * Zero-initialize every field you don't set up explicitly, to + * insulate against future API updates. */ struct spi_transfer { /* it's ok if tx_buf == rx_buf (right?) * for MicroWire, one buffer must be null - * buffers must work with dma_*map_single() calls + * buffers must work with dma_*map_single() calls, unless + * spi_message.is_dma_mapped reports a pre-existing mapping */ const void *tx_buf; void *rx_buf; @@ -302,6 +332,11 @@ struct spi_transfer { * @status: zero for success, else negative errno * @queue: for use by whichever driver currently owns the message * @state: for use by whichever driver currently owns the message + * + * The code that submits an spi_message (and its spi_transfers) + * to the lower layers is responsible for managing its memory. + * Zero-initialize every field you don't set up explicitly, to + * insulate against future API updates. */ struct spi_message { struct spi_transfer *transfers; @@ -336,6 +371,29 @@ struct spi_message { void *state; }; +/* It's fine to embed message and transaction structures in other data + * structures so long as you don't free them while they're in use. + */ + +static inline struct spi_message *spi_message_alloc(unsigned ntrans, gfp_t flags) +{ + struct spi_message *m; + + m = kzalloc(sizeof(struct spi_message) + + ntrans * sizeof(struct spi_transfer), + flags); + if (m) { + m->transfers = (void *)(m + 1); + m->n_transfer = ntrans; + } + return m; +} + +static inline void spi_message_free(struct spi_message *m) +{ + kfree(m); +} + /** * spi_setup -- setup SPI mode and clock rate * @spi: the device whose settings are being modified @@ -363,7 +421,10 @@ spi_setup(struct spi_device *spi) * The completion callback is invoked in a context which can't sleep. * Before that invocation, the value of message->status is undefined. * When the callback is issued, message->status holds either zero (to - * indicate complete success) or a negative error code. + * indicate complete success) or a negative error code. After that + * callback returns, the driver which issued the transfer request may + * deallocate the associated memory; it's no longer in use by any SPI + * core or controller driver code. * * Note that although all messages to a spi_device are handled in * FIFO order, messages may go to different devices in other orders. @@ -445,6 +506,7 @@ spi_read(struct spi_device *spi, u8 *buf, size_t len) return spi_sync(spi, &m); } +/* this copies txbuf and rxbuf data; for small transfers only! */ extern int spi_write_then_read(struct spi_device *spi, const u8 *txbuf, unsigned n_tx, u8 *rxbuf, unsigned n_rx); @@ -555,8 +617,9 @@ spi_register_board_info(struct spi_board_info const *info, unsigned n) /* If you're hotplugging an adapter with devices (parport, usb, etc) - * use spi_new_device() to describe each device. You would then call - * spi_unregister_device() to start making that device vanish. + * use spi_new_device() to describe each device. You can also call + * spi_unregister_device() to start making that device vanish, but + * normally that would be handled by spi_unregister_master(). */ extern struct spi_device * spi_new_device(struct spi_master *, struct spi_board_info *); -- cgit 1.2.3-korg From 7111763d391b0c5a949a4f2575aa88cd585f0ff6 Mon Sep 17 00:00:00 2001 From: David Brownell Date: Sun, 8 Jan 2006 13:34:29 -0800 Subject: [PATCH] spi: misc fixes This collects some small SPI patches that seem to be missing from the MM tree: - spi_butterfly kbuild hooks got dropped somehow; this restores them - quick fix for a (theoretical?) m25p80_write() oops noted by Andrew - quick fix for a potential config-specific oops for mtd_dataflash() - minor doc tweaks Signed-off-by: David Brownell Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman --- Documentation/spi/spi-summary | 13 +++++++++++++ drivers/mtd/devices/m25p80.c | 4 +++- drivers/mtd/devices/mtd_dataflash.c | 2 +- drivers/spi/Kconfig | 10 ++++++++++ drivers/spi/Makefile | 1 + 5 files changed, 28 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/spi/spi-summary b/Documentation/spi/spi-summary index 761debf748e91..a5ffba33a3518 100644 --- a/Documentation/spi/spi-summary +++ b/Documentation/spi/spi-summary @@ -115,6 +115,9 @@ shows up in sysfs in several locations: /sys/devices/.../CTLR/spiB.C ... spi_device for on bus "B", chipselect C, accessed through CTLR. + /sys/devices/.../CTLR/spiB.C/modalias ... identifies the driver + that should be used with this device (for hotplug/coldplug) + /sys/bus/spi/devices/spiB.C ... symlink to the physical spiB-C device @@ -247,6 +250,12 @@ driver is registered: Like with other static board-specific setup, you won't unregister those. +The widely used "card" style computers bundle memory, cpu, and little else +onto a card that's maybe just thirty square centimeters. On such systems, +your arch/.../mach-.../board-*.c file would primarily provide information +about the devices on the mainboard into which such a card is plugged. That +certainly includes SPI devices hooked up through the card connectors! + NON-STATIC CONFIGURATIONS @@ -258,6 +267,10 @@ up the spi bus master, and will likely need spi_new_device() to provide the board info based on the board that was hotplugged. Of course, you'd later call at least spi_unregister_device() when that board is removed. +When Linux includes support for MMC/SD/SDIO/DataFlash cards through SPI, those +configurations will also be dynamic. Fortunately, those devices all support +basic device identification probes, so that support should hotplug normally. + How do I write an "SPI Protocol Driver"? ---------------------------------------- diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c index 45108ed85588b..d5f24089be717 100644 --- a/drivers/mtd/devices/m25p80.c +++ b/drivers/mtd/devices/m25p80.c @@ -378,7 +378,9 @@ static int m25p80_write(struct mtd_info *mtd, loff_t to, size_t len, spi_sync(flash->spi, &m); - *retlen += m.actual_length - sizeof(flash->command); + if (retlen) + *retlen += m.actual_length + - sizeof(flash->command); } } diff --git a/drivers/mtd/devices/mtd_dataflash.c b/drivers/mtd/devices/mtd_dataflash.c index 99d3a0320fc9c..155737e7483f6 100644 --- a/drivers/mtd/devices/mtd_dataflash.c +++ b/drivers/mtd/devices/mtd_dataflash.c @@ -508,7 +508,7 @@ add_dataflash(struct spi_device *spi, char *name, priv->partitioned = 1; return add_mtd_partitions(device, parts, nr_parts); } - } else if (pdata->nr_parts) + } else if (pdata && pdata->nr_parts) dev_warn(&spi->dev, "ignoring %d default partitions on %s\n", pdata->nr_parts, device->name); diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index 9b21c5d77b4a3..7a75faeb0526d 100644 --- a/drivers/spi/Kconfig +++ b/drivers/spi/Kconfig @@ -65,6 +65,16 @@ config SPI_BITBANG need it. You only need to select this explicitly to support driver modules that aren't part of this kernel tree. +config SPI_BUTTERFLY + tristate "Parallel port adapter for AVR Butterfly (DEVELOPMENT)" + depends on SPI_MASTER && PARPORT && EXPERIMENTAL + select SPI_BITBANG + help + This uses a custom parallel port cable to connect to an AVR + Butterfly , an + inexpensive battery powered microcontroller evaluation board. + This same cable can be used to flash new firmware. + # # Add new SPI master controllers in alphabetical order above this line # diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile index 5da6a4df40129..c2c87e845abf8 100644 --- a/drivers/spi/Makefile +++ b/drivers/spi/Makefile @@ -12,6 +12,7 @@ obj-$(CONFIG_SPI_MASTER) += spi.o # SPI master controller drivers (bus) obj-$(CONFIG_SPI_BITBANG) += spi_bitbang.o +obj-$(CONFIG_SPI_BUTTERFLY) += spi_butterfly.o # ... add above this line ... # SPI protocol drivers (device/link on bus) -- cgit 1.2.3-korg From 2e10c84b9cf0b2d269c5629048d8d6e35eaf6b2b Mon Sep 17 00:00:00 2001 From: David Brownell Date: Wed, 11 Jan 2006 11:23:49 -0800 Subject: [PATCH] SPI: add spi_butterfly driver This adds a bitbanging parport based adaptor cable for AVR Butterfly, giving SPI links to its DataFlash chip and (eventually) firmware running in the card. Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman --- Documentation/spi/butterfly | 57 ++++++ drivers/spi/Kconfig | 10 ++ drivers/spi/spi_butterfly.c | 423 ++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 490 insertions(+) create mode 100644 Documentation/spi/butterfly create mode 100644 drivers/spi/spi_butterfly.c (limited to 'Documentation') diff --git a/Documentation/spi/butterfly b/Documentation/spi/butterfly new file mode 100644 index 0000000000000..a2e8c8d90e350 --- /dev/null +++ b/Documentation/spi/butterfly @@ -0,0 +1,57 @@ +spi_butterfly - parport-to-butterfly adapter driver +=================================================== + +This is a hardware and software project that includes building and using +a parallel port adapter cable, together with an "AVR Butterfly" to run +firmware for user interfacing and/or sensors. A Butterfly is a $US20 +battery powered card with an AVR microcontroller and lots of goodies: +sensors, LCD, flash, toggle stick, and more. You can use AVR-GCC to +develop firmware for this, and flash it using this adapter cable. + +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. + + +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). + + Signal Butterfly Parport (DB-25) + ------ --------- --------------- + SCK = J403.PB1/SCK = pin 2/D0 + RESET = J403.nRST = pin 3/D1 + VCC = J403.VCC_EXT = pin 8/D6 + MOSI = J403.PB2/MOSI = pin 9/D7 + MISO = J403.PB3/MISO = pin 11/S7,nBUSY + GND = J403.GND = pin 23/GND + +Then to let Linux master that bus to talk to the DataFlash chip, you must +(a) flash new firmware that disables SPI (set PRR.2, and disable pullups +by clearing PORTB.[0-3]); (b) configure the mtd_dataflash driver; and +(c) cable in the chipselect. + + Signal Butterfly Parport (DB-25) + ------ --------- --------------- + VCC = J400.VCC_EXT = pin 7/D5 + 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: + + Signal Butterfly Parport (DB-25) + ------ --------- --------------- + SCK = J403.PE4/USCK = pin 5/D3 + MOSI = J403.PE5/DI = pin 6/D4 + MISO = J403.PE6/DO = pin 12/S5,nPAPEROUT + GND = J403.GND = pin 22/GND + + IRQ = J402.PF4 = pin 10/S6,ACK + GND = J402.GND(P2) = pin 25/GND + diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index 7a75faeb0526d..b77dbd63e596f 100644 --- a/drivers/spi/Kconfig +++ b/drivers/spi/Kconfig @@ -75,6 +75,16 @@ config SPI_BUTTERFLY inexpensive battery powered microcontroller evaluation board. This same cable can be used to flash new firmware. +config SPI_BUTTERFLY + tristate "Parallel port adapter for AVR Butterfly (DEVELOPMENT)" + depends on SPI_MASTER && PARPORT && EXPERIMENTAL + select SPI_BITBANG + help + This uses a custom parallel port cable to connect to an AVR + Butterfly , an + inexpensive battery powered microcontroller evaluation board. + This same cable can be used to flash new firmware. + # # Add new SPI master controllers in alphabetical order above this line # diff --git a/drivers/spi/spi_butterfly.c b/drivers/spi/spi_butterfly.c new file mode 100644 index 0000000000000..79a3c59615ab9 --- /dev/null +++ b/drivers/spi/spi_butterfly.c @@ -0,0 +1,423 @@ +/* + * spi_butterfly.c - parport-to-butterfly adapter + * + * Copyright (C) 2005 David Brownell + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + */ +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +#include + + +/* + * This uses SPI to talk with an "AVR Butterfly", which is a $US20 card + * with a battery powered AVR microcontroller and lots of goodies. You + * can use GCC to develop firmware for this. + * + * See Documentation/spi/butterfly for information about how to build + * and use this custom parallel port cable. + */ + +#undef HAVE_USI /* nyet */ + + +/* DATA output bits (pins 2..9 == D0..D7) */ +#define butterfly_nreset (1 << 1) /* pin 3 */ + +#define spi_sck_bit (1 << 0) /* pin 2 */ +#define spi_mosi_bit (1 << 7) /* pin 9 */ + +#define usi_sck_bit (1 << 3) /* pin 5 */ +#define usi_mosi_bit (1 << 4) /* pin 6 */ + +#define vcc_bits ((1 << 6) | (1 << 5)) /* pins 7, 8 */ + +/* STATUS input bits */ +#define spi_miso_bit PARPORT_STATUS_BUSY /* pin 11 */ + +#define usi_miso_bit PARPORT_STATUS_PAPEROUT /* pin 12 */ + +/* CONTROL output bits */ +#define spi_cs_bit PARPORT_CONTROL_SELECT /* pin 17 */ +/* USI uses no chipselect */ + + + +static inline struct butterfly *spidev_to_pp(struct spi_device *spi) +{ + return spi->controller_data; +} + +static inline int is_usidev(struct spi_device *spi) +{ +#ifdef HAVE_USI + return spi->chip_select != 1; +#else + return 0; +#endif +} + + +struct butterfly { + /* REVISIT ... for now, this must be first */ + struct spi_bitbang bitbang; + + struct parport *port; + struct pardevice *pd; + + u8 lastbyte; + + struct spi_device *dataflash; + struct spi_device *butterfly; + struct spi_board_info info[2]; + +}; + +/*----------------------------------------------------------------------*/ + +/* + * these routines may be slower than necessary because they're hiding + * the fact that there are two different SPI busses on this cable: one + * to the DataFlash chip (or AVR SPI controller), the other to the + * AVR USI controller. + */ + +static inline void +setsck(struct spi_device *spi, int is_on) +{ + struct butterfly *pp = spidev_to_pp(spi); + u8 bit, byte = pp->lastbyte; + + if (is_usidev(spi)) + bit = usi_sck_bit; + else + bit = spi_sck_bit; + + if (is_on) + byte |= bit; + else + byte &= ~bit; + parport_write_data(pp->port, byte); + pp->lastbyte = byte; +} + +static inline void +setmosi(struct spi_device *spi, int is_on) +{ + struct butterfly *pp = spidev_to_pp(spi); + u8 bit, byte = pp->lastbyte; + + if (is_usidev(spi)) + bit = usi_mosi_bit; + else + bit = spi_mosi_bit; + + if (is_on) + byte |= bit; + else + byte &= ~bit; + parport_write_data(pp->port, byte); + pp->lastbyte = byte; +} + +static inline int getmiso(struct spi_device *spi) +{ + struct butterfly *pp = spidev_to_pp(spi); + int value; + u8 bit; + + if (is_usidev(spi)) + bit = usi_miso_bit; + else + bit = spi_miso_bit; + + /* only STATUS_BUSY is NOT negated */ + value = !(parport_read_status(pp->port) & bit); + return (bit == PARPORT_STATUS_BUSY) ? value : !value; +} + +static void butterfly_chipselect(struct spi_device *spi, int value) +{ + struct butterfly *pp = spidev_to_pp(spi); + + /* set default clock polarity */ + if (value) + setsck(spi, spi->mode & SPI_CPOL); + + /* no chipselect on this USI link config */ + if (is_usidev(spi)) + return; + + /* here, value == "activate or not" */ + + /* most PARPORT_CONTROL_* bits are negated */ + if (spi_cs_bit == PARPORT_CONTROL_INIT) + value = !value; + + /* here, value == "bit value to write in control register" */ + + parport_frob_control(pp->port, spi_cs_bit, value ? spi_cs_bit : 0); +} + + +/* we only needed to implement one mode here, and choose SPI_MODE_0 */ + +#define spidelay(X) do{}while(0) +//#define spidelay ndelay + +#define EXPAND_BITBANG_TXRX +#include + +static u32 +butterfly_txrx_word_mode0(struct spi_device *spi, + unsigned nsecs, + u32 word, u8 bits) +{ + return bitbang_txrx_be_cpha0(spi, nsecs, 0, word, bits); +} + +/*----------------------------------------------------------------------*/ + +/* override default partitioning with cmdlinepart */ +static struct mtd_partition partitions[] = { { + /* JFFS2 wants partitions of 4*N blocks for this device ... */ + + /* sector 0 = 8 pages * 264 bytes/page (1 block) + * sector 1 = 248 pages * 264 bytes/page + */ + .name = "bookkeeping", // 66 KB + .offset = 0, + .size = (8 + 248) * 264, +// .mask_flags = MTD_WRITEABLE, +}, { + /* sector 2 = 256 pages * 264 bytes/page + * sectors 3-5 = 512 pages * 264 bytes/page + */ + .name = "filesystem", // 462 KB + .offset = MTDPART_OFS_APPEND, + .size = MTDPART_SIZ_FULL, +} }; + +static struct flash_platform_data flash = { + .name = "butterflash", + .parts = partitions, + .nr_parts = ARRAY_SIZE(partitions), +}; + + +/* REVISIT remove this ugly global and its "only one" limitation */ +static struct butterfly *butterfly; + +static void butterfly_attach(struct parport *p) +{ + struct pardevice *pd; + int status; + struct butterfly *pp; + struct spi_master *master; + struct platform_device *pdev; + + if (butterfly) + return; + + /* REVISIT: this just _assumes_ a butterfly is there ... no probe, + * and no way to be selective about what it binds to. + */ + + /* FIXME where should master->cdev.dev come from? + * e.g. /sys/bus/pnp0/00:0b, some PCI thing, etc + * setting up a platform device like this is an ugly kluge... + */ + pdev = platform_device_register_simple("butterfly", -1, NULL, 0); + + master = spi_alloc_master(&pdev->dev, sizeof *pp); + if (!master) { + status = -ENOMEM; + goto done; + } + pp = spi_master_get_devdata(master); + + /* + * SPI and bitbang hookup + * + * use default setup(), cleanup(), and transfer() methods; and + * only bother implementing mode 0. Start it later. + */ + master->bus_num = 42; + master->num_chipselect = 2; + + pp->bitbang.master = spi_master_get(master); + pp->bitbang.chipselect = butterfly_chipselect; + pp->bitbang.txrx_word[SPI_MODE_0] = butterfly_txrx_word_mode0; + + /* + * parport hookup + */ + pp->port = p; + pd = parport_register_device(p, "spi_butterfly", + NULL, NULL, NULL, + 0 /* FLAGS */, pp); + if (!pd) { + status = -ENOMEM; + goto clean0; + } + pp->pd = pd; + + status = parport_claim(pd); + if (status < 0) + goto clean1; + + /* + * Butterfly reset, powerup, run firmware + */ + pr_debug("%s: powerup/reset Butterfly\n", p->name); + + /* nCS for dataflash (this bit is inverted on output) */ + parport_frob_control(pp->port, spi_cs_bit, 0); + + /* stabilize power with chip in reset (nRESET), and + * both spi_sck_bit and usi_sck_bit clear (CPOL=0) + */ + pp->lastbyte |= vcc_bits; + parport_write_data(pp->port, pp->lastbyte); + msleep(5); + + /* take it out of reset; assume long reset delay */ + pp->lastbyte |= butterfly_nreset; + parport_write_data(pp->port, pp->lastbyte); + msleep(100); + + + /* + * Start SPI ... for now, hide that we're two physical busses. + */ + status = spi_bitbang_start(&pp->bitbang); + if (status < 0) + goto clean2; + + /* Bus 1 lets us talk to at45db041b (firmware disables AVR) + * or AVR (firmware resets at45, acts as spi slave) + */ + pp->info[0].max_speed_hz = 15 * 1000 * 1000; + strcpy(pp->info[0].modalias, "mtd_dataflash"); + pp->info[0].platform_data = &flash; + pp->info[0].chip_select = 1; + pp->info[0].controller_data = pp; + pp->dataflash = spi_new_device(pp->bitbang.master, &pp->info[0]); + if (pp->dataflash) + pr_debug("%s: dataflash at %s\n", p->name, + pp->dataflash->dev.bus_id); + +#ifdef HAVE_USI + /* even more custom AVR firmware */ + pp->info[1].max_speed_hz = 10 /* ?? */ * 1000 * 1000; + strcpy(pp->info[1].modalias, "butterfly"); + // pp->info[1].platform_data = ... TBD ... ; + pp->info[1].chip_select = 2, + pp->info[1].controller_data = pp; + pp->butterfly = spi_new_device(pp->bitbang.master, &pp->info[1]); + if (pp->butterfly) + pr_debug("%s: butterfly at %s\n", p->name, + pp->butterfly->dev.bus_id); + + /* FIXME setup ACK for the IRQ line ... */ +#endif + + // dev_info(_what?_, ...) + pr_info("%s: AVR Butterfly\n", p->name); + butterfly = pp; + return; + +clean2: + /* turn off VCC */ + parport_write_data(pp->port, 0); + + parport_release(pp->pd); +clean1: + parport_unregister_device(pd); +clean0: + (void) spi_master_put(pp->bitbang.master); +done: + platform_device_unregister(pdev); + pr_debug("%s: butterfly probe, fail %d\n", p->name, status); +} + +static void butterfly_detach(struct parport *p) +{ + struct butterfly *pp; + struct platform_device *pdev; + int status; + + /* FIXME this global is ugly ... but, how to quickly get from + * the parport to the "struct butterfly" associated with it? + * "old school" driver-internal device lists? + */ + if (!butterfly || butterfly->port != p) + return; + pp = butterfly; + butterfly = NULL; + +#ifdef HAVE_USI + spi_unregister_device(pp->butterfly); + pp->butterfly = NULL; +#endif + spi_unregister_device(pp->dataflash); + pp->dataflash = NULL; + + status = spi_bitbang_stop(&pp->bitbang); + + /* turn off VCC */ + parport_write_data(pp->port, 0); + msleep(10); + + parport_release(pp->pd); + parport_unregister_device(pp->pd); + + pdev = to_platform_device(pp->bitbang.master->cdev.dev); + + (void) spi_master_put(pp->bitbang.master); + + platform_device_unregister(pdev); +} + +static struct parport_driver butterfly_driver = { + .name = "spi_butterfly", + .attach = butterfly_attach, + .detach = butterfly_detach, +}; + + +static int __init butterfly_init(void) +{ + return parport_register_driver(&butterfly_driver); +} +device_initcall(butterfly_init); + +static void __exit butterfly_exit(void) +{ + parport_unregister_driver(&butterfly_driver); +} +module_exit(butterfly_exit); + +MODULE_LICENSE("GPL"); -- cgit 1.2.3-korg From e1b114ee90040af5108973abd1a82babc4905868 Mon Sep 17 00:00:00 2001 From: Xose Vazquez Perez Date: Sat, 14 Jan 2006 12:57:41 +0100 Subject: [PATCH] docs: update some updated code docs Based on comments from Randy Dunlap on my previous commit 5b0ed2c64d8fdafb5fcfb3baabdd288628b1ff9b Signed-off-by: Linus Torvalds --- Documentation/SubmittingDrivers | 2 +- Documentation/SubmittingPatches | 3 ++- 2 files changed, 3 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/SubmittingDrivers b/Documentation/SubmittingDrivers index dd311cff1cc30..6bd30fdd0786b 100644 --- a/Documentation/SubmittingDrivers +++ b/Documentation/SubmittingDrivers @@ -143,7 +143,7 @@ KernelNewbies: http://kernelnewbies.org/ Linux USB project: - http://linux-usb.sourceforge.net/ + http://www.linux-usb.org/ How to NOT write kernel driver by arjanv@redhat.com http://people.redhat.com/arjanv/olspaper.pdf diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index 6198e5ebcf65b..c2c85bcb3d438 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -478,10 +478,11 @@ Andrew Morton, "The perfect patch" (tpp). Jeff Garzik, "Linux kernel patch submission format." -Greg Kroah, "How to piss off a kernel subsystem maintainer". +Greg Kroah-Hartman "How to piss off a kernel subsystem maintainer". + NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people!. -- cgit 1.2.3-korg From 7339ff8302fd70aabf5f1ae26e0c4905fa74a495 Mon Sep 17 00:00:00 2001 From: Robin Holt Date: Sat, 14 Jan 2006 13:20:48 -0800 Subject: [PATCH] Add tmpfs options for memory placement policies Anything that writes into a tmpfs filesystem is liable to disproportionately decrease the available memory on a particular node. Since there's no telling what sort of application (e.g. dd/cp/cat) might be dropping large files there, this lets the admin choose the appropriate default behavior for their site's situation. Introduce a tmpfs mount option which allows specifying a memory policy and a second option to specify the nodelist for that policy. With the default policy, tmpfs will behave as it does today. This patch adds support for preferred, bind, and interleave policies. The default policy will cause pages to be added to tmpfs files on the node which is doing the writing. Some jobs expect a single process to create and manage the tmpfs files. This results in a node which has a significantly reduced number of free pages. With this patch, the administrator can specify the policy and nodes for that policy where they would prefer allocations. This patch was originally written by Brent Casavant and Hugh Dickins. I added support for the bind and preferred policies and the mpol_nodelist mount option. Signed-off-by: Brent Casavant Signed-off-by: Hugh Dickins Signed-off-by: Robin Holt Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/filesystems/tmpfs.txt | 12 ++++++++++++ fs/hugetlbfs/inode.c | 2 +- include/linux/mempolicy.h | 11 ++++------- include/linux/shmem_fs.h | 2 ++ mm/mempolicy.c | 24 +++++++++++++++++++++++ mm/shmem.c | 39 ++++++++++++++++++++++++++++++------- 6 files changed, 75 insertions(+), 15 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/tmpfs.txt b/Documentation/filesystems/tmpfs.txt index 0d783c504eade..dbe4d87d26154 100644 --- a/Documentation/filesystems/tmpfs.txt +++ b/Documentation/filesystems/tmpfs.txt @@ -78,6 +78,18 @@ use up all the memory on the machine; but enhances the scalability of that instance in a system with many cpus making intensive use of it. +tmpfs has a mount option to set the NUMA memory allocation policy for +all files in that instance: +mpol=interleave prefers to allocate memory from each node in turn +mpol=default prefers to allocate memory from the local node +mpol=bind prefers to allocate from mpol_nodelist +mpol=preferred prefers to allocate from first node in mpol_nodelist + +The following mount option is used in conjunction with mpol=interleave, +mpol=bind or mpol=preferred: +mpol_nodelist: nodelist suitable for parsing with nodelist_parse. + + To specify the initial root directory you can use the following mount options: diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c index ab4c3a9d51b88..f568102da1e8d 100644 --- a/fs/hugetlbfs/inode.c +++ b/fs/hugetlbfs/inode.c @@ -402,7 +402,7 @@ static struct inode *hugetlbfs_get_inode(struct super_block *sb, uid_t uid, inode->i_mapping->backing_dev_info =&hugetlbfs_backing_dev_info; inode->i_atime = inode->i_mtime = inode->i_ctime = CURRENT_TIME; info = HUGETLBFS_I(inode); - mpol_shared_policy_init(&info->policy); + mpol_shared_policy_init(&info->policy, MPOL_DEFAULT, NULL); switch (mode & S_IFMT) { default: init_special_inode(inode, mode, dev); diff --git a/include/linux/mempolicy.h b/include/linux/mempolicy.h index c7ac77e873b3f..d6a53ed6ab6c5 100644 --- a/include/linux/mempolicy.h +++ b/include/linux/mempolicy.h @@ -132,12 +132,8 @@ struct shared_policy { spinlock_t lock; }; -static inline void mpol_shared_policy_init(struct shared_policy *info) -{ - info->root = RB_ROOT; - spin_lock_init(&info->lock); -} - +void mpol_shared_policy_init(struct shared_policy *info, int policy, + nodemask_t *nodes); int mpol_set_shared_policy(struct shared_policy *info, struct vm_area_struct *vma, struct mempolicy *new); @@ -211,7 +207,8 @@ static inline int mpol_set_shared_policy(struct shared_policy *info, return -EINVAL; } -static inline void mpol_shared_policy_init(struct shared_policy *info) +static inline void mpol_shared_policy_init(struct shared_policy *info, + int policy, nodemask_t *nodes) { } diff --git a/include/linux/shmem_fs.h b/include/linux/shmem_fs.h index c3e598276e78e..c057f0b32318b 100644 --- a/include/linux/shmem_fs.h +++ b/include/linux/shmem_fs.h @@ -26,6 +26,8 @@ struct shmem_sb_info { unsigned long free_blocks; /* How many are left for allocation */ unsigned long max_inodes; /* How many inodes are allowed */ unsigned long free_inodes; /* How many are left for allocation */ + int policy; /* Default NUMA memory alloc policy */ + nodemask_t policy_nodes; /* nodemask for preferred and bind */ spinlock_t stat_lock; }; diff --git a/mm/mempolicy.c b/mm/mempolicy.c index b62cab575a84b..3171f884d2459 100644 --- a/mm/mempolicy.c +++ b/mm/mempolicy.c @@ -1359,6 +1359,30 @@ restart: return 0; } +void mpol_shared_policy_init(struct shared_policy *info, int policy, + nodemask_t *policy_nodes) +{ + info->root = RB_ROOT; + spin_lock_init(&info->lock); + + if (policy != MPOL_DEFAULT) { + struct mempolicy *newpol; + + /* Falls back to MPOL_DEFAULT on any error */ + newpol = mpol_new(policy, policy_nodes); + if (!IS_ERR(newpol)) { + /* Create pseudo-vma that contains just the policy */ + struct vm_area_struct pvma; + + memset(&pvma, 0, sizeof(struct vm_area_struct)); + /* Policy covers entire file */ + pvma.vm_end = TASK_SIZE; + mpol_set_shared_policy(info, &pvma, newpol); + mpol_free(newpol); + } + } +} + int mpol_set_shared_policy(struct shared_policy *info, struct vm_area_struct *vma, struct mempolicy *npol) { diff --git a/mm/shmem.c b/mm/shmem.c index 343b3c0937e56..ce501bce1c2e2 100644 --- a/mm/shmem.c +++ b/mm/shmem.c @@ -1316,7 +1316,8 @@ shmem_get_inode(struct super_block *sb, int mode, dev_t dev) case S_IFREG: inode->i_op = &shmem_inode_operations; inode->i_fop = &shmem_file_operations; - mpol_shared_policy_init(&info->policy); + mpol_shared_policy_init(&info->policy, sbinfo->policy, + &sbinfo->policy_nodes); break; case S_IFDIR: inode->i_nlink++; @@ -1330,7 +1331,8 @@ shmem_get_inode(struct super_block *sb, int mode, dev_t dev) * Must not load anything in the rbtree, * mpol_free_shared_policy will not be called. */ - mpol_shared_policy_init(&info->policy); + mpol_shared_policy_init(&info->policy, MPOL_DEFAULT, + NULL); break; } } else if (sbinfo->max_inodes) { @@ -1843,7 +1845,9 @@ static struct inode_operations shmem_symlink_inode_operations = { .put_link = shmem_put_link, }; -static int shmem_parse_options(char *options, int *mode, uid_t *uid, gid_t *gid, unsigned long *blocks, unsigned long *inodes) +static int shmem_parse_options(char *options, int *mode, uid_t *uid, + gid_t *gid, unsigned long *blocks, unsigned long *inodes, + int *policy, nodemask_t *policy_nodes) { char *this_char, *value, *rest; @@ -1897,6 +1901,19 @@ static int shmem_parse_options(char *options, int *mode, uid_t *uid, gid_t *gid, *gid = simple_strtoul(value,&rest,0); if (*rest) goto bad_val; + } else if (!strcmp(this_char,"mpol")) { + if (!strcmp(value,"default")) + *policy = MPOL_DEFAULT; + else if (!strcmp(value,"preferred")) + *policy = MPOL_PREFERRED; + else if (!strcmp(value,"bind")) + *policy = MPOL_BIND; + else if (!strcmp(value,"interleave")) + *policy = MPOL_INTERLEAVE; + else + goto bad_val; + } else if (!strcmp(this_char,"mpol_nodelist")) { + nodelist_parse(value, *policy_nodes); } else { printk(KERN_ERR "tmpfs: Bad mount option %s\n", this_char); @@ -1917,12 +1934,14 @@ static int shmem_remount_fs(struct super_block *sb, int *flags, char *data) struct shmem_sb_info *sbinfo = SHMEM_SB(sb); unsigned long max_blocks = sbinfo->max_blocks; unsigned long max_inodes = sbinfo->max_inodes; + int policy = sbinfo->policy; + nodemask_t policy_nodes = sbinfo->policy_nodes; unsigned long blocks; unsigned long inodes; int error = -EINVAL; - if (shmem_parse_options(data, NULL, NULL, NULL, - &max_blocks, &max_inodes)) + if (shmem_parse_options(data, NULL, NULL, NULL, &max_blocks, + &max_inodes, &policy, &policy_nodes)) return error; spin_lock(&sbinfo->stat_lock); @@ -1948,6 +1967,8 @@ static int shmem_remount_fs(struct super_block *sb, int *flags, char *data) sbinfo->free_blocks = max_blocks - blocks; sbinfo->max_inodes = max_inodes; sbinfo->free_inodes = max_inodes - inodes; + sbinfo->policy = policy; + sbinfo->policy_nodes = policy_nodes; out: spin_unlock(&sbinfo->stat_lock); return error; @@ -1972,6 +1993,8 @@ static int shmem_fill_super(struct super_block *sb, struct shmem_sb_info *sbinfo; unsigned long blocks = 0; unsigned long inodes = 0; + int policy = MPOL_DEFAULT; + nodemask_t policy_nodes = node_online_map; #ifdef CONFIG_TMPFS /* @@ -1984,8 +2007,8 @@ static int shmem_fill_super(struct super_block *sb, inodes = totalram_pages - totalhigh_pages; if (inodes > blocks) inodes = blocks; - if (shmem_parse_options(data, &mode, &uid, &gid, - &blocks, &inodes)) + if (shmem_parse_options(data, &mode, &uid, &gid, &blocks, + &inodes, &policy, &policy_nodes)) return -EINVAL; } #else @@ -2003,6 +2026,8 @@ static int shmem_fill_super(struct super_block *sb, sbinfo->free_blocks = blocks; sbinfo->max_inodes = inodes; sbinfo->free_inodes = inodes; + sbinfo->policy = policy; + sbinfo->policy_nodes = policy_nodes; sb->s_fs_info = sbinfo; sb->s_maxbytes = SHMEM_MAX_BYTES; -- cgit 1.2.3-korg From a6b25b675db9f9f1af640b928f5476e8454b391c Mon Sep 17 00:00:00 2001 From: Randy Dunlap Date: Sat, 14 Jan 2006 13:21:19 -0800 Subject: [PATCH] nlm kernel-parameters update Add 2 lockd kernel parameters and spell 2 others correctly. Signed-off-by: Randy Dunlap Cc: Neil Brown Cc: Olaf Kirch Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/kernel-parameters.txt | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index fe11fccf7e41b..e88e348886f24 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -712,9 +712,17 @@ running once the system is up. load_ramdisk= [RAM] List of ramdisks to load from floppy See Documentation/ramdisk.txt. - lockd.udpport= [NFS] + lockd.nlm_grace_period=P [NFS] Assign grace period. + Format: + + lockd.nlm_tcpport=N [NFS] Assign TCP port. + Format: - lockd.tcpport= [NFS] + lockd.nlm_timeout=T [NFS] Assign timeout value. + Format: + + lockd.nlm_udpport=M [NFS] Assign UDP port. + Format: logibm.irq= [HW,MOUSE] Logitech Bus Mouse Driver Format: -- cgit 1.2.3-korg From 16ab3adf562fb723d9085c998637f214b10072c5 Mon Sep 17 00:00:00 2001 From: Randy Dunlap Date: Sat, 14 Jan 2006 13:21:20 -0800 Subject: [PATCH] Update kernel-parameters.txt IOSCHED to spell out 'anticipatory' Signed-off-by: Randy Dunlap Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/kernel-parameters.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index e88e348886f24..1cbcf65b764b4 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -471,7 +471,7 @@ running once the system is up. arch/i386/kernel/cpu/cpufreq/elanfreq.c. elevator= [IOSCHED] - Format: {"as" | "cfq" | "deadline" | "noop"} + Format: {"anticipatory" | "cfq" | "deadline" | "noop"} See Documentation/block/as-iosched.txt and Documentation/block/deadline-iosched.txt for details. -- cgit 1.2.3-korg From a9df3d0f312f4b1aefec76ae5ee86cccbf7cd4e0 Mon Sep 17 00:00:00 2001 From: Ingo Molnar Date: Sat, 14 Jan 2006 13:21:33 -0800 Subject: [PATCH] When CONFIG_CC_OPTIMIZE_FOR_SIZE, allow gcc4 to control inlining If optimizing for size (CONFIG_CC_OPTIMIZE_FOR_SIZE), allow gcc4 compilers to decide what to inline and what not - instead of the kernel forcing gcc to inline all the time. This requires several places that require to be inlined to be marked as such, previous patches in this series do that. Signed-off-by: Ingo Molnar Signed-off-by: Arjan van de Ven Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/feature-removal-schedule.txt | 9 +++++++++ include/linux/compiler-gcc4.h | 9 +++++++++ lib/Kconfig.debug | 14 ++++++++++++++ 3 files changed, 32 insertions(+) (limited to 'Documentation') diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 9474501dd6cc4..b4a1ea7626985 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -123,6 +123,15 @@ Who: Christoph Hellwig --------------------------- +What: CONFIG_FORCED_INLINING +When: June 2006 +Why: Config option is there to see if gcc is good enough. (in january + 2006). If it is, the behavior should just be the default. If it's not, + the option should just go away entirely. +Who: Arjan van de Ven + +--------------------------- + What: START_ARRAY ioctl for md When: July 2006 Files: drivers/md/md.c diff --git a/include/linux/compiler-gcc4.h b/include/linux/compiler-gcc4.h index 8249115a1f730..6f5cc6f0e7a66 100644 --- a/include/linux/compiler-gcc4.h +++ b/include/linux/compiler-gcc4.h @@ -3,6 +3,15 @@ /* These definitions are for GCC v4.x. */ #include +#ifdef CONFIG_FORCED_INLINING +# undef inline +# undef __inline__ +# undef __inline +# define inline inline __attribute__((always_inline)) +# define __inline__ __inline__ __attribute__((always_inline)) +# define __inline __inline __attribute__((always_inline)) +#endif + #define __attribute_used__ __attribute__((__used__)) #define __must_check __attribute__((warn_unused_result)) #define __compiler_offsetof(a,b) __builtin_offsetof(a,b) diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index a609235a517f5..a314e663d5177 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -195,6 +195,20 @@ config FRAME_POINTER some architectures or if you use external debuggers. If you don't debug the kernel, you can say N. +config FORCED_INLINING + bool "Force gcc to inline functions marked 'inline'" + depends on DEBUG_KERNEL + default y + help + This option determines if the kernel forces gcc to inline the functions + developers have marked 'inline'. Doing so takes away freedom from gcc to + do what it thinks is best, which is desirable for the gcc 3.x series of + compilers. The gcc 4.x series have a rewritten inlining algorithm and + disabling this option will generate a smaller kernel there. Hopefully + this algorithm is so good that allowing gcc4 to make the decision can + become the default in the future, until then this option is there to + test gcc for this. + config RCU_TORTURE_TEST tristate "torture tests for RCU" depends on DEBUG_KERNEL -- cgit 1.2.3-korg