Re: [RFC 02/23] watchdog: omap_wdt: raw read and write endian fix
On 11/15/2013 04:01 PM, Taras Kondratiuk wrote: From: Victor Kamensky All OMAP IP blocks expect LE data, but CPU may operate in BE mode. Need to use endian neutral functions to read/write h/w registers. I.e instead of __raw_read[lw] and __raw_write[lw] functions code need to use read[lw]_relaxed and write[lw]_relaxed functions. If the first simply reads/writes register, the second will byteswap it if host operates in BE mode. Changes are trivial sed like replacement of __raw_xxx functions with xxx_relaxed variant. Signed-off-by: Victor Kamensky Signed-off-by: Taras Kondratiuk Acked-by: Guenter Roeck -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] ARM: OMAP2+: Remove legacy booting support for LDP
We can now boot with appended device tree with pretty much
the same functionality. So let's remove the legacy board
file as we want to make mach-omap2 device tree only.
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/Kconfig | 6 -
arch/arm/mach-omap2/Makefile| 1 -
arch/arm/mach-omap2/board-ldp.c | 425
3 files changed, 432 deletions(-)
delete mode 100644 arch/arm/mach-omap2/board-ldp.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 4191ae0..0f7952d 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -204,12 +204,6 @@ config MACH_DEVKIT8000
default y
select OMAP_PACKAGE_CUS
-config MACH_OMAP_LDP
- bool "OMAP3 LDP board"
- depends on ARCH_OMAP3
- default y
- select OMAP_PACKAGE_CBB
-
config MACH_OMAP3530_LV_SOM
bool "OMAP3 Logic 3530 LV SOM board"
depends on ARCH_OMAP3
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 83b147e..6a280f8 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -237,7 +237,6 @@ obj-$(CONFIG_SOC_OMAP2420) += msdi.o
obj-$(CONFIG_MACH_OMAP_GENERIC)+= board-generic.o
pdata-quirks.o
obj-$(CONFIG_MACH_OMAP3_BEAGLE)+= board-omap3beagle.o
obj-$(CONFIG_MACH_DEVKIT8000) += board-devkit8000.o
-obj-$(CONFIG_MACH_OMAP_LDP)+= board-ldp.o
obj-$(CONFIG_MACH_OMAP3530_LV_SOM) += board-omap3logic.o
obj-$(CONFIG_MACH_OMAP3_TORPEDO)+= board-omap3logic.o
obj-$(CONFIG_MACH_OVERO) += board-overo.o
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
deleted file mode 100644
index 4ec8d82..000
--- a/arch/arm/mach-omap2/board-ldp.c
+++ /dev/null
@@ -1,425 +0,0 @@
-/*
- * linux/arch/arm/mach-omap2/board-ldp.c
- *
- * Copyright (C) 2008 Texas Instruments Inc.
- * Nishant Kamat
- *
- * Modified from mach-omap2/board-3430sdp.c
- *
- * 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
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include
-#include
-#include
-
-#include "common.h"
-#include "gpmc.h"
-#include "gpmc-smsc911x.h"
-
-#include
-#include
-
-#include "board-flash.h"
-#include "mux.h"
-#include "hsmmc.h"
-#include "control.h"
-#include "common-board-devices.h"
-
-#define LDP_SMSC911X_CS1
-#define LDP_SMSC911X_GPIO 152
-#define DEBUG_BASE 0x0800
-#define LDP_ETHR_START DEBUG_BASE
-
-static uint32_t board_keymap[] = {
- KEY(0, 0, KEY_1),
- KEY(1, 0, KEY_2),
- KEY(2, 0, KEY_3),
- KEY(0, 1, KEY_4),
- KEY(1, 1, KEY_5),
- KEY(2, 1, KEY_6),
- KEY(3, 1, KEY_F5),
- KEY(0, 2, KEY_7),
- KEY(1, 2, KEY_8),
- KEY(2, 2, KEY_9),
- KEY(3, 2, KEY_F6),
- KEY(0, 3, KEY_F7),
- KEY(1, 3, KEY_0),
- KEY(2, 3, KEY_F8),
- PERSISTENT_KEY(4, 5),
- KEY(4, 4, KEY_VOLUMEUP),
- KEY(5, 5, KEY_VOLUMEDOWN),
- 0
-};
-
-static struct matrix_keymap_data board_map_data = {
- .keymap = board_keymap,
- .keymap_size= ARRAY_SIZE(board_keymap),
-};
-
-static struct twl4030_keypad_data ldp_kp_twl4030_data = {
- .keymap_data= &board_map_data,
- .rows = 6,
- .cols = 6,
- .rep= 1,
-};
-
-static struct gpio_keys_button ldp_gpio_keys_buttons[] = {
- [0] = {
- .code = KEY_ENTER,
- .gpio = 101,
- .desc = "enter sw",
- .active_low = 1,
- .debounce_interval = 30,
- },
- [1] = {
- .code = KEY_F1,
- .gpio = 102,
- .desc = "func 1",
- .active_low = 1,
- .debounce_interval = 30,
- },
- [2] = {
- .code = KEY_F2,
- .gpio = 103,
- .desc = "func 2",
- .active_low = 1,
- .debounce_interval = 30,
- },
- [3] = {
- .code = KEY_F3,
- .gpio = 104,
- .desc = "func 3",
- .active_low = 1,
- .debounce_interval = 30,
- },
- [4] = {
- .code = KEY_F4,
- .gpio = 105,
- .desc
[PATCH 4/5] ARM: dts: Add basic support for omap3 LDP zoom1 labrador
Basic things like serial, Ethernet, MMC, NAND, DSS, touchscreen
and GPIO keys work.
For twl4030-keypad we're still missing the binding, but
support for that should be trivial to add once the driver
has been updated.
MUSB I'm pretty sure I got got to enumerate once, but I
suspect the battery charging somehow disrupts it and it's
not enumerating in general for some reason.
Patches are welcome to improve things if people are
still using this board.
For reference, here's some more info on this old board:
http://www.openomap.org/wiki/tiki-index.php?page=HardwareInfo
Cc: devicet...@vger.kernel.org
Cc: "Benoît Cousson"
Signed-off-by: Tony Lindgren
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/omap3-ldp.dts | 231
2 files changed, 232 insertions(+)
create mode 100644 arch/arm/boot/dts/omap3-ldp.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index de37094..fc37bca 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -183,6 +183,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap3-beagle-xm.dtb \
omap3-evm.dtb \
omap3-evm-37xx.dtb \
+ omap3-ldp.dtb \
omap3-n900.dtb \
omap3-n9.dtb \
omap3-n950.dtb \
diff --git a/arch/arm/boot/dts/omap3-ldp.dts b/arch/arm/boot/dts/omap3-ldp.dts
new file mode 100644
index 000..ddce0d8
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-ldp.dts
@@ -0,0 +1,231 @@
+/*
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * 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.
+ */
+/dts-v1/;
+
+#include "omap34xx.dtsi"
+#include "omap-gpmc-smsc911x.dtsi"
+
+/ {
+ model = "TI OMAP3430 LDP (Zoom1 Labrador)";
+ compatible = "ti,omap3-ldp", "ti,omap3";
+
+ memory {
+ device_type = "memory";
+ reg = <0x8000 0x800>; /* 128 MB */
+ };
+
+ cpus {
+ cpu@0 {
+ cpu0-supply = <&vcc>;
+ };
+ };
+
+ gpio_keys {
+ compatible = "gpio-keys";
+ pinctrl-names = "default";
+ pinctrl-0 = <&gpio_key_pins>;
+
+ key_enter {
+ label = "enter";
+ gpios = <&gpio4 5 GPIO_ACTIVE_LOW>; /* gpio101 */
+ linux,code = <0x0107001c>; /* KEY_ENTER */
+ gpio-key,wakeup;
+ };
+
+ key_f1 {
+ label = "f1";
+ gpios = <&gpio4 6 GPIO_ACTIVE_LOW>; /* gpio102 */
+ linux,code = <0x0303003b>; /* KEY_F1 */
+ gpio-key,wakeup;
+ };
+
+ key_f2 {
+ label = "f2";
+ gpios = <&gpio4 7 GPIO_ACTIVE_LOW>; /* gpio103 */
+ linux,code = <0x0403003c>; /* KEY_F2 */
+ gpio-key,wakeup;
+ };
+
+ key_f3 {
+ label = "f3";
+ gpios = <&gpio4 8 GPIO_ACTIVE_LOW>; /* gpio104 */
+ linux,code = <0x0503003d>; /* KEY_F3 */
+ gpio-key,wakeup;
+ };
+
+ key_f4 {
+ label = "f4";
+ gpios = <&gpio4 9 GPIO_ACTIVE_LOW>; /* gpio105 */
+ linux,code = <0x0704003e>; /* KEY_F4 */
+ gpio-key,wakeup;
+ };
+
+ key_left {
+ label = "left";
+ gpios = <&gpio4 10 GPIO_ACTIVE_LOW>; /* gpio106 */
+ linux,code = <0x04070069>; /* KEY_LEFT */
+ gpio-key,wakeup;
+ };
+
+ key_right {
+ label = "right";
+ gpios = <&gpio4 11 GPIO_ACTIVE_LOW>; /* gpio107 */
+ linux,code = <0x0507006a>; /* KEY_RIGHT */
+ gpio-key,wakeup;
+ };
+
+ key_up {
+ label = "up";
+ gpios = <&gpio4 12 GPIO_ACTIVE_LOW>; /* gpio108 */
+ linux,code = <0x06070067>; /* KEY_UP */
+ gpio-key,wakeup;
+ };
+
+ key_down {
+ label = "down";
+ gpios = <&gpio4 13 GPIO_ACTIVE_LOW>; /* gpio109 */
+ linux,code = <0x0707006c>; /* KEY_DOWN */
+ gpio-key,wakeup;
+ };
+ };
+};
+
+&gpmc {
+ ranges = <0 0 0x 0x0100>,
+<1 0 0x0800 0x0100>;
+
+ nand@0,0 {
+ linux,mtd-name= "micron,nand";
+ reg = <0 0 0>;
+ nand-bus-width = <16>;
+
[PATCH 0/5] Prepare making omap3 device tree only and convert LDP
Hi all, Here are few patches to deal with the mix of legacy platform data and device tree that we still need to do at least until DSS has device tree bindings. These patches should allow the remaining omap3 boards to be made device tree only so we can remove the board-*.c files. I've also converted the old LDP board to be device tree only as that has the typical TWL GPIO controlled LCD panel setup, and made sure the basic things work. These patches are against mainline tree commit 10d0c9705, and also needs the recently posted patches from following: [PATCH 0/8] Various omap device tree usability fixes for v3.13 merge window [PATCH 00/11] Make omap24xx booting device tree based for v3.14 merge window I've also pushed all the related patches to a temporary branch omap-for-v3.14/tmp-testing-dt in the linux-omap git tree. Regards, Tony Tony Lindgren (5): mfd: twl-core: Fix passing of platform data in the device tree case ARM: OMAP2+: Add support for legacy auxdata for twl ARM: OMAP2+: Add DT init code for DPI displays and make omap3 LDP to use it ARM: dts: Add basic support for omap3 LDP zoom1 labrador ARM: OMAP2+: Remove legacy booting support for LDP arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/omap3-ldp.dts| 231 arch/arm/mach-omap2/Kconfig| 6 - arch/arm/mach-omap2/Makefile | 1 - arch/arm/mach-omap2/board-ldp.c| 425 - arch/arm/mach-omap2/common.h | 1 + arch/arm/mach-omap2/dss-common.c | 67 ++ arch/arm/mach-omap2/dss-common.h | 1 + arch/arm/mach-omap2/omap_device.c | 2 + arch/arm/mach-omap2/pdata-quirks.c | 31 +++ drivers/mfd/twl-core.c | 15 +- 11 files changed, 346 insertions(+), 435 deletions(-) create mode 100644 arch/arm/boot/dts/omap3-ldp.dts delete mode 100644 arch/arm/mach-omap2/board-ldp.c -- 1.8.1.1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] ARM: OMAP2+: Add support for legacy auxdata for twl
As we currently need to support a mix of legacy platform data and
device tree intialized data, let's make sure things keep working
for the TWL GPIOs.
Mostly the issue is caused by the fact that DSS does not yet have
device tree bindings, so we need to rely on the TWL GPIO callback
for setting up things like LCD backlight for some boards.
As of_platform_populate() for the TWL GPIO is called by twl-core
after the I2C bus has been initialized, we cannot pass the auxdata
table from the board init code to twl-core like we used to with
just legacy platform data.
So let's use the omap_device bus hook to patch in the platform
data for TWL GPIO until we have sorted out the issues with the
TWL GPIOs and device tree bindings.
The other option was be to initialize twl core using legacy
platform data, which seems like a step backwards as we're moving
to device tree only initialization. And we really don't want to
add custom configuration functions to the TWL GPIO driver either
for this.
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/common.h | 1 +
arch/arm/mach-omap2/omap_device.c | 2 ++
arch/arm/mach-omap2/pdata-quirks.c | 16
3 files changed, 19 insertions(+)
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index f7644fe..d0f3308 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -293,6 +293,7 @@ static inline void omap4_cpu_resume(void)
#endif
void pdata_quirks_init(struct of_device_id *);
+void omap_auxdata_legacy_init(struct device *dev);
void omap_pcs_legacy_init(int irq, void (*rearm)(void));
struct omap_sdrc_params;
diff --git a/arch/arm/mach-omap2/omap_device.c
b/arch/arm/mach-omap2/omap_device.c
index 53f0735..828f538 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -36,6 +36,7 @@
#include
#include
+#include "common.h"
#include "soc.h"
#include "omap_device.h"
#include "omap_hwmod.h"
@@ -200,6 +201,7 @@ static int _omap_device_notifier_call(struct notifier_block
*nb,
case BUS_NOTIFY_ADD_DEVICE:
if (pdev->dev.of_node)
omap_device_build_from_dt(pdev);
+ omap_auxdata_legacy_init(dev);
/* fall through */
default:
od = to_omap_device(pdev);
diff --git a/arch/arm/mach-omap2/pdata-quirks.c
b/arch/arm/mach-omap2/pdata-quirks.c
index e7e9984..f2fc072 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -27,6 +27,7 @@ struct pdata_init {
};
struct of_dev_auxdata omap_auxdata_lookup[];
+static struct twl4030_gpio_platform_data twl_gpio_auxdata;
/*
* Create alias for USB host PHY clock.
@@ -137,6 +138,21 @@ void omap_pcs_legacy_init(int irq, void (*rearm)(void))
}
/*
+ * GPIOs for TWL are initialized by the I2C bus and need custom
+ * handing until DSS has device tree bindings.
+ */
+void omap_auxdata_legacy_init(struct device *dev)
+{
+ if (dev->platform_data)
+ return;
+
+ if (strcmp("twl4030-gpio", dev_name(dev)))
+ return;
+
+ dev->platform_data = &twl_gpio_auxdata;
+}
+
+/*
* Few boards still need auxdata populated before we populate
* the dev entries in of_platform_populate().
*/
--
1.8.1.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] ARM: OMAP2+: Add DT init code for DPI displays and make omap3 LDP to use it
In order to make the remaining omap3 boards usable with device
tree, we need to initialize the DPI based displays using pdata
until we have the DSS bindings in place.
At least board-am3517evm.c, board-cm-t35.c, board-devkit8000.c,
board-ldp.c and board-overo.c all use fairly similar DPI setup,
so let's add generic code for it. And let's make omap3 LDP to
use it and also initialize the ads7846 until we have a binding
for it.
Note that at least LDP needs the TWL bug fix posted as
"gpio: twl4030: Fix regression for twl gpio output" for the
LCD backlight to power.
Cc: Tomi Valkeinen
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/dss-common.c | 67 ++
arch/arm/mach-omap2/dss-common.h | 1 +
arch/arm/mach-omap2/pdata-quirks.c | 15 +
3 files changed, 83 insertions(+)
diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
index 365bfd3..86e98c5 100644
--- a/arch/arm/mach-omap2/dss-common.c
+++ b/arch/arm/mach-omap2/dss-common.c
@@ -257,3 +257,70 @@ void __init omap3_igep2_display_init_of(void)
platform_device_register(&omap3_igep2_tfp410_device);
platform_device_register(&omap3_igep2_dvi_connector_device);
}
+
+/* Systems with DPI LCD */
+
+static struct panel_dpi_platform_data dpi_lcd = {
+ .name = "lcd",
+ .source = "dpi.0",
+ .enable_gpio= -1,
+ .backlight_gpio = -1,
+};
+
+static struct platform_device dpi_lcd_device = {
+ .name = "panel-dpi",
+ .id = 0,
+ .dev.platform_data = &dpi_lcd,
+};
+
+static struct omap_dss_board_info dpi_dss_data = {
+ .default_display_name = "lcd",
+};
+
+static void dpi_display_init(void)
+{
+ platform_device_register(&dpi_lcd_device);
+ omap_display_init(&dpi_dss_data);
+}
+
+/* DPI on omap3 LDP */
+
+static const struct display_timing ldp_lcd_videomode = {
+ .pixelclock = { 0, 540, 0 },
+
+ .hactive = { 0, 240, 0 },
+ .hfront_porch = { 0, 3, 0 },
+ .hback_porch = { 0, 39, 0 },
+ .hsync_len = { 0, 3, 0 },
+
+ .vactive = { 0, 320, 0 },
+ .vfront_porch = { 0, 2, 0 },
+ .vback_porch = { 0, 7, 0 },
+ .vsync_len = { 0, 1, 0 },
+
+ .flags = DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW |
+ DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_PIXDATA_POSEDGE,
+};
+
+void __init omap3_ldp_display_init_of(int gpio_bl, int gpio_en)
+{
+ int r;
+
+ static struct gpio gpios[] = {
+ { 55, GPIOF_OUT_INIT_HIGH, "LCD RESET" },
+ { 56, GPIOF_OUT_INIT_HIGH, "LCD QVGA" },
+ };
+
+ r = gpio_request_array(gpios, ARRAY_SIZE(gpios));
+ if (r) {
+ pr_err("Cannot request LCD GPIOs, error %d\n", r);
+ return;
+ }
+
+ dpi_lcd.data_lines = 18;
+ dpi_lcd.display_timing = &ldp_lcd_videomode;
+ dpi_lcd.enable_gpio = gpio_en;
+ dpi_lcd.backlight_gpio = gpio_bl;
+
+ dpi_display_init();
+}
diff --git a/arch/arm/mach-omap2/dss-common.h b/arch/arm/mach-omap2/dss-common.h
index a9becf0..bc9921c 100644
--- a/arch/arm/mach-omap2/dss-common.h
+++ b/arch/arm/mach-omap2/dss-common.h
@@ -9,5 +9,6 @@
void __init omap4_panda_display_init_of(void);
void __init omap_4430sdp_display_init_of(void);
void __init omap3_igep2_display_init_of(void);
+void omap3_ldp_display_init_of(int gpio_bl, int gpio_en);
#endif
diff --git a/arch/arm/mach-omap2/pdata-quirks.c
b/arch/arm/mach-omap2/pdata-quirks.c
index f2fc072..97f200f 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -100,6 +100,20 @@ static void __init omap3_evm_legacy_init(void)
legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 149);
}
+/* Pass enable and backlight GPIO to DSS code */
+int __init ldp_twl_gpio_setup(struct device *dev, unsigned gpio, unsigned
ngpio)
+{
+ omap3_ldp_display_init_of(gpio + 7, gpio + 15);
+ omap_ads7846_init(1, 54, 310, NULL);
+
+ return 0;
+}
+
+static void __init omap3_ldp_legacy_init(void)
+{
+ twl_gpio_auxdata.setup = ldp_twl_gpio_setup;
+}
+
static void __init omap3_zoom_legacy_init(void)
{
legacy_init_wl12xx(WL12XX_REFCLOCK_26, 0, 162);
@@ -190,6 +204,7 @@ static struct pdata_init pdata_quirks[] __initdata = {
{ "nokia,omap3-n950", hsmmc2_internal_input_clk, },
{ "isee,omap3-igep0020", omap3_igep0020_legacy_init, },
{ "ti,omap3-evm-37xx", omap3_evm_legacy_init, },
+ { "ti,omap3-ldp", omap3_ldp_legacy_init, },
{ "ti,omap3-zoom3", omap3_zoom_legacy_init, },
#endif
#ifdef CONFIG_ARCH_OMAP4
--
1.8.1.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] mfd: twl-core: Fix passing of platform data in the device tree case
Since we still need to rely on a mix of device tree initialized
drivers and legacy platform data initialize drivers, let's fix
the passing of platform data to twl4030-gpio.
As the twl4030 GPIO is initialized by twl-core.c, we need to register
the auxdata for twl4030 GPIO in twl-core.c.
Cc: Samuel Ortiz
Cc: Lee Jones
Signed-off-by: Tony Lindgren
---
Samuel & Lee, I'd like to merge this fix via arm-soc tree if this looks
OK to you as I have other patches that depend on this.
---
drivers/mfd/twl-core.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index 29473c2..d5b3dd8 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -1133,6 +1133,11 @@ static int twl_remove(struct i2c_client *client)
return 0;
}
+static struct of_dev_auxdata twl_auxdata_lookup[] = {
+ OF_DEV_AUXDATA("ti,twl4030-gpio", 0, "twl4030-gpio", NULL),
+ { /* sentinel */ },
+};
+
/* NOTE: This driver only handles a single twl4030/tps659x0 chip */
static int
twl_probe(struct i2c_client *client, const struct i2c_device_id *id)
@@ -1271,10 +1276,14 @@ twl_probe(struct i2c_client *client, const struct
i2c_device_id *id)
twl_i2c_write_u8(TWL4030_MODULE_INTBR, temp, REG_GPPUPDCTR1);
}
- if (node)
- status = of_platform_populate(node, NULL, NULL, &client->dev);
- else
+ if (node) {
+ if (pdata)
+ twl_auxdata_lookup[0].platform_data = pdata->gpio;
+ status = of_platform_populate(node, NULL, twl_auxdata_lookup,
+ &client->dev);
+ } else {
status = add_children(pdata, irq_base, id->driver_data);
+ }
fail:
if (status < 0)
--
1.8.1.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 03/23] OMAPDSS: raw read and write endian fix
From: Victor Kamensky
All OMAP IP blocks expect LE data, but CPU may operate in BE mode.
Need to use endian neutral functions to read/write h/w registers.
I.e instead of __raw_read[lw] and __raw_write[lw] functions code
need to use read[lw]_relaxed and write[lw]_relaxed functions.
If the first simply reads/writes register, the second will byteswap
it if host operates in BE mode.
Changes are trivial sed like replacement of __raw_xxx functions
with xxx_relaxed variant.
Signed-off-by: Victor Kamensky
Signed-off-by: Taras Kondratiuk
---
drivers/video/omap2/dss/dispc.c |4 ++--
drivers/video/omap2/dss/dsi.c |4 ++--
drivers/video/omap2/dss/dss.c |4 ++--
drivers/video/omap2/dss/rfbi.c| 16
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c |4 ++--
drivers/video/omap2/dss/venc.c|4 ++--
drivers/video/omap2/omapfb/omapfb-main.c | 10 +-
drivers/video/omap2/vrfb.c|6 +++---
8 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 4779750..87a3682 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -228,12 +228,12 @@ static unsigned long dispc_plane_lclk_rate(enum
omap_plane plane);
static inline void dispc_write_reg(const u16 idx, u32 val)
{
- __raw_writel(val, dispc.base + idx);
+ writel_relaxed(val, dispc.base + idx);
}
static inline u32 dispc_read_reg(const u16 idx)
{
- return __raw_readl(dispc.base + idx);
+ return readl_relaxed(dispc.base + idx);
}
static u32 mgr_fld_read(enum omap_channel channel, enum mgr_reg_fields regfld)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index a598b58..c5af3fa 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -414,7 +414,7 @@ static inline void dsi_write_reg(struct platform_device
*dsidev,
{
struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
- __raw_writel(val, dsi->base + idx.idx);
+ writel_relaxed(val, dsi->base + idx.idx);
}
static inline u32 dsi_read_reg(struct platform_device *dsidev,
@@ -422,7 +422,7 @@ static inline u32 dsi_read_reg(struct platform_device
*dsidev,
{
struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
- return __raw_readl(dsi->base + idx.idx);
+ return readl_relaxed(dsi->base + idx.idx);
}
static void dsi_bus_lock(struct omap_dss_device *dssdev)
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index bd01608..e53f663 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -104,12 +104,12 @@ static const char * const dss_generic_clk_source_names[]
= {
static inline void dss_write_reg(const struct dss_reg idx, u32 val)
{
- __raw_writel(val, dss.base + idx.idx);
+ writel_relaxed(val, dss.base + idx.idx);
}
static inline u32 dss_read_reg(const struct dss_reg idx)
{
- return __raw_readl(dss.base + idx.idx);
+ return readl_relaxed(dss.base + idx.idx);
}
#define SR(reg) \
diff --git a/drivers/video/omap2/dss/rfbi.c b/drivers/video/omap2/dss/rfbi.c
index c8a81a2..7772e33 100644
--- a/drivers/video/omap2/dss/rfbi.c
+++ b/drivers/video/omap2/dss/rfbi.c
@@ -122,12 +122,12 @@ static struct {
static inline void rfbi_write_reg(const struct rfbi_reg idx, u32 val)
{
- __raw_writel(val, rfbi.base + idx.idx);
+ writel_relaxed(val, rfbi.base + idx.idx);
}
static inline u32 rfbi_read_reg(const struct rfbi_reg idx)
{
- return __raw_readl(rfbi.base + idx.idx);
+ return readl_relaxed(rfbi.base + idx.idx);
}
static int rfbi_runtime_get(void)
@@ -263,8 +263,8 @@ static void rfbi_write_pixels(const void __iomem *buf, int
scr_width,
for (; h; --h) {
for (i = 0; i < w; ++i) {
const u8 __iomem *b = (const u8 __iomem *)pd;
- rfbi_write_reg(RFBI_PARAM, __raw_readb(b+1));
- rfbi_write_reg(RFBI_PARAM, __raw_readb(b+0));
+ rfbi_write_reg(RFBI_PARAM, readb_relaxed(b+1));
+ rfbi_write_reg(RFBI_PARAM, readb_relaxed(b+0));
++pd;
}
pd += horiz_offset;
@@ -277,9 +277,9 @@ static void rfbi_write_pixels(const void __iomem *buf, int
scr_width,
for (; h; --h) {
for (i = 0; i < w; ++i) {
const u8 __iomem *b = (const u8 __iomem *)pd;
- rfbi_write_reg(RFBI_PARAM, __raw_readb(b+2));
- rfbi_write_reg(RFBI_PARAM, __raw_readb(b+1));
- rfbi_write_reg(RFBI_PARAM, __raw_readb(b+0));
+ rfbi_write_reg(RFBI_PARAM, readb_relaxed(b+2));
+
[RFC 10/23] Input: omap-keypad - raw read and write endian fix
From: Victor Kamensky
All OMAP IP blocks expect LE data, but CPU may operate in BE mode.
Need to use endian neutral functions to read/write h/w registers.
I.e instead of __raw_read[lw] and __raw_write[lw] functions code
need to use read[lw]_relaxed and write[lw]_relaxed functions.
If the first simply reads/writes register, the second will byteswap
it if host operates in BE mode.
Changes are trivial sed like replacement of __raw_xxx functions
with xxx_relaxed variant.
Signed-off-by: Victor Kamensky
Signed-off-by: Taras Kondratiuk
---
drivers/input/keyboard/omap4-keypad.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/input/keyboard/omap4-keypad.c
b/drivers/input/keyboard/omap4-keypad.c
index 30acfd4..952a2eb 100644
--- a/drivers/input/keyboard/omap4-keypad.c
+++ b/drivers/input/keyboard/omap4-keypad.c
@@ -89,26 +89,26 @@ struct omap4_keypad {
static int kbd_readl(struct omap4_keypad *keypad_data, u32 offset)
{
- return __raw_readl(keypad_data->base +
+ return readl_relaxed(keypad_data->base +
keypad_data->reg_offset + offset);
}
static void kbd_writel(struct omap4_keypad *keypad_data, u32 offset, u32 value)
{
- __raw_writel(value,
+ writel_relaxed(value,
keypad_data->base + keypad_data->reg_offset + offset);
}
static int kbd_read_irqreg(struct omap4_keypad *keypad_data, u32 offset)
{
- return __raw_readl(keypad_data->base +
+ return readl_relaxed(keypad_data->base +
keypad_data->irqreg_offset + offset);
}
static void kbd_write_irqreg(struct omap4_keypad *keypad_data,
u32 offset, u32 value)
{
- __raw_writel(value,
+ writel_relaxed(value,
keypad_data->base + keypad_data->irqreg_offset + offset);
}
@@ -312,7 +312,7 @@ static int omap4_keypad_probe(struct platform_device *pdev)
dev_err(&pdev->dev, "pm_runtime_get_sync() failed\n");
goto err_unmap;
}
- rev = __raw_readl(keypad_data->base + OMAP4_KBD_REVISION);
+ rev = readl_relaxed(keypad_data->base + OMAP4_KBD_REVISION);
rev &= 0x03 << 30;
rev >>= 30;
switch (rev) {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 07/23] hwrng: omap - raw read and write endian fix
From: Victor Kamensky
All OMAP IP blocks expect LE data, but CPU may operate in BE mode.
Need to use endian neutral functions to read/write h/w registers.
I.e instead of __raw_read[lw] and __raw_write[lw] functions code
need to use read[lw]_relaxed and write[lw]_relaxed functions.
If the first simply reads/writes register, the second will byteswap
it if host operates in BE mode.
Changes are trivial sed like replacement of __raw_xxx functions
with xxx_relaxed variant.
Signed-off-by: Victor Kamensky
Signed-off-by: Taras Kondratiuk
---
drivers/char/hw_random/omap-rng.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/char/hw_random/omap-rng.c
b/drivers/char/hw_random/omap-rng.c
index 9b89ff4..d68cf8a 100644
--- a/drivers/char/hw_random/omap-rng.c
+++ b/drivers/char/hw_random/omap-rng.c
@@ -131,13 +131,13 @@ struct omap_rng_dev {
static inline u32 omap_rng_read(struct omap_rng_dev *priv, u16 reg)
{
- return __raw_readl(priv->base + priv->pdata->regs[reg]);
+ return readl_relaxed(priv->base + priv->pdata->regs[reg]);
}
static inline void omap_rng_write(struct omap_rng_dev *priv, u16 reg,
u32 val)
{
- __raw_writel(val, priv->base + priv->pdata->regs[reg]);
+ writel_relaxed(val, priv->base + priv->pdata->regs[reg]);
}
static int omap_rng_data_present(struct hwrng *rng, int wait)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 08/23] crypto: omap-aes - raw read and write endian fix
From: Victor Kamensky
All OMAP IP blocks expect LE data, but CPU may operate in BE mode.
Need to use endian neutral functions to read/write h/w registers.
I.e instead of __raw_read[lw] and __raw_write[lw] functions code
need to use read[lw]_relaxed and write[lw]_relaxed functions.
If the first simply reads/writes register, the second will byteswap
it if host operates in BE mode.
Changes are trivial sed like replacement of __raw_xxx functions
with xxx_relaxed variant.
Signed-off-by: Victor Kamensky
Signed-off-by: Taras Kondratiuk
---
drivers/crypto/omap-aes.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index ce791c2..777ae0a 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -195,7 +195,7 @@ static DEFINE_SPINLOCK(list_lock);
#define omap_aes_read(dd, offset) \
({ \
int _read_ret; \
- _read_ret = __raw_readl(dd->io_base + offset); \
+ _read_ret = readl_relaxed(dd->io_base + offset);\
pr_debug("omap_aes_read(" #offset "=%#x)= %#x\n", \
offset, _read_ret);\
_read_ret; \
@@ -203,7 +203,7 @@ static DEFINE_SPINLOCK(list_lock);
#else
static inline u32 omap_aes_read(struct omap_aes_dev *dd, u32 offset)
{
- return __raw_readl(dd->io_base + offset);
+ return readl_relaxed(dd->io_base + offset);
}
#endif
@@ -212,13 +212,13 @@ static inline u32 omap_aes_read(struct omap_aes_dev *dd,
u32 offset)
do {\
pr_debug("omap_aes_write(" #offset "=%#x) value=%#x\n", \
offset, value);\
- __raw_writel(value, dd->io_base + offset); \
+ writel_relaxed(value, dd->io_base + offset);\
} while (0)
#else
static inline void omap_aes_write(struct omap_aes_dev *dd, u32 offset,
u32 value)
{
- __raw_writel(value, dd->io_base + offset);
+ writel_relaxed(value, dd->io_base + offset);
}
#endif
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 13/23] spi: omap2-mcspi: raw read and write endian fix
From: Victor Kamensky
All OMAP IP blocks expect LE data, but CPU may operate in BE mode.
Need to use endian neutral functions to read/write h/w registers.
I.e instead of __raw_read[lw] and __raw_write[lw] functions code
need to use read[lw]_relaxed and write[lw]_relaxed functions.
If the first simply reads/writes register, the second will byteswap
it if host operates in BE mode.
Changes are trivial sed like replacement of __raw_xxx functions
with xxx_relaxed variant.
Signed-off-by: Victor Kamensky
Signed-off-by: Taras Kondratiuk
---
drivers/spi/spi-omap2-mcspi.c | 38 +++---
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index ed4af47..c9471b7 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -157,14 +157,14 @@ static inline void mcspi_write_reg(struct spi_master
*master,
{
struct omap2_mcspi *mcspi = spi_master_get_devdata(master);
- __raw_writel(val, mcspi->base + idx);
+ writel_relaxed(val, mcspi->base + idx);
}
static inline u32 mcspi_read_reg(struct spi_master *master, int idx)
{
struct omap2_mcspi *mcspi = spi_master_get_devdata(master);
- return __raw_readl(mcspi->base + idx);
+ return readl_relaxed(mcspi->base + idx);
}
static inline void mcspi_write_cs_reg(const struct spi_device *spi,
@@ -172,14 +172,14 @@ static inline void mcspi_write_cs_reg(const struct
spi_device *spi,
{
struct omap2_mcspi_cs *cs = spi->controller_state;
- __raw_writel(val, cs->base + idx);
+ writel_relaxed(val, cs->base + idx);
}
static inline u32 mcspi_read_cs_reg(const struct spi_device *spi, int idx)
{
struct omap2_mcspi_cs *cs = spi->controller_state;
- return __raw_readl(cs->base + idx);
+ return readl_relaxed(cs->base + idx);
}
static inline u32 mcspi_cached_chconf0(const struct spi_device *spi)
@@ -332,7 +332,7 @@ static void omap2_mcspi_restore_ctx(struct omap2_mcspi
*mcspi)
mcspi_write_reg(spi_cntrl, OMAP2_MCSPI_WAKEUPENABLE, ctx->wakeupenable);
list_for_each_entry(cs, &ctx->cs, node)
- __raw_writel(cs->chconf0, cs->base + OMAP2_MCSPI_CHCONF0);
+ writel_relaxed(cs->chconf0, cs->base + OMAP2_MCSPI_CHCONF0);
}
static int mcspi_wait_for_reg_bit(void __iomem *reg, unsigned long bit)
@@ -340,9 +340,9 @@ static int mcspi_wait_for_reg_bit(void __iomem *reg,
unsigned long bit)
unsigned long timeout;
timeout = jiffies + msecs_to_jiffies(1000);
- while (!(__raw_readl(reg) & bit)) {
+ while (!(readl_relaxed(reg) & bit)) {
if (time_after(jiffies, timeout)) {
- if (!(__raw_readl(reg) & bit))
+ if (!(readl_relaxed(reg) & bit))
return -ETIMEDOUT;
else
return 0;
@@ -669,7 +669,7 @@ omap2_mcspi_txrx_pio(struct spi_device *spi, struct
spi_transfer *xfer)
}
dev_vdbg(&spi->dev, "write-%d %02x\n",
word_len, *tx);
- __raw_writel(*tx++, tx_reg);
+ writel_relaxed(*tx++, tx_reg);
}
if (rx != NULL) {
if (mcspi_wait_for_reg_bit(chstat_reg,
@@ -681,7 +681,7 @@ omap2_mcspi_txrx_pio(struct spi_device *spi, struct
spi_transfer *xfer)
if (c == 1 && tx == NULL &&
(l & OMAP2_MCSPI_CHCONF_TURBO)) {
omap2_mcspi_set_enable(spi, 0);
- *rx++ = __raw_readl(rx_reg);
+ *rx++ = readl_relaxed(rx_reg);
dev_vdbg(&spi->dev, "read-%d %02x\n",
word_len, *(rx - 1));
if (mcspi_wait_for_reg_bit(chstat_reg,
@@ -695,7 +695,7 @@ omap2_mcspi_txrx_pio(struct spi_device *spi, struct
spi_transfer *xfer)
omap2_mcspi_set_enable(spi, 0);
}
- *rx++ = __raw_readl(rx_reg);
+ *rx++ = readl_relaxed(rx_reg);
dev_vdbg(&spi->dev, "read-%d %02x\n",
word_len, *(rx - 1));
}
@@ -716,7 +716,7 @@ omap2_mcspi_txrx_pio(struct spi_device *spi, struct
spi_transfer *xfer)
}
dev_vdbg(&spi->dev, "write-%d %04x\n",
word_len, *tx);
- __raw_writel(*tx++, tx_reg);
+
[RFC 04/23] mmc: omap: raw read and write endian fix
From: Victor Kamensky
All OMAP IP blocks expect LE data, but CPU may operate in BE mode.
Need to use endian neutral functions to read/write h/w registers.
I.e instead of __raw_read[lw] and __raw_write[lw] functions code
need to use read[lw]_relaxed and write[lw]_relaxed functions.
If the first simply reads/writes register, the second will byteswap
it if host operates in BE mode.
Changes are trivial sed like replacement of __raw_xxx functions
with xxx_relaxed variant.
Signed-off-by: Victor Kamensky
Signed-off-by: Taras Kondratiuk
---
drivers/mmc/host/omap.c |4 ++--
drivers/mmc/host/omap_hsmmc.c |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
index b94f38e..ef2d088 100644
--- a/drivers/mmc/host/omap.c
+++ b/drivers/mmc/host/omap.c
@@ -79,8 +79,8 @@
#define mmc_omap2()(!mmc_omap1())
#define OMAP_MMC_REG(host, reg)(OMAP_MMC_REG_##reg <<
(host)->reg_shift)
-#define OMAP_MMC_READ(host, reg) __raw_readw((host)->virt_base +
OMAP_MMC_REG(host, reg))
-#define OMAP_MMC_WRITE(host, reg, val) __raw_writew((val), (host)->virt_base +
OMAP_MMC_REG(host, reg))
+#define OMAP_MMC_READ(host, reg)readw_relaxed((host)->virt_base +
OMAP_MMC_REG(host, reg))
+#define OMAP_MMC_WRITE(host, reg, val) writew_relaxed((val), (host)->virt_base
+ OMAP_MMC_REG(host, reg))
/*
* Command types
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 6ac63df..fbbbfc0 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -135,10 +135,10 @@
* MMC Host controller read/write API's
*/
#define OMAP_HSMMC_READ(base, reg) \
- __raw_readl((base) + OMAP_HSMMC_##reg)
+ readl_relaxed((base) + OMAP_HSMMC_##reg)
#define OMAP_HSMMC_WRITE(base, reg, val) \
- __raw_writel((val), (base) + OMAP_HSMMC_##reg)
+ writel_relaxed((val), (base) + OMAP_HSMMC_##reg)
struct omap_hsmmc_next {
unsigned intdma_len;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 01/23] gpio/omap: raw read and write endian fix
From: Victor Kamensky
All OMAP IP blocks expect LE data, but CPU may operate in BE mode.
Need to use endian neutral functions to read/write h/w registers.
I.e instead of __raw_read[lw] and __raw_write[lw] functions code
need to use read[lw]_relaxed and write[lw]_relaxed functions.
If the first simply reads/writes register, the second will byteswap
it if host operates in BE mode.
Changes are trivial sed like replacement of __raw_xxx functions
with xxx_relaxed variant.
Signed-off-by: Victor Kamensky
Signed-off-by: Taras Kondratiuk
---
drivers/gpio/gpio-omap.c | 188 +++---
1 file changed, 94 insertions(+), 94 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 89675f8..8f4ad0f 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -108,12 +108,12 @@ static void _set_gpio_direction(struct gpio_bank *bank,
int gpio, int is_input)
u32 l;
reg += bank->regs->direction;
- l = __raw_readl(reg);
+ l = readl_relaxed(reg);
if (is_input)
l |= 1 << gpio;
else
l &= ~(1 << gpio);
- __raw_writel(l, reg);
+ writel_relaxed(l, reg);
bank->context.oe = l;
}
@@ -132,7 +132,7 @@ static void _set_gpio_dataout_reg(struct gpio_bank *bank,
int gpio, int enable)
bank->context.dataout &= ~l;
}
- __raw_writel(l, reg);
+ writel_relaxed(l, reg);
}
/* set data out value using mask register */
@@ -142,12 +142,12 @@ static void _set_gpio_dataout_mask(struct gpio_bank
*bank, int gpio, int enable)
u32 gpio_bit = GPIO_BIT(bank, gpio);
u32 l;
- l = __raw_readl(reg);
+ l = readl_relaxed(reg);
if (enable)
l |= gpio_bit;
else
l &= ~gpio_bit;
- __raw_writel(l, reg);
+ writel_relaxed(l, reg);
bank->context.dataout = l;
}
@@ -155,26 +155,26 @@ static int _get_gpio_datain(struct gpio_bank *bank, int
offset)
{
void __iomem *reg = bank->base + bank->regs->datain;
- return (__raw_readl(reg) & (1 << offset)) != 0;
+ return (readl_relaxed(reg) & (1 << offset)) != 0;
}
static int _get_gpio_dataout(struct gpio_bank *bank, int offset)
{
void __iomem *reg = bank->base + bank->regs->dataout;
- return (__raw_readl(reg) & (1 << offset)) != 0;
+ return (readl_relaxed(reg) & (1 << offset)) != 0;
}
static inline void _gpio_rmw(void __iomem *base, u32 reg, u32 mask, bool set)
{
- int l = __raw_readl(base + reg);
+ int l = readl_relaxed(base + reg);
if (set)
l |= mask;
else
l &= ~mask;
- __raw_writel(l, base + reg);
+ writel_relaxed(l, base + reg);
}
static inline void _gpio_dbck_enable(struct gpio_bank *bank)
@@ -183,7 +183,7 @@ static inline void _gpio_dbck_enable(struct gpio_bank *bank)
clk_enable(bank->dbck);
bank->dbck_enabled = true;
- __raw_writel(bank->dbck_enable_mask,
+ writel_relaxed(bank->dbck_enable_mask,
bank->base + bank->regs->debounce_en);
}
}
@@ -196,7 +196,7 @@ static inline void _gpio_dbck_disable(struct gpio_bank
*bank)
* enabled but the clock is not, GPIO module seems to be unable
* to detect events and generate interrupts at least on OMAP3.
*/
- __raw_writel(0, bank->base + bank->regs->debounce_en);
+ writel_relaxed(0, bank->base + bank->regs->debounce_en);
clk_disable(bank->dbck);
bank->dbck_enabled = false;
@@ -233,10 +233,10 @@ static void _set_gpio_debounce(struct gpio_bank *bank,
unsigned gpio,
clk_enable(bank->dbck);
reg = bank->base + bank->regs->debounce;
- __raw_writel(debounce, reg);
+ writel_relaxed(debounce, reg);
reg = bank->base + bank->regs->debounce_en;
- val = __raw_readl(reg);
+ val = readl_relaxed(reg);
if (debounce)
val |= l;
@@ -244,7 +244,7 @@ static void _set_gpio_debounce(struct gpio_bank *bank,
unsigned gpio,
val &= ~l;
bank->dbck_enable_mask = val;
- __raw_writel(val, reg);
+ writel_relaxed(val, reg);
clk_disable(bank->dbck);
/*
* Enable debounce clock per module.
@@ -283,12 +283,12 @@ static void _clear_gpio_debounce(struct gpio_bank *bank,
unsigned gpio)
bank->dbck_enable_mask &= ~gpio_bit;
bank->context.debounce_en &= ~gpio_bit;
- __raw_writel(bank->context.debounce_en,
+writel_relaxed(bank->context.debounce_en,
bank->base + bank->regs->debounce_en);
if (!bank->dbck_enable_mask) {
bank->context.debounce = 0;
- __raw_writel(bank->context.debounce, bank->base +
+ writel_relaxed(bank->context
[RFC 19/23] ARM: OMAP: counter-32k: raw read and write endian fix
From: Victor Kamensky
All OMAP IP blocks expect LE data, but CPU may operate in BE mode.
Need to use endian neutral functions to read/write h/w registers.
I.e instead of __raw_read[lw] and __raw_write[lw] functions code
need to use read[lw]_relaxed and write[lw]_relaxed functions.
If the first simply reads/writes register, the second will byteswap
it if host operates in BE mode.
Changes are trivial sed like replacement of __raw_xxx functions
with xxx_relaxed variant.
Signed-off-by: Victor Kamensky
Signed-off-by: Taras Kondratiuk
---
arch/arm/plat-omap/counter_32k.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/plat-omap/counter_32k.c b/arch/arm/plat-omap/counter_32k.c
index d9bc98e..21ca329 100644
--- a/arch/arm/plat-omap/counter_32k.c
+++ b/arch/arm/plat-omap/counter_32k.c
@@ -40,7 +40,7 @@ static void __iomem *sync32k_cnt_reg;
static u32 notrace omap_32k_read_sched_clock(void)
{
- return sync32k_cnt_reg ? __raw_readl(sync32k_cnt_reg) : 0;
+ return sync32k_cnt_reg ? readl_relaxed(sync32k_cnt_reg) : 0;
}
/**
@@ -64,7 +64,7 @@ static void omap_read_persistent_clock(struct timespec *ts)
spin_lock_irqsave(&read_persistent_clock_lock, flags);
last_cycles = cycles;
- cycles = sync32k_cnt_reg ? __raw_readl(sync32k_cnt_reg) : 0;
+ cycles = sync32k_cnt_reg ? readl_relaxed(sync32k_cnt_reg) : 0;
nsecs = clocksource_cyc2ns(cycles - last_cycles,
persistent_mult, persistent_shift);
@@ -95,7 +95,7 @@ int __init omap_init_clocksource_32k(void __iomem *vbase)
* The 'SCHEME' bits(30-31) of the revision register is used
* to identify the version.
*/
- if (__raw_readl(vbase + OMAP2_32KSYNCNT_REV_OFF) &
+ if (readl_relaxed(vbase + OMAP2_32KSYNCNT_REV_OFF) &
OMAP2_32KSYNCNT_REV_SCHEME)
sync32k_cnt_reg = vbase + OMAP2_32KSYNCNT_CR_OFF_HIGH;
else
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 09/23] crypto: omap-sham - raw read and write endian fix
From: Victor Kamensky
All OMAP IP blocks expect LE data, but CPU may operate in BE mode.
Need to use endian neutral functions to read/write h/w registers.
I.e instead of __raw_read[lw] and __raw_write[lw] functions code
need to use read[lw]_relaxed and write[lw]_relaxed functions.
If the first simply reads/writes register, the second will byteswap
it if host operates in BE mode.
Changes are trivial sed like replacement of __raw_xxx functions
with xxx_relaxed variant.
Signed-off-by: Victor Kamensky
Signed-off-by: Taras Kondratiuk
---
drivers/crypto/omap-sham.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index 8bdde57..b011b97 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -244,13 +244,13 @@ static struct omap_sham_drv sham = {
static inline u32 omap_sham_read(struct omap_sham_dev *dd, u32 offset)
{
- return __raw_readl(dd->io_base + offset);
+ return readl_relaxed(dd->io_base + offset);
}
static inline void omap_sham_write(struct omap_sham_dev *dd,
u32 offset, u32 value)
{
- __raw_writel(value, dd->io_base + offset);
+ writel_relaxed(value, dd->io_base + offset);
}
static inline void omap_sham_write_mask(struct omap_sham_dev *dd, u32 address,
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 11/23] mfd: omap-usb-host: raw read and write endian fix
From: Victor Kamensky
All OMAP IP blocks expect LE data, but CPU may operate in BE mode.
Need to use endian neutral functions to read/write h/w registers.
I.e instead of __raw_read[lw] and __raw_write[lw] functions code
need to use read[lw]_relaxed and write[lw]_relaxed functions.
If the first simply reads/writes register, the second will byteswap
it if host operates in BE mode.
Changes are trivial sed like replacement of __raw_xxx functions
with xxx_relaxed variant.
Signed-off-by: Victor Kamensky
Signed-off-by: Taras Kondratiuk
---
drivers/mfd/omap-usb-host.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 29ee54d..3b34de1 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -121,22 +121,22 @@ static u64 usbhs_dmamask = DMA_BIT_MASK(32);
static inline void usbhs_write(void __iomem *base, u32 reg, u32 val)
{
- __raw_writel(val, base + reg);
+ writel_relaxed(val, base + reg);
}
static inline u32 usbhs_read(void __iomem *base, u32 reg)
{
- return __raw_readl(base + reg);
+ return readl_relaxed(base + reg);
}
static inline void usbhs_writeb(void __iomem *base, u8 reg, u8 val)
{
- __raw_writeb(val, base + reg);
+ writeb_relaxed(val, base + reg);
}
static inline u8 usbhs_readb(void __iomem *base, u8 reg)
{
- return __raw_readb(base + reg);
+ return readb_relaxed(base + reg);
}
/*-*/
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 12/23] mfd: omap-usb-tll: raw read and write endian fix
From: Victor Kamensky
All OMAP IP blocks expect LE data, but CPU may operate in BE mode.
Need to use endian neutral functions to read/write h/w registers.
I.e instead of __raw_read[lw] and __raw_write[lw] functions code
need to use read[lw]_relaxed and write[lw]_relaxed functions.
If the first simply reads/writes register, the second will byteswap
it if host operates in BE mode.
Changes are trivial sed like replacement of __raw_xxx functions
with xxx_relaxed variant.
Signed-off-by: Victor Kamensky
Signed-off-by: Taras Kondratiuk
---
drivers/mfd/omap-usb-tll.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
index e59ac4c..15bcd93 100644
--- a/drivers/mfd/omap-usb-tll.c
+++ b/drivers/mfd/omap-usb-tll.c
@@ -121,22 +121,22 @@ static DEFINE_SPINLOCK(tll_lock); /* serialize access to
tll_dev */
static inline void usbtll_write(void __iomem *base, u32 reg, u32 val)
{
- __raw_writel(val, base + reg);
+ writel_relaxed(val, base + reg);
}
static inline u32 usbtll_read(void __iomem *base, u32 reg)
{
- return __raw_readl(base + reg);
+ return readl_relaxed(base + reg);
}
static inline void usbtll_writeb(void __iomem *base, u8 reg, u8 val)
{
- __raw_writeb(val, base + reg);
+ writeb_relaxed(val, base + reg);
}
static inline u8 usbtll_readb(void __iomem *base, u8 reg)
{
- return __raw_readb(base + reg);
+ return readb_relaxed(base + reg);
}
/*-*/
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 14/23] USB: ehci-omap: raw read and write endian fix
From: Victor Kamensky
All OMAP IP blocks expect LE data, but CPU may operate in BE mode.
Need to use endian neutral functions to read/write h/w registers.
I.e instead of __raw_read[lw] and __raw_write[lw] functions code
need to use read[lw]_relaxed and write[lw]_relaxed functions.
If the first simply reads/writes register, the second will byteswap
it if host operates in BE mode.
Changes are trivial sed like replacement of __raw_xxx functions
with xxx_relaxed variant.
Signed-off-by: Victor Kamensky
Signed-off-by: Taras Kondratiuk
---
drivers/usb/host/ehci-omap.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 6fa82d6..803e706 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -73,12 +73,12 @@ struct omap_hcd {
static inline void ehci_write(void __iomem *base, u32 reg, u32 val)
{
- __raw_writel(val, base + reg);
+ writel_relaxed(val, base + reg);
}
static inline u32 ehci_read(void __iomem *base, u32 reg)
{
- return __raw_readl(base + reg);
+ return readl_relaxed(base + reg);
}
/* configure so an HC device and id are always provided */
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 20/23] ARM: OMAP: debug-leds: raw read and write endian fix
From: Victor Kamensky
All OMAP IP blocks expect LE data, but CPU may operate in BE mode.
Need to use endian neutral functions to read/write h/w registers.
I.e instead of __raw_read[lw] and __raw_write[lw] functions code
need to use read[lw]_relaxed and write[lw]_relaxed functions.
If the first simply reads/writes register, the second will byteswap
it if host operates in BE mode.
Changes are trivial sed like replacement of __raw_xxx functions
with xxx_relaxed variant.
Signed-off-by: Victor Kamensky
Signed-off-by: Taras Kondratiuk
---
arch/arm/plat-omap/debug-leds.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm/plat-omap/debug-leds.c b/arch/arm/plat-omap/debug-leds.c
index aa7ebc6..48b69de 100644
--- a/arch/arm/plat-omap/debug-leds.c
+++ b/arch/arm/plat-omap/debug-leds.c
@@ -85,12 +85,12 @@ static void dbg_led_set(struct led_classdev *cdev,
struct dbg_led *led = container_of(cdev, struct dbg_led, cdev);
u16 reg;
- reg = __raw_readw(&fpga->leds);
+ reg = readw_relaxed(&fpga->leds);
if (b != LED_OFF)
reg |= led->mask;
else
reg &= ~led->mask;
- __raw_writew(reg, &fpga->leds);
+ writew_relaxed(reg, &fpga->leds);
}
static enum led_brightness dbg_led_get(struct led_classdev *cdev)
@@ -98,7 +98,7 @@ static enum led_brightness dbg_led_get(struct led_classdev
*cdev)
struct dbg_led *led = container_of(cdev, struct dbg_led, cdev);
u16 reg;
- reg = __raw_readw(&fpga->leds);
+ reg = readw_relaxed(&fpga->leds);
return (reg & led->mask) ? LED_FULL : LED_OFF;
}
@@ -112,7 +112,7 @@ static int fpga_probe(struct platform_device *pdev)
return -ENODEV;
fpga = ioremap(iomem->start, resource_size(iomem));
- __raw_writew(0xff, &fpga->leds);
+ writew_relaxed(0xff, &fpga->leds);
for (i = 0; i < ARRAY_SIZE(dbg_leds); i++) {
struct dbg_led *led;
@@ -138,15 +138,15 @@ static int fpga_probe(struct platform_device *pdev)
static int fpga_suspend_noirq(struct device *dev)
{
- fpga_led_state = __raw_readw(&fpga->leds);
- __raw_writew(0xff, &fpga->leds);
+ fpga_led_state = readw_relaxed(&fpga->leds);
+ writew_relaxed(0xff, &fpga->leds);
return 0;
}
static int fpga_resume_noirq(struct device *dev)
{
- __raw_writew(~fpga_led_state, &fpga->leds);
+ writew_relaxed(~fpga_led_state, &fpga->leds);
return 0;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 17/23] ARM: OMAP2+: raw read and write endian fix
From: Victor Kamensky
All OMAP IP blocks expect LE data, but CPU may operate in BE mode.
Need to use endian neutral functions to read/write h/w registers.
I.e instead of __raw_read[lw] and __raw_write[lw] functions code
need to use read[lw]_relaxed and write[lw]_relaxed functions.
If the first simply reads/writes register, the second will byteswap
it if host operates in BE mode.
Changes are trivial sed like replacement of __raw_xxx functions
with xxx_relaxed variant.
Signed-off-by: Victor Kamensky
Signed-off-by: Taras Kondratiuk
---
arch/arm/mach-omap2/board-flash.c |4 +--
arch/arm/mach-omap2/clkt2xxx_dpllcore.c |2 +-
arch/arm/mach-omap2/clkt2xxx_osc.c|8 +++---
arch/arm/mach-omap2/clkt2xxx_sys.c|2 +-
arch/arm/mach-omap2/clkt_clksel.c | 10 +++
arch/arm/mach-omap2/clkt_dpll.c |6 ++---
arch/arm/mach-omap2/clkt_iclk.c |8 +++---
arch/arm/mach-omap2/clock.c | 16 +--
arch/arm/mach-omap2/clock36xx.c |6 ++---
arch/arm/mach-omap2/cm2xxx_3xxx.h |4 +--
arch/arm/mach-omap2/cm33xx.c |4 +--
arch/arm/mach-omap2/cm3xxx.c |8 +++---
arch/arm/mach-omap2/cm44xx.c |8 +++---
arch/arm/mach-omap2/cminst44xx.c |4 +--
arch/arm/mach-omap2/control.c | 20 +++---
arch/arm/mach-omap2/dma.c |4 +--
arch/arm/mach-omap2/dpll3xxx.c| 32 +++---
arch/arm/mach-omap2/dpll44xx.c| 12 -
arch/arm/mach-omap2/gpmc.c|8 +++---
arch/arm/mach-omap2/id.c |2 +-
arch/arm/mach-omap2/irq.c |4 +--
arch/arm/mach-omap2/mux.c |8 +++---
arch/arm/mach-omap2/omap-hotplug.c|4 +--
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 18 ++---
arch/arm/mach-omap2/omap-smp.c|4 +--
arch/arm/mach-omap2/omap-wakeupgen.c | 42 ++---
arch/arm/mach-omap2/omap4-common.c| 16 +--
arch/arm/mach-omap2/omap_hwmod.c | 10 +++
arch/arm/mach-omap2/omap_phy_internal.c |6 ++---
arch/arm/mach-omap2/prcm_mpu44xx.c|4 +--
arch/arm/mach-omap2/prm2xxx.h |2 +-
arch/arm/mach-omap2/prm2xxx_3xxx.h|4 +--
arch/arm/mach-omap2/prm33xx.c |4 +--
arch/arm/mach-omap2/prm3xxx.h |2 +-
arch/arm/mach-omap2/prm44xx.c |4 +--
arch/arm/mach-omap2/prminst44xx.c |4 +--
arch/arm/mach-omap2/sdrc.h|8 +++---
arch/arm/mach-omap2/sdrc2xxx.c|4 +--
arch/arm/mach-omap2/sr_device.c |2 +-
arch/arm/mach-omap2/sram.c| 16 +--
arch/arm/mach-omap2/timer.c |8 +++---
arch/arm/mach-omap2/vc.c |4 +--
arch/arm/mach-omap2/wd_timer.c|8 +++---
43 files changed, 177 insertions(+), 177 deletions(-)
diff --git a/arch/arm/mach-omap2/board-flash.c
b/arch/arm/mach-omap2/board-flash.c
index fc20a61..17ecd8d 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -160,13 +160,13 @@ static u8 get_gpmc0_type(void)
if (!fpga_map_addr)
return -ENOMEM;
- if (!(__raw_readw(fpga_map_addr + REG_FPGA_REV)))
+ if (!(readw_relaxed(fpga_map_addr + REG_FPGA_REV)))
/* we dont have an DEBUG FPGA??? */
/* Depend on #defines!! default to strata boot return param */
goto unmap;
/* S8-DIP-OFF = 1, S8-DIP-ON = 0 */
- cs = __raw_readw(fpga_map_addr + REG_FPGA_DIP_SWITCH_INPUT2) & 0xf;
+ cs = readw_relaxed(fpga_map_addr + REG_FPGA_DIP_SWITCH_INPUT2) & 0xf;
/* ES2.0 SDP's onwards 4 dip switches are provided for CS */
if (omap_rev() >= OMAP3430_REV_ES1_0)
diff --git a/arch/arm/mach-omap2/clkt2xxx_dpllcore.c
b/arch/arm/mach-omap2/clkt2xxx_dpllcore.c
index d862010..83933df 100644
--- a/arch/arm/mach-omap2/clkt2xxx_dpllcore.c
+++ b/arch/arm/mach-omap2/clkt2xxx_dpllcore.c
@@ -141,7 +141,7 @@ int omap2_reprogram_dpllcore(struct clk_hw *hw, unsigned
long rate,
if (!dd)
return -EINVAL;
- tmpset.cm_clksel1_pll = __raw_readl(dd->mult_div1_reg);
+ tmpset.cm_clksel1_pll = readl_relaxed(dd->mult_div1_reg);
tmpset.cm_clksel1_pll &= ~(dd->mult_mask |
dd->div1_mask);
div = ((curr_prcm_set->xtal_speed / 100) - 1);
diff --git a/arch/arm/mach-omap2/clkt2xxx_osc.c
b/arch/arm/mach-omap2/clkt2xxx_osc.c
index 19f54d4..0717dff 100644
--- a/arch/arm/mach-omap2/clkt2xxx_osc.c
+++ b/arch/arm/mach-omap2/clkt2xxx_osc.c
@@ -39,9 +39,9 @@ int omap2_enable_osc_ck(struct clk_hw *clk)
{
u32 pcc;
- pcc = __raw_readl(prcm_clksrc_ctrl);
+ pc
[RFC 23/23] ARM: OMAP4: enable big endian support
From: Victor Kamensky Previous patches fixed big endian issues in OMAP4 code, so mark it as one that supports big endian Signed-off-by: Victor Kamensky Signed-off-by: Taras Kondratiuk --- arch/arm/mach-omap2/Kconfig |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index b5fb5f7..b5b19a3 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -48,6 +48,7 @@ config ARCH_OMAP4 select COMMON_CLK select ARM_ERRATA_754322 select ARM_ERRATA_775420 + select ARCH_SUPPORTS_BIG_ENDIAN config SOC_OMAP5 bool "TI OMAP5" -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 21/23] ARM: OMAP4: sleep: byteswap data for big-endian
From: Victor Kamensky
Assembler functions defined in sleep44xx.S need to byteswap values
after read / before write from h/w register if code compiled in big
endian mode. Simple change to do 'rev x, x' before str instruction
and after ldr instruction that deals with h/w registers.
Signed-off-by: Victor Kamensky
Signed-off-by: Taras Kondratiuk
---
arch/arm/mach-omap2/sleep44xx.S | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm/mach-omap2/sleep44xx.S b/arch/arm/mach-omap2/sleep44xx.S
index 9086ce0..8017016 100644
--- a/arch/arm/mach-omap2/sleep44xx.S
+++ b/arch/arm/mach-omap2/sleep44xx.S
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include "omap-secure.h"
@@ -74,6 +75,7 @@ ENTRY(omap4_finish_suspend)
*/
bl omap4_get_sar_ram_base
ldr r9, [r0, #OMAP_TYPE_OFFSET]
+ARM_BE8(revr9, r9)
cmp r9, #0x1@ Check for HS device
bne skip_secure_l1_clean
mov r0, #SCU_PM_NORMAL
@@ -113,12 +115,14 @@ skip_secure_l1_clean:
bl omap4_get_sar_ram_base
mov r8, r0
ldr r9, [r8, #OMAP_TYPE_OFFSET]
+ARM_BE8(revr9, r9)
cmp r9, #0x1@ Check for HS device
bne scu_gp_set
mrc p15, 0, r0, c0, c0, 5 @ Read MPIDR
andsr0, r0, #0x0f
ldreq r0, [r8, #SCU_OFFSET0]
ldrne r0, [r8, #SCU_OFFSET1]
+ARM_BE8(revr0, r0)
mov r1, #0x00
stmfd r13!, {r4-r12, r14}
ldr r12, =OMAP4_MON_SCU_PWR_INDEX
@@ -130,6 +134,7 @@ scu_gp_set:
andsr0, r0, #0x0f
ldreq r1, [r8, #SCU_OFFSET0]
ldrne r1, [r8, #SCU_OFFSET1]
+ARM_BE8(revr1, r1)
bl omap4_get_scu_base
bl scu_power_mode
skip_scu_gp_set:
@@ -157,6 +162,7 @@ skip_scu_gp_set:
andsr5, r5, #0x0f
ldreq r0, [r8, #L2X0_SAVE_OFFSET0]@ Retrieve L2 state from SAR
ldrne r0, [r8, #L2X0_SAVE_OFFSET1]@ memory.
+ARM_BE8(revr0, r0)
cmp r0, #3
bne do_WFI
#ifdef CONFIG_PL310_ERRATA_727915
@@ -167,9 +173,11 @@ skip_scu_gp_set:
bl omap4_get_l2cache_base
mov r2, r0
ldr r0, =0x
+ARM_BE8(revr0, r0)
str r0, [r2, #L2X0_CLEAN_INV_WAY]
wait:
ldr r0, [r2, #L2X0_CLEAN_INV_WAY]
+ARM_BE8(revr0, r0)
ldr r1, =0x
andsr0, r0, r1
bne wait
@@ -182,9 +190,11 @@ l2x_sync:
bl omap4_get_l2cache_base
mov r2, r0
mov r0, #0x0
+ARM_BE8(revr0, r0)
str r0, [r2, #L2X0_CACHE_SYNC]
sync:
ldr r0, [r2, #L2X0_CACHE_SYNC]
+ARM_BE8(revr0, r0)
andsr0, r0, #0x1
bne sync
#endif
@@ -216,6 +226,7 @@ do_WFI:
bl omap4_get_sar_ram_base
mov r8, r0
ldr r9, [r8, #OMAP_TYPE_OFFSET]
+ARM_BE8(revr9, r9)
cmp r9, #0x1@ Check for HS device
bne scu_gp_clear
mov r0, #SCU_PM_NORMAL
@@ -258,6 +269,7 @@ ENTRY(omap4_cpu_resume)
*/
ldr r8, =OMAP44XX_SAR_RAM_BASE
ldr r9, [r8, #OMAP_TYPE_OFFSET]
+ARM_BE8(revr9, r9)
cmp r9, #0x1@ Skip if GP device
bne skip_ns_smp_enable
mrc p15, 0, r0, c0, c0, 5
@@ -292,16 +304,19 @@ skip_ns_smp_enable:
*/
ldr r2, =OMAP44XX_L2CACHE_BASE
ldr r0, [r2, #L2X0_CTRL]
+ARM_BE8(revr0, r0)
and r0, #0x0f
cmp r0, #1
beq skip_l2en @ Skip if already enabled
ldr r3, =OMAP44XX_SAR_RAM_BASE
ldr r1, [r3, #OMAP_TYPE_OFFSET]
+ARM_BE8(revr1, r1)
cmp r1, #0x1@ Check for HS device
bne set_gp_por
ldr r0, =OMAP4_PPA_L2_POR_INDEX
ldr r1, =OMAP44XX_SAR_RAM_BASE
ldr r4, [r1, #L2X0_PREFETCH_CTRL_OFFSET]
+ARM_BE8(revr4, r4)
adr r3, ppa_por_params
str r4, [r3, #0x04]
mov r1, #0x0@ Process ID
@@ -313,11 +328,13 @@ skip_ns_smp_enable:
set_gp_por:
ldr r1, =OMAP44XX_SAR_RAM_BASE
ldr r0, [r1, #L2X0_PREFETCH_CTRL_OFFSET]
+ARM_BE8(revr0, r0)
ldr r12, =OMAP4_MON_L2X0_PREFETCH_INDEX @ Setup L2 PREFETCH
DO_SMC
set_aux_ctrl:
ldr r1, =OMAP44XX_SAR_RAM_BASE
ldr r0, [r1, #L2X0_AUXCTRL_OFFSET]
+ARM_BE8(revr0, r0)
ldr r12, =OMAP4_MON_L2X0_AUXCTRL_INDEX @ Setup L2 AUXCTRL
DO_SMC
mov r0, #0x1
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 16/23] ASoC: omap: mcbsp, mcpdm, dmic: raw read and write endian fix
From: Victor Kamensky
All OMAP IP blocks expect LE data, but CPU may operate in BE mode.
Need to use endian neutral functions to read/write h/w registers.
I.e instead of __raw_read[lw] and __raw_write[lw] functions code
need to use read[lw]_relaxed and write[lw]_relaxed functions.
If the first simply reads/writes register, the second will byteswap
it if host operates in BE mode.
Changes are trivial sed like replacement of __raw_xxx functions
with xxx_relaxed variant.
Signed-off-by: Victor Kamensky
Signed-off-by: Taras Kondratiuk
---
sound/soc/omap/mcbsp.c | 12 ++--
sound/soc/omap/omap-dmic.c |4 ++--
sound/soc/omap/omap-mcpdm.c |4 ++--
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/sound/soc/omap/mcbsp.c b/sound/soc/omap/mcbsp.c
index 83433fd..86c7538 100644
--- a/sound/soc/omap/mcbsp.c
+++ b/sound/soc/omap/mcbsp.c
@@ -36,10 +36,10 @@ static void omap_mcbsp_write(struct omap_mcbsp *mcbsp, u16
reg, u32 val)
if (mcbsp->pdata->reg_size == 2) {
((u16 *)mcbsp->reg_cache)[reg] = (u16)val;
- __raw_writew((u16)val, addr);
+ writew_relaxed((u16)val, addr);
} else {
((u32 *)mcbsp->reg_cache)[reg] = val;
- __raw_writel(val, addr);
+ writel_relaxed(val, addr);
}
}
@@ -48,22 +48,22 @@ static int omap_mcbsp_read(struct omap_mcbsp *mcbsp, u16
reg, bool from_cache)
void __iomem *addr = mcbsp->io_base + reg * mcbsp->pdata->reg_step;
if (mcbsp->pdata->reg_size == 2) {
- return !from_cache ? __raw_readw(addr) :
+ return !from_cache ? readw_relaxed(addr) :
((u16 *)mcbsp->reg_cache)[reg];
} else {
- return !from_cache ? __raw_readl(addr) :
+ return !from_cache ? readl_relaxed(addr) :
((u32 *)mcbsp->reg_cache)[reg];
}
}
static void omap_mcbsp_st_write(struct omap_mcbsp *mcbsp, u16 reg, u32 val)
{
- __raw_writel(val, mcbsp->st_data->io_base_st + reg);
+ writel_relaxed(val, mcbsp->st_data->io_base_st + reg);
}
static int omap_mcbsp_st_read(struct omap_mcbsp *mcbsp, u16 reg)
{
- return __raw_readl(mcbsp->st_data->io_base_st + reg);
+ return readl_relaxed(mcbsp->st_data->io_base_st + reg);
}
#define MCBSP_READ(mcbsp, reg) \
diff --git a/sound/soc/omap/omap-dmic.c b/sound/soc/omap/omap-dmic.c
index 12e566b..1bd531d 100644
--- a/sound/soc/omap/omap-dmic.c
+++ b/sound/soc/omap/omap-dmic.c
@@ -61,12 +61,12 @@ struct omap_dmic {
static inline void omap_dmic_write(struct omap_dmic *dmic, u16 reg, u32 val)
{
- __raw_writel(val, dmic->io_base + reg);
+ writel_relaxed(val, dmic->io_base + reg);
}
static inline int omap_dmic_read(struct omap_dmic *dmic, u16 reg)
{
- return __raw_readl(dmic->io_base + reg);
+ return readl_relaxed(dmic->io_base + reg);
}
static inline void omap_dmic_start(struct omap_dmic *dmic)
diff --git a/sound/soc/omap/omap-mcpdm.c b/sound/soc/omap/omap-mcpdm.c
index 90d2a7c..653ba1c 100644
--- a/sound/soc/omap/omap-mcpdm.c
+++ b/sound/soc/omap/omap-mcpdm.c
@@ -74,12 +74,12 @@ struct omap_mcpdm {
static inline void omap_mcpdm_write(struct omap_mcpdm *mcpdm, u16 reg, u32 val)
{
- __raw_writel(val, mcpdm->io_base + reg);
+ writel_relaxed(val, mcpdm->io_base + reg);
}
static inline int omap_mcpdm_read(struct omap_mcpdm *mcpdm, u16 reg)
{
- return __raw_readl(mcpdm->io_base + reg);
+ return readl_relaxed(mcpdm->io_base + reg);
}
#ifdef DEBUG
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 06/23] drivers: bus: omap_l3: raw read and write endian fix
From: Victor Kamensky
All OMAP IP blocks expect LE data, but CPU may operate in BE mode.
Need to use endian neutral functions to read/write h/w registers.
I.e instead of __raw_read[lw] and __raw_write[lw] functions code
need to use read[lw]_relaxed and write[lw]_relaxed functions.
If the first simply reads/writes register, the second will byteswap
it if host operates in BE mode.
Changes are trivial sed like replacement of __raw_xxx functions
with xxx_relaxed variant.
Signed-off-by: Victor Kamensky
Signed-off-by: Taras Kondratiuk
---
drivers/bus/omap_l3_noc.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c
index feeecae..82de7a5 100644
--- a/drivers/bus/omap_l3_noc.c
+++ b/drivers/bus/omap_l3_noc.c
@@ -72,7 +72,7 @@ static irqreturn_t l3_interrupt_handler(int irq, void *_l3)
* to determine the source
*/
base = l3->l3_base[i];
- err_reg = __raw_readl(base + l3_flagmux[i] +
+ err_reg = readl_relaxed(base + l3_flagmux[i] +
+ L3_FLAGMUX_REGERR0 + (inttype << 3));
/* Get the corresponding error and analyse */
@@ -82,9 +82,9 @@ static irqreturn_t l3_interrupt_handler(int irq, void *_l3)
/* Read the stderrlog_main_source from clk domain */
l3_targ_base = base + *(l3_targ[i] + err_src);
- std_err_main = __raw_readl(l3_targ_base +
+ std_err_main = readl_relaxed(l3_targ_base +
L3_TARG_STDERRLOG_MAIN);
- masterid = __raw_readl(l3_targ_base +
+ masterid = readl_relaxed(l3_targ_base +
L3_TARG_STDERRLOG_MSTADDR);
switch (std_err_main & CUSTOM_ERROR) {
@@ -93,7 +93,7 @@ static irqreturn_t l3_interrupt_handler(int irq, void *_l3)
l3_targ_inst_name[i][err_src];
WARN(true, "L3 standard error: TARGET:%s at
address 0x%x\n",
target_name,
- __raw_readl(l3_targ_base +
+ readl_relaxed(l3_targ_base +
L3_TARG_STDERRLOG_SLVOFSLSB));
/* clear the std error log*/
clear = std_err_main | CLEAR_STDERR_LOG;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 18/23] ARM: OMAP: dmtimer: raw read and write endian fix
From: Victor Kamensky
All OMAP IP blocks expect LE data, but CPU may operate in BE mode.
Need to use endian neutral functions to read/write h/w registers.
I.e instead of __raw_read[lw] and __raw_write[lw] functions code
need to use read[lw]_relaxed and write[lw]_relaxed functions.
If the first simply reads/writes register, the second will byteswap
it if host operates in BE mode.
Changes are trivial sed like replacement of __raw_xxx functions
with xxx_relaxed variant.
Signed-off-by: Victor Kamensky
Signed-off-by: Taras Kondratiuk
---
arch/arm/plat-omap/dmtimer.c |8
arch/arm/plat-omap/include/plat/dmtimer.h | 16
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 869254c..db10169 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -103,7 +103,7 @@ static void omap_timer_restore_context(struct omap_dm_timer
*timer)
timer->context.tmar);
omap_dm_timer_write_reg(timer, OMAP_TIMER_IF_CTRL_REG,
timer->context.tsicr);
- __raw_writel(timer->context.tier, timer->irq_ena);
+ writel_relaxed(timer->context.tier, timer->irq_ena);
omap_dm_timer_write_reg(timer, OMAP_TIMER_CTRL_REG,
timer->context.tclr);
}
@@ -699,9 +699,9 @@ int omap_dm_timer_set_int_disable(struct omap_dm_timer
*timer, u32 mask)
omap_dm_timer_enable(timer);
if (timer->revision == 1)
- l = __raw_readl(timer->irq_ena) & ~mask;
+ l = readl_relaxed(timer->irq_ena) & ~mask;
- __raw_writel(l, timer->irq_dis);
+ writel_relaxed(l, timer->irq_dis);
l = omap_dm_timer_read_reg(timer, OMAP_TIMER_WAKEUP_EN_REG) & ~mask;
omap_dm_timer_write_reg(timer, OMAP_TIMER_WAKEUP_EN_REG, l);
@@ -722,7 +722,7 @@ unsigned int omap_dm_timer_read_status(struct omap_dm_timer
*timer)
return 0;
}
- l = __raw_readl(timer->irq_stat);
+ l = readl_relaxed(timer->irq_stat);
return l;
}
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h
b/arch/arm/plat-omap/include/plat/dmtimer.h
index fb92abb..e5e46d6 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -280,20 +280,20 @@ static inline u32 __omap_dm_timer_read(struct
omap_dm_timer *timer, u32 reg,
int posted)
{
if (posted)
- while (__raw_readl(timer->pend) & (reg >> WPSHIFT))
+ while (readl_relaxed(timer->pend) & (reg >> WPSHIFT))
cpu_relax();
- return __raw_readl(timer->func_base + (reg & 0xff));
+ return readl_relaxed(timer->func_base + (reg & 0xff));
}
static inline void __omap_dm_timer_write(struct omap_dm_timer *timer,
u32 reg, u32 val, int posted)
{
if (posted)
- while (__raw_readl(timer->pend) & (reg >> WPSHIFT))
+ while (readl_relaxed(timer->pend) & (reg >> WPSHIFT))
cpu_relax();
- __raw_writel(val, timer->func_base + (reg & 0xff));
+ writel_relaxed(val, timer->func_base + (reg & 0xff));
}
static inline void __omap_dm_timer_init_regs(struct omap_dm_timer *timer)
@@ -301,7 +301,7 @@ static inline void __omap_dm_timer_init_regs(struct
omap_dm_timer *timer)
u32 tidr;
/* Assume v1 ip if bits [31:16] are zero */
- tidr = __raw_readl(timer->io_base);
+ tidr = readl_relaxed(timer->io_base);
if (!(tidr >> 16)) {
timer->revision = 1;
timer->irq_stat = timer->io_base + OMAP_TIMER_V1_STAT_OFFSET;
@@ -382,7 +382,7 @@ static inline void __omap_dm_timer_stop(struct
omap_dm_timer *timer,
}
/* Ack possibly pending interrupt */
- __raw_writel(OMAP_TIMER_INT_OVERFLOW, timer->irq_stat);
+ writel_relaxed(OMAP_TIMER_INT_OVERFLOW, timer->irq_stat);
}
static inline void __omap_dm_timer_load_start(struct omap_dm_timer *timer,
@@ -396,7 +396,7 @@ static inline void __omap_dm_timer_load_start(struct
omap_dm_timer *timer,
static inline void __omap_dm_timer_int_enable(struct omap_dm_timer *timer,
unsigned int value)
{
- __raw_writel(value, timer->irq_ena);
+ writel_relaxed(value, timer->irq_ena);
__omap_dm_timer_write(timer, OMAP_TIMER_WAKEUP_EN_REG, value, 0);
}
@@ -409,7 +409,7 @@ __omap_dm_timer_read_counter(struct omap_dm_timer *timer,
int posted)
static inline void __omap_dm_timer_write_status(struct omap_dm_timer *timer,
unsigned int value)
{
- __raw_writel(value, timer->irq_stat);
+ writel_relaxed(value, timer->irq_stat);
}
#endif /* __ASM_ARCH_DMTIMER_H */
--
1.7.9.5
--
To unsubscribe from this list:
[RFC 02/23] watchdog: omap_wdt: raw read and write endian fix
From: Victor Kamensky
All OMAP IP blocks expect LE data, but CPU may operate in BE mode.
Need to use endian neutral functions to read/write h/w registers.
I.e instead of __raw_read[lw] and __raw_write[lw] functions code
need to use read[lw]_relaxed and write[lw]_relaxed functions.
If the first simply reads/writes register, the second will byteswap
it if host operates in BE mode.
Changes are trivial sed like replacement of __raw_xxx functions
with xxx_relaxed variant.
Signed-off-by: Victor Kamensky
Signed-off-by: Taras Kondratiuk
---
drivers/watchdog/omap_wdt.c | 36 ++--
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
index af88ffd..2ff7bff 100644
--- a/drivers/watchdog/omap_wdt.c
+++ b/drivers/watchdog/omap_wdt.c
@@ -68,14 +68,14 @@ static void omap_wdt_reload(struct omap_wdt_dev *wdev)
void __iomem*base = wdev->base;
/* wait for posted write to complete */
- while ((__raw_readl(base + OMAP_WATCHDOG_WPS)) & 0x08)
+ while ((readl_relaxed(base + OMAP_WATCHDOG_WPS)) & 0x08)
cpu_relax();
wdev->wdt_trgr_pattern = ~wdev->wdt_trgr_pattern;
- __raw_writel(wdev->wdt_trgr_pattern, (base + OMAP_WATCHDOG_TGR));
+ writel_relaxed(wdev->wdt_trgr_pattern, (base + OMAP_WATCHDOG_TGR));
/* wait for posted write to complete */
- while ((__raw_readl(base + OMAP_WATCHDOG_WPS)) & 0x08)
+ while ((readl_relaxed(base + OMAP_WATCHDOG_WPS)) & 0x08)
cpu_relax();
/* reloaded WCRR from WLDR */
}
@@ -85,12 +85,12 @@ static void omap_wdt_enable(struct omap_wdt_dev *wdev)
void __iomem *base = wdev->base;
/* Sequence to enable the watchdog */
- __raw_writel(0x, base + OMAP_WATCHDOG_SPR);
- while ((__raw_readl(base + OMAP_WATCHDOG_WPS)) & 0x10)
+ writel_relaxed(0x, base + OMAP_WATCHDOG_SPR);
+ while ((readl_relaxed(base + OMAP_WATCHDOG_WPS)) & 0x10)
cpu_relax();
- __raw_writel(0x, base + OMAP_WATCHDOG_SPR);
- while ((__raw_readl(base + OMAP_WATCHDOG_WPS)) & 0x10)
+ writel_relaxed(0x, base + OMAP_WATCHDOG_SPR);
+ while ((readl_relaxed(base + OMAP_WATCHDOG_WPS)) & 0x10)
cpu_relax();
}
@@ -99,12 +99,12 @@ static void omap_wdt_disable(struct omap_wdt_dev *wdev)
void __iomem *base = wdev->base;
/* sequence required to disable watchdog */
- __raw_writel(0x, base + OMAP_WATCHDOG_SPR); /* TIMER_MODE */
- while (__raw_readl(base + OMAP_WATCHDOG_WPS) & 0x10)
+ writel_relaxed(0x, base + OMAP_WATCHDOG_SPR); /* TIMER_MODE */
+ while (readl_relaxed(base + OMAP_WATCHDOG_WPS) & 0x10)
cpu_relax();
- __raw_writel(0x, base + OMAP_WATCHDOG_SPR); /* TIMER_MODE */
- while (__raw_readl(base + OMAP_WATCHDOG_WPS) & 0x10)
+ writel_relaxed(0x, base + OMAP_WATCHDOG_SPR); /* TIMER_MODE */
+ while (readl_relaxed(base + OMAP_WATCHDOG_WPS) & 0x10)
cpu_relax();
}
@@ -115,11 +115,11 @@ static void omap_wdt_set_timer(struct omap_wdt_dev *wdev,
void __iomem *base = wdev->base;
/* just count up at 32 KHz */
- while (__raw_readl(base + OMAP_WATCHDOG_WPS) & 0x04)
+ while (readl_relaxed(base + OMAP_WATCHDOG_WPS) & 0x04)
cpu_relax();
- __raw_writel(pre_margin, base + OMAP_WATCHDOG_LDR);
- while (__raw_readl(base + OMAP_WATCHDOG_WPS) & 0x04)
+ writel_relaxed(pre_margin, base + OMAP_WATCHDOG_LDR);
+ while (readl_relaxed(base + OMAP_WATCHDOG_WPS) & 0x04)
cpu_relax();
}
@@ -135,11 +135,11 @@ static int omap_wdt_start(struct watchdog_device *wdog)
pm_runtime_get_sync(wdev->dev);
/* initialize prescaler */
- while (__raw_readl(base + OMAP_WATCHDOG_WPS) & 0x01)
+ while (readl_relaxed(base + OMAP_WATCHDOG_WPS) & 0x01)
cpu_relax();
- __raw_writel((1 << 5) | (PTV << 2), base + OMAP_WATCHDOG_CNTRL);
- while (__raw_readl(base + OMAP_WATCHDOG_WPS) & 0x01)
+ writel_relaxed((1 << 5) | (PTV << 2), base + OMAP_WATCHDOG_CNTRL);
+ while (readl_relaxed(base + OMAP_WATCHDOG_WPS) & 0x01)
cpu_relax();
omap_wdt_set_timer(wdev, wdog->timeout);
@@ -275,7 +275,7 @@ static int omap_wdt_probe(struct platform_device *pdev)
}
pr_info("OMAP Watchdog Timer Rev 0x%02x: initial timeout %d sec\n",
- __raw_readl(wdev->base + OMAP_WATCHDOG_REV) & 0xFF,
+ readl_relaxed(wdev->base + OMAP_WATCHDOG_REV) & 0xFF,
omap_wdt->timeout);
pm_runtime_put_sync(wdev->dev);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 22/23] ARM: OMAP4: sleep/smp: switch CPU to BE if compiled for BE
From: Victor Kamensky If kernel operates in BE mode on device that has LE bootloader/ROM code, we need to switch CPU to operate in BE mode before it will start to access BE data. Generic secondary_startup function that is called from OMAP specific secondary startup code will do the switch, but we need to do it earlier because OMAP's secondary_startup code works with BE data. Signed-off-by: Victor Kamensky Signed-off-by: Taras Kondratiuk --- arch/arm/mach-omap2/omap-headsmp.S | 13 + arch/arm/mach-omap2/sleep44xx.S|6 ++ 2 files changed, 19 insertions(+) diff --git a/arch/arm/mach-omap2/omap-headsmp.S b/arch/arm/mach-omap2/omap-headsmp.S index 75e9295..75c98d4 100644 --- a/arch/arm/mach-omap2/omap-headsmp.S +++ b/arch/arm/mach-omap2/omap-headsmp.S @@ -17,6 +17,7 @@ #include #include +#include #include "omap44xx.h" @@ -58,6 +59,12 @@ hold:ldr r12,=0x103 bne hold /* +* ROM code operates in little endian mode, when we get control we +* need to switch it back to big endian mode. +*/ +ARM_BE8(setend be) + + /* * we've been released from the wait loop,secondary_stack * should now contain the SVC stack for this core */ @@ -75,6 +82,12 @@ hold_2: ldr r12,=0x103 bne hold_2 /* +* ROM code operates in little endian mode, when we get control we +* need to switch it back to big endian mode. +*/ +ARM_BE8(setend be) + + /* * GIC distributor control register has changed between * CortexA9 r1pX and r2pX. The Control Register secure * banked version is now composed of 2 bits: diff --git a/arch/arm/mach-omap2/sleep44xx.S b/arch/arm/mach-omap2/sleep44xx.S index 8017016..f509dc5 100644 --- a/arch/arm/mach-omap2/sleep44xx.S +++ b/arch/arm/mach-omap2/sleep44xx.S @@ -260,6 +260,12 @@ ENDPROC(omap4_finish_suspend) */ ENTRY(omap4_cpu_resume) /* +* ROM code operates in little endian mode, when we get control we +* need to switch it back to big endian mode. +*/ +ARM_BE8(setend be) + + /* * Configure ACTRL and enable NS SMP bit access on CPU1 on HS device. * OMAP44XX EMU/HS devices - CPU0 SMP bit access is enabled in PPA * init and for CPU1, a secure PPA API provided. CPU0 must be ON -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 00/23] OMAP4: big endian support and fixes
This series is a split up of Victor's initial BE series for Pandaboard. The first 20 patches are trivial replacement of __raw_xxx functions with xxx_relaxed endian neutral variant. Patches #1-#16 covers OMAP drivers in 'drivers' and 'sound' directories. Patch #17 covers 'mach-omap2' directory. Initially I've split it into 10+ separate patches, but it didn't look like a good idea. Patches #18-#20 covers 'plat-omap'. Some code here most probably won't be used in BE mode (like debug-leds for OMAP1 boards), but changes are made anyway to remove __raw_xxx() functions completely from 'mach-omap2' and 'plat-omap'. This will simplify future grep'ing for new __raw_xxx() entries. Patch #21 fixes LE data handling in assembler code. Patch #22 switches CPU to BE after it returns from ROM code. And the last one marks OMAP4 as BE ready. Based on rmk/for-next commit fb95742a4a4f69323950d6d8f68bcb48c947b91f Tested on Pandaboard (OMAP4430 and OMAP4460 variants). Victor Kamensky (23): gpio/omap: raw read and write endian fix watchdog: omap_wdt: raw read and write endian fix OMAPDSS: raw read and write endian fix mmc: omap: raw read and write endian fix i2c: omap: raw read and write endian fix drivers: bus: omap_l3: raw read and write endian fix hwrng: omap - raw read and write endian fix crypto: omap-aes - raw read and write endian fix crypto: omap-sham - raw read and write endian fix Input: omap-keypad - raw read and write endian fix mfd: omap-usb-host: raw read and write endian fix mfd: omap-usb-tll: raw read and write endian fix spi: omap2-mcspi: raw read and write endian fix USB: ehci-omap: raw read and write endian fix usb: musb: raw read and write endian fix ASoC: omap: mcbsp, mcpdm, dmic: raw read and write endian fix ARM: OMAP2+: raw read and write endian fix ARM: OMAP: dmtimer: raw read and write endian fix ARM: OMAP: counter-32k: raw read and write endian fix ARM: OMAP: debug-leds: raw read and write endian fix ARM: OMAP4: sleep: byteswap data for big-endian ARM: OMAP4: sleep/smp: switch CPU to BE if compiled for BE ARM: OMAP4: enable big endian support arch/arm/mach-omap2/Kconfig |1 + arch/arm/mach-omap2/board-flash.c |4 +- arch/arm/mach-omap2/clkt2xxx_dpllcore.c |2 +- arch/arm/mach-omap2/clkt2xxx_osc.c|8 +- arch/arm/mach-omap2/clkt2xxx_sys.c|2 +- arch/arm/mach-omap2/clkt_clksel.c | 10 +- arch/arm/mach-omap2/clkt_dpll.c |6 +- arch/arm/mach-omap2/clkt_iclk.c |8 +- arch/arm/mach-omap2/clock.c | 16 +-- arch/arm/mach-omap2/clock36xx.c |6 +- arch/arm/mach-omap2/cm2xxx_3xxx.h |4 +- arch/arm/mach-omap2/cm33xx.c |4 +- arch/arm/mach-omap2/cm3xxx.c |8 +- arch/arm/mach-omap2/cm44xx.c |8 +- arch/arm/mach-omap2/cminst44xx.c |4 +- arch/arm/mach-omap2/control.c | 20 +-- arch/arm/mach-omap2/dma.c |4 +- arch/arm/mach-omap2/dpll3xxx.c| 32 ++--- arch/arm/mach-omap2/dpll44xx.c| 12 +- arch/arm/mach-omap2/gpmc.c|8 +- arch/arm/mach-omap2/id.c |2 +- arch/arm/mach-omap2/irq.c |4 +- arch/arm/mach-omap2/mux.c |8 +- arch/arm/mach-omap2/omap-headsmp.S| 13 ++ arch/arm/mach-omap2/omap-hotplug.c|4 +- arch/arm/mach-omap2/omap-mpuss-lowpower.c | 18 +-- arch/arm/mach-omap2/omap-smp.c|4 +- arch/arm/mach-omap2/omap-wakeupgen.c | 42 +++ arch/arm/mach-omap2/omap4-common.c| 16 +-- arch/arm/mach-omap2/omap_hwmod.c | 10 +- arch/arm/mach-omap2/omap_phy_internal.c |6 +- arch/arm/mach-omap2/prcm_mpu44xx.c|4 +- arch/arm/mach-omap2/prm2xxx.h |2 +- arch/arm/mach-omap2/prm2xxx_3xxx.h|4 +- arch/arm/mach-omap2/prm33xx.c |4 +- arch/arm/mach-omap2/prm3xxx.h |2 +- arch/arm/mach-omap2/prm44xx.c |4 +- arch/arm/mach-omap2/prminst44xx.c |4 +- arch/arm/mach-omap2/sdrc.h|8 +- arch/arm/mach-omap2/sdrc2xxx.c|4 +- arch/arm/mach-omap2/sleep44xx.S | 23 arch/arm/mach-omap2/sr_device.c |2 +- arch/arm/mach-omap2/sram.c| 16 +-- arch/arm/mach-omap2/timer.c |8 +- arch/arm/mach-omap2/vc.c |4 +- arch/arm/mach-omap2/wd_timer.c|8 +- arch/arm/plat-omap/counter_32k.c |6 +- arch/arm/plat-omap/debug-leds.c | 14 +-- arch/arm/plat-omap/dmtimer.c |8 +- arch/arm/plat-omap/include/plat/dmtimer.h | 16 +-- drivers/bus/omap_l3_noc.c |8 +- drivers/char/hw_random/omap-rng.c |4 +- drivers/crypto/omap-aes.c |8 +- drivers/crypto/omap-sham.c
[RFC 15/23] usb: musb: raw read and write endian fix
From: Victor Kamensky
All OMAP IP blocks expect LE data, but CPU may operate in BE mode.
Need to use endian neutral functions to read/write h/w registers.
I.e instead of __raw_read[lw] and __raw_write[lw] functions code
need to use read[lw]_relaxed and write[lw]_relaxed functions.
If the first simply reads/writes register, the second will byteswap
it if host operates in BE mode.
Changes are trivial sed like replacement of __raw_xxx functions
with xxx_relaxed variant.
Signed-off-by: Victor Kamensky
Signed-off-by: Taras Kondratiuk
---
drivers/usb/musb/musb_io.h | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/musb/musb_io.h b/drivers/usb/musb/musb_io.h
index eebeed7..76f4d2a 100644
--- a/drivers/usb/musb/musb_io.h
+++ b/drivers/usb/musb/musb_io.h
@@ -42,17 +42,17 @@
/* NOTE: these offsets are all in bytes */
static inline u16 musb_readw(const void __iomem *addr, unsigned offset)
- { return __raw_readw(addr + offset); }
+ { return readw_relaxed(addr + offset); }
static inline u32 musb_readl(const void __iomem *addr, unsigned offset)
- { return __raw_readl(addr + offset); }
+ { return readl_relaxed(addr + offset); }
static inline void musb_writew(void __iomem *addr, unsigned offset, u16 data)
- { __raw_writew(data, addr + offset); }
+ { writew_relaxed(data, addr + offset); }
static inline void musb_writel(void __iomem *addr, unsigned offset, u32 data)
- { __raw_writel(data, addr + offset); }
+ { writel_relaxed(data, addr + offset); }
#if defined(CONFIG_USB_MUSB_TUSB6010) || defined
(CONFIG_USB_MUSB_TUSB6010_MODULE)
@@ -65,7 +65,7 @@ static inline u8 musb_readb(const void __iomem *addr,
unsigned offset)
u16 tmp;
u8 val;
- tmp = __raw_readw(addr + (offset & ~1));
+ tmp = readw_relaxed(addr + (offset & ~1));
if (offset & 1)
val = (tmp >> 8);
else
@@ -78,22 +78,22 @@ static inline void musb_writeb(void __iomem *addr, unsigned
offset, u8 data)
{
u16 tmp;
- tmp = __raw_readw(addr + (offset & ~1));
+ tmp = readw_relaxed(addr + (offset & ~1));
if (offset & 1)
tmp = (data << 8) | (tmp & 0xff);
else
tmp = (tmp & 0xff00) | data;
- __raw_writew(tmp, addr + (offset & ~1));
+ writew_relaxed(tmp, addr + (offset & ~1));
}
#else
static inline u8 musb_readb(const void __iomem *addr, unsigned offset)
- { return __raw_readb(addr + offset); }
+ { return readb_relaxed(addr + offset); }
static inline void musb_writeb(void __iomem *addr, unsigned offset, u8 data)
- { __raw_writeb(data, addr + offset); }
+ { writeb_relaxed(data, addr + offset); }
#endif /* CONFIG_USB_MUSB_TUSB6010 */
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 05/23] i2c: omap: raw read and write endian fix
From: Victor Kamensky
All OMAP IP blocks expect LE data, but CPU may operate in BE mode.
Need to use endian neutral functions to read/write h/w registers.
I.e instead of __raw_read[lw] and __raw_write[lw] functions code
need to use read[lw]_relaxed and write[lw]_relaxed functions.
If the first simply reads/writes register, the second will byteswap
it if host operates in BE mode.
Changes are trivial sed like replacement of __raw_xxx functions
with xxx_relaxed variant.
Signed-off-by: Victor Kamensky
Signed-off-by: Taras Kondratiuk
---
drivers/i2c/busses/i2c-omap.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 9967a6f..d69826e 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -266,13 +266,13 @@ static const u8 reg_map_ip_v2[] = {
static inline void omap_i2c_write_reg(struct omap_i2c_dev *i2c_dev,
int reg, u16 val)
{
- __raw_writew(val, i2c_dev->base +
+ writew_relaxed(val, i2c_dev->base +
(i2c_dev->regs[reg] << i2c_dev->reg_shift));
}
static inline u16 omap_i2c_read_reg(struct omap_i2c_dev *i2c_dev, int reg)
{
- return __raw_readw(i2c_dev->base +
+ return readw_relaxed(i2c_dev->base +
(i2c_dev->regs[reg] << i2c_dev->reg_shift));
}
@@ -1142,7 +1142,7 @@ omap_i2c_probe(struct platform_device *pdev)
* Also since the omap_i2c_read_reg uses reg_map_ip_* a
* raw_readw is done.
*/
- rev = __raw_readw(dev->base + 0x04);
+ rev = readw_relaxed(dev->base + 0x04);
dev->scheme = OMAP_I2C_SCHEME(rev);
switch (dev->scheme) {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 9/8] i2c: Fix device tree binding for i2c-cbus-gpio
* Wolfram Sang [131115 14:27]: > On Thu, Nov 14, 2013 at 03:08:42PM -0800, Tony Lindgren wrote: > > Looks like we're missing two lines needed to make it > > work properly with device tree. > > > > Cc: linux-...@vger.kernel.org > > Cc: Aaro Koskinen > > Cc: Wolfram Sang > > Signed-off-by: Tony Lindgren > > Applied to for-next, thanks! Thanks, will drop this one from my fixes series. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 9/8] i2c: Fix device tree binding for i2c-cbus-gpio
On Thu, Nov 14, 2013 at 03:08:42PM -0800, Tony Lindgren wrote: > Looks like we're missing two lines needed to make it > work properly with device tree. > > Cc: linux-...@vger.kernel.org > Cc: Aaro Koskinen > Cc: Wolfram Sang > Signed-off-by: Tony Lindgren Applied to for-next, thanks! signature.asc Description: Digital signature
Re: [PATCH V3] ARM: OMAP2+: omap_device: maintain sane runtime pm status around suspend/resume
Tony Lindgren writes: > * Nishanth Menon [131115 05:30]: >> On 11/15/2013 02:07 AM, Paul Walmsley wrote: >> > On Thu, 14 Nov 2013, Nishanth Menon wrote: >> > >> >> OMAP device hooks around suspend|resume_noirq ensures that hwmod >> >> devices are forced to idle using omap_device_idle/enable as part of >> >> the last stage of suspend activity. >> >> >> >> For a device such as i2c who uses autosuspend, it is possible to enter >> >> the suspend path with dev->power.runtime_status = RPM_ACTIVE. >> >> >> >> As part of the suspend flow, the generic runtime logic would increment >> >> it's dev->power.disable_depth to 1. This should prevent further >> >> pm_runtime_get_sync from succeeding once the runtime_status has been >> >> set to RPM_SUSPENDED. >> >> >> >> Now, as part of the suspend_noirq handler in omap_device, we force the >> >> following: if the device status is !suspended, we force the device >> >> to idle using omap_device_idle (clocks are cut etc..). This ensures >> >> that from a hardware perspective, the device is "suspended". However, >> >> runtime_status is left to be active. >> >> >> >> *if* an operation is attempted after this point to >> >> pm_runtime_get_sync, runtime framework depends on runtime_status to >> >> indicate accurately the device status, and since it sees it to be >> >> ACTIVE, it assumes the module is functional and returns a non-error >> >> value. As a result the user will see pm_runtime_get succeed, however a >> >> register access will crash due to the lack of clocks. >> >> >> >> To prevent this from happening, we should ensure that runtime_status >> >> exactly indicates the device status. As a result of this change >> >> any further calls to pm_runtime_get* would return -EACCES (since >> >> disable_depth is 1). On resume, we restore the clocks and runtime >> >> status exactly as we suspended with. These operations are not expected >> >> to fail as we update the states after the core runtime framework has >> >> suspended itself and restore before the core runtime framework has >> >> resumed. >> >> >> >> Reported-by: J Keerthy >> >> Signed-off-by: Nishanth Menon >> >> Acked-by: Rajendra Nayak >> >> Acked-by: Kevin Hilman >> > >> > Looks reasonable to me. Looks like this should be considered for -stable >> > - Nishanth, what do you think? >> >> Every product kernel since 3.4 needed to be hacked (we have hacked in >> different ways so far) to work around this (since we never spend time >> digging deeper :( ), So, I do agree with your view that a -stable tag >> will be most beneficial. >> >> > >> > Tony or Kevin, do you want to take this one, or want me to? > > I can take it unless you have other fixes pending right now. This version looks good to me. Reviewed-by: Kevin Hilman -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3] ARM: OMAP2+: omap_device: maintain sane runtime pm status around suspend/resume
On Fri, 15 Nov 2013, Tony Lindgren wrote: > I can take it unless you have other fixes pending right now. Ran a quick test with the patch applied on v3.12, results here: http://www.pwsan.com/omap/testlogs/test_nm_omap_device_fix_v3.12-rc/20131115123132/ No other fixes queued here right now, so: Acked-by: Paul Walmsley - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] omap fixes for v3.13 merge window
The following changes since commit 10d0c9705e80bbd3d587c5fad24599aabaca6688: Merge tag 'devicetree-for-3.13' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux (2013-11-12 16:52:17 +0900) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.13/fixes-for-merge-window-take2 for you to fetch changes up to 26273e02a0cf18eb72416559310d3294390a9024: ARM: OMAP2+: Fix build for dra7xx without omap4 and 5 (2013-11-15 08:27:29 -0800) Few clock fixes, a runtime PM fix, and pinctrl-single fix along with few other fixes that popped up during the merge window. Eric Witcher (1): ARM: OMAP: devicetree: fix SPI node compatible property syntax items Joel Fernandes (1): doc: devicetree: Add bindings documentation for omap-des driver Lokesh Vutla (1): ARM: dts: doc: Document missing compatible property for omap-sham driver Nishanth Menon (1): ARM: OMAP2+: omap_device: maintain sane runtime pm status around suspend/resume Roger Quadros (1): pinctrl: single: call pcs_soc->rearm() whenever IRQ mask is changed Tomi Valkeinen (3): ARM: OMAP4: use CLK_SET_RATE_PARENT for dss_dss_clk ARM: OMAP3: use CLK_SET_RATE_PARENT for dss clocks ARM: OMAP3: fix dpll4_m3_ck and dpll4_m4_ck dividers Tony Lindgren (2): Merge tag 'for-v3.13/clock-fixes-a' of git://git.kernel.org/.../pjw/omap-pending into xxx-dt ARM: OMAP2+: Fix build for dra7xx without omap4 and 5 Wei Yongjun (2): ARM: OMAP2+: smsc911x: fix return value check in gpmc_smsc911x_init() ARM: OMAP3: Beagle: fix return value check in beagle_opp_init() .../devicetree/bindings/crypto/omap-des.txt| 30 +++ .../devicetree/bindings/crypto/omap-sham.txt | 2 +- Documentation/devicetree/bindings/spi/omap-spi.txt | 4 +- arch/arm/mach-omap2/Makefile | 2 +- arch/arm/mach-omap2/board-omap3beagle.c| 2 +- arch/arm/mach-omap2/cclock3xxx_data.c | 58 ++ arch/arm/mach-omap2/cclock44xx_data.c | 3 +- arch/arm/mach-omap2/gpmc-smsc911x.c| 2 +- arch/arm/mach-omap2/omap_device.c | 13 - arch/arm/mach-omap2/prm44xx_54xx.h | 3 +- drivers/pinctrl/pinctrl-single.c | 10 ++-- 11 files changed, 103 insertions(+), 26 deletions(-) create mode 100644 Documentation/devicetree/bindings/crypto/omap-des.txt -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/11] Make omap24xx booting device tree based for v3.14 merge window
* Aaro Koskinen [131115 10:48]: > Hi, > > On Thu, Nov 14, 2013 at 04:09:47PM -0800, Tony Lindgren wrote: > > Here are some early patches for the v3.14 merge window to make > > omap2 booting device tree based before we make omap3 device > > tree only. Otherwise we cannot remove the shared platform data > > between omap2 and 3 for things like some hwmod entries. > > > > I've added minimal support for 2430sdp to boot it to serial > > console with ethernet working, and kept n8x0 support using > > the legacy init for the drivers. Then the old H4 I have not > > updated as I'm not using it. > > > > Hopefully if there are still people using n8x0 they can > > pick up the work from here on removing the rest of the legacy > > platform data init as we're planning to drop those things > > completely over next few merge cycles. > > Thanks for the effort, I'll try to continue this work. You can add my > Tested-by for N8x0 bits. > > > Note that these patches are against mainline commit 10d0c9705 > > as there are few device tree related fixes to stuff the resources. > > These also depend on the recently posted fixes series > > "[PATCH 0/8] Various omap device tree usability fixes for v3.13 > > merge window" > > I noticed one bug. If you disable MACH_NOKIA_N8X0 from .config, there > is a compilation failure: > > arch/arm/mach-omap2/built-in.o: In function `omap2420_n8x0_legacy_init': > /home/aaro/git/linux/arch/arm/mach-omap2/pdata-quirks.c:76: undefined > reference to `n8x0_legacy_init' OK thanks for testing, I'll fix that. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 9/8] i2c: Fix device tree binding for i2c-cbus-gpio
Hi, On Thu, Nov 14, 2013 at 03:08:42PM -0800, Tony Lindgren wrote: > Looks like we're missing two lines needed to make it > work properly with device tree. > > Cc: linux-...@vger.kernel.org > Cc: Aaro Koskinen You can change this to: Tested-by: I booted DT-N800 with Tony's patches, and it works. Thanks, A. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/11] Make omap24xx booting device tree based for v3.14 merge window
Hi, On Thu, Nov 14, 2013 at 04:09:47PM -0800, Tony Lindgren wrote: > Here are some early patches for the v3.14 merge window to make > omap2 booting device tree based before we make omap3 device > tree only. Otherwise we cannot remove the shared platform data > between omap2 and 3 for things like some hwmod entries. > > I've added minimal support for 2430sdp to boot it to serial > console with ethernet working, and kept n8x0 support using > the legacy init for the drivers. Then the old H4 I have not > updated as I'm not using it. > > Hopefully if there are still people using n8x0 they can > pick up the work from here on removing the rest of the legacy > platform data init as we're planning to drop those things > completely over next few merge cycles. Thanks for the effort, I'll try to continue this work. You can add my Tested-by for N8x0 bits. > Note that these patches are against mainline commit 10d0c9705 > as there are few device tree related fixes to stuff the resources. > These also depend on the recently posted fixes series > "[PATCH 0/8] Various omap device tree usability fixes for v3.13 > merge window" I noticed one bug. If you disable MACH_NOKIA_N8X0 from .config, there is a compilation failure: arch/arm/mach-omap2/built-in.o: In function `omap2420_n8x0_legacy_init': /home/aaro/git/linux/arch/arm/mach-omap2/pdata-quirks.c:76: undefined reference to `n8x0_legacy_init' A. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] input: touchscreen: fix spelling mistake in TSC/ADC DT binding
Hi, On Fri, Nov 15, 2013 at 03:55:40PM +, Mark Rutland wrote: > > > > > > diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c > > > > > > b/drivers/input/touchscreen/ti_am335x_tsc.c > > > > > > index e1c5300..b61df9d 100644 > > > > > > --- a/drivers/input/touchscreen/ti_am335x_tsc.c > > > > > > +++ b/drivers/input/touchscreen/ti_am335x_tsc.c > > > > > > @@ -348,9 +348,16 @@ static int titsc_parse_dt(struct > > > > > > platform_device *pdev, > > > > > > if (err < 0) > > > > > > return err; > > > > > > > > > > > > - err = of_property_read_u32(node, "ti,coordiante-readouts", > > > > > > + /* > > > > > > +* try with new binding first. If it fails, still try with > > > > > > +* bogus, miss-spelled version. > > > > > > +*/ > > > > > > + err = of_property_read_u32(node, "ti,coordinate-readouts", > > > > > > &ts_dev->coordinate_readouts); > > > > > > if (err < 0) > > > > > > + err = of_property_read_u32(node, > > > > > > "ti,coordiante-readouts", > > > > > > + &ts_dev->coordinate_readouts); > > > > > > + if (err < 0) > > > > > > return err; > > > > > > > > > > Thanks, very good. Do we keep this fallback for ever or just for a > > > > > year > > > > > or two? > > > > > > > > That's for DT maintainers to decide but considering DT is an ABI, I > > > > guess we need to keep for 30 years or so :-p > > > > > > We keep it as long as we have to. If no-one's relying on the typo by the > > > next merge window, I see no reason we'd have to keep support for the > > > > and how could you know that ? considering it's an ABI, how could you > > ever know that ? > > If you know that the only user of a binding is a dts for a particular > product that you're in charge of, then you'd know the set of kernel + > dtb combinations out there, and can judge. once the binding has made into mainline, it's next to impossible to figure out who has downloaded a tarball containing that driver and made a product out of it. Besides keeping that check in the driver won't hurt at all in the long run. I would give it at least until 4.0 before thinking about removing, and that might still not be enough time. -- balbi signature.asc Description: Digital signature
[PATCH] ARM: OMAP2+: Fix build for dra7xx without omap4 and 5
Otherwise we can get errors like: arch/arm/mach-omap2/prm44xx.c:274: error: redefinition of ‘omap44xx_prm_reconfigure_io_chain’ arch/arm/mach-omap2/built-in.o: In function `default_finish_suspend': arch/arm/mach-omap2/omap-mpuss-lowpower.c:95: undefined reference to `omap_do_wfi' Signed-off-by: Tony Lindgren --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -40,7 +40,7 @@ omap-4-5-common = omap4-common.o omap-wakeupgen.o obj-$(CONFIG_ARCH_OMAP4) += $(omap-4-5-common) $(smp-y) sleep44xx.o obj-$(CONFIG_SOC_OMAP5)+= $(omap-4-5-common) $(smp-y) sleep44xx.o obj-$(CONFIG_SOC_AM43XX) += $(omap-4-5-common) -obj-$(CONFIG_SOC_DRA7XX) += $(omap-4-5-common) $(smp-y) +obj-$(CONFIG_SOC_DRA7XX) += $(omap-4-5-common) $(smp-y) sleep44xx.o plus_sec := $(call as-instr,.arch_extension sec,+sec) AFLAGS_omap-headsmp.o :=-Wa,-march=armv7-a$(plus_sec) --- a/arch/arm/mach-omap2/prm44xx_54xx.h +++ b/arch/arm/mach-omap2/prm44xx_54xx.h @@ -42,7 +42,8 @@ extern u32 omap4_prm_vcvp_read(u8 offset); extern void omap4_prm_vcvp_write(u32 val, u8 offset); extern u32 omap4_prm_vcvp_rmw(u32 mask, u32 bits, u8 offset); -#if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5) +#if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5) || \ + defined(CONFIG_SOC_DRA7XX) void omap44xx_prm_reconfigure_io_chain(void); #else static inline void omap44xx_prm_reconfigure_io_chain(void) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 16/51] DMA-API: ppc: vio.c: replace dma_set_mask()+dma_set_coherent_mask() with new helper
Hi, On 09/19/2013 11:41 PM, Russell King wrote: > Replace the following sequence: > > dma_set_mask(dev, mask); > dma_set_coherent_mask(dev, mask); > > with a call to the new helper dma_set_mask_and_coherent(). > > Signed-off-by: Russell King > --- > arch/powerpc/kernel/vio.c |3 +-- > 1 files changed, 1 insertions(+), 2 deletions(-) > > diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c > index 78a3506..96b6c97 100644 > --- a/arch/powerpc/kernel/vio.c > +++ b/arch/powerpc/kernel/vio.c > @@ -1413,8 +1413,7 @@ struct vio_dev *vio_register_device_node(struct > device_node *of_node) > > /* needed to ensure proper operation of coherent allocations >* later, in case driver doesn't set it explicitly */ > - dma_set_mask(&viodev->dev, DMA_BIT_MASK(64)); > - dma_set_coherent_mask(&viodev->dev, DMA_BIT_MASK(64)); > + dma_set_mask_and_coherent(&viodev->dev, DMA_BIT_MASK(64)); > } > > /* register with generic device framework */ > The new helper routine dma_set_mask_and_coherent() breaks the initialization of the pseries vio devices which do not have an initial dev->dma_mask. I think we need to use dma_coerce_mask_and_coherent() instead. Signed-off-by: Cédric Le Goater --- arch/powerpc/kernel/vio.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c index e7d0c88f..76a6482 100644 --- a/arch/powerpc/kernel/vio.c +++ b/arch/powerpc/kernel/vio.c @@ -1419,7 +1419,7 @@ struct vio_dev *vio_register_device_node(struct device_node *of_node) /* needed to ensure proper operation of coherent allocations * later, in case driver doesn't set it explicitly */ - dma_set_mask_and_coherent(&viodev->dev, DMA_BIT_MASK(64)); + dma_coerce_mask_and_coherent(&viodev->dev, DMA_BIT_MASK(64)); } /* register with generic device framework */ -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: OMAP4460: cpuidle: Extend PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD on cpuidle
On Friday 15 November 2013 11:11 AM, Tony Lindgren wrote: > * Taras Kondratiuk [131115 08:03]: >> On 11/15/2013 05:36 PM, Tony Lindgren wrote: >>> * Tony Lindgren [131114 10:36]: * Grygorii Strashko [131022 12:09]: > The same workaround as ff999b8a0983ee15668394ed49e38d3568fc6859 > "ARM: OMAP4460: Workaround for ROM bug because of CA9 r2pX GIC ..." > need to be applied not only when system is booting, but when MPUSS hits > OSWR state through CPUIdle too. Without this WA the same issue is > reproduced now on boards PandaES and Tablet/Blaze with SOM OMAP4460 > when CONFIG_CPU_IDLE is enabled. > After MPUSS has enterred OSWR and waken up: > - GIC distributor became disabled forever > - scheduling is not performed any more > > Cc: Kevin Hilman > Acked-by: Santosh Shilimkar > Reported-by: Taras Kondratiuk > Signed-off-by: Grygorii Strashko Applying into omap-for-v3.13/fixes thanks. >>> >>> Hmm looks like this breaks the build with randconfigs at least >>> with the attached .config, so dropping for now. >> >> Hi Tony >> Have you forgot to attach .config? > > Oops, sorry looks like I removed it already as I rebuilt the tree > and started a new set of randconfig build tests. > >>> arch/arm/mach-omap2/built-in.o: In function `omap_enter_idle_coupled': >>> :(.text+0xb48c): undefined reference to `pm44xx_errata' >> >> I assume that .config doesn't have CONFIG_SMP enabled while >> pm44xx_errata is defined in omap-smp.c. >> I think it should be a separate patch to move pm44xx_errata somewhere >> else, so this patch will remain the same. > > Yes something like that probably. Sounds like that should be then > patches before this fix. > >> Btw, do we need omap_enter_idle_coupled() in UP? > > That should be checked, am43xx may need it. > Nope. omap_enter_idle_coupled() is needed only for SMP systems. UP don't need couple idle functionality as such. Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: OMAP4460: cpuidle: Extend PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD on cpuidle
* Taras Kondratiuk [131115 08:03]: > On 11/15/2013 05:36 PM, Tony Lindgren wrote: > > * Tony Lindgren [131114 10:36]: > >> * Grygorii Strashko [131022 12:09]: > >>> The same workaround as ff999b8a0983ee15668394ed49e38d3568fc6859 > >>> "ARM: OMAP4460: Workaround for ROM bug because of CA9 r2pX GIC ..." > >>> need to be applied not only when system is booting, but when MPUSS hits > >>> OSWR state through CPUIdle too. Without this WA the same issue is > >>> reproduced now on boards PandaES and Tablet/Blaze with SOM OMAP4460 > >>> when CONFIG_CPU_IDLE is enabled. > >>> After MPUSS has enterred OSWR and waken up: > >>> - GIC distributor became disabled forever > >>> - scheduling is not performed any more > >>> > >>> Cc: Kevin Hilman > >>> Acked-by: Santosh Shilimkar > >>> Reported-by: Taras Kondratiuk > >>> Signed-off-by: Grygorii Strashko > >> > >> Applying into omap-for-v3.13/fixes thanks. > > > > Hmm looks like this breaks the build with randconfigs at least > > with the attached .config, so dropping for now. > > Hi Tony > Have you forgot to attach .config? Oops, sorry looks like I removed it already as I rebuilt the tree and started a new set of randconfig build tests. > > arch/arm/mach-omap2/built-in.o: In function `omap_enter_idle_coupled': > > :(.text+0xb48c): undefined reference to `pm44xx_errata' > > I assume that .config doesn't have CONFIG_SMP enabled while > pm44xx_errata is defined in omap-smp.c. > I think it should be a separate patch to move pm44xx_errata somewhere > else, so this patch will remain the same. Yes something like that probably. Sounds like that should be then patches before this fix. > Btw, do we need omap_enter_idle_coupled() in UP? That should be checked, am43xx may need it. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: OMAP4460: cpuidle: Extend PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD on cpuidle
On 11/15/2013 05:36 PM, Tony Lindgren wrote: > * Tony Lindgren [131114 10:36]: >> * Grygorii Strashko [131022 12:09]: >>> The same workaround as ff999b8a0983ee15668394ed49e38d3568fc6859 >>> "ARM: OMAP4460: Workaround for ROM bug because of CA9 r2pX GIC ..." >>> need to be applied not only when system is booting, but when MPUSS hits >>> OSWR state through CPUIdle too. Without this WA the same issue is >>> reproduced now on boards PandaES and Tablet/Blaze with SOM OMAP4460 >>> when CONFIG_CPU_IDLE is enabled. >>> After MPUSS has enterred OSWR and waken up: >>> - GIC distributor became disabled forever >>> - scheduling is not performed any more >>> >>> Cc: Kevin Hilman >>> Acked-by: Santosh Shilimkar >>> Reported-by: Taras Kondratiuk >>> Signed-off-by: Grygorii Strashko >> >> Applying into omap-for-v3.13/fixes thanks. > > Hmm looks like this breaks the build with randconfigs at least > with the attached .config, so dropping for now. Hi Tony Have you forgot to attach .config? > arch/arm/mach-omap2/built-in.o: In function `omap_enter_idle_coupled': > :(.text+0xb48c): undefined reference to `pm44xx_errata' I assume that .config doesn't have CONFIG_SMP enabled while pm44xx_errata is defined in omap-smp.c. I think it should be a separate patch to move pm44xx_errata somewhere else, so this patch will remain the same. Btw, do we need omap_enter_idle_coupled() in UP? -- Taras Kondratiuk -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] input: touchscreen: fix spelling mistake in TSC/ADC DT binding
On Thu, Nov 14, 2013 at 03:54:04PM +, Felipe Balbi wrote: > HI, > > On Thu, Nov 14, 2013 at 11:19:59AM +, Mark Rutland wrote: > > > On Tue, Oct 22, 2013 at 10:42:00AM +0200, Sebastian Andrzej Siewior wrote: > > > > On 10/21/2013 10:13 PM, Felipe Balbi wrote: > > > > > diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c > > > > > b/drivers/input/touchscreen/ti_am335x_tsc.c > > > > > index e1c5300..b61df9d 100644 > > > > > --- a/drivers/input/touchscreen/ti_am335x_tsc.c > > > > > +++ b/drivers/input/touchscreen/ti_am335x_tsc.c > > > > > @@ -348,9 +348,16 @@ static int titsc_parse_dt(struct platform_device > > > > > *pdev, > > > > > if (err < 0) > > > > > return err; > > > > > > > > > > - err = of_property_read_u32(node, "ti,coordiante-readouts", > > > > > + /* > > > > > + * try with new binding first. If it fails, still try with > > > > > + * bogus, miss-spelled version. > > > > > + */ > > > > > + err = of_property_read_u32(node, "ti,coordinate-readouts", > > > > > &ts_dev->coordinate_readouts); > > > > > if (err < 0) > > > > > + err = of_property_read_u32(node, > > > > > "ti,coordiante-readouts", > > > > > + &ts_dev->coordinate_readouts); > > > > > + if (err < 0) > > > > > return err; > > > > > > > > Thanks, very good. Do we keep this fallback for ever or just for a year > > > > or two? > > > > > > That's for DT maintainers to decide but considering DT is an ABI, I > > > guess we need to keep for 30 years or so :-p > > > > We keep it as long as we have to. If no-one's relying on the typo by the > > next merge window, I see no reason we'd have to keep support for the > > and how could you know that ? considering it's an ABI, how could you > ever know that ? If you know that the only user of a binding is a dts for a particular product that you're in charge of, then you'd know the set of kernel + dtb combinations out there, and can judge. If a bug is found in a driver such that it hasn't worked for a number of releases, and no-one's complained, the binding is clearly not in use and thus support for it can be removed. If maintaining compatibility becomes too hard, and all users are happy to migrate to a newer dtb, then it's not necessary to maintain compatiblity for the old binding. While we can't always remove existing bindings, there are cases where it's possible and appropriate. However, we should strive for compatibility for as long a term as possible. Thanks, Mark. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: OMAP4460: cpuidle: Extend PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD on cpuidle
* Tony Lindgren [131114 10:36]: > * Grygorii Strashko [131022 12:09]: > > The same workaround as ff999b8a0983ee15668394ed49e38d3568fc6859 > > "ARM: OMAP4460: Workaround for ROM bug because of CA9 r2pX GIC ..." > > need to be applied not only when system is booting, but when MPUSS hits > > OSWR state through CPUIdle too. Without this WA the same issue is > > reproduced now on boards PandaES and Tablet/Blaze with SOM OMAP4460 > > when CONFIG_CPU_IDLE is enabled. > > After MPUSS has enterred OSWR and waken up: > > - GIC distributor became disabled forever > > - scheduling is not performed any more > > > > Cc: Kevin Hilman > > Acked-by: Santosh Shilimkar > > Reported-by: Taras Kondratiuk > > Signed-off-by: Grygorii Strashko > > Applying into omap-for-v3.13/fixes thanks. Hmm looks like this breaks the build with randconfigs at least with the attached .config, so dropping for now. arch/arm/mach-omap2/built-in.o: In function `omap_enter_idle_coupled': :(.text+0xb48c): undefined reference to `pm44xx_errata' Can you please check and repost? Thanks, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP4+: pm_debug: provide more visibility into suspend failure
Apologies - $subject should have been an RFC PATCH. On 11/15/2013 09:11 AM, Nishanth Menon wrote: [...] -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP4+: pm_debug: provide more visibility into suspend failure
Traditionally on OMAP4+ systems, with complete data properly populated,
we should be able to track down which device prevented the power domain
from transitioning to low power state. This is rather trivial is the
powerdomain to clockdomain to list of clock status registers were easily
accessible. However, it is not. we have linkage from clk->clkdm, and
hwmod to clkdm, however going from clkdm to clk status involves a search
for matches :(.
Previously, we just get:
Powerdomain (XYZ) didn't enter target state 1
Now, we get:
Powerdomain (XYZ) didn't enter target state 1
XYZ: s/w flags(HWSUP_SWSUP HWSUP_ENABLED(int) ) h/w control(enable_auto
)
module-X: functional
This simplifies our debug when hwmod is properly populated with every
device in the SoC and when status bits are properly identified. However,
the alternative to doing this is to replicate actual h/w data in some
other form which duplicates existing infrastructure for the same.
Signed-off-by: Nishanth Menon
---
Traditionally, we have add solutions in production kernel that
duplicated data such as:
3.0:
https://android.googlesource.com/kernel/omap.git/+/android-omap-tuna-3.0-jb-mr2/arch/arm/mach-omap2/prcm-debug.c
3.4:
http://git.omapzoom.org/?p=kernel/omap.git;a=blob;f=arch/arm/mach-omap2/prcm-54xx-debug_data.c;h=26d9b1e74368ec387db86fde6208e37ffeb95d5c;hb=p-linux-omap-3.4
Which for obvious reasons dont make sense in an upstream kernel - the
rationale for duplicated data was the in-development state of pm code
which needed cross verification as well.
The code is a bit dirty, but then, this is just an RFC to see if folks
are interested in this feature. If folks think this actually adds
value, then we can split this up properly and control the prints with
some debugfs control flag (instead of spamming every single time).
we could discuss even on how to make this prettier, do checkpatch,
split into a proper series etc.. just *if* folks think it is worth the
work..
Sample logs (using TI vendor kernel):
DRA7-evm: http://pastebin.mozilla.org/3606008
OMAP5-uEVM: http://pastebin.mozilla.org/3606015
Obviously, could be extended for more TI platforms as well since it
uses the mach-omap2 frameworks - but we could instead decide not to
develop this further till we cleanup hwmod instead of adding new usage
of the same and make that transition harder.. over to folks for comments..
Applies on kernel tag v3.12
arch/arm/mach-omap2/clockdomain.c | 23 ++
arch/arm/mach-omap2/clockdomain.h |5 +++
arch/arm/mach-omap2/cminst44xx.c | 40 +
arch/arm/mach-omap2/pm-debug.c| 85 +
arch/arm/mach-omap2/pm.h |6 +++
arch/arm/mach-omap2/pm44xx.c |1 +
arch/arm/mach-omap2/powerdomain.c |3 +-
7 files changed, 162 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/clockdomain.c
b/arch/arm/mach-omap2/clockdomain.c
index 2da3b5e..6de3860 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -1295,3 +1295,26 @@ int clkdm_hwmod_disable(struct clockdomain *clkdm,
struct omap_hwmod *oh)
return 0;
}
+int clkdm_control_status(struct clockdomain *clkdm, bool *disable_auto, bool
*force_sleep, bool *force_wakeup, bool *enable_auto)
+{
+ /* The clkdm attribute does not exist yet prior OMAP4 */
+ if (cpu_is_omap24xx() || cpu_is_omap34xx())
+ return 0;
+
+ if (!clkdm || !arch_clkdm || !arch_clkdm->clkdm_control_status ||
!disable_auto || !force_sleep || !force_wakeup || !enable_auto)
+ return -EINVAL;
+
+ return arch_clkdm->clkdm_control_status(clkdm, disable_auto,
force_sleep, force_wakeup, enable_auto);
+}
+
+int clkdm_current_status(struct clockdomain *clkdm, struct omap_hwmod *oh,
bool *functional, bool *in_transition, bool *if_idle, bool *disabled)
+{
+ /* The clkdm attribute does not exist yet prior OMAP4 */
+ if (cpu_is_omap24xx() || cpu_is_omap34xx())
+ return 0;
+
+ if (!clkdm || !oh || !arch_clkdm || !arch_clkdm->clkdm_current_status
|| !functional || !in_transition || !if_idle || !disabled)
+ return -EINVAL;
+
+ return arch_clkdm->clkdm_current_status(clkdm, oh, functional,
in_transition, if_idle, disabled);
+}
diff --git a/arch/arm/mach-omap2/clockdomain.h
b/arch/arm/mach-omap2/clockdomain.h
index 4b03394..1048baa 100644
--- a/arch/arm/mach-omap2/clockdomain.h
+++ b/arch/arm/mach-omap2/clockdomain.h
@@ -172,8 +172,13 @@ struct clkdm_ops {
void(*clkdm_deny_idle)(struct clockdomain *clkdm);
int (*clkdm_clk_enable)(struct clockdomain *clkdm);
int (*clkdm_clk_disable)(struct clockdomain *clkdm);
+ int (*clkdm_control_status)(struct clockdomain *clkdm, bool
*disable_auto, bool *force_sleep, bool *force_wakeup, bool *enable_auto);
+ int (*clkdm_current_status)(struct clockdomain *clkdm, struct
omap_hwmod *oh, bool *functional
Re: [PATCH V4 1/4] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs
On Friday 15 November 2013 06:23 AM, Mark Rutland wrote: > On Thu, Nov 14, 2013 at 04:46:36PM +, Sricharan R wrote: >> Hi Mark, >> >> On Thursday 14 November 2013 07:31 PM, Mark Rutland wrote: >>> On Thu, Nov 14, 2013 at 12:18:47PM +, Sricharan R wrote: In some socs the gic can be preceded by a crossbar IP which routes the peripheral interrupts to the gic inputs. The peripheral interrupts are associated with a fixed crossbar input line and the crossbar routes that to one of the free gic input line. The DT entries for peripherals provides the fixed crossbar input line as its interrupt number and the mapping code should associate this with a free gic input line. This patch adds the support inside the gic irqchip to handle such routable irqs. The routable irqs are registered in a linear domain. The registered routable domain's callback should be implemented to get a free irq and to configure the IP to route it. Cc: Thomas Gleixner Cc: Linus Walleij Cc: Santosh Shilimkar Cc: Russell King Cc: Tony Lindgren Cc: Rajendra Nayak Cc: Marc Zyngier Cc: Grant Likely Cc: Rob Herring Signed-off-by: Sricharan R Acked-by: Santosh Shilimkar --- [V2] Added default routable-irqs functions to avoid unnecessary if checks as per Thomas Gleixner comments and renamed routable-irq binding as per Kumar Gala comments. [V3] Addressed unnecessary warn-on and updated default xlate function as per Thomas Gleixner comments Documentation/devicetree/bindings/arm/gic.txt |6 ++ drivers/irqchip/irq-gic.c | 81 ++--- include/linux/irqchip/arm-gic.h |7 ++- 3 files changed, 83 insertions(+), 11 deletions(-) diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt index 3dfb0c0..5357745 100644 --- a/Documentation/devicetree/bindings/arm/gic.txt +++ b/Documentation/devicetree/bindings/arm/gic.txt @@ -49,6 +49,11 @@ Optional regions, used when the GIC doesn't have banked registers. The offset is cpu-offset * cpu-nr. +- arm,routable-irqs : Total number of gic irq inputs which are not directly +connected from the peripherals, but are routed dynamically +by a crossbar/multiplexer preceding the GIC. The GIC irq +input line is assigned dynamically when the corresponding +peripheral's crossbar line is mapped. >>> I'm not keen on the design of the arm,routable-irqs property. The set of >>> IRQs which the crossbar IP can use is a property of which IRQ lines it >>> has routed to the GIC. I don't see why that should be considered a >>> property of the GIC; it's a property of the crossbar IP's attachment to >>> the GIC. >>> >>> Given we already have a mechanism for describing the attachment (i.e. >>> the interrupts property) where the property appears on the node for the >>> device generating/propagating the interrupt, I don't see why we should >>> do differently here. >> We did try using interrupts=<> property for all peripherals and >> mapping them as crossbar's parent. But that approach of representing >> crossbar as a interrupt parent was not accepted, since the crossbar >> was just routing the interrupts from peripherals to GIC and nothing more. >> Also mapping all the interrupts using interrupt-map like property by a >> fixed way >> in DTS itself was considered hacky > > I'm not suggesting you should interrupt-map. I agree that that > interrupt-map is not suitable for a dynamically configurable device like > the crossbar. > > When you say that the crossbar is just routing the interrupts, at what > level is it doing so? Does it accept a logical interrupt and output > another logical interrupt, or does it just connect the two lines > electrically? > Its just makes electrical connection between input and output line and thats it. Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] wl1251: split wl251 platform data to a separate structure
On Fri, Nov 15, 2013 at 09:32:55AM -0500, John W. Linville wrote: > On Thu, Nov 14, 2013 at 03:22:18PM -0800, Tony Lindgren wrote: > > * Sebastian Reichel [131114 15:04]: > > > On Thu, Nov 14, 2013 at 10:51:33AM -0800, Tony Lindgren wrote: > > > > [...] > > > > > > > > If this is not going into v3.13, these will cause conflicts > > > > with the mach-omap2/board-*.c files for v3.14. > > > > > > > > So it might be best to do a minimal header patch first that > > > > can be merged in by both linux-omap and wireless trees. > > > > > > I guess this patch is pretty minimal. It also seems to be acked by > > > the involved Maintainers, so maybe just merge Patch 1 without the > > > other patches? > > > > > > This does not solve the problem with the struct modification from > > > the second patch, but I guess it's the more intrusive patch. > > > > Once at least the first two patches are ready, how about I queue > > them after -rc1 and set up an immutable branch that can be merged > > in by linux-omap tree and the wireless tree? > > That sounds reasonable to me. So what changes do you request for those patches? I will try to update them as soon as possible. -- Sebastian signature.asc Description: Digital signature
Re: [PATCH 1/4] wl1251: split wl251 platform data to a separate structure
On Thu, Nov 14, 2013 at 03:22:18PM -0800, Tony Lindgren wrote: > * Sebastian Reichel [131114 15:04]: > > On Thu, Nov 14, 2013 at 10:51:33AM -0800, Tony Lindgren wrote: > > > [...] > > > > > > If this is not going into v3.13, these will cause conflicts > > > with the mach-omap2/board-*.c files for v3.14. > > > > > > So it might be best to do a minimal header patch first that > > > can be merged in by both linux-omap and wireless trees. > > > > I guess this patch is pretty minimal. It also seems to be acked by > > the involved Maintainers, so maybe just merge Patch 1 without the > > other patches? > > > > This does not solve the problem with the struct modification from > > the second patch, but I guess it's the more intrusive patch. > > Once at least the first two patches are ready, how about I queue > them after -rc1 and set up an immutable branch that can be merged > in by linux-omap tree and the wireless tree? That sounds reasonable to me. -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] ARM: omap: edma: add suspend suspend/resume hooks
On 11/07/2013 02:42 PM, Vaibhav Bedia wrote: > Hi Nishanth :) > On Thu, Nov 7, 2013 at 10:48 AM, Nishanth Menon wrote: >> On 11/07/2013 09:36 AM, Daniel Mack wrote: >>> On 11/07/2013 04:18 PM, Nishanth Menon wrote: Tested this on a vendor V3.12 tag based kernel: Test patch: http://pastebin.com/AmnktQ7B test: echo -n "1">/sys/power/pm_print_times; rtcwake -d /dev/rtc0 -m mem -s 5 with the current patch: http://pastebin.com/RujarRLV suspend_late and resume_early: http://pastebin.com/RujarRLV >>> >>> These two are identical. >>> suspend_noirq and resume_noirq: http://pastebin.com/nKfbm7Mj >>> >>> And I can't see any difference between this one and the first one, >>> except for slightly different timings. Am I missing anything? >> >> aah, that happens to be a little key :) >> if you see the current patch, it happens around line 417, >> with suspend_late, it moves deeper(or later) into suspend around 738 >> with noirq - it is as late as it can get - around line 823 just before >> the last set of arch suspend calls are done. >> > > That's some nifty analysis overnight ;) > > Yeah, the intention was to move the EDMA ops as late as possible. > I am not sure if noirq thing takes care of the late i2c stuff to talk to the > PMICs that happens on some OMAPs. Maybe the generic PM code > handles that already but i am a bit rusty on the details right now so > that would just mention that scenario to be considered. > To trigger the fail, I created a custom Test case on TI vendor kernel based on v3.12 tag: On beagleBone-Black test scenario (BBB): Boot from SD card ensure firmware is loaded (rev 0x182) run LTP fsstress [1] in background on EMMC mkdir -p /tmp/testing mke2fs /dev/mmcblk1p1 mount /dev/mmcblk1p1 /tmp/testing fsstress -d /tmp/testing p 4 -n 1000 -l0 -v >/dev/null & run ping in the background (to add yet another interface) run memtester[2] (70% of free memory) memtester 343M >/dev/null & sleep 10 (to allow memtester to start up properly) start=`date`;i=0; while [ 1 ]; do rtcwake -d /dev/rtc0 -m mem -s 2; i=$((i + 1)); echo "$i: start =$start, now="`date`; sleep 2; done Eventual hang log (using the regular suspend-resume): [3] - took close to two days of testing to trigger this. Moving to a suspend_late and resume_early such as in [4], it passed the test for over 4 days now. Daniel, will be good if you could post [4] for comments if you think that is the right thing to do and helps solve the issue you saw as well. [1] https://github.com/linux-test-project/ltp/tree/master/testcases/kernel/fs/fsstress [2] http://pyropus.ca/software/memtester [3] http://pastebin.pandaboard.org/index.php/view/18307529 [4] https://git.ti.com/ti-linux-kernel/ti-linux-kernel/commit/f8f9a8c38644d27dc8671009209922531b072110 -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3] ARM: OMAP2+: omap_device: maintain sane runtime pm status around suspend/resume
* Nishanth Menon [131115 05:30]: > On 11/15/2013 02:07 AM, Paul Walmsley wrote: > > On Thu, 14 Nov 2013, Nishanth Menon wrote: > > > >> OMAP device hooks around suspend|resume_noirq ensures that hwmod > >> devices are forced to idle using omap_device_idle/enable as part of > >> the last stage of suspend activity. > >> > >> For a device such as i2c who uses autosuspend, it is possible to enter > >> the suspend path with dev->power.runtime_status = RPM_ACTIVE. > >> > >> As part of the suspend flow, the generic runtime logic would increment > >> it's dev->power.disable_depth to 1. This should prevent further > >> pm_runtime_get_sync from succeeding once the runtime_status has been > >> set to RPM_SUSPENDED. > >> > >> Now, as part of the suspend_noirq handler in omap_device, we force the > >> following: if the device status is !suspended, we force the device > >> to idle using omap_device_idle (clocks are cut etc..). This ensures > >> that from a hardware perspective, the device is "suspended". However, > >> runtime_status is left to be active. > >> > >> *if* an operation is attempted after this point to > >> pm_runtime_get_sync, runtime framework depends on runtime_status to > >> indicate accurately the device status, and since it sees it to be > >> ACTIVE, it assumes the module is functional and returns a non-error > >> value. As a result the user will see pm_runtime_get succeed, however a > >> register access will crash due to the lack of clocks. > >> > >> To prevent this from happening, we should ensure that runtime_status > >> exactly indicates the device status. As a result of this change > >> any further calls to pm_runtime_get* would return -EACCES (since > >> disable_depth is 1). On resume, we restore the clocks and runtime > >> status exactly as we suspended with. These operations are not expected > >> to fail as we update the states after the core runtime framework has > >> suspended itself and restore before the core runtime framework has > >> resumed. > >> > >> Reported-by: J Keerthy > >> Signed-off-by: Nishanth Menon > >> Acked-by: Rajendra Nayak > >> Acked-by: Kevin Hilman > > > > Looks reasonable to me. Looks like this should be considered for -stable > > - Nishanth, what do you think? > > Every product kernel since 3.4 needed to be hacked (we have hacked in > different ways so far) to work around this (since we never spend time > digging deeper :( ), So, I do agree with your view that a -stable tag > will be most beneficial. > > > > > Tony or Kevin, do you want to take this one, or want me to? I can take it unless you have other fixes pending right now. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3] ARM: OMAP2+: omap_device: maintain sane runtime pm status around suspend/resume
On 11/15/2013 02:07 AM, Paul Walmsley wrote: > On Thu, 14 Nov 2013, Nishanth Menon wrote: > >> OMAP device hooks around suspend|resume_noirq ensures that hwmod >> devices are forced to idle using omap_device_idle/enable as part of >> the last stage of suspend activity. >> >> For a device such as i2c who uses autosuspend, it is possible to enter >> the suspend path with dev->power.runtime_status = RPM_ACTIVE. >> >> As part of the suspend flow, the generic runtime logic would increment >> it's dev->power.disable_depth to 1. This should prevent further >> pm_runtime_get_sync from succeeding once the runtime_status has been >> set to RPM_SUSPENDED. >> >> Now, as part of the suspend_noirq handler in omap_device, we force the >> following: if the device status is !suspended, we force the device >> to idle using omap_device_idle (clocks are cut etc..). This ensures >> that from a hardware perspective, the device is "suspended". However, >> runtime_status is left to be active. >> >> *if* an operation is attempted after this point to >> pm_runtime_get_sync, runtime framework depends on runtime_status to >> indicate accurately the device status, and since it sees it to be >> ACTIVE, it assumes the module is functional and returns a non-error >> value. As a result the user will see pm_runtime_get succeed, however a >> register access will crash due to the lack of clocks. >> >> To prevent this from happening, we should ensure that runtime_status >> exactly indicates the device status. As a result of this change >> any further calls to pm_runtime_get* would return -EACCES (since >> disable_depth is 1). On resume, we restore the clocks and runtime >> status exactly as we suspended with. These operations are not expected >> to fail as we update the states after the core runtime framework has >> suspended itself and restore before the core runtime framework has >> resumed. >> >> Reported-by: J Keerthy >> Signed-off-by: Nishanth Menon >> Acked-by: Rajendra Nayak >> Acked-by: Kevin Hilman > > Looks reasonable to me. Looks like this should be considered for -stable > - Nishanth, what do you think? Every product kernel since 3.4 needed to be hacked (we have hacked in different ways so far) to work around this (since we never spend time digging deeper :( ), So, I do agree with your view that a -stable tag will be most beneficial. > > Tony or Kevin, do you want to take this one, or want me to? > > > - Paul > -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] dt: binding documentation for isp1704 charger
On Thu, Nov 14, 2013 at 12:38:54PM +, Sebastian Reichel wrote: > Add devicetree binding documentation for isp1704-charger. > > Signed-off-by: Sebastian Reichel > --- > Documentation/devicetree/bindings/power/isp1704.txt | 17 + > 1 file changed, 17 insertions(+) > create mode 100644 Documentation/devicetree/bindings/power/isp1704.txt > > diff --git a/Documentation/devicetree/bindings/power/isp1704.txt > b/Documentation/devicetree/bindings/power/isp1704.txt > new file mode 100644 > index 000..bbeec11 > --- /dev/null > +++ b/Documentation/devicetree/bindings/power/isp1704.txt > @@ -0,0 +1,17 @@ > +Binding for NXP ISP1704 USB Charger Detection > + > +Required properties: > +- compatible: Should contain one of the following: > + * "nxp,isp1704" > +- nxp,enable-gpio: Should contain a phandle to the Nit: phandle + gpio-specifier Otherwise this looks fine. Mark. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4 1/4] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs
On Thu, Nov 14, 2013 at 04:46:36PM +, Sricharan R wrote: > Hi Mark, > > On Thursday 14 November 2013 07:31 PM, Mark Rutland wrote: > > On Thu, Nov 14, 2013 at 12:18:47PM +, Sricharan R wrote: > >> In some socs the gic can be preceded by a crossbar IP which > >> routes the peripheral interrupts to the gic inputs. The peripheral > >> interrupts are associated with a fixed crossbar input line and the > >> crossbar routes that to one of the free gic input line. > >> > >> The DT entries for peripherals provides the fixed crossbar input line > >> as its interrupt number and the mapping code should associate this with > >> a free gic input line. This patch adds the support inside the gic irqchip > >> to handle such routable irqs. The routable irqs are registered in a linear > >> domain. The registered routable domain's callback should be implemented > >> to get a free irq and to configure the IP to route it. > >> > >> Cc: Thomas Gleixner > >> Cc: Linus Walleij > >> Cc: Santosh Shilimkar > >> Cc: Russell King > >> Cc: Tony Lindgren > >> Cc: Rajendra Nayak > >> Cc: Marc Zyngier > >> Cc: Grant Likely > >> Cc: Rob Herring > >> Signed-off-by: Sricharan R > >> Acked-by: Santosh Shilimkar > >> --- > >> [V2] Added default routable-irqs functions to avoid > >> unnecessary if checks as per Thomas Gleixner comments > >> and renamed routable-irq binding as per > >> Kumar Gala comments. > >> > >> [V3] Addressed unnecessary warn-on and updated default > >> xlate function as per Thomas Gleixner comments > >> > >> Documentation/devicetree/bindings/arm/gic.txt |6 ++ > >> drivers/irqchip/irq-gic.c | 81 > >> ++--- > >> include/linux/irqchip/arm-gic.h |7 ++- > >> 3 files changed, 83 insertions(+), 11 deletions(-) > >> > >> diff --git a/Documentation/devicetree/bindings/arm/gic.txt > >> b/Documentation/devicetree/bindings/arm/gic.txt > >> index 3dfb0c0..5357745 100644 > >> --- a/Documentation/devicetree/bindings/arm/gic.txt > >> +++ b/Documentation/devicetree/bindings/arm/gic.txt > >> @@ -49,6 +49,11 @@ Optional > >>regions, used when the GIC doesn't have banked registers. The offset is > >>cpu-offset * cpu-nr. > >> > >> +- arm,routable-irqs : Total number of gic irq inputs which are not > >> directly > >> +connected from the peripherals, but are routed dynamically > >> +by a crossbar/multiplexer preceding the GIC. The GIC irq > >> +input line is assigned dynamically when the corresponding > >> +peripheral's crossbar line is mapped. > > I'm not keen on the design of the arm,routable-irqs property. The set of > > IRQs which the crossbar IP can use is a property of which IRQ lines it > > has routed to the GIC. I don't see why that should be considered a > > property of the GIC; it's a property of the crossbar IP's attachment to > > the GIC. > > > > Given we already have a mechanism for describing the attachment (i.e. > > the interrupts property) where the property appears on the node for the > > device generating/propagating the interrupt, I don't see why we should > > do differently here. > We did try using interrupts=<> property for all peripherals and > mapping them as crossbar's parent. But that approach of representing > crossbar as a interrupt parent was not accepted, since the crossbar > was just routing the interrupts from peripherals to GIC and nothing more. > Also mapping all the interrupts using interrupt-map like property by a > fixed way > in DTS itself was considered hacky I'm not suggesting you should interrupt-map. I agree that that interrupt-map is not suitable for a dynamically configurable device like the crossbar. When you say that the crossbar is just routing the interrupts, at what level is it doing so? Does it accept a logical interrupt and output another logical interrupt, or does it just connect the two lines electrically? We don't necessarily have to use the interrupts property, but I still think that the set of GIC input IRQ lines that the crossbar is wired to should be described on the crossbar node. > > Listing 160 interrupts in the crossbar node is clearly something we > > don't want to have to do. If we had a property that we could use to > > define a range (or multiple ranges) of interrupts, then the crossbar > > driver could go and request those ranges from its interrupt-parent (the > > GIC) and the GIC driver could reserve/allocate the irqdomain at that > > time. > Again, this kind of approach of crossbar requesting irqs from GIC > was tried earlier and it did not go anywhere. Subsequently after lot of > discussions this design was considered the best one. > > http://www.spinics.net/lists/linux-omap/msg97085.html As far as I can see, the comment there was to use irqdomains, which I am not arguing against. I am arguing that the linkage of the GIC and the crossbar is being described the wrong way around. The GIC inpu
Re: [PATCH V4 2/4] DRIVERS: IRQCHIP: CROSSBAR: Add support for Crossbar IP
On Thu, Nov 14, 2013 at 04:41:41PM +, Sricharan R wrote:
> Hi Mark,
>
> On Thursday 14 November 2013 07:42 PM, Mark Rutland wrote:
> > On Thu, Nov 14, 2013 at 12:18:48PM +, Sricharan R wrote:
> >> Some socs have a large number of interrupts requests to service
> >> the needs of its many peripherals and subsystems. All of the
> >> interrupt lines from the subsystems are not needed at the same
> >> time, so they have to be muxed to the irq-controller appropriately.
> >> In such places a interrupt controllers are preceded by an CROSSBAR
> >> that provides flexibility in muxing the device requests to the controller
> >> inputs.
> >>
> >> This driver takes care a allocating a free irq and then configuring the
> >> crossbar IP as a part of the mpu's irqchip callbacks. crossbar_init should
> >> be called right before the irqchip_init, so that it is setup to handle the
> >> irqchip callbacks.
> >>
> >> Cc: Thomas Gleixner
> >> Cc: Linus Walleij
> >> Cc: Santosh Shilimkar
> >> Cc: Russell King
> >> Cc: Tony Lindgren
> >> Cc: Rajendra Nayak
> >> Cc: Marc Zyngier
> >> Cc: Grant Likely
> >> Cc: Rob Herring
> >> Signed-off-by: Sricharan R
> >> Acked-by: Kumar Gala (for DT binding portion)
> >> Acked-by: Santosh Shilimkar
> >> ---
> >> [V2] Addressed Thomas Gleixner comments
> >> and renamed the bindings as per Kumar Gala
> >> comments.
> >> [V3] Changed static inline const to static inline int and removed
> >> unnecessary variable initialization as per
> >> Thomas Gleixner . Updated commit tags
> >> [V4] Renamed crossbar_init as irqcrossbar_init as per
> >> Rajendra Nayak suggestion.
> >>
> >> .../devicetree/bindings/arm/omap/crossbar.txt | 27 +++
> >> drivers/irqchip/Kconfig|8 +
> >> drivers/irqchip/Makefile |1 +
> >> drivers/irqchip/irq-crossbar.c | 206
> >>
> >> include/linux/irqchip/irq-crossbar.h | 11 ++
> >> 5 files changed, 253 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/arm/omap/crossbar.txt
> >> create mode 100644 drivers/irqchip/irq-crossbar.c
> >> create mode 100644 include/linux/irqchip/irq-crossbar.h
> >>
> >> diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt
> >> b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
> >> new file mode 100644
> >> index 000..fb88585
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
> >> @@ -0,0 +1,27 @@
> >> +Some socs have a large number of interrupts requests to service
> >> +the needs of its many peripherals and subsystems. All of the
> >> +interrupt lines from the subsystems are not needed at the same
> >> +time, so they have to be muxed to the irq-controller appropriately.
> >> +In such places a interrupt controllers are preceded by an CROSSBAR
> >> +that provides flexibility in muxing the device requests to the controller
> >> +inputs.
> >> +
> >> +Required properties:
> >> +- compatible : Should be "ti,irq-crossbar"
> >> +- reg: Base address and the size of the crossbar registers.
> >> +- ti,max-irqs: Total number of irqs available at the interrupt controller.
> >> +- ti,reg-size: Size of a individual register in bytes. Every individual
> >> + register is assumed to be of same size. Valid sizes are 1, 2, 4.
> >> +- ti,irqs-reserved: List of the reserved irq lines that are not muxed
> >> using
> >> + crossbar. These interrupt lines are reserved in the soc,
> >> + so crossbar bar driver should not consider them as free
> >> + lines.
> > The combination of the ti,max-irqs and ti,irqs-reserved properties seems
> > backwards to me. Why can we not describe the set of IRQs that _can_ be
> > used?
> Total set of irqs that are usable is max - reserved. Since reserved irqs
> are not continuous, we have to give the list. During the init we count
> the total number of reserved and get the usable one.
So why not describe the set of usable IRQs, rather than a set of IRQs
for which only some are usable then subtracting the set of unusable
IRQs?
It seems backwards to me to have a binding for a device describe
resources it doesn't have.
> >> +
> >> +Examples:
> >> + crossbar_mpu: @4a02 {
> >> + compatible = "ti,irq-crossbar";
> >> + reg = <0x4a002a48 0x130>;
> >> + ti,max-irqs = <160>;
> >> + ti,reg-size = <2>;
> >> + ti,irqs-reserved = <0 1 2 3 5 6 131 132 139 140>;
> >> + };
> > [...]
> >
> >> + /* Get and mark reserved irqs */
> >> + irqsr = of_get_property(node, "ti,irqs-reserved", &size);
> >> + if (irqsr) {
> >> + size /= sizeof(__be32);
> >> +
> >> + for (i = 0; i < size; i++) {
> >> + entry = be32_to_cpup(irqsr + i);
> >> + if (entry > max) {
> >> + pr_err("Invalid rese
Re: 3.12: omap4: cpuidle: solid hangs at boot
+ Kevin Hi Paolo, On Thursday 14 November 2013 04:34 PM, Paolo Pisati wrote: > Vanilla 3.12 multi_v7_defconfig + cpu_idle result in a solid hang on my > pandaes > board: has anyone experienced it before? is cpu_idle safe on omap4? I have also seen the same issue on my panda es board. On further investigation, it seemed to work on 3.11 and broken between 3.12-rc1 and 3.12-rc2 because of the following patch: 7835027 ARM: OMAP4: cpuidle: fix: call cpu_cluster_pm_exit conditionally (http://www.mail-archive.com/linux-omap@vger.kernel.org/msg94655.html) But by applying a recent patch from Grygorii Strashko https://patchwork.kernel.org/patch/3084521/ seems to make it work. You can give a try by applying the given patch. Kevin, please correct me if I am wrong. Thanks and regards, Lokesh > > same kernel boots fine on omap3 and some other arm boards fwiw. > if you want to reproduce it: > > config: http://people.canonical.com/~ppisati/3.12_armv7multi_cpuidle/config > > zImage: http://people.canonical.com/~ppisati/3.12_armv7multi_cpuidle/zImage > > boot log: http://paste.ubuntu.com/6415293/ > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3] ARM: OMAP2+: omap_device: maintain sane runtime pm status around suspend/resume
On Thu, 14 Nov 2013, Nishanth Menon wrote: > OMAP device hooks around suspend|resume_noirq ensures that hwmod > devices are forced to idle using omap_device_idle/enable as part of > the last stage of suspend activity. > > For a device such as i2c who uses autosuspend, it is possible to enter > the suspend path with dev->power.runtime_status = RPM_ACTIVE. > > As part of the suspend flow, the generic runtime logic would increment > it's dev->power.disable_depth to 1. This should prevent further > pm_runtime_get_sync from succeeding once the runtime_status has been > set to RPM_SUSPENDED. > > Now, as part of the suspend_noirq handler in omap_device, we force the > following: if the device status is !suspended, we force the device > to idle using omap_device_idle (clocks are cut etc..). This ensures > that from a hardware perspective, the device is "suspended". However, > runtime_status is left to be active. > > *if* an operation is attempted after this point to > pm_runtime_get_sync, runtime framework depends on runtime_status to > indicate accurately the device status, and since it sees it to be > ACTIVE, it assumes the module is functional and returns a non-error > value. As a result the user will see pm_runtime_get succeed, however a > register access will crash due to the lack of clocks. > > To prevent this from happening, we should ensure that runtime_status > exactly indicates the device status. As a result of this change > any further calls to pm_runtime_get* would return -EACCES (since > disable_depth is 1). On resume, we restore the clocks and runtime > status exactly as we suspended with. These operations are not expected > to fail as we update the states after the core runtime framework has > suspended itself and restore before the core runtime framework has > resumed. > > Reported-by: J Keerthy > Signed-off-by: Nishanth Menon > Acked-by: Rajendra Nayak > Acked-by: Kevin Hilman Looks reasonable to me. Looks like this should be considered for -stable - Nishanth, what do you think? Tony or Kevin, do you want to take this one, or want me to? - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
