* [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.