linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Brad Boyer <flar@allandria.com>
Cc: Vijay Nikam <vijay.t.nikam@gmail.com>, linuxppc-dev@ozlabs.org
Subject: Re: request_irq return errno 38
Date: Thu, 12 Feb 2009 17:01:59 +1100	[thread overview]
Message-ID: <1234418520.29851.52.camel@pasglop> (raw)
In-Reply-To: <20090211223546.GA20129@cynthia.pants.nu>

On Wed, 2009-02-11 at 14:35 -0800, Brad Boyer wrote:
> On Wed, Feb 11, 2009 at 03:43:26PM +0530, Vijay Nikam wrote:
> > I read in LDD book, they give directly irq no. they have given
> > parallel port example, here they have set or said irq no. defaults to
> > 7 and they have not done any irq_mapping so what is the difference ? ?
> > ? I mean how I should know when to use irq_mapping and when not ? ? ?
> > 
> > Also is it some difference between writng drivers on embedded Linux
> > level and Linux PC (i386) ? ? ?
> 
> The basic request_irq() function is generic, but the value of the
> arguments (especially the number for the IRQ line) is architecture
> specific in many ways. This is one difference between the i386 code
> and the powerpc code inside Linux. Most i386 hardware is standard
> PC hardware with very clearly defined interrupt sources. 

In fact, not even clearly anymore :-) IE, there are still some legacy
interrupts at fixed numbers but most things are remapped on x86 too
nowadays when using IO_APICs, the kernel obtains numbers from ACPI,
remaps them etc...

What saves x86 is that anything other than legacy ISA uses PCI nowadays
and thus that remapping is invisible to PCI drivers (as it is on
powerpc). The problem only bites with other bus types more common on
embedded hardware, as you mention further down.

> Because of
> this, the mapping from the numeric IRQ value to a real hardware
> interrupt source is defined pretty clearly. The powerpc architecture
> code has to support almost arbitrarily complex hardware, and the
> embedded world is the source of most of the complexity. Because of
> this, the powerpc code has to dynamically allocate those numeric
> IRQ sources and tie them to a specific hardware interrupt. There
> is functionality to take the information from your device tree and
> convert it to a virtual IRQ. That happens automatically for some types
> of devices like PCI cards, but your driver may have to do that mapping
> itself in other cases. I believe the appropriate API for this is the
> function irq_of_parse_and_map(). It takes a device node and index into
> the interrupt list for that device and gives a virtual IRQ number.

Cheers,
Ben.

> 	Brad Boyer
> 	flar@allandria.com
> 
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev

  reply	other threads:[~2009-02-12  6:02 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-11  8:43 request_irq return errno 38 Vijay Nikam
2009-02-11  9:15 ` Michael Ellerman
2009-02-11  9:41   ` Vijay Nikam
2009-02-11  9:54     ` Michael Ellerman
2009-02-11 10:13       ` Vijay Nikam
2009-02-11 22:35         ` Brad Boyer
2009-02-12  6:01           ` Benjamin Herrenschmidt [this message]
2009-02-12 10:51           ` Vijay Nikam
2009-02-12 16:39             ` Timur Tabi
2009-02-12 22:49               ` David Gibson
2009-02-11 22:48         ` Scott Wood

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=1234418520.29851.52.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=flar@allandria.com \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=vijay.t.nikam@gmail.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 NNTP newsgroup(s).