ep93xx SPI driver v3

ep93xx SPI driver v3

[Martin Guy]

cc-ing to list...

> Next thing (after possible bug fixes, that is) is probably to
> implement proper DMA support. Unfortunately there is no platform
> code for that yet, only M2P controller support :( which means that
>  we have to implement M2M controller support

Yes, ep93xx DMA engine has two flavours: memory-to-peripheral, used
for most devices, and memory-to-memory, used for block memcpy and for
memory-to-SSP/SPI (== SD card).

The easiest route would seem to be to get the M2M stuff working to do
memcpy fast. Can linux make use of that? I haven't yet seen anything
that can make use of a memory-to-memory copy DMA engine.

If we can get that working, a reasonable second stage would make it
work for ep93xx-SPI transfers, making SD card access even less
CPU-intensive

   M

ep93xx SPI driver v3

[Mika Westerberg]

On Sat, Apr 17, 2010 at 04:23:53AM +0100, Martin Guy wrote:
> Yes, ep93xx DMA engine has two flavours: memory-to-peripheral, used
> for most devices, and memory-to-memory, used for block memcpy and for
> memory-to-SSP/SPI (== SD card).
>
> The easiest route would seem to be to get the M2M stuff working to do
> memcpy fast. Can linux make use of that? I haven't yet seen anything
> that can make use of a memory-to-memory copy DMA engine.

I think that the M2M engine can also perform M2P transfers for
SSPRX, SSPTX, and IDE in addition to memory-to-memory transfers.

There already is dma-m2p support and I guess that it can be extended
to support M2M controller for IDE and SPI.

> If we can get that working, a reasonable second stage would make it
> work for ep93xx-SPI transfers, making SD card access even less
> CPU-intensive

Yes.

MW

ep93xx SPI driver v3

[Ryan Mallon]

Martin Guy wrote:
> cc-ing to list...
> 
>> Next thing (after possible bug fixes, that is) is probably to
>> implement proper DMA support. Unfortunately there is no platform
>> code for that yet, only M2P controller support :( which means that
>>  we have to implement M2M controller support
> 
> Yes, ep93xx DMA engine has two flavours: memory-to-peripheral, used
> for most devices, and memory-to-memory, used for block memcpy and for
> memory-to-SSP/SPI (== SD card).
> 
> The easiest route would seem to be to get the M2M stuff working to do
> memcpy fast. Can linux make use of that? I haven't yet seen anything
> that can make use of a memory-to-memory copy DMA engine.

There is support for the M2P DMA (see arch/arm/mach-ep93xx/dma-m2p.c),
which could be used as a guide. There is also dmaengine, which I don't
know much about, but could possibly be implemented for the ep93xx DMA
channels. I think dmaengine supports asynchronous memcpy.

> If we can get that working, a reasonable second stage would make it
> work for ep93xx-SPI transfers, making SD card access even less
> CPU-intensive

Sine the M2M DMA support for the ep93xx is not in the mainline yet, I
would be happy for the SPI driver to be merged without DMA support, and
to have it added at a later date.

~Ryan

-- 
Bluewater Systems Ltd - ARM Technology Solution Centre

Ryan Mallon         		5 Amuri Park, 404 Barbadoes St
ryan at bluewatersys.com         	PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com	New Zealand
Phone: +64 3 3779127		Freecall: Australia 1800 148 751
Fax:   +64 3 3779135			  USA 1800 261 2934

ep93xx SPI driver v3

[Mika Westerberg]

On Mon, Apr 19, 2010 at 08:53:28AM +1200, Ryan Mallon wrote:
> Martin Guy wrote:
> > If we can get that working, a reasonable second stage would make it
> > work for ep93xx-SPI transfers, making SD card access even less
> > CPU-intensive
> 
> Sine the M2M DMA support for the ep93xx is not in the mainline yet, I
> would be happy for the SPI driver to be merged without DMA support, and
> to have it added at a later date.

Yeah. This discussion actually referred to future improvements. We
can implement DMA support later on.

BTW: do you guys think that there is any real use of polling mode
in the driver or should I drop it out completely? I mean, if we are
going to add proper timeout / error reporting for polling, it makes
the driver more complex.

Thanks,
MW

ep93xx SPI driver v3

[Martin Guy]

On 4/19/10, Mika Westerberg <mika.westerberg@iki.fi> wrote:
>  BTW: do you guys think that there is any real use of polling mode
>  in the driver or should I drop it out completely?

Is there any advantage to it in terms of transfer speed or CPU efficiency?

   M

ep93xx SPI driver v3

[Mika Westerberg]

On Mon, Apr 19, 2010 at 10:25:03AM +0100, Martin Guy wrote:
> On 4/19/10, Mika Westerberg <mika.westerberg@iki.fi> wrote:
> >  BTW: do you guys think that there is any real use of polling mode
> >  in the driver or should I drop it out completely?
> 
> Is there any advantage to it in terms of transfer speed or CPU efficiency?

I guess no. At least for CPU efficiency.

Original motivation for implementing it was to let users choose which method they prefer
but now I have second thoughts about that since interrupt mode seems to perform OK and
I don't see any advantage of using polling here.

Thanks,
MW

ep93xx SPI driver v3

[Ryan Mallon]

Mika Westerberg wrote:
> On Mon, Apr 19, 2010 at 08:53:28AM +1200, Ryan Mallon wrote:
>> Martin Guy wrote:
>>> If we can get that working, a reasonable second stage would make it
>>> work for ep93xx-SPI transfers, making SD card access even less
>>> CPU-intensive
>> Sine the M2M DMA support for the ep93xx is not in the mainline yet, I
>> would be happy for the SPI driver to be merged without DMA support, and
>> to have it added at a later date.
> 
> Yeah. This discussion actually referred to future improvements. We
> can implement DMA support later on.
> 
> BTW: do you guys think that there is any real use of polling mode
> in the driver or should I drop it out completely? I mean, if we are
> going to add proper timeout / error reporting for polling, it makes
> the driver more complex.

I recall not being able to get interrupt mode working in the driver the
Hartley and I worked on. I can't remember if this was a limitation of
our hardware, or just bugs in the interrupt code. I'll try and find some
time today to test the driver out.

~Ryan