* [PATCH] MIPS: Add some irq definitins required by OF
@ 2010-10-14 21:02 David Daney
2010-10-15 1:27 ` Grant Likely
0 siblings, 1 reply; 6+ messages in thread
From: David Daney @ 2010-10-14 21:02 UTC (permalink / raw)
To: linux-mips, ralf; +Cc: David Daney, Grant Likely
Using the forthcoming open firmware (OF) on mips patches, requires
that several interrupt related definitions be added.
In the future we may want to allow some sort of override for
irq_create_mapping, but for now it is just supplies an identity
mapping.
Signed-off-by: David Daney <ddaney@caviumnetworks.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
---
arch/mips/include/asm/irq.h | 33 +++++++++++++++++++++++++++++++++
1 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/arch/mips/include/asm/irq.h b/arch/mips/include/asm/irq.h
index dea4aed..f109e67 100644
--- a/arch/mips/include/asm/irq.h
+++ b/arch/mips/include/asm/irq.h
@@ -16,6 +16,39 @@
#include <irq.h>
+#define NO_IRQ UINT_MAX
+
+/*
+ * This type is the placeholder for a hardware interrupt number. It
+ * has to be big enough to enclose whatever representation is used by
+ * a given platform.
+ */
+typedef unsigned long irq_hw_number_t;
+
+static inline void irq_dispose_mapping(unsigned int virq)
+{
+ return;
+}
+
+struct irq_host;
+
+/**
+ * irq_create_mapping - Map a hardware interrupt into linux virq space
+ * @host: host owning this hardware interrupt or NULL for default host
+ * @hwirq: hardware irq number in that host space
+ *
+ * Only one mapping per hardware interrupt is permitted. Returns a linux
+ * virq number.
+ * If the sense/trigger is to be specified, set_irq_type() should be called
+ * on the number returned from that call.
+ */
+static inline unsigned int irq_create_mapping(struct irq_host *host,
+ irq_hw_number_t hwirq)
+{
+ /* For now, an identity mapping. */
+ return (unsigned int)hwirq;
+}
+
#ifdef CONFIG_I8259
static inline int irq_canonicalize(int irq)
{
--
1.7.2.3
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] MIPS: Add some irq definitins required by OF
2010-10-14 21:02 [PATCH] MIPS: Add some irq definitins required by OF David Daney
@ 2010-10-15 1:27 ` Grant Likely
2010-10-15 19:50 ` David Daney
2010-10-26 22:18 ` David Daney
0 siblings, 2 replies; 6+ messages in thread
From: Grant Likely @ 2010-10-15 1:27 UTC (permalink / raw)
To: David Daney; +Cc: linux-mips, ralf
On Thu, Oct 14, 2010 at 3:02 PM, David Daney <ddaney@caviumnetworks.com> wrote:
> Using the forthcoming open firmware (OF) on mips patches, requires
> that several interrupt related definitions be added.
>
> In the future we may want to allow some sort of override for
> irq_create_mapping, but for now it is just supplies an identity
> mapping.
>
> Signed-off-by: David Daney <ddaney@caviumnetworks.com>
> Cc: Grant Likely <grant.likely@secretlab.ca>
Hi David,
If you try my current next-devicetree branch then this patch should
not be necessary. I was able to build the mips patch before I posted it.
> ---
> arch/mips/include/asm/irq.h | 33 +++++++++++++++++++++++++++++++++
> 1 files changed, 33 insertions(+), 0 deletions(-)
>
> diff --git a/arch/mips/include/asm/irq.h b/arch/mips/include/asm/irq.h
> index dea4aed..f109e67 100644
> --- a/arch/mips/include/asm/irq.h
> +++ b/arch/mips/include/asm/irq.h
> @@ -16,6 +16,39 @@
>
> #include <irq.h>
>
> +#define NO_IRQ UINT_MAX
Really? The verdict came down a long time ago that 0 is to be the
value that means no irq, and only a few architectures still define
NO_IRQ as -1. It is assumed that the architectures which do not
define NO_IRQ use 0 as the invalid value. Mostly notably x86 does not
define NO_IRQ, and Linus nack'd the patch to add it.
linux-2.6$ git grep '#define[ \t]*NO_IRQ[^_]'
arch/arm/include/asm/irq.h:#define NO_IRQ ((unsigned int)(-1))
arch/microblaze/include/asm/irq.h:#define NO_IRQ (-1)
arch/mn10300/include/asm/irq.h:#define NO_IRQ INT_MAX
arch/parisc/include/asm/irq.h:#define NO_IRQ (-1)
arch/powerpc/include/asm/irq.h:#define NO_IRQ (0)
arch/xtensa/variants/s6000/include/variant/irq.h:#define NO_IRQ (-1)
drivers/input/touchscreen/ucb1400_ts.c:#define NO_IRQ 0
drivers/of/irq.c:#define NO_IRQ 0
drivers/pcmcia/pd6729.c:#define NO_IRQ ((unsigned int)(0))
drivers/rtc/rtc-m48t59.c:#define NO_IRQ (-1)
drivers/scsi/arm/fas216.h:#define NO_IRQ 255
As far as I can tell, only arm, microblaze, mn10200, parisc, and
xtensa define NO_IRQ to -1, and of those I've got a pending patch to
change Microblaze to use 0. arm is the hard holdout because of all
the legacy board ports.
> +
> +/*
> + * This type is the placeholder for a hardware interrupt number. It
> + * has to be big enough to enclose whatever representation is used by
> + * a given platform.
> + */
> +typedef unsigned long irq_hw_number_t;
> +
> +static inline void irq_dispose_mapping(unsigned int virq)
> +{
> + return;
> +}
> +
> +struct irq_host;
> +
> +/**
> + * irq_create_mapping - Map a hardware interrupt into linux virq space
> + * @host: host owning this hardware interrupt or NULL for default host
> + * @hwirq: hardware irq number in that host space
> + *
> + * Only one mapping per hardware interrupt is permitted. Returns a linux
> + * virq number.
> + * If the sense/trigger is to be specified, set_irq_type() should be called
> + * on the number returned from that call.
> + */
> +static inline unsigned int irq_create_mapping(struct irq_host *host,
> + irq_hw_number_t hwirq)
> +{
> + /* For now, an identity mapping. */
> + return (unsigned int)hwirq;
> +}
> +
> #ifdef CONFIG_I8259
> static inline int irq_canonicalize(int irq)
> {
> --
> 1.7.2.3
>
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] MIPS: Add some irq definitins required by OF
2010-10-15 1:27 ` Grant Likely
@ 2010-10-15 19:50 ` David Daney
2010-10-15 19:55 ` Grant Likely
2010-10-26 22:18 ` David Daney
1 sibling, 1 reply; 6+ messages in thread
From: David Daney @ 2010-10-15 19:50 UTC (permalink / raw)
To: Grant Likely; +Cc: linux-mips, ralf
On 10/14/2010 06:27 PM, Grant Likely wrote:
> On Thu, Oct 14, 2010 at 3:02 PM, David Daney<ddaney@caviumnetworks.com> wrote:
>> Using the forthcoming open firmware (OF) on mips patches, requires
>> that several interrupt related definitions be added.
>>
>> In the future we may want to allow some sort of override for
>> irq_create_mapping, but for now it is just supplies an identity
>> mapping.
>>
>> Signed-off-by: David Daney<ddaney@caviumnetworks.com>
>> Cc: Grant Likely<grant.likely@secretlab.ca>
>
> Hi David,
>
> If you try my current next-devicetree branch then this patch should
> not be necessary. I was able to build the mips patch before I posted it.
>
This is what I get building on your next-devicetree branch:
CC drivers/of/of_i2c.o
drivers/of/of_i2c.c: In function 'of_i2c_register_devices':
drivers/of/of_i2c.c:70: error: implicit declaration of function
'irq_dispose_mapping'
Hence the part of my patch where I added those irq_create_mapping() and
irq_dispose_mapping() functions.
David Daney
>> ---
>> arch/mips/include/asm/irq.h | 33 +++++++++++++++++++++++++++++++++
>> 1 files changed, 33 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/mips/include/asm/irq.h b/arch/mips/include/asm/irq.h
>> index dea4aed..f109e67 100644
>> --- a/arch/mips/include/asm/irq.h
>> +++ b/arch/mips/include/asm/irq.h
>> @@ -16,6 +16,39 @@
>>
>> #include<irq.h>
>>
>> +#define NO_IRQ UINT_MAX
>
> Really? The verdict came down a long time ago that 0 is to be the
> value that means no irq, and only a few architectures still define
> NO_IRQ as -1. It is assumed that the architectures which do not
> define NO_IRQ use 0 as the invalid value. Mostly notably x86 does not
> define NO_IRQ, and Linus nack'd the patch to add it.
>
> linux-2.6$ git grep '#define[ \t]*NO_IRQ[^_]'
> arch/arm/include/asm/irq.h:#define NO_IRQ ((unsigned int)(-1))
> arch/microblaze/include/asm/irq.h:#define NO_IRQ (-1)
> arch/mn10300/include/asm/irq.h:#define NO_IRQ INT_MAX
> arch/parisc/include/asm/irq.h:#define NO_IRQ (-1)
> arch/powerpc/include/asm/irq.h:#define NO_IRQ (0)
> arch/xtensa/variants/s6000/include/variant/irq.h:#define NO_IRQ (-1)
> drivers/input/touchscreen/ucb1400_ts.c:#define NO_IRQ 0
> drivers/of/irq.c:#define NO_IRQ 0
> drivers/pcmcia/pd6729.c:#define NO_IRQ ((unsigned int)(0))
> drivers/rtc/rtc-m48t59.c:#define NO_IRQ (-1)
> drivers/scsi/arm/fas216.h:#define NO_IRQ 255
>
> As far as I can tell, only arm, microblaze, mn10200, parisc, and
> xtensa define NO_IRQ to -1, and of those I've got a pending patch to
> change Microblaze to use 0. arm is the hard holdout because of all
> the legacy board ports.
>
>> +
>> +/*
>> + * This type is the placeholder for a hardware interrupt number. It
>> + * has to be big enough to enclose whatever representation is used by
>> + * a given platform.
>> + */
>> +typedef unsigned long irq_hw_number_t;
>> +
>> +static inline void irq_dispose_mapping(unsigned int virq)
>> +{
>> + return;
>> +}
>> +
>> +struct irq_host;
>> +
>> +/**
>> + * irq_create_mapping - Map a hardware interrupt into linux virq space
>> + * @host: host owning this hardware interrupt or NULL for default host
>> + * @hwirq: hardware irq number in that host space
>> + *
>> + * Only one mapping per hardware interrupt is permitted. Returns a linux
>> + * virq number.
>> + * If the sense/trigger is to be specified, set_irq_type() should be called
>> + * on the number returned from that call.
>> + */
>> +static inline unsigned int irq_create_mapping(struct irq_host *host,
>> + irq_hw_number_t hwirq)
>> +{
>> + /* For now, an identity mapping. */
>> + return (unsigned int)hwirq;
>> +}
>> +
>> #ifdef CONFIG_I8259
>> static inline int irq_canonicalize(int irq)
>> {
>> --
>> 1.7.2.3
>>
>>
>
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] MIPS: Add some irq definitins required by OF
2010-10-15 19:50 ` David Daney
@ 2010-10-15 19:55 ` Grant Likely
0 siblings, 0 replies; 6+ messages in thread
From: Grant Likely @ 2010-10-15 19:55 UTC (permalink / raw)
To: David Daney; +Cc: linux-mips, ralf
On Fri, Oct 15, 2010 at 1:50 PM, David Daney <ddaney@caviumnetworks.com> wrote:
> On 10/14/2010 06:27 PM, Grant Likely wrote:
>>
>> On Thu, Oct 14, 2010 at 3:02 PM, David Daney<ddaney@caviumnetworks.com>
>> wrote:
>>>
>>> Using the forthcoming open firmware (OF) on mips patches, requires
>>> that several interrupt related definitions be added.
>>>
>>> In the future we may want to allow some sort of override for
>>> irq_create_mapping, but for now it is just supplies an identity
>>> mapping.
>>>
>>> Signed-off-by: David Daney<ddaney@caviumnetworks.com>
>>> Cc: Grant Likely<grant.likely@secretlab.ca>
>>
>> Hi David,
>>
>> If you try my current next-devicetree branch then this patch should
>> not be necessary. I was able to build the mips patch before I posted it.
>>
>
> This is what I get building on your next-devicetree branch:
>
> CC drivers/of/of_i2c.o
> drivers/of/of_i2c.c: In function 'of_i2c_register_devices':
> drivers/of/of_i2c.c:70: error: implicit declaration of function
> 'irq_dispose_mapping'
>
>
> Hence the part of my patch where I added those irq_create_mapping() and
> irq_dispose_mapping() functions.
Oops, I missed that. I obviously didn't have CONFIG_I2C enabled when
I build tested. I'll craft a patch so that MIPS doesn't need to
define it.
g.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] MIPS: Add some irq definitins required by OF
2010-10-15 1:27 ` Grant Likely
2010-10-15 19:50 ` David Daney
@ 2010-10-26 22:18 ` David Daney
2010-10-27 8:10 ` Grant Likely
1 sibling, 1 reply; 6+ messages in thread
From: David Daney @ 2010-10-26 22:18 UTC (permalink / raw)
To: Grant Likely; +Cc: linux-mips, ralf
On 10/14/2010 06:27 PM, Grant Likely wrote:
> On Thu, Oct 14, 2010 at 3:02 PM, David Daney<ddaney@caviumnetworks.com> wrote:
[...]
>>
>> +#define NO_IRQ UINT_MAX
>
> Really? The verdict came down a long time ago that 0 is to be the
> value that means no irq, and only a few architectures still define
> NO_IRQ as -1. It is assumed that the architectures which do not
> define NO_IRQ use 0 as the invalid value. Mostly notably x86 does not
> define NO_IRQ, and Linus nack'd the patch to add it.
>
I was not part of that discussion.
I would however note, that all the irq functions return unsigned, so a
value of -1 is meaningless. Also my understanding is that 8259 based
systems use the values of 0 - 15 as the interrupt numbers, making 0
unavailable for use as NO_IRQ.
Given these constraints, UINT_MAX would seem to be a good value. It has
to be defined as something *and* have global visibility, because it is
part of the OF irq mapping functions API.
David Daney
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] MIPS: Add some irq definitins required by OF
2010-10-26 22:18 ` David Daney
@ 2010-10-27 8:10 ` Grant Likely
0 siblings, 0 replies; 6+ messages in thread
From: Grant Likely @ 2010-10-27 8:10 UTC (permalink / raw)
To: David Daney; +Cc: linux-mips, ralf
On Tue, Oct 26, 2010 at 11:18 PM, David Daney <ddaney@caviumnetworks.com> wrote:
> On 10/14/2010 06:27 PM, Grant Likely wrote:
>>
>> On Thu, Oct 14, 2010 at 3:02 PM, David Daney<ddaney@caviumnetworks.com>
>> wrote:
>
> [...]
>>>
>>> +#define NO_IRQ UINT_MAX
>>
>> Really? The verdict came down a long time ago that 0 is to be the
>> value that means no irq, and only a few architectures still define
>> NO_IRQ as -1. It is assumed that the architectures which do not
>> define NO_IRQ use 0 as the invalid value. Mostly notably x86 does not
>> define NO_IRQ, and Linus nack'd the patch to add it.
>>
>
> I was not part of that discussion.
>
> I would however note, that all the irq functions return unsigned, so a value
> of -1 is meaningless. Also my understanding is that 8259 based systems use
> the values of 0 - 15 as the interrupt numbers, making 0 unavailable for use
> as NO_IRQ.
This is an old discussion which has been debated thoroughly and
ultimately resolved by Linus[1]. NO_IRQ is in the (slow) process of
being removed entirely. It is worth reading the entire thread for
background.
[1] http://lkml.org/lkml/2005/11/21/200
An irq value of 0 means no irq, and the correct cross-platform test is
"if (!irq)". Note that this is the /linux/ irq number, not the
hardware irq number. Of course interrupt controller hardware may
define an interrupt number zero, it must not be mapped to linux irq
number zero.
As you note, 8259 systems do define an irq number 0 which is mapped to
the timer, but it is not exported to driver code. If an architecture
wants to use irq 0 directly, then it should be contained in the arch
code.
g.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2010-10-27 8:11 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-10-14 21:02 [PATCH] MIPS: Add some irq definitins required by OF David Daney
2010-10-15 1:27 ` Grant Likely
2010-10-15 19:50 ` David Daney
2010-10-15 19:55 ` Grant Likely
2010-10-26 22:18 ` David Daney
2010-10-27 8:10 ` Grant Likely
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.