Re: edma: "3-byte" transfers and masked writes in general

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 10/03/16 11:27, Matthijs van Duin wrote:
> On 3 October 2016 at 10:00, Peter Ujfalusi <peter.ujfalusi@xxxxxx> wrote:
>> On 10/03/16 09:37, Matthijs van Duin wrote:
>>> I recently noticed the curious definition DMA_SLAVE_BUSWIDTH_3_BYTES
>>> and EDMA's supposed support thereof. While I appreciate it might just
>>> be a convenient hack to support dma for packed 24-bit audio, I feel it
>>> can use some clarification (and warning).
>>>
>>> EDMA does not really support 3-byte transfers.
>>
>> In A-Synchronized transfer the eDMA will transfer ACNT number of bytes in
>> response to a DMA request. ACNT valid values are 1 to 65535, including 3, 21, etc.
>>
>> Also there are not alignment restrictions from eDMA to SRC or DST address. The
>> only exception is SAM/DAM in constant addressing mode where the SRC/DST should
>> be 256bit aligned.
> 
> None of this contradicts what I said. It isn't hard to verify that it
> implicitly performs larger aligned transfers, this shows up in various
> situations such as the examples I gave. It also shows up in the L3
> interconnect error log when a read or write hits a disabled target or
> address hole.
> 
> For another example, I created a 16-byte aligned buffer containing:
> 10 11 12 13  14 15 16 17  18 19 1A 1B  1C 1D 1E 1F
> 
> I then did an edma transfer with ACNT=3 from this buffer to an
> FF-filled ethernet dma descriptor, then dumped the descriptor:
> 10 11 12 13  FF FF FF FF  FF FF FF FF  FF FF FF FF
> 
> This shows unambiguously that edma transferred 4 bytes, even though it
> will have requested to mask byte 3 of the 4-byte write (a request
> ignored by the ethernet dma descriptor memory).

What happens if you set ACNT to 2?
You are right, instead of 3 bytes the destination got 4 bytes changed.

>> As far as I can see the eDMA itself does not have alignment restrictions, but
>> the peripheral might have.
> 
> The peripheral is on a 32-bit bus and is not the source of alignment
> restrictions more stringent than 32-bit. The problem is that violating
> edma's alignment

There is no alignment restriction in eDMA. There might be restriction on the
L3/L4 boundary for the ethernet, it is clearly not behaving in a way how it
supposed to behave.
The eDMA itself can handle 3 byte transfer, it is another story that how well
that works with selected peripherals.

> causes it to use masked writes, but this peripheral
> ignores the mask and exposes the aligned 16-byte write that edma
> actually performed.

How did you set up the DMA to do this? Can you paste the relevant code
snippets which does the request of the DMA channel, set up for the transfer, etc?

-- 
Péter
--
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



[Index of Archives]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux PCI]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux