* [PATCH 0/7] ARM RealView DeviceTree support v6
@ 2014-09-08 11:37 ` Linus Walleij
0 siblings, 0 replies; 46+ messages in thread
From: Linus Walleij @ 2014-09-08 11:37 UTC (permalink / raw)
To: linux-arm-kernel, devicetree, linux-leds, linux-pm
Cc: Arnd Bergmann, Pawel Moll, Mark Rutland, Marc Zyngier,
Will Deacon, Rob Herring, Linus Walleij
I've updated the RealView DeviceTree patch again.
Main changes:
- Calculate cache associativity from ePAPR definitions
- Rely on the l2c_aux_[mask|val] from the DT_MACHINE
- Add cache line size to device tree
Florian Fainelli (1):
ARM: l2c: parse 'cache-size' and 'cache-sets' properties
Linus Walleij (6):
leds: add a driver for syscon-based LEDs
leds: add device tree bindings for register bit LEDs
power: reset: driver for the Versatile syscon reboot
soc: add driver for the ARM RealView
ARM: l2x0: calculate associativity from ePAPR cache props
ARM: realview: basic device tree implementation
Documentation/devicetree/bindings/arm/arm-boards | 65 ++++++
Documentation/devicetree/bindings/arm/gic.txt | 1 +
Documentation/devicetree/bindings/arm/l2cc.txt | 2 +
.../devicetree/bindings/leds/register-bit-led.txt | 99 +++++++++
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/arm-realview-pb1176.dts | 246 +++++++++++++++++++++
arch/arm/mach-realview/Kconfig | 13 ++
arch/arm/mach-realview/Makefile | 1 +
arch/arm/mach-realview/realview-dt.c | 32 +++
arch/arm/mm/cache-l2x0.c | 111 ++++++++++
drivers/irqchip/irq-gic.c | 2 +
drivers/leds/Kconfig | 10 +
drivers/leds/Makefile | 1 +
drivers/leds/leds-syscon.c | 165 ++++++++++++++
drivers/power/reset/Kconfig | 9 +
drivers/power/reset/Makefile | 1 +
drivers/power/reset/arm-versatile-reboot.c | 111 ++++++++++
drivers/soc/Kconfig | 1 +
drivers/soc/Makefile | 1 +
drivers/soc/versatile/Kconfig | 10 +
drivers/soc/versatile/Makefile | 1 +
drivers/soc/versatile/soc-realview.c | 144 ++++++++++++
22 files changed, 1027 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/register-bit-led.txt
create mode 100644 arch/arm/boot/dts/arm-realview-pb1176.dts
create mode 100644 arch/arm/mach-realview/realview-dt.c
create mode 100644 drivers/leds/leds-syscon.c
create mode 100644 drivers/power/reset/arm-versatile-reboot.c
create mode 100644 drivers/soc/versatile/Kconfig
create mode 100644 drivers/soc/versatile/Makefile
create mode 100644 drivers/soc/versatile/soc-realview.c
--
1.9.3
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 0/7] ARM RealView DeviceTree support v6
@ 2014-09-08 11:37 ` Linus Walleij
0 siblings, 0 replies; 46+ messages in thread
From: Linus Walleij @ 2014-09-08 11:37 UTC (permalink / raw)
To: linux-arm-kernel
I've updated the RealView DeviceTree patch again.
Main changes:
- Calculate cache associativity from ePAPR definitions
- Rely on the l2c_aux_[mask|val] from the DT_MACHINE
- Add cache line size to device tree
Florian Fainelli (1):
ARM: l2c: parse 'cache-size' and 'cache-sets' properties
Linus Walleij (6):
leds: add a driver for syscon-based LEDs
leds: add device tree bindings for register bit LEDs
power: reset: driver for the Versatile syscon reboot
soc: add driver for the ARM RealView
ARM: l2x0: calculate associativity from ePAPR cache props
ARM: realview: basic device tree implementation
Documentation/devicetree/bindings/arm/arm-boards | 65 ++++++
Documentation/devicetree/bindings/arm/gic.txt | 1 +
Documentation/devicetree/bindings/arm/l2cc.txt | 2 +
.../devicetree/bindings/leds/register-bit-led.txt | 99 +++++++++
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/arm-realview-pb1176.dts | 246 +++++++++++++++++++++
arch/arm/mach-realview/Kconfig | 13 ++
arch/arm/mach-realview/Makefile | 1 +
arch/arm/mach-realview/realview-dt.c | 32 +++
arch/arm/mm/cache-l2x0.c | 111 ++++++++++
drivers/irqchip/irq-gic.c | 2 +
drivers/leds/Kconfig | 10 +
drivers/leds/Makefile | 1 +
drivers/leds/leds-syscon.c | 165 ++++++++++++++
drivers/power/reset/Kconfig | 9 +
drivers/power/reset/Makefile | 1 +
drivers/power/reset/arm-versatile-reboot.c | 111 ++++++++++
drivers/soc/Kconfig | 1 +
drivers/soc/Makefile | 1 +
drivers/soc/versatile/Kconfig | 10 +
drivers/soc/versatile/Makefile | 1 +
drivers/soc/versatile/soc-realview.c | 144 ++++++++++++
22 files changed, 1027 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/register-bit-led.txt
create mode 100644 arch/arm/boot/dts/arm-realview-pb1176.dts
create mode 100644 arch/arm/mach-realview/realview-dt.c
create mode 100644 drivers/leds/leds-syscon.c
create mode 100644 drivers/power/reset/arm-versatile-reboot.c
create mode 100644 drivers/soc/versatile/Kconfig
create mode 100644 drivers/soc/versatile/Makefile
create mode 100644 drivers/soc/versatile/soc-realview.c
--
1.9.3
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 1/7 v6] leds: add a driver for syscon-based LEDs
2014-09-08 11:37 ` Linus Walleij
@ 2014-09-08 11:38 ` Linus Walleij
-1 siblings, 0 replies; 46+ messages in thread
From: Linus Walleij @ 2014-09-08 11:38 UTC (permalink / raw)
To: linux-arm-kernel, devicetree, linux-leds, linux-pm
Cc: Arnd Bergmann, Pawel Moll, Mark Rutland, Marc Zyngier,
Will Deacon, Rob Herring, Linus Walleij, Bryan Wu,
Richard Purdie
This makes it possible to create a set of LEDs from a syscon
MFD instance, which is lean mean and clean on the ARM
reference designs and can replace the Versatile LEDs driver
in the long run, as well as other custom syscon LEDs drivers.
Cc: Bryan Wu <cooloney@gmail.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v1->v2:
- Augment driver to probe all nodes of a syscon to see if they
are "register-bit-led"s, and then allocate them under the syscon
if that is the case.
- Switch compatible string from "syscon-leds" to "register-bit-led"
---
drivers/leds/Kconfig | 10 +++
drivers/leds/Makefile | 1 +
drivers/leds/leds-syscon.c | 165 +++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 176 insertions(+)
create mode 100644 drivers/leds/leds-syscon.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 8c96e2ddf43b..ea05b6e2ea58 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -478,6 +478,16 @@ config LEDS_BLINKM
This option enables support for the BlinkM RGB LED connected
through I2C. Say Y to enable support for the BlinkM LED.
+config LEDS_SYSCON
+ bool "LED support for LEDs on system controllers"
+ depends on LEDS_CLASS
+ depends on MFD_SYSCON
+ depends on OF
+ help
+ This option enabled support for the LEDs on syscon type
+ devices. This will only work with device tree enabled
+ devices.
+
config LEDS_VERSATILE
tristate "LED support for the ARM Versatile and RealView"
depends on ARCH_REALVIEW || ARCH_VERSATILE
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index d8cc5f2777de..822dd83ef97a 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -53,6 +53,7 @@ obj-$(CONFIG_LEDS_ASIC3) += leds-asic3.o
obj-$(CONFIG_LEDS_MAX8997) += leds-max8997.o
obj-$(CONFIG_LEDS_LM355x) += leds-lm355x.o
obj-$(CONFIG_LEDS_BLINKM) += leds-blinkm.o
+obj-$(CONFIG_LEDS_SYSCON) += leds-syscon.o
obj-$(CONFIG_LEDS_VERSATILE) += leds-versatile.o
# LED SPI Drivers
diff --git a/drivers/leds/leds-syscon.c b/drivers/leds/leds-syscon.c
new file mode 100644
index 000000000000..b6174f421ef2
--- /dev/null
+++ b/drivers/leds/leds-syscon.c
@@ -0,0 +1,165 @@
+/*
+ * Generic Syscon LEDs Driver
+ *
+ * Copyright (c) 2014, Linaro Limited
+ * Author: Linus Walleij <linus.walleij@linaro.org>
+ *
+ * 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
+ *
+ * This driver provides system reboot functionality for APM X-Gene SoC.
+ * For system shutdown, this is board specify. If a board designer
+ * implements GPIO shutdown, use the gpio-poweroff.c driver.
+ */
+#include <linux/io.h>
+#include <linux/of_device.h>
+#include <linux/of_address.h>
+#include <linux/platform_device.h>
+#include <linux/stat.h>
+#include <linux/slab.h>
+#include <linux/mfd/syscon.h>
+#include <linux/regmap.h>
+#include <linux/leds.h>
+
+/**
+ * struct syscon_led - state container for syscon based LEDs
+ * @cdev: LED class device for this LED
+ * @map: regmap to access the syscon device backing this LED
+ * @offset: the offset into the syscon regmap for the LED register
+ * @mask: the bit in the register corresponding to the LED
+ * @state: current state of the LED
+ */
+struct syscon_led {
+ struct led_classdev cdev;
+ struct regmap *map;
+ u32 offset;
+ u32 mask;
+ bool state;
+};
+
+static void syscon_led_set(struct led_classdev *led_cdev,
+ enum led_brightness value)
+{
+ struct syscon_led *sled =
+ container_of(led_cdev, struct syscon_led, cdev);
+ u32 val;
+ int ret;
+
+ if (value == LED_OFF) {
+ val = 0;
+ sled->state = false;
+ } else {
+ val = sled->mask;
+ sled->state = true;
+ }
+
+ ret = regmap_update_bits(sled->map, sled->offset, sled->mask, val);
+ if (ret < 0)
+ dev_err(sled->cdev.dev, "error updating LED status\n");
+}
+
+static const struct of_device_id syscon_match[] = {
+ { .compatible = "syscon", },
+};
+
+static int __init syscon_leds_init(void)
+{
+ const struct of_device_id *devid;
+ struct device_node *np;
+ struct device_node *child;
+ struct regmap *map;
+ struct platform_device *pdev;
+ struct device *dev;
+ int ret;
+
+ np = of_find_matching_node_and_match(NULL, syscon_match,
+ &devid);
+ if (!np)
+ return -ENODEV;
+
+ map = syscon_node_to_regmap(np);
+ if (IS_ERR(map))
+ return PTR_ERR(map);
+
+ /*
+ * If the map is there, the device should be there, we allocate
+ * memory on the syscon device's behalf here.
+ */
+ pdev = of_find_device_by_node(np);
+ if (!pdev)
+ return -ENODEV;
+ dev = &pdev->dev;
+
+ for_each_available_child_of_node(np, child) {
+ struct syscon_led *sled;
+ const char *state;
+
+ /* Only check for register-bit-leds */
+ if (of_property_match_string(child, "compatible",
+ "register-bit-led") < 0)
+ continue;
+
+ sled = devm_kzalloc(dev, sizeof(*sled), GFP_KERNEL);
+ if (!sled)
+ return -ENOMEM;
+
+ sled->map = map;
+
+ if (of_property_read_u32(child, "offset", &sled->offset))
+ return -EINVAL;
+ if (of_property_read_u32(child, "mask", &sled->mask))
+ return -EINVAL;
+ sled->cdev.name =
+ of_get_property(child, "label", NULL) ? : child->name;
+ sled->cdev.default_trigger =
+ of_get_property(child, "linux,default-trigger", NULL);
+
+ state = of_get_property(child, "default-state", NULL);
+ if (state) {
+ if (!strcmp(state, "keep")) {
+ u32 val;
+
+ ret = regmap_read(map, sled->offset, &val);
+ if (ret < 0)
+ return ret;
+ sled->state = !!(val & sled->mask);
+ } else if (!strcmp(state, "on")) {
+ sled->state = true;
+ ret = regmap_update_bits(map, sled->offset,
+ sled->mask,
+ sled->mask);
+ if (ret < 0)
+ return ret;
+ } else {
+ sled->state = false;
+ ret = regmap_update_bits(map, sled->offset,
+ sled->mask, 0);
+ if (ret < 0)
+ return ret;
+ }
+
+ }
+ sled->cdev.brightness_set = syscon_led_set;
+
+ ret = led_classdev_register(dev, &sled->cdev);
+ if (ret < 0)
+ return ret;
+
+ dev_info(dev, "registered LED %s\n", sled->cdev.name);
+ }
+
+ return 0;
+}
+device_initcall(syscon_leds_init);
--
1.9.3
^ permalink raw reply related [flat|nested] 46+ messages in thread
* [PATCH 1/7 v6] leds: add a driver for syscon-based LEDs
@ 2014-09-08 11:38 ` Linus Walleij
0 siblings, 0 replies; 46+ messages in thread
From: Linus Walleij @ 2014-09-08 11:38 UTC (permalink / raw)
To: linux-arm-kernel
This makes it possible to create a set of LEDs from a syscon
MFD instance, which is lean mean and clean on the ARM
reference designs and can replace the Versatile LEDs driver
in the long run, as well as other custom syscon LEDs drivers.
Cc: Bryan Wu <cooloney@gmail.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v1->v2:
- Augment driver to probe all nodes of a syscon to see if they
are "register-bit-led"s, and then allocate them under the syscon
if that is the case.
- Switch compatible string from "syscon-leds" to "register-bit-led"
---
drivers/leds/Kconfig | 10 +++
drivers/leds/Makefile | 1 +
drivers/leds/leds-syscon.c | 165 +++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 176 insertions(+)
create mode 100644 drivers/leds/leds-syscon.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 8c96e2ddf43b..ea05b6e2ea58 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -478,6 +478,16 @@ config LEDS_BLINKM
This option enables support for the BlinkM RGB LED connected
through I2C. Say Y to enable support for the BlinkM LED.
+config LEDS_SYSCON
+ bool "LED support for LEDs on system controllers"
+ depends on LEDS_CLASS
+ depends on MFD_SYSCON
+ depends on OF
+ help
+ This option enabled support for the LEDs on syscon type
+ devices. This will only work with device tree enabled
+ devices.
+
config LEDS_VERSATILE
tristate "LED support for the ARM Versatile and RealView"
depends on ARCH_REALVIEW || ARCH_VERSATILE
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index d8cc5f2777de..822dd83ef97a 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -53,6 +53,7 @@ obj-$(CONFIG_LEDS_ASIC3) += leds-asic3.o
obj-$(CONFIG_LEDS_MAX8997) += leds-max8997.o
obj-$(CONFIG_LEDS_LM355x) += leds-lm355x.o
obj-$(CONFIG_LEDS_BLINKM) += leds-blinkm.o
+obj-$(CONFIG_LEDS_SYSCON) += leds-syscon.o
obj-$(CONFIG_LEDS_VERSATILE) += leds-versatile.o
# LED SPI Drivers
diff --git a/drivers/leds/leds-syscon.c b/drivers/leds/leds-syscon.c
new file mode 100644
index 000000000000..b6174f421ef2
--- /dev/null
+++ b/drivers/leds/leds-syscon.c
@@ -0,0 +1,165 @@
+/*
+ * Generic Syscon LEDs Driver
+ *
+ * Copyright (c) 2014, Linaro Limited
+ * Author: Linus Walleij <linus.walleij@linaro.org>
+ *
+ * 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
+ *
+ * This driver provides system reboot functionality for APM X-Gene SoC.
+ * For system shutdown, this is board specify. If a board designer
+ * implements GPIO shutdown, use the gpio-poweroff.c driver.
+ */
+#include <linux/io.h>
+#include <linux/of_device.h>
+#include <linux/of_address.h>
+#include <linux/platform_device.h>
+#include <linux/stat.h>
+#include <linux/slab.h>
+#include <linux/mfd/syscon.h>
+#include <linux/regmap.h>
+#include <linux/leds.h>
+
+/**
+ * struct syscon_led - state container for syscon based LEDs
+ * @cdev: LED class device for this LED
+ * @map: regmap to access the syscon device backing this LED
+ * @offset: the offset into the syscon regmap for the LED register
+ * @mask: the bit in the register corresponding to the LED
+ * @state: current state of the LED
+ */
+struct syscon_led {
+ struct led_classdev cdev;
+ struct regmap *map;
+ u32 offset;
+ u32 mask;
+ bool state;
+};
+
+static void syscon_led_set(struct led_classdev *led_cdev,
+ enum led_brightness value)
+{
+ struct syscon_led *sled =
+ container_of(led_cdev, struct syscon_led, cdev);
+ u32 val;
+ int ret;
+
+ if (value == LED_OFF) {
+ val = 0;
+ sled->state = false;
+ } else {
+ val = sled->mask;
+ sled->state = true;
+ }
+
+ ret = regmap_update_bits(sled->map, sled->offset, sled->mask, val);
+ if (ret < 0)
+ dev_err(sled->cdev.dev, "error updating LED status\n");
+}
+
+static const struct of_device_id syscon_match[] = {
+ { .compatible = "syscon", },
+};
+
+static int __init syscon_leds_init(void)
+{
+ const struct of_device_id *devid;
+ struct device_node *np;
+ struct device_node *child;
+ struct regmap *map;
+ struct platform_device *pdev;
+ struct device *dev;
+ int ret;
+
+ np = of_find_matching_node_and_match(NULL, syscon_match,
+ &devid);
+ if (!np)
+ return -ENODEV;
+
+ map = syscon_node_to_regmap(np);
+ if (IS_ERR(map))
+ return PTR_ERR(map);
+
+ /*
+ * If the map is there, the device should be there, we allocate
+ * memory on the syscon device's behalf here.
+ */
+ pdev = of_find_device_by_node(np);
+ if (!pdev)
+ return -ENODEV;
+ dev = &pdev->dev;
+
+ for_each_available_child_of_node(np, child) {
+ struct syscon_led *sled;
+ const char *state;
+
+ /* Only check for register-bit-leds */
+ if (of_property_match_string(child, "compatible",
+ "register-bit-led") < 0)
+ continue;
+
+ sled = devm_kzalloc(dev, sizeof(*sled), GFP_KERNEL);
+ if (!sled)
+ return -ENOMEM;
+
+ sled->map = map;
+
+ if (of_property_read_u32(child, "offset", &sled->offset))
+ return -EINVAL;
+ if (of_property_read_u32(child, "mask", &sled->mask))
+ return -EINVAL;
+ sled->cdev.name =
+ of_get_property(child, "label", NULL) ? : child->name;
+ sled->cdev.default_trigger =
+ of_get_property(child, "linux,default-trigger", NULL);
+
+ state = of_get_property(child, "default-state", NULL);
+ if (state) {
+ if (!strcmp(state, "keep")) {
+ u32 val;
+
+ ret = regmap_read(map, sled->offset, &val);
+ if (ret < 0)
+ return ret;
+ sled->state = !!(val & sled->mask);
+ } else if (!strcmp(state, "on")) {
+ sled->state = true;
+ ret = regmap_update_bits(map, sled->offset,
+ sled->mask,
+ sled->mask);
+ if (ret < 0)
+ return ret;
+ } else {
+ sled->state = false;
+ ret = regmap_update_bits(map, sled->offset,
+ sled->mask, 0);
+ if (ret < 0)
+ return ret;
+ }
+
+ }
+ sled->cdev.brightness_set = syscon_led_set;
+
+ ret = led_classdev_register(dev, &sled->cdev);
+ if (ret < 0)
+ return ret;
+
+ dev_info(dev, "registered LED %s\n", sled->cdev.name);
+ }
+
+ return 0;
+}
+device_initcall(syscon_leds_init);
--
1.9.3
^ permalink raw reply related [flat|nested] 46+ messages in thread
* [PATCH 2/7 v6] leds: add device tree bindings for register bit LEDs
2014-09-08 11:37 ` Linus Walleij
@ 2014-09-08 11:38 ` Linus Walleij
-1 siblings, 0 replies; 46+ messages in thread
From: Linus Walleij @ 2014-09-08 11:38 UTC (permalink / raw)
To: linux-arm-kernel, devicetree, linux-leds, linux-pm
Cc: Arnd Bergmann, Pawel Moll, Mark Rutland, Marc Zyngier,
Will Deacon, Rob Herring, Linus Walleij, Bryan Wu,
Richard Purdie
This adds the device tree bindings used by register bit LEDs.
Cc: devicetree@vger.kernel.org
Cc: Bryan Wu <cooloney@gmail.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v1->v2:
- Rename binding "register-bit-led"
- Define that such nodes appear only as children of syscon
- Group required and optional parameters
- Number nodes as foo@<offset>.<bit>
- Update example
---
.../devicetree/bindings/leds/register-bit-led.txt | 99 ++++++++++++++++++++++
1 file changed, 99 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/register-bit-led.txt
diff --git a/Documentation/devicetree/bindings/leds/register-bit-led.txt b/Documentation/devicetree/bindings/leds/register-bit-led.txt
new file mode 100644
index 000000000000..379cefdc0bda
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/register-bit-led.txt
@@ -0,0 +1,99 @@
+Device Tree Bindings for Register Bit LEDs
+
+Register bit leds are used with syscon multifunctional devices
+where single bits in a certain register can turn on/off a
+single LED. The register bit LEDs appear as children to the
+syscon device, with the proper compatible string. For the
+syscon bindings see:
+Documentation/devicetree/bindings/mfd/syscon.txt
+
+Each LED is represented as a sub-node of the syscon device. Each
+node's name represents the name of the corresponding LED.
+
+LED sub-node properties:
+
+Required properties:
+- compatible : must be "register-bit-led"
+- offset : register offset to the register controlling this LED
+- mask : bit mask for the bit controlling this LED in the register
+ typically 0x01, 0x02, 0x04 ...
+
+Optional properties:
+- label : (optional)
+ see Documentation/devicetree/bindings/leds/common.txt
+- linux,default-trigger : (optional)
+ see Documentation/devicetree/bindings/leds/common.txt
+- default-state: (optional) The initial state of the LED. Valid
+ values are "on", "off", and "keep". If the LED is already on or off
+ and the default-state property is set the to same value, then no
+ glitch should be produced where the LED momentarily turns off (or
+ on). The "keep" setting will keep the LED at whatever its current
+ state is, without producing a glitch. The default is off if this
+ property is not present.
+
+Example:
+
+syscon: syscon@10000000 {
+ compatible = "arm,realview-pb1176-syscon", "syscon";
+ reg = <0x10000000 0x1000>;
+
+ led@08.0 {
+ compatible = "register-bit-led";
+ offset = <0x08>;
+ mask = <0x01>;
+ label = "versatile:0";
+ linux,default-trigger = "heartbeat";
+ default-state = "on";
+ };
+ led@08.1 {
+ compatible = "register-bit-led";
+ offset = <0x08>;
+ mask = <0x02>;
+ label = "versatile:1";
+ linux,default-trigger = "mmc0";
+ default-state = "off";
+ };
+ led@08.2 {
+ compatible = "register-bit-led";
+ offset = <0x08>;
+ mask = <0x04>;
+ label = "versatile:2";
+ linux,default-trigger = "cpu0";
+ default-state = "off";
+ };
+ led@08.3 {
+ compatible = "register-bit-led";
+ offset = <0x08>;
+ mask = <0x08>;
+ label = "versatile:3";
+ default-state = "off";
+ };
+ led@08.4 {
+ compatible = "register-bit-led";
+ offset = <0x08>;
+ mask = <0x10>;
+ label = "versatile:4";
+ default-state = "off";
+ };
+ led@08.5 {
+ compatible = "register-bit-led";
+ offset = <0x08>;
+ mask = <0x20>;
+ label = "versatile:5";
+ default-state = "off";
+ };
+ led@08.6 {
+ compatible = "register-bit-led";
+ offset = <0x08>;
+ mask = <0x40>;
+ label = "versatile:6";
+ default-state = "off";
+ };
+ led@08.7 {
+ compatible = "register-bit-led";
+ offset = <0x08>;
+ mask = <0x80>;
+ label = "versatile:7";
+ default-state = "off";
+ };
+};
--
1.9.3
^ permalink raw reply related [flat|nested] 46+ messages in thread
* [PATCH 2/7 v6] leds: add device tree bindings for register bit LEDs
@ 2014-09-08 11:38 ` Linus Walleij
0 siblings, 0 replies; 46+ messages in thread
From: Linus Walleij @ 2014-09-08 11:38 UTC (permalink / raw)
To: linux-arm-kernel
This adds the device tree bindings used by register bit LEDs.
Cc: devicetree at vger.kernel.org
Cc: Bryan Wu <cooloney@gmail.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v1->v2:
- Rename binding "register-bit-led"
- Define that such nodes appear only as children of syscon
- Group required and optional parameters
- Number nodes as foo@<offset>.<bit>
- Update example
---
.../devicetree/bindings/leds/register-bit-led.txt | 99 ++++++++++++++++++++++
1 file changed, 99 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/register-bit-led.txt
diff --git a/Documentation/devicetree/bindings/leds/register-bit-led.txt b/Documentation/devicetree/bindings/leds/register-bit-led.txt
new file mode 100644
index 000000000000..379cefdc0bda
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/register-bit-led.txt
@@ -0,0 +1,99 @@
+Device Tree Bindings for Register Bit LEDs
+
+Register bit leds are used with syscon multifunctional devices
+where single bits in a certain register can turn on/off a
+single LED. The register bit LEDs appear as children to the
+syscon device, with the proper compatible string. For the
+syscon bindings see:
+Documentation/devicetree/bindings/mfd/syscon.txt
+
+Each LED is represented as a sub-node of the syscon device. Each
+node's name represents the name of the corresponding LED.
+
+LED sub-node properties:
+
+Required properties:
+- compatible : must be "register-bit-led"
+- offset : register offset to the register controlling this LED
+- mask : bit mask for the bit controlling this LED in the register
+ typically 0x01, 0x02, 0x04 ...
+
+Optional properties:
+- label : (optional)
+ see Documentation/devicetree/bindings/leds/common.txt
+- linux,default-trigger : (optional)
+ see Documentation/devicetree/bindings/leds/common.txt
+- default-state: (optional) The initial state of the LED. Valid
+ values are "on", "off", and "keep". If the LED is already on or off
+ and the default-state property is set the to same value, then no
+ glitch should be produced where the LED momentarily turns off (or
+ on). The "keep" setting will keep the LED at whatever its current
+ state is, without producing a glitch. The default is off if this
+ property is not present.
+
+Example:
+
+syscon: syscon at 10000000 {
+ compatible = "arm,realview-pb1176-syscon", "syscon";
+ reg = <0x10000000 0x1000>;
+
+ led at 08.0 {
+ compatible = "register-bit-led";
+ offset = <0x08>;
+ mask = <0x01>;
+ label = "versatile:0";
+ linux,default-trigger = "heartbeat";
+ default-state = "on";
+ };
+ led at 08.1 {
+ compatible = "register-bit-led";
+ offset = <0x08>;
+ mask = <0x02>;
+ label = "versatile:1";
+ linux,default-trigger = "mmc0";
+ default-state = "off";
+ };
+ led at 08.2 {
+ compatible = "register-bit-led";
+ offset = <0x08>;
+ mask = <0x04>;
+ label = "versatile:2";
+ linux,default-trigger = "cpu0";
+ default-state = "off";
+ };
+ led at 08.3 {
+ compatible = "register-bit-led";
+ offset = <0x08>;
+ mask = <0x08>;
+ label = "versatile:3";
+ default-state = "off";
+ };
+ led at 08.4 {
+ compatible = "register-bit-led";
+ offset = <0x08>;
+ mask = <0x10>;
+ label = "versatile:4";
+ default-state = "off";
+ };
+ led at 08.5 {
+ compatible = "register-bit-led";
+ offset = <0x08>;
+ mask = <0x20>;
+ label = "versatile:5";
+ default-state = "off";
+ };
+ led at 08.6 {
+ compatible = "register-bit-led";
+ offset = <0x08>;
+ mask = <0x40>;
+ label = "versatile:6";
+ default-state = "off";
+ };
+ led at 08.7 {
+ compatible = "register-bit-led";
+ offset = <0x08>;
+ mask = <0x80>;
+ label = "versatile:7";
+ default-state = "off";
+ };
+};
--
1.9.3
^ permalink raw reply related [flat|nested] 46+ messages in thread
* [PATCH 3/7 v6] power: reset: driver for the Versatile syscon reboot
2014-09-08 11:37 ` Linus Walleij
@ 2014-09-08 11:38 ` Linus Walleij
-1 siblings, 0 replies; 46+ messages in thread
From: Linus Walleij @ 2014-09-08 11:38 UTC (permalink / raw)
To: linux-arm-kernel, devicetree, linux-leds, linux-pm
Cc: Arnd Bergmann, Pawel Moll, Mark Rutland, Marc Zyngier,
Will Deacon, Rob Herring, Linus Walleij, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse
This driver enabled us to drive the reboot of the Versatile family
of ARM reference boards. Even though only the RealView boards are
supported initially, these boards all have the same procedure for
reboot:
- Write a magic value into an unlocking register
- Write another magic value into a reset control register
The driver will be reusable for Versatile and possibly also the
Integrator family of reference boards.
Cc: Sebastian Reichel <sre@kernel.org>
Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v1->v2:
- Do not probe from a platform device, instead use a device_initcall()
and look up the syscon device from its node. If that device is
not yet registered, the call will be deferred. This is done so that
the Linux driver model is not reflected into the device tree, as
the reboot property of the syscon is not a separate device.
---
drivers/power/reset/Kconfig | 9 +++
drivers/power/reset/Makefile | 1 +
drivers/power/reset/arm-versatile-reboot.c | 111 +++++++++++++++++++++++++++++
3 files changed, 121 insertions(+)
create mode 100644 drivers/power/reset/arm-versatile-reboot.c
diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index ca41523bbebf..2447c76e2f1a 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -75,6 +75,15 @@ config POWER_RESET_SUN6I
help
Reboot support for the Allwinner A31 SoCs.
+config POWER_RESET_VERSATILE
+ bool "ARM Versatile family reboot driver"
+ depends on ARM
+ depends on MFD_SYSCON
+ depends on OF
+ help
+ Power off and restart support for ARM Versatile family of
+ reference boards.
+
config POWER_RESET_VEXPRESS
bool "ARM Versatile Express power-off and reset driver"
depends on ARM || ARM64
diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
index a42e70edd037..41ab0e7b92b8 100644
--- a/drivers/power/reset/Makefile
+++ b/drivers/power/reset/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_POWER_RESET_MSM) += msm-poweroff.o
obj-$(CONFIG_POWER_RESET_QNAP) += qnap-poweroff.o
obj-$(CONFIG_POWER_RESET_RESTART) += restart-poweroff.o
obj-$(CONFIG_POWER_RESET_SUN6I) += sun6i-reboot.o
+obj-$(CONFIG_POWER_RESET_VERSATILE) += arm-versatile-reboot.o
obj-$(CONFIG_POWER_RESET_VEXPRESS) += vexpress-poweroff.o
obj-$(CONFIG_POWER_RESET_XGENE) += xgene-reboot.o
obj-$(CONFIG_POWER_RESET_KEYSTONE) += keystone-reset.o
diff --git a/drivers/power/reset/arm-versatile-reboot.c b/drivers/power/reset/arm-versatile-reboot.c
new file mode 100644
index 000000000000..5b08bffcf1a8
--- /dev/null
+++ b/drivers/power/reset/arm-versatile-reboot.c
@@ -0,0 +1,111 @@
+/*
+ * Copyright (C) 2014 Linaro Ltd.
+ *
+ * Author: Linus Walleij <linus.walleij@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2, as
+ * published by the Free Software Foundation.
+ *
+ */
+#include <linux/init.h>
+#include <linux/mfd/syscon.h>
+#include <linux/reboot.h>
+#include <linux/regmap.h>
+#include <linux/of.h>
+#include <asm/system_misc.h>
+
+#define REALVIEW_SYS_LOCK_OFFSET 0x20
+#define REALVIEW_SYS_LOCK_VAL 0xA05F
+#define REALVIEW_SYS_RESETCTL_OFFSET 0x40
+
+/*
+ * We detect the different syscon types from the compatible strings.
+ */
+enum versatile_reboot {
+ REALVIEW_REBOOT_EB,
+ REALVIEW_REBOOT_PB1176,
+ REALVIEW_REBOOT_PB11MP,
+ REALVIEW_REBOOT_PBA8,
+ REALVIEW_REBOOT_PBX,
+};
+
+/* Pointer to the system controller */
+static struct regmap *syscon_regmap;
+static enum versatile_reboot versatile_reboot_type;
+
+static const struct of_device_id versatile_reboot_of_match[] = {
+ {
+ .compatible = "arm,realview-eb-syscon",
+ .data = (void *)REALVIEW_REBOOT_EB,
+ },
+ {
+ .compatible = "arm,realview-pb1176-syscon",
+ .data = (void *)REALVIEW_REBOOT_PB1176,
+ },
+ {
+ .compatible = "arm,realview-pb11mp-syscon",
+ .data = (void *)REALVIEW_REBOOT_PB11MP,
+ },
+ {
+ .compatible = "arm,realview-pba8-syscon",
+ .data = (void *)REALVIEW_REBOOT_PBA8,
+ },
+ {
+ .compatible = "arm,realview-pbx-syscon",
+ .data = (void *)REALVIEW_REBOOT_PBX,
+ },
+};
+
+static void versatile_reboot(enum reboot_mode mode, const char *cmd)
+{
+ /* Unlock the reset register */
+ regmap_write(syscon_regmap, REALVIEW_SYS_LOCK_OFFSET,
+ REALVIEW_SYS_LOCK_VAL);
+ /* Then hit reset on the different machines */
+ switch (versatile_reboot_type) {
+ case REALVIEW_REBOOT_EB:
+ regmap_write(syscon_regmap,
+ REALVIEW_SYS_RESETCTL_OFFSET, 0x0008);
+ break;
+ case REALVIEW_REBOOT_PB1176:
+ regmap_write(syscon_regmap,
+ REALVIEW_SYS_RESETCTL_OFFSET, 0x0100);
+ break;
+ case REALVIEW_REBOOT_PB11MP:
+ case REALVIEW_REBOOT_PBA8:
+ regmap_write(syscon_regmap, REALVIEW_SYS_RESETCTL_OFFSET,
+ 0x0000);
+ regmap_write(syscon_regmap, REALVIEW_SYS_RESETCTL_OFFSET,
+ 0x0004);
+ break;
+ case REALVIEW_REBOOT_PBX:
+ regmap_write(syscon_regmap, REALVIEW_SYS_RESETCTL_OFFSET,
+ 0x00f0);
+ regmap_write(syscon_regmap, REALVIEW_SYS_RESETCTL_OFFSET,
+ 0x00f4);
+ break;
+ }
+ dsb();
+}
+
+static int __init versatile_reboot_probe(void)
+{
+ const struct of_device_id *reboot_id;
+ struct device_node *np;
+
+ np = of_find_matching_node_and_match(NULL, versatile_reboot_of_match,
+ &reboot_id);
+ if (!np)
+ return -ENODEV;
+ versatile_reboot_type = (enum versatile_reboot)reboot_id->data;
+
+ syscon_regmap = syscon_node_to_regmap(np);
+ if (IS_ERR(syscon_regmap))
+ return PTR_ERR(syscon_regmap);
+
+ arm_pm_restart = versatile_reboot;
+ pr_info("versatile reboot driver registered\n");
+ return 0;
+}
+device_initcall(versatile_reboot_probe);
--
1.9.3
^ permalink raw reply related [flat|nested] 46+ messages in thread
* [PATCH 3/7 v6] power: reset: driver for the Versatile syscon reboot
@ 2014-09-08 11:38 ` Linus Walleij
0 siblings, 0 replies; 46+ messages in thread
From: Linus Walleij @ 2014-09-08 11:38 UTC (permalink / raw)
To: linux-arm-kernel
This driver enabled us to drive the reboot of the Versatile family
of ARM reference boards. Even though only the RealView boards are
supported initially, these boards all have the same procedure for
reboot:
- Write a magic value into an unlocking register
- Write another magic value into a reset control register
The driver will be reusable for Versatile and possibly also the
Integrator family of reference boards.
Cc: Sebastian Reichel <sre@kernel.org>
Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v1->v2:
- Do not probe from a platform device, instead use a device_initcall()
and look up the syscon device from its node. If that device is
not yet registered, the call will be deferred. This is done so that
the Linux driver model is not reflected into the device tree, as
the reboot property of the syscon is not a separate device.
---
drivers/power/reset/Kconfig | 9 +++
drivers/power/reset/Makefile | 1 +
drivers/power/reset/arm-versatile-reboot.c | 111 +++++++++++++++++++++++++++++
3 files changed, 121 insertions(+)
create mode 100644 drivers/power/reset/arm-versatile-reboot.c
diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index ca41523bbebf..2447c76e2f1a 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -75,6 +75,15 @@ config POWER_RESET_SUN6I
help
Reboot support for the Allwinner A31 SoCs.
+config POWER_RESET_VERSATILE
+ bool "ARM Versatile family reboot driver"
+ depends on ARM
+ depends on MFD_SYSCON
+ depends on OF
+ help
+ Power off and restart support for ARM Versatile family of
+ reference boards.
+
config POWER_RESET_VEXPRESS
bool "ARM Versatile Express power-off and reset driver"
depends on ARM || ARM64
diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
index a42e70edd037..41ab0e7b92b8 100644
--- a/drivers/power/reset/Makefile
+++ b/drivers/power/reset/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_POWER_RESET_MSM) += msm-poweroff.o
obj-$(CONFIG_POWER_RESET_QNAP) += qnap-poweroff.o
obj-$(CONFIG_POWER_RESET_RESTART) += restart-poweroff.o
obj-$(CONFIG_POWER_RESET_SUN6I) += sun6i-reboot.o
+obj-$(CONFIG_POWER_RESET_VERSATILE) += arm-versatile-reboot.o
obj-$(CONFIG_POWER_RESET_VEXPRESS) += vexpress-poweroff.o
obj-$(CONFIG_POWER_RESET_XGENE) += xgene-reboot.o
obj-$(CONFIG_POWER_RESET_KEYSTONE) += keystone-reset.o
diff --git a/drivers/power/reset/arm-versatile-reboot.c b/drivers/power/reset/arm-versatile-reboot.c
new file mode 100644
index 000000000000..5b08bffcf1a8
--- /dev/null
+++ b/drivers/power/reset/arm-versatile-reboot.c
@@ -0,0 +1,111 @@
+/*
+ * Copyright (C) 2014 Linaro Ltd.
+ *
+ * Author: Linus Walleij <linus.walleij@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2, as
+ * published by the Free Software Foundation.
+ *
+ */
+#include <linux/init.h>
+#include <linux/mfd/syscon.h>
+#include <linux/reboot.h>
+#include <linux/regmap.h>
+#include <linux/of.h>
+#include <asm/system_misc.h>
+
+#define REALVIEW_SYS_LOCK_OFFSET 0x20
+#define REALVIEW_SYS_LOCK_VAL 0xA05F
+#define REALVIEW_SYS_RESETCTL_OFFSET 0x40
+
+/*
+ * We detect the different syscon types from the compatible strings.
+ */
+enum versatile_reboot {
+ REALVIEW_REBOOT_EB,
+ REALVIEW_REBOOT_PB1176,
+ REALVIEW_REBOOT_PB11MP,
+ REALVIEW_REBOOT_PBA8,
+ REALVIEW_REBOOT_PBX,
+};
+
+/* Pointer to the system controller */
+static struct regmap *syscon_regmap;
+static enum versatile_reboot versatile_reboot_type;
+
+static const struct of_device_id versatile_reboot_of_match[] = {
+ {
+ .compatible = "arm,realview-eb-syscon",
+ .data = (void *)REALVIEW_REBOOT_EB,
+ },
+ {
+ .compatible = "arm,realview-pb1176-syscon",
+ .data = (void *)REALVIEW_REBOOT_PB1176,
+ },
+ {
+ .compatible = "arm,realview-pb11mp-syscon",
+ .data = (void *)REALVIEW_REBOOT_PB11MP,
+ },
+ {
+ .compatible = "arm,realview-pba8-syscon",
+ .data = (void *)REALVIEW_REBOOT_PBA8,
+ },
+ {
+ .compatible = "arm,realview-pbx-syscon",
+ .data = (void *)REALVIEW_REBOOT_PBX,
+ },
+};
+
+static void versatile_reboot(enum reboot_mode mode, const char *cmd)
+{
+ /* Unlock the reset register */
+ regmap_write(syscon_regmap, REALVIEW_SYS_LOCK_OFFSET,
+ REALVIEW_SYS_LOCK_VAL);
+ /* Then hit reset on the different machines */
+ switch (versatile_reboot_type) {
+ case REALVIEW_REBOOT_EB:
+ regmap_write(syscon_regmap,
+ REALVIEW_SYS_RESETCTL_OFFSET, 0x0008);
+ break;
+ case REALVIEW_REBOOT_PB1176:
+ regmap_write(syscon_regmap,
+ REALVIEW_SYS_RESETCTL_OFFSET, 0x0100);
+ break;
+ case REALVIEW_REBOOT_PB11MP:
+ case REALVIEW_REBOOT_PBA8:
+ regmap_write(syscon_regmap, REALVIEW_SYS_RESETCTL_OFFSET,
+ 0x0000);
+ regmap_write(syscon_regmap, REALVIEW_SYS_RESETCTL_OFFSET,
+ 0x0004);
+ break;
+ case REALVIEW_REBOOT_PBX:
+ regmap_write(syscon_regmap, REALVIEW_SYS_RESETCTL_OFFSET,
+ 0x00f0);
+ regmap_write(syscon_regmap, REALVIEW_SYS_RESETCTL_OFFSET,
+ 0x00f4);
+ break;
+ }
+ dsb();
+}
+
+static int __init versatile_reboot_probe(void)
+{
+ const struct of_device_id *reboot_id;
+ struct device_node *np;
+
+ np = of_find_matching_node_and_match(NULL, versatile_reboot_of_match,
+ &reboot_id);
+ if (!np)
+ return -ENODEV;
+ versatile_reboot_type = (enum versatile_reboot)reboot_id->data;
+
+ syscon_regmap = syscon_node_to_regmap(np);
+ if (IS_ERR(syscon_regmap))
+ return PTR_ERR(syscon_regmap);
+
+ arm_pm_restart = versatile_reboot;
+ pr_info("versatile reboot driver registered\n");
+ return 0;
+}
+device_initcall(versatile_reboot_probe);
--
1.9.3
^ permalink raw reply related [flat|nested] 46+ messages in thread
* [PATCH 4/7 v6] soc: add driver for the ARM RealView
2014-09-08 11:37 ` Linus Walleij
@ 2014-09-08 11:38 ` Linus Walleij
-1 siblings, 0 replies; 46+ messages in thread
From: Linus Walleij @ 2014-09-08 11:38 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-leds-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA
Cc: Arnd Bergmann, Pawel Moll, Mark Rutland, Marc Zyngier,
Will Deacon, Rob Herring, Linus Walleij
This adds a SoC driver to be used by the ARM RealView
reference boards. We create the "versatile" directory to hold
the different ARM reference designs as per the pattern of the
clk directory layout. The driver utilze the syscon to get to
the register needed. After this we can use sysfs to get at
some SoC properties on RealView DT variants like this:
> cd /sysbus/soc/devices/soc0
> ls
board family machine power subsystem
build fpga manufacturer soc_id uevent
> cat family
Versatile
> cat fpga
Multi-layer AXI
> cat board
HBI-0147
> cat build
03
Signed-off-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
drivers/soc/Kconfig | 1 +
drivers/soc/Makefile | 1 +
drivers/soc/versatile/Kconfig | 10 +++
drivers/soc/versatile/Makefile | 1 +
drivers/soc/versatile/soc-realview.c | 144 +++++++++++++++++++++++++++++++++++
5 files changed, 157 insertions(+)
create mode 100644 drivers/soc/versatile/Kconfig
create mode 100644 drivers/soc/versatile/Makefile
create mode 100644 drivers/soc/versatile/soc-realview.c
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index c8543855aa82..6ed3590253cf 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -1,5 +1,6 @@
menu "SOC (System On Chip) specific Drivers"
source "drivers/soc/qcom/Kconfig"
+source "drivers/soc/versatile/Kconfig"
endmenu
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index 3b1b95d932d1..d20d8f625732 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -4,3 +4,4 @@
obj-$(CONFIG_ARCH_QCOM) += qcom/
obj-$(CONFIG_ARCH_TEGRA) += tegra/
+obj-$(CONFIG_PLAT_VERSATILE) += versatile/
diff --git a/drivers/soc/versatile/Kconfig b/drivers/soc/versatile/Kconfig
new file mode 100644
index 000000000000..bf5ee9c85330
--- /dev/null
+++ b/drivers/soc/versatile/Kconfig
@@ -0,0 +1,10 @@
+#
+# ARM Versatile SoC drivers
+#
+config SOC_REALVIEW
+ bool "SoC bus device for the ARM RealView platforms"
+ depends on ARCH_REALVIEW
+ select SOC_BUS
+ help
+ Include support for the SoC bus on the ARM RealView platforms
+ providing some sysfs information about the ASIC variant.
diff --git a/drivers/soc/versatile/Makefile b/drivers/soc/versatile/Makefile
new file mode 100644
index 000000000000..ad547435648e
--- /dev/null
+++ b/drivers/soc/versatile/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_SOC_REALVIEW) += soc-realview.o
diff --git a/drivers/soc/versatile/soc-realview.c b/drivers/soc/versatile/soc-realview.c
new file mode 100644
index 000000000000..cea8ea3491d2
--- /dev/null
+++ b/drivers/soc/versatile/soc-realview.c
@@ -0,0 +1,144 @@
+/*
+ * Copyright (C) 2014 Linaro Ltd.
+ *
+ * Author: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2, as
+ * published by the Free Software Foundation.
+ *
+ */
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/slab.h>
+#include <linux/sys_soc.h>
+#include <linux/platform_device.h>
+#include <linux/mfd/syscon.h>
+#include <linux/regmap.h>
+#include <linux/of.h>
+
+/* System ID in syscon */
+#define REALVIEW_SYS_ID_OFFSET 0x00
+
+static const struct of_device_id realview_soc_of_match[] = {
+ { .compatible = "arm,realview-eb-soc", },
+ { .compatible = "arm,realview-pb1176-soc", },
+ { .compatible = "arm,realview-pb11mp-soc", },
+ { .compatible = "arm,realview-pba8-soc", },
+ { .compatible = "arm,realview-pbx-soc", },
+};
+
+static u32 realview_coreid;
+
+static const char *realview_board_str(u32 id)
+{
+ switch ((id >> 16) & 0xfff) {
+ case 0x0147:
+ return "HBI-0147";
+ default:
+ return "Unknown";
+ }
+}
+
+static const char *realview_arch_str(u32 id)
+{
+ switch ((id >> 8) & 0xf) {
+ case 0x05:
+ return "Multi-layer AXI";
+ default:
+ return "Unknown";
+ }
+}
+
+static ssize_t realview_get_manf(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ return sprintf(buf, "%02x\n", realview_coreid >> 24);
+}
+
+static struct device_attribute realview_manf_attr =
+ __ATTR(manufacturer, S_IRUGO, realview_get_manf, NULL);
+
+static ssize_t realview_get_board(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ return sprintf(buf, "%s\n", realview_board_str(realview_coreid));
+}
+
+static struct device_attribute realview_board_attr =
+ __ATTR(board, S_IRUGO, realview_get_board, NULL);
+
+static ssize_t realview_get_arch(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ return sprintf(buf, "%s\n", realview_arch_str(realview_coreid));
+}
+
+static struct device_attribute realview_arch_attr =
+ __ATTR(fpga, S_IRUGO, realview_get_arch, NULL);
+
+static ssize_t realview_get_build(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ return sprintf(buf, "%02x\n", (realview_coreid & 0xFF));
+}
+
+static struct device_attribute realview_build_attr =
+ __ATTR(build, S_IRUGO, realview_get_build, NULL);
+
+static int realview_soc_probe(struct platform_device *pdev)
+{
+ static struct regmap *syscon_regmap;
+ struct soc_device *soc_dev;
+ struct soc_device_attribute *soc_dev_attr;
+ struct device_node *np = pdev->dev.of_node;
+ int ret;
+
+ syscon_regmap = syscon_regmap_lookup_by_phandle(np, "regmap");
+ if (IS_ERR(syscon_regmap))
+ return PTR_ERR(syscon_regmap);
+
+ soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL);
+ if (!soc_dev_attr)
+ return -ENOMEM;
+
+ ret = of_property_read_string(np, "compatible",
+ &soc_dev_attr->soc_id);
+ if (ret)
+ return -EINVAL;
+
+ soc_dev_attr->machine = "RealView";
+ soc_dev_attr->family = "Versatile";
+ soc_dev = soc_device_register(soc_dev_attr);
+ if (IS_ERR(soc_dev)) {
+ kfree(soc_dev_attr);
+ return -ENODEV;
+ }
+ ret = regmap_read(syscon_regmap, REALVIEW_SYS_ID_OFFSET,
+ &realview_coreid);
+ if (ret)
+ return -ENODEV;
+
+ device_create_file(soc_device_to_device(soc_dev), &realview_manf_attr);
+ device_create_file(soc_device_to_device(soc_dev), &realview_board_attr);
+ device_create_file(soc_device_to_device(soc_dev), &realview_arch_attr);
+ device_create_file(soc_device_to_device(soc_dev), &realview_build_attr);
+
+ dev_info(&pdev->dev, "RealView Syscon Core ID: 0x%08x\n",
+ realview_coreid);
+ /* FIXME: add attributes for SoC to sysfs */
+ return 0;
+}
+
+static struct platform_driver realview_soc_driver = {
+ .probe = realview_soc_probe,
+ .driver = {
+ .name = "realview-soc",
+ .of_match_table = realview_soc_of_match,
+ },
+};
+module_platform_driver(realview_soc_driver);
--
1.9.3
--
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] 46+ messages in thread
* [PATCH 4/7 v6] soc: add driver for the ARM RealView
@ 2014-09-08 11:38 ` Linus Walleij
0 siblings, 0 replies; 46+ messages in thread
From: Linus Walleij @ 2014-09-08 11:38 UTC (permalink / raw)
To: linux-arm-kernel
This adds a SoC driver to be used by the ARM RealView
reference boards. We create the "versatile" directory to hold
the different ARM reference designs as per the pattern of the
clk directory layout. The driver utilze the syscon to get to
the register needed. After this we can use sysfs to get at
some SoC properties on RealView DT variants like this:
> cd /sysbus/soc/devices/soc0
> ls
board family machine power subsystem
build fpga manufacturer soc_id uevent
> cat family
Versatile
> cat fpga
Multi-layer AXI
> cat board
HBI-0147
> cat build
03
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/soc/Kconfig | 1 +
drivers/soc/Makefile | 1 +
drivers/soc/versatile/Kconfig | 10 +++
drivers/soc/versatile/Makefile | 1 +
drivers/soc/versatile/soc-realview.c | 144 +++++++++++++++++++++++++++++++++++
5 files changed, 157 insertions(+)
create mode 100644 drivers/soc/versatile/Kconfig
create mode 100644 drivers/soc/versatile/Makefile
create mode 100644 drivers/soc/versatile/soc-realview.c
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index c8543855aa82..6ed3590253cf 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -1,5 +1,6 @@
menu "SOC (System On Chip) specific Drivers"
source "drivers/soc/qcom/Kconfig"
+source "drivers/soc/versatile/Kconfig"
endmenu
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index 3b1b95d932d1..d20d8f625732 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -4,3 +4,4 @@
obj-$(CONFIG_ARCH_QCOM) += qcom/
obj-$(CONFIG_ARCH_TEGRA) += tegra/
+obj-$(CONFIG_PLAT_VERSATILE) += versatile/
diff --git a/drivers/soc/versatile/Kconfig b/drivers/soc/versatile/Kconfig
new file mode 100644
index 000000000000..bf5ee9c85330
--- /dev/null
+++ b/drivers/soc/versatile/Kconfig
@@ -0,0 +1,10 @@
+#
+# ARM Versatile SoC drivers
+#
+config SOC_REALVIEW
+ bool "SoC bus device for the ARM RealView platforms"
+ depends on ARCH_REALVIEW
+ select SOC_BUS
+ help
+ Include support for the SoC bus on the ARM RealView platforms
+ providing some sysfs information about the ASIC variant.
diff --git a/drivers/soc/versatile/Makefile b/drivers/soc/versatile/Makefile
new file mode 100644
index 000000000000..ad547435648e
--- /dev/null
+++ b/drivers/soc/versatile/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_SOC_REALVIEW) += soc-realview.o
diff --git a/drivers/soc/versatile/soc-realview.c b/drivers/soc/versatile/soc-realview.c
new file mode 100644
index 000000000000..cea8ea3491d2
--- /dev/null
+++ b/drivers/soc/versatile/soc-realview.c
@@ -0,0 +1,144 @@
+/*
+ * Copyright (C) 2014 Linaro Ltd.
+ *
+ * Author: Linus Walleij <linus.walleij@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2, as
+ * published by the Free Software Foundation.
+ *
+ */
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/slab.h>
+#include <linux/sys_soc.h>
+#include <linux/platform_device.h>
+#include <linux/mfd/syscon.h>
+#include <linux/regmap.h>
+#include <linux/of.h>
+
+/* System ID in syscon */
+#define REALVIEW_SYS_ID_OFFSET 0x00
+
+static const struct of_device_id realview_soc_of_match[] = {
+ { .compatible = "arm,realview-eb-soc", },
+ { .compatible = "arm,realview-pb1176-soc", },
+ { .compatible = "arm,realview-pb11mp-soc", },
+ { .compatible = "arm,realview-pba8-soc", },
+ { .compatible = "arm,realview-pbx-soc", },
+};
+
+static u32 realview_coreid;
+
+static const char *realview_board_str(u32 id)
+{
+ switch ((id >> 16) & 0xfff) {
+ case 0x0147:
+ return "HBI-0147";
+ default:
+ return "Unknown";
+ }
+}
+
+static const char *realview_arch_str(u32 id)
+{
+ switch ((id >> 8) & 0xf) {
+ case 0x05:
+ return "Multi-layer AXI";
+ default:
+ return "Unknown";
+ }
+}
+
+static ssize_t realview_get_manf(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ return sprintf(buf, "%02x\n", realview_coreid >> 24);
+}
+
+static struct device_attribute realview_manf_attr =
+ __ATTR(manufacturer, S_IRUGO, realview_get_manf, NULL);
+
+static ssize_t realview_get_board(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ return sprintf(buf, "%s\n", realview_board_str(realview_coreid));
+}
+
+static struct device_attribute realview_board_attr =
+ __ATTR(board, S_IRUGO, realview_get_board, NULL);
+
+static ssize_t realview_get_arch(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ return sprintf(buf, "%s\n", realview_arch_str(realview_coreid));
+}
+
+static struct device_attribute realview_arch_attr =
+ __ATTR(fpga, S_IRUGO, realview_get_arch, NULL);
+
+static ssize_t realview_get_build(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ return sprintf(buf, "%02x\n", (realview_coreid & 0xFF));
+}
+
+static struct device_attribute realview_build_attr =
+ __ATTR(build, S_IRUGO, realview_get_build, NULL);
+
+static int realview_soc_probe(struct platform_device *pdev)
+{
+ static struct regmap *syscon_regmap;
+ struct soc_device *soc_dev;
+ struct soc_device_attribute *soc_dev_attr;
+ struct device_node *np = pdev->dev.of_node;
+ int ret;
+
+ syscon_regmap = syscon_regmap_lookup_by_phandle(np, "regmap");
+ if (IS_ERR(syscon_regmap))
+ return PTR_ERR(syscon_regmap);
+
+ soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL);
+ if (!soc_dev_attr)
+ return -ENOMEM;
+
+ ret = of_property_read_string(np, "compatible",
+ &soc_dev_attr->soc_id);
+ if (ret)
+ return -EINVAL;
+
+ soc_dev_attr->machine = "RealView";
+ soc_dev_attr->family = "Versatile";
+ soc_dev = soc_device_register(soc_dev_attr);
+ if (IS_ERR(soc_dev)) {
+ kfree(soc_dev_attr);
+ return -ENODEV;
+ }
+ ret = regmap_read(syscon_regmap, REALVIEW_SYS_ID_OFFSET,
+ &realview_coreid);
+ if (ret)
+ return -ENODEV;
+
+ device_create_file(soc_device_to_device(soc_dev), &realview_manf_attr);
+ device_create_file(soc_device_to_device(soc_dev), &realview_board_attr);
+ device_create_file(soc_device_to_device(soc_dev), &realview_arch_attr);
+ device_create_file(soc_device_to_device(soc_dev), &realview_build_attr);
+
+ dev_info(&pdev->dev, "RealView Syscon Core ID: 0x%08x\n",
+ realview_coreid);
+ /* FIXME: add attributes for SoC to sysfs */
+ return 0;
+}
+
+static struct platform_driver realview_soc_driver = {
+ .probe = realview_soc_probe,
+ .driver = {
+ .name = "realview-soc",
+ .of_match_table = realview_soc_of_match,
+ },
+};
+module_platform_driver(realview_soc_driver);
--
1.9.3
^ permalink raw reply related [flat|nested] 46+ messages in thread
* [PATCH 5/7 v6] ARM: l2c: parse 'cache-size' and 'cache-sets' properties
2014-09-08 11:37 ` Linus Walleij
@ 2014-09-08 11:38 ` Linus Walleij
-1 siblings, 0 replies; 46+ messages in thread
From: Linus Walleij @ 2014-09-08 11:38 UTC (permalink / raw)
To: linux-arm-kernel, devicetree, linux-leds, linux-pm
Cc: Arnd Bergmann, Pawel Moll, Mark Rutland, Marc Zyngier,
Will Deacon, Rob Herring, Florian Fainelli, Linus Walleij
From: Florian Fainelli <f.fainelli@gmail.com>
When both 'cache-size' and 'cache-sets' are specified for a L2 cache
controller node, parse those properties and set up the
way_size based on which type of L2 cache controller we are using.
Update the L2 cache controller Device Tree binding with the optional
'cache-size' and 'cache-sets' properties. These both come from the
ePAPR specification.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
Documentation/devicetree/bindings/arm/l2cc.txt | 2 +
arch/arm/mm/cache-l2x0.c | 61 ++++++++++++++++++++++++++
2 files changed, 63 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/l2cc.txt b/Documentation/devicetree/bindings/arm/l2cc.txt
index af527ee111c2..d33ed2344c7e 100644
--- a/Documentation/devicetree/bindings/arm/l2cc.txt
+++ b/Documentation/devicetree/bindings/arm/l2cc.txt
@@ -44,6 +44,8 @@ Optional properties:
I/O coherent mode. Valid only when the arm,pl310-cache compatible
string is used.
- interrupts : 1 combined interrupt.
+- cache-size : specifies the size in bytes of the cache
+- cache-sets : specifies the number of associativity sets of the cache
- cache-id-part: cache id part number to be used if it is not present
on hardware
- wt-override: If present then L2 is forced to Write through mode
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 5f2c988a06ac..61a684c743c6 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -945,6 +945,61 @@ static int l2_wt_override;
* pass it though the device tree */
static u32 cache_id_part_number_from_dt;
+static void __init l2x0_cache_size_of_parse(const struct device_node *np,
+ u32 *aux_val, u32 *aux_mask,
+ u32 max_way_size)
+{
+ u32 mask = 0, val = 0;
+ u32 size = 0, sets = 0;
+ u32 way_size = 0, way_size_bits = 1;
+
+ of_property_read_u32(np, "cache-size", &size);
+ of_property_read_u32(np, "cache-sets", &sets);
+
+ if (!size || !sets)
+ return;
+
+ way_size = size / sets;
+
+ if (way_size > max_way_size) {
+ pr_warn("L2C: way size %dKB is too large\n", way_size >> 10);
+ return;
+ }
+
+ way_size >>= 10;
+ switch (way_size) {
+ case 512:
+ way_size_bits = 6;
+ break;
+ case 256:
+ way_size_bits = 5;
+ break;
+ case 128:
+ way_size_bits = 4;
+ break;
+ case 64:
+ way_size_bits = 3;
+ break;
+ case 32:
+ way_size_bits = 2;
+ break;
+ case 16:
+ way_size_bits = 1;
+ break;
+ default:
+ pr_err("cache way size: %d KB is not mapped\n",
+ way_size);
+ break;
+ }
+
+ mask |= L2C_AUX_CTRL_WAY_SIZE_MASK;
+ val |= (way_size_bits << L2C_AUX_CTRL_WAY_SIZE_SHIFT);
+
+ *aux_val &= ~mask;
+ *aux_val |= val;
+ *aux_mask &= ~mask;
+}
+
static void __init l2x0_of_parse(const struct device_node *np,
u32 *aux_val, u32 *aux_mask)
{
@@ -974,6 +1029,8 @@ static void __init l2x0_of_parse(const struct device_node *np,
val |= (dirty - 1) << L2X0_AUX_CTRL_DIRTY_LATENCY_SHIFT;
}
+ l2x0_cache_size_of_parse(np, aux_val, aux_mask, SZ_256K);
+
*aux_val &= ~mask;
*aux_val |= val;
*aux_mask &= ~mask;
@@ -1047,6 +1104,8 @@ static void __init l2c310_of_parse(const struct device_node *np,
writel_relaxed((filter[0] & ~(SZ_1M - 1)) | L310_ADDR_FILTER_EN,
l2x0_base + L310_ADDR_FILTER_START);
}
+
+ l2x0_cache_size_of_parse(np, aux_val, aux_mask, SZ_512K);
}
static const struct l2c_init_data of_l2c310_data __initconst = {
@@ -1253,6 +1312,8 @@ static void __init aurora_of_parse(const struct device_node *np,
*aux_val &= ~mask;
*aux_val |= val;
*aux_mask &= ~mask;
+
+ l2x0_cache_size_of_parse(np, aux_val, aux_mask, SZ_256K);
}
static const struct l2c_init_data of_aurora_with_outer_data __initconst = {
--
1.9.3
^ permalink raw reply related [flat|nested] 46+ messages in thread
* [PATCH 5/7 v6] ARM: l2c: parse 'cache-size' and 'cache-sets' properties
@ 2014-09-08 11:38 ` Linus Walleij
0 siblings, 0 replies; 46+ messages in thread
From: Linus Walleij @ 2014-09-08 11:38 UTC (permalink / raw)
To: linux-arm-kernel
From: Florian Fainelli <f.fainelli@gmail.com>
When both 'cache-size' and 'cache-sets' are specified for a L2 cache
controller node, parse those properties and set up the
way_size based on which type of L2 cache controller we are using.
Update the L2 cache controller Device Tree binding with the optional
'cache-size' and 'cache-sets' properties. These both come from the
ePAPR specification.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
Documentation/devicetree/bindings/arm/l2cc.txt | 2 +
arch/arm/mm/cache-l2x0.c | 61 ++++++++++++++++++++++++++
2 files changed, 63 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/l2cc.txt b/Documentation/devicetree/bindings/arm/l2cc.txt
index af527ee111c2..d33ed2344c7e 100644
--- a/Documentation/devicetree/bindings/arm/l2cc.txt
+++ b/Documentation/devicetree/bindings/arm/l2cc.txt
@@ -44,6 +44,8 @@ Optional properties:
I/O coherent mode. Valid only when the arm,pl310-cache compatible
string is used.
- interrupts : 1 combined interrupt.
+- cache-size : specifies the size in bytes of the cache
+- cache-sets : specifies the number of associativity sets of the cache
- cache-id-part: cache id part number to be used if it is not present
on hardware
- wt-override: If present then L2 is forced to Write through mode
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 5f2c988a06ac..61a684c743c6 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -945,6 +945,61 @@ static int l2_wt_override;
* pass it though the device tree */
static u32 cache_id_part_number_from_dt;
+static void __init l2x0_cache_size_of_parse(const struct device_node *np,
+ u32 *aux_val, u32 *aux_mask,
+ u32 max_way_size)
+{
+ u32 mask = 0, val = 0;
+ u32 size = 0, sets = 0;
+ u32 way_size = 0, way_size_bits = 1;
+
+ of_property_read_u32(np, "cache-size", &size);
+ of_property_read_u32(np, "cache-sets", &sets);
+
+ if (!size || !sets)
+ return;
+
+ way_size = size / sets;
+
+ if (way_size > max_way_size) {
+ pr_warn("L2C: way size %dKB is too large\n", way_size >> 10);
+ return;
+ }
+
+ way_size >>= 10;
+ switch (way_size) {
+ case 512:
+ way_size_bits = 6;
+ break;
+ case 256:
+ way_size_bits = 5;
+ break;
+ case 128:
+ way_size_bits = 4;
+ break;
+ case 64:
+ way_size_bits = 3;
+ break;
+ case 32:
+ way_size_bits = 2;
+ break;
+ case 16:
+ way_size_bits = 1;
+ break;
+ default:
+ pr_err("cache way size: %d KB is not mapped\n",
+ way_size);
+ break;
+ }
+
+ mask |= L2C_AUX_CTRL_WAY_SIZE_MASK;
+ val |= (way_size_bits << L2C_AUX_CTRL_WAY_SIZE_SHIFT);
+
+ *aux_val &= ~mask;
+ *aux_val |= val;
+ *aux_mask &= ~mask;
+}
+
static void __init l2x0_of_parse(const struct device_node *np,
u32 *aux_val, u32 *aux_mask)
{
@@ -974,6 +1029,8 @@ static void __init l2x0_of_parse(const struct device_node *np,
val |= (dirty - 1) << L2X0_AUX_CTRL_DIRTY_LATENCY_SHIFT;
}
+ l2x0_cache_size_of_parse(np, aux_val, aux_mask, SZ_256K);
+
*aux_val &= ~mask;
*aux_val |= val;
*aux_mask &= ~mask;
@@ -1047,6 +1104,8 @@ static void __init l2c310_of_parse(const struct device_node *np,
writel_relaxed((filter[0] & ~(SZ_1M - 1)) | L310_ADDR_FILTER_EN,
l2x0_base + L310_ADDR_FILTER_START);
}
+
+ l2x0_cache_size_of_parse(np, aux_val, aux_mask, SZ_512K);
}
static const struct l2c_init_data of_l2c310_data __initconst = {
@@ -1253,6 +1312,8 @@ static void __init aurora_of_parse(const struct device_node *np,
*aux_val &= ~mask;
*aux_val |= val;
*aux_mask &= ~mask;
+
+ l2x0_cache_size_of_parse(np, aux_val, aux_mask, SZ_256K);
}
static const struct l2c_init_data of_aurora_with_outer_data __initconst = {
--
1.9.3
^ permalink raw reply related [flat|nested] 46+ messages in thread
* [PATCH 6/7 v6] ARM: l2x0: calculate associativity from ePAPR cache props
2014-09-08 11:37 ` Linus Walleij
@ 2014-09-08 11:38 ` Linus Walleij
-1 siblings, 0 replies; 46+ messages in thread
From: Linus Walleij @ 2014-09-08 11:38 UTC (permalink / raw)
To: linux-arm-kernel, devicetree, linux-leds, linux-pm
Cc: Arnd Bergmann, Pawel Moll, Mark Rutland, Marc Zyngier,
Will Deacon, Rob Herring, Linus Walleij
Using the cache size, number of sets and cache line size we can
calculate desired associativity of the L2 cache. This is done
by the calculation:
associativity = (cache size / cache sets) / cache line size
For most normal cache sizes this will quickly roof out to the
maximum associativity of 8 (L2x0 variants) or 16 (PL3x0 variants).
While all variants have a hard-coded line size of 32 bytes we also
support reading the "cache-line-size" ePAPR binding and complain
if it does not match the hardware.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
arch/arm/mm/cache-l2x0.c | 62 +++++++++++++++++++++++++++++++++++++++++++-----
1 file changed, 56 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 61a684c743c6..f275cd4e5151 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -947,14 +947,18 @@ static u32 cache_id_part_number_from_dt;
static void __init l2x0_cache_size_of_parse(const struct device_node *np,
u32 *aux_val, u32 *aux_mask,
- u32 max_way_size)
+ u32 max_way_size,
+ u32 max_associativity)
{
u32 mask = 0, val = 0;
u32 size = 0, sets = 0;
u32 way_size = 0, way_size_bits = 1;
+ u32 linesize = 0;
+ u32 assoc = 0;
of_property_read_u32(np, "cache-size", &size);
of_property_read_u32(np, "cache-sets", &sets);
+ of_property_read_u32(np, "cache-line-size", &linesize);
if (!size || !sets)
return;
@@ -962,10 +966,56 @@ static void __init l2x0_cache_size_of_parse(const struct device_node *np,
way_size = size / sets;
if (way_size > max_way_size) {
- pr_warn("L2C: way size %dKB is too large\n", way_size >> 10);
+ pr_warn("L2C OF: way size %dKB is too large\n", way_size >> 10);
return;
}
+ /* All these l2 caches have the same line size actually */
+ if (!linesize)
+ linesize = CACHE_LINE_SIZE;
+ if (linesize != CACHE_LINE_SIZE)
+ pr_warn("L2C OF: DT supplied line size %d bytes does "
+ "not match hardware line size of %d bytes\n",
+ linesize,
+ CACHE_LINE_SIZE);
+
+ /*
+ * This cache is set associative. By increasing associativity
+ * we increase the number of blocks per set. Usually this
+ * quickly hits the roof at 8 or 16 ways of associativity.
+ */
+ assoc = way_size / linesize;
+ if (assoc > max_associativity)
+ assoc = max_associativity;
+
+ mask |= L2X0_AUX_CTRL_ASSOC_MASK;
+
+ /*
+ * Special checks for the PL310 that only has two settings and
+ * cannot be set to fully associative.
+ */
+ if (max_associativity == 16) {
+ if (assoc <= 8) {
+ assoc = 8;
+ /* Leave bit 16 in associativity set to 0 */
+ }
+ if (assoc > 8 && assoc <= 16) {
+ assoc = 16;
+ val |= L310_AUX_CTRL_ASSOCIATIVITY_16;
+ }
+ } else {
+ if (sets == 1)
+ /* Direct-mapped cache */
+ assoc = 1;
+ val |= (assoc << L2X0_AUX_CTRL_ASSOC_SHIFT);
+ }
+
+ pr_info("L2C OF: size: %d bytes (%dKB)\n", size, size >> 10);
+ pr_info("L2C OF: way_size: %d bytes (%d KB)\n",
+ way_size, way_size >> 10);
+ pr_info("L2C OF: associativity: %d ways\n", assoc);
+
+ /* Convert to KB */
way_size >>= 10;
switch (way_size) {
case 512:
@@ -987,7 +1037,7 @@ static void __init l2x0_cache_size_of_parse(const struct device_node *np,
way_size_bits = 1;
break;
default:
- pr_err("cache way size: %d KB is not mapped\n",
+ pr_err("L2C OF: cache way size: %d KB is not mapped\n",
way_size);
break;
}
@@ -1029,7 +1079,7 @@ static void __init l2x0_of_parse(const struct device_node *np,
val |= (dirty - 1) << L2X0_AUX_CTRL_DIRTY_LATENCY_SHIFT;
}
- l2x0_cache_size_of_parse(np, aux_val, aux_mask, SZ_256K);
+ l2x0_cache_size_of_parse(np, aux_val, aux_mask, SZ_256K, 8);
*aux_val &= ~mask;
*aux_val |= val;
@@ -1105,7 +1155,7 @@ static void __init l2c310_of_parse(const struct device_node *np,
l2x0_base + L310_ADDR_FILTER_START);
}
- l2x0_cache_size_of_parse(np, aux_val, aux_mask, SZ_512K);
+ l2x0_cache_size_of_parse(np, aux_val, aux_mask, SZ_512K, 16);
}
static const struct l2c_init_data of_l2c310_data __initconst = {
@@ -1313,7 +1363,7 @@ static void __init aurora_of_parse(const struct device_node *np,
*aux_val |= val;
*aux_mask &= ~mask;
- l2x0_cache_size_of_parse(np, aux_val, aux_mask, SZ_256K);
+ l2x0_cache_size_of_parse(np, aux_val, aux_mask, SZ_256K, 8);
}
static const struct l2c_init_data of_aurora_with_outer_data __initconst = {
--
1.9.3
^ permalink raw reply related [flat|nested] 46+ messages in thread
* [PATCH 6/7 v6] ARM: l2x0: calculate associativity from ePAPR cache props
@ 2014-09-08 11:38 ` Linus Walleij
0 siblings, 0 replies; 46+ messages in thread
From: Linus Walleij @ 2014-09-08 11:38 UTC (permalink / raw)
To: linux-arm-kernel
Using the cache size, number of sets and cache line size we can
calculate desired associativity of the L2 cache. This is done
by the calculation:
associativity = (cache size / cache sets) / cache line size
For most normal cache sizes this will quickly roof out to the
maximum associativity of 8 (L2x0 variants) or 16 (PL3x0 variants).
While all variants have a hard-coded line size of 32 bytes we also
support reading the "cache-line-size" ePAPR binding and complain
if it does not match the hardware.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
arch/arm/mm/cache-l2x0.c | 62 +++++++++++++++++++++++++++++++++++++++++++-----
1 file changed, 56 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 61a684c743c6..f275cd4e5151 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -947,14 +947,18 @@ static u32 cache_id_part_number_from_dt;
static void __init l2x0_cache_size_of_parse(const struct device_node *np,
u32 *aux_val, u32 *aux_mask,
- u32 max_way_size)
+ u32 max_way_size,
+ u32 max_associativity)
{
u32 mask = 0, val = 0;
u32 size = 0, sets = 0;
u32 way_size = 0, way_size_bits = 1;
+ u32 linesize = 0;
+ u32 assoc = 0;
of_property_read_u32(np, "cache-size", &size);
of_property_read_u32(np, "cache-sets", &sets);
+ of_property_read_u32(np, "cache-line-size", &linesize);
if (!size || !sets)
return;
@@ -962,10 +966,56 @@ static void __init l2x0_cache_size_of_parse(const struct device_node *np,
way_size = size / sets;
if (way_size > max_way_size) {
- pr_warn("L2C: way size %dKB is too large\n", way_size >> 10);
+ pr_warn("L2C OF: way size %dKB is too large\n", way_size >> 10);
return;
}
+ /* All these l2 caches have the same line size actually */
+ if (!linesize)
+ linesize = CACHE_LINE_SIZE;
+ if (linesize != CACHE_LINE_SIZE)
+ pr_warn("L2C OF: DT supplied line size %d bytes does "
+ "not match hardware line size of %d bytes\n",
+ linesize,
+ CACHE_LINE_SIZE);
+
+ /*
+ * This cache is set associative. By increasing associativity
+ * we increase the number of blocks per set. Usually this
+ * quickly hits the roof at 8 or 16 ways of associativity.
+ */
+ assoc = way_size / linesize;
+ if (assoc > max_associativity)
+ assoc = max_associativity;
+
+ mask |= L2X0_AUX_CTRL_ASSOC_MASK;
+
+ /*
+ * Special checks for the PL310 that only has two settings and
+ * cannot be set to fully associative.
+ */
+ if (max_associativity == 16) {
+ if (assoc <= 8) {
+ assoc = 8;
+ /* Leave bit 16 in associativity set to 0 */
+ }
+ if (assoc > 8 && assoc <= 16) {
+ assoc = 16;
+ val |= L310_AUX_CTRL_ASSOCIATIVITY_16;
+ }
+ } else {
+ if (sets == 1)
+ /* Direct-mapped cache */
+ assoc = 1;
+ val |= (assoc << L2X0_AUX_CTRL_ASSOC_SHIFT);
+ }
+
+ pr_info("L2C OF: size: %d bytes (%dKB)\n", size, size >> 10);
+ pr_info("L2C OF: way_size: %d bytes (%d KB)\n",
+ way_size, way_size >> 10);
+ pr_info("L2C OF: associativity: %d ways\n", assoc);
+
+ /* Convert to KB */
way_size >>= 10;
switch (way_size) {
case 512:
@@ -987,7 +1037,7 @@ static void __init l2x0_cache_size_of_parse(const struct device_node *np,
way_size_bits = 1;
break;
default:
- pr_err("cache way size: %d KB is not mapped\n",
+ pr_err("L2C OF: cache way size: %d KB is not mapped\n",
way_size);
break;
}
@@ -1029,7 +1079,7 @@ static void __init l2x0_of_parse(const struct device_node *np,
val |= (dirty - 1) << L2X0_AUX_CTRL_DIRTY_LATENCY_SHIFT;
}
- l2x0_cache_size_of_parse(np, aux_val, aux_mask, SZ_256K);
+ l2x0_cache_size_of_parse(np, aux_val, aux_mask, SZ_256K, 8);
*aux_val &= ~mask;
*aux_val |= val;
@@ -1105,7 +1155,7 @@ static void __init l2c310_of_parse(const struct device_node *np,
l2x0_base + L310_ADDR_FILTER_START);
}
- l2x0_cache_size_of_parse(np, aux_val, aux_mask, SZ_512K);
+ l2x0_cache_size_of_parse(np, aux_val, aux_mask, SZ_512K, 16);
}
static const struct l2c_init_data of_l2c310_data __initconst = {
@@ -1313,7 +1363,7 @@ static void __init aurora_of_parse(const struct device_node *np,
*aux_val |= val;
*aux_mask &= ~mask;
- l2x0_cache_size_of_parse(np, aux_val, aux_mask, SZ_256K);
+ l2x0_cache_size_of_parse(np, aux_val, aux_mask, SZ_256K, 8);
}
static const struct l2c_init_data of_aurora_with_outer_data __initconst = {
--
1.9.3
^ permalink raw reply related [flat|nested] 46+ messages in thread
* [PATCH 7/7 v6] ARM: realview: basic device tree implementation
2014-09-08 11:37 ` Linus Walleij
@ 2014-09-08 11:38 ` Linus Walleij
-1 siblings, 0 replies; 46+ messages in thread
From: Linus Walleij @ 2014-09-08 11:38 UTC (permalink / raw)
To: linux-arm-kernel, devicetree, linux-leds, linux-pm
Cc: Arnd Bergmann, Pawel Moll, Mark Rutland, Marc Zyngier,
Will Deacon, Rob Herring, Linus Walleij
This implements basic device tree boot support for the RealView
platforms, with a basic device tree for ARM PB1176 as an example.
The implementation is done with a new DT-specific board file
using only pre-existing bindings for the basic IRQ, timer and
serial port drivers. A new compatible type is added to the GIC
for the ARM1176.
This implementation uses the MFD syscon handle from day one to
access the system controller registers, and register the devices
using the SoC bus.
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh@kernel.org>
Acked-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v5->v6:
- Rely on the default DT machine as it will pass the l2x0
untouched, we can let the default population call build
up the device tree and skipe .init_machine() entirely.
- Get rid of cache associativity from the device tree, we
added code to calculate this from size and sets.
- Put .l2c_aux_mask and .l2c_aux_val into the DT MACHINE
entry so we can skip the separate call to l2x0_init().
- Specify cache line size in L2 DT entry.
ChangeLog v4->v5:
- Move the l2x0_init() aux set-ups over to the device tree,
using one patch from Florian Fainelli and one patch from
myself to support the needed bits.
- Put "simple-bus" last in binding documentation, examples
and device tree so we go from most to least specific.
- Use the compatible arm11mp-gic binding for the GIC, and add
a more specific binding "arm,arm1176jzf-devchip-gic" for the
variant specifically found on the ARM1176JZF development
chip. Add IRQCHIP_DECLARE() for both variants.
- Drop the "reboot device" node as we rewrote the driver to
hog onto the syscon node directly.
- Augment device tree for the new register-bit-leds used with
the syscon.
ChangeLog v3->v4:
- Switch the LEDs to usa a new syscon-LEDs driver so we can
use the syscon as a hub for all these registers
- Split out the SoC driver to its own file in drivers/soc
ChangeLog v2->v3:
- Rename uart@0x12345678 to serial@0x12345678 in DTS file
- Drop static remapping for the LEDs, using my new invention
syscon-leds instead
- Drop the hunk selecting ARM_DMA_MEM_BUFFERABLE for the DT
version of the RealView platform. We think this is a local
optimization we can live without.
- Split off the reset driver to a separate syscon-based reset
driver in drivers/power/reset, add separate device tree
bindings for this driver.
- To make sure the reset driver is always available for this
system a few extra select statements are needed in Kconfig
- Split off the SoC bus driver to an easily identifiable chunk
inside the mach-realview/realview-dt.c file. This *can* be
spun off as a separate driver under drivers/soc for example
but we need some separate discussion on this subject.
- Augment the SoC driver to display some system info so it's
clear why this driver is there.
- Drop surplus string "with device tree" from machine
description in the DTS file.
- Move the new GIC compatible string in alphabetic order.
ChangeLog v1->v2:
- Adjust timer clock names to be the same as the example in the
device tree binding.
- Remove all memory fixup code - this should be handled by the
device tree specification of memory areas or by special MM hacks
for the RealView PBX.
- Fix the documentation around syscon to specify that it can be in
any node, need not be the root node.
- Switch device tree license to the BSD license, taken from
arch/powerpc/boot/dts/p1024rdb_32b.dts
- Add a hunk for the new compatible string to
Documentation/devicetree/bindings/arm/gic.txt
- Move the clocks out of the SoC node, certainly the xtal is not
sitting on the SoC...
- Sort the selects in Kconfig alphabetically
- Use IS_ENABLED() for the l2x0 code snippet
- Instead of checking the board variant in the reset routine to
figure out how to tweak the reset controller, have a compatible
string for each syscon variant, map it to an enum that provides a
unique type ID and that way figure out how to handle it in a maybe
more elegant way.
- Open issue: what do to with the l2x0 stuff?
---
Documentation/devicetree/bindings/arm/arm-boards | 65 ++++++
Documentation/devicetree/bindings/arm/gic.txt | 1 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/arm-realview-pb1176.dts | 246 +++++++++++++++++++++++
arch/arm/mach-realview/Kconfig | 13 ++
arch/arm/mach-realview/Makefile | 1 +
arch/arm/mach-realview/realview-dt.c | 32 +++
drivers/irqchip/irq-gic.c | 2 +
8 files changed, 361 insertions(+)
create mode 100644 arch/arm/boot/dts/arm-realview-pb1176.dts
create mode 100644 arch/arm/mach-realview/realview-dt.c
diff --git a/Documentation/devicetree/bindings/arm/arm-boards b/Documentation/devicetree/bindings/arm/arm-boards
index c554ed3d44fb..556c8665fdbf 100644
--- a/Documentation/devicetree/bindings/arm/arm-boards
+++ b/Documentation/devicetree/bindings/arm/arm-boards
@@ -92,3 +92,68 @@ Required nodes:
- core-module: the root node to the Versatile platforms must have
a core-module with regs and the compatible strings
"arm,core-module-versatile", "syscon"
+
+ARM RealView Boards
+-------------------
+The RealView boards cover tailored evaluation boards that are used to explore
+the ARM11 and Cortex A-8 and Cortex A-9 processors.
+
+Required properties (in root node):
+ /* RealView Emulation Baseboard */
+ compatible = "arm,realview-eb";
+ /* RealView Platform Baseboard for ARM1176JZF-S */
+ compatible = "arm,realview-pb1176";
+ /* RealView Platform Baseboard for ARM11 MPCore */
+ compatible = "arm,realview-pb11mp";
+ /* RealView Platform Baseboard for Cortex A-8 */
+ compatible = "arm,realview-pba8";
+ /* RealView Platform Baseboard Explore for Cortex A-9 */
+ compatible = "arm,realview-pbx";
+
+Required nodes:
+
+- soc: some node of the RealView platforms must be the SoC
+ node that contain the SoC-specific devices, withe the compatible
+ string set to one of these tuples:
+ "arm,realview-eb-soc", "simple-bus"
+ "arm,realview-pb1176-soc", "simple-bus"
+ "arm,realview-pb11mp-soc", "simple-bus"
+ "arm,realview-pba8-soc", "simple-bus"
+ "arm,realview-pbx-soc", "simple-bus"
+
+- syscon: some subnode of the RealView SoC node must be a
+ system controller node pointing to the control registers,
+ with the compatible string set to one of these tuples:
+ "arm,realview-eb-syscon", "syscon"
+ "arm,realview-pb1176-syscon", "syscon"
+ "arm,realview-pb11mp-syscon", "syscon"
+ "arm,realview-pba8-syscon", "syscon"
+ "arm,realview-pbx-syscon", "syscon"
+
+ Required properties for the system controller:
+ - regs: the location and size of the system controller registers,
+ one range of 0x1000 bytes.
+
+Example:
+
+/dts-v1/;
+#include <dt-bindings/interrupt-controller/irq.h>
+#include "skeleton.dtsi"
+
+/ {
+ model = "ARM RealView PB1176 with device tree";
+ compatible = "arm,realview-pb1176";
+
+ soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "arm,realview-pb1176-soc", "simple-bus";
+ ranges;
+
+ syscon: syscon@10000000 {
+ compatible = "arm,realview-syscon", "syscon";
+ reg = <0x10000000 0x1000>;
+ };
+
+ };
+};
diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt
index c7d2fa156678..b38608af66db 100644
--- a/Documentation/devicetree/bindings/arm/gic.txt
+++ b/Documentation/devicetree/bindings/arm/gic.txt
@@ -17,6 +17,7 @@ Main node required properties:
"arm,cortex-a7-gic"
"arm,arm11mp-gic"
"brcm,brahma-b15-gic"
+ "arm,arm1176jzf-devchip-gic"
- interrupt-controller : Identifies the node as an interrupt controller
- #interrupt-cells : Specifies the number of cells needed to encode an
interrupt source. The type shall be a <u32> and the value shall be 3.
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index b8c5cd3ddeb9..e55d28eed151 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -344,6 +344,7 @@ dtb-$(CONFIG_ARCH_QCOM) += \
qcom-apq8084-mtp.dtb \
qcom-msm8660-surf.dtb \
qcom-msm8960-cdp.dtb
+dtb-$(CONFIG_ARCH_REALVIEW) += arm-realview-pb1176.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += \
rk3066a-bqcurie2.dtb \
rk3188-radxarock.dtb \
diff --git a/arch/arm/boot/dts/arm-realview-pb1176.dts b/arch/arm/boot/dts/arm-realview-pb1176.dts
new file mode 100644
index 000000000000..e1e730f9a3ce
--- /dev/null
+++ b/arch/arm/boot/dts/arm-realview-pb1176.dts
@@ -0,0 +1,246 @@
+/*
+ * Copyright 2014 Linaro Ltd
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include <dt-bindings/interrupt-controller/irq.h>
+#include "skeleton.dtsi"
+
+/ {
+ model = "ARM RealView PB1176";
+ compatible = "arm,realview-pb1176";
+
+ chosen { };
+
+ aliases {
+ serial0 = &pb1176_serial0;
+ serial1 = &pb1176_serial1;
+ serial2 = &pb1176_serial2;
+ serial3 = &pb1176_serial3;
+ };
+
+ memory {
+ /* 128 MiB memory @ 0x0 */
+ reg = <0x00000000 0x08000000>;
+ };
+
+ xtal24mhz: xtal24mhz@24M {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <24000000>;
+ };
+
+ timclk: timclk@1M {
+ #clock-cells = <0>;
+ compatible = "fixed-factor-clock";
+ clock-div = <24>;
+ clock-mult = <1>;
+ clocks = <&xtal24mhz>;
+ };
+
+ uartclk: uartclk@24M {
+ #clock-cells = <0>;
+ compatible = "fixed-factor-clock";
+ clock-div = <1>;
+ clock-mult = <1>;
+ clocks = <&xtal24mhz>;
+ };
+
+ /* FIXME: this actually hangs off the PLL clocks */
+ pclk: pclk@0 {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <0>;
+ };
+
+ soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "arm,realview-pb1176-soc", "simple-bus";
+ regmap = <&syscon>;
+ ranges;
+
+ syscon: syscon@10000000 {
+ compatible = "arm,realview-pb1176-syscon", "syscon";
+ reg = <0x10000000 0x1000>;
+
+ led@08.0 {
+ compatible = "register-bit-led";
+ offset = <0x08>;
+ mask = <0x01>;
+ label = "versatile:0";
+ linux,default-trigger = "heartbeat";
+ default-state = "on";
+ };
+ led@08.1 {
+ compatible = "register-bit-led";
+ offset = <0x08>;
+ mask = <0x02>;
+ label = "versatile:1";
+ linux,default-trigger = "mmc0";
+ default-state = "off";
+ };
+ led@08.2 {
+ compatible = "register-bit-led";
+ offset = <0x08>;
+ mask = <0x04>;
+ label = "versatile:2";
+ linux,default-trigger = "cpu0";
+ default-state = "off";
+ };
+ led@08.3 {
+ compatible = "register-bit-led";
+ offset = <0x08>;
+ mask = <0x08>;
+ label = "versatile:3";
+ default-state = "off";
+ };
+ led@08.4 {
+ compatible = "register-bit-led";
+ offset = <0x08>;
+ mask = <0x10>;
+ label = "versatile:4";
+ default-state = "off";
+ };
+ led@08.5 {
+ compatible = "register-bit-led";
+ offset = <0x08>;
+ mask = <0x20>;
+ label = "versatile:5";
+ default-state = "off";
+ };
+ led@08.6 {
+ compatible = "register-bit-led";
+ offset = <0x08>;
+ mask = <0x40>;
+ label = "versatile:6";
+ default-state = "off";
+ };
+ led@08.7 {
+ compatible = "register-bit-led";
+ offset = <0x08>;
+ mask = <0x80>;
+ label = "versatile:7";
+ default-state = "off";
+ };
+ };
+
+ /* Primary DevChip GIC synthesized with the CPU */
+ intc_dc1176: interrupt-controller@10120000 {
+ compatible = "arm,arm1176jzf-devchip-gic", "arm,arm11mp-gic";
+ #interrupt-cells = <3>;
+ #address-cells = <1>;
+ interrupt-controller;
+ reg = <0x10121000 0x1000>,
+ <0x10120000 0x100>;
+ };
+
+ /* This GIC on the board is cascaded off the DevChip GIC */
+ intc_pb1176: interrupt-controller@10040000 {
+ compatible = "arm,arm1176jzf-devchip-gic", "arm,arm11mp-gic";
+ #interrupt-cells = <3>;
+ #address-cells = <1>;
+ interrupt-controller;
+ reg = <0x10041000 0x1000>,
+ <0x10040000 0x100>;
+ interrupt-parent = <&intc_dc1176>;
+ interrupts = <0 31 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ L2: l2-cache {
+ compatible = "arm,l220-cache";
+ reg = <0x10110000 0x1000>;
+ interrupt-parent = <&intc_dc1176>;
+ interrupts = <0 13 IRQ_TYPE_LEVEL_HIGH>;
+ cache-unified;
+ cache-level = <2>;
+ /*
+ * Override default cache size, sets and
+ * associativity as these may be erroneously set
+ * up by boot loader(s).
+ */
+ cache-size = <131072>; // 128kB
+ cache-sets = <8>;
+ cache-line-size = <32>;
+ };
+
+ pmu {
+ compatible = "arm,arm1176-pmu";
+ interrupt-parent = <&intc_dc1176>;
+ interrupts = <0 7 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ timer01: timer@10104000 {
+ compatible = "arm,sp804", "arm,primecell";
+ reg = <0x10104000 0x1000>;
+ interrupt-parent = <&intc_dc1176>;
+ interrupts = <0 8 IRQ_TYPE_LEVEL_HIGH>, <0 9 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&timclk>, <&timclk>, <&pclk>;
+ clock-names = "timer1", "timer2", "apb_pclk";
+ };
+
+ timer23: timer@10105000 {
+ compatible = "arm,sp804", "arm,primecell";
+ reg = <0x10105000 0x1000>;
+ interrupt-parent = <&intc_dc1176>;
+ interrupts = <0 10 IRQ_TYPE_LEVEL_HIGH>;
+ arm,sp804-has-irq = <1>;
+ clocks = <&timclk>, <&timclk>, <&pclk>;
+ clock-names = "timer1", "timer2", "apb_pclk";
+ };
+
+ pb1176_serial0: serial@1010c000 {
+ compatible = "arm,pl011", "arm,primecell";
+ reg = <0x1010c000 0x1000>;
+ interrupt-parent = <&intc_dc1176>;
+ interrupts = <0 18 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&uartclk>, <&pclk>;
+ clock-names = "uartclk", "apb_pclk";
+ };
+
+ pb1176_serial1: serial@1010d000 {
+ compatible = "arm,pl011", "arm,primecell";
+ reg = <0x1010d000 0x1000>;
+ interrupt-parent = <&intc_dc1176>;
+ interrupts = <0 19 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&uartclk>, <&pclk>;
+ clock-names = "uartclk", "apb_pclk";
+ };
+
+ pb1176_serial2: serial@1010e000 {
+ compatible = "arm,pl011", "arm,primecell";
+ reg = <0x1010e000 0x1000>;
+ interrupt-parent = <&intc_dc1176>;
+ interrupts = <0 20 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&uartclk>, <&pclk>;
+ clock-names = "uartclk", "apb_pclk";
+ };
+
+ pb1176_serial3: serial@1010f000 {
+ compatible = "arm,pl011", "arm,primecell";
+ reg = <0x1010f000 0x1000>;
+ interrupt-parent = <&intc_dc1176>;
+ interrupts = <0 21 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&uartclk>, <&pclk>;
+ clock-names = "uartclk", "apb_pclk";
+ };
+ };
+};
diff --git a/arch/arm/mach-realview/Kconfig b/arch/arm/mach-realview/Kconfig
index 9db2029aa632..565925f37dc5 100644
--- a/arch/arm/mach-realview/Kconfig
+++ b/arch/arm/mach-realview/Kconfig
@@ -1,6 +1,19 @@
menu "RealView platform type"
depends on ARCH_REALVIEW
+config REALVIEW_DT
+ bool "Support RealView(R) Device Tree based boot"
+ select ARM_GIC
+ select MFD_SYSCON
+ select POWER_RESET
+ select POWER_RESET_VERSATILE
+ select POWER_SUPPLY
+ select SOC_REALVIEW
+ select USE_OF
+ help
+ Include support for booting the ARM(R) RealView(R) evaluation
+ boards using a device tree machine description.
+
config MACH_REALVIEW_EB
bool "Support RealView(R) Emulation Baseboard"
select ARM_GIC
diff --git a/arch/arm/mach-realview/Makefile b/arch/arm/mach-realview/Makefile
index 541fa4c109ef..e07fdf7ae8a7 100644
--- a/arch/arm/mach-realview/Makefile
+++ b/arch/arm/mach-realview/Makefile
@@ -3,6 +3,7 @@
#
obj-y := core.o
+obj-$(CONFIG_REALVIEW_DT) += realview-dt.o
obj-$(CONFIG_MACH_REALVIEW_EB) += realview_eb.o
obj-$(CONFIG_MACH_REALVIEW_PB11MP) += realview_pb11mp.o
obj-$(CONFIG_MACH_REALVIEW_PB1176) += realview_pb1176.o
diff --git a/arch/arm/mach-realview/realview-dt.c b/arch/arm/mach-realview/realview-dt.c
new file mode 100644
index 000000000000..cc28b89dd48f
--- /dev/null
+++ b/arch/arm/mach-realview/realview-dt.c
@@ -0,0 +1,32 @@
+/*
+ * Copyright (C) 2014 Linaro Ltd.
+ *
+ * Author: Linus Walleij <linus.walleij@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2, as
+ * published by the Free Software Foundation.
+ *
+ */
+#include <linux/of_platform.h>
+#include <asm/mach/arch.h>
+#include <asm/hardware/cache-l2x0.h>
+#include "core.h"
+
+static const char *realview_dt_platform_compat[] __initconst = {
+ "arm,realview-eb",
+ "arm,realview-pb1176",
+ "arm,realview-pb11mp",
+ "arm,realview-pba8",
+ "arm,realview-pbx",
+ NULL,
+};
+
+DT_MACHINE_START(REALVIEW_DT, "ARM RealView Machine (Device Tree Support)")
+#ifdef CONFIG_ZONE_DMA
+ .dma_zone_size = SZ_256M,
+#endif
+ .dt_compat = realview_dt_platform_compat,
+ .l2c_aux_val = 0x0,
+ .l2c_aux_mask = ~0x0,
+MACHINE_END
diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index 4b959e606fe8..4e75e3f24a97 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -1022,6 +1022,8 @@ gic_of_init(struct device_node *node, struct device_node *parent)
return 0;
}
IRQCHIP_DECLARE(gic_400, "arm,gic-400", gic_of_init);
+IRQCHIP_DECLARE(arm11mp_gic, "arm,arm11mp-gic", gic_of_init);
+IRQCHIP_DECLARE(arm1176jzf_dc_gic, "arm,arm1176jzf-devchip-gic", gic_of_init);
IRQCHIP_DECLARE(cortex_a15_gic, "arm,cortex-a15-gic", gic_of_init);
IRQCHIP_DECLARE(cortex_a9_gic, "arm,cortex-a9-gic", gic_of_init);
IRQCHIP_DECLARE(cortex_a7_gic, "arm,cortex-a7-gic", gic_of_init);
--
1.9.3
^ permalink raw reply related [flat|nested] 46+ messages in thread
* [PATCH 7/7 v6] ARM: realview: basic device tree implementation
@ 2014-09-08 11:38 ` Linus Walleij
0 siblings, 0 replies; 46+ messages in thread
From: Linus Walleij @ 2014-09-08 11:38 UTC (permalink / raw)
To: linux-arm-kernel
This implements basic device tree boot support for the RealView
platforms, with a basic device tree for ARM PB1176 as an example.
The implementation is done with a new DT-specific board file
using only pre-existing bindings for the basic IRQ, timer and
serial port drivers. A new compatible type is added to the GIC
for the ARM1176.
This implementation uses the MFD syscon handle from day one to
access the system controller registers, and register the devices
using the SoC bus.
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh@kernel.org>
Acked-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v5->v6:
- Rely on the default DT machine as it will pass the l2x0
untouched, we can let the default population call build
up the device tree and skipe .init_machine() entirely.
- Get rid of cache associativity from the device tree, we
added code to calculate this from size and sets.
- Put .l2c_aux_mask and .l2c_aux_val into the DT MACHINE
entry so we can skip the separate call to l2x0_init().
- Specify cache line size in L2 DT entry.
ChangeLog v4->v5:
- Move the l2x0_init() aux set-ups over to the device tree,
using one patch from Florian Fainelli and one patch from
myself to support the needed bits.
- Put "simple-bus" last in binding documentation, examples
and device tree so we go from most to least specific.
- Use the compatible arm11mp-gic binding for the GIC, and add
a more specific binding "arm,arm1176jzf-devchip-gic" for the
variant specifically found on the ARM1176JZF development
chip. Add IRQCHIP_DECLARE() for both variants.
- Drop the "reboot device" node as we rewrote the driver to
hog onto the syscon node directly.
- Augment device tree for the new register-bit-leds used with
the syscon.
ChangeLog v3->v4:
- Switch the LEDs to usa a new syscon-LEDs driver so we can
use the syscon as a hub for all these registers
- Split out the SoC driver to its own file in drivers/soc
ChangeLog v2->v3:
- Rename uart at 0x12345678 to serial at 0x12345678 in DTS file
- Drop static remapping for the LEDs, using my new invention
syscon-leds instead
- Drop the hunk selecting ARM_DMA_MEM_BUFFERABLE for the DT
version of the RealView platform. We think this is a local
optimization we can live without.
- Split off the reset driver to a separate syscon-based reset
driver in drivers/power/reset, add separate device tree
bindings for this driver.
- To make sure the reset driver is always available for this
system a few extra select statements are needed in Kconfig
- Split off the SoC bus driver to an easily identifiable chunk
inside the mach-realview/realview-dt.c file. This *can* be
spun off as a separate driver under drivers/soc for example
but we need some separate discussion on this subject.
- Augment the SoC driver to display some system info so it's
clear why this driver is there.
- Drop surplus string "with device tree" from machine
description in the DTS file.
- Move the new GIC compatible string in alphabetic order.
ChangeLog v1->v2:
- Adjust timer clock names to be the same as the example in the
device tree binding.
- Remove all memory fixup code - this should be handled by the
device tree specification of memory areas or by special MM hacks
for the RealView PBX.
- Fix the documentation around syscon to specify that it can be in
any node, need not be the root node.
- Switch device tree license to the BSD license, taken from
arch/powerpc/boot/dts/p1024rdb_32b.dts
- Add a hunk for the new compatible string to
Documentation/devicetree/bindings/arm/gic.txt
- Move the clocks out of the SoC node, certainly the xtal is not
sitting on the SoC...
- Sort the selects in Kconfig alphabetically
- Use IS_ENABLED() for the l2x0 code snippet
- Instead of checking the board variant in the reset routine to
figure out how to tweak the reset controller, have a compatible
string for each syscon variant, map it to an enum that provides a
unique type ID and that way figure out how to handle it in a maybe
more elegant way.
- Open issue: what do to with the l2x0 stuff?
---
Documentation/devicetree/bindings/arm/arm-boards | 65 ++++++
Documentation/devicetree/bindings/arm/gic.txt | 1 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/arm-realview-pb1176.dts | 246 +++++++++++++++++++++++
arch/arm/mach-realview/Kconfig | 13 ++
arch/arm/mach-realview/Makefile | 1 +
arch/arm/mach-realview/realview-dt.c | 32 +++
drivers/irqchip/irq-gic.c | 2 +
8 files changed, 361 insertions(+)
create mode 100644 arch/arm/boot/dts/arm-realview-pb1176.dts
create mode 100644 arch/arm/mach-realview/realview-dt.c
diff --git a/Documentation/devicetree/bindings/arm/arm-boards b/Documentation/devicetree/bindings/arm/arm-boards
index c554ed3d44fb..556c8665fdbf 100644
--- a/Documentation/devicetree/bindings/arm/arm-boards
+++ b/Documentation/devicetree/bindings/arm/arm-boards
@@ -92,3 +92,68 @@ Required nodes:
- core-module: the root node to the Versatile platforms must have
a core-module with regs and the compatible strings
"arm,core-module-versatile", "syscon"
+
+ARM RealView Boards
+-------------------
+The RealView boards cover tailored evaluation boards that are used to explore
+the ARM11 and Cortex A-8 and Cortex A-9 processors.
+
+Required properties (in root node):
+ /* RealView Emulation Baseboard */
+ compatible = "arm,realview-eb";
+ /* RealView Platform Baseboard for ARM1176JZF-S */
+ compatible = "arm,realview-pb1176";
+ /* RealView Platform Baseboard for ARM11 MPCore */
+ compatible = "arm,realview-pb11mp";
+ /* RealView Platform Baseboard for Cortex A-8 */
+ compatible = "arm,realview-pba8";
+ /* RealView Platform Baseboard Explore for Cortex A-9 */
+ compatible = "arm,realview-pbx";
+
+Required nodes:
+
+- soc: some node of the RealView platforms must be the SoC
+ node that contain the SoC-specific devices, withe the compatible
+ string set to one of these tuples:
+ "arm,realview-eb-soc", "simple-bus"
+ "arm,realview-pb1176-soc", "simple-bus"
+ "arm,realview-pb11mp-soc", "simple-bus"
+ "arm,realview-pba8-soc", "simple-bus"
+ "arm,realview-pbx-soc", "simple-bus"
+
+- syscon: some subnode of the RealView SoC node must be a
+ system controller node pointing to the control registers,
+ with the compatible string set to one of these tuples:
+ "arm,realview-eb-syscon", "syscon"
+ "arm,realview-pb1176-syscon", "syscon"
+ "arm,realview-pb11mp-syscon", "syscon"
+ "arm,realview-pba8-syscon", "syscon"
+ "arm,realview-pbx-syscon", "syscon"
+
+ Required properties for the system controller:
+ - regs: the location and size of the system controller registers,
+ one range of 0x1000 bytes.
+
+Example:
+
+/dts-v1/;
+#include <dt-bindings/interrupt-controller/irq.h>
+#include "skeleton.dtsi"
+
+/ {
+ model = "ARM RealView PB1176 with device tree";
+ compatible = "arm,realview-pb1176";
+
+ soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "arm,realview-pb1176-soc", "simple-bus";
+ ranges;
+
+ syscon: syscon at 10000000 {
+ compatible = "arm,realview-syscon", "syscon";
+ reg = <0x10000000 0x1000>;
+ };
+
+ };
+};
diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt
index c7d2fa156678..b38608af66db 100644
--- a/Documentation/devicetree/bindings/arm/gic.txt
+++ b/Documentation/devicetree/bindings/arm/gic.txt
@@ -17,6 +17,7 @@ Main node required properties:
"arm,cortex-a7-gic"
"arm,arm11mp-gic"
"brcm,brahma-b15-gic"
+ "arm,arm1176jzf-devchip-gic"
- interrupt-controller : Identifies the node as an interrupt controller
- #interrupt-cells : Specifies the number of cells needed to encode an
interrupt source. The type shall be a <u32> and the value shall be 3.
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index b8c5cd3ddeb9..e55d28eed151 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -344,6 +344,7 @@ dtb-$(CONFIG_ARCH_QCOM) += \
qcom-apq8084-mtp.dtb \
qcom-msm8660-surf.dtb \
qcom-msm8960-cdp.dtb
+dtb-$(CONFIG_ARCH_REALVIEW) += arm-realview-pb1176.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += \
rk3066a-bqcurie2.dtb \
rk3188-radxarock.dtb \
diff --git a/arch/arm/boot/dts/arm-realview-pb1176.dts b/arch/arm/boot/dts/arm-realview-pb1176.dts
new file mode 100644
index 000000000000..e1e730f9a3ce
--- /dev/null
+++ b/arch/arm/boot/dts/arm-realview-pb1176.dts
@@ -0,0 +1,246 @@
+/*
+ * Copyright 2014 Linaro Ltd
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include <dt-bindings/interrupt-controller/irq.h>
+#include "skeleton.dtsi"
+
+/ {
+ model = "ARM RealView PB1176";
+ compatible = "arm,realview-pb1176";
+
+ chosen { };
+
+ aliases {
+ serial0 = &pb1176_serial0;
+ serial1 = &pb1176_serial1;
+ serial2 = &pb1176_serial2;
+ serial3 = &pb1176_serial3;
+ };
+
+ memory {
+ /* 128 MiB memory @ 0x0 */
+ reg = <0x00000000 0x08000000>;
+ };
+
+ xtal24mhz: xtal24mhz at 24M {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <24000000>;
+ };
+
+ timclk: timclk at 1M {
+ #clock-cells = <0>;
+ compatible = "fixed-factor-clock";
+ clock-div = <24>;
+ clock-mult = <1>;
+ clocks = <&xtal24mhz>;
+ };
+
+ uartclk: uartclk at 24M {
+ #clock-cells = <0>;
+ compatible = "fixed-factor-clock";
+ clock-div = <1>;
+ clock-mult = <1>;
+ clocks = <&xtal24mhz>;
+ };
+
+ /* FIXME: this actually hangs off the PLL clocks */
+ pclk: pclk at 0 {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <0>;
+ };
+
+ soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "arm,realview-pb1176-soc", "simple-bus";
+ regmap = <&syscon>;
+ ranges;
+
+ syscon: syscon at 10000000 {
+ compatible = "arm,realview-pb1176-syscon", "syscon";
+ reg = <0x10000000 0x1000>;
+
+ led at 08.0 {
+ compatible = "register-bit-led";
+ offset = <0x08>;
+ mask = <0x01>;
+ label = "versatile:0";
+ linux,default-trigger = "heartbeat";
+ default-state = "on";
+ };
+ led at 08.1 {
+ compatible = "register-bit-led";
+ offset = <0x08>;
+ mask = <0x02>;
+ label = "versatile:1";
+ linux,default-trigger = "mmc0";
+ default-state = "off";
+ };
+ led at 08.2 {
+ compatible = "register-bit-led";
+ offset = <0x08>;
+ mask = <0x04>;
+ label = "versatile:2";
+ linux,default-trigger = "cpu0";
+ default-state = "off";
+ };
+ led at 08.3 {
+ compatible = "register-bit-led";
+ offset = <0x08>;
+ mask = <0x08>;
+ label = "versatile:3";
+ default-state = "off";
+ };
+ led at 08.4 {
+ compatible = "register-bit-led";
+ offset = <0x08>;
+ mask = <0x10>;
+ label = "versatile:4";
+ default-state = "off";
+ };
+ led at 08.5 {
+ compatible = "register-bit-led";
+ offset = <0x08>;
+ mask = <0x20>;
+ label = "versatile:5";
+ default-state = "off";
+ };
+ led at 08.6 {
+ compatible = "register-bit-led";
+ offset = <0x08>;
+ mask = <0x40>;
+ label = "versatile:6";
+ default-state = "off";
+ };
+ led at 08.7 {
+ compatible = "register-bit-led";
+ offset = <0x08>;
+ mask = <0x80>;
+ label = "versatile:7";
+ default-state = "off";
+ };
+ };
+
+ /* Primary DevChip GIC synthesized with the CPU */
+ intc_dc1176: interrupt-controller at 10120000 {
+ compatible = "arm,arm1176jzf-devchip-gic", "arm,arm11mp-gic";
+ #interrupt-cells = <3>;
+ #address-cells = <1>;
+ interrupt-controller;
+ reg = <0x10121000 0x1000>,
+ <0x10120000 0x100>;
+ };
+
+ /* This GIC on the board is cascaded off the DevChip GIC */
+ intc_pb1176: interrupt-controller at 10040000 {
+ compatible = "arm,arm1176jzf-devchip-gic", "arm,arm11mp-gic";
+ #interrupt-cells = <3>;
+ #address-cells = <1>;
+ interrupt-controller;
+ reg = <0x10041000 0x1000>,
+ <0x10040000 0x100>;
+ interrupt-parent = <&intc_dc1176>;
+ interrupts = <0 31 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ L2: l2-cache {
+ compatible = "arm,l220-cache";
+ reg = <0x10110000 0x1000>;
+ interrupt-parent = <&intc_dc1176>;
+ interrupts = <0 13 IRQ_TYPE_LEVEL_HIGH>;
+ cache-unified;
+ cache-level = <2>;
+ /*
+ * Override default cache size, sets and
+ * associativity as these may be erroneously set
+ * up by boot loader(s).
+ */
+ cache-size = <131072>; // 128kB
+ cache-sets = <8>;
+ cache-line-size = <32>;
+ };
+
+ pmu {
+ compatible = "arm,arm1176-pmu";
+ interrupt-parent = <&intc_dc1176>;
+ interrupts = <0 7 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ timer01: timer at 10104000 {
+ compatible = "arm,sp804", "arm,primecell";
+ reg = <0x10104000 0x1000>;
+ interrupt-parent = <&intc_dc1176>;
+ interrupts = <0 8 IRQ_TYPE_LEVEL_HIGH>, <0 9 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&timclk>, <&timclk>, <&pclk>;
+ clock-names = "timer1", "timer2", "apb_pclk";
+ };
+
+ timer23: timer at 10105000 {
+ compatible = "arm,sp804", "arm,primecell";
+ reg = <0x10105000 0x1000>;
+ interrupt-parent = <&intc_dc1176>;
+ interrupts = <0 10 IRQ_TYPE_LEVEL_HIGH>;
+ arm,sp804-has-irq = <1>;
+ clocks = <&timclk>, <&timclk>, <&pclk>;
+ clock-names = "timer1", "timer2", "apb_pclk";
+ };
+
+ pb1176_serial0: serial at 1010c000 {
+ compatible = "arm,pl011", "arm,primecell";
+ reg = <0x1010c000 0x1000>;
+ interrupt-parent = <&intc_dc1176>;
+ interrupts = <0 18 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&uartclk>, <&pclk>;
+ clock-names = "uartclk", "apb_pclk";
+ };
+
+ pb1176_serial1: serial at 1010d000 {
+ compatible = "arm,pl011", "arm,primecell";
+ reg = <0x1010d000 0x1000>;
+ interrupt-parent = <&intc_dc1176>;
+ interrupts = <0 19 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&uartclk>, <&pclk>;
+ clock-names = "uartclk", "apb_pclk";
+ };
+
+ pb1176_serial2: serial at 1010e000 {
+ compatible = "arm,pl011", "arm,primecell";
+ reg = <0x1010e000 0x1000>;
+ interrupt-parent = <&intc_dc1176>;
+ interrupts = <0 20 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&uartclk>, <&pclk>;
+ clock-names = "uartclk", "apb_pclk";
+ };
+
+ pb1176_serial3: serial at 1010f000 {
+ compatible = "arm,pl011", "arm,primecell";
+ reg = <0x1010f000 0x1000>;
+ interrupt-parent = <&intc_dc1176>;
+ interrupts = <0 21 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&uartclk>, <&pclk>;
+ clock-names = "uartclk", "apb_pclk";
+ };
+ };
+};
diff --git a/arch/arm/mach-realview/Kconfig b/arch/arm/mach-realview/Kconfig
index 9db2029aa632..565925f37dc5 100644
--- a/arch/arm/mach-realview/Kconfig
+++ b/arch/arm/mach-realview/Kconfig
@@ -1,6 +1,19 @@
menu "RealView platform type"
depends on ARCH_REALVIEW
+config REALVIEW_DT
+ bool "Support RealView(R) Device Tree based boot"
+ select ARM_GIC
+ select MFD_SYSCON
+ select POWER_RESET
+ select POWER_RESET_VERSATILE
+ select POWER_SUPPLY
+ select SOC_REALVIEW
+ select USE_OF
+ help
+ Include support for booting the ARM(R) RealView(R) evaluation
+ boards using a device tree machine description.
+
config MACH_REALVIEW_EB
bool "Support RealView(R) Emulation Baseboard"
select ARM_GIC
diff --git a/arch/arm/mach-realview/Makefile b/arch/arm/mach-realview/Makefile
index 541fa4c109ef..e07fdf7ae8a7 100644
--- a/arch/arm/mach-realview/Makefile
+++ b/arch/arm/mach-realview/Makefile
@@ -3,6 +3,7 @@
#
obj-y := core.o
+obj-$(CONFIG_REALVIEW_DT) += realview-dt.o
obj-$(CONFIG_MACH_REALVIEW_EB) += realview_eb.o
obj-$(CONFIG_MACH_REALVIEW_PB11MP) += realview_pb11mp.o
obj-$(CONFIG_MACH_REALVIEW_PB1176) += realview_pb1176.o
diff --git a/arch/arm/mach-realview/realview-dt.c b/arch/arm/mach-realview/realview-dt.c
new file mode 100644
index 000000000000..cc28b89dd48f
--- /dev/null
+++ b/arch/arm/mach-realview/realview-dt.c
@@ -0,0 +1,32 @@
+/*
+ * Copyright (C) 2014 Linaro Ltd.
+ *
+ * Author: Linus Walleij <linus.walleij@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2, as
+ * published by the Free Software Foundation.
+ *
+ */
+#include <linux/of_platform.h>
+#include <asm/mach/arch.h>
+#include <asm/hardware/cache-l2x0.h>
+#include "core.h"
+
+static const char *realview_dt_platform_compat[] __initconst = {
+ "arm,realview-eb",
+ "arm,realview-pb1176",
+ "arm,realview-pb11mp",
+ "arm,realview-pba8",
+ "arm,realview-pbx",
+ NULL,
+};
+
+DT_MACHINE_START(REALVIEW_DT, "ARM RealView Machine (Device Tree Support)")
+#ifdef CONFIG_ZONE_DMA
+ .dma_zone_size = SZ_256M,
+#endif
+ .dt_compat = realview_dt_platform_compat,
+ .l2c_aux_val = 0x0,
+ .l2c_aux_mask = ~0x0,
+MACHINE_END
diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index 4b959e606fe8..4e75e3f24a97 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -1022,6 +1022,8 @@ gic_of_init(struct device_node *node, struct device_node *parent)
return 0;
}
IRQCHIP_DECLARE(gic_400, "arm,gic-400", gic_of_init);
+IRQCHIP_DECLARE(arm11mp_gic, "arm,arm11mp-gic", gic_of_init);
+IRQCHIP_DECLARE(arm1176jzf_dc_gic, "arm,arm1176jzf-devchip-gic", gic_of_init);
IRQCHIP_DECLARE(cortex_a15_gic, "arm,cortex-a15-gic", gic_of_init);
IRQCHIP_DECLARE(cortex_a9_gic, "arm,cortex-a9-gic", gic_of_init);
IRQCHIP_DECLARE(cortex_a7_gic, "arm,cortex-a7-gic", gic_of_init);
--
1.9.3
^ permalink raw reply related [flat|nested] 46+ messages in thread
* Re: [PATCH 6/7 v6] ARM: l2x0: calculate associativity from ePAPR cache props
2014-09-08 11:38 ` Linus Walleij
@ 2014-09-08 12:15 ` Arnd Bergmann
-1 siblings, 0 replies; 46+ messages in thread
From: Arnd Bergmann @ 2014-09-08 12:15 UTC (permalink / raw)
To: Linus Walleij
Cc: linux-arm-kernel, devicetree, linux-leds, linux-pm, Pawel Moll,
Mark Rutland, Marc Zyngier, Will Deacon, Rob Herring
On Monday 08 September 2014 13:38:05 Linus Walleij wrote:
> static void __init l2x0_cache_size_of_parse(const struct device_node *np,
> u32 *aux_val, u32 *aux_mask,
> - u32 max_way_size)
> + u32 max_way_size,
> + u32 max_associativity)
> {
> u32 mask = 0, val = 0;
> u32 size = 0, sets = 0;
> u32 way_size = 0, way_size_bits = 1;
> + u32 linesize = 0;
> + u32 assoc = 0;
>
> of_property_read_u32(np, "cache-size", &size);
> of_property_read_u32(np, "cache-sets", &sets);
> + of_property_read_u32(np, "cache-line-size", &linesize);
>
If I read ePAPR correctly, you have to read "cache-block-size" as well, and
use that as a fallback if "cache-line-size" is not provided. The line size
is only required to be in the DT if it's different from the block size.
> if (!size || !sets)
> return;
> @@ -962,10 +966,56 @@ static void __init l2x0_cache_size_of_parse(const struct device_node *np,
> way_size = size / sets;
>
> if (way_size > max_way_size) {
> - pr_warn("L2C: way size %dKB is too large\n", way_size >> 10);
> + pr_warn("L2C OF: way size %dKB is too large\n", way_size >> 10);
> return;
> }
>
> + /* All these l2 caches have the same line size actually */
> + if (!linesize)
> + linesize = CACHE_LINE_SIZE;
> + if (linesize != CACHE_LINE_SIZE)
> + pr_warn("L2C OF: DT supplied line size %d bytes does "
> + "not match hardware line size of %d bytes\n",
> + linesize,
> + CACHE_LINE_SIZE);
and CACHE_LINE_SIZE seems to be what ePAPR calls cache-block-size, i.e.
the fundamental unit of cache management as seen from the CPU, independent
of how it is physically organized.
> + /*
> + * This cache is set associative. By increasing associativity
> + * we increase the number of blocks per set. Usually this
> + * quickly hits the roof at 8 or 16 ways of associativity.
> + */
> + assoc = way_size / linesize;
> + if (assoc > max_associativity)
> + assoc = max_associativity;
> +
I don't see what this helps us. Doesn't this silently try to fix up
incorrect device trees?
If so, I'd rather see the cache get disabled and a warning printed
here.
> + /*
> + * Special checks for the PL310 that only has two settings and
> + * cannot be set to fully associative.
> + */
> + if (max_associativity == 16) {
> + if (assoc <= 8) {
> + assoc = 8;
> + /* Leave bit 16 in associativity set to 0 */
> + }
> + if (assoc > 8 && assoc <= 16) {
> + assoc = 16;
> + val |= L310_AUX_CTRL_ASSOCIATIVITY_16;
> + }
Same thing here.
> + } else {
> + if (sets == 1)
> + /* Direct-mapped cache */
> + assoc = 1;
> + val |= (assoc << L2X0_AUX_CTRL_ASSOC_SHIFT);
> + }
This looks wrong: isn't "sets==1" fully associative rather than
direct-mapped?
Arnd
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 6/7 v6] ARM: l2x0: calculate associativity from ePAPR cache props
@ 2014-09-08 12:15 ` Arnd Bergmann
0 siblings, 0 replies; 46+ messages in thread
From: Arnd Bergmann @ 2014-09-08 12:15 UTC (permalink / raw)
To: linux-arm-kernel
On Monday 08 September 2014 13:38:05 Linus Walleij wrote:
> static void __init l2x0_cache_size_of_parse(const struct device_node *np,
> u32 *aux_val, u32 *aux_mask,
> - u32 max_way_size)
> + u32 max_way_size,
> + u32 max_associativity)
> {
> u32 mask = 0, val = 0;
> u32 size = 0, sets = 0;
> u32 way_size = 0, way_size_bits = 1;
> + u32 linesize = 0;
> + u32 assoc = 0;
>
> of_property_read_u32(np, "cache-size", &size);
> of_property_read_u32(np, "cache-sets", &sets);
> + of_property_read_u32(np, "cache-line-size", &linesize);
>
If I read ePAPR correctly, you have to read "cache-block-size" as well, and
use that as a fallback if "cache-line-size" is not provided. The line size
is only required to be in the DT if it's different from the block size.
> if (!size || !sets)
> return;
> @@ -962,10 +966,56 @@ static void __init l2x0_cache_size_of_parse(const struct device_node *np,
> way_size = size / sets;
>
> if (way_size > max_way_size) {
> - pr_warn("L2C: way size %dKB is too large\n", way_size >> 10);
> + pr_warn("L2C OF: way size %dKB is too large\n", way_size >> 10);
> return;
> }
>
> + /* All these l2 caches have the same line size actually */
> + if (!linesize)
> + linesize = CACHE_LINE_SIZE;
> + if (linesize != CACHE_LINE_SIZE)
> + pr_warn("L2C OF: DT supplied line size %d bytes does "
> + "not match hardware line size of %d bytes\n",
> + linesize,
> + CACHE_LINE_SIZE);
and CACHE_LINE_SIZE seems to be what ePAPR calls cache-block-size, i.e.
the fundamental unit of cache management as seen from the CPU, independent
of how it is physically organized.
> + /*
> + * This cache is set associative. By increasing associativity
> + * we increase the number of blocks per set. Usually this
> + * quickly hits the roof at 8 or 16 ways of associativity.
> + */
> + assoc = way_size / linesize;
> + if (assoc > max_associativity)
> + assoc = max_associativity;
> +
I don't see what this helps us. Doesn't this silently try to fix up
incorrect device trees?
If so, I'd rather see the cache get disabled and a warning printed
here.
> + /*
> + * Special checks for the PL310 that only has two settings and
> + * cannot be set to fully associative.
> + */
> + if (max_associativity == 16) {
> + if (assoc <= 8) {
> + assoc = 8;
> + /* Leave bit 16 in associativity set to 0 */
> + }
> + if (assoc > 8 && assoc <= 16) {
> + assoc = 16;
> + val |= L310_AUX_CTRL_ASSOCIATIVITY_16;
> + }
Same thing here.
> + } else {
> + if (sets == 1)
> + /* Direct-mapped cache */
> + assoc = 1;
> + val |= (assoc << L2X0_AUX_CTRL_ASSOC_SHIFT);
> + }
This looks wrong: isn't "sets==1" fully associative rather than
direct-mapped?
Arnd
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 5/7 v6] ARM: l2c: parse 'cache-size' and 'cache-sets' properties
2014-09-08 11:38 ` Linus Walleij
@ 2014-09-08 12:20 ` Arnd Bergmann
-1 siblings, 0 replies; 46+ messages in thread
From: Arnd Bergmann @ 2014-09-08 12:20 UTC (permalink / raw)
To: Linus Walleij
Cc: linux-arm-kernel, devicetree, linux-leds, linux-pm, Pawel Moll,
Mark Rutland, Marc Zyngier, Will Deacon, Rob Herring,
Florian Fainelli
On Monday 08 September 2014 13:38:04 Linus Walleij wrote:
> + of_property_read_u32(np, "cache-size", &size);
> + of_property_read_u32(np, "cache-sets", &sets);
> +
> + if (!size || !sets)
> + return;
> +
> + way_size = size / sets;
Going back to this one: Isn't (size / sets) the set-size rather
than the way-size?
After we discussed this on IRC, I had expected a calculation like
set_size = size / sets;
ways = set_size / line_size;
way_size = size / ways;
Arnd
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 5/7 v6] ARM: l2c: parse 'cache-size' and 'cache-sets' properties
@ 2014-09-08 12:20 ` Arnd Bergmann
0 siblings, 0 replies; 46+ messages in thread
From: Arnd Bergmann @ 2014-09-08 12:20 UTC (permalink / raw)
To: linux-arm-kernel
On Monday 08 September 2014 13:38:04 Linus Walleij wrote:
> + of_property_read_u32(np, "cache-size", &size);
> + of_property_read_u32(np, "cache-sets", &sets);
> +
> + if (!size || !sets)
> + return;
> +
> + way_size = size / sets;
Going back to this one: Isn't (size / sets) the set-size rather
than the way-size?
After we discussed this on IRC, I had expected a calculation like
set_size = size / sets;
ways = set_size / line_size;
way_size = size / ways;
Arnd
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 5/7 v6] ARM: l2c: parse 'cache-size' and 'cache-sets' properties
2014-09-08 12:20 ` Arnd Bergmann
@ 2014-09-08 12:36 ` Linus Walleij
-1 siblings, 0 replies; 46+ messages in thread
From: Linus Walleij @ 2014-09-08 12:36 UTC (permalink / raw)
To: Arnd Bergmann, Florian Fainelli
Cc: linux-arm-kernel, devicetree, linux-leds, linux-pm, Pawel Moll,
Mark Rutland, Marc Zyngier, Will Deacon, Rob Herring
On Mon, Sep 8, 2014 at 2:20 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday 08 September 2014 13:38:04 Linus Walleij wrote:
>> + of_property_read_u32(np, "cache-size", &size);
>> + of_property_read_u32(np, "cache-sets", &sets);
>> +
>> + if (!size || !sets)
>> + return;
>> +
>> + way_size = size / sets;
>
> Going back to this one: Isn't (size / sets) the set-size rather
> than the way-size?
>
> After we discussed this on IRC, I had expected a calculation like
>
> set_size = size / sets;
> ways = set_size / line_size;
> way_size = size / ways;
First: in this PB1176 case:
set_size = 128K/8 = 16K
ways = 16K/32 = 512 bytes
way_size = 128K/512 = 128 bytes
Well maybe it's the ARM reference manual internal lingo that
is actually causing the confusion here. It will say something
like:
[19:17] Way-size 3’b000 = Reserved, internally mapped to 16KB
3’b001 = 16KB, this is the default value
3’b010 = 32KB
3’b011 = 64KB
3’b100 = 128KB
3’b101 = 256KB
3’b110 to 3’b111 = Reserved, internally mapped to 256 KB
OK way-size ... is in the 16 thru 256KB range, which fits nicely
with set size incidentally. And also corresponds to current
comments in the code such as this from
arch/arm/mach-realview/realview_pb1176.c:
#ifdef CONFIG_CACHE_L2X0
/*
* The PL220 needs to be manually configured as the hardware
* doesn't report the correct sizes.
* 128kB (16kB/way), 8-way associativity, event monitor and
* parity enabled, ignore share bit, no force write allocate
* Bits: .... ...0 0111 0011 0000 .... .... ....
*/
l2x0_init(__io_address(REALVIEW_PB1176_L220_BASE), 0x00730000,
0xfe000fff);
#endif
I can add a comment explaining that ARMs terminology does
not match the academic terminology or something, and say that
the thing we poke into "way-size" is actually "set size", if we agree
that is what we're seeing here.
Florian: what was your interpretation?
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 5/7 v6] ARM: l2c: parse 'cache-size' and 'cache-sets' properties
@ 2014-09-08 12:36 ` Linus Walleij
0 siblings, 0 replies; 46+ messages in thread
From: Linus Walleij @ 2014-09-08 12:36 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Sep 8, 2014 at 2:20 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday 08 September 2014 13:38:04 Linus Walleij wrote:
>> + of_property_read_u32(np, "cache-size", &size);
>> + of_property_read_u32(np, "cache-sets", &sets);
>> +
>> + if (!size || !sets)
>> + return;
>> +
>> + way_size = size / sets;
>
> Going back to this one: Isn't (size / sets) the set-size rather
> than the way-size?
>
> After we discussed this on IRC, I had expected a calculation like
>
> set_size = size / sets;
> ways = set_size / line_size;
> way_size = size / ways;
First: in this PB1176 case:
set_size = 128K/8 = 16K
ways = 16K/32 = 512 bytes
way_size = 128K/512 = 128 bytes
Well maybe it's the ARM reference manual internal lingo that
is actually causing the confusion here. It will say something
like:
[19:17] Way-size 3?b000 = Reserved, internally mapped to 16KB
3?b001 = 16KB, this is the default value
3?b010 = 32KB
3?b011 = 64KB
3?b100 = 128KB
3?b101 = 256KB
3?b110 to 3?b111 = Reserved, internally mapped to 256 KB
OK way-size ... is in the 16 thru 256KB range, which fits nicely
with set size incidentally. And also corresponds to current
comments in the code such as this from
arch/arm/mach-realview/realview_pb1176.c:
#ifdef CONFIG_CACHE_L2X0
/*
* The PL220 needs to be manually configured as the hardware
* doesn't report the correct sizes.
* 128kB (16kB/way), 8-way associativity, event monitor and
* parity enabled, ignore share bit, no force write allocate
* Bits: .... ...0 0111 0011 0000 .... .... ....
*/
l2x0_init(__io_address(REALVIEW_PB1176_L220_BASE), 0x00730000,
0xfe000fff);
#endif
I can add a comment explaining that ARMs terminology does
not match the academic terminology or something, and say that
the thing we poke into "way-size" is actually "set size", if we agree
that is what we're seeing here.
Florian: what was your interpretation?
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 6/7 v6] ARM: l2x0: calculate associativity from ePAPR cache props
2014-09-08 12:15 ` Arnd Bergmann
@ 2014-09-08 12:43 ` Linus Walleij
-1 siblings, 0 replies; 46+ messages in thread
From: Linus Walleij @ 2014-09-08 12:43 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, devicetree, linux-leds, linux-pm, Pawel Moll,
Mark Rutland, Marc Zyngier, Will Deacon, Rob Herring
On Mon, Sep 8, 2014 at 2:15 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday 08 September 2014 13:38:05 Linus Walleij wrote:
>> static void __init l2x0_cache_size_of_parse(const struct device_node *np,
>> u32 *aux_val, u32 *aux_mask,
>> - u32 max_way_size)
>> + u32 max_way_size,
>> + u32 max_associativity)
>> {
>> u32 mask = 0, val = 0;
>> u32 size = 0, sets = 0;
>> u32 way_size = 0, way_size_bits = 1;
>> + u32 linesize = 0;
>> + u32 assoc = 0;
>>
>> of_property_read_u32(np, "cache-size", &size);
>> of_property_read_u32(np, "cache-sets", &sets);
>> + of_property_read_u32(np, "cache-line-size", &linesize);
>>
>
> If I read ePAPR correctly, you have to read "cache-block-size" as well, and
> use that as a fallback if "cache-line-size" is not provided. The line size
> is only required to be in the DT if it's different from the block size.
OK fixed this...
>> if (way_size > max_way_size) {
>> - pr_warn("L2C: way size %dKB is too large\n", way_size >> 10);
>> + pr_warn("L2C OF: way size %dKB is too large\n", way_size >> 10);
>> return;
>> }
>>
>> + /* All these l2 caches have the same line size actually */
>> + if (!linesize)
>> + linesize = CACHE_LINE_SIZE;
>> + if (linesize != CACHE_LINE_SIZE)
>> + pr_warn("L2C OF: DT supplied line size %d bytes does "
>> + "not match hardware line size of %d bytes\n",
>> + linesize,
>> + CACHE_LINE_SIZE);
>
> and CACHE_LINE_SIZE seems to be what ePAPR calls cache-block-size, i.e.
> the fundamental unit of cache management as seen from the CPU, independent
> of how it is physically organized.
Yeah. Well, actually that means the variable in cache-l2x0.c should
be renamed from CACHE_LINE_SIZE to CACHE_BLOCK_SIZE
if we go with that terminology, right? That is the real change that
is needed to make terminology consistent then.
>> + /*
>> + * This cache is set associative. By increasing associativity
>> + * we increase the number of blocks per set. Usually this
>> + * quickly hits the roof at 8 or 16 ways of associativity.
>> + */
>> + assoc = way_size / linesize;
>> + if (assoc > max_associativity)
>> + assoc = max_associativity;
>> +
>
> I don't see what this helps us. Doesn't this silently try to fix up
> incorrect device trees?
I will look closer... But whatever comes out of the calculation
is always way about 8 or even 16. Probably my arithmetics
get it wrong because of terminology confusion. With the
definitions from your previous mail, maybe it all ends up
correctly. I'll hack around a bit and see.
>> + } else {
>> + if (sets == 1)
>> + /* Direct-mapped cache */
>> + assoc = 1;
>> + val |= (assoc << L2X0_AUX_CTRL_ASSOC_SHIFT);
>> + }
>
> This looks wrong: isn't "sets==1" fully associative rather than
> direct-mapped?
Yep. I'll fix.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 6/7 v6] ARM: l2x0: calculate associativity from ePAPR cache props
@ 2014-09-08 12:43 ` Linus Walleij
0 siblings, 0 replies; 46+ messages in thread
From: Linus Walleij @ 2014-09-08 12:43 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Sep 8, 2014 at 2:15 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday 08 September 2014 13:38:05 Linus Walleij wrote:
>> static void __init l2x0_cache_size_of_parse(const struct device_node *np,
>> u32 *aux_val, u32 *aux_mask,
>> - u32 max_way_size)
>> + u32 max_way_size,
>> + u32 max_associativity)
>> {
>> u32 mask = 0, val = 0;
>> u32 size = 0, sets = 0;
>> u32 way_size = 0, way_size_bits = 1;
>> + u32 linesize = 0;
>> + u32 assoc = 0;
>>
>> of_property_read_u32(np, "cache-size", &size);
>> of_property_read_u32(np, "cache-sets", &sets);
>> + of_property_read_u32(np, "cache-line-size", &linesize);
>>
>
> If I read ePAPR correctly, you have to read "cache-block-size" as well, and
> use that as a fallback if "cache-line-size" is not provided. The line size
> is only required to be in the DT if it's different from the block size.
OK fixed this...
>> if (way_size > max_way_size) {
>> - pr_warn("L2C: way size %dKB is too large\n", way_size >> 10);
>> + pr_warn("L2C OF: way size %dKB is too large\n", way_size >> 10);
>> return;
>> }
>>
>> + /* All these l2 caches have the same line size actually */
>> + if (!linesize)
>> + linesize = CACHE_LINE_SIZE;
>> + if (linesize != CACHE_LINE_SIZE)
>> + pr_warn("L2C OF: DT supplied line size %d bytes does "
>> + "not match hardware line size of %d bytes\n",
>> + linesize,
>> + CACHE_LINE_SIZE);
>
> and CACHE_LINE_SIZE seems to be what ePAPR calls cache-block-size, i.e.
> the fundamental unit of cache management as seen from the CPU, independent
> of how it is physically organized.
Yeah. Well, actually that means the variable in cache-l2x0.c should
be renamed from CACHE_LINE_SIZE to CACHE_BLOCK_SIZE
if we go with that terminology, right? That is the real change that
is needed to make terminology consistent then.
>> + /*
>> + * This cache is set associative. By increasing associativity
>> + * we increase the number of blocks per set. Usually this
>> + * quickly hits the roof at 8 or 16 ways of associativity.
>> + */
>> + assoc = way_size / linesize;
>> + if (assoc > max_associativity)
>> + assoc = max_associativity;
>> +
>
> I don't see what this helps us. Doesn't this silently try to fix up
> incorrect device trees?
I will look closer... But whatever comes out of the calculation
is always way about 8 or even 16. Probably my arithmetics
get it wrong because of terminology confusion. With the
definitions from your previous mail, maybe it all ends up
correctly. I'll hack around a bit and see.
>> + } else {
>> + if (sets == 1)
>> + /* Direct-mapped cache */
>> + assoc = 1;
>> + val |= (assoc << L2X0_AUX_CTRL_ASSOC_SHIFT);
>> + }
>
> This looks wrong: isn't "sets==1" fully associative rather than
> direct-mapped?
Yep. I'll fix.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 5/7 v6] ARM: l2c: parse 'cache-size' and 'cache-sets' properties
2014-09-08 12:36 ` Linus Walleij
@ 2014-09-08 13:16 ` Arnd Bergmann
-1 siblings, 0 replies; 46+ messages in thread
From: Arnd Bergmann @ 2014-09-08 13:16 UTC (permalink / raw)
To: Linus Walleij
Cc: Florian Fainelli, linux-arm-kernel, devicetree, linux-leds,
linux-pm, Pawel Moll, Mark Rutland, Marc Zyngier, Will Deacon,
Rob Herring
On Monday 08 September 2014 14:36:48 Linus Walleij wrote:
> On Mon, Sep 8, 2014 at 2:20 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Monday 08 September 2014 13:38:04 Linus Walleij wrote:
> >> + of_property_read_u32(np, "cache-size", &size);
> >> + of_property_read_u32(np, "cache-sets", &sets);
> >> +
> >> + if (!size || !sets)
> >> + return;
> >> +
> >> + way_size = size / sets;
> >
> > Going back to this one: Isn't (size / sets) the set-size rather
> > than the way-size?
> >
> > After we discussed this on IRC, I had expected a calculation like
> >
> > set_size = size / sets;
> > ways = set_size / line_size;
> > way_size = size / ways;
>
> First: in this PB1176 case:
>
> set_size = 128K/8 = 16K
> ways = 16K/32 = 512 bytes
> way_size = 128K/512 = 128 bytes
I guess we should first try to find the right units so we know what
we are talking about. I was under the impression that the set size
is the number of bytes in a set, while 'ways' is counting the
associativity and has no unit.
The last line also seems to incorrectly computed. Dividing 128KB
by 512 bytes should be 256 (no unit).
> Well maybe it's the ARM reference manual internal lingo that
> is actually causing the confusion here. It will say something
> like:
>
> [19:17] Way-size 3’b000 = Reserved, internally mapped to 16KB
> 3’b001 = 16KB, this is the default value
> 3’b010 = 32KB
> 3’b011 = 64KB
> 3’b100 = 128KB
> 3’b101 = 256KB
> 3’b110 to 3’b111 = Reserved, internally mapped to 256 KB
>
> OK way-size ... is in the 16 thru 256KB range, which fits nicely
> with set size incidentally. And also corresponds to current
> comments in the code such as this from
> arch/arm/mach-realview/realview_pb1176.c:
>
> #ifdef CONFIG_CACHE_L2X0
> /*
> * The PL220 needs to be manually configured as the hardware
> * doesn't report the correct sizes.
> * 128kB (16kB/way), 8-way associativity, event monitor and
> * parity enabled, ignore share bit, no force write allocate
> * Bits: .... ...0 0111 0011 0000 .... .... ....
> */
> l2x0_init(__io_address(REALVIEW_PB1176_L220_BASE), 0x00730000,
> 0xfe000fff);
> #endif
16KB way-size seems realistic, yes.
> I can add a comment explaining that ARMs terminology does
> not match the academic terminology or something, and say that
> the thing we poke into "way-size" is actually "set size", if we agree
> that is what we're seeing here.
Let's see again: 16KB way-size * 8 ways = 128KB, that seems correct.
16KB way-size / 32B line-size = 512 sets, that also seems realistic.
128KB cache-size / 512 sets = 256B set-size. 256B / 32B = 8 ways,
so everything fits together.
Now in the code:
+ of_property_read_u32(np, "cache-size", &size);
131072
+ of_property_read_u32(np, "cache-sets", &sets);
512
+
+ if (!size || !sets)
+ return;
+
+ way_size = size / sets;
256 -> impossible.
set_size = size / sets;
256
ways = set_size / line_size;
8
way_size = size / ways;
16KB -> ok
Arnd
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 5/7 v6] ARM: l2c: parse 'cache-size' and 'cache-sets' properties
@ 2014-09-08 13:16 ` Arnd Bergmann
0 siblings, 0 replies; 46+ messages in thread
From: Arnd Bergmann @ 2014-09-08 13:16 UTC (permalink / raw)
To: linux-arm-kernel
On Monday 08 September 2014 14:36:48 Linus Walleij wrote:
> On Mon, Sep 8, 2014 at 2:20 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Monday 08 September 2014 13:38:04 Linus Walleij wrote:
> >> + of_property_read_u32(np, "cache-size", &size);
> >> + of_property_read_u32(np, "cache-sets", &sets);
> >> +
> >> + if (!size || !sets)
> >> + return;
> >> +
> >> + way_size = size / sets;
> >
> > Going back to this one: Isn't (size / sets) the set-size rather
> > than the way-size?
> >
> > After we discussed this on IRC, I had expected a calculation like
> >
> > set_size = size / sets;
> > ways = set_size / line_size;
> > way_size = size / ways;
>
> First: in this PB1176 case:
>
> set_size = 128K/8 = 16K
> ways = 16K/32 = 512 bytes
> way_size = 128K/512 = 128 bytes
I guess we should first try to find the right units so we know what
we are talking about. I was under the impression that the set size
is the number of bytes in a set, while 'ways' is counting the
associativity and has no unit.
The last line also seems to incorrectly computed. Dividing 128KB
by 512 bytes should be 256 (no unit).
> Well maybe it's the ARM reference manual internal lingo that
> is actually causing the confusion here. It will say something
> like:
>
> [19:17] Way-size 3?b000 = Reserved, internally mapped to 16KB
> 3?b001 = 16KB, this is the default value
> 3?b010 = 32KB
> 3?b011 = 64KB
> 3?b100 = 128KB
> 3?b101 = 256KB
> 3?b110 to 3?b111 = Reserved, internally mapped to 256 KB
>
> OK way-size ... is in the 16 thru 256KB range, which fits nicely
> with set size incidentally. And also corresponds to current
> comments in the code such as this from
> arch/arm/mach-realview/realview_pb1176.c:
>
> #ifdef CONFIG_CACHE_L2X0
> /*
> * The PL220 needs to be manually configured as the hardware
> * doesn't report the correct sizes.
> * 128kB (16kB/way), 8-way associativity, event monitor and
> * parity enabled, ignore share bit, no force write allocate
> * Bits: .... ...0 0111 0011 0000 .... .... ....
> */
> l2x0_init(__io_address(REALVIEW_PB1176_L220_BASE), 0x00730000,
> 0xfe000fff);
> #endif
16KB way-size seems realistic, yes.
> I can add a comment explaining that ARMs terminology does
> not match the academic terminology or something, and say that
> the thing we poke into "way-size" is actually "set size", if we agree
> that is what we're seeing here.
Let's see again: 16KB way-size * 8 ways = 128KB, that seems correct.
16KB way-size / 32B line-size = 512 sets, that also seems realistic.
128KB cache-size / 512 sets = 256B set-size. 256B / 32B = 8 ways,
so everything fits together.
Now in the code:
+ of_property_read_u32(np, "cache-size", &size);
131072
+ of_property_read_u32(np, "cache-sets", &sets);
512
+
+ if (!size || !sets)
+ return;
+
+ way_size = size / sets;
256 -> impossible.
set_size = size / sets;
256
ways = set_size / line_size;
8
way_size = size / ways;
16KB -> ok
Arnd
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 6/7 v6] ARM: l2x0: calculate associativity from ePAPR cache props
2014-09-08 12:43 ` Linus Walleij
@ 2014-09-08 13:18 ` Arnd Bergmann
-1 siblings, 0 replies; 46+ messages in thread
From: Arnd Bergmann @ 2014-09-08 13:18 UTC (permalink / raw)
To: Linus Walleij
Cc: linux-arm-kernel, devicetree, linux-leds, linux-pm, Pawel Moll,
Mark Rutland, Marc Zyngier, Will Deacon, Rob Herring
On Monday 08 September 2014 14:43:55 Linus Walleij wrote:
>
> >
> > and CACHE_LINE_SIZE seems to be what ePAPR calls cache-block-size, i.e.
> > the fundamental unit of cache management as seen from the CPU, independent
> > of how it is physically organized.
>
> Yeah. Well, actually that means the variable in cache-l2x0.c should
> be renamed from CACHE_LINE_SIZE to CACHE_BLOCK_SIZE
> if we go with that terminology, right? That is the real change that
> is needed to make terminology consistent then.
Not sure if it's worth it. It may be a case of IBM terminology being
at odds with ARM terminology. ;-)
Arnd
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 6/7 v6] ARM: l2x0: calculate associativity from ePAPR cache props
@ 2014-09-08 13:18 ` Arnd Bergmann
0 siblings, 0 replies; 46+ messages in thread
From: Arnd Bergmann @ 2014-09-08 13:18 UTC (permalink / raw)
To: linux-arm-kernel
On Monday 08 September 2014 14:43:55 Linus Walleij wrote:
>
> >
> > and CACHE_LINE_SIZE seems to be what ePAPR calls cache-block-size, i.e.
> > the fundamental unit of cache management as seen from the CPU, independent
> > of how it is physically organized.
>
> Yeah. Well, actually that means the variable in cache-l2x0.c should
> be renamed from CACHE_LINE_SIZE to CACHE_BLOCK_SIZE
> if we go with that terminology, right? That is the real change that
> is needed to make terminology consistent then.
Not sure if it's worth it. It may be a case of IBM terminology being
at odds with ARM terminology. ;-)
Arnd
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 5/7 v6] ARM: l2c: parse 'cache-size' and 'cache-sets' properties
2014-09-08 12:36 ` Linus Walleij
@ 2014-09-08 19:57 ` Florian Fainelli
-1 siblings, 0 replies; 46+ messages in thread
From: Florian Fainelli @ 2014-09-08 19:57 UTC (permalink / raw)
To: Linus Walleij, Arnd Bergmann
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-leds-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA, Pawel Moll, Mark Rutland,
Marc Zyngier, Will Deacon, Rob Herring
On 09/08/2014 05:36 AM, Linus Walleij wrote:
> On Mon, Sep 8, 2014 at 2:20 PM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
>> On Monday 08 September 2014 13:38:04 Linus Walleij wrote:
>>> + of_property_read_u32(np, "cache-size", &size);
>>> + of_property_read_u32(np, "cache-sets", &sets);
>>> +
>>> + if (!size || !sets)
>>> + return;
>>> +
>>> + way_size = size / sets;
>>
>> Going back to this one: Isn't (size / sets) the set-size rather
>> than the way-size?
>>
>> After we discussed this on IRC, I had expected a calculation like
>>
>> set_size = size / sets;
>> ways = set_size / line_size;
>> way_size = size / ways;
>
> First: in this PB1176 case:
>
> set_size = 128K/8 = 16K
> ways = 16K/32 = 512 bytes
> way_size = 128K/512 = 128 bytes
>
> Well maybe it's the ARM reference manual internal lingo that
> is actually causing the confusion here. It will say something
> like:
>
> [19:17] Way-size 3’b000 = Reserved, internally mapped to 16KB
> 3’b001 = 16KB, this is the default value
> 3’b010 = 32KB
> 3’b011 = 64KB
> 3’b100 = 128KB
> 3’b101 = 256KB
> 3’b110 to 3’b111 = Reserved, internally mapped to 256 KB
>
> OK way-size ... is in the 16 thru 256KB range, which fits nicely
> with set size incidentally. And also corresponds to current
> comments in the code such as this from
> arch/arm/mach-realview/realview_pb1176.c:
>
> #ifdef CONFIG_CACHE_L2X0
> /*
> * The PL220 needs to be manually configured as the hardware
> * doesn't report the correct sizes.
> * 128kB (16kB/way), 8-way associativity, event monitor and
> * parity enabled, ignore share bit, no force write allocate
> * Bits: .... ...0 0111 0011 0000 .... .... ....
> */
> l2x0_init(__io_address(REALVIEW_PB1176_L220_BASE), 0x00730000,
> 0xfe000fff);
> #endif
>
> I can add a comment explaining that ARMs terminology does
> not match the academic terminology or something, and say that
> the thing we poke into "way-size" is actually "set size", if we agree
> that is what we're seeing here.
>
> Florian: what was your interpretation?
Yes that was my interpretation as well, that we could have 'way-size'
and 'set-size' be the same things here, now that I re-think about it, I
am not sure anymore. More to follow on Arnd's reply to this email.
--
Florian
--
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] 46+ messages in thread
* [PATCH 5/7 v6] ARM: l2c: parse 'cache-size' and 'cache-sets' properties
@ 2014-09-08 19:57 ` Florian Fainelli
0 siblings, 0 replies; 46+ messages in thread
From: Florian Fainelli @ 2014-09-08 19:57 UTC (permalink / raw)
To: linux-arm-kernel
On 09/08/2014 05:36 AM, Linus Walleij wrote:
> On Mon, Sep 8, 2014 at 2:20 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Monday 08 September 2014 13:38:04 Linus Walleij wrote:
>>> + of_property_read_u32(np, "cache-size", &size);
>>> + of_property_read_u32(np, "cache-sets", &sets);
>>> +
>>> + if (!size || !sets)
>>> + return;
>>> +
>>> + way_size = size / sets;
>>
>> Going back to this one: Isn't (size / sets) the set-size rather
>> than the way-size?
>>
>> After we discussed this on IRC, I had expected a calculation like
>>
>> set_size = size / sets;
>> ways = set_size / line_size;
>> way_size = size / ways;
>
> First: in this PB1176 case:
>
> set_size = 128K/8 = 16K
> ways = 16K/32 = 512 bytes
> way_size = 128K/512 = 128 bytes
>
> Well maybe it's the ARM reference manual internal lingo that
> is actually causing the confusion here. It will say something
> like:
>
> [19:17] Way-size 3?b000 = Reserved, internally mapped to 16KB
> 3?b001 = 16KB, this is the default value
> 3?b010 = 32KB
> 3?b011 = 64KB
> 3?b100 = 128KB
> 3?b101 = 256KB
> 3?b110 to 3?b111 = Reserved, internally mapped to 256 KB
>
> OK way-size ... is in the 16 thru 256KB range, which fits nicely
> with set size incidentally. And also corresponds to current
> comments in the code such as this from
> arch/arm/mach-realview/realview_pb1176.c:
>
> #ifdef CONFIG_CACHE_L2X0
> /*
> * The PL220 needs to be manually configured as the hardware
> * doesn't report the correct sizes.
> * 128kB (16kB/way), 8-way associativity, event monitor and
> * parity enabled, ignore share bit, no force write allocate
> * Bits: .... ...0 0111 0011 0000 .... .... ....
> */
> l2x0_init(__io_address(REALVIEW_PB1176_L220_BASE), 0x00730000,
> 0xfe000fff);
> #endif
>
> I can add a comment explaining that ARMs terminology does
> not match the academic terminology or something, and say that
> the thing we poke into "way-size" is actually "set size", if we agree
> that is what we're seeing here.
>
> Florian: what was your interpretation?
Yes that was my interpretation as well, that we could have 'way-size'
and 'set-size' be the same things here, now that I re-think about it, I
am not sure anymore. More to follow on Arnd's reply to this email.
--
Florian
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 5/7 v6] ARM: l2c: parse 'cache-size' and 'cache-sets' properties
2014-09-08 13:16 ` Arnd Bergmann
@ 2014-09-08 20:33 ` Florian Fainelli
-1 siblings, 0 replies; 46+ messages in thread
From: Florian Fainelli @ 2014-09-08 20:33 UTC (permalink / raw)
To: Arnd Bergmann, Linus Walleij
Cc: Mark Rutland, devicetree, Pawel Moll, linux-pm, Marc Zyngier,
Will Deacon, linux-arm-kernel, Rob Herring, linux-leds
On 09/08/2014 06:16 AM, Arnd Bergmann wrote:
> On Monday 08 September 2014 14:36:48 Linus Walleij wrote:
>> On Mon, Sep 8, 2014 at 2:20 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>>> On Monday 08 September 2014 13:38:04 Linus Walleij wrote:
>>>> + of_property_read_u32(np, "cache-size", &size);
>>>> + of_property_read_u32(np, "cache-sets", &sets);
>>>> +
>>>> + if (!size || !sets)
>>>> + return;
>>>> +
>>>> + way_size = size / sets;
>>>
>>> Going back to this one: Isn't (size / sets) the set-size rather
>>> than the way-size?
>>>
>>> After we discussed this on IRC, I had expected a calculation like
>>>
>>> set_size = size / sets;
>>> ways = set_size / line_size;
>>> way_size = size / ways;
>>
>> First: in this PB1176 case:
>>
>> set_size = 128K/8 = 16K
>> ways = 16K/32 = 512 bytes
>> way_size = 128K/512 = 128 bytes
>
> I guess we should first try to find the right units so we know what
> we are talking about. I was under the impression that the set size
> is the number of bytes in a set, while 'ways' is counting the
> associativity and has no unit.
I agree with that.
>
> The last line also seems to incorrectly computed. Dividing 128KB
> by 512 bytes should be 256 (no unit).
>
>> Well maybe it's the ARM reference manual internal lingo that
>> is actually causing the confusion here. It will say something
>> like:
>>
>> [19:17] Way-size 3’b000 = Reserved, internally mapped to 16KB
>> 3’b001 = 16KB, this is the default value
>> 3’b010 = 32KB
>> 3’b011 = 64KB
>> 3’b100 = 128KB
>> 3’b101 = 256KB
>> 3’b110 to 3’b111 = Reserved, internally mapped to 256 KB
>>
>> OK way-size ... is in the 16 thru 256KB range, which fits nicely
>> with set size incidentally. And also corresponds to current
>> comments in the code such as this from
>> arch/arm/mach-realview/realview_pb1176.c:
>>
>> #ifdef CONFIG_CACHE_L2X0
>> /*
>> * The PL220 needs to be manually configured as the hardware
>> * doesn't report the correct sizes.
>> * 128kB (16kB/way), 8-way associativity, event monitor and
>> * parity enabled, ignore share bit, no force write allocate
>> * Bits: .... ...0 0111 0011 0000 .... .... ....
>> */
>> l2x0_init(__io_address(REALVIEW_PB1176_L220_BASE), 0x00730000,
>> 0xfe000fff);
>> #endif
>
> 16KB way-size seems realistic, yes.
>
>> I can add a comment explaining that ARMs terminology does
>> not match the academic terminology or something, and say that
>> the thing we poke into "way-size" is actually "set size", if we agree
>> that is what we're seeing here.
>
> Let's see again: 16KB way-size * 8 ways = 128KB, that seems correct.
> 16KB way-size / 32B line-size = 512 sets, that also seems realistic.
> 128KB cache-size / 512 sets = 256B set-size. 256B / 32B = 8 ways,
> so everything fits together.
>
> Now in the code:
>
> + of_property_read_u32(np, "cache-size", &size);
>
> 131072
>
> + of_property_read_u32(np, "cache-sets", &sets);
>
> 512
>
> +
> + if (!size || !sets)
> + return;
> +
> + way_size = size / sets;
>
> 256 -> impossible.
>
>
> set_size = size / sets;
>
> 256
>
> ways = set_size / line_size;
>
> 8
>
> way_size = size / ways;
>
> 16KB -> ok
So what we are missing right now is just a 'cache-line-size' property to
get the maths right.
--
Florian
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 5/7 v6] ARM: l2c: parse 'cache-size' and 'cache-sets' properties
@ 2014-09-08 20:33 ` Florian Fainelli
0 siblings, 0 replies; 46+ messages in thread
From: Florian Fainelli @ 2014-09-08 20:33 UTC (permalink / raw)
To: linux-arm-kernel
On 09/08/2014 06:16 AM, Arnd Bergmann wrote:
> On Monday 08 September 2014 14:36:48 Linus Walleij wrote:
>> On Mon, Sep 8, 2014 at 2:20 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>>> On Monday 08 September 2014 13:38:04 Linus Walleij wrote:
>>>> + of_property_read_u32(np, "cache-size", &size);
>>>> + of_property_read_u32(np, "cache-sets", &sets);
>>>> +
>>>> + if (!size || !sets)
>>>> + return;
>>>> +
>>>> + way_size = size / sets;
>>>
>>> Going back to this one: Isn't (size / sets) the set-size rather
>>> than the way-size?
>>>
>>> After we discussed this on IRC, I had expected a calculation like
>>>
>>> set_size = size / sets;
>>> ways = set_size / line_size;
>>> way_size = size / ways;
>>
>> First: in this PB1176 case:
>>
>> set_size = 128K/8 = 16K
>> ways = 16K/32 = 512 bytes
>> way_size = 128K/512 = 128 bytes
>
> I guess we should first try to find the right units so we know what
> we are talking about. I was under the impression that the set size
> is the number of bytes in a set, while 'ways' is counting the
> associativity and has no unit.
I agree with that.
>
> The last line also seems to incorrectly computed. Dividing 128KB
> by 512 bytes should be 256 (no unit).
>
>> Well maybe it's the ARM reference manual internal lingo that
>> is actually causing the confusion here. It will say something
>> like:
>>
>> [19:17] Way-size 3?b000 = Reserved, internally mapped to 16KB
>> 3?b001 = 16KB, this is the default value
>> 3?b010 = 32KB
>> 3?b011 = 64KB
>> 3?b100 = 128KB
>> 3?b101 = 256KB
>> 3?b110 to 3?b111 = Reserved, internally mapped to 256 KB
>>
>> OK way-size ... is in the 16 thru 256KB range, which fits nicely
>> with set size incidentally. And also corresponds to current
>> comments in the code such as this from
>> arch/arm/mach-realview/realview_pb1176.c:
>>
>> #ifdef CONFIG_CACHE_L2X0
>> /*
>> * The PL220 needs to be manually configured as the hardware
>> * doesn't report the correct sizes.
>> * 128kB (16kB/way), 8-way associativity, event monitor and
>> * parity enabled, ignore share bit, no force write allocate
>> * Bits: .... ...0 0111 0011 0000 .... .... ....
>> */
>> l2x0_init(__io_address(REALVIEW_PB1176_L220_BASE), 0x00730000,
>> 0xfe000fff);
>> #endif
>
> 16KB way-size seems realistic, yes.
>
>> I can add a comment explaining that ARMs terminology does
>> not match the academic terminology or something, and say that
>> the thing we poke into "way-size" is actually "set size", if we agree
>> that is what we're seeing here.
>
> Let's see again: 16KB way-size * 8 ways = 128KB, that seems correct.
> 16KB way-size / 32B line-size = 512 sets, that also seems realistic.
> 128KB cache-size / 512 sets = 256B set-size. 256B / 32B = 8 ways,
> so everything fits together.
>
> Now in the code:
>
> + of_property_read_u32(np, "cache-size", &size);
>
> 131072
>
> + of_property_read_u32(np, "cache-sets", &sets);
>
> 512
>
> +
> + if (!size || !sets)
> + return;
> +
> + way_size = size / sets;
>
> 256 -> impossible.
>
>
> set_size = size / sets;
>
> 256
>
> ways = set_size / line_size;
>
> 8
>
> way_size = size / ways;
>
> 16KB -> ok
So what we are missing right now is just a 'cache-line-size' property to
get the maths right.
--
Florian
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 5/7 v6] ARM: l2c: parse 'cache-size' and 'cache-sets' properties
2014-09-08 20:33 ` Florian Fainelli
@ 2014-09-08 20:41 ` Arnd Bergmann
-1 siblings, 0 replies; 46+ messages in thread
From: Arnd Bergmann @ 2014-09-08 20:41 UTC (permalink / raw)
To: Florian Fainelli
Cc: Linus Walleij, Mark Rutland, devicetree, Pawel Moll, linux-pm,
Marc Zyngier, Will Deacon, linux-arm-kernel, Rob Herring,
linux-leds
On Monday 08 September 2014 13:33:39 Florian Fainelli wrote:
> So what we are missing right now is just a 'cache-line-size' property to
> get the maths right.
Patch 6/7 actually adds that already, and it's even required by ePAPR.
Arnd
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 5/7 v6] ARM: l2c: parse 'cache-size' and 'cache-sets' properties
@ 2014-09-08 20:41 ` Arnd Bergmann
0 siblings, 0 replies; 46+ messages in thread
From: Arnd Bergmann @ 2014-09-08 20:41 UTC (permalink / raw)
To: linux-arm-kernel
On Monday 08 September 2014 13:33:39 Florian Fainelli wrote:
> So what we are missing right now is just a 'cache-line-size' property to
> get the maths right.
Patch 6/7 actually adds that already, and it's even required by ePAPR.
Arnd
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 5/7 v6] ARM: l2c: parse 'cache-size' and 'cache-sets' properties
2014-09-08 13:16 ` Arnd Bergmann
@ 2014-09-09 7:14 ` Linus Walleij
-1 siblings, 0 replies; 46+ messages in thread
From: Linus Walleij @ 2014-09-09 7:14 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Florian Fainelli, linux-arm-kernel, devicetree, linux-leds,
linux-pm, Pawel Moll, Mark Rutland, Marc Zyngier, Will Deacon,
Rob Herring
On Mon, Sep 8, 2014 at 3:16 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> [Me]
>> I can add a comment explaining that ARMs terminology does
>> not match the academic terminology or something, and say that
>> the thing we poke into "way-size" is actually "set size", if we agree
>> that is what we're seeing here.
>
> Let's see again: 16KB way-size * 8 ways = 128KB, that seems correct.
> 16KB way-size / 32B line-size = 512 sets, that also seems realistic.
> 128KB cache-size / 512 sets = 256B set-size. 256B / 32B = 8 ways,
> so everything fits together.
I've sent a v2 version of the patch using the terminology and calculations
from this thread, and it yields the right numbers, for PB1176, I will check
with the values from other RealView platforms to see if they also give the
same result back.
I had to squash Florians & my patch, it didn't make sense to have them
artificially separate.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 5/7 v6] ARM: l2c: parse 'cache-size' and 'cache-sets' properties
@ 2014-09-09 7:14 ` Linus Walleij
0 siblings, 0 replies; 46+ messages in thread
From: Linus Walleij @ 2014-09-09 7:14 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Sep 8, 2014 at 3:16 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> [Me]
>> I can add a comment explaining that ARMs terminology does
>> not match the academic terminology or something, and say that
>> the thing we poke into "way-size" is actually "set size", if we agree
>> that is what we're seeing here.
>
> Let's see again: 16KB way-size * 8 ways = 128KB, that seems correct.
> 16KB way-size / 32B line-size = 512 sets, that also seems realistic.
> 128KB cache-size / 512 sets = 256B set-size. 256B / 32B = 8 ways,
> so everything fits together.
I've sent a v2 version of the patch using the terminology and calculations
from this thread, and it yields the right numbers, for PB1176, I will check
with the values from other RealView platforms to see if they also give the
same result back.
I had to squash Florians & my patch, it didn't make sense to have them
artificially separate.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 3/7 v6] power: reset: driver for the Versatile syscon reboot
2014-09-08 11:38 ` Linus Walleij
@ 2014-09-12 8:55 ` Linus Walleij
-1 siblings, 0 replies; 46+ messages in thread
From: Linus Walleij @ 2014-09-12 8:55 UTC (permalink / raw)
To: linux-arm-kernel, linux-pm, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse
Cc: Arnd Bergmann, Pawel Moll, Mark Rutland, Marc Zyngier,
Will Deacon, Rob Herring, Linus Walleij
On Mon, Sep 8, 2014 at 1:38 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> This driver enabled us to drive the reboot of the Versatile family
> of ARM reference boards. Even though only the RealView boards are
> supported initially, these boards all have the same procedure for
> reboot:
>
> - Write a magic value into an unlocking register
> - Write another magic value into a reset control register
>
> The driver will be reusable for Versatile and possibly also the
> Integrator family of reference boards.
>
> Cc: Sebastian Reichel <sre@kernel.org>
> Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> Cc: David Woodhouse <dwmw2@infradead.org>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> ChangeLog v1->v2:
> - Do not probe from a platform device, instead use a device_initcall()
> and look up the syscon device from its node. If that device is
> not yet registered, the call will be deferred. This is done so that
> the Linux driver model is not reflected into the device tree, as
> the reboot property of the syscon is not a separate device.
Can any of the power maintainers please ACK this patch if it
looks OK, so it can be pulled in through ARM SoC?
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 3/7 v6] power: reset: driver for the Versatile syscon reboot
@ 2014-09-12 8:55 ` Linus Walleij
0 siblings, 0 replies; 46+ messages in thread
From: Linus Walleij @ 2014-09-12 8:55 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Sep 8, 2014 at 1:38 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> This driver enabled us to drive the reboot of the Versatile family
> of ARM reference boards. Even though only the RealView boards are
> supported initially, these boards all have the same procedure for
> reboot:
>
> - Write a magic value into an unlocking register
> - Write another magic value into a reset control register
>
> The driver will be reusable for Versatile and possibly also the
> Integrator family of reference boards.
>
> Cc: Sebastian Reichel <sre@kernel.org>
> Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> Cc: David Woodhouse <dwmw2@infradead.org>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> ChangeLog v1->v2:
> - Do not probe from a platform device, instead use a device_initcall()
> and look up the syscon device from its node. If that device is
> not yet registered, the call will be deferred. This is done so that
> the Linux driver model is not reflected into the device tree, as
> the reboot property of the syscon is not a separate device.
Can any of the power maintainers please ACK this patch if it
looks OK, so it can be pulled in through ARM SoC?
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 1/7 v6] leds: add a driver for syscon-based LEDs
2014-09-08 11:38 ` Linus Walleij
@ 2014-09-12 8:56 ` Linus Walleij
-1 siblings, 0 replies; 46+ messages in thread
From: Linus Walleij @ 2014-09-12 8:56 UTC (permalink / raw)
To: linux-arm-kernel, linux-leds, Bryan Wu, Richard Purdie
Cc: Arnd Bergmann, Pawel Moll, Mark Rutland, Marc Zyngier,
Will Deacon, Rob Herring, Linus Walleij
On Mon, Sep 8, 2014 at 1:38 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> This makes it possible to create a set of LEDs from a syscon
> MFD instance, which is lean mean and clean on the ARM
> reference designs and can replace the Versatile LEDs driver
> in the long run, as well as other custom syscon LEDs drivers.
>
> Cc: Bryan Wu <cooloney@gmail.com>
> Cc: Richard Purdie <rpurdie@rpsys.net>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> ChangeLog v1->v2:
> - Augment driver to probe all nodes of a syscon to see if they
> are "register-bit-led"s, and then allocate them under the syscon
> if that is the case.
> - Switch compatible string from "syscon-leds" to "register-bit-led"
Bryan can you please ACK this patch if you're OK with it so
it can be pulled in through ARM SoC?
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 1/7 v6] leds: add a driver for syscon-based LEDs
@ 2014-09-12 8:56 ` Linus Walleij
0 siblings, 0 replies; 46+ messages in thread
From: Linus Walleij @ 2014-09-12 8:56 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Sep 8, 2014 at 1:38 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> This makes it possible to create a set of LEDs from a syscon
> MFD instance, which is lean mean and clean on the ARM
> reference designs and can replace the Versatile LEDs driver
> in the long run, as well as other custom syscon LEDs drivers.
>
> Cc: Bryan Wu <cooloney@gmail.com>
> Cc: Richard Purdie <rpurdie@rpsys.net>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> ChangeLog v1->v2:
> - Augment driver to probe all nodes of a syscon to see if they
> are "register-bit-led"s, and then allocate them under the syscon
> if that is the case.
> - Switch compatible string from "syscon-leds" to "register-bit-led"
Bryan can you please ACK this patch if you're OK with it so
it can be pulled in through ARM SoC?
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 3/7 v6] power: reset: driver for the Versatile syscon reboot
2014-09-12 8:55 ` Linus Walleij
@ 2014-09-15 16:06 ` Sebastian Reichel
-1 siblings, 0 replies; 46+ messages in thread
From: Sebastian Reichel @ 2014-09-15 16:06 UTC (permalink / raw)
To: Linus Walleij
Cc: linux-arm-kernel, linux-pm, Dmitry Eremin-Solenikov,
David Woodhouse, Arnd Bergmann, Pawel Moll, Mark Rutland,
Marc Zyngier, Will Deacon, Rob Herring
[-- Attachment #1: Type: text/plain, Size: 1473 bytes --]
On Fri, Sep 12, 2014 at 10:55:19AM +0200, Linus Walleij wrote:
> On Mon, Sep 8, 2014 at 1:38 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> > This driver enabled us to drive the reboot of the Versatile family
> > of ARM reference boards. Even though only the RealView boards are
> > supported initially, these boards all have the same procedure for
> > reboot:
> >
> > - Write a magic value into an unlocking register
> > - Write another magic value into a reset control register
> >
> > The driver will be reusable for Versatile and possibly also the
> > Integrator family of reference boards.
> >
> > Cc: Sebastian Reichel <sre@kernel.org>
> > Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> > Cc: David Woodhouse <dwmw2@infradead.org>
> > Acked-by: Arnd Bergmann <arnd@arndb.de>
> > Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> > ---
> > ChangeLog v1->v2:
> > - Do not probe from a platform device, instead use a device_initcall()
> > and look up the syscon device from its node. If that device is
> > not yet registered, the call will be deferred. This is done so that
> > the Linux driver model is not reflected into the device tree, as
> > the reboot property of the syscon is not a separate device.
>
> Can any of the power maintainers please ACK this patch if it
> looks OK, so it can be pulled in through ARM SoC?
Sorry for the delay:
Acked-By: Sebastian Reichel <sre@kernel.org>
-- Sebastian
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 3/7 v6] power: reset: driver for the Versatile syscon reboot
@ 2014-09-15 16:06 ` Sebastian Reichel
0 siblings, 0 replies; 46+ messages in thread
From: Sebastian Reichel @ 2014-09-15 16:06 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Sep 12, 2014 at 10:55:19AM +0200, Linus Walleij wrote:
> On Mon, Sep 8, 2014 at 1:38 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> > This driver enabled us to drive the reboot of the Versatile family
> > of ARM reference boards. Even though only the RealView boards are
> > supported initially, these boards all have the same procedure for
> > reboot:
> >
> > - Write a magic value into an unlocking register
> > - Write another magic value into a reset control register
> >
> > The driver will be reusable for Versatile and possibly also the
> > Integrator family of reference boards.
> >
> > Cc: Sebastian Reichel <sre@kernel.org>
> > Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> > Cc: David Woodhouse <dwmw2@infradead.org>
> > Acked-by: Arnd Bergmann <arnd@arndb.de>
> > Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> > ---
> > ChangeLog v1->v2:
> > - Do not probe from a platform device, instead use a device_initcall()
> > and look up the syscon device from its node. If that device is
> > not yet registered, the call will be deferred. This is done so that
> > the Linux driver model is not reflected into the device tree, as
> > the reboot property of the syscon is not a separate device.
>
> Can any of the power maintainers please ACK this patch if it
> looks OK, so it can be pulled in through ARM SoC?
Sorry for the delay:
Acked-By: Sebastian Reichel <sre@kernel.org>
-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140915/decd54cf/attachment.sig>
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 1/7 v6] leds: add a driver for syscon-based LEDs
2014-09-12 8:56 ` Linus Walleij
@ 2014-09-18 22:39 ` Linus Walleij
-1 siblings, 0 replies; 46+ messages in thread
From: Linus Walleij @ 2014-09-18 22:39 UTC (permalink / raw)
To: linux-arm-kernel, linux-leds, Bryan Wu, Richard Purdie
Cc: Arnd Bergmann, Pawel Moll, Mark Rutland, Marc Zyngier,
Will Deacon, Rob Herring, Linus Walleij
On Fri, Sep 12, 2014 at 1:56 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Mon, Sep 8, 2014 at 1:38 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>
>> This makes it possible to create a set of LEDs from a syscon
>> MFD instance, which is lean mean and clean on the ARM
>> reference designs and can replace the Versatile LEDs driver
>> in the long run, as well as other custom syscon LEDs drivers.
>>
>> Cc: Bryan Wu <cooloney@gmail.com>
>> Cc: Richard Purdie <rpurdie@rpsys.net>
>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>> ---
>> ChangeLog v1->v2:
>> - Augment driver to probe all nodes of a syscon to see if they
>> are "register-bit-led"s, and then allocate them under the syscon
>> if that is the case.
>> - Switch compatible string from "syscon-leds" to "register-bit-led"
>
> Bryan can you please ACK this patch if you're OK with it so
> it can be pulled in through ARM SoC?
Ping!
I will send a pull request for this soon anyway.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 1/7 v6] leds: add a driver for syscon-based LEDs
@ 2014-09-18 22:39 ` Linus Walleij
0 siblings, 0 replies; 46+ messages in thread
From: Linus Walleij @ 2014-09-18 22:39 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Sep 12, 2014 at 1:56 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Mon, Sep 8, 2014 at 1:38 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>
>> This makes it possible to create a set of LEDs from a syscon
>> MFD instance, which is lean mean and clean on the ARM
>> reference designs and can replace the Versatile LEDs driver
>> in the long run, as well as other custom syscon LEDs drivers.
>>
>> Cc: Bryan Wu <cooloney@gmail.com>
>> Cc: Richard Purdie <rpurdie@rpsys.net>
>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>> ---
>> ChangeLog v1->v2:
>> - Augment driver to probe all nodes of a syscon to see if they
>> are "register-bit-led"s, and then allocate them under the syscon
>> if that is the case.
>> - Switch compatible string from "syscon-leds" to "register-bit-led"
>
> Bryan can you please ACK this patch if you're OK with it so
> it can be pulled in through ARM SoC?
Ping!
I will send a pull request for this soon anyway.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 1/7 v6] leds: add a driver for syscon-based LEDs
2014-09-18 22:39 ` Linus Walleij
@ 2015-01-13 20:19 ` Bryan Wu
-1 siblings, 0 replies; 46+ messages in thread
From: Bryan Wu @ 2015-01-13 20:19 UTC (permalink / raw)
To: Linus Walleij
Cc: linux-arm-kernel, linux-leds, Richard Purdie, Arnd Bergmann,
Pawel Moll, Mark Rutland, Marc Zyngier, Will Deacon, Rob Herring
On Thu, Sep 18, 2014 at 3:39 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Fri, Sep 12, 2014 at 1:56 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
>> On Mon, Sep 8, 2014 at 1:38 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>>
>>> This makes it possible to create a set of LEDs from a syscon
>>> MFD instance, which is lean mean and clean on the ARM
>>> reference designs and can replace the Versatile LEDs driver
>>> in the long run, as well as other custom syscon LEDs drivers.
>>>
>>> Cc: Bryan Wu <cooloney@gmail.com>
>>> Cc: Richard Purdie <rpurdie@rpsys.net>
>>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>>> ---
>>> ChangeLog v1->v2:
>>> - Augment driver to probe all nodes of a syscon to see if they
>>> are "register-bit-led"s, and then allocate them under the syscon
>>> if that is the case.
>>> - Switch compatible string from "syscon-leds" to "register-bit-led"
>>
>> Bryan can you please ACK this patch if you're OK with it so
>> it can be pulled in through ARM SoC?
>
> Ping!
>
> I will send a pull request for this soon anyway.
>
> Yours,
> Linus Walleij
So sorry about this, my Gmail filter out this email. I have no problem
with this.
-Bryan
^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 1/7 v6] leds: add a driver for syscon-based LEDs
@ 2015-01-13 20:19 ` Bryan Wu
0 siblings, 0 replies; 46+ messages in thread
From: Bryan Wu @ 2015-01-13 20:19 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Sep 18, 2014 at 3:39 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Fri, Sep 12, 2014 at 1:56 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
>> On Mon, Sep 8, 2014 at 1:38 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>>
>>> This makes it possible to create a set of LEDs from a syscon
>>> MFD instance, which is lean mean and clean on the ARM
>>> reference designs and can replace the Versatile LEDs driver
>>> in the long run, as well as other custom syscon LEDs drivers.
>>>
>>> Cc: Bryan Wu <cooloney@gmail.com>
>>> Cc: Richard Purdie <rpurdie@rpsys.net>
>>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>>> ---
>>> ChangeLog v1->v2:
>>> - Augment driver to probe all nodes of a syscon to see if they
>>> are "register-bit-led"s, and then allocate them under the syscon
>>> if that is the case.
>>> - Switch compatible string from "syscon-leds" to "register-bit-led"
>>
>> Bryan can you please ACK this patch if you're OK with it so
>> it can be pulled in through ARM SoC?
>
> Ping!
>
> I will send a pull request for this soon anyway.
>
> Yours,
> Linus Walleij
So sorry about this, my Gmail filter out this email. I have no problem
with this.
-Bryan
^ permalink raw reply [flat|nested] 46+ messages in thread
end of thread, other threads:[~2015-01-13 20:19 UTC | newest]
Thread overview: 46+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-09-08 11:37 [PATCH 0/7] ARM RealView DeviceTree support v6 Linus Walleij
2014-09-08 11:37 ` Linus Walleij
2014-09-08 11:38 ` [PATCH 1/7 v6] leds: add a driver for syscon-based LEDs Linus Walleij
2014-09-08 11:38 ` Linus Walleij
2014-09-12 8:56 ` Linus Walleij
2014-09-12 8:56 ` Linus Walleij
2014-09-18 22:39 ` Linus Walleij
2014-09-18 22:39 ` Linus Walleij
2015-01-13 20:19 ` Bryan Wu
2015-01-13 20:19 ` Bryan Wu
2014-09-08 11:38 ` [PATCH 2/7 v6] leds: add device tree bindings for register bit LEDs Linus Walleij
2014-09-08 11:38 ` Linus Walleij
2014-09-08 11:38 ` [PATCH 3/7 v6] power: reset: driver for the Versatile syscon reboot Linus Walleij
2014-09-08 11:38 ` Linus Walleij
2014-09-12 8:55 ` Linus Walleij
2014-09-12 8:55 ` Linus Walleij
2014-09-15 16:06 ` Sebastian Reichel
2014-09-15 16:06 ` Sebastian Reichel
[not found] ` <1410176286-32533-1-git-send-email-linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2014-09-08 11:38 ` [PATCH 4/7 v6] soc: add driver for the ARM RealView Linus Walleij
2014-09-08 11:38 ` Linus Walleij
2014-09-08 11:38 ` [PATCH 5/7 v6] ARM: l2c: parse 'cache-size' and 'cache-sets' properties Linus Walleij
2014-09-08 11:38 ` Linus Walleij
2014-09-08 12:20 ` Arnd Bergmann
2014-09-08 12:20 ` Arnd Bergmann
2014-09-08 12:36 ` Linus Walleij
2014-09-08 12:36 ` Linus Walleij
2014-09-08 13:16 ` Arnd Bergmann
2014-09-08 13:16 ` Arnd Bergmann
2014-09-08 20:33 ` Florian Fainelli
2014-09-08 20:33 ` Florian Fainelli
2014-09-08 20:41 ` Arnd Bergmann
2014-09-08 20:41 ` Arnd Bergmann
2014-09-09 7:14 ` Linus Walleij
2014-09-09 7:14 ` Linus Walleij
[not found] ` <CACRpkdb_bS0P-fGxogiyCzG9CRPhJK1Gro=H3X1Ks_-UoXh52w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-09-08 19:57 ` Florian Fainelli
2014-09-08 19:57 ` Florian Fainelli
2014-09-08 11:38 ` [PATCH 6/7 v6] ARM: l2x0: calculate associativity from ePAPR cache props Linus Walleij
2014-09-08 11:38 ` Linus Walleij
2014-09-08 12:15 ` Arnd Bergmann
2014-09-08 12:15 ` Arnd Bergmann
2014-09-08 12:43 ` Linus Walleij
2014-09-08 12:43 ` Linus Walleij
2014-09-08 13:18 ` Arnd Bergmann
2014-09-08 13:18 ` Arnd Bergmann
2014-09-08 11:38 ` [PATCH 7/7 v6] ARM: realview: basic device tree implementation Linus Walleij
2014-09-08 11:38 ` Linus Walleij
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.