History log of /freebsd-10.0-release/sys/arm/at91/at91_spi.c
Revision Date Author Comments
(<<< Hide modified files)
(Show modified files >>>)
# 259065 07-Dec-2013 gjb

- Copy stable/10 (r259064) to releng/10.0 as part of the
10.0-RELEASE cycle.
- Update __FreeBSD_version [1]
- Set branch name to -RC1

[1] 10.0-CURRENT __FreeBSD_version value ended at '55', so
start releng/10.0 at '100' so the branch is started with
a value ending in zero.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation

# 256281 10-Oct-2013 gjb

Copy head (r256279) to stable/10 as part of the 10.0-RELEASE cycle.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation


# 239626 23-Aug-2012 imp

Fetch the chip select in the bridge driver, like all the other spi
bridges do.


# 238955 31-Jul-2012 imp

Allow chip selects other than 0. The SAM9260EK board
has its dataflash on CS1.


# 237239 18-Jun-2012 marius

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


# 236495 02-Jun-2012 marius

- 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


# 225882 30-Sep-2011 kevlo

Remove pointless semicolons after label


# 192059 13-May-2009 gonzo

- Make SPI bus bridge be non-arch dependent by using more generic
name

Reviewed by: imp


# 185265 24-Nov-2008 imp

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.


# 183670 07-Oct-2008 imp

Use bus_get_dma_tag() instead of NULL here. Not really needed for atmel
at the moment, but it is more correct.


# 167082 27-Feb-2007 jhb

Use tsleep() rather than msleep() with a NULL mtx.


# 166901 23-Feb-2007 piso

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@


# 164741 29-Nov-2006 imp

MFp4:
correct data counts so that we clock enough data for the spi
transaction. This allows complete spi transactions to happen.


# 163526 20-Oct-2006 imp

MFp4: Working SPI driver.


# 160358 14-Jul-2006 imp

MF p4:

Adapt to forthcoming spi framework. The ioctls for SPI commands and such
belong in the higher level driver.


# 155324 04-Feb-2006 imp

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.