lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e9e822da-1cb9-b510-7639-43407fda8321@nvidia.com>
Date:   Tue, 25 Jun 2019 08:27:21 +0530
From:   Sameer Pujar <spujar@...dia.com>
To:     Vinod Koul <vkoul@...nel.org>
CC:     <dan.j.williams@...el.com>, <tiwai@...e.com>,
        <jonathanh@...dia.com>, <dmaengine@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <sharadg@...dia.com>,
        <rlokhande@...dia.com>, <dramesh@...dia.com>, <mkumard@...dia.com>
Subject: Re: [PATCH] [RFC] dmaengine: add fifo_size member


On 6/24/2019 11:56 AM, Vinod Koul wrote:
> On 20-06-19, 15:59, Sameer Pujar wrote:
>
>>>>> So can you explain me what is the difference here that the peripheral
>>>>> cannot configure and use burst size with passing fifo depth?
>>>> Say for example FIFO_THRESHOLD is programmed as 16 WORDS, BURST_SIZE as 8
>>>> WORDS.
>>>> ADMAIF does not push data to AHUB(operation [2]) till threshold of 16 WORDS
>>>> is
>>>> reached in ADMAIF FIFO. Hence 2 burst transfers are needed to reach the
>>>> threshold.
>>>> As mentioned earlier, threshold here is to just indicate when data transfer
>>>> can happen
>>>> to AHUB modules.
>>> So we have ADMA and AHUB and peripheral. You are talking to AHUB and that
>>> is _not_ peripheral and if I have guess right the fifo depth is for AHUB
>>> right?
>> Yes the communication is between ADMA and AHUB. ADMAIF is the interface
>> between
>> ADMA and AHUB. ADMA channel sending data to AHUB pairs with ADMAIF TX
>> channel.
>> Similary ADMA channel receiving data from AHUB pairs with ADMAIF RX channel.
>> FIFO DEPTH we are talking is about each ADMAIF TX/RX channel and it is
>> configurable.
>> DMA transfers happen to/from ADMAIF FIFOs and whenever data(per WORD) is
>> popped/pushed
>> out of ADMAIF to/from AHUB, asseration is made to ADMA. ADMA keeps counters
>> based on
>> these assertions. By knowing FIFO DEPTH and these counters, ADMA knows when
>> to wait or
>> when to transfer data.
> Where does ADMAIF driver reside in kernel, who configures it for normal
> dma txns..?
Not yet, we are in the process of upstreaming ADMAIF driver.
To describe briefly, audio subsystem is using ALSA SoC(ASoC) layer. 
ADMAIF is
registered as platform driver and exports DMA functionality. It 
registers PCM
devices for each Rx/Tx ADMAIF channel. During PCM playback/capture 
operations,
ALSA callbacks configure DMA channel using API dmaengine_slave_config().
RFC patch proposed, is to help populate FIFO_SIZE value as well during above
call, since ADMA requires it.
>
> Also it wold have helped the long discussion if that part was made clear
> rather than talking about peripheral all this time :(
Thought it was clear, though should have avoided using 'peripheral' in the
discussions. Sorry for the confusion.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