SPI, DMA and an i.MX31

SPI, DMA and an i.MX31

[Wolf, Rene, HRO-GP]

Hello everyone!

First of all this is my first post to this mailing list and I hope
I'm not screwing it :-).
I'm using the qong board from denx.de and their kernel in version
2.6.31 (should be equal to kernel.org). So, this is about the freescale
i.MX31 (ARM11), its SPI and (S)DMA. The goal is to do DMA-transfer
between the SPI and some buffer in memory. I'm quite new to drivers
under Linux, so I first tried to find out how DMA works here.

By this point I already worked with traditional MCU-DMAs, programing
them by hand with no OS (did so on an STM32 ARM Cortex-m3).
That would work something like that (for transmitting data
over SPI):
- get some buffer, fill in data.
- Tell SPI that it's going to be DMAed
- Tell DMA to communicate with SPI
- Tell DMA source pointer and set auto increment
- Tell DMA dest. (spi->tx) and set fixed
- Tell DMA count and length of word.
- Start transfer.

Now from books like "Essential Linux Device Drivers" and
"Linux Device Drivers" + "/usr/src/linux/Documentation/DMA-API.txt"
+ an example (/u/s/l/drivers/spi/atmel_spi.c) I got the following
idea how this might work under Linux (all those 'spi->cfg' are
figuratively :-)
- Get some buffer (buf=kmalloc or so...), fill in data
- Register buffer with system ( dma_map_single() )
- Tell SPI that it's going to be DMAed ( writel(spi->cfg, flags) )
- Tell DMA to communicate with SPI ( writel(dma->cfg, flags) )
- Tell DMA source pointer (+ autoinc.) ( writel(dma->src, &buf) )
- Tell DMA dest. (+ fixed) ( writel(dma->dest, &(spi->buf)) )
- Tell DMA count and length of words. (...)
- Start transfer. (...)

Am I right so far?

As far as I can tell this is mostly writing registers by hand,
there is no common API for setting stuff like src., dest., count,
device... is there? May be I missed, or didn't understand it.

Then I checked the (S)DMA that's inside the i.MX31 and how to do
the above. That SmartDMA is quite a nice piece of hardware: a
RISC processor with its own memory and it includes 32 threads
(DMA channels), scheduled by hardware. Pretty cool but that means
it has its own assembly language and needs some startup code ....

Looking around I found stuff like:
/u/s/l/arch/arm/plat-mxc/dma-mx1-mx2.c
though nothing for i.MX31. But then there is that:
http://osdir.com/ml/android-porting/2009-03/msg00251.html
http://lists.infradead.org/pipermail/linux-mtd/2009-May/025801.html
http://marc.info/?l=linux-arm-kernel&m=118003963232016&w=2
in those boot-msgs there is a line 'Using SDMA I.API'. At least
the 3rd one seams to be using LTIB.

So I guess there is no SDMA support for the i.MX31 and SPI unless
I switch to LTIB or do the SDMA-(errr...)-programing myself. Though
I would love to do the programing (I actually called freescale about
the SDMA API manual, cause they do not have it online), I don't have
time to do either of the two options. I would then resort to
interrupt-driven SPI for my task.


It would be nice if someone could give me a clue on my guess
about the basic concept for DMA+Linux. And if there really is no
SPI<->DMA support readily available for the i.MX31 (actually there
seems to be one for the IPU. There's a switch in the .config under:
'# DMA Devices' -> 'CONFIG_MX3_IPU=y' but as far as I recall the
i.MX31 manual this DMA serving the IPU is a different one.)

Any hints are welcome, even 'rtfm' :-) (coz then I know I
missed something)


Thanks a lot!

Cheers
Rene



Rene Wolf
LFK-Lenkflugk?rpersysteme GmbH
Human Resources Operations & Policy, HRO
Landshuter Stra?e 26, 85716 Unterschlei?heim, GERMANY
Phone: +49 89 3179 8337
Fax: +49 8252 99 8964
E-Mail: rene.wolf at mbda-systems.de

http://www.mbda.net

Chairman of the Supervisory Board: Antoine Bouvier
Managing Director: Werner Kaltenegger
Registered Office: Schrobenhausen
Commercial Register: Amtsgericht Ingolstadt, HRB 4365

SPI, DMA and an i.MX31

[Wolf, Rene, HRO-GP]

Hello Marc 

Thanks for your fast reply! 

> in the LTIB kernel sources, you'll find the sources for the freescale
> SDMA API(s) Under linux-2.6.22/arch/arm/plat-mxc/sdma/. Using the
> API is not complicated, you can look in sound/arm/mxc-alsa-pmic.c to
> see an exemple, basically you allocate a channel (mxc_dma_request),
> register a callback handler (mxc_dma_callback_set) and post requests
> (mxc_dma_config).

I did 'download' it (using the script provided by ltib and some manual
labor) -> kernel 2.6.22.6.
At the moment I use 2.6.31 and I'm planning on keeping it that way :-)
Do you think 'porting' that sdma-API would be difficult?

SPI, DMA and an i.MX31

[Magnus Lilja]

Hi Rene,

Wolf, Rene, HRO-GP wrote:
> Hello Marc 
> 
> Thanks for your fast reply! 
> 
>> in the LTIB kernel sources, you'll find the sources for the freescale
>> SDMA API(s) Under linux-2.6.22/arch/arm/plat-mxc/sdma/. Using the
>> API is not complicated, you can look in sound/arm/mxc-alsa-pmic.c to
>> see an exemple, basically you allocate a channel (mxc_dma_request),
>> register a callback handler (mxc_dma_callback_set) and post requests
>> (mxc_dma_config).
> 
> I did 'download' it (using the script provided by ltib and some manual
> labor) -> kernel 2.6.22.6.
> At the moment I use 2.6.31 and I'm planning on keeping it that way :-)

Freescale has released a BSP for i.MX31 based on kernel 2.6.26. Don't
know how much it differs in the DMA areas but it might be good to
check it out and use that as well as a base for your work on i.MX31-DMA
in 2.6.31. (freescale.com/imx31 => Software & Tools => i.MX31PDK => Downloads)

>> this information is regarding as confidential
> [...]
>> One will have to sign NDA agreement with Freescale.
> 
> I didn't get why they are doing it, but that might be the reason this
> api is not included in the mainline/denx kernel.

My guess is that it's probably best to use the DMA scripts that Freescale
released in their LTIB/BSP.

> Thanks again and I will have a closer look on porting that api :-)

It would be very nice to have i.MX31 DMA support in mainline, that would
perhaps also make it possible to have ALSA sound support for i.MX31.

Looking forward to testing this!


Regards, Magnus

SPI, DMA and an i.MX31

[Tonyliu]

Magnus Lilja wrote:
> Hi Rene,
>
> Wolf, Rene, HRO-GP wrote:
>   
>> Hello Marc 
>>
>> Thanks for your fast reply! 
>>
>>     
>>> in the LTIB kernel sources, you'll find the sources for the freescale
>>> SDMA API(s) Under linux-2.6.22/arch/arm/plat-mxc/sdma/. Using the
>>> API is not complicated, you can look in sound/arm/mxc-alsa-pmic.c to
>>> see an exemple, basically you allocate a channel (mxc_dma_request),
>>> register a callback handler (mxc_dma_callback_set) and post requests
>>> (mxc_dma_config).
>>>       
>> I did 'download' it (using the script provided by ltib and some manual
>> labor) -> kernel 2.6.22.6.
>> At the moment I use 2.6.31 and I'm planning on keeping it that way :-)
>>     
>
> Freescale has released a BSP for i.MX31 based on kernel 2.6.26. Don't
> know how much it differs in the DMA areas but it might be good to
> check it out and use that as well as a base for your work on i.MX31-DMA
> in 2.6.31. (freescale.com/imx31 => Software & Tools => i.MX31PDK => Downloads)
>
>   
>>> this information is regarding as confidential
>>>       
>> [...]
>>     
>>> One will have to sign NDA agreement with Freescale.
>>>       
>> I didn't get why they are doing it, but that might be the reason this
>> api is not included in the mainline/denx kernel.
>>     
>
> My guess is that it's probably best to use the DMA scripts that Freescale
> released in their LTIB/BSP.
>
>   
>> Thanks again and I will have a closer look on porting that api :-)
>>     
>
> It would be very nice to have i.MX31 DMA support in mainline, that would
> perhaps also make it possible to have ALSA sound support for i.MX31.
>   
AFAIK, it's not easy to support it in mainline as the sdma controller 
also need some binary firmware to work.
and there is no final stable release for the firmware, FSL drop that 
from time to time. I'm not sure whether
such type driver can be accepted by mainline.

