Re: [PATCH 2/4] ARM: OMAP: IOMMU driver: VMA management
Please ignore this patch. This is the same as the previous one. From: ext Hiroshi DOYU [EMAIL PROTECTED] Subject: [PATCH 2/4] ARM: OMAP: IOMMU driver: VMA management Date: Mon, 8 Sep 2008 08:56:32 +0300 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Patch for Touch Screen noise on OMAP3EVM.
When git kernel tree is used on a OMAP3EVM board file for touch screen
testing, it shows lot of jitter. With this patch the jitter can be
reduced.
Signed-off-by: Naveen Atmakuri [EMAIL PROTECTED]
---
arch/arm/mach-omap2/board-omap3evm.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 4963f0f..9a4784e 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -27,6 +27,8 @@
#include asm/mach-types.h
#include asm/mach/arch.h
#include asm/mach/map.h
+#include linux/io.h
+#include linux/delay.h
#include mach/gpio.h
#include mach/keypad.h
@@ -132,8 +134,16 @@ static int ads7846_get_pendown_state(void)
}
struct ads7846_platform_data ads7846_config = {
+ .x_max = 0x0fff,
+ .y_max = 0x0fff,
+ .x_plate_ohms = 180,
+ .pressure_max = 255,
+ .debounce_max = 10,
+ .debounce_tol = 3,
+ .debounce_rep = 1,
.get_pendown_state = ads7846_get_pendown_state,
.keep_vref_on = 1,
+ .settle_delay_usecs = 150,
};
static struct omap2_mcspi_device_config ads7846_mcspi_config = {
--
1.5.6
Warm Regards,
Naveen Atmakuri.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] Sysfs interface for controlling suspend states + set_pwrdm_state fix
ext Paul Walmsley [EMAIL PROTECTED] writes:
Hello Tero,
On Wed, 27 Aug 2008, Tero Kristo wrote:
Target states for each powerdomain can now be set via sysfs interface.
E.g. echo 0 /sys/power/suspend/mpu_pwrdm will program MPU suspend
state to be OFF.
Is this all debugging code, or is there a broader use in mind?
If it is debugging code, the directory should probably go to debugfs, and
all of this code should be wrapped in #ifdef CONFIG_PM_DEBUG.
Either way, let's change the directory structure, so we can add
other files for other powerdomain parameters later. How about:
/sys/power/domain/mpu_pwrdm/next_power_state
or
/debug/powerdomain/mpu_pwrdm/next_power_state
?
I'm not sure if you though so, but for clarification: these interfaces
are not telling value of next_powerst. They are for defining pwrst of
each powerdomain on next suspend. CPUidle/pm_idle/srf can live their
own life and select dynamic next_pwrsts outside this. In case of
suspend each powerdomain is tried to be driven in to state declared in
/sys/power/suspend/*.
Paul, what do you think? Is this for debugging only? I think it is for
debugging, but so is whole suspend concept. At least from my point of view.
Also, set_pwrdm_state() should now work when pwrdm is currently in
power save state.
Signed-off-by: Tero Kristo [EMAIL PROTECTED]
---
arch/arm/mach-omap2/pm34xx.c | 97
+-
1 files changed, 96 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index e0d1b1f..4b42031 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -82,6 +82,8 @@ static void per_gpio_clk_disable(void)
clk_disable(gpio_fcks[i-1]);
}
+static struct kobject *suspend_dir_kobj;
+
/* XXX This is for gpio fclk hack. Will be removed as gpio driver
* handles fcks correctly */
static void gpio_fclk_mask(u32 *fclk)
@@ -306,6 +308,7 @@ int set_pwrdm_state(struct powerdomain *pwrdm, u32 state)
{
u32 cur_state;
int ret = 0;
+int sleep_switch = 0;
if (pwrdm == NULL || IS_ERR(pwrdm))
return -EINVAL;
@@ -315,6 +318,16 @@ int set_pwrdm_state(struct powerdomain *pwrdm, u32
state)
if (cur_state == state)
return ret;
+/* Check if we need to wake-up the pwrdm for state switch */
+/* MPU, core and per are never in sleep states when we are here*/
Please make sure your comments follow CodingStyle - in this case, add a
space after here
+if (pwrdm_read_pwrst(pwrdm) PWRDM_POWER_ON) {
+if ((cm_read_mod_reg(pwrdm-prcm_offs, 0x48) 0x3) == 0x3) {
Please use preprocessor macros, not these bare numbers. This sort of
thing is just backsliding.
+sleep_switch = 1;
+cm_rmw_mod_reg_bits(0x3, 0x2, pwrdm-prcm_offs, 0x48);
As above.
+pwrdm_wait_transition(pwrdm);
+}
+}
+
pwrdm_for_each_clkdm(pwrdm, _clkdm_deny_idle);
ret = pwrdm_set_next_pwrst(pwrdm, state);
@@ -326,6 +339,12 @@ int set_pwrdm_state(struct powerdomain *pwrdm, u32
state)
pwrdm_for_each_clkdm(pwrdm, _clkdm_allow_idle);
+if (sleep_switch) {
+cm_rmw_mod_reg_bits(0x3, 0x3, pwrdm-prcm_offs, 0x48);
As above.
+pwrdm_wait_transition(pwrdm);
+pm_dbg_pwrdm_state_switch(pwrdm);
+}
+
err:
return ret;
}
@@ -380,7 +399,6 @@ static int omap3_pm_suspend(void)
restore:
/* Restore next_pwrsts */
list_for_each_entry(pwrst, pwrst_list, node) {
- set_pwrdm_state(pwrst-pwrdm, pwrst-saved_state);
state = pwrdm_read_prev_pwrst(pwrst-pwrdm);
if (state != pwrst-next_state) {
printk(KERN_INFO Powerdomain (%s) didn't enter
@@ -388,6 +406,7 @@ restore:
pwrst-pwrdm-name, pwrst-next_state);
ret = -1;
}
+set_pwrdm_state(pwrst-pwrdm, pwrst-saved_state);
}
if (ret)
printk(KERN_ERR Could not enter target state in pm_suspend\n);
@@ -584,9 +603,67 @@ static void __init prcm_setup_regs(void)
OCP_MOD, OMAP2_PRM_IRQENABLE_MPU_OFFSET);
}
+static struct power_state *get_pwrst_node(const char *name)
+{
+struct powerdomain *pwrdm;
+struct power_state *pwrst_tmp;
+struct power_state *pwrst = NULL;
+
+pwrdm = pwrdm_lookup(name);
+
+if (pwrdm == NULL) {
+printk(KERN_ERR pwrdm not found %s\n, name);
+return NULL;
+}
+
+list_for_each_entry(pwrst_tmp, pwrst_list, node)
+if (pwrst_tmp-pwrdm == pwrdm)
+pwrst = pwrst_tmp;
+
+if (pwrst == NULL)
+printk(KERN_ERR pwrdm not in suspend list %s\n, name);
+
+return pwrst;
+}
+
+static ssize_t state_show(struct kobject *kobj, struct kobj_attribute
Re: [PATCH 1/1] Use pmd_table() MACRO for unmap_area_sections()
Hi Richard, From: ext Woodruff, Richard [EMAIL PROTECTED] Subject: RE: [PATCH 1/1] Use pmd_table() MACRO for unmap_area_sections() Date: Sun, 7 Sep 2008 21:04:56 -0500 From: [EMAIL PROTECTED] [mailto:linux-omap- [EMAIL PROTECTED] On Behalf Of Russell King - ARM Linux Well, the first question is... where has this come from, and why. In OMAPs, a few devices have a local IO MMU. Their basic structure is similar to an ARM MMU, but less featured. IVA Camera have one each on 3430/2430, a 2420 has those before mentioned and + 3rd in its video accelerator. The usage in TI kernels has varied a bit. Some times they are just load and lock TLB's, for others table walking can be enabled. In all cases if a table walk miss happens it is fatal and the IP block device will have to be reset. In *theory*, from this IOMMU hardware perspective, it's feasible to load something on memory dynamically(on-demand loading) when a table walk miss happens by notifying it to some memory manager through its assigned interrupt. Practically this latency may be a problem in some cases;) Hiroshi DOYU -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC rev2] ASoC: OMAP: Add support for OMAP2430 and OMAP34xx in McBSP DAI driver
Signed-off-by: Jarkko Nikula [EMAIL PROTECTED]
---
sound/soc/omap/omap-mcbsp.c | 95 ++
1 files changed, 77 insertions(+), 18 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index 35310e1..a217cf2 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -84,11 +84,22 @@ static const unsigned long omap1_mcbsp_port[][2] = {
static const int omap1_dma_reqs[][2] = {};
static const unsigned long omap1_mcbsp_port[][2] = {};
#endif
-#if defined(CONFIG_ARCH_OMAP2420)
-static const int omap2420_dma_reqs[][2] = {
+
+#if defined(CONFIG_ARCH_OMAP24XX) || defined(CONFIG_ARCH_OMAP34XX)
+static const int omap24xx_dma_reqs[][2] = {
{ OMAP24XX_DMA_MCBSP1_TX, OMAP24XX_DMA_MCBSP1_RX },
{ OMAP24XX_DMA_MCBSP2_TX, OMAP24XX_DMA_MCBSP2_RX },
+#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP34XX)
+ { OMAP24XX_DMA_MCBSP3_TX, OMAP24XX_DMA_MCBSP3_RX },
+ { OMAP24XX_DMA_MCBSP4_TX, OMAP24XX_DMA_MCBSP4_RX },
+ { OMAP24XX_DMA_MCBSP5_TX, OMAP24XX_DMA_MCBSP5_RX },
+#endif
};
+#else
+static const int omap2420_dma_reqs[][2] = {};
+#endif
+
+#if defined(CONFIG_ARCH_OMAP2420)
static const unsigned long omap2420_mcbsp_port[][2] = {
{ OMAP24XX_MCBSP1_BASE + OMAP_MCBSP_REG_DXR1,
OMAP24XX_MCBSP1_BASE + OMAP_MCBSP_REG_DRR1 },
@@ -96,10 +107,43 @@ static const unsigned long omap2420_mcbsp_port[][2] = {
OMAP24XX_MCBSP2_BASE + OMAP_MCBSP_REG_DRR1 },
};
#else
-static const int omap2420_dma_reqs[][2] = {};
static const unsigned long omap2420_mcbsp_port[][2] = {};
#endif
+#if defined(CONFIG_ARCH_OMAP2430)
+static const unsigned long omap2430_mcbsp_port[][2] = {
+ { OMAP24XX_MCBSP1_BASE + OMAP_MCBSP_REG_DXR,
+ OMAP24XX_MCBSP1_BASE + OMAP_MCBSP_REG_DRR },
+ { OMAP24XX_MCBSP2_BASE + OMAP_MCBSP_REG_DXR,
+ OMAP24XX_MCBSP2_BASE + OMAP_MCBSP_REG_DRR },
+ { OMAP2430_MCBSP3_BASE + OMAP_MCBSP_REG_DXR,
+ OMAP2430_MCBSP3_BASE + OMAP_MCBSP_REG_DRR },
+ { OMAP2430_MCBSP4_BASE + OMAP_MCBSP_REG_DXR,
+ OMAP2430_MCBSP4_BASE + OMAP_MCBSP_REG_DRR },
+ { OMAP2430_MCBSP5_BASE + OMAP_MCBSP_REG_DXR,
+ OMAP2430_MCBSP5_BASE + OMAP_MCBSP_REG_DRR },
+};
+#else
+static const unsigned long omap2430_mcbsp_port[][2] = {};
+#endif
+
+#if defined(CONFIG_ARCH_OMAP34XX)
+static const unsigned long omap34xx_mcbsp_port[][2] = {
+ { OMAP34XX_MCBSP1_BASE + OMAP_MCBSP_REG_DXR,
+ OMAP34XX_MCBSP1_BASE + OMAP_MCBSP_REG_DRR },
+ { OMAP34XX_MCBSP2_BASE + OMAP_MCBSP_REG_DXR,
+ OMAP34XX_MCBSP2_BASE + OMAP_MCBSP_REG_DRR },
+ { OMAP34XX_MCBSP3_BASE + OMAP_MCBSP_REG_DXR,
+ OMAP34XX_MCBSP3_BASE + OMAP_MCBSP_REG_DRR },
+ { OMAP34XX_MCBSP4_BASE + OMAP_MCBSP_REG_DXR,
+ OMAP34XX_MCBSP4_BASE + OMAP_MCBSP_REG_DRR },
+ { OMAP34XX_MCBSP5_BASE + OMAP_MCBSP_REG_DXR,
+ OMAP34XX_MCBSP5_BASE + OMAP_MCBSP_REG_DRR },
+};
+#else
+static const unsigned long omap34xx_mcbsp_port[][2] = {};
+#endif
+
static int omap_mcbsp_dai_startup(struct snd_pcm_substream *substream)
{
struct snd_soc_pcm_runtime *rtd = substream-private_data;
@@ -167,12 +211,15 @@ static int omap_mcbsp_dai_hw_params(struct
snd_pcm_substream *substream,
dma = omap1_dma_reqs[bus_id][substream-stream];
port = omap1_mcbsp_port[bus_id][substream-stream];
} else if (cpu_is_omap2420()) {
- dma = omap2420_dma_reqs[bus_id][substream-stream];
+ dma = omap24xx_dma_reqs[bus_id][substream-stream];
port = omap2420_mcbsp_port[bus_id][substream-stream];
+ } else if (cpu_is_omap2430()) {
+ dma = omap24xx_dma_reqs[bus_id][substream-stream];
+ port = omap2430_mcbsp_port[bus_id][substream-stream];
+ } else if (cpu_is_omap343x()) {
+ dma = omap24xx_dma_reqs[bus_id][substream-stream];
+ port = omap34xx_mcbsp_port[bus_id][substream-stream];
} else {
- /*
-* TODO: Add support for 2430 and 3430
-*/
return -ENODEV;
}
omap_mcbsp_dai_dma_params[id][substream-stream].dma_req = dma;
@@ -310,7 +357,7 @@ static int omap_mcbsp_dai_set_clks_src(struct
omap_mcbsp_data *mcbsp_data,
int clk_id)
{
int sel_bit;
- u16 reg;
+ u16 reg, reg_devconf1 = OMAP243X_CONTROL_DEVCONF1;
if (cpu_class_is_omap1()) {
/* OMAP1's can use only external source clock */
@@ -320,6 +367,12 @@ static int omap_mcbsp_dai_set_clks_src(struct
omap_mcbsp_data *mcbsp_data,
return 0;
}
+ if (cpu_is_omap2420() mcbsp_data-bus_id 1)
+ return -EINVAL;
+
+ if (cpu_is_omap343x())
+ reg_devconf1 = OMAP343X_CONTROL_DEVCONF1;
+
switch (mcbsp_data-bus_id) {
case 0:
reg =
[RFC 0/2 rev2] McBSP and ASoC OMAP update patches for 2430 and 34xx
Here is second version of patch adding support for 2430 in McBSP driver. Updated version uses phys_base instead of virt_base. See following commits from Russell King: ecec3b3e080464cc1b4e792cf4d8e7e89d50b011 2cfd6fcda3b8c6ee7a5fa9a4573e3246532a0716 Second patch is the same than first version. It's for testing ASoC OMAP and eventually it will go through the alsa-devel. -- Jarkko -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC rev2] ARM: OMAP: Add support for OMAP2430 in McBSP
Signed-off-by: Jarkko Nikula [EMAIL PROTECTED]
---
arch/arm/mach-omap2/mcbsp.c | 73 ++
arch/arm/plat-omap/include/mach/mcbsp.h |3 +
2 files changed, 66 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
index 7addc5a..afbe1e6 100644
--- a/arch/arm/mach-omap2/mcbsp.c
+++ b/arch/arm/mach-omap2/mcbsp.c
@@ -145,8 +145,8 @@ static struct omap_mcbsp_ops omap2_mcbsp_ops = {
.request= omap2_mcbsp_request,
};
-#ifdef CONFIG_ARCH_OMAP24XX
-static struct omap_mcbsp_platform_data omap24xx_mcbsp_pdata[] = {
+#ifdef CONFIG_ARCH_OMAP2420
+static struct omap_mcbsp_platform_data omap2420_mcbsp_pdata[] = {
{
.phys_base = OMAP24XX_MCBSP1_BASE,
.dma_rx_sync= OMAP24XX_DMA_MCBSP1_RX,
@@ -166,10 +166,58 @@ static struct omap_mcbsp_platform_data
omap24xx_mcbsp_pdata[] = {
.clk_name = mcbsp_clk,
},
};
-#define OMAP24XX_MCBSP_PDATA_SZARRAY_SIZE(omap24xx_mcbsp_pdata)
+#define OMAP2420_MCBSP_PDATA_SZARRAY_SIZE(omap2420_mcbsp_pdata)
#else
-#define omap24xx_mcbsp_pdata NULL
-#define OMAP24XX_MCBSP_PDATA_SZ0
+#define omap2420_mcbsp_pdata NULL
+#define OMAP2420_MCBSP_PDATA_SZ0
+#endif
+
+#ifdef CONFIG_ARCH_OMAP2430
+static struct omap_mcbsp_platform_data omap2430_mcbsp_pdata[] = {
+ {
+ .phys_base = OMAP24XX_MCBSP1_BASE,
+ .dma_rx_sync= OMAP24XX_DMA_MCBSP1_RX,
+ .dma_tx_sync= OMAP24XX_DMA_MCBSP1_TX,
+ .rx_irq = INT_24XX_MCBSP1_IRQ_RX,
+ .tx_irq = INT_24XX_MCBSP1_IRQ_TX,
+ .ops= omap2_mcbsp_ops,
+ .clk_name = mcbsp_clk,
+ },
+ {
+ .phys_base = OMAP24XX_MCBSP2_BASE,
+ .dma_rx_sync= OMAP24XX_DMA_MCBSP2_RX,
+ .dma_tx_sync= OMAP24XX_DMA_MCBSP2_TX,
+ .rx_irq = INT_24XX_MCBSP2_IRQ_RX,
+ .tx_irq = INT_24XX_MCBSP2_IRQ_TX,
+ .ops= omap2_mcbsp_ops,
+ .clk_name = mcbsp_clk,
+ },
+ {
+ .phys_base = OMAP2430_MCBSP3_BASE,
+ .dma_rx_sync= OMAP24XX_DMA_MCBSP3_RX,
+ .dma_tx_sync= OMAP24XX_DMA_MCBSP3_TX,
+ .ops= omap2_mcbsp_ops,
+ .clk_name = mcbsp_clk,
+ },
+ {
+ .phys_base = OMAP2430_MCBSP4_BASE,
+ .dma_rx_sync= OMAP24XX_DMA_MCBSP4_RX,
+ .dma_tx_sync= OMAP24XX_DMA_MCBSP4_TX,
+ .ops= omap2_mcbsp_ops,
+ .clk_name = mcbsp_clk,
+ },
+ {
+ .phys_base = OMAP2430_MCBSP5_BASE,
+ .dma_rx_sync= OMAP24XX_DMA_MCBSP5_RX,
+ .dma_tx_sync= OMAP24XX_DMA_MCBSP5_TX,
+ .ops= omap2_mcbsp_ops,
+ .clk_name = mcbsp_clk,
+ },
+};
+#define OMAP2430_MCBSP_PDATA_SZARRAY_SIZE(omap2430_mcbsp_pdata)
+#else
+#define omap2430_mcbsp_pdata NULL
+#define OMAP2430_MCBSP_PDATA_SZ0
#endif
#ifdef CONFIG_ARCH_OMAP34XX
@@ -230,8 +278,10 @@ static int __init omap2_mcbsp_init(void)
clk_register(omap_mcbsp_clks[i].clk);
}
- if (cpu_is_omap24xx())
- omap_mcbsp_count = OMAP24XX_MCBSP_PDATA_SZ;
+ if (cpu_is_omap2420())
+ omap_mcbsp_count = OMAP2420_MCBSP_PDATA_SZ;
+ if (cpu_is_omap2430())
+ omap_mcbsp_count = OMAP2430_MCBSP_PDATA_SZ;
if (cpu_is_omap34xx())
omap_mcbsp_count = OMAP34XX_MCBSP_PDATA_SZ;
@@ -240,9 +290,12 @@ static int __init omap2_mcbsp_init(void)
if (!mcbsp_ptr)
return -ENOMEM;
- if (cpu_is_omap24xx())
- omap_mcbsp_register_board_cfg(omap24xx_mcbsp_pdata,
- OMAP24XX_MCBSP_PDATA_SZ);
+ if (cpu_is_omap2420())
+ omap_mcbsp_register_board_cfg(omap2420_mcbsp_pdata,
+ OMAP2420_MCBSP_PDATA_SZ);
+ if (cpu_is_omap2430())
+ omap_mcbsp_register_board_cfg(omap2430_mcbsp_pdata,
+ OMAP2430_MCBSP_PDATA_SZ);
if (cpu_is_omap34xx())
omap_mcbsp_register_board_cfg(omap34xx_mcbsp_pdata,
OMAP34XX_MCBSP_PDATA_SZ);
diff --git a/arch/arm/plat-omap/include/mach/mcbsp.h
b/arch/arm/plat-omap/include/mach/mcbsp.h
index f4e7980..6a0d1a0 100644
--- a/arch/arm/plat-omap/include/mach/mcbsp.h
+++ b/arch/arm/plat-omap/include/mach/mcbsp.h
@@ -43,6 +43,9 @@
#define OMAP24XX_MCBSP1_BASE 0x48074000
#define OMAP24XX_MCBSP2_BASE 0x48076000
+#define
Re: [PATCH 32/33] add omap 1-wire interface driver
- Original Message -
From: Tony Lindgren [EMAIL PROTECTED]
To: Madhusudhan Chikkature [EMAIL PROTECTED]
Cc: Felipe Balbi [EMAIL PROTECTED]; linux-omap@vger.kernel.org; Felipe
Balbi [EMAIL PROTECTED]
Sent: Friday, September 05, 2008 11:29 PM
Subject: Re: [PATCH 32/33] add omap 1-wire interface driver
* Madhusudhan Chikkature [EMAIL PROTECTED] [080901 06:16]:
Hi,
The HDQ patchset that I posted to Tony were given ACK by Evgeniy Polyakov on
the omap list. I hope that helps.
Madhu, can you post your 1-wire driver to LKML and Cc Evgeniy Polyakov
so we can get that integrated? Also Cc l-o list.
I have a question regarding this. In fact it can be a generic question which
might apply for other drivers as well. How do we post the OMAP3 related driver
patches to LKML or any other driver specific lists if OMAP3 base support is not
already present there?
Regards,
Madhu
Thanks,
Tony
Regards,
Madhu
- Original Message -
From: Felipe Balbi [EMAIL PROTECTED]
To: linux-omap@vger.kernel.org
Cc: Felipe Balbi [EMAIL PROTECTED]
Sent: Saturday, August 30, 2008 10:46 PM
Subject: [PATCH 32/33] add omap 1-wire interface driver
From: Felipe Balbi [EMAIL PROTECTED]
Signed-off-by: Felipe Balbi [EMAIL PROTECTED]
---
arch/arm/plat-omap/include/mach/irqs.h |2 +
drivers/w1/masters/Kconfig |7 +
drivers/w1/masters/Makefile|1 +
drivers/w1/masters/omap_hdq.c | 704
4 files changed, 714 insertions(+), 0 deletions(-)
create mode 100644 drivers/w1/masters/omap_hdq.c
diff --git a/arch/arm/plat-omap/include/mach/irqs.h
b/arch/arm/plat-omap/include/mach/irqs.h
index 17248bb..c9e95a6 100644
--- a/arch/arm/plat-omap/include/mach/irqs.h
+++ b/arch/arm/plat-omap/include/mach/irqs.h
@@ -54,6 +54,8 @@
#define INT_TIMER2 30
#define INT_LCD_CTRL 31
+#define INT_24XX_HDQ_IRQ 58 /* Temporarily here for driver to build */
+
/*
* OMAP-1510 specific IRQ numbers for interrupt handler 1
*/
diff --git a/drivers/w1/masters/Kconfig b/drivers/w1/masters/Kconfig
index c449309..636d4f7 100644
--- a/drivers/w1/masters/Kconfig
+++ b/drivers/w1/masters/Kconfig
@@ -42,6 +42,13 @@ config W1_MASTER_DS1WM
in HP iPAQ devices like h5xxx, h2200, and ASIC3-based like
hx4700.
+config HDQ_MASTER_OMAP
+ tristate OMAP HDQ driver
+ depends on ARCH_OMAP2430 || ARCH_OMAP34XX
+ help
+ Say Y here if you want support for the 1-wire or HDQ Interface
+ on an OMAP processor.
+
config W1_MASTER_GPIO
tristate GPIO 1-wire busmaster
depends on GENERIC_GPIO
diff --git a/drivers/w1/masters/Makefile b/drivers/w1/masters/Makefile
index 1420b5b..1daeb6e 100644
--- a/drivers/w1/masters/Makefile
+++ b/drivers/w1/masters/Makefile
@@ -6,4 +6,5 @@ obj-$(CONFIG_W1_MASTER_MATROX) += matrox_w1.o
obj-$(CONFIG_W1_MASTER_DS2490) += ds2490.o
obj-$(CONFIG_W1_MASTER_DS2482) += ds2482.o
obj-$(CONFIG_W1_MASTER_DS1WM) += ds1wm.o
+obj-$(CONFIG_HDQ_MASTER_OMAP) += omap_hdq.o
obj-$(CONFIG_W1_MASTER_GPIO) += w1-gpio.o
diff --git a/drivers/w1/masters/omap_hdq.c b/drivers/w1/masters/omap_hdq.c
new file mode 100644
index 000..880e282
--- /dev/null
+++ b/drivers/w1/masters/omap_hdq.c
@@ -0,0 +1,704 @@
+/*
+ * drivers/w1/masters/omap_hdq.c
+ *
+ * Copyright (C) 2007 Texas Instruments, Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ *
+ */
+#include linux/kernel.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/interrupt.h
+#include linux/err.h
+#include linux/clk.h
+#include linux/io.h
+#include asm/irq.h
+#include mach/hardware.h
+
+#include ../w1.h
+#include ../w1_int.h
+
+#define MOD_NAME OMAP_HDQ:
+
+#define OMAP_HDQ_REVISION 0x00
+#define OMAP_HDQ_TX_DATA 0x04
+#define OMAP_HDQ_RX_DATA 0x08
+#define OMAP_HDQ_CTRL_STATUS 0x0c
+#define OMAP_HDQ_CTRL_STATUS_INTERRUPTMASK (16)
+#define OMAP_HDQ_CTRL_STATUS_CLOCKENABLE (15)
+#define OMAP_HDQ_CTRL_STATUS_GO (14)
+#define OMAP_HDQ_CTRL_STATUS_INITIALIZATION (12)
+#define OMAP_HDQ_CTRL_STATUS_DIR (11)
+#define OMAP_HDQ_CTRL_STATUS_MODE (10)
+#define OMAP_HDQ_INT_STATUS 0x10
+#define OMAP_HDQ_INT_STATUS_TXCOMPLETE (12)
+#define OMAP_HDQ_INT_STATUS_RXCOMPLETE (11)
+#define OMAP_HDQ_INT_STATUS_TIMEOUT (10)
+#define OMAP_HDQ_SYSCONFIG 0x14
+#define OMAP_HDQ_SYSCONFIG_SOFTRESET (11)
+#define OMAP_HDQ_SYSCONFIG_AUTOIDLE (10)
+#define OMAP_HDQ_SYSSTATUS 0x18
+#define OMAP_HDQ_SYSSTATUS_RESETDONE (10)
+
+#define OMAP_HDQ_FLAG_CLEAR 0
+#define OMAP_HDQ_FLAG_SET 1
+#define OMAP_HDQ_TIMEOUT (HZ/5)
+
+#define OMAP_HDQ_MAX_USER 4
+
+DECLARE_WAIT_QUEUE_HEAD(hdq_wait_queue);
+int W1_ID;
+
+struct hdq_data {
+ resource_size_t
[PATCH] omapfb: setting GOLCD bit for shadow registers to make effect
A shadow register change has no direct effect on the display configuration until the GOLCD (DISPC_CONTROL[5]) is set. Signed-off-by: Arun C [EMAIL PROTECTED] --- drivers/video/omap/dispc.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/drivers/video/omap/dispc.c b/drivers/video/omap/dispc.c index 82ba030..2e7af85 100644 --- a/drivers/video/omap/dispc.c +++ b/drivers/video/omap/dispc.c @@ -436,6 +436,11 @@ static inline int _setup_plane(int plane, int channel_out, dispc_write_reg(ri_reg[plane], (screen_width - width) * bpp / 8 + 1); + /* Wait untill GOLCD bit is cleared and set it */ + while (dispc_read_reg(DISPC_CONTROL) (1 5)) + continue; + MOD_REG_FLD(DISPC_CONTROL, 1 5, 1 5); + return height * screen_width * bpp / 8; } -- 1.5.3.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
3430: can't find mmc debounce clock
Hello, I read that the mmc has 3 clocks: fixed functional clock (MMCi_FCLK), interface clock (MMCi_ICLK) and debounce clock (MMCi_32). But, when I look in clock34xx.h, I can only see two of those - there is the mmchs_fck and mmchs_ick. There is no struct clk for the debounce clock. Only when I look in older kernels I can see also the mmchsdb2_fck. So where is the debounce clock struct ? (I want to 'get' and 'enable' it...) Thank you in advance Budhee -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: powering up the mmc controller on 3430
On Mon, Sep 8, 2008 at 4:49 AM, Woodruff, Richard [EMAIL PROTECTED] wrote: I believe the driver now calls this via its platform data in arch/arm/mach-omap2/. Same sequence but now a bit more generalized from the external driver point of view. Thank you, I will look into it Budhee Regards, Richard W. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/1] Use pmd_table() MACRO for unmap_area_sections()
Hi, The usage in TI kernels has varied a bit. Some times they are just load and lock TLB's, for others table walking can be enabled. In all cases if a table walk miss happens it is fatal and the IP block device will have to be reset. In *theory*, from this IOMMU hardware perspective, it's feasible to load something on memory dynamically(on-demand loading) when a table walk miss happens by notifying it to some memory manager through its assigned interrupt. Practically this latency may be a problem in some cases;) I've been told explicitly by a few people that a table miss is fatal and the block needs to be reset to recover state. I've not personally dug into TRM and underlying functional specs to validate this. It might be different per IP. Extreme case some kind of checkpoint would work ;) In some discussions some people have even taken in table walk time as a consideration if certain camera streaming cases will work. So, your comment about latency seems on. Regards, Richard W. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Fixed CPU type check for OMAP3
ES version definitions were incorrect, also GP/EMU/SEC etc. types were not
detected at all.
Signed-off-by: Tero Kristo [EMAIL PROTECTED]
---
arch/arm/mach-omap2/id.c |9 -
arch/arm/plat-omap/include/mach/cpu.h |2 +-
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index a526c0f..290b88c 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -53,6 +53,13 @@ static struct omap_id omap_ids[] __initdata = {
{ .hawkeye = 0xb68a, .dev = 0x0, .type = 0x2430 },
};
+static const char omap3_revs[][4] = {
+ 1.0,
+ 2.0,
+ 2.1,
+ 3.0
+};
+
static struct omap_chip_id omap_chip;
/**
@@ -224,7 +231,7 @@ void __init omap2_check_revision(void)
* Note that rev cannot be used directly as ES1.0 uses value 0.
*/
if (hawkeye == 0xb7ae) {
- system_rev = 0x3430 | ((1 + rev) 12);
+ _set_system_rev(0x3430 | (rev 12), rev);
pr_info(OMAP%04x ES2.%i\n, system_rev 16, rev);
_set_omap_chip();
return;
diff --git a/arch/arm/plat-omap/include/mach/cpu.h
b/arch/arm/plat-omap/include/mach/cpu.h
index e046418..e170d29 100644
--- a/arch/arm/plat-omap/include/mach/cpu.h
+++ b/arch/arm/plat-omap/include/mach/cpu.h
@@ -357,7 +357,7 @@ IS_OMAP_TYPE(3430, 0x3430)
#define OMAP3430_REV_ES1_0 0x3430
#define OMAP3430_REV_ES2_0 0x34301000
#define OMAP3430_REV_ES2_1 0x34302000
-#define OMAP3430_REV_ES2_2 0x34303000
+#define OMAP3430_REV_ES3_0 0x34303000
/*
* omap_chip bits
--
1.5.4.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Fixed CPU type check for OMAP3
ES version definitions were incorrect, also GP/EMU/SEC etc. types were not
detected at all.
Signed-off-by: Tero Kristo [EMAIL PROTECTED]
---
arch/arm/mach-omap2/id.c |11 +--
arch/arm/plat-omap/include/mach/cpu.h |2 +-
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index a526c0f..290b88c 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -53,6 +53,13 @@ static struct omap_id omap_ids[] __initdata = {
{ .hawkeye = 0xb68a, .dev = 0x0, .type = 0x2430 },
};
+static const char omap3_revs[][4] = {
+ 1.0,
+ 2.0,
+ 2.1,
+ 3.0
+};
+
static struct omap_chip_id omap_chip;
/**
@@ -224,7 +231,7 @@ void __init omap2_check_revision(void)
* Note that rev cannot be used directly as ES1.0 uses value 0.
*/
if (hawkeye == 0xb7ae) {
- system_rev = 0x3430 | ((1 + rev) 12);
- pr_info(OMAP%04x ES2.%i\n, system_rev 16, rev);
+ _set_system_rev(0x3430 | (rev 12), rev);
+ pr_info(OMAP%04x ES%s\n, system_rev 16, omap3_revs[rev]);
_set_omap_chip();
return;
diff --git a/arch/arm/plat-omap/include/mach/cpu.h
b/arch/arm/plat-omap/include/mach/cpu.h
index e046418..e170d29 100644
--- a/arch/arm/plat-omap/include/mach/cpu.h
+++ b/arch/arm/plat-omap/include/mach/cpu.h
@@ -357,7 +357,7 @@ IS_OMAP_TYPE(3430, 0x3430)
#define OMAP3430_REV_ES1_0 0x3430
#define OMAP3430_REV_ES2_0 0x34301000
#define OMAP3430_REV_ES2_1 0x34302000
-#define OMAP3430_REV_ES2_2 0x34303000
+#define OMAP3430_REV_ES3_0 0x34303000
/*
* omap_chip bits
--
1.5.4.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH - Omapzoom] [NAND] Add prefetch and DMA support
From: Vimal Singh [EMAIL PROTECTED]
Following patch taken over the omapzoom.org tree adds
prefetch and DMA support to the OMAP2/3 nand driver.
Signed-off-by: Vimal Singh [EMAIL PROTECTED]
Signed-off-by: Nishant Kamat [EMAIL PROTECTED]
---
arch/arm/mach-omap2/gpmc.c | 95 +++
arch/arm/plat-omap/include/mach/gpmc.h |4
drivers/mtd/nand/Kconfig | 30
drivers/mtd/nand/omap2.c | 199 ++---
4 files changed, 310 insertions(+), 18 deletions(-)
Index: omapkernel/arch/arm/mach-omap2/gpmc.c
===
--- omapkernel.orig/arch/arm/mach-omap2/gpmc.c 2008-09-08 18:23:29.0
+0530
+++ omapkernel/arch/arm/mach-omap2/gpmc.c 2008-09-08 18:34:22.0
+0530
@@ -54,6 +54,12 @@
#define GPMC_CHUNK_SHIFT 24 /* 16 MB */
#define GPMC_SECTION_SHIFT 28 /* 128 MB */
+#ifdef CONFIG_MTD_NAND_OMAP_PREFETCH
+#define CS_NUM_SHIFT 24
+#define ENABLE_PREFETCH7
+#define DMA_MPU_MODE 2
+#endif
+
#ifdef CONFIG_OMAP3_PM
/*
* Structure to save/restore gpmc context
@@ -407,6 +413,92 @@
}
EXPORT_SYMBOL(gpmc_cs_free);
+#ifdef CONFIG_MTD_NAND_OMAP_PREFETCH
+/*
+ * gpmc_prefetch_init - configures default configuration for prefetch engine
+ */
+static void gpmc_prefetch_init(void)
+{
+ /* Setting the default threshold to 64 */
+ gpmc_write_reg(GPMC_PREFETCH_CONTROL, 0x0);
+ gpmc_write_reg(GPMC_PREFETCH_CONFIG1, 0x40 8);
+ gpmc_write_reg(GPMC_PREFETCH_CONFIG2, 0x0);
+}
+
+/*
+ * gpmc_prefetch_start - configures and starts prefetch transfer
+ * @cs - nand cs (chip select) number
+ * @dma_mode: dma mode enable (1) or disable (0)
+ * @u32_count: number of bytes to be transferred
+ * @is_write: prefetch read(0) or write post(1) mode
+ */
+void gpmc_prefetch_start(int cs, int dma_mode,
+ unsigned int u32_count, int is_write)
+{
+ uint32_t prefetch_config1;
+ if (is_write) {
+ /* Set the amount of bytes to be prefetched */
+ gpmc_write_reg(GPMC_PREFETCH_CONFIG2, u32_count);
+
+ /* Set dma/mpu mode, the post write and enable the engine
+* Set which cs is using the post write
+*/
+ prefetch_config1 = gpmc_read_reg(GPMC_PREFETCH_CONFIG1);
+ prefetch_config1 |= ((cs CS_NUM_SHIFT) |
+ (dma_mode DMA_MPU_MODE) |
+ (1 ENABLE_PREFETCH) | 0x1);
+ gpmc_write_reg(GPMC_PREFETCH_CONFIG1, prefetch_config1);
+ } else {
+ /* Set the amount of bytes to be prefetched */
+ gpmc_write_reg(GPMC_PREFETCH_CONFIG2, u32_count);
+
+ /* Set dma/mpu mode, the prefech read and enable the engine
+* Set which cs is using the prefetch
+*/
+ prefetch_config1 = gpmc_read_reg(GPMC_PREFETCH_CONFIG1);
+ prefetch_config1 |= (((cs CS_NUM_SHIFT) |
+ (dma_mode DMA_MPU_MODE) |
+ (1 ENABLE_PREFETCH)) ~0x1);
+ gpmc_write_reg(GPMC_PREFETCH_CONFIG1, prefetch_config1);
+ }
+ /* Start the prefetch engine */
+ gpmc_write_reg(GPMC_PREFETCH_CONTROL, 0x1);
+}
+EXPORT_SYMBOL(gpmc_prefetch_start);
+
+/*
+ * gpmc_prefetch_stop - disables and stops the prefetch engine
+ */
+void gpmc_prefetch_stop(void)
+{
+ uint32_t prefetch_config1;
+ /* stop the PFPW engine */
+ gpmc_write_reg(GPMC_PREFETCH_CONTROL, 0x0);
+
+ /* Disable the PFPW engine */
+ prefetch_config1 = gpmc_read_reg(GPMC_PREFETCH_CONFIG1);
+ prefetch_config1 = ~((0x07 CS_NUM_SHIFT) |
+ (1 ENABLE_PREFETCH) |
+ (1 DMA_MPU_MODE) | 0x1);
+ gpmc_write_reg(GPMC_PREFETCH_CONFIG1, prefetch_config1);
+}
+EXPORT_SYMBOL(gpmc_prefetch_stop);
+
+/*
+ * gpmc_prefetch_status - reads prefetch status of engine
+ */
+int gpmc_prefetch_status(void)
+{
+ return gpmc_read_reg(GPMC_PREFETCH_STATUS);
+}
+EXPORT_SYMBOL(gpmc_prefetch_status);
+#else
+int gpmc_prefetch_status(void) {return 0; }
+void gpmc_prefetch_stop(void) {}
+void gpmc_prefetch_start(int cs, int dma_mode, unsigned int u32_count,
+ int is_write) {}
+#endif
+
static void __init gpmc_mem_init(void)
{
int cs;
@@ -462,6 +554,9 @@
gpmc_freq_cfg.freq_cfg = NULL;
gpmc_freq_cfg.total_no_of_freq = 0;
#endif
+#ifdef CONFIG_MTD_NAND_OMAP_PREFETCH
+ gpmc_prefetch_init();
+#endif
gpmc_mem_init();
}
Index: omapkernel/arch/arm/plat-omap/include/mach/gpmc.h
===
--- omapkernel.orig/arch/arm/plat-omap/include/mach/gpmc.h
[Resend][PATCH - Omapzoom][NAND] Add prefetch and DMA support
From: Vimal Singh [EMAIL PROTECTED]
Following patch taken over the omapzoom.org tree adds
prefetch and DMA support to the OMAP2/3 nand driver.
Signed-off-by: Vimal Singh [EMAIL PROTECTED]
Signed-off-by: Nishant Kamat [EMAIL PROTECTED]
---
arch/arm/mach-omap2/gpmc.c | 95 +++
arch/arm/plat-omap/include/mach/gpmc.h |4
drivers/mtd/nand/Kconfig | 30
drivers/mtd/nand/omap2.c | 199 ++---
4 files changed, 310 insertions(+), 18 deletions(-)
Index: omapkernel/arch/arm/mach-omap2/gpmc.c
===
--- omapkernel.orig/arch/arm/mach-omap2/gpmc.c 2008-09-08 18:23:29.0
+0530
+++ omapkernel/arch/arm/mach-omap2/gpmc.c 2008-09-08 18:34:22.0
+0530
@@ -54,6 +54,12 @@
#define GPMC_CHUNK_SHIFT 24 /* 16 MB */
#define GPMC_SECTION_SHIFT 28 /* 128 MB */
+#ifdef CONFIG_MTD_NAND_OMAP_PREFETCH
+#define CS_NUM_SHIFT 24
+#define ENABLE_PREFETCH7
+#define DMA_MPU_MODE 2
+#endif
+
#ifdef CONFIG_OMAP3_PM
/*
* Structure to save/restore gpmc context
@@ -407,6 +413,92 @@
}
EXPORT_SYMBOL(gpmc_cs_free);
+#ifdef CONFIG_MTD_NAND_OMAP_PREFETCH
+/*
+ * gpmc_prefetch_init - configures default configuration for prefetch engine
+ */
+static void gpmc_prefetch_init(void)
+{
+ /* Setting the default threshold to 64 */
+ gpmc_write_reg(GPMC_PREFETCH_CONTROL, 0x0);
+ gpmc_write_reg(GPMC_PREFETCH_CONFIG1, 0x40 8);
+ gpmc_write_reg(GPMC_PREFETCH_CONFIG2, 0x0);
+}
+
+/*
+ * gpmc_prefetch_start - configures and starts prefetch transfer
+ * @cs - nand cs (chip select) number
+ * @dma_mode: dma mode enable (1) or disable (0)
+ * @u32_count: number of bytes to be transferred
+ * @is_write: prefetch read(0) or write post(1) mode
+ */
+void gpmc_prefetch_start(int cs, int dma_mode,
+ unsigned int u32_count, int is_write)
+{
+ uint32_t prefetch_config1;
+ if (is_write) {
+ /* Set the amount of bytes to be prefetched */
+ gpmc_write_reg(GPMC_PREFETCH_CONFIG2, u32_count);
+
+ /* Set dma/mpu mode, the post write and enable the engine
+* Set which cs is using the post write
+*/
+ prefetch_config1 = gpmc_read_reg(GPMC_PREFETCH_CONFIG1);
+ prefetch_config1 |= ((cs CS_NUM_SHIFT) |
+ (dma_mode DMA_MPU_MODE) |
+ (1 ENABLE_PREFETCH) | 0x1);
+ gpmc_write_reg(GPMC_PREFETCH_CONFIG1, prefetch_config1);
+ } else {
+ /* Set the amount of bytes to be prefetched */
+ gpmc_write_reg(GPMC_PREFETCH_CONFIG2, u32_count);
+
+ /* Set dma/mpu mode, the prefech read and enable the engine
+* Set which cs is using the prefetch
+*/
+ prefetch_config1 = gpmc_read_reg(GPMC_PREFETCH_CONFIG1);
+ prefetch_config1 |= (((cs CS_NUM_SHIFT) |
+ (dma_mode DMA_MPU_MODE) |
+ (1 ENABLE_PREFETCH)) ~0x1);
+ gpmc_write_reg(GPMC_PREFETCH_CONFIG1, prefetch_config1);
+ }
+ /* Start the prefetch engine */
+ gpmc_write_reg(GPMC_PREFETCH_CONTROL, 0x1);
+}
+EXPORT_SYMBOL(gpmc_prefetch_start);
+
+/*
+ * gpmc_prefetch_stop - disables and stops the prefetch engine
+ */
+void gpmc_prefetch_stop(void)
+{
+ uint32_t prefetch_config1;
+ /* stop the PFPW engine */
+ gpmc_write_reg(GPMC_PREFETCH_CONTROL, 0x0);
+
+ /* Disable the PFPW engine */
+ prefetch_config1 = gpmc_read_reg(GPMC_PREFETCH_CONFIG1);
+ prefetch_config1 = ~((0x07 CS_NUM_SHIFT) |
+ (1 ENABLE_PREFETCH) |
+ (1 DMA_MPU_MODE) | 0x1);
+ gpmc_write_reg(GPMC_PREFETCH_CONFIG1, prefetch_config1);
+}
+EXPORT_SYMBOL(gpmc_prefetch_stop);
+
+/*
+ * gpmc_prefetch_status - reads prefetch status of engine
+ */
+int gpmc_prefetch_status(void)
+{
+ return gpmc_read_reg(GPMC_PREFETCH_STATUS);
+}
+EXPORT_SYMBOL(gpmc_prefetch_status);
+#else
+int gpmc_prefetch_status(void) {return 0; }
+void gpmc_prefetch_stop(void) {}
+void gpmc_prefetch_start(int cs, int dma_mode, unsigned int u32_count,
+ int is_write) {}
+#endif
+
static void __init gpmc_mem_init(void)
{
int cs;
@@ -462,6 +554,9 @@
gpmc_freq_cfg.freq_cfg = NULL;
gpmc_freq_cfg.total_no_of_freq = 0;
#endif
+#ifdef CONFIG_MTD_NAND_OMAP_PREFETCH
+ gpmc_prefetch_init();
+#endif
gpmc_mem_init();
}
Index: omapkernel/arch/arm/plat-omap/include/mach/gpmc.h
===
--- omapkernel.orig/arch/arm/plat-omap/include/mach/gpmc.h
[PATCH - Omapzoom][ONENAND] Add synchronous burst support
From: Vimal Singh [EMAIL PROTECTED]
Following patch taken over the omapzoom.org tree adds
synchronous burst read support to the OMAP2/3 onenand driver.
Signed-off-by: Vimal Singh [EMAIL PROTECTED]
Signed-off-by: Nishant Kamat [EMAIL PROTECTED]
---
arch/arm/mach-omap2/board-3430sdp-flash.c | 59 +++---
drivers/mtd/onenand/Kconfig |6 +++
2 files changed, 60 insertions(+), 5 deletions(-)
Index: omapkernel/drivers/mtd/onenand/Kconfig
===
--- omapkernel.orig/drivers/mtd/onenand/Kconfig 2008-09-08 12:35:43.0
+0530
+++ omapkernel/drivers/mtd/onenand/Kconfig 2008-09-08 13:00:39.0
+0530
@@ -70,4 +70,10 @@
The simulator may simulate various OneNAND flash chips for the
OneNAND MTD layer.
+config MTD_ONENAND_SYNC_BURST_READ
+ bool OneNand Synchronous burst read support
+ help
+ Support for synchronous burst reads for a OneNand flash
+ device
+
endif # MTD_ONENAND
Index: omapkernel/arch/arm/mach-omap2/board-3430sdp-flash.c
===
--- omapkernel.orig/arch/arm/mach-omap2/board-3430sdp-flash.c 2008-09-08
12:35:43.0 +0530
+++ omapkernel/arch/arm/mach-omap2/board-3430sdp-flash.c2008-09-08
13:00:39.0 +0530
@@ -76,8 +76,16 @@
};
struct gpmc_cs_config pdc_onenand_gpmc_setting[] = {
+#ifdef CONFIG_MTD_ONENAND_SYNC_BURST_READ
+ {0x60801200, 0xF0900, 0x00030200, 0x0F040901, 0x0109100A, 0x1F06},
+#else
{0x1200, 0x000F0F01, 0x00030301, 0x0F040F04, 0x010F1010, 0x1F06},
+#endif
+#ifdef CONFIG_MTD_ONENAND_SYNC_BURST_READ
+ {0x62801201, 0xF1000, 0x00030200, 0x0F041002, 0x02101013, 0x1F06}
+#else
{0x1200, 0x000F0F01, 0x00030301, 0x0F040F04, 0x010F1010, 0x1F06}
+#endif
};
struct gpmc_cs_config fpga_gpmc_setting[] = {
@@ -252,15 +260,56 @@
.resource = sdp_nand_resource,
};
-/*
- * sdp_onenand_setup - The function configures the onenand flash.
- * @onenand_base: Onenand base address
+static unsigned short omap2_onenand_readw(void __iomem *addr)
+{
+ return readw(addr);
+}
+
+static void omap2_onenand_writew(unsigned short value, void __iomem *addr)
+{
+ writew(value, addr);
+}
+
+static int omap2_onenand_set_sync_mode(int cs, void __iomem *onenand_base,
+ int freq)
+{
+#ifdef CONFIG_MTD_ONENAND_SYNC_BURST_READ
+ u32 reg;
+
+ /* Configure OneNAND for sync read */
+ reg = omap2_onenand_readw(onenand_base + ONENAND_REG_SYS_CFG1);
+ reg = ~((0x7 ONENAND_SYS_CFG1_BRL_SHIFT) | (0x7 9));
+ reg |= (0x06 ONENAND_SYS_CFG1_BRL_SHIFT) |
+ ONENAND_SYS_CFG1_SYNC_READ |
+ ONENAND_SYS_CFG1_BL_8 | 0x04;
+ omap2_onenand_writew(reg, onenand_base + ONENAND_REG_SYS_CFG1);
+
+ gpmc_cs_write_reg(cs, GPMC_CS_CONFIG2, 0xf1000);
+ gpmc_cs_write_reg(cs, GPMC_CS_CONFIG3, 0x00030200);
+ gpmc_cs_write_reg(cs, GPMC_CS_CONFIG4, 0x0f041002);
+ gpmc_cs_write_reg(cs, GPMC_CS_CONFIG5, 0x02101013);
+ gpmc_cs_write_reg(cs, GPMC_CS_CONFIG6, 0x1f06);
+ gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1, 0x62801201);
+#endif
+ return 0;
+}
+
+/**
+ * sdp_onenand_setup - Set the onenand sync mode
+ * @onenand_base: The onenand base address in GPMC memory map
*
- * @return int:Currently always returning zero.
*/
static int sdp_onenand_setup(void __iomem *onenand_base, int freq)
{
- /* Onenand setup does nothing at present */
+ struct omap_onenand_platform_data *datap = sdp_onenand_data;
+ struct device *dev = sdp_onenand_device.dev;
+
+ /* Set sync timings in GPMC */
+ if (omap2_onenand_set_sync_mode(datap-cs, onenand_base, freq) 0) {
+ dev_err(dev, Unable to set synchronous mode\n);
+ return -EINVAL;
+ }
+
return 0;
}
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Resend][PATCH - Omapzoom][NAND] Add prefetch and DMA support
On Mon, Sep 08, 2008 at 01:03:35PM -0500, [EMAIL PROTECTED] wrote:
+#ifdef CONFIG_MTD_NAND_OMAP_PREFETCH
+ static int use_prefetch = 1;
+
+ /* modprobe ... use_prefetch=0 etc */
+ module_param(use_prefetch, bool, 0);
+ MODULE_PARM_DESC(use_prefetch, enable/disable use of PREFETCH);
Don't indent C code just because there's preprocessor stuff around it.
@@ -127,6 +148,9 @@
unsigned long phys_base;
void __iomem*gpmc_cs_baseaddr;
void __iomem*gpmc_baseaddr;
+ void __iomem*nand_pref_fifo_add;
Ok, nand_pref_fifo_add is MMIO.
+ struct completion comp;
+ int dma_ch;
};
/*
@@ -190,6 +214,85 @@
__raw_writeb(cmd, info-nand.IO_ADDR_W);
}
+#ifdef CONFIG_MTD_NAND_OMAP_PREFETCH_DMA
+/*
+ * omap_nand_dma_cb: callback on the completion of dma transfer
+ * @lch: logical channel
+ * @ch_satuts: channel status
+ * @data: pointer to completion data structure
+ */
+static void omap_nand_dma_cb(int lch, u16 ch_status, void *data)
+{
+ complete((struct completion *) data);
+}
+
+/*
+ * omap_nand_dma_transfer: configer and start dma transfer
+ * @mtd: MTD device structure
+ * @addr: virtual address in RAM of source/destination
+ * @count: number of data bytes to be transferred
+ * @is_write: flag for read/write operation
+ */
+static inline int omap_nand_dma_transfer(struct mtd_info *mtd, void *addr,
+ unsigned int count, int is_write)
+{
+ struct omap_nand_info *info = container_of(mtd,
+ struct omap_nand_info, mtd);
+
+ uint32_t prefetch_status = 0;
+
+ /* The fifo depth is 64 bytes. We have a synch at each frame and frame
+ * length is 64 bytes.
+ */
+ int buf_len = count/64;
+
+ if (is_write) {
+ omap_set_dma_dest_params(info-dma_ch, 0, OMAP_DMA_AMODE_CONSTANT,
+ info-phys_base, 0, 0);
+ omap_set_dma_dest_burst_mode(info-dma_ch, OMAP_DMA_DATA_BURST_16);
+ omap_set_dma_src_params(info-dma_ch, 0, OMAP_DMA_AMODE_POST_INC,
+ virt_to_phys(addr), 0, 0);
+ omap_set_dma_src_burst_mode(info-dma_ch, OMAP_DMA_DATA_BURST_16);
+ omap_set_dma_transfer_params(info-dma_ch, OMAP_DMA_DATA_TYPE_S32,
+ 0x10, buf_len, OMAP_DMA_SYNC_FRAME,
+ OMAP24XX_DMA_GPMC, OMAP_DMA_DST_SYNC);
+ } else {
+ omap_set_dma_src_params(info-dma_ch, 0, OMAP_DMA_AMODE_CONSTANT,
+ info-phys_base, 0, 0);
+ omap_set_dma_src_burst_mode(info-dma_ch, OMAP_DMA_DATA_BURST_16);
+ omap_set_dma_dest_params(info-dma_ch, 0, OMAP_DMA_AMODE_POST_INC,
+ virt_to_phys(addr), 0, 0);
+ omap_set_dma_dest_burst_mode(info-dma_ch, OMAP_DMA_DATA_BURST_16);
+ omap_set_dma_transfer_params(info-dma_ch, OMAP_DMA_DATA_TYPE_S32,
+ 0x10, buf_len, OMAP_DMA_SYNC_FRAME,
+ OMAP24XX_DMA_GPMC, OMAP_DMA_SRC_SYNC);
+ }
+
+ /* configure and start prefetch transfer */
+ gpmc_prefetch_start(info-gpmc_cs, 0x1, count, is_write);
+ init_completion(info-comp);
+ dma_sync_single_for_cpu(info-pdev-dev,
+ virt_to_phys(addr), count, DMA_TO_DEVICE);
Please read the DMA API and use the proper functions. This is an abuse
of the DMA API.
+ omap_start_dma(info-dma_ch);
+ wait_for_completion(info-comp);
+ if (!is_write)
+ dma_sync_single_for_cpu(info-pdev-dev,
+ virt_to_phys(addr), count, DMA_FROM_DEVICE);
Ditto. This is an abuse of the API. This is how it's supposed to work:
enum dma_direction dir = is_write ? DMA_TO_DEVICE : DMA_FROM_DEVICE;
dma_addr_t dma_addr;
dma_addr = dma_map_single(info-pdev-dev, addr, count, dir);
/* setup and start DMA using dma_addr */
wait_for_completion(info-comp);
dma_unmap_single(info-pdev-dev, dma_addr, count, dir);
+ prefetch_status = gpmc_prefetch_status();
+ while (prefetch_status 0x3FFF)
+ prefetch_status = gpmc_prefetch_status();
+
+ /* disable and stop the PFPW engine */
+ gpmc_prefetch_stop();
+ return 0;
+}
+#else
+static void omap_nand_dma_cb(int lch, u16 ch_status, void *data) {}
+static inline int omap_nand_dma_transfer(struct mtd_info *mtd, void *addr,
+ unsigned int count, int is_write)
+{return 0; }
+#endif
+
/*
* omap_read_buf - read data from NAND controller into buffer
* @mtd: MTD device structure
@@ -201,11 +304,33 @@
struct omap_nand_info *info =
Re: [alsa-devel] [PATCH 3/5] ALSA: ASoC: Add support for TWL4030 audio codec (rev 3)
On Mon, Sep 8, 2008 at 2:56 AM, Mark Brown [EMAIL PROTECTED] wrote: On Sat, Sep 06, 2008 at 11:41:42PM -0700, [EMAIL PROTECTED] wrote: + +config SND_SOC_TWL4030 + tristate + depends on SND_SOC I2C + Sorry, didn't notice earlier: this should depend on whatever the config option is for the TWL4030 core driver rather than on I2C since it doesn't actually interact with I2C directly. Although in most applications this won't make much odds since the machine driver will select the codec driver and select ignores the dependencies anyway. You are correct. Good catch, though as you say it doesn't really matter in practice. I will re-submit a version with this fixed nonetheless. Steve -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]Add 3430 SDP board level support for HSMMC2
On Wednesday 13 August 2008, Madhusudhan Chikkature wrote: A better way to do this would be to let the boards say exactly what the hardware configuration is, rather than requiring all OMAP3 boards to be set up exactly like the SDP... I think the initial version was written specific to SDP. Later on it was changed to hsmmc.c and the platforms which required simillar setup as SDP started using it. Right ... Now, if support for a new board is required which is unlike SDP a new file can still be added for that perticular board, right? Each board already gets a board-XYZ.c file. So the clean way to do this is to have that file set up its hsmmc config ... NOT to clone versions of hsmmc.c for each board! -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omapfb: setting GOLCD bit for shadow registers to make effect
arun c [EMAIL PROTECTED] writes: A shadow register change has no direct effect on the display configuration until the GOLCD (DISPC_CONTROL[5]) is set. Signed-off-by: Arun C [EMAIL PROTECTED] --- drivers/video/omap/dispc.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/drivers/video/omap/dispc.c b/drivers/video/omap/dispc.c index 82ba030..2e7af85 100644 --- a/drivers/video/omap/dispc.c +++ b/drivers/video/omap/dispc.c @@ -436,6 +436,11 @@ static inline int _setup_plane(int plane, int channel_out, dispc_write_reg(ri_reg[plane], (screen_width - width) * bpp / 8 + 1); + /* Wait untill GOLCD bit is cleared and set it */ Nit: until (one l) + while (dispc_read_reg(DISPC_CONTROL) (1 5)) + continue; + MOD_REG_FLD(DISPC_CONTROL, 1 5, 1 5); + return height * screen_width * bpp / 8; } This looks good. However, the same thing is needed in omap_dispc_enable_plane() as well. Placing the loop+set in a function (go_lcd()?) would make sense. -- Måns Rullgård [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [PATCH 3/5] ALSA: ASoC: Add support for TWL4030 audio codec (rev 4)
From: Steve Sakoman [EMAIL PROTECTED]
Signed-off-by: Steve Sakoman [EMAIL PROTECTED]
Acked-by: Mark Brown [EMAIL PROTECTED]
---
sound/soc/codecs/Kconfig |5 +
sound/soc/codecs/Makefile |2 +
sound/soc/codecs/twl4030.c | 653
sound/soc/codecs/twl4030.h | 197 +
4 files changed, 857 insertions(+), 0 deletions(-)
create mode 100644 sound/soc/codecs/twl4030.c
create mode 100644 sound/soc/codecs/twl4030.h
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 1db04a2..2f00e1e 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -50,3 +50,8 @@ config SND_SOC_CS4270_VD33_ERRATA
config SND_SOC_TLV320AIC3X
tristate
depends on I2C
+
+config SND_SOC_TWL4030
+ tristate
+ depends on SND_SOC TWL4030_CORE
+
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index d7b97ab..a519ced 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -10,6 +10,7 @@ snd-soc-wm9712-objs := wm9712.o
snd-soc-wm9713-objs := wm9713.o
snd-soc-cs4270-objs := cs4270.o
snd-soc-tlv320aic3x-objs := tlv320aic3x.o
+snd-soc-twl4030-objs := twl4030.o
obj-$(CONFIG_SND_SOC_AC97_CODEC) += snd-soc-ac97.o
obj-$(CONFIG_SND_SOC_AK4535) += snd-soc-ak4535.o
@@ -23,3 +24,4 @@ obj-$(CONFIG_SND_SOC_WM9712) += snd-soc-wm9712.o
obj-$(CONFIG_SND_SOC_WM9713) += snd-soc-wm9713.o
obj-$(CONFIG_SND_SOC_CS4270) += snd-soc-cs4270.o
obj-$(CONFIG_SND_SOC_TLV320AIC3X) += snd-soc-tlv320aic3x.o
+obj-$(CONFIG_SND_SOC_TWL4030) += snd-soc-twl4030.o
diff --git a/sound/soc/codecs/twl4030.c b/sound/soc/codecs/twl4030.c
new file mode 100644
index 000..ee2f0d3
--- /dev/null
+++ b/sound/soc/codecs/twl4030.c
@@ -0,0 +1,653 @@
+/*
+ * ALSA SoC TWL4030 codec driver
+ *
+ * Author: Steve Sakoman, [EMAIL PROTECTED]
+ *
+ * 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/platform_device.h
+#include linux/i2c/twl4030.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 twl4030.h
+
+/*
+ * twl4030 register cache default register settings
+ */
+static const u8 twl4030_reg[TWL4030_CACHEREGNUM] = {
+ 0x00, /* this register not used */
+ 0x93, /* REG_CODEC_MODE (0x1) */
+ 0xc3, /* REG_OPTION (0x2) */
+ 0x00, /* REG_UNKNOWN(0x3) */
+ 0x00, /* REG_MICBIAS_CTL(0x4) */
+ 0x24, /* REG_ANAMICL(0x5) */
+ 0x04, /* REG_ANAMICR(0x6) */
+ 0x0a, /* REG_AVADC_CTL (0x7) */
+ 0x00, /* REG_ADCMICSEL (0x8) */
+ 0x00, /* REG_DIGMIXING (0x9) */
+ 0x0c, /* REG_ATXL1PGA (0xA) */
+ 0x0c, /* REG_ATXR1PGA (0xB) */
+ 0x00, /* REG_AVTXL2PGA (0xC) */
+ 0x00, /* REG_AVTXR2PGA (0xD) */
+ 0x01, /* REG_AUDIO_IF (0xE) */
+ 0x00, /* REG_VOICE_IF (0xF) */
+ 0x00, /* REG_ARXR1PGA (0x10) */
+ 0x00, /* REG_ARXL1PGA (0x11) */
+ 0x6c, /* REG_ARXR2PGA (0x12) */
+ 0x6c, /* REG_ARXL2PGA (0x13) */
+ 0x00, /* REG_VRXPGA (0x14) */
+ 0x00, /* REG_VSTPGA (0x15) */
+ 0x00, /* REG_VRX2ARXPGA (0x16) */
+ 0x0c, /* REG_AVDAC_CTL (0x17) */
+ 0x00, /* REG_ARX2VTXPGA (0x18) */
+ 0x00, /* REG_ARXL1_APGA_CTL (0x19) */
+ 0x00, /* REG_ARXR1_APGA_CTL (0x1A) */
+ 0x4b, /* REG_ARXL2_APGA_CTL (0x1B) */
+ 0x4b, /* REG_ARXR2_APGA_CTL (0x1C) */
+ 0x00, /* REG_ATX2ARXPGA (0x1D) */
+ 0x00, /* REG_BT_IF (0x1E) */
+ 0x00, /* REG_BTPGA (0x1F) */
+ 0x00, /* REG_BTSTPGA(0x20) */
+ 0x00, /* REG_EAR_CTL(0x21) */
+ 0x24, /* REG_HS_SEL (0x22) */
+ 0x0a, /* REG_HS_GAIN_SET(0x23) */
+ 0x00, /* REG_HS_POPN_SET(0x24) */
+ 0x00, /* REG_PREDL_CTL (0x25) */
+ 0x00,
Re: [PATCH - Omapzoom] [NAND] Add prefetch and DMA support
On Monday 08 September 2008, Kamat, Nishant wrote:
- while (len--)
- *p++ = cpu_to_le16(readw(info-nand.IO_ADDR_R));
+ if (use_prefetch) {
Em, clearly this does not go on top of the NAND patch I
sent recently ... please do that instead, so we don't
need to repeat the cleanups.
http://marc.info/?l=linux-omapm=122021756032341w=2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Resend][PATCH - Omapzoom][NAND] Add prefetch and DMA support
On Monday 08 September 2008, Russell King - ARM Linux wrote: - while (len--) - *p++ = cpu_to_le16(readw(info-nand.IO_ADDR_R)); This driver needs work (see endianness explaination below.) Already done, but this patch doesn't build on that patch... -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH - Omapzoom] [NAND] Add prefetch and DMA support
On Monday 08 September 2008, Kamat, Nishant wrote: +config MTD_NAND_OMAP_PREFETCH + bool GPMC prefetch support for NAND Flash device + depends on MTD_NAND MTD_NAND_OMAP2 + default n + help + The NAND device can be accessed for Read/Write using GPMC PREFETCH engine + to improve the performance. Is there a reason this isn't always enabled, and the choice is just whether to use DMA or not? I'd be interested to see performance measurements for the three cases. - current/slow code - the readsw() update I sent previously - this prefetch engine And I'd expect this prefetch engine code would also be improved by using readsw() and writesw() when DMA isn't in use. On one ARM926 I observed a 16% speedup *just* from switching from slow byte-at-a-time PIO to using readsb ... this current code has that same pessimization. - Dave + +choice + prompt Prefetch engine support for GPMC + depends on MTD_NAND_OMAP_PREFETCH + help + The GPMC PREFETCH engine can be configured eigther in MPU interrupt mode + or in DMA interrupt mode. + +config MTD_NAND_OMAP_PREFETCH_MPU + depends on MTD_NAND_OMAP_PREFETCH + bool MPU mode always for spare area + MPU mode for main area + help + Say y if... you want MPU interrupt mode for both spare area and main area accesses. + +config MTD_NAND_OMAP_PREFETCH_DMA + depends on MTD_NAND_OMAP_PREFETCH + bool MPU mode always for spare area + DMA mode for main area + help + Say y if... you want MPU interrupt mode for spare area and DMA mode for main + area access. + +endchoice + -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/2 rev2] McBSP and ASoC OMAP update patches for 2430 and 34xx
* Jarkko Nikula [EMAIL PROTECTED] [080908 03:30]: Here is second version of patch adding support for 2430 in McBSP driver. Updated version uses phys_base instead of virt_base. See following commits from Russell King: ecec3b3e080464cc1b4e792cf4d8e7e89d50b011 2cfd6fcda3b8c6ee7a5fa9a4573e3246532a0716 Second patch is the same than first version. It's for testing ASoC OMAP and eventually it will go through the alsa-devel. Thanks, pushing these to l-o tree. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [PATCH 3/5] ALSA: ASoC: Add support for TWL4030 audio codec (rev 3)
* Steve Sakoman [EMAIL PROTECTED] [080908 11:16]: On Mon, Sep 8, 2008 at 2:56 AM, Mark Brown [EMAIL PROTECTED] wrote: On Sat, Sep 06, 2008 at 11:41:42PM -0700, [EMAIL PROTECTED] wrote: + +config SND_SOC_TWL4030 + tristate + depends on SND_SOC I2C + Sorry, didn't notice earlier: this should depend on whatever the config option is for the TWL4030 core driver rather than on I2C since it doesn't actually interact with I2C directly. Although in most applications this won't make much odds since the machine driver will select the codec driver and select ignores the dependencies anyway. You are correct. Good catch, though as you say it doesn't really matter in practice. I will re-submit a version with this fixed nonetheless. Pushing this series to linux-omap today with the re-submitted version of patch 3/5. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2.6.27-rc3-omap1] omap2_nand updates
* Felipe Balbi [EMAIL PROTECTED] [080831 14:54]:
On Sun, Aug 31, 2008 at 02:19:05PM -0700, David Brownell wrote:
From: David Brownell [EMAIL PROTECTED]
Minor updates to the OMAP{2,3} NAND driver:
- Rename those buffer PIO routines as *_buf16()
- Get rid of pointless LE16 data conversions; OMAP is always LE
- Speed up buffer reads by switching to __raw_readsl()
Right now this driver only handles 16-bit NAND, but eventually it
should handle 8-bit too. Moreover it may be worth using DMA...
Signed-off-by: David Brownell [EMAIL PROTECTED]
Thanks Dave, I'll melded it up in my queue.
Pushing to linux-omap tree today.
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HyperSPARC RT625 Cache Controler, Ross CY7C605 Cache Controler, Cache Aliases, and Linux MM Code
From: Piet Delaney [EMAIL PROTECTED] Date: Mon, 08 Sep 2008 22:07:26 -0700 Wonder why the update_mmu_cache() for sun4c has to do so much more work that sun4m. Caches are virtually indexed and virtually tagged on sun4c, that's why. Keep on wonderin' Wonder why SPARC has to do more work that ARM. ARMs that have the cache issues aren't SMP, that's why. Keep on wonderin' -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/12] CORE OFF support in omap_sram_idle
Hello Rajendra, one more comment from me...
ext Rajendra Nayak [EMAIL PROTECTED] writes:
struct omap3_processor_cx omap3_power_states[OMAP3_MAX_STATES];
Index: linux-omap-2.6/arch/arm/mach-omap2/pm34xx.c
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/pm34xx.c 2008-09-01
18:23:19.0 +0530
+++ linux-omap-2.6/arch/arm/mach-omap2/pm34xx.c 2008-09-01
18:24:02.0
+0530
@@ -27,10 +27,13 @@
#include mach/gpio.h
#include mach/sram.h
#include mach/pm.h
+#include mach/prcm.h
#include mach/clockdomain.h
#include mach/powerdomain.h
#include mach/common.h
#include mach/control.h
+#include mach/serial.h
+#include mach/gpio.h
#include asm/tlbflush.h
#include cm.h
@@ -58,6 +61,7 @@ static struct powerdomain *mpu_pwrdm, *n
static struct powerdomain *core_pwrdm, *per_pwrdm;
int set_pwrdm_state(struct powerdomain *pwrdm, u32 state);
+void omap3_restore_sram_ctx(void);
u32 context_mem[128];
@@ -91,6 +95,16 @@ static void gpio_fclk_mask(u32 *fclk)
*fclk = ~(0x1f 13);
}
+void omap3_save_per_ctx(void)
+{
+ omap3_gpio_save();
+}
+
+void omap3_restore_per_ctx(void)
+{
+ omap3_gpio_restore();
+}
+
/* PRCM Interrupt Handler for wakeups */
static irqreturn_t prcm_interrupt_handler (int irq, void *dev_id)
{
@@ -225,6 +239,7 @@ void omap_sram_idle(void)
int mpu_next_state = PWRDM_POWER_ON;
int per_next_state = PWRDM_POWER_ON;
int core_next_state = PWRDM_POWER_ON;
+ int core_prev_state, per_prev_state;
if (!_omap_sram_idle)
return;
@@ -261,15 +276,27 @@ void omap_sram_idle(void)
/* PER changes only with core */
per_next_state = pwrdm_read_next_pwrst(per_pwrdm);
if (per_next_state PWRDM_POWER_ON) {
+ if (per_next_state == PWRDM_POWER_OFF) {
+ omap3_save_per_ctx();
+ omap3_save_uart_ctx(2);
+ }
if (clocks_off_while_idle) {
per_gpio_clk_disable();
omap_serial_enable_clocks(0, 2);
}
}
+ if (core_next_state == PWRDM_POWER_OFF) {
+ omap3_save_core_ctx();
+ omap3_save_prcm_ctx();
Prcm is saved twice, once here...
+ omap3_save_uart_ctx(0);
+ omap3_save_uart_ctx(1);
+ }
if (clocks_off_while_idle) {
omap_serial_enable_clocks(0, 0);
omap_serial_enable_clocks(0, 1);
}
+ if (core_next_state == PWRDM_POWER_OFF)
+ omap3_save_prcm_ctx();
And then again here.
--
Jouni Högander
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
