From: Sricharan R <r.sricharan@ti.com>
To: Jason Cooper <jason@lakedaemon.net>
Cc: linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
tony@atomide.com, santosh.shilimkar@ti.com, nm@ti.com,
rnayak@ti.com, linux@arm.linux.org.uk, tglx@linutronix.de,
joe@perches.com
Subject: Re: [PATCH V3 16/16] irqchip: crossbar: allow for quirky hardware with direct hardwiring of GIC
Date: Mon, 23 Jun 2014 12:52:44 +0530 [thread overview]
Message-ID: <53A7D5C4.6090201@ti.com> (raw)
In-Reply-To: <20140621025723.GF21711@titan.lakedaemon.net>
Hi Jason,
On Saturday 21 June 2014 08:27 AM, Jason Cooper wrote:
> On Mon, Jun 16, 2014 at 04:53:16PM +0530, Sricharan R wrote:
>> From: Nishanth Menon <nm@ti.com>
>>
>> On certain platforms such as DRA7, SPIs 0, 1, 2, 3, 5, 6, 10, 131,
>> 132, 133 are direct wired to hardware blocks bypassing crossbar.
>> This quirky implementation is *NOT* supposed to be the expectation
>> of crossbar hardware usage. However, these are already marked in our
>> description of the hardware with SKIP and RESERVED where appropriate.
>>
>> Unfortunately, we need to be able to refer to these hardwired IRQs.
>> So, to request these, crossbar driver can use the existing information
>> from it's table that these SKIP/RESERVED maps are direct wired sources
>> and generic allocation/programming of crossbar should be avoided.
>>
>> Signed-off-by: Nishanth Menon <nm@ti.com>
>> Signed-off-by: Sricharan R <r.sricharan@ti.com>
>> ---
>> .../devicetree/bindings/arm/omap/crossbar.txt | 12 ++++++++++--
>> drivers/irqchip/irq-crossbar.c | 20 ++++++++++++++++++--
>> 2 files changed, 28 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
>> index 8210ea4..438ccab 100644
>> --- a/Documentation/devicetree/bindings/arm/omap/crossbar.txt
>> +++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
>> @@ -42,8 +42,10 @@ Documentation/devicetree/bindings/arm/gic.txt for further details.
>>
>> An interrupt consumer on an SoC using crossbar will use:
>> interrupts = <GIC_SPI request_number interrupt_level>
>> -request number shall be between 0 to that described by
>> -"ti,max-crossbar-sources"
>> +When the request number is between 0 to that described by
>> +"ti,max-crossbar-sources", it is assumed to be a crossbar mapping. If the
>> +request_number is greater than "ti,max-crossbar-sources", then it is mapped as a
>> +quirky hardware mapping direct to GIC.
>>
>> Example:
>> device_x@0x4a023000 {
>> @@ -51,3 +53,9 @@ Example:
>> interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
>> ...
>> };
>> +
>> + device_y@0x4a033000 {
>> + /* Direct mapped GIC SPI 1 used */
>> + interrupts = <GIC_SPI 401 IRQ_TYPE_LEVEL_HIGH>;
>
> Ideally, I'd like to see a macro here so that it's clear that we crossed
> a magic threshold. eg:
>
> #define MAX_SOURCES 400
> #define DIRECT_IRQ(irq) (MAX_SOURCES + irq)
> ...
> interrupts = <GIC_SPI DIRECT_IRQ(1) IRQ_TYPE_LEVEL_HIGH>;
>
> and, then:
>
> ti,max-crossbar-sources = <MAX_SOURCES>;
>
Ok, thats more good for readability. Will add that macro then.
Regards,
Sricharan
WARNING: multiple messages have this Message-ID (diff)
From: r.sricharan@ti.com (Sricharan R)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V3 16/16] irqchip: crossbar: allow for quirky hardware with direct hardwiring of GIC
Date: Mon, 23 Jun 2014 12:52:44 +0530 [thread overview]
Message-ID: <53A7D5C4.6090201@ti.com> (raw)
In-Reply-To: <20140621025723.GF21711@titan.lakedaemon.net>
Hi Jason,
On Saturday 21 June 2014 08:27 AM, Jason Cooper wrote:
> On Mon, Jun 16, 2014 at 04:53:16PM +0530, Sricharan R wrote:
>> From: Nishanth Menon <nm@ti.com>
>>
>> On certain platforms such as DRA7, SPIs 0, 1, 2, 3, 5, 6, 10, 131,
>> 132, 133 are direct wired to hardware blocks bypassing crossbar.
>> This quirky implementation is *NOT* supposed to be the expectation
>> of crossbar hardware usage. However, these are already marked in our
>> description of the hardware with SKIP and RESERVED where appropriate.
>>
>> Unfortunately, we need to be able to refer to these hardwired IRQs.
>> So, to request these, crossbar driver can use the existing information
>> from it's table that these SKIP/RESERVED maps are direct wired sources
>> and generic allocation/programming of crossbar should be avoided.
>>
>> Signed-off-by: Nishanth Menon <nm@ti.com>
>> Signed-off-by: Sricharan R <r.sricharan@ti.com>
>> ---
>> .../devicetree/bindings/arm/omap/crossbar.txt | 12 ++++++++++--
>> drivers/irqchip/irq-crossbar.c | 20 ++++++++++++++++++--
>> 2 files changed, 28 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
>> index 8210ea4..438ccab 100644
>> --- a/Documentation/devicetree/bindings/arm/omap/crossbar.txt
>> +++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
>> @@ -42,8 +42,10 @@ Documentation/devicetree/bindings/arm/gic.txt for further details.
>>
>> An interrupt consumer on an SoC using crossbar will use:
>> interrupts = <GIC_SPI request_number interrupt_level>
>> -request number shall be between 0 to that described by
>> -"ti,max-crossbar-sources"
>> +When the request number is between 0 to that described by
>> +"ti,max-crossbar-sources", it is assumed to be a crossbar mapping. If the
>> +request_number is greater than "ti,max-crossbar-sources", then it is mapped as a
>> +quirky hardware mapping direct to GIC.
>>
>> Example:
>> device_x at 0x4a023000 {
>> @@ -51,3 +53,9 @@ Example:
>> interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
>> ...
>> };
>> +
>> + device_y at 0x4a033000 {
>> + /* Direct mapped GIC SPI 1 used */
>> + interrupts = <GIC_SPI 401 IRQ_TYPE_LEVEL_HIGH>;
>
> Ideally, I'd like to see a macro here so that it's clear that we crossed
> a magic threshold. eg:
>
> #define MAX_SOURCES 400
> #define DIRECT_IRQ(irq) (MAX_SOURCES + irq)
> ...
> interrupts = <GIC_SPI DIRECT_IRQ(1) IRQ_TYPE_LEVEL_HIGH>;
>
> and, then:
>
> ti,max-crossbar-sources = <MAX_SOURCES>;
>
Ok, thats more good for readability. Will add that macro then.
Regards,
Sricharan
WARNING: multiple messages have this Message-ID (diff)
From: Sricharan R <r.sricharan@ti.com>
To: Jason Cooper <jason@lakedaemon.net>
Cc: <linux-omap@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<tony@atomide.com>, <santosh.shilimkar@ti.com>, <nm@ti.com>,
<rnayak@ti.com>, <linux@arm.linux.org.uk>, <tglx@linutronix.de>,
<joe@perches.com>
Subject: Re: [PATCH V3 16/16] irqchip: crossbar: allow for quirky hardware with direct hardwiring of GIC
Date: Mon, 23 Jun 2014 12:52:44 +0530 [thread overview]
Message-ID: <53A7D5C4.6090201@ti.com> (raw)
In-Reply-To: <20140621025723.GF21711@titan.lakedaemon.net>
Hi Jason,
On Saturday 21 June 2014 08:27 AM, Jason Cooper wrote:
> On Mon, Jun 16, 2014 at 04:53:16PM +0530, Sricharan R wrote:
>> From: Nishanth Menon <nm@ti.com>
>>
>> On certain platforms such as DRA7, SPIs 0, 1, 2, 3, 5, 6, 10, 131,
>> 132, 133 are direct wired to hardware blocks bypassing crossbar.
>> This quirky implementation is *NOT* supposed to be the expectation
>> of crossbar hardware usage. However, these are already marked in our
>> description of the hardware with SKIP and RESERVED where appropriate.
>>
>> Unfortunately, we need to be able to refer to these hardwired IRQs.
>> So, to request these, crossbar driver can use the existing information
>> from it's table that these SKIP/RESERVED maps are direct wired sources
>> and generic allocation/programming of crossbar should be avoided.
>>
>> Signed-off-by: Nishanth Menon <nm@ti.com>
>> Signed-off-by: Sricharan R <r.sricharan@ti.com>
>> ---
>> .../devicetree/bindings/arm/omap/crossbar.txt | 12 ++++++++++--
>> drivers/irqchip/irq-crossbar.c | 20 ++++++++++++++++++--
>> 2 files changed, 28 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
>> index 8210ea4..438ccab 100644
>> --- a/Documentation/devicetree/bindings/arm/omap/crossbar.txt
>> +++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
>> @@ -42,8 +42,10 @@ Documentation/devicetree/bindings/arm/gic.txt for further details.
>>
>> An interrupt consumer on an SoC using crossbar will use:
>> interrupts = <GIC_SPI request_number interrupt_level>
>> -request number shall be between 0 to that described by
>> -"ti,max-crossbar-sources"
>> +When the request number is between 0 to that described by
>> +"ti,max-crossbar-sources", it is assumed to be a crossbar mapping. If the
>> +request_number is greater than "ti,max-crossbar-sources", then it is mapped as a
>> +quirky hardware mapping direct to GIC.
>>
>> Example:
>> device_x@0x4a023000 {
>> @@ -51,3 +53,9 @@ Example:
>> interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
>> ...
>> };
>> +
>> + device_y@0x4a033000 {
>> + /* Direct mapped GIC SPI 1 used */
>> + interrupts = <GIC_SPI 401 IRQ_TYPE_LEVEL_HIGH>;
>
> Ideally, I'd like to see a macro here so that it's clear that we crossed
> a magic threshold. eg:
>
> #define MAX_SOURCES 400
> #define DIRECT_IRQ(irq) (MAX_SOURCES + irq)
> ...
> interrupts = <GIC_SPI DIRECT_IRQ(1) IRQ_TYPE_LEVEL_HIGH>;
>
> and, then:
>
> ti,max-crossbar-sources = <MAX_SOURCES>;
>
Ok, thats more good for readability. Will add that macro then.
Regards,
Sricharan
next prev parent reply other threads:[~2014-06-23 7:22 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-16 11:23 [PATCH V3 00/16] irqchip: crossbar: driver fixes Sricharan R
2014-06-16 11:23 ` Sricharan R
2014-06-16 11:23 ` Sricharan R
2014-06-16 11:23 ` [PATCH V3 01/16] irqchip: crossbar: dont use '0' to mark reserved interrupts Sricharan R
2014-06-16 11:23 ` Sricharan R
2014-06-16 11:23 ` Sricharan R
2014-06-16 11:23 ` [PATCH V3 02/16] irqchip: crossbar: check for premapped crossbar before allocating Sricharan R
2014-06-16 11:23 ` Sricharan R
2014-06-16 11:23 ` Sricharan R
2014-06-16 11:23 ` [PATCH V3 03/16] irqchip: crossbar: introduce ti,irqs-skip to skip Sricharan R
2014-06-16 11:23 ` Sricharan R
2014-06-16 11:23 ` Sricharan R
2014-06-21 2:33 ` Jason Cooper
2014-06-21 2:33 ` Jason Cooper
[not found] ` <20140621023302.GE21711-u4khhh1J0LxI1Ri9qeTfzeTW4wlIGRCZ@public.gmane.org>
2014-06-23 7:20 ` Sricharan R
2014-06-23 7:20 ` Sricharan R
2014-06-23 7:20 ` Sricharan R
2014-06-16 11:23 ` [PATCH V3 04/16] irqchip: crossbar: initialise the crossbar with a safe value Sricharan R
2014-06-16 11:23 ` Sricharan R
2014-06-16 11:23 ` Sricharan R
2014-06-16 11:23 ` [PATCH V3 05/16] irqchip: crossbar: change allocation logic by reversing search for free irqs Sricharan R
2014-06-16 11:23 ` Sricharan R
2014-06-16 11:23 ` Sricharan R
2014-06-16 11:23 ` [PATCH V3 06/16] irqchip: crossbar: remove IS_ERR_VALUE check Sricharan R
2014-06-16 11:23 ` Sricharan R
2014-06-16 11:23 ` Sricharan R
2014-06-16 11:23 ` [PATCH V3 07/16] irqchip: crossbar: fix sparse and checkpatch warnings Sricharan R
2014-06-16 11:23 ` Sricharan R
2014-06-16 11:23 ` Sricharan R
2014-06-16 11:23 ` [PATCH V3 08/16] irqchip: crossbar: fix kerneldoc warning Sricharan R
2014-06-16 11:23 ` Sricharan R
2014-06-16 11:23 ` Sricharan R
2014-06-16 11:23 ` [PATCH V3 09/16] irqchip: crossbar: return proper error value Sricharan R
2014-06-16 11:23 ` Sricharan R
2014-06-16 11:23 ` Sricharan R
2014-06-16 11:23 ` [PATCH V3 10/16] irqchip: crossbar: change the goto naming Sricharan R
2014-06-16 11:23 ` Sricharan R
2014-06-16 11:23 ` Sricharan R
2014-06-16 11:23 ` [PATCH V3 11/16] irqchip: crossbar: set cb pointer to null in case of error Sricharan R
2014-06-16 11:23 ` Sricharan R
2014-06-16 11:23 ` Sricharan R
2014-06-16 11:23 ` [PATCH V3 12/16] irqchip: crossbar: add kerneldoc for crossbar_domain_unmap callback Sricharan R
2014-06-16 11:23 ` Sricharan R
2014-06-16 11:23 ` Sricharan R
2014-06-16 11:23 ` [PATCH V3 13/16] irqchip: crossbar: introduce ti,max-crossbar-sources to identify valid crossbar mapping Sricharan R
2014-06-16 11:23 ` Sricharan R
2014-06-16 11:23 ` [PATCH V3 13/16] irqchip: crossbar: introduce ti, max-crossbar-sources " Sricharan R
2014-06-16 11:23 ` [PATCH V3 14/16] irqchip: crossbar: introduce centralized check for crossbar write Sricharan R
2014-06-16 11:23 ` Sricharan R
2014-06-16 11:23 ` Sricharan R
2014-06-16 11:23 ` [PATCH V3 15/16] documentation: dt: omap: crossbar: add description for interrupt consumer Sricharan R
2014-06-16 11:23 ` Sricharan R
2014-06-16 11:23 ` Sricharan R
2014-06-16 11:23 ` [PATCH V3 16/16] irqchip: crossbar: allow for quirky hardware with direct hardwiring of GIC Sricharan R
2014-06-16 11:23 ` Sricharan R
2014-06-16 11:23 ` Sricharan R
2014-06-21 2:57 ` Jason Cooper
2014-06-21 2:57 ` Jason Cooper
2014-06-23 7:22 ` Sricharan R [this message]
2014-06-23 7:22 ` Sricharan R
2014-06-23 7:22 ` Sricharan R
[not found] ` <1402917796-31574-1-git-send-email-r.sricharan-l0cyMroinI0@public.gmane.org>
2014-06-16 14:04 ` [PATCH V3 00/16] irqchip: crossbar: driver fixes Santosh Shilimkar
2014-06-16 14:04 ` Santosh Shilimkar
2014-06-16 14:04 ` Santosh Shilimkar
2014-06-17 8:54 ` Sricharan R
2014-06-17 8:54 ` Sricharan R
2014-06-17 8:54 ` Sricharan R
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=53A7D5C4.6090201@ti.com \
--to=r.sricharan@ti.com \
--cc=devicetree@vger.kernel.org \
--cc=jason@lakedaemon.net \
--cc=joe@perches.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=nm@ti.com \
--cc=rnayak@ti.com \
--cc=santosh.shilimkar@ti.com \
--cc=tglx@linutronix.de \
--cc=tony@atomide.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 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.