[PATCH 1/3] AM35x: Add musb support
From: Ajay Kumar Gupta ajay.gu...@ti.com
AM35x has musb interface (version 1.8) and uses CPPI41 DMA engine.
It has USB phy built inside the IP itself.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-omap@vger.kernel.org
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap2/board-am3517evm.c | 31 +++
arch/arm/mach-omap2/usb-musb.c|4
arch/arm/plat-omap/include/plat/usb.h | 21 +
3 files changed, 56 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index 4d0f585..6d352a2 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -35,6 +35,7 @@
#include plat/control.h
#include plat/usb.h
#include plat/display.h
+#include plat/control.h
#include mux.h
@@ -375,6 +376,31 @@ static void __init am3517_evm_init_irq(void)
omap_gpio_init();
}
+static struct omap_musb_board_data musb_board_data = {
+ .interface_type = MUSB_INTERFACE_ULPI,
+ .mode = MUSB_OTG,
+ .power = 500,
+};
+
+static __init void am3517_evm_musb_init(void)
+{
+ u32 devconf2;
+
+ /*
+* Set up USB clock/mode in the DEVCONF2 register.
+*/
+ devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2);
+
+ /* USB2.0 PHY reference clock is 13 MHz */
+ devconf2 = ~(CONF2_REFFREQ | CONF2_OTGMODE | CONF2_PHY_GPIOMODE);
+ devconf2 |= CONF2_REFFREQ_13MHZ | CONF2_SESENDEN | CONF2_VBDTCTEN
+ | CONF2_DATPOL;
+
+ omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
+
+ usb_musb_init(musb_board_data);
+}
+
static const struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
.port_mode[0] = EHCI_HCD_OMAP_MODE_PHY,
#if defined(CONFIG_PANEL_SHARP_LQ043T1DG01) || \
@@ -393,6 +419,8 @@ static const struct ehci_hcd_omap_platform_data ehci_pdata
__initconst = {
#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
+ /* USB OTG DRVVBUS offset = 0x212 */
+ OMAP3_MUX(SAD2D_MCAD23, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLDOWN),
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
#else
@@ -459,6 +487,9 @@ static void __init am3517_evm_init(void)
ARRAY_SIZE(am3517evm_i2c1_boardinfo));
/*Ethernet*/
am3517_evm_ethernet_init(am3517_evm_emac_pdata);
+
+ /* MUSB */
+ am3517_evm_musb_init();
}
MACHINE_START(OMAP3517EVM, OMAP3517/AM3517 EVM)
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 33a5cde..7260558 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -28,6 +28,7 @@
#include mach/hardware.h
#include mach/irqs.h
+#include mach/am35xx.h
#include plat/usb.h
#ifdef CONFIG_USB_MUSB_SOC
@@ -89,6 +90,9 @@ void __init usb_musb_init(struct omap_musb_board_data
*board_data)
{
if (cpu_is_omap243x()) {
musb_resources[0].start = OMAP243X_HS_BASE;
+ } else if (cpu_is_omap3517() || cpu_is_omap3505()) {
+ musb_resources[0].start = AM35XX_IPSS_USBOTGSS_BASE;
+ musb_resources[1].start = INT_35XX_USBOTG_IRQ;
} else if (cpu_is_omap34xx()) {
musb_resources[0].start = OMAP34XX_HSUSB_OTG_BASE;
} else if (cpu_is_omap44xx()) {
diff --git a/arch/arm/plat-omap/include/plat/usb.h
b/arch/arm/plat-omap/include/plat/usb.h
index 2a9427c..9feddac 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -218,6 +218,27 @@ static inline omap2_usbfs_init(struct omap_usb_config
*pdata)
# define USBT2TLL5PI (1 17)
# define USB0PUENACTLOI (1 16)
# define USBSTANDBYCTRL (1 15)
+/* AM35x */
+/* USB 2.0 PHY Control */
+#define CONF2_PHY_GPIOMODE (1 23)
+#define CONF2_OTGMODE (3 14)
+#define CONF2_NO_OVERRIDE (0 14)
+#define CONF2_FORCE_HOST (1 14)
+#define CONF2_FORCE_DEVICE (2 14)
+#define CONF2_FORCE_HOST_VBUS_LOW (3 14)
+#define CONF2_SESENDEN (1 13)
+#define CONF2_VBDTCTEN (1 12)
+#define CONF2_REFFREQ_24MHZ(2 8)
+#define CONF2_REFFREQ_26MHZ(7 8)
+#define CONF2_REFFREQ_13MHZ(6 8)
+#define CONF2_REFFREQ (0xf 8)
+#define CONF2_PHYCLKGD (1 7)
+#define CONF2_VBUSSENSE(1 6)
+#define CONF2_PHY_PLLON(1 5)
+#define CONF2_RESET(1 4)
+#define CONF2_PHYPWRDN (1 3)
+#define CONF2_OTGPWRDN (1 2)
+#define CONF2_DATPOL (1 1)
#if defined(CONFIG_ARCH_OMAP1) defined(CONFIG_USB)
u32 omap1_usb0_init(unsigned nwires, unsigned is_device);
--
1.7.3.rc0.35.g8ac8c
--
To unsubscribe from this list: send the line unsubscribe
[PATCH 0/4] Horray, more CBUS patches
I believe now everything is fine. Still, it's only compile tested with n770_defconfig and omap2plus_defconfig. Felipe Balbi (4): cbus: remove unneded includes cbus: retu: move platform_device to board file cbus: tahvo: move platform_device to board file cbus: tahvo-usb: move platform_device to board file arch/arm/mach-omap1/board-nokia770.c | 72 + arch/arm/mach-omap2/board-n8x0.c | 73 ++ drivers/cbus/cbus.c |5 -- drivers/cbus/retu.c | 69 +--- drivers/cbus/tahvo-usb.c | 15 +-- drivers/cbus/tahvo.c | 65 +- 6 files changed, 149 insertions(+), 150 deletions(-) -- 1.7.3.rc0.35.g8ac8c -- 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/4] cbus: remove unneded includes
we don't use anything from those headers, thus removing them. Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/cbus/cbus.c |5 - 1 files changed, 0 insertions(+), 5 deletions(-) diff --git a/drivers/cbus/cbus.c b/drivers/cbus/cbus.c index 9e745bb..a8bbf42 100644 --- a/drivers/cbus/cbus.c +++ b/drivers/cbus/cbus.c @@ -30,15 +30,10 @@ #include linux/init.h #include linux/kernel.h #include linux/slab.h -#include linux/delay.h #include linux/spinlock.h #include linux/gpio.h #include linux/platform_device.h -#include asm/io.h -#include asm/mach-types.h - -#include plat/board.h #include plat/cbus.h #include cbus.h -- 1.7.3.rc0.35.g8ac8c -- 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/4] cbus: retu: move platform_device to board file
No functional changes, just moving platform_device
registration to the proper location.
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap1/board-nokia770.c | 34 +
arch/arm/mach-omap2/board-n8x0.c | 34 +
drivers/cbus/retu.c | 69 +-
3 files changed, 69 insertions(+), 68 deletions(-)
diff --git a/arch/arm/mach-omap1/board-nokia770.c
b/arch/arm/mach-omap1/board-nokia770.c
index b9e9de4..3969f2d 100644
--- a/arch/arm/mach-omap1/board-nokia770.c
+++ b/arch/arm/mach-omap1/board-nokia770.c
@@ -12,6 +12,7 @@
#include linux/init.h
#include linux/mutex.h
#include linux/platform_device.h
+#include linux/irq.h
#include linux/input.h
#include linux/clk.h
#include linux/omapfb.h
@@ -112,9 +113,42 @@ static struct platform_device nokia770_cbus_device = {
},
};
+static struct resource retu_resource[] = {
+ {
+ .start = -EINVAL, /* set later */
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct platform_device retu_device = {
+ .name = retu,
+ .id = -1,
+ .resource = retu_resource,
+ .num_resources = ARRAY_SIZE(retu_resource),
+};
+
static void __init nokia770_cbus_init(void)
{
+ int ret;
+
platform_device_register(nokia770_cbus_device);
+
+ ret = gpio_request(62, RETU irq);
+ if (ret 0) {
+ pr_err(retu: Unable to reserve IRQ GPIO\n);
+ return;
+ }
+
+ ret = gpio_direction_input(62);
+ if (ret 0) {
+ pr_err(retu: Unable to change gpio direction\n);
+ gpio_free(62);
+ return;
+ }
+
+ set_irq_type(gpio_to_irq(62), IRQ_TYPE_EDGE_RISING);
+ retu_resource[0].start = gpio_to_irq(62);
+ platform_device_register(retu_device);
}
#else
diff --git a/arch/arm/mach-omap2/board-n8x0.c b/arch/arm/mach-omap2/board-n8x0.c
index 67aaaef..938742d 100644
--- a/arch/arm/mach-omap2/board-n8x0.c
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@ -15,6 +15,7 @@
#include linux/delay.h
#include linux/gpio.h
#include linux/init.h
+#include linux/irq.h
#include linux/io.h
#include linux/stddef.h
#include linux/platform_device.h
@@ -221,9 +222,42 @@ static struct platform_device n8x0_cbus_device = {
},
};
+static struct resource retu_resource[] = {
+ {
+ .start = -EINVAL, /* set later */
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct platform_device retu_device = {
+ .name = retu,
+ .id = -1,
+ .resource = retu_resource,
+ .num_resources = ARRAY_SIZE(retu_resource),
+};
+
static void __init n8x0_cbus_init(void)
{
+ int ret;
+
platform_device_register(n8x0_cbus_device);
+
+ ret = gpio_request(108, RETU irq);
+ if (ret 0) {
+ pr_err(retu: Unable to reserve IRQ GPIO\n);
+ return;
+ }
+
+ ret = gpio_direction_input(108);
+ if (ret 0) {
+ pr_err(retu: Unable to change gpio direction\n);
+ gpio_free(108);
+ return;
+ }
+
+ set_irq_type(gpio_to_irq(108), IRQ_TYPE_EDGE_RISING);
+ retu_resource[0].start = gpio_to_irq(108);
+ platform_device_register(retu_device);
}
#else
diff --git a/drivers/cbus/retu.c b/drivers/cbus/retu.c
index 4a072da..a2977c9 100644
--- a/drivers/cbus/retu.c
+++ b/drivers/cbus/retu.c
@@ -50,7 +50,6 @@
#define PFXretu:
static int retu_initialized;
-static int retu_irq_pin;
static int retu_is_vilma;
static struct tasklet_struct retu_tasklet;
@@ -477,20 +476,6 @@ static struct platform_driver retu_driver = {
},
};
-static struct resource retu_resource[] = {
- {
- .start = -EINVAL, /* set later */
- .flags = IORESOURCE_IRQ,
- },
-};
-
-static struct platform_device retu_device = {
- .name = retu,
- .id = -1,
- .resource = retu_resource,
- .num_resources = ARRAY_SIZE(retu_resource),
-};
-
/**
* retu_init - initialise Retu driver
*
@@ -498,57 +483,7 @@ static struct platform_device retu_device = {
*/
static int __init retu_init(void)
{
- int ret = 0;
-
- /* REVISIT: Pass these from board-*.c files in platform_data */
- if (machine_is_nokia770()) {
- retu_irq_pin = 62;
- } else if (machine_is_nokia_n800() || machine_is_nokia_n810() ||
- machine_is_nokia_n810_wimax()) {
- retu_irq_pin = 108;
- } else {
- pr_err(retu: Unsupported board for retu\n);
- ret = -ENODEV;
- goto err0;
- }
-
- ret = gpio_request(retu_irq_pin, RETU irq);
- if (ret 0) {
- pr_err(retu: Unable to reserve IRQ GPIO\n);
- goto err0;
[PATCH 3/4] cbus: tahvo: move platform_device to board file
No functional changes, just moving platform_device
registration to the proper location.
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap1/board-nokia770.c | 32
arch/arm/mach-omap2/board-n8x0.c | 33 +
drivers/cbus/tahvo.c | 65 +-
3 files changed, 66 insertions(+), 64 deletions(-)
diff --git a/arch/arm/mach-omap1/board-nokia770.c
b/arch/arm/mach-omap1/board-nokia770.c
index 3969f2d..fabc154 100644
--- a/arch/arm/mach-omap1/board-nokia770.c
+++ b/arch/arm/mach-omap1/board-nokia770.c
@@ -127,6 +127,20 @@ static struct platform_device retu_device = {
.num_resources = ARRAY_SIZE(retu_resource),
};
+static struct resource tahvo_resource[] = {
+ {
+ .start = -EINVAL, /* set later */
+ .flags = IORESOURCE_IRQ,
+ }
+};
+
+static struct platform_device tahvo_device = {
+ .name = tahvo,
+ .id = -1,
+ .resource = tahvo_resource,
+ .num_resources = ARRAY_SIZE(tahvo_resource),
+};
+
static void __init nokia770_cbus_init(void)
{
int ret;
@@ -149,6 +163,24 @@ static void __init nokia770_cbus_init(void)
set_irq_type(gpio_to_irq(62), IRQ_TYPE_EDGE_RISING);
retu_resource[0].start = gpio_to_irq(62);
platform_device_register(retu_device);
+
+ ret = gpio_request(40, TAHVO irq);
+ if (ret) {
+ pr_err(tahvo: Unable to reserve IRQ GPIO\n);
+ gpio_free(62);
+ return;
+ }
+
+ ret = gpio_direction_input(40);
+ if (ret) {
+ pr_err(tahvo: Unable to change direction\n);
+ gpio_free(62);
+ gpio_free(40);
+ return;
+ }
+
+ tahvo_resource[0].start = gpio_to_irq(40);
+ platform_device_register(tahvo_device);
}
#else
diff --git a/arch/arm/mach-omap2/board-n8x0.c b/arch/arm/mach-omap2/board-n8x0.c
index 938742d..1823f01 100644
--- a/arch/arm/mach-omap2/board-n8x0.c
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@ -236,6 +236,20 @@ static struct platform_device retu_device = {
.num_resources = ARRAY_SIZE(retu_resource),
};
+static struct resource tahvo_resource[] = {
+ {
+ .start = -EINVAL, /* set later */
+ .flags = IORESOURCE_IRQ,
+ }
+};
+
+static struct platform_device tahvo_device = {
+ .name = tahvo,
+ .id = -1,
+ .resource = tahvo_resource,
+ .num_resources = ARRAY_SIZE(tahvo_resource),
+};
+
static void __init n8x0_cbus_init(void)
{
int ret;
@@ -258,6 +272,25 @@ static void __init n8x0_cbus_init(void)
set_irq_type(gpio_to_irq(108), IRQ_TYPE_EDGE_RISING);
retu_resource[0].start = gpio_to_irq(108);
platform_device_register(retu_device);
+
+ ret = gpio_request(111, TAHVO irq);
+ if (ret) {
+ pr_err(tahvo: Unable to reserve IRQ GPIO\n);
+ gpio_free(108);
+ return;
+ }
+
+ /* Set the pin as input */
+ ret = gpio_direction_input(111);
+ if (ret) {
+ pr_err(tahvo: Unable to change direction\n);
+ gpio_free(108);
+ gpio_free(111);
+ return;
+ }
+
+ tahvo_resource[0].start = gpio_to_irq(111);
+ platform_device_register(tahvo_device);
}
#else
diff --git a/drivers/cbus/tahvo.c b/drivers/cbus/tahvo.c
index 2ae1ac4..9699056 100644
--- a/drivers/cbus/tahvo.c
+++ b/drivers/cbus/tahvo.c
@@ -50,7 +50,6 @@
#define PFXtahvo:
static int tahvo_initialized;
-static int tahvo_irq_pin;
static int tahvo_is_betty;
static struct tasklet_struct tahvo_tasklet;
@@ -374,20 +373,6 @@ static struct platform_driver tahvo_driver = {
},
};
-static struct resource tahvo_resource[] = {
- {
- .start = -EINVAL, /* set later */
- .flags = IORESOURCE_IRQ,
- }
-};
-
-static struct platform_device tahvo_device = {
- .name = tahvo,
- .id = -1,
- .resource = tahvo_resource,
- .num_resources = ARRAY_SIZE(tahvo_resource),
-};
-
/**
* tahvo_init - initialise Tahvo driver
*
@@ -395,53 +380,7 @@ static struct platform_device tahvo_device = {
*/
static int __init tahvo_init(void)
{
- int ret = 0;
-
- /* REVISIT: Pass these from board-*.c files in platform_data */
- if (machine_is_nokia770()) {
- tahvo_irq_pin = 40;
- } else if (machine_is_nokia_n800() || machine_is_nokia_n810() ||
- machine_is_nokia_n810_wimax()) {
- tahvo_irq_pin = 111;
- } else {
- pr_err(tahvo: Unsupported board for tahvo\n);
- ret = -ENODEV;
- goto err0;
- }
-
- ret = gpio_request(tahvo_irq_pin, TAHVO irq);
- if (ret) {
-
[PATCH 4/4] cbus: tahvo-usb: move platform_device to board file
No functional changes, just moving platform_device
registration to the proper location.
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap1/board-nokia770.c |6 ++
arch/arm/mach-omap2/board-n8x0.c |6 ++
drivers/cbus/tahvo-usb.c | 15 ++-
3 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap1/board-nokia770.c
b/arch/arm/mach-omap1/board-nokia770.c
index fabc154..51bd52c 100644
--- a/arch/arm/mach-omap1/board-nokia770.c
+++ b/arch/arm/mach-omap1/board-nokia770.c
@@ -141,6 +141,11 @@ static struct platform_device tahvo_device = {
.num_resources = ARRAY_SIZE(tahvo_resource),
};
+static struct platform_device tahvo_usb_device = {
+ .name = tahvo-usb,
+ .id = -1,
+};
+
static void __init nokia770_cbus_init(void)
{
int ret;
@@ -181,6 +186,7 @@ static void __init nokia770_cbus_init(void)
tahvo_resource[0].start = gpio_to_irq(40);
platform_device_register(tahvo_device);
+ platform_device_register(tahvo_usb_device);
}
#else
diff --git a/arch/arm/mach-omap2/board-n8x0.c b/arch/arm/mach-omap2/board-n8x0.c
index 1823f01..ebd460e 100644
--- a/arch/arm/mach-omap2/board-n8x0.c
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@ -250,6 +250,11 @@ static struct platform_device tahvo_device = {
.num_resources = ARRAY_SIZE(tahvo_resource),
};
+static struct platform_device tahvo_usb_device = {
+ .name = tahvo-usb,
+ .id = -1,
+};
+
static void __init n8x0_cbus_init(void)
{
int ret;
@@ -291,6 +296,7 @@ static void __init n8x0_cbus_init(void)
tahvo_resource[0].start = gpio_to_irq(111);
platform_device_register(tahvo_device);
+ platform_device_register(tahvo_usb_device);
}
#else
diff --git a/drivers/cbus/tahvo-usb.c b/drivers/cbus/tahvo-usb.c
index 1cb81fd..3b83bab 100644
--- a/drivers/cbus/tahvo-usb.c
+++ b/drivers/cbus/tahvo-usb.c
@@ -742,30 +742,20 @@ static struct platform_driver tahvo_usb_driver = {
.remove = __exit_p(tahvo_usb_remove),
};
-static struct platform_device tahvo_usb_device = {
- .name = tahvo-usb,
- .id = -1,
-};
-
static int __init tahvo_usb_init(void)
{
int ret = 0;
- printk(KERN_INFO Tahvo USB transceiver driver initializing\n);
ret = platform_driver_probe(tahvo_usb_driver, tahvo_usb_probe);
if (ret)
return ret;
- ret = platform_device_register(tahvo_usb_device);
- if (ret 0) {
- platform_driver_unregister(tahvo_usb_driver);
- return ret;
- }
+
ret = platform_driver_probe(omap_otg_driver, omap_otg_probe);
if (ret) {
- platform_device_unregister(tahvo_usb_device);
platform_driver_unregister(tahvo_usb_driver);
return ret;
}
+
return 0;
}
@@ -774,7 +764,6 @@ subsys_initcall(tahvo_usb_init);
static void __exit tahvo_usb_exit(void)
{
platform_driver_unregister(omap_otg_driver);
- platform_device_unregister(tahvo_usb_device);
platform_driver_unregister(tahvo_usb_driver);
}
module_exit(tahvo_usb_exit);
--
1.7.3.rc0.35.g8ac8c
--
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 0/2] Trivial series
Hi Tony, found these while compiling n770_defconfig. Probably worth sending to mainline anyway ? Felipe Balbi (2): arm: omap1: devices: need to return with a value arm: omap1: remove unused variables arch/arm/mach-omap1/devices.c |2 +- arch/arm/mach-omap1/mailbox.c |1 - arch/arm/mach-omap1/pm_bus.c |1 - 3 files changed, 1 insertions(+), 3 deletions(-) -- 1.7.3.rc0.35.g8ac8c -- 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/2] arm: omap1: remove unused variables
Get rid of the following warnings:
arch/arm/mach-omap1/pm_bus.c: In function 'omap1_pm_runtime_resume':
arch/arm/mach-omap1/pm_bus.c:51: warning: unused variable 'ret'
arch/arm/mach-omap1/mailbox.c: In function 'omap1_mbox_probe':
arch/arm/mach-omap1/mailbox.c:148: warning: unused variable 'i'
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap1/mailbox.c |1 -
arch/arm/mach-omap1/pm_bus.c |1 -
2 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap1/mailbox.c b/arch/arm/mach-omap1/mailbox.c
index 1a85a42..1add133 100644
--- a/arch/arm/mach-omap1/mailbox.c
+++ b/arch/arm/mach-omap1/mailbox.c
@@ -145,7 +145,6 @@ static int __devinit omap1_mbox_probe(struct
platform_device *pdev)
{
struct resource *mem;
int ret;
- int i;
struct omap_mbox **list;
list = omap1_mboxes;
diff --git a/arch/arm/mach-omap1/pm_bus.c b/arch/arm/mach-omap1/pm_bus.c
index 8b66392..f97c6e9 100644
--- a/arch/arm/mach-omap1/pm_bus.c
+++ b/arch/arm/mach-omap1/pm_bus.c
@@ -48,7 +48,6 @@ static int omap1_pm_runtime_suspend(struct device *dev)
static int omap1_pm_runtime_resume(struct device *dev)
{
- int ret = 0;
struct clk *iclk, *fclk;
dev_dbg(dev, %s\n, __func__);
--
1.7.3.rc0.35.g8ac8c
--
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/2] arm: omap1: devices: need to return with a value
Get rid of the following warning:
arch/arm/mach-omap1/devices.c: In function 'omap_init_wdt':
arch/arm/mach-omap1/devices.c:298: warning: 'return' with
no value, in function returning non-void
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap1/devices.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap1/devices.c b/arch/arm/mach-omap1/devices.c
index 63d68cf..a037aba 100644
--- a/arch/arm/mach-omap1/devices.c
+++ b/arch/arm/mach-omap1/devices.c
@@ -295,7 +295,7 @@ static struct platform_device omap_wdt_device = {
static int __init omap_init_wdt(void)
{
if (!cpu_is_omap16xx())
- return;
+ return -ENODEV;
platform_device_register(omap_wdt_device);
return 0;
--
1.7.3.rc0.35.g8ac8c
--
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] omap: dsp: fix for ioremap()
Since ioremap() on RAM will be soon disallowed, this is required. This also requires a patch like: http://article.gmane.org/gmane.linux.kernel/1047146 Felipe Contreras (1): omap: dsp: remove shm from normal memory arch/arm/plat-omap/devices.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) -- 1.7.3.1.2.g7fe2b -- 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] omap: dsp: remove shm from normal memory
Also, don't be picky about the location.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
arch/arm/plat-omap/devices.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/devices.c b/arch/arm/plat-omap/devices.c
index 4c8f9b9..da10433 100644
--- a/arch/arm/plat-omap/devices.c
+++ b/arch/arm/plat-omap/devices.c
@@ -285,12 +285,14 @@ void __init omap_dsp_reserve_sdram_memblock(void)
if (!size)
return;
- paddr = __memblock_alloc_base(size, SZ_1M, MEMBLOCK_REAL_LIMIT);
+ paddr = memblock_alloc(size, SZ_1M);
if (!paddr) {
pr_err(%s: failed to reserve %x bytes\n,
__func__, size);
return;
}
+ memblock_free(paddr, size);
+ memblock_remove(paddr, size);
omap_dsp_phys_mempool_base = paddr;
}
--
1.7.3.1.2.g7fe2b
--
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 0/4] Horray, more CBUS patches
On Tue, 19 Oct 2010 10:29:14 +0300 Felipe Balbi ba...@ti.com wrote: I believe now everything is fine. Still, it's only compile tested with n770_defconfig and omap2plus_defconfig. Felipe Balbi (4): cbus: remove unneded includes cbus: retu: move platform_device to board file cbus: tahvo: move platform_device to board file cbus: tahvo-usb: move platform_device to board file omap2plus_defconfig doesn't include CONFIG_CBUS(_x) so you must enable them manually. -- Jarkko -- 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 0/4] Horray, more CBUS patches
On Tue, Oct 19, 2010 at 02:38:25AM -0500, Jarkko Nikula wrote: On Tue, 19 Oct 2010 10:29:14 +0300 Felipe Balbi ba...@ti.com wrote: I believe now everything is fine. Still, it's only compile tested with n770_defconfig and omap2plus_defconfig. Felipe Balbi (4): cbus: remove unneded includes cbus: retu: move platform_device to board file cbus: tahvo: move platform_device to board file cbus: tahvo-usb: move platform_device to board file omap2plus_defconfig doesn't include CONFIG_CBUS(_x) so you must enable them manually. I did that, don't worry -- balbi -- 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] omap: dsp: fix for ioremap()
On Tue, Oct 19, 2010 at 02:37:23AM -0500, Felipe Contreras wrote: Since ioremap() on RAM will be soon disallowed, this is required. This also requires a patch like: http://article.gmane.org/gmane.linux.kernel/1047146 Felipe Contreras (1): omap: dsp: remove shm from normal memory arch/arm/plat-omap/devices.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) -ENOPATCH ?? -- balbi -- 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] omap: dsp: fix for ioremap()
On Tue, Oct 19, 2010 at 02:38:34AM -0500, Balbi, Felipe wrote: On Tue, Oct 19, 2010 at 02:37:23AM -0500, Felipe Contreras wrote: Since ioremap() on RAM will be soon disallowed, this is required. This also requires a patch like: http://article.gmane.org/gmane.linux.kernel/1047146 Felipe Contreras (1): omap: dsp: remove shm from normal memory arch/arm/plat-omap/devices.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) -ENOPATCH ?? ok, now I got the patch. Just $SUBJECT is a bit misleading, sorry -- balbi -- 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: [PATCHv3 00/11] staging tidspbridge: iommu migration
On Tue, Oct 19, 2010 at 2:06 AM, Tony Lindgren t...@atomide.com wrote: * Felipe Contreras felipe.contre...@gmail.com [101015 13:09]: On Fri, Oct 15, 2010 at 7:53 PM, Guzman Lugo, Fernando fernando.l...@ti.com wrote: If you want I can provide my working branch on top of .36-rc8 with next-staging merged. If I revert your patches, it works fine. That could be interested. Can you send me the link? There you go: git://gitorious.org/~felipec/linux-omap/felipec.git (fc-dsp-work) HEAD works, HEAD^ doesn't. Great, can you please also let us know what if anything should be still queued for the merge window that's about to open? I've lost track of the dspbridge mutations by now.. We would need these: http://article.gmane.org/gmane.linux.kernel/1044209 http://article.gmane.org/gmane.linux.ports.arm.omap/45076 (just sent) The first one is in staging-next, you have ack'ed it, but Paul nak'ed it. We would need it on mainline if dsp has any chances of working there. -- Felipe Contreras -- 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] omap: dsp: fix for ioremap()
On Tue, Oct 19, 2010 at 10:39 AM, Felipe Balbi ba...@ti.com wrote: On Tue, Oct 19, 2010 at 02:38:34AM -0500, Balbi, Felipe wrote: On Tue, Oct 19, 2010 at 02:37:23AM -0500, Felipe Contreras wrote: Since ioremap() on RAM will be soon disallowed, this is required. This also requires a patch like: http://article.gmane.org/gmane.linux.kernel/1047146 Felipe Contreras (1): omap: dsp: remove shm from normal memory arch/arm/plat-omap/devices.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) -ENOPATCH ?? ok, now I got the patch. Just $SUBJECT is a bit misleading, sorry :) I thought on just sending the patch, but the last time there wasn't enough explanation that it depended on another one. -- Felipe Contreras -- 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] arm: omap1: devices: need to return with a value
On Tue, Oct 19, 2010 at 10:30:54AM +0300, Felipe Balbi wrote:
Get rid of the following warning:
arch/arm/mach-omap1/devices.c: In function 'omap_init_wdt':
arch/arm/mach-omap1/devices.c:298: warning: 'return' with
no value, in function returning non-void
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap1/devices.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap1/devices.c b/arch/arm/mach-omap1/devices.c
index 63d68cf..a037aba 100644
--- a/arch/arm/mach-omap1/devices.c
+++ b/arch/arm/mach-omap1/devices.c
@@ -295,7 +295,7 @@ static struct platform_device omap_wdt_device = {
static int __init omap_init_wdt(void)
{
if (!cpu_is_omap16xx())
- return;
+ return -ENODEV;
platform_device_register(omap_wdt_device);
return 0;
It's unrelated to this patch, but using
return platform_device_register(omap_wdt_device);
would be a bit cleaner.
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
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 5/6] TI816X: Enable Build for TI816X EVM
Tony Lindgren wrote on Friday, September 17, 2010 3:57 AM: * Hemant Pedanekar hema...@ti.com [100811 10:04]: This patch adds build support for TI816X. This enables building files in mach-omap2 and plat-omap directories. This you can merge into the patch adding the board-*.c file. Tony I will merge patch4 5. Thanks - Hemant -- 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] TWL IRQ: Fix fucntion declaration warnings
Hi Manjunath, On Wed, Oct 06, 2010 at 03:26:59AM +0530, G, Manjunath Kondaiah wrote: Fixes following sparse warnings for twl4030 and twl6030 irq files. drivers/mfd/twl4030-irq.c:783:5: warning: symbol 'twl4030_init_irq' was not declared. Should it be static? drivers/mfd/twl4030-irq.c:863:5: warning: symbol 'twl4030_exit_irq' was not declared. Should it be static? drivers/mfd/twl4030-irq.c:873:5: warning: symbol 'twl4030_init_chip_irq' was not declared. Should it be static? drivers/mfd/twl6030-irq.c:226:5: warning: symbol 'twl6030_init_irq' was not declared. Should it be static? drivers/mfd/twl6030-irq.c:290:5: warning: symbol 'twl6030_exit_irq' was not declared. Should it be static? Patch applied, thanks. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- 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 6/6] TI816X: Add low level debug support
Tony Lindgren wrote on Friday, September 17, 2010 3:58 AM: * Hemant Pedanekar hema...@ti.com [100811 10:04]: This patch adds support for low level debugging on TI816X boards. Currently the support for UART3 console on TI816X EVM is added. --- a/arch/arm/mach-omap2/include/mach/debug-macro.S +++ b/arch/arm/mach-omap2/include/mach/debug-macro.S @@ -66,6 +66,12 @@ omap_uart_lsr:.word 0 beq 34f @ configure OMAP3UART4 cmp \rx, #OMAP4UART4@ only on 44xx beq 44f @ configure OMAP4UART4 +cmp \rx, #TI816XUART1 @ ti816x UART offsets different +beq 81f @ configure UART1 +cmp \rx, #TI816XUART2 @ ti816x UART offsets different +beq 82f @ configure UART2 +cmp \rx, #TI816XUART3 @ ti816x UART offsets different +beq 83f @ configure UART3 cmp \rx, #ZOOM_UART @ only on zoom2/3 beq 95f @ configure ZOOM_UART Would be nice to have the TI816XUART defines in this patch too instead of defining them in some other patch earlier. Tony Can you please refer to the patch @https://patchwork.kernel.org/patch/118855/ The file arch/arm/plat-omap/include/plat/serial.h which has these defined, is part of this patch. Thanks - Hemant -- 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 0/5] 32k sync timer meets hwmod
Hi all, Converted 32k-sync timer to platform_driver and now using pm_runtime and hwmod. Tested on 3430 by me and 4430 by Tarun If someone could test on 2430 and 2420, I would be really glad. Felipe Balbi (5): arm: omap1/2/3/4: convert 32k-sync driver to a platform_driver arm: omap: counter-32k: convert to pm_runtime API clocksource: move omap 32k timer to drivers/clocksource arm: omap: introduce 32k timer hwmod for omap2/3/4 arm: omap: 32k: move to omap_device_build arch/arm/mach-omap1/devices.c | 24 +++ arch/arm/mach-omap2/clock2420_data.c |2 +- arch/arm/mach-omap2/clock2430_data.c |2 +- arch/arm/mach-omap2/clock3xxx_data.c |2 +- arch/arm/mach-omap2/devices.c | 36 + arch/arm/mach-omap2/omap_hwmod_2420_data.c | 52 ++ arch/arm/mach-omap2/omap_hwmod_2430_data.c | 52 ++ arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 51 ++ arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 61 arch/arm/plat-omap/Makefile|2 +- arch/arm/plat-omap/counter_32k.c | 183 -- drivers/clocksource/Makefile |1 + drivers/clocksource/omap-32k.c | 231 13 files changed, 512 insertions(+), 187 deletions(-) delete mode 100644 arch/arm/plat-omap/counter_32k.c create mode 100644 drivers/clocksource/omap-32k.c -- 1.7.3.1.120.g38a18 -- 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] arm: omap1/2/3/4: convert 32k-sync driver to a platform_driver
Convert the omap32k clocksource driver into a platform_driver
and while at that, also remove the ifdeferry around the code.
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap1/devices.c| 24
arch/arm/mach-omap2/clock2420_data.c |2 +-
arch/arm/mach-omap2/clock2430_data.c |2 +-
arch/arm/mach-omap2/clock3xxx_data.c |2 +-
arch/arm/mach-omap2/devices.c| 35 +
arch/arm/plat-omap/Makefile |2 +-
arch/arm/plat-omap/counter-32k.c | 253 ++
arch/arm/plat-omap/counter_32k.c | 183
8 files changed, 316 insertions(+), 187 deletions(-)
create mode 100644 arch/arm/plat-omap/counter-32k.c
delete mode 100644 arch/arm/plat-omap/counter_32k.c
diff --git a/arch/arm/mach-omap1/devices.c b/arch/arm/mach-omap1/devices.c
index 63d68cf..0f2a7ad 100644
--- a/arch/arm/mach-omap1/devices.c
+++ b/arch/arm/mach-omap1/devices.c
@@ -29,6 +29,29 @@
/*-*/
+#define OMAP16XX_TIMER_32K_BASE0xfffbc400
+
+static struct resource omap_32k_resources[] = {
+ {
+ .start = OMAP16XX_TIMER_32K_BASE,
+ .end= SZ_4K,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct platform_device omap_32k_device = {
+ .name = omap-counter-32k,
+ .id = -1,
+ .num_resources = ARRAY_SIZE(omap_32k_resources),
+ .resource = omap_32k_resources,
+};
+
+static void omap_init_32k(void)
+{
+ if (cpu_is_omap16xx())
+ (void) platform_device_register(omap_32k_device);
+};
+
#if defined(CONFIG_RTC_DRV_OMAP) || defined(CONFIG_RTC_DRV_OMAP_MODULE)
#defineOMAP_RTC_BASE 0xfffb4800
@@ -266,6 +289,7 @@ static int __init omap1_init_devices(void)
* in alphabetical order so they're easier to sort through.
*/
+ omap_init_32k();
omap_init_mbox();
omap_init_rtc();
omap_init_spi100k();
diff --git a/arch/arm/mach-omap2/clock2420_data.c
b/arch/arm/mach-omap2/clock2420_data.c
index 21f8562..6da8fc2 100644
--- a/arch/arm/mach-omap2/clock2420_data.c
+++ b/arch/arm/mach-omap2/clock2420_data.c
@@ -1842,7 +1842,7 @@ static struct omap_clk omap2420_clks[] = {
CLK(NULL, gpios_fck,gpios_fck, CK_242X),
CLK(omap_wdt, ick, mpu_wdt_ick, CK_242X),
CLK(omap_wdt, fck, mpu_wdt_fck, CK_242X),
- CLK(NULL, sync_32k_ick, sync_32k_ick, CK_242X),
+ CLK(omap-counter-32k, ick, sync_32k_ick, CK_242X),
CLK(NULL, wdt1_ick, wdt1_ick, CK_242X),
CLK(NULL, omapctrl_ick, omapctrl_ick, CK_242X),
CLK(omap24xxcam, fck, cam_fck, CK_242X),
diff --git a/arch/arm/mach-omap2/clock2430_data.c
b/arch/arm/mach-omap2/clock2430_data.c
index e32afcb..e5142cf 100644
--- a/arch/arm/mach-omap2/clock2430_data.c
+++ b/arch/arm/mach-omap2/clock2430_data.c
@@ -1954,7 +1954,7 @@ static struct omap_clk omap2430_clks[] = {
CLK(NULL, gpios_fck,gpios_fck, CK_243X),
CLK(omap_wdt, ick, mpu_wdt_ick, CK_243X),
CLK(omap_wdt, fck, mpu_wdt_fck, CK_243X),
- CLK(NULL, sync_32k_ick, sync_32k_ick, CK_243X),
+ CLK(omap-counter-32k, ick, sync_32k_ick, CK_243X),
CLK(NULL, wdt1_ick, wdt1_ick, CK_243X),
CLK(NULL, omapctrl_ick, omapctrl_ick, CK_243X),
CLK(NULL, icr_ick, icr_ick, CK_243X),
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index d85ecd5..548fba3 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3370,7 +3370,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(omap_wdt, ick, wdt2_ick, CK_3XXX),
CLK(NULL, wdt1_ick, wdt1_ick, CK_3XXX),
CLK(NULL, gpio1_ick,gpio1_ick, CK_3XXX),
- CLK(NULL, omap_32ksync_ick, omap_32ksync_ick, CK_3XXX),
+ CLK(omap-counter-32k, ick, omap_32ksync_ick, CK_3XXX),
CLK(NULL, gpt12_ick,gpt12_ick, CK_3XXX),
CLK(NULL, gpt1_ick, gpt1_ick, CK_3XXX),
CLK(omap-mcbsp.2, prcm_fck, per_96m_fck, CK_3XXX),
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index eaf3799..e64a78e 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -33,6 +33,40 @@
#include mux.h
#include control.h
+static struct resource omap_32k_resources[] = {
+ {
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct platform_device omap_32k_device = {
+ .name = omap-counter-32k,
+ .id = -1,
+ .num_resources =
[PATCH 2/5] arm: omap: counter-32k: convert to pm_runtime API
Trivial patch removing clock framework and adding
pm_runtime API.
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/plat-omap/counter-32k.c | 48 ++---
1 files changed, 13 insertions(+), 35 deletions(-)
diff --git a/arch/arm/plat-omap/counter-32k.c b/arch/arm/plat-omap/counter-32k.c
index f3fcb38..7bfd67a 100644
--- a/arch/arm/plat-omap/counter-32k.c
+++ b/arch/arm/plat-omap/counter-32k.c
@@ -27,7 +27,7 @@
#include linux/time.h
#include linux/clocksource.h
#include linux/platform_device.h
-#include linux/clk.h
+#include linux/pm_runtime.h
#include linux/err.h
struct omap_counter_32k_device {
@@ -37,7 +37,6 @@ struct omap_counter_32k_device {
cycles_tlast_cycles;
struct device *dev;
- struct clk *ick;
void __iomem*base;
/*
@@ -117,7 +116,6 @@ static int __init omap_counter_32k_probe(struct
platform_device *pdev)
{
struct omap_counter_32k_device *omap;
struct resource *res;
- struct clk *ick;
int ret;
@@ -130,11 +128,18 @@ static int __init omap_counter_32k_probe(struct
platform_device *pdev)
goto err0;
}
+ pm_runtime_enable(pdev-dev);
+ ret = pm_runtime_get_sync(pdev-dev);
+ if (ret) {
+ dev_dbg(pdev-dev, unable to enable runtime pm\n);
+ goto err1;
+ }
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
dev_dbg(pdev-dev, couldn't get resource\n);
ret = -ENODEV;
- goto err1;
+ goto err2;
}
base = ioremap(res-start, resource_size(res));
@@ -144,22 +149,8 @@ static int __init omap_counter_32k_probe(struct
platform_device *pdev)
goto err2;
}
- ick = clk_get(pdev-dev, ick);
- if (IS_ERR(ick)) {
- dev_dbg(pdev-dev, couldn't get clock\n);
- ret = PTR_ERR(ick);
- goto err3;
- }
-
- ret = clk_enable(ick);
- if (ret) {
- dev_dbg(pdev-dev, couldn't enable clock\n);
- goto err4;
- }
-
omap-base = base;
omap-dev = pdev-dev;
- omap-ick = ick;
omap-cs.name = counter-32k;
omap-cs.rating = 250;
@@ -174,7 +165,7 @@ static int __init omap_counter_32k_probe(struct
platform_device *pdev)
ret = clocksource_register(omap-cs);
if (ret) {
dev_dbg(pdev-dev, failed to register clocksource\n);
- goto err5;
+ goto err3;
}
/* initialize our offset */
@@ -190,16 +181,12 @@ static int __init omap_counter_32k_probe(struct
platform_device *pdev)
return 0;
-err5:
- clk_disable(ick);
-
-err4:
- clk_put(ick);
-
err3:
iounmap(base);
err2:
+ pm_runtime_put_sync(pdev-dev);
+
err1:
kfree(omap);
@@ -211,9 +198,8 @@ static int __exit omap_counter_32k_remove(struct
platform_device *pdev)
{
struct omap_counter_32k_device *omap = platform_get_drvdata(pdev);
+ pm_runtime_put_sync(pdev-dev);
clocksource_unregister(omap-cs);
- clk_disable(omap-ick);
- clk_put(omap-ick);
iounmap(omap-base);
kfree(omap);
platform_set_drvdata(pdev, NULL);
@@ -221,16 +207,8 @@ static int __exit omap_counter_32k_remove(struct
platform_device *pdev)
return 0;
}
-static void omap_counter_32k_shutdown(struct platform_device *pdev)
-{
- struct omap_counter_32k_device *omap = platform_get_drvdata(pdev);
-
- clk_disable(omap-ick);
-}
-
static struct platform_driver omap_counter_32k_driver = {
.remove = __exit_p(omap_counter_32k_remove),
- .shutdown = omap_counter_32k_shutdown,
.driver = {
.name = omap-counter-32k,
},
--
1.7.3.1.120.g38a18
--
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] clocksource: move omap 32k timer to drivers/clocksource
this is a better location for that driver. No changes to the code otherwise. Signed-off-by: Felipe Balbi ba...@ti.com --- arch/arm/plat-omap/Makefile|2 +- drivers/clocksource/Makefile |1 + .../clocksource/omap-32k.c |2 +- 3 files changed, 3 insertions(+), 2 deletions(-) rename arch/arm/plat-omap/counter-32k.c = drivers/clocksource/omap-32k.c (98%) diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile index ff57f33..2a15191 100644 --- a/arch/arm/plat-omap/Makefile +++ b/arch/arm/plat-omap/Makefile @@ -4,7 +4,7 @@ # Common support obj-y := common.o sram.o clock.o devices.o dma.o mux.o gpio.o \ -usb.o fb.o io.o counter-32k.o +usb.o fb.o io.o obj-m := obj-n := obj- := diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile index be61ece..ccdbc16 100644 --- a/drivers/clocksource/Makefile +++ b/drivers/clocksource/Makefile @@ -1,6 +1,7 @@ obj-$(CONFIG_ATMEL_TCB_CLKSRC) += tcb_clksrc.o obj-$(CONFIG_X86_CYCLONE_TIMER)+= cyclone.o obj-$(CONFIG_X86_PM_TIMER) += acpi_pm.o +obj-$(CONFIG_OMAP_32K_TIMER) += omap-32k.o obj-$(CONFIG_SCx200HR_TIMER) += scx200_hrt.o obj-$(CONFIG_CS5535_CLOCK_EVENT_SRC) += cs5535-clockevt.o obj-$(CONFIG_SH_TIMER_CMT) += sh_cmt.o diff --git a/arch/arm/plat-omap/counter-32k.c b/drivers/clocksource/omap-32k.c similarity index 98% rename from arch/arm/plat-omap/counter-32k.c rename to drivers/clocksource/omap-32k.c index 7bfd67a..5c61510 100644 --- a/arch/arm/plat-omap/counter-32k.c +++ b/drivers/clocksource/omap-32k.c @@ -1,5 +1,5 @@ /* - * counter-32k.c -- OMAP 32k Sync Timer Clocksource Driver + * omap-32k.c -- OMAP 32k Sync Timer Clocksource Driver * * Copyright (C) 2005-2010 Tony Lindgren t...@atomide.com * Copyright (C) 2010 Nokia Corporation -- 1.7.3.1.120.g38a18 -- 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 4/5] arm: omap: introduce 32k timer hwmod for omap2/3/4
Add 32k timer hwmod to the database.
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 52 +++
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 52 +++
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 51 +++
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 61
4 files changed, 216 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index a1a3dd6..05b9d2a 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -557,6 +557,57 @@ static struct omap_hwmod omap2420_i2c2_hwmod = {
.flags = HWMOD_16BIT_REG,
};
+/*
+ * 'counter' class
+ * 32-bit ordinary counter, clocked by the falling edge of the 32 khz clock
+ */
+
+static struct omap_hwmod_class omap2420_counter_hwmod_class = {
+ .name = counter,
+};
+
+/* counter_32k */
+static struct omap_hwmod omap2420_counter_32k_hwmod;
+static struct omap_hwmod_addr_space omap2420_counter_32k_addrs[] = {
+ {
+ .pa_start = 0x48004000,
+ .pa_end = 0x48000fff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_wkup - counter_32k */
+static struct omap_hwmod_ocp_if omap2420_l4_wkup__counter_32k = {
+ .master = omap2420_l4_wkup_hwmod,
+ .slave = omap2420_counter_32k_hwmod,
+ .clk= l4_ck,
+ .addr = omap2420_counter_32k_addrs,
+ .addr_cnt = ARRAY_SIZE(omap2420_counter_32k_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* counter_32k slave ports */
+static struct omap_hwmod_ocp_if *omap2420_counter_32k_slaves[] = {
+ omap2420_l4_wkup__counter_32k,
+};
+
+static struct omap_hwmod omap2420_counter_32k_hwmod = {
+ .name = counter_32k,
+ .class = omap2420_counter_hwmod_class,
+ .main_clk = sync_32k_ick,
+ .prcm = {
+ .omap2 = {
+ .prcm_reg_id = 1,
+ .module_bit = OMAP24XX_EN_GPT1_SHIFT,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit = OMAP24XX_ST_GPT1_SHIFT,
+ },
+ },
+ .slaves = omap2420_counter_32k_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap2420_counter_32k_slaves),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
+};
+
static __initdata struct omap_hwmod *omap2420_hwmods[] = {
omap2420_l3_main_hwmod,
omap2420_l4_core_hwmod,
@@ -569,6 +620,7 @@ static __initdata struct omap_hwmod *omap2420_hwmods[] = {
omap2420_uart3_hwmod,
omap2420_i2c1_hwmod,
omap2420_i2c2_hwmod,
+ omap2420_counter_32k_hwmod,
NULL,
};
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 7cf0d3a..96e9b12 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -569,6 +569,57 @@ static struct omap_hwmod omap2430_i2c2_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
};
+/*
+ * 'counter' class
+ * 32-bit ordinary counter, clocked by the falling edge of the 32 khz clock
+ */
+
+static struct omap_hwmod_class omap2430_counter_hwmod_class = {
+ .name = counter,
+};
+
+/* counter_32k */
+static struct omap_hwmod omap2430_counter_32k_hwmod;
+static struct omap_hwmod_addr_space omap2430_counter_32k_addrs[] = {
+ {
+ .pa_start = 0x48004000,
+ .pa_end = 0x48000fff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_wkup - counter_32k */
+static struct omap_hwmod_ocp_if omap2430_l4_wkup__counter_32k = {
+ .master = omap2430_l4_wkup_hwmod,
+ .slave = omap2430_counter_32k_hwmod,
+ .clk= l4_ck,
+ .addr = omap2430_counter_32k_addrs,
+ .addr_cnt = ARRAY_SIZE(omap2430_counter_32k_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* counter_32k slave ports */
+static struct omap_hwmod_ocp_if *omap2430_counter_32k_slaves[] = {
+ omap2430_l4_wkup__counter_32k,
+};
+
+static struct omap_hwmod omap2430_counter_32k_hwmod = {
+ .name = counter_32k,
+ .class = omap2430_counter_hwmod_class,
+ .main_clk = sync_32k_ick,
+ .prcm = {
+ .omap2 = {
+ .prcm_reg_id = 1,
+ .module_bit = OMAP24XX_EN_GPT1_SHIFT,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit = OMAP24XX_ST_GPT1_SHIFT,
+ },
+ },
+ .slaves = omap2430_counter_32k_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap2430_counter_32k_slaves),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
+};
+
static
[PATCH 5/5] arm: omap: 32k: move to omap_device_build
search on hwmod database and build omap_device
on the fly.
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap2/devices.c | 53 +
1 files changed, 27 insertions(+), 26 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index e64a78e..2d851b9 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -33,39 +33,40 @@
#include mux.h
#include control.h
-static struct resource omap_32k_resources[] = {
+struct omap_device_pm_latency omap_32k_latency[] = {
{
- .flags = IORESOURCE_MEM,
+ .deactivate_func= omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
},
};
-static struct platform_device omap_32k_device = {
- .name = omap-counter-32k,
- .id = -1,
- .num_resources = ARRAY_SIZE(omap_32k_resources),
- .resource = omap_32k_resources,
-};
-
-static void omap_init_32k(void)
+static int __init omap_init_32k(void)
{
- if (cpu_is_omap2420()) {
- omap_32k_resources[0].start = OMAP2420_32KSYNCT_BASE;
- omap_32k_resources[0].end = OMAP2420_32KSYNCT_BASE + SZ_4K;
- } else if (cpu_is_omap2430()) {
- omap_32k_resources[0].start = OMAP2430_32KSYNCT_BASE;
- omap_32k_resources[0].end = OMAP2430_32KSYNCT_BASE + SZ_4K;
- } else if (cpu_is_omap34xx()) {
- omap_32k_resources[0].start = OMAP3430_32KSYNCT_BASE;
- omap_32k_resources[0].end = OMAP3430_32KSYNCT_BASE + SZ_4K;
- } else if (cpu_is_omap44xx()) {
- omap_32k_resources[0].start = OMAP4430_32KSYNCT_BASE;
- omap_32k_resources[0].end = OMAP4430_32KSYNCT_BASE + SZ_4K;
- } else {/* not supported */
- return;
+ struct omap_device *od;
+ struct omap_hwmod *oh;
+
+ int id = -1;
+
+ const char *oh_name = counter_32k;
+ const char *dev_name = omap-counter-32k;
+
+ if (!cpu_class_is_omap2())
+ return 0;
+
+ oh = omap_hwmod_lookup(oh_name);
+ if (!oh) {
+ pr_err(Could not lookup %s hwmod\n, oh_name);
+ return -ENODEV;
}
- (void) platform_device_register(omap_32k_device);
-};
+ od = omap_device_build(dev_name, id, oh, NULL, 0,
+ omap_32k_latency, ARRAY_SIZE(omap_32k_latency), 0);
+ WARN(IS_ERR(od), Can't build omap device for %s:%s.\n,
+ dev_name, oh-name);
+
+ return 0;
+}
#if defined(CONFIG_VIDEO_OMAP2) || defined(CONFIG_VIDEO_OMAP2_MODULE)
--
1.7.3.1.120.g38a18
--
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 0/5] 32k sync timer meets hwmod
On Tue, Oct 19, 2010 at 04:22:11AM -0500, Balbi, Felipe wrote: Hi all, Converted 32k-sync timer to platform_driver and now using pm_runtime and hwmod. Tested on 3430 by me and 4430 by Tarun If someone could test on 2430 and 2420, I would be really glad. of course, after it's tested on 2430 and 2420 I will re-send Ccing LAKML and clksource maintainer. -- balbi -- 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] TWL IRQ: Fix fucntion declaration warnings
On Tue, Oct 19, 2010 at 11:06:14AM +0200, Samuel Ortiz wrote: Hi Manjunath, On Wed, Oct 06, 2010 at 03:26:59AM +0530, G, Manjunath Kondaiah wrote: Fixes following sparse warnings for twl4030 and twl6030 irq files. drivers/mfd/twl4030-irq.c:783:5: warning: symbol 'twl4030_init_irq' was not declared. Should it be static? drivers/mfd/twl4030-irq.c:863:5: warning: symbol 'twl4030_exit_irq' was not declared. Should it be static? drivers/mfd/twl4030-irq.c:873:5: warning: symbol 'twl4030_init_chip_irq' was not declared. Should it be static? drivers/mfd/twl6030-irq.c:226:5: warning: symbol 'twl6030_init_irq' was not declared. Should it be static? drivers/mfd/twl6030-irq.c:290:5: warning: symbol 'twl6030_exit_irq' was not declared. Should it be static? Patch applied, thanks. I didn't get the original patch, so I just now noticed the typo in the Subject. You might want to do s/fucntion/function/ Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- 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 2/6] TI816X: Update common omap platform files
Tony Lindgren wrote on Friday, September 17, 2010 4:01 AM: * Hemant Pedanekar hema...@ti.com [100811 10:03]: --- a/arch/arm/plat-omap/include/plat/serial.h +++ b/arch/arm/plat-omap/include/plat/serial.h @@ -51,6 +51,11 @@ #define OMAP4_UART3_BASE0x4802 #define OMAP4_UART4_BASE0x4806e000 +/* TI816X serial ports */ +#define TI816X_UART1_BASE 0x4802 +#define TI816X_UART2_BASE 0x48022000 +#define TI816X_UART3_BASE 0x48024000 + /* External port on Zoom2/3 */ #define ZOOM_UART_BASE 0x1000 #define ZOOM_UART_VIRT 0xfa40 These defines should get added by the serial port patch in the series, currently 6/6. Tony I have included them here because the common.c (part of this patch) requires UART base addresses in ti816x_globals while the same serial.h file is also part of patch 6 where TI816XUART definitions are used for LL DEBUG. Thanks - Hemant -- 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] spi/omap2_mcspi: disable channel after TX_ONLY transfer in PIO mode
In the TX_ONLY transfer, the SPI controller also receives data simultaneously and saves them in the rx register. After the TX_ONLY transfer, the rx register will hold the random data received during the last tx transaction. If the direct following transfer is RX_ONLY, this random data has the possibility to affect this transfer like this: When the SPI controller is changed from TX_ONLY to RX_ONLY, the random data makes the rx register full immediately and triggers a dummy write automatically(in SPI RX_ONLY transfers, we need a dummy write to trigger the first transaction). So the first data received in the RX_ONLY transfer will be that random data instead of something meaningful. We can avoid this by inserting a Disable/Re-enable toggle of the channel after the TX_ONLY transfer, since it purges the rx register. Signed-off-by: Jason Wang jason77.w...@gmail.com Tested-by: Grazvydas Ignotas nota...@gmail.com Acked-by: Tony Lindgren t...@atomide.com --- Hi Grant, The touchpanel driver can't work correctly on the omap3evm platform, This is due to a omap2_mcspi driver issue, now fix it. drivers/spi/omap2_mcspi.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c index b3a94ca..43fab41 100644 --- a/drivers/spi/omap2_mcspi.c +++ b/drivers/spi/omap2_mcspi.c @@ -644,6 +644,12 @@ omap2_mcspi_txrx_pio(struct spi_device *spi, struct spi_transfer *xfer) } else if (mcspi_wait_for_reg_bit(chstat_reg, OMAP2_MCSPI_CHSTAT_EOT) 0) dev_err(spi-dev, EOT timed out\n); + + /* disable chan to purge rx datas received in TX_ONLY transfer, +* otherwise these rx datas will affect the direct following +* RX_ONLY transfer. +*/ + omap2_mcspi_set_enable(spi, 0); } out: omap2_mcspi_set_enable(spi, 1); -- 1.5.6.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
[PATCH v2 0/3] usb: generic Kconfig fixes
This gets rid of some warnings, makes defconfigs smarter by having more proper dependencies, and general cleanups. BTW, this is the reason USB_GADGET_MUSB_HDRC sometimes is not selected: http://article.gmane.org/gmane.linux.kbuild.devel/5480 v2: comments by Felipe Balbi Felipe Contreras (3): usb: fix Kconfig warning usb: trivial Kconfig cleanups drivers: cleanup Kconfig stuff drivers/mfd/Kconfig|3 ++- drivers/regulator/Kconfig |1 + drivers/usb/core/Kconfig |3 --- drivers/usb/gadget/Kconfig | 16 ++-- drivers/usb/musb/Kconfig | 23 ++- drivers/usb/otg/Kconfig|2 ++ 6 files changed, 13 insertions(+), 35 deletions(-) -- 1.7.3.1.2.g7fe2b -- 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 v2 2/3] usb: trivial Kconfig cleanups
Note: USB_GADGET_MUSB_HDRC is already defined in usb/gadget. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- drivers/usb/core/Kconfig |3 --- drivers/usb/gadget/Kconfig |2 +- drivers/usb/musb/Kconfig | 17 - 3 files changed, 5 insertions(+), 17 deletions(-) diff --git a/drivers/usb/core/Kconfig b/drivers/usb/core/Kconfig index 9eed5b5..8f57a26 100644 --- a/drivers/usb/core/Kconfig +++ b/drivers/usb/core/Kconfig @@ -110,8 +110,6 @@ config USB_OTG bool depends on USB EXPERIMENTAL depends on USB_SUSPEND - default n - config USB_OTG_WHITELIST bool Rely on OTG Targeted Peripherals List @@ -139,4 +137,3 @@ config USB_OTG_BLACKLIST_HUB external hubs. OTG hosts are allowed to reduce hardware and software costs by not supporting external hubs. So are Embedded Hosts that don't offer OTG support. - diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig index 19a6eb6..c530bc6 100644 --- a/drivers/usb/gadget/Kconfig +++ b/drivers/usb/gadget/Kconfig @@ -125,7 +125,6 @@ choice config USB_GADGET_AT91 boolean Atmel AT91 USB Device Port depends on ARCH_AT91 !ARCH_AT91SAM9RL !ARCH_AT91CAP9 !ARCH_AT91SAM9G45 - select USB_GADGET_SELECTED help Many Atmel AT91 processors (such as the AT91RM2000) have a full speed USB Device Port with support for five configurable @@ -139,6 +138,7 @@ config USB_AT91 tristate depends on USB_GADGET_AT91 default USB_GADGET + select USB_GADGET_SELECTED config USB_GADGET_ATMEL_USBA boolean Atmel USBA diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig index cfd38ed..20895c4 100644 --- a/drivers/usb/musb/Kconfig +++ b/drivers/usb/musb/Kconfig @@ -8,12 +8,12 @@ comment Enable Host or Gadget support to see Inventra options # (M)HDRC = (Multipoint) Highspeed Dual-Role Controller config USB_MUSB_HDRC + tristate 'Inventra Highspeed Dual Role Controller (TI, ADI, ...)' depends on (USB || USB_GADGET) depends on (ARM || (BF54x !BF544) || (BF52x !BF522 !BF523)) select NOP_USB_XCEIV if (ARCH_DAVINCI || MACH_OMAP3EVM || BLACKFIN) select TWL4030_USB if MACH_OMAP_3430SDP select USB_OTG_UTILS - tristate 'Inventra Highspeed Dual Role Controller (TI, ADI, ...)' help Say Y here if your system has a dual role high speed USB controller based on the Mentor Graphics silicon IP. Then @@ -79,8 +79,8 @@ choice # use USB_MUSB_HDRC_HCD not USB_MUSB_HOST to #ifdef host side support; # OTG needs both roles, not just USB_MUSB_HOST. config USB_MUSB_HOST - depends on USB bool USB Host + depends on USB help Say Y here if your system supports the USB host role. If it has a USB A (rectangular), Mini-A (uncommon), @@ -90,8 +90,8 @@ config USB_MUSB_HOST # use USB_GADGET_MUSB_HDRC not USB_MUSB_PERIPHERAL to #ifdef peripheral # side support ... OTG needs both roles config USB_MUSB_PERIPHERAL - depends on USB_GADGET bool USB Peripheral (gadget stack) + depends on USB_GADGET select USB_GADGET_MUSB_HDRC help Say Y here if your system supports the USB peripheral role. @@ -100,8 +100,8 @@ config USB_MUSB_PERIPHERAL (With a Mini-AB connector, you should enable USB OTG.) config USB_MUSB_OTG - depends on USB USB_GADGET PM EXPERIMENTAL bool Both host and peripheral: USB OTG (On The Go) Device + depends on USB USB_GADGET PM EXPERIMENTAL select USB_GADGET_MUSB_HDRC select USB_OTG help @@ -125,14 +125,6 @@ config USB_MUSB_OTG endchoice -# enable peripheral support (including with OTG) -config USB_GADGET_MUSB_HDRC - bool - depends on USB_MUSB_HDRC (USB_MUSB_PERIPHERAL || USB_MUSB_OTG) -# default y -# select USB_GADGET_DUALSPEED -# select USB_GADGET_SELECTED - # enables host support (including with OTG) config USB_MUSB_HDRC_HCD bool @@ -140,7 +132,6 @@ config USB_MUSB_HDRC_HCD select USB_OTG if USB_GADGET_MUSB_HDRC default y - config MUSB_PIO_ONLY bool 'Disable DMA (always use PIO)' depends on USB_MUSB_HDRC -- 1.7.3.1.2.g7fe2b -- 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 v2 3/3] drivers: cleanup Kconfig stuff
Add missing dependencies, and remove redundant ones, and select sensible defaults. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- drivers/mfd/Kconfig|3 ++- drivers/regulator/Kconfig |1 + drivers/usb/gadget/Kconfig |3 +-- drivers/usb/musb/Kconfig |6 ++ drivers/usb/otg/Kconfig|2 ++ 5 files changed, 8 insertions(+), 7 deletions(-) diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index db51ea1..0bbaf01 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -156,6 +156,7 @@ config MENELAUS config TWL4030_CORE bool Texas Instruments TWL4030/TWL5030/TWL6030/TPS659x0 Support depends on I2C=y GENERIC_HARDIRQS + default y if ARCH_OMAP3 || ARCH_OMAP4 help Say yes here if you have TWL4030 / TWL6030 family chip on your board. This core driver provides register access and IRQ handling @@ -169,7 +170,7 @@ config TWL4030_CORE config TWL4030_POWER bool Support power resources on TWL4030 family chips - depends on TWL4030_CORE ARM + depends on TWL4030_CORE help Say yes here if you want to use the power resources on the TWL4030 family chips. Most of these resources are regulators, diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig index 172951b..af0439d 100644 --- a/drivers/regulator/Kconfig +++ b/drivers/regulator/Kconfig @@ -111,6 +111,7 @@ config REGULATOR_MAX8998 config REGULATOR_TWL4030 bool TI TWL4030/TWL5030/TWL6030/TPS695x0 PMIC depends on TWL4030_CORE + default y help This driver supports the voltage regulators provided by this family of companion chips. diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig index c530bc6..2aac57e 100644 --- a/drivers/usb/gadget/Kconfig +++ b/drivers/usb/gadget/Kconfig @@ -111,7 +111,6 @@ config USB_GADGET_SELECTED # choice prompt USB Peripheral Controller - depends on USB_GADGET help A USB device uses a controller to talk to its host. Systems should have only one such upstream link. @@ -191,7 +190,6 @@ config USB_GADGET_OMAP boolean OMAP USB Device Controller depends on ARCH_OMAP select ISP1301_OMAP if MACH_OMAP_H2 || MACH_OMAP_H3 || MACH_OMAP_H4_OTG - select USB_OTG_UTILS if ARCH_OMAP help Many Texas Instruments OMAP processors have flexible full speed USB device controllers, with support for up to 30 @@ -843,6 +841,7 @@ config USB_CDC_COMPOSITE config USB_G_NOKIA tristate Nokia composite gadget depends on PHONET + depends on USB_GADGET_MUSB_HDRC help The Nokia composite gadget provides support for acm, obex and phonet in only one composite gadget driver. diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig index 20895c4..a3f01f6 100644 --- a/drivers/usb/musb/Kconfig +++ b/drivers/usb/musb/Kconfig @@ -11,8 +11,7 @@ config USB_MUSB_HDRC tristate 'Inventra Highspeed Dual Role Controller (TI, ADI, ...)' depends on (USB || USB_GADGET) depends on (ARM || (BF54x !BF544) || (BF52x !BF522 !BF523)) - select NOP_USB_XCEIV if (ARCH_DAVINCI || MACH_OMAP3EVM || BLACKFIN) - select TWL4030_USB if MACH_OMAP_3430SDP + depends on (NOP_USB_XCEIV || TWL4030_USB) select USB_OTG_UTILS help Say Y here if your system has a dual role high speed USB @@ -59,8 +58,7 @@ comment Blackfin high speed USB Support config USB_TUSB6010 boolean TUSB 6010 support - depends on USB_MUSB_HDRC !USB_MUSB_SOC - select NOP_USB_XCEIV + depends on USB_MUSB_HDRC !USB_MUSB_SOC NOP_USB_XCEIV default y help The TUSB 6010 chip, from Texas Instruments, connects a discrete diff --git a/drivers/usb/otg/Kconfig b/drivers/usb/otg/Kconfig index 3b12895..2e5fd2d 100644 --- a/drivers/usb/otg/Kconfig +++ b/drivers/usb/otg/Kconfig @@ -53,6 +53,7 @@ config TWL4030_USB tristate TWL4030 USB Transceiver Driver depends on TWL4030_CORE REGULATOR_TWL4030 select USB_OTG_UTILS + default y if ARCH_OMAP3 help Enable this to support the USB OTG transceiver on TWL4030 family chips (including the TWL5030 and TPS659x0 devices). @@ -62,6 +63,7 @@ config TWL4030_USB config NOP_USB_XCEIV tristate NOP USB Transceiver Driver select USB_OTG_UTILS + default y if ARCH_DAVINCI || MACH_OMAP3EVM || BLACKFIN help this driver is to be used by all the usb transceiver which are either built-in with usb ip or which are autonomous and doesn't require any -- 1.7.3.1.2.g7fe2b -- 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 v2 1/3] usb: fix Kconfig warning
warning: (USB_MUSB_HDRC_HCD USB_SUPPORT USB_MUSB_HDRC (USB_MUSB_HOST || USB_MUSB_OTG) USB_GADGET_MUSB_HDRC || USB_MUSB_OTG choice USB USB_GADGET PM EXPERIMENTAL) selects USB_OTG which has unmet direct dependencies (USB_GADGET_OMAP ARCH_OMAP_OTG USB_OHCI_HCD) This doesn't seem to happen on 2.6.36-rc8, but still doesn't make sense to keep this duplicated config that is already defined in usb/core. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- drivers/usb/gadget/Kconfig | 11 --- 1 files changed, 0 insertions(+), 11 deletions(-) diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig index cd27f9b..19a6eb6 100644 --- a/drivers/usb/gadget/Kconfig +++ b/drivers/usb/gadget/Kconfig @@ -209,17 +209,6 @@ config USB_OMAP default USB_GADGET select USB_GADGET_SELECTED -config USB_OTG - boolean OTG Support - depends on USB_GADGET_OMAP ARCH_OMAP_OTG USB_OHCI_HCD - help - The most notable feature of USB OTG is support for a - Dual-Role device, which can act as either a device - or a host. The initial role choice can be changed - later, when two dual-role devices talk to each other. - - Select this only if your OMAP board has a Mini-AB connector. - config USB_GADGET_PXA25X boolean PXA 25x or IXP 4xx depends on (ARCH_PXA PXA25x) || ARCH_IXP4XX -- 1.7.3.1.2.g7fe2b -- 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 1/3] usb: fix Kconfig warning
On Tue, Oct 19, 2010 at 05:03:26AM -0500, Felipe Contreras wrote: warning: (USB_MUSB_HDRC_HCD USB_SUPPORT USB_MUSB_HDRC (USB_MUSB_HOST || USB_MUSB_OTG) USB_GADGET_MUSB_HDRC || USB_MUSB_OTG choice USB USB_GADGET PM EXPERIMENTAL) selects USB_OTG which has unmet direct dependencies (USB_GADGET_OMAP ARCH_OMAP_OTG USB_OHCI_HCD) This doesn't seem to happen on 2.6.36-rc8, but still doesn't make sense to keep this duplicated config that is already defined in usb/core. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com Since this is related to MUSB, Greg to do you want me to queue for -rc0 cycle and re-send for you ? -- balbi -- 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 3/3] drivers: cleanup Kconfig stuff
Hi, On Tue, Oct 19, 2010 at 05:03:28AM -0500, Felipe Contreras wrote: + depends on (NOP_USB_XCEIV || TWL4030_USB) + default y if ARCH_OMAP3 + default y if ARCH_DAVINCI || MACH_OMAP3EVM || BLACKFIN it could be only me, but I see these kind of dependencies tend to disaster. They can all grow to infinity. Soon, we will have another twl family of devices, or we will have another MACH_* which will need nop_xceiv, etc etc. -- balbi -- 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] TWL IRQ: Fix fucntion declaration warnings
Hi Uwe, On Tue, Oct 19, 2010 at 11:28:16AM +0200, Uwe Kleine-König wrote: On Tue, Oct 19, 2010 at 11:06:14AM +0200, Samuel Ortiz wrote: Hi Manjunath, On Wed, Oct 06, 2010 at 03:26:59AM +0530, G, Manjunath Kondaiah wrote: Fixes following sparse warnings for twl4030 and twl6030 irq files. drivers/mfd/twl4030-irq.c:783:5: warning: symbol 'twl4030_init_irq' was not declared. Should it be static? drivers/mfd/twl4030-irq.c:863:5: warning: symbol 'twl4030_exit_irq' was not declared. Should it be static? drivers/mfd/twl4030-irq.c:873:5: warning: symbol 'twl4030_init_chip_irq' was not declared. Should it be static? drivers/mfd/twl6030-irq.c:226:5: warning: symbol 'twl6030_init_irq' was not declared. Should it be static? drivers/mfd/twl6030-irq.c:290:5: warning: symbol 'twl6030_exit_irq' was not declared. Should it be static? Patch applied, thanks. I didn't get the original patch, so I just now noticed the typo in the Subject. You might want to do s/fucntion/function/ Yes, I noticed as well and fixed it, thanks. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- 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 3/3] drivers: cleanup Kconfig stuff
On Tue, Oct 19, 2010 at 1:32 PM, Felipe Balbi ba...@ti.com wrote: On Tue, Oct 19, 2010 at 05:03:28AM -0500, Felipe Contreras wrote: + depends on (NOP_USB_XCEIV || TWL4030_USB) + default y if ARCH_OMAP3 + default y if ARCH_DAVINCI || MACH_OMAP3EVM || BLACKFIN it could be only me, but I see these kind of dependencies tend to disaster. They can all grow to infinity. Soon, we will have another twl family of devices, or we will have another MACH_* which will need nop_xceiv, etc etc. The USB_MUSB_HDRC dependency on NOP_USB_XCEIV || TWL4030_USB is already there, I'm just making it explicit. The rest are not dependencies, just sensible defaults, and they are already in drivers/usb/musb/Kconfig, I'm just moving them. If you have a better approach to avoid manually selecting TWL4030_USB on defconfigs, and making sure USB_MUSB_HDRC works, please share it. -- Felipe Contreras -- 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 3/3] drivers: cleanup Kconfig stuff
Hi, On Tue, Oct 19, 2010 at 05:59:58AM -0500, Felipe Contreras wrote: The USB_MUSB_HDRC dependency on NOP_USB_XCEIV || TWL4030_USB is already there, I'm just making it explicit. The rest are not dependencies, just sensible defaults, and they are already in drivers/usb/musb/Kconfig, I'm just moving them. might be true, but what will happen is that other developers will just follow what's in the tree so they'll keep on adding more and more sesible defaults to this line. Linus had some really good comments about Kconfig usage some time ago and I'm sure he wouldn't like us adding sensible defaults all over the place. If you have a better approach to avoid manually selecting TWL4030_USB on defconfigs, and making sure USB_MUSB_HDRC works, please share it. that's the thing. Currently, I don't think it should be automatic as we can only have one transceiver structure. Look into drivers/usb/otg/otg.c, it's just a static global pointer on that file, which prevents us from having a working solution if you enable more than one transceiver. Ideally there would be a class or something similar to allow us to register N transceiver and use the correct one in runtime, that would make distro-makers' life easier. It'll probably help Linaro also at some point, but as of today, enabling more than one transceiver will never work. -- balbi -- 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] omap2plus: wdt: Fix boot warn when CONFIG_PM_RUNTIME=n
Paul, -Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Friday, October 15, 2010 12:08 AM To: Varadarajan, Charulatha Cc: Kevin Hilman; Cousson, Benoit; linux-omap@vger.kernel.org Subject: RE: [PATCH] omap2plus: wdt: Fix boot warn when CONFIG_PM_RUNTIME=n Hello Charu, Kevin, Benoît, On Thu, 14 Oct 2010, Varadarajan, Charulatha wrote: Please provide your input on this. Thinking about this problem -- and the earlier problem of how to determine what state to leave the watchdog in -- what occurs to me is that we should probably: Thanks for providing detailed input on this. 1. add a function pointer in the struct omap_hwmod_class for a custom pre-shutdown function, called before clocks are disabled, etc.; that can do the appropriate register writes needed during an omap_hwmod_shutdown() while the device is still considered to be enabled; 2. add a function to allow OMAP core code or board-*.c code to tell the hwmod code to leave a hwmod disabled at the end of _setup(), rather than idled or left enabled -- something like omap_hwmod_set_postsetup_state(HWMOD_STATE_DISABLED); 3. look to see if we can detect if the watchdog is enabled before the hwmod code starts -- perhaps by reading WSPR? -- and if it is not enabled, calling omap_hwmod_set_postsetup_state(HWMOD_STATE_DISABLED) prior to calling omap_hwmod_late_init(); 4. disable the MPU watchdog by default if #3 is not possible, and then allow specific board files to indicate that it should be enabled if they want full kernel boot watchdog coverage with something like omap_hwmod_set_postsetup_state(HWMOD_STATE_IDLE); and possibly also add a kernel command line parameter like enable_omapwdt_boot that can specify that the watchdog should be left enabled upon boot. This arrangement is a little more complicated, but it ensures that omap_hwmod_shutdown() really will shut down the watchdog. It also makes it possible for individual board files or bootloader configurations to ensure full watchdog coverage of the kernel initialization process. If I were designing a commercial OMAP-based device, I'd probably want full watchdog coverage of the entire boot process from the bootloader onwards. But simultaneously we don't want to change the existing kernel behavior too much -- most of our developer users would probably be shocked if, upon upgrading to a new kernel, suddenly the watchdog started rebooting their machines -- so it makes sense to me to disable the watchdog unless instructed otherwise. Enclosed below is a work-in-progress patch to illustrate the proposal. It clearly needs some more work and should be split into at least two patches, but it might help clarify what I am proposing. We also should, IMHO, move the struct omap_hwmod_class definitions out of the main hwmod data files, since they may contain function pointers. (We will probably also need a .reset function pointer there also to deal with complicated IPs like the IVA2, as we discussed a few months ago.) We should try to restrict the main omap_hwmod data files to be relatively OS-independent data structures. Regarding the omap_hwmod_is_enabled() proposal: it seems racy to me. In theory the system state can change after the result of omap_hwmod_is_enabled() is tested, but before the consequence of the conditional statement runs. There used to be a similar problem in the clock framework with a clk_is_enabled() function (a similar race still exists with the clk_get_rate() function). If possible, I think we should try to avoid creating APIs that are explicitly racy. Charu, I think that functions like omap2_disable_wdt() and any related watchdog device manipulation functions should go into their own file -- something like arch/arm/mach-omap2/wd_timer.c ? -- and not live in devices.c. Yes, you are right. I can do this in a new file arch/arm/mach-omap2/wd_timer.c. After doing this, I can also move the omap_device_build of wdt device from devices.c to mach-omap2/wd_timer.c. -V Charulatha One last thing: Benoît, in the hwmod data, I think we should separate watchdog IPs that are automatically enabled upon reset (like the MPU watchdog), from watchdogs that are disabled after reset (like the IVA2 watchdog). It doesn't matter to me whether we create a second class, or whether we just use a dev_attr flag. If we separate these, then code can use omap_hwmod_for_each_class() to ensure that all watchdogs of this type are disabled upon boot, rather than hardcoding a specific hwmod. Thoughts? ... As an aside, we seem to again be skirting issues of what it means for a hwmod to be enabled and idle. If we read enabled as fully functional and registers accessible, that seems to make sense; but if we consider idle as meaning configured but nonfunctional, that does not match up to the state that modules like WDT and GPIO are left in. The issue
Re: PATCH [0/4] perf: clean-up of power events API
On Sunday 10 October 2010 14:19:28 Ingo Molnar wrote: * Arjan van de Ven ar...@linux.intel.com wrote: ... also I have to say that some events are more likely to change than others function foo in the kernel called is more likely to change than the processor went to THIS frequency. The concept of CPU frequencies has been with us fora long time and is going to be there for a long time as well .. Right, it's a frequency and a CPU that should get passed along with the event. The X86/ACPI specific X-state data (even there unused and never will get used) should vanish before ARM starts to make use of it. The idle (power_start/power_end) state definition is worse... Most definitely. It's no accident that it took such a long time for this issue to be raised in the first place. It's a rare occurance - Do you agree that this occurance happened now and these events should get cleaned up before ARM and other archs make use of the broken interface? If not, discussing this further, is a big waste of time... and Jean would have to try to adapt his ARM code on the broken ABI... and then we can deal with it intelligently, without breaking stuff unnecessarily. Can we get this defined a bit clearer so that a patch can be created? Compatibility can only be achieved by still firing the old events for some kernel rounds. I'll send some patches in a new thread with these people in CC. It would be great to see a decision (in a way that a patch can be created) how an event change can/should look like if there is urgent need. Thanks, Thomas -- 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/3] PERF(userspace): Adjust perf timechart to the new power events
The transition was rather smooth, only part I had to fiddle
some time was the check whether a tracepoint/event is
supported by the running kernel.
builtin-timechart must only pass -e power:xy events which
are supported by the running kernel.
For this I added the tiny helper function:
int is_valid_tracepoint(const char *event_string)
to parse-events.[hc]
which could be more generic as an interface and support
hardware/software/... events, not only tracepoints, but someone
else could extend that if needed...
Signed-off-by: Thomas Renninger tr...@suse.de
CC: Linus Torvalds torva...@linux-foundation.org
CC: Andrew Morton a...@linux-foundation.org
CC: Thomas Gleixner t...@linutronix.de
CC: Masami Hiramatsu masami.hiramatsu...@hitachi.com
CC: Frank Eigler f...@redhat.com
CC: Steven Rostedt rost...@goodmis.org
CC: Kevin Hilman khil...@deeprootsystems.com
CC: Peter Zijlstra pet...@infradead.org
CC: linux-omap@vger.kernel.org
CC: r...@sisk.pl
CC: linux...@lists.linux-foundation.org
CC: linux-trace-us...@vger.kernel.org
CC: Jean Pihet jean.pi...@newoldbits.com
CC: Pierre Tardy tar...@gmail.com
CC: Frederic Weisbecker fweis...@gmail.com
CC: Tejun Heo t...@kernel.org
CC: Mathieu Desnoyers mathieu.desnoy...@efficios.com
CC: Arjan van de Ven ar...@linux.intel.com
CC: Ingo Molnar mi...@elte.hu
---
tools/perf/builtin-timechart.c | 87 ---
tools/perf/util/parse-events.c | 43 +++-
tools/perf/util/parse-events.h |1 +
3 files changed, 114 insertions(+), 17 deletions(-)
diff --git a/tools/perf/builtin-timechart.c b/tools/perf/builtin-timechart.c
index 9bcc38f..1304c27 100644
--- a/tools/perf/builtin-timechart.c
+++ b/tools/perf/builtin-timechart.c
@@ -32,6 +32,8 @@
#include util/session.h
#include util/svghelper.h
+#define SUPPORT_OLD_POWER_EVENTS 1
+
static charconst *input_name = perf.data;
static charconst *output_name = output.svg;
@@ -298,12 +300,25 @@ struct trace_entry {
int lock_depth;
};
-struct power_entry {
+#if defined(SUPPORT_OLD_POWER_EVENTS)
+struct power_entry_old {
struct trace_entry te;
u64 type;
u64 value;
u64 cpu_id;
};
+#endif
+
+struct power_processor_entry {
+ struct trace_entry te;
+ u64 state;
+ u64 cpu_id;
+};
+
+struct power_suspend_entry {
+ struct trace_entry te;
+ u64 state;
+};
#define TASK_COMM_LEN 16
struct wakeup_entry {
@@ -489,29 +504,46 @@ static int process_sample_event(event_t *event, struct
perf_session *session)
te = (void *)data.raw_data;
if (session-sample_type PERF_SAMPLE_RAW data.raw_size 0) {
char *event_str;
- struct power_entry *pe;
-
- pe = (void *)te;
+#if defined(SUPPORT_OLD_POWER_EVENTS)
+ struct power_entry_old *peo;
+ peo = (void *)te;
+#endif
event_str = perf_header__find_event(te-type);
if (!event_str)
return 0;
- if (strcmp(event_str, power:power_start) == 0)
- c_state_start(pe-cpu_id, data.time, pe-value);
-
- if (strcmp(event_str, power:power_end) == 0)
- c_state_end(pe-cpu_id, data.time);
+ if (strcmp(event_str, power:processor_idle) == 0) {
+ struct power_processor_entry *ppe = (void *)te;
+ if (ppe-state == 0)
+ c_state_end(ppe-cpu_id, data.time);
+ else
+ c_state_start(ppe-cpu_id, data.time,
+ ppe-state);
+ }
- if (strcmp(event_str, power:power_frequency) == 0)
- p_state_change(pe-cpu_id, data.time, pe-value);
+ else if (strcmp(event_str, power:processor_frequency) == 0) {
+ struct power_processor_entry *ppe = (void *)te;
+ p_state_change(ppe-cpu_id, data.time, ppe-state);
+ }
- if (strcmp(event_str, sched:sched_wakeup) == 0)
+ else if (strcmp(event_str, sched:sched_wakeup) == 0)
sched_wakeup(data.cpu, data.time, data.pid, te);
- if (strcmp(event_str, sched:sched_switch) == 0)
+ else if (strcmp(event_str, sched:sched_switch) == 0)
sched_switch(data.cpu, data.time, te);
+
+#if defined(SUPPORT_OLD_POWER_EVENTS)
+ else if (strcmp(event_str, power:power_start) == 0)
+ c_state_start(peo-cpu_id, data.time, peo-value);
+
+ else if (strcmp(event_str, power:power_end) == 0)
+ c_state_end(peo-cpu_id, data.time);
+
+ else if (strcmp(event_str, power:power_frequency) == 0)
+ p_state_change(peo-cpu_id, data.time, peo-value);
[PATCH 1/3] PERF: Do not export power_frequency, but power_start event
power_frequency moved to drivers/cpufreq/cpufreq.c which has
to be compiled in, no need to export it.
intel_idle can a be module though...
Signed-off-by: Thomas Renninger tr...@suse.de
CC: Linus Torvalds torva...@linux-foundation.org
CC: Andrew Morton a...@linux-foundation.org
CC: Thomas Gleixner t...@linutronix.de
CC: Masami Hiramatsu masami.hiramatsu...@hitachi.com
CC: Frank Eigler f...@redhat.com
CC: Steven Rostedt rost...@goodmis.org
CC: Kevin Hilman khil...@deeprootsystems.com
CC: Peter Zijlstra pet...@infradead.org
CC: linux-omap@vger.kernel.org
CC: r...@sisk.pl
CC: linux...@lists.linux-foundation.org
CC: linux-trace-us...@vger.kernel.org
CC: Jean Pihet jean.pi...@newoldbits.com
CC: Pierre Tardy tar...@gmail.com
CC: Frederic Weisbecker fweis...@gmail.com
CC: Tejun Heo t...@kernel.org
CC: Mathieu Desnoyers mathieu.desnoy...@efficios.com
CC: Arjan van de Ven ar...@linux.intel.com
CC: Ingo Molnar mi...@elte.hu
---
drivers/idle/intel_idle.c |2 --
kernel/trace/power-traces.c |2 +-
2 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c
index c37ef64..21ac077 100644
--- a/drivers/idle/intel_idle.c
+++ b/drivers/idle/intel_idle.c
@@ -201,9 +201,7 @@ static int intel_idle(struct cpuidle_device *dev, struct
cpuidle_state *state)
kt_before = ktime_get_real();
stop_critical_timings();
-#ifndef MODULE
trace_power_start(POWER_CSTATE, (eax 4) + 1, cpu);
-#endif
if (!need_resched()) {
__monitor((void *)current_thread_info()-flags, 0, 0);
diff --git a/kernel/trace/power-traces.c b/kernel/trace/power-traces.c
index a22582a..0e0497d 100644
--- a/kernel/trace/power-traces.c
+++ b/kernel/trace/power-traces.c
@@ -13,5 +13,5 @@
#define CREATE_TRACE_POINTS
#include trace/events/power.h
-EXPORT_TRACEPOINT_SYMBOL_GPL(power_frequency);
+EXPORT_TRACEPOINT_SYMBOL_GPL(power_start);
--
1.6.0.2
--
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 3/3] drivers: cleanup Kconfig stuff
On Tue, Oct 19, 2010 at 2:16 PM, Felipe Balbi ba...@ti.com wrote: On Tue, Oct 19, 2010 at 05:59:58AM -0500, Felipe Contreras wrote: The USB_MUSB_HDRC dependency on NOP_USB_XCEIV || TWL4030_USB is already there, I'm just making it explicit. The rest are not dependencies, just sensible defaults, and they are already in drivers/usb/musb/Kconfig, I'm just moving them. might be true, but what will happen is that other developers will just follow what's in the tree so they'll keep on adding more and more sesible defaults to this line. That is actually the intention. Linus had some really good comments about Kconfig usage some time ago and I'm sure he wouldn't like us adding sensible defaults all over the place. It's the other way around. He wanted to get rid of defconfigs completely by moving the complexity to Kconfigs: http://article.gmane.org/gmane.linux.kernel/994720 http://article.gmane.org/gmane.linux.kernel/994706 http://article.gmane.org/gmane.linux.kernel/994718 You seem to be pushing for the exact opposite; keep the complexity on the defconfigs and the burden on the user creating configs. If you have a better approach to avoid manually selecting TWL4030_USB on defconfigs, and making sure USB_MUSB_HDRC works, please share it. that's the thing. Currently, I don't think it should be automatic as we can only have one transceiver structure. Look into drivers/usb/otg/otg.c, it's just a static global pointer on that file, which prevents us from having a working solution if you enable more than one transceiver. Ideally there would be a class or something similar to allow us to register N transceiver and use the correct one in runtime, that would make distro-makers' life easier. It'll probably help Linaro also at some point, but as of today, enabling more than one transceiver will never work. Ok. But for now 'default y if ARCH_OMAP3' for TWL4030_USB doesn't hurt, nor increases the total size of Kconfigs, and solves a real problem. -- Felipe Contreras -- 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 [0/4] perf: clean-up of power events API
* Thomas Renninger tr...@suse.de wrote: Most definitely. It's no accident that it took such a long time for this issue to be raised in the first place. It's a rare occurance - Do you agree that this occurance happened now and these events should get cleaned up before ARM and other archs make use of the broken interface? If not, discussing this further, is a big waste of time... and Jean would have to try to adapt his ARM code on the broken ABI... The discussion seems to have died down somewhat. Please re-send to lkml the latest patches you have to remind everyone of the latest state of things - the merge window is getting near. My only compatibility/ABI point is basically that it shouldnt break _existing_ tracepoints (and users thereof). If your latest bits meet that then it ought to be a good first step. You are free to (and encouraged to) introduce more complete sets of events. Thanks, Ingo -- 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 [0/4] perf: clean-up of power events API
* Peter Zijlstra pet...@infradead.org wrote: On Tue, 2010-10-19 at 13:45 +0200, Ingo Molnar wrote: * Thomas Renninger tr...@suse.de wrote: Most definitely. It's no accident that it took such a long time for this issue to be raised in the first place. It's a rare occurance - Do you agree that this occurance happened now and these events should get cleaned up before ARM and other archs make use of the broken interface? If not, discussing this further, is a big waste of time... and Jean would have to try to adapt his ARM code on the broken ABI... The discussion seems to have died down somewhat. Please re-send to lkml the latest patches you have to remind everyone of the latest state of things - the merge window is getting near. My only compatibility/ABI point is basically that it shouldnt break _existing_ tracepoints (and users thereof). If your latest bits meet that then it ought to be a good first step. You are free to (and encouraged to) introduce more complete sets of events. Can we deprecate and eventually remove the old ones, or will we be forever obliged to carry the old ones too? We most definitely want to deprecate and remove the old ones - but we want to give instrumentation software some migration time for that. Jean, Arjan, what would be a feasible and practical deprecation period for that? One kernel cycle? Thanks, Ingo -- 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 3/3] drivers: cleanup Kconfig stuff
Hi, On Tue, Oct 19, 2010 at 06:36:32AM -0500, Felipe Contreras wrote: That is actually the intention. so it's a bit messed up one :-p It's the other way around. He wanted to get rid of defconfigs completely by moving the complexity to Kconfigs: Yes, but he was suggesting to add things like Kconfig.rx51 and that would be selecting correct drivers to get rx51 working, he was definitely not suggesting to add sensible defaults all over the tree. http://article.gmane.org/gmane.linux.kernel/994720 http://article.gmane.org/gmane.linux.kernel/994706 http://article.gmane.org/gmane.linux.kernel/994718 You seem to be pushing for the exact opposite; keep the complexity on the defconfigs and the burden on the user creating configs. no, you got me wrong. We do need to get rid of defconfigs, but we have to do so while keeping the resulting binary working and as of today, if you enable more than one transceiver driver, it won't work. Ok. But for now 'default y if ARCH_OMAP3' for TWL4030_USB doesn't hurt, nor increases the total size of Kconfigs, and solves a real problem. I don't see it that way. I see that there will be boards with one too many transceivers enabled and the resulting binary won't work, but I'll leave that for Greg to decide. -- balbi -- 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 [0/4] perf: clean-up of power events API
On Tue, 2010-10-19 at 13:45 +0200, Ingo Molnar wrote: * Thomas Renninger tr...@suse.de wrote: Most definitely. It's no accident that it took such a long time for this issue to be raised in the first place. It's a rare occurance - Do you agree that this occurance happened now and these events should get cleaned up before ARM and other archs make use of the broken interface? If not, discussing this further, is a big waste of time... and Jean would have to try to adapt his ARM code on the broken ABI... The discussion seems to have died down somewhat. Please re-send to lkml the latest patches you have to remind everyone of the latest state of things - the merge window is getting near. My only compatibility/ABI point is basically that it shouldnt break _existing_ tracepoints (and users thereof). If your latest bits meet that then it ought to be a good first step. You are free to (and encouraged to) introduce more complete sets of events. Can we deprecate and eventually remove the old ones, or will we be forever obliged to carry the old ones too? -- 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: [RFC v3][PATCH 0/4] OMAP: DSS2: Overlay Manager LCD2 support in DISPC
Hi, On Tue, 2010-10-05 at 13:55 +0200, ext Archit Taneja wrote: This patch series which incorporates changes in DSS2 to enable omap_dss_device instances to use the new Overlay Manager LCD2 in DISPC. On OMAP4, we have a new DISPC channel for Overlay Manager LCD2. This channel's video port is a source port for RFBI, DSI2 and DPI. The Primary channel's video port is connected to RFBI and DSI1. There is a set of regsiters for LCD2 channel similar to the existing LCD channel, like DISPC_CONTROL2, DISPC_DIVISOR2, DISPC_CONFIG2 and so on. In order to decide which LCD Overlay Manager to configure(LCD/LCD2), there is a need for the omap_dss_device instances to tell the interface drivers(DSI, DPI, RFBI etc) which LCD channel they want to connect to, so that the corresponding registers get configured. Therefore, a new enum omap_channel member is introduced to omap_dss_device. This design was made keeping in mind the possible addition of more Overlay Managers in future OMAPs, this code is also backward compatible with OMAP3 as omap_dss_device instances in OMAP3 will stick only with OMAP_DSS_CHANNEL_LCD. This will apply over the set of dss_feature framework patches: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg34768.html The patchset makes dispc API changes in patch 2, but doesn't change any of the code that uses that API. This means that the kernel doesn't compile after applying patch 2. The kernel has to be compilable and working after each patch, so that is not acceptable. Fixing that in easy way would mean squashing the later patches together with patch 2, but that would result in a huge patch, and patch 2 is already very big. Thus I'd suggest doing the changes in smaller bits. You could first add the register definitions, and make the changes in dispc.c to keep everything working. After that you could change the dispc functions, one by one or in small groups (depending on the amount of changes), and add the channel argument and adjusting the code using those functions in the same time. This would solve the problem of keeping the kernel working, and would make the patches much more readable. Tomi -- 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 [0/4] perf: clean-up of power events API
On 10/19/2010 4:52 AM, Ingo Molnar wrote: * Peter Zijlstrapet...@infradead.org wrote: On Tue, 2010-10-19 at 13:45 +0200, Ingo Molnar wrote: * Thomas Renningertr...@suse.de wrote: Most definitely. It's no accident that it took such a long time for this issue to be raised in the first place. It's a rare occurance - Do you agree that this occurance happened now and these events should get cleaned up before ARM and other archs make use of the broken interface? If not, discussing this further, is a big waste of time... and Jean would have to try to adapt his ARM code on the broken ABI... The discussion seems to have died down somewhat. Please re-send to lkml the latest patches you have to remind everyone of the latest state of things - the merge window is getting near. My only compatibility/ABI point is basically that it shouldnt break _existing_ tracepoints (and users thereof). If your latest bits meet that then it ought to be a good first step. You are free to (and encouraged to) introduce more complete sets of events. Can we deprecate and eventually remove the old ones, or will we be forever obliged to carry the old ones too? We most definitely want to deprecate and remove the old ones - but we want to give instrumentation software some migration time for that. Jean, Arjan, what would be a feasible and practical deprecation period for that? One kernel cycle? more like a year for some time software needs to support both, especially if popular distros stick to an older kernel like *cough* RHEL6 -- 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 3/3] drivers: cleanup Kconfig stuff
Hi Felipe, On 10/19/2010 01:03 PM, ext Felipe Contreras wrote: Add missing dependencies, and remove redundant ones, and select sensible defaults. Signed-off-by: Felipe Contrerasfelipe.contre...@gmail.com --- drivers/mfd/Kconfig|3 ++- drivers/regulator/Kconfig |1 + drivers/usb/gadget/Kconfig |3 +-- drivers/usb/musb/Kconfig |6 ++ drivers/usb/otg/Kconfig|2 ++ 5 files changed, 8 insertions(+), 7 deletions(-) diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig index c530bc6..2aac57e 100644 --- a/drivers/usb/gadget/Kconfig +++ b/drivers/usb/gadget/Kconfig @@ -111,7 +111,6 @@ config USB_GADGET_SELECTED # choice prompt USB Peripheral Controller - depends on USB_GADGET help A USB device uses a controller to talk to its host. Systems should have only one such upstream link. @@ -191,7 +190,6 @@ config USB_GADGET_OMAP boolean OMAP USB Device Controller depends on ARCH_OMAP select ISP1301_OMAP if MACH_OMAP_H2 || MACH_OMAP_H3 || MACH_OMAP_H4_OTG - select USB_OTG_UTILS if ARCH_OMAP help Many Texas Instruments OMAP processors have flexible full speed USB device controllers, with support for up to 30 @@ -843,6 +841,7 @@ config USB_CDC_COMPOSITE config USB_G_NOKIA tristate Nokia composite gadget depends on PHONET + depends on USB_GADGET_MUSB_HDRC This is wrong. Is there a build problem or run-time problem without this? -- regards, -roger -- 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 [0/4] perf: clean-up of power events API
* Arjan van de Ven ar...@linux.intel.com wrote: On 10/19/2010 4:52 AM, Ingo Molnar wrote: * Peter Zijlstrapet...@infradead.org wrote: On Tue, 2010-10-19 at 13:45 +0200, Ingo Molnar wrote: * Thomas Renningertr...@suse.de wrote: Most definitely. It's no accident that it took such a long time for this issue to be raised in the first place. It's a rare occurance - Do you agree that this occurance happened now and these events should get cleaned up before ARM and other archs make use of the broken interface? If not, discussing this further, is a big waste of time... and Jean would have to try to adapt his ARM code on the broken ABI... The discussion seems to have died down somewhat. Please re-send to lkml the latest patches you have to remind everyone of the latest state of things - the merge window is getting near. My only compatibility/ABI point is basically that it shouldnt break _existing_ tracepoints (and users thereof). If your latest bits meet that then it ought to be a good first step. You are free to (and encouraged to) introduce more complete sets of events. Can we deprecate and eventually remove the old ones, or will we be forever obliged to carry the old ones too? We most definitely want to deprecate and remove the old ones - but we want to give instrumentation software some migration time for that. Jean, Arjan, what would be a feasible and practical deprecation period for that? One kernel cycle? more like a year for some time software needs to support both, especially if popular distros stick to an older kernel like *cough* RHEL6 Sure, you can support both. But as long as support for the _new_ events is included in PowerTop there's no need to keep the duality upstream. Running ancient PowerTop on fresh kernels is not common. An old RHEL kernel will still keep on working as you can keep support for old events in PowerTop as long as you wish to. The new kernel also wont 'overwrite' old events with new definitions in the future, so PowerTop will keep working for as long as you want to support older kernels. Does that sound good? Thanks, Ingo -- 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 [0/4] perf: clean-up of power events API
On 10/19/2010 6:50 AM, Ingo Molnar wrote: * Arjan van de Venar...@linux.intel.com wrote: On 10/19/2010 4:52 AM, Ingo Molnar wrote: * Peter Zijlstrapet...@infradead.org wrote: On Tue, 2010-10-19 at 13:45 +0200, Ingo Molnar wrote: * Thomas Renningertr...@suse.de wrote: Most definitely. It's no accident that it took such a long time for this issue to be raised in the first place. It's a rare occurance - Do you agree that this occurance happened now and these events should get cleaned up before ARM and other archs make use of the broken interface? If not, discussing this further, is a big waste of time... and Jean would have to try to adapt his ARM code on the broken ABI... The discussion seems to have died down somewhat. Please re-send to lkml the latest patches you have to remind everyone of the latest state of things - the merge window is getting near. My only compatibility/ABI point is basically that it shouldnt break _existing_ tracepoints (and users thereof). If your latest bits meet that then it ought to be a good first step. You are free to (and encouraged to) introduce more complete sets of events. Can we deprecate and eventually remove the old ones, or will we be forever obliged to carry the old ones too? We most definitely want to deprecate and remove the old ones - but we want to give instrumentation software some migration time for that. Jean, Arjan, what would be a feasible and practical deprecation period for that? One kernel cycle? more like a year for some time software needs to support both, especially if popular distros stick to an older kernel like *cough* RHEL6 Sure, you can support both. But as long as support for the _new_ events is included in PowerTop there's no need to keep the duality upstream. Running ancient PowerTop on fresh kernels is not common. An old RHEL kernel will still keep on working as you can keep support for old events in PowerTop as long as you wish to. The new kernel also wont 'overwrite' old events with new definitions in the future, so PowerTop will keep working for as long as you want to support older kernels. Does that sound good? this does not scale much long term, eg this only works if this is only done once, and these points are stable afterwards. otherwise we get 25 of those different workarounds for kernel ABI breakage into all different projects, and it becomes untestable for all the poor software writers... -- 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] spi/omap2_mcspi: Verify TX reg is empty after TX only xfer with DMA
In case of TX only with DMA, the driver assumes that the data
has been transferred once DMA callback in invoked. However,
SPI's shift register may still contain data. Thus, the driver
is supposed to verify that the register is empty and the end of
the SPI transfer has been reached.
Signed-off-by: Ilkka Koskinen ilkka.koski...@nokia.com
Tested-by: Tuomas Katila ext-tuomas.2.kat...@nokia.com
---
drivers/spi/omap2_mcspi.c | 39 ++-
1 files changed, 26 insertions(+), 13 deletions(-)
diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
index b3a94ca..a2e053c 100644
--- a/drivers/spi/omap2_mcspi.c
+++ b/drivers/spi/omap2_mcspi.c
@@ -296,6 +296,19 @@ static int omap2_mcspi_enable_clocks(struct omap2_mcspi
*mcspi)
return 0;
}
+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)) {
+ if (time_after(jiffies, timeout))
+ return -1;
+ cpu_relax();
+ }
+ return 0;
+}
+
static unsigned
omap2_mcspi_txrx_dma(struct spi_device *spi, struct spi_transfer *xfer)
{
@@ -309,11 +322,14 @@ omap2_mcspi_txrx_dma(struct spi_device *spi, struct
spi_transfer *xfer)
u32 l;
u8 * rx;
const u8* tx;
+ void __iomem*chstat_reg;
mcspi = spi_master_get_devdata(spi-master);
mcspi_dma = mcspi-dma_channels[spi-chip_select];
l = mcspi_cached_chconf0(spi);
+ chstat_reg = cs-base + OMAP2_MCSPI_CHSTAT0;
+
count = xfer-len;
c = count;
word_len = cs-word_len;
@@ -382,6 +398,16 @@ omap2_mcspi_txrx_dma(struct spi_device *spi, struct
spi_transfer *xfer)
if (tx != NULL) {
wait_for_completion(mcspi_dma-dma_tx_completion);
dma_unmap_single(NULL, xfer-tx_dma, count, DMA_TO_DEVICE);
+
+ /* for TX_ONLY mode, be sure all words have shifted out */
+ if (rx == NULL) {
+ if (mcspi_wait_for_reg_bit(chstat_reg,
+ OMAP2_MCSPI_CHSTAT_TXS) 0)
+ dev_err(spi-dev, TXS timed out\n);
+ else if (mcspi_wait_for_reg_bit(chstat_reg,
+ OMAP2_MCSPI_CHSTAT_EOT) 0)
+ dev_err(spi-dev, EOT timed out\n);
+ }
}
if (rx != NULL) {
@@ -435,19 +461,6 @@ omap2_mcspi_txrx_dma(struct spi_device *spi, struct
spi_transfer *xfer)
return count;
}
-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)) {
- if (time_after(jiffies, timeout))
- return -1;
- cpu_relax();
- }
- return 0;
-}
-
static unsigned
omap2_mcspi_txrx_pio(struct spi_device *spi, struct spi_transfer *xfer)
{
--
1.6.0.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 3/3] drivers: cleanup Kconfig stuff
On Tue, Oct 19, 2010 at 2:52 PM, Felipe Balbi ba...@ti.com wrote: On Tue, Oct 19, 2010 at 06:36:32AM -0500, Felipe Contreras wrote: That is actually the intention. so it's a bit messed up one :-p Why? It makes configurations simpler. It's the other way around. He wanted to get rid of defconfigs completely by moving the complexity to Kconfigs: Yes, but he was suggesting to add things like Kconfig.rx51 and that would be selecting correct drivers to get rx51 working, he was definitely not suggesting to add sensible defaults all over the tree. There are two parts, one part is to fix the Kconfigs, and another was to come up with a way to replace the horrible defconfigs. Part two is mostly fixed thanks to 'make savedefconfig', since the defconfigs are not so horrible any more, but part one is a continued effort. For part two Linus had the idea to use Kconfigs instead of defconfigs, but they would mostly look very similar to the current ones generated by 'make savedefconfig'. I don't know what makes you think Linus didn't want part one to be done. He wanted the Kconfig.rx51 to be human readable, and you are proposing that TWL4030_USB should be manually added there... I don't think TWL4030_USB says anything to human beings. See the last link: --- It's often tedious for other cases too (I just want to enable a particular driver, what do I need to do so?) --- http://article.gmane.org/gmane.linux.kernel/994720 http://article.gmane.org/gmane.linux.kernel/994706 http://article.gmane.org/gmane.linux.kernel/994718 You seem to be pushing for the exact opposite; keep the complexity on the defconfigs and the burden on the user creating configs. no, you got me wrong. We do need to get rid of defconfigs, but we have to do so while keeping the resulting binary working and as of today, if you enable more than one transceiver driver, it won't work. Yes, but how do you get rid of the defconfig while also having a working USB_G_NOKIA? Somehow a transceiver should be automatically selected. Ok. But for now 'default y if ARCH_OMAP3' for TWL4030_USB doesn't hurt, nor increases the total size of Kconfigs, and solves a real problem. I don't see it that way. I see that there will be boards with one too many transceivers enabled and the resulting binary won't work, but I'll leave that for Greg to decide. That is no change from the current situation; you can still have two transceivers. My patch is not changing that. The issue you are pointing out is a separate one, and I can write a patch for that... basically: config NOP_USB_XCEIV depends !TWL4030_USB config TWL4030_USB depends !NOP_USB_XCEIV -- Felipe Contreras -- 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 3/3] drivers: cleanup Kconfig stuff
Hi Roger, On Tue, Oct 19, 2010 at 4:40 PM, Roger Quadros roger.quad...@nokia.com wrote: @@ -843,6 +841,7 @@ config USB_CDC_COMPOSITE config USB_G_NOKIA tristate Nokia composite gadget depends on PHONET + depends on USB_GADGET_MUSB_HDRC This is wrong. Is there a build problem or run-time problem without this? Try: CONFIG_USB_G_NOKIA=y CONFIG_USB_GADGET_MUSB_HDRC=n At least g_nokia doesn't seem to work correctly on my N900. -- Felipe Contreras -- 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
linux-next - multi-omap image fails to boot on omap3/4
Hi all, linux-next, as of 20101019, built with the omap2plus_defconfig fails to boot on omap3 and omap4. (I've disabled CONFIG_ARCH_OMAP2 or CONFIG_SWP_EMULATE to get the image to build). Building with only ARCH_OMAP3 allows the resultant image to boot up on OMAP3. Likewise, an image built with only ARCH_OMAP4 boots up on OMAP4 boards. earlyprintk does not provide any additional prints after Uncompressing Linux... done, booting the kernel. Any ideas where to look? - Anand -- 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 v2] omap4: pandaboard: fix up mmc card detect logic
From: Menon, Nishanth n...@ti.com
For MMC1 Controller, card detect interrupt source is
twl6030 which is non-gpio. The card detect call back function provides
card present/absent status by reading MMC Control register present
on twl6030. This functionality was introduced in mfd tree on
track to kernel.org
Sync pandaboard to the same and make mmc work.
Cc: Tony Lindgren t...@atomide.com
Cc: Madhusudhan Chikkature madhu...@ti.com
Cc: Adrian Hunter adrian.hun...@nokia.com
Cc: Samuel Ortiz sa...@linux.intel.com
Acked-by: Kishore Kadiyala kishore.kadiy...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
Tested-by: Jarkko Nikula jhnik...@gmail.com
Acked-by: Madhusudhan Chikkature madhu...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
v2: reposting to l-a, l-o
Depends on
http://git.kernel.org/?p=linux/kernel/git/sameo/mfd-2.6.git;a=commitdiff;h=1bf5197061a4aec99e9fd4f92d4a543310f83585;hp=0c9b33e5a23e2053165c9e303b3a3cf1b2b8
Discussion:
http://marc.info/?t=12871492137r=1w=2
arch/arm/mach-omap2/board-omap4panda.c | 15 ---
1 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 702f2a6..1ecd0a6 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -160,10 +160,19 @@ static int omap4_twl6030_hsmmc_late_init(struct device
*dev)
struct platform_device, dev);
struct omap_mmc_platform_data *pdata = dev-platform_data;
+ if (!pdata) {
+ dev_err(dev, %s: NULL platform data\n, __func__);
+ return -EINVAL;
+ }
/* Setting MMC1 Card detect Irq */
- if (pdev-id == 0)
- pdata-slots[0].card_detect_irq = TWL6030_IRQ_BASE +
- MMCDETECT_INTR_OFFSET;
+ if (pdev-id == 0) {
+ ret = twl6030_mmc_card_detect_config();
+if (ret)
+ dev_err(dev, %s: Error card detect config(%d)\n,
+ __func__, ret);
+else
+ pdata-slots[0].card_detect = twl6030_mmc_card_detect;
+ }
return ret;
}
--
1.6.3.3
--
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] omap4: pandaboard: fix up mmc card detect logic
Hi Nishanth, On Tue, Oct 19, 2010 at 09:50:25AM -0500, Nishanth Menon wrote: From: Menon, Nishanth n...@ti.com For MMC1 Controller, card detect interrupt source is twl6030 which is non-gpio. The card detect call back function provides card present/absent status by reading MMC Control register present on twl6030. This functionality was introduced in mfd tree on track to kernel.org Sync pandaboard to the same and make mmc work. Cc: Tony Lindgren t...@atomide.com Cc: Madhusudhan Chikkature madhu...@ti.com Cc: Adrian Hunter adrian.hun...@nokia.com Cc: Samuel Ortiz sa...@linux.intel.com Acked-by: Kishore Kadiyala kishore.kadiy...@ti.com Signed-off-by: Nishanth Menon n...@ti.com Tested-by: Jarkko Nikula jhnik...@gmail.com Acked-by: Madhusudhan Chikkature madhu...@ti.com Acked-by: Tony Lindgren t...@atomide.com Patch applied, thanks a lot. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- 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 3/3] drivers: cleanup Kconfig stuff
Hi, (already at home so using personal email) On Tue, 19 Oct 2010 17:32:07 +0300, Felipe Contreras felipe.contre...@gmail.com wrote: There are two parts, one part is to fix the Kconfigs, and another was to come up with a way to replace the horrible defconfigs. Part two is mostly fixed thanks to 'make savedefconfig', since the defconfigs are not so horrible any more, but part one is a continued effort. For part two Linus had the idea to use Kconfigs instead of defconfigs, but they would mostly look very similar to the current ones generated by 'make savedefconfig'. I don't know what makes you think Linus didn't want part one to be done. He wanted the Kconfig.rx51 to be human readable, and you are proposing that TWL4030_USB should be manually added there... I don't think TWL4030_USB says anything to human beings. I don't read anywhere Linus saying we should clutter drivers/*/Kconfig with defaults. I think you're inverting things, it's much better to select TWL4030_USB when you enable MACH_OMAP_RX51 then default y if MACH_OMAP_RX51. Yes, but how do you get rid of the defconfig while also having a working USB_G_NOKIA? Somehow a transceiver should be automatically selected. and you do that selection when the board is enabled otherwise the drivers Kconfig will be cluttered with default Y if blabla. But like I said before, it's Greg's ball. Personally, I think you're taking the wrong approach. -- balbi -- 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/3] drivers: misc: add omap_hwspinlock driver
On Mon, Oct 18, 2010 at 09:44:33AM +0200, Ohad Ben-Cohen wrote:
+#else /* !CONFIG_OMAP_HWSPINLOCK */
+
+static inline struct omap_hwspinlock *omap_hwspinlock_request(void)
+{
+ return ERR_PTR(-ENOSYS);
+}
One note, do you really want to fail if this option isn't built into the
kernel, yet you have a driver that is asking for it? Shouldn't you
instead just silently succeed, and let the code path get compiled away?
We did that for debugfs, after learning the pain that procfs had with
its api for is not built. Doing it the way you are requires the user
to always test for -ENOSYS, when in reality, if that is returned,
there's nothing the driver can do about it, so it should just not worry
about it.
Just something to think about.
thanks,
greg k-h
--
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 3/3] drivers: cleanup Kconfig stuff
On Tue, Oct 19, 2010 at 01:03:28PM +0300, Felipe Contreras wrote: Add missing dependencies, and remove redundant ones, and select sensible defaults. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- drivers/mfd/Kconfig|3 ++- drivers/regulator/Kconfig |1 + drivers/usb/gadget/Kconfig |3 +-- drivers/usb/musb/Kconfig |6 ++ drivers/usb/otg/Kconfig|2 ++ 5 files changed, 8 insertions(+), 7 deletions(-) diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index db51ea1..0bbaf01 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -156,6 +156,7 @@ config MENELAUS config TWL4030_CORE bool Texas Instruments TWL4030/TWL5030/TWL6030/TPS659x0 Support depends on I2C=y GENERIC_HARDIRQS + default y if ARCH_OMAP3 || ARCH_OMAP4 Sorry, but unless the driver is somehow required to keep the board from going up in a puff of smoke, a default should NEVER be y. Because of that, I can't take this patch. greg k-h -- 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 2/3] usb: trivial Kconfig cleanups
On Tue, Oct 19, 2010 at 01:03:27PM +0300, Felipe Contreras wrote: Note: USB_GADGET_MUSB_HDRC is already defined in usb/gadget. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com Please describe _what_ trivial cleanups you did, and why you did them. Care to resend? thanks, greg k-h -- 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 1/3] usb: fix Kconfig warning
On Tue, Oct 19, 2010 at 01:28:09PM +0300, Felipe Balbi wrote: On Tue, Oct 19, 2010 at 05:03:26AM -0500, Felipe Contreras wrote: warning: (USB_MUSB_HDRC_HCD USB_SUPPORT USB_MUSB_HDRC (USB_MUSB_HOST || USB_MUSB_OTG) USB_GADGET_MUSB_HDRC || USB_MUSB_OTG choice USB USB_GADGET PM EXPERIMENTAL) selects USB_OTG which has unmet direct dependencies (USB_GADGET_OMAP ARCH_OMAP_OTG USB_OHCI_HCD) This doesn't seem to happen on 2.6.36-rc8, but still doesn't make sense to keep this duplicated config that is already defined in usb/core. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com Since this is related to MUSB, Greg to do you want me to queue for -rc0 cycle and re-send for you ? If you ack this patch, I'll be glad to take it as-is. thanks, greg k-h -- 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 3/3] drivers: cleanup Kconfig stuff
On 10/19/2010 9:22 PM, Greg KH wrote: On Tue, Oct 19, 2010 at 01:03:28PM +0300, Felipe Contreras wrote: Add missing dependencies, and remove redundant ones, and select sensible defaults. Signed-off-by: Felipe Contrerasfelipe.contre...@gmail.com --- drivers/mfd/Kconfig|3 ++- drivers/regulator/Kconfig |1 + drivers/usb/gadget/Kconfig |3 +-- drivers/usb/musb/Kconfig |6 ++ drivers/usb/otg/Kconfig|2 ++ 5 files changed, 8 insertions(+), 7 deletions(-) diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index db51ea1..0bbaf01 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -156,6 +156,7 @@ config MENELAUS config TWL4030_CORE bool Texas Instruments TWL4030/TWL5030/TWL6030/TPS659x0 Support depends on I2C=y GENERIC_HARDIRQS + default y if ARCH_OMAP3 || ARCH_OMAP4 Sorry, but unless the driver is somehow required to keep the board from going up in a puff of smoke, a default should NEVER be y. Because of that, I can't take this patch. This is the driver for the Power-management IC on the board. Without this IC being correctly configured, I'm guessing a lot of things will fail. Not so sure if anything will go up in smoke (sounds unlikely), or if the kernel will fail to boot - I'll check quickly - but for this one specific instance, I think it's reasonable to accept a default y. Kevin/Tony can probably confirm. Greg, For other instances of unnecessary default y, do you think they should be removed? - Anand -- 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 3/3] drivers: cleanup Kconfig stuff
On Tue, Oct 19, 2010 at 09:42:17PM +0530, Anand Gadiyar wrote: On 10/19/2010 9:22 PM, Greg KH wrote: On Tue, Oct 19, 2010 at 01:03:28PM +0300, Felipe Contreras wrote: Add missing dependencies, and remove redundant ones, and select sensible defaults. Signed-off-by: Felipe Contrerasfelipe.contre...@gmail.com --- drivers/mfd/Kconfig|3 ++- drivers/regulator/Kconfig |1 + drivers/usb/gadget/Kconfig |3 +-- drivers/usb/musb/Kconfig |6 ++ drivers/usb/otg/Kconfig|2 ++ 5 files changed, 8 insertions(+), 7 deletions(-) diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index db51ea1..0bbaf01 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -156,6 +156,7 @@ config MENELAUS config TWL4030_CORE bool Texas Instruments TWL4030/TWL5030/TWL6030/TPS659x0 Support depends on I2C=y GENERIC_HARDIRQS + default y if ARCH_OMAP3 || ARCH_OMAP4 Sorry, but unless the driver is somehow required to keep the board from going up in a puff of smoke, a default should NEVER be y. Because of that, I can't take this patch. This is the driver for the Power-management IC on the board. Without this IC being correctly configured, I'm guessing a lot of things will fail. Not so sure if anything will go up in smoke (sounds unlikely), or if the kernel will fail to boot - I'll check quickly - but for this one specific instance, I think it's reasonable to accept a default y. Sorry, but no, I'm not going to take it for the reasons stated above. Kevin/Tony can probably confirm. Greg, For other instances of unnecessary default y, do you think they should be removed? I wouldn't worry about trivial things like that, the damage is already done. thanks, greg k-h -- 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/3] drivers: misc: add omap_hwspinlock driver
Ohad Ben-Cohen o...@wizery.com writes:
From: Simon Que s...@ti.com
Add driver for OMAP's Hardware Spinlock module.
The OMAP Hardware Spinlock module, initially introduced in OMAP4,
provides hardware assistance for synchronization between the
multiple processors in the device (Cortex-A9, Cortex-M3 and
C64x+ DSP).
[...]
+/**
+ * omap_hwspin_trylock() - attempt to lock a specific hwspinlock
+ * @hwlock: a hwspinlock which we want to trylock
+ * @flags: a pointer to where the caller's interrupt state will be saved at
+ *
+ * This function attempt to lock the underlying hwspinlock. Unlike
+ * hwspinlock_lock, this function will immediately fail if the hwspinlock
+ * is already taken.
+ *
+ * Upon a successful return from this function, preemption and interrupts
+ * are disabled, so the caller must not sleep, and is advised to release
+ * the hwspinlock as soon as possible. This is required in order to minimize
+ * remote cores polling on the hardware interconnect.
+ *
+ * This function can be called from any context.
+ *
+ * Returns 0 if we successfully locked the hwspinlock, -EBUSY if
+ * the hwspinlock was already taken, and -EINVAL if @hwlock is invalid.
+ */
+int omap_hwspin_trylock(struct omap_hwspinlock *hwlock, unsigned long *flags)
+{
+ u32 ret;
+
+ if (IS_ERR_OR_NULL(hwlock)) {
+ pr_err(invalid hwlock\n);
+ return -EINVAL;
+ }
+
+ /*
+ * This spin_trylock_irqsave serves two purposes:
+
+ * 1. Disable local interrupts and preemption, in order to
+ *minimize the period of time in which the hwspinlock
+ *is taken (so caller will not preempted). This is
+ *important in order to minimize the possible polling on
+ *the hardware interconnect by a remote user of this lock.
+ *
+ * 2. Make this hwspinlock primitive SMP-safe (so we can try to
+ *take it from additional contexts on the local cpu)
+ */
3. Ensures that in_atomic/might_sleep checks catch potential problems
with hwspinlock usage (e.g. scheduler checks like 'scheduling while
atomic' etc.)
+ if (!spin_trylock_irqsave(hwlock-lock, *flags))
+ return -EBUSY;
+
+ /* attempt to acquire the lock by reading its value */
+ ret = readl(hwlock-addr);
+
+ /* lock is already taken */
+ if (ret == SPINLOCK_TAKEN) {
+ spin_unlock_irqrestore(hwlock-lock, *flags);
+ return -EBUSY;
+ }
+
+ /*
+ * We can be sure the other core's memory operations
+ * are observable to us only _after_ we successfully take
+ * the hwspinlock, so we must make sure that subsequent memory
+ * operations will not be reordered before we actually took the
+ * hwspinlock.
+ * Note: the implicit memory barrier of the spinlock above is too
+ * early, so we need this additional explicit memory barrier.
+ */
+ mb();
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(omap_hwspin_trylock);
[...]
+/**
+ * omap_hwspinlock_unlock() - unlock a specific hwspinlock
minor nit: s/lock_unlock/_unlock/ to match name below
+ * @hwlock: a previously-acquired hwspinlock which we want to unlock
+ * @flags: a pointer to the caller's saved interrupts state
+ *
+ * This function will unlock a specific hwspinlock, enable preemption and
+ * restore the interrupts state. @hwlock must be taken (by us!) before
+ * calling this function: it is a bug to call unlock on a @hwlock that was
+ * not taken by us, i.e. using one of omap_hwspin_{lock trylock,
lock_timeout}.
+ *
+ * This function can be called from any context.
+ *
+ * Returns 0 when the @hwlock on success, or -EINVAL if @hwlock is invalid.
+ */
+int omap_hwspin_unlock(struct omap_hwspinlock *hwlock, unsigned long *flags)
+{
+ if (IS_ERR_OR_NULL(hwlock)) {
+ pr_err(invalid hwlock\n);
+ return -EINVAL;
+ }
+
+ /*
+ * We must make sure that memory operations, done before unlocking
+ * the hwspinlock, will not be reordered after the lock is released.
+ * The memory barrier induced by the spin_unlock below is too late:
+ * the other core is going to access memory soon after it will take
+ * the hwspinlock, and by then we want to be sure our memory operations
+ * were already observable.
+ */
+ mb();
+
+ /* release the lock by writing 0 to it (NOTTAKEN) */
+ writel(SPINLOCK_NOTTAKEN, hwlock-addr);
+
+ /* undo the spin_trylock_irqsave called in the locking function */
+ spin_unlock_irqrestore(hwlock-lock, *flags);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(omap_hwspin_unlock);
[...]
Kevin
--
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/3] drivers: misc: add omap_hwspinlock driver
On Mon, Oct 18, 2010 at 1:44 AM, Ohad Ben-Cohen o...@wizery.com wrote: From: Simon Que s...@ti.com Add driver for OMAP's Hardware Spinlock module. The OMAP Hardware Spinlock module, initially introduced in OMAP4, provides hardware assistance for synchronization between the multiple processors in the device (Cortex-A9, Cortex-M3 and C64x+ DSP). Hi Ohad, A couple of comments below. Signed-off-by: Simon Que s...@ti.com Signed-off-by: Hari Kanigeri h-kanige...@ti.com Signed-off-by: Krishnamoorthy, Balaji T balaj...@ti.com [o...@wizery.com: disable interrupts/preemption to prevent hw abuse] [o...@wizery.com: add memory barriers to prevent memory reordering issues] [o...@wizery.com: relax omap interconnect between subsequent lock attempts] [o...@wizery.com: timeout param to use jiffies instead of number of attempts] [o...@wizery.com: remove code duplication in lock, trylock, lock_timeout] [o...@wizery.com: runtime pm usage count to reflect num of requested locks] [o...@wizery.com: move to drivers/misc, general cleanups, document] Signed-off-by: Ohad Ben-Cohen o...@wizery.com Cc: Benoit Cousson b-cous...@ti.com Cc: Tony Lindgren t...@atomide.com --- Documentation/misc-devices/omap_hwspinlock.txt | 199 + drivers/misc/Kconfig | 10 + drivers/misc/Makefile | 1 + drivers/misc/omap_hwspinlock.c | 555 include/linux/omap_hwspinlock.h | 108 + 5 files changed, 873 insertions(+), 0 deletions(-) create mode 100644 Documentation/misc-devices/omap_hwspinlock.txt create mode 100644 drivers/misc/omap_hwspinlock.c create mode 100644 include/linux/omap_hwspinlock.h diff --git a/Documentation/misc-devices/omap_hwspinlock.txt b/Documentation/misc-devices/omap_hwspinlock.txt new file mode 100644 index 000..b093347 --- /dev/null +++ b/Documentation/misc-devices/omap_hwspinlock.txt @@ -0,0 +1,199 @@ +OMAP Hardware Spinlocks + +1. Introduction + +Hardware spinlock modules provide hardware assistance for synchronization +and mutual exclusion between heterogeneous processors and those not operating +under a single, shared operating system. + +For example, OMAP4 has dual Cortex-A9, dual Cortex-M3 and a C64x+ DSP, +each of which is running a different Operating System (the master, A9, +is usually running Linux and the slave processors, the M3 and the DSP, +are running some flavor of RTOS). + +A hwspinlock driver allows kernel code to access data structures (or hardware +resources) that are shared with any of the existing remote processors, with +which there is no alternative mechanism to accomplish synchronization and +mutual exclusion operations. + +This is necessary, for example, for Inter-processor communications: +on OMAP4, cpu-intensive multimedia tasks are offloaded by the host to the +remote M3 and/or C64x+ slave processors (by an IPC subsystem called Syslink). + +To achieve fast message-based communications, a minimal kernel support +is needed to deliver messages arriving from a remote processor to the +appropriate user process. + +This communication is based on simple data structures that are shared between +the remote processors, and access to them is synchronized using the hwspinlock +module (remote processor directly places new messages in this shared data +structure). + +2. User API + + struct omap_hwspinlock *omap_hwspinlock_request(void); + - dynamically assign an hwspinlock and return its address, or + ERR_PTR(-EBUSY) if an unused hwspinlock isn't available. Users of this + API will usually want to communicate the lock's id to the remote core + before it can be used to achieve synchronization (to get the id of the + lock, use omap_hwspinlock_get_id()). + Can be called from an atomic context (this function will not sleep) but + not from within interrupt context. I strongly recommend reconsidering the ERR_PTR() pattern in new driver code. It is impossible to tell from looking at the prototype of a function if it returns an ERR_PTR() value, or a NULL on failure. I pretty much guarantee that new users of this code will miss the subtlety and introduce new bugs by assuming that the return value can be tested with if (!hwlock). ERR_PTR() is only appropriate when the caller actually cares about the failure code and has different behaviour depending on the result. For example, filesystem code that needs to return to userspace a specific error code. Very seldom does driver code like users of this API actually care. Using it is just asking for bugs with no benefit. + struct omap_hwspinlock *omap_hwspinlock_request_specific(unsigned int id); + - assign a specific hwspinlock id and return its address, or + ERR_PTR(-EBUSY) if that hwspinlock is already in use. Usually board code + will be calling this function in order to reserve specific hwspinlock + ids for
Re: [PATCH 3/3] omap: add hwspinlock device
On Tue, Oct 19, 2010 at 11:03 AM, Kevin Hilman
khil...@deeprootsystems.com wrote:
Ohad Ben-Cohen o...@wizery.com writes:
From: Simon Que s...@ti.com
Build and register an hwspinlock platform device.
Although only OMAP4 supports the hardware spinlock module (for now),
it is still safe to run this initcall on all omaps, because hwmod lookup
will simply fail on hwspinlock-less platforms.
Signed-off-by: Simon Que s...@ti.com
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Cc: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/Makefile | 1 +
arch/arm/mach-omap2/hwspinlock.c | 67
++
2 files changed, 68 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/hwspinlock.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 7352412..e55d1c5 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -190,3 +190,4 @@ obj-y += $(smc91x-m)
$(smc91x-y)
smsc911x-$(CONFIG_SMSC911X) := gpmc-smsc911x.o
obj-y += $(smsc911x-m) $(smsc911x-y)
+obj-$(CONFIG_ARCH_OMAP4) += hwspinlock.o
diff --git a/arch/arm/mach-omap2/hwspinlock.c
b/arch/arm/mach-omap2/hwspinlock.c
new file mode 100644
index 000..641a6d4
--- /dev/null
+++ b/arch/arm/mach-omap2/hwspinlock.c
@@ -0,0 +1,67 @@
+/*
+ * OMAP hardware spinlock device initialization
+ *
+ * Copyright (C) 2010 Texas Instruments. All rights reserved.
+ *
+ * Contact: Simon Que s...@ti.com
+ * Hari Kanigeri h-kanige...@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.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/err.h
+
+#include plat/omap_hwmod.h
+#include plat/omap_device.h
+
+struct omap_device_pm_latency omap_spinlock_latency[] = {
+ {
+ .deactivate_func = omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+ }
+};
+
+int __init hwspinlocks_init(void)
+{
+ int retval = 0;
+ struct omap_hwmod *oh;
+ struct omap_device *od;
+ const char *oh_name = spinlock;
+ const char *dev_name = omap_hwspinlock;
+
+ /*
+ * Hwmod lookup will fail in case our platform doesn't support the
+ * hardware spinlock module, so it is safe to run this initcall
+ * on all omaps
+ */
+ oh = omap_hwmod_lookup(oh_name);
+ if (oh == NULL)
+ return -EINVAL;
+
+ od = omap_device_build(dev_name, 0, oh, NULL, 0,
+ omap_spinlock_latency,
+ ARRAY_SIZE(omap_spinlock_latency), false);
+ if (IS_ERR(od)) {
+ pr_err(Can't build omap_device for %s:%s\n, dev_name,
+ oh_name);
+ retval = PTR_ERR(od);
+ }
+
+ return retval;
+}
+postcore_initcall(hwspinlocks_init);
Any reason this needs to be a postcore_initcall? Are there users of
hwspinlocks this early in boot? Probaly subsys or even device_initcall
is more appropriate here.
I would've suspected that any users of hwspinlocks will be dependent on
drivers for the other cores (e.g. syslink) which would likely be
initialized much later.
On that note, is there any reason why this file cannot be selected as a module?
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
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 3/3] omap: add hwspinlock device
Ohad Ben-Cohen o...@wizery.com writes:
From: Simon Que s...@ti.com
Build and register an hwspinlock platform device.
Although only OMAP4 supports the hardware spinlock module (for now),
it is still safe to run this initcall on all omaps, because hwmod lookup
will simply fail on hwspinlock-less platforms.
Signed-off-by: Simon Que s...@ti.com
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Cc: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/hwspinlock.c | 67
++
2 files changed, 68 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/hwspinlock.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 7352412..e55d1c5 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -190,3 +190,4 @@ obj-y += $(smc91x-m)
$(smc91x-y)
smsc911x-$(CONFIG_SMSC911X) := gpmc-smsc911x.o
obj-y+= $(smsc911x-m) $(smsc911x-y)
+obj-$(CONFIG_ARCH_OMAP4) += hwspinlock.o
diff --git a/arch/arm/mach-omap2/hwspinlock.c
b/arch/arm/mach-omap2/hwspinlock.c
new file mode 100644
index 000..641a6d4
--- /dev/null
+++ b/arch/arm/mach-omap2/hwspinlock.c
@@ -0,0 +1,67 @@
+/*
+ * OMAP hardware spinlock device initialization
+ *
+ * Copyright (C) 2010 Texas Instruments. All rights reserved.
+ *
+ * Contact: Simon Que s...@ti.com
+ * Hari Kanigeri h-kanige...@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.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/err.h
+
+#include plat/omap_hwmod.h
+#include plat/omap_device.h
+
+struct omap_device_pm_latency omap_spinlock_latency[] = {
+ {
+ .deactivate_func = omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+ }
+};
+
+int __init hwspinlocks_init(void)
+{
+ int retval = 0;
+ struct omap_hwmod *oh;
+ struct omap_device *od;
+ const char *oh_name = spinlock;
+ const char *dev_name = omap_hwspinlock;
+
+ /*
+ * Hwmod lookup will fail in case our platform doesn't support the
+ * hardware spinlock module, so it is safe to run this initcall
+ * on all omaps
+ */
+ oh = omap_hwmod_lookup(oh_name);
+ if (oh == NULL)
+ return -EINVAL;
+
+ od = omap_device_build(dev_name, 0, oh, NULL, 0,
+ omap_spinlock_latency,
+ ARRAY_SIZE(omap_spinlock_latency), false);
+ if (IS_ERR(od)) {
+ pr_err(Can't build omap_device for %s:%s\n, dev_name,
+ oh_name);
+ retval = PTR_ERR(od);
+ }
+
+ return retval;
+}
+postcore_initcall(hwspinlocks_init);
Any reason this needs to be a postcore_initcall? Are there users of
hwspinlocks this early in boot? Probaly subsys or even device_initcall
is more appropriate here.
I would've suspected that any users of hwspinlocks will be dependent on
drivers for the other cores (e.g. syslink) which would likely be
initialized much later.
Kevin
--
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 2/3] usb: trivial Kconfig cleanups
On Tue, Oct 19, 2010 at 6:51 PM, Greg KH g...@kroah.com wrote: On Tue, Oct 19, 2010 at 01:03:27PM +0300, Felipe Contreras wrote: Note: USB_GADGET_MUSB_HDRC is already defined in usb/gadget. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com Please describe _what_ trivial cleanups you did, and why you did them. Care to resend? How about: Shuffle the code a bit so the description is at the top, remove duplicated configs (USB_GADGET_MUSB_HDRC), 'default n' is redundant, and USB_GADGET_SELECTED should go after USB_GADGET (on the appropriate config). -- Felipe Contreras -- 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/3] drivers: misc: add omap_hwspinlock driver
Ohad Ben-Cohen o...@wizery.com writes: From: Simon Que s...@ti.com Add driver for OMAP's Hardware Spinlock module. The OMAP Hardware Spinlock module, initially introduced in OMAP4, provides hardware assistance for synchronization between the multiple processors in the device (Cortex-A9, Cortex-M3 and C64x+ DSP). [...] diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index b743312..ce4b7a6 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -390,6 +390,16 @@ config BMP085 To compile this driver as a module, choose M here: the module will be called bmp085. +config OMAP_HWSPINLOCK + bool OMAP Hardware Spinlock module Should be tristate so it can also be built as a module by default. e.g., when building multi-OMAP kernels, no reason or this to be built-in. It can then be loaded as a module on OMAP4 only. Kevin -- 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/3] drivers: misc: add omap_hwspinlock driver
On Monday 18 October 2010 09:44:33 Ohad Ben-Cohen wrote: + int omap_hwspin_lock(struct omap_hwspinlock *hwlock, unsigned long *flags); ... + The flags parameter is a pointer to where the interrupts state of the + caller will be saved at. This seems to encourage sloppy coding: The only variant you allow is the one that corresponds to Linux's spin_lock_irqsave(), which is generally discouraged in all places where you know if you need to disable interrupts or not. IMHO the default should be a version that only allows locks that don't get taken at IRQ time and consequently don't require saving the interrupt flags. Arnd -- 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 2/3] usb: trivial Kconfig cleanups
On Tue, Oct 19, 2010 at 08:15:19PM +0300, Felipe Contreras wrote: On Tue, Oct 19, 2010 at 6:51 PM, Greg KH g...@kroah.com wrote: On Tue, Oct 19, 2010 at 01:03:27PM +0300, Felipe Contreras wrote: Note: USB_GADGET_MUSB_HDRC is already defined in usb/gadget. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com Please describe _what_ trivial cleanups you did, and why you did them. Care to resend? How about: Shuffle the code a bit so the description is at the top, remove duplicated configs (USB_GADGET_MUSB_HDRC), 'default n' is redundant, and USB_GADGET_SELECTED should go after USB_GADGET (on the appropriate config). Sounds good, but you need to resend it with this information in it, not much I can do with it in an independant email. thanks, greg k-h -- 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 2/3] usb: trivial Kconfig cleanups
On Tue, Oct 19, 2010 at 8:50 PM, Greg KH g...@kroah.com wrote: On Tue, Oct 19, 2010 at 08:15:19PM +0300, Felipe Contreras wrote: On Tue, Oct 19, 2010 at 6:51 PM, Greg KH g...@kroah.com wrote: On Tue, Oct 19, 2010 at 01:03:27PM +0300, Felipe Contreras wrote: Note: USB_GADGET_MUSB_HDRC is already defined in usb/gadget. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com Please describe _what_ trivial cleanups you did, and why you did them. Care to resend? How about: Shuffle the code a bit so the description is at the top, remove duplicated configs (USB_GADGET_MUSB_HDRC), 'default n' is redundant, and USB_GADGET_SELECTED should go after USB_GADGET (on the appropriate config). Sounds good, but you need to resend it with this information in it, not much I can do with it in an independant email. I know that, I just wanted to see if it was ok before resending so I don't resend another time. -- Felipe Contreras -- 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: linux-next - multi-omap image fails to boot on omap3/4
* Anand Gadiyar gadi...@ti.com [101019 07:41]: Hi all, linux-next, as of 20101019, built with the omap2plus_defconfig fails to boot on omap3 and omap4. (I've disabled CONFIG_ARCH_OMAP2 or CONFIG_SWP_EMULATE to get the image to build). Building with only ARCH_OMAP3 allows the resultant image to boot up on OMAP3. Likewise, an image built with only ARCH_OMAP4 boots up on OMAP4 boards. earlyprintk does not provide any additional prints after Uncompressing Linux... done, booting the kernel. Any ideas where to look? Hmm I did a quick test merge of linux-omap master and rmk/devel branches and that boots just fine. So it's probably something that already got fixed in rmk/devel but is not yet in next, or something that came from elsewhere, or something that we have in omap-testing branch that's not in for-next for some reason. 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: linux-next: omap2plus_defconfig does not build
On Tue, Oct 19, 2010 at 10:45 PM, Tony Lindgren t...@atomide.com wrote: * Anand Gadiyar gadi...@ti.com [101013 06:14]: Building omap2plus_defconfig (which enables support for OMAP2420/2430/OMAP3 and OMAP4 in one image), I get the following build error. CC arch/arm/kernel/swp_emulate.o /tmp/ccg979qz.s: Assembler messages: /tmp/ccg979qz.s:343: Error: selected processor does not support ARM mode `ldrexb r6,[r5]' /tmp/ccg979qz.s:344: Error: selected processor does not support ARM mode `strexb r1,r3,[r5]' make[1]: *** [arch/arm/kernel/swp_emulate.o] Error 1 make: *** [arch/arm/kernel] Error 2 I'm using CodeSourcery's 2010q1-202 toolchain based on gcc 4.4.1. I haven't been following the lists closely the last few days, so I'm not sure if this is a known issue. Just reporting it for now. This seems to be related to ARM: Add SWP/SWPB emulation for ARMv7 processors (v5) where SWP_EMULATE is selected by default. For the omap2plus_defconfig in for-next we now have CPU_V6 and CPU_V7 set with SMP and SMP_ON_UP. I had forgotten I'd reported this earlier. I reported the build break again today, and Catalin provided this patch [1] which solves the build issue. - Anand [1] http://marc.info/?t=12874841253r=1w=2 -- 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: linux-next - multi-omap image fails to boot on omap3/4
On Tue, Oct 19, 2010 at 11:51 PM, Tony Lindgren t...@atomide.com wrote: * Anand Gadiyar gadi...@ti.com [101019 07:41]: Hi all, linux-next, as of 20101019, built with the omap2plus_defconfig fails to boot on omap3 and omap4. (I've disabled CONFIG_ARCH_OMAP2 or CONFIG_SWP_EMULATE to get the image to build). Building with only ARCH_OMAP3 allows the resultant image to boot up on OMAP3. Likewise, an image built with only ARCH_OMAP4 boots up on OMAP4 boards. earlyprintk does not provide any additional prints after Uncompressing Linux... done, booting the kernel. Any ideas where to look? Hmm I did a quick test merge of linux-omap master and rmk/devel branches and that boots just fine. So it's probably something that already got fixed in rmk/devel but is not yet in next, or something that came from elsewhere, or something that we have in omap-testing branch that's not in for-next for some reason. I tried bisecting linux-next between v2.6.36-rc8 and HEAD, but there's a commit in between that breaks the build. I'll take another stab at this in a while. - Anand -- 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
External SD card on nokia n810.
2nd slot was fixed by the commit 214044b. I just tried and both internal mmc and external microSD (=uSD) are working on current l-o head 8b4b015. FYI: here is some info how to get access to N810 serial port pins. Makes debugging much easier :-) http://bu3sch.de/joomla/index.php/nokia-n810-serial-console Thanks! It works =) -- Best regards, Maksim A. Boyko -- Best regards, Maksim A. Boyko -- 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/3] drivers: misc: add omap_hwspinlock driver
On Tue, Oct 19, 2010 at 5:46 PM, Greg KH g...@kroah.com wrote:
On Mon, Oct 18, 2010 at 09:44:33AM +0200, Ohad Ben-Cohen wrote:
+#else /* !CONFIG_OMAP_HWSPINLOCK */
+
+static inline struct omap_hwspinlock *omap_hwspinlock_request(void)
+{
+ return ERR_PTR(-ENOSYS);
+}
One note, do you really want to fail if this option isn't built into the
kernel, yet you have a driver that is asking for it? Shouldn't you
instead just silently succeed, and let the code path get compiled away?
We did that for debugfs, after learning the pain that procfs had with
its api for is not built. Doing it the way you are requires the user
to always test for -ENOSYS, when in reality, if that is returned,
there's nothing the driver can do about it, so it should just not worry
about it.
Just something to think about.
Completely agree; if hwspinlock support is not needed, we better let
its users run uninterruptedly. I'll change it.
Thanks,
Ohad.
thanks,
greg k-h
--
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/3] drivers: misc: add omap_hwspinlock driver
On Tue, Oct 19, 2010 at 6:58 PM, Kevin Hilman khil...@deeprootsystems.com wrote: + * This spin_trylock_irqsave serves two purposes: + + * 1. Disable local interrupts and preemption, in order to + * minimize the period of time in which the hwspinlock + * is taken (so caller will not preempted). This is + * important in order to minimize the possible polling on + * the hardware interconnect by a remote user of this lock. + * + * 2. Make this hwspinlock primitive SMP-safe (so we can try to + * take it from additional contexts on the local cpu) + */ 3. Ensures that in_atomic/might_sleep checks catch potential problems with hwspinlock usage (e.g. scheduler checks like 'scheduling while atomic' etc.) Nice one. Added. +/** + * omap_hwspinlock_unlock() - unlock a specific hwspinlock minor nit: s/lock_unlock/_unlock/ to match name below Thanks. -- 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/9] arch: arm: fixed typos
On Mon, 18 Oct 2010, Uwe Kleine-König wrote: On Sat, Oct 16, 2010 at 11:00:05AM +0200, Andrea Gelmini wrote: Intialize, configuation, wakup, Managment, addres I already fixed some of these in http://thread.gmane.org/gmane.linux.kernel/1030436/ Don't know why they didn't appear in the trivial tree yet. Ah, now I see your patchset you sent me way back. It somehow slipped through cracks, sorry. Could you please refresh it (and probably incorporate Andrea's changes as well) and resend it to me? Thanks, -- Jiri Kosina SUSE Labs, Novell Inc. -- 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/3] drivers: misc: add omap_hwspinlock driver
On Tue, Oct 19, 2010 at 7:01 PM, Grant Likely grant.lik...@secretlab.ca wrote: + struct omap_hwspinlock *omap_hwspinlock_request(void); ... ERR_PTR() is only appropriate when the caller actually cares about the failure code and has different behaviour depending on the result. Agree; the hwspinlock users can surely live without an explicit error code from the _request APIs, and some extra robustness can only do good. I'll remove it. Disabling irqs *might* be a concern as a source of RT latency. It might be better to make the caller responsible for managing local spin locks and irq disable/enable. This a coming from an hardware requirement, rather than a choice the user should take. If a hwspinlock is taken over a long period of time, its other user (with which we try to achieve synchronization) might be polling the OMAP interconnect for too long (trying to take the hwspinlock) and thus preventing it to be used for other transactions. To prevent such lengthy polling on the interconnect, the hwspinlock should only be used for very short period of times, with preemption and interrupts disabled. That's why we don't give users the choice whether to disable interrupts or not - it's simply not a decision they should take. Thanks, Ohad. -- 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/3] drivers: misc: add omap_hwspinlock driver
On Tue, Oct 19, 2010 at 7:21 PM, Arnd Bergmann a...@arndb.de wrote:
On Monday 18 October 2010 09:44:33 Ohad Ben-Cohen wrote:
+ int omap_hwspin_lock(struct omap_hwspinlock *hwlock, unsigned long
*flags);
...
+ The flags parameter is a pointer to where the interrupts state of the
+ caller will be saved at.
This seems to encourage sloppy coding: The only variant you allow is the one
that corresponds to Linux's spin_lock_irqsave()
Yes, this is a hardware requirement to minimize the period of time in
which the hwspinlock is taken, in order to prevent lengthy polling on
the interconnect (preventing it from serving other transactions).
, which is generally discouraged
in all places where you know if you need to disable interrupts or not.
IMHO the default should be a version that only allows locks that don't get
taken at IRQ time and consequently don't require saving the interrupt flags.
Please note that the hwspinlocks should never be used to achieve
synchronization with Linux contexts running on the same cpu - it's
always about achieving mutual exclusion with a remote processor.
So whether the lock is taken at IRQ time or not does not affect the
requirement to disable interrupts while it is taken (very differently
from local spin_lock{_irqsave} synchronizations).
Thanks,
Ohad.
Arnd
--
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 3/3] drivers: cleanup Kconfig stuff
On Tue, Oct 19, 2010 at 6:05 PM, Felipe Balbi m...@felipebalbi.com wrote: On Tue, 19 Oct 2010 17:32:07 +0300, Felipe Contreras felipe.contre...@gmail.com wrote: There are two parts, one part is to fix the Kconfigs, and another was to come up with a way to replace the horrible defconfigs. Part two is mostly fixed thanks to 'make savedefconfig', since the defconfigs are not so horrible any more, but part one is a continued effort. For part two Linus had the idea to use Kconfigs instead of defconfigs, but they would mostly look very similar to the current ones generated by 'make savedefconfig'. I don't know what makes you think Linus didn't want part one to be done. He wanted the Kconfig.rx51 to be human readable, and you are proposing that TWL4030_USB should be manually added there... I don't think TWL4030_USB says anything to human beings. I don't read anywhere Linus saying we should clutter drivers/*/Kconfig with defaults. I think you're inverting things, it's much better to select TWL4030_USB when you enable MACH_OMAP_RX51 then default y if MACH_OMAP_RX51. So say, if you have 100 board defconfigs with OMAP3 chips and TWL4030, each and every one of them should select both USB_MUSB_HDRC and TWL4030_USB? And you are saying if somebody is doing 'make menuconfig', that person should somehow know that _obviously_ he needs TWL4030_USB in order to use USB_MUSB_HDRC, or USB_G_NOKIA? That's precisely the opposite to: --- It's often tedious for other cases too (I just want to enable a particular driver, what do I need to do so?) --- --- In other words, you _can_ encode the information that is in the xyz_defconfig files by doing it in Kconfig.xyz files instead. But you do it in a human-readable manner. And the hierarchical thing is absolutely required for that - otherwise you'd end up with just another form of the current xyz_defconfig. --- Yes, but how do you get rid of the defconfig while also having a working USB_G_NOKIA? Somehow a transceiver should be automatically selected. and you do that selection when the board is enabled otherwise the drivers Kconfig will be cluttered with default Y if blabla. If you can imagine a hierarchy like: drivers/usb/otg/Kconfig arch/arm/mach-omap2/Kconfig ^ arch/arm/mach-omap2/boards/Kconfig.n900 You would want TWL4030_USB to be up in the hierarchy, so that you don't have to add one extra line to each and every board file. But in fact, you don't want TWL4030_USB on the Kconfig because not everyone might want/need USB support. That should be selected by the user, and asking the user to somehow know that he needs both TWL4030_USB and USB_MUSB_HDRC is way too much to ask in my opinion. The idea would be to keep Kconfig.n900 so minimal that it's not needed at all. -- Felipe Contreras -- 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/3] drivers: misc: add omap_hwspinlock driver
On Tuesday 19 October 2010 22:43:34 Ohad Ben-Cohen wrote: Disabling irqs might be a concern as a source of RT latency. It might be better to make the caller responsible for managing local spin locks and irq disable/enable. This a coming from an hardware requirement, rather than a choice the user should take. If a hwspinlock is taken over a long period of time, its other user (with which we try to achieve synchronization) might be polling the OMAP interconnect for too long (trying to take the hwspinlock) and thus preventing it to be used for other transactions. This sounds exactly like any other spinlock. To prevent such lengthy polling on the interconnect, the hwspinlock should only be used for very short period of times, with preemption and interrupts disabled. Interrupts disabled in general might go a bit too far -- they are also short and infrequent events unless you have seriously broken drivers. When running with CONFIG_PREEMPT, I would guess you actually want to turn the omap_hwspinlock into a sleeping operation, though that would require much extra work to implement. Disabling preemption while the hwspinlock is held is of course a correct implementation technically, but it might not be what someone enabling CONFIG_PREEMPT expects. That's why we don't give users the choice whether to disable interrupts or not - it's simply not a decision they should take. What about those cases where you already know that interrupts are disabled, e.g. while holding a regular spin_lock_irq or inside of an interrupt handler? Arnd -- 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 3/3] omap: add hwspinlock device
On Tue, Oct 19, 2010 at 7:03 PM, Kevin Hilman khil...@deeprootsystems.com wrote: +postcore_initcall(hwspinlocks_init); Any reason this needs to be a postcore_initcall? Are there users of hwspinlocks this early in boot? i2c-omap, which is subsys_initcall (the I2C bus is shared between the A9 and the M3 on some OMAP4 boards). And to allow early board code to reserve specific hwspinlock numbers for predefined use-cases, we probably want to be before arch_initcall. The I2C Probaly subsys or even device_initcall is more appropriate here. I would've suspected that any users of hwspinlocks will be dependent on drivers for the other cores (e.g. syslink) which would likely be initialized much later. Kevin -- 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/3] drivers: misc: add omap_hwspinlock driver
On Tuesday 19 October 2010 22:51:22 Ohad Ben-Cohen wrote:
, which is generally discouraged
in all places where you know if you need to disable interrupts or not.
IMHO the default should be a version that only allows locks that don't get
taken at IRQ time and consequently don't require saving the interrupt flags.
Please note that the hwspinlocks should never be used to achieve
synchronization with Linux contexts running on the same cpu - it's
always about achieving mutual exclusion with a remote processor.
Ok, I see.
So whether the lock is taken at IRQ time or not does not affect the
requirement to disable interrupts while it is taken (very differently
from local spin_lock{_irqsave} synchronizations).
Right. There are two more things to consider though:
If you know that interrupts are disabled, you may still want to avoid
having to save the interrupt flag to the stack, to save some cycles
saving and restoring it. I don't know how expensive that is on ARM,
some other architectures take an microseconds to restore the interrupt
enabled flag from a register.
Even in the case where you know that interrupts are enabled, you may
want to avoid saving the interrupt flag to the stack, the simpler
API (one argument instead of two) gives less room for screwing up.
Arnd
--
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/3] drivers: misc: add omap_hwspinlock driver
On Tue, Oct 19, 2010 at 10:58 PM, Arnd Bergmann a...@arndb.de wrote: If a hwspinlock is taken over a long period of time, its other user (with which we try to achieve synchronization) might be polling the OMAP interconnect for too long (trying to take the hwspinlock) and thus preventing it to be used for other transactions. This sounds exactly like any other spinlock. The difference is hardware-specific: the hwspinlock device is located on the OMAP's L4 interconnect where access is slow, wasteful of power, and spinning on it may prevent other peripherals from interconnecting. -- 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
DSS2 crash with shutdown -h now
I'm using a 2.6.35 kernel, and the generic panel driver. I see this crash about 25% of the time, so I suspect a race condition. Is anyone else encountering this? Steve Unmounting local filesystems... Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa050040 Internal error: : 1028 [#1] last sysfs file: /sys/devices/virtual/vc/vcs12/uevent Modules linked in: ipv6 uvcvideo videodev v4l1_compat ads7846 CPU: 0Not tainted (2.6.35 #1) PC is at dss_select_dispc_clk_source+0x20/0x40 LR is at omapdss_dpi_display_disable+0x20/0x50 pc : [c01f74d4]lr : [c01ffc80]psr: 6013 sp : ded59e38 ip : 0090 fp : 0001 r10: 0001 r9 : ded58000 r8 : c0032084 r7 : ded59e50 r6 : r5 : c01fcc28 r4 : c057da00 r3 : r2 : fa05 r1 : c05d062c r0 : 0002 Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c5387d Table: 9ed84019 DAC: 0015 Process halt (pid: 503, stack limit = 0xded582f0) Stack: (0xded59e38 to 0xded5a000) 9e20: c057da00 c020a430 9e40: c01fcc48 ded59e50 c022f424 dfc3fc78 dfccc170 dfe02400 c057d4cc 9e60: c057d4c0 c05d4fac c0230ba4 c0575de0 c022c6f8 28121969 cdef0123 9e80: fee1dead c0065d58 28121969 c0065ed4 0014 dfc17dd8 0001 dfc299c0 9ea0: ded59eb0 c0062ee4 c00546f0 000a4800 a013 ded59f08 9ec0: 0001 0014 ded58000 0001 0001 c0063068 ded59f08 9ee0: dfc299c0 dfc18500 ded59f08 0014 ded58000 c0063cb8 0001 9f00: 0006 c0063d2c 0014 0164 01f7 dfc299f8 9f20: 0164 dfc299f0 c057f598 fffd c006e810 9f40: ded59f6c dfc299c0 c0052fbc dfc299c0 dff16e00 dec41080 dec92540 9f60: ded59fac ded59f70 c03e841c c0052f90 ff9c c0031f58 dec927a8 ded58000 9f80: 0006 0025 0006 9fa0: 0058 c0031f00 fee1dead 28121969 4321fedc 9fc0: 0006 0058 0001 0001 0001 0001 9fe0: 00011e50 bef36cb0 925c 400e23f8 2010 fee1dead [c01f74d4] (dss_select_dispc_clk_source+0x20/0x40) from [c01ffc80] (omapdss_dpi_display_disable+0x20/0x50) [c01ffc80] (omapdss_dpi_display_disable+0x20/0x50) from [c020a430] (generic_panel_disable+0xc/0x18) [c020a430] (generic_panel_disable+0xc/0x18) from [c01fcc48] (dss_disable_device+0x20/0x2c) [c01fcc48] (dss_disable_device+0x20/0x2c) from [c022f424] (bus_for_each_dev+0x4c/0x8c) [c022f424] (bus_for_each_dev+0x4c/0x8c) from [c0230ba4] (platform_drv_shutdown+0x1c/0x24) [c0230ba4] (platform_drv_shutdown+0x1c/0x24) from [c022c6f8] (device_shutdown+0x70/0x94) [c022c6f8] (device_shutdown+0x70/0x94) from [c0065d58] (kernel_halt+0x10/0x2c) [c0065d58] (kernel_halt+0x10/0x2c) from [c0065ed4] (sys_reboot+0x118/0x1dc) [c0065ed4] (sys_reboot+0x118/0x1dc) from [c0031f00] (ret_fast_syscall+0x0/0x30) Code: e5833000 eafd e59f101c e5912000 (e5923040) OMAPFB: pan_display(0) OMAPFB: setcmap OMAPFB: setcmap OMAPFB: setcmap ---[ end trace 953aeb15ef1f69db ]--- Segmentation fault -- 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 v2 0/7] OMAP4: mux: Add the OMAP4430 ES1 ES2 support
Hi Tony, Upon Nishanth request, here is the updated version... It takes into account your proposal to store partition information in a partition structure instead of inside every pad entries. The mechanism relies on the uniqueness of the pad name in each partition to find the correct partition during iteration. Removed as well some cpu_is_xxx calls from the core code by adding a couple of flags during partition init. Please note that due to low level access to mux api from the RX51 board code, I have to disable the mux change to build properly with omap2plus_defconfig. Look like you do have some idea to fix that :-) I was thinking of: - brute force approach that consist of keeping all the data after init, and thus allowing removing the __init in the omap_mux_init_signal API - or adding some flag in the pad entry to keep them after init . Boot tested on SDP4430 with ES1.0 ES2.0 with omap2plus_defconfig. Still require some real driver to use that mux API in order to validate it. The series is on top of lo/master (2.6.36-rc8) and is available here: git://gitorious.org/omap-pm/linux.git ctrl-wip/mux-omap4-v2 Thanks, Benoit v1: http://www.spinics.net/lists/linux-omap/msg37158.html Benoit Cousson (7): OMAP: mux: Replace printk with pr_xxx macros OMAP3: RX-51: Temporary disable dynamic mux change for eMMC OMAP: mux: Add support for control module split in several partitions OMAP4: mux: Add CBL package data for OMAP4430 ES1 OMAP4: mux: Select CBL package for SDP4430 with ES1 OMAP4: mux: Add CBS package data for OMAP4430 ES2 OMAP4: mux: Select CBS package for SDP4430 with ES2 arch/arm/mach-omap2/Kconfig |8 + arch/arm/mach-omap2/Makefile |1 + arch/arm/mach-omap2/board-4430sdp.c | 14 + arch/arm/mach-omap2/board-rx51-peripherals.c |3 +- arch/arm/mach-omap2/mux.c| 330 -- arch/arm/mach-omap2/mux.h| 92 +- arch/arm/mach-omap2/mux2420.c|7 +- arch/arm/mach-omap2/mux2430.c|7 +- arch/arm/mach-omap2/mux34xx.c|7 +- arch/arm/mach-omap2/mux44xx.c| 1625 ++ arch/arm/mach-omap2/mux44xx.h| 298 + 11 files changed, 2229 insertions(+), 163 deletions(-) create mode 100644 arch/arm/mach-omap2/mux44xx.c create mode 100644 arch/arm/mach-omap2/mux44xx.h -- 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 v2 1/7] OMAP: mux: Replace printk with pr_xxx macros
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/mux.c | 38 +++---
1 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 074536a..979e9d1 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -102,13 +102,13 @@ int __init omap_mux_init_gpio(int gpio, int val)
}
if (found == 0) {
- printk(KERN_ERR mux: Could not set gpio%i\n, gpio);
+ pr_err(mux: Could not set gpio%i\n, gpio);
return -ENODEV;
}
if (found 1) {
- printk(KERN_INFO mux: Multiple gpio paths (%d) for gpio%i\n,
- found, gpio);
+ pr_info(mux: Multiple gpio paths (%d) for gpio%i\n,
+ found, gpio);
return -EINVAL;
}
@@ -118,8 +118,8 @@ int __init omap_mux_init_gpio(int gpio, int val)
mux_mode |= OMAP_MUX_MODE3;
else
mux_mode |= OMAP_MUX_MODE4;
- printk(KERN_DEBUG mux: Setting signal %s.gpio%i 0x%04x - 0x%04x\n,
- gpio_mux-muxnames[0], gpio, old_mode, mux_mode);
+ pr_debug(mux: Setting signal %s.gpio%i 0x%04x - 0x%04x\n,
+gpio_mux-muxnames[0], gpio, old_mode, mux_mode);
omap_mux_write(mux_mode, gpio_mux-reg_offset);
return 0;
@@ -161,9 +161,9 @@ int __init omap_mux_init_signal(const char *muxname, int
val)
old_mode = omap_mux_read(m-reg_offset);
mux_mode = val | i;
- printk(KERN_DEBUG mux: Setting signal
- %s.%s 0x%04x - 0x%04x\n,
- m0_entry, muxname, old_mode, mux_mode);
+ pr_debug(mux: Setting signal
+%s.%s 0x%04x - 0x%04x\n,
+m0_entry, muxname, old_mode, mux_mode);
omap_mux_write(mux_mode, m-reg_offset);
found++;
}
@@ -174,12 +174,12 @@ int __init omap_mux_init_signal(const char *muxname, int
val)
return 0;
if (found 1) {
- printk(KERN_ERR mux: Multiple signal paths (%i) for %s\n,
- found, muxname);
+ pr_err(mux: Multiple signal paths (%i) for %s\n,
+ found, muxname);
return -EINVAL;
}
- printk(KERN_ERR mux: Could not set signal %s\n, muxname);
+ pr_err(mux: Could not set signal %s\n, muxname);
return -ENODEV;
}
@@ -462,8 +462,8 @@ static void __init omap_mux_package_fixup(struct omap_mux
*p,
s++;
}
if (!found)
- printk(KERN_ERR mux: Unknown entry offset 0x%x\n,
- p-reg_offset);
+ pr_err(mux: Unknown entry offset 0x%x\n,
+ p-reg_offset);
p++;
}
}
@@ -487,8 +487,8 @@ static void __init omap_mux_package_init_balls(struct
omap_ball *b,
s++;
}
if (!found)
- printk(KERN_ERR mux: Unknown ball offset 0x%x\n,
- b-reg_offset);
+ pr_err(mux: Unknown ball offset 0x%x\n,
+ b-reg_offset);
b++;
}
}
@@ -615,7 +615,7 @@ u16 omap_mux_get_gpio(int gpio)
offset = omap_mux_get_by_gpio(gpio);
if (offset == OMAP_MUX_TERMINATOR) {
- printk(KERN_ERR mux: Could not get gpio%i\n, gpio);
+ pr_err(mux: Could not get gpio%i\n, gpio);
return offset;
}
@@ -629,7 +629,7 @@ void omap_mux_set_gpio(u16 val, int gpio)
offset = omap_mux_get_by_gpio(gpio);
if (offset == OMAP_MUX_TERMINATOR) {
- printk(KERN_ERR mux: Could not set gpio%i\n, gpio);
+ pr_err(mux: Could not set gpio%i\n, gpio);
return;
}
@@ -687,7 +687,7 @@ static void __init omap_mux_init_list(struct omap_mux
*superset)
entry = omap_mux_list_add(superset);
if (!entry) {
- printk(KERN_ERR mux: Could not add entry\n);
+ pr_err(mux: Could not add entry\n);
return;
}
superset++;
@@ -738,7 +738,7 @@ int __init omap_mux_init(u32 mux_pbase, u32 mux_size,
mux_phys = mux_pbase;
mux_base = ioremap(mux_pbase, mux_size);
if (!mux_base) {
- printk(KERN_ERR mux: Could not
[RFC v2 2/7] OMAP3: RX-51: Temporary disable dynamic mux change for eMMC
RX-51 board is using some low level function in order to change
the padconf settings at runtime.
Since these functions will not be usable anymore after the
partition introduction, remove the code that use these code.
As soon as a proper API will be proposed, this patch will be drop.
Signed-off-by: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/board-rx51-peripherals.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 25a273d..56a49a0 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -260,6 +260,7 @@ static struct twl4030_madc_platform_data rx51_madc_data = {
.irq_line = 1,
};
+#if 0
/* Enable input logic and pull all lines up when eMMC is on. */
static struct omap_board_mux rx51_mmc2_on_mux[] = {
OMAP3_MUX(SDMMC2_CMD, OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0),
@@ -299,6 +300,7 @@ static void rx51_mmc2_remux(struct device *dev, int slot,
int power_on)
else
omap_mux_write_array(rx51_mmc2_off_mux);
}
+#endif
static struct omap2_hsmmc_info mmc[] __initdata = {
{
@@ -319,7 +321,6 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
.gpio_wp= -EINVAL,
.nonremovable = true,
.power_saving = true,
- .remux = rx51_mmc2_remux,
},
{} /* Terminator */
};
--
1.7.0.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
[RFC v2 3/7] OMAP: mux: Add support for control module split in several partitions
Starting on OMAP4, the pin mux configuration is located in two
different partitions of the control module (CODE_PAD and WKUP_PAD).
The first one is inside the core power domain whereas the second
one is inside the wakeup.
Add the capability to add any number of partition during board init
time depending of Soc partitioning.
Add some init flags as well in order to avoid explicit Soc version
check inside the mux core code.
Note that this implementation change will make the mux_read, mux_write
and omap_mux_write_array accessors unusable outside the mux code.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/mux.c | 298 ++--
arch/arm/mach-omap2/mux.h | 79 +++-
arch/arm/mach-omap2/mux2420.c |7 +-
arch/arm/mach-omap2/mux2430.c |7 +-
arch/arm/mach-omap2/mux34xx.c |7 +-
5 files changed, 252 insertions(+), 146 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 979e9d1..9b9128e 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -1,9 +1,9 @@
/*
* linux/arch/arm/mach-omap2/mux.c
*
- * OMAP2 and OMAP3 pin multiplexing configurations
+ * OMAP2, OMAP3 and OMAP4 pin multiplexing configurations
*
- * Copyright (C) 2004 - 2008 Texas Instruments Inc.
+ * Copyright (C) 2004 - 2010 Texas Instruments Inc.
* Copyright (C) 2003 - 2008 Nokia Corporation
*
* Written by Tony Lindgren
@@ -40,60 +40,60 @@
#define OMAP_MUX_BASE_OFFSET 0x30/* Offset from CTRL_BASE */
#define OMAP_MUX_BASE_SZ 0x5ca
-#define MUXABLE_GPIO_MODE3 BIT(0)
struct omap_mux_entry {
struct omap_mux mux;
struct list_headnode;
};
-static unsigned long mux_phys;
-static void __iomem *mux_base;
-static u8 omap_mux_flags;
+static LIST_HEAD(mux_partitions);
+static DEFINE_MUTEX(muxmode_mutex);
-u16 omap_mux_read(u16 reg)
+static u16 omap_mux_read(struct omap_mux_partition *partition, u16 reg)
{
- if (cpu_is_omap24xx())
- return __raw_readb(mux_base + reg);
+ if (partition-flags OMAP_MUX_REG_8BIT)
+ return __raw_readb(partition-base + reg);
else
- return __raw_readw(mux_base + reg);
+ return __raw_readw(partition-base + reg);
}
-void omap_mux_write(u16 val, u16 reg)
+static void omap_mux_write(struct omap_mux_partition *partition, u16 val,
+ u16 reg)
{
- if (cpu_is_omap24xx())
- __raw_writeb(val, mux_base + reg);
+ if (partition-flags OMAP_MUX_REG_8BIT)
+ __raw_writeb(val, partition-base + reg);
else
- __raw_writew(val, mux_base + reg);
+ __raw_writew(val, partition-base + reg);
}
-void omap_mux_write_array(struct omap_board_mux *board_mux)
+static void omap_mux_write_array(struct omap_mux_partition *partition,
+struct omap_board_mux *board_mux)
{
- while (board_mux-reg_offset != OMAP_MUX_TERMINATOR) {
- omap_mux_write(board_mux-value, board_mux-reg_offset);
+ while (board_mux-reg_offset != OMAP_MUX_TERMINATOR) {
+ omap_mux_write(partition, board_mux-value,
+ board_mux-reg_offset);
board_mux++;
}
}
-static LIST_HEAD(muxmodes);
-static DEFINE_MUTEX(muxmode_mutex);
-
#ifdef CONFIG_OMAP_MUX
static char *omap_mux_options;
-int __init omap_mux_init_gpio(int gpio, int val)
+static int __init _omap_mux_init_gpio(struct omap_mux_partition *partition,
+ int gpio, int val)
{
struct omap_mux_entry *e;
struct omap_mux *gpio_mux = NULL;
u16 old_mode;
u16 mux_mode;
int found = 0;
+ struct list_head *muxmodes = partition-muxmodes;
if (!gpio)
return -EINVAL;
- list_for_each_entry(e, muxmodes, node) {
+ list_for_each_entry(e, muxmodes, node) {
struct omap_mux *m = e-mux;
if (gpio == m-gpio) {
gpio_mux = m;
@@ -112,24 +112,40 @@ int __init omap_mux_init_gpio(int gpio, int val)
return -EINVAL;
}
- old_mode = omap_mux_read(gpio_mux-reg_offset);
+ old_mode = omap_mux_read(partition, gpio_mux-reg_offset);
mux_mode = val ~(OMAP_MUX_NR_MODES - 1);
- if (omap_mux_flags MUXABLE_GPIO_MODE3)
+ if (partition-flags OMAP_MUX_GPIO_IN_MODE3)
mux_mode |= OMAP_MUX_MODE3;
else
mux_mode |= OMAP_MUX_MODE4;
pr_debug(mux: Setting signal %s.gpio%i 0x%04x - 0x%04x\n,
gpio_mux-muxnames[0], gpio, old_mode, mux_mode);
- omap_mux_write(mux_mode, gpio_mux-reg_offset);
+
[RFC v2 5/7] OMAP4: mux: Select CBL package for SDP4430 with ES1
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/Kconfig |1 +
arch/arm/mach-omap2/board-4430sdp.c | 10 ++
2 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index e14c73d..7efb256 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -280,6 +280,7 @@ config MACH_OMAP_4430SDP
bool OMAP 4430 SDP board
default y
depends on ARCH_OMAP4
+ select OMAP_PACKAGE_CBL
config MACH_OMAP4_PANDA
bool OMAP4 Panda Board
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index aafd306..83ee5b4 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -35,6 +35,7 @@
#include plat/usb.h
#include plat/mmc.h
+#include mux.h
#include hsmmc.h
#include timer-gp.h
#include control.h
@@ -500,10 +501,19 @@ static void __init omap_sfh7741prox_init(void)
}
}
+#ifdef CONFIG_OMAP_MUX
+static struct omap_board_mux board_mux[] __initdata = {
+ { .reg_offset = OMAP_MUX_TERMINATOR },
+};
+#else
+#define board_mux NULL
+#endif
+
static void __init omap_4430sdp_init(void)
{
int status;
+ omap4_mux_init(board_mux, OMAP_PACKAGE_CBL);
omap4_i2c_init();
omap_sfh7741prox_init();
platform_add_devices(sdp4430_devices, ARRAY_SIZE(sdp4430_devices));
--
1.7.0.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
[RFC v2 7/7] OMAP4: mux: Select CBS package for SDP4430 with ES2
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Anand Gadiyar gadi...@ti.com
---
arch/arm/mach-omap2/Kconfig |1 +
arch/arm/mach-omap2/board-4430sdp.c |6 +-
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 92fea63..39229cf 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -284,6 +284,7 @@ config MACH_OMAP_4430SDP
default y
depends on ARCH_OMAP4
select OMAP_PACKAGE_CBL
+ select OMAP_PACKAGE_CBS
config MACH_OMAP4_PANDA
bool OMAP4 Panda Board
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 83ee5b4..323b62e 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -512,8 +512,12 @@ static struct omap_board_mux board_mux[] __initdata = {
static void __init omap_4430sdp_init(void)
{
int status;
+ int package = OMAP_PACKAGE_CBS;
+
+ if (omap_rev() == OMAP4430_REV_ES1_0)
+ package = OMAP_PACKAGE_CBL;
+ omap4_mux_init(board_mux, package);
- omap4_mux_init(board_mux, OMAP_PACKAGE_CBL);
omap4_i2c_init();
omap_sfh7741prox_init();
platform_add_devices(sdp4430_devices, ARRAY_SIZE(sdp4430_devices));
--
1.7.0.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
[RFC v2 6/7] OMAP4: mux: Add CBS package data for OMAP4430 ES2
Please note that the full muxmodes are re-defined for ES2 instead
of using the subset. There are 81 differences among 204 pins.
The subset fixup will have to iterate over the whole list for each
subset entry, which can lead to an important number of iteration.
On the other hand, it will take much more memory at boot time.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Anand Gadiyar gadi...@ti.com
---
arch/arm/mach-omap2/Kconfig |3 +
arch/arm/mach-omap2/mux.h |1 +
arch/arm/mach-omap2/mux44xx.c | 741 -
arch/arm/mach-omap2/mux44xx.h | 21 ++
4 files changed, 758 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 7efb256..92fea63 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -88,6 +88,9 @@ config OMAP_PACKAGE_CBP
config OMAP_PACKAGE_CBL
bool
+config OMAP_PACKAGE_CBS
+ bool
+
comment OMAP Board Type
depends on ARCH_OMAP2PLUS
diff --git a/arch/arm/mach-omap2/mux.h b/arch/arm/mach-omap2/mux.h
index 28286a9..b34a2ad 100644
--- a/arch/arm/mach-omap2/mux.h
+++ b/arch/arm/mach-omap2/mux.h
@@ -62,6 +62,7 @@
/* Flags for omapX_mux_init */
#define OMAP_PACKAGE_MASK 0x
+#define OMAP_PACKAGE_CBS 8 /* 547-pin 0.40 0.40 */
#define OMAP_PACKAGE_CBL 7 /* 547-pin 0.40 0.40 */
#define OMAP_PACKAGE_CBP 6 /* 515-pin 0.40 0.50 */
#define OMAP_PACKAGE_CUS 5 /* 423-pin 0.65 */
diff --git a/arch/arm/mach-omap2/mux44xx.c b/arch/arm/mach-omap2/mux44xx.c
index 5e9d60a..80335f3 100644
--- a/arch/arm/mach-omap2/mux44xx.c
+++ b/arch/arm/mach-omap2/mux44xx.c
@@ -48,7 +48,7 @@
}
/*
- * Superset of all mux modes for omap4
+ * Superset of all mux modes for omap4 ES1.0
*/
static struct omap_mux __initdata omap4_core_muxmodes[] = {
_OMAP4_MUXENTRY(GPMC_AD0, 0, gpmc_ad0, sdmmc2_dat0, NULL, NULL,
@@ -755,6 +755,724 @@ struct omap_ball __initdata omap4_core_cbl_ball[] = {
#endif
/*
+ * Superset of all mux modes for omap4 ES2.0
+ */
+static struct omap_mux __initdata omap4_es2_core_muxmodes[] = {
+ _OMAP4_MUXENTRY(GPMC_AD0, 0, gpmc_ad0, sdmmc2_dat0, NULL, NULL,
+ NULL, NULL, NULL, NULL),
+ _OMAP4_MUXENTRY(GPMC_AD1, 0, gpmc_ad1, sdmmc2_dat1, NULL, NULL,
+ NULL, NULL, NULL, NULL),
+ _OMAP4_MUXENTRY(GPMC_AD2, 0, gpmc_ad2, sdmmc2_dat2, NULL, NULL,
+ NULL, NULL, NULL, NULL),
+ _OMAP4_MUXENTRY(GPMC_AD3, 0, gpmc_ad3, sdmmc2_dat3, NULL, NULL,
+ NULL, NULL, NULL, NULL),
+ _OMAP4_MUXENTRY(GPMC_AD4, 0, gpmc_ad4, sdmmc2_dat4,
+ sdmmc2_dir_dat0, NULL, NULL, NULL, NULL, NULL),
+ _OMAP4_MUXENTRY(GPMC_AD5, 0, gpmc_ad5, sdmmc2_dat5,
+ sdmmc2_dir_dat1, NULL, NULL, NULL, NULL, NULL),
+ _OMAP4_MUXENTRY(GPMC_AD6, 0, gpmc_ad6, sdmmc2_dat6,
+ sdmmc2_dir_cmd, NULL, NULL, NULL, NULL, NULL),
+ _OMAP4_MUXENTRY(GPMC_AD7, 0, gpmc_ad7, sdmmc2_dat7,
+ sdmmc2_clk_fdbk, NULL, NULL, NULL, NULL, NULL),
+ _OMAP4_MUXENTRY(GPMC_AD8, 32, gpmc_ad8, kpd_row0, c2c_data15,
+ gpio_32, NULL, sdmmc1_dat0, NULL, NULL),
+ _OMAP4_MUXENTRY(GPMC_AD9, 33, gpmc_ad9, kpd_row1, c2c_data14,
+ gpio_33, NULL, sdmmc1_dat1, NULL, NULL),
+ _OMAP4_MUXENTRY(GPMC_AD10, 34, gpmc_ad10, kpd_row2, c2c_data13,
+ gpio_34, NULL, sdmmc1_dat2, NULL, NULL),
+ _OMAP4_MUXENTRY(GPMC_AD11, 35, gpmc_ad11, kpd_row3, c2c_data12,
+ gpio_35, NULL, sdmmc1_dat3, NULL, NULL),
+ _OMAP4_MUXENTRY(GPMC_AD12, 36, gpmc_ad12, kpd_col0, c2c_data11,
+ gpio_36, NULL, sdmmc1_dat4, NULL, NULL),
+ _OMAP4_MUXENTRY(GPMC_AD13, 37, gpmc_ad13, kpd_col1, c2c_data10,
+ gpio_37, NULL, sdmmc1_dat5, NULL, NULL),
+ _OMAP4_MUXENTRY(GPMC_AD14, 38, gpmc_ad14, kpd_col2, c2c_data9,
+ gpio_38, NULL, sdmmc1_dat6, NULL, NULL),
+ _OMAP4_MUXENTRY(GPMC_AD15, 39, gpmc_ad15, kpd_col3, c2c_data8,
+ gpio_39, NULL, sdmmc1_dat7, NULL, NULL),
+ _OMAP4_MUXENTRY(GPMC_A16, 40, gpmc_a16, kpd_row4, c2c_datain0,
+ gpio_40, venc_656_data0, NULL, NULL, safe_mode),
+ _OMAP4_MUXENTRY(GPMC_A17, 41, gpmc_a17, kpd_row5, c2c_datain1,
+ gpio_41, venc_656_data1, NULL, NULL, safe_mode),
+ _OMAP4_MUXENTRY(GPMC_A18, 42, gpmc_a18, kpd_row6, c2c_datain2,
+ gpio_42, venc_656_data2, NULL, NULL, safe_mode),
+ _OMAP4_MUXENTRY(GPMC_A19, 43, gpmc_a19, kpd_row7, c2c_datain3,
+ gpio_43, venc_656_data3, NULL,
Re: linux-next - multi-omap image fails to boot on omap3/4
* Gadiyar, Anand gadi...@ti.com [101019 11:26]: On Tue, Oct 19, 2010 at 11:51 PM, Tony Lindgren t...@atomide.com wrote: * Anand Gadiyar gadi...@ti.com [101019 07:41]: Hi all, linux-next, as of 20101019, built with the omap2plus_defconfig fails to boot on omap3 and omap4. (I've disabled CONFIG_ARCH_OMAP2 or CONFIG_SWP_EMULATE to get the image to build). Building with only ARCH_OMAP3 allows the resultant image to boot up on OMAP3. Likewise, an image built with only ARCH_OMAP4 boots up on OMAP4 boards. earlyprintk does not provide any additional prints after Uncompressing Linux... done, booting the kernel. Any ideas where to look? Hmm I did a quick test merge of linux-omap master and rmk/devel branches and that boots just fine. So it's probably something that already got fixed in rmk/devel but is not yet in next, or something that came from elsewhere, or something that we have in omap-testing branch that's not in for-next for some reason. I tried bisecting linux-next between v2.6.36-rc8 and HEAD, but there's a commit in between that breaks the build. I'll take another stab at this in a while. Looks like current next at 80f8f1f8b33750d954beb386c0c8142d0c01c25c boots again except on 2430sdp it produces a NULL pointer at ubi_io_write. 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: [RFC v2 0/7] OMAP4: mux: Add the OMAP4430 ES1 ES2 support
* Benoit Cousson b-cous...@ti.com [101019 15:14]: Hi Tony, Upon Nishanth request, here is the updated version... It takes into account your proposal to store partition information in a partition structure instead of inside every pad entries. The mechanism relies on the uniqueness of the pad name in each partition to find the correct partition during iteration. OK, using the offset defines won't be unique necessarily.. Removed as well some cpu_is_xxx calls from the core code by adding a couple of flags during partition init. That's great. Please note that due to low level access to mux api from the RX51 board code, I have to disable the mux change to build properly with omap2plus_defconfig. Look like you do have some idea to fix that :-) I was thinking of: - brute force approach that consist of keeping all the data after init, and thus allowing removing the __init in the omap_mux_init_signal API - or adding some flag in the pad entry to keep them after init . Well I was thinking we just register a board specific dynamic mux table and then call that when hitting retention or off and restore after that. Still need to think about that a bit more, I don't know if we want the automatic muxing of gpio pins still in addition to that. Boot tested on SDP4430 with ES1.0 ES2.0 with omap2plus_defconfig. Still require some real driver to use that mux API in order to validate it. You can test by echoing wrong values after booting via /sys to mess up the MMC data lines and then type sync :) The series is on top of lo/master (2.6.36-rc8) and is available here: git://gitorious.org/omap-pm/linux.git ctrl-wip/mux-omap4-v2 For pulling anything in, the git branches need to be based on something that's immutable. So preferrably v2.6.35 or some recent -rc tag in this case. Or rebase it on v2.6.36 after that's been released. 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
