| Message ID | 1374165830-6367-2-git-send-email-r.sricharan@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Thu, 2013-07-18 at 22:13 +0530, 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. [] > diff --git a/drivers/misc/crossbar.c b/drivers/misc/crossbar.c [] > +int crossbar_unmap(struct device_node *cbdev_node, unsigned index) [] > + list_for_each_entry(cbdev, &cb_devlist, node) { > + if (strcmp(cbdev->name, tmp.cb_name)) > + continue; [] > + dev_warn(cbdev->dev, > + "unmapped int_no %x mapped to cb %x\n", > + tmp.int_no, tmp.cb_no); > + return 0; [] > + dev_warn(cbdev->dev, "%s cb entry %d not found\n", > + __func__, tmp.cb_no); > + return -ENOENT; Why does this function always emit a dev_warn before return? Maybe the first should be dev_info? -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On Thu, Jul 18, 2013 at 10:13:48PM +0530, 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@ti.com> why isn't this done under pinctrl ? If all it does is mux DMA and IRQ request lines, it should be written as a pinctrl driver no ?
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@ti.com> > --- > .../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
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@ti.com> >> --- >> .../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. Actually its more of setting up the IRQ and DMA pins maps once at boot for a given SOC based on chosen configuration by the board. So I am leaning towards pinctrl as well. Just haven't thought enough about whether thats the best approach. CC'ing Linus W and Tony L whether we can use pinctrl framework for such an IP and if yes how ;-). Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Jul 18, 2013 at 6:39 PM, Santosh Shilimkar <santosh.shilimkar@ti.com> 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@ti.com> >>> --- >>> .../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-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> On Thursday 18 July 2013 02:56 PM, Nishanth Menon wrote: > > 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. > > Actually its more of setting up the IRQ and DMA pins maps once > at boot for a given SOC based on chosen configuration by the > board. So I am leaning towards pinctrl as well. Just haven't > thought enough about whether thats the best approach. > > CC'ing Linus W and Tony L whether we can use pinctrl framework > for such an IP and if yes how ;-). If it really muxes signals then using pinctrl seems logical. Especially if the registers are in the SCM block. It might be already possible to handle it already with pinctrl-single,bits for the muxing part. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On Friday 19 July 2013 05:43 AM, Nishanth Menon wrote: > On Thu, Jul 18, 2013 at 6:39 PM, Santosh Shilimkar > <santosh.shilimkar@ti.com> 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@ti.com> >>>> --- >>>> .../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> The problems to be solved with Dynamic mappings are 1) How to populate the drivers resources with the dynamically allocated data? This also means that all the drivers should be adapted to use crossbar before it does a request_irq. 2) How to get a dynamic line when there is no "free" line. That is how to decide runtime which one to replace. We can do this in dts because we know what peripheral is not used in a board. Regards, Sricharan -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Friday 19 July 2013 12:47 PM, Tony Lindgren wrote: >> On Thursday 18 July 2013 02:56 PM, Nishanth Menon wrote: >> >> 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. >> >> Actually its more of setting up the IRQ and DMA pins maps once >> at boot for a given SOC based on chosen configuration by the >> board. So I am leaning towards pinctrl as well. Just haven't >> thought enough about whether thats the best approach. >> >> CC'ing Linus W and Tony L whether we can use pinctrl framework >> for such an IP and if yes how ;-). > If it really muxes signals then using pinctrl seems logical. > Especially if the registers are in the SCM block. > > It might be already possible to handle it already with > pinctrl-single,bits for the muxing part. I also thought of using the pinctrl itself. But then i wanted to have the error handling as well, hence did this. Regards, Sricharan -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Jul 18, 2013 at 8:25 PM, Felipe Balbi <balbi@ti.com> wrote: >> 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. (...) > why isn't this done under pinctrl ? If all it does is mux DMA and IRQ > request lines, it should be written as a pinctrl driver no ? Actually I was thinking about this at one time when designing pinctrl, "what if we face the problem of arbitrary signal multiplexing?" However pin control is named for what it does and also controls things like the electrical properties of pins, biasing and so on which is ill applicable here. I would rather say that the pin multiplexing portions of pin control could be rewritten to use a more generic component dealing with arbitrary line multiplexing, i.e. something under /lib and maybe then move over some generic concepts such as the function to group mapping. The same concept as found here is found in the muxes used by drivers/dma/amba-pl08x.c back-ends on ARM reference hardware which is also multiplexing DMA signals. In that case we have done platform-specific hooks and implemented this in the per-machine platform code. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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? Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Monday 22 July 2013 08:20 AM, Sricharan R wrote: > 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. > Right. Thats the reason its not a typical chained IRQChip like GPIO, MFD PMIC etc etc. Those chips always has a primary interrupt line and then secondary interrupts which are kind of controlled at SW level(secondary logical IRQs) using some common registers. Cross-bar is just a dummy hardware. The only interesting part from IRQ chip or DMA subsystem is "request_irq" or "request_dma" look-up which happens at driver probe ideally should be transparent and then program the appropriate cross-bar mux for IRQ or DMA routing. The actual IRQ assertion reporting or ISR execution etc all has to be handled by primary IRQ controller since the cross-bar has no intelligence or IRQ controller like capability. 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.) 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. 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. Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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
On Wednesday 24 July 2013 12:08 PM, Nishanth Menon wrote: > 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? > The whole reason the cross-bar being there because all the peripherals IRQs can not me routed to the IRQ controller. So You pick up a configuration would like to support and stick to it. It will be good to specify all the peripheral devices but tsome of them might not have the IRQ/DMA lines associated with them because of limited slots on IRQ/DMA controller. >> >> 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). Its not interrupt distribution problem but rather setting up the signal routing which otherwise generally hardwired in SOC. Hence the pin-control analogy. Pinmux also lets you set many possible combinations but we pick one for a board design. > That said, maybe a intermediate pinctrl approach might be more pragmatic andless 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? This sounds better. That way we can get all the devices in the DT at least. Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 07/24/2013 11:38 AM, Santosh Shilimkar wrote: > On Wednesday 24 July 2013 12:08 PM, Nishanth Menon wrote: >> 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? > This sounds better. That way we can get all the devices in the DT at least. Fair enough - if Linus and Tony are still ok with this approach to the problem, seeing a patch series with the effect would be beneficial.
On Wednesday 24 July 2013 10:17 PM, Nishanth Menon wrote: > On 07/24/2013 11:38 AM, Santosh Shilimkar wrote: >> On Wednesday 24 July 2013 12:08 PM, Nishanth Menon wrote: >>> 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? >> This sounds better. That way we can get all the devices in the DT at least. > > Fair enough - if Linus and Tony are still ok with this approach to the problem, seeing a patch series with the effect would be beneficial. > Ok, i will use this idea of certain number interrupts to groups. Yes on DRA7XX, we have about 160 gic lines and 320 irq crossbar device inputs contending for it. 1:2 and fully arbitrary. But will we be really exhausting them ? Regards, Sricharan -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 07/24/2013 01:43 PM, Sricharan R wrote: > On Wednesday 24 July 2013 10:17 PM, Nishanth Menon wrote: >> On 07/24/2013 11:38 AM, Santosh Shilimkar wrote: >>> On Wednesday 24 July 2013 12:08 PM, Nishanth Menon wrote: >>>> 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? >>> This sounds better. That way we can get all the devices in the DT at least. >> >> Fair enough - if Linus and Tony are still ok with this approach to the problem, seeing a patch series with the effect would be beneficial. >> > Ok, i will use this idea of certain number interrupts to groups. > Yes on DRA7XX, we have about 160 gic lines and 320 irq crossbar device inputs contending for it. > 1:2 and fully arbitrary. But will we be really exhausting them ? > Depends on how we allocate :). The default arbitary allocation can be made more logical in your series ofcourse :).
On Wednesday 24 July 2013 02:51 PM, Nishanth Menon wrote: > On 07/24/2013 01:43 PM, Sricharan R wrote: >> On Wednesday 24 July 2013 10:17 PM, Nishanth Menon wrote: >>> On 07/24/2013 11:38 AM, Santosh Shilimkar wrote: >>>> On Wednesday 24 July 2013 12:08 PM, Nishanth Menon wrote: >>>>> 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? >>>> This sounds better. That way we can get all the devices in the DT at least. >>> >>> Fair enough - if Linus and Tony are still ok with this approach to the problem, seeing a patch series with the effect would be beneficial. >>> >> Ok, i will use this idea of certain number interrupts to groups. >> Yes on DRA7XX, we have about 160 gic lines and 320 irq crossbar device inputs contending for it. >> 1:2 and fully arbitrary. But will we be really exhausting them ? >> > Depends on how we allocate :). The default arbitary allocation can be made more logical in your series ofcourse :). > I would just most logical peripherals rather than providing every single IP connected to cross bar. Otherwise we will end up wth hwmod like scenario where now started removing the unused stuff because of maintenance and loc issues ;-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Santosh Shilimkar <santosh.shilimkar@ti.com> [130724 12:06]: > On Wednesday 24 July 2013 02:51 PM, Nishanth Menon wrote: > > On 07/24/2013 01:43 PM, Sricharan R wrote: > >> On Wednesday 24 July 2013 10:17 PM, Nishanth Menon wrote: > >>> On 07/24/2013 11:38 AM, Santosh Shilimkar wrote: > >>>> On Wednesday 24 July 2013 12:08 PM, Nishanth Menon wrote: > >>>>> 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? > >>>> This sounds better. That way we can get all the devices in the DT at least. > >>> > >>> Fair enough - if Linus and Tony are still ok with this approach to the problem, seeing a patch series with the effect would be beneficial. > >>> > >> Ok, i will use this idea of certain number interrupts to groups. > >> Yes on DRA7XX, we have about 160 gic lines and 320 irq crossbar device inputs contending for it. > >> 1:2 and fully arbitrary. But will we be really exhausting them ? > >> > > Depends on how we allocate :). The default arbitary allocation can be made more logical in your series ofcourse :). > > > I would just most logical peripherals rather than providing every single > IP connected to cross bar. Otherwise we will end up wth hwmod like > scenario where now started removing the unused stuff because of > maintenance and loc issues ;-) Sorry for the delay on this, I think the best way to set this up is as a separate drivers/irqchip controller. Then just map the configured interrupts for the board with interrupt-map and interrupt-map-mask binding. No need to stuff all the SoC specific maps to the .dts, just the ones used for the board. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Tony, On Tuesday 13 August 2013 01:40 PM, Tony Lindgren wrote: > * Santosh Shilimkar <santosh.shilimkar@ti.com> [130724 12:06]: >> On Wednesday 24 July 2013 02:51 PM, Nishanth Menon wrote: >>> On 07/24/2013 01:43 PM, Sricharan R wrote: >>>> On Wednesday 24 July 2013 10:17 PM, Nishanth Menon wrote: >>>>> On 07/24/2013 11:38 AM, Santosh Shilimkar wrote: >>>>>> On Wednesday 24 July 2013 12:08 PM, Nishanth Menon wrote: >>>>>>> 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? >>>>>> This sounds better. That way we can get all the devices in the DT at least. >>>>> Fair enough - if Linus and Tony are still ok with this approach to the problem, seeing a patch series with the effect would be beneficial. >>>>> >>>> Ok, i will use this idea of certain number interrupts to groups. >>>> Yes on DRA7XX, we have about 160 gic lines and 320 irq crossbar device inputs contending for it. >>>> 1:2 and fully arbitrary. But will we be really exhausting them ? >>>> >>> Depends on how we allocate :). The default arbitary allocation can be made more logical in your series ofcourse :). >>> >> I would just most logical peripherals rather than providing every single >> IP connected to cross bar. Otherwise we will end up wth hwmod like >> scenario where now started removing the unused stuff because of >> maintenance and loc issues ;-) > Sorry for the delay on this, I think the best way to set this up > is as a separate drivers/irqchip controller. Then just map the > configured interrupts for the board with interrupt-map and > interrupt-map-mask binding. No need to stuff all the SoC specific > maps to the .dts, just the ones used for the board. > > Regards, > > Tony > Initially irqchip was discussed, but we also have a DMA crossbar to map the dma-requests. Since both irq/dma crossbars should be handled, pinctrl was suggested as the appropriate place to handle this. Regards, Sricharan -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tuesday 13 August 2013 04:10 AM, Tony Lindgren wrote: > * Santosh Shilimkar <santosh.shilimkar@ti.com> [130724 12:06]: >> On Wednesday 24 July 2013 02:51 PM, Nishanth Menon wrote: >>> On 07/24/2013 01:43 PM, Sricharan R wrote: >>>> On Wednesday 24 July 2013 10:17 PM, Nishanth Menon wrote: >>>>> On 07/24/2013 11:38 AM, Santosh Shilimkar wrote: >>>>>> On Wednesday 24 July 2013 12:08 PM, Nishanth Menon wrote: >>>>>>> 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? >>>>>> This sounds better. That way we can get all the devices in the DT at least. >>>>> >>>>> Fair enough - if Linus and Tony are still ok with this approach to the problem, seeing a patch series with the effect would be beneficial. >>>>> >>>> Ok, i will use this idea of certain number interrupts to groups. >>>> Yes on DRA7XX, we have about 160 gic lines and 320 irq crossbar device inputs contending for it. >>>> 1:2 and fully arbitrary. But will we be really exhausting them ? >>>> >>> Depends on how we allocate :). The default arbitary allocation can be made more logical in your series ofcourse :). >>> >> I would just most logical peripherals rather than providing every single >> IP connected to cross bar. Otherwise we will end up wth hwmod like >> scenario where now started removing the unused stuff because of >> maintenance and loc issues ;-) > > Sorry for the delay on this, I think the best way to set this up > is as a separate drivers/irqchip controller. Then just map the > configured interrupts for the board with interrupt-map and > interrupt-map-mask binding. No need to stuff all the SoC specific > maps to the .dts, just the ones used for the board. > Interrupt mask/unmask, really ? Thats like abusing those irqchip hooks completely. Your point is to just setup events which we need and thats what I also suggested. But the use of irqchip hooks is certainly not the right idea since they are for masking/unmasking interrupts in running system and not for joining the interrupt line which needs to happen once during probe. Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tuesday 13 August 2013 05:56 AM, Sricharan R wrote: > Hi Tony, > > On Tuesday 13 August 2013 01:40 PM, Tony Lindgren wrote: >> * Santosh Shilimkar <santosh.shilimkar@ti.com> [130724 12:06]: >>> On Wednesday 24 July 2013 02:51 PM, Nishanth Menon wrote: >>>> On 07/24/2013 01:43 PM, Sricharan R wrote: >>>>> On Wednesday 24 July 2013 10:17 PM, Nishanth Menon wrote: >>>>>> On 07/24/2013 11:38 AM, Santosh Shilimkar wrote: >>>>>>> On Wednesday 24 July 2013 12:08 PM, Nishanth Menon wrote: >>>>>>>> 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? >>>>>>> This sounds better. That way we can get all the devices in the DT at least. >>>>>> Fair enough - if Linus and Tony are still ok with this approach to the problem, seeing a patch series with the effect would be beneficial. >>>>>> >>>>> Ok, i will use this idea of certain number interrupts to groups. >>>>> Yes on DRA7XX, we have about 160 gic lines and 320 irq crossbar device inputs contending for it. >>>>> 1:2 and fully arbitrary. But will we be really exhausting them ? >>>>> >>>> Depends on how we allocate :). The default arbitary allocation can be made more logical in your series ofcourse :). >>>> >>> I would just most logical peripherals rather than providing every single >>> IP connected to cross bar. Otherwise we will end up wth hwmod like >>> scenario where now started removing the unused stuff because of >>> maintenance and loc issues ;-) >> Sorry for the delay on this, I think the best way to set this up >> is as a separate drivers/irqchip controller. Then just map the >> configured interrupts for the board with interrupt-map and >> interrupt-map-mask binding. No need to stuff all the SoC specific >> maps to the .dts, just the ones used for the board. >> >> Regards, >> >> Tony >> > Initially irqchip was discussed, but we also have a DMA crossbar > to map the dma-requests. Since both irq/dma crossbars should be handled, > pinctrl was suggested as the appropriate place to handle this. > I replied on other thread. I guess Tony's point is to setup only required events for a board rather than setting up every possible event. Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Santosh Shilimkar <santosh.shilimkar@ti.com> [130813 06:35]: > On Tuesday 13 August 2013 04:10 AM, Tony Lindgren wrote: > > * Santosh Shilimkar <santosh.shilimkar@ti.com> [130724 12:06]: > >> On Wednesday 24 July 2013 02:51 PM, Nishanth Menon wrote: > >>> On 07/24/2013 01:43 PM, Sricharan R wrote: > >>>> On Wednesday 24 July 2013 10:17 PM, Nishanth Menon wrote: > >>>>> On 07/24/2013 11:38 AM, Santosh Shilimkar wrote: > >>>>>> On Wednesday 24 July 2013 12:08 PM, Nishanth Menon wrote: > >>>>>>> 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? > >>>>>> This sounds better. That way we can get all the devices in the DT at least. > >>>>> > >>>>> Fair enough - if Linus and Tony are still ok with this approach to the problem, seeing a patch series with the effect would be beneficial. > >>>>> > >>>> Ok, i will use this idea of certain number interrupts to groups. > >>>> Yes on DRA7XX, we have about 160 gic lines and 320 irq crossbar device inputs contending for it. > >>>> 1:2 and fully arbitrary. But will we be really exhausting them ? > >>>> > >>> Depends on how we allocate :). The default arbitary allocation can be made more logical in your series ofcourse :). > >>> > >> I would just most logical peripherals rather than providing every single > >> IP connected to cross bar. Otherwise we will end up wth hwmod like > >> scenario where now started removing the unused stuff because of > >> maintenance and loc issues ;-) > > > > Sorry for the delay on this, I think the best way to set this up > > is as a separate drivers/irqchip controller. Then just map the > > configured interrupts for the board with interrupt-map and > > interrupt-map-mask binding. No need to stuff all the SoC specific > > maps to the .dts, just the ones used for the board. > > > Interrupt mask/unmask, really ? Thats like abusing those irqchip > hooks completely. Your point is to just setup events which we need > and thats what I also suggested. But the use of irqchip hooks is > certainly not the right idea since they are for masking/unmasking > interrupts in running system and not for joining the interrupt > line which needs to happen once during probe. Well if it's an interrupt controller. Doing a chained IRQ pinctrl driver might work too. But yes, the idea with interrupt-map was to only map what's used rather than have data for each SoC. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Aug 13, 2013 at 11:56 AM, Sricharan R <r.sricharan@ti.com> wrote: > Initially irqchip was discussed, but we also have a DMA crossbar > to map the dma-requests. Since both irq/dma crossbars should be handled, > pinctrl was suggested as the appropriate place to handle this. I think it is better to use irqchip. For DMA there is already an arbiter mechanism for arbitration of virtual channels over physical channels, this is not much different, the DMA might need some different tweaking but should be solved in that subsystem I think. I don't see any way to really abstract this pretty simple crossbar for reuse across subsystems. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thursday 15 August 2013 04:01 PM, Linus Walleij wrote: > On Tue, Aug 13, 2013 at 11:56 AM, Sricharan R <r.sricharan@ti.com> wrote: > >> Initially irqchip was discussed, but we also have a DMA crossbar >> to map the dma-requests. Since both irq/dma crossbars should be handled, >> pinctrl was suggested as the appropriate place to handle this. > > I think it is better to use irqchip. > Did you happen to read the thread why irqchip is in-appropriate for such an IP. As I said earlier, an IRQ-chip always need a real IRQ link (even for the chained one) to the primary irqchip. This IP is just dummy IP makes the connections for the primary irqchip(read GIC). And its use only limited to make the connection between the peripheral IRQ event to the GIC IRQ line. I don't see how you can make this happen with an irqchip infrastructure. If you have a idea to make that work, we can go with that since for time being we can ignore the DMA event related need of this IP. > For DMA there is already an arbiter mechanism for arbitration of > virtual channels over physical channels, this is not much different, > the DMA might need some different tweaking but should be solved > in that subsystem I think. > Sure. The IP won't be limited to DMA and IRQ lines but any other events like gpio etc in future. > I don't see any way to really abstract this pretty simple crossbar > for reuse across subsystems. > This exactly the reason, i am against idea of over-engineering the simple IP whose only job is to make the physical wire connection in software where as this is generally done in RTL by default on most of the SOCs. Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Aug 15, 2013 at 10:26 PM, Santosh Shilimkar <santosh.shilimkar@ti.com> wrote: > On Thursday 15 August 2013 04:01 PM, Linus Walleij wrote: >> On Tue, Aug 13, 2013 at 11:56 AM, Sricharan R <r.sricharan@ti.com> wrote: >> >>> Initially irqchip was discussed, but we also have a DMA crossbar >>> to map the dma-requests. Since both irq/dma crossbars should be handled, >>> pinctrl was suggested as the appropriate place to handle this. >> >> I think it is better to use irqchip. >> > Did you happen to read the thread why irqchip is in-appropriate > for such an IP. Sorry I don't understand what thread that is... can you point me there? My previous statement on this issue what this: http://marc.info/?l=linux-kernel&m=137442541628641&w=2 > As I said earlier, an IRQ-chip always need a > real IRQ link (even for the chained one) to the primary irqchip. > > This IP is just dummy IP makes the connections for the primary > irqchip(read GIC). And its use only limited to make the > connection between the peripheral IRQ event to the GIC IRQ line. > > I don't see how you can make this happen with an irqchip > infrastructure. I think my post above describes this. >> I don't see any way to really abstract this pretty simple crossbar >> for reuse across subsystems. >> > This exactly the reason, i am against idea of over-engineering the > simple IP whose only job is to make the physical wire connection > in software where as this is generally done in RTL by default on > most of the SOCs. Well, it was made accessible by software, and if someone has a usecase that requires this do be done dynamically, i.e. not just being set up by firmware and never touched, and that use case is valid, then I guess we need to do something... I think it was mentioned in the thread that there is really such a usecase? Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thursday 15 August 2013 04:51 PM, Linus Walleij wrote: > On Thu, Aug 15, 2013 at 10:26 PM, Santosh Shilimkar > <santosh.shilimkar@ti.com> wrote: >> On Thursday 15 August 2013 04:01 PM, Linus Walleij wrote: >>> On Tue, Aug 13, 2013 at 11:56 AM, Sricharan R <r.sricharan@ti.com> wrote: >>> >>>> Initially irqchip was discussed, but we also have a DMA crossbar >>>> to map the dma-requests. Since both irq/dma crossbars should be handled, >>>> pinctrl was suggested as the appropriate place to handle this. >>> >>> I think it is better to use irqchip. >>> >> Did you happen to read the thread why irqchip is in-appropriate >> for such an IP. > > Sorry I don't understand what thread that is... can you point me there? > My previous statement on this issue what this: > http://marc.info/?l=linux-kernel&m=137442541628641&w=2 > It was discussed in couple of threads but the main point was the need of a link needed for the irqchip. >> As I said earlier, an IRQ-chip always need a >> real IRQ link (even for the chained one) to the primary irqchip. >> >> This IP is just dummy IP makes the connections for the primary >> irqchip(read GIC). And its use only limited to make the >> connection between the peripheral IRQ event to the GIC IRQ line. >> >> I don't see how you can make this happen with an irqchip >> infrastructure. > > I think my post above describes this. > Sorry for being dumb but I don't think cascaded irqchip examples like GPIO and cross-bars are same. If you take an example of GPIO irqchip, it always have a physical connection even if it is 1 IRQ line for (32 logical/sparse IRQs). That goes with other MFD examples too. So may be I am still missing something in your proposal. >>> I don't see any way to really abstract this pretty simple crossbar >>> for reuse across subsystems. >>> >> This exactly the reason, i am against idea of over-engineering the >> simple IP whose only job is to make the physical wire connection >> in software where as this is generally done in RTL by default on >> most of the SOCs. > > Well, it was made accessible by software, and if someone has a > usecase that requires this do be done dynamically, i.e. not just > being set up by firmware and never touched, and that use case > is valid, then I guess we need to do something... > > I think it was mentioned in the thread that there is really such > a usecase? > Actually there is no practical usecase but one but one can manufacture it ;-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Aug 15, 2013 at 11:14 PM, Santosh Shilimkar <santosh.shilimkar@ti.com> wrote: > On Thursday 15 August 2013 04:51 PM, Linus Walleij wrote: (...) >> Sorry I don't understand what thread that is... can you point me there? >> My previous statement on this issue what this: >> http://marc.info/?l=linux-kernel&m=137442541628641&w=2 (...) >>> I don't see how you can make this happen with an irqchip >>> infrastructure. >> >> I think my post above describes this. >> > Sorry for being dumb but I don't think cascaded irqchip examples > like GPIO and cross-bars are same. If you take an example of > GPIO irqchip, it always have a physical connection even if it > is 1 IRQ line for (32 logical/sparse IRQs). That goes with > other MFD examples too. > > So may be I am still missing something in your proposal. Why does it matter if it is a GPIO or MFD or whatever? The point is that the IRQ line passes thru something else, and this we model as an irqdomain. Anyway here is a silicon cascaded IRQ chip: arch/arm/mach-versatile/core.c See versatile_init_irq(): __vic_init(VA_VIC_BASE, IRQ_VIC_START, ~0, 0, np); (...) fpga_irq_init(VA_SIC_BASE, "SIC", IRQ_SIC_START, IRQ_VICSOURCE31, PIC_VALID, np); The VIC in the versatile has the SIC cascaded from one of its IRQ lines. Both the VIC and SIC (fpga IRQ) are using irqdomains so the SIC spawns a child irqdomain from IRQ 31 (last IRQ) of the VIC. The difference with a crossbar is that it can software-config which IRQ goes where, and does not have a callback to clear interrupts or anything like that, it just passes them thru. But it is best modeled as an irqdomain IMO. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Linus, On Thursday 22 August 2013 02:40 AM, Linus Walleij wrote: > On Thu, Aug 15, 2013 at 11:14 PM, Santosh Shilimkar > <santosh.shilimkar@ti.com> wrote: >> On Thursday 15 August 2013 04:51 PM, Linus Walleij wrote: > (...) >>> Sorry I don't understand what thread that is... can you point me there? >>> My previous statement on this issue what this: >>> http://marc.info/?l=linux-kernel&m=137442541628641&w=2 > (...) >>>> I don't see how you can make this happen with an irqchip >>>> infrastructure. >>> I think my post above describes this. >>> >> Sorry for being dumb but I don't think cascaded irqchip examples >> like GPIO and cross-bars are same. If you take an example of >> GPIO irqchip, it always have a physical connection even if it >> is 1 IRQ line for (32 logical/sparse IRQs). That goes with >> other MFD examples too. >> >> So may be I am still missing something in your proposal. > Why does it matter if it is a GPIO or MFD or whatever? > The point is that the IRQ line passes thru something else, > and this we model as an irqdomain. > > Anyway here is a silicon cascaded IRQ chip: > arch/arm/mach-versatile/core.c > See versatile_init_irq(): > > __vic_init(VA_VIC_BASE, IRQ_VIC_START, ~0, 0, np); > (...) > fpga_irq_init(VA_SIC_BASE, "SIC", IRQ_SIC_START, > IRQ_VICSOURCE31, PIC_VALID, np); > > The VIC in the versatile has the SIC cascaded from one of > its IRQ lines. Both the VIC and SIC (fpga IRQ) are > using irqdomains so the SIC spawns a child irqdomain > from IRQ 31 (last IRQ) of the VIC. Ok, this is a typical example of irqchip cascaded. > The difference with a crossbar is that it can software-config > which IRQ goes where, and does not have a callback > to clear interrupts or anything like that, it just passes them > thru. But it is best modeled as an irqdomain IMO. We can model crossbar as irqchip and gic as its interrupt parent and peripherals to have crossbar as interrupt-parent. peripherals will do request_irq(crossbar_number) | | crossbar_unmask() | | maps crossbar number<-> to interrupt number and calls request_irq(int_no, crossbar_handler,..) crossbar_handler(interrupt number) | | get crossbar number from interrupt number | | handle_irq(crossbar_domain(crossbar number)) So this means a extra dummy handler. Also the concern is by modelling it as irqchip, we will have to find a different solution for DMA crossbar. Regards, Sricharan -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thursday 22 August 2013 07:33 AM, Sricharan R wrote: > Hi Linus, > > On Thursday 22 August 2013 02:40 AM, Linus Walleij wrote: >> On Thu, Aug 15, 2013 at 11:14 PM, Santosh Shilimkar >> <santosh.shilimkar@ti.com> wrote: >>> On Thursday 15 August 2013 04:51 PM, Linus Walleij wrote: >> (...) >>>> Sorry I don't understand what thread that is... can you point me there? >>>> My previous statement on this issue what this: >>>> http://marc.info/?l=linux-kernel&m=137442541628641&w=2 >> (...) >>>>> I don't see how you can make this happen with an irqchip >>>>> infrastructure. >>>> I think my post above describes this. >>>> >>> Sorry for being dumb but I don't think cascaded irqchip examples >>> like GPIO and cross-bars are same. If you take an example of >>> GPIO irqchip, it always have a physical connection even if it >>> is 1 IRQ line for (32 logical/sparse IRQs). That goes with >>> other MFD examples too. >>> >>> So may be I am still missing something in your proposal. >> Why does it matter if it is a GPIO or MFD or whatever? >> The point is that the IRQ line passes thru something else, >> and this we model as an irqdomain. >> >> Anyway here is a silicon cascaded IRQ chip: >> arch/arm/mach-versatile/core.c >> See versatile_init_irq(): >> >> __vic_init(VA_VIC_BASE, IRQ_VIC_START, ~0, 0, np); >> (...) >> fpga_irq_init(VA_SIC_BASE, "SIC", IRQ_SIC_START, >> IRQ_VICSOURCE31, PIC_VALID, np); >> >> The VIC in the versatile has the SIC cascaded from one of >> its IRQ lines. Both the VIC and SIC (fpga IRQ) are >> using irqdomains so the SIC spawns a child irqdomain >> from IRQ 31 (last IRQ) of the VIC. > Ok, this is a typical example of irqchip cascaded. >> The difference with a crossbar is that it can software-config >> which IRQ goes where, and does not have a callback >> to clear interrupts or anything like that, it just passes them >> thru. But it is best modeled as an irqdomain IMO. > We can model crossbar as irqchip and gic as its interrupt parent > and peripherals to have crossbar as interrupt-parent. > > peripherals will do request_irq(crossbar_number) > | > | > crossbar_unmask() > | > | > maps crossbar number<-> to interrupt number and > calls request_irq(int_no, crossbar_handler,..) > > > crossbar_handler(interrupt number) > | > | > get crossbar number from interrupt number > | > | > handle_irq(crossbar_domain(crossbar number)) > > > So this means a extra dummy handler. Its not optimal to go through the dummy call stack on fast path but considering its not going to eat too many instructions, its fine to have dummy handler. We should try this out. > Also the concern is by modelling it as irqchip, we will have > to find a different solution for DMA crossbar. > DMAEngine has a notion of logical channel and that was actually used in the EDMA support series by Matt [1] We can do something similar to handle that scenario. [1] https://lkml.org/lkml/2013/6/18/56 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thursday 22 August 2013 05:03 PM, Sricharan R wrote: > maps crossbar number<-> to interrupt number and > calls request_irq(int_no, crossbar_handler,..) So will this mapping happen based on some data passed from DT or just based on whats available when the device does a request_irq()? If its based on whats available then I see an issue when you need to remap something thats already mapped by default (and not used) since you run out of all free ones. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On Friday 23 August 2013 10:17 AM, Rajendra Nayak wrote: > On Thursday 22 August 2013 05:03 PM, Sricharan R wrote: >> maps crossbar number<-> to interrupt number and >> calls request_irq(int_no, crossbar_handler,..) > So will this mapping happen based on some data passed from DT or > just based on whats available when the device does a request_irq()? > > If its based on whats available then I see an issue when you need > to remap something thats already mapped by default (and not used) > since you run out of all free ones. Yes, when done based on what is available then there is a problem when we run out of free ones because we do not know which one to replace. I was thinking of something like this, 1) DT would give a list of all free ones, and also if some are mapped as default and not used, mark those also as free. 2) While mapping see if it has a default mapping and use it. otherwise, pick from free list. This should be ok right ? Regards, Sricharan -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Friday 23 August 2013 11:41 AM, Sricharan R wrote: > Hi, > On Friday 23 August 2013 10:17 AM, Rajendra Nayak wrote: >> On Thursday 22 August 2013 05:03 PM, Sricharan R wrote: >>> maps crossbar number<-> to interrupt number and >>> calls request_irq(int_no, crossbar_handler,..) >> So will this mapping happen based on some data passed from DT or >> just based on whats available when the device does a request_irq()? >> >> If its based on whats available then I see an issue when you need >> to remap something thats already mapped by default (and not used) >> since you run out of all free ones. > Yes, when done based on what is available then there is a > problem when we run out of free ones because we do not > know which one to replace. I was thinking of something like > this, > 1) DT would give a list of all free ones, and also if some are > mapped as default and not used, mark those also as free. > > 2) While mapping see if it has a default mapping and use it. > otherwise, pick from free list. > > This should be ok right ? yeah, sounds ok. > > Regards, > Sricharan > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Friday 23 August 2013 11:41 AM, Sricharan R wrote: > Hi, > On Friday 23 August 2013 10:17 AM, Rajendra Nayak wrote: >> On Thursday 22 August 2013 05:03 PM, Sricharan R wrote: >>> maps crossbar number<-> to interrupt number and >>> calls request_irq(int_no, crossbar_handler,..) >> So will this mapping happen based on some data passed from DT or >> just based on whats available when the device does a request_irq()? >> >> If its based on whats available then I see an issue when you need >> to remap something thats already mapped by default (and not used) >> since you run out of all free ones. > Yes, when done based on what is available then there is a > problem when we run out of free ones because we do not > know which one to replace. I was thinking of something like > this, > 1) DT would give a list of all free ones, and also if some are > mapped as default and not used, mark those also as free. > > 2) While mapping see if it has a default mapping and use it. > otherwise, pick from free list. Since the entire DT is available to you at boot time, you should be able to find each node where interrupt-parent = <&crossbar> and then allocate one of 0-160 GIC interrupt numbers for that node, no? Where would there be a need for default mapping and remapping? From one the mails in the thread the crossbar is completely flexible - any of the 320 crossbar interrupts can be mapped to any of the 160 GIC interrupts. Any GIC interrupts left after this boot-time scan can be added to an unused list for use with runtime DT fragments (when that support comes). Sorry if I misunderstood, but above proposal sounds like maintaining a separate free interrupt lines list in DT. That will quickly go out of sync. Thanks, Sekhar -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Friday 23 August 2013 12:06 PM, Sekhar Nori wrote: > On Friday 23 August 2013 11:41 AM, Sricharan R wrote: >> Hi, >> On Friday 23 August 2013 10:17 AM, Rajendra Nayak wrote: >>> On Thursday 22 August 2013 05:03 PM, Sricharan R wrote: >>>> maps crossbar number<-> to interrupt number and >>>> calls request_irq(int_no, crossbar_handler,..) >>> So will this mapping happen based on some data passed from DT or >>> just based on whats available when the device does a request_irq()? >>> >>> If its based on whats available then I see an issue when you need >>> to remap something thats already mapped by default (and not used) >>> since you run out of all free ones. >> Yes, when done based on what is available then there is a >> problem when we run out of free ones because we do not >> know which one to replace. I was thinking of something like >> this, >> 1) DT would give a list of all free ones, and also if some are >> mapped as default and not used, mark those also as free. >> >> 2) While mapping see if it has a default mapping and use it. >> otherwise, pick from free list. > Since the entire DT is available to you at boot time, you should be able > to find each node where interrupt-parent = <&crossbar> and then allocate > one of 0-160 GIC interrupt numbers for that node, no? Where would there > be a need for default mapping and remapping? From one the mails in the > thread the crossbar is completely flexible - any of the 320 crossbar > interrupts can be mapped to any of the 160 GIC interrupts. > > Any GIC interrupts left after this boot-time scan can be added to an > unused list for use with runtime DT fragments (when that support comes). > > Sorry if I misunderstood, but above proposal sounds like maintaining a > separate free interrupt lines list in DT. That will quickly go out of sync. Say, peripheral x uses crossbar 1 and specifies this in DT. During boot crossbar 1 gets mapped int 10. So if by default some other crossbar has its interrupt mapped to 10, then it should be removed. Instead clear all crossbar registers once and mark all as free, then allocate only during request. Correct ?. In this the free no need to maintain any list. Regards, Sricharan -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Friday 23 August 2013 12:23 PM, Sricharan R wrote: > On Friday 23 August 2013 12:06 PM, Sekhar Nori wrote: >> On Friday 23 August 2013 11:41 AM, Sricharan R wrote: >>> Hi, >>> On Friday 23 August 2013 10:17 AM, Rajendra Nayak wrote: >>>> On Thursday 22 August 2013 05:03 PM, Sricharan R wrote: >>>>> maps crossbar number<-> to interrupt number and >>>>> calls request_irq(int_no, crossbar_handler,..) >>>> So will this mapping happen based on some data passed from DT or >>>> just based on whats available when the device does a request_irq()? >>>> >>>> If its based on whats available then I see an issue when you need >>>> to remap something thats already mapped by default (and not used) >>>> since you run out of all free ones. >>> Yes, when done based on what is available then there is a >>> problem when we run out of free ones because we do not >>> know which one to replace. I was thinking of something like >>> this, >>> 1) DT would give a list of all free ones, and also if some are >>> mapped as default and not used, mark those also as free. >>> >>> 2) While mapping see if it has a default mapping and use it. >>> otherwise, pick from free list. >> Since the entire DT is available to you at boot time, you should be able >> to find each node where interrupt-parent = <&crossbar> and then allocate >> one of 0-160 GIC interrupt numbers for that node, no? Where would there >> be a need for default mapping and remapping? From one the mails in the >> thread the crossbar is completely flexible - any of the 320 crossbar >> interrupts can be mapped to any of the 160 GIC interrupts. >> >> Any GIC interrupts left after this boot-time scan can be added to an >> unused list for use with runtime DT fragments (when that support comes). >> >> Sorry if I misunderstood, but above proposal sounds like maintaining a >> separate free interrupt lines list in DT. That will quickly go out of sync. > Say, peripheral x uses crossbar 1 and specifies this in DT. > During boot crossbar 1 gets mapped int 10. So if by default > some other crossbar has its interrupt mapped to 10, > then it should be removed. Instead clear all crossbar registers > once and mark all as free, then allocate only during request. > Correct ?. In this the free no need to maintain any list. Right, so in my suggestion there is nothing like a "default mapping" and entire 160 GIC interrupt number space is up for grabs. I think this will be much simpler to write and maintain. If you really want to maintain default mapping as far as possible, you can do two passes on the crossbar interrupt numbers requested. Once to assign the default map - for numbers less that 160 - and then look at the free GIC interrupt slots and use those for numbers greater than 160. Thanks, Sekhar -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Friday 23 August 2013 04:14 AM, Sekhar Nori wrote: > On Friday 23 August 2013 12:23 PM, Sricharan R wrote: >> On Friday 23 August 2013 12:06 PM, Sekhar Nori wrote: >>> On Friday 23 August 2013 11:41 AM, Sricharan R wrote: >>>> Hi, >>>> On Friday 23 August 2013 10:17 AM, Rajendra Nayak wrote: >>>>> On Thursday 22 August 2013 05:03 PM, Sricharan R wrote: >>>>>> maps crossbar number<-> to interrupt number and >>>>>> calls request_irq(int_no, crossbar_handler,..) >>>>> So will this mapping happen based on some data passed from DT or >>>>> just based on whats available when the device does a request_irq()? >>>>> >>>>> If its based on whats available then I see an issue when you need >>>>> to remap something thats already mapped by default (and not used) >>>>> since you run out of all free ones. >>>> Yes, when done based on what is available then there is a >>>> problem when we run out of free ones because we do not >>>> know which one to replace. I was thinking of something like >>>> this, >>>> 1) DT would give a list of all free ones, and also if some are >>>> mapped as default and not used, mark those also as free. >>>> >>>> 2) While mapping see if it has a default mapping and use it. >>>> otherwise, pick from free list. >>> Since the entire DT is available to you at boot time, you should be able >>> to find each node where interrupt-parent = <&crossbar> and then allocate >>> one of 0-160 GIC interrupt numbers for that node, no? Where would there >>> be a need for default mapping and remapping? From one the mails in the >>> thread the crossbar is completely flexible - any of the 320 crossbar >>> interrupts can be mapped to any of the 160 GIC interrupts. >>> >>> Any GIC interrupts left after this boot-time scan can be added to an >>> unused list for use with runtime DT fragments (when that support comes). >>> >>> Sorry if I misunderstood, but above proposal sounds like maintaining a >>> separate free interrupt lines list in DT. That will quickly go out of sync. >> Say, peripheral x uses crossbar 1 and specifies this in DT. >> During boot crossbar 1 gets mapped int 10. So if by default >> some other crossbar has its interrupt mapped to 10, >> then it should be removed. Instead clear all crossbar registers >> once and mark all as free, then allocate only during request. >> Correct ?. In this the free no need to maintain any list. > > Right, so in my suggestion there is nothing like a "default mapping" and > entire 160 GIC interrupt number space is up for grabs. I think this will > be much simpler to write and maintain. > > If you really want to maintain default mapping as far as possible, you > can do two passes on the crossbar interrupt numbers requested. Once to > assign the default map - for numbers less that 160 - and then look at > the free GIC interrupt slots and use those for numbers greater than 160. > The whole point we are moving to domain is not have any default mapping(connection done) at DT level. Rather DT only specifies the peripherals and their cross-bar connection ID(i.e cross-bar IRQ line). This will be the driver input as a IRQ line from DT. The cross-bar driver needs to map any of the free list available on *request* only. Of-course you have 320 inputs out of which only 160 can be mapped and once you run out of it, you just return error on request IRQ. That way there is no contention. Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 8/23/2013 7:08 PM, Santosh Shilimkar wrote: > On Friday 23 August 2013 04:14 AM, Sekhar Nori wrote: >> On Friday 23 August 2013 12:23 PM, Sricharan R wrote: >>> On Friday 23 August 2013 12:06 PM, Sekhar Nori wrote: >>>> On Friday 23 August 2013 11:41 AM, Sricharan R wrote: >>>>> Hi, >>>>> On Friday 23 August 2013 10:17 AM, Rajendra Nayak wrote: >>>>>> On Thursday 22 August 2013 05:03 PM, Sricharan R wrote: >>>>>>> maps crossbar number<-> to interrupt number and >>>>>>> calls request_irq(int_no, crossbar_handler,..) >>>>>> So will this mapping happen based on some data passed from DT or >>>>>> just based on whats available when the device does a request_irq()? >>>>>> >>>>>> If its based on whats available then I see an issue when you need >>>>>> to remap something thats already mapped by default (and not used) >>>>>> since you run out of all free ones. >>>>> Yes, when done based on what is available then there is a >>>>> problem when we run out of free ones because we do not >>>>> know which one to replace. I was thinking of something like >>>>> this, >>>>> 1) DT would give a list of all free ones, and also if some are >>>>> mapped as default and not used, mark those also as free. >>>>> >>>>> 2) While mapping see if it has a default mapping and use it. >>>>> otherwise, pick from free list. >>>> Since the entire DT is available to you at boot time, you should be able >>>> to find each node where interrupt-parent = <&crossbar> and then allocate >>>> one of 0-160 GIC interrupt numbers for that node, no? Where would there >>>> be a need for default mapping and remapping? From one the mails in the >>>> thread the crossbar is completely flexible - any of the 320 crossbar >>>> interrupts can be mapped to any of the 160 GIC interrupts. >>>> >>>> Any GIC interrupts left after this boot-time scan can be added to an >>>> unused list for use with runtime DT fragments (when that support comes). >>>> >>>> Sorry if I misunderstood, but above proposal sounds like maintaining a >>>> separate free interrupt lines list in DT. That will quickly go out of sync. >>> Say, peripheral x uses crossbar 1 and specifies this in DT. >>> During boot crossbar 1 gets mapped int 10. So if by default >>> some other crossbar has its interrupt mapped to 10, >>> then it should be removed. Instead clear all crossbar registers >>> once and mark all as free, then allocate only during request. >>> Correct ?. In this the free no need to maintain any list. >> >> Right, so in my suggestion there is nothing like a "default mapping" and >> entire 160 GIC interrupt number space is up for grabs. I think this will >> be much simpler to write and maintain. >> >> If you really want to maintain default mapping as far as possible, you >> can do two passes on the crossbar interrupt numbers requested. Once to >> assign the default map - for numbers less that 160 - and then look at >> the free GIC interrupt slots and use those for numbers greater than 160. >> > The whole point we are moving to domain is not have any default > mapping(connection done) at DT level. Rather DT only specifies the > peripherals and their cross-bar connection ID(i.e cross-bar IRQ line). > This will be the driver input as a IRQ line from DT. The cross-bar > driver needs to map any of the free list available on *request* only. Right, the mapping can be done on request. That will be cleaner. Thanks, Sekhar -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Aug 23, 2013 at 6:28 PM, Sekhar Nori <nsekhar@ti.com> wrote: > On 8/23/2013 7:08 PM, Santosh Shilimkar wrote: >> The whole point we are moving to domain is not have any default >> mapping(connection done) at DT level. Rather DT only specifies the >> peripherals and their cross-bar connection ID(i.e cross-bar IRQ line). >> This will be the driver input as a IRQ line from DT. The cross-bar >> driver needs to map any of the free list available on *request* only. > > Right, the mapping can be done on request. That will be cleaner. I like where this design is going now :-) Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Friday 23 August 2013 03:06 PM, Linus Walleij wrote: > On Fri, Aug 23, 2013 at 6:28 PM, Sekhar Nori <nsekhar@ti.com> wrote: >> On 8/23/2013 7:08 PM, Santosh Shilimkar wrote: > >>> The whole point we are moving to domain is not have any default >>> mapping(connection done) at DT level. Rather DT only specifies the >>> peripherals and their cross-bar connection ID(i.e cross-bar IRQ line). >>> This will be the driver input as a IRQ line from DT. The cross-bar >>> driver needs to map any of the free list available on *request* only. >> >> Right, the mapping can be done on request. That will be cleaner. > > I like where this design is going now :-) > Sure and thanks for good discussion. Debates are useful regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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>; + }; + diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index c002d86..de89bff 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -527,6 +527,14 @@ config SRAM the genalloc API. It is supposed to be used for small on-chip SRAM areas found on many SoCs. +config CROSSBAR + bool "on-chip crossbar driver" + select REGMAP_MMIO + help + This driver is for IRQ/DMA crossbar devices which is responsible for + muxing the irq/dma requests from external peripherals to the corresponding + controller's inputs. + source "drivers/misc/c2port/Kconfig" source "drivers/misc/eeprom/Kconfig" source "drivers/misc/cb710/Kconfig" diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile index c235d5b..37ce1b8 100644 --- a/drivers/misc/Makefile +++ b/drivers/misc/Makefile @@ -53,3 +53,4 @@ obj-$(CONFIG_INTEL_MEI) += mei/ obj-$(CONFIG_VMWARE_VMCI) += vmw_vmci/ obj-$(CONFIG_LATTICE_ECP3_CONFIG) += lattice-ecp3-config.o obj-$(CONFIG_SRAM) += sram.o +obj-$(CONFIG_CROSSBAR) += crossbar.o diff --git a/drivers/misc/crossbar.c b/drivers/misc/crossbar.c new file mode 100644 index 0000000..c0a7e83 --- /dev/null +++ b/drivers/misc/crossbar.c @@ -0,0 +1,258 @@ +/* + * IRQ/DMA CROSSBAR DRIVER + * + * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/ + * Sricharan R <r.sricharan@ti.com> + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 + * USA + */ +#include <linux/crossbar.h> +#include <linux/regmap.h> + +static LIST_HEAD(cb_devlist); + +static struct regmap_config cb_regmap_config = { + .reg_bits = 32, +}; + +static unsigned cb_entry_read(struct cb_line *tmp, const void *cbs) +{ + unsigned index = 0; + + tmp->cb_name = cbs; + index = strlen(tmp->cb_name) + 1; + + tmp->dev_name = cbs + index; + index += strlen(tmp->dev_name) + 1; + + tmp->int_no = be32_to_cpup(cbs + index); + index += sizeof(tmp->int_no); + + tmp->cb_no = be32_to_cpup(cbs + index); + index += sizeof(tmp->cb_no); + + tmp->offset = be32_to_cpup(cbs + index); + index += sizeof(tmp->offset); + + return index; +} + +int crossbar_unmap(struct device_node *cbdev_node, unsigned index) +{ + const void *cbs; + unsigned size = 0, i = 0; + struct cb_line tmp; + struct cb_device *cbdev; + struct cb_entry *cbentry, *p; + + cbs = of_get_property(cbdev_node, "crossbar-lines", &size); + if (!cbs) + return -ENOENT; + + size = 0; + + while (i++ < index) + size += cb_entry_read(&tmp, cbs + size); + + cb_entry_read(&tmp, cbs + size); + + list_for_each_entry(cbdev, &cb_devlist, node) { + if (strcmp(cbdev->name, tmp.cb_name)) + continue; + + mutex_lock(&cbdev->cb_lock); + list_for_each_entry_safe(cbentry, p, &cbdev->cb_entries, + cb_list) { + if ((cbentry->line.cb_no == tmp.cb_no) && + (cbentry->line.int_no == tmp.int_no)) { + list_del(&cbentry->cb_list); + mutex_unlock(&cbdev->cb_lock); + dev_warn(cbdev->dev, + "unmapped int_no %x mapped to cb %x\n", + tmp.int_no, tmp.cb_no); + return 0; + } + } + mutex_unlock(&cbdev->cb_lock); + break; + } + + dev_warn(cbdev->dev, "%s cb entry %d not found\n", + __func__, tmp.cb_no); + return -ENOENT; +} +EXPORT_SYMBOL(crossbar_unmap); + +const int cb_map(struct cb_line cbl) +{ + struct cb_device *cbdev; + struct cb_entry *cbentry, *tmp; + unsigned val; + + /* Get corresponding device pointer */ + list_for_each_entry(cbdev, &cb_devlist, node) { + if (strcmp(cbdev->name, cbl.cb_name)) + continue; + + mutex_lock(&cbdev->cb_lock); + + /* Check for invalid and duplicate mapping */ + list_for_each_entry_safe(cbentry, tmp, &cbdev->cb_entries, + cb_list) { + if ((cbentry->line.cb_no == cbl.cb_no) && + (cbentry->line.int_no != cbl.int_no)) { + dev_warn(cbdev->dev, + "%s irq already mapped to irq no %d", + cbentry->line.dev_name, + cbentry->line.int_no); + mutex_unlock(&cbdev->cb_lock); + return -EINVAL; + } + if ((cbentry->line.cb_no == cbl.cb_no) && + (cbentry->line.int_no == cbl.int_no)) { + mutex_unlock(&cbdev->cb_lock); + return 0; + } + if ((cbentry->line.int_no == cbl.int_no) && + (cbentry->line.cb_no != cbl.cb_no)) { + dev_warn(cbdev->dev, + "%s irq replaced by %s irq\n", + cbentry->line.dev_name, + cbl.dev_name); + list_del(&(cbentry->cb_list)); + break; + } + } + + cbentry = devm_kzalloc(cbdev->dev, sizeof(struct cb_entry), + GFP_KERNEL); + cbentry->line = cbl; + list_add_tail(&(cbentry->cb_list), &cbdev->cb_entries); + + regmap_read(cbdev->cb_regmap, cbl.offset, &val); + + /* Print the replaced entry and map the new one */ + dev_warn(cbdev->dev, + "replacing irq %d mapped to cb input %d with cb input %d\n", + cbl.int_no, val, cbl.cb_no); + + regmap_write(cbdev->cb_regmap, cbl.offset, cbl.cb_no); + mutex_unlock(&cbdev->cb_lock); + return 0; + } + + dev_warn(cbdev->dev, "crossbar device %s not found", cbl.cb_name); + return -ENODEV; +} + +int crossbar_map(struct device_node *cbdev_node) +{ + const void *cbs; + unsigned size = 0, index = 0; + int err; + + cbs = of_get_property(cbdev_node, "crossbar-lines", &size); + if (!cbs) + return -ENOENT; + + while (index < size) { + struct cb_line tmp; + + index += cb_entry_read(&tmp, cbs + index); + + err = cb_map(tmp); + if (IS_ERR_VALUE(err)) + return err; + } + + return 0; +} +EXPORT_SYMBOL(crossbar_map); + +static int crossbar_probe(struct platform_device *pdev) +{ + struct cb_device *cbdev; + unsigned width; + struct device_node *cbdev_node = pdev->dev.of_node; + int err; + struct resource *res; + + cbdev = devm_kzalloc(&pdev->dev, sizeof(struct cb_device), GFP_KERNEL); + if (!cbdev) + return -ENOMEM; + + /* Get the device resources */ + of_property_read_string(cbdev_node, "crossbar-name", &(cbdev->name)); + + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); + if (res == NULL) + return -ENOENT; + + cbdev->base = devm_ioremap_resource(&pdev->dev, res); + if (!cbdev->base) + return -ENOMEM; + + cbdev->dev = &pdev->dev; + + of_property_read_u32(cbdev_node, "reg-width", &width); + + cb_regmap_config.val_bits = width; + cb_regmap_config.reg_stride = width >> 3; + + cbdev->cb_regmap = devm_regmap_init_mmio(cbdev->dev, cbdev->base, + &cb_regmap_config); + + if (IS_ERR(cbdev->cb_regmap)) { + dev_err(&pdev->dev, "regmap init failed\n"); + err = PTR_ERR(cbdev->cb_regmap); + return err; + } + + platform_set_drvdata(pdev, cbdev); + list_add_tail(&cbdev->node, &cb_devlist); + + /* INIT LIST HEAD */ + INIT_LIST_HEAD(&cbdev->cb_entries); + + mutex_init(&cbdev->cb_lock); + + /* map the cross bar entries passed as default from DT */ + err = crossbar_map(cbdev_node); + + return err; +} + +#ifdef CONFIG_OF +static const struct of_device_id crossbar_match[] = { + {.compatible = "crossbar", }, + {}, +}; +#endif + +static struct platform_driver crossbar_driver = { + .probe = crossbar_probe, + .driver = { + .name = "crossbar", + .owner = THIS_MODULE, + .of_match_table = crossbar_match, + }, +}; + +static int __init crossbar_init(void) +{ + return platform_driver_register(&crossbar_driver); +} +postcore_initcall(crossbar_init); diff --git a/include/linux/crossbar.h b/include/linux/crossbar.h new file mode 100644 index 0000000..27ca735 --- /dev/null +++ b/include/linux/crossbar.h @@ -0,0 +1,71 @@ +/* + * IRQ/DMA CROSSBAR DRIVER + * + * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/ + * Sricharan <r.sricharan@ti.com> + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 + * USA + */ +#include <linux/io.h> +#include <linux/of.h> +#include <linux/of_irq.h> +#include <linux/of_address.h> +#include <linux/list.h> +#include <linux/err.h> +#include <linux/gfp.h> +#include <linux/platform_device.h> + +/* + * @base: base address of the crossbar device + * @dev: device ptr + * @name: name of the crossbar device + * @node: list node for the crossbar devices linked list + * @cb_entries: list of entries that belong to the crossbar + * @cb_lock: mutex + * @regmap pointer + */ +struct cb_device { + void __iomem *base; + struct device *dev; + const char *name; + struct list_head node; + struct list_head cb_entries; + struct mutex cb_lock; + struct regmap *cb_regmap; +}; + +/* + * @cb_name: name of crossbar target to which this line is mapped + * @dev_name: mapped device input request name + * @cb_no: crossbar device input number + * @int_no: request number to which this input should be routed + * @offset: register offset address + */ +struct cb_line { + const char *cb_name; + const char *dev_name; + unsigned cb_no; + unsigned int_no; + unsigned offset; +}; + +struct cb_entry { + struct cb_line line; + struct list_head cb_list; +}; + +int crossbar_map(struct device_node *cbdev_node); +int crossbar_unmap(struct device_node *cbdev_node, unsigned index);
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@ti.com> --- .../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