From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Robert Thorhuus <robert.thorhuus@ericsson.com>
Cc: "linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Subject: Re: Open Firmware and interrupt trigger
Date: Fri, 25 Feb 2011 07:46:58 +1100 [thread overview]
Message-ID: <1298580418.8833.428.camel@pasglop> (raw)
In-Reply-To: <9081694521850B4D91387C8C2E612B591062A0D5CA@ESESSCMS0361.eemea.ericsson.se>
On Wed, 2011-02-23 at 22:18 +0100, Robert Thorhuus wrote:
> Hello!
>
> I'm quite new to linux and Open Firmware.
>
> I have a PPC processor. To this I have a Compact Flash connected. The Compact Flash is using external interrupt 0 of the processor.
> In my DTS file I have specified a Compact Flash node and within it I have an interrupt element:
> interrupt = <0 2 0 0>;
>
> Here I thought the first number was the ID of the interrupt and the second one should be a number indicating how the interrupt is triggered (high, low, raising, falling).
>
> The interrupt is active low.
>
> But I could not get it to work which ever value I chose.
>
> Looking in the code I found this in function __devinit pata_of_platform_probe in file pata_of_platform.c:
>
> ret = of_irq_to_resource(dn, 0, &irq_res);
> if (ret == NO_IRQ)
> irq_res.start = irq_res.end = 0;
> else
> irq_res.flags = 0;
>
> Here "flags" will be zero whatever I do in the DTS. As far as I can understand the flags are defined in interrupts.h:
> #define IRQF_TRIGGER_NONE 0x00000000
> #define IRQF_TRIGGER_RISING 0x00000001
> #define IRQF_TRIGGER_FALLING 0x00000002
> #define IRQF_TRIGGER_HIGH 0x00000004
> #define IRQF_TRIGGER_LOW 0x00000008
Actually, the .dts flags depend on the specific interrupt controller you
are using. For example, MPIC uses a different mapping scheme (for
historical reasons). Check booting-without-of.txt.
> So modifying the code to:
> else
> irq_res.flags = 2;
>
> I get it to work.
>
> Could someone please explain to me why the "flags" parameter is hardcoded zero or just point in a good direction.
That does indeed look odd. Might be worth trying to figure out with the
git history who came up with that code in the first place and ask that
person. Without answer, I think it's valid to patch that out.
Cheers,
Ben.
> Thank you
>
> BR
> Robert
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
next prev parent reply other threads:[~2011-02-24 20:47 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-23 4:33 [RFC PATCH 00/15] Remove last remains of of_platform_bus_type Grant Likely
2011-02-23 4:33 ` [RFC PATCH 01/15] dt/powerpc: move of_bus_type infrastructure to ibmebus Grant Likely
2011-02-24 14:46 ` Arnd Bergmann
2011-02-25 8:53 ` Benjamin Herrenschmidt
2011-02-28 7:35 ` Grant Likely
2011-02-23 4:33 ` [RFC PATCH 02/15] dt: add a match table pointer to struct device Grant Likely
2011-02-23 18:29 ` Rob Herring
2011-02-23 18:44 ` Grant Likely
2011-02-23 21:18 ` Open Firmware and interrupt trigger Robert Thorhuus
2011-02-24 20:46 ` Benjamin Herrenschmidt [this message]
2011-02-25 7:29 ` Robert Thorhuus
2011-02-25 8:47 ` Benjamin Herrenschmidt
2011-02-23 4:33 ` [RFC PATCH 03/15] dt/powerpc: Eliminate users of of_platform_{, un}register_driver Grant Likely
2011-02-23 4:33 ` [RFC PATCH 04/15] dt/sparc: " Grant Likely
2011-02-23 4:34 ` [RFC PATCH 05/15] leds/leds-gpio: merge platform_driver with of_platform_driver Grant Likely
2011-02-23 4:34 ` [RFC PATCH 06/15] dt: xilinx_hwicap: merge platform and of_platform driver bindings Grant Likely
2011-02-25 18:25 ` [RFC PATCH 06/15] dt: xilinx_hwicap: merge platform and of_platformdriver bindings Stephen Neuendorffer
2011-02-28 7:41 ` Grant Likely
2011-02-23 4:34 ` [RFC PATCH 07/15] dt: uartlite: merge platform and of_platform driver bindings Grant Likely
2011-02-23 8:58 ` Peter Korsgaard
2011-02-23 18:10 ` Grant Likely
2011-02-23 4:34 ` [RFC PATCH 08/15] dt/spi: Eliminate users of of_platform_{, un}register_driver Grant Likely
2011-02-23 4:34 ` [RFC PATCH 09/15] dt/sound: " Grant Likely
2011-02-23 4:34 ` [RFC PATCH 10/15] dt/net: " Grant Likely
2011-02-23 4:34 ` [RFC PATCH 11/15] dt/video: " Grant Likely
2011-02-23 4:34 ` [RFC PATCH 12/15] dt/usb: " Grant Likely
2011-02-23 4:34 ` [RFC PATCH 13/15] dt/serial: " Grant Likely
2011-02-24 16:34 ` Arnd Bergmann
2011-02-23 4:34 ` [RFC PATCH 14/15] dt: Eliminate of_platform_{,un}register_driver Grant Likely
2011-02-23 16:56 ` Rob Herring
2011-02-23 17:22 ` Grant Likely
2011-02-23 4:34 ` [RFC PATCH 15/15] dt: eliminate of_platform_driver shim code Grant Likely
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=1298580418.8833.428.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=robert.thorhuus@ericsson.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).