d/freebsd-dev
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
1d0fce9bfe
freebsd-dev/sys/arm/at91/at91_spi.c

458 lines
12 KiB
C
Raw Normal View History

Import support for the Atmel AT91RM9200 CPU/Microcontroller. This SoC is a ARM920T based CPU with a bunch of built-in peripherals. The inital import supports the SPI bus, the TWI bus (although iicbus integration is not complete), the uarts, the system timer and the onboard ethernet. Support for the Kwikbyte KB9202 (http://www.kwikbyte.com) board is also included, although there's no reason why the 9200 and the 9201 wouldn't also work. Primitive support for running under the skyeye emulator is also provided (although skyeye's support for the AT91RM9200 is a little weak). The code has been structured so that other members of Atmel's arm family can be supported in the future. The AT91SAM9260 is not presently supported due to lack of hardware. The arm7tdmi families are also not supported becasue they lack an MMU. Many thanks to cognet@ for his help and assistance in bringing up this board. He did much of the vm work and wrote parts of the uart and system timer code as well as the bus space implementation. The system boots to single user w/o problem, although the serial console is a little slow and the ethernet driver is still in flux. This work was sponsored by Timing Solutions, Corporation. I am grateful to their support of the FreeBSD project in this manner.
2006-02-04 23:32:13 +00:00
/*-
- Prepend the device description with "AT91" to reflect its nature. [1] - Move DMA tag and map creature to at91_spi_activate() where the other resource allocation also lives. [1] - Flesh out at91_spi_deactivate(). [1] - Work around the "Software Reset must be Written Twice" erratum. - For now, run the bus at the slowest speed possible in order to work around data corruption on transit even seen with 9 MHz on ETHERNUT5 (15 MHz maximum) and AT45DB321D (20 MHz maximum). This also serves as a poor man's work-around for the "NPCSx rises if no data data is to be transmitted" erratum of RM9200. Being able to use the appropriate bus speed would require: 1) Adding a proper work-around for the RM9200 bug consisting of taking the chip select control away from the SPI peripheral and managing it directly as a GPIO line. 2) Taking the maximum frequencies supported by the actual board and the slave devices into account and basing the whole thing on the master clock instead of hardcoding a divisor as previously done. 3) Fixing the above mentioned data corruption. - KASSERT that TX/RX command and data sizes match on transfers. - Introduce a mutex ensuring that only one child device is running a SPI transfer at a time. [1] - Add preliminary, #ifdef'ed out support for setting the chip select. [1] - Use the RX instead of the TX commando size when setting up the RX side of a transfer. - For controllers having SPI_SR_TXEMPTY, i.e. !RM9200, also wait for the completion of the TX part of transfers before stopping the whole thing again. - Use DEVMETHOD_END. [1] - Use NULL instead of 0 for pointers. [1, partially] Additional testing by: Ian Lepore Submitted by: Ian Lepore [1] MFC after: 1 week
2012-06-03 00:54:10 +00:00
* Copyright (c) 2006 M. Warner Losh.
* Copyright (c) 2011-2012 Ian Lepore.
* All rights reserved.
Import support for the Atmel AT91RM9200 CPU/Microcontroller. This SoC is a ARM920T based CPU with a bunch of built-in peripherals. The inital import supports the SPI bus, the TWI bus (although iicbus integration is not complete), the uarts, the system timer and the onboard ethernet. Support for the Kwikbyte KB9202 (http://www.kwikbyte.com) board is also included, although there's no reason why the 9200 and the 9201 wouldn't also work. Primitive support for running under the skyeye emulator is also provided (although skyeye's support for the AT91RM9200 is a little weak). The code has been structured so that other members of Atmel's arm family can be supported in the future. The AT91SAM9260 is not presently supported due to lack of hardware. The arm7tdmi families are also not supported becasue they lack an MMU. Many thanks to cognet@ for his help and assistance in bringing up this board. He did much of the vm work and wrote parts of the uart and system timer code as well as the bus space implementation. The system boots to single user w/o problem, although the serial console is a little slow and the ethernet driver is still in flux. This work was sponsored by Timing Solutions, Corporation. I am grateful to their support of the FreeBSD project in this manner.
2006-02-04 23:32:13 +00:00
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
Tweak the disclaimer section of the license to match COPYRIGHT, for better or worse. Ok'd by folks that have additional copyrights to the files in cases where there's joint authorship.
2008-11-25 00:13:26 +00:00
* THIS SOFTWARE IS PROVIDED BY AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
Import support for the Atmel AT91RM9200 CPU/Microcontroller. This SoC is a ARM920T based CPU with a bunch of built-in peripherals. The inital import supports the SPI bus, the TWI bus (although iicbus integration is not complete), the uarts, the system timer and the onboard ethernet. Support for the Kwikbyte KB9202 (http://www.kwikbyte.com) board is also included, although there's no reason why the 9200 and the 9201 wouldn't also work. Primitive support for running under the skyeye emulator is also provided (although skyeye's support for the AT91RM9200 is a little weak). The code has been structured so that other members of Atmel's arm family can be supported in the future. The AT91SAM9260 is not presently supported due to lack of hardware. The arm7tdmi families are also not supported becasue they lack an MMU. Many thanks to cognet@ for his help and assistance in bringing up this board. He did much of the vm work and wrote parts of the uart and system timer code as well as the bus space implementation. The system boots to single user w/o problem, although the serial console is a little slow and the ethernet driver is still in flux. This work was sponsored by Timing Solutions, Corporation. I am grateful to their support of the FreeBSD project in this manner.
2006-02-04 23:32:13 +00:00
*/
Add FDT attachment.
2014-02-09 21:00:22 +00:00
#include "opt_platform.h"
Import support for the Atmel AT91RM9200 CPU/Microcontroller. This SoC is a ARM920T based CPU with a bunch of built-in peripherals. The inital import supports the SPI bus, the TWI bus (although iicbus integration is not complete), the uarts, the system timer and the onboard ethernet. Support for the Kwikbyte KB9202 (http://www.kwikbyte.com) board is also included, although there's no reason why the 9200 and the 9201 wouldn't also work. Primitive support for running under the skyeye emulator is also provided (although skyeye's support for the AT91RM9200 is a little weak). The code has been structured so that other members of Atmel's arm family can be supported in the future. The AT91SAM9260 is not presently supported due to lack of hardware. The arm7tdmi families are also not supported becasue they lack an MMU. Many thanks to cognet@ for his help and assistance in bringing up this board. He did much of the vm work and wrote parts of the uart and system timer code as well as the bus space implementation. The system boots to single user w/o problem, although the serial console is a little slow and the ethernet driver is still in flux. This work was sponsored by Timing Solutions, Corporation. I am grateful to their support of the FreeBSD project in this manner.
2006-02-04 23:32:13 +00:00
#include <sys/cdefs.h>
__FBSDID("$FreeBSD$");
#include <sys/param.h>
#include <sys/systm.h>
#include <sys/bus.h>
#include <sys/conf.h>
#include <sys/kernel.h>
- Prepend the device description with "AT91" to reflect its nature. [1] - Move DMA tag and map creature to at91_spi_activate() where the other resource allocation also lives. [1] - Flesh out at91_spi_deactivate(). [1] - Work around the "Software Reset must be Written Twice" erratum. - For now, run the bus at the slowest speed possible in order to work around data corruption on transit even seen with 9 MHz on ETHERNUT5 (15 MHz maximum) and AT45DB321D (20 MHz maximum). This also serves as a poor man's work-around for the "NPCSx rises if no data data is to be transmitted" erratum of RM9200. Being able to use the appropriate bus speed would require: 1) Adding a proper work-around for the RM9200 bug consisting of taking the chip select control away from the SPI peripheral and managing it directly as a GPIO line. 2) Taking the maximum frequencies supported by the actual board and the slave devices into account and basing the whole thing on the master clock instead of hardcoding a divisor as previously done. 3) Fixing the above mentioned data corruption. - KASSERT that TX/RX command and data sizes match on transfers. - Introduce a mutex ensuring that only one child device is running a SPI transfer at a time. [1] - Add preliminary, #ifdef'ed out support for setting the chip select. [1] - Use the RX instead of the TX commando size when setting up the RX side of a transfer. - For controllers having SPI_SR_TXEMPTY, i.e. !RM9200, also wait for the completion of the TX part of transfers before stopping the whole thing again. - Use DEVMETHOD_END. [1] - Use NULL instead of 0 for pointers. [1, partially] Additional testing by: Ian Lepore Submitted by: Ian Lepore [1] MFC after: 1 week
2012-06-03 00:54:10 +00:00
#include <sys/lock.h>
Import support for the Atmel AT91RM9200 CPU/Microcontroller. This SoC is a ARM920T based CPU with a bunch of built-in peripherals. The inital import supports the SPI bus, the TWI bus (although iicbus integration is not complete), the uarts, the system timer and the onboard ethernet. Support for the Kwikbyte KB9202 (http://www.kwikbyte.com) board is also included, although there's no reason why the 9200 and the 9201 wouldn't also work. Primitive support for running under the skyeye emulator is also provided (although skyeye's support for the AT91RM9200 is a little weak). The code has been structured so that other members of Atmel's arm family can be supported in the future. The AT91SAM9260 is not presently supported due to lack of hardware. The arm7tdmi families are also not supported becasue they lack an MMU. Many thanks to cognet@ for his help and assistance in bringing up this board. He did much of the vm work and wrote parts of the uart and system timer code as well as the bus space implementation. The system boots to single user w/o problem, although the serial console is a little slow and the ethernet driver is still in flux. This work was sponsored by Timing Solutions, Corporation. I am grateful to their support of the FreeBSD project in this manner.
2006-02-04 23:32:13 +00:00
#include <sys/mbuf.h>
#include <sys/malloc.h>
#include <sys/module.h>
#include <sys/rman.h>
- Prepend the device description with "AT91" to reflect its nature. [1] - Move DMA tag and map creature to at91_spi_activate() where the other resource allocation also lives. [1] - Flesh out at91_spi_deactivate(). [1] - Work around the "Software Reset must be Written Twice" erratum. - For now, run the bus at the slowest speed possible in order to work around data corruption on transit even seen with 9 MHz on ETHERNUT5 (15 MHz maximum) and AT45DB321D (20 MHz maximum). This also serves as a poor man's work-around for the "NPCSx rises if no data data is to be transmitted" erratum of RM9200. Being able to use the appropriate bus speed would require: 1) Adding a proper work-around for the RM9200 bug consisting of taking the chip select control away from the SPI peripheral and managing it directly as a GPIO line. 2) Taking the maximum frequencies supported by the actual board and the slave devices into account and basing the whole thing on the master clock instead of hardcoding a divisor as previously done. 3) Fixing the above mentioned data corruption. - KASSERT that TX/RX command and data sizes match on transfers. - Introduce a mutex ensuring that only one child device is running a SPI transfer at a time. [1] - Add preliminary, #ifdef'ed out support for setting the chip select. [1] - Use the RX instead of the TX commando size when setting up the RX side of a transfer. - For controllers having SPI_SR_TXEMPTY, i.e. !RM9200, also wait for the completion of the TX part of transfers before stopping the whole thing again. - Use DEVMETHOD_END. [1] - Use NULL instead of 0 for pointers. [1, partially] Additional testing by: Ian Lepore Submitted by: Ian Lepore [1] MFC after: 1 week
2012-06-03 00:54:10 +00:00
#include <sys/sx.h>
Import support for the Atmel AT91RM9200 CPU/Microcontroller. This SoC is a ARM920T based CPU with a bunch of built-in peripherals. The inital import supports the SPI bus, the TWI bus (although iicbus integration is not complete), the uarts, the system timer and the onboard ethernet. Support for the Kwikbyte KB9202 (http://www.kwikbyte.com) board is also included, although there's no reason why the 9200 and the 9201 wouldn't also work. Primitive support for running under the skyeye emulator is also provided (although skyeye's support for the AT91RM9200 is a little weak). The code has been structured so that other members of Atmel's arm family can be supported in the future. The AT91SAM9260 is not presently supported due to lack of hardware. The arm7tdmi families are also not supported becasue they lack an MMU. Many thanks to cognet@ for his help and assistance in bringing up this board. He did much of the vm work and wrote parts of the uart and system timer code as well as the bus space implementation. The system boots to single user w/o problem, although the serial console is a little slow and the ethernet driver is still in flux. This work was sponsored by Timing Solutions, Corporation. I am grateful to their support of the FreeBSD project in this manner.
2006-02-04 23:32:13 +00:00
#include <machine/bus.h>
Allow chip selects other than 0. The SAM9260EK board has its dataflash on CS1.
2012-07-31 19:14:22 +00:00
#include <arm/at91/at91var.h>
Import support for the Atmel AT91RM9200 CPU/Microcontroller. This SoC is a ARM920T based CPU with a bunch of built-in peripherals. The inital import supports the SPI bus, the TWI bus (although iicbus integration is not complete), the uarts, the system timer and the onboard ethernet. Support for the Kwikbyte KB9202 (http://www.kwikbyte.com) board is also included, although there's no reason why the 9200 and the 9201 wouldn't also work. Primitive support for running under the skyeye emulator is also provided (although skyeye's support for the AT91RM9200 is a little weak). The code has been structured so that other members of Atmel's arm family can be supported in the future. The AT91SAM9260 is not presently supported due to lack of hardware. The arm7tdmi families are also not supported becasue they lack an MMU. Many thanks to cognet@ for his help and assistance in bringing up this board. He did much of the vm work and wrote parts of the uart and system timer code as well as the bus space implementation. The system boots to single user w/o problem, although the serial console is a little slow and the ethernet driver is still in flux. This work was sponsored by Timing Solutions, Corporation. I am grateful to their support of the FreeBSD project in this manner.
2006-02-04 23:32:13 +00:00
#include <arm/at91/at91_spireg.h>
MF p4: Adapt to forthcoming spi framework. The ioctls for SPI commands and such belong in the higher level driver.
2006-07-14 21:35:59 +00:00
#include <arm/at91/at91_pdcreg.h>
#include <dev/spibus/spi.h>
Fetch the chip select in the bridge driver, like all the other spi bridges do.
2012-08-23 22:38:37 +00:00
#include <dev/spibus/spibusvar.h>
- Prepend the device description with "AT91" to reflect its nature. [1] - Move DMA tag and map creature to at91_spi_activate() where the other resource allocation also lives. [1] - Flesh out at91_spi_deactivate(). [1] - Work around the "Software Reset must be Written Twice" erratum. - For now, run the bus at the slowest speed possible in order to work around data corruption on transit even seen with 9 MHz on ETHERNUT5 (15 MHz maximum) and AT45DB321D (20 MHz maximum). This also serves as a poor man's work-around for the "NPCSx rises if no data data is to be transmitted" erratum of RM9200. Being able to use the appropriate bus speed would require: 1) Adding a proper work-around for the RM9200 bug consisting of taking the chip select control away from the SPI peripheral and managing it directly as a GPIO line. 2) Taking the maximum frequencies supported by the actual board and the slave devices into account and basing the whole thing on the master clock instead of hardcoding a divisor as previously done. 3) Fixing the above mentioned data corruption. - KASSERT that TX/RX command and data sizes match on transfers. - Introduce a mutex ensuring that only one child device is running a SPI transfer at a time. [1] - Add preliminary, #ifdef'ed out support for setting the chip select. [1] - Use the RX instead of the TX commando size when setting up the RX side of a transfer. - For controllers having SPI_SR_TXEMPTY, i.e. !RM9200, also wait for the completion of the TX part of transfers before stopping the whole thing again. - Use DEVMETHOD_END. [1] - Use NULL instead of 0 for pointers. [1, partially] Additional testing by: Ian Lepore Submitted by: Ian Lepore [1] MFC after: 1 week
2012-06-03 00:54:10 +00:00
Add FDT attachment.
2014-02-09 21:00:22 +00:00
#ifdef FDT
#include <dev/fdt/fdt_common.h>
#include <dev/ofw/ofw_bus.h>
#include <dev/ofw/ofw_bus_subr.h>
#endif
MF p4: Adapt to forthcoming spi framework. The ioctls for SPI commands and such belong in the higher level driver.
2006-07-14 21:35:59 +00:00
#include "spibus_if.h"
Import support for the Atmel AT91RM9200 CPU/Microcontroller. This SoC is a ARM920T based CPU with a bunch of built-in peripherals. The inital import supports the SPI bus, the TWI bus (although iicbus integration is not complete), the uarts, the system timer and the onboard ethernet. Support for the Kwikbyte KB9202 (http://www.kwikbyte.com) board is also included, although there's no reason why the 9200 and the 9201 wouldn't also work. Primitive support for running under the skyeye emulator is also provided (although skyeye's support for the AT91RM9200 is a little weak). The code has been structured so that other members of Atmel's arm family can be supported in the future. The AT91SAM9260 is not presently supported due to lack of hardware. The arm7tdmi families are also not supported becasue they lack an MMU. Many thanks to cognet@ for his help and assistance in bringing up this board. He did much of the vm work and wrote parts of the uart and system timer code as well as the bus space implementation. The system boots to single user w/o problem, although the serial console is a little slow and the ethernet driver is still in flux. This work was sponsored by Timing Solutions, Corporation. I am grateful to their support of the FreeBSD project in this manner.
2006-02-04 23:32:13 +00:00
struct at91_spi_softc
{
device_t dev; /* Myself */
void *intrhand; /* Interrupt handle */
struct resource *irq_res; /* IRQ resource */
struct resource *mem_res; /* Memory resource */
- Prepend the device description with "AT91" to reflect its nature. [1] - Move DMA tag and map creature to at91_spi_activate() where the other resource allocation also lives. [1] - Flesh out at91_spi_deactivate(). [1] - Work around the "Software Reset must be Written Twice" erratum. - For now, run the bus at the slowest speed possible in order to work around data corruption on transit even seen with 9 MHz on ETHERNUT5 (15 MHz maximum) and AT45DB321D (20 MHz maximum). This also serves as a poor man's work-around for the "NPCSx rises if no data data is to be transmitted" erratum of RM9200. Being able to use the appropriate bus speed would require: 1) Adding a proper work-around for the RM9200 bug consisting of taking the chip select control away from the SPI peripheral and managing it directly as a GPIO line. 2) Taking the maximum frequencies supported by the actual board and the slave devices into account and basing the whole thing on the master clock instead of hardcoding a divisor as previously done. 3) Fixing the above mentioned data corruption. - KASSERT that TX/RX command and data sizes match on transfers. - Introduce a mutex ensuring that only one child device is running a SPI transfer at a time. [1] - Add preliminary, #ifdef'ed out support for setting the chip select. [1] - Use the RX instead of the TX commando size when setting up the RX side of a transfer. - For controllers having SPI_SR_TXEMPTY, i.e. !RM9200, also wait for the completion of the TX part of transfers before stopping the whole thing again. - Use DEVMETHOD_END. [1] - Use NULL instead of 0 for pointers. [1, partially] Additional testing by: Ian Lepore Submitted by: Ian Lepore [1] MFC after: 1 week
2012-06-03 00:54:10 +00:00
bus_dma_tag_t dmatag; /* bus dma tag for transfers */
MF p4: Adapt to forthcoming spi framework. The ioctls for SPI commands and such belong in the higher level driver.
2006-07-14 21:35:59 +00:00
bus_dmamap_t map[4]; /* Maps for the transaction */
- Prepend the device description with "AT91" to reflect its nature. [1] - Move DMA tag and map creature to at91_spi_activate() where the other resource allocation also lives. [1] - Flesh out at91_spi_deactivate(). [1] - Work around the "Software Reset must be Written Twice" erratum. - For now, run the bus at the slowest speed possible in order to work around data corruption on transit even seen with 9 MHz on ETHERNUT5 (15 MHz maximum) and AT45DB321D (20 MHz maximum). This also serves as a poor man's work-around for the "NPCSx rises if no data data is to be transmitted" erratum of RM9200. Being able to use the appropriate bus speed would require: 1) Adding a proper work-around for the RM9200 bug consisting of taking the chip select control away from the SPI peripheral and managing it directly as a GPIO line. 2) Taking the maximum frequencies supported by the actual board and the slave devices into account and basing the whole thing on the master clock instead of hardcoding a divisor as previously done. 3) Fixing the above mentioned data corruption. - KASSERT that TX/RX command and data sizes match on transfers. - Introduce a mutex ensuring that only one child device is running a SPI transfer at a time. [1] - Add preliminary, #ifdef'ed out support for setting the chip select. [1] - Use the RX instead of the TX commando size when setting up the RX side of a transfer. - For controllers having SPI_SR_TXEMPTY, i.e. !RM9200, also wait for the completion of the TX part of transfers before stopping the whole thing again. - Use DEVMETHOD_END. [1] - Use NULL instead of 0 for pointers. [1, partially] Additional testing by: Ian Lepore Submitted by: Ian Lepore [1] MFC after: 1 week
2012-06-03 00:54:10 +00:00
struct sx xfer_mtx; /* Enforce one transfer at a time */
uint32_t xfer_done; /* interrupt<->mainthread signaling */
Import support for the Atmel AT91RM9200 CPU/Microcontroller. This SoC is a ARM920T based CPU with a bunch of built-in peripherals. The inital import supports the SPI bus, the TWI bus (although iicbus integration is not complete), the uarts, the system timer and the onboard ethernet. Support for the Kwikbyte KB9202 (http://www.kwikbyte.com) board is also included, although there's no reason why the 9200 and the 9201 wouldn't also work. Primitive support for running under the skyeye emulator is also provided (although skyeye's support for the AT91RM9200 is a little weak). The code has been structured so that other members of Atmel's arm family can be supported in the future. The AT91SAM9260 is not presently supported due to lack of hardware. The arm7tdmi families are also not supported becasue they lack an MMU. Many thanks to cognet@ for his help and assistance in bringing up this board. He did much of the vm work and wrote parts of the uart and system timer code as well as the bus space implementation. The system boots to single user w/o problem, although the serial console is a little slow and the ethernet driver is still in flux. This work was sponsored by Timing Solutions, Corporation. I am grateful to their support of the FreeBSD project in this manner.
2006-02-04 23:32:13 +00:00
};
- Prepend the device description with "AT91" to reflect its nature. [1] - Move DMA tag and map creature to at91_spi_activate() where the other resource allocation also lives. [1] - Flesh out at91_spi_deactivate(). [1] - Work around the "Software Reset must be Written Twice" erratum. - For now, run the bus at the slowest speed possible in order to work around data corruption on transit even seen with 9 MHz on ETHERNUT5 (15 MHz maximum) and AT45DB321D (20 MHz maximum). This also serves as a poor man's work-around for the "NPCSx rises if no data data is to be transmitted" erratum of RM9200. Being able to use the appropriate bus speed would require: 1) Adding a proper work-around for the RM9200 bug consisting of taking the chip select control away from the SPI peripheral and managing it directly as a GPIO line. 2) Taking the maximum frequencies supported by the actual board and the slave devices into account and basing the whole thing on the master clock instead of hardcoding a divisor as previously done. 3) Fixing the above mentioned data corruption. - KASSERT that TX/RX command and data sizes match on transfers. - Introduce a mutex ensuring that only one child device is running a SPI transfer at a time. [1] - Add preliminary, #ifdef'ed out support for setting the chip select. [1] - Use the RX instead of the TX commando size when setting up the RX side of a transfer. - For controllers having SPI_SR_TXEMPTY, i.e. !RM9200, also wait for the completion of the TX part of transfers before stopping the whole thing again. - Use DEVMETHOD_END. [1] - Use NULL instead of 0 for pointers. [1, partially] Additional testing by: Ian Lepore Submitted by: Ian Lepore [1] MFC after: 1 week
2012-06-03 00:54:10 +00:00
#define CS_TO_MR(cs) ((~(1 << (cs)) & 0x0f) << 16)
Import support for the Atmel AT91RM9200 CPU/Microcontroller. This SoC is a ARM920T based CPU with a bunch of built-in peripherals. The inital import supports the SPI bus, the TWI bus (although iicbus integration is not complete), the uarts, the system timer and the onboard ethernet. Support for the Kwikbyte KB9202 (http://www.kwikbyte.com) board is also included, although there's no reason why the 9200 and the 9201 wouldn't also work. Primitive support for running under the skyeye emulator is also provided (although skyeye's support for the AT91RM9200 is a little weak). The code has been structured so that other members of Atmel's arm family can be supported in the future. The AT91SAM9260 is not presently supported due to lack of hardware. The arm7tdmi families are also not supported becasue they lack an MMU. Many thanks to cognet@ for his help and assistance in bringing up this board. He did much of the vm work and wrote parts of the uart and system timer code as well as the bus space implementation. The system boots to single user w/o problem, although the serial console is a little slow and the ethernet driver is still in flux. This work was sponsored by Timing Solutions, Corporation. I am grateful to their support of the FreeBSD project in this manner.
2006-02-04 23:32:13 +00:00
static inline uint32_t
RD4(struct at91_spi_softc *sc, bus_size_t off)
{
- Prepend the device description with "AT91" to reflect its nature. [1] - Move DMA tag and map creature to at91_spi_activate() where the other resource allocation also lives. [1] - Flesh out at91_spi_deactivate(). [1] - Work around the "Software Reset must be Written Twice" erratum. - For now, run the bus at the slowest speed possible in order to work around data corruption on transit even seen with 9 MHz on ETHERNUT5 (15 MHz maximum) and AT45DB321D (20 MHz maximum). This also serves as a poor man's work-around for the "NPCSx rises if no data data is to be transmitted" erratum of RM9200. Being able to use the appropriate bus speed would require: 1) Adding a proper work-around for the RM9200 bug consisting of taking the chip select control away from the SPI peripheral and managing it directly as a GPIO line. 2) Taking the maximum frequencies supported by the actual board and the slave devices into account and basing the whole thing on the master clock instead of hardcoding a divisor as previously done. 3) Fixing the above mentioned data corruption. - KASSERT that TX/RX command and data sizes match on transfers. - Introduce a mutex ensuring that only one child device is running a SPI transfer at a time. [1] - Add preliminary, #ifdef'ed out support for setting the chip select. [1] - Use the RX instead of the TX commando size when setting up the RX side of a transfer. - For controllers having SPI_SR_TXEMPTY, i.e. !RM9200, also wait for the completion of the TX part of transfers before stopping the whole thing again. - Use DEVMETHOD_END. [1] - Use NULL instead of 0 for pointers. [1, partially] Additional testing by: Ian Lepore Submitted by: Ian Lepore [1] MFC after: 1 week
2012-06-03 00:54:10 +00:00
return (bus_read_4(sc->mem_res, off));
Import support for the Atmel AT91RM9200 CPU/Microcontroller. This SoC is a ARM920T based CPU with a bunch of built-in peripherals. The inital import supports the SPI bus, the TWI bus (although iicbus integration is not complete), the uarts, the system timer and the onboard ethernet. Support for the Kwikbyte KB9202 (http://www.kwikbyte.com) board is also included, although there's no reason why the 9200 and the 9201 wouldn't also work. Primitive support for running under the skyeye emulator is also provided (although skyeye's support for the AT91RM9200 is a little weak). The code has been structured so that other members of Atmel's arm family can be supported in the future. The AT91SAM9260 is not presently supported due to lack of hardware. The arm7tdmi families are also not supported becasue they lack an MMU. Many thanks to cognet@ for his help and assistance in bringing up this board. He did much of the vm work and wrote parts of the uart and system timer code as well as the bus space implementation. The system boots to single user w/o problem, although the serial console is a little slow and the ethernet driver is still in flux. This work was sponsored by Timing Solutions, Corporation. I am grateful to their support of the FreeBSD project in this manner.
2006-02-04 23:32:13 +00:00
}
static inline void
WR4(struct at91_spi_softc *sc, bus_size_t off, uint32_t val)
{
- Prepend the device description with "AT91" to reflect its nature. [1] - Move DMA tag and map creature to at91_spi_activate() where the other resource allocation also lives. [1] - Flesh out at91_spi_deactivate(). [1] - Work around the "Software Reset must be Written Twice" erratum. - For now, run the bus at the slowest speed possible in order to work around data corruption on transit even seen with 9 MHz on ETHERNUT5 (15 MHz maximum) and AT45DB321D (20 MHz maximum). This also serves as a poor man's work-around for the "NPCSx rises if no data data is to be transmitted" erratum of RM9200. Being able to use the appropriate bus speed would require: 1) Adding a proper work-around for the RM9200 bug consisting of taking the chip select control away from the SPI peripheral and managing it directly as a GPIO line. 2) Taking the maximum frequencies supported by the actual board and the slave devices into account and basing the whole thing on the master clock instead of hardcoding a divisor as previously done. 3) Fixing the above mentioned data corruption. - KASSERT that TX/RX command and data sizes match on transfers. - Introduce a mutex ensuring that only one child device is running a SPI transfer at a time. [1] - Add preliminary, #ifdef'ed out support for setting the chip select. [1] - Use the RX instead of the TX commando size when setting up the RX side of a transfer. - For controllers having SPI_SR_TXEMPTY, i.e. !RM9200, also wait for the completion of the TX part of transfers before stopping the whole thing again. - Use DEVMETHOD_END. [1] - Use NULL instead of 0 for pointers. [1, partially] Additional testing by: Ian Lepore Submitted by: Ian Lepore [1] MFC after: 1 week
2012-06-03 00:54:10 +00:00
Import support for the Atmel AT91RM9200 CPU/Microcontroller. This SoC is a ARM920T based CPU with a bunch of built-in peripherals. The inital import supports the SPI bus, the TWI bus (although iicbus integration is not complete), the uarts, the system timer and the onboard ethernet. Support for the Kwikbyte KB9202 (http://www.kwikbyte.com) board is also included, although there's no reason why the 9200 and the 9201 wouldn't also work. Primitive support for running under the skyeye emulator is also provided (although skyeye's support for the AT91RM9200 is a little weak). The code has been structured so that other members of Atmel's arm family can be supported in the future. The AT91SAM9260 is not presently supported due to lack of hardware. The arm7tdmi families are also not supported becasue they lack an MMU. Many thanks to cognet@ for his help and assistance in bringing up this board. He did much of the vm work and wrote parts of the uart and system timer code as well as the bus space implementation. The system boots to single user w/o problem, although the serial console is a little slow and the ethernet driver is still in flux. This work was sponsored by Timing Solutions, Corporation. I am grateful to their support of the FreeBSD project in this manner.
2006-02-04 23:32:13 +00:00
bus_write_4(sc->mem_res, off, val);
}
/* bus entry points */
static int at91_spi_attach(device_t dev);
static int at91_spi_detach(device_t dev);
- Prepend the device description with "AT91" to reflect its nature. [1] - Move DMA tag and map creature to at91_spi_activate() where the other resource allocation also lives. [1] - Flesh out at91_spi_deactivate(). [1] - Work around the "Software Reset must be Written Twice" erratum. - For now, run the bus at the slowest speed possible in order to work around data corruption on transit even seen with 9 MHz on ETHERNUT5 (15 MHz maximum) and AT45DB321D (20 MHz maximum). This also serves as a poor man's work-around for the "NPCSx rises if no data data is to be transmitted" erratum of RM9200. Being able to use the appropriate bus speed would require: 1) Adding a proper work-around for the RM9200 bug consisting of taking the chip select control away from the SPI peripheral and managing it directly as a GPIO line. 2) Taking the maximum frequencies supported by the actual board and the slave devices into account and basing the whole thing on the master clock instead of hardcoding a divisor as previously done. 3) Fixing the above mentioned data corruption. - KASSERT that TX/RX command and data sizes match on transfers. - Introduce a mutex ensuring that only one child device is running a SPI transfer at a time. [1] - Add preliminary, #ifdef'ed out support for setting the chip select. [1] - Use the RX instead of the TX commando size when setting up the RX side of a transfer. - For controllers having SPI_SR_TXEMPTY, i.e. !RM9200, also wait for the completion of the TX part of transfers before stopping the whole thing again. - Use DEVMETHOD_END. [1] - Use NULL instead of 0 for pointers. [1, partially] Additional testing by: Ian Lepore Submitted by: Ian Lepore [1] MFC after: 1 week
2012-06-03 00:54:10 +00:00
static int at91_spi_probe(device_t dev);
static int at91_spi_transfer(device_t dev, device_t child,
struct spi_command *cmd);
Import support for the Atmel AT91RM9200 CPU/Microcontroller. This SoC is a ARM920T based CPU with a bunch of built-in peripherals. The inital import supports the SPI bus, the TWI bus (although iicbus integration is not complete), the uarts, the system timer and the onboard ethernet. Support for the Kwikbyte KB9202 (http://www.kwikbyte.com) board is also included, although there's no reason why the 9200 and the 9201 wouldn't also work. Primitive support for running under the skyeye emulator is also provided (although skyeye's support for the AT91RM9200 is a little weak). The code has been structured so that other members of Atmel's arm family can be supported in the future. The AT91SAM9260 is not presently supported due to lack of hardware. The arm7tdmi families are also not supported becasue they lack an MMU. Many thanks to cognet@ for his help and assistance in bringing up this board. He did much of the vm work and wrote parts of the uart and system timer code as well as the bus space implementation. The system boots to single user w/o problem, although the serial console is a little slow and the ethernet driver is still in flux. This work was sponsored by Timing Solutions, Corporation. I am grateful to their support of the FreeBSD project in this manner.
2006-02-04 23:32:13 +00:00
/* helper routines */
- Prepend the device description with "AT91" to reflect its nature. [1] - Move DMA tag and map creature to at91_spi_activate() where the other resource allocation also lives. [1] - Flesh out at91_spi_deactivate(). [1] - Work around the "Software Reset must be Written Twice" erratum. - For now, run the bus at the slowest speed possible in order to work around data corruption on transit even seen with 9 MHz on ETHERNUT5 (15 MHz maximum) and AT45DB321D (20 MHz maximum). This also serves as a poor man's work-around for the "NPCSx rises if no data data is to be transmitted" erratum of RM9200. Being able to use the appropriate bus speed would require: 1) Adding a proper work-around for the RM9200 bug consisting of taking the chip select control away from the SPI peripheral and managing it directly as a GPIO line. 2) Taking the maximum frequencies supported by the actual board and the slave devices into account and basing the whole thing on the master clock instead of hardcoding a divisor as previously done. 3) Fixing the above mentioned data corruption. - KASSERT that TX/RX command and data sizes match on transfers. - Introduce a mutex ensuring that only one child device is running a SPI transfer at a time. [1] - Add preliminary, #ifdef'ed out support for setting the chip select. [1] - Use the RX instead of the TX commando size when setting up the RX side of a transfer. - For controllers having SPI_SR_TXEMPTY, i.e. !RM9200, also wait for the completion of the TX part of transfers before stopping the whole thing again. - Use DEVMETHOD_END. [1] - Use NULL instead of 0 for pointers. [1, partially] Additional testing by: Ian Lepore Submitted by: Ian Lepore [1] MFC after: 1 week
2012-06-03 00:54:10 +00:00
static void at91_getaddr(void *arg, bus_dma_segment_t *segs, int nsegs,
int error);
Import support for the Atmel AT91RM9200 CPU/Microcontroller. This SoC is a ARM920T based CPU with a bunch of built-in peripherals. The inital import supports the SPI bus, the TWI bus (although iicbus integration is not complete), the uarts, the system timer and the onboard ethernet. Support for the Kwikbyte KB9202 (http://www.kwikbyte.com) board is also included, although there's no reason why the 9200 and the 9201 wouldn't also work. Primitive support for running under the skyeye emulator is also provided (although skyeye's support for the AT91RM9200 is a little weak). The code has been structured so that other members of Atmel's arm family can be supported in the future. The AT91SAM9260 is not presently supported due to lack of hardware. The arm7tdmi families are also not supported becasue they lack an MMU. Many thanks to cognet@ for his help and assistance in bringing up this board. He did much of the vm work and wrote parts of the uart and system timer code as well as the bus space implementation. The system boots to single user w/o problem, although the serial console is a little slow and the ethernet driver is still in flux. This work was sponsored by Timing Solutions, Corporation. I am grateful to their support of the FreeBSD project in this manner.
2006-02-04 23:32:13 +00:00
static int at91_spi_activate(device_t dev);
static void at91_spi_deactivate(device_t dev);
MFp4: Working SPI driver.
2006-10-20 07:10:13 +00:00
static void at91_spi_intr(void *arg);
Import support for the Atmel AT91RM9200 CPU/Microcontroller. This SoC is a ARM920T based CPU with a bunch of built-in peripherals. The inital import supports the SPI bus, the TWI bus (although iicbus integration is not complete), the uarts, the system timer and the onboard ethernet. Support for the Kwikbyte KB9202 (http://www.kwikbyte.com) board is also included, although there's no reason why the 9200 and the 9201 wouldn't also work. Primitive support for running under the skyeye emulator is also provided (although skyeye's support for the AT91RM9200 is a little weak). The code has been structured so that other members of Atmel's arm family can be supported in the future. The AT91SAM9260 is not presently supported due to lack of hardware. The arm7tdmi families are also not supported becasue they lack an MMU. Many thanks to cognet@ for his help and assistance in bringing up this board. He did much of the vm work and wrote parts of the uart and system timer code as well as the bus space implementation. The system boots to single user w/o problem, although the serial console is a little slow and the ethernet driver is still in flux. This work was sponsored by Timing Solutions, Corporation. I am grateful to their support of the FreeBSD project in this manner.
2006-02-04 23:32:13 +00:00
static int
at91_spi_probe(device_t dev)
{
Add FDT attachment.
2014-02-09 21:00:22 +00:00
#ifdef FDT
if (!ofw_bus_is_compatible(dev, "atmel,at91rm9200-spi"))
return (ENXIO);
#endif
- Prepend the device description with "AT91" to reflect its nature. [1] - Move DMA tag and map creature to at91_spi_activate() where the other resource allocation also lives. [1] - Flesh out at91_spi_deactivate(). [1] - Work around the "Software Reset must be Written Twice" erratum. - For now, run the bus at the slowest speed possible in order to work around data corruption on transit even seen with 9 MHz on ETHERNUT5 (15 MHz maximum) and AT45DB321D (20 MHz maximum). This also serves as a poor man's work-around for the "NPCSx rises if no data data is to be transmitted" erratum of RM9200. Being able to use the appropriate bus speed would require: 1) Adding a proper work-around for the RM9200 bug consisting of taking the chip select control away from the SPI peripheral and managing it directly as a GPIO line. 2) Taking the maximum frequencies supported by the actual board and the slave devices into account and basing the whole thing on the master clock instead of hardcoding a divisor as previously done. 3) Fixing the above mentioned data corruption. - KASSERT that TX/RX command and data sizes match on transfers. - Introduce a mutex ensuring that only one child device is running a SPI transfer at a time. [1] - Add preliminary, #ifdef'ed out support for setting the chip select. [1] - Use the RX instead of the TX commando size when setting up the RX side of a transfer. - For controllers having SPI_SR_TXEMPTY, i.e. !RM9200, also wait for the completion of the TX part of transfers before stopping the whole thing again. - Use DEVMETHOD_END. [1] - Use NULL instead of 0 for pointers. [1, partially] Additional testing by: Ian Lepore Submitted by: Ian Lepore [1] MFC after: 1 week
2012-06-03 00:54:10 +00:00
device_set_desc(dev, "AT91 SPI");
Import support for the Atmel AT91RM9200 CPU/Microcontroller. This SoC is a ARM920T based CPU with a bunch of built-in peripherals. The inital import supports the SPI bus, the TWI bus (although iicbus integration is not complete), the uarts, the system timer and the onboard ethernet. Support for the Kwikbyte KB9202 (http://www.kwikbyte.com) board is also included, although there's no reason why the 9200 and the 9201 wouldn't also work. Primitive support for running under the skyeye emulator is also provided (although skyeye's support for the AT91RM9200 is a little weak). The code has been structured so that other members of Atmel's arm family can be supported in the future. The AT91SAM9260 is not presently supported due to lack of hardware. The arm7tdmi families are also not supported becasue they lack an MMU. Many thanks to cognet@ for his help and assistance in bringing up this board. He did much of the vm work and wrote parts of the uart and system timer code as well as the bus space implementation. The system boots to single user w/o problem, although the serial console is a little slow and the ethernet driver is still in flux. This work was sponsored by Timing Solutions, Corporation. I am grateful to their support of the FreeBSD project in this manner.
2006-02-04 23:32:13 +00:00
return (0);
}
static int
at91_spi_attach(device_t dev)
{
- Prepend the device description with "AT91" to reflect its nature. [1] - Move DMA tag and map creature to at91_spi_activate() where the other resource allocation also lives. [1] - Flesh out at91_spi_deactivate(). [1] - Work around the "Software Reset must be Written Twice" erratum. - For now, run the bus at the slowest speed possible in order to work around data corruption on transit even seen with 9 MHz on ETHERNUT5 (15 MHz maximum) and AT45DB321D (20 MHz maximum). This also serves as a poor man's work-around for the "NPCSx rises if no data data is to be transmitted" erratum of RM9200. Being able to use the appropriate bus speed would require: 1) Adding a proper work-around for the RM9200 bug consisting of taking the chip select control away from the SPI peripheral and managing it directly as a GPIO line. 2) Taking the maximum frequencies supported by the actual board and the slave devices into account and basing the whole thing on the master clock instead of hardcoding a divisor as previously done. 3) Fixing the above mentioned data corruption. - KASSERT that TX/RX command and data sizes match on transfers. - Introduce a mutex ensuring that only one child device is running a SPI transfer at a time. [1] - Add preliminary, #ifdef'ed out support for setting the chip select. [1] - Use the RX instead of the TX commando size when setting up the RX side of a transfer. - For controllers having SPI_SR_TXEMPTY, i.e. !RM9200, also wait for the completion of the TX part of transfers before stopping the whole thing again. - Use DEVMETHOD_END. [1] - Use NULL instead of 0 for pointers. [1, partially] Additional testing by: Ian Lepore Submitted by: Ian Lepore [1] MFC after: 1 week
2012-06-03 00:54:10 +00:00
struct at91_spi_softc *sc;
int err;
uint32_t csr;
sc = device_get_softc(dev);
Import support for the Atmel AT91RM9200 CPU/Microcontroller. This SoC is a ARM920T based CPU with a bunch of built-in peripherals. The inital import supports the SPI bus, the TWI bus (although iicbus integration is not complete), the uarts, the system timer and the onboard ethernet. Support for the Kwikbyte KB9202 (http://www.kwikbyte.com) board is also included, although there's no reason why the 9200 and the 9201 wouldn't also work. Primitive support for running under the skyeye emulator is also provided (although skyeye's support for the AT91RM9200 is a little weak). The code has been structured so that other members of Atmel's arm family can be supported in the future. The AT91SAM9260 is not presently supported due to lack of hardware. The arm7tdmi families are also not supported becasue they lack an MMU. Many thanks to cognet@ for his help and assistance in bringing up this board. He did much of the vm work and wrote parts of the uart and system timer code as well as the bus space implementation. The system boots to single user w/o problem, although the serial console is a little slow and the ethernet driver is still in flux. This work was sponsored by Timing Solutions, Corporation. I am grateful to their support of the FreeBSD project in this manner.
2006-02-04 23:32:13 +00:00
sc->dev = dev;
- Prepend the device description with "AT91" to reflect its nature. [1] - Move DMA tag and map creature to at91_spi_activate() where the other resource allocation also lives. [1] - Flesh out at91_spi_deactivate(). [1] - Work around the "Software Reset must be Written Twice" erratum. - For now, run the bus at the slowest speed possible in order to work around data corruption on transit even seen with 9 MHz on ETHERNUT5 (15 MHz maximum) and AT45DB321D (20 MHz maximum). This also serves as a poor man's work-around for the "NPCSx rises if no data data is to be transmitted" erratum of RM9200. Being able to use the appropriate bus speed would require: 1) Adding a proper work-around for the RM9200 bug consisting of taking the chip select control away from the SPI peripheral and managing it directly as a GPIO line. 2) Taking the maximum frequencies supported by the actual board and the slave devices into account and basing the whole thing on the master clock instead of hardcoding a divisor as previously done. 3) Fixing the above mentioned data corruption. - KASSERT that TX/RX command and data sizes match on transfers. - Introduce a mutex ensuring that only one child device is running a SPI transfer at a time. [1] - Add preliminary, #ifdef'ed out support for setting the chip select. [1] - Use the RX instead of the TX commando size when setting up the RX side of a transfer. - For controllers having SPI_SR_TXEMPTY, i.e. !RM9200, also wait for the completion of the TX part of transfers before stopping the whole thing again. - Use DEVMETHOD_END. [1] - Use NULL instead of 0 for pointers. [1, partially] Additional testing by: Ian Lepore Submitted by: Ian Lepore [1] MFC after: 1 week
2012-06-03 00:54:10 +00:00
sx_init(&sc->xfer_mtx, device_get_nameunit(dev));
/*
* Allocate resources.
*/
Import support for the Atmel AT91RM9200 CPU/Microcontroller. This SoC is a ARM920T based CPU with a bunch of built-in peripherals. The inital import supports the SPI bus, the TWI bus (although iicbus integration is not complete), the uarts, the system timer and the onboard ethernet. Support for the Kwikbyte KB9202 (http://www.kwikbyte.com) board is also included, although there's no reason why the 9200 and the 9201 wouldn't also work. Primitive support for running under the skyeye emulator is also provided (although skyeye's support for the AT91RM9200 is a little weak). The code has been structured so that other members of Atmel's arm family can be supported in the future. The AT91SAM9260 is not presently supported due to lack of hardware. The arm7tdmi families are also not supported becasue they lack an MMU. Many thanks to cognet@ for his help and assistance in bringing up this board. He did much of the vm work and wrote parts of the uart and system timer code as well as the bus space implementation. The system boots to single user w/o problem, although the serial console is a little slow and the ethernet driver is still in flux. This work was sponsored by Timing Solutions, Corporation. I am grateful to their support of the FreeBSD project in this manner.
2006-02-04 23:32:13 +00:00
err = at91_spi_activate(dev);
if (err)
goto out;
Honor the disabled status by only grabbing resources and returning when running under FDT.
2014-02-13 16:50:08 +00:00
#ifdef FDT
/*
* Disable devices need to hold their resources, so return now and not attach
* the spibus, setup interrupt handlers, etc.
*/
if (!ofw_bus_status_okay(dev))
return 0;
#endif
Import support for the Atmel AT91RM9200 CPU/Microcontroller. This SoC is a ARM920T based CPU with a bunch of built-in peripherals. The inital import supports the SPI bus, the TWI bus (although iicbus integration is not complete), the uarts, the system timer and the onboard ethernet. Support for the Kwikbyte KB9202 (http://www.kwikbyte.com) board is also included, although there's no reason why the 9200 and the 9201 wouldn't also work. Primitive support for running under the skyeye emulator is also provided (although skyeye's support for the AT91RM9200 is a little weak). The code has been structured so that other members of Atmel's arm family can be supported in the future. The AT91SAM9260 is not presently supported due to lack of hardware. The arm7tdmi families are also not supported becasue they lack an MMU. Many thanks to cognet@ for his help and assistance in bringing up this board. He did much of the vm work and wrote parts of the uart and system timer code as well as the bus space implementation. The system boots to single user w/o problem, although the serial console is a little slow and the ethernet driver is still in flux. This work was sponsored by Timing Solutions, Corporation. I am grateful to their support of the FreeBSD project in this manner.
2006-02-04 23:32:13 +00:00
/*
- Prepend the device description with "AT91" to reflect its nature. [1] - Move DMA tag and map creature to at91_spi_activate() where the other resource allocation also lives. [1] - Flesh out at91_spi_deactivate(). [1] - Work around the "Software Reset must be Written Twice" erratum. - For now, run the bus at the slowest speed possible in order to work around data corruption on transit even seen with 9 MHz on ETHERNUT5 (15 MHz maximum) and AT45DB321D (20 MHz maximum). This also serves as a poor man's work-around for the "NPCSx rises if no data data is to be transmitted" erratum of RM9200. Being able to use the appropriate bus speed would require: 1) Adding a proper work-around for the RM9200 bug consisting of taking the chip select control away from the SPI peripheral and managing it directly as a GPIO line. 2) Taking the maximum frequencies supported by the actual board and the slave devices into account and basing the whole thing on the master clock instead of hardcoding a divisor as previously done. 3) Fixing the above mentioned data corruption. - KASSERT that TX/RX command and data sizes match on transfers. - Introduce a mutex ensuring that only one child device is running a SPI transfer at a time. [1] - Add preliminary, #ifdef'ed out support for setting the chip select. [1] - Use the RX instead of the TX commando size when setting up the RX side of a transfer. - For controllers having SPI_SR_TXEMPTY, i.e. !RM9200, also wait for the completion of the TX part of transfers before stopping the whole thing again. - Use DEVMETHOD_END. [1] - Use NULL instead of 0 for pointers. [1, partially] Additional testing by: Ian Lepore Submitted by: Ian Lepore [1] MFC after: 1 week
2012-06-03 00:54:10 +00:00
* Set up the hardware.
Import support for the Atmel AT91RM9200 CPU/Microcontroller. This SoC is a ARM920T based CPU with a bunch of built-in peripherals. The inital import supports the SPI bus, the TWI bus (although iicbus integration is not complete), the uarts, the system timer and the onboard ethernet. Support for the Kwikbyte KB9202 (http://www.kwikbyte.com) board is also included, although there's no reason why the 9200 and the 9201 wouldn't also work. Primitive support for running under the skyeye emulator is also provided (although skyeye's support for the AT91RM9200 is a little weak). The code has been structured so that other members of Atmel's arm family can be supported in the future. The AT91SAM9260 is not presently supported due to lack of hardware. The arm7tdmi families are also not supported becasue they lack an MMU. Many thanks to cognet@ for his help and assistance in bringing up this board. He did much of the vm work and wrote parts of the uart and system timer code as well as the bus space implementation. The system boots to single user w/o problem, although the serial console is a little slow and the ethernet driver is still in flux. This work was sponsored by Timing Solutions, Corporation. I am grateful to their support of the FreeBSD project in this manner.
2006-02-04 23:32:13 +00:00
*/
- Prepend the device description with "AT91" to reflect its nature. [1] - Move DMA tag and map creature to at91_spi_activate() where the other resource allocation also lives. [1] - Flesh out at91_spi_deactivate(). [1] - Work around the "Software Reset must be Written Twice" erratum. - For now, run the bus at the slowest speed possible in order to work around data corruption on transit even seen with 9 MHz on ETHERNUT5 (15 MHz maximum) and AT45DB321D (20 MHz maximum). This also serves as a poor man's work-around for the "NPCSx rises if no data data is to be transmitted" erratum of RM9200. Being able to use the appropriate bus speed would require: 1) Adding a proper work-around for the RM9200 bug consisting of taking the chip select control away from the SPI peripheral and managing it directly as a GPIO line. 2) Taking the maximum frequencies supported by the actual board and the slave devices into account and basing the whole thing on the master clock instead of hardcoding a divisor as previously done. 3) Fixing the above mentioned data corruption. - KASSERT that TX/RX command and data sizes match on transfers. - Introduce a mutex ensuring that only one child device is running a SPI transfer at a time. [1] - Add preliminary, #ifdef'ed out support for setting the chip select. [1] - Use the RX instead of the TX commando size when setting up the RX side of a transfer. - For controllers having SPI_SR_TXEMPTY, i.e. !RM9200, also wait for the completion of the TX part of transfers before stopping the whole thing again. - Use DEVMETHOD_END. [1] - Use NULL instead of 0 for pointers. [1, partially] Additional testing by: Ian Lepore Submitted by: Ian Lepore [1] MFC after: 1 week
2012-06-03 00:54:10 +00:00
WR4(sc, SPI_CR, SPI_CR_SWRST);
/* "Software Reset must be Written Twice" erratum */
Import support for the Atmel AT91RM9200 CPU/Microcontroller. This SoC is a ARM920T based CPU with a bunch of built-in peripherals. The inital import supports the SPI bus, the TWI bus (although iicbus integration is not complete), the uarts, the system timer and the onboard ethernet. Support for the Kwikbyte KB9202 (http://www.kwikbyte.com) board is also included, although there's no reason why the 9200 and the 9201 wouldn't also work. Primitive support for running under the skyeye emulator is also provided (although skyeye's support for the AT91RM9200 is a little weak). The code has been structured so that other members of Atmel's arm family can be supported in the future. The AT91SAM9260 is not presently supported due to lack of hardware. The arm7tdmi families are also not supported becasue they lack an MMU. Many thanks to cognet@ for his help and assistance in bringing up this board. He did much of the vm work and wrote parts of the uart and system timer code as well as the bus space implementation. The system boots to single user w/o problem, although the serial console is a little slow and the ethernet driver is still in flux. This work was sponsored by Timing Solutions, Corporation. I am grateful to their support of the FreeBSD project in this manner.
2006-02-04 23:32:13 +00:00
WR4(sc, SPI_CR, SPI_CR_SWRST);
MFp4: Working SPI driver.
2006-10-20 07:10:13 +00:00
WR4(sc, SPI_IDR, 0xffffffff);
MF p4: Adapt to forthcoming spi framework. The ioctls for SPI commands and such belong in the higher level driver.
2006-07-14 21:35:59 +00:00
WR4(sc, SPI_MR, (0xf << 24) | SPI_MR_MSTR | SPI_MR_MODFDIS |
- Prepend the device description with "AT91" to reflect its nature. [1] - Move DMA tag and map creature to at91_spi_activate() where the other resource allocation also lives. [1] - Flesh out at91_spi_deactivate(). [1] - Work around the "Software Reset must be Written Twice" erratum. - For now, run the bus at the slowest speed possible in order to work around data corruption on transit even seen with 9 MHz on ETHERNUT5 (15 MHz maximum) and AT45DB321D (20 MHz maximum). This also serves as a poor man's work-around for the "NPCSx rises if no data data is to be transmitted" erratum of RM9200. Being able to use the appropriate bus speed would require: 1) Adding a proper work-around for the RM9200 bug consisting of taking the chip select control away from the SPI peripheral and managing it directly as a GPIO line. 2) Taking the maximum frequencies supported by the actual board and the slave devices into account and basing the whole thing on the master clock instead of hardcoding a divisor as previously done. 3) Fixing the above mentioned data corruption. - KASSERT that TX/RX command and data sizes match on transfers. - Introduce a mutex ensuring that only one child device is running a SPI transfer at a time. [1] - Add preliminary, #ifdef'ed out support for setting the chip select. [1] - Use the RX instead of the TX commando size when setting up the RX side of a transfer. - For controllers having SPI_SR_TXEMPTY, i.e. !RM9200, also wait for the completion of the TX part of transfers before stopping the whole thing again. - Use DEVMETHOD_END. [1] - Use NULL instead of 0 for pointers. [1, partially] Additional testing by: Ian Lepore Submitted by: Ian Lepore [1] MFC after: 1 week
2012-06-03 00:54:10 +00:00
CS_TO_MR(0));
/*
* For now, run the bus at the slowest speed possible as otherwise we
* may encounter data corruption on transmit as seen with ETHERNUT5
* and AT45DB321D even though both board and slave device can take
* more.
* This also serves as a work-around for the "NPCSx rises if no data
* data is to be transmitted" erratum. The ideal workaround for the
* latter is to take the chip select control away from the peripheral
* and manage it directly as a GPIO line. The easy solution is to
* slow down the bus so dramatically that it just never gets starved
* as may be seen when the OCHI controller is running and consuming
* memory and APB bandwidth.
* Also, currently we lack a way for lettting both the board and the
* slave devices take their maximum supported SPI clocks into account.
Allow chip selects other than 0. The SAM9260EK board has its dataflash on CS1.
2012-07-31 19:14:22 +00:00
* Also, we hard-wire SPI mode to 3.
- Prepend the device description with "AT91" to reflect its nature. [1] - Move DMA tag and map creature to at91_spi_activate() where the other resource allocation also lives. [1] - Flesh out at91_spi_deactivate(). [1] - Work around the "Software Reset must be Written Twice" erratum. - For now, run the bus at the slowest speed possible in order to work around data corruption on transit even seen with 9 MHz on ETHERNUT5 (15 MHz maximum) and AT45DB321D (20 MHz maximum). This also serves as a poor man's work-around for the "NPCSx rises if no data data is to be transmitted" erratum of RM9200. Being able to use the appropriate bus speed would require: 1) Adding a proper work-around for the RM9200 bug consisting of taking the chip select control away from the SPI peripheral and managing it directly as a GPIO line. 2) Taking the maximum frequencies supported by the actual board and the slave devices into account and basing the whole thing on the master clock instead of hardcoding a divisor as previously done. 3) Fixing the above mentioned data corruption. - KASSERT that TX/RX command and data sizes match on transfers. - Introduce a mutex ensuring that only one child device is running a SPI transfer at a time. [1] - Add preliminary, #ifdef'ed out support for setting the chip select. [1] - Use the RX instead of the TX commando size when setting up the RX side of a transfer. - For controllers having SPI_SR_TXEMPTY, i.e. !RM9200, also wait for the completion of the TX part of transfers before stopping the whole thing again. - Use DEVMETHOD_END. [1] - Use NULL instead of 0 for pointers. [1, partially] Additional testing by: Ian Lepore Submitted by: Ian Lepore [1] MFC after: 1 week
2012-06-03 00:54:10 +00:00
*/
csr = SPI_CSR_CPOL | (4 << 16) | (0xff << 8);
WR4(sc, SPI_CSR0, csr);
WR4(sc, SPI_CSR1, csr);
WR4(sc, SPI_CSR2, csr);
WR4(sc, SPI_CSR3, csr);
MF p4: Adapt to forthcoming spi framework. The ioctls for SPI commands and such belong in the higher level driver.
2006-07-14 21:35:59 +00:00
WR4(sc, SPI_CR, SPI_CR_SPIEN);
WR4(sc, PDC_PTCR, PDC_PTCR_TXTDIS);
WR4(sc, PDC_PTCR, PDC_PTCR_RXTDIS);
WR4(sc, PDC_RNPR, 0);
WR4(sc, PDC_RNCR, 0);
WR4(sc, PDC_TNPR, 0);
WR4(sc, PDC_TNCR, 0);
WR4(sc, PDC_RPR, 0);
WR4(sc, PDC_RCR, 0);
WR4(sc, PDC_TPR, 0);
WR4(sc, PDC_TCR, 0);
RD4(sc, SPI_RDR);
RD4(sc, SPI_SR);
device_add_child(dev, "spibus", -1);
bus_generic_attach(dev);
Remove pointless semicolons after label
2011-09-30 04:55:23 +00:00
out:
Import support for the Atmel AT91RM9200 CPU/Microcontroller. This SoC is a ARM920T based CPU with a bunch of built-in peripherals. The inital import supports the SPI bus, the TWI bus (although iicbus integration is not complete), the uarts, the system timer and the onboard ethernet. Support for the Kwikbyte KB9202 (http://www.kwikbyte.com) board is also included, although there's no reason why the 9200 and the 9201 wouldn't also work. Primitive support for running under the skyeye emulator is also provided (although skyeye's support for the AT91RM9200 is a little weak). The code has been structured so that other members of Atmel's arm family can be supported in the future. The AT91SAM9260 is not presently supported due to lack of hardware. The arm7tdmi families are also not supported becasue they lack an MMU. Many thanks to cognet@ for his help and assistance in bringing up this board. He did much of the vm work and wrote parts of the uart and system timer code as well as the bus space implementation. The system boots to single user w/o problem, although the serial console is a little slow and the ethernet driver is still in flux. This work was sponsored by Timing Solutions, Corporation. I am grateful to their support of the FreeBSD project in this manner.
2006-02-04 23:32:13 +00:00
if (err)
at91_spi_deactivate(dev);
return (err);
}
static int
at91_spi_detach(device_t dev)
{
- Prepend the device description with "AT91" to reflect its nature. [1] - Move DMA tag and map creature to at91_spi_activate() where the other resource allocation also lives. [1] - Flesh out at91_spi_deactivate(). [1] - Work around the "Software Reset must be Written Twice" erratum. - For now, run the bus at the slowest speed possible in order to work around data corruption on transit even seen with 9 MHz on ETHERNUT5 (15 MHz maximum) and AT45DB321D (20 MHz maximum). This also serves as a poor man's work-around for the "NPCSx rises if no data data is to be transmitted" erratum of RM9200. Being able to use the appropriate bus speed would require: 1) Adding a proper work-around for the RM9200 bug consisting of taking the chip select control away from the SPI peripheral and managing it directly as a GPIO line. 2) Taking the maximum frequencies supported by the actual board and the slave devices into account and basing the whole thing on the master clock instead of hardcoding a divisor as previously done. 3) Fixing the above mentioned data corruption. - KASSERT that TX/RX command and data sizes match on transfers. - Introduce a mutex ensuring that only one child device is running a SPI transfer at a time. [1] - Add preliminary, #ifdef'ed out support for setting the chip select. [1] - Use the RX instead of the TX commando size when setting up the RX side of a transfer. - For controllers having SPI_SR_TXEMPTY, i.e. !RM9200, also wait for the completion of the TX part of transfers before stopping the whole thing again. - Use DEVMETHOD_END. [1] - Use NULL instead of 0 for pointers. [1, partially] Additional testing by: Ian Lepore Submitted by: Ian Lepore [1] MFC after: 1 week
2012-06-03 00:54:10 +00:00
Import support for the Atmel AT91RM9200 CPU/Microcontroller. This SoC is a ARM920T based CPU with a bunch of built-in peripherals. The inital import supports the SPI bus, the TWI bus (although iicbus integration is not complete), the uarts, the system timer and the onboard ethernet. Support for the Kwikbyte KB9202 (http://www.kwikbyte.com) board is also included, although there's no reason why the 9200 and the 9201 wouldn't also work. Primitive support for running under the skyeye emulator is also provided (although skyeye's support for the AT91RM9200 is a little weak). The code has been structured so that other members of Atmel's arm family can be supported in the future. The AT91SAM9260 is not presently supported due to lack of hardware. The arm7tdmi families are also not supported becasue they lack an MMU. Many thanks to cognet@ for his help and assistance in bringing up this board. He did much of the vm work and wrote parts of the uart and system timer code as well as the bus space implementation. The system boots to single user w/o problem, although the serial console is a little slow and the ethernet driver is still in flux. This work was sponsored by Timing Solutions, Corporation. I am grateful to their support of the FreeBSD project in this manner.
2006-02-04 23:32:13 +00:00
return (EBUSY); /* XXX */
}
static int
at91_spi_activate(device_t dev)
{
struct at91_spi_softc *sc;
- Prepend the device description with "AT91" to reflect its nature. [1] - Move DMA tag and map creature to at91_spi_activate() where the other resource allocation also lives. [1] - Flesh out at91_spi_deactivate(). [1] - Work around the "Software Reset must be Written Twice" erratum. - For now, run the bus at the slowest speed possible in order to work around data corruption on transit even seen with 9 MHz on ETHERNUT5 (15 MHz maximum) and AT45DB321D (20 MHz maximum). This also serves as a poor man's work-around for the "NPCSx rises if no data data is to be transmitted" erratum of RM9200. Being able to use the appropriate bus speed would require: 1) Adding a proper work-around for the RM9200 bug consisting of taking the chip select control away from the SPI peripheral and managing it directly as a GPIO line. 2) Taking the maximum frequencies supported by the actual board and the slave devices into account and basing the whole thing on the master clock instead of hardcoding a divisor as previously done. 3) Fixing the above mentioned data corruption. - KASSERT that TX/RX command and data sizes match on transfers. - Introduce a mutex ensuring that only one child device is running a SPI transfer at a time. [1] - Add preliminary, #ifdef'ed out support for setting the chip select. [1] - Use the RX instead of the TX commando size when setting up the RX side of a transfer. - For controllers having SPI_SR_TXEMPTY, i.e. !RM9200, also wait for the completion of the TX part of transfers before stopping the whole thing again. - Use DEVMETHOD_END. [1] - Use NULL instead of 0 for pointers. [1, partially] Additional testing by: Ian Lepore Submitted by: Ian Lepore [1] MFC after: 1 week
2012-06-03 00:54:10 +00:00
int err, i, rid;
Import support for the Atmel AT91RM9200 CPU/Microcontroller. This SoC is a ARM920T based CPU with a bunch of built-in peripherals. The inital import supports the SPI bus, the TWI bus (although iicbus integration is not complete), the uarts, the system timer and the onboard ethernet. Support for the Kwikbyte KB9202 (http://www.kwikbyte.com) board is also included, although there's no reason why the 9200 and the 9201 wouldn't also work. Primitive support for running under the skyeye emulator is also provided (although skyeye's support for the AT91RM9200 is a little weak). The code has been structured so that other members of Atmel's arm family can be supported in the future. The AT91SAM9260 is not presently supported due to lack of hardware. The arm7tdmi families are also not supported becasue they lack an MMU. Many thanks to cognet@ for his help and assistance in bringing up this board. He did much of the vm work and wrote parts of the uart and system timer code as well as the bus space implementation. The system boots to single user w/o problem, although the serial console is a little slow and the ethernet driver is still in flux. This work was sponsored by Timing Solutions, Corporation. I am grateful to their support of the FreeBSD project in this manner.
2006-02-04 23:32:13 +00:00
sc = device_get_softc(dev);
- Prepend the device description with "AT91" to reflect its nature. [1] - Move DMA tag and map creature to at91_spi_activate() where the other resource allocation also lives. [1] - Flesh out at91_spi_deactivate(). [1] - Work around the "Software Reset must be Written Twice" erratum. - For now, run the bus at the slowest speed possible in order to work around data corruption on transit even seen with 9 MHz on ETHERNUT5 (15 MHz maximum) and AT45DB321D (20 MHz maximum). This also serves as a poor man's work-around for the "NPCSx rises if no data data is to be transmitted" erratum of RM9200. Being able to use the appropriate bus speed would require: 1) Adding a proper work-around for the RM9200 bug consisting of taking the chip select control away from the SPI peripheral and managing it directly as a GPIO line. 2) Taking the maximum frequencies supported by the actual board and the slave devices into account and basing the whole thing on the master clock instead of hardcoding a divisor as previously done. 3) Fixing the above mentioned data corruption. - KASSERT that TX/RX command and data sizes match on transfers. - Introduce a mutex ensuring that only one child device is running a SPI transfer at a time. [1] - Add preliminary, #ifdef'ed out support for setting the chip select. [1] - Use the RX instead of the TX commando size when setting up the RX side of a transfer. - For controllers having SPI_SR_TXEMPTY, i.e. !RM9200, also wait for the completion of the TX part of transfers before stopping the whole thing again. - Use DEVMETHOD_END. [1] - Use NULL instead of 0 for pointers. [1, partially] Additional testing by: Ian Lepore Submitted by: Ian Lepore [1] MFC after: 1 week
2012-06-03 00:54:10 +00:00
err = ENOMEM;
Import support for the Atmel AT91RM9200 CPU/Microcontroller. This SoC is a ARM920T based CPU with a bunch of built-in peripherals. The inital import supports the SPI bus, the TWI bus (although iicbus integration is not complete), the uarts, the system timer and the onboard ethernet. Support for the Kwikbyte KB9202 (http://www.kwikbyte.com) board is also included, although there's no reason why the 9200 and the 9201 wouldn't also work. Primitive support for running under the skyeye emulator is also provided (although skyeye's support for the AT91RM9200 is a little weak). The code has been structured so that other members of Atmel's arm family can be supported in the future. The AT91SAM9260 is not presently supported due to lack of hardware. The arm7tdmi families are also not supported becasue they lack an MMU. Many thanks to cognet@ for his help and assistance in bringing up this board. He did much of the vm work and wrote parts of the uart and system timer code as well as the bus space implementation. The system boots to single user w/o problem, although the serial console is a little slow and the ethernet driver is still in flux. This work was sponsored by Timing Solutions, Corporation. I am grateful to their support of the FreeBSD project in this manner.
2006-02-04 23:32:13 +00:00
rid = 0;
sc->mem_res = bus_alloc_resource_any(dev, SYS_RES_MEMORY, &rid,
RF_ACTIVE);
if (sc->mem_res == NULL)
- Prepend the device description with "AT91" to reflect its nature. [1] - Move DMA tag and map creature to at91_spi_activate() where the other resource allocation also lives. [1] - Flesh out at91_spi_deactivate(). [1] - Work around the "Software Reset must be Written Twice" erratum. - For now, run the bus at the slowest speed possible in order to work around data corruption on transit even seen with 9 MHz on ETHERNUT5 (15 MHz maximum) and AT45DB321D (20 MHz maximum). This also serves as a poor man's work-around for the "NPCSx rises if no data data is to be transmitted" erratum of RM9200. Being able to use the appropriate bus speed would require: 1) Adding a proper work-around for the RM9200 bug consisting of taking the chip select control away from the SPI peripheral and managing it directly as a GPIO line. 2) Taking the maximum frequencies supported by the actual board and the slave devices into account and basing the whole thing on the master clock instead of hardcoding a divisor as previously done. 3) Fixing the above mentioned data corruption. - KASSERT that TX/RX command and data sizes match on transfers. - Introduce a mutex ensuring that only one child device is running a SPI transfer at a time. [1] - Add preliminary, #ifdef'ed out support for setting the chip select. [1] - Use the RX instead of the TX commando size when setting up the RX side of a transfer. - For controllers having SPI_SR_TXEMPTY, i.e. !RM9200, also wait for the completion of the TX part of transfers before stopping the whole thing again. - Use DEVMETHOD_END. [1] - Use NULL instead of 0 for pointers. [1, partially] Additional testing by: Ian Lepore Submitted by: Ian Lepore [1] MFC after: 1 week
2012-06-03 00:54:10 +00:00
goto out;
Import support for the Atmel AT91RM9200 CPU/Microcontroller. This SoC is a ARM920T based CPU with a bunch of built-in peripherals. The inital import supports the SPI bus, the TWI bus (although iicbus integration is not complete), the uarts, the system timer and the onboard ethernet. Support for the Kwikbyte KB9202 (http://www.kwikbyte.com) board is also included, although there's no reason why the 9200 and the 9201 wouldn't also work. Primitive support for running under the skyeye emulator is also provided (although skyeye's support for the AT91RM9200 is a little weak). The code has been structured so that other members of Atmel's arm family can be supported in the future. The AT91SAM9260 is not presently supported due to lack of hardware. The arm7tdmi families are also not supported becasue they lack an MMU. Many thanks to cognet@ for his help and assistance in bringing up this board. He did much of the vm work and wrote parts of the uart and system timer code as well as the bus space implementation. The system boots to single user w/o problem, although the serial console is a little slow and the ethernet driver is still in flux. This work was sponsored by Timing Solutions, Corporation. I am grateful to their support of the FreeBSD project in this manner.
2006-02-04 23:32:13 +00:00
rid = 0;
sc->irq_res = bus_alloc_resource_any(dev, SYS_RES_IRQ, &rid,
RF_ACTIVE);
MFp4: Working SPI driver.
2006-10-20 07:10:13 +00:00
if (sc->irq_res == NULL)
- Prepend the device description with "AT91" to reflect its nature. [1] - Move DMA tag and map creature to at91_spi_activate() where the other resource allocation also lives. [1] - Flesh out at91_spi_deactivate(). [1] - Work around the "Software Reset must be Written Twice" erratum. - For now, run the bus at the slowest speed possible in order to work around data corruption on transit even seen with 9 MHz on ETHERNUT5 (15 MHz maximum) and AT45DB321D (20 MHz maximum). This also serves as a poor man's work-around for the "NPCSx rises if no data data is to be transmitted" erratum of RM9200. Being able to use the appropriate bus speed would require: 1) Adding a proper work-around for the RM9200 bug consisting of taking the chip select control away from the SPI peripheral and managing it directly as a GPIO line. 2) Taking the maximum frequencies supported by the actual board and the slave devices into account and basing the whole thing on the master clock instead of hardcoding a divisor as previously done. 3) Fixing the above mentioned data corruption. - KASSERT that TX/RX command and data sizes match on transfers. - Introduce a mutex ensuring that only one child device is running a SPI transfer at a time. [1] - Add preliminary, #ifdef'ed out support for setting the chip select. [1] - Use the RX instead of the TX commando size when setting up the RX side of a transfer. - For controllers having SPI_SR_TXEMPTY, i.e. !RM9200, also wait for the completion of the TX part of transfers before stopping the whole thing again. - Use DEVMETHOD_END. [1] - Use NULL instead of 0 for pointers. [1, partially] Additional testing by: Ian Lepore Submitted by: Ian Lepore [1] MFC after: 1 week
2012-06-03 00:54:10 +00:00
goto out;
MFp4: Working SPI driver.
2006-10-20 07:10:13 +00:00
err = bus_setup_intr(dev, sc->irq_res, INTR_TYPE_MISC | INTR_MPSAFE,
o break newbus api: add a new argument of type driver_filter_t to bus_setup_intr() o add an int return code to all fast handlers o retire INTR_FAST/IH_FAST For more info: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=465712+0+current/freebsd-current Reviewed by: many Approved by: re@
2007-02-23 12:19:07 +00:00
NULL, at91_spi_intr, sc, &sc->intrhand);
MFp4: Working SPI driver.
2006-10-20 07:10:13 +00:00
if (err != 0)
- Prepend the device description with "AT91" to reflect its nature. [1] - Move DMA tag and map creature to at91_spi_activate() where the other resource allocation also lives. [1] - Flesh out at91_spi_deactivate(). [1] - Work around the "Software Reset must be Written Twice" erratum. - For now, run the bus at the slowest speed possible in order to work around data corruption on transit even seen with 9 MHz on ETHERNUT5 (15 MHz maximum) and AT45DB321D (20 MHz maximum). This also serves as a poor man's work-around for the "NPCSx rises if no data data is to be transmitted" erratum of RM9200. Being able to use the appropriate bus speed would require: 1) Adding a proper work-around for the RM9200 bug consisting of taking the chip select control away from the SPI peripheral and managing it directly as a GPIO line. 2) Taking the maximum frequencies supported by the actual board and the slave devices into account and basing the whole thing on the master clock instead of hardcoding a divisor as previously done. 3) Fixing the above mentioned data corruption. - KASSERT that TX/RX command and data sizes match on transfers. - Introduce a mutex ensuring that only one child device is running a SPI transfer at a time. [1] - Add preliminary, #ifdef'ed out support for setting the chip select. [1] - Use the RX instead of the TX commando size when setting up the RX side of a transfer. - For controllers having SPI_SR_TXEMPTY, i.e. !RM9200, also wait for the completion of the TX part of transfers before stopping the whole thing again. - Use DEVMETHOD_END. [1] - Use NULL instead of 0 for pointers. [1, partially] Additional testing by: Ian Lepore Submitted by: Ian Lepore [1] MFC after: 1 week
2012-06-03 00:54:10 +00:00
goto out;
err = bus_dma_tag_create(bus_get_dma_tag(dev), 1, 0,
BUS_SPACE_MAXADDR_32BIT, BUS_SPACE_MAXADDR, NULL, NULL, 2048, 1,
2048, BUS_DMA_ALLOCNOW, NULL, NULL, &sc->dmatag);
if (err != 0)
goto out;
for (i = 0; i < 4; i++) {
err = bus_dmamap_create(sc->dmatag, 0, &sc->map[i]);
if (err != 0)
goto out;
}
out:
if (err != 0)
at91_spi_deactivate(dev);
MFp4: Working SPI driver.
2006-10-20 07:10:13 +00:00
return (err);
Import support for the Atmel AT91RM9200 CPU/Microcontroller. This SoC is a ARM920T based CPU with a bunch of built-in peripherals. The inital import supports the SPI bus, the TWI bus (although iicbus integration is not complete), the uarts, the system timer and the onboard ethernet. Support for the Kwikbyte KB9202 (http://www.kwikbyte.com) board is also included, although there's no reason why the 9200 and the 9201 wouldn't also work. Primitive support for running under the skyeye emulator is also provided (although skyeye's support for the AT91RM9200 is a little weak). The code has been structured so that other members of Atmel's arm family can be supported in the future. The AT91SAM9260 is not presently supported due to lack of hardware. The arm7tdmi families are also not supported becasue they lack an MMU. Many thanks to cognet@ for his help and assistance in bringing up this board. He did much of the vm work and wrote parts of the uart and system timer code as well as the bus space implementation. The system boots to single user w/o problem, although the serial console is a little slow and the ethernet driver is still in flux. This work was sponsored by Timing Solutions, Corporation. I am grateful to their support of the FreeBSD project in this manner.
2006-02-04 23:32:13 +00:00
}
static void
at91_spi_deactivate(device_t dev)
{
struct at91_spi_softc *sc;
- Prepend the device description with "AT91" to reflect its nature. [1] - Move DMA tag and map creature to at91_spi_activate() where the other resource allocation also lives. [1] - Flesh out at91_spi_deactivate(). [1] - Work around the "Software Reset must be Written Twice" erratum. - For now, run the bus at the slowest speed possible in order to work around data corruption on transit even seen with 9 MHz on ETHERNUT5 (15 MHz maximum) and AT45DB321D (20 MHz maximum). This also serves as a poor man's work-around for the "NPCSx rises if no data data is to be transmitted" erratum of RM9200. Being able to use the appropriate bus speed would require: 1) Adding a proper work-around for the RM9200 bug consisting of taking the chip select control away from the SPI peripheral and managing it directly as a GPIO line. 2) Taking the maximum frequencies supported by the actual board and the slave devices into account and basing the whole thing on the master clock instead of hardcoding a divisor as previously done. 3) Fixing the above mentioned data corruption. - KASSERT that TX/RX command and data sizes match on transfers. - Introduce a mutex ensuring that only one child device is running a SPI transfer at a time. [1] - Add preliminary, #ifdef'ed out support for setting the chip select. [1] - Use the RX instead of the TX commando size when setting up the RX side of a transfer. - For controllers having SPI_SR_TXEMPTY, i.e. !RM9200, also wait for the completion of the TX part of transfers before stopping the whole thing again. - Use DEVMETHOD_END. [1] - Use NULL instead of 0 for pointers. [1, partially] Additional testing by: Ian Lepore Submitted by: Ian Lepore [1] MFC after: 1 week
2012-06-03 00:54:10 +00:00
int i;
Import support for the Atmel AT91RM9200 CPU/Microcontroller. This SoC is a ARM920T based CPU with a bunch of built-in peripherals. The inital import supports the SPI bus, the TWI bus (although iicbus integration is not complete), the uarts, the system timer and the onboard ethernet. Support for the Kwikbyte KB9202 (http://www.kwikbyte.com) board is also included, although there's no reason why the 9200 and the 9201 wouldn't also work. Primitive support for running under the skyeye emulator is also provided (although skyeye's support for the AT91RM9200 is a little weak). The code has been structured so that other members of Atmel's arm family can be supported in the future. The AT91SAM9260 is not presently supported due to lack of hardware. The arm7tdmi families are also not supported becasue they lack an MMU. Many thanks to cognet@ for his help and assistance in bringing up this board. He did much of the vm work and wrote parts of the uart and system timer code as well as the bus space implementation. The system boots to single user w/o problem, although the serial console is a little slow and the ethernet driver is still in flux. This work was sponsored by Timing Solutions, Corporation. I am grateful to their support of the FreeBSD project in this manner.
2006-02-04 23:32:13 +00:00
sc = device_get_softc(dev);
- Prepend the device description with "AT91" to reflect its nature. [1] - Move DMA tag and map creature to at91_spi_activate() where the other resource allocation also lives. [1] - Flesh out at91_spi_deactivate(). [1] - Work around the "Software Reset must be Written Twice" erratum. - For now, run the bus at the slowest speed possible in order to work around data corruption on transit even seen with 9 MHz on ETHERNUT5 (15 MHz maximum) and AT45DB321D (20 MHz maximum). This also serves as a poor man's work-around for the "NPCSx rises if no data data is to be transmitted" erratum of RM9200. Being able to use the appropriate bus speed would require: 1) Adding a proper work-around for the RM9200 bug consisting of taking the chip select control away from the SPI peripheral and managing it directly as a GPIO line. 2) Taking the maximum frequencies supported by the actual board and the slave devices into account and basing the whole thing on the master clock instead of hardcoding a divisor as previously done. 3) Fixing the above mentioned data corruption. - KASSERT that TX/RX command and data sizes match on transfers. - Introduce a mutex ensuring that only one child device is running a SPI transfer at a time. [1] - Add preliminary, #ifdef'ed out support for setting the chip select. [1] - Use the RX instead of the TX commando size when setting up the RX side of a transfer. - For controllers having SPI_SR_TXEMPTY, i.e. !RM9200, also wait for the completion of the TX part of transfers before stopping the whole thing again. - Use DEVMETHOD_END. [1] - Use NULL instead of 0 for pointers. [1, partially] Additional testing by: Ian Lepore Submitted by: Ian Lepore [1] MFC after: 1 week
2012-06-03 00:54:10 +00:00
bus_generic_detach(dev);
for (i = 0; i < 4; i++)
if (sc->map[i])
bus_dmamap_destroy(sc->dmatag, sc->map[i]);
if (sc->dmatag)
bus_dma_tag_destroy(sc->dmatag);
Import support for the Atmel AT91RM9200 CPU/Microcontroller. This SoC is a ARM920T based CPU with a bunch of built-in peripherals. The inital import supports the SPI bus, the TWI bus (although iicbus integration is not complete), the uarts, the system timer and the onboard ethernet. Support for the Kwikbyte KB9202 (http://www.kwikbyte.com) board is also included, although there's no reason why the 9200 and the 9201 wouldn't also work. Primitive support for running under the skyeye emulator is also provided (although skyeye's support for the AT91RM9200 is a little weak). The code has been structured so that other members of Atmel's arm family can be supported in the future. The AT91SAM9260 is not presently supported due to lack of hardware. The arm7tdmi families are also not supported becasue they lack an MMU. Many thanks to cognet@ for his help and assistance in bringing up this board. He did much of the vm work and wrote parts of the uart and system timer code as well as the bus space implementation. The system boots to single user w/o problem, although the serial console is a little slow and the ethernet driver is still in flux. This work was sponsored by Timing Solutions, Corporation. I am grateful to their support of the FreeBSD project in this manner.
2006-02-04 23:32:13 +00:00
if (sc->intrhand)
bus_teardown_intr(dev, sc->irq_res, sc->intrhand);
- Prepend the device description with "AT91" to reflect its nature. [1] - Move DMA tag and map creature to at91_spi_activate() where the other resource allocation also lives. [1] - Flesh out at91_spi_deactivate(). [1] - Work around the "Software Reset must be Written Twice" erratum. - For now, run the bus at the slowest speed possible in order to work around data corruption on transit even seen with 9 MHz on ETHERNUT5 (15 MHz maximum) and AT45DB321D (20 MHz maximum). This also serves as a poor man's work-around for the "NPCSx rises if no data data is to be transmitted" erratum of RM9200. Being able to use the appropriate bus speed would require: 1) Adding a proper work-around for the RM9200 bug consisting of taking the chip select control away from the SPI peripheral and managing it directly as a GPIO line. 2) Taking the maximum frequencies supported by the actual board and the slave devices into account and basing the whole thing on the master clock instead of hardcoding a divisor as previously done. 3) Fixing the above mentioned data corruption. - KASSERT that TX/RX command and data sizes match on transfers. - Introduce a mutex ensuring that only one child device is running a SPI transfer at a time. [1] - Add preliminary, #ifdef'ed out support for setting the chip select. [1] - Use the RX instead of the TX commando size when setting up the RX side of a transfer. - For controllers having SPI_SR_TXEMPTY, i.e. !RM9200, also wait for the completion of the TX part of transfers before stopping the whole thing again. - Use DEVMETHOD_END. [1] - Use NULL instead of 0 for pointers. [1, partially] Additional testing by: Ian Lepore Submitted by: Ian Lepore [1] MFC after: 1 week
2012-06-03 00:54:10 +00:00
sc->intrhand = NULL;
Import support for the Atmel AT91RM9200 CPU/Microcontroller. This SoC is a ARM920T based CPU with a bunch of built-in peripherals. The inital import supports the SPI bus, the TWI bus (although iicbus integration is not complete), the uarts, the system timer and the onboard ethernet. Support for the Kwikbyte KB9202 (http://www.kwikbyte.com) board is also included, although there's no reason why the 9200 and the 9201 wouldn't also work. Primitive support for running under the skyeye emulator is also provided (although skyeye's support for the AT91RM9200 is a little weak). The code has been structured so that other members of Atmel's arm family can be supported in the future. The AT91SAM9260 is not presently supported due to lack of hardware. The arm7tdmi families are also not supported becasue they lack an MMU. Many thanks to cognet@ for his help and assistance in bringing up this board. He did much of the vm work and wrote parts of the uart and system timer code as well as the bus space implementation. The system boots to single user w/o problem, although the serial console is a little slow and the ethernet driver is still in flux. This work was sponsored by Timing Solutions, Corporation. I am grateful to their support of the FreeBSD project in this manner.
2006-02-04 23:32:13 +00:00
if (sc->irq_res)
bus_release_resource(dev, SYS_RES_IRQ,
rman_get_rid(sc->irq_res), sc->irq_res);
- Prepend the device description with "AT91" to reflect its nature. [1] - Move DMA tag and map creature to at91_spi_activate() where the other resource allocation also lives. [1] - Flesh out at91_spi_deactivate(). [1] - Work around the "Software Reset must be Written Twice" erratum. - For now, run the bus at the slowest speed possible in order to work around data corruption on transit even seen with 9 MHz on ETHERNUT5 (15 MHz maximum) and AT45DB321D (20 MHz maximum). This also serves as a poor man's work-around for the "NPCSx rises if no data data is to be transmitted" erratum of RM9200. Being able to use the appropriate bus speed would require: 1) Adding a proper work-around for the RM9200 bug consisting of taking the chip select control away from the SPI peripheral and managing it directly as a GPIO line. 2) Taking the maximum frequencies supported by the actual board and the slave devices into account and basing the whole thing on the master clock instead of hardcoding a divisor as previously done. 3) Fixing the above mentioned data corruption. - KASSERT that TX/RX command and data sizes match on transfers. - Introduce a mutex ensuring that only one child device is running a SPI transfer at a time. [1] - Add preliminary, #ifdef'ed out support for setting the chip select. [1] - Use the RX instead of the TX commando size when setting up the RX side of a transfer. - For controllers having SPI_SR_TXEMPTY, i.e. !RM9200, also wait for the completion of the TX part of transfers before stopping the whole thing again. - Use DEVMETHOD_END. [1] - Use NULL instead of 0 for pointers. [1, partially] Additional testing by: Ian Lepore Submitted by: Ian Lepore [1] MFC after: 1 week
2012-06-03 00:54:10 +00:00
sc->irq_res = NULL;
if (sc->mem_res)
bus_release_resource(dev, SYS_RES_MEMORY,
rman_get_rid(sc->mem_res), sc->mem_res);
sc->mem_res = NULL;
Import support for the Atmel AT91RM9200 CPU/Microcontroller. This SoC is a ARM920T based CPU with a bunch of built-in peripherals. The inital import supports the SPI bus, the TWI bus (although iicbus integration is not complete), the uarts, the system timer and the onboard ethernet. Support for the Kwikbyte KB9202 (http://www.kwikbyte.com) board is also included, although there's no reason why the 9200 and the 9201 wouldn't also work. Primitive support for running under the skyeye emulator is also provided (although skyeye's support for the AT91RM9200 is a little weak). The code has been structured so that other members of Atmel's arm family can be supported in the future. The AT91SAM9260 is not presently supported due to lack of hardware. The arm7tdmi families are also not supported becasue they lack an MMU. Many thanks to cognet@ for his help and assistance in bringing up this board. He did much of the vm work and wrote parts of the uart and system timer code as well as the bus space implementation. The system boots to single user w/o problem, although the serial console is a little slow and the ethernet driver is still in flux. This work was sponsored by Timing Solutions, Corporation. I am grateful to their support of the FreeBSD project in this manner.
2006-02-04 23:32:13 +00:00
}
static void
- Prepend the device description with "AT91" to reflect its nature. [1] - Move DMA tag and map creature to at91_spi_activate() where the other resource allocation also lives. [1] - Flesh out at91_spi_deactivate(). [1] - Work around the "Software Reset must be Written Twice" erratum. - For now, run the bus at the slowest speed possible in order to work around data corruption on transit even seen with 9 MHz on ETHERNUT5 (15 MHz maximum) and AT45DB321D (20 MHz maximum). This also serves as a poor man's work-around for the "NPCSx rises if no data data is to be transmitted" erratum of RM9200. Being able to use the appropriate bus speed would require: 1) Adding a proper work-around for the RM9200 bug consisting of taking the chip select control away from the SPI peripheral and managing it directly as a GPIO line. 2) Taking the maximum frequencies supported by the actual board and the slave devices into account and basing the whole thing on the master clock instead of hardcoding a divisor as previously done. 3) Fixing the above mentioned data corruption. - KASSERT that TX/RX command and data sizes match on transfers. - Introduce a mutex ensuring that only one child device is running a SPI transfer at a time. [1] - Add preliminary, #ifdef'ed out support for setting the chip select. [1] - Use the RX instead of the TX commando size when setting up the RX side of a transfer. - For controllers having SPI_SR_TXEMPTY, i.e. !RM9200, also wait for the completion of the TX part of transfers before stopping the whole thing again. - Use DEVMETHOD_END. [1] - Use NULL instead of 0 for pointers. [1, partially] Additional testing by: Ian Lepore Submitted by: Ian Lepore [1] MFC after: 1 week
2012-06-03 00:54:10 +00:00
at91_getaddr(void *arg, bus_dma_segment_t *segs, int nsegs __unused,
int error)
Import support for the Atmel AT91RM9200 CPU/Microcontroller. This SoC is a ARM920T based CPU with a bunch of built-in peripherals. The inital import supports the SPI bus, the TWI bus (although iicbus integration is not complete), the uarts, the system timer and the onboard ethernet. Support for the Kwikbyte KB9202 (http://www.kwikbyte.com) board is also included, although there's no reason why the 9200 and the 9201 wouldn't also work. Primitive support for running under the skyeye emulator is also provided (although skyeye's support for the AT91RM9200 is a little weak). The code has been structured so that other members of Atmel's arm family can be supported in the future. The AT91SAM9260 is not presently supported due to lack of hardware. The arm7tdmi families are also not supported becasue they lack an MMU. Many thanks to cognet@ for his help and assistance in bringing up this board. He did much of the vm work and wrote parts of the uart and system timer code as well as the bus space implementation. The system boots to single user w/o problem, although the serial console is a little slow and the ethernet driver is still in flux. This work was sponsored by Timing Solutions, Corporation. I am grateful to their support of the FreeBSD project in this manner.
2006-02-04 23:32:13 +00:00
{
- Prepend the device description with "AT91" to reflect its nature. [1] - Move DMA tag and map creature to at91_spi_activate() where the other resource allocation also lives. [1] - Flesh out at91_spi_deactivate(). [1] - Work around the "Software Reset must be Written Twice" erratum. - For now, run the bus at the slowest speed possible in order to work around data corruption on transit even seen with 9 MHz on ETHERNUT5 (15 MHz maximum) and AT45DB321D (20 MHz maximum). This also serves as a poor man's work-around for the "NPCSx rises if no data data is to be transmitted" erratum of RM9200. Being able to use the appropriate bus speed would require: 1) Adding a proper work-around for the RM9200 bug consisting of taking the chip select control away from the SPI peripheral and managing it directly as a GPIO line. 2) Taking the maximum frequencies supported by the actual board and the slave devices into account and basing the whole thing on the master clock instead of hardcoding a divisor as previously done. 3) Fixing the above mentioned data corruption. - KASSERT that TX/RX command and data sizes match on transfers. - Introduce a mutex ensuring that only one child device is running a SPI transfer at a time. [1] - Add preliminary, #ifdef'ed out support for setting the chip select. [1] - Use the RX instead of the TX commando size when setting up the RX side of a transfer. - For controllers having SPI_SR_TXEMPTY, i.e. !RM9200, also wait for the completion of the TX part of transfers before stopping the whole thing again. - Use DEVMETHOD_END. [1] - Use NULL instead of 0 for pointers. [1, partially] Additional testing by: Ian Lepore Submitted by: Ian Lepore [1] MFC after: 1 week
2012-06-03 00:54:10 +00:00
MF p4: Adapt to forthcoming spi framework. The ioctls for SPI commands and such belong in the higher level driver.
2006-07-14 21:35:59 +00:00
if (error != 0)
Import support for the Atmel AT91RM9200 CPU/Microcontroller. This SoC is a ARM920T based CPU with a bunch of built-in peripherals. The inital import supports the SPI bus, the TWI bus (although iicbus integration is not complete), the uarts, the system timer and the onboard ethernet. Support for the Kwikbyte KB9202 (http://www.kwikbyte.com) board is also included, although there's no reason why the 9200 and the 9201 wouldn't also work. Primitive support for running under the skyeye emulator is also provided (although skyeye's support for the AT91RM9200 is a little weak). The code has been structured so that other members of Atmel's arm family can be supported in the future. The AT91SAM9260 is not presently supported due to lack of hardware. The arm7tdmi families are also not supported becasue they lack an MMU. Many thanks to cognet@ for his help and assistance in bringing up this board. He did much of the vm work and wrote parts of the uart and system timer code as well as the bus space implementation. The system boots to single user w/o problem, although the serial console is a little slow and the ethernet driver is still in flux. This work was sponsored by Timing Solutions, Corporation. I am grateful to their support of the FreeBSD project in this manner.
2006-02-04 23:32:13 +00:00
return;
MF p4: Adapt to forthcoming spi framework. The ioctls for SPI commands and such belong in the higher level driver.
2006-07-14 21:35:59 +00:00
*(bus_addr_t *)arg = segs[0].ds_addr;
Import support for the Atmel AT91RM9200 CPU/Microcontroller. This SoC is a ARM920T based CPU with a bunch of built-in peripherals. The inital import supports the SPI bus, the TWI bus (although iicbus integration is not complete), the uarts, the system timer and the onboard ethernet. Support for the Kwikbyte KB9202 (http://www.kwikbyte.com) board is also included, although there's no reason why the 9200 and the 9201 wouldn't also work. Primitive support for running under the skyeye emulator is also provided (although skyeye's support for the AT91RM9200 is a little weak). The code has been structured so that other members of Atmel's arm family can be supported in the future. The AT91SAM9260 is not presently supported due to lack of hardware. The arm7tdmi families are also not supported becasue they lack an MMU. Many thanks to cognet@ for his help and assistance in bringing up this board. He did much of the vm work and wrote parts of the uart and system timer code as well as the bus space implementation. The system boots to single user w/o problem, although the serial console is a little slow and the ethernet driver is still in flux. This work was sponsored by Timing Solutions, Corporation. I am grateful to their support of the FreeBSD project in this manner.
2006-02-04 23:32:13 +00:00
}
static int
MF p4: Adapt to forthcoming spi framework. The ioctls for SPI commands and such belong in the higher level driver.
2006-07-14 21:35:59 +00:00
at91_spi_transfer(device_t dev, device_t child, struct spi_command *cmd)
Import support for the Atmel AT91RM9200 CPU/Microcontroller. This SoC is a ARM920T based CPU with a bunch of built-in peripherals. The inital import supports the SPI bus, the TWI bus (although iicbus integration is not complete), the uarts, the system timer and the onboard ethernet. Support for the Kwikbyte KB9202 (http://www.kwikbyte.com) board is also included, although there's no reason why the 9200 and the 9201 wouldn't also work. Primitive support for running under the skyeye emulator is also provided (although skyeye's support for the AT91RM9200 is a little weak). The code has been structured so that other members of Atmel's arm family can be supported in the future. The AT91SAM9260 is not presently supported due to lack of hardware. The arm7tdmi families are also not supported becasue they lack an MMU. Many thanks to cognet@ for his help and assistance in bringing up this board. He did much of the vm work and wrote parts of the uart and system timer code as well as the bus space implementation. The system boots to single user w/o problem, although the serial console is a little slow and the ethernet driver is still in flux. This work was sponsored by Timing Solutions, Corporation. I am grateful to their support of the FreeBSD project in this manner.
2006-02-04 23:32:13 +00:00
{
struct at91_spi_softc *sc;
MF p4: Adapt to forthcoming spi framework. The ioctls for SPI commands and such belong in the higher level driver.
2006-07-14 21:35:59 +00:00
bus_addr_t addr;
Fetch the chip select in the bridge driver, like all the other spi bridges do.
2012-08-23 22:38:37 +00:00
int err, i, j, mode[4], cs;
- Prepend the device description with "AT91" to reflect its nature. [1] - Move DMA tag and map creature to at91_spi_activate() where the other resource allocation also lives. [1] - Flesh out at91_spi_deactivate(). [1] - Work around the "Software Reset must be Written Twice" erratum. - For now, run the bus at the slowest speed possible in order to work around data corruption on transit even seen with 9 MHz on ETHERNUT5 (15 MHz maximum) and AT45DB321D (20 MHz maximum). This also serves as a poor man's work-around for the "NPCSx rises if no data data is to be transmitted" erratum of RM9200. Being able to use the appropriate bus speed would require: 1) Adding a proper work-around for the RM9200 bug consisting of taking the chip select control away from the SPI peripheral and managing it directly as a GPIO line. 2) Taking the maximum frequencies supported by the actual board and the slave devices into account and basing the whole thing on the master clock instead of hardcoding a divisor as previously done. 3) Fixing the above mentioned data corruption. - KASSERT that TX/RX command and data sizes match on transfers. - Introduce a mutex ensuring that only one child device is running a SPI transfer at a time. [1] - Add preliminary, #ifdef'ed out support for setting the chip select. [1] - Use the RX instead of the TX commando size when setting up the RX side of a transfer. - For controllers having SPI_SR_TXEMPTY, i.e. !RM9200, also wait for the completion of the TX part of transfers before stopping the whole thing again. - Use DEVMETHOD_END. [1] - Use NULL instead of 0 for pointers. [1, partially] Additional testing by: Ian Lepore Submitted by: Ian Lepore [1] MFC after: 1 week
2012-06-03 00:54:10 +00:00
KASSERT(cmd->tx_cmd_sz == cmd->rx_cmd_sz,
("%s: TX/RX command sizes should be equal", __func__));
KASSERT(cmd->tx_data_sz == cmd->rx_data_sz,
("%s: TX/RX data sizes should be equal", __func__));
Import support for the Atmel AT91RM9200 CPU/Microcontroller. This SoC is a ARM920T based CPU with a bunch of built-in peripherals. The inital import supports the SPI bus, the TWI bus (although iicbus integration is not complete), the uarts, the system timer and the onboard ethernet. Support for the Kwikbyte KB9202 (http://www.kwikbyte.com) board is also included, although there's no reason why the 9200 and the 9201 wouldn't also work. Primitive support for running under the skyeye emulator is also provided (although skyeye's support for the AT91RM9200 is a little weak). The code has been structured so that other members of Atmel's arm family can be supported in the future. The AT91SAM9260 is not presently supported due to lack of hardware. The arm7tdmi families are also not supported becasue they lack an MMU. Many thanks to cognet@ for his help and assistance in bringing up this board. He did much of the vm work and wrote parts of the uart and system timer code as well as the bus space implementation. The system boots to single user w/o problem, although the serial console is a little slow and the ethernet driver is still in flux. This work was sponsored by Timing Solutions, Corporation. I am grateful to their support of the FreeBSD project in this manner.
2006-02-04 23:32:13 +00:00
Fetch the chip select in the bridge driver, like all the other spi bridges do.
2012-08-23 22:38:37 +00:00
/* get the proper chip select */
spibus_get_cs(child, &cs);
MF p4: Adapt to forthcoming spi framework. The ioctls for SPI commands and such belong in the higher level driver.
2006-07-14 21:35:59 +00:00
sc = device_get_softc(dev);
i = 0;
- Prepend the device description with "AT91" to reflect its nature. [1] - Move DMA tag and map creature to at91_spi_activate() where the other resource allocation also lives. [1] - Flesh out at91_spi_deactivate(). [1] - Work around the "Software Reset must be Written Twice" erratum. - For now, run the bus at the slowest speed possible in order to work around data corruption on transit even seen with 9 MHz on ETHERNUT5 (15 MHz maximum) and AT45DB321D (20 MHz maximum). This also serves as a poor man's work-around for the "NPCSx rises if no data data is to be transmitted" erratum of RM9200. Being able to use the appropriate bus speed would require: 1) Adding a proper work-around for the RM9200 bug consisting of taking the chip select control away from the SPI peripheral and managing it directly as a GPIO line. 2) Taking the maximum frequencies supported by the actual board and the slave devices into account and basing the whole thing on the master clock instead of hardcoding a divisor as previously done. 3) Fixing the above mentioned data corruption. - KASSERT that TX/RX command and data sizes match on transfers. - Introduce a mutex ensuring that only one child device is running a SPI transfer at a time. [1] - Add preliminary, #ifdef'ed out support for setting the chip select. [1] - Use the RX instead of the TX commando size when setting up the RX side of a transfer. - For controllers having SPI_SR_TXEMPTY, i.e. !RM9200, also wait for the completion of the TX part of transfers before stopping the whole thing again. - Use DEVMETHOD_END. [1] - Use NULL instead of 0 for pointers. [1, partially] Additional testing by: Ian Lepore Submitted by: Ian Lepore [1] MFC after: 1 week
2012-06-03 00:54:10 +00:00
sx_xlock(&sc->xfer_mtx);
/*
* Disable transfers while we set things up.
*/
WR4(sc, PDC_PTCR, PDC_PTCR_TXTDIS | PDC_PTCR_RXTDIS);
Allow chip selects other than 0. The SAM9260EK board has its dataflash on CS1.
2012-07-31 19:14:22 +00:00
/*
* PSCDEC = 0 has a range of 0..3 for chip select. We
* don't support PSCDEC = 1 which has a range of 0..15.
*/
Fetch the chip select in the bridge driver, like all the other spi bridges do.
2012-08-23 22:38:37 +00:00
if (cs < 0 || cs > 3) {
- Prepend the device description with "AT91" to reflect its nature. [1] - Move DMA tag and map creature to at91_spi_activate() where the other resource allocation also lives. [1] - Flesh out at91_spi_deactivate(). [1] - Work around the "Software Reset must be Written Twice" erratum. - For now, run the bus at the slowest speed possible in order to work around data corruption on transit even seen with 9 MHz on ETHERNUT5 (15 MHz maximum) and AT45DB321D (20 MHz maximum). This also serves as a poor man's work-around for the "NPCSx rises if no data data is to be transmitted" erratum of RM9200. Being able to use the appropriate bus speed would require: 1) Adding a proper work-around for the RM9200 bug consisting of taking the chip select control away from the SPI peripheral and managing it directly as a GPIO line. 2) Taking the maximum frequencies supported by the actual board and the slave devices into account and basing the whole thing on the master clock instead of hardcoding a divisor as previously done. 3) Fixing the above mentioned data corruption. - KASSERT that TX/RX command and data sizes match on transfers. - Introduce a mutex ensuring that only one child device is running a SPI transfer at a time. [1] - Add preliminary, #ifdef'ed out support for setting the chip select. [1] - Use the RX instead of the TX commando size when setting up the RX side of a transfer. - For controllers having SPI_SR_TXEMPTY, i.e. !RM9200, also wait for the completion of the TX part of transfers before stopping the whole thing again. - Use DEVMETHOD_END. [1] - Use NULL instead of 0 for pointers. [1, partially] Additional testing by: Ian Lepore Submitted by: Ian Lepore [1] MFC after: 1 week
2012-06-03 00:54:10 +00:00
device_printf(dev,
Fetch the chip select in the bridge driver, like all the other spi bridges do.
2012-08-23 22:38:37 +00:00
"Invalid chip select %d requested by %s\n", cs,
- Prepend the device description with "AT91" to reflect its nature. [1] - Move DMA tag and map creature to at91_spi_activate() where the other resource allocation also lives. [1] - Flesh out at91_spi_deactivate(). [1] - Work around the "Software Reset must be Written Twice" erratum. - For now, run the bus at the slowest speed possible in order to work around data corruption on transit even seen with 9 MHz on ETHERNUT5 (15 MHz maximum) and AT45DB321D (20 MHz maximum). This also serves as a poor man's work-around for the "NPCSx rises if no data data is to be transmitted" erratum of RM9200. Being able to use the appropriate bus speed would require: 1) Adding a proper work-around for the RM9200 bug consisting of taking the chip select control away from the SPI peripheral and managing it directly as a GPIO line. 2) Taking the maximum frequencies supported by the actual board and the slave devices into account and basing the whole thing on the master clock instead of hardcoding a divisor as previously done. 3) Fixing the above mentioned data corruption. - KASSERT that TX/RX command and data sizes match on transfers. - Introduce a mutex ensuring that only one child device is running a SPI transfer at a time. [1] - Add preliminary, #ifdef'ed out support for setting the chip select. [1] - Use the RX instead of the TX commando size when setting up the RX side of a transfer. - For controllers having SPI_SR_TXEMPTY, i.e. !RM9200, also wait for the completion of the TX part of transfers before stopping the whole thing again. - Use DEVMETHOD_END. [1] - Use NULL instead of 0 for pointers. [1, partially] Additional testing by: Ian Lepore Submitted by: Ian Lepore [1] MFC after: 1 week
2012-06-03 00:54:10 +00:00
device_get_nameunit(child));
err = EINVAL;
goto out;
}
Allow chip selects other than 0. The SAM9260EK board has its dataflash on CS1.
2012-07-31 19:14:22 +00:00
- Prepend the device description with "AT91" to reflect its nature. [1] - Move DMA tag and map creature to at91_spi_activate() where the other resource allocation also lives. [1] - Flesh out at91_spi_deactivate(). [1] - Work around the "Software Reset must be Written Twice" erratum. - For now, run the bus at the slowest speed possible in order to work around data corruption on transit even seen with 9 MHz on ETHERNUT5 (15 MHz maximum) and AT45DB321D (20 MHz maximum). This also serves as a poor man's work-around for the "NPCSx rises if no data data is to be transmitted" erratum of RM9200. Being able to use the appropriate bus speed would require: 1) Adding a proper work-around for the RM9200 bug consisting of taking the chip select control away from the SPI peripheral and managing it directly as a GPIO line. 2) Taking the maximum frequencies supported by the actual board and the slave devices into account and basing the whole thing on the master clock instead of hardcoding a divisor as previously done. 3) Fixing the above mentioned data corruption. - KASSERT that TX/RX command and data sizes match on transfers. - Introduce a mutex ensuring that only one child device is running a SPI transfer at a time. [1] - Add preliminary, #ifdef'ed out support for setting the chip select. [1] - Use the RX instead of the TX commando size when setting up the RX side of a transfer. - For controllers having SPI_SR_TXEMPTY, i.e. !RM9200, also wait for the completion of the TX part of transfers before stopping the whole thing again. - Use DEVMETHOD_END. [1] - Use NULL instead of 0 for pointers. [1, partially] Additional testing by: Ian Lepore Submitted by: Ian Lepore [1] MFC after: 1 week
2012-06-03 00:54:10 +00:00
#ifdef SPI_CHIP_SELECT_HIGH_SUPPORT
Allow chip selects other than 0. The SAM9260EK board has its dataflash on CS1.
2012-07-31 19:14:22 +00:00
/*
* The AT91RM9200 couldn't do CS high for CS 0. Other chips can, but we
* don't support that yet, or other spi modes.
*/
Fetch the chip select in the bridge driver, like all the other spi bridges do.
2012-08-23 22:38:37 +00:00
if (at91_is_rm92() && cs == 0 &&
- Prepend the device description with "AT91" to reflect its nature. [1] - Move DMA tag and map creature to at91_spi_activate() where the other resource allocation also lives. [1] - Flesh out at91_spi_deactivate(). [1] - Work around the "Software Reset must be Written Twice" erratum. - For now, run the bus at the slowest speed possible in order to work around data corruption on transit even seen with 9 MHz on ETHERNUT5 (15 MHz maximum) and AT45DB321D (20 MHz maximum). This also serves as a poor man's work-around for the "NPCSx rises if no data data is to be transmitted" erratum of RM9200. Being able to use the appropriate bus speed would require: 1) Adding a proper work-around for the RM9200 bug consisting of taking the chip select control away from the SPI peripheral and managing it directly as a GPIO line. 2) Taking the maximum frequencies supported by the actual board and the slave devices into account and basing the whole thing on the master clock instead of hardcoding a divisor as previously done. 3) Fixing the above mentioned data corruption. - KASSERT that TX/RX command and data sizes match on transfers. - Introduce a mutex ensuring that only one child device is running a SPI transfer at a time. [1] - Add preliminary, #ifdef'ed out support for setting the chip select. [1] - Use the RX instead of the TX commando size when setting up the RX side of a transfer. - For controllers having SPI_SR_TXEMPTY, i.e. !RM9200, also wait for the completion of the TX part of transfers before stopping the whole thing again. - Use DEVMETHOD_END. [1] - Use NULL instead of 0 for pointers. [1, partially] Additional testing by: Ian Lepore Submitted by: Ian Lepore [1] MFC after: 1 week
2012-06-03 00:54:10 +00:00
(cmd->flags & SPI_CHIP_SELECT_HIGH) != 0) {
device_printf(dev,
Allow chip selects other than 0. The SAM9260EK board has its dataflash on CS1.
2012-07-31 19:14:22 +00:00
"Invalid chip select high requested by %s for cs 0.\n",
- Prepend the device description with "AT91" to reflect its nature. [1] - Move DMA tag and map creature to at91_spi_activate() where the other resource allocation also lives. [1] - Flesh out at91_spi_deactivate(). [1] - Work around the "Software Reset must be Written Twice" erratum. - For now, run the bus at the slowest speed possible in order to work around data corruption on transit even seen with 9 MHz on ETHERNUT5 (15 MHz maximum) and AT45DB321D (20 MHz maximum). This also serves as a poor man's work-around for the "NPCSx rises if no data data is to be transmitted" erratum of RM9200. Being able to use the appropriate bus speed would require: 1) Adding a proper work-around for the RM9200 bug consisting of taking the chip select control away from the SPI peripheral and managing it directly as a GPIO line. 2) Taking the maximum frequencies supported by the actual board and the slave devices into account and basing the whole thing on the master clock instead of hardcoding a divisor as previously done. 3) Fixing the above mentioned data corruption. - KASSERT that TX/RX command and data sizes match on transfers. - Introduce a mutex ensuring that only one child device is running a SPI transfer at a time. [1] - Add preliminary, #ifdef'ed out support for setting the chip select. [1] - Use the RX instead of the TX commando size when setting up the RX side of a transfer. - For controllers having SPI_SR_TXEMPTY, i.e. !RM9200, also wait for the completion of the TX part of transfers before stopping the whole thing again. - Use DEVMETHOD_END. [1] - Use NULL instead of 0 for pointers. [1, partially] Additional testing by: Ian Lepore Submitted by: Ian Lepore [1] MFC after: 1 week
2012-06-03 00:54:10 +00:00
device_get_nameunit(child));
err = EINVAL;
goto out;
}
#endif
Fetch the chip select in the bridge driver, like all the other spi bridges do.
2012-08-23 22:38:37 +00:00
err = (RD4(sc, SPI_MR) & ~0x000f0000) | CS_TO_MR(cs);
Allow chip selects other than 0. The SAM9260EK board has its dataflash on CS1.
2012-07-31 19:14:22 +00:00
WR4(sc, SPI_MR, err);
- Prepend the device description with "AT91" to reflect its nature. [1] - Move DMA tag and map creature to at91_spi_activate() where the other resource allocation also lives. [1] - Flesh out at91_spi_deactivate(). [1] - Work around the "Software Reset must be Written Twice" erratum. - For now, run the bus at the slowest speed possible in order to work around data corruption on transit even seen with 9 MHz on ETHERNUT5 (15 MHz maximum) and AT45DB321D (20 MHz maximum). This also serves as a poor man's work-around for the "NPCSx rises if no data data is to be transmitted" erratum of RM9200. Being able to use the appropriate bus speed would require: 1) Adding a proper work-around for the RM9200 bug consisting of taking the chip select control away from the SPI peripheral and managing it directly as a GPIO line. 2) Taking the maximum frequencies supported by the actual board and the slave devices into account and basing the whole thing on the master clock instead of hardcoding a divisor as previously done. 3) Fixing the above mentioned data corruption. - KASSERT that TX/RX command and data sizes match on transfers. - Introduce a mutex ensuring that only one child device is running a SPI transfer at a time. [1] - Add preliminary, #ifdef'ed out support for setting the chip select. [1] - Use the RX instead of the TX commando size when setting up the RX side of a transfer. - For controllers having SPI_SR_TXEMPTY, i.e. !RM9200, also wait for the completion of the TX part of transfers before stopping the whole thing again. - Use DEVMETHOD_END. [1] - Use NULL instead of 0 for pointers. [1, partially] Additional testing by: Ian Lepore Submitted by: Ian Lepore [1] MFC after: 1 week
2012-06-03 00:54:10 +00:00
/*
* Set up the TX side of the transfer.
*/
if ((err = bus_dmamap_load(sc->dmatag, sc->map[i], cmd->tx_cmd,
cmd->tx_cmd_sz, at91_getaddr, &addr, 0)) != 0)
MF p4: Adapt to forthcoming spi framework. The ioctls for SPI commands and such belong in the higher level driver.
2006-07-14 21:35:59 +00:00
goto out;
WR4(sc, PDC_TPR, addr);
WR4(sc, PDC_TCR, cmd->tx_cmd_sz);
bus_dmamap_sync(sc->dmatag, sc->map[i], BUS_DMASYNC_PREWRITE);
MFp4: Working SPI driver.
2006-10-20 07:10:13 +00:00
mode[i++] = BUS_DMASYNC_POSTWRITE;
if (cmd->tx_data_sz > 0) {
- Prepend the device description with "AT91" to reflect its nature. [1] - Move DMA tag and map creature to at91_spi_activate() where the other resource allocation also lives. [1] - Flesh out at91_spi_deactivate(). [1] - Work around the "Software Reset must be Written Twice" erratum. - For now, run the bus at the slowest speed possible in order to work around data corruption on transit even seen with 9 MHz on ETHERNUT5 (15 MHz maximum) and AT45DB321D (20 MHz maximum). This also serves as a poor man's work-around for the "NPCSx rises if no data data is to be transmitted" erratum of RM9200. Being able to use the appropriate bus speed would require: 1) Adding a proper work-around for the RM9200 bug consisting of taking the chip select control away from the SPI peripheral and managing it directly as a GPIO line. 2) Taking the maximum frequencies supported by the actual board and the slave devices into account and basing the whole thing on the master clock instead of hardcoding a divisor as previously done. 3) Fixing the above mentioned data corruption. - KASSERT that TX/RX command and data sizes match on transfers. - Introduce a mutex ensuring that only one child device is running a SPI transfer at a time. [1] - Add preliminary, #ifdef'ed out support for setting the chip select. [1] - Use the RX instead of the TX commando size when setting up the RX side of a transfer. - For controllers having SPI_SR_TXEMPTY, i.e. !RM9200, also wait for the completion of the TX part of transfers before stopping the whole thing again. - Use DEVMETHOD_END. [1] - Use NULL instead of 0 for pointers. [1, partially] Additional testing by: Ian Lepore Submitted by: Ian Lepore [1] MFC after: 1 week
2012-06-03 00:54:10 +00:00
if ((err = bus_dmamap_load(sc->dmatag, sc->map[i],
cmd->tx_data, cmd->tx_data_sz, at91_getaddr, &addr, 0)) !=
0)
MFp4: Working SPI driver.
2006-10-20 07:10:13 +00:00
goto out;
WR4(sc, PDC_TNPR, addr);
MFp4: correct data counts so that we clock enough data for the spi transaction. This allows complete spi transactions to happen.
2006-11-29 07:57:02 +00:00
WR4(sc, PDC_TNCR, cmd->tx_data_sz);
MFp4: Working SPI driver.
2006-10-20 07:10:13 +00:00
bus_dmamap_sync(sc->dmatag, sc->map[i], BUS_DMASYNC_PREWRITE);
mode[i++] = BUS_DMASYNC_POSTWRITE;
}
- Prepend the device description with "AT91" to reflect its nature. [1] - Move DMA tag and map creature to at91_spi_activate() where the other resource allocation also lives. [1] - Flesh out at91_spi_deactivate(). [1] - Work around the "Software Reset must be Written Twice" erratum. - For now, run the bus at the slowest speed possible in order to work around data corruption on transit even seen with 9 MHz on ETHERNUT5 (15 MHz maximum) and AT45DB321D (20 MHz maximum). This also serves as a poor man's work-around for the "NPCSx rises if no data data is to be transmitted" erratum of RM9200. Being able to use the appropriate bus speed would require: 1) Adding a proper work-around for the RM9200 bug consisting of taking the chip select control away from the SPI peripheral and managing it directly as a GPIO line. 2) Taking the maximum frequencies supported by the actual board and the slave devices into account and basing the whole thing on the master clock instead of hardcoding a divisor as previously done. 3) Fixing the above mentioned data corruption. - KASSERT that TX/RX command and data sizes match on transfers. - Introduce a mutex ensuring that only one child device is running a SPI transfer at a time. [1] - Add preliminary, #ifdef'ed out support for setting the chip select. [1] - Use the RX instead of the TX commando size when setting up the RX side of a transfer. - For controllers having SPI_SR_TXEMPTY, i.e. !RM9200, also wait for the completion of the TX part of transfers before stopping the whole thing again. - Use DEVMETHOD_END. [1] - Use NULL instead of 0 for pointers. [1, partially] Additional testing by: Ian Lepore Submitted by: Ian Lepore [1] MFC after: 1 week
2012-06-03 00:54:10 +00:00
/*
* Set up the RX side of the transfer.
*/
if ((err = bus_dmamap_load(sc->dmatag, sc->map[i], cmd->rx_cmd,
cmd->rx_cmd_sz, at91_getaddr, &addr, 0)) != 0)
MF p4: Adapt to forthcoming spi framework. The ioctls for SPI commands and such belong in the higher level driver.
2006-07-14 21:35:59 +00:00
goto out;
WR4(sc, PDC_RPR, addr);
- Prepend the device description with "AT91" to reflect its nature. [1] - Move DMA tag and map creature to at91_spi_activate() where the other resource allocation also lives. [1] - Flesh out at91_spi_deactivate(). [1] - Work around the "Software Reset must be Written Twice" erratum. - For now, run the bus at the slowest speed possible in order to work around data corruption on transit even seen with 9 MHz on ETHERNUT5 (15 MHz maximum) and AT45DB321D (20 MHz maximum). This also serves as a poor man's work-around for the "NPCSx rises if no data data is to be transmitted" erratum of RM9200. Being able to use the appropriate bus speed would require: 1) Adding a proper work-around for the RM9200 bug consisting of taking the chip select control away from the SPI peripheral and managing it directly as a GPIO line. 2) Taking the maximum frequencies supported by the actual board and the slave devices into account and basing the whole thing on the master clock instead of hardcoding a divisor as previously done. 3) Fixing the above mentioned data corruption. - KASSERT that TX/RX command and data sizes match on transfers. - Introduce a mutex ensuring that only one child device is running a SPI transfer at a time. [1] - Add preliminary, #ifdef'ed out support for setting the chip select. [1] - Use the RX instead of the TX commando size when setting up the RX side of a transfer. - For controllers having SPI_SR_TXEMPTY, i.e. !RM9200, also wait for the completion of the TX part of transfers before stopping the whole thing again. - Use DEVMETHOD_END. [1] - Use NULL instead of 0 for pointers. [1, partially] Additional testing by: Ian Lepore Submitted by: Ian Lepore [1] MFC after: 1 week
2012-06-03 00:54:10 +00:00
WR4(sc, PDC_RCR, cmd->rx_cmd_sz);
MF p4: Adapt to forthcoming spi framework. The ioctls for SPI commands and such belong in the higher level driver.
2006-07-14 21:35:59 +00:00
bus_dmamap_sync(sc->dmatag, sc->map[i], BUS_DMASYNC_PREREAD);
MFp4: Working SPI driver.
2006-10-20 07:10:13 +00:00
mode[i++] = BUS_DMASYNC_POSTREAD;
MFp4: correct data counts so that we clock enough data for the spi transaction. This allows complete spi transactions to happen.
2006-11-29 07:57:02 +00:00
if (cmd->rx_data_sz > 0) {
- Prepend the device description with "AT91" to reflect its nature. [1] - Move DMA tag and map creature to at91_spi_activate() where the other resource allocation also lives. [1] - Flesh out at91_spi_deactivate(). [1] - Work around the "Software Reset must be Written Twice" erratum. - For now, run the bus at the slowest speed possible in order to work around data corruption on transit even seen with 9 MHz on ETHERNUT5 (15 MHz maximum) and AT45DB321D (20 MHz maximum). This also serves as a poor man's work-around for the "NPCSx rises if no data data is to be transmitted" erratum of RM9200. Being able to use the appropriate bus speed would require: 1) Adding a proper work-around for the RM9200 bug consisting of taking the chip select control away from the SPI peripheral and managing it directly as a GPIO line. 2) Taking the maximum frequencies supported by the actual board and the slave devices into account and basing the whole thing on the master clock instead of hardcoding a divisor as previously done. 3) Fixing the above mentioned data corruption. - KASSERT that TX/RX command and data sizes match on transfers. - Introduce a mutex ensuring that only one child device is running a SPI transfer at a time. [1] - Add preliminary, #ifdef'ed out support for setting the chip select. [1] - Use the RX instead of the TX commando size when setting up the RX side of a transfer. - For controllers having SPI_SR_TXEMPTY, i.e. !RM9200, also wait for the completion of the TX part of transfers before stopping the whole thing again. - Use DEVMETHOD_END. [1] - Use NULL instead of 0 for pointers. [1, partially] Additional testing by: Ian Lepore Submitted by: Ian Lepore [1] MFC after: 1 week
2012-06-03 00:54:10 +00:00
if ((err = bus_dmamap_load(sc->dmatag, sc->map[i],
cmd->rx_data, cmd->rx_data_sz, at91_getaddr, &addr, 0)) !=
0)
MFp4: Working SPI driver.
2006-10-20 07:10:13 +00:00
goto out;
WR4(sc, PDC_RNPR, addr);
MFp4: correct data counts so that we clock enough data for the spi transaction. This allows complete spi transactions to happen.
2006-11-29 07:57:02 +00:00
WR4(sc, PDC_RNCR, cmd->rx_data_sz);
MFp4: Working SPI driver.
2006-10-20 07:10:13 +00:00
bus_dmamap_sync(sc->dmatag, sc->map[i], BUS_DMASYNC_PREREAD);
mode[i++] = BUS_DMASYNC_POSTREAD;
}
- Prepend the device description with "AT91" to reflect its nature. [1] - Move DMA tag and map creature to at91_spi_activate() where the other resource allocation also lives. [1] - Flesh out at91_spi_deactivate(). [1] - Work around the "Software Reset must be Written Twice" erratum. - For now, run the bus at the slowest speed possible in order to work around data corruption on transit even seen with 9 MHz on ETHERNUT5 (15 MHz maximum) and AT45DB321D (20 MHz maximum). This also serves as a poor man's work-around for the "NPCSx rises if no data data is to be transmitted" erratum of RM9200. Being able to use the appropriate bus speed would require: 1) Adding a proper work-around for the RM9200 bug consisting of taking the chip select control away from the SPI peripheral and managing it directly as a GPIO line. 2) Taking the maximum frequencies supported by the actual board and the slave devices into account and basing the whole thing on the master clock instead of hardcoding a divisor as previously done. 3) Fixing the above mentioned data corruption. - KASSERT that TX/RX command and data sizes match on transfers. - Introduce a mutex ensuring that only one child device is running a SPI transfer at a time. [1] - Add preliminary, #ifdef'ed out support for setting the chip select. [1] - Use the RX instead of the TX commando size when setting up the RX side of a transfer. - For controllers having SPI_SR_TXEMPTY, i.e. !RM9200, also wait for the completion of the TX part of transfers before stopping the whole thing again. - Use DEVMETHOD_END. [1] - Use NULL instead of 0 for pointers. [1, partially] Additional testing by: Ian Lepore Submitted by: Ian Lepore [1] MFC after: 1 week
2012-06-03 00:54:10 +00:00
/*
* Start the transfer, wait for it to complete.
*/
sc->xfer_done = 0;
Revert the part of r236495 that introduced checking of SPI_SR_TXEMPTY for TX transfer completion as for reasons unknown this occasionally causes SPI_SR_RXBUFF and SPI_SR_ENDRX to not rise. In any case, once the RX part of the transfer is done it's obvious that the preceding TX part had finished and checking of SPI_SR_TXEMPTY was introduced to rule out a possible cause for the data corruption mentioned in r236495 but which didn't turn out to be the problem anyway. MFC after: 3 days
2012-06-18 20:14:42 +00:00
WR4(sc, SPI_IER, SPI_SR_RXBUFF);
MF p4: Adapt to forthcoming spi framework. The ioctls for SPI commands and such belong in the higher level driver.
2006-07-14 21:35:59 +00:00
WR4(sc, PDC_PTCR, PDC_PTCR_TXTEN | PDC_PTCR_RXTEN);
- Prepend the device description with "AT91" to reflect its nature. [1] - Move DMA tag and map creature to at91_spi_activate() where the other resource allocation also lives. [1] - Flesh out at91_spi_deactivate(). [1] - Work around the "Software Reset must be Written Twice" erratum. - For now, run the bus at the slowest speed possible in order to work around data corruption on transit even seen with 9 MHz on ETHERNUT5 (15 MHz maximum) and AT45DB321D (20 MHz maximum). This also serves as a poor man's work-around for the "NPCSx rises if no data data is to be transmitted" erratum of RM9200. Being able to use the appropriate bus speed would require: 1) Adding a proper work-around for the RM9200 bug consisting of taking the chip select control away from the SPI peripheral and managing it directly as a GPIO line. 2) Taking the maximum frequencies supported by the actual board and the slave devices into account and basing the whole thing on the master clock instead of hardcoding a divisor as previously done. 3) Fixing the above mentioned data corruption. - KASSERT that TX/RX command and data sizes match on transfers. - Introduce a mutex ensuring that only one child device is running a SPI transfer at a time. [1] - Add preliminary, #ifdef'ed out support for setting the chip select. [1] - Use the RX instead of the TX commando size when setting up the RX side of a transfer. - For controllers having SPI_SR_TXEMPTY, i.e. !RM9200, also wait for the completion of the TX part of transfers before stopping the whole thing again. - Use DEVMETHOD_END. [1] - Use NULL instead of 0 for pointers. [1, partially] Additional testing by: Ian Lepore Submitted by: Ian Lepore [1] MFC after: 1 week
2012-06-03 00:54:10 +00:00
do
err = tsleep(&sc->xfer_done, PCATCH | PZERO, "at91_spi", hz);
Revert the part of r236495 that introduced checking of SPI_SR_TXEMPTY for TX transfer completion as for reasons unknown this occasionally causes SPI_SR_RXBUFF and SPI_SR_ENDRX to not rise. In any case, once the RX part of the transfer is done it's obvious that the preceding TX part had finished and checking of SPI_SR_TXEMPTY was introduced to rule out a possible cause for the data corruption mentioned in r236495 but which didn't turn out to be the problem anyway. MFC after: 3 days
2012-06-18 20:14:42 +00:00
while (sc->xfer_done == 0 && err != EINTR);
MF p4: Adapt to forthcoming spi framework. The ioctls for SPI commands and such belong in the higher level driver.
2006-07-14 21:35:59 +00:00
- Prepend the device description with "AT91" to reflect its nature. [1] - Move DMA tag and map creature to at91_spi_activate() where the other resource allocation also lives. [1] - Flesh out at91_spi_deactivate(). [1] - Work around the "Software Reset must be Written Twice" erratum. - For now, run the bus at the slowest speed possible in order to work around data corruption on transit even seen with 9 MHz on ETHERNUT5 (15 MHz maximum) and AT45DB321D (20 MHz maximum). This also serves as a poor man's work-around for the "NPCSx rises if no data data is to be transmitted" erratum of RM9200. Being able to use the appropriate bus speed would require: 1) Adding a proper work-around for the RM9200 bug consisting of taking the chip select control away from the SPI peripheral and managing it directly as a GPIO line. 2) Taking the maximum frequencies supported by the actual board and the slave devices into account and basing the whole thing on the master clock instead of hardcoding a divisor as previously done. 3) Fixing the above mentioned data corruption. - KASSERT that TX/RX command and data sizes match on transfers. - Introduce a mutex ensuring that only one child device is running a SPI transfer at a time. [1] - Add preliminary, #ifdef'ed out support for setting the chip select. [1] - Use the RX instead of the TX commando size when setting up the RX side of a transfer. - For controllers having SPI_SR_TXEMPTY, i.e. !RM9200, also wait for the completion of the TX part of transfers before stopping the whole thing again. - Use DEVMETHOD_END. [1] - Use NULL instead of 0 for pointers. [1, partially] Additional testing by: Ian Lepore Submitted by: Ian Lepore [1] MFC after: 1 week
2012-06-03 00:54:10 +00:00
/*
* Stop the transfer and clean things up.
*/
MFp4: Working SPI driver.
2006-10-20 07:10:13 +00:00
WR4(sc, PDC_PTCR, PDC_PTCR_TXTDIS | PDC_PTCR_RXTDIS);
- Prepend the device description with "AT91" to reflect its nature. [1] - Move DMA tag and map creature to at91_spi_activate() where the other resource allocation also lives. [1] - Flesh out at91_spi_deactivate(). [1] - Work around the "Software Reset must be Written Twice" erratum. - For now, run the bus at the slowest speed possible in order to work around data corruption on transit even seen with 9 MHz on ETHERNUT5 (15 MHz maximum) and AT45DB321D (20 MHz maximum). This also serves as a poor man's work-around for the "NPCSx rises if no data data is to be transmitted" erratum of RM9200. Being able to use the appropriate bus speed would require: 1) Adding a proper work-around for the RM9200 bug consisting of taking the chip select control away from the SPI peripheral and managing it directly as a GPIO line. 2) Taking the maximum frequencies supported by the actual board and the slave devices into account and basing the whole thing on the master clock instead of hardcoding a divisor as previously done. 3) Fixing the above mentioned data corruption. - KASSERT that TX/RX command and data sizes match on transfers. - Introduce a mutex ensuring that only one child device is running a SPI transfer at a time. [1] - Add preliminary, #ifdef'ed out support for setting the chip select. [1] - Use the RX instead of the TX commando size when setting up the RX side of a transfer. - For controllers having SPI_SR_TXEMPTY, i.e. !RM9200, also wait for the completion of the TX part of transfers before stopping the whole thing again. - Use DEVMETHOD_END. [1] - Use NULL instead of 0 for pointers. [1, partially] Additional testing by: Ian Lepore Submitted by: Ian Lepore [1] MFC after: 1 week
2012-06-03 00:54:10 +00:00
if (err == 0)
for (j = 0; j < i; j++)
MFp4: Working SPI driver.
2006-10-20 07:10:13 +00:00
bus_dmamap_sync(sc->dmatag, sc->map[j], mode[j]);
Remove pointless semicolons after label
2011-09-30 04:55:23 +00:00
out:
MFp4: Working SPI driver.
2006-10-20 07:10:13 +00:00
for (j = 0; j < i; j++)
bus_dmamap_unload(sc->dmatag, sc->map[j]);
- Prepend the device description with "AT91" to reflect its nature. [1] - Move DMA tag and map creature to at91_spi_activate() where the other resource allocation also lives. [1] - Flesh out at91_spi_deactivate(). [1] - Work around the "Software Reset must be Written Twice" erratum. - For now, run the bus at the slowest speed possible in order to work around data corruption on transit even seen with 9 MHz on ETHERNUT5 (15 MHz maximum) and AT45DB321D (20 MHz maximum). This also serves as a poor man's work-around for the "NPCSx rises if no data data is to be transmitted" erratum of RM9200. Being able to use the appropriate bus speed would require: 1) Adding a proper work-around for the RM9200 bug consisting of taking the chip select control away from the SPI peripheral and managing it directly as a GPIO line. 2) Taking the maximum frequencies supported by the actual board and the slave devices into account and basing the whole thing on the master clock instead of hardcoding a divisor as previously done. 3) Fixing the above mentioned data corruption. - KASSERT that TX/RX command and data sizes match on transfers. - Introduce a mutex ensuring that only one child device is running a SPI transfer at a time. [1] - Add preliminary, #ifdef'ed out support for setting the chip select. [1] - Use the RX instead of the TX commando size when setting up the RX side of a transfer. - For controllers having SPI_SR_TXEMPTY, i.e. !RM9200, also wait for the completion of the TX part of transfers before stopping the whole thing again. - Use DEVMETHOD_END. [1] - Use NULL instead of 0 for pointers. [1, partially] Additional testing by: Ian Lepore Submitted by: Ian Lepore [1] MFC after: 1 week
2012-06-03 00:54:10 +00:00
sx_xunlock(&sc->xfer_mtx);
return (err);
Import support for the Atmel AT91RM9200 CPU/Microcontroller. This SoC is a ARM920T based CPU with a bunch of built-in peripherals. The inital import supports the SPI bus, the TWI bus (although iicbus integration is not complete), the uarts, the system timer and the onboard ethernet. Support for the Kwikbyte KB9202 (http://www.kwikbyte.com) board is also included, although there's no reason why the 9200 and the 9201 wouldn't also work. Primitive support for running under the skyeye emulator is also provided (although skyeye's support for the AT91RM9200 is a little weak). The code has been structured so that other members of Atmel's arm family can be supported in the future. The AT91SAM9260 is not presently supported due to lack of hardware. The arm7tdmi families are also not supported becasue they lack an MMU. Many thanks to cognet@ for his help and assistance in bringing up this board. He did much of the vm work and wrote parts of the uart and system timer code as well as the bus space implementation. The system boots to single user w/o problem, although the serial console is a little slow and the ethernet driver is still in flux. This work was sponsored by Timing Solutions, Corporation. I am grateful to their support of the FreeBSD project in this manner.
2006-02-04 23:32:13 +00:00
}
MFp4: Working SPI driver.
2006-10-20 07:10:13 +00:00
static void
at91_spi_intr(void *arg)
{
- Prepend the device description with "AT91" to reflect its nature. [1] - Move DMA tag and map creature to at91_spi_activate() where the other resource allocation also lives. [1] - Flesh out at91_spi_deactivate(). [1] - Work around the "Software Reset must be Written Twice" erratum. - For now, run the bus at the slowest speed possible in order to work around data corruption on transit even seen with 9 MHz on ETHERNUT5 (15 MHz maximum) and AT45DB321D (20 MHz maximum). This also serves as a poor man's work-around for the "NPCSx rises if no data data is to be transmitted" erratum of RM9200. Being able to use the appropriate bus speed would require: 1) Adding a proper work-around for the RM9200 bug consisting of taking the chip select control away from the SPI peripheral and managing it directly as a GPIO line. 2) Taking the maximum frequencies supported by the actual board and the slave devices into account and basing the whole thing on the master clock instead of hardcoding a divisor as previously done. 3) Fixing the above mentioned data corruption. - KASSERT that TX/RX command and data sizes match on transfers. - Introduce a mutex ensuring that only one child device is running a SPI transfer at a time. [1] - Add preliminary, #ifdef'ed out support for setting the chip select. [1] - Use the RX instead of the TX commando size when setting up the RX side of a transfer. - For controllers having SPI_SR_TXEMPTY, i.e. !RM9200, also wait for the completion of the TX part of transfers before stopping the whole thing again. - Use DEVMETHOD_END. [1] - Use NULL instead of 0 for pointers. [1, partially] Additional testing by: Ian Lepore Submitted by: Ian Lepore [1] MFC after: 1 week
2012-06-03 00:54:10 +00:00
struct at91_spi_softc *sc;
Revert the part of r236495 that introduced checking of SPI_SR_TXEMPTY for TX transfer completion as for reasons unknown this occasionally causes SPI_SR_RXBUFF and SPI_SR_ENDRX to not rise. In any case, once the RX part of the transfer is done it's obvious that the preceding TX part had finished and checking of SPI_SR_TXEMPTY was introduced to rule out a possible cause for the data corruption mentioned in r236495 but which didn't turn out to be the problem anyway. MFC after: 3 days
2012-06-18 20:14:42 +00:00
uint32_t sr;
MFp4: Working SPI driver.
2006-10-20 07:10:13 +00:00
- Prepend the device description with "AT91" to reflect its nature. [1] - Move DMA tag and map creature to at91_spi_activate() where the other resource allocation also lives. [1] - Flesh out at91_spi_deactivate(). [1] - Work around the "Software Reset must be Written Twice" erratum. - For now, run the bus at the slowest speed possible in order to work around data corruption on transit even seen with 9 MHz on ETHERNUT5 (15 MHz maximum) and AT45DB321D (20 MHz maximum). This also serves as a poor man's work-around for the "NPCSx rises if no data data is to be transmitted" erratum of RM9200. Being able to use the appropriate bus speed would require: 1) Adding a proper work-around for the RM9200 bug consisting of taking the chip select control away from the SPI peripheral and managing it directly as a GPIO line. 2) Taking the maximum frequencies supported by the actual board and the slave devices into account and basing the whole thing on the master clock instead of hardcoding a divisor as previously done. 3) Fixing the above mentioned data corruption. - KASSERT that TX/RX command and data sizes match on transfers. - Introduce a mutex ensuring that only one child device is running a SPI transfer at a time. [1] - Add preliminary, #ifdef'ed out support for setting the chip select. [1] - Use the RX instead of the TX commando size when setting up the RX side of a transfer. - For controllers having SPI_SR_TXEMPTY, i.e. !RM9200, also wait for the completion of the TX part of transfers before stopping the whole thing again. - Use DEVMETHOD_END. [1] - Use NULL instead of 0 for pointers. [1, partially] Additional testing by: Ian Lepore Submitted by: Ian Lepore [1] MFC after: 1 week
2012-06-03 00:54:10 +00:00
sc = (struct at91_spi_softc*)arg;
MFp4: Working SPI driver.
2006-10-20 07:10:13 +00:00
sr = RD4(sc, SPI_SR) & RD4(sc, SPI_IMR);
Revert the part of r236495 that introduced checking of SPI_SR_TXEMPTY for TX transfer completion as for reasons unknown this occasionally causes SPI_SR_RXBUFF and SPI_SR_ENDRX to not rise. In any case, once the RX part of the transfer is done it's obvious that the preceding TX part had finished and checking of SPI_SR_TXEMPTY was introduced to rule out a possible cause for the data corruption mentioned in r236495 but which didn't turn out to be the problem anyway. MFC after: 3 days
2012-06-18 20:14:42 +00:00
if ((sr & SPI_SR_RXBUFF) != 0) {
sc->xfer_done = 1;
WR4(sc, SPI_IDR, SPI_SR_RXBUFF);
- Prepend the device description with "AT91" to reflect its nature. [1] - Move DMA tag and map creature to at91_spi_activate() where the other resource allocation also lives. [1] - Flesh out at91_spi_deactivate(). [1] - Work around the "Software Reset must be Written Twice" erratum. - For now, run the bus at the slowest speed possible in order to work around data corruption on transit even seen with 9 MHz on ETHERNUT5 (15 MHz maximum) and AT45DB321D (20 MHz maximum). This also serves as a poor man's work-around for the "NPCSx rises if no data data is to be transmitted" erratum of RM9200. Being able to use the appropriate bus speed would require: 1) Adding a proper work-around for the RM9200 bug consisting of taking the chip select control away from the SPI peripheral and managing it directly as a GPIO line. 2) Taking the maximum frequencies supported by the actual board and the slave devices into account and basing the whole thing on the master clock instead of hardcoding a divisor as previously done. 3) Fixing the above mentioned data corruption. - KASSERT that TX/RX command and data sizes match on transfers. - Introduce a mutex ensuring that only one child device is running a SPI transfer at a time. [1] - Add preliminary, #ifdef'ed out support for setting the chip select. [1] - Use the RX instead of the TX commando size when setting up the RX side of a transfer. - For controllers having SPI_SR_TXEMPTY, i.e. !RM9200, also wait for the completion of the TX part of transfers before stopping the whole thing again. - Use DEVMETHOD_END. [1] - Use NULL instead of 0 for pointers. [1, partially] Additional testing by: Ian Lepore Submitted by: Ian Lepore [1] MFC after: 1 week
2012-06-03 00:54:10 +00:00
wakeup(&sc->xfer_done);
MFp4: Working SPI driver.
2006-10-20 07:10:13 +00:00
}
Revert the part of r236495 that introduced checking of SPI_SR_TXEMPTY for TX transfer completion as for reasons unknown this occasionally causes SPI_SR_RXBUFF and SPI_SR_ENDRX to not rise. In any case, once the RX part of the transfer is done it's obvious that the preceding TX part had finished and checking of SPI_SR_TXEMPTY was introduced to rule out a possible cause for the data corruption mentioned in r236495 but which didn't turn out to be the problem anyway. MFC after: 3 days
2012-06-18 20:14:42 +00:00
if ((sr & ~SPI_SR_RXBUFF) != 0) {
MFp4: Working SPI driver.
2006-10-20 07:10:13 +00:00
device_printf(sc->dev, "Unexpected ISR %#x\n", sr);
Revert the part of r236495 that introduced checking of SPI_SR_TXEMPTY for TX transfer completion as for reasons unknown this occasionally causes SPI_SR_RXBUFF and SPI_SR_ENDRX to not rise. In any case, once the RX part of the transfer is done it's obvious that the preceding TX part had finished and checking of SPI_SR_TXEMPTY was introduced to rule out a possible cause for the data corruption mentioned in r236495 but which didn't turn out to be the problem anyway. MFC after: 3 days
2012-06-18 20:14:42 +00:00
WR4(sc, SPI_IDR, sr & ~SPI_SR_RXBUFF);
MFp4: Working SPI driver.
2006-10-20 07:10:13 +00:00
}
}
static devclass_t at91_spi_devclass;
Import support for the Atmel AT91RM9200 CPU/Microcontroller. This SoC is a ARM920T based CPU with a bunch of built-in peripherals. The inital import supports the SPI bus, the TWI bus (although iicbus integration is not complete), the uarts, the system timer and the onboard ethernet. Support for the Kwikbyte KB9202 (http://www.kwikbyte.com) board is also included, although there's no reason why the 9200 and the 9201 wouldn't also work. Primitive support for running under the skyeye emulator is also provided (although skyeye's support for the AT91RM9200 is a little weak). The code has been structured so that other members of Atmel's arm family can be supported in the future. The AT91SAM9260 is not presently supported due to lack of hardware. The arm7tdmi families are also not supported becasue they lack an MMU. Many thanks to cognet@ for his help and assistance in bringing up this board. He did much of the vm work and wrote parts of the uart and system timer code as well as the bus space implementation. The system boots to single user w/o problem, although the serial console is a little slow and the ethernet driver is still in flux. This work was sponsored by Timing Solutions, Corporation. I am grateful to their support of the FreeBSD project in this manner.
2006-02-04 23:32:13 +00:00
static device_method_t at91_spi_methods[] = {
/* Device interface */
DEVMETHOD(device_probe, at91_spi_probe),
DEVMETHOD(device_attach, at91_spi_attach),
DEVMETHOD(device_detach, at91_spi_detach),
MF p4: Adapt to forthcoming spi framework. The ioctls for SPI commands and such belong in the higher level driver.
2006-07-14 21:35:59 +00:00
/* spibus interface */
DEVMETHOD(spibus_transfer, at91_spi_transfer),
- Prepend the device description with "AT91" to reflect its nature. [1] - Move DMA tag and map creature to at91_spi_activate() where the other resource allocation also lives. [1] - Flesh out at91_spi_deactivate(). [1] - Work around the "Software Reset must be Written Twice" erratum. - For now, run the bus at the slowest speed possible in order to work around data corruption on transit even seen with 9 MHz on ETHERNUT5 (15 MHz maximum) and AT45DB321D (20 MHz maximum). This also serves as a poor man's work-around for the "NPCSx rises if no data data is to be transmitted" erratum of RM9200. Being able to use the appropriate bus speed would require: 1) Adding a proper work-around for the RM9200 bug consisting of taking the chip select control away from the SPI peripheral and managing it directly as a GPIO line. 2) Taking the maximum frequencies supported by the actual board and the slave devices into account and basing the whole thing on the master clock instead of hardcoding a divisor as previously done. 3) Fixing the above mentioned data corruption. - KASSERT that TX/RX command and data sizes match on transfers. - Introduce a mutex ensuring that only one child device is running a SPI transfer at a time. [1] - Add preliminary, #ifdef'ed out support for setting the chip select. [1] - Use the RX instead of the TX commando size when setting up the RX side of a transfer. - For controllers having SPI_SR_TXEMPTY, i.e. !RM9200, also wait for the completion of the TX part of transfers before stopping the whole thing again. - Use DEVMETHOD_END. [1] - Use NULL instead of 0 for pointers. [1, partially] Additional testing by: Ian Lepore Submitted by: Ian Lepore [1] MFC after: 1 week
2012-06-03 00:54:10 +00:00
DEVMETHOD_END
Import support for the Atmel AT91RM9200 CPU/Microcontroller. This SoC is a ARM920T based CPU with a bunch of built-in peripherals. The inital import supports the SPI bus, the TWI bus (although iicbus integration is not complete), the uarts, the system timer and the onboard ethernet. Support for the Kwikbyte KB9202 (http://www.kwikbyte.com) board is also included, although there's no reason why the 9200 and the 9201 wouldn't also work. Primitive support for running under the skyeye emulator is also provided (although skyeye's support for the AT91RM9200 is a little weak). The code has been structured so that other members of Atmel's arm family can be supported in the future. The AT91SAM9260 is not presently supported due to lack of hardware. The arm7tdmi families are also not supported becasue they lack an MMU. Many thanks to cognet@ for his help and assistance in bringing up this board. He did much of the vm work and wrote parts of the uart and system timer code as well as the bus space implementation. The system boots to single user w/o problem, although the serial console is a little slow and the ethernet driver is still in flux. This work was sponsored by Timing Solutions, Corporation. I am grateful to their support of the FreeBSD project in this manner.
2006-02-04 23:32:13 +00:00
};
static driver_t at91_spi_driver = {
- Make SPI bus bridge be non-arch dependent by using more generic name Reviewed by: imp
2009-05-13 18:42:49 +00:00
"spi",
Import support for the Atmel AT91RM9200 CPU/Microcontroller. This SoC is a ARM920T based CPU with a bunch of built-in peripherals. The inital import supports the SPI bus, the TWI bus (although iicbus integration is not complete), the uarts, the system timer and the onboard ethernet. Support for the Kwikbyte KB9202 (http://www.kwikbyte.com) board is also included, although there's no reason why the 9200 and the 9201 wouldn't also work. Primitive support for running under the skyeye emulator is also provided (although skyeye's support for the AT91RM9200 is a little weak). The code has been structured so that other members of Atmel's arm family can be supported in the future. The AT91SAM9260 is not presently supported due to lack of hardware. The arm7tdmi families are also not supported becasue they lack an MMU. Many thanks to cognet@ for his help and assistance in bringing up this board. He did much of the vm work and wrote parts of the uart and system timer code as well as the bus space implementation. The system boots to single user w/o problem, although the serial console is a little slow and the ethernet driver is still in flux. This work was sponsored by Timing Solutions, Corporation. I am grateful to their support of the FreeBSD project in this manner.
2006-02-04 23:32:13 +00:00
at91_spi_methods,
sizeof(struct at91_spi_softc),
};
Add FDT attachment.
2014-02-09 21:00:22 +00:00
#ifdef FDT
DRIVER_MODULE(at91_spi, simplebus, at91_spi_driver, at91_spi_devclass, NULL,
NULL);
#else
- Prepend the device description with "AT91" to reflect its nature. [1] - Move DMA tag and map creature to at91_spi_activate() where the other resource allocation also lives. [1] - Flesh out at91_spi_deactivate(). [1] - Work around the "Software Reset must be Written Twice" erratum. - For now, run the bus at the slowest speed possible in order to work around data corruption on transit even seen with 9 MHz on ETHERNUT5 (15 MHz maximum) and AT45DB321D (20 MHz maximum). This also serves as a poor man's work-around for the "NPCSx rises if no data data is to be transmitted" erratum of RM9200. Being able to use the appropriate bus speed would require: 1) Adding a proper work-around for the RM9200 bug consisting of taking the chip select control away from the SPI peripheral and managing it directly as a GPIO line. 2) Taking the maximum frequencies supported by the actual board and the slave devices into account and basing the whole thing on the master clock instead of hardcoding a divisor as previously done. 3) Fixing the above mentioned data corruption. - KASSERT that TX/RX command and data sizes match on transfers. - Introduce a mutex ensuring that only one child device is running a SPI transfer at a time. [1] - Add preliminary, #ifdef'ed out support for setting the chip select. [1] - Use the RX instead of the TX commando size when setting up the RX side of a transfer. - For controllers having SPI_SR_TXEMPTY, i.e. !RM9200, also wait for the completion of the TX part of transfers before stopping the whole thing again. - Use DEVMETHOD_END. [1] - Use NULL instead of 0 for pointers. [1, partially] Additional testing by: Ian Lepore Submitted by: Ian Lepore [1] MFC after: 1 week
2012-06-03 00:54:10 +00:00
DRIVER_MODULE(at91_spi, atmelarm, at91_spi_driver, at91_spi_devclass, NULL,
NULL);
Add FDT attachment.
2014-02-09 21:00:22 +00:00
#endif
Reference in New Issue Copy Permalink