Re: [PATCH v6 7/8] OMAP4: Keyboard board support
HI Abraham, On Thu, Sep 30, 2010 at 12:36:13AM -0500, Abraham Arce wrote: > From: Syed Rafiuddin > > Keyboard support for SDP OMAP4430 > I think this would benefit from "const" sprinkled on it. BTW, I picked up patches 2, 3, 4, 5, 8 (all touching drivers/input). Thanks. -- Dmitry -- 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 08/11] OMAP3: PM: Adding debug support to Voltage and Smartreflex drivers
>>-Original Message- >>From: Kevin Hilman [mailto:khil...@deeprootsystems.com] >>Sent: Thursday, September 30, 2010 4:50 AM >>To: Gopinath, Thara >>Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy, >>Vishwanath; Sawant, Anand >>Subject: Re: [PATCH v3 08/11] OMAP3: PM: Adding debug support to Voltage and >>Smartreflex drivers >> >>Thara Gopinath writes: >> >>[...] >> >>> diff --git a/arch/arm/plat-omap/include/plat/voltage.h b/arch/arm/plat- >>omap/include/plat/voltage.h >>> index 99836a1..8978d33 100644 >>> --- a/arch/arm/plat-omap/include/plat/voltage.h >>> +++ b/arch/arm/plat-omap/include/plat/voltage.h >>> @@ -14,6 +14,11 @@ >>> #ifndef __ARCH_ARM_MACH_OMAP2_VOLTAGE_H >>> #define __ARCH_ARM_MACH_OMAP2_VOLTAGE_H >>> >>> +extern u32 enable_sr_vp_debug; >>> +#ifdef CONFIG_PM_DEBUG >>> +extern struct dentry *pm_dbg_main_dir; >>> +#endif >>> + >>> #define VOLTSCALE_VPFORCEUPDATE1 >>> #define VOLTSCALE_VCBYPASS 2 >> >>This belongs in PATCH 1/11 and belongs in pm.h, not voltage.h as it's a >>feature of the PM debug layer, not the voltage layer. Yes indeed!! Will fix this in v4 Regards Thara -- 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 v6 8/8] Input: omap4 - pm runtime
Enable pm runtime in driver Reviewed-by: Basak, Partha Signed-off-by: Abraham Arce --- drivers/input/keyboard/omap4-keypad.c |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/drivers/input/keyboard/omap4-keypad.c b/drivers/input/keyboard/omap4-keypad.c index 45bd097..ed47e9a 100644 --- a/drivers/input/keyboard/omap4-keypad.c +++ b/drivers/input/keyboard/omap4-keypad.c @@ -29,6 +29,7 @@ #include #include #include +#include #include @@ -239,6 +240,9 @@ static int __devinit omap4_keypad_probe(struct platform_device *pdev) matrix_keypad_build_keymap(pdata->keymap_data, row_shift, input_dev->keycode, input_dev->keybit); + pm_runtime_enable(&pdev->dev); + pm_runtime_get_sync(&pdev->dev); + omap4_keypad_config(keypad_data); error = request_irq(keypad_data->irq, omap4_keypad_interrupt, @@ -277,6 +281,9 @@ static int __devexit omap4_keypad_remove(struct platform_device *pdev) struct omap4_keypad *keypad_data = platform_get_drvdata(pdev); struct resource *res; + pm_runtime_put_sync(&pdev->dev); + pm_runtime_disable(&pdev->dev); + free_irq(keypad_data->irq, keypad_data); input_unregister_device(keypad_data->input); -- 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
[PATCH v6 7/8] OMAP4: Keyboard board support
From: Syed Rafiuddin
Keyboard support for SDP OMAP4430
Signed-off-by: Syed Rafiuddin
Signed-off-by: Abraham Arce
---
arch/arm/mach-omap2/board-4430sdp.c | 90 +++
1 files changed, 90 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 1bed1e6..2991e56 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -44,6 +45,91 @@
#define OMAP4_SFH7741_SENSOR_OUTPUT_GPIO 184
#define OMAP4_SFH7741_ENABLE_GPIO 188
+static int sdp4430_keymap[] = {
+ KEY(0, 0, KEY_E),
+ KEY(0, 1, KEY_R),
+ KEY(0, 2, KEY_T),
+ KEY(0, 3, KEY_HOME),
+ KEY(0, 4, KEY_F5),
+ KEY(0, 5, KEY_UNKNOWN),
+ KEY(0, 6, KEY_I),
+ KEY(0, 7, KEY_LEFTSHIFT),
+
+ KEY(1, 0, KEY_D),
+ KEY(1, 1, KEY_F),
+ KEY(1, 2, KEY_G),
+ KEY(1, 3, KEY_SEND),
+ KEY(1, 4, KEY_F6),
+ KEY(1, 5, KEY_UNKNOWN),
+ KEY(1, 6, KEY_K),
+ KEY(1, 7, KEY_ENTER),
+
+ KEY(2, 0, KEY_X),
+ KEY(2, 1, KEY_C),
+ KEY(2, 2, KEY_V),
+ KEY(2, 3, KEY_END),
+ KEY(2, 4, KEY_F7),
+ KEY(2, 5, KEY_UNKNOWN),
+ KEY(2, 6, KEY_DOT),
+ KEY(2, 7, KEY_CAPSLOCK),
+
+ KEY(3, 0, KEY_Z),
+ KEY(3, 1, KEY_KPPLUS),
+ KEY(3, 2, KEY_B),
+ KEY(3, 3, KEY_F1),
+ KEY(3, 4, KEY_F8),
+ KEY(3, 5, KEY_UNKNOWN),
+ KEY(3, 6, KEY_O),
+ KEY(3, 7, KEY_SPACE),
+
+ KEY(4, 0, KEY_W),
+ KEY(4, 1, KEY_Y),
+ KEY(4, 2, KEY_U),
+ KEY(4, 3, KEY_F2),
+ KEY(4, 4, KEY_VOLUMEUP),
+ KEY(4, 5, KEY_UNKNOWN),
+ KEY(4, 6, KEY_L),
+ KEY(4, 7, KEY_LEFT),
+
+ KEY(5, 0, KEY_S),
+ KEY(5, 1, KEY_H),
+ KEY(5, 2, KEY_J),
+ KEY(5, 3, KEY_F3),
+ KEY(5, 4, KEY_F9),
+ KEY(5, 5, KEY_VOLUMEDOWN),
+ KEY(5, 6, KEY_M),
+ KEY(5, 7, KEY_RIGHT),
+
+ KEY(6, 0, KEY_Q),
+ KEY(6, 1, KEY_A),
+ KEY(6, 2, KEY_N),
+ KEY(6, 3, KEY_BACK),
+ KEY(6, 4, KEY_BACKSPACE),
+ KEY(6, 5, KEY_UNKNOWN),
+ KEY(6, 6, KEY_P),
+ KEY(6, 7, KEY_UP),
+
+ KEY(7, 0, KEY_PROG1),
+ KEY(7, 1, KEY_PROG2),
+ KEY(7, 2, KEY_PROG3),
+ KEY(7, 3, KEY_PROG4),
+ KEY(7, 4, KEY_F4),
+ KEY(7, 5, KEY_UNKNOWN),
+ KEY(7, 6, KEY_OK),
+ KEY(7, 7, KEY_DOWN),
+};
+
+static struct matrix_keymap_data sdp4430_keymap_data = {
+ .keymap = sdp4430_keymap,
+ .keymap_size= ARRAY_SIZE(sdp4430_keymap),
+};
+
+static struct omap4_keypad_platform_data sdp4430_keypad_data = {
+ .keymap_data= &sdp4430_keymap_data,
+ .rows = 8,
+ .cols = 8,
+};
+
static struct gpio_led sdp4430_gpio_leds[] = {
{
.name = "omap4:green:debug0",
@@ -507,6 +593,10 @@ static void __init omap_4430sdp_init(void)
if (!cpu_is_omap44xx())
usb_musb_init(&musb_board_data);
+ status = omap4_keyboard_init(&sdp4430_keypad_data);
+ if (status)
+ pr_err("Keypad initialization failed: %d\n", status);
+
status = omap_ethernet_init();
if (status) {
pr_err("Ethernet initialization failed: %d\n", status);
--
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
[PATCH v6 5/8] Input: omap4 - Wake-up on events & long presses
From: Mike Turquette Programs keyboard controller to generate a wake-up request on events and on long key presses. Does not generate wake-up requests on timeouts since driver code does not handle them. This allows keyboard to wake-up OMAP from suspend. Signed-off-by: Mike Turquette Signed-off-by: Abraham Arce --- drivers/input/keyboard/omap4-keypad.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/input/keyboard/omap4-keypad.c b/drivers/input/keyboard/omap4-keypad.c index 07e792e..45bd097 100644 --- a/drivers/input/keyboard/omap4-keypad.c +++ b/drivers/input/keyboard/omap4-keypad.c @@ -54,6 +54,8 @@ #define OMAP4_DEF_IRQENABLE_EVENTEN(1 << 0) #define OMAP4_DEF_IRQENABLE_LONGKEY(1 << 1) #define OMAP4_DEF_IRQENABLE_TIMEOUTEN (1 << 2) +#define OMAP4_DEF_WUP_EVENT_ENA(1 << 0) +#define OMAP4_DEF_WUP_LONG_KEY_ENA (1 << 1) #define OMAP4_DEF_CTRL_NOSOFTMODE (1 << 1) #define OMAP4_DEF_CTRLPTVVALUE (1 << 2) #define OMAP4_DEF_CTRLPTV (1 << 1) @@ -88,6 +90,8 @@ static void __devinit omap4_keypad_config(struct omap4_keypad *keypad_data) keypad_data->base + OMAP4_KBD_IRQSTATUS); __raw_writel(OMAP4_DEF_IRQENABLE_EVENTEN | OMAP4_DEF_IRQENABLE_LONGKEY, keypad_data->base + OMAP4_KBD_IRQENABLE); + __raw_writel(OMAP4_DEF_WUP_EVENT_ENA | OMAP4_DEF_WUP_LONG_KEY_ENA, + keypad_data->base + OMAP4_KBD_WAKEUPENABLE); } /* Interrupt handler */ -- 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
[PATCH v6 6/8] OMAP4: Keyboard device registration
Register keyboard device with hwmod framework
Signed-off-by: Abraham Arce
---
arch/arm/mach-omap2/devices.c | 39 +++
1 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 9e5d51b..226cc7a 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -28,6 +28,9 @@
#include
#include
#include
+#include
+#include
+#include
#include "mux.h"
@@ -138,6 +141,42 @@ static inline void omap_init_camera(void)
}
#endif
+struct omap_device_pm_latency omap4_keyboard_latency[] = {
+ {
+ .deactivate_func = omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+ },
+};
+
+int omap4_keyboard_init(struct omap4_keypad_platform_data
+ *keypad_data)
+{
+ struct omap_device *od;
+ struct omap_hwmod *oh;
+ const char *oh_name = "kbd";
+ const char *name = "omap4-keypad";
+
+ if (!cpu_is_omap44xx())
+ return -ENODEV;
+
+ oh = omap_hwmod_lookup(oh_name);
+ if (!oh) {
+ pr_err("Could not look up %s\n", oh_name);
+ return -ENODEV;
+ }
+
+ od = omap_device_build(name, -1, oh, keypad_data,
+ sizeof(*keypad_data),
+ omap4_keyboard_latency,
+ ARRAY_SIZE(omap4_keyboard_latency), 0);
+ if (WARN(IS_ERR(od), "Could not build omap_device for %s %s\n",
+ name, oh->name))
+ return -ENODEV;
+
+ return 0;
+}
+
#if defined(CONFIG_OMAP_MBOX_FWK) || defined(CONFIG_OMAP_MBOX_FWK_MODULE)
#define MBOX_REG_SIZE 0x120
--
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
[PATCH v6 4/8] Input: omap4 - Interrupt line configuration
Select correct interrupt line behaviour
Signed-off-by: Abraham Arce
---
drivers/input/keyboard/omap4-keypad.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/input/keyboard/omap4-keypad.c
b/drivers/input/keyboard/omap4-keypad.c
index 2b61f5f..07e792e 100644
--- a/drivers/input/keyboard/omap4-keypad.c
+++ b/drivers/input/keyboard/omap4-keypad.c
@@ -238,7 +238,7 @@ static int __devinit omap4_keypad_probe(struct
platform_device *pdev)
omap4_keypad_config(keypad_data);
error = request_irq(keypad_data->irq, omap4_keypad_interrupt,
-IRQF_TRIGGER_FALLING,
+IRQF_TRIGGER_RISING,
"omap4-keypad", keypad_data);
if (error) {
dev_err(&pdev->dev, "failed to register interrupt\n");
--
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
[PATCH v6 1/8] OMAP4: hwmod data: add keyboard controller
From: Benoit Cousson
Add hwmod data for OMAP4 keyboard controller
taking the following patch as base:
OMAP4: hwmod: Add partial hwmod support for OMAP4430 ES1.0
Signed-off-by: Benoit Cousson
Signed-off-by: Abraham Arce
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 69
1 files changed, 69 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index e20b0ee..c04a04d 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -413,6 +413,72 @@ static struct omap_hwmod omap44xx_mpu_private_hwmod = {
};
/*
+ * 'kbd' class
+ * keyboard controller
+ */
+
+static struct omap_hwmod_class_sysconfig omap44xx_kbd_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
+ SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
+ SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap44xx_kbd_hwmod_class = {
+ .name = "kbd",
+ .sysc = &omap44xx_kbd_sysc,
+};
+
+/* kbd */
+static struct omap_hwmod omap44xx_kbd_hwmod;
+static struct omap_hwmod_irq_info omap44xx_kbd_irqs[] = {
+ { .irq = 120 + OMAP44XX_IRQ_GIC_START },
+};
+
+static struct omap_hwmod_addr_space omap44xx_kbd_addrs[] = {
+ {
+ .pa_start = 0x4a31c000,
+ .pa_end = 0x4a31c07f,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_wkup -> kbd */
+static struct omap_hwmod_ocp_if omap44xx_l4_wkup__kbd = {
+ .master = &omap44xx_l4_wkup_hwmod,
+ .slave = &omap44xx_kbd_hwmod,
+ .clk= "l4_wkup_clk_mux_ck",
+ .addr = omap44xx_kbd_addrs,
+ .addr_cnt = ARRAY_SIZE(omap44xx_kbd_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* kbd slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_kbd_slaves[] = {
+ &omap44xx_l4_wkup__kbd,
+};
+
+static struct omap_hwmod omap44xx_kbd_hwmod = {
+ .name = "kbd",
+ .class = &omap44xx_kbd_hwmod_class,
+ .mpu_irqs = omap44xx_kbd_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_kbd_irqs),
+ .main_clk = "kbd_fck",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_reg = OMAP4430_CM_WKUP_KEYBOARD_CLKCTRL,
+ },
+ },
+ .slaves = omap44xx_kbd_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap44xx_kbd_slaves),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+};
+
+/*
* 'mpu' class
* mpu sub-system
*/
@@ -470,6 +536,9 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
/* mpu_bus class */
&omap44xx_mpu_private_hwmod,
+ /* kbd class */
+ &omap44xx_kbd_hwmod,
+
/* mpu class */
&omap44xx_mpu_hwmod,
NULL,
--
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
[PATCH v6 2/8] Input: omap4 - use platform device helpers
Get mem and irq resources using platform helpers
- platform_get_base
- platform_get_irq
Signed-off-by: Abraham Arce
---
arch/arm/plat-omap/include/plat/omap4-keypad.h |4 +--
drivers/input/keyboard/omap4-keypad.c | 40 +---
2 files changed, 36 insertions(+), 8 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap4-keypad.h
b/arch/arm/plat-omap/include/plat/omap4-keypad.h
index 522a8ab..2b1d9bc 100644
--- a/arch/arm/plat-omap/include/plat/omap4-keypad.h
+++ b/arch/arm/plat-omap/include/plat/omap4-keypad.h
@@ -8,9 +8,7 @@ struct omap4_keypad_platform_data {
u8 rows;
u8 cols;
-
- u16 irq;
- void __iomem *base;
};
+extern int omap4_keyboard_init(struct omap4_keypad_platform_data *);
#endif
diff --git a/drivers/input/keyboard/omap4-keypad.c
b/drivers/input/keyboard/omap4-keypad.c
index 975f8bb..788169d 100644
--- a/drivers/input/keyboard/omap4-keypad.c
+++ b/drivers/input/keyboard/omap4-keypad.c
@@ -148,7 +148,10 @@ static int __devinit omap4_keypad_probe(struct
platform_device *pdev)
const struct omap4_keypad_platform_data *pdata;
struct omap4_keypad *keypad_data;
struct input_dev *input_dev;
+ struct resource *res;
+ resource_size_t size;
unsigned int row_shift, max_keys;
+ int irq;
int error;
/* platform data */
@@ -158,12 +161,14 @@ static int __devinit omap4_keypad_probe(struct
platform_device *pdev)
return -EINVAL;
}
- if (!pdata->base) {
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res) {
dev_err(&pdev->dev, "no base address specified\n");
return -EINVAL;
}
- if (!pdata->irq) {
+ irq = platform_get_irq(pdev, 0);
+ if (!irq) {
dev_err(&pdev->dev, "no keyboard irq assigned\n");
return -EINVAL;
}
@@ -184,9 +189,23 @@ static int __devinit omap4_keypad_probe(struct
platform_device *pdev)
return -ENOMEM;
}
- keypad_data->base = pdata->base;
- keypad_data->irq = pdata->irq;
+ size = resource_size(res);
+
+ res = request_mem_region(res->start, size, pdev->name);
+ if (!res) {
+ dev_err(&pdev->dev, "can't request mem region\n");
+ error = -EBUSY;
+ goto err_free_keypad;
+ }
+ keypad_data->base = ioremap(res->start, resource_size(res));
+ if (!keypad_data->base) {
+ dev_err(&pdev->dev, "can't ioremap mem resource\n");
+ error = -ENOMEM;
+ goto err_release_mem;
+ }
+
+ keypad_data->irq = irq;
keypad_data->row_shift = row_shift;
keypad_data->rows = pdata->rows;
keypad_data->cols = pdata->cols;
@@ -195,7 +214,7 @@ static int __devinit omap4_keypad_probe(struct
platform_device *pdev)
keypad_data->input = input_dev = input_allocate_device();
if (!input_dev) {
error = -ENOMEM;
- goto err_free_keypad;
+ goto err_unmap;
}
input_dev->name = pdev->name;
@@ -243,6 +262,10 @@ err_free_irq:
free_irq(keypad_data->irq, keypad_data);
err_free_input:
input_free_device(input_dev);
+err_unmap:
+ iounmap(keypad_data->base);
+err_release_mem:
+ release_mem_region(res->start, size);
err_free_keypad:
kfree(keypad_data);
return error;
@@ -251,9 +274,16 @@ err_free_keypad:
static int __devexit omap4_keypad_remove(struct platform_device *pdev)
{
struct omap4_keypad *keypad_data = platform_get_drvdata(pdev);
+ struct resource *res;
free_irq(keypad_data->irq, keypad_data);
input_unregister_device(keypad_data->input);
+
+ iounmap(keypad_data->base);
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ release_mem_region(res->start, resource_size(res));
+
kfree(keypad_data);
platform_set_drvdata(pdev, NULL);
--
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
[PATCH v6 3/8] Input: omap4 - SYSCONFIG register configuration
Remove SYSCONFIG register configuration, omap hwmod framework will
use internal API to modify as required
Other minor updates:
- Change a variable name from DEF to VAL, this represents a value
- Break line width to 80 characters
Signed-off-by: Abraham Arce
---
drivers/input/keyboard/omap4-keypad.c | 13 +
1 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/input/keyboard/omap4-keypad.c
b/drivers/input/keyboard/omap4-keypad.c
index 788169d..2b61f5f 100644
--- a/drivers/input/keyboard/omap4-keypad.c
+++ b/drivers/input/keyboard/omap4-keypad.c
@@ -51,17 +51,15 @@
#define OMAP4_KBD_FULLCODE63_320x48
/* OMAP4 bit definitions */
-#define OMAP4_DEF_SYSCONFIG_SOFTRST(1 << 1)
-#define OMAP4_DEF_SYSCONFIG_ENAWKUP(1 << 2)
#define OMAP4_DEF_IRQENABLE_EVENTEN(1 << 0)
#define OMAP4_DEF_IRQENABLE_LONGKEY(1 << 1)
#define OMAP4_DEF_IRQENABLE_TIMEOUTEN (1 << 2)
#define OMAP4_DEF_CTRL_NOSOFTMODE (1 << 1)
#define OMAP4_DEF_CTRLPTVVALUE (1 << 2)
#define OMAP4_DEF_CTRLPTV (1 << 1)
-#define OMAP4_DEF_IRQDISABLE 0x00
/* OMAP4 values */
+#define OMAP4_VAL_IRQDISABLE 0x00
#define OMAP4_VAL_DEBOUNCINGTIME 0x07
#define OMAP4_VAL_FUNCTIONALCFG0x1E
@@ -82,13 +80,11 @@ struct omap4_keypad {
static void __devinit omap4_keypad_config(struct omap4_keypad *keypad_data)
{
- __raw_writel(OMAP4_DEF_SYSCONFIG_SOFTRST | OMAP4_DEF_SYSCONFIG_ENAWKUP,
- keypad_data->base + OMAP4_KBD_SYSCONFIG);
__raw_writel(OMAP4_VAL_FUNCTIONALCFG,
keypad_data->base + OMAP4_KBD_CTRL);
__raw_writel(OMAP4_VAL_DEBOUNCINGTIME,
keypad_data->base + OMAP4_KBD_DEBOUNCINGTIME);
- __raw_writel(OMAP4_DEF_IRQDISABLE,
+ __raw_writel(OMAP4_VAL_IRQDISABLE,
keypad_data->base + OMAP4_KBD_IRQSTATUS);
__raw_writel(OMAP4_DEF_IRQENABLE_EVENTEN | OMAP4_DEF_IRQENABLE_LONGKEY,
keypad_data->base + OMAP4_KBD_IRQENABLE);
@@ -104,11 +100,12 @@ static irqreturn_t omap4_keypad_interrupt(int irq, void
*dev_id)
u32 *new_state = (u32 *) key_state;
/* Disable interrupts */
- __raw_writel(OMAP4_DEF_IRQDISABLE,
+ __raw_writel(OMAP4_VAL_IRQDISABLE,
keypad_data->base + OMAP4_KBD_IRQENABLE);
*new_state = __raw_readl(keypad_data->base + OMAP4_KBD_FULLCODE31_0);
- *(new_state + 1) = __raw_readl(keypad_data->base +
OMAP4_KBD_FULLCODE63_32);
+ *(new_state + 1) = __raw_readl(keypad_data->base
+ + OMAP4_KBD_FULLCODE63_32);
for (row = 0; row < keypad_data->rows; row++) {
changed = key_state[row] ^ keypad_data->key_state[row];
--
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
[PATCH v6 0/8] OMAP4 Keyboard Controller Support
Keyboard controller for OMAP4 includes - built-in scanning algorithm - debouncing feature This patch series is based in already accepted OMAP4 keyboard controller: Linux Input Tree Commit a17f79553f052f04d47689a842118f775f81b7e3 Input: add support for OMAP4 keyboard controller Dependency on hwmod changes for OMAP4: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg28188.html --- v1 http://www.mail-archive.com/linux-omap@vger.kernel.org/msg26502.html Initial Version v2 http://www.mail-archive.com/linux-omap@vger.kernel.org/msg28334.html Vimal.Singh.01 | Signed-off-by missing in patch Vimal.Singh.02 | row/column interpretation in board file Vimal.Singh.03 | 0 element removal in board file Trilok.Soni.01 | hwmod framework in mainline Trilok.Soni.02 | extra brackets in Kconfig Trilok.Soni.03 | default y/n option in Kconfig Trilok.Soni.04 | path/filename in the header of driver Trilok.Soni.05 | static? omap_device_pm_latency in driver Trilok.Soni.06 | input_sync added in driver Trilok.Soni.07 | check error return in all driver Trilok.Soni.08 | keypad_data->input=NULL Felipe.Balbi.01 | platform_driver to know about hwmod and omap_device? Felipe.Balbi.02 | blank line Felipe.Balbi.03 | saving struct device * Felipe.Balbi.04 | platform_data should not be saved Felipe.Balbi.05 | dev_dbg() usage Felipe.Balbi.06 | missing input_sync() Felipe.Balbi.07 | snprintf() usage Felipe.Balbi.08 | omap_hwmod and omap_device location Felipe.Balbi.09 | matrix_keypad_platform_data allocation from platform code Felipe.Balbi.10 | omap_device_build from platform code Felipe.Balbi.11 | registering/configuring call location Kevin.Hillman.01 | Driver Testing Kevin.Hillman.02 | omap_hwmod and omap_device location Dmitry.Torokhov.01 | reason to make omap_keypad_threaded threaded? Dmitry.Torokhov.02 | MATRIX_SCAN_CODE and incorrect values Dmitry.Torokhov.03 | matrix_keypad_platform_data allocation Dmitry.Torokhov.04 | overriding pdata pointer Dmitry.Torokhov.05 | keypad_codes separate allocation Dmitry.Torokhov.06 | keypad_data->base check location Dmitry.Torokhov.07 | keypad_data->irq check location Dmitry.Torokhov.08 | input_dev->keycodemax needed Dmitry.Torokhov.09 | KEY_OK set bit Dmitry.Torokhov.10 | MSC_SCAN report missing Dmitry.Torokhov.11 | input_dev = NULL; Dmitry.Torokhov.12 | free_irq call location in remove function v3 http://www.mail-archive.com/linux-omap@vger.kernel.org/msg29297.html Dmitry.Torokhov | Rework in driver code v4 http://www.mail-archive.com/linux-omap@vger.kernel.org/msg30759.html Felipe.Balbi.01| rows, cols, base and irq definitions Felipe.Balbi.02| device_* calls Felipe.Balbi.03| input device registration before irq enabling Felipe.Balbi.04| kzalloc allocation never to be freed Tony.Lindgren.01 | test in omap2 and omap3 Tony.Lindgren.02 | add cpu_is_omap44xx() Kevin.Hillman.01 | drop device_* calls Kevin.Hillman.01 | use runtime PM API Tomas.Petazzoni.01 | oh_name declaration v5 Basak.Partha.01 | Enable Wakeup patch dependency by Rajendra Basak.Partha.02 | dev_pm_ops dummy functions, avoid .runtime functions Basak.Partha.03 | Remove omap_hwmod_for_each_by_class Basak.Partha.04 | Remove request_mem_region Basak.Partha.04 | Overall PM runtime implementation Benoit.Cousson.01 | Detailed history required Anand.Gadiyar.01 | s/initialization/init for omap4_keypad_initialization It will be renamed to omap4_keyboard_init Anand.Gadiyar.02 | 2 unnecessary line additions Anand.Gadiyar.03 | 1 unnecessary line removal Anand.Gadiyar.04 | Correct interrupt line behaviour in a separate patch Anand.Gadiyar.05 | cpu_is_omap44xx() extra check Sergio.Aguirre.01 | Change sdp4430_keypad_data naming, use keypad_data instead Sergio.Aguirre.02 | Remove unnecessary keypad_data variable Sergio.Aguirre.03 | 2 changes for name/oh_name definition, to be const Sergio.Aguirre.04 | Use sdp4430_keypad_data variable directly Sergio.Aguirre.05 | Add check for return value for WARN(IS_ERR(od)... Manjunatha.GK.01 | Use different subject: OMAP3: hwmod data: add system DMA Manjunatha.GK.02 | change unsigned used for negative number Manjunatha.GK.03 | cpu_is_omap44xx() under CONFIG_ARCH_OMAP4 --- Abraham Arce (5): Input: omap4 - use platform device helpers Input: omap4 - SYSCONFIG register configuration Input: omap4 - Interrupt line configuration OMAP4: Keyboard device registration Input: omap4 - pm runtime Benoit Cousson (1): OMAP4: hwmod data: add keyboard controller Mike Turquette (1): Input: omap4 - Wake-up on events & long presses Syed Rafiuddin (1): OMAP4: Keyboard board support arch/arm/mach-omap2/board-4430sdp.c| 90 arch/arm/mach-omap2/devices.c | 39 ++ arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 69 ++ arch/arm/plat-omap/include/plat/omap4-keypad.h |4 +- drivers/input/keybo
[PATCH 2/3 v5] musb: add musb support for AM35x
AM35x has musb interface and uses CPPI4.1 DMA engine. Current patch supports only PIO mode. DMA support can be added later once basic CPPI4.1 DMA patch is accepted. Also added USB_MUSB_AM35X which is required to differentiate musb ips between OMAP3x and AM35x. This config would be used to for below purposes, - Select am35x.c instead of omap2430.c for compilation at drivers/usb/musb directory. Please note there are significant differneces in these two files as musb ip in quite different on AM35x. - Select workaround codes applicable for AM35x musb issues. one such workaround is for bytewise read issue on AM35x. Signed-off-by: Ajay Kumar Gupta --- Changes from v4: - Added musb->phy_clock which is required to cleanup the clock related stuff. - Renamed few macros - Modified copyright detail as per Sergei's comment. - Made USB_MUSB_AM35X config hidden and also modified it to get selected based on 'default' field. This should allow it to further scale for other boards based on AM35X. - Removed musb->set_clock. drivers/usb/musb/Kconfig | 13 +- drivers/usb/musb/Makefile|4 + drivers/usb/musb/am35x.c | 494 ++ drivers/usb/musb/musb_core.h |1 + 4 files changed, 511 insertions(+), 1 deletions(-) create mode 100644 drivers/usb/musb/am35x.c diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig index 1dd21c2..e345ca9 100644 --- a/drivers/usb/musb/Kconfig +++ b/drivers/usb/musb/Kconfig @@ -60,6 +60,17 @@ comment "OMAP 44xx high speed USB support" comment "Blackfin high speed USB Support" depends on USB_MUSB_HDRC && ((BF54x && !BF544) || (BF52x && !BF522 && !BF523)) +config USB_MUSB_AM35X + bool + depends on USB_MUSB_HDRC + select NOP_USB_XCEIV + default MACH_OMAP3517EVM + help + Select this option if your platform is based on AM35x. As + AM35x has an updated MUSB with CPPI4.1 DMA so this config + is introduced to differentiate musb ip between OMAP3x and + AM35x platforms. + config USB_TUSB6010 boolean "TUSB 6010 support" depends on USB_MUSB_HDRC && !USB_MUSB_SOC @@ -147,7 +158,7 @@ config USB_MUSB_HDRC_HCD config MUSB_PIO_ONLY bool 'Disable DMA (always use PIO)' depends on USB_MUSB_HDRC - default USB_TUSB6010 || ARCH_DAVINCI_DA8XX + default USB_TUSB6010 || ARCH_DAVINCI_DA8XX || USB_MUSB_AM35X help All data is copied between memory and FIFO by the CPU. DMA controllers are ignored. diff --git a/drivers/usb/musb/Makefile b/drivers/usb/musb/Makefile index f664ecf..217363d 100644 --- a/drivers/usb/musb/Makefile +++ b/drivers/usb/musb/Makefile @@ -23,7 +23,11 @@ ifeq ($(CONFIG_ARCH_OMAP2430),y) endif ifeq ($(CONFIG_ARCH_OMAP3430),y) + ifeq ($(CONFIG_USB_MUSB_AM35X),y) + musb_hdrc-objs += am35x.o + else musb_hdrc-objs += omap2430.o + endif endif ifeq ($(CONFIG_ARCH_OMAP4),y) diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c new file mode 100644 index 000..53962a0 --- /dev/null +++ b/drivers/usb/musb/am35x.c @@ -0,0 +1,494 @@ +/* + * Texas Instruments AM35x "glue layer" + * + * Copyright (c) 2010, by Texas Instruments + * + * Based on the DA8xx "glue layer" code. + * Copyright (c) 2008-2009, MontaVista Software, Inc. + * + * This file is part of the Inventra Controller Driver for Linux. + * + * The Inventra Controller Driver for Linux 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. + * + * The Inventra Controller Driver for Linux 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 The Inventra Controller Driver for Linux ; if not, + * write to the Free Software Foundation, Inc., 59 Temple Place, + * Suite 330, Boston, MA 02111-1307 USA + * + */ + +#include +#include +#include + +#include +#include + +#include "musb_core.h" + +/* + * AM35x specific definitions + */ +/* USB 2.0 OTG module registers */ +#define USB_REVISION_REG 0x00 +#define USB_CTRL_REG 0x04 +#define USB_STAT_REG 0x08 +#define USB_EMULATION_REG 0x0c +/* 0x10 Reserved */ +#define USB_AUTOREQ_REG0x14 +#define USB_SRP_FIX_TIME_REG 0x18 +#define USB_TEARDOWN_REG 0x1c +#define EP_INTR_SRC_REG0x20 +#define EP_INTR_SRC_SET_REG0x24 +#define EP_INTR_SRC_CLEAR_REG 0x28 +#define EP_INTR_MASK_REG 0x2c +#define EP_INTR_MASK_SET_REG 0x30 +#define EP_INTR_MASK_CLEAR_REG 0x34 +#define EP_INTR_SR
[PATCH 1/3 v5] AM35x: Add musb support
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
---
Patch set created against latest linus's tree + Felipe's 14 patch set
for v2.6.37.
No change from v4.
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
#include
#include
+#include
#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
#include
+#include
#include
#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.6.2.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
[PATCH 3/3 v5] musb: AM35x: Workaround for fifo read issue
AM35x supports only 32bit read operations so we need to have
workaround for 8bit and 16bit read operations.
Signed-off-by: Ajay Kumar Gupta
---
No logical change from v4.
drivers/usb/musb/am35x.c | 30 ++
drivers/usb/musb/musb_core.c |2 ++
2 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index 53962a0..b0aabf3 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -492,3 +492,33 @@ void musb_platform_restore_context(struct musb *musb,
phy_on();
}
#endif
+
+/* AM35x supports only 32bit read operation */
+void musb_read_fifo(struct musb_hw_ep *hw_ep, u16 len, u8 *dst)
+{
+ void __iomem *fifo = hw_ep->fifo;
+ u32 val;
+ int i;
+
+ /* Read for 32bit-aligned destination address */
+ if (likely((0x03 & (unsigned long) dst) == 0) && len >= 4) {
+ readsl(fifo, dst, len >> 2);
+ dst += len & ~0x03;
+ len &= 0x03;
+ }
+ /*
+* Now read the remaining 1 to 3 byte or complete length if
+* unaligned address.
+*/
+ if (len > 4) {
+ for (i = 0; i < (len >> 2); i++) {
+ *(u32 *) dst = musb_readl(fifo, 0);
+ dst += 4;
+ }
+ len &= 0x03;
+ }
+ if (len > 0) {
+ val = musb_readl(fifo, 0);
+ memcpy(dst, &val, len);
+ }
+}
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 472b2a7..f03a2aa 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -272,6 +272,7 @@ void musb_write_fifo(struct musb_hw_ep *hw_ep, u16 len,
const u8 *src)
}
}
+#if !defined(CONFIG_USB_MUSB_AM35X)
/*
* Unload an endpoint's FIFO
*/
@@ -309,6 +310,7 @@ void musb_read_fifo(struct musb_hw_ep *hw_ep, u16 len, u8
*dst)
readsb(fifo, dst, len);
}
}
+#endif
#endif /* normal PIO */
--
1.6.2.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
[Beagleboard] linux-omap-pm -- cpufreq query
Hi all, Till recently I was working with Angstrom environment for beagleboard (with a linux-omap-pm 2.6.29 kernel) and had to migrate to the latest kernel version possible that is supported by linux-omap-pm branch for non-omap related reasons. I am sticking to linux-omap-pm instead of linux-omap or linux mainlines chiefly because I need cpufreq related functionalities. I was happily using the latest head from linux-omap-pm when I realised that there are no frequency transitions that are occurring now when I initiate requests through sys-fs writes. I found out that OMAP_PM_SRF is no longer supported (which was being used earlier on for helping with cpufreq changes). Is it that one cannot do cpufreq related changes with the current(+/-) linux-omap-pm kernel? I checked linux-omap-pm's head/cpufreq branch for example and it contains only OMAP_PM_NONE and OMAP_PM_NOOP in plat-omap/Kconfig. Are there any changes I can make so that I can get back cpufreq functionality. If yes, is there an general idea as to when this will be available with linux-omap-pm head ? thx, -hari -- 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: Compilation: omap-for-linus omap2plus error
Adding more info to previous email, email account changed On Wed, Sep 29, 2010 at 10:54 PM, Abraham Arce wrote: > Hi, > > Is there any patch missing in omap-for-linus branch? > > CC arch/arm/mach-omap2/pm_bus.o > arch/arm/mach-omap2/pm_bus.c: In function 'omap_pm_runtime_init': > arch/arm/mach-omap2/pm_bus.c:64: error: implicit declaration of function > 'platform_bus_get_pm_ops' > arch/arm/mach-omap2/pm_bus.c:64: warning: assignment makes pointer from > integer without a cast > arch/arm/mach-omap2/pm_bus.c:81: error: implicit declaration of function > 'platform_bus_set_pm_ops' > make[1]: *** [arch/arm/mach-omap2/pm_bus.o] Error 1 > make: *** [arch/arm/mach-omap2] Error 2 > I am trying using following commit as latest Kevin Hilman 7ad0e386d46e9edff64705ab25337ad9130baf63 OMAP2+: defconfig: disable CPUfreq Best Regards Abraham -- 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
Compilation: omap-for-linus omap2plus error
Hi, Is there any patch missing in omap-for-linus branch? CC arch/arm/mach-omap2/pm_bus.o arch/arm/mach-omap2/pm_bus.c: In function 'omap_pm_runtime_init': arch/arm/mach-omap2/pm_bus.c:64: error: implicit declaration of function 'platform_bus_get_pm_ops' arch/arm/mach-omap2/pm_bus.c:64: warning: assignment makes pointer from integer without a cast arch/arm/mach-omap2/pm_bus.c:81: error: implicit declaration of function 'platform_bus_set_pm_ops' make[1]: *** [arch/arm/mach-omap2/pm_bus.o] Error 1 make: *** [arch/arm/mach-omap2] Error 2 Best Regards Abraham -- 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
build error: omap_ctrl_readl and omap_ctrl_writel undefined
I am trying to build the master branch on linux-omap and I am getting the following error on 'make modules' Git log: 2365f1f | Wed, 29 Sep 2010 11:19:10 -0700 | Tony Lindgren | Linux-omap rebuilt: Updated to v2.6.36-rc6, merged in few more patches acc012f | Wed, 29 Sep 2010 11:19:00 -0700 | Tony Lindgren | Merge for-next 11f4559 | Wed, 29 Sep 2010 11:18:58 -0700 | Tony Lindgren | Merge omap-testing 03d0fcb | Wed, 29 Sep 2010 11:18:56 -0700 | Tony Lindgren | Merge omap-fixes cddb52c | Wed, 29 Sep 2010 11:18:54 -0700 | Tony Lindgren | Merge cbu Build error: LD [M] net/wireless/cfg80211.o CC [M] net/wireless/lib80211.o ERROR: "omap_ctrl_writel" [sound/soc/omap/snd-soc-omap-mcbsp.ko] undefined! ERROR: "omap_ctrl_readl" [sound/soc/omap/snd-soc-omap-mcbsp.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 Regards, Venkat. -- 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: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c
* Tony Lindgren [100929 19:10]: > > Then trying to build for omap1 OSK fails with: > > In file included from arch/arm/plat-omap/common.c:35: > arch/arm/plat-omap/include/plat/control.h:20:40: error: > mach/ctrl_module_core_44xx.h: No such file or directory > arch/arm/plat-omap/include/plat/control.h:21:40: error: > mach/ctrl_module_wkup_44xx.h: No such file or directory > arch/arm/plat-omap/include/plat/control.h:22:44: error: > mach/ctrl_module_pad_core_44xx.h: No such file or directory > arch/arm/plat-omap/include/plat/control.h:23:44: error: > mach/ctrl_module_pad_wkup_44xx.h: No such file or directory This seems to be related to Santosh' commit 802edcb7. Santosh, can you do a patch to fix this against the current omap-for-linus branch? 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: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c
* Kevin Hilman [100929 15:15]: > Tony Lindgren writes: > > > * Kevin Hilman [100928 11:25]: > >> Tony, > >> > >> The following pull request will bring hwmod driver conversions for > >> watchdog, UART and i2c drivers. It is based on your omap-for-linus > >> branch. > >> > >> The i2c driver is waiting for final signoff/ack from the upstream > >> subsystem maintainers, but are otherwise ready to go for broader > >> testing. After I get the final ack, I will update the branch for a > >> final pull. > >> > >> In the meantime, I'd like to get them into l-o master (or omap-testing) > >> for broader testing. > > > > Tried pulling it but I'm getting tons of these errors on omap2: > > Tony, > > Can you pull the latest version of my pm-hwmods branch from: > ssh://master.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git > pm-hwmods > > This version has the updated patch from Rajendra for i2c as well as some > UART3 fixes for a problem he noticed on 2430 as well. Getting closer.. Now 2430sdp boots OK. But on N800 (2420) I get the following very early on: ... [0.00] Calibrating delay loop... 318.27 BogoMIPS (lpj=1245184) [0.00] pid_max: default: 32768 minimum: 301 [0.00] Security Framework initialized [0.00] Mount-cache hash table entries: 512 [0.00] CPU: Testing write buffer coherency: ok [0.00] Unhandled fault: imprecise external abort (0xc06) at 0x [0.00] Internal error: : c06 [#1] SMP [0.00] last sysfs file: [0.00] Modules linked in: [0.00] CPU: 0Not tainted (2.6.36-rc6-08801-g332f930 #395) [0.00] PC is at kernel_thread_helper+0x0/0x14 [0.00] LR is at kernel_thread_helper+0x0/0x14 [0.00] pc : []lr : []psr: 0093 [0.00] sp : c7825ff8 ip : fp : [0.00] r10: r9 : r8 : [0.00] r7 : 0013 r6 : c004cca8 r5 : c00a4dc0 r4 : [0.00] r3 : r2 : r1 : r0 : [0.00] Flags: nzcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel [0.00] Control: 00c5387f Table: 80004000 DAC: 0017 [0.00] Process swapper (pid: 2, stack limit = 0xc78242f8) [0.00] Stack: (0xc7825ff8 to 0xc7826000) [0.00] 5fe0: [0.00] [] (kernel_thread_helper+0x0/0x14) from [] (0x) [0.00] Code: c04d9ba8 c04de459 c05ca0a0 c04caf13 (eb01ac97) [0.00] ---[ end trace 1b75b31a2719ed1c ]--- Then trying to build for omap1 OSK fails with: In file included from arch/arm/plat-omap/common.c:35: arch/arm/plat-omap/include/plat/control.h:20:40: error: mach/ctrl_module_core_44xx.h: No such file or directory arch/arm/plat-omap/include/plat/control.h:21:40: error: mach/ctrl_module_wkup_44xx.h: No such file or directory arch/arm/plat-omap/include/plat/control.h:22:44: error: mach/ctrl_module_pad_core_44xx.h: No such file or directory arch/arm/plat-omap/include/plat/control.h:23:44: error: mach/ctrl_module_pad_wkup_44xx.h: No such file or directory > Before this is final, I'm still waiting on two things: > > 1) ack from Ben Dooks for the drivers/i2c change > 2) additional patch from Charu to prevent reset when >CONFIG_OMAP_WATCHDOG=n OK, sounds like we may be able to merge this then after the remaining issues are sorted out. 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: Hang on Suspend to RAM with 2.6.36-rc4
Laine Walker-Avina writes: > On Wed, Sep 22, 2010 at 3:21 PM, Laine Walker-Avina > wrote: >> On Tue, Sep 14, 2010 at 4:02 PM, Kevin Hilman >> wrote: >>> Laine Walker-Avina writes: >>> I just pulled the latest changes today from the linux-omap git tree, and something appears to have broken suspend to RAM on my OMAP3503 board. >>> >>> Is this on the master branch? What defconfig? When was this last >>> working for you? -rc3? >> Yes, on the master branch. I'm using my own config. It was working on >> 2.6.35 or so. I tried backporting my board patches to 2.6.36 and it >> fails there too now for some reason. It might be the SD card, I'll >> have to find another one and try it out. >>> >>> Looks like you may have your rootfs on MMC. Do you have >>> CONFIG_MMC_UNSAFE_RESUME=y in your .config? >> No [...] > > This appears to be caused by commit 4c2ef25f (mmc: fix all hangs > related to mmc/sd card insert/removal during suspend/resume). Enabling > CONFIG_MMC_UNSAFE_RESUME seems to fix it. Good. > Ideally, it would be nice to have the root file-system on a mmc > regardless of whether or not it's removable or not. You'll have to take that one up with the MMC core. I'm sure they would welcome patches to fix it. ;) 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 v3 02/11] OMAP3: PM: Adding voltage driver support for OMAP3
Thara Gopinath writes:
> This patch adds voltage driver support for OMAP3. The driver
> allows configuring the voltage controller and voltage
> processors during init and exports APIs to enable/disable
> voltage processors, scale voltage and reset voltage.
> The driver also maintains the global voltage table on a per
> VDD basis which contains the various voltages supported by the
> VDD along with per voltage dependent data like smartreflex
> n-target value, errminlimit and voltage processor errorgain.
> The driver allows scaling of VDD voltages either through
> "vc bypass method" or through "vp forceupdate method" the
> choice being configurable through the board file.
>
> This patch contains code originally in linux omap pm branch
> smartreflex driver. Major contributors to this driver are
> Lesly A M, Rajendra Nayak, Kalle Jokiniemi, Paul Walmsley,
> Nishant Menon, Kevin Hilman.
>
> Signed-off-by: Thara Gopinath
[...]
> +static void vp_latch_vsel(struct omap_vdd_info *vdd)
> +{
> + u32 vpconfig;
> + unsigned long uvdc;
> + char vsel;
> +
> + uvdc = omap_voltage_get_nom_volt(&vdd->voltdm);
> + if (!uvdc) {
> + pr_warning("%s: unable to find current voltage for vdd_%s\n",
> + __func__, vdd->voltdm.name);
> + return;
> + }
> +
> + if (!volt_pmic_info.uv_to_vsel) {
> + pr_warning("%s: PMIC function to convert voltage in uV to"
> + " vsel not registered\n", __func__);
> + return;
> + }
Should return an error condition to the caller here...
> + vsel = volt_pmic_info.uv_to_vsel(uvdc);
> +
> + vpconfig = voltage_read_reg(vdd->vp_offs.vpconfig);
> + vpconfig &= ~(vdd->vp_reg.vpconfig_initvoltage_mask |
> + vdd->vp_reg.vpconfig_initvdd);
> + vpconfig |= vsel << vdd->vp_reg.vpconfig_initvoltage_shift;
> +
> + voltage_write_reg(vdd->vp_offs.vpconfig, vpconfig);
> +
> + /* Trigger initVDD value copy to voltage processor */
> + voltage_write_reg(vdd->vp_offs.vpconfig,
> + (vpconfig | vdd->vp_reg.vpconfig_initvdd));
> +
> + /* Clear initVDD copy trigger bit */
> + voltage_write_reg(vdd->vp_offs.vpconfig, vpconfig);
> +}
[...]
> +static void __init init_voltageprocessor(struct omap_vdd_info *vdd)
> +{
> + u32 vpconfig;
> +
> + vpconfig = vdd->vp_reg.vpconfig_erroroffset |
> + (vdd->vp_reg.vpconfig_errorgain <<
> + vdd->vp_reg.vpconfig_errorgain_shift) |
> + vdd->vp_reg.vpconfig_timeouten;
> +
> + voltage_write_reg(vdd->vp_offs.vpconfig, vpconfig);
> +
> + voltage_write_reg(vdd->vp_offs.vstepmin,
> + (vdd->vp_reg.vstepmin_smpswaittimemin <<
> + vdd->vp_reg.vstepmin_smpswaittimemin_shift) |
> + (vdd->vp_reg.vstepmin_stepmin <<
> + vdd->vp_reg.vstepmin_stepmin_shift));
> +
> + voltage_write_reg(vdd->vp_offs.vstepmax,
> + (vdd->vp_reg.vstepmax_smpswaittimemax <<
> + vdd->vp_reg.vstepmax_smpswaittimemax_shift) |
> + (vdd->vp_reg.vstepmax_stepmax <<
> + vdd->vp_reg.vstepmax_stepmax_shift));
> +
> + voltage_write_reg(vdd->vp_offs.vlimitto,
> + (vdd->vp_reg.vlimitto_vddmax <<
> + vdd->vp_reg.vlimitto_vddmax_shift) |
> + (vdd->vp_reg.vlimitto_vddmin <<
> + vdd->vp_reg.vlimitto_vddmin_shift) |
> + (vdd->vp_reg.vlimitto_timeout <<
> + vdd->vp_reg.vlimitto_timeout_shift));
> +
> + /* Set the init voltage */
> + vp_latch_vsel(vdd);
On OMAP4/panda, the boot hangs after this.
Since there is no PMIC registered, this call returns early but there is
no error checking done. I think the init needs a little more error
checking and graceful failure, especially when there is no PMIC present.
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: Hang on Suspend to RAM with 2.6.36-rc4
On Wed, Sep 22, 2010 at 3:21 PM, Laine Walker-Avina wrote:
> On Tue, Sep 14, 2010 at 4:02 PM, Kevin Hilman
> wrote:
>> Laine Walker-Avina writes:
>>
>>> I just pulled the latest changes today from the linux-omap git tree,
>>> and something appears to have broken suspend to RAM on my OMAP3503
>>> board.
>>
>> Is this on the master branch? What defconfig? When was this last
>> working for you? -rc3?
> Yes, on the master branch. I'm using my own config. It was working on
> 2.6.35 or so. I tried backporting my board patches to 2.6.36 and it
> fails there too now for some reason. It might be the SD card, I'll
> have to find another one and try it out.
>>
>> Looks like you may have your rootfs on MMC. Do you have
>> CONFIG_MMC_UNSAFE_RESUME=y in your .config?
> No
>>
>> Kevin
>>
>>> Here's a log:
>>>
>>> ~$ echo mem > /sys/power/state
>>> [ 23.102416] PM: Syncing filesystems ... done.
>>> [ 29.493927] PM: Preparing system for mem sleep
>>> [ 29.500396] PM: Adding info for No Bus:vcs63
>>> [ 29.506774] PM: Adding info for No Bus:vcsa63
>>> [ 29.547424] mmc0: card bed5 removed
>>> [ 29.550964] PM: Removing info for mmc:mmc0:bed5
>>> [ 37.001373] INFO: task init:1 blocked for more than 5 seconds.
>>> [ 37.007415] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
>>> disables this message.
>>> [ 37.015472] init D c02a8cb8 0 1 0 0x
>>> [ 37.021942] [] (schedule+0x320/0x368) from []
>>> (do_get_write_access+0x2bc/0x52c)
>>> [ 37.031250] [] (do_get_write_access+0x2bc/0x52c) from
>>> [] (journal_get_write_access+0x24/0x38)
>>> [ 37.041809] [] (journal_get_write_access+0x24/0x38) from
>>> [] (__ext3_journal_get_write_access+0x1c/0x48)
>>> [ 37.053222] []
>>> (__ext3_journal_get_write_access+0x1c/0x48) from []
>>> (ext3_reserve_inode_write+0x3c/0x80)
>>> [ 37.064636] [] (ext3_reserve_inode_write+0x3c/0x80) from
>>> [] (ext3_mark_inode_dirty+0x30/0x54)
>>> [ 37.075164] [] (ext3_mark_inode_dirty+0x30/0x54) from
>>> [] (ext3_dirty_inode+0x68/0x80)
>>> [ 37.084991] [] (ext3_dirty_inode+0x68/0x80) from
>>> [] (__mark_inode_dirty+0x2c/0x188)
>>> [ 37.094665] [] (__mark_inode_dirty+0x2c/0x188) from
>>> [] (touch_atime+0x114/0x140)
>>> [ 37.104064] [] (touch_atime+0x114/0x140) from
>>> [] (generic_file_aio_read+0x6e8/0x76c)
>>> [ 37.113830] [] (generic_file_aio_read+0x6e8/0x76c) from
>>> [] (do_sync_read+0xa0/0xe8)
>>> [ 37.123474] [] (do_sync_read+0xa0/0xe8) from []
>>> (vfs_read+0xa8/0x130)
>>> [ 37.131896] [] (vfs_read+0xa8/0x130) from []
>>> (sys_read+0x3c/0x68)
>>> [ 37.139984] [] (sys_read+0x3c/0x68) from []
>>> (ret_fast_syscall+0x0/0x3c)
>>> [ 37.148559] 1 lock held by init/1:
>>> [ 37.152008] #0: (jbd_handle){+.+...}, at: []
>>> start_this_handle+0x314/0x3c8
>>> [ 37.160247] INFO: task mmcqd:320 blocked for more than 5 seconds.
>>> [ 37.166534] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
>>> disables this message.
>>> [ 37.174560] mmcqd D c02a8cb8 0 320 2 0x
>>> [ 37.181030] [] (schedule+0x320/0x368) from []
>>> (__mmc_claim_host+0xbc/0x158)
>>> [ 37.190002] [] (__mmc_claim_host+0xbc/0x158) from
>>> [] (mmc_blk_issue_rw_rq+0x38/0x504)
>>> [ 37.199829] [] (mmc_blk_issue_rw_rq+0x38/0x504) from
>>> [] (mmc_queue_thread+0xdc/0xe0)
>>> [ 37.209564] [] (mmc_queue_thread+0xdc/0xe0) from
>>> [] (kthread+0x80/0x88)
>>> [ 37.218200] [] (kthread+0x80/0x88) from []
>>> (kernel_thread_exit+0x0/0x8)
>>> [ 37.226776] no locks held by mmcqd/320.
>>> [ 37.230682] INFO: task sh:363 blocked for more than 5 seconds.
>>> [ 37.236694] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
>>> disables this message.
>>> [ 37.244720] sh D c02a8cb8 0 363 1 0x
>>> [ 37.251220] [] (schedule+0x320/0x368) from []
>>> (log_wait_commit+0xb8/0x110)
>>> [ 37.260101] [] (log_wait_commit+0xb8/0x110) from
>>> [] (ext3_sync_fs+0x3c/0x44)
>>> [ 37.269134] [] (ext3_sync_fs+0x3c/0x44) from []
>>> (__sync_filesystem+0x80/0x9c)
>>> [ 37.278289] [] (__sync_filesystem+0x80/0x9c) from
>>> [] (fsync_bdev+0x18/0x38)
>>> [ 37.287261] [] (fsync_bdev+0x18/0x38) from []
>>> (invalidate_partition+0x18/0x34)
>>> [ 37.296478] [] (invalidate_partition+0x18/0x34) from
>>> [] (del_gendisk+0x28/0xd0)
>>> [ 37.305786] [] (del_gendisk+0x28/0xd0) from []
>>> (mmc_blk_remove+0x20/0x40)
>>> [ 37.314575] [] (mmc_blk_remove+0x20/0x40) from
>>> [] (mmc_bus_remove+0x18/0x20)
>>> [ 37.323608] [] (mmc_bus_remove+0x18/0x20) from
>>> [] (__device_release_driver+0x84/0xd0)
>>> [ 37.333435] [] (__device_release_driver+0x84/0xd0) from
>>> [] (device_release_driver+0x20/0x2c)
>>> [ 37.343902] [] (device_release_driver+0x20/0x2c) from
>>> [] (bus_remove_device+0xa4/0xb4)
>>> [ 37.353820] [] (bus_remove_device+0xa4/0xb4) from
>>> [] (device_del+0x114/0x194)
>>> [ 37.362945] [] (device_del+0x114/0x194) from []
>>> (mmc_remove_card+0x5c/0x70)
>>> [ 37.371917] [] (mmc_remove_card+0x5c/0x70) from
>>> []
RE: [PATCH v2 03/10] OMAP: mach-omap2: Fix static function warnings
Hi Paul,
> -Original Message-
> From: Paul Walmsley [mailto:p...@pwsan.com]
> Sent: Thursday, September 30, 2010 3:06 AM
> To: G, Manjunath Kondaiah
> Cc: linux-omap@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; Tony Lindgren; Menon, Nishanth
> Subject: Re: [PATCH v2 03/10] OMAP: mach-omap2: Fix static
> function warnings
>
> Hello Manjunath,
>
> one comment:
>
> On Tue, 21 Sep 2010, G, Manjunath Kondaiah wrote:
>
> > arch/arm/mach-omap2/powerdomain.c | 28
>
> > 12 files changed, 27 insertions(+), 47 deletions(-) create mode
> > 100644 arch/arm/mach-omap2/include/mach/board-rx51.h
> >
> > diff --git a/arch/arm/mach-omap2/powerdomain.c
> > b/arch/arm/mach-omap2/powerdomain.c
> > index 6527ec3..6e51079 100644
> > --- a/arch/arm/mach-omap2/powerdomain.c
> > +++ b/arch/arm/mach-omap2/powerdomain.c
> > @@ -981,34 +981,6 @@ bool pwrdm_has_hdwr_sar(struct powerdomain
> > *pwrdm) }
> >
> > /**
> > - * pwrdm_set_lowpwrstchange - Request a low power state change
> > - * @pwrdm: struct powerdomain *
> > - *
> > - * Allows a powerdomain to transtion to a lower power sleep state
> > - * from an existing sleep state without waking up the powerdomain.
> > - * Returns -EINVAL if the powerdomain pointer is null or if the
> > - * powerdomain does not support LOWPOWERSTATECHANGE, or returns 0
> > - * upon success.
> > - */
> > -int pwrdm_set_lowpwrstchange(struct powerdomain *pwrdm) -{
> > - if (!pwrdm)
> > - return -EINVAL;
> > -
> > - if (!(pwrdm->flags & PWRDM_HAS_LOWPOWERSTATECHANGE))
> > - return -EINVAL;
> > -
> > - pr_debug("powerdomain: %s: setting LOWPOWERSTATECHANGE bit\n",
> > -pwrdm->name);
> > -
> > - prm_rmw_mod_reg_bits(OMAP4430_LOWPOWERSTATECHANGE_MASK,
> > -(1 << OMAP4430_LOWPOWERSTATECHANGE_SHIFT),
> > -pwrdm->prcm_offs, pwrstctrl_reg_offs);
> > -
> > - return 0;
> > -}
> > -
>
> Please don't delete this function. It will be needed for
> OMAP4 power management. Instead, just add a prototype in
> plat-omap/include/plat/powerdomains.h.
Thanks. Taken care with new pull request sent to tony.
-Manjunath
--
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: [GIT PULL] omap2 sparse fixes
> -Original Message- > From: Tony Lindgren [mailto:t...@atomide.com] > Sent: Thursday, September 30, 2010 3:27 AM > To: G, Manjunath Kondaiah > Cc: linux-omap@vger.kernel.org; > linux-arm-ker...@lists.infradead.org; Samuel Ortiz; Dmitry > Torokhov; linux-...@lists.infradead.org; Russell King - ARM Linux > Subject: Re: [GIT PULL] omap2 sparse fixes > > * G, Manjunath Kondaiah [100929 12:42]: > > > > Tony, > > > > > -Original Message- > > > From: Tony Lindgren [mailto:t...@atomide.com] > > > Sent: Wednesday, September 29, 2010 12:02 AM > > > To: G, Manjunath Kondaiah > > > Cc: linux-omap@vger.kernel.org; > > > linux-arm-ker...@lists.infradead.org; Samuel Ortiz; > Dmitry Torokhov; > > > linux-...@lists.infradead.org; Russell King - ARM Linux > > > Subject: Re: [GIT PULL] omap2 sparse fixes > > > > > > * G, Manjunath Kondaiah [100928 08:26]: > > ... > > > > > Yes please take out all patches that are not in > arch/arm/*omap*/ path. > > > The others really should go to the driver maintainers. > > > > > > Tony > > > > Here is new branch which has only arch/arm/*omap*/ related patches. > > Thanks. Noticed one more thing though: > > In your patch "OMAP: mach-omap2: Fix static function > warnings" looks like you're adding > omap2_gp_clockevent_set_gptimer twice: Sorry I missed removing this while adding it in timer-gp.h. Also, I noticed in the same patch, the board_nand_init nd board_flash_init functions are exported thrgough board-flash.h. I moved board-flash.h from mach/board-flash.h to mach-omap2/board-flash.h so that only board files can access these functions. > > --- a/arch/arm/plat-omap/include/plat/timer-gp.h > +++ b/arch/arm/mach-omap2/timer-gp.h > @@ -11,7 +11,6 @@ > #ifndef __ARCH_ARM_PLAT_OMAP_INCLUDE_MACH_TIMER_GP_H > #define __ARCH_ARM_PLAT_OMAP_INCLUDE_MACH_TIMER_GP_H > > -int __init omap2_gp_clockevent_set_gptimer(u8 id); > +extern int __init omap2_gp_clockevent_set_gptimer(u8 id); > > #endif > - > --- a/arch/arm/plat-omap/include/plat/dmtimer.h > +++ b/arch/arm/plat-omap/include/plat/dmtimer.h > @@ -81,6 +81,6 @@ unsigned int > omap_dm_timer_read_counter(struct omap_dm_timer *timer); > void omap_dm_timer_write_counter(struct omap_dm_timer *timer, > unsigned int value); > > int omap_dm_timers_active(void); > - > +int omap2_gp_clockevent_set_gptimer(u8 id); Removed. > > #endif /* __ASM_ARCH_DMTIMER_H */ > > Please also be careful that your branch contains the same > patches as you've posted for review. Nobody wants to pull > different stuff than what was posted! Also looks like Paul > had one comment related to the same patch. Patches are same except pulling out twl and driver patches from the series. Paul's comment is addressed and changes are pushed to git branch. Build tested with omap3_defconfig and boot tested with beagle board. The following changes since commit 899611ee7d373e5eeda08e9a8632684e1ebbbf00: Linus Torvalds (1): Linux 2.6.36-rc6 are available in the git repository at: git://dev.omapzoom.org/pub/scm/manju/kernel-omap3-dev.git omap_sparse_fixesv2 G, Manjunath Kondaiah (7): OMAP: mach-omap2: Fix incorrect assignment warnings OMAP: mach-omap2: Fix static declaration warnings OMAP2plus: Fix static function warnings OMAP: mach-omap2: Fix miscellaneous sparse warnings OMAP: plat-omap: Fix static function warnings OMAP: Convert write/read functions to raw read/write OMAP3: Keypad: Fix incorrect type initializer -Manjunath -- 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 08/11] OMAP3: PM: Adding debug support to Voltage and Smartreflex drivers
Thara Gopinath writes: [...] > diff --git a/arch/arm/plat-omap/include/plat/voltage.h > b/arch/arm/plat-omap/include/plat/voltage.h > index 99836a1..8978d33 100644 > --- a/arch/arm/plat-omap/include/plat/voltage.h > +++ b/arch/arm/plat-omap/include/plat/voltage.h > @@ -14,6 +14,11 @@ > #ifndef __ARCH_ARM_MACH_OMAP2_VOLTAGE_H > #define __ARCH_ARM_MACH_OMAP2_VOLTAGE_H > > +extern u32 enable_sr_vp_debug; > +#ifdef CONFIG_PM_DEBUG > +extern struct dentry *pm_dbg_main_dir; > +#endif > + > #define VOLTSCALE_VPFORCEUPDATE 1 > #define VOLTSCALE_VCBYPASS 2 This belongs in PATCH 1/11 and belongs in pm.h, not voltage.h as it's a feature of the PM debug layer, not the voltage layer. 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 v3 07/11] OMAP3: PM: Adding T2 enabling of smartreflex support
"Gopinath, Thara" writes: >>>Thara Gopinath writes: >>> This patch adds support in the twl4030 driver to hook up the API enabling smartreflex support on PMIC side with the smartreflex driver. Without this the OMAP smartreflex modules will not function. Signed-off-by: Thara Gopinath >>> >>>This one should be a separate patch with a subject something like >>> >>> mfd: twl4030: add SmartReflex support >>> >>>and the changelog should indicate its dependency on this SR/voltage >>>series. > > Do you mean to say this patch should not be a part of this series at all ?? > Yes, as it will need to be merged via the mfd tree once the SR core is merged. 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] OMAP: PM: CPUFREQ: Fix conditional compilation
Silesh C V writes: > Fix conditional compilation. A conditional expresiion > should follow "#elif", in this case #elif clause should > check whether CONFIG_ARCH_OMAP3 is defined or not > (ie. defined(CONFIG_ARCH_OMAP3)) rather than checking for > the value of the macro. > > Signed-off-by: Silesh C V OK, applied to the pm-cpufreq sub-branch of the PM branch. Kevin > --- > arch/arm/plat-omap/cpu-omap.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/arch/arm/plat-omap/cpu-omap.c b/arch/arm/plat-omap/cpu-omap.c > index df08829..02e4865 100644 > --- a/arch/arm/plat-omap/cpu-omap.c > +++ b/arch/arm/plat-omap/cpu-omap.c > @@ -41,7 +41,7 @@ static struct cpufreq_frequency_table *freq_table; > > #ifdef CONFIG_ARCH_OMAP1 > #define MPU_CLK "mpu" > -#elif CONFIG_ARCH_OMAP3 > +#elif defined(CONFIG_ARCH_OMAP3) > #define MPU_CLK "arm_fck" > #else > #define MPU_CLK "virt_prcm_set" -- 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: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c
Tony Lindgren writes: > * Kevin Hilman [100928 11:25]: >> Tony, >> >> The following pull request will bring hwmod driver conversions for >> watchdog, UART and i2c drivers. It is based on your omap-for-linus >> branch. >> >> The i2c driver is waiting for final signoff/ack from the upstream >> subsystem maintainers, but are otherwise ready to go for broader >> testing. After I get the final ack, I will update the branch for a >> final pull. >> >> In the meantime, I'd like to get them into l-o master (or omap-testing) >> for broader testing. > > Tried pulling it but I'm getting tons of these errors on omap2: Tony, Can you pull the latest version of my pm-hwmods branch from: ssh://master.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git pm-hwmods This version has the updated patch from Rajendra for i2c as well as some UART3 fixes for a problem he noticed on 2430 as well. Before this is final, I'm still waiting on two things: 1) ack from Ben Dooks for the drivers/i2c change 2) additional patch from Charu to prevent reset when CONFIG_OMAP_WATCHDOG=n 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: [GIT PULL] omap2 sparse fixes
* G, Manjunath Kondaiah [100929 12:42]: > > Tony, > > > -Original Message- > > From: Tony Lindgren [mailto:t...@atomide.com] > > Sent: Wednesday, September 29, 2010 12:02 AM > > To: G, Manjunath Kondaiah > > Cc: linux-omap@vger.kernel.org; > > linux-arm-ker...@lists.infradead.org; Samuel Ortiz; Dmitry > > Torokhov; linux-...@lists.infradead.org; Russell King - ARM Linux > > Subject: Re: [GIT PULL] omap2 sparse fixes > > > > * G, Manjunath Kondaiah [100928 08:26]: > ... > > > Yes please take out all patches that are not in arch/arm/*omap*/ path. > > The others really should go to the driver maintainers. > > > > Tony > > Here is new branch which has only arch/arm/*omap*/ related patches. Thanks. Noticed one more thing though: In your patch "OMAP: mach-omap2: Fix static function warnings" looks like you're adding omap2_gp_clockevent_set_gptimer twice: --- a/arch/arm/plat-omap/include/plat/timer-gp.h +++ b/arch/arm/mach-omap2/timer-gp.h @@ -11,7 +11,6 @@ #ifndef __ARCH_ARM_PLAT_OMAP_INCLUDE_MACH_TIMER_GP_H #define __ARCH_ARM_PLAT_OMAP_INCLUDE_MACH_TIMER_GP_H -int __init omap2_gp_clockevent_set_gptimer(u8 id); +extern int __init omap2_gp_clockevent_set_gptimer(u8 id); #endif - --- a/arch/arm/plat-omap/include/plat/dmtimer.h +++ b/arch/arm/plat-omap/include/plat/dmtimer.h @@ -81,6 +81,6 @@ unsigned int omap_dm_timer_read_counter(struct omap_dm_timer *timer); void omap_dm_timer_write_counter(struct omap_dm_timer *timer, unsigned int value); int omap_dm_timers_active(void); - +int omap2_gp_clockevent_set_gptimer(u8 id); #endif /* __ASM_ARCH_DMTIMER_H */ Please also be careful that your branch contains the same patches as you've posted for review. Nobody wants to pull different stuff than what was posted! Also looks like Paul had one comment related to the same patch. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 03/10] OMAP: mach-omap2: Fix static function warnings
Hello Manjunath,
one comment:
On Tue, 21 Sep 2010, G, Manjunath Kondaiah wrote:
> arch/arm/mach-omap2/powerdomain.c | 28
>
> 12 files changed, 27 insertions(+), 47 deletions(-)
> create mode 100644 arch/arm/mach-omap2/include/mach/board-rx51.h
>
> diff --git a/arch/arm/mach-omap2/powerdomain.c
> b/arch/arm/mach-omap2/powerdomain.c
> index 6527ec3..6e51079 100644
> --- a/arch/arm/mach-omap2/powerdomain.c
> +++ b/arch/arm/mach-omap2/powerdomain.c
> @@ -981,34 +981,6 @@ bool pwrdm_has_hdwr_sar(struct powerdomain *pwrdm)
> }
>
> /**
> - * pwrdm_set_lowpwrstchange - Request a low power state change
> - * @pwrdm: struct powerdomain *
> - *
> - * Allows a powerdomain to transtion to a lower power sleep state
> - * from an existing sleep state without waking up the powerdomain.
> - * Returns -EINVAL if the powerdomain pointer is null or if the
> - * powerdomain does not support LOWPOWERSTATECHANGE, or returns 0
> - * upon success.
> - */
> -int pwrdm_set_lowpwrstchange(struct powerdomain *pwrdm)
> -{
> - if (!pwrdm)
> - return -EINVAL;
> -
> - if (!(pwrdm->flags & PWRDM_HAS_LOWPOWERSTATECHANGE))
> - return -EINVAL;
> -
> - pr_debug("powerdomain: %s: setting LOWPOWERSTATECHANGE bit\n",
> - pwrdm->name);
> -
> - prm_rmw_mod_reg_bits(OMAP4430_LOWPOWERSTATECHANGE_MASK,
> - (1 << OMAP4430_LOWPOWERSTATECHANGE_SHIFT),
> - pwrdm->prcm_offs, pwrstctrl_reg_offs);
> -
> - return 0;
> -}
> -
Please don't delete this function. It will be needed for OMAP4 power
management. Instead, just add a prototype in
plat-omap/include/plat/powerdomains.h.
- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 02/11] OMAP3: PM: Adding voltage driver support for OMAP3
Thara Gopinath writes:
> This patch adds voltage driver support for OMAP3. The driver
> allows configuring the voltage controller and voltage
> processors during init and exports APIs to enable/disable
> voltage processors, scale voltage and reset voltage.
> The driver also maintains the global voltage table on a per
> VDD basis which contains the various voltages supported by the
> VDD along with per voltage dependent data like smartreflex
> n-target value, errminlimit and voltage processor errorgain.
> The driver allows scaling of VDD voltages either through
> "vc bypass method" or through "vp forceupdate method" the
> choice being configurable through the board file.
>
> This patch contains code originally in linux omap pm branch
> smartreflex driver. Major contributors to this driver are
> Lesly A M, Rajendra Nayak, Kalle Jokiniemi, Paul Walmsley,
> Nishant Menon, Kevin Hilman.
>
> Signed-off-by: Thara Gopinath
[...]
> +static void __init vdd_data_configure(struct omap_vdd_info *vdd)
> +{
> + if (cpu_is_omap34xx())
> + omap3_vdd_data_configure(vdd);
> +}
> +
> +static void __init init_voltagecontroller(void)
> +{
> + if (cpu_is_omap34xx())
> + omap3_init_voltagecontroller();
> +}
Drop these two functions...
[...]
> +/**
> + * omap_voltage_init : Volatage init API which does VP and VC init.
> + */
> +static int __init omap_voltage_init(void)
> +{
> + int i;
...and setup function pointers in these cpu_is checks. Something like
the below (not even compile tested.)
void (*vdd_data_configure)(void);
void (*init_voltageprocessor)(void);
> +
> + if (cpu_is_omap34xx()) {
> + volt_mod = OMAP3430_GR_MOD;
> + vdd_info = omap3_vdd_info;
> + nr_scalable_vdd = OMAP3_NR_SCALABLE_VDD;
vdd_data_configure = omap3_vdd_data_configure;
init_voltageprocessor = omap3_init_voltageprocessor;
> + } else {
> + pr_warning("%s: voltage driver support not added\n", __func__);
> + return 0;
> + }
> + init_voltagecontroller();
> + for (i = 0; i < nr_scalable_vdd; i++) {
> + vdd_data_configure(&vdd_info[i]);
> + init_voltageprocessor(&vdd_info[i]);
> + }
> + return 0;
> +}
> +core_initcall(omap_voltage_init);
We really want to minimize the cpu_is_* checks, and ideally they should
only be present in the first __init function.
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
[PATCH v4 1/5] OMAP2xxx: hwmod: add I2C hwmods for OMAP2420, 2430
From: Paul Walmsley
Add hwmod structures for I2C controllers on OMAP2420/2430.
Signed-off-by: Paul Walmsley
Signed-off-by: Rajendra Nayak
Cc: Kevin Hilman
---
v4 contains fixes for issues reported here
http://marc.info/?l=linux-omap&m=128570513206195&w=2
arch/arm/mach-omap2/cm-regbits-24xx.h |4 +
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 142 +-
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 156 +++-
3 files changed, 298 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/cm-regbits-24xx.h
b/arch/arm/mach-omap2/cm-regbits-24xx.h
index da51cc3..9a106c0 100644
--- a/arch/arm/mach-omap2/cm-regbits-24xx.h
+++ b/arch/arm/mach-omap2/cm-regbits-24xx.h
@@ -126,8 +126,12 @@
#define OMAP24XX_ST_HDQ_MASK (1 << 23)
#define OMAP2420_ST_I2C2_SHIFT 20
#define OMAP2420_ST_I2C2_MASK (1 << 20)
+#define OMAP2430_ST_I2CHS1_SHIFT 19
+#define OMAP2430_ST_I2CHS1_MASK(1 << 19)
#define OMAP2420_ST_I2C1_SHIFT 19
#define OMAP2420_ST_I2C1_MASK (1 << 19)
+#define OMAP2430_ST_I2CHS2_SHIFT 20
+#define OMAP2430_ST_I2CHS2_MASK(1 << 20)
#define OMAP24XX_ST_MCBSP2_SHIFT 16
#define OMAP24XX_ST_MCBSP2_MASK(1 << 16)
#define OMAP24XX_ST_MCBSP1_SHIFT 15
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index 3cc768e..25d6da2 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -15,9 +15,12 @@
#include
#include
#include
+#include
+#include
#include "omap_hwmod_common_data.h"
+#include "cm-regbits-24xx.h"
#include "prm-regbits-24xx.h"
/*
@@ -71,6 +74,8 @@ static struct omap_hwmod omap2420_l3_main_hwmod = {
};
static struct omap_hwmod omap2420_l4_wkup_hwmod;
+static struct omap_hwmod omap2420_i2c1_hwmod;
+static struct omap_hwmod omap2420_i2c2_hwmod;
/* L4_CORE -> L4_WKUP interface */
static struct omap_hwmod_ocp_if omap2420_l4_core__l4_wkup = {
@@ -79,6 +84,45 @@ static struct omap_hwmod_ocp_if omap2420_l4_core__l4_wkup = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* I2C IP block address space length (in bytes) */
+#define OMAP2_I2C_AS_LEN 128
+
+/* L4 CORE -> I2C1 interface */
+static struct omap_hwmod_addr_space omap2420_i2c1_addr_space[] = {
+ {
+ .pa_start = 0x4807,
+ .pa_end = 0x4807 + OMAP2_I2C_AS_LEN - 1,
+ .flags = ADDR_TYPE_RT,
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2420_l4_core__i2c1 = {
+ .master = &omap2420_l4_core_hwmod,
+ .slave = &omap2420_i2c1_hwmod,
+ .clk= "i2c1_ick",
+ .addr = omap2420_i2c1_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap2420_i2c1_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* L4 CORE -> I2C2 interface */
+static struct omap_hwmod_addr_space omap2420_i2c2_addr_space[] = {
+ {
+ .pa_start = 0x48072000,
+ .pa_end = 0x48072000 + OMAP2_I2C_AS_LEN - 1,
+ .flags = ADDR_TYPE_RT,
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2420_l4_core__i2c2 = {
+ .master = &omap2420_l4_core_hwmod,
+ .slave = &omap2420_i2c2_hwmod,
+ .clk= "i2c2_ick",
+ .addr = omap2420_i2c2_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap2420_i2c2_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* Slave interfaces on the L4_CORE interconnect */
static struct omap_hwmod_ocp_if *omap2420_l4_core_slaves[] = {
&omap2420_l3_main__l4_core,
@@ -87,6 +131,8 @@ static struct omap_hwmod_ocp_if *omap2420_l4_core_slaves[] =
{
/* Master interfaces on the L4_CORE interconnect */
static struct omap_hwmod_ocp_if *omap2420_l4_core_masters[] = {
&omap2420_l4_core__l4_wkup,
+ &omap2420_l4_core__i2c1,
+ &omap2420_l4_core__i2c2
};
/* L4 CORE */
@@ -165,12 +211,106 @@ static struct omap_hwmod omap2420_iva_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420)
};
+/* I2C common */
+static struct omap_hwmod_class_sysconfig i2c_sysc = {
+ .rev_offs = 0x00,
+ .sysc_offs = 0x20,
+ .syss_offs = 0x10,
+ .sysc_flags = SYSC_HAS_SOFTRESET,
+ .sysc_fields= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class i2c_class = {
+ .name = "i2c",
+ .sysc = &i2c_sysc,
+};
+
+static struct omap_i2c_dev_attr i2c_dev_attr;
+
+/* I2C1 */
+
+static struct omap_hwmod_irq_info i2c1_mpu_irqs[] = {
+ { .irq = INT_24XX_I2C1_IRQ, },
+};
+
+st
Re: [PATCH 05/13] OMAP: Introduce device specific set rate and get rate in device opp structures.
Hi Thara, On 9/29/2010 1:16 PM, Gopinath, Thara wrote: -Original Message- From: Cousson, Benoit Sent: Saturday, September 18, 2010 3:43 PM To: Gopinath, Thara Cc: Kevin Hilman; Paul Walmsley; linux-omap@vger.kernel.org; Sripathy, Vishwanath; Sawant, Anand Subject: Re: [PATCH 05/13] OMAP: Introduce device specific set rate and get rate in device opp structures. Hi Thara, On 9/17/2010 4:55 PM, Gopinath, Thara wrote: From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Thursday, September 16, 2010 8:58 PM "Gopinath, Thara" writes: From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Friday, September 03, 2010 5:12 AM Thara Gopinath writes: This patch extends the device opp structure to contain pointers to scale the operating rate of the device and to retrieve the operating rate of the device. This patch also adds the three new APIs in the opp layer namely opp_set_rate that can be called to set a new operating rate for a device, opp_get_rate that can be called to retrieve the operating frequency for a device and opp_populate_rate_fns to populte the device specific set_rate and get_rate API's. The opp_set_rate and opp_get_rate does some routine error checks and finally calls into the device specific set_rate and get_rate APIs populated through opp_populate_rate_fns. Signed-off-by: Thara Gopinath As I think about this more, I'm not sure the OPP layer is the right layer for the get/set rate functions. The OPP layer is currently just the data store for OPP data. To me, these set/get functions are better associated directly with an omap_device instead of an OPP. For instance, the new OPP APIs are a bit confusing in terms of OPPs. e.g: opp_get_rate(). What is the "rate" of an OPP, and what's the difference with opp_get_freq()? What's really happening is the rate is being changed for a device, and the need for specific hooks are at the device level, not the OPP level. For example, this current approach would not scale if you needed multiple devices in the same domain that each needed custom set_rate/get_rate hooks. So instead, what about adding custom hooks at the omap_device level? They could be registered at omap_device_build() time in the device specific code. This is exactly what I had in my mind when I started implementing this. But then Paul said hwmod or omap_device is not the place to keep it. IIRC, Paul's concern was that *hwmod* was not the right place for this (and I agree.) However, I think omap_device is the right place for this. Paul? Also I do not want the set rate get rate APIs for devices that require changes dividers in the PRCM clock module to be spread out in the system. Makes it very very difficult to debug. If we agree to add the set_rate and get_rate in the omap_device structure, I would like to have one more API in the omap_device layer to register these APIs device wise. Thus we can keep these set rate and get rate APIs in one single file. Agreed. And those functions should be in the respective device-specific file, where the omap_device_build() etc are done for that device. Hello Kevin, I basically agree with all your other suggestions except this. I do not think device files are the correct place for this. For starters definitely mpu, l3 and iva devices are not built from any device file. I do not like the idea of device set rate APIs spread across different files. I don't not understand the reason? If we need to add specific device function for mpu, l3, or iva, we can easily add a file to contain that. BTW, thanks to work done by Santosh and Felipe we will probably soon introduce a l3 driver that will allow to handle interconnect errors. We will thus have a real device for l3 as well. A device set_rate is clearly device specific. If a device will have to play with its own internal dividers along with PRCM dividers, that code still belong to the device. I do not see the need nor the advantage to centralize that? You will end-up with a huge file that every driver owners will have to hack in order to add set_rate support for their device. At device build time, IP with set_rate support will just add non-null parameters to the omap_device_build(), et voila. For the debug point of view, you can just add a new sysfs entry for scalable devices that will allow you to track scalable device vs regular ones. Hello Benoit/Kevin, Most of the devices need not scale any internal dividers. For devices that need to scale internal dividers, I agree that the set_rate and get_rate should come from the devices file. But for other devices that involve only PRCM dividers, I do not think they should be bothered with implementing these APIs and maintaining them. But why? For dividers under PRCM control, we do have clock nodes to control them, so device can still use them. I'm still missing your point about centralizing that. Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a me
Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c
"Nayak, Rajendra" writes:
[...]
>> > Btw, the WARN's come only for UART3 and the error at hwmod init shows that
>> > maybe _wait_target_ready fails.
>> >
>> > [0.00] NR_IRQS:402
>> > [0.00] Clocking rate (Crystal/DPLL/MPU): 13.0/660/330 MHz
>> > [0.00] omap_hwmod: uart3: cannot be enabled (3)
>> >
>>
>> UART3 on 24xx is in CM_IDLEST2_CORE, and the 2430 hwmod data has it in
>> CM_IDLEST1_CORE.
>>
>> Can you test the change below? I don't have a 2430, and it appears that
>> this is already correct in the 2420 hwmod data.
>>
>> Kevin
>>
>>
>> diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
>> b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
>> index 92f4ec0..5b61f7c 100644
>> --- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
>> +++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
>> @@ -449,9 +449,9 @@ static struct omap_hwmod omap2430_uart3_hwmod = {
>> .prcm = {
>> .omap2 = {
>> .module_offs = CORE_MOD,
>> -.prcm_reg_id = 1,
>> +.prcm_reg_id = 2,
>> .module_bit = OMAP24XX_EN_UART3_SHIFT,
>> -.idlest_reg_id = 1,
>> +.idlest_reg_id = 2,
>> .idlest_idle_bit = OMAP24XX_EN_UART3_SHIFT,
>> },
>> },
>
> This does seem to fix the issue on 2430. I don't see the error at hwmod init
> or the WARN's later.
Thanks for testing Rajendra,
I'll fold this into the UART hwmod data for OMAP2 since that was
originally done by me, not Govindraj.
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: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c
> -Original Message-
> From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
> Sent: Thursday, September 30, 2010 1:11 AM
> To: Nayak, Rajendra
> Cc: Raja, Govindraj; Tony Lindgren; linux-omap@vger.kernel.org; Varadarajan,
> Charulatha
> Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog,
> UART, i2c
>
> "Nayak, Rajendra" writes:
>
> >> -Original Message-
> >> From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
> >> Sent: Thursday, September 30, 2010 12:49 AM
> >> To: Nayak, Rajendra; Raja, Govindraj
> >> Cc: Tony Lindgren; linux-omap@vger.kernel.org; Varadarajan, Charulatha
> >> Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions:
> >> watchdog, UART, i2c
> >>
> >> "Nayak, Rajendra" writes:
> >>
> >> [...]
> >>
> >> >
> >> > I forgot to mention, there are similar WARN's that I see on 2430sdp even
> >> > with UART
> >> >
> >>
> >> Govidraj, can you look into these UART issues please?
> >>
> >> Looks like you might need to double check the bitfields and the
> >> module_offs for both of these.
> >
> > Btw, the WARN's come only for UART3 and the error at hwmod init shows that
> > maybe _wait_target_ready fails.
> >
> > [0.00] NR_IRQS:402
> > [0.00] Clocking rate (Crystal/DPLL/MPU): 13.0/660/330 MHz
> > [0.00] omap_hwmod: uart3: cannot be enabled (3)
> >
>
> UART3 on 24xx is in CM_IDLEST2_CORE, and the 2430 hwmod data has it in
> CM_IDLEST1_CORE.
>
> Can you test the change below? I don't have a 2430, and it appears that
> this is already correct in the 2420 hwmod data.
>
> Kevin
>
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
> b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
> index 92f4ec0..5b61f7c 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
> @@ -449,9 +449,9 @@ static struct omap_hwmod omap2430_uart3_hwmod = {
> .prcm = {
> .omap2 = {
> .module_offs = CORE_MOD,
> - .prcm_reg_id = 1,
> + .prcm_reg_id = 2,
> .module_bit = OMAP24XX_EN_UART3_SHIFT,
> - .idlest_reg_id = 1,
> + .idlest_reg_id = 2,
> .idlest_idle_bit = OMAP24XX_EN_UART3_SHIFT,
> },
> },
This does seem to fix the issue on 2430. I don't see the error at hwmod init
or the WARN's later.
--
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: [GIT PULL] omap2 sparse fixes
Tony,
> -Original Message-
> From: Tony Lindgren [mailto:t...@atomide.com]
> Sent: Wednesday, September 29, 2010 12:02 AM
> To: G, Manjunath Kondaiah
> Cc: linux-omap@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; Samuel Ortiz; Dmitry
> Torokhov; linux-...@lists.infradead.org; Russell King - ARM Linux
> Subject: Re: [GIT PULL] omap2 sparse fixes
>
> * G, Manjunath Kondaiah [100928 08:26]:
...
> Yes please take out all patches that are not in arch/arm/*omap*/ path.
> The others really should go to the driver maintainers.
>
> Tony
Here is new branch which has only arch/arm/*omap*/ related patches.
-Manjunath
The following changes since commit 899611ee7d373e5eeda08e9a8632684e1ebbbf00:
Linus Torvalds (1):
Linux 2.6.36-rc6
are available in the git repository at:
git://dev.omapzoom.org/pub/scm/manju/kernel-omap3-dev.git omap_sparse_fixes
G, Manjunath Kondaiah (7):
OMAP: mach-omap2: Fix incorrect assignment warnings
OMAP: mach-omap2: Fix static declaration warnings
OMAP: mach-omap2: Fix static function warnings
OMAP: mach-omap2: Fix miscellaneous sparse warnings
OMAP: plat-omap: Fix static function warnings
OMAP: Convert write/read functions to raw read/write
OMAP3: Keypad: Fix incorrect type initializer
arch/arm/mach-omap2/board-3430sdp.c|2 +-
arch/arm/mach-omap2/board-4430sdp.c|3 +-
arch/arm/mach-omap2/board-am3517evm.c |5 +--
arch/arm/mach-omap2/board-cm-t35.c |2 +-
arch/arm/mach-omap2/board-devkit8000.c |4 +-
arch/arm/mach-omap2/board-igep0020.c |4 +-
arch/arm/mach-omap2/board-ldp.c|2 +-
arch/arm/mach-omap2/board-n8x0.c | 16 +--
arch/arm/mach-omap2/board-omap3beagle.c|2 +-
arch/arm/mach-omap2/board-omap3evm.c |8 +++---
arch/arm/mach-omap2/board-omap3stalker.c |6 ++--
arch/arm/mach-omap2/board-omap3touchbook.c |4 +-
arch/arm/mach-omap2/board-omap4panda.c |2 +-
arch/arm/mach-omap2/board-rx51-peripherals.c |4 ++-
arch/arm/mach-omap2/board-rx51-sdram.c |2 +-
arch/arm/mach-omap2/board-rx51-video.c |2 +
arch/arm/mach-omap2/board-zoom-debugboard.c|2 +
arch/arm/mach-omap2/board-zoom-peripherals.c |4 ++-
arch/arm/mach-omap2/control.c |5 ++-
arch/arm/mach-omap2/gpmc-onenand.c |8 +++---
arch/arm/mach-omap2/include/mach/board-flash.h |2 +
arch/arm/mach-omap2/include/mach/board-rx51.h | 11
arch/arm/mach-omap2/io.c |1 +
arch/arm/mach-omap2/io.h |7 +
arch/arm/mach-omap2/irq.c |1 -
arch/arm/mach-omap2/mux2420.c |2 +-
arch/arm/mach-omap2/mux2430.c |2 +-
arch/arm/mach-omap2/mux34xx.c | 12
arch/arm/mach-omap2/pm-debug.c |2 +-
arch/arm/mach-omap2/pm34xx.c |2 +-
arch/arm/mach-omap2/powerdomain.c | 28
arch/arm/mach-omap2/prcm.c |2 +-
.../include/plat => mach-omap2}/timer-gp.h |3 +-
arch/arm/plat-omap/cpu-omap.c |4 +-
arch/arm/plat-omap/dmtimer.c |6 ++--
arch/arm/plat-omap/fb.c|2 +
arch/arm/plat-omap/fb.h| 10 +++
arch/arm/plat-omap/include/plat/dmtimer.h |4 ++-
arch/arm/plat-omap/include/plat/sdrc.h |1 +
arch/arm/plat-omap/include/plat/sram.h |1 -
arch/arm/plat-omap/mcbsp.c | 10 +++---
arch/arm/plat-omap/sram.c | 21 ++
arch/arm/plat-omap/sram.h |6
43 files changed, 115 insertions(+), 112 deletions(-)
create mode 100644 arch/arm/mach-omap2/include/mach/board-rx51.h
create mode 100644 arch/arm/mach-omap2/io.h
rename arch/arm/{plat-omap/include/plat => mach-omap2}/timer-gp.h (86%)
create mode 100644 arch/arm/plat-omap/fb.h
create mode 100644 arch/arm/plat-omap/sram.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: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c
"Nayak, Rajendra" writes:
>> -Original Message-
>> From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
>> Sent: Thursday, September 30, 2010 12:49 AM
>> To: Nayak, Rajendra; Raja, Govindraj
>> Cc: Tony Lindgren; linux-omap@vger.kernel.org; Varadarajan, Charulatha
>> Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions:
>> watchdog, UART, i2c
>>
>> "Nayak, Rajendra" writes:
>>
>> [...]
>>
>> >
>> > I forgot to mention, there are similar WARN's that I see on 2430sdp even
>> > with UART
>> >
>>
>> Govidraj, can you look into these UART issues please?
>>
>> Looks like you might need to double check the bitfields and the
>> module_offs for both of these.
>
> Btw, the WARN's come only for UART3 and the error at hwmod init shows that
> maybe _wait_target_ready fails.
>
> [0.00] NR_IRQS:402
> [0.00] Clocking rate (Crystal/DPLL/MPU): 13.0/660/330 MHz
> [0.00] omap_hwmod: uart3: cannot be enabled (3)
>
UART3 on 24xx is in CM_IDLEST2_CORE, and the 2430 hwmod data has it in
CM_IDLEST1_CORE.
Can you test the change below? I don't have a 2430, and it appears that
this is already correct in the 2420 hwmod data.
Kevin
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 92f4ec0..5b61f7c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -449,9 +449,9 @@ static struct omap_hwmod omap2430_uart3_hwmod = {
.prcm = {
.omap2 = {
.module_offs = CORE_MOD,
- .prcm_reg_id = 1,
+ .prcm_reg_id = 2,
.module_bit = OMAP24XX_EN_UART3_SHIFT,
- .idlest_reg_id = 1,
+ .idlest_reg_id = 2,
.idlest_idle_bit = OMAP24XX_EN_UART3_SHIFT,
},
},
--
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: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c
> -Original Message- > From: Kevin Hilman [mailto:khil...@deeprootsystems.com] > Sent: Thursday, September 30, 2010 12:49 AM > To: Nayak, Rajendra; Raja, Govindraj > Cc: Tony Lindgren; linux-omap@vger.kernel.org; Varadarajan, Charulatha > Subject: Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, > UART, i2c > > "Nayak, Rajendra" writes: > > [...] > > > > > I forgot to mention, there are similar WARN's that I see on 2430sdp even > > with UART > > > > Govidraj, can you look into these UART issues please? > > Looks like you might need to double check the bitfields and the > module_offs for both of these. Btw, the WARN's come only for UART3 and the error at hwmod init shows that maybe _wait_target_ready fails. [0.00] NR_IRQS:402 [0.00] Clocking rate (Crystal/DPLL/MPU): 13.0/660/330 MHz [0.00] omap_hwmod: uart3: cannot be enabled (3) > > Thanks, > > Kevin > > > [0.00] WARNING: at arch/arm/mach-omap2/omap_hwmod.c:1237 > > _omap_hwmod_idle+0x28/0xd8() > > [0.00] omap_hwmod: uart3: idle state can only be entered from > > enabled state > > [0.00] Modules linked in: > > [0.00] [] (unwind_backtrace+0x0/0xe4) from [] > (warn_slowpath_common+0x4c/0x64) > > [0.00] [] (warn_slowpath_common+0x4c/0x64) from > > [] > (warn_slowpath_fmt+0x2c/0x3c) > > [0.00] [] (warn_slowpath_fmt+0x2c/0x3c) from [] > (_omap_hwmod_idle+0x28/0xd8) > > [0.00] [] (_omap_hwmod_idle+0x28/0xd8) from [] > (omap_hwmod_idle+0x28/0x38) > > [0.00] [] (omap_hwmod_idle+0x28/0x38) from [] > (omap_serial_init_port+0x164/0x42c) > > [0.00] [] (omap_serial_init_port+0x164/0x42c) from > > [] > (omap_serial_init+0x18/0x40) > > [0.00] [] (omap_serial_init+0x18/0x40) from [] > > (omap_2430sdp_init+0x48/0xcc) > > [0.00] [] (omap_2430sdp_init+0x48/0xcc) from [] > (customize_machine+0x18/0x24) > > [0.00] [] (customize_machine+0x18/0x24) from [] > > (do_one_initcall+0xcc/0x1a4) > > [0.00] [] (do_one_initcall+0xcc/0x1a4) from [] > > (kernel_init+0x148/0x210) > > [0.00] [] (kernel_init+0x148/0x210) from [] > > (kernel_thread_exit+0x0/0x8) > > [0.00] ---[ end trace 1b75b31a2719ed1c ]--- > > [0.00] [ cut here ] > > [0.00] WARNING: at arch/arm/mach-omap2/omap_hwmod.c:1237 > > _omap_hwmod_idle+0x28/0xd8() > > [0.00] omap_hwmod: uart3: idle state can only be entered from > > enabled state > > [0.00] Modules linked in: > > [0.00] [] (unwind_backtrace+0x0/0xe4) from [] > (warn_slowpath_common+0x4c/0x64) > > [0.00] [] (warn_slowpath_common+0x4c/0x64) from > > [] > (warn_slowpath_fmt+0x2c/0x3c) > > [0.00] [] (warn_slowpath_fmt+0x2c/0x3c) from [] > (_omap_hwmod_idle+0x28/0xd8) > > [0.00] [] (_omap_hwmod_idle+0x28/0xd8) from [] > > (uart_idle_hwmod+0x10/0x18) > > [0.00] [] (uart_idle_hwmod+0x10/0x18) from [] > (_omap_device_deactivate+0x58/0x144) > > [0.00] [] (_omap_device_deactivate+0x58/0x144) from > > [] > (omap_device_idle+0x48/0x68) > > [0.00] [] (omap_device_idle+0x48/0x68) from [] > (omap_serial_init_port+0x324/0x42c) > > [0.00] [] (omap_serial_init_port+0x324/0x42c) from > > [] > (omap_serial_init+0x18/0x40) > > [0.00] [] (omap_serial_init+0x18/0x40) from [] > > (omap_2430sdp_init+0x48/0xcc) > > [0.00] [] (omap_2430sdp_init+0x48/0xcc) from [] > (customize_machine+0x18/0x24) > > [0.00] [] (customize_machine+0x18/0x24) from [] > > (do_one_initcall+0xcc/0x1a4) > > [0.00] [] (do_one_initcall+0xcc/0x1a4) from [] > > (kernel_init+0x148/0x210) > > [0.00] [] (kernel_init+0x148/0x210) from [] > > (kernel_thread_exit+0x0/0x8) > > [0.00] ---[ end trace 1b75b31a2719ed1d ]--- > >> > >> > >> diff --git a/arch/arm/mach-omap2/cm-regbits-24xx.h > >> b/arch/arm/mach-omap2/cm-regbits-24xx.h > >> index 5986e2b..9a106c0 100644 > >> --- a/arch/arm/mach-omap2/cm-regbits-24xx.h > >> +++ b/arch/arm/mach-omap2/cm-regbits-24xx.h > >> @@ -126,12 +126,12 @@ > >> #define OMAP24XX_ST_HDQ_MASK (1 << 23) > >> #define OMAP2420_ST_I2C2_SHIFT20 > >> #define OMAP2420_ST_I2C2_MASK (1 << 20) > >> -#define OMAP2430_ST_I2CHS1_SHIFT 20 > >> -#define OMAP2430_ST_I2CHS1_MASK (1 << 20) > >> +#define OMAP2430_ST_I2CHS1_SHIFT 19 > >> +#define OMAP2430_ST_I2CHS1_MASK (1 << 19) > >> #define OMAP2420_ST_I2C1_SHIFT19 > >> #define OMAP2420_ST_I2C1_MASK (1 << 19) > >> -#define OMAP2430_ST_I2CHS2_SHIFT 19 > >> -#define OMAP2430_ST_I2CHS2_MASK (1 << 19) > >> +#define OMAP2430_ST_I2CHS2_SHIFT 20 > >> +#define OMAP2430_ST_I2CHS2_MASK (1 << 20) > >>
Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c
"Nayak, Rajendra" writes:
[...]
>
> I forgot to mention, there are similar WARN's that I see on 2430sdp even with
> UART
>
Govidraj, can you look into these UART issues please?
Looks like you might need to double check the bitfields and the
module_offs for both of these.
Thanks,
Kevin
> [0.00] WARNING: at arch/arm/mach-omap2/omap_hwmod.c:1237
> _omap_hwmod_idle+0x28/0xd8()
> [0.00] omap_hwmod: uart3: idle state can only be entered from enabled
> state
> [0.00] Modules linked in:
> [0.00] [] (unwind_backtrace+0x0/0xe4) from []
> (warn_slowpath_common+0x4c/0x64)
> [0.00] [] (warn_slowpath_common+0x4c/0x64) from
> [] (warn_slowpath_fmt+0x2c/0x3c)
> [0.00] [] (warn_slowpath_fmt+0x2c/0x3c) from []
> (_omap_hwmod_idle+0x28/0xd8)
> [0.00] [] (_omap_hwmod_idle+0x28/0xd8) from []
> (omap_hwmod_idle+0x28/0x38)
> [0.00] [] (omap_hwmod_idle+0x28/0x38) from []
> (omap_serial_init_port+0x164/0x42c)
> [0.00] [] (omap_serial_init_port+0x164/0x42c) from
> [] (omap_serial_init+0x18/0x40)
> [0.00] [] (omap_serial_init+0x18/0x40) from []
> (omap_2430sdp_init+0x48/0xcc)
> [0.00] [] (omap_2430sdp_init+0x48/0xcc) from []
> (customize_machine+0x18/0x24)
> [0.00] [] (customize_machine+0x18/0x24) from []
> (do_one_initcall+0xcc/0x1a4)
> [0.00] [] (do_one_initcall+0xcc/0x1a4) from []
> (kernel_init+0x148/0x210)
> [0.00] [] (kernel_init+0x148/0x210) from []
> (kernel_thread_exit+0x0/0x8)
> [0.00] ---[ end trace 1b75b31a2719ed1c ]---
> [0.00] [ cut here ]
> [0.00] WARNING: at arch/arm/mach-omap2/omap_hwmod.c:1237
> _omap_hwmod_idle+0x28/0xd8()
> [0.00] omap_hwmod: uart3: idle state can only be entered from enabled
> state
> [0.00] Modules linked in:
> [0.00] [] (unwind_backtrace+0x0/0xe4) from []
> (warn_slowpath_common+0x4c/0x64)
> [0.00] [] (warn_slowpath_common+0x4c/0x64) from
> [] (warn_slowpath_fmt+0x2c/0x3c)
> [0.00] [] (warn_slowpath_fmt+0x2c/0x3c) from []
> (_omap_hwmod_idle+0x28/0xd8)
> [0.00] [] (_omap_hwmod_idle+0x28/0xd8) from []
> (uart_idle_hwmod+0x10/0x18)
> [0.00] [] (uart_idle_hwmod+0x10/0x18) from []
> (_omap_device_deactivate+0x58/0x144)
> [0.00] [] (_omap_device_deactivate+0x58/0x144) from
> [] (omap_device_idle+0x48/0x68)
> [0.00] [] (omap_device_idle+0x48/0x68) from []
> (omap_serial_init_port+0x324/0x42c)
> [0.00] [] (omap_serial_init_port+0x324/0x42c) from
> [] (omap_serial_init+0x18/0x40)
> [0.00] [] (omap_serial_init+0x18/0x40) from []
> (omap_2430sdp_init+0x48/0xcc)
> [0.00] [] (omap_2430sdp_init+0x48/0xcc) from []
> (customize_machine+0x18/0x24)
> [0.00] [] (customize_machine+0x18/0x24) from []
> (do_one_initcall+0xcc/0x1a4)
> [0.00] [] (do_one_initcall+0xcc/0x1a4) from []
> (kernel_init+0x148/0x210)
> [0.00] [] (kernel_init+0x148/0x210) from []
> (kernel_thread_exit+0x0/0x8)
> [0.00] ---[ end trace 1b75b31a2719ed1d ]---
>>
>>
>> diff --git a/arch/arm/mach-omap2/cm-regbits-24xx.h
>> b/arch/arm/mach-omap2/cm-regbits-24xx.h
>> index 5986e2b..9a106c0 100644
>> --- a/arch/arm/mach-omap2/cm-regbits-24xx.h
>> +++ b/arch/arm/mach-omap2/cm-regbits-24xx.h
>> @@ -126,12 +126,12 @@
>> #define OMAP24XX_ST_HDQ_MASK(1 << 23)
>> #define OMAP2420_ST_I2C2_SHIFT 20
>> #define OMAP2420_ST_I2C2_MASK (1 << 20)
>> -#define OMAP2430_ST_I2CHS1_SHIFT20
>> -#define OMAP2430_ST_I2CHS1_MASK (1 << 20)
>> +#define OMAP2430_ST_I2CHS1_SHIFT19
>> +#define OMAP2430_ST_I2CHS1_MASK (1 << 19)
>> #define OMAP2420_ST_I2C1_SHIFT 19
>> #define OMAP2420_ST_I2C1_MASK (1 << 19)
>> -#define OMAP2430_ST_I2CHS2_SHIFT19
>> -#define OMAP2430_ST_I2CHS2_MASK (1 << 19)
>> +#define OMAP2430_ST_I2CHS2_SHIFT20
>> +#define OMAP2430_ST_I2CHS2_MASK (1 << 20)
>> #define OMAP24XX_ST_MCBSP2_SHIFT16
>> #define OMAP24XX_ST_MCBSP2_MASK (1 << 16)
>> #define OMAP24XX_ST_MCBSP1_SHIFT15
>> diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
>> b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
>> index 8bf46c1..ca4edd3 100644
>> --- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
>> +++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
>> @@ -504,6 +504,7 @@ static struct omap_hwmod omap2420_i2c1_hwmod = {
>> .main_clk = "i2c1_fck",
>> .prcm = {
>> .omap2 = {
>> +.module_offs = CORE_MOD,
>> .prcm_reg_id = 1,
>> .module_bit = OMAP2420_EN_I2C1_SHIFT,
>
Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c
"Nayak, Rajendra" writes: > .. > >> > > This is with the omap2plus_defconfig and after editing cmdline to have >> > > console set >> > > to ttyO2. >> > > >> > > Would be nice to have those fixed before we merge it. >> > >> > Rajendra, can you look into this on OMAP2? This is happening for Tony >> > on both n8x0 and 2430sdp. >> >> Sure, I'll have a look. > > Kevin, > > I saw 3 issues with the patch which adds OMAP2 hwmods which I never seem to > have > caught with the boottest on 2430 that I tried before I posted the patches. Thanks for digging into this. [...] > > These are the fixes that make it boot on 2430sdp. Should I repost the > original patch with these fixes? Yes please. 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 05/11] omap3: Remove non-existent config option
On Wed, Sep 29, 2010 at 4:28 PM, Marathe, Yogesh wrote:
> dsplink and syslink (two drivers who use iommu) should not enable
> CONFIG_MPU_BRIDGE_IOMMU as dspbridge and dsplink /syslink
> can not co-exist as they are using same resources. Not applying patch
> breaks dsplink/sylink any one which is being used. Defining this config
> makes them co-exist.
No, for dsp-link you would have:
CONFIG_TIDSPBRIDGE=n
CONFIG_OMAP_IOMMU_IVA2=y
It would be exactly the same as applying your patch.
And tidspbridge is not using iommu right now.
And AFAIK syslink is not for omap3, so omap3_devices is not relevant.
> I'm ok with changing name to CONFIG_OMAP_IOMMU_IVA2 but ideally
> then that will also break the dspbridge.
No, grep for MPU_BRIDGE_IOMMU on the current tidspbridge in mainline;
it's not defined anywhere, so CONFIG_OMAP_IOMMU_IVA2, or
CONFIG_FOOBAR, it doesn't matter for tidspbridge right now. And
MPU_BRIDGE_IOMMU doesn't depend on tidspbridge on any way.
> One more way would be to soure revert the patch and apply on dspbridge branch
> if it breaks the builds on that branch rather than
> breaking others in master.
There is no tidspbrige branch; it's in mainline:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;f=drivers/staging/tidspbridge
But that doesn't matter, even if it was in a branch, iommu should not
break either tidspbridge, or dsp-link, and driver branches should not
modify anything outside their domain (ideally).
All you need to do is 'select OMAP_IOMMU_IVA2', although the attached
patch would be needed.
--
Felipe Contreras
From 2795948f11cb218eb7f4be26fd747727ba5c31da Mon Sep 17 00:00:00 2001
From: Felipe Contreras
Date: Wed, 29 Sep 2010 22:05:46 +0300
Subject: [PATCH] omap: iommu: make iva2 iommu selectable
It seems dsp-link will do this, and tidspbridge too at some point, but
right now it's not possible to select CONFIG_MPU_BRIDGE_IOMMU.
Signed-off-by: Felipe Contreras
---
arch/arm/mach-omap2/omap-iommu.c |2 +-
arch/arm/plat-omap/Kconfig |3 +++
2 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index f5a1aad..adc0904 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -35,7 +35,7 @@ static struct iommu_device omap3_devices[] = {
.clk_name = "cam_ick",
},
},
-#if defined(CONFIG_MPU_BRIDGE_IOMMU)
+#if defined(CONFIG_OMAP_IOMMU_IVA2)
{
.base = 0x5d00,
.irq = 28,
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index e39a417..e0b41b6 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -109,6 +109,9 @@ config OMAP_IOMMU_DEBUG
Say N unless you know you need this.
+config OMAP_IOMMU_IVA2
+ bool
+
choice
prompt "System timer"
default OMAP_32K_TIMER if !ARCH_OMAP15XX
--
1.7.3.2.g9e605
Re: [PATCH 0/2] OMAP2+: misc. defconfig cleanups for 2.6.37
* Kevin Hilman [100928 11:59]: > A couple of small defconfig changes for 2.6.37 with the goal of working > towards a smaller default kernel image. Thanks, adding both to omap-for-linus. 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: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c
> -Original Message- > From: Nayak, Rajendra > Sent: Wednesday, September 29, 2010 9:44 PM > To: Nayak, Rajendra; Kevin Hilman; Tony Lindgren > Cc: linux-omap@vger.kernel.org; Varadarajan, Charulatha; Raja, Govindraj > Subject: RE: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, > UART, i2c > > .. > > > > > This is with the omap2plus_defconfig and after editing cmdline to have > > > > console set > > > > to ttyO2. > > > > > > > > Would be nice to have those fixed before we merge it. > > > > > > Rajendra, can you look into this on OMAP2? This is happening for Tony > > > on both n8x0 and 2430sdp. > > > > Sure, I'll have a look. > > Kevin, > > I saw 3 issues with the patch which adds OMAP2 hwmods which I never seem to > have > caught with the boottest on 2430 that I tried before I posted the patches. > > These were causing the hwmod enable at init to fail and subsequent idle would > throw > WARN's > > Looking back at my bootlog on 2430, I did see the "cannot be enable" errors > during > hwmod init, but the WARN's never came and I seem to have overlooked these > errors. > The only reason I can think of why the WARN's were not thrown was if for some > reason (usecounting) the pm_runtime_put_sync's from the i2c driver were not > translating into a omap_device/hmwod disable/idle call. > > Partial 2430 bootlog from pm-core branch.. > > <6>Clocking rate (Crystal/DPLL/MPU): 13.0/660/330 MHz > Clocking rate (Crystal/DPLL/MPU): 13.0/660/330 MHz > <4>omap_hwmod: i2c1: cannot clk_get main_clk i2c1_fck > omap_hwmod: i2c1: cannot clk_get main_clk i2c1_fck > <4>omap_hwmod: i2c2: cannot clk_get main_clk i2c2_fck > omap_hwmod: i2c2: cannot clk_get main_clk i2c2_fck > <4>omap_hwmod: i2c1: cannot be enabled (3) > omap_hwmod: i2c1: cannot be enabled (3) > <4>omap_hwmod: i2c2: cannot be enabled (3) > omap_hwmod: i2c2: cannot be enabled (3) > <6>GPMC revision 3.0 > GPMC revision 3.0 > <6>IRQ: Found an INTC at 0xfa0fe000 (revision 3.0) with 96 interrupts > IRQ: Found an INTC at 0xfa0fe000 (revision 3.0) with 96 interrupts > <6>Total of 96 interrupts on 1 active controller > Total of 96 interrupts on 1 active controller > <6>OMAP GPIO hardware version 2.4 > OMAP GPIO hardware version 2.4 > <6>OMAP clockevent source: GPTIMER1 at 32000 Hz > OMAP clockevent source: GPTIMER1 at 32000 Hz > Console: colour dummy device 80x30 > Console: colour dummy device 80x30 > <6>Calibrating delay loop... Calibrating delay loop... 320.37 BogoMIPS > (lpj=1253376) > 320.37 BogoMIPS (lpj=1253376) > <6>pid_max: default: 32768 minimum: 301 > pid_max: default: 32768 minimum: 301 > Mount-cache hash table entries: 512 > Mount-cache hash table entries: 512 > <6>CPU: Testing write buffer coherency: CPU: Testing write buffer coherency: > ok > ok > <6>regulator: core version 0.5 > regulator: core version 0.5 > <6>NET: Registered protocol family 16 > NET: Registered protocol family 16 > <7>mux: Setting signal i2c2_scl.i2c2_scl 0x -> 0x0100 > mux: Setting signal i2c2_scl.i2c2_scl 0x -> 0x0100 > <7>mux: Setting signal i2c2_sda.i2c2_sda 0x -> 0x0100 > mux: Setting signal i2c2_sda.i2c2_sda 0x -> 0x0100 > <3>look up for i2c2 successful > look up for i2c2 successful > <7>mux: Setting signal usb0hs_data1.usb0_dat 0x0004 -> 0x0004 > mux: Setting signal usb0hs_data1.usb0_dat 0x0004 -> 0x0004 > <7>mux: Setting signal usb0hs_data0.usb0_txen 0x0004 -> 0x0004 > mux: Setting signal usb0hs_data0.usb0_txen 0x0004 -> 0x0004 > <7>mux: Setting signal usb0hs_data2.usb0_se0 0x0004 -> 0x0004 > mux: Setting signal usb0hs_data2.usb0_se0 0x0004 -> 0x0004 > USB: hmc 0USB: hmc 0, usb0 3 wires, usb0 3 wires, Mini-AB on usb0, Mini-AB on > usb0 > > <7>mux: Setting signal usb0hs_stp.usb0hs_stp 0x0018 -> 0x0018 > mux: Setting signal usb0hs_stp.usb0hs_stp 0x0018 -> 0x0018 > <7>mux: Setting signal gpio_149.gpio149 0x0018 -> 0x0103 > mux: Setting signal gpio_149.gpio149 0x0018 -> 0x0103 > <6>OMAP DMA hardware revision 4.0 > OMAP DMA hardware revision 4.0 > bio: create slab at 0 > bio: create slab at 0 > <4>omap_device: i2c_omap.1: new worst case activate latency 0: 2563476 > omap_device: i2c_omap.1: new worst case activate latency 0: 2563476 > <6>i2c_omap i2c_omap.1: bus 1 rev3.7 at 100 kHz > i2c_omap i2c_omap.1: bus 1 rev3.7 at 100 kHz > <6>i2c_omap i2c_omap.2: bus 2 rev3.7 at 2600 kHz > i2c_omap i2c_omap.2: bus 2 rev3.7 at 2600 kHz > > > These are the fixes that make it boot on 2430sdp. Should I repost the > original patch with these fixes? I forgot to mention, there are similar WARN's that I see on 2430sdp even with UART [0.00] WARNING: at arch/arm/mach-omap2/omap_hwmod.c:1237 _omap_hwmod_idle+0x28/0xd8() [0.00] omap_hwmod: uart3: idle state can only be entered from enabled state [0.00] Modules linked in: [0.00] [] (unwind_backtrace+0x0/0xe4) from [] (warn_slowpath_common+0x4c/0x64) [0.00] [] (warn_slowpath_common+0x4c/0x64) from [] (warn_slowpath_fmt+0x2c/0x3c) [0.00
RE: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c
.. > > > This is with the omap2plus_defconfig and after editing cmdline to have > > > console set > > > to ttyO2. > > > > > > Would be nice to have those fixed before we merge it. > > > > Rajendra, can you look into this on OMAP2? This is happening for Tony > > on both n8x0 and 2430sdp. > > Sure, I'll have a look. Kevin, I saw 3 issues with the patch which adds OMAP2 hwmods which I never seem to have caught with the boottest on 2430 that I tried before I posted the patches. These were causing the hwmod enable at init to fail and subsequent idle would throw WARN's Looking back at my bootlog on 2430, I did see the "cannot be enable" errors during hwmod init, but the WARN's never came and I seem to have overlooked these errors. The only reason I can think of why the WARN's were not thrown was if for some reason (usecounting) the pm_runtime_put_sync's from the i2c driver were not translating into a omap_device/hmwod disable/idle call. Partial 2430 bootlog from pm-core branch.. <6>Clocking rate (Crystal/DPLL/MPU): 13.0/660/330 MHz Clocking rate (Crystal/DPLL/MPU): 13.0/660/330 MHz <4>omap_hwmod: i2c1: cannot clk_get main_clk i2c1_fck omap_hwmod: i2c1: cannot clk_get main_clk i2c1_fck <4>omap_hwmod: i2c2: cannot clk_get main_clk i2c2_fck omap_hwmod: i2c2: cannot clk_get main_clk i2c2_fck <4>omap_hwmod: i2c1: cannot be enabled (3) omap_hwmod: i2c1: cannot be enabled (3) <4>omap_hwmod: i2c2: cannot be enabled (3) omap_hwmod: i2c2: cannot be enabled (3) <6>GPMC revision 3.0 GPMC revision 3.0 <6>IRQ: Found an INTC at 0xfa0fe000 (revision 3.0) with 96 interrupts IRQ: Found an INTC at 0xfa0fe000 (revision 3.0) with 96 interrupts <6>Total of 96 interrupts on 1 active controller Total of 96 interrupts on 1 active controller <6>OMAP GPIO hardware version 2.4 OMAP GPIO hardware version 2.4 <6>OMAP clockevent source: GPTIMER1 at 32000 Hz OMAP clockevent source: GPTIMER1 at 32000 Hz Console: colour dummy device 80x30 Console: colour dummy device 80x30 <6>Calibrating delay loop... Calibrating delay loop... 320.37 BogoMIPS (lpj=1253376) 320.37 BogoMIPS (lpj=1253376) <6>pid_max: default: 32768 minimum: 301 pid_max: default: 32768 minimum: 301 Mount-cache hash table entries: 512 Mount-cache hash table entries: 512 <6>CPU: Testing write buffer coherency: CPU: Testing write buffer coherency: ok ok <6>regulator: core version 0.5 regulator: core version 0.5 <6>NET: Registered protocol family 16 NET: Registered protocol family 16 <7>mux: Setting signal i2c2_scl.i2c2_scl 0x -> 0x0100 mux: Setting signal i2c2_scl.i2c2_scl 0x -> 0x0100 <7>mux: Setting signal i2c2_sda.i2c2_sda 0x -> 0x0100 mux: Setting signal i2c2_sda.i2c2_sda 0x -> 0x0100 <3>look up for i2c2 successful look up for i2c2 successful <7>mux: Setting signal usb0hs_data1.usb0_dat 0x0004 -> 0x0004 mux: Setting signal usb0hs_data1.usb0_dat 0x0004 -> 0x0004 <7>mux: Setting signal usb0hs_data0.usb0_txen 0x0004 -> 0x0004 mux: Setting signal usb0hs_data0.usb0_txen 0x0004 -> 0x0004 <7>mux: Setting signal usb0hs_data2.usb0_se0 0x0004 -> 0x0004 mux: Setting signal usb0hs_data2.usb0_se0 0x0004 -> 0x0004 USB: hmc 0USB: hmc 0, usb0 3 wires, usb0 3 wires, Mini-AB on usb0, Mini-AB on usb0 <7>mux: Setting signal usb0hs_stp.usb0hs_stp 0x0018 -> 0x0018 mux: Setting signal usb0hs_stp.usb0hs_stp 0x0018 -> 0x0018 <7>mux: Setting signal gpio_149.gpio149 0x0018 -> 0x0103 mux: Setting signal gpio_149.gpio149 0x0018 -> 0x0103 <6>OMAP DMA hardware revision 4.0 OMAP DMA hardware revision 4.0 bio: create slab at 0 bio: create slab at 0 <4>omap_device: i2c_omap.1: new worst case activate latency 0: 2563476 omap_device: i2c_omap.1: new worst case activate latency 0: 2563476 <6>i2c_omap i2c_omap.1: bus 1 rev3.7 at 100 kHz i2c_omap i2c_omap.1: bus 1 rev3.7 at 100 kHz <6>i2c_omap i2c_omap.2: bus 2 rev3.7 at 2600 kHz i2c_omap i2c_omap.2: bus 2 rev3.7 at 2600 kHz These are the fixes that make it boot on 2430sdp. Should I repost the original patch with these fixes? diff --git a/arch/arm/mach-omap2/cm-regbits-24xx.h b/arch/arm/mach-omap2/cm-regbits-24xx.h index 5986e2b..9a106c0 100644 --- a/arch/arm/mach-omap2/cm-regbits-24xx.h +++ b/arch/arm/mach-omap2/cm-regbits-24xx.h @@ -126,12 +126,12 @@ #define OMAP24XX_ST_HDQ_MASK (1 << 23) #define OMAP2420_ST_I2C2_SHIFT 20 #define OMAP2420_ST_I2C2_MASK (1 << 20) -#define OMAP2430_ST_I2CHS1_SHIFT 20 -#define OMAP2430_ST_I2CHS1_MASK(1 << 20) +#define OMAP2430_ST_I2CHS1_SHIFT 19 +#define OMAP2430_ST_I2CHS1_MASK(1 << 19) #define OMAP2420_ST_I2C1_SHIFT 19 #define OMAP2420_ST_I2C1_MASK (1 << 19) -#define OMAP2430_ST_I2CHS2_SHIFT 19 -#define OMAP2430_ST_I2CHS2_MASK(1 << 19) +#define OMAP2430_ST_I2CHS2_SHIFT 20 +#define OM
Re: [PATCH 2/3 v4] musb: add musb support for AM35x
Hi,
Already replied to Sergei on the comments below,
so please see the answer in my reply to Sergei.
On 09/29/10 17:46, Gupta, Ajay Kumar wrote:
> Hi,
>
> [...]
>>> + devconf2 &= ~CONF2_OTGMODE;
>>> + switch (musb_mode) {
>>> +#ifdef CONFIG_USB_MUSB_OTG
>>> + case MUSB_OTG: /* Don't override the VBUS/ID comparators */
>>> + devconf2 |= CONF2_NO_OVERRIDE;
>> This does nothing, can be removed...
> Yes, but it's good to have it from code readability perspective.
>
> I can remove it but let's get Felipe's opinion on this.
>
> [...]
>>> + if (musb->set_clock)
>>> + musb->set_clock(musb->clock, 0);
>>> + else
>>> + clk_disable(musb->clock);
>>> +
>>> + otg_fck = clk_get(musb->controller, "fck");
>>> + if (IS_ERR(otg_fck)) {
>>> + DBG(2, "clk_get() failed for otg_fck.\n");
>>> + } else {
>>> + clk_put(otg_fck);
>>> + clk_put(otg_fck);
>>> + clk_disable(otg_fck);
>> I think the order should be:
>> clk_disable(...);
>> clk_put(...);
> Again I would wait for Felipe's opinion on this ordering. BTW there
> Are codes on musb_core.c where clk_put is done before clk_disable().
>
>>> And of course, it should be put only once... ;)
> No. clk_put() needs to be done twice as clk_get() is called two times;
> one in musb_platform_init() and other in current function musb_platform_exit.
>
> Other solution could be to save otg_fck in some static variable as
> Sergei suggested.
>
> Thanks,
> Ajay
> [...]
>
> --
> 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
>
--
Regards,
Igor.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/3 v4] musb: add musb support for AM35x
Hi,
> >
> > +config USB_MUSB_AM35X
> > + boolean "AM35X MUSB support"
> > + depends on USB_MUSB_HDRC && MACH_OMAP3517EVM
>
> As I've already said, depending on the board type won't scale... :-(
..and to scale it up we need to add "select USB_MUSB_AM35X" in
arch/arm/mach-omap2/Kconfig for all the boards having AM35x.
Felipe, what's your opinion on this?
>
> > + select NOP_USB_XCEIV
> > + default y
> > + help
> > + Select this option if your platform is based on AM35x. As
> > + AM35x has an updated MUSB with CPPI4.1 DMA so this config
> > + is introduced to differentiate musb ip between OMAP3x and
> > + AM35x platforms.
>
> OK, but why it's made visible?
Hmm, can be made hidden.
>
> > diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
> > new file mode 100644
> > index 000..ee0c104
> > --- /dev/null
> > +++ b/drivers/usb/musb/am35x.c
> > @@ -0,0 +1,510 @@
> > +/*
> > + * Texas Instruments AM35x "glue layer"
> > + *
> > + * Copyright (c) 2010, by Texas Instruments
> > + *
> > + * Based on the DA8xx "glue layer" code.
> > + * Copyright (C) 2005-2006 by Texas Instruments
>
> There's no code by TI in the DA8xx layer -- that copyright comes from
> the
> DaVinci code.
Yes, it's from DaVinci.
>
> > + * Copyright (c) 2008, MontaVista Software, Inc.
>
> I've extended it to 2008-2009 (and should have to 2010 :-).
no issue, I will update it.
>
> > +/* USB interrupt register bits */
> > +#define USB_INTR_USB_SHIFT 16
> > +#define USB_INTR_USB_MASK (0x1ff << USB_INTR_USB_SHIFT)
>
> Don't seem like good names (USB_ repeated twice)...
Ok, will try to get a better name in next version :)
>
> [...]
>
> > +int __init musb_platform_init(struct musb *musb, void *board_data)
> > +{
> > + void __iomem *reg_base = musb->ctrl_base;
> > + struct clk *otg_fck;
> > + u32 rev, lvl_intr, sw_reset;
> > + int status;
> > +
> > + musb->mregs += USB_MENTOR_CORE_OFFSET;
> > +
> > + if (musb->set_clock)
> > + musb->set_clock(musb->clock, 1);
>
> OMAP doesn't use plat->set_clock anymore, does it?
Yes it doesn't anymore so can be removed.
>
> > + else
> > + clk_enable(musb->clock);
> > + DBG(2, "usbotg_ck=%lud\n", clk_get_rate(musb->clock));
> > +
> > + otg_fck = clk_get(musb->controller, "fck");
> > + if (IS_ERR(otg_fck)) {
> > + status = PTR_ERR(otg_fck);
> > + otg_fck = NULL;
>
> This assignment does not seem necessary.
Yes.
>
> > + goto exit0;
> > + }
> [...]
> > +exit1:
> > + clk_disable(otg_fck);
> > +exit0:
> > + clk_disable(musb->clock);
> > + return status;
> > +}
> > +
> > +int musb_platform_exit(struct musb *musb)
> > +{
> > + struct clk *otg_fck;
> > +
> > + if (is_host_enabled(musb))
> > + del_timer_sync(&otg_workaround);
> > +
> > + phy_off();
> > +
> > + otg_put_transceiver(musb->xceiv);
> > + usb_nop_xceiv_unregister();
> > +
> > + if (musb->set_clock)
> > + musb->set_clock(musb->clock, 0);
>
> Looks like it may be dropped...
>
> > + else
> > + clk_disable(musb->clock);
> > +
> > + otg_fck = clk_get(musb->controller, "fck");
>
> Isn't it better to store this in some static variable? I don't think
> there's
> or there'll be multiple instances of MUSB on AM35x...
AM35x has only one instance but future coming platform does have
two musb interfaces and so we would face this issue. I think it's
better to add another entry in "struct musb" itself.
Felipe, any comment?
Thanks,
Ajay
>
> > + if (IS_ERR(otg_fck)) {
> > + DBG(2, "clk_get() failed for otg_fck.\n");
> > + } else {
> > + clk_put(otg_fck);
> > + clk_put(otg_fck);
> > + clk_disable(otg_fck);
> > + }
> > +
> > + return 0;
> > +}
>
> WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3 v4] musb: add musb support for AM35x
Hi,
On 09/29/10 17:38, Sergei Shtylyov wrote:
> Hello.
>
> Igor Grinberg wrote:
>
>>> AM35x has musb interface and uses CPPI4.1 DMA engine.
>>> Current patch supports only PIO mode. DMA support can be
>>> added later once basic CPPI4.1 DMA patch is accepted.
>
>>> Also added USB_MUSB_AM35X which is required to differentiate musb ips
>>> between OMAP3x and AM35x. This config would be used to for below
>>> purposes,
>>> - Select am35x.c instead of omap2430.c for compilation
>>> at drivers/usb/musb directory. Please note there are
>>> significant differneces in these two files as musb ip
>>> in quite different on AM35x.
>>> - Select workaround codes applicable for AM35x musb issues.
>>> one such workaround is for bytewise read issue on AM35x.
>
>>> Signed-off-by: Ajay Kumar Gupta
>
> [...]
>
>>> diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
>>> new file mode 100644
>>> index 000..ee0c104
>>> --- /dev/null
>>> +++ b/drivers/usb/musb/am35x.c
>>> @@ -0,0 +1,510 @@
> [...]
>>> +int musb_platform_set_mode(struct musb *musb, u8 musb_mode)
>>> +{
>>> +u32 devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2);
>>> +
>>> +devconf2 &= ~CONF2_OTGMODE;
>>> +switch (musb_mode) {
>>> +#ifdefCONFIG_USB_MUSB_HDRC_HCD
>>> +case MUSB_HOST:/* Force VBUS valid, ID = 0 */
>>> +devconf2 |= CONF2_FORCE_HOST;
>>> +break;
>>> +#endif
>>> +#ifdefCONFIG_USB_GADGET_MUSB_HDRC
>>> +case MUSB_PERIPHERAL:/* Force VBUS valid, ID = 1 */
>>> +devconf2 |= CONF2_FORCE_DEVICE;
>>> +break;
>>> +#endif
>>> +#ifdefCONFIG_USB_MUSB_OTG
>>> +case MUSB_OTG:/* Don't override the VBUS/ID comparators */
>>> +devconf2 |= CONF2_NO_OVERRIDE;
>
>> This does nothing, can be removed...
>
>Well, I think you should let it live -- for completeness...
Well, I actually don't like, how those bits defined in first place,
but I want am35xx musb support badly, so yeah, let it be...
>
>>> +int musb_platform_exit(struct musb *musb)
>>> +{
>>> +struct clk *otg_fck;
>>> +
>>> +if (is_host_enabled(musb))
>>> +del_timer_sync(&otg_workaround);
>>> +
>>> +phy_off();
>>> +
>>> +otg_put_transceiver(musb->xceiv);
>>> +usb_nop_xceiv_unregister();
>>> +
>>> +if (musb->set_clock)
>>> +musb->set_clock(musb->clock, 0);
>>> +else
>>> +clk_disable(musb->clock);
>>> +
>>> +otg_fck = clk_get(musb->controller, "fck");
>>> +if (IS_ERR(otg_fck)) {
>>> +DBG(2, "clk_get() failed for otg_fck.\n");
>>> +} else {
>>> +clk_put(otg_fck);
>>> +clk_put(otg_fck);
>>> +clk_disable(otg_fck);
>
>> I think the order should be:
>> clk_disable(...);
>> clk_put(...);
>
>Right...
>
>> And of course, it should be put only once... ;)
>
>clk_get() is called twice, here and in musb_platform_init(), and so is
> clk_put().
Right, it should be stored in a static variable or a structure
(as you state in your reply), so there won't be any need for putting it twice.
>
> WBR, Sergei
> --
> 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
>
--
Regards,
Igor.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/3 v4] musb: add musb support for AM35x
Hi,
[...]
> > + devconf2 &= ~CONF2_OTGMODE;
> > + switch (musb_mode) {
> > +#ifdef CONFIG_USB_MUSB_OTG
> > + case MUSB_OTG: /* Don't override the VBUS/ID comparators */
> > + devconf2 |= CONF2_NO_OVERRIDE;
>
> This does nothing, can be removed...
Yes, but it's good to have it from code readability perspective.
I can remove it but let's get Felipe's opinion on this.
[...]
> > + if (musb->set_clock)
> > + musb->set_clock(musb->clock, 0);
> > + else
> > + clk_disable(musb->clock);
> > +
> > + otg_fck = clk_get(musb->controller, "fck");
> > + if (IS_ERR(otg_fck)) {
> > + DBG(2, "clk_get() failed for otg_fck.\n");
> > + } else {
> > + clk_put(otg_fck);
> > + clk_put(otg_fck);
> > + clk_disable(otg_fck);
>
> I think the order should be:
> clk_disable(...);
> clk_put(...);
Again I would wait for Felipe's opinion on this ordering. BTW there
Are codes on musb_core.c where clk_put is done before clk_disable().
>> And of course, it should be put only once... ;)
No. clk_put() needs to be done twice as clk_get() is called two times;
one in musb_platform_init() and other in current function musb_platform_exit.
Other solution could be to save otg_fck in some static variable as
Sergei suggested.
Thanks,
Ajay
>
[...]
--
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 v8 0/6] OMAP: WDT: Implement WDT in hwmod way
"Varadarajan, Charulatha" writes: [...] >> >> Instead, I would rather have a small piece of code in omap_init_wdt() >> which disarms the watchdog so we don't have any assumptions about >> bootloader behavior. >> >> The question remains whether this disarm should be >> #ifndef CONFIG_OMAP_WATCHDOG or if it should happen all the time. In >> case the watchdog is a module, it's probe may not happen within the >> timeout period and they system may reboot also, so I lean towards >> disarming the watchdog unconditionally. > > Agreed. But this shall be handled in mach-omap2/devices.c by directly > accessing the watchdog registers and disabling it, as the watchdog driver > would not be available by this time. Correct. > If this okay, I would send a separate patch on top my hwmod series to > handle this. Yes please. Thanks, 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 2/3 v4] musb: add musb support for AM35x
Hello.
Igor Grinberg wrote:
AM35x has musb interface and uses CPPI4.1 DMA engine.
Current patch supports only PIO mode. DMA support can be
added later once basic CPPI4.1 DMA patch is accepted.
Also added USB_MUSB_AM35X which is required to differentiate musb ips
between OMAP3x and AM35x. This config would be used to for below
purposes,
- Select am35x.c instead of omap2430.c for compilation
at drivers/usb/musb directory. Please note there are
significant differneces in these two files as musb ip
in quite different on AM35x.
- Select workaround codes applicable for AM35x musb issues.
one such workaround is for bytewise read issue on AM35x.
Signed-off-by: Ajay Kumar Gupta
[...]
diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
new file mode 100644
index 000..ee0c104
--- /dev/null
+++ b/drivers/usb/musb/am35x.c
@@ -0,0 +1,510 @@
[...]
+int musb_platform_set_mode(struct musb *musb, u8 musb_mode)
+{
+ u32 devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2);
+
+ devconf2 &= ~CONF2_OTGMODE;
+ switch (musb_mode) {
+#ifdef CONFIG_USB_MUSB_HDRC_HCD
+ case MUSB_HOST: /* Force VBUS valid, ID = 0 */
+ devconf2 |= CONF2_FORCE_HOST;
+ break;
+#endif
+#ifdef CONFIG_USB_GADGET_MUSB_HDRC
+ case MUSB_PERIPHERAL: /* Force VBUS valid, ID = 1 */
+ devconf2 |= CONF2_FORCE_DEVICE;
+ break;
+#endif
+#ifdef CONFIG_USB_MUSB_OTG
+ case MUSB_OTG: /* Don't override the VBUS/ID comparators */
+ devconf2 |= CONF2_NO_OVERRIDE;
This does nothing, can be removed...
Well, I think you should let it live -- for completeness...
+int musb_platform_exit(struct musb *musb)
+{
+ struct clk *otg_fck;
+
+ if (is_host_enabled(musb))
+ del_timer_sync(&otg_workaround);
+
+ phy_off();
+
+ otg_put_transceiver(musb->xceiv);
+ usb_nop_xceiv_unregister();
+
+ if (musb->set_clock)
+ musb->set_clock(musb->clock, 0);
+ else
+ clk_disable(musb->clock);
+
+ otg_fck = clk_get(musb->controller, "fck");
+ if (IS_ERR(otg_fck)) {
+ DBG(2, "clk_get() failed for otg_fck.\n");
+ } else {
+ clk_put(otg_fck);
+ clk_put(otg_fck);
+ clk_disable(otg_fck);
I think the order should be:
clk_disable(...);
clk_put(...);
Right...
And of course, it should be put only once... ;)
clk_get() is called twice, here and in musb_platform_init(), and so is
clk_put().
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3 v4] musb: add musb support for AM35x
Hello.
Ajay Kumar Gupta wrote:
AM35x has musb interface and uses CPPI4.1 DMA engine.
Current patch supports only PIO mode. DMA support can be
added later once basic CPPI4.1 DMA patch is accepted.
Also added USB_MUSB_AM35X which is required to differentiate musb ips
between OMAP3x and AM35x. This config would be used to for below
purposes,
- Select am35x.c instead of omap2430.c for compilation
at drivers/usb/musb directory. Please note there are
significant differneces in these two files as musb ip
in quite different on AM35x.
- Select workaround codes applicable for AM35x musb issues.
one such workaround is for bytewise read issue on AM35x.
Signed-off-by: Ajay Kumar Gupta
[...]
diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
index 1dd21c2..0941a32 100644
--- a/drivers/usb/musb/Kconfig
+++ b/drivers/usb/musb/Kconfig
@@ -60,6 +60,17 @@ comment "OMAP 44xx high speed USB support"
comment "Blackfin high speed USB Support"
depends on USB_MUSB_HDRC && ((BF54x && !BF544) || (BF52x && !BF522 &&
!BF523))
+config USB_MUSB_AM35X
+ boolean "AM35X MUSB support"
+ depends on USB_MUSB_HDRC && MACH_OMAP3517EVM
As I've already said, depending on the board type won't scale... :-(
+ select NOP_USB_XCEIV
+ default y
+ help
+ Select this option if your platform is based on AM35x. As
+ AM35x has an updated MUSB with CPPI4.1 DMA so this config
+ is introduced to differentiate musb ip between OMAP3x and
+ AM35x platforms.
OK, but why it's made visible?
diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
new file mode 100644
index 000..ee0c104
--- /dev/null
+++ b/drivers/usb/musb/am35x.c
@@ -0,0 +1,510 @@
+/*
+ * Texas Instruments AM35x "glue layer"
+ *
+ * Copyright (c) 2010, by Texas Instruments
+ *
+ * Based on the DA8xx "glue layer" code.
+ * Copyright (C) 2005-2006 by Texas Instruments
There's no code by TI in the DA8xx layer -- that copyright comes from the
DaVinci code.
+ * Copyright (c) 2008, MontaVista Software, Inc.
I've extended it to 2008-2009 (and should have to 2010 :-).
+/* USB interrupt register bits */
+#define USB_INTR_USB_SHIFT 16
+#define USB_INTR_USB_MASK (0x1ff << USB_INTR_USB_SHIFT)
Don't seem like good names (USB_ repeated twice)...
[...]
+int __init musb_platform_init(struct musb *musb, void *board_data)
+{
+ void __iomem *reg_base = musb->ctrl_base;
+ struct clk *otg_fck;
+ u32 rev, lvl_intr, sw_reset;
+ int status;
+
+ musb->mregs += USB_MENTOR_CORE_OFFSET;
+
+ if (musb->set_clock)
+ musb->set_clock(musb->clock, 1);
OMAP doesn't use plat->set_clock anymore, does it?
+ else
+ clk_enable(musb->clock);
+ DBG(2, "usbotg_ck=%lud\n", clk_get_rate(musb->clock));
+
+ otg_fck = clk_get(musb->controller, "fck");
+ if (IS_ERR(otg_fck)) {
+ status = PTR_ERR(otg_fck);
+ otg_fck = NULL;
This assignment does not seem necessary.
+ goto exit0;
+ }
[...]
+exit1:
+ clk_disable(otg_fck);
+exit0:
+ clk_disable(musb->clock);
+ return status;
+}
+
+int musb_platform_exit(struct musb *musb)
+{
+ struct clk *otg_fck;
+
+ if (is_host_enabled(musb))
+ del_timer_sync(&otg_workaround);
+
+ phy_off();
+
+ otg_put_transceiver(musb->xceiv);
+ usb_nop_xceiv_unregister();
+
+ if (musb->set_clock)
+ musb->set_clock(musb->clock, 0);
Looks like it may be dropped...
+ else
+ clk_disable(musb->clock);
+
+ otg_fck = clk_get(musb->controller, "fck");
Isn't it better to store this in some static variable? I don't think there's
or there'll be multiple instances of MUSB on AM35x...
+ if (IS_ERR(otg_fck)) {
+ DBG(2, "clk_get() failed for otg_fck.\n");
+ } else {
+ clk_put(otg_fck);
+ clk_put(otg_fck);
+ clk_disable(otg_fck);
+ }
+
+ return 0;
+}
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3 v4] musb: add musb support for AM35x
On 09/29/10 14:45, Ajay Kumar Gupta wrote: > AM35x has musb interface and uses CPPI4.1 DMA engine. > Current patch supports only PIO mode. DMA support can be > added later once basic CPPI4.1 DMA patch is accepted. > > Also added USB_MUSB_AM35X which is required to differentiate musb ips > between OMAP3x and AM35x. This config would be used to for below > purposes, > - Select am35x.c instead of omap2430.c for compilation > at drivers/usb/musb directory. Please note there are > significant differneces in these two files as musb ip > in quite different on AM35x. > - Select workaround codes applicable for AM35x musb issues. > one such workaround is for bytewise read issue on AM35x. > > Signed-off-by: Ajay Kumar Gupta > --- > Changes from v3, (Mostly based on Sergei's review comment) > - Cleaned up the clock related coding. > - Removed the setting of musb->a_wait_vcon > - Removed musb->is_active = 1 from isr routine. > - Moved the GPIOMODE and DATA_POLARITY PHY config to board files. > - Didn't add SESSSION bit write in otg_time for OTG_STATE_B_IDLE > case as it always makes Vbus in switched on state. > - Removed waiting loop in musb_platform_exit() function. > > drivers/usb/musb/Kconfig | 13 +- > drivers/usb/musb/Makefile |4 + > drivers/usb/musb/am35x.c | 510 > + > 3 files changed, 526 insertions(+), 1 deletions(-) > create mode 100644 drivers/usb/musb/am35x.c > > diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig > index 1dd21c2..0941a32 100644 > --- a/drivers/usb/musb/Kconfig > +++ b/drivers/usb/musb/Kconfig > @@ -60,6 +60,17 @@ comment "OMAP 44xx high speed USB support" > comment "Blackfin high speed USB Support" > depends on USB_MUSB_HDRC && ((BF54x && !BF544) || (BF52x && !BF522 && > !BF523)) > > +config USB_MUSB_AM35X > + boolean "AM35X MUSB support" > + depends on USB_MUSB_HDRC && MACH_OMAP3517EVM > + select NOP_USB_XCEIV > + default y > + help > + Select this option if your platform is based on AM35x. As > + AM35x has an updated MUSB with CPPI4.1 DMA so this config > + is introduced to differentiate musb ip between OMAP3x and > + AM35x platforms. > + > config USB_TUSB6010 > boolean "TUSB 6010 support" > depends on USB_MUSB_HDRC && !USB_MUSB_SOC > @@ -147,7 +158,7 @@ config USB_MUSB_HDRC_HCD > config MUSB_PIO_ONLY > bool 'Disable DMA (always use PIO)' > depends on USB_MUSB_HDRC > - default USB_TUSB6010 || ARCH_DAVINCI_DA8XX > + default USB_TUSB6010 || ARCH_DAVINCI_DA8XX || USB_MUSB_AM35X > help > All data is copied between memory and FIFO by the CPU. > DMA controllers are ignored. > diff --git a/drivers/usb/musb/Makefile b/drivers/usb/musb/Makefile > index f664ecf..217363d 100644 > --- a/drivers/usb/musb/Makefile > +++ b/drivers/usb/musb/Makefile > @@ -23,7 +23,11 @@ ifeq ($(CONFIG_ARCH_OMAP2430),y) > endif > > ifeq ($(CONFIG_ARCH_OMAP3430),y) > + ifeq ($(CONFIG_USB_MUSB_AM35X),y) > + musb_hdrc-objs += am35x.o > + else > musb_hdrc-objs += omap2430.o > + endif > endif > > ifeq ($(CONFIG_ARCH_OMAP4),y) > diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c > new file mode 100644 > index 000..ee0c104 > --- /dev/null > +++ b/drivers/usb/musb/am35x.c > @@ -0,0 +1,510 @@ > +/* > + * Texas Instruments AM35x "glue layer" > + * > + * Copyright (c) 2010, by Texas Instruments > + * > + * Based on the DA8xx "glue layer" code. > + * Copyright (C) 2005-2006 by Texas Instruments > + * Copyright (c) 2008, MontaVista Software, Inc. > + * > + * This file is part of the Inventra Controller Driver for Linux. > + * > + * The Inventra Controller Driver for Linux 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. > + * > + * The Inventra Controller Driver for Linux 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 The Inventra Controller Driver for Linux ; if not, > + * write to the Free Software Foundation, Inc., 59 Temple Place, > + * Suite 330, Boston, MA 02111-1307 USA > + * > + */ > + > +#include > +#include > +#include > + > +#include > +#include > + > +#include "musb_core.h" > + > +/* > + * AM35x specific definitions > + */ > +/* USB 2.0 OTG module registers */ > +#define USB_REVISION_REG 0x00 > +#define USB_CTRL_REG 0x04 > +#define USB_STAT_REG 0x08 > +#define USB_EMULATION_REG0x0c > +/* 0x10 Reserved */ > +#define USB_AUTOREQ_REG 0
Re: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c
"Varadarajan, Charulatha" writes: > Kevin, > >> -Original Message- >> From: Kevin Hilman [mailto:khil...@deeprootsystems.com] >> Sent: Tuesday, September 28, 2010 11:55 PM >> To: linux-omap@vger.kernel.org >> Cc: Varadarajan, Charulatha; Nayak, Rajendra; Raja, Govindraj >> Subject: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, >> UART, i2c >> >> Tony, >> >> The following pull request will bring hwmod driver conversions for >> watchdog, UART and i2c drivers. It is based on your omap-for-linus >> branch. >> >> The i2c driver is waiting for final signoff/ack from the upstream >> subsystem maintainers, but are otherwise ready to go for broader >> testing. After I get the final ack, I will update the branch for a >> final pull. >> >> In the meantime, I'd like to get them into l-o master (or omap-testing) >> for broader testing. >> >> Note this also depends on a handful of patches from my pm-backports >> branch, most of which you have picked into omap-testing, except for the >> one I just posted to linux-arm-kernel: >> >>ARM: add cpu_idle_wait() to support CPUidle on SMP systems. >> >> This one is required now that the default config enables SMP. >> >> Charu, Rajendra, Govindraj, since all of the hwmod data changes touch >> the same files, pulling these together meant I had to manually merge >> these together. Please do a sanity check of the resulting merge. >> Thanks. > > Minor observations as mentioned below. Charu, thanks for the review. I need to look at this closer. Rather than me trying to solve this with a manual merge, I may have to request the various authors to rebase. Kevin >> >> Kevin >> >> >> The following changes since commit >> b6a26b4b87d7b030a546e7bdaf390ffc58323f36: > > <> > >> >> arch/arm/mach-omap1/devices.c | 27 + >> arch/arm/mach-omap2/Kconfig | 11 +- >> arch/arm/mach-omap2/board-3630sdp.c |1 - >> arch/arm/mach-omap2/board-zoom-peripherals.c |1 + >> arch/arm/mach-omap2/clock3xxx_data.c | 22 + >> arch/arm/mach-omap2/cm-regbits-24xx.h |4 + >> arch/arm/mach-omap2/cm-regbits-34xx.h |2 + >> arch/arm/mach-omap2/devices.c | 39 + >> arch/arm/mach-omap2/omap_hwmod_2420_data.c| 397 - > > "cm-regbits-24xx.h" is included twice in this file > >> arch/arm/mach-omap2/omap_hwmod_2430_data.c| 410 - >> arch/arm/mach-omap2/omap_hwmod_3xxx_data.c| 549 ++- >> arch/arm/mach-omap2/omap_hwmod_44xx_data.c| 605 +++ > > The order of hwmod structures for different modules are mixed up. > Example, under 'wd_timer' class, uart sysc definitions are placed. > >> arch/arm/mach-omap2/pm34xx.c | 17 +- >> arch/arm/mach-omap2/prcm-common.h |5 + >> arch/arm/mach-omap2/prm-regbits-34xx.h|4 + >> arch/arm/mach-omap2/serial.c | 555 ++- >> arch/arm/plat-omap/common.c | 16 - >> arch/arm/plat-omap/devices.c | 41 - >> arch/arm/plat-omap/i2c.c | 124 +-- >> arch/arm/plat-omap/include/plat/common.h |1 - >> arch/arm/plat-omap/include/plat/dma.h |2 + >> arch/arm/plat-omap/include/plat/i2c.h | 13 + >> arch/arm/plat-omap/include/plat/irqs.h|2 + >> arch/arm/plat-omap/include/plat/l4_3xxx.h | 24 + >> arch/arm/plat-omap/include/plat/omap-serial.h | 129 +++ >> drivers/i2c/busses/i2c-omap.c | 69 +- >> drivers/serial/Kconfig| 27 + >> drivers/serial/Makefile |1 + >> drivers/serial/omap-serial.c | 1333 >> + >> drivers/watchdog/omap_wdt.c | 42 +- >> include/linux/i2c-omap.h |5 + >> include/linux/serial_core.h |3 + >> 32 files changed, 3984 insertions(+), 497 deletions(-) >> create mode 100644 arch/arm/plat-omap/include/plat/l4_3xxx.h >> create mode 100644 arch/arm/plat-omap/include/plat/omap-serial.h >> create mode 100644 drivers/serial/omap-serial.c > -- > 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 -- 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 01/14] ARM: mmu: Setup MT_MEMORY and MT_MEMORY_NONCACHED L1 entries
On Wed, Sep 29, 2010 at 03:51:21PM +0100, Catalin Marinas wrote:
> Hi Santosh,
>
> Santosh Shilimkar wrote:
> > This patch populates the L1 entries for MT_MEMORY and MT_MEMORY_NONCACHED
> > types so that at boot-up, we can map memories outside system memory
> > at page level granularity
> >
> > Previously the mapping was limiting to section level, which creates
> > unnecessary addiotional mapping for which physical memory may not
> > present. On the newer ARM with speculation, this is dangerous and can
> > result in untraceable aborts.
> >
> > Signed-off-by: Santosh Shilimkar
> > Reviewed-by: Russell King
> > ---
> > arch/arm/mm/mmu.c | 17 +++--
> > 1 files changed, 15 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> > index 6e1c4f6..3e986a6 100644
> > --- a/arch/arm/mm/mmu.c
> > +++ b/arch/arm/mm/mmu.c
> > @@ -246,6 +246,9 @@ static struct mem_type mem_types[] = {
> > .domain= DOMAIN_USER,
> > },
> > [MT_MEMORY] = {
> > + .prot_pte = L_PTE_PRESENT | L_PTE_YOUNG | L_PTE_DIRTY |
> > + L_PTE_USER | L_PTE_EXEC,
> > + .prot_l1 = PMD_TYPE_TABLE,
>
> Just a quick question - does this need to have L_PTE_USER? Is it
> read-only or it needs L_PTE_WRITE as well?
Eek. It should not have L_PTE_USER or else it will be accessible to
userspace.
--
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 01/14] ARM: mmu: Setup MT_MEMORY and MT_MEMORY_NONCACHED L1 entries
> -Original Message-
> From: Catalin Marinas [mailto:catalin.mari...@arm.com]
> Sent: Wednesday, September 29, 2010 8:21 PM
> To: Shilimkar, Santosh
> Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH 01/14] ARM: mmu: Setup MT_MEMORY and
> MT_MEMORY_NONCACHED L1 entries
>
> Hi Santosh,
>
> Santosh Shilimkar wrote:
> > This patch populates the L1 entries for MT_MEMORY and
> MT_MEMORY_NONCACHED
> > types so that at boot-up, we can map memories outside system memory
> > at page level granularity
> >
> > Previously the mapping was limiting to section level, which creates
> > unnecessary addiotional mapping for which physical memory may not
> > present. On the newer ARM with speculation, this is dangerous and can
> > result in untraceable aborts.
> >
> > Signed-off-by: Santosh Shilimkar
> > Reviewed-by: Russell King
> > ---
> > arch/arm/mm/mmu.c | 17 +++--
> > 1 files changed, 15 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> > index 6e1c4f6..3e986a6 100644
> > --- a/arch/arm/mm/mmu.c
> > +++ b/arch/arm/mm/mmu.c
> > @@ -246,6 +246,9 @@ static struct mem_type mem_types[] = {
> > .domain= DOMAIN_USER,
> > },
> > [MT_MEMORY] = {
> > + .prot_pte = L_PTE_PRESENT | L_PTE_YOUNG | L_PTE_DIRTY |
> > + L_PTE_USER | L_PTE_EXEC,
> > + .prot_l1 = PMD_TYPE_TABLE,
>
> Just a quick question - does this need to have L_PTE_USER? Is it
> read-only or it needs L_PTE_WRITE as well?
>
I think you are right. It should have "L_PTE_WRITE" as well.
Regards,
Santosh
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3 v4] musb: AM35x: Workaround for fifo read issue
Hello.
Ajay Kumar Gupta wrote:
AM35x supports only 32bit read operations so we need to have
workaround for 8bit and 16bit read operations.
Signed-off-by: Ajay Kumar Gupta
drivers/usb/musb/am35x.c | 30 ++
drivers/usb/musb/musb_core.c |2 ++
2 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index ee0c104..dce99fc 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -508,3 +508,33 @@ void musb_platform_restore_context(struct musb *musb,
phy_on();
}
#endif
+
+/* AM35x supports only 32bit read operation */
+void musb_read_fifo(struct musb_hw_ep *hw_ep, u16 len, u8 *dst)
+{
+ void __iomem *fifo = hw_ep->fifo;
+ u32 val;
+ int i;
+
+ /* Read for 32bit-aligned destination address */
+ if (likely((0x03 & (unsigned long) dst) == 0) && len >= 4) {
+ readsl(fifo, dst, len >> 2);
+ dst += len & ~0x03;
+ len &= 0x03;
+ }
+ /*
+* Now read the rest 1 to 3 bytes or complete length if
s/rest/remaining/
+* unaligned address.
+*/
+ if (len > 4) {
+ for (i = 0; i < (len >> 2); i++) {
+ *(u32 *) dst = musb_readl(fifo, 0);
+ dst += 4;
+ }
+ len %= 4;
Why not 'len &= 0x03' like above?
WBR, Sergei
--
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: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, UART, i2c
Kevin, > -Original Message- > From: Kevin Hilman [mailto:khil...@deeprootsystems.com] > Sent: Tuesday, September 28, 2010 11:55 PM > To: linux-omap@vger.kernel.org > Cc: Varadarajan, Charulatha; Nayak, Rajendra; Raja, Govindraj > Subject: [GIT PULL] for testing: OMAP hwmod driver conversions: watchdog, > UART, i2c > > Tony, > > The following pull request will bring hwmod driver conversions for > watchdog, UART and i2c drivers. It is based on your omap-for-linus > branch. > > The i2c driver is waiting for final signoff/ack from the upstream > subsystem maintainers, but are otherwise ready to go for broader > testing. After I get the final ack, I will update the branch for a > final pull. > > In the meantime, I'd like to get them into l-o master (or omap-testing) > for broader testing. > > Note this also depends on a handful of patches from my pm-backports > branch, most of which you have picked into omap-testing, except for the > one I just posted to linux-arm-kernel: > >ARM: add cpu_idle_wait() to support CPUidle on SMP systems. > > This one is required now that the default config enables SMP. > > Charu, Rajendra, Govindraj, since all of the hwmod data changes touch > the same files, pulling these together meant I had to manually merge > these together. Please do a sanity check of the resulting merge. > Thanks. Minor observations as mentioned below. > > Kevin > > > The following changes since commit > b6a26b4b87d7b030a546e7bdaf390ffc58323f36: <> > > arch/arm/mach-omap1/devices.c | 27 + > arch/arm/mach-omap2/Kconfig | 11 +- > arch/arm/mach-omap2/board-3630sdp.c |1 - > arch/arm/mach-omap2/board-zoom-peripherals.c |1 + > arch/arm/mach-omap2/clock3xxx_data.c | 22 + > arch/arm/mach-omap2/cm-regbits-24xx.h |4 + > arch/arm/mach-omap2/cm-regbits-34xx.h |2 + > arch/arm/mach-omap2/devices.c | 39 + > arch/arm/mach-omap2/omap_hwmod_2420_data.c| 397 - "cm-regbits-24xx.h" is included twice in this file > arch/arm/mach-omap2/omap_hwmod_2430_data.c| 410 - > arch/arm/mach-omap2/omap_hwmod_3xxx_data.c| 549 ++- > arch/arm/mach-omap2/omap_hwmod_44xx_data.c| 605 +++ The order of hwmod structures for different modules are mixed up. Example, under 'wd_timer' class, uart sysc definitions are placed. > arch/arm/mach-omap2/pm34xx.c | 17 +- > arch/arm/mach-omap2/prcm-common.h |5 + > arch/arm/mach-omap2/prm-regbits-34xx.h|4 + > arch/arm/mach-omap2/serial.c | 555 ++- > arch/arm/plat-omap/common.c | 16 - > arch/arm/plat-omap/devices.c | 41 - > arch/arm/plat-omap/i2c.c | 124 +-- > arch/arm/plat-omap/include/plat/common.h |1 - > arch/arm/plat-omap/include/plat/dma.h |2 + > arch/arm/plat-omap/include/plat/i2c.h | 13 + > arch/arm/plat-omap/include/plat/irqs.h|2 + > arch/arm/plat-omap/include/plat/l4_3xxx.h | 24 + > arch/arm/plat-omap/include/plat/omap-serial.h | 129 +++ > drivers/i2c/busses/i2c-omap.c | 69 +- > drivers/serial/Kconfig| 27 + > drivers/serial/Makefile |1 + > drivers/serial/omap-serial.c | 1333 > + > drivers/watchdog/omap_wdt.c | 42 +- > include/linux/i2c-omap.h |5 + > include/linux/serial_core.h |3 + > 32 files changed, 3984 insertions(+), 497 deletions(-) > create mode 100644 arch/arm/plat-omap/include/plat/l4_3xxx.h > create mode 100644 arch/arm/plat-omap/include/plat/omap-serial.h > create mode 100644 drivers/serial/omap-serial.c -- 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 01/14] ARM: mmu: Setup MT_MEMORY and MT_MEMORY_NONCACHED L1 entries
Hi Santosh,
Santosh Shilimkar wrote:
> This patch populates the L1 entries for MT_MEMORY and MT_MEMORY_NONCACHED
> types so that at boot-up, we can map memories outside system memory
> at page level granularity
>
> Previously the mapping was limiting to section level, which creates
> unnecessary addiotional mapping for which physical memory may not
> present. On the newer ARM with speculation, this is dangerous and can
> result in untraceable aborts.
>
> Signed-off-by: Santosh Shilimkar
> Reviewed-by: Russell King
> ---
> arch/arm/mm/mmu.c | 17 +++--
> 1 files changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> index 6e1c4f6..3e986a6 100644
> --- a/arch/arm/mm/mmu.c
> +++ b/arch/arm/mm/mmu.c
> @@ -246,6 +246,9 @@ static struct mem_type mem_types[] = {
> .domain= DOMAIN_USER,
> },
> [MT_MEMORY] = {
> + .prot_pte = L_PTE_PRESENT | L_PTE_YOUNG | L_PTE_DIRTY |
> + L_PTE_USER | L_PTE_EXEC,
> + .prot_l1 = PMD_TYPE_TABLE,
Just a quick question - does this need to have L_PTE_USER? Is it
read-only or it needs L_PTE_WRITE as well?
Thanks.
--
Catalin
--
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 v8 0/6] OMAP: WDT: Implement WDT in hwmod way
Kevin, > -Original Message- > From: Kevin Hilman [mailto:khil...@deeprootsystems.com] <> > >> > >> I found a little snag with this series. Try testing with > >> omap2plus_defconfig and changing CONFIG_OMAP_WATCHDOG=n. > >> > >> If CONFIG_OMAP_WATCHDOG is not enabled in the kernel config, the system > >> will reboot soon after bootup. > > > > Thanks for finding this issue. > > > > After watchdog module reset, the WDTs are enabled. The default time > > for a system reset after a watchdog module reset is ~10s as per the > > default value of the WDT registers. Hence the above problem is observed. > > > > If CONFIG_OMAP_WATCHDOG is defined, wdt's probe is called within this > > 10s time and watchdog_disable is called during probe. Hence we are not > > finding this issue if CONFIG_OMAP_WATCHDOG is defined. > > > > Ideally, because of the above, watchdog should be with > > HWMOD_INIT_NO_RESET flag. > > > > If agreed, I would send the below patch (extended to other OMAPs) > > on top of my watchdog timer hwmod series with proper change log. > > Using HWMOD_INIT_NO_RESET makes us still dependent on the bootloader > settings. Agreed. > > Instead, I would rather have a small piece of code in omap_init_wdt() > which disarms the watchdog so we don't have any assumptions about > bootloader behavior. > > The question remains whether this disarm should be > #ifndef CONFIG_OMAP_WATCHDOG or if it should happen all the time. In > case the watchdog is a module, it's probe may not happen within the > timeout period and they system may reboot also, so I lean towards > disarming the watchdog unconditionally. Agreed. But this shall be handled in mach-omap2/devices.c by directly accessing the watchdog registers and disabling it, as the watchdog driver would not be available by this time. If this okay, I would send a separate patch on top my hwmod series to handle this. -V Charulatha <> -- 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 07/11] OMAP3: PM: Adding T2 enabling of smartreflex support
>>-Original Message-
>>From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
>>Sent: Wednesday, September 29, 2010 5:38 AM
>>To: Gopinath, Thara
>>Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy,
>>Vishwanath; Sawant, Anand
>>Subject: Re: [PATCH v3 07/11] OMAP3: PM: Adding T2 enabling of smartreflex
>>support
>>
>>Thara Gopinath writes:
>>
>>> This patch adds support in the twl4030 driver to hook up
>>> the API enabling smartreflex support on PMIC side with the
>>> smartreflex driver. Without this the OMAP smartreflex modules
>>> will not function.
>>>
>>> Signed-off-by: Thara Gopinath
>>
>>This one should be a separate patch with a subject something like
>>
>> mfd: twl4030: add SmartReflex support
>>
>>and the changelog should indicate its dependency on this SR/voltage
>>series.
Do you mean to say this patch should not be a part of this series at all ??
Regards
Thara
>>
>>Kevin
>>
>>> ---
>>> drivers/mfd/twl-core.c |7 +--
>>> drivers/mfd/twl4030-power.c | 29 +
>>> include/linux/i2c/twl.h |1 +
>>> 3 files changed, 35 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
>>> index 720e099..677b903 100644
>>> --- a/drivers/mfd/twl-core.c
>>> +++ b/drivers/mfd/twl-core.c
>>> @@ -1009,8 +1009,11 @@ twl_probe(struct i2c_client *client, const struct
>>i2c_device_id *id)
>>> clocks_init(&client->dev, pdata->clock);
>>>
>>> /* load power event scripts */
>>> - if (twl_has_power() && pdata->power)
>>> - twl4030_power_init(pdata->power);
>>> + if (twl_has_power()) {
>>> + twl4030_power_sr_init();
>>> +if (pdata->power)
>>> + twl4030_power_init(pdata->power);
>>> + }
>>>
>>> /* Maybe init the T2 Interrupt subsystem */
>>> if (client->irq
>>> diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
>>> index 7efa878..6d0ad2d 100644
>>> --- a/drivers/mfd/twl4030-power.c
>>> +++ b/drivers/mfd/twl4030-power.c
>>> @@ -31,6 +31,8 @@
>>>
>>> #include
>>>
>>> +#include
>>> +
>>> static u8 twl4030_start_script_address = 0x2b;
>>>
>>> #define PWR_P1_SW_EVENTS 0x10
>>> @@ -63,6 +65,10 @@ static u8 twl4030_start_script_address = 0x2b;
>>> #define R_MEMORY_ADDRESS PHY_TO_OFF_PM_MASTER(0x59)
>>> #define R_MEMORY_DATA PHY_TO_OFF_PM_MASTER(0x5a)
>>>
>>> +/* Smartreflex Control */
>>> +#define R_DCDC_GLOBAL_CFG PHY_TO_OFF_PM_RECEIVER(0x61)
>>> +#define CFG_ENABLE_SRFLX 0x08
>>> +
>>> #define R_PROTECT_KEY 0x0E
>>> #define R_KEY_10xC0
>>> #define R_KEY_20x0C
>>> @@ -511,6 +517,29 @@ int twl4030_remove_script(u8 flags)
>>> return err;
>>> }
>>>
>>> +/* API to enable smrtreflex on Triton side */
>>> +static void twl4030_smartreflex_init(void)
>>> +{
>>> + int ret = 0;
>>> + u8 read_val;
>>> +
>>> + ret = twl_i2c_read_u8(TWL4030_MODULE_PM_RECEIVER, &read_val,
>>> + R_DCDC_GLOBAL_CFG);
>>> + read_val |= CFG_ENABLE_SRFLX;
>>> + ret |= twl_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, read_val,
>>> + R_DCDC_GLOBAL_CFG);
>>> +}
>>> +
>>> +struct omap_smartreflex_pmic_data twl4030_sr_data = {
>>> + .sr_pmic_init = twl4030_smartreflex_init,
>>> +};
>>> +
>>> +void __init twl4030_power_sr_init()
>>> +{
>>> + /* Register the SR init API with the Smartreflex driver */
>>> + omap_sr_register_pmic(&twl4030_sr_data);
>>> +}
>>> +
>>> void __init twl4030_power_init(struct twl4030_power_data *twl4030_scripts)
>>> {
>>> int err = 0;
>>> diff --git a/include/linux/i2c/twl.h b/include/linux/i2c/twl.h
>>> index 6de90bf..b02011e 100644
>>> --- a/include/linux/i2c/twl.h
>>> +++ b/include/linux/i2c/twl.h
>>> @@ -550,6 +550,7 @@ struct twl4030_power_data {
>>> };
>>>
>>> extern void twl4030_power_init(struct twl4030_power_data
>>*triton2_scripts);
>>> +extern void twl4030_power_sr_init(void);
>>> extern int twl4030_remove_script(u8 flags);
>>>
>>> struct twl4030_codec_audio_data {
--
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 03/11] OMAP3: PM: Adding smartreflex driver support.
>>-Original Message-
>>From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
>>Sent: Wednesday, September 29, 2010 5:01 AM
>>To: Gopinath, Thara
>>Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy,
>>Vishwanath; Sawant, Anand
>>Subject: Re: [PATCH v3 03/11] OMAP3: PM: Adding smartreflex driver support.
>>
>>Thara Gopinath writes:
>>
>>> SmartReflex modules do adaptive voltage control for real-time
>>> voltage adjustments. With Smartreflex the power supply voltage
>>> can be adapted to the silicon performance(manufacturing process,
>>> temperature induced performance, age induced performance etc).
>>>
>>> There are differnet classes of smartreflex implementation.
>>> Class-0: Manufacturing Test Calibration
>>> Class-1: Boot-Time Software Calibration
>>> Class-2: Continuous Software Calibration
>>> Class-3: Continuous Hardware Calibration
>>> Class-4: Fully Integrated Power Management
>>>
>>> OMAP3 has two smartreflex modules one associated with VDD1 and the
>>> other associated with VDD2.
>>> This patch adds support for smartreflex driver. The driver is designed
>>> for Class-1 , Class-2 and Class-3 support and is a platform driver.
>>> Smartreflex driver can be enabled through a Kconfig option
>>> "SmartReflex support" under "System type"->"TI OMAP implementations" menu.
>>>
>>> Smartreflex autocompensation feature can be enabled runtime through
>>> a debug fs option.
>>> To enable smartreflex autocompensation feature
>>> echo 1 > /debugfs/pm_debug/smartreflex/sr_/autocomp
>>> To disable smartreflex autocompensation feature
>>> echo 0 > /debugfs/pm_debug/smartreflex/sr_/autocomp
>>>
>>> where X can be mpu, core , iva etc.
>>>
>>
>>[...]
>>
>>> +static void sr_set_regfields(struct omap_sr *sr)
>>> +{
>>> + /*
>>> +* For time being these values are defined in smartreflex.h
>>> +* and populated during init. May be they can be moved to board
>>> +* file or pmic specific data structure. In that case these structure
>>> +* fields will have to be populated using the pdata or pmic structure.
>>> +*/
>>> + if (cpu_is_omap34xx()) {
>>> + sr->err_weight = OMAP3430_SR_ERRWEIGHT;
>>> + sr->err_maxlimit = OMAP3430_SR_ERRMAXLIMIT;
>>> + sr->accum_data = OMAP3430_SR_ACCUMDATA;
>>> + if (!(strcmp(sr->voltdm->name, "mpu"))) {
>>> + sr->senn_avgweight = OMAP3430_SR1_SENNAVGWEIGHT;
>>> + sr->senp_avgweight = OMAP3430_SR1_SENPAVGWEIGHT;
>>> + } else {
>>> + sr->senn_avgweight = OMAP3430_SR2_SENNAVGWEIGHT;
>>> + sr->senp_avgweight = OMAP3430_SR2_SENPAVGWEIGHT;
>>> + }
>>> + }
>>> + /* TODO: 3630 and Omap4 specific bit field values */
>>
>>This comment is still present even after the OMAP4 series is applied.
>>
>>[...]
>>
>>> +/*
>>> + * 3430 specific values. Maybe these should be passed from board file or
>>> + * pmic structures.
>>> + */
>>> +#define OMAP3430_SR_ACCUMDATA 0x1f4
>>> +
>>> +#define OMAP3430_SR1_SENPAVGWEIGHT 0x03
>>> +#define OMAP3430_SR1_SENNAVGWEIGHT 0x03
>>> +
>>> +#define OMAP3430_SR2_SENPAVGWEIGHT 0x01
>>> +#define OMAP3430_SR2_SENNAVGWEIGHT 0x01
>>> +
>>> +#define OMAP3430_SR_ERRWEIGHT 0x04
>>> +#define OMAP3430_SR_ERRMAXLIMIT0x02
>>> +
>>> +/* TODO:3630/OMAP4 values if it has to come from this file */
>>
>>ditto
>>
>>It's best to just not put these kind of things into the code in the
>>first place, they tend to be forgotten and stale quickly.
Will fix this and post V4.
>>
>>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 2/9 v3] usb: musb: Remove board_data parameter from musb_platform_init()
Hema HK writes:
> Removed the board_data parameter being passed to musb_platform_init function
> as board data can be extracted from device structure which is already member
> of
> musb structure.
>
> Signed-off-by: Hema HK
> Cc: Felipe Balbi
> Cc: Tony Lindgren
> Cc: Kevin Hilman
> Cc: Cousson, Benoit
> Cc: Paul Walmsley
For the davinci changes:
Acked-by: Kevin Hilman
Kevin
> ---
> drivers/usb/musb/blackfin.c |2 +-
> drivers/usb/musb/davinci.c |2 +-
> drivers/usb/musb/musb_core.c |2 +-
> drivers/usb/musb/musb_core.h |2 +-
> drivers/usb/musb/omap2430.c |6 --
> drivers/usb/musb/tusb6010.c |2 +-
> 6 files changed, 9 insertions(+), 7 deletions(-)
>
> Index: linux-omap-pm/drivers/usb/musb/blackfin.c
> ===
> --- linux-omap-pm.orig/drivers/usb/musb/blackfin.c
> +++ linux-omap-pm/drivers/usb/musb/blackfin.c
> @@ -323,7 +323,7 @@ int musb_platform_set_mode(struct musb *
> return -EIO;
> }
>
> -int __init musb_platform_init(struct musb *musb, void *board_data)
> +int __init musb_platform_init(struct musb *musb)
> {
>
> /*
> Index: linux-omap-pm/drivers/usb/musb/davinci.c
> ===
> --- linux-omap-pm.orig/drivers/usb/musb/davinci.c
> +++ linux-omap-pm/drivers/usb/musb/davinci.c
> @@ -376,7 +376,7 @@ int musb_platform_set_mode(struct musb *
> return -EIO;
> }
>
> -int __init musb_platform_init(struct musb *musb, void *board_data)
> +int __init musb_platform_init(struct musb *musb)
> {
> void __iomem*tibase = musb->ctrl_base;
> u32 revision;
> Index: linux-omap-pm/drivers/usb/musb/musb_core.c
> ===
> --- linux-omap-pm.orig/drivers/usb/musb/musb_core.c
> +++ linux-omap-pm/drivers/usb/musb/musb_core.c
> @@ -2022,7 +2022,7 @@ bad_config:
>* isp1504, non-OTG, etc) mostly hooking up through ULPI.
>*/
> musb->isr = generic_interrupt;
> - status = musb_platform_init(musb, plat->board_data);
> + status = musb_platform_init(musb);
> if (status < 0)
> goto fail2;
>
> Index: linux-omap-pm/drivers/usb/musb/musb_core.h
> ===
> --- linux-omap-pm.orig/drivers/usb/musb/musb_core.h
> +++ linux-omap-pm/drivers/usb/musb/musb_core.h
> @@ -612,7 +612,7 @@ extern int musb_platform_get_vbus_status
> #define musb_platform_get_vbus_status(x) 0
> #endif
>
> -extern int __init musb_platform_init(struct musb *musb, void *board_data);
> +extern int __init musb_platform_init(struct musb *musb);
> extern int musb_platform_exit(struct musb *musb);
>
> #endif /* __MUSB_CORE_H__ */
> Index: linux-omap-pm/drivers/usb/musb/omap2430.c
> ===
> --- linux-omap-pm.orig/drivers/usb/musb/omap2430.c
> +++ linux-omap-pm/drivers/usb/musb/omap2430.c
> @@ -187,10 +187,12 @@ int musb_platform_set_mode(struct musb *
> return 0;
> }
>
> -int __init musb_platform_init(struct musb *musb, void *board_data)
> +int __init musb_platform_init(struct musb *musb)
> {
> u32 l;
> - struct omap_musb_board_data *data = board_data;
> + struct device *dev = musb->controller;
> + struct musb_hdrc_platform_data *plat = dev->platform_data;
> + struct omap_musb_board_data *data = plat->board_data;
>
> /* We require some kind of external transceiver, hooked
>* up through ULPI. TWL4030-family PMICs include one,
> Index: linux-omap-pm/drivers/usb/musb/tusb6010.c
> ===
> --- linux-omap-pm.orig/drivers/usb/musb/tusb6010.c
> +++ linux-omap-pm/drivers/usb/musb/tusb6010.c
> @@ -1091,7 +1091,7 @@ err:
> return -ENODEV;
> }
>
> -int __init musb_platform_init(struct musb *musb, void *board_data)
> +int __init musb_platform_init(struct musb *musb)
> {
> struct platform_device *pdev;
> struct resource *mem;
--
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 04/11] OMAP4: Extend clock data.
>>-Original Message-
>>From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
>>Sent: Wednesday, September 29, 2010 4:39 AM
>>To: Gopinath, Thara
>>Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy,
>>Vishwanath; Sawant, Anand
>>Subject: Re: [PATCH v2 04/11] OMAP4: Extend clock data.
>>
>>Thara Gopinath writes:
>>
>>> This patch extends the OMAP4 clock data to include
>>> various x2 clockc nodes as the clock framework
>>> skips a *2 whie calculating the dpll locked frequency.
>>>
>>> Signed-off-by: Thara Gopinath
>>
>>Acked-by: Kevin Hilman
>>
>>Please post this as a separate patch, and Paul can queue for 2.6.37.
Ok I will post this as a separate patch.
Regards
Thara
>>
>>Thanks,
>>
>>Kevin
>>
>>> ---
>>> arch/arm/mach-omap2/clock44xx_data.c | 40 +++---
>>---
>>> 1 files changed, 32 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-omap2/clock44xx_data.c b/arch/arm/mach-
>>omap2/clock44xx_data.c
>>> index edf2c28..3652fda 100644
>>> --- a/arch/arm/mach-omap2/clock44xx_data.c
>>> +++ b/arch/arm/mach-omap2/clock44xx_data.c
>>> @@ -481,14 +481,21 @@ static struct clk dpll_core_m5_ck = {
>>> .set_rate = &omap2_clksel_set_rate,
>>> };
>>>
>>> +static struct clk dpll_core_m5x2_ck = {
>>> + .name = "dpll_core_m5x2_ck",
>>> + .parent = &dpll_core_m5_ck,
>>> + .ops= &clkops_null,
>>> + .recalc = &omap3_clkoutx2_recalc,
>>> +};
>>> +
>>> static const struct clksel div_core_div[] = {
>>> - { .parent = &dpll_core_m5_ck, .rates = div2_1to2_rates },
>>> + { .parent = &dpll_core_m5x2_ck, .rates = div2_1to2_rates },
>>> { .parent = NULL },
>>> };
>>>
>>> static struct clk div_core_ck = {
>>> .name = "div_core_ck",
>>> - .parent = &dpll_core_m5_ck,
>>> + .parent = &dpll_core_m5x2_ck,
>>> .clksel = div_core_div,
>>> .clksel_reg = OMAP4430_CM_CLKSEL_CORE,
>>> .clksel_mask= OMAP4430_CLKSEL_CORE_MASK,
>>> @@ -507,13 +514,13 @@ static const struct clksel_rate div4_1to8_rates[] = {
>>> };
>>>
>>> static const struct clksel div_iva_hs_clk_div[] = {
>>> - { .parent = &dpll_core_m5_ck, .rates = div4_1to8_rates },
>>> + { .parent = &dpll_core_m5x2_ck, .rates = div4_1to8_rates },
>>> { .parent = NULL },
>>> };
>>>
>>> static struct clk div_iva_hs_clk = {
>>> .name = "div_iva_hs_clk",
>>> - .parent = &dpll_core_m5_ck,
>>> + .parent = &dpll_core_m5x2_ck,
>>> .clksel = div_iva_hs_clk_div,
>>> .clksel_reg = OMAP4430_CM_BYPCLK_DPLL_IVA,
>>> .clksel_mask= OMAP4430_CLKSEL_0_1_MASK,
>>> @@ -525,7 +532,7 @@ static struct clk div_iva_hs_clk = {
>>>
>>> static struct clk div_mpu_hs_clk = {
>>> .name = "div_mpu_hs_clk",
>>> - .parent = &dpll_core_m5_ck,
>>> + .parent = &dpll_core_m5x2_ck,
>>> .clksel = div_iva_hs_clk_div,
>>> .clksel_reg = OMAP4430_CM_BYPCLK_DPLL_MPU,
>>> .clksel_mask= OMAP4430_CLKSEL_0_1_MASK,
>>> @@ -651,6 +658,13 @@ static struct clk dpll_iva_m4_ck = {
>>> .set_rate = &omap2_clksel_set_rate,
>>> };
>>>
>>> +static struct clk dpll_iva_m4x2_ck = {
>>> + .name = "dpll_iva_m4x2_ck",
>>> + .parent = &dpll_iva_m4_ck,
>>> + .ops= &clkops_null,
>>> + .recalc = &omap3_clkoutx2_recalc,
>>> +};
>>> +
>>> static struct clk dpll_iva_m5_ck = {
>>> .name = "dpll_iva_m5_ck",
>>> .parent = &dpll_iva_ck,
>>> @@ -663,6 +677,13 @@ static struct clk dpll_iva_m5_ck = {
>>> .set_rate = &omap2_clksel_set_rate,
>>> };
>>>
>>> +static struct clk dpll_iva_m5x2_ck = {
>>> + .name = "dpll_iva_m5x2_ck",
>>> + .parent = &dpll_iva_m5_ck,
>>> + .ops= &clkops_null,
>>> + .recalc = &omap3_clkoutx2_recalc,
>>> +};
>>> +
>>> /* DPLL_MPU */
>>> static struct dpll_data dpll_mpu_dd = {
>>> .mult_div1_reg = OMAP4430_CM_CLKSEL_DPLL_MPU,
>>> @@ -1350,7 +1371,7 @@ static struct clk dsp_fck = {
>>> .enable_reg = OMAP4430_CM_TESLA_TESLA_CLKCTRL,
>>> .enable_bit = OMAP4430_MODULEMODE_HWCTRL,
>>> .clkdm_name = "tesla_clkdm",
>>> - .parent = &dpll_iva_m4_ck,
>>> + .parent = &dpll_iva_m4x2_ck,
>>> .recalc = &followparent_recalc,
>>> };
>>>
>>> @@ -1725,7 +1746,7 @@ static struct clk iva_fck = {
>>> .enable_reg = OMAP4430_CM_IVAHD_IVAHD_CLKCTRL,
>>> .enable_bit = OMAP4430_MODULEMODE_HWCTRL,
>>> .clkdm_name = "ivahd_clkdm",
>>> - .parent = &dpll_iva_m5_ck,
>>> + .parent = &dpll_iva_m5x2_ck,
>>> .recalc = &followparent_recalc,
>>> };
>>>
>>> @@ -2089,7 +2110,7 @@ static struct clk sl2if_ick = {
>>> .enable_reg = OMAP4430_CM_IVAHD_SL2_CLKCTRL,
>>> .enable_bit = OMAP4430_MODULEMODE_HWCTRL,
>>> .clkdm_name = "ivahd_clkdm",
>>> - .parent = &dpll_i
Re: [PATCH v4] usb: musb: Adding names for IRQs in resource structure
Hema HK writes:
> The resource data is getting automatically populated from a set of data
> generated from TI's hardware database for the OMAP platform,
> While we could hack in some exceptions to that tool to generate resources
> in a specific order, it seems less fragile to use the resource name
> instead.That way, no matter what order the resources are generated, the
> driver still work.
>
> Modified the OMAP,Blackfin and Davinci architecture files to add the name of
> the IRQs
> in the resource structures and musb driver to use the get_irq_byname() api to
> get the device and dma irq numbers instead of using the index.
>
> Signed-off-by: Hema HK
> Cc: Felipe Balbi
> Cc: Tony Lindgren
> Cc: Kevin Hilman
> Cc: Cousson, Benoit
> Cc: Paul Walmsley
> Cc: Mike Frysinger
> ---
For the davinci changes:
Acked-by: Kevin Hilman
Kevin
> [Updated the changelog with background]
>
> arch/arm/mach-davinci/usb.c|2 ++
> arch/arm/mach-omap2/usb-musb.c |2 ++
> arch/blackfin/mach-bf527/boards/cm_bf527.c |2 ++
> arch/blackfin/mach-bf527/boards/ezbrd.c|2 ++
> arch/blackfin/mach-bf527/boards/ezkit.c|2 ++
> arch/blackfin/mach-bf548/boards/cm_bf548.c |2 ++
> arch/blackfin/mach-bf548/boards/ezkit.c|2 ++
> drivers/usb/musb/cppi_dma.c|2 +-
> drivers/usb/musb/musb_core.c |2 +-
> drivers/usb/musb/musbhsdma.c |2 +-
> 10 files changed, 17 insertions(+), 3 deletions(-)
>
> Index: linux-omap-pm/arch/arm/mach-davinci/usb.c
> ===
> --- linux-omap-pm.orig/arch/arm/mach-davinci/usb.c
> +++ linux-omap-pm/arch/arm/mach-davinci/usb.c
> @@ -64,10 +64,12 @@ static struct resource usb_resources[] =
> {
> .start = IRQ_USBINT,
> .flags = IORESOURCE_IRQ,
> + .name = "mc"
> },
> {
> /* placeholder for the dedicated CPPI IRQ */
> .flags = IORESOURCE_IRQ,
> + .name = "dma"
> },
> };
>
> Index: linux-omap-pm/arch/arm/mach-omap2/usb-musb.c
> ===
> --- linux-omap-pm.orig/arch/arm/mach-omap2/usb-musb.c
> +++ linux-omap-pm/arch/arm/mach-omap2/usb-musb.c
> @@ -39,10 +39,12 @@ static struct resource musb_resources[]
> [1] = { /* general IRQ */
> .start = INT_243X_HS_USB_MC,
> .flags = IORESOURCE_IRQ,
> + .name = "mc",
> },
> [2] = { /* DMA IRQ */
> .start = INT_243X_HS_USB_DMA,
> .flags = IORESOURCE_IRQ,
> + .name = "dma",
> },
> };
>
> Index: linux-omap-pm/arch/blackfin/mach-bf527/boards/cm_bf527.c
> ===
> --- linux-omap-pm.orig/arch/blackfin/mach-bf527/boards/cm_bf527.c
> +++ linux-omap-pm/arch/blackfin/mach-bf527/boards/cm_bf527.c
> @@ -82,11 +82,13 @@ static struct resource musb_resources[]
> .start = IRQ_USB_INT0,
> .end= IRQ_USB_INT0,
> .flags = IORESOURCE_IRQ | IORESOURCE_IRQ_HIGHLEVEL,
> + .name = "mc"
> },
> [2] = { /* DMA IRQ */
> .start = IRQ_USB_DMA,
> .end= IRQ_USB_DMA,
> .flags = IORESOURCE_IRQ | IORESOURCE_IRQ_HIGHLEVEL,
> + .name = "dma"
> },
> };
>
> Index: linux-omap-pm/arch/blackfin/mach-bf527/boards/ezbrd.c
> ===
> --- linux-omap-pm.orig/arch/blackfin/mach-bf527/boards/ezbrd.c
> +++ linux-omap-pm/arch/blackfin/mach-bf527/boards/ezbrd.c
> @@ -46,11 +46,13 @@ static struct resource musb_resources[]
> .start = IRQ_USB_INT0,
> .end= IRQ_USB_INT0,
> .flags = IORESOURCE_IRQ | IORESOURCE_IRQ_HIGHLEVEL,
> + .name = "mc"
> },
> [2] = { /* DMA IRQ */
> .start = IRQ_USB_DMA,
> .end= IRQ_USB_DMA,
> .flags = IORESOURCE_IRQ | IORESOURCE_IRQ_HIGHLEVEL,
> + .name = "dma"
> },
> };
>
> Index: linux-omap-pm/arch/blackfin/mach-bf527/boards/ezkit.c
> ===
> --- linux-omap-pm.orig/arch/blackfin/mach-bf527/boards/ezkit.c
> +++ linux-omap-pm/arch/blackfin/mach-bf527/boards/ezkit.c
> @@ -86,11 +86,13 @@ static struct resource musb_resources[]
> .start = IRQ_USB_INT0,
> .end= IRQ_USB_INT0,
> .flags = IORESOURCE_IRQ | IORESOURCE_IRQ_HIGHLEVEL,
> + .name = "mc"
> },
> [2] = { /* DMA IRQ */
> .start = IRQ_USB_DMA,
> .end= IRQ_USB_DMA,
> .flags = IORESOURCE_IRQ | IORESOURCE_IRQ_HIGHLEVEL,
> + .name = "dma"
> },
>
Re: [PATCH v8 0/6] OMAP: WDT: Implement WDT in hwmod way
"Varadarajan, Charulatha" writes:
>> -Original Message-
>> From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
>> Sent: Wednesday, September 29, 2010 6:36 AM
>> To: Varadarajan, Charulatha
>> Cc: t...@atomide.com; w...@iguana.be; linux-omap@vger.kernel.org; linux-
>> watch...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
>> p...@pwsan.com; Cousson, Benoit; Nayak, Rajendra; Basak, Partha
>> Subject: Re: [PATCH v8 0/6] OMAP: WDT: Implement WDT in hwmod way
>>
>> Hi Charu,
>>
>> "Varadarajan, Charulatha" writes:
>>
>> > Series of patches to port watchdog module to use hwmod APIs
>> > for OMAP2PLUS chips and use runtime APIs for all OMAP chips.
>> > For this hwmod database for OMAP2PLUS watchdog instances are
>> > populated and implements watchdog module to use PM runtime APIs.
>> >
>> > This patch series is generated on "origin/pm-core" which
>> > has Kevin's pm-next series, the runtime PM core patch series,
>> > and a collection of hwmod fixes that Paul/Benoit have lined up
>> > for 2.6.37.
>> >
>> > Tested on OMAP2430, OMAP4430 (ES1.0 & ES2.0), OMAP3430 SDP boards
>> > and zoom3 board. Also verified that this patch series does not
>> > break the OMAP1 build.
>>
>> I found a little snag with this series. Try testing with
>> omap2plus_defconfig and changing CONFIG_OMAP_WATCHDOG=n.
>>
>> If CONFIG_OMAP_WATCHDOG is not enabled in the kernel config, the system
>> will reboot soon after bootup.
>
> Thanks for finding this issue.
>
> After watchdog module reset, the WDTs are enabled. The default time
> for a system reset after a watchdog module reset is ~10s as per the
> default value of the WDT registers. Hence the above problem is observed.
>
> If CONFIG_OMAP_WATCHDOG is defined, wdt's probe is called within this
> 10s time and watchdog_disable is called during probe. Hence we are not
> finding this issue if CONFIG_OMAP_WATCHDOG is defined.
>
> Ideally, because of the above, watchdog should be with
> HWMOD_INIT_NO_RESET flag.
>
> If agreed, I would send the below patch (extended to other OMAPs)
> on top of my watchdog timer hwmod series with proper change log.
Using HWMOD_INIT_NO_RESET makes us still dependent on the bootloader
settings.
Instead, I would rather have a small piece of code in omap_init_wdt()
which disarms the watchdog so we don't have any assumptions about
bootloader behavior.
The question remains whether this disarm should be
#ifndef CONFIG_OMAP_WATCHDOG or if it should happen all the time. In
case the watchdog is a module, it's probe may not happen within the
timeout period and they system may reboot also, so I lean towards
disarming the watchdog unconditionally.
Kevin
> diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-
> omap2/omap_hwmod_3xxx_data.c
> index 5bfe9c9..c567b24 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> @@ -260,6 +260,7 @@ static struct omap_hwmod omap3xxx_wd_timer2_hwmod = {
> .slaves = omap3xxx_wd_timer2_slaves,
> .slaves_cnt = ARRAY_SIZE(omap3xxx_wd_timer2_slaves),
> .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
> + .flags = HWMOD_INIT_NO_RESET,
> };
>
> -V Charulatha
>
> <>
--
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 : [omap3] Nand flash initialisation error
In complement to my previous mail I have found that if I only add a call to gpmc_cs_request the info->phys_base is well initialized. So I could after call the platform_device_register as usual. Anyway I still have the bogus (but working) detection of the flash: NAND device: Manufacturer ID: 0x2c, Chip ID: 0xba (Micron omap2-nand.0) NAND bus width 8 instead 16 bit No NAND device found. NAND device: Manufacturer ID: 0x2c, Chip ID: 0xba (Micron NAND 256MiB 1,8V 16-bit) Any idea ? De : linux-omap-ow...@vger.kernel.org [linux-omap-ow...@vger.kernel.org] de la part de GERBER Patrick [patrick.ger...@heig-vd.ch] Date d'envoi : mercredi, 29. septembre 2010 14:05 À : linux-omap@vger.kernel.org Objet : [omap3] Nand flash initialisation error Hello, I am using 2.6.34.5 vanilla kernel on a gumstix over Fire using OMAP3530. I have some problems wit the nand flash (the chip on the top of the OMAP). The MTD partition is not created. When booting the board code is well detecting a Nand on CS0 and call the platform_device_register. The omap_nand_probe() fail with -16 (EBUSY) after calling request_mem_region() with 0 as a base address. So the info->phys_base is not initialized. After looking in older kernel I have tried to add a call gpmc_nand_init(&overo_nand_data) in my board code instead of the call to platform_device_register. With this addition the Flash is well detected and the mtd partition created. But there is some errors due to misconfiguration of the flash (bus width, detecting twice, ...). Of course my platform_device structure is not used because I have to pass only the omap_nand_platform_data struct to gpmc_nand_init(). (the ## prefixed lines are personal debug addition) ... Found NAND on CS0 ## gpmc_baseaddr 0xfe00, gpmc_cs_baseaddr 0xfe60 Registering NAND on CS0 ... omap2-nand driver initializing ## omap_nand_probe NAND device: Manufacturer ID: 0x2c, Chip ID: 0xba (Micron omap2-nand.0) NAND bus width 8 instead 16 bit No NAND device found. NAND device: Manufacturer ID: 0x2c, Chip ID: 0xba (Micron NAND 256MiB 1,8V 16-bit) cmdlinepart partition parsing not available Creating 5 MTD partitions on "omap2-nand.0": ... I have looked on other board initialization (beagle, igep, ...) and the code seems pretty similar. I would like to know if the call to gpmc_nand_init() is still necessary and why the detection is so hesitant ? I'd rather use the platform_device_register() but I dont understand why the info->phys_base is 0 ?!? Thanks in advance for any help. Patrick-- 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 -- 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
[omap3] Nand flash initialisation error
Hello, I am using 2.6.34.5 vanilla kernel on a gumstix over Fire using OMAP3530. I have some problems wit the nand flash (the chip on the top of the OMAP). The MTD partition is not created. When booting the board code is well detecting a Nand on CS0 and call the platform_device_register. The omap_nand_probe() fail with -16 (EBUSY) after calling request_mem_region() with 0 as a base address. So the info->phys_base is not initialized. After looking in older kernel I have tried to add a call gpmc_nand_init(&overo_nand_data) in my board code instead of the call to platform_device_register. With this addition the Flash is well detected and the mtd partition created. But there is some errors due to misconfiguration of the flash (bus width, detecting twice, ...). Of course my platform_device structure is not used because I have to pass only the omap_nand_platform_data struct to gpmc_nand_init(). (the ## prefixed lines are personal debug addition) ... Found NAND on CS0 ## gpmc_baseaddr 0xfe00, gpmc_cs_baseaddr 0xfe60 Registering NAND on CS0 ... omap2-nand driver initializing ## omap_nand_probe NAND device: Manufacturer ID: 0x2c, Chip ID: 0xba (Micron omap2-nand.0) NAND bus width 8 instead 16 bit No NAND device found. NAND device: Manufacturer ID: 0x2c, Chip ID: 0xba (Micron NAND 256MiB 1,8V 16-bit) cmdlinepart partition parsing not available Creating 5 MTD partitions on "omap2-nand.0": ... I have looked on other board initialization (beagle, igep, ...) and the code seems pretty similar. I would like to know if the call to gpmc_nand_init() is still necessary and why the detection is so hesitant ? I'd rather use the platform_device_register() but I dont understand why the info->phys_base is 0 ?!? Thanks in advance for any help. Patrick-- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] usb: musb: Adding names for IRQs in resource structure
On Wed, Sep 29, 2010 at 12:26, Hema HK wrote: > The resource data is getting automatically populated from a set of data > generated from TI's hardware database for the OMAP platform, > While we could hack in some exceptions to that tool to generate resources > in a specific order, it seems less fragile to use the resource name > instead.That way, no matter what order the resources are generated, the > driver still work. > > Modified the OMAP,Blackfin and Davinci architecture files to add the name of > the IRQs > in the resource structures and musb driver to use the get_irq_byname() api to > get the device and dma irq numbers instead of using the index. > > Signed-off-by: Hema HK > Cc: Felipe Balbi > Cc: Tony Lindgren > Cc: Kevin Hilman > Cc: Cousson, Benoit > Cc: Paul Walmsley > Cc: Mike Frysinger if Felipe is ok with this, then i'm ok with this Acked-by: Mike Frysinger -mike -- 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 05/11] omap3: Remove non-existent config option
> -Original Message- > From: Felipe Contreras [mailto:felipe.contre...@gmail.com] > Sent: Wednesday, September 29, 2010 5:05 PM > To: Kanigeri, Hari > Cc: Marathe, Yogesh; Premi, Sanjeev; Tony Lindgren; linux-arm- > ker...@lists.infradead.org; linux-omap@vger.kernel.org > Subject: Re: [PATCH 05/11] omap3: Remove non-existent config > option > > Hi Hari, > > On Mon, Sep 27, 2010 at 7:28 PM, Kanigeri, Hari kanige...@ti.com> wrote: > > Yogesh is coming from dsplink requirement to use iommu. I see his > comment as why Bridge requirement should be imposed on other IPCs > that need iommu. > > Ahh, that explains a lot. However, dsp-link can just enable > CONFIG_MPU_BRIDGE_IOMMU, and that's it, right? Perhaps it would > make > sense to rename to CONFIG_OMAP_IOMMU_IVA2, or something like > that. But > not remove it and break tidspbridge, which is already in staging. > > Once both are working happily with CONFIG_OMAP_IOMMU_IVA2 on, > _then_ > it can be removed. > > -- > Felipe Contreras Felipe, dsplink and syslink (two drivers who use iommu) should not enable CONFIG_MPU_BRIDGE_IOMMU as dspbridge and dsplink /syslink can not co-exist as they are using same resources. Not applying patch breaks dsplink/sylink any one which is being used. Defining this config makes them co-exist. I'm ok with changing name to CONFIG_OMAP_IOMMU_IVA2 but ideally then that will also break the dspbridge. One more way would be to soure revert the patch and apply on dspbridge branch if it breaks the builds on that branch rather than breaking others in master. Regards, Yogesh. -- 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 v8 0/6] OMAP: WDT: Implement WDT in hwmod way
> -Original Message-
> From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
> Sent: Wednesday, September 29, 2010 6:36 AM
> To: Varadarajan, Charulatha
> Cc: t...@atomide.com; w...@iguana.be; linux-omap@vger.kernel.org; linux-
> watch...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> p...@pwsan.com; Cousson, Benoit; Nayak, Rajendra; Basak, Partha
> Subject: Re: [PATCH v8 0/6] OMAP: WDT: Implement WDT in hwmod way
>
> Hi Charu,
>
> "Varadarajan, Charulatha" writes:
>
> > Series of patches to port watchdog module to use hwmod APIs
> > for OMAP2PLUS chips and use runtime APIs for all OMAP chips.
> > For this hwmod database for OMAP2PLUS watchdog instances are
> > populated and implements watchdog module to use PM runtime APIs.
> >
> > This patch series is generated on "origin/pm-core" which
> > has Kevin's pm-next series, the runtime PM core patch series,
> > and a collection of hwmod fixes that Paul/Benoit have lined up
> > for 2.6.37.
> >
> > Tested on OMAP2430, OMAP4430 (ES1.0 & ES2.0), OMAP3430 SDP boards
> > and zoom3 board. Also verified that this patch series does not
> > break the OMAP1 build.
>
> I found a little snag with this series. Try testing with
> omap2plus_defconfig and changing CONFIG_OMAP_WATCHDOG=n.
>
> If CONFIG_OMAP_WATCHDOG is not enabled in the kernel config, the system
> will reboot soon after bootup.
Thanks for finding this issue.
After watchdog module reset, the WDTs are enabled. The default time
for a system reset after a watchdog module reset is ~10s as per the
default value of the WDT registers. Hence the above problem is observed.
If CONFIG_OMAP_WATCHDOG is defined, wdt's probe is called within this
10s time and watchdog_disable is called during probe. Hence we are not
finding this issue if CONFIG_OMAP_WATCHDOG is defined.
Ideally, because of the above, watchdog should be with
HWMOD_INIT_NO_RESET flag.
If agreed, I would send the below patch (extended to other OMAPs)
on top of my watchdog timer hwmod series with proper change log.
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-
omap2/omap_hwmod_3xxx_data.c
index 5bfe9c9..c567b24 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -260,6 +260,7 @@ static struct omap_hwmod omap3xxx_wd_timer2_hwmod = {
.slaves = omap3xxx_wd_timer2_slaves,
.slaves_cnt = ARRAY_SIZE(omap3xxx_wd_timer2_slaves),
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+ .flags = HWMOD_INIT_NO_RESET,
};
-V Charulatha
<>
--
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 v4] musb: AM35x: Workaround for fifo read issue
AM35x supports only 32bit read operations so we need to have
workaround for 8bit and 16bit read operations.
Signed-off-by: Ajay Kumar Gupta
---
No change from v3.
drivers/usb/musb/am35x.c | 30 ++
drivers/usb/musb/musb_core.c |2 ++
2 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index ee0c104..dce99fc 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -508,3 +508,33 @@ void musb_platform_restore_context(struct musb *musb,
phy_on();
}
#endif
+
+/* AM35x supports only 32bit read operation */
+void musb_read_fifo(struct musb_hw_ep *hw_ep, u16 len, u8 *dst)
+{
+ void __iomem *fifo = hw_ep->fifo;
+ u32 val;
+ int i;
+
+ /* Read for 32bit-aligned destination address */
+ if (likely((0x03 & (unsigned long) dst) == 0) && len >= 4) {
+ readsl(fifo, dst, len >> 2);
+ dst += len & ~0x03;
+ len &= 0x03;
+ }
+ /*
+* Now read the rest 1 to 3 bytes or complete length if
+* unaligned address.
+*/
+ if (len > 4) {
+ for (i = 0; i < (len >> 2); i++) {
+ *(u32 *) dst = musb_readl(fifo, 0);
+ dst += 4;
+ }
+ len %= 4;
+ }
+ if (len > 0) {
+ val = musb_readl(fifo, 0);
+ memcpy(dst, &val, len);
+ }
+}
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 472b2a7..f03a2aa 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -272,6 +272,7 @@ void musb_write_fifo(struct musb_hw_ep *hw_ep, u16 len,
const u8 *src)
}
}
+#if !defined(CONFIG_USB_MUSB_AM35X)
/*
* Unload an endpoint's FIFO
*/
@@ -309,6 +310,7 @@ void musb_read_fifo(struct musb_hw_ep *hw_ep, u16 len, u8
*dst)
readsb(fifo, dst, len);
}
}
+#endif
#endif /* normal PIO */
--
1.6.2.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
[PATCH 1/3 v4] AM35x: Add musb support
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
---
Patch set created against latest linus's tree + Felipe's 14 patch set
for v2.6.37.
Changes from v3,
- Removed the new config ARCH_AM35x and added USB_MUSB_AM35X
at drivers/usb/musb/Kconfig
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
#include
#include
+#include
#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
#include
+#include
#include
#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.6.2.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
[PATCH 2/3 v4] musb: add musb support for AM35x
AM35x has musb interface and uses CPPI4.1 DMA engine. Current patch supports only PIO mode. DMA support can be added later once basic CPPI4.1 DMA patch is accepted. Also added USB_MUSB_AM35X which is required to differentiate musb ips between OMAP3x and AM35x. This config would be used to for below purposes, - Select am35x.c instead of omap2430.c for compilation at drivers/usb/musb directory. Please note there are significant differneces in these two files as musb ip in quite different on AM35x. - Select workaround codes applicable for AM35x musb issues. one such workaround is for bytewise read issue on AM35x. Signed-off-by: Ajay Kumar Gupta --- Changes from v3, (Mostly based on Sergei's review comment) - Cleaned up the clock related coding. - Removed the setting of musb->a_wait_vcon - Removed musb->is_active = 1 from isr routine. - Moved the GPIOMODE and DATA_POLARITY PHY config to board files. - Didn't add SESSSION bit write in otg_time for OTG_STATE_B_IDLE case as it always makes Vbus in switched on state. - Removed waiting loop in musb_platform_exit() function. drivers/usb/musb/Kconfig | 13 +- drivers/usb/musb/Makefile |4 + drivers/usb/musb/am35x.c | 510 + 3 files changed, 526 insertions(+), 1 deletions(-) create mode 100644 drivers/usb/musb/am35x.c diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig index 1dd21c2..0941a32 100644 --- a/drivers/usb/musb/Kconfig +++ b/drivers/usb/musb/Kconfig @@ -60,6 +60,17 @@ comment "OMAP 44xx high speed USB support" comment "Blackfin high speed USB Support" depends on USB_MUSB_HDRC && ((BF54x && !BF544) || (BF52x && !BF522 && !BF523)) +config USB_MUSB_AM35X + boolean "AM35X MUSB support" + depends on USB_MUSB_HDRC && MACH_OMAP3517EVM + select NOP_USB_XCEIV + default y + help + Select this option if your platform is based on AM35x. As + AM35x has an updated MUSB with CPPI4.1 DMA so this config + is introduced to differentiate musb ip between OMAP3x and + AM35x platforms. + config USB_TUSB6010 boolean "TUSB 6010 support" depends on USB_MUSB_HDRC && !USB_MUSB_SOC @@ -147,7 +158,7 @@ config USB_MUSB_HDRC_HCD config MUSB_PIO_ONLY bool 'Disable DMA (always use PIO)' depends on USB_MUSB_HDRC - default USB_TUSB6010 || ARCH_DAVINCI_DA8XX + default USB_TUSB6010 || ARCH_DAVINCI_DA8XX || USB_MUSB_AM35X help All data is copied between memory and FIFO by the CPU. DMA controllers are ignored. diff --git a/drivers/usb/musb/Makefile b/drivers/usb/musb/Makefile index f664ecf..217363d 100644 --- a/drivers/usb/musb/Makefile +++ b/drivers/usb/musb/Makefile @@ -23,7 +23,11 @@ ifeq ($(CONFIG_ARCH_OMAP2430),y) endif ifeq ($(CONFIG_ARCH_OMAP3430),y) + ifeq ($(CONFIG_USB_MUSB_AM35X),y) + musb_hdrc-objs += am35x.o + else musb_hdrc-objs += omap2430.o + endif endif ifeq ($(CONFIG_ARCH_OMAP4),y) diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c new file mode 100644 index 000..ee0c104 --- /dev/null +++ b/drivers/usb/musb/am35x.c @@ -0,0 +1,510 @@ +/* + * Texas Instruments AM35x "glue layer" + * + * Copyright (c) 2010, by Texas Instruments + * + * Based on the DA8xx "glue layer" code. + * Copyright (C) 2005-2006 by Texas Instruments + * Copyright (c) 2008, MontaVista Software, Inc. + * + * This file is part of the Inventra Controller Driver for Linux. + * + * The Inventra Controller Driver for Linux 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. + * + * The Inventra Controller Driver for Linux 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 The Inventra Controller Driver for Linux ; if not, + * write to the Free Software Foundation, Inc., 59 Temple Place, + * Suite 330, Boston, MA 02111-1307 USA + * + */ + +#include +#include +#include + +#include +#include + +#include "musb_core.h" + +/* + * AM35x specific definitions + */ +/* USB 2.0 OTG module registers */ +#define USB_REVISION_REG 0x00 +#define USB_CTRL_REG 0x04 +#define USB_STAT_REG 0x08 +#define USB_EMULATION_REG 0x0c +/* 0x10 Reserved */ +#define USB_AUTOREQ_REG0x14 +#define USB_SRP_FIX_TIME_REG 0x18 +#define USB_TEARDOWN_REG 0x1c +#define EP_INTR_SRC_REG0x20 +#define EP_INTR_SRC_SET_REG0x24 +#define EP_INTR_SRC_CLEAR_REG 0x28 +#define EP_INTR_MASK_REG 0x2c +#define
RE: [PATCH v4] usb: musb: Adding names for IRQs in resource structure
>-Original Message-
>From: Balbi, Felipe
>Sent: Wednesday, September 29, 2010 3:41 PM
>To: Kalliguddi, Hema
>Cc: Balbi, Felipe; linux-omap@vger.kernel.org;
>linux-...@vger.kernel.org; Tony Lindgren; Kevin Hilman;
>Cousson, Benoit; Paul Walmsley; Mike Frysinger
>Subject: Re: [PATCH v4] usb: musb: Adding names for IRQs in
>resource structure
>
>On Wed, Sep 29, 2010 at 03:54:45AM -0500, Kalliguddi, Hema wrote:
>> Hi,
>>
>>>-Original Message-
>>>From: Balbi, Felipe
>>>Sent: Wednesday, September 29, 2010 12:30 PM
>>>To: Kalliguddi, Hema
>>>Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org;
>>>Balbi, Felipe; Tony Lindgren; Kevin Hilman; Cousson, Benoit;
>>>Paul Walmsley; Mike Frysinger
>>>Subject: Re: [PATCH v4] usb: musb: Adding names for IRQs in
>>>resource structure
>>>
>>>Hi,
>>>
>>>On Wed, Sep 29, 2010 at 11:26:39AM -0500, Kalliguddi, Hema wrote:
Index: linux-omap-pm/arch/arm/mach-davinci/usb.c
===
--- linux-omap-pm.orig/arch/arm/mach-davinci/usb.c
+++ linux-omap-pm/arch/arm/mach-davinci/usb.c
@@ -64,10 +64,12 @@ static struct resource usb_resources[] =
{
.start = IRQ_USBINT,
.flags = IORESOURCE_IRQ,
+ .name = "mc"
},
{
/* placeholder for the dedicated CPPI IRQ */
.flags = IORESOURCE_IRQ,
+ .name = "dma"
},
};
>>>
>>>you add names only to the IRQs, this will still require the
>memory base
>>>to be the first resource. Maybe adding a name like "regs" to
>the memory
>>>base and changing to platform_get_resource_byname(pdev, "regs") on
>>>musb-core.c
>>>
>>It does not mandate the base address to be the first
>resource, as the api
>>used for getting the base address takes the resource type as
>parameter.
>>"platform_get_resource(struct platform_device *dev,unsigned int type,
>>unsigned int num)". but it mandates the base addresses have to be in
>>certain order if there are multiple base address.Since for musb there
>>is one base address.
>
>true :-p Sorry about that. Just noise.
>
That's Ok...
>--
>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 05/11] omap3: Remove non-existent config option
Hi Hari, On Mon, Sep 27, 2010 at 7:28 PM, Kanigeri, Hari wrote: > Yogesh is coming from dsplink requirement to use iommu. I see his comment as > why Bridge requirement should be imposed on other IPCs that need iommu. Ahh, that explains a lot. However, dsp-link can just enable CONFIG_MPU_BRIDGE_IOMMU, and that's it, right? Perhaps it would make sense to rename to CONFIG_OMAP_IOMMU_IVA2, or something like that. But not remove it and break tidspbridge, which is already in staging. Once both are working happily with CONFIG_OMAP_IOMMU_IVA2 on, _then_ it can be removed. -- 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 05/13] OMAP: Introduce device specific set rate and get rate in device opp structures.
>>-Original Message- >>From: Cousson, Benoit >>Sent: Saturday, September 18, 2010 3:43 PM >>To: Gopinath, Thara >>Cc: Kevin Hilman; Paul Walmsley; linux-omap@vger.kernel.org; Sripathy, >>Vishwanath; Sawant, Anand >>Subject: Re: [PATCH 05/13] OMAP: Introduce device specific set rate and get >>rate in device opp structures. >> >>Hi Thara, >> >>On 9/17/2010 4:55 PM, Gopinath, Thara wrote: >>> > From: Kevin Hilman [mailto:khil...@deeprootsystems.com] > Sent: Thursday, September 16, 2010 8:58 PM > > "Gopinath, Thara" writes: > From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Friday, September 03, 2010 5:12 AM Thara Gopinath writes: > This patch extends the device opp structure to contain > pointers to scale the operating rate of the > device and to retrieve the operating rate of the device. > This patch also adds the three new APIs in the opp layer > namely opp_set_rate that can be called to set a new operating > rate for a device, opp_get_rate that can be called to retrieve > the operating frequency for a device and opp_populate_rate_fns > to populte the device specific set_rate and get_rate API's. > The opp_set_rate and opp_get_rate does some routine error > checks and finally calls into the device specific set_rate > and get_rate APIs populated through opp_populate_rate_fns. > > Signed-off-by: Thara Gopinath As I think about this more, I'm not sure the OPP layer is the right layer for the get/set rate functions. The OPP layer is currently just the data store for OPP data. To me, these set/get functions are better associated directly with an omap_device instead of an OPP. For instance, the new OPP APIs are a bit confusing in terms of OPPs. e.g: opp_get_rate(). What is the "rate" of an OPP, and what's the difference with opp_get_freq()? What's really happening is the rate is being changed for a device, and the need for specific hooks are at the device level, not the OPP >>level. For example, this current approach would not scale if you needed multiple devices in the same domain that each needed custom set_rate/get_rate hooks. So instead, what about adding custom hooks at the omap_device level? They could be registered at omap_device_build() time in the device specific code. >> >> This is exactly what I had in my mind when I started implementing this. >> But then Paul said hwmod or omap_device is not the place to keep it. > > IIRC, Paul's concern was that *hwmod* was not the right place for this > (and I agree.) However, I think omap_device is the right place for > this. > > Paul? > >> Also I do not want the set rate get rate APIs for devices that require >> changes dividers in the PRCM clock module to be spread out in the >> system. Makes it very very difficult to debug. If we agree to add the >> set_rate and get_rate in the omap_device structure, I would like to >> have one more API in the omap_device layer to register these APIs >> device wise. Thus we can keep these set rate and get rate APIs in one >> single file. > > Agreed. And those functions should be in the respective > device-specific file, where the omap_device_build() etc are done for > that device. >>> >>> Hello Kevin, >>> >>> I basically agree with all your other suggestions except this. I do not >>> think device files are the correct place for this. For starters definitely >>mpu, >>> l3 and iva devices are not built from any device file. I do not like the >>idea >>> of device set rate APIs spread across different files. >> >>I don't not understand the reason? >>If we need to add specific device function for mpu, l3, or iva, we can >>easily add a file to contain that. >>BTW, thanks to work done by Santosh and Felipe we will probably soon >>introduce a l3 driver that will allow to handle interconnect errors. We >>will thus have a real device for l3 as well. >> >>A device set_rate is clearly device specific. If a device will have to >>play with its own internal dividers along with PRCM dividers, that code >>still belong to the device. >> >>I do not see the need nor the advantage to centralize that? You will >>end-up with a huge file that every driver owners will have to hack in >>order to add set_rate support for their device. >> >>At device build time, IP with set_rate support will just add non-null >>parameters to the omap_device_build(), et voila. >> >>For the debug point of view, you can just add a new sysfs entry for >>scalable devices that will allow you to track scalable device vs regular >>ones. Hello Benoit/Kevin, Most of the devices need not scale any internal dividers. For devices that nee
Re: [PATCH v4 1/4] omap4 hsmmc: Adding card detect support for MMC1
Gentle Reminder !
Regards,
Kishore
On Tue, Sep 28, 2010 at 12:22 PM, kishore kadiyala
wrote:
> Hi Samuel,
>
> Could you please review this patch which touches mfd/twl6030-irq.c for
> card detect support
> of MMC1 controller on OMAP4.
>
> Regards,
> Kishore
>
> On Mon, Sep 27, 2010 at 1:25 PM, kishore kadiyala
> wrote:
>> Cc: Samuel Ortiz
>>
>> On Fri, Sep 24, 2010 at 10:43 PM, kishore kadiyala
>> wrote:
>>> Adding card detect callback function and card detect configuration
>>> function for MMC1 Controller on OMAP4.
>>>
>>> Card detect configuration function does initial configuration of the
>>> MMC Control & PullUp-PullDown registers of Phoenix.
>>>
>>> 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.
>>>
>>> Since OMAP4 doesn't use any GPIO line as used in OMAP3 for card detect,
>>> the suspend/resume initialization which was done in omap_hsmmc_gpio_init
>>> previously is moved to the probe thus making it generic for both OMAP3 &
>>> OMAP4.
>>>
>>> Cc: Tony Lindgren
>>> Cc: Andrew Morton
>>> Cc: Madhusudhan Chikkature
>>> Cc: Adrian Hunter
>>> Signed-off-by: Kishore Kadiyala
>>> ---
>>> arch/arm/mach-omap2/board-4430sdp.c | 7 +++-
>>> drivers/mfd/twl6030-irq.c | 73
>>> +++
>>> drivers/mmc/host/omap_hsmmc.c | 4 +-
>>> include/linux/i2c/twl.h | 31 +++
>>> 4 files changed, 112 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-omap2/board-4430sdp.c
>>> b/arch/arm/mach-omap2/board-4430sdp.c
>>> index 9447644..a49f285 100644
>>> --- a/arch/arm/mach-omap2/board-4430sdp.c
>>> +++ b/arch/arm/mach-omap2/board-4430sdp.c
>>> @@ -227,9 +227,14 @@ static int omap4_twl6030_hsmmc_late_init(struct device
>>> *dev)
>>> struct omap_mmc_platform_data *pdata = dev->platform_data;
>>>
>>> /* Setting MMC1 Card detect Irq */
>>> - if (pdev->id == 0)
>>> + if (pdev->id == 0) {
>>> + ret = twl6030_mmc_card_detect_config();
>>> + if (ret)
>>> + pr_err("Failed configuring MMC1 card detect\n");
>>> pdata->slots[0].card_detect_irq = TWL6030_IRQ_BASE +
>>> MMCDETECT_INTR_OFFSET;
>>> + pdata->slots[0].card_detect = twl6030_mmc_card_detect;
>>> + }
>>> return ret;
>>> }
>>>
>>> diff --git a/drivers/mfd/twl6030-irq.c b/drivers/mfd/twl6030-irq.c
>>> index 10bf228..2d3bb82 100644
>>> --- a/drivers/mfd/twl6030-irq.c
>>> +++ b/drivers/mfd/twl6030-irq.c
>>> @@ -36,6 +36,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>>
>>> /*
>>> * TWL6030 (unlike its predecessors, which had two level interrupt handling)
>>> @@ -223,6 +224,78 @@ int twl6030_interrupt_mask(u8 bit_mask, u8 offset)
>>> }
>>> EXPORT_SYMBOL(twl6030_interrupt_mask);
>>>
>>> +int twl6030_mmc_card_detect_config(void)
>>> +{
>>> + int ret;
>>> + u8 reg_val = 0;
>>> +
>>> + /* Unmasking the Card detect Interrupt line for MMC1 from Phoenix */
>>> + twl6030_interrupt_unmask(TWL6030_MMCDETECT_INT_MASK,
>>> + REG_INT_MSK_LINE_B);
>>> + twl6030_interrupt_unmask(TWL6030_MMCDETECT_INT_MASK,
>>> + REG_INT_MSK_STS_B);
>>> + /*
>>> + * Intially Configuring MMC_CTRL for receving interrupts &
>>> + * Card status on TWL6030 for MMC1
>>> + */
>>> + ret = twl_i2c_read_u8(TWL6030_MODULE_ID0, ®_val,
>>> TWL6030_MMCCTRL);
>>> + if (ret < 0) {
>>> + pr_err("twl6030: Failed to read MMCCTRL, error %d\n", ret);
>>> + return ret;
>>> + }
>>> + reg_val &= ~VMMC_AUTO_OFF;
>>> + reg_val |= SW_FC;
>>> + ret = twl_i2c_write_u8(TWL6030_MODULE_ID0, reg_val,
>>> TWL6030_MMCCTRL);
>>> + if (ret < 0) {
>>> + pr_err("twl6030: Failed to write MMCCTRL, error %d\n", ret);
>>> + return ret;
>>> + }
>>> +
>>> + /* Configuring PullUp-PullDown register */
>>> + ret = twl_i2c_read_u8(TWL6030_MODULE_ID0, ®_val,
>>> + TWL6030_CFG_INPUT_PUPD3);
>>> + if (ret < 0) {
>>> + pr_err("twl6030: Failed to read CFG_INPUT_PUPD3, error
>>> %d\n",
>>> +
>>> ret);
>>> + return ret;
>>> + }
>>> + reg_val &= ~(MMC_PU | MMC_PD);
>>> + ret = twl_i2c_write_u8(TWL6030_MODULE_ID0, reg_val,
>>> + TWL6030_CFG_INPUT_PUPD3);
>>> + if (ret < 0) {
>>> + pr_err("twl6030: Failed to write CFG_INPUT_PUPD3, error
>>> %d\n",
>>> +
>>>
Re: [PATCH v4] usb: musb: Adding names for IRQs in resource structure
On Wed, Sep 29, 2010 at 03:54:45AM -0500, Kalliguddi, Hema wrote:
Hi,
-Original Message-
From: Balbi, Felipe
Sent: Wednesday, September 29, 2010 12:30 PM
To: Kalliguddi, Hema
Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org;
Balbi, Felipe; Tony Lindgren; Kevin Hilman; Cousson, Benoit;
Paul Walmsley; Mike Frysinger
Subject: Re: [PATCH v4] usb: musb: Adding names for IRQs in
resource structure
Hi,
On Wed, Sep 29, 2010 at 11:26:39AM -0500, Kalliguddi, Hema wrote:
Index: linux-omap-pm/arch/arm/mach-davinci/usb.c
===
--- linux-omap-pm.orig/arch/arm/mach-davinci/usb.c
+++ linux-omap-pm/arch/arm/mach-davinci/usb.c
@@ -64,10 +64,12 @@ static struct resource usb_resources[] =
{
.start = IRQ_USBINT,
.flags = IORESOURCE_IRQ,
+ .name = "mc"
},
{
/* placeholder for the dedicated CPPI IRQ */
.flags = IORESOURCE_IRQ,
+ .name = "dma"
},
};
you add names only to the IRQs, this will still require the memory base
to be the first resource. Maybe adding a name like "regs" to the memory
base and changing to platform_get_resource_byname(pdev, "regs") on
musb-core.c
It does not mandate the base address to be the first resource, as the api
used for getting the base address takes the resource type as parameter.
"platform_get_resource(struct platform_device *dev,unsigned int type,
unsigned int num)". but it mandates the base addresses have to be in
certain order if there are multiple base address.Since for musb there
is one base address.
true :-p Sorry about that. Just noise.
--
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 2/2] OMAP:DSS: RFC Patch to add HDMI DSS driver support
K, Mythri P [2010-09-08 10:16:29]: Hi, [snip] > Yes this is just a RFC patch to introduce the HDMI driver and panel as such, > if you have no other comments on these 2 patch set I shall incorporate these > comments and send out the complete patch series with all the relevant > changes in display.h and some overlay.c and manager.c changes. there's EDID parser[1] already in kernel, so you might better reuse it and/or extend it for your needs. The next thing is, that there's and there will be the demand for EDID on OMAP3 also, so it might be wise to rethink it from the beginning and split or write the code in a way, that it can be reused on OMAP3 also. I think, that at least the code for calculation of ideal video resolution and timings could be made generic and could be used on OMAP3 also. Or am I mistaken? I'm adding Ricardo Salveti to the CC, he showed me his first draft of EDID parsing[2] for OMAP3 yesterday. Yes, it's just the draft, but it's at least reusing the code already available in kernel. I think, that the same could or should apply for the OMAP4 code. What I'm trying to say is, that I'm not uber kernel hacker, but I would like to have EDID working on my Beagle also and I'll definitely help with this. Thanks. 1. drivers/video/fbmon.c and drivers/video/edid.h 2. http://kernel.ubuntu.com/git?p=rsalveti/ubuntu-maverick.git;a=commitdiff;h=a0ea712b64988ccd7984069b99864a1b4ac43881 -- ynezz -- 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] tracing, perf: add more power related events
Hi, On Wed, Sep 29, 2010 at 9:49 AM, Thomas Renninger wrote: > On Tuesday 28 September 2010 23:45:24 Arjan van de Ven wrote: >> On 9/28/2010 2:22 PM, Rafael J. Wysocki wrote: >> > On Tuesday, September 28, 2010, Jean Pihet wrote: >> >> Hi, >> > Hi, >> > >> >> Here is what I am proposing, in reply to all your comments: >> >> >> >> 1) rename the events to match Thomas's proposal: >> >> power:power_cpu_cstate >> >> power:power_cpu_pstate >> >> power:power_cpu_sstate > I'd not name it that X86/ACPI specific. > power:processor_sleep > power:processor_frequency > power:system_suspend > This would map with X86/ACPI c/p/s states but the name would > also match fine with ARM and other archs. Good for me! > >> > If that sstate thing is going to mean "suspend", then please drop >> > it. >> > "Suspend" is not a state, let alone a CPU state. It is a procedure >> > by which the (entire) system is put into a sleep state (that is not >> > confined to CPUs). >> >> there are also non-suspend S states, like S0i1 and S0i3 (supported in >> the current Intel "Moorestown" platform) >> >> so it's slightly more complex than "just" suspend :) > Something specific for this arch could get introduced, similar as > Jean did for the ARM specifics, e.g.: > power:moorestown_suspend I would not introduce arch specific events. Your other proposal below is more generic. > Intel probably invented three names for this new technique, one > might fit as an event name? > Depending whether extra info needs passed through this event it > could also use > power:system_suspend > and pass a suspend state of #define S0i1 0x100, #define S0i2 0x101... I am OK with that. > > I try to find time to come up with another cleanup patch. > I also want to look at perf timechart then where I remember some ugly > hacks with C-state accounting and the broken state_start, state_end and > frequency_switch events. Hope it won't get too ugly and perf timechart > can support both, the old and the cleaned up events for a while. About pytimechart, I think it should be updated with the support for the new events only. The current version is not perfect but supports the current events correctly. I am planning to celan up and upgrade that tool when the new API is out. If that could force people to upgrade to the new events API asap... > > Thomas > I know you want to see real code. Let me come with a respin of the patch asap (it is a matter of days). Thanks, Jean -- 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] OMAP: PM: CPUFREQ: Fix conditional compilation
Fix conditional compilation. A conditional expresiion should follow "#elif", in this case #elif clause should check whether CONFIG_ARCH_OMAP3 is defined or not (ie. defined(CONFIG_ARCH_OMAP3)) rather than checking for the value of the macro. Signed-off-by: Silesh C V --- arch/arm/plat-omap/cpu-omap.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/cpu-omap.c b/arch/arm/plat-omap/cpu-omap.c index df08829..02e4865 100644 --- a/arch/arm/plat-omap/cpu-omap.c +++ b/arch/arm/plat-omap/cpu-omap.c @@ -41,7 +41,7 @@ static struct cpufreq_frequency_table *freq_table; #ifdef CONFIG_ARCH_OMAP1 #define MPU_CLK"mpu" -#elif CONFIG_ARCH_OMAP3 +#elif defined(CONFIG_ARCH_OMAP3) #define MPU_CLK"arm_fck" #else #define MPU_CLK"virt_prcm_set" -- 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
RE: [PATCH v4] usb: musb: Adding names for IRQs in resource structure
Hi,
>-Original Message-
>From: Balbi, Felipe
>Sent: Wednesday, September 29, 2010 12:30 PM
>To: Kalliguddi, Hema
>Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org;
>Balbi, Felipe; Tony Lindgren; Kevin Hilman; Cousson, Benoit;
>Paul Walmsley; Mike Frysinger
>Subject: Re: [PATCH v4] usb: musb: Adding names for IRQs in
>resource structure
>
>Hi,
>
>On Wed, Sep 29, 2010 at 11:26:39AM -0500, Kalliguddi, Hema wrote:
>>Index: linux-omap-pm/arch/arm/mach-davinci/usb.c
>>===
>>--- linux-omap-pm.orig/arch/arm/mach-davinci/usb.c
>>+++ linux-omap-pm/arch/arm/mach-davinci/usb.c
>>@@ -64,10 +64,12 @@ static struct resource usb_resources[] =
>> {
>> .start = IRQ_USBINT,
>> .flags = IORESOURCE_IRQ,
>>+ .name = "mc"
>> },
>> {
>> /* placeholder for the dedicated CPPI IRQ */
>> .flags = IORESOURCE_IRQ,
>>+ .name = "dma"
>> },
>> };
>
>you add names only to the IRQs, this will still require the memory base
>to be the first resource. Maybe adding a name like "regs" to the memory
>base and changing to platform_get_resource_byname(pdev, "regs") on
>musb-core.c
>
It does not mandate the base address to be the first resource, as the api
used for getting the base address takes the resource type as parameter.
"platform_get_resource(struct platform_device *dev,unsigned int type,
unsigned int num)". but it mandates the base addresses have to be in
certain order if there are multiple base address.Since for musb there
is one base address.
>--
>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] tracing, perf: add more power related events
On Tuesday 28 September 2010 23:45:24 Arjan van de Ven wrote: > On 9/28/2010 2:22 PM, Rafael J. Wysocki wrote: > > On Tuesday, September 28, 2010, Jean Pihet wrote: > >> Hi, > > Hi, > > > >> Here is what I am proposing, in reply to all your comments: > >> > >> 1) rename the events to match Thomas's proposal: > >> power:power_cpu_cstate > >> power:power_cpu_pstate > >> power:power_cpu_sstate I'd not name it that X86/ACPI specific. power:processor_sleep power:processor_frequency power:system_suspend This would map with X86/ACPI c/p/s states but the name would also match fine with ARM and other archs. > > If that sstate thing is going to mean "suspend", then please drop > > it. > > "Suspend" is not a state, let alone a CPU state. It is a procedure > > by which the (entire) system is put into a sleep state (that is not > > confined to CPUs). > > there are also non-suspend S states, like S0i1 and S0i3 (supported in > the current Intel "Moorestown" platform) > > so it's slightly more complex than "just" suspend :) Something specific for this arch could get introduced, similar as Jean did for the ARM specifics, e.g.: power:moorestown_suspend Intel probably invented three names for this new technique, one might fit as an event name? Depending whether extra info needs passed through this event it could also use power:system_suspend and pass a suspend state of #define S0i1 0x100, #define S0i2 0x101... I try to find time to come up with another cleanup patch. I also want to look at perf timechart then where I remember some ugly hacks with C-state accounting and the broken state_start, state_end and frequency_switch events. Hope it won't get too ugly and perf timechart can support both, the old and the cleaned up events for a while. 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
[GIT PULL] ARM: l2x0: kexex, cleanup and optimisation for 2.6.37
The following changes since commit b30a3f6257ed2105259b404d419b4964e363928c: Linus Torvalds (1): Linux 2.6.36-rc5 are available in the git repository at: git://dev.omapzoom.org/pub/scm/santosh/kernel-omap4-base.git l2x0-pull-rmk Catalin Marinas (1): ARM: Improve the L2 cache performance when PL310 is used Per Fransson (1): ARM: ux500 specific L2 cache code Santosh Shilimkar (4): omap4: l2x0: Override the default l2x0_disable ARM: l2x0: Fix coding-style in the cache-l2x0.h ARM: l2x0: Determine the cache size ARM: l2x0: Optimise the range based operations Thomas Gleixner (2): arm: Disable outer (L2) cache in kexec arm: Implement l2x0 cache disable functions arch/arm/include/asm/hardware/cache-l2x0.h |9 ++- arch/arm/include/asm/outercache.h | 24 + arch/arm/kernel/machine_kexec.c|3 + arch/arm/mach-omap2/omap4-common.c | 13 + arch/arm/mach-ux500/cpu.c | 45 arch/arm/mm/Kconfig|8 +++ arch/arm/mm/cache-l2x0.c | 78 +-- 7 files changed, 171 insertions(+), 9 deletions(-) Regards, Santosh Thread where this was discussed: http://marc.info/?l=linux-omap&m=128396111204338&w=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] OMAP: ZOOM2: Change GPIO to enable LCD NEC NL8048HL11-01B on OMAP34x-II MDP
Hi,
On Tue, 2010-09-21 at 14:21 +0200, ext Yanick Saugy wrote:
> The PIN which controls LCD's reset signal (VGA_nRESET/h_GPIO_96) was not
> configured as a GPIO. We had to modify the OMAP MUX, and select this PIN
> (CAM_XCLKA) as an output GPIO (OMAP_MUX_MODE4). (kernel 2.6.35)
>
> Be aware of changing this PIN will probably disable the camera, because
> it was previously configured as a camera clock.
>
>
> Signed-off-by: Yanick Saugy
>
> --- a/arch/arm/mach-omap2/board-zoom2.c 2010-09-15 15:27:05.148399721 +0200
> +++ b/arch/arm/mach-omap2/board-zoom2.c 2010-09-15 14:46:09.792900019 +0200
> @@ -71,6 +71,7 @@ static struct twl4030_platform_data zoom
>
> #ifdef CONFIG_OMAP_MUX
> static struct omap_board_mux board_mux[] __initdata = {
> + OMAP3_MUX(CAM_XCLKA, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
> { .reg_offset = OMAP_MUX_TERMINATOR },
> };
> #else
> @@ -82,6 +83,7 @@ static void __init omap_zoom2_init(void)
> omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
> zoom_peripherals_init();
> zoom_debugboard_init();
> +zoom_display_init(OMAP_DSS_VENC_TYPE_COMPOSITE);
> }
>
> static void __init omap_zoom2_map_io(void)
How did you create this patch? It doesn't look like standard one, and
git am chokes on it. Also, it doesn't apply to the latest linux tree, so
you need to rebase.
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 2/9 v3] usb: musb: Remove board_data parameter from musb_platform_init()
Hi, On Wed, Sep 29, 2010 at 02:00:14AM -0500, Kalliguddi, Hema wrote: Any comments on this patch? I need an ack from Mike (blackfin) and Kevin (DaVinci). Everything else is fine by me. -- 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 2/9 v3] usb: musb: Remove board_data parameter from musb_platform_init()
Hi,
>-Original Message-
>From: Kalliguddi, Hema
>Sent: Thursday, September 23, 2010 5:58 AM
>To: linux-omap@vger.kernel.org; linux-...@vger.kernel.org
>Cc: Kalliguddi, Hema; Balbi, Felipe; Tony Lindgren; Kevin
>Hilman; Cousson, Benoit; Paul Walmsley
>Subject: [PATCH 2/9 v3] usb: musb: Remove board_data parameter
>from musb_platform_init()
>
>Removed the board_data parameter being passed to
>musb_platform_init function
>as board data can be extracted from device structure which is
>already member of
>musb structure.
>
>Signed-off-by: Hema HK
>Cc: Felipe Balbi
>Cc: Tony Lindgren
>Cc: Kevin Hilman
>Cc: Cousson, Benoit
>Cc: Paul Walmsley
>
>---
> drivers/usb/musb/blackfin.c |2 +-
> drivers/usb/musb/davinci.c |2 +-
> drivers/usb/musb/musb_core.c |2 +-
> drivers/usb/musb/musb_core.h |2 +-
> drivers/usb/musb/omap2430.c |6 --
> drivers/usb/musb/tusb6010.c |2 +-
> 6 files changed, 9 insertions(+), 7 deletions(-)
>
>Index: linux-omap-pm/drivers/usb/musb/blackfin.c
>===
>--- linux-omap-pm.orig/drivers/usb/musb/blackfin.c
>+++ linux-omap-pm/drivers/usb/musb/blackfin.c
>@@ -323,7 +323,7 @@ int musb_platform_set_mode(struct musb *
> return -EIO;
> }
>
>-int __init musb_platform_init(struct musb *musb, void *board_data)
>+int __init musb_platform_init(struct musb *musb)
> {
>
> /*
>Index: linux-omap-pm/drivers/usb/musb/davinci.c
>===
>--- linux-omap-pm.orig/drivers/usb/musb/davinci.c
>+++ linux-omap-pm/drivers/usb/musb/davinci.c
>@@ -376,7 +376,7 @@ int musb_platform_set_mode(struct musb *
> return -EIO;
> }
>
>-int __init musb_platform_init(struct musb *musb, void *board_data)
>+int __init musb_platform_init(struct musb *musb)
> {
> void __iomem*tibase = musb->ctrl_base;
> u32 revision;
>Index: linux-omap-pm/drivers/usb/musb/musb_core.c
>===
>--- linux-omap-pm.orig/drivers/usb/musb/musb_core.c
>+++ linux-omap-pm/drivers/usb/musb/musb_core.c
>@@ -2022,7 +2022,7 @@ bad_config:
>* isp1504, non-OTG, etc) mostly hooking up through ULPI.
>*/
> musb->isr = generic_interrupt;
>- status = musb_platform_init(musb, plat->board_data);
>+ status = musb_platform_init(musb);
> if (status < 0)
> goto fail2;
>
>Index: linux-omap-pm/drivers/usb/musb/musb_core.h
>===
>--- linux-omap-pm.orig/drivers/usb/musb/musb_core.h
>+++ linux-omap-pm/drivers/usb/musb/musb_core.h
>@@ -612,7 +612,7 @@ extern int musb_platform_get_vbus_status
> #define musb_platform_get_vbus_status(x) 0
> #endif
>
>-extern int __init musb_platform_init(struct musb *musb, void
>*board_data);
>+extern int __init musb_platform_init(struct musb *musb);
> extern int musb_platform_exit(struct musb *musb);
>
> #endif/* __MUSB_CORE_H__ */
>Index: linux-omap-pm/drivers/usb/musb/omap2430.c
>===
>--- linux-omap-pm.orig/drivers/usb/musb/omap2430.c
>+++ linux-omap-pm/drivers/usb/musb/omap2430.c
>@@ -187,10 +187,12 @@ int musb_platform_set_mode(struct musb *
> return 0;
> }
>
>-int __init musb_platform_init(struct musb *musb, void *board_data)
>+int __init musb_platform_init(struct musb *musb)
> {
> u32 l;
>- struct omap_musb_board_data *data = board_data;
>+ struct device *dev = musb->controller;
>+ struct musb_hdrc_platform_data *plat = dev->platform_data;
>+ struct omap_musb_board_data *data = plat->board_data;
>
> /* We require some kind of external transceiver, hooked
>* up through ULPI. TWL4030-family PMICs include one,
>Index: linux-omap-pm/drivers/usb/musb/tusb6010.c
>===
>--- linux-omap-pm.orig/drivers/usb/musb/tusb6010.c
>+++ linux-omap-pm/drivers/usb/musb/tusb6010.c
>@@ -1091,7 +1091,7 @@ err:
> return -ENODEV;
> }
>
>-int __init musb_platform_init(struct musb *musb, void *board_data)
>+int __init musb_platform_init(struct musb *musb)
> {
> struct platform_device *pdev;
> struct resource *mem;
>
Any comments on this patch?
Regards,
Hema
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] usb: musb: Adding names for IRQs in resource structure
Hi,
On Wed, Sep 29, 2010 at 11:26:39AM -0500, Kalliguddi, Hema wrote:
Index: linux-omap-pm/arch/arm/mach-davinci/usb.c
===
--- linux-omap-pm.orig/arch/arm/mach-davinci/usb.c
+++ linux-omap-pm/arch/arm/mach-davinci/usb.c
@@ -64,10 +64,12 @@ static struct resource usb_resources[] =
{
.start = IRQ_USBINT,
.flags = IORESOURCE_IRQ,
+ .name = "mc"
},
{
/* placeholder for the dedicated CPPI IRQ */
.flags = IORESOURCE_IRQ,
+ .name = "dma"
},
};
you add names only to the IRQs, this will still require the memory base
to be the first resource. Maybe adding a name like "regs" to the memory
base and changing to platform_get_resource_byname(pdev, "regs") on
musb-core.c
--
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
