RE: [PATCH 1/2] OMAP3: PM: Configure PRM setup times from board files
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Thursday, October 01, 2009 12:44 AM
To: Nayak, Rajendra
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH 1/2] OMAP3: PM: Configure PRM setup times
from board files
Rajendra Nayak rna...@ti.com writes:
The setup times to be programmed in the PRM module on OMAP
(for clksetup, voltsetup etc) are board specific.
They depend heavily on the PMIC used and even on different boards
with the same PMIC, they vary based on the sleep/wake
sequence used, system clock speed et al.
This patch makes it possible for these setup values to be
configured from different board files.
Signed-off-by: Rajendra Nayak rna...@ti.com
Hi Rajendra,
Sorry about this, but your series slipped through cracks on my side.
I like this approach, but it needs to be rebased against current PM
branch since lots of the code that it touches has been reworked.
Also, instead of continuing to overload init_common_hw, how about
adding something like omap_pm_register() which takes the various rate
tables and setup times, or possibly adding the rate tables and setup
times as arguments to omap3_pm_earlly_init() and making it explicitly
called by board code instead of an arch_initcall().
Hi Kevin,
Yes, I will rework this patch and repost in a couple days.
regards,
Rajendra
Kevin
---
arch/arm/mach-omap2/board-3430sdp.c | 20 +++-
arch/arm/mach-omap2/board-apollon.c |2 +-
arch/arm/mach-omap2/board-generic.c |2 +-
arch/arm/mach-omap2/board-h4.c |2 +-
arch/arm/mach-omap2/board-ldp.c |2 +-
arch/arm/mach-omap2/board-omap3beagle.c |2 +-
arch/arm/mach-omap2/board-omap3evm.c|2 +-
arch/arm/mach-omap2/board-overo.c |2 +-
arch/arm/mach-omap2/board-rx51.c|2 +-
arch/arm/mach-omap2/board-zoom2.c |2 +-
arch/arm/mach-omap2/io.c|5 -
arch/arm/mach-omap2/pm.c|7 +++
arch/arm/mach-omap2/pm.h| 16 +---
arch/arm/mach-omap2/pm34xx.c| 10 ++
arch/arm/plat-omap/include/mach/io.h|4 +++-
15 files changed, 61 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index e9a4d10..b43cf94 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -58,6 +58,23 @@
#define TWL4030_MSECURE_GPIO 22
+/* FIXME: These are not the optimal setup values to be used
on 3430sdp*/
+static struct prm_setup_vc omap3_setuptime_table = {
+.clksetup = 0xff,
+.voltsetup_time1 = 0xfff,
+.voltsetup_time2 = 0xfff,
+.voltoffset = 0xff,
+.voltsetup2 = 0xff,
+.vdd0_on = 0x30,
+.vdd0_onlp = 0x20,
+.vdd0_ret = 0x1e,
+.vdd0_off = 0x00,
+.vdd1_on = 0x2c,
+.vdd1_onlp = 0x20,
+.vdd1_ret = 0x1e,
+.vdd1_off = 0x00,
+};
+
static int sdp3430_keymap[] = {
KEY(0, 0, KEY_LEFT),
KEY(0, 1, KEY_RIGHT),
@@ -174,7 +191,8 @@ static struct platform_device
*sdp3430_devices[] __initdata = {
static void __init omap_3430sdp_init_irq(void)
{
omap2_init_common_hw(hyb18m512160af6_sdrc_params,
omap3_mpu_rate_table,
- omap3_dsp_rate_table, omap3_l3_rate_table);
+ omap3_dsp_rate_table, omap3_l3_rate_table,
+ omap3_setuptime_table);
omap_init_irq();
omap_gpio_init();
}
diff --git a/arch/arm/mach-omap2/board-apollon.c
b/arch/arm/mach-omap2/board-apollon.c
index 1a7fb81..293a9b2 100644
--- a/arch/arm/mach-omap2/board-apollon.c
+++ b/arch/arm/mach-omap2/board-apollon.c
@@ -250,7 +250,7 @@ out:
static void __init omap_apollon_init_irq(void)
{
-omap2_init_common_hw(NULL, NULL, NULL, NULL);
+omap2_init_common_hw(NULL, NULL, NULL, NULL, NULL);
omap_init_irq();
omap_gpio_init();
apollon_init_smc91x();
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 23583da..dfc1b49 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -33,7 +33,7 @@
static void __init omap_generic_init_irq(void)
{
-omap2_init_common_hw(NULL, NULL, NULL, NULL);
+omap2_init_common_hw(NULL, NULL, NULL, NULL, NULL);
omap_init_irq();
}
diff --git a/arch/arm/mach-omap2/board-h4.c
b/arch/arm/mach-omap2/board-h4.c
index de6adf7..af0ebaf 100644
--- a/arch/arm/mach-omap2/board-h4.c
+++ b/arch/arm/mach-omap2/board-h4.c
@@ -270,7 +270,7 @@ static void __init h4_init_flash(void)
static void __init omap_h4_init_irq(void)
{
-omap2_init_common_hw(NULL, NULL, NULL, NULL);
+omap2_init_common_hw(NULL, NULL, NULL, NULL, NULL);
omap_init_irq();
omap_gpio_init();
h4_init_flash();
diff --git a/arch/arm/mach-omap2/board-ldp.c
b/arch/arm/mach-omap2/board-ldp.c
[PATCH] OMAP3 : Fix McSPI RX Timeout
McSPI RX timeout issues are reported on some of the OMAP3 custom boards.
After verifying configuration sequence in TRM, there seems to be issue with
McSPI configuration sequence.
The steps to be followed for both TX and RX:
1. Configure OMAP2_MCSPI_CHCONF0 register with required settings such as
TX/RX mode, word length, force chip select(if required).
2. Set MS bit to 0 in OMAP2_MCSPI_CHCTRL0 register to provide the clock.
3. Enable SPI channel in OMAP2_MCSPI_MODULCTRL
But, the sequence used in current code seems to be wrong. Here it is:
1. Set MS bit to 0 in OMAP2_MCSPI_CHCTRL0 register to provide the clock
(This is done during bootup)
2. Enable SPI channel in OMAP2_MCSPI_MODULCTRL
3. Configure OMAP2_MCSPI_CHCONF0 register with required settings such as
TX/RX mode, word length, force chip select(if required).
After correcting configuration sequence, the timeout seems to be not
reproducible anymore.
Signed-off-by: Manjunatha GK manj...@ti.com
---
drivers/spi/omap2_mcspi.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
index ba1a872..846485c 100644
--- a/drivers/spi/omap2_mcspi.c
+++ b/drivers/spi/omap2_mcspi.c
@@ -802,7 +802,6 @@ static void omap2_mcspi_work(struct work_struct *work)
spi = m-spi;
cs = spi-controller_state;
- omap2_mcspi_set_enable(spi, 1);
list_for_each_entry(t, m-transfers, transfer_list) {
if (t-tx_buf == NULL t-rx_buf == NULL t-len) {
status = -EINVAL;
@@ -830,6 +829,9 @@ static void omap2_mcspi_work(struct work_struct *work)
chconf |= OMAP2_MCSPI_CHCONF_TRM_TX_ONLY;
mcspi_write_chconf0(spi, chconf);
+ omap2_mcspi_set_master_mode(mcspi-master);
+
+ omap2_mcspi_set_enable(spi, 1);
if (t-len) {
unsignedcount;
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430
The problem here is not with the restore. If MPU reads the PADCONF_SAVEDONE bit very close to the end of context save sequence for the pad conf registers, the last context is not saved to the scratchpad memory. This is a h/w bug. The workaround proposed is to delay the MPU access of SAVEDONE bit until the last context has been saved. 300 us delay is the current safe delay proposed by TI. I believe investigations are going on to whether this delay can be optimized. Also only the last context (ETK_D14) has the risk of not getting saved. We could add a defconfig option for this workaround and enable it on need basis till TI comes out with proper optimized workaround sequence. Regards Thara -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Menon, Nishanth Sent: Monday, October 05, 2009 10:58 PM To: Kevin Hilman Cc: linux-omap@vger.kernel.org; Gulati, Shweta Subject: Re: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430 Kevin Hilman had written, on 10/05/2009 12:04 PM, the following: y...@india.ti.com writes: From: Shweta Gulati shweta.gul...@ti.com Please add descriptive changelog, including Erratta number and summary of the bug. Signed-off-by: Shweta Gulati shweta.gul...@ti.com --- arch/arm/mach-omap2/pm34xx.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index a9eda25..38f4781 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -140,6 +140,12 @@ static void omap3_core_save_context(void) omap_ctrl_readl(OMAP343X_CONTROL_PADCONF_OFF); control_padconf_off |= START_PADCONF_SAVE; omap_ctrl_writel(control_padconf_off, OMAP343X_CONTROL_PADCONF_OFF); + /* Due to Silicon Bug on context restore it is found + * that the CONTROL_PAD_CONF_ETK14 register is not saved into + * scratch pad memory sometimes. To rectify it delay acess by Mpu + * for 300us for scm to finish saving task + */ + udelay(300); Why 300 usecs? 300uSec could be optimized as I understand. Is ETK14 the only register not saved? The bug as I understand is that the register is saved, but restore potentially can corrupt the values. there is an alternative implementation possible: a) we save the register in a seperate variable b) we allow the restore issue to kick us (essentially allow it to be corrupted) c) we over write the restored value with the saved value. This has the risk of a glitch on the line (between the corrupted restore data to the time we restore with correct data). -- 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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 0/7] TWL6030 audio codec initial support
Following patch series adds initial support for TWL6030 codec driver. Changes from v2: - CODEC now handles scenarios where no platform data is passed - Removed GPIOLIB dependency of codec driver - Removed magic values, register reads instead - Added runtime constraints depending on sysclk - Added more constraints for switching to low-power mode - Use request_threaded_irq instead (oneshot support required) - wait_for_completion with timeout - Changelog now gives a better explanation of features and corresponding changes Thanks, -Misa --- Misael Lopez Cruz (7): OMAP4: PMIC: Add support for twl6030 codec ASoC: TWL6030: Add twl6030 codec driver ASoC: TWL6030: Manual power-up/down sequences ASoC: TWL6030: Add support for low-power PLL ASoC: TWL6030: Add restrictions for low-power playback mode ASoC: TWL6030: Enable audio interrupt ASoC: TWL6030: Detect power-up sequence completion drivers/mfd/twl-core.c | 15 + include/linux/i2c/twl.h|7 + sound/soc/codecs/Kconfig |4 + sound/soc/codecs/Makefile |2 + sound/soc/codecs/twl6030.c | 1242 sound/soc/codecs/twl6030.h | 141 + 6 files changed, 1411 insertions(+), 0 deletions(-) create mode 100644 sound/soc/codecs/twl6030.c create mode 100644 sound/soc/codecs/twl6030.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
[PATCHv3 1/7] OMAP4: PMIC: Add support for twl6030 codec
In order to have TWL6030 CODEC driver as a platform driver, codec data
should be passed through twl_platform_data structure.
For twl6030 audio codec, the following data may be passed:
- audpwron_gpio: gpio line used to power-up/down the codec. A low-to-high
transition powers codec up. Setting audpwron_gpio to a negative value
means that codec will use manual power sequence instead of automatic
sequence
- naudint_irq: irq line for audio interrupt. twl6030 drives NAUDINT line
to low when an interrupt (codec ready, plug insertion/removal, etc) is
detected
However, codec driver can operate if any or none of them are passed.
Signed-off-by: Misael Lopez Cruz x0052...@ti.com
---
drivers/mfd/twl-core.c | 15 +++
include/linux/i2c/twl.h |7 +++
2 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index af4cf47..6432af1 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -108,6 +108,12 @@
#define twl_has_mmc() false
#endif
+#if defined(CONFIG_SND_SOC_TWL6030) || defined(CONFIG_SND_SOC_TWL6030_MODULE)
+#define twl_has_codec()true
+#else
+#define twl_has_codec()false
+#endif
+
#if defined(CONFIG_TWL4030_USB) || defined(CONFIG_TWL4030_USB_MODULE)
#define twl_has_usb() true
#else
@@ -190,6 +196,7 @@
#define BCI_SUB_CHIP_IDSUB_CHIP_ID1
#define GPIO_SUB_CHIP_ID 0 /* NOT SUPPORTED IN TWL6030 */
#define KEYPAD_SUB_CHIP_ID 0 /* ADDED FOR COMPILATION ONLY */
+#define CODEC_SUB_CHIP_ID SUB_CHIP_ID3
/* subchip/slave 0 0x48 - POWER */
#define TWL6030_BASEADD_RTC0x
@@ -632,6 +639,14 @@ add_children(struct twl_platform_data *pdata, unsigned
long features)
if (IS_ERR(child))
return PTR_ERR(child);
}
+
+ if (twl_has_codec()) {
+ child = add_child(CODEC_SUB_CHIP_ID, twl6030_codec,
+ pdata-codec, sizeof(*pdata-codec), false,
+ 0, 0);
+ if (IS_ERR(child))
+ return PTR_ERR(child);
+ }
#endif
if (twl_has_usb() pdata-usb) {
diff --git a/include/linux/i2c/twl.h b/include/linux/i2c/twl.h
index b687a8b..e76ca9b 100644
--- a/include/linux/i2c/twl.h
+++ b/include/linux/i2c/twl.h
@@ -472,6 +472,12 @@ struct twl_usb_data {
enum twl_usb_mode usb_mode;
};
+struct twl_codec_data {
+ /* twl6030 */
+ int audpwron_gpio; /* audio power-on gpio */
+ int naudint_irq;/* audio interrupt */
+};
+
struct twl_platform_data {
unsignedirq_base, irq_end;
struct twl_bci_platform_data*bci;
@@ -479,6 +485,7 @@ struct twl_platform_data {
struct twl_madc_platform_data *madc;
struct twl_keypad_data *keypad;
struct twl_usb_data *usb;
+ struct twl_codec_data *codec;
/* LDO regulators common to TWL4030/TWL6030 */
struct regulator_init_data *vdac;
--
1.5.4.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 2/7] ASoC: TWL6030: Add twl6030 codec driver
Initial version of TWL6030 codec driver.
The TWL6030 codec uses a propietary PDM-based digital audio interface.
Audio paths supported are:
- Input: Main Mic, Sub Mic, Headset Mic, Auxiliary-FM Left/Right
- Output: Headset Left/Right, Handsfree Left/Right
Signed-off-by: Misael Lopez Cruz x0052...@ti.com
---
sound/soc/codecs/Kconfig |4 +
sound/soc/codecs/Makefile |2 +
sound/soc/codecs/twl6030.c | 824
sound/soc/codecs/twl6030.h | 94 +
4 files changed, 924 insertions(+), 0 deletions(-)
create mode 100644 sound/soc/codecs/twl6030.c
create mode 100644 sound/soc/codecs/twl6030.h
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index bbc97fd..0effb52 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -25,6 +25,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_TLV320AIC26 if SPI_MASTER
select SND_SOC_TLV320AIC3X if I2C
select SND_SOC_TWL4030 if TWL4030_CORE
+ select SND_SOC_TWL6030 if TWL6030_CORE
select SND_SOC_UDA134X
select SND_SOC_UDA1380 if I2C
select SND_SOC_WM8350 if MFD_WM8350
@@ -114,6 +115,9 @@ config SND_SOC_TLV320AIC3X
config SND_SOC_TWL4030
tristate
+config SND_SOC_TWL6030
+ tristate
+
config SND_SOC_UDA134X
tristate
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index 8b75305..b70c8a1 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -13,6 +13,7 @@ snd-soc-tlv320aic23-objs := tlv320aic23.o
snd-soc-tlv320aic26-objs := tlv320aic26.o
snd-soc-tlv320aic3x-objs := tlv320aic3x.o
snd-soc-twl4030-objs := twl4030.o
+snd-soc-twl6030-objs := twl6030.o
snd-soc-uda134x-objs := uda134x.o
snd-soc-uda1380-objs := uda1380.o
snd-soc-wm8350-objs := wm8350.o
@@ -50,6 +51,7 @@ obj-$(CONFIG_SND_SOC_TLV320AIC23) += snd-soc-tlv320aic23.o
obj-$(CONFIG_SND_SOC_TLV320AIC26) += snd-soc-tlv320aic26.o
obj-$(CONFIG_SND_SOC_TLV320AIC3X) += snd-soc-tlv320aic3x.o
obj-$(CONFIG_SND_SOC_TWL4030) += snd-soc-twl4030.o
+obj-$(CONFIG_SND_SOC_TWL6030) += snd-soc-twl6030.o
obj-$(CONFIG_SND_SOC_UDA134X) += snd-soc-uda134x.o
obj-$(CONFIG_SND_SOC_UDA1380) += snd-soc-uda1380.o
obj-$(CONFIG_SND_SOC_WM8350) += snd-soc-wm8350.o
diff --git a/sound/soc/codecs/twl6030.c b/sound/soc/codecs/twl6030.c
new file mode 100644
index 000..3c6c540
--- /dev/null
+++ b/sound/soc/codecs/twl6030.c
@@ -0,0 +1,824 @@
+/*
+ * ALSA SoC TWL6030 codec driver
+ *
+ * Author: Misael Lopez Cruz x0052...@ti.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/moduleparam.h
+#include linux/init.h
+#include linux/delay.h
+#include linux/pm.h
+#include linux/i2c.h
+#include linux/gpio.h
+#include linux/platform_device.h
+#include linux/i2c/twl.h
+
+#include sound/core.h
+#include sound/pcm.h
+#include sound/pcm_params.h
+#include sound/soc.h
+#include sound/soc-dapm.h
+#include sound/initval.h
+#include sound/tlv.h
+
+#include twl6030.h
+
+#define TWL6030_RATES (SNDRV_PCM_RATE_48000)
+#define TWL6030_FORMATS (SNDRV_PCM_FMTBIT_S32_LE)
+
+/* codec private data */
+struct twl6030_data {
+ struct snd_soc_codec codec;
+ int audpwron;
+ int codec_powered;
+};
+
+/*
+ * twl6030 register cache default register settings
+ */
+static const u8 twl6030_reg[TWL6030_CACHEREGNUM] = {
+ 0x00, /* not used 0x00*/
+ 0x4B, /* TWL6030_ASICID (ro)0x01*/
+ 0x00, /* TWL6030_ASICREV (ro) 0x02*/
+ 0x00, /* TWL6030_INTID 0x03*/
+ 0x7B, /* TWL6030_INTMR 0x04*/
+ 0x00, /* TWL6030_NCPCTRL0x05*/
+ 0x00, /* TWL6030_LDOCTL 0x06*/
+ 0x00, /* TWL6030_HPPLLCTL 0x07*/
+ 0x00, /* TWL6030_LPPLLCTL 0x08*/
+ 0x00, /* TWL6030_LPPLLDIV 0x09*/
+ 0x00, /* TWL6030_AMICBCTL 0x0A*/
+ 0x00, /* TWL6030_DMICBCTL 0x0B*/
+ 0x18, /* TWL6030_MICLCTL0x0C*/
+ 0x18, /* TWL6030_MICRCTL0x0D*/
+ 0x00, /* TWL6030_MICGAIN0x0E*/
+ 0x1B, /* TWL6030_LINEGAIN 0x0F*/
+ 0x00, /* TWL6030_HSLCTL 0x10*/
+ 0x00, /* TWL6030_HSRCTL 0x11*/
+ 0x00, /* TWL6030_HSGAIN 0x12*/
+
[PATCHv3 3/7] ASoC: TWL6030: Manual power-up/down sequences
TWL6030 codec device can be powered-up/down through a specific register
writes sequence. These sequences can be used when no gpio line is
provided for AUDPWRON.
When the codec is powered-up in this way, automatic power-down sequence
(triggered by thermal shutdown) is not possible.
Signed-off-by: Misael Lopez Cruz x0052...@ti.com
---
sound/soc/codecs/twl6030.c | 112 ++-
sound/soc/codecs/twl6030.h | 16 ++
2 files changed, 115 insertions(+), 13 deletions(-)
diff --git a/sound/soc/codecs/twl6030.c b/sound/soc/codecs/twl6030.c
index 3c6c540..f97dec2 100644
--- a/sound/soc/codecs/twl6030.c
+++ b/sound/soc/codecs/twl6030.c
@@ -244,6 +244,88 @@ static void twl6030_init_vdd_regs(struct snd_soc_codec
*codec)
}
}
+/* twl6030 codec manual power-up sequence */
+static void twl6030_power_up(struct snd_soc_codec *codec)
+{
+ u8 ncpctl, ldoctl, lppllctl, accctl;
+
+ ncpctl = twl6030_read_reg_cache(codec, TWL6030_REG_NCPCTL);
+ ldoctl = twl6030_read_reg_cache(codec, TWL6030_REG_LDOCTL);
+ lppllctl = twl6030_read_reg_cache(codec, TWL6030_REG_LPPLLCTL);
+ accctl = twl6030_read_reg_cache(codec, TWL6030_REG_ACCCTL);
+
+ /* enable reference system */
+ ldoctl |= TWL6030_REFENA;
+ twl6030_write(codec, TWL6030_REG_LDOCTL, ldoctl);
+ mdelay(10);
+ /* enable internal oscillator */
+ ldoctl |= TWL6030_OSCENA;
+ twl6030_write(codec, TWL6030_REG_LDOCTL, ldoctl);
+ udelay(10);
+ /* enable high-side ldo */
+ ldoctl |= TWL6030_HSLDOENA;
+ twl6030_write(codec, TWL6030_REG_LDOCTL, ldoctl);
+ udelay(244);
+ /* enable negative charge pump */
+ ncpctl |= TWL6030_NCPENA | TWL6030_NCPOPEN;
+ twl6030_write(codec, TWL6030_REG_NCPCTL, ncpctl);
+ udelay(488);
+ /* enable low-side ldo */
+ ldoctl |= TWL6030_LSLDOENA;
+ twl6030_write(codec, TWL6030_REG_LDOCTL, ldoctl);
+ udelay(244);
+ /* enable low-power pll */
+ lppllctl |= TWL6030_LPLLENA;
+ twl6030_write(codec, TWL6030_REG_LPPLLCTL, lppllctl);
+ /* reset state machine */
+ accctl |= TWL6030_RESETSPLIT;
+ twl6030_write(codec, TWL6030_REG_ACCCTL, accctl);
+ mdelay(5);
+ accctl = ~TWL6030_RESETSPLIT;
+ twl6030_write(codec, TWL6030_REG_ACCCTL, accctl);
+ /* disable internal oscillator */
+ ldoctl = ~TWL6030_OSCENA;
+ twl6030_write(codec, TWL6030_REG_LDOCTL, ldoctl);
+}
+
+/* twl6030 codec manual power-down sequence */
+static void twl6030_power_down(struct snd_soc_codec *codec)
+{
+ u8 ncpctl, ldoctl, lppllctl, accctl;
+
+ ncpctl = twl6030_read_reg_cache(codec, TWL6030_REG_NCPCTL);
+ ldoctl = twl6030_read_reg_cache(codec, TWL6030_REG_LDOCTL);
+ lppllctl = twl6030_read_reg_cache(codec, TWL6030_REG_LPPLLCTL);
+ accctl = twl6030_read_reg_cache(codec, TWL6030_REG_ACCCTL);
+
+ /* enable internal oscillator */
+ ldoctl |= TWL6030_OSCENA;
+ twl6030_write(codec, TWL6030_REG_LDOCTL, ldoctl);
+ udelay(10);
+ /* disable low-power pll */
+ lppllctl = ~TWL6030_LPLLENA;
+ twl6030_write(codec, TWL6030_REG_LPPLLCTL, lppllctl);
+ /* disable low-side ldo */
+ ldoctl = ~TWL6030_LSLDOENA;
+ twl6030_write(codec, TWL6030_REG_LDOCTL, ldoctl);
+ udelay(244);
+ /* disable negative charge pump */
+ ncpctl = ~(TWL6030_NCPENA | TWL6030_NCPOPEN);
+ twl6030_write(codec, TWL6030_REG_NCPCTL, ncpctl);
+ udelay(488);
+ /* disable high-side ldo */
+ ldoctl = ~TWL6030_HSLDOENA;
+ twl6030_write(codec, TWL6030_REG_LDOCTL, ldoctl);
+ udelay(244);
+ /* disable internal oscillator */
+ ldoctl = ~TWL6030_OSCENA;
+ twl6030_write(codec, TWL6030_REG_LDOCTL, ldoctl);
+ /* disable reference system */
+ ldoctl = ~TWL6030_REFENA;
+ twl6030_write(codec, TWL6030_REG_LDOCTL, ldoctl);
+ mdelay(10);
+}
+
/*
* MICATT volume control:
* from -6 to 0 dB in 6 dB steps
@@ -480,12 +562,15 @@ static int twl6030_set_bias_level(struct snd_soc_codec
*codec,
/* power-up sequence latency */
mdelay(16);
- }
- /* sync registers updated during power-up sequence */
- twl6030_read(codec, TWL6030_REG_NCPCTL);
- twl6030_read(codec, TWL6030_REG_LDOCTL);
- twl6030_read(codec, TWL6030_REG_LPPLLCTL);
+ /* sync registers updated during power-up sequence */
+ twl6030_read(codec, TWL6030_REG_NCPCTL);
+ twl6030_read(codec, TWL6030_REG_LDOCTL);
+ twl6030_read(codec, TWL6030_REG_LPPLLCTL);
+ } else {
+ /* use manual power-up sequence */
+ twl6030_power_up(codec);
+ }
/* initialize vdd/vss registers with reg_cache */
[PATCHv3 4/7] ASoC: TWL6030: Add support for low-power PLL
TWL6030 codec sysclk can be provided by: low-power or high
performance PLL.
The low-power PLL takes a low-frequency input at 32,768 Hz and
generates an approximate of 17.64 or 19.2 MHz.
The high-performance PLL generates an exact 19.2 MHz clock signal
from high-frequency input at 12/19.2/26/38.4 MHz.
For the particular case of headset path, PLL being used defines the
headset power mode: low-power, high-performance. Headset DAC and
output driver should be configured according to the selected mode.
17.64 MHz sysclk is recommended only for headset low-power playback
mode.
Signed-off-by: Misael Lopez Cruz x0052...@ti.com
---
sound/soc/codecs/twl6030.c | 232 +--
sound/soc/codecs/twl6030.h | 16 +++
2 files changed, 215 insertions(+), 33 deletions(-)
diff --git a/sound/soc/codecs/twl6030.c b/sound/soc/codecs/twl6030.c
index f97dec2..9fc4795 100644
--- a/sound/soc/codecs/twl6030.c
+++ b/sound/soc/codecs/twl6030.c
@@ -39,7 +39,7 @@
#include twl6030.h
-#define TWL6030_RATES (SNDRV_PCM_RATE_48000)
+#define TWL6030_RATES (SNDRV_PCM_RATE_44100 | SNDRV_PCM_RATE_48000)
#define TWL6030_FORMATS (SNDRV_PCM_FMTBIT_S32_LE)
/* codec private data */
@@ -47,6 +47,9 @@ struct twl6030_data {
struct snd_soc_codec codec;
int audpwron;
int codec_powered;
+ int pll;
+ unsigned int sysclk;
+ struct snd_pcm_hw_constraint_list *sysclk_constraints;
};
/*
@@ -326,6 +329,29 @@ static void twl6030_power_down(struct snd_soc_codec *codec)
mdelay(10);
}
+/* set headset dac and driver power mode */
+static int headset_power_mode(struct snd_soc_codec *codec, int high_perf)
+{
+ int hslctl, hsrctl;
+ int mask = TWL6030_HSDRVMODEL | TWL6030_HSDACMODEL;
+
+ hslctl = twl6030_read_reg_cache(codec, TWL6030_REG_HSLCTL);
+ hsrctl = twl6030_read_reg_cache(codec, TWL6030_REG_HSRCTL);
+
+ if (high_perf) {
+ hslctl = ~mask;
+ hsrctl = ~mask;
+ } else {
+ hslctl |= mask;
+ hsrctl |= mask;
+ }
+
+ twl6030_write(codec, TWL6030_REG_HSLCTL, hslctl);
+ twl6030_write(codec, TWL6030_REG_HSRCTL, hsrctl);
+
+ return 0;
+}
+
/*
* MICATT volume control:
* from -6 to 0 dB in 6 dB steps
@@ -607,55 +633,195 @@ static int twl6030_set_bias_level(struct snd_soc_codec
*codec,
return 0;
}
+/* set of rates for each pll: low-power and high-performance */
+
+static unsigned int lp_rates[] = {
+ 44100,
+ 48000,
+};
+
+static struct snd_pcm_hw_constraint_list lp_constraints = {
+ .count = ARRAY_SIZE(lp_rates),
+ .list = lp_rates,
+};
+
+static unsigned int hp_rates[] = {
+ 48000,
+};
+
+static struct snd_pcm_hw_constraint_list hp_constraints = {
+ .count = ARRAY_SIZE(hp_rates),
+ .list = hp_rates,
+};
+
+static int twl6030_startup(struct snd_pcm_substream *substream,
+ struct snd_soc_dai *dai)
+{
+ struct snd_soc_pcm_runtime *rtd = substream-private_data;
+ struct snd_soc_device *socdev = rtd-socdev;
+ struct snd_soc_codec *codec = socdev-card-codec;
+ struct twl6030_data *priv = codec-private_data;
+
+ if (!priv-sysclk) {
+ dev_err(codec-dev,
+ no mclk configured, call set_sysclk() on init\n);
+ return -EINVAL;
+ }
+
+ snd_pcm_hw_constraint_list(substream-runtime, 0,
+ SNDRV_PCM_HW_PARAM_RATE,
+ priv-sysclk_constraints);
+
+ return 0;
+}
+
+static int twl6030_hw_params(struct snd_pcm_substream *substream,
+ struct snd_pcm_hw_params *params,
+ struct snd_soc_dai *dai)
+{
+ struct snd_soc_pcm_runtime *rtd = substream-private_data;
+ struct snd_soc_device *socdev = rtd-socdev;
+ struct snd_soc_codec *codec = socdev-card-codec;
+ struct twl6030_data *priv = codec-private_data;
+ u8 lppllctl;
+ int rate;
+
+ /* nothing to do for high-perf pll, it supports only 48 kHz */
+ if (priv-pll == TWL6030_HPPLL_ID)
+ return 0;
+
+ lppllctl = twl6030_read_reg_cache(codec, TWL6030_REG_LPPLLCTL);
+
+ rate = params_rate(params);
+ switch (rate) {
+ case 44100:
+ lppllctl |= TWL6030_LPLLFIN;
+ priv-sysclk = 1764;
+ break;
+ case 48000:
+ lppllctl = ~TWL6030_LPLLFIN;
+ priv-sysclk = 1920;
+ break;
+ default:
+ dev_err(codec-dev, unsupported rate %d\n, rate);
+ return -EINVAL;
+ }
+
+ twl6030_write(codec, TWL6030_REG_LPPLLCTL, lppllctl);
+
+ return 0;
+}
+
static int twl6030_set_dai_sysclk(struct snd_soc_dai *codec_dai,
int clk_id, unsigned int freq, int dir)
{
struct snd_soc_codec *codec = codec_dai-codec;
+ struct
[PATCHv3 5/7] ASoC: TWL6030: Add restrictions for low-power playback mode
Low-power playback mode is a special scenario where only headset path
(headset DAC and driver) is active. Only in this mode the codec can
support 44.1 and 48 kHz, low-power PLL should provide sysclk signal.
Currently, handsfree DAC and driver are the only components that can
prevent codec to enter to low-power playback mode. Other components
like earphone driver, vibrator driver or loopback (which are not yet
supported in the driver) can cause the same effect.
In order to detect conflicting paths, CODEC driver supervises
non-low-power widgets powered by DAPM mechanism, just at the point
pcm trigger callback gets called.
Signed-off-by: Misael Lopez Cruz x0052...@ti.com
---
sound/soc/codecs/twl6030.c | 79 +++
1 files changed, 71 insertions(+), 8 deletions(-)
diff --git a/sound/soc/codecs/twl6030.c b/sound/soc/codecs/twl6030.c
index 9fc4795..8548442 100644
--- a/sound/soc/codecs/twl6030.c
+++ b/sound/soc/codecs/twl6030.c
@@ -48,6 +48,7 @@ struct twl6030_data {
int audpwron;
int codec_powered;
int pll;
+ int non_lp;
unsigned int sysclk;
struct snd_pcm_hw_constraint_list *sysclk_constraints;
};
@@ -352,6 +353,20 @@ static int headset_power_mode(struct snd_soc_codec *codec,
int high_perf)
return 0;
}
+static int twl6030_power_mode_event(struct snd_soc_dapm_widget *w,
+ struct snd_kcontrol *kcontrol, int event)
+{
+ struct snd_soc_codec *codec = w-codec;
+ struct twl6030_data *priv = codec-private_data;
+
+ if (SND_SOC_DAPM_EVENT_ON(event))
+ priv-non_lp++;
+ else
+ priv-non_lp--;
+
+ return 0;
+}
+
/*
* MICATT volume control:
* from -6 to 0 dB in 6 dB steps
@@ -485,10 +500,14 @@ static const struct snd_soc_dapm_widget
twl6030_dapm_widgets[] = {
TWL6030_REG_HSLCTL, 0, 0),
SND_SOC_DAPM_DAC(HSDAC Right, Headset Playback,
TWL6030_REG_HSRCTL, 0, 0),
- SND_SOC_DAPM_DAC(HFDAC Left, Handsfree Playback,
- TWL6030_REG_HFLCTL, 0, 0),
- SND_SOC_DAPM_DAC(HFDAC Right, Handsfree Playback,
- TWL6030_REG_HFRCTL, 0, 0),
+ SND_SOC_DAPM_DAC_E(HFDAC Left, Handsfree Playback,
+ TWL6030_REG_HFLCTL, 0, 0,
+ twl6030_power_mode_event,
+ SND_SOC_DAPM_POST_PMU | SND_SOC_DAPM_POST_PMD),
+ SND_SOC_DAPM_DAC_E(HFDAC Right, Handsfree Playback,
+ TWL6030_REG_HFRCTL, 0, 0,
+ twl6030_power_mode_event,
+ SND_SOC_DAPM_POST_PMU | SND_SOC_DAPM_POST_PMD),
/* Analog playback switches */
SND_SOC_DAPM_SWITCH(HSDAC Left Playback,
@@ -504,10 +523,14 @@ static const struct snd_soc_dapm_widget
twl6030_dapm_widgets[] = {
SND_SOC_NOPM, 0, 0, hsl_driver_switch_controls),
SND_SOC_DAPM_SWITCH(Headset Right Driver,
SND_SOC_NOPM, 0, 0, hsr_driver_switch_controls),
- SND_SOC_DAPM_SWITCH(Handsfree Left Driver,
- SND_SOC_NOPM, 0, 0, hfl_driver_switch_controls),
- SND_SOC_DAPM_SWITCH(Handsfree Right Driver,
- SND_SOC_NOPM, 0, 0, hfr_driver_switch_controls),
+ SND_SOC_DAPM_SWITCH_E(Handsfree Left Driver,
+ SND_SOC_NOPM, 0, 0, hfl_driver_switch_controls,
+ twl6030_power_mode_event,
+ SND_SOC_DAPM_POST_PMU | SND_SOC_DAPM_POST_PMD),
+ SND_SOC_DAPM_SWITCH_E(Handsfree Right Driver,
+ SND_SOC_NOPM, 0, 0, hfr_driver_switch_controls,
+ twl6030_power_mode_event,
+ SND_SOC_DAPM_POST_PMU | SND_SOC_DAPM_POST_PMD),
/* Analog playback PGAs */
SND_SOC_DAPM_PGA(HFDAC Left PGA,
@@ -668,6 +691,17 @@ static int twl6030_startup(struct snd_pcm_substream
*substream,
return -EINVAL;
}
+ /*
+* capture is not supported at 17.64 MHz,
+* it's reserved for headset low-power playback scenario
+*/
+ if ((priv-sysclk == 1764) substream-stream) {
+ dev_err(codec-dev,
+ capture mode is not supported at %dHz\n,
+ priv-sysclk);
+ return -EINVAL;
+ }
+
snd_pcm_hw_constraint_list(substream-runtime, 0,
SNDRV_PCM_HW_PARAM_RATE,
priv-sysclk_constraints);
@@ -712,6 +746,34 @@ static int twl6030_hw_params(struct snd_pcm_substream
*substream,
return 0;
}
+static int twl6030_trigger(struct snd_pcm_substream *substream,
+ int cmd, struct snd_soc_dai *dai)
+{
+ struct snd_soc_pcm_runtime *rtd = substream-private_data;
+ struct snd_soc_device *socdev = rtd-socdev;
+ struct snd_soc_codec *codec = socdev-card-codec;
+
[PATCHv3 6/7] ASoC: TWL6030: Enable audio interrupt
NAUDINT interrupt line is provided by the TWL6030 codec to signal
externally events like headset plug/unplug, hook, power-up sequence
completion, etc.
Signed-off-by: Misael Lopez Cruz x0052...@ti.com
---
sound/soc/codecs/twl6030.c | 70 ---
sound/soc/codecs/twl6030.h | 14 +
2 files changed, 79 insertions(+), 5 deletions(-)
diff --git a/sound/soc/codecs/twl6030.c b/sound/soc/codecs/twl6030.c
index 8548442..56fe136 100644
--- a/sound/soc/codecs/twl6030.c
+++ b/sound/soc/codecs/twl6030.c
@@ -46,6 +46,7 @@
struct twl6030_data {
struct snd_soc_codec codec;
int audpwron;
+ int naudint;
int codec_powered;
int pll;
int non_lp;
@@ -61,7 +62,7 @@ static const u8 twl6030_reg[TWL6030_CACHEREGNUM] = {
0x4B, /* TWL6030_ASICID (ro)0x01*/
0x00, /* TWL6030_ASICREV (ro) 0x02*/
0x00, /* TWL6030_INTID 0x03*/
- 0x7B, /* TWL6030_INTMR 0x04*/
+ 0x00, /* TWL6030_INTMR 0x04*/
0x00, /* TWL6030_NCPCTRL0x05*/
0x00, /* TWL6030_LDOCTL 0x06*/
0x00, /* TWL6030_HPPLLCTL 0x07*/
@@ -367,6 +368,39 @@ static int twl6030_power_mode_event(struct
snd_soc_dapm_widget *w,
return 0;
}
+/* audio interrupt handler */
+static irqreturn_t twl6030_naudint_handler(int irq, void *data)
+{
+ struct snd_soc_codec *codec = data;
+ u8 intid;
+
+ twl_i2c_read_u8(TWL6030_MODULE_AUDIO, intid, TWL6030_REG_INTID);
+
+ switch (intid) {
+ case TWL6030_THINT:
+ dev_alert(codec-dev, die temp over-limit detection\n);
+ break;
+ case TWL6030_PLUGINT:
+ case TWL6030_UNPLUGINT:
+ case TWL6030_HOOKINT:
+ break;
+ case TWL6030_HFINT:
+ dev_alert(codec-dev, hf drivers over current detection\n);
+ break;
+ case TWL6030_VIBINT:
+ dev_alert(codec-dev, vib drivers over current detection\n);
+ break;
+ case TWL6030_READYINT:
+ dev_alert(codec-dev, codec is ready\n);
+ break;
+ default:
+ dev_err(codec-dev, unknown audio interrupt %d\n, intid);
+ break;
+ }
+
+ return IRQ_HANDLED;
+}
+
/*
* MICATT volume control:
* from -6 to 0 dB in 6 dB steps
@@ -993,19 +1027,23 @@ static int __devinit twl6030_codec_probe(struct
platform_device *pdev)
struct twl_codec_data *twl_codec = pdev-dev.platform_data;
struct snd_soc_codec *codec;
struct twl6030_data *priv;
- int audpwron;
+ int audpwron, naudint;
int ret = 0;
priv = kzalloc(sizeof(struct twl6030_data), GFP_KERNEL);
if (priv == NULL)
return -ENOMEM;
- if (twl_codec)
+ if (twl_codec) {
audpwron = twl_codec-audpwron_gpio;
- else
+ naudint = twl_codec-naudint_irq;
+ } else {
audpwron = -EINVAL;
+ naudint = 0;
+ }
priv-audpwron = audpwron;
+ priv-naudint = naudint;
codec = priv-codec;
codec-dev = pdev-dev;
@@ -1043,13 +1081,28 @@ static int __devinit twl6030_codec_probe(struct
platform_device *pdev)
priv-codec_powered = 0;
}
+ if (naudint) {
+ /* audio interrupt */
+ ret = request_threaded_irq(naudint, NULL,
+ twl6030_naudint_handler,
+ IRQF_TRIGGER_LOW | IRQF_ONESHOT,
+ twl6030_codec, codec);
+ if (ret)
+ goto gpio2_err;
+ } else {
+ dev_warn(codec-dev,
+ no naudint irq, audio interrupts disabled\n);
+ twl6030_write_reg_cache(codec, TWL6030_REG_INTMR,
+ TWL6030_ALLINT_MSK);
+ }
+
/* init vio registers */
twl6030_init_vio_regs(codec);
/* power on device */
ret = twl6030_set_bias_level(codec, SND_SOC_BIAS_STANDBY);
if (ret)
- goto gpio2_err;
+ goto irq_err;
ret = snd_soc_register_codec(codec);
if (ret)
@@ -1068,6 +1121,9 @@ dai_err:
twl6030_codec = NULL;
reg_err:
twl6030_set_bias_level(codec, SND_SOC_BIAS_OFF);
+irq_err:
+ if (naudint)
+ free_irq(naudint, codec);
gpio2_err:
if (gpio_is_valid(audpwron))
gpio_free(audpwron);
@@ -1082,10 +1138,14 @@ static int __devexit twl6030_codec_remove(struct
platform_device *pdev)
{
struct twl6030_data *priv = twl6030_codec-private_data;
int audpwron = priv-audpwron;
+ int naudint = priv-naudint;
if (gpio_is_valid(audpwron))
gpio_free(audpwron);
+ if (naudint)
+ free_irq(naudint, twl6030_codec);
+
[PATCHv3 7/7] ASoC: TWL6030: Detect power-up sequence completion
When the codec is powered-up through external AUDPWRON line it starts
its power-up sequence. The completion of the sequence is signaled
through the audio interrupt, and then codec is operational.
If NAUDINT irq is provided, CODEC driver starts a wait_for_completion
just after AUDPWRON line transitions from low to high. It's signaled as
complete when servicing READYINT interrupt.
If AUDPWRON gpio line is provided but NAUDINT irq is not, then CODEC
driver enables READYINT and polls on INTID register. If none of them are
provided, then CODEC uses manual power sequences and disables all audio
interrupts.
Signed-off-by: Misael Lopez Cruz x0052...@ti.com
---
sound/soc/codecs/twl6030.c | 61 +--
sound/soc/codecs/twl6030.h |1 +
2 files changed, 53 insertions(+), 9 deletions(-)
diff --git a/sound/soc/codecs/twl6030.c b/sound/soc/codecs/twl6030.c
index 56fe136..3db7f1d 100644
--- a/sound/soc/codecs/twl6030.c
+++ b/sound/soc/codecs/twl6030.c
@@ -52,6 +52,7 @@ struct twl6030_data {
int non_lp;
unsigned int sysclk;
struct snd_pcm_hw_constraint_list *sysclk_constraints;
+ struct completion ready;
};
/*
@@ -372,6 +373,7 @@ static int twl6030_power_mode_event(struct
snd_soc_dapm_widget *w,
static irqreturn_t twl6030_naudint_handler(int irq, void *data)
{
struct snd_soc_codec *codec = data;
+ struct twl6030_data *priv = codec-private_data;
u8 intid;
twl_i2c_read_u8(TWL6030_MODULE_AUDIO, intid, TWL6030_REG_INTID);
@@ -391,7 +393,7 @@ static irqreturn_t twl6030_naudint_handler(int irq, void
*data)
dev_alert(codec-dev, vib drivers over current detection\n);
break;
case TWL6030_READYINT:
- dev_alert(codec-dev, codec is ready\n);
+ complete(priv-ready);
break;
default:
dev_err(codec-dev, unknown audio interrupt %d\n, intid);
@@ -626,11 +628,45 @@ static int twl6030_add_widgets(struct snd_soc_codec
*codec)
return 0;
}
+static int twl6030_power_up_completion(struct snd_soc_codec *codec,
+ int naudint)
+{
+ struct twl6030_data *priv = codec-private_data;
+ int time_left;
+ u8 intid;
+
+ if (naudint) {
+ /* wait for ready interrupt with 48 ms timeout */
+ time_left = wait_for_completion_timeout(priv-ready,
+ msecs_to_jiffies(48));
+ } else {
+ /* retry 3 times only */
+ for (time_left = 3; time_left 0; time_left--) {
+ mdelay(16);
+ twl_i2c_read_u8(TWL6030_MODULE_AUDIO, intid,
+ TWL6030_REG_INTID);
+ if (intid TWL6030_READYINT)
+ break;
+ }
+ }
+
+ if (!time_left) {
+ dev_err(codec-dev, timeout waiting for READYINT\n);
+ return -ETIMEDOUT;
+ }
+
+ priv-codec_powered = 1;
+
+ return 0;
+}
+
static int twl6030_set_bias_level(struct snd_soc_codec *codec,
enum snd_soc_bias_level level)
{
struct twl6030_data *priv = codec-private_data;
int audpwron = priv-audpwron;
+ int naudint = priv-naudint;
+ int ret;
switch (level) {
case SND_SOC_BIAS_ON:
@@ -643,8 +679,10 @@ static int twl6030_set_bias_level(struct snd_soc_codec
*codec,
/* use AUDPWRON line */
gpio_set_value(audpwron, 1);
- /* power-up sequence latency */
- mdelay(16);
+ /* wait for power-up completion */
+ ret = twl6030_power_up_completion(codec, naudint);
+ if (ret)
+ return ret;
/* sync registers updated during power-up sequence */
twl6030_read(codec, TWL6030_REG_NCPCTL);
@@ -653,12 +691,11 @@ static int twl6030_set_bias_level(struct snd_soc_codec
*codec,
} else {
/* use manual power-up sequence */
twl6030_power_up(codec);
+ priv-codec_powered = 1;
}
/* initialize vdd/vss registers with reg_cache */
twl6030_init_vdd_regs(codec);
-
- priv-codec_powered = 1;
break;
case SND_SOC_BIAS_OFF:
if (!priv-codec_powered)
@@ -1068,6 +1105,7 @@ static int __devinit twl6030_codec_probe(struct
platform_device *pdev)
mutex_init(codec-mutex);
INIT_LIST_HEAD(codec-dapm_widgets);
INIT_LIST_HEAD(codec-dapm_paths);
+ init_completion(priv-ready);
if (gpio_is_valid(audpwron)) {
ret = gpio_request(audpwron, audpwron);
@@ -1090,10 +1128,15 @@
RE: Question on OPP table handling
Hi Kevin,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Nishanth Menon
Sent: Monday, October 05, 2009 7:19 PM
To: linux-omap@vger.kernel.org
Cc: Premi, Sanjeev; Kevin H
Subject: Re: Question on OPP table handling
Kevin Hilman had written, on 10/05/2009 11:56 AM, the following:
Premi, Sanjeev pr...@ti.com writes:
-Original Message-
From: Nishanth Menon [mailto:menon.nisha...@gmail.com]
Sent: Saturday, October 03, 2009 8:35 PM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org
Subject: Question on OPP table handling
Sanjeev Premi said the following on 10/01/2009 01:03 PM:
+struct omap_opp omap3_mpu_rate_table[] = {
+{0, 0, 0},
+/*OPP1*/
+{S125M, VDD1_OPP1, 0x1E},
+/*OPP2*/
+{S250M, VDD1_OPP2, 0x26},
+/*OPP3*/
+{S500M, VDD1_OPP3, 0x30},
+/*OPP4*/
+{S550M, VDD1_OPP4, 0x36},
+/*OPP5*/
+{S600M, VDD1_OPP5, 0x3C},
+};
For those involved,
if we wanted to convert omap3_mpu_table[] into
*omap3_mpu_table so that
we dynamically initialize it based on cpu type - what would be the
recommendations?
Nishanth,
Good idea!
As a table, previous patch enables it (not as intent, but due to
syntax):
+/* struct omap_opp_table - View OPP table as an object
+ * @min: Minimum OPP id
+ * @max: Maximim OPP id
+ * @opps: Pointer to array defining the OPPs.
+ *
+ * An OPP table has varied length. Knowing minimum and maximum
+ * OPP ids allow easy traversal.
+ */
+struct omap_opp_table {
+ u8 min;
+ u8 max;
+ struct omap_opp* opps;
+};
But now, I think it would be good to have an API that can fill an
opp_table:
int add_opp_definition(u8 id, u32 freq, u16 vsel);
...and, if an array is preferred, length can be set as:
int set_opp_table_length (u8 max);
I'm all for dynamic OPP setting, but not as an array. A list should
probably be used.
Won't a list implementation cause more than necessary overhead? I agree
that something like set_opp_table_length probably might be redundant in
that case.
I'm aligned with Nishanth. I think a static table with the possibility to
disable some entry is good enough to deal with most of the OPPs we have on
OMAP3 and we will have to handle on OMAP4.
OPPs are defined during silicon characterization, and should not be changed
dynamically (in theory).
Do you have something in mind that might justify a dynamic management?
Regards,
Benoit
If I were to extend the discussion from other thread on toggling the
valid OPPs
based on enable_off_mode, these could be handy.
int set_opp_valid(bool flag);
bool is_opp_valid(void);
Yes, we need a concept of a valid OPP, not just for OFF mode, but for
OSWR and possibly for a full constraint framework as well.
Ack.
--
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
--
To unsubscribe from this list: send the line unsubscribe 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: Question on OPP table handling
-Original Message-
From: Shilimkar, Santosh
Sent: Tuesday, October 06, 2009 1:36 PM
To: Menon, Nishanth; linux-omap@vger.kernel.org
Cc: Premi, Sanjeev; Kevin H
Subject: RE: Question on OPP table handling
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Nishanth Menon
Sent: Monday, October 05, 2009 10:49 PM
To: linux-omap@vger.kernel.org
Cc: Premi, Sanjeev; Kevin H
Subject: Re: Question on OPP table handling
Kevin Hilman had written, on 10/05/2009 11:56 AM, the following:
Premi, Sanjeev pr...@ti.com writes:
-Original Message-
From: Nishanth Menon [mailto:menon.nisha...@gmail.com]
Sent: Saturday, October 03, 2009 8:35 PM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org
Subject: Question on OPP table handling
Sanjeev Premi said the following on 10/01/2009 01:03 PM:
+struct omap_opp omap3_mpu_rate_table[] = {
+ {0, 0, 0},
+ /*OPP1*/
+ {S125M, VDD1_OPP1, 0x1E},
+ /*OPP2*/
+ {S250M, VDD1_OPP2, 0x26},
+ /*OPP3*/
+ {S500M, VDD1_OPP3, 0x30},
+ /*OPP4*/
+ {S550M, VDD1_OPP4, 0x36},
+ /*OPP5*/
+ {S600M, VDD1_OPP5, 0x3C},
+};
For those involved,
if we wanted to convert omap3_mpu_table[] into
*omap3_mpu_table so that
we dynamically initialize it based on cpu type - what
would be the
recommendations?
Nishanth,
Good idea!
As a table, previous patch enables it (not as intent, but due to
syntax):
+/* struct omap_opp_table - View OPP table as an object
+ * @min: Minimum OPP id
+ * @max: Maximim OPP id
+ * @opps: Pointer to array defining the OPPs.
+ *
+ * An OPP table has varied length. Knowing minimum
and maximum
+ * OPP ids allow easy traversal.
+ */
+struct omap_opp_table {
+ u8 min;
+ u8 max;
+ struct omap_opp* opps;
+};
But now, I think it would be good to have an API that can fill an
opp_table:
int add_opp_definition(u8 id, u32 freq, u16 vsel);
...and, if an array is preferred, length can be set as:
int set_opp_table_length (u8 max);
I'm all for dynamic OPP setting, but not as an array. A
list should
probably be used.
Won't a list implementation cause more than necessary
overhead? I agree
that something like set_opp_table_length probably might be
redundant in
that case.
If I were to extend the discussion from other thread on
toggling the
valid OPPs
based on enable_off_mode, these could be handy.
int set_opp_valid(bool flag);
bool is_opp_valid(void);
Yes, we need a concept of a valid OPP, not just for OFF
mode, but for
OSWR and possibly for a full constraint framework as well.
Ack.
Even though above approach is possibly better a simple fix
could be just adding a flag in the structure (OPP
valid/invalid) and populating this flag run time using CPU type.
[sp] This is exactly in the original patch.
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: [alsa-devel] [PATCHv3 1/7] OMAP4: PMIC: Add support for twl6030 codec
On Tuesday 06 October 2009 10:29:39 ext Lopez Cruz, Misael wrote:
In order to have TWL6030 CODEC driver as a platform driver, codec data
should be passed through twl_platform_data structure.
For twl6030 audio codec, the following data may be passed:
- audpwron_gpio: gpio line used to power-up/down the codec. A low-to-high
transition powers codec up. Setting audpwron_gpio to a negative value
means that codec will use manual power sequence instead of automatic
sequence
- naudint_irq: irq line for audio interrupt. twl6030 drives NAUDINT line
to low when an interrupt (codec ready, plug insertion/removal, etc) is
detected
However, codec driver can operate if any or none of them are passed.
How does the twl4030 series would fit with this modification?
I have also added the twl4030 codec as a child for the twl MFD, but I have not
finished the cleanup of the codec fully.
Signed-off-by: Misael Lopez Cruz x0052...@ti.com
---
drivers/mfd/twl-core.c | 15 +++
include/linux/i2c/twl.h |7 +++
2 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index af4cf47..6432af1 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -108,6 +108,12 @@
#define twl_has_mmc() false
#endif
+#if defined(CONFIG_SND_SOC_TWL6030) ||
defined(CONFIG_SND_SOC_TWL6030_MODULE) +#define twl_has_codec() true
+#else
+#define twl_has_codec() false
+#endif
+
#if defined(CONFIG_TWL4030_USB) || defined(CONFIG_TWL4030_USB_MODULE)
#define twl_has_usb()true
#else
@@ -190,6 +196,7 @@
#define BCI_SUB_CHIP_ID SUB_CHIP_ID1
#define GPIO_SUB_CHIP_ID 0 /* NOT SUPPORTED IN TWL6030 */
#define KEYPAD_SUB_CHIP_ID 0 /* ADDED FOR COMPILATION ONLY */
+#define CODEC_SUB_CHIP_IDSUB_CHIP_ID3
TWL4030 codec is under ID2 address group.
/* subchip/slave 0 0x48 - POWER */
#define TWL6030_BASEADD_RTC 0x
@@ -632,6 +639,14 @@ add_children(struct twl_platform_data *pdata, unsigned
long features) if (IS_ERR(child))
return PTR_ERR(child);
}
+
+ if (twl_has_codec()) {
+ child = add_child(CODEC_SUB_CHIP_ID, twl6030_codec,
+ pdata-codec, sizeof(*pdata-codec), false,
+ 0, 0);
+ if (IS_ERR(child))
+ return PTR_ERR(child);
+ }
We are going to have the twl4030 as child as well.
#endif
if (twl_has_usb() pdata-usb) {
diff --git a/include/linux/i2c/twl.h b/include/linux/i2c/twl.h
index b687a8b..e76ca9b 100644
--- a/include/linux/i2c/twl.h
+++ b/include/linux/i2c/twl.h
@@ -472,6 +472,12 @@ struct twl_usb_data {
enum twl_usb_mode usb_mode;
};
+struct twl_codec_data {
+ /* twl6030 */
+ int audpwron_gpio; /* audio power-on gpio */
+ int naudint_irq;/* audio interrupt */
+};
These are not applicable for the twl4030 codec, should we have different
twl_codec_data for twl6030 and twl4030 series?
Should I merge here the things which will be used for the twl4030 codec?
At the moment, I only have audio_mclk in my codec_data, but most probably the
HS
ramp related things will be also merged here in the future.
+
struct twl_platform_data {
unsignedirq_base, irq_end;
struct twl_bci_platform_data*bci;
@@ -479,6 +485,7 @@ struct twl_platform_data {
struct twl_madc_platform_data *madc;
struct twl_keypad_data *keypad;
struct twl_usb_data *usb;
+ struct twl_codec_data *codec;
/* LDO regulators common to TWL4030/TWL6030 */
struct regulator_init_data *vdac;
--
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: Question on OPP table handling
-Original Message-
From: Cousson, Benoit
Sent: Tuesday, October 06, 2009 2:12 PM
To: Kevin H; linux-omap@vger.kernel.org
Cc: Premi, Sanjeev; Menon, Nishanth
Subject: RE: Question on OPP table handling
Hi Kevin,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Nishanth Menon
Sent: Monday, October 05, 2009 7:19 PM
To: linux-omap@vger.kernel.org
Cc: Premi, Sanjeev; Kevin H
Subject: Re: Question on OPP table handling
Kevin Hilman had written, on 10/05/2009 11:56 AM, the following:
Premi, Sanjeev pr...@ti.com writes:
-Original Message-
From: Nishanth Menon [mailto:menon.nisha...@gmail.com]
Sent: Saturday, October 03, 2009 8:35 PM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org
Subject: Question on OPP table handling
Sanjeev Premi said the following on 10/01/2009 01:03 PM:
+struct omap_opp omap3_mpu_rate_table[] = {
+ {0, 0, 0},
+ /*OPP1*/
+ {S125M, VDD1_OPP1, 0x1E},
+ /*OPP2*/
+ {S250M, VDD1_OPP2, 0x26},
+ /*OPP3*/
+ {S500M, VDD1_OPP3, 0x30},
+ /*OPP4*/
+ {S550M, VDD1_OPP4, 0x36},
+ /*OPP5*/
+ {S600M, VDD1_OPP5, 0x3C},
+};
For those involved,
if we wanted to convert omap3_mpu_table[] into
*omap3_mpu_table so that
we dynamically initialize it based on cpu type - what
would be the
recommendations?
Nishanth,
Good idea!
As a table, previous patch enables it (not as intent, but due to
syntax):
+/* struct omap_opp_table - View OPP table as an object
+ * @min: Minimum OPP id
+ * @max: Maximim OPP id
+ * @opps: Pointer to array defining the OPPs.
+ *
+ * An OPP table has varied length. Knowing minimum
and maximum
+ * OPP ids allow easy traversal.
+ */
+struct omap_opp_table {
+ u8 min;
+ u8 max;
+ struct omap_opp* opps;
+};
But now, I think it would be good to have an API that can fill an
opp_table:
int add_opp_definition(u8 id, u32 freq, u16 vsel);
...and, if an array is preferred, length can be set as:
int set_opp_table_length (u8 max);
I'm all for dynamic OPP setting, but not as an array. A
list should
probably be used.
Won't a list implementation cause more than necessary
overhead? I agree
that something like set_opp_table_length probably might be
redundant in
that case.
I'm aligned with Nishanth. I think a static table with the
possibility to disable some entry is good enough to deal with
most of the OPPs we have on OMAP3 and we will have to handle on OMAP4.
OPPs are defined during silicon characterization, and should
not be changed dynamically (in theory).
[sp] The intent of 'dynamic' is not with respect to changing the
OPPs but manitaining OPPs in an array or a list.
This is to take care of possibility that an OPP is not
applicable for specific devices. E.g. OPP5 was earlier
considered 'overdrive'; and the code had a small 'hack'
to prevent this OPP being used during cpufreq.
Marking the OPP 'disabled/invalid' in the table would have
been a better solution.
In a 'list' implementation, the node corresponding to such
OPPs can be removed from the 'active' list.
Best regards,
Sanjeev
Do you have something in mind that might justify a dynamic management?
Regards,
Benoit
If I were to extend the discussion from other thread on
toggling the
valid OPPs
based on enable_off_mode, these could be handy.
int set_opp_valid(bool flag);
bool is_opp_valid(void);
Yes, we need a concept of a valid OPP, not just for OFF
mode, but for
OSWR and possibly for a full constraint framework as well.
Ack.
--
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
--
To unsubscribe from this list: send the line unsubscribe 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: Question on OPP table handling
-Original Message-
From: Premi, Sanjeev
Sent: Tuesday, October 06, 2009 2:14 PM
To: Shilimkar, Santosh; Menon, Nishanth; linux-omap@vger.kernel.org
Cc: Kevin H
Subject: RE: Question on OPP table handling
-Original Message-
From: Shilimkar, Santosh
Sent: Tuesday, October 06, 2009 1:36 PM
To: Menon, Nishanth; linux-omap@vger.kernel.org
Cc: Premi, Sanjeev; Kevin H
Subject: RE: Question on OPP table handling
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Nishanth Menon
Sent: Monday, October 05, 2009 10:49 PM
To: linux-omap@vger.kernel.org
Cc: Premi, Sanjeev; Kevin H
Subject: Re: Question on OPP table handling
Kevin Hilman had written, on 10/05/2009 11:56 AM, the following:
Premi, Sanjeev pr...@ti.com writes:
-Original Message-
From: Nishanth Menon [mailto:menon.nisha...@gmail.com]
Sent: Saturday, October 03, 2009 8:35 PM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org
Subject: Question on OPP table handling
Sanjeev Premi said the following on 10/01/2009 01:03 PM:
+struct omap_opp omap3_mpu_rate_table[] = {
+{0, 0, 0},
+/*OPP1*/
+{S125M, VDD1_OPP1, 0x1E},
+/*OPP2*/
+{S250M, VDD1_OPP2, 0x26},
+/*OPP3*/
+{S500M, VDD1_OPP3, 0x30},
+/*OPP4*/
+{S550M, VDD1_OPP4, 0x36},
+/*OPP5*/
+{S600M, VDD1_OPP5, 0x3C},
+};
For those involved,
if we wanted to convert omap3_mpu_table[] into
*omap3_mpu_table so that
we dynamically initialize it based on cpu type - what
would be the
recommendations?
Nishanth,
Good idea!
As a table, previous patch enables it (not as intent, but due to
syntax):
+/* struct omap_opp_table - View OPP table as an object
+ * @min: Minimum OPP id
+ * @max: Maximim OPP id
+ * @opps: Pointer to array defining the OPPs.
+ *
+ * An OPP table has varied length. Knowing minimum
and maximum
+ * OPP ids allow easy traversal.
+ */
+struct omap_opp_table {
+ u8 min;
+ u8 max;
+ struct omap_opp* opps;
+};
But now, I think it would be good to have an API that can fill an
opp_table:
int add_opp_definition(u8 id, u32 freq, u16 vsel);
...and, if an array is preferred, length can be set as:
int set_opp_table_length (u8 max);
I'm all for dynamic OPP setting, but not as an array. A
list should
probably be used.
Won't a list implementation cause more than necessary
overhead? I agree
that something like set_opp_table_length probably might be
redundant in
that case.
If I were to extend the discussion from other thread on
toggling the
valid OPPs
based on enable_off_mode, these could be handy.
int set_opp_valid(bool flag);
bool is_opp_valid(void);
Yes, we need a concept of a valid OPP, not just for OFF
mode, but for
OSWR and possibly for a full constraint framework as well.
Ack.
Even though above approach is possibly better a simple fix
could be just adding a flag in the structure (OPP
valid/invalid) and populating this flag run time using CPU type.
[sp] This is exactly in the original patch.
OK
Regards,
Santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHv3 0/1] Runtime detection of Si features
-Original Message- From: Premi, Sanjeev Sent: Thursday, October 01, 2009 10:55 PM To: linux-omap@vger.kernel.org Cc: Premi, Sanjeev Subject: [PATCHv3 0/1] Runtime detection of Si features This version is essentially same patch as [1]; but refreshed against the tip (2bf0f78). The change in text corresponding to the closing #endif in cpu.h required change in the last line of the patch. [1] http://patchwork.kernel.org/patch/41989/ Sanjeev Premi (1): Runtime detection of Si features arch/arm/mach-omap2/id.c | 52 +++-- arch/arm/mach-omap2/mmc-twl4030.c |1 + arch/arm/plat-omap/include/mach/control.h | 34 +++ arch/arm/plat-omap/include/mach/cpu.h | 23 + 4 files changed, 107 insertions(+), 3 deletions(-) Tony, Where does this stand in your queue? Best regards, Sanjeev-- To unsubscribe from this list: send the line unsubscribe 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]PM: Initialization of SDRC params for DVFS on Zoom2
Kevin,Jean
Sorry for the late reply.
I have tested DVFS on Zoom2 with 256Mb with this patch and it works fine.
In Zoom2 SDRC module uses 2 chip selects. Since u-boot is configuring the SDRC
module to use 2 chip selects do we need to configure it in the kernel as well?
If you think so then this change is needed.
Regards
Teerth
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Wednesday, September 30, 2009 11:36 PM
To: Reddy, Teerth
Cc: linux-omap@vger.kernel.org; Jean Pihet
Subject: Re: [PATCH]PM: Initialization of SDRC params for DVFS on Zoom2
Teerth, ping.
On Wed, Sep 9, 2009 at 5:12 AM, Jean Pihet jpi...@mvista.com wrote:
On Wednesday 09 September 2009 00:17:42 Kevin Hilman wrote:
Reddy, Teerth tee...@ti.com writes:
This patch initializes the SDRC params for DVFS on Zoom2.
Signed-off-by: Teerth Reddy tee...@ti.com
---
arch/arm/mach-omap2/board-zoom2.c | 6 --
1 files changed, 4 insertions(+), 2 deletions(-)
Index: linux-omap-pm/arch/arm/mach-omap2/board-zoom2.c
===
--- linux-omap-pm.orig/arch/arm/mach-omap2/board-zoom2.c
+++ linux-omap-pm/arch/arm/mach-omap2/board-zoom2.c
@@ -23,6 +23,7 @@
#include mmc-twl4030.h
#include omap3-opp.h
+#include sdram-micron-mt46h32m32lf-6.h
static struct omap_uart_config zoom2_uart_config __initdata = {
.enabled_uarts = ((1 0) | (1 1) | (1 2)),
@@ -36,8 +37,9 @@ 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, omap3_mpu_rate_table,
- omap3_dsp_rate_table, omap3_l3_rate_table);
+ omap2_init_common_hw(mt46h32m32lf6_sdrc_params, NULL,
+ omap3_mpu_rate_table, omap3_dsp_rate_table,
+ omap3_l3_rate_table);
Not having looked at the Zoom2 schematics, are you sure this is only
using a single chip select? The other boards using the same part
(beagle, overo) are interfacing to this part using both CSes.
Have you tested DVFS on Zoom2 using the full 256Mb?
Good point!
DVFS works fine using the two chip selects:
omap2_init_common_hw(mt46h32m32lf6_sdrc_params,
mt46h32m32lf6_sdrc_params,
omap3_mpu_rate_table,
omap3_dsp_rate_table,
omap3_l3_rate_table);
One remark though: since the memory chips are popped on top of the OMAP chip
the schematics are not showing the chip selects connections. In any case
U-Boot is configuring the SDRC module to use the 2 chip selects, so I think
this change is needed.
We need confirmation. Anyone from TI knows?
Regards,
Jean
Kevin
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
--
To unsubscribe from this list: send the line unsubscribe 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: Question on OPP table handling
Premi, Sanjeev had written, on 10/06/2009 03:52 AM, the following:
+ {0, 0, 0},
+ /*OPP1*/
+ {S125M, VDD1_OPP1, 0x1E},
+ /*OPP2*/
+ {S250M, VDD1_OPP2, 0x26},
+ /*OPP3*/
+ {S500M, VDD1_OPP3, 0x30},
+ /*OPP4*/
+ {S550M, VDD1_OPP4, 0x36},
+ /*OPP5*/
+ {S600M, VDD1_OPP5, 0x3C},
+};
For those involved,
if we wanted to convert omap3_mpu_table[] into
*omap3_mpu_table so that
we dynamically initialize it based on cpu type - what
would be the
recommendations?
Nishanth,
Good idea!
As a table, previous patch enables it (not as intent, but due to
syntax):
+/* struct omap_opp_table - View OPP table as an object
+ * @min: Minimum OPP id
+ * @max: Maximim OPP id
+ * @opps: Pointer to array defining the OPPs.
+ *
+ * An OPP table has varied length. Knowing minimum
and maximum
+ * OPP ids allow easy traversal.
+ */
+struct omap_opp_table {
+ u8 min;
+ u8 max;
+ struct omap_opp* opps;
+};
But now, I think it would be good to have an API that can fill an
opp_table:
int add_opp_definition(u8 id, u32 freq, u16 vsel);
...and, if an array is preferred, length can be set as:
int set_opp_table_length (u8 max);
I'm all for dynamic OPP setting, but not as an array. A
list should
probably be used.
Won't a list implementation cause more than necessary
overhead? I agree
that something like set_opp_table_length probably might be
redundant in
that case.
I'm aligned with Nishanth. I think a static table with the
possibility to disable some entry is good enough to deal with
most of the OPPs we have on OMAP3 and we will have to handle on OMAP4.
OPPs are defined during silicon characterization, and should
not be changed dynamically (in theory).
[sp] The intent of 'dynamic' is not with respect to changing the
OPPs but manitaining OPPs in an array or a list.
This is to take care of possibility that an OPP is not
applicable for specific devices. E.g. OPP5 was earlier
considered 'overdrive'; and the code had a small 'hack'
to prevent this OPP being used during cpufreq.
Marking the OPP 'disabled/invalid' in the table would have
been a better solution.
In a 'list' implementation, the node corresponding to such
OPPs can be removed from the 'active' list.
Couple of opinions on why a list with disabled/invalid marker might not
make sense as a grand unified OPP table:
a) it is no better than a list implementation
b) it is a waste of memory.
c) search Algo overheads
Recommendation a.k.a hybrid approach:
* Each silicon has it's own static OPP table
* Each table has a invalid marker which is disabled for silicon variants
which dont need specific OPPs
* OPPs table be stored in a hash table a.k.a how do we optimize search
for OPP params?
--
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] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430
Gopinath, Thara had written, on 10/06/2009 01:59 AM, the following: The problem here is not with the restore. If MPU reads the PADCONF_SAVEDONE bit very close to the end of context save sequence for the pad conf registers, the last context is not saved to the scratchpad memory. This is a h/w bug. The workaround proposed is to delay the MPU access of SAVEDONE bit until the last context has been saved. 300 us delay is the current safe delay proposed by TI. I believe investigations are going on to whether this delay can be optimized. Also only the last context (ETK_D14) has the risk of not getting saved. So, if I were to save specifically the ETK14 and restore it explicitly, I could in theory work around this issue. We could add a defconfig option for this workaround and enable it on need basis till TI comes out with proper optimized workaround sequence. we could probably hope to see a final patch then I believe? 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: Question on OPP table handling
Couple of opinions on why a list with disabled/invalid marker might not make sense as a grand unified OPP table: a) it is no better than a list implementation b) it is a waste of memory. [Romit] Put all the OPP tables for different OPPs in __initdata. Copy the runtime detected CPU's OPP table in memory. Others get discarded! -- To unsubscribe from this list: send the line unsubscribe 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: Question on OPP table handling
Dasgupta, Romit had written, on 10/06/2009 07:00 AM, the following: Couple of opinions on why a list with disabled/invalid marker might not make sense as a grand unified OPP table: a) it is no better than a list implementation b) it is a waste of memory. [Romit] Put all the OPP tables for different OPPs in __initdata. Copy the runtime detected CPU's OPP table in memory. Others get discarded! I like this approach.. takers? -- 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: Question on OPP table handling
-Original Message- From: Menon, Nishanth Sent: Tuesday, October 06, 2009 2:04 PM To: Dasgupta, Romit Cc: Premi, Sanjeev; Cousson, Benoit; Kevin H; linux-omap@vger.kernel.org Subject: Re: Question on OPP table handling Dasgupta, Romit had written, on 10/06/2009 07:00 AM, the following: Couple of opinions on why a list with disabled/invalid marker might not make sense as a grand unified OPP table: a) it is no better than a list implementation b) it is a waste of memory. [Romit] Put all the OPP tables for different OPPs in __initdata. Copy the runtime detected CPU's OPP table in memory. Others get discarded! I like this approach.. takers? I think it is not enough. Some OPPs will be selected based on runtime CPU detection, but some OPPs might be disabled dynamically for some usecase depending of external parameters. Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Question on OPP table handling
Dasgupta, Romit had written, on 10/06/2009 07:00 AM, the following: Couple of opinions on why a list with disabled/invalid marker might not make sense as a grand unified OPP table: a) it is no better than a list implementation b) it is a waste of memory. [Romit] Put all the OPP tables for different OPPs in __initdata. Copy the runtime detected CPU's OPP table in memory. Others get discarded! I like this approach.. takers? I think it is not enough. Some OPPs will be selected based on runtime CPU detection, but some OPPs might be disabled dynamically for some usecase depending of external parameters. [Romit] For a given SoC and type you can have only one OPP table. Isn't that true? -- To unsubscribe from this list: send the line unsubscribe 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: Question on OPP table handling
Typo I meant Put all the OPP tables for different CPUs (instead ofOPPs) in __initdata. Copy the run time detected CPU's OPP table in memory. Others get discarded! -Original Message- From: Menon, Nishanth Sent: Tuesday, October 06, 2009 5:34 PM To: Dasgupta, Romit Cc: Premi, Sanjeev; Cousson, Benoit; Kevin H; linux-omap@vger.kernel.org Subject: Re: Question on OPP table handling Dasgupta, Romit had written, on 10/06/2009 07:00 AM, the following: Couple of opinions on why a list with disabled/invalid marker might not make sense as a grand unified OPP table: a) it is no better than a list implementation b) it is a waste of memory. [Romit] Put all the OPP tables for different OPPs in __initdata. Copy the runtime detected CPU's OPP table in memory. Others get discarded! I like this approach.. takers? -- 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: Question on OPP table handling
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Dasgupta, Romit Sent: Tuesday, October 06, 2009 5:51 PM To: Menon, Nishanth Cc: Premi, Sanjeev; Cousson, Benoit; Kevin H; linux-omap@vger.kernel.org Subject: RE: Question on OPP table handling Typo I meant Put all the OPP tables for different CPUs (instead ofOPPs) in __initdata. Copy the run time detected CPU's OPP table in memory. Others get discarded! This is a good idea. Or if we want to save the _Copy_ effort, then make all these opp table structures as 'const' so that it get moved to *.RO section. In that case all data is still available. -- To unsubscribe from this list: send the line unsubscribe 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: Question on OPP table handling
-Original Message- From: Dasgupta, Romit Sent: Tuesday, October 06, 2009 2:14 PM To: Cousson, Benoit; Menon, Nishanth Cc: Premi, Sanjeev; Kevin H; linux-omap@vger.kernel.org Subject: RE: Question on OPP table handling Dasgupta, Romit had written, on 10/06/2009 07:00 AM, the following: Couple of opinions on why a list with disabled/invalid marker might not make sense as a grand unified OPP table: a) it is no better than a list implementation b) it is a waste of memory. [Romit] Put all the OPP tables for different OPPs in __initdata. Copy the runtime detected CPU's OPP table in memory. Others get discarded! I like this approach.. takers? I think it is not enough. Some OPPs will be selected based on runtime CPU detection, but some OPPs might be disabled dynamically for some usecase depending of external parameters. [Romit] For a given SoC and type you can have only one OPP table. Isn't that true? 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. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP: Fix Unlikely(x) y
The closing parenthesis was not on the right location.
Signed-off-by: Roel Kluin roel.kl...@gmail.com
---
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index 71ebd7f..7c345b7 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -373,7 +373,7 @@ static inline int gpio_valid(int gpio)
static int check_gpio(int gpio)
{
- if (unlikely(gpio_valid(gpio)) 0) {
+ if (unlikely(gpio_valid(gpio) 0)) {
printk(KERN_ERR omap-gpio: invalid GPIO %d\n, gpio);
dump_stack();
return -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
Re: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430
Gopinath, Thara th...@ti.com writes: The problem here is not with the restore. If MPU reads the PADCONF_SAVEDONE bit very close to the end of context save sequence for the pad conf registers, the last context is not saved to the scratchpad memory. This is a h/w bug. The workaround proposed is to delay the MPU access of SAVEDONE bit until the last context has been saved. 300 us delay is the current safe delay proposed by TI. I believe investigations are going on to whether this delay can be optimized. Also only the last context (ETK_D14) has the risk of not getting saved. All of this should've been in the original changelog. These are the details that help others understand the problem trying to be solved and think about whether there might be other solutions. We could add a defconfig option for this workaround and enable it on need basis till TI comes out with proper optimized workaround sequence. No, Kconfig is not an option for this. I think Nishanth's proposal is a much better workaround for this problem, and doesn't introduce and additional 300 usec delay to *every* off-mode transistion. Kevin -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Menon, Nishanth Sent: Monday, October 05, 2009 10:58 PM To: Kevin Hilman Cc: linux-omap@vger.kernel.org; Gulati, Shweta Subject: Re: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430 Kevin Hilman had written, on 10/05/2009 12:04 PM, the following: y...@india.ti.com writes: From: Shweta Gulati shweta.gul...@ti.com Please add descriptive changelog, including Erratta number and summary of the bug. Signed-off-by: Shweta Gulati shweta.gul...@ti.com --- arch/arm/mach-omap2/pm34xx.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index a9eda25..38f4781 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -140,6 +140,12 @@ static void omap3_core_save_context(void) omap_ctrl_readl(OMAP343X_CONTROL_PADCONF_OFF); control_padconf_off |= START_PADCONF_SAVE; omap_ctrl_writel(control_padconf_off, OMAP343X_CONTROL_PADCONF_OFF); + /* Due to Silicon Bug on context restore it is found + * that the CONTROL_PAD_CONF_ETK14 register is not saved into + * scratch pad memory sometimes. To rectify it delay acess by Mpu + * for 300us for scm to finish saving task + */ + udelay(300); Why 300 usecs? 300uSec could be optimized as I understand. Is ETK14 the only register not saved? The bug as I understand is that the register is saved, but restore potentially can corrupt the values. there is an alternative implementation possible: a) we save the register in a seperate variable b) we allow the restore issue to kick us (essentially allow it to be corrupted) c) we over write the restored value with the saved value. This has the risk of a glitch on the line (between the corrupted restore data to the time we restore with correct data). -- 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 -- To unsubscribe from this list: send the line unsubscribe 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]PM: Initialization of SDRC params for DVFS on Zoom2
Reddy, Teerth tee...@ti.com writes:
Kevin,Jean
Sorry for the late reply.
I have tested DVFS on Zoom2 with 256Mb with this patch and it works fine.
In Zoom2 SDRC module uses 2 chip selects. Since u-boot is configuring the
SDRC module to use 2 chip selects do we need to configure it in the kernel as
well?
If you think so then this change is needed.
Yes, otherwise the settings for the 2nd CS will not be modified during
DVFS and DVFS will not work properly when using both CSes.
Kevin
Regards
Teerth
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Wednesday, September 30, 2009 11:36 PM
To: Reddy, Teerth
Cc: linux-omap@vger.kernel.org; Jean Pihet
Subject: Re: [PATCH]PM: Initialization of SDRC params for DVFS on Zoom2
Teerth, ping.
On Wed, Sep 9, 2009 at 5:12 AM, Jean Pihet jpi...@mvista.com wrote:
On Wednesday 09 September 2009 00:17:42 Kevin Hilman wrote:
Reddy, Teerth tee...@ti.com writes:
This patch initializes the SDRC params for DVFS on Zoom2.
Signed-off-by: Teerth Reddy tee...@ti.com
---
arch/arm/mach-omap2/board-zoom2.c | 6 --
1 files changed, 4 insertions(+), 2 deletions(-)
Index: linux-omap-pm/arch/arm/mach-omap2/board-zoom2.c
===
--- linux-omap-pm.orig/arch/arm/mach-omap2/board-zoom2.c
+++ linux-omap-pm/arch/arm/mach-omap2/board-zoom2.c
@@ -23,6 +23,7 @@
#include mmc-twl4030.h
#include omap3-opp.h
+#include sdram-micron-mt46h32m32lf-6.h
static struct omap_uart_config zoom2_uart_config __initdata = {
.enabled_uarts = ((1 0) | (1 1) | (1 2)),
@@ -36,8 +37,9 @@ 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, omap3_mpu_rate_table,
- omap3_dsp_rate_table, omap3_l3_rate_table);
+ omap2_init_common_hw(mt46h32m32lf6_sdrc_params, NULL,
+ omap3_mpu_rate_table, omap3_dsp_rate_table,
+ omap3_l3_rate_table);
Not having looked at the Zoom2 schematics, are you sure this is only
using a single chip select? The other boards using the same part
(beagle, overo) are interfacing to this part using both CSes.
Have you tested DVFS on Zoom2 using the full 256Mb?
Good point!
DVFS works fine using the two chip selects:
omap2_init_common_hw(mt46h32m32lf6_sdrc_params,
mt46h32m32lf6_sdrc_params,
omap3_mpu_rate_table,
omap3_dsp_rate_table,
omap3_l3_rate_table);
One remark though: since the memory chips are popped on top of the OMAP chip
the schematics are not showing the chip selects connections. In any case
U-Boot is configuring the SDRC module to use the 2 chip selects, so I think
this change is needed.
We need confirmation. Anyone from TI knows?
Regards,
Jean
Kevin
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
--
To unsubscribe from this list: send the line unsubscribe 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] OMAP3: DVFS: No sdrc AC timing changes during core dvfs
This patch removes the SDRC AC timings changes done during core dvfs. Updating AC timing CTRL values for SDRC during DVFS is seen to be a risk, while the RFR CTRL value is safe to be updated. Signed-off-by: Rajendra Nayak rna...@ti.com --- arch/arm/mach-omap2/clock34xx.c| 17 +++- arch/arm/mach-omap2/sram34xx.S | 44 +-- arch/arm/plat-omap/include/mach/sram.h |6 +--- arch/arm/plat-omap/sram.c | 18 4 files changed, 20 insertions(+), 65 deletions(-) diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c index d6b7eb6..6210200 100644 --- a/arch/arm/mach-omap2/clock34xx.c +++ b/arch/arm/mach-omap2/clock34xx.c @@ -893,19 +893,22 @@ static int omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned long rate) sdrc_cs1-rfr_ctrl, sdrc_cs1-actim_ctrla, sdrc_cs1-actim_ctrlb, sdrc_cs1-mr); + /* +* Only the SDRC RFRCTRL value is seen to be safe to be +* changed during dvfs. +* The ACTiming values are left unchanged and should be +* the ones programmed by the bootloader for higher OPP. +*/ if (sdrc_cs1) omap3_configure_core_dpll( new_div, unlock_dll, c, rate clk-rate, - sdrc_cs0-rfr_ctrl, sdrc_cs0-actim_ctrla, - sdrc_cs0-actim_ctrlb, sdrc_cs0-mr, - sdrc_cs1-rfr_ctrl, sdrc_cs1-actim_ctrla, - sdrc_cs1-actim_ctrlb, sdrc_cs1-mr); + sdrc_cs0-rfr_ctrl, sdrc_cs0-mr, + sdrc_cs1-rfr_ctrl, sdrc_cs1-mr); else omap3_configure_core_dpll( new_div, unlock_dll, c, rate clk-rate, - sdrc_cs0-rfr_ctrl, sdrc_cs0-actim_ctrla, - sdrc_cs0-actim_ctrlb, sdrc_cs0-mr, - 0, 0, 0, 0); + sdrc_cs0-rfr_ctrl, sdrc_cs0-mr, + 0, 0); return 0; } diff --git a/arch/arm/mach-omap2/sram34xx.S b/arch/arm/mach-omap2/sram34xx.S index 82aa4a3..fc84801 100644 --- a/arch/arm/mach-omap2/sram34xx.S +++ b/arch/arm/mach-omap2/sram34xx.S @@ -83,12 +83,8 @@ * before use by the code in SRAM (SDRAM is not accessible during SDRC * reconfiguration): * new SDRC_RFR_CTRL_0 register contents - * new SDRC_ACTIM_CTRL_A_0 register contents - * new SDRC_ACTIM_CTRL_B_0 register contents * new SDRC_MR_0 register value * new SDRC_RFR_CTRL_1 register contents - * new SDRC_ACTIM_CTRL_A_1 register contents - * new SDRC_ACTIM_CTRL_B_1 register contents * new SDRC_MR_1 register value * * If the param SDRC_RFR_CTRL_1 is 0, the parameters @@ -102,20 +98,12 @@ ENTRY(omap3_sram_configure_core_dpll) ldr r4, [sp, #52] str r4, omap_sdrc_rfr_ctrl_0_val ldr r4, [sp, #56] - str r4, omap_sdrc_actim_ctrl_a_0_val - ldr r4, [sp, #60] - str r4, omap_sdrc_actim_ctrl_b_0_val - ldr r4, [sp, #64] str r4, omap_sdrc_mr_0_val - ldr r4, [sp, #68] + ldr r4, [sp, #60] str r4, omap_sdrc_rfr_ctrl_1_val cmp r4, #0 @ if SDRC_RFR_CTRL_1 is 0, beq skip_cs1_params @ do not use cs1 params - ldr r4, [sp, #72] - str r4, omap_sdrc_actim_ctrl_a_1_val - ldr r4, [sp, #76] - str r4, omap_sdrc_actim_ctrl_b_1_val - ldr r4, [sp, #80] + ldr r4, [sp, #64] str r4, omap_sdrc_mr_1_val skip_cs1_params: dsb @ flush buffered writes to interconnect @@ -219,12 +207,6 @@ configure_sdrc: ldr r12, omap_sdrc_rfr_ctrl_0_val @ fetch value from SRAM ldr r11, omap3_sdrc_rfr_ctrl_0 @ fetch addr from SRAM str r12, [r11] @ store - ldr r12, omap_sdrc_actim_ctrl_a_0_val - ldr r11, omap3_sdrc_actim_ctrl_a_0 - str r12, [r11] - ldr r12, omap_sdrc_actim_ctrl_b_0_val - ldr r11, omap3_sdrc_actim_ctrl_b_0 - str r12, [r11] ldr r12, omap_sdrc_mr_0_val ldr r11, omap3_sdrc_mr_0 str r12, [r11] @@ -233,12 +215,6 @@ configure_sdrc: beq skip_cs1_prog @ do not program cs1 params ldr r11, omap3_sdrc_rfr_ctrl_1 str r12, [r11] - ldr r12, omap_sdrc_actim_ctrl_a_1_val - ldr r11, omap3_sdrc_actim_ctrl_a_1 - str r12, [r11] - ldr r12, omap_sdrc_actim_ctrl_b_1_val - ldr r11, omap3_sdrc_actim_ctrl_b_1 - str r12, [r11] ldr r12, omap_sdrc_mr_1_val ldr r11, omap3_sdrc_mr_1 str r12, [r11] @@ -259,14 +235,6 @@
Re: Question on OPP table handling
Cousson, Benoit b-cous...@ti.com writes:
Hi Kevin,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Nishanth Menon
Sent: Monday, October 05, 2009 7:19 PM
To: linux-omap@vger.kernel.org
Cc: Premi, Sanjeev; Kevin H
Subject: Re: Question on OPP table handling
Kevin Hilman had written, on 10/05/2009 11:56 AM, the following:
Premi, Sanjeev pr...@ti.com writes:
-Original Message-
From: Nishanth Menon [mailto:menon.nisha...@gmail.com]
Sent: Saturday, October 03, 2009 8:35 PM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org
Subject: Question on OPP table handling
Sanjeev Premi said the following on 10/01/2009 01:03 PM:
+struct omap_opp omap3_mpu_rate_table[] = {
+ {0, 0, 0},
+ /*OPP1*/
+ {S125M, VDD1_OPP1, 0x1E},
+ /*OPP2*/
+ {S250M, VDD1_OPP2, 0x26},
+ /*OPP3*/
+ {S500M, VDD1_OPP3, 0x30},
+ /*OPP4*/
+ {S550M, VDD1_OPP4, 0x36},
+ /*OPP5*/
+ {S600M, VDD1_OPP5, 0x3C},
+};
For those involved,
if we wanted to convert omap3_mpu_table[] into
*omap3_mpu_table so that
we dynamically initialize it based on cpu type - what would be the
recommendations?
Nishanth,
Good idea!
As a table, previous patch enables it (not as intent, but due to
syntax):
+/* struct omap_opp_table - View OPP table as an object
+ * @min: Minimum OPP id
+ * @max: Maximim OPP id
+ * @opps: Pointer to array defining the OPPs.
+ *
+ * An OPP table has varied length. Knowing minimum and maximum
+ * OPP ids allow easy traversal.
+ */
+struct omap_opp_table {
+ u8 min;
+ u8 max;
+ struct omap_opp* opps;
+};
But now, I think it would be good to have an API that can fill an
opp_table:
int add_opp_definition(u8 id, u32 freq, u16 vsel);
...and, if an array is preferred, length can be set as:
int set_opp_table_length (u8 max);
I'm all for dynamic OPP setting, but not as an array. A list should
probably be used.
Won't a list implementation cause more than necessary overhead? I agree
that something like set_opp_table_length probably might be redundant in
that case.
I'm aligned with Nishanth. I think a static table with the possibility to
disable some entry is good enough to deal with most of the OPPs we have on
OMAP3 and we will have to handle on OMAP4.
OPPs are defined during silicon characterization, and should not be changed
dynamically (in theory).
Do you have something in mind that might justify a dynamic management?
Ultimately, I don't really care what the data structure used is.
My primary concern is that at run-time (not just boot time) OPPs can
be disabled/invalidated so that they are not available to DVFS.
There are many reasons for this
- chip bugs
- CPUfreq policies can disable/enable certain OPPs
- speed-rated silicon
- thermal management
- etc.
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] OMAP3: SRF: Fix latency resource target value computations
The Shared resource framework currently considers the highest requested
level for a resource as the target level to be set. This works for OPP
and frequency resources as they are used to model performace based
constraints. However for latency based constraints/resources the least requested
level should be the one considered for the target level. This patch fixes
the issue by having an additional flag to identify the different types
of resources. Currently supported ones are Performace resources and
latency resources.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/resource34xx.c |4 ++--
arch/arm/mach-omap2/resource34xx.h | 16
arch/arm/plat-omap/include/mach/resource.h |9 -
arch/arm/plat-omap/resource.c | 20 ++--
4 files changed, 40 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/resource34xx.c
b/arch/arm/mach-omap2/resource34xx.c
index 491e1dc..e1a540e 100644
--- a/arch/arm/mach-omap2/resource34xx.c
+++ b/arch/arm/mach-omap2/resource34xx.c
@@ -41,7 +41,7 @@
void init_latency(struct shared_resource *resp)
{
resp-no_of_users = 0;
- resp-curr_level = RES_DEFAULTLEVEL;
+ resp-curr_level = RES_LATENCY_DEFAULTLEVEL;
*((u8 *)resp-resource_data) = 0;
return;
}
@@ -65,7 +65,7 @@ int set_latency(struct shared_resource *resp, u32 latency)
resp-curr_level = latency;
pm_qos_req_added = resp-resource_data;
- if (latency == RES_DEFAULTLEVEL)
+ if (latency == RES_LATENCY_DEFAULTLEVEL)
/* No more users left, remove the pm_qos_req if present */
if (*pm_qos_req_added) {
pm_qos_remove_requirement(PM_QOS_CPU_DMA_LATENCY,
diff --git a/arch/arm/mach-omap2/resource34xx.h
b/arch/arm/mach-omap2/resource34xx.h
index 3c70eef..918a76c 100644
--- a/arch/arm/mach-omap2/resource34xx.h
+++ b/arch/arm/mach-omap2/resource34xx.h
@@ -49,6 +49,7 @@ static struct shared_resource_ops lat_res_ops = {
static struct shared_resource mpu_latency = {
.name = mpu_latency,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+ .flags = RES_TYPE_LATENCY,
.resource_data = mpu_qos_req_added,
.ops= lat_res_ops,
};
@@ -56,6 +57,7 @@ static struct shared_resource mpu_latency = {
static struct shared_resource core_latency = {
.name = core_latency,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+ .flags = RES_TYPE_LATENCY,
.resource_data = core_qos_req_added,
.ops= lat_res_ops,
};
@@ -91,6 +93,7 @@ static struct shared_resource_ops pd_lat_res_ops = {
static struct shared_resource core_pwrdm_latency = {
.name = core_pwrdm_latency,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+ .flags = RES_TYPE_LATENCY,
.resource_data = core_qos_req_added,
.ops= lat_res_ops,
};
@@ -106,6 +109,7 @@ static struct pd_latency_db iva2_pwrdm_lat_db = {
static struct shared_resource iva2_pwrdm_latency = {
.name = iva2_pwrdm_latency,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+ .flags = RES_TYPE_LATENCY,
.resource_data = iva2_pwrdm_lat_db,
.ops= pd_lat_res_ops,
};
@@ -129,6 +133,7 @@ static struct pd_latency_db sgx_pwrdm_lat_db = {
static struct shared_resource gfx_pwrdm_latency = {
.name = gfx_pwrdm_latency,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES1),
+ .flags = RES_TYPE_LATENCY,
.resource_data = gfx_pwrdm_lat_db,
.ops= pd_lat_res_ops,
};
@@ -136,6 +141,7 @@ static struct shared_resource gfx_pwrdm_latency = {
static struct shared_resource sgx_pwrdm_latency = {
.name = sgx_pwrdm_latency,
.omap_chip = OMAP_CHIP_INIT(CHIP_GE_OMAP3430ES2),
+ .flags = RES_TYPE_LATENCY,
.resource_data = sgx_pwrdm_lat_db,
.ops= pd_lat_res_ops,
};
@@ -151,6 +157,7 @@ static struct pd_latency_db dss_pwrdm_lat_db = {
static struct shared_resource dss_pwrdm_latency = {
.name = dss_pwrdm_latency,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+ .flags = RES_TYPE_LATENCY,
.resource_data = dss_pwrdm_lat_db,
.ops= pd_lat_res_ops,
};
@@ -166,6 +173,7 @@ static struct pd_latency_db cam_pwrdm_lat_db = {
static struct shared_resource cam_pwrdm_latency = {
.name = cam_pwrdm_latency,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+ .flags = RES_TYPE_LATENCY,
.resource_data = cam_pwrdm_lat_db,
.ops= pd_lat_res_ops,
};
@@ -181,6 +189,7 @@ static struct pd_latency_db per_pwrdm_lat_db = {
static struct shared_resource per_pwrdm_latency = {
.name
RE: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430
-Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Tuesday, October 06, 2009 6:47 PM To: Gopinath, Thara Cc: Menon, Nishanth; linux-omap@vger.kernel.org; Gulati, Shweta Subject: Re: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430 Gopinath, Thara th...@ti.com writes: The problem here is not with the restore. If MPU reads the PADCONF_SAVEDONE bit very close to the end of context save sequence for the pad conf registers, the last context is not saved to the scratchpad memory. This is a h/w bug. The workaround proposed is to delay the MPU access of SAVEDONE bit until the last context has been saved. 300 us delay is the current safe delay proposed by TI. I believe investigations are going on to whether this delay can be optimized. Also only the last context (ETK_D14) has the risk of not getting saved. All of this should've been in the original changelog. These are the details that help others understand the problem trying to be solved and think about whether there might be other solutions. We could add a defconfig option for this workaround and enable it on need basis till TI comes out with proper optimized workaround sequence. No, Kconfig is not an option for this. I think Nishanth's proposal is a much better workaround for this problem, and doesn't introduce and additional 300 usec delay to *every* off-mode transistion. I am not very sure about this as it has the risk of glitch on the line. It is probably ok if the ball is not used. But if in use, the glitch could create issues. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]PM: Initialization of SDRC params for DVFS on Zoom2
Reddy, Teerth tee...@ti.com writes:
Kevin,Jean
Sorry for the late reply.
I have tested DVFS on Zoom2 with 256Mb with this patch and it works fine.
In Zoom2 SDRC module uses 2 chip selects. Since u-boot is configuring the
SDRC module to use 2 chip selects do we need to configure it in the kernel as
well?
If you think so then this change is needed.
Teerth,
Please break this up into two patches.
1) for linux-omap master: add the SDRC params for both CSes to init_common_hw
2) for PM branch: addition of rate tables for DVFS
Thanks,
Regards
Teerth
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Wednesday, September 30, 2009 11:36 PM
To: Reddy, Teerth
Cc: linux-omap@vger.kernel.org; Jean Pihet
Subject: Re: [PATCH]PM: Initialization of SDRC params for DVFS on Zoom2
Teerth, ping.
On Wed, Sep 9, 2009 at 5:12 AM, Jean Pihet jpi...@mvista.com wrote:
On Wednesday 09 September 2009 00:17:42 Kevin Hilman wrote:
Reddy, Teerth tee...@ti.com writes:
This patch initializes the SDRC params for DVFS on Zoom2.
Signed-off-by: Teerth Reddy tee...@ti.com
---
arch/arm/mach-omap2/board-zoom2.c | 6 --
1 files changed, 4 insertions(+), 2 deletions(-)
Index: linux-omap-pm/arch/arm/mach-omap2/board-zoom2.c
===
--- linux-omap-pm.orig/arch/arm/mach-omap2/board-zoom2.c
+++ linux-omap-pm/arch/arm/mach-omap2/board-zoom2.c
@@ -23,6 +23,7 @@
#include mmc-twl4030.h
#include omap3-opp.h
+#include sdram-micron-mt46h32m32lf-6.h
static struct omap_uart_config zoom2_uart_config __initdata = {
.enabled_uarts = ((1 0) | (1 1) | (1 2)),
@@ -36,8 +37,9 @@ 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, omap3_mpu_rate_table,
- omap3_dsp_rate_table, omap3_l3_rate_table);
+ omap2_init_common_hw(mt46h32m32lf6_sdrc_params, NULL,
+ omap3_mpu_rate_table, omap3_dsp_rate_table,
+ omap3_l3_rate_table);
Not having looked at the Zoom2 schematics, are you sure this is only
using a single chip select? The other boards using the same part
(beagle, overo) are interfacing to this part using both CSes.
Have you tested DVFS on Zoom2 using the full 256Mb?
Good point!
DVFS works fine using the two chip selects:
omap2_init_common_hw(mt46h32m32lf6_sdrc_params,
mt46h32m32lf6_sdrc_params,
omap3_mpu_rate_table,
omap3_dsp_rate_table,
omap3_l3_rate_table);
One remark though: since the memory chips are popped on top of the OMAP chip
the schematics are not showing the chip selects connections. In any case
U-Boot is configuring the SDRC module to use the 2 chip selects, so I think
this change is needed.
We need confirmation. Anyone from TI knows?
Regards,
Jean
Kevin
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
--
To unsubscribe from this list: send the line unsubscribe 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] [OMAP1] mux: Add MMC mux pins for omap7xx
There are three mux pins needed for omap7xx that differ
from the other omap configurations. This change adds the
declarations into mux.c and mux.h.
Signed-off-by: Cory Maccarrone darkstar6...@gmail.com
---
arch/arm/mach-omap1/mux.c |5 +
arch/arm/plat-omap/include/mach/mux.h |5 +
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap1/mux.c b/arch/arm/mach-omap1/mux.c
index d59899d..feb6d8c 100644
--- a/arch/arm/mach-omap1/mux.c
+++ b/arch/arm/mach-omap1/mux.c
@@ -51,6 +51,11 @@ MUX_CFG_7XX(E3_7XX_KBC4,13, 25,0,
24, 1, 0)
MUX_CFG_7XX(AA17_7XX_USB_DM, 2, 21,0, 20, 0, 0)
MUX_CFG_7XX(W16_7XX_USB_PU_EN, 2, 25,0, 24, 0, 0)
MUX_CFG_7XX(W17_7XX_USB_VBUSI, 2, 29,0, 28, 0, 0)
+
+/* MMC Pins */
+MUX_CFG_7XX(MMC_7XX_CMD, 2,9,0,8, 1, 0)
+MUX_CFG_7XX(MMC_7XX_CLK, 2, 13,0, 12, 1, 0)
+MUX_CFG_7XX(MMC_7XX_DAT0,2, 17,0, 16, 1, 0)
};
#define OMAP7XX_PINS_SZARRAY_SIZE(omap7xx_pins)
#else
diff --git a/arch/arm/plat-omap/include/mach/mux.h
b/arch/arm/plat-omap/include/mach/mux.h
index f3c1d8a..56e357e 100644
--- a/arch/arm/plat-omap/include/mach/mux.h
+++ b/arch/arm/plat-omap/include/mach/mux.h
@@ -219,6 +219,11 @@ enum omap7xx_index {
AA17_7XX_USB_DM,
W16_7XX_USB_PU_EN,
W17_7XX_USB_VBUSI,
+
+ /* MMC */
+ MMC_7XX_CMD,
+ MMC_7XX_CLK,
+ MMC_7XX_DAT0,
};
enum omap1xxx_index {
--
1.5.6.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [OMAP] mmc: Add mux configuration for omap7xx
The MMC mux pins normally used by omap chips in devices.c
are different from what is needed by omap7xx chips. This
change adds a conditional around the mux setup code to
enable the correct mux pins.
Signed-off-by: Cory Maccarrone darkstar6...@gmail.com
---
arch/arm/mach-omap1/devices.c | 15 +++
1 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap1/devices.c b/arch/arm/mach-omap1/devices.c
index 0680843..54f18e8 100644
--- a/arch/arm/mach-omap1/devices.c
+++ b/arch/arm/mach-omap1/devices.c
@@ -108,15 +108,22 @@ static inline void omap1_mmc_mux(struct
omap_mmc_platform_data *mmc_controller,
int controller_nr)
{
if (controller_nr == 0) {
- omap_cfg_reg(MMC_CMD);
- omap_cfg_reg(MMC_CLK);
- omap_cfg_reg(MMC_DAT0);
+ if (cpu_is_omap7xx()) {
+ omap_cfg_reg(MMC_7XX_CMD);
+ omap_cfg_reg(MMC_7XX_CLK);
+ omap_cfg_reg(MMC_7XX_DAT0);
+ } else {
+ omap_cfg_reg(MMC_CMD);
+ omap_cfg_reg(MMC_CLK);
+ omap_cfg_reg(MMC_DAT0);
+ }
+
if (cpu_is_omap1710()) {
omap_cfg_reg(M15_1710_MMC_CLKI);
omap_cfg_reg(P19_1710_MMC_CMDDIR);
omap_cfg_reg(P20_1710_MMC_DATDIR0);
}
- if (mmc_controller-slots[0].wires == 4) {
+ if (mmc_controller-slots[0].wires == 4 !cpu_is_omap7xx()) {
omap_cfg_reg(MMC_DAT1);
/* NOTE: DAT2 can be on W10 (here) or M15 */
if (!mmc_controller-slots[0].nomux)
--
1.5.6.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430
Gopinath, Thara th...@ti.com writes: -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Tuesday, October 06, 2009 6:47 PM To: Gopinath, Thara Cc: Menon, Nishanth; linux-omap@vger.kernel.org; Gulati, Shweta Subject: Re: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430 Gopinath, Thara th...@ti.com writes: The problem here is not with the restore. If MPU reads the PADCONF_SAVEDONE bit very close to the end of context save sequence for the pad conf registers, the last context is not saved to the scratchpad memory. This is a h/w bug. The workaround proposed is to delay the MPU access of SAVEDONE bit until the last context has been saved. 300 us delay is the current safe delay proposed by TI. I believe investigations are going on to whether this delay can be optimized. Also only the last context (ETK_D14) has the risk of not getting saved. All of this should've been in the original changelog. These are the details that help others understand the problem trying to be solved and think about whether there might be other solutions. We could add a defconfig option for this workaround and enable it on need basis till TI comes out with proper optimized workaround sequence. No, Kconfig is not an option for this. I think Nishanth's proposal is a much better workaround for this problem, and doesn't introduce and additional 300 usec delay to *every* off-mode transistion. I am not very sure about this as it has the risk of glitch on the line. It is probably ok if the ball is not used. But if in use, the glitch could create issues. I don't follow. IIUC, Nishanth's proposal would be to In save context: - manually save ETK_D14 to some static variable (SDRAM) - initiate the padconf safe - poll SAVE_DONE - here ETK_D14 value saved by HW possibly corrupted, but the copy saved manually should be fine In restore: - manually restore ETK_D14 from the static variable What is wrong with this approach? Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430
-Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Tuesday, October 06, 2009 7:50 PM To: Gopinath, Thara Cc: Menon, Nishanth; linux-omap@vger.kernel.org; Gulati, Shweta Subject: Re: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430 Gopinath, Thara th...@ti.com writes: -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Tuesday, October 06, 2009 6:47 PM To: Gopinath, Thara Cc: Menon, Nishanth; linux-omap@vger.kernel.org; Gulati, Shweta Subject: Re: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430 Gopinath, Thara th...@ti.com writes: The problem here is not with the restore. If MPU reads the PADCONF_SAVEDONE bit very close to the end of context save sequence for the pad conf registers, the last context is not saved to the scratchpad memory. This is a h/w bug. The workaround proposed is to delay the MPU access of SAVEDONE bit until the last context has been saved. 300 us delay is the current safe delay proposed by TI. I believe investigations are going on to whether this delay can be optimized. Also only the last context (ETK_D14) has the risk of not getting saved. All of this should've been in the original changelog. These are the details that help others understand the problem trying to be solved and think about whether there might be other solutions. We could add a defconfig option for this workaround and enable it on need basis till TI comes out with proper optimized workaround sequence. No, Kconfig is not an option for this. I think Nishanth's proposal is a much better workaround for this problem, and doesn't introduce and additional 300 usec delay to *every* off-mode transistion. I am not very sure about this as it has the risk of glitch on the line. It is probably ok if the ball is not used. But if in use, the glitch could create issues. I don't follow. IIUC, Nishanth's proposal would be to In save context: - manually save ETK_D14 to some static variable (SDRAM) - initiate the padconf safe - poll SAVE_DONE - here ETK_D14 value saved by HW possibly corrupted, but the copy saved manually should be fine In restore: - manually restore ETK_D14 from the static variable What is wrong with this approach? In this approach there is a possibility that the h/w restore a wrong value to PADCONF_ETKD14. Now suppose this pin is in use and is supposed to be pulled high. And the proper save does not happen 1. Before going to Off - the pin is pulled high 2. Off 3. h/w restore - Has done bad save. So bad value restored. Say pull low. 4. Manual restore - the pin is again pulled high. Now there is a glitch between step 3 and 4. If this pin is not used by anybody we could live with this glitch. But considering this pin is muxed with gpio28/gpio29, hsusb_tll_data0/ hsusb_tll_data1 this glitch might be unacceptable. Regards Thara -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430
Gopinath, Thara th...@ti.com writes: -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Tuesday, October 06, 2009 7:50 PM To: Gopinath, Thara Cc: Menon, Nishanth; linux-omap@vger.kernel.org; Gulati, Shweta Subject: Re: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430 Gopinath, Thara th...@ti.com writes: -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Tuesday, October 06, 2009 6:47 PM To: Gopinath, Thara Cc: Menon, Nishanth; linux-omap@vger.kernel.org; Gulati, Shweta Subject: Re: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430 Gopinath, Thara th...@ti.com writes: The problem here is not with the restore. If MPU reads the PADCONF_SAVEDONE bit very close to the end of context save sequence for the pad conf registers, the last context is not saved to the scratchpad memory. This is a h/w bug. The workaround proposed is to delay the MPU access of SAVEDONE bit until the last context has been saved. 300 us delay is the current safe delay proposed by TI. I believe investigations are going on to whether this delay can be optimized. Also only the last context (ETK_D14) has the risk of not getting saved. All of this should've been in the original changelog. These are the details that help others understand the problem trying to be solved and think about whether there might be other solutions. We could add a defconfig option for this workaround and enable it on need basis till TI comes out with proper optimized workaround sequence. No, Kconfig is not an option for this. I think Nishanth's proposal is a much better workaround for this problem, and doesn't introduce and additional 300 usec delay to *every* off-mode transistion. I am not very sure about this as it has the risk of glitch on the line. It is probably ok if the ball is not used. But if in use, the glitch could create issues. I don't follow. IIUC, Nishanth's proposal would be to In save context: - manually save ETK_D14 to some static variable (SDRAM) - initiate the padconf safe - poll SAVE_DONE - here ETK_D14 value saved by HW possibly corrupted, but the copy saved manually should be fine In restore: - manually restore ETK_D14 from the static variable What is wrong with this approach? In this approach there is a possibility that the h/w restore a wrong value to PADCONF_ETKD14. Now suppose this pin is in use and is supposed to be pulled high. And the proper save does not happen 1. Before going to Off - the pin is pulled high 2. Off 3. h/w restore - Has done bad save. So bad value restored. Say pull low. 4. Manual restore - the pin is again pulled high. Now there is a glitch between step 3 and 4. If this pin is not used by anybody we could live with this glitch. But considering this pin is muxed with gpio28/gpio29, hsusb_tll_data0/ hsusb_tll_data1 this glitch might be unacceptable. I see now. Thanks for explanation. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430
Will repost the patch with the defconfig option added. So that this can be disabled if not needed. Regards Thara -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Tuesday, October 06, 2009 8:19 PM To: Gopinath, Thara Cc: Menon, Nishanth; linux-omap@vger.kernel.org; Gulati, Shweta Subject: Re: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430 Gopinath, Thara th...@ti.com writes: -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Tuesday, October 06, 2009 7:50 PM To: Gopinath, Thara Cc: Menon, Nishanth; linux-omap@vger.kernel.org; Gulati, Shweta Subject: Re: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430 Gopinath, Thara th...@ti.com writes: -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Tuesday, October 06, 2009 6:47 PM To: Gopinath, Thara Cc: Menon, Nishanth; linux-omap@vger.kernel.org; Gulati, Shweta Subject: Re: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430 Gopinath, Thara th...@ti.com writes: The problem here is not with the restore. If MPU reads the PADCONF_SAVEDONE bit very close to the end of context save sequence for the pad conf registers, the last context is not saved to the scratchpad memory. This is a h/w bug. The workaround proposed is to delay the MPU access of SAVEDONE bit until the last context has been saved. 300 us delay is the current safe delay proposed by TI. I believe investigations are going on to whether this delay can be optimized. Also only the last context (ETK_D14) has the risk of not getting saved. All of this should've been in the original changelog. These are the details that help others understand the problem trying to be solved and think about whether there might be other solutions. We could add a defconfig option for this workaround and enable it on need basis till TI comes out with proper optimized workaround sequence. No, Kconfig is not an option for this. I think Nishanth's proposal is a much better workaround for this problem, and doesn't introduce and additional 300 usec delay to *every* off-mode transistion. I am not very sure about this as it has the risk of glitch on the line. It is probably ok if the ball is not used. But if in use, the glitch could create issues. I don't follow. IIUC, Nishanth's proposal would be to In save context: - manually save ETK_D14 to some static variable (SDRAM) - initiate the padconf safe - poll SAVE_DONE - here ETK_D14 value saved by HW possibly corrupted, but the copy saved manually should be fine In restore: - manually restore ETK_D14 from the static variable What is wrong with this approach? In this approach there is a possibility that the h/w restore a wrong value to PADCONF_ETKD14. Now suppose this pin is in use and is supposed to be pulled high. And the proper save does not happen 1. Before going to Off - the pin is pulled high 2. Off 3. h/w restore - Has done bad save. So bad value restored. Say pull low. 4. Manual restore - the pin is again pulled high. Now there is a glitch between step 3 and 4. If this pin is not used by anybody we could live with this glitch. But considering this pin is muxed with gpio28/gpio29, hsusb_tll_data0/ hsusb_tll_data1 this glitch might be unacceptable. I see now. Thanks for explanation. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430
Gopinath, Thara th...@ti.com writes: Will repost the patch with the defconfig option added. So that this can be disabled if not needed. ok, please update the changelog as well as describe the 300usec value in terms of cycles. IOW, is 300usecs going to work at lower OPPs also? Kevin -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Tuesday, October 06, 2009 8:19 PM To: Gopinath, Thara Cc: Menon, Nishanth; linux-omap@vger.kernel.org; Gulati, Shweta Subject: Re: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430 Gopinath, Thara th...@ti.com writes: -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Tuesday, October 06, 2009 7:50 PM To: Gopinath, Thara Cc: Menon, Nishanth; linux-omap@vger.kernel.org; Gulati, Shweta Subject: Re: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430 Gopinath, Thara th...@ti.com writes: -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Tuesday, October 06, 2009 6:47 PM To: Gopinath, Thara Cc: Menon, Nishanth; linux-omap@vger.kernel.org; Gulati, Shweta Subject: Re: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430 Gopinath, Thara th...@ti.com writes: The problem here is not with the restore. If MPU reads the PADCONF_SAVEDONE bit very close to the end of context save sequence for the pad conf registers, the last context is not saved to the scratchpad memory. This is a h/w bug. The workaround proposed is to delay the MPU access of SAVEDONE bit until the last context has been saved. 300 us delay is the current safe delay proposed by TI. I believe investigations are going on to whether this delay can be optimized. Also only the last context (ETK_D14) has the risk of not getting saved. All of this should've been in the original changelog. These are the details that help others understand the problem trying to be solved and think about whether there might be other solutions. We could add a defconfig option for this workaround and enable it on need basis till TI comes out with proper optimized workaround sequence. No, Kconfig is not an option for this. I think Nishanth's proposal is a much better workaround for this problem, and doesn't introduce and additional 300 usec delay to *every* off-mode transistion. I am not very sure about this as it has the risk of glitch on the line. It is probably ok if the ball is not used. But if in use, the glitch could create issues. I don't follow. IIUC, Nishanth's proposal would be to In save context: - manually save ETK_D14 to some static variable (SDRAM) - initiate the padconf safe - poll SAVE_DONE - here ETK_D14 value saved by HW possibly corrupted, but the copy saved manually should be fine In restore: - manually restore ETK_D14 from the static variable What is wrong with this approach? In this approach there is a possibility that the h/w restore a wrong value to PADCONF_ETKD14. Now suppose this pin is in use and is supposed to be pulled high. And the proper save does not happen 1. Before going to Off - the pin is pulled high 2. Off 3. h/w restore - Has done bad save. So bad value restored. Say pull low. 4. Manual restore - the pin is again pulled high. Now there is a glitch between step 3 and 4. If this pin is not used by anybody we could live with this glitch. But considering this pin is muxed with gpio28/gpio29, hsusb_tll_data0/ hsusb_tll_data1 this glitch might be unacceptable. I see now. Thanks for explanation. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/8] omap: Lock DPLL5 at boot
On Fri, 2 Oct 2009, Tony Lindgren wrote: From: Rajendra Nayak rna...@ti.com Lock DPLL5 at 120MHz at boot. The USBHOST 120MHz f-clock and USBTLL f-clock are the only users of this DPLL, and 120MHz is is the only recommended rate for these clocks. With this patch, the 60 MHz ULPI clock is generated correctly. Tested on an OMAP3430 SDP. Signed-off-by: Rajendra Nayak rna...@ti.com Signed-off-by: Anand Gadiyar gadi...@ti.com Signed-off-by: Tony Lindgren t...@atomide.com Signed-off-by: Paul Walmsley p...@pwsan.com - 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] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430
-Original Message- From: Menon, Nishanth Sent: Tuesday, October 06, 2009 8:48 PM To: Kevin Hilman Cc: Gopinath, Thara; linux-omap@vger.kernel.org; Gulati, Shweta Subject: Re: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430 Kevin Hilman had written, on 10/06/2009 10:05 AM, the following: Gopinath, Thara th...@ti.com writes: Will repost the patch with the defconfig option added. So that this can be disabled if not needed. ok, please update the changelog as well as describe the 300usec value in terms of cycles. IOW, is 300usecs going to work at lower OPPs also? Could I request for 2 options: a) workaround with no delay (manual save restore) - power savings for boards which dont use the pin b) workaround with 300uSec - for boards which use the pin -functional How do we find out if the pin is functional or not? Also please have a check based on CPU revision and add errata number? I do not think this is yet published as an errata. -- 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] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430
Gopinath, Thara had written, on 10/06/2009 10:23 AM, the following: -Original Message- From: Menon, Nishanth Sent: Tuesday, October 06, 2009 8:48 PM To: Kevin Hilman Cc: Gopinath, Thara; linux-omap@vger.kernel.org; Gulati, Shweta Subject: Re: [PATCH] OMAP3: PM: Fix for Silicon bug on Context Restore on OMAP3430 Kevin Hilman had written, on 10/06/2009 10:05 AM, the following: Gopinath, Thara th...@ti.com writes: Will repost the patch with the defconfig option added. So that this can be disabled if not needed. ok, please update the changelog as well as describe the 300usec value in terms of cycles. IOW, is 300usecs going to work at lower OPPs also? Could I request for 2 options: a) workaround with no delay (manual save restore) - power savings for boards which dont use the pin b) workaround with 300uSec - for boards which use the pin -functional How do we find out if the pin is functional or not? I thought you are adding Kconfig option. leave it to the board defconfig to decide? Also please have a check based on CPU revision and add errata number? I do not think this is yet published as an errata. could we atleast mark it as an /* ERRATA YET TO BE NUMBERED... */ blah blah -- 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: [alsa-devel] [PATCHv3 1/7] OMAP4: PMIC: Add support for twl6030 codec
On Tue, Oct 06, 2009 at 11:46:05AM +0300, Peter Ujfalusi wrote: How does the twl4030 series would fit with this modification? I have also added the twl4030 codec as a child for the twl MFD, but I have not finished the cleanup of the codec fully. The TWL6030 specific bits all look good but this change ought to go via the MFD tree (probably as part of the big patch series adding twl6030 support that doesn't look to have been applied yet). Are people happy that the interface to the twl6030 won't change as a result of the twl4030 audio support? If so then I'll apply the ASoC side now, the Kconfig dependencies will stop it being built too soon. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [alsa-devel] [PATCHv3 1/7] OMAP4: PMIC: Add support for twl6030 codec
Peter Ujfalusi wrote:
On Tuesday 06 October 2009 10:29:39 ext Lopez Cruz, Misael wrote:
In order to have TWL6030 CODEC driver as a platform driver, codec
data should be passed through twl_platform_data structure.
For twl6030 audio codec, the following data may be passed:
- audpwron_gpio: gpio line used to power-up/down the codec. A
low-to-high transition powers codec up. Setting audpwron_gpio to a
negative value means that codec will use manual power sequence
instead of automatic sequence - naudint_irq: irq line for audio
interrupt. twl6030 drives NAUDINT line to low when an interrupt
(codec ready, plug insertion/removal, etc) is detected
However, codec driver can operate if any or none of them are passed.
How does the twl4030 series would fit with this modification?
I have also added the twl4030 codec as a child for the twl
MFD, but I have not finished the cleanup of the codec fully.
twl6030 codec data won't conflict with twl4030's as it's dependent of
TWL6030_CORE. We can add parallely the required data for twl4030 codec.
Signed-off-by: Misael Lopez Cruz x0052...@ti.com
---
drivers/mfd/twl-core.c | 15 +++
include/linux/i2c/twl.h |7 +++
2 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index af4cf47..6432af1 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -108,6 +108,12 @@
#define twl_has_mmc() false
#endif
+#if defined(CONFIG_SND_SOC_TWL6030) ||
defined(CONFIG_SND_SOC_TWL6030_MODULE) +#define
twl_has_codec() true +#else +#define twl_has_codec()false
+#endif
+
#if defined(CONFIG_TWL4030_USB) ||
defined(CONFIG_TWL4030_USB_MODULE)
#define twl_has_usb() true
#else
@@ -190,6 +196,7 @@
#define BCI_SUB_CHIP_ID SUB_CHIP_ID1
#define GPIO_SUB_CHIP_ID0 /* NOT SUPPORTED IN TWL6030 */
#define KEYPAD_SUB_CHIP_ID 0 /* ADDED FOR COMPILATION ONLY */
+#define CODEC_SUB_CHIP_ID SUB_CHIP_ID3
TWL4030 codec is under ID2 address group.
CODEC_SUB_CHIP_ID for twl6030 is under #ifdef CONFIG_TWL6030_CORE.
There are a different set of _CHIP_IDs for twl4030 children, which
doesn't have a definition for CODEC yet.
/* subchip/slave 0 0x48 - POWER */
#define TWL6030_BASEADD_RTC 0x
@@ -632,6 +639,14 @@ add_children(struct twl_platform_data *pdata,
unsigned long features) if (IS_ERR(child))
return PTR_ERR(child);
}
+
+if (twl_has_codec()) {
+child = add_child(CODEC_SUB_CHIP_ID, twl6030_codec,
+pdata-codec, sizeof(*pdata-codec), false,
+0, 0);
+if (IS_ERR(child))
+return PTR_ERR(child);
+}
We are going to have the twl4030 as child as well.
#endif
if (twl_has_usb() pdata-usb) {
diff --git a/include/linux/i2c/twl.h b/include/linux/i2c/twl.h index
b687a8b..e76ca9b 100644 --- a/include/linux/i2c/twl.h
+++ b/include/linux/i2c/twl.h
@@ -472,6 +472,12 @@ struct twl_usb_data {
enum twl_usb_mode usb_mode;
};
+struct twl_codec_data {
+/* twl6030 */
+int audpwron_gpio; /* audio power-on gpio */
+int naudint_irq;/* audio interrupt */
+};
These are not applicable for the twl4030 codec, should we
have different
twl_codec_data for twl6030 and twl4030 series?
Currently, the support for TWL4030 and TWL6030 makes them mutually
exclusive, TWL6030_CORE depends on !TWL4030_CORE. So we can have
separate twl_codec_data definitions to avoid unused space in the
structure.
Should I merge here the things which will be used for the twl4030
codec?
I think merging them would suit only if both twl versions can be
enabled at the same time, but not sure it that makes sense.
At the moment, I only have audio_mclk in my codec_data, but
most probably the HS ramp related things will be also merged here
in the future.
+
struct twl_platform_data {
unsignedirq_base, irq_end;
struct twl_bci_platform_data*bci;
@@ -479,6 +485,7 @@ struct twl_platform_data {
struct twl_madc_platform_data *madc;
struct twl_keypad_data *keypad;
struct twl_usb_data *usb;
+struct twl_codec_data *codec;
/* LDO regulators common to TWL4030/TWL6030 */
struct regulator_init_data *vdac;
--
To unsubscribe from this list: send the line unsubscribe 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] [OMAP1] mux: Add MMC mux pins for omap7xx
Cory Maccarrone had written, on 10/06/2009 08:53 AM, the following:
There are three mux pins needed for omap7xx that differ
from the other omap configurations. This change adds the
declarations into mux.c and mux.h.
Signed-off-by: Cory Maccarrone darkstar6...@gmail.com
---
arch/arm/mach-omap1/mux.c |5 +
arch/arm/plat-omap/include/mach/mux.h |5 +
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap1/mux.c b/arch/arm/mach-omap1/mux.c
index d59899d..feb6d8c 100644
--- a/arch/arm/mach-omap1/mux.c
+++ b/arch/arm/mach-omap1/mux.c
@@ -51,6 +51,11 @@ MUX_CFG_7XX(E3_7XX_KBC4,13, 25,0,
24, 1, 0)
MUX_CFG_7XX(AA17_7XX_USB_DM, 2, 21,0, 20, 0, 0)
MUX_CFG_7XX(W16_7XX_USB_PU_EN, 2, 25,0, 24, 0, 0)
MUX_CFG_7XX(W17_7XX_USB_VBUSI, 2, 29,0, 28, 0, 0)
+
+/* MMC Pins */
+MUX_CFG_7XX(MMC_7XX_CMD, 2,9,0,8, 1, 0)
+MUX_CFG_7XX(MMC_7XX_CLK, 2, 13,0, 12, 1, 0)
+MUX_CFG_7XX(MMC_7XX_DAT0,2, 17,0, 16, 1, 0)
};
#define OMAP7XX_PINS_SZARRAY_SIZE(omap7xx_pins)
#else
diff --git a/arch/arm/plat-omap/include/mach/mux.h
b/arch/arm/plat-omap/include/mach/mux.h
index f3c1d8a..56e357e 100644
--- a/arch/arm/plat-omap/include/mach/mux.h
+++ b/arch/arm/plat-omap/include/mach/mux.h
@@ -219,6 +219,11 @@ enum omap7xx_index {
AA17_7XX_USB_DM,
W16_7XX_USB_PU_EN,
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?
--
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] [OMAP1] mux: Add MMC mux pins for omap7xx
On Tue, Oct 6, 2009 at 10:30 AM, Nishanth Menon n...@ti.com wrote:
Cory Maccarrone had written, on 10/06/2009 08:53 AM, the following:
There are three mux pins needed for omap7xx that differ
from the other omap configurations. This change adds the
declarations into mux.c and mux.h.
Signed-off-by: Cory Maccarrone darkstar6...@gmail.com
---
arch/arm/mach-omap1/mux.c | 5 +
arch/arm/plat-omap/include/mach/mux.h | 5 +
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap1/mux.c b/arch/arm/mach-omap1/mux.c
index d59899d..feb6d8c 100644
--- a/arch/arm/mach-omap1/mux.c
+++ b/arch/arm/mach-omap1/mux.c
@@ -51,6 +51,11 @@ MUX_CFG_7XX(E3_7XX_KBC4, 13, 25, 0,
24, 1, 0)
MUX_CFG_7XX(AA17_7XX_USB_DM, 2, 21, 0, 20, 0, 0)
MUX_CFG_7XX(W16_7XX_USB_PU_EN, 2, 25, 0, 24, 0, 0)
MUX_CFG_7XX(W17_7XX_USB_VBUSI, 2, 29, 0, 28, 0, 0)
+
+/* MMC Pins */
+MUX_CFG_7XX(MMC_7XX_CMD, 2, 9, 0, 8, 1, 0)
+MUX_CFG_7XX(MMC_7XX_CLK, 2, 13, 0, 12, 1, 0)
+MUX_CFG_7XX(MMC_7XX_DAT0, 2, 17, 0, 16, 1, 0)
};
#define OMAP7XX_PINS_SZ ARRAY_SIZE(omap7xx_pins)
#else
diff --git a/arch/arm/plat-omap/include/mach/mux.h
b/arch/arm/plat-omap/include/mach/mux.h
index f3c1d8a..56e357e 100644
--- a/arch/arm/plat-omap/include/mach/mux.h
+++ b/arch/arm/plat-omap/include/mach/mux.h
@@ -219,6 +219,11 @@ enum omap7xx_index {
AA17_7XX_USB_DM,
W16_7XX_USB_PU_EN,
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?
--
Regards,
Nishanth Menon
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.
- Cory
--
To unsubscribe from this list: send the line unsubscribe 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] CPUidle: always return with interrupts enabled
On Wed, 30 Sep 2009 23:21:33 +0200
Rafael J. Wysocki r...@sisk.pl wrote:
On Wednesday 30 September 2009, Kevin Hilman wrote:
In the case where cpuidle_idle_call() returns before changing state
due to a need_resched(), it was returning with IRQs disabled.
This patch ensures IRQs are (re)enabled before returning.
Venki, any comments on this?
Rigor mortis is setting in on this one.
Venki's most recent linux-acpi email was on July 31.
Reported-by: Hemanth V heman...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
drivers/cpuidle/cpuidle.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index ad41f19..12fdd39 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -76,8 +76,11 @@ static void cpuidle_idle_call(void)
#endif
/* ask the governor for the next state */
next_state = cpuidle_curr_governor-select(dev);
- if (need_resched())
+ if (need_resched()) {
+ local_irq_enable();
return;
+ }
+
target_state = dev-states[next_state];
/* enter the state and update stats */
The patch seems correct to me. The code is hopelessly poorly
documented as per usual, but other paths in that function, including
the call to target_state-enter() (which devolves to default_idle) also
enable interrupts.
Kevin, the changelog is not good. It tells us what was wrong with the
code but does not describe the user-visible effects of the bug.
I'm unable to find any bug report from Hemanth so I'm all in the dark.
Your cc to linux-omap makes me suspect that whatever the problem was
was exhibited on a non-x86 platform, under some circumstances. Perhaps
that explains (for unknown reasons) why whatever the problem was was
not observed on x86. But I'm totally in the dark and grasping for
clues and have no way of determining (for example) whether we should
backport the fix to earlier kernels.
Please send along the additional information?
--
To unsubscribe from this list: send the line unsubscribe 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] CPUidle: always return with interrupts enabled
On Tue, Oct 6, 2009 at 1:34 PM, Andrew Morton a...@linux-foundation.org wrote:
On Wed, 30 Sep 2009 23:21:33 +0200
Rafael J. Wysocki r...@sisk.pl wrote:
On Wednesday 30 September 2009, Kevin Hilman wrote:
In the case where cpuidle_idle_call() returns before changing state
due to a need_resched(), it was returning with IRQs disabled.
This patch ensures IRQs are (re)enabled before returning.
Venki, any comments on this?
Rigor mortis is setting in on this one.
Venki's most recent linux-acpi email was on July 31.
Reported-by: Hemanth V heman...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
drivers/cpuidle/cpuidle.c | 5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index ad41f19..12fdd39 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -76,8 +76,11 @@ static void cpuidle_idle_call(void)
#endif
/* ask the governor for the next state */
next_state = cpuidle_curr_governor-select(dev);
- if (need_resched())
+ if (need_resched()) {
+ local_irq_enable();
return;
+ }
+
target_state = dev-states[next_state];
/* enter the state and update stats */
The patch seems correct to me. The code is hopelessly poorly
documented as per usual, but other paths in that function, including
the call to target_state-enter() (which devolves to default_idle) also
enable interrupts.
Kevin, the changelog is not good. It tells us what was wrong with the
code but does not describe the user-visible effects of the bug.
The idle path assumes that the platform specific idle code returns
with interrupts enabled (although this too is undocumented AFAICT) and
on ARM we have a WARN_ON(!(irqs_disabled()) when returning from the
idle loop, so the user-visible effects were only a warning since
interrupts were eventually re-enabled later.
I'm unable to find any bug report from Hemanth so I'm all in the dark.
Your cc to linux-omap makes me suspect that whatever the problem was
was exhibited on a non-x86 platform, under some circumstances. Perhaps
that explains (for unknown reasons) why whatever the problem was was
not observed on x86. But I'm totally in the dark and grasping for
clues and have no way of determining (for example) whether we should
backport the fix to earlier kernels.
Please send along the additional information?
On x86, this same problem exists, but there is no WARN_ON() to detect
it. As on ARM, the interrupts are eventually re-enabled, so I'm not
sure of any actual bugs triggered by this. It's primarily a
correctness/consistency fix.
Thanks,
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [OMAP1] mux: Add MMC mux pins for omap7xx
Cory Maccarrone darkstar6...@gmail.com writes:
On Tue, Oct 6, 2009 at 10:30 AM, Nishanth Menon n...@ti.com wrote:
Cory Maccarrone had written, on 10/06/2009 08:53 AM, the following:
There are three mux pins needed for omap7xx that differ
from the other omap configurations. This change adds the
declarations into mux.c and mux.h.
Signed-off-by: Cory Maccarrone darkstar6...@gmail.com
---
arch/arm/mach-omap1/mux.c | 5 +
arch/arm/plat-omap/include/mach/mux.h | 5 +
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap1/mux.c b/arch/arm/mach-omap1/mux.c
index d59899d..feb6d8c 100644
--- a/arch/arm/mach-omap1/mux.c
+++ b/arch/arm/mach-omap1/mux.c
@@ -51,6 +51,11 @@ MUX_CFG_7XX(E3_7XX_KBC4, 13, 25, 0,
24, 1, 0)
MUX_CFG_7XX(AA17_7XX_USB_DM, 2, 21, 0, 20, 0, 0)
MUX_CFG_7XX(W16_7XX_USB_PU_EN, 2, 25, 0, 24, 0, 0)
MUX_CFG_7XX(W17_7XX_USB_VBUSI, 2, 29, 0, 28, 0, 0)
+
+/* MMC Pins */
+MUX_CFG_7XX(MMC_7XX_CMD, 2, 9, 0, 8, 1, 0)
+MUX_CFG_7XX(MMC_7XX_CLK, 2, 13, 0, 12, 1, 0)
+MUX_CFG_7XX(MMC_7XX_DAT0, 2, 17, 0, 16, 1, 0)
};
#define OMAP7XX_PINS_SZ ARRAY_SIZE(omap7xx_pins)
#else
diff --git a/arch/arm/plat-omap/include/mach/mux.h
b/arch/arm/plat-omap/include/mach/mux.h
index f3c1d8a..56e357e 100644
--- a/arch/arm/plat-omap/include/mach/mux.h
+++ b/arch/arm/plat-omap/include/mach/mux.h
@@ -219,6 +219,11 @@ enum omap7xx_index {
AA17_7XX_USB_DM,
W16_7XX_USB_PU_EN,
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?
--
Regards,
Nishanth Menon
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.
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
Timeout after setting SD/MMC clock, bus width on 3530
Hi, I have a prototype board based on the 3530EVM which cannot read its microSD card. I enabled CONFIG_MMC_DEBUG and other printks to the 2.6.29rc3 kernel and can see that info like the transfer rate is coming back but after I reach mmc_set_clock() and setting the bus width, I just get timeouts (output below). Looking at DAT0-3 on a scope, I see activity on DAT0, but the other lines just follow the MMC power, up for ~800ms then off. As an experiment, I tried commenting-out these 2 lines in drivers/mmc/host/omap_hsmmc.c: mmc-caps |= MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED; ... mmc-caps |= MMC_CAP_4_BIT_DATA; in an attempt to use slow, 1-wire transfers, but that got me a panic in mmc_omap_irq(). Assuming the hardware is functioning, is there a way to force the SD controller into its simplest/slowest mode to improve my chances of reading the card? Thanks! , John ... mmc0: starting CMD9 arg 8fe4 flags 0007 MMC: IRQ Status is 1 drivers/mmc/core/sd.c 102 mmc_decode_csd() csd_struct=0 tacc_ns=0 tacc_clks=0 max_dtr=2500 cmdclass=1461 capacity=7744512 drivers/mmc/core/sd.c 67 mmc_decode_cid() manfid=3 prod_name=SU04G card type=1 card state=8 mmc0: starting CMD7 arg 8fe4 flags 0015 MMC: IRQ Status is 1 mmc0: starting CMD55 arg 8fe4 flags 0095 MMC: IRQ Status is 1 mmc0: starting CMD51 arg flags 00b5 MMC: IRQ Status is 3 drivers/mmc/core/sd.c 183 mmc_decode_scr() mmc0: starting CMD6 arg 00f1 flags 00b5 MMC: IRQ Status is 3 drivers/mmc/core/sd.c 261 mmc_switch_hs() mmc0: starting CMD6 arg 80f1 flags 00b5 MMC: IRQ Status is 3 card-csd.max_dtr=2500 mmc_card_highspeed true max_dtr=5000 drivers/mmc/core/core.c:443 mmc_set_clock() mmc_app_set_bus_width() mmc_app_set_bus_width MMC_BUS_WIDTH_4 mmc0: starting CMD55 arg 8fe4 flags 0095 MMC: IRQ Status is 18000 mmc0: starting CMD55 arg 8fe4 flags 0095 drivers/mmc/host/omap_hsmmc.c 535 MMC: IRQ Status is 18000 mmc0: starting CMD55 arg 8fe4 flags 0095 MMC: IRQ Status is 18000 mmc0: starting CMD55 arg 8fe4 flags 0095 MMC: IRQ Status is 18000 drivers/mmc/core/sd.c 559 mmc_app_set_bus_width failed mmc0: error -110 whilst initialising SD card -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
mux strategy (was RE: [PATCH] [OMAP1] mux: Add MMC mux pins for omap7xx)
-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? 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: mux strategy (was RE: [PATCH] [OMAP1] mux: Add MMC mux pins for omap7xx)
Menon, Nishanth n...@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. 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: [ANNOUNCE] updated PM branch, based on 2.6.32-rc1
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
RFC: omap3630 board definitions
Could you please review the 3630 board definitions added: Zoom3: http://www.arm.linux.org.uk/developer/machines/list.php?id=2464 SDP3630: http://www.arm.linux.org.uk/developer/machines/list.php?id=2465 Regards, Vikram -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
