On Thu, Jul 18, 2013 at 6:39 PM, Santosh Shilimkar
<santosh.shilimkar@xxxxxx> wrote:
> On Thursday 18 July 2013 02:56 PM, Nishanth Menon wrote:
>> On 07/18/2013 11:43 AM, Sricharan R wrote:
>>> Some socs have a large number of interrupts/dma requests to service
>>> the needs of its many peripherals and subsystems. All of the
>>> requests lines from the subsystems are not needed at the same
>>> time, so they have to be muxed to the controllers appropriately.
>>> In such places a interrupt/dma controllers are preceded by an
>>> IRQ/DMA CROSSBAR that provides flexibility in muxing the device
>>> requests to the controller inputs.
>>>
>>> The Peripheral irq/dma requests are connected to one crossbar's input
>>> and the output of the crossbar is connected to controller's input
>>> line. On POR, there are some mappings which are done by default.
>>> Those peripherals which do not have a mapping on POR, should be configured
>>> to route its requests using the crossbar.
>>>
>>> The drivers identifies every controller's crossbar as individual devices.
>>> The mappings can be specified from the DT crossbar nodes and those gets mapped
>>> during the crossbar device's probe. The mappings can also be specified by adding
>>> the crossbar lines to the peripheral device nodes and map it with
>>> crossbar_map/unmap apis.
>>>
>>> Signed-off-by: Sricharan R <r.sricharan@xxxxxx>
>>> ---
>>> .../devicetree/bindings/arm/omap/crossbar.txt | 24 ++
>>> drivers/misc/Kconfig | 8 +
>>> drivers/misc/Makefile | 1 +
>>> drivers/misc/crossbar.c | 258 ++++++++++++++++++++
>>> include/linux/crossbar.h | 71 ++++++
>>> 5 files changed, 362 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/arm/omap/crossbar.txt
>>> create mode 100644 drivers/misc/crossbar.c
>>> create mode 100644 include/linux/crossbar.h
>>>
>>> diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
>>> new file mode 100644
>>> index 0000000..02a8a28
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
>>> @@ -0,0 +1,24 @@
>>> +* TI - IRQ/DMA Crossbar
>>> +
>>> +This version is an implementation of the Crossbar IRQ/DMA IP
>>> +
>>> +Required properties:
>>> +- compatible : Should be "ti,dra-crossbar"
>>> +- crossbar-name: Name of the controller to which crossbar output is routed
>>> +- reg: Contains crossbar register address range
>>> +- reg-width: Represents the width of the individual registers
>>> +- crossbar-lines: Default mappings.Should contain the crossbar-name
>>> + device name, int/dma request number, crossbar number,
>>> + register offset in the same order.
>>> +
>>> +Examples:
>>> + crossbar_mpu: mpuirq@4a002a48 {
>>> + compatible = "crossbar";
>>> + crossbar-name = "mpu-irq";
>>> + reg = <0x4a002a48 0x0130>;
>>> + reg-width = <16>;
>>> + crossbar-lines = "mpu-irq", "rtc-ss-alarm", <0x9f 0xd9 0x12c>,
>>> + "mpu-irq", "mcasp3-arevt", <0x9e 0x96 0x12a>,
>>> + "mpu-irq", "mcasp3-axevt", <0x9d 0x97 0x128>;
>>> + };
>>
>> I carry forward my TI internal objection to this approach:
>>
>> NAK.
>>
>> DRA7 uses a cross bar to map a line to GIC interrupt. Flow of interrupt is as follows:
>> hardware IP block -interrupt line-> IRQ Cross bar -> GIC IRQ line --> MPU IRQ.
>>
>>
>> What we have done today for DRA is to provide IRQ numbers as direct maps from hardware IP block to GIC based on default IRQ cross bar mapping.
>>
>> 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.
>>
>> Now, think of a product that wants to use UART10 instead of UART1, SoC design allows you do that by doing a remapping of GIC interrupt to UART10 - which is awesome.
>>
>> Option 1: u-boot/bootloader
>> mw.l IRQ_CROSSBAR_address with value to map uart10 to GIC IRQ for UART1,
>>
>> Option 2: in kernel do a raw_writel version of option 1.
>> This patch does option 1 in kernel in a "fancy way" - why the heck would I want to do that when u-boot allows me to do the same thing in uEnv.txt
>>
>> Option 3: map GIC interrupt to IRQ CROSS bar dynamically.
>> a) Allows us to define every single IP available on DRA7 SoC.
>> b) GIC allocation happens dynamically
>> c) allow products use IPs as needed.
>>
>> Sorry, Conceptually option 3 is the right approach in my view.
>> instead of doing
>> uart1: serial@4806a000 {
>> <snip>
>> + interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
>>
>> we should be able to do the following:
>> uart1: serial@4806a000 {
>> <snip>
>> + interrupts = <TI_IRQ_CROSSBAR 192 IRQ_TYPE_LEVEL_HIGH>;
>>
>> and not worry about the GIC interrupt number used
>>
>>
> Since the cross-bar is not limited t0 IRQ lines and applicable for
> DMA request lines as well, making it IRQ chip doesn't make sense. Its
> not typical pin control functionality either but at least that framework
> is much closer to consider as an option.
The core concept is that this is a trivial mapping problem and if can
extrapolate pinctrl to be mapping for SoC internal signals, oh great!
pinctrl solved a problem where we are not absolutely sure how to
reallocate SoC *external* pins to board interface. pinctrl works in
more complex world, each SoC pinout has A options, but not all B SoC
signals can or will routed there - in fact, inside one single SoC
family, there never was a pattern even as it all depended on how the
board manufacturer wanted to do it - and yep, it was easy - a signal
just had limited number of options it could go to review and pinctrl
options to do that was simple as well!
The problem here IMHO is different. it is a simple X->Y mapping, where
X > Y, but any of X can be mapped to any of Y - so, now with a static
map, you need be sure that you do not map double even by mistake - so
what ever number of GIC mappings need to be evaluated always every
time we do a static map change to ensure no conflicts w.r.t board
usage etc. Doable? sure! Right way to solve a simple X->Y mapping
problem? I personally don't think so.
<rant>
Now, if we want to force every single DRA7 product board designers and
s/w board support guy to consider how the DRA internal signals are
mapped using dts - yes, we are proposing to solve the problem of a
trivial resource allocation problem with a framework meant to handle
much more complex muxing problem and ensured that all DRA7 product
guys will wonder "what the heck were these guys thinking"?
</rant>
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
