Motorola MX.l DMA controller problem

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.

Reply to
JJ
Loading thread data ...

How do you specify the data byte count?

Can you read the ending address upon transfer complete?

Reply to
Tommy Reynolds

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
    formatting link
  • Monta vista also propose a BSP
    formatting link
  • Now, Sysgo will propose a BSP !!
    formatting link

Steph

Reply to
Stephane M

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:

and

problem.

Reply to
JJ

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:

and

problem.

Reply to
JJ

I am using BSP 3.6 from Motorola. Thank you for your information and I am going to them and check if they work.

Reply to
JJ

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.

Reply to
JJ

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:

and

problem.

"MX21

one of

Website...

Reply to
JJ

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:

and

problem.

"MX21

one of

Website...

Reply to
JJ

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.

Reply to
Floog

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.