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
- 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
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.
