* [PATCH 25/30] ARM: OMAP3: omap3pandora: Adapt to ehci-omap changes
From: Roger Quadros @ 2013-01-28 11:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359372631-8180-1-git-send-email-rogerq@ti.com>
Add platform device for 'nop-usb-xceiv'. This will be used as a
PHY for HS USB Port 2, so provide binding information for it.
Model RESET for HS USB Port 2 as GPIO fixed regulator and link
it to the 'nop-usb-xceiv' PHY.
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
arch/arm/mach-omap2/board-omap3pandora.c | 54 +++++++++++++++++++++++++----
1 files changed, 46 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3pandora.c b/arch/arm/mach-omap2/board-omap3pandora.c
index 145a6f8..c2cd1ea 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -23,6 +23,8 @@
#include <linux/spi/spi.h>
#include <linux/regulator/machine.h>
+#include <linux/regulator/fixed.h>
+#include <linux/usb/phy.h>
#include <linux/i2c/twl.h>
#include <linux/wl12xx.h>
#include <linux/mtd/partitions.h>
@@ -560,23 +562,55 @@ fail:
printk(KERN_ERR "wl1251 board initialisation failed\n");
}
+/* PHY device on HS USB Port 2 i.e. nop_usb_xceiv.2 */
+static struct platform_device hsusb2_phy_device = {
+ .name = "nop_usb_xceiv",
+ .id = 2,
+};
+
+/* Regulator for HS USB Port 2 PHY reset */
+static struct regulator_consumer_supply hsusb2_reset_supplies[] = {
+ /* Link PHY device to reset supply so it gets used in the PHY driver */
+ REGULATOR_SUPPLY("reset", "nop_usb_xceiv.2"),
+};
+
+static struct regulator_init_data hsusb2_reset_data = {
+ .constraints = {
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ },
+ .consumer_supplies = hsusb2_reset_supplies,
+ .num_consumer_supplies = ARRAY_SIZE(hsusb2_reset_supplies),
+};
+
+static struct fixed_voltage_config hsusb2_reset_config = {
+ .supply_name = "hsusb2_reset",
+ .microvolts = 3300000,
+ .gpio = 16,
+ .startup_delay = 70000, /* 70msec */
+ .enable_high = 1,
+ .enabled_at_boot = 0, /* keep in RESET */
+ .init_data = &hsusb2_reset_data,
+};
+
+static struct platform_device hsusb2_reset_device = {
+ .name = "reg-fixed-voltage",
+ .id = PLATFORM_DEVID_AUTO,
+ .dev = {
+ .platform_data = &hsusb2_reset_config,
+ },
+};
+
static struct platform_device *omap3pandora_devices[] __initdata = {
&pandora_leds_gpio,
&pandora_keys_gpio,
&pandora_vwlan_device,
&pandora_backlight,
+ &hsusb2_phy_device,
+ &hsusb2_reset_device,
};
static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
-
- .port_mode[0] = OMAP_USBHS_PORT_MODE_UNUSED,
.port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
- .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
-
- .phy_reset = true,
- .reset_gpio_port[0] = -EINVAL,
- .reset_gpio_port[1] = 16,
- .reset_gpio_port[2] = -EINVAL
};
#ifdef CONFIG_OMAP_MUX
@@ -601,6 +635,10 @@ static void __init omap3pandora_init(void)
ARRAY_SIZE(omap3pandora_spi_board_info));
omap_ads7846_init(1, OMAP3_PANDORA_TS_GPIO, 0, NULL);
usbhs_init(&usbhs_bdata);
+
+ /* PHY on HSUSB Port 2 i.e. index 1 */
+ usb_bind_phy("ehci-omap.0", 1, "nop_usb_xceiv.2");
+
usb_musb_init(NULL);
gpmc_nand_init(&pandora_nand_data, NULL);
--
1.7.4.1
^ permalink raw reply related
* [PATCH 26/30] ARM: OMAP3: omap3stalker: Adapt to ehci-omap changes
From: Roger Quadros @ 2013-01-28 11:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359372631-8180-1-git-send-email-rogerq@ti.com>
Add platform device for 'nop-usb-xceiv'. This will be used as a
PHY for HS USB Port 2, so provide binding information for it.
Model RESET for HS USB Port 2 as GPIO fixed regulator and link
it to the 'nop-usb-xceiv' PHY.
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
arch/arm/mach-omap2/board-omap3stalker.c | 52 ++++++++++++++++++++++++++----
1 files changed, 45 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3stalker.c b/arch/arm/mach-omap2/board-omap3stalker.c
index 278ae95..ed343f0 100644
--- a/arch/arm/mach-omap2/board-omap3stalker.c
+++ b/arch/arm/mach-omap2/board-omap3stalker.c
@@ -26,6 +26,7 @@
#include <linux/regulator/fixed.h>
#include <linux/regulator/machine.h>
+#include <linux/usb/phy.h>
#include <linux/i2c/twl.h>
#include <linux/mmc/host.h>
#include <linux/input/matrix_keypad.h>
@@ -357,19 +358,52 @@ static int __init omap3_stalker_i2c_init(void)
#define OMAP3_STALKER_TS_GPIO 175
+/* PHY device on HS USB Port 2 i.e. nop_usb_xceiv.2 */
+static struct platform_device hsusb2_phy_device = {
+ .name = "nop_usb_xceiv",
+ .id = 2,
+};
+
+/* Regulator for HS USB Port 2 PHY reset */
+static struct regulator_consumer_supply hsusb2_reset_supplies[] = {
+ /* Link PHY device to reset supply so it gets used in the PHY driver */
+ REGULATOR_SUPPLY("reset", "nop_usb_xceiv.2"),
+};
+
+static struct regulator_init_data hsusb2_reset_data = {
+ .constraints = {
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ },
+ .consumer_supplies = hsusb2_reset_supplies,
+ .num_consumer_supplies = ARRAY_SIZE(hsusb2_reset_supplies),
+};
+
+static struct fixed_voltage_config hsusb2_reset_config = {
+ .supply_name = "hsusb2_reset",
+ .microvolts = 3300000,
+ .gpio = 21,
+ .startup_delay = 70000, /* 70msec */
+ .enable_high = 1,
+ .enabled_at_boot = 0, /* keep in RESET */
+ .init_data = &hsusb2_reset_data,
+};
+
+static struct platform_device hsusb2_reset_device = {
+ .name = "reg-fixed-voltage",
+ .id = PLATFORM_DEVID_AUTO,
+ .dev = {
+ .platform_data = &hsusb2_reset_config,
+ },
+};
+
static struct platform_device *omap3_stalker_devices[] __initdata = {
&keys_gpio,
+ &hsusb2_phy_device,
+ &hsusb2_reset_device,
};
static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
- .port_mode[0] = OMAP_USBHS_PORT_MODE_UNUSED,
.port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
- .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
-
- .phy_reset = true,
- .reset_gpio_port[0] = -EINVAL,
- .reset_gpio_port[1] = 21,
- .reset_gpio_port[2] = -EINVAL,
};
#ifdef CONFIG_OMAP_MUX
@@ -405,6 +439,10 @@ static void __init omap3_stalker_init(void)
omap_serial_init();
omap_sdrc_init(mt46h32m32lf6_sdrc_params, NULL);
usb_musb_init(NULL);
+
+ /* PHY on HSUSB Port 2 i.e. index 1 */
+ usb_bind_phy("ehci-omap.0", 1, "nop_usb_xceiv.2");
+
usbhs_init(&usbhs_bdata);
omap_ads7846_init(1, OMAP3_STALKER_TS_GPIO, 310, NULL);
--
1.7.4.1
^ permalink raw reply related
* [PATCH 27/30] ARM: OMAP3: omap3touchbook: Adapt to ehci-omap changes
From: Roger Quadros @ 2013-01-28 11:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359372631-8180-1-git-send-email-rogerq@ti.com>
Add 2 platform devices for 'nop-usb-xceiv'. These will be used as a
PHY for HS USB Ports 1 and 2, so provide binding information for them.
Model RESET for HS USB Port 2 as GPIO fixed regulator and link it
to the respective 'nop-usb-xceiv' PHY.
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
arch/arm/mach-omap2/board-omap3touchbook.c | 62 ++++++++++++++++++++++++---
1 files changed, 55 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3touchbook.c b/arch/arm/mach-omap2/board-omap3touchbook.c
index 65a285f..3e00dbf 100644
--- a/arch/arm/mach-omap2/board-omap3touchbook.c
+++ b/arch/arm/mach-omap2/board-omap3touchbook.c
@@ -35,6 +35,8 @@
#include <linux/spi/ads7846.h>
#include <linux/regulator/machine.h>
+#include <linux/regulator/fixed.h>
+#include <linux/usb/phy.h>
#include <linux/i2c/twl.h>
#include <asm/mach-types.h>
@@ -304,21 +306,61 @@ static struct omap_board_mux board_mux[] __initdata = {
};
#endif
+/* PHY device on HS USB Port 1 i.e. nop_usb_xceiv.1 */
+static struct platform_device hsusb1_phy_device = {
+ .name = "nop_usb_xceiv",
+ .id = 1,
+};
+
+/* PHY device on HS USB Port 2 i.e. nop_usb_xceiv.2 */
+static struct platform_device hsusb2_phy_device = {
+ .name = "nop_usb_xceiv",
+ .id = 2,
+};
+
+/* Regulator for HS USB Port 2 PHY reset */
+static struct regulator_consumer_supply hsusb2_reset_supplies[] = {
+ /* Link PHY device to reset supply so it gets used in the PHY driver */
+ REGULATOR_SUPPLY("reset", "nop_usb_xceiv.2"),
+};
+
+static struct regulator_init_data hsusb2_reset_data = {
+ .constraints = {
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ },
+ .consumer_supplies = hsusb2_reset_supplies,
+ .num_consumer_supplies = ARRAY_SIZE(hsusb2_reset_supplies),
+};
+
+static struct fixed_voltage_config hsusb2_reset_config = {
+ .supply_name = "hsusb2_reset",
+ .microvolts = 3300000,
+ .gpio = 147,
+ .startup_delay = 70000, /* 70msec */
+ .enable_high = 1,
+ .enabled_at_boot = 0, /* keep in RESET */
+ .init_data = &hsusb2_reset_data,
+};
+
+static struct platform_device hsusb2_reset_device = {
+ .name = "reg-fixed-voltage",
+ .id = PLATFORM_DEVID_AUTO,
+ .dev = {
+ .platform_data = &hsusb2_reset_config,
+ },
+};
+
static struct platform_device *omap3_touchbook_devices[] __initdata = {
&leds_gpio,
&keys_gpio,
+ &hsusb1_phy_device,
+ &hsusb2_phy_device,
+ &hsusb2_reset_device,
};
static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
-
.port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
.port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
- .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
-
- .phy_reset = true,
- .reset_gpio_port[0] = -EINVAL,
- .reset_gpio_port[1] = 147,
- .reset_gpio_port[2] = -EINVAL
};
static void omap3_touchbook_poweroff(void)
@@ -366,6 +408,12 @@ static void __init omap3_touchbook_init(void)
/* Touchscreen and accelerometer */
omap_ads7846_init(4, OMAP3_TS_GPIO, 310, &ads7846_pdata);
usb_musb_init(NULL);
+
+ /* PHY on HSUSB Port 1 i.e. index 0 */
+ usb_bind_phy("ehci-omap.0", 0, "nop_usb_xceiv.1");
+ /* PHY on HSUSB Port 2 i.e. index 1 */
+ usb_bind_phy("ehci-omap.0", 1, "nop_usb_xceiv.2");
+
usbhs_init(&usbhs_bdata);
board_nand_init(omap3touchbook_nand_partitions,
ARRAY_SIZE(omap3touchbook_nand_partitions), NAND_CS,
--
1.7.4.1
^ permalink raw reply related
* [PATCH 1/6 v14] gpio: Add a block GPIO API to gpiolib
From: Stijn Devriendt @ 2013-01-28 11:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51053268.2000002@antcom.de>
On Sun, Jan 27, 2013 at 2:58 PM, Roland Stigge <stigge@antcom.de> wrote:
> On 27/01/13 14:19, Stijn Devriendt wrote:
>>> +Block GPIO
>>> +----------
>>> +
>>> +The above described interface concentrates on handling single GPIOs. However,
>>> +in applications where it is critical to set several GPIOs at once, this
>>> +interface doesn't work well, e.g. bit-banging protocols via grouped GPIO lines.
>>> +Consider a GPIO controller that is connected via a slow I2C line. When
>>> +switching two or more GPIOs one after another, there can be considerable time
>>> +between those events. This is solved by an interface called Block GPIO:
>>> +
>>> +struct gpio_block *gpio_block_create(unsigned int *gpios, size_t size,
>>> + const char *name);
>>> +
>>> +This creates a new block of GPIOs as a list of GPIO numbers with the specified
>>> +size which are accessible via the returned struct gpio_block and the accessor
>>> +functions described below. Please note that you need to request the GPIOs
>>> +separately via gpio_request(). Similarly, the direction of the used GPIOs need
>>> +to be set by the user before using the block.
>>
>> Is there anything holding you back from letting gpio_block_create() do
>> the request
>> for all the pins?
>
> It's analoguous to plain GPIOs: They exist, but are not requested (by
> whom?) by default.
>
This is one of the warts of the GPIO API, if you ask me (and probably
others too).
Using a resource without allocating it first is just asking for
trouble. It's one of those
things pinctl was designed to solve... I've been thinking about
spending spare time
sending out patches converting all implicit requests and then removing
the implicit
request, but spare time is limited...
Regards,
Stijn
>> Also, wouldn't it make sense to have a gpio_block_direction_input()
>> and _output()
>> variant? On the other hand, for things like I2C and SPI emulation,
>> some pins will
>> naturally be always output (like clock lines) while other could be
>> switched between
>> in and output (like the i2c data line).
>
> Right. Current implementation emphasizes on switching, not direction or
> other convenience functions, which could be added, nevertheless.
>
> Roland
^ permalink raw reply
* [PATCH 28/30] ARM: OMAP3: overo: Adapt to ehci-omap changes
From: Roger Quadros @ 2013-01-28 11:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359372631-8180-1-git-send-email-rogerq@ti.com>
Add platform device for 'nop-usb-xceiv'. This will be used as a
PHY for HS USB Port 2, so provide binding information for it.
Model RESET for HS USB Port 2 as GPIO fixed regulator and link
it to the 'nop-usb-xceiv' PHY.
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
arch/arm/mach-omap2/board-overo.c | 55 +++++++++++++++++++++++++++++++++----
1 files changed, 49 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/board-overo.c b/arch/arm/mach-omap2/board-overo.c
index b1b0f09..5c6ea7d 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -31,6 +31,7 @@
#include <linux/regulator/machine.h>
#include <linux/regulator/fixed.h>
#include <linux/spi/spi.h>
+#include <linux/usb/phy.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/nand.h>
@@ -457,14 +458,51 @@ static int __init overo_spi_init(void)
return 0;
}
+/* PHY device on HS USB Port 2 i.e. nop_usb_xceiv.2 */
+static struct platform_device hsusb2_phy_device = {
+ .name = "nop_usb_xceiv",
+ .id = 2,
+};
+
+/* Regulator for HS USB Port 2 PHY reset */
+static struct regulator_consumer_supply hsusb2_reset_supplies[] = {
+ /* Link PHY device to reset supply so it gets used in the PHY driver */
+ REGULATOR_SUPPLY("reset", "nop_usb_xceiv.2"),
+};
+
+static struct regulator_init_data hsusb2_reset_data = {
+ .constraints = {
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ },
+ .consumer_supplies = hsusb2_reset_supplies,
+ .num_consumer_supplies = ARRAY_SIZE(hsusb2_reset_supplies),
+};
+
+static struct fixed_voltage_config hsusb2_reset_config = {
+ .supply_name = "hsusb2_reset",
+ .microvolts = 3300000,
+ .gpio = OVERO_GPIO_USBH_NRESET,
+ .startup_delay = 70000, /* 70msec */
+ .enable_high = 1,
+ .enabled_at_boot = 0, /* keep in RESET */
+ .init_data = &hsusb2_reset_data,
+};
+
+static struct platform_device hsusb2_reset_device = {
+ .name = "reg-fixed-voltage",
+ .id = PLATFORM_DEVID_AUTO,
+ .dev = {
+ .platform_data = &hsusb2_reset_config,
+ },
+};
+
+static struct platform_device *overo_devices[] __initdata = {
+ &hsusb2_phy_device,
+ &hsusb2_reset_device,
+};
+
static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
- .port_mode[0] = OMAP_USBHS_PORT_MODE_UNUSED,
.port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
- .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
- .phy_reset = true,
- .reset_gpio_port[0] = -EINVAL,
- .reset_gpio_port[1] = OVERO_GPIO_USBH_NRESET,
- .reset_gpio_port[2] = -EINVAL
};
#ifdef CONFIG_OMAP_MUX
@@ -499,7 +537,12 @@ static void __init overo_init(void)
mt46h32m32lf6_sdrc_params);
board_nand_init(overo_nand_partitions,
ARRAY_SIZE(overo_nand_partitions), NAND_CS, 0, NULL);
+ platform_add_devices(overo_devices, ARRAY_SIZE(overo_devices));
usb_musb_init(NULL);
+
+ /* PHY on HSUSB Port 2 i.e. index 1 */
+ usb_bind_phy("ehci-omap.0", 1, "nop_usb_xceiv.2");
+
usbhs_init(&usbhs_bdata);
overo_spi_init();
overo_init_smsc911x();
--
1.7.4.1
^ permalink raw reply related
* [PATCH 29/30] ARM: OMAP: zoom: Adapt to ehci-omap changes
From: Roger Quadros @ 2013-01-28 11:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359372631-8180-1-git-send-email-rogerq@ti.com>
Add platform device for 'nop-usb-xceiv'. This will be used as a
PHY for HS USB Port 2, so provide binding information for it.
Model RESET for HS USB Port 2 as GPIO fixed regulator and link
it to the 'nop-usb-xceiv' PHY.
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
arch/arm/mach-omap2/board-zoom.c | 56 +++++++++++++++++++++++++++++++++----
1 files changed, 50 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom.c b/arch/arm/mach-omap2/board-zoom.c
index 2d7a457..d258632 100644
--- a/arch/arm/mach-omap2/board-zoom.c
+++ b/arch/arm/mach-omap2/board-zoom.c
@@ -17,6 +17,9 @@
#include <linux/gpio.h>
#include <linux/i2c/twl.h>
#include <linux/mtd/nand.h>
+#include <linux/regulator/machine.h>
+#include <linux/regulator/fixed.h>
+#include <linux/usb/phy.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
@@ -92,14 +95,51 @@ static struct mtd_partition zoom_nand_partitions[] = {
},
};
+/* PHY device on HS USB Port 2 i.e. nop_usb_xceiv.2 */
+static struct platform_device hsusb2_phy_device = {
+ .name = "nop_usb_xceiv",
+ .id = 2,
+};
+
+/* Regulator for HS USB Port 2 PHY reset */
+static struct regulator_consumer_supply hsusb2_reset_supplies[] = {
+ /* Link PHY device to reset supply so it gets used in the PHY driver */
+ REGULATOR_SUPPLY("reset", "nop_usb_xceiv.2"),
+};
+
+static struct regulator_init_data hsusb2_reset_data = {
+ .constraints = {
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ },
+ .consumer_supplies = hsusb2_reset_supplies,
+ .num_consumer_supplies = ARRAY_SIZE(hsusb2_reset_supplies),
+};
+
+static struct fixed_voltage_config hsusb2_reset_config = {
+ .supply_name = "hsusb2_reset",
+ .microvolts = 3300000,
+ .gpio = ZOOM3_EHCI_RESET_GPIO,
+ .startup_delay = 70000, /* 70msec */
+ .enable_high = 1,
+ .enabled_at_boot = 0, /* keep in RESET */
+ .init_data = &hsusb2_reset_data,
+};
+
+static struct platform_device hsusb2_reset_device = {
+ .name = "reg-fixed-voltage",
+ .id = PLATFORM_DEVID_AUTO,
+ .dev = {
+ .platform_data = &hsusb2_reset_config,
+ },
+};
+
+static struct platform_device *zoom3_devices[] __initdata = {
+ &hsusb2_phy_device,
+ &hsusb2_reset_device,
+};
+
static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
- .port_mode[0] = OMAP_USBHS_PORT_MODE_UNUSED,
.port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
- .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
- .phy_reset = true,
- .reset_gpio_port[0] = -EINVAL,
- .reset_gpio_port[1] = ZOOM3_EHCI_RESET_GPIO,
- .reset_gpio_port[2] = -EINVAL,
};
static void __init omap_zoom_init(void)
@@ -109,6 +149,10 @@ static void __init omap_zoom_init(void)
} else if (machine_is_omap_zoom3()) {
omap3_mux_init(board_mux, OMAP_PACKAGE_CBP);
omap_mux_init_gpio(ZOOM3_EHCI_RESET_GPIO, OMAP_PIN_OUTPUT);
+
+ platform_add_devices(zoom3_devices, ARRAY_SIZE(zoom3_devices));
+ /* PHY on HSUSB Port 2 i.e. index 1 */
+ usb_bind_phy("ehci-omap.0", 1, "nop_usb_xceiv.2");
usbhs_init(&usbhs_bdata);
}
--
1.7.4.1
^ permalink raw reply related
* [PATCH 30/30] ARM: OMAP: USB: Remove unused fields from struct usbhs_omap_platform_data
From: Roger Quadros @ 2013-01-28 11:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359372631-8180-1-git-send-email-rogerq@ti.com>
All users have been adapted to the changes in ehci-omap. We can now
get rid of the unused fields from usbhs_omap_platform_data.
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
include/linux/platform_data/usb-omap.h | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/include/linux/platform_data/usb-omap.h b/include/linux/platform_data/usb-omap.h
index 925a4a7..227601f 100644
--- a/include/linux/platform_data/usb-omap.h
+++ b/include/linux/platform_data/usb-omap.h
@@ -41,13 +41,10 @@ enum usbhs_omap_port_mode {
struct usbhs_omap_platform_data {
int nports;
enum usbhs_omap_port_mode port_mode[OMAP3_HS_USB_PORTS];
- int reset_gpio_port[OMAP3_HS_USB_PORTS];
- struct regulator *regulator[OMAP3_HS_USB_PORTS];
/* OMAP3 <= ES2.1 have a single ulpi bypass control bit */
unsigned single_ulpi_bypass:1;
unsigned es2_compatibility:1;
- unsigned phy_reset:1;
};
/*-------------------------------------------------------------------------*/
--
1.7.4.1
^ permalink raw reply related
* [PATCH 09/26] mfd: ab8500-debugfs: Provide a means for a user subscribe to IRQs
From: Lee Jones @ 2013-01-28 11:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130128104933.GY1174@sortiz-mobl>
On Mon, 28 Jan 2013, Samuel Ortiz wrote:
> Hi Lee,
>
> On Mon, Jan 28, 2013 at 10:22:23AM +0000, Lee Jones wrote:
> > On Mon, 28 Jan 2013, Samuel Ortiz wrote:
> >
> > > Hi Lee,
> > >
> > > On Tue, Jan 15, 2013 at 12:55:49PM +0000, Lee Jones wrote:
> > > > Allow users to subscribe to and view IRQ events live from debugfs.
> > > I seem to remember that I got a similar patch some time ago for the same
> > > purpose and my answer was: Please use a UIO driver for this. There already is
> > > such driver, it's uio_pdrv_genirq. What your debugfs registration entry could
> > > do is adding a platform device for the specific interrupt number. This would
> > > avoid the irq handler registration and the sysfs entry creation, both things I
> > > believe are not very elegant and open coded. It also gives you an IRQ count
> > > implementation.
> > > Ideally, the UIO framework could be improved to support IRQ ranges (through
> > > IRQ domains) instead of the current single interrupt number.
> > >
> > > Have you considered going through that path ?
> >
> > I'm going to have to put this patch-set in the bin. Pulling this
> > patch, causes lots of conflicts to the remaining patches in the
> > set.
> I bet removing this one causes a lot of conflicts. I'm not saying it should
> absolutely be removed, but I'm afraid once it's upstream no one is going to
> look at improving it.
This is really not the case. I have every intention of fixing each and
every issue which are brought to my attention during the upstreaming
process of 'drivers/regulators', 'drivers/power' and 'drivers/mfd'.
All I'm doing is making a list of all the fixups and re-writes and
I'll address them on the completion of the push. Hence if you're happy
for this to go in with my promise of improvement, it would certainly
make this task a great deal easier for me.
> And to be honest, having an IRQ handler from debugfs
> code looks weird to me. I know you can put all sort of crazyness into a
> debugfs entry, but still.
>
> > I'll start again from scratch and find another way to sync the ab* MFD
> > drivers. I might even have to do it manually i.e. throw out all
> > commit history and upstream it as my own patches pulled in from diffs.
> I don't have any problems with that.
I'm sure you don't, but it's me that's doing all the hard work. ;)
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* OMAP baseline test results for v3.8-rc5
From: Felipe Balbi @ 2013-01-28 11:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <C8443D0743D26F4388EA172BF4E2A7A93EA9456A@DBDE01.ent.ti.com>
Hi,
On Mon, Jan 28, 2013 at 11:34:15AM +0100, Mohammed, Afzal wrote:
> Hi,
>
> On Sat, Jan 26, 2013 at 14:16:04, Balbi, Felipe wrote:
> > On Sat, Jan 26, 2013 at 08:40:07AM +0000, Paul Walmsley wrote:
>
> > > * am335xbone: hangs after "Starting kernel"
> > > - Cause unknown; may be due to CONFIG_EARLY_PRINTK=y?
> > > - http://www.mail-archive.com/linux-omap at vger.kernel.org/msg82297.html
> > > - http://marc.info/?l=linux-omap&m=135903184512238&w=2
> >
> > FYI, I don't think it's related to CONFIG_EARLY_PRINTK. Tested with and
> > without it, also removed CONFIG_DEBUG_LL completely and nothing seemed
> > to help my bone, no matter if I had appended DTB or not.
>
> Following patch with low level debug may help to find where the issue is,
> (my observation is that it boots with mainline u-boot)
>
> Regards
> Afzal
>
>
> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> index 41b581f..178a411 100644
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -117,6 +117,10 @@ config SOC_AM33XX
> select CPU_V7
> select MULTI_IRQ_HANDLER
> select COMMON_CLK
> + select MACH_AM335XEVM
> +
> +config MACH_AM335XEVM
> + bool
>
> config OMAP_PACKAGE_ZAF
> bool
seems to be a bug with __unflatten_device_tree()...
U-Boot SPL 2013.01-00009-g54b08ef (Jan 25 2013 - 10:26:10)
OMAP SD/MMC: 0
reading u-boot.img
reading u-boot.img
U-Boot 2013.01-00009-g54b08ef (Jan 25 2013 - 10:26:10)
I2C: ready
DRAM: 512 MiB
WARNING: Caches not enabled
NAND: No NAND device found!!!
0 MiB
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
*** Warning - readenv() failed, using default environment
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Peripheral mode controller at 47401000 using PIO, IRQ 0
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Host mode controller at 47401800 using PIO, IRQ 0
Net: cpsw, usb_ether
Hit any key to stop autoboot: 1 \b\b\b 0
U-Boot#
U-Boot# ext2load mmc ${mmcdev}:2 0x80f80000 /boot/am335x-bone.dtb
7967 bytes read in 17 ms (457 KiB/s)
U-Boot# setenv bootargs console=${console} ${optargs} root=${mmcroot} rootfstype=${mmcrootfstype} debug earlyprintk mem=256M
U-Boot# ext2load mmc ${mmcdev}:2 ${loadaddr} ${bootfile}
4265360 bytes read in 502 ms (8.1 MiB/s)
U-Boot# bootm 0x80200000 - 0x80f80000
## Booting kernel from Legacy Image at 80200000 ...
Image Name: Linux-3.8.0-rc5-02311-g1308c2b-d
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 4265296 Bytes = 4.1 MiB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
## Flattened Device Tree blob at 80f80000
Booting using the fdt blob at 0x80f80000
Loading Kernel Image ... OK
OK
Loading Device Tree to 9fe3e000, end 9fe42f1e ... OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 3.8.0-rc5-02311-g1308c2b-dirty (balbi at arwen) (gcc version 4.6.3 (Sourcery CodeBench Lite 2012.03-57) ) #37 SMP Mon Jan 28 13:32:47 EET 2013
[ 0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[ 0.000000] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x BeagleBone
[ 0.000000] bootconsole [earlycon0] enabled
[ 0.000000] Memory policy: ECC disabled, Data cache writeback
[ 0.000000] On node 0 totalpages: 65280
[ 0.000000] free_area_init_node: node 0, pgdat c08331c0, node_mem_map c0d91000
[ 0.000000] Normal zone: 512 pages used for memmap
[ 0.000000] Normal zone: 0 pages reserved
[ 0.000000] Normal zone: 64768 pages, LIFO batch:15
[ 0.000000] Unable to handle kernel paging request at virtual address dfe3e000
[ 0.000000] pgd = c0004000
[ 0.000000] [dfe3e000] *pgd=00000000
[ 0.000000] Internal error: Oops: 5 [#1] SMP ARM
[ 0.000000] Modules linked in:
[ 0.000000] CPU: 0 Not tainted (3.8.0-rc5-02311-g1308c2b-dirty #37)
[ 0.000000] PC is at __unflatten_device_tree+0x1c/0x12c
[ 0.000000] LR is at unflatten_device_tree+0x1c/0x34
[ 0.000000] pc : [<c0457d2c>] lr : [<c077a370>] psr: a0000193
[ 0.000000] sp : c07a5f80 ip : 00000000 fp : 00000000
[ 0.000000] r10: 00000000 r9 : 413fc082 r8 : 80004059
[ 0.000000] r7 : c0755dd0 r6 : c0783ac0 r5 : dfe3e000 r4 : c0755dd0
[ 0.000000] r3 : d00dfeed r2 : c0755dd0 r1 : c0d8a8d4 r0 : dfe3e000
[ 0.000000] Flags: NzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
[ 0.000000] Control: 10c5387d Table: 80004019 DAC: 00000017
[ 0.000000] Process swapper (pid: 0, stack limit = 0xc07a4240)
[ 0.000000] Stack: (0xc07a5f80 to 0xc07a6000)
[ 0.000000] 5f80: c07b13d0 c00503b4 8fefffff c0d8a8d4 c0755dd0 c083607c c0783ac0 c07a5fe4
[ 0.000000] 5fa0: 80004059 c077a370 c0781dd8 c0755028 00000000 c07a5fc4 c0783abc 00000001
[ 0.000000] 5fc0: 00000000 c0783abc c07b11c4 c0751618 00000000 00000000 00000000 00000000
[ 0.000000] 5fe0: 00000000 c0783ac0 00000000 10c53c7d c07ac98c 80008078 00000000 00000000
[ 0.000000] [<c0457d2c>] (__unflatten_device_tree+0x1c/0x12c) from [<c077a370>] (unflatten_device_tree+0x1c/0x34)
[ 0.000000] [<c077a370>] (unflatten_device_tree+0x1c/0x34) from [<c0755028>] (setup_arch+0xf8/0x190)
[ 0.000000] [<c0755028>] (setup_arch+0xf8/0x190) from [<c0751618>] (start_kernel+0x80/0x2a8)
[ 0.000000] [<c0751618>] (start_kernel+0x80/0x2a8) from [<80008078>] (0x80008078)
[ 0.000000] Code: e1a07002 e58d100c 0a000033 e59f30f4 (e5951000)
[ 0.000000] ---[ end trace 1b75b31a2719ed1c ]---
[ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130128/f83adee0/attachment.sig>
^ permalink raw reply
* [PATCH 5/6 v14] gpio: Add device tree support to block GPIO API
From: Stijn Devriendt @ 2013-01-28 11:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <510539C5.8000208@antcom.de>
On Sun, Jan 27, 2013 at 3:29 PM, Roland Stigge <stigge@antcom.de> wrote:
> On 27/01/13 14:07, Stijn Devriendt wrote:
>>> +Example:
>>> +
>>> + blockgpio {
>>> + compatible = "linux,gpio-block";
>>> +
>>> + block0 {
>>> + gpios = <&gpio 3 0 0>,
>>> + <&gpio 3 1 0>;
>>> + };
>>> + block1 {
>>> + gpios = <&gpio 4 1 0>,
>>> + <&gpio 4 3 0>,
>>> + <&gpio 4 2 0>,
>>> + <&gpio 4 4 0>,
>>> + <&gpio 4 5 0>,
>>> + <&gpio 4 6 0>,
>>> + <&gpio 4 7 0>,
>>> + <&gpio 4 8 0>,
>>> + <&gpio 4 9 0>,
>>> + <&gpio 4 10 0>,
>>> + <&gpio 4 19 0>;
>>> + };
>>> + };
>>
>> How do you see bindings for other kinds of drivers?
>>
>> In my patchset, it's possible for other drivers to use gpio-blocks.
>> One example we have is a power sequencer with 2 pins attached
>> to GPIO pins. These 2 pins form a 2bit word to select power margining.
>> These 2 pins need to be set synchronously (as otherwise when going
>> from profile 0 to profile 3 you pass either profile 1 or profile 2 which
>> could be bad for hardware)
>>
>> In the device-tree this is specified as:
>>
>> powr at 0x20 {
>> // other properties
>>
>> gpios = <&gpio 4 0
>> &gpio 5 0>;
>> };
>>
>> Is this kind of integration also possible?
>
> You can reference the gpio block via a phandle, e.g.:
>
> blockgpio {
> compatible = "linux,gpio-block";
>
> selector1 {
> gpios = <&gpio 4 0>,
> <&gpio 5 0>;
> };
> };
>
> powr at 0x20 {
> // ...
>
> gpios = <&selector1>;
> };
>
>
> In the driver, you can get the gpio block like this:
>
> block = gpio_block_find_by_name(of_parse_phandle(powr, "gpios", 0)->name);
>
> (Simplified by removed error/NULL handling!)
>
> If this turns out to be a common pattern, I can add a convenience "get"
> function for this.
Given the pick-up of device-tree in ARM and MIPS, I think this stands
a good chance
of becoming a common pattern. Do mind the "gpios" name; it's already used by the
normal GPIO request functions...
This is one of the things I liked about my patch, there's little
difference between
using a group of GPIOs versus multiple separate GPIOs. The device-tree
description
is the same, only the driver handles them differently.
You could ask the question whether the device-tree should make a
difference between
1 GPIO, 2 separate GPIOs or 3 GPIOs in a block. For a H/W description
language it's
all the same. It is an implementation detail of the OS/drivers whether
they handle them
as a block or as separate GPIOs.
Regards,
Stijn
^ permalink raw reply
* OMAP baseline test results for v3.8-rc5
From: Mark Jackson @ 2013-01-28 11:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <C8443D0743D26F4388EA172BF4E2A7A93EA9456A@DBDE01.ent.ti.com>
On 28/01/13 10:34, Mohammed, Afzal wrote:
> Hi,
>
> On Sat, Jan 26, 2013 at 14:16:04, Balbi, Felipe wrote:
>> On Sat, Jan 26, 2013 at 08:40:07AM +0000, Paul Walmsley wrote:
>
>>> * am335xbone: hangs after "Starting kernel"
>>> - Cause unknown; may be due to CONFIG_EARLY_PRINTK=y?
>>> - http://www.mail-archive.com/linux-omap at vger.kernel.org/msg82297.html
>>> - http://marc.info/?l=linux-omap&m=135903184512238&w=2
>>
>> FYI, I don't think it's related to CONFIG_EARLY_PRINTK. Tested with and
>> without it, also removed CONFIG_DEBUG_LL completely and nothing seemed
>> to help my bone, no matter if I had appended DTB or not.
>
> Following patch with low level debug may help to find where the issue is,
> (my observation is that it boots with mainline u-boot)
>
> Regards
> Afzal
>
>
> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> index 41b581f..178a411 100644
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -117,6 +117,10 @@ config SOC_AM33XX
> select CPU_V7
> select MULTI_IRQ_HANDLER
> select COMMON_CLK
> + select MACH_AM335XEVM
> +
> +config MACH_AM335XEVM
> + bool
>
> config OMAP_PACKAGE_ZAF
> bool
>
I can confirm that this patch works with EARLY_PRINTK and DEBUG_LL enabled (current mainline kernel
and u-boot), and the following .config changes:-
$ diff .config.omap2plus_defconfig .config
505c505,508
< # CONFIG_ARM_APPENDED_DTB is not set
---
> CONFIG_ARM_APPENDED_DTB=y
> CONFIG_ARM_ATAG_DTB_COMPAT=y
> CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y
> # CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND is not set
2659c2662,2665
< # CONFIG_DEBUG_LL is not set
---
> CONFIG_DEBUG_LL=y
> CONFIG_DEBUG_LL_UART_NONE=y
> # CONFIG_DEBUG_ICEDCC is not set
> # CONFIG_DEBUG_SEMIHOSTING is not set
2660a2667
> CONFIG_EARLY_PRINTK=y
Boot log
--------
Filename '/nanobone/uImage-dtb'.
Load address: 0x80000000
Loading: #################################################################
#################################################################
#################################################################
#################################################################
#########
627 KiB/s
done
Bytes transferred = 3946799 (3c392f hex)
## Booting kernel from Legacy Image at 80000000 ...
Image Name: Linux 3.8.0-rc5-dirty
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3946735 Bytes = 3.8 MiB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 3.8.0-rc5-dirty (mpfj at mpfj-nanobone) (gcc version 4.5.4 (Buildroot
2012.11-git-00497-ge48bf89) ) #9 SMP Mon Jan 28 11:34:19 GMT 2013
[ 0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[ 0.000000] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x BeagleBone
[ 0.000000] bootconsole [earlycon0] enabled
[ 0.000000] Memory policy: ECC disabled, Data cache writeback
[ 0.000000] On node 0 totalpages: 65280
[ 0.000000] free_area_init_node: node 0, pgdat c07c7040, node_mem_map c0d27000
[ 0.000000] Normal zone: 512 pages used for memmap
[ 0.000000] Normal zone: 0 pages reserved
[ 0.000000] Normal zone: 64768 pages, LIFO batch:15
[ 0.000000] AM335X ES1.0 (neon )
[ 0.000000] PERCPU: Embedded 9 pages/cpu @c0f30000 s12992 r8192 d15680 u36864
[ 0.000000] pcpu-alloc: s12992 r8192 d15680 u36864 alloc=9*4096
[ 0.000000] pcpu-alloc: [0] 0
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 64768
[ 0.000000] Kernel command line: console=ttyO0,115200n8 earlyprintk debug root=/dev/mmcblk0p2 ro
rootfstype=ext2 rootwait
<snip>
[ 1.702800] davinci_mdio 4a101000.mdio: phy[0]: device 4a101000.mdio:00, driver SMSC LAN8710/LAN8720
[ 1.713088] Random MACID = 56:e9:38:ee:af:e4
[ 1.723695] drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
[ 1.735470] Waiting for root device /dev/mmcblk0p2...
Still no support for rootfs on MMC, but hopefully that won't be long ??
Regards
Mark J.
^ permalink raw reply
* OMAP baseline test results for v3.8-rc5
From: Mohammed, Afzal @ 2013-01-28 11:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130128113818.GD28698@arwen.pp.htv.fi>
Hi Felipe,
On Mon, Jan 28, 2013 at 17:08:19, Balbi, Felipe wrote:
> seems to be a bug with __unflatten_device_tree()...
> U-Boot# bootm 0x80200000 - 0x80f80000
Try loading dtb at a different address, I do,
bootm 81000000 - 82000000
Regards
Afzal
^ permalink raw reply
* [PATCH v3 3/3] arm: omap2: gpmc: add DT bindings for OneNAND
From: Mark Rutland @ 2013-01-28 11:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CALF0-+X2qsF5OETerRSVsJbjkC-JdVXsZhyw1sxQYR+PWX6LHA@mail.gmail.com>
On Fri, Jan 25, 2013 at 06:11:28PM +0000, Ezequiel Garcia wrote:
> Hi Mark,
>
> First of all: thanks for reviewing.
>
> On Fri, Jan 25, 2013 at 12:56 PM, Mark Rutland <mark.rutland@arm.com> wrote:
> > Hi,
> >
> > I have a couple more comments after looking though this a bit more thoroughly.
> >
> > On Fri, Jan 25, 2013 at 12:23:11PM +0000, Ezequiel Garcia wrote:
> >> This patch adds device tree bindings for OMAP OneNAND devices.
> >> Tested on an OMAP3 3430 IGEPv2 board.
> >>
> >> Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
> >> ---
> >> Changes from v2:
> >> * Remove unneeded of_node_put() as reported by Mark Rutland
> >>
> >> Changes from v1:
> >> * Fix typo in Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
> >>
> >> .../devicetree/bindings/mtd/gpmc-onenand.txt | 43 +++++++++++++++++++
> >> arch/arm/mach-omap2/gpmc.c | 45 ++++++++++++++++++++
> >> 2 files changed, 88 insertions(+), 0 deletions(-)
> >> create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt b/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
> >> new file mode 100644
> >> index 0000000..deec9da
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
> >> @@ -0,0 +1,43 @@
> >> +Device tree bindings for GPMC connected OneNANDs
> >> +
> >> +GPMC connected OneNAND (found on OMAP boards) are represented as child nodes of
> >> +the GPMC controller with a name of "onenand".
> >> +
> >> +All timing relevant properties as well as generic gpmc child properties are
> >> +explained in a separate documents - please refer to
> >> +Documentation/devicetree/bindings/bus/ti-gpmc.txt
> >
> > Which tree can I find this in?
> >
>
> GPMC binding was posted by Daniel Mack a while ago.
> Tony has recently pushed it to his master branch here:
> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git
Aha. Thanks, it's far easier to understand with the gpmc doc!
>
> >> +
> >> +Required properties:
> >> +
> >> + - reg: The CS line the peripheral is connected to
> >> +
> >> +Optional properties:
> >> +
> >> + - dma-channel: DMA Channel index
> >> +
> >> +For inline partiton table parsing (optional):
> >> +
> >> + - #address-cells: should be set to 1
> >> + - #size-cells: should be set to 1
> >> +
> >> +Example for an OMAP3430 board:
> >> +
> >> + gpmc: gpmc at 6e000000 {
> >> + compatible = "ti,omap3430-gpmc";
> >> + ti,hwmods = "gpmc";
> >> + reg = <0x6e000000 0x1000000>;
> >> + interrupts = <20>;
> >> + gpmc,num-cs = <8>;
> >> + gpmc,num-waitpins = <4>;
> >> + #address-cells = <2>;
> >> + #size-cells = <1>;
> >> +
> >> + onenand at 0 {
> >> + reg = <0 0 0>; /* CS0, offset 0 */
> >> +
> >> + #address-cells = <1>;
> >> + #size-cells = <1>;
> >> +
> >> + /* partitions go here */
> >> + };
> >> + };
> >> diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
> >> index c6255f7..0636d0a 100644
> >> --- a/arch/arm/mach-omap2/gpmc.c
> >> +++ b/arch/arm/mach-omap2/gpmc.c
> >> @@ -39,6 +39,7 @@
> >> #include "omap_device.h"
> >> #include "gpmc.h"
> >> #include "gpmc-nand.h"
> >> +#include "gpmc-onenand.h"
> >>
> >> #define DEVICE_NAME "omap-gpmc"
> >>
> >> @@ -1259,6 +1260,43 @@ static int gpmc_probe_nand_child(struct platform_device *pdev,
> >> }
> >> #endif
> >>
> >> +#ifdef CONFIG_MTD_ONENAND
> >> +static int gpmc_probe_onenand_child(struct platform_device *pdev,
> >> + struct device_node *child)
> >> +{
> >> + u32 val;
> >> + struct omap_onenand_platform_data *gpmc_onenand_data;
> >> +
> >> + if (of_property_read_u32(child, "reg", &val) < 0) {
> >> + dev_err(&pdev->dev, "%s has no 'reg' property\n",
> >> + child->full_name);
> >> + return -ENODEV;
> >> + }
> >
> > I don't understand the format of the reg property, but it seems odd that you
> > only need to read one cell from it. Are the remaining address cell and size
> > cell used anywhere?
> >
>
> Okey, I'll give a shot and try to explain this myself:
>
> As you can see by Daniel's first patch [1]
> the reg property originally contained the chip select only, and
> after some discussion in that same thread, and in this one [2]
> It was decided to use a reg property that would also describe
> the base address and size of the gpmc sub-device,
> and use ranges for the address translation.
> This was reflected in Daniel's changelog when he submitted
> the v2 patch series [3].
>
> [1] http://www.spinics.net/lists/arm-kernel/msg202169.html
> [2] http://web.archiveorange.com/archive/v/vEQ2yFI0tmpQJdigvAog
> [3] http://lists.infradead.org/pipermail/linux-arm-kernel/2012-November/129426.html
So if I've understood correctly, the first address cell is the CS, and the
second the offset within this (as the comment in the onenand at 0 node hints)?
If so, the code now makes sense to me :)
I was having difficulty seeing where the base address of the child got
translated via ranges, but I see in [3] that this doesn't currently happen.
That answers my question about the remaining cells.
Might it be worth sanity checking the runtime calculated address with the one
translated from dt? That way we can print a warning if the two don't match,
which would help to discover broken dts (or invalid runtime calculation if
future hardware breaks it somewhow).
Thanks,
Mark.
^ permalink raw reply
* [GIT PULL V2 2/4] ARM: mvebu: drivers for v3.9
From: Chris Ball @ 2013-01-28 11:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130128055304.GA25723@quad.lixom.net>
Hi,
On Mon, Jan 28 2013, Olof Johansson wrote:
> I didn't see any acks by Chris Ball on these, he's usually pretty
> responsive on code reviews so I just wanted to make sure he's OK with
> us taking this through arm-soc, and aware of it.
>
> Looks like this whole branch could go through the mmc tree? The dtsi
> updates from the last branch would still go through arm-soc.
Thanks for the ping, would be good to take these via mmc-next so I've
pushed the four new mvsdio patches there now:
mmc: mvsdio: add pinctrl integration
mmc: mvsdio: implement a Device Tree binding
mmc: mvsdio: use slot-gpio for card detect gpio
mmc: mvsdio: use slot-gpio infrastructure for write protect gpio
Hope that works okay for everyone,
- Chris.
--
Chris Ball <cjb@laptop.org> <http://printf.net/>
One Laptop Per Child
^ permalink raw reply
* [PATCH] ARM: mxs: gpio-mxs: Add IRQ_TYPE_EDGE_BOTH support
From: Shawn Guo @ 2013-01-28 11:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359306248-28690-1-git-send-email-gwenhael.goavec-merou@armadeus.com>
On Sun, Jan 27, 2013 at 06:04:08PM +0100, Gwenhael Goavec-Merou wrote:
> This patch adds support for IRQ_TYPE_EDGE_BOTH needed for some driver
> (gpio-keys).
> Inspired from gpio-mxc.c
>
> Signed-off-by: Gwenhael Goavec-Merou <gwenhael.goavec-merou@armadeus.com>
> ---
> drivers/gpio/gpio-mxs.c | 31 +++++++++++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
>
> diff --git a/drivers/gpio/gpio-mxs.c b/drivers/gpio/gpio-mxs.c
> index fa2a63c..7690eec 100644
> --- a/drivers/gpio/gpio-mxs.c
> +++ b/drivers/gpio/gpio-mxs.c
> @@ -65,6 +65,7 @@ struct mxs_gpio_port {
> struct irq_domain *domain;
> struct bgpio_chip bgc;
> enum mxs_gpio_id devid;
> + u32 both_edges;
> };
>
> static inline int is_imx23_gpio(struct mxs_gpio_port *port)
> @@ -81,13 +82,24 @@ static inline int is_imx28_gpio(struct mxs_gpio_port *port)
>
> static int mxs_gpio_set_irq_type(struct irq_data *d, unsigned int type)
> {
> + u32 val;
> u32 pin_mask = 1 << d->hwirq;
> + u32 gpio_idx = d->hwirq;
This does not really needed, since what you need in the code below is
all about pin_mask.
> struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
> struct mxs_gpio_port *port = gc->private;
> void __iomem *pin_addr;
> int edge;
>
> + port->both_edges &= ~(1 << gpio_idx);
> switch (type) {
> + case IRQ_TYPE_EDGE_BOTH:
> + val = gpio_get_value(port->bgc.gc.base + gpio_idx);
> + if (val)
> + edge = GPIO_INT_LOW_LEV;
> + else
> + edge = GPIO_INT_HIGH_LEV;
I do not quite understand this. Why do you need to set LEVEL in case
of EDGE_BOTH?
> + port->both_edges |= 1 << gpio_idx;
> + break;
> case IRQ_TYPE_EDGE_RISING:
> edge = GPIO_INT_RISE_EDGE;
> break;
> @@ -123,6 +135,22 @@ static int mxs_gpio_set_irq_type(struct irq_data *d, unsigned int type)
>
> return 0;
> }
Have a new line here, please.
> +static void mxs_flip_edge(struct mxs_gpio_port *port, u32 gpio)
> +{
> + u32 bit, val, edge;
> + void __iomem *pin_addr;
> +
> + bit = 1<<gpio;
Nit: Have space before << and after, please.
> +
> + pin_addr = port->base + PINCTRL_IRQPOL(port);
> + val = readl(pin_addr);
> + edge = val&bit;
Ditto
Shawn
> +
> + if (edge)
> + writel(bit, pin_addr + MXS_CLR);
> + else
> + writel(bit, pin_addr + MXS_SET);
> +}
>
> /* MXS has one interrupt *per* gpio port */
> static void mxs_gpio_irq_handler(u32 irq, struct irq_desc *desc)
> @@ -137,6 +165,9 @@ static void mxs_gpio_irq_handler(u32 irq, struct irq_desc *desc)
>
> while (irq_stat != 0) {
> int irqoffset = fls(irq_stat) - 1;
> + if (port->both_edges & (1 << irqoffset))
> + mxs_flip_edge(port, irqoffset);
> +
> generic_handle_irq(irq_find_mapping(port->domain, irqoffset));
> irq_stat &= ~(1 << irqoffset);
> }
> --
> 1.7.12.4
>
^ permalink raw reply
* OMAP baseline test results for v3.8-rc5
From: Felipe Balbi @ 2013-01-28 12:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <C8443D0743D26F4388EA172BF4E2A7A93EA946E4@DBDE01.ent.ti.com>
Hi,
On Mon, Jan 28, 2013 at 12:46:21PM +0100, Mohammed, Afzal wrote:
> Hi Felipe,
>
> On Mon, Jan 28, 2013 at 17:08:19, Balbi, Felipe wrote:
>
> > seems to be a bug with __unflatten_device_tree()...
>
> > U-Boot# bootm 0x80200000 - 0x80f80000
>
> Try loading dtb at a different address, I do,
>
> bootm 81000000 - 82000000
didn't help :-s
U-Boot# bootm 0x81000000 - 0x82000000
## Booting kernel from Legacy Image at 81000000 ...
Image Name: Linux-3.8.0-rc5-02311-g1308c2b-d
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 4265296 Bytes = 4.1 MiB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
## Flattened Device Tree blob at 82000000
Booting using the fdt blob at 0x82000000
Loading Kernel Image ... OK
OK
Loading Device Tree to 9fe3e000, end 9fe42f1e ... OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 3.8.0-rc5-02311-g1308c2b-dirty (balbi at arwen) (gcc version 4.6.3 (Sourcery CodeBench Lite 2012.03-57) ) #37 SMP Mon
Jan 28 13:32:47 EET 2013
[ 0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[ 0.000000] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x BeagleBone
[ 0.000000] bootconsole [earlycon0] enabled
[ 0.000000] Memory policy: ECC disabled, Data cache writeback
[ 0.000000] On node 0 totalpages: 65280
[ 0.000000] free_area_init_node: node 0, pgdat c08331c0, node_mem_map c0d91000
[ 0.000000] Normal zone: 512 pages used for memmap
[ 0.000000] Normal zone: 0 pages reserved
[ 0.000000] Normal zone: 64768 pages, LIFO batch:15
[ 0.000000] Unable to handle kernel paging request at virtual address dfe3e000
[ 0.000000] pgd = c0004000
[ 0.000000] [dfe3e000] *pgd=00000000
[ 0.000000] Internal error: Oops: 5 [#1] SMP ARM
[ 0.000000] Modules linked in:
[ 0.000000] CPU: 0 Not tainted (3.8.0-rc5-02311-g1308c2b-dirty #37)
[ 0.000000] PC is at __unflatten_device_tree+0x1c/0x12c
[ 0.000000] LR is at unflatten_device_tree+0x1c/0x34
[ 0.000000] pc : [<c0457d2c>] lr : [<c077a370>] psr: a0000193
[ 0.000000] sp : c07a5f80 ip : 00000000 fp : 00000000
[ 0.000000] r10: 00000000 r9 : 413fc082 r8 : 80004059
[ 0.000000] r7 : c0755dd0 r6 : c0783ac0 r5 : dfe3e000 r4 : c0755dd0
[ 0.000000] r3 : d00dfeed r2 : c0755dd0 r1 : c0d8a8d4 r0 : dfe3e000
[ 0.000000] Flags: NzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
[ 0.000000] Control: 10c5387d Table: 80004019 DAC: 00000017
[ 0.000000] Process swapper (pid: 0, stack limit = 0xc07a4240)
[ 0.000000] Stack: (0xc07a5f80 to 0xc07a6000)
[ 0.000000] 5f80: c07b13d0 c00503b4 8fefffff c0d8a8d4 c0755dd0 c083607c c0783ac0 c07a5fe4
[ 0.000000] 5fa0: 80004059 c077a370 c0781dd8 c0755028 00000000 c07a5fc4 c0783abc 00000001
[ 0.000000] 5fc0: 00000000 c0783abc c07b11c4 c0751618 00000000 00000000 00000000 00000000
[ 0.000000] 5fe0: 00000000 c0783ac0 00000000 10c53c7d c07ac98c 80008078 00000000 00000000
[ 0.000000] [<c0457d2c>] (__unflatten_device_tree+0x1c/0x12c) from [<c077a370>] (unflatten_device_tree+0x1c/0x34)
[ 0.000000] [<c077a370>] (unflatten_device_tree+0x1c/0x34) from [<c0755028>] (setup_arch+0xf8/0x190)
[ 0.000000] [<c0755028>] (setup_arch+0xf8/0x190) from [<c0751618>] (start_kernel+0x80/0x2a8)
[ 0.000000] [<c0751618>] (start_kernel+0x80/0x2a8) from [<80008078>] (0x80008078)
[ 0.000000] Code: e1a07002 e58d100c 0a000033 e59f30f4 (e5951000)
[ 0.000000] ---[ end trace 1b75b31a2719ed1c ]---
[ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130128/b07198b9/attachment.sig>
^ permalink raw reply
* OMAP baseline test results for v3.8-rc5
From: Mohammed, Afzal @ 2013-01-28 12:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130128121635.GI28698@arwen.pp.htv.fi>
Hi Felipe,
On Mon, Jan 28, 2013 at 17:46:35, Balbi, Felipe wrote:
> didn't help :-s
Hands up :(
Regards
Afzal
^ permalink raw reply
* OMAP baseline test results for v3.8-rc4
From: Bedia, Vaibhav @ 2013-01-28 12:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130125165942.GY22517@atomide.com>
On Fri, Jan 25, 2013 at 22:29:43, Tony Lindgren wrote:
> * Bedia, Vaibhav <vaibhav.bedia@ti.com> [130123 06:35]:
> > Hi Tony,
> >
> > On Tue, Jan 22, 2013 at 23:53:32, Tony Lindgren wrote:
> > [...]
> > > >
> > > > But I should get *something* from the kernel before it starts trying to access the rootfs ?
> > >
> > > Here's something Kevin fixed but did not send it out before going to
> > > a vacation. Can you give it a try with earlyprintk enabled?
> > >
> > > Note that this does not help with no output early on, that sounds
> > > like a bug configuring the DEBUG_LL port somewhere.
> > >
> >
> > I think earlyprintk on AM335x has not been functional for a while [1].
> > Will the latest patches from you to enable multiplatform debug-ll be sufficient
> > to test this out? I am trying to track down the boot issues reported and just
> > want to be sure of the dependencies.
>
> Yes you should check with current linux next and select the DEBUG_LL
> port manually.
>
Verified on linux-next that selecting the right UART port gives a functional early_console.
(One of the rare cases where forcing a kernel panic early in the boot process makes sense ;)
Regards,
Vaibhav
^ permalink raw reply
* [PATCH 5/6 v14] gpio: Add device tree support to block GPIO API
From: Roland Stigge @ 2013-01-28 12:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOY=C6HTRFY=rXOAhTwuR3NvtaRFbfbkkpn7FeyK+eqG7sVcKg@mail.gmail.com>
On 01/28/2013 12:39 PM, Stijn Devriendt wrote:
>>> In the device-tree this is specified as:
>>>
>>> powr at 0x20 {
>>> // other properties
>>>
>>> gpios = <&gpio 4 0
>>> &gpio 5 0>;
>>> };
>>>
>>> Is this kind of integration also possible?
>>
>> You can reference the gpio block via a phandle, e.g.:
>>
>> blockgpio {
>> compatible = "linux,gpio-block";
>>
>> selector1 {
>> gpios = <&gpio 4 0>,
>> <&gpio 5 0>;
>> };
>> };
>>
>> powr at 0x20 {
>> // ...
>>
>> gpios = <&selector1>;
>> };
>>
>>
>> In the driver, you can get the gpio block like this:
>>
>> block = gpio_block_find_by_name(of_parse_phandle(powr, "gpios", 0)->name);
>>
>> (Simplified by removed error/NULL handling!)
>>
>> If this turns out to be a common pattern, I can add a convenience "get"
>> function for this.
>
> Given the pick-up of device-tree in ARM and MIPS, I think this stands
> a good chance
> of becoming a common pattern. Do mind the "gpios" name; it's already used by the
> normal GPIO request functions...
Right, when providing the respective convenience function, I'll better
use sth. like "gpioblock" as property name.
Specifying a traditional list of GPIOs instead is easy, actually. The
respective driver just needs to allocate a gpio block explicitly
(insteady of implicitly via phandle as above). Unfortunately, gpio
blocks that should be exported and available to userspace can't be
specified this way. Therefore the strategy as above.
Roland
^ permalink raw reply
* [PATCH] cpufreq: instantiate cpufreq-cpu0 as a platform_driver
From: Rafael J. Wysocki @ 2013-01-28 12:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130128083159.GD31689@S2101-09.ap.freescale.net>
On Monday, January 28, 2013 04:32:01 PM Shawn Guo wrote:
> On Sat, Jan 26, 2013 at 11:21:27PM +0100, Rafael J. Wysocki wrote:
> > On Saturday, January 26, 2013 09:55:50 PM Shawn Guo wrote:
> > > As multiplatform build is being adopted by more and more ARM platforms,
> > > initcall function should be used very carefully. For example, when
> > > GENERIC_CPUFREQ_CPU0 is built in the kernel, cpu0_cpufreq_driver_init()
> > > will be called on all the platforms to initialize cpufreq-cpu0 driver.
> > >
> > > To eliminate this undesired the effect, the patch changes cpufreq-cpu0
> > > driver to have it instantiated as a platform_driver. Then it will only
> > > run on platforms that create the platform_device "cpufreq-cpu0".
> > >
> > > Along with the change, it also changes cpu_dev to be &pdev->dev,
> > > so that managed functions can start working, and module build gets
> > > supported too.
> > >
> > > Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> > > ---
> > > Rafael,
> > >
> > > The patch depends patch "power: export opp cpufreq functions".
> > > https://patchwork.kernel.org/patch/1847261/
> >
> > That one should use EXPORT_SYMBOL_GPL() for exporting symbols, though.
> >
> When commit 80126ce (PM / OPP: Export symbols for module usage.)
> already exported a few symbols with EXPORT_SYMBOL()?
Yes, even then.
All symbols in new patches that I apply have to be exported with _GPL.
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* [PATCH] arm: zynq: Add missing irqchip.h to common.c
From: Michal Simek @ 2013-01-28 12:30 UTC (permalink / raw)
To: linux-arm-kernel
The patch: "ARM: use common irqchip_init for GIC init"
(sha1: 0529e315bbda5d502c93df2cfafba9bb337fbdf4)
should also add linux/irqchip.h header.
Error message:
arch/arm/mach-zynq/common.c:99:14: error: 'irqchip_init'
undeclared here (not in a function)
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---
arch/arm/mach-zynq/common.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-zynq/common.c b/arch/arm/mach-zynq/common.c
index 6472a69..cf3ec54 100644
--- a/arch/arm/mach-zynq/common.c
+++ b/arch/arm/mach-zynq/common.c
@@ -24,6 +24,7 @@
#include <linux/of_irq.h>
#include <linux/of_platform.h>
#include <linux/of.h>
+#include <linux/irqchip.h>
#include <asm/mach/arch.h>
#include <asm/mach/map.h>
--
1.7.0.4
^ permalink raw reply related
* [GIT PULL v2] arm-soc: Xilinx zynq timer changes for v3.9
From: Michal Simek @ 2013-01-28 12:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130128061350.GC25723@quad.lixom.net>
Hi,
2013/1/28 Olof Johansson <olof@lixom.net>:
> On Fri, Jan 25, 2013 at 04:48:43PM +0100, Michal Simek wrote:
>> Hi Arnd and Olof,
>>
>> can you please look at this pull request?
>
> Hi,
>
> Sorry for the delay. I was out sick part of last week and dealing with
> backlog when I got back on my feet. Doing a sweep of pull requests now.
ah ok.
> Two comments.
>
> 1. mach-pxa/time.c conflict resolution doesn't seem right -- you for some
> reason deleted the suspend/resume struct members from the
> clock_event_device.
grrr. You are right,
> 2. Below:
>
>> > Soren Brinkmann (7):
>> > arm: zynq: timer: Replace PSS through PS
>
> This is pure churn. :( We can't keep renaming things in the kernel just
> because some document writer decides to change a term, we tend to stick
> to what's already there. As long as it's not completely misleading, at least.
>
>
> I' shortly push a new "depends/cleanup" branch to arm-soc. It essentially
> contains the next/cleanup contents that you merged together yourself,
> but as a branch that you can just pull in. Since others might need to
> do the same, providing the branch from us just makes sense.
>
> So, can you please rebase on top of that and send a fresh pull request? If
> you really want the PSS->PS rename included I'll give you a first-time
> pass for it but please keep it in mind for the future.
I tend to keep this patch in the tree but I will keep this in my mind.
I believe that only this mainline timer driver contains it and all new patches
which come soon will just use PS instead of PSS.
I will send updated pull request.
There will be one more patch "arm: zynq: Add missing irqchip.h to common.c"
because of compilation error introduced by the last merge around git changes.
btw: I want to also add maintainer fragment and defconfig update(sent by Josh)
Which branch should I use?
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
^ permalink raw reply
* [PATCH 3/4 v11] arm highbank: add support for pl320 IPC
From: Rafael J. Wysocki @ 2013-01-28 12:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359143205-20279-4-git-send-email-mark.langsdorf@calxeda.com>
On Friday, January 25, 2013 01:46:44 PM Mark Langsdorf wrote:
> From: Rob Herring <rob.herring@calxeda.com>
>
> The pl320 IPC allows for interprocessor communication between the highbank A9
> and the EnergyCore Management Engine. The pl320 implements a straightforward
> mailbox protocol.
>
> Signed-off-by: Mark Langsdorf <mark.langsdorf@calxeda.com>
> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
> Cc: Omar Ramirez Luna <omar.luna@linaro.org>
> Cc: Arnd Bergmann <arnd@arndb.de>
> ---
> Changes from v10
> Removed deependency on Omar Ramirez Luna's mailbox code. Now the
> patch creates the directory itself.
> Changes from v9
> Used to be the 4th patch in the series.
> Changes from v6, v7, v8
> None.
> Changes from v5
> Renamed ipc_transmit() to pl320_ipc_transmit().
> Properly exported pl320_ipc_{un}register_notifier().
> Changes from v4
> Moved pl320-ipc.c from arch/arm/mach-highbank to drivers/mailbox.
> Moved header information to include/linux/mailbox.h.
> Added Kconfig options to reflect the new code location.
> Change drivers/mailbox/Makefile to build the omap mailboxes only
> when they are configured.
> Removed ipc_call_fast and renamed ipc_call_slow ipc_transmit.
> Changes from v3, v2
> None.
> Changes from v1
> Removed erroneous changes for cpufreq Kconfig.
>
> arch/arm/mach-highbank/Kconfig | 2 +
> drivers/mailbox/Kconfig | 18 ++++
> drivers/mailbox/Makefile | 1 +
> drivers/mailbox/pl320-ipc.c | 199 +++++++++++++++++++++++++++++++++++++++++
> include/linux/mailbox.h | 18 ++++
> 5 files changed, 238 insertions(+)
> create mode 100644 drivers/mailbox/Kconfig
> create mode 100644 drivers/mailbox/Makefile
> create mode 100644 drivers/mailbox/pl320-ipc.c
> create mode 100644 include/linux/mailbox.h
>
> diff --git a/arch/arm/mach-highbank/Kconfig b/arch/arm/mach-highbank/Kconfig
> index 551c97e..2388085 100644
> --- a/arch/arm/mach-highbank/Kconfig
> +++ b/arch/arm/mach-highbank/Kconfig
> @@ -11,5 +11,7 @@ config ARCH_HIGHBANK
> select GENERIC_CLOCKEVENTS
> select HAVE_ARM_SCU
> select HAVE_SMP
> + select MAILBOX
> + select PL320_MBOX
> select SPARSE_IRQ
> select USE_OF
> diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
> new file mode 100644
> index 0000000..9489554
> --- /dev/null
> +++ b/drivers/mailbox/Kconfig
> @@ -0,0 +1,18 @@
> +menuconfig MAILBOX
> + bool "Mailbox Hardware Support"
> + help
> + Mailbox is a framework to control hardware communication between
> + on-chip processors through queued messages and interrupt driven
> + signals. Say Y if your platform supports hardware mailboxes.
> +
> +if MAILBOX
> +config PL320_MBOX
> + bool "ARM PL320 Mailbox"
> + help
> + An implementation of the ARM PL320 Interprocessor Communication
> + Mailbox (IPCM), tailored for the Calxeda Highbank. It is used to
> + send short messages between Highbank's A9 cores and the EnergyCore
> + Management Engine, primarily for cpufreq. Say Y here if you want
> + to use the PL320 IPCM support.
> +
> +endif
> diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
> new file mode 100644
> index 0000000..543ad6a
> --- /dev/null
> +++ b/drivers/mailbox/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_PL320_MBOX) += pl320-ipc.o
> diff --git a/drivers/mailbox/pl320-ipc.c b/drivers/mailbox/pl320-ipc.c
> new file mode 100644
> index 0000000..68c0d50
> --- /dev/null
> +++ b/drivers/mailbox/pl320-ipc.c
> @@ -0,0 +1,199 @@
> +/*
> + * Copyright 2012 Calxeda, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along with
> + * this program. If not, see <http://www.gnu.org/licenses/>.
> + */
> +#include <linux/types.h>
> +#include <linux/err.h>
> +#include <linux/delay.h>
> +#include <linux/export.h>
> +#include <linux/io.h>
> +#include <linux/interrupt.h>
> +#include <linux/completion.h>
> +#include <linux/mutex.h>
> +#include <linux/notifier.h>
> +#include <linux/spinlock.h>
> +#include <linux/device.h>
> +#include <linux/amba/bus.h>
> +
> +#include <linux/mailbox.h>
> +
> +#define IPCMxSOURCE(m) ((m) * 0x40)
> +#define IPCMxDSET(m) (((m) * 0x40) + 0x004)
> +#define IPCMxDCLEAR(m) (((m) * 0x40) + 0x008)
> +#define IPCMxDSTATUS(m) (((m) * 0x40) + 0x00C)
> +#define IPCMxMODE(m) (((m) * 0x40) + 0x010)
> +#define IPCMxMSET(m) (((m) * 0x40) + 0x014)
> +#define IPCMxMCLEAR(m) (((m) * 0x40) + 0x018)
> +#define IPCMxMSTATUS(m) (((m) * 0x40) + 0x01C)
> +#define IPCMxSEND(m) (((m) * 0x40) + 0x020)
> +#define IPCMxDR(m, dr) (((m) * 0x40) + ((dr) * 4) + 0x024)
> +
> +#define IPCMMIS(irq) (((irq) * 8) + 0x800)
> +#define IPCMRIS(irq) (((irq) * 8) + 0x804)
> +
> +#define MBOX_MASK(n) (1 << (n))
> +#define IPC_TX_MBOX 1
> +#define IPC_RX_MBOX 2
> +
> +#define CHAN_MASK(n) (1 << (n))
> +#define A9_SOURCE 1
> +#define M3_SOURCE 0
> +
> +static void __iomem *ipc_base;
> +static int ipc_irq;
> +static DEFINE_MUTEX(ipc_m1_lock);
> +static DECLARE_COMPLETION(ipc_completion);
> +static ATOMIC_NOTIFIER_HEAD(ipc_notifier);
> +
> +static inline void set_destination(int source, int mbox)
> +{
> + __raw_writel(CHAN_MASK(source), ipc_base + IPCMxDSET(mbox));
> + __raw_writel(CHAN_MASK(source), ipc_base + IPCMxMSET(mbox));
> +}
> +
> +static inline void clear_destination(int source, int mbox)
> +{
> + __raw_writel(CHAN_MASK(source), ipc_base + IPCMxDCLEAR(mbox));
> + __raw_writel(CHAN_MASK(source), ipc_base + IPCMxMCLEAR(mbox));
> +}
> +
> +static void __ipc_send(int mbox, u32 *data)
> +{
> + int i;
> + for (i = 0; i < 7; i++)
> + __raw_writel(data[i], ipc_base + IPCMxDR(mbox, i));
> + __raw_writel(0x1, ipc_base + IPCMxSEND(mbox));
> +}
> +
> +static u32 __ipc_rcv(int mbox, u32 *data)
> +{
> + int i;
> + for (i = 0; i < 7; i++)
> + data[i] = __raw_readl(ipc_base + IPCMxDR(mbox, i));
> + return data[1];
> +}
> +
> +/* blocking implmentation from the A9 side, not usuable in interrupts! */
> +int pl320_ipc_transmit(u32 *data)
> +{
> + int ret;
> +
> + mutex_lock(&ipc_m1_lock);
> +
> + init_completion(&ipc_completion);
> + __ipc_send(IPC_TX_MBOX, data);
> + ret = wait_for_completion_timeout(&ipc_completion,
> + msecs_to_jiffies(1000));
> + if (ret == 0) {
> + ret = -ETIMEDOUT;
> + goto out;
> + }
> +
> + ret = __ipc_rcv(IPC_TX_MBOX, data);
> +out:
> + mutex_unlock(&ipc_m1_lock);
> + return ret;
> +}
> +EXPORT_SYMBOL(pl320_ipc_transmit);
> +
> +irqreturn_t ipc_handler(int irq, void *dev)
> +{
> + u32 irq_stat;
> + u32 data[7];
> +
> + irq_stat = __raw_readl(ipc_base + IPCMMIS(1));
> + if (irq_stat & MBOX_MASK(IPC_TX_MBOX)) {
> + __raw_writel(0, ipc_base + IPCMxSEND(IPC_TX_MBOX));
> + complete(&ipc_completion);
> + }
> + if (irq_stat & MBOX_MASK(IPC_RX_MBOX)) {
> + __ipc_rcv(IPC_RX_MBOX, data);
> + atomic_notifier_call_chain(&ipc_notifier, data[0], data + 1);
> + __raw_writel(2, ipc_base + IPCMxSEND(IPC_RX_MBOX));
> + }
> +
> + return IRQ_HANDLED;
> +}
> +
> +int pl320_ipc_register_notifier(struct notifier_block *nb)
> +{
> + return atomic_notifier_chain_register(&ipc_notifier, nb);
> +}
> +EXPORT_SYMBOL(pl320_ipc_register_notifier);
> +
> +int pl320_ipc_unregister_notifier(struct notifier_block *nb)
> +{
> + return atomic_notifier_chain_unregister(&ipc_notifier, nb);
> +}
> +EXPORT_SYMBOL(pl320_ipc_unregister_notifier);
I need all of your symbols to be exported with EXPORT_SYMBOL_GPL().
Is it OK to make that change when applying the patch or do you want to send
a new one?
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* [PATCH 19/19] [INCOMPLETE] ARM: make return_address available for ARM_UNWIND
From: Dave Martin @ 2013-01-28 12:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+KhAHYJus7+LsVhNa4RcxfpeTBtV=_vf2YDACtoMujo5c6tXA@mail.gmail.com>
On Mon, Jan 28, 2013 at 11:33:11AM +0900, Keun-O Park wrote:
> Hello guys,
>
> Could you please review the patch of fixing bug first of returning
> wrong address when using frame pointer?
> I am wondering if the first patch is not delivered to the mailing.
I posted a similar patch to alkml a couple of months ago, but I got
no response and it looks like I forgot about it.
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-November/129381.html
[...]
>
> ~~~~~~~~~~~~~~~~~~~~~snip~~~~~~~~~~~~~~~~~~~~~~~~~
> From 3a60b536d22a2043d735c890a9aac9e7cb72de8f Mon Sep 17 00:00:00 2001
> From: sahara <keun-o.park@windriver.com>
> Date: Thu, 3 Jan 2013 17:12:37 +0900
> Subject: [PATCH 1/2] arm: fix returning wrong CALLER_ADDRx
>
> This makes return_address return correct value for ftrace feature.
> unwind_frame does not update frame->lr but frame->pc for backtrace.
> And, the initialization for data.addr was missing so that wrong value
> returned when unwind_frame failed.
>
> Signed-off-by: sahara <keun-o.park@windriver.com>
> ---
> arch/arm/kernel/return_address.c | 5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/kernel/return_address.c b/arch/arm/kernel/return_address.c
> index 8085417..fafedd8 100644
> --- a/arch/arm/kernel/return_address.c
> +++ b/arch/arm/kernel/return_address.c
> @@ -26,7 +26,7 @@ static int save_return_addr(struct stackframe *frame, void *d)
> struct return_address_data *data = d;
>
> if (!data->level) {
> - data->addr = (void *)frame->lr;
> + data->addr = (void *)frame->pc;
>
> return 1;
> } else {
> @@ -41,7 +41,8 @@ void *return_address(unsigned int level)
> struct stackframe frame;
> register unsigned long current_sp asm ("sp");
>
> - data.level = level + 1;
> + data.level = level + 2;
> + data.addr = NULL;
Can you explain why this is needed? I think I concluded it wasn't
necessary, but you may be right -- I think if walk_stackframe()
fails to unwind the next frame just after data.level reaches zero,
then data.addr can remain unset and return_address() may return
uninitialised garbage.
Initialising data.addr to NULL before we start seems a good way
to avoid that.
Cheers
---Dave
^ permalink raw reply
* [GIT PULL v3] arm-soc: Xilinx zynq timer changes for v3.9
From: Michal Simek @ 2013-01-28 12:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHTX3d+qeKPT3YYG3=YgWYN5YTS1oT9HoTEpVwC4GZAYve5uYw@mail.gmail.com>
Hi Olof,
based on your previous email I am sending updated pull request which is based
on arm-soc depends/cleanup branch.
As I wrote in my email I tend to keep there Soren's patch around
renaming PSS to PS
and be more strict on this for future.
I have also added one more patch which fix Rob's conversion to irqchip_init.
btw: As I mentioned in the previous email I want to add 2 defconfig
updates + maintainer
fragment. I have created branch zynq/misc in the same repo. Is this
name ok for you?
If yes, I will send you separate pull request just for this branch.
Thanks,
Michal
The following changes since commit f8060f5446b1f2782f0a8ca9be2d870ea4198aee:
Olof Johansson (1):
Merge tag 'gic-vic-to-irqchip' of
git://sources.calxeda.com/kernel/linux into next/cleanup
are available in the git repository at:
git://git.xilinx.com/linux-xlnx.git zynq/timer
Michal Simek (1):
arm: zynq: Add missing irqchip.h to common.c
Soren Brinkmann (7):
arm: zynq: timer: Replace PSS through PS
arm: zynq: timer: Remove unnecessary register write
arm: zynq: timer: Remove unused #defines
arm: zynq: timer: Align columns
arm: zynq: timer: Remove redundant #includes
arm: zynq: timer: Fix comment style
arm: zynq: timer: Set clock_event cpumask
arch/arm/mach-zynq/common.c | 3 +-
arch/arm/mach-zynq/common.h | 2 +-
arch/arm/mach-zynq/timer.c | 150 ++++++++++++++++++++----------------------
3 files changed, 74 insertions(+), 81 deletions(-)
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox