linux-kernel - Re: [PATCH] [RFC] dmaengine: add fifo

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: <e852d576-9cc2-ed42-1a1a-d696112c88bf@nvidia.com>
Date:   Thu, 2 May 2019 16:23:14 +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>
Subject: Re: [PATCH] [RFC] dmaengine: add fifo_size member


On 5/2/2019 11:34 AM, Vinod Koul wrote:
> On 30-04-19, 17:00, Sameer Pujar wrote:
>> During the DMA transfers from memory to I/O, it was observed that transfers
>> were inconsistent and resulted in glitches for audio playback. It happened
>> because fifo size on DMA did not match with slave channel configuration.
>>
>> currently 'dma_slave_config' structure does not have a field for fifo size.
>> Hence the platform pcm driver cannot pass the fifo size as a slave_config.
>> Note that 'snd_dmaengine_dai_dma_data' structure has fifo_size field which
>> cannot be used to pass the size info. This patch introduces fifo_size field
>> and the same can be populated on slave side. Users can set required size
>> for slave peripheral (multiple channels can be independently running with
>> different fifo sizes) and the corresponding sizes are programmed through
>> dma_slave_config on DMA side.
> FIFO size is a hardware property not sure why you would want an
> interface to program that?
>
> On mismatch, I guess you need to take care of src/dst_maxburst..
Yes, FIFO size is a HW property. But it is SW configurable(atleast in my 
case) on
slave side and can be set to different sizes. The src/dst_maxburst is 
programmed
for specific values, I think this depends on few factors related to 
bandwidth
needs of client, DMA needs of the system etc.,
In such cases how does DMA know the actual FIFO depth of slave peripheral?
>> Request for feedback/suggestions.
>>
>> Signed-off-by: Sameer Pujar <spujar@...dia.com>
>> ---
>>   include/linux/dmaengine.h | 3 +++
>>   1 file changed, 3 insertions(+)
>>
>> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
>> index d49ec5c..9ec198b 100644
>> --- a/include/linux/dmaengine.h
>> +++ b/include/linux/dmaengine.h
>> @@ -351,6 +351,8 @@ enum dma_slave_buswidth {
>>    * @slave_id: Slave requester id. Only valid for slave channels. The dma
>>    * slave peripheral will have unique id as dma requester which need to be
>>    * pass as slave config.
>> + * @fifo_size: Fifo size value. The dma slave peripheral can configure required
>> + * fifo size and the same needs to be passed as slave config.
>>    *
>>    * This struct is passed in as configuration data to a DMA engine
>>    * in order to set up a certain channel for DMA transport at runtime.
>> @@ -376,6 +378,7 @@ struct dma_slave_config {
>>   	u32 dst_port_window_size;
>>   	bool device_fc;
>>   	unsigned int slave_id;
>> +	u32 fifo_size;
>>   };
>>   
>>   /**
>> -- 
>> 2.7.4