All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 1/2] bus: ixp4xx: Add DT bindings for the IXP4xx expansion bus
@ 2021-07-17  0:16 ` Linus Walleij
  0 siblings, 0 replies; 13+ messages in thread
From: Linus Walleij @ 2021-07-17  0:16 UTC (permalink / raw)
  To: linux-arm-kernel, Imre Kaloz, Krzysztof Halasa
  Cc: Linus Walleij, Marc Zyngier, devicetree

This adds device tree bindings for the IXP4xx expansion bus controller.

Cc: Marc Zyngier <maz@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
 ...intel,ixp4xx-expansion-bus-controller.yaml | 151 ++++++++++++++++++
 1 file changed, 151 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/bus/intel,ixp4xx-expansion-bus-controller.yaml

diff --git a/Documentation/devicetree/bindings/bus/intel,ixp4xx-expansion-bus-controller.yaml b/Documentation/devicetree/bindings/bus/intel,ixp4xx-expansion-bus-controller.yaml
new file mode 100644
index 000000000000..0875b653c35c
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/intel,ixp4xx-expansion-bus-controller.yaml
@@ -0,0 +1,151 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/bus/intel,ixp4xx-expansion-bus-controller.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intel IXP4xx Expansion Bus Controller
+
+description: |
+  The IXP4xx expansion bus controller handles access to devices on the
+  memory-mapped expansion bus on the Intel IXP4xx family of system on chips,
+  including IXP42x, IXP43x, IXP45x and IXP46x.
+
+maintainers:
+  - Linus Walleij <linus.walleij@linaro.org>
+
+properties:
+  $nodename:
+    pattern: '^bus@[0-9a-f]+$'
+
+  compatible:
+    enum:
+      - intel,ixp42x-expansion-bus-controller
+      - intel,ixp43x-expansion-bus-controller
+      - intel,ixp45x-expansion-bus-controller
+      - intel,ixp46x-expansion-bus-controller
+
+  reg:
+    description: Control registers for the expansion bus, these are not
+      inside the memory range handled by the expansion bus.
+    maxItems: 1
+
+  "#address-cells":
+    description: |
+      The first cell is the chip select numer.
+      The second cell is the address offset within the bank.
+    const: 2
+
+  "#size-cells":
+    const: 1
+
+  ranges: true
+  dma-ranges: true
+
+patternProperties:
+  "^.*@[0-7],[0-9a-f]+$":
+    description: Devices attached to chip selects are represented as
+      subnodes.
+    type: object
+
+    properties:
+      intel,ixp4xx-eb-t1:
+        description: Address timing, extend address phase with n cycles.
+        $ref: /schemas/types.yaml#/definitions/uint32
+        maximum: 3
+
+      intel,ixp4xx-eb-t2:
+        description: Setup chip select timing, extend setup phase with n cycles.
+        $ref: /schemas/types.yaml#/definitions/uint32
+        maximum: 3
+
+      intel,ixp4xx-eb-t3:
+        description: Strobe timing, extend strobe phase with n cycles.
+        $ref: /schemas/types.yaml#/definitions/uint32
+        maximum: 15
+
+      intel,ixp4xx-eb-t4:
+        description: Hold timing, extend hold phase with n cycles.
+        $ref: /schemas/types.yaml#/definitions/uint32
+        maximum: 3
+
+      intel,ixp4xx-eb-t5:
+        description: Recovery timing, extend recovery phase with n cycles.
+        $ref: /schemas/types.yaml#/definitions/uint32
+        maximum: 15
+
+      intel,ixp4xx-eb-cycle-type:
+        description: The type of cycles to use on the expansion bus for this
+          chip select. 0 = Intel cycles, 1 = Motorola cycles, 2 = HPI cycles.
+        $ref: /schemas/types.yaml#/definitions/uint32
+        enum: [0, 1, 2]
+
+      intel,ixp4xx-eb-byte-access-on-halfword:
+        description: Allow byte read access on half word devices.
+        $ref: /schemas/types.yaml#/definitions/flag
+
+      intel,ixp4xx-eb-hpi-hrdy-pol-high:
+        description: Set HPI HRDY polarity to active high when using HPI.
+        $ref: /schemas/types.yaml#/definitions/flag
+
+      intel,ixp4xx-eb-mux-address-and-data:
+        description: Multiplex address and data on the data bus.
+        $ref: /schemas/types.yaml#/definitions/flag
+
+      intel,ixp4xx-eb-ahb-split-transfers:
+        description: Enable AHB split transfers.
+        $ref: /schemas/types.yaml#/definitions/flag
+
+      intel,ixp4xx-eb-write-enable:
+        description: Enable write cycles.
+        $ref: /schemas/types.yaml#/definitions/flag
+
+      intel,ixp4xx-eb-byte-access:
+        description: Expansion bus uses only 8 bits. The default is to use
+          16 bits.
+        $ref: /schemas/types.yaml#/definitions/flag
+
+    unevaluatedProperties: false
+
+required:
+  - compatible
+  - reg
+  - "#address-cells"
+  - "#size-cells"
+  - ranges
+  - dma-ranges
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/irq.h>
+    bus@50000000 {
+        compatible = "intel,ixp42x-expansion-bus-controller";
+        reg = <0xc4000000 0x28>;
+        #address-cells = <2>;
+        #size-cells = <1>;
+        ranges = <0 0x0 0x50000000 0x01000000>,
+                 <1 0x0 0x51000000 0x01000000>;
+        dma-ranges = <0 0x0 0x50000000 0x01000000>,
+                     <1 0x0 0x51000000 0x01000000>;
+        flash@0,0 {
+            compatible = "intel,ixp4xx-flash", "cfi-flash";
+            bank-width = <2>;
+            reg = <0 0x00000000 0x1000000>;
+            intel,ixp4xx-eb-t3 = <3>;
+            intel,ixp4xx-eb-byte-access-on-halfword;
+            intel,ixp4xx-eb-write-enable;
+        };
+        serial@1,0 {
+            compatible = "exar,xr16l2551", "ns8250";
+            reg = <1 0x00000000 0x10>;
+            interrupt-parent = <&gpio0>;
+            interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
+            clock-frequency = <1843200>;
+            intel,ixp4xx-eb-t3 = <3>;
+            intel,ixp4xx-eb-cycle-type = <1>;
+            intel,ixp4xx-eb-write-enable;
+            intel,ixp4xx-eb-byte-access;
+        };
+    };
-- 
2.31.1


^ permalink raw reply related	[flat|nested] 13+ messages in thread

* [PATCH 1/2] bus: ixp4xx: Add DT bindings for the IXP4xx expansion bus
@ 2021-07-17  0:16 ` Linus Walleij
  0 siblings, 0 replies; 13+ messages in thread
From: Linus Walleij @ 2021-07-17  0:16 UTC (permalink / raw)
  To: linux-arm-kernel, Imre Kaloz, Krzysztof Halasa
  Cc: Linus Walleij, Marc Zyngier, devicetree

This adds device tree bindings for the IXP4xx expansion bus controller.

Cc: Marc Zyngier <maz@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
 ...intel,ixp4xx-expansion-bus-controller.yaml | 151 ++++++++++++++++++
 1 file changed, 151 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/bus/intel,ixp4xx-expansion-bus-controller.yaml

diff --git a/Documentation/devicetree/bindings/bus/intel,ixp4xx-expansion-bus-controller.yaml b/Documentation/devicetree/bindings/bus/intel,ixp4xx-expansion-bus-controller.yaml
new file mode 100644
index 000000000000..0875b653c35c
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/intel,ixp4xx-expansion-bus-controller.yaml
@@ -0,0 +1,151 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/bus/intel,ixp4xx-expansion-bus-controller.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intel IXP4xx Expansion Bus Controller
+
+description: |
+  The IXP4xx expansion bus controller handles access to devices on the
+  memory-mapped expansion bus on the Intel IXP4xx family of system on chips,
+  including IXP42x, IXP43x, IXP45x and IXP46x.
+
+maintainers:
+  - Linus Walleij <linus.walleij@linaro.org>
+
+properties:
+  $nodename:
+    pattern: '^bus@[0-9a-f]+$'
+
+  compatible:
+    enum:
+      - intel,ixp42x-expansion-bus-controller
+      - intel,ixp43x-expansion-bus-controller
+      - intel,ixp45x-expansion-bus-controller
+      - intel,ixp46x-expansion-bus-controller
+
+  reg:
+    description: Control registers for the expansion bus, these are not
+      inside the memory range handled by the expansion bus.
+    maxItems: 1
+
+  "#address-cells":
+    description: |
+      The first cell is the chip select numer.
+      The second cell is the address offset within the bank.
+    const: 2
+
+  "#size-cells":
+    const: 1
+
+  ranges: true
+  dma-ranges: true
+
+patternProperties:
+  "^.*@[0-7],[0-9a-f]+$":
+    description: Devices attached to chip selects are represented as
+      subnodes.
+    type: object
+
+    properties:
+      intel,ixp4xx-eb-t1:
+        description: Address timing, extend address phase with n cycles.
+        $ref: /schemas/types.yaml#/definitions/uint32
+        maximum: 3
+
+      intel,ixp4xx-eb-t2:
+        description: Setup chip select timing, extend setup phase with n cycles.
+        $ref: /schemas/types.yaml#/definitions/uint32
+        maximum: 3
+
+      intel,ixp4xx-eb-t3:
+        description: Strobe timing, extend strobe phase with n cycles.
+        $ref: /schemas/types.yaml#/definitions/uint32
+        maximum: 15
+
+      intel,ixp4xx-eb-t4:
+        description: Hold timing, extend hold phase with n cycles.
+        $ref: /schemas/types.yaml#/definitions/uint32
+        maximum: 3
+
+      intel,ixp4xx-eb-t5:
+        description: Recovery timing, extend recovery phase with n cycles.
+        $ref: /schemas/types.yaml#/definitions/uint32
+        maximum: 15
+
+      intel,ixp4xx-eb-cycle-type:
+        description: The type of cycles to use on the expansion bus for this
+          chip select. 0 = Intel cycles, 1 = Motorola cycles, 2 = HPI cycles.
+        $ref: /schemas/types.yaml#/definitions/uint32
+        enum: [0, 1, 2]
+
+      intel,ixp4xx-eb-byte-access-on-halfword:
+        description: Allow byte read access on half word devices.
+        $ref: /schemas/types.yaml#/definitions/flag
+
+      intel,ixp4xx-eb-hpi-hrdy-pol-high:
+        description: Set HPI HRDY polarity to active high when using HPI.
+        $ref: /schemas/types.yaml#/definitions/flag
+
+      intel,ixp4xx-eb-mux-address-and-data:
+        description: Multiplex address and data on the data bus.
+        $ref: /schemas/types.yaml#/definitions/flag
+
+      intel,ixp4xx-eb-ahb-split-transfers:
+        description: Enable AHB split transfers.
+        $ref: /schemas/types.yaml#/definitions/flag
+
+      intel,ixp4xx-eb-write-enable:
+        description: Enable write cycles.
+        $ref: /schemas/types.yaml#/definitions/flag
+
+      intel,ixp4xx-eb-byte-access:
+        description: Expansion bus uses only 8 bits. The default is to use
+          16 bits.
+        $ref: /schemas/types.yaml#/definitions/flag
+
+    unevaluatedProperties: false
+
+required:
+  - compatible
+  - reg
+  - "#address-cells"
+  - "#size-cells"
+  - ranges
+  - dma-ranges
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/irq.h>
+    bus@50000000 {
+        compatible = "intel,ixp42x-expansion-bus-controller";
+        reg = <0xc4000000 0x28>;
+        #address-cells = <2>;
+        #size-cells = <1>;
+        ranges = <0 0x0 0x50000000 0x01000000>,
+                 <1 0x0 0x51000000 0x01000000>;
+        dma-ranges = <0 0x0 0x50000000 0x01000000>,
+                     <1 0x0 0x51000000 0x01000000>;
+        flash@0,0 {
+            compatible = "intel,ixp4xx-flash", "cfi-flash";
+            bank-width = <2>;
+            reg = <0 0x00000000 0x1000000>;
+            intel,ixp4xx-eb-t3 = <3>;
+            intel,ixp4xx-eb-byte-access-on-halfword;
+            intel,ixp4xx-eb-write-enable;
+        };
+        serial@1,0 {
+            compatible = "exar,xr16l2551", "ns8250";
+            reg = <1 0x00000000 0x10>;
+            interrupt-parent = <&gpio0>;
+            interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
+            clock-frequency = <1843200>;
+            intel,ixp4xx-eb-t3 = <3>;
+            intel,ixp4xx-eb-cycle-type = <1>;
+            intel,ixp4xx-eb-write-enable;
+            intel,ixp4xx-eb-byte-access;
+        };
+    };
-- 
2.31.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 13+ messages in thread

* [PATCH 2/2] bus: ixp4xx: Add a driver for IXP4xx expansion bus
  2021-07-17  0:16 ` Linus Walleij
  (?)
@ 2021-07-17  0:16 ` Linus Walleij
  -1 siblings, 0 replies; 13+ messages in thread
From: Linus Walleij @ 2021-07-17  0:16 UTC (permalink / raw)
  To: linux-arm-kernel, Imre Kaloz, Krzysztof Halasa
  Cc: Linus Walleij, Marc Zyngier

The Intel IXP4xx SoCs have an expansion bus that is usually just
used for flash memory and configured by the boot loaders and can
be accessed using the "simple-bus".

However some devices need more elaborate configuration and then we
need to provide a proper 3-unit address space indicating chip
select for each device and provide timing and similar information.

Cc: Marc Zyngier <maz@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
 MAINTAINERS                   |   2 +
 drivers/bus/Kconfig           |  10 ++
 drivers/bus/Makefile          |   1 +
 drivers/bus/intel-ixp4xx-eb.c | 288 ++++++++++++++++++++++++++++++++++
 4 files changed, 301 insertions(+)
 create mode 100644 drivers/bus/intel-ixp4xx-eb.c

diff --git a/MAINTAINERS b/MAINTAINERS
index a61f4f3b78a9..883da28d8406 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2009,10 +2009,12 @@ M:	Krzysztof Halasa <khalasa@piap.pl>
 L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
 S:	Maintained
 F:	Documentation/devicetree/bindings/arm/intel-ixp4xx.yaml
+F:	Documentation/devicetree/bindings/bus/intel,ixp4xx-expansion-bus-controller.yaml
 F:	Documentation/devicetree/bindings/gpio/intel,ixp4xx-gpio.txt
 F:	Documentation/devicetree/bindings/interrupt-controller/intel,ixp4xx-interrupt.yaml
 F:	Documentation/devicetree/bindings/timer/intel,ixp4xx-timer.yaml
 F:	arch/arm/mach-ixp4xx/
+F:	drivers/bus/intel-ixp4xx-eb.c
 F:	drivers/clocksource/timer-ixp4xx.c
 F:	drivers/crypto/ixp4xx_crypto.c
 F:	drivers/gpio/gpio-ixp4xx.c
diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index e7f7eee6ee9a..c00852583f70 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -95,6 +95,16 @@ config IMX_WEIM
 	  The WEIM(Wireless External Interface Module) works like a bus.
 	  You can attach many different devices on it, such as NOR, onenand.
 
+config INTEL_IXP4XX_EB
+	bool "Intel IXP4xx expansion bus interface driver"
+	depends on HAS_IOMEM
+	depends on ARCH_IXP4XX || COMPILE_TEST
+	default ARCH_IXP4XX
+	help
+	  Driver for the Intel IXP4xx expansion bus interface. The driver is
+	  needed to set up various chip select configuration parameters before
+	  devices on the expansion bus can be discovered.
+
 config MIPS_CDMM
 	bool "MIPS Common Device Memory Map (CDMM) Driver"
 	depends on CPU_MIPSR2 || CPU_MIPSR5
diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile
index 397e35392bff..1c29c5e8ffb8 100644
--- a/drivers/bus/Makefile
+++ b/drivers/bus/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_FSL_MC_BUS)	+= fsl-mc/
 obj-$(CONFIG_BT1_APB)		+= bt1-apb.o
 obj-$(CONFIG_BT1_AXI)		+= bt1-axi.o
 obj-$(CONFIG_IMX_WEIM)		+= imx-weim.o
+obj-$(CONFIG_INTEL_IXP4XX_EB)	+= intel-ixp4xx-eb.o
 obj-$(CONFIG_MIPS_CDMM)		+= mips_cdmm.o
 obj-$(CONFIG_MVEBU_MBUS) 	+= mvebu-mbus.o
 
diff --git a/drivers/bus/intel-ixp4xx-eb.c b/drivers/bus/intel-ixp4xx-eb.c
new file mode 100644
index 000000000000..a97fef9eba2a
--- /dev/null
+++ b/drivers/bus/intel-ixp4xx-eb.c
@@ -0,0 +1,288 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Intel IXP4xx Expansion Bus Controller
+ * Copyright (C) 2021 Linaro Ltd.
+ *
+ * Author: Linus Walleij <linus.walleij@linaro.org>
+ */
+
+#include <linux/module.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/init.h>
+#include <linux/platform_device.h>
+#include <linux/bits.h>
+#include <linux/log2.h>
+
+#define IXP4XX_EXP_TIMING_CS0		0x00
+#define IXP4XX_EXP_TIMING_CS1		0x04
+#define IXP4XX_EXP_TIMING_CS2		0x08
+#define IXP4XX_EXP_TIMING_CS3		0x0c
+#define IXP4XX_EXP_TIMING_CS4		0x10
+#define IXP4XX_EXP_TIMING_CS5		0x14
+#define IXP4XX_EXP_TIMING_CS6		0x18
+#define IXP4XX_EXP_TIMING_CS7		0x1c
+
+/* Bits inside each CS timing register */
+#define IXP4XX_EXP_TIMING_STRIDE	0x04
+#define IXP4XX_EXP_CS_EN		BIT(31)
+#define IXP456_EXP_PAR_EN		BIT(30) /* Only on IXP45x and IXP46x */
+#define IXP4XX_EXP_T1_SHIFT		28
+#define IXP4XX_EXP_T2_SHIFT		26
+#define IXP4XX_EXP_T3_SHIFT		22
+#define IXP4XX_EXP_T4_SHIFT		20
+#define IXP4XX_EXP_T5_SHIFT		16
+#define IXP4XX_EXP_CYC_TYPE_MASK	GENMASK(15, 14)
+#define IXP4XX_EXP_CYC_TYPE_SHIFT	14
+#define IXP4XX_EXP_SIZE_MASK		GENMASK(13, 10)
+#define IXP4XX_EXP_SIZE_SHIFT		10
+#define IXP4XX_EXP_CNFG_0		BIT(9) /* Always zero */
+#define IXP43X_EXP_SYNC_INTEL		BIT(8) /* Only on IXP43x */
+#define IXP43X_EXP_EXP_CHIP		BIT(7) /* Only on IXP43x */
+#define IXP4XX_EXP_BYTE_RD16		BIT(6)
+#define IXP4XX_EXP_HRDY_POL		BIT(5) /* Only on IXP42x */
+#define IXP4XX_EXP_MUX_EN		BIT(4)
+#define IXP4XX_EXP_SPLT_EN		BIT(3)
+#define IXP4XX_EXP_WORD			BIT(2) /* Always zero */
+#define IXP4XX_EXP_WR_EN		BIT(1)
+#define IXP4XX_EXP_BYTE_EN		BIT(0)
+
+#define IXP4XX_EXP_CNFG0		0x20
+#define IXP4XX_EXP_CNFG0_MEM_MAP	BIT(31)
+#define IXP4XX_EXP_CNFG1		0x24
+
+#define IXP4XX_EXP_BOOT_BASE		0x00000000
+#define IXP4XX_EXP_NORMAL_BASE		0x50000000
+#define IXP4XX_EXP_STRIDE		0x01000000
+
+struct ixp4xx_exp_tim_prop {
+	const char *prop;
+	u32 max;
+	u16 shift;
+};
+
+static const struct ixp4xx_exp_tim_prop ixp4xx_exp_tim_props[] = {
+	{
+		.prop = "intel,ixp4xx-eb-t1",
+		.max = 3,
+		.shift = IXP4XX_EXP_T1_SHIFT,
+	},
+	{
+		.prop = "intel,ixp4xx-eb-t2",
+		.max = 3,
+		.shift = IXP4XX_EXP_T2_SHIFT,
+	},
+	{
+		.prop = "intel,ixp4xx-eb-t3",
+		.max = 15,
+		.shift = IXP4XX_EXP_T3_SHIFT,
+	},
+	{
+		.prop = "intel,ixp4xx-eb-t4",
+		.max = 3,
+		.shift = IXP4XX_EXP_T4_SHIFT,
+	},
+	{
+		.prop = "intel,ixp4xx-eb-t5",
+		.max = 15,
+		.shift = IXP4XX_EXP_T5_SHIFT,
+	},
+};
+
+static void ixp4xx_exp_setup_chipselect(struct device_node *np,
+					struct device *dev,
+					void __iomem *base,
+					u32 bus_base,
+					u32 cs_index,
+					u32 cs_size)
+{
+	u32 cs_cfg;
+	u32 val;
+	u32 cur_cssize;
+	u32 cs_order;
+	int ret;
+	int i;
+
+	if (cs_index > 7) {
+		dev_err(dev,
+			"invalid chipselect %u, we only support 0-7\n",
+			cs_index);
+		return;
+	}
+
+	/* Several chip selects can be joined into one device */
+	if (cs_size > IXP4XX_EXP_STRIDE)
+		cur_cssize = IXP4XX_EXP_STRIDE;
+	else
+		cur_cssize = cs_size;
+
+
+	/*
+	 * The following will read/modify/write the configuration for one
+	 * chipselect, attempting to leave the boot defaults in place unless
+	 * something is explicitly defined.
+	 */
+	cs_cfg = readl(base + IXP4XX_EXP_TIMING_CS0 +
+		       IXP4XX_EXP_TIMING_STRIDE * cs_index);
+	dev_info(dev, "CS%d at %#08x, size %#08x, config before: %#08x\n",
+		 cs_index, bus_base + IXP4XX_EXP_STRIDE * cs_index,
+		 cur_cssize, cs_cfg);
+
+	/* Size set-up first align to 2^9 .. 2^24 */
+	cur_cssize = roundup_pow_of_two(cur_cssize);
+	if (cur_cssize < 512)
+		cur_cssize = 512;
+	cs_order = ilog2(cur_cssize);
+	if (cs_order < 9 || cs_order > 24) {
+		dev_err(dev, "illegal size order %d\n", cs_order);
+		return;
+	}
+	dev_dbg(dev, "CS%d size order: %d\n", cs_index, cs_order);
+	cs_cfg &= ~(IXP4XX_EXP_SIZE_MASK);
+	cs_cfg |= ((cs_order - 9) << IXP4XX_EXP_SIZE_SHIFT);
+
+	for (i = 0; i < ARRAY_SIZE(ixp4xx_exp_tim_props); i++) {
+		const struct ixp4xx_exp_tim_prop *ip = &ixp4xx_exp_tim_props[i];
+
+		/* All are regular u32 values */
+		ret = of_property_read_u32(np, ip->prop, &val);
+		if (ret)
+			continue;
+
+		if (val > ip->max) {
+			dev_err(dev,
+				"too high value for %s: %u, capped at %u\n",
+				ip->prop, val, ip->max);
+			val = ip->max;
+		}
+		/* This assumes max value fills all the assigned bits (and it does) */
+		cs_cfg &= ~ip->max;
+		cs_cfg |= (val << ip->shift);
+		dev_info(dev, "set %s to %u\n", ip->prop, val);
+	}
+
+	ret = of_property_read_u32(np, "intel,ixp4xx-eb-cycle-type", &val);
+	if (!ret) {
+		if (val > 3) {
+			dev_err(dev, "illegal cycle typ %d\n", val);
+			return;
+		}
+		cs_cfg &= ~IXP4XX_EXP_CYC_TYPE_MASK;
+		cs_cfg |= val << IXP4XX_EXP_CYC_TYPE_SHIFT;
+	}
+
+	if (of_property_read_bool(np, "intel,ixp4xx-eb-byte-access-on-halfword"))
+		cs_cfg |= IXP4XX_EXP_BYTE_RD16;
+
+	if (of_property_read_bool(np, "intel,ixp4xx-eb-hpi-hrdy-pol-high"))
+		cs_cfg |= IXP4XX_EXP_HRDY_POL;
+
+	if (of_property_read_bool(np, "intel,ixp4xx-eb-mux-address-and-data"))
+		cs_cfg |= IXP4XX_EXP_MUX_EN;
+
+	if (of_property_read_bool(np, "intel,ixp4xx-eb-ahb-split-transfers"))
+		cs_cfg |= IXP4XX_EXP_SPLT_EN;
+
+	if (of_property_read_bool(np, "intel,ixp4xx-eb-write-enable"))
+		cs_cfg |= IXP4XX_EXP_WR_EN;
+
+	/* Bus width, 8 (byte) or 16 bytes */
+	if (of_property_read_bool(np, "intel,ixp4xx-eb-byte-access"))
+		cs_cfg |= IXP4XX_EXP_BYTE_EN;
+
+	cs_cfg |= IXP4XX_EXP_CS_EN;
+
+	writel(cs_cfg, base + IXP4XX_EXP_TIMING_CS0 +
+	       IXP4XX_EXP_TIMING_STRIDE * cs_index);
+	dev_info(dev, "wrote %#08x into CS%d config\n", cs_cfg, cs_index);
+
+	/*
+	 * If several chip selects are joined together into one big
+	 * device area, we call ourselves recursively for each successive
+	 * chip select. For a 32MB flash chip this results in two calls
+	 * for example.
+	 */
+	if (cs_size > IXP4XX_EXP_STRIDE)
+		ixp4xx_exp_setup_chipselect(np, dev, base, bus_base,
+					    cs_index + 1,
+					    cs_size - IXP4XX_EXP_STRIDE);
+}
+
+static int ixp4xx_exp_probe(struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	struct device_node *child;
+	struct device *dev = &pdev->dev;
+	struct resource *res;
+	void __iomem *base;
+	bool have_children = false;
+	u32 bus_base;
+	u32 val;
+	int ret;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	base = devm_ioremap_resource(dev, res);
+	if (IS_ERR(base))
+		return dev_err_probe(dev, PTR_ERR(base),
+				     "no IO base\n");
+
+	val = readl(base + IXP4XX_EXP_CNFG0);
+	if (val & IXP4XX_EXP_CNFG0_MEM_MAP)
+		bus_base = IXP4XX_EXP_BOOT_BASE;
+	else
+		bus_base = IXP4XX_EXP_NORMAL_BASE;
+	dev_info(dev, "expansion bus at %08x\n", bus_base);
+
+	/* Walk over the child nodes and see what chipselects we use */
+	for_each_available_child_of_node(np, child) {
+		u32 reg[3];
+		u32 csindex;
+		u32 cssize;
+
+		/* Figure out the chipselect details */
+		ret = of_property_read_u32_array(child, "reg", reg, ARRAY_SIZE(reg));
+		if (ret < 0) {
+			of_node_put(child);
+			return ret;
+		}
+		csindex = reg[0];
+		cssize = reg[2];
+
+		ixp4xx_exp_setup_chipselect(child,
+					    dev,
+					    base,
+					    bus_base,
+					    csindex,
+					    cssize);
+
+		/* We have at least one child */
+		have_children = true;
+	}
+
+	if (have_children)
+		return of_platform_default_populate(np, NULL, dev);
+
+	return 0;
+}
+
+static const struct of_device_id ixp4xx_exp_of_match[] = {
+	{ .compatible = "intel,ixp42x-expansion-bus-controller", },
+	{ .compatible = "intel,ixp43x-expansion-bus-controller", },
+	{ .compatible = "intel,ixp45x-expansion-bus-controller", },
+	{ .compatible = "intel,ixp46x-expansion-bus-controller", },
+	{ }
+};
+
+static struct platform_driver ixp4xx_exp_driver = {
+	.probe = ixp4xx_exp_probe,
+	.driver = {
+		.name = "intel-extbus",
+		.of_match_table = ixp4xx_exp_of_match,
+	},
+};
+module_platform_driver(ixp4xx_exp_driver);
+MODULE_AUTHOR("Linus Walleij <linus.walleij@linaro.org>");
+MODULE_DESCRIPTION("Intel IXP4xx external bus driver");
+MODULE_LICENSE("GPL");
-- 
2.31.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 13+ messages in thread

