Re: [PATCH 1/8] ARM: OMAP3: mmc-twl4030 uses regulator framework
On Mon, May 25, 2009 at 07:47:30PM -0300, Daniel Ribeiro wrote: This hack would look less ugly on twl4030reg_probe(). There you can disable the regulator without first enabling it. That might cause issues when running on a platform where someone has used the MMC regulators for some purpose other than MMC and expects them to stay on during boot. It can be done via the machine constraints if required, though. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Please help in adding ams-delta support to ASoC
Hi, I am trying to add sound support for ams-delta omap machine, yet without much success. Three years ago, Mark Underwood created an omap-alsa compatible driver that basically worked[1]. It was derieved from similiar driver for aic23 codec found on omap osk machine. It looks like Mark has never managed to finish his work. It's not clear for me if he has found that getting a working fullduplex sound is technically impossible on a voice modem codec, shared among modem and cpu, controlable only from modem side afaik, but I have decided to give it a try. Since Mark's initial work, omap-alsa framework has been depreciated in favour of soc-omap. API changes are so significant that Mark's code is rather not useable directly any more. However, I am trying to use it as a starting point, by comparing it against it's prototype osk/aic23 code. Following Mark, I am trying to derieve the new ams-delta sound driver from current asoc driver for omap osk9512. For codec part, I decided to base my work on much more simple ad73311 rather that tlv320aic23. Comparing Mark's code agaist it's osk/aic23 prototype, I can see the folowing significant changes: 1. rate tables/bitmaps found in hw_constraint_rates, snd_omap_alsa_playback and snd_omap_alsa_capture structures limited to 8kHz, 2. hardware related code found in codec_configure_dev(), codec_clock_on() and codec_clock_off() callback functions replaced with ams-delta hardware specific code that switches the codec DAI pins from modem chip to mcbsp cpu interface and back, 3. codec_set_samplerate() and all mixer related functions replaced with stubs. 4. the following McBSP register settings changes: - .xcr2 = XPHASE | XFRLEN2(OMAP_MCBSP_WORD_8) | - XWDLEN2(OMAP_MCBSP_WORD_16) | XDATDLY(0) | XFIG, + .xcr2 = XPHASE | XWDLEN2(OMAP_MCBSP_WORD_16) | XFRLEN2(0), - .srgr1 = FWID(DEFAULT_BITPERSAMPLE - 1), + .srgr1 = CLKGDV(0), - .srgr2 = GSYNC | CLKSP | FSGM | FPER(DEFAULT_BITPERSAMPLE * 2 - 1), + .srgr2 = GSYNC, - .pcr0 = CLKXP | CLKRP, /* mcbsp: slave */ I have found points 1. to 3. rather trivial to implement in new framework. Regarding point 4., it looks like detailed register settings are now done inside omap-mcbsp.c, based on machine specified format, so I have to find out what format should be specified for ams-delta. Please correct me if I am missing something. There was one more modification in Mark's code, addressing dma chaining problem on omap15xx hardware, but as far as I could see, the problem was already solved in the asoc omap framework. Initially, I based my work on ompenembedded provided linux-omap.git revision 90e758af52ba803cba233fabee81176d99589f09. The results were rather poor - total system hangup after first device access, with no single message. So I have switched to linux-2.6.30-rc5 and now I can safely access the device, however it does not work as expected. aplay and arecord wait forever, cat to/from /dev/dsp breaks with hardware error messgae. DMA interrput counters stay at 0. However, codec switching that I do from machine-ops-startup/shutdown seems working, as modem stops producing any sounds while the alsa device is in use and gets back thereafter. First of all, I'd like to make sure if my problem is related to my code only. As I am new in these areas, I would like to ask you if the omap asoc framework is stable enough to relay on. If yes, could you please look at my dirty code (attached) an give me some hints? I can provide you with more information if necessary. Regards, Janusz [1] http://www.earth.li/pipermail/e3-hacking/2006-April/000481.html diff -Npru git/sound/soc/codecs/Kconfig git/sound/soc/codecs/Kconfig --- git/sound/soc/codecs/Kconfig 2009-05-12 21:13:59.0 +0200 +++ git/sound/soc/codecs/Kconfig 2009-05-18 22:31:15.0 +0200 @@ -12,6 +12,7 @@ config SND_SOC_ALL_CODECS tristate Build all ASoC CODEC drivers select SND_SOC_AC97_CODEC if SND_SOC_AC97_BUS select SND_SOC_AD1980 if SND_SOC_AC97_BUS + select SND_SOC_CX20442 select SND_SOC_AD73311 if I2C select SND_SOC_AK4535 if I2C select SND_SOC_CS4270 if I2C @@ -55,6 +56,9 @@ config SND_SOC_AC97_CODEC config SND_SOC_AD1980 tristate +config SND_SOC_CX20442 + tristate + config SND_SOC_AD73311 tristate diff -Npru git/sound/soc/codecs/Makefile git/sound/soc/codecs/Makefile --- git/sound/soc/codecs/Makefile 2009-05-12 21:13:59.0 +0200 +++ git/sound/soc/codecs/Makefile 2009-05-18 22:33:32.0 +0200 @@ -1,5 +1,6 @@ snd-soc-ac97-objs := ac97.o snd-soc-ad1980-objs := ad1980.o +snd-soc-cx20442-objs := cx20442.o snd-soc-ad73311-objs := ad73311.o snd-soc-ak4535-objs := ak4535.o snd-soc-cs4270-objs := cs4270.o @@ -28,6 +29,7 @@ snd-soc-wm9713-objs := wm9713.o obj-$(CONFIG_SND_SOC_AC97_CODEC) += snd-soc-ac97.o obj-$(CONFIG_SND_SOC_AD1980) += snd-soc-ad1980.o +obj-$(CONFIG_SND_SOC_CX20442) += snd-soc-cx20442.o obj-$(CONFIG_SND_SOC_AD73311)
[RFC][PATCH] OMAP3: add support for 2 SDRAM chip selects (was: Re: Beagleboard rev C memory timings suspend/resume)
Hi Paul, Kevin,
Here is a patch for the SDRC 2nd CS support. It applies on top of the current
pm branch.
I have some questions:
- Is it OK to copy the micron sdram params file to a new file with the 2 CSes
params? One could use a unique file with #ifdef SDRC_SUPPORT_2_CSES.
- Does the RX51 board have 2 sdram parts? If so I need to update the board
file as well.
Comments are welcome.
Regards,
Jean
From 517f52f4bef8225c5921b55ecd96eda2e0c4b697 Mon Sep 17 00:00:00 2001
From: Jean Pihet jpi...@mvista.com
Date: Tue, 26 May 2009 14:55:57 +0200
Subject: [PATCH] OMAP3: add support for 2 SDRAM chip selects
Some boards (Beagle Cx, Overo) have 2 SDRAM parts
connected to the SDRC.
This patch adds the following:
- ensure that the CKE signals mux settings are correct
- extend the omap_sdrc_params struct with the 2nd CS params
- add a new file for the micron sdram params for 2 CSes
- adapt the sram sleep code to configure the SDRC for the 2nd CS
Thanks to Paul Walmsley and Kevin Hilman for the suggestions
and code reviews.
Tested on Beagleboard rev C2 and B5.
Signed-off-by: Jean Pihet jpi...@mvista.com
On Monday 11 May 2009 22:27:50 Paul Walmsley wrote:
Hi Jean,
On Mon, 11 May 2009, Jean Pihet wrote:
On Saturday 09 May 2009 00:43:43 Paul Walmsley wrote:
One possibility: perhaps the problem is with Beagle's pin mux settings.
You might want to boot with mem=128M and make sure
CONTROL_PADCONF_SAD2D_SBUSFLAG and CONTROL_PADCONF_SDRC_CKE1 are in
mode 0 before suspend and after resume.
Yes that definitely is the root cause. I should have checked this first
;-( The U-Boot change is committed, cf.
http://gitorious.org/u-boot-omap3/mainline/commit/c6f01ad390308800693c62d
bdb096ab59e03630b and
http://gitorious.org/u-boot-omap3/mainline/commit/4025cfbde3611b14c0d4831
a5524e5e061128e30
Nice work!
Sounds like we should also patch mach-omap2/sdrc.c:omap2_sdrc_init() to
warn if the sdrc_cke1 pin mux is wrong if a second struct omap_sdrc_params
* is passed. Probably board-omap3beagle.c should also remux the pad if
it's wrong. Otherwise there will be a lot of unhappy Rev C BeagleBoard
users.
I am looking at a fix for the SDRC setup with 2 CSes. I will propose the
changes asap.
Excellent, thanks Jean.
- Paul
From 517f52f4bef8225c5921b55ecd96eda2e0c4b697 Mon Sep 17 00:00:00 2001
From: Jean Pihet jpi...@mvista.com
Date: Tue, 26 May 2009 14:55:57 +0200
Subject: [PATCH] OMAP3: add support for 2 SDRAM chip selects
Some boards (Beagle Cx, Overo) have 2 SDRAM parts
connected to the SDRC.
This patch adds the following:
- ensure that the CKE signals mux settings are correct
- extend the omap_sdrc_params struct with the 2nd CS params
- add a new file for the micron sdram params for 2 CSes
- adapt the sram sleep code to configure the SDRC for the 2nd CS
Thanks to Paul Walmsley and Kevin Hilman for the suggestions
and code reviews.
Tested on Beagleboard rev C2 and B5.
Signed-off-by: Jean Pihet jpi...@mvista.com
---
arch/arm/mach-omap2/board-omap3beagle.c|6 +-
arch/arm/mach-omap2/board-overo.c |6 +-
arch/arm/mach-omap2/board-rx51-sdram.c |8 +-
arch/arm/mach-omap2/clock34xx.c| 18 ++-
arch/arm/mach-omap2/mux.c |6 +
.../mach-omap2/sdram-micron-mt46h32m32lf-6-2cses.h | 93 ++
arch/arm/mach-omap2/sdram-micron-mt46h32m32lf-6.h | 60 +-
.../mach-omap2/sdram-qimonda-hyb18m512160af-6.h| 40 +++---
arch/arm/mach-omap2/sdrc.c | 15 ++-
arch/arm/mach-omap2/sram34xx.S | 128 +++-
arch/arm/plat-omap/include/mach/mux.h |4 +
arch/arm/plat-omap/include/mach/sdrc.h | 23 +++--
arch/arm/plat-omap/include/mach/sram.h | 12 +-
arch/arm/plat-omap/sram.c | 34 +++--
14 files changed, 329 insertions(+), 124 deletions(-)
create mode 100644 arch/arm/mach-omap2/sdram-micron-mt46h32m32lf-6-2cses.h
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index 7294dbf..7128213 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -110,7 +110,7 @@ static struct platform_device omap3beagle_nand_device = {
.resource = omap3beagle_nand_resource,
};
-#include sdram-micron-mt46h32m32lf-6.h
+#include sdram-micron-mt46h32m32lf-6-2cses.h
static struct omap_uart_config omap3_beagle_uart_config __initdata = {
.enabled_uarts = ((1 0) | (1 1) | (1 2)),
@@ -441,6 +441,10 @@ static void __init omap3_beagle_init(void)
usb_musb_init();
usb_ehci_init();
omap3beagle_flash_init();
+
+ /* Ensure SDRC pins are mux'd for self-refresh */
+ omap_cfg_reg(H16_34XX_SDRC_CKE0);
+ omap_cfg_reg(H17_34XX_SDRC_CKE1);
}
static void __init omap3_beagle_map_io(void)
diff --git a/arch/arm/mach-omap2/board-overo.c b/arch/arm/mach-omap2/board-overo.c
index
Re: [PATCH 1/2] McSPI Slave and DMA,FIFO support
Tony, Any update on this patch.
Thanks
Hemanth
This patch adds support for McSPI slave and FIFO. DMA and FIFO
could be enabled together for better throughput. Platform config
parameters have been added to enable these features on any particular
McSPI controller.
FIFO can be enabled by defining fifo_depth parameter. fifo_depth needs
to be a multiple of buffer size that is used for read/write.
These features are useful when you have high throughput devices
like WLAN or Modem connected over SPI.
Signed-off-by: Hemanth V heman...@ti.com
arch/arm/mach-omap2/devices.c |5
arch/arm/plat-omap/include/mach/mcspi.h | 16 +
drivers/spi/omap2_mcspi.c | 343
3 files changed, 325 insertions(+), 39 deletions(-)
---
Index: linux-omap-2.6/arch/arm/mach-omap2/devices.c
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/devices.c 2009-05-19
17:00:21.0 +0530
+++ linux-omap-2.6/arch/arm/mach-omap2/devices.c 2009-05-20
11:02:41.0
+0530
@@ -259,6 +259,7 @@
static struct omap2_mcspi_platform_config omap2_mcspi1_config = {
.num_cs = 4,
+ .force_cs_mode = 1,
};
static struct resource omap2_mcspi1_resources[] = {
@@ -281,6 +282,10 @@
static struct omap2_mcspi_platform_config omap2_mcspi2_config = {
.num_cs = 2,
+ .mode = OMAP2_MCSPI_MASTER,
+ .dma_mode = 1,
+ .force_cs_mode = 0,
+ .fifo_depth = 0,
};
static struct resource omap2_mcspi2_resources[] = {
Index: linux-omap-2.6/arch/arm/plat-omap/include/mach/mcspi.h
===
--- linux-omap-2.6.orig/arch/arm/plat-omap/include/mach/mcspi.h
2009-05-19
17:00:21.0 +0530
+++ linux-omap-2.6/arch/arm/plat-omap/include/mach/mcspi.h2009-05-20
11:02:41.0 +0530
@@ -1,8 +1,24 @@
#ifndef _OMAP2_MCSPI_H
#define _OMAP2_MCSPI_H
+#define OMAP2_MCSPI_MASTER 0
+#define OMAP2_MCSPI_SLAVE1
+
struct omap2_mcspi_platform_config {
unsigned short num_cs;
+
+ /* SPI is master or slave */
+ unsigned short mode;
+
+ /* Use only DMA for data transfers */
+ unsigned short dma_mode;
+
+ /* Force chip select mode */
+ unsigned short force_cs_mode;
+
+ /* FIFO depth in bytes, max value 64 */
+ unsigned short fifo_depth;
+
};
struct omap2_mcspi_device_config {
Index: linux-omap-2.6/drivers/spi/omap2_mcspi.c
===
--- linux-omap-2.6.orig/drivers/spi/omap2_mcspi.c 2009-05-19
17:00:21.0
+0530
+++ linux-omap-2.6/drivers/spi/omap2_mcspi.c 2009-05-20 11:02:41.0
+0530
@@ -37,9 +37,11 @@
#include mach/dma.h
#include mach/clock.h
+#include mach/mcspi.h
#define OMAP2_MCSPI_MAX_FREQ 4800
+#define OMAP2_MCSPI_MAX_FIFODEPTH64
#define OMAP2_MCSPI_REVISION 0x00
#define OMAP2_MCSPI_SYSCONFIG0x10
@@ -49,6 +51,7 @@
#define OMAP2_MCSPI_WAKEUPENABLE 0x20
#define OMAP2_MCSPI_SYST 0x24
#define OMAP2_MCSPI_MODULCTRL0x28
+#define OMAP2_MCSPI_XFERLEVEL0x7c
/* per-channel banks, 0x14 bytes each, first is: */
#define OMAP2_MCSPI_CHCONF0 0x2c
@@ -85,6 +88,9 @@
#define OMAP2_MCSPI_CHCONF_ISBIT(18)
#define OMAP2_MCSPI_CHCONF_TURBO BIT(19)
#define OMAP2_MCSPI_CHCONF_FORCE BIT(20)
+#define OMAP2_MCSPI_CHCONF_FFER BIT(28)
+#define OMAP2_MCSPI_CHCONF_FFET BIT(27)
+
#define OMAP2_MCSPI_CHSTAT_RXS BIT(0)
#define OMAP2_MCSPI_CHSTAT_TXS BIT(1)
@@ -93,6 +99,7 @@
#define OMAP2_MCSPI_CHCTRL_ENBIT(0)
#define OMAP2_MCSPI_WAKEUPENABLE_WKENBIT(0)
+#define OMAP2_MCSPI_IRQ_EOW BIT(17)
/* We have 2 DMA channels per CS, one for RX and one for TX */
struct omap2_mcspi_dma {
@@ -125,6 +132,10 @@
unsigned long phys;
/* SPI1 has 4 channels, while SPI2 has 2 */
struct omap2_mcspi_dma *dma_channels;
+ unsigned short mcspi_mode;
+ unsigned short dma_mode;
+ unsigned short force_cs_mode;
+ unsigned short fifo_depth;
};
struct omap2_mcspi_cs {
@@ -133,6 +144,37 @@
int word_len;
};
+#ifdef CONFIG_SPI_DEBUG
+struct reg_type {
+ char name[40];
+ int offset;
+};
+
+static struct reg_type reg_map[] = {
+ {MCSPI_REV, 0x0},
+ {MCSPI_SYSCONFIG, 0x10},
+ {MCSPI_SYSSTATUS, 0x14},
+ {MCSPI_IRQSTATUS, 0x18},
+ {MCSPI_IRQENABLE, 0x1C},
+ {MCSPI_WAKEUPENABLE, 0x20},
+ {MCSPI_SYST, 0x24},
+ {MCSPI_MODULCTRL, 0x28},
+ {MCSPI_XFERLEVEL, 0x7c},
+ {CH0, 0x2C},
+ {CH1, 0x40},
+ {CH2, 0x54},
+ {CH3, 0x68}
+};
+
Re: [PATCH 00/10] OMAP clock/SDRC patches on v2.6.30-rc5
Hello Russell, On Tue, 12 May 2009, Paul Walmsley wrote: This series contains OMAP clock and SDRAM controller patches against v2.6.30-rc5. If you are happy with these, Tony will merge them into his for-next branch for you to pull. This series includes the clk_init_one() to clk_preinit() rename that we've discussed recently. Most of the patches prepare for CORE DPLL M2 rate changing support. Any comments on these patches? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/10] OMAP clock/SDRC patches on v2.6.30-rc5
On Tue, May 26, 2009 at 10:29:52AM -0600, Paul Walmsley wrote: Hello Russell, On Tue, 12 May 2009, Paul Walmsley wrote: This series contains OMAP clock and SDRAM controller patches against v2.6.30-rc5. If you are happy with these, Tony will merge them into his for-next branch for you to pull. This series includes the clk_init_one() to clk_preinit() rename that we've discussed recently. Most of the patches prepare for CORE DPLL M2 rate changing support. Any comments on these patches? All look fine to me. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/10] OMAP clock/SDRC patches on v2.6.30-rc5
On Tue, 26 May 2009, Russell King - ARM Linux wrote: On Tue, May 26, 2009 at 10:29:52AM -0600, Paul Walmsley wrote: Hello Russell, On Tue, 12 May 2009, Paul Walmsley wrote: This series contains OMAP clock and SDRAM controller patches against v2.6.30-rc5. If you are happy with these, Tony will merge them into his for-next branch for you to pull. This series includes the clk_init_one() to clk_preinit() rename that we've discussed recently. Most of the patches prepare for CORE DPLL M2 rate changing support. Any comments on these patches? All look fine to me. Great, thanks. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][PATCH] Add support for hook switch on ams-delta
Hi,
This trivial patch adds gpio-keys compatible platform device definition to
ams-delta board, that supports hook switch found on this videophone. It is
derived from similiar definitions found in other boards code. The patch is
based on linux-2.6.30-rc5. Any comments are welcome.
Cheers,
Janusz
diff -Npru a/arch/arm/mach-omap1/board-ams-delta.c b/arch/arm/mach-omap1/board-ams-delta.c
--- a/arch/arm/mach-omap1/board-ams-delta.c 2009-05-17 17:58:18.0 +0200
+++ b/arch/arm/mach-omap1/board-ams-delta.c 2009-05-17 16:22:59.0 +0200
@@ -15,6 +15,7 @@
#include linux/kernel.h
#include linux/init.h
#include linux/input.h
+#include linux/gpio_keys.h
#include linux/platform_device.h
#include mach/hardware.h
@@ -213,10 +214,35 @@ static struct platform_device ams_delta_
.id = -1
};
+static struct gpio_keys_button ams_delta_gpio_keys_buttons[] = {
+ [0] = {
+ .desc = hook_switch,
+ .type = EV_SW, /* or EV_KEY ? */
+ .code = SW_HEADPHONE_INSERT, /* or a new one ? */
+ .active_low = 1,
+ .gpio = AMS_DELTA_GPIO_PIN_HOOK_SWITCH,
+ .debounce_interval = 10,
+ },
+};
+
+static struct gpio_keys_platform_data ams_delta_gpio_keys = {
+ .buttons = ams_delta_gpio_keys_buttons,
+ .nbuttons = ARRAY_SIZE(ams_delta_gpio_keys_buttons),
+};
+
+static struct platform_device ams_delta_gpio_keys_device = {
+ .name = gpio-keys,
+ .id = -1,
+ .dev = {
+ .platform_data = ams_delta_gpio_keys,
+ },
+};
+
static struct platform_device *ams_delta_devices[] __initdata = {
ams_delta_kp_device,
ams_delta_lcd_device,
ams_delta_led_device,
+ ams_delta_gpio_keys_device,
};
static void __init ams_delta_init(void)
@@ -233,6 +259,13 @@ static void __init ams_delta_init_irq(vo
omap_usb_init(ams_delta_usb_config);
platform_add_devices(ams_delta_devices, ARRAY_SIZE(ams_delta_devices));
+
+ omap_cfg_reg(P20_1610_GPIO4); /* is this required? */
+
+ /* The hook switch state could be exposed over sysfs with gpio_export().
+ * This should be done after the gpio-keys driver calls gpio_request(),
+ * but I don't know how to do this from outside of the driver. */
+ /* gpio_export(AMS_DELTA_GPIO_PIN_HOOK_SWITCH, 0); */
}
static void __init ams_delta_map_io(void)
Re: Gumstix Overo Low Power Standby?
On May 20, 2009, at 1:55 PM, Kevin Hilman wrote: Kevin Hilman khil...@deeprootsystems.com writes: Blazej Kot bj...@cornell.edu writes: I have been working with the linux-pm kernel on the Gumstix Overo, seeing how low it's power consumption can go, both during the cpu on and especially while the CPU is suspended. Thus far, I've had some disappointing results, the best I could get is about 500mW while on, and 250mW while suspended (ie by running echo mem /sys/power/ state). I am led to believe that the OMAP processor is capable of much lower power consumption during standby. I am wondering if anybody in the gumstix community is looking into the software support for very-low-power modes on the overo. If so, I am wondering what the lowest power levels are which you have reached during standby are. I have seen this: http://markmail.org/message/ge5hec5f5asp7a67#query:omap%20linux %2080%20ma+page:1+mid:t2erlwweknakm767+state:results Which seems to indicate the lowest power reached is 80mA at 3.3V - 0.264 W, which is about what I'm seeing. Is it really true that the overo draws a quarter of a watt when doing absolutely nothing? There are lots of factors involved. The current OMAP PM branch is focused on minimizing power consumed by the OMAP SoC itself. However, there are lots of other things on- board (audio codecs, regulators, WiFi chipsets etc.) that can consume power that we may not be currently managing in the omap kernel. I don't have an Overo so am not familiar with all the on board peripherals, but you should probably do some experiments where you can put all the on-board devices into low-power/off states and run some experiments as well. In the case of the Beagle results you referenced, I'm pretty sure it is something on board that is drawing the ~80mA and not on-chip. I assume this because setting the OMAP to use OFF-mode in suspend or idle results in the drop of a few mA reflecting an expected drop in power consumed by OMAP itself, but still leaving lots of power consumed. For example, testing today's PM branch on Beagle gives me roughly the same numbers as the post you referenced, but slightly better: - boot idle: 323 mA - screen blank: 216 mA # echo 3 /sys/class/graphics/fb0/blank - suspend (OMAP retention): 75 mA # echo mem /sys/power/state - sleep-while-idle: 75 mA - this same power state as suspend, but happens in idle # echo 1 /sys/power/sleep_while_idle - suspend (OMAP off): 72 mA # echo 1 /sys/power/enable_off_mode # echo 1 /sys/power/voltage_off_while_idle Ultimitately the answer is that more work needs to be done with the using the regulator framework and/or the drivers for the on-chip peripherals to be sure they can be powered off when needed. After digging a little more in the beagle forums, someone has already done the work to confirm that it is indeed board level design and issues that are drawing the rest of the power on Beagle. There's a thread[1] in the beagleboard list about how to get down to 8mW power on Beagle, but it does require hardware changes. This should shed some light on the types of things you'd probably have to do for Overo. Kevin [1] http://groups.google.com/group/beagleboard/browse_thread/thread/197a8ef6b46cc828/6e98db4cbe2cebaa?# Thanks for that, it is an interesting link. I have now reached the new low of around 170mW (at 3.28V), but this is high. I basically used the TWL (PMC) scripts in the linked post, and also turned off the U6 chip on the gumstix, which is the USB PHY layer driver. Also, I noticed that my systems becomes unusable after suspending for more than abut a minute, and it will not wake from sleep. I will try to troubleshot and narrow this down. I am wondering, is there anyone out there working on PM issues on the Gumstix? Perhaps if there are some gumstix company people here they can answer what their status is. I will ask around on the gumstix emailing list also. thanks, Blazej -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/10] OMAP clock/SDRC patches on v2.6.30-rc5
* Paul Walmsley p...@pwsan.com [090526 09:53]: On Tue, 26 May 2009, Russell King - ARM Linux wrote: On Tue, May 26, 2009 at 10:29:52AM -0600, Paul Walmsley wrote: Hello Russell, On Tue, 12 May 2009, Paul Walmsley wrote: This series contains OMAP clock and SDRAM controller patches against v2.6.30-rc5. If you are happy with these, Tony will merge them into his for-next branch for you to pull. This series includes the clk_init_one() to clk_preinit() rename that we've discussed recently. Most of the patches prepare for CORE DPLL M2 rate changing support. Any comments on these patches? All look fine to me. Great, thanks. I've pulled these to the omap for-next branch to wait for the merge window. 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
[PATCH 00/10] OMAP clock/powerdomain/SDRC patches for post-2.6.30
Hello Russell, here is the next set of OMAP clock patches for review for the post-2.6.30 merge window. They apply on top of the previous set (OMAP clock/SDRC patches on v2.6.30-rc5). If you're happy with these patches, Tony will queue them up into his for-next branch. This series completes basic support for OMAP3 CORE DVFS. A few other minor bugs are fixed by the off-by-one patch and the GPIO debounce clock patch. regards, - Paul --- Paul Walmsley (8): OMAP3 clock: GPIO de-bounce clocks don't affect module idle state OMAP3 SDRC: set FIXEDDELAY when disabling SDRC DLL OMAP3 SRAM: convert SRAM code to use macros rather than magic numbers OMAP3 SRAM: add more comments on the SRAM code OMAP3 clock/SDRC: program SDRC_MR register during SDRC clock change OMAP3 clock: add a short delay when lowering CORE clk rate OMAP3 clock: initialize SDRC timings at kernel start OMAP3 clock: remove wait for DPLL3 M2 clock to stabilize Roel Kluin (1): OMAP2 clock/powerdomain: off by 1 error in loop timeout comparisons Tero Kristo (1): OMAP3: Add support for DPLL3 divisor values higher than 2 arch/arm/mach-omap2/clock.c|2 arch/arm/mach-omap2/clock34xx.c| 42 -- arch/arm/mach-omap2/clock34xx.h| 12 +-- arch/arm/mach-omap2/io.c | 38 + arch/arm/mach-omap2/powerdomain.c |2 arch/arm/mach-omap2/sram34xx.S | 129 +--- arch/arm/plat-omap/include/mach/sram.h |6 + arch/arm/plat-omap/sram.c |8 +- 8 files changed, 171 insertions(+), 68 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/10] OMAP3 clock: remove wait for DPLL3 M2 clock to stabilize
The original CDP kernel that this code comes from waited for 0x800 loops after switching the CORE DPLL M2 divider. This does not appear to be necessary. Signed-off-by: Paul Walmsley p...@pwsan.com --- arch/arm/mach-omap2/sram34xx.S |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-omap2/sram34xx.S b/arch/arm/mach-omap2/sram34xx.S index c080c82..84781a6 100644 --- a/arch/arm/mach-omap2/sram34xx.S +++ b/arch/arm/mach-omap2/sram34xx.S @@ -102,9 +102,6 @@ configure_core_dpll: orr r12, r12, r3, lsl #0x1B @ r3 contains the M2 val str r12, [r11] ldr r12, [r11] @ posted-write barrier for CM - mov r12, #0x800 @ wait for the clock to stabilise - cmp r3, #2 - bne wait_clk_stable bx lr wait_clk_stable: subsr12, r12, #1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/10] OMAP3 clock: initialize SDRC timings at kernel start
On the OMAP3, initialize SDRC timings when the kernel boots. This ensures
that the kernel is running with known, optimized SDRC timings, rather than
whatever was configured by the bootloader.
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/clock34xx.c |3 ---
arch/arm/mach-omap2/io.c| 38 ++
2 files changed, 38 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
index 62092f2..a62e326 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -715,9 +715,6 @@ static int omap3_core_dpll_m2_set_rate(struct clk *clk,
unsigned long rate)
if (clk != dpll3_m2_ck)
return -EINVAL;
- if (rate == clk-rate)
- return 0;
-
validrate = omap2_clksel_round_rate_div(clk, rate, new_div);
if (validrate != rate)
return -EINVAL;
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 916fcd3..2756f49 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -19,6 +19,7 @@
#include linux/kernel.h
#include linux/init.h
#include linux/io.h
+#include linux/clk.h
#include asm/tlb.h
@@ -195,6 +196,40 @@ void __init omap2_map_common_io(void)
omapfb_reserve_sdram();
}
+/*
+ * omap2_init_reprogram_sdrc - reprogram SDRC timing parameters
+ *
+ * Sets the CORE DPLL3 M2 divider to the same value that it's at
+ * currently. This has the effect of setting the SDRC SDRAM AC timing
+ * registers to the values currently defined by the kernel. Currently
+ * only defined for OMAP3; will return 0 if called on OMAP2. Returns
+ * -EINVAL if the dpll3_m2_ck cannot be found, 0 if called on OMAP2,
+ * or passes along the return value of clk_set_rate().
+ */
+static int __init _omap2_init_reprogram_sdrc(void)
+{
+ struct clk *dpll3_m2_ck;
+ int v = -EINVAL;
+ long rate;
+
+ if (!cpu_is_omap34xx())
+ return 0;
+
+ dpll3_m2_ck = clk_get(NULL, dpll3_m2_ck);
+ if (!dpll3_m2_ck)
+ return -EINVAL;
+
+ rate = clk_get_rate(dpll3_m2_ck);
+ pr_info(Reprogramming SDRC clock to %ld Hz\n, rate);
+ v = clk_set_rate(dpll3_m2_ck, rate);
+ if (v)
+ pr_err(dpll3_m2_clk rate change failed: %d\n, v);
+
+ clk_put(dpll3_m2_ck);
+
+ return v;
+}
+
void __init omap2_init_common_hw(struct omap_sdrc_params *sp)
{
omap2_mux_init();
@@ -202,5 +237,8 @@ void __init omap2_init_common_hw(struct omap_sdrc_params
*sp)
clkdm_init(clockdomains_omap, clkdm_pwrdm_autodeps);
omap2_clk_init();
omap2_sdrc_init(sp);
+
+ _omap2_init_reprogram_sdrc();
+
gpmc_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 03/10] OMAP3 clock: add a short delay when lowering CORE clk rate
When changing the SDRAM clock from 166MHz to 83MHz via the CORE DPLL M2
divider, add a short delay before returning to SDRAM to allow the SDRC
time to stabilize. Without this delay, the system is prone to random
panics upon re-entering SDRAM.
This time delay varies based on MPU frequency. At 500MHz MPU frequency at
room temperature, 64 loops seems to work okay; so add another 32 loops for
environmental and process variation.
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/clock34xx.c| 30 --
arch/arm/mach-omap2/sram34xx.S | 20 +---
arch/arm/plat-omap/include/mach/sram.h |4 ++--
arch/arm/plat-omap/sram.c |8 +---
4 files changed, 44 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
index a62e326..29d0f07 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -283,6 +283,20 @@ static struct omap_clk omap34xx_clks[] = {
#define MIN_SDRC_DLL_LOCK_FREQ 8300
+#define CYCLES_PER_MHZ 100
+
+/* Scale factor for fixed-point arith in omap3_core_dpll_m2_set_rate() */
+#define SDRC_MPURATE_SCALE 8
+
+/* 2^SDRC_MPURATE_BASE_SHIFT: MPU MHz that SDRC_MPURATE_LOOPS is defined for */
+#define SDRC_MPURATE_BASE_SHIFT9
+
+/*
+ * SDRC_MPURATE_LOOPS: Number of MPU loops to execute at
+ * 2^MPURATE_BASE_SHIFT MHz for SDRC to stabilize
+ */
+#define SDRC_MPURATE_LOOPS 96
+
/**
* omap3_dpll_recalc - recalculate DPLL rate
* @clk: DPLL struct clk
@@ -706,7 +720,8 @@ static int omap3_core_dpll_m2_set_rate(struct clk *clk,
unsigned long rate)
{
u32 new_div = 0;
u32 unlock_dll = 0;
- unsigned long validrate, sdrcrate;
+ u32 c;
+ unsigned long validrate, sdrcrate, mpurate;
struct omap_sdrc_params *sp;
if (!clk || !rate)
@@ -734,6 +749,17 @@ static int omap3_core_dpll_m2_set_rate(struct clk *clk,
unsigned long rate)
unlock_dll = 1;
}
+ /*
+* XXX This only needs to be done when the CPU frequency changes
+*/
+ mpurate = arm_fck.rate / CYCLES_PER_MHZ;
+ c = (mpurate SDRC_MPURATE_SCALE) SDRC_MPURATE_BASE_SHIFT;
+ c += 1; /* for safety */
+ c *= SDRC_MPURATE_LOOPS;
+ c = SDRC_MPURATE_SCALE;
+ if (c == 0)
+ c = 1;
+
pr_debug(clock: changing CORE DPLL rate from %lu to %lu\n, clk-rate,
validrate);
pr_debug(clock: SDRC timing params used: %08x %08x %08x\n,
@@ -744,7 +770,7 @@ static int omap3_core_dpll_m2_set_rate(struct clk *clk,
unsigned long rate)
/* REVISIT: Add SDRC_MR changing to this code also */
omap3_configure_core_dpll(sp-rfr_ctrl, sp-actim_ctrla,
- sp-actim_ctrlb, new_div, unlock_dll);
+ sp-actim_ctrlb, new_div, unlock_dll, c);
return 0;
}
diff --git a/arch/arm/mach-omap2/sram34xx.S b/arch/arm/mach-omap2/sram34xx.S
index 84781a6..8d4a88c 100644
--- a/arch/arm/mach-omap2/sram34xx.S
+++ b/arch/arm/mach-omap2/sram34xx.S
@@ -42,10 +42,14 @@
* r0 = sdrc_rfr_ctrl r1 = sdrc_actim_ctrla r2 = sdrc_actim_ctrlb r3 = M2
* r4 = Unlock SDRC DLL? (1 = yes, 0 = no) -- only unlock DLL for
* SDRC rates 83MHz
+ * r5 = number of MPU cycles to wait for SDRC to stabilize after
+ * reprogramming the SDRC when switching to a slower MPU speed
+ *
*/
ENTRY(omap3_sram_configure_core_dpll)
stmfd sp!, {r1-r12, lr} @ store regs to stack
ldr r4, [sp, #52] @ pull extra args off the stack
+ ldr r5, [sp, #56] @ load extra args from the stack
dsb @ flush buffered writes to interconnect
cmp r3, #0x2
blneconfigure_sdrc
@@ -59,7 +63,11 @@ ENTRY(omap3_sram_configure_core_dpll)
bleqwait_dll_unlock
blnewait_dll_lock
cmp r3, #0x1
- blneconfigure_sdrc
+ beq return_to_sdram
+ bl configure_sdrc
+ mov r12, r5 @ if slowing, wait for SDRC to stabilize
+ bl wait_clk_stable
+return_to_sdram:
isb @ prevent speculative exec past here
mov r0, #0 @ return value
ldmfd sp!, {r1-r12, pc} @ restore regs and return
@@ -106,16 +114,6 @@ configure_core_dpll:
wait_clk_stable:
subsr12, r12, #1
bne wait_clk_stable
- nop
- nop
- nop
- nop
- nop
- nop
- nop
- nop
- nop
- nop
bx lr
enable_sdrc:
ldr r11, omap3_cm_iclken1_core
diff --git a/arch/arm/plat-omap/include/mach/sram.h
b/arch/arm/plat-omap/include/mach/sram.h
index dca7c16..c32fa0a 100644
--- a/arch/arm/plat-omap/include/mach/sram.h
+++
[PATCH 08/10] OMAP3 SDRC: set FIXEDDELAY when disabling SDRC DLL
Correspondence with the TI OMAP hardware team indicates that SDRC_DLLA_CTRL.FIXEDDELAY should be initialized to 0x0f. This number was apparently derived from process validation. This is only used when the SDRC DLL is unlocked (e.g., SDRC clock frequency less than 83MHz). Signed-off-by: Paul Walmsley p...@pwsan.com --- arch/arm/mach-omap2/sram34xx.S | 12 1 files changed, 12 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/sram34xx.S b/arch/arm/mach-omap2/sram34xx.S index 487fa86..f41f8d9 100644 --- a/arch/arm/mach-omap2/sram34xx.S +++ b/arch/arm/mach-omap2/sram34xx.S @@ -41,8 +41,18 @@ #define SDRC_UNLOCK_DLL0x1 /* SDRC_DLLA_CTRL bit settings */ +#define FIXEDDELAY_SHIFT 24 +#define FIXEDDELAY_MASK(0xff FIXEDDELAY_SHIFT) #define DLLIDLE_MASK 0x4 +/* + * SDRC_DLLA_CTRL default values: TI hardware team indicates that + * FIXEDDELAY should be initialized to 0xf. This apparently was + * empirically determined during process testing, so no derivation + * was provided. + */ +#define FIXEDDELAY_DEFAULT (0x0f FIXEDDELAY_SHIFT) + /* SDRC_DLLA_STATUS bit settings */ #define LOCKSTATUS_MASK0x4 @@ -103,6 +113,8 @@ return_to_sdram: unlock_dll: ldr r11, omap3_sdrc_dlla_ctrl ldr r12, [r11] + and r12, r12, #FIXEDDELAY_MASK + orr r12, r12, #FIXEDDELAY_DEFAULT orr r12, r12, #DLLIDLE_MASK str r12, [r11] @ (no OCP barrier needed) bx lr -- To unsubscribe from this list: send the line unsubscribe 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 07/10] OMAP3: Add support for DPLL3 divisor values higher than 2
From: Tero Kristo tero.kri...@nokia.com Previously only 1 and 2 was supported. This is needed for DVFS VDD2 control. Signed-off-by: Tero Kristo tero.kri...@nokia.com --- arch/arm/mach-omap2/clock34xx.c|9 +++-- arch/arm/mach-omap2/sram34xx.S |8 +--- arch/arm/plat-omap/include/mach/sram.h |6 -- arch/arm/plat-omap/sram.c |6 +++--- 4 files changed, 15 insertions(+), 14 deletions(-) diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c index 5d57047..718a557 100644 --- a/arch/arm/mach-omap2/clock34xx.c +++ b/arch/arm/mach-omap2/clock34xx.c @@ -736,9 +736,9 @@ static int omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned long rate) sdrcrate = sdrc_ick.rate; if (rate clk-rate) - sdrcrate = ((rate / clk-rate) - 1); + sdrcrate = ((rate / clk-rate) 1); else - sdrcrate = ((clk-rate / rate) - 1); + sdrcrate = ((clk-rate / rate) 1); sp = omap2_sdrc_get_params(sdrcrate); if (!sp) @@ -765,12 +765,9 @@ static int omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned long rate) pr_debug(clock: SDRC timing params used: %08x %08x %08x\n, sp-rfr_ctrl, sp-actim_ctrla, sp-actim_ctrlb); - /* REVISIT: SRAM code doesn't support other M2 divisors yet */ - WARN_ON(new_div != 1 new_div != 2); - omap3_configure_core_dpll(sp-rfr_ctrl, sp-actim_ctrla, sp-actim_ctrlb, new_div, unlock_dll, c, - sp-mr); + sp-mr, rate clk-rate); return 0; } diff --git a/arch/arm/mach-omap2/sram34xx.S b/arch/arm/mach-omap2/sram34xx.S index 16eb4ef..487fa86 100644 --- a/arch/arm/mach-omap2/sram34xx.S +++ b/arch/arm/mach-omap2/sram34xx.S @@ -70,6 +70,7 @@ * r5 = number of MPU cycles to wait for SDRC to stabilize after * reprogramming the SDRC when switching to a slower MPU speed * r6 = new SDRC_MR_0 register value + * r7 = increasing SDRC rate? (1 = yes, 0 = no) * */ ENTRY(omap3_sram_configure_core_dpll) @@ -77,9 +78,10 @@ ENTRY(omap3_sram_configure_core_dpll) ldr r4, [sp, #52] @ pull extra args off the stack ldr r5, [sp, #56] @ load extra args from the stack ldr r6, [sp, #60] @ load extra args from the stack + ldr r7, [sp, #64] @ load extra args from the stack dsb @ flush buffered writes to interconnect - cmp r3, #0x2@ if increasing SDRC clk rate, - blneconfigure_sdrc @ program the SDRC regs early (for RFR) + cmp r7, #1 @ if increasing SDRC clk rate, + bleqconfigure_sdrc @ program the SDRC regs early (for RFR) cmp r4, #SDRC_UNLOCK_DLL@ set the intended DLL state blequnlock_dll blnelock_dll @@ -89,7 +91,7 @@ ENTRY(omap3_sram_configure_core_dpll) cmp r4, #SDRC_UNLOCK_DLL@ wait for DLL status to change bleqwait_dll_unlock blnewait_dll_lock - cmp r3, #0x1@ if increasing SDRC clk rate, + cmp r7, #1 @ if increasing SDRC clk rate, beq return_to_sdram @ return to SDRAM code, otherwise, bl configure_sdrc @ reprogram SDRC regs now mov r12, r5 diff --git a/arch/arm/plat-omap/include/mach/sram.h b/arch/arm/plat-omap/include/mach/sram.h index 4f87056..4d53cc5 100644 --- a/arch/arm/plat-omap/include/mach/sram.h +++ b/arch/arm/plat-omap/include/mach/sram.h @@ -24,7 +24,8 @@ extern u32 omap2_set_prcm(u32 dpll_ctrl_val, u32 sdrc_rfr_val, int bypass); extern u32 omap3_configure_core_dpll(u32 sdrc_rfr_ctrl, u32 sdrc_actim_ctrla, u32 sdrc_actim_ctrlb, u32 m2, -u32 unlock_dll, u32 f, u32 sdrc_mr); +u32 unlock_dll, u32 f, u32 sdrc_mr, +u32 inc); /* Do not use these */ extern void omap1_sram_reprogram_clock(u32 ckctl, u32 dpllctl); @@ -62,7 +63,8 @@ extern unsigned long omap243x_sram_reprogram_sdrc_sz; extern u32 omap3_sram_configure_core_dpll(u32 sdrc_rfr_ctrl, u32 sdrc_actim_ctrla, u32 sdrc_actim_ctrlb, u32 m2, - u32 unlock_dll, u32 f, u32 sdrc_mr); + u32 unlock_dll, u32 f, u32 sdrc_mr, + u32 inc); extern unsigned long omap3_sram_configure_core_dpll_sz; #endif diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c index 81048b3..8ee6cc9 100644 --- a/arch/arm/plat-omap/sram.c +++ b/arch/arm/plat-omap/sram.c @@ -366,10
[PATCH 09/10] OMAP3 clock: GPIO de-bounce clocks don't affect module idle state
GPIO de-bounce clocks don't have any impact on the module idle state, so
the clock code should not wait for the module to enable after the de-bounce
clocks are enabled.
Problem found by Kevin Hilman khil...@deeprootsystems.com.
Signed-off-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/clock34xx.h | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h
index 6763b8f..017a30e 100644
--- a/arch/arm/mach-omap2/clock34xx.h
+++ b/arch/arm/mach-omap2/clock34xx.h
@@ -2182,7 +2182,7 @@ static struct clk wkup_32k_fck = {
static struct clk gpio1_dbck = {
.name = gpio1_dbck,
- .ops= clkops_omap2_dflt_wait,
+ .ops= clkops_omap2_dflt,
.parent = wkup_32k_fck,
.enable_reg = OMAP_CM_REGADDR(WKUP_MOD, CM_FCLKEN),
.enable_bit = OMAP3430_EN_GPIO1_SHIFT,
@@ -2427,7 +2427,7 @@ static struct clk per_32k_alwon_fck = {
static struct clk gpio6_dbck = {
.name = gpio6_dbck,
- .ops= clkops_omap2_dflt_wait,
+ .ops= clkops_omap2_dflt,
.parent = per_32k_alwon_fck,
.enable_reg = OMAP_CM_REGADDR(OMAP3430_PER_MOD, CM_FCLKEN),
.enable_bit = OMAP3430_EN_GPIO6_SHIFT,
@@ -2437,7 +2437,7 @@ static struct clk gpio6_dbck = {
static struct clk gpio5_dbck = {
.name = gpio5_dbck,
- .ops= clkops_omap2_dflt_wait,
+ .ops= clkops_omap2_dflt,
.parent = per_32k_alwon_fck,
.enable_reg = OMAP_CM_REGADDR(OMAP3430_PER_MOD, CM_FCLKEN),
.enable_bit = OMAP3430_EN_GPIO5_SHIFT,
@@ -2447,7 +2447,7 @@ static struct clk gpio5_dbck = {
static struct clk gpio4_dbck = {
.name = gpio4_dbck,
- .ops= clkops_omap2_dflt_wait,
+ .ops= clkops_omap2_dflt,
.parent = per_32k_alwon_fck,
.enable_reg = OMAP_CM_REGADDR(OMAP3430_PER_MOD, CM_FCLKEN),
.enable_bit = OMAP3430_EN_GPIO4_SHIFT,
@@ -2457,7 +2457,7 @@ static struct clk gpio4_dbck = {
static struct clk gpio3_dbck = {
.name = gpio3_dbck,
- .ops= clkops_omap2_dflt_wait,
+ .ops= clkops_omap2_dflt,
.parent = per_32k_alwon_fck,
.enable_reg = OMAP_CM_REGADDR(OMAP3430_PER_MOD, CM_FCLKEN),
.enable_bit = OMAP3430_EN_GPIO3_SHIFT,
@@ -2467,7 +2467,7 @@ static struct clk gpio3_dbck = {
static struct clk gpio2_dbck = {
.name = gpio2_dbck,
- .ops= clkops_omap2_dflt_wait,
+ .ops= clkops_omap2_dflt,
.parent = per_32k_alwon_fck,
.enable_reg = OMAP_CM_REGADDR(OMAP3430_PER_MOD, CM_FCLKEN),
.enable_bit = OMAP3430_EN_GPIO2_SHIFT,
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/10] OMAP3 SRAM: convert SRAM code to use macros rather than magic numbers
Convert omap3_sram_configure_core_dpll() to use macros rather than magic numbers. Signed-off-by: Paul Walmsley p...@pwsan.com --- arch/arm/mach-omap2/sram34xx.S | 53 +--- 1 files changed, 38 insertions(+), 15 deletions(-) diff --git a/arch/arm/mach-omap2/sram34xx.S b/arch/arm/mach-omap2/sram34xx.S index 37a1e1f..16eb4ef 100644 --- a/arch/arm/mach-omap2/sram34xx.S +++ b/arch/arm/mach-omap2/sram34xx.S @@ -36,6 +36,29 @@ .text +/* r4 parameters */ +#define SDRC_NO_UNLOCK_DLL 0x0 +#define SDRC_UNLOCK_DLL0x1 + +/* SDRC_DLLA_CTRL bit settings */ +#define DLLIDLE_MASK 0x4 + +/* SDRC_DLLA_STATUS bit settings */ +#define LOCKSTATUS_MASK0x4 + +/* SDRC_POWER bit settings */ +#define SRFRONIDLEREQ_MASK 0x40 +#define PWDENA_MASK0x4 + +/* CM_IDLEST1_CORE bit settings */ +#define ST_SDRC_MASK 0x2 + +/* CM_ICLKEN1_CORE bit settings */ +#define EN_SDRC_MASK 0x2 + +/* CM_CLKSEL1_PLL bit settings */ +#define CORE_DPLL_CLKOUT_DIV_SHIFT 0x1b + /* * omap3_sram_configure_core_dpll - change DPLL3 M2 divider * r0 = new SDRC_RFR_CTRL register contents @@ -57,13 +80,13 @@ ENTRY(omap3_sram_configure_core_dpll) dsb @ flush buffered writes to interconnect cmp r3, #0x2@ if increasing SDRC clk rate, blneconfigure_sdrc @ program the SDRC regs early (for RFR) - cmp r4, #0x1@ set the intended DLL state + cmp r4, #SDRC_UNLOCK_DLL@ set the intended DLL state blequnlock_dll blnelock_dll bl sdram_in_selfrefresh@ put SDRAM in self refresh, idle SDRC bl configure_core_dpll @ change the DPLL3 M2 divider bl enable_sdrc @ take SDRC out of idle - cmp r4, #0x1@ wait for DLL status to change + cmp r4, #SDRC_UNLOCK_DLL@ wait for DLL status to change bleqwait_dll_unlock blnewait_dll_lock cmp r3, #0x1@ if increasing SDRC clk rate, @@ -78,33 +101,33 @@ return_to_sdram: unlock_dll: ldr r11, omap3_sdrc_dlla_ctrl ldr r12, [r11] - orr r12, r12, #0x4 + orr r12, r12, #DLLIDLE_MASK str r12, [r11] @ (no OCP barrier needed) bx lr lock_dll: ldr r11, omap3_sdrc_dlla_ctrl ldr r12, [r11] - bic r12, r12, #0x4 + bic r12, r12, #DLLIDLE_MASK str r12, [r11] @ (no OCP barrier needed) bx lr sdram_in_selfrefresh: ldr r11, omap3_sdrc_power @ read the SDRC_POWER register ldr r12, [r11] @ read the contents of SDRC_POWER mov r9, r12 @ keep a copy of SDRC_POWER bits - orr r12, r12, #0x40 @ enable self refresh on idle req - bic r12, r12, #0x4 @ clear PWDENA + orr r12, r12, #SRFRONIDLEREQ_MASK @ enable self refresh on idle + bic r12, r12, #PWDENA_MASK @ clear PWDENA str r12, [r11] @ write back to SDRC_POWER register ldr r12, [r11] @ posted-write barrier for SDRC idle_sdrc: ldr r11, omap3_cm_iclken1_core @ read the CM_ICLKEN1_CORE reg ldr r12, [r11] - bic r12, r12, #0x2 @ disable iclk bit for SDRC + bic r12, r12, #EN_SDRC_MASK @ disable iclk bit for SDRC str r12, [r11] wait_sdrc_idle: ldr r11, omap3_cm_idlest1_core ldr r12, [r11] - and r12, r12, #0x2 @ check for SDRC idle - cmp r12, #2 + and r12, r12, #ST_SDRC_MASK @ check for SDRC idle + cmp r12, #ST_SDRC_MASK bne wait_sdrc_idle bx lr configure_core_dpll: @@ -112,7 +135,7 @@ configure_core_dpll: ldr r12, [r11] ldr r10, core_m2_mask_val @ modify m2 for core dpll and r12, r12, r10 - orr r12, r12, r3, lsl #0x1B @ r3 contains the M2 val + orr r12, r12, r3, lsl #CORE_DPLL_CLKOUT_DIV_SHIFT str r12, [r11] ldr r12, [r11] @ posted-write barrier for CM bx lr @@ -123,12 +146,12 @@ wait_clk_stable: enable_sdrc: ldr r11, omap3_cm_iclken1_core ldr r12, [r11] - orr r12, r12, #0x2 @ enable iclk bit for SDRC + orr r12, r12, #EN_SDRC_MASK @ enable iclk bit for SDRC str r12, [r11] wait_sdrc_idle1: ldr r11, omap3_cm_idlest1_core ldr r12, [r11] - and r12, r12, #0x2 + and r12, r12, #ST_SDRC_MASK cmp r12, #0 bne wait_sdrc_idle1 restore_sdrc_power_val: @@ -138,14 +161,14 @@
Please advise on choosing the right backlight switching framework
Hi, I'd like to add support for lcd backlight on/off switching on omap1 ams-delta board. I could potentially use omap1_bl backlight class device driver for this purpose, but it is not fully compatible with ams-delta, as it actually changes lcd contrast instead of backlight intensity on this board. I can see two possible ways of controlling backlight on omap platforms: 1. over omapfb panel device driver, with lcd_panel.set_bklight_level(), 2. over backlight class device driver, using backlight_ops.update_status(). Which method is the preferred one, giving more chances for integration into the mainline kernel? Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-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 00/13] OMAP2/3: PM sync-up
* Kevin Hilman khil...@deeprootsystems.com [090520 16:20]: This series is intended to push the core PM support from linux-omap into mainline. Upon review/acceptance, Tony will merge into his for-next branch for the next merge window so all OMAP stuff can come from one place. In addition to the linux-omap PM core sync, several OMAP3 init fixes are required to ensure that the chip can hit full-chip retention on idle and suspend. Currently based on Tony's omap3-upstream branch. Compile tested on OMAP2, Boot tested on OMAP3430SDP and can hit full-chip retention in suspend and in idle. I've pulled these to omap for-next branch. Tony Changes since v1: - updated push core PM patch with review comments - dropped all /sys/power/* knobs - will use hlt_counter when it's exported to platform code - dropped save/restore of abort mode regs in favor of cpu_init() - MUSB idle patch fixed to work even when MUSB not enabled in Kconfig - 2 new patches - added UART-specific timeout feature under uart platform device. this replaces the need for /sys/power/clocks_off_while_idle - revert of irq_chip-disable patch which is the wrong solution for the bug it was trying to fix Jouni Hogander (2): OMAP: Add new function to check wether there is irq pending OMAP: UART: Add sysfs interface for adjusting UART sleep timeout Kevin Hilman (10): Revert ARM: OMAP: Mask interrupts when disabling interrupts, v2 OMAP2/3: PM: push core PM code from linux-omap OMAP3: PM: Force IVA2 into idle during bootup OMAP3: PM: Add wake-up bit defintiions for CONTROL_PADCONF_X OMAP3: PM: UART: disable clocks when idle and off-mode support OMAP3: PM: Add D2D clocks and auto-idle setup to PRCM init OMAP3: PM: D2D clockdomain supports SW supervised transitions OMAP3: PM: Ensure PRCM interrupts are cleared at boot OMAP3: PM: Clear pending PRCM reset flags on init OMAP3: PM: prevent module wakeups from waking IVA2 Peter 'p2' De Schrijver (1): OMAP3: PM: Ensure MUSB block can idle when driver not loaded arch/arm/mach-omap2/Makefile |5 +- arch/arm/mach-omap2/clock34xx.c |3 + arch/arm/mach-omap2/clock34xx.h | 33 ++- arch/arm/mach-omap2/clockdomains.h|2 +- arch/arm/mach-omap2/cm-regbits-34xx.h | 14 + arch/arm/mach-omap2/irq.c | 18 +- arch/arm/mach-omap2/pm-debug.c| 152 ++ arch/arm/mach-omap2/pm.c | 134 +++ arch/arm/mach-omap2/pm.h | 40 ++ arch/arm/mach-omap2/pm24xx.c | 549 ++ arch/arm/mach-omap2/pm34xx.c | 710 + arch/arm/mach-omap2/prcm-common.h |2 + arch/arm/mach-omap2/prm.h |2 + arch/arm/mach-omap2/sdrc.c|5 +- arch/arm/mach-omap2/serial.c | 437 +- arch/arm/mach-omap2/sleep24xx.S |1 - arch/arm/mach-omap2/sleep34xx.S | 436 ++ arch/arm/mach-omap2/usb-musb.c| 21 +- arch/arm/plat-omap/Kconfig|2 +- arch/arm/plat-omap/common.c |1 - arch/arm/plat-omap/include/mach/common.h |2 - arch/arm/plat-omap/include/mach/control.h | 13 + arch/arm/plat-omap/include/mach/irqs.h|1 + arch/arm/plat-omap/include/mach/pm.h | 345 -- arch/arm/plat-omap/include/mach/serial.h |9 + arch/arm/plat-omap/include/mach/usb.h |6 - drivers/mtd/onenand/omap2.c |1 - 27 files changed, 2475 insertions(+), 469 deletions(-) create mode 100644 arch/arm/mach-omap2/pm-debug.c create mode 100644 arch/arm/mach-omap2/pm.h create mode 100644 arch/arm/mach-omap2/pm24xx.c create mode 100644 arch/arm/mach-omap2/pm34xx.c create mode 100644 arch/arm/mach-omap2/sleep34xx.S delete mode 100644 arch/arm/plat-omap/include/mach/pm.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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/10] Omap updates for merge window after 2.6.30
* Tony Lindgren t...@atomide.com [090519 16:31]: Hi all, This series contains omap updates for review. There will be one more series after this for omap3 specific patches. I've merged these into omap for-next branch. Regards, Tony --- Eero Nurkkala (1): ARM: OMAP: McBSP: Fix legacy interrupts to clear their status Imre Deak (1): ARM: OMAP2: 2430SDP: Add FB support to board file Jarkko Nikula (1): ARM: OMAP: Update contact address of I2C registration helper Juha Yrjola (1): ARM: OMAP2/3: Add generic onenand support when connected to GPMC Mans Rullgard (1): ARM: OMAP: Increase VMALLOC_END to allow 256MB RAM Santosh Shilimkar (1): ARM: OMAP2/3: sDMA: Correct omap_request_dma_chain() Tomi Valkeinen (1): ARM: OMAP2/3: DMA: implement trans copy and const fill Tony Lindgren (3): ARM: OMAP2/3: Add generic smc91x support when connected to GPMC ARM: OMAP1: Make 770 LCD work ARM: OMAP1: Misc clean-up arch/arm/configs/rx51_defconfig |2 arch/arm/mach-omap1/Kconfig |1 arch/arm/mach-omap1/Makefile |4 arch/arm/mach-omap1/board-nokia770.c | 17 + arch/arm/mach-omap2/Makefile |6 arch/arm/mach-omap2/board-2430sdp.c | 112 ++-- arch/arm/mach-omap2/board-3430sdp.c | 78 ++ arch/arm/mach-omap2/board-rx51-peripherals.c | 192 ++ arch/arm/mach-omap2/gpmc-onenand.c| 340 + arch/arm/mach-omap2/gpmc-smc91x.c | 189 ++ arch/arm/plat-omap/dma.c | 79 -- arch/arm/plat-omap/i2c.c |2 arch/arm/plat-omap/include/mach/dma.h |3 arch/arm/plat-omap/include/mach/gpmc-smc91x.h | 46 +++ arch/arm/plat-omap/include/mach/hwa742.h |5 arch/arm/plat-omap/include/mach/onenand.h | 29 ++ arch/arm/plat-omap/include/mach/vmalloc.h |2 arch/arm/plat-omap/mcbsp.c| 30 ++ arch/arm/plat-omap/sram.c |4 drivers/video/omap/hwa742.c | 26 +- 20 files changed, 851 insertions(+), 316 deletions(-) create mode 100644 arch/arm/mach-omap2/gpmc-onenand.c create mode 100644 arch/arm/mach-omap2/gpmc-smc91x.c create mode 100644 arch/arm/plat-omap/include/mach/gpmc-smc91x.h -- Signature -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] Updates for omap3 for merge window after 2.6.30
* Tony Lindgren t...@atomide.com [090522 15:37]: Hi all, Here are mostly omap3 specific updates for the coming merge window for review. Still to come few more boards and regulator framework changes for omap3 in one more series. I've merged these into omap for-next branch. Regards, Tony --- Imre Deak (1): ARM: OMAP3: ZOOM MDK: Add FB support to board file Paul Walmsley (2): ARM: OMAP3: SDRC: add timing data for Qimonda HYB18M512160AF-6 ARM: OMAP3: SDRC: add timing data for Micron MT46H32M32LF-6 Tony Lindgren (2): ARM: OMAP3: Initialize more devices for LDP ARM: OMAP2/3: Remove L4_WK_OMAP_BASE, L4_PER_OMAP_BASE, L4_EMU_BASE, L3_OMAP_BASE Vikram Pandita (1): ARM: OMAP2/3: Serial: Remove arch_initcall dependency arch/arm/mach-omap2/board-3430sdp.c|3 arch/arm/mach-omap2/board-ldp.c| 219 arch/arm/mach-omap2/board-omap3beagle.c|4 arch/arm/mach-omap2/board-omap3pandora.c |3 arch/arm/mach-omap2/board-overo.c |3 arch/arm/mach-omap2/sdram-micron-mt46h32m32lf-6.h | 69 ++ .../mach-omap2/sdram-qimonda-hyb18m512160af-6.h| 54 + arch/arm/mach-omap2/serial.c | 22 +- arch/arm/plat-omap/include/mach/keypad.h |4 arch/arm/plat-omap/include/mach/omap34xx.h |4 10 files changed, 361 insertions(+), 24 deletions(-) create mode 100644 arch/arm/mach-omap2/sdram-micron-mt46h32m32lf-6.h create mode 100644 arch/arm/mach-omap2/sdram-qimonda-hyb18m512160af-6.h -- Signature -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Please help in adding ams-delta support to ASoC
On Tuesday 26 May 2009 16:17:23 ext Janusz Krzysztofik wrote: Hi, I am trying to add sound support for ams-delta omap machine, yet without much success. Three years ago, Mark Underwood created an omap-alsa compatible driver that basically worked[1]. It was derieved from similiar driver for aic23 codec found on omap osk machine. It looks like Mark has never managed to finish his work. It's not clear for me if he has found that getting a working fullduplex sound is technically impossible on a voice modem codec, shared among modem and cpu, controlable only from modem side afaik, but I have decided to give it a try. Since Mark's initial work, omap-alsa framework has been depreciated in favour of soc-omap. API changes are so significant that Mark's code is rather not useable directly any more. However, I am trying to use it as a starting point, by comparing it against it's prototype osk/aic23 code. Following Mark, I am trying to derieve the new ams-delta sound driver from current asoc driver for omap osk9512. For codec part, I decided to base my work on much more simple ad73311 rather that tlv320aic23. Comparing Mark's code agaist it's osk/aic23 prototype, I can see the folowing significant changes: 1. rate tables/bitmaps found in hw_constraint_rates, snd_omap_alsa_playback and snd_omap_alsa_capture structures limited to 8kHz, 2. hardware related code found in codec_configure_dev(), codec_clock_on() and codec_clock_off() callback functions replaced with ams-delta hardware specific code that switches the codec DAI pins from modem chip to mcbsp cpu interface and back, 3. codec_set_samplerate() and all mixer related functions replaced with stubs. 4. the following McBSP register settings changes: - .xcr2 = XPHASE | XFRLEN2(OMAP_MCBSP_WORD_8) | - XWDLEN2(OMAP_MCBSP_WORD_16) | XDATDLY(0) | XFIG, + .xcr2 = XPHASE | XWDLEN2(OMAP_MCBSP_WORD_16) | XFRLEN2(0), - .srgr1 = FWID(DEFAULT_BITPERSAMPLE - 1), + .srgr1 = CLKGDV(0), - .srgr2 = GSYNC | CLKSP | FSGM | FPER(DEFAULT_BITPERSAMPLE * 2 - 1), + .srgr2 = GSYNC, - .pcr0 = CLKXP | CLKRP, /* mcbsp: slave */ Since I don't have the original osk/aic23 thing, this does not mean to much... Just a bit confusing. The configuration suggest slave McBSP with NB_IF polarity, dual phase format, 16 bit words, 16*2 long frames, the FS pulse is probably a pulse... Suggesting kind of DSP mode, but with not so correct configuration, which happens to be working. I have found points 1. to 3. rather trivial to implement in new framework. Regarding point 4., it looks like detailed register settings are now done inside omap-mcbsp.c, based on machine specified format, so I have to find out what format should be specified for ams-delta. Please correct me if I am missing something. Yes, that is correct. What you need for the point 4: Interface format of the cx20442 codec (I2S, DSP_A, DSP_B, etc) Clock polarities. Does the codec provides the clocks (bit, frame sync) - codec master or slave When you know these the soc/omap/arms-delta.c can configure the CPU dai with: snd_soc_dai_set_fmt(cpu_dai, ... There was one more modification in Mark's code, addressing dma chaining problem on omap15xx hardware, but as far as I could see, the problem was already solved in the asoc omap framework. Initially, I based my work on ompenembedded provided linux-omap.git revision 90e758af52ba803cba233fabee81176d99589f09. The results were rather poor - total system hangup after first device access, with no single message. So I have switched to linux-2.6.30-rc5 and now I can safely access the device, however it does not work as expected. aplay and arecord wait forever, cat to/from /dev/dsp breaks with hardware error messgae. DMA interrput counters stay at 0. This means that the McBSP module is not transmitting/receiving any data. Which suggests that the clocking is not working in your setup. Check the slave master mode for the codec. Also worth checking the PIN configuration for the McBSP1 module, just in case it is correct. However, codec switching that I do from machine-ops-startup/shutdown seems working, as modem stops producing any sounds while the alsa device is in use and gets back thereafter. First of all, I'd like to make sure if my problem is related to my code only. As I am new in these areas, I would like to ask you if the omap asoc framework is stable enough to relay on. I believe that it is stable enough. If yes, could you please look at my dirty code (attached) an give me some hints? I can provide you with more information if necessary. Given that it is still early morning, I could not find anything that would prevent it to be somehow working... Regards, Janusz -- 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
