Motorola MX.l DMA controller problem

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Motoroloa's MX.l's DMA controller does not support transfer count and
get_dma_residue does not function. I dont know how to fix this problem.



Re: Motorola MX.l DMA controller problem

Quoted text here. Click to load it

How do you specify the data byte count?

Can you read the ending address upon transfer complete?


Re: Motorola MX.l DMA controller problem
I am using the BSP 3.6 from Motorola. When I use GETODELAY in OSS, it
does not work properly, so I check the kernel code. I found that it use
Channel Count Register in get_dma_residue, and I checked the reference
manual and found that it was used for set size of transfer cycle but
only reflecting transferred count under normal situtation.

I also checked its Channel Destination Address Register, but its
content won't change and it also does not reflect any change.

I am not sure where does it specify the data byte count but I will try
to check it.



Tommy Reynolds wrote:
Quoted text here. Click to load it
and
problem.


Re: Motorola MX.l DMA controller problem
I am using the BSP 3.6 from Motorola. When I use GETODELAY in OSS, it
does not work properly, so I check the kernel code. I found that it use
Channel Count Register in get_dma_residue, and I checked the reference
manual and found that it was used for set size of transfer cycle but
only reflecting transferred count under normal situtation.

I also checked its Channel Destination Address Register, but its
content won't change and it also does not reflect any change.

I am not sure where does it specify the data byte count but I will try
to check it.



Tommy Reynolds wrote:
Quoted text here. Click to load it
and
problem.


Re: Motorola MX.l DMA controller problem
I need to make a correction on previous mail:

The Channel Count Register does not reflect transferred byte count
under normal situation. It only reflect transferred byte count only if
source is end-of-brust FIFO mode such as endpoint of USB. Therefore, it
is no use under normal situtation.


Re: Motorola MX.l DMA controller problem

Quoted text here. Click to load it

Which Linux are you using ??
I would suppose that BSP MX1, could be "quite"  copmpatible with a "MX21
BSP"

Actually, There are 3 Linux distry today on the market. Are you using one of
them ??
At least the Metrowerks one can be downloaded fo free on their Website...
Have a look if this will solve your problem with the Brand new BSP

* Metrowerks just released a fairly new BSP wiht PCS and Embedix
http://www.metrowerks.com/MW/download/default.asp?action=bsp
* Monta vista also propose a BSP
http://www.mvista.com/products/boards.html#arm
* Now, Sysgo will propose a BSP !!
http://www.sysgo.com/index.php?id79%&backPID80%&L=1&tt_news15%3

Steph



Re: Motorola MX.l DMA controller problem
I am using BSP 3.6 from Motorola. Thank you for your information and I
am going to them and check if they work.


Re: Motorola MX.l DMA controller problem
I checked MX21's reference manuel, Motorola added a new register
"Channel Counter Register" to MX21's DMAC. I does not check MX21's BSP
but I believe it is fixed by the new register in MX21.


Stephane M wrote:
Quoted text here. Click to load it
and
problem.
"MX21
Quoted text here. Click to load it
one of
Website...


Re: Motorola MX.l DMA controller problem
I checked MX21's reference manuel, Motorola added a new register
"Channel Counter Register" to MX21's DMAC. I does not check MX21's BSP
but I believe it is fixed by the new register in MX21.


Stephane M wrote:
Quoted text here. Click to load it
and
problem.
"MX21
Quoted text here. Click to load it
one of
Website...


re:Motorola MX.l DMA controller problem
All,

If you refer to the BSP0.3.6, it means you are using the iMXL or iMX1
BSP. You cannot retrieve the current number of bytes that have been
exchanged (=get_dma_residue), the DMA does not support it.

Yet, this function is available in the iMX21, with a new register
called counter register, that indicates the number of bytes really
transferred.


Site Timeline