On 12/15/2016 05:38 AM, Vinod Koul wrote:
> On Wed, Dec 14, 2016 at 01:11:53AM +0100, Holger Dengler wrote:
>> The Flexcard interface design split packet receive and transmit. All
>> received packets and card status information are multiplexed with a
>> Flexcard specific protocol and handled through a DMA capable ringbuffer.
>> The TX path has to poke each available component separate.
>>
>> Add a Flexcard DMA ringbuffer driver and packet demultiplexer.
> 
> so the dma driver should only provide service and not do demuxing...

The Flexcard can be equipped with multiple functional modules (so called 
Tinys). Unfortunately, the RX traffic of all Tinys is handled by the base card 
in a single DMA-ringbuffer. No separate channels, no scatter-gather-lists. So 
RX-demuxing must be done by one single instance per base card. The TX-path is 
_not_ handled via DMA, the data goes directly to the Tiny registers.

>> +#define FLEXCARD_DMA_STAT_BUSY              (1 << 15)
>> +#define FLEXCARD_DMA_STAT_OFL               (1 << 31)
>> +
>> +#define FLEXCARD_MAX_PAKET_SIZE             0x200
>> +
>> +#define FLEXCARD_BUF_HEADER_LEN_SHIFT       15
>> +#define FLEXCARD_BUF_HEADER_LEN_MASK        0xfe
>> +
>> +#define FLEXCARD_CANIF_OFFSET               0x20
> 
> Okay I have skipped over the parser and other stuff and still looking for
> the dmaengine APIs. 
> 
> This driver _doesn't_ do that, and am not sure why.

The main reason, why we do not used the dmaengine interfaces, is, that the 
Flexcard DMA engine is not as flexible as normal DMA engines are. It is only 
used for the receive path, it does not support separate channels per Tiny and 
it uses a single ring-buffer instead of scatter-gather-lists. If we would use 
the dmaengine interfaces, we would end up with a solution, that accepts only 
one client per card, and the client must always be the parser (because of the 
demuxing). Therefore, I do not see any advantage in using the dmaengine 
interfaces.

> Anyway, if this driver doesnt need dmaengine APIs it doesnt belong in
> drivers/dma/. Otherwise please port to dmanegine APIs, possibly use parser
> as a client. You cna use virt-channels as well for managing the transfers.

Ok, I can follow your argumentation, that the driver for the Flexcard "DMA" 
does not belong to drivers/dma. In our second post [1], we had it in 
drivers/mfd, but Lee mentioned, that it is not a mfd driver and asked us to 
move it to drivers/dma [2]. But if it is neither a mfd nor a dmaengine driver, 
what kind of driver is it? What is the right place for this driver? (Maybe the 
naming of the driver is too confusing. Although the Flexcard use DMA (from a 
technically point of view), this function is more a RX-demux-engine...)

@Lee: 
with Vinods comments, the information above and (optionally) a renaming, do you 
see any possibility to re-include it in drivers/mfd?

[1] http://www.spinics.net/lists/kernel/msg1954282.html
[2] http://www.spinics.net/lists/kernel/msg1957525.html

> 
> So I am not considering this submission
> 
> Thanks
> 
-- 
Gruß,
Holger Dengler
--
phone: +49 7556 25 999 14; fax: +49 7556 25 999 99

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to