Documentation: remove duplicated words
Remove many duplicated words under Documentation/ and do other small cleanups. Examples: "and and" --> "and" "in in" --> "in" "the the" --> "the" "the the" --> "to the" ... Signed-off-by: Paolo Ornati <ornati@fastwebnet.it> Signed-off-by: Adrian Bunk <bunk@stusta.de>
This commit is contained in:
committed by
Adrian Bunk
parent
53cb47268e
commit
670e9f34ee
@@ -124,12 +124,12 @@ use a value of 8.
|
||||
The "pxa2xx_spi_chip.timeout_microsecs" fields is used to efficiently handle
|
||||
trailing bytes in the SSP receiver fifo. The correct value for this field is
|
||||
dependent on the SPI bus speed ("spi_board_info.max_speed_hz") and the specific
|
||||
slave device. Please note the the PXA2xx SSP 1 does not support trailing byte
|
||||
slave device. Please note that the PXA2xx SSP 1 does not support trailing byte
|
||||
timeouts and must busy-wait any trailing bytes.
|
||||
|
||||
The "pxa2xx_spi_chip.enable_loopback" field is used to place the SSP porting
|
||||
into internal loopback mode. In this mode the SSP controller internally
|
||||
connects the SSPTX pin the the SSPRX pin. This is useful for initial setup
|
||||
connects the SSPTX pin to the SSPRX pin. This is useful for initial setup
|
||||
testing.
|
||||
|
||||
The "pxa2xx_spi_chip.cs_control" field is used to point to a board specific
|
||||
@@ -208,7 +208,7 @@ DMA and PIO I/O Support
|
||||
-----------------------
|
||||
The pxa2xx_spi driver support both DMA and interrupt driven PIO message
|
||||
transfers. The driver defaults to PIO mode and DMA transfers must enabled by
|
||||
setting the "enable_dma" flag in the "pxa2xx_spi_master" structure and and
|
||||
setting the "enable_dma" flag in the "pxa2xx_spi_master" structure and
|
||||
ensuring that the "pxa2xx_spi_chip.dma_burst_size" field is non-zero. The DMA
|
||||
mode support both coherent and stream based DMA mappings.
|
||||
|
||||
|
@@ -262,7 +262,7 @@ NON-STATIC CONFIGURATIONS
|
||||
Developer boards often play by different rules than product boards, and one
|
||||
example is the potential need to hotplug SPI devices and/or controllers.
|
||||
|
||||
For those cases you might need to use use spi_busnum_to_master() to look
|
||||
For those cases you might need to use spi_busnum_to_master() to look
|
||||
up the spi bus master, and will likely need spi_new_device() to provide the
|
||||
board info based on the board that was hotplugged. Of course, you'd later
|
||||
call at least spi_unregister_device() when that board is removed.
|
||||
@@ -322,7 +322,7 @@ As soon as it enters probe(), the driver may issue I/O requests to
|
||||
the SPI device using "struct spi_message". When remove() returns,
|
||||
the driver guarantees that it won't submit any more such messages.
|
||||
|
||||
- An spi_message is a sequence of of protocol operations, executed
|
||||
- An spi_message is a sequence of protocol operations, executed
|
||||
as one atomic sequence. SPI driver controls include:
|
||||
|
||||
+ when bidirectional reads and writes start ... by how its
|
||||
|
Reference in New Issue
Block a user