* Re: [PATCH 1/2] bus: ixp4xx: Add DT bindings for the IXP4xx expansion bus
  2021-07-17  0:16 ` Linus Walleij
@ 2021-07-19 13:47   ` Rob Herring
  -1 siblings, 0 replies; 13+ messages in thread
From: Rob Herring @ 2021-07-19 13:47 UTC (permalink / raw)
  To: Linus Walleij
  Cc: Imre Kaloz, devicetree, Marc Zyngier, linux-arm-kernel, Krzysztof Halasa

On Sat, 17 Jul 2021 02:16:37 +0200, Linus Walleij wrote:
> This adds device tree bindings for the IXP4xx expansion bus controller.
> 
> Cc: Marc Zyngier <maz@kernel.org>
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
>  ...intel,ixp4xx-expansion-bus-controller.yaml | 151 ++++++++++++++++++
>  1 file changed, 151 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/bus/intel,ixp4xx-expansion-bus-controller.yaml
> 

My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):

yamllint warnings/errors:

dtschema/dtc warnings/errors:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/bus/intel,ixp4xx-expansion-bus-controller.example.dt.yaml: serial@1,0: compatible: 'oneOf' conditional failed, one must be fixed:
	['exar,xr16l2551', 'ns8250'] is too long
	Additional items are not allowed ('ns8250' was unexpected)
	['exar,xr16l2551', 'ns8250'] is too short
	'ns8250' was expected
	'ns16450' was expected
	'ns16550' was expected
	'ns16550a' was expected
	'ns16850' was expected
	'aspeed,ast2400-vuart' was expected
	'aspeed,ast2500-vuart' was expected
	'intel,xscale-uart' was expected
	'mrvl,pxa-uart' was expected
	'nuvoton,wpcm450-uart' was expected
	'nuvoton,npcm750-uart' was expected
	'nvidia,tegra20-uart' was expected
	'nxp,lpc3220-uart' was expected
	'exar,xr16l2551' is not one of ['altr,16550-FIFO32', 'altr,16550-FIFO64', 'altr,16550-FIFO128', 'fsl,16550-FIFO64', 'fsl,ns16550', 'andestech,uart16550', 'nxp,lpc1850-uart', 'opencores,uart16550-rtlsvn105', 'ti,da830-uart']
	'exar,xr16l2551' is not one of ['ns16750', 'cavium,octeon-3860-uart', 'xlnx,xps-uart16550-2.00.b', 'ralink,rt2880-uart']
	'exar,xr16l2551' is not one of ['ralink,mt7620a-uart', 'ralink,rt3052-uart', 'ralink,rt3883-uart']
	'exar,xr16l2551' is not one of ['mediatek,mt7622-btif', 'mediatek,mt7623-btif']
	'mrvl,mmp-uart' was expected
	'exar,xr16l2551' is not one of ['nvidia,tegra30-uart', 'nvidia,tegra114-uart', 'nvidia,tegra124-uart', 'nvidia,tegra186-uart', 'nvidia,tegra194-uart', 'nvidia,tegra210-uart']
	'ns8250' is not one of ['ns16550', 'ns16550a']
	'ralink,rt2880-uart' was expected
	'mediatek,mtk-btif' was expected
	From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/serial/8250.yaml