Tony**


> Looking forward to testing this!
>
>
> Regards, Magnus
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>   


-- 
Tony Liu | Liu Bo
-------------------------------------------------------------
WIND RIVER | China Development Center
Tel: 86-10-8477-8542 ext: 8542 |  Fax: 86-10-64790367
(M): 86-136-7117-3612
Address: 15/F, Wangjing TowerB, Chaoyang District, Beijing, P.R.China

SPI, DMA and an i.MX31

[Wolf, Rene, HRO-GP]

Hi @ all!

Wow, there seams to be some interest in this :-)

> My guess is that it's probably best to use the DMA scripts that Freescale
> released in their LTIB/BSP.

So far I did search the LTIB src for reference on sdma. Then I copied
those files to 2.6.31. For files which existed in 2.6.31, I tried to
add the stuff referencing / using the sdma. Mostly that worked smoothly.
But there was heavy reorganization on the sources from LTIB to 2.6.31:
one example would be, in LTIB <asm/arch/hardware.h> =>
<mach/hardware.h>. That was an easy one, changing the #include fixed
the majority of those problems. But there is at least one which just
doesn't match any more: <asm/arch/dma.h>. There is an <asm/dma.h> in
2.6.31 but that is just the definition of the global interface. The
one from LTIB has an i.MX specific interface + some enums. I just did a
work around by adding the following to <asm/dma.h>:
#ifdef  CONFIG_ARCH_MX31
#include <mach/sdma_mx31.h>
#endif/*CONFIG_ARCH_MX31*/
As you prob. guessed the <mach/sdma_mx31.h> is the 'dma.h' from LTIB.

Another thing was the UART 1-5. The sdma was referenced in some INIT
routines. I sort of had the feeling that those would collide with the
interrupt driven UART my bsp uses at the moment, so I just commented
out 'uart+sdam' stuff (just in one src file, as far as I remember).

At the moment I'm just trying to get it to compile. If that works I
should somehow verify that the api is 'still' working (there are)
drivers that could be compiled to thest it, right :?)

> Freescale has released a BSP for i.MX31 based on kernel 2.6.26. Don't
> know how much it differs in the DMA areas but it might be good to
> check it out and use that as well as a base for your work on i.MX31-DMA
> in 2.6.31. (freescale.com/imx31 => Software & Tools => i.MX31PDK =>
> Downloads)

Jep. As far as I can remember I did check it and that was a binary only
release or I just overlooked the interesting stuff... I will have a
second look at it.

> It would be very nice to have i.MX31 DMA support in mainline, that would
> perhaps also make it possible to have ALSA sound support for i.MX31.

Hmm, would that be ok by the GPL and stuff. Coz the actual 'firmware'
is binary only, though it is packed as a 'short' array inside
'sdma_script_code.h' & 'sdma_script_code_pass2.h'?

> Looking forward to testing this!

Me too :-) and I hope that I'm getting there, coz I only got limited
time for that after which I must resort to interrupts...


Thanks for the nice discussion!

Cheers
Rene


Rene Wolf
LFK-Lenkflugk?rpersysteme GmbH
Human Resources Operations & Policy, HRO
Landshuter Stra?e 26, 85716 Unterschlei?heim, GERMANY
Phone: +49 89 3179 8337
Fax: +49 8252 99 8964
E-Mail: rene.wolf at mbda-systems.de

http://www.mbda.net

Chairman of the Supervisory Board: Antoine Bouvier
Managing Director: Werner Kaltenegger
Registered Office: Schrobenhausen
Commercial Register: Amtsgericht Ingolstadt, HRB 4365

SPI, DMA and an i.MX31

[Andy Green]

On 09/22/09 10:00, Somebody in the thread at some point said:

