Message-ID: <0d27301c-a9b1-4189-37b8-d7d07160ff25@linutronix.de>
Date:   Mon, 19 Dec 2016 11:54:10 +0100
From:   Holger Dengler <dengler@...utronix.de>
To:     Vinod Koul <vinod.koul@...el.com>
Cc:     Lee Jones <lee.jones@...aro.org>, Arnd Bergmann <arnd@...db.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org, dmaengine@...r.kernel.org,
        Thomas Gleixner <tglx@...utronix.de>,
        Sebastian Siewior <bigeasy@...utronix.de>,
        Juergen Bubeck <bubeck@...ug.com>,
        Peter Mahler <mahler@...ug.com>,
        Benedikt Spranger <b.spranger@...utronix.de>
Subject: Re: [PATCH 12/12] dma: Flexcard DMA ringbuffer demux driver

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


Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)

Powered by blists - more mailing lists