Using IDMA1 ( or IDMA2 ) on 860

Hello,

On my board I am using SCC1 and SCC2 for 10 Mbps
ethernets.

I am also using SMC1 and SMC2 for some 9600 baud
serial connection.

I am also planning on using IDMA1 for some DMA. My
chip is a 860P are there any problems with Parameter
ram conflict?

All SCC1, SCC2, SMC1 and SMC2 work fine. But my IDMA1
CPM interrupt handler never gets invoked, on hardware
side I do see the DREQ line going low and I have
verified that RCCR register for CPM is set correctly
to level trigger the interrupt.

Any ideas on why IDMA1 interrupt handler is not
getting invoked?

ANY HELP !!!!

John


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

John Francis wrote:

..... on hardware
side I do see the DREQ line going low and I have
verified that RCCR register for CPM is set correctly
to level trigger the interrupt.

Any ideas on why IDMA1 interrupt handler is not
getting invoked?

The DREQ has nothing to do with generating an interrupt, it
is a data transfer handshake signal.  The configuration of
this pin is determined by the system design, connection to
the peripheral for data transfer and the configuration of
the memory controller.

The configuration of the IDMA channel, including the buffer
descriptors, will determine how and when the CPM interrupt
will occur.

	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Hello Dan,

--- Dan Malek <dan@mvista.com> wrote:

John Francis wrote:

quoted

..... on hardware
side I do see the DREQ line going low and I have
verified that RCCR register for CPM is set

correctly

quoted

to level trigger the interrupt.

Any ideas on why IDMA1 interrupt handler is not
getting invoked?

The DREQ has nothing to do with generating an
interrupt, it
is a data transfer handshake signal.  The
configuration of
this pin is determined by the system design,
connection to
the peripheral for data transfer and the
configuration of
the memory controller.

The configuration of the IDMA channel, including the
buffer
descriptors, will determine how and when the CPM
interrupt
will occur.

	-- Dan

May be I should have been more specific, yes I have
setup the PC15 pin to have correct direction.

I have checked and rechecked the IDMA buffer
descriptors and they look "okay".

I have another question may be this is something
related.

I am working with chip whos configuration memory is
accessible and that memory is mapped to chip select 2
( BR2 ).

WHat I have seen is my kernel functions cause panic if
I use first version of GetChipAddress but second
version works?

I mean if I do something like
 *(unsigned long *)(GetChipAddress() + 0x02 ) =
0xABCD;

first version causes panic, second version doesn't.

/* version1 of  GetChipAddress this BREAKS why? */

GetChipAddress()
{

PDA *ppda = (PDA *)(GetIMMR() & IO_MAP_MASK);

return(ppda->memc_br2 & 0xFFFF8000);
}

/* version2 of GetChipAddress this WORKS why? */
unsigned long driver_fifobase;
GetChipAddress()
{
PDA *ppda = (PDA *)(GetIMMR() & IO_MAP_MASK);


if ( driver_fifobase == 0 )
       driver_fifobase =
    (unsigned long)ioremap_nocache( ( ppda->memc_br2
		& 0xffff0000),0x4000 );

return driver_fifobase;

}

Thanks.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

John Francis wrote:

May be I should have been more specific, yes I have
setup the PC15 pin to have correct direction.

Well, your description indicated you were expecting the
transition of DREQ to generate an interrupt.  This isn't
the case.  Have you connected a logic analyzer to the bus
and determined the DMA is working correctly?

/* version2 of GetChipAddress this WORKS why? */

Because you can't directly access physical bus addresses from
the kernel.  They have to be mapped to some virtual address.
The IMMR is mapped to a well known address that can generally
be used anywhere in the kernel.  Anything else must be mapped,
as your example shows.  Just make sure you do this _once_,
don't keep calling ioremap() over and over or you will exhaust
the VM space and get a different address every time.


	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Dan,

quoted

/* version2 of GetChipAddress this WORKS why? */

Because you can't directly access physical bus
addresses from
the kernel.  They have to be mapped to some virtual
address.
The IMMR is mapped to a well known address that can
generally
be used anywhere in the kernel.  Anything else must
be mapped,
as your example shows.  Just make sure you do this
_once_,
don't keep calling ioremap() over and over or you
will exhaust
the VM space and get a different address every time.


	-- Dan

Thanks for all your help and education. One last
question on this, if I have a pointer that is returned
by doing ioremap_noncache() if I want to assign this
pointer in buffer descriptor setup should i be doing
__pa () correct? Will __pa() translate that address
back to the actual physical address?

John


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

John Francis wrote:

..... if I have a pointer that is returned
by doing ioremap_noncache() if I want to assign this
pointer in buffer descriptor setup should i be doing
__pa () correct?

No, that won't work.  You will have to keep the original
physical address around someplace and use it when necessary.


	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/