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.
This series adds a crossbar driver and the DT bindings for the
same. Also the DT nodes for DRA7xx SOC which has a IRQ/DMA
crossbar has been added here.
This series is on top of the basic DRA support from Rajendra [1][2]
[1] http://comments.gmane.org/gmane.linux.ports.arm.omap/100763
[2] http://comments.gmane.org/gmane.linux.ports.arm.omap/100773
Sricharan R (3):
misc: Add crossbar driver
ARM: dts: DRA: Add crossbar device binding
ARM: DRA: Enable crossbar driver for dra soc
.../devicetree/bindings/arm/omap/crossbar.txt | 24 ++
arch/arm/boot/dts/dra7.dtsi | 19 ++
arch/arm/mach-omap2/Kconfig | 1 +
drivers/misc/Kconfig | 8 +
drivers/misc/Makefile | 1 +
drivers/misc/crossbar.c | 258 ++++++++++++++++++++
include/linux/crossbar.h | 71 ++++++
7 files changed, 382 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
--
1.7.9.5
This adds the irq/dma crossbar device nodes.
There is a IRQ and DMA crossbar device in the soc, which
maps the irq/dma requests from the peripherals to the
mpu/dsp/ipu/eve interrupt and sdma/edma controller's inputs.
The Peripheral irq/dma requests are connected to only one crossbar
input and the output of the crossbar is connected to only one
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 control registers.
The irq/dma mapping for some peripherals are
added with the crossbar nodes here.
Signed-off-by: Sricharan R <[email protected]>
---
arch/arm/boot/dts/dra7.dtsi | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index a5d9350..e6208b4 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -85,6 +85,25 @@
ranges;
ti,hwmods = "l3_main_1", "l3_main_2";
+ 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>;
+ };
+
+ crossbar_dma: dmareq@4a002b78 {
+ compatible = "crossbar";
+ crossbar-name = "dma-req";
+ reg = <0x4a002b78 0x0100>;
+ reg-width = <16>;
+ crossbar-lines = "dma-req", "mcasp3-rx", <0x7e 0x84 0xfc>,
+ "dma-req", "mcasp3-tx", <0x7d 0x85 0xfa>;
+ };
+
counter32k: counter@4ae04000 {
compatible = "ti,omap-counter32k";
reg = <0x4ae04000 0x40>;
--
1.7.9.5
Enable the crossbar driver to handle the irq/dma
crossbar devices in the soc.
Signed-off-by: Sricharan R <[email protected]>
---
arch/arm/mach-omap2/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 80aaadc..3def350 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -120,6 +120,7 @@ config SOC_DRA7XX
select ARM_GIC
select HAVE_SMP
select COMMON_CLK
+ select CROSSBAR
comment "OMAP Core Type"
depends on ARCH_OMAP2
--
1.7.9.5
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 <[email protected]>
---
.../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>;
+ };
+
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 <[email protected]>
+ *
+ * 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 <[email protected]>
+ *
+ * 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);
--
1.7.9.5
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?
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 <[email protected]>
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 ?
--
balbi
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 <[email protected]>
> ---
> .../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
--
Regards,
Nishanth Menon
On 07/18/2013 11:43 AM, Sricharan R wrote:
> This adds the irq/dma crossbar device nodes.
>
> There is a IRQ and DMA crossbar device in the soc, which
> maps the irq/dma requests from the peripherals to the
> mpu/dsp/ipu/eve interrupt and sdma/edma controller's inputs.
> The Peripheral irq/dma requests are connected to only one crossbar
> input and the output of the crossbar is connected to only one
> 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 control registers.
>
What is POR? Plan on Record? I supppose, we just love our TLA?
> The irq/dma mapping for some peripherals are
> added with the crossbar nodes here.
>
> Signed-off-by: Sricharan R <[email protected]>
> ---
> arch/arm/boot/dts/dra7.dtsi | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
>
> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
> index a5d9350..e6208b4 100644
> --- a/arch/arm/boot/dts/dra7.dtsi
> +++ b/arch/arm/boot/dts/dra7.dtsi
> @@ -85,6 +85,25 @@
> ranges;
> ti,hwmods = "l3_main_1", "l3_main_2";
>
> + 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>;
a) I'd like to use UART10. oh, let me guess: we dont map all cross bar
options here.. just "certain ones"
b) I like to use random 6 uarts out of the available 10 uarts on the fly.
c) I'd like to use IRQCROSS bar such that i use all the hardware block
instances that dont have default GIC IRQ mapping.
> + };
> +
> + crossbar_dma: dmareq@4a002b78 {
> + compatible = "crossbar";
> + crossbar-name = "dma-req";
> + reg = <0x4a002b78 0x0100>;
> + reg-width = <16>;
> + crossbar-lines = "dma-req", "mcasp3-rx", <0x7e 0x84 0xfc>,
> + "dma-req", "mcasp3-tx", <0x7d 0x85 0xfa>;
> + };
> +
> counter32k: counter@4ae04000 {
> compatible = "ti,omap-counter32k";
> reg = <0x4ae04000 0x40>;
>
--
Regards,
Nishanth Menon
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 <[email protected]>
>> ---
>> .../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
On Thu, Jul 18, 2013 at 6:39 PM, Santosh Shilimkar
<[email protected]> 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 <[email protected]>
>>> ---
>>> .../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
> 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
Hi,
On Friday 19 July 2013 05:43 AM, Nishanth Menon wrote:
> On Thu, Jul 18, 2013 at 6:39 PM, Santosh Shilimkar
> <[email protected]> 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 <[email protected]>
>>>> ---
>>>> .../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
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
On Thu, Jul 18, 2013 at 8:25 PM, Felipe Balbi <[email protected]> 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
On Thu, Jul 18, 2013 at 8:56 PM, Nishanth Menon <[email protected]> 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
Hi Linus,
On Sunday 21 July 2013 10:19 PM, Linus Walleij wrote:
> On Thu, Jul 18, 2013 at 8:56 PM, Nishanth Menon <[email protected]> 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
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 <[email protected]> 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
On 07/22/2013 11:23 AM, Santosh Shilimkar wrote:
> To summaries it again, what I understood from Sricharan's proposal,
>
> - Setup all the routing at cross-bar probe so that kernel continue to
> work like normal IRQ controller with cross-bar scope vanishes once
> the routing is done. Cross-bar does this before any of the devices
> are created.
> - Something similar needs to happen for DMA lines as well or for any
> other event routing in future.
> - Cross-bar callbacks for device drivers for error paths.
> (Sricharan, you have to drop these because it doesn't bring any
> functionality and rather can create a side effects of drivers
> getting polluted.)
Ack.
>
> The concern raised on above was instead of fixing the routing at DT
> statically, doing at the driver probes where the loop-up for IRQ or DMA
> lines should happen in background transparently on drivers call of
> request_irq/request_dma_channel etc with cross-bar number as
> an input to it. Though it will be nice to have
> such feature, it doesn't bring anything special and brings the
> notion of these APIs which expect that you know what IRQ and DMA
> lines you want while calling these.
Unfortunately, we do have a constraint without allocating dynamic IRQs -
what IP instances should hwmod and dts contain?
If we go with current series of patches[1] [2] for DRA7 dts which
assumes default mapping, hence, uart7-10, GPTimers12-16 dont have
default irq - hence they dont exist in dts etc.
How would we like to support those with pinctrl approach?
>
> Note that mux inputs are pretty much fixed. Its his connection
> to IRQ controller or DMA controller is what needs to be programmed.
> So scope is pretty much limited. I felt this requirement is pretty
> similar to pin-mux and hence thought of it as a viable option.
>
> Having said all of above, if there is a better alternative than
> enhanced pin-mux we surely can do that.
We could look at it as a signal mux problem as this thread suggests OR
look at it as interrupt distribution problem (which is how it looks like
at the face of it). That said, maybe a intermediate pinctrl approach
might be more pragmatic and less theoretically flexible.
an option might be to "statically allocate" default number of interrupts
to a domain - example:
* GIC IRQ 72->78 allotted to UARTs
* pinctrl mapping provided for those but only 6 can be used (rest are
marked status="disabled" as default) at any given time (choice of
pinctrl option determines GIC interrupt line to use)
* All modules will have a pinctrl definition to have a mapping - to
avoid bootloader overriding default cross bar setting in ways
un-expected by kernel.
Does that sound fair trade off?
[1] http://marc.info/?l=linux-omap&m=137335524702155&w=2
[2] http://marc.info/?l=linux-omap&m=137335522802144&w=2
--
Regards,
Nishanth Menon
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
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.
--
Regards,
Nishanth Menon
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
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 :).
--
Regards,
Nishanth Menon
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 ;-)
* Santosh Shilimkar <[email protected]> [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
Hi Tony,
On Tuesday 13 August 2013 01:40 PM, Tony Lindgren wrote:
> * Santosh Shilimkar <[email protected]> [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
On Tuesday 13 August 2013 04:10 AM, Tony Lindgren wrote:
> * Santosh Shilimkar <[email protected]> [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
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 <[email protected]> [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
* Santosh Shilimkar <[email protected]> [130813 06:35]:
> On Tuesday 13 August 2013 04:10 AM, Tony Lindgren wrote:
> > * Santosh Shilimkar <[email protected]> [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
On Tue, Aug 13, 2013 at 11:56 AM, Sricharan R <[email protected]> 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
On Thursday 15 August 2013 04:01 PM, Linus Walleij wrote:
> On Tue, Aug 13, 2013 at 11:56 AM, Sricharan R <[email protected]> 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
On Thu, Aug 15, 2013 at 10:26 PM, Santosh Shilimkar
<[email protected]> wrote:
> On Thursday 15 August 2013 04:01 PM, Linus Walleij wrote:
>> On Tue, Aug 13, 2013 at 11:56 AM, Sricharan R <[email protected]> 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
On Thursday 15 August 2013 04:51 PM, Linus Walleij wrote:
> On Thu, Aug 15, 2013 at 10:26 PM, Santosh Shilimkar
> <[email protected]> wrote:
>> On Thursday 15 August 2013 04:01 PM, Linus Walleij wrote:
>>> On Tue, Aug 13, 2013 at 11:56 AM, Sricharan R <[email protected]> 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 ;-)
On Thu, Aug 15, 2013 at 11:14 PM, Santosh Shilimkar
<[email protected]> 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
Hi Linus,
On Thursday 22 August 2013 02:40 AM, Linus Walleij wrote:
> On Thu, Aug 15, 2013 at 11:14 PM, Santosh Shilimkar
> <[email protected]> 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
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
>> <[email protected]> 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
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.
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
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
>
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
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
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
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
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
On Fri, Aug 23, 2013 at 6:28 PM, Sekhar Nori <[email protected]> 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
On Friday 23 August 2013 03:06 PM, Linus Walleij wrote:
> On Fri, Aug 23, 2013 at 6:28 PM, Sekhar Nori <[email protected]> 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