* [PATCH 0/9] ARM Versatile multi-platform support
@ 2014-12-30 19:28 ` Rob Herring
0 siblings, 0 replies; 86+ messages in thread
From: Rob Herring @ 2014-12-30 19:28 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: Russell King, Linus Walleij, Peter Maydell,
arm-DgEjT+Ai2ygdnm+yROfE0A, Bjorn Helgaas, Rob Herring
From: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
This series converts ARM Versatile platform to multi-platform. I started
this some time ago and some pieces were already merged. The primary
piece remaining is converting the PCI host to DT which I was waiting for
the common PCI DT parsing to get settled. Now that that is in place as
well as a few other pieces are in place like multi-platform fixes for
CLCD, we can fully convert Versatile to DT and multi-platform.
There's still a few things that need DT support which can be done
later:
- MMC card detect and write protect. Should be able to use VExpress
support
- Reboot support. Should be able to re-use Realview reboot code.
- flash phys-map support. Binding exists, but specifically Vpp control
is needed.
- CLCD support. Not sure where this is at.
This has been tested on QEMU. A previous version was tested on
Versatile/AB by Linus Walleij. Linus reported a problem with the
display panel detection. Investigation on h/w is needed still as I have
not been able to identify the issue by inspection and the display
detection seems to work correctly on QEMU.
Linus had also mentioned to me that QEMU users may have some issue with
removing non-DT code as the work flow has to change somewhat. Copying
Peter Maydell here for comment (and there's rumors he may have actual PB
h/w with PCI as well).
This series is available here:
git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git versatile-multiplatform
Rob
Rob Herring (9):
dt/bindings: add versatile PCI binding
dts: versatile: add PCI controller binding
ARM: versatile: add DT based PCI detection
pci: add DT based ARM Versatile PCI host driver
dts: versatile: add sysregs nodes
ARM: versatile: switch to DT only booting and remove legacy code
ARM: versatile: move mach includes into mach directory
ARM: versatile: convert to multi-platform
ARM: versatile: consolidate code to single file
.../devicetree/bindings/pci/versatile.txt | 59 ++
arch/arm/Kconfig | 17 -
arch/arm/boot/dts/versatile-ab.dts | 23 +
arch/arm/boot/dts/versatile-pb.dts | 37 +
arch/arm/mach-versatile/Kconfig | 39 +-
arch/arm/mach-versatile/Makefile | 6 +-
arch/arm/mach-versatile/Makefile.boot | 4 -
arch/arm/mach-versatile/core.c | 845 ---------------------
arch/arm/mach-versatile/core.h | 46 --
arch/arm/mach-versatile/include/mach/clkdev.h | 16 -
arch/arm/mach-versatile/include/mach/hardware.h | 38 -
arch/arm/mach-versatile/include/mach/irqs.h | 134 ----
arch/arm/mach-versatile/include/mach/uncompress.h | 45 --
arch/arm/mach-versatile/pci.c | 368 ---------
.../mach-versatile/{include/mach => }/platform.h | 179 +----
arch/arm/mach-versatile/versatile_ab.c | 44 --
arch/arm/mach-versatile/versatile_dt.c | 338 ++++++++-
arch/arm/mach-versatile/versatile_pb.c | 91 ---
drivers/clk/versatile/Kconfig | 3 +-
drivers/pci/host/Kconfig | 4 +
drivers/pci/host/Makefile | 1 +
drivers/pci/host/pci-versatile.c | 305 ++++++++
22 files changed, 784 insertions(+), 1858 deletions(-)
create mode 100644 Documentation/devicetree/bindings/pci/versatile.txt
delete mode 100644 arch/arm/mach-versatile/Makefile.boot
delete mode 100644 arch/arm/mach-versatile/core.c
delete mode 100644 arch/arm/mach-versatile/core.h
delete mode 100644 arch/arm/mach-versatile/include/mach/clkdev.h
delete mode 100644 arch/arm/mach-versatile/include/mach/hardware.h
delete mode 100644 arch/arm/mach-versatile/include/mach/irqs.h
delete mode 100644 arch/arm/mach-versatile/include/mach/uncompress.h
delete mode 100644 arch/arm/mach-versatile/pci.c
rename arch/arm/mach-versatile/{include/mach => }/platform.h (54%)
delete mode 100644 arch/arm/mach-versatile/versatile_ab.c
delete mode 100644 arch/arm/mach-versatile/versatile_pb.c
create mode 100644 drivers/pci/host/pci-versatile.c
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 0/9] ARM Versatile multi-platform support
@ 2014-12-30 19:28 ` Rob Herring
0 siblings, 0 replies; 86+ messages in thread
From: Rob Herring @ 2014-12-30 19:28 UTC (permalink / raw)
To: linux-arm-kernel
From: Rob Herring <robh@kernel.org>
This series converts ARM Versatile platform to multi-platform. I started
this some time ago and some pieces were already merged. The primary
piece remaining is converting the PCI host to DT which I was waiting for
the common PCI DT parsing to get settled. Now that that is in place as
well as a few other pieces are in place like multi-platform fixes for
CLCD, we can fully convert Versatile to DT and multi-platform.
There's still a few things that need DT support which can be done
later:
- MMC card detect and write protect. Should be able to use VExpress
support
- Reboot support. Should be able to re-use Realview reboot code.
- flash phys-map support. Binding exists, but specifically Vpp control
is needed.
- CLCD support. Not sure where this is at.
This has been tested on QEMU. A previous version was tested on
Versatile/AB by Linus Walleij. Linus reported a problem with the
display panel detection. Investigation on h/w is needed still as I have
not been able to identify the issue by inspection and the display
detection seems to work correctly on QEMU.
Linus had also mentioned to me that QEMU users may have some issue with
removing non-DT code as the work flow has to change somewhat. Copying
Peter Maydell here for comment (and there's rumors he may have actual PB
h/w with PCI as well).
This series is available here:
git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git versatile-multiplatform
Rob
Rob Herring (9):
dt/bindings: add versatile PCI binding
dts: versatile: add PCI controller binding
ARM: versatile: add DT based PCI detection
pci: add DT based ARM Versatile PCI host driver
dts: versatile: add sysregs nodes
ARM: versatile: switch to DT only booting and remove legacy code
ARM: versatile: move mach includes into mach directory
ARM: versatile: convert to multi-platform
ARM: versatile: consolidate code to single file
.../devicetree/bindings/pci/versatile.txt | 59 ++
arch/arm/Kconfig | 17 -
arch/arm/boot/dts/versatile-ab.dts | 23 +
arch/arm/boot/dts/versatile-pb.dts | 37 +
arch/arm/mach-versatile/Kconfig | 39 +-
arch/arm/mach-versatile/Makefile | 6 +-
arch/arm/mach-versatile/Makefile.boot | 4 -
arch/arm/mach-versatile/core.c | 845 ---------------------
arch/arm/mach-versatile/core.h | 46 --
arch/arm/mach-versatile/include/mach/clkdev.h | 16 -
arch/arm/mach-versatile/include/mach/hardware.h | 38 -
arch/arm/mach-versatile/include/mach/irqs.h | 134 ----
arch/arm/mach-versatile/include/mach/uncompress.h | 45 --
arch/arm/mach-versatile/pci.c | 368 ---------
.../mach-versatile/{include/mach => }/platform.h | 179 +----
arch/arm/mach-versatile/versatile_ab.c | 44 --
arch/arm/mach-versatile/versatile_dt.c | 338 ++++++++-
arch/arm/mach-versatile/versatile_pb.c | 91 ---
drivers/clk/versatile/Kconfig | 3 +-
drivers/pci/host/Kconfig | 4 +
drivers/pci/host/Makefile | 1 +
drivers/pci/host/pci-versatile.c | 305 ++++++++
22 files changed, 784 insertions(+), 1858 deletions(-)
create mode 100644 Documentation/devicetree/bindings/pci/versatile.txt
delete mode 100644 arch/arm/mach-versatile/Makefile.boot
delete mode 100644 arch/arm/mach-versatile/core.c
delete mode 100644 arch/arm/mach-versatile/core.h
delete mode 100644 arch/arm/mach-versatile/include/mach/clkdev.h
delete mode 100644 arch/arm/mach-versatile/include/mach/hardware.h
delete mode 100644 arch/arm/mach-versatile/include/mach/irqs.h
delete mode 100644 arch/arm/mach-versatile/include/mach/uncompress.h
delete mode 100644 arch/arm/mach-versatile/pci.c
rename arch/arm/mach-versatile/{include/mach => }/platform.h (54%)
delete mode 100644 arch/arm/mach-versatile/versatile_ab.c
delete mode 100644 arch/arm/mach-versatile/versatile_pb.c
create mode 100644 drivers/pci/host/pci-versatile.c
--
2.1.0
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 1/9] dt/bindings: add versatile PCI binding
2014-12-30 19:28 ` Rob Herring
@ 2014-12-30 19:28 ` Rob Herring
-1 siblings, 0 replies; 86+ messages in thread
From: Rob Herring @ 2014-12-30 19:28 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: Russell King, Linus Walleij, Peter Maydell,
arm-DgEjT+Ai2ygdnm+yROfE0A, Bjorn Helgaas, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala
From: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Add binding documentation for the PCI controller found on Versatile PB
boards.
Signed-off-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
Cc: Ian Campbell <ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>
Cc: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
---
.../devicetree/bindings/pci/versatile.txt | 59 ++++++++++++++++++++++
1 file changed, 59 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/versatile.txt
diff --git a/Documentation/devicetree/bindings/pci/versatile.txt b/Documentation/devicetree/bindings/pci/versatile.txt
new file mode 100644
index 0000000..2cc6071
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/versatile.txt
@@ -0,0 +1,59 @@
+* ARM Versatile Platform Baseboard PCI interface
+
+PCI host controller found on the ARM Versatile PB board's FPGA.
+
+Required properties:
+- compatible: should contain "arm,versatile-pci" to identify the Versatile PCI
+ controller.
+- reg: base addresses and lengths of the pci controller. There must be 3
+ entries:
+ - Versatile specific registers
+ - Self Config space
+ - Config space
+- #address-cells: set to <3>
+- #size-cells: set to <2>
+- device_type: set to "pci"
+- bus-range: set to <0 0xff>
+- ranges: ranges for the PCI memory and I/O regions
+- #interrupt-cells: set to <1>
+- interrupt-map-mask and interrupt-map: standard PCI properties to define
+ the mapping of the PCI interface to interrupt numbers.
+
+Example:
+
+pci-controller@10001000 {
+ compatible = "arm,versatile-pci";
+ device_type = "pci";
+ reg = <0x10001000 0x1000
+ 0x41000000 0x10000
+ 0x42000000 0x100000>;
+ bus-range = <0 0xff>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+
+ ranges = <0x01000000 0 0x00000000 0x43000000 0 0x00010000 /* downstream I/O */
+ 0x02000000 0 0x50000000 0x50000000 0 0x10000000 /* non-prefetchable memory */
+ 0x42000000 0 0x60000000 0x60000000 0 0x10000000>; /* prefetchable memory */
+
+ interrupt-map-mask = <0x1800 0 0 7>;
+ interrupt-map = <0x1800 0 0 1 &sic 28
+ 0x1800 0 0 2 &sic 29
+ 0x1800 0 0 3 &sic 30
+ 0x1800 0 0 4 &sic 27
+
+ 0x1000 0 0 1 &sic 27
+ 0x1000 0 0 2 &sic 28
+ 0x1000 0 0 3 &sic 29
+ 0x1000 0 0 4 &sic 30
+
+ 0x0800 0 0 1 &sic 30
+ 0x0800 0 0 2 &sic 27
+ 0x0800 0 0 3 &sic 28
+ 0x0800 0 0 4 &sic 29
+
+ 0x0000 0 0 1 &sic 29
+ 0x0000 0 0 2 &sic 30
+ 0x0000 0 0 3 &sic 27
+ 0x0000 0 0 4 &sic 28>;
+};
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 86+ messages in thread
* [PATCH 1/9] dt/bindings: add versatile PCI binding
@ 2014-12-30 19:28 ` Rob Herring
0 siblings, 0 replies; 86+ messages in thread
From: Rob Herring @ 2014-12-30 19:28 UTC (permalink / raw)
To: linux-arm-kernel
From: Rob Herring <robh@kernel.org>
Add binding documentation for the PCI controller found on Versatile PB
boards.
Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
Cc: Kumar Gala <galak@codeaurora.org>
---
.../devicetree/bindings/pci/versatile.txt | 59 ++++++++++++++++++++++
1 file changed, 59 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/versatile.txt
diff --git a/Documentation/devicetree/bindings/pci/versatile.txt b/Documentation/devicetree/bindings/pci/versatile.txt
new file mode 100644
index 0000000..2cc6071
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/versatile.txt
@@ -0,0 +1,59 @@
+* ARM Versatile Platform Baseboard PCI interface
+
+PCI host controller found on the ARM Versatile PB board's FPGA.
+
+Required properties:
+- compatible: should contain "arm,versatile-pci" to identify the Versatile PCI
+ controller.
+- reg: base addresses and lengths of the pci controller. There must be 3
+ entries:
+ - Versatile specific registers
+ - Self Config space
+ - Config space
+- #address-cells: set to <3>
+- #size-cells: set to <2>
+- device_type: set to "pci"
+- bus-range: set to <0 0xff>
+- ranges: ranges for the PCI memory and I/O regions
+- #interrupt-cells: set to <1>
+- interrupt-map-mask and interrupt-map: standard PCI properties to define
+ the mapping of the PCI interface to interrupt numbers.
+
+Example:
+
+pci-controller at 10001000 {
+ compatible = "arm,versatile-pci";
+ device_type = "pci";
+ reg = <0x10001000 0x1000
+ 0x41000000 0x10000
+ 0x42000000 0x100000>;
+ bus-range = <0 0xff>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+
+ ranges = <0x01000000 0 0x00000000 0x43000000 0 0x00010000 /* downstream I/O */
+ 0x02000000 0 0x50000000 0x50000000 0 0x10000000 /* non-prefetchable memory */
+ 0x42000000 0 0x60000000 0x60000000 0 0x10000000>; /* prefetchable memory */
+
+ interrupt-map-mask = <0x1800 0 0 7>;
+ interrupt-map = <0x1800 0 0 1 &sic 28
+ 0x1800 0 0 2 &sic 29
+ 0x1800 0 0 3 &sic 30
+ 0x1800 0 0 4 &sic 27
+
+ 0x1000 0 0 1 &sic 27
+ 0x1000 0 0 2 &sic 28
+ 0x1000 0 0 3 &sic 29
+ 0x1000 0 0 4 &sic 30
+
+ 0x0800 0 0 1 &sic 30
+ 0x0800 0 0 2 &sic 27
+ 0x0800 0 0 3 &sic 28
+ 0x0800 0 0 4 &sic 29
+
+ 0x0000 0 0 1 &sic 29
+ 0x0000 0 0 2 &sic 30
+ 0x0000 0 0 3 &sic 27
+ 0x0000 0 0 4 &sic 28>;
+};
--
2.1.0
^ permalink raw reply related [flat|nested] 86+ messages in thread
* [PATCH 2/9] dts: versatile: add PCI controller binding
2014-12-30 19:28 ` Rob Herring
@ 2014-12-30 19:28 ` Rob Herring
-1 siblings, 0 replies; 86+ messages in thread
From: Rob Herring @ 2014-12-30 19:28 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: Russell King, Linus Walleij, Peter Maydell,
arm-DgEjT+Ai2ygdnm+yROfE0A, Bjorn Helgaas, Rob Herring
From: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Add the PCI controller node for the Versatile/PB board.
Signed-off-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
Cc: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
arch/arm/boot/dts/versatile-pb.dts | 37 +++++++++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/arch/arm/boot/dts/versatile-pb.dts b/arch/arm/boot/dts/versatile-pb.dts
index e36c1e8..b83137f 100644
--- a/arch/arm/boot/dts/versatile-pb.dts
+++ b/arch/arm/boot/dts/versatile-pb.dts
@@ -29,6 +29,43 @@
clock-names = "apb_pclk";
};
+ pci-controller@10001000 {
+ compatible = "arm,versatile-pci";
+ device_type = "pci";
+ reg = <0x10001000 0x1000
+ 0x41000000 0x10000
+ 0x42000000 0x100000>;
+ bus-range = <0 0xff>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+
+ ranges = <0x01000000 0 0x00000000 0x43000000 0 0x00010000 /* downstream I/O */
+ 0x02000000 0 0x50000000 0x50000000 0 0x10000000 /* non-prefetchable memory */
+ 0x42000000 0 0x60000000 0x60000000 0 0x10000000>; /* prefetchable memory */
+
+ interrupt-map-mask = <0x1800 0 0 7>;
+ interrupt-map = <0x1800 0 0 1 &sic 28
+ 0x1800 0 0 2 &sic 29
+ 0x1800 0 0 3 &sic 30
+ 0x1800 0 0 4 &sic 27
+
+ 0x1000 0 0 1 &sic 27
+ 0x1000 0 0 2 &sic 28
+ 0x1000 0 0 3 &sic 29
+ 0x1000 0 0 4 &sic 30
+
+ 0x0800 0 0 1 &sic 30
+ 0x0800 0 0 2 &sic 27
+ 0x0800 0 0 3 &sic 28
+ 0x0800 0 0 4 &sic 29
+
+ 0x0000 0 0 1 &sic 29
+ 0x0000 0 0 2 &sic 30
+ 0x0000 0 0 3 &sic 27
+ 0x0000 0 0 4 &sic 28>;
+ };
+
fpga {
uart@9000 {
compatible = "arm,pl011", "arm,primecell";
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 86+ messages in thread
* [PATCH 2/9] dts: versatile: add PCI controller binding
@ 2014-12-30 19:28 ` Rob Herring
0 siblings, 0 replies; 86+ messages in thread
From: Rob Herring @ 2014-12-30 19:28 UTC (permalink / raw)
To: linux-arm-kernel
From: Rob Herring <robh@kernel.org>
Add the PCI controller node for the Versatile/PB board.
Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Linus Walleij <linus.walleij@linaro.org>
---
arch/arm/boot/dts/versatile-pb.dts | 37 +++++++++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/arch/arm/boot/dts/versatile-pb.dts b/arch/arm/boot/dts/versatile-pb.dts
index e36c1e8..b83137f 100644
--- a/arch/arm/boot/dts/versatile-pb.dts
+++ b/arch/arm/boot/dts/versatile-pb.dts
@@ -29,6 +29,43 @@
clock-names = "apb_pclk";
};
+ pci-controller at 10001000 {
+ compatible = "arm,versatile-pci";
+ device_type = "pci";
+ reg = <0x10001000 0x1000
+ 0x41000000 0x10000
+ 0x42000000 0x100000>;
+ bus-range = <0 0xff>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+
+ ranges = <0x01000000 0 0x00000000 0x43000000 0 0x00010000 /* downstream I/O */
+ 0x02000000 0 0x50000000 0x50000000 0 0x10000000 /* non-prefetchable memory */
+ 0x42000000 0 0x60000000 0x60000000 0 0x10000000>; /* prefetchable memory */
+
+ interrupt-map-mask = <0x1800 0 0 7>;
+ interrupt-map = <0x1800 0 0 1 &sic 28
+ 0x1800 0 0 2 &sic 29
+ 0x1800 0 0 3 &sic 30
+ 0x1800 0 0 4 &sic 27
+
+ 0x1000 0 0 1 &sic 27
+ 0x1000 0 0 2 &sic 28
+ 0x1000 0 0 3 &sic 29
+ 0x1000 0 0 4 &sic 30
+
+ 0x0800 0 0 1 &sic 30
+ 0x0800 0 0 2 &sic 27
+ 0x0800 0 0 3 &sic 28
+ 0x0800 0 0 4 &sic 29
+
+ 0x0000 0 0 1 &sic 29
+ 0x0000 0 0 2 &sic 30
+ 0x0000 0 0 3 &sic 27
+ 0x0000 0 0 4 &sic 28>;
+ };
+
fpga {
uart at 9000 {
compatible = "arm,pl011", "arm,primecell";
--
2.1.0
^ permalink raw reply related [flat|nested] 86+ messages in thread
* [PATCH 3/9] ARM: versatile: add DT based PCI detection
2014-12-30 19:28 ` Rob Herring
@ 2014-12-30 19:28 ` Rob Herring
-1 siblings, 0 replies; 86+ messages in thread
From: Rob Herring @ 2014-12-30 19:28 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: Russell King, Linus Walleij, Peter Maydell,
arm-DgEjT+Ai2ygdnm+yROfE0A, Bjorn Helgaas, Rob Herring
From: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Disable the Versatile PCI DT node when no PCI backplane is detected. This
will prevent the Versatile PCI driver from probing when PCI is not
populated.
Signed-off-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
Cc: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
arch/arm/mach-versatile/versatile_dt.c | 46 ++++++++++++++++++++++++++++++++++
1 file changed, 46 insertions(+)
diff --git a/arch/arm/mach-versatile/versatile_dt.c b/arch/arm/mach-versatile/versatile_dt.c
index 9f9bc61..5053810 100644
--- a/arch/arm/mach-versatile/versatile_dt.c
+++ b/arch/arm/mach-versatile/versatile_dt.c
@@ -22,15 +22,61 @@
*/
#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
#include <linux/of_irq.h>
#include <linux/of_platform.h>
+#include <linux/slab.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
#include "core.h"
+#define VERSATILE_SYS_PCICTL_OFFSET 0x44
+
+static void __init versatile_dt_pci_init(void)
+{
+ u32 val;
+ void __iomem *base;
+ struct device_node *np;
+ struct property *newprop;
+
+ np = of_find_compatible_node(NULL, NULL, "arm,core-module-versatile");
+ if (!np)
+ return;
+
+ base = of_iomap(np, 0);
+ if (!base)
+ return;
+
+ /* Check if PCI backplane is detected */
+ val = __raw_readl(base + VERSATILE_SYS_PCICTL_OFFSET);
+ if (val & 1)
+ goto err;
+
+ np = of_find_compatible_node(NULL, NULL, "arm,versatile-pci");
+ if (!np)
+ goto err;
+
+ newprop = kzalloc(sizeof(*newprop), GFP_KERNEL);
+ if (!newprop)
+ goto err;
+
+ newprop->name = kstrdup("status", GFP_KERNEL);
+ newprop->value = kstrdup("disabled", GFP_KERNEL);
+ newprop->length = sizeof("disabled");
+ of_update_property(np, newprop);
+
+ pr_info("Not plugged into PCI backplane!\n");
+err:
+ iounmap(base);
+}
+
static void __init versatile_dt_init(void)
{
+ versatile_dt_pci_init();
+
of_platform_populate(NULL, of_default_bus_match_table,
versatile_auxdata_lookup, NULL);
}
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 86+ messages in thread
* [PATCH 3/9] ARM: versatile: add DT based PCI detection
@ 2014-12-30 19:28 ` Rob Herring
0 siblings, 0 replies; 86+ messages in thread
From: Rob Herring @ 2014-12-30 19:28 UTC (permalink / raw)
To: linux-arm-kernel
From: Rob Herring <robh@kernel.org>
Disable the Versatile PCI DT node when no PCI backplane is detected. This
will prevent the Versatile PCI driver from probing when PCI is not
populated.
Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Linus Walleij <linus.walleij@linaro.org>
---
arch/arm/mach-versatile/versatile_dt.c | 46 ++++++++++++++++++++++++++++++++++
1 file changed, 46 insertions(+)
diff --git a/arch/arm/mach-versatile/versatile_dt.c b/arch/arm/mach-versatile/versatile_dt.c
index 9f9bc61..5053810 100644
--- a/arch/arm/mach-versatile/versatile_dt.c
+++ b/arch/arm/mach-versatile/versatile_dt.c
@@ -22,15 +22,61 @@
*/
#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
#include <linux/of_irq.h>
#include <linux/of_platform.h>
+#include <linux/slab.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
#include "core.h"
+#define VERSATILE_SYS_PCICTL_OFFSET 0x44
+
+static void __init versatile_dt_pci_init(void)
+{
+ u32 val;
+ void __iomem *base;
+ struct device_node *np;
+ struct property *newprop;
+
+ np = of_find_compatible_node(NULL, NULL, "arm,core-module-versatile");
+ if (!np)
+ return;
+
+ base = of_iomap(np, 0);
+ if (!base)
+ return;
+
+ /* Check if PCI backplane is detected */
+ val = __raw_readl(base + VERSATILE_SYS_PCICTL_OFFSET);
+ if (val & 1)
+ goto err;
+
+ np = of_find_compatible_node(NULL, NULL, "arm,versatile-pci");
+ if (!np)
+ goto err;
+
+ newprop = kzalloc(sizeof(*newprop), GFP_KERNEL);
+ if (!newprop)
+ goto err;
+
+ newprop->name = kstrdup("status", GFP_KERNEL);
+ newprop->value = kstrdup("disabled", GFP_KERNEL);
+ newprop->length = sizeof("disabled");
+ of_update_property(np, newprop);
+
+ pr_info("Not plugged into PCI backplane!\n");
+err:
+ iounmap(base);
+}
+
static void __init versatile_dt_init(void)
{
+ versatile_dt_pci_init();
+
of_platform_populate(NULL, of_default_bus_match_table,
versatile_auxdata_lookup, NULL);
}
--
2.1.0
^ permalink raw reply related [flat|nested] 86+ messages in thread
* [PATCH 4/9] pci: add DT based ARM Versatile PCI host driver
2014-12-30 19:28 ` Rob Herring
@ 2014-12-30 19:28 ` Rob Herring
-1 siblings, 0 replies; 86+ messages in thread
From: Rob Herring @ 2014-12-30 19:28 UTC (permalink / raw)
To: linux-arm-kernel, devicetree
Cc: Russell King, Linus Walleij, Peter Maydell, arm, Bjorn Helgaas,
Rob Herring, linux-pci
From: Rob Herring <robh@kernel.org>
This converts the Versatile PCI host code to a platform driver using
the commom DT parsing and setup. The driver uses only an empty ARM
pci_sys_data struct and does not use pci_common_init_dev init function.
The old host code will be removed in a subsequent commit when Versatile
is completely converted to DT.
I've tested this on QEMU with the sym53c8xx driver in both i/o and
memory mapped modes.
Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: linux-pci@vger.kernel.org
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Peter Maydell <peter.maydell@linaro.org>
---
drivers/pci/host/Kconfig | 4 +
drivers/pci/host/Makefile | 1 +
drivers/pci/host/pci-versatile.c | 305 +++++++++++++++++++++++++++++++++++++++
3 files changed, 310 insertions(+)
create mode 100644 drivers/pci/host/pci-versatile.c
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index c4b6568..7b892a9 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -102,4 +102,8 @@ config PCI_LAYERSCAPE
help
Say Y here if you want PCIe controller support on Layerscape SoCs.
+config PCI_VERSATILE
+ bool "ARM Versatile PB PCI controller"
+ depends on ARCH_VERSATILE
+
endmenu
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 44c2699..e61d91c 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -12,3 +12,4 @@ obj-$(CONFIG_PCI_KEYSTONE) += pci-keystone-dw.o pci-keystone.o
obj-$(CONFIG_PCIE_XILINX) += pcie-xilinx.o
obj-$(CONFIG_PCI_XGENE) += pci-xgene.o
obj-$(CONFIG_PCI_LAYERSCAPE) += pci-layerscape.o
+obj-$(CONFIG_PCI_VERSATILE) += pci-versatile.o
diff --git a/drivers/pci/host/pci-versatile.c b/drivers/pci/host/pci-versatile.c
new file mode 100644
index 0000000..a3e7bc5
--- /dev/null
+++ b/drivers/pci/host/pci-versatile.c
@@ -0,0 +1,305 @@
+/*
+ * Copyright 2004 Koninklijke Philips Electronics NV
+ *
+ * Conversion to platform driver and DT:
+ * Copyright 2014 Linaro Ltd.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * 14/04/2005 Initial version, colin.king@philips.com
+ */
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/of_pci.h>
+#include <linux/of_platform.h>
+#include <linux/pci.h>
+#include <linux/platform_device.h>
+
+static void __iomem *versatile_pci_base;
+static void __iomem *versatile_cfg_base[2];
+
+#define PCI_IMAP(m) (versatile_pci_base + ((m) * 4))
+#define PCI_SMAP(m) (versatile_pci_base + 0x14 + ((m) * 4))
+#define PCI_SELFID (versatile_pci_base + 0xc)
+
+#define VP_PCI_DEVICE_ID 0x030010ee
+#define VP_PCI_CLASS_ID 0x0b400000
+
+static u32 pci_slot_ignore;
+
+static int __init versatile_pci_slot_ignore(char *str)
+{
+ int retval;
+ int slot;
+
+ while ((retval = get_option(&str, &slot))) {
+ if ((slot < 0) || (slot > 31))
+ pr_err("Illegal slot value: %d\n", slot);
+ else
+ pci_slot_ignore |= (1 << slot);
+ }
+ return 1;
+}
+__setup("pci_slot_ignore=", versatile_pci_slot_ignore);
+
+
+static void __iomem *__pci_addr(struct pci_bus *bus,
+ unsigned int devfn, int offset)
+{
+ unsigned int busnr = bus->number;
+
+ /*
+ * Trap out illegal values
+ */
+ BUG_ON(offset > 255);
+ BUG_ON(busnr > 255);
+ BUG_ON(devfn > 255);
+
+ return versatile_cfg_base[1] + ((busnr << 16) |
+ (PCI_SLOT(devfn) << 11) | (PCI_FUNC(devfn) << 8) | offset);
+}
+
+static int versatile_read_config(struct pci_bus *bus, unsigned int devfn,
+ int where, int size, u32 *val)
+{
+ void __iomem *addr = __pci_addr(bus, devfn, where & ~3);
+ u32 v;
+ int slot = PCI_SLOT(devfn);
+
+ if (pci_slot_ignore & (1 << slot)) {
+ /* Ignore this slot */
+ v = (1 << (8 * size)) - 1;
+ } else {
+ switch (size) {
+ case 1:
+ v = readl(addr);
+ if (where & 2)
+ v >>= 16;
+ if (where & 1)
+ v >>= 8;
+ v &= 0xff;
+ break;
+
+ case 2:
+ v = readl(addr);
+ if (where & 2)
+ v >>= 16;
+ v &= 0xffff;
+ break;
+
+ default:
+ v = readl(addr);
+ break;
+ }
+ }
+
+ *val = v;
+ return PCIBIOS_SUCCESSFUL;
+}
+
+static int versatile_write_config(struct pci_bus *bus, unsigned int devfn,
+ int where, int size, u32 val)
+{
+ void __iomem *addr = __pci_addr(bus, devfn, where);
+ int slot = PCI_SLOT(devfn);
+
+ if (pci_slot_ignore & (1 << slot))
+ return PCIBIOS_SUCCESSFUL;
+
+ switch (size) {
+ case 1:
+ writeb((u8)val, addr);
+ break;
+
+ case 2:
+ writew((u16)val, addr);
+ break;
+
+ case 4:
+ writel(val, addr);
+ break;
+ }
+
+ return PCIBIOS_SUCCESSFUL;
+}
+
+static struct pci_ops pci_versatile_ops = {
+ .read = versatile_read_config,
+ .write = versatile_write_config,
+};
+
+static int versatile_pci_parse_request_of_pci_ranges(struct device *dev,
+ struct list_head *res)
+{
+ int err, mem = 1, res_valid = 0;
+ struct device_node *np = dev->of_node;
+ resource_size_t iobase;
+ struct pci_host_bridge_window *win;
+
+ err = of_pci_get_host_bridge_resources(np, 0, 0xff, res, &iobase);
+ if (err)
+ return err;
+
+ list_for_each_entry(win, res, list) {
+ struct resource *parent, *res = win->res;
+
+ switch (resource_type(res)) {
+ case IORESOURCE_IO:
+ parent = &ioport_resource;
+ err = pci_remap_iospace(res, iobase);
+ if (err) {
+ dev_warn(dev, "error %d: failed to map resource %pR\n",
+ err, res);
+ continue;
+ }
+ break;
+ case IORESOURCE_MEM:
+ parent = &iomem_resource;
+ res_valid |= !(res->flags & IORESOURCE_PREFETCH);
+
+ writel(res->start >> 28, PCI_IMAP(mem));
+ writel(PHYS_OFFSET >> 28, PCI_SMAP(mem));
+ mem++;
+
+ break;
+ case IORESOURCE_BUS:
+ default:
+ continue;
+ }
+
+ err = devm_request_resource(dev, parent, res);
+ if (err)
+ goto out_release_res;
+ }
+
+ if (!res_valid) {
+ dev_err(dev, "non-prefetchable memory resource required\n");
+ err = -EINVAL;
+ goto out_release_res;
+ }
+
+ return 0;
+
+out_release_res:
+ pci_free_resource_list(res);
+ return err;
+}
+
+/* Unused, temporary to satisfy ARM arch code */
+struct pci_sys_data sys;
+
+static int versatile_pci_probe(struct platform_device *pdev)
+{
+ struct resource *res;
+ int ret, i, myslot = -1;
+ u32 val;
+ void __iomem *local_pci_cfg_base;
+ struct pci_bus *bus;
+ LIST_HEAD(pci_res);
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res)
+ return -ENODEV;
+ versatile_pci_base = devm_ioremap_resource(&pdev->dev, res);
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ if (!res)
+ return -ENODEV;
+ versatile_cfg_base[0] = devm_ioremap_resource(&pdev->dev, res);
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
+ if (!res)
+ return -ENODEV;
+ versatile_cfg_base[1] = devm_ioremap_resource(&pdev->dev, res);
+
+ ret = versatile_pci_parse_request_of_pci_ranges(&pdev->dev, &pci_res);
+ if (ret)
+ return ret;
+
+ /*
+ * We need to discover the PCI core first to configure itself
+ * before the main PCI probing is performed
+ */
+ for (i = 0; i < 32; i++) {
+ if ((readl(versatile_cfg_base[0] + (i << 11) + PCI_VENDOR_ID) == VP_PCI_DEVICE_ID) &&
+ (readl(versatile_cfg_base[0] + (i << 11) + PCI_CLASS_REVISION) == VP_PCI_CLASS_ID)) {
+ myslot = i;
+ break;
+ }
+ }
+ if (myslot == -1) {
+ dev_err(&pdev->dev, "Cannot find PCI core!\n");
+ return -EIO;
+ }
+ /*
+ * Do not to map Versatile FPGA PCI device into memory space
+ */
+ pci_slot_ignore |= (1 << myslot);
+
+ dev_info(&pdev->dev, "PCI core found (slot %d)\n", myslot);
+
+ writel(myslot, PCI_SELFID);
+ local_pci_cfg_base = versatile_cfg_base[1] + (myslot << 11);
+
+ val = readl(local_pci_cfg_base + PCI_COMMAND);
+ val |= PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER | PCI_COMMAND_INVALIDATE;
+ writel(val, local_pci_cfg_base + PCI_COMMAND);
+
+ /*
+ * Configure the PCI inbound memory windows to be 1:1 mapped to SDRAM
+ */
+ writel(PHYS_OFFSET, local_pci_cfg_base + PCI_BASE_ADDRESS_0);
+ writel(PHYS_OFFSET, local_pci_cfg_base + PCI_BASE_ADDRESS_1);
+ writel(PHYS_OFFSET, local_pci_cfg_base + PCI_BASE_ADDRESS_2);
+
+ /*
+ * For many years the kernel and QEMU were symbiotically buggy
+ * in that they both assumed the same broken IRQ mapping.
+ * QEMU therefore attempts to auto-detect old broken kernels
+ * so that they still work on newer QEMU as they did on old
+ * QEMU. Since we now use the correct (ie matching-hardware)
+ * IRQ mapping we write a definitely different value to a
+ * PCI_INTERRUPT_LINE register to tell QEMU that we expect
+ * real hardware behaviour and it need not be backwards
+ * compatible for us. This write is harmless on real hardware.
+ */
+ writel(0, versatile_cfg_base[0] + PCI_INTERRUPT_LINE);
+
+ pci_add_flags(PCI_ENABLE_PROC_DOMAINS);
+ pci_add_flags(PCI_REASSIGN_ALL_BUS | PCI_REASSIGN_ALL_RSRC);
+
+ bus = pci_scan_root_bus(&pdev->dev, 0, &pci_versatile_ops, &sys, &pci_res);
+ if (!bus)
+ return -ENOMEM;
+
+ pci_fixup_irqs(pci_common_swizzle, of_irq_parse_and_map_pci);
+ pci_assign_unassigned_bus_resources(bus);
+
+ return 0;
+}
+
+static const struct of_device_id versatile_pci_of_match[] = {
+ { .compatible = "arm,versatile-pci", },
+ { },
+};
+MODULE_DEVICE_TABLE(of, versatile_pci_of_match);
+
+static struct platform_driver versatile_pci_driver = {
+ .driver = {
+ .name = "versatile-pci",
+ .of_match_table = versatile_pci_of_match,
+ },
+ .probe = versatile_pci_probe,
+};
+module_platform_driver(versatile_pci_driver);
+
+MODULE_DESCRIPTION("Versatile PCI driver");
+MODULE_LICENSE("GPLv2");
--
2.1.0
^ permalink raw reply related [flat|nested] 86+ messages in thread
* [PATCH 4/9] pci: add DT based ARM Versatile PCI host driver
@ 2014-12-30 19:28 ` Rob Herring
0 siblings, 0 replies; 86+ messages in thread
From: Rob Herring @ 2014-12-30 19:28 UTC (permalink / raw)
To: linux-arm-kernel
From: Rob Herring <robh@kernel.org>
This converts the Versatile PCI host code to a platform driver using
the commom DT parsing and setup. The driver uses only an empty ARM
pci_sys_data struct and does not use pci_common_init_dev init function.
The old host code will be removed in a subsequent commit when Versatile
is completely converted to DT.
I've tested this on QEMU with the sym53c8xx driver in both i/o and
memory mapped modes.
Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: linux-pci at vger.kernel.org
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Peter Maydell <peter.maydell@linaro.org>
---
drivers/pci/host/Kconfig | 4 +
drivers/pci/host/Makefile | 1 +
drivers/pci/host/pci-versatile.c | 305 +++++++++++++++++++++++++++++++++++++++
3 files changed, 310 insertions(+)
create mode 100644 drivers/pci/host/pci-versatile.c
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index c4b6568..7b892a9 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -102,4 +102,8 @@ config PCI_LAYERSCAPE
help
Say Y here if you want PCIe controller support on Layerscape SoCs.
+config PCI_VERSATILE
+ bool "ARM Versatile PB PCI controller"
+ depends on ARCH_VERSATILE
+
endmenu
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 44c2699..e61d91c 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -12,3 +12,4 @@ obj-$(CONFIG_PCI_KEYSTONE) += pci-keystone-dw.o pci-keystone.o
obj-$(CONFIG_PCIE_XILINX) += pcie-xilinx.o
obj-$(CONFIG_PCI_XGENE) += pci-xgene.o
obj-$(CONFIG_PCI_LAYERSCAPE) += pci-layerscape.o
+obj-$(CONFIG_PCI_VERSATILE) += pci-versatile.o
diff --git a/drivers/pci/host/pci-versatile.c b/drivers/pci/host/pci-versatile.c
new file mode 100644
index 0000000..a3e7bc5
--- /dev/null
+++ b/drivers/pci/host/pci-versatile.c
@@ -0,0 +1,305 @@
+/*
+ * Copyright 2004 Koninklijke Philips Electronics NV
+ *
+ * Conversion to platform driver and DT:
+ * Copyright 2014 Linaro Ltd.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * 14/04/2005 Initial version, colin.king at philips.com
+ */
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/of_pci.h>
+#include <linux/of_platform.h>
+#include <linux/pci.h>
+#include <linux/platform_device.h>
+
+static void __iomem *versatile_pci_base;
+static void __iomem *versatile_cfg_base[2];
+
+#define PCI_IMAP(m) (versatile_pci_base + ((m) * 4))
+#define PCI_SMAP(m) (versatile_pci_base + 0x14 + ((m) * 4))
+#define PCI_SELFID (versatile_pci_base + 0xc)
+
+#define VP_PCI_DEVICE_ID 0x030010ee
+#define VP_PCI_CLASS_ID 0x0b400000
+
+static u32 pci_slot_ignore;
+
+static int __init versatile_pci_slot_ignore(char *str)
+{
+ int retval;
+ int slot;
+
+ while ((retval = get_option(&str, &slot))) {
+ if ((slot < 0) || (slot > 31))
+ pr_err("Illegal slot value: %d\n", slot);
+ else
+ pci_slot_ignore |= (1 << slot);
+ }
+ return 1;
+}
+__setup("pci_slot_ignore=", versatile_pci_slot_ignore);
+
+
+static void __iomem *__pci_addr(struct pci_bus *bus,
+ unsigned int devfn, int offset)
+{
+ unsigned int busnr = bus->number;
+
+ /*
+ * Trap out illegal values
+ */
+ BUG_ON(offset > 255);
+ BUG_ON(busnr > 255);
+ BUG_ON(devfn > 255);
+
+ return versatile_cfg_base[1] + ((busnr << 16) |
+ (PCI_SLOT(devfn) << 11) | (PCI_FUNC(devfn) << 8) | offset);
+}
+
+static int versatile_read_config(struct pci_bus *bus, unsigned int devfn,
+ int where, int size, u32 *val)
+{
+ void __iomem *addr = __pci_addr(bus, devfn, where & ~3);
+ u32 v;
+ int slot = PCI_SLOT(devfn);
+
+ if (pci_slot_ignore & (1 << slot)) {
+ /* Ignore this slot */
+ v = (1 << (8 * size)) - 1;
+ } else {
+ switch (size) {
+ case 1:
+ v = readl(addr);
+ if (where & 2)
+ v >>= 16;
+ if (where & 1)
+ v >>= 8;
+ v &= 0xff;
+ break;
+
+ case 2:
+ v = readl(addr);
+ if (where & 2)
+ v >>= 16;
+ v &= 0xffff;
+ break;
+
+ default:
+ v = readl(addr);
+ break;
+ }
+ }
+
+ *val = v;
+ return PCIBIOS_SUCCESSFUL;
+}
+
+static int versatile_write_config(struct pci_bus *bus, unsigned int devfn,
+ int where, int size, u32 val)
+{
+ void __iomem *addr = __pci_addr(bus, devfn, where);
+ int slot = PCI_SLOT(devfn);
+
+ if (pci_slot_ignore & (1 << slot))
+ return PCIBIOS_SUCCESSFUL;
+
+ switch (size) {
+ case 1:
+ writeb((u8)val, addr);
+ break;
+
+ case 2:
+ writew((u16)val, addr);
+ break;
+
+ case 4:
+ writel(val, addr);
+ break;
+ }
+
+ return PCIBIOS_SUCCESSFUL;
+}
+
+static struct pci_ops pci_versatile_ops = {
+ .read = versatile_read_config,
+ .write = versatile_write_config,
+};
+
+static int versatile_pci_parse_request_of_pci_ranges(struct device *dev,
+ struct list_head *res)
+{
+ int err, mem = 1, res_valid = 0;
+ struct device_node *np = dev->of_node;
+ resource_size_t iobase;
+ struct pci_host_bridge_window *win;
+
+ err = of_pci_get_host_bridge_resources(np, 0, 0xff, res, &iobase);
+ if (err)
+ return err;
+
+ list_for_each_entry(win, res, list) {
+ struct resource *parent, *res = win->res;
+
+ switch (resource_type(res)) {
+ case IORESOURCE_IO:
+ parent = &ioport_resource;
+ err = pci_remap_iospace(res, iobase);
+ if (err) {
+ dev_warn(dev, "error %d: failed to map resource %pR\n",
+ err, res);
+ continue;
+ }
+ break;
+ case IORESOURCE_MEM:
+ parent = &iomem_resource;
+ res_valid |= !(res->flags & IORESOURCE_PREFETCH);
+
+ writel(res->start >> 28, PCI_IMAP(mem));
+ writel(PHYS_OFFSET >> 28, PCI_SMAP(mem));
+ mem++;
+
+ break;
+ case IORESOURCE_BUS:
+ default:
+ continue;
+ }
+
+ err = devm_request_resource(dev, parent, res);
+ if (err)
+ goto out_release_res;
+ }
+
+ if (!res_valid) {
+ dev_err(dev, "non-prefetchable memory resource required\n");
+ err = -EINVAL;
+ goto out_release_res;
+ }
+
+ return 0;
+
+out_release_res:
+ pci_free_resource_list(res);
+ return err;
+}
+
+/* Unused, temporary to satisfy ARM arch code */
+struct pci_sys_data sys;
+
+static int versatile_pci_probe(struct platform_device *pdev)
+{
+ struct resource *res;
+ int ret, i, myslot = -1;
+ u32 val;
+ void __iomem *local_pci_cfg_base;
+ struct pci_bus *bus;
+ LIST_HEAD(pci_res);
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res)
+ return -ENODEV;
+ versatile_pci_base = devm_ioremap_resource(&pdev->dev, res);
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ if (!res)
+ return -ENODEV;
+ versatile_cfg_base[0] = devm_ioremap_resource(&pdev->dev, res);
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
+ if (!res)
+ return -ENODEV;
+ versatile_cfg_base[1] = devm_ioremap_resource(&pdev->dev, res);
+
+ ret = versatile_pci_parse_request_of_pci_ranges(&pdev->dev, &pci_res);
+ if (ret)
+ return ret;
+
+ /*
+ * We need to discover the PCI core first to configure itself
+ * before the main PCI probing is performed
+ */
+ for (i = 0; i < 32; i++) {
+ if ((readl(versatile_cfg_base[0] + (i << 11) + PCI_VENDOR_ID) == VP_PCI_DEVICE_ID) &&
+ (readl(versatile_cfg_base[0] + (i << 11) + PCI_CLASS_REVISION) == VP_PCI_CLASS_ID)) {
+ myslot = i;
+ break;
+ }
+ }
+ if (myslot == -1) {
+ dev_err(&pdev->dev, "Cannot find PCI core!\n");
+ return -EIO;
+ }
+ /*
+ * Do not to map Versatile FPGA PCI device into memory space
+ */
+ pci_slot_ignore |= (1 << myslot);
+
+ dev_info(&pdev->dev, "PCI core found (slot %d)\n", myslot);
+
+ writel(myslot, PCI_SELFID);
+ local_pci_cfg_base = versatile_cfg_base[1] + (myslot << 11);
+
+ val = readl(local_pci_cfg_base + PCI_COMMAND);
+ val |= PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER | PCI_COMMAND_INVALIDATE;
+ writel(val, local_pci_cfg_base + PCI_COMMAND);
+
+ /*
+ * Configure the PCI inbound memory windows to be 1:1 mapped to SDRAM
+ */
+ writel(PHYS_OFFSET, local_pci_cfg_base + PCI_BASE_ADDRESS_0);
+ writel(PHYS_OFFSET, local_pci_cfg_base + PCI_BASE_ADDRESS_1);
+ writel(PHYS_OFFSET, local_pci_cfg_base + PCI_BASE_ADDRESS_2);
+
+ /*
+ * For many years the kernel and QEMU were symbiotically buggy
+ * in that they both assumed the same broken IRQ mapping.
+ * QEMU therefore attempts to auto-detect old broken kernels
+ * so that they still work on newer QEMU as they did on old
+ * QEMU. Since we now use the correct (ie matching-hardware)
+ * IRQ mapping we write a definitely different value to a
+ * PCI_INTERRUPT_LINE register to tell QEMU that we expect
+ * real hardware behaviour and it need not be backwards
+ * compatible for us. This write is harmless on real hardware.
+ */
+ writel(0, versatile_cfg_base[0] + PCI_INTERRUPT_LINE);
+
+ pci_add_flags(PCI_ENABLE_PROC_DOMAINS);
+ pci_add_flags(PCI_REASSIGN_ALL_BUS | PCI_REASSIGN_ALL_RSRC);
+
+ bus = pci_scan_root_bus(&pdev->dev, 0, &pci_versatile_ops, &sys, &pci_res);
+ if (!bus)
+ return -ENOMEM;
+
+ pci_fixup_irqs(pci_common_swizzle, of_irq_parse_and_map_pci);
+ pci_assign_unassigned_bus_resources(bus);
+
+ return 0;
+}
+
+static const struct of_device_id versatile_pci_of_match[] = {
+ { .compatible = "arm,versatile-pci", },
+ { },
+};
+MODULE_DEVICE_TABLE(of, versatile_pci_of_match);
+
+static struct platform_driver versatile_pci_driver = {
+ .driver = {
+ .name = "versatile-pci",
+ .of_match_table = versatile_pci_of_match,
+ },
+ .probe = versatile_pci_probe,
+};
+module_platform_driver(versatile_pci_driver);
+
+MODULE_DESCRIPTION("Versatile PCI driver");
+MODULE_LICENSE("GPLv2");
--
2.1.0
^ permalink raw reply related [flat|nested] 86+ messages in thread
* [PATCH 5/9] dts: versatile: add sysregs nodes
2014-12-30 19:28 ` Rob Herring
@ 2014-12-30 19:28 ` Rob Herring
-1 siblings, 0 replies; 86+ messages in thread
From: Rob Herring @ 2014-12-30 19:28 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: Russell King, Linus Walleij, Peter Maydell,
arm-DgEjT+Ai2ygdnm+yROfE0A, Bjorn Helgaas, Rob Herring
From: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
The Versatile boards have the same sysregs as other ARM Ltd boards. Add
the nodes in preparation to enable support for 24MHz counter as
sched_clock and MMC card detect and write protect support.
Signed-off-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
Cc: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
arch/arm/boot/dts/versatile-ab.dts | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/arch/arm/boot/dts/versatile-ab.dts b/arch/arm/boot/dts/versatile-ab.dts
index 27d0d9c..62f04b0 100644
--- a/arch/arm/boot/dts/versatile-ab.dts
+++ b/arch/arm/boot/dts/versatile-ab.dts
@@ -252,6 +252,29 @@
#size-cells = <1>;
ranges = <0 0x10000000 0x10000>;
+ sysreg@0 {
+ compatible = "arm,vexpress-sysreg";
+ reg = <0x00000 0x1000>;
+
+ v2m_led_gpios: sys_led@08 {
+ compatible = "arm,vexpress-sysreg,sys_led";
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ v2m_mmc_gpios: sys_mci@48 {
+ compatible = "arm,vexpress-sysreg,sys_mci";
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ v2m_flash_gpios: sys_flash@4c {
+ compatible = "arm,vexpress-sysreg,sys_flash";
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+ };
+
aaci@4000 {
compatible = "arm,primecell";
reg = <0x4000 0x1000>;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 86+ messages in thread
* [PATCH 5/9] dts: versatile: add sysregs nodes
@ 2014-12-30 19:28 ` Rob Herring
0 siblings, 0 replies; 86+ messages in thread
From: Rob Herring @ 2014-12-30 19:28 UTC (permalink / raw)
To: linux-arm-kernel
From: Rob Herring <robh@kernel.org>
The Versatile boards have the same sysregs as other ARM Ltd boards. Add
the nodes in preparation to enable support for 24MHz counter as
sched_clock and MMC card detect and write protect support.
Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Linus Walleij <linus.walleij@linaro.org>
---
arch/arm/boot/dts/versatile-ab.dts | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/arch/arm/boot/dts/versatile-ab.dts b/arch/arm/boot/dts/versatile-ab.dts
index 27d0d9c..62f04b0 100644
--- a/arch/arm/boot/dts/versatile-ab.dts
+++ b/arch/arm/boot/dts/versatile-ab.dts
@@ -252,6 +252,29 @@
#size-cells = <1>;
ranges = <0 0x10000000 0x10000>;
+ sysreg at 0 {
+ compatible = "arm,vexpress-sysreg";
+ reg = <0x00000 0x1000>;
+
+ v2m_led_gpios: sys_led at 08 {
+ compatible = "arm,vexpress-sysreg,sys_led";
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ v2m_mmc_gpios: sys_mci at 48 {
+ compatible = "arm,vexpress-sysreg,sys_mci";
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ v2m_flash_gpios: sys_flash at 4c {
+ compatible = "arm,vexpress-sysreg,sys_flash";
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+ };
+
aaci at 4000 {
compatible = "arm,primecell";
reg = <0x4000 0x1000>;
--
2.1.0
^ permalink raw reply related [flat|nested] 86+ messages in thread
* [PATCH 6/9] ARM: versatile: switch to DT only booting and remove legacy code
2014-12-30 19:28 ` Rob Herring
@ 2014-12-30 19:28 ` Rob Herring
-1 siblings, 0 replies; 86+ messages in thread
From: Rob Herring @ 2014-12-30 19:28 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: Russell King, Linus Walleij, Peter Maydell,
arm-DgEjT+Ai2ygdnm+yROfE0A, Bjorn Helgaas, Rob Herring,
Mike Turquette
From: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
With DT support for clocks, irqchips, timers, and PCI now in place, DT
based booting has feature parity with non-DT legacy boot. The final
piece is actually enabling common clock support on Versatile. Enabling
full DT support requires either removing the old Versatile clock code,
updating the legacy boot to use the common clock code, or making DT and
legacy boot mutually exclusive. Given that removing legacy boot code is
the goal anyway, I am going with the 1st option.
Tested on QEMU. Earlier versions of this patch have been tested on h/w
by Linus Walleij.
Signed-off-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
Cc: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Mike Turquette <mturquette-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
arch/arm/Kconfig | 14 +-
arch/arm/mach-versatile/Kconfig | 33 --
arch/arm/mach-versatile/Makefile | 6 +-
arch/arm/mach-versatile/core.c | 540 +-----------------------
arch/arm/mach-versatile/core.h | 9 +-
arch/arm/mach-versatile/include/mach/clkdev.h | 16 -
arch/arm/mach-versatile/include/mach/hardware.h | 6 -
arch/arm/mach-versatile/include/mach/irqs.h | 134 ------
arch/arm/mach-versatile/include/mach/platform.h | 174 --------
arch/arm/mach-versatile/pci.c | 368 ----------------
arch/arm/mach-versatile/versatile_ab.c | 44 --
arch/arm/mach-versatile/versatile_dt.c | 1 +
arch/arm/mach-versatile/versatile_pb.c | 91 ----
drivers/clk/versatile/Kconfig | 3 +-
14 files changed, 23 insertions(+), 1416 deletions(-)
delete mode 100644 arch/arm/mach-versatile/Kconfig
delete mode 100644 arch/arm/mach-versatile/include/mach/clkdev.h
delete mode 100644 arch/arm/mach-versatile/include/mach/irqs.h
delete mode 100644 arch/arm/mach-versatile/pci.c
delete mode 100644 arch/arm/mach-versatile/versatile_ab.c
delete mode 100644 arch/arm/mach-versatile/versatile_pb.c
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 97d07ed..7816b54 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -343,13 +343,15 @@ config ARCH_VERSATILE
select ARM_AMBA
select ARM_TIMER_SP804
select ARM_VIC
- select CLKDEV_LOOKUP
+ select CLKSRC_VERSATILE
+ select COMMON_CLK
+ select COMMON_CLK_VERSATILE
+ select CPU_ARM926T
select GENERIC_CLOCKEVENTS
- select HAVE_MACH_CLKDEV
select ICST
- select PLAT_VERSATILE
- select PLAT_VERSATILE_CLOCK
- select PLAT_VERSATILE_SCHED_CLOCK
+ select MIGHT_HAVE_PCI
+ select SPARSE_IRQ
+ select USE_OF
select VERSATILE_FPGA_IRQ
help
This enables support for ARM Ltd Versatile board.
@@ -954,8 +956,6 @@ source "arch/arm/mach-u300/Kconfig"
source "arch/arm/mach-ux500/Kconfig"
-source "arch/arm/mach-versatile/Kconfig"
-
source "arch/arm/mach-vexpress/Kconfig"
source "arch/arm/plat-versatile/Kconfig"
diff --git a/arch/arm/mach-versatile/Kconfig b/arch/arm/mach-versatile/Kconfig
deleted file mode 100644
index 1dba368..0000000
--- a/arch/arm/mach-versatile/Kconfig
+++ /dev/null
@@ -1,33 +0,0 @@
-menu "Versatile platform type"
- depends on ARCH_VERSATILE
-
-config ARCH_VERSATILE_PB
- bool "Support Versatile Platform Baseboard for ARM926EJ-S"
- default y
- select CPU_ARM926T
- select MIGHT_HAVE_PCI
- help
- Include support for the ARM(R) Versatile Platform Baseboard
- for the ARM926EJ-S.
-
-config MACH_VERSATILE_AB
- bool "Support Versatile Application Baseboard for ARM926EJ-S"
- select CPU_ARM926T
- help
- Include support for the ARM(R) Versatile Application Baseboard
- for the ARM926EJ-S.
-
-config MACH_VERSATILE_DT
- bool "Support Versatile platform from device tree"
- select CPU_ARM926T
- select USE_OF
- help
- Include support for the ARM(R) Versatile/PB platform,
- using the device tree for discovery
-
-config MACH_VERSATILE_AUTO
- def_bool y
- depends on !ARCH_VERSATILE_PB && !MACH_VERSATILE_AB
- select MACH_VERSATILE_DT
-
-endmenu
diff --git a/arch/arm/mach-versatile/Makefile b/arch/arm/mach-versatile/Makefile
index 81fa3fe..ccef512 100644
--- a/arch/arm/mach-versatile/Makefile
+++ b/arch/arm/mach-versatile/Makefile
@@ -2,8 +2,4 @@
# Makefile for the linux kernel.
#
-obj-y := core.o
-obj-$(CONFIG_ARCH_VERSATILE_PB) += versatile_pb.o
-obj-$(CONFIG_MACH_VERSATILE_AB) += versatile_ab.o
-obj-$(CONFIG_MACH_VERSATILE_DT) += versatile_dt.o
-obj-$(CONFIG_PCI) += pci.o
+obj-y := core.o versatile_dt.o
diff --git a/arch/arm/mach-versatile/core.c b/arch/arm/mach-versatile/core.c
index 08fb8c8..566a946 100644
--- a/arch/arm/mach-versatile/core.c
+++ b/arch/arm/mach-versatile/core.c
@@ -23,111 +23,22 @@
#include <linux/dma-mapping.h>
#include <linux/platform_device.h>
#include <linux/interrupt.h>
-#include <linux/irqdomain.h>
-#include <linux/of_address.h>
#include <linux/of_platform.h>
#include <linux/amba/bus.h>
#include <linux/amba/clcd.h>
#include <linux/platform_data/video-clcd-versatile.h>
-#include <linux/amba/pl061.h>
#include <linux/amba/mmci.h>
-#include <linux/amba/pl022.h>
#include <linux/io.h>
-#include <linux/irqchip/arm-vic.h>
-#include <linux/irqchip/versatile-fpga.h>
-#include <linux/gfp.h>
-#include <linux/clkdev.h>
#include <linux/mtd/physmap.h>
-#include <linux/bitops.h>
#include <linux/reboot.h>
-#include <asm/irq.h>
-#include <asm/hardware/arm_timer.h>
-#include <asm/hardware/icst.h>
-#include <asm/mach-types.h>
-
#include <asm/mach/arch.h>
-#include <asm/mach/irq.h>
-#include <asm/mach/time.h>
#include <asm/mach/map.h>
#include <mach/hardware.h>
#include <mach/platform.h>
-#include <asm/hardware/timer-sp.h>
-
-#include <plat/sched_clock.h>
#include "core.h"
-/*
- * All IO addresses are mapped onto VA 0xFFFx.xxxx, where x.xxxx
- * is the (PA >> 12).
- *
- * Setup a VA for the Versatile Vectored Interrupt Controller.
- */
-#define VA_VIC_BASE __io_address(VERSATILE_VIC_BASE)
-#define VA_SIC_BASE __io_address(VERSATILE_SIC_BASE)
-
-/* These PIC IRQs are valid in each configuration */
-#define PIC_VALID_ALL BIT(SIC_INT_KMI0) | BIT(SIC_INT_KMI1) | \
- BIT(SIC_INT_SCI3) | BIT(SIC_INT_UART3) | \
- BIT(SIC_INT_CLCD) | BIT(SIC_INT_TOUCH) | \
- BIT(SIC_INT_KEYPAD) | BIT(SIC_INT_DoC) | \
- BIT(SIC_INT_USB) | BIT(SIC_INT_PCI0) | \
- BIT(SIC_INT_PCI1) | BIT(SIC_INT_PCI2) | \
- BIT(SIC_INT_PCI3)
-#if 1
-#define IRQ_MMCI0A IRQ_VICSOURCE22
-#define IRQ_AACI IRQ_VICSOURCE24
-#define IRQ_ETH IRQ_VICSOURCE25
-#define PIC_MASK 0xFFD00000
-#define PIC_VALID PIC_VALID_ALL
-#else
-#define IRQ_MMCI0A IRQ_SIC_MMCI0A
-#define IRQ_AACI IRQ_SIC_AACI
-#define IRQ_ETH IRQ_SIC_ETH
-#define PIC_MASK 0
-#define PIC_VALID PIC_VALID_ALL | BIT(SIC_INT_MMCI0A) | \
- BIT(SIC_INT_MMCI1A) | BIT(SIC_INT_AACI) | \
- BIT(SIC_INT_ETH)
-#endif
-
-/* Lookup table for finding a DT node that represents the vic instance */
-static const struct of_device_id vic_of_match[] __initconst = {
- { .compatible = "arm,versatile-vic", },
- {}
-};
-
-static const struct of_device_id sic_of_match[] __initconst = {
- { .compatible = "arm,versatile-sic", },
- {}
-};
-
-void __init versatile_init_irq(void)
-{
- struct device_node *np;
-
- np = of_find_matching_node_by_address(NULL, vic_of_match,
- VERSATILE_VIC_BASE);
- __vic_init(VA_VIC_BASE, 0, IRQ_VIC_START, ~0, 0, np);
-
- writel(~0, VA_SIC_BASE + SIC_IRQ_ENABLE_CLEAR);
-
- np = of_find_matching_node_by_address(NULL, sic_of_match,
- VERSATILE_SIC_BASE);
-
- fpga_irq_init(VA_SIC_BASE, "SIC", IRQ_SIC_START,
- IRQ_VICSOURCE31, PIC_VALID, np);
-
- /*
- * Interrupts on secondary controller from 0 to 8 are routed to
- * source 31 on PIC.
- * Interrupts from 21 to 31 are routed directly to the VIC on
- * the corresponding number on primary controller. This is controlled
- * by setting PIC_ENABLEx.
- */
- writel(PIC_MASK, VA_SIC_BASE + SIC_INT_PIC_ENABLE);
-}
-
static struct map_desc versatile_io_desc[] __initdata __maybe_unused = {
{
.virtual = IO_ADDRESS(VERSATILE_SYS_BASE),
@@ -135,59 +46,16 @@ static struct map_desc versatile_io_desc[] __initdata __maybe_unused = {
.length = SZ_4K,
.type = MT_DEVICE
}, {
- .virtual = IO_ADDRESS(VERSATILE_SIC_BASE),
- .pfn = __phys_to_pfn(VERSATILE_SIC_BASE),
- .length = SZ_4K,
- .type = MT_DEVICE
- }, {
- .virtual = IO_ADDRESS(VERSATILE_VIC_BASE),
- .pfn = __phys_to_pfn(VERSATILE_VIC_BASE),
- .length = SZ_4K,
- .type = MT_DEVICE
- }, {
.virtual = IO_ADDRESS(VERSATILE_SCTL_BASE),
.pfn = __phys_to_pfn(VERSATILE_SCTL_BASE),
.length = SZ_4K * 9,
.type = MT_DEVICE
},
-#ifdef CONFIG_MACH_VERSATILE_AB
- {
- .virtual = IO_ADDRESS(VERSATILE_IB2_BASE),
- .pfn = __phys_to_pfn(VERSATILE_IB2_BASE),
- .length = SZ_64M,
- .type = MT_DEVICE
- },
-#endif
-#ifdef CONFIG_DEBUG_LL
- {
- .virtual = IO_ADDRESS(VERSATILE_UART0_BASE),
- .pfn = __phys_to_pfn(VERSATILE_UART0_BASE),
- .length = SZ_4K,
- .type = MT_DEVICE
- },
-#endif
-#ifdef CONFIG_PCI
- {
- .virtual = IO_ADDRESS(VERSATILE_PCI_CORE_BASE),
- .pfn = __phys_to_pfn(VERSATILE_PCI_CORE_BASE),
- .length = SZ_4K,
- .type = MT_DEVICE
- }, {
- .virtual = (unsigned long)VERSATILE_PCI_VIRT_BASE,
- .pfn = __phys_to_pfn(VERSATILE_PCI_BASE),
- .length = VERSATILE_PCI_BASE_SIZE,
- .type = MT_DEVICE
- }, {
- .virtual = (unsigned long)VERSATILE_PCI_CFG_VIRT_BASE,
- .pfn = __phys_to_pfn(VERSATILE_PCI_CFG_BASE),
- .length = VERSATILE_PCI_CFG_BASE_SIZE,
- .type = MT_DEVICE
- },
-#endif
};
void __init versatile_map_io(void)
{
+ debug_ll_io_init();
iotable_init(versatile_io_desc, ARRAY_SIZE(versatile_io_desc));
}
@@ -217,7 +85,7 @@ static struct resource versatile_flash_resource = {
.flags = IORESOURCE_MEM,
};
-static struct platform_device versatile_flash_device = {
+struct platform_device versatile_flash_device = {
.name = "physmap-flash",
.id = 0,
.dev = {
@@ -227,52 +95,6 @@ static struct platform_device versatile_flash_device = {
.resource = &versatile_flash_resource,
};
-static struct resource smc91x_resources[] = {
- [0] = {
- .start = VERSATILE_ETH_BASE,
- .end = VERSATILE_ETH_BASE + SZ_64K - 1,
- .flags = IORESOURCE_MEM,
- },
- [1] = {
- .start = IRQ_ETH,
- .end = IRQ_ETH,
- .flags = IORESOURCE_IRQ,
- },
-};
-
-static struct platform_device smc91x_device = {
- .name = "smc91x",
- .id = 0,
- .num_resources = ARRAY_SIZE(smc91x_resources),
- .resource = smc91x_resources,
-};
-
-static struct resource versatile_i2c_resource = {
- .start = VERSATILE_I2C_BASE,
- .end = VERSATILE_I2C_BASE + SZ_4K - 1,
- .flags = IORESOURCE_MEM,
-};
-
-static struct platform_device versatile_i2c_device = {
- .name = "versatile-i2c",
- .id = 0,
- .num_resources = 1,
- .resource = &versatile_i2c_resource,
-};
-
-static struct i2c_board_info versatile_i2c_board_info[] = {
- {
- I2C_BOARD_INFO("ds1338", 0xd0 >> 1),
- },
-};
-
-static int __init versatile_i2c_init(void)
-{
- return i2c_register_board_info(0, versatile_i2c_board_info,
- ARRAY_SIZE(versatile_i2c_board_info));
-}
-arch_initcall(versatile_i2c_init);
-
#define VERSATILE_SYSMCI (__io_address(VERSATILE_SYS_BASE) + VERSATILE_SYS_MCI_OFFSET)
unsigned int mmc_status(struct device *dev)
@@ -295,126 +117,11 @@ static struct mmci_platform_data mmc0_plat_data = {
.gpio_cd = -1,
};
-static struct resource char_lcd_resources[] = {
- {
- .start = VERSATILE_CHAR_LCD_BASE,
- .end = (VERSATILE_CHAR_LCD_BASE + SZ_4K - 1),
- .flags = IORESOURCE_MEM,
- },
-};
-
-static struct platform_device char_lcd_device = {
- .name = "arm-charlcd",
- .id = -1,
- .num_resources = ARRAY_SIZE(char_lcd_resources),
- .resource = char_lcd_resources,
-};
-
-static struct resource leds_resources[] = {
- {
- .start = VERSATILE_SYS_BASE + VERSATILE_SYS_LED_OFFSET,
- .end = VERSATILE_SYS_BASE + VERSATILE_SYS_LED_OFFSET + 4,
- .flags = IORESOURCE_MEM,
- },
-};
-
-static struct platform_device leds_device = {
- .name = "versatile-leds",
- .id = -1,
- .num_resources = ARRAY_SIZE(leds_resources),
- .resource = leds_resources,
-};
-
-/*
- * Clock handling
- */
-static const struct icst_params versatile_oscvco_params = {
- .ref = 24000000,
- .vco_max = ICST307_VCO_MAX,
- .vco_min = ICST307_VCO_MIN,
- .vd_min = 4 + 8,
- .vd_max = 511 + 8,
- .rd_min = 1 + 2,
- .rd_max = 127 + 2,
- .s2div = icst307_s2div,
- .idx2s = icst307_idx2s,
-};
-
-static void versatile_oscvco_set(struct clk *clk, struct icst_vco vco)
-{
- void __iomem *sys_lock = __io_address(VERSATILE_SYS_BASE) + VERSATILE_SYS_LOCK_OFFSET;
- u32 val;
-
- val = readl(clk->vcoreg) & ~0x7ffff;
- val |= vco.v | (vco.r << 9) | (vco.s << 16);
-
- writel(0xa05f, sys_lock);
- writel(val, clk->vcoreg);
- writel(0, sys_lock);
-}
-
-static const struct clk_ops osc4_clk_ops = {
- .round = icst_clk_round,
- .set = icst_clk_set,
- .setvco = versatile_oscvco_set,
-};
-
-static struct clk osc4_clk = {
- .ops = &osc4_clk_ops,
- .params = &versatile_oscvco_params,
-};
-
-/*
- * These are fixed clocks.
- */
-static struct clk ref24_clk = {
- .rate = 24000000,
-};
-
-static struct clk sp804_clk = {
- .rate = 1000000,
-};
-
-static struct clk dummy_apb_pclk;
-
-static struct clk_lookup lookups[] = {
- { /* AMBA bus clock */
- .con_id = "apb_pclk",
- .clk = &dummy_apb_pclk,
- }, { /* UART0 */
- .dev_id = "dev:f1",
- .clk = &ref24_clk,
- }, { /* UART1 */
- .dev_id = "dev:f2",
- .clk = &ref24_clk,
- }, { /* UART2 */
- .dev_id = "dev:f3",
- .clk = &ref24_clk,
- }, { /* UART3 */
- .dev_id = "fpga:09",
- .clk = &ref24_clk,
- }, { /* KMI0 */
- .dev_id = "fpga:06",
- .clk = &ref24_clk,
- }, { /* KMI1 */
- .dev_id = "fpga:07",
- .clk = &ref24_clk,
- }, { /* MMC0 */
- .dev_id = "fpga:05",
- .clk = &ref24_clk,
- }, { /* MMC1 */
- .dev_id = "fpga:0b",
- .clk = &ref24_clk,
- }, { /* SSP */
- .dev_id = "dev:f4",
- .clk = &ref24_clk,
- }, { /* CLCD */
- .dev_id = "dev:20",
- .clk = &osc4_clk,
- }, { /* SP804 timers */
- .dev_id = "sp804",
- .clk = &sp804_clk,
- },
+static struct mmci_platform_data mmc1_plat_data = {
+ .ocr_mask = MMC_VDD_32_33|MMC_VDD_33_34,
+ .status = mmc_status,
+ .gpio_wp = -1,
+ .gpio_cd = -1,
};
/*
@@ -449,11 +156,10 @@ static void versatile_clcd_disable(struct clcd_fb *fb)
val &= ~SYS_CLCD_NLCDIOON | SYS_CLCD_PWR3V5SWITCH;
writel(val, sys_clcd);
-#ifdef CONFIG_MACH_VERSATILE_AB
/*
* If the LCD is Sanyo 2x5 in on the IB2 board, turn the back-light off
*/
- if (machine_is_versatile_ab() && is_sanyo_2_5_lcd) {
+ if (of_machine_is_compatible("arm,versatile-ab") && is_sanyo_2_5_lcd) {
void __iomem *versatile_ib2_ctrl = __io_address(VERSATILE_IB2_CTRL);
unsigned long ctrl;
@@ -461,7 +167,6 @@ static void versatile_clcd_disable(struct clcd_fb *fb)
ctrl &= ~0x01;
writel(ctrl, versatile_ib2_ctrl);
}
-#endif
}
/*
@@ -502,11 +207,10 @@ static void versatile_clcd_enable(struct clcd_fb *fb)
val |= SYS_CLCD_NLCDIOON | SYS_CLCD_PWR3V5SWITCH;
writel(val, sys_clcd);
-#ifdef CONFIG_MACH_VERSATILE_AB
/*
* If the LCD is Sanyo 2x5 in on the IB2 board, turn the back-light on
*/
- if (machine_is_versatile_ab() && is_sanyo_2_5_lcd) {
+ if (of_machine_is_compatible("arm,versatile-ab") && is_sanyo_2_5_lcd) {
void __iomem *versatile_ib2_ctrl = __io_address(VERSATILE_IB2_CTRL);
unsigned long ctrl;
@@ -514,7 +218,6 @@ static void versatile_clcd_enable(struct clcd_fb *fb)
ctrl |= 0x01;
writel(ctrl, versatile_ib2_ctrl);
}
-#endif
}
/*
@@ -575,113 +278,6 @@ static struct clcd_board clcd_plat_data = {
.remove = versatile_clcd_remove_dma,
};
-static struct pl061_platform_data gpio0_plat_data = {
- .gpio_base = 0,
- .irq_base = IRQ_GPIO0_START,
-};
-
-static struct pl061_platform_data gpio1_plat_data = {
- .gpio_base = 8,
- .irq_base = IRQ_GPIO1_START,
-};
-
-static struct pl061_platform_data gpio2_plat_data = {
- .gpio_base = 16,
- .irq_base = IRQ_GPIO2_START,
-};
-
-static struct pl061_platform_data gpio3_plat_data = {
- .gpio_base = 24,
- .irq_base = IRQ_GPIO3_START,
-};
-
-static struct pl022_ssp_controller ssp0_plat_data = {
- .bus_id = 0,
- .enable_dma = 0,
- .num_chipselect = 1,
-};
-
-#define AACI_IRQ { IRQ_AACI }
-#define MMCI0_IRQ { IRQ_MMCI0A,IRQ_SIC_MMCI0B }
-#define KMI0_IRQ { IRQ_SIC_KMI0 }
-#define KMI1_IRQ { IRQ_SIC_KMI1 }
-
-/*
- * These devices are connected directly to the multi-layer AHB switch
- */
-#define SMC_IRQ { }
-#define MPMC_IRQ { }
-#define CLCD_IRQ { IRQ_CLCDINT }
-#define DMAC_IRQ { IRQ_DMAINT }
-
-/*
- * These devices are connected via the core APB bridge
- */
-#define SCTL_IRQ { }
-#define WATCHDOG_IRQ { IRQ_WDOGINT }
-#define GPIO0_IRQ { IRQ_GPIOINT0 }
-#define GPIO1_IRQ { IRQ_GPIOINT1 }
-#define GPIO2_IRQ { IRQ_GPIOINT2 }
-#define GPIO3_IRQ { IRQ_GPIOINT3 }
-#define RTC_IRQ { IRQ_RTCINT }
-
-/*
- * These devices are connected via the DMA APB bridge
- */
-#define SCI_IRQ { IRQ_SCIINT }
-#define UART0_IRQ { IRQ_UARTINT0 }
-#define UART1_IRQ { IRQ_UARTINT1 }
-#define UART2_IRQ { IRQ_UARTINT2 }
-#define SSP_IRQ { IRQ_SSPINT }
-
-/* FPGA Primecells */
-APB_DEVICE(aaci, "fpga:04", AACI, NULL);
-APB_DEVICE(mmc0, "fpga:05", MMCI0, &mmc0_plat_data);
-APB_DEVICE(kmi0, "fpga:06", KMI0, NULL);
-APB_DEVICE(kmi1, "fpga:07", KMI1, NULL);
-
-/* DevChip Primecells */
-AHB_DEVICE(smc, "dev:00", SMC, NULL);
-AHB_DEVICE(mpmc, "dev:10", MPMC, NULL);
-AHB_DEVICE(clcd, "dev:20", CLCD, &clcd_plat_data);
-AHB_DEVICE(dmac, "dev:30", DMAC, NULL);
-APB_DEVICE(sctl, "dev:e0", SCTL, NULL);
-APB_DEVICE(wdog, "dev:e1", WATCHDOG, NULL);
-APB_DEVICE(gpio0, "dev:e4", GPIO0, &gpio0_plat_data);
-APB_DEVICE(gpio1, "dev:e5", GPIO1, &gpio1_plat_data);
-APB_DEVICE(gpio2, "dev:e6", GPIO2, &gpio2_plat_data);
-APB_DEVICE(gpio3, "dev:e7", GPIO3, &gpio3_plat_data);
-APB_DEVICE(rtc, "dev:e8", RTC, NULL);
-APB_DEVICE(sci0, "dev:f0", SCI, NULL);
-APB_DEVICE(uart0, "dev:f1", UART0, NULL);
-APB_DEVICE(uart1, "dev:f2", UART1, NULL);
-APB_DEVICE(uart2, "dev:f3", UART2, NULL);
-APB_DEVICE(ssp0, "dev:f4", SSP, &ssp0_plat_data);
-
-static struct amba_device *amba_devs[] __initdata = {
- &dmac_device,
- &uart0_device,
- &uart1_device,
- &uart2_device,
- &smc_device,
- &mpmc_device,
- &clcd_device,
- &sctl_device,
- &wdog_device,
- &gpio0_device,
- &gpio1_device,
- &gpio2_device,
- &gpio3_device,
- &rtc_device,
- &sci0_device,
- &ssp0_device,
- &aaci_device,
- &mmc0_device,
- &kmi0_device,
- &kmi1_device,
-};
-
-#ifdef CONFIG_OF
/*
* Lookup table for attaching a specific name and platform_data pointer to
* devices as they get created by of_platform_populate(). Ideally this table
@@ -690,80 +286,12 @@ static struct amba_device *amba_devs[] __initdata = {
*/
struct of_dev_auxdata versatile_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA("arm,primecell", VERSATILE_MMCI0_BASE, "fpga:05", &mmc0_plat_data),
- OF_DEV_AUXDATA("arm,primecell", VERSATILE_KMI0_BASE, "fpga:06", NULL),
- OF_DEV_AUXDATA("arm,primecell", VERSATILE_KMI1_BASE, "fpga:07", NULL),
- OF_DEV_AUXDATA("arm,primecell", VERSATILE_UART3_BASE, "fpga:09", NULL),
- /* FIXME: this is buggy, the platform data is needed for this MMC instance too */
- OF_DEV_AUXDATA("arm,primecell", VERSATILE_MMCI1_BASE, "fpga:0b", NULL),
+ OF_DEV_AUXDATA("arm,primecell", VERSATILE_MMCI1_BASE, "fpga:0b", &mmc1_plat_data),
OF_DEV_AUXDATA("arm,primecell", VERSATILE_CLCD_BASE, "dev:20", &clcd_plat_data),
- OF_DEV_AUXDATA("arm,primecell", VERSATILE_UART0_BASE, "dev:f1", NULL),
- OF_DEV_AUXDATA("arm,primecell", VERSATILE_UART1_BASE, "dev:f2", NULL),
- OF_DEV_AUXDATA("arm,primecell", VERSATILE_UART2_BASE, "dev:f3", NULL),
- OF_DEV_AUXDATA("arm,primecell", VERSATILE_SSP_BASE, "dev:f4", &ssp0_plat_data),
-#if 0
- /*
- * These entries are unnecessary because no clocks referencing
- * them. I've left them in for now as place holders in case
- * any of them need to be added back, but they should be
- * removed before actually committing this patch. --gcl
- */
- OF_DEV_AUXDATA("arm,primecell", VERSATILE_AACI_BASE, "fpga:04", NULL),
- OF_DEV_AUXDATA("arm,primecell", VERSATILE_SCI1_BASE, "fpga:0a", NULL),
- OF_DEV_AUXDATA("arm,primecell", VERSATILE_SMC_BASE, "dev:00", NULL),
- OF_DEV_AUXDATA("arm,primecell", VERSATILE_MPMC_BASE, "dev:10", NULL),
- OF_DEV_AUXDATA("arm,primecell", VERSATILE_DMAC_BASE, "dev:30", NULL),
-
- OF_DEV_AUXDATA("arm,primecell", VERSATILE_SCTL_BASE, "dev:e0", NULL),
- OF_DEV_AUXDATA("arm,primecell", VERSATILE_WATCHDOG_BASE, "dev:e1", NULL),
- OF_DEV_AUXDATA("arm,primecell", VERSATILE_GPIO0_BASE, "dev:e4", NULL),
- OF_DEV_AUXDATA("arm,primecell", VERSATILE_GPIO1_BASE, "dev:e5", NULL),
- OF_DEV_AUXDATA("arm,primecell", VERSATILE_GPIO2_BASE, "dev:e6", NULL),
- OF_DEV_AUXDATA("arm,primecell", VERSATILE_GPIO3_BASE, "dev:e7", NULL),
- OF_DEV_AUXDATA("arm,primecell", VERSATILE_RTC_BASE, "dev:e8", NULL),
- OF_DEV_AUXDATA("arm,primecell", VERSATILE_SCI_BASE, "dev:f0", NULL),
-#endif
{}
};
-#endif
-
-#ifdef CONFIG_LEDS
-#define VA_LEDS_BASE (__io_address(VERSATILE_SYS_BASE) + VERSATILE_SYS_LED_OFFSET)
-
-static void versatile_leds_event(led_event_t ledevt)
-{
- unsigned long flags;
- u32 val;
-
- local_irq_save(flags);
- val = readl(VA_LEDS_BASE);
-
- switch (ledevt) {
- case led_idle_start:
- val = val & ~VERSATILE_SYS_LED0;
- break;
-
- case led_idle_end:
- val = val | VERSATILE_SYS_LED0;
- break;
-
- case led_timer:
- val = val ^ VERSATILE_SYS_LED1;
- break;
-
- case led_halted:
- val = 0;
- break;
-
- default:
- break;
- }
-
- writel(val, VA_LEDS_BASE);
- local_irq_restore(flags);
-}
-#endif /* CONFIG_LEDS */
void versatile_restart(enum reboot_mode mode, const char *cmd)
{
@@ -782,12 +310,6 @@ void versatile_restart(enum reboot_mode mode, const char *cmd)
void __init versatile_init_early(void)
{
u32 val;
- void __iomem *sys = __io_address(VERSATILE_SYS_BASE);
-
- osc4_clk.vcoreg = sys + VERSATILE_SYS_OSCCLCD_OFFSET;
- clkdev_add_table(lookups, ARRAY_SIZE(lookups));
-
- versatile_sched_clock_init(sys + VERSATILE_SYS_24MHz_OFFSET, 24000000);
/*
* set clock frequency:
@@ -801,45 +323,3 @@ void __init versatile_init_early(void)
(VERSATILE_TIMCLK << VERSATILE_TIMER4_EnSel) | val,
__io_address(VERSATILE_SCTL_BASE));
}
-
-void __init versatile_init(void)
-{
- int i;
-
- platform_device_register(&versatile_flash_device);
- platform_device_register(&versatile_i2c_device);
- platform_device_register(&smc91x_device);
- platform_device_register(&char_lcd_device);
- platform_device_register(&leds_device);
-
- for (i = 0; i < ARRAY_SIZE(amba_devs); i++) {
- struct amba_device *d = amba_devs[i];
- amba_device_register(d, &iomem_resource);
- }
-}
-
-/*
- * Where is the timer (VA)?
- */
-#define TIMER0_VA_BASE __io_address(VERSATILE_TIMER0_1_BASE)
-#define TIMER1_VA_BASE (__io_address(VERSATILE_TIMER0_1_BASE) + 0x20)
-#define TIMER2_VA_BASE __io_address(VERSATILE_TIMER2_3_BASE)
-#define TIMER3_VA_BASE (__io_address(VERSATILE_TIMER2_3_BASE) + 0x20)
-
-/*
- * Set up timer interrupt, and return the current time in seconds.
- */
-void __init versatile_timer_init(void)
-{
-
- /*
- * Initialise to a known state (all timers off)
- */
- writel(0, TIMER0_VA_BASE + TIMER_CTRL);
- writel(0, TIMER1_VA_BASE + TIMER_CTRL);
- writel(0, TIMER2_VA_BASE + TIMER_CTRL);
- writel(0, TIMER3_VA_BASE + TIMER_CTRL);
-
- sp804_clocksource_init(TIMER3_VA_BASE, "timer3");
- sp804_clockevents_init(TIMER0_VA_BASE, IRQ_TIMERINT0_1, "timer0");
-}
diff --git a/arch/arm/mach-versatile/core.h b/arch/arm/mach-versatile/core.h
index f06d576..c3d7157 100644
--- a/arch/arm/mach-versatile/core.h
+++ b/arch/arm/mach-versatile/core.h
@@ -26,7 +26,8 @@
#include <linux/of_platform.h>
#include <linux/reboot.h>
-extern void __init versatile_init(void);
+extern struct platform_device versatile_flash_device;
+
extern void __init versatile_init_early(void);
extern void __init versatile_init_irq(void);
extern void __init versatile_map_io(void);
@@ -37,10 +38,4 @@ extern unsigned int mmc_status(struct device *dev);
extern struct of_dev_auxdata versatile_auxdata_lookup[];
#endif
-#define APB_DEVICE(name, busid, base, plat) \
-static AMBA_APB_DEVICE(name, busid, 0, VERSATILE_##base##_BASE, base##_IRQ, plat)
-
-#define AHB_DEVICE(name, busid, base, plat) \
-static AMBA_AHB_DEVICE(name, busid, 0, VERSATILE_##base##_BASE, base##_IRQ, plat)
-
#endif
diff --git a/arch/arm/mach-versatile/include/mach/clkdev.h b/arch/arm/mach-versatile/include/mach/clkdev.h
deleted file mode 100644
index e58d077..0000000
--- a/arch/arm/mach-versatile/include/mach/clkdev.h
+++ /dev/null
@@ -1,16 +0,0 @@
-#ifndef __ASM_MACH_CLKDEV_H
-#define __ASM_MACH_CLKDEV_H
-
-#include <plat/clock.h>
-
-struct clk {
- unsigned long rate;
- const struct clk_ops *ops;
- const struct icst_params *params;
- void __iomem *vcoreg;
-};
-
-#define __clk_get(clk) ({ 1; })
-#define __clk_put(clk) do { } while (0)
-
-#endif
diff --git a/arch/arm/mach-versatile/include/mach/hardware.h b/arch/arm/mach-versatile/include/mach/hardware.h
index 3e5d425..22a1158 100644
--- a/arch/arm/mach-versatile/include/mach/hardware.h
+++ b/arch/arm/mach-versatile/include/mach/hardware.h
@@ -24,12 +24,6 @@
#include <asm/sizes.h>
-/*
- * PCI space virtual addresses
- */
-#define VERSATILE_PCI_VIRT_BASE (void __iomem *)0xe8000000ul
-#define VERSATILE_PCI_CFG_VIRT_BASE (void __iomem *)0xe9000000ul
-
/* macro to get at MMIO space when running virtually */
#define IO_ADDRESS(x) (((x) & 0x0fffffff) + (((x) >> 4) & 0x0f000000) + 0xf0000000)
diff --git a/arch/arm/mach-versatile/include/mach/irqs.h b/arch/arm/mach-versatile/include/mach/irqs.h
deleted file mode 100644
index 0fd771c..0000000
--- a/arch/arm/mach-versatile/include/mach/irqs.h
+++ /dev/null
@@ -1,134 +0,0 @@
-/*
- * arch/arm/mach-versatile/include/mach/irqs.h
- *
- * Copyright (C) 2003 ARM Limited
- * Copyright (C) 2000 Deep Blue Solutions Ltd.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
- */
-
-#include <mach/platform.h>
-
-/*
- * IRQ interrupts definitions are the same as the INT definitions
- * held within platform.h
- */
-#define IRQ_VIC_START 32
-#define IRQ_WDOGINT (IRQ_VIC_START + INT_WDOGINT)
-#define IRQ_SOFTINT (IRQ_VIC_START + INT_SOFTINT)
-#define IRQ_COMMRx (IRQ_VIC_START + INT_COMMRx)
-#define IRQ_COMMTx (IRQ_VIC_START + INT_COMMTx)
-#define IRQ_TIMERINT0_1 (IRQ_VIC_START + INT_TIMERINT0_1)
-#define IRQ_TIMERINT2_3 (IRQ_VIC_START + INT_TIMERINT2_3)
-#define IRQ_GPIOINT0 (IRQ_VIC_START + INT_GPIOINT0)
-#define IRQ_GPIOINT1 (IRQ_VIC_START + INT_GPIOINT1)
-#define IRQ_GPIOINT2 (IRQ_VIC_START + INT_GPIOINT2)
-#define IRQ_GPIOINT3 (IRQ_VIC_START + INT_GPIOINT3)
-#define IRQ_RTCINT (IRQ_VIC_START + INT_RTCINT)
-#define IRQ_SSPINT (IRQ_VIC_START + INT_SSPINT)
-#define IRQ_UARTINT0 (IRQ_VIC_START + INT_UARTINT0)
-#define IRQ_UARTINT1 (IRQ_VIC_START + INT_UARTINT1)
-#define IRQ_UARTINT2 (IRQ_VIC_START + INT_UARTINT2)
-#define IRQ_SCIINT (IRQ_VIC_START + INT_SCIINT)
-#define IRQ_CLCDINT (IRQ_VIC_START + INT_CLCDINT)
-#define IRQ_DMAINT (IRQ_VIC_START + INT_DMAINT)
-#define IRQ_PWRFAILINT (IRQ_VIC_START + INT_PWRFAILINT)
-#define IRQ_MBXINT (IRQ_VIC_START + INT_MBXINT)
-#define IRQ_GNDINT (IRQ_VIC_START + INT_GNDINT)
-#define IRQ_VICSOURCE21 (IRQ_VIC_START + INT_VICSOURCE21)
-#define IRQ_VICSOURCE22 (IRQ_VIC_START + INT_VICSOURCE22)
-#define IRQ_VICSOURCE23 (IRQ_VIC_START + INT_VICSOURCE23)
-#define IRQ_VICSOURCE24 (IRQ_VIC_START + INT_VICSOURCE24)
-#define IRQ_VICSOURCE25 (IRQ_VIC_START + INT_VICSOURCE25)
-#define IRQ_VICSOURCE26 (IRQ_VIC_START + INT_VICSOURCE26)
-#define IRQ_VICSOURCE27 (IRQ_VIC_START + INT_VICSOURCE27)
-#define IRQ_VICSOURCE28 (IRQ_VIC_START + INT_VICSOURCE28)
-#define IRQ_VICSOURCE29 (IRQ_VIC_START + INT_VICSOURCE29)
-#define IRQ_VICSOURCE30 (IRQ_VIC_START + INT_VICSOURCE30)
-#define IRQ_VICSOURCE31 (IRQ_VIC_START + INT_VICSOURCE31)
-#define IRQ_VIC_END (IRQ_VIC_START + 31)
-
-/*
- * FIQ interrupts definitions are the same as the INT definitions.
- */
-#define FIQ_WDOGINT INT_WDOGINT
-#define FIQ_SOFTINT INT_SOFTINT
-#define FIQ_COMMRx INT_COMMRx
-#define FIQ_COMMTx INT_COMMTx
-#define FIQ_TIMERINT0_1 INT_TIMERINT0_1
-#define FIQ_TIMERINT2_3 INT_TIMERINT2_3
-#define FIQ_GPIOINT0 INT_GPIOINT0
-#define FIQ_GPIOINT1 INT_GPIOINT1
-#define FIQ_GPIOINT2 INT_GPIOINT2
-#define FIQ_GPIOINT3 INT_GPIOINT3
-#define FIQ_RTCINT INT_RTCINT
-#define FIQ_SSPINT INT_SSPINT
-#define FIQ_UARTINT0 INT_UARTINT0
-#define FIQ_UARTINT1 INT_UARTINT1
-#define FIQ_UARTINT2 INT_UARTINT2
-#define FIQ_SCIINT INT_SCIINT
-#define FIQ_CLCDINT INT_CLCDINT
-#define FIQ_DMAINT INT_DMAINT
-#define FIQ_PWRFAILINT INT_PWRFAILINT
-#define FIQ_MBXINT INT_MBXINT
-#define FIQ_GNDINT INT_GNDINT
-#define FIQ_VICSOURCE21 INT_VICSOURCE21
-#define FIQ_VICSOURCE22 INT_VICSOURCE22
-#define FIQ_VICSOURCE23 INT_VICSOURCE23
-#define FIQ_VICSOURCE24 INT_VICSOURCE24
-#define FIQ_VICSOURCE25 INT_VICSOURCE25
-#define FIQ_VICSOURCE26 INT_VICSOURCE26
-#define FIQ_VICSOURCE27 INT_VICSOURCE27
-#define FIQ_VICSOURCE28 INT_VICSOURCE28
-#define FIQ_VICSOURCE29 INT_VICSOURCE29
-#define FIQ_VICSOURCE30 INT_VICSOURCE30
-#define FIQ_VICSOURCE31 INT_VICSOURCE31
-
-
-/*
- * Secondary interrupt controller
- */
-#define IRQ_SIC_START 64
-#define IRQ_SIC_MMCI0B (IRQ_SIC_START + SIC_INT_MMCI0B)
-#define IRQ_SIC_MMCI1B (IRQ_SIC_START + SIC_INT_MMCI1B)
-#define IRQ_SIC_KMI0 (IRQ_SIC_START + SIC_INT_KMI0)
-#define IRQ_SIC_KMI1 (IRQ_SIC_START + SIC_INT_KMI1)
-#define IRQ_SIC_SCI3 (IRQ_SIC_START + SIC_INT_SCI3)
-#define IRQ_SIC_UART3 (IRQ_SIC_START + SIC_INT_UART3)
-#define IRQ_SIC_CLCD (IRQ_SIC_START + SIC_INT_CLCD)
-#define IRQ_SIC_TOUCH (IRQ_SIC_START + SIC_INT_TOUCH)
-#define IRQ_SIC_KEYPAD (IRQ_SIC_START + SIC_INT_KEYPAD)
-#define IRQ_SIC_DoC (IRQ_SIC_START + SIC_INT_DoC)
-#define IRQ_SIC_MMCI0A (IRQ_SIC_START + SIC_INT_MMCI0A)
-#define IRQ_SIC_MMCI1A (IRQ_SIC_START + SIC_INT_MMCI1A)
-#define IRQ_SIC_AACI (IRQ_SIC_START + SIC_INT_AACI)
-#define IRQ_SIC_ETH (IRQ_SIC_START + SIC_INT_ETH)
-#define IRQ_SIC_USB (IRQ_SIC_START + SIC_INT_USB)
-#define IRQ_SIC_PCI0 (IRQ_SIC_START + SIC_INT_PCI0)
-#define IRQ_SIC_PCI1 (IRQ_SIC_START + SIC_INT_PCI1)
-#define IRQ_SIC_PCI2 (IRQ_SIC_START + SIC_INT_PCI2)
-#define IRQ_SIC_PCI3 (IRQ_SIC_START + SIC_INT_PCI3)
-#define IRQ_SIC_END 95
-
-#define IRQ_GPIO0_START (IRQ_SIC_END + 1)
-#define IRQ_GPIO0_END (IRQ_GPIO0_START + 31)
-#define IRQ_GPIO1_START (IRQ_GPIO0_END + 1)
-#define IRQ_GPIO1_END (IRQ_GPIO1_START + 31)
-#define IRQ_GPIO2_START (IRQ_GPIO1_END + 1)
-#define IRQ_GPIO2_END (IRQ_GPIO2_START + 31)
-#define IRQ_GPIO3_START (IRQ_GPIO2_END + 1)
-#define IRQ_GPIO3_END (IRQ_GPIO3_START + 31)
-
-#define NR_IRQS (IRQ_GPIO3_END + 1)
diff --git a/arch/arm/mach-versatile/include/mach/platform.h b/arch/arm/mach-versatile/include/mach/platform.h
index 6f938cc..7fe008b 100644
--- a/arch/arm/mach-versatile/include/mach/platform.h
+++ b/arch/arm/mach-versatile/include/mach/platform.h
@@ -185,79 +185,13 @@
/*
* VERSATILE peripheral addresses
*/
-#define VERSATILE_PCI_CORE_BASE 0x10001000 /* PCI core control */
-#define VERSATILE_I2C_BASE 0x10002000 /* I2C control */
-#define VERSATILE_SIC_BASE 0x10003000 /* Secondary interrupt controller */
-#define VERSATILE_AACI_BASE 0x10004000 /* Audio */
#define VERSATILE_MMCI0_BASE 0x10005000 /* MMC interface */
-#define VERSATILE_KMI0_BASE 0x10006000 /* KMI interface */
-#define VERSATILE_KMI1_BASE 0x10007000 /* KMI 2nd interface */
-#define VERSATILE_CHAR_LCD_BASE 0x10008000 /* Character LCD */
-#define VERSATILE_UART3_BASE 0x10009000 /* UART 3 */
-#define VERSATILE_SCI1_BASE 0x1000A000
#define VERSATILE_MMCI1_BASE 0x1000B000 /* MMC Interface */
- /* 0x1000C000 - 0x1000CFFF = reserved */
-#define VERSATILE_ETH_BASE 0x10010000 /* Ethernet */
-#define VERSATILE_USB_BASE 0x10020000 /* USB */
- /* 0x10030000 - 0x100FFFFF = reserved */
-#define VERSATILE_SMC_BASE 0x10100000 /* SMC */
-#define VERSATILE_MPMC_BASE 0x10110000 /* MPMC */
#define VERSATILE_CLCD_BASE 0x10120000 /* CLCD */
-#define VERSATILE_DMAC_BASE 0x10130000 /* DMA controller */
-#define VERSATILE_VIC_BASE 0x10140000 /* Vectored interrupt controller */
-#define VERSATILE_PERIPH_BASE 0x10150000 /* off-chip peripherals alias from */
- /* 0x10000000 - 0x100FFFFF */
-#define VERSATILE_AHBM_BASE 0x101D0000 /* AHB monitor */
#define VERSATILE_SCTL_BASE 0x101E0000 /* System controller */
-#define VERSATILE_WATCHDOG_BASE 0x101E1000 /* Watchdog */
-#define VERSATILE_TIMER0_1_BASE 0x101E2000 /* Timer 0 and 1 */
-#define VERSATILE_TIMER2_3_BASE 0x101E3000 /* Timer 2 and 3 */
-#define VERSATILE_GPIO0_BASE 0x101E4000 /* GPIO port 0 */
-#define VERSATILE_GPIO1_BASE 0x101E5000 /* GPIO port 1 */
-#define VERSATILE_GPIO2_BASE 0x101E6000 /* GPIO port 2 */
-#define VERSATILE_GPIO3_BASE 0x101E7000 /* GPIO port 3 */
-#define VERSATILE_RTC_BASE 0x101E8000 /* Real Time Clock */
- /* 0x101E9000 - reserved */
-#define VERSATILE_SCI_BASE 0x101F0000 /* Smart card controller */
-#define VERSATILE_UART0_BASE 0x101F1000 /* Uart 0 */
-#define VERSATILE_UART1_BASE 0x101F2000 /* Uart 1 */
-#define VERSATILE_UART2_BASE 0x101F3000 /* Uart 2 */
-#define VERSATILE_SSP_BASE 0x101F4000 /* Synchronous Serial Port */
-
-#define VERSATILE_SSMC_BASE 0x20000000 /* SSMC */
#define VERSATILE_IB2_BASE 0x24000000 /* IB2 module */
-#define VERSATILE_MBX_BASE 0x40000000 /* MBX */
-
-/* PCI space */
-#define VERSATILE_PCI_BASE 0x41000000 /* PCI Interface */
-#define VERSATILE_PCI_CFG_BASE 0x42000000
-#define VERSATILE_PCI_IO_BASE 0x43000000
-#define VERSATILE_PCI_MEM_BASE0 0x44000000
-#define VERSATILE_PCI_MEM_BASE1 0x50000000
-#define VERSATILE_PCI_MEM_BASE2 0x60000000
-/* Sizes of above maps */
-#define VERSATILE_PCI_BASE_SIZE 0x01000000
-#define VERSATILE_PCI_CFG_BASE_SIZE 0x02000000
-#define VERSATILE_PCI_IO_BASE_SIZE 0x01000000
-#define VERSATILE_PCI_MEM_BASE0_SIZE 0x0c000000 /* 32Mb */
-#define VERSATILE_PCI_MEM_BASE1_SIZE 0x10000000 /* 256Mb */
-#define VERSATILE_PCI_MEM_BASE2_SIZE 0x10000000 /* 256Mb */
-
-#define VERSATILE_SDRAM67_BASE 0x70000000 /* SDRAM banks 6 and 7 */
-#define VERSATILE_LT_BASE 0x80000000 /* Logic Tile expansion */
/*
- * Disk on Chip
- */
-#define VERSATILE_DOC_BASE 0x2C000000
-#define VERSATILE_DOC_SIZE (16 << 20)
-#define VERSATILE_DOC_PAGE_SIZE 512
-#define VERSATILE_DOC_TOTAL_PAGES (DOC_SIZE / PAGE_SIZE)
-
-#define ERASE_UNIT_PAGES 32
-#define START_PAGE 0x80
-
-/*
* LED settings, bits [7:0]
*/
#define VERSATILE_SYS_LED0 (1 << 0)
@@ -281,106 +215,6 @@
#define VERSATILE_INTREG_OFFSET 0x8 /* Interrupt control */
#define VERSATILE_DECODE_OFFSET 0xC /* Fitted logic modules */
-
-/* ------------------------------------------------------------------------
- * Versatile Interrupt Controller - control registers
- * ------------------------------------------------------------------------
- *
- * Offsets from interrupt controller base
- *
- * System Controller interrupt controller base is
- *
- * VERSATILE_IC_BASE
- *
- * Core Module interrupt controller base is
- *
- * VERSATILE_SYS_IC
- *
- */
-/* VIC definitions in include/asm-arm/hardware/vic.h */
-
-#define SIC_IRQ_STATUS 0
-#define SIC_IRQ_RAW_STATUS 0x04
-#define SIC_IRQ_ENABLE 0x08
-#define SIC_IRQ_ENABLE_SET 0x08
-#define SIC_IRQ_ENABLE_CLEAR 0x0C
-#define SIC_INT_SOFT_SET 0x10
-#define SIC_INT_SOFT_CLEAR 0x14
-#define SIC_INT_PIC_ENABLE 0x20 /* read status of pass through mask */
-#define SIC_INT_PIC_ENABLES 0x20 /* set interrupt pass through bits */
-#define SIC_INT_PIC_ENABLEC 0x24 /* Clear interrupt pass through bits */
-
-/* ------------------------------------------------------------------------
- * Interrupts - bit assignment (primary)
- * ------------------------------------------------------------------------
- */
-
-#define INT_WDOGINT 0 /* Watchdog timer */
-#define INT_SOFTINT 1 /* Software interrupt */
-#define INT_COMMRx 2 /* Debug Comm Rx interrupt */
-#define INT_COMMTx 3 /* Debug Comm Tx interrupt */
-#define INT_TIMERINT0_1 4 /* Timer 0 and 1 */
-#define INT_TIMERINT2_3 5 /* Timer 2 and 3 */
-#define INT_GPIOINT0 6 /* GPIO 0 */
-#define INT_GPIOINT1 7 /* GPIO 1 */
-#define INT_GPIOINT2 8 /* GPIO 2 */
-#define INT_GPIOINT3 9 /* GPIO 3 */
-#define INT_RTCINT 10 /* Real Time Clock */
-#define INT_SSPINT 11 /* Synchronous Serial Port */
-#define INT_UARTINT0 12 /* UART 0 on development chip */
-#define INT_UARTINT1 13 /* UART 1 on development chip */
-#define INT_UARTINT2 14 /* UART 2 on development chip */
-#define INT_SCIINT 15 /* Smart Card Interface */
-#define INT_CLCDINT 16 /* CLCD controller */
-#define INT_DMAINT 17 /* DMA controller */
-#define INT_PWRFAILINT 18 /* Power failure */
-#define INT_MBXINT 19 /* Graphics processor */
-#define INT_GNDINT 20 /* Reserved */
- /* External interrupt signals from logic tiles or secondary controller */
-#define INT_VICSOURCE21 21 /* Disk on Chip */
-#define INT_VICSOURCE22 22 /* MCI0A */
-#define INT_VICSOURCE23 23 /* MCI1A */
-#define INT_VICSOURCE24 24 /* AACI */
-#define INT_VICSOURCE25 25 /* Ethernet */
-#define INT_VICSOURCE26 26 /* USB */
-#define INT_VICSOURCE27 27 /* PCI 0 */
-#define INT_VICSOURCE28 28 /* PCI 1 */
-#define INT_VICSOURCE29 29 /* PCI 2 */
-#define INT_VICSOURCE30 30 /* PCI 3 */
-#define INT_VICSOURCE31 31 /* SIC source */
-
-#define VERSATILE_SC_VALID_INT 0x003FFFFF
-
-#define MAXIRQNUM 31
-#define MAXFIQNUM 31
-#define MAXSWINUM 31
-
-/* ------------------------------------------------------------------------
- * Interrupts - bit assignment (secondary)
- * ------------------------------------------------------------------------
- */
-#define SIC_INT_MMCI0B 1 /* Multimedia Card 0B */
-#define SIC_INT_MMCI1B 2 /* Multimedia Card 1B */
-#define SIC_INT_KMI0 3 /* Keyboard/Mouse port 0 */
-#define SIC_INT_KMI1 4 /* Keyboard/Mouse port 1 */
-#define SIC_INT_SCI3 5 /* Smart Card interface */
-#define SIC_INT_UART3 6 /* UART 3 empty or data available */
-#define SIC_INT_CLCD 7 /* Character LCD */
-#define SIC_INT_TOUCH 8 /* Touchscreen */
-#define SIC_INT_KEYPAD 9 /* Key pressed on display keypad */
- /* 10:20 - reserved */
-#define SIC_INT_DoC 21 /* Disk on Chip memory controller */
-#define SIC_INT_MMCI0A 22 /* MMC 0A */
-#define SIC_INT_MMCI1A 23 /* MMC 1A */
-#define SIC_INT_AACI 24 /* Audio Codec */
-#define SIC_INT_ETH 25 /* Ethernet controller */
-#define SIC_INT_USB 26 /* USB controller */
-#define SIC_INT_PCI0 27
-#define SIC_INT_PCI1 28
-#define SIC_INT_PCI2 29
-#define SIC_INT_PCI3 30
-
-
/*
* System controller bit assignment
*/
@@ -393,16 +227,9 @@
#define VERSATILE_TIMER4_EnSel 21
-#define VERSATILE_CSR_BASE 0x10000000
-#define VERSATILE_CSR_SIZE 0x10000000
-
-#ifdef CONFIG_MACH_VERSATILE_AB
/*
* IB2 Versatile/AB expansion board definitions
*/
-#define VERSATILE_IB2_CAMERA_BANK VERSATILE_IB2_BASE
-#define VERSATILE_IB2_KBD_DATAREG (VERSATILE_IB2_BASE + 0x01000000)
-
/* VICINTSOURCE27 */
#define VERSATILE_IB2_INT_BASE (VERSATILE_IB2_BASE + 0x02000000)
#define VERSATILE_IB2_IER (VERSATILE_IB2_INT_BASE + 0)
@@ -411,6 +238,5 @@
#define VERSATILE_IB2_CTL_BASE (VERSATILE_IB2_BASE + 0x03000000)
#define VERSATILE_IB2_CTRL (VERSATILE_IB2_CTL_BASE + 0)
#define VERSATILE_IB2_STAT (VERSATILE_IB2_CTL_BASE + 4)
-#endif
#endif
diff --git a/arch/arm/mach-versatile/pci.c b/arch/arm/mach-versatile/pci.c
deleted file mode 100644
index c97be4e..0000000
--- a/arch/arm/mach-versatile/pci.c
+++ /dev/null
@@ -1,368 +0,0 @@
-/*
- * linux/arch/arm/mach-versatile/pci.c
- *
- * (C) Copyright Koninklijke Philips Electronics NV 2004. All rights reserved.
- * You can redistribute and/or modify this software under the terms of version 2
- * of the GNU General Public License as published by the Free Software Foundation.
- * THIS SOFTWARE IS PROVIDED "AS IS" WITHOUT ANY WARRANTY; WITHOUT EVEN THE IMPLIED
- * WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * General Public License for more details.
- * Koninklijke Philips Electronics nor its subsidiaries is obligated to provide any support for this software.
- *
- * ARM Versatile PCI driver.
- *
- * 14/04/2005 Initial version, colin.king-//tT4aWmXyZBDgjK7y7TUQ@public.gmane.org
- *
- */
-#include <linux/kernel.h>
-#include <linux/pci.h>
-#include <linux/ioport.h>
-#include <linux/interrupt.h>
-#include <linux/spinlock.h>
-#include <linux/init.h>
-#include <linux/io.h>
-
-#include <mach/hardware.h>
-#include <mach/irqs.h>
-#include <asm/irq.h>
-#include <asm/mach/pci.h>
-
-/*
- * these spaces are mapped using the following base registers:
- *
- * Usage Local Bus Memory Base/Map registers used
- *
- * Mem 50000000 - 5FFFFFFF LB_BASE0/LB_MAP0, non prefetch
- * Mem 60000000 - 6FFFFFFF LB_BASE1/LB_MAP1, prefetch
- * IO 44000000 - 4FFFFFFF LB_BASE2/LB_MAP2, IO
- * Cfg 42000000 - 42FFFFFF PCI config
- *
- */
-#define __IO_ADDRESS(n) ((void __iomem *)(unsigned long)IO_ADDRESS(n))
-#define SYS_PCICTL __IO_ADDRESS(VERSATILE_SYS_PCICTL)
-#define PCI_IMAP0 __IO_ADDRESS(VERSATILE_PCI_CORE_BASE+0x0)
-#define PCI_IMAP1 __IO_ADDRESS(VERSATILE_PCI_CORE_BASE+0x4)
-#define PCI_IMAP2 __IO_ADDRESS(VERSATILE_PCI_CORE_BASE+0x8)
-#define PCI_SMAP0 __IO_ADDRESS(VERSATILE_PCI_CORE_BASE+0x14)
-#define PCI_SMAP1 __IO_ADDRESS(VERSATILE_PCI_CORE_BASE+0x18)
-#define PCI_SMAP2 __IO_ADDRESS(VERSATILE_PCI_CORE_BASE+0x1c)
-#define PCI_SELFID __IO_ADDRESS(VERSATILE_PCI_CORE_BASE+0xc)
-
-#define DEVICE_ID_OFFSET 0x00
-#define CSR_OFFSET 0x04
-#define CLASS_ID_OFFSET 0x08
-
-#define VP_PCI_DEVICE_ID 0x030010ee
-#define VP_PCI_CLASS_ID 0x0b400000
-
-static unsigned long pci_slot_ignore = 0;
-
-static int __init versatile_pci_slot_ignore(char *str)
-{
- int retval;
- int slot;
-
- while ((retval = get_option(&str,&slot))) {
- if ((slot < 0) || (slot > 31)) {
- printk("Illegal slot value: %d\n",slot);
- } else {
- pci_slot_ignore |= (1 << slot);
- }
- }
- return 1;
-}
-
-__setup("pci_slot_ignore=", versatile_pci_slot_ignore);
-
-
-static void __iomem *__pci_addr(struct pci_bus *bus,
- unsigned int devfn, int offset)
-{
- unsigned int busnr = bus->number;
-
- /*
- * Trap out illegal values
- */
- if (offset > 255)
- BUG();
- if (busnr > 255)
- BUG();
- if (devfn > 255)
- BUG();
-
- return VERSATILE_PCI_CFG_VIRT_BASE + ((busnr << 16) |
- (PCI_SLOT(devfn) << 11) | (PCI_FUNC(devfn) << 8) | offset);
-}
-
-static int versatile_read_config(struct pci_bus *bus, unsigned int devfn, int where,
- int size, u32 *val)
-{
- void __iomem *addr = __pci_addr(bus, devfn, where & ~3);
- u32 v;
- int slot = PCI_SLOT(devfn);
-
- if (pci_slot_ignore & (1 << slot)) {
- /* Ignore this slot */
- switch (size) {
- case 1:
- v = 0xff;
- break;
- case 2:
- v = 0xffff;
- break;
- default:
- v = 0xffffffff;
- }
- } else {
- switch (size) {
- case 1:
- v = __raw_readl(addr);
- if (where & 2) v >>= 16;
- if (where & 1) v >>= 8;
- v &= 0xff;
- break;
-
- case 2:
- v = __raw_readl(addr);
- if (where & 2) v >>= 16;
- v &= 0xffff;
- break;
-
- default:
- v = __raw_readl(addr);
- break;
- }
- }
-
- *val = v;
- return PCIBIOS_SUCCESSFUL;
-}
-
-static int versatile_write_config(struct pci_bus *bus, unsigned int devfn, int where,
- int size, u32 val)
-{
- void __iomem *addr = __pci_addr(bus, devfn, where);
- int slot = PCI_SLOT(devfn);
-
- if (pci_slot_ignore & (1 << slot)) {
- return PCIBIOS_SUCCESSFUL;
- }
-
- switch (size) {
- case 1:
- __raw_writeb((u8)val, addr);
- break;
-
- case 2:
- __raw_writew((u16)val, addr);
- break;
-
- case 4:
- __raw_writel(val, addr);
- break;
- }
-
- return PCIBIOS_SUCCESSFUL;
-}
-
-static struct pci_ops pci_versatile_ops = {
- .read = versatile_read_config,
- .write = versatile_write_config,
-};
-
-static struct resource unused_mem = {
- .name = "PCI unused",
- .start = VERSATILE_PCI_MEM_BASE0,
- .end = VERSATILE_PCI_MEM_BASE0+VERSATILE_PCI_MEM_BASE0_SIZE-1,
- .flags = IORESOURCE_MEM,
-};
-
-static struct resource non_mem = {
- .name = "PCI non-prefetchable",
- .start = VERSATILE_PCI_MEM_BASE1,
- .end = VERSATILE_PCI_MEM_BASE1+VERSATILE_PCI_MEM_BASE1_SIZE-1,
- .flags = IORESOURCE_MEM,
-};
-
-static struct resource pre_mem = {
- .name = "PCI prefetchable",
- .start = VERSATILE_PCI_MEM_BASE2,
- .end = VERSATILE_PCI_MEM_BASE2+VERSATILE_PCI_MEM_BASE2_SIZE-1,
- .flags = IORESOURCE_MEM | IORESOURCE_PREFETCH,
-};
-
-static int __init pci_versatile_setup_resources(struct pci_sys_data *sys)
-{
- int ret = 0;
-
- ret = request_resource(&iomem_resource, &unused_mem);
- if (ret) {
- printk(KERN_ERR "PCI: unable to allocate unused "
- "memory region (%d)\n", ret);
- goto out;
- }
- ret = request_resource(&iomem_resource, &non_mem);
- if (ret) {
- printk(KERN_ERR "PCI: unable to allocate non-prefetchable "
- "memory region (%d)\n", ret);
- goto release_unused_mem;
- }
- ret = request_resource(&iomem_resource, &pre_mem);
- if (ret) {
- printk(KERN_ERR "PCI: unable to allocate prefetchable "
- "memory region (%d)\n", ret);
- goto release_non_mem;
- }
-
- /*
- * the mem resource for this bus
- * the prefetch mem resource for this bus
- */
- pci_add_resource_offset(&sys->resources, &non_mem, sys->mem_offset);
- pci_add_resource_offset(&sys->resources, &pre_mem, sys->mem_offset);
-
- goto out;
-
- release_non_mem:
- release_resource(&non_mem);
- release_unused_mem:
- release_resource(&unused_mem);
- out:
- return ret;
-}
-
-int __init pci_versatile_setup(int nr, struct pci_sys_data *sys)
-{
- int ret = 0;
- int i;
- int myslot = -1;
- unsigned long val;
- void __iomem *local_pci_cfg_base;
-
- val = __raw_readl(SYS_PCICTL);
- if (!(val & 1)) {
- printk("Not plugged into PCI backplane!\n");
- ret = -EIO;
- goto out;
- }
-
- ret = pci_ioremap_io(0, VERSATILE_PCI_IO_BASE);
- if (ret)
- goto out;
-
- if (nr == 0) {
- ret = pci_versatile_setup_resources(sys);
- if (ret < 0) {
- printk("pci_versatile_setup: resources... oops?\n");
- goto out;
- }
- } else {
- printk("pci_versatile_setup: resources... nr == 0??\n");
- goto out;
- }
-
- /*
- * We need to discover the PCI core first to configure itself
- * before the main PCI probing is performed
- */
- for (i=0; i<32; i++)
- if ((__raw_readl(VERSATILE_PCI_VIRT_BASE+(i<<11)+DEVICE_ID_OFFSET) == VP_PCI_DEVICE_ID) &&
- (__raw_readl(VERSATILE_PCI_VIRT_BASE+(i<<11)+CLASS_ID_OFFSET) == VP_PCI_CLASS_ID)) {
- myslot = i;
- break;
- }
-
- if (myslot == -1) {
- printk("Cannot find PCI core!\n");
- ret = -EIO;
- goto out;
- }
-
- printk("PCI core found (slot %d)\n",myslot);
-
- __raw_writel(myslot, PCI_SELFID);
- local_pci_cfg_base = VERSATILE_PCI_CFG_VIRT_BASE + (myslot << 11);
-
- val = __raw_readl(local_pci_cfg_base + CSR_OFFSET);
- val |= PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER | PCI_COMMAND_INVALIDATE;
- __raw_writel(val, local_pci_cfg_base + CSR_OFFSET);
-
- /*
- * Configure the PCI inbound memory windows to be 1:1 mapped to SDRAM
- */
- __raw_writel(PHYS_OFFSET, local_pci_cfg_base + PCI_BASE_ADDRESS_0);
- __raw_writel(PHYS_OFFSET, local_pci_cfg_base + PCI_BASE_ADDRESS_1);
- __raw_writel(PHYS_OFFSET, local_pci_cfg_base + PCI_BASE_ADDRESS_2);
-
- /*
- * For many years the kernel and QEMU were symbiotically buggy
- * in that they both assumed the same broken IRQ mapping.
- * QEMU therefore attempts to auto-detect old broken kernels
- * so that they still work on newer QEMU as they did on old
- * QEMU. Since we now use the correct (ie matching-hardware)
- * IRQ mapping we write a definitely different value to a
- * PCI_INTERRUPT_LINE register to tell QEMU that we expect
- * real hardware behaviour and it need not be backwards
- * compatible for us. This write is harmless on real hardware.
- */
- __raw_writel(0, VERSATILE_PCI_VIRT_BASE+PCI_INTERRUPT_LINE);
-
- /*
- * Do not to map Versatile FPGA PCI device into memory space
- */
- pci_slot_ignore |= (1 << myslot);
- ret = 1;
-
- out:
- return ret;
-}
-
-
-void __init pci_versatile_preinit(void)
-{
- pcibios_min_mem = 0x50000000;
-
- __raw_writel(VERSATILE_PCI_MEM_BASE0 >> 28, PCI_IMAP0);
- __raw_writel(VERSATILE_PCI_MEM_BASE1 >> 28, PCI_IMAP1);
- __raw_writel(VERSATILE_PCI_MEM_BASE2 >> 28, PCI_IMAP2);
-
- __raw_writel(PHYS_OFFSET >> 28, PCI_SMAP0);
- __raw_writel(PHYS_OFFSET >> 28, PCI_SMAP1);
- __raw_writel(PHYS_OFFSET >> 28, PCI_SMAP2);
-
- __raw_writel(1, SYS_PCICTL);
-}
-
-/*
- * map the specified device/slot/pin to an IRQ. Different backplanes may need to modify this.
- */
-static int __init versatile_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
-{
- int irq;
-
- /*
- * Slot INTA INTB INTC INTD
- * 31 PCI1 PCI2 PCI3 PCI0
- * 30 PCI0 PCI1 PCI2 PCI3
- * 29 PCI3 PCI0 PCI1 PCI2
- */
- irq = IRQ_SIC_PCI0 + ((slot + 2 + pin - 1) & 3);
-
- return irq;
-}
-
-static struct hw_pci versatile_pci __initdata = {
- .map_irq = versatile_map_irq,
- .nr_controllers = 1,
- .ops = &pci_versatile_ops,
- .setup = pci_versatile_setup,
- .preinit = pci_versatile_preinit,
-};
-
-static int __init versatile_pci_init(void)
-{
- pci_common_init(&versatile_pci);
- return 0;
-}
-
-subsys_initcall(versatile_pci_init);
diff --git a/arch/arm/mach-versatile/versatile_ab.c b/arch/arm/mach-versatile/versatile_ab.c
deleted file mode 100644
index 1caef10..0000000
--- a/arch/arm/mach-versatile/versatile_ab.c
+++ /dev/null
@@ -1,44 +0,0 @@
-/*
- * linux/arch/arm/mach-versatile/versatile_ab.c
- *
- * Copyright (C) 2004 ARM Limited
- * Copyright (C) 2000 Deep Blue Solutions Ltd
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
- */
-
-#include <linux/init.h>
-#include <linux/device.h>
-#include <linux/amba/bus.h>
-#include <linux/io.h>
-
-#include <mach/hardware.h>
-#include <asm/irq.h>
-#include <asm/mach-types.h>
-
-#include <asm/mach/arch.h>
-
-#include "core.h"
-
-MACHINE_START(VERSATILE_AB, "ARM-Versatile AB")
- /* Maintainer: ARM Ltd/Deep Blue Solutions Ltd */
- .atag_offset = 0x100,
- .map_io = versatile_map_io,
- .init_early = versatile_init_early,
- .init_irq = versatile_init_irq,
- .init_time = versatile_timer_init,
- .init_machine = versatile_init,
- .restart = versatile_restart,
-MACHINE_END
diff --git a/arch/arm/mach-versatile/versatile_dt.c b/arch/arm/mach-versatile/versatile_dt.c
index 5053810..1bb21d1 100644
--- a/arch/arm/mach-versatile/versatile_dt.c
+++ b/arch/arm/mach-versatile/versatile_dt.c
@@ -77,6 +77,7 @@ static void __init versatile_dt_init(void)
{
versatile_dt_pci_init();
+ platform_device_register(&versatile_flash_device);
of_platform_populate(NULL, of_default_bus_match_table,
versatile_auxdata_lookup, NULL);
}
diff --git a/arch/arm/mach-versatile/versatile_pb.c b/arch/arm/mach-versatile/versatile_pb.c
deleted file mode 100644
index 9a53d0b..0000000
--- a/arch/arm/mach-versatile/versatile_pb.c
+++ /dev/null
@@ -1,91 +0,0 @@
-/*
- * linux/arch/arm/mach-versatile/versatile_pb.c
- *
- * Copyright (C) 2004 ARM Limited
- * Copyright (C) 2000 Deep Blue Solutions Ltd
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
- */
-
-#include <linux/init.h>
-#include <linux/device.h>
-#include <linux/amba/bus.h>
-#include <linux/amba/pl061.h>
-#include <linux/amba/mmci.h>
-#include <linux/io.h>
-
-#include <mach/hardware.h>
-#include <asm/irq.h>
-#include <asm/mach-types.h>
-
-#include <asm/mach/arch.h>
-
-#include "core.h"
-
-#if 1
-#define IRQ_MMCI1A IRQ_VICSOURCE23
-#else
-#define IRQ_MMCI1A IRQ_SIC_MMCI1A
-#endif
-
-static struct mmci_platform_data mmc1_plat_data = {
- .ocr_mask = MMC_VDD_32_33|MMC_VDD_33_34,
- .status = mmc_status,
- .gpio_wp = -1,
- .gpio_cd = -1,
-};
-
-#define UART3_IRQ { IRQ_SIC_UART3 }
-#define SCI1_IRQ { IRQ_SIC_SCI3 }
-#define MMCI1_IRQ { IRQ_MMCI1A, IRQ_SIC_MMCI1B }
-
-/*
- * These devices are connected via the DMA APB bridge
- */
-
-/* FPGA Primecells */
-APB_DEVICE(uart3, "fpga:09", UART3, NULL);
-APB_DEVICE(sci1, "fpga:0a", SCI1, NULL);
-APB_DEVICE(mmc1, "fpga:0b", MMCI1, &mmc1_plat_data);
-
-
-static struct amba_device *amba_devs[] __initdata = {
- &uart3_device,
- &sci1_device,
- &mmc1_device,
-};
-
-static void __init versatile_pb_init(void)
-{
- int i;
-
- versatile_init();
-
- for (i = 0; i < ARRAY_SIZE(amba_devs); i++) {
- struct amba_device *d = amba_devs[i];
- amba_device_register(d, &iomem_resource);
- }
-}
-
-MACHINE_START(VERSATILE_PB, "ARM-Versatile PB")
- /* Maintainer: ARM Ltd/Deep Blue Solutions Ltd */
- .atag_offset = 0x100,
- .map_io = versatile_map_io,
- .init_early = versatile_init_early,
- .init_irq = versatile_init_irq,
- .init_time = versatile_timer_init,
- .init_machine = versatile_pb_init,
- .restart = versatile_restart,
-MACHINE_END
diff --git a/drivers/clk/versatile/Kconfig b/drivers/clk/versatile/Kconfig
index 1530c93..ec1923a 100644
--- a/drivers/clk/versatile/Kconfig
+++ b/drivers/clk/versatile/Kconfig
@@ -1,6 +1,7 @@
config COMMON_CLK_VERSATILE
bool "Clock driver for ARM Reference designs"
- depends on ARCH_INTEGRATOR || ARCH_REALVIEW || ARCH_VEXPRESS || ARM64
+ depends on ARCH_INTEGRATOR || ARCH_REALVIEW || \
+ ARCH_VERSATILE || ARCH_VEXPRESS || ARM64
---help---
Supports clocking on ARM Reference designs:
- Integrator/AP and Integrator/CP
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 86+ messages in thread
* [PATCH 6/9] ARM: versatile: switch to DT only booting and remove legacy code
@ 2014-12-30 19:28 ` Rob Herring
0 siblings, 0 replies; 86+ messages in thread
From: Rob Herring @ 2014-12-30 19:28 UTC (permalink / raw)
To: linux-arm-kernel
From: Rob Herring <robh@kernel.org>
With DT support for clocks, irqchips, timers, and PCI now in place, DT
based booting has feature parity with non-DT legacy boot. The final
piece is actually enabling common clock support on Versatile. Enabling
full DT support requires either removing the old Versatile clock code,
updating the legacy boot to use the common clock code, or making DT and
legacy boot mutually exclusive. Given that removing legacy boot code is
the goal anyway, I am going with the 1st option.
Tested on QEMU. Earlier versions of this patch have been tested on h/w
by Linus Walleij.
Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Mike Turquette <mturquette@linaro.org>
---
arch/arm/Kconfig | 14 +-
arch/arm/mach-versatile/Kconfig | 33 --
arch/arm/mach-versatile/Makefile | 6 +-
arch/arm/mach-versatile/core.c | 540 +-----------------------
arch/arm/mach-versatile/core.h | 9 +-
arch/arm/mach-versatile/include/mach/clkdev.h | 16 -
arch/arm/mach-versatile/include/mach/hardware.h | 6 -
arch/arm/mach-versatile/include/mach/irqs.h | 134 ------
arch/arm/mach-versatile/include/mach/platform.h | 174 --------
arch/arm/mach-versatile/pci.c | 368 ----------------
arch/arm/mach-versatile/versatile_ab.c | 44 --
arch/arm/mach-versatile/versatile_dt.c | 1 +
arch/arm/mach-versatile/versatile_pb.c | 91 ----
drivers/clk/versatile/Kconfig | 3 +-
14 files changed, 23 insertions(+), 1416 deletions(-)
delete mode 100644 arch/arm/mach-versatile/Kconfig
delete mode 100644 arch/arm/mach-versatile/include/mach/clkdev.h
delete mode 100644 arch/arm/mach-versatile/include/mach/irqs.h
delete mode 100644 arch/arm/mach-versatile/pci.c
delete mode 100644 arch/arm/mach-versatile/versatile_ab.c
delete mode 100644 arch/arm/mach-versatile/versatile_pb.c
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 97d07ed..7816b54 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -343,13 +343,15 @@ config ARCH_VERSATILE
select ARM_AMBA
select ARM_TIMER_SP804
select ARM_VIC
- select CLKDEV_LOOKUP
+ select CLKSRC_VERSATILE
+ select COMMON_CLK
+ select COMMON_CLK_VERSATILE
+ select CPU_ARM926T
select GENERIC_CLOCKEVENTS
- select HAVE_MACH_CLKDEV
select ICST
- select PLAT_VERSATILE
- select PLAT_VERSATILE_CLOCK
- select PLAT_VERSATILE_SCHED_CLOCK
+ select MIGHT_HAVE_PCI
+ select SPARSE_IRQ
+ select USE_OF
select VERSATILE_FPGA_IRQ
help
This enables support for ARM Ltd Versatile board.
@@ -954,8 +956,6 @@ source "arch/arm/mach-u300/Kconfig"
source "arch/arm/mach-ux500/Kconfig"
-source "arch/arm/mach-versatile/Kconfig"
-
source "arch/arm/mach-vexpress/Kconfig"
source "arch/arm/plat-versatile/Kconfig"
diff --git a/arch/arm/mach-versatile/Kconfig b/arch/arm/mach-versatile/Kconfig
deleted file mode 100644
index 1dba368..0000000
--- a/arch/arm/mach-versatile/Kconfig
+++ /dev/null
@@ -1,33 +0,0 @@
-menu "Versatile platform type"
- depends on ARCH_VERSATILE
-
-config ARCH_VERSATILE_PB
- bool "Support Versatile Platform Baseboard for ARM926EJ-S"
- default y
- select CPU_ARM926T
- select MIGHT_HAVE_PCI
- help
- Include support for the ARM(R) Versatile Platform Baseboard
- for the ARM926EJ-S.
-
-config MACH_VERSATILE_AB
- bool "Support Versatile Application Baseboard for ARM926EJ-S"
- select CPU_ARM926T
- help
- Include support for the ARM(R) Versatile Application Baseboard
- for the ARM926EJ-S.
-
-config MACH_VERSATILE_DT
- bool "Support Versatile platform from device tree"
- select CPU_ARM926T
- select USE_OF
- help
- Include support for the ARM(R) Versatile/PB platform,
- using the device tree for discovery
-
-config MACH_VERSATILE_AUTO
- def_bool y
- depends on !ARCH_VERSATILE_PB && !MACH_VERSATILE_AB
- select MACH_VERSATILE_DT
-
-endmenu
diff --git a/arch/arm/mach-versatile/Makefile b/arch/arm/mach-versatile/Makefile
index 81fa3fe..ccef512 100644
--- a/arch/arm/mach-versatile/Makefile
+++ b/arch/arm/mach-versatile/Makefile
@@ -2,8 +2,4 @@
# Makefile for the linux kernel.
#
-obj-y := core.o
-obj-$(CONFIG_ARCH_VERSATILE_PB) += versatile_pb.o
-obj-$(CONFIG_MACH_VERSATILE_AB) += versatile_ab.o
-obj-$(CONFIG_MACH_VERSATILE_DT) += versatile_dt.o
-obj-$(CONFIG_PCI) += pci.o
+obj-y := core.o versatile_dt.o
diff --git a/arch/arm/mach-versatile/core.c b/arch/arm/mach-versatile/core.c
index 08fb8c8..566a946 100644
--- a/arch/arm/mach-versatile/core.c
+++ b/arch/arm/mach-versatile/core.c
@@ -23,111 +23,22 @@
#include <linux/dma-mapping.h>
#include <linux/platform_device.h>
#include <linux/interrupt.h>
-#include <linux/irqdomain.h>
-#include <linux/of_address.h>
#include <linux/of_platform.h>
#include <linux/amba/bus.h>
#include <linux/amba/clcd.h>
#include <linux/platform_data/video-clcd-versatile.h>
-#include <linux/amba/pl061.h>
#include <linux/amba/mmci.h>
-#include <linux/amba/pl022.h>
#include <linux/io.h>
-#include <linux/irqchip/arm-vic.h>
-#include <linux/irqchip/versatile-fpga.h>
-#include <linux/gfp.h>
-#include <linux/clkdev.h>
#include <linux/mtd/physmap.h>
-#include <linux/bitops.h>
#include <linux/reboot.h>
-#include <asm/irq.h>
-#include <asm/hardware/arm_timer.h>
-#include <asm/hardware/icst.h>
-#include <asm/mach-types.h>
-
#include <asm/mach/arch.h>
-#include <asm/mach/irq.h>
-#include <asm/mach/time.h>
#include <asm/mach/map.h>
#include <mach/hardware.h>
#include <mach/platform.h>
-#include <asm/hardware/timer-sp.h>
-
-#include <plat/sched_clock.h>
#include "core.h"
-/*
- * All IO addresses are mapped onto VA 0xFFFx.xxxx, where x.xxxx
- * is the (PA >> 12).
- *
- * Setup a VA for the Versatile Vectored Interrupt Controller.
- */
-#define VA_VIC_BASE __io_address(VERSATILE_VIC_BASE)
-#define VA_SIC_BASE __io_address(VERSATILE_SIC_BASE)
-
-/* These PIC IRQs are valid in each configuration */
-#define PIC_VALID_ALL BIT(SIC_INT_KMI0) | BIT(SIC_INT_KMI1) | \
- BIT(SIC_INT_SCI3) | BIT(SIC_INT_UART3) | \
- BIT(SIC_INT_CLCD) | BIT(SIC_INT_TOUCH) | \
- BIT(SIC_INT_KEYPAD) | BIT(SIC_INT_DoC) | \
- BIT(SIC_INT_USB) | BIT(SIC_INT_PCI0) | \
- BIT(SIC_INT_PCI1) | BIT(SIC_INT_PCI2) | \
- BIT(SIC_INT_PCI3)
-#if 1
-#define IRQ_MMCI0A IRQ_VICSOURCE22
-#define IRQ_AACI IRQ_VICSOURCE24
-#define IRQ_ETH IRQ_VICSOURCE25
-#define PIC_MASK 0xFFD00000
-#define PIC_VALID PIC_VALID_ALL
-#else
-#define IRQ_MMCI0A IRQ_SIC_MMCI0A
-#define IRQ_AACI IRQ_SIC_AACI
-#define IRQ_ETH IRQ_SIC_ETH
-#define PIC_MASK 0
-#define PIC_VALID PIC_VALID_ALL | BIT(SIC_INT_MMCI0A) | \
- BIT(SIC_INT_MMCI1A) | BIT(SIC_INT_AACI) | \
- BIT(SIC_INT_ETH)
-#endif
-
-/* Lookup table for finding a DT node that represents the vic instance */
-static const struct of_device_id vic_of_match[] __initconst = {
- { .compatible = "arm,versatile-vic", },
- {}
-};
-
-static const struct of_device_id sic_of_match[] __initconst = {
- { .compatible = "arm,versatile-sic", },
- {}
-};
-
-void __init versatile_init_irq(void)
-{
- struct device_node *np;
-
- np = of_find_matching_node_by_address(NULL, vic_of_match,
- VERSATILE_VIC_BASE);
- __vic_init(VA_VIC_BASE, 0, IRQ_VIC_START, ~0, 0, np);
-
- writel(~0, VA_SIC_BASE + SIC_IRQ_ENABLE_CLEAR);
-
- np = of_find_matching_node_by_address(NULL, sic_of_match,
- VERSATILE_SIC_BASE);
-
- fpga_irq_init(VA_SIC_BASE, "SIC", IRQ_SIC_START,
- IRQ_VICSOURCE31, PIC_VALID, np);
-
- /*
- * Interrupts on secondary controller from 0 to 8 are routed to
- * source 31 on PIC.
- * Interrupts from 21 to 31 are routed directly to the VIC on
- * the corresponding number on primary controller. This is controlled
- * by setting PIC_ENABLEx.
- */
- writel(PIC_MASK, VA_SIC_BASE + SIC_INT_PIC_ENABLE);
-}
-
static struct map_desc versatile_io_desc[] __initdata __maybe_unused = {
{
.virtual = IO_ADDRESS(VERSATILE_SYS_BASE),
@@ -135,59 +46,16 @@ static struct map_desc versatile_io_desc[] __initdata __maybe_unused = {
.length = SZ_4K,
.type = MT_DEVICE
}, {
- .virtual = IO_ADDRESS(VERSATILE_SIC_BASE),
- .pfn = __phys_to_pfn(VERSATILE_SIC_BASE),
- .length = SZ_4K,
- .type = MT_DEVICE
- }, {
- .virtual = IO_ADDRESS(VERSATILE_VIC_BASE),
- .pfn = __phys_to_pfn(VERSATILE_VIC_BASE),
- .length = SZ_4K,
- .type = MT_DEVICE
- }, {
.virtual = IO_ADDRESS(VERSATILE_SCTL_BASE),
.pfn = __phys_to_pfn(VERSATILE_SCTL_BASE),
.length = SZ_4K * 9,
.type = MT_DEVICE
},
-#ifdef CONFIG_MACH_VERSATILE_AB
- {
- .virtual = IO_ADDRESS(VERSATILE_IB2_BASE),
- .pfn = __phys_to_pfn(VERSATILE_IB2_BASE),
- .length = SZ_64M,
- .type = MT_DEVICE
- },
-#endif
-#ifdef CONFIG_DEBUG_LL
- {
- .virtual = IO_ADDRESS(VERSATILE_UART0_BASE),
- .pfn = __phys_to_pfn(VERSATILE_UART0_BASE),
- .length = SZ_4K,
- .type = MT_DEVICE
- },
-#endif
-#ifdef CONFIG_PCI
- {
- .virtual = IO_ADDRESS(VERSATILE_PCI_CORE_BASE),
- .pfn = __phys_to_pfn(VERSATILE_PCI_CORE_BASE),
- .length = SZ_4K,
- .type = MT_DEVICE
- }, {
- .virtual = (unsigned long)VERSATILE_PCI_VIRT_BASE,
- .pfn = __phys_to_pfn(VERSATILE_PCI_BASE),
- .length = VERSATILE_PCI_BASE_SIZE,
- .type = MT_DEVICE
- }, {
- .virtual = (unsigned long)VERSATILE_PCI_CFG_VIRT_BASE,
- .pfn = __phys_to_pfn(VERSATILE_PCI_CFG_BASE),
- .length = VERSATILE_PCI_CFG_BASE_SIZE,
- .type = MT_DEVICE
- },
-#endif
};
void __init versatile_map_io(void)
{
+ debug_ll_io_init();
iotable_init(versatile_io_desc, ARRAY_SIZE(versatile_io_desc));
}
@@ -217,7 +85,7 @@ static struct resource versatile_flash_resource = {
.flags = IORESOURCE_MEM,
};
-static struct platform_device versatile_flash_device = {
+struct platform_device versatile_flash_device = {
.name = "physmap-flash",
.id = 0,
.dev = {
@@ -227,52 +95,6 @@ static struct platform_device versatile_flash_device = {
.resource = &versatile_flash_resource,
};
-static struct resource smc91x_resources[] = {
- [0] = {
- .start = VERSATILE_ETH_BASE,
- .end = VERSATILE_ETH_BASE + SZ_64K - 1,
- .flags = IORESOURCE_MEM,
- },
- [1] = {
- .start = IRQ_ETH,
- .end = IRQ_ETH,
- .flags = IORESOURCE_IRQ,
- },
-};
-
-static struct platform_device smc91x_device = {
- .name = "smc91x",
- .id = 0,
- .num_resources = ARRAY_SIZE(smc91x_resources),
- .resource = smc91x_resources,
-};
-
-static struct resource versatile_i2c_resource = {
- .start = VERSATILE_I2C_BASE,
- .end = VERSATILE_I2C_BASE + SZ_4K - 1,
- .flags = IORESOURCE_MEM,
-};
-
-static struct platform_device versatile_i2c_device = {
- .name = "versatile-i2c",
- .id = 0,
- .num_resources = 1,
- .resource = &versatile_i2c_resource,
-};
-
-static struct i2c_board_info versatile_i2c_board_info[] = {
- {
- I2C_BOARD_INFO("ds1338", 0xd0 >> 1),
- },
-};
-
-static int __init versatile_i2c_init(void)
-{
- return i2c_register_board_info(0, versatile_i2c_board_info,
- ARRAY_SIZE(versatile_i2c_board_info));
-}
-arch_initcall(versatile_i2c_init);
-
#define VERSATILE_SYSMCI (__io_address(VERSATILE_SYS_BASE) + VERSATILE_SYS_MCI_OFFSET)
unsigned int mmc_status(struct device *dev)
@@ -295,126 +117,11 @@ static struct mmci_platform_data mmc0_plat_data = {
.gpio_cd = -1,
};
-static struct resource char_lcd_resources[] = {
- {
- .start = VERSATILE_CHAR_LCD_BASE,
- .end = (VERSATILE_CHAR_LCD_BASE + SZ_4K - 1),
- .flags = IORESOURCE_MEM,
- },
-};
-
-static struct platform_device char_lcd_device = {
- .name = "arm-charlcd",
- .id = -1,
- .num_resources = ARRAY_SIZE(char_lcd_resources),
- .resource = char_lcd_resources,
-};
-
-static struct resource leds_resources[] = {
- {
- .start = VERSATILE_SYS_BASE + VERSATILE_SYS_LED_OFFSET,
- .end = VERSATILE_SYS_BASE + VERSATILE_SYS_LED_OFFSET + 4,
- .flags = IORESOURCE_MEM,
- },
-};
-
-static struct platform_device leds_device = {
- .name = "versatile-leds",
- .id = -1,
- .num_resources = ARRAY_SIZE(leds_resources),
- .resource = leds_resources,
-};
-
-/*
- * Clock handling
- */
-static const struct icst_params versatile_oscvco_params = {
- .ref = 24000000,
- .vco_max = ICST307_VCO_MAX,
- .vco_min = ICST307_VCO_MIN,
- .vd_min = 4 + 8,
- .vd_max = 511 + 8,
- .rd_min = 1 + 2,
- .rd_max = 127 + 2,
- .s2div = icst307_s2div,
- .idx2s = icst307_idx2s,
-};
-
-static void versatile_oscvco_set(struct clk *clk, struct icst_vco vco)
-{
- void __iomem *sys_lock = __io_address(VERSATILE_SYS_BASE) + VERSATILE_SYS_LOCK_OFFSET;
- u32 val;
-
- val = readl(clk->vcoreg) & ~0x7ffff;
- val |= vco.v | (vco.r << 9) | (vco.s << 16);
-
- writel(0xa05f, sys_lock);
- writel(val, clk->vcoreg);
- writel(0, sys_lock);
-}
-
-static const struct clk_ops osc4_clk_ops = {
- .round = icst_clk_round,
- .set = icst_clk_set,
- .setvco = versatile_oscvco_set,
-};
-
-static struct clk osc4_clk = {
- .ops = &osc4_clk_ops,
- .params = &versatile_oscvco_params,
-};
-
-/*
- * These are fixed clocks.
- */
-static struct clk ref24_clk = {
- .rate = 24000000,
-};
-
-static struct clk sp804_clk = {
- .rate = 1000000,
-};
-
-static struct clk dummy_apb_pclk;
-
-static struct clk_lookup lookups[] = {
- { /* AMBA bus clock */
- .con_id = "apb_pclk",
- .clk = &dummy_apb_pclk,
- }, { /* UART0 */
- .dev_id = "dev:f1",
- .clk = &ref24_clk,
- }, { /* UART1 */
- .dev_id = "dev:f2",
- .clk = &ref24_clk,
- }, { /* UART2 */
- .dev_id = "dev:f3",
- .clk = &ref24_clk,
- }, { /* UART3 */
- .dev_id = "fpga:09",
- .clk = &ref24_clk,
- }, { /* KMI0 */
- .dev_id = "fpga:06",
- .clk = &ref24_clk,
- }, { /* KMI1 */
- .dev_id = "fpga:07",
- .clk = &ref24_clk,
- }, { /* MMC0 */
- .dev_id = "fpga:05",
- .clk = &ref24_clk,
- }, { /* MMC1 */
- .dev_id = "fpga:0b",
- .clk = &ref24_clk,
- }, { /* SSP */
- .dev_id = "dev:f4",
- .clk = &ref24_clk,
- }, { /* CLCD */
- .dev_id = "dev:20",
- .clk = &osc4_clk,
- }, { /* SP804 timers */
- .dev_id = "sp804",
- .clk = &sp804_clk,
- },
+static struct mmci_platform_data mmc1_plat_data = {
+ .ocr_mask = MMC_VDD_32_33|MMC_VDD_33_34,
+ .status = mmc_status,
+ .gpio_wp = -1,
+ .gpio_cd = -1,
};
/*
@@ -449,11 +156,10 @@ static void versatile_clcd_disable(struct clcd_fb *fb)
val &= ~SYS_CLCD_NLCDIOON | SYS_CLCD_PWR3V5SWITCH;
writel(val, sys_clcd);
-#ifdef CONFIG_MACH_VERSATILE_AB
/*
* If the LCD is Sanyo 2x5 in on the IB2 board, turn the back-light off
*/
- if (machine_is_versatile_ab() && is_sanyo_2_5_lcd) {
+ if (of_machine_is_compatible("arm,versatile-ab") && is_sanyo_2_5_lcd) {
void __iomem *versatile_ib2_ctrl = __io_address(VERSATILE_IB2_CTRL);
unsigned long ctrl;
@@ -461,7 +167,6 @@ static void versatile_clcd_disable(struct clcd_fb *fb)
ctrl &= ~0x01;
writel(ctrl, versatile_ib2_ctrl);
}
-#endif
}
/*
@@ -502,11 +207,10 @@ static void versatile_clcd_enable(struct clcd_fb *fb)
val |= SYS_CLCD_NLCDIOON | SYS_CLCD_PWR3V5SWITCH;
writel(val, sys_clcd);
-#ifdef CONFIG_MACH_VERSATILE_AB
/*
* If the LCD is Sanyo 2x5 in on the IB2 board, turn the back-light on
*/
- if (machine_is_versatile_ab() && is_sanyo_2_5_lcd) {
+ if (of_machine_is_compatible("arm,versatile-ab") && is_sanyo_2_5_lcd) {
void __iomem *versatile_ib2_ctrl = __io_address(VERSATILE_IB2_CTRL);
unsigned long ctrl;
@@ -514,7 +218,6 @@ static void versatile_clcd_enable(struct clcd_fb *fb)
ctrl |= 0x01;
writel(ctrl, versatile_ib2_ctrl);
}
-#endif
}
/*
@@ -575,113 +278,6 @@ static struct clcd_board clcd_plat_data = {
.remove = versatile_clcd_remove_dma,
};
-static struct pl061_platform_data gpio0_plat_data = {
- .gpio_base = 0,
- .irq_base = IRQ_GPIO0_START,
-};
-
-static struct pl061_platform_data gpio1_plat_data = {
- .gpio_base = 8,
- .irq_base = IRQ_GPIO1_START,
-};
-
-static struct pl061_platform_data gpio2_plat_data = {
- .gpio_base = 16,
- .irq_base = IRQ_GPIO2_START,
-};
-
-static struct pl061_platform_data gpio3_plat_data = {
- .gpio_base = 24,
- .irq_base = IRQ_GPIO3_START,
-};
-
-static struct pl022_ssp_controller ssp0_plat_data = {
- .bus_id = 0,
- .enable_dma = 0,
- .num_chipselect = 1,
-};
-
-#define AACI_IRQ { IRQ_AACI }
-#define MMCI0_IRQ { IRQ_MMCI0A,IRQ_SIC_MMCI0B }
-#define KMI0_IRQ { IRQ_SIC_KMI0 }
-#define KMI1_IRQ { IRQ_SIC_KMI1 }
-
-/*
- * These devices are connected directly to the multi-layer AHB switch
- */
-#define SMC_IRQ { }
-#define MPMC_IRQ { }
-#define CLCD_IRQ { IRQ_CLCDINT }
-#define DMAC_IRQ { IRQ_DMAINT }
-
-/*
- * These devices are connected via the core APB bridge
- */
-#define SCTL_IRQ { }
-#define WATCHDOG_IRQ { IRQ_WDOGINT }
-#define GPIO0_IRQ { IRQ_GPIOINT0 }
-#define GPIO1_IRQ { IRQ_GPIOINT1 }
-#define GPIO2_IRQ { IRQ_GPIOINT2 }
-#define GPIO3_IRQ { IRQ_GPIOINT3 }
-#define RTC_IRQ { IRQ_RTCINT }
-
-/*
- * These devices are connected via the DMA APB bridge
- */
-#define SCI_IRQ { IRQ_SCIINT }
-#define UART0_IRQ { IRQ_UARTINT0 }
-#define UART1_IRQ { IRQ_UARTINT1 }
-#define UART2_IRQ { IRQ_UARTINT2 }
-#define SSP_IRQ { IRQ_SSPINT }
-
-/* FPGA Primecells */
-APB_DEVICE(aaci, "fpga:04", AACI, NULL);
-APB_DEVICE(mmc0, "fpga:05", MMCI0, &mmc0_plat_data);
-APB_DEVICE(kmi0, "fpga:06", KMI0, NULL);
-APB_DEVICE(kmi1, "fpga:07", KMI1, NULL);
-
-/* DevChip Primecells */
-AHB_DEVICE(smc, "dev:00", SMC, NULL);
-AHB_DEVICE(mpmc, "dev:10", MPMC, NULL);
-AHB_DEVICE(clcd, "dev:20", CLCD, &clcd_plat_data);
-AHB_DEVICE(dmac, "dev:30", DMAC, NULL);
-APB_DEVICE(sctl, "dev:e0", SCTL, NULL);
-APB_DEVICE(wdog, "dev:e1", WATCHDOG, NULL);
-APB_DEVICE(gpio0, "dev:e4", GPIO0, &gpio0_plat_data);
-APB_DEVICE(gpio1, "dev:e5", GPIO1, &gpio1_plat_data);
-APB_DEVICE(gpio2, "dev:e6", GPIO2, &gpio2_plat_data);
-APB_DEVICE(gpio3, "dev:e7", GPIO3, &gpio3_plat_data);
-APB_DEVICE(rtc, "dev:e8", RTC, NULL);
-APB_DEVICE(sci0, "dev:f0", SCI, NULL);
-APB_DEVICE(uart0, "dev:f1", UART0, NULL);
-APB_DEVICE(uart1, "dev:f2", UART1, NULL);
-APB_DEVICE(uart2, "dev:f3", UART2, NULL);
-APB_DEVICE(ssp0, "dev:f4", SSP, &ssp0_plat_data);
-
-static struct amba_device *amba_devs[] __initdata = {
- &dmac_device,
- &uart0_device,
- &uart1_device,
- &uart2_device,
- &smc_device,
- &mpmc_device,
- &clcd_device,
- &sctl_device,
- &wdog_device,
- &gpio0_device,
- &gpio1_device,
- &gpio2_device,
- &gpio3_device,
- &rtc_device,
- &sci0_device,
- &ssp0_device,
- &aaci_device,
- &mmc0_device,
- &kmi0_device,
- &kmi1_device,
-};
-
-#ifdef CONFIG_OF
/*
* Lookup table for attaching a specific name and platform_data pointer to
* devices as they get created by of_platform_populate(). Ideally this table
@@ -690,80 +286,12 @@ static struct amba_device *amba_devs[] __initdata = {
*/
struct of_dev_auxdata versatile_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA("arm,primecell", VERSATILE_MMCI0_BASE, "fpga:05", &mmc0_plat_data),
- OF_DEV_AUXDATA("arm,primecell", VERSATILE_KMI0_BASE, "fpga:06", NULL),
- OF_DEV_AUXDATA("arm,primecell", VERSATILE_KMI1_BASE, "fpga:07", NULL),
- OF_DEV_AUXDATA("arm,primecell", VERSATILE_UART3_BASE, "fpga:09", NULL),
- /* FIXME: this is buggy, the platform data is needed for this MMC instance too */
- OF_DEV_AUXDATA("arm,primecell", VERSATILE_MMCI1_BASE, "fpga:0b", NULL),
+ OF_DEV_AUXDATA("arm,primecell", VERSATILE_MMCI1_BASE, "fpga:0b", &mmc1_plat_data),
OF_DEV_AUXDATA("arm,primecell", VERSATILE_CLCD_BASE, "dev:20", &clcd_plat_data),
- OF_DEV_AUXDATA("arm,primecell", VERSATILE_UART0_BASE, "dev:f1", NULL),
- OF_DEV_AUXDATA("arm,primecell", VERSATILE_UART1_BASE, "dev:f2", NULL),
- OF_DEV_AUXDATA("arm,primecell", VERSATILE_UART2_BASE, "dev:f3", NULL),
- OF_DEV_AUXDATA("arm,primecell", VERSATILE_SSP_BASE, "dev:f4", &ssp0_plat_data),
-#if 0
- /*
- * These entries are unnecessary because no clocks referencing
- * them. I've left them in for now as place holders in case
- * any of them need to be added back, but they should be
- * removed before actually committing this patch. --gcl
- */
- OF_DEV_AUXDATA("arm,primecell", VERSATILE_AACI_BASE, "fpga:04", NULL),
- OF_DEV_AUXDATA("arm,primecell", VERSATILE_SCI1_BASE, "fpga:0a", NULL),
- OF_DEV_AUXDATA("arm,primecell", VERSATILE_SMC_BASE, "dev:00", NULL),
- OF_DEV_AUXDATA("arm,primecell", VERSATILE_MPMC_BASE, "dev:10", NULL),
- OF_DEV_AUXDATA("arm,primecell", VERSATILE_DMAC_BASE, "dev:30", NULL),
-
- OF_DEV_AUXDATA("arm,primecell", VERSATILE_SCTL_BASE, "dev:e0", NULL),
- OF_DEV_AUXDATA("arm,primecell", VERSATILE_WATCHDOG_BASE, "dev:e1", NULL),
- OF_DEV_AUXDATA("arm,primecell", VERSATILE_GPIO0_BASE, "dev:e4", NULL),
- OF_DEV_AUXDATA("arm,primecell", VERSATILE_GPIO1_BASE, "dev:e5", NULL),
- OF_DEV_AUXDATA("arm,primecell", VERSATILE_GPIO2_BASE, "dev:e6", NULL),
- OF_DEV_AUXDATA("arm,primecell", VERSATILE_GPIO3_BASE, "dev:e7", NULL),
- OF_DEV_AUXDATA("arm,primecell", VERSATILE_RTC_BASE, "dev:e8", NULL),
- OF_DEV_AUXDATA("arm,primecell", VERSATILE_SCI_BASE, "dev:f0", NULL),
-#endif
{}
};
-#endif
-
-#ifdef CONFIG_LEDS
-#define VA_LEDS_BASE (__io_address(VERSATILE_SYS_BASE) + VERSATILE_SYS_LED_OFFSET)
-
-static void versatile_leds_event(led_event_t ledevt)
-{
- unsigned long flags;
- u32 val;
-
- local_irq_save(flags);
- val = readl(VA_LEDS_BASE);
-
- switch (ledevt) {
- case led_idle_start:
- val = val & ~VERSATILE_SYS_LED0;
- break;
-
- case led_idle_end:
- val = val | VERSATILE_SYS_LED0;
- break;
-
- case led_timer:
- val = val ^ VERSATILE_SYS_LED1;
- break;
-
- case led_halted:
- val = 0;
- break;
-
- default:
- break;
- }
-
- writel(val, VA_LEDS_BASE);
- local_irq_restore(flags);
-}
-#endif /* CONFIG_LEDS */
void versatile_restart(enum reboot_mode mode, const char *cmd)
{
@@ -782,12 +310,6 @@ void versatile_restart(enum reboot_mode mode, const char *cmd)
void __init versatile_init_early(void)
{
u32 val;
- void __iomem *sys = __io_address(VERSATILE_SYS_BASE);
-
- osc4_clk.vcoreg = sys + VERSATILE_SYS_OSCCLCD_OFFSET;
- clkdev_add_table(lookups, ARRAY_SIZE(lookups));
-
- versatile_sched_clock_init(sys + VERSATILE_SYS_24MHz_OFFSET, 24000000);
/*
* set clock frequency:
@@ -801,45 +323,3 @@ void __init versatile_init_early(void)
(VERSATILE_TIMCLK << VERSATILE_TIMER4_EnSel) | val,
__io_address(VERSATILE_SCTL_BASE));
}
-
-void __init versatile_init(void)
-{
- int i;
-
- platform_device_register(&versatile_flash_device);
- platform_device_register(&versatile_i2c_device);
- platform_device_register(&smc91x_device);
- platform_device_register(&char_lcd_device);
- platform_device_register(&leds_device);
-
- for (i = 0; i < ARRAY_SIZE(amba_devs); i++) {
- struct amba_device *d = amba_devs[i];
- amba_device_register(d, &iomem_resource);
- }
-}
-
-/*
- * Where is the timer (VA)?
- */
-#define TIMER0_VA_BASE __io_address(VERSATILE_TIMER0_1_BASE)
-#define TIMER1_VA_BASE (__io_address(VERSATILE_TIMER0_1_BASE) + 0x20)
-#define TIMER2_VA_BASE __io_address(VERSATILE_TIMER2_3_BASE)
-#define TIMER3_VA_BASE (__io_address(VERSATILE_TIMER2_3_BASE) + 0x20)
-
-/*
- * Set up timer interrupt, and return the current time in seconds.
- */
-void __init versatile_timer_init(void)
-{
-
- /*
- * Initialise to a known state (all timers off)
- */
- writel(0, TIMER0_VA_BASE + TIMER_CTRL);
- writel(0, TIMER1_VA_BASE + TIMER_CTRL);
- writel(0, TIMER2_VA_BASE + TIMER_CTRL);
- writel(0, TIMER3_VA_BASE + TIMER_CTRL);
-
- sp804_clocksource_init(TIMER3_VA_BASE, "timer3");
- sp804_clockevents_init(TIMER0_VA_BASE, IRQ_TIMERINT0_1, "timer0");
-}
diff --git a/arch/arm/mach-versatile/core.h b/arch/arm/mach-versatile/core.h
index f06d576..c3d7157 100644
--- a/arch/arm/mach-versatile/core.h
+++ b/arch/arm/mach-versatile/core.h
@@ -26,7 +26,8 @@
#include <linux/of_platform.h>
#include <linux/reboot.h>
-extern void __init versatile_init(void);
+extern struct platform_device versatile_flash_device;
+
extern void __init versatile_init_early(void);
extern void __init versatile_init_irq(void);
extern void __init versatile_map_io(void);
@@ -37,10 +38,4 @@ extern unsigned int mmc_status(struct device *dev);
extern struct of_dev_auxdata versatile_auxdata_lookup[];
#endif
-#define APB_DEVICE(name, busid, base, plat) \
-static AMBA_APB_DEVICE(name, busid, 0, VERSATILE_##base##_BASE, base##_IRQ, plat)
-
-#define AHB_DEVICE(name, busid, base, plat) \
-static AMBA_AHB_DEVICE(name, busid, 0, VERSATILE_##base##_BASE, base##_IRQ, plat)
-
#endif
diff --git a/arch/arm/mach-versatile/include/mach/clkdev.h b/arch/arm/mach-versatile/include/mach/clkdev.h
deleted file mode 100644
index e58d077..0000000
--- a/arch/arm/mach-versatile/include/mach/clkdev.h
+++ /dev/null
@@ -1,16 +0,0 @@
-#ifndef __ASM_MACH_CLKDEV_H
-#define __ASM_MACH_CLKDEV_H
-
-#include <plat/clock.h>
-
-struct clk {
- unsigned long rate;
- const struct clk_ops *ops;
- const struct icst_params *params;
- void __iomem *vcoreg;
-};
-
-#define __clk_get(clk) ({ 1; })
-#define __clk_put(clk) do { } while (0)
-
-#endif
diff --git a/arch/arm/mach-versatile/include/mach/hardware.h b/arch/arm/mach-versatile/include/mach/hardware.h
index 3e5d425..22a1158 100644
--- a/arch/arm/mach-versatile/include/mach/hardware.h
+++ b/arch/arm/mach-versatile/include/mach/hardware.h
@@ -24,12 +24,6 @@
#include <asm/sizes.h>
-/*
- * PCI space virtual addresses
- */
-#define VERSATILE_PCI_VIRT_BASE (void __iomem *)0xe8000000ul
-#define VERSATILE_PCI_CFG_VIRT_BASE (void __iomem *)0xe9000000ul
-
/* macro to get at MMIO space when running virtually */
#define IO_ADDRESS(x) (((x) & 0x0fffffff) + (((x) >> 4) & 0x0f000000) + 0xf0000000)
diff --git a/arch/arm/mach-versatile/include/mach/irqs.h b/arch/arm/mach-versatile/include/mach/irqs.h
deleted file mode 100644
index 0fd771c..0000000
--- a/arch/arm/mach-versatile/include/mach/irqs.h
+++ /dev/null
@@ -1,134 +0,0 @@
-/*
- * arch/arm/mach-versatile/include/mach/irqs.h
- *
- * Copyright (C) 2003 ARM Limited
- * Copyright (C) 2000 Deep Blue Solutions Ltd.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
- */
-
-#include <mach/platform.h>
-
-/*
- * IRQ interrupts definitions are the same as the INT definitions
- * held within platform.h
- */
-#define IRQ_VIC_START 32
-#define IRQ_WDOGINT (IRQ_VIC_START + INT_WDOGINT)
-#define IRQ_SOFTINT (IRQ_VIC_START + INT_SOFTINT)
-#define IRQ_COMMRx (IRQ_VIC_START + INT_COMMRx)
-#define IRQ_COMMTx (IRQ_VIC_START + INT_COMMTx)
-#define IRQ_TIMERINT0_1 (IRQ_VIC_START + INT_TIMERINT0_1)
-#define IRQ_TIMERINT2_3 (IRQ_VIC_START + INT_TIMERINT2_3)
-#define IRQ_GPIOINT0 (IRQ_VIC_START + INT_GPIOINT0)
-#define IRQ_GPIOINT1 (IRQ_VIC_START + INT_GPIOINT1)
-#define IRQ_GPIOINT2 (IRQ_VIC_START + INT_GPIOINT2)
-#define IRQ_GPIOINT3 (IRQ_VIC_START + INT_GPIOINT3)
-#define IRQ_RTCINT (IRQ_VIC_START + INT_RTCINT)
-#define IRQ_SSPINT (IRQ_VIC_START + INT_SSPINT)
-#define IRQ_UARTINT0 (IRQ_VIC_START + INT_UARTINT0)
-#define IRQ_UARTINT1 (IRQ_VIC_START + INT_UARTINT1)
-#define IRQ_UARTINT2 (IRQ_VIC_START + INT_UARTINT2)
-#define IRQ_SCIINT (IRQ_VIC_START + INT_SCIINT)
-#define IRQ_CLCDINT (IRQ_VIC_START + INT_CLCDINT)
-#define IRQ_DMAINT (IRQ_VIC_START + INT_DMAINT)
-#define IRQ_PWRFAILINT (IRQ_VIC_START + INT_PWRFAILINT)
-#define IRQ_MBXINT (IRQ_VIC_START + INT_MBXINT)
-#define IRQ_GNDINT (IRQ_VIC_START + INT_GNDINT)
-#define IRQ_VICSOURCE21 (IRQ_VIC_START + INT_VICSOURCE21)
-#define IRQ_VICSOURCE22 (IRQ_VIC_START + INT_VICSOURCE22)
-#define IRQ_VICSOURCE23 (IRQ_VIC_START + INT_VICSOURCE23)
-#define IRQ_VICSOURCE24 (IRQ_VIC_START + INT_VICSOURCE24)
-#define IRQ_VICSOURCE25 (IRQ_VIC_START + INT_VICSOURCE25)
-#define IRQ_VICSOURCE26 (IRQ_VIC_START + INT_VICSOURCE26)
-#define IRQ_VICSOURCE27 (IRQ_VIC_START + INT_VICSOURCE27)
-#define IRQ_VICSOURCE28 (IRQ_VIC_START + INT_VICSOURCE28)
-#define IRQ_VICSOURCE29 (IRQ_VIC_START + INT_VICSOURCE29)
-#define IRQ_VICSOURCE30 (IRQ_VIC_START + INT_VICSOURCE30)
-#define IRQ_VICSOURCE31 (IRQ_VIC_START + INT_VICSOURCE31)
-#define IRQ_VIC_END (IRQ_VIC_START + 31)
-
-/*
- * FIQ interrupts definitions are the same as the INT definitions.
- */
-#define FIQ_WDOGINT INT_WDOGINT
-#define FIQ_SOFTINT INT_SOFTINT
-#define FIQ_COMMRx INT_COMMRx
-#define FIQ_COMMTx INT_COMMTx
-#define FIQ_TIMERINT0_1 INT_TIMERINT0_1
-#define FIQ_TIMERINT2_3 INT_TIMERINT2_3
-#define FIQ_GPIOINT0 INT_GPIOINT0
-#define FIQ_GPIOINT1 INT_GPIOINT1
-#define FIQ_GPIOINT2 INT_GPIOINT2
-#define FIQ_GPIOINT3 INT_GPIOINT3
-#define FIQ_RTCINT INT_RTCINT
-#define FIQ_SSPINT INT_SSPINT
-#define FIQ_UARTINT0 INT_UARTINT0
-#define FIQ_UARTINT1 INT_UARTINT1
-#define FIQ_UARTINT2 INT_UARTINT2
-#define FIQ_SCIINT INT_SCIINT
-#define FIQ_CLCDINT INT_CLCDINT
-#define FIQ_DMAINT INT_DMAINT
-#define FIQ_PWRFAILINT INT_PWRFAILINT
-#define FIQ_MBXINT INT_MBXINT
-#define FIQ_GNDINT INT_GNDINT
-#define FIQ_VICSOURCE21 INT_VICSOURCE21
-#define FIQ_VICSOURCE22 INT_VICSOURCE22
-#define FIQ_VICSOURCE23 INT_VICSOURCE23
-#define FIQ_VICSOURCE24 INT_VICSOURCE24
-#define FIQ_VICSOURCE25 INT_VICSOURCE25
-#define FIQ_VICSOURCE26 INT_VICSOURCE26
-#define FIQ_VICSOURCE27 INT_VICSOURCE27
-#define FIQ_VICSOURCE28 INT_VICSOURCE28
-#define FIQ_VICSOURCE29 INT_VICSOURCE29
-#define FIQ_VICSOURCE30 INT_VICSOURCE30
-#define FIQ_VICSOURCE31 INT_VICSOURCE31
-
-
-/*
- * Secondary interrupt controller
- */
-#define IRQ_SIC_START 64
-#define IRQ_SIC_MMCI0B (IRQ_SIC_START + SIC_INT_MMCI0B)
-#define IRQ_SIC_MMCI1B (IRQ_SIC_START + SIC_INT_MMCI1B)
-#define IRQ_SIC_KMI0 (IRQ_SIC_START + SIC_INT_KMI0)
-#define IRQ_SIC_KMI1 (IRQ_SIC_START + SIC_INT_KMI1)
-#define IRQ_SIC_SCI3 (IRQ_SIC_START + SIC_INT_SCI3)
-#define IRQ_SIC_UART3 (IRQ_SIC_START + SIC_INT_UART3)
-#define IRQ_SIC_CLCD (IRQ_SIC_START + SIC_INT_CLCD)
-#define IRQ_SIC_TOUCH (IRQ_SIC_START + SIC_INT_TOUCH)
-#define IRQ_SIC_KEYPAD (IRQ_SIC_START + SIC_INT_KEYPAD)
-#define IRQ_SIC_DoC (IRQ_SIC_START + SIC_INT_DoC)
-#define IRQ_SIC_MMCI0A (IRQ_SIC_START + SIC_INT_MMCI0A)
-#define IRQ_SIC_MMCI1A (IRQ_SIC_START + SIC_INT_MMCI1A)
-#define IRQ_SIC_AACI (IRQ_SIC_START + SIC_INT_AACI)
-#define IRQ_SIC_ETH (IRQ_SIC_START + SIC_INT_ETH)
-#define IRQ_SIC_USB (IRQ_SIC_START + SIC_INT_USB)
-#define IRQ_SIC_PCI0 (IRQ_SIC_START + SIC_INT_PCI0)
-#define IRQ_SIC_PCI1 (IRQ_SIC_START + SIC_INT_PCI1)
-#define IRQ_SIC_PCI2 (IRQ_SIC_START + SIC_INT_PCI2)
-#define IRQ_SIC_PCI3 (IRQ_SIC_START + SIC_INT_PCI3)
-#define IRQ_SIC_END 95
-
-#define IRQ_GPIO0_START (IRQ_SIC_END + 1)
-#define IRQ_GPIO0_END (IRQ_GPIO0_START + 31)
-#define IRQ_GPIO1_START (IRQ_GPIO0_END + 1)
-#define IRQ_GPIO1_END (IRQ_GPIO1_START + 31)
-#define IRQ_GPIO2_START (IRQ_GPIO1_END + 1)
-#define IRQ_GPIO2_END (IRQ_GPIO2_START + 31)
-#define IRQ_GPIO3_START (IRQ_GPIO2_END + 1)
-#define IRQ_GPIO3_END (IRQ_GPIO3_START + 31)
-
-#define NR_IRQS (IRQ_GPIO3_END + 1)
diff --git a/arch/arm/mach-versatile/include/mach/platform.h b/arch/arm/mach-versatile/include/mach/platform.h
index 6f938cc..7fe008b 100644
--- a/arch/arm/mach-versatile/include/mach/platform.h
+++ b/arch/arm/mach-versatile/include/mach/platform.h
@@ -185,79 +185,13 @@
/*
* VERSATILE peripheral addresses
*/
-#define VERSATILE_PCI_CORE_BASE 0x10001000 /* PCI core control */
-#define VERSATILE_I2C_BASE 0x10002000 /* I2C control */
-#define VERSATILE_SIC_BASE 0x10003000 /* Secondary interrupt controller */
-#define VERSATILE_AACI_BASE 0x10004000 /* Audio */
#define VERSATILE_MMCI0_BASE 0x10005000 /* MMC interface */
-#define VERSATILE_KMI0_BASE 0x10006000 /* KMI interface */
-#define VERSATILE_KMI1_BASE 0x10007000 /* KMI 2nd interface */
-#define VERSATILE_CHAR_LCD_BASE 0x10008000 /* Character LCD */
-#define VERSATILE_UART3_BASE 0x10009000 /* UART 3 */
-#define VERSATILE_SCI1_BASE 0x1000A000
#define VERSATILE_MMCI1_BASE 0x1000B000 /* MMC Interface */
- /* 0x1000C000 - 0x1000CFFF = reserved */
-#define VERSATILE_ETH_BASE 0x10010000 /* Ethernet */
-#define VERSATILE_USB_BASE 0x10020000 /* USB */
- /* 0x10030000 - 0x100FFFFF = reserved */
-#define VERSATILE_SMC_BASE 0x10100000 /* SMC */
-#define VERSATILE_MPMC_BASE 0x10110000 /* MPMC */
#define VERSATILE_CLCD_BASE 0x10120000 /* CLCD */
-#define VERSATILE_DMAC_BASE 0x10130000 /* DMA controller */
-#define VERSATILE_VIC_BASE 0x10140000 /* Vectored interrupt controller */
-#define VERSATILE_PERIPH_BASE 0x10150000 /* off-chip peripherals alias from */
- /* 0x10000000 - 0x100FFFFF */
-#define VERSATILE_AHBM_BASE 0x101D0000 /* AHB monitor */
#define VERSATILE_SCTL_BASE 0x101E0000 /* System controller */
-#define VERSATILE_WATCHDOG_BASE 0x101E1000 /* Watchdog */
-#define VERSATILE_TIMER0_1_BASE 0x101E2000 /* Timer 0 and 1 */
-#define VERSATILE_TIMER2_3_BASE 0x101E3000 /* Timer 2 and 3 */
-#define VERSATILE_GPIO0_BASE 0x101E4000 /* GPIO port 0 */
-#define VERSATILE_GPIO1_BASE 0x101E5000 /* GPIO port 1 */
-#define VERSATILE_GPIO2_BASE 0x101E6000 /* GPIO port 2 */
-#define VERSATILE_GPIO3_BASE 0x101E7000 /* GPIO port 3 */
-#define VERSATILE_RTC_BASE 0x101E8000 /* Real Time Clock */
- /* 0x101E9000 - reserved */
-#define VERSATILE_SCI_BASE 0x101F0000 /* Smart card controller */
-#define VERSATILE_UART0_BASE 0x101F1000 /* Uart 0 */
-#define VERSATILE_UART1_BASE 0x101F2000 /* Uart 1 */
-#define VERSATILE_UART2_BASE 0x101F3000 /* Uart 2 */
-#define VERSATILE_SSP_BASE 0x101F4000 /* Synchronous Serial Port */
-
-#define VERSATILE_SSMC_BASE 0x20000000 /* SSMC */
#define VERSATILE_IB2_BASE 0x24000000 /* IB2 module */
-#define VERSATILE_MBX_BASE 0x40000000 /* MBX */
-
-/* PCI space */
-#define VERSATILE_PCI_BASE 0x41000000 /* PCI Interface */
-#define VERSATILE_PCI_CFG_BASE 0x42000000
-#define VERSATILE_PCI_IO_BASE 0x43000000
-#define VERSATILE_PCI_MEM_BASE0 0x44000000
-#define VERSATILE_PCI_MEM_BASE1 0x50000000
-#define VERSATILE_PCI_MEM_BASE2 0x60000000
-/* Sizes of above maps */
-#define VERSATILE_PCI_BASE_SIZE 0x01000000
-#define VERSATILE_PCI_CFG_BASE_SIZE 0x02000000
-#define VERSATILE_PCI_IO_BASE_SIZE 0x01000000
-#define VERSATILE_PCI_MEM_BASE0_SIZE 0x0c000000 /* 32Mb */
-#define VERSATILE_PCI_MEM_BASE1_SIZE 0x10000000 /* 256Mb */
-#define VERSATILE_PCI_MEM_BASE2_SIZE 0x10000000 /* 256Mb */
-
-#define VERSATILE_SDRAM67_BASE 0x70000000 /* SDRAM banks 6 and 7 */
-#define VERSATILE_LT_BASE 0x80000000 /* Logic Tile expansion */
/*
- * Disk on Chip
- */
-#define VERSATILE_DOC_BASE 0x2C000000
-#define VERSATILE_DOC_SIZE (16 << 20)
-#define VERSATILE_DOC_PAGE_SIZE 512
-#define VERSATILE_DOC_TOTAL_PAGES (DOC_SIZE / PAGE_SIZE)
-
-#define ERASE_UNIT_PAGES 32
-#define START_PAGE 0x80
-
-/*
* LED settings, bits [7:0]
*/
#define VERSATILE_SYS_LED0 (1 << 0)
@@ -281,106 +215,6 @@
#define VERSATILE_INTREG_OFFSET 0x8 /* Interrupt control */
#define VERSATILE_DECODE_OFFSET 0xC /* Fitted logic modules */
-
-/* ------------------------------------------------------------------------
- * Versatile Interrupt Controller - control registers
- * ------------------------------------------------------------------------
- *
- * Offsets from interrupt controller base
- *
- * System Controller interrupt controller base is
- *
- * VERSATILE_IC_BASE
- *
- * Core Module interrupt controller base is
- *
- * VERSATILE_SYS_IC
- *
- */
-/* VIC definitions in include/asm-arm/hardware/vic.h */
-
-#define SIC_IRQ_STATUS 0
-#define SIC_IRQ_RAW_STATUS 0x04
-#define SIC_IRQ_ENABLE 0x08
-#define SIC_IRQ_ENABLE_SET 0x08
-#define SIC_IRQ_ENABLE_CLEAR 0x0C
-#define SIC_INT_SOFT_SET 0x10
-#define SIC_INT_SOFT_CLEAR 0x14
-#define SIC_INT_PIC_ENABLE 0x20 /* read status of pass through mask */
-#define SIC_INT_PIC_ENABLES 0x20 /* set interrupt pass through bits */
-#define SIC_INT_PIC_ENABLEC 0x24 /* Clear interrupt pass through bits */
-
-/* ------------------------------------------------------------------------
- * Interrupts - bit assignment (primary)
- * ------------------------------------------------------------------------
- */
-
-#define INT_WDOGINT 0 /* Watchdog timer */
-#define INT_SOFTINT 1 /* Software interrupt */
-#define INT_COMMRx 2 /* Debug Comm Rx interrupt */
-#define INT_COMMTx 3 /* Debug Comm Tx interrupt */
-#define INT_TIMERINT0_1 4 /* Timer 0 and 1 */
-#define INT_TIMERINT2_3 5 /* Timer 2 and 3 */
-#define INT_GPIOINT0 6 /* GPIO 0 */
-#define INT_GPIOINT1 7 /* GPIO 1 */
-#define INT_GPIOINT2 8 /* GPIO 2 */
-#define INT_GPIOINT3 9 /* GPIO 3 */
-#define INT_RTCINT 10 /* Real Time Clock */
-#define INT_SSPINT 11 /* Synchronous Serial Port */
-#define INT_UARTINT0 12 /* UART 0 on development chip */
-#define INT_UARTINT1 13 /* UART 1 on development chip */
-#define INT_UARTINT2 14 /* UART 2 on development chip */
-#define INT_SCIINT 15 /* Smart Card Interface */
-#define INT_CLCDINT 16 /* CLCD controller */
-#define INT_DMAINT 17 /* DMA controller */
-#define INT_PWRFAILINT 18 /* Power failure */
-#define INT_MBXINT 19 /* Graphics processor */
-#define INT_GNDINT 20 /* Reserved */
- /* External interrupt signals from logic tiles or secondary controller */
-#define INT_VICSOURCE21 21 /* Disk on Chip */
-#define INT_VICSOURCE22 22 /* MCI0A */
-#define INT_VICSOURCE23 23 /* MCI1A */
-#define INT_VICSOURCE24 24 /* AACI */
-#define INT_VICSOURCE25 25 /* Ethernet */
-#define INT_VICSOURCE26 26 /* USB */
-#define INT_VICSOURCE27 27 /* PCI 0 */
-#define INT_VICSOURCE28 28 /* PCI 1 */
-#define INT_VICSOURCE29 29 /* PCI 2 */
-#define INT_VICSOURCE30 30 /* PCI 3 */
-#define INT_VICSOURCE31 31 /* SIC source */
-
-#define VERSATILE_SC_VALID_INT 0x003FFFFF
-
-#define MAXIRQNUM 31
-#define MAXFIQNUM 31
-#define MAXSWINUM 31
-
-/* ------------------------------------------------------------------------
- * Interrupts - bit assignment (secondary)
- * ------------------------------------------------------------------------
- */
-#define SIC_INT_MMCI0B 1 /* Multimedia Card 0B */
-#define SIC_INT_MMCI1B 2 /* Multimedia Card 1B */
-#define SIC_INT_KMI0 3 /* Keyboard/Mouse port 0 */
-#define SIC_INT_KMI1 4 /* Keyboard/Mouse port 1 */
-#define SIC_INT_SCI3 5 /* Smart Card interface */
-#define SIC_INT_UART3 6 /* UART 3 empty or data available */
-#define SIC_INT_CLCD 7 /* Character LCD */
-#define SIC_INT_TOUCH 8 /* Touchscreen */
-#define SIC_INT_KEYPAD 9 /* Key pressed on display keypad */
- /* 10:20 - reserved */
-#define SIC_INT_DoC 21 /* Disk on Chip memory controller */
-#define SIC_INT_MMCI0A 22 /* MMC 0A */
-#define SIC_INT_MMCI1A 23 /* MMC 1A */
-#define SIC_INT_AACI 24 /* Audio Codec */
-#define SIC_INT_ETH 25 /* Ethernet controller */
-#define SIC_INT_USB 26 /* USB controller */
-#define SIC_INT_PCI0 27
-#define SIC_INT_PCI1 28
-#define SIC_INT_PCI2 29
-#define SIC_INT_PCI3 30
-
-
/*
* System controller bit assignment
*/
@@ -393,16 +227,9 @@
#define VERSATILE_TIMER4_EnSel 21
-#define VERSATILE_CSR_BASE 0x10000000
-#define VERSATILE_CSR_SIZE 0x10000000
-
-#ifdef CONFIG_MACH_VERSATILE_AB
/*
* IB2 Versatile/AB expansion board definitions
*/
-#define VERSATILE_IB2_CAMERA_BANK VERSATILE_IB2_BASE
-#define VERSATILE_IB2_KBD_DATAREG (VERSATILE_IB2_BASE + 0x01000000)
-
/* VICINTSOURCE27 */
#define VERSATILE_IB2_INT_BASE (VERSATILE_IB2_BASE + 0x02000000)
#define VERSATILE_IB2_IER (VERSATILE_IB2_INT_BASE + 0)
@@ -411,6 +238,5 @@
#define VERSATILE_IB2_CTL_BASE (VERSATILE_IB2_BASE + 0x03000000)
#define VERSATILE_IB2_CTRL (VERSATILE_IB2_CTL_BASE + 0)
#define VERSATILE_IB2_STAT (VERSATILE_IB2_CTL_BASE + 4)
-#endif
#endif
diff --git a/arch/arm/mach-versatile/pci.c b/arch/arm/mach-versatile/pci.c
deleted file mode 100644
index c97be4e..0000000
--- a/arch/arm/mach-versatile/pci.c
+++ /dev/null
@@ -1,368 +0,0 @@
-/*
- * linux/arch/arm/mach-versatile/pci.c
- *
- * (C) Copyright Koninklijke Philips Electronics NV 2004. All rights reserved.
- * You can redistribute and/or modify this software under the terms of version 2
- * of the GNU General Public License as published by the Free Software Foundation.
- * THIS SOFTWARE IS PROVIDED "AS IS" WITHOUT ANY WARRANTY; WITHOUT EVEN THE IMPLIED
- * WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * General Public License for more details.
- * Koninklijke Philips Electronics nor its subsidiaries is obligated to provide any support for this software.
- *
- * ARM Versatile PCI driver.
- *
- * 14/04/2005 Initial version, colin.king@philips.com
- *
- */
-#include <linux/kernel.h>
-#include <linux/pci.h>
-#include <linux/ioport.h>
-#include <linux/interrupt.h>
-#include <linux/spinlock.h>
-#include <linux/init.h>
-#include <linux/io.h>
-
-#include <mach/hardware.h>
-#include <mach/irqs.h>
-#include <asm/irq.h>
-#include <asm/mach/pci.h>
-
-/*
- * these spaces are mapped using the following base registers:
- *
- * Usage Local Bus Memory Base/Map registers used
- *
- * Mem 50000000 - 5FFFFFFF LB_BASE0/LB_MAP0, non prefetch
- * Mem 60000000 - 6FFFFFFF LB_BASE1/LB_MAP1, prefetch
- * IO 44000000 - 4FFFFFFF LB_BASE2/LB_MAP2, IO
- * Cfg 42000000 - 42FFFFFF PCI config
- *
- */
-#define __IO_ADDRESS(n) ((void __iomem *)(unsigned long)IO_ADDRESS(n))
-#define SYS_PCICTL __IO_ADDRESS(VERSATILE_SYS_PCICTL)
-#define PCI_IMAP0 __IO_ADDRESS(VERSATILE_PCI_CORE_BASE+0x0)
-#define PCI_IMAP1 __IO_ADDRESS(VERSATILE_PCI_CORE_BASE+0x4)
-#define PCI_IMAP2 __IO_ADDRESS(VERSATILE_PCI_CORE_BASE+0x8)
-#define PCI_SMAP0 __IO_ADDRESS(VERSATILE_PCI_CORE_BASE+0x14)
-#define PCI_SMAP1 __IO_ADDRESS(VERSATILE_PCI_CORE_BASE+0x18)
-#define PCI_SMAP2 __IO_ADDRESS(VERSATILE_PCI_CORE_BASE+0x1c)
-#define PCI_SELFID __IO_ADDRESS(VERSATILE_PCI_CORE_BASE+0xc)
-
-#define DEVICE_ID_OFFSET 0x00
-#define CSR_OFFSET 0x04
-#define CLASS_ID_OFFSET 0x08
-
-#define VP_PCI_DEVICE_ID 0x030010ee
-#define VP_PCI_CLASS_ID 0x0b400000
-
-static unsigned long pci_slot_ignore = 0;
-
-static int __init versatile_pci_slot_ignore(char *str)
-{
- int retval;
- int slot;
-
- while ((retval = get_option(&str,&slot))) {
- if ((slot < 0) || (slot > 31)) {
- printk("Illegal slot value: %d\n",slot);
- } else {
- pci_slot_ignore |= (1 << slot);
- }
- }
- return 1;
-}
-
-__setup("pci_slot_ignore=", versatile_pci_slot_ignore);
-
-
-static void __iomem *__pci_addr(struct pci_bus *bus,
- unsigned int devfn, int offset)
-{
- unsigned int busnr = bus->number;
-
- /*
- * Trap out illegal values
- */
- if (offset > 255)
- BUG();
- if (busnr > 255)
- BUG();
- if (devfn > 255)
- BUG();
-
- return VERSATILE_PCI_CFG_VIRT_BASE + ((busnr << 16) |
- (PCI_SLOT(devfn) << 11) | (PCI_FUNC(devfn) << 8) | offset);
-}
-
-static int versatile_read_config(struct pci_bus *bus, unsigned int devfn, int where,
- int size, u32 *val)
-{
- void __iomem *addr = __pci_addr(bus, devfn, where & ~3);
- u32 v;
- int slot = PCI_SLOT(devfn);
-
- if (pci_slot_ignore & (1 << slot)) {
- /* Ignore this slot */
- switch (size) {
- case 1:
- v = 0xff;
- break;
- case 2:
- v = 0xffff;
- break;
- default:
- v = 0xffffffff;
- }
- } else {
- switch (size) {
- case 1:
- v = __raw_readl(addr);
- if (where & 2) v >>= 16;
- if (where & 1) v >>= 8;
- v &= 0xff;
- break;
-
- case 2:
- v = __raw_readl(addr);
- if (where & 2) v >>= 16;
- v &= 0xffff;
- break;
-
- default:
- v = __raw_readl(addr);
- break;
- }
- }
-
- *val = v;
- return PCIBIOS_SUCCESSFUL;
-}
-
-static int versatile_write_config(struct pci_bus *bus, unsigned int devfn, int where,
- int size, u32 val)
-{
- void __iomem *addr = __pci_addr(bus, devfn, where);
- int slot = PCI_SLOT(devfn);
-
- if (pci_slot_ignore & (1 << slot)) {
- return PCIBIOS_SUCCESSFUL;
- }
-
- switch (size) {
- case 1:
- __raw_writeb((u8)val, addr);
- break;
-
- case 2:
- __raw_writew((u16)val, addr);
- break;
-
- case 4:
- __raw_writel(val, addr);
- break;
- }
-
- return PCIBIOS_SUCCESSFUL;
-}
-
-static struct pci_ops pci_versatile_ops = {
- .read = versatile_read_config,
- .write = versatile_write_config,
-};
-
-static struct resource unused_mem = {
- .name = "PCI unused",
- .start = VERSATILE_PCI_MEM_BASE0,
- .end = VERSATILE_PCI_MEM_BASE0+VERSATILE_PCI_MEM_BASE0_SIZE-1,
- .flags = IORESOURCE_MEM,
-};
-
-static struct resource non_mem = {
- .name = "PCI non-prefetchable",
- .start = VERSATILE_PCI_MEM_BASE1,
- .end = VERSATILE_PCI_MEM_BASE1+VERSATILE_PCI_MEM_BASE1_SIZE-1,
- .flags = IORESOURCE_MEM,
-};
-
-static struct resource pre_mem = {
- .name = "PCI prefetchable",
- .start = VERSATILE_PCI_MEM_BASE2,
- .end = VERSATILE_PCI_MEM_BASE2+VERSATILE_PCI_MEM_BASE2_SIZE-1,
- .flags = IORESOURCE_MEM | IORESOURCE_PREFETCH,
-};
-
-static int __init pci_versatile_setup_resources(struct pci_sys_data *sys)
-{
- int ret = 0;
-
- ret = request_resource(&iomem_resource, &unused_mem);
- if (ret) {
- printk(KERN_ERR "PCI: unable to allocate unused "
- "memory region (%d)\n", ret);
- goto out;
- }
- ret = request_resource(&iomem_resource, &non_mem);
- if (ret) {
- printk(KERN_ERR "PCI: unable to allocate non-prefetchable "
- "memory region (%d)\n", ret);
- goto release_unused_mem;
- }
- ret = request_resource(&iomem_resource, &pre_mem);
- if (ret) {
- printk(KERN_ERR "PCI: unable to allocate prefetchable "
- "memory region (%d)\n", ret);
- goto release_non_mem;
- }
-
- /*
- * the mem resource for this bus
- * the prefetch mem resource for this bus
- */
- pci_add_resource_offset(&sys->resources, &non_mem, sys->mem_offset);
- pci_add_resource_offset(&sys->resources, &pre_mem, sys->mem_offset);
-
- goto out;
-
- release_non_mem:
- release_resource(&non_mem);
- release_unused_mem:
- release_resource(&unused_mem);
- out:
- return ret;
-}
-
-int __init pci_versatile_setup(int nr, struct pci_sys_data *sys)
-{
- int ret = 0;
- int i;
- int myslot = -1;
- unsigned long val;
- void __iomem *local_pci_cfg_base;
-
- val = __raw_readl(SYS_PCICTL);
- if (!(val & 1)) {
- printk("Not plugged into PCI backplane!\n");
- ret = -EIO;
- goto out;
- }
-
- ret = pci_ioremap_io(0, VERSATILE_PCI_IO_BASE);
- if (ret)
- goto out;
-
- if (nr == 0) {
- ret = pci_versatile_setup_resources(sys);
- if (ret < 0) {
- printk("pci_versatile_setup: resources... oops?\n");
- goto out;
- }
- } else {
- printk("pci_versatile_setup: resources... nr == 0??\n");
- goto out;
- }
-
- /*
- * We need to discover the PCI core first to configure itself
- * before the main PCI probing is performed
- */
- for (i=0; i<32; i++)
- if ((__raw_readl(VERSATILE_PCI_VIRT_BASE+(i<<11)+DEVICE_ID_OFFSET) == VP_PCI_DEVICE_ID) &&
- (__raw_readl(VERSATILE_PCI_VIRT_BASE+(i<<11)+CLASS_ID_OFFSET) == VP_PCI_CLASS_ID)) {
- myslot = i;
- break;
- }
-
- if (myslot == -1) {
- printk("Cannot find PCI core!\n");
- ret = -EIO;
- goto out;
- }
-
- printk("PCI core found (slot %d)\n",myslot);
-
- __raw_writel(myslot, PCI_SELFID);
- local_pci_cfg_base = VERSATILE_PCI_CFG_VIRT_BASE + (myslot << 11);
-
- val = __raw_readl(local_pci_cfg_base + CSR_OFFSET);
- val |= PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER | PCI_COMMAND_INVALIDATE;
- __raw_writel(val, local_pci_cfg_base + CSR_OFFSET);
-
- /*
- * Configure the PCI inbound memory windows to be 1:1 mapped to SDRAM
- */
- __raw_writel(PHYS_OFFSET, local_pci_cfg_base + PCI_BASE_ADDRESS_0);
- __raw_writel(PHYS_OFFSET, local_pci_cfg_base + PCI_BASE_ADDRESS_1);
- __raw_writel(PHYS_OFFSET, local_pci_cfg_base + PCI_BASE_ADDRESS_2);
-
- /*
- * For many years the kernel and QEMU were symbiotically buggy
- * in that they both assumed the same broken IRQ mapping.
- * QEMU therefore attempts to auto-detect old broken kernels
- * so that they still work on newer QEMU as they did on old
- * QEMU. Since we now use the correct (ie matching-hardware)
- * IRQ mapping we write a definitely different value to a
- * PCI_INTERRUPT_LINE register to tell QEMU that we expect
- * real hardware behaviour and it need not be backwards
- * compatible for us. This write is harmless on real hardware.
- */
- __raw_writel(0, VERSATILE_PCI_VIRT_BASE+PCI_INTERRUPT_LINE);
-
- /*
- * Do not to map Versatile FPGA PCI device into memory space
- */
- pci_slot_ignore |= (1 << myslot);
- ret = 1;
-
- out:
- return ret;
-}
-
-
-void __init pci_versatile_preinit(void)
-{
- pcibios_min_mem = 0x50000000;
-
- __raw_writel(VERSATILE_PCI_MEM_BASE0 >> 28, PCI_IMAP0);
- __raw_writel(VERSATILE_PCI_MEM_BASE1 >> 28, PCI_IMAP1);
- __raw_writel(VERSATILE_PCI_MEM_BASE2 >> 28, PCI_IMAP2);
-
- __raw_writel(PHYS_OFFSET >> 28, PCI_SMAP0);
- __raw_writel(PHYS_OFFSET >> 28, PCI_SMAP1);
- __raw_writel(PHYS_OFFSET >> 28, PCI_SMAP2);
-
- __raw_writel(1, SYS_PCICTL);
-}
-
-/*
- * map the specified device/slot/pin to an IRQ. Different backplanes may need to modify this.
- */
-static int __init versatile_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
-{
- int irq;
-
- /*
- * Slot INTA INTB INTC INTD
- * 31 PCI1 PCI2 PCI3 PCI0
- * 30 PCI0 PCI1 PCI2 PCI3
- * 29 PCI3 PCI0 PCI1 PCI2
- */
- irq = IRQ_SIC_PCI0 + ((slot + 2 + pin - 1) & 3);
-
- return irq;
-}
-
-static struct hw_pci versatile_pci __initdata = {
- .map_irq = versatile_map_irq,
- .nr_controllers = 1,
- .ops = &pci_versatile_ops,
- .setup = pci_versatile_setup,
- .preinit = pci_versatile_preinit,
-};
-
-static int __init versatile_pci_init(void)
-{
- pci_common_init(&versatile_pci);
- return 0;
-}
-
-subsys_initcall(versatile_pci_init);
diff --git a/arch/arm/mach-versatile/versatile_ab.c b/arch/arm/mach-versatile/versatile_ab.c
deleted file mode 100644
index 1caef10..0000000
--- a/arch/arm/mach-versatile/versatile_ab.c
+++ /dev/null
@@ -1,44 +0,0 @@
-/*
- * linux/arch/arm/mach-versatile/versatile_ab.c
- *
- * Copyright (C) 2004 ARM Limited
- * Copyright (C) 2000 Deep Blue Solutions Ltd
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
- */
-
-#include <linux/init.h>
-#include <linux/device.h>
-#include <linux/amba/bus.h>
-#include <linux/io.h>
-
-#include <mach/hardware.h>
-#include <asm/irq.h>
-#include <asm/mach-types.h>
-
-#include <asm/mach/arch.h>
-
-#include "core.h"
-
-MACHINE_START(VERSATILE_AB, "ARM-Versatile AB")
- /* Maintainer: ARM Ltd/Deep Blue Solutions Ltd */
- .atag_offset = 0x100,
- .map_io = versatile_map_io,
- .init_early = versatile_init_early,
- .init_irq = versatile_init_irq,
- .init_time = versatile_timer_init,
- .init_machine = versatile_init,
- .restart = versatile_restart,
-MACHINE_END
diff --git a/arch/arm/mach-versatile/versatile_dt.c b/arch/arm/mach-versatile/versatile_dt.c
index 5053810..1bb21d1 100644
--- a/arch/arm/mach-versatile/versatile_dt.c
+++ b/arch/arm/mach-versatile/versatile_dt.c
@@ -77,6 +77,7 @@ static void __init versatile_dt_init(void)
{
versatile_dt_pci_init();
+ platform_device_register(&versatile_flash_device);
of_platform_populate(NULL, of_default_bus_match_table,
versatile_auxdata_lookup, NULL);
}
diff --git a/arch/arm/mach-versatile/versatile_pb.c b/arch/arm/mach-versatile/versatile_pb.c
deleted file mode 100644
index 9a53d0b..0000000
--- a/arch/arm/mach-versatile/versatile_pb.c
+++ /dev/null
@@ -1,91 +0,0 @@
-/*
- * linux/arch/arm/mach-versatile/versatile_pb.c
- *
- * Copyright (C) 2004 ARM Limited
- * Copyright (C) 2000 Deep Blue Solutions Ltd
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
- */
-
-#include <linux/init.h>
-#include <linux/device.h>
-#include <linux/amba/bus.h>
-#include <linux/amba/pl061.h>
-#include <linux/amba/mmci.h>
-#include <linux/io.h>
-
-#include <mach/hardware.h>
-#include <asm/irq.h>
-#include <asm/mach-types.h>
-
-#include <asm/mach/arch.h>
-
-#include "core.h"
-
-#if 1
-#define IRQ_MMCI1A IRQ_VICSOURCE23
-#else
-#define IRQ_MMCI1A IRQ_SIC_MMCI1A
-#endif
-
-static struct mmci_platform_data mmc1_plat_data = {
- .ocr_mask = MMC_VDD_32_33|MMC_VDD_33_34,
- .status = mmc_status,
- .gpio_wp = -1,
- .gpio_cd = -1,
-};
-
-#define UART3_IRQ { IRQ_SIC_UART3 }
-#define SCI1_IRQ { IRQ_SIC_SCI3 }
-#define MMCI1_IRQ { IRQ_MMCI1A, IRQ_SIC_MMCI1B }
-
-/*
- * These devices are connected via the DMA APB bridge
- */
-
-/* FPGA Primecells */
-APB_DEVICE(uart3, "fpga:09", UART3, NULL);
-APB_DEVICE(sci1, "fpga:0a", SCI1, NULL);
-APB_DEVICE(mmc1, "fpga:0b", MMCI1, &mmc1_plat_data);
-
-
-static struct amba_device *amba_devs[] __initdata = {
- &uart3_device,
- &sci1_device,
- &mmc1_device,
-};
-
-static void __init versatile_pb_init(void)
-{
- int i;
-
- versatile_init();
-
- for (i = 0; i < ARRAY_SIZE(amba_devs); i++) {
- struct amba_device *d = amba_devs[i];
- amba_device_register(d, &iomem_resource);
- }
-}
-
-MACHINE_START(VERSATILE_PB, "ARM-Versatile PB")
- /* Maintainer: ARM Ltd/Deep Blue Solutions Ltd */
- .atag_offset = 0x100,
- .map_io = versatile_map_io,
- .init_early = versatile_init_early,
- .init_irq = versatile_init_irq,
- .init_time = versatile_timer_init,
- .init_machine = versatile_pb_init,
- .restart = versatile_restart,
-MACHINE_END
diff --git a/drivers/clk/versatile/Kconfig b/drivers/clk/versatile/Kconfig
index 1530c93..ec1923a 100644
--- a/drivers/clk/versatile/Kconfig
+++ b/drivers/clk/versatile/Kconfig
@@ -1,6 +1,7 @@
config COMMON_CLK_VERSATILE
bool "Clock driver for ARM Reference designs"
- depends on ARCH_INTEGRATOR || ARCH_REALVIEW || ARCH_VEXPRESS || ARM64
+ depends on ARCH_INTEGRATOR || ARCH_REALVIEW || \
+ ARCH_VERSATILE || ARCH_VEXPRESS || ARM64
---help---
Supports clocking on ARM Reference designs:
- Integrator/AP and Integrator/CP
--
2.1.0
^ permalink raw reply related [flat|nested] 86+ messages in thread
* [PATCH 7/9] ARM: versatile: move mach includes into mach directory
2014-12-30 19:28 ` Rob Herring
@ 2014-12-30 19:28 ` Rob Herring
-1 siblings, 0 replies; 86+ messages in thread
From: Rob Herring @ 2014-12-30 19:28 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: Russell King, Linus Walleij, Peter Maydell,
arm-DgEjT+Ai2ygdnm+yROfE0A, Bjorn Helgaas, Rob Herring
From: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
In preparation for multi-platform support, move platform.h and
hardware.h into mach-versatile directory. Combine them into a single
file in the process.
Signed-off-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
Cc: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
arch/arm/mach-versatile/core.c | 3 +-
arch/arm/mach-versatile/include/mach/hardware.h | 32 ----------------------
.../mach-versatile/{include/mach => }/platform.h | 5 ++++
3 files changed, 6 insertions(+), 34 deletions(-)
delete mode 100644 arch/arm/mach-versatile/include/mach/hardware.h
rename arch/arm/mach-versatile/{include/mach => }/platform.h (98%)
diff --git a/arch/arm/mach-versatile/core.c b/arch/arm/mach-versatile/core.c
index 566a946..f6b122b 100644
--- a/arch/arm/mach-versatile/core.c
+++ b/arch/arm/mach-versatile/core.c
@@ -34,8 +34,7 @@
#include <asm/mach/arch.h>
#include <asm/mach/map.h>
-#include <mach/hardware.h>
-#include <mach/platform.h>
+#include "platform.h"
#include "core.h"
diff --git a/arch/arm/mach-versatile/include/mach/hardware.h b/arch/arm/mach-versatile/include/mach/hardware.h
deleted file mode 100644
index 22a1158..0000000
--- a/arch/arm/mach-versatile/include/mach/hardware.h
+++ /dev/null
@@ -1,32 +0,0 @@
-/*
- * arch/arm/mach-versatile/include/mach/hardware.h
- *
- * This file contains the hardware definitions of the Versatile boards.
- *
- * Copyright (C) 2003 ARM Limited.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
- */
-#ifndef __ASM_ARCH_HARDWARE_H
-#define __ASM_ARCH_HARDWARE_H
-
-#include <asm/sizes.h>
-
-/* macro to get at MMIO space when running virtually */
-#define IO_ADDRESS(x) (((x) & 0x0fffffff) + (((x) >> 4) & 0x0f000000) + 0xf0000000)
-
-#define __io_address(n) ((void __iomem __force *)IO_ADDRESS(n))
-
-#endif
diff --git a/arch/arm/mach-versatile/include/mach/platform.h b/arch/arm/mach-versatile/platform.h
similarity index 98%
rename from arch/arm/mach-versatile/include/mach/platform.h
rename to arch/arm/mach-versatile/platform.h
index 7fe008b..05deec2 100644
--- a/arch/arm/mach-versatile/include/mach/platform.h
+++ b/arch/arm/mach-versatile/platform.h
@@ -21,6 +21,11 @@
#ifndef __address_h
#define __address_h 1
+/* macro to get at MMIO space when running virtually */
+#define IO_ADDRESS(x) (((x) & 0x0fffffff) + (((x) >> 4) & 0x0f000000) + 0xf0000000)
+
+#define __io_address(n) ((void __iomem __force *)IO_ADDRESS(n))
+
/*
* Memory definitions
*/
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 86+ messages in thread
* [PATCH 7/9] ARM: versatile: move mach includes into mach directory
@ 2014-12-30 19:28 ` Rob Herring
0 siblings, 0 replies; 86+ messages in thread
From: Rob Herring @ 2014-12-30 19:28 UTC (permalink / raw)
To: linux-arm-kernel
From: Rob Herring <robh@kernel.org>
In preparation for multi-platform support, move platform.h and
hardware.h into mach-versatile directory. Combine them into a single
file in the process.
Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Linus Walleij <linus.walleij@linaro.org>
---
arch/arm/mach-versatile/core.c | 3 +-
arch/arm/mach-versatile/include/mach/hardware.h | 32 ----------------------
.../mach-versatile/{include/mach => }/platform.h | 5 ++++
3 files changed, 6 insertions(+), 34 deletions(-)
delete mode 100644 arch/arm/mach-versatile/include/mach/hardware.h
rename arch/arm/mach-versatile/{include/mach => }/platform.h (98%)
diff --git a/arch/arm/mach-versatile/core.c b/arch/arm/mach-versatile/core.c
index 566a946..f6b122b 100644
--- a/arch/arm/mach-versatile/core.c
+++ b/arch/arm/mach-versatile/core.c
@@ -34,8 +34,7 @@
#include <asm/mach/arch.h>
#include <asm/mach/map.h>
-#include <mach/hardware.h>
-#include <mach/platform.h>
+#include "platform.h"
#include "core.h"
diff --git a/arch/arm/mach-versatile/include/mach/hardware.h b/arch/arm/mach-versatile/include/mach/hardware.h
deleted file mode 100644
index 22a1158..0000000
--- a/arch/arm/mach-versatile/include/mach/hardware.h
+++ /dev/null
@@ -1,32 +0,0 @@
-/*
- * arch/arm/mach-versatile/include/mach/hardware.h
- *
- * This file contains the hardware definitions of the Versatile boards.
- *
- * Copyright (C) 2003 ARM Limited.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
- */
-#ifndef __ASM_ARCH_HARDWARE_H
-#define __ASM_ARCH_HARDWARE_H
-
-#include <asm/sizes.h>
-
-/* macro to get at MMIO space when running virtually */
-#define IO_ADDRESS(x) (((x) & 0x0fffffff) + (((x) >> 4) & 0x0f000000) + 0xf0000000)
-
-#define __io_address(n) ((void __iomem __force *)IO_ADDRESS(n))
-
-#endif
diff --git a/arch/arm/mach-versatile/include/mach/platform.h b/arch/arm/mach-versatile/platform.h
similarity index 98%
rename from arch/arm/mach-versatile/include/mach/platform.h
rename to arch/arm/mach-versatile/platform.h
index 7fe008b..05deec2 100644
--- a/arch/arm/mach-versatile/include/mach/platform.h
+++ b/arch/arm/mach-versatile/platform.h
@@ -21,6 +21,11 @@
#ifndef __address_h
#define __address_h 1
+/* macro to get at MMIO space when running virtually */
+#define IO_ADDRESS(x) (((x) & 0x0fffffff) + (((x) >> 4) & 0x0f000000) + 0xf0000000)
+
+#define __io_address(n) ((void __iomem __force *)IO_ADDRESS(n))
+
/*
* Memory definitions
*/
--
2.1.0
^ permalink raw reply related [flat|nested] 86+ messages in thread
* [PATCH 8/9] ARM: versatile: convert to multi-platform
2014-12-30 19:28 ` Rob Herring
@ 2014-12-30 19:28 ` Rob Herring
-1 siblings, 0 replies; 86+ messages in thread
From: Rob Herring @ 2014-12-30 19:28 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: Russell King, Linus Walleij, Peter Maydell,
arm-DgEjT+Ai2ygdnm+yROfE0A, Bjorn Helgaas, Rob Herring
From: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Now that all the prerequisites are in place, we can enable Versatile
boards for multi-platform kernels.
Signed-off-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
Cc: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
arch/arm/Kconfig | 21 +----------
arch/arm/mach-versatile/Kconfig | 14 +++++++
arch/arm/mach-versatile/Makefile.boot | 4 --
arch/arm/mach-versatile/include/mach/uncompress.h | 45 -----------------------
4 files changed, 16 insertions(+), 68 deletions(-)
create mode 100644 arch/arm/mach-versatile/Kconfig
delete mode 100644 arch/arm/mach-versatile/Makefile.boot
delete mode 100644 arch/arm/mach-versatile/include/mach/uncompress.h
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 7816b54..4d9858f 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -337,25 +337,6 @@ config ARCH_REALVIEW
help
This enables support for ARM Ltd RealView boards.
-config ARCH_VERSATILE
- bool "ARM Ltd. Versatile family"
- select ARCH_WANT_OPTIONAL_GPIOLIB
- select ARM_AMBA
- select ARM_TIMER_SP804
- select ARM_VIC
- select CLKSRC_VERSATILE
- select COMMON_CLK
- select COMMON_CLK_VERSATILE
- select CPU_ARM926T
- select GENERIC_CLOCKEVENTS
- select ICST
- select MIGHT_HAVE_PCI
- select SPARSE_IRQ
- select USE_OF
- select VERSATILE_FPGA_IRQ
- help
- This enables support for ARM Ltd Versatile board.
-
config ARCH_AT91
bool "Atmel AT91"
select ARCH_REQUIRE_GPIOLIB
@@ -956,6 +937,8 @@ source "arch/arm/mach-u300/Kconfig"
source "arch/arm/mach-ux500/Kconfig"
+source "arch/arm/mach-versatile/Kconfig"
+
source "arch/arm/mach-vexpress/Kconfig"
source "arch/arm/plat-versatile/Kconfig"
diff --git a/arch/arm/mach-versatile/Kconfig b/arch/arm/mach-versatile/Kconfig
new file mode 100644
index 0000000..1d6a8b2
--- /dev/null
+++ b/arch/arm/mach-versatile/Kconfig
@@ -0,0 +1,14 @@
+config ARCH_VERSATILE
+ bool "ARM Ltd. Versatile family" if ARCH_MULTI_V5
+ select ARM_AMBA
+ select ARM_TIMER_SP804
+ select ARM_VIC
+ select CLKSRC_VERSATILE
+ select COMMON_CLK_VERSATILE
+ select CPU_ARM926T
+ select ICST
+ select MIGHT_HAVE_PCI
+ select VERSATILE_FPGA_IRQ
+ help
+ This enables support for ARM Ltd Versatile board.
+
diff --git a/arch/arm/mach-versatile/Makefile.boot b/arch/arm/mach-versatile/Makefile.boot
deleted file mode 100644
index ff0a4b5..0000000
--- a/arch/arm/mach-versatile/Makefile.boot
+++ /dev/null
@@ -1,4 +0,0 @@
- zreladdr-y += 0x00008000
-params_phys-y := 0x00000100
-initrd_phys-y := 0x00800000
-
diff --git a/arch/arm/mach-versatile/include/mach/uncompress.h b/arch/arm/mach-versatile/include/mach/uncompress.h
deleted file mode 100644
index 986e3d3..0000000
--- a/arch/arm/mach-versatile/include/mach/uncompress.h
+++ /dev/null
@@ -1,45 +0,0 @@
-/*
- * arch/arm/mach-versatile/include/mach/uncompress.h
- *
- * Copyright (C) 2003 ARM Limited
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
- */
-#define AMBA_UART_DR (*(volatile unsigned char *)0x101F1000)
-#define AMBA_UART_LCRH (*(volatile unsigned char *)0x101F102C)
-#define AMBA_UART_CR (*(volatile unsigned char *)0x101F1030)
-#define AMBA_UART_FR (*(volatile unsigned char *)0x101F1018)
-
-/*
- * This does not append a newline
- */
-static inline void putc(int c)
-{
- while (AMBA_UART_FR & (1 << 5))
- barrier();
-
- AMBA_UART_DR = c;
-}
-
-static inline void flush(void)
-{
- while (AMBA_UART_FR & (1 << 3))
- barrier();
-}
-
-/*
- * nothing to do
- */
-#define arch_decomp_setup()
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 86+ messages in thread
* [PATCH 8/9] ARM: versatile: convert to multi-platform
@ 2014-12-30 19:28 ` Rob Herring
0 siblings, 0 replies; 86+ messages in thread
From: Rob Herring @ 2014-12-30 19:28 UTC (permalink / raw)
To: linux-arm-kernel
From: Rob Herring <robh@kernel.org>
Now that all the prerequisites are in place, we can enable Versatile
boards for multi-platform kernels.
Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Linus Walleij <linus.walleij@linaro.org>
---
arch/arm/Kconfig | 21 +----------
arch/arm/mach-versatile/Kconfig | 14 +++++++
arch/arm/mach-versatile/Makefile.boot | 4 --
arch/arm/mach-versatile/include/mach/uncompress.h | 45 -----------------------
4 files changed, 16 insertions(+), 68 deletions(-)
create mode 100644 arch/arm/mach-versatile/Kconfig
delete mode 100644 arch/arm/mach-versatile/Makefile.boot
delete mode 100644 arch/arm/mach-versatile/include/mach/uncompress.h
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 7816b54..4d9858f 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -337,25 +337,6 @@ config ARCH_REALVIEW
help
This enables support for ARM Ltd RealView boards.
-config ARCH_VERSATILE
- bool "ARM Ltd. Versatile family"
- select ARCH_WANT_OPTIONAL_GPIOLIB
- select ARM_AMBA
- select ARM_TIMER_SP804
- select ARM_VIC
- select CLKSRC_VERSATILE
- select COMMON_CLK
- select COMMON_CLK_VERSATILE
- select CPU_ARM926T
- select GENERIC_CLOCKEVENTS
- select ICST
- select MIGHT_HAVE_PCI
- select SPARSE_IRQ
- select USE_OF
- select VERSATILE_FPGA_IRQ
- help
- This enables support for ARM Ltd Versatile board.
-
config ARCH_AT91
bool "Atmel AT91"
select ARCH_REQUIRE_GPIOLIB
@@ -956,6 +937,8 @@ source "arch/arm/mach-u300/Kconfig"
source "arch/arm/mach-ux500/Kconfig"
+source "arch/arm/mach-versatile/Kconfig"
+
source "arch/arm/mach-vexpress/Kconfig"
source "arch/arm/plat-versatile/Kconfig"
diff --git a/arch/arm/mach-versatile/Kconfig b/arch/arm/mach-versatile/Kconfig
new file mode 100644
index 0000000..1d6a8b2
--- /dev/null
+++ b/arch/arm/mach-versatile/Kconfig
@@ -0,0 +1,14 @@
+config ARCH_VERSATILE
+ bool "ARM Ltd. Versatile family" if ARCH_MULTI_V5
+ select ARM_AMBA
+ select ARM_TIMER_SP804
+ select ARM_VIC
+ select CLKSRC_VERSATILE
+ select COMMON_CLK_VERSATILE
+ select CPU_ARM926T
+ select ICST
+ select MIGHT_HAVE_PCI
+ select VERSATILE_FPGA_IRQ
+ help
+ This enables support for ARM Ltd Versatile board.
+
diff --git a/arch/arm/mach-versatile/Makefile.boot b/arch/arm/mach-versatile/Makefile.boot
deleted file mode 100644
index ff0a4b5..0000000
--- a/arch/arm/mach-versatile/Makefile.boot
+++ /dev/null
@@ -1,4 +0,0 @@
- zreladdr-y += 0x00008000
-params_phys-y := 0x00000100
-initrd_phys-y := 0x00800000
-
diff --git a/arch/arm/mach-versatile/include/mach/uncompress.h b/arch/arm/mach-versatile/include/mach/uncompress.h
deleted file mode 100644
index 986e3d3..0000000
--- a/arch/arm/mach-versatile/include/mach/uncompress.h
+++ /dev/null
@@ -1,45 +0,0 @@
-/*
- * arch/arm/mach-versatile/include/mach/uncompress.h
- *
- * Copyright (C) 2003 ARM Limited
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
- */
-#define AMBA_UART_DR (*(volatile unsigned char *)0x101F1000)
-#define AMBA_UART_LCRH (*(volatile unsigned char *)0x101F102C)
-#define AMBA_UART_CR (*(volatile unsigned char *)0x101F1030)
-#define AMBA_UART_FR (*(volatile unsigned char *)0x101F1018)
-
-/*
- * This does not append a newline
- */
-static inline void putc(int c)
-{
- while (AMBA_UART_FR & (1 << 5))
- barrier();
-
- AMBA_UART_DR = c;
-}
-
-static inline void flush(void)
-{
- while (AMBA_UART_FR & (1 << 3))
- barrier();
-}
-
-/*
- * nothing to do
- */
-#define arch_decomp_setup()
--
2.1.0
^ permalink raw reply related [flat|nested] 86+ messages in thread
* [PATCH 9/9] ARM: versatile: consolidate code to single file
2014-12-30 19:28 ` Rob Herring
@ 2014-12-30 19:28 ` Rob Herring
-1 siblings, 0 replies; 86+ messages in thread
From: Rob Herring @ 2014-12-30 19:28 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: Russell King, Linus Walleij, Peter Maydell,
arm-DgEjT+Ai2ygdnm+yROfE0A, Bjorn Helgaas, Rob Herring
From: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
The split of core.c and versatile_dt.c now makes little sense, so move
all of core.c into versatile_dt.c.
Signed-off-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
Cc: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
arch/arm/mach-versatile/Makefile | 2 +-
arch/arm/mach-versatile/core.c | 324 ---------------------------------
arch/arm/mach-versatile/core.h | 41 -----
arch/arm/mach-versatile/versatile_dt.c | 291 ++++++++++++++++++++++++++++-
4 files changed, 291 insertions(+), 367 deletions(-)
delete mode 100644 arch/arm/mach-versatile/core.c
delete mode 100644 arch/arm/mach-versatile/core.h
diff --git a/arch/arm/mach-versatile/Makefile b/arch/arm/mach-versatile/Makefile
index ccef512..41b124b 100644
--- a/arch/arm/mach-versatile/Makefile
+++ b/arch/arm/mach-versatile/Makefile
@@ -2,4 +2,4 @@
# Makefile for the linux kernel.
#
-obj-y := core.o versatile_dt.o
+obj-y := versatile_dt.o
diff --git a/arch/arm/mach-versatile/core.c b/arch/arm/mach-versatile/core.c
deleted file mode 100644
index f6b122b..0000000
--- a/arch/arm/mach-versatile/core.c
+++ /dev/null
@@ -1,324 +0,0 @@
-/*
- * linux/arch/arm/mach-versatile/core.c
- *
- * Copyright (C) 1999 - 2003 ARM Limited
- * Copyright (C) 2000 Deep Blue Solutions Ltd
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
- */
-#include <linux/init.h>
-#include <linux/device.h>
-#include <linux/dma-mapping.h>
-#include <linux/platform_device.h>
-#include <linux/interrupt.h>
-#include <linux/of_platform.h>
-#include <linux/amba/bus.h>
-#include <linux/amba/clcd.h>
-#include <linux/platform_data/video-clcd-versatile.h>
-#include <linux/amba/mmci.h>
-#include <linux/io.h>
-#include <linux/mtd/physmap.h>
-#include <linux/reboot.h>
-
-#include <asm/mach/arch.h>
-#include <asm/mach/map.h>
-#include "platform.h"
-
-#include "core.h"
-
-static struct map_desc versatile_io_desc[] __initdata __maybe_unused = {
- {
- .virtual = IO_ADDRESS(VERSATILE_SYS_BASE),
- .pfn = __phys_to_pfn(VERSATILE_SYS_BASE),
- .length = SZ_4K,
- .type = MT_DEVICE
- }, {
- .virtual = IO_ADDRESS(VERSATILE_SCTL_BASE),
- .pfn = __phys_to_pfn(VERSATILE_SCTL_BASE),
- .length = SZ_4K * 9,
- .type = MT_DEVICE
- },
-};
-
-void __init versatile_map_io(void)
-{
- debug_ll_io_init();
- iotable_init(versatile_io_desc, ARRAY_SIZE(versatile_io_desc));
-}
-
-
-#define VERSATILE_FLASHCTRL (__io_address(VERSATILE_SYS_BASE) + VERSATILE_SYS_FLASH_OFFSET)
-
-static void versatile_flash_set_vpp(struct platform_device *pdev, int on)
-{
- u32 val;
-
- val = __raw_readl(VERSATILE_FLASHCTRL);
- if (on)
- val |= VERSATILE_FLASHPROG_FLVPPEN;
- else
- val &= ~VERSATILE_FLASHPROG_FLVPPEN;
- __raw_writel(val, VERSATILE_FLASHCTRL);
-}
-
-static struct physmap_flash_data versatile_flash_data = {
- .width = 4,
- .set_vpp = versatile_flash_set_vpp,
-};
-
-static struct resource versatile_flash_resource = {
- .start = VERSATILE_FLASH_BASE,
- .end = VERSATILE_FLASH_BASE + VERSATILE_FLASH_SIZE - 1,
- .flags = IORESOURCE_MEM,
-};
-
-struct platform_device versatile_flash_device = {
- .name = "physmap-flash",
- .id = 0,
- .dev = {
- .platform_data = &versatile_flash_data,
- },
- .num_resources = 1,
- .resource = &versatile_flash_resource,
-};
-
-#define VERSATILE_SYSMCI (__io_address(VERSATILE_SYS_BASE) + VERSATILE_SYS_MCI_OFFSET)
-
-unsigned int mmc_status(struct device *dev)
-{
- struct amba_device *adev = container_of(dev, struct amba_device, dev);
- u32 mask;
-
- if (adev->res.start == VERSATILE_MMCI0_BASE)
- mask = 1;
- else
- mask = 2;
-
- return readl(VERSATILE_SYSMCI) & mask;
-}
-
-static struct mmci_platform_data mmc0_plat_data = {
- .ocr_mask = MMC_VDD_32_33|MMC_VDD_33_34,
- .status = mmc_status,
- .gpio_wp = -1,
- .gpio_cd = -1,
-};
-
-static struct mmci_platform_data mmc1_plat_data = {
- .ocr_mask = MMC_VDD_32_33|MMC_VDD_33_34,
- .status = mmc_status,
- .gpio_wp = -1,
- .gpio_cd = -1,
-};
-
-/*
- * CLCD support.
- */
-#define SYS_CLCD_MODE_MASK (3 << 0)
-#define SYS_CLCD_MODE_888 (0 << 0)
-#define SYS_CLCD_MODE_5551 (1 << 0)
-#define SYS_CLCD_MODE_565_RLSB (2 << 0)
-#define SYS_CLCD_MODE_565_BLSB (3 << 0)
-#define SYS_CLCD_NLCDIOON (1 << 2)
-#define SYS_CLCD_VDDPOSSWITCH (1 << 3)
-#define SYS_CLCD_PWR3V5SWITCH (1 << 4)
-#define SYS_CLCD_ID_MASK (0x1f << 8)
-#define SYS_CLCD_ID_SANYO_3_8 (0x00 << 8)
-#define SYS_CLCD_ID_UNKNOWN_8_4 (0x01 << 8)
-#define SYS_CLCD_ID_EPSON_2_2 (0x02 << 8)
-#define SYS_CLCD_ID_SANYO_2_5 (0x07 << 8)
-#define SYS_CLCD_ID_VGA (0x1f << 8)
-
-static bool is_sanyo_2_5_lcd;
-
-/*
- * Disable all display connectors on the interface module.
- */
-static void versatile_clcd_disable(struct clcd_fb *fb)
-{
- void __iomem *sys_clcd = __io_address(VERSATILE_SYS_BASE) + VERSATILE_SYS_CLCD_OFFSET;
- u32 val;
-
- val = readl(sys_clcd);
- val &= ~SYS_CLCD_NLCDIOON | SYS_CLCD_PWR3V5SWITCH;
- writel(val, sys_clcd);
-
- /*
- * If the LCD is Sanyo 2x5 in on the IB2 board, turn the back-light off
- */
- if (of_machine_is_compatible("arm,versatile-ab") && is_sanyo_2_5_lcd) {
- void __iomem *versatile_ib2_ctrl = __io_address(VERSATILE_IB2_CTRL);
- unsigned long ctrl;
-
- ctrl = readl(versatile_ib2_ctrl);
- ctrl &= ~0x01;
- writel(ctrl, versatile_ib2_ctrl);
- }
-}
-
-/*
- * Enable the relevant connector on the interface module.
- */
-static void versatile_clcd_enable(struct clcd_fb *fb)
-{
- struct fb_var_screeninfo *var = &fb->fb.var;
- void __iomem *sys_clcd = __io_address(VERSATILE_SYS_BASE) + VERSATILE_SYS_CLCD_OFFSET;
- u32 val;
-
- val = readl(sys_clcd);
- val &= ~SYS_CLCD_MODE_MASK;
-
- switch (var->green.length) {
- case 5:
- val |= SYS_CLCD_MODE_5551;
- break;
- case 6:
- if (var->red.offset == 0)
- val |= SYS_CLCD_MODE_565_RLSB;
- else
- val |= SYS_CLCD_MODE_565_BLSB;
- break;
- case 8:
- val |= SYS_CLCD_MODE_888;
- break;
- }
-
- /*
- * Set the MUX
- */
- writel(val, sys_clcd);
-
- /*
- * And now enable the PSUs
- */
- val |= SYS_CLCD_NLCDIOON | SYS_CLCD_PWR3V5SWITCH;
- writel(val, sys_clcd);
-
- /*
- * If the LCD is Sanyo 2x5 in on the IB2 board, turn the back-light on
- */
- if (of_machine_is_compatible("arm,versatile-ab") && is_sanyo_2_5_lcd) {
- void __iomem *versatile_ib2_ctrl = __io_address(VERSATILE_IB2_CTRL);
- unsigned long ctrl;
-
- ctrl = readl(versatile_ib2_ctrl);
- ctrl |= 0x01;
- writel(ctrl, versatile_ib2_ctrl);
- }
-}
-
-/*
- * Detect which LCD panel is connected, and return the appropriate
- * clcd_panel structure. Note: we do not have any information on
- * the required timings for the 8.4in panel, so we presently assume
- * VGA timings.
- */
-static int versatile_clcd_setup(struct clcd_fb *fb)
-{
- void __iomem *sys_clcd = __io_address(VERSATILE_SYS_BASE) + VERSATILE_SYS_CLCD_OFFSET;
- const char *panel_name;
- u32 val;
-
- is_sanyo_2_5_lcd = false;
-
- val = readl(sys_clcd) & SYS_CLCD_ID_MASK;
- if (val == SYS_CLCD_ID_SANYO_3_8)
- panel_name = "Sanyo TM38QV67A02A";
- else if (val == SYS_CLCD_ID_SANYO_2_5) {
- panel_name = "Sanyo QVGA Portrait";
- is_sanyo_2_5_lcd = true;
- } else if (val == SYS_CLCD_ID_EPSON_2_2)
- panel_name = "Epson L2F50113T00";
- else if (val == SYS_CLCD_ID_VGA)
- panel_name = "VGA";
- else {
- printk(KERN_ERR "CLCD: unknown LCD panel ID 0x%08x, using VGA\n",
- val);
- panel_name = "VGA";
- }
-
- fb->panel = versatile_clcd_get_panel(panel_name);
- if (!fb->panel)
- return -EINVAL;
-
- return versatile_clcd_setup_dma(fb, SZ_1M);
-}
-
-static void versatile_clcd_decode(struct clcd_fb *fb, struct clcd_regs *regs)
-{
- clcdfb_decode(fb, regs);
-
- /* Always clear BGR for RGB565: we do the routing externally */
- if (fb->fb.var.green.length == 6)
- regs->cntl &= ~CNTL_BGR;
-}
-
-static struct clcd_board clcd_plat_data = {
- .name = "Versatile",
- .caps = CLCD_CAP_5551 | CLCD_CAP_565 | CLCD_CAP_888,
- .check = clcdfb_check,
- .decode = versatile_clcd_decode,
- .disable = versatile_clcd_disable,
- .enable = versatile_clcd_enable,
- .setup = versatile_clcd_setup,
- .mmap = versatile_clcd_mmap_dma,
- .remove = versatile_clcd_remove_dma,
-};
-
-/*
- * Lookup table for attaching a specific name and platform_data pointer to
- * devices as they get created by of_platform_populate(). Ideally this table
- * would not exist, but the current clock implementation depends on some devices
- * having a specific name.
- */
-struct of_dev_auxdata versatile_auxdata_lookup[] __initdata = {
- OF_DEV_AUXDATA("arm,primecell", VERSATILE_MMCI0_BASE, "fpga:05", &mmc0_plat_data),
- OF_DEV_AUXDATA("arm,primecell", VERSATILE_MMCI1_BASE, "fpga:0b", &mmc1_plat_data),
-
- OF_DEV_AUXDATA("arm,primecell", VERSATILE_CLCD_BASE, "dev:20", &clcd_plat_data),
-
- {}
-};
-
-void versatile_restart(enum reboot_mode mode, const char *cmd)
-{
- void __iomem *sys = __io_address(VERSATILE_SYS_BASE);
- u32 val;
-
- val = __raw_readl(sys + VERSATILE_SYS_RESETCTL_OFFSET);
- val |= 0x105;
-
- __raw_writel(0xa05f, sys + VERSATILE_SYS_LOCK_OFFSET);
- __raw_writel(val, sys + VERSATILE_SYS_RESETCTL_OFFSET);
- __raw_writel(0, sys + VERSATILE_SYS_LOCK_OFFSET);
-}
-
-/* Early initializations */
-void __init versatile_init_early(void)
-{
- u32 val;
-
- /*
- * set clock frequency:
- * VERSATILE_REFCLK is 32KHz
- * VERSATILE_TIMCLK is 1MHz
- */
- val = readl(__io_address(VERSATILE_SCTL_BASE));
- writel((VERSATILE_TIMCLK << VERSATILE_TIMER1_EnSel) |
- (VERSATILE_TIMCLK << VERSATILE_TIMER2_EnSel) |
- (VERSATILE_TIMCLK << VERSATILE_TIMER3_EnSel) |
- (VERSATILE_TIMCLK << VERSATILE_TIMER4_EnSel) | val,
- __io_address(VERSATILE_SCTL_BASE));
-}
diff --git a/arch/arm/mach-versatile/core.h b/arch/arm/mach-versatile/core.h
deleted file mode 100644
index c3d7157..0000000
--- a/arch/arm/mach-versatile/core.h
+++ /dev/null
@@ -1,41 +0,0 @@
-/*
- * linux/arch/arm/mach-versatile/core.h
- *
- * Copyright (C) 2004 ARM Limited
- * Copyright (C) 2000 Deep Blue Solutions Ltd
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
- */
-
-#ifndef __ASM_ARCH_VERSATILE_H
-#define __ASM_ARCH_VERSATILE_H
-
-#include <linux/amba/bus.h>
-#include <linux/of_platform.h>
-#include <linux/reboot.h>
-
-extern struct platform_device versatile_flash_device;
-
-extern void __init versatile_init_early(void);
-extern void __init versatile_init_irq(void);
-extern void __init versatile_map_io(void);
-extern void versatile_timer_init(void);
-extern void versatile_restart(enum reboot_mode, const char *);
-extern unsigned int mmc_status(struct device *dev);
-#ifdef CONFIG_OF
-extern struct of_dev_auxdata versatile_auxdata_lookup[];
-#endif
-
-#endif
diff --git a/arch/arm/mach-versatile/versatile_dt.c b/arch/arm/mach-versatile/versatile_dt.c
index 1bb21d1..9b0d392 100644
--- a/arch/arm/mach-versatile/versatile_dt.c
+++ b/arch/arm/mach-versatile/versatile_dt.c
@@ -28,13 +28,302 @@
#include <linux/of_irq.h>
#include <linux/of_platform.h>
#include <linux/slab.h>
+#include <linux/amba/bus.h>
+#include <linux/amba/clcd.h>
+#include <linux/platform_data/video-clcd-versatile.h>
+#include <linux/amba/mmci.h>
+#include <linux/mtd/physmap.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
+#include <asm/mach/map.h>
-#include "core.h"
+#include "platform.h"
#define VERSATILE_SYS_PCICTL_OFFSET 0x44
+#define VERSATILE_FLASHCTRL (__io_address(VERSATILE_SYS_BASE) + VERSATILE_SYS_FLASH_OFFSET)
+
+static void versatile_flash_set_vpp(struct platform_device *pdev, int on)
+{
+ u32 val;
+
+ val = __raw_readl(VERSATILE_FLASHCTRL);
+ if (on)
+ val |= VERSATILE_FLASHPROG_FLVPPEN;
+ else
+ val &= ~VERSATILE_FLASHPROG_FLVPPEN;
+ __raw_writel(val, VERSATILE_FLASHCTRL);
+}
+
+static struct physmap_flash_data versatile_flash_data = {
+ .width = 4,
+ .set_vpp = versatile_flash_set_vpp,
+};
+
+static struct resource versatile_flash_resource = {
+ .start = VERSATILE_FLASH_BASE,
+ .end = VERSATILE_FLASH_BASE + VERSATILE_FLASH_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+};
+
+struct platform_device versatile_flash_device = {
+ .name = "physmap-flash",
+ .id = 0,
+ .dev = {
+ .platform_data = &versatile_flash_data,
+ },
+ .num_resources = 1,
+ .resource = &versatile_flash_resource,
+};
+
+#define VERSATILE_SYSMCI (__io_address(VERSATILE_SYS_BASE) + VERSATILE_SYS_MCI_OFFSET)
+
+unsigned int mmc_status(struct device *dev)
+{
+ struct amba_device *adev = container_of(dev, struct amba_device, dev);
+ u32 mask;
+
+ if (adev->res.start == VERSATILE_MMCI0_BASE)
+ mask = 1;
+ else
+ mask = 2;
+
+ return readl(VERSATILE_SYSMCI) & mask;
+}
+
+static struct mmci_platform_data mmc0_plat_data = {
+ .ocr_mask = MMC_VDD_32_33|MMC_VDD_33_34,
+ .status = mmc_status,
+ .gpio_wp = -1,
+ .gpio_cd = -1,
+};
+
+static struct mmci_platform_data mmc1_plat_data = {
+ .ocr_mask = MMC_VDD_32_33|MMC_VDD_33_34,
+ .status = mmc_status,
+ .gpio_wp = -1,
+ .gpio_cd = -1,
+};
+
+/*
+ * CLCD support.
+ */
+#define SYS_CLCD_MODE_MASK (3 << 0)
+#define SYS_CLCD_MODE_888 (0 << 0)
+#define SYS_CLCD_MODE_5551 (1 << 0)
+#define SYS_CLCD_MODE_565_RLSB (2 << 0)
+#define SYS_CLCD_MODE_565_BLSB (3 << 0)
+#define SYS_CLCD_NLCDIOON (1 << 2)
+#define SYS_CLCD_VDDPOSSWITCH (1 << 3)
+#define SYS_CLCD_PWR3V5SWITCH (1 << 4)
+#define SYS_CLCD_ID_MASK (0x1f << 8)
+#define SYS_CLCD_ID_SANYO_3_8 (0x00 << 8)
+#define SYS_CLCD_ID_UNKNOWN_8_4 (0x01 << 8)
+#define SYS_CLCD_ID_EPSON_2_2 (0x02 << 8)
+#define SYS_CLCD_ID_SANYO_2_5 (0x07 << 8)
+#define SYS_CLCD_ID_VGA (0x1f << 8)
+
+static bool is_sanyo_2_5_lcd;
+
+/*
+ * Disable all display connectors on the interface module.
+ */
+static void versatile_clcd_disable(struct clcd_fb *fb)
+{
+ void __iomem *sys_clcd = __io_address(VERSATILE_SYS_BASE) + VERSATILE_SYS_CLCD_OFFSET;
+ u32 val;
+
+ val = readl(sys_clcd);
+ val &= ~SYS_CLCD_NLCDIOON | SYS_CLCD_PWR3V5SWITCH;
+ writel(val, sys_clcd);
+
+ /*
+ * If the LCD is Sanyo 2x5 in on the IB2 board, turn the back-light off
+ */
+ if (of_machine_is_compatible("arm,versatile-ab") && is_sanyo_2_5_lcd) {
+ void __iomem *versatile_ib2_ctrl = __io_address(VERSATILE_IB2_CTRL);
+ unsigned long ctrl;
+
+ ctrl = readl(versatile_ib2_ctrl);
+ ctrl &= ~0x01;
+ writel(ctrl, versatile_ib2_ctrl);
+ }
+}
+
+/*
+ * Enable the relevant connector on the interface module.
+ */
+static void versatile_clcd_enable(struct clcd_fb *fb)
+{
+ struct fb_var_screeninfo *var = &fb->fb.var;
+ void __iomem *sys_clcd = __io_address(VERSATILE_SYS_BASE) + VERSATILE_SYS_CLCD_OFFSET;
+ u32 val;
+
+ val = readl(sys_clcd);
+ val &= ~SYS_CLCD_MODE_MASK;
+
+ switch (var->green.length) {
+ case 5:
+ val |= SYS_CLCD_MODE_5551;
+ break;
+ case 6:
+ if (var->red.offset == 0)
+ val |= SYS_CLCD_MODE_565_RLSB;
+ else
+ val |= SYS_CLCD_MODE_565_BLSB;
+ break;
+ case 8:
+ val |= SYS_CLCD_MODE_888;
+ break;
+ }
+
+ /*
+ * Set the MUX
+ */
+ writel(val, sys_clcd);
+
+ /*
+ * And now enable the PSUs
+ */
+ val |= SYS_CLCD_NLCDIOON | SYS_CLCD_PWR3V5SWITCH;
+ writel(val, sys_clcd);
+
+ /*
+ * If the LCD is Sanyo 2x5 in on the IB2 board, turn the back-light on
+ */
+ if (of_machine_is_compatible("arm,versatile-ab") && is_sanyo_2_5_lcd) {
+ void __iomem *versatile_ib2_ctrl = __io_address(VERSATILE_IB2_CTRL);
+ unsigned long ctrl;
+
+ ctrl = readl(versatile_ib2_ctrl);
+ ctrl |= 0x01;
+ writel(ctrl, versatile_ib2_ctrl);
+ }
+}
+
+/*
+ * Detect which LCD panel is connected, and return the appropriate
+ * clcd_panel structure. Note: we do not have any information on
+ * the required timings for the 8.4in panel, so we presently assume
+ * VGA timings.
+ */
+static int versatile_clcd_setup(struct clcd_fb *fb)
+{
+ void __iomem *sys_clcd = __io_address(VERSATILE_SYS_BASE) + VERSATILE_SYS_CLCD_OFFSET;
+ const char *panel_name;
+ u32 val;
+
+ is_sanyo_2_5_lcd = false;
+
+ val = readl(sys_clcd) & SYS_CLCD_ID_MASK;
+ if (val == SYS_CLCD_ID_SANYO_3_8)
+ panel_name = "Sanyo TM38QV67A02A";
+ else if (val == SYS_CLCD_ID_SANYO_2_5) {
+ panel_name = "Sanyo QVGA Portrait";
+ is_sanyo_2_5_lcd = true;
+ } else if (val == SYS_CLCD_ID_EPSON_2_2)
+ panel_name = "Epson L2F50113T00";
+ else if (val == SYS_CLCD_ID_VGA)
+ panel_name = "VGA";
+ else {
+ printk(KERN_ERR "CLCD: unknown LCD panel ID 0x%08x, using VGA\n",
+ val);
+ panel_name = "VGA";
+ }
+
+ fb->panel = versatile_clcd_get_panel(panel_name);
+ if (!fb->panel)
+ return -EINVAL;
+
+ return versatile_clcd_setup_dma(fb, SZ_1M);
+}
+
+static void versatile_clcd_decode(struct clcd_fb *fb, struct clcd_regs *regs)
+{
+ clcdfb_decode(fb, regs);
+
+ /* Always clear BGR for RGB565: we do the routing externally */
+ if (fb->fb.var.green.length == 6)
+ regs->cntl &= ~CNTL_BGR;
+}
+
+static struct clcd_board clcd_plat_data = {
+ .name = "Versatile",
+ .caps = CLCD_CAP_5551 | CLCD_CAP_565 | CLCD_CAP_888,
+ .check = clcdfb_check,
+ .decode = versatile_clcd_decode,
+ .disable = versatile_clcd_disable,
+ .enable = versatile_clcd_enable,
+ .setup = versatile_clcd_setup,
+ .mmap = versatile_clcd_mmap_dma,
+ .remove = versatile_clcd_remove_dma,
+};
+
+/*
+ * Lookup table for attaching a specific name and platform_data pointer to
+ * devices as they get created by of_platform_populate(). Ideally this table
+ * would not exist, but the current clock implementation depends on some devices
+ * having a specific name.
+ */
+struct of_dev_auxdata versatile_auxdata_lookup[] __initdata = {
+ OF_DEV_AUXDATA("arm,primecell", VERSATILE_MMCI0_BASE, "fpga:05", &mmc0_plat_data),
+ OF_DEV_AUXDATA("arm,primecell", VERSATILE_MMCI1_BASE, "fpga:0b", &mmc1_plat_data),
+
+ OF_DEV_AUXDATA("arm,primecell", VERSATILE_CLCD_BASE, "dev:20", &clcd_plat_data),
+
+ {}
+};
+
+static struct map_desc versatile_io_desc[] __initdata __maybe_unused = {
+ {
+ .virtual = IO_ADDRESS(VERSATILE_SYS_BASE),
+ .pfn = __phys_to_pfn(VERSATILE_SYS_BASE),
+ .length = SZ_4K,
+ .type = MT_DEVICE
+ }, {
+ .virtual = IO_ADDRESS(VERSATILE_SCTL_BASE),
+ .pfn = __phys_to_pfn(VERSATILE_SCTL_BASE),
+ .length = SZ_4K * 9,
+ .type = MT_DEVICE
+ },
+};
+
+static void __init versatile_map_io(void)
+{
+ debug_ll_io_init();
+ iotable_init(versatile_io_desc, ARRAY_SIZE(versatile_io_desc));
+}
+
+static void __init versatile_init_early(void)
+{
+ u32 val;
+
+ /*
+ * set clock frequency:
+ * VERSATILE_REFCLK is 32KHz
+ * VERSATILE_TIMCLK is 1MHz
+ */
+ val = readl(__io_address(VERSATILE_SCTL_BASE));
+ writel((VERSATILE_TIMCLK << VERSATILE_TIMER1_EnSel) |
+ (VERSATILE_TIMCLK << VERSATILE_TIMER2_EnSel) |
+ (VERSATILE_TIMCLK << VERSATILE_TIMER3_EnSel) |
+ (VERSATILE_TIMCLK << VERSATILE_TIMER4_EnSel) | val,
+ __io_address(VERSATILE_SCTL_BASE));
+}
+
+static void versatile_restart(enum reboot_mode mode, const char *cmd)
+{
+ void __iomem *sys = __io_address(VERSATILE_SYS_BASE);
+ u32 val;
+
+ val = __raw_readl(sys + VERSATILE_SYS_RESETCTL_OFFSET);
+ val |= 0x105;
+
+ __raw_writel(0xa05f, sys + VERSATILE_SYS_LOCK_OFFSET);
+ __raw_writel(val, sys + VERSATILE_SYS_RESETCTL_OFFSET);
+ __raw_writel(0, sys + VERSATILE_SYS_LOCK_OFFSET);
+}
+
static void __init versatile_dt_pci_init(void)
{
u32 val;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 86+ messages in thread
* [PATCH 9/9] ARM: versatile: consolidate code to single file
@ 2014-12-30 19:28 ` Rob Herring
0 siblings, 0 replies; 86+ messages in thread
From: Rob Herring @ 2014-12-30 19:28 UTC (permalink / raw)
To: linux-arm-kernel
From: Rob Herring <robh@kernel.org>
The split of core.c and versatile_dt.c now makes little sense, so move
all of core.c into versatile_dt.c.
Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Linus Walleij <linus.walleij@linaro.org>
---
arch/arm/mach-versatile/Makefile | 2 +-
arch/arm/mach-versatile/core.c | 324 ---------------------------------
arch/arm/mach-versatile/core.h | 41 -----
arch/arm/mach-versatile/versatile_dt.c | 291 ++++++++++++++++++++++++++++-
4 files changed, 291 insertions(+), 367 deletions(-)
delete mode 100644 arch/arm/mach-versatile/core.c
delete mode 100644 arch/arm/mach-versatile/core.h
diff --git a/arch/arm/mach-versatile/Makefile b/arch/arm/mach-versatile/Makefile
index ccef512..41b124b 100644
--- a/arch/arm/mach-versatile/Makefile
+++ b/arch/arm/mach-versatile/Makefile
@@ -2,4 +2,4 @@
# Makefile for the linux kernel.
#
-obj-y := core.o versatile_dt.o
+obj-y := versatile_dt.o
diff --git a/arch/arm/mach-versatile/core.c b/arch/arm/mach-versatile/core.c
deleted file mode 100644
index f6b122b..0000000
--- a/arch/arm/mach-versatile/core.c
+++ /dev/null
@@ -1,324 +0,0 @@
-/*
- * linux/arch/arm/mach-versatile/core.c
- *
- * Copyright (C) 1999 - 2003 ARM Limited
- * Copyright (C) 2000 Deep Blue Solutions Ltd
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
- */
-#include <linux/init.h>
-#include <linux/device.h>
-#include <linux/dma-mapping.h>
-#include <linux/platform_device.h>
-#include <linux/interrupt.h>
-#include <linux/of_platform.h>
-#include <linux/amba/bus.h>
-#include <linux/amba/clcd.h>
-#include <linux/platform_data/video-clcd-versatile.h>
-#include <linux/amba/mmci.h>
-#include <linux/io.h>
-#include <linux/mtd/physmap.h>
-#include <linux/reboot.h>
-
-#include <asm/mach/arch.h>
-#include <asm/mach/map.h>
-#include "platform.h"
-
-#include "core.h"
-
-static struct map_desc versatile_io_desc[] __initdata __maybe_unused = {
- {
- .virtual = IO_ADDRESS(VERSATILE_SYS_BASE),
- .pfn = __phys_to_pfn(VERSATILE_SYS_BASE),
- .length = SZ_4K,
- .type = MT_DEVICE
- }, {
- .virtual = IO_ADDRESS(VERSATILE_SCTL_BASE),
- .pfn = __phys_to_pfn(VERSATILE_SCTL_BASE),
- .length = SZ_4K * 9,
- .type = MT_DEVICE
- },
-};
-
-void __init versatile_map_io(void)
-{
- debug_ll_io_init();
- iotable_init(versatile_io_desc, ARRAY_SIZE(versatile_io_desc));
-}
-
-
-#define VERSATILE_FLASHCTRL (__io_address(VERSATILE_SYS_BASE) + VERSATILE_SYS_FLASH_OFFSET)
-
-static void versatile_flash_set_vpp(struct platform_device *pdev, int on)
-{
- u32 val;
-
- val = __raw_readl(VERSATILE_FLASHCTRL);
- if (on)
- val |= VERSATILE_FLASHPROG_FLVPPEN;
- else
- val &= ~VERSATILE_FLASHPROG_FLVPPEN;
- __raw_writel(val, VERSATILE_FLASHCTRL);
-}
-
-static struct physmap_flash_data versatile_flash_data = {
- .width = 4,
- .set_vpp = versatile_flash_set_vpp,
-};
-
-static struct resource versatile_flash_resource = {
- .start = VERSATILE_FLASH_BASE,
- .end = VERSATILE_FLASH_BASE + VERSATILE_FLASH_SIZE - 1,
- .flags = IORESOURCE_MEM,
-};
-
-struct platform_device versatile_flash_device = {
- .name = "physmap-flash",
- .id = 0,
- .dev = {
- .platform_data = &versatile_flash_data,
- },
- .num_resources = 1,
- .resource = &versatile_flash_resource,
-};
-
-#define VERSATILE_SYSMCI (__io_address(VERSATILE_SYS_BASE) + VERSATILE_SYS_MCI_OFFSET)
-
-unsigned int mmc_status(struct device *dev)
-{
- struct amba_device *adev = container_of(dev, struct amba_device, dev);
- u32 mask;
-
- if (adev->res.start == VERSATILE_MMCI0_BASE)
- mask = 1;
- else
- mask = 2;
-
- return readl(VERSATILE_SYSMCI) & mask;
-}
-
-static struct mmci_platform_data mmc0_plat_data = {
- .ocr_mask = MMC_VDD_32_33|MMC_VDD_33_34,
- .status = mmc_status,
- .gpio_wp = -1,
- .gpio_cd = -1,
-};
-
-static struct mmci_platform_data mmc1_plat_data = {
- .ocr_mask = MMC_VDD_32_33|MMC_VDD_33_34,
- .status = mmc_status,
- .gpio_wp = -1,
- .gpio_cd = -1,
-};
-
-/*
- * CLCD support.
- */
-#define SYS_CLCD_MODE_MASK (3 << 0)
-#define SYS_CLCD_MODE_888 (0 << 0)
-#define SYS_CLCD_MODE_5551 (1 << 0)
-#define SYS_CLCD_MODE_565_RLSB (2 << 0)
-#define SYS_CLCD_MODE_565_BLSB (3 << 0)
-#define SYS_CLCD_NLCDIOON (1 << 2)
-#define SYS_CLCD_VDDPOSSWITCH (1 << 3)
-#define SYS_CLCD_PWR3V5SWITCH (1 << 4)
-#define SYS_CLCD_ID_MASK (0x1f << 8)
-#define SYS_CLCD_ID_SANYO_3_8 (0x00 << 8)
-#define SYS_CLCD_ID_UNKNOWN_8_4 (0x01 << 8)
-#define SYS_CLCD_ID_EPSON_2_2 (0x02 << 8)
-#define SYS_CLCD_ID_SANYO_2_5 (0x07 << 8)
-#define SYS_CLCD_ID_VGA (0x1f << 8)
-
-static bool is_sanyo_2_5_lcd;
-
-/*
- * Disable all display connectors on the interface module.
- */
-static void versatile_clcd_disable(struct clcd_fb *fb)
-{
- void __iomem *sys_clcd = __io_address(VERSATILE_SYS_BASE) + VERSATILE_SYS_CLCD_OFFSET;
- u32 val;
-
- val = readl(sys_clcd);
- val &= ~SYS_CLCD_NLCDIOON | SYS_CLCD_PWR3V5SWITCH;
- writel(val, sys_clcd);
-
- /*
- * If the LCD is Sanyo 2x5 in on the IB2 board, turn the back-light off
- */
- if (of_machine_is_compatible("arm,versatile-ab") && is_sanyo_2_5_lcd) {
- void __iomem *versatile_ib2_ctrl = __io_address(VERSATILE_IB2_CTRL);
- unsigned long ctrl;
-
- ctrl = readl(versatile_ib2_ctrl);
- ctrl &= ~0x01;
- writel(ctrl, versatile_ib2_ctrl);
- }
-}
-
-/*
- * Enable the relevant connector on the interface module.
- */
-static void versatile_clcd_enable(struct clcd_fb *fb)
-{
- struct fb_var_screeninfo *var = &fb->fb.var;
- void __iomem *sys_clcd = __io_address(VERSATILE_SYS_BASE) + VERSATILE_SYS_CLCD_OFFSET;
- u32 val;
-
- val = readl(sys_clcd);
- val &= ~SYS_CLCD_MODE_MASK;
-
- switch (var->green.length) {
- case 5:
- val |= SYS_CLCD_MODE_5551;
- break;
- case 6:
- if (var->red.offset == 0)
- val |= SYS_CLCD_MODE_565_RLSB;
- else
- val |= SYS_CLCD_MODE_565_BLSB;
- break;
- case 8:
- val |= SYS_CLCD_MODE_888;
- break;
- }
-
- /*
- * Set the MUX
- */
- writel(val, sys_clcd);
-
- /*
- * And now enable the PSUs
- */
- val |= SYS_CLCD_NLCDIOON | SYS_CLCD_PWR3V5SWITCH;
- writel(val, sys_clcd);
-
- /*
- * If the LCD is Sanyo 2x5 in on the IB2 board, turn the back-light on
- */
- if (of_machine_is_compatible("arm,versatile-ab") && is_sanyo_2_5_lcd) {
- void __iomem *versatile_ib2_ctrl = __io_address(VERSATILE_IB2_CTRL);
- unsigned long ctrl;
-
- ctrl = readl(versatile_ib2_ctrl);
- ctrl |= 0x01;
- writel(ctrl, versatile_ib2_ctrl);
- }
-}
-
-/*
- * Detect which LCD panel is connected, and return the appropriate
- * clcd_panel structure. Note: we do not have any information on
- * the required timings for the 8.4in panel, so we presently assume
- * VGA timings.
- */
-static int versatile_clcd_setup(struct clcd_fb *fb)
-{
- void __iomem *sys_clcd = __io_address(VERSATILE_SYS_BASE) + VERSATILE_SYS_CLCD_OFFSET;
- const char *panel_name;
- u32 val;
-
- is_sanyo_2_5_lcd = false;
-
- val = readl(sys_clcd) & SYS_CLCD_ID_MASK;
- if (val == SYS_CLCD_ID_SANYO_3_8)
- panel_name = "Sanyo TM38QV67A02A";
- else if (val == SYS_CLCD_ID_SANYO_2_5) {
- panel_name = "Sanyo QVGA Portrait";
- is_sanyo_2_5_lcd = true;
- } else if (val == SYS_CLCD_ID_EPSON_2_2)
- panel_name = "Epson L2F50113T00";
- else if (val == SYS_CLCD_ID_VGA)
- panel_name = "VGA";
- else {
- printk(KERN_ERR "CLCD: unknown LCD panel ID 0x%08x, using VGA\n",
- val);
- panel_name = "VGA";
- }
-
- fb->panel = versatile_clcd_get_panel(panel_name);
- if (!fb->panel)
- return -EINVAL;
-
- return versatile_clcd_setup_dma(fb, SZ_1M);
-}
-
-static void versatile_clcd_decode(struct clcd_fb *fb, struct clcd_regs *regs)
-{
- clcdfb_decode(fb, regs);
-
- /* Always clear BGR for RGB565: we do the routing externally */
- if (fb->fb.var.green.length == 6)
- regs->cntl &= ~CNTL_BGR;
-}
-
-static struct clcd_board clcd_plat_data = {
- .name = "Versatile",
- .caps = CLCD_CAP_5551 | CLCD_CAP_565 | CLCD_CAP_888,
- .check = clcdfb_check,
- .decode = versatile_clcd_decode,
- .disable = versatile_clcd_disable,
- .enable = versatile_clcd_enable,
- .setup = versatile_clcd_setup,
- .mmap = versatile_clcd_mmap_dma,
- .remove = versatile_clcd_remove_dma,
-};
-
-/*
- * Lookup table for attaching a specific name and platform_data pointer to
- * devices as they get created by of_platform_populate(). Ideally this table
- * would not exist, but the current clock implementation depends on some devices
- * having a specific name.
- */
-struct of_dev_auxdata versatile_auxdata_lookup[] __initdata = {
- OF_DEV_AUXDATA("arm,primecell", VERSATILE_MMCI0_BASE, "fpga:05", &mmc0_plat_data),
- OF_DEV_AUXDATA("arm,primecell", VERSATILE_MMCI1_BASE, "fpga:0b", &mmc1_plat_data),
-
- OF_DEV_AUXDATA("arm,primecell", VERSATILE_CLCD_BASE, "dev:20", &clcd_plat_data),
-
- {}
-};
-
-void versatile_restart(enum reboot_mode mode, const char *cmd)
-{
- void __iomem *sys = __io_address(VERSATILE_SYS_BASE);
- u32 val;
-
- val = __raw_readl(sys + VERSATILE_SYS_RESETCTL_OFFSET);
- val |= 0x105;
-
- __raw_writel(0xa05f, sys + VERSATILE_SYS_LOCK_OFFSET);
- __raw_writel(val, sys + VERSATILE_SYS_RESETCTL_OFFSET);
- __raw_writel(0, sys + VERSATILE_SYS_LOCK_OFFSET);
-}
-
-/* Early initializations */
-void __init versatile_init_early(void)
-{
- u32 val;
-
- /*
- * set clock frequency:
- * VERSATILE_REFCLK is 32KHz
- * VERSATILE_TIMCLK is 1MHz
- */
- val = readl(__io_address(VERSATILE_SCTL_BASE));
- writel((VERSATILE_TIMCLK << VERSATILE_TIMER1_EnSel) |
- (VERSATILE_TIMCLK << VERSATILE_TIMER2_EnSel) |
- (VERSATILE_TIMCLK << VERSATILE_TIMER3_EnSel) |
- (VERSATILE_TIMCLK << VERSATILE_TIMER4_EnSel) | val,
- __io_address(VERSATILE_SCTL_BASE));
-}
diff --git a/arch/arm/mach-versatile/core.h b/arch/arm/mach-versatile/core.h
deleted file mode 100644
index c3d7157..0000000
--- a/arch/arm/mach-versatile/core.h
+++ /dev/null
@@ -1,41 +0,0 @@
-/*
- * linux/arch/arm/mach-versatile/core.h
- *
- * Copyright (C) 2004 ARM Limited
- * Copyright (C) 2000 Deep Blue Solutions Ltd
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
- */
-
-#ifndef __ASM_ARCH_VERSATILE_H
-#define __ASM_ARCH_VERSATILE_H
-
-#include <linux/amba/bus.h>
-#include <linux/of_platform.h>
-#include <linux/reboot.h>
-
-extern struct platform_device versatile_flash_device;
-
-extern void __init versatile_init_early(void);
-extern void __init versatile_init_irq(void);
-extern void __init versatile_map_io(void);
-extern void versatile_timer_init(void);
-extern void versatile_restart(enum reboot_mode, const char *);
-extern unsigned int mmc_status(struct device *dev);
-#ifdef CONFIG_OF
-extern struct of_dev_auxdata versatile_auxdata_lookup[];
-#endif
-
-#endif
diff --git a/arch/arm/mach-versatile/versatile_dt.c b/arch/arm/mach-versatile/versatile_dt.c
index 1bb21d1..9b0d392 100644
--- a/arch/arm/mach-versatile/versatile_dt.c
+++ b/arch/arm/mach-versatile/versatile_dt.c
@@ -28,13 +28,302 @@
#include <linux/of_irq.h>
#include <linux/of_platform.h>
#include <linux/slab.h>
+#include <linux/amba/bus.h>
+#include <linux/amba/clcd.h>
+#include <linux/platform_data/video-clcd-versatile.h>
+#include <linux/amba/mmci.h>
+#include <linux/mtd/physmap.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
+#include <asm/mach/map.h>
-#include "core.h"
+#include "platform.h"
#define VERSATILE_SYS_PCICTL_OFFSET 0x44
+#define VERSATILE_FLASHCTRL (__io_address(VERSATILE_SYS_BASE) + VERSATILE_SYS_FLASH_OFFSET)
+
+static void versatile_flash_set_vpp(struct platform_device *pdev, int on)
+{
+ u32 val;
+
+ val = __raw_readl(VERSATILE_FLASHCTRL);
+ if (on)
+ val |= VERSATILE_FLASHPROG_FLVPPEN;
+ else
+ val &= ~VERSATILE_FLASHPROG_FLVPPEN;
+ __raw_writel(val, VERSATILE_FLASHCTRL);
+}
+
+static struct physmap_flash_data versatile_flash_data = {
+ .width = 4,
+ .set_vpp = versatile_flash_set_vpp,
+};
+
+static struct resource versatile_flash_resource = {
+ .start = VERSATILE_FLASH_BASE,
+ .end = VERSATILE_FLASH_BASE + VERSATILE_FLASH_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+};
+
+struct platform_device versatile_flash_device = {
+ .name = "physmap-flash",
+ .id = 0,
+ .dev = {
+ .platform_data = &versatile_flash_data,
+ },
+ .num_resources = 1,
+ .resource = &versatile_flash_resource,
+};
+
+#define VERSATILE_SYSMCI (__io_address(VERSATILE_SYS_BASE) + VERSATILE_SYS_MCI_OFFSET)
+
+unsigned int mmc_status(struct device *dev)
+{
+ struct amba_device *adev = container_of(dev, struct amba_device, dev);
+ u32 mask;
+
+ if (adev->res.start == VERSATILE_MMCI0_BASE)
+ mask = 1;
+ else
+ mask = 2;
+
+ return readl(VERSATILE_SYSMCI) & mask;
+}
+
+static struct mmci_platform_data mmc0_plat_data = {
+ .ocr_mask = MMC_VDD_32_33|MMC_VDD_33_34,
+ .status = mmc_status,
+ .gpio_wp = -1,
+ .gpio_cd = -1,
+};
+
+static struct mmci_platform_data mmc1_plat_data = {
+ .ocr_mask = MMC_VDD_32_33|MMC_VDD_33_34,
+ .status = mmc_status,
+ .gpio_wp = -1,
+ .gpio_cd = -1,
+};
+
+/*
+ * CLCD support.
+ */
+#define SYS_CLCD_MODE_MASK (3 << 0)
+#define SYS_CLCD_MODE_888 (0 << 0)
+#define SYS_CLCD_MODE_5551 (1 << 0)
+#define SYS_CLCD_MODE_565_RLSB (2 << 0)
+#define SYS_CLCD_MODE_565_BLSB (3 << 0)
+#define SYS_CLCD_NLCDIOON (1 << 2)
+#define SYS_CLCD_VDDPOSSWITCH (1 << 3)
+#define SYS_CLCD_PWR3V5SWITCH (1 << 4)
+#define SYS_CLCD_ID_MASK (0x1f << 8)
+#define SYS_CLCD_ID_SANYO_3_8 (0x00 << 8)
+#define SYS_CLCD_ID_UNKNOWN_8_4 (0x01 << 8)
+#define SYS_CLCD_ID_EPSON_2_2 (0x02 << 8)
+#define SYS_CLCD_ID_SANYO_2_5 (0x07 << 8)
+#define SYS_CLCD_ID_VGA (0x1f << 8)
+
+static bool is_sanyo_2_5_lcd;
+
+/*
+ * Disable all display connectors on the interface module.
+ */
+static void versatile_clcd_disable(struct clcd_fb *fb)
+{
+ void __iomem *sys_clcd = __io_address(VERSATILE_SYS_BASE) + VERSATILE_SYS_CLCD_OFFSET;
+ u32 val;
+
+ val = readl(sys_clcd);
+ val &= ~SYS_CLCD_NLCDIOON | SYS_CLCD_PWR3V5SWITCH;
+ writel(val, sys_clcd);
+
+ /*
+ * If the LCD is Sanyo 2x5 in on the IB2 board, turn the back-light off
+ */
+ if (of_machine_is_compatible("arm,versatile-ab") && is_sanyo_2_5_lcd) {
+ void __iomem *versatile_ib2_ctrl = __io_address(VERSATILE_IB2_CTRL);
+ unsigned long ctrl;
+
+ ctrl = readl(versatile_ib2_ctrl);
+ ctrl &= ~0x01;
+ writel(ctrl, versatile_ib2_ctrl);
+ }
+}
+
+/*
+ * Enable the relevant connector on the interface module.
+ */
+static void versatile_clcd_enable(struct clcd_fb *fb)
+{
+ struct fb_var_screeninfo *var = &fb->fb.var;
+ void __iomem *sys_clcd = __io_address(VERSATILE_SYS_BASE) + VERSATILE_SYS_CLCD_OFFSET;
+ u32 val;
+
+ val = readl(sys_clcd);
+ val &= ~SYS_CLCD_MODE_MASK;
+
+ switch (var->green.length) {
+ case 5:
+ val |= SYS_CLCD_MODE_5551;
+ break;
+ case 6:
+ if (var->red.offset == 0)
+ val |= SYS_CLCD_MODE_565_RLSB;
+ else
+ val |= SYS_CLCD_MODE_565_BLSB;
+ break;
+ case 8:
+ val |= SYS_CLCD_MODE_888;
+ break;
+ }
+
+ /*
+ * Set the MUX
+ */
+ writel(val, sys_clcd);
+
+ /*
+ * And now enable the PSUs
+ */
+ val |= SYS_CLCD_NLCDIOON | SYS_CLCD_PWR3V5SWITCH;
+ writel(val, sys_clcd);
+
+ /*
+ * If the LCD is Sanyo 2x5 in on the IB2 board, turn the back-light on
+ */
+ if (of_machine_is_compatible("arm,versatile-ab") && is_sanyo_2_5_lcd) {
+ void __iomem *versatile_ib2_ctrl = __io_address(VERSATILE_IB2_CTRL);
+ unsigned long ctrl;
+
+ ctrl = readl(versatile_ib2_ctrl);
+ ctrl |= 0x01;
+ writel(ctrl, versatile_ib2_ctrl);
+ }
+}
+
+/*
+ * Detect which LCD panel is connected, and return the appropriate
+ * clcd_panel structure. Note: we do not have any information on
+ * the required timings for the 8.4in panel, so we presently assume
+ * VGA timings.
+ */
+static int versatile_clcd_setup(struct clcd_fb *fb)
+{
+ void __iomem *sys_clcd = __io_address(VERSATILE_SYS_BASE) + VERSATILE_SYS_CLCD_OFFSET;
+ const char *panel_name;
+ u32 val;
+
+ is_sanyo_2_5_lcd = false;
+
+ val = readl(sys_clcd) & SYS_CLCD_ID_MASK;
+ if (val == SYS_CLCD_ID_SANYO_3_8)
+ panel_name = "Sanyo TM38QV67A02A";
+ else if (val == SYS_CLCD_ID_SANYO_2_5) {
+ panel_name = "Sanyo QVGA Portrait";
+ is_sanyo_2_5_lcd = true;
+ } else if (val == SYS_CLCD_ID_EPSON_2_2)
+ panel_name = "Epson L2F50113T00";
+ else if (val == SYS_CLCD_ID_VGA)
+ panel_name = "VGA";
+ else {
+ printk(KERN_ERR "CLCD: unknown LCD panel ID 0x%08x, using VGA\n",
+ val);
+ panel_name = "VGA";
+ }
+
+ fb->panel = versatile_clcd_get_panel(panel_name);
+ if (!fb->panel)
+ return -EINVAL;
+
+ return versatile_clcd_setup_dma(fb, SZ_1M);
+}
+
+static void versatile_clcd_decode(struct clcd_fb *fb, struct clcd_regs *regs)
+{
+ clcdfb_decode(fb, regs);
+
+ /* Always clear BGR for RGB565: we do the routing externally */
+ if (fb->fb.var.green.length == 6)
+ regs->cntl &= ~CNTL_BGR;
+}
+
+static struct clcd_board clcd_plat_data = {
+ .name = "Versatile",
+ .caps = CLCD_CAP_5551 | CLCD_CAP_565 | CLCD_CAP_888,
+ .check = clcdfb_check,
+ .decode = versatile_clcd_decode,
+ .disable = versatile_clcd_disable,
+ .enable = versatile_clcd_enable,
+ .setup = versatile_clcd_setup,
+ .mmap = versatile_clcd_mmap_dma,
+ .remove = versatile_clcd_remove_dma,
+};
+
+/*
+ * Lookup table for attaching a specific name and platform_data pointer to
+ * devices as they get created by of_platform_populate(). Ideally this table
+ * would not exist, but the current clock implementation depends on some devices
+ * having a specific name.
+ */
+struct of_dev_auxdata versatile_auxdata_lookup[] __initdata = {
+ OF_DEV_AUXDATA("arm,primecell", VERSATILE_MMCI0_BASE, "fpga:05", &mmc0_plat_data),
+ OF_DEV_AUXDATA("arm,primecell", VERSATILE_MMCI1_BASE, "fpga:0b", &mmc1_plat_data),
+
+ OF_DEV_AUXDATA("arm,primecell", VERSATILE_CLCD_BASE, "dev:20", &clcd_plat_data),
+
+ {}
+};
+
+static struct map_desc versatile_io_desc[] __initdata __maybe_unused = {
+ {
+ .virtual = IO_ADDRESS(VERSATILE_SYS_BASE),
+ .pfn = __phys_to_pfn(VERSATILE_SYS_BASE),
+ .length = SZ_4K,
+ .type = MT_DEVICE
+ }, {
+ .virtual = IO_ADDRESS(VERSATILE_SCTL_BASE),
+ .pfn = __phys_to_pfn(VERSATILE_SCTL_BASE),
+ .length = SZ_4K * 9,
+ .type = MT_DEVICE
+ },
+};
+
+static void __init versatile_map_io(void)
+{
+ debug_ll_io_init();
+ iotable_init(versatile_io_desc, ARRAY_SIZE(versatile_io_desc));
+}
+
+static void __init versatile_init_early(void)
+{
+ u32 val;
+
+ /*
+ * set clock frequency:
+ * VERSATILE_REFCLK is 32KHz
+ * VERSATILE_TIMCLK is 1MHz
+ */
+ val = readl(__io_address(VERSATILE_SCTL_BASE));
+ writel((VERSATILE_TIMCLK << VERSATILE_TIMER1_EnSel) |
+ (VERSATILE_TIMCLK << VERSATILE_TIMER2_EnSel) |
+ (VERSATILE_TIMCLK << VERSATILE_TIMER3_EnSel) |
+ (VERSATILE_TIMCLK << VERSATILE_TIMER4_EnSel) | val,
+ __io_address(VERSATILE_SCTL_BASE));
+}
+
+static void versatile_restart(enum reboot_mode mode, const char *cmd)
+{
+ void __iomem *sys = __io_address(VERSATILE_SYS_BASE);
+ u32 val;
+
+ val = __raw_readl(sys + VERSATILE_SYS_RESETCTL_OFFSET);
+ val |= 0x105;
+
+ __raw_writel(0xa05f, sys + VERSATILE_SYS_LOCK_OFFSET);
+ __raw_writel(val, sys + VERSATILE_SYS_RESETCTL_OFFSET);
+ __raw_writel(0, sys + VERSATILE_SYS_LOCK_OFFSET);
+}
+
static void __init versatile_dt_pci_init(void)
{
u32 val;
--
2.1.0
^ permalink raw reply related [flat|nested] 86+ messages in thread
* Re: [PATCH 3/9] ARM: versatile: add DT based PCI detection
2014-12-30 19:28 ` Rob Herring
@ 2014-12-30 21:37 ` Arnd Bergmann
-1 siblings, 0 replies; 86+ messages in thread
From: Arnd Bergmann @ 2014-12-30 21:37 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA, Peter Maydell,
Russell King, Rob Herring, Linus Walleij,
arm-DgEjT+Ai2ygdnm+yROfE0A, Bjorn Helgaas
On Tuesday 30 December 2014 13:28:32 Rob Herring wrote:
> From: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>
> Disable the Versatile PCI DT node when no PCI backplane is detected. This
> will prevent the Versatile PCI driver from probing when PCI is not
> populated.
Can you explain why the check is done in platform code instead of the PCI
driver probe function itself?
> + /* Check if PCI backplane is detected */
> + val = __raw_readl(base + VERSATILE_SYS_PCICTL_OFFSET);
> + if (val & 1)
> + goto err;
Using __raw_readl prevents this from working with big-endian kernels, so just
use readl here.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 3/9] ARM: versatile: add DT based PCI detection
@ 2014-12-30 21:37 ` Arnd Bergmann
0 siblings, 0 replies; 86+ messages in thread
From: Arnd Bergmann @ 2014-12-30 21:37 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 30 December 2014 13:28:32 Rob Herring wrote:
> From: Rob Herring <robh@kernel.org>
>
> Disable the Versatile PCI DT node when no PCI backplane is detected. This
> will prevent the Versatile PCI driver from probing when PCI is not
> populated.
Can you explain why the check is done in platform code instead of the PCI
driver probe function itself?
> + /* Check if PCI backplane is detected */
> + val = __raw_readl(base + VERSATILE_SYS_PCICTL_OFFSET);
> + if (val & 1)
> + goto err;
Using __raw_readl prevents this from working with big-endian kernels, so just
use readl here.
Arnd
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 4/9] pci: add DT based ARM Versatile PCI host driver
2014-12-30 19:28 ` Rob Herring
@ 2014-12-30 21:58 ` Arnd Bergmann
-1 siblings, 0 replies; 86+ messages in thread
From: Arnd Bergmann @ 2014-12-30 21:58 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Rob Herring, devicetree, Peter Maydell, Russell King,
Rob Herring, linux-pci, Linus Walleij, arm, Bjorn Helgaas
On Tuesday 30 December 2014 13:28:33 Rob Herring wrote:
> From: Rob Herring <robh@kernel.org>
>
> This converts the Versatile PCI host code to a platform driver using
> the commom DT parsing and setup. The driver uses only an empty ARM
> pci_sys_data struct and does not use pci_common_init_dev init function.
> The old host code will be removed in a subsequent commit when Versatile
> is completely converted to DT.
>
> I've tested this on QEMU with the sym53c8xx driver in both i/o and
> memory mapped modes.
Ah, this is quite clever, I think you tried to explain to me what you
did with the pci_sys_data before, but I didn't get it then.
> +
> +static void __iomem *__pci_addr(struct pci_bus *bus,
> + unsigned int devfn, int offset)
> +{
> + unsigned int busnr = bus->number;
> +
> + /*
> + * Trap out illegal values
> + */
> + BUG_ON(offset > 255);
> + BUG_ON(busnr > 255);
> + BUG_ON(devfn > 255);
Isn't an offset>255 something that can be triggered by a non-broken
driver or even user space?
Maybe just return PCIBIOS_BAD_REGISTER_NUMBER in this case?
> +static int versatile_pci_parse_request_of_pci_ranges(struct device *dev,
> + struct list_head *res)
> +{
> + int err, mem = 1, res_valid = 0;
> + struct device_node *np = dev->of_node;
> + resource_size_t iobase;
> + struct pci_host_bridge_window *win;
> +
> + err = of_pci_get_host_bridge_resources(np, 0, 0xff, res, &iobase);
> + if (err)
> + return err;
> +
> + list_for_each_entry(win, res, list) {
> + struct resource *parent, *res = win->res;
> +
> + switch (resource_type(res)) {
> + case IORESOURCE_IO:
> + parent = &ioport_resource;
> + err = pci_remap_iospace(res, iobase);
> + if (err) {
> + dev_warn(dev, "error %d: failed to map resource %pR\n",
> + err, res);
> + continue;
> + }
> + break;
> + case IORESOURCE_MEM:
> + parent = &iomem_resource;
> + res_valid |= !(res->flags & IORESOURCE_PREFETCH);
> +
> + writel(res->start >> 28, PCI_IMAP(mem));
> + writel(PHYS_OFFSET >> 28, PCI_SMAP(mem));
> + mem++;
> +
> + break;
> + case IORESOURCE_BUS:
> + default:
> + continue;
> + }
> +
> + err = devm_request_resource(dev, parent, res);
> + if (err)
> + goto out_release_res;
> + }
I wonder if we should also request the physical resource for the I/O space
window to have it show up in /proc/iomem. We are rather inconsistent in this
regard between drivers.
> + pci_add_flags(PCI_ENABLE_PROC_DOMAINS);
> + pci_add_flags(PCI_REASSIGN_ALL_BUS | PCI_REASSIGN_ALL_RSRC);
> +
> + bus = pci_scan_root_bus(&pdev->dev, 0, &pci_versatile_ops, &sys, &pci_res);
> + if (!bus)
> + return -ENOMEM;
> +
> + pci_fixup_irqs(pci_common_swizzle, of_irq_parse_and_map_pci);
> + pci_assign_unassigned_bus_resources(bus);
> +
> + return 0;
One general question, mainly for Bjorn: pci_scan_root_bus adds all the devices
at the Linux driver level by calling pci_bus_add_devices(), but then we call
pci_fixup_irqs and pci_assign_unassigned_bus_resources after that, which will
change the devices again. Is this how it's meant to work? How do we ensure
that we have the correct irq number and resources by the time we enter the
probe() function of the PCI device driver that gets bound to a device here?
Arnd
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 4/9] pci: add DT based ARM Versatile PCI host driver
@ 2014-12-30 21:58 ` Arnd Bergmann
0 siblings, 0 replies; 86+ messages in thread
From: Arnd Bergmann @ 2014-12-30 21:58 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 30 December 2014 13:28:33 Rob Herring wrote:
> From: Rob Herring <robh@kernel.org>
>
> This converts the Versatile PCI host code to a platform driver using
> the commom DT parsing and setup. The driver uses only an empty ARM
> pci_sys_data struct and does not use pci_common_init_dev init function.
> The old host code will be removed in a subsequent commit when Versatile
> is completely converted to DT.
>
> I've tested this on QEMU with the sym53c8xx driver in both i/o and
> memory mapped modes.
Ah, this is quite clever, I think you tried to explain to me what you
did with the pci_sys_data before, but I didn't get it then.
> +
> +static void __iomem *__pci_addr(struct pci_bus *bus,
> + unsigned int devfn, int offset)
> +{
> + unsigned int busnr = bus->number;
> +
> + /*
> + * Trap out illegal values
> + */
> + BUG_ON(offset > 255);
> + BUG_ON(busnr > 255);
> + BUG_ON(devfn > 255);
Isn't an offset>255 something that can be triggered by a non-broken
driver or even user space?
Maybe just return PCIBIOS_BAD_REGISTER_NUMBER in this case?
> +static int versatile_pci_parse_request_of_pci_ranges(struct device *dev,
> + struct list_head *res)
> +{
> + int err, mem = 1, res_valid = 0;
> + struct device_node *np = dev->of_node;
> + resource_size_t iobase;
> + struct pci_host_bridge_window *win;
> +
> + err = of_pci_get_host_bridge_resources(np, 0, 0xff, res, &iobase);
> + if (err)
> + return err;
> +
> + list_for_each_entry(win, res, list) {
> + struct resource *parent, *res = win->res;
> +
> + switch (resource_type(res)) {
> + case IORESOURCE_IO:
> + parent = &ioport_resource;
> + err = pci_remap_iospace(res, iobase);
> + if (err) {
> + dev_warn(dev, "error %d: failed to map resource %pR\n",
> + err, res);
> + continue;
> + }
> + break;
> + case IORESOURCE_MEM:
> + parent = &iomem_resource;
> + res_valid |= !(res->flags & IORESOURCE_PREFETCH);
> +
> + writel(res->start >> 28, PCI_IMAP(mem));
> + writel(PHYS_OFFSET >> 28, PCI_SMAP(mem));
> + mem++;
> +
> + break;
> + case IORESOURCE_BUS:
> + default:
> + continue;
> + }
> +
> + err = devm_request_resource(dev, parent, res);
> + if (err)
> + goto out_release_res;
> + }
I wonder if we should also request the physical resource for the I/O space
window to have it show up in /proc/iomem. We are rather inconsistent in this
regard between drivers.
> + pci_add_flags(PCI_ENABLE_PROC_DOMAINS);
> + pci_add_flags(PCI_REASSIGN_ALL_BUS | PCI_REASSIGN_ALL_RSRC);
> +
> + bus = pci_scan_root_bus(&pdev->dev, 0, &pci_versatile_ops, &sys, &pci_res);
> + if (!bus)
> + return -ENOMEM;
> +
> + pci_fixup_irqs(pci_common_swizzle, of_irq_parse_and_map_pci);
> + pci_assign_unassigned_bus_resources(bus);
> +
> + return 0;
One general question, mainly for Bjorn: pci_scan_root_bus adds all the devices
at the Linux driver level by calling pci_bus_add_devices(), but then we call
pci_fixup_irqs and pci_assign_unassigned_bus_resources after that, which will
change the devices again. Is this how it's meant to work? How do we ensure
that we have the correct irq number and resources by the time we enter the
probe() function of the PCI device driver that gets bound to a device here?
Arnd
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 7/9] ARM: versatile: move mach includes into mach directory
2014-12-30 19:28 ` Rob Herring
@ 2014-12-30 22:05 ` Arnd Bergmann
-1 siblings, 0 replies; 86+ messages in thread
From: Arnd Bergmann @ 2014-12-30 22:05 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA, Peter Maydell,
Russell King, Rob Herring, Linus Walleij,
arm-DgEjT+Ai2ygdnm+yROfE0A, Bjorn Helgaas
On Tuesday 30 December 2014 13:28:36 Rob Herring wrote:
> From: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>
> In preparation for multi-platform support, move platform.h and
> hardware.h into mach-versatile directory. Combine them into a single
> file in the process.
>
> Signed-off-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
> Cc: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> arch/arm/mach-versatile/core.c | 3 +-
> arch/arm/mach-versatile/include/mach/hardware.h | 32 ----------------------
> .../mach-versatile/{include/mach => }/platform.h | 5 ++++
> 3 files changed, 6 insertions(+), 34 deletions(-)
>
If I read this right, there is only one file left that includes this
header after patch 9, so how about moving the contents into versatile_dt.c
directly?
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 7/9] ARM: versatile: move mach includes into mach directory
@ 2014-12-30 22:05 ` Arnd Bergmann
0 siblings, 0 replies; 86+ messages in thread
From: Arnd Bergmann @ 2014-12-30 22:05 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 30 December 2014 13:28:36 Rob Herring wrote:
> From: Rob Herring <robh@kernel.org>
>
> In preparation for multi-platform support, move platform.h and
> hardware.h into mach-versatile directory. Combine them into a single
> file in the process.
>
> Signed-off-by: Rob Herring <robh@kernel.org>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> ---
> arch/arm/mach-versatile/core.c | 3 +-
> arch/arm/mach-versatile/include/mach/hardware.h | 32 ----------------------
> .../mach-versatile/{include/mach => }/platform.h | 5 ++++
> 3 files changed, 6 insertions(+), 34 deletions(-)
>
If I read this right, there is only one file left that includes this
header after patch 9, so how about moving the contents into versatile_dt.c
directly?
Arnd
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 0/9] ARM Versatile multi-platform support
2014-12-30 19:28 ` Rob Herring
@ 2014-12-30 22:08 ` Arnd Bergmann
-1 siblings, 0 replies; 86+ messages in thread
From: Arnd Bergmann @ 2014-12-30 22:08 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA, Peter Maydell,
Russell King, Rob Herring, Linus Walleij,
arm-DgEjT+Ai2ygdnm+yROfE0A, Bjorn Helgaas
On Tuesday 30 December 2014 13:28:29 Rob Herring wrote:
> From: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>
> This series converts ARM Versatile platform to multi-platform. I started
> this some time ago and some pieces were already merged. The primary
> piece remaining is converting the PCI host to DT which I was waiting for
> the common PCI DT parsing to get settled. Now that that is in place as
> well as a few other pieces are in place like multi-platform fixes for
> CLCD, we can fully convert Versatile to DT and multi-platform.
Hi Rob, thanks for picking this up again, looks great overall!
I've replied to a few individual patches with minor questions, but
none of them are show-stoppers.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 0/9] ARM Versatile multi-platform support
@ 2014-12-30 22:08 ` Arnd Bergmann
0 siblings, 0 replies; 86+ messages in thread
From: Arnd Bergmann @ 2014-12-30 22:08 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 30 December 2014 13:28:29 Rob Herring wrote:
> From: Rob Herring <robh@kernel.org>
>
> This series converts ARM Versatile platform to multi-platform. I started
> this some time ago and some pieces were already merged. The primary
> piece remaining is converting the PCI host to DT which I was waiting for
> the common PCI DT parsing to get settled. Now that that is in place as
> well as a few other pieces are in place like multi-platform fixes for
> CLCD, we can fully convert Versatile to DT and multi-platform.
Hi Rob, thanks for picking this up again, looks great overall!
I've replied to a few individual patches with minor questions, but
none of them are show-stoppers.
Arnd
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 3/9] ARM: versatile: add DT based PCI detection
2014-12-30 21:37 ` Arnd Bergmann
@ 2014-12-30 23:05 ` Rob Herring
-1 siblings, 0 replies; 86+ messages in thread
From: Rob Herring @ 2014-12-30 23:05 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Peter Maydell, Russell King,
Linus Walleij, arm-DgEjT+Ai2ygdnm+yROfE0A, Bjorn Helgaas
On Tue, Dec 30, 2014 at 3:37 PM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> On Tuesday 30 December 2014 13:28:32 Rob Herring wrote:
>> From: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>
>> Disable the Versatile PCI DT node when no PCI backplane is detected. This
>> will prevent the Versatile PCI driver from probing when PCI is not
>> populated.
>
> Can you explain why the check is done in platform code instead of the PCI
> driver probe function itself?
Because the register to check is not part of the PCI controller, but
part of the system registers. There was no infrastructure for the
system registers when I originally wrote this, but there's some syscon
support now for VExpress that may be able to be used. I think it is
cleaner if we can avoid syscon dependencies in drivers in general, but
it is pretty much zero chance the Versatile PCI driver will ever be
used on another platform.
>> + /* Check if PCI backplane is detected */
>> + val = __raw_readl(base + VERSATILE_SYS_PCICTL_OFFSET);
>> + if (val & 1)
>> + goto err;
>
> Using __raw_readl prevents this from working with big-endian kernels, so just
> use readl here.
So does the fact that this is an ARM926, but yes there's not really
any reason not to use readl.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 3/9] ARM: versatile: add DT based PCI detection
@ 2014-12-30 23:05 ` Rob Herring
0 siblings, 0 replies; 86+ messages in thread
From: Rob Herring @ 2014-12-30 23:05 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Dec 30, 2014 at 3:37 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 30 December 2014 13:28:32 Rob Herring wrote:
>> From: Rob Herring <robh@kernel.org>
>>
>> Disable the Versatile PCI DT node when no PCI backplane is detected. This
>> will prevent the Versatile PCI driver from probing when PCI is not
>> populated.
>
> Can you explain why the check is done in platform code instead of the PCI
> driver probe function itself?
Because the register to check is not part of the PCI controller, but
part of the system registers. There was no infrastructure for the
system registers when I originally wrote this, but there's some syscon
support now for VExpress that may be able to be used. I think it is
cleaner if we can avoid syscon dependencies in drivers in general, but
it is pretty much zero chance the Versatile PCI driver will ever be
used on another platform.
>> + /* Check if PCI backplane is detected */
>> + val = __raw_readl(base + VERSATILE_SYS_PCICTL_OFFSET);
>> + if (val & 1)
>> + goto err;
>
> Using __raw_readl prevents this from working with big-endian kernels, so just
> use readl here.
So does the fact that this is an ARM926, but yes there's not really
any reason not to use readl.
Rob
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 0/9] ARM Versatile multi-platform support
2014-12-30 19:28 ` Rob Herring
@ 2014-12-31 9:25 ` Peter Maydell
-1 siblings, 0 replies; 86+ messages in thread
From: Peter Maydell @ 2014-12-31 9:25 UTC (permalink / raw)
To: Rob Herring
Cc: arm-mail-list, devicetree-u79uwXL29TY76Z2rM5mHXA, Russell King,
Linus Walleij, arm-DgEjT+Ai2ygdnm+yROfE0A, Bjorn Helgaas,
Rob Herring, Will Deacon, Marc Zyngier
On 30 December 2014 at 19:28, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> This has been tested on QEMU. A previous version was tested on
> Versatile/AB by Linus Walleij. Linus reported a problem with the
> display panel detection. Investigation on h/w is needed still as I have
> not been able to identify the issue by inspection and the display
> detection seems to work correctly on QEMU.
>
> Linus had also mentioned to me that QEMU users may have some issue with
> removing non-DT code as the work flow has to change somewhat.
As long as you call out the requirement for a DT now in whatever
your equivalent of release notes is that should be fine. (Does
the kernel provide a useful message to serial in the absence of a
DT or does it now not have enough platform knowledge to do that?)
> Copying
> Peter Maydell here for comment (and there's rumors he may have actual PB
> h/w with PCI as well).
Will Deacon and Marc Zyngier are currently in possession of that h/w.
I'm sure they'd be delighted to pull it out of the cupboard and
give it a spin :-)
-- PMM
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 0/9] ARM Versatile multi-platform support
@ 2014-12-31 9:25 ` Peter Maydell
0 siblings, 0 replies; 86+ messages in thread
From: Peter Maydell @ 2014-12-31 9:25 UTC (permalink / raw)
To: linux-arm-kernel
On 30 December 2014 at 19:28, Rob Herring <robherring2@gmail.com> wrote:
> This has been tested on QEMU. A previous version was tested on
> Versatile/AB by Linus Walleij. Linus reported a problem with the
> display panel detection. Investigation on h/w is needed still as I have
> not been able to identify the issue by inspection and the display
> detection seems to work correctly on QEMU.
>
> Linus had also mentioned to me that QEMU users may have some issue with
> removing non-DT code as the work flow has to change somewhat.
As long as you call out the requirement for a DT now in whatever
your equivalent of release notes is that should be fine. (Does
the kernel provide a useful message to serial in the absence of a
DT or does it now not have enough platform knowledge to do that?)
> Copying
> Peter Maydell here for comment (and there's rumors he may have actual PB
> h/w with PCI as well).
Will Deacon and Marc Zyngier are currently in possession of that h/w.
I'm sure they'd be delighted to pull it out of the cupboard and
give it a spin :-)
-- PMM
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 3/9] ARM: versatile: add DT based PCI detection
2014-12-30 23:05 ` Rob Herring
@ 2014-12-31 15:23 ` Arnd Bergmann
-1 siblings, 0 replies; 86+ messages in thread
From: Arnd Bergmann @ 2014-12-31 15:23 UTC (permalink / raw)
To: Rob Herring
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Peter Maydell, Russell King,
Linus Walleij, arm-DgEjT+Ai2ygdnm+yROfE0A, Bjorn Helgaas
On Tuesday 30 December 2014 17:05:16 Rob Herring wrote:
> On Tue, Dec 30, 2014 at 3:37 PM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> > On Tuesday 30 December 2014 13:28:32 Rob Herring wrote:
> >> From: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> >>
> >> Disable the Versatile PCI DT node when no PCI backplane is detected. This
> >> will prevent the Versatile PCI driver from probing when PCI is not
> >> populated.
> >
> > Can you explain why the check is done in platform code instead of the PCI
> > driver probe function itself?
>
> Because the register to check is not part of the PCI controller, but
> part of the system registers. There was no infrastructure for the
> system registers when I originally wrote this, but there's some syscon
> support now for VExpress that may be able to be used. I think it is
> cleaner if we can avoid syscon dependencies in drivers in general, but
> it is pretty much zero chance the Versatile PCI driver will ever be
> used on another platform.
Ok, I see. I guess ideally we would get a correct DTB file from the boot
loader, but that is of course completely unrealistic on versatile, both
on hardware and qemu.
Maybe we can just take your current approach for now, and add a comment
about the possibility of using syscon in the future to the function.
I'm also not completely sure if your code gets it right: the existing
driver writes '1' into this register in .preinit() and then reads the
same register back in .setup(). Your driver just reads the value but
never writes it.
I suspect that either the existing behavior is completely bogus because
the driver always reads what it write before, and then you can skip
the logic completely, or your new driver is broken because reading
the register without writing it first will result in undefined behavior
on real hardware.
> >> + /* Check if PCI backplane is detected */
> >> + val = __raw_readl(base + VERSATILE_SYS_PCICTL_OFFSET);
> >> + if (val & 1)
> >> + goto err;
> >
> > Using __raw_readl prevents this from working with big-endian kernels, so just
> > use readl here.
>
> So does the fact that this is an ARM926, but yes there's not really
> any reason not to use readl.
Ok. I don't think there is anything preventing you from setting big-endian
mode on arm926 though, it's just that nobody ever has the need in practice,
and a lot of drivers are broken.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 3/9] ARM: versatile: add DT based PCI detection
@ 2014-12-31 15:23 ` Arnd Bergmann
0 siblings, 0 replies; 86+ messages in thread
From: Arnd Bergmann @ 2014-12-31 15:23 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 30 December 2014 17:05:16 Rob Herring wrote:
> On Tue, Dec 30, 2014 at 3:37 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Tuesday 30 December 2014 13:28:32 Rob Herring wrote:
> >> From: Rob Herring <robh@kernel.org>
> >>
> >> Disable the Versatile PCI DT node when no PCI backplane is detected. This
> >> will prevent the Versatile PCI driver from probing when PCI is not
> >> populated.
> >
> > Can you explain why the check is done in platform code instead of the PCI
> > driver probe function itself?
>
> Because the register to check is not part of the PCI controller, but
> part of the system registers. There was no infrastructure for the
> system registers when I originally wrote this, but there's some syscon
> support now for VExpress that may be able to be used. I think it is
> cleaner if we can avoid syscon dependencies in drivers in general, but
> it is pretty much zero chance the Versatile PCI driver will ever be
> used on another platform.
Ok, I see. I guess ideally we would get a correct DTB file from the boot
loader, but that is of course completely unrealistic on versatile, both
on hardware and qemu.
Maybe we can just take your current approach for now, and add a comment
about the possibility of using syscon in the future to the function.
I'm also not completely sure if your code gets it right: the existing
driver writes '1' into this register in .preinit() and then reads the
same register back in .setup(). Your driver just reads the value but
never writes it.
I suspect that either the existing behavior is completely bogus because
the driver always reads what it write before, and then you can skip
the logic completely, or your new driver is broken because reading
the register without writing it first will result in undefined behavior
on real hardware.
> >> + /* Check if PCI backplane is detected */
> >> + val = __raw_readl(base + VERSATILE_SYS_PCICTL_OFFSET);
> >> + if (val & 1)
> >> + goto err;
> >
> > Using __raw_readl prevents this from working with big-endian kernels, so just
> > use readl here.
>
> So does the fact that this is an ARM926, but yes there's not really
> any reason not to use readl.
Ok. I don't think there is anything preventing you from setting big-endian
mode on arm926 though, it's just that nobody ever has the need in practice,
and a lot of drivers are broken.
Arnd
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 3/9] ARM: versatile: add DT based PCI detection
2014-12-31 15:23 ` Arnd Bergmann
@ 2014-12-31 16:13 ` Peter Maydell
-1 siblings, 0 replies; 86+ messages in thread
From: Peter Maydell @ 2014-12-31 16:13 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Rob Herring, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Russell King, Linus Walleij,
arm-DgEjT+Ai2ygdnm+yROfE0A, Bjorn Helgaas
On 31 December 2014 at 15:23, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> On Tuesday 30 December 2014 17:05:16 Rob Herring wrote:
>> Because the register to check is not part of the PCI controller, but
>> part of the system registers. There was no infrastructure for the
>> system registers when I originally wrote this, but there's some syscon
>> support now for VExpress that may be able to be used. I think it is
>> cleaner if we can avoid syscon dependencies in drivers in general, but
>> it is pretty much zero chance the Versatile PCI driver will ever be
>> used on another platform.
>
> Ok, I see. I guess ideally we would get a correct DTB file from the boot
> loader, but that is of course completely unrealistic on versatile, both
> on hardware and qemu.
Why would you want to get the bootloader to do this for you when
the hardware provides a perfectly good mechanism for probing
for the existence of the hardware? "Ask the hardware" is always
going to be a more reliable and foolproof way to get the answer
if you can do it -- device tree should just be for the cases where
there is no way to probe. In any case the only way for the boot
loader to determine the correct value to put into the device tree
would be to read the register itself.
> I suspect that either the existing behavior is completely bogus because
> the driver always reads what it write before, and then you can skip
> the logic completely, or your new driver is broken because reading
> the register without writing it first will result in undefined behavior
> on real hardware.
The documentation describes this register as:
# The SYS_PCICTL register at 0x10000044 enables the bridge to the PCI bus:
#
# * Setting bit 0 HIGH enables PCI bus accesses.
# * Read returns a HIGH in bit 0 if a PCI board is present
# in the expansion backplane.
ie the read and write behaviour is independent. So I suspect
that this new driver's failure to write 1 means that it
will break PCI on real hardware. (QEMU doesn't attempt to
model this behaviour: SYS_PCICTL will always read-as-one,
writes-ignored.)
thanks
-- PMM
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 3/9] ARM: versatile: add DT based PCI detection
@ 2014-12-31 16:13 ` Peter Maydell
0 siblings, 0 replies; 86+ messages in thread
From: Peter Maydell @ 2014-12-31 16:13 UTC (permalink / raw)
To: linux-arm-kernel
On 31 December 2014 at 15:23, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 30 December 2014 17:05:16 Rob Herring wrote:
>> Because the register to check is not part of the PCI controller, but
>> part of the system registers. There was no infrastructure for the
>> system registers when I originally wrote this, but there's some syscon
>> support now for VExpress that may be able to be used. I think it is
>> cleaner if we can avoid syscon dependencies in drivers in general, but
>> it is pretty much zero chance the Versatile PCI driver will ever be
>> used on another platform.
>
> Ok, I see. I guess ideally we would get a correct DTB file from the boot
> loader, but that is of course completely unrealistic on versatile, both
> on hardware and qemu.
Why would you want to get the bootloader to do this for you when
the hardware provides a perfectly good mechanism for probing
for the existence of the hardware? "Ask the hardware" is always
going to be a more reliable and foolproof way to get the answer
if you can do it -- device tree should just be for the cases where
there is no way to probe. In any case the only way for the boot
loader to determine the correct value to put into the device tree
would be to read the register itself.
> I suspect that either the existing behavior is completely bogus because
> the driver always reads what it write before, and then you can skip
> the logic completely, or your new driver is broken because reading
> the register without writing it first will result in undefined behavior
> on real hardware.
The documentation describes this register as:
# The SYS_PCICTL register at 0x10000044 enables the bridge to the PCI bus:
#
# * Setting bit 0 HIGH enables PCI bus accesses.
# * Read returns a HIGH in bit 0 if a PCI board is present
# in the expansion backplane.
ie the read and write behaviour is independent. So I suspect
that this new driver's failure to write 1 means that it
will break PCI on real hardware. (QEMU doesn't attempt to
model this behaviour: SYS_PCICTL will always read-as-one,
writes-ignored.)
thanks
-- PMM
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 3/9] ARM: versatile: add DT based PCI detection
2014-12-31 16:13 ` Peter Maydell
@ 2014-12-31 19:22 ` Rob Herring
-1 siblings, 0 replies; 86+ messages in thread
From: Rob Herring @ 2014-12-31 19:22 UTC (permalink / raw)
To: Peter Maydell
Cc: Arnd Bergmann, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Russell King, Linus Walleij,
arm-DgEjT+Ai2ygdnm+yROfE0A, Bjorn Helgaas
On Wed, Dec 31, 2014 at 10:13 AM, Peter Maydell
<peter.maydell-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> On 31 December 2014 at 15:23, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
>> On Tuesday 30 December 2014 17:05:16 Rob Herring wrote:
>>> Because the register to check is not part of the PCI controller, but
>>> part of the system registers. There was no infrastructure for the
>>> system registers when I originally wrote this, but there's some syscon
>>> support now for VExpress that may be able to be used. I think it is
>>> cleaner if we can avoid syscon dependencies in drivers in general, but
>>> it is pretty much zero chance the Versatile PCI driver will ever be
>>> used on another platform.
>>
>> Ok, I see. I guess ideally we would get a correct DTB file from the boot
>> loader, but that is of course completely unrealistic on versatile, both
>> on hardware and qemu.
>
> Why would you want to get the bootloader to do this for you when
> the hardware provides a perfectly good mechanism for probing
> for the existence of the hardware? "Ask the hardware" is always
> going to be a more reliable and foolproof way to get the answer
> if you can do it -- device tree should just be for the cases where
> there is no way to probe. In any case the only way for the boot
> loader to determine the correct value to put into the device tree
> would be to read the register itself.
Only that it is nice to hide all the ugly bits in the
bootloader/firmware and DT already provides a standard way to enable
or disable h/w. This h/w is not probeable in any sort of standard way.
>> I suspect that either the existing behavior is completely bogus because
>> the driver always reads what it write before, and then you can skip
>> the logic completely, or your new driver is broken because reading
>> the register without writing it first will result in undefined behavior
>> on real hardware.
>
> The documentation describes this register as:
>
> # The SYS_PCICTL register at 0x10000044 enables the bridge to the PCI bus:
> #
> # * Setting bit 0 HIGH enables PCI bus accesses.
> # * Read returns a HIGH in bit 0 if a PCI board is present
> # in the expansion backplane.
>
> ie the read and write behaviour is independent. So I suspect
> that this new driver's failure to write 1 means that it
> will break PCI on real hardware. (QEMU doesn't attempt to
> model this behaviour: SYS_PCICTL will always read-as-one,
> writes-ignored.)
>From Table 4.4, I came to the conclusion that the write wasn't really necessary:
SYS_PCICTL 0x10000044 Read only -Read returns a HIGH in bit [0] if
a PCI board is present in the expansion backplane.
I'll add it back.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 3/9] ARM: versatile: add DT based PCI detection
@ 2014-12-31 19:22 ` Rob Herring
0 siblings, 0 replies; 86+ messages in thread
From: Rob Herring @ 2014-12-31 19:22 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Dec 31, 2014 at 10:13 AM, Peter Maydell
<peter.maydell@linaro.org> wrote:
> On 31 December 2014 at 15:23, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Tuesday 30 December 2014 17:05:16 Rob Herring wrote:
>>> Because the register to check is not part of the PCI controller, but
>>> part of the system registers. There was no infrastructure for the
>>> system registers when I originally wrote this, but there's some syscon
>>> support now for VExpress that may be able to be used. I think it is
>>> cleaner if we can avoid syscon dependencies in drivers in general, but
>>> it is pretty much zero chance the Versatile PCI driver will ever be
>>> used on another platform.
>>
>> Ok, I see. I guess ideally we would get a correct DTB file from the boot
>> loader, but that is of course completely unrealistic on versatile, both
>> on hardware and qemu.
>
> Why would you want to get the bootloader to do this for you when
> the hardware provides a perfectly good mechanism for probing
> for the existence of the hardware? "Ask the hardware" is always
> going to be a more reliable and foolproof way to get the answer
> if you can do it -- device tree should just be for the cases where
> there is no way to probe. In any case the only way for the boot
> loader to determine the correct value to put into the device tree
> would be to read the register itself.
Only that it is nice to hide all the ugly bits in the
bootloader/firmware and DT already provides a standard way to enable
or disable h/w. This h/w is not probeable in any sort of standard way.
>> I suspect that either the existing behavior is completely bogus because
>> the driver always reads what it write before, and then you can skip
>> the logic completely, or your new driver is broken because reading
>> the register without writing it first will result in undefined behavior
>> on real hardware.
>
> The documentation describes this register as:
>
> # The SYS_PCICTL register at 0x10000044 enables the bridge to the PCI bus:
> #
> # * Setting bit 0 HIGH enables PCI bus accesses.
> # * Read returns a HIGH in bit 0 if a PCI board is present
> # in the expansion backplane.
>
> ie the read and write behaviour is independent. So I suspect
> that this new driver's failure to write 1 means that it
> will break PCI on real hardware. (QEMU doesn't attempt to
> model this behaviour: SYS_PCICTL will always read-as-one,
> writes-ignored.)
>From Table 4.4, I came to the conclusion that the write wasn't really necessary:
SYS_PCICTL 0x10000044 Read only -Read returns a HIGH in bit [0] if
a PCI board is present in the expansion backplane.
I'll add it back.
Rob
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 3/9] ARM: versatile: add DT based PCI detection
2014-12-31 19:22 ` Rob Herring
@ 2014-12-31 21:07 ` Peter Maydell
-1 siblings, 0 replies; 86+ messages in thread
From: Peter Maydell @ 2014-12-31 21:07 UTC (permalink / raw)
To: Rob Herring
Cc: Arnd Bergmann, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Russell King, Linus Walleij,
arm-DgEjT+Ai2ygdnm+yROfE0A, Bjorn Helgaas
On 31 December 2014 at 19:22, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Wed, Dec 31, 2014 at 10:13 AM, Peter Maydell
> <peter.maydell-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>> Why would you want to get the bootloader to do this for you when
>> the hardware provides a perfectly good mechanism for probing
>> for the existence of the hardware? "Ask the hardware" is always
>> going to be a more reliable and foolproof way to get the answer
>> if you can do it -- device tree should just be for the cases where
>> there is no way to probe. In any case the only way for the boot
>> loader to determine the correct value to put into the device tree
>> would be to read the register itself.
>
> Only that it is nice to hide all the ugly bits in the
> bootloader/firmware and DT already provides a standard way to enable
> or disable h/w. This h/w is not probeable in any sort of standard way.
This is an embedded system, you were expecting some kind of
standard? :-) I believe that SYS_PCICTL tells you whether
you're going to find the PCI controller or a decode error
at the addresses in the memory map where the PCI controller
usually lives, so robustness suggests it's worth retaining
the check in the kernel. [I'd want to check this on hardware
but my current belief is that if there's no backplane attached
then the register will read zero and the PCI controller register
space will abort with decode errors.]
> From Table 4.4, I came to the conclusion that the write wasn't really necessary:
>
> SYS_PCICTL 0x10000044 Read only -Read returns a HIGH in bit [0] if
> a PCI board is present in the expansion backplane.
>
> I'll add it back.
The self-contradictory VersatilePB docs strike again, I see.
Interestingly, in the PB1176 docs this register is documented
as definitely read/only:
# [1]Read only: Reserved.
#
# Note
#
# On the RealView Platform Baseboard for ARM926EJ-S, this bit
# was PCICONTROLIN signal and indicated that 66MHz mode was
# enabled. The PB1176JZF-S only supports 33MHz operation.
#
# [0]Read only: Status of P_DETECT pin.
...and in passing provides some info about the 926 board that
isn't in the docs for the 926!
A little digging suggests that it may in fact be the case
that the 1176 docs are correct and the write to bit 0 does
nothing. However the safest thing here is to keep doing
what the old kernel did, I think.
thanks
-- PMM
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 3/9] ARM: versatile: add DT based PCI detection
@ 2014-12-31 21:07 ` Peter Maydell
0 siblings, 0 replies; 86+ messages in thread
From: Peter Maydell @ 2014-12-31 21:07 UTC (permalink / raw)
To: linux-arm-kernel
On 31 December 2014 at 19:22, Rob Herring <robherring2@gmail.com> wrote:
> On Wed, Dec 31, 2014 at 10:13 AM, Peter Maydell
> <peter.maydell@linaro.org> wrote:
>> Why would you want to get the bootloader to do this for you when
>> the hardware provides a perfectly good mechanism for probing
>> for the existence of the hardware? "Ask the hardware" is always
>> going to be a more reliable and foolproof way to get the answer
>> if you can do it -- device tree should just be for the cases where
>> there is no way to probe. In any case the only way for the boot
>> loader to determine the correct value to put into the device tree
>> would be to read the register itself.
>
> Only that it is nice to hide all the ugly bits in the
> bootloader/firmware and DT already provides a standard way to enable
> or disable h/w. This h/w is not probeable in any sort of standard way.
This is an embedded system, you were expecting some kind of
standard? :-) I believe that SYS_PCICTL tells you whether
you're going to find the PCI controller or a decode error
at the addresses in the memory map where the PCI controller
usually lives, so robustness suggests it's worth retaining
the check in the kernel. [I'd want to check this on hardware
but my current belief is that if there's no backplane attached
then the register will read zero and the PCI controller register
space will abort with decode errors.]
> From Table 4.4, I came to the conclusion that the write wasn't really necessary:
>
> SYS_PCICTL 0x10000044 Read only -Read returns a HIGH in bit [0] if
> a PCI board is present in the expansion backplane.
>
> I'll add it back.
The self-contradictory VersatilePB docs strike again, I see.
Interestingly, in the PB1176 docs this register is documented
as definitely read/only:
# [1]Read only: Reserved.
#
# Note
#
# On the RealView Platform Baseboard for ARM926EJ-S, this bit
# was PCICONTROLIN signal and indicated that 66MHz mode was
# enabled. The PB1176JZF-S only supports 33MHz operation.
#
# [0]Read only: Status of P_DETECT pin.
...and in passing provides some info about the 926 board that
isn't in the docs for the 926!
A little digging suggests that it may in fact be the case
that the 1176 docs are correct and the write to bit 0 does
nothing. However the safest thing here is to keep doing
what the old kernel did, I think.
thanks
-- PMM
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 3/9] ARM: versatile: add DT based PCI detection
2014-12-31 21:07 ` Peter Maydell
@ 2015-01-01 15:35 ` Arnd Bergmann
-1 siblings, 0 replies; 86+ messages in thread
From: Arnd Bergmann @ 2015-01-01 15:35 UTC (permalink / raw)
To: Peter Maydell
Cc: Rob Herring, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Russell King, Linus Walleij,
arm-DgEjT+Ai2ygdnm+yROfE0A, Bjorn Helgaas
On Wednesday 31 December 2014 21:07:25 Peter Maydell wrote:
> On 31 December 2014 at 19:22, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > On Wed, Dec 31, 2014 at 10:13 AM, Peter Maydell
> > <peter.maydell-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> >> Why would you want to get the bootloader to do this for you when
> >> the hardware provides a perfectly good mechanism for probing
> >> for the existence of the hardware? "Ask the hardware" is always
> >> going to be a more reliable and foolproof way to get the answer
> >> if you can do it -- device tree should just be for the cases where
> >> there is no way to probe. In any case the only way for the boot
> >> loader to determine the correct value to put into the device tree
> >> would be to read the register itself.
> >
> > Only that it is nice to hide all the ugly bits in the
> > bootloader/firmware and DT already provides a standard way to enable
> > or disable h/w. This h/w is not probeable in any sort of standard way.
>
> This is an embedded system, you were expecting some kind of
> standard?
But that is exactly the point: While we try to ask the hardware about
anything that can be reasonably queried through an in-kernel interface
that talks to the hardware, it works less well when that hardware interface
is rather obscure and (like this one) only used on a few special machines.
Similar examples are Marvell's SoC ID register, which you have to read by
powering on the PCI host bridge and reading the Vendor/Device ID registers
for the root bus, or the 'nvram' on Broadcom's wifi router chips that is
in reality a partition on either NOR or NAND flash. Accessing those at
early boot from a random device driver is a real pain, and it would be
much nicer to have the boot loader read them and put the data into the
DT for us if we had the option. Unfortunately we have to deal with legacy
boot loaders that don't change the DTB.
> > From Table 4.4, I came to the conclusion that the write wasn't really necessary:
> >
> > SYS_PCICTL 0x10000044 Read only -Read returns a HIGH in bit [0] if
> > a PCI board is present in the expansion backplane.
> >
> > I'll add it back.
>
> The self-contradictory VersatilePB docs strike again, I see.
> Interestingly, in the PB1176 docs this register is documented
> as definitely read/only:
>
> # [1]Read only: Reserved.
> #
> # Note
> #
> # On the RealView Platform Baseboard for ARM926EJ-S, this bit
> # was PCICONTROLIN signal and indicated that 66MHz mode was
> # enabled. The PB1176JZF-S only supports 33MHz operation.
> #
> # [0]Read only: Status of P_DETECT pin.
>
> ...and in passing provides some info about the 926 board that
> isn't in the docs for the 926!
>
> A little digging suggests that it may in fact be the case
> that the 1176 docs are correct and the write to bit 0 does
> nothing. However the safest thing here is to keep doing
> what the old kernel did, I think.
Agreed. This also means that we need a way to access that register
anyway, and any discussion about finding a way to move the read
access for probing the device elsewhere is moot. A syscon device node
would probably be best, but the current approach also works.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 3/9] ARM: versatile: add DT based PCI detection
@ 2015-01-01 15:35 ` Arnd Bergmann
0 siblings, 0 replies; 86+ messages in thread
From: Arnd Bergmann @ 2015-01-01 15:35 UTC (permalink / raw)
To: linux-arm-kernel
On Wednesday 31 December 2014 21:07:25 Peter Maydell wrote:
> On 31 December 2014 at 19:22, Rob Herring <robherring2@gmail.com> wrote:
> > On Wed, Dec 31, 2014 at 10:13 AM, Peter Maydell
> > <peter.maydell@linaro.org> wrote:
> >> Why would you want to get the bootloader to do this for you when
> >> the hardware provides a perfectly good mechanism for probing
> >> for the existence of the hardware? "Ask the hardware" is always
> >> going to be a more reliable and foolproof way to get the answer
> >> if you can do it -- device tree should just be for the cases where
> >> there is no way to probe. In any case the only way for the boot
> >> loader to determine the correct value to put into the device tree
> >> would be to read the register itself.
> >
> > Only that it is nice to hide all the ugly bits in the
> > bootloader/firmware and DT already provides a standard way to enable
> > or disable h/w. This h/w is not probeable in any sort of standard way.
>
> This is an embedded system, you were expecting some kind of
> standard?
But that is exactly the point: While we try to ask the hardware about
anything that can be reasonably queried through an in-kernel interface
that talks to the hardware, it works less well when that hardware interface
is rather obscure and (like this one) only used on a few special machines.
Similar examples are Marvell's SoC ID register, which you have to read by
powering on the PCI host bridge and reading the Vendor/Device ID registers
for the root bus, or the 'nvram' on Broadcom's wifi router chips that is
in reality a partition on either NOR or NAND flash. Accessing those at
early boot from a random device driver is a real pain, and it would be
much nicer to have the boot loader read them and put the data into the
DT for us if we had the option. Unfortunately we have to deal with legacy
boot loaders that don't change the DTB.
> > From Table 4.4, I came to the conclusion that the write wasn't really necessary:
> >
> > SYS_PCICTL 0x10000044 Read only -Read returns a HIGH in bit [0] if
> > a PCI board is present in the expansion backplane.
> >
> > I'll add it back.
>
> The self-contradictory VersatilePB docs strike again, I see.
> Interestingly, in the PB1176 docs this register is documented
> as definitely read/only:
>
> # [1]Read only: Reserved.
> #
> # Note
> #
> # On the RealView Platform Baseboard for ARM926EJ-S, this bit
> # was PCICONTROLIN signal and indicated that 66MHz mode was
> # enabled. The PB1176JZF-S only supports 33MHz operation.
> #
> # [0]Read only: Status of P_DETECT pin.
>
> ...and in passing provides some info about the 926 board that
> isn't in the docs for the 926!
>
> A little digging suggests that it may in fact be the case
> that the 1176 docs are correct and the write to bit 0 does
> nothing. However the safest thing here is to keep doing
> what the old kernel did, I think.
Agreed. This also means that we need a way to access that register
anyway, and any discussion about finding a way to move the read
access for probing the device elsewhere is moot. A syscon device node
would probably be best, but the current approach also works.
Arnd
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 3/9] ARM: versatile: add DT based PCI detection
2015-01-01 15:35 ` Arnd Bergmann
@ 2015-01-01 15:52 ` Peter Maydell
-1 siblings, 0 replies; 86+ messages in thread
From: Peter Maydell @ 2015-01-01 15:52 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Rob Herring, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Russell King, Linus Walleij,
arm-DgEjT+Ai2ygdnm+yROfE0A, Bjorn Helgaas
On 1 January 2015 at 15:35, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> But that is exactly the point: While we try to ask the hardware about
> anything that can be reasonably queried through an in-kernel interface
> that talks to the hardware, it works less well when that hardware interface
> is rather obscure and (like this one) only used on a few special machines.
"We put this random collection of status bits in to a register somewhere
because it was convenient for the h/w engineers" is pretty common, I think.
> Similar examples are Marvell's SoC ID register, which you have to read by
> powering on the PCI host bridge and reading the Vendor/Device ID registers
> for the root bus, or the 'nvram' on Broadcom's wifi router chips that is
> in reality a partition on either NOR or NAND flash. Accessing those at
> early boot from a random device driver is a real pain, and it would be
> much nicer to have the boot loader read them and put the data into the
> DT for us if we had the option. Unfortunately we have to deal with legacy
> boot loaders that don't change the DTB.
I don't think it's going to be any easier for the boot loader, which
is quite possibly totally uninterested in PCI and would have
no reason to need to prod this location on the versatilepb. I also trust
the kernel much more to get bugfixes and be easily updatable. I appreciate
that it's more work for you if you can't just say "punt this nastiness
to the bootloader", but I think it's also the better (more robust
and self-contained) design.
-- PMM
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 3/9] ARM: versatile: add DT based PCI detection
@ 2015-01-01 15:52 ` Peter Maydell
0 siblings, 0 replies; 86+ messages in thread
From: Peter Maydell @ 2015-01-01 15:52 UTC (permalink / raw)
To: linux-arm-kernel
On 1 January 2015 at 15:35, Arnd Bergmann <arnd@arndb.de> wrote:
> But that is exactly the point: While we try to ask the hardware about
> anything that can be reasonably queried through an in-kernel interface
> that talks to the hardware, it works less well when that hardware interface
> is rather obscure and (like this one) only used on a few special machines.
"We put this random collection of status bits in to a register somewhere
because it was convenient for the h/w engineers" is pretty common, I think.
> Similar examples are Marvell's SoC ID register, which you have to read by
> powering on the PCI host bridge and reading the Vendor/Device ID registers
> for the root bus, or the 'nvram' on Broadcom's wifi router chips that is
> in reality a partition on either NOR or NAND flash. Accessing those at
> early boot from a random device driver is a real pain, and it would be
> much nicer to have the boot loader read them and put the data into the
> DT for us if we had the option. Unfortunately we have to deal with legacy
> boot loaders that don't change the DTB.
I don't think it's going to be any easier for the boot loader, which
is quite possibly totally uninterested in PCI and would have
no reason to need to prod this location on the versatilepb. I also trust
the kernel much more to get bugfixes and be easily updatable. I appreciate
that it's more work for you if you can't just say "punt this nastiness
to the bootloader", but I think it's also the better (more robust
and self-contained) design.
-- PMM
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 4/9] pci: add DT based ARM Versatile PCI host driver
2014-12-30 21:58 ` Arnd Bergmann
@ 2015-01-02 18:14 ` Rob Herring
-1 siblings, 0 replies; 86+ messages in thread
From: Rob Herring @ 2015-01-02 18:14 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, devicetree, Peter Maydell, Russell King,
linux-pci, Linus Walleij, arm, Bjorn Helgaas
On Tue, Dec 30, 2014 at 3:58 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 30 December 2014 13:28:33 Rob Herring wrote:
>> From: Rob Herring <robh@kernel.org>
>>
>> This converts the Versatile PCI host code to a platform driver using
>> the commom DT parsing and setup. The driver uses only an empty ARM
>> pci_sys_data struct and does not use pci_common_init_dev init function.
>> The old host code will be removed in a subsequent commit when Versatile
>> is completely converted to DT.
>>
>> I've tested this on QEMU with the sym53c8xx driver in both i/o and
>> memory mapped modes.
>
> Ah, this is quite clever, I think you tried to explain to me what you
> did with the pci_sys_data before, but I didn't get it then.
>
>> +
>> +static void __iomem *__pci_addr(struct pci_bus *bus,
>> + unsigned int devfn, int offset)
>> +{
>> + unsigned int busnr = bus->number;
>> +
>> + /*
>> + * Trap out illegal values
>> + */
>> + BUG_ON(offset > 255);
>> + BUG_ON(busnr > 255);
>> + BUG_ON(devfn > 255);
>
> Isn't an offset>255 something that can be triggered by a non-broken
> driver or even user space?
I don't know. I just copied what the old driver did. Are these checks
even host controller specific?
> Maybe just return PCIBIOS_BAD_REGISTER_NUMBER in this case?
Perhaps. We could probably simplify the config space read/write
functions and just provide the PCI core a bus/devfn/offset to config
address translation function. That would not work in all cases, but
propably most that have memory mapped config space.
>> +static int versatile_pci_parse_request_of_pci_ranges(struct device *dev,
>> + struct list_head *res)
>> +{
>> + int err, mem = 1, res_valid = 0;
>> + struct device_node *np = dev->of_node;
>> + resource_size_t iobase;
>> + struct pci_host_bridge_window *win;
>> +
>> + err = of_pci_get_host_bridge_resources(np, 0, 0xff, res, &iobase);
>> + if (err)
>> + return err;
>> +
>> + list_for_each_entry(win, res, list) {
>> + struct resource *parent, *res = win->res;
>> +
>> + switch (resource_type(res)) {
>> + case IORESOURCE_IO:
>> + parent = &ioport_resource;
>> + err = pci_remap_iospace(res, iobase);
>> + if (err) {
>> + dev_warn(dev, "error %d: failed to map resource %pR\n",
>> + err, res);
>> + continue;
>> + }
>> + break;
>> + case IORESOURCE_MEM:
>> + parent = &iomem_resource;
>> + res_valid |= !(res->flags & IORESOURCE_PREFETCH);
>> +
>> + writel(res->start >> 28, PCI_IMAP(mem));
>> + writel(PHYS_OFFSET >> 28, PCI_SMAP(mem));
>> + mem++;
>> +
>> + break;
>> + case IORESOURCE_BUS:
>> + default:
>> + continue;
>> + }
>> +
>> + err = devm_request_resource(dev, parent, res);
>> + if (err)
>> + goto out_release_res;
>> + }
>
> I wonder if we should also request the physical resource for the I/O space
> window to have it show up in /proc/iomem. We are rather inconsistent in this
> regard between drivers.
It's a little complicated now because we don't have that as a struct
resource any more. We could reconstruct it from iobase and the i/o
resource size.
>
>> + pci_add_flags(PCI_ENABLE_PROC_DOMAINS);
>> + pci_add_flags(PCI_REASSIGN_ALL_BUS | PCI_REASSIGN_ALL_RSRC);
>> +
>> + bus = pci_scan_root_bus(&pdev->dev, 0, &pci_versatile_ops, &sys, &pci_res);
>> + if (!bus)
>> + return -ENOMEM;
>> +
>> + pci_fixup_irqs(pci_common_swizzle, of_irq_parse_and_map_pci);
>> + pci_assign_unassigned_bus_resources(bus);
>> +
>> + return 0;
>
> One general question, mainly for Bjorn: pci_scan_root_bus adds all the devices
> at the Linux driver level by calling pci_bus_add_devices(), but then we call
> pci_fixup_irqs and pci_assign_unassigned_bus_resources after that, which will
> change the devices again. Is this how it's meant to work? How do we ensure
> that we have the correct irq number and resources by the time we enter the
> probe() function of the PCI device driver that gets bound to a device here?
I'm a bit puzzled myself. I think that the devices are not probed
until after pci_assign_unassigned_bus_resources. It certainly doesn't
work without that call. Really, I think of_irq_parse_and_map_pci
should be the default if no one else has set the device's irq (and the
host has a device node of course).
It also seems to be a bit of random set of pci functions that are
called here. It would be nice to simplify this chunk of code.
Rob
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 4/9] pci: add DT based ARM Versatile PCI host driver
@ 2015-01-02 18:14 ` Rob Herring
0 siblings, 0 replies; 86+ messages in thread
From: Rob Herring @ 2015-01-02 18:14 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Dec 30, 2014 at 3:58 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 30 December 2014 13:28:33 Rob Herring wrote:
>> From: Rob Herring <robh@kernel.org>
>>
>> This converts the Versatile PCI host code to a platform driver using
>> the commom DT parsing and setup. The driver uses only an empty ARM
>> pci_sys_data struct and does not use pci_common_init_dev init function.
>> The old host code will be removed in a subsequent commit when Versatile
>> is completely converted to DT.
>>
>> I've tested this on QEMU with the sym53c8xx driver in both i/o and
>> memory mapped modes.
>
> Ah, this is quite clever, I think you tried to explain to me what you
> did with the pci_sys_data before, but I didn't get it then.
>
>> +
>> +static void __iomem *__pci_addr(struct pci_bus *bus,
>> + unsigned int devfn, int offset)
>> +{
>> + unsigned int busnr = bus->number;
>> +
>> + /*
>> + * Trap out illegal values
>> + */
>> + BUG_ON(offset > 255);
>> + BUG_ON(busnr > 255);
>> + BUG_ON(devfn > 255);
>
> Isn't an offset>255 something that can be triggered by a non-broken
> driver or even user space?
I don't know. I just copied what the old driver did. Are these checks
even host controller specific?
> Maybe just return PCIBIOS_BAD_REGISTER_NUMBER in this case?
Perhaps. We could probably simplify the config space read/write
functions and just provide the PCI core a bus/devfn/offset to config
address translation function. That would not work in all cases, but
propably most that have memory mapped config space.
>> +static int versatile_pci_parse_request_of_pci_ranges(struct device *dev,
>> + struct list_head *res)
>> +{
>> + int err, mem = 1, res_valid = 0;
>> + struct device_node *np = dev->of_node;
>> + resource_size_t iobase;
>> + struct pci_host_bridge_window *win;
>> +
>> + err = of_pci_get_host_bridge_resources(np, 0, 0xff, res, &iobase);
>> + if (err)
>> + return err;
>> +
>> + list_for_each_entry(win, res, list) {
>> + struct resource *parent, *res = win->res;
>> +
>> + switch (resource_type(res)) {
>> + case IORESOURCE_IO:
>> + parent = &ioport_resource;
>> + err = pci_remap_iospace(res, iobase);
>> + if (err) {
>> + dev_warn(dev, "error %d: failed to map resource %pR\n",
>> + err, res);
>> + continue;
>> + }
>> + break;
>> + case IORESOURCE_MEM:
>> + parent = &iomem_resource;
>> + res_valid |= !(res->flags & IORESOURCE_PREFETCH);
>> +
>> + writel(res->start >> 28, PCI_IMAP(mem));
>> + writel(PHYS_OFFSET >> 28, PCI_SMAP(mem));
>> + mem++;
>> +
>> + break;
>> + case IORESOURCE_BUS:
>> + default:
>> + continue;
>> + }
>> +
>> + err = devm_request_resource(dev, parent, res);
>> + if (err)
>> + goto out_release_res;
>> + }
>
> I wonder if we should also request the physical resource for the I/O space
> window to have it show up in /proc/iomem. We are rather inconsistent in this
> regard between drivers.
It's a little complicated now because we don't have that as a struct
resource any more. We could reconstruct it from iobase and the i/o
resource size.
>
>> + pci_add_flags(PCI_ENABLE_PROC_DOMAINS);
>> + pci_add_flags(PCI_REASSIGN_ALL_BUS | PCI_REASSIGN_ALL_RSRC);
>> +
>> + bus = pci_scan_root_bus(&pdev->dev, 0, &pci_versatile_ops, &sys, &pci_res);
>> + if (!bus)
>> + return -ENOMEM;
>> +
>> + pci_fixup_irqs(pci_common_swizzle, of_irq_parse_and_map_pci);
>> + pci_assign_unassigned_bus_resources(bus);
>> +
>> + return 0;
>
> One general question, mainly for Bjorn: pci_scan_root_bus adds all the devices
> at the Linux driver level by calling pci_bus_add_devices(), but then we call
> pci_fixup_irqs and pci_assign_unassigned_bus_resources after that, which will
> change the devices again. Is this how it's meant to work? How do we ensure
> that we have the correct irq number and resources by the time we enter the
> probe() function of the PCI device driver that gets bound to a device here?
I'm a bit puzzled myself. I think that the devices are not probed
until after pci_assign_unassigned_bus_resources. It certainly doesn't
work without that call. Really, I think of_irq_parse_and_map_pci
should be the default if no one else has set the device's irq (and the
host has a device node of course).
It also seems to be a bit of random set of pci functions that are
called here. It would be nice to simplify this chunk of code.
Rob
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 4/9] pci: add DT based ARM Versatile PCI host driver
2015-01-02 18:14 ` Rob Herring
@ 2015-01-02 20:52 ` Arnd Bergmann
-1 siblings, 0 replies; 86+ messages in thread
From: Arnd Bergmann @ 2015-01-02 20:52 UTC (permalink / raw)
To: Rob Herring
Cc: linux-arm-kernel, devicetree, Peter Maydell, Russell King,
linux-pci, Linus Walleij, arm, Bjorn Helgaas
On Friday 02 January 2015 12:14:43 Rob Herring wrote:
> On Tue, Dec 30, 2014 at 3:58 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Tuesday 30 December 2014 13:28:33 Rob Herring wrote:
> >> From: Rob Herring <robh@kernel.org>
> >>
> >> This converts the Versatile PCI host code to a platform driver using
> >> the commom DT parsing and setup. The driver uses only an empty ARM
> >> pci_sys_data struct and does not use pci_common_init_dev init function.
> >> The old host code will be removed in a subsequent commit when Versatile
> >> is completely converted to DT.
> >>
> >> I've tested this on QEMU with the sym53c8xx driver in both i/o and
> >> memory mapped modes.
> >
> > Ah, this is quite clever, I think you tried to explain to me what you
> > did with the pci_sys_data before, but I didn't get it then.
> >
> >> +
> >> +static void __iomem *__pci_addr(struct pci_bus *bus,
> >> + unsigned int devfn, int offset)
> >> +{
> >> + unsigned int busnr = bus->number;
> >> +
> >> + /*
> >> + * Trap out illegal values
> >> + */
> >> + BUG_ON(offset > 255);
> >> + BUG_ON(busnr > 255);
> >> + BUG_ON(devfn > 255);
> >
> > Isn't an offset>255 something that can be triggered by a non-broken
> > driver or even user space?
>
> I don't know. I just copied what the old driver did. Are these checks
> even host controller specific?
A busnr or devfn larger than 255 would be a serious bug on any host
controller, those just don't exist. A BUG_ON check here is not a problem,
but if we want to have it, I'd prefer to put it into the core code.
offset values between 256 and 4095 can be valid on some devices, but
apparently this host controller does not support them.
> > Maybe just return PCIBIOS_BAD_REGISTER_NUMBER in this case?
>
> Perhaps. We could probably simplify the config space read/write
> functions and just provide the PCI core a bus/devfn/offset to config
> address translation function. That would not work in all cases, but
> propably most that have memory mapped config space.
Actually, thinking about this some more, the implementation seems to
be "CAM" compliant, and we could share the confic space accessors with
the ones from drivers/pci/host/pci-host-generic.c.
> >> +static int versatile_pci_parse_request_of_pci_ranges(struct device *dev,
> >> + struct list_head *res)
> >> +{
> >> + int err, mem = 1, res_valid = 0;
> >> + struct device_node *np = dev->of_node;
> >> + resource_size_t iobase;
> >> + struct pci_host_bridge_window *win;
> >> +
> >> + err = of_pci_get_host_bridge_resources(np, 0, 0xff, res, &iobase);
> >> + if (err)
> >> + return err;
> >> +
> >> + list_for_each_entry(win, res, list) {
> >> + struct resource *parent, *res = win->res;
> >> +
> >> + switch (resource_type(res)) {
> >> + case IORESOURCE_IO:
> >> + parent = &ioport_resource;
> >> + err = pci_remap_iospace(res, iobase);
> >> + if (err) {
> >> + dev_warn(dev, "error %d: failed to map resource %pR\n",
> >> + err, res);
> >> + continue;
> >> + }
> >> + break;
> >> + case IORESOURCE_MEM:
> >> + parent = &iomem_resource;
> >> + res_valid |= !(res->flags & IORESOURCE_PREFETCH);
> >> +
> >> + writel(res->start >> 28, PCI_IMAP(mem));
> >> + writel(PHYS_OFFSET >> 28, PCI_SMAP(mem));
> >> + mem++;
> >> +
> >> + break;
> >> + case IORESOURCE_BUS:
> >> + default:
> >> + continue;
> >> + }
> >> +
> >> + err = devm_request_resource(dev, parent, res);
> >> + if (err)
> >> + goto out_release_res;
> >> + }
> >
> > I wonder if we should also request the physical resource for the I/O space
> > window to have it show up in /proc/iomem. We are rather inconsistent in this
> > regard between drivers.
>
> It's a little complicated now because we don't have that as a struct
> resource any more. We could reconstruct it from iobase and the i/o
> resource size.
> >> + pci_add_flags(PCI_ENABLE_PROC_DOMAINS);
> >> + pci_add_flags(PCI_REASSIGN_ALL_BUS | PCI_REASSIGN_ALL_RSRC);
> >> +
> >> + bus = pci_scan_root_bus(&pdev->dev, 0, &pci_versatile_ops, &sys, &pci_res);
> >> + if (!bus)
> >> + return -ENOMEM;
> >> +
> >> + pci_fixup_irqs(pci_common_swizzle, of_irq_parse_and_map_pci);
> >> + pci_assign_unassigned_bus_resources(bus);
> >> +
> >> + return 0;
> >
> > One general question, mainly for Bjorn: pci_scan_root_bus adds all the devices
> > at the Linux driver level by calling pci_bus_add_devices(), but then we call
> > pci_fixup_irqs and pci_assign_unassigned_bus_resources after that, which will
> > change the devices again. Is this how it's meant to work? How do we ensure
> > that we have the correct irq number and resources by the time we enter the
> > probe() function of the PCI device driver that gets bound to a device here?
>
> I'm a bit puzzled myself. I think that the devices are not probed
> until after pci_assign_unassigned_bus_resources. It certainly doesn't
> work without that call. Really, I think of_irq_parse_and_map_pci
> should be the default if no one else has set the device's irq (and the
> host has a device node of course).
>
> It also seems to be a bit of random set of pci functions that are
> called here. It would be nice to simplify this chunk of code.
Yes, and we recently had some attempts at creating a better interface posted
on the mailing list, not sure what the latest status on it is. I think we
want to end up with a two-stage interface along the lines of:
/* allocate a pci_host_bridge, scan DT, set default operations, map
I/O space if necessary, request all resources ... */
phb = pci_host_bridge_create(parent, ..., sizeof(struct my_pci_private));
if (IS_ERR(phb))
return PTR_ERR(phb);
/* any host specific customization */
phb->bus->ops = my_pci_ops; /* for nonstandard config space access */
phb->foo = my_pci_foo; /* some other optional function pointers, replacing pcibios_* */
my_pci = &phb->priv; /* extra allocated data */
my_pci->clk = devm_clk_get(parent, "pci");
my_pci->regs = devm_ioremap_resource(parent, platform_get_resource(pdev,
IORESOURCE_MEM, 0);
/* scan everything */
return pci_scan_child_bus_and_add_devices(phb->bus);
Arnd
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 4/9] pci: add DT based ARM Versatile PCI host driver
@ 2015-01-02 20:52 ` Arnd Bergmann
0 siblings, 0 replies; 86+ messages in thread
From: Arnd Bergmann @ 2015-01-02 20:52 UTC (permalink / raw)
To: linux-arm-kernel
On Friday 02 January 2015 12:14:43 Rob Herring wrote:
> On Tue, Dec 30, 2014 at 3:58 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Tuesday 30 December 2014 13:28:33 Rob Herring wrote:
> >> From: Rob Herring <robh@kernel.org>
> >>
> >> This converts the Versatile PCI host code to a platform driver using
> >> the commom DT parsing and setup. The driver uses only an empty ARM
> >> pci_sys_data struct and does not use pci_common_init_dev init function.
> >> The old host code will be removed in a subsequent commit when Versatile
> >> is completely converted to DT.
> >>
> >> I've tested this on QEMU with the sym53c8xx driver in both i/o and
> >> memory mapped modes.
> >
> > Ah, this is quite clever, I think you tried to explain to me what you
> > did with the pci_sys_data before, but I didn't get it then.
> >
> >> +
> >> +static void __iomem *__pci_addr(struct pci_bus *bus,
> >> + unsigned int devfn, int offset)
> >> +{
> >> + unsigned int busnr = bus->number;
> >> +
> >> + /*
> >> + * Trap out illegal values
> >> + */
> >> + BUG_ON(offset > 255);
> >> + BUG_ON(busnr > 255);
> >> + BUG_ON(devfn > 255);
> >
> > Isn't an offset>255 something that can be triggered by a non-broken
> > driver or even user space?
>
> I don't know. I just copied what the old driver did. Are these checks
> even host controller specific?
A busnr or devfn larger than 255 would be a serious bug on any host
controller, those just don't exist. A BUG_ON check here is not a problem,
but if we want to have it, I'd prefer to put it into the core code.
offset values between 256 and 4095 can be valid on some devices, but
apparently this host controller does not support them.
> > Maybe just return PCIBIOS_BAD_REGISTER_NUMBER in this case?
>
> Perhaps. We could probably simplify the config space read/write
> functions and just provide the PCI core a bus/devfn/offset to config
> address translation function. That would not work in all cases, but
> propably most that have memory mapped config space.
Actually, thinking about this some more, the implementation seems to
be "CAM" compliant, and we could share the confic space accessors with
the ones from drivers/pci/host/pci-host-generic.c.
> >> +static int versatile_pci_parse_request_of_pci_ranges(struct device *dev,
> >> + struct list_head *res)
> >> +{
> >> + int err, mem = 1, res_valid = 0;
> >> + struct device_node *np = dev->of_node;
> >> + resource_size_t iobase;
> >> + struct pci_host_bridge_window *win;
> >> +
> >> + err = of_pci_get_host_bridge_resources(np, 0, 0xff, res, &iobase);
> >> + if (err)
> >> + return err;
> >> +
> >> + list_for_each_entry(win, res, list) {
> >> + struct resource *parent, *res = win->res;
> >> +
> >> + switch (resource_type(res)) {
> >> + case IORESOURCE_IO:
> >> + parent = &ioport_resource;
> >> + err = pci_remap_iospace(res, iobase);
> >> + if (err) {
> >> + dev_warn(dev, "error %d: failed to map resource %pR\n",
> >> + err, res);
> >> + continue;
> >> + }
> >> + break;
> >> + case IORESOURCE_MEM:
> >> + parent = &iomem_resource;
> >> + res_valid |= !(res->flags & IORESOURCE_PREFETCH);
> >> +
> >> + writel(res->start >> 28, PCI_IMAP(mem));
> >> + writel(PHYS_OFFSET >> 28, PCI_SMAP(mem));
> >> + mem++;
> >> +
> >> + break;
> >> + case IORESOURCE_BUS:
> >> + default:
> >> + continue;
> >> + }
> >> +
> >> + err = devm_request_resource(dev, parent, res);
> >> + if (err)
> >> + goto out_release_res;
> >> + }
> >
> > I wonder if we should also request the physical resource for the I/O space
> > window to have it show up in /proc/iomem. We are rather inconsistent in this
> > regard between drivers.
>
> It's a little complicated now because we don't have that as a struct
> resource any more. We could reconstruct it from iobase and the i/o
> resource size.
> >> + pci_add_flags(PCI_ENABLE_PROC_DOMAINS);
> >> + pci_add_flags(PCI_REASSIGN_ALL_BUS | PCI_REASSIGN_ALL_RSRC);
> >> +
> >> + bus = pci_scan_root_bus(&pdev->dev, 0, &pci_versatile_ops, &sys, &pci_res);
> >> + if (!bus)
> >> + return -ENOMEM;
> >> +
> >> + pci_fixup_irqs(pci_common_swizzle, of_irq_parse_and_map_pci);
> >> + pci_assign_unassigned_bus_resources(bus);
> >> +
> >> + return 0;
> >
> > One general question, mainly for Bjorn: pci_scan_root_bus adds all the devices
> > at the Linux driver level by calling pci_bus_add_devices(), but then we call
> > pci_fixup_irqs and pci_assign_unassigned_bus_resources after that, which will
> > change the devices again. Is this how it's meant to work? How do we ensure
> > that we have the correct irq number and resources by the time we enter the
> > probe() function of the PCI device driver that gets bound to a device here?
>
> I'm a bit puzzled myself. I think that the devices are not probed
> until after pci_assign_unassigned_bus_resources. It certainly doesn't
> work without that call. Really, I think of_irq_parse_and_map_pci
> should be the default if no one else has set the device's irq (and the
> host has a device node of course).
>
> It also seems to be a bit of random set of pci functions that are
> called here. It would be nice to simplify this chunk of code.
Yes, and we recently had some attempts at creating a better interface posted
on the mailing list, not sure what the latest status on it is. I think we
want to end up with a two-stage interface along the lines of:
/* allocate a pci_host_bridge, scan DT, set default operations, map
I/O space if necessary, request all resources ... */
phb = pci_host_bridge_create(parent, ..., sizeof(struct my_pci_private));
if (IS_ERR(phb))
return PTR_ERR(phb);
/* any host specific customization */
phb->bus->ops = my_pci_ops; /* for nonstandard config space access */
phb->foo = my_pci_foo; /* some other optional function pointers, replacing pcibios_* */
my_pci = &phb->priv; /* extra allocated data */
my_pci->clk = devm_clk_get(parent, "pci");
my_pci->regs = devm_ioremap_resource(parent, platform_get_resource(pdev,
IORESOURCE_MEM, 0);
/* scan everything */
return pci_scan_child_bus_and_add_devices(phb->bus);
Arnd
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 4/9] pci: add DT based ARM Versatile PCI host driver
2015-01-02 20:52 ` Arnd Bergmann
@ 2015-01-02 23:13 ` Rob Herring
-1 siblings, 0 replies; 86+ messages in thread
From: Rob Herring @ 2015-01-02 23:13 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, devicetree, Peter Maydell, Russell King,
linux-pci, Linus Walleij, arm, Bjorn Helgaas
On Fri, Jan 2, 2015 at 2:52 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday 02 January 2015 12:14:43 Rob Herring wrote:
>> On Tue, Dec 30, 2014 at 3:58 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Tuesday 30 December 2014 13:28:33 Rob Herring wrote:
>> >> From: Rob Herring <robh@kernel.org>
>> >>
>> >> This converts the Versatile PCI host code to a platform driver using
>> >> the commom DT parsing and setup. The driver uses only an empty ARM
>> >> pci_sys_data struct and does not use pci_common_init_dev init function.
>> >> The old host code will be removed in a subsequent commit when Versatile
>> >> is completely converted to DT.
>> >>
>> >> I've tested this on QEMU with the sym53c8xx driver in both i/o and
>> >> memory mapped modes.
>> >
>> > Ah, this is quite clever, I think you tried to explain to me what you
>> > did with the pci_sys_data before, but I didn't get it then.
>> >
>> >> +
>> >> +static void __iomem *__pci_addr(struct pci_bus *bus,
>> >> + unsigned int devfn, int offset)
>> >> +{
>> >> + unsigned int busnr = bus->number;
>> >> +
>> >> + /*
>> >> + * Trap out illegal values
>> >> + */
>> >> + BUG_ON(offset > 255);
>> >> + BUG_ON(busnr > 255);
>> >> + BUG_ON(devfn > 255);
>> >
>> > Isn't an offset>255 something that can be triggered by a non-broken
>> > driver or even user space?
>>
>> I don't know. I just copied what the old driver did. Are these checks
>> even host controller specific?
>
> A busnr or devfn larger than 255 would be a serious bug on any host
> controller, those just don't exist. A BUG_ON check here is not a problem,
> but if we want to have it, I'd prefer to put it into the core code.
Agreed.
> offset values between 256 and 4095 can be valid on some devices, but
> apparently this host controller does not support them.
I'm going to drop the checks. The only checks I see in other drivers
are for the bus number to match the root bus which I'm not convinced
are needed either.
>> > Maybe just return PCIBIOS_BAD_REGISTER_NUMBER in this case?
>>
>> Perhaps. We could probably simplify the config space read/write
>> functions and just provide the PCI core a bus/devfn/offset to config
>> address translation function. That would not work in all cases, but
>> propably most that have memory mapped config space.
>
> Actually, thinking about this some more, the implementation seems to
> be "CAM" compliant, and we could share the confic space accessors with
> the ones from drivers/pci/host/pci-host-generic.c.
Almost. It uses readl for all size accesses. Yet writes support
different access sizes. I would guess that the h/w can support byte
and word reads if writes are supported, but I can't really verify.
Dword-only sized reads or reads and writes seem to be the main
variations for config space accesses. There's a few hosts with more
complex config space access setup, but quite a few only vary in
address decode.
>> >> +static int versatile_pci_parse_request_of_pci_ranges(struct device *dev,
>> >> + struct list_head *res)
>> >> +{
>> >> + int err, mem = 1, res_valid = 0;
>> >> + struct device_node *np = dev->of_node;
>> >> + resource_size_t iobase;
>> >> + struct pci_host_bridge_window *win;
>> >> +
>> >> + err = of_pci_get_host_bridge_resources(np, 0, 0xff, res, &iobase);
>> >> + if (err)
>> >> + return err;
>> >> +
>> >> + list_for_each_entry(win, res, list) {
>> >> + struct resource *parent, *res = win->res;
>> >> +
>> >> + switch (resource_type(res)) {
>> >> + case IORESOURCE_IO:
>> >> + parent = &ioport_resource;
>> >> + err = pci_remap_iospace(res, iobase);
>> >> + if (err) {
>> >> + dev_warn(dev, "error %d: failed to map resource %pR\n",
>> >> + err, res);
>> >> + continue;
>> >> + }
>> >> + break;
>> >> + case IORESOURCE_MEM:
>> >> + parent = &iomem_resource;
>> >> + res_valid |= !(res->flags & IORESOURCE_PREFETCH);
>> >> +
>> >> + writel(res->start >> 28, PCI_IMAP(mem));
>> >> + writel(PHYS_OFFSET >> 28, PCI_SMAP(mem));
>> >> + mem++;
>> >> +
>> >> + break;
>> >> + case IORESOURCE_BUS:
>> >> + default:
>> >> + continue;
>> >> + }
>> >> +
>> >> + err = devm_request_resource(dev, parent, res);
>> >> + if (err)
>> >> + goto out_release_res;
>> >> + }
>> >
>> > I wonder if we should also request the physical resource for the I/O space
>> > window to have it show up in /proc/iomem. We are rather inconsistent in this
>> > regard between drivers.
>>
>> It's a little complicated now because we don't have that as a struct
>> resource any more. We could reconstruct it from iobase and the i/o
>> resource size.
>
>
>
>> >> + pci_add_flags(PCI_ENABLE_PROC_DOMAINS);
>> >> + pci_add_flags(PCI_REASSIGN_ALL_BUS | PCI_REASSIGN_ALL_RSRC);
>> >> +
>> >> + bus = pci_scan_root_bus(&pdev->dev, 0, &pci_versatile_ops, &sys, &pci_res);
>> >> + if (!bus)
>> >> + return -ENOMEM;
>> >> +
>> >> + pci_fixup_irqs(pci_common_swizzle, of_irq_parse_and_map_pci);
>> >> + pci_assign_unassigned_bus_resources(bus);
>> >> +
>> >> + return 0;
>> >
>> > One general question, mainly for Bjorn: pci_scan_root_bus adds all the devices
>> > at the Linux driver level by calling pci_bus_add_devices(), but then we call
>> > pci_fixup_irqs and pci_assign_unassigned_bus_resources after that, which will
>> > change the devices again. Is this how it's meant to work? How do we ensure
>> > that we have the correct irq number and resources by the time we enter the
>> > probe() function of the PCI device driver that gets bound to a device here?
>>
>> I'm a bit puzzled myself. I think that the devices are not probed
>> until after pci_assign_unassigned_bus_resources. It certainly doesn't
>> work without that call. Really, I think of_irq_parse_and_map_pci
>> should be the default if no one else has set the device's irq (and the
>> host has a device node of course).
>>
>> It also seems to be a bit of random set of pci functions that are
>> called here. It would be nice to simplify this chunk of code.
>
> Yes, and we recently had some attempts at creating a better interface posted
> on the mailing list, not sure what the latest status on it is. I think we
> want to end up with a two-stage interface along the lines of:
>
> /* allocate a pci_host_bridge, scan DT, set default operations, map
> I/O space if necessary, request all resources ... */
> phb = pci_host_bridge_create(parent, ..., sizeof(struct my_pci_private));
Humm, I wondered what happened to pci_host_bridge_create and thought
we had abandoned it. It wasn't too clear reading thru the threads. The
host drivers generally still have to walk thru the resources anyway to
setup inbound and outbound windows, so we don't gain too much moving
that out. And the error clean-up gets complicated too.
Rob
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 4/9] pci: add DT based ARM Versatile PCI host driver
@ 2015-01-02 23:13 ` Rob Herring
0 siblings, 0 replies; 86+ messages in thread
From: Rob Herring @ 2015-01-02 23:13 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Jan 2, 2015 at 2:52 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday 02 January 2015 12:14:43 Rob Herring wrote:
>> On Tue, Dec 30, 2014 at 3:58 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Tuesday 30 December 2014 13:28:33 Rob Herring wrote:
>> >> From: Rob Herring <robh@kernel.org>
>> >>
>> >> This converts the Versatile PCI host code to a platform driver using
>> >> the commom DT parsing and setup. The driver uses only an empty ARM
>> >> pci_sys_data struct and does not use pci_common_init_dev init function.
>> >> The old host code will be removed in a subsequent commit when Versatile
>> >> is completely converted to DT.
>> >>
>> >> I've tested this on QEMU with the sym53c8xx driver in both i/o and
>> >> memory mapped modes.
>> >
>> > Ah, this is quite clever, I think you tried to explain to me what you
>> > did with the pci_sys_data before, but I didn't get it then.
>> >
>> >> +
>> >> +static void __iomem *__pci_addr(struct pci_bus *bus,
>> >> + unsigned int devfn, int offset)
>> >> +{
>> >> + unsigned int busnr = bus->number;
>> >> +
>> >> + /*
>> >> + * Trap out illegal values
>> >> + */
>> >> + BUG_ON(offset > 255);
>> >> + BUG_ON(busnr > 255);
>> >> + BUG_ON(devfn > 255);
>> >
>> > Isn't an offset>255 something that can be triggered by a non-broken
>> > driver or even user space?
>>
>> I don't know. I just copied what the old driver did. Are these checks
>> even host controller specific?
>
> A busnr or devfn larger than 255 would be a serious bug on any host
> controller, those just don't exist. A BUG_ON check here is not a problem,
> but if we want to have it, I'd prefer to put it into the core code.
Agreed.
> offset values between 256 and 4095 can be valid on some devices, but
> apparently this host controller does not support them.
I'm going to drop the checks. The only checks I see in other drivers
are for the bus number to match the root bus which I'm not convinced
are needed either.
>> > Maybe just return PCIBIOS_BAD_REGISTER_NUMBER in this case?
>>
>> Perhaps. We could probably simplify the config space read/write
>> functions and just provide the PCI core a bus/devfn/offset to config
>> address translation function. That would not work in all cases, but
>> propably most that have memory mapped config space.
>
> Actually, thinking about this some more, the implementation seems to
> be "CAM" compliant, and we could share the confic space accessors with
> the ones from drivers/pci/host/pci-host-generic.c.
Almost. It uses readl for all size accesses. Yet writes support
different access sizes. I would guess that the h/w can support byte
and word reads if writes are supported, but I can't really verify.
Dword-only sized reads or reads and writes seem to be the main
variations for config space accesses. There's a few hosts with more
complex config space access setup, but quite a few only vary in
address decode.
>> >> +static int versatile_pci_parse_request_of_pci_ranges(struct device *dev,
>> >> + struct list_head *res)
>> >> +{
>> >> + int err, mem = 1, res_valid = 0;
>> >> + struct device_node *np = dev->of_node;
>> >> + resource_size_t iobase;
>> >> + struct pci_host_bridge_window *win;
>> >> +
>> >> + err = of_pci_get_host_bridge_resources(np, 0, 0xff, res, &iobase);
>> >> + if (err)
>> >> + return err;
>> >> +
>> >> + list_for_each_entry(win, res, list) {
>> >> + struct resource *parent, *res = win->res;
>> >> +
>> >> + switch (resource_type(res)) {
>> >> + case IORESOURCE_IO:
>> >> + parent = &ioport_resource;
>> >> + err = pci_remap_iospace(res, iobase);
>> >> + if (err) {
>> >> + dev_warn(dev, "error %d: failed to map resource %pR\n",
>> >> + err, res);
>> >> + continue;
>> >> + }
>> >> + break;
>> >> + case IORESOURCE_MEM:
>> >> + parent = &iomem_resource;
>> >> + res_valid |= !(res->flags & IORESOURCE_PREFETCH);
>> >> +
>> >> + writel(res->start >> 28, PCI_IMAP(mem));
>> >> + writel(PHYS_OFFSET >> 28, PCI_SMAP(mem));
>> >> + mem++;
>> >> +
>> >> + break;
>> >> + case IORESOURCE_BUS:
>> >> + default:
>> >> + continue;
>> >> + }
>> >> +
>> >> + err = devm_request_resource(dev, parent, res);
>> >> + if (err)
>> >> + goto out_release_res;
>> >> + }
>> >
>> > I wonder if we should also request the physical resource for the I/O space
>> > window to have it show up in /proc/iomem. We are rather inconsistent in this
>> > regard between drivers.
>>
>> It's a little complicated now because we don't have that as a struct
>> resource any more. We could reconstruct it from iobase and the i/o
>> resource size.
>
>
>
>> >> + pci_add_flags(PCI_ENABLE_PROC_DOMAINS);
>> >> + pci_add_flags(PCI_REASSIGN_ALL_BUS | PCI_REASSIGN_ALL_RSRC);
>> >> +
>> >> + bus = pci_scan_root_bus(&pdev->dev, 0, &pci_versatile_ops, &sys, &pci_res);
>> >> + if (!bus)
>> >> + return -ENOMEM;
>> >> +
>> >> + pci_fixup_irqs(pci_common_swizzle, of_irq_parse_and_map_pci);
>> >> + pci_assign_unassigned_bus_resources(bus);
>> >> +
>> >> + return 0;
>> >
>> > One general question, mainly for Bjorn: pci_scan_root_bus adds all the devices
>> > at the Linux driver level by calling pci_bus_add_devices(), but then we call
>> > pci_fixup_irqs and pci_assign_unassigned_bus_resources after that, which will
>> > change the devices again. Is this how it's meant to work? How do we ensure
>> > that we have the correct irq number and resources by the time we enter the
>> > probe() function of the PCI device driver that gets bound to a device here?
>>
>> I'm a bit puzzled myself. I think that the devices are not probed
>> until after pci_assign_unassigned_bus_resources. It certainly doesn't
>> work without that call. Really, I think of_irq_parse_and_map_pci
>> should be the default if no one else has set the device's irq (and the
>> host has a device node of course).
>>
>> It also seems to be a bit of random set of pci functions that are
>> called here. It would be nice to simplify this chunk of code.
>
> Yes, and we recently had some attempts at creating a better interface posted
> on the mailing list, not sure what the latest status on it is. I think we
> want to end up with a two-stage interface along the lines of:
>
> /* allocate a pci_host_bridge, scan DT, set default operations, map
> I/O space if necessary, request all resources ... */
> phb = pci_host_bridge_create(parent, ..., sizeof(struct my_pci_private));
Humm, I wondered what happened to pci_host_bridge_create and thought
we had abandoned it. It wasn't too clear reading thru the threads. The
host drivers generally still have to walk thru the resources anyway to
setup inbound and outbound windows, so we don't gain too much moving
that out. And the error clean-up gets complicated too.
Rob
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 4/9] pci: add DT based ARM Versatile PCI host driver
2015-01-02 23:13 ` Rob Herring
@ 2015-01-05 9:35 ` Arnd Bergmann
-1 siblings, 0 replies; 86+ messages in thread
From: Arnd Bergmann @ 2015-01-05 9:35 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Rob Herring, devicetree, Russell King, Peter Maydell, linux-pci,
Linus Walleij, arm, Bjorn Helgaas
On Friday 02 January 2015 17:13:19 Rob Herring wrote:
> On Fri, Jan 2, 2015 at 2:52 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Friday 02 January 2015 12:14:43 Rob Herring wrote:
> >> On Tue, Dec 30, 2014 at 3:58 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> >> > On Tuesday 30 December 2014 13:28:33 Rob Herring wrote:
> >> > Maybe just return PCIBIOS_BAD_REGISTER_NUMBER in this case?
> >>
> >> Perhaps. We could probably simplify the config space read/write
> >> functions and just provide the PCI core a bus/devfn/offset to config
> >> address translation function. That would not work in all cases, but
> >> propably most that have memory mapped config space.
> >
> > Actually, thinking about this some more, the implementation seems to
> > be "CAM" compliant, and we could share the confic space accessors with
> > the ones from drivers/pci/host/pci-host-generic.c.
>
> Almost. It uses readl for all size accesses. Yet writes support
> different access sizes. I would guess that the h/w can support byte
> and word reads if writes are supported, but I can't really verify.
> Dword-only sized reads or reads and writes seem to be the main
> variations for config space accesses. There's a few hosts with more
> complex config space access setup, but quite a few only vary in
> address decode.
It was probably just done the current way because it seemed simpler
at the time, but I agree that we can just keep it like this if there
is any chance it's required as a workaround for a hardware glitch.
With your other patch you just posted, it really becomes trivial
to do.
> >> I'm a bit puzzled myself. I think that the devices are not probed
> >> until after pci_assign_unassigned_bus_resources. It certainly doesn't
> >> work without that call. Really, I think of_irq_parse_and_map_pci
> >> should be the default if no one else has set the device's irq (and the
> >> host has a device node of course).
> >>
> >> It also seems to be a bit of random set of pci functions that are
> >> called here. It would be nice to simplify this chunk of code.
> >
> > Yes, and we recently had some attempts at creating a better interface posted
> > on the mailing list, not sure what the latest status on it is. I think we
> > want to end up with a two-stage interface along the lines of:
> >
> > /* allocate a pci_host_bridge, scan DT, set default operations, map
> > I/O space if necessary, request all resources ... */
> > phb = pci_host_bridge_create(parent, ..., sizeof(struct my_pci_private));
>
> Humm, I wondered what happened to pci_host_bridge_create and thought
> we had abandoned it. It wasn't too clear reading thru the threads. The
> host drivers generally still have to walk thru the resources anyway to
> setup inbound and outbound windows, so we don't gain too much moving
> that out.
I think the discussion has not ended yet, I'm still in favor of
doing it like that. The current of_pci_get_host_bridge_resources()
function is indeed lacking a bit because it just returns the resources
that are needed for setting up the PCI side, but it doesn't
provide a list of the host side windows that may need to get programmed
into hardware registers on machines without a firmware that has set them
up in advance (i.e. most ARM32 and MIPS32 machines).
We could add another exported function to return those, or we could
find a way to pass those back through the pci_host_bridge pointer
from the common function.
Setting up the PCI side by itself does seem useful to me though, mainly
to prevent host controller drivers from getting it wrong.
> And the error clean-up gets complicated too.
In what way? I would hope that we could come up with a way to make
pci_host_bridge_create() able to roll-back, so it does nothing in
case of an error, and allocate all resources using devm_* so it
all gets undone if probe() fails for another reason.
Arnd
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 4/9] pci: add DT based ARM Versatile PCI host driver
@ 2015-01-05 9:35 ` Arnd Bergmann
0 siblings, 0 replies; 86+ messages in thread
From: Arnd Bergmann @ 2015-01-05 9:35 UTC (permalink / raw)
To: linux-arm-kernel
On Friday 02 January 2015 17:13:19 Rob Herring wrote:
> On Fri, Jan 2, 2015 at 2:52 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Friday 02 January 2015 12:14:43 Rob Herring wrote:
> >> On Tue, Dec 30, 2014 at 3:58 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> >> > On Tuesday 30 December 2014 13:28:33 Rob Herring wrote:
> >> > Maybe just return PCIBIOS_BAD_REGISTER_NUMBER in this case?
> >>
> >> Perhaps. We could probably simplify the config space read/write
> >> functions and just provide the PCI core a bus/devfn/offset to config
> >> address translation function. That would not work in all cases, but
> >> propably most that have memory mapped config space.
> >
> > Actually, thinking about this some more, the implementation seems to
> > be "CAM" compliant, and we could share the confic space accessors with
> > the ones from drivers/pci/host/pci-host-generic.c.
>
> Almost. It uses readl for all size accesses. Yet writes support
> different access sizes. I would guess that the h/w can support byte
> and word reads if writes are supported, but I can't really verify.
> Dword-only sized reads or reads and writes seem to be the main
> variations for config space accesses. There's a few hosts with more
> complex config space access setup, but quite a few only vary in
> address decode.
It was probably just done the current way because it seemed simpler
at the time, but I agree that we can just keep it like this if there
is any chance it's required as a workaround for a hardware glitch.
With your other patch you just posted, it really becomes trivial
to do.
> >> I'm a bit puzzled myself. I think that the devices are not probed
> >> until after pci_assign_unassigned_bus_resources. It certainly doesn't
> >> work without that call. Really, I think of_irq_parse_and_map_pci
> >> should be the default if no one else has set the device's irq (and the
> >> host has a device node of course).
> >>
> >> It also seems to be a bit of random set of pci functions that are
> >> called here. It would be nice to simplify this chunk of code.
> >
> > Yes, and we recently had some attempts at creating a better interface posted
> > on the mailing list, not sure what the latest status on it is. I think we
> > want to end up with a two-stage interface along the lines of:
> >
> > /* allocate a pci_host_bridge, scan DT, set default operations, map
> > I/O space if necessary, request all resources ... */
> > phb = pci_host_bridge_create(parent, ..., sizeof(struct my_pci_private));
>
> Humm, I wondered what happened to pci_host_bridge_create and thought
> we had abandoned it. It wasn't too clear reading thru the threads. The
> host drivers generally still have to walk thru the resources anyway to
> setup inbound and outbound windows, so we don't gain too much moving
> that out.
I think the discussion has not ended yet, I'm still in favor of
doing it like that. The current of_pci_get_host_bridge_resources()
function is indeed lacking a bit because it just returns the resources
that are needed for setting up the PCI side, but it doesn't
provide a list of the host side windows that may need to get programmed
into hardware registers on machines without a firmware that has set them
up in advance (i.e. most ARM32 and MIPS32 machines).
We could add another exported function to return those, or we could
find a way to pass those back through the pci_host_bridge pointer
from the common function.
Setting up the PCI side by itself does seem useful to me though, mainly
to prevent host controller drivers from getting it wrong.
> And the error clean-up gets complicated too.
In what way? I would hope that we could come up with a way to make
pci_host_bridge_create() able to roll-back, so it does nothing in
case of an error, and allocate all resources using devm_* so it
all gets undone if probe() fails for another reason.
Arnd
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 0/9] ARM Versatile multi-platform support
2014-12-31 9:25 ` Peter Maydell
@ 2015-01-05 9:50 ` Marc Zyngier
-1 siblings, 0 replies; 86+ messages in thread
From: Marc Zyngier @ 2015-01-05 9:50 UTC (permalink / raw)
To: Peter Maydell, Rob Herring
Cc: arm-mail-list, devicetree-u79uwXL29TY76Z2rM5mHXA, Russell King,
Linus Walleij, arm-DgEjT+Ai2ygdnm+yROfE0A, Bjorn Helgaas,
Rob Herring, Will Deacon
On 31/12/14 09:25, Peter Maydell wrote:
> On 30 December 2014 at 19:28, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> This has been tested on QEMU. A previous version was tested on
>> Versatile/AB by Linus Walleij. Linus reported a problem with the
>> display panel detection. Investigation on h/w is needed still as I have
>> not been able to identify the issue by inspection and the display
>> detection seems to work correctly on QEMU.
>>
>> Linus had also mentioned to me that QEMU users may have some issue with
>> removing non-DT code as the work flow has to change somewhat.
>
> As long as you call out the requirement for a DT now in whatever
> your equivalent of release notes is that should be fine. (Does
> the kernel provide a useful message to serial in the absence of a
> DT or does it now not have enough platform knowledge to do that?)
>
>> Copying
>> Peter Maydell here for comment (and there's rumors he may have actual PB
>> h/w with PCI as well).
>
> Will Deacon and Marc Zyngier are currently in possession of that h/w.
> I'm sure they'd be delighted to pull it out of the cupboard and
> give it a spin :-)
I'll try to find some time (or a victim to do the testing... ;-). To
those interested, I have a few extra PCI backplanes (just the PCB, not
the huge noisy carrier rack) I could be convinced to part with...
Thanks,
M.
--
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 0/9] ARM Versatile multi-platform support
@ 2015-01-05 9:50 ` Marc Zyngier
0 siblings, 0 replies; 86+ messages in thread
From: Marc Zyngier @ 2015-01-05 9:50 UTC (permalink / raw)
To: linux-arm-kernel
On 31/12/14 09:25, Peter Maydell wrote:
> On 30 December 2014 at 19:28, Rob Herring <robherring2@gmail.com> wrote:
>> This has been tested on QEMU. A previous version was tested on
>> Versatile/AB by Linus Walleij. Linus reported a problem with the
>> display panel detection. Investigation on h/w is needed still as I have
>> not been able to identify the issue by inspection and the display
>> detection seems to work correctly on QEMU.
>>
>> Linus had also mentioned to me that QEMU users may have some issue with
>> removing non-DT code as the work flow has to change somewhat.
>
> As long as you call out the requirement for a DT now in whatever
> your equivalent of release notes is that should be fine. (Does
> the kernel provide a useful message to serial in the absence of a
> DT or does it now not have enough platform knowledge to do that?)
>
>> Copying
>> Peter Maydell here for comment (and there's rumors he may have actual PB
>> h/w with PCI as well).
>
> Will Deacon and Marc Zyngier are currently in possession of that h/w.
> I'm sure they'd be delighted to pull it out of the cupboard and
> give it a spin :-)
I'll try to find some time (or a victim to do the testing... ;-). To
those interested, I have a few extra PCI backplanes (just the PCB, not
the huge noisy carrier rack) I could be convinced to part with...
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 0/9] ARM Versatile multi-platform support
2015-01-05 9:50 ` Marc Zyngier
@ 2015-01-05 10:08 ` Peter Maydell
-1 siblings, 0 replies; 86+ messages in thread
From: Peter Maydell @ 2015-01-05 10:08 UTC (permalink / raw)
To: Marc Zyngier
Cc: Rob Herring, arm-mail-list, devicetree-u79uwXL29TY76Z2rM5mHXA,
Russell King, Linus Walleij, arm-DgEjT+Ai2ygdnm+yROfE0A,
Bjorn Helgaas, Rob Herring, Will Deacon
On 5 January 2015 at 09:50, Marc Zyngier <marc.zyngier-5wv7dgnIgG8@public.gmane.org> wrote:
> On 31/12/14 09:25, Peter Maydell wrote:
>> Will Deacon and Marc Zyngier are currently in possession of that h/w.
>> I'm sure they'd be delighted to pull it out of the cupboard and
>> give it a spin :-)
>
> I'll try to find some time (or a victim to do the testing... ;-)
To save you some time in trying to debug things which didn't work
before this patchset, the status last time I tested on h/w was:
* PCI MMIO accesses work
* PCI IO accesses work
* PCI bus-master (DMA) doesn't work
with the failure symptom for DMA being that the card wrote to
the correct area of memory but only every other word, so you
got strings like "HellXXXXrld" with the Xs being garbage.
This feels to me like a h/w issue rather than a driver problem.
-- PMM
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 0/9] ARM Versatile multi-platform support
@ 2015-01-05 10:08 ` Peter Maydell
0 siblings, 0 replies; 86+ messages in thread
From: Peter Maydell @ 2015-01-05 10:08 UTC (permalink / raw)
To: linux-arm-kernel
On 5 January 2015 at 09:50, Marc Zyngier <marc.zyngier@arm.com> wrote:
> On 31/12/14 09:25, Peter Maydell wrote:
>> Will Deacon and Marc Zyngier are currently in possession of that h/w.
>> I'm sure they'd be delighted to pull it out of the cupboard and
>> give it a spin :-)
>
> I'll try to find some time (or a victim to do the testing... ;-)
To save you some time in trying to debug things which didn't work
before this patchset, the status last time I tested on h/w was:
* PCI MMIO accesses work
* PCI IO accesses work
* PCI bus-master (DMA) doesn't work
with the failure symptom for DMA being that the card wrote to
the correct area of memory but only every other word, so you
got strings like "HellXXXXrld" with the Xs being garbage.
This feels to me like a h/w issue rather than a driver problem.
-- PMM
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 0/9] ARM Versatile multi-platform support
2015-01-05 10:08 ` Peter Maydell
@ 2015-01-05 11:19 ` Marc Zyngier
-1 siblings, 0 replies; 86+ messages in thread
From: Marc Zyngier @ 2015-01-05 11:19 UTC (permalink / raw)
To: Peter Maydell
Cc: Rob Herring, arm-mail-list, devicetree@vger.kernel.org,
Russell King, Linus Walleij, arm@kernel.org, Bjorn Helgaas,
Rob Herring, Will Deacon
On Mon, Jan 05 2015 at 10:08:18 am GMT, Peter Maydell <peter.maydell-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> On 5 January 2015 at 09:50, Marc Zyngier <marc.zyngier-5wv7dgnIgG8@public.gmane.org> wrote:
>> On 31/12/14 09:25, Peter Maydell wrote:
>>> Will Deacon and Marc Zyngier are currently in possession of that h/w.
>>> I'm sure they'd be delighted to pull it out of the cupboard and
>>> give it a spin :-)
>>
>> I'll try to find some time (or a victim to do the testing... ;-)
>
> To save you some time in trying to debug things which didn't work
> before this patchset, the status last time I tested on h/w was:
> * PCI MMIO accesses work
> * PCI IO accesses work
> * PCI bus-master (DMA) doesn't work
>
> with the failure symptom for DMA being that the card wrote to
> the correct area of memory but only every other word, so you
> got strings like "HellXXXXrld" with the Xs being garbage.
> This feels to me like a h/w issue rather than a driver problem.
Looks like some 64bit address decoding getting in the way. Or
something.... Do you remember the exact platform you tried this on (I
have PB926, PB1176, and a bunch of RealViews with an odd mix of
tiles...)?
M.
--
Jazz is not dead. It just smells funny.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 0/9] ARM Versatile multi-platform support
@ 2015-01-05 11:19 ` Marc Zyngier
0 siblings, 0 replies; 86+ messages in thread
From: Marc Zyngier @ 2015-01-05 11:19 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Jan 05 2015 at 10:08:18 am GMT, Peter Maydell <peter.maydell@linaro.org> wrote:
> On 5 January 2015 at 09:50, Marc Zyngier <marc.zyngier@arm.com> wrote:
>> On 31/12/14 09:25, Peter Maydell wrote:
>>> Will Deacon and Marc Zyngier are currently in possession of that h/w.
>>> I'm sure they'd be delighted to pull it out of the cupboard and
>>> give it a spin :-)
>>
>> I'll try to find some time (or a victim to do the testing... ;-)
>
> To save you some time in trying to debug things which didn't work
> before this patchset, the status last time I tested on h/w was:
> * PCI MMIO accesses work
> * PCI IO accesses work
> * PCI bus-master (DMA) doesn't work
>
> with the failure symptom for DMA being that the card wrote to
> the correct area of memory but only every other word, so you
> got strings like "HellXXXXrld" with the Xs being garbage.
> This feels to me like a h/w issue rather than a driver problem.
Looks like some 64bit address decoding getting in the way. Or
something.... Do you remember the exact platform you tried this on (I
have PB926, PB1176, and a bunch of RealViews with an odd mix of
tiles...)?
M.
--
Jazz is not dead. It just smells funny.
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 0/9] ARM Versatile multi-platform support
2015-01-05 11:19 ` Marc Zyngier
@ 2015-01-05 17:41 ` Peter Maydell
-1 siblings, 0 replies; 86+ messages in thread
From: Peter Maydell @ 2015-01-05 17:41 UTC (permalink / raw)
To: Marc Zyngier
Cc: Rob Herring, arm-mail-list, devicetree-u79uwXL29TY76Z2rM5mHXA,
Russell King, Linus Walleij, arm-DgEjT+Ai2ygdnm+yROfE0A,
Bjorn Helgaas, Rob Herring, Will Deacon
On 5 January 2015 at 11:19, Marc Zyngier <marc.zyngier-5wv7dgnIgG8@public.gmane.org> wrote:
> On Mon, Jan 05 2015 at 10:08:18 am GMT, Peter Maydell <peter.maydell-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>> On 5 January 2015 at 09:50, Marc Zyngier <marc.zyngier-5wv7dgnIgG8@public.gmane.org> wrote:
>>> On 31/12/14 09:25, Peter Maydell wrote:
>>>> Will Deacon and Marc Zyngier are currently in possession of that h/w.
>>>> I'm sure they'd be delighted to pull it out of the cupboard and
>>>> give it a spin :-)
>>>
>>> I'll try to find some time (or a victim to do the testing... ;-)
>>
>> To save you some time in trying to debug things which didn't work
>> before this patchset, the status last time I tested on h/w was:
>> * PCI MMIO accesses work
>> * PCI IO accesses work
>> * PCI bus-master (DMA) doesn't work
>>
>> with the failure symptom for DMA being that the card wrote to
>> the correct area of memory but only every other word, so you
>> got strings like "HellXXXXrld" with the Xs being garbage.
>> This feels to me like a h/w issue rather than a driver problem.
>
> Looks like some 64bit address decoding getting in the way. Or
> something.... Do you remember the exact platform you tried this on (I
> have PB926, PB1176, and a bunch of RealViews with an odd mix of
> tiles...)?
According to my coverletter email from the last time I did anything
with versatile PCI:
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-August/193990.html
it was a PB926 (and an rtl8139 network card). I'm pretty sure I
flashed the board with the latest IO FPGA image too.
thanks
-- PMM
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 0/9] ARM Versatile multi-platform support
@ 2015-01-05 17:41 ` Peter Maydell
0 siblings, 0 replies; 86+ messages in thread
From: Peter Maydell @ 2015-01-05 17:41 UTC (permalink / raw)
To: linux-arm-kernel
On 5 January 2015 at 11:19, Marc Zyngier <marc.zyngier@arm.com> wrote:
> On Mon, Jan 05 2015 at 10:08:18 am GMT, Peter Maydell <peter.maydell@linaro.org> wrote:
>> On 5 January 2015 at 09:50, Marc Zyngier <marc.zyngier@arm.com> wrote:
>>> On 31/12/14 09:25, Peter Maydell wrote:
>>>> Will Deacon and Marc Zyngier are currently in possession of that h/w.
>>>> I'm sure they'd be delighted to pull it out of the cupboard and
>>>> give it a spin :-)
>>>
>>> I'll try to find some time (or a victim to do the testing... ;-)
>>
>> To save you some time in trying to debug things which didn't work
>> before this patchset, the status last time I tested on h/w was:
>> * PCI MMIO accesses work
>> * PCI IO accesses work
>> * PCI bus-master (DMA) doesn't work
>>
>> with the failure symptom for DMA being that the card wrote to
>> the correct area of memory but only every other word, so you
>> got strings like "HellXXXXrld" with the Xs being garbage.
>> This feels to me like a h/w issue rather than a driver problem.
>
> Looks like some 64bit address decoding getting in the way. Or
> something.... Do you remember the exact platform you tried this on (I
> have PB926, PB1176, and a bunch of RealViews with an odd mix of
> tiles...)?
According to my coverletter email from the last time I did anything
with versatile PCI:
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-August/193990.html
it was a PB926 (and an rtl8139 network card). I'm pretty sure I
flashed the board with the latest IO FPGA image too.
thanks
-- PMM
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 3/9] ARM: versatile: add DT based PCI detection
2014-12-30 19:28 ` Rob Herring
@ 2015-01-08 19:37 ` Linus Walleij
-1 siblings, 0 replies; 86+ messages in thread
From: Linus Walleij @ 2015-01-08 19:37 UTC (permalink / raw)
To: Rob Herring
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Russell King, Peter Maydell,
arm-DgEjT+Ai2ygdnm+yROfE0A, Bjorn Helgaas, Rob Herring
On Tue, Dec 30, 2014 at 8:28 PM, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> From: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>
> Disable the Versatile PCI DT node when no PCI backplane is detected. This
> will prevent the Versatile PCI driver from probing when PCI is not
> populated.
>
> Signed-off-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
> Cc: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
(...)
> + /* Check if PCI backplane is detected */
> + val = __raw_readl(base + VERSATILE_SYS_PCICTL_OFFSET);
I think this kind of random syscon register access should be handled
using the mfd/syscon.c hub and looked up in some way to be used
by the driver.
I'm thinking along the pattern of adding code in drivers/*
by the pattern of e.g.
drivers/video/fbdev/amba-clcd-versatile.c
i.e. an add-on that gets compiled-in only for those platform
but still married to the main driver.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 3/9] ARM: versatile: add DT based PCI detection
@ 2015-01-08 19:37 ` Linus Walleij
0 siblings, 0 replies; 86+ messages in thread
From: Linus Walleij @ 2015-01-08 19:37 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Dec 30, 2014 at 8:28 PM, Rob Herring <robherring2@gmail.com> wrote:
> From: Rob Herring <robh@kernel.org>
>
> Disable the Versatile PCI DT node when no PCI backplane is detected. This
> will prevent the Versatile PCI driver from probing when PCI is not
> populated.
>
> Signed-off-by: Rob Herring <robh@kernel.org>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Linus Walleij <linus.walleij@linaro.org>
(...)
> + /* Check if PCI backplane is detected */
> + val = __raw_readl(base + VERSATILE_SYS_PCICTL_OFFSET);
I think this kind of random syscon register access should be handled
using the mfd/syscon.c hub and looked up in some way to be used
by the driver.
I'm thinking along the pattern of adding code in drivers/*
by the pattern of e.g.
drivers/video/fbdev/amba-clcd-versatile.c
i.e. an add-on that gets compiled-in only for those platform
but still married to the main driver.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 5/9] dts: versatile: add sysregs nodes
2014-12-30 19:28 ` Rob Herring
@ 2015-01-08 19:44 ` Linus Walleij
-1 siblings, 0 replies; 86+ messages in thread
From: Linus Walleij @ 2015-01-08 19:44 UTC (permalink / raw)
To: Rob Herring
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Russell King, Peter Maydell,
arm-DgEjT+Ai2ygdnm+yROfE0A, Bjorn Helgaas, Rob Herring
On Tue, Dec 30, 2014 at 8:28 PM, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> From: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>
> The Versatile boards have the same sysregs as other ARM Ltd boards. Add
> the nodes in preparation to enable support for 24MHz counter as
> sched_clock and MMC card detect and write protect support.
>
> Signed-off-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
> Cc: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> arch/arm/boot/dts/versatile-ab.dts | 23 +++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
>
> diff --git a/arch/arm/boot/dts/versatile-ab.dts b/arch/arm/boot/dts/versatile-ab.dts
> index 27d0d9c..62f04b0 100644
> --- a/arch/arm/boot/dts/versatile-ab.dts
> +++ b/arch/arm/boot/dts/versatile-ab.dts
> @@ -252,6 +252,29 @@
> #size-cells = <1>;
> ranges = <0 0x10000000 0x10000>;
>
> + sysreg@0 {
> + compatible = "arm,vexpress-sysreg";
vexpress? No...
compatible = "syscon";
> + reg = <0x00000 0x1000>;
> +
> + v2m_led_gpios: sys_led@08 {
> + compatible = "arm,vexpress-sysreg,sys_led";
> + gpio-controller;
> + #gpio-cells = <2>;
> + };
These are not GPIOs. These are LED registers really.
see how to use LEDs from drivers/leds/leds-syscon.c and bindings.
example in:
arch/arm/boot/dts/integrator.dtsi
Very straight-forward I think.
> +
> + v2m_mmc_gpios: sys_mci@48 {
> + compatible = "arm,vexpress-sysreg,sys_mci";
> + gpio-controller;
> + #gpio-cells = <2>;
> + };
> +
> + v2m_flash_gpios: sys_flash@4c {
> + compatible = "arm,vexpress-sysreg,sys_flash";
> + gpio-controller;
> + #gpio-cells = <2>;
> + };
I don't have drivers for these "gpio controllers" and I don't think they are
GPIOs either, since they are not general purpose at all.
For the latter I have some code boiling for the Integrators:
https://git.kernel.org/cgit/linux/kernel/git/linusw/linux-integrator.git/commit/?h=multiplatform&id=9c28e114ec957fadf1dade382d8e8b8aa43c8426
https://git.kernel.org/cgit/linux/kernel/git/linusw/linux-integrator.git/commit/?h=multiplatform&id=a3d4512abb85de290cdca0586bcff9147833917f
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 5/9] dts: versatile: add sysregs nodes
@ 2015-01-08 19:44 ` Linus Walleij
0 siblings, 0 replies; 86+ messages in thread
From: Linus Walleij @ 2015-01-08 19:44 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Dec 30, 2014 at 8:28 PM, Rob Herring <robherring2@gmail.com> wrote:
> From: Rob Herring <robh@kernel.org>
>
> The Versatile boards have the same sysregs as other ARM Ltd boards. Add
> the nodes in preparation to enable support for 24MHz counter as
> sched_clock and MMC card detect and write protect support.
>
> Signed-off-by: Rob Herring <robh@kernel.org>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> ---
> arch/arm/boot/dts/versatile-ab.dts | 23 +++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
>
> diff --git a/arch/arm/boot/dts/versatile-ab.dts b/arch/arm/boot/dts/versatile-ab.dts
> index 27d0d9c..62f04b0 100644
> --- a/arch/arm/boot/dts/versatile-ab.dts
> +++ b/arch/arm/boot/dts/versatile-ab.dts
> @@ -252,6 +252,29 @@
> #size-cells = <1>;
> ranges = <0 0x10000000 0x10000>;
>
> + sysreg at 0 {
> + compatible = "arm,vexpress-sysreg";
vexpress? No...
compatible = "syscon";
> + reg = <0x00000 0x1000>;
> +
> + v2m_led_gpios: sys_led at 08 {
> + compatible = "arm,vexpress-sysreg,sys_led";
> + gpio-controller;
> + #gpio-cells = <2>;
> + };
These are not GPIOs. These are LED registers really.
see how to use LEDs from drivers/leds/leds-syscon.c and bindings.
example in:
arch/arm/boot/dts/integrator.dtsi
Very straight-forward I think.
> +
> + v2m_mmc_gpios: sys_mci at 48 {
> + compatible = "arm,vexpress-sysreg,sys_mci";
> + gpio-controller;
> + #gpio-cells = <2>;
> + };
> +
> + v2m_flash_gpios: sys_flash at 4c {
> + compatible = "arm,vexpress-sysreg,sys_flash";
> + gpio-controller;
> + #gpio-cells = <2>;
> + };
I don't have drivers for these "gpio controllers" and I don't think they are
GPIOs either, since they are not general purpose at all.
For the latter I have some code boiling for the Integrators:
https://git.kernel.org/cgit/linux/kernel/git/linusw/linux-integrator.git/commit/?h=multiplatform&id=9c28e114ec957fadf1dade382d8e8b8aa43c8426
https://git.kernel.org/cgit/linux/kernel/git/linusw/linux-integrator.git/commit/?h=multiplatform&id=a3d4512abb85de290cdca0586bcff9147833917f
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 0/9] ARM Versatile multi-platform support
2014-12-30 19:28 ` Rob Herring
@ 2015-01-08 19:47 ` Linus Walleij
-1 siblings, 0 replies; 86+ messages in thread
From: Linus Walleij @ 2015-01-08 19:47 UTC (permalink / raw)
To: Rob Herring
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Russell King, Peter Maydell,
arm-DgEjT+Ai2ygdnm+yROfE0A, Bjorn Helgaas, Rob Herring
On Tue, Dec 30, 2014 at 8:28 PM, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> From: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>
> This series converts ARM Versatile platform to multi-platform. I started
> this some time ago and some pieces were already merged. The primary
> piece remaining is converting the PCI host to DT which I was waiting for
> the common PCI DT parsing to get settled. Now that that is in place as
> well as a few other pieces are in place like multi-platform fixes for
> CLCD, we can fully convert Versatile to DT and multi-platform.
>
> There's still a few things that need DT support which can be done
> later:
> - MMC card detect and write protect. Should be able to use VExpress
> support
> - Reboot support. Should be able to re-use Realview reboot code.
> - flash phys-map support. Binding exists, but specifically Vpp control
> is needed.
> - CLCD support. Not sure where this is at.
I like it overall but would like to see some use of the syscon
pattern to access random registers in syscon, and specifically not
to refer to these registers as some "gpio" because they aren't.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 0/9] ARM Versatile multi-platform support
@ 2015-01-08 19:47 ` Linus Walleij
0 siblings, 0 replies; 86+ messages in thread
From: Linus Walleij @ 2015-01-08 19:47 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Dec 30, 2014 at 8:28 PM, Rob Herring <robherring2@gmail.com> wrote:
> From: Rob Herring <robh@kernel.org>
>
> This series converts ARM Versatile platform to multi-platform. I started
> this some time ago and some pieces were already merged. The primary
> piece remaining is converting the PCI host to DT which I was waiting for
> the common PCI DT parsing to get settled. Now that that is in place as
> well as a few other pieces are in place like multi-platform fixes for
> CLCD, we can fully convert Versatile to DT and multi-platform.
>
> There's still a few things that need DT support which can be done
> later:
> - MMC card detect and write protect. Should be able to use VExpress
> support
> - Reboot support. Should be able to re-use Realview reboot code.
> - flash phys-map support. Binding exists, but specifically Vpp control
> is needed.
> - CLCD support. Not sure where this is at.
I like it overall but would like to see some use of the syscon
pattern to access random registers in syscon, and specifically not
to refer to these registers as some "gpio" because they aren't.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 3/9] ARM: versatile: add DT based PCI detection
2015-01-08 19:37 ` Linus Walleij
@ 2015-01-08 21:34 ` Rob Herring
-1 siblings, 0 replies; 86+ messages in thread
From: Rob Herring @ 2015-01-08 21:34 UTC (permalink / raw)
To: Linus Walleij
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Russell King, Peter Maydell,
arm-DgEjT+Ai2ygdnm+yROfE0A, Bjorn Helgaas
On Thu, Jan 8, 2015 at 1:37 PM, Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> On Tue, Dec 30, 2014 at 8:28 PM, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>> From: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>
>> Disable the Versatile PCI DT node when no PCI backplane is detected. This
>> will prevent the Versatile PCI driver from probing when PCI is not
>> populated.
>>
>> Signed-off-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> Cc: Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
>> Cc: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>
> (...)
>> + /* Check if PCI backplane is detected */
>> + val = __raw_readl(base + VERSATILE_SYS_PCICTL_OFFSET);
>
> I think this kind of random syscon register access should be handled
> using the mfd/syscon.c hub and looked up in some way to be used
> by the driver.
Perhaps, but I've not figured out how much of VExpress syscon can be
used for Versatile. I looked at it briefly, but it appeared to be more
work that I have time for ATM. We still have other accesses to system
registers in Versatile as well. So if we want to merge all this
anytime soon, the options are:
- this patch
- Create a versatilepb-pci.dts which includes versatilepb.dts and enables PCI
- Default to PCI enabled (for QEMU) in the dts and users have to
disable in their dts if they don't have a PCI backplane.
> I'm thinking along the pattern of adding code in drivers/*
> by the pattern of e.g.
> drivers/video/fbdev/amba-clcd-versatile.c
> i.e. an add-on that gets compiled-in only for those platform
> but still married to the main driver.
One difference here is the PCI driver is pretty much only ever going
to be for a single platform.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 3/9] ARM: versatile: add DT based PCI detection
@ 2015-01-08 21:34 ` Rob Herring
0 siblings, 0 replies; 86+ messages in thread
From: Rob Herring @ 2015-01-08 21:34 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Jan 8, 2015 at 1:37 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Tue, Dec 30, 2014 at 8:28 PM, Rob Herring <robherring2@gmail.com> wrote:
>
>> From: Rob Herring <robh@kernel.org>
>>
>> Disable the Versatile PCI DT node when no PCI backplane is detected. This
>> will prevent the Versatile PCI driver from probing when PCI is not
>> populated.
>>
>> Signed-off-by: Rob Herring <robh@kernel.org>
>> Cc: Russell King <linux@arm.linux.org.uk>
>> Cc: Linus Walleij <linus.walleij@linaro.org>
>
> (...)
>> + /* Check if PCI backplane is detected */
>> + val = __raw_readl(base + VERSATILE_SYS_PCICTL_OFFSET);
>
> I think this kind of random syscon register access should be handled
> using the mfd/syscon.c hub and looked up in some way to be used
> by the driver.
Perhaps, but I've not figured out how much of VExpress syscon can be
used for Versatile. I looked at it briefly, but it appeared to be more
work that I have time for ATM. We still have other accesses to system
registers in Versatile as well. So if we want to merge all this
anytime soon, the options are:
- this patch
- Create a versatilepb-pci.dts which includes versatilepb.dts and enables PCI
- Default to PCI enabled (for QEMU) in the dts and users have to
disable in their dts if they don't have a PCI backplane.
> I'm thinking along the pattern of adding code in drivers/*
> by the pattern of e.g.
> drivers/video/fbdev/amba-clcd-versatile.c
> i.e. an add-on that gets compiled-in only for those platform
> but still married to the main driver.
One difference here is the PCI driver is pretty much only ever going
to be for a single platform.
Rob
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 0/9] ARM Versatile multi-platform support
2015-01-08 19:47 ` Linus Walleij
@ 2015-01-08 21:38 ` Rob Herring
-1 siblings, 0 replies; 86+ messages in thread
From: Rob Herring @ 2015-01-08 21:38 UTC (permalink / raw)
To: Linus Walleij
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Russell King, Peter Maydell,
arm-DgEjT+Ai2ygdnm+yROfE0A, Bjorn Helgaas
On Thu, Jan 8, 2015 at 1:47 PM, Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> On Tue, Dec 30, 2014 at 8:28 PM, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>> From: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>
>> This series converts ARM Versatile platform to multi-platform. I started
>> this some time ago and some pieces were already merged. The primary
>> piece remaining is converting the PCI host to DT which I was waiting for
>> the common PCI DT parsing to get settled. Now that that is in place as
>> well as a few other pieces are in place like multi-platform fixes for
>> CLCD, we can fully convert Versatile to DT and multi-platform.
>>
>> There's still a few things that need DT support which can be done
>> later:
>> - MMC card detect and write protect. Should be able to use VExpress
>> support
>> - Reboot support. Should be able to re-use Realview reboot code.
>> - flash phys-map support. Binding exists, but specifically Vpp control
>> is needed.
>> - CLCD support. Not sure where this is at.
>
> I like it overall but would like to see some use of the syscon
> pattern to access random registers in syscon, and specifically not
> to refer to these registers as some "gpio" because they aren't.
I'm not sure I follow. Creating GPIO lines for SD card detect and
write protect is exactly how VExpress syscon was implemented.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 0/9] ARM Versatile multi-platform support
@ 2015-01-08 21:38 ` Rob Herring
0 siblings, 0 replies; 86+ messages in thread
From: Rob Herring @ 2015-01-08 21:38 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Jan 8, 2015 at 1:47 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Tue, Dec 30, 2014 at 8:28 PM, Rob Herring <robherring2@gmail.com> wrote:
>
>> From: Rob Herring <robh@kernel.org>
>>
>> This series converts ARM Versatile platform to multi-platform. I started
>> this some time ago and some pieces were already merged. The primary
>> piece remaining is converting the PCI host to DT which I was waiting for
>> the common PCI DT parsing to get settled. Now that that is in place as
>> well as a few other pieces are in place like multi-platform fixes for
>> CLCD, we can fully convert Versatile to DT and multi-platform.
>>
>> There's still a few things that need DT support which can be done
>> later:
>> - MMC card detect and write protect. Should be able to use VExpress
>> support
>> - Reboot support. Should be able to re-use Realview reboot code.
>> - flash phys-map support. Binding exists, but specifically Vpp control
>> is needed.
>> - CLCD support. Not sure where this is at.
>
> I like it overall but would like to see some use of the syscon
> pattern to access random registers in syscon, and specifically not
> to refer to these registers as some "gpio" because they aren't.
I'm not sure I follow. Creating GPIO lines for SD card detect and
write protect is exactly how VExpress syscon was implemented.
Rob
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 5/9] dts: versatile: add sysregs nodes
2015-01-08 19:44 ` Linus Walleij
@ 2015-01-08 23:53 ` Rob Herring
-1 siblings, 0 replies; 86+ messages in thread
From: Rob Herring @ 2015-01-08 23:53 UTC (permalink / raw)
To: Linus Walleij
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Russell King, Peter Maydell,
arm-DgEjT+Ai2ygdnm+yROfE0A, Bjorn Helgaas, Lorenzo Pieralisi,
Liviu Dudau, Sudeep Holla
Adding VExpress maintainers...
On Thu, Jan 8, 2015 at 1:44 PM, Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> On Tue, Dec 30, 2014 at 8:28 PM, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>> From: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>
>> The Versatile boards have the same sysregs as other ARM Ltd boards. Add
>> the nodes in preparation to enable support for 24MHz counter as
>> sched_clock and MMC card detect and write protect support.
>>
>> Signed-off-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> Cc: Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
>> Cc: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>> ---
>> arch/arm/boot/dts/versatile-ab.dts | 23 +++++++++++++++++++++++
>> 1 file changed, 23 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/versatile-ab.dts b/arch/arm/boot/dts/versatile-ab.dts
>> index 27d0d9c..62f04b0 100644
>> --- a/arch/arm/boot/dts/versatile-ab.dts
>> +++ b/arch/arm/boot/dts/versatile-ab.dts
>> @@ -252,6 +252,29 @@
>> #size-cells = <1>;
>> ranges = <0 0x10000000 0x10000>;
>>
>> + sysreg@0 {
>> + compatible = "arm,vexpress-sysreg";
>
> vexpress? No...
Compatible with yes. Should perhaps be '"arm,versatile-sysreg",
"arm,vexpress-sysreg"' instead. Kind of backwards, as really the
versatile came first, but it would work. Or we just need another match
entry in the kernel.
I copied this whole chunk as is from VExpress and verified these sub
nodes are all the same hence why it is here.
> compatible = "syscon";
maybe? VExpress is missing that then...
>> + reg = <0x00000 0x1000>;
>> +
>> + v2m_led_gpios: sys_led@08 {
>> + compatible = "arm,vexpress-sysreg,sys_led";
>> + gpio-controller;
>> + #gpio-cells = <2>;
>> + };
>
> These are not GPIOs. These are LED registers really.
A register bit that controls an i/o signal sounds like a GPIO to me.
> see how to use LEDs from drivers/leds/leds-syscon.c and bindings.
> example in:
> arch/arm/boot/dts/integrator.dtsi
>
> Very straight-forward I think.
So we have 2 implementations and bindings for roughly the same hardware? Great!
>> + v2m_mmc_gpios: sys_mci@48 {
>> + compatible = "arm,vexpress-sysreg,sys_mci";
>> + gpio-controller;
>> + #gpio-cells = <2>;
>> + };
>> +
>> + v2m_flash_gpios: sys_flash@4c {
>> + compatible = "arm,vexpress-sysreg,sys_flash";
>> + gpio-controller;
>> + #gpio-cells = <2>;
>> + };
>
> I don't have drivers for these "gpio controllers" and I don't think they are
> GPIOs either, since they are not general purpose at all.
They are only general purpose until you connect the i/o lines to
something. But yes, if we went around making every misc internal
control line in SOCs a 1-bit GPIO controller that would be pretty
crazy.
Anyway, most of this is not actually used ATM on Versatile, but it is
present in VExpress. I added it only for sched_clock. We need to
resolve this with VExpress platforms, but it's already in use for MMC
and LEDs.
Rob
> For the latter I have some code boiling for the Integrators:
> https://git.kernel.org/cgit/linux/kernel/git/linusw/linux-integrator.git/commit/?h=multiplatform&id=9c28e114ec957fadf1dade382d8e8b8aa43c8426
> https://git.kernel.org/cgit/linux/kernel/git/linusw/linux-integrator.git/commit/?h=multiplatform&id=a3d4512abb85de290cdca0586bcff9147833917f
>
> Yours,
> Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 5/9] dts: versatile: add sysregs nodes
@ 2015-01-08 23:53 ` Rob Herring
0 siblings, 0 replies; 86+ messages in thread
From: Rob Herring @ 2015-01-08 23:53 UTC (permalink / raw)
To: linux-arm-kernel
Adding VExpress maintainers...
On Thu, Jan 8, 2015 at 1:44 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Tue, Dec 30, 2014 at 8:28 PM, Rob Herring <robherring2@gmail.com> wrote:
>
>> From: Rob Herring <robh@kernel.org>
>>
>> The Versatile boards have the same sysregs as other ARM Ltd boards. Add
>> the nodes in preparation to enable support for 24MHz counter as
>> sched_clock and MMC card detect and write protect support.
>>
>> Signed-off-by: Rob Herring <robh@kernel.org>
>> Cc: Russell King <linux@arm.linux.org.uk>
>> Cc: Linus Walleij <linus.walleij@linaro.org>
>> ---
>> arch/arm/boot/dts/versatile-ab.dts | 23 +++++++++++++++++++++++
>> 1 file changed, 23 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/versatile-ab.dts b/arch/arm/boot/dts/versatile-ab.dts
>> index 27d0d9c..62f04b0 100644
>> --- a/arch/arm/boot/dts/versatile-ab.dts
>> +++ b/arch/arm/boot/dts/versatile-ab.dts
>> @@ -252,6 +252,29 @@
>> #size-cells = <1>;
>> ranges = <0 0x10000000 0x10000>;
>>
>> + sysreg at 0 {
>> + compatible = "arm,vexpress-sysreg";
>
> vexpress? No...
Compatible with yes. Should perhaps be '"arm,versatile-sysreg",
"arm,vexpress-sysreg"' instead. Kind of backwards, as really the
versatile came first, but it would work. Or we just need another match
entry in the kernel.
I copied this whole chunk as is from VExpress and verified these sub
nodes are all the same hence why it is here.
> compatible = "syscon";
maybe? VExpress is missing that then...
>> + reg = <0x00000 0x1000>;
>> +
>> + v2m_led_gpios: sys_led at 08 {
>> + compatible = "arm,vexpress-sysreg,sys_led";
>> + gpio-controller;
>> + #gpio-cells = <2>;
>> + };
>
> These are not GPIOs. These are LED registers really.
A register bit that controls an i/o signal sounds like a GPIO to me.
> see how to use LEDs from drivers/leds/leds-syscon.c and bindings.
> example in:
> arch/arm/boot/dts/integrator.dtsi
>
> Very straight-forward I think.
So we have 2 implementations and bindings for roughly the same hardware? Great!
>> + v2m_mmc_gpios: sys_mci at 48 {
>> + compatible = "arm,vexpress-sysreg,sys_mci";
>> + gpio-controller;
>> + #gpio-cells = <2>;
>> + };
>> +
>> + v2m_flash_gpios: sys_flash at 4c {
>> + compatible = "arm,vexpress-sysreg,sys_flash";
>> + gpio-controller;
>> + #gpio-cells = <2>;
>> + };
>
> I don't have drivers for these "gpio controllers" and I don't think they are
> GPIOs either, since they are not general purpose at all.
They are only general purpose until you connect the i/o lines to
something. But yes, if we went around making every misc internal
control line in SOCs a 1-bit GPIO controller that would be pretty
crazy.
Anyway, most of this is not actually used ATM on Versatile, but it is
present in VExpress. I added it only for sched_clock. We need to
resolve this with VExpress platforms, but it's already in use for MMC
and LEDs.
Rob
> For the latter I have some code boiling for the Integrators:
> https://git.kernel.org/cgit/linux/kernel/git/linusw/linux-integrator.git/commit/?h=multiplatform&id=9c28e114ec957fadf1dade382d8e8b8aa43c8426
> https://git.kernel.org/cgit/linux/kernel/git/linusw/linux-integrator.git/commit/?h=multiplatform&id=a3d4512abb85de290cdca0586bcff9147833917f
>
> Yours,
> Linus Walleij
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 5/9] dts: versatile: add sysregs nodes
2015-01-08 23:53 ` Rob Herring
@ 2015-01-09 7:10 ` Linus Walleij
-1 siblings, 0 replies; 86+ messages in thread
From: Linus Walleij @ 2015-01-09 7:10 UTC (permalink / raw)
To: Rob Herring
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Russell King, Peter Maydell,
arm-DgEjT+Ai2ygdnm+yROfE0A, Bjorn Helgaas, Lorenzo Pieralisi,
Liviu Dudau, Sudeep Holla
On Fri, Jan 9, 2015 at 12:53 AM, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Thu, Jan 8, 2015 at 1:44 PM, Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>> On Tue, Dec 30, 2014 at 8:28 PM, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> compatible = "syscon";
>
> maybe? VExpress is missing that then...
I don't like the way some vexpress stuff has been done I think, just
not enough reviewing power :(
I've tried to make an as clean separation as possible in the Integrator
as it has been refactored with a minimum of time pressure and
I tried to make it as reusable as possible. But it doesn't necessarily
mean I did the right thing all the time ...
>>> + reg = <0x00000 0x1000>;
>>> +
>>> + v2m_led_gpios: sys_led@08 {
>>> + compatible = "arm,vexpress-sysreg,sys_led";
>>> + gpio-controller;
>>> + #gpio-cells = <2>;
>>> + };
>>
>> These are not GPIOs. These are LED registers really.
>
> A register bit that controls an i/o signal sounds like a GPIO to me.
Are they described as general purpose in the manual for the
board?
In the ARM reference design manuals I've seen these bits are
described as for one purpose only. I mean you can claim the
memory RE signal is "a bit that controls an I/O signal" as well,
but we have to think about the abstraction here.
>> see how to use LEDs from drivers/leds/leds-syscon.c and bindings.
>> example in:
>> arch/arm/boot/dts/integrator.dtsi
>>
>> Very straight-forward I think.
>
> So we have 2 implementations and bindings for roughly the same hardware? Great!
The syscon stuff is designed to be reusable for machines outside
the Versatile and ARM reference families.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 5/9] dts: versatile: add sysregs nodes
@ 2015-01-09 7:10 ` Linus Walleij
0 siblings, 0 replies; 86+ messages in thread
From: Linus Walleij @ 2015-01-09 7:10 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Jan 9, 2015 at 12:53 AM, Rob Herring <robherring2@gmail.com> wrote:
> On Thu, Jan 8, 2015 at 1:44 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>> On Tue, Dec 30, 2014 at 8:28 PM, Rob Herring <robherring2@gmail.com> wrote:
>> compatible = "syscon";
>
> maybe? VExpress is missing that then...
I don't like the way some vexpress stuff has been done I think, just
not enough reviewing power :(
I've tried to make an as clean separation as possible in the Integrator
as it has been refactored with a minimum of time pressure and
I tried to make it as reusable as possible. But it doesn't necessarily
mean I did the right thing all the time ...
>>> + reg = <0x00000 0x1000>;
>>> +
>>> + v2m_led_gpios: sys_led at 08 {
>>> + compatible = "arm,vexpress-sysreg,sys_led";
>>> + gpio-controller;
>>> + #gpio-cells = <2>;
>>> + };
>>
>> These are not GPIOs. These are LED registers really.
>
> A register bit that controls an i/o signal sounds like a GPIO to me.
Are they described as general purpose in the manual for the
board?
In the ARM reference design manuals I've seen these bits are
described as for one purpose only. I mean you can claim the
memory RE signal is "a bit that controls an I/O signal" as well,
but we have to think about the abstraction here.
>> see how to use LEDs from drivers/leds/leds-syscon.c and bindings.
>> example in:
>> arch/arm/boot/dts/integrator.dtsi
>>
>> Very straight-forward I think.
>
> So we have 2 implementations and bindings for roughly the same hardware? Great!
The syscon stuff is designed to be reusable for machines outside
the Versatile and ARM reference families.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 0/9] ARM Versatile multi-platform support
2015-01-08 21:38 ` Rob Herring
@ 2015-01-09 8:34 ` Linus Walleij
-1 siblings, 0 replies; 86+ messages in thread
From: Linus Walleij @ 2015-01-09 8:34 UTC (permalink / raw)
To: Rob Herring, linux-gpio-u79uwXL29TY76Z2rM5mHXA,
Alexandre Courbot, Lee Jones, Paweł Moll, Arnd Bergmann
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Russell King, Peter Maydell,
arm-DgEjT+Ai2ygdnm+yROfE0A, Bjorn Helgaas
On Thu, Jan 8, 2015 at 10:38 PM, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Thu, Jan 8, 2015 at 1:47 PM, Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>> On Tue, Dec 30, 2014 at 8:28 PM, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>
>>> From: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>>
>>> This series converts ARM Versatile platform to multi-platform. I started
>>> this some time ago and some pieces were already merged. The primary
>>> piece remaining is converting the PCI host to DT which I was waiting for
>>> the common PCI DT parsing to get settled. Now that that is in place as
>>> well as a few other pieces are in place like multi-platform fixes for
>>> CLCD, we can fully convert Versatile to DT and multi-platform.
>>>
>>> There's still a few things that need DT support which can be done
>>> later:
>>> - MMC card detect and write protect. Should be able to use VExpress
>>> support
>>> - Reboot support. Should be able to re-use Realview reboot code.
>>> - flash phys-map support. Binding exists, but specifically Vpp control
>>> is needed.
>>> - CLCD support. Not sure where this is at.
>>
>> I like it overall but would like to see some use of the syscon
>> pattern to access random registers in syscon, and specifically not
>> to refer to these registers as some "gpio" because they aren't.
>
> I'm not sure I follow. Creating GPIO lines for SD card detect and
> write protect is exactly how VExpress syscon was implemented.
Hm it all boils down to this mfd/vexpress-sysreg.c driver that
spawns some MFD devices.
>From there a LED, card detect and flash protection are modeled as
"basic-mmio-gpio" instantiating the drivers/gpio/gpio-generic.c
driver to drive/read various bits.
Specifically commit 974cc7b93441a0e78f030495436d1be7eb7c208d
that makes a layered MFD->gpio->gpio LED cake.
Needless to say neither the GPIO maintainers or the GPIO
mailing list was included in review of this patch and it was
merged on its MFD merits :(
It is sort of elegant in a way, but I don't like it when we describe
registers that are not general purpose as "general purpose input
output" it is simply ontologically wrong and a misleading hardware
description. These bits are not general purpose *at* *all* they are
special purpose.
It is Linux GPIO implementation details leaking into the hardware
description basically: it just happened to be very convenient to
describe these register bits as "gpios" as the drivers etc were
already in place.
I prefer syscon->syscon LED as a two layer cake
instead of a three layer cake involving GPIO and it's more to the point,
describing the hardware properly, so I say let's go for that instead.
For card detect and flash protection I suspect we can use
syscon as well, avoiding shoehorning a GPIO abstraction between
it.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 0/9] ARM Versatile multi-platform support
@ 2015-01-09 8:34 ` Linus Walleij
0 siblings, 0 replies; 86+ messages in thread
From: Linus Walleij @ 2015-01-09 8:34 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Jan 8, 2015 at 10:38 PM, Rob Herring <robherring2@gmail.com> wrote:
> On Thu, Jan 8, 2015 at 1:47 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>> On Tue, Dec 30, 2014 at 8:28 PM, Rob Herring <robherring2@gmail.com> wrote:
>>
>>> From: Rob Herring <robh@kernel.org>
>>>
>>> This series converts ARM Versatile platform to multi-platform. I started
>>> this some time ago and some pieces were already merged. The primary
>>> piece remaining is converting the PCI host to DT which I was waiting for
>>> the common PCI DT parsing to get settled. Now that that is in place as
>>> well as a few other pieces are in place like multi-platform fixes for
>>> CLCD, we can fully convert Versatile to DT and multi-platform.
>>>
>>> There's still a few things that need DT support which can be done
>>> later:
>>> - MMC card detect and write protect. Should be able to use VExpress
>>> support
>>> - Reboot support. Should be able to re-use Realview reboot code.
>>> - flash phys-map support. Binding exists, but specifically Vpp control
>>> is needed.
>>> - CLCD support. Not sure where this is at.
>>
>> I like it overall but would like to see some use of the syscon
>> pattern to access random registers in syscon, and specifically not
>> to refer to these registers as some "gpio" because they aren't.
>
> I'm not sure I follow. Creating GPIO lines for SD card detect and
> write protect is exactly how VExpress syscon was implemented.
Hm it all boils down to this mfd/vexpress-sysreg.c driver that
spawns some MFD devices.
>From there a LED, card detect and flash protection are modeled as
"basic-mmio-gpio" instantiating the drivers/gpio/gpio-generic.c
driver to drive/read various bits.
Specifically commit 974cc7b93441a0e78f030495436d1be7eb7c208d
that makes a layered MFD->gpio->gpio LED cake.
Needless to say neither the GPIO maintainers or the GPIO
mailing list was included in review of this patch and it was
merged on its MFD merits :(
It is sort of elegant in a way, but I don't like it when we describe
registers that are not general purpose as "general purpose input
output" it is simply ontologically wrong and a misleading hardware
description. These bits are not general purpose *at* *all* they are
special purpose.
It is Linux GPIO implementation details leaking into the hardware
description basically: it just happened to be very convenient to
describe these register bits as "gpios" as the drivers etc were
already in place.
I prefer syscon->syscon LED as a two layer cake
instead of a three layer cake involving GPIO and it's more to the point,
describing the hardware properly, so I say let's go for that instead.
For card detect and flash protection I suspect we can use
syscon as well, avoiding shoehorning a GPIO abstraction between
it.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 5/9] dts: versatile: add sysregs nodes
2015-01-09 7:10 ` Linus Walleij
@ 2015-01-09 11:53 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 86+ messages in thread
From: Lorenzo Pieralisi @ 2015-01-09 11:53 UTC (permalink / raw)
To: Linus Walleij
Cc: Rob Herring, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Russell King, Peter Maydell,
arm-DgEjT+Ai2ygdnm+yROfE0A, Bjorn Helgaas, Liviu Dudau,
Sudeep Holla, pawel.moll-5wv7dgnIgG8
Cc'ing Pawel since he wrote the sysreg code
On Fri, Jan 09, 2015 at 07:10:36AM +0000, Linus Walleij wrote:
> On Fri, Jan 9, 2015 at 12:53 AM, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > On Thu, Jan 8, 2015 at 1:44 PM, Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>
> >> On Tue, Dec 30, 2014 at 8:28 PM, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >> compatible = "syscon";
> >
> > maybe? VExpress is missing that then...
>
> I don't like the way some vexpress stuff has been done I think, just
> not enough reviewing power :(
I think that "syscon" is not meant to be there in the first place and it
was done on purpose for vexpress but I need Pawel to confirm and shed
light on this.
> I've tried to make an as clean separation as possible in the Integrator
> as it has been refactored with a minimum of time pressure and
> I tried to make it as reusable as possible. But it doesn't necessarily
> mean I did the right thing all the time ...
>
> >>> + reg = <0x00000 0x1000>;
> >>> +
> >>> + v2m_led_gpios: sys_led@08 {
> >>> + compatible = "arm,vexpress-sysreg,sys_led";
> >>> + gpio-controller;
> >>> + #gpio-cells = <2>;
> >>> + };
> >>
> >> These are not GPIOs. These are LED registers really.
> >
> > A register bit that controls an i/o signal sounds like a GPIO to me.
>
> Are they described as general purpose in the manual for the
> board?
>
> In the ARM reference design manuals I've seen these bits are
> described as for one purpose only. I mean you can claim the
> memory RE signal is "a bit that controls an I/O signal" as well,
> but we have to think about the abstraction here.
I will have a look into this.
Thanks,
Lorenzo
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 5/9] dts: versatile: add sysregs nodes
@ 2015-01-09 11:53 ` Lorenzo Pieralisi
0 siblings, 0 replies; 86+ messages in thread
From: Lorenzo Pieralisi @ 2015-01-09 11:53 UTC (permalink / raw)
To: linux-arm-kernel
Cc'ing Pawel since he wrote the sysreg code
On Fri, Jan 09, 2015 at 07:10:36AM +0000, Linus Walleij wrote:
> On Fri, Jan 9, 2015 at 12:53 AM, Rob Herring <robherring2@gmail.com> wrote:
> > On Thu, Jan 8, 2015 at 1:44 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>
> >> On Tue, Dec 30, 2014 at 8:28 PM, Rob Herring <robherring2@gmail.com> wrote:
> >> compatible = "syscon";
> >
> > maybe? VExpress is missing that then...
>
> I don't like the way some vexpress stuff has been done I think, just
> not enough reviewing power :(
I think that "syscon" is not meant to be there in the first place and it
was done on purpose for vexpress but I need Pawel to confirm and shed
light on this.
> I've tried to make an as clean separation as possible in the Integrator
> as it has been refactored with a minimum of time pressure and
> I tried to make it as reusable as possible. But it doesn't necessarily
> mean I did the right thing all the time ...
>
> >>> + reg = <0x00000 0x1000>;
> >>> +
> >>> + v2m_led_gpios: sys_led at 08 {
> >>> + compatible = "arm,vexpress-sysreg,sys_led";
> >>> + gpio-controller;
> >>> + #gpio-cells = <2>;
> >>> + };
> >>
> >> These are not GPIOs. These are LED registers really.
> >
> > A register bit that controls an i/o signal sounds like a GPIO to me.
>
> Are they described as general purpose in the manual for the
> board?
>
> In the ARM reference design manuals I've seen these bits are
> described as for one purpose only. I mean you can claim the
> memory RE signal is "a bit that controls an I/O signal" as well,
> but we have to think about the abstraction here.
I will have a look into this.
Thanks,
Lorenzo
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 5/9] dts: versatile: add sysregs nodes
2015-01-08 23:53 ` Rob Herring
@ 2015-01-15 16:06 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 86+ messages in thread
From: Lorenzo Pieralisi @ 2015-01-15 16:06 UTC (permalink / raw)
To: Rob Herring
Cc: Linus Walleij, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Russell King, Peter Maydell,
arm-DgEjT+Ai2ygdnm+yROfE0A, Bjorn Helgaas, Liviu Dudau,
Sudeep Holla
On Thu, Jan 08, 2015 at 11:53:15PM +0000, Rob Herring wrote:
> Adding VExpress maintainers...
>
> On Thu, Jan 8, 2015 at 1:44 PM, Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> > On Tue, Dec 30, 2014 at 8:28 PM, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >
> >> From: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> >>
> >> The Versatile boards have the same sysregs as other ARM Ltd boards. Add
> >> the nodes in preparation to enable support for 24MHz counter as
> >> sched_clock and MMC card detect and write protect support.
> >>
> >> Signed-off-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> >> Cc: Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
> >> Cc: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> >> ---
> >> arch/arm/boot/dts/versatile-ab.dts | 23 +++++++++++++++++++++++
> >> 1 file changed, 23 insertions(+)
> >>
> >> diff --git a/arch/arm/boot/dts/versatile-ab.dts b/arch/arm/boot/dts/versatile-ab.dts
> >> index 27d0d9c..62f04b0 100644
> >> --- a/arch/arm/boot/dts/versatile-ab.dts
> >> +++ b/arch/arm/boot/dts/versatile-ab.dts
> >> @@ -252,6 +252,29 @@
> >> #size-cells = <1>;
> >> ranges = <0 0x10000000 0x10000>;
> >>
> >> + sysreg@0 {
> >> + compatible = "arm,vexpress-sysreg";
> >
> > vexpress? No...
>
> Compatible with yes. Should perhaps be '"arm,versatile-sysreg",
> "arm,vexpress-sysreg"' instead. Kind of backwards, as really the
> versatile came first, but it would work. Or we just need another match
> entry in the kernel.
versatile and vexpress sys registers are not compatible, so they should
not be treated as such.
Actually, versatile regs are not managed by a single entity driver
in the kernel, so basically I really think you should not leave
"arm,vexpress-sysreg"
in the compatible list.
> I copied this whole chunk as is from VExpress and verified these sub
> nodes are all the same hence why it is here.
>
> > compatible = "syscon";
>
> maybe? VExpress is missing that then...
vexpress-sysreg is more than a "syscon" interface, so we can't match
on it, it would be wrong.
>
> >> + reg = <0x00000 0x1000>;
> >> +
> >> + v2m_led_gpios: sys_led@08 {
> >> + compatible = "arm,vexpress-sysreg,sys_led";
> >> + gpio-controller;
> >> + #gpio-cells = <2>;
> >> + };
> >
> > These are not GPIOs. These are LED registers really.
>
> A register bit that controls an i/o signal sounds like a GPIO to me.
To me too. I agree that definining a gpio-controller for every possible
gpio pin would soon get unwieldy, but hey, the choice made for vexpress
leds makes perfect sense to me, after all they are gpio signals
connected to leds, and there is a driver for that in the kernel:
drivers/leds/leds-gpio.c
we could move this stuff to syscon-leds, but honestly I think is one of those
things we could argue forever about that.
> > see how to use LEDs from drivers/leds/leds-syscon.c and bindings.
> > example in:
> > arch/arm/boot/dts/integrator.dtsi
> >
> > Very straight-forward I think.
>
> So we have 2 implementations and bindings for roughly the same hardware? Great!
See above.
> >> + v2m_mmc_gpios: sys_mci@48 {
> >> + compatible = "arm,vexpress-sysreg,sys_mci";
> >> + gpio-controller;
> >> + #gpio-cells = <2>;
> >> + };
> >> +
> >> + v2m_flash_gpios: sys_flash@4c {
> >> + compatible = "arm,vexpress-sysreg,sys_flash";
> >> + gpio-controller;
> >> + #gpio-cells = <2>;
> >> + };
> >
> > I don't have drivers for these "gpio controllers" and I don't think they are
> > GPIOs either, since they are not general purpose at all.
>
> They are only general purpose until you connect the i/o lines to
> something. But yes, if we went around making every misc internal
> control line in SOCs a 1-bit GPIO controller that would be pretty
> crazy.
>
> Anyway, most of this is not actually used ATM on Versatile, but it is
> present in VExpress. I added it only for sched_clock. We need to
> resolve this with VExpress platforms, but it's already in use for MMC
> and LEDs.
I did not get what you meant here, in particular which bits you want us
to fix/change/update on vexpress.
Thanks,
Lorenzo
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 5/9] dts: versatile: add sysregs nodes
@ 2015-01-15 16:06 ` Lorenzo Pieralisi
0 siblings, 0 replies; 86+ messages in thread
From: Lorenzo Pieralisi @ 2015-01-15 16:06 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Jan 08, 2015 at 11:53:15PM +0000, Rob Herring wrote:
> Adding VExpress maintainers...
>
> On Thu, Jan 8, 2015 at 1:44 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> > On Tue, Dec 30, 2014 at 8:28 PM, Rob Herring <robherring2@gmail.com> wrote:
> >
> >> From: Rob Herring <robh@kernel.org>
> >>
> >> The Versatile boards have the same sysregs as other ARM Ltd boards. Add
> >> the nodes in preparation to enable support for 24MHz counter as
> >> sched_clock and MMC card detect and write protect support.
> >>
> >> Signed-off-by: Rob Herring <robh@kernel.org>
> >> Cc: Russell King <linux@arm.linux.org.uk>
> >> Cc: Linus Walleij <linus.walleij@linaro.org>
> >> ---
> >> arch/arm/boot/dts/versatile-ab.dts | 23 +++++++++++++++++++++++
> >> 1 file changed, 23 insertions(+)
> >>
> >> diff --git a/arch/arm/boot/dts/versatile-ab.dts b/arch/arm/boot/dts/versatile-ab.dts
> >> index 27d0d9c..62f04b0 100644
> >> --- a/arch/arm/boot/dts/versatile-ab.dts
> >> +++ b/arch/arm/boot/dts/versatile-ab.dts
> >> @@ -252,6 +252,29 @@
> >> #size-cells = <1>;
> >> ranges = <0 0x10000000 0x10000>;
> >>
> >> + sysreg at 0 {
> >> + compatible = "arm,vexpress-sysreg";
> >
> > vexpress? No...
>
> Compatible with yes. Should perhaps be '"arm,versatile-sysreg",
> "arm,vexpress-sysreg"' instead. Kind of backwards, as really the
> versatile came first, but it would work. Or we just need another match
> entry in the kernel.
versatile and vexpress sys registers are not compatible, so they should
not be treated as such.
Actually, versatile regs are not managed by a single entity driver
in the kernel, so basically I really think you should not leave
"arm,vexpress-sysreg"
in the compatible list.
> I copied this whole chunk as is from VExpress and verified these sub
> nodes are all the same hence why it is here.
>
> > compatible = "syscon";
>
> maybe? VExpress is missing that then...
vexpress-sysreg is more than a "syscon" interface, so we can't match
on it, it would be wrong.
>
> >> + reg = <0x00000 0x1000>;
> >> +
> >> + v2m_led_gpios: sys_led at 08 {
> >> + compatible = "arm,vexpress-sysreg,sys_led";
> >> + gpio-controller;
> >> + #gpio-cells = <2>;
> >> + };
> >
> > These are not GPIOs. These are LED registers really.
>
> A register bit that controls an i/o signal sounds like a GPIO to me.
To me too. I agree that definining a gpio-controller for every possible
gpio pin would soon get unwieldy, but hey, the choice made for vexpress
leds makes perfect sense to me, after all they are gpio signals
connected to leds, and there is a driver for that in the kernel:
drivers/leds/leds-gpio.c
we could move this stuff to syscon-leds, but honestly I think is one of those
things we could argue forever about that.
> > see how to use LEDs from drivers/leds/leds-syscon.c and bindings.
> > example in:
> > arch/arm/boot/dts/integrator.dtsi
> >
> > Very straight-forward I think.
>
> So we have 2 implementations and bindings for roughly the same hardware? Great!
See above.
> >> + v2m_mmc_gpios: sys_mci at 48 {
> >> + compatible = "arm,vexpress-sysreg,sys_mci";
> >> + gpio-controller;
> >> + #gpio-cells = <2>;
> >> + };
> >> +
> >> + v2m_flash_gpios: sys_flash at 4c {
> >> + compatible = "arm,vexpress-sysreg,sys_flash";
> >> + gpio-controller;
> >> + #gpio-cells = <2>;
> >> + };
> >
> > I don't have drivers for these "gpio controllers" and I don't think they are
> > GPIOs either, since they are not general purpose at all.
>
> They are only general purpose until you connect the i/o lines to
> something. But yes, if we went around making every misc internal
> control line in SOCs a 1-bit GPIO controller that would be pretty
> crazy.
>
> Anyway, most of this is not actually used ATM on Versatile, but it is
> present in VExpress. I added it only for sched_clock. We need to
> resolve this with VExpress platforms, but it's already in use for MMC
> and LEDs.
I did not get what you meant here, in particular which bits you want us
to fix/change/update on vexpress.
Thanks,
Lorenzo
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 5/9] dts: versatile: add sysregs nodes
2015-01-15 16:06 ` Lorenzo Pieralisi
@ 2015-01-19 10:25 ` Linus Walleij
-1 siblings, 0 replies; 86+ messages in thread
From: Linus Walleij @ 2015-01-19 10:25 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Rob Herring, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Russell King, Peter Maydell,
arm-DgEjT+Ai2ygdnm+yROfE0A, Bjorn Helgaas, Liviu Dudau,
Sudeep Holla
On Thu, Jan 15, 2015 at 5:06 PM, Lorenzo Pieralisi
<lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org> wrote:
> On Thu, Jan 08, 2015 at 11:53:15PM +0000, Rob Herring wrote:
>> On Thu, Jan 8, 2015 at 1:44 PM, Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>> > On Tue, Dec 30, 2014 at 8:28 PM, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> >> + reg = <0x00000 0x1000>;
>> >> +
>> >> + v2m_led_gpios: sys_led@08 {
>> >> + compatible = "arm,vexpress-sysreg,sys_led";
>> >> + gpio-controller;
>> >> + #gpio-cells = <2>;
>> >> + };
>> >
>> > These are not GPIOs. These are LED registers really.
>>
>> A register bit that controls an i/o signal sounds like a GPIO to me.
>
> To me too. I agree that definining a gpio-controller for every possible
> gpio pin would soon get unwieldy, but hey, the choice made for vexpress
> leds makes perfect sense to me, after all they are gpio signals
> connected to leds, and there is a driver for that in the kernel:
>
> drivers/leds/leds-gpio.c
>
> we could move this stuff to syscon-leds, but honestly I think is one of those
> things we could argue forever about that.
OK it's just so that the GPIO maintainer disagrees with the way
gpio-controller is being used here, and I consequently NACK it
so for the record add my:
Nacked-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
To this patch if/when merging it through ARM SoC.
If the DT people think it is a good way to describe the hardware
and override this then I will live with it I guess...
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 5/9] dts: versatile: add sysregs nodes
@ 2015-01-19 10:25 ` Linus Walleij
0 siblings, 0 replies; 86+ messages in thread
From: Linus Walleij @ 2015-01-19 10:25 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Jan 15, 2015 at 5:06 PM, Lorenzo Pieralisi
<lorenzo.pieralisi@arm.com> wrote:
> On Thu, Jan 08, 2015 at 11:53:15PM +0000, Rob Herring wrote:
>> On Thu, Jan 8, 2015 at 1:44 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>> > On Tue, Dec 30, 2014 at 8:28 PM, Rob Herring <robherring2@gmail.com> wrote:
>> >> + reg = <0x00000 0x1000>;
>> >> +
>> >> + v2m_led_gpios: sys_led at 08 {
>> >> + compatible = "arm,vexpress-sysreg,sys_led";
>> >> + gpio-controller;
>> >> + #gpio-cells = <2>;
>> >> + };
>> >
>> > These are not GPIOs. These are LED registers really.
>>
>> A register bit that controls an i/o signal sounds like a GPIO to me.
>
> To me too. I agree that definining a gpio-controller for every possible
> gpio pin would soon get unwieldy, but hey, the choice made for vexpress
> leds makes perfect sense to me, after all they are gpio signals
> connected to leds, and there is a driver for that in the kernel:
>
> drivers/leds/leds-gpio.c
>
> we could move this stuff to syscon-leds, but honestly I think is one of those
> things we could argue forever about that.
OK it's just so that the GPIO maintainer disagrees with the way
gpio-controller is being used here, and I consequently NACK it
so for the record add my:
Nacked-by: Linus Walleij <linus.walleij@linaro.org>
To this patch if/when merging it through ARM SoC.
If the DT people think it is a good way to describe the hardware
and override this then I will live with it I guess...
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 4/9] pci: add DT based ARM Versatile PCI host driver
2014-12-30 19:28 ` Rob Herring
@ 2015-01-24 0:54 ` Bjorn Helgaas
-1 siblings, 0 replies; 86+ messages in thread
From: Bjorn Helgaas @ 2015-01-24 0:54 UTC (permalink / raw)
To: Rob Herring
Cc: linux-arm-kernel, devicetree, Russell King, Linus Walleij,
Peter Maydell, arm, Rob Herring, linux-pci
Sorry for the late reply; maybe this has already been queued up somewhere,
so this might be moot.
I usually capitalize the "PCI" and first letter of the subject, like:
PCI: Add DT based ARM Versatile PCI host driver
And I try to ask for MAINTAINER updates since these drivers are under
drivers/pci, but I can't maintain them all myself.
On Tue, Dec 30, 2014 at 01:28:33PM -0600, Rob Herring wrote:
> From: Rob Herring <robh@kernel.org>
>
> This converts the Versatile PCI host code to a platform driver using
> the commom DT parsing and setup. The driver uses only an empty ARM
> pci_sys_data struct and does not use pci_common_init_dev init function.
> The old host code will be removed in a subsequent commit when Versatile
> is completely converted to DT.
>
> I've tested this on QEMU with the sym53c8xx driver in both i/o and
> memory mapped modes.
>
> Signed-off-by: Rob Herring <robh@kernel.org>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: linux-pci@vger.kernel.org
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Peter Maydell <peter.maydell@linaro.org>
Looks fine to me.
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> +++ b/drivers/pci/host/pci-versatile.c
> ...
> + /*
> + * We need to discover the PCI core first to configure itself
> + * before the main PCI probing is performed
Unusual to have two spaces between the "*" and the comments here.
> +MODULE_LICENSE("GPLv2");
This needs to be "GPL v2" per license_is_gpl_compatible().
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 4/9] pci: add DT based ARM Versatile PCI host driver
@ 2015-01-24 0:54 ` Bjorn Helgaas
0 siblings, 0 replies; 86+ messages in thread
From: Bjorn Helgaas @ 2015-01-24 0:54 UTC (permalink / raw)
To: linux-arm-kernel
Sorry for the late reply; maybe this has already been queued up somewhere,
so this might be moot.
I usually capitalize the "PCI" and first letter of the subject, like:
PCI: Add DT based ARM Versatile PCI host driver
And I try to ask for MAINTAINER updates since these drivers are under
drivers/pci, but I can't maintain them all myself.
On Tue, Dec 30, 2014 at 01:28:33PM -0600, Rob Herring wrote:
> From: Rob Herring <robh@kernel.org>
>
> This converts the Versatile PCI host code to a platform driver using
> the commom DT parsing and setup. The driver uses only an empty ARM
> pci_sys_data struct and does not use pci_common_init_dev init function.
> The old host code will be removed in a subsequent commit when Versatile
> is completely converted to DT.
>
> I've tested this on QEMU with the sym53c8xx driver in both i/o and
> memory mapped modes.
>
> Signed-off-by: Rob Herring <robh@kernel.org>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: linux-pci at vger.kernel.org
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Peter Maydell <peter.maydell@linaro.org>
Looks fine to me.
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> +++ b/drivers/pci/host/pci-versatile.c
> ...
> + /*
> + * We need to discover the PCI core first to configure itself
> + * before the main PCI probing is performed
Unusual to have two spaces between the "*" and the comments here.
> +MODULE_LICENSE("GPLv2");
This needs to be "GPL v2" per license_is_gpl_compatible().
^ permalink raw reply [flat|nested] 86+ messages in thread
* Re: [PATCH 4/9] pci: add DT based ARM Versatile PCI host driver
2014-12-30 21:58 ` Arnd Bergmann
@ 2015-01-24 1:01 ` Bjorn Helgaas
-1 siblings, 0 replies; 86+ messages in thread
From: Bjorn Helgaas @ 2015-01-24 1:01 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, Rob Herring, devicetree, Peter Maydell,
Russell King, Rob Herring, linux-pci, Linus Walleij, arm
On Tue, Dec 30, 2014 at 10:58:00PM +0100, Arnd Bergmann wrote:
> On Tuesday 30 December 2014 13:28:33 Rob Herring wrote:
> > + list_for_each_entry(win, res, list) {
> > + struct resource *parent, *res = win->res;
> > +
> > + switch (resource_type(res)) {
> > + case IORESOURCE_IO:
> > + parent = &ioport_resource;
> > + err = pci_remap_iospace(res, iobase);
> > + if (err) {
> > + dev_warn(dev, "error %d: failed to map resource %pR\n",
> > + err, res);
> > + continue;
> > + }
> > + break;
> > + case IORESOURCE_MEM:
> > + parent = &iomem_resource;
> > + res_valid |= !(res->flags & IORESOURCE_PREFETCH);
> > +
> > + writel(res->start >> 28, PCI_IMAP(mem));
> > + writel(PHYS_OFFSET >> 28, PCI_SMAP(mem));
> > + mem++;
> > +
> > + break;
> > + case IORESOURCE_BUS:
> > + default:
> > + continue;
> > + }
> > +
> > + err = devm_request_resource(dev, parent, res);
> > + if (err)
> > + goto out_release_res;
> > + }
>
> I wonder if we should also request the physical resource for the I/O space
> window to have it show up in /proc/iomem. We are rather inconsistent in this
> regard between drivers.
I'd like that. We are inconsistent, but I think it's useful to have this
information in /proc/iomem. After all, it is physical address space that
we can't use for anything else, so I guess you could argue that it's
actually a bug to omit it.
> > + pci_add_flags(PCI_ENABLE_PROC_DOMAINS);
> > + pci_add_flags(PCI_REASSIGN_ALL_BUS | PCI_REASSIGN_ALL_RSRC);
> > +
> > + bus = pci_scan_root_bus(&pdev->dev, 0, &pci_versatile_ops, &sys, &pci_res);
> > + if (!bus)
> > + return -ENOMEM;
> > +
> > + pci_fixup_irqs(pci_common_swizzle, of_irq_parse_and_map_pci);
> > + pci_assign_unassigned_bus_resources(bus);
> > +
> > + return 0;
>
> One general question, mainly for Bjorn: pci_scan_root_bus adds all the devices
> at the Linux driver level by calling pci_bus_add_devices(), but then we call
> pci_fixup_irqs and pci_assign_unassigned_bus_resources after that, which will
> change the devices again. Is this how it's meant to work? How do we ensure
> that we have the correct irq number and resources by the time we enter the
> probe() function of the PCI device driver that gets bound to a device here?
Nope, that isn't how it's meant to work. After pci_bus_add_devices()
completes, drivers can be already bound to the device, and the PCI core
should keep its mitts off things the driver could be using. But I think
we've had this problem for a long time, and I haven't looked at it recently
to see how hard it would be to fix.
Bjorn
^ permalink raw reply [flat|nested] 86+ messages in thread
* [PATCH 4/9] pci: add DT based ARM Versatile PCI host driver
@ 2015-01-24 1:01 ` Bjorn Helgaas
0 siblings, 0 replies; 86+ messages in thread
From: Bjorn Helgaas @ 2015-01-24 1:01 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Dec 30, 2014 at 10:58:00PM +0100, Arnd Bergmann wrote:
> On Tuesday 30 December 2014 13:28:33 Rob Herring wrote:
> > + list_for_each_entry(win, res, list) {
> > + struct resource *parent, *res = win->res;
> > +
> > + switch (resource_type(res)) {
> > + case IORESOURCE_IO:
> > + parent = &ioport_resource;
> > + err = pci_remap_iospace(res, iobase);
> > + if (err) {
> > + dev_warn(dev, "error %d: failed to map resource %pR\n",
> > + err, res);
> > + continue;
> > + }
> > + break;
> > + case IORESOURCE_MEM:
> > + parent = &iomem_resource;
> > + res_valid |= !(res->flags & IORESOURCE_PREFETCH);
> > +
> > + writel(res->start >> 28, PCI_IMAP(mem));
> > + writel(PHYS_OFFSET >> 28, PCI_SMAP(mem));
> > + mem++;
> > +
> > + break;
> > + case IORESOURCE_BUS:
> > + default:
> > + continue;
> > + }
> > +
> > + err = devm_request_resource(dev, parent, res);
> > + if (err)
> > + goto out_release_res;
> > + }
>
> I wonder if we should also request the physical resource for the I/O space
> window to have it show up in /proc/iomem. We are rather inconsistent in this
> regard between drivers.
I'd like that. We are inconsistent, but I think it's useful to have this
information in /proc/iomem. After all, it is physical address space that
we can't use for anything else, so I guess you could argue that it's
actually a bug to omit it.
> > + pci_add_flags(PCI_ENABLE_PROC_DOMAINS);
> > + pci_add_flags(PCI_REASSIGN_ALL_BUS | PCI_REASSIGN_ALL_RSRC);
> > +
> > + bus = pci_scan_root_bus(&pdev->dev, 0, &pci_versatile_ops, &sys, &pci_res);
> > + if (!bus)
> > + return -ENOMEM;
> > +
> > + pci_fixup_irqs(pci_common_swizzle, of_irq_parse_and_map_pci);
> > + pci_assign_unassigned_bus_resources(bus);
> > +
> > + return 0;
>
> One general question, mainly for Bjorn: pci_scan_root_bus adds all the devices
> at the Linux driver level by calling pci_bus_add_devices(), but then we call
> pci_fixup_irqs and pci_assign_unassigned_bus_resources after that, which will
> change the devices again. Is this how it's meant to work? How do we ensure
> that we have the correct irq number and resources by the time we enter the
> probe() function of the PCI device driver that gets bound to a device here?
Nope, that isn't how it's meant to work. After pci_bus_add_devices()
completes, drivers can be already bound to the device, and the PCI core
should keep its mitts off things the driver could be using. But I think
we've had this problem for a long time, and I haven't looked at it recently
to see how hard it would be to fix.
Bjorn
^ permalink raw reply [flat|nested] 86+ messages in thread
end of thread, other threads:[~2015-01-24 1:01 UTC | newest]
Thread overview: 86+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-12-30 19:28 [PATCH 0/9] ARM Versatile multi-platform support Rob Herring
2014-12-30 19:28 ` Rob Herring
[not found] ` <1419967718-26909-1-git-send-email-robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-12-30 19:28 ` [PATCH 1/9] dt/bindings: add versatile PCI binding Rob Herring
2014-12-30 19:28 ` Rob Herring
2014-12-30 19:28 ` [PATCH 2/9] dts: versatile: add PCI controller binding Rob Herring
2014-12-30 19:28 ` Rob Herring
2014-12-30 19:28 ` [PATCH 3/9] ARM: versatile: add DT based PCI detection Rob Herring
2014-12-30 19:28 ` Rob Herring
[not found] ` <1419967718-26909-4-git-send-email-robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-12-30 21:37 ` Arnd Bergmann
2014-12-30 21:37 ` Arnd Bergmann
2014-12-30 23:05 ` Rob Herring
2014-12-30 23:05 ` Rob Herring
[not found] ` <CAL_Jsq+iVWPsN9LXEMT6DmjS7MGsnmgJLgyb33N3me=OcCet6g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-12-31 15:23 ` Arnd Bergmann
2014-12-31 15:23 ` Arnd Bergmann
2014-12-31 16:13 ` Peter Maydell
2014-12-31 16:13 ` Peter Maydell
[not found] ` <CAFEAcA9=eoP4-F0Z8J171=DHE5JHVn7ahMnQrHQFz9SHePQHNQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-12-31 19:22 ` Rob Herring
2014-12-31 19:22 ` Rob Herring
[not found] ` <CAL_JsqLBCeCc2VKvHAdG5bBJt=2qmX5BnosdGd_2n+Pb9BhuZQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-12-31 21:07 ` Peter Maydell
2014-12-31 21:07 ` Peter Maydell
[not found] ` <CAFEAcA-=2GGEAdnO9+8EV+8OkwUHj3tRiMYWvS4b-cpy6P6rYg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-01-01 15:35 ` Arnd Bergmann
2015-01-01 15:35 ` Arnd Bergmann
2015-01-01 15:52 ` Peter Maydell
2015-01-01 15:52 ` Peter Maydell
2015-01-08 19:37 ` Linus Walleij
2015-01-08 19:37 ` Linus Walleij
[not found] ` <CACRpkdYEHwXhw3nEPHp7+4rtzXyh9Qb2QCpsRMfopxNoaX3rLA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-01-08 21:34 ` Rob Herring
2015-01-08 21:34 ` Rob Herring
2014-12-30 19:28 ` [PATCH 5/9] dts: versatile: add sysregs nodes Rob Herring
2014-12-30 19:28 ` Rob Herring
[not found] ` <1419967718-26909-6-git-send-email-robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-01-08 19:44 ` Linus Walleij
2015-01-08 19:44 ` Linus Walleij
[not found] ` <CACRpkdbinR3Uvi5zZmQJFxJgnWfvE6JZouMVxxRRGVtMNXkBQQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-01-08 23:53 ` Rob Herring
2015-01-08 23:53 ` Rob Herring
[not found] ` <CAL_JsqKBLx03E1w0NMH8CH+Pm_L8yQvnR6VTTDxqnpOwAoDhXg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-01-09 7:10 ` Linus Walleij
2015-01-09 7:10 ` Linus Walleij
[not found] ` <CACRpkdZFxToT5L0sJXap-NQGtjkryn4KTZVnweKCxXL9WvFLEg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-01-09 11:53 ` Lorenzo Pieralisi
2015-01-09 11:53 ` Lorenzo Pieralisi
2015-01-15 16:06 ` Lorenzo Pieralisi
2015-01-15 16:06 ` Lorenzo Pieralisi
2015-01-19 10:25 ` Linus Walleij
2015-01-19 10:25 ` Linus Walleij
2014-12-30 19:28 ` [PATCH 6/9] ARM: versatile: switch to DT only booting and remove legacy code Rob Herring
2014-12-30 19:28 ` Rob Herring
2014-12-30 19:28 ` [PATCH 7/9] ARM: versatile: move mach includes into mach directory Rob Herring
2014-12-30 19:28 ` Rob Herring
[not found] ` <1419967718-26909-8-git-send-email-robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-12-30 22:05 ` Arnd Bergmann
2014-12-30 22:05 ` Arnd Bergmann
2014-12-30 19:28 ` [PATCH 8/9] ARM: versatile: convert to multi-platform Rob Herring
2014-12-30 19:28 ` Rob Herring
2014-12-30 19:28 ` [PATCH 9/9] ARM: versatile: consolidate code to single file Rob Herring
2014-12-30 19:28 ` Rob Herring
2014-12-30 22:08 ` [PATCH 0/9] ARM Versatile multi-platform support Arnd Bergmann
2014-12-30 22:08 ` Arnd Bergmann
2014-12-31 9:25 ` Peter Maydell
2014-12-31 9:25 ` Peter Maydell
[not found] ` <CAFEAcA9pKdRNQ-fgKumQhjTjei-4NJ-OB1gSOxTCnCjShy10jw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-01-05 9:50 ` Marc Zyngier
2015-01-05 9:50 ` Marc Zyngier
[not found] ` <54AA5E7C.1040706-5wv7dgnIgG8@public.gmane.org>
2015-01-05 10:08 ` Peter Maydell
2015-01-05 10:08 ` Peter Maydell
[not found] ` <CAFEAcA8Nq6BPOerN7EhHpT_oa9W3+2Y_=5+zBuQD_c5fh0Yb1A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-01-05 11:19 ` Marc Zyngier
2015-01-05 11:19 ` Marc Zyngier
[not found] ` <87y4ph79wb.fsf-BgpFEFc6EmV6Fr0h90IsVGS4ubULX0JqMm0uRHvK7Nw@public.gmane.org>
2015-01-05 17:41 ` Peter Maydell
2015-01-05 17:41 ` Peter Maydell
2015-01-08 19:47 ` Linus Walleij
2015-01-08 19:47 ` Linus Walleij
[not found] ` <CACRpkda8T8CwghVYtTw41h_y+GdCA5xCEaSL1Jy4VZBo3MAy-Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-01-08 21:38 ` Rob Herring
2015-01-08 21:38 ` Rob Herring
[not found] ` <CAL_JsqKLNPVDCUELaZU8JW0roT3RcyqcxtJbvbYQrjzxjt3FeQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-01-09 8:34 ` Linus Walleij
2015-01-09 8:34 ` Linus Walleij
2014-12-30 19:28 ` [PATCH 4/9] pci: add DT based ARM Versatile PCI host driver Rob Herring
2014-12-30 19:28 ` Rob Herring
2014-12-30 21:58 ` Arnd Bergmann
2014-12-30 21:58 ` Arnd Bergmann
2015-01-02 18:14 ` Rob Herring
2015-01-02 18:14 ` Rob Herring
2015-01-02 20:52 ` Arnd Bergmann
2015-01-02 20:52 ` Arnd Bergmann
2015-01-02 23:13 ` Rob Herring
2015-01-02 23:13 ` Rob Herring
2015-01-05 9:35 ` Arnd Bergmann
2015-01-05 9:35 ` Arnd Bergmann
2015-01-24 1:01 ` Bjorn Helgaas
2015-01-24 1:01 ` Bjorn Helgaas
2015-01-24 0:54 ` Bjorn Helgaas
2015-01-24 0:54 ` Bjorn Helgaas
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.