public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
* [ECOS] Question on PCI Interrupt translation
@ 2000-09-15 19:49 Ling Su
  2000-09-16  9:22 ` [ECOS] " Jonathan Larmour
  0 siblings, 1 reply; 3+ messages in thread
From: Ling Su @ 2000-09-15 19:49 UTC (permalink / raw)
  To: Jonathan Larmour; +Cc: ecos-discuss

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1175 bytes --]

Dear Jifl,
 
I have some question on the PCI interrupt translation, hope you can shed me 
some light. Thanks in advance!
 
In the PCI library docuement, there is a kernel API called 
cyg_pci_translate_interrupt(), it is used to translate the PCI interrupt 
requested by device to the accosiated CPU interrupt. When I read the Macro 
definiation in plf_io.h for NEC vrc4373, I didn't catch the idea of how to 
actually do the mapping. Supposely my PCI board can staticaly map to #INTA 
instead of #INTB - #INTD, right? so I needn't translate the interrupt, just 
allocate HAL INT11 to it, right?
 
Actually I follow what I described, I create the interrupt and hard wire it 
to IRQ 11, I can actually observe the falling edge of interrupt signal on the 
PCI bus, but I can not see the ISR and DSR are called. Did I miss anything 
important?
 
I read the test cases for intr, I didn't find an realistic sample to test 
the interrupt mechanism, since the test case just cover the function call part, 
not real interrupt is generated. Is there any working interrupt sample? 

 
Sorry for my dump question, and thanks for your patience!
 
Best Regards,
-Ling

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [ECOS] Re: Question on PCI Interrupt translation
  2000-09-15 19:49 [ECOS] Question on PCI Interrupt translation Ling Su
@ 2000-09-16  9:22 ` Jonathan Larmour
  2000-09-18 20:09   ` Ling Su
  0 siblings, 1 reply; 3+ messages in thread
From: Jonathan Larmour @ 2000-09-16  9:22 UTC (permalink / raw)
  To: Ling Su; +Cc: ecos-discuss

> Ling Su wrote:
> 
> Dear Jifl,
> 
> I have some question on the PCI interrupt translation, hope you can shed
> me some light. Thanks in advance!
> 
> In the PCI library docuement, there is a kernel API called
> cyg_pci_translate_interrupt(), it is used to translate the PCI interrupt
> requested by device to the accosiated CPU interrupt. When I read the
> Macro definiation in plf_io.h for NEC vrc4373, I didn't catch the idea of
> how to actually do the mapping. Supposely my PCI board can staticaly map
> to #INTA instead of #INTB - #INTD, right? so I needn't translate the
> interrupt, just allocate HAL INT11 to it, right?
> 
> Actually I follow what I described, I create the interrupt and hard wire
> it to IRQ 11, I can actually observe the falling edge of interrupt signal
> on the PCI bus, but I can not see the ISR and DSR are called. Did I miss
> anything important?

In principle, what you are describing sounds right to me, although I notice
the comment in plf_io.h:

// Translate the PCI interrupt requested by the device (INTA#, INTB#,
// INTC# or INTD#) to the associated CPU interrupt (i.e., HAL vector).
// We don't actually know what the mappings are at present for this
// board. The following is therefore just a temporary guess until
// we can find out.

You could try putting the interrupt handler on _all_ the PCI interrupts
just to be sure. If the mapping is wrong, let us know what the right one
is!
 
As you are guessing, it may just be a simple mistake in constructing the
ISR. Normally the steps are:

cyg_interrupt_create()
cyg_interrupt_attach()
cyg_interrupt_unmask()

and be sure to call cyg_interrupt_acknowledge() in the ISR.

> I read the test cases for intr, I didn't find an realistic sample to test
> the interrupt mechanism, since the test case just cover the function call
> part, not real interrupt is generated. Is there any working interrupt
> sample?

Any serial device driver. Also the kernel real time clock, although this
uses the internal C++ based interface.

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [ECOS] Re: Question on PCI Interrupt translation
  2000-09-16  9:22 ` [ECOS] " Jonathan Larmour
@ 2000-09-18 20:09   ` Ling Su
  0 siblings, 0 replies; 3+ messages in thread
From: Ling Su @ 2000-09-18 20:09 UTC (permalink / raw)
  To: Jonathan Larmour; +Cc: ecos-discuss

>
> As you are guessing, it may just be a simple mistake in constructing the
> ISR. Normally the steps are:
>
> cyg_interrupt_create()
> cyg_interrupt_attach()
> cyg_interrupt_unmask()
>
> and be sure to call cyg_interrupt_acknowledge() in the ISR.
>
> > I read the test cases for intr, I didn't find an realistic sample to
test
> > the interrupt mechanism, since the test case just cover the function
call
> > part, not real interrupt is generated. Is there any working interrupt
> > sample?
>

Thanks Jifl,

I guess I follow the correct step of using interrupt. I am not sure if it is
the bug for eCos, I changed one thing in platform.S for vrc4373. In the
initialization of vrc4372, the INTPOL and INTRIG are set to 0x03fff, I use
0x001f instead. Since PCI standard use interrupt for level trigger, low
active, I initialize the #INTA-#INTB to this configuration, I can enter the
ISR now...

But the question is, supposely the DSR will be executed automatically,
right? But I wait for a long time, nothing happens? Is that a problem?

Will you attend the ESC at San Jose?

Thanks.

Rgds,
-Ling

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2000-09-18 20:09 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-09-15 19:49 [ECOS] Question on PCI Interrupt translation Ling Su
2000-09-16  9:22 ` [ECOS] " Jonathan Larmour
2000-09-18 20:09   ` Ling Su

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 read-only IMAP folder(s) and NNTP newsgroup(s).