Documentation/devicetree/bindings/bus/intel,ixp4xx-expansion-bus-controller.example.dt.yaml:0:0: /example-0/bus@50000000/serial@1,0: failed to match any schema with compatible: ['exar,xr16l2551', 'ns8250']
\ndoc reference errors (make refcheckdocs):

See https://patchwork.ozlabs.org/patch/1506323

This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit.


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 1/2] bus: ixp4xx: Add DT bindings for the IXP4xx expansion bus
@ 2021-07-19 13:47   ` Rob Herring
  0 siblings, 0 replies; 13+ messages in thread
From: Rob Herring @ 2021-07-19 13:47 UTC (permalink / raw)
  To: Linus Walleij
  Cc: Imre Kaloz, devicetree, Marc Zyngier, linux-arm-kernel, Krzysztof Halasa

On Sat, 17 Jul 2021 02:16:37 +0200, Linus Walleij wrote:
> This adds device tree bindings for the IXP4xx expansion bus controller.
> 
> Cc: Marc Zyngier <maz@kernel.org>
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
>  ...intel,ixp4xx-expansion-bus-controller.yaml | 151 ++++++++++++++++++
>  1 file changed, 151 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/bus/intel,ixp4xx-expansion-bus-controller.yaml
> 

My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):

yamllint warnings/errors:

dtschema/dtc warnings/errors:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/bus/intel,ixp4xx-expansion-bus-controller.example.dt.yaml: serial@1,0: compatible: 'oneOf' conditional failed, one must be fixed:
	['exar,xr16l2551', 'ns8250'] is too long
	Additional items are not allowed ('ns8250' was unexpected)
	['exar,xr16l2551', 'ns8250'] is too short
	'ns8250' was expected
	'ns16450' was expected
	'ns16550' was expected
	'ns16550a' was expected
	'ns16850' was expected
	'aspeed,ast2400-vuart' was expected
	'aspeed,ast2500-vuart' was expected
	'intel,xscale-uart' was expected
	'mrvl,pxa-uart' was expected
	'nuvoton,wpcm450-uart' was expected
	'nuvoton,npcm750-uart' was expected
	'nvidia,tegra20-uart' was expected
	'nxp,lpc3220-uart' was expected
	'exar,xr16l2551' is not one of ['altr,16550-FIFO32', 'altr,16550-FIFO64', 'altr,16550-FIFO128', 'fsl,16550-FIFO64', 'fsl,ns16550', 'andestech,uart16550', 'nxp,lpc1850-uart', 'opencores,uart16550-rtlsvn105', 'ti,da830-uart']
	'exar,xr16l2551' is not one of ['ns16750', 'cavium,octeon-3860-uart', 'xlnx,xps-uart16550-2.00.b', 'ralink,rt2880-uart']
	'exar,xr16l2551' is not one of ['ralink,mt7620a-uart', 'ralink,rt3052-uart', 'ralink,rt3883-uart']
	'exar,xr16l2551' is not one of ['mediatek,mt7622-btif', 'mediatek,mt7623-btif']
	'mrvl,mmp-uart' was expected
	'exar,xr16l2551' is not one of ['nvidia,tegra30-uart', 'nvidia,tegra114-uart', 'nvidia,tegra124-uart', 'nvidia,tegra186-uart', 'nvidia,tegra194-uart', 'nvidia,tegra210-uart']
	'ns8250' is not one of ['ns16550', 'ns16550a']
	'ralink,rt2880-uart' was expected
	'mediatek,mtk-btif' was expected
	From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/serial/8250.yaml
Documentation/devicetree/bindings/bus/intel,ixp4xx-expansion-bus-controller.example.dt.yaml:0:0: /example-0/bus@50000000/serial@1,0: failed to match any schema with compatible: ['exar,xr16l2551', 'ns8250']
\ndoc reference errors (make refcheckdocs):

See https://patchwork.ozlabs.org/patch/1506323

This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit.


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 1/2] bus: ixp4xx: Add DT bindings for the IXP4xx expansion bus
  2021-07-19 13:47   ` Rob Herring
@ 2021-07-19 14:10     ` Linus Walleij
  -1 siblings, 0 replies; 13+ messages in thread
From: Linus Walleij @ 2021-07-19 14:10 UTC (permalink / raw)
  To: Rob Herring
  Cc: Imre Kaloz,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	Marc Zyngier, Linux ARM, Krzysztof Halasa

On Mon, Jul 19, 2021 at 3:47 PM Rob Herring <robh@kernel.org> wrote:

> My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
> on your patch (DT_CHECKER_FLAGS is new in v5.13):
>
> yamllint warnings/errors:
>
> dtschema/dtc warnings/errors:
> /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/bus/intel,ixp4xx-expansion-bus-controller.example.dt.yaml: serial@1,0: compatible: 'oneOf' conditional failed, one must be fixed:
>         ['exar,xr16l2551', 'ns8250'] is too long
>         Additional items are not allowed ('ns8250' was unexpected)
>         ['exar,xr16l2551', 'ns8250'] is too short

This is because the patch adding these compatibles was sent separately
so it can be merged into the tty subsystem.

So pretty much false alarm, but the bot can't know everything.

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 1/2] bus: ixp4xx: Add DT bindings for the IXP4xx expansion bus
@ 2021-07-19 14:10     ` Linus Walleij
  0 siblings, 0 replies; 13+ messages in thread
From: Linus Walleij @ 2021-07-19 14:10 UTC (permalink / raw)
  To: Rob Herring
  Cc: Imre Kaloz,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	Marc Zyngier, Linux ARM, Krzysztof Halasa

On Mon, Jul 19, 2021 at 3:47 PM Rob Herring <robh@kernel.org> wrote:

> My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
> on your patch (DT_CHECKER_FLAGS is new in v5.13):
>
> yamllint warnings/errors:
>
> dtschema/dtc warnings/errors:
> /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/bus/intel,ixp4xx-expansion-bus-controller.example.dt.yaml: serial@1,0: compatible: 'oneOf' conditional failed, one must be fixed:
>         ['exar,xr16l2551', 'ns8250'] is too long
>         Additional items are not allowed ('ns8250' was unexpected)
>         ['exar,xr16l2551', 'ns8250'] is too short