Hi Rene -

> Wow, there seems to be some interest in this :-)

Yes, I'm working on an iMX31 board at the moment and would love to see 
DMA at the platform level too.

> At the moment I'm just trying to get it to compile. If that works I
> should somehow verify that the api is 'still' working (there are)
> drivers that could be compiled to thest it, right :?)

Take a look at ./drivers/mmc/host/mxcmmc.c -->

#ifdef CONFIG_ARCH_MX2
#include <mach/dma-mx1-mx2.h>
#define HAS_DMA
#endif

If you jiggle that around to match your DMA patch, then you should be 
able to test the SD Card relatively straightforward since the same 
driver is tested with DMA on those platforms presumably.

-Andy

SPI, DMA and an i.MX31

[Wolf, Rene, HRO-GP]

> Good news everyone!
[Professor Hubert J. Farnsworth]

The kernel does compile. When I tried to run it the first time, it hung
right after the start. (Just after '...booting the kernel.'). Then I
set 'CONFIG_MXC_SDMA_API' to 'n' and recompiled: worked and was booting
correct (as far as I could see). I then checked the init routine from
'sdma.c' and after some try'n'error I got that it hung on enabling the
clocks for the sdma. After a quick look in arch/arm/mach-mx3/clock.c
@ line 475 - there is the entry for sdma_clk1:
DEFINE_CLOCK(sdma_clk1, 0, MXC_CCM_CGR0, 14, NULL, &sdma_clk1, &ahb_clk)
which references its self with '&sdma_clk1', thus it hung in a loop. I
guess this is a typo an should reference 'sdma_clk2' or 'NULL' not '1'.
After changing that my system booted smoothly. If I look in '/proc' there
is a dir called 'sdma', and inside there is a file 'channels':
$ cat channels
Channel 0: MCU

It seams to be alive :-)

> Take a look at ./drivers/mmc/host/mxcmmc.c

Next will try to test the mmc driver, but I don't have an MMC/SD slot on
my board. Hopefully there is some sign of an MMC in the channels
file or so.

Thanks again :-)


Cheers
Rene 

Ps: @ Marc Titinger: I think you are using HTML-Mail.
Afaik they won't show up on the mailing list :-)
-> check http://david.woodhou.se/email.html #7


Rene Wolf
LFK-Lenkflugk?rpersysteme GmbH
Human Resources Operations & Policy, HRO
Landshuter Stra?e 26, 85716 Unterschlei?heim, GERMANY
Phone: +49 89 3179 8337
Fax: +49 8252 99 8964
E-Mail: rene.wolf at mbda-systems.de

http://www.mbda.net

Chairman of the Supervisory Board: Antoine Bouvier
Managing Director: Werner Kaltenegger
Registered Office: Schrobenhausen
Commercial Register: Amtsgericht Ingolstadt, HRB 4365

SPI, DMA and an i.MX31

[Andy Green]

On 09/22/09 14:22, Somebody in the thread at some point said:

Hi Rene -

> After changing that my system booted smoothly. If I look in '/proc' there
> is a dir called 'sdma', and inside there is a file 'channels':
> $ cat channels
> Channel 0: MCU
>
> It seams to be alive :-)
>
>> Take a look at ./drivers/mmc/host/mxcmmc.c
>
> Next will try to test the mmc driver, but I don't have an MMC/SD slot on
> my board. Hopefully there is some sign of an MMC in the channels
> file or so.

Sounds encouraging... if you want to post or send a test patch if it 
gets to that point I'll try to give it a go on a real SD Card.

At the moment event/0 which owns the PIO to the SD card eats most of the 
CPU on a loaded system, this should be pretty revolutionary when it works.

-Andy

SPI, DMA and an i.MX31

[Magnus Lilja]

Hi

2009/9/22 Wolf, Rene, HRO-GP <rene.wolf@mbda-systems.de>:
> Hi @ all!
>
> Wow, there seams to be some interest in this :-)
>
>> Freescale has released a BSP for i.MX31 based on kernel 2.6.26. Don't
>> know how much it differs in the DMA areas but it might be good to
>> check it out and use that as well as a base for your work on i.MX31-DMA
>> in 2.6.31. (freescale.com/imx31 => Software & Tools => i.MX31PDK =>
>> Downloads)
>
> Jep. As far as I can remember I did check it and that was a binary only
> release or I just overlooked the interesting stuff... I will have a
> second look at it.

