Fix spelling/wording issues

Found by using:
    codespell --builtin clear,rare,usage,informal,code,names

Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>

7 files changed, 30 insertions, 30 deletions

diff --git a/README.md b/README.md
index be2645f..44feb0b 100644
--- a/README.md
+++ b/README.md
@@ -6,7 +6,7 @@ Xorg mailing list:
 
   https://lists.x.org/mailman/listinfo/xorg
 
-The master development code repository can be found at:
+The primary development code repository can be found at:
 
   https://gitlab.freedesktop.org/xorg/driver/xf86-video-tseng
 
diff --git a/src/README b/src/README
index dca1c6b..638925b 100644
--- a/src/README
+++ b/src/README
@@ -7,10 +7,10 @@ This file is NOT up to date for the New Design!
 
 ============== old (pre-ND) contents below ==============
 
-"I just thought it would be usefull if we had some kind of TODO and BUGS
+"I just thought it would be useful if we had some kind of TODO and BUGS
 files in the distribution as it would make it easier to see what is needed
 to be done and what could be done better, instead of browsing through the
-sourcecode. And we whould be able to se the progress literally by the ever
+sourcecode. And we would be able to see the progress literally by the ever
 decreasing TODO file :-)"
 
 
@@ -30,7 +30,7 @@ half of the cursor displayed)
 * text font sometimes corrupted when going back to text mode. This may be
 related to the order in which registers are restored: the ARK driver first
 restores extended registers before restoring the standard registers for
-excactly this reason.
+exactly this reason.
 
 * The code needs to be heavily reworked to fix all sorts of data type
 problems. The current code will certainly not run on an Alpha. The first
@@ -94,7 +94,7 @@ extensions to the MIX hardware compared to the ET4000).
 * Mclk support is still lacking (that would also allow MClk-dependent
 maximum bandwidth).
 
-* Apart from the things mentionned above, I think the ET6000 server is
+* Apart from the things mentioned above, I think the ET6000 server is
 pretty complete. Some optimisations could possibly be added. Like for
 example some assembler code for calculating a framebuffer address from X/Y
 coordinates. That would help to speed up small blits.
@@ -111,30 +111,30 @@ We're using a ping-pong buffer scheme (triple buffering actually) in
 off-screen memory to store one scanline worth of font data at a time. each
 of these scanlines is "blitted" to on-screen memory using the accelerator.
 The scanline is the MIX map, and there's also a 4x1 solid foreground color
-(SRC map), and a 4x1 solid background color (PAT map). 
+(SRC map), and a 4x1 solid background color (PAT map).
 
 Basically, the flow is as follows:
 
 	- setup accelerator for font-expansion
-	
+
 	- store scanline 1 in off-screen memory buffer 1
-	
+
 	- start operation
-	
+
 	- store scanline 2 in off-screen memory buffer 2
-	
+
 	- start operation
-	
+
 	- store scanline 3 in off-screen memory buffer 3
-	
+
 	- start operation
-	
+
 	- store scanline 4 in off-screen memory buffer 1
-	
+
 	- start operation
-	
+
 	... etc, until the whole line of text is drawn.
-	
+
 There is no explicit "waiting" for the accelerator to finish an operation
 before starting a new one, because it has been set up to add "wait-states"
 when the queue is full. We're aiming to use concurrency between the
@@ -172,11 +172,11 @@ Here's an attempt at showing you what _should_ have been rendered:
 
 and what _is_ rendered sometimes (only an example):
 
-1  
+1
 2   #####################################################################
 3
 4
-5 
+5
 6   ########################                                #############
 7
 8
@@ -186,7 +186,7 @@ and what _is_ rendered sometimes (only an example):
 12
 13  ########################
 14  #####################################################################
-15  
+15
 
 At line 6, 32 pixels of the "black" scanline data from line 3 is rendered
 instead of the actual full-white that would normally have to be there. At
diff --git a/src/tseng.h b/src/tseng.h
index 2e05090..9f88ace 100644
--- a/src/tseng.h
+++ b/src/tseng.h
@@ -44,7 +44,7 @@
 
 #include "compat-api.h"
 /*
- * Contrary to the old driver, we use the "Chip Revision" here intead of
+ * Contrary to the old driver, we use the "Chip Revision" here instead of
  * multiple chipsets like "TYPE_ET4000W32Pa", "TYPE_ET4000W32Pb", etc.
  */
 
diff --git a/src/tseng_accel.c b/src/tseng_accel.c
index 3edf001..a291d54 100644
--- a/src/tseng_accel.c
+++ b/src/tseng_accel.c
@@ -142,7 +142,7 @@ tseng_init_acl(ScrnInfoPtr pScrn)
     pTseng->scratchMemBase = pTseng->FbBase + pTseng->AccelColorBufferOffset;
     /* 
      * we won't be using tsengCPU2ACLBase in linear memory mode anyway, since
-     * using the MMU apertures restricts the amount of useable video memory
+     * using the MMU apertures restricts the amount of usable video memory
      * to only 2MB, supposing we ONLY redirect MMU aperture 2 to the CPU.
      * (see data book W32p, page 207)
      */
@@ -1093,7 +1093,7 @@ TsengSubsequentImageWriteScanline(ScrnInfoPtr pScrn,
  *
  * 3. The Tseng data book says that the ACL Y count register needs to be
  *    programmed with "dy-1". A similar thing is said about ACL X count. But
- *    this assumes (x2,y2) is NOT drawn (although that is not mentionned in
+ *    this assumes (x2,y2) is NOT drawn (although that is not mentioned in
  *    the data book). X assumes the endpoint _is_ drawn. If "dy-1" is used,
  *    this sometimes results in a negative value (if dx==dy==0),
  *    causing a complete accelerator hang.
@@ -1304,7 +1304,7 @@ TsengXAAInit(ScreenPtr pScreen)
      *
      * The W32 and W32i chips don't have a register to set the amount of
      * bytes per pixel, and hence they don't skip 1 byte in each 4-byte word
-     * at 24bpp. Therefor, the FG or BG colors would have to be concatenated
+     * at 24bpp. Therefore, the FG or BG colors would have to be concatenated
      * in video memory (R-G-B-R-G-B-... instead of R-G-B-X-R-G-B-X-..., with
      * X = dont' care), plus a wrap value that is a multiple of 3 would have
      * to be set. There is no such wrap combination available.
diff --git a/src/tseng_cursor.c b/src/tseng_cursor.c
index 3c8a70f..78a3d0f 100644
--- a/src/tseng_cursor.c
+++ b/src/tseng_cursor.c
@@ -238,7 +238,7 @@ TsengHWCursorInit(ScreenPtr pScreen)
 
     pTseng->CursorInfoRec = infoPtr;
 
-    /* calculate memory addres from video memory offsets */
+    /* calculate memory address from video memory offsets */
     pTseng->HWCursorBuffer =
 	pTseng->FbBase + pTseng->HWCursorBufferOffset;
 
diff --git a/src/tseng_driver.c b/src/tseng_driver.c
index 0db62e5..2ccc6d3 100644
--- a/src/tseng_driver.c
+++ b/src/tseng_driver.c
@@ -100,7 +100,7 @@ static int pix24bpp = 0;
 /* 
  * This contains the functions needed by the server after loading the
  * driver module.  It must be supplied, and gets added the driver list by
- * the Module Setup funtion in the dynamic case.  In the static case a
+ * the Module Setup function in the dynamic case.  In the static case a
  * reference to this is compiled in, and this requires that the name of
  * this DriverRec be an upper-case version of the driver name.
  */
@@ -1564,7 +1564,7 @@ TsengCloseScreen(CLOSE_SCREEN_ARGS_DECL)
  * partially reset to "0" when TS register index 0 bit 1 is set (synchronous
  * reset): bits 3..5 are reset during a sync. reset.
  *
- * We therefor do _not_ call vgaHWSaveScreen here, since it does a sequencer
+ * We therefore do _not_ call vgaHWSaveScreen here, since it does a sequencer
  * reset. Instead, we do the same as in vgaHWSaveScreen except for the seq. reset.
  *
  * If this is not done, the higher level code will not be able to access the
diff --git a/src/tseng_mode.c b/src/tseng_mode.c
index c96403e..a6cbdeb 100644
--- a/src/tseng_mode.c
+++ b/src/tseng_mode.c
@@ -458,7 +458,7 @@ STG1703Clock(ScrnInfoPtr pScrn, int Clock)
 }
 
 /*
- * Copy the given Regs into a freshly alloced STG1703Regs
+ * Copy the given Regs into a freshly allocated STG1703Regs
  * and init it for the new mode.
  */
 static struct STG1703Regs *
@@ -795,7 +795,7 @@ TsengRAMDACProbe(ScrnInfoPtr pScrn)
  *
  * We should also take acceleration into account: accelerated modes
  * strain the bandwidth heavily, because they cause lots of random
- * acesses to video memory, which is bad for bandwidth due to smaller
+ * accesses to video memory, which is bad for bandwidth due to smaller
  * page-mode memory requests.
  */
 void
@@ -1272,7 +1272,7 @@ TsengModeInit(ScrnInfoPtr pScrn, DisplayModePtr OrigMode)
              * in 24bpp, the position of the BLANK signal determines the
              * phase of the R,G and B values. XFree86 sets blanking equal to
              * the Sync, so setting the Sync correctly will also set the
-             * BLANK corectly, and thus also the RGB phase
+             * BLANK correctly, and thus also the RGB phase
              */
             rgb_skew = (mode->CrtcHTotal / 8 - mode->CrtcHBlankEnd / 8 - 1) % 3;
             mode->CrtcHBlankEnd += rgb_skew * 8 + 24;
@@ -1359,7 +1359,7 @@ TsengModeInit(ScrnInfoPtr pScrn, DisplayModePtr OrigMode)
      * some bits we want to change. 
      * Notably bit 7 of CRTC 0x34, which changes RAS setup time from 4 to 0 ns 
      * (performance),
-     * and bit 7 of CRTC 0x37, which changes the CRTC FIFO low treshold control.
+     * and bit 7 of CRTC 0x37, which changes the CRTC FIFO low threshold control.
      * At really high pixel clocks, this will avoid lots of garble on the screen 
      * when something is being drawn. This only happens WAY beyond 80 MHz 
      * (those 135 MHz ramdac's...)