spelling fixes: arch/sh/

Spelling fixes in arch/sh/.

Signed-off-by: Simon Arlott <simon@fire.lp0.eu>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>

arch/sh/drivers/dma/dma-api.c

@@ -115,7 +115,7 @@ static int search_cap(const char **haystack, const char *needle)
 /**
  * request_dma_bycap - Allocate a DMA channel based on its capabilities
  * @dmac: List of DMA controllers to search
- * @caps: List of capabilites
+ * @caps: List of capabilities
  *
  * Search all channels of all DMA controllers to find a channel which
  * matches the requested capabilities. The result is the channel

arch/sh/drivers/dma/dma-isa.c

@@ -28,7 +28,7 @@
  * NOTE: ops->xfer() is the preferred way of doing things. However, there
  * are some users of the ISA DMA API that exist in common code that we
  * don't necessarily want to go out of our way to break, so we still
- * allow for some compatability at that level. Any new code is strongly
+ * allow for some compatibility at that level. Any new code is strongly
  * advised to run far away from the ISA DMA API and use the SH DMA API
  * directly.
  */

arch/sh/drivers/dma/dmabrg.c

@@ -33,7 +33,7 @@
  *     9      | HAC1/SSI1 | rec | half done    | DMABRGI2
  *
  * all can be enabled/disabled in the DMABRGCR register,
- * as well as checked if they occured.
+ * as well as checked if they occurred.
  *
  * DMABRGI0 services  USB  DMA  Address  errors,  but it still must be
  * enabled/acked in the DMABRGCR register.  USB-DMA complete indicator

arch/sh/drivers/pci/ops-dreamcast.c

@@ -57,7 +57,7 @@ struct pci_channel board_pci_channels[] = {
  *
  * Also, we could very easily support both Type 0 and Type 1 configurations
  * here, but since it doesn't seem that there is any such implementation in
- * existance, we don't bother.
+ * existence, we don't bother.
  *
  * I suppose if someone actually gets around to ripping the chip out of
  * the BBA and hanging some more devices off of it, then this might be

arch/sh/drivers/pci/pci-st40.c

@@ -292,7 +292,7 @@ int __init st40pci_init(unsigned memStart, unsigned memSize)
 			    PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER |
 			    PCI_COMMAND_IO);
 
-	/* Accesse to the 0xb0000000 -> 0xb6000000 area will go through to 0x10000000 -> 0x16000000
+	/* Access to the 0xb0000000 -> 0xb6000000 area will go through to 0x10000000 -> 0x16000000
 	 * on the PCI bus. This allows a nice 1-1 bus to phys mapping.
 	 */
 
@@ -315,7 +315,7 @@ int __init st40pci_init(unsigned memStart, unsigned memSize)
 	ST40PCI_WRITE(CSR_MBAR0, 0);
 	ST40PCI_WRITE(LSR0, 0x0fff0001);
 
-	/* ... and set up the initial incomming window to expose all of RAM */
+	/* ... and set up the initial incoming window to expose all of RAM */
 	pci_set_rbar_region(7, memStart, memStart, memSize);
 
 	/* Maximise timeout values */
@@ -473,7 +473,7 @@ static void pci_set_rbar_region(unsigned int region,     unsigned long localAddr
 
 	mask = r2p2(regionSize) - 0x10000;
 
-	/* Diable the region (in case currently in use, should never happen) */
+	/* Disable the region (in case currently in use, should never happen) */
 	ST40PCI_WRITE_INDEXED(RSR, region, 0);
 
 	/* Start of local address space to publish */

arch/sh/drivers/pci/pci-st40.h

@@ -4,7 +4,7 @@
  * May be copied or modified under the terms of the GNU General Public
  * License.  See linux/COPYING for more information.                            
  *
- * Defintions for the ST40 PCI hardware.
+ * Definitions for the ST40 PCI hardware.
  */
 
 #ifndef __PCI_ST40_H__

arch/sh/drivers/superhyway/ops-sh4-202.c

@@ -130,7 +130,7 @@ static int sh4202_read_vcr(unsigned long base, struct superhyway_vcr_info *vcr)
 	 * Some modules (PBR and ePBR for instance) also appear to have
 	 * VCRL/VCRH flipped in the documentation, but on the SH4-202
 	 * itself it appears that these are all consistently mapped with
-	 * VCRH preceeding VCRL.
+	 * VCRH preceding VCRL.
 	 *
 	 * Do not trust the documentation, for it is evil.
 	 */