From: Jonathan Larmour <jlarmour@redhat.com>
To: Ling Su <lingsu@palmmicro.com>
Cc: ecos-discuss@sources.redhat.com
Subject: [ECOS] Re: Question on PCI Interrupt translation
Date: Sat, 16 Sep 2000 09:22:00 -0000 [thread overview]
Message-ID: <39C39E43.D84D85FE@redhat.com> (raw)
In-Reply-To: <002601c01f88$dbb55000$1601a8c0@crusoe>
> 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
next prev parent reply other threads:[~2000-09-16 9:22 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-09-15 19:49 [ECOS] " Ling Su
2000-09-16 9:22 ` Jonathan Larmour [this message]
2000-09-18 20:09 ` [ECOS] " Ling Su
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=39C39E43.D84D85FE@redhat.com \
--to=jlarmour@redhat.com \
--cc=ecos-discuss@sources.redhat.com \
--cc=lingsu@palmmicro.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).