* Using IDMA1 ( or IDMA2 ) on 860
@ 2001-08-19 19:06 John Francis
2001-08-19 19:50 ` Dan Malek
0 siblings, 1 reply; 6+ messages in thread
From: John Francis @ 2001-08-19 19:06 UTC (permalink / raw)
To: linuxppc-embedded
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/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Using IDMA1 ( or IDMA2 ) on 860
2001-08-19 19:06 Using IDMA1 ( or IDMA2 ) on 860 John Francis
@ 2001-08-19 19:50 ` Dan Malek
2001-08-19 20:33 ` John Francis
0 siblings, 1 reply; 6+ messages in thread
From: Dan Malek @ 2001-08-19 19:50 UTC (permalink / raw)
To: John Francis; +Cc: linuxppc-embedded
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/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Using IDMA1 ( or IDMA2 ) on 860
2001-08-19 19:50 ` Dan Malek
@ 2001-08-19 20:33 ` John Francis
2001-08-19 20:41 ` Dan Malek
0 siblings, 1 reply; 6+ messages in thread
From: John Francis @ 2001-08-19 20:33 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-embedded
Hello Dan,
--- Dan Malek <dan@mvista.com> wrote:
> 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
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/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Using IDMA1 ( or IDMA2 ) on 860
2001-08-19 20:33 ` John Francis
@ 2001-08-19 20:41 ` Dan Malek
2001-08-20 19:16 ` John Francis
0 siblings, 1 reply; 6+ messages in thread
From: Dan Malek @ 2001-08-19 20:41 UTC (permalink / raw)
To: John Francis; +Cc: linuxppc-embedded
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/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Using IDMA1 ( or IDMA2 ) on 860
2001-08-19 20:41 ` Dan Malek
@ 2001-08-20 19:16 ` John Francis
2001-08-20 19:35 ` Dan Malek
0 siblings, 1 reply; 6+ messages in thread
From: John Francis @ 2001-08-20 19:16 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-embedded
Dan,
>
> > /* 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/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Using IDMA1 ( or IDMA2 ) on 860
2001-08-20 19:16 ` John Francis
@ 2001-08-20 19:35 ` Dan Malek
0 siblings, 0 replies; 6+ messages in thread
From: Dan Malek @ 2001-08-20 19:35 UTC (permalink / raw)
To: John Francis; +Cc: linuxppc-embedded
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/
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2001-08-20 19:35 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-08-19 19:06 Using IDMA1 ( or IDMA2 ) on 860 John Francis
2001-08-19 19:50 ` Dan Malek
2001-08-19 20:33 ` John Francis
2001-08-19 20:41 ` Dan Malek
2001-08-20 19:16 ` John Francis
2001-08-20 19:35 ` Dan Malek
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).