Depends on what you mean by "binary only", the source code for
Freescale's Linux is available in the BSP but no source for the SDMA
is included.

>
>> It would be very nice to have i.MX31 DMA support in mainline, that would
>> perhaps also make it possible to have ALSA sound support for i.MX31.
>
> Hmm, would that be ok by the GPL and stuff. Coz the actual 'firmware'
> is binary only, though it is packed as a 'short' array inside
> 'sdma_script_code.h' & 'sdma_script_code_pass2.h'?

That might be a problem. Binary firmware can be handled in Linux, as
an example one can load it from user space but that makes it difficult
to enable the SDMA before userspace has started. Another example is to
let the bootloader load the SDMA scripts but that's not a nice
solution. Don't know if this firmware can be accepted as a binary
within the kernel.

Perhaps there are other ways.

Regards, Magnus

SPI, DMA and an i.MX31

[Bill Gatliff]

Magnus Lilja wrote:
>
> That might be a problem. Binary firmware can be handled in Linux, as
> an example one can load it from user space but that makes it difficult
> to enable the SDMA before userspace has started. Another example is to
> let the bootloader load the SDMA scripts but that's not a nice
> solution. Don't know if this firmware can be accepted as a binary
> within the kernel.
>   

It couldn't be a "binary" in the kernel per se, it would be a constant
character array that gets compiled into a binary chunk.  Sort of like
how, for example, Keyspan's drivers are done.  See
linux/firmware/README.AddingFirmware, linux/firmware/keyspan and
drivers/usb/serial/keyspan*.


b.g.

-- 
Bill Gatliff
bgat at billgatliff.com

SPI, DMA and an i.MX31

[Magnus Lilja]

Hi Bill

2009/9/22 Bill Gatliff <bgat@billgatliff.com>:
> Magnus Lilja wrote:
>>
>> That might be a problem. Binary firmware can be handled in Linux, as
>> an example one can load it from user space but that makes it difficult
>> to enable the SDMA before userspace has started. Another example is to
>> let the bootloader load the SDMA scripts but that's not a nice
>> solution. Don't know if this firmware can be accepted as a binary
>> within the kernel.
>>
>
> It couldn't be a "binary" in the kernel per se, it would be a constant
> character array that gets compiled into a binary chunk.

Correct. That's the way Freescale has done it in their BSP, a char[]
array that eventually gets downloaded into the SDMA engine.

> ?Sort of like
> how, for example, Keyspan's drivers are done. ?See
> linux/firmware/README.AddingFirmware, linux/firmware/keyspan and
> drivers/usb/serial/keyspan*.

The README states that new firmware shall be added to Davids
linux-firmware tree, but that would mean that the DMA scripts would be
outside of the Linux source tree. Should one merge Davids
linux-firmware tree with the standard Linux-tree locally or how is it
supposed to work?

Thanks, Magnus

SPI, DMA and an i.MX31

[Wolf, Rene, HRO-GP]

Hi all.

Yesterday I was trying to reorganize the newly added sdma stuff. Up till
then it was just a dirty hack, now it got better structure. As I don't
know much on the organization of the kernel I cannot say if I did it the
right way. As a template I tried to match the structure of the dma driver
for the mx1/mx2 SoCs.

@Andy
The drivers/mmc/host/mxcmmc.c from 2.6.31 uses some different dma api: all
those fkt start with 'imx_', the sdma's from the ltib have a 'mxc' prefix.
I tried to match them and wrap those 'mxc' in defines, mapping them to the
'imx' ones. Unfortunately for some fkts I didn't find a matching 'mxc' one.
The driver compiles, but I guess it's pretty useless the way it is. May be
I should have looked to the driver version in ltib, instead.

After that I tried to register a SDMA channel with a device. As far as I
can see that works. The Registered channel shows under
'/proc/sdma/channels'. Freeing that also works.

Next: Will try to start a SDMA transfer with SPI.

