[PATCH 1/2] Manual revert of "omap: Fix compile for early_param and omap_smc1"
From: Felipe Balbi
This reverts the early_param part of commit
a91741262f0ae82d651c7270bc1354016c5bb9dd.
Signed-off-by: Felipe Balbi
---
arch/arm/mach-omap2/board-omap3touchbook.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3touchbook.c
b/arch/arm/mach-omap2/board-omap3touchbook.c
index 07b7a32..2a5bf5c 100644
--- a/arch/arm/mach-omap2/board-omap3touchbook.c
+++ b/arch/arm/mach-omap2/board-omap3touchbook.c
@@ -493,7 +493,7 @@ static void __init omap3touchbook_flash_init(void)
}
}
-static struct ehci_hcd_omap_platform_data ehci_pdata __initdata = {
+static struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
.port_mode[0] = EHCI_HCD_OMAP_MODE_PHY,
.port_mode[1] = EHCI_HCD_OMAP_MODE_PHY,
--
1.7.0.rc0.33.g7c3932
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Revert "omap: Fix compile for early_param and omap_smc1"
On Thu, Mar 04, 2010 at 08:40:15AM +0100, Balbi Felipe (Nokia-D/Helsinki) wrote: From: Felipe Balbi This reverts commit a91741262f0ae82d651c7270bc1354016c5bb9dd. Signed-off-by: Felipe Balbi I reverted too much... __early_param() doesn't work. -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] arm: omap: ehci: avoid compiler error with touchbook
From: Felipe Balbi
the early_param() call in board-omap3touchbook.c expands to:
static const char __setup_str_early_touchbook_revision[]
__section(.init.rodata) _aligned(1) = tbr;
[...]
and we have a non-const variable being added to the
same section:
static struct ehci_hcd_omap_platform_data ehci_pdata
__section(.init.rodata);
because of that, gcc generates a section type conflict
which can (and actually should) be avoided by marking
const every variable marked with __initconst.
This patch fixes that for the ehci_hdc_omap_platform_data.
Signed-off-by: Felipe Balbi
---
arch/arm/mach-omap2/board-3430sdp.c|2 +-
arch/arm/mach-omap2/board-3630sdp.c|2 +-
arch/arm/mach-omap2/board-am3517evm.c |2 +-
arch/arm/mach-omap2/board-cm-t35.c |2 +-
arch/arm/mach-omap2/board-devkit8000.c |2 +-
arch/arm/mach-omap2/board-igep0020.c |2 +-
arch/arm/mach-omap2/board-omap3beagle.c|2 +-
arch/arm/mach-omap2/board-omap3evm.c |2 +-
arch/arm/mach-omap2/board-omap3pandora.c |2 +-
arch/arm/mach-omap2/board-omap3touchbook.c |2 +-
arch/arm/mach-omap2/board-overo.c |2 +-
arch/arm/mach-omap2/board-zoom3.c |2 +-
arch/arm/mach-omap2/usb-ehci.c |4 ++--
arch/arm/plat-omap/include/plat/usb.h |2 +-
14 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index a101029..5822bcf 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -648,7 +648,7 @@ static void enable_board_wakeup_source(void)
OMAP_WAKEUP_EN | OMAP_PIN_INPUT_PULLUP);
}
-static struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
+static const struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
.port_mode[0] = EHCI_HCD_OMAP_MODE_PHY,
.port_mode[1] = EHCI_HCD_OMAP_MODE_PHY,
diff --git a/arch/arm/mach-omap2/board-3630sdp.c
b/arch/arm/mach-omap2/board-3630sdp.c
index 4386d2b..a0a2a11 100755
--- a/arch/arm/mach-omap2/board-3630sdp.c
+++ b/arch/arm/mach-omap2/board-3630sdp.c
@@ -54,7 +54,7 @@ static void enable_board_wakeup_source(void)
OMAP_WAKEUP_EN | OMAP_PIN_INPUT_PULLUP);
}
-static struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
+static const struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
.port_mode[0] = EHCI_HCD_OMAP_MODE_PHY,
.port_mode[1] = EHCI_HCD_OMAP_MODE_PHY,
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index 70c1861..6ae8805 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -273,7 +273,7 @@ static void __init am3517_evm_init_irq(void)
omap_gpio_init();
}
-static struct ehci_hcd_omap_platform_data ehci_pdata __initdata = {
+static const struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
.port_mode[0] = EHCI_HCD_OMAP_MODE_PHY,
.port_mode[1] = EHCI_HCD_OMAP_MODE_PHY,
.port_mode[2] = EHCI_HCD_OMAP_MODE_UNKNOWN,
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index afa77ca..046acd0 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -612,7 +612,7 @@ static struct omap2_hsmmc_info mmc[] = {
{} /* Terminator */
};
-static struct ehci_hcd_omap_platform_data ehci_pdata = {
+static const struct ehci_hcd_omap_platform_data ehci_pdata = {
.port_mode[0] = EHCI_HCD_OMAP_MODE_PHY,
.port_mode[1] = EHCI_HCD_OMAP_MODE_PHY,
.port_mode[2] = EHCI_HCD_OMAP_MODE_UNKNOWN,
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 3710190..5bfc13b 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -636,7 +636,7 @@ static struct omap_musb_board_data musb_board_data = {
.power = 100,
};
-static struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
+static const struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
.port_mode[0] = EHCI_HCD_OMAP_MODE_PHY,
.port_mode[1] = EHCI_HCD_OMAP_MODE_PHY,
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index 9958987..4f1accf 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -442,7 +442,7 @@ static struct omap_musb_board_data musb_board_data = {
.power = 100,
};
-static struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
+static const struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
.port_mode[0] = EHCI_HCD_OMAP_MODE_UNKNOWN,
.port_mode[1] = EHCI_HCD_OMAP_MODE_PHY,
.port_mode[2] = EHCI_HCD_OMAP_MODE_UNKNOWN,
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board
Re: [PATCH 2/2] arm: omap: ehci: avoid compiler error with touchbook
On Thu, Mar 04, 2010 at 08:40:16AM +0100, Balbi Felipe (Nokia-D/Helsinki) wrote: From: Felipe Balbi the early_param() call in board-omap3touchbook.c expands to: static const char __setup_str_early_touchbook_revision[] __section(.init.rodata) _aligned(1) = tbr; [...] and we have a non-const variable being added to the same section: static struct ehci_hcd_omap_platform_data ehci_pdata __section(.init.rodata); because of that, gcc generates a section type conflict which can (and actually should) be avoided by marking const every variable marked with __initconst. This patch fixes that for the ehci_hdc_omap_platform_data. Signed-off-by: Felipe Balbi missed one git add, sorry. Resending this one only. -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] arm: omap: ehci: avoid compiler error with touchbook
From: Felipe Balbi
the early_param() call in board-omap3touchbook.c expands to:
static const char __setup_str_early_touchbook_revision[]
__section(.init.rodata) _aligned(1) = tbr;
[...]
and we have a non-const variable being added to the
same section:
static struct ehci_hcd_omap_platform_data ehci_pdata
__section(.init.rodata);
because of that, gcc generates a section type conflict
which can (and actually should) be avoided by marking
const every variable marked with __initconst.
This patch fixes that for the ehci_hdc_omap_platform_data.
Signed-off-by: Felipe Balbi
---
arch/arm/mach-omap2/board-3430sdp.c|2 +-
arch/arm/mach-omap2/board-3630sdp.c|2 +-
arch/arm/mach-omap2/board-am3517evm.c |2 +-
arch/arm/mach-omap2/board-cm-t35.c |2 +-
arch/arm/mach-omap2/board-devkit8000.c |2 +-
arch/arm/mach-omap2/board-igep0020.c |2 +-
arch/arm/mach-omap2/board-omap3beagle.c|2 +-
arch/arm/mach-omap2/board-omap3evm.c |2 +-
arch/arm/mach-omap2/board-omap3pandora.c |2 +-
arch/arm/mach-omap2/board-omap3touchbook.c |2 +-
arch/arm/mach-omap2/board-overo.c |2 +-
arch/arm/mach-omap2/board-zoom3.c |2 +-
arch/arm/mach-omap2/usb-ehci.c |4 ++--
arch/arm/plat-omap/include/plat/usb.h |2 +-
14 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index a101029..5822bcf 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -648,7 +648,7 @@ static void enable_board_wakeup_source(void)
OMAP_WAKEUP_EN | OMAP_PIN_INPUT_PULLUP);
}
-static struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
+static const struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
.port_mode[0] = EHCI_HCD_OMAP_MODE_PHY,
.port_mode[1] = EHCI_HCD_OMAP_MODE_PHY,
diff --git a/arch/arm/mach-omap2/board-3630sdp.c
b/arch/arm/mach-omap2/board-3630sdp.c
index 4386d2b..a0a2a11 100755
--- a/arch/arm/mach-omap2/board-3630sdp.c
+++ b/arch/arm/mach-omap2/board-3630sdp.c
@@ -54,7 +54,7 @@ static void enable_board_wakeup_source(void)
OMAP_WAKEUP_EN | OMAP_PIN_INPUT_PULLUP);
}
-static struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
+static const struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
.port_mode[0] = EHCI_HCD_OMAP_MODE_PHY,
.port_mode[1] = EHCI_HCD_OMAP_MODE_PHY,
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index 70c1861..edbaa7f 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -273,7 +273,7 @@ static void __init am3517_evm_init_irq(void)
omap_gpio_init();
}
-static struct ehci_hcd_omap_platform_data ehci_pdata __initdata = {
+static const struct ehci_hcd_omap_platform_data ehci_pdata __initdata = {
.port_mode[0] = EHCI_HCD_OMAP_MODE_PHY,
.port_mode[1] = EHCI_HCD_OMAP_MODE_PHY,
.port_mode[2] = EHCI_HCD_OMAP_MODE_UNKNOWN,
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index afa77ca..046acd0 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -612,7 +612,7 @@ static struct omap2_hsmmc_info mmc[] = {
{} /* Terminator */
};
-static struct ehci_hcd_omap_platform_data ehci_pdata = {
+static const struct ehci_hcd_omap_platform_data ehci_pdata = {
.port_mode[0] = EHCI_HCD_OMAP_MODE_PHY,
.port_mode[1] = EHCI_HCD_OMAP_MODE_PHY,
.port_mode[2] = EHCI_HCD_OMAP_MODE_UNKNOWN,
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 3710190..5bfc13b 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -636,7 +636,7 @@ static struct omap_musb_board_data musb_board_data = {
.power = 100,
};
-static struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
+static const struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
.port_mode[0] = EHCI_HCD_OMAP_MODE_PHY,
.port_mode[1] = EHCI_HCD_OMAP_MODE_PHY,
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index 9958987..4f1accf 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -442,7 +442,7 @@ static struct omap_musb_board_data musb_board_data = {
.power = 100,
};
-static struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
+static const struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
.port_mode[0] = EHCI_HCD_OMAP_MODE_UNKNOWN,
.port_mode[1] = EHCI_HCD_OMAP_MODE_PHY,
.port_mode[2] = EHCI_HCD_OMAP_MODE_UNKNOWN,
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-
[PATCH 1/2] Revert "omap: Fix compile for early_param and omap_smc1"
From: Felipe Balbi
This reverts commit a91741262f0ae82d651c7270bc1354016c5bb9dd.
Signed-off-by: Felipe Balbi
---
arch/arm/mach-omap2/board-4430sdp.c|2 +-
arch/arm/mach-omap2/board-omap3touchbook.c | 12 ++--
drivers/video/omap2/vram.c | 14 +-
3 files changed, 12 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index a462d50..180ac11 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -49,7 +49,7 @@ static struct omap_board_config_kernel sdp4430_config[]
__initdata = {
{ OMAP_TAG_LCD, &sdp4430_lcd_config },
};
-#if defined(CONFIG_SMP) && defined(CONFIG_CACHE_L2X0)
+#ifdef CONFIG_CACHE_L2X0
noinline void omap_smc1(u32 fn, u32 arg)
{
register u32 r12 asm("r12") = fn;
diff --git a/arch/arm/mach-omap2/board-omap3touchbook.c
b/arch/arm/mach-omap2/board-omap3touchbook.c
index 07b7a32..3943d0f 100644
--- a/arch/arm/mach-omap2/board-omap3touchbook.c
+++ b/arch/arm/mach-omap2/board-omap3touchbook.c
@@ -493,7 +493,7 @@ static void __init omap3touchbook_flash_init(void)
}
}
-static struct ehci_hcd_omap_platform_data ehci_pdata __initdata = {
+static struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
.port_mode[0] = EHCI_HCD_OMAP_MODE_PHY,
.port_mode[1] = EHCI_HCD_OMAP_MODE_PHY,
@@ -518,14 +518,14 @@ static void omap3_touchbook_poweroff(void)
gpio_direction_output(TB_KILL_POWER_GPIO, 0);
}
-static int __init early_touchbook_revision(char *p)
+static void __init early_touchbook_revision(char **p)
{
- if (!p)
- return 0;
+ if (!*p)
+ return;
- return strict_strtoul(p, 10, &touchbook_revision);
+ strict_strtoul(*p, 10, &touchbook_revision);
}
-early_param("tbr", early_touchbook_revision);
+__early_param("tbr=", early_touchbook_revision);
static struct omap_musb_board_data musb_board_data = {
.interface_type = MUSB_INTERFACE_ULPI,
diff --git a/drivers/video/omap2/vram.c b/drivers/video/omap2/vram.c
index 1d88425..55a4de5 100644
--- a/drivers/video/omap2/vram.c
+++ b/drivers/video/omap2/vram.c
@@ -511,17 +511,13 @@ static u32 omap_vram_sdram_size __initdata;
static u32 omap_vram_def_sdram_size __initdata;
static u32 omap_vram_def_sdram_start __initdata;
-static int __init omap_vram_early_vram(char *p)
+static void __init omap_vram_early_vram(char **p)
{
- char *endp;
-
- omap_vram_def_sdram_size = memparse(p, &endp);
- if (*endp == ',')
- omap_vram_def_sdram_start = simple_strtoul(endp + 1, &p, 16);
-
- return 0;
+ omap_vram_def_sdram_size = memparse(*p, p);
+ if (**p == ',')
+ omap_vram_def_sdram_start = simple_strtoul((*p) + 1, p, 16);
}
-early_param("vram", omap_vram_early_vram);
+__early_param("vram=", omap_vram_early_vram);
/*
* Called from map_io. We need to call to this early enough so that we
--
1.7.0.rc0.33.g7c3932
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP: DMA: Fix multi-line comments
Multi line comments are fixed as per CodingStyle
guidelines.
Cc: Tony Lindgren
Cc: Kevin Hilman
Signed-off-by: Manjunatha GK
---
arch/arm/plat-omap/dma.c | 18 --
1 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 2ab224c..e5de2bb 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -500,7 +500,8 @@ void omap_set_dma_src_burst_mode(int lch, enum
omap_dma_burst_mode burst_mode)
burst = 0x2;
break;
}
- /* not supported by current hardware on OMAP1
+ /*
+* not supported by current hardware on OMAP1
* w |= (0x03 << 7);
* fall through
*/
@@ -509,7 +510,8 @@ void omap_set_dma_src_burst_mode(int lch, enum
omap_dma_burst_mode burst_mode)
burst = 0x3;
break;
}
- /* OMAP1 don't support burst 16
+ /*
+* OMAP1 don't support burst 16
* fall through
*/
default:
@@ -603,7 +605,8 @@ void omap_set_dma_dest_burst_mode(int lch, enum
omap_dma_burst_mode burst_mode)
burst = 0x3;
break;
}
- /* OMAP1 don't support burst 16
+ /*
+* OMAP1 don't support burst 16
* fall through
*/
default:
@@ -1267,8 +1270,10 @@ int omap_request_dma_chain(int dev_id, const char
*dev_name,
return -EINVAL;
}
- /* Allocate a queue to maintain the status of the channels
-* in the chain */
+ /*
+* Allocate a queue to maintain the status of the channels
+* in the chain
+*/
channels = kmalloc(sizeof(*channels) * no_of_chans, GFP_KERNEL);
if (channels == NULL) {
printk(KERN_ERR "omap_dma: No memory for channel queue\n");
@@ -1897,7 +1902,8 @@ static int omap2_dma_handle_ch(int ch)
printk(KERN_INFO "DMA transaction error with device %d\n",
dma_chan[ch].dev_id);
if (cpu_class_is_omap2()) {
- /* Errata: sDMA Channel is not disabled
+ /*
+* Errata: sDMA Channel is not disabled
* after a transaction error. So we explicitely
* disable the channel
*/
--
1.6.3.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] OMAP: DMA: Init CDAC to zero
The register DMA4_CDAC needs to be initialized to zero
before starting DMA transfer.
Cc: Tony Lindgren
Cc: Santosh Shilimkar
Cc: Govindraj R
Cc: Kevin Hilman
Reported-by:S, Venkatraman
Signed-off-by: Manjunatha GK
---
It was aligned to reset CDAC to zero in omap_start_dma(int lch)
instead of creating new API for accessing CDAC register.
Discussion thread is at:
http://patchwork.kernel.org/patch/83176/
http://patchwork.kernel.org/patch/82948/
v2 changes:
Fixed multiline comments as per CodingStyle
arch/arm/plat-omap/dma.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 2ab224c..f6c9bdc 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -936,6 +936,15 @@ void omap_start_dma(int lch)
{
u32 l;
+ /*
+* The CPC/CDAC register needs to be initialized to zero
+* before starting dma transfer.
+*/
+ if (cpu_is_omap15xx())
+ dma_write(0, CPC(lch));
+ else
+ dma_write(0, CDAC(lch));
+
if (!omap_dma_in_1510_mode() && dma_chan[lch].next_lch != -1) {
int next_lch, cur_lch;
char dma_chan_link_map[OMAP_DMA4_LOGICAL_DMA_CH_COUNT];
--
1.6.3.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: McBSP: Drop unnecessary status/error bit clearing on reg_cache retrieved register values
On Tue, 23 Feb 2010 16:50:38 +0100 Janusz Krzysztofik wrote: > The MsBSP register cache will never have any error/status flags set, since > these flags are never written to the reg_cache. So it is kind of not > necessary to clear these flags, which are actually always 0. > > In other words, clearing the status/error flags are not necessary, since the > reg_cache will never got these bits set. We can just write back the > register content from the cache as it is when clearing an error condition. > > Created against l-o for-next commit 62a7c2cc4c8e57e80ccf379536f362fe6e863ac3 > dated 2010-02-22. > Tested on Amstrad Delta. > > Reported-by: Peter Ujfalusi > Signed-off-by: Janusz Krzysztofik > Acked-by: Jarkko Nikula -- To unsubscribe from this list: send the line "unsubscribe 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: usb_nop_xceiv_register() missing when OTG built as modules
> -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Kevin Hilman > Sent: Thursday, March 04, 2010 5:39 AM > To: linux-omap@vger.kernel.org > Subject: usb_nop_xceiv_register() missing when OTG built as modules > > This just started happening with v2.6.33. > > On OMAP3EVM, usb_nop_xceiv_register() is called in the board file, > but if USB gadget support is built as a module, this causes a link > error (below) Kevin, usb_nop_xceiv_register() is defined at drivers/usb/otg/nop-usb-xceiv.c file which gets compiled if CONFIG_NOP_USB_XCEIV=y. I think you have enabled CONFIG_NOP_USB_XCEIV as module? Regards, Ajay > > This is obviously broken, and this hook needs to be fixed to work when > called as a module. > > To reproduce, start with omap3_defconfig and change both USB host > and gadget to be built as modules. > > Kevin > > > [...] > LD .tmp_vmlinux1 > arch/arm/mach-omap2/built-in.o: In function `omap3_evm_init': > /opt/home/khilman/work.local/kernel/omap/dev/arch/arm/mach-omap2/board- > omap3evm.c:686: undefined reference to `usb_nop_xceiv_register' > arch/arm/mach-omap2/built-in.o: In function `omap_4430sdp_init': > /opt/home/khilman/work.local/kernel/omap/dev/arch/arm/mach-omap2/board- > 4430sdp.c:143: undefined reference to `usb_nop_xceiv_register' > make[1]: *** [.tmp_vmlinux1] Error 1 > make: *** [sub-make] Error 2 > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
usb_nop_xceiv_register() missing when OTG built as modules
This just started happening with v2.6.33. On OMAP3EVM, usb_nop_xceiv_register() is called in the board file, but if USB gadget support is built as a module, this causes a link error (below) This is obviously broken, and this hook needs to be fixed to work when called as a module. To reproduce, start with omap3_defconfig and change both USB host and gadget to be built as modules. Kevin [...] LD .tmp_vmlinux1 arch/arm/mach-omap2/built-in.o: In function `omap3_evm_init': /opt/home/khilman/work.local/kernel/omap/dev/arch/arm/mach-omap2/board-omap3evm.c:686: undefined reference to `usb_nop_xceiv_register' arch/arm/mach-omap2/built-in.o: In function `omap_4430sdp_init': /opt/home/khilman/work.local/kernel/omap/dev/arch/arm/mach-omap2/board-4430sdp.c:143: undefined reference to `usb_nop_xceiv_register' make[1]: *** [.tmp_vmlinux1] Error 1 make: *** [sub-make] Error 2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] mmc: omap_hsmmc: Fix conditional locking
> -Original Message-
> From: Thomas Gleixner [mailto:t...@linutronix.de]
> Sent: Wednesday, March 03, 2010 4:16 AM
> To: Madhusudhan
> Cc: 'LKML'; linux-omap@vger.kernel.org; linux-...@vger.kernel.org
> Subject: RE: [PATCH] mmc: omap_hsmmc: Fix conditional locking
>
> On Tue, 2 Mar 2010, Madhusudhan wrote:
> > > Conditional locking on (!in_interrupt()) is broken by design and there
> > > is no reason to keep the host->irq_lock across the call to
> > > mmc_request_done(). Also the host->protect_card magic hack does not
> > > depend on the context
> > >
> >
> > Can you please elaborate why the existing logic is broken?
>
> Locks are only to be held to serialize data or state.
>
> The mmc_request_done() call does _NOT_ require that at all. So
> dropping the lock there is the right thing to do.
>
> Also conditional locking on in_interrupt() is generally a nono as it
> relies on assumptions which are not necessarily true in all
> circumstances. Just one simple example: interrupt threading will make
> it explode nicely and it did already with the realtime patches
> applied.
>
> Such code constructs prevent us to do generic changes to the kernel
> behaviour without any real good reason.
>
> > It locks at the new request and unlocks just before issuing the cmd.
> Further
> > IRQ handler has these calls hence the !in_interrupt check.
>
> Aside of the conditional locking I have several issues with that code:
>
> 1) The code flow is massively unreadable:
>
>omap_hsmmc_start_command()
>{
> .
> if (!in_interrupt())
> spin_unlock_irq();
>}
>
>omap_hsmmc_request()
>{
> if (!in_interrupt())
> spin_lock_irq();
>
> omap_hsmmc_start_command();
>}
>
> We generally want to see the lock/unlock pairs in one function and not
> having to figure out where the heck unlock happens.
>
> 2) The point of unlocking is patently wrong
>
>omap_hsmmc_start_command()
>{
> .
> if (!in_interrupt())
> spin_unlock_irq();
> --->
> OMAP_HSMMC_WRITE(host->base, ARG, cmd->arg);
> --->
> OMAP_HSMMC_WRITE(host->base, CMD, cmdreg);
>}
>
> What happens, if you get a spurious interrupt here ? Same for SMP,
> though you are probably protected by the core mmc code request
> serialization there.
>
> > How does this patch improve that? In fact with your patch for a data
> > transfer cmd there are several lock-unlock calls.
>
> 1) The patch simply removes conditional locking and moves the lock
>sections to those places which protect something. Aside of that it
>makes the code easier to understand.
>
> 2) What's the point of not having those lock/unlocks ? On UP the
>spinlock is a NOOP anyway, so you won't even notice. On SMP you
>won't notice either, simply because the lock is cache hot and
>almost never contended.
>
Sounds reasonable.Readbility is still a factor but works for me as the main
intention here is to remove the in_interrupt conditional.
Acked-by: Madhusudhan Chikkature
Best Regards,
Madhu
> Thanks,
>
> tglx
--
To unsubscribe from this list: send the line "unsubscribe 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: DMA: Init CDAC to Zero
Manjunatha GK writes:
> The register DMA4_CDAC needs to be initialized to zero
> before starting DMA transfer.
>
> Cc: Tony Lindgren
> Cc: Santosh Shilimkar
> Cc: Govindraj R
> Cc: Kevin Hilman
> Reported-by:S, Venkatraman
> Signed-off-by: Manjunatha GK
> ---
> It was aligned to reset CDAC to zero in omap_start_dma(int lch)
> instead of creating new API for accessing CDAC register.
>
> Discussion thread is at:
> http://patchwork.kernel.org/patch/83176/
> http://patchwork.kernel.org/patch/82948/
>
>
> arch/arm/plat-omap/dma.c |8
> 1 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
> index 2ab224c..96741d4 100644
> --- a/arch/arm/plat-omap/dma.c
> +++ b/arch/arm/plat-omap/dma.c
> @@ -936,6 +936,14 @@ void omap_start_dma(int lch)
> {
> u32 l;
>
> + /* CPC/CDAC register needs to be initialized to zero
> + * before starting dma transfer.
> + */
Please fix the multi-line comment style. Search for 'multi-line' in
Documentation/CodingStyle for details.
Kevin
> + if (cpu_is_omap15xx())
> + dma_write(0, CPC(lch));
> + else
> + dma_write(0, CDAC(lch));
> +
> if (!omap_dma_in_1510_mode() && dma_chan[lch].next_lch != -1) {
> int next_lch, cur_lch;
> char dma_chan_link_map[OMAP_DMA4_LOGICAL_DMA_CH_COUNT];
> --
> 1.6.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] omap3: Fix support for the LEDs connected to GPIO outputs on IGEP v2 board.
From: Enric Balletbo i Serra
Select CONFIG_LEDS_GPIO to enable IGEP v2 LED support and control of supported
LEDs from userspace. Otherwise GPIO LEDs are exported as GPIO 26, 27 and 28
using
the gpiolib framework.
Signed-off-by: Enric Balletbo i Serra
---
arch/arm/mach-omap2/board-igep0020.c | 54 ++---
1 files changed, 36 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index 26f65ca..19aaff0 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -16,7 +16,6 @@
#include
#include
#include
-#include
#include
#include
@@ -39,8 +38,8 @@
#define IGEP2_SMSC911X_CS 5
#define IGEP2_SMSC911X_GPIO 176
#define IGEP2_GPIO_USBH_NRESET 24
-#define IGEP2_GPIO_LED0_RED26
-#define IGEP2_GPIO_LED0_GREEN 27
+#define IGEP2_GPIO_LED0_GREEN 26
+#define IGEP2_GPIO_LED0_RED27
#define IGEP2_GPIO_LED1_RED28
#define IGEP2_GPIO_DVI_PUP 170
#define IGEP2_GPIO_WIFI_NPD94
@@ -355,34 +354,50 @@ static void __init igep2_display_init(void)
gpio_direction_output(IGEP2_GPIO_DVI_PUP, 1))
pr_err("IGEP v2: Could not obtain gpio GPIO_DVI_PUP\n");
}
-#ifdef CONFIG_LEDS_TRIGGERS
-static struct gpio_led gpio_leds[] = {
+
+#if defined(CONFIG_LEDS_GPIO) || defined(CONFIG_LEDS_GPIO_MODULE)
+#include
+
+static struct gpio_led igep2_gpio_leds[] = {
{
- .name = "GPIO_LED1_RED",
+ .name = "led0:red",
+ .gpio = IGEP2_GPIO_LED0_RED,
+ },
+ {
+ .name = "led0:green",
.default_trigger = "heartbeat",
+ .gpio = IGEP2_GPIO_LED0_GREEN,
+ },
+ {
+ .name = "led1:red",
.gpio = IGEP2_GPIO_LED1_RED,
},
};
-static struct gpio_led_platform_data gpio_leds_info = {
- .leds = gpio_leds,
- .num_leds = ARRAY_SIZE(gpio_leds),
+static struct gpio_led_platform_data igep2_led_pdata = {
+ .leds = igep2_gpio_leds,
+ .num_leds = ARRAY_SIZE(igep2_gpio_leds),
};
-static struct platform_device leds_gpio = {
+static struct platform_device igep2_led_device = {
.name = "leds-gpio",
.id = -1,
.dev= {
-.platform_data = &gpio_leds_info,
+.platform_data = &igep2_led_pdata,
},
};
+
+static void __init igep2_init_led(void)
+{
+ platform_device_register(&igep2_led_device);
+}
+
+#else
+static inline void igep2_init_led(void) {}
#endif
static struct platform_device *igep2_devices[] __initdata = {
&igep2_dss_device,
-#ifdef CONFIG_LEDS_TRIGGERS
- &leds_gpio,
-#endif
};
static void __init igep2_init_irq(void)
@@ -471,31 +486,34 @@ static void __init igep2_init(void)
usb_ehci_init(&ehci_pdata);
igep2_flash_init();
+ igep2_init_led();
igep2_display_init();
igep2_init_smsc911x();
/* GPIO userspace leds */
- if ((gpio_request(IGEP2_GPIO_LED0_RED, "GPIO_LED0_RED") == 0) &&
+#if !defined(CONFIG_LEDS_GPIO) && !defined(CONFIG_LEDS_GPIO_MODULE)
+ if ((gpio_request(IGEP2_GPIO_LED0_RED, "led0:red") == 0) &&
(gpio_direction_output(IGEP2_GPIO_LED0_RED, 1) == 0)) {
gpio_export(IGEP2_GPIO_LED0_RED, 0);
gpio_set_value(IGEP2_GPIO_LED0_RED, 0);
} else
pr_warning("IGEP v2: Could not obtain gpio GPIO_LED0_RED\n");
- if ((gpio_request(IGEP2_GPIO_LED0_GREEN, "GPIO_LED0_GREEN") == 0) &&
+ if ((gpio_request(IGEP2_GPIO_LED0_GREEN, "led0:green") == 0) &&
(gpio_direction_output(IGEP2_GPIO_LED0_GREEN, 1) == 0)) {
gpio_export(IGEP2_GPIO_LED0_GREEN, 0);
gpio_set_value(IGEP2_GPIO_LED0_GREEN, 0);
} else
pr_warning("IGEP v2: Could not obtain gpio GPIO_LED0_GREEN\n");
-#ifndef CONFIG_LEDS_TRIGGERS
- if ((gpio_request(IGEP2_GPIO_LED1_RED, "GPIO_LED1_RED") == 0) &&
+
+ if ((gpio_request(IGEP2_GPIO_LED1_RED, "led1:red") == 0) &&
(gpio_direction_output(IGEP2_GPIO_LED1_RED, 1) == 0)) {
gpio_export(IGEP2_GPIO_LED1_RED, 0);
gpio_set_value(IGEP2_GPIO_LED1_RED, 0);
} else
pr_warning("IGEP v2: Could not obtain gpio GPIO_LED1_RED\n");
#endif
+
/* GPIO W-LAN + Bluetooth combo module */
if ((gpio_request(IGEP2_GPIO_WIFI_NPD, "GPIO_WIFI_NPD") == 0) &&
(gpio_direction_output(IGEP2_GPIO_WIFI_NPD, 1) == 0)) {
--
1.5.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] omap3: Fix EHCI port for IGEP v2 board.
From: Enric Balletbo i Serra
IGEP v2 uses EHCI port 1 instead of EHCI port 2.
Signed-off-by: Enric Balletbo i Serra
---
arch/arm/mach-omap2/board-igep0020.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index 9958987..26f65ca 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -443,13 +443,13 @@ static struct omap_musb_board_data musb_board_data = {
};
static struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
- .port_mode[0] = EHCI_HCD_OMAP_MODE_UNKNOWN,
- .port_mode[1] = EHCI_HCD_OMAP_MODE_PHY,
+ .port_mode[0] = EHCI_HCD_OMAP_MODE_PHY,
+ .port_mode[1] = EHCI_HCD_OMAP_MODE_UNKNOWN,
.port_mode[2] = EHCI_HCD_OMAP_MODE_UNKNOWN,
.phy_reset = true,
- .reset_gpio_port[0] = -EINVAL,
- .reset_gpio_port[1] = IGEP2_GPIO_USBH_NRESET,
+ .reset_gpio_port[0] = IGEP2_GPIO_USBH_NRESET,
+ .reset_gpio_port[1] = -EINVAL,
.reset_gpio_port[2] = -EINVAL,
};
--
1.5.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP: mach-omap2/io.c: fix function declarations
Get rid of the following warnings:
warning: non-ANSI function declaration of function [...]
Signed-off-by: Aaro Koskinen
---
arch/arm/mach-omap2/io.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 402e8f0..ae89d55 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -237,7 +237,7 @@ static void __init _omap2_map_common_io(void)
}
#ifdef CONFIG_ARCH_OMAP2420
-void __init omap242x_map_common_io()
+void __init omap242x_map_common_io(void)
{
iotable_init(omap24xx_io_desc, ARRAY_SIZE(omap24xx_io_desc));
iotable_init(omap242x_io_desc, ARRAY_SIZE(omap242x_io_desc));
@@ -246,7 +246,7 @@ void __init omap242x_map_common_io()
#endif
#ifdef CONFIG_ARCH_OMAP2430
-void __init omap243x_map_common_io()
+void __init omap243x_map_common_io(void)
{
iotable_init(omap24xx_io_desc, ARRAY_SIZE(omap24xx_io_desc));
iotable_init(omap243x_io_desc, ARRAY_SIZE(omap243x_io_desc));
@@ -255,7 +255,7 @@ void __init omap243x_map_common_io()
#endif
#ifdef CONFIG_ARCH_OMAP3
-void __init omap34xx_map_common_io()
+void __init omap34xx_map_common_io(void)
{
iotable_init(omap34xx_io_desc, ARRAY_SIZE(omap34xx_io_desc));
_omap2_map_common_io();
@@ -263,7 +263,7 @@ void __init omap34xx_map_common_io()
#endif
#ifdef CONFIG_ARCH_OMAP4
-void __init omap44xx_map_common_io()
+void __init omap44xx_map_common_io(void)
{
iotable_init(omap44xx_io_desc, ARRAY_SIZE(omap44xx_io_desc));
_omap2_map_common_io();
--
1.5.6.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] omap: Fix gpio_resume_after_retention
For omap4 case, this was wrongly writing GPIO_LEVELDETECTx
registers with OMAP24XX_ offset and OMAP4_ offset.
Bug introduced in commit:
commit 3f1686a9bfe74979c6ad538c78039730f665f77e
Author: Tony Lindgren
Date: Mon Feb 15 09:27:25 2010 -0800
omap: Fix gpio.c for multi-omap for omap4
Signed-off-by: Sergio Aguirre
---
arch/arm/plat-omap/gpio.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index 337199e..76a347b 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -2140,18 +2140,18 @@ void omap2_gpio_resume_after_retention(void)
if (gen) {
u32 old0, old1;
- if (cpu_is_omap24xx() || cpu_is_omap44xx()) {
+ if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
old0 = __raw_readl(bank->base +
OMAP24XX_GPIO_LEVELDETECT0);
old1 = __raw_readl(bank->base +
OMAP24XX_GPIO_LEVELDETECT1);
- __raw_writel(old0 | gen, bank->base +
+ __raw_writel(old0 | gen, bank->base +
OMAP24XX_GPIO_LEVELDETECT0);
- __raw_writel(old1 | gen, bank->base +
+ __raw_writel(old1 | gen, bank->base +
OMAP24XX_GPIO_LEVELDETECT1);
- __raw_writel(old0, bank->base +
+ __raw_writel(old0, bank->base +
OMAP24XX_GPIO_LEVELDETECT0);
- __raw_writel(old1, bank->base +
+ __raw_writel(old1, bank->base +
OMAP24XX_GPIO_LEVELDETECT1);
}
--
1.6.3.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3: PM: Enable wake-up from McBSP2, 3 and 4 modules
On Wed, 3 Mar 2010 15:08:05 +0200 Peter Ujfalusi wrote: > Wake-up from McBSP ports are needed, especially when the THRESHOLD > dma mode is in use for audio playback. > > Signed-off-by: Peter Ujfalusi > --- > arch/arm/mach-omap2/pm34xx.c |8 ++-- > 1 files changed, 6 insertions(+), 2 deletions(-) > How about the commit e3d9329640e4b291cdd2c6d178774c28bba47d59 in mainline? -- Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 4/5] OMAP3: McBSP: Add interface for FIFO caused delay query
On Wed, 3 Mar 2010 15:08:08 +0200 Peter Ujfalusi wrote: > New functions for querying the FIFO caused delay on both > TX and RX path. > On TX path the return value shows the number of used > locations in the FIFO. > On RX papth it returns the number of locations to be filled > to reach the threshold value (DMA will be triggered to read > the data out from the FIFO). > Acked-by: Jarkko Nikula -- To unsubscribe from this list: send the line "unsubscribe 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 part1/2 merge][PATCH 08/10] omap3: 3630sdp: Explicitly enable all UARTs
> -Original Message-
> From: Aguirre, Sergio
> Sent: Wednesday, March 03, 2010 8:19 AM
> To: linux-omap@vger.kernel.org
> Cc: Aguirre, Sergio
> Subject: [RFC part1/2 merge][PATCH 08/10] omap3: 3630sdp: Explicitly
> enable all UARTs
>
> All UARTs seem physically reachable, so, enable them all.
>
> Signed-off-by: Sergio Aguirre
> ---
> arch/arm/mach-omap2/board-3630sdp.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
> mode change 100755 => 100644 arch/arm/mach-omap2/board-3630sdp.c
>
> diff --git a/arch/arm/mach-omap2/board-3630sdp.c b/arch/arm/mach-
> omap2/board-3630sdp.c
> old mode 100755
> new mode 100644
> index 4386d2b..35df894
> --- a/arch/arm/mach-omap2/board-3630sdp.c
> +++ b/arch/arm/mach-omap2/board-3630sdp.c
> @@ -96,6 +96,7 @@ static struct omap_board_mux board_mux[] __initdata = {
> static void __init omap_sdp_init(void)
> {
> omap3_mux_init(board_mux, OMAP_PACKAGE_CBP);
> + omap_serial_init_allports();
Oops, forgot to change this one.
Please take attached one instead.
Regards,
Sergio
> zoom_peripherals_init();
> board_smc91x_init();
> enable_board_wakeup_source();
> --
> 1.6.3.3
0008-omap3-3630sdp-Explicitly-enable-all-UARTs.patch
Description: 0008-omap3-3630sdp-Explicitly-enable-all-UARTs.patch
Re: [alsa-devel] [PATCHv2 5/5] ASoC: OMAP3: Report delay caused by the internal FIFO
On Wed, 03 Mar 2010 13:28:24 + Liam Girdwood wrote: > On Wed, 2010-03-03 at 15:08 +0200, Peter Ujfalusi wrote: > > Use the new delay calback function to report the delay through > > ALSA for application caused by the internal FIFO. > > > > Signed-off-by: Peter Ujfalusi > > --- > > Acked-by: Liam Girdwood Acked-by: Jarkko Nikula -- To unsubscribe from this list: send the line "unsubscribe 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] Add support for OMAP3Stalker boards
This patche add omap3 board support for the EMA-Tech StalkerBoards. Base on
TI's EVM.
>From ca9879de445ffa8063e79f43a715712eca9b335f Mon Sep 17 00:00:00 2001
From: Jason Lam
Date: Wed, 3 Mar 2010 10:04:36 +0800
Subject: [PATCH] Add support for OMAP3Stalker boards
Signed-off-by: Jason Lam
---
arch/arm/mach-omap2/Kconfig | 20 +
arch/arm/mach-omap2/Makefile |2 +
arch/arm/mach-omap2/board-omap3stalker.c | 922
++
3 files changed, 944 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-omap3stalker.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index a8a3d1e..50386c8 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -82,6 +82,26 @@ config MACH_OMAP3517EVM
depends on ARCH_OMAP3
select OMAP_PACKAGE_CBB
+config MACH_SBC3530
+ bool "OMAP3 SBC STALKER board"
+ depends on ARCH_OMAP3
+
+choice
+ prompt STALKER_BOARD_TYPE
+ depends on MACH_SBC3530
+ default STALKER_EVM
+
+config STALKER_BOARD_TYPE_EVM
+ bool "Stalker EVM board"
+ help
+ Select this option if you have a Stalker EVM board
+
+config STALKER_BOARD_TYPE_LK_S
+ bool "Stalker LK-S board"
+ help
+ Select this option if you have a Stalker LK-S board
+endchoice
+
config MACH_OMAP3_PANDORA
bool "OMAP3 Pandora"
depends on ARCH_OMAP3
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 2069fb3..51cfe4b 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -110,6 +110,8 @@ obj-$(CONFIG_MACH_OVERO)+= board-overo.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP3EVM)+= board-omap3evm.o \
hsmmc.o
+obj-$(CONFIG_MACH_SBC3530) += board-omap3stalker.o \
+ hsmmc.o
obj-$(CONFIG_MACH_OMAP3_PANDORA) += board-omap3pandora.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP_3430SDP)+= board-3430sdp.o \
diff --git a/arch/arm/mach-omap2/board-omap3stalker.c
b/arch/arm/mach-omap2/board-omap3stalker.c
new file mode 100644
index 000..bb70b46
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap3stalker.c
@@ -0,0 +1,922 @@
+/*
+ * linux/arch/arm/mach-omap2/board-omap3evm.c
+ *
+ * Copyright (C) 2008 Guangzhou EMA-Tech
+ *
+ * Modified from mach-omap2/board-omap3evm.c
+ *
+ * Initial code: Syed Mohammed Khasim
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#if defined(CONFIG_STALKER_BOARD_TYPE_EVM)
+#include
+#elif defined(CONFIG_STALKER_BOARD_TYPE_LK_S)
+#include
+#include
+#include
+#endif
+
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "mux.h"
+#include "sdram-micron-mt46h32m32lf-6.h"
+#include "hsmmc.h"
+#include "pm.h"
+
+static struct mtd_partition omap3stalker_nand_partitions[] = {
+ /* All the partition sizes are listed in terms of NAND block size */
+ {
+.name = "X-Loader",
+.offset = 0,
+.size = 4 * (SZ_128K),
+.mask_flags = MTD_WRITEABLE,
+},
+ {
+.name = "U-Boot",
+.offset = MTDPART_OFS_APPEND,
+.size = 15 * (SZ_128K),
+.mask_flags = MTD_WRITEABLE,
+},
+ {
+.name = "U-Boot Env",
+.offset = MTDPART_OFS_APPEND,
+.size = 1 * (SZ_128K)},
+ {
+.name = "Kernel",
+.offset = MTDPART_OFS_APPEND,
+.size = 32 * (SZ_128K)},
+ {
+.name = "File System",
+.size = MTDPART_SIZ_FULL,
+.offset = MTDPART_OFS_APPEND,
+},
+};
+
+static struct omap_nand_platform_data omap3stalker_nand_data = {
+ .parts = omap3stalker_nand_partitions,
+ .nr_parts = ARRAY_SIZE(omap3stalker_nand_partitions),
+ .nand_setup = NULL,
+ .dma_channel = -1, /* disable DMA in OMAP NAND driver */
+ .dev_ready = NULL,
+};
+
+static struct resource omap3stalker_nand_resource = {
+ .flags = IORESOURCE_MEM,
+};
+
+static struct platform_device omap3stalker_nand_device = {
+ .name = "omap2-nand",
+ .id = 0,
+ .dev = {
+ .platform_data = &omap3stalker_nand_data,
+ },
+ .num_resources = 1,
+ .resource = &omap3stalker_nand_resource,
+};
+
+void __init omap3stalker_flash_init(void)
+{
+ u8 cs = 0;
+ u8 nandcs = GPMC_CS_
[RFC part1/2 merge][PATCH 06/10] omap3: serial: Fix uart4 handling for 3630
This patch makes the following:
- Adds missing wakeup padding register handling.
- Fixes a hardcode to use PER module ONLY on UART3.
- Corrects IRQ number to 80 for 3630 case.
Signed-off-by: Sergio Aguirre
---
arch/arm/mach-omap2/serial.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 351ba62..c3bad91 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -444,7 +444,7 @@ static void omap_uart_idle_init(struct omap_uart_state
*uart)
omap_uart_smart_idle_enable(uart, 0);
if (cpu_is_omap34xx()) {
- u32 mod = (uart->num == 2) ? OMAP3430_PER_MOD : CORE_MOD;
+ u32 mod = (uart->num > 1) ? OMAP3430_PER_MOD : CORE_MOD;
u32 wk_mask = 0;
u32 padconf = 0;
@@ -463,6 +463,10 @@ static void omap_uart_idle_init(struct omap_uart_state
*uart)
wk_mask = OMAP3430_ST_UART3_MASK;
padconf = 0x19e;
break;
+ case 3:
+ wk_mask = OMAP3630_ST_UART4_MASK;
+ padconf = 0x0d2;
+ break;
}
uart->wk_mask = wk_mask;
uart->padconf = padconf;
@@ -694,6 +698,10 @@ void __init omap_serial_early_init(void)
if (cpu_is_omap44xx())
p->irq += 32;
+
+ /* IRQ for UART4 in omap3630 is 80 */
+ if (cpu_is_omap3630() && (i == 3))
+ p->irq = 80;
}
}
--
1.6.3.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC part1/2 merge][PATCH 08/10] omap3: 3630sdp: Explicitly enable all UARTs
All UARTs seem physically reachable, so, enable them all.
Signed-off-by: Sergio Aguirre
---
arch/arm/mach-omap2/board-3630sdp.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
mode change 100755 => 100644 arch/arm/mach-omap2/board-3630sdp.c
diff --git a/arch/arm/mach-omap2/board-3630sdp.c
b/arch/arm/mach-omap2/board-3630sdp.c
old mode 100755
new mode 100644
index 4386d2b..35df894
--- a/arch/arm/mach-omap2/board-3630sdp.c
+++ b/arch/arm/mach-omap2/board-3630sdp.c
@@ -96,6 +96,7 @@ static struct omap_board_mux board_mux[] __initdata = {
static void __init omap_sdp_init(void)
{
omap3_mux_init(board_mux, OMAP_PACKAGE_CBP);
+ omap_serial_init_allports();
zoom_peripherals_init();
board_smc91x_init();
enable_board_wakeup_source();
--
1.6.3.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC part1/2 merge][PATCH 09/10] omap3: zoom 2/3: Change debugboard serial port id
This is now changed to PLAT8250_DEV_PLATFORM (= 0), because
it is the only port that's going to be initted in Zoom 2/3 boards.
So, it doesn't make sense to keep the hardcoded 3 value anymore.
Signed-off-by: Sergio Aguirre
---
arch/arm/mach-omap2/board-zoom-debugboard.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom-debugboard.c
b/arch/arm/mach-omap2/board-zoom-debugboard.c
index bb4018b..e15d2e8 100644
--- a/arch/arm/mach-omap2/board-zoom-debugboard.c
+++ b/arch/arm/mach-omap2/board-zoom-debugboard.c
@@ -96,7 +96,7 @@ static struct plat_serial8250_port serial_platform_data[] = {
static struct platform_device zoom_debugboard_serial_device = {
.name = "serial8250",
- .id = 3,
+ .id = PLAT8250_DEV_PLATFORM,
.dev= {
.platform_data = serial_platform_data,
},
--
1.6.3.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC part1/2 merge][PATCH 10/10] omap3: zoom2/3: Register only 1 8250 port
There's no more serial ports available, so, doesn't make sense to create 4 device nodes. Signed-off-by: Sergio Aguirre --- arch/arm/configs/omap_zoom2_defconfig |2 +- arch/arm/configs/omap_zoom3_defconfig |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/configs/omap_zoom2_defconfig b/arch/arm/configs/omap_zoom2_defconfig index a82e813..3dfd2d5 100644 --- a/arch/arm/configs/omap_zoom2_defconfig +++ b/arch/arm/configs/omap_zoom2_defconfig @@ -660,7 +660,7 @@ CONFIG_DEVKMEM=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_NR_UARTS=32 -CONFIG_SERIAL_8250_RUNTIME_UARTS=4 +CONFIG_SERIAL_8250_RUNTIME_UARTS=1 CONFIG_SERIAL_8250_EXTENDED=y CONFIG_SERIAL_8250_MANY_PORTS=y CONFIG_SERIAL_8250_SHARE_IRQ=y diff --git a/arch/arm/configs/omap_zoom3_defconfig b/arch/arm/configs/omap_zoom3_defconfig index ff8ac3d..a1c0c43 100644 --- a/arch/arm/configs/omap_zoom3_defconfig +++ b/arch/arm/configs/omap_zoom3_defconfig @@ -680,7 +680,7 @@ CONFIG_DEVKMEM=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_NR_UARTS=32 -CONFIG_SERIAL_8250_RUNTIME_UARTS=4 +CONFIG_SERIAL_8250_RUNTIME_UARTS=1 CONFIG_SERIAL_8250_EXTENDED=y CONFIG_SERIAL_8250_MANY_PORTS=y CONFIG_SERIAL_8250_SHARE_IRQ=y -- 1.6.3.3 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC part1/2 merge][PATCH 05/10] OMAP3: PRCM: Consider UART4 for 3630 chip in prcm_setup_regs
Signed-off-by: Sergio Aguirre
---
arch/arm/mach-omap2/pm34xx.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index fee2efb..81082f2 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -734,6 +734,9 @@ static void __init omap3_d2d_idle(void)
static void __init prcm_setup_regs(void)
{
+ u32 omap3630_auto_uart4 = cpu_is_omap3630() ? OMAP3630_AUTO_UART4 : 0;
+ u32 omap3630_en_uart4 = cpu_is_omap3630() ? OMAP3630_EN_UART4 : 0;
+
/* XXX Reset all wkdeps. This should be done when initializing
* powerdomains */
prm_write_mod_reg(0, OMAP3430_IVA2_MOD, PM_WKDEP);
@@ -820,6 +823,7 @@ static void __init prcm_setup_regs(void)
CM_AUTOIDLE);
cm_write_mod_reg(
+ omap3630_auto_uart4 |
OMAP3430_AUTO_GPIO6 |
OMAP3430_AUTO_GPIO5 |
OMAP3430_AUTO_GPIO4 |
@@ -899,14 +903,14 @@ static void __init prcm_setup_regs(void)
OMAP3430_EN_GPIO4 | OMAP3430_EN_GPIO5 |
OMAP3430_EN_GPIO6 | OMAP3430_EN_UART3 |
OMAP3430_EN_MCBSP2 | OMAP3430_EN_MCBSP3 |
- OMAP3430_EN_MCBSP4,
+ OMAP3430_EN_MCBSP4 | omap3630_en_uart4,
OMAP3430_PER_MOD, PM_WKEN);
/* and allow them to wake up MPU */
prm_write_mod_reg(OMAP3430_GRPSEL_GPIO2 | OMAP3430_EN_GPIO3 |
OMAP3430_GRPSEL_GPIO4 | OMAP3430_EN_GPIO5 |
OMAP3430_GRPSEL_GPIO6 | OMAP3430_EN_UART3 |
OMAP3430_EN_MCBSP2 | OMAP3430_EN_MCBSP3 |
- OMAP3430_EN_MCBSP4,
+ OMAP3430_EN_MCBSP4 | omap3630_en_uart4,
OMAP3430_PER_MOD, OMAP3430_PM_MPUGRPSEL);
/* Don't attach IVA interrupts */
--
1.6.3.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC part1/2 merge][PATCH 02/10] omap2/3/4: serial: Remove condition for getting uart4_phys
This check is invalid, since we haven't filled the
omap_revision var at this point.
Signed-off-by: Sergio Aguirre
---
arch/arm/mach-omap2/serial.c | 14 +-
1 files changed, 1 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 1ca4330..351ba62 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -115,7 +115,6 @@ static struct plat_serial8250_port serial_platform_data2[]
= {
}
};
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
static struct plat_serial8250_port serial_platform_data3[] = {
{
.irq= 70,
@@ -128,23 +127,12 @@ static struct plat_serial8250_port
serial_platform_data3[] = {
}
};
-static inline void omap2_set_globals_uart4(struct omap_globals *omap2_globals)
-{
- serial_platform_data3[0].mapbase = omap2_globals->uart4_phys;
-}
-#else
-static inline void omap2_set_globals_uart4(struct omap_globals *omap2_globals)
-{
-}
-#endif
-
void __init omap2_set_globals_uart(struct omap_globals *omap2_globals)
{
serial_platform_data0[0].mapbase = omap2_globals->uart1_phys;
serial_platform_data1[0].mapbase = omap2_globals->uart2_phys;
serial_platform_data2[0].mapbase = omap2_globals->uart3_phys;
- if (cpu_is_omap3630() || cpu_is_omap44xx())
- omap2_set_globals_uart4(omap2_globals);
+ serial_platform_data3[0].mapbase = omap2_globals->uart4_phys;
}
static inline unsigned int __serial_read_reg(struct uart_port *up,
--
1.6.3.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC part1/2 merge][PATCH 07/10] omap3: zoom2/3 / 3630sdp: Don't init always all uarts
This is useless, since in Zoom2/3 boards, the ports aren't even
physically accessible.
They must be explicitly initted in the board-zoom2.c, board-zoom3.c
and board-3630sdp.c files instead.
Signed-off-by: Sergio Aguirre
---
arch/arm/mach-omap2/board-zoom-peripherals.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
mode change 100755 => 100644 arch/arm/mach-omap2/board-zoom-peripherals.c
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c
b/arch/arm/mach-omap2/board-zoom-peripherals.c
old mode 100755
new mode 100644
index ca95d8d..6b39849
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -280,7 +280,6 @@ static void enable_board_wakeup_source(void)
void __init zoom_peripherals_init(void)
{
omap_i2c_init();
- omap_serial_init();
usb_musb_init(&musb_board_data);
enable_board_wakeup_source();
}
--
1.6.3.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC part1/2 merge][PATCH 04/10] OMAP clock: Add uart4_ick/fck definitions for 3630
This is only valid for omap 36xx family of chips.
Signed-off-by: Sergio Aguirre
---
arch/arm/mach-omap2/clock3xxx_data.c | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index d5153b6..e8afaa6 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -2541,6 +2541,16 @@ static struct clk uart3_fck = {
.recalc = &followparent_recalc,
};
+static struct clk uart4_fck = {
+ .name = "uart4_fck",
+ .ops= &clkops_omap2_dflt_wait,
+ .parent = &per_48m_fck,
+ .enable_reg = OMAP_CM_REGADDR(OMAP3430_PER_MOD, CM_FCLKEN),
+ .enable_bit = OMAP3630_EN_UART4_SHIFT,
+ .clkdm_name = "per_clkdm",
+ .recalc = &followparent_recalc,
+};
+
static struct clk gpt2_fck = {
.name = "gpt2_fck",
.ops= &clkops_omap2_dflt_wait,
@@ -2791,6 +2801,16 @@ static struct clk uart3_ick = {
.recalc = &followparent_recalc,
};
+static struct clk uart4_ick = {
+ .name = "uart4_ick",
+ .ops= &clkops_omap2_dflt_wait,
+ .parent = &per_l4_ick,
+ .enable_reg = OMAP_CM_REGADDR(OMAP3430_PER_MOD, CM_ICLKEN),
+ .enable_bit = OMAP3630_EN_UART4_SHIFT,
+ .clkdm_name = "per_clkdm",
+ .recalc = &followparent_recalc,
+};
+
static struct clk gpt9_ick = {
.name = "gpt9_ick",
.ops= &clkops_omap2_dflt_wait,
@@ -3420,6 +3440,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, "per_96m_fck", &per_96m_fck, CK_3XXX),
CLK(NULL, "per_48m_fck", &per_48m_fck, CK_3XXX),
CLK(NULL, "uart3_fck",&uart3_fck, CK_3XXX),
+ CLK(NULL, "uart4_fck",&uart4_fck, CK_36XX),
CLK(NULL, "gpt2_fck", &gpt2_fck, CK_3XXX),
CLK(NULL, "gpt3_fck", &gpt3_fck, CK_3XXX),
CLK(NULL, "gpt4_fck", &gpt4_fck, CK_3XXX),
@@ -3443,6 +3464,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, "gpio2_ick",&gpio2_ick, CK_3XXX),
CLK(NULL, "wdt3_ick", &wdt3_ick, CK_3XXX),
CLK(NULL, "uart3_ick",&uart3_ick, CK_3XXX),
+ CLK(NULL, "uart4_ick",&uart4_ick, CK_36XX),
CLK(NULL, "gpt9_ick", &gpt9_ick, CK_3XXX),
CLK(NULL, "gpt8_ick", &gpt8_ick, CK_3XXX),
CLK(NULL, "gpt7_ick", &gpt7_ick, CK_3XXX),
--
1.6.3.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC part1/2 merge][PATCH 03/10] ARM: OMAP3630: PRCM: Add UART4 control bits
This bits are exclusive of omap 36xx family of chips. Signed-off-by: Sergio Aguirre --- arch/arm/mach-omap2/cm-regbits-34xx.h |2 ++ arch/arm/mach-omap2/prcm-common.h |4 2 files changed, 6 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/cm-regbits-34xx.h b/arch/arm/mach-omap2/cm-regbits-34xx.h index a3a3ca0..834b671 100644 --- a/arch/arm/mach-omap2/cm-regbits-34xx.h +++ b/arch/arm/mach-omap2/cm-regbits-34xx.h @@ -649,6 +649,8 @@ #define OMAP3430_ST_MCBSP2_MASK(1 << 0) /* CM_AUTOIDLE_PER */ +#define OMAP3630_AUTO_UART4(1 << 18) +#define OMAP3630_AUTO_UART4_SHIFT 18 #define OMAP3430_AUTO_GPIO6(1 << 17) #define OMAP3430_AUTO_GPIO6_SHIFT 17 #define OMAP3430_AUTO_GPIO5(1 << 16) diff --git a/arch/arm/mach-omap2/prcm-common.h b/arch/arm/mach-omap2/prcm-common.h index 90f603d..c4e7bcb 100644 --- a/arch/arm/mach-omap2/prcm-common.h +++ b/arch/arm/mach-omap2/prcm-common.h @@ -390,6 +390,8 @@ #define OMAP3430_EN_MPU_SHIFT 1 /* CM_FCLKEN_PER, CM_ICLKEN_PER, PM_WKEN_PER shared bits */ +#define OMAP3630_EN_UART4 (1 << 18) +#define OMAP3630_EN_UART4_SHIFT18 #define OMAP3430_EN_GPIO6 (1 << 17) #define OMAP3430_EN_GPIO6_SHIFT17 #define OMAP3430_EN_GPIO5 (1 << 16) @@ -430,6 +432,8 @@ #define OMAP3430_EN_MCBSP2_SHIFT 0 /* CM_IDLEST_PER, PM_WKST_PER shared bits */ +#define OMAP3630_ST_UART4_SHIFT18 +#define OMAP3630_ST_UART4_MASK (1 << 18) #define OMAP3430_ST_GPIO6_SHIFT17 #define OMAP3430_ST_GPIO6_MASK (1 << 17) #define OMAP3430_ST_GPIO5_SHIFT16 -- 1.6.3.3 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC part1/2 merge][PATCH 01/10] OMAP3: serial: Check for zero-based physical addr
This is for protecting a wrong mapping attempt of a zero-based
physical address.
The result is that, no serial port will be attempted to be mapped.
Also add an additional protection for NULL clocks before attempting
to enable them (if above condition applies)
Signed-off-by: Sergio Aguirre
---
arch/arm/mach-omap2/serial.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index da77930..1ca4330 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -664,6 +664,12 @@ void __init omap_serial_early_init(void)
struct device *dev = &pdev->dev;
struct plat_serial8250_port *p = dev->platform_data;
+ /* Don't map zero-based physical address */
+ if (p->mapbase == 0) {
+ printk(KERN_WARNING "omap serial: No physical address"
+ " for uart#%d, so skipping early_init...\n", i);
+ continue;
+ }
/*
* Module 4KB + L4 interconnect 4KB
* Static mapping, never released
@@ -727,6 +733,10 @@ void __init omap_serial_init_port(int port)
pdev = &uart->pdev;
dev = &pdev->dev;
+ /* Don't proceed if there's no clocks available */
+ if (!uart->ick || !uart->fck)
+ return;
+
omap_uart_enable_clocks(uart);
omap_uart_reset(uart);
--
1.6.3.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC part1/2 merge][PATCH 00/10] omap2/3/4: uart4 fixes + zoom2/3 changes
Hi, This is a merge of my previously posted RFC series [1] and [2], and is meant to be applied on top of Thomas's Patch [3]. Changelog compared to previous versions: - Series merged, as mentioned above. - Dropped omap_serial_init rename. - Added patch for zoom2/3 defconfig to init only one port. Please let me know your comments and thoughts. Thanks to: - Vikram Pandita - Paul Walmsley - Kevin Hilman - Manjunath Kondaiah For the feedback recieved so far. I really appreciate it. Regards, Sergio Detailed changelog: Sergio Aguirre (10): OMAP3: serial: Check for zero-based physical addr omap2/3/4: serial: Remove condition for getting uart4_phys ARM: OMAP3630: PRCM: Add UART4 control bits OMAP clock: Add uart4_ick/fck definitions for 3630 OMAP3: PRCM: Consider UART4 for 3630 chip in prcm_setup_regs omap3: serial: Fix uart4 handling for 3630 omap3: zoom2/3 / 3630sdp: Don't init always all uarts omap3: 3630sdp: Explicitly enable all UARTs omap3: zoom 2/3: Change debugboard serial port id omap3: zoom2/3: Register only 1 8250 port arch/arm/configs/omap_zoom2_defconfig|2 +- arch/arm/configs/omap_zoom3_defconfig|2 +- arch/arm/mach-omap2/board-3630sdp.c |1 + arch/arm/mach-omap2/board-zoom-debugboard.c |2 +- arch/arm/mach-omap2/board-zoom-peripherals.c |1 - arch/arm/mach-omap2/clock3xxx_data.c | 22 arch/arm/mach-omap2/cm-regbits-34xx.h|2 + arch/arm/mach-omap2/pm34xx.c |8 - arch/arm/mach-omap2/prcm-common.h|4 +++ arch/arm/mach-omap2/serial.c | 34 +++-- 10 files changed, 58 insertions(+), 20 deletions(-) mode change 100755 => 100644 arch/arm/mach-omap2/board-3630sdp.c mode change 100755 => 100644 arch/arm/mach-omap2/board-zoom-peripherals.c [1] http://marc.info/?l=linux-omap&m=126730356232287&w=2 [2] http://marc.info/?l=linux-omap&m=126746974103007&w=2 [3] http://marc.info/?l=linux-kernel&m=126709078514087&w=2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Smart Reflex Patch Fix
Hi All, I need some help I have the following problem my working environement is the beagleboard running android. After enabling the ondemand governor and running the (userspace-application) for a while the board prints the following: SR2:VDD autocomp is not active and simply halts!!!.. I thought of a solution by patching the linux kernel, however I dont know where to head.Can anyone please help? Thanks Best Regards Mai -- To unsubscribe from this list: send the line "unsubscribe 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] OMAP3: PM: Enable wake-up from McBSP2, 3 and 4 modules
On Wednesday 03 March 2010 15:08:05 Ujfalusi Peter (Nokia-D/Tampere) wrote: > Wake-up from McBSP ports are needed, especially when the THRESHOLD > dma mode is in use for audio playback. > > Signed-off-by: Peter Ujfalusi Hmmm, please disregard this patch, I have forgot to clean up the directory. This has been already taken for 2.6.33 kernel. Only the [PATCHv2] prefix is valid for this series. Sorry for the noise. -- Péter -- To unsubscribe from this list: send the line "unsubscribe 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: About multicore OMAP
> -Original Message- > From: Jacob john [mailto:jacob.joh...@gmail.com] > Sent: Wednesday, March 03, 2010 7:27 PM > To: Shilimkar, Santosh > Cc: linux-omap@vger.kernel.org > Subject: Re: About multicore OMAP > > On Thu, Feb 25, 2010 at 8:04 PM, Shilimkar, Santosh > wrote: > >> -Original Message- > >> From: Jacob john [mailto:jacob.joh...@gmail.com] > >> Sent: Thursday, February 25, 2010 7:58 PM > >> To: Shilimkar, Santosh > >> Cc: linux-omap@vger.kernel.org > >> Subject: Re: About multicore OMAP > >> > >> On Thu, Feb 25, 2010 at 7:45 PM, Shilimkar, Santosh > >> wrote: > >> >> -Original Message- > >> >> From: Jacob john [mailto:jacob.joh...@gmail.com] > >> >> Sent: Thursday, February 25, 2010 7:37 PM > >> >> To: Shilimkar, Santosh > >> >> Cc: linux-omap@vger.kernel.org > >> >> Subject: Re: About multicore OMAP > >> >> > >> >> On Wed, Feb 24, 2010 at 10:24 AM, Shilimkar, Santosh > >> >> wrote: > >> >> >> -Original Message- > >> >> >> From: Jacob john [mailto:jacob.joh...@gmail.com] > >> >> >> Sent: Wednesday, February 24, 2010 10:16 AM > >> >> >> To: Shilimkar, Santosh > >> >> >> Cc: linux-omap@vger.kernel.org > >> >> >> Subject: Re: About multicore OMAP > >> >> >> > >> >> >> On Tue, Feb 23, 2010 at 10:20 PM, Shilimkar, Santosh > >> >> >> wrote: > >> >> >> > John, > >> >> >> >> -Original Message- > >> >> >> >> From: linux-omap-ow...@vger.kernel.org > >> >> >> >> [mailto:linux-omap-ow...@vger.kernel.org] On > Behalf > >> Of > >> >> >> >> Shilimkar, Santosh > >> >> >> >> Sent: Tuesday, February 23, 2010 8:01 PM > >> >> >> >> To: Jacob john > >> >> >> >> Cc: linux-omap@vger.kernel.org > >> >> >> >> Subject: RE: About multicore OMAP > >> >> >> >> > >> >> >> >> > -Original Message- > >> >> >> >> > From: Jacob john [mailto:jacob.joh...@gmail.com] > >> >> >> >> > Sent: Tuesday, February 23, 2010 7:51 PM > >> >> >> >> > To: Shilimkar, Santosh > >> >> >> >> > Cc: linux-omap@vger.kernel.org > >> >> >> >> > Subject: Re: About multicore OMAP > >> >> >> >> > > >> >> >> >> > It's Blaze with two lcd's and pico, looks great. Can I have this > >> >> >> >> > linux-omap kernel running on OMAP4?, plus I'm looking for SMP > >> >> >> >> > benchmark results etc. > >> >> >> >> > > >> >> >> >> Linux-omap kernel with omap_4430sdp_defconfig will boot on blaze > >> >> >> >> with SMP. This > >> >> >> >> won't have lot of driver support as such currently. Also L2 cache > >> >> >> >> support is in > >> >> >> >> on the way to make it to mainline as well. You should be able to > >> >> >> >> play with this > >> >> >> >> with some basic benchmark test related to CPU. > >> >> >> >> > >> >> >> >> Display , Audio, Pico, keypad, touchscreeen etc drivers are > >> >> >> >> available with the > >> >> >> >> release and you should be able get more details from the TI > >> >> >> >> contact person who > >> >> >> >> gave you the blaze. You can also get the performance numbers from > >> >> >> >> same source > >> >> >> >> > >> >> >> > If you need the full kernel with all the drivers I mentioned > >> >> >> > above, you can use > >> >> >> > below git. > >> >> >> > http://dev.omapzoom.org/?p=integration/kernel-omap4.git;a=shortlog;h=refs/heads/L24.4 > >> >> >> > >> >> >> Good help so far.., wondering why two trees for OMAP4, tell me > >> >> >> the > >> >> >> diff b/n this list and the zoom. > >> >> >> is there a different mailing list for zoom? confusing... and I am > >> >> >> sorrythanks for the pointers > >> >> >> > >> >> > The mailing list is only one (Linux-omap). There is no difference. > >> >> > Linux-omap > >> >> > tree is almost mainline equivalent from omap4 point of view. The > >> >> > features are developed > >> >> > on the tree I mentioned above. The tested features will be > >> >> > up-streamed after rebasing > >> >> > one by one. You will find only upstreamed/lined-up features in > >> >> > linux-omap tree. > >> >> > > >> >> Thanks Sentosh for your help, what do you advise? you always wanted me > >> >> to go to zoom, so I don't have to pull from Linux-omap. > >> >> When I should use zoom and when I should come back to Linux-omap? > >> >> please clarify. Good way to ask "which is latest?" :) > >> >> I am sorry, I am confusedhelp me > >> >> > >> > The dev.omapzoom.org trees gets updated regularly with > >> > linux-omap/maininle. So basically > >> > it is ( Linux-omap-master + Additional drivers including IPC). So you > >> > can use the > >> > git available on dev.omapzoom.org. This will enable you to have all the > >> > drivers in > >> > one tree. > >> > >> Sounds great, appreciate this, TI gave Android kernel, so from > >> omapzoom I get Android kernel? > >> please share GIT url path for the same, any readme is there like > >> Linux-omap? thanks for your help > >> > > > Here is the link for the android git. > > http://dev.omapzoom.org/?p=vikram/omap3.git;a=shortlog;h=refs/heads/android-2.6.32-omap4 > Sentosh, can I have uboot link for omap4, thanks for your help. ht
Re: About multicore OMAP
On Thu, Feb 25, 2010 at 8:04 PM, Shilimkar, Santosh wrote: >> -Original Message- >> From: Jacob john [mailto:jacob.joh...@gmail.com] >> Sent: Thursday, February 25, 2010 7:58 PM >> To: Shilimkar, Santosh >> Cc: linux-omap@vger.kernel.org >> Subject: Re: About multicore OMAP >> >> On Thu, Feb 25, 2010 at 7:45 PM, Shilimkar, Santosh >> wrote: >> >> -Original Message- >> >> From: Jacob john [mailto:jacob.joh...@gmail.com] >> >> Sent: Thursday, February 25, 2010 7:37 PM >> >> To: Shilimkar, Santosh >> >> Cc: linux-omap@vger.kernel.org >> >> Subject: Re: About multicore OMAP >> >> >> >> On Wed, Feb 24, 2010 at 10:24 AM, Shilimkar, Santosh >> >> wrote: >> >> >> -Original Message- >> >> >> From: Jacob john [mailto:jacob.joh...@gmail.com] >> >> >> Sent: Wednesday, February 24, 2010 10:16 AM >> >> >> To: Shilimkar, Santosh >> >> >> Cc: linux-omap@vger.kernel.org >> >> >> Subject: Re: About multicore OMAP >> >> >> >> >> >> On Tue, Feb 23, 2010 at 10:20 PM, Shilimkar, Santosh >> >> >> wrote: >> >> >> > John, >> >> >> >> -Original Message- >> >> >> >> From: linux-omap-ow...@vger.kernel.org >> >> >> >> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf >> Of >> >> >> >> Shilimkar, Santosh >> >> >> >> Sent: Tuesday, February 23, 2010 8:01 PM >> >> >> >> To: Jacob john >> >> >> >> Cc: linux-omap@vger.kernel.org >> >> >> >> Subject: RE: About multicore OMAP >> >> >> >> >> >> >> >> > -Original Message- >> >> >> >> > From: Jacob john [mailto:jacob.joh...@gmail.com] >> >> >> >> > Sent: Tuesday, February 23, 2010 7:51 PM >> >> >> >> > To: Shilimkar, Santosh >> >> >> >> > Cc: linux-omap@vger.kernel.org >> >> >> >> > Subject: Re: About multicore OMAP >> >> >> >> > >> >> >> >> > It's Blaze with two lcd's and pico, looks great. Can I have this >> >> >> >> > linux-omap kernel running on OMAP4?, plus I'm looking for SMP >> >> >> >> > benchmark results etc. >> >> >> >> > >> >> >> >> Linux-omap kernel with omap_4430sdp_defconfig will boot on blaze >> >> >> >> with SMP. This >> >> >> >> won't have lot of driver support as such currently. Also L2 cache >> >> >> >> support is in >> >> >> >> on the way to make it to mainline as well. You should be able to >> >> >> >> play with this >> >> >> >> with some basic benchmark test related to CPU. >> >> >> >> >> >> >> >> Display , Audio, Pico, keypad, touchscreeen etc drivers are >> >> >> >> available with the >> >> >> >> release and you should be able get more details from the TI contact >> >> >> >> person who >> >> >> >> gave you the blaze. You can also get the performance numbers from >> >> >> >> same source >> >> >> >> >> >> >> > If you need the full kernel with all the drivers I mentioned above, >> >> >> > you can use >> >> >> > below git. >> >> >> > http://dev.omapzoom.org/?p=integration/kernel-omap4.git;a=shortlog;h=refs/heads/L24.4 >> >> >> >> >> >> Good help so far.., wondering why two trees for OMAP4, tell me the >> >> >> diff b/n this list and the zoom. >> >> >> is there a different mailing list for zoom? confusing... and I am >> >> >> sorrythanks for the pointers >> >> >> >> >> > The mailing list is only one (Linux-omap). There is no difference. >> >> > Linux-omap >> >> > tree is almost mainline equivalent from omap4 point of view. The >> >> > features are developed >> >> > on the tree I mentioned above. The tested features will be up-streamed >> >> > after rebasing >> >> > one by one. You will find only upstreamed/lined-up features in >> >> > linux-omap tree. >> >> > >> >> Thanks Sentosh for your help, what do you advise? you always wanted me >> >> to go to zoom, so I don't have to pull from Linux-omap. >> >> When I should use zoom and when I should come back to Linux-omap? >> >> please clarify. Good way to ask "which is latest?" :) >> >> I am sorry, I am confusedhelp me >> >> >> > The dev.omapzoom.org trees gets updated regularly with >> > linux-omap/maininle. So basically >> > it is ( Linux-omap-master + Additional drivers including IPC). So you can >> > use the >> > git available on dev.omapzoom.org. This will enable you to have all the >> > drivers in >> > one tree. >> >> Sounds great, appreciate this, TI gave Android kernel, so from >> omapzoom I get Android kernel? >> please share GIT url path for the same, any readme is there like >> Linux-omap? thanks for your help >> > > Here is the link for the android git. > http://dev.omapzoom.org/?p=vikram/omap3.git;a=shortlog;h=refs/heads/android-2.6.32-omap4 Sentosh, can I have uboot link for omap4, thanks for your help. > > > Regards, > Santosh > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP: Zoom3: Fix Zoom3 booting issue
> -Original Message- > From: G, Manjunath Kondaiah > Sent: Wednesday, March 03, 2010 7:39 AM > To: Aguirre, Sergio; linux-omap@vger.kernel.org > Cc: Tony Lindgren; Shilimkar, Santosh; Raja, Govindraj > Subject: RE: [PATCH] OMAP: Zoom3: Fix Zoom3 booting issue > > > > > > To update further, it seems to be working on zoom3 with ttyS0 > > > with following combination of patches: > > > > > > 1. > > > [RFC,part2,v1,4/4] omap3: zoom 2/3: Change debugboard serial port id > > > [RFC,part2,v1,3/4] omap3: 3630sdp: Explicitly enable all UARTs > > > [RFC,part2,v1,2/4] omap3: zoom2/3 / 3630sdp: Don't init > > always all uarts > > > [RFC,part2,v1,1/4] omap2/3/4: serial: rename omap_serial_init > > > > > > 2. > > > [RESEND,PATCH/RFC] OMAP2: serial.c: Fix number of uarts in > > early_init > > > > > > 3. > > > [RFC,v3,6/6] omap3: serial: Fix uart4 handling for 3630 > > > [RFC,v3,5/6] OMAP3: PRCM: Consider UART4 for 3630 chip in > > prcm_setup_regs > > > [RFC,v3,4/6] OMAP clock: Add uart4_ick/fck definitions for 3630 > > > [RFC,v3,3/6] ARM: OMAP3630: PRCM: Add UART4 control bits > > > [RFC,v3,2/6] omap2/3/4: serial: Remove condition for > > getting uart4_phys > > > [RFC,v3,1/6] OMAP3: serial: Check for zero-based physical addr > > > > Yeah, that should be the total patchlist applied. > > > > I'm assuming you're applying from bottom to top order in your > > list above... > > Yes. But, you will be dropping v1 part2 series right? I'll just drop patch #0001 in that series, and resend. Actually, I'll group the 2 series and resend in a single batch, just to be clear on the dependency between them. Regards, Sergio > > Regards, > Manjunath -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP: Zoom3: Fix Zoom3 booting issue
> > To update further, it seems to be working on zoom3 with ttyS0 > > with following combination of patches: > > > > 1. > > [RFC,part2,v1,4/4] omap3: zoom 2/3: Change debugboard serial port id > > [RFC,part2,v1,3/4] omap3: 3630sdp: Explicitly enable all UARTs > > [RFC,part2,v1,2/4] omap3: zoom2/3 / 3630sdp: Don't init > always all uarts > > [RFC,part2,v1,1/4] omap2/3/4: serial: rename omap_serial_init > > > > 2. > > [RESEND,PATCH/RFC] OMAP2: serial.c: Fix number of uarts in > early_init > > > > 3. > > [RFC,v3,6/6] omap3: serial: Fix uart4 handling for 3630 > > [RFC,v3,5/6] OMAP3: PRCM: Consider UART4 for 3630 chip in > prcm_setup_regs > > [RFC,v3,4/6] OMAP clock: Add uart4_ick/fck definitions for 3630 > > [RFC,v3,3/6] ARM: OMAP3630: PRCM: Add UART4 control bits > > [RFC,v3,2/6] omap2/3/4: serial: Remove condition for > getting uart4_phys > > [RFC,v3,1/6] OMAP3: serial: Check for zero-based physical addr > > Yeah, that should be the total patchlist applied. > > I'm assuming you're applying from bottom to top order in your > list above... Yes. But, you will be dropping v1 part2 series right? Regards, Manjunath-- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 0/5] FIFO caused playback delay (latency) handling in soc/omap
On Wed, Mar 03, 2010 at 03:08:03PM +0200, Peter Ujfalusi wrote: > Peter Ujfalusi (5): > ASoC: core: fix tailing whitespace in soc_pcm_apply_symmetry > ASoC: core: soc level wrapper for pcm_pointer callback > ASoC: core: Add delay operation to snd_soc_dai_ops I'll apply these just now, thanks! > OMAP3: McBSP: Add interface for FIFO caused delay query > ASoC: OMAP3: Report delay caused by the internal FIFO These also look OK to me but there's the arch/arm dependency. -- To unsubscribe from this list: send the line "unsubscribe 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: Zoom3: Fix Zoom3 booting issue
> -Original Message- > From: G, Manjunath Kondaiah > Sent: Wednesday, March 03, 2010 12:38 AM > To: G, Manjunath Kondaiah; Aguirre, Sergio; linux-omap@vger.kernel.org > Cc: Tony Lindgren; Shilimkar, Santosh; Raja, Govindraj > Subject: RE: [PATCH] OMAP: Zoom3: Fix Zoom3 booting issue > > > > > > -Original Message- > > From: G, Manjunath Kondaiah > > Sent: Wednesday, March 03, 2010 11:31 AM > > To: Aguirre, Sergio; linux-omap@vger.kernel.org > > Cc: Tony Lindgren; Shilimkar, Santosh; Raja, Govindraj > > Subject: RE: [PATCH] OMAP: Zoom3: Fix Zoom3 booting issue > > > > Sergio, > > > > > -Original Message- > > > From: Aguirre, Sergio > > > Sent: Tuesday, March 02, 2010 9:41 PM > > > To: G, Manjunath Kondaiah; linux-omap@vger.kernel.org > > > Cc: G, Manjunath Kondaiah; Tony Lindgren; Shilimkar, Santosh; > > > Raja, Govindraj > > > Subject: RE: [PATCH] OMAP: Zoom3: Fix Zoom3 booting issue > > > > > > Manju, > > > > > > > -Original Message- > > > > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > > > > ow...@vger.kernel.org] On Behalf Of Manjunatha GK > > > > Sent: Tuesday, March 02, 2010 7:36 AM > > > > To: linux-omap@vger.kernel.org > > > > Cc: G, Manjunath Kondaiah; Tony Lindgren; Shilimkar, > > Santosh; Raja, > > > > Govindraj > > > > Subject: [PATCH] OMAP: Zoom3: Fix Zoom3 booting issue > > > > > > > > The commit id "5550bc33a1a9002976022cc794fe8c52ad9a0021" > > seems to be > > > > broken > > > > zoom3 boot which adds support for UART4 on OMAP4 and OMAP3630. > > > > > > > > But, it looks like OMAP3630 UART4 interface and functional > > > clock nodes > > > > needs > > > > to be added for omap3630. Thus limiting no. of UART's for > > > 3630 to 3 to > > > > prevent > > > > boot up issues until clock nodes are added for UART4 on OMAP3630. > > > > > > I already tried a similar patch here: > > > > > > http://patchwork.kernel.org/patch/81692/ > > > > > > But as it is really not solving anything, and Tony rejected > > > it, I started working on the needed bits to get UART4 > > > enabled, therefore I have came up with this patch series: > > > > > > - [RFC v3][PATCH 0/6] OMAP3630: UART4 startup (+ new bugfix!) [1] > > > > > > Also, I'm working in my spare time on a cleanup proposal [2], > > > which I'll repost today, given some comments from Kevin. > > > > > > So, if you want to boot, take series [1] and [2], and then > > > you should be able to boot with ttyS0. > > > > Sergio, did you test this combination on zoom3? It seems to > > be not working > > on zoom3 with ttyS0 and also with ttyS3. > > > > Where as, reducing number of uarts(for 3630) to 3 seems to > > working fine for > > ttyS3 on zoom3. > > To update further, it seems to be working on zoom3 with ttyS0 > with following combination of patches: > > 1. > [RFC,part2,v1,4/4] omap3: zoom 2/3: Change debugboard serial port id > [RFC,part2,v1,3/4] omap3: 3630sdp: Explicitly enable all UARTs > [RFC,part2,v1,2/4] omap3: zoom2/3 / 3630sdp: Don't init always all uarts > [RFC,part2,v1,1/4] omap2/3/4: serial: rename omap_serial_init > > 2. > [RESEND,PATCH/RFC] OMAP2: serial.c: Fix number of uarts in early_init > > 3. > [RFC,v3,6/6] omap3: serial: Fix uart4 handling for 3630 > [RFC,v3,5/6] OMAP3: PRCM: Consider UART4 for 3630 chip in prcm_setup_regs > [RFC,v3,4/6] OMAP clock: Add uart4_ick/fck definitions for 3630 > [RFC,v3,3/6] ARM: OMAP3630: PRCM: Add UART4 control bits > [RFC,v3,2/6] omap2/3/4: serial: Remove condition for getting uart4_phys > [RFC,v3,1/6] OMAP3: serial: Check for zero-based physical addr Yeah, that should be the total patchlist applied. I'm assuming you're applying from bottom to top order in your list above... Regards, Sergio > > -Manjunath -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [PATCHv2 5/5] ASoC: OMAP3: Report delay caused by the internal FIFO
On Wed, 2010-03-03 at 15:08 +0200, Peter Ujfalusi wrote: > Use the new delay calback function to report the delay through > ALSA for application caused by the internal FIFO. > > Signed-off-by: Peter Ujfalusi > --- Acked-by: Liam Girdwood -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk -- To unsubscribe from this list: send the line "unsubscribe 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: [alsa-devel] [PATCHv2 3/5] ASoC: core: Add delay operation to snd_soc_dai_ops
On Wed, 2010-03-03 at 15:08 +0200, Peter Ujfalusi wrote: > The delay callback can be used by the core to query the delay > on the dai caused by FIFO or delay in the platform side. > In case if both CPU and CODEC dai has FIFO the delay reported > by each will be added to form the full delay on the chain. > If none of the dai has FIFO, than the delay will be kept as > zero. > > Signed-off-by: Peter Ujfalusi Acked-by: Liam Girdwood -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk -- To unsubscribe from this list: send the line "unsubscribe 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: [alsa-devel] [PATCHv2 2/5] ASoC: core: soc level wrapper for pcm_pointer callback
On Wed, 2010-03-03 at 15:08 +0200, Peter Ujfalusi wrote: > Create a soc level wrapper for pcm_pointer callback. > This will facilitate the soc level handling of different > HW buffers in the audio path. > > Signed-off-by: Peter Ujfalusi Acked-by: Liam Girdwood -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk -- To unsubscribe from this list: send the line "unsubscribe 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: [alsa-devel] [PATCHv2 1/5] ASoC: core: fix tailing whitespace in soc_pcm_apply_symmetry
On Wed, 2010-03-03 at 15:08 +0200, Peter Ujfalusi wrote: > My editor removes the tailing spaces, which causes problems when > changing the soc-core.c > Removing the space. > > Signed-off-by: Peter Ujfalusi Acked-by: Liam Girdwood -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 1/5] ASoC: core: fix tailing whitespace in soc_pcm_apply_symmetry
My editor removes the tailing spaces, which causes problems when
changing the soc-core.c
Removing the space.
Signed-off-by: Peter Ujfalusi
---
sound/soc/soc-core.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index a03bac9..37c872e 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -315,7 +315,7 @@ static int soc_pcm_apply_symmetry(struct snd_pcm_substream
*substream)
if (codec_dai->symmetric_rates || cpu_dai->symmetric_rates ||
machine->symmetric_rates) {
- dev_dbg(card->dev, "Symmetry forces %dHz rate\n",
+ dev_dbg(card->dev, "Symmetry forces %dHz rate\n",
machine->rate);
ret = snd_pcm_hw_constraint_minmax(substream->runtime,
--
1.7.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
[PATCHv2 0/5] FIFO caused playback delay (latency) handling in soc/omap
Hello, Changes since the RFC round on the alsa-devel list: - core is not limiting the query for the delay to the playback stream. It is no the dai and platform driver's responsibility handle that - delay interface added for platform driver - Capture path delay calculation is added to OMAP McBSP. - omap_mcbsp_get_tx_buffstat renamed as omap_mcbsp_get_tx_delay to reflect what it is actually doing. Tony: is it still possible to get this taken for 2.6.34? It would be nice to avoid cross tree problems during the 34 cycle... The initial RFC patch description: There has been discussion in alsa-devel in this subject several times, but no actual patches has been sent (it was not soc related, but anyway it was discussed). Based on the available information the latency caused by the HW buffer on some systems can be handled by updating the runtime->delay. It has been discussed, that the runtime->delay can also be updated dynamically to show more accurate delay. To further complicate things, in ASoC we could have more buffer in the chain. To handle this we need soc level support. This series tries to do that in soc by: - introducing a pcm_pointer wrapper - in this wrapper we call the original pcm_pointer functions to get the DMA pointer - introducing a new interface in dai_ops and for platfrom drivers to ask the delay - adding the cpu_dai, codec_dai and platform driver returned delay to form the actual delay - update the runtime->delay with this value. With this approach none of the existing drivers need change, but they can add support for specifying the FIFO caused delay. In this series on top of the core changes the omap(3) code is updated to take this delay reporting into use. I have not added the support to the tlv320dac33 codec driver, since it needs a bit more work, but along the same line it can be done, and if the tlv320dac33 is hooked to omap McBSP than applications can know the whole delay/latency on that path. The series is based on linux-omap master branch (with regcache and sidetone). However the first 3 patch for soc core applies on top of sound-2.6 topic/asoc cleanly as well. Obviously the last patch depends on the OMAP platform patch. --- Peter Ujfalusi (5): ASoC: core: fix tailing whitespace in soc_pcm_apply_symmetry ASoC: core: soc level wrapper for pcm_pointer callback ASoC: core: Add delay operation to snd_soc_dai_ops OMAP3: McBSP: Add interface for FIFO caused delay query ASoC: OMAP3: Report delay caused by the internal FIFO arch/arm/plat-omap/include/plat/mcbsp.h |6 +++ arch/arm/plat-omap/mcbsp.c | 55 +++ include/sound/soc-dai.h |6 +++ include/sound/soc.h |7 sound/soc/omap/omap-mcbsp.c | 26 ++ sound/soc/soc-core.c| 39 +- 6 files changed, 137 insertions(+), 2 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] OMAP3: PM: Enable wake-up from McBSP2, 3 and 4 modules
Wake-up from McBSP ports are needed, especially when the THRESHOLD dma mode is in use for audio playback. Signed-off-by: Peter Ujfalusi --- arch/arm/mach-omap2/pm34xx.c |8 ++-- 1 files changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index 81ed252..6b17647 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -878,12 +878,16 @@ static void __init prcm_setup_regs(void) /* Enable wakeups in PER */ prm_write_mod_reg(OMAP3430_EN_GPIO2 | OMAP3430_EN_GPIO3 | OMAP3430_EN_GPIO4 | OMAP3430_EN_GPIO5 | - OMAP3430_EN_GPIO6 | OMAP3430_EN_UART3, + OMAP3430_EN_GPIO6 | OMAP3430_EN_UART3 | + OMAP3430_EN_MCBSP2 | OMAP3430_EN_MCBSP3 | + OMAP3430_EN_MCBSP4, OMAP3430_PER_MOD, PM_WKEN); /* and allow them to wake up MPU */ prm_write_mod_reg(OMAP3430_GRPSEL_GPIO2 | OMAP3430_EN_GPIO3 | OMAP3430_GRPSEL_GPIO4 | OMAP3430_EN_GPIO5 | - OMAP3430_GRPSEL_GPIO6 | OMAP3430_EN_UART3, + OMAP3430_GRPSEL_GPIO6 | OMAP3430_EN_UART3 | + OMAP3430_EN_MCBSP2 | OMAP3430_EN_MCBSP3 | + OMAP3430_EN_MCBSP4, OMAP3430_PER_MOD, OMAP3430_PM_MPUGRPSEL); /* Don't attach IVA interrupts */ -- 1.6.5.3 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 2/5] ASoC: core: soc level wrapper for pcm_pointer callback
Create a soc level wrapper for pcm_pointer callback.
This will facilitate the soc level handling of different
HW buffers in the audio path.
Signed-off-by: Peter Ujfalusi
---
sound/soc/soc-core.c | 19 ++-
1 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index 37c872e..de5223d 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -797,6 +797,23 @@ static int soc_pcm_trigger(struct snd_pcm_substream
*substream, int cmd)
return 0;
}
+/*
+ * soc level wrapper for pointer callback
+ */
+static snd_pcm_uframes_t soc_pcm_pointer(struct snd_pcm_substream *substream)
+{
+ struct snd_soc_pcm_runtime *rtd = substream->private_data;
+ struct snd_soc_device *socdev = rtd->socdev;
+ struct snd_soc_card *card = socdev->card;
+ struct snd_soc_platform *platform = card->platform;
+ snd_pcm_uframes_t offset = 0;
+
+ if (platform->pcm_ops->pointer)
+ offset = platform->pcm_ops->pointer(substream);
+
+ return offset;
+}
+
/* ASoC PCM operations */
static struct snd_pcm_ops soc_pcm_ops = {
.open = soc_pcm_open,
@@ -805,6 +822,7 @@ static struct snd_pcm_ops soc_pcm_ops = {
.hw_free= soc_pcm_hw_free,
.prepare= soc_pcm_prepare,
.trigger= soc_pcm_trigger,
+ .pointer= soc_pcm_pointer,
};
#ifdef CONFIG_PM
@@ -1331,7 +1349,6 @@ static int soc_new_pcm(struct snd_soc_device *socdev,
dai_link->pcm = pcm;
pcm->private_data = rtd;
soc_pcm_ops.mmap = platform->pcm_ops->mmap;
- soc_pcm_ops.pointer = platform->pcm_ops->pointer;
soc_pcm_ops.ioctl = platform->pcm_ops->ioctl;
soc_pcm_ops.copy = platform->pcm_ops->copy;
soc_pcm_ops.silence = platform->pcm_ops->silence;
--
1.7.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
[PATCHv2 4/5] OMAP3: McBSP: Add interface for FIFO caused delay query
New functions for querying the FIFO caused delay on both
TX and RX path.
On TX path the return value shows the number of used
locations in the FIFO.
On RX papth it returns the number of locations to be filled
to reach the threshold value (DMA will be triggered to read
the data out from the FIFO).
Signed-off-by: Peter Ujfalusi
---
arch/arm/plat-omap/include/plat/mcbsp.h |6 +++
arch/arm/plat-omap/mcbsp.c | 55 +++
2 files changed, 61 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/mcbsp.h
b/arch/arm/plat-omap/include/plat/mcbsp.h
index 3974835..1bd7021 100644
--- a/arch/arm/plat-omap/include/plat/mcbsp.h
+++ b/arch/arm/plat-omap/include/plat/mcbsp.h
@@ -149,6 +149,8 @@
#define OMAP_MCBSP_REG_WAKEUPEN0xA8
#define OMAP_MCBSP_REG_XCCR0xAC
#define OMAP_MCBSP_REG_RCCR0xB0
+#define OMAP_MCBSP_REG_XBUFFSTAT 0xB4
+#define OMAP_MCBSP_REG_RBUFFSTAT 0xB8
#define OMAP_MCBSP_REG_SSELCR 0xBC
#define OMAP_ST_REG_REV0x00
@@ -471,6 +473,8 @@ void omap_mcbsp_set_tx_threshold(unsigned int id, u16
threshold);
void omap_mcbsp_set_rx_threshold(unsigned int id, u16 threshold);
u16 omap_mcbsp_get_max_tx_threshold(unsigned int id);
u16 omap_mcbsp_get_max_rx_threshold(unsigned int id);
+u16 omap_mcbsp_get_tx_delay(unsigned int id);
+u16 omap_mcbsp_get_rx_delay(unsigned int id);
int omap_mcbsp_get_dma_op_mode(unsigned int id);
#else
static inline void omap_mcbsp_set_tx_threshold(unsigned int id, u16 threshold)
@@ -479,6 +483,8 @@ static inline void omap_mcbsp_set_rx_threshold(unsigned int
id, u16 threshold)
{ }
static inline u16 omap_mcbsp_get_max_tx_threshold(unsigned int id) { return 0;
}
static inline u16 omap_mcbsp_get_max_rx_threshold(unsigned int id) { return 0;
}
+static inline u16 omap_mcbsp_get_tx_delay(unsigned int id) { return 0; }
+static inline u16 omap_mcbsp_get_rx_delay(unsigned int id) { return 0; }
static inline int omap_mcbsp_get_dma_op_mode(unsigned int id) { return 0; }
#endif
int omap_mcbsp_request(unsigned int id);
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index e47686e..5e6d309 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -561,6 +561,61 @@ u16 omap_mcbsp_get_max_rx_threshold(unsigned int id)
}
EXPORT_SYMBOL(omap_mcbsp_get_max_rx_threshold);
+#define MCBSP2_FIFO_SIZE 0x500 /* 1024 + 256 locations */
+#define MCBSP1345_FIFO_SIZE0x80 /* 128 locations */
+/*
+ * omap_mcbsp_get_tx_delay returns the number of used slots in the McBSP FIFO
+ */
+u16 omap_mcbsp_get_tx_delay(unsigned int id)
+{
+ struct omap_mcbsp *mcbsp;
+ u16 buffstat;
+
+ if (!omap_mcbsp_check_valid_id(id)) {
+ printk(KERN_ERR "%s: Invalid id (%d)\n", __func__, id + 1);
+ return -ENODEV;
+ }
+ mcbsp = id_to_mcbsp_ptr(id);
+
+ /* Returns the number of free locations in the buffer */
+ buffstat = MCBSP_READ(mcbsp, XBUFFSTAT);
+
+ /* Number of slots are different in McBSP ports */
+ if (mcbsp->id == 2)
+ return MCBSP2_FIFO_SIZE - buffstat;
+ else
+ return MCBSP1345_FIFO_SIZE - buffstat;
+}
+EXPORT_SYMBOL(omap_mcbsp_get_tx_delay);
+
+/*
+ * omap_mcbsp_get_rx_delay returns the number of free slots in the McBSP FIFO
+ * to reach the threshold value (when the DMA will be triggered to read it)
+ */
+u16 omap_mcbsp_get_rx_delay(unsigned int id)
+{
+ struct omap_mcbsp *mcbsp;
+ u16 buffstat, threshold;
+
+ if (!omap_mcbsp_check_valid_id(id)) {
+ printk(KERN_ERR "%s: Invalid id (%d)\n", __func__, id + 1);
+ return -ENODEV;
+ }
+ mcbsp = id_to_mcbsp_ptr(id);
+
+ /* Returns the number of used locations in the buffer */
+ buffstat = MCBSP_READ(mcbsp, RBUFFSTAT);
+ /* RX threshold */
+ threshold = MCBSP_READ(mcbsp, THRSH1);
+
+ /* Return the number of location till we reach the threshold limit */
+ if (threshold <= buffstat)
+ return 0;
+ else
+ return threshold - buffstat;
+}
+EXPORT_SYMBOL(omap_mcbsp_get_rx_delay);
+
/*
* omap_mcbsp_get_dma_op_mode just return the current configured
* operating mode for the mcbsp channel
--
1.7.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
[PATCHv2 3/5] ASoC: core: Add delay operation to snd_soc_dai_ops
The delay callback can be used by the core to query the delay
on the dai caused by FIFO or delay in the platform side.
In case if both CPU and CODEC dai has FIFO the delay reported
by each will be added to form the full delay on the chain.
If none of the dai has FIFO, than the delay will be kept as
zero.
Signed-off-by: Peter Ujfalusi
---
include/sound/soc-dai.h |6 ++
include/sound/soc.h |7 +++
sound/soc/soc-core.c| 18 ++
3 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/include/sound/soc-dai.h b/include/sound/soc-dai.h
index 061f16d..be9cd47 100644
--- a/include/sound/soc-dai.h
+++ b/include/sound/soc-dai.h
@@ -182,6 +182,12 @@ struct snd_soc_dai_ops {
struct snd_soc_dai *);
int (*trigger)(struct snd_pcm_substream *, int,
struct snd_soc_dai *);
+ /*
+* For hardware based FIFO caused delay reporting.
+* Optional.
+*/
+ snd_pcm_sframes_t (*delay)(struct snd_pcm_substream *,
+ struct snd_soc_dai *);
};
/*
diff --git a/include/sound/soc.h b/include/sound/soc.h
index 5d234a8..c010824 100644
--- a/include/sound/soc.h
+++ b/include/sound/soc.h
@@ -469,6 +469,13 @@ struct snd_soc_platform {
struct snd_pcm *);
void (*pcm_free)(struct snd_pcm *);
+ /*
+* For platform caused delay reporting.
+* Optional.
+*/
+ snd_pcm_sframes_t (*delay)(struct snd_pcm_substream *,
+ struct snd_soc_dai *);
+
/* platform stream ops */
struct snd_pcm_ops *pcm_ops;
};
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index de5223d..e9c2dc1 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -799,6 +799,8 @@ static int soc_pcm_trigger(struct snd_pcm_substream
*substream, int cmd)
/*
* soc level wrapper for pointer callback
+ * If cpu_dai, codec_dai, platform driver has the delay callback, than
+ * the runtime->delay will be updated accordingly.
*/
static snd_pcm_uframes_t soc_pcm_pointer(struct snd_pcm_substream *substream)
{
@@ -806,11 +808,27 @@ static snd_pcm_uframes_t soc_pcm_pointer(struct
snd_pcm_substream *substream)
struct snd_soc_device *socdev = rtd->socdev;
struct snd_soc_card *card = socdev->card;
struct snd_soc_platform *platform = card->platform;
+ struct snd_soc_dai_link *machine = rtd->dai;
+ struct snd_soc_dai *cpu_dai = machine->cpu_dai;
+ struct snd_soc_dai *codec_dai = machine->codec_dai;
+ struct snd_pcm_runtime *runtime = substream->runtime;
snd_pcm_uframes_t offset = 0;
+ snd_pcm_sframes_t delay = 0;
if (platform->pcm_ops->pointer)
offset = platform->pcm_ops->pointer(substream);
+ if (cpu_dai->ops->delay)
+ delay += cpu_dai->ops->delay(substream, cpu_dai);
+
+ if (codec_dai->ops->delay)
+ delay += codec_dai->ops->delay(substream, codec_dai);
+
+ if (platform->delay)
+ delay += platform->delay(substream, codec_dai);
+
+ runtime->delay = delay;
+
return offset;
}
--
1.7.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
[PATCHv2 5/5] ASoC: OMAP3: Report delay caused by the internal FIFO
Use the new delay calback function to report the delay through
ALSA for application caused by the internal FIFO.
Signed-off-by: Peter Ujfalusi
---
sound/soc/omap/omap-mcbsp.c | 26 ++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index e814a95..2952fb0 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -256,6 +256,31 @@ static int omap_mcbsp_dai_trigger(struct snd_pcm_substream
*substream, int cmd,
return err;
}
+static snd_pcm_sframes_t omap_mcbsp_dai_delay(
+ struct snd_pcm_substream *substream,
+ struct snd_soc_dai *dai)
+{
+ struct snd_soc_pcm_runtime *rtd = substream->private_data;
+ struct snd_soc_dai *cpu_dai = rtd->dai->cpu_dai;
+ struct omap_mcbsp_data *mcbsp_data = to_mcbsp(cpu_dai->private_data);
+ u16 fifo_use;
+ snd_pcm_sframes_t delay;
+
+ if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
+ fifo_use = omap_mcbsp_get_tx_delay(mcbsp_data->bus_id);
+ else
+ fifo_use = omap_mcbsp_get_rx_delay(mcbsp_data->bus_id);
+
+ /*
+* Divide the used locations with the channel count to get the
+* FIFO usage in samples (don't care about partial samples in the
+* buffer).
+*/
+ delay = fifo_use / substream->runtime->channels;
+
+ return delay;
+}
+
static int omap_mcbsp_dai_hw_params(struct snd_pcm_substream *substream,
struct snd_pcm_hw_params *params,
struct snd_soc_dai *dai)
@@ -607,6 +632,7 @@ static struct snd_soc_dai_ops omap_mcbsp_dai_ops = {
.startup= omap_mcbsp_dai_startup,
.shutdown = omap_mcbsp_dai_shutdown,
.trigger= omap_mcbsp_dai_trigger,
+ .delay = omap_mcbsp_dai_delay,
.hw_params = omap_mcbsp_dai_hw_params,
.set_fmt= omap_mcbsp_dai_set_dai_fmt,
.set_clkdiv = omap_mcbsp_dai_set_clkdiv,
--
1.7.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] Add support for packet synchronised sDMA transfers.
I believe, packet mode is already supported in the current DMA driver. Both the FS and BS bits of the CCR are set when packet mode is selected. This is because, enum for OMAP_DMA_SYNC_PACKET is '0x03' (i.e OMAP_DMA_SYNC_FRAME | OMAP_DMA_SYNC_BLOCK). On Wed, Mar 3, 2010 at 4:20 AM, Fabrice Goucem wrote: > System DMA packet synchronisation is currently not supported in the > Linux Kernel. > This patch provides necessary modifications to support packet > synchronisation: > Function omap_set_dma_transfer_params() handles value OMAP_DMA_SYNC_PACKET > to program FS and BS bits of register CCR. > Users can give the packet size to the DMA driver by using parameters > src_fi / dst_fi in functions omap_set_dma_src_params() / > omap_set_dma_dest_params(). > > Patch has been validated using OMAP's McSPI (on Zoom2, OMAP3430): > McSPI is configured to use DMA transfer. > FIFO are activated with a threshold of 16 bytes (i.e. DMA requests will be > triggered as soon as more than 16 bytes are free in the FIFO). > A frame of 132 elements (bytes) has been transfered, by packets of 16 > elements. Resulting transfer was 8 packets of 16 elements plus a last packet > of 4 elements. > > Modifications tested building on OMAP2, OMAP3 and OMAP4 configurations. > > Signed-off-by: Fabrice Goucem > Acked-by: Venkatraman S > Acked-by: Santosh Shilimkar > Acked-by: Shilpa Maddi > --- > arch/arm/plat-omap/dma.c | 6 -- > 1 files changed, 4 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c > index 2ab224c..48f9355 100644 > --- a/arch/arm/plat-omap/dma.c > +++ b/arch/arm/plat-omap/dma.c > @@ -293,12 +293,14 @@ void omap_set_dma_transfer_params(int lch, int > data_type, int elem_count, > val |= (dma_trigger & ~0x1f) << 14; > val |= dma_trigger & 0x1f; > > - if (sync_mode & OMAP_DMA_SYNC_FRAME) > + if ((sync_mode == OMAP_DMA_SYNC_FRAME) || > + (sync_mode == OMAP_DMA_SYNC_PACKET)) > val |= 1 << 5; > else > val &= ~(1 << 5); > > - if (sync_mode & OMAP_DMA_SYNC_BLOCK) > + if ((sync_mode == OMAP_DMA_SYNC_BLOCK) || > + (sync_mode == OMAP_DMA_SYNC_PACKET)) > val |= 1 << 18; > else > val &= ~(1 << 18); > -- > 1.6.0.4 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe 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] Add support for packet synchronised sDMA transfers.
System DMA packet synchronisation is currently not supported in the Linux Kernel. This patch provides necessary modifications to support packet synchronisation: Function omap_set_dma_transfer_params() handles value OMAP_DMA_SYNC_PACKET to program FS and BS bits of register CCR. Users can give the packet size to the DMA driver by using parameters src_fi / dst_fi in functions omap_set_dma_src_params() / omap_set_dma_dest_params(). Patch has been validated using OMAP's McSPI (on Zoom2, OMAP3430): McSPI is configured to use DMA transfer. FIFO are activated with a threshold of 16 bytes (i.e. DMA requests will be triggered as soon as more than 16 bytes are free in the FIFO). A frame of 132 elements (bytes) has been transfered, by packets of 16 elements. Resulting transfer was 8 packets of 16 elements plus a last packet of 4 elements. Modifications tested building on OMAP2, OMAP3 and OMAP4 configurations. Signed-off-by: Fabrice Goucem Acked-by: Venkatraman S Acked-by: Santosh Shilimkar Acked-by: Shilpa Maddi --- arch/arm/plat-omap/dma.c |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c index 2ab224c..48f9355 100644 --- a/arch/arm/plat-omap/dma.c +++ b/arch/arm/plat-omap/dma.c @@ -293,12 +293,14 @@ void omap_set_dma_transfer_params(int lch, int data_type, int elem_count, val |= (dma_trigger & ~0x1f) << 14; val |= dma_trigger & 0x1f; - if (sync_mode & OMAP_DMA_SYNC_FRAME) + if ((sync_mode == OMAP_DMA_SYNC_FRAME) || + (sync_mode == OMAP_DMA_SYNC_PACKET)) val |= 1 << 5; else val &= ~(1 << 5); - if (sync_mode & OMAP_DMA_SYNC_BLOCK) + if ((sync_mode == OMAP_DMA_SYNC_BLOCK) || + (sync_mode == OMAP_DMA_SYNC_PACKET)) val |= 1 << 18; else val &= ~(1 << 18); -- 1.6.0.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] mmc: omap_hsmmc: Fix conditional locking
On Tue, 2 Mar 2010, Madhusudhan wrote:
> > Conditional locking on (!in_interrupt()) is broken by design and there
> > is no reason to keep the host->irq_lock across the call to
> > mmc_request_done(). Also the host->protect_card magic hack does not
> > depend on the context
> >
>
> Can you please elaborate why the existing logic is broken?
Locks are only to be held to serialize data or state.
The mmc_request_done() call does _NOT_ require that at all. So
dropping the lock there is the right thing to do.
Also conditional locking on in_interrupt() is generally a nono as it
relies on assumptions which are not necessarily true in all
circumstances. Just one simple example: interrupt threading will make
it explode nicely and it did already with the realtime patches
applied.
Such code constructs prevent us to do generic changes to the kernel
behaviour without any real good reason.
> It locks at the new request and unlocks just before issuing the cmd. Further
> IRQ handler has these calls hence the !in_interrupt check.
Aside of the conditional locking I have several issues with that code:
1) The code flow is massively unreadable:
omap_hsmmc_start_command()
{
.
if (!in_interrupt())
spin_unlock_irq();
}
omap_hsmmc_request()
{
if (!in_interrupt())
spin_lock_irq();
omap_hsmmc_start_command();
}
We generally want to see the lock/unlock pairs in one function and not
having to figure out where the heck unlock happens.
2) The point of unlocking is patently wrong
omap_hsmmc_start_command()
{
.
if (!in_interrupt())
spin_unlock_irq();
--->
OMAP_HSMMC_WRITE(host->base, ARG, cmd->arg);
--->
OMAP_HSMMC_WRITE(host->base, CMD, cmdreg);
}
What happens, if you get a spurious interrupt here ? Same for SMP,
though you are probably protected by the core mmc code request
serialization there.
> How does this patch improve that? In fact with your patch for a data
> transfer cmd there are several lock-unlock calls.
1) The patch simply removes conditional locking and moves the lock
sections to those places which protect something. Aside of that it
makes the code easier to understand.
2) What's the point of not having those lock/unlocks ? On UP the
spinlock is a NOOP anyway, so you won't even notice. On SMP you
won't notice either, simply because the lock is cache hot and
almost never contended.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP: DMA: Init CDAC to Zero
The register DMA4_CDAC needs to be initialized to zero
before starting DMA transfer.
Cc: Tony Lindgren
Cc: Santosh Shilimkar
Cc: Govindraj R
Cc: Kevin Hilman
Reported-by:S, Venkatraman
Signed-off-by: Manjunatha GK
---
It was aligned to reset CDAC to zero in omap_start_dma(int lch)
instead of creating new API for accessing CDAC register.
Discussion thread is at:
http://patchwork.kernel.org/patch/83176/
http://patchwork.kernel.org/patch/82948/
arch/arm/plat-omap/dma.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 2ab224c..96741d4 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -936,6 +936,14 @@ void omap_start_dma(int lch)
{
u32 l;
+ /* CPC/CDAC register needs to be initialized to zero
+* before starting dma transfer.
+*/
+ if (cpu_is_omap15xx())
+ dma_write(0, CPC(lch));
+ else
+ dma_write(0, CDAC(lch));
+
if (!omap_dma_in_1510_mode() && dma_chan[lch].next_lch != -1) {
int next_lch, cur_lch;
char dma_chan_link_map[OMAP_DMA4_LOGICAL_DMA_CH_COUNT];
--
1.6.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
