public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
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

  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).