Re: [PATCHv1 1/3] OMAP UART: Adds omap-serial driver support.
On Thu, Oct 8, 2009 at 3:21 AM, Tony Lindgren t...@atomide.com wrote: * Govindraj.R govindraj.r...@ti.com [090924 03:29]: From: Govindraj R govindraj.r...@ti.com This patch adds support for OMAP3430-HIGH SPEED UART Controller. Signed-off-by: Govindraj R govindraj.r...@ti.com Reviewed-by: Alan Cox a...@lxorguk.ukuu.org.uk Reviewed-by: Tony Lindgren t...@atomide.com You should only add Reviewed-by if Alan or me have replied with it. So far I've only replied with some comments that have not yet been fixed, so we're few more steps from being Reviewd-by. snip diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig index 6553833..67a7129 100644 --- a/drivers/serial/Kconfig +++ b/drivers/serial/Kconfig @@ -1359,6 +1359,53 @@ config SERIAL_OF_PLATFORM Currently, only 8250 compatible ports are supported, but others can easily be added. +config SERIAL_OMAP + bool OMAP serial port support + depends on ARM ARCH_OMAP + select SERIAL_CORE + help + If you have a machine based on an Texas Instruments OMAP CPU you + can enable its onboard serial ports by enabling this option. + +config SERIAL_OMAP_CONSOLE + bool Console on OMAP serial port + depends on SERIAL_OMAP + select SERIAL_CORE_CONSOLE + help + If you have enabled the serial port on the Texas Instruments OMAP + CPU you can make it the console by answering Y to this option. + + Even if you say Y here, the currently visible virtual console + (/dev/tty0) will still be used as the system console by default, but + you can alter that using a kernel command line option such as + console=ttyS0. (Try man bootparam or see the documentation of + your boot loader (lilo or loadlin) about how to pass options to the + kernel at boot time.) + +config SERIAL_OMAP_DMA_UART1 + bool UART1 DMA support + depends on SERIAL_OMAP + help + If you have enabled the serial port on the Texas Instruments OMAP + CPU you can enable the DMA transfer on UART 1 by answering + to this option. + +config SERIAL_OMAP_DMA_UART2 + bool UART2 DMA support + depends on SERIAL_OMAP + help + If you have enabled the serial port on the Texas Instruments OMAP + CPU you can enable the DMA transfer on UART 2 by answering + to this option. + +config SERIAL_OMAP_DMA_UART3 + bool UART3 DMA support + depends on SERIAL_OMAP + help + If you have enabled the serial port on the Texas Instruments OMAP + CPU you can enable the DMA transfer on UART 3 by answering + to this option. + config SERIAL_OF_PLATFORM_NWPSERIAL tristate NWP serial port driver depends on PPC_OF PPC_DCR There's absolutely no need for having Kconfig options for the DMA support. Please pass that in platform_data from the board-*.c files. This is the third time I'm commenting on the same issue! What's the point of posting these patches for review if the issues don't get solved? The omap-serial uart driver is designed to work either in interrupt mode or in DMA mode, We have provided this option so that one can select interrupt mode or DMA mode based on the uart usage, if somebody is using uart as console then interrupt mode will do, else if used with bluetooth which does huge data transfer then DMA mode can be selected. Don't you think this should be a configurable option using kconfig rather than passing as platform data? if used as platform data then one has to modify platform data to switch between the interrupt and DMA mode. Regards, Govindraj.R Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-serial in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv1 1/3] OMAP UART: Adds omap-serial driver support.
On Sat, Oct 3, 2009 at 4:11 AM, Jonathan McDowell nood...@earth.li wrote: On Thu, Sep 24, 2009 at 03:57:13PM +0530, Govindraj.R wrote: From: Govindraj R govindraj.r...@ti.com This patch adds support for OMAP3430-HIGH SPEED UART Controller. Signed-off-by: Govindraj R govindraj.r...@ti.com Reviewed-by: Alan Cox a...@lxorguk.ukuu.org.uk Reviewed-by: Tony Lindgren t...@atomide.com --- +config SERIAL_OMAP + bool OMAP serial port support + depends on ARM ARCH_OMAP + select SERIAL_CORE + help + If you have a machine based on an Texas Instruments OMAP CPU you + can enable its onboard serial ports by enabling this option. If it's OMAP3 hardware then should the depends on be ARCH_OMAP3 || ARCH_OMAP4, rather than allowing it for OMAP1 + 2 as well? J. Agree. Will do the changes. -- Revd. Jonathan McDowell, ULC | If they can't take a jokefuck 'em. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- --- Regards, Govindraj.R -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH] OMAP3: introduce OMAP3630
Hi,
On Thu, Oct 08, 2009 at 06:47:03AM +0200, ext Nishanth Menon wrote:
Device intro:
OMAP3630 is the latest in the family of OMAP3 devices
and among the changes it introduces are:
New OPP levels for new voltage and frequency levels. a bunch of
Bug fixes to various modules feature additions, notably with ISP,
sDMA etc.
Details about the chip is available here:
http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateId=6123navigationId=12836contentId=52606
Strategy used:
Strategy to introduce this device into Linux was discussed here:
Ref: http://marc.info/?t=12534330343r=1w=2
Two approaches were available:
a) Consider 3630 generation of devices as a new family of silicon
b) Consider 3630 as an offshoot of 3430 family of devices
As a common consensus, (b) seems to be more valid for 3630 as:
* There are changes which are easily handled by looking at rev
* Most of existing 34xx infrastructure can be reused(almost 90%+)
- so no ugly if (cpu_is_omap34xx() || cpu_is_omap36xx())
all over the place
- lesser chance of bugs due to reuse of proven code flow
- 36xx specific handling can still be done where required
within the existing infrastructure
NOTE:
* If additional 34xx series are added, OMAP3430_REV_ES can be
added on top of the existing 3630 ones are renumbered
This patch was tested on SDP3430.
no test on 3630 boards ?
Signed-off-by: Madhusudhan Chikkature Rajashekar madhu...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
Cc: Allen Pais allen.p...@ti.com
Cc: Anand Gadiyar gadi...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Sanjeev Premi pr...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Sergio Alberto Aguirre Rodriguez saagui...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/id.c | 33
++---
arch/arm/plat-omap/include/mach/cpu.h |6 ++
2 files changed, 36 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 03b80f2..79193c6 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -186,6 +186,7 @@ void __init omap3_check_revision(void)
{
u32 cpuid, idcode;
u16 hawkeye;
+ u16 omap_type;
u8 rev;
char *rev_name = ES1.0;
@@ -210,7 +211,10 @@ void __init omap3_check_revision(void)
hawkeye = (idcode 12) 0x;
rev = (idcode 28) 0xff;
- if (hawkeye == 0xb7ae) {
+ omap_type = omap_rev() 16;
+ switch (hawkeye) {
+ case 0xb7ae:
+ /* Handle 34xx devices */
switch (rev) {
case 0:
omap_revision = OMAP3430_REV_ES2_0;
@@ -231,12 +235,35 @@ void __init omap3_check_revision(void)
default:
/* Use the latest known revision as default */
omap_revision = OMAP3430_REV_ES3_1;
- rev_name = Unknown revision\n;
+ rev_name = Unknown 34xx revision\n;
+ /* Fall through */
there's a break right below, you don't really fall through...
}
+ break;
+ case 0xb891:
+ /* Handle 36xx devices */
+ /* Over ride for display purposes */
multi-lined comment style is:
/* line 1
* line 2
* .
* .
* .
* line N
*/
+ omap_type = 0x3630;
+ switch (rev) {
+ case 0:
+ omap_revision = OMAP3630_REV_ES1_0;
+ rev_name = ES1.0;
+ break;
+ default:
+ /* Use the latest known revision as default */
+ omap_revision = OMAP3630_REV_ES1_0;
+ rev_name = Unknown 36xx revision\n;
+ /* Fall through */
don't fall through.
+ }
+ break;
+ default:
+ /* Unknown default to latest rev as default*/
+ omap_revision = OMAP3630_REV_ES1_0;
+ rev_name = Unknown revision\n;
+ /* Fall through */
unnecessary comment.
--
balbi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mux strategy (was RE: [PATCH] [OMAP1] mux: Add MMC mux pins for omap7xx)
Tony Lindgren wrote: * Kevin Hilman khil...@deeprootsystems.com [091006 15:18]: Menon, Nishanth n...@ti.com writes: BTW, I've been thinking about the following sets of patches for the next merge window: 1. Do the include directories for mach-omap1 and mach-omap2 as suggested by Russell earlier 2. Move all mux code to only live under arch/arm/*omap*/ and make sure drivers don't call omap_cfg_reg() any longer IMHO, we should also change omap_cfg_reg to omap_cfg_mux or something alike. 3. Remove the enumeration for the mux and require all the boards to register the pins they'll use +1 After these it should be trivial to improve the mux code further. The steps 2 3 above will be most likely breaking things for some boards, so help will be needed with testing. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Sincerely yours, Mike. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHv1 1/3] OMAP UART: Adds omap-serial driver support.
Govind, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Govindraj Sent: Thursday, October 08, 2009 11:44 AM To: Tony Lindgren Cc: Raja, Govindraj; linux-omap@vger.kernel.org; linux-ker...@vger.kernel.org; linux-ser...@vger.kernel.org Subject: Re: [PATCHv1 1/3] OMAP UART: Adds omap-serial driver support. On Thu, Oct 8, 2009 at 3:21 AM, Tony Lindgren t...@atomide.com wrote: * Govindraj.R govindraj.r...@ti.com [090924 03:29]: From: Govindraj R govindraj.r...@ti.com This patch adds support for OMAP3430-HIGH SPEED UART Controller. Signed-off-by: Govindraj R govindraj.r...@ti.com Reviewed-by: Alan Cox a...@lxorguk.ukuu.org.uk Reviewed-by: Tony Lindgren t...@atomide.com You should only add Reviewed-by if Alan or me have replied with it. So far I've only replied with some comments that have not yet been fixed, so we're few more steps from being Reviewd-by. snip diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig index 6553833..67a7129 100644 --- a/drivers/serial/Kconfig +++ b/drivers/serial/Kconfig @@ -1359,6 +1359,53 @@ config SERIAL_OF_PLATFORM Currently, only 8250 compatible ports are supported, but others can easily be added. +config SERIAL_OMAP + bool OMAP serial port support + depends on ARM ARCH_OMAP + select SERIAL_CORE + help + If you have a machine based on an Texas Instruments OMAP CPU you + can enable its onboard serial ports by enabling this option. + +config SERIAL_OMAP_CONSOLE + bool Console on OMAP serial port + depends on SERIAL_OMAP + select SERIAL_CORE_CONSOLE + help + If you have enabled the serial port on the Texas Instruments OMAP + CPU you can make it the console by answering Y to this option. + + Even if you say Y here, the currently visible virtual console + (/dev/tty0) will still be used as the system console by default, but + you can alter that using a kernel command line option such as + console=ttyS0. (Try man bootparam or see the documentation of + your boot loader (lilo or loadlin) about how to pass options to the + kernel at boot time.) + +config SERIAL_OMAP_DMA_UART1 + bool UART1 DMA support + depends on SERIAL_OMAP + help + If you have enabled the serial port on the Texas Instruments OMAP + CPU you can enable the DMA transfer on UART 1 by answering + to this option. + +config SERIAL_OMAP_DMA_UART2 + bool UART2 DMA support + depends on SERIAL_OMAP + help + If you have enabled the serial port on the Texas Instruments OMAP + CPU you can enable the DMA transfer on UART 2 by answering + to this option. + +config SERIAL_OMAP_DMA_UART3 + bool UART3 DMA support + depends on SERIAL_OMAP + help + If you have enabled the serial port on the Texas Instruments OMAP + CPU you can enable the DMA transfer on UART 3 by answering + to this option. + config SERIAL_OF_PLATFORM_NWPSERIAL tristate NWP serial port driver depends on PPC_OF PPC_DCR There's absolutely no need for having Kconfig options for the DMA support. Please pass that in platform_data from the board-*.c files. This is the third time I'm commenting on the same issue! What's the point of posting these patches for review if the issues don't get solved? The omap-serial uart driver is designed to work either in interrupt mode or in DMA mode, We have provided this option so that one can select interrupt mode or DMA mode based on the uart usage, if somebody is using uart as console then interrupt mode will do, else if used with bluetooth which does huge data transfer then DMA mode can be selected. Don't you think this should be a configurable option using kconfig rather than passing as platform data? if used as platform data then one has to modify platform data to switch between the interrupt and DMA mode. Regards, Govindraj.R Usage of UART is board dependent. It's usage will not change dynamically for a given board. This can be removed from Kconfig and move it to respective board file- board-*.c Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-serial 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 -- To unsubscribe from this list: send the line unsubscribe 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]ZOOM2: Initialization of SDRC params on Zoom2
From: Teerth Reddy tee...@ti.com
This patch initializes the correct SDRC settings required
for DVFS on Zoom2.
Signed-off-by: Teerth Reddy tee...@ti.com
---
arch/arm/mach-omap2/board-zoom2.c |4 +++-
1 files changed, 3 insertions(+), 1 deletion(-)
Index: linux-omap-2.6/arch/arm/mach-omap2/board-zoom2.c
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/board-zoom2.c
+++ linux-omap-2.6/arch/arm/mach-omap2/board-zoom2.c
@@ -25,6 +25,7 @@
#include mach/keypad.h
#include mmc-twl4030.h
+#include sdram-micron-mt46h32m32lf-6.h
/* Zoom2 has Qwerty keyboard*/
static int board_keymap[] = {
@@ -213,7 +214,8 @@ static void __init omap_zoom2_init_irq(v
{
omap_board_config = zoom2_config;
omap_board_config_size = ARRAY_SIZE(zoom2_config);
- omap2_init_common_hw(NULL, NULL);
+ omap2_init_common_hw(mt46h32m32lf6_sdrc_params,
+mt46h32m32lf6_sdrc_params);
omap_init_irq();
omap_gpio_init();
}
--
To unsubscribe from this list: send the line unsubscribe 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: Fix VDD2 OPP1 issue
From 144669d941a432875db37ae9431847f6753e566e Mon Sep 17 00:00:00 2001
From: Teerth Reddy tee...@ti.com
Date: Wed, 9 Sep 2009 11:01:04 +0530
Subject: [PATCH] ARM: OMAP3: PM: Fix VDD2 OPP1 issue
This patch fixes the VDD2 OPP1 issue. The patch has change
which does not allow VDD2 OPP setting to 1.VDD2 should not be put
at OPP1 as this is not a supported OPP for VDD2
Signed-off-by: Teerth Reddy tee...@ti.com
---
arch/arm/mach-omap2/pm.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index fec7d00..d0e03c4 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -195,7 +195,7 @@ static ssize_t vdd_opp_store(struct kobject *kobj, struct
kobj_attribute *attr,
}
resource_set_opp_level(VDD1_OPP, value, flags);
} else if (attr == vdd2_opp_attr) {
- if (value 1 || value 3) {
+ if (value 2 || value 3) {
printk(KERN_ERR vdd_opp_store: Invalid value\n);
return -EINVAL;
}
--
1.5.4.7
--
To unsubscribe from this list: send the line unsubscribe 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] [RFC] OMAP: eliminate OMAP_MAX_NR_PORTS
From: Alexander Shishkin virtu...@slind.org
Signed-off-by: Alexander Shishkin virtu...@slind.org
---
arch/arm/mach-omap1/serial.c |2 +-
arch/arm/mach-omap2/serial.c |6 +++---
arch/arm/plat-omap/include/mach/serial.h |4
3 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap1/serial.c b/arch/arm/mach-omap1/serial.c
index ed07af1..a86de7c 100644
--- a/arch/arm/mach-omap1/serial.c
+++ b/arch/arm/mach-omap1/serial.c
@@ -123,7 +123,7 @@ void __init omap_serial_init(void)
serial_platform_data[2].uartclk = OMAP1510_BASE_BAUD * 16;
}
- for (i = 0; i OMAP_MAX_NR_PORTS; i++) {
+ for (i = 0; i ARRAY_SIZE(serial_platform_data); i++) {
unsigned char reg;
switch (i) {
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index ae21868..c5bef44 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -549,7 +549,7 @@ static inline void omap_uart_idle_init(struct
omap_uart_state *uart) {}
#define DEV_CREATE_FILE(dev, attr)
#endif /* CONFIG_PM */
-static struct omap_uart_state omap_uart[OMAP_MAX_NR_PORTS] = {
+static struct omap_uart_state omap_uart[] = {
{
.pdev = {
.name = serial8250,
@@ -599,7 +599,7 @@ void __init omap_serial_early_init(void)
* if not needed.
*/
- for (i = 0; i OMAP_MAX_NR_PORTS; i++) {
+ for (i = 0; i ARRAY_SIZE(omap_uart); i++) {
struct omap_uart_state *uart = omap_uart[i];
struct platform_device *pdev = uart-pdev;
struct device *dev = pdev-dev;
@@ -641,7 +641,7 @@ void __init omap_serial_init(void)
{
int i;
- for (i = 0; i OMAP_MAX_NR_PORTS; i++) {
+ for (i = 0; i ARRAY_SIZE(omap_uart); i++) {
struct omap_uart_state *uart = omap_uart[i];
struct platform_device *pdev = uart-pdev;
struct device *dev = pdev-dev;
diff --git a/arch/arm/plat-omap/include/mach/serial.h
b/arch/arm/plat-omap/include/mach/serial.h
index e249186..9951345 100644
--- a/arch/arm/plat-omap/include/mach/serial.h
+++ b/arch/arm/plat-omap/include/mach/serial.h
@@ -20,26 +20,22 @@
#define OMAP_UART1_BASE0xfffb
#define OMAP_UART2_BASE0xfffb0800
#define OMAP_UART3_BASE0xfffb9800
-#define OMAP_MAX_NR_PORTS 3
#elif defined(CONFIG_ARCH_OMAP2)
/* OMAP2 serial ports */
#define OMAP_UART1_BASE0x4806a000
#define OMAP_UART2_BASE0x4806c000
#define OMAP_UART3_BASE0x4806e000
-#define OMAP_MAX_NR_PORTS 3
#elif defined(CONFIG_ARCH_OMAP3)
/* OMAP3 serial ports */
#define OMAP_UART1_BASE0x4806a000
#define OMAP_UART2_BASE0x4806c000
#define OMAP_UART3_BASE0x4902
-#define OMAP_MAX_NR_PORTS 3
#elif defined(CONFIG_ARCH_OMAP4)
/* OMAP4 serial ports */
#define OMAP_UART1_BASE0x4806a000
#define OMAP_UART2_BASE0x4806c000
#define OMAP_UART3_BASE0x4802
#define OMAP_UART4_BASE0x4806e000
-#define OMAP_MAX_NR_PORTS 4
#endif
#define OMAP1510_BASE_BAUD (1200/16)
--
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: [RFC][PATCH] OMAP3: introduce OMAP3630
-Original Message-
From: Menon, Nishanth
Sent: Thursday, October 08, 2009 10:17 AM
To: linux-omap
Cc: Menon, Nishanth; Chikkature Rajashekar, Madhusudhan; Pandita, Vikram;
Pais, Allen; Gadiyar, Anand; Cousson, Benoit; Kevin Hilman; Premi,
Sanjeev; Shilimkar, Santosh; Aguirre Rodriguez, Sergio Alberto; Tony
Lindgren
Subject: [RFC][PATCH] OMAP3: introduce OMAP3630
Device intro:
OMAP3630 is the latest in the family of OMAP3 devices
and among the changes it introduces are:
New OPP levels for new voltage and frequency levels. a bunch of
Bug fixes to various modules feature additions, notably with ISP,
sDMA etc.
Details about the chip is available here:
http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateId=61
23navigationId=12836contentId=52606
Strategy used:
Strategy to introduce this device into Linux was discussed here:
Ref: http://marc.info/?t=12534330343r=1w=2
Two approaches were available:
a) Consider 3630 generation of devices as a new family of silicon
b) Consider 3630 as an offshoot of 3430 family of devices
As a common consensus, (b) seems to be more valid for 3630 as:
* There are changes which are easily handled by looking at rev
* Most of existing 34xx infrastructure can be reused(almost 90%+)
- so no ugly if (cpu_is_omap34xx() || cpu_is_omap36xx())
all over the place
- lesser chance of bugs due to reuse of proven code flow
- 36xx specific handling can still be done where required
within the existing infrastructure
NOTE:
* If additional 34xx series are added, OMAP3430_REV_ES can be
added on top of the existing 3630 ones are renumbered
This patch was tested on SDP3430.
Signed-off-by: Madhusudhan Chikkature Rajashekar madhu...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
Cc: Allen Pais allen.p...@ti.com
Cc: Anand Gadiyar gadi...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Sanjeev Premi pr...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Sergio Alberto Aguirre Rodriguez saagui...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/id.c | 33
++---
arch/arm/plat-omap/include/mach/cpu.h |6 ++
2 files changed, 36 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 03b80f2..79193c6 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -186,6 +186,7 @@ void __init omap3_check_revision(void)
{
u32 cpuid, idcode;
u16 hawkeye;
+ u16 omap_type;
u8 rev;
char *rev_name = ES1.0;
@@ -210,7 +211,10 @@ void __init omap3_check_revision(void)
hawkeye = (idcode 12) 0x;
rev = (idcode 28) 0xff;
- if (hawkeye == 0xb7ae) {
+ omap_type = omap_rev() 16;
+ switch (hawkeye) {
+ case 0xb7ae:
+ /* Handle 34xx devices */
switch (rev) {
case 0:
omap_revision = OMAP3430_REV_ES2_0;
@@ -231,12 +235,35 @@ void __init omap3_check_revision(void)
default:
/* Use the latest known revision as default */
omap_revision = OMAP3430_REV_ES3_1;
- rev_name = Unknown revision\n;
+ rev_name = Unknown 34xx revision\n;
+ /* Fall through */
}
+ break;
+ case 0xb891:
+ /* Handle 36xx devices */
+ /* Over ride for display purposes */
+ omap_type = 0x3630;
+ switch (rev) {
+ case 0:
+ omap_revision = OMAP3630_REV_ES1_0;
+ rev_name = ES1.0;
+ break;
+ default:
+ /* Use the latest known revision as default */
+ omap_revision = OMAP3630_REV_ES1_0;
+ rev_name = Unknown 36xx revision\n;
+ /* Fall through */
+ }
+ break;
+ default:
+ /* Unknown default to latest rev as default*/
+ omap_revision = OMAP3630_REV_ES1_0;
+ rev_name = Unknown revision\n;
+ /* Fall through */
}
out:
- pr_info(OMAP%04x %s\n, omap_rev() 16, rev_name);
+ pr_info(OMAP%04x %s\n, omap_type, rev_name);
}
#define OMAP3_SHOW_FEATURE(feat) \
diff --git a/arch/arm/plat-omap/include/mach/cpu.h b/arch/arm/plat-
omap/include/mach/cpu.h
index 431fec4..af1080f 100644
--- a/arch/arm/plat-omap/include/mach/cpu.h
+++ b/arch/arm/plat-omap/include/mach/cpu.h
@@ -383,6 +383,12 @@ IS_OMAP_TYPE(3430, 0x3430)
#define OMAP3430_REV_ES2_1 0x34302034
#define OMAP3430_REV_ES3_0 0x34303034
#define OMAP3430_REV_ES3_1 0x34304034
+/* NOTE: Add 36xx series below
+ *
RE: Patches merged to split OMAP2_IO_ADDRESS
Tony, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Tony Lindgren Sent: Thursday, October 08, 2009 5:55 AM To: linux-omap@vger.kernel.org Cc: Paul Walmsley Subject: Patches merged to split OMAP2_IO_ADDRESS Hi all, I've pushed Santosh' patches to split OMAP2_IO_ADDRESS into *_L3_IO_ADDRESS and *_L4_IO_ADDRESS so we can claim more kernel address space and support over 512MB of memory instead of 256MB. Of course, our goal is to convert everything except the .S files to use ioremap() instead, but that can now be done parallel and in smaller chunks. Please everybody, please convert your code to use ioremap(), there are static mappings already in place so it should work out of the box. I also had add two quick patches to keep things compiling, Paul can you take a look at them? I could not really test them as all the code is not there yet. Will post them as a reply to this thread. Thanks for the merge!! I have boot tested below platforms with latest LO master. 1. OMAP3430 SDP board - BOOT OK 2. OMAP3 BEAGLE - BOOT OK 3. OMAP 4430 SDP - BOOT OK with variation of patch: http://patchwork.kernel.org/patch/50531/ 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
[PATCH 0/8] RX-51 audio drivers
Hello everyone, Here is a patch series with most of audio support for RX51. Basically it includes asoc machine driver for rx51, tpa6130a2 amplifier driver (asoc version), board file configuration and setup and the sidetone feature of mcbsp. On top of that, there are few patches to use regulator framework to control vmmc2. This series is based on linux-omap. So basically after applying it, you can boot the device and have sound support. Even though this patches were tested using linux-omap, the series is applicable on top of sound-2.6 tree as well. Please review. And as usual, comments are welcome. BR, --- Eduardo Valentin Eduardo Valentin (6): ASoC: OMAP: RX-51 Machine driver and AIC34b_dummy driver OMAP: RX51: Add audio board file board-rx51-peripherals: split vaux3 and vmmc2 supplies RX-51: Audio: Add usage of regulator framework to control VMMC2 ASoC: tlv320aic3x: add initial usage of regulator framework to control avdd_dac ASoC: tpa6130a2: Control vdd using regulator framework Eero Nurkkala (1): McBSP: OMAP3: Add Sidetone feature Peter Ujfalusi (1): ASoC: TPA6130A2 amplifier driver arch/arm/mach-omap2/Makefile |1 + arch/arm/mach-omap2/board-rx51-audio.c | 132 + arch/arm/mach-omap2/board-rx51-peripherals.c | 22 +- arch/arm/mach-omap2/mcbsp.c |2 + arch/arm/plat-omap/include/mach/mcbsp.h | 43 ++ arch/arm/plat-omap/mcbsp.c | 379 - include/sound/tpa6130a2-plat.h | 30 + sound/soc/codecs/Kconfig |4 + sound/soc/codecs/Makefile|2 + sound/soc/codecs/tlv320aic3x.c | 26 + sound/soc/codecs/tpa6130a2.c | 396 + sound/soc/codecs/tpa6130a2.h | 62 ++ sound/soc/omap/Kconfig | 10 + sound/soc/omap/Makefile |2 + sound/soc/omap/aic34b_dummy.c| 271 + sound/soc/omap/aic34b_dummy.h| 32 + sound/soc/omap/rx51.c| 793 ++ sound/soc/omap/rx51.h| 29 + 18 files changed, 2225 insertions(+), 11 deletions(-) create mode 100644 arch/arm/mach-omap2/board-rx51-audio.c create mode 100644 include/sound/tpa6130a2-plat.h create mode 100644 sound/soc/codecs/tpa6130a2.c create mode 100644 sound/soc/codecs/tpa6130a2.h create mode 100644 sound/soc/omap/aic34b_dummy.c create mode 100644 sound/soc/omap/aic34b_dummy.h create mode 100644 sound/soc/omap/rx51.c create mode 100644 sound/soc/omap/rx51.h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/8] ASoC: TPA6130A2 amplifier driver
From: Peter Ujfalusi peter.ujfal...@nokia.com
Driver for Texas Instruments TPA6130A2 headphone stereo
amplifier.
Signed-off-by: Peter Ujfalusi peter.ujfal...@nokia.com
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
include/sound/tpa6130a2-plat.h | 30 +++
sound/soc/codecs/Kconfig |4 +
sound/soc/codecs/Makefile |2 +
sound/soc/codecs/tpa6130a2.c | 380
sound/soc/codecs/tpa6130a2.h | 62 +++
5 files changed, 478 insertions(+), 0 deletions(-)
create mode 100644 include/sound/tpa6130a2-plat.h
create mode 100644 sound/soc/codecs/tpa6130a2.c
create mode 100644 sound/soc/codecs/tpa6130a2.h
diff --git a/include/sound/tpa6130a2-plat.h b/include/sound/tpa6130a2-plat.h
new file mode 100644
index 000..d315728
--- /dev/null
+++ b/include/sound/tpa6130a2-plat.h
@@ -0,0 +1,30 @@
+/*
+ * TPA6130A2 driver platform header
+ *
+ * Copyright (C) Nokia Corporation
+ *
+ * Written by Peter Ujfalusi peter.ujfal...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ */
+
+#ifndef TPA6130A2_PLAT_H
+#define TPA6130A2_PLAT_H
+
+struct tpa6130a2_platform_data {
+ int (*set_power)(int state);
+};
+
+#endif
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 0edca93..2437fd3 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -28,6 +28,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_TLV320AIC23 if I2C
select SND_SOC_TLV320AIC26 if SPI_MASTER
select SND_SOC_TLV320AIC3X if I2C
+ select SND_SOC_TPA6130A2 if I2C
select SND_SOC_TWL4030 if TWL4030_CORE
select SND_SOC_UDA134X
select SND_SOC_UDA1380 if I2C
@@ -220,3 +221,6 @@ config SND_SOC_WM9713
# Amp
config SND_SOC_MAX9877
tristate
+
+config SND_SOC_TPA6130A2
+ tristate
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index fb4af28..498c024 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -47,6 +47,7 @@ snd-soc-wm-hubs-objs := wm_hubs.o
# Amp
snd-soc-max9877-objs := max9877.o
+snd-soc-tpa6130a2-objs := tpa6130a2.o
obj-$(CONFIG_SND_SOC_AC97_CODEC) += snd-soc-ac97.o
obj-$(CONFIG_SND_SOC_AD1836) += snd-soc-ad1836.o
@@ -97,3 +98,4 @@ obj-$(CONFIG_SND_SOC_WM_HUBS) += snd-soc-wm-hubs.o
# Amp
obj-$(CONFIG_SND_SOC_MAX9877) += snd-soc-max9877.o
+obj-$(CONFIG_SND_SOC_TPA6130A2)+= snd-soc-tpa6130a2.o
diff --git a/sound/soc/codecs/tpa6130a2.c b/sound/soc/codecs/tpa6130a2.c
new file mode 100644
index 000..d246aad
--- /dev/null
+++ b/sound/soc/codecs/tpa6130a2.c
@@ -0,0 +1,380 @@
+/*
+ * ALSA SoC Texas Instruments TPA6130A2 headset stereo amplifier driver
+ *
+ * Copyright (C) Nokia Corporation
+ *
+ * Author: Peter Ujfalusi peter.ujfal...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ */
+
+#include linux/module.h
+#include linux/errno.h
+#include linux/string.h
+#include linux/device.h
+#include linux/i2c.h
+#include linux/sysfs.h
+#include sound/tpa6130a2-plat.h
+#include sound/soc.h
+#include sound/soc-dapm.h
+#include sound/tlv.h
+
+#include tpa6130a2.h
+
+struct i2c_client *tpa6130a2_client;
+
+/* This struct is used to save the context */
+struct tpa6130a2_data {
+ /* mutex protect access to tpa6130a2_data structure */
+ struct mutex mutex;
+ unsigned char regs[TPA6130A2_CACHEREGNUM];
+ unsigned char power_state;
+ int (*set_power)(int state);
+};
+
+static int tpa6130a2_i2c_read(int reg)
+{
+ struct tpa6130a2_data *data;
+ int val;
+
+ BUG_ON(tpa6130a2_client == NULL);
+
+ data = i2c_get_clientdata(tpa6130a2_client);
+
+ /* If powered off, return the cached value */
+ if (data-power_state) {
+ val
[PATCH 5/8] board-rx51-peripherals: split vaux3 and vmmc2 supplies
From: Eduardo Valentin eduardo.valen...@nokia.com
Use separated supplies for vaux3 and vmmc2.
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
arch/arm/mach-omap2/board-rx51-peripherals.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index b227475..92f7dfa 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -125,6 +125,10 @@ static struct regulator_consumer_supply rx51_vmmc1_supply
= {
.supply = vmmc,
};
+static struct regulator_consumer_supply rx51_vaux3_supply = {
+ .supply = vmmc,
+};
+
static struct regulator_consumer_supply rx51_vmmc2_supply = {
.supply = vmmc,
};
@@ -184,7 +188,7 @@ static struct regulator_init_data rx51_vaux3_mmc = {
| REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies = 1,
- .consumer_supplies = rx51_vmmc2_supply,
+ .consumer_supplies = rx51_vaux3_supply,
};
static struct regulator_init_data rx51_vaux4 = {
@@ -266,7 +270,7 @@ static int rx51_twlgpio_setup(struct device *dev, unsigned
gpio, unsigned n)
/* set up MMC adapters, linking their regulators to them */
twl4030_mmc_init(mmc);
rx51_vmmc1_supply.dev = mmc[0].dev;
- rx51_vmmc2_supply.dev = mmc[1].dev;
+ rx51_vaux3_supply.dev = mmc[1].dev;
rx51_vsim_supply.dev = mmc[1].dev;
return 0;
--
1.6.4.183.g04423
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/8] OMAP: RX51: Add audio board file
From: Eduardo Valentin eduardo.valen...@nokia.com
Add board-rx51-audio.c with audio support for rx51 boards.
Platform data included for the following drivers:
si4713, aic34b_dummy and tpa6130a2.
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-rx51-audio.c | 132
2 files changed, 133 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-rx51-audio.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 6b7702f..50f2fbe 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -70,6 +70,7 @@ obj-$(CONFIG_MACH_OMAP_3430SDP) +=
board-3430sdp.o \
obj-$(CONFIG_MACH_NOKIA_N8X0) += board-n8x0.o
obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o \
board-rx51-peripherals.o \
+ board-rx51-audio.o \
mmc-twl4030.o
obj-$(CONFIG_MACH_OMAP_ZOOM2) += board-zoom2.o \
mmc-twl4030.o \
diff --git a/arch/arm/mach-omap2/board-rx51-audio.c
b/arch/arm/mach-omap2/board-rx51-audio.c
new file mode 100644
index 000..cba42b5
--- /dev/null
+++ b/arch/arm/mach-omap2/board-rx51-audio.c
@@ -0,0 +1,132 @@
+/*
+ * linux/arch/arm/mach-omap2/board-rx51-audio.c
+ *
+ * Copyright (C) 2008 Nokia
+ *
+ * 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 linux/kernel.h
+#include linux/init.h
+#include linux/i2c.h
+#include linux/gpio.h
+#include linux/delay.h
+#include linux/i2c/twl4030.h
+#include sound/tpa6130a2-plat.h
+#include media/si4713.h
+#include media/radio-si4713.h
+#include linux/platform_device.h
+#include asm/mach-types.h
+
+#define RX51_FMTX_RESET_GPIO 163
+#define RX51_FMTX_IRQ 53
+#define RX51_FMRX_IRQ 43
+#define RX51_HEADPHN_EN_GPIO 98
+
+static int si4713_set_power(int power)
+{
+ if (!power)
+ udelay(1);
+ gpio_set_value(RX51_FMTX_RESET_GPIO, power);
+ udelay(50);
+
+ return 0;
+}
+
+static struct si4713_platform_data rx51_si4713_platform_data = {
+ .set_power = si4713_set_power,
+};
+
+static void __init rx51_init_si4713(void)
+{
+ int r;
+
+ r = gpio_request(RX51_FMTX_RESET_GPIO, si4713);
+ if (r 0) {
+ printk(KERN_ERR Failed to request gpio for FMTx rst\n);
+ return;
+ }
+
+ gpio_direction_output(RX51_FMTX_RESET_GPIO, 0);
+}
+
+static int tpa6130a2_set_power(int state)
+{
+ gpio_set_value(RX51_HEADPHN_EN_GPIO, !!state);
+ return 0;
+}
+
+static struct tpa6130a2_platform_data rx51_tpa6130a2_platform_data = {
+ .set_power = tpa6130a2_set_power,
+};
+
+static void __init rx51_init_tpa6130a2(void)
+{
+ int r;
+
+ r = gpio_request(RX51_HEADPHN_EN_GPIO, tpa6130a2);
+ if (r 0) {
+ printk(KERN_ERR Failed to request shutdown gpio
+ for TPA6130a2 chip\n);
+ }
+
+ gpio_direction_output(RX51_HEADPHN_EN_GPIO, 0);
+
+ return;
+}
+
+struct i2c_board_info si4713_board_info = {
+ I2C_BOARD_INFO(si4713, SI4713_I2C_ADDR_BUSEN_HIGH),
+ .irq= OMAP_GPIO_IRQ(RX51_FMTX_IRQ),
+ .platform_data = rx51_si4713_platform_data,
+};
+
+static struct radio_si4713_platform_data rx51_radio_si4713_platform_data = {
+ .i2c_bus= 2,
+ .subdev_board_info = si4713_board_info,
+};
+
+static struct platform_device radio_fmtx = {
+ .name = radio-si4713,
+ .id = -1,
+ .dev= {
+ .platform_data = rx51_radio_si4713_platform_data,
+ },
+};
+
+static struct platform_device *rx51_audio_devices[] = {
+ radio_fmtx,
+};
+
+static struct i2c_board_info __initdata rx51_audio_i2c_board_info_2[] = {
+ {
+ I2C_BOARD_INFO(aic34b_dummy, 0x19),
+ },
+ {
+ I2C_BOARD_INFO(tlv320aic3x, 0x18),
+ },
+ {
+ I2C_BOARD_INFO(tpa6130a2, 0x60),
+ .platform_data = rx51_tpa6130a2_platform_data,
+ },
+};
+
+static int __init rx51_audio_init(void)
+{
+ if (!machine_is_nokia_rx51())
+ return 0;
+
+ platform_add_devices(rx51_audio_devices,
+ ARRAY_SIZE(rx51_audio_devices));
+
+ rx51_init_tpa6130a2();
+ rx51_init_si4713();
+ i2c_register_board_info(2, rx51_audio_i2c_board_info_2,
+ ARRAY_SIZE(rx51_audio_i2c_board_info_2));
+
+ return 0;
+}
+
+subsys_initcall(rx51_audio_init);
--
1.6.4.183.g04423
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
[PATCH 6/8] RX-51: Audio: Add usage of regulator framework to control VMMC2
From: Eduardo Valentin eduardo.valen...@nokia.com
This patch adds two supplies for VMMC2 on rx51 boards.
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 92f7dfa..9177b1c 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -129,8 +129,9 @@ static struct regulator_consumer_supply rx51_vaux3_supply =
{
.supply = vmmc,
};
-static struct regulator_consumer_supply rx51_vmmc2_supply = {
- .supply = vmmc,
+static struct regulator_consumer_supply rx51_vmmc2_supplies[] = {
+ REGULATOR_SUPPLY(avdd_dac, 2-0018), /* tlv320aic3x */
+ REGULATOR_SUPPLY(vdd, 2-0060), /* tpa6130a2*/
};
static struct regulator_consumer_supply rx51_vsim_supply = {
@@ -230,8 +231,8 @@ static struct regulator_init_data rx51_vmmc2 = {
| REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
},
- .num_consumer_supplies = 1,
- .consumer_supplies = rx51_vmmc2_supply,
+ .num_consumer_supplies = ARRAY_SIZE(rx51_vmmc2_supplies),
+ .consumer_supplies = rx51_vmmc2_supplies,
};
static struct regulator_init_data rx51_vsim = {
@@ -442,10 +443,9 @@ static int __init rx51_i2c_init(void)
if ((system_rev = SYSTEM_REV_S_USES_VAUX3 system_rev 0x100) ||
system_rev = SYSTEM_REV_B_USES_VAUX3)
rx51_twldata.vaux3 = rx51_vaux3_mmc;
- else {
+ else
rx51_twldata.vaux3 = rx51_vaux3_cam;
- rx51_twldata.vmmc2 = rx51_vmmc2;
- }
+ rx51_twldata.vmmc2 = rx51_vmmc2;
omap_register_i2c_bus(1, 2600, rx51_peripherals_i2c_board_info_1,
ARRAY_SIZE(rx51_peripherals_i2c_board_info_1));
omap_register_i2c_bus(2, 100, NULL, 0);
--
1.6.4.183.g04423
--
To unsubscribe from this list: send the line unsubscribe 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/8] ASoC: OMAP: RX-51 Machine driver and AIC34b_dummy driver
From: Eduardo Valentin eduardo.valen...@nokia.com Introduce RX-51 Machine driver for ASoC and AIC34b_dummy (block B) i2c driver. Also move the request_gpio of speaker_enabled from board-rx51-peripherals.c to this machine driver. These drivers were originally written by Jarkko Nikula. Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com --- arch/arm/mach-omap2/board-rx51-peripherals.c |2 - sound/soc/omap/Kconfig | 10 + sound/soc/omap/Makefile |2 + sound/soc/omap/aic34b_dummy.c| 271 + sound/soc/omap/aic34b_dummy.h| 32 + sound/soc/omap/rx51.c| 793 ++ sound/soc/omap/rx51.h| 29 + 7 files changed, 1137 insertions(+), 2 deletions(-) create mode 100644 sound/soc/omap/aic34b_dummy.c create mode 100644 sound/soc/omap/aic34b_dummy.h create mode 100644 sound/soc/omap/rx51.c create mode 100644 sound/soc/omap/rx51.h diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c b/arch/arm/mach-omap2/board-rx51-peripherals.c index c1af532..b227475 100644 --- a/arch/arm/mach-omap2/board-rx51-peripherals.c +++ b/arch/arm/mach-omap2/board-rx51-peripherals.c @@ -262,8 +262,6 @@ static int rx51_twlgpio_setup(struct device *dev, unsigned gpio, unsigned n) /* FIXME this gpio setup is just a placeholder for now */ gpio_request(gpio + 6, backlight_pwm); gpio_direction_output(gpio + 6, 0); - gpio_request(gpio + 7, speaker_en); - gpio_direction_output(gpio + 7, 1); /* set up MMC adapters, linking their regulators to them */ twl4030_mmc_init(mmc); diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig index 2dee983..bdcd4be 100644 --- a/sound/soc/omap/Kconfig +++ b/sound/soc/omap/Kconfig @@ -15,6 +15,16 @@ config SND_OMAP_SOC_N810 help Say Y if you want to add support for SoC audio on Nokia N810. +config SND_OMAP_SOC_RX51 + tristate SoC Audio support for Nokia RX51 + depends on SND_OMAP_SOC MACH_NOKIA_RX51 + select OMAP_MCBSP + select SND_OMAP_SOC_MCBSP + select SND_SOC_TLV320AIC3X + select SND_SOC_TPA6130A2 + help + Say Y if you want to add support for SoC audio on Nokia RX51. + config SND_OMAP_SOC_AMS_DELTA tristate SoC Audio support for Amstrad E3 (Delta) videophone depends on SND_OMAP_SOC MACH_AMS_DELTA diff --git a/sound/soc/omap/Makefile b/sound/soc/omap/Makefile index 02d6947..7dec270 100644 --- a/sound/soc/omap/Makefile +++ b/sound/soc/omap/Makefile @@ -16,8 +16,10 @@ snd-soc-sdp3430-objs := sdp3430.o snd-soc-omap3pandora-objs := omap3pandora.o snd-soc-omap3beagle-objs := omap3beagle.o snd-soc-zoom2-objs := zoom2.o +snd-soc-rx51-objs := rx51.o obj-$(CONFIG_SND_OMAP_SOC_N810) += snd-soc-n810.o +obj-$(CONFIG_SND_OMAP_SOC_RX51) += snd-soc-rx51.o aic34b_dummy.o obj-$(CONFIG_SND_OMAP_SOC_AMS_DELTA) += snd-soc-ams-delta.o obj-$(CONFIG_SND_OMAP_SOC_OSK5912) += snd-soc-osk5912.o obj-$(CONFIG_SND_OMAP_SOC_OVERO) += snd-soc-overo.o diff --git a/sound/soc/omap/aic34b_dummy.c b/sound/soc/omap/aic34b_dummy.c new file mode 100644 index 000..17c4d9c --- /dev/null +++ b/sound/soc/omap/aic34b_dummy.c @@ -0,0 +1,271 @@ +/* + * aic34b_dummy.c -- Dummy driver for AIC34 block B parts used in Nokia RX51 + * + * Purpose for this driver is to cover few audio connections on Nokia RX51 HW + * which are connected into block B of TLV320AIC34 dual codec. + * + * Copyright (C) 2008 - 2009 Nokia Corporation + * + * Contact: Peter Ujfalusi peter.ujfal...@nokia.com + * Eduardo Valentin eduardo.valen...@nokia.com + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * version 2 as published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA + * 02110-1301 USA + * + * TODO: + * - Get rid of this driver, at least when ASoC v2 is merged and when + * we can support multiple codec instances in tlv320aic3x.c driver. + * This driver is hacked only for Nokia RX51 HW. + */ + +#include linux/module.h +#include linux/errno.h +#include linux/device.h +#include linux/i2c.h +#include sound/soc.h + +#include ../codecs/tlv320aic3x.h + +struct i2c_client *aic34b_client; +static DEFINE_MUTEX(aic34b_mutex); +static DEFINE_MUTEX(button_press_mutex); +static ktime_t button_press_denial_start; +static int aic34b_volume; +static int button_press_denied; +static int aic34b_bias; + + +static int
[PATCH 7/8] ASoC: tlv320aic3x: add initial usage of regulator framework to control avdd_dac
From: Eduardo Valentin eduardo.valen...@nokia.com
This patch adds initial usage of regulator framework to control avdd_dac
inside tlv320aic3x ASoC codec driver.
The refcount to avdd_dac is increased / decreased
only during probe and remove. Here it is still needed to implement
proper enable/disable regulator depending on chip usage. Now if driver
can get regulator for avdd_dac, then it will just let it on on probe
and then leave it off on remove.
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
sound/soc/codecs/tlv320aic3x.c | 26 ++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/sound/soc/codecs/tlv320aic3x.c b/sound/soc/codecs/tlv320aic3x.c
index 3395cf9..82e0a64 100644
--- a/sound/soc/codecs/tlv320aic3x.c
+++ b/sound/soc/codecs/tlv320aic3x.c
@@ -38,6 +38,7 @@
#include linux/delay.h
#include linux/pm.h
#include linux/i2c.h
+#include linux/regulator/consumer.h
#include linux/platform_device.h
#include sound/core.h
#include sound/pcm.h
@@ -56,6 +57,7 @@ struct aic3x_priv {
struct snd_soc_codec codec;
unsigned int sysclk;
int master;
+ struct regulator *regulator;
};
/*
@@ -1286,6 +1288,11 @@ static int aic3x_unregister(struct aic3x_priv *aic3x)
snd_soc_unregister_dai(aic3x_dai);
snd_soc_unregister_codec(aic3x-codec);
+ if (aic3x-regulator) {
+ regulator_disable(aic3x-regulator);
+ regulator_put(aic3x-regulator);
+ }
+
kfree(aic3x);
aic3x_codec = NULL;
@@ -1320,6 +1327,25 @@ static int aic3x_i2c_probe(struct i2c_client *i2c,
codec-control_data = i2c;
codec-hw_write = (hw_write_t) i2c_master_send;
+ aic3x-regulator = regulator_get(i2c-dev, avdd_dac);
+ if (IS_ERR(aic3x-regulator)) {
+ dev_warn(i2c-dev, No regulator to supply avdd_dac.
+Assuming always on.\n);
+ aic3x-regulator = NULL;
+ }
+
+ /*
+* REVISIT: Need to add proper code to put into sleep mode
+* avdd_dac regulator. For now, just leave it on.
+*/
+ if (aic3x-regulator) {
+ int err;
+
+ err = regulator_enable(aic3x-regulator);
+ if (err 0)
+ return err;
+ }
+
i2c_set_clientdata(i2c, aic3x);
return aic3x_register(codec);
--
1.6.4.183.g04423
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/8] McBSP: OMAP3: Add Sidetone feature
From: Eero Nurkkala ext-eero.nurkk...@nokia.com
Add Sidetone feature to mcbsp instances 2 and 3 on OMAP3 based devices.
Signed-off-by: Eero Nurkkala ext-eero.nurkk...@nokia.com
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
arch/arm/mach-omap2/mcbsp.c |2 +
arch/arm/plat-omap/include/mach/mcbsp.h | 43
arch/arm/plat-omap/mcbsp.c | 379 ++-
3 files changed, 423 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
index a846aa1..c5b4d33 100644
--- a/arch/arm/mach-omap2/mcbsp.c
+++ b/arch/arm/mach-omap2/mcbsp.c
@@ -132,6 +132,7 @@ static struct omap_mcbsp_platform_data
omap34xx_mcbsp_pdata[] = {
},
{
.phys_base = OMAP34XX_MCBSP2_BASE,
+ .phys_base_st = OMAP34XX_MCBSP2_ST_BASE,
.dma_rx_sync= OMAP24XX_DMA_MCBSP2_RX,
.dma_tx_sync= OMAP24XX_DMA_MCBSP2_TX,
.rx_irq = INT_24XX_MCBSP2_IRQ_RX,
@@ -141,6 +142,7 @@ static struct omap_mcbsp_platform_data
omap34xx_mcbsp_pdata[] = {
},
{
.phys_base = OMAP34XX_MCBSP3_BASE,
+ .phys_base_st = OMAP34XX_MCBSP3_ST_BASE,
.dma_rx_sync= OMAP24XX_DMA_MCBSP3_RX,
.dma_tx_sync= OMAP24XX_DMA_MCBSP3_TX,
.rx_irq = INT_24XX_MCBSP3_IRQ_RX,
diff --git a/arch/arm/plat-omap/include/mach/mcbsp.h
b/arch/arm/plat-omap/include/mach/mcbsp.h
index 7e9cae3..8ecc09d 100644
--- a/arch/arm/plat-omap/include/mach/mcbsp.h
+++ b/arch/arm/plat-omap/include/mach/mcbsp.h
@@ -49,6 +49,9 @@
#define OMAP34XX_MCBSP1_BASE 0x48074000
#define OMAP34XX_MCBSP2_BASE 0x49022000
+#define OMAP34XX_MCBSP2_ST_BASE0x49028000
+#define OMAP34XX_MCBSP3_BASE 0x49024000
+#define OMAP34XX_MCBSP3_ST_BASE0x4902A000
#define OMAP34XX_MCBSP3_BASE 0x49024000
#define OMAP34XX_MCBSP4_BASE 0x49026000
#define OMAP34XX_MCBSP5_BASE 0x48096000
@@ -147,6 +150,15 @@
#define OMAP_MCBSP_REG_WAKEUPEN0xA8
#define OMAP_MCBSP_REG_XCCR0xAC
#define OMAP_MCBSP_REG_RCCR0xB0
+#define OMAP_MCBSP_REG_SSELCR 0xBC
+
+#define OMAP_ST_REG_REV0x00
+#define OMAP_ST_REG_SYSCONFIG 0x10
+#define OMAP_ST_REG_IRQSTATUS 0x18
+#define OMAP_ST_REG_IRQENABLE 0x1C
+#define OMAP_ST_REG_SGAINCR0x24
+#define OMAP_ST_REG_SFIRCR 0x28
+#define OMAP_ST_REG_SSELCR 0x2C
#define AUDIO_MCBSP_DATAWRITE (OMAP24XX_MCBSP2_BASE + OMAP_MCBSP_REG_DXR1)
#define AUDIO_MCBSP_DATAREAD (OMAP24XX_MCBSP2_BASE + OMAP_MCBSP_REG_DRR1)
@@ -265,6 +277,24 @@
#define ENAWAKEUP 0x0004
#define SOFTRST0x0002
+/** McBSP SSELCR bit definitions ***/
+#define SIDETONEEN 0x0400
+
+/** McBSP Sidetone SYSCONFIG bit definitions ***/
+#define ST_AUTOIDLE0x0001
+
+/** McBSP Sidetone SGAINCR bit definitions */
+#define ST_CH1GAIN(value) ((value16)) /* Bits 16:31 */
+#define ST_CH0GAIN(value) (value) /* Bits 0:15 */
+
+/** McBSP Sidetone SFIRCR bit definitions **/
+#define ST_FIRCOEFF(value) (value) /* Bits 0:15 */
+
+/** McBSP Sidetone SSELCR bit definitions **/
+#define ST_COEFFWRDONE 0x0004
+#define ST_COEFFWREN 0x0002
+#define ST_SIDETONEEN 0x0001
+
/** McBSP DMA operating modes **/
#define MCBSP_DMA_MODE_ELEMENT 0
#define MCBSP_DMA_MODE_THRESHOLD 1
@@ -375,10 +405,22 @@ struct omap_mcbsp_platform_data {
u16 rx_irq, tx_irq;
struct omap_mcbsp_ops *ops;
#ifdef CONFIG_ARCH_OMAP34XX
+ /* Sidetone block for McBSP 2 and 3 */
+ unsigned long phys_base_st;
u16 buffer_size;
#endif
};
+struct omap_mcbsp_st_data {
+ void __iomem *io_base_st;
+ int enabled;
+ int running;
+ s16 taps[128]; /* Sidetone filter coefficients */
+ int nr_taps;/* Number of filter coefficients in use */
+ s16 ch0gain;
+ s16 ch1gain;
+};
+
struct omap_mcbsp {
struct device *dev;
unsigned long phys_base;
@@ -411,6 +453,7 @@ struct omap_mcbsp {
struct clk *iclk;
struct clk *fclk;
#ifdef CONFIG_ARCH_OMAP34XX
+ struct omap_mcbsp_st_data *st_data;
int dma_op_mode;
u16 max_tx_thres;
u16 max_rx_thres;
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index 88ac976..9baa4b4 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -26,6 +26,9 @@
#include mach/dma.h
#include mach/mcbsp.h
+#ifdef CONFIG_ARCH_OMAP34XX
+#include ../mach-omap2/cm-regbits-34xx.h
+#endif
struct omap_mcbsp **mcbsp_ptr;
int omap_mcbsp_count;
@@ -54,6 +57,11 @@ int omap_mcbsp_read(void __iomem
Re: [PATCH 7/8] ASoC: tlv320aic3x: add initial usage of regulator framework to control avdd_dac
On Thu, 2009-10-08 at 13:58 +0200, Valentin Eduardo (Nokia-D/Helsinki)
wrote:
From: Eduardo Valentin eduardo.valen...@nokia.com
This patch adds initial usage of regulator framework to control avdd_dac
inside tlv320aic3x ASoC codec driver.
The refcount to avdd_dac is increased / decreased
only during probe and remove. Here it is still needed to implement
proper enable/disable regulator depending on chip usage. Now if driver
can get regulator for avdd_dac, then it will just let it on on probe
and then leave it off on remove.
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
sound/soc/codecs/tlv320aic3x.c | 26 ++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/sound/soc/codecs/tlv320aic3x.c b/sound/soc/codecs/tlv320aic3x.c
index 3395cf9..82e0a64 100644
--- a/sound/soc/codecs/tlv320aic3x.c
+++ b/sound/soc/codecs/tlv320aic3x.c
@@ -38,6 +38,7 @@
#include linux/delay.h
#include linux/pm.h
#include linux/i2c.h
+#include linux/regulator/consumer.h
#include linux/platform_device.h
#include sound/core.h
#include sound/pcm.h
@@ -56,6 +57,7 @@ struct aic3x_priv {
struct snd_soc_codec codec;
unsigned int sysclk;
int master;
+ struct regulator *regulator;
};
/*
@@ -1286,6 +1288,11 @@ static int aic3x_unregister(struct aic3x_priv *aic3x)
snd_soc_unregister_dai(aic3x_dai);
snd_soc_unregister_codec(aic3x-codec);
+ if (aic3x-regulator) {
+ regulator_disable(aic3x-regulator);
+ regulator_put(aic3x-regulator);
+ }
+
kfree(aic3x);
aic3x_codec = NULL;
@@ -1320,6 +1327,25 @@ static int aic3x_i2c_probe(struct i2c_client *i2c,
codec-control_data = i2c;
codec-hw_write = (hw_write_t) i2c_master_send;
+ aic3x-regulator = regulator_get(i2c-dev, avdd_dac);
+ if (IS_ERR(aic3x-regulator)) {
+ dev_warn(i2c-dev, No regulator to supply avdd_dac.
+ Assuming always on.\n);
+ aic3x-regulator = NULL;
+ }
+
+ /*
+ * REVISIT: Need to add proper code to put into sleep mode
+ * avdd_dac regulator. For now, just leave it on.
+ */
Will this ever be revisited =) ? If so, I think there's going to be a
jungle in finding the right spots - you need to remember the bypass
paths also (bias is not on necessarily). Also, this is regulator thing
is highly platform dependent, not aic3x related really at all, so is
this the correct place... Just a thought, dont take it too seriously ;)
+ if (aic3x-regulator) {
+ int err;
+
+ err = regulator_enable(aic3x-regulator);
+ if (err 0)
+ return err;
+ }
+
i2c_set_clientdata(i2c, aic3x);
return aic3x_register(codec);
--
To unsubscribe from this list: send the line unsubscribe 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/8] ASoC: TPA6130A2 amplifier driver
On Thu, 2009-10-08 at 13:58 +0200, Valentin Eduardo (Nokia-D/Helsinki)
wrote:
+/*
+ * TPA6130 volume. From -59.5 to 4 dB with increasing step size when going
+ * down in gain. Justify scale so that it is quite correct from -20 dB and
+ * up. This setting shows -30 dB at minimum, -12.95 dB at 49 % (actual
+ * is -10.3 dB) and 4.65 dB at maximum (actual is 4 dB).
+ */
The comment is misleading from all it says. For me it seems that the
scale is quite correct from -59.5 to 4 dB or so. Also the minimum is
-59.5 dB, not -30.
+static const unsigned int tpa6130_tlv[] = {
+ TLV_DB_RANGE_HEAD(10),
+ 0, 1, TLV_DB_SCALE_ITEM(-5950, 600, 0),
+ 2, 3, TLV_DB_SCALE_ITEM(-5000, 250, 0),
+ 4, 5, TLV_DB_SCALE_ITEM(-4550, 160, 0),
+ 6, 7, TLV_DB_SCALE_ITEM(-4140, 190, 0),
+ 8, 9, TLV_DB_SCALE_ITEM(-3650, 120, 0),
+ 10, 11, TLV_DB_SCALE_ITEM(-3330, 160, 0),
+ 12, 13, TLV_DB_SCALE_ITEM(-3040, 180, 0),
+ 14, 20, TLV_DB_SCALE_ITEM(-2710, 110, 0),
+ 21, 37, TLV_DB_SCALE_ITEM(-1960, 74, 0),
+ 38, 63, TLV_DB_SCALE_ITEM(-720, 45, 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 2/8] ASoC: OMAP: RX-51 Machine driver and AIC34b_dummy driver
On Thu, 2009-10-08 at 13:58 +0200, Valentin Eduardo (Nokia-D/Helsinki) wrote: From: Eduardo Valentin eduardo.valen...@nokia.com Introduce RX-51 Machine driver for ASoC and AIC34b_dummy (block B) i2c driver. Also move the request_gpio of speaker_enabled from board-rx51-peripherals.c to this machine driver. These drivers were originally written by Jarkko Nikula. Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com --- arch/arm/mach-omap2/board-rx51-peripherals.c |2 - sound/soc/omap/Kconfig | 10 + sound/soc/omap/Makefile |2 + sound/soc/omap/aic34b_dummy.c| 271 + sound/soc/omap/aic34b_dummy.h| 32 + sound/soc/omap/rx51.c| 793 ++ sound/soc/omap/rx51.h| 29 + 7 files changed, 1137 insertions(+), 2 deletions(-) create mode 100644 sound/soc/omap/aic34b_dummy.c create mode 100644 sound/soc/omap/aic34b_dummy.h create mode 100644 sound/soc/omap/rx51.c create mode 100644 sound/soc/omap/rx51.h diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c b/arch/arm/mach-omap2/board-rx51-peripherals.c index c1af532..b227475 100644 --- a/arch/arm/mach-omap2/board-rx51-peripherals.c +++ b/arch/arm/mach-omap2/board-rx51-peripherals.c @@ -262,8 +262,6 @@ static int rx51_twlgpio_setup(struct device *dev, unsigned gpio, unsigned n) /* FIXME this gpio setup is just a placeholder for now */ gpio_request(gpio + 6, backlight_pwm); gpio_direction_output(gpio + 6, 0); - gpio_request(gpio + 7, speaker_en); - gpio_direction_output(gpio + 7, 1); /* set up MMC adapters, linking their regulators to them */ twl4030_mmc_init(mmc); diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig index 2dee983..bdcd4be 100644 --- a/sound/soc/omap/Kconfig +++ b/sound/soc/omap/Kconfig @@ -15,6 +15,16 @@ config SND_OMAP_SOC_N810 help Say Y if you want to add support for SoC audio on Nokia N810. +config SND_OMAP_SOC_RX51 + tristate SoC Audio support for Nokia RX51 + depends on SND_OMAP_SOC MACH_NOKIA_RX51 + select OMAP_MCBSP + select SND_OMAP_SOC_MCBSP + select SND_SOC_TLV320AIC3X + select SND_SOC_TPA6130A2 + help + Say Y if you want to add support for SoC audio on Nokia RX51. + config SND_OMAP_SOC_AMS_DELTA tristate SoC Audio support for Amstrad E3 (Delta) videophone depends on SND_OMAP_SOC MACH_AMS_DELTA diff --git a/sound/soc/omap/Makefile b/sound/soc/omap/Makefile index 02d6947..7dec270 100644 --- a/sound/soc/omap/Makefile +++ b/sound/soc/omap/Makefile @@ -16,8 +16,10 @@ snd-soc-sdp3430-objs := sdp3430.o snd-soc-omap3pandora-objs := omap3pandora.o snd-soc-omap3beagle-objs := omap3beagle.o snd-soc-zoom2-objs := zoom2.o +snd-soc-rx51-objs := rx51.o obj-$(CONFIG_SND_OMAP_SOC_N810) += snd-soc-n810.o +obj-$(CONFIG_SND_OMAP_SOC_RX51) += snd-soc-rx51.o aic34b_dummy.o obj-$(CONFIG_SND_OMAP_SOC_AMS_DELTA) += snd-soc-ams-delta.o obj-$(CONFIG_SND_OMAP_SOC_OSK5912) += snd-soc-osk5912.o obj-$(CONFIG_SND_OMAP_SOC_OVERO) += snd-soc-overo.o diff --git a/sound/soc/omap/aic34b_dummy.c b/sound/soc/omap/aic34b_dummy.c new file mode 100644 index 000..17c4d9c --- /dev/null +++ b/sound/soc/omap/aic34b_dummy.c @@ -0,0 +1,271 @@ +/* + * aic34b_dummy.c -- Dummy driver for AIC34 block B parts used in Nokia RX51 + * + * Purpose for this driver is to cover few audio connections on Nokia RX51 HW + * which are connected into block B of TLV320AIC34 dual codec. + * + * Copyright (C) 2008 - 2009 Nokia Corporation + * + * Contact: Peter Ujfalusi peter.ujfal...@nokia.com + * Eduardo Valentin eduardo.valen...@nokia.com + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * version 2 as published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA + * 02110-1301 USA + * + * TODO: + * - Get rid of this driver, at least when ASoC v2 is merged and when + * we can support multiple codec instances in tlv320aic3x.c driver. + * This driver is hacked only for Nokia RX51 HW. + */ + +#include linux/module.h +#include linux/errno.h +#include linux/device.h +#include linux/i2c.h +#include sound/soc.h + +#include ../codecs/tlv320aic3x.h + +struct i2c_client *aic34b_client; +static DEFINE_MUTEX(aic34b_mutex);
omap850 omap730 rtc
Hi, I'm currently very close to finishing the rtc working on my htc wizard (omap850). During boot-up, I see: omap_rtc omap_rtc: setting system clock to 2009-09-08 12:47:02 UTC (1252414022) which is the correct time, however, trying to read /dev/rtc0 fails: select() to /dev/rtc0 to wait for clock tick timed out Any ideas? Chris -- To unsubscribe from this list: send the line unsubscribe 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] OMAP3: add platform devices for ETM and ETB
This enables debug components found in omap3xxx.
Signed-off-by: Alexander Shishkin virtu...@slind.org
---
arch/arm/mach-omap2/Kconfig |7
arch/arm/mach-omap2/Makefile |3 ++
arch/arm/mach-omap2/emu.c| 70 ++
3 files changed, 80 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/emu.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 75b1c7e..87bcc2a 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -88,3 +88,10 @@ config MACH_OMAP_ZOOM2
config MACH_OMAP_4430SDP
bool OMAP 4430 SDP board
depends on ARCH_OMAP4
+
+config OMAP3_EMU
+ tristate OMAP3 debugging peripherals
+ depends on ARCH_OMAP3 OC_ETM
+ help
+ Say Y here to enable debugging hardware of omap3
+
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 6b7702f..572dd27 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -44,6 +44,9 @@ obj-$(CONFIG_ARCH_OMAP4) += cm4xxx.o
obj-$(CONFIG_ARCH_OMAP2) += clock24xx.o
obj-$(CONFIG_ARCH_OMAP3) += clock34xx.o
+# EMU periferals
+obj-$(CONFIG_OMAP3_EMU)+= emu.o
+
iommu-y+= iommu2.o
iommu-$(CONFIG_ARCH_OMAP3) += omap3-iommu.o
diff --git a/arch/arm/mach-omap2/emu.c b/arch/arm/mach-omap2/emu.c
new file mode 100644
index 000..f98874e
--- /dev/null
+++ b/arch/arm/mach-omap2/emu.c
@@ -0,0 +1,70 @@
+/*
+ * linux/arch/arm/mach-omap2/emu.c
+ *
+ * ETM and ETB CoreSight components' resources as found in OMAP3xxx.
+ *
+ * Copyright (C) 2009 Nokia Corporation.
+ * Alexander Shishkin
+ *
+ * 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 linux/kernel.h
+#include linux/init.h
+#include linux/types.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/io.h
+
+MODULE_LICENSE(GPL);
+MODULE_AUTHOR(Alexander Shishkin);
+
+/* Cortex CoreSight components within omap3xxx EMU */
+#define ETM_BASE (L4_EMU_34XX_PHYS + 0x1)
+#define DBG_BASE (L4_EMU_34XX_PHYS + 0x11000)
+#define ETB_BASE (L4_EMU_34XX_PHYS + 0x1b000)
+#define DAPCTL (L4_EMU_34XX_PHYS + 0x1d000)
+
+static struct resource rx51_etb_resource = {
+ .start = ETB_BASE,
+ .end = ETB_BASE + SZ_4K,
+ .flags = IORESOURCE_MEM,
+};
+
+static struct platform_device rx51_etb_device = {
+ .name = etb,
+ .id = -1,
+ .num_resources = 1,
+ .resource = rx51_etb_resource,
+};
+
+static struct resource rx51_etm_resource = {
+ .start = ETM_BASE,
+ .end = ETM_BASE + SZ_4K,
+ .flags = IORESOURCE_MEM,
+};
+
+static struct platform_device rx51_etm_device = {
+ .name = etm,
+ .id = -1,
+ .num_resources = 1,
+ .resource = rx51_etm_resource,
+};
+
+static struct platform_device *rx51_trace_devices[] = {
+ rx51_etm_device,
+ rx51_etb_device,
+};
+
+static int __init emu_init(void)
+{
+ platform_add_devices(rx51_trace_devices,
+ ARRAY_SIZE(rx51_trace_devices));
+
+ return 0;
+}
+
+module_init(emu_init);
+
--
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 1/2] arm: a driver for on-chip ETM and ETB
This driver implements support for on-chip Embedded Tracing Macrocell and
Embedded Trace Buffer. It allows to trigger tracing of kernel execution flow
and exporting trace output to userspace via character device and a sysrq
combo.
Trace output can then be decoded by a fairly simple open source tool [1]
which is already sufficient to get the idea of what the kernel is doing.
[1]: http://github.com/virtuoso/etm2human
Signed-off-by: Alexander Shishkin virtu...@slind.org
---
arch/arm/Kconfig.debug|8 +
arch/arm/include/asm/hardware/coresight.h | 164
arch/arm/kernel/Makefile |2 +
arch/arm/kernel/etm.c | 584 +
4 files changed, 758 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/include/asm/hardware/coresight.h
create mode 100644 arch/arm/kernel/etm.c
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 1a6f70e..ac83c03 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -83,6 +83,14 @@ config DEBUG_ICEDCC
It does include a timeout to ensure that the system does not
totally freeze when there is nothing connected to read.
+config OC_ETM
+ tristate On-chip ETM and ETB
+ depends on ARCH_OMAP3
+ help
+ Enables the on-chip embedded trace macrocell and embedded trace
+ buffer driver that will allow you to collect traces of the
+ kernel code.
+
config DEBUG_DC21285_PORT
bool Kernel low-level debugging messages via footbridge serial port
depends on DEBUG_LL FOOTBRIDGE
diff --git a/arch/arm/include/asm/hardware/coresight.h
b/arch/arm/include/asm/hardware/coresight.h
new file mode 100644
index 000..ba22df9
--- /dev/null
+++ b/arch/arm/include/asm/hardware/coresight.h
@@ -0,0 +1,164 @@
+/*
+ * linux/arch/arm/include/asm/hardware/coresight.h
+ *
+ * CoreSight components' registers
+ *
+ * Copyright (C) 2009 Nokia Corporation.
+ * Alexander Shishkin
+ *
+ * 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.
+ */
+
+#ifndef __ASM_HARDWARE_CORESIGHT_H
+#define __ASM_HARDWARE_CORESIGHT_H
+
+#define TRACER_ACCESSED_BIT0
+#define TRACER_RUNNING_BIT 1
+#define TRACER_CYCLE_ACC_BIT 2
+#define TRACER_ACCESSEDBIT(TRACER_ACCESSED_BIT)
+#define TRACER_RUNNING BIT(TRACER_RUNNING_BIT)
+#define TRACER_CYCLE_ACC BIT(TRACER_CYCLE_ACC_BIT)
+
+struct tracectx {
+ unsigned int etb_bufsz;
+ void __iomem *etb_regs;
+ void __iomem *etm_regs;
+ unsigned long flags;
+ int ncmppairs;
+ int etm_portsz;
+ struct device *dev;
+ struct mutex mutex;
+};
+
+#define TRACER_TIMEOUT 1
+
+#define etm_writel(t, v, x) \
+ (__raw_writel((v), (t)-etm_regs + (x)))
+#define etm_readl(t, x) (__raw_readl((t)-etm_regs + (x)))
+
+/* CoreSight Management Registers */
+#define CSMR_LOCKACCESS 0xfb0
+#define CSMR_LOCKSTATUS 0xfb4
+#define CSMR_AUTHSTATUS 0xfb8
+#define CSMR_DEVID 0xfc8
+#define CSMR_DEVTYPE 0xfcc
+/* CoreSight Component Registers */
+#define CSCR_CLASS 0xff4
+
+#define CSCR_PRSR 0x314
+
+#define UNLOCK_MAGIC 0xc5acce55
+
+/* ETM control register, ETM Architecture, 3.3.1 */
+#define ETMR_CTRL 0
+#define ETMCTRL_POWERDOWN 1
+#define ETMCTRL_PROGRAM(1 10)
+#define ETMCTRL_PORTSEL(1 11)
+#define ETMCTRL_DO_CONTEXTID (3 14)
+#define ETMCTRL_PORTMASK1 (7 4)
+#define ETMCTRL_PORTMASK2 (1 21)
+#define ETMCTRL_PORTMASK (ETMCTRL_PORTMASK1 | ETMCTRL_PORTMASK2)
+#define ETMCTRL_PORTSIZE(x) x) 7) 4) | (!!((x) 8)) 21)
+#define ETMCTRL_DO_CPRT(1 1)
+#define ETMCTRL_DATAMASK (3 2)
+#define ETMCTRL_DATA_DO_DATA (1 2)
+#define ETMCTRL_DATA_DO_ADDR (1 3)
+#define ETMCTRL_DATA_DO_BOTH (ETMCTRL_DATA_DO_DATA | ETMCTRL_DATA_DO_ADDR)
+#define ETMCTRL_BRANCH_OUTPUT (1 8)
+#define ETMCTRL_CYCLEACCURATE (1 12)
+
+/* ETM configuration code register */
+#define ETMR_CONFCODE (0x04)
+
+/* ETM trace start/stop resource control register */
+#define ETMR_TRACESSCTRL (0x18)
+
+/* ETM trigger event register */
+#define ETMR_TRIGEVT (0x08)
+
+/* address access type register bits, ETM architecture,
+ * table 3-27 */
+/* - access type */
+#define ETMAAT_IFETCH 0
+#define ETMAAT_IEXEC 1
+#define ETMAAT_IEXECPASS 2
+#define ETMAAT_IEXECFAIL 3
+#define ETMAAT_DLOADSTORE 4
+#define ETMAAT_DLOAD 5
+#define ETMAAT_DSTORE 6
+/* - comparison access size */
+#define ETMAAT_JAVA(0 3)
+#define ETMAAT_THUMB (1 3)
+#define ETMAAT_ARM (3 3)
+/* - data value comparison control */
+#define ETMAAT_NOVALCMP(0 5)
+#define ETMAAT_VALMATCH(1 5)
+#define
Re: [PATCH 1/8] ASoC: TPA6130A2 amplifier driver
On Thu, Oct 08, 2009 at 02:58:50PM +0300, Eduardo Valentin wrote:
+struct tpa6130a2_platform_data {
+ int (*set_power)(int state);
+};
Why is this a callback and not just a GPIO number? That'd seem simpler
for users.
+int tpa6130a2_add_controls(struct snd_soc_codec *codec)
+{
+ snd_soc_dapm_new_controls(codec, tpa6130a2_dapm_widgets,
+ ARRAY_SIZE(tpa6130a2_dapm_widgets));
+
+ return snd_soc_add_controls(codec, tpa6130a2_controls,
+ ARRAY_SIZE(tpa6130a2_controls));
+
+}
+EXPORT_SYMBOL(tpa6130a2_add_controls);
All the ASoC APIs are EXPORT_SYMBOL_GPL().
+ pdata = (struct tpa6130a2_platform_data *)client-dev.platform_data;
+ /* Set default register values */
+ data-regs[TPA6130A2_REG_CONTROL] = TPA6130A2_SWS |
+ TPA6130A2_HP_EN_R |
+ TPA6130A2_HP_EN_L;
This looks like you could implement stereo paths with individual power
control?
+ data-regs[TPA6130A2_REG_VOL_MUTE] = TPA6130A2_VOLUME(20);
The standard thing is to use hardware defaults and leave decisions like
this up to user space.
+ data-set_power = pdata-set_power;
+ if (!pdata-set_power) {
+ data-power_state = 1;
+ tpa6130a2_initialize();
+ }
+ tpa6130a2_power(1);
+
+ /* Read version */
+ err = tpa6130a2_i2c_read(TPA6130A2_REG_VERSION)
+ TPA6130A2_VERSION_MASK;
+ if ((err != 1) (err != 2)) {
+ dev_err(dev, Unexpected headphone amplifier chip version
+of 0x%02x, was expecting 0x01 or 0x02\n, err);
+ err = -ENODEV;
This seems a bit excessive - is it really likely that the register map
would be changed incompatibly in a future version?
--
To unsubscribe from this list: send the line unsubscribe 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/8] ASoC: TPA6130A2 amplifier driver
On Thursday 08 October 2009 15:30:29 Nurkkala Eero.An (EXT-Offcode/Oulu) wrote: On Thu, 2009-10-08 at 13:58 +0200, Valentin Eduardo (Nokia-D/Helsinki) wrote: +/* + * TPA6130 volume. From -59.5 to 4 dB with increasing step size when going + * down in gain. Justify scale so that it is quite correct from -20 dB and + * up. This setting shows -30 dB at minimum, -12.95 dB at 49 % (actual + * is -10.3 dB) and 4.65 dB at maximum (actual is 4 dB). + */ The comment is misleading from all it says. For me it seems that the scale is quite correct from -59.5 to 4 dB or so. Also the minimum is -59.5 dB, not -30. Yes, the scale is really close to the reality, the comment need to be fixed. -- 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: [PATCH 2/8] ASoC: OMAP: RX-51 Machine driver and AIC34b_dummy driver
On Thu, Oct 08, 2009 at 02:58:51PM +0300, Eduardo Valentin wrote:
From: Eduardo Valentin eduardo.valen...@nokia.com
Introduce RX-51 Machine driver for ASoC and AIC34b_dummy (block B) i2c driver.
What is an AIC34b_dummy (block B)? You probably want to split it out
into a separate patch.
+ * TODO:
+ * - Get rid of this driver, at least when ASoC v2 is merged and when
+ * we can support multiple codec instances in tlv320aic3x.c driver.
+ * This driver is hacked only for Nokia RX51 HW.
Could you please explain what the issue here is? A description of the
hardware would go a long way here.
+EXPORT_SYMBOL(aic34b_set_mic_bias);
EXPORT_SYMBOL_GPL().
+static void rx51_set_eci_switches(int mode)
+{
+ switch (mode) {
+ case 0: /* Bias off */
+ case 1: /* Bias according to rx51_dapm_jack_bias */
+ case 4: /* Bias on */
+ /* Codec connected to mic/bias line */
+ gpio_set_value(RX51_ECI_SWITCH_1_GPIO, 0);
+ gpio_set_value(RX51_ECI_SWITCH_2_GPIO, 1);
+ break;
+ case 2:
+ /* ECI INT#2 detect connected to mic/bias line */
+ gpio_set_value(RX51_ECI_SWITCH_1_GPIO, 0);
+ gpio_set_value(RX51_ECI_SWITCH_2_GPIO, 0);
+ break;
+ case 3:
+ /* ECI RX/TX connected to mic/bias line */
+ gpio_set_value(RX51_ECI_SWITCH_1_GPIO, 1);
+ gpio_set_value(RX51_ECI_SWITCH_2_GPIO, 0);
+ break;
+ }
Some defines for the mode (instead of magic numbers) would be nice).
+void rx51_jack_report(int status)
+{
+ snd_jack_report(rx51_jack, status);
+}
+EXPORT_SYMBOL(rx51_jack_report);
Why is this being exported?
+enum {
+ RX51_EXT_API_AIC34B,
+};
+#define SOC_RX51_EXT_SINGLE_TLV(xname, ext_api, max, tlv_array) \
+{ \
+ .iface = SNDRV_CTL_ELEM_IFACE_MIXER, \
+ .name = xname, \
+ .access = SNDRV_CTL_ELEM_ACCESS_TLV_READ | \
+ SNDRV_CTL_ELEM_ACCESS_READWRITE, \
+ .tlv.p = (tlv_array), \
+ .info = rx51_ext_info_volsw, \
+ .get = rx51_ext_get_volsw, \
+ .put = rx51_ext_put_volsw, \
+ .private_value = (ext_api) 26 | (max) 16, \
+}
This looks like it ought to be pushed down into some other driver?
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/8] McBSP: OMAP3: Add Sidetone feature
On Thu, Oct 08, 2009 at 02:58:52PM +0300, Eduardo Valentin wrote:
+static const struct attribute *sidetone_attrs[] = {
+ dev_attr_st_enable.attr,
+ dev_attr_st_taps.attr,
+ dev_attr_st_ch0gain.attr,
+ dev_attr_st_ch1gain.attr,
+ NULL,
+};
This stuff, particularly the enable, probably wants to be pushed out via
an ALSA API rather than via random sysfs stuff. It'd be better to
publish a control API here and then use that from within ALSA.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
X-loader / U-Boot query
I have a new board - OMAP 3530 with 512MB DRAM NAND I've build X-loader and U-Boot for it and it mostly comes up. The sources I used (based on recommendations from the BeagleBoard pages) were: http://git.gitorious.org/x-load-omap3/mainline.git git://git.denx.de/u-boot.git I had to make a small change to get it to recognize the larger NAND FLASH device. The problem I have now is that it's only seeing 1/2 (256MB) of the available DRAM. * Does anyone know how to get it to see all 512MB? * Is there a better place to ask/discuss these questions? A cursory look around did not point to anything fresh (most of the web pages Wikis I looked are are _years_ old) Thanks for any help/pointers -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe 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 7/8] ASoC: tlv320aic3x: add initial usage of regulator framework to control avdd_dac
On Thu, Oct 08, 2009 at 02:17:07PM +0200, Nurkkala Eero.An (EXT-Offcode/Oulu)
wrote:
On Thu, 2009-10-08 at 13:58 +0200, Valentin Eduardo (Nokia-D/Helsinki)
wrote:
From: Eduardo Valentin eduardo.valen...@nokia.com
This patch adds initial usage of regulator framework to control avdd_dac
inside tlv320aic3x ASoC codec driver.
The refcount to avdd_dac is increased / decreased
only during probe and remove. Here it is still needed to implement
proper enable/disable regulator depending on chip usage. Now if driver
can get regulator for avdd_dac, then it will just let it on on probe
and then leave it off on remove.
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
sound/soc/codecs/tlv320aic3x.c | 26 ++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/sound/soc/codecs/tlv320aic3x.c b/sound/soc/codecs/tlv320aic3x.c
index 3395cf9..82e0a64 100644
--- a/sound/soc/codecs/tlv320aic3x.c
+++ b/sound/soc/codecs/tlv320aic3x.c
@@ -38,6 +38,7 @@
#include linux/delay.h
#include linux/pm.h
#include linux/i2c.h
+#include linux/regulator/consumer.h
#include linux/platform_device.h
#include sound/core.h
#include sound/pcm.h
@@ -56,6 +57,7 @@ struct aic3x_priv {
struct snd_soc_codec codec;
unsigned int sysclk;
int master;
+ struct regulator *regulator;
};
/*
@@ -1286,6 +1288,11 @@ static int aic3x_unregister(struct aic3x_priv *aic3x)
snd_soc_unregister_dai(aic3x_dai);
snd_soc_unregister_codec(aic3x-codec);
+ if (aic3x-regulator) {
+ regulator_disable(aic3x-regulator);
+ regulator_put(aic3x-regulator);
+ }
+
kfree(aic3x);
aic3x_codec = NULL;
@@ -1320,6 +1327,25 @@ static int aic3x_i2c_probe(struct i2c_client *i2c,
codec-control_data = i2c;
codec-hw_write = (hw_write_t) i2c_master_send;
+ aic3x-regulator = regulator_get(i2c-dev, avdd_dac);
+ if (IS_ERR(aic3x-regulator)) {
+ dev_warn(i2c-dev, No regulator to supply avdd_dac.
+Assuming always on.\n);
+ aic3x-regulator = NULL;
+ }
+
+ /*
+* REVISIT: Need to add proper code to put into sleep mode
+* avdd_dac regulator. For now, just leave it on.
+*/
Will this ever be revisited =) ? If so, I think there's going to be a
jungle in finding the right spots - you need to remember the bypass
paths also (bias is not on necessarily). Also, this is regulator thing
is highly platform dependent, not aic3x related really at all, so is
this the correct place... Just a thought, dont take it too seriously ;)
Heheh.. no I don't take it too seriously, don't worry :-)
Actually I've discussed about it with Peter. Initially I wrote it
inside rx51 machine driver. But then, we agreed it is actually a
thing which must be controlled by the driver. The same way it is done
for TPA for instance.
Of course, the presence of that regulator must not be a blocker for
the driver. As you can see, if the regulator can not be queried, the driver
will assume that it is always on.
I must agree with you, but would rephrase as: the presence of this regulator
is board specific, but controlling when it must be enabled/disabled is a role
for the driver, in this case, tlv320aic3x.
What do you think ?
+ if (aic3x-regulator) {
+ int err;
+
+ err = regulator_enable(aic3x-regulator);
+ if (err 0)
+ return err;
+ }
+
i2c_set_clientdata(i2c, aic3x);
return aic3x_register(codec);
--
Eduardo Valentin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/8] ASoC: OMAP: RX-51 Machine driver and AIC34b_dummy driver
On Thu, Oct 08, 2009 at 02:31:26PM +0200, Nurkkala Eero.An (EXT-Offcode/Oulu)
wrote:
On Thu, 2009-10-08 at 13:58 +0200, Valentin Eduardo (Nokia-D/Helsinki)
wrote:
From: Eduardo Valentin eduardo.valen...@nokia.com
Introduce RX-51 Machine driver for ASoC and AIC34b_dummy (block B) i2c
driver.
Also move the request_gpio of speaker_enabled
from board-rx51-peripherals.c to this machine driver.
These drivers were originally written by Jarkko Nikula.
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
arch/arm/mach-omap2/board-rx51-peripherals.c |2 -
sound/soc/omap/Kconfig | 10 +
sound/soc/omap/Makefile |2 +
sound/soc/omap/aic34b_dummy.c| 271 +
sound/soc/omap/aic34b_dummy.h| 32 +
sound/soc/omap/rx51.c| 793
++
sound/soc/omap/rx51.h| 29 +
7 files changed, 1137 insertions(+), 2 deletions(-)
create mode 100644 sound/soc/omap/aic34b_dummy.c
create mode 100644 sound/soc/omap/aic34b_dummy.h
create mode 100644 sound/soc/omap/rx51.c
create mode 100644 sound/soc/omap/rx51.h
snip
+static struct platform_device *rx51_snd_device;
+
+#define REMAP_OFFSET 2
+#define DEDICATED_OFFSET 3
+#define VMMC2_DEV_GRP 0x2B
+#define VMMC2_285V 0x0a
+
These defines appear unused?
yeah, will rip then off.
+static int __init rx51_soc_init(void)
+{
+ int err;
+ struct device *dev;
+
+ if (!machine_is_nokia_rx51())
+ return -ENODEV;
+
+ if (gpio_request(RX51_CODEC_RESET_GPIO, NULL) 0)
+ BUG();
+ if (gpio_request(RX51_TVOUT_SEL_GPIO, tvout_sel) 0)
+ BUG();
+ if (gpio_request(RX51_ECI_SWITCH_1_GPIO, ECI switch 1) 0)
+ BUG();
+ if (gpio_request(RX51_ECI_SWITCH_2_GPIO, ECI switch 2) 0)
+ BUG();
+ gpio_direction_output(RX51_CODEC_RESET_GPIO, 0);
+ gpio_direction_output(RX51_TVOUT_SEL_GPIO, 0);
+ gpio_direction_output(RX51_ECI_SWITCH_1_GPIO, 0);
+ gpio_direction_output(RX51_ECI_SWITCH_2_GPIO, 1);
+
+ gpio_set_value(RX51_CODEC_RESET_GPIO, 0);
+ udelay(1);
+ gpio_set_value(RX51_CODEC_RESET_GPIO, 1);
+ msleep(1);
+
+ if (gpio_request(RX51_SPEAKER_AMP_TWL_GPIO, NULL) 0)
+ BUG();
+ gpio_direction_output(RX51_SPEAKER_AMP_TWL_GPIO, 0);
+
+ err = snd_soc_register_dai(btcodec_dai);
+ if (err)
+ return err;
+
+ rx51_snd_device = platform_device_alloc(soc-audio, -1);
+ if (!rx51_snd_device) {
+ err = -ENOMEM;
+ goto err0;
+ }
+
+ platform_set_drvdata(rx51_snd_device, rx51_snd_devdata);
+ rx51_snd_devdata.dev = rx51_snd_device-dev;
+ err = platform_device_add(rx51_snd_device);
+ if (err)
+ goto err1;
+
+ dev = rx51_snd_device-dev;
+
+ *(unsigned int *)rx51_dai[0].cpu_dai-private_data = 1;
+ *(unsigned int *)rx51_dai[1].cpu_dai-private_data = 2;
+
+ err = device_create_file(dev, dev_attr_eci_mode);
+ if (err)
+ goto err2;
+
+ return err;
+err2:
+ platform_device_del(rx51_snd_device);
+err1:
+ platform_device_put(rx51_snd_device);
+err0:
+ snd_soc_unregister_dai(btcodec_dai);
+
+ return err;
+
+}
+
+static void __exit rx51_soc_exit(void)
+{
+ platform_device_unregister(rx51_snd_device);
+ snd_soc_unregister_dai(btcodec_dai);
+}
+
+module_init(rx51_soc_init);
+module_exit(rx51_soc_exit);
+
+MODULE_AUTHOR(Nokia Corporation);
+MODULE_DESCRIPTION(ALSA SoC Nokia RX51);
+MODULE_LICENSE(GPL);
diff --git a/sound/soc/omap/rx51.h b/sound/soc/omap/rx51.h
new file mode 100644
index 000..ee55260
--- /dev/null
+++ b/sound/soc/omap/rx51.h
@@ -0,0 +1,29 @@
+#ifndef _RX51_H_
+#define _RX51_H_
+
+/*
+ * rx51.h - SoC audio for Nokia RX51
+ *
+ * Copyright (C) 2008 - 2009 Nokia Corporation
+ *
+ * Contact: Peter Ujfalusi peter.ujfal...@nokia.com
+ * Eduardo Valentin eduardo.valen...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write
Re: [PATCH 5/8] board-rx51-peripherals: split vaux3 and vmmc2 supplies
On Thu, Oct 08, 2009 at 02:58:54PM +0300, Eduardo Valentin wrote:
From: Eduardo Valentin eduardo.valen...@nokia.com
Use separated supplies for vaux3 and vmmc2.
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
+static struct regulator_consumer_supply rx51_vaux3_supply = {
+ .supply = vmmc,
+};
+
I'd expect all these supplies to have devices associated with them (see
below)...
static struct regulator_consumer_supply rx51_vmmc2_supply = {
.supply = vmmc,
};
@@ -184,7 +188,7 @@ static struct regulator_init_data rx51_vaux3_mmc = {
| REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies = 1,
- .consumer_supplies = rx51_vmmc2_supply,
+ .consumer_supplies = rx51_vaux3_supply,
};
I may have missed it but I don't see rx51_vmmc2_supply added back
anywhere in the patch?
static struct regulator_init_data rx51_vaux4 = {
@@ -266,7 +270,7 @@ static int rx51_twlgpio_setup(struct device *dev,
unsigned gpio, unsigned n)
/* set up MMC adapters, linking their regulators to them */
twl4030_mmc_init(mmc);
rx51_vmmc1_supply.dev = mmc[0].dev;
- rx51_vmmc2_supply.dev = mmc[1].dev;
+ rx51_vaux3_supply.dev = mmc[1].dev;
...using dev_name rather than dev should avoid the need to do this at
runtime.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/8] McBSP: OMAP3: Add Sidetone feature
On Thu, Oct 08, 2009 at 03:17:02PM +0200, Mark Brown wrote:
On Thu, Oct 08, 2009 at 02:58:52PM +0300, Eduardo Valentin wrote:
+static const struct attribute *sidetone_attrs[] = {
+ dev_attr_st_enable.attr,
+ dev_attr_st_taps.attr,
+ dev_attr_st_ch0gain.attr,
+ dev_attr_st_ch1gain.attr,
+ NULL,
+};
This stuff, particularly the enable, probably wants to be pushed out via
an ALSA API rather than via random sysfs stuff. It'd be better to
publish a control API here and then use that from within ALSA.
I see. The thing is this mcbsp driver is kinda of odd driver.
It is currently a platform driver. And it is supposed to be not
restricted to audio things (even though it is currently used only
by audio). It does not export any alsa interface currently.
So, maybe we should rip off this sysfs things, export
symbols inside kernel and then export to user land somewhere else
from alsa code?
--
Eduardo Valentin
--
To unsubscribe from this list: send the line unsubscribe 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 6/8] RX-51: Audio: Add usage of regulator framework to control VMMC2
On Thu, Oct 08, 2009 at 02:58:55PM +0300, Eduardo Valentin wrote:
+static struct regulator_consumer_supply rx51_vmmc2_supplies[] = {
+ REGULATOR_SUPPLY(avdd_dac, 2-0018), /* tlv320aic3x */
+ REGULATOR_SUPPLY(vdd, 2-0060), /* tpa6130a2*/
};
avdd_dac is the only supply added for the tlv320aic3x but, for example,
the tlv320aic34 has something like 8 supplies from a quick scan of the
datasheet. It'd be better to set up all of the supplies, even if only
with a fixed voltage regulator supplying them, since when regulator
support is added to the CODEC driver it should be requesting all the
supplies it needs and therefore fail to instatiate if some are missing.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/8] McBSP: OMAP3: Add Sidetone feature
On Thu, Oct 08, 2009 at 04:23:33PM +0300, Eduardo Valentin wrote: So, maybe we should rip off this sysfs things, export symbols inside kernel and then export to user land somewhere else from alsa code? Yes, that's what I'm suggesting. Provide an API to ALSA and then let ALSA worry about the control stuff. -- To unsubscribe from this list: send the line unsubscribe 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][PATCH] OMAP3: introduce OMAP3630
-Original Message- From: Shilimkar, Santosh diff --git a/arch/arm/plat-omap/include/mach/cpu.h b/arch/arm/plat- omap/include/mach/cpu.h index 431fec4..af1080f 100644 --- a/arch/arm/plat-omap/include/mach/cpu.h +++ b/arch/arm/plat-omap/include/mach/cpu.h @@ -383,6 +383,12 @@ IS_OMAP_TYPE(3430, 0x3430) #define OMAP3430_REV_ES2_1 0x34302034 #define OMAP3430_REV_ES3_0 0x34303034 #define OMAP3430_REV_ES3_1 0x34304034 +/* NOTE: Add 36xx series below + * If additional 34xx series are added, OMAP3430_REV_ES can be + * added above the 3630 defines and series renumbered to ensure + * rev() checks to work + */ +#define OMAP3630_REV_ES1_0 0x34305034 #define OMAP443X_CLASS 0x44300034 Was expecting that this patch will add cpu_is_omap36xx() in cpu.h apart from above. Is this handled in another patch ? Idea is to re-use all 34xx code for 36xx, as per the mail thread on list, and given in reference. Hence at run time, the check could be: if (omap_rev() == OMAP3630_REV_ES1_0) x cpu_is_omap34xx() will be true for 36xx as well. Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/8] ASoC: tlv320aic3x: add initial usage of regulator framework to control avdd_dac
On Thu, Oct 08, 2009 at 02:58:56PM +0300, Eduardo Valentin wrote:
This patch adds initial usage of regulator framework to control avdd_dac
inside tlv320aic3x ASoC codec driver.
If you're going to do this you should add support for all the supplies
of the device, not just one of them. The extra effort required is low
and it avoids compatibility problems when someone wants to set up other
supplies, causing existing boards to need to specify them.
+ aic3x-regulator = regulator_get(i2c-dev, avdd_dac);
+ if (IS_ERR(aic3x-regulator)) {
+ dev_warn(i2c-dev, No regulator to supply avdd_dac.
+ Assuming always on.\n);
You shouldn't split error messages over multiple lines like this, it
breaks grepping to try to find where the message came from.
I'd also rather see failure to get the regulator treated as a hard
error. When the regulator API compiled out it is stubbed so that for
simple get/enable/disable/put usage it will return success but do
nothing. If the regulator API is compiled in and we're not able to
acquire regulators there's a good chance that things will break (eg, due
to supplies being turned off because they appear to be unused) so
flagging the error immediately is less likely to result in runtime
fragility.
+ /*
+ * REVISIT: Need to add proper code to put into sleep mode
+ * avdd_dac regulator. For now, just leave it on.
+ */
+ if (aic3x-regulator) {
+ int err;
+
+ err = regulator_enable(aic3x-regulator);
+ if (err 0)
+ return err;
+ }
The best way to handle this is to push the enable/disable into the bias
level configuration so that the regulators are enabled when the chip
goes off-standby and disabled during standby-off. This will have the
same effect for the moment but will mean that we'll be able to add core
support for fully powering down the audio subsystem at runtime in the
future.
--
To unsubscribe from this list: send the line unsubscribe 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/8] ASoC: TPA6130A2 amplifier driver
On Thursday 08 October 2009 15:52:13 ext Mark Brown wrote:
On Thu, Oct 08, 2009 at 02:58:50PM +0300, Eduardo Valentin wrote:
+struct tpa6130a2_platform_data {
+ int (*set_power)(int state);
+};
Why is this a callback and not just a GPIO number? That'd seem simpler
for users.
Well, same amount of code, but in different place if the power is enabled
through a GPIO. But if the power is controlled via different means (nothing
comes to mind, but there are exotic systems out there), in this way it is
simple
to handle
+int tpa6130a2_add_controls(struct snd_soc_codec *codec)
+{
+ snd_soc_dapm_new_controls(codec, tpa6130a2_dapm_widgets,
+ ARRAY_SIZE(tpa6130a2_dapm_widgets));
+
+ return snd_soc_add_controls(codec, tpa6130a2_controls,
+ ARRAY_SIZE(tpa6130a2_controls));
+
+}
+EXPORT_SYMBOL(tpa6130a2_add_controls);
All the ASoC APIs are EXPORT_SYMBOL_GPL().
Right.
+ pdata = (struct tpa6130a2_platform_data *)client-dev.platform_data;
+ /* Set default register values */
+ data-regs[TPA6130A2_REG_CONTROL] = TPA6130A2_SWS |
+ TPA6130A2_HP_EN_R |
+ TPA6130A2_HP_EN_L;
This looks like you could implement stereo paths with individual power
control?
Can we put something in between DAPM_OUTPUT and DAPM_HP to handle the stereo
path correctly?
We could have two paths from codec to the TPA6130A2 Headphone, which is
needed
to actually control the power of the amplifier.
At the end we are not really gaining much, but one more level of switch on the
path.
We could have simple mute alsa controls in tpa6130a2_controls for the amplifier
itself...
+ data-regs[TPA6130A2_REG_VOL_MUTE] = TPA6130A2_VOLUME(20);
The standard thing is to use hardware defaults and leave decisions like
this up to user space.
OK, The reset value is 0 (-59.5 dB)
+ data-set_power = pdata-set_power;
+ if (!pdata-set_power) {
+ data-power_state = 1;
+ tpa6130a2_initialize();
+ }
+ tpa6130a2_power(1);
+
+ /* Read version */
+ err = tpa6130a2_i2c_read(TPA6130A2_REG_VERSION)
+TPA6130A2_VERSION_MASK;
+ if ((err != 1) (err != 2)) {
+ dev_err(dev, Unexpected headphone amplifier chip version
+ of 0x%02x, was expecting 0x01 or 0x02\n, err);
+ err = -ENODEV;
This seems a bit excessive - is it really likely that the register map
would be changed incompatibly in a future version?
Hmm, we have only seen these versions of the chip, and we know that the driver
works with these. Also we don't have any information on different versions, but
I would think that the register map is not changing (the reset values for some
registers are different)
--
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: [PATCH 7/8] ASoC: tlv320aic3x: add initial usage of regulator framework to control avdd_dac
On Thu, Oct 08, 2009 at 03:17:07PM +0300, Eero Nurkkala wrote: Will this ever be revisited =) ? If so, I think there's going to be a jungle in finding the right spots - you need to remember the bypass paths also (bias is not on necessarily). The bias is always on when any path through the chip is on, this was fixed in either .31 or .30. Also, this is regulator thing is highly platform dependent, not aic3x related really at all, so is this the correct place... Just a thought, dont take it too seriously ;) I'm not sure what you mean by this? -- To unsubscribe from this list: send the line unsubscribe 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 8/8] ASoC: tpa6130a2: Control vdd using regulator framework
On Thu, Oct 08, 2009 at 02:58:57PM +0300, Eduardo Valentin wrote:
+ data-regulator = regulator_get(dev, vdd);
+ if (IS_ERR(data-regulator)) {
+ dev_info(dev, Could not get regulator for vdd.
+ Executing without regulator.\n);
+ data-regulator = NULL;
+ }
Similar comments to the previous patch apply to this driver - regulator
usage should be unconditional, error messages should not be split over
multiple lines and you should represent all the supplies separately (it
looks like there's both VDD and CPVSS required here, for example) to
avoid future surprises.
--
To unsubscribe from this list: send the line unsubscribe 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: Fix VDD2 OPP1 issue
Reddy, Teerth tee...@ti.com writes:
From 144669d941a432875db37ae9431847f6753e566e Mon Sep 17 00:00:00 2001
From: Teerth Reddy tee...@ti.com
Date: Wed, 9 Sep 2009 11:01:04 +0530
Subject: [PATCH] ARM: OMAP3: PM: Fix VDD2 OPP1 issue
This patch fixes the VDD2 OPP1 issue. The patch has change
which does not allow VDD2 OPP setting to 1.VDD2 should not be put
at OPP1 as this is not a supported OPP for VDD2
Patch looks fine, but shortlog (subject) and changelog should be more
clear. These should be written for people who are not as familiar
with the code. For example, seeing this shortlog in a git history
would not be helpful as the irst thing one would ask is what OPP1
issue?
How about something like this:
Subject: OMAP3: PM: do not allow OPP1 allow for VDD2
Since OPP1 is not a supported OPP for VDD2, do not allow it to be
changed using the sysfs interface.
Kevin
Signed-off-by: Teerth Reddy tee...@ti.com
---
arch/arm/mach-omap2/pm.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index fec7d00..d0e03c4 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -195,7 +195,7 @@ static ssize_t vdd_opp_store(struct kobject *kobj, struct
kobj_attribute *attr,
}
resource_set_opp_level(VDD1_OPP, value, flags);
} else if (attr == vdd2_opp_attr) {
- if (value 1 || value 3) {
+ if (value 2 || value 3) {
printk(KERN_ERR vdd_opp_store: Invalid value\n);
return -EINVAL;
}
--
1.5.4.7
--
To unsubscribe from this list: send the line unsubscribe 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: X-loader / U-Boot query
The problem I have now is that it's only seeing 1/2 (256MB) of the available DRAM. Please refer sdrc_init() in u-boot/board/omap3530beagle/mem.c . SDRC_MCFG register has definition for SIZE and CS settings. Refer [1] for details about SDRC configurations. [1]http://focus.ti.com/pdfs/wtbu/SWPU114Q_PrelimFinal_EPDF_03_05_2009.pdf Regards, Shankar * Does anyone know how to get it to see all 512MB? * Is there a better place to ask/discuss these questions? A cursory look around did not point to anything fresh (most of the web pages Wikis I looked are are _years_ old) Thanks for any help/pointers -- To unsubscribe from this list: send the line unsubscribe 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/8] ASoC: TPA6130A2 amplifier driver
On Thu, Oct 08, 2009 at 04:38:24PM +0300, Peter Ujfalusi wrote:
On Thursday 08 October 2009 15:52:13 ext Mark Brown wrote:
On Thu, Oct 08, 2009 at 02:58:50PM +0300, Eduardo Valentin wrote:
+struct tpa6130a2_platform_data {
+ int (*set_power)(int state);
+};
Why is this a callback and not just a GPIO number? That'd seem simpler
for users.
Well, same amount of code, but in different place if the power is enabled
Until someone adds a second board, at which point they need to copy the
code to acquire and release the GPIO.
through a GPIO. But if the power is controlled via different means (nothing
comes to mind, but there are exotic systems out there), in this way it is
simple
to handle
I suspect we can deal with that adequately when it crops up, for example
by having the driver set up a default callback function if a GPIO is
specified instead of a callback.
+ pdata = (struct tpa6130a2_platform_data *)client-dev.platform_data;
+ /* Set default register values */
+ data-regs[TPA6130A2_REG_CONTROL] = TPA6130A2_SWS |
+ TPA6130A2_HP_EN_R |
+ TPA6130A2_HP_EN_L;
This looks like you could implement stereo paths with individual power
control?
Can we put something in between DAPM_OUTPUT and DAPM_HP to handle the stereo
path correctly?
Yes.
We could have two paths from codec to the TPA6130A2 Headphone, which is
needed
to actually control the power of the amplifier.
Or make TPA6130A2 Headphone be a SND_SOC_DAPM_SUPPLY() connected to
the individual channels for the headphone outputs, which should do the
right thing.
At the end we are not really gaining much, but one more level of switch on
the
path.
We could have simple mute alsa controls in tpa6130a2_controls for the
amplifier
itself...
It'd mean that mono outputs would only need to enable one of the
channels. Depending on the hardware feeding the amp this may behave
better - there may be some noise or leakage on the idle channel which
it'd be better to avoid amplifying - and it should certainly use a
little less power.
+ err = tpa6130a2_i2c_read(TPA6130A2_REG_VERSION)
+ TPA6130A2_VERSION_MASK;
+ if ((err != 1) (err != 2)) {
+ dev_err(dev, Unexpected headphone amplifier chip version
+of 0x%02x, was expecting 0x01 or 0x02\n, err);
+ err = -ENODEV;
This seems a bit excessive - is it really likely that the register map
would be changed incompatibly in a future version?
Hmm, we have only seen these versions of the chip, and we know that the
driver
works with these. Also we don't have any information on different versions,
but
I would think that the register map is not changing (the reset values for
some
registers are different)
It's fairly common to see some incompatible changes in early silicon
revisions but once things get properly launched it's fairly unusual.
I'd be more inclined to print a warning here rather than fail - chances
are that the driver will work fine with any new revisions that are
produced.
--
To unsubscribe from this list: send the line unsubscribe 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 8/8] ASoC: tpa6130a2: Control vdd using regulator framework
On Thu, Oct 08, 2009 at 03:43:33PM +0200, Mark Brown wrote:
On Thu, Oct 08, 2009 at 02:58:57PM +0300, Eduardo Valentin wrote:
+ data-regulator = regulator_get(dev, vdd);
+ if (IS_ERR(data-regulator)) {
+ dev_info(dev, Could not get regulator for vdd.
+ Executing without regulator.\n);
+ data-regulator = NULL;
+ }
Similar comments to the previous patch apply to this driver - regulator
usage should be unconditional, error messages should not be split over
multiple lines and you should represent all the supplies separately (it
looks like there's both VDD and CPVSS required here, for example) to
avoid future surprises.
Yeah. The idea here was to keep driver running even if regulators
are not properly set in board files. Maybe those in which the regulator
is always on. That's why I wrote it with nicely message.
--
Eduardo Valentin
--
To unsubscribe from this list: send the line unsubscribe 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: Fix VDD2 OPP1 issue
Reddy, Teerth had written, on 10/08/2009 04:21 AM, the following:
From 144669d941a432875db37ae9431847f6753e566e Mon Sep 17 00:00:00 2001
From: Teerth Reddy tee...@ti.com
Date: Wed, 9 Sep 2009 11:01:04 +0530
Subject: [PATCH] ARM: OMAP3: PM: Fix VDD2 OPP1 issue
This patch fixes the VDD2 OPP1 issue. The patch has change
which does not allow VDD2 OPP setting to 1.VDD2 should not be put
at OPP1 as this is not a supported OPP for VDD2
Signed-off-by: Teerth Reddy tee...@ti.com
---
arch/arm/mach-omap2/pm.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index fec7d00..d0e03c4 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -195,7 +195,7 @@ static ssize_t vdd_opp_store(struct kobject *kobj, struct
kobj_attribute *attr,
}
resource_set_opp_level(VDD1_OPP, value, flags);
} else if (attr == vdd2_opp_attr) {
- if (value 1 || value 3) {
+ if (value 2 || value 3) {
printk(KERN_ERR vdd_opp_store: Invalid value\n);
return -EINVAL;
}
this is not scalable. we should be able to disable OPPs for each OPP
from the OPP array. with different silicons, we could have the same OPP
enabled/disabled. NAK - need to handle based on mpu_opps[vale].rate ==0
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe 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][PATCH] OMAP3: introduce OMAP3630
-Original Message- From: Pandita, Vikram Sent: Thursday, October 08, 2009 7:01 PM To: Shilimkar, Santosh; Menon, Nishanth; linux-omap Cc: Chikkature Rajashekar, Madhusudhan; Pais, Allen; Gadiyar, Anand; Cousson, Benoit; Kevin Hilman; Premi, Sanjeev; Aguirre Rodriguez, Sergio Alberto; Tony Lindgren Subject: RE: [RFC][PATCH] OMAP3: introduce OMAP3630 -Original Message- From: Shilimkar, Santosh diff --git a/arch/arm/plat-omap/include/mach/cpu.h b/arch/arm/plat- omap/include/mach/cpu.h index 431fec4..af1080f 100644 --- a/arch/arm/plat-omap/include/mach/cpu.h +++ b/arch/arm/plat-omap/include/mach/cpu.h @@ -383,6 +383,12 @@ IS_OMAP_TYPE(3430, 0x3430) #define OMAP3430_REV_ES2_10x34302034 #define OMAP3430_REV_ES3_00x34303034 #define OMAP3430_REV_ES3_10x34304034 +/* NOTE: Add 36xx series below + * If additional 34xx series are added, OMAP3430_REV_ES can be + * added above the 3630 defines and series renumbered to ensure + * rev() checks to work + */ +#define OMAP3630_REV_ES1_00x34305034 #define OMAP443X_CLASS0x44300034 Was expecting that this patch will add cpu_is_omap36xx() in cpu.h apart from above. Is this handled in another patch ? Idea is to re-use all 34xx code for 36xx, as per the mail thread on list, and given in reference. Hence at run time, the check could be: if (omap_rev() == OMAP3630_REV_ES1_0) x cpu_is_omap34xx() will be true for 36xx as well. [sp] This case seems quite similar to the OMAP35x. Can you look at this thread: http://marc.info/?l=linux-omapm=125372581804902w=2 It applies equally well here as well... I will be submitting updated patch tomorrow. Best regards, Sanjeev 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: [RFC][PATCH] OMAP3: introduce OMAP3630
Nishanth, -Original Message- From: Menon, Nishanth Sent: Wednesday, October 07, 2009 11:47 PM To: linux-omap Cc: Menon, Nishanth; Chikkature Rajashekar, Madhusudhan; Pandita, Vikram; Pais, Allen; Gadiyar, Anand; Cousson, Benoit; Kevin Hilman; Premi, Sanjeev; Shilimkar, Santosh; Aguirre Rodriguez, Sergio Alberto; Tony Lindgren Subject: [RFC][PATCH] OMAP3: introduce OMAP3630 Device intro: OMAP3630 is the latest in the family of OMAP3 devices and among the changes it introduces are: New OPP levels for new voltage and frequency levels. a bunch of Bug fixes to various modules feature additions, notably with ISP, sDMA etc. Details about the chip is available here: http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?t emplateId=6123navigationId=12836contentId=52606 Strategy used: Strategy to introduce this device into Linux was discussed here: Ref: http://marc.info/?t=12534330343r=1w=2 Two approaches were available: a) Consider 3630 generation of devices as a new family of silicon b) Consider 3630 as an offshoot of 3430 family of devices As a common consensus, (b) seems to be more valid for 3630 as: * There are changes which are easily handled by looking at rev * Most of existing 34xx infrastructure can be reused(almost 90%+) - so no ugly if (cpu_is_omap34xx() || cpu_is_omap36xx()) all over the place And how about cpu_is_omap3() ? That would be valid across 34xx (zoom2, n900), 35xx (beagle, pandora), and 36xx (zoom3). IMO, returning positive in a 3630/3530 to cpu_is_omap34xx() could make the code quite unreadable. 1. If you need to do something 34xx specific, then use cpu_is_34xx() 2. If your code is valid for all 34xx, 35xx, 36xx, then why not using cpu_is_omap3() ? What do you think? - lesser chance of bugs due to reuse of proven code flow - 36xx specific handling can still be done where required within the existing infrastructure NOTE: * If additional 34xx series are added, OMAP3430_REV_ES can be added on top of the existing 3630 ones are renumbered This patch was tested on SDP3430. Maybe this should say: This patch didn't broke SDP3430. XD Regards, Sergio -- To unsubscribe from this list: send the line unsubscribe 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][PATCH] OMAP3: introduce OMAP3630
Premi, Sanjeev had written, on 10/08/2009 09:23 AM, the following: -Original Message- From: Pandita, Vikram Sent: Thursday, October 08, 2009 7:01 PM To: Shilimkar, Santosh; Menon, Nishanth; linux-omap Cc: Chikkature Rajashekar, Madhusudhan; Pais, Allen; Gadiyar, Anand; Cousson, Benoit; Kevin Hilman; Premi, Sanjeev; Aguirre Rodriguez, Sergio Alberto; Tony Lindgren Subject: RE: [RFC][PATCH] OMAP3: introduce OMAP3630 -Original Message- From: Shilimkar, Santosh diff --git a/arch/arm/plat-omap/include/mach/cpu.h b/arch/arm/plat- omap/include/mach/cpu.h index 431fec4..af1080f 100644 --- a/arch/arm/plat-omap/include/mach/cpu.h +++ b/arch/arm/plat-omap/include/mach/cpu.h @@ -383,6 +383,12 @@ IS_OMAP_TYPE(3430, 0x3430) #define OMAP3430_REV_ES2_1 0x34302034 #define OMAP3430_REV_ES3_0 0x34303034 #define OMAP3430_REV_ES3_1 0x34304034 +/* NOTE: Add 36xx series below + * If additional 34xx series are added, OMAP3430_REV_ES can be + * added above the 3630 defines and series renumbered to ensure + * rev() checks to work + */ +#define OMAP3630_REV_ES1_0 0x34305034 #define OMAP443X_CLASS 0x44300034 Was expecting that this patch will add cpu_is_omap36xx() in cpu.h apart from above. Is this handled in another patch ? Idea is to re-use all 34xx code for 36xx, as per the mail thread on list, and given in reference. Hence at run time, the check could be: if (omap_rev() == OMAP3630_REV_ES1_0) x cpu_is_omap34xx() will be true for 36xx as well. [sp] This case seems quite similar to the OMAP35x. Can you look at this thread: http://marc.info/?l=linux-omapm=125372581804902w=2 It applies equally well here as well... I will be submitting updated patch tomorrow. yes, any specifics should be feature based IMHO. we will need to extend the feature list. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe 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 8/8] ASoC: tpa6130a2: Control vdd using regulator framework
On Thu, Oct 08, 2009 at 04:56:28PM +0300, Eduardo Valentin wrote: On Thu, Oct 08, 2009 at 03:43:33PM +0200, Mark Brown wrote: Similar comments to the previous patch apply to this driver - regulator usage should be unconditional, error messages should not be split over multiple lines and you should represent all the supplies separately (it looks like there's both VDD and CPVSS required here, for example) to avoid future surprises. Yeah. The idea here was to keep driver running even if regulators are not properly set in board files. Maybe those in which the regulator is always on. That's why I wrote it with nicely message. The issue is that this doesn't actually end up increasing the system robustness since in some systems the regulator control will be required and the failures can be non-obvious, such as having a shared regulator powered off at run time due to other system activity. A misconfigured regulator supply that stops probe is relatively easy to diagnose and fix compared to potential silent interactions with other subsystems. It's simple enough to set up a fixed voltage regulator in the board for any supplies that don't have soft regulators. -- To unsubscribe from this list: send the line unsubscribe 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: Fix VDD2 OPP1 issue
Nishanth Menon n...@ti.com writes:
Reddy, Teerth had written, on 10/08/2009 04:21 AM, the following:
From 144669d941a432875db37ae9431847f6753e566e Mon Sep 17 00:00:00 2001
From: Teerth Reddy tee...@ti.com
Date: Wed, 9 Sep 2009 11:01:04 +0530
Subject: [PATCH] ARM: OMAP3: PM: Fix VDD2 OPP1 issue
This patch fixes the VDD2 OPP1 issue. The patch has change
which does not allow VDD2 OPP setting to 1.VDD2 should not be put at
OPP1 as this is not a supported OPP for VDD2
Signed-off-by: Teerth Reddy tee...@ti.com
---
arch/arm/mach-omap2/pm.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index fec7d00..d0e03c4 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -195,7 +195,7 @@ static ssize_t vdd_opp_store(struct kobject *kobj,
struct kobj_attribute *attr,
}
resource_set_opp_level(VDD1_OPP, value, flags);
} else if (attr == vdd2_opp_attr) {
-if (value 1 || value 3) {
+if (value 2 || value 3) {
printk(KERN_ERR vdd_opp_store: Invalid value\n);
return -EINVAL;
}
this is not scalable. we should be able to disable OPPs for each OPP
from the OPP array. with different silicons, we could have the same
OPP enabled/disabled. NAK - need to handle based on
mpu_opps[vale].rate ==0
Agreed that the current code is not scalable, but that was a problem
before Teerth's fix.
The proposed patch is a bugfix to existing code and should be merged
after my comments are addressed.
Then, the scalability issues can be addressed separately.
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC][PATCH] OMAP3: introduce OMAP3630
Nishanth, Would there be CONFIG_ARCH_OMAP3630? - Allen From: Menon, Nishanth Sent: Thursday, October 08, 2009 9:40 AM To: Premi, Sanjeev Cc: Pandita, Vikram; Shilimkar, Santosh; linux-omap; Chikkature Rajashekar, Madhusudhan; Pais, Allen; Gadiyar, Anand; Cousson, Benoit; Kevin Hilman; Aguirre Rodriguez, Sergio Alberto; Tony Lindgren Subject: Re: [RFC][PATCH] OMAP3: introduce OMAP3630 Premi, Sanjeev had written, on 10/08/2009 09:23 AM, the following: -Original Message- From: Pandita, Vikram Sent: Thursday, October 08, 2009 7:01 PM To: Shilimkar, Santosh; Menon, Nishanth; linux-omap Cc: Chikkature Rajashekar, Madhusudhan; Pais, Allen; Gadiyar, Anand; Cousson, Benoit; Kevin Hilman; Premi, Sanjeev; Aguirre Rodriguez, Sergio Alberto; Tony Lindgren Subject: RE: [RFC][PATCH] OMAP3: introduce OMAP3630 -Original Message- From: Shilimkar, Santosh diff --git a/arch/arm/plat-omap/include/mach/cpu.h b/arch/arm/plat- omap/include/mach/cpu.h index 431fec4..af1080f 100644 --- a/arch/arm/plat-omap/include/mach/cpu.h +++ b/arch/arm/plat-omap/include/mach/cpu.h @@ -383,6 +383,12 @@ IS_OMAP_TYPE(3430, 0x3430) #define OMAP3430_REV_ES2_10x34302034 #define OMAP3430_REV_ES3_00x34303034 #define OMAP3430_REV_ES3_10x34304034 +/* NOTE: Add 36xx series below + * If additional 34xx series are added, OMAP3430_REV_ES can be + * added above the 3630 defines and series renumbered to ensure + * rev() checks to work + */ +#define OMAP3630_REV_ES1_00x34305034 #define OMAP443X_CLASS0x44300034 Was expecting that this patch will add cpu_is_omap36xx() in cpu.h apart from above. Is this handled in another patch ? Idea is to re-use all 34xx code for 36xx, as per the mail thread on list, and given in reference. Hence at run time, the check could be: if (omap_rev() == OMAP3630_REV_ES1_0) x cpu_is_omap34xx() will be true for 36xx as well. [sp] This case seems quite similar to the OMAP35x. Can you look at this thread: http://marc.info/?l=linux-omapm=125372581804902w=2 It applies equally well here as well... I will be submitting updated patch tomorrow. yes, any specifics should be feature based IMHO. we will need to extend the feature list. -- Regards, Nishanth Menon-- To unsubscribe from this list: send the line unsubscribe 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: X-loader / U-Boot query
The problem is located in u-boot/cpu/arm_cortexa8/omap3/mem.c Function do_sdrc_init() There is an assumption that the RAM size on each CS is maximum of 128M. See this line: writel(RASWIDTH_13BITS | CASWIDTH_10BITS | ADDRMUXLEGACY | RAMSIZE_128 | BANKALLOCATION | B32NOT16 | B32NOT16 | DEEPPD | DDR_SDRAM, sdrc_base-cs[cs].mcfg); Adam Gary Thomas wrote: I have a new board - OMAP 3530 with 512MB DRAM NAND I've build X-loader and U-Boot for it and it mostly comes up. The sources I used (based on recommendations from the BeagleBoard pages) were: http://git.gitorious.org/x-load-omap3/mainline.git git://git.denx.de/u-boot.git I had to make a small change to get it to recognize the larger NAND FLASH device. The problem I have now is that it's only seeing 1/2 (256MB) of the available DRAM. * Does anyone know how to get it to see all 512MB? * Is there a better place to ask/discuss these questions? A cursory look around did not point to anything fresh (most of the web pages Wikis I looked are are _years_ old) Thanks for any help/pointers -- To unsubscribe from this list: send the line unsubscribe 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: Fix VDD2 OPP1 issue
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Thursday, October 08, 2009 9:58 AM
To: Menon, Nishanth
Cc: Reddy, Teerth; linux-omap@vger.kernel.org
Subject: Re: [PATCH] OMAP3: PM: Fix VDD2 OPP1 issue
Nishanth Menon n...@ti.com writes:
Reddy, Teerth had written, on 10/08/2009 04:21 AM, the following:
From 144669d941a432875db37ae9431847f6753e566e Mon Sep 17 00:00:00 2001
From: Teerth Reddy tee...@ti.com
Date: Wed, 9 Sep 2009 11:01:04 +0530
Subject: [PATCH] ARM: OMAP3: PM: Fix VDD2 OPP1 issue
This patch fixes the VDD2 OPP1 issue. The patch has change
which does not allow VDD2 OPP setting to 1.VDD2 should not be put at
OPP1 as this is not a supported OPP for VDD2
Signed-off-by: Teerth Reddy tee...@ti.com
---
arch/arm/mach-omap2/pm.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index fec7d00..d0e03c4 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -195,7 +195,7 @@ static ssize_t vdd_opp_store(struct kobject *kobj,
struct kobj_attribute *attr,
}
resource_set_opp_level(VDD1_OPP, value, flags);
} else if (attr == vdd2_opp_attr) {
- if (value 1 || value 3) {
+ if (value 2 || value 3) {
printk(KERN_ERR vdd_opp_store: Invalid value\n);
return -EINVAL;
}
this is not scalable. we should be able to disable OPPs for each OPP
from the OPP array. with different silicons, we could have the same
OPP enabled/disabled. NAK - need to handle based on
mpu_opps[vale].rate ==0
Agreed that the current code is not scalable, but that was a problem
before Teerth's fix.
The proposed patch is a bugfix to existing code and should be merged
after my comments are addressed.
Then, the scalability issues can be addressed separately.
Ok, reverting my objection.
Will try to do a follow up patch - essentially let program_opp make that
decision IMHO.
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe 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: X-loader / U-Boot query
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Adam Machalek Sent: Thursday, October 08, 2009 9:47 AM To: Gary Thomas Cc: linux-omap@vger.kernel.org Subject: Re: X-loader / U-Boot query The problem is located in u-boot/cpu/arm_cortexa8/omap3/mem.c Function do_sdrc_init() There is an assumption that the RAM size on each CS is maximum of 128M. See this line: writel(RASWIDTH_13BITS | CASWIDTH_10BITS | ADDRMUXLEGACY | RAMSIZE_128 | BANKALLOCATION | B32NOT16 | B32NOT16 | DEEPPD | DDR_SDRAM, sdrc_base-cs[cs].mcfg); This discussion should really be taken to u-boot mailing list. Yes, any additional patches would be good to have.. Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe 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][PATCH] OMAP3: introduce OMAP3630
-Original Message- From: Pais, Allen Sent: Thursday, October 08, 2009 10:04 AM To: Menon, Nishanth; Premi, Sanjeev Nishanth, Would there be CONFIG_ARCH_OMAP3630? There is no need for it. From: Menon, Nishanth Sent: Thursday, October 08, 2009 9:40 AM To: Premi, Sanjeev Cc: Pandita, Vikram; Shilimkar, Santosh; linux-omap; Chikkature Rajashekar, Madhusudhan; Pais, Allen; Gadiyar, Anand; Cousson, Benoit; Kevin Hilman; Aguirre Rodriguez, Sergio Alberto; Tony Lindgren Subject: Re: [RFC][PATCH] OMAP3: introduce OMAP3630 Stop top posting please. Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe 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: X-loader / U-Boot query
On 10/08/2009 09:14 AM, Menon, Nishanth wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Adam Machalek Sent: Thursday, October 08, 2009 9:47 AM To: Gary Thomas Cc: linux-omap@vger.kernel.org Subject: Re: X-loader / U-Boot query The problem is located in u-boot/cpu/arm_cortexa8/omap3/mem.c Function do_sdrc_init() There is an assumption that the RAM size on each CS is maximum of 128M. See this line: writel(RASWIDTH_13BITS | CASWIDTH_10BITS | ADDRMUXLEGACY | RAMSIZE_128 | BANKALLOCATION | B32NOT16 | B32NOT16 | DEEPPD | DDR_SDRAM,sdrc_base-cs[cs].mcfg); This discussion should really be taken to u-boot mailing list. Yes, any additional patches would be good to have.. Where is that list?? I did ask this question in the original email... -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe 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: X-loader / U-Boot query
-Original Message- From: Gary Thomas [mailto:g...@mlbassoc.com] Sent: Thursday, October 08, 2009 10:17 AM To: Menon, Nishanth Cc: Adam Machalek; linux-omap@vger.kernel.org Subject: Re: X-loader / U-Boot query On 10/08/2009 09:14 AM, Menon, Nishanth wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Adam Machalek Sent: Thursday, October 08, 2009 9:47 AM To: Gary Thomas Cc: linux-omap@vger.kernel.org Subject: Re: X-loader / U-Boot query The problem is located in u-boot/cpu/arm_cortexa8/omap3/mem.c Function do_sdrc_init() There is an assumption that the RAM size on each CS is maximum of 128M. See this line: writel(RASWIDTH_13BITS | CASWIDTH_10BITS | ADDRMUXLEGACY | RAMSIZE_128 | BANKALLOCATION | B32NOT16 | B32NOT16 | DEEPPD | DDR_SDRAM,sdrc_base-cs[cs].mcfg); This discussion should really be taken to u-boot mailing list. Yes, any additional patches would be good to have.. Where is that list?? I did ask this question in the original email... Please see [1] and the specific list [2] and also see [3] Regards, Nishanth Menon Ref: [1] http://www.google.com/search?sourceid=navclientie=UTF-8rlz=1T4GGLL_enUS306US306q=u-boot+mailing+list [2] http://lists.denx.de/mailman/listinfo/u-boot [3] http://www.denx.de/wiki/U-Boot -- To unsubscribe from this list: send the line unsubscribe 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 7/8] ASoC: tlv320aic3x: add initial usage of regulator framework to control avdd_dac
Mark Brown wrote: Will this ever be revisited =) ? If so, I think there's going to be a jungle in finding the right spots - you need to remember the bypass paths also (bias is not on necessarily). The bias is always on when any path through the chip is on, this was fixed in either .31 or .30. Good! Thanks for the update. Also, this is regulator thing is highly platform dependent, not aic3x related really at all, so is this the correct place... Just a thought, dont take it too seriously ;) I'm not sure what you mean by this? You may power the aic3x from a fixed source, or from multiple sources, with and without any regulator in between. It's up to the HW and HW design. Moreover, you don't _power off_ (turn the regulator off) the analog voltages of aic3x; things won't work. So it's not like a switch everybody may use. Or nothing prevent you from experiencing that... - EEro -- To unsubscribe from this list: send the line unsubscribe 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: X-loader / U-Boot query
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Gary Thomas Sent: Thursday, October 08, 2009 10:17 AM To: Menon, Nishanth Cc: Adam Machalek; linux-omap@vger.kernel.org Subject: Re: X-loader / U-Boot query On 10/08/2009 09:14 AM, Menon, Nishanth wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Adam Machalek Sent: Thursday, October 08, 2009 9:47 AM To: Gary Thomas Cc: linux-omap@vger.kernel.org Subject: Re: X-loader / U-Boot query The problem is located in u-boot/cpu/arm_cortexa8/omap3/mem.c Function do_sdrc_init() There is an assumption that the RAM size on each CS is maximum of 128M. See this line: writel(RASWIDTH_13BITS | CASWIDTH_10BITS | ADDRMUXLEGACY | RAMSIZE_128 | BANKALLOCATION | B32NOT16 | B32NOT16 | DEEPPD | DDR_SDRAM,sdrc_base-cs[cs].mcfg); This discussion should really be taken to u-boot mailing list. Yes, any additional patches would be good to have.. Where is that list?? I did ask this question in the original email... Sorry, I have not seen all the thread. Are you using x-loader? Then your DDR configuration happens in x-loader and not in u-boot as it skips it. In that case your question should be on x-loader and this is the right list to discuss the same. If you use u-boot for RAM configuration then you should be on NOR flash. Regards, Khasim -- To unsubscribe from this list: send the line unsubscribe 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 7/8] ASoC: tlv320aic3x: add initial usage of regulator framework to control avdd_dac
On 8 Oct 2009, at 16:44, ext-eero.nurkk...@nokia.com wrote: Mark Brown wrote: Also, this is regulator thing is highly platform dependent, not aic3x related really at all, so is this the correct place... Just a thought, dont take it too seriously ;) I'm not sure what you mean by this? You may power the aic3x from a fixed source, or from multiple sources, with and without any regulator in between. It's up to the HW and HW design. The regulator API can cope with all this pretty transparently - if multiple supplies come from the same regulator the API will hide that from the consumer. There is a fixed voltage regulator driver which can be used to represent supplies with no soft control. Moreover, you don't _power off_ (turn the regulator off) the analog voltages of aic3x; things won't work. So it's not like a switch everybody may use. Or nothing prevent you from experiencing that... I'd expect the usage would be that after the audio subsystem has been idle for some configurable period of time the core would bring the audio subsystem down to bias off, at which point supplies could also be switched off. -- To unsubscribe from this list: send the line unsubscribe 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][PATCH] OMAP3: introduce OMAP3630
-Original Message- From: Aguirre Rodriguez, Sergio Alberto Sent: Thursday, October 08, 2009 9:31 AM To: Menon, Nishanth; linux-omap Cc: Chikkature Rajashekar, Madhusudhan; Pandita, Vikram; Pais, Allen; Gadiyar, Anand; Cousson, Benoit; Kevin Hilman; Premi, Sanjeev; Shilimkar, Santosh; Tony Lindgren Subject: RE: [RFC][PATCH] OMAP3: introduce OMAP3630 Nishanth, -Original Message- From: Menon, Nishanth Sent: Wednesday, October 07, 2009 11:47 PM To: linux-omap Cc: Menon, Nishanth; Chikkature Rajashekar, Madhusudhan; Pandita, Vikram; Pais, Allen; Gadiyar, Anand; Cousson, Benoit; Kevin Hilman; Premi, Sanjeev; Shilimkar, Santosh; Aguirre Rodriguez, Sergio Alberto; Tony Lindgren Subject: [RFC][PATCH] OMAP3: introduce OMAP3630 Device intro: OMAP3630 is the latest in the family of OMAP3 devices and among the changes it introduces are: New OPP levels for new voltage and frequency levels. a bunch of Bug fixes to various modules feature additions, notably with ISP, sDMA etc. Details about the chip is available here: http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?t emplateId=6123navigationId=12836contentId=52606 Strategy used: Strategy to introduce this device into Linux was discussed here: Ref: http://marc.info/?t=12534330343r=1w=2 Two approaches were available: a) Consider 3630 generation of devices as a new family of silicon b) Consider 3630 as an offshoot of 3430 family of devices As a common consensus, (b) seems to be more valid for 3630 as: * There are changes which are easily handled by looking at rev * Most of existing 34xx infrastructure can be reused(almost 90%+) - so no ugly if (cpu_is_omap34xx() || cpu_is_omap36xx()) all over the place And how about cpu_is_omap3() ? That would be valid across 34xx (zoom2, n900), 35xx (beagle, pandora), and 36xx (zoom3). IMO, returning positive in a 3630/3530 to cpu_is_omap34xx() could make the code quite unreadable. 1. If you need to do something 34xx specific, then use cpu_is_34xx() 2. If your code is valid for all 34xx, 35xx, 36xx, then why not using cpu_is_omap3() ? What do you think? Not at this stage, lets bring in rename over time once 35xx changes from Sanjeev are also in.. - lesser chance of bugs due to reuse of proven code flow - 36xx specific handling can still be done where required within the existing infrastructure NOTE: * If additional 34xx series are added, OMAP3430_REV_ES can be added on top of the existing 3630 ones are renumbered This patch was tested on SDP3430. Maybe this should say: This patch didn't broke SDP3430. No. it means what it says - I tested this patch and booted the l-o kernel on SDP3430== OMAP3430 is fine. Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe 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: X-loader / U-Boot query
On 10/08/2009 09:54 AM, Syed Mohammed, Khasim wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Gary Thomas Sent: Thursday, October 08, 2009 10:17 AM To: Menon, Nishanth Cc: Adam Machalek; linux-omap@vger.kernel.org Subject: Re: X-loader / U-Boot query On 10/08/2009 09:14 AM, Menon, Nishanth wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Adam Machalek Sent: Thursday, October 08, 2009 9:47 AM To: Gary Thomas Cc: linux-omap@vger.kernel.org Subject: Re: X-loader / U-Boot query The problem is located in u-boot/cpu/arm_cortexa8/omap3/mem.c Function do_sdrc_init() There is an assumption that the RAM size on each CS is maximum of 128M. See this line: writel(RASWIDTH_13BITS | CASWIDTH_10BITS | ADDRMUXLEGACY | RAMSIZE_128 | BANKALLOCATION | B32NOT16 | B32NOT16 | DEEPPD | DDR_SDRAM,sdrc_base-cs[cs].mcfg); This discussion should really be taken to u-boot mailing list. Yes, any additional patches would be good to have.. Where is that list?? I did ask this question in the original email... Sorry, I have not seen all the thread. Are you using x-loader? Then your DDR configuration happens in x-loader and not in u-boot as it skips it. In that case your question should be on x-loader and this is the right list to discuss the same. If you use u-boot for RAM configuration then you should be on NOR flash. I'm definitely using x-loader (followed by U-Boot). Where is this set in X-loader? Is there any guidance for using the larger DRAM devices? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe 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: X-loader / U-Boot query
-Original Message- From: Gary Thomas [mailto:g...@mlbassoc.com] Sent: Thursday, October 08, 2009 11:10 AM To: Syed Mohammed, Khasim Cc: linux-omap@vger.kernel.org Subject: Re: X-loader / U-Boot query On 10/08/2009 09:54 AM, Syed Mohammed, Khasim wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Gary Thomas Sent: Thursday, October 08, 2009 10:17 AM To: Menon, Nishanth Cc: Adam Machalek; linux-omap@vger.kernel.org Subject: Re: X-loader / U-Boot query On 10/08/2009 09:14 AM, Menon, Nishanth wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Adam Machalek Sent: Thursday, October 08, 2009 9:47 AM To: Gary Thomas Cc: linux-omap@vger.kernel.org Subject: Re: X-loader / U-Boot query The problem is located in u-boot/cpu/arm_cortexa8/omap3/mem.c Function do_sdrc_init() There is an assumption that the RAM size on each CS is maximum of 128M. See this line: writel(RASWIDTH_13BITS | CASWIDTH_10BITS | ADDRMUXLEGACY | RAMSIZE_128 | BANKALLOCATION | B32NOT16 | B32NOT16 | DEEPPD | DDR_SDRAM,sdrc_base-cs[cs].mcfg); This discussion should really be taken to u-boot mailing list. Yes, any additional patches would be good to have.. Where is that list?? I did ask this question in the original email... Sorry, I have not seen all the thread. Are you using x-loader? Then your DDR configuration happens in x-loader and not in u-boot as it skips it. In that case your question should be on x-loader and this is the right list to discuss the same. If you use u-boot for RAM configuration then you should be on NOR flash. I'm definitely using x-loader (followed by U-Boot). Where is this set in X-loader? Is there any guidance for using the larger DRAM devices? I have tried upto 256MB on beagleboard, http://gitorious.org/x-load-omap3/mainline/commit/c0bc8cc7005abad65be07b0c64901bcfaff71971 See the DDR configuration. I think others have tried for 512MB on other OMAP3 devices I don't know about the source location for the same. Regards, Khasim -- To unsubscribe from this list: send the line unsubscribe 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: X-loader / U-Boot query
Gary Thomas wrote: I have a new board - OMAP 3530 with 512MB DRAM NAND I've build X-loader and U-Boot for it and it mostly comes up. The sources I used (based on recommendations from the BeagleBoard pages) were: http://git.gitorious.org/x-load-omap3/mainline.git git://git.denx.de/u-boot.git I had to make a small change to get it to recognize the larger NAND FLASH device. The problem I have now is that it's only seeing 1/2 (256MB) of the available DRAM. * Does anyone know how to get it to see all 512MB? Not exactly on how to see all 512MB. But while we switched U-Boot Beagle to support 256MB instead of 128MB we did what is in http://git.mansr.com/?p=u-boot;a=shortlog;h=refs/heads/old Maybe the top ~10 commits from Mans there could help you. * Is there a better place to ask/discuss these questions? Yes. U-Boot list. It was already mentioned in this thread. Cheers Dirk -- To unsubscribe from this list: send the line unsubscribe 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: mux strategy (was RE: [PATCH] [OMAP1] mux: Add MMC mux pins for omap7xx)
* Philip Balister phi...@balister.org [091007 19:32]: On 10/07/2009 10:47 AM, Tony Lindgren wrote: * Kevin Hilmankhil...@deeprootsystems.com [091006 15:18]: Menon, Nishanthn...@ti.com writes: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Kevin Hilman W17_7XX_USB_VBUSI, + + /* MMC */ + MMC_7XX_CMD, + MMC_7XX_CLK, + MMC_7XX_DAT0, probably a dumb question - but should'nt these go off to bootloader perhaps? Perhaps, although we use either EOL (for HTC Wizard) or Haret to boot, and they don't set up the right mux configuration for our board. This way though, we don't have to worry about the boot loader -- we can set it up right regardless of who boots us. I agree with Cory. I prefer that mux settings go into the kernel, even if they are setup in the bootloader already. It's better to have redundancy than wonder what to do if changing boot loaders. Probably opening up a can of worms.. Are the rules different for OMAP3? Should'nt we have all mux done at kernel so that kernel is loader independent? Yes, we should. My preference is to always have muxing in the kernel. Agreed. We still should support bootloader only muxing too. BTW, I've been thinking about the following sets of patches for the next merge window: 1. Do the include directories for mach-omap1 and mach-omap2 as suggested by Russell earlier Does anyone have a reference to Russell's suggestion? Here's a link to the thread discussing the earlier header changes: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg15087.html Regards, Tony Philip 2. Move all mux code to only live under arch/arm/*omap*/ and make sure drivers don't call omap_cfg_reg() any longer 3. Remove the enumeration for the mux and require all the boards to register the pins they'll use After these it should be trivial to improve the mux code further. The steps 2 3 above will be most likely breaking things for some boards, so help will be needed with testing. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
FEATURES prints
Folks, With the addition of FEATURES in l-o, the following prints: - l2cache : Y - iva : Y - sgx : Y - neon : Y - isp : Y comes up on SDP3430 - now that we will introduce half a dozen features here and there, we will soon clutter this up. we should introduce a sysfs entry + remove the above noise.. any comments? -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2] OMAP3: introduce OMAP3630
-Original Message-
From: Menon, Nishanth
Sent: Thursday, October 08, 2009 12:32 PM
To: linux-omap
Cc: Menon, Nishanth; Chikkature Rajashekar, Madhusudhan;
Pandita, Vikram; Pais, Allen; Gadiyar, Anand; Cousson,
Benoit; Felipe Balbi; Kevin Hilman; Premi, Sanjeev;
Shilimkar, Santosh; Aguirre Rodriguez, Sergio Alberto; Tony Lindgren
Subject: [PATCH v2] OMAP3: introduce OMAP3630
Device intro:
OMAP3630 is the latest in the family of OMAP3 devices
and among the changes it introduces are:
New OPP levels for new voltage and frequency levels. a bunch of
Bug fixes to various modules feature additions, notably with ISP,
sDMA etc.
Details about the chip is available here:
http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?t
emplateId=6123navigationId=12836contentId=52606
Strategy used:
Strategy to introduce this device into Linux was discussed here:
Ref: http://marc.info/?t=12534330343r=1w=2
Two approaches were available:
a) Consider 3630 generation of devices as a new family of silicon
b) Consider 3630 as an offshoot of 3430 family of devices
As a common consensus, (b) seems to be more valid for 3630 as:
* There are changes which are easily handled by using FEATURES
infrastructure.
For details how to do this, see thread:
http://marc.info/?t=12505099851r=1w=2
* Most of existing 34xx infrastructure can be reused(almost 90%+)
- so no ugly if (cpu_is_omap34xx() || cpu_is_omap36xx())
all over the place
- lesser chance of bugs due to reuse of proven code flow
- 36xx specific handling can still be done where required
within the existing infrastructure
NOTE:
* If additional 34xx series are added, OMAP3430_REV_ES can be
added on top of the existing 3630 ones are renumbered
This patch was tested on SDP3430. zoom3/sdp3630 support needs
further follow on patches
Signed-off-by: Madhusudhan Chikkature Rajashekar madhu...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
Cc: Allen Pais allen.p...@ti.com
Cc: Anand Gadiyar gadi...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Felipe Balbi felipe.ba...@nokia.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Sanjeev Premi pr...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Sergio Alberto Aguirre Rodriguez saagui...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/id.c | 31
---
arch/arm/plat-omap/include/mach/cpu.h |6 ++
2 files changed, 34 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 03b80f2..3fc5e4e 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -186,6 +186,7 @@ void __init omap3_check_revision(void)
{
u32 cpuid, idcode;
u16 hawkeye;
+ u16 omap_type;
u8 rev;
char *rev_name = ES1.0;
@@ -210,7 +211,10 @@ void __init omap3_check_revision(void)
hawkeye = (idcode 12) 0x;
rev = (idcode 28) 0xff;
- if (hawkeye == 0xb7ae) {
+ omap_type = omap_rev() 16;
This is wrong.
omap_rev() returns omap_revision static var, which is not yet assigned at this
point.
So, this line needs to go _after_ below switch. [1]
+ switch (hawkeye) {
+ case 0xb7ae:
+ /* Handle 34xx devices */
switch (rev) {
case 0:
omap_revision = OMAP3430_REV_ES2_0;
@@ -231,12 +235,33 @@ void __init omap3_check_revision(void)
default:
/* Use the latest known revision as default */
omap_revision = OMAP3430_REV_ES3_1;
- rev_name = Unknown revision\n;
+ rev_name = Unknown 34xx revision\n;
}
+ break;
+ case 0xb891:
+ /* Handle 36xx devices
+ * But, override for display purposes
+ */
+ omap_type = 0x3630;
+ switch (rev) {
+ case 0:
+ omap_revision = OMAP3630_REV_ES1_0;
+ rev_name = ES1.0;
+ break;
+ default:
+ /* Use the latest known revision as default */
+ omap_revision = OMAP3630_REV_ES1_0;
+ rev_name = Unknown 36xx revision\n;
+ }
+ break;
+ default:
+ /* Unknown default to latest rev as default*/
+ omap_revision = OMAP3630_REV_ES1_0;
+ rev_name = Unknown revision\n;
}
[1] Here:
omap_type = omap_rev() 16;
Regards,
Sergio
out:
- pr_info(OMAP%04x %s\n, omap_rev() 16, rev_name);
+ pr_info(OMAP%04x %s\n, omap_type, rev_name);
}
#define OMAP3_SHOW_FEATURE(feat) \
diff --git a/arch/arm/plat-omap/include/mach/cpu.h
RE: [PATCH v2] OMAP3: introduce OMAP3630
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
Aguirre Rodriguez, Sergio Alberto
Sent: Thursday, October 08, 2009 2:59 PM
From: Menon, Nishanth
Sent: Thursday, October 08, 2009 12:32 PM
Device intro:
OMAP3630 is the latest in the family of OMAP3 devices
and among the changes it introduces are:
New OPP levels for new voltage and frequency levels. a bunch of
Bug fixes to various modules feature additions, notably with ISP,
sDMA etc.
Details about the chip is available here:
http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?t
emplateId=6123navigationId=12836contentId=52606
Strategy used:
Strategy to introduce this device into Linux was discussed here:
Ref: http://marc.info/?t=12534330343r=1w=2
Two approaches were available:
a) Consider 3630 generation of devices as a new family of silicon
b) Consider 3630 as an offshoot of 3430 family of devices
As a common consensus, (b) seems to be more valid for 3630 as:
* There are changes which are easily handled by using FEATURES
infrastructure.
For details how to do this, see thread:
http://marc.info/?t=12505099851r=1w=2
* Most of existing 34xx infrastructure can be reused(almost 90%+)
- so no ugly if (cpu_is_omap34xx() || cpu_is_omap36xx())
all over the place
- lesser chance of bugs due to reuse of proven code flow
- 36xx specific handling can still be done where required
within the existing infrastructure
NOTE:
* If additional 34xx series are added, OMAP3430_REV_ES can be
added on top of the existing 3630 ones are renumbered
This patch was tested on SDP3430. zoom3/sdp3630 support needs
further follow on patches
Signed-off-by: Madhusudhan Chikkature Rajashekar madhu...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
Cc: Allen Pais allen.p...@ti.com
Cc: Anand Gadiyar gadi...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Felipe Balbi felipe.ba...@nokia.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Sanjeev Premi pr...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Sergio Alberto Aguirre Rodriguez saagui...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/id.c | 31
---
arch/arm/plat-omap/include/mach/cpu.h |6 ++
2 files changed, 34 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 03b80f2..3fc5e4e 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -186,6 +186,7 @@ void __init omap3_check_revision(void)
{
u32 cpuid, idcode;
u16 hawkeye;
+ u16 omap_type;
u8 rev;
char *rev_name = ES1.0;
@@ -210,7 +211,10 @@ void __init omap3_check_revision(void)
hawkeye = (idcode 12) 0x;
rev = (idcode 28) 0xff;
- if (hawkeye == 0xb7ae) {
+ omap_type = omap_rev() 16;
This is wrong.
omap_rev() returns omap_revision static var, which is not yet
assigned at this point.
So, this line needs to go _after_ below switch. [1]
Actually, omap_type is not used anywhere else than the end printk,
so why creating a var for that?
How about this instead:
#define omap_type() (omap_rev() 16)
Regards,
Sergio
+ switch (hawkeye) {
+ case 0xb7ae:
+ /* Handle 34xx devices */
switch (rev) {
case 0:
omap_revision = OMAP3430_REV_ES2_0;
@@ -231,12 +235,33 @@ void __init omap3_check_revision(void)
default:
/* Use the latest known revision as default */
omap_revision = OMAP3430_REV_ES3_1;
- rev_name = Unknown revision\n;
+ rev_name = Unknown 34xx revision\n;
}
+ break;
+ case 0xb891:
+ /* Handle 36xx devices
+* But, override for display purposes
+*/
+ omap_type = 0x3630;
+ switch (rev) {
+ case 0:
+ omap_revision = OMAP3630_REV_ES1_0;
+ rev_name = ES1.0;
+ break;
+ default:
+ /* Use the latest known revision as default */
+ omap_revision = OMAP3630_REV_ES1_0;
+ rev_name = Unknown 36xx revision\n;
+ }
+ break;
+ default:
+ /* Unknown default to latest rev as default*/
+ omap_revision = OMAP3630_REV_ES1_0;
+ rev_name = Unknown revision\n;
}
[1] Here:
omap_type = omap_rev() 16;
Regards,
Sergio
out:
- pr_info(OMAP%04x %s\n, omap_rev() 16, rev_name);
+ pr_info(OMAP%04x %s\n, omap_type, rev_name);
}
#define OMAP3_SHOW_FEATURE(feat) \
diff --git
Re: [GIT PULL] omap fixes for v2.6.32-rc3
On Wed, Oct 7, 2009 at 9:51 PM, Tony Lindgren t...@atomide.com wrote: Linus, Please pull omap fixes from: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-fixes-for-linus Regards, Tony The following changes since commit 374576a8b6f865022c0fd1ca62396889b23d66dd: Linus Torvalds (1): Linux 2.6.32-rc3 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-fixes-for-linus Artem Bityutskiy (1): OMAP3: PM: introduce a new powerdomain walk helper Daniel Walker (1): omap: iovmm: Add missing mutex_unlock Hiroshi DOYU (1): omap: iovmm: Fix incorrect spelling Jon Hunter (1): OMAP3: PM: Prevent hang in prcm_interrupt_handler Kevin Hilman (1): OMAP3: PM: Enable GPIO module-level wakeups Paul Walmsley (2): OMAP3: PM: PRCM interrupt: check MPUGRPSEL register OMAP3: PM: PRCM interrupt: only handle selected PRCM interrupts Rajendra Nayak (1): omap: Lock DPLL5 at boot Sergio Aguirre (1): omapfb: Condition mutex acquisition Tommi Rantala (2): omapfb: Blizzard: fix pointer to be const omapfb: Blizzard: constify register address tables Tony Lindgren (2): omap: Fix incorrect 730 vs 850 detection Merge branch 'pm-fixes-32' of git://git.kernel.org/.../khilman/linux-omap-pm into omap-fixes-for-linus Vikram Pandita (1): OMAP3: PM: USBHOST: clear wakeup events on both hosts ye janboe (1): omap: SRAM: flush the right address after memcpy in omap_sram_push The beagleboard is still not booting for me with this branch, I need to add these two patches: * http://patchwork.kernel.org/patch/50721/ This one is needed because the defconfig has: CONFIG_TWL4030_USB=y * http://patchwork.kernel.org/patch/50970/ This is needed because most people boot from an MMC. You can add my 'tested-by' line if you want. Cheers. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap fixes for v2.6.32-rc3
* Felipe Contreras felipe.contre...@gmail.com [091008 14:29]: On Wed, Oct 7, 2009 at 9:51 PM, Tony Lindgren t...@atomide.com wrote: Linus, Please pull omap fixes from: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-fixes-for-linus Regards, Tony The following changes since commit 374576a8b6f865022c0fd1ca62396889b23d66dd: Linus Torvalds (1): Linux 2.6.32-rc3 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-fixes-for-linus Artem Bityutskiy (1): OMAP3: PM: introduce a new powerdomain walk helper Daniel Walker (1): omap: iovmm: Add missing mutex_unlock Hiroshi DOYU (1): omap: iovmm: Fix incorrect spelling Jon Hunter (1): OMAP3: PM: Prevent hang in prcm_interrupt_handler Kevin Hilman (1): OMAP3: PM: Enable GPIO module-level wakeups Paul Walmsley (2): OMAP3: PM: PRCM interrupt: check MPUGRPSEL register OMAP3: PM: PRCM interrupt: only handle selected PRCM interrupts Rajendra Nayak (1): omap: Lock DPLL5 at boot Sergio Aguirre (1): omapfb: Condition mutex acquisition Tommi Rantala (2): omapfb: Blizzard: fix pointer to be const omapfb: Blizzard: constify register address tables Tony Lindgren (2): omap: Fix incorrect 730 vs 850 detection Merge branch 'pm-fixes-32' of git://git.kernel.org/.../khilman/linux-omap-pm into omap-fixes-for-linus Vikram Pandita (1): OMAP3: PM: USBHOST: clear wakeup events on both hosts ye janboe (1): omap: SRAM: flush the right address after memcpy in omap_sram_push The beagleboard is still not booting for me with this branch, I need to add these two patches: * http://patchwork.kernel.org/patch/50721/ This should go to the mainline kernel via Samuel as it's drivers/mfd related. This one is needed because the defconfig has: CONFIG_TWL4030_USB=y * http://patchwork.kernel.org/patch/50970/ This is needed because most people boot from an MMC. And this should go in via the mmc list. So little more patience is still needed :) Cheers, Tony You can add my 'tested-by' line if you want. Cheers. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] updated PM branch, based on 2.6.32-rc1
On Tue, Oct 6, 2009 at 4:16 PM, Kevin Hilman khil...@deeprootsystems.com wrote: Kevin Hilman khil...@deeprootsystems.com writes: Hello, I've rebased/updated the PM branch based on current linux-omap master branch (2.6.32-rc1 based.) I've also updated the OMAP Power Management wiki, and the 'Current version' section highlights the changes, supported platforms as well as the features that have made it into mainline. http://elinux.org/OMAP_Power_Management#Current_version FYI... I just rebased the PM branch onto current omap/master. Some important user-visible changes: The /sys/power/* options are moving into debugfs. For mainline, these primarily debug options need to move to debugfs so I've moved them there. So, if you're missing some flag under /sys/power, it's now under /debug/pm_debug. I've updated the 'Using the PM branch' seciont of PM wiki[1] with the new filenames. Kevin [1] http://elinux.org/OMAP_Power_Management -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Hi, I build and tried this latest on Beagleboard (C2). Booting from MMC using ramdisk image. I changed the LL console to the 3rd UART. The issue I have is that after the system boots up it works for as long as I keep actively using it but if I leave it idle for a short time (~5s) it stops responding. I have tried waking it up using both UART and USER button on the board. This is with the default PM configuration. If I put the board into suspend (retention) it wakes up without any issues. Also, if I enable /debug/pm_debug/sleep_while_idle board wakes up without issues. Well the first couple characers on the console seem to go missing but I guess without CTS/RTS that is expected? Any pointers would be appreciated. - Juha -- Madness takes it's toll. Please have exact change. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap fixes for v2.6.32-rc3
On Fri, Oct 9, 2009 at 12:41 AM, Tony Lindgren t...@atomide.com wrote: * Felipe Contreras felipe.contre...@gmail.com [091008 14:29]: On Wed, Oct 7, 2009 at 9:51 PM, Tony Lindgren t...@atomide.com wrote: Linus, Please pull omap fixes from: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-fixes-for-linus Regards, Tony The following changes since commit 374576a8b6f865022c0fd1ca62396889b23d66dd: Linus Torvalds (1): Linux 2.6.32-rc3 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-fixes-for-linus Artem Bityutskiy (1): OMAP3: PM: introduce a new powerdomain walk helper Daniel Walker (1): omap: iovmm: Add missing mutex_unlock Hiroshi DOYU (1): omap: iovmm: Fix incorrect spelling Jon Hunter (1): OMAP3: PM: Prevent hang in prcm_interrupt_handler Kevin Hilman (1): OMAP3: PM: Enable GPIO module-level wakeups Paul Walmsley (2): OMAP3: PM: PRCM interrupt: check MPUGRPSEL register OMAP3: PM: PRCM interrupt: only handle selected PRCM interrupts Rajendra Nayak (1): omap: Lock DPLL5 at boot Sergio Aguirre (1): omapfb: Condition mutex acquisition Tommi Rantala (2): omapfb: Blizzard: fix pointer to be const omapfb: Blizzard: constify register address tables Tony Lindgren (2): omap: Fix incorrect 730 vs 850 detection Merge branch 'pm-fixes-32' of git://git.kernel.org/.../khilman/linux-omap-pm into omap-fixes-for-linus Vikram Pandita (1): OMAP3: PM: USBHOST: clear wakeup events on both hosts ye janboe (1): omap: SRAM: flush the right address after memcpy in omap_sram_push The beagleboard is still not booting for me with this branch, I need to add these two patches: * http://patchwork.kernel.org/patch/50721/ This should go to the mainline kernel via Samuel as it's drivers/mfd related. This one is needed because the defconfig has: CONFIG_TWL4030_USB=y * http://patchwork.kernel.org/patch/50970/ This is needed because most people boot from an MMC. And this should go in via the mmc list. Should it? Here you can see Uwe Kleine-König sending the original patch without even CC'ing the mmc list: http://marc.info/?l=linux-kernelm=124820861213849w=2 And it was unintentionally broken by this one: http://marc.info/?l=linux-mmcm=12524976347w=2 I don't see what we are waiting for, the code is clearly broken, even the compiler warns that nobody is using omap_hsmmc_probe(). -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] updated PM branch, based on 2.6.32-rc1
Juha Kuikka juha.kui...@gmail.com writes: On Tue, Oct 6, 2009 at 4:16 PM, Kevin Hilman khil...@deeprootsystems.com wrote: Kevin Hilman khil...@deeprootsystems.com writes: Hello, I've rebased/updated the PM branch based on current linux-omap master branch (2.6.32-rc1 based.) I've also updated the OMAP Power Management wiki, and the 'Current version' section highlights the changes, supported platforms as well as the features that have made it into mainline. http://elinux.org/OMAP_Power_Management#Current_version FYI... I just rebased the PM branch onto current omap/master. Some important user-visible changes: The /sys/power/* options are moving into debugfs. For mainline, these primarily debug options need to move to debugfs so I've moved them there. So, if you're missing some flag under /sys/power, it's now under /debug/pm_debug. I've updated the 'Using the PM branch' seciont of PM wiki[1] with the new filenames. Kevin [1] http://elinux.org/OMAP_Power_Management -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Hi, Hi Juha, I build and tried this latest on Beagleboard (C2). Booting from MMC using ramdisk image. I changed the LL console to the 3rd UART. The issue I have is that after the system boots up it works for as long as I keep actively using it but if I leave it idle for a short time (~5s) it stops responding. I have tried waking it up using both UART and USER button on the board. This is with the default PM configuration. Thanks for testing, and reporting your problem. I have noticed exactly the same problem and am still investigating it. If I put the board into suspend (retention) it wakes up without any issues. Also, if I enable /debug/pm_debug/sleep_while_idle board wakes up without issues. Well the first couple characers on the console seem to go missing but I guess without CTS/RTS that is expected? Yes, the loss of the first character is expected. Any pointers would be appreciated. I also noticed that it works when 'sleep_while_idle' is enabled, and this has led me to suspect a bug in that serial timout path, but I have yet to debug further. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] omap_hsmmc: Add missing probe handler hook
Andrew,
Here's a fix from Roger Quadros that was accidentally not posted
to linux-mmc as pointed out by Felipe Contreras on LKML.
Can you please pick it up?
For reference, this is the issue Uwe Kleine-König mentioned at:
http://www.mail-archive.com/linux-...@vger.kernel.org/msg00528.html
Felipe Contreras summarized how things broke at:
http://lkml.org/lkml/2009/10/8/334
Regards,
Tony
Content-Type: text/plain; charset=utf-8
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: [v2] omap_hsmmc: Add missing probe handler hook
Date: Fri, 02 Oct 2009 12:22:40 -
From: Roger Quadros ext-roger.quad...@nokia.com
X-Patchwork-Id: 51344
The missing probe handler hook will never probe the driver. Add it back.
Fixes broken MMC on OMAP.
We use platform_driver_probe() API since omap_hsmmc is not a hot-pluggable
device.
Signed-off-by: Roger Quadros ext-roger.quad...@nokia.com
Tested-by: Felipe Contreras felipe.contre...@gmail.com
Tested-by: Tony Lindgren t...@atomide.com
---
drivers/mmc/host/omap_hsmmc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 4487cc0..0aecaae 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2013,7 +2013,7 @@ static struct platform_driver omap_hsmmc_driver = {
static int __init omap_hsmmc_init(void)
{
/* Register the MMC driver */
- return platform_driver_register(omap_hsmmc_driver);
+ return platform_driver_probe(omap_hsmmc_driver, omap_hsmmc_probe);
}
static void __exit omap_hsmmc_cleanup(void)
Re: Patches merged to split OMAP2_IO_ADDRESS
Tony Lindgren had written, on 10/08/2009 01:08 PM, the following: * Shilimkar, Santosh santosh.shilim...@ti.com [091008 03:59]: Tony, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Tony Lindgren Sent: Thursday, October 08, 2009 5:55 AM To: linux-omap@vger.kernel.org Cc: Paul Walmsley Subject: Patches merged to split OMAP2_IO_ADDRESS Hi all, I've pushed Santosh' patches to split OMAP2_IO_ADDRESS into *_L3_IO_ADDRESS and *_L4_IO_ADDRESS so we can claim more kernel address space and support over 512MB of memory instead of 256MB. Of course, our goal is to convert everything except the .S files to use ioremap() instead, but that can now be done parallel and in smaller chunks. Please everybody, please convert your code to use ioremap(), there are static mappings already in place so it should work out of the box. I also had add two quick patches to keep things compiling, Paul can you take a look at them? I could not really test them as all the code is not there yet. Will post them as a reply to this thread. Thanks for the merge!! I have boot tested below platforms with latest LO master. 1. OMAP3430 SDP board - BOOT OK 2. OMAP3 BEAGLE - BOOT OK 3. OMAP 4430 SDP - BOOT OK with variation of patch: http://patchwork.kernel.org/patch/50531/ Great. I guess we still have some issues on 24xx with the hwmod, but hopefully we'll get that working again soon. Can somebody with 512MB memory on a board try the current l-o master and make sure things work? http://pastebin.mozilla.org/675489 3630 board with SDPdefconfig +8250 hack (with 3430 OPP values + wrong GPIOs) - boots up mostly fine.. Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap fixes for v2.6.32-rc3
* Felipe Contreras felipe.contre...@gmail.com [091008 15:20]: On Fri, Oct 9, 2009 at 1:13 AM, Felipe Contreras felipe.contre...@gmail.com wrote: On Fri, Oct 9, 2009 at 12:41 AM, Tony Lindgren t...@atomide.com wrote: * Felipe Contreras felipe.contre...@gmail.com [091008 14:29]: On Wed, Oct 7, 2009 at 9:51 PM, Tony Lindgren t...@atomide.com wrote: snip snip The beagleboard is still not booting for me with this branch, I need to add these two patches: * http://patchwork.kernel.org/patch/50721/ This should go to the mainline kernel via Samuel as it's drivers/mfd related. This one is needed because the defconfig has: CONFIG_TWL4030_USB=y * http://patchwork.kernel.org/patch/50970/ This is needed because most people boot from an MMC. And this should go in via the mmc list. Should it? Here you can see Uwe Kleine-König sending the original patch without even CC'ing the mmc list: http://marc.info/?l=linux-kernelm=124820861213849w=2 And it was unintentionally broken by this one: http://marc.info/?l=linux-mmcm=12524976347w=2 Er, actually that one was ok, the problem was introduced only in the final version: http://marc.info/?l=linux-mmcm=125366315417006w=2 Right, looks like Roger forgot to Cc linux-mmc. I don't see what we are waiting for, the code is clearly broken, even the compiler warns that nobody is using omap_hsmmc_probe(). I've sent Roger's patch to Andrew linux-mmc so hopefully it will get merged soon: http://www.mail-archive.com/linux-...@vger.kernel.org/msg00539.html Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Query: EHCI clock management approach
Gadiyar, Anand gadi...@ti.com writes:
I'd like to post a patch in a couple of days to refactor the EHCI
clock management code. This would be useful to do aggressive clock
management in the idle path.
A current implementation I have is to simply factor out the
clock_enable/disable calls out. Does it make sense to move this out
to mach-omap2/* and provide the function pointer through platform
data? Does the driver need to be aware of the clocks that it needs,
or is it sufficient for it to just call a platform-specific function
that turns on/off all the clocks needed by the driver?
The reason I ask is, in a future OMAP, we may need to enable a
different set of clocks, but we should be able to re-use the rest of
the code directly.
I am so glad you asked...
The short answer is: use omap_device.
Now that omap_hwmod + omap_device are in mainline (thanks to Paul
Walmsley), all new drivers need to use this.
Once an omap_hwmod and omap_device for EHCI are implemented, the
driver calls would be abstracted just like you are looking for.
Below[3], I extracted the comments dirctly from
arch/arm/plat-omap/omap_device.c which describe how the drivers would
use these. You can also look at an example of a converted MMC
driver[1] done by Paul.
Note that the abstraction via pdata to omap_device will be going away
by the time we reach 2.6.33 (hopefully.) By then the runtime PM
framework[2] will be available for OMAP and, drivers will use runtime
PM. The runtime PM core for OMAP will then call the omap_device layer
directly.
Kevin
[1] http://marc.info/?l=linux-omapm=124419789124570w=2
[2] http://elinux.org/OMAP_Power_Management#future_directions
[3] This is extracted directly from the header of
arch/arm/plat-omap/omap_device.c
Guidelines for usage by driver authors:
1. These functions are intended to be used by device drivers via
function pointers in struct platform_data. As an example,
omap_device_enable() should be passed to the driver as
struct foo_driver_platform_data {
...
int (*device_enable)(struct platform_device *pdev);
...
}
Note that the generic device_enable name is used, rather than
omap_device_enable. This is so other architectures can pass in their
own enable/disable functions here.
This should be populated during device setup:
...
pdata-device_enable = omap_device_enable;
...
2. Drivers should first check to ensure the function pointer is not null
before calling it, as in:
if (pdata-device_enable)
pdata-device_enable(pdev);
This allows other architectures that don't use similar device_enable()/
device_shutdown() functions to execute normally.
...
Suggested usage by device drivers:
During device initialization:
device_enable()
During device idle:
(save remaining device context if necessary)
device_idle();
During device resume:
device_enable();
(restore context if necessary)
During device shutdown:
device_shutdown()
(device must be reinitialized at this point to use it again)
--
To unsubscribe from this list: send the line unsubscribe 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 v3] OMAP3: introduce OMAP3630
--- SNIP ME --
Hi,
A bit of history for this patchset
V3 - Fixes from Sergio's comments + boot tested on SDP3430+3630.
V2 - fixes of generic comments from Felipe Balbi+minor cleanups
V1 - inital implementation of (a) approach
V0 - original approach introducing a new silicon family
--- END OF SNIP ME --
Device intro:
OMAP3630 is the latest in the family of OMAP3 devices
and among the changes it introduces are:
New OPP levels for new voltage and frequency levels. a bunch of
Bug fixes to various modules feature additions, notably with ISP,
sDMA etc.
Details about the chip is available here:
http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateId=6123navigationId=12836contentId=52606
Strategy used:
Strategy to introduce this device into Linux was discussed here:
Ref: http://marc.info/?t=12534330343r=1w=2
Two approaches were available:
a) Consider 3630 generation of devices as a new family of silicon
b) Consider 3630 as an offshoot of 3430 family of devices
As a common consensus, (b) seems to be more valid for 3630 as:
* There are changes which are easily handled by using FEATURES
infrastructure.
For details how to do this, see thread:
http://marc.info/?t=12505099851r=1w=2
* Most of existing 34xx infrastructure can be reused(almost 90%+)
- so no ugly if (cpu_is_omap34xx() || cpu_is_omap36xx())
all over the place
- lesser chance of bugs due to reuse of proven code flow
- 36xx specific handling can still be done where required
within the existing infrastructure
NOTE:
* If additional 34xx series are added, OMAP3430_REV_ES can be
added on top of the existing 3630 ones are renumbered
This patch was tested on SDP3430, boot tested on 3630 platform using
3430sdp defconfig
Signed-off-by: Madhusudhan Chikkature Rajashekar madhu...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
Cc: Allen Pais allen.p...@ti.com
Cc: Anand Gadiyar gadi...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Felipe Balbi felipe.ba...@nokia.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Sanjeev Premi pr...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Sergio Alberto Aguirre Rodriguez saagui...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/id.c | 32 +---
arch/arm/plat-omap/include/mach/cpu.h |6 ++
2 files changed, 35 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 03b80f2..2870d3b 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -186,6 +186,7 @@ void __init omap3_check_revision(void)
{
u32 cpuid, idcode;
u16 hawkeye;
+ u16 omap_type = 0;
u8 rev;
char *rev_name = ES1.0;
@@ -210,7 +211,9 @@ void __init omap3_check_revision(void)
hawkeye = (idcode 12) 0x;
rev = (idcode 28) 0xff;
- if (hawkeye == 0xb7ae) {
+ switch (hawkeye) {
+ case 0xb7ae:
+ /* Handle 34xx devices */
switch (rev) {
case 0:
omap_revision = OMAP3430_REV_ES2_0;
@@ -231,12 +234,35 @@ void __init omap3_check_revision(void)
default:
/* Use the latest known revision as default */
omap_revision = OMAP3430_REV_ES3_1;
- rev_name = Unknown revision\n;
+ rev_name = Unknown 34xx revision\n;
}
+ break;
+ case 0xb891:
+ /* Handle 36xx devices
+* But, override for display purposes
+*/
+ omap_type = 0x3630;
+ switch (rev) {
+ case 0:
+ omap_revision = OMAP3630_REV_ES1_0;
+ rev_name = ES1.0;
+ break;
+ default:
+ /* Use the latest known revision as default */
+ omap_revision = OMAP3630_REV_ES1_0;
+ rev_name = Unknown 36xx revision\n;
+ }
+ break;
+ default:
+ /* Unknown default to latest rev as default*/
+ omap_revision = OMAP3630_REV_ES1_0;
+ rev_name = Unknown revision\n;
}
out:
- pr_info(OMAP%04x %s\n, omap_rev() 16, rev_name);
+ if (!omap_type)
+ omap_type = omap_rev() 16;
+ pr_info(OMAP%04x %s\n, omap_type, rev_name);
}
#define OMAP3_SHOW_FEATURE(feat) \
diff --git a/arch/arm/plat-omap/include/mach/cpu.h
b/arch/arm/plat-omap/include/mach/cpu.h
index 431fec4..af1080f 100644
--- a/arch/arm/plat-omap/include/mach/cpu.h
+++ b/arch/arm/plat-omap/include/mach/cpu.h
@@ -383,6 +383,12 @@ IS_OMAP_TYPE(3430, 0x3430)
#define OMAP3430_REV_ES2_1 0x34302034
#define OMAP3430_REV_ES3_0 0x34303034
#define OMAP3430_REV_ES3_1 0x34304034
Re: Question on OPP table handling
Sanjeev, All, Cousson, Benoit had written, on 10/06/2009 07:52 AM, the following: Yes, it is true but you might have to disable dynamically some OPP (like OPP5 and OPP4) for thermal management reason. The way the resource is handled today, you cannot force the reduction of the frequency in case of thermal issue. I agree that there might be more elegant way to deal with that, but we can take advantage of disabling dynamically any OPP to do it. I would like to introduce OPP tables for 3630, but I will be dependent on http://marc.info/?l=linux-omapm=125442020209267w=2 Let me know how I can introduce the following into l-o + l-o pm. ( I suppose l-o first…): http://dev.omapzoom.org/?p=integration/kernel-omap3.git;a=blob;f=arch/arm/mach-omap2/omap3-opp.h;h=ac3ae6f219b37760de00e8e469ae3911d02f0304;hb=refs/heads/sync_wake-up3630#l74 Not sure of the status and plan on this. Could we sync on this? -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe 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: [ANNOUNCE] updated PM branch, based on 2.6.32-rc1
Kevin, On Thu, Oct 8, 2009 at 5:32 PM, Kevin Hilman khil...@deeprootsystems.com wrote: Juha Kuikka juha.kui...@gmail.com writes: Also, if I enable /debug/pm_debug/sleep_while_idle board wakes up without issues. Well the first couple characers on the console seem to go missing but I guess without CTS/RTS that is expected? Yes, the loss of the first character is expected. Curious Question: even with 3430 ES3.1 and IORING? I wonder why.. Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe 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][PATCH] OMAP3: introduce OMAP3630
-Original Message- From: Menon, Nishanth Sent: Thursday, October 08, 2009 8:11 PM To: Premi, Sanjeev Cc: Pandita, Vikram; Shilimkar, Santosh; linux-omap; Chikkature Rajashekar, Madhusudhan; Pais, Allen; Gadiyar, Anand; Cousson, Benoit; Kevin Hilman; Aguirre Rodriguez, Sergio Alberto; Tony Lindgren Subject: Re: [RFC][PATCH] OMAP3: introduce OMAP3630 Premi, Sanjeev had written, on 10/08/2009 09:23 AM, the following: -Original Message- From: Pandita, Vikram Sent: Thursday, October 08, 2009 7:01 PM To: Shilimkar, Santosh; Menon, Nishanth; linux-omap Cc: Chikkature Rajashekar, Madhusudhan; Pais, Allen; Gadiyar, Anand; Cousson, Benoit; Kevin Hilman; Premi, Sanjeev; Aguirre Rodriguez, Sergio Alberto; Tony Lindgren Subject: RE: [RFC][PATCH] OMAP3: introduce OMAP3630 -Original Message- From: Shilimkar, Santosh diff --git a/arch/arm/plat-omap/include/mach/cpu.h b/arch/arm/plat- omap/include/mach/cpu.h index 431fec4..af1080f 100644 --- a/arch/arm/plat-omap/include/mach/cpu.h +++ b/arch/arm/plat-omap/include/mach/cpu.h @@ -383,6 +383,12 @@ IS_OMAP_TYPE(3430, 0x3430) #define OMAP3430_REV_ES2_1 0x34302034 #define OMAP3430_REV_ES3_0 0x34303034 #define OMAP3430_REV_ES3_1 0x34304034 +/* NOTE: Add 36xx series below + * If additional 34xx series are added, OMAP3430_REV_ES can be + * added above the 3630 defines and series renumbered to ensure + * rev() checks to work + */ +#define OMAP3630_REV_ES1_0 0x34305034 #define OMAP443X_CLASS 0x44300034 Was expecting that this patch will add cpu_is_omap36xx() in cpu.h apart from above. Is this handled in another patch ? Idea is to re-use all 34xx code for 36xx, as per the mail thread on list, and given in reference. Hence at run time, the check could be: if (omap_rev() == OMAP3630_REV_ES1_0) x cpu_is_omap34xx() will be true for 36xx as well. [sp] This case seems quite similar to the OMAP35x. Can you look at this thread: http://marc.info/?l=linux-omapm=125372581804902w=2 It applies equally well here as well... I will be submitting updated patch tomorrow. yes, any specifics should be feature based IMHO. we will need to extend the feature list. If we are going to handle the delta 3630 changes w.r.t 3430 with feature based approach, its probably is the best thing. But in case delat code will be added like below then having a cpu_is_omap36xx() makes more sense. if (omap_rev() == OMAP3630_REV_ES1_0) x There is no harm having both cpu_is_omap36xx() and cpu_is_omap34xx() true for 3630 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 7/8] ASoC: tlv320aic3x: add initial usage of regulator framework to control avdd_dac
On Thu, 2009-10-08 at 18:01 +0200, ext Mark Brown wrote: On 8 Oct 2009, at 16:44, ext-eero.nurkk...@nokia.com wrote: Mark Brown wrote: Also, this is regulator thing is highly platform dependent, not aic3x related really at all, so is this the correct place... Just a thought, dont take it too seriously ;) I'm not sure what you mean by this? You may power the aic3x from a fixed source, or from multiple sources, with and without any regulator in between. It's up to the HW and HW design. The regulator API can cope with all this pretty transparently - if multiple supplies come from the same regulator the API will hide that from the consumer. There is a fixed voltage regulator driver which can be used to represent supplies with no soft control. Moreover, you don't _power off_ (turn the regulator off) the analog voltages of aic3x; things won't work. So it's not like a switch everybody may use. Or nothing prevent you from experiencing that... I'd expect the usage would be that after the audio subsystem has been idle for some configurable period of time the core would bring the audio subsystem down to bias off, at which point supplies could also be switched off. Right. That would also sound like the RST line also needs also be asserted, and then rewriting all register contents upon wakeup? And also redirecting all i2c traffic to the cache instead of any real i2c writes (meanwhile the device is shut down)? Like in tpa6130? - Eero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/8] McBSP: OMAP3: Add Sidetone feature
On Thu, 2009-10-08 at 15:17 +0200, ext Mark Brown wrote:
On Thu, Oct 08, 2009 at 02:58:52PM +0300, Eduardo Valentin wrote:
+static const struct attribute *sidetone_attrs[] = {
+ dev_attr_st_enable.attr,
+ dev_attr_st_taps.attr,
+ dev_attr_st_ch0gain.attr,
+ dev_attr_st_ch1gain.attr,
+ NULL,
+};
This stuff, particularly the enable, probably wants to be pushed out via
an ALSA API rather than via random sysfs stuff. It'd be better to
publish a control API here and then use that from within ALSA.
Hmm. What would be the way to transfer 128 x s16 words; is there an ALSA
control for something like that already ? IIRC correctly, the max
bytesize per control is (or used to be) something like 256 bytes or so.
So that gets right at it. (that's the sidetone 128 tap FIR in question)
- Eero
--
To unsubscribe from this list: send the line unsubscribe 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: Patches merged to split OMAP2_IO_ADDRESS
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Thursday, October 08, 2009 11:38 PM To: Shilimkar, Santosh Cc: linux-omap@vger.kernel.org; Paul Walmsley Subject: Re: Patches merged to split OMAP2_IO_ADDRESS * Shilimkar, Santosh santosh.shilim...@ti.com [091008 03:59]: Tony, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Tony Lindgren Sent: Thursday, October 08, 2009 5:55 AM To: linux-omap@vger.kernel.org Cc: Paul Walmsley Subject: Patches merged to split OMAP2_IO_ADDRESS Hi all, I've pushed Santosh' patches to split OMAP2_IO_ADDRESS into *_L3_IO_ADDRESS and *_L4_IO_ADDRESS so we can claim more kernel address space and support over 512MB of memory instead of 256MB. Of course, our goal is to convert everything except the .S files to use ioremap() instead, but that can now be done parallel and in smaller chunks. Please everybody, please convert your code to use ioremap(), there are static mappings already in place so it should work out of the box. I also had add two quick patches to keep things compiling, Paul can you take a look at them? I could not really test them as all the code is not there yet. Will post them as a reply to this thread. Thanks for the merge!! I have boot tested below platforms with latest LO master. 1. OMAP3430 SDP board - BOOT OK 2. OMAP3 BEAGLE - BOOT OK 3. OMAP 4430 SDP - BOOT OK with variation of patch: http://patchwork.kernel.org/patch/50531/ Great. I guess we still have some issues on 24xx with the hwmod, but hopefully we'll get that working again soon. Can somebody with 512MB memory on a board try the current l-o master and make sure things work? Please check the dmesg for no overlaps in virtual address space, then run some memory test like memtester. Boot tested on OMAP4430 with 512MB and dmesg don't show any overlaps. Will run some memory test tomorrow. Regrads 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
