Message-ID: <51EFFBE1.4090505@ti.com>
Date:	Wed, 24 Jul 2013 11:08:01 -0500
From:	Nishanth Menon <nm@...com>
To:	Santosh Shilimkar <santosh.shilimkar@...com>
CC:	Sricharan R <r.sricharan@...com>,
	Linus Walleij <linus.walleij@...aro.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devicetree-discuss@...ts.ozlabs.org" 
	<devicetree-discuss@...ts.ozlabs.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Linux-OMAP <linux-omap@...r.kernel.org>,
	ext Tony Lindgren <tony@...mide.com>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	Rajendra Nayak <rnayak@...com>, Felipe Balbi <balbi@...com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Grant Likely <grant.likely@...retlab.ca>
Subject: Re: [PATCH 1/3] misc: Add crossbar driver

On 07/22/2013 11:23 AM, Santosh Shilimkar wrote:
> To summaries it again, what I understood from Sricharan's proposal,
>
> - Setup all the routing at cross-bar probe so that kernel continue to
> work like normal IRQ controller with cross-bar scope vanishes once
> the routing is done. Cross-bar does this before any of the devices
> are created.
> - Something similar needs to happen for DMA lines as well or for any
> other event routing in future.
> - Cross-bar callbacks for device drivers for error paths.
> (Sricharan, you have to drop these because it doesn't bring any
> functionality and rather can create a side effects of drivers
> getting polluted.)
Ack.

>
> The concern raised on above was instead of fixing the routing at DT
> statically, doing at the driver probes where the loop-up for IRQ or DMA
> lines should happen in background transparently on drivers call of
> request_irq/request_dma_channel etc with cross-bar number as
> an input to it. Though it will be nice to have
> such feature, it doesn't bring anything special and brings the
> notion of these APIs which expect that you know what IRQ and DMA
> lines you want while calling these.
Unfortunately, we do have a constraint without allocating dynamic IRQs - 
what IP instances should hwmod and dts contain?

If we go with current series of patches[1] [2] for DRA7 dts which 
assumes default mapping, hence, uart7-10, GPTimers12-16 dont have 
default irq - hence they dont exist in dts etc.

How would we like to support those with pinctrl approach?

>
> Note that mux inputs are pretty much fixed. Its his connection
> to IRQ controller or DMA controller is what needs to be programmed.
> So scope is pretty much limited. I felt this requirement is pretty
> similar to pin-mux and hence thought of it as a viable option.
>
> Having said all of above, if there is a better alternative than
> enhanced pin-mux we surely can do that.
We could look at it as a signal mux problem as this thread suggests OR 
look at it as interrupt distribution problem (which is how it looks like 
at the face of it). That said, maybe a intermediate pinctrl approach 
might be more pragmatic and less theoretically flexible.
an option might be to "statically allocate" default number of interrupts 
to a domain - example:
* GIC IRQ 72->78 allotted to UARTs
* pinctrl mapping provided for those but only 6 can be used (rest are 
marked status="disabled" as default) at any given time (choice of 
pinctrl option determines GIC interrupt line to use)
* All modules will have a pinctrl definition to have a mapping - to 
avoid bootloader overriding default cross bar setting in ways 
un-expected by kernel.

Does that sound fair trade off?

[1] http://marc.info/?l=linux-omap&m=137335524702155&w=2
[2] http://marc.info/?l=linux-omap&m=137335522802144&w=2
-- 
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists