Correct spelling problems for Documentation/arm/ as reported
by codespell.
Signed-off-by: Randy Dunlap <rdunlap@xxxxxxxxxxxxx>
Cc: Russell King <linux@xxxxxxxxxxxxxxx>
Cc: linux-arm-kernel@xxxxxxxxxxxxxxxxxxx
Cc: Jonathan Corbet <corbet@xxxxxxx>
Cc: linux-doc@xxxxxxxxxxxxxxx
---
Documentation/arm/arm.rst | 2 +-
Documentation/arm/ixp4xx.rst | 4 ++--
Documentation/arm/keystone/knav-qmss.rst | 2 +-
Documentation/arm/stm32/stm32-dma-mdma-chaining.rst | 6 +++---
Documentation/arm/sunxi/clocks.rst | 2 +-
Documentation/arm/swp_emulation.rst | 2 +-
Documentation/arm/tcm.rst | 2 +-
Documentation/arm/vlocks.rst | 2 +-
8 files changed, 11 insertions(+), 11 deletions(-)
diff -- a/Documentation/arm/ixp4xx.rst b/Documentation/arm/ixp4xx.rst
--- a/Documentation/arm/ixp4xx.rst
+++ b/Documentation/arm/ixp4xx.rst
@@ -78,9 +78,9 @@ IXP4xx provides two methods of accessing
1) A direct mapped window from 0x48000000 to 0x4bffffff (64MB).
To access PCI via this space, we simply ioremap() the BAR
into the kernel and we can use the standard read[bwl]/write[bwl]
- macros. This is the preffered method due to speed but it
+ macros. This is the preferred method due to speed but it
limits the system to just 64MB of PCI memory. This can be
- problamatic if using video cards and other memory-heavy devices.
+ problematic if using video cards and other memory-heavy devices.
2) If > 64MB of memory space is required, the IXP4xx can be
configured to use indirect registers to access PCI This allows
diff -- a/Documentation/arm/swp_emulation.rst b/Documentation/arm/swp_emulation.rst
--- a/Documentation/arm/swp_emulation.rst
+++ b/Documentation/arm/swp_emulation.rst
@@ -1,7 +1,7 @@
Software emulation of deprecated SWP instruction (CONFIG_SWP_EMULATE)
---------------------------------------------------------------------
-ARMv6 architecture deprecates use of the SWP/SWPB instructions, and recommeds
+ARMv6 architecture deprecates use of the SWP/SWPB instructions, and recommends
moving to the load-locked/store-conditional instructions LDREX and STREX.
ARMv7 multiprocessing extensions introduce the ability to disable these
diff -- a/Documentation/arm/tcm.rst b/Documentation/arm/tcm.rst
--- a/Documentation/arm/tcm.rst
+++ b/Documentation/arm/tcm.rst
@@ -71,7 +71,7 @@ in <asm/tcm.h>. Using this interface it
- Have the remaining TCM RAM added to a special
allocation pool with gen_pool_create() and gen_pool_add()
- and provice tcm_alloc() and tcm_free() for this
+ and provide tcm_alloc() and tcm_free() for this
memory. Such a heap is great for things like saving
device state when shutting off device power domains.
diff -- a/Documentation/arm/stm32/stm32-dma-mdma-chaining.rst b/Documentation/arm/stm32/stm32-dma-mdma-chaining.rst
--- a/Documentation/arm/stm32/stm32-dma-mdma-chaining.rst
+++ b/Documentation/arm/stm32/stm32-dma-mdma-chaining.rst
@@ -359,7 +359,7 @@ Driver updates for STM32 DMA-MDMA chaini
descriptor you want a callback to be called at the end of the transfer
(dmaengine_prep_slave_sg()) or the period (dmaengine_prep_dma_cyclic()).
Depending on the direction, set the callback on the descriptor that finishes
- the overal transfer:
+ the overall transfer:
* DMA_DEV_TO_MEM: set the callback on the "MDMA" descriptor
* DMA_MEM_TO_DEV: set the callback on the "DMA" descriptor
@@ -371,7 +371,7 @@ Driver updates for STM32 DMA-MDMA chaini
As STM32 MDMA channel transfer is triggered by STM32 DMA, you must issue
STM32 MDMA channel before STM32 DMA channel.
- If any, your callback will be called to warn you about the end of the overal
+ If any, your callback will be called to warn you about the end of the overall
transfer or the period completion.
Don't forget to terminate both channels. STM32 DMA channel is configured in
@@ -412,4 +412,4 @@ Resources
:Authors:
-- Amelie Delaunay <amelie.delaunay@xxxxxxxxxxx>
\ No newline at end of file
+- Amelie Delaunay <amelie.delaunay@xxxxxxxxxxx>
diff -- a/Documentation/arm/arm.rst b/Documentation/arm/arm.rst
--- a/Documentation/arm/arm.rst
+++ b/Documentation/arm/arm.rst
@@ -141,7 +141,7 @@ ST506 hard drives
`*configure` harddrive set to 2). I've got an internal 20MB and a great
big external 5.25" FH 64MB drive (who could ever want more :-) ).
- I've just got 240K/s off it (a dd with bs=128k); thats about half of what
+ I've just got 240K/s off it (a dd with bs=128k); that's about half of what
RiscOS gets; but it's a heck of a lot better than the 50K/s I was getting
last week :-)
diff -- a/Documentation/arm/keystone/knav-qmss.rst b/Documentation/arm/keystone/knav-qmss.rst
--- a/Documentation/arm/keystone/knav-qmss.rst
+++ b/Documentation/arm/keystone/knav-qmss.rst
@@ -39,7 +39,7 @@ CPPI/QMSS Low Level Driver document (doc
git://git.ti.com/keystone-rtos/qmss-lld.git
-k2_qmss_pdsp_acc48_k2_le_1_0_0_9.bin firmware supports upto 48 accumulator
+k2_qmss_pdsp_acc48_k2_le_1_0_0_9.bin firmware supports up to 48 accumulator
channels. This firmware is available under ti-keystone folder of
firmware.git at
diff -- a/Documentation/arm/sunxi/clocks.rst b/Documentation/arm/sunxi/clocks.rst
--- a/Documentation/arm/sunxi/clocks.rst
+++ b/Documentation/arm/sunxi/clocks.rst
@@ -5,7 +5,7 @@ Frequently asked questions about the sun
This document contains useful bits of information that people tend to ask
about the sunxi clock system, as well as accompanying ASCII art when adequate.
-Q: Why is the main 24MHz oscillator gatable? Wouldn't that break the
+Q: Why is the main 24MHz oscillator gateable? Wouldn't that break the
system?
A: The 24MHz oscillator allows gating to save power. Indeed, if gated
diff -- a/Documentation/arm/vlocks.rst b/Documentation/arm/vlocks.rst
--- a/Documentation/arm/vlocks.rst
+++ b/Documentation/arm/vlocks.rst
@@ -155,7 +155,7 @@ the basic algorithm:
optimisation.
If there are too many CPUs to read the currently_voting array in
- one transaction then multiple transations are still required. The
+ one transaction then multiple transactions are still required. The
implementation uses a simple loop of word-sized loads for this
case. The number of transactions is still fewer than would be
required if bytes were loaded individually.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel