Commit 2ed4ba94 authored by Tom Rix's avatar Tom Rix Committed by Vinod Koul
Browse files

dmaengine: ti: cleanup comments 



Remove the second 'the'

Replacements
completetion to completion
seens to seen
pendling to pending
atleast to at least
tranfer to transfer
multibple to a multiple
transfering to transferring

Signed-off-by: default avatarTom Rix <trix@redhat.com>
Acked-by: default avatarPeter Ujfalusi <peter.ujfalusi@gmail.com>
Reviewed-by: default avatarRandy Dunlap <rdunlap@infradead.org>
Link: https://lore.kernel.org/r/20220217182546.3266909-1-trix@redhat.com


Signed-off-by: default avatarVinod Koul <vkoul@kernel.org>
parent fb7a444a

drivers/dma/ti/cppi41.c

+3 −3
Original line number Diff line number Diff line
@@ -315,7 +315,7 @@ static irqreturn_t cppi41_irq(int irq, void *data) 
		val = cppi_readl(cdd->qmgr_mem + QMGR_PEND(i));

		if (i == QMGR_PENDING_SLOT_Q(first_completion_queue) && val) {

			u32 mask;

			/* set corresponding bit for completetion Q 93 */

			/* set corresponding bit for completion Q 93 */

			mask = 1 << QMGR_PENDING_BIT_Q(first_completion_queue);

			/* not set all bits for queues less than Q 93 */

			mask--;
@@ -703,7 +703,7 @@ static int cppi41_tear_down_chan(struct cppi41_channel *c) 
	 * transfer descriptor followed by TD descriptor. Waiting seems not to

	 * cause any difference.

	 * RX seems to be thrown out right away. However once the TearDown

	 * descriptor gets through we are done. If we have seens the transfer

	 * descriptor gets through we are done. If we have seen the transfer

	 * descriptor before the TD we fetch it from enqueue, it has to be

	 * there waiting for us.

	 */
@@ -747,7 +747,7 @@ static int cppi41_stop_chan(struct dma_chan *chan) 
		struct cppi41_channel *cc, *_ct;



		/*

		 * channels might still be in the pendling list if

		 * channels might still be in the pending list if

		 * cppi41_dma_issue_pending() is called after

		 * cppi41_runtime_suspend() is called

		 */

drivers/dma/ti/edma.c

+5 −5
Original line number Diff line number Diff line
@@ -976,7 +976,7 @@ static int edma_config_pset(struct dma_chan *chan, struct edma_pset *epset, 
		 * and quotient respectively of the division of:

		 * (dma_length / acnt) by (SZ_64K -1). This is so

		 * that in case bcnt over flows, we have ccnt to use.

		 * Note: In A-sync tranfer only, bcntrld is used, but it

		 * Note: In A-sync transfer only, bcntrld is used, but it

		 * only applies for sg_dma_len(sg) >= SZ_64K.

		 * In this case, the best way adopted is- bccnt for the

		 * first frame will be the remainder below. Then for
@@ -1203,7 +1203,7 @@ static struct dma_async_tx_descriptor *edma_prep_dma_memcpy( 
		 * slot2: the remaining amount of data after slot1.

		 *	  ACNT = full_length - length1, length2 = ACNT

		 *

		 * When the full_length is multibple of 32767 one slot can be

		 * When the full_length is a multiple of 32767 one slot can be

		 * used to complete the transfer.

		 */

		width = array_size;
@@ -1814,7 +1814,7 @@ static void edma_issue_pending(struct dma_chan *chan) 
 * This limit exists to avoid a possible infinite loop when waiting for proof

 * that a particular transfer is completed. This limit can be hit if there

 * are large bursts to/from slow devices or the CPU is never able to catch

 * the DMA hardware idle. On an AM335x transfering 48 bytes from the UART

 * the DMA hardware idle. On an AM335x transferring 48 bytes from the UART

 * RX-FIFO, as many as 55 loops have been seen.

 */

#define EDMA_MAX_TR_WAIT_LOOPS 1000

drivers/dma/ti/omap-dma.c

+1 −1
Original line number Diff line number Diff line
@@ -1442,7 +1442,7 @@ static int omap_dma_pause(struct dma_chan *chan) 
	 * A source-synchronised channel is one where the fetching of data is

	 * under control of the device. In other words, a device-to-memory

	 * transfer. So, a destination-synchronised channel (which would be a

	 * memory-to-device transfer) undergoes an abort if the the CCR_ENABLE

	 * memory-to-device transfer) undergoes an abort if the CCR_ENABLE

	 * bit is cleared.

	 * From 16.1.4.20.4.6.2 Abort: "If an abort trigger occurs, the channel

	 * aborts immediately after completion of current read/write