On Wed, 2015-06-17 at 17:35 +0100, Mark Brown wrote: > On Wed, Jun 17, 2015 at 10:10:51PM +0800, Eddie Huang wrote: > > > Our hardware limitation is: we don't have separate dma tx, rx channel > > with transfer finish interrupt, only have spi trigger operation.So the > > mediatek SPI dma full duplex operation steps are: > > 1. Set TX DMA address. > > 2. Set RX DMA address. > > 3. Set length (this step assume TX, RX are the same size). > > 4. Set TX DMA enable, RX DMA enable bit in spi config register. (not > > trigger DMA, just told spi use dma) > > 5. Trigger spi operations. > > 6. Wait spi operations finish interrupt. > > Sure, that's what I understood. > > > If tx scatterlist per list data size are 128, 4096, 256. rx scatterlist > > per list data size are 128, 4096, 256. So we need to go through above > > steps three times. If tx scatterlists per list data size are 128, 4096, > > 256. rx scatterlists per list data size are 256, 4096, 128. If we start > > sending first entry, tx size is 128, rx size is 256, this will cause > > hardware malfunction because tx, rx data length are not the same. > > > The solution I think is copy scatterlist data into one single buffer in > > mediatek spi transfer function, but I think this is odd because > > __spi_map_msg() map single buffer into scatterlist, then our driver map > > scatterlist into single buffer again. I hope this explaination is more > > clear than before. > > To repeat what I said in my last mail: there's no need to use the > scatterlists as-is, your driver can do whatever set of DMA transfers it > likes to keep the lengths of each transfer the same. Attempting to > linearise the transfers in memory isn't going to work unless you > allocate physically contiguous memory (which could get painful) and will > add substantial overhead. > > For example with your above example you could split the transfers up to > be 128, 128, 3968, 128, 128. This is a workable way. Thanks your suggestion.We will try to implement this, Eddie Thanks -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
