From: nm@ti.com (Nishanth Menon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/5] irqchip: crossbar: Skip some irqs from getting mapped to crossbar
Date: Fri, 9 May 2014 09:00:52 -0500 [thread overview]
Message-ID: <536CDF94.7000900@ti.com> (raw)
In-Reply-To: <536CDBDF.10600@ti.com>
On 05/09/2014 08:45 AM, Santosh Shilimkar wrote:
> On Friday 09 May 2014 09:36 AM, Nishanth Menon wrote:
>> On 05/09/2014 08:27 AM, Santosh Shilimkar wrote:
>>> On Friday 09 May 2014 08:54 AM, Nishanth Menon wrote:
>>>> On 05/08/2014 11:22 PM, Joel Fernandes wrote:
>>>>> On Thu, May 8, 2014 at 7:25 PM, Santosh Shilimkar
>>>>> <santosh.shilimkar@ti.com> wrote:
>>>> [...]
>>>>> Ok, thanks for pointing to the post.
>>>>>
>>>>
>>>>
>>>> Yep - thanks Santosh for clarifying this. Now, we still have the
>>>> issues that I pointed out in [1] - without resolving which, we should
>>>> not enable crossbar for dra74x/72x.
>>>>
>>>> A. taking example of PMU
>>>> interrupts = <GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH>
>>>> this wont work. instead the crossbar driver needs some sort of a hint
>>>> to know that it should not map these on crossbar register instead
>>>> assign GIC mapping directly.
>>>>
>>>> I propose doing the following
>>>> #define GIC_CROSSBAR_PASSTHROUGH(irq_no) ((irq_no) | (0x1 << 31))
>>>>
>>>> and dts will define the following:
>>>> interrupts = <GIC_SPI GIC_CROSSBAR_PASSTHROUGH(131) IRQ_TYPE_LEVEL_HIGH>
>>>>
>>>> This will also work for the other cases (B.2, B.3)
>>>>
>>>> For B.2: L3_APP_IRQ:
>>>> instead of:
>>>> interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>
>>>> we do:
>>>> interrupts = <GIC_SPI GIC_CROSSBAR_PASSTHROUGH(10) IRQ_TYPE_LEVEL_HIGH>
>>>>
>>>> For B.3: NMI
>>>> interrupts = <GIC_SPI GIC_CROSSBAR_PASSTHROUGH(133) IRQ_TYPE_LEVEL_HIGH>
>>>>
>>> We can't do add a flag to generic interrupt controller flags since its
>>> very specific to cross-bar.
>>>
>>>> xlate is easy ->
>>>>
>>>> diff --git a/drivers/irqchip/irq-crossbar.c
>>>> b/drivers/irqchip/irq-crossbar.c
>>>> index de021638..fd09ab4 100644
>>>> --- a/drivers/irqchip/irq-crossbar.c
>>>> +++ b/drivers/irqchip/irq-crossbar.c
>>>> @@ -112,6 +112,10 @@ static int crossbar_domain_xlate(struct
>>>> irq_domain *d,
>>>> {
>>>> unsigned long ret;
>>>>
>>>> + /* Check to see if direct GIC mapping is required */
>>>> + if (intspec[1] & BIT(31))
>>>> + return intspec[1] & ~BIT[31];
>>>> +
>>>> ret = get_prev_map_irq(intspec[1]);
>>>> if (!IS_ERR_VALUE(ret))
>>>> goto found;
>>>>
>>>> But then, crossbar_domain_map and crossbar_domain_unmap need hints as
>>>> well to know that there is no corresponding crossbar registers.
>>>> Have'nt thought through that yet. Looking to hear about opinions here.
>>>>
>>>>
>>> May be we need additional property like reserved to take care of 1:1
>>> map.
>>>
>>> ti,irqs-direct-map = <131 132>;
>>>
>> We already have equivalents for these -> reserved and skip. Problem is
>> how does crossbar driver know the difference between direct maps and
>> crossbar value?
>>
>> 6 is one of those reserved ones. dts for a device says:
>> interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>
>>
>>
>> Now, xlate gets intspec[1] = 6. 6 is valid crossbar number
>> PRM_IRQ_MPU, however GIC 6 is mapped to WD_TIMER_MPU_C1_IRQ_WARN ->
>> you need to be able to get a hint that this is direct mapping dts
>> intended.
>>
>> in the "6" example:
>>
>> How do i get PRM_IRQ_MPU?
>> interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>
>>
>> How do I get WD_TIMER_MPU_C1_IRQ_WARN?
>> interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH> ????? - that wont work as
>> crossbar driver thinks it is crossbar 6 (PRM_IRQ_MPU)
>>
> Looks like I am missing something. Is the issue because of SPI offset (32)
> which makes above confusion ?
The way we modelled crossbar is that the irqchip is GIC and routable
mapper is crossbar - which makes sense. now for every "interrupts"
description we try to find a map using the crossbar driver as the irq
framework rightly identifies that peripheral interrupts are routable
and crossbar driver is the guy who knows how to map these to a proper
GIC interrupt number. So far, we are good.
Now the trouble starts when our hardware description in dts assumes
that every peripheral interrupt is a routable interrupt - as this
thread describes - that is NOT the case.
Now the question is how do you differentiate?
interrupts = <GIC_SPI Number Level>
GIC_SPI is correct since we are attempting to describe the SPI
interrupt (offset what ever it is, is a NOP from conceptual discussion).
Level is fine as well.
Number: what does this indicate? crossbar number is what we have
assumed so far. however, then you loose the ability to describe
interrupts on GIC SPI which dont have crossbar interrupts.
Question is how do we differentiate between the two?
--
Regards,
Nishanth Menon
next prev parent reply other threads:[~2014-05-09 14:00 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-05 14:18 [PATCH 0/5] irqchip/dra7: crossbar bug fixes Sricharan R
2014-05-05 14:18 ` [PATCH 1/5] irqchip: crossbar: dont use '0' to mark reserved interrupts Sricharan R
2014-05-05 14:18 ` [PATCH 2/5] irqchip: crossbar: check for premapped crossbar before allocating Sricharan R
2014-05-05 14:18 ` [PATCH 3/5] irqchip: crossbar: Skip some irqs from getting mapped to crossbar Sricharan R
2014-05-08 19:24 ` Joel Fernandes
2014-05-08 20:37 ` Nishanth Menon
2014-05-08 22:43 ` Joel Fernandes
2014-05-08 23:05 ` Santosh Shilimkar
2014-05-09 0:13 ` Joel Fernandes
2014-05-09 0:25 ` Santosh Shilimkar
2014-05-09 4:22 ` Joel Fernandes
2014-05-09 12:54 ` Nishanth Menon
2014-05-09 13:27 ` Santosh Shilimkar
2014-05-09 13:36 ` Nishanth Menon
2014-05-09 13:45 ` Santosh Shilimkar
2014-05-09 14:00 ` Nishanth Menon [this message]
2014-05-09 14:13 ` Joel Fernandes
2014-05-09 20:41 ` Santosh Shilimkar
2014-05-09 13:43 ` Joel Fernandes
2014-05-09 13:36 ` Joel Fernandes
2014-05-09 13:37 ` Joel Fernandes
2014-05-09 13:38 ` Nishanth Menon
2014-05-05 14:18 ` [PATCH 4/5] irqchip: crossbar: Initialise the crossbar with a safe value Sricharan R
2014-05-05 14:18 ` [PATCH 5/5] irqchip: crossbar: Change allocation logic by reversing search for free irqs Sricharan R
2014-05-05 18:10 ` [PATCH 0/5] irqchip/dra7: crossbar bug fixes Darren Etheridge
2014-05-06 0:48 ` Tony Lindgren
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=536CDF94.7000900@ti.com \
--to=nm@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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).