This is because the patch adding these compatibles was sent separately
so it can be merged into the tty subsystem.

So pretty much false alarm, but the bot can't know everything.

Yours,
Linus Walleij

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 1/2] bus: ixp4xx: Add DT bindings for the IXP4xx expansion bus
  2021-07-17  0:16 ` Linus Walleij
@ 2021-07-19 15:18   ` Rob Herring
  -1 siblings, 0 replies; 13+ messages in thread
From: Rob Herring @ 2021-07-19 15:18 UTC (permalink / raw)
  To: Linus Walleij
  Cc: linux-arm-kernel, Imre Kaloz, Krzysztof Halasa, Marc Zyngier, devicetree

On Sat, Jul 17, 2021 at 02:16:37AM +0200, Linus Walleij wrote:
> This adds device tree bindings for the IXP4xx expansion bus controller.
> 
> Cc: Marc Zyngier <maz@kernel.org>
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
>  ...intel,ixp4xx-expansion-bus-controller.yaml | 151 ++++++++++++++++++
>  1 file changed, 151 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/bus/intel,ixp4xx-expansion-bus-controller.yaml
> 
> diff --git a/Documentation/devicetree/bindings/bus/intel,ixp4xx-expansion-bus-controller.yaml b/Documentation/devicetree/bindings/bus/intel,ixp4xx-expansion-bus-controller.yaml
> new file mode 100644
> index 000000000000..0875b653c35c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/bus/intel,ixp4xx-expansion-bus-controller.yaml
> @@ -0,0 +1,151 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/bus/intel,ixp4xx-expansion-bus-controller.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Intel IXP4xx Expansion Bus Controller
> +
> +description: |
> +  The IXP4xx expansion bus controller handles access to devices on the
> +  memory-mapped expansion bus on the Intel IXP4xx family of system on chips,
> +  including IXP42x, IXP43x, IXP45x and IXP46x.
> +
> +maintainers:
> +  - Linus Walleij <linus.walleij@linaro.org>
> +
> +properties:
> +  $nodename:
> +    pattern: '^bus@[0-9a-f]+$'
> +
> +  compatible:
> +    enum:
> +      - intel,ixp42x-expansion-bus-controller
> +      - intel,ixp43x-expansion-bus-controller
> +      - intel,ixp45x-expansion-bus-controller
> +      - intel,ixp46x-expansion-bus-controller
> +
> +  reg:
> +    description: Control registers for the expansion bus, these are not
> +      inside the memory range handled by the expansion bus.
> +    maxItems: 1
> +
> +  "#address-cells":
> +    description: |
> +      The first cell is the chip select numer.
> +      The second cell is the address offset within the bank.
> +    const: 2
> +
> +  "#size-cells":
> +    const: 1
> +
> +  ranges: true
> +  dma-ranges: true
> +
> +patternProperties:
> +  "^.*@[0-7],[0-9a-f]+$":
> +    description: Devices attached to chip selects are represented as
> +      subnodes.
> +    type: object
> +
> +    properties:
> +      intel,ixp4xx-eb-t1:
> +        description: Address timing, extend address phase with n cycles.
> +        $ref: /schemas/types.yaml#/definitions/uint32
> +        maximum: 3
> +
> +      intel,ixp4xx-eb-t2:
> +        description: Setup chip select timing, extend setup phase with n cycles.
> +        $ref: /schemas/types.yaml#/definitions/uint32
> +        maximum: 3
> +
> +      intel,ixp4xx-eb-t3:
> +        description: Strobe timing, extend strobe phase with n cycles.
> +        $ref: /schemas/types.yaml#/definitions/uint32
> +        maximum: 15
> +
> +      intel,ixp4xx-eb-t4:
> +        description: Hold timing, extend hold phase with n cycles.
> +        $ref: /schemas/types.yaml#/definitions/uint32
> +        maximum: 3
> +
> +      intel,ixp4xx-eb-t5:
> +        description: Recovery timing, extend recovery phase with n cycles.
> +        $ref: /schemas/types.yaml#/definitions/uint32
> +        maximum: 15
> +
> +      intel,ixp4xx-eb-cycle-type:
> +        description: The type of cycles to use on the expansion bus for this
> +          chip select. 0 = Intel cycles, 1 = Motorola cycles, 2 = HPI cycles.
> +        $ref: /schemas/types.yaml#/definitions/uint32
> +        enum: [0, 1, 2]
> +
> +      intel,ixp4xx-eb-byte-access-on-halfword:
> +        description: Allow byte read access on half word devices.
> +        $ref: /schemas/types.yaml#/definitions/flag
> +
> +      intel,ixp4xx-eb-hpi-hrdy-pol-high:
> +        description: Set HPI HRDY polarity to active high when using HPI.
> +        $ref: /schemas/types.yaml#/definitions/flag
> +
> +      intel,ixp4xx-eb-mux-address-and-data:
> +        description: Multiplex address and data on the data bus.
> +        $ref: /schemas/types.yaml#/definitions/flag
> +
> +      intel,ixp4xx-eb-ahb-split-transfers:
> +        description: Enable AHB split transfers.
> +        $ref: /schemas/types.yaml#/definitions/flag
> +
> +      intel,ixp4xx-eb-write-enable:
> +        description: Enable write cycles.
> +        $ref: /schemas/types.yaml#/definitions/flag
> +
> +      intel,ixp4xx-eb-byte-access:
> +        description: Expansion bus uses only 8 bits. The default is to use
> +          16 bits.
> +        $ref: /schemas/types.yaml#/definitions/flag
> +
> +    unevaluatedProperties: false

This will cause failures when implemented. The problem is this won't 
allow any other child node properties as this schema and the device 
schema are evaluated independently. The only way I see to solve this is 
the child node schemas have to include some 'bus properties' schema 
which includes all possible bus controller properties. There's been a 
recent patch set doing this for SPI. At least here, I think the number 
of different child devices on parallel expansion buses are limited.

So spliting this to 2 schema files would be the first step. Minimally, 
just drop unevaluatedProperties.

