Linux kernel mirror (for testing) git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel os linux

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: Tom Rix <trix@redhat.com>
Acked-by: Peter Ujfalusi <peter.ujfalusi@gmail.com>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://lore.kernel.org/r/20220217182546.3266909-1-trix@redhat.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>

authored by

Tom Rix and committed by
Vinod Koul
2ed4ba94 fb7a444a

+9 -9
+3 -3
drivers/dma/ti/cppi41.c
··· 315 315 val = cppi_readl(cdd->qmgr_mem + QMGR_PEND(i)); 316 316 if (i == QMGR_PENDING_SLOT_Q(first_completion_queue) && val) { 317 317 u32 mask; 318 - /* set corresponding bit for completetion Q 93 */ 318 + /* set corresponding bit for completion Q 93 */ 319 319 mask = 1 << QMGR_PENDING_BIT_Q(first_completion_queue); 320 320 /* not set all bits for queues less than Q 93 */ 321 321 mask--; ··· 703 703 * transfer descriptor followed by TD descriptor. Waiting seems not to 704 704 * cause any difference. 705 705 * RX seems to be thrown out right away. However once the TearDown 706 - * descriptor gets through we are done. If we have seens the transfer 706 + * descriptor gets through we are done. If we have seen the transfer 707 707 * descriptor before the TD we fetch it from enqueue, it has to be 708 708 * there waiting for us. 709 709 */ ··· 747 747 struct cppi41_channel *cc, *_ct; 748 748 749 749 /* 750 - * channels might still be in the pendling list if 750 + * channels might still be in the pending list if 751 751 * cppi41_dma_issue_pending() is called after 752 752 * cppi41_runtime_suspend() is called 753 753 */
+5 -5
drivers/dma/ti/edma.c
··· 118 118 119 119 /* 120 120 * Max of 20 segments per channel to conserve PaRAM slots 121 - * Also note that MAX_NR_SG should be atleast the no.of periods 121 + * Also note that MAX_NR_SG should be at least the no.of periods 122 122 * that are required for ASoC, otherwise DMA prep calls will 123 123 * fail. Today davinci-pcm is the only user of this driver and 124 - * requires atleast 17 slots, so we setup the default to 20. 124 + * requires at least 17 slots, so we setup the default to 20. 125 125 */ 126 126 #define MAX_NR_SG 20 127 127 #define EDMA_MAX_SLOTS MAX_NR_SG ··· 976 976 * and quotient respectively of the division of: 977 977 * (dma_length / acnt) by (SZ_64K -1). This is so 978 978 * that in case bcnt over flows, we have ccnt to use. 979 - * Note: In A-sync tranfer only, bcntrld is used, but it 979 + * Note: In A-sync transfer only, bcntrld is used, but it 980 980 * only applies for sg_dma_len(sg) >= SZ_64K. 981 981 * In this case, the best way adopted is- bccnt for the 982 982 * first frame will be the remainder below. Then for ··· 1203 1203 * slot2: the remaining amount of data after slot1. 1204 1204 * ACNT = full_length - length1, length2 = ACNT 1205 1205 * 1206 - * When the full_length is multibple of 32767 one slot can be 1206 + * When the full_length is a multiple of 32767 one slot can be 1207 1207 * used to complete the transfer. 1208 1208 */ 1209 1209 width = array_size; ··· 1814 1814 * This limit exists to avoid a possible infinite loop when waiting for proof 1815 1815 * that a particular transfer is completed. This limit can be hit if there 1816 1816 * are large bursts to/from slow devices or the CPU is never able to catch 1817 - * the DMA hardware idle. On an AM335x transfering 48 bytes from the UART 1817 + * the DMA hardware idle. On an AM335x transferring 48 bytes from the UART 1818 1818 * RX-FIFO, as many as 55 loops have been seen. 1819 1819 */ 1820 1820 #define EDMA_MAX_TR_WAIT_LOOPS 1000
+1 -1
drivers/dma/ti/omap-dma.c
··· 1442 1442 * A source-synchronised channel is one where the fetching of data is 1443 1443 * under control of the device. In other words, a device-to-memory 1444 1444 * transfer. So, a destination-synchronised channel (which would be a 1445 - * memory-to-device transfer) undergoes an abort if the the CCR_ENABLE 1445 + * memory-to-device transfer) undergoes an abort if the CCR_ENABLE 1446 1446 * bit is cleared. 1447 1447 * From 16.1.4.20.4.6.2 Abort: "If an abort trigger occurs, the channel 1448 1448 * aborts immediately after completion of current read/write