[PATCH] McBSP: Fix the free variable update at remove.
From: Shubhrajyoti D At remove the free variable is wrongly updated.Attempting to solve the same. Signed-off-by: Shubhrajyoti D Signed-off-by: Kishon Vijay Abraham I Reported-by: Vikram Pandita --- arch/arm/plat-omap/mcbsp.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c index eac4b97..6802ed1 100644 --- a/arch/arm/plat-omap/mcbsp.c +++ b/arch/arm/plat-omap/mcbsp.c @@ -1845,7 +1845,7 @@ static int __devexit omap_mcbsp_remove(struct platform_device *pdev) mcbsp->fclk = NULL; mcbsp->iclk = NULL; - mcbsp->free = 0; + mcbsp->free = 1; mcbsp->dev = NULL; } -- 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
[PATCH v2] McBSP: Fix the free variable update at remove.
From: Shubhrajyoti D
At remove the free variable is wrongly updated.Attempting to solve the same.
Signed-off-by: Shubhrajyoti D
---
-[v2] Instead of using 0/1 use a macro
arch/arm/plat-omap/include/plat/mcbsp.h |3 +++
arch/arm/plat-omap/mcbsp.c | 10 +-
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/mcbsp.h
b/arch/arm/plat-omap/include/plat/mcbsp.h
index b87d83c..8988733 100644
--- a/arch/arm/plat-omap/include/plat/mcbsp.h
+++ b/arch/arm/plat-omap/include/plat/mcbsp.h
@@ -37,6 +37,9 @@ static struct platform_device omap_mcbsp##port_nr = { \
.id = OMAP_MCBSP##port_nr, \
}
+#define TRUE 1
+#define FALSE 0
+
#define OMAP7XX_MCBSP1_BASE0xfffb1000
#define OMAP7XX_MCBSP2_BASE0xfffb1800
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index eac4b97..438b3c7 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -755,7 +755,7 @@ int omap_mcbsp_request(unsigned int id)
goto err_kfree;
}
- mcbsp->free = 0;
+ mcbsp->free = FALSE;
mcbsp->reg_cache = reg_cache;
spin_unlock(&mcbsp->lock);
@@ -815,7 +815,7 @@ err_clk_disable:
clk_disable(mcbsp->iclk);
spin_lock(&mcbsp->lock);
- mcbsp->free = 1;
+ mcbsp->free = TRUE;
mcbsp->reg_cache = NULL;
err_kfree:
spin_unlock(&mcbsp->lock);
@@ -858,7 +858,7 @@ void omap_mcbsp_free(unsigned int id)
if (mcbsp->free)
dev_err(mcbsp->dev, "McBSP%d was not reserved\n", mcbsp->id);
else
- mcbsp->free = 1;
+ mcbsp->free = TRUE;
mcbsp->reg_cache = NULL;
spin_unlock(&mcbsp->lock);
@@ -1771,7 +1771,7 @@ static int __devinit omap_mcbsp_probe(struct
platform_device *pdev)
spin_lock_init(&mcbsp->lock);
mcbsp->id = id + 1;
- mcbsp->free = 1;
+ mcbsp->free = TRUE;
mcbsp->dma_tx_lch = -1;
mcbsp->dma_rx_lch = -1;
@@ -1845,7 +1845,7 @@ static int __devexit omap_mcbsp_remove(struct
platform_device *pdev)
mcbsp->fclk = NULL;
mcbsp->iclk = NULL;
- mcbsp->free = 0;
+ mcbsp->free = TRUE;
mcbsp->dev = NULL;
}
--
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
[PATCH v2 ] McBSP: Fix the free variable update at remove
From: Shubhrajyoti D At remove the free variable is wrongly updated.Attempting to solve the same. Signed-off-by: Shubhrajyoti D Reported-by: Vikram Pandita --- -[v2] Instead of using 0/1 use true/false arch/arm/plat-omap/mcbsp.c | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c index eac4b97..07c0525 100644 --- a/arch/arm/plat-omap/mcbsp.c +++ b/arch/arm/plat-omap/mcbsp.c @@ -755,7 +755,7 @@ int omap_mcbsp_request(unsigned int id) goto err_kfree; } - mcbsp->free = 0; + mcbsp->free = false; mcbsp->reg_cache = reg_cache; spin_unlock(&mcbsp->lock); @@ -815,7 +815,7 @@ err_clk_disable: clk_disable(mcbsp->iclk); spin_lock(&mcbsp->lock); - mcbsp->free = 1; + mcbsp->free = true; mcbsp->reg_cache = NULL; err_kfree: spin_unlock(&mcbsp->lock); @@ -858,7 +858,7 @@ void omap_mcbsp_free(unsigned int id) if (mcbsp->free) dev_err(mcbsp->dev, "McBSP%d was not reserved\n", mcbsp->id); else - mcbsp->free = 1; + mcbsp->free = true; mcbsp->reg_cache = NULL; spin_unlock(&mcbsp->lock); @@ -1771,7 +1771,7 @@ static int __devinit omap_mcbsp_probe(struct platform_device *pdev) spin_lock_init(&mcbsp->lock); mcbsp->id = id + 1; - mcbsp->free = 1; + mcbsp->free = true; mcbsp->dma_tx_lch = -1; mcbsp->dma_rx_lch = -1; @@ -1845,7 +1845,7 @@ static int __devexit omap_mcbsp_remove(struct platform_device *pdev) mcbsp->fclk = NULL; mcbsp->iclk = NULL; - mcbsp->free = 0; + mcbsp->free = true; mcbsp->dev = NULL; } -- 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
[PATCH ] McBSP:Make the free variable update more readable
From: Shubhrajyoti D Using true/false instead of 1/0 to update the free variable. Signed-off-by: Shubhrajyoti D --- arch/arm/plat-omap/mcbsp.c | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c index eac4b97..07c0525 100644 --- a/arch/arm/plat-omap/mcbsp.c +++ b/arch/arm/plat-omap/mcbsp.c @@ -755,7 +755,7 @@ int omap_mcbsp_request(unsigned int id) goto err_kfree; } - mcbsp->free = 0; + mcbsp->free = false; mcbsp->reg_cache = reg_cache; spin_unlock(&mcbsp->lock); @@ -815,7 +815,7 @@ err_clk_disable: clk_disable(mcbsp->iclk); spin_lock(&mcbsp->lock); - mcbsp->free = 1; + mcbsp->free = true; mcbsp->reg_cache = NULL; err_kfree: spin_unlock(&mcbsp->lock); @@ -858,7 +858,7 @@ void omap_mcbsp_free(unsigned int id) if (mcbsp->free) dev_err(mcbsp->dev, "McBSP%d was not reserved\n", mcbsp->id); else - mcbsp->free = 1; + mcbsp->free = true; mcbsp->reg_cache = NULL; spin_unlock(&mcbsp->lock); @@ -1771,7 +1771,7 @@ static int __devinit omap_mcbsp_probe(struct platform_device *pdev) spin_lock_init(&mcbsp->lock); mcbsp->id = id + 1; - mcbsp->free = 1; + mcbsp->free = true; mcbsp->dma_tx_lch = -1; mcbsp->dma_rx_lch = -1; -- 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
[PATCH v7] Enable Runtime PM functionality in OMAP4 driver based on the following assumptions:
From: Abraham Arce - Runtime PM selected by ARCH_OMAP2PLUS_TYPICAL && ARCH_OMAP2PLUS, which is the default OMAP2+ defconfig including OMAP4 - Runtime PM APIs handles Clock Framework APIs - Do not do the keypadconfig if the irq request fails A minimal pm runtime get/put approach is implemented in probe/remove calls respectively based on: - Keyboard controller in wakeup domain so it is always on and power impact may be minimal - Cutting of clocks will prevent interrupts Signed-off-by: Abraham Arce Cc: Kevin Hilman --- Updating the changelogs as per Kevin's suggestion drivers/input/keyboard/omap4-keypad.c | 11 +-- 1 files changed, 9 insertions(+), 2 deletions(-) diff --git a/drivers/input/keyboard/omap4-keypad.c b/drivers/input/keyboard/omap4-keypad.c index 45bd097..36239e2 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,7 +240,8 @@ 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); - omap4_keypad_config(keypad_data); + pm_runtime_enable(&pdev->dev); + pm_runtime_get_sync(&pdev->dev); error = request_irq(keypad_data->irq, omap4_keypad_interrupt, IRQF_TRIGGER_RISING, @@ -255,8 +257,9 @@ static int __devinit omap4_keypad_probe(struct platform_device *pdev) goto err_free_irq; } - + omap4_keypad_config(keypad_data); platform_set_drvdata(pdev, keypad_data); + return 0; err_free_irq: @@ -278,6 +281,10 @@ static int __devexit omap4_keypad_remove(struct platform_device *pdev) struct resource *res; free_irq(keypad_data->irq, keypad_data); + + pm_runtime_put_sync(&pdev->dev); + pm_runtime_disable(&pdev->dev); + input_unregister_device(keypad_data->input); iounmap(keypad_data->base); -- 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
[PATCH 0/3]OMAP4: Keypad support
From: Shubhrajyoti D Adding the keypad 4430sdp board support and PM runtime change. Tested on 4430sdp. Abraham Arce (1): OMAP4:keypad: PM runtime Benoit Cousson (1): OMAP4: hwmod data: Add keypad in the hwmod database Syed Rafiuddin (1): OMAP4: keypad: Add the board support. arch/arm/mach-omap2/board-4430sdp.c| 89 arch/arm/mach-omap2/devices.c | 41 + arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 70 ++ drivers/input/keyboard/omap4-keypad.c |8 +++ 4 files changed, 208 insertions(+), 0 deletions(-) -- 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 v8 2/3] OMAP4: keypad: Add the board support.
From: Syed Rafiuddin
-Add the platform changes for the keypad driver
-Register keyboard device with hwmod framework.
Signed-off-by: Syed Rafiuddin
Signed-off-by: Abraham Arce
Signed-off-by: Shubhrajyoti D
---
arch/arm/mach-omap2/board-4430sdp.c | 89 +++
arch/arm/mach-omap2/devices.c | 41
2 files changed, 130 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 9525515..0bbceb3 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include "mux.h"
#include "hsmmc.h"
@@ -48,6 +49,90 @@
#define OMAP4_SFH7741_SENSOR_OUTPUT_GPIO 184
#define OMAP4_SFH7741_ENABLE_GPIO 188
+static const 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",
@@ -591,6 +676,10 @@ static void __init omap_4430sdp_init(void)
spi_register_board_info(sdp4430_spi_board_info,
ARRAY_SIZE(sdp4430_spi_board_info));
}
+
+ status = omap4_keyboard_init(&sdp4430_keypad_data);
+ if (status)
+ pr_err("Keypad initialization failed: %d\n", status);
}
static void __init omap_4430sdp_map_io(void)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 1bca147..24831af 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include "mux.h"
#include "control.h"
@@ -141,6 +142,46 @@ static inline void omap_init_camera(void)
}
#endif
+struct omap_device_pm_latency omap_keyboard_latency[] = {
+ {
+ .deactivate_func = omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+ },
+};
+
+int __init omap4_keyboard_init(struct omap4_keypad_platform_data
+ *sdp4430_keypad_data)
+{
+ struct omap_device *od;
+ struct omap_hwmod *oh;
+ struct omap4_keypad_platform_data *keypad_data;
+ unsigned int id = -1;
+ char *oh_name = "kbd";
+ char *name = "omap4-keypad";
+
+ oh = omap_hwmod_lookup(oh_name);
+ if (!oh) {
+ pr_err("Could not look up %s\n", oh_name);
+ return -ENODEV;
+ }
+
+ keypad_data = sdp4430_keypad_data;
+
+ od = omap_device_build(name, id, oh, keypad_data,
+ sizeof(struct omap4_keypad
[PATCH v8 3/3] OMAP4:keypad: PM runtime
From: Abraham Arce Enable Runtime PM functionality in OMAP4 driver based on the following assumptions A minimal pm runtime get/put approach is implemented in probe/remove calls respectively. - Keyboard controller in wakeup domain so it is always on and power impact may be minimal - In OMAP4 the device control is at module/device level and ick/fclk level control is difficult so cutting of clocks will prevent interrupts. Signed-off-by: Abraham Arce Cc: Kevin Hilman Signed-off-by: Shubhrajyoti D --- drivers/input/keyboard/omap4-keypad.c |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/drivers/input/keyboard/omap4-keypad.c b/drivers/input/keyboard/omap4-keypad.c index 45bd097..fcfbb9b 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, @@ -278,6 +282,10 @@ static int __devexit omap4_keypad_remove(struct platform_device *pdev) struct resource *res; free_irq(keypad_data->irq, keypad_data); + + pm_runtime_put_sync(&pdev->dev); + pm_runtime_disable(&pdev->dev); + input_unregister_device(keypad_data->input); iounmap(keypad_data->base); -- 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
[PATCH v8 1/3] OMAP4: hwmod data: Add keypad in the hwmod database
From: Benoit Cousson
Add hwmod data for OMAP4 keyboard controller
taking Benoit's patch:
OMAP4: hwmod: Add partial hwmod support for OMAP4430
Signed-off-by: Benoit Cousson
Signed-off-by: Abraham Arce
Signed-off-by: Shubhrajyoti D
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 70
1 files changed, 70 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 f9778fb..a0c6c39 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -657,6 +657,73 @@ 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
*/
@@ -1509,6 +1576,9 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
&omap44xx_gpio5_hwmod,
&omap44xx_gpio6_hwmod,
+ /* kbd class */
+ &omap44xx_kbd_hwmod,
+
/* mpu class */
&omap44xx_mpu_hwmod,
/* wd_timer class */
--
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 v8 3/3] OMAP4:keypad: PM runtime
Missed adding linux omap On Tuesday 08 February 2011 02:00 PM, Shubhrajyoti wrote: Hello, Any comments/suggestions. Thanks, On Monday 27 December 2010 11:21 AM, shubhrajy...@ti.com wrote: From: Abraham Arce Enable Runtime PM functionality in OMAP4 driver based on the following assumptions A minimal pm runtime get/put approach is implemented in probe/remove calls respectively. - Keyboard controller in wakeup domain so it is always on and power impact may be minimal - In OMAP4 the device control is at module/device level and ick/fclk level control is difficult so cutting of clocks will prevent interrupts. Signed-off-by: Abraham Arce Cc: Kevin Hilman Signed-off-by: Shubhrajyoti D --- drivers/input/keyboard/omap4-keypad.c |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/drivers/input/keyboard/omap4-keypad.c b/drivers/input/keyboard/omap4-keypad.c index 45bd097..fcfbb9b 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, @@ -278,6 +282,10 @@ static int __devexit omap4_keypad_remove(struct platform_device *pdev) struct resource *res; free_irq(keypad_data->irq, keypad_data); + +pm_runtime_put_sync(&pdev->dev); +pm_runtime_disable(&pdev->dev); + input_unregister_device(keypad_data->input); iounmap(keypad_data->base); -- 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 3/3] OMAP4:keypad: PM runtime
Hello Dmitry, If there are no further comments. Can it be queued? With Regards, Shubhro On Tuesday 08 February 2011 02:00 PM, Shubhrajyoti wrote: Hello, Any comments/suggestions. Thanks, On Monday 27 December 2010 11:21 AM, shubhrajy...@ti.com wrote: From: Abraham Arce Enable Runtime PM functionality in OMAP4 driver based on the following assumptions A minimal pm runtime get/put approach is implemented in probe/remove calls respectively. - Keyboard controller in wakeup domain so it is always on and power impact may be minimal - In OMAP4 the device control is at module/device level and ick/fclk level control is difficult so cutting of clocks will prevent interrupts. Signed-off-by: Abraham Arce Cc: Kevin Hilman Signed-off-by: Shubhrajyoti D --- drivers/input/keyboard/omap4-keypad.c |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/drivers/input/keyboard/omap4-keypad.c b/drivers/input/keyboard/omap4-keypad.c index 45bd097..fcfbb9b 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, @@ -278,6 +282,10 @@ static int __devexit omap4_keypad_remove(struct platform_device *pdev) struct resource *res; free_irq(keypad_data->irq, keypad_data); + +pm_runtime_put_sync(&pdev->dev); +pm_runtime_disable(&pdev->dev); + input_unregister_device(keypad_data->input); iounmap(keypad_data->base); -- 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 3/3] OMAP4:keypad: PM runtime
On Wednesday 23 February 2011 11:59 AM, Dmitry Torokhov wrote: On Sat, Feb 19, 2011 at 01:44:32PM +0530, Datta, Shubhrajyoti wrote: On Sat, Feb 19, 2011 at 11:01 AM, Dmitry Torokhov wrote: Hi Shubhrajyoti, On Sat, Feb 19, 2011 at 08:37:15AM +0530, Shubhrajyoti wrote: Hello Dmitry, If there are no further comments. Can it be queued? I normally try not to merge board code leaving it to arch owner. Can we at least get arch/board maintainer ACKs on this? Also, I am wondering, what is the utility of this patch? Without it, as far as I understand, runtime PM is disabled for the device. With the patch we enable runtime PM but immediately bump up usage count, thus ensuring that the device is always powered on. So what changed? Or am I missing something? After the hwmod changes the clocks are cut. So if it is not enabled then the device is not usable. OK, that makes sense. So since we are wiring up runtime PM I think we should go a strep further and do it in open/close methods. Does the patch below still work for you? Yes it works I did some basic testinig it on omap4 sdp. Thanks Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap4: hwmod: Enable the keypad
On Thursday 24 February 2011 04:28 PM, Cousson, Benoit wrote:
On 2/24/2011 6:42 AM, Datta, Shubhrajyoti wrote:
From: Shubhrajyoti D
Enable the keypad in the hwmod database.
Signed-off-by: Shubhrajyoti D
Cc: Benoit Cousson
Acked-by: Benoit Cousson
Could this patch be queued for the next merge window. If there are no
further comments.
Thanks and regards,
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 79a8601..5af80d6 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -5056,7 +5056,7 @@ static __initdata struct omap_hwmod
*omap44xx_hwmods[] = {
&omap44xx_iva_seq1_hwmod,
/* kbd class */
-/* &omap44xx_kbd_hwmod, */
+ &omap44xx_kbd_hwmod,
/* mailbox class */
&omap44xx_mailbox_hwmod,
--
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][RFC] OMAP4: I2C : I2C context save
On Monday 20 June 2011 09:05 PM, Kevin Hilman wrote:
shubhrajy...@ti.com writes:
From: Shubhrajyoti D
Currently the OMAP4 doesnot hit device off still the
driver may have support for it.Adding support for the
same.
Signed-off-by: Shubhrajyoti D
Please Cc linux-omap as this change to the hwmod data would go through
Tony.
Yes , missed out.
Also, please describe why this hwmod data change affects the problem
described in the changelog.
After Andy's patch set
static void omap_i2c_unidle(struct omap_i2c_dev *dev)
{
pm_runtime_get_sync(&pdev->dev);
if (pdata->flags & OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, dev->pscstate);
omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, dev->scllstate);
omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, dev->sclhstate);
omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, dev->bufstate);
omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG, dev->syscstate);
omap_i2c_write_reg(dev, OMAP_I2C_WE_REG, dev->westate);
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
}
dev->idle = 0;
This is dependent on the flag, I am making it true for OMAP4 also.
Kevin
---
Applies on top of patches from Andy Green
http://www.spinics.net/lists/linux-i2c/msg05632.html
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 0fe9556..5e2c748 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2130,7 +2130,8 @@ static struct omap_hwmod_class omap44xx_i2c_hwmod_class =
{
};
static struct omap_i2c_dev_attr i2c_dev_attr = {
- .flags = OMAP_I2C_FLAG_BUS_SHIFT_NONE,
+ .flags = OMAP_I2C_FLAG_BUS_SHIFT_NONE |
+ OMAP_I2C_FLAG_RESET_REGS_POSTIDLE,
};
/* i2c1 */
--
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] OMAP4: I2C: Enable FIFO usage for OMAP4
On Thursday 30 June 2011 04:53 AM, Kevin Hilman wrote: Shubhrajyoti D writes: Currently the fifo depth is set to zero for OMAP4 which disables the FIFO usage. This patch enables the FIFO usage for I2C transactions on OMAP4 also. Do you know the history of why the FIFO depth was set to zero? A summary of that history would greatly help reviewers. Reported-By:Nishanth Menon minor: missing space after ':' Signed-off-by: Shubhrajyoti D Tested on what platforms? OMAP3 also? OMAP4 and OMAP3 Could you please rebase this onto my for_3.1/i2c-andy branch[1] where we have a large series of I2C patches queued up for the v3.1 merge window already? OK will rebase and resend. Thanks, Kevin [1] git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git -- 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] OMAP4: I2C: Enable FIFO usage for OMAP4
On Friday 01 July 2011 04:20 AM, Kevin Hilman wrote: Shubhrajyoti writes: On Thursday 30 June 2011 04:53 AM, Kevin Hilman wrote: Shubhrajyoti D writes: Currently the fifo depth is set to zero for OMAP4 which disables the FIFO usage. This patch enables the FIFO usage for I2C transactions on OMAP4 also. Do you know the history of why the FIFO depth was set to zero? A summary of that history would greatly help reviewers. Looks like it is disabled in the initial bring up and some how didn’t get enabled. All I could find is http://www.mail-archive.com/linux-i2c@vger.kernel.org/msg01404.html Reported-By:Nishanth Menon minor: missing space after ':' Yes will fix it. Signed-off-by: Shubhrajyoti D Tested on what platforms? OMAP3 also? OMAP4 and OMAP3 Please add a brief summary of what platforms it was tested on in the changelog. Will update it Could you please rebase this onto my for_3.1/i2c-andy branch[1] where we have a large series of I2C patches queued up for the v3.1 merge window already? OK will rebase and resend. Sent a rebased version. 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][RFC] OMAP4: I2C : I2C context save
On Wednesday 06 July 2011 12:01 AM, Kevin Hilman wrote:
Shubhrajyoti writes:
On Monday 20 June 2011 09:05 PM, Kevin Hilman wrote:
shubhrajy...@ti.com writes:
From: Shubhrajyoti D
Currently the OMAP4 doesnot hit device off still the
driver may have support for it.Adding support for the
same.
Signed-off-by: Shubhrajyoti D
Please Cc linux-omap as this change to the hwmod data would go through
Tony.
Yes , missed out.
Also, please describe why this hwmod data change affects the problem
described in the changelog.
After Andy's patch set
static void omap_i2c_unidle(struct omap_i2c_dev *dev)
{
pm_runtime_get_sync(&pdev->dev);
if (pdata->flags& OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, dev->pscstate);
omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, dev->scllstate);
omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, dev->sclhstate);
omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, dev->bufstate);
omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG, dev->syscstate);
omap_i2c_write_reg(dev, OMAP_I2C_WE_REG, dev->westate);
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
}
dev->idle = 0;
This is dependent on the flag, I am making it true for OMAP4 also.
What I meant was: please describe this in the changelog. Without more
detail, the hwmod change itself is not understandable.
Yes , will explain it in the change logs.
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] OMAP4: Keyboard: Mux changes in the board file
On Tuesday 12 July 2011 01:38 AM, Kevin Hilman wrote:
On Fri, 2011-07-01 at 00:48 -0700, Tony Lindgren wrote:
* Shubhrajyoti D [110623 05:10]:
The mux settings for keypad are done for omap4430sdp in
board file.
Applying into devel-board branch.
+static struct omap_board_data keypad_data = {
+ .id = 1,
+ .pads= keypad_pads,
+ .pads_cnt = ARRAY_SIZE(keypad_pads),
+};
Aligned this struct better.
This patch (and this struct) introduces another section mismatch warning
because it references another struct which is __initdata but the struct
itself is not:
WARNING: vmlinux.o(.data+0x37788): Section mismatch in reference from
the variable keypad_data to the (unknown reference) .init.data:(unknown)
The variable keypad_data references
the (unknown reference) __initdata (unknown)
A quick glance suggests the the right fix is that this struct should
also be __initdata:
Yes , will incorporate the comments and send a patch.
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index c7cef44..66758bf 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -199,7 +199,7 @@ static struct omap4_keypad_platform_data
sdp4430_keypad_data = {
.cols = 8,
};
-static struct omap_board_data keypad_data = {
+static struct omap_board_data keypad_data __initdata = {
.id = 1,
.pads = keypad_pads,
.pads_cnt = ARRAY_SIZE(keypad_pads),
--
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: Keypad: Make keypad_data initdata
On Tuesday 12 July 2011 12:09 PM, Vishwanath Sripathy wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Shubhrajyoti D
Sent: Tuesday, July 12, 2011 12:02 PM
To: linux-omap@vger.kernel.org
Cc: Shubhrajyoti D
Subject: [PATCH] OMAP: Keypad: Make keypad_data initdata
The keypad data is accessed only at init so making it initdata.
This removes the section mismatch warning.
Reported-by: Kevin Hilman
Signed-off-by: Shubhrajyoti D
---
arch/arm/mach-omap2/board-4430sdp.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-
omap2/board-4430sdp.c
Is this issue only for OMAP4 SDP? What about Panda, Beagle, OMAP3 SDP
boards?
If it's only for OMAP4, pls correct the subject.
Yes will correct the subject line.
Vishwa
index 47e6ab9..2b28c7e 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -195,7 +195,7 @@ static struct omap4_keypad_platform_data
sdp4430_keypad_data = {
.cols = 8,
};
-static struct omap_board_data keypad_data = {
+static struct omap_board_data keypad_data __initdata = {
.id = 1,
.pads= keypad_pads,
.pads_cnt = ARRAY_SIZE(keypad_pads),
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-
omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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][RFC] OMAP4: I2C : I2C context save
On Thursday 14 July 2011 02:57 AM, Hilman, Kevin wrote: On Wed, Jul 13, 2011 at 2:15 PM, Kevin Hilman wrote: Ben Dooks writes: On Tue, Jul 05, 2011 at 02:50:46PM +0530, Shubhrajyoti D wrote: Currently the OMAP4 doesnot hit device off still the driver may have support for it.Adding support for the same. Signed-off-by: Shubhrajyoti D I guess since the previous set has been taken by Kevin then these will be too. Sure, I'll pick these up, but it's probably to late for v3.1. We've already submitted the bulk of the OMAP stuff for v3.1. Kevin in the folowing I tried taking the comments do do have any further comments or suggestions. http://www.spinics.net/lists/linux-i2c/msg05823.html I should've also said I'll pick these up when they are ready. There are still some comments that need addressing. 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] OMAP4:hwmod: I2C : I2C context save
Please ignore the patch sent another one with correct sub line
On Thursday 14 July 2011 10:03 PM, Shubhrajyoti D wrote:
Restore of context is not done for OMAP4. This patch
adds the OMAP_I2C_FLAG_RESET_REGS_POSTIDLE in the OMAP4
hwmod data which activates the restore for OMAP4.
Currently the OMAP4 does not hit device off still the
driver may have support for it.
Signed-off-by: Shubhrajyoti D
---
Applies on top of patches from Andy Green
http://www.spinics.net/lists/linux-i2c/msg05632.html
Tested on OMAP4430
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 0fe9556..5e2c748 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2130,7 +2130,8 @@ static struct omap_hwmod_class omap44xx_i2c_hwmod_class =
{
};
static struct omap_i2c_dev_attr i2c_dev_attr = {
- .flags = OMAP_I2C_FLAG_BUS_SHIFT_NONE,
+ .flags = OMAP_I2C_FLAG_BUS_SHIFT_NONE |
+ OMAP_I2C_FLAG_RESET_REGS_POSTIDLE,
};
/* i2c1 */
--
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] OMAP4: hwmod data: I2C: add flag for context restore
On Saturday 16 July 2011 03:25 AM, Kevin Hilman wrote:
Shubhrajyoti D writes:
Restore of context is not done for OMAP4. This patch
adds the OMAP_I2C_FLAG_RESET_REGS_POSTIDLE in the OMAP4
hwmod data which activates the restore for OMAP4.
Currently the OMAP4 does not hit device off still the
driver may have support for it.
Signed-off-by: Shubhrajyoti D
Reviewed-by: Kevin Hilman
Please repost one more time with the linux-arm-kernel list Cc'd (and you
can add my reviewed-by tag.)
Paul can then probably queue this for v3.1-rc
Kevin
OK thanks
---
Applies on top of patches from Andy Green
http://www.spinics.net/lists/linux-i2c/msg05632.html
Tested on OMAP4430
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 0fe9556..5e2c748 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2130,7 +2130,8 @@ static struct omap_hwmod_class omap44xx_i2c_hwmod_class =
{
};
static struct omap_i2c_dev_attr i2c_dev_attr = {
- .flags = OMAP_I2C_FLAG_BUS_SHIFT_NONE,
+ .flags = OMAP_I2C_FLAG_BUS_SHIFT_NONE |
+ OMAP_I2C_FLAG_RESET_REGS_POSTIDLE,
};
/* i2c1 */
--
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: [PATCHV2 2/5] OMAP: I2C: Reset support
On Thursday 21 July 2011 04:49 PM, Santosh Shilimkar wrote: On 7/21/2011 4:39 PM, Shubhrajyoti D wrote: Under some error conditions the i2c driver may do a reset adding support in the platform. Signed-off-by: Shubhrajyoti D --- As commented on 1/5, this one should be folded with 1/5 unless and until you have some valid reason. Thanks for your review. Will combine the patches and send. 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: [PATCHV3 2/4] OMAP: I2C: Remove the reset in the init path
On Thursday 21 July 2011 07:29 PM, Felipe Balbi wrote: Hi, On Thu, Jul 21, 2011 at 07:22:59PM +0530, Shubhrajyoti D wrote: The reset in the driver at init is not needed anymore as the hwmod framework takes care of reseting it. Signed-off-by: Shubhrajyoti D this is still doing two things: a. remove the reset from init path b. add and use ->device_reset() when needed. Yes agree , will add it. -- 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: HSI framework for linux-next
On Friday 28 October 2011 04:53 PM, Artem Bityutskiy wrote: On Fri, 2011-10-28 at 12:27 +0300, Carlos Chinea wrote: Hi Stephen, I have been working in an HSI framework for linux: https://lkml.org/lkml/2011/6/10/280 The framework is in good shape and is currently being used for some people so we would like it to see it integrated, if possible, for 3.3 Latest discussion for integration: https://lkml.org/lkml/2011/10/20/177 Stephen, I confirm that this is useful and solid framework, works well, and we are also interested to see it upstream. Yes also it may help others to hook up their controller support. Thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP4: I2C: Enable FIFO usage for OMAP4
On Thursday 14 July 2011 12:50 AM, Ben Dooks wrote:
> On Tue, Jul 05, 2011 at 05:01:01PM -0700, Kevin Hilman wrote:
>> Shubhrajyoti D writes:
>>
>>> Currently the fifo depth is set to zero for OMAP4 which disables
>>> the FIFO usage. This patch enables the FIFO usage for I2C transactions
>>> on OMAP4 also.
>>>
>>> Tested on omap4430 and 3430.
>>>
>>> Reported-By: Nishanth Menon
>>> Signed-off-by: Shubhrajyoti D
>>> ---
>>> Rebased on top of the series by Andy Green
>>> http://www.spinics.net/lists/linux-i2c/msg05632.html
>> Thanks.
>>
>> This is v3.1 material, but would be nice to see a couple tested-by or
>> acked-by tags from folks that are more actively using the I2C driver
>> before merging
>>
>> Kevin
> guess you'll be picking these up?
Ben Could this patch be lined up as well?
>
>>> drivers/i2c/busses/i2c-omap.c | 11 ++-
>>> 1 files changed, 6 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
>>> index d53cd61..8f87a37 100644
>>> --- a/drivers/i2c/busses/i2c-omap.c
>>> +++ b/drivers/i2c/busses/i2c-omap.c
>>> @@ -1068,13 +1068,14 @@ omap_i2c_probe(struct platform_device *pdev)
>>> * size. This is to ensure that we can handle the status on int
>>> * call back latencies.
>>> */
>>> - if (dev->rev >= OMAP_I2C_REV_ON_3530_4430) {
>>> - dev->fifo_size = 0;
>>> +
>>> + dev->fifo_size = (dev->fifo_size / 2);
>>> +
>>> + if (dev->rev >= OMAP_I2C_REV_ON_3530_4430)
>>> dev->b_hw = 0; /* Disable hardware fixes */
>>> - } else {
>>> - dev->fifo_size = (dev->fifo_size / 2);
>>> + else
>>> dev->b_hw = 1; /* Enable hardware fixes */
>>> - }
>>> +
>>> /* calculate wakeup latency constraint for MPU */
>>> if (dev->set_mpu_wkup_lat != NULL)
>>> dev->latency = (100 * dev->fifo_size) /
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-i2c" 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] OMAP4: I2C: Enable FIFO usage for OMAP4
On Thursday 03 November 2011 07:51 PM, Kevin Hilman wrote: > Shubhrajyoti writes: > >> On Thursday 14 July 2011 12:50 AM, Ben Dooks wrote: >>> On Tue, Jul 05, 2011 at 05:01:01PM -0700, Kevin Hilman wrote: >>>> Shubhrajyoti D writes: >>>> >>>>> Currently the fifo depth is set to zero for OMAP4 which disables >>>>> the FIFO usage. This patch enables the FIFO usage for I2C transactions >>>>> on OMAP4 also. >>>>> >>>>> Tested on omap4430 and 3430. >>>>> >>>>> Reported-By: Nishanth Menon >>>>> Signed-off-by: Shubhrajyoti D >>>>> --- >>>>> Rebased on top of the series by Andy Green >>>>> http://www.spinics.net/lists/linux-i2c/msg05632.html >>>> Thanks. >>>> >>>> This is v3.1 material, but would be nice to see a couple tested-by or >>>> acked-by tags from folks that are more actively using the I2C driver >>>> before merging >>>> >>>> Kevin >>> guess you'll be picking these up? >> Ben Could this patch be lined up as well? > Please update this patch against my for_3.2/i2c-cleanup branch, and add > the Tested-by from Nishanth Menon. > > Then I will push to get this in as a fix for v3.2-rc. Thanks the patch was already rebased to the for_3.2/i2c-cleanup branch and applies on your tree . Resent it adding Nishanth's Tested-by 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 v2] omap4: i2c: add post idle reset registers flag
On Tuesday 08 November 2011 03:01 AM, David Anders wrote:
> omap44xx i2c devices need to have the registers reset post idle
> similar to omap3xxx devices. this adds the additional flag for
> OMAP_I2C_FLAG_RESET_REGS_POSTIDLE to the omap44xx i2c_dev_attr.
Hello Anders a similar patch is already posted
http://www.spinics.net/lists/linux-i2c/msg05913.html
> Signed-off-by: David Anders
> ---
> arch/arm/mach-omap2/omap_hwmod_44xx_data.c |3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> index 7695e5d..e93dc40 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> @@ -2257,7 +2257,8 @@ static struct omap_hwmod_class omap44xx_i2c_hwmod_class
> = {
> };
>
> static struct omap_i2c_dev_attr i2c_dev_attr = {
> - .flags = OMAP_I2C_FLAG_BUS_SHIFT_NONE,
> + .flags = OMAP_I2C_FLAG_RESET_REGS_POSTIDLE |
> + OMAP_I2C_FLAG_BUS_SHIFT_NONE,
> };
>
> /* i2c1 */
--
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 v7 11/21] OMAP2+: UART: Move errata handling from serial.c to omap-serial
On Friday 11 November 2011 05:14 AM, Jon Hunter wrote: > Hi Govindraj, > > On 10/18/2011 10:26, Govindraj.R wrote: >> Move the errata handling mechanism from serial.c to omap-serial file >> and utilise the same func in driver file. >> >> Errata i202, i291 are moved to be handled with omap-serial >> Moving the errata macro from serial.c file to driver header file >> as from on errata will be handled in driver file itself. >> Corrected errata id from chapter reference 2.15 to errata id i291. >> >> Removed errata and dma_enabled feilds from omap_uart_state struct Nitpick. The field spelling could be corrected. >> as they are no more needed with errata handling done within omap-serial. >> >> Acked-by: Alan Cox >> Signed-off-by: Govindraj.R >> --- >> arch/arm/mach-omap2/serial.c | 97 >> +++-- >> arch/arm/plat-omap/include/plat/omap-serial.h |6 ++ >> drivers/tty/serial/omap-serial.c | 66 - >> 3 files changed, 95 insertions(+), 74 deletions(-) > > [snip] > >> +/* Enable the MDR1 errata for OMAP3 */ >> +if (cpu_is_omap34xx()&& !cpu_is_ti816x()) >> +omap_up.errata |= UART_ERRATA_i202_MDR1_ACCESS; > > This errata (i202) is applicable to all devices from OMAP2430 to > OMAP4460 (apparently this one is not getting fixed). So could you make > sure this is enabled for 2430, 3430, 3630, 4430 and 4460? > Yes good point. > [snip] > >> +/* >> + * Work Around for Errata i202 (3430 - 1.12, 3630 - 1.6) > > We should update the comment to be "Work Around for Errata i202 (2430, > 3430, 3630, 4430 and 4460)". The "1.12" and "1.6" are just the section > references in the errata docs, but I think that you can drop these as > you can just search for the errata ID which is i202. > > Cheers > Jon > > > > -- > 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: [REPOST PATCH 1/2 v4] OMAP2+: hwmod: Add API to enable IO ring wakeup.
On Monday 04 July 2011 10:25 AM, Govindraj.R wrote:
> Add API to enable IO pad wakeup capability based on mux dynamic pad and
> wake_up enable flag available from hwmod_mux initialization.
>
> Use the wakeup_enable flag and enable wakeup capability
> for the given pads. Wakeup capability will be enabled/disabled
> during hwmod idle transition based on whether wakeup_flag is
> set or cleared.
>
> Map the enable/disable pad wakeup API's to hwmod_wakeup_enable/disable.
>
> Signed-off-by: Govindraj.R
> ---
> arch/arm/mach-omap2/omap_hwmod.c | 59
> ++
> 1 files changed, 59 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod.c
> b/arch/arm/mach-omap2/omap_hwmod.c
> index 293fa6c..3b28e0a 100644
> --- a/arch/arm/mach-omap2/omap_hwmod.c
> +++ b/arch/arm/mach-omap2/omap_hwmod.c
> @@ -1770,6 +1770,34 @@ static int __init omap_hwmod_setup_all(void)
> core_initcall(omap_hwmod_setup_all);
>
> /**
> + * omap_hwmod_set_ioring_wakeup - enable io pad wakeup flag.
> + * @oh: struct omap_hwmod *
> + * @set: bool value indicating to set or clear wakeup status.
> + *
> + * Set or Clear wakeup flag for the io_pad.
> + */
> +static int omap_hwmod_set_ioring_wakeup(struct omap_hwmod *oh, bool set_wake)
> +{
> + struct omap_device_pad *pad;
> + int ret = -EINVAL, j;
> +
> + if (oh->mux && oh->mux->enabled) {
> + for (j = 0; j < oh->mux->nr_pads_dynamic; j++) {
> + pad = oh->mux->pads_dynamic[j];
> + if (pad->flags & OMAP_DEVICE_PAD_WAKEUP) {
> + if (set_wake)
> + pad->idle |= OMAP_WAKEUP_EN;
> + else
> + pad->idle &= ~OMAP_WAKEUP_EN;
Will this not erase the other bits ?
Should we read and erase only the wakeup bits.
Am I missing something ?
> + ret = 0;
> + }
> + }
> + }
> +
> + return ret;
> +}
> +
> +/**
> * omap_hwmod_enable - enable an omap_hwmod
> * @oh: struct omap_hwmod *
> *
> @@ -2097,6 +2125,35 @@ int omap_hwmod_del_initiator_dep(struct omap_hwmod *oh,
> {
> return _del_initiator_dep(oh, init_oh);
> }
> +/**
> + * omap_hwmod_enable_ioring_wakeup - Set wakeup flag for iopad.
> + * @oh: struct omap_hwmod *
> + *
> + * Traverse through dynamic pads, if pad is enabled then
> + * set wakeup enable bit flag for the mux pin. Wakeup pad bit
> + * will be set during hwmod idle transistion.
> + * Return error if pads are not enabled or not available.
> + */
> +int omap_hwmod_enable_ioring_wakeup(struct omap_hwmod *oh)
> +{
> + /* Enable pad wake-up capability */
> + return omap_hwmod_set_ioring_wakeup(oh, true);
> +}
> +
> +/**
> + * omap_hwmod_disable_ioring_wakeup - Clear wakeup flag for iopad.
> + * @oh: struct omap_hwmod *
> + *
> + * Traverse through dynamic pads, if pad is enabled then
> + * clear wakeup enable bit flag for the mux pin. Wakeup pad bit
> + * will be set during hwmod idle transistion.
> + * Return error if pads are not enabled or not available.
> + */
> +int omap_hwmod_disable_ioring_wakeup(struct omap_hwmod *oh)
> +{
> + /* Disable pad wakeup capability */
> + return omap_hwmod_set_ioring_wakeup(oh, false);
> +}
>
> /**
> * omap_hwmod_enable_wakeup - allow device to wake up the system
> @@ -2123,6 +2180,7 @@ int omap_hwmod_enable_wakeup(struct omap_hwmod *oh)
> v = oh->_sysc_cache;
> _enable_wakeup(oh, &v);
> _write_sysconfig(v, oh);
> + omap_hwmod_enable_ioring_wakeup(oh);
> spin_unlock_irqrestore(&oh->_lock, flags);
>
> return 0;
> @@ -2153,6 +2211,7 @@ int omap_hwmod_disable_wakeup(struct omap_hwmod *oh)
> v = oh->_sysc_cache;
> _disable_wakeup(oh, &v);
> _write_sysconfig(v, oh);
> + omap_hwmod_disable_ioring_wakeup(oh);
> spin_unlock_irqrestore(&oh->_lock, flags);
>
> return 0;
--
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: [REPOST PATCH 1/2 v4] OMAP2+: hwmod: Add API to enable IO ring wakeup.
On Monday 14 November 2011 05:14 PM, Shubhrajyoti wrote:
> On Monday 04 July 2011 10:25 AM, Govindraj.R wrote:
>> Add API to enable IO pad wakeup capability based on mux dynamic pad and
>> wake_up enable flag available from hwmod_mux initialization.
>>
>> Use the wakeup_enable flag and enable wakeup capability
>> for the given pads. Wakeup capability will be enabled/disabled
>> during hwmod idle transition based on whether wakeup_flag is
>> set or cleared.
>>
>> Map the enable/disable pad wakeup API's to hwmod_wakeup_enable/disable.
>>
>> Signed-off-by: Govindraj.R
>> ---
>> arch/arm/mach-omap2/omap_hwmod.c | 59
>> ++
>> 1 files changed, 59 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/omap_hwmod.c
>> b/arch/arm/mach-omap2/omap_hwmod.c
>> index 293fa6c..3b28e0a 100644
>> --- a/arch/arm/mach-omap2/omap_hwmod.c
>> +++ b/arch/arm/mach-omap2/omap_hwmod.c
>> @@ -1770,6 +1770,34 @@ static int __init omap_hwmod_setup_all(void)
>> core_initcall(omap_hwmod_setup_all);
>>
>> /**
>> + * omap_hwmod_set_ioring_wakeup - enable io pad wakeup flag.
>> + * @oh: struct omap_hwmod *
>> + * @set: bool value indicating to set or clear wakeup status.
>> + *
>> + * Set or Clear wakeup flag for the io_pad.
>> + */
>> +static int omap_hwmod_set_ioring_wakeup(struct omap_hwmod *oh, bool
>> set_wake)
>> +{
>> +struct omap_device_pad *pad;
>> +int ret = -EINVAL, j;
>> +
>> +if (oh->mux && oh->mux->enabled) {
>> +for (j = 0; j < oh->mux->nr_pads_dynamic; j++) {
>> +pad = oh->mux->pads_dynamic[j];
>> +if (pad->flags & OMAP_DEVICE_PAD_WAKEUP) {
>> +if (set_wake)
>> +pad->idle |= OMAP_WAKEUP_EN;
>> +else
>> +pad->idle &= ~OMAP_WAKEUP_EN;
> Will this not erase the other bits ?
> Should we read and erase only the wakeup bits.
> Am I missing something ?
My bad please ignore
>> +ret = 0;
>> +}
>> +}
>> +}
>> +
>> +return ret;
>> +}
>> +
>> +/**
>> * omap_hwmod_enable - enable an omap_hwmod
>> * @oh: struct omap_hwmod *
>> *
>> @@ -2097,6 +2125,35 @@ int omap_hwmod_del_initiator_dep(struct omap_hwmod
>> *oh,
>> {
>> return _del_initiator_dep(oh, init_oh);
>> }
>> +/**
>> + * omap_hwmod_enable_ioring_wakeup - Set wakeup flag for iopad.
>> + * @oh: struct omap_hwmod *
>> + *
>> + * Traverse through dynamic pads, if pad is enabled then
>> + * set wakeup enable bit flag for the mux pin. Wakeup pad bit
>> + * will be set during hwmod idle transistion.
>> + * Return error if pads are not enabled or not available.
>> + */
>> +int omap_hwmod_enable_ioring_wakeup(struct omap_hwmod *oh)
>> +{
>> +/* Enable pad wake-up capability */
>> +return omap_hwmod_set_ioring_wakeup(oh, true);
>> +}
>> +
>> +/**
>> + * omap_hwmod_disable_ioring_wakeup - Clear wakeup flag for iopad.
>> + * @oh: struct omap_hwmod *
>> + *
>> + * Traverse through dynamic pads, if pad is enabled then
>> + * clear wakeup enable bit flag for the mux pin. Wakeup pad bit
>> + * will be set during hwmod idle transistion.
>> + * Return error if pads are not enabled or not available.
>> + */
>> +int omap_hwmod_disable_ioring_wakeup(struct omap_hwmod *oh)
>> +{
>> +/* Disable pad wakeup capability */
>> +return omap_hwmod_set_ioring_wakeup(oh, false);
>> +}
>>
>> /**
>> * omap_hwmod_enable_wakeup - allow device to wake up the system
>> @@ -2123,6 +2180,7 @@ int omap_hwmod_enable_wakeup(struct omap_hwmod *oh)
>> v = oh->_sysc_cache;
>> _enable_wakeup(oh, &v);
>> _write_sysconfig(v, oh);
>> +omap_hwmod_enable_ioring_wakeup(oh);
>> spin_unlock_irqrestore(&oh->_lock, flags);
>>
>> return 0;
>> @@ -2153,6 +2211,7 @@ int omap_hwmod_disable_wakeup(struct omap_hwmod *oh)
>> v = oh->_sysc_cache;
>> _disable_wakeup(oh, &v);
>> _write_sysconfig(v, oh);
>> +omap_hwmod_disable_ioring_wakeup(oh);
>> spin_unlock_irqrestore(&oh->_lock, flags);
>>
>> return 0;
--
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] OMAP2+: UART: Make the SERIAL_OMAP depend on ARCH_OMAP2PLUS
On Tuesday 15 November 2011 02:36 PM, Russell King - ARM Linux wrote: > On Tue, Nov 15, 2011 at 11:57:40AM +0530, Shubhrajyoti D wrote: >> Making SERIAL_OMAP depend on ARCH_OMAP2PLUS instead of >> oring with ARCH2/3/4. >> >> Acked-by: Felipe Balbi >> Suggested-by: Sricharan R >> Signed-off-by: Shubhrajyoti D > There's another one: > > drivers/mtd/nand/Kconfig: depends on ARM && (ARCH_OMAP2 || ARCH_OMAP3 || > ARCH_OMAP4) > > And the 'ARM &&' is redundant. Will send a patch addressing the same. -- 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] MTD: nand: Making MTD_NAND_OMAP2 depend on ARCH_OMAP2PLUS
On Tuesday 15 November 2011 11:22 PM, Russell King - ARM Linux wrote: > On Tue, Nov 15, 2011 at 03:52:36PM +0530, Shubhrajyoti D wrote: >> Making MTD_NAND_OMAP2 depend on ARCH_OMAP2PLUS instead of >> oring with ARCH2/3/4. >> >> Reported-by: Russell King > Thanks, but please make this rmk+ker...@arm.linux.org.uk. yes , will correct it. >> Signed-off-by: Shubhrajyoti D >> --- >> drivers/mtd/nand/Kconfig |2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig >> index cce7b70..b68dd5e 100644 >> --- a/drivers/mtd/nand/Kconfig >> +++ b/drivers/mtd/nand/Kconfig >> @@ -110,7 +110,7 @@ config MTD_NAND_AMS_DELTA >> >> config MTD_NAND_OMAP2 >> tristate "NAND Flash device on OMAP2, OMAP3 and OMAP4" >> -depends on ARM && (ARCH_OMAP2 || ARCH_OMAP3 || ARCH_OMAP4) >> +depends on ARCH_OMAP2PLUS >> help >>Support for NAND flash on Texas Instruments OMAP2, OMAP3 and OMAP4 >>platforms. >> -- >> 1.7.1 >> >> >> ___ >> linux-arm-kernel mailing list >> linux-arm-ker...@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- 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: I2C: Fix the interrupt clearing in OMAP4
On Tuesday 22 November 2011 12:05 AM, Kevin Hilman wrote: > Shubhrajyoti D writes: > >> For OMAP4 Interrupt enable register is a legacy register. > I don't see anything in the docs mentioning this is legacy. In fact, > that register is used extensivly throughout the driver, even for OMAP4. > > I think the CLR/SET registers were added to aid atomically > setting/clearing specific interrupts, but when disabling all, I don't > see why I2C_IE cannot be used. > > For that reason, any reason why the 4430-specific check cannot simply be > removed to fix this interrupt clearing bug? I think IE could be used as well since the CLR is there I thought of using it. >> To clear the interrupts we were writing 0 to it. > This patch still writes 0 to it, so I'm not seeing the point of this comment. > >> However on OMAP4 we were writing 1 to IRQENABLE_CLR which clears only >> the arbitration lost interrupt. The patch intends to fix the same by >> writing 1 to all the bits. > This is the bug, and should come first in the changelog so readers know > what the problem is. > Yes will make this the first thing . >> Signed-off-by: Shubhrajyoti D > I believe this patch was originally from a fix by Vikram Pandita. Even > if you've now changed the implementation, please credit the original > author (and Cc them) in the changelog. It's common practice (and common > courtesy) to say something like "Based on an a patch originally from > Author ". Thanks. Yes missed to copy the second version will update. > Also, this patch doesn't apply to mainline or linux-omap master. Can > you please update? It is was based on linus tree. Will update. > 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 v3] OMAP: I2C: Fix the interrupt clearing in OMAP4
On Tuesday 22 November 2011 11:31 AM, Shubhrajyoti D wrote:
> However on OMAP4 we were writing 1 to IRQENABLE_CLR which clears only
> the arbitration lost interrupt. The patch intends to fix the same by writing
> 0 to the IE register.
Please ignore this patch I will send another one in a while.
> Signed-off-by: Vikram Pandita
> Signed-off-by: Shubhrajyoti D
> ---
> drivers/i2c/busses/i2c-omap.c |6 ++
> 1 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index 2dfb631..4220949 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -308,10 +308,8 @@ static void omap_i2c_idle(struct omap_i2c_dev *dev)
> pdata = pdev->dev.platform_data;
>
> dev->iestate = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
> - if (dev->rev >= OMAP_I2C_REV_ON_4430)
> - omap_i2c_write_reg(dev, OMAP_I2C_IRQENABLE_CLR, 1);
> - else
> - omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, 0);
> +
> + omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, 0);
>
> if (dev->rev < OMAP_I2C_REV_2) {
> iv = omap_i2c_read_reg(dev, OMAP_I2C_IV_REG); /* Read clears */
--
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: [PATCHv7 2/3] OMAP: I2C: Remove the reset in the init path
On Saturday 03 December 2011 03:07 AM, Jon Hunter wrote:
> Hi Shubhrajyoti,
>
> On 12/2/2011 3:21, Shubhrajyoti D wrote:
>> - The reset in the driver at init is not needed anymore as the
>> hwmod framework takes care of reseting it.
>> - Reset is removed from omap_i2c_init, which was called
>> not only during probe, but also after time out and error handling.
>> device_reset were added in those places to effect the reset.
>> - Earlier the hwmod SYSC settings were over-written in the driver.
>> Removing the same and letting the hwmod take care of the settings.
>> - Clean up the SYSS_RESETDONE_MASK macro as it is no longer needed.
>> - Clean up the SYSCONFIG SYSC bit defination macros.
>> - Fix the typos in wakeup.
>>
>> Signed-off-by: Shubhrajyoti D
>> ---
>> drivers/i2c/busses/i2c-omap.c | 82
>> +++--
>> 1 files changed, 22 insertions(+), 60 deletions(-)
>>
>> diff --git a/drivers/i2c/busses/i2c-omap.c
>> b/drivers/i2c/busses/i2c-omap.c
>> index fa23faa..beff9f3 100644
>> --- a/drivers/i2c/busses/i2c-omap.c
>> +++ b/drivers/i2c/busses/i2c-omap.c
>> @@ -155,19 +155,6 @@ enum {
>> #define OMAP_I2C_SYSTEST_SDA_O(1<< 0)/* SDA line drive
>> out */
>> #endif
>>
>> -/* OCP_SYSSTATUS bit definitions */
>> -#define SYSS_RESETDONE_MASK(1<< 0)
>> -
>> -/* OCP_SYSCONFIG bit definitions */
>> -#define SYSC_CLOCKACTIVITY_MASK(0x3<< 8)
>> -#define SYSC_SIDLEMODE_MASK(0x3<< 3)
>> -#define SYSC_ENAWAKEUP_MASK(1<< 2)
>> -#define SYSC_SOFTRESET_MASK(1<< 1)
>> -#define SYSC_AUTOIDLE_MASK(1<< 0)
>> -
>> -#define SYSC_IDLEMODE_SMART0x2
>> -#define SYSC_CLOCKACTIVITY_FCLK0x2
>> -
>> /* Errata definitions */
>> #define I2C_OMAP_ERRATA_I207(1<< 0)
>> #define I2C_OMAP3_1P153(1<< 1)
>> @@ -182,6 +169,7 @@ struct omap_i2c_dev {
>> u32latency;/* maximum mpu wkup latency */
>> void(*set_mpu_wkup_lat)(struct device *dev,
>> long latency);
>> +int(*device_reset)(struct device *dev);
>> u32speed;/* Speed of bus in Khz */
>> u16cmd_err;
>> u8*buf;
>> @@ -317,60 +305,23 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
>> u16 psc = 0, scll = 0, sclh = 0, buf = 0;
>> u16 fsscll = 0, fssclh = 0, hsscll = 0, hssclh = 0;
>> unsigned long fclk_rate = 1200;
>> -unsigned long timeout;
>> unsigned long internal_clk = 0;
>> struct clk *fclk;
>> struct omap_i2c_bus_platform_data *pdata;
>>
>> pdata = dev->dev->platform_data;
>>
>> -if (dev->rev>= OMAP_I2C_OMAP1_REV_2) {
>> -/* Disable I2C controller before soft reset */
>> -omap_i2c_write_reg(dev, OMAP_I2C_CON_REG,
>> -omap_i2c_read_reg(dev, OMAP_I2C_CON_REG)&
>> -~(OMAP_I2C_CON_EN));
>> -
>> -omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG,
>> SYSC_SOFTRESET_MASK);
>> -/* For some reason we need to set the EN bit before the
>> - * reset done bit gets set. */
>> -timeout = jiffies + OMAP_I2C_TIMEOUT;
>> -omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
>> -while (!(omap_i2c_read_reg(dev, OMAP_I2C_SYSS_REG)&
>> - SYSS_RESETDONE_MASK)) {
>> -if (time_after(jiffies, timeout)) {
>> -dev_warn(dev->dev, "timeout waiting "
>> -"for controller reset\n");
>> -return -ETIMEDOUT;
>> -}
>> -msleep(1);
>> -}
>> -
>> -/* SYSC register is cleared by the reset; rewrite it */
>> -if (dev->rev == OMAP_I2C_REV_ON_2430) {
>> -
>> -omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG,
>> - SYSC_AUTOIDLE_MASK);
>> -
>> -} else if (dev->rev>= OMAP_I2C_REV_ON_3430) {
>> -dev->syscstate = SYSC_AUTOIDLE_MASK;
>> -dev->syscstate |= SYSC_ENAWAKEUP_MASK;
>> -dev->syscstate |= (SYSC_IDLEMODE_SMART<<
>> - __ffs(SYSC_SIDLEMODE_MASK));
>> -dev->syscstate |= (SYSC_CLOCKACTIVITY_FCLK<<
>> - __ffs(SYSC_CLOCKACTIVIT
Re: [PATCH] i2c_omap: correct OMAP_I2C_SYSC_REG offset
On Friday 09 December 2011 01:01 AM, Jon Hunter wrote:
> Hi Kevin,
>
> On 12/8/2011 12:12, Kevin Hilman wrote:
>> Alexander Aring writes:
>>
>>> Correct OMAP_I2C_SYSC_REG offset in omap4 register map.
>>> Offset 0x20 is reserved and OMAP_I2C_SYSC_REG has 0x10 as offset.
>>>
>>> Signed-off-by: Alexander Aring
>>
>> Thanks for the patch!
>>
>> A different approach to fix this is being done by Shubhrajyoti[1] as
>> part of his reset series.
>>
>> However, I think we should probably apply this patch for v3.2 and also
>> send to the stable kernel for v3.0& v3.1.
>>
>> Shubhrajyoti/Jon, any objections to me queuing this fix for v3.2 (and
>> stable.) It would just mean rebasing your other fixes and cleanup
>> series on top of this.
>
> I have no issue with that and I am in favour of getting the fix in now.
I too have no issues.
>
> Cheers
> Jon
>
>>
>>> ---
>>> drivers/i2c/busses/i2c-omap.c |2 +-
>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/drivers/i2c/busses/i2c-omap.c
>>> b/drivers/i2c/busses/i2c-omap.c
>>> index a43d002..fc3bb37 100644
>>> --- a/drivers/i2c/busses/i2c-omap.c
>>> +++ b/drivers/i2c/busses/i2c-omap.c
>>> @@ -235,7 +235,7 @@ static const u8 reg_map_ip_v2[] = {
>>> [OMAP_I2C_BUF_REG] = 0x94,
>>> [OMAP_I2C_CNT_REG] = 0x98,
>>> [OMAP_I2C_DATA_REG] = 0x9c,
>>> -[OMAP_I2C_SYSC_REG] = 0x20,
>>> +[OMAP_I2C_SYSC_REG] = 0x10,
>>> [OMAP_I2C_CON_REG] = 0xa4,
>>> [OMAP_I2C_OA_REG] = 0xa8,
>>> [OMAP_I2C_SA_REG] = 0xac,
--
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: [PATCHv7 1/3] OMAP: I2C: Reset support
On Friday 09 December 2011 06:45 AM, Paul Walmsley wrote:
> Hi
>
> some comments
>
> On Fri, 2 Dec 2011, Shubhrajyoti D wrote:
>
>> Under some error conditions the i2c driver may do a reset.
>> Adding a reset field and support in the device-specific code.
>>
>> Signed-off-by: Shubhrajyoti D
>> ---
>> arch/arm/plat-omap/i2c.c | 18 ++
>> include/linux/i2c-omap.h |1 +
>> 2 files changed, 19 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
>> index db071bc..883229c 100644
>> --- a/arch/arm/plat-omap/i2c.c
>> +++ b/arch/arm/plat-omap/i2c.c
>> @@ -74,6 +74,22 @@ static struct omap_i2c_bus_platform_data
>> i2c_pdata[OMAP_I2C_MAX_CONTROLLERS];
>> static struct platform_device omap_i2c_devices[] = {
>> I2C_DEV_BUILDER(1, i2c_resources[0], &i2c_pdata[0]),
>> };
>> +/**
>> + * omap2_i2c_reset - reset the omap i2c module.
>> + * @dev: struct device*
>> + */
>> +
>> +static int omap2_i2c_reset(struct device *dev)
>> +{
>> +int r = 0;
>> +struct platform_device *pdev = to_platform_device(dev);
>> +struct omap_device *odev = to_omap_device(pdev);
>> +struct omap_hwmod *oh;
>> +
>> +oh = odev->hwmods[0];
>> +r = omap_hwmod_reset(oh);
>> +return r;
>> +}
> This function should go into arch/arm/plat-omap/omap_device.c, and it
agree
> should be renamed to omap_device_reset(), since it's not I2C specific.
> Also it shouldn't assume that there's only one hwmod - it should iterate
> over all of the hwmods in the omap_device and call omap_hwmod_reset() on
> each.
Yes agree will fix in the next version.
>>
>> #define OMAP_I2C_CMDLINE_SETUP (BIT(31))
>>
>> @@ -179,6 +195,8 @@ static inline int omap2_i2c_add_bus(int bus_id)
>> */
>> if (cpu_is_omap34xx())
>> pdata->set_mpu_wkup_lat = omap_pm_set_max_mpu_wakeup_lat_compat;
>> +
>> +pdata->device_reset = omap2_i2c_reset;
> omap_device_reset
>
>> pdev = omap_device_build(name, bus_id, oh, pdata,
>> sizeof(struct omap_i2c_bus_platform_data),
>> NULL, 0, 0);
>> diff --git a/include/linux/i2c-omap.h b/include/linux/i2c-omap.h
>> index 92a0dc7..fd38249 100644
>> --- a/include/linux/i2c-omap.h
>> +++ b/include/linux/i2c-omap.h
>> @@ -35,6 +35,7 @@ struct omap_i2c_bus_platform_data {
>> u32 rev;
>> u32 flags;
>> void(*set_mpu_wkup_lat)(struct device *dev, long set);
>> +int (*device_reset) (struct device *dev);
>> };
>>
>> #endif
>> --
>> 1.7.1
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
> - 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: [PATCHv8 3/5] OMAP: I2C: Reset support
Hi Benoit, On Friday 16 December 2011 02:21 PM, Cousson, Benoit wrote: > Hi Shubhro, > > On 12/13/2011 11:55 AM, Shubhrajyoti D wrote: >> Under some error conditions the i2c driver may do a reset. >> Adding a reset field and support in the device-specific code to aid >> error-recovery. >> >> Signed-off-by: Shubhrajyoti D >> --- >> arch/arm/plat-omap/i2c.c |2 ++ >> include/linux/i2c-omap.h |1 + >> 2 files changed, 3 insertions(+), 0 deletions(-) >> >> diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c >> index db071bc..6cddde2 100644 >> --- a/arch/arm/plat-omap/i2c.c >> +++ b/arch/arm/plat-omap/i2c.c >> @@ -179,6 +179,8 @@ static inline int omap2_i2c_add_bus(int bus_id) >>*/ >> if (cpu_is_omap34xx()) >> pdata->set_mpu_wkup_lat = >> omap_pm_set_max_mpu_wakeup_lat_compat; >> + >> +pdata->device_reset = omap_device_reset; > > We should avoid introducing any new pdata function pointers since we > are in the process of removing them for DT support. However if the driver has to do a reset due to some error what is the recommended way? Currently we used to access the SYSC directly I am removing the same and introducing this function pointer. > > Regards, > Benoit -- 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: [PATCHv8 4/5] OMAP: I2C: Remove the reset in the init path
Ben, On Friday 16 December 2011 02:10 PM, Paul Walmsley wrote: > Hi > > On Tue, 13 Dec 2011, Shubhrajyoti D wrote: > >> - The reset in the driver at init is not needed anymore as the >>hwmod framework takes care of reseting it. >> - Reset is removed from omap_i2c_init, which was called >>not only during probe, but also after time out and error handling. >>device_reset were added in those places to effect the reset. >> - Earlier the hwmod SYSC settings were over-written in the driver. >>Removing the same and letting the hwmod take care of the settings. >> - Clean up the SYSS_RESETDONE_MASK macro as it is no longer needed. >> - Clean up the SYSCONFIG SYSC bit definition macros. >> - Fix the typos in wakeup. >> >> Signed-off-by: Shubhrajyoti D >> --- >> drivers/i2c/busses/i2c-omap.c | 83 >> +++- >> 1 files changed, 23 insertions(+), 60 deletions(-) > This patch either needs to be acked by Ben with a note that it's okay for > us to merge through the OMAP tree, or needs to be merged by Ben during the > 3.4 merge window, after patches 1-3 have reached the mainline tree. I agree. Ben do you have any comments . > > - 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: [GIT PULL] ARM: OMAP: I2C: prepare to use hwmod reset in driver
On Saturday 17 December 2011 05:54 AM, Tony Lindgren wrote: > * Paul Walmsley [111216 12:27]: >> Hi >> >> On Fri, 16 Dec 2011, Tony Lindgren wrote: >> >>> * Paul Walmsley [111216 11:45]: >>>> On Fri, 16 Dec 2011, Tony Lindgren wrote: >>>> >>>>> * Paul Walmsley [111216 01:24]: >>>>> >>>>>> Shubhrajyoti D (2): >>>>>> ARM: OMAP: omap_device: add omap_device_reset to reset all the >>>>>> hwmods in the device >>>>>> ARM: OMAP: I2C: Reset support >>>>>> >>>>> Can you please update shi to leave out the extra callback >>>>> function int (*device_reset) (struct device *dev) as I'd >>>>> rather see that happen with pm_runtime calls? >>>> What PM runtime call is used to reset a device? >>> Hmm how about pm_runtime_disable? Or do we need a new >>> call for reset? > Meanwhile as Paul pointed out, we still need the device_reset > pointer, so pulling in this series into i2c branch. > >> Looking at the last few hunks of: >> >> http://marc.info/?l=linux-omap&m=132377389204328&w=2 >> >> it appears to me that the driver needs to reset the device while it's >> still active & powered on, etc. >> >> Shubhrajyoti, care to comment further? The driver does a reset in the error path. Since we are not supposed to access the sysc reg the function is needed. >> >> - 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: [GIT PULL] ARM: OMAP: I2C: prepare to use hwmod reset in driver
On Monday 19 December 2011 10:02 PM, Cousson, Benoit wrote: > Hi Shubhro, > > On 12/18/2011 9:01 AM, Shubhrajyoti wrote: > > [...] > >> The driver does a reset in the error path. >> Since we are not supposed to access the sysc reg the function is needed. > > I'm just wondering what will happen to the driver if this callback is > not provided during the device creation? This is what will happen > during DT boot for example? > > Is it a mandatory function? This is used in the recovery mechanism in case of errors like some one holding the bus and not releasing it etc. > > Thanks, > Benoit -- 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 02/10] i2c: OMAP: Add DT support for i2c controller
Since it touches the driver file
+linux-i2c
On Friday 09 December 2011 07:32 PM, Benoit Cousson wrote:
> Add initial DT support to retrieve the frequency using a
> DT attribute instead of the pdata pointer if of_node exist.
>
> Add documentation for omap i2c controller binding.
>
> Based on original patches from Manju and Grant.
>
> Signed-off-by: Benoit Cousson
> Cc: Ben Dooks
> ---
> Documentation/devicetree/bindings/i2c/omap-i2c.txt | 42
> drivers/i2c/busses/i2c-omap.c | 100
> +---
> 2 files changed, 107 insertions(+), 35 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/i2c/omap-i2c.txt
>
> diff --git a/Documentation/devicetree/bindings/i2c/omap-i2c.txt
> b/Documentation/devicetree/bindings/i2c/omap-i2c.txt
> new file mode 100644
> index 000..d259a17
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i2c/omap-i2c.txt
> @@ -0,0 +1,42 @@
> +I2C for OMAP platforms
> +
> +Required properties :
> +- compatible : Must be "ti,omap3-i2c" or "ti,omap4-i2c"
> +- ti,hwmods : Must be "i2c", n being the instance number (1-based)
> +- #address-cells = <1>;
> +- #size-cells = <0>;
> +
> +Recommended properties :
> +- clock-frequency : Desired I2C bus clock frequency in Hz. Otherwise
> + the default 100 kHz frequency will be used.
> +
> +Optional properties:
> +- Child nodes conforming to i2c bus binding
> +- ti,flags : u32: settings or errata relative to the i2c
> +0x1: OMAP_I2C_FLAG_NO_FIFO
> +0x2: OMAP_I2C_FLAG_SIMPLE_CLOCK
> +0x4: OMAP_I2C_FLAG_16BIT_DATA_REG
> +0x8: OMAP_I2C_FLAG_RESET_REGS_POSTIDLE
> +0x10: OMAP_I2C_FLAG_APPLY_ERRATA_I207
> +0x20: OMAP_I2C_FLAG_ALWAYS_ARMXOR_CLK
> +0x40: OMAP_I2C_FLAG_FORCE_19200_INT_CLK
> + Valid for ti,omap3-i2c only:
> +0x80: OMAP_I2C_FLAG_BUS_SHIFT_1: 8 bits registers
> +0x100: OMAP_I2C_FLAG_BUS_SHIFT_2: 16 bits registers
> +
> +Note: Current implementation will fetch base address, irq and dma
> +from omap hwmod data base during device registration.
> +Future plan is to migrate hwmod data base contents into device tree
> +blob so that, all the required data will be used from device tree dts
> +file.
> +
> +Examples :
> +
> +i2c1: i2c@0 {
> +compatible = "ti,omap3-i2c";
> +#address-cells = <1>;
> +#size-cells = <0>;
> +ti,hwmods = "i2c1";
> +clock-frequency = <40>;
> +ti,flags = <0x118>;
> +};
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index a43d002..b4a8eee 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -37,6 +37,8 @@
> #include
> #include
> #include
> +#include
> +#include
> #include
> #include
> #include
> @@ -182,7 +184,9 @@ struct omap_i2c_dev {
> u32 latency;/* maximum mpu wkup latency */
> void(*set_mpu_wkup_lat)(struct device *dev,
> long latency);
> - u32 speed; /* Speed of bus in Khz */
> + u32 speed; /* Speed of bus in kHz */
> + u32 dtrev; /* extra revision from DT */
> + u32 flags;
> u16 cmd_err;
> u8 *buf;
> u8 *regs;
> @@ -266,11 +270,7 @@ static inline u16 omap_i2c_read_reg(struct omap_i2c_dev
> *i2c_dev, int reg)
>
> static void omap_i2c_unidle(struct omap_i2c_dev *dev)
> {
> - struct omap_i2c_bus_platform_data *pdata;
> -
> - pdata = dev->dev->platform_data;
> -
> - if (pdata->flags & OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
> + if (dev->flags & OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
> omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
> omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, dev->pscstate);
> omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, dev->scllstate);
> @@ -291,13 +291,10 @@ static void omap_i2c_unidle(struct omap_i2c_dev *dev)
>
> static void omap_i2c_idle(struct omap_i2c_dev *dev)
> {
> - struct omap_i2c_bus_platform_data *pdata;
> u16 iv;
>
> - pdata = dev->dev->platform_data;
> -
> dev->iestate = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
> - if (pdata->rev == OMAP_I2C_IP_VERSION_2)
> + if (dev->dtrev == OMAP_I2C_IP_VERSION_2)
> omap_i2c_write_reg(dev, OMAP_I2C_IP_V2_IRQENABLE_CLR, 1);
> else
> omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, 0);
> @@ -320,9 +317,6 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
> unsigned long timeout;
> unsigned long internal_clk = 0;
> struct clk *fclk;
> - struct omap_i2c_bus_platform_data *pdata;
> -
> - pdata = dev->dev->platform_data;
>
> if (dev->rev >= OMAP_I2C_OMAP1_REV_2) {
> /* Disable I2C controller before soft reset */
> @@ -373,7 +367,7 @@ static int omap_i2c_init(struct omap_i2c_dev
Re: [PATCH v2 3/3] OMAPDSS: HDMI: HPD support added to HDMI driver
Hi Mythri,
On Friday 06 January 2012 06:14 PM, mythr...@ti.com wrote:
> From: Mythri P K
>
> GPIO based handling of connect/disconnect of the HDMI cable
> (Hot-plug detect)is added to the HDMI driver.
>
> Signed-off-by: Mythri P K
> ---
> drivers/video/omap2/dss/dss_features.c |1 +
> drivers/video/omap2/dss/hdmi.c | 49
>
> 2 files changed, 50 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/video/omap2/dss/dss_features.c
> b/drivers/video/omap2/dss/dss_features.c
> index 544b172..ef3f666 100644
> --- a/drivers/video/omap2/dss/dss_features.c
> +++ b/drivers/video/omap2/dss/dss_features.c
> @@ -477,6 +477,7 @@ static const struct ti_hdmi_ip_ops omap4_hdmi_functions =
> {
> .audio_enable = ti_hdmi_4xxx_wp_audio_enable,
> #endif
> .configure_range= ti_hdmi_4xxx_configure_range,
> + .notify_hpd = ti_hdmi_4xxx_notify_hpd,
>
> };
>
> diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
> index 29de79f..4c3110d 100644
> --- a/drivers/video/omap2/dss/hdmi.c
> +++ b/drivers/video/omap2/dss/hdmi.c
> @@ -66,6 +66,9 @@ static struct {
> struct omap_display_platform_data *pdata;
> struct platform_device *pdev;
> struct hdmi_ip_data ip_data;
> + struct omap_dss_device *dssdev;
> +
> + bool hpd;
>
> struct clk *sys_clk;
> } hdmi;
> @@ -461,6 +464,29 @@ void hdmi_dump_regs(struct seq_file *s)
> mutex_unlock(&hdmi.lock);
> }
>
> +static int hdmi_get_current_hpd(void)
> +{
> + return gpio_get_value(hdmi.dssdev->hpd_gpio);
> +}
> +
> +static irqreturn_t hpd_enable_handler(int irq, void *ptr)
> +{
> + DSSDBG("hpd enable %d\n", hdmi.hpd);
> +
> + hdmi.ip_data.ops->notify_hpd(&hdmi.ip_data, hdmi.hpd);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static irqreturn_t hpd_irq_handler(int irq, void *ptr)
> +{
> + if (hdmi.dssdev->state == OMAP_DSS_DISPLAY_ACTIVE) {
> + hdmi.hpd = hdmi_get_current_hpd();
> + return IRQ_WAKE_THREAD;
> + }
> + return IRQ_HANDLED;
> +}
> +
> int omapdss_hdmi_read_edid(u8 *buf, int len)
> {
> int r;
> @@ -782,11 +808,22 @@ static int omapdss_hdmihw_probe(struct platform_device
> *pdev)
> {
> struct resource *hdmi_mem;
> int r;
> + struct omap_dss_board_info *board_data;
>
> hdmi.pdata = pdev->dev.platform_data;
> hdmi.pdev = pdev;
>
> mutex_init(&hdmi.lock);
> + /* save reference to HDMI device */
> + board_data = hdmi.pdata->board_data;
> + for (r = 0; r < board_data->num_devices; r++) {
> + if (board_data->devices[r]->type == OMAP_DISPLAY_TYPE_HDMI)
> + hdmi.dssdev = board_data->devices[r];
> + }
> + if (!hdmi.dssdev) {
> + DSSERR("can't get HDMI device\n");
> + return -EINVAL;
> + }
>
> hdmi_mem = platform_get_resource(hdmi.pdev, IORESOURCE_MEM, 0);
> if (!hdmi_mem) {
> @@ -810,6 +847,16 @@ static int omapdss_hdmihw_probe(struct platform_device
> *pdev)
>
> pm_runtime_enable(&pdev->dev);
>
> + r = request_threaded_irq(gpio_to_irq(hdmi.dssdev->hpd_gpio),
> + hpd_irq_handler, hpd_enable_handler,
> + IRQF_DISABLED | IRQF_TRIGGER_RISING |
Why is IRQF_DISABLED needed?
> + IRQF_TRIGGER_FALLING, "hpd", NULL);
> + if (r < 0) {
> + pr_err("hdmi: request_irq %d failed\n",
> + gpio_to_irq(hdmi.dssdev->hpd_gpio));
> + return -EINVAL;
Could we return the error from request_threaded_irq instead of masking
with EINVAL.
> + }
> +
> hdmi.ip_data.core_sys_offset = HDMI_CORE_SYS;
> hdmi.ip_data.core_av_offset = HDMI_CORE_AV;
> hdmi.ip_data.pll_offset = HDMI_PLLCTRL;
> @@ -840,6 +887,8 @@ static int omapdss_hdmihw_remove(struct platform_device
> *pdev)
> snd_soc_unregister_codec(&pdev->dev);
> #endif
>
> + free_irq(gpio_to_irq(hdmi.dssdev->hpd_gpio), hpd_irq_handler);
> +
> pm_runtime_disable(&pdev->dev);
>
> hdmi_put_clocks();
--
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: [PATCHv8 4/5] OMAP: I2C: Remove the reset in the init path
On Tuesday 10 January 2012 08:56 PM, Kevin Hilman wrote: > "Datta, Shubhrajyoti" writes: > >> On Tue, Jan 10, 2012 at 11:53 AM, Datta, Shubhrajyoti >> wrote: >>> >>> >>> On Fri, Dec 16, 2011 at 2:29 PM, Shubhrajyoti wrote: >>>> Ben, >>>> >>>> On Friday 16 December 2011 02:10 PM, Paul Walmsley wrote: >>>>> Hi >>>>> >>>>> On Tue, 13 Dec 2011, Shubhrajyoti D wrote: >>>>> >>>>>> - The reset in the driver at init is not needed anymore as the >>>>>>hwmod framework takes care of reseting it. >>>>>> - Reset is removed from omap_i2c_init, which was called >>>>>>not only during probe, but also after time out and error handling. >>>>>>device_reset were added in those places to effect the reset. >>>>>> - Earlier the hwmod SYSC settings were over-written in the driver. >>>>>>Removing the same and letting the hwmod take care of the settings. >>>>>> - Clean up the SYSS_RESETDONE_MASK macro as it is no longer needed. >>>>>> - Clean up the SYSCONFIG SYSC bit definition macros. >>>>>> - Fix the typos in wakeup. >>>>>> >>>>>> Signed-off-by: Shubhrajyoti D >>>>>> --- >>>>>> drivers/i2c/busses/i2c-omap.c | 83 >>>>>> +++- >>>>>> 1 files changed, 23 insertions(+), 60 deletions(-) >>>>> This patch either needs to be acked by Ben with a note that it's okay for >>>>> us to merge through the OMAP tree, or needs to be merged by Ben during the >>>>> 3.4 merge window, after patches 1-3 have reached the mainline tree. >>>> I agree. >>>> Ben do you have any comments . >>> >> If there are no further comments can this be merged also ? > As Benoit mentioned earlier, the addition of new pdata fields will cause > problems with the DT support already queued for v3.3. > > This series should be reworked on top of the DT support which Ben has > now queued for v3.3 (my branch: for_3.3/i2c/misc) Yes will rework 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: [PATCHv8 4/5] OMAP: I2C: Remove the reset in the init path
On Wednesday 11 January 2012 06:59 PM, Paul Walmsley wrote: > On Wed, 11 Jan 2012, Shubhrajyoti wrote: > >> On Tuesday 10 January 2012 08:56 PM, Kevin Hilman wrote: >>> "Datta, Shubhrajyoti" writes: >>> >>>> On Tue, Jan 10, 2012 at 11:53 AM, Datta, Shubhrajyoti >>>> wrote: >>>>> On Fri, Dec 16, 2011 at 2:29 PM, Shubhrajyoti wrote: >>>>>> On Friday 16 December 2011 02:10 PM, Paul Walmsley wrote: >>>>>> >>>>>>> This patch either needs to be acked by Ben with a note that it's okay >>>>>>> for >>>>>>> us to merge through the OMAP tree, or needs to be merged by Ben during >>>>>>> the >>>>>>> 3.4 merge window, after patches 1-3 have reached the mainline tree. >>>>>> I agree. >>>>>> Ben do you have any comments . >>>> If there are no further comments can this be merged also ? >>> As Benoit mentioned earlier, the addition of new pdata fields will cause >>> problems with the DT support already queued for v3.3. >>> >>> This series should be reworked on top of the DT support which Ben has >>> now queued for v3.3 (my branch: for_3.3/i2c/misc) >> Yes will rework it. > Depending on what you plan to do, you'll probably need to coordinate this > with Tony also. He's already pulled some of the patches from this series > into his i2c branch. > > The real question is how you plan to handle the device reset function, > given that the driver should compile on a non-OMAP build (meaning that you > can't call omap_device*() functions from the driver directly), nor should > the driver touch the SYSCONFIG register directly. Paul I thought through it myself not very clear. - One way is to find some way for the dt to pass function pointer. Or maybe a flag that activates a static function / hwmod func. Will give this a little more thought and get back. I have not any answer right now. > > - 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 RFC] OMAP: I2C: Fix the mismatch of pm_runtime enable and disable
On Wednesday 11 January 2012 07:29 PM, Grazvydas Ignotas wrote: > On Wed, Jan 11, 2012 at 3:21 PM, Shubhrajyoti D wrote: >> Currently the i2c driver calls the pm_runtime_enable and never >> the disable. This may cause a warning when pm_runtime_enable >> checks for the count match.Attempting to fix the same by calling >> pm_runtime_disable in the error and the remove path. > I remember seeing Felipe doing the reverse to musb here: > http://marc.info/?l=linux-omap&m=132432610700952&w=2 > so I'm confused here. Strange however I see many drivers doing the same in the kernel on greping . Besides I expect a warn to come up. Felipe could you explain the issue? >> Cc: Kevin Hilman >> Cc: Rajendra Nayak >> Signed-off-by: Shubhrajyoti D >> --- >> drivers/i2c/busses/i2c-omap.c |2 ++ >> 1 files changed, 2 insertions(+), 0 deletions(-) >> >> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c >> index 12d402c..abc7b5b 100644 >> --- a/drivers/i2c/busses/i2c-omap.c >> +++ b/drivers/i2c/busses/i2c-omap.c >> @@ -1070,6 +1070,7 @@ err_unuse_clocks: >>omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0); >>pm_runtime_put(dev->dev); >>iounmap(dev->base); >> + pm_runtime_disable(&pdev->dev); >> err_free_mem: >>platform_set_drvdata(pdev, NULL); >>kfree(dev); >> @@ -1085,6 +1086,7 @@ omap_i2c_remove(struct platform_device *pdev) >>struct omap_i2c_dev *dev = platform_get_drvdata(pdev); >>struct resource *mem; >> >> + pm_runtime_disable(&pdev->dev); >>platform_set_drvdata(pdev, NULL); >> >>free_irq(dev->irq, dev); >> -- >> 1.7.1 >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-omap" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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] I2C: OMAP: Recover from Bus Busy condition
On Wednesday 11 January 2012 11:12 PM, Shubhrajyoti D wrote:
> From: Vikram Pandita
I am reworking the patch on the latest changes.
Please ignore this.
> In case a peripheral is driving SDA bus low (ie. a start condition), provide
> a constant clock output using the test mode of the OMAP I2C controller to
> try and clear the bus. Soft reset I2C controller after attempting the bus
> clear
> to ensure that controller is in a good state.
>
> Based upon Vikram Pandita's patch from TI Android 3.0 kernel and modified for
> mainline by Jon Hunter. A couple differences from the original patch ...
> 1. Add a new function for bus clear
> 2. Ensure that the CON.I2C_EN bit is set when using the SYSTEST feature to
>output a permanent clock. This bit needs to be set and tpyically it would
>be set by the unidle function but this is not the case for all OMAP
>generations.
> 3. Program the SYSTEST setting only the bits we care about. However, restore
>SYSTEST registers to there original state as some OMAP generations do not
>implement perform a soft-reset.
> 4. Clear the CON register after performing the bus clear, so when we call the
>init function the controller is disabled and the init function will
>re-enable later.
>
> Cc: Kevin Hilman
> Signed-off-by: Vikram Pandita
> Signed-off-by: Jon Hunter
> Signed-off-by: Shubhrajyoti D
> ---
> Original patch can be found here:
> http://git.omapzoom.org/?p=kernel/omap.git;a=commit;h=a2ab04192ba25e60f95ba1ff3af5601a2d7b5bd1
> applies on Kevin's for_3.3/i2c/misc
>
> drivers/i2c/busses/i2c-omap.c | 32 +---
> 1 files changed, 29 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index f713eac..6d59bc6 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -147,16 +147,15 @@ enum {
> #define OMAP_I2C_SCLH_HSSCLH 8
>
> /* I2C System Test Register (OMAP_I2C_SYSTEST): */
> -#ifdef DEBUG
> #define OMAP_I2C_SYSTEST_ST_EN (1 << 15) /* System test
> enable */
> #define OMAP_I2C_SYSTEST_FREE(1 << 14) /* Free running
> mode */
> #define OMAP_I2C_SYSTEST_TMODE_MASK (3 << 12) /* Test mode select */
> -#define OMAP_I2C_SYSTEST_TMODE_SHIFT (12)/* Test mode select */
> +#define OMAP_I2C_SYSTEST_TMODE_TEST (2 << 12) /* Test mode select */
> +#define OMAP_I2C_SYSTEST_TMODE_LOOP (3 << 12) /* Test mode select */
> #define OMAP_I2C_SYSTEST_SCL_I (1 << 3)/* SCL line
> sense in */
> #define OMAP_I2C_SYSTEST_SCL_O (1 << 2)/* SCL line
> drive out */
> #define OMAP_I2C_SYSTEST_SDA_I (1 << 1)/* SDA line
> sense in */
> #define OMAP_I2C_SYSTEST_SDA_O (1 << 0)/* SDA line
> drive out */
> -#endif
>
> /* OCP_SYSSTATUS bit definitions */
> #define SYSS_RESETDONE_MASK (1 << 0)
> @@ -508,6 +507,31 @@ static int omap_i2c_wait_for_bb(struct omap_i2c_dev *dev)
> }
>
> /*
> + * Bus Clear
> + */
> +static int omap_i2c_bus_clear(struct omap_i2c_dev *dev)
> +{
> + u16 w;
> +
> + /*
> + * Per the I2C specification, if we are stuck in a bus busy state
> + * we can attempt a bus clear to try and recover the bus by sending
> + * at least 9 clock pulses on SCL. Put the I2C in a test mode so it
> + * will output a continuous clock on SCL.
> + */
> + w = omap_i2c_read_reg(dev, OMAP_I2C_SYSTEST_REG);
> + omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
> + omap_i2c_write_reg(dev, OMAP_I2C_SYSTEST_REG,
> + (OMAP_I2C_SYSTEST_ST_EN | OMAP_I2C_SYSTEST_TMODE_TEST));
> + msleep(1);
> + omap_i2c_write_reg(dev, OMAP_I2C_SYSTEST_REG, w);
> + omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
> + omap_i2c_reset(dev);
> + omap_i2c_init(dev);
> + return omap_i2c_wait_for_bb(dev);
> +}
> +
> +/*
> * Low level master read/write transaction.
> */
> static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
> @@ -632,6 +656,8 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg
> msgs[], int num)
>
> r = omap_i2c_wait_for_bb(dev);
> if (r < 0)
> + r = omap_i2c_bus_clear(dev);
> + if (r < 0)
> goto out;
>
> if (dev->set_mpu_wkup_lat != NULL)
--
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] I2C: OMAP: Recover from Bus Busy condition
On Thursday 12 January 2012 03:58 AM, Kevin Hilman wrote: > Shubhrajyoti D writes: > >> From: Vikram Pandita >> >> In case a peripheral is driving SDA bus low (ie. a start condition), provide >> a constant clock output using the test mode of the OMAP I2C controller to >> try and clear the bus. Soft reset I2C controller after attempting the bus >> clear >> to ensure that controller is in a good state. >> >> Based upon Vikram Pandita's patch from TI Android 3.0 kernel and modified for >> mainline by Jon Hunter. >> >> A couple differences from the original patch ... >> 1. Add a new function for bus clear >> 2. Ensure that the CON.I2C_EN bit is set when using the SYSTEST feature to >>output a permanent clock. This bit needs to be set and tpyically it would >>be set by the unidle function but this is not the case for all OMAP >>generations. >> 3. Program the SYSTEST setting only the bits we care about. However, restore >>SYSTEST registers to there original state as some OMAP generations do not >>implement perform a soft-reset. >> 4. Clear the CON register after performing the bus clear, so when we call the >>init function the controller is disabled and the init function will >>re-enable later. >> >> Cc: Kevin Hilman >> Signed-off-by: Vikram Pandita >> Signed-off-by: Jon Hunter >> Signed-off-by: Shubhrajyoti D >> --- >> Original patch can be found here: >> http://git.omapzoom.org/?p=kernel/omap.git;a=commit;h=a2ab04192ba25e60f95ba1ff3af5601a2d7b5bd1 >> applies on Kevin's for_3.3/i2c/misc > Please also explain how this was tested, and on what platforms. Please ignore will resend. > 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 RFC] I2C : OMAP : make omap_i2c_unidle/idle functions depend on CONFIG_PM_RUNTIME
On Thursday 12 January 2012 03:46 AM, Kevin Hilman wrote: > Shubhrajyoti D writes: > >> The functions omap_i2c_unidle/idle are called from omap_i2c_runtime_resume >> and omap_i2c_runtime_suspend which is compiled for CONFIG_PM_RUNTIME. >> Make the omap_i2c_unidle/idle also depend on CONFIG_PM_RUNTIME flag. > I probably should've done this when I initially cleaned up the > callbacks, but since you're doing it... > > rather than move the functions within the file, just remove the > functions and move the code into the runtime callbacks. That may break the modularity of the code since the omap_i2c_unidle is responsible for restore. I would have preferred to keep it separate. Do you think I could rename omap_i2c_unidle to omap_i2c_restore instead ? However don't feel strongly about it either dif you still feel that it should be moved into runtime callbacks directly I am ok. > > 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] usb: musb: drop superfluous pm_runtime calls around musb_shutdown
On Thursday 12 January 2012 06:51 PM, Grazvydas Ignotas wrote: > Since commit 4f9edd2d7e8d "usb: musb: Fix the crash issue during reboot" > musb_shutdown() does pm_runtime_get_sync/pm_runtime_put by itself, so > this no longer needs to be done by the caller. Also, musb_exit_debugfs() > doesn't access the device, so just drop those runtime_pm calls. > > Signed-off-by: Grazvydas Ignotas Looks good to me Reviewed-by: Shubhrajyoti D -- 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 RFC 2/2] OMAP : serial : Check for error in get_context_loss_count
On Friday 20 January 2012 04:29 AM, Kevin Hilman wrote:
> Shubhrajyoti D writes:
>
>> In serial_omap_runtime_resume in case of errors returned by
>> get_context_loss_count print a warning and do a restore.
>>
>> Signed-off-by: Shubhrajyoti D
> These two patches should be combined into a single patch.
>
OK I will combine. I had split as the one was a serial driver and one
for omap
maintainer.
However I agree that they should be combined.
> Also, please Cc Govindraj since he's the maintainer of this driver and
> should Ack.
will do that
> Thanks,
>
> Kevin
>
>> ---
>> applies on Tony's uart branch
>>
>> drivers/tty/serial/omap-serial.c | 10 --
>> 1 files changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/tty/serial/omap-serial.c
>> b/drivers/tty/serial/omap-serial.c
>> index 29fe6fd..6008612 100644
>> --- a/drivers/tty/serial/omap-serial.c
>> +++ b/drivers/tty/serial/omap-serial.c
>> @@ -1602,10 +1602,16 @@ static int serial_omap_runtime_resume(struct device
>> *dev)
>>
>> if (up) {
>> if (pdata->get_context_loss_count) {
>> -u32 loss_cnt = pdata->get_context_loss_count(dev);
>> +int loss_cnt = pdata->get_context_loss_count(dev);
>>
>> -if (up->context_loss_cnt != loss_cnt)
>> +if (loss_cnt < 0) {
>> +dev_err(dev,
>> +"get_context_loss_count failed : %d\n",
>> +loss_cnt);
>> serial_omap_restore_context(up);
>> +} else if (up->context_loss_cnt != loss_cnt) {
>> +serial_omap_restore_context(up);
>> +}
>> }
>>
>> /* Errata i291 */
--
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/5] omap-serial: Fix the error handling in the omap_serial probe
On Friday 20 January 2012 02:19 PM, Govindraj wrote:
> On Mon, Jan 16, 2012 at 3:52 PM, Shubhrajyoti D wrote:
>> The patch does the following
>>
>> - The pm_runtime_disable is called in the remove not in the error
>> case of probe.The patch calls the pm_runtime_disable in the error
>> case.
>> - The up is not freed in the error path. Fix the memory leak by calling
>> kfree in the error path.
>> - Also the iounmap is not called fix the same by calling iounmap in the
>> error case of probe and remove .
>> - Make the name of the error tags more meaningful.
>>
>> Signed-off-by: Shubhrajyoti D
>> ---
>> drivers/tty/serial/omap-serial.c | 27 +--
>> 1 files changed, 17 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/tty/serial/omap-serial.c
>> b/drivers/tty/serial/omap-serial.c
>> index 1c24269..8c6f137 100644
>> --- a/drivers/tty/serial/omap-serial.c
>> +++ b/drivers/tty/serial/omap-serial.c
>> @@ -1369,14 +1369,14 @@ static int serial_omap_probe(struct platform_device
>> *pdev)
>>
>>dma_rx = platform_get_resource_byname(pdev, IORESOURCE_DMA, "rx");
>>if (!dma_rx) {
>> - ret = -EINVAL;
>> - goto err;
>> + ret = -ENXIO;
>> + goto do_release_region;
>>}
>>
>>dma_tx = platform_get_resource_byname(pdev, IORESOURCE_DMA, "tx");
>>if (!dma_tx) {
>> - ret = -EINVAL;
>> - goto err;
>> + ret = -ENXIO;
>> + goto do_release_region;
>>}
>>
>>up = kzalloc(sizeof(*up), GFP_KERNEL);
>> @@ -1403,7 +1403,7 @@ static int serial_omap_probe(struct platform_device
>> *pdev)
>>dev_err(&pdev->dev, "failed to get alias/pdev id, errno %d\n",
>>
>> up->port.line);
>>ret = -ENODEV;
>> - goto err;
>> + goto err_port_line;
>>}
>>
>>sprintf(up->name, "OMAP UART%d", up->port.line);
>> @@ -1412,7 +1412,7 @@ static int serial_omap_probe(struct platform_device
>> *pdev)
>>if (!up->port.membase) {
>>dev_err(&pdev->dev, "can't ioremap UART\n");
>>ret = -ENOMEM;
>> - goto err;
>> + goto err_ioremap;
>>}
>>
>>up->port.flags = omap_up_info->flags;
>> @@ -1458,16 +1458,22 @@ static int serial_omap_probe(struct platform_device
>> *pdev)
>>
>>ret = uart_add_one_port(&serial_omap_reg, &up->port);
>>if (ret != 0)
>> - goto do_release_region;
>> + goto err_add_port;
>>
>>pm_runtime_put(&pdev->dev);
>>platform_set_drvdata(pdev, up);
>>return 0;
>> -err:
>> - dev_err(&pdev->dev, "[UART%d]: failure [%s]: %d\n",
>> - pdev->id, __func__, ret);
>> +
>> +err_add_port:
>> + pm_runtime_disable(&pdev->dev);
>> + iounmap(up->port.membase);
>> +err_ioremap:
>> +err_port_line:
>> + kfree(up);
>> do_release_region:
>>release_mem_region(mem->start, resource_size(mem));
>> + dev_err(&pdev->dev, "[UART%d]: failure [%s]: %d\n",
>> + pdev->id, __func__, ret);
>>return ret;
>> }
>>
>> @@ -1476,6 +1482,7 @@ static int serial_omap_remove(struct platform_device
>> *dev)
>>struct uart_omap_port *up = platform_get_drvdata(dev);
>>
>>if (up) {
>> + iounmap(up->port.membase);
> you can build omap-serial as module insmod and rmmod
> the module and test this patch.
>
> This can be done on zoom board which uses a non-omap uart
> as console.
Yes will do that and post another version.
> --
> Thanks,
> Govindraj.R
--
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: [PATCHv5 17/18] I2C: OMAP: Do not set the XUDF if the underflow is not reached
Hi Moiz,
Thanks for your review.
On Tuesday 03 April 2012 09:41 PM, Sonasath, Moiz wrote:
> Shubhrajyoti,
>
> On Tue, Apr 3, 2012 at 11:02 AM, Shubhrajyoti D wrote:
>
>> Currently in the 1.153 errata handling while waiting for transmitter
>> underflow if NACK is got the XUDF flag is also set.
>> The flag is set after wait for the condition is over.
>>
>> Cc: Alexander Shishkin
>> Cc: Moiz Sonasath
>> Signed-off-by: Shubhrajyoti D
>> ---
>> drivers/i2c/busses/i2c-omap.c |2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
>> index 51576d6..a3160d1 100644
>> --- a/drivers/i2c/busses/i2c-omap.c
>> +++ b/drivers/i2c/busses/i2c-omap.c
>> @@ -763,7 +763,6 @@ static int errata_omap3_1p153(struct omap_i2c_dev
>> *dev, u16 *stat, int *err)
>>if (*stat & (OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) {
>>omap_i2c_ack_stat(dev, *stat & (OMAP_I2C_STAT_XRDY |
>>OMAP_I2C_STAT_XDR));
>> - *err |= OMAP_I2C_STAT_XUDF;
>>
> I think we should set the NACK|AL err flag here instead??
On return of negative values there is a goto and those flags are set there.
Did I miss something?
>
>>return -ETIMEDOUT;
>>}
>>
>> @@ -776,6 +775,7 @@ static int errata_omap3_1p153(struct omap_i2c_dev
>> *dev, u16 *stat, int *err)
>>return 0;
>>}
>>
>> + *err |= OMAP_I2C_STAT_XUDF;
>>
> Ack for this change.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] OMAP2+: UART: Remove cpu checks for populating errata flags
Hi Govind,
On Tuesday 03 April 2012 07:12 PM, Govindraj.R wrote:
> From: "Govindraj.R"
>
> Currently the errata is populated based on cpu checks this can
> be removed and replaced with module version check of uart ip block.
> MVR reg is provided within the uart reg map use the same
> to populate the errata and thus now errata population and handling
> can be managed within the driver itself.
>
> Cc: Jon Hunter
> Cc: Paul Walmsley
> Cc: Kevin Hilman
> Signed-off-by: Felipe Balbi
> Signed-off-by: Govindraj.R
> ---
> arch/arm/mach-omap2/serial.c |8 ---
> arch/arm/plat-omap/include/plat/omap-serial.h |1 -
> drivers/tty/serial/omap-serial.c | 74
> -
> 3 files changed, 73 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
> index 0cdd359..6affdd4 100644
> --- a/arch/arm/mach-omap2/serial.c
> +++ b/arch/arm/mach-omap2/serial.c
> @@ -355,14 +355,6 @@ void __init omap_serial_init_port(struct omap_board_data
> *bdata,
> omap_up.dma_rx_poll_rate = info->dma_rx_poll_rate;
> omap_up.autosuspend_timeout = info->autosuspend_timeout;
>
> - /* Enable the MDR1 Errata i202 for OMAP2430/3xxx/44xx */
> - if (!cpu_is_omap2420() && !cpu_is_ti816x())
> - omap_up.errata |= UART_ERRATA_i202_MDR1_ACCESS;
> -
> - /* Enable DMA Mode Force Idle Errata i291 for omap34xx/3630 */
> - if (cpu_is_omap34xx() || cpu_is_omap3630())
34xx is true for 3630 also thanks for fixing the unneeded oring.
:-)
> - omap_up.errata |= UART_ERRATA_i291_DMA_FORCEIDLE;
> -
> pdata = &omap_up;
> pdata_size = sizeof(struct omap_uart_port_info);
>
> diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
> b/arch/arm/plat-omap/include/plat/omap-serial.h
> index 9ff..1a52725 100644
> --- a/arch/arm/plat-omap/include/plat/omap-serial.h
> +++ b/arch/arm/plat-omap/include/plat/omap-serial.h
> @@ -65,7 +65,6 @@ struct omap_uart_port_info {
> booldma_enabled;/* To specify DMA Mode */
> unsigned intuartclk;/* UART clock rate */
> upf_t flags; /* UPF_* flags */
> - u32 errata;
> unsigned intdma_rx_buf_size;
> unsigned intdma_rx_timeout;
> unsigned intautosuspend_timeout;
> diff --git a/drivers/tty/serial/omap-serial.c
> b/drivers/tty/serial/omap-serial.c
> index 0121486..0555c96 100644
> --- a/drivers/tty/serial/omap-serial.c
> +++ b/drivers/tty/serial/omap-serial.c
> @@ -44,6 +44,13 @@
> #include
> #include
>
> +#define UART_BUILD_REVISION(x, y)(((x) << 8) | (y))
> +
> +#define OMAP_UART_REV_42 0x0402
> +#define OMAP_UART_REV_46 0x0406
> +#define OMAP_UART_REV_52 0x0502
> +#define OMAP_UART_REV_63 0x0603
Maybe a comment can be added or the #define changed to reflect
the processor also so that it is easy to map.
A dev_info print could be added so that the bootup logs(probe) could
tell what ip rev is booted is running.
Feel free to ignore such trivial comments.
> +
> #define DEFAULT_CLK_SPEED 4800 /* 48Mhz*/
>
> /* SCR register bitmasks */
> @@ -53,6 +60,17 @@
> #define OMAP_UART_FCR_RX_FIFO_TRIG_SHIFT 6
> #define OMAP_UART_FCR_RX_FIFO_TRIG_MASK (0x3 << 6)
>
> +/* MVR register bitmasks */
> +#define OMAP_UART_MVR_SCHEME_SHIFT 30
> +
> +#define OMAP_UART_LEGACY_MVR_MAJ_MASK0xf0
> +#define OMAP_UART_LEGACY_MVR_MAJ_SHIFT 4
> +#define OMAP_UART_LEGACY_MVR_MIN_MASK0x0f
> +
> +#define OMAP_UART_MVR_MAJ_MASK 0x700
> +#define OMAP_UART_MVR_MAJ_SHIFT 8
> +#define OMAP_UART_MVR_MIN_MASK 0x3f
> +
> static struct uart_omap_port *ui[OMAP_MAX_HSUART_PORTS];
>
> /* Forward declaration of functions */
> @@ -1346,6 +1364,59 @@ static void uart_tx_dma_callback(int lch, u16
> ch_status, void *data)
> return;
> }
>
> +static void omap_serial_fill_features_erratas(struct uart_omap_port *up)
> +{
> + u32 mvr, scheme;
> + u16 revision, major, minor;
> +
> + mvr = serial_in(up, UART_OMAP_MVER);
> +
> + /* Check revision register scheme */
> + scheme = mvr >> OMAP_UART_MVR_SCHEME_SHIFT;
> +
> + switch (scheme) {
> + case 0: /* Legacy Scheme: OMAP2/3 */
> + /* MINOR_REV[0:4], MAJOR_REV[4:7] */
> + major = (mvr & OMAP_UART_LEGACY_MVR_MAJ_MASK) >>
> + OMAP_UART_LEGACY_MVR_MAJ_SHIFT;
> + minor = (mvr & OMAP_UART_LEGACY_MVR_MIN_MASK);
> + break;
> + case 1:
> + /* New Scheme: OMAP4+ */
> + /* MINOR_REV[0:5], MAJOR_REV[8:10] */
> + major = (mvr & OMAP_UART_MVR_MAJ_MASK) >>
> + OMAP_UART_MVR_MAJ_SHIFT;
> + minor = (mvr & OMAP_UART_MVR_MIN_MASK);
> + break;
> + default:
> +
Re: [PATCH RESEND] Input: omap-keypad: dynamically handle register offsets
Hi Sourav,
Some suggestions/ doubts.
On Tuesday 03 April 2012 10:52 AM, Sourav Poddar wrote:
> From: G, Manjunath Kondaiah
>
> Keypad controller register offsets are different for omap4
> and omap5. Handle these offsets through static mapping and
> assign these mappings during run time.
>
> Signed-off-by: Felipe Balbi
> Signed-off-by: G, Manjunath Kondaiah
> Signed-off-by: Sourav Poddar
> ---
> Test Info
> - Tested on omap4 sdp with 3.4-rc1
> - Tested on omap5430evm with 3.1 custom kernel.
> drivers/input/keyboard/Kconfig|6 +-
> drivers/input/keyboard/omap4-keypad.c | 120 ++--
> 2 files changed, 100 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
> index f354813..9a0e1a9 100644
> --- a/drivers/input/keyboard/Kconfig
> +++ b/drivers/input/keyboard/Kconfig
> @@ -511,10 +511,10 @@ config KEYBOARD_OMAP
> To compile this driver as a module, choose M here: the
> module will be called omap-keypad.
>
> -config KEYBOARD_OMAP4
> - tristate "TI OMAP4 keypad support"
> +config KEYBOARD_OMAP4+
> + tristate "TI OMAP4+ keypad support"
> help
> - Say Y here if you want to use the OMAP4 keypad.
> + Say Y here if you want to use the OMAP4+ keypad.
>
> To compile this driver as a module, choose M here: the
> module will be called omap4-keypad.
> diff --git a/drivers/input/keyboard/omap4-keypad.c
> b/drivers/input/keyboard/omap4-keypad.c
> index e809ac0..742e1e3 100644
> --- a/drivers/input/keyboard/omap4-keypad.c
> +++ b/drivers/input/keyboard/omap4-keypad.c
> @@ -68,6 +68,11 @@
>
> #define OMAP4_MASK_IRQSTATUSDISABLE 0x
>
> +enum {
> + KBD_REVISION_OMAP4 = 0,
> + KBD_REVISION_OMAP5,
> +};
> +
> struct omap4_keypad {
> struct input_dev *input;
>
> @@ -76,11 +81,66 @@ struct omap4_keypad {
>
> unsigned int rows;
> unsigned int cols;
> + unsigned int revision;
> + u32 irqstatus;
> + u32 irqenable;
> unsigned int row_shift;
> unsigned char key_state[8];
> unsigned short keymap[];
> };
>
> +static int kbd_read_irqstatus(struct omap4_keypad *keypad_data, u32 offset)
> +{
> + return __raw_readl(keypad_data->base + offset);
> +}
> +
> +static int kbd_write_irqstatus(struct omap4_keypad *keypad_data,
> + u32 offset, u32 value)
> +{
> + return __raw_writel(value, keypad_data->base + offset);
> +}
> +
> +static int kbd_write_irqenable(struct omap4_keypad *keypad_data,
> + u32 offset, u32 value)
> +{
> + return __raw_writel(value, keypad_data->base + offset);
> +}
The functions
kbd_write_irqenable and kbd_write_irqstatus look identical.
Could we optimise it?
Feel free to ignore such trivial comments.
> +
> +static int kbd_readl(struct omap4_keypad *keypad_data, u32 offset)
> +{
> + if (keypad_data->revision == KBD_REVISION_OMAP4)
> + return __raw_readl(keypad_data->base + offset);
> + else if (keypad_data->revision == KBD_REVISION_OMAP5)
> + return __raw_readl(keypad_data->base + offset + 0x10);
> +
> + return -ENODEV;
> +}
> +
> +static void kbd_writel(struct omap4_keypad *keypad_data, u32 offset, u32
> value)
> +{
> + if (keypad_data->revision == KBD_REVISION_OMAP4)
> + __raw_writel(value, keypad_data->base + offset);
> + else if (keypad_data->revision == KBD_REVISION_OMAP5)
> + __raw_writel(value, keypad_data->base + offset + 0x10);
> +}
> +
> +static int kbd_read_revision(struct omap4_keypad *keypad_data, u32 offset)
> +{
> + int reg;
Can this be unsigned?
> + reg = __raw_readl(keypad_data->base + offset);
> + reg &= 0x03 << 30;
> + reg >>= 30;
> +
> + switch (reg) {
> + case 1:
> + return KBD_REVISION_OMAP5;
> + case 0:
> + return KBD_REVISION_OMAP4;
> + default:
> + return -ENODEV;
> + }
> +}
> +
> /* Interrupt handler */
> static irqreturn_t omap4_keypad_interrupt(int irq, void *dev_id)
> {
> @@ -91,12 +151,11 @@ static irqreturn_t omap4_keypad_interrupt(int irq, void
> *dev_id)
> u32 *new_state = (u32 *) key_state;
>
> /* Disable interrupts */
> - __raw_writel(OMAP4_VAL_IRQDISABLE,
> - keypad_data->base + OMAP4_KBD_IRQENABLE);
> + kbd_write_irqenable(keypad_data, keypad_data->irqenable,
> + OMAP4_VAL_IRQDISABLE);
>
> - *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 = kbd_readl(keypad_data, OMAP4_KBD_FULLCODE31_0);
In the error case a negative value is returned.
Could we prevent writing in that cases.
> + *(new_state + 1) = kbd_readl(keypad_data, OMAP4_KBD_FULLCODE63_32);
>
> for (row =
Re: [PATCH 00/19] I2C updates
On Tuesday 10 April 2012 05:11 PM, Felipe Balbi wrote: > On Tue, Apr 10, 2012 at 05:01:37PM +0530, S, Venkatraman wrote: >> On Tue, Apr 10, 2012 at 4:26 PM, Shubhrajyoti D wrote: [...] >>> modpost: Fix modpost license checking of vmlinux.o (2012-04-09 20:52:56 >>> -0700) >>> >>> are available in the git repository at: >>> g...@gitorious.org:linus-tree/linus-tree.git i2c_omap-next >> Minor nit: >> You might want to indicate a git:// link instead of an ssh URL ? > indeed, for those who haven't noticed git now has separate url and > pushurl for every remote. Meaning you can pull and push with different > urls. This solves this issue. Thanks, Venkat , Felipe Here is the corrected pull request The following changes since commit 258f742635360175564e9470eb060ff4d4b984e7: modpost: Fix modpost license checking of vmlinux.o (2012-04-09 20:52:56 -0700) are available in the git repository at: git://gitorious.org/linus-tree/linus-tree.git i2c_omap-next Jon Hunter (1): I2C: OMAP: Correct I2C revision for OMAP3 Shubhrajyoti D (16): I2C: OMAP: make omap_i2c_unidle/idle functions depend on CONFIG_PM_RUNTIME I2C: OMAP: Remove reset at init I2C: OMAP: I2C register restore only if context is lost I2C: OMAP: Fix the interrupt clearing in OMAP4 I2C: OMAP: Fix the mismatch of pm_runtime enable and disable I2C: OMAP: Optimise the remove code I2C: OMAP: Fix the error handling I2C: OMAP: Don't check if wait_for_completion_timeout() returns less than zero I2C: OMAP: use devm_* functions I2C: OMAP: Fix the crash in i2c remove I2C: OMAP: Handle error check for pm runtime I2C: OMAP: Use SET_RUNTIME_PM_OPS I2C: OMAP: make the read ready processing a separate function I2C: OMAP: Do not set the XUDF if the underflow is not reached I2C: OMAP: Rename the 1p153 to the erratum id i462 ARM: OMAP4: hwmod data: I2C: add flag for context restore Tasslehoff Kjappfot (1): I2C: OMAP: fix missing handling of errata I2C_OMAP3_1P153 Vikram Pandita (1): I2C: OMAP: Recover from Bus Busy condition arch/arm/mach-omap2/omap_hwmod_44xx_data.c |3 +- arch/arm/plat-omap/i2c.c |3 + drivers/i2c/busses/i2c-omap.c | 342 +++- include/linux/i2c-omap.h |1 + 4 files changed, 194 insertions(+), 155 deletions(-) -- 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: [PATCHv6 19/19] ARM: OMAP4: hwmod data: I2C: add flag for context restore
On Tuesday 10 April 2012 11:43 PM, Paul Walmsley wrote: > On Tue, 10 Apr 2012, Shubhrajyoti D wrote: > >> Restore of context is not done for OMAP4. This patch >> adds the OMAP_I2C_FLAG_RESET_REGS_POSTIDLE in the OMAP4 >> hwmod data which activates the restore for OMAP4. >> Currently the OMAP4 does not hit device off still the >> driver may have support for it. >> >> Cc: Benoit Cousson >> Cc: Paul Wamsley >> Reviewed-by: Kevin Hilman >> Signed-off-by: Shubhrajyoti D > Thanks, queued for 3.5. You can drop this from your series; it will > likely cause merge conflicts if you don't. Thanks Paul. Will drop this patch and resend. > - 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: [PATCHv7 00/18] I2C updates
Please ignore this series sent the wrong patches by mistake. Will resend. On Wednesday 11 April 2012 04:22 PM, Shubhrajyoti D wrote: > The patch series does the following > > - Warn fixes if CONFIG_PM_RUNTIME is not selected. > - I2C register restore only if context if the context is lost > - Bus busy recovery mechanism. > - the reset is not done in init. > - Adds a patch to use devm_* functions > - Also checks the return type of the get_sync and in case > of errors prevents register access, also print the cause of > failure in case of errors. > - In case of i2c remove register access was done without any > get_sync fix the same. > - Adds a pdata function pointer to do context save restore > - Split the omap_i2c_isr to increase readability > - Make the i2c use SET_RUNTIME_PM_OPS > - Folds a patch from Tasslehoff to prevent any merge conflicts. > - Prevents the XDUF flag to be set if the underflow condition is not met. > - As per discussion in [1] .Adds a patch to rename the 1p153 errata and > use the unique id instead as the section number in the recent errata > docs has changed. > > - As discussed in [2] Paul has queued the flag for context restore patch, > removing it from the series. > > > [1] http://www.spinics.net/lists/linux-i2c/msg07607.html > [2] http://www.spinics.net/lists/linux-i2c/msg07685.html > > Tested on omap4sdp and omap3sdp. > > > The following changes since commit 258f742635360175564e9470eb060ff4d4b984e7: > > modpost: Fix modpost license checking of vmlinux.o (2012-04-09 20:52:56 > -0700) > > are available in the git repository at: > git://gitorious.org/linus-tree/linus-tree.git i2c_omap-next > > > > Jon Hunter (1): > I2C: OMAP: Correct I2C revision for OMAP3 > > Shubhrajyoti D (15): > I2C: OMAP: make omap_i2c_unidle/idle functions depend on > CONFIG_PM_RUNTIME > I2C: OMAP: Remove reset at init > I2C: OMAP: I2C register restore only if context is lost > I2C: OMAP: Fix the interrupt clearing in OMAP4 > I2C: OMAP: Fix the mismatch of pm_runtime enable and disable > I2C: OMAP: Optimise the remove code > I2C: OMAP: Fix the error handling > I2C: OMAP: Don't check if wait_for_completion_timeout() returns less > than zero > I2C: OMAP: use devm_* functions > I2C: OMAP: Fix the crash in i2c remove > I2C: OMAP: Handle error check for pm runtime > I2C: OMAP: Use SET_RUNTIME_PM_OPS > I2C: OMAP: make the read ready processing a separate function > I2C: OMAP: Do not set the XUDF if the underflow is not reached > I2C: OMAP: Rename the 1p153 to the erratum id i462 > > Tasslehoff Kjappfot (1): > I2C: OMAP: fix missing handling of errata I2C_OMAP3_1P153 > > Vikram Pandita (1): > I2C: OMAP: Recover from Bus Busy condition > > arch/arm/plat-omap/i2c.c |3 + > drivers/i2c/busses/i2c-omap.c | 348 > +++-- > include/linux/i2c-omap.h |1 + > 3 files changed, 198 insertions(+), 154 deletions(-) > -- 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: [PATCHv7 11/18] I2C: OMAP: use devm_* functions
On Wednesday 11 April 2012 05:04 PM, Felipe Balbi wrote: > On Wed, Apr 11, 2012 at 04:42:49PM +0530, Shubhrajyoti D wrote: >> The various devm_ functions allocate memory that is released when a driver >> detaches. This patch uses devm_kzalloc, devm_request_mem_region and >> devm_ioremap for data that is allocated in the probe function of a platform >> device and is only freed in the remove function. >> >> Signed-off-by: Shubhrajyoti D >> --- >> drivers/i2c/busses/i2c-omap.c | 29 + >> 1 files changed, 9 insertions(+), 20 deletions(-) >> >> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c >> index 121c52e..86be475 100644 >> --- a/drivers/i2c/busses/i2c-omap.c >> +++ b/drivers/i2c/busses/i2c-omap.c >> @@ -995,17 +995,17 @@ omap_i2c_probe(struct platform_device *pdev) >> return -ENODEV; >> } >> >> -ioarea = request_mem_region(mem->start, resource_size(mem), >> -pdev->name); >> +ioarea = devm_request_mem_region(&pdev->dev, mem->start, >> +resource_size(mem), pdev->name); > you could use devm_request_and_ioremap() OK will do that. thanks, -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: OMAP: dmtimer: Use devm_ API and do some cleanup in probe()
On Monday 16 April 2012 05:55 PM, Tarun Kanti DebBarma wrote:
> Replace the regular kzalloc and ioremap with the devm_ equivalent
> to simplify error handling. We don't need kree() anymore in
> omap_dm_timer_remove().
>
> Also added *dev* pointer to reference pdev->dev which makes the
> usage shorter in code.
>
> Signed-off-by: Tarun Kanti DebBarma
> ---
>
> - timer->io_base = ioremap(mem->start, resource_size(mem));
> + timer->io_base = devm_ioremap(dev, mem->start, resource_size(mem));
> if (!timer->io_base) {
Could we use devm_request_and_ioremap here?
--
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: [PATCHv8 04/18] I2C: OMAP: I2C register restore only if context is lost
On Monday 16 April 2012 11:43 PM, Tony Lindgren wrote: > * Shubhrajyoti D [120412 06:10]: >> Currently i2c register restore is done always. >> Adding conditional restore. >> The i2c register restore is done only if the context is lost. >> Also remove the definition of SYSS_RESETDONE_MASK and use the >> one in omap_hwmod.h. >> >> Signed-off-by: Shubhrajyoti D >> --- >> arch/arm/plat-omap/i2c.c |3 ++ >> drivers/i2c/busses/i2c-omap.c | 52 >> ++-- >> include/linux/i2c-omap.h |1 + >> 3 files changed, 38 insertions(+), 18 deletions(-) >> >> diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c >> index db071bc..4ccab07 100644 >> --- a/arch/arm/plat-omap/i2c.c >> +++ b/arch/arm/plat-omap/i2c.c >> @@ -179,6 +179,9 @@ static inline int omap2_i2c_add_bus(int bus_id) >> */ >> if (cpu_is_omap34xx()) >> pdata->set_mpu_wkup_lat = omap_pm_set_max_mpu_wakeup_lat_compat; >> + >> +pdata->get_context_loss_count = omap_pm_get_dev_context_loss_count; >> + >> pdev = omap_device_build(name, bus_id, oh, pdata, >> sizeof(struct omap_i2c_bus_platform_data), >> NULL, 0, 0); > This should be acked by Kevin, I should have cced Kevin. > adding him to Cc. Thanks. > For the arch/arm/plat-omap/i2c.c part: > > Acked-by: Tony Lindgren > Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/7] UART: OMAP: Cut the clock in the error cases
Hi Kevin,
Thanks for the review.
On Wednesday 18 April 2012 05:36 AM, Kevin Hilman wrote:
> Shubhrajyoti D writes:
>
>> In the error cases the clock cut is missed. This patch intends to fix the
>> same.
> Please change the references to 'cut clocks' in subject/changelog here
> (and in other patches) to use runtime suspend instead. First, runtime PM
> calls do more than cut clocks, but they only do so when
> usecounting/autosuspend timeouts permit.
Yes thanks will fix it.
>
>
>> Cc: sta...@vger.kernel.org
> Please hold off on Cc'ing stable until your patches are reviewed and accepted.
OK
>> Cc: Govindraj.R
>> Signed-off-by: Shubhrajyoti D
>> ---
>> drivers/tty/serial/omap-serial.c |6 +-
>> 1 files changed, 5 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/tty/serial/omap-serial.c
>> b/drivers/tty/serial/omap-serial.c
>> index fe099bb..10e80bb 100644
>> --- a/drivers/tty/serial/omap-serial.c
>> +++ b/drivers/tty/serial/omap-serial.c
>> @@ -319,6 +319,8 @@ static void serial_omap_start_tx(struct uart_port *port)
>>
>> if (ret < 0) {
>> serial_omap_enable_ier_thri(up);
>> +pm_runtime_mark_last_busy(&up->pdev->dev);
>> +pm_runtime_put_autosuspend(&up->pdev->dev);
> Why the autosuspend version here?
>
> Kevin
>
>
In case the request_dma fails we enable the thri( effectively like intr
mode) so
I thought of using the autosuspend version here .
Do you prefer put version instead ?
With Regards,
Shubhro
--
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/7] UART: OMAP: Cut the clock in the error cases
On Wednesday 18 April 2012 07:30 PM, Kevin Hilman wrote:
>>>if (ret < 0) {
>>>serial_omap_enable_ier_thri(up);
>>> + pm_runtime_mark_last_busy(&up->pdev->dev);
>>> + pm_runtime_put_autosuspend(&up->pdev->dev);
>>> >> Why the autosuspend version here?
>>> >>
>>> >> Kevin
>>> >>
>>> >>
>> > In case the request_dma fails we enable the thri( effectively like intr
>> > mode) so
>> > I thought of using the autosuspend version here .
>> >
>> > Do you prefer put version instead ?
> Not necessarily, it should just be well described in the changelog.
>
> Kevin
Yes agree completely. Will describe that in the changelog.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/8] DMA engine conversion
On Monday 23 April 2012 06:02 PM, Shilimkar, Santosh wrote: >> conversion process is fairly straight forward - it's more or less: >> > 1. add struct dma_chan * pointer to the private structure. >> > 2. add allocation/freeing functions for the DMA engine channels. >> > 3. convert the callbacks to match the DMA engine callback prototype. >> > 4. add code to set the DMA engine channel configuration appropriately >> > (avoiding any unnecessary calls) via dmaengine_slave_config(). >> > 5. add code to queue the transfer via dmaengine_prep_slave_sg() and >> > dmaengine_submit(). >> > 6. omap_start_dma() becomes dma_async_issue_pending(). >> > >> > drivers/spi/spi-omap2-mcspi.c | 186 >> > +--- >> > 1 files changed, 153 insertions(+), 33 deletions(-) > The patch seems to be fine to me. > > Am looping Shubro in case he has any comment on "why element sync was used ?" > and also to test the patch with more peripherals connected over SPI. > > Regards > Santosh Tested on omap4 ethernet and omap3 touchscreen also did a spidev test. Tested-by: Shubhrajyoti mailto:shubhrajy...@ti.com>> -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv8 07/10] I2C: OMAP: Handle error check for pm runtime
On Monday 23 April 2012 09:50 PM, Wolfram Sang wrote:
> On Thu, Apr 19, 2012 at 06:58:18PM +0530, Shubhrajyoti D wrote:
>> If PM runtime get_sync fails return with the error
>> so that no further reads/writes goes through the interface.
>> This will avoid possible abort. Add a error message in case
>> of failure with the cause of the failure.
> I don't think the error message is especially helpful. You also use different
> string (probably typo).
Will correct and resend
>
>> Signed-off-by: Shubhrajyoti D
>> ---
>> drivers/i2c/busses/i2c-omap.c | 19 ---
>> 1 files changed, 16 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
>> index 44e8cfa..d555dcd 100644
>> --- a/drivers/i2c/busses/i2c-omap.c
>> +++ b/drivers/i2c/busses/i2c-omap.c
>> @@ -585,7 +585,11 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg
>> msgs[], int num)
>> int i;
>> int r;
>>
>> -pm_runtime_get_sync(dev->dev);
>> +r = pm_runtime_get_sync(dev->dev);
>> +if (r < 0) {
>> +dev_err(dev->dev, "pm_runtime_get_sync failed %d\n", r);
>> +return r;
>> +}
>>
>> r = omap_i2c_wait_for_bb(dev);
>> if (r < 0)
>> @@ -1011,7 +1015,11 @@ omap_i2c_probe(struct platform_device *pdev)
>> dev->regs = (u8 *)reg_map_ip_v1;
>>
>> pm_runtime_enable(dev->dev);
>> -pm_runtime_get_sync(dev->dev);
>> +r = pm_runtime_get_sync(dev->dev);
>> +if (r < 0) {
>> +dev_err(dev->dev, "pm_runtime_get_sync failed:%d\n", r);
>> +return r;
>> +}
> Smatch says:
>
> drivers/i2c/busses/i2c-omap.c:1021 omap_i2c_probe() warn: 'mem->start' was
> not released on error
>
> In fact, you are leaking quite more.
Ops will correct, thanks.
>
>> @@ -1103,12 +,17 @@ omap_i2c_remove(struct platform_device *pdev)
>> {
>> struct omap_i2c_dev *dev = platform_get_drvdata(pdev);
>> struct resource *mem;
>> +int ret;
>>
>> platform_set_drvdata(pdev, NULL);
>>
>> free_irq(dev->irq, dev);
>> i2c_del_adapter(&dev->adapter);
>> -pm_runtime_get_sync(&pdev->dev);
>> +ret = pm_runtime_get_sync(&pdev->dev);
>> +if (ret < 0) {
>> +dev_err(dev->dev, "pm_runtime_get_sync failed %d\n", ret);
>> +return ret;
>> +}
> I am no too familiar with runtime_pm. Is it really so bad to fail remove, when
> get_sync has an error? Why is it checked and e.g. pm_runtime_put later is not?
> Any pointers?
If the get_sync fails the clock were not enabled so checking to prevent
register access.
>
>> omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
>> pm_runtime_put(&pdev->dev);
>> pm_runtime_disable(&pdev->dev);
>> --
>> 1.7.5.4
>>
> Thanks,
>
>Wolfram
>
--
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: [PATCHv8 09/10] I2C: OMAP: Do not set the XUDF if the underflow is not reached
On Monday 23 April 2012 10:12 PM, Wolfram Sang wrote: > On Thu, Apr 19, 2012 at 06:58:20PM +0530, Shubhrajyoti D wrote: >> Currently in the 1.153 errata handling while waiting for transmitter >> underflow if NACK is got the XUDF flag is also set. >> The flag is set after wait for the condition is over. > What does XUDF mean? Please update the commit description, I can't know > all terminology for all architectures. > Transmitter underflow ,will update the commit description and resend. -- 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: [PATCHv8 08/10] I2C: OMAP: fix missing handling of errata I2C_OMAP3_1P153
On Monday 23 April 2012 10:13 PM, Wolfram Sang wrote: > On Thu, Apr 19, 2012 at 06:58:19PM +0530, Shubhrajyoti D wrote: >> From: Tasslehoff Kjappfot >> >> i2c_probe set the dev->errata flag, but omap_i2c_init cleared the flag again. >> Move the errata handling to i2c_probe. >> >> Signed-off-by: Tasslehoff Kjappfot >> Signed-off-by: Shubhrajyoti D > Subject looks bogus to me. You are handling I207 here. Actually probe set ip153 then i2c init cleared so moved all the errata handling in one place so that such errors are prevented. WIll update the changelogs and resend > >> --- >> drivers/i2c/busses/i2c-omap.c | 10 +- >> 1 files changed, 5 insertions(+), 5 deletions(-) >> >> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c >> index d555dcd..9323201 100644 >> --- a/drivers/i2c/busses/i2c-omap.c >> +++ b/drivers/i2c/busses/i2c-omap.c >> @@ -427,11 +427,6 @@ static int omap_i2c_init(struct omap_i2c_dev *dev) >> /* Take the I2C module out of reset: */ >> omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN); >> >> -dev->errata = 0; >> - >> -if (dev->flags & OMAP_I2C_FLAG_APPLY_ERRATA_I207) >> -dev->errata |= I2C_OMAP_ERRATA_I207; >> - >> /* Enable interrupts */ >> dev->iestate = (OMAP_I2C_IE_XRDY | OMAP_I2C_IE_RRDY | >> OMAP_I2C_IE_ARDY | OMAP_I2C_IE_NACK | >> @@ -1023,6 +1018,11 @@ omap_i2c_probe(struct platform_device *pdev) >> >> dev->rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) & 0xff; >> >> +dev->errata = 0; >> + >> +if (dev->flags & OMAP_I2C_FLAG_APPLY_ERRATA_I207) >> +dev->errata |= I2C_OMAP_ERRATA_I207; >> + >> if (dev->rev <= OMAP_I2C_REV_ON_3430) >> dev->errata |= I2C_OMAP3_1P153; >> >> -- >> 1.7.5.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: [PATCHv8 00/10] I2C fixes
On Monday 23 April 2012 10:35 PM, Wolfram Sang wrote: > On Thu, Apr 19, 2012 at 06:58:11PM +0530, Shubhrajyoti D wrote: >> This patch series seperates the fixes from other >> changes from [2] > I also noticed this one in my build. Can you check? > > WARNING: modpost: Found 1 section mismatch(es). I checked on the old branch didnt see the error anyways will rebase to the latest head and recheck . Thanks, -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv8 06/10] I2C: OMAP: Fix the crash in i2c remove
On Monday 23 April 2012 10:19 PM, Wolfram Sang wrote: >> [ 154.901153] Exception stack(0xdf9b9fb0 to 0xdf9b9ff8) >> > [ 154.907104] 9fa0: beaf1f04 >> > 4006be00 000f 000c >> > [ 154.915710] 9fc0: 4006c000 8034 ff40 0007 >> > 0007b8d7 >> > [ 154.916778] 9fe0: beaf1b68 d23c 4005baf0 8010 >> > >> > [ 154.931335] r6: r5:8010 r4:4005baf0 r3:beaf1f04 >> > [ 154.937316] ---[ end trace 1b75b31a2719ed21 ]-- >> > >> > Cc: >> > Signed-off-by: Shubhrajyoti D > Is this really the correct solution? I do wonder that every driver using > runtime PM should enable the clocks on their own. That should be done by > the core, By core you don't mean the i2c core but the pm layer right? > I'd say; it is not unusual that drivers need to write to > registers in remove(). If it is correct, can I get some acks? I did see the crash. Will wait for the pm experts to comment. >> > --- >> > drivers/i2c/busses/i2c-omap.c |2 ++ >> > 1 files changed, 2 insertions(+), 0 deletions(-) >> > -- 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: [PATCHv8 06/10] I2C: OMAP: Fix the crash in i2c remove
On Tuesday 24 April 2012 11:48 PM, Wolfram Sang wrote: > On Tue, Apr 24, 2012 at 11:44:15PM +0530, Shubhrajyoti wrote: >> On Monday 23 April 2012 10:19 PM, Wolfram Sang wrote: >>>> [ 154.901153] Exception stack(0xdf9b9fb0 to 0xdf9b9ff8) >>>>> [ 154.907104] 9fa0: beaf1f04 >>>>> 4006be00 000f 000c >>>>> [ 154.915710] 9fc0: 4006c000 8034 ff40 0007 >>>>> 0007b8d7 >>>>> [ 154.916778] 9fe0: beaf1b68 d23c 4005baf0 8010 >>>>> >>>>> [ 154.931335] r6: r5:8010 r4:4005baf0 r3:beaf1f04 >>>>> [ 154.937316] ---[ end trace 1b75b31a2719ed21 ]-- >>>>> >>>>> Cc: >>>>> Signed-off-by: Shubhrajyoti D >>> Is this really the correct solution? I do wonder that every driver using >>> runtime PM should enable the clocks on their own. That should be done by >>> the core, >> By core you don't mean the i2c core but the pm layer right? > Yes. > >>> I'd say; it is not unusual that drivers need to write to >>> registers in remove(). If it is correct, can I get some acks? >> I did see the crash. > That was never a doubt. With "correct" I meant "correct solution". > >> Will wait for the pm experts to comment. As far as I know I don’t think that the pm layer doesn't enable the clocks for the drivers on remove. Maybe Kevin or Rajendra can comment better. -- 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: [PATCHv8 06/10] I2C: OMAP: Fix the crash in i2c remove
On Thursday 26 April 2012 11:58 AM, Shubhrajyoti wrote: > On Tuesday 24 April 2012 11:48 PM, Wolfram Sang wrote: >> On Tue, Apr 24, 2012 at 11:44:15PM +0530, Shubhrajyoti wrote: >>> On Monday 23 April 2012 10:19 PM, Wolfram Sang wrote: >>>>> [ 154.901153] Exception stack(0xdf9b9fb0 to 0xdf9b9ff8) >>>>>> [ 154.907104] 9fa0: beaf1f04 >>>>>> 4006be00 000f 000c >>>>>> [ 154.915710] 9fc0: 4006c000 8034 ff40 0007 >>>>>> 0007b8d7 >>>>>> [ 154.916778] 9fe0: beaf1b68 d23c 4005baf0 8010 >>>>>> >>>>>> [ 154.931335] r6:ffff r5:8010 r4:4005baf0 r3:beaf1f04 >>>>>> [ 154.937316] ---[ end trace 1b75b31a2719ed21 ]-- >>>>>> >>>>>> Cc: >>>>>> Signed-off-by: Shubhrajyoti D >>>> Is this really the correct solution? I do wonder that every driver using >>>> runtime PM should enable the clocks on their own. That should be done by >>>> the core, >>> By core you don't mean the i2c core but the pm layer right? >> Yes. >> >>>> I'd say; it is not unusual that drivers need to write to >>>> registers in remove(). If it is correct, can I get some acks? >>> I did see the crash. >> That was never a doubt. With "correct" I meant "correct solution". >> >>> Will wait for the pm experts to comment. > As far as I know I don’t think that the pm layer doesn't enable the clocks > for the drivers on remove. Maybe Kevin or Rajendra can comment better. typo what i meant was As far as I know the pm layer doesn't enable the clocks for the drivers on remove. Maybe Kevin or Rajendra can comment better. thanks, > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv9 06/10] I2C: OMAP: Fix the crash in i2c remove
On Saturday 12 May 2012 11:40 PM, Wolfram Sang wrote:
>> Cc: Kevin Hilman
>> > Cc: Rajendra Nayak
>> > Signed-off-by: Shubhrajyoti D
> I'd really like a comment from the PM experts if each and every driver
> has to ensure that the clocks are enabled on remove like this?
Just resent cc ing linux-pm
BTW also found that
Some others are also doing the same. eg:
drivers/mmc/host/omap_hsmmc.c
static int __devexit omap_hsmmc_remove(struct platform_device *pdev)
{
struct omap_hsmmc_host *host = platform_get_drvdata(pdev);
struct resource *res;
pm_runtime_get_sync(host->dev);
mmc_remove_host(host->mmc);
2. drivers/usb/musb/musb_core.c
static void musb_shutdown(struct platform_device *pdev)
{
struct musb *musb = dev_to_musb(&pdev->dev);
unsigned long flags;
pm_runtime_get_sync(musb->controller);
Anyways will wait for feedback.
>
>> > ---
>> > drivers/i2c/busses/i2c-omap.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: [PATCHv9 00/10] I2C fixes
Hi Kevin, On Saturday 26 May 2012 03:43 AM, Kevin Hilman wrote: > Shubhrajyoti D writes: > >> The patch series does the following >> >> - Warn fixes if CONFIG_PM_RUNTIME is not selected. >> - In case of i2c remove register access was done without any >> get_sync fix the same. >> - Folds a patch from Tasslehoff to prevent any merge conflicts. >> - Prevents the XDUF flag to be set if the underflow condition is not met. >> - As per discussion in [1] .Adds a patch to rename the 1p153 errata and >> use the unique id instead as the section number in the recent errata >> docs has changed. >> >> v9: >> Fix the comments from Wolfram Sang >> >> [1] http://www.spinics.net/lists/linux-i2c/msg07607.html >> >> Tested on omap4sdp and omap3sdp. > Can you also describe how it was tested? I did basic functionality tests using i2c-tools. > > With the runtime PM changes, does it still hit full-chip retention in > idle and suspend after these changes? Will check. > > I had a few minor comments on this version, Will fixup and resend. > otherwise feel free add > > Reviewed-by: Kevin Hilman Thanks for your review. > > That being said, before this is merged, I woudl like to see some more > non-author Tested-bys. We've been having lots of regressions of late > from OMAP drivers that are not being sufficiently tested before > merging. We need to ensure proper testing before merge. > > Other testers should also report what platforms they tested on, and how > it was tested. > > 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: [PATCHv9 00/10] I2C fixes
On Saturday 26 May 2012 05:10 AM, Kevin Hilman wrote: > Shubhrajyoti, > > Can you add one more patch to this series. Yes will add it. Thanks, Shubhro > > The patch below from Neil Brown has been circulating for awhile, and > I've been using it locally for awhile now too. It would help if it got > into this series and got some broader testing. > > 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: [PATCHv9 02/10] I2C: OMAP: Fix the mismatch of pm_runtime enable and disable
On Saturday 26 May 2012 03:27 AM, Kevin Hilman wrote: > Looks right. > > Can you be more specific in the changelog about when the errors/warning > happens? By the way the count cribs Unbalanced pm_runtime_enable! is what happens. I found it by review, I did the testing with this patch. Since there was an access without get_sync I was seeing some other issues. Did not test with the fix and without this patch. > e.g. why pm_runtime_enable() is called again? Is this on > module unload/reload? > > Other than that > > Acked-by: Kevin Hilman Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv9 07/10] I2C: OMAP: Handle error check for pm runtime
On Saturday 26 May 2012 03:36 AM, Kevin Hilman wrote: >> +r = pm_runtime_get_sync(dev->dev); >> > + if (r < 0) >> > + return r; > nit: please use IS_ERR_VALUE() Will fix that and resend. > 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: PM(?) problems on v3.3-rc1 on OMAP3
On Friday 20 January 2012 05:26 PM, Govindraj wrote: > On Fri, Jan 20, 2012 at 4:03 PM, Tomi Valkeinen wrote: >> Hi, >> >> I'm testing v3.3-rc1 on OMAP3 overo, and I'm having problems probably >> related to PM. >> >> First, when I boot up, the console (via USB serial) is very laggy, it >> often takes many seconds until the key pressed appears so it's more or >> less unusable. >> >> Second, I compile DSS as modules, and don't load them. Looking at >> debugfs/pm_debug/time, I can see that both RET and ON for dss_pwrdm are >> increasing. What is making DSS powerdomain switch back and forth? >> >> Third, when I load the DSS modules, I see only ON state increasing for >> dss_pwrdm, as it should be. However, I'm getting constant stream of sync >> losts from DSS, and the display doesn't basically work at all. >> >> I can see MPU pwrdm going into RET a lot, and if I do "while true; do >> echo foo; done", which I presume basically prevents RET for MPU, the >> display becomes stable. >> >> This sounds a bit like the problem reported by Joe (DSS2/PM on 3.2 >> broken?), although this is happening all the time. In this case, as in >> Joe's, the DSS fck is well below 96MHz, which is the limit on OMAP3 for >> DSS fclk on OPP2. And I'm not aware of any other constraints for DSS >> (well, memory throughput, but that should cause fifo underflows). >> >> Is there a way to lock the OPP to the full power OPP? The other way could be to use userspace governor and set it manually. Also the governor could be changed through sysfs. > btw, > > I think enabling cpu_idle and performance governor to should ensure that. > > However enabling performance governor boot fails. > > failure logs as in here [1]. I was using latest mainline and beagle -XM > > -- > Thanks, > Govindraj.R > > [1]: > > http://pastebin.com/9ZfB2V6B > -- > 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 RFC 2/2] mtd : Make the mtd_suspend return 0 if the suspend is not implemented
On Tuesday 24 January 2012 01:39 PM, Brian Norris wrote:
> Hi,
>
> On Mon, Jan 23, 2012 at 12:12 AM, Shubhrajyoti D wrote:
> ...
>> include/linux/mtd/mtd.h |6 +++---
>> 1 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
>> index 1a81fde..c717bb6 100644
>> --- a/include/linux/mtd/mtd.h
>> +++ b/include/linux/mtd/mtd.h
>> @@ -427,9 +427,9 @@ static inline int mtd_is_locked(struct mtd_info *mtd,
>> loff_t ofs, uint64_t len)
>>
>> static inline int mtd_suspend(struct mtd_info *mtd)
>> {
>> - if (!mtd->suspend)
>> - return -EOPNOTSUPP;
>> - return mtd->suspend(mtd);
>> + if (mtd->suspend)
>> + return mtd->suspend(mtd);
>> + return 0;
>> }
>>
>> static inline void mtd_resume(struct mtd_info *mtd)
> I believe this fix is already accounted for in Artem Bityutskiy's
> l2-mtd-2.6 repository as:
>
> commit 091a7fe219ee8d3e76be9e02221433af10c6f574
> mtd: fix MTD suspend
> (http://git.infradead.org/users/dedekind/l2-mtd-2.6.git/commit/091a7fe219ee8d3e76be9e02221433af10c6f574)
>
> However, the bug made it into the 3.3 merge window, so shouldn't this
> bugfix be sent upstream immediately?
OK thanks for pointing that.
> Brian
--
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 RFC 1/2] watchdog : omap_wdt : Implement WDIOC_GETBOOTSTATUS for omap3+
On Tuesday 24 January 2012 03:03 PM, Wolfram Sang wrote: >> Just returning the register content does not help much and looking at other >> implementations, like Blackfin, I am guessing this IOCTL is supposed to give >> a yes/no sort of result. > It needs to return WDIOF_* flags as defined in include/linux/watchdog.h. > Check also Documentation/watchdog/watchdog-api.txt for further info. > Yes, not all drivers follow this style, sadly. Yes I agree. > Regards, > >Wolfram > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3 v5] usb: musb: Add support for ti81xx platform
On Wednesday 08 February 2012 09:56 AM, Ajay Kumar Gupta wrote:
> +static int dsps_musb_init(struct musb *musb)
> +{
> + struct device *dev = musb->controller;
> + struct musb_hdrc_platform_data *plat = dev->platform_data;
> + struct platform_device *pdev = to_platform_device(dev->parent);
> + struct dsps_glue *glue = platform_get_drvdata(pdev);
> + const struct dsps_musb_wrapper *wrp = glue->wrp;
> + struct omap_musb_board_data *data = plat->board_data;
> + void __iomem *reg_base = musb->ctrl_base;
> + u32 rev, val;
> + int status;
> +
> + /* mentor core register starts at offset of 0x400 from musb base */
> + musb->mregs += wrp->musb_core_offset;
> +
> + /* NOP driver needs change if supporting dual instance */
> + usb_nop_xceiv_register();
> + musb->xceiv = otg_get_transceiver();
> + if (!musb->xceiv)
> + return -ENODEV;
> +
> + status = pm_runtime_get_sync(dev);
> + if (status < 0) {
> + dev_err(dev, "pm_runtime_get_sync FAILED");
> + goto err0;
> + }
So you are doing a get_sync at init and you cut the clocks at exit only.
Any particular reason for that.
> +
--
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/5] omap-serial: Fix the error handling in the omap_serial probe
On Friday 20 January 2012 03:05 PM, Shubhrajyoti wrote:
> On Friday 20 January 2012 02:19 PM, Govindraj wrote:
>> On Mon, Jan 16, 2012 at 3:52 PM, Shubhrajyoti D wrote:
>>> The patch does the following
>>>
>>> - The pm_runtime_disable is called in the remove not in the error
>>> case of probe.The patch calls the pm_runtime_disable in the error
>>> case.
>>> - The up is not freed in the error path. Fix the memory leak by calling
>>> kfree in the error path.
>>> - Also the iounmap is not called fix the same by calling iounmap in the
>>> error case of probe and remove .
>>> - Make the name of the error tags more meaningful.
>>>
>>> Signed-off-by: Shubhrajyoti D
>>> ---
>>> drivers/tty/serial/omap-serial.c | 27 +--
>>> 1 files changed, 17 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/drivers/tty/serial/omap-serial.c
>>> b/drivers/tty/serial/omap-serial.c
>>> index 1c24269..8c6f137 100644
>>> --- a/drivers/tty/serial/omap-serial.c
>>> +++ b/drivers/tty/serial/omap-serial.c
>>> @@ -1369,14 +1369,14 @@ static int serial_omap_probe(struct platform_device
>>> *pdev)
>>>
>>>dma_rx = platform_get_resource_byname(pdev, IORESOURCE_DMA, "rx");
>>>if (!dma_rx) {
>>> - ret = -EINVAL;
>>> - goto err;
>>> + ret = -ENXIO;
>>> + goto do_release_region;
>>>}
>>>
>>>dma_tx = platform_get_resource_byname(pdev, IORESOURCE_DMA, "tx");
>>>if (!dma_tx) {
>>> - ret = -EINVAL;
>>> - goto err;
>>> + ret = -ENXIO;
>>> + goto do_release_region;
>>>}
>>>
>>>up = kzalloc(sizeof(*up), GFP_KERNEL);
>>> @@ -1403,7 +1403,7 @@ static int serial_omap_probe(struct platform_device
>>> *pdev)
>>>dev_err(&pdev->dev, "failed to get alias/pdev id, errno
>>> %d\n",
>>>
>>> up->port.line);
>>>ret = -ENODEV;
>>> - goto err;
>>> + goto err_port_line;
>>>}
>>>
>>>sprintf(up->name, "OMAP UART%d", up->port.line);
>>> @@ -1412,7 +1412,7 @@ static int serial_omap_probe(struct platform_device
>>> *pdev)
>>>if (!up->port.membase) {
>>>dev_err(&pdev->dev, "can't ioremap UART\n");
>>>ret = -ENOMEM;
>>> - goto err;
>>> + goto err_ioremap;
>>>}
>>>
>>>up->port.flags = omap_up_info->flags;
>>> @@ -1458,16 +1458,22 @@ static int serial_omap_probe(struct platform_device
>>> *pdev)
>>>
>>>ret = uart_add_one_port(&serial_omap_reg, &up->port);
>>>if (ret != 0)
>>> - goto do_release_region;
>>> + goto err_add_port;
>>>
>>>pm_runtime_put(&pdev->dev);
>>>platform_set_drvdata(pdev, up);
>>>return 0;
>>> -err:
>>> - dev_err(&pdev->dev, "[UART%d]: failure [%s]: %d\n",
>>> - pdev->id, __func__, ret);
>>> +
>>> +err_add_port:
>>> + pm_runtime_disable(&pdev->dev);
>>> + iounmap(up->port.membase);
>>> +err_ioremap:
>>> +err_port_line:
>>> + kfree(up);
>>> do_release_region:
>>>release_mem_region(mem->start, resource_size(mem));
>>> + dev_err(&pdev->dev, "[UART%d]: failure [%s]: %d\n",
>>> + pdev->id, __func__, ret);
>>>return ret;
>>> }
>>>
>>> @@ -1476,6 +1482,7 @@ static int serial_omap_remove(struct platform_device
>>> *dev)
>>>struct uart_omap_port *up = platform_get_drvdata(dev);
>>>
>>>if (up) {
>>> + iounmap(up->port.membase);
>> you can build omap-serial as module insmod and rmmod
>> the module and test this patch.
>>
>> This can be done on zoom board which uses a non-omap uart
>> as console.
> Yes will do that and post another version.
yes , there was a missing memory release just tested with that patch.
thanks,
>> --
>> Thanks,
>> Govindraj.R
--
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] i2c: fix missing handling of errata I2C_OMAP3_1P153
On Monday 06 February 2012 08:03 PM, tasskj...@gmail.com wrote:
> From: Tasslehoff Kjappfot
>
> i2c_prope set the dev->errata flag, but omap_i2c_init cleared the flag again.
> Move the errata handling to i2c_init.
>
also in my opinion moving the reset to 0 should be moved to probe.
also you may want to cc linux-i2c for the driver patches.
> Signed-off-by: Tasslehoff Kjappfot
> ---
> drivers/i2c/busses/i2c-omap.c |7 ---
> 1 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index 801df60..ecaa60d 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -473,6 +473,10 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
> if (dev->flags & OMAP_I2C_FLAG_APPLY_ERRATA_I207)
> dev->errata |= I2C_OMAP_ERRATA_I207;
>
> + if (dev->rev <= OMAP_I2C_REV_ON_3430)
> + dev->errata |= I2C_OMAP3_1P153;
> +
> +
> /* Enable interrupts */
> dev->iestate = (OMAP_I2C_IE_XRDY | OMAP_I2C_IE_RRDY |
> OMAP_I2C_IE_ARDY | OMAP_I2C_IE_NACK |
> @@ -1058,9 +1062,6 @@ omap_i2c_probe(struct platform_device *pdev)
>
> dev->rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) & 0xff;
>
> - if (dev->rev <= OMAP_I2C_REV_ON_3430)
> - dev->errata |= I2C_OMAP3_1P153;
> -
> if (!(dev->flags & OMAP_I2C_FLAG_NO_FIFO)) {
> u16 s;
>
--
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: OMAP34xx
On Monday 13 February 2012 12:42 AM, Paul Walmsley wrote: > Hi > > On Sun, 12 Feb 2012, Russell King - ARM Linux wrote: > >> The other allnoconfig issue is: >> >> arch/arm/mach-omap2/built-in.o:(.data+0xa3d0): undefined reference to >> `omap_i2c_reset' >> >> which looks like hwmod can't cope with the I2C_OMAP being disabled. >> >> I don't propose these are fixed for v3.3, but they certainly should be >> fixed for v3.4. > Thanks for the report. Here's a patch for this for 3.4. Compile-tested > only; will boot-test it as part of the v2 of the 3.4 hwmod changes. > Boot tested on omap4430 sdp. > - Paul > > From: Paul Walmsley > Date: Sun, 12 Feb 2012 11:49:34 -0700 > Subject: [PATCH] ARM: OMAP2+: I2C: always compile I2C reset code, even if I2C > driver is not built > > During kernel init, we reset all IP blocks on the OMAP that we can, > even if there is no driver compiled for that IP block. Unlike most IP > blocks, the I2C block requires some extra programming for this to > work. This reset code is incorrectly omitted when the I2C driver is > deselected. In this circumstance, the build breaks. Fix by compiling > the I2C reset code unconditionally. > > Problem reported by Russell King . > > Signed-off-by: Paul Walmsley > Cc: Russell King > --- > arch/arm/mach-omap2/Makefile |5 + > 1 files changed, 1 insertions(+), 4 deletions(-) > > diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile > index fc9b238..0d5676c 100644 > --- a/arch/arm/mach-omap2/Makefile > +++ b/arch/arm/mach-omap2/Makefile > @@ -4,7 +4,7 @@ > > # Common support > obj-y := id.o io.o control.o mux.o devices.o serial.o gpmc.o timer.o pm.o \ > - common.o gpio.o dma.o wd_timer.o display.o > + common.o gpio.o dma.o wd_timer.o display.o i2c.o > > omap-2-3-common = irq.o sdrc.o > hwmod-common = omap_hwmod.o \ > @@ -182,9 +182,6 @@ obj-$(CONFIG_OMAP_IOMMU) += iommu2.o > iommu-$(CONFIG_OMAP_IOMMU) := omap-iommu.o > obj-y+= $(iommu-m) $(iommu-y) > > -i2c-omap-$(CONFIG_I2C_OMAP) := i2c.o > -obj-y+= $(i2c-omap-m) $(i2c-omap-y) > - > ifneq ($(CONFIG_TIDSPBRIDGE),) > obj-y+= dsp.o > endif -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/10] I2C updates
On Tuesday 14 February 2012 11:42 AM, Hebbar, Gururaja wrote: > Hi, > > I am interested in testing these patches on AM335x. Thanks for your interest in testin. > Do you have a tree with these > patches applied so that I can pull. tree: git://gitorious.org/linus-tree/linus-tree.git branch: i2c_misc_fixes let me know if that works for you > On Fri, Feb 10, 2012 at 19:29:55, Datta, Shubhrajyoti wrote: >> This patch series colates the various i2c updates into >> a series. Since it is collection of various patches >> the version info is not retained, however most of them undergone >> multiple versions. >> >> This is rebased to linus head commit 63082402968f4b73f10b28a8ac1f3da821aeb82d >> >> The patch series does the following >> >> - Warn fixes if CONFIG_PM_RUNTIME is not selected. >> - I2C register restore only if context if the context is lost >> - Bus busy recovery mechanism. >> - the reset is not done in init. >> >> Tested on omap4sdp and omap3sdp. >> >> >> Cc: Kevin Hilman >> Cc: Ben Dooks >> >> Jon Hunter (1): >> I2C: OMAP: Correct I2C revision for OMAP3 >> >> Shubhrajyoti D (8): >> I2C : OMAP : make omap_i2c_unidle/idle functions depend on >> CONFIG_PM_RUNTIME >> OMAP : I2C : Remove reset at init >> OMAP: I2C: I2C register restore only if context is lost >> OMAP: I2C: Fix the interrupt clearing in OMAP4 >> OMAP: I2C: Fix the mismatch of pm_runtime enable and disable >> OMAP: I2C: Optimise the remove code >> OMAP: I2C: Fix the error handling >> I2C: OMAP: Don't check if wait_for_completion_timeout() returns less >> than zero >> >> Vikram Pandita (1): >> I2C: OMAP: Recover from Bus Busy condition >> >> drivers/i2c/busses/i2c-omap.c | 173 >> - >> 1 files changed, 101 insertions(+), 72 deletions(-) > > > Regards, > Gururaja -- 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/5] gpio/omap: Use devm_ API and add request_mem_region
On Thursday 16 February 2012 11:11 AM, DebBarma, Tarun Kanti wrote:
> Hi Benoit,
>
> On Wed, Feb 15, 2012 at 9:34 PM, Benoit Cousson wrote:
>> Replace the regular kzalloc and ioremap with the devm_ equivalent
>> to simplify error handling.
>>
>> Add the missing devm_request_mem_region to reserve the region used
>> by the driver.
>>
>> Signed-off-by: Benoit Cousson
>> Cc: Tarun Kanti DebBarma
>> ---
>> drivers/gpio/gpio-omap.c | 35 +++
>> 1 files changed, 15 insertions(+), 20 deletions(-)
>>
>> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
>> index a0c3e03..c3a9dc8 100644
>> --- a/drivers/gpio/gpio-omap.c
>> +++ b/drivers/gpio/gpio-omap.c
>> @@ -19,7 +19,7 @@
>> #include
>> #include
>> #include
>> -#include
>> +#include
>> #include
>> #include
>>
>> @@ -1052,23 +1052,19 @@ static int __devinit omap_gpio_probe(struct
>> platform_device *pdev)
>>struct gpio_bank *bank;
>>int ret = 0;
>>
>> - if (!dev->platform_data) {
>> - ret = -EINVAL;
>> - goto err_exit;
>> - }
>> + if (!dev->platform_data)
>> + return -EINVAL;
>>
>> - bank = kzalloc(sizeof(struct gpio_bank), GFP_KERNEL);
>> + bank = devm_kzalloc(&pdev->dev, sizeof(struct gpio_bank),
>> GFP_KERNEL);
>>if (!bank) {
>>dev_err(dev, "Memory alloc failed\n");
>> - ret = -ENOMEM;
>> - goto err_exit;
>> + return -ENOMEM;
>>}
>>
>>res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
>>if (unlikely(!res)) {
>>dev_err(dev, "Invalid IRQ resource\n");
>> - ret = -ENODEV;
>> - goto err_free;
>> + return -ENODEV;
> How is the memory allocated to 'bank' getting freed before return -ENODEV?
I think that may not be needed
See http://www.kernel.org/doc/htmldocs/device-drivers/API-devm-kzalloc.html
>>}
>>
>>bank->irq = res->start;
>> @@ -1096,15 +1092,19 @@ static int __devinit omap_gpio_probe(struct
>> platform_device *pdev)
>>res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>if (unlikely(!res)) {
>>dev_err(dev, "Invalid mem resource\n");
>> - ret = -ENODEV;
>> - goto err_free;
>> + return -ENODEV;
> And here?
>
>> + }
>> +
>> + if (!devm_request_mem_region(dev, res->start, resource_size(res),
>> +pdev->name)) {
>> + dev_err(dev, "Region already claimed\n");
>> + return -EBUSY;
>>}
>>
>> - bank->base = ioremap(res->start, resource_size(res));
>> + bank->base = devm_ioremap(dev, res->start, resource_size(res));
>>if (!bank->base) {
>>dev_err(dev, "Could not ioremap\n");
>> - ret = -ENOMEM;
>> - goto err_free;
>> + return -ENOMEM;
> And here?
> --
> Tarun
>>}
>>
>>platform_set_drvdata(pdev, bank);
>> @@ -1125,11 +1125,6 @@ static int __devinit omap_gpio_probe(struct
>> platform_device *pdev)
>>list_add_tail(&bank->node, &omap_gpio_list);
>>
>>return ret;
>> -
>> -err_free:
>> - kfree(bank);
>> -err_exit:
>> - return ret;
>> }
>>
>> #ifdef CONFIG_ARCH_OMAP2PLUS
>> --
>> 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
--
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] ARM: OMAP2: remove some orphan function declarations.
On Sunday 19 February 2012 07:59 AM, NeilBrown wrote: > commit 2fd149645eb removed omap_uart_can_sleep and omap3_can_sleep, > but not their declarations. So remove those now. > a small description with the commit id would have been good. Looks good to me. Reviewed-by: Shubhrajyoti D thanks. > Signed-off-by: NeilBrown > --- > > arch/arm/mach-omap2/pm.h |1 - > arch/arm/plat-omap/include/plat/serial.h |1 - > 2 files changed, 0 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h > index b737b11..6cd954d 100644 > --- a/arch/arm/mach-omap2/pm.h > +++ b/arch/arm/mach-omap2/pm.h > @@ -18,7 +18,6 @@ > extern void *omap3_secure_ram_storage; > extern void omap3_pm_off_mode_enable(int); > extern void omap_sram_idle(void); > -extern int omap3_can_sleep(void); > extern int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32 state); > extern int omap3_idle_init(void); > extern int omap4_idle_init(void); > diff --git a/arch/arm/plat-omap/include/plat/serial.h > b/arch/arm/plat-omap/include/plat/serial.h > index 198d1e6..b073e5f 100644 > --- a/arch/arm/plat-omap/include/plat/serial.h > +++ b/arch/arm/plat-omap/include/plat/serial.h > @@ -110,7 +110,6 @@ struct omap_board_data; > struct omap_uart_port_info; > > extern void omap_serial_init(void); > -extern int omap_uart_can_sleep(void); > extern void omap_serial_board_init(struct omap_uart_port_info > *platform_data); > extern void omap_serial_init_port(struct omap_board_data *bdata, > struct omap_uart_port_info *platform_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 -- 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 5/6] gpio/omap: fix trigger type to unsigned
On Thursday 23 February 2012 05:40 PM, Tarun Kanti DebBarma wrote:
> The GPIO trigger parameter is of type unsigned.
> enum {
> IRQ_TYPE_NONE = 0x,
> IRQ_TYPE_EDGE_RISING= 0x0001,
> IRQ_TYPE_EDGE_FALLING = 0x0002,
> IRQ_TYPE_EDGE_BOTH = (IRQ_TYPE_EDGE_FALLING |
> IRQ_TYPE_EDGE_RISING),
> IRQ_TYPE_LEVEL_HIGH = 0x0004,
> IRQ_TYPE_LEVEL_LOW = 0x0008,
> IRQ_TYPE_LEVEL_MASK = (IRQ_TYPE_LEVEL_LOW | IRQ_TYPE_LEVEL_HIGH),
> IRQ_TYPE_SENSE_MASK = 0x000f,
>
> IRQ_TYPE_PROBE = 0x0010,
> ...
> };
> Even though gpio_irq_type(struct irq_data *d, unsigned type) has the right
> type
> of parameter, the subsequent called functions set_gpio_triggering() and
> set_gpio_trigger() wrongly makes it signed integer. Fix this.
>
> Signed-off-by: Tarun Kanti DebBarma
> ---
> drivers/gpio/gpio-omap.c |5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
> index 3dd4b3a..67535c8 100644
> --- a/drivers/gpio/gpio-omap.c
> +++ b/drivers/gpio/gpio-omap.c
> @@ -232,7 +232,7 @@ static void _set_gpio_debounce(struct gpio_bank *bank,
> unsigned gpio,
> }
>
> static inline void set_gpio_trigger(struct gpio_bank *bank, int gpio,
> - int trigger)
> + unsigned trigger)
> {
> void __iomem *base = bank->base;
> u32 gpio_bit = 1 << gpio;
> @@ -314,7 +314,8 @@ static void _toggle_gpio_edge_triggering(struct gpio_bank
> *bank, int gpio)
> static void _toggle_gpio_edge_triggering(struct gpio_bank *bank, int gpio) {}
> #endif
>
> -static int _set_gpio_triggering(struct gpio_bank *bank, int gpio, int
> trigger)
> +static int _set_gpio_triggering(struct gpio_bank *bank, int gpio,
> + unsigned trigger)
you meant unsigned int ? could it be made u32.
> {
> void __iomem *reg = bank->base;
> void __iomem *base = bank->base;
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/10] I2C updates
On Friday 10 February 2012 07:29 PM, Shubhrajyoti D wrote: > This patch series colates the various i2c updates into > a series. Since it is collection of various patches > the version info is not retained, however most of them undergone > multiple versions. If there are no further comments can this be queued. > This is rebased to linus head commit 63082402968f4b73f10b28a8ac1f3da821aeb82d > > The patch series does the following > > - Warn fixes if CONFIG_PM_RUNTIME is not selected. > - I2C register restore only if context if the context is lost > - Bus busy recovery mechanism. > - the reset is not done in init. > > Tested on omap4sdp and omap3sdp. > > > Cc: Kevin Hilman > Cc: Ben Dooks > > Jon Hunter (1): > I2C: OMAP: Correct I2C revision for OMAP3 > > Shubhrajyoti D (8): > I2C : OMAP : make omap_i2c_unidle/idle functions depend on > CONFIG_PM_RUNTIME > OMAP : I2C : Remove reset at init > OMAP: I2C: I2C register restore only if context is lost > OMAP: I2C: Fix the interrupt clearing in OMAP4 > OMAP: I2C: Fix the mismatch of pm_runtime enable and disable > OMAP: I2C: Optimise the remove code > OMAP: I2C: Fix the error handling > I2C: OMAP: Don't check if wait_for_completion_timeout() returns less > than zero > > Vikram Pandita (1): > I2C: OMAP: Recover from Bus Busy condition > > drivers/i2c/busses/i2c-omap.c | 173 > - > 1 files changed, 101 insertions(+), 72 deletions(-) > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/10] I2C updates
On Friday 10 February 2012 07:29 PM, Shubhrajyoti D wrote: > This patch series colates the various i2c updates into > a series. Since it is collection of various patches > the version info is not retained, however most of them undergone > multiple versions. If there are no further comments can this be queued. > This is rebased to linus head commit 63082402968f4b73f10b28a8ac1f3da821aeb82d > > The patch series does the following > > - Warn fixes if CONFIG_PM_RUNTIME is not selected. > - I2C register restore only if context if the context is lost > - Bus busy recovery mechanism. > - the reset is not done in init. > > Tested on omap4sdp and omap3sdp. > > > Cc: Kevin Hilman > Cc: Ben Dooks > > Jon Hunter (1): > I2C: OMAP: Correct I2C revision for OMAP3 > > Shubhrajyoti D (8): > I2C : OMAP : make omap_i2c_unidle/idle functions depend on > CONFIG_PM_RUNTIME > OMAP : I2C : Remove reset at init > OMAP: I2C: I2C register restore only if context is lost > OMAP: I2C: Fix the interrupt clearing in OMAP4 > OMAP: I2C: Fix the mismatch of pm_runtime enable and disable > OMAP: I2C: Optimise the remove code > OMAP: I2C: Fix the error handling > I2C: OMAP: Don't check if wait_for_completion_timeout() returns less > than zero > > Vikram Pandita (1): > I2C: OMAP: Recover from Bus Busy condition > > drivers/i2c/busses/i2c-omap.c | 173 > - > 1 files changed, 101 insertions(+), 72 deletions(-) > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/5] spi/omap: Remove bus_num usage for instance index
On Wednesday 29 February 2012 03:49 AM, Benoit Cousson wrote:
> bus_num was used to reference the mcspi controller instance in a fixed array.
> Remove this array and store this information directly inside drvdata
> structure.
>
Good change thanks.
If you want add my Reviewed-by
> bus_num is now just set if the pdev->id is present or with -1 for dynamic
> allocation by SPI core, but the driver does not access it anymore.
>
> Clean some bad comments format, and remove un-needed space.
>
> Signed-off-by: Benoit Cousson
> ---
> drivers/spi/spi-omap2-mcspi.c | 72 +++-
> 1 files changed, 34 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
> index 0b0dfb7..e034164 100644
> --- a/drivers/spi/spi-omap2-mcspi.c
> +++ b/drivers/spi/spi-omap2-mcspi.c
> @@ -109,6 +109,16 @@ struct omap2_mcspi_dma {
> #define DMA_MIN_BYTES160
>
>
> +/*
> + * Used for context save and restore, structure members to be updated
> whenever
> + * corresponding registers are modified.
> + */
> +struct omap2_mcspi_regs {
> + u32 modulctrl;
> + u32 wakeupenable;
> + struct list_head cs;
> +};
> +
> struct omap2_mcspi {
> struct work_struct work;
> /* lock protects queue and registers */
> @@ -120,8 +130,9 @@ struct omap2_mcspi {
> unsigned long phys;
> /* SPI1 has 4 channels, while SPI2 has 2 */
> struct omap2_mcspi_dma *dma_channels;
> - struct device *dev;
> + struct device *dev;
> struct workqueue_struct *wq;
> + struct omap2_mcspi_regs ctx;
> };
>
> struct omap2_mcspi_cs {
> @@ -133,17 +144,6 @@ struct omap2_mcspi_cs {
> u32 chconf0;
> };
>
> -/* used for context save and restore, structure members to be updated
> whenever
> - * corresponding registers are modified.
> - */
> -struct omap2_mcspi_regs {
> - u32 modulctrl;
> - u32 wakeupenable;
> - struct list_head cs;
> -};
> -
> -static struct omap2_mcspi_regs omap2_mcspi_ctx[OMAP2_MCSPI_MAX_CTRL];
> -
> #define MOD_REG_BIT(val, mask, set) do { \
> if (set) \
> val |= mask; \
> @@ -234,9 +234,12 @@ static void omap2_mcspi_force_cs(struct spi_device *spi,
> int cs_active)
>
> static void omap2_mcspi_set_master_mode(struct spi_master *master)
> {
> + struct omap2_mcspi *mcspi = spi_master_get_devdata(master);
> + struct omap2_mcspi_regs *ctx = &mcspi->ctx;
> u32 l;
>
> - /* setup when switching from (reset default) slave mode
> + /*
> + * Setup when switching from (reset default) slave mode
>* to single-channel master mode
>*/
> l = mcspi_read_reg(master, OMAP2_MCSPI_MODULCTRL);
> @@ -245,24 +248,20 @@ static void omap2_mcspi_set_master_mode(struct
> spi_master *master)
> MOD_REG_BIT(l, OMAP2_MCSPI_MODULCTRL_SINGLE, 1);
> mcspi_write_reg(master, OMAP2_MCSPI_MODULCTRL, l);
>
> - omap2_mcspi_ctx[master->bus_num - 1].modulctrl = l;
> + ctx->modulctrl = l;
> }
>
> static void omap2_mcspi_restore_ctx(struct omap2_mcspi *mcspi)
> {
> - struct spi_master *spi_cntrl;
> - struct omap2_mcspi_cs *cs;
> - spi_cntrl = mcspi->master;
> + struct spi_master *spi_cntrl = mcspi->master;
> + struct omap2_mcspi_regs *ctx = &mcspi->ctx;
> + struct omap2_mcspi_cs *cs;
>
> /* McSPI: context restore */
> - mcspi_write_reg(spi_cntrl, OMAP2_MCSPI_MODULCTRL,
> - omap2_mcspi_ctx[spi_cntrl->bus_num - 1].modulctrl);
> -
> - mcspi_write_reg(spi_cntrl, OMAP2_MCSPI_WAKEUPENABLE,
> - omap2_mcspi_ctx[spi_cntrl->bus_num - 1].wakeupenable);
> + mcspi_write_reg(spi_cntrl, OMAP2_MCSPI_MODULCTRL, ctx->modulctrl);
> + mcspi_write_reg(spi_cntrl, OMAP2_MCSPI_WAKEUPENABLE, ctx->wakeupenable);
>
> - list_for_each_entry(cs, &omap2_mcspi_ctx[spi_cntrl->bus_num - 1].cs,
> - node)
> + list_for_each_entry(cs, &ctx->cs, node)
> __raw_writel(cs->chconf0, cs->base + OMAP2_MCSPI_CHCONF0);
> }
> static void omap2_mcspi_disable_clocks(struct omap2_mcspi *mcspi)
> @@ -775,7 +774,8 @@ static int omap2_mcspi_request_dma(struct spi_device *spi)
> static int omap2_mcspi_setup(struct spi_device *spi)
> {
> int ret;
> - struct omap2_mcspi *mcspi;
> + struct omap2_mcspi *mcspi = spi_master_get_devdata(spi->master);
> + struct omap2_mcspi_regs *ctx = &mcspi->ctx;
> struct omap2_mcspi_dma *mcspi_dma;
> struct omap2_mcspi_cs *cs = spi->controller_state;
>
> @@ -785,7 +785,6 @@ static int omap2_mcspi_setup(struct spi_device *spi)
> return -EINVAL;
> }
>
> - mcspi = spi_master_get_devdata(spi->master);
> mcspi_dma = &mcspi->dma_channels[spi->chip_select];
>
> if (!cs) {
> @@ -797,8 +796,7 @@ static int omap2_mcspi_setup(struct spi_device *
Re: [PATCH RFC] spi/omap: Trivial cleanup
On Tuesday 06 March 2012 03:46 PM, Cousson, Benoit wrote: > Hi Shubhro, > > On 2/29/2012 3:04 PM, Shubhrajyoti D wrote: >> The context is stored directly inside drvdata structure post >> [f887876 spi/omap: Remove bus_num usage for instance index]. >> Remove the OMAP2_MCSPI_MAX_CTRL macro as it is not needed anymore. >> >> Cc: Benoit Cousson >> Signed-off-by: Shubhrajyoti D > > Thanks for that extra cleanup, I missed it. > > Acked-by: Benoit Cousson > >> --- >> Applies on Benoit's for_3.4/dt_spi_eth >> >> drivers/spi/spi-omap2-mcspi.c |3 --- >> 1 files changed, 0 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/spi/spi-omap2-mcspi.c >> b/drivers/spi/spi-omap2-mcspi.c >> index d1eb26c..3526281 100644 >> --- a/drivers/spi/spi-omap2-mcspi.c >> +++ b/drivers/spi/spi-omap2-mcspi.c >> @@ -45,9 +45,6 @@ >> >> #define OMAP2_MCSPI_MAX_FREQ4800 >> >> -/* OMAP2 has 3 SPI controllers, while OMAP3 has 4 */ >> -#define OMAP2_MCSPI_MAX_CTRL 4 >> - > > I guess it can be included in the "spi/omap: Remove bus_num usage for > instance index"? > Is that OK for you? Yes, sure. > > > Thanks, > Benoit > -- 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 RESEND 4/8] mmc: omap: context save after enabling runtime pm
On Thursday 15 March 2012 08:03 PM, Venkatraman S wrote:
> From: Balaji T K
>
> call context save api after enabling runtime pm
> to make sure register access in context save api
If I am not mistaken the api would
store the number of power state changes and accesses no registers.
Am I missing something?
> happens with clk enabled.
>
> Signed-off-by: Balaji T K
> ---
> drivers/mmc/host/omap_hsmmc.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index 0f8d34b..9fa2f39 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -1871,8 +1871,6 @@ static int __init omap_hsmmc_probe(struct
> platform_device *pdev)
> goto err1;
> }
>
> - omap_hsmmc_context_save(host);
> -
> if (host->pdata->controller_flags & OMAP_HSMMC_BROKEN_MULTIBLOCK_READ) {
> dev_info(&pdev->dev, "multiblock reads disabled due to 35xx
> erratum 2.1.1.128; MMC read performance may suffer\n");
> mmc->caps2 |= MMC_CAP2_NO_MULTI_READ;
> @@ -1883,6 +1881,8 @@ static int __init omap_hsmmc_probe(struct
> platform_device *pdev)
> pm_runtime_set_autosuspend_delay(host->dev, MMC_AUTOSUSPEND_DELAY);
> pm_runtime_use_autosuspend(host->dev);
>
> + omap_hsmmc_context_save(host);
> +
> if (cpu_is_omap2430()) {
> host->dbclk = clk_get(&pdev->dev, "mmchsdb_fck");
> /*
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5 RESEND] ARM: OMAP: USB: HOST TLL platform driver
Hi Keshava,
Some doubts / comments .
On Monday 19 March 2012 12:18 PM, Keshava Munegowda wrote:
> From: Keshava Munegowda
>
> The platform driver for the TLL component of the OMAP USB host controller
> is implemented. Depending on the TLL hardware revision , the TLL channels
> are configured. The USB HS core driver uses this driver through exported
> APIs from the TLL platform driver.
> usb_tll_enable and usb_tll_disble are the exported APIs of the USB TLL
> platform driver.
>
> Signed-off-by: Keshava Munegowda
> Reviewed-by: Partha Basak
> ---
> arch/arm/plat-omap/include/plat/usb.h |8 +
> drivers/mfd/Kconfig |2 +-
> drivers/mfd/Makefile |2 +-
> drivers/mfd/omap-usb-tll.c| 463
> +
> 4 files changed, 473 insertions(+), 2 deletions(-)
> create mode 100644 drivers/mfd/omap-usb-tll.c
>
> diff --git a/arch/arm/plat-omap/include/plat/usb.h
> b/arch/arm/plat-omap/include/plat/usb.h
> index dc864b5..eb1e47d 100644
> --- a/arch/arm/plat-omap/include/plat/usb.h
> +++ b/arch/arm/plat-omap/include/plat/usb.h
> @@ -61,6 +61,10 @@ struct usbhs_omap_platform_data {
> struct ehci_hcd_omap_platform_data *ehci_data;
> struct ohci_hcd_omap_platform_data *ohci_data;
> };
> +
> +struct usbtll_omap_platform_data {
> + enum usbhs_omap_port_mode port_mode[OMAP3_HS_USB_PORTS];
> +};
> /*-*/
>
> #define OMAP1_OTG_BASE 0xfffb0400
> @@ -105,6 +109,10 @@ extern int omap4430_phy_set_clk(struct device *dev, int
> on);
> extern int omap4430_phy_init(struct device *dev);
> extern int omap4430_phy_exit(struct device *dev);
> extern int omap4430_phy_suspend(struct device *dev, int suspend);
> +
> +extern int omap_tll_enable(void);
> +extern int omap_tll_disable(void);
> +
> #endif
>
> extern void am35x_musb_reset(void);
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index f147395..5f75ad4 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -772,7 +772,7 @@ config MFD_WL1273_CORE
> audio codec.
>
> config MFD_OMAP_USB_HOST
> - bool "Support OMAP USBHS core driver"
> + bool "Support OMAP USBHS core and TLL driver"
> depends on USB_EHCI_HCD_OMAP || USB_OHCI_HCD_OMAP3
> default y
> help
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index b953bab..4b3a8e0 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -105,7 +105,7 @@ obj-$(CONFIG_MFD_TPS6586X)+= tps6586x.o
> obj-$(CONFIG_MFD_VX855) += vx855.o
> obj-$(CONFIG_MFD_WL1273_CORE)+= wl1273-core.o
> obj-$(CONFIG_MFD_CS5535) += cs5535-mfd.o
> -obj-$(CONFIG_MFD_OMAP_USB_HOST) += omap-usb-host.o
> +obj-$(CONFIG_MFD_OMAP_USB_HOST) += omap-usb-host.o omap-usb-tll.o
> obj-$(CONFIG_MFD_PM8921_CORE)+= pm8921-core.o
> obj-$(CONFIG_MFD_PM8XXX_IRQ) += pm8xxx-irq.o
> obj-$(CONFIG_TPS65911_COMPARATOR)+= tps65911-comparator.o
> diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
> new file mode 100644
> index 000..3da468a
> --- /dev/null
> +++ b/drivers/mfd/omap-usb-tll.c
> @@ -0,0 +1,463 @@
> +/**
> + * omap-usb-tll.c - The USB TLL driver for OMAP EHCI & OHCI
> + *
> + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com
Nitpick : 2012
> + * Author: Keshava Munegowda
> + *
> + * This program is free software: you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 of
> + * the License as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see
Re: [PATCH 1/5 RESEND] ARM: OMAP: USB: HOST TLL platform driver
Hi Keshava,
On Tuesday 20 March 2012 12:58 PM, Munegowda, Keshava wrote:
>>> +}
>>> +
>>> +static const struct dev_pm_ops usbtllomap_dev_pm_ops = {
>>> + .runtime_suspend= usbtll_runtime_suspend,
>>> + .runtime_resume = usbtll_runtime_resume,
>>> +};
>>> +
>> Also how about using runtime_pm_ops ?
> Sorry I din't get this? what exact alternative are you suggesting here?
SET_RUNTIME_PM_OPS(usbtll_runtime_suspend,
usbtll_runtime_resume, NULL)
I should have been clearer.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] SPI updates
On Tuesday 20 March 2012 09:50 PM, Grant Likely wrote: > On Tue, 20 Mar 2012 15:59:46 +0530, Shubhrajyoti D > wrote: >> The patch series does the following cleanups >> - Converts the spi to module_platform_driver >> - Use the devm functions so that the freeing need not >> be done in the driver. >> >> This is also available through >> git : git://gitorious.org/linus-tree/linus-tree.git >> branch : spi >> >> >> Felipe Balbi (2): >> spi: omap2-mcspi: make it behave as a module >> spi: omap2-mcspi: convert to module_platform_driver >> >> Shubhrajyoti D (1): >> spi: omap2-mcspi: use devm_* functions >> >> drivers/spi/spi-omap2-mcspi.c | 46 >> - >> 1 files changed, 9 insertions(+), 37 deletions(-) > Merged for v3.5 (it's too late for v3.4) > > g. Thanks Grant. -- 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 RFC] usb: musb: omap: fix the error check for pm_runtime_get_sync
>>You haven't run it thru scripts/checkpatch.pl either, I guess?
>>
Actually modified the patch a little afterwards.
>>> drivers/usb/musb/omap2430.c |5 +++--
>>> 1 files changed, 3 insertions(+), 2 deletions(-)
>>> diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
>>> index 2ae0bb3..e5dd18f 100644
>>> --- a/drivers/usb/musb/omap2430.c
>>> +++ b/drivers/usb/musb/omap2430.c
>> [...]
>>> @@ -301,7 +302,7 @@ static int omap2430_musb_init(struct musb *musb)
>>>
>>> status = pm_runtime_get_sync(dev);
>>> if (status< 0) {
>>> - dev_err(dev, "pm_runtime_get_sync FAILED");
>>> + dev_err(dev, "pm_runtime_get_sync FAILED %d \n",status);
>>If I don't mistake, scripts/checkpatch.pl should warn about
>> unneeded spaces before '\n'. And also about missing spaces after
>> commas.
> I fixed in my branch, thanks
>
Thanks Felipe,
Anyways resent the patch.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: fix section mismatches in usb-host.c
Hi Igor,
On Monday 26 March 2012 08:21 PM, Igor Grinberg wrote:
> Fix the below section mismatch warning and alike:
>
> WARNING: vmlinux.o(.text+0x281d4): Section mismatch in reference from
> the function setup_ehci_io_mux() to the function
> .init.text:omap_mux_init_signal()
> The function setup_ehci_io_mux() references
> the function __init omap_mux_init_signal().
> This is often because setup_ehci_io_mux lacks a __init
> annotation or the annotation of omap_mux_init_signal is wrong.
>
These functions are called from init section only so the functions also
should also have the __init
annotation.
Reviewed-by: Shubhrajyoti D
> Signed-off-by: Igor Grinberg
> ---
> arch/arm/mach-omap2/usb-host.c | 10 ++
> 1 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
> index f51348d..dde8a11 100644
> --- a/arch/arm/mach-omap2/usb-host.c
> +++ b/arch/arm/mach-omap2/usb-host.c
> @@ -54,7 +54,7 @@ static struct omap_device_pm_latency omap_uhhtll_latency[]
> = {
> /*
> * setup_ehci_io_mux - initialize IO pad mux for USBHOST
> */
> -static void setup_ehci_io_mux(const enum usbhs_omap_port_mode *port_mode)
> +static void __init setup_ehci_io_mux(const enum usbhs_omap_port_mode
> *port_mode)
> {
> switch (port_mode[0]) {
> case OMAP_EHCI_PORT_MODE_PHY:
> @@ -197,7 +197,8 @@ static void setup_ehci_io_mux(const enum
> usbhs_omap_port_mode *port_mode)
> return;
> }
>
> -static void setup_4430ehci_io_mux(const enum usbhs_omap_port_mode *port_mode)
> +static
> +void __init setup_4430ehci_io_mux(const enum usbhs_omap_port_mode *port_mode)
> {
> switch (port_mode[0]) {
> case OMAP_EHCI_PORT_MODE_PHY:
> @@ -315,7 +316,7 @@ static void setup_4430ehci_io_mux(const enum
> usbhs_omap_port_mode *port_mode)
> }
> }
>
> -static void setup_ohci_io_mux(const enum usbhs_omap_port_mode *port_mode)
> +static void __init setup_ohci_io_mux(const enum usbhs_omap_port_mode
> *port_mode)
> {
> switch (port_mode[0]) {
> case OMAP_OHCI_PORT_MODE_PHY_6PIN_DATSE0:
> @@ -412,7 +413,8 @@ static void setup_ohci_io_mux(const enum
> usbhs_omap_port_mode *port_mode)
> }
> }
>
> -static void setup_4430ohci_io_mux(const enum usbhs_omap_port_mode *port_mode)
> +static
> +void __init setup_4430ohci_io_mux(const enum usbhs_omap_port_mode *port_mode)
> {
> switch (port_mode[0]) {
> case OMAP_OHCI_PORT_MODE_PHY_6PIN_DATSE0:
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 0/6] spi: omap2-mcspi: driver updates
On Saturday 31 March 2012 11:14 AM, Grant Likely wrote: > On Fri, 30 Mar 2012 15:50:16 +0530, Shubhrajyoti D > wrote: >> The patch series does the following cleanups >> - Converts the spi to module_platform_driver >> - Use the devm functions so that the freeing need not >> be done in the driver. >> - Makes the driver use autosuspend >> - Folds Benoit's bus_num removal patch in the series >> >> Changes from v1 >> - Makes the driver use autosuspend >> - Folds Benoit's bus_num removal patch in the series >> >> Changes from v2 >> - The tmp variable is used to write this can be optimised >> as it is not needed if the value is directly written. >> Acknowledge Tarun for the suggestion. >> >> This is also available through >> git : git://gitorious.org/linus-tree/linus-tree.git >> branch : spi >> >> This is targeted for v3.5. > Okay, now is a good time to talk about git pull request workflow. 10 > days ago you published a git tree and I replied that I had pulled it > into mine. Now you've got a new branch with the patches from the old > branch rebased onto a new head. Compairing your branch with mine now > looks like this: > > $ git fetch git://gitorious.org/linus-tree/linus-tree.git spi > remote: Counting objects: 34, done. > remote: Compressing objects: 100% (28/28), done. > remote: Total 30 (delta 24), reused 6 (delta 2) > Unpacking objects: 100% (30/30), done. > From git://gitorious.org/linus-tree/linus-tree > * branchspi-> FETCH_HEAD > $ git show-branch --topic origin spi/next FETCH_HEAD > ! [origin] Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc > ! [spi/next] Merge branch 'spi' of git://gitorious.org/linus-tree/linus-tree > into spi/next > ! [FETCH_HEAD] spi: omap2-mcspi: Trivial optimisation > --- > + [FETCH_HEAD] spi: omap2-mcspi: Trivial optimisation > + [FETCH_HEAD^] spi: omap2-mcspi: add support for pm_runtime autosuspend > + [FETCH_HEAD~2] spi: omap2-mcspi: use devm_* functions > + [FETCH_HEAD~3] spi: omap2-mcspi: convert to module_platform_driver > + [FETCH_HEAD~4] spi: omap2-mcspi: make it behave as a module > + [FETCH_HEAD~5] spi/omap: Remove bus_num usage for instance index > - [spi/next] Merge branch 'spi' of > git://gitorious.org/linus-tree/linus-tree into spi/next > + [spi/next^2] OMAP : SPI : use devm_* functions > + [spi/next^2^] spi: omap2-mcspi: convert to module_platform_driver > + [spi/next^2~2] spi: omap2-mcspi: make it behave as a module > +++ [origin~189] Linux 3.3 > > I cannot merge this branch. If I did it would result in 2 commits for > each of the commits from the original branch. You'll need go back and > rebase the new commits on top of the old base or on top of my current > spi/next branch[1] > > [1] git://git.secretlab.ca/git/linux-2.6 spi/next > > I've already published that branch, so I will not rebase it either to > remove the original commits. The new commits must go on top. > > Next time, *don't* rebase a branch that has been pulled. It should be > left alone and new commits added on top of it. Apologies for this time. Yes will take care henceforth. > If your in the > situation where mainline has commits that you need to bring into the > branch, then *merge* mainline into your branch (preferably at a tagged > release point), or ask me to merge in mainline to give you a new > baseline to work from. > > One option I do have is to apply only the patches I'm missing to my > tree, but I'm not going to because I don't actually know if patches > 1, 2, or 3 have changed since the version that I've posted. It's > safer for me to get you to rebase back onto the proper base and post > only the new patches. Your cover letter should state specifically > which branch the patches apply on top of. Will send another pull request. -- 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: [PATCHV2 3/5] OMAP: I2C: Remove the reset in the init path
On Thursday 21 July 2011 04:57 PM, Santosh Shilimkar wrote:
Thanks for your review.
On 7/21/2011 4:39 PM, Shubhrajyoti D wrote:
+/*
+ * Enabling all wakup sources to stop I2C freezing on
+ * WFI instruction.
+ * REVISIT: Some wkup sources might not be needed.
+ */
Surely not related to your patch. But the 'REVISIT:' caught
my attention. Is the comment still valid.
Yes I will look and optimise the settings. Obviously all of them may not
be needed.
Will get back on this.
Also I see that we are not writing it for " < OMAP_I2C_REV_ON_3530_4430"
I will send a patch correcting the same.
+dev->westate = OMAP_I2C_WE_ALL;
+if (dev->rev< OMAP_I2C_REV_ON_3530_4430)
Space if (dev->rev < OMAP_I2C_REV_ON_3530_4430)
+omap_i2c_write_reg(dev, OMAP_I2C_WE_REG,
+dev->westate);
}
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
@@ -612,6 +572,11 @@ static int omap_i2c_xfer_msg(struct i2c_adapter
*adap,
return r;
if (r == 0) {
dev_err(dev->dev, "controller timed out\n");
+if (dev->device_reset != NULL) {
+r = dev->device_reset(dev->dev);
+if (r< 0)
ditto
+dev_err(dev->dev, "reset failed\n");
+}
omap_i2c_init(dev);
return -ETIMEDOUT;
}
@@ -622,6 +587,11 @@ static int omap_i2c_xfer_msg(struct i2c_adapter
*adap,
/* We have an error */
if (dev->cmd_err& (OMAP_I2C_STAT_AL | OMAP_I2C_STAT_ROVR |
You can fix this one as well.
OMAP_I2C_STAT_XUDF)) {
+if (dev->device_reset != NULL) {
+r = dev->device_reset(dev->dev);
+if (r< 0)
here too.
+dev_err(dev->dev, "reset failed\n");
+}
omap_i2c_init(dev);
return -EIO;
}
@@ -1024,6 +994,7 @@ omap_i2c_probe(struct platform_device *pdev)
if (pdata != NULL) {
speed = pdata->clkrate;
dev->set_mpu_wkup_lat = pdata->set_mpu_wkup_lat;
+dev->device_reset = pdata->device_reset;
} else {
speed = 100;/* Default speed */
dev->set_mpu_wkup_lat = NULL;
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