> +
> +required:
> +  - compatible
> +  - reg
> +  - "#address-cells"
> +  - "#size-cells"
> +  - ranges
> +  - dma-ranges
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/interrupt-controller/irq.h>
> +    bus@50000000 {
> +        compatible = "intel,ixp42x-expansion-bus-controller";
> +        reg = <0xc4000000 0x28>;
> +        #address-cells = <2>;
> +        #size-cells = <1>;
> +        ranges = <0 0x0 0x50000000 0x01000000>,
> +                 <1 0x0 0x51000000 0x01000000>;
> +        dma-ranges = <0 0x0 0x50000000 0x01000000>,
> +                     <1 0x0 0x51000000 0x01000000>;
> +        flash@0,0 {
> +            compatible = "intel,ixp4xx-flash", "cfi-flash";
> +            bank-width = <2>;
> +            reg = <0 0x00000000 0x1000000>;
> +            intel,ixp4xx-eb-t3 = <3>;
> +            intel,ixp4xx-eb-byte-access-on-halfword;
> +            intel,ixp4xx-eb-write-enable;
> +        };
> +        serial@1,0 {
> +            compatible = "exar,xr16l2551", "ns8250";
> +            reg = <1 0x00000000 0x10>;
> +            interrupt-parent = <&gpio0>;
> +            interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
> +            clock-frequency = <1843200>;
> +            intel,ixp4xx-eb-t3 = <3>;
> +            intel,ixp4xx-eb-cycle-type = <1>;
> +            intel,ixp4xx-eb-write-enable;
> +            intel,ixp4xx-eb-byte-access;
> +        };
> +    };
> -- 
> 2.31.1
> 
> 

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 1/2] bus: ixp4xx: Add DT bindings for the IXP4xx expansion bus
@ 2021-07-19 15:18   ` Rob Herring
  0 siblings, 0 replies; 13+ messages in thread
From: Rob Herring @ 2021-07-19 15:18 UTC (permalink / raw)
  To: Linus Walleij
  Cc: linux-arm-kernel, Imre Kaloz, Krzysztof Halasa, Marc Zyngier, devicetree

On Sat, Jul 17, 2021 at 02:16:37AM +0200, Linus Walleij wrote:
> This adds device tree bindings for the IXP4xx expansion bus controller.
> 
> Cc: Marc Zyngier <maz@kernel.org>
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
>  ...intel,ixp4xx-expansion-bus-controller.yaml | 151 ++++++++++++++++++
>  1 file changed, 151 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/bus/intel,ixp4xx-expansion-bus-controller.yaml
> 
> diff --git a/Documentation/devicetree/bindings/bus/intel,ixp4xx-expansion-bus-controller.yaml b/Documentation/devicetree/bindings/bus/intel,ixp4xx-expansion-bus-controller.yaml
> new file mode 100644
> index 000000000000..0875b653c35c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/bus/intel,ixp4xx-expansion-bus-controller.yaml
> @@ -0,0 +1,151 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/bus/intel,ixp4xx-expansion-bus-controller.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Intel IXP4xx Expansion Bus Controller
> +
> +description: |
> +  The IXP4xx expansion bus controller handles access to devices on the
> +  memory-mapped expansion bus on the Intel IXP4xx family of system on chips,
> +  including IXP42x, IXP43x, IXP45x and IXP46x.
> +
> +maintainers:
> +  - Linus Walleij <linus.walleij@linaro.org>
> +
> +properties:
> +  $nodename:
> +    pattern: '^bus@[0-9a-f]+$'
> +
> +  compatible:
> +    enum:
> +      - intel,ixp42x-expansion-bus-controller
> +      - intel,ixp43x-expansion-bus-controller
> +      - intel,ixp45x-expansion-bus-controller
> +      - intel,ixp46x-expansion-bus-controller
> +
> +  reg:
> +    description: Control registers for the expansion bus, these are not
> +      inside the memory range handled by the expansion bus.
> +    maxItems: 1
> +
> +  "#address-cells":
> +    description: |
> +      The first cell is the chip select numer.
> +      The second cell is the address offset within the bank.
> +    const: 2
> +
> +  "#size-cells":
> +    const: 1
> +
> +  ranges: true
> +  dma-ranges: true
> +
> +patternProperties:
> +  "^.*@[0-7],[0-9a-f]+$":
> +    description: Devices attached to chip selects are represented as
> +      subnodes.
> +    type: object
> +
> +    properties:
> +      intel,ixp4xx-eb-t1:
> +        description: Address timing, extend address phase with n cycles.
> +        $ref: /schemas/types.yaml#/definitions/uint32
> +        maximum: 3
> +
> +      intel,ixp4xx-eb-t2:
> +        description: Setup chip select timing, extend setup phase with n cycles.
> +        $ref: /schemas/types.yaml#/definitions/uint32
> +        maximum: 3
> +
> +      intel,ixp4xx-eb-t3:
> +        description: Strobe timing, extend strobe phase with n cycles.
> +        $ref: /schemas/types.yaml#/definitions/uint32
> +        maximum: 15
> +
> +      intel,ixp4xx-eb-t4:
> +        description: Hold timing, extend hold phase with n cycles.
> +        $ref: /schemas/types.yaml#/definitions/uint32
> +        maximum: 3
> +
> +      intel,ixp4xx-eb-t5:
> +        description: Recovery timing, extend recovery phase with n cycles.
> +        $ref: /schemas/types.yaml#/definitions/uint32
> +        maximum: 15
> +
> +      intel,ixp4xx-eb-cycle-type:
> +        description: The type of cycles to use on the expansion bus for this
> +          chip select. 0 = Intel cycles, 1 = Motorola cycles, 2 = HPI cycles.
> +        $ref: /schemas/types.yaml#/definitions/uint32
> +        enum: [0, 1, 2]
> +
> +      intel,ixp4xx-eb-byte-access-on-halfword:
> +        description: Allow byte read access on half word devices.
> +        $ref: /schemas/types.yaml#/definitions/flag
> +
> +      intel,ixp4xx-eb-hpi-hrdy-pol-high:
> +        description: Set HPI HRDY polarity to active high when using HPI.
> +        $ref: /schemas/types.yaml#/definitions/flag
> +
> +      intel,ixp4xx-eb-mux-address-and-data:
> +        description: Multiplex address and data on the data bus.
> +        $ref: /schemas/types.yaml#/definitions/flag
> +
> +      intel,ixp4xx-eb-ahb-split-transfers:
> +        description: Enable AHB split transfers.
> +        $ref: /schemas/types.yaml#/definitions/flag
> +
> +      intel,ixp4xx-eb-write-enable:
> +        description: Enable write cycles.
> +        $ref: /schemas/types.yaml#/definitions/flag
> +
> +      intel,ixp4xx-eb-byte-access:
> +        description: Expansion bus uses only 8 bits. The default is to use
> +          16 bits.
> +        $ref: /schemas/types.yaml#/definitions/flag
> +
> +    unevaluatedProperties: false

This will cause failures when implemented. The problem is this won't 
allow any other child node properties as this schema and the device 
schema are evaluated independently. The only way I see to solve this is 
the child node schemas have to include some 'bus properties' schema 
which includes all possible bus controller properties. There's been a 
recent patch set doing this for SPI. At least here, I think the number 
of different child devices on parallel expansion buses are limited.

So spliting this to 2 schema files would be the first step. Minimally, 
just drop unevaluatedProperties.

> +
> +required:
> +  - compatible
> +  - reg
> +  - "#address-cells"
> +  - "#size-cells"
> +  - ranges
> +  - dma-ranges
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/interrupt-controller/irq.h>
> +    bus@50000000 {
> +        compatible = "intel,ixp42x-expansion-bus-controller";
> +        reg = <0xc4000000 0x28>;
> +        #address-cells = <2>;
> +        #size-cells = <1>;
> +        ranges = <0 0x0 0x50000000 0x01000000>,
> +                 <1 0x0 0x51000000 0x01000000>;
> +        dma-ranges = <0 0x0 0x50000000 0x01000000>,
> +                     <1 0x0 0x51000000 0x01000000>;
> +        flash@0,0 {
> +            compatible = "intel,ixp4xx-flash", "cfi-flash";
> +            bank-width = <2>;
> +            reg = <0 0x00000000 0x1000000>;
> +            intel,ixp4xx-eb-t3 = <3>;
> +            intel,ixp4xx-eb-byte-access-on-halfword;
> +            intel,ixp4xx-eb-write-enable;
> +        };
> +        serial@1,0 {
> +            compatible = "exar,xr16l2551", "ns8250";
> +            reg = <1 0x00000000 0x10>;
> +            interrupt-parent = <&gpio0>;
> +            interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
> +            clock-frequency = <1843200>;
> +            intel,ixp4xx-eb-t3 = <3>;
> +            intel,ixp4xx-eb-cycle-type = <1>;
> +            intel,ixp4xx-eb-write-enable;
> +            intel,ixp4xx-eb-byte-access;
> +        };
> +    };
> -- 
> 2.31.1
> 
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 1/2] bus: ixp4xx: Add DT bindings for the IXP4xx expansion bus
  2021-07-19 15:18   ` Rob Herring
