Date: Fri, 10 Jul 2015 13:38:05 +0530
From: Vinod Koul <vinod.koul@intel.com>
To: Cyrille Pitchen <cyrille.pitchen@atmel.com>
Cc: nicolas.ferre@atmel.com, ludovic.desroches@atmel.com,
        dan.j.williams@intel.com, dmaengine@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/1] dmaengine: at_xdmac: fix transfer data width in
 at_xdmac_prep_slave_sg()
Message-ID: <20150710080805.GE836@localhost>
References: <32f90f9820ddf6412a637cdf3fda4e284a7854d1.1435667600.git.cyrille.pitchen@atmel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <32f90f9820ddf6412a637cdf3fda4e284a7854d1.1435667600.git.cyrille.pitchen@atmel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2346
Lines: 46

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 linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/