On Tue, Jun 30, 2015 at 02:36:57PM +0200, Cyrille Pitchen wrote: > This patch adds the missing update of the transfer data width in > at_xdmac_prep_slave_sg(). > > Indeed, for each item in the scatter-gather list, we check whether the > transfer length is aligned with the data width provided by > dmaengine_slave_config(). If so, we directly use this data width for the > current part of the transfer we are preparing. Otherwise, the data width > is reduced to 8 bits (1 byte). Of course, the actual number of register > accesses must also be updated to match the new data width. > > So one chunk was missing in the original patch (see Fixes tag below): the > number of register accesses was correctly set to (len >> fixed_dwidth) in > mbr_ubc but the real data width was not updated in mbr_cfg. Since mbr_cfg > may change for each part of the scatter-gather transfer this also explains > why the original patch used the Descriptor View 2 instead of the > Descriptor View 1. > > Let's take the example of a DMA transfer to write 8bit data into an Atmel > USART with FIFOs. When FIFOs are enabled in the USART, its Transmit > Holding Register (THR) works in multidata mode, that is to say that up to > 4 8bit data can be written into the THR in a single 32bit access and it is > still possible to write only one data with a 8bit access. To take > advantage of this new feature, the DMA driver was modified to allow > multiple dwidths when doing slave transfers. > For instance, when the total length is 22 bytes, the USART driver splits > the transfer into 2 parts: > > First part: 20 bytes transferred through 5 32bit writes into THR > Second part: 2 bytes transferred though 2 8bit writes into THR > > For the second part, the data width was first set to 4_BYTES by the USART > driver thanks to dmaengine_slave_config() then at_xdmac_prep_slave_sg() > reduces this data width to 1_BYTE because the 2 byte length is not aligned > with the original 4_BYTES data width. Since the data width is modified, > the actual number of writes into THR must be set accordingly. Applied thanks -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
