From: Sricharan R <r.sricharan@ti.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Nishanth Menon <nm@ti.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"devicetree-discuss@lists.ozlabs.org"
<devicetree-discuss@lists.ozlabs.org>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Linux-OMAP <linux-omap@vger.kernel.org>,
ext Tony Lindgren <tony@atomide.com>,
Russell King - ARM Linux <linux@arm.linux.org.uk>,
Rajendra Nayak <rnayak@ti.com>, Felipe Balbi <balbi@ti.com>,
Thomas Gleixner <tglx@linutronix.de>,
Grant Likely <grant.likely@secretlab.ca>
Subject: Re: [PATCH 1/3] misc: Add crossbar driver
Date: Mon, 22 Jul 2013 17:50:21 +0530 [thread overview]
Message-ID: <51ED2385.60108@ti.com> (raw)
In-Reply-To: <CACRpkdY3nQaWimTwB-Zt-8+Q_KZr8a0rpB1SUQq=AuoG4bAYnQ@mail.gmail.com>
Hi Linus,
On Sunday 21 July 2013 10:19 PM, Linus Walleij wrote:
> On Thu, Jul 18, 2013 at 8:56 PM, Nishanth Menon <nm@ti.com> wrote:
>
>> I carry forward my TI internal objection to this approach:
> It is actually a very good sign of FOSS-maturity that you as a company
> take unresolved architectural issues to the community. Kudos!
>
>> Lets see what happens as a result of this:
>>
>> https://patchwork.kernel.org/patch/2825148/ (introducing DTS for DRA7)
>> uart1 to uart6 is defined. while in fact 10 uarts exist on IP block.
>> uart1: serial@4806a000 {
>> <snip>
>> + interrupts = <0 72 0x4>;
>> Assumes that GIC interrupt by default mapping used.
> So introducing this inbetween the GIC lines and its actual device IRQ
> lines inevitably means that the GIC three-cell concept is completely
> ill-devised to handle this.
>
> For routing IRQs, I think the proper solution would be to use a
> cascaded struct irqchip, which in turn contains an irqdomain
> translation to remux the signal onto the GIC inputs.
>
> I.e. the interrupt-controller given to that serial would be the
> crossbar irqchip, and that in turn will hog and allocate apropriate
> lines from the gic to it would probably itself list *all* the IRQs
> of the GIC as "its" IRQs.
>
> We already have plenty of cascading irqchips such as GPIO
> controller providing IRQs, just that they only multiplex on a
> single GIC line instead of the whole lot.
>
> Mock example:
>
> intc: interrupt-controller@0 {
> compatible = "arm,cortex-a9-gic";
> #interrupt-cells = <3>;
> #address-cells = <1>;
> interrupt-controller;
> reg = ...;
> };
>
> crossbar: crossbar@0 {
> compatible = "...";
> interrupt-controller;
> #interrupt-cells = <1>;
> interrupt-parent = <&intc>;
> interrupts = <0 0 IRQ_TYPE_LEVEL_HIGH>,
> <0 1 IRQ_TYPE_LEVEL_HIGH>,
> <0 2 IRQ_TYPE_LEVEL_HIGH>,
> ....
> <0 n IRQ_TYPE_LEVEL_HIGH>;
> };
>
> uart0: serial@0 {
> compatible = "...";
> interrupt-parent = <&crossbar>;
> interrupts = <1234>;
> };
>
> Maybe the interrupts provided from crossbar cannot even be
> specified by a number, maybe a line name need to be used
> or so. I don't know the particulars.
>
> Whether this as a whole is a good idea, I don't know,
> but you would have to go about it something like this.
>
> What happens if there is no line to mux in a certain IRQ?
Thanks for this.
Was thinking of a similar kind of approach with irqchip.
But then, there was a GAP since crossbar does not have an irq unlike
other irqchips. But as you said this can be done by setting the crossbar
to map and receive the GIC interrupts and then direct to devices.
Only thing is, this is fine for IRQs, and something different has to be done
for DMA crossbars again. Also when we allocate dynamically here,
finding out a irq line when there is no free line is a question.
With the other approach of using/extending the pinctrl framework that you
gave, it is good to handle both irqs/dma. I looked at the other example in
drivers/dma/amba-pl08x.c and i see that data is getting populated and passed
from the platform. I initially started with something similar, where the data
was passed statically from DT and a driver to use that. So now it looks good
to extend the pinctrl fw. I will try a approach for that first and see how it looks.
Regards,
Sricharan
next prev parent reply other threads:[~2013-07-22 12:20 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-18 16:43 [PATCH 0/3] Add crossbar driver Sricharan R
2013-07-18 16:43 ` [PATCH 1/3] misc: " Sricharan R
2013-07-18 16:55 ` Joe Perches
2013-07-18 18:25 ` Felipe Balbi
2013-07-21 16:33 ` Linus Walleij
2013-07-18 18:56 ` Nishanth Menon
2013-07-18 23:39 ` Santosh Shilimkar
[not found] ` <51E87C98.5030001-l0cyMroinI0@public.gmane.org>
2013-07-19 0:13 ` Nishanth Menon
2013-07-19 10:48 ` Sricharan R
2013-07-19 7:17 ` Tony Lindgren
2013-07-19 10:48 ` Sricharan R
[not found] ` <51E83A4F.5080904-l0cyMroinI0@public.gmane.org>
2013-07-21 16:49 ` Linus Walleij
2013-07-22 12:20 ` Sricharan R [this message]
2013-07-22 16:23 ` Santosh Shilimkar
2013-07-24 16:08 ` Nishanth Menon
2013-07-24 16:38 ` Santosh Shilimkar
2013-07-24 16:47 ` Nishanth Menon
2013-07-24 18:43 ` Sricharan R
2013-07-24 18:51 ` Nishanth Menon
2013-07-24 18:59 ` Santosh Shilimkar
2013-08-13 8:10 ` Tony Lindgren
2013-08-13 9:56 ` Sricharan R
2013-08-13 13:29 ` Santosh Shilimkar
2013-08-15 20:01 ` Linus Walleij
2013-08-15 20:26 ` Santosh Shilimkar
2013-08-15 20:51 ` Linus Walleij
2013-08-15 21:14 ` Santosh Shilimkar
2013-08-21 21:10 ` Linus Walleij
2013-08-22 11:33 ` Sricharan R
2013-08-22 13:45 ` Santosh Shilimkar
2013-08-23 4:47 ` Rajendra Nayak
2013-08-23 6:11 ` Sricharan R
2013-08-23 6:17 ` Rajendra Nayak
2013-08-23 6:36 ` Sekhar Nori
2013-08-23 6:53 ` Sricharan R
2013-08-23 8:14 ` Sekhar Nori
2013-08-23 13:38 ` Santosh Shilimkar
2013-08-23 16:28 ` Sekhar Nori
2013-08-23 19:06 ` Linus Walleij
2013-08-23 19:44 ` Santosh Shilimkar
2013-08-13 13:28 ` Santosh Shilimkar
2013-08-14 7:27 ` Tony Lindgren
2013-07-18 16:43 ` [PATCH 2/3] ARM: dts: DRA: Add crossbar device binding Sricharan R
2013-07-18 19:04 ` Nishanth Menon
2013-07-18 16:43 ` [PATCH 3/3] ARM: DRA7xx: Enable crossbar driver for the soc 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=51ED2385.60108@ti.com \
--to=r.sricharan@ti.com \
--cc=balbi@ti.com \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=grant.likely@secretlab.ca \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.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=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 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).