@ 2021-07-19 22:48     ` Linus Walleij
  -1 siblings, 0 replies; 13+ messages in thread
From: Linus Walleij @ 2021-07-19 22:48 UTC (permalink / raw)
  To: Rob Herring
  Cc: Linux ARM, Imre Kaloz, Krzysztof Halasa, Marc Zyngier,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS

On Mon, Jul 19, 2021 at 5:18 PM Rob Herring <robh@kernel.org> wrote:

> > +patternProperties:
> > +  "^.*@[0-7],[0-9a-f]+$":
> > +    description: Devices attached to chip selects are represented as
> > +      subnodes.
> > +    type: object
> > +
> > +    properties:
> > +      intel,ixp4xx-eb-t1:
> > +        description: Address timing, extend address phase with n cycles.
> > +        $ref: /schemas/types.yaml#/definitions/uint32
> > +        maximum: 3

(...)

> > +    unevaluatedProperties: false
>
> This will cause failures when implemented. The problem is this won't
> allow any other child node properties as this schema and the device
> schema are evaluated independently. The only way I see to solve this is
> the child node schemas have to include some 'bus properties' schema
> which includes all possible bus controller properties. There's been a
> recent patch set doing this for SPI. At least here, I think the number
> of different child devices on parallel expansion buses are limited.
>
> So spliting this to 2 schema files would be the first step. Minimally,
> just drop unevaluatedProperties.

SPI upstream simply uses

additionalProperties: true

is that acceptable for now?

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 1/2] bus: ixp4xx: Add DT bindings for the IXP4xx expansion bus
@ 2021-07-19 22:48     ` Linus Walleij
  0 siblings, 0 replies; 13+ messages in thread
From: Linus Walleij @ 2021-07-19 22:48 UTC (permalink / raw)
  To: Rob Herring
  Cc: Linux ARM, Imre Kaloz, Krzysztof Halasa, Marc Zyngier,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS

On Mon, Jul 19, 2021 at 5:18 PM Rob Herring <robh@kernel.org> wrote:

> > +patternProperties:
> > +  "^.*@[0-7],[0-9a-f]+$":
> > +    description: Devices attached to chip selects are represented as
> > +      subnodes.
> > +    type: object
> > +
> > +    properties:
> > +      intel,ixp4xx-eb-t1:
> > +        description: Address timing, extend address phase with n cycles.
> > +        $ref: /schemas/types.yaml#/definitions/uint32
> > +        maximum: 3

(...)

> > +    unevaluatedProperties: false
>
> This will cause failures when implemented. The problem is this won't
> allow any other child node properties as this schema and the device
> schema are evaluated independently. The only way I see to solve this is
> the child node schemas have to include some 'bus properties' schema
> which includes all possible bus controller properties. There's been a
> recent patch set doing this for SPI. At least here, I think the number
> of different child devices on parallel expansion buses are limited.
>
> So spliting this to 2 schema files would be the first step. Minimally,
> just drop unevaluatedProperties.

SPI upstream simply uses

additionalProperties: true

is that acceptable for now?

Yours,
Linus Walleij

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 1/2] bus: ixp4xx: Add DT bindings for the IXP4xx expansion bus
  2021-07-19 22:48     ` Linus Walleij
@ 2021-07-20 16:39       ` Rob Herring
  -1 siblings, 0 replies; 13+ messages in thread
From: Rob Herring @ 2021-07-20 16:39 UTC (permalink / raw)
  To: Linus Walleij
  Cc: Linux ARM, Imre Kaloz, Krzysztof Halasa, Marc Zyngier,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS

On Mon, Jul 19, 2021 at 4:49 PM Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Mon, Jul 19, 2021 at 5:18 PM Rob Herring <robh@kernel.org> wrote:
>
> > > +patternProperties:
> > > +  "^.*@[0-7],[0-9a-f]+$":
> > > +    description: Devices attached to chip selects are represented as
> > > +      subnodes.
> > > +    type: object
> > > +
> > > +    properties:
> > > +      intel,ixp4xx-eb-t1:
> > > +        description: Address timing, extend address phase with n cycles.
> > > +        $ref: /schemas/types.yaml#/definitions/uint32
> > > +        maximum: 3
>
> (...)
>
> > > +    unevaluatedProperties: false
> >
> > This will cause failures when implemented. The problem is this won't
> > allow any other child node properties as this schema and the device
> > schema are evaluated independently. The only way I see to solve this is
> > the child node schemas have to include some 'bus properties' schema
> > which includes all possible bus controller properties. There's been a
> > recent patch set doing this for SPI. At least here, I think the number
> > of different child devices on parallel expansion buses are limited.
> >
> > So spliting this to 2 schema files would be the first step. Minimally,
> > just drop unevaluatedProperties.
>
> SPI upstream simply uses
>
> additionalProperties: true
>
> is that acceptable for now?

Yes. (That is the default)

Rob

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 1/2] bus: ixp4xx: Add DT bindings for the IXP4xx expansion bus
@ 2021-07-20 16:39       ` Rob Herring
  0 siblings, 0 replies; 13+ messages in thread
From: Rob Herring @ 2021-07-20 16:39 UTC (permalink / raw)
  To: Linus Walleij
  Cc: Linux ARM, Imre Kaloz, Krzysztof Halasa, Marc Zyngier,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS

On Mon, Jul 19, 2021 at 4:49 PM Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Mon, Jul 19, 2021 at 5:18 PM Rob Herring <robh@kernel.org> wrote:
>
> > > +patternProperties:
> > > +  "^.*@[0-7],[0-9a-f]+$":
> > > +    description: Devices attached to chip selects are represented as
> > > +      subnodes.
> > > +    type: object
> > > +
> > > +    properties:
> > > +      intel,ixp4xx-eb-t1:
> > > +        description: Address timing, extend address phase with n cycles.
> > > +        $ref: /schemas/types.yaml#/definitions/uint32
> > > +        maximum: 3
>
> (...)
>
> > > +    unevaluatedProperties: false
> >
> > This will cause failures when implemented. The problem is this won't
> > allow any other child node properties as this schema and the device
> > schema are evaluated independently. The only way I see to solve this is
> > the child node schemas have to include some 'bus properties' schema
> > which includes all possible bus controller properties. There's been a
> > recent patch set doing this for SPI. At least here, I think the number
> > of different child devices on parallel expansion buses are limited.
> >
> > So spliting this to 2 schema files would be the first step. Minimally,
> > just drop unevaluatedProperties.
>
> SPI upstream simply uses
>
> additionalProperties: true
>
> is that acceptable for now?

Yes. (That is the default)

Rob

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2021-07-20 16:41 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-07-17  0:16 [PATCH 1/2] bus: ixp4xx: Add DT bindings for the IXP4xx expansion bus Linus Walleij
2021-07-17  0:16 ` Linus Walleij
2021-07-17  0:16 ` [PATCH 2/2] bus: ixp4xx: Add a driver for " Linus Walleij
2021-07-19 13:47 ` [PATCH 1/2] bus: ixp4xx: Add DT bindings for the " Rob Herring
2021-07-19 13:47   ` Rob Herring
2021-07-19 14:10   ` Linus Walleij
2021-07-19 14:10     ` Linus Walleij
2021-07-19 15:18 ` Rob Herring
2021-07-19 15:18   ` Rob Herring
2021-07-19 22:48   ` Linus Walleij
2021-07-19 22:48     ` Linus Walleij
2021-07-20 16:39     ` Rob Herring
2021-07-20 16:39       ` Rob Herring

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.