invert tx and rx in spi_dma_setup

[bertvoldenuit]

Summary

According to SAMD21 Errata:

1.7.2 Linked Descriptor

When at least one channel using linked descriptors is already active, enabling another DMA channel (with or without
linked descriptors) can result in a channel Fetch Error (FERR) or an incorrect descriptor fetch.
This occurs if the channel number of the channel being enabled is lower than the channel already active.

Workaround

When enabling a DMA channel while other channels using linked descriptors are already active, the channel number
of the new channel enabled must be greater than the other channel numbers.`

In the spi driver, in the description and in the code it is always Tx and then Rx except in one place where it is Rx and then Tx which could lead in the FERR according to Errata

I think it would be better to swap Rx/Tx in the following code:

static void spi_dma_setup(struct sam_spidev_s *priv)
{
  /* Allocate a pair of DMA channels */

    priv->dma_rx = sam_dmachannel(DMACH_FLAG_BEATSIZE_BYTE |
                                                           DMACH_FLAG_MEM_INCREMENT |
                                                           DMACH_FLAG_PERIPH_RXTRIG(priv->dma_rx_trig)); 
    priv->dma_tx = sam_dmachannel(DMACH_FLAG_BEATSIZE_BYTE |
                                                           DMACH_FLAG_MEM_INCREMENT |
                                                           DMACH_FLAG_PERIPH_TXTRIG(priv->dma_tx_trig));
                               
}

into

static void spi_dma_setup(struct sam_spidev_s *priv)
{
  /* Allocate a pair of DMA channels */

  priv->dma_tx = sam_dmachannel(DMACH_FLAG_BEATSIZE_BYTE |
                                                        DMACH_FLAG_MEM_INCREMENT |
                                                        DMACH_FLAG_PERIPH_TXTRIG(priv->dma_tx_trig));

  priv->dma_rx = sam_dmachannel(DMACH_FLAG_BEATSIZE_BYTE |
                                                         DMACH_FLAG_MEM_INCREMENT |
                                                         DMACH_FLAG_PERIPH_RXTRIG(priv->dma_rx_trig));                                
}

Impact

In my case (driving led strip ws2812), I still get an error TERR on the Rx channel. It has no particular impact but it makes more sense and should avoid potential FERR according to errata.

Testing

Compiles and runs

[xiaoxiang781216]

but, let's sqaush into one patch, @bertvoldenuit .

[pkarashchenko]

Please squash, so we can merge

[bertvoldenuit]

Done!
Sorry for the delay, I am not familiar with squashing. I hope I did it good!

[xiaoxiang781216]

let's ignore the new gcc report warning:

bas_token.l: In function 'yylex':
Error: bas_token.l:[121](https://github.com/apache/nuttx/actions/runs/7145281334/job/19460719816?pr=11307#step:7:122)0:31: error: 'strcpy' writing 1 or more bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=]
 1210 |                             }
      |                               ^                                  
In file included from bas_auto.h:77,
                 from bas_token.l:16:
bas_token.h:103:8: note: at offset 2 into destination object 'name' of size 2
  103 |   char name[2/* ... */];
      |        ^~~~

I will fix it soon.