ToDo: One with found knowledge about that should check if the new stuff
is placed correctly. Then there seams to be effort to define a global
DMA interface, for more than buffer allocation (at least for the i.MX
series). So the SDMA stuff should be made complaint with that (I guess
those 'imx' fkts are ones to go). Further there are structures that are
passed to some of the SDMA functions to set up a transfer for a device.
Those structures are incomplete. For my test I added one for CSPI3 TX in
8Bit mode. For all other cspi in all other modes, they are missing. There
should be some for 8/16/32 bit for cspi 1/2/3 in rx/tx direction.

@Bill and Magnus
Would it be ok if there was an assembler for the sdma, and the 'firmware'
could be in assembler? (I don't know how this would work, just curious :-)

Thanks again! Unfortunately by next Monday I'm out of time. Hopefully I
will be able to post the stuff I've done so far, on this list. Together
with an evaluation if the current port 'works' or not.


Cheers
Rene 



Rene Wolf
LFK-Lenkflugk?rpersysteme GmbH
Human Resources Operations & Policy, HRO
Landshuter Stra?e 26, 85716 Unterschlei?heim, GERMANY
Phone: +49 89 3179 8337
Fax: +49 8252 99 8964
E-Mail: rene.wolf at mbda-systems.de

http://www.mbda.net

Chairman of the Supervisory Board: Antoine Bouvier
Managing Director: Werner Kaltenegger
Registered Office: Schrobenhausen
Commercial Register: Amtsgericht Ingolstadt, HRB 4365

SPI, DMA and an i.MX31

[Andy Green]

On 09/24/09 11:51, Somebody in the thread at some point said:

Hi Rene -

> The drivers/mmc/host/mxcmmc.c from 2.6.31 uses some different dma api: all
> those fkt start with 'imx_', the sdma's from the ltib have a 'mxc' prefix.
> I tried to match them and wrap those 'mxc' in defines, mapping them to the
> 'imx' ones. Unfortunately for some fkts I didn't find a matching 'mxc' one.
> The driver compiles, but I guess it's pretty useless the way it is. May be
> I should have looked to the driver version in ltib, instead.
>
> After that I tried to register a SDMA channel with a device. As far as I
> can see that works. The Registered channel shows under
> '/proc/sdma/channels'. Freeing that also works.
>
> Next: Will try to start a SDMA transfer with SPI.

Thanks a lot for taking a look at it anyway.

Since this mxcmmc.c imx_ stuff is platform stuff cover mx1 and mx2, I 
guess there'll be trouble getting any mx3 DMA stuff accepted that 
doesn't play along with its existing game or change them all to some 
more standard method.

-Andy

SPI, DMA and an i.MX31

[Wolf, Rene, HRO-GP]

Hello @ all.

For the rest of the previous week I was trying to get the SDMA to work
with CSPI3. I did not succeed in that. But also could not verify if
I did it wrong or if the SDMA api is failing. What works, is to register
a channel with the SDMA. This shows up in '/proc/sdma/channels', freeing
that channel also works. A new irq pops up in '/proc/interrupts'.
And I managed to get the software callback to work, at least once.
Because I don't know how to use the api of the SDMA I cannot say if I
did the correct setup sequence. Also there seam to be more than one way
of doing that. 

I made a git patch based on 2.6.31. It is around 2 megs. and bz2 of it
is still some 200 kb. I guess I should upload it somewhere. Plus I hope
to get a small demo code ready, to show what I tried.

@Andy:
May be you might try that with your mmc app. some time :-)

At the moment I'm waiting for green light on posting that patch, which
hopefully will arrive soon.


Cheers
Rene  


Rene Wolf
LFK-Lenkflugk?rpersysteme GmbH
Human Resources Operations & Policy, HRO
Landshuter Stra?e 26, 85716 Unterschlei?heim, GERMANY
Phone: +49 89 3179 8337
Fax: +49 8252 99 8964
E-Mail: rene.wolf at mbda-systems.de

http://www.mbda.net

Chairman of the Supervisory Board: Antoine Bouvier
Managing Director: Werner Kaltenegger
Registered Office: Schrobenhausen
Commercial Register: Amtsgericht Ingolstadt, HRB 4365