RE: [PATCH] OMAP3: Fix McBSP poll read and write for 32bit reg access
snip
-Original Message-
From: Varadarajan, Charu Latha
Sent: Thursday, October 15, 2009 10:59 AM
To: Shilimkar, Santosh; linux-omap@vger.kernel.org
Cc: Syed, Rafiuddin
Subject: RE: [PATCH] OMAP3: Fix McBSP poll read and write for 32bit reg
access
__
Subject: RE: [PATCH] OMAP3: Fix McBSP poll read and write for
32bit reg access
Charu,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Varadarajan, Charu Latha
Sent: Wednesday, October 14, 2009 3:00 PM
To: linux-omap@vger.kernel.org
Cc: Varadarajan, Charu Latha; Syed, Rafiuddin
Subject: [PATCH] OMAP3: Fix McBSP poll read and write for
32bit reg access
omap_mcbsp_pollwrite and omap_mcbsp_pollread functions access
McBSP registers as 16-bit registers.
The McBSP registers (DRR_REG and DXR_REG) are limited to
32-bit data accesses (L4 Interconnect). 16-bit and 8-bit is
not allowed and can corrupt register content.
This patch modifies omap_mcbsp_pollwrite and
omap_mcbsp_pollread functions to do 32 bit access for above
mentioned McBSP registers. Data accepted by these
functions is also modified to 32-bit.
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Syed Rafiuddin rafiuddin.s...@ti.com
---
arch/arm/plat-omap/include/mach/mcbsp.h |4 +-
arch/arm/plat-omap/mcbsp.c | 46
++
-
2 files changed, 23 insertions(+), 27 deletions(-)
diff --git a/arch/arm/plat-omap/include/mach/mcbsp.h
b/arch/arm/plat-
omap/include/mach/mcbsp.h
index 7e9cae3..05b0d8d 100644
--- a/arch/arm/plat-omap/include/mach/mcbsp.h
+++ b/arch/arm/plat-omap/include/mach/mcbsp.h
@@ -455,8 +455,8 @@ int
omap_mcbsp_spi_master_recv_word_poll(unsigned int
id, u32 * word);
void omap_mcbsp_set_spi_mode(unsigned int id, const struct
omap_mcbsp_spi_cfg * spi_cfg);
/* Polled read/write functions */
-int omap_mcbsp_pollread(unsigned int id, u16 * buf);
-int omap_mcbsp_pollwrite(unsigned int id, u16 buf);
+int omap_mcbsp_pollread(unsigned int id, u32 *buf);
+int omap_mcbsp_pollwrite(unsigned int id, u32 buf);
If the issue is with DRR_REG and DXR_REG, why are you
changing the signature of the generic API. You can handle
these registers as a exceptions in the code.
If 32 bit data could be read and written on McBSP, why should we
restrict
poll read and
poll write functions only for 16 bit data read and write?
If these API's are only accessing the DXR and DRR regs then this is OK.
int omap_mcbsp_set_io_type(unsigned int id, omap_mcbsp_io_type_t
io_type);
#endif
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-
omap/mcbsp.c
index 88ac976..1f278a2 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -613,7 +613,7 @@ void omap_mcbsp_stop(unsigned int id,
int tx, int rx)
EXPORT_SYMBOL(omap_mcbsp_stop);
/* polled mcbsp i/o operations */
-int omap_mcbsp_pollwrite(unsigned int id, u16 buf)
+int omap_mcbsp_pollwrite(unsigned int id, u32 buf)
{
struct omap_mcbsp *mcbsp;
void __iomem *base;
@@ -626,26 +626,24 @@ int omap_mcbsp_pollwrite(unsigned int
id, u16 buf)
mcbsp = id_to_mcbsp_ptr(id);
base = mcbsp-io_base;
- writew(buf, base + OMAP_MCBSP_REG_DXR1);
+ OMAP_MCBSP_WRITE(base, DXR, buf);
Why do you need this? Is writew()/readw() not doing 16 bit
operations ?
The intension is to use 32 bit access and not 16 bit access
Use readl() / writel() then.
Yes, OMAP_MCBSP_WRITE macro makes use of readl() / writel() for OMAP3
Good!! Then get rid of this macro and directly use kernel standard API- readl()
/ writel()
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] ARM: OMAP: SDMA: Fix omap_stop_dma() API for channel linking
OMAP sDMA driver API omap_stop_dma() doesn't really stop the dma when used in linking scenario. This patch fixes the same. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Venkatraman S svenk...@ti.com Reviewed-By: Tony Lindgren t...@atomide.com CC: Hari n hari.z...@gmail.com CC: Jarkko Nikula jhnik...@gmail.com --- arch/arm/plat-omap/dma.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c index fd3154a..1c933b4 100644 --- a/arch/arm/plat-omap/dma.c +++ b/arch/arm/plat-omap/dma.c @@ -987,6 +987,11 @@ void omap_stop_dma(int lch) /* Mark the current channel */ dma_chan_link_map[cur_lch] = 1; + /* Disable the DMA channel */ + l = dma_read(CCR(lch)); + l = ~OMAP_DMA_CCR_EN; + dma_write(l, CCR(lch)); + disable_lnk(cur_lch); next_lch = dma_chan[cur_lch].next_lch; -- 1.5.4.7 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3: Fix McBSP poll read and write for 32bit reg access
On Thursday 15 October 2009 09:10:54 ext Shilimkar, Santosh wrote: - writew(buf, base + OMAP_MCBSP_REG_DXR1); + OMAP_MCBSP_WRITE(base, DXR, buf); Why do you need this? Is writew()/readw() not doing 16 bit operations ? The intension is to use 32 bit access and not 16 bit access Use readl() / writel() then. Yes, OMAP_MCBSP_WRITE macro makes use of readl() / writel() for OMAP3 Good!! Then get rid of this macro and directly use kernel standard API- readl() / writel() -- Well, OMAP1 and OMAP2 still has 16 bit registers in McBSP. -- Péter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP3: Fix McBSP poll read and write for 32bit reg access
Charu, -Original Message- From: Peter Ujfalusi [mailto:peter.ujfal...@nokia.com] Sent: Thursday, October 15, 2009 12:56 PM To: Shilimkar, Santosh Cc: Varadarajan, Charu Latha; linux-omap@vger.kernel.org; Syed, Rafiuddin Subject: Re: [PATCH] OMAP3: Fix McBSP poll read and write for 32bit reg access On Thursday 15 October 2009 09:10:54 ext Shilimkar, Santosh wrote: - writew(buf, base + OMAP_MCBSP_REG_DXR1); + OMAP_MCBSP_WRITE(base, DXR, buf); Why do you need this? Is writew()/readw() not doing 16 bit operations ? The intension is to use 32 bit access and not 16 bit access Use readl() / writel() then. Yes, OMAP_MCBSP_WRITE macro makes use of readl() / writel() for OMAP3 Good!! Then get rid of this macro and directly use kernel standard API- readl() / writel() -- Well, OMAP1 and OMAP2 still has 16 bit registers in McBSP. Please look at this comment from Peter. So please reconsider your patch and decision of changing the signature of the API since it breaks OMAP1 and OMAP2. 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] [PATCH 5/8] board-rx51-peripherals: split vaux3 and vmmc2 supplies
On Wed, Oct 14, 2009 at 10:15:48AM -0700, Tony Lindgren wrote: * Mark Brown broo...@opensource.wolfsonmicro.com [091012 02:18]: On Mon, Oct 12, 2009 at 11:08:58AM +0300, Eduardo Valentin wrote: I'm afraid using dev_name is not that easy. The mmc driver generates device name at runtime. That's why this board file setups .dev at runtime as well. ... So, changing this supply to something static using .dev_name it is not possible with current code. That would need refactoring the whole mmc and hsmmc setup. And the device naming procedure is dependent on cpu as well. Check arch/arm/mach-omap2/device.c:omap2_init_mmc. same answer each time it's run? How does this work with the clock API? The clocks are matched using clkdev. Basically the driver just requests functional clock (fck) and interface clock (ick): $ grep mmci arch/arm/*omap*/clock*.c arch/arm/mach-omap1/clock.c: CLK(mmci-omap.0, fck, mmc1_ck, CK_16XX | CK_1510 | CK_310), arch/arm/mach-omap1/clock.c: CLK(mmci-omap.0, ick, armper_ck.clk, CK_16XX | CK_1510 | CK_310), So this is using the standard dev_name based clkdev matching which Eduardo said was impossible for the regulators. Is it just that this will actually work fine for the regulators or is there some other magic in the OMAP code that joins things up? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2] OMAP3: introduce OMAP3630
Muxes for OMAP 3630.
Signed-off-by: Allen Pais allen.p...@ti.com
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index b5fac32..93abb74 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -551,6 +551,42 @@ MUX_CFG_34XX(AF13_3430_MMC3_DAT3, 0x5e2,
MUX_CFG_34XX(AF26_34XX_SYS_NIRQ, 0x1E0,
OMAP3_WAKEUP_EN | OMAP34XX_PIN_INPUT_PULLUP |
OMAP34XX_MUX_MODE0)
+
+/*Muxes for 3630 */
+MUX_CFG_34XX(H26_3630_DSS_DATA18, 0x100,
+ OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLDOWN)
+MUX_CFG_34XX(H25_3630_DSS_DATA19, 0x102,
+ OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLDOWN)
+MUX_CFG_34XX(E28_3630_DSS_DATA20, 0x104,
+ OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLDOWN)
+MUX_CFG_34XX(J26_3630_DSS_DATA21, 0x106,
+ OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLDOWN)
+MUX_CFG_34XX(AC27_3630_DSS_DATA22, 0x108,
+ OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLDOWN)
+MUX_CFG_34XX(AC28_3630_DSS_DATA23, 0x10A,
+ OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLDOWN)
+
+MUX_CFG_34XX(AF9_3630_ETKD8, 0x5EC,
+ OMAP34XX_MUX_MODE1 | OMAP34XX_PIN_INPUT_PULLDOWN)
+MUX_CFG_34XX(AG9_3630_ETKD9, 0x5EE,
+ OMAP34XX_MUX_MODE1 | OMAP34XX_PIN_INPUT_PULLDOWN)
+MUX_CFG_34XX(AG7_3630_ETKD12, 0x5F0,
+ OMAP34XX_MUX_MODE1 | OMAP34XX_PIN_INPUT_PULLDOWN)
+
+MUX_CFG_34XX(AA25_3630_UART2_TX, 0x178,
+ OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULLDOWN)
+MUX_CFG_34XX(AD25_3630_UART2_RX, 0x17A,
+ OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULLDOWN)
+MUX_CFG_34XX(AB25_3630_UART2_RTS, 0x176,
+ OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULLDOWN)
+MUX_CFG_34XX(AB26_3630_UART2_CTS, 0x174,
+ OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULLDOWN)
+
+MUX_CFG_34XX(H20_UART3_RX_IRRX, 0x19E,
+ OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLDOWN)
+MUX_CFG_34XX(H21_UART3_TX_IRTX, 0x1A0,
+ OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLDOWN)
+
};
#define OMAP34XX_PINS_SZ ARRAY_SIZE(omap34xx_pins)
diff --git a/arch/arm/plat-omap/include/mach/mux.h
b/arch/arm/plat-omap/include/mach/mux.h
index 0f49d2d..8d8cbe1 100644
--- a/arch/arm/plat-omap/include/mach/mux.h
+++ b/arch/arm/plat-omap/include/mach/mux.h
@@ -890,6 +890,32 @@ enum omap34xx_index {
/* SYS_NIRQ T2 INT1 */
AF26_34XX_SYS_NIRQ,
+
+ /*Muxes for 3630*/
+ K28_3630_CAM_D6,
+ L28_3630_CAM_D7,
+ K27_3630_CAM_D8,
+ L27_3630_CAM_D9,
+
+ H26_3630_DSS_DATA18,
+ H25_3630_DSS_DATA19,
+ E28_3630_DSS_DATA20,
+ J26_3630_DSS_DATA21,
+ AC27_3630_DSS_DATA22,
+ AC28_3630_DSS_DATA23,
+
+ AF9_3630_ETKD8,
+ AG9_3630_ETKD9,
+ AG7_3630_ETK12,
+
+ AA25_3630_UART2_TX,
+ AD25_3630_UART2_RX,
+ AB25_3630_UART2_RTS,
+ AB26_3630_UART2_CTS,
+
+ H20_UART3_RX_IRRX,
+ H21_UART3_TX_IRTX,
+
};
struct omap_mux_cfg {--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][Patch V1] OMAP3: Mux Changes.
Please ignore my previous mail.
Muxes for OMAP 3630.
Signed-off-by: Allen Pais allen.p...@ti.com diff --git
a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c index b5fac32..93abb74
100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -551,6 +551,42 @@ MUX_CFG_34XX(AF13_3430_MMC3_DAT3, 0x5e2,
MUX_CFG_34XX(AF26_34XX_SYS_NIRQ, 0x1E0,
OMAP3_WAKEUP_EN | OMAP34XX_PIN_INPUT_PULLUP |
OMAP34XX_MUX_MODE0)
+
+/*Muxes for 3630 */
+MUX_CFG_34XX(H26_3630_DSS_DATA18, 0x100,
+ OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLDOWN)
+MUX_CFG_34XX(H25_3630_DSS_DATA19, 0x102,
+ OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLDOWN)
+MUX_CFG_34XX(E28_3630_DSS_DATA20, 0x104,
+ OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLDOWN)
+MUX_CFG_34XX(J26_3630_DSS_DATA21, 0x106,
+ OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLDOWN)
+MUX_CFG_34XX(AC27_3630_DSS_DATA22, 0x108,
+ OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLDOWN)
+MUX_CFG_34XX(AC28_3630_DSS_DATA23, 0x10A,
+ OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLDOWN)
+
+MUX_CFG_34XX(AF9_3630_ETKD8, 0x5EC,
+ OMAP34XX_MUX_MODE1 | OMAP34XX_PIN_INPUT_PULLDOWN)
+MUX_CFG_34XX(AG9_3630_ETKD9, 0x5EE,
+ OMAP34XX_MUX_MODE1 | OMAP34XX_PIN_INPUT_PULLDOWN)
+MUX_CFG_34XX(AG7_3630_ETKD12, 0x5F0,
+ OMAP34XX_MUX_MODE1 | OMAP34XX_PIN_INPUT_PULLDOWN)
+
+MUX_CFG_34XX(AA25_3630_UART2_TX, 0x178,
+ OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULLDOWN)
+MUX_CFG_34XX(AD25_3630_UART2_RX, 0x17A,
+ OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULLDOWN)
+MUX_CFG_34XX(AB25_3630_UART2_RTS, 0x176,
+ OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULLDOWN)
+MUX_CFG_34XX(AB26_3630_UART2_CTS, 0x174,
+ OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULLDOWN)
+
+MUX_CFG_34XX(H20_UART3_RX_IRRX, 0x19E,
+ OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLDOWN)
+MUX_CFG_34XX(H21_UART3_TX_IRTX, 0x1A0,
+ OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLDOWN)
+
};
#define OMAP34XX_PINS_SZ ARRAY_SIZE(omap34xx_pins)
diff --git a/arch/arm/plat-omap/include/mach/mux.h
b/arch/arm/plat-omap/include/mach/mux.h
index 0f49d2d..8d8cbe1 100644
--- a/arch/arm/plat-omap/include/mach/mux.h
+++ b/arch/arm/plat-omap/include/mach/mux.h
@@ -890,6 +890,32 @@ enum omap34xx_index {
/* SYS_NIRQ T2 INT1 */
AF26_34XX_SYS_NIRQ,
+
+ /*Muxes for 3630*/
+ K28_3630_CAM_D6,
+ L28_3630_CAM_D7,
+ K27_3630_CAM_D8,
+ L27_3630_CAM_D9,
+
+ H26_3630_DSS_DATA18,
+ H25_3630_DSS_DATA19,
+ E28_3630_DSS_DATA20,
+ J26_3630_DSS_DATA21,
+ AC27_3630_DSS_DATA22,
+ AC28_3630_DSS_DATA23,
+
+ AF9_3630_ETKD8,
+ AG9_3630_ETKD9,
+ AG7_3630_ETK12,
+
+ AA25_3630_UART2_TX,
+ AD25_3630_UART2_RX,
+ AB25_3630_UART2_RTS,
+ AB26_3630_UART2_CTS,
+
+ H20_UART3_RX_IRRX,
+ H21_UART3_TX_IRTX,
+
};
struct omap_mux_cfg {--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2] OMAP3: introduce OMAP3630
Muxes for OMAP 3630.
What is the plan to add omap_cfg_reg calls for these new pins, which actually
configures these pin muxes.
Thanks
Hemanth
Signed-off-by: Allen Pais allen.p...@ti.com
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index b5fac32..93abb74 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -551,6 +551,42 @@ MUX_CFG_34XX(AF13_3430_MMC3_DAT3, 0x5e2,
MUX_CFG_34XX(AF26_34XX_SYS_NIRQ, 0x1E0,
OMAP3_WAKEUP_EN | OMAP34XX_PIN_INPUT_PULLUP |
OMAP34XX_MUX_MODE0)
+
+/*Muxes for 3630 */
+MUX_CFG_34XX(H26_3630_DSS_DATA18, 0x100,
+ OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLDOWN)
+MUX_CFG_34XX(H25_3630_DSS_DATA19, 0x102,
+ OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLDOWN)
+MUX_CFG_34XX(E28_3630_DSS_DATA20, 0x104,
+ OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLDOWN)
+MUX_CFG_34XX(J26_3630_DSS_DATA21, 0x106,
+ OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLDOWN)
+MUX_CFG_34XX(AC27_3630_DSS_DATA22, 0x108,
+ OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLDOWN)
+MUX_CFG_34XX(AC28_3630_DSS_DATA23, 0x10A,
+ OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLDOWN)
+
+MUX_CFG_34XX(AF9_3630_ETKD8, 0x5EC,
+ OMAP34XX_MUX_MODE1 | OMAP34XX_PIN_INPUT_PULLDOWN)
+MUX_CFG_34XX(AG9_3630_ETKD9, 0x5EE,
+ OMAP34XX_MUX_MODE1 | OMAP34XX_PIN_INPUT_PULLDOWN)
+MUX_CFG_34XX(AG7_3630_ETKD12, 0x5F0,
+ OMAP34XX_MUX_MODE1 | OMAP34XX_PIN_INPUT_PULLDOWN)
+
+MUX_CFG_34XX(AA25_3630_UART2_TX, 0x178,
+ OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULLDOWN)
+MUX_CFG_34XX(AD25_3630_UART2_RX, 0x17A,
+ OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULLDOWN)
+MUX_CFG_34XX(AB25_3630_UART2_RTS, 0x176,
+ OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULLDOWN)
+MUX_CFG_34XX(AB26_3630_UART2_CTS, 0x174,
+ OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULLDOWN)
+
+MUX_CFG_34XX(H20_UART3_RX_IRRX, 0x19E,
+ OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLDOWN)
+MUX_CFG_34XX(H21_UART3_TX_IRTX, 0x1A0,
+ OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLDOWN)
+
};
#define OMAP34XX_PINS_SZ ARRAY_SIZE(omap34xx_pins)
diff --git a/arch/arm/plat-omap/include/mach/mux.h
b/arch/arm/plat-omap/include/mach/mux.h
index 0f49d2d..8d8cbe1 100644
--- a/arch/arm/plat-omap/include/mach/mux.h
+++ b/arch/arm/plat-omap/include/mach/mux.h
@@ -890,6 +890,32 @@ enum omap34xx_index {
/* SYS_NIRQ T2 INT1 */
AF26_34XX_SYS_NIRQ,
+
+ /*Muxes for 3630*/
+ K28_3630_CAM_D6,
+ L28_3630_CAM_D7,
+ K27_3630_CAM_D8,
+ L27_3630_CAM_D9,
+
+ H26_3630_DSS_DATA18,
+ H25_3630_DSS_DATA19,
+ E28_3630_DSS_DATA20,
+ J26_3630_DSS_DATA21,
+ AC27_3630_DSS_DATA22,
+ AC28_3630_DSS_DATA23,
+
+ AF9_3630_ETKD8,
+ AG9_3630_ETKD9,
+ AG7_3630_ETK12,
+
+ AA25_3630_UART2_TX,
+ AD25_3630_UART2_RX,
+ AB25_3630_UART2_RTS,
+ AB26_3630_UART2_CTS,
+
+ H20_UART3_RX_IRRX,
+ H21_UART3_TX_IRTX,
+
};
struct omap_mux_cfg {--
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: Memory performance / Cache problem
On Wednesday 14 October 2009 17:48:39 ext e...@gmx.de wrote: Mem clock is both times 166MHz. I don't know whether are differences in cycle access and timing, but memclock is fine. Following Siarhei hints of initialize the buffers (around 1.2 MByte each) I get different results in 22kernel for use of malloc alone memcpy = 473.764, loop4 = 448.430, loop1 = 102.770, rand = 29.641 calloc alone memcpy = 405.947, loop4 = 361.550, loop1 =95.441, rand = 21.853 malloc+memset: memcpy = 239.294, loop4 = 188.617, loop1 =80.871, rand = 4.726 In 31kernel all 3 measures are about the same (unfortunatly low) level of malloc+memset in 22. First of all: What performance can be expected? Does 22 make failures if it is so much faster? Can the later kernels get a boost in memory handling? What you see is just a (fake) performance boost because you have a single physical page shared between all the virtual pages in the source buffer. So you get no cache misses on read operations and everything seems fast. This is unlikely to happen on real use, and it does not reflect real memory performance. So the benchmark is inadequate. You can get some basic information here: http://en.wikipedia.org/wiki/Copy-on-write Regarding the difference in behavior between .22 and recent kernels. It may be some regression in copy-on-write implementation, or just some change done on purpose. That is assuming that the userspace stuff was identical in both tests. Ok, understand the difference if the memory is uninitialised. But why there is the difference in malloc + memset and calloc? In both cases the memory will be cleared. -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser -- 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: SMP: BUG with PREEMPT enabled
On Wed, Oct 14, 2009 at 04:56:18PM +0530, Shilimkar, Santosh wrote:
On the latest ARM kernel(v2.6.32-rc4),I have observed a BUG() dump when
Umm...
@@ -350,7 +350,7 @@ static inline void local_flush_tlb_mm(struct mm_struct
*mm)
if (tlb_flag(TLB_WB))
dsb();
- if (cpu_isset(smp_processor_id(), mm-cpu_vm_mask)) {
+ if (cpu_isset(get_cpu(), mm-cpu_vm_mask)) {
This isn't 2.6.32-rc4 code - which actually is:
if (cpumask_test_cpu(smp_processor_id(), mm_cpumask(mm))) {
so what kernel version are you working with?
The result is this patch won't apply to 2.6.32-rc4.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC][Patch V1] OMAP3: Mux Changes.
Please send your patch using git send email. And generate your patch using git
format patch
-Original Message-
From: Pais, Allen
Sent: Thursday, October 15, 2009 4:38 AM
Please ignore my previous mail.
Muxes for OMAP 3630.
Signed-off-by: Allen Pais allen.p...@ti.com diff --git a/arch/arm/mach-
omap2/mux.c b/arch/arm/mach-omap2/mux.c index b5fac32..93abb74 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -551,6 +551,42 @@ MUX_CFG_34XX(AF13_3430_MMC3_DAT3, 0x5e2,
MUX_CFG_34XX(AF26_34XX_SYS_NIRQ, 0x1E0,
OMAP3_WAKEUP_EN | OMAP34XX_PIN_INPUT_PULLUP |
OMAP34XX_MUX_MODE0)
+
+/*Muxes for 3630 */
+MUX_CFG_34XX(H26_3630_DSS_DATA18, 0x100,
+ OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLDOWN)
+MUX_CFG_34XX(H25_3630_DSS_DATA19, 0x102,
+ OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLDOWN)
+MUX_CFG_34XX(E28_3630_DSS_DATA20, 0x104,
+ OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLDOWN)
+MUX_CFG_34XX(J26_3630_DSS_DATA21, 0x106,
+ OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLDOWN)
+MUX_CFG_34XX(AC27_3630_DSS_DATA22, 0x108,
+ OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLDOWN)
+MUX_CFG_34XX(AC28_3630_DSS_DATA23, 0x10A,
+ OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLDOWN)
Why cant I do this in Board file?
+
+MUX_CFG_34XX(AF9_3630_ETKD8, 0x5EC,
+ OMAP34XX_MUX_MODE1 | OMAP34XX_PIN_INPUT_PULLDOWN)
+MUX_CFG_34XX(AG9_3630_ETKD9, 0x5EE,
+ OMAP34XX_MUX_MODE1 | OMAP34XX_PIN_INPUT_PULLDOWN)
+MUX_CFG_34XX(AG7_3630_ETKD12, 0x5F0,
+ OMAP34XX_MUX_MODE1 | OMAP34XX_PIN_INPUT_PULLDOWN)
Why am I doing this?
+
+MUX_CFG_34XX(AA25_3630_UART2_TX, 0x178,
+ OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULLDOWN)
+MUX_CFG_34XX(AD25_3630_UART2_RX, 0x17A,
+ OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULLDOWN)
+MUX_CFG_34XX(AB25_3630_UART2_RTS, 0x176,
+ OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULLDOWN)
+MUX_CFG_34XX(AB26_3630_UART2_CTS, 0x174,
+ OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULLDOWN)
Please explain..
+
+MUX_CFG_34XX(H20_UART3_RX_IRRX, 0x19E,
+ OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLDOWN)
+MUX_CFG_34XX(H21_UART3_TX_IRTX, 0x1A0,
+ OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLDOWN)
+
};
??
#define OMAP34XX_PINS_SZ ARRAY_SIZE(omap34xx_pins)
diff --git a/arch/arm/plat-omap/include/mach/mux.h b/arch/arm/plat-
omap/include/mach/mux.h
index 0f49d2d..8d8cbe1 100644
--- a/arch/arm/plat-omap/include/mach/mux.h
+++ b/arch/arm/plat-omap/include/mach/mux.h
@@ -890,6 +890,32 @@ enum omap34xx_index {
/* SYS_NIRQ T2 INT1 */
AF26_34XX_SYS_NIRQ,
+
+ /*Muxes for 3630*/
+ K28_3630_CAM_D6,
+ L28_3630_CAM_D7,
+ K27_3630_CAM_D8,
+ L27_3630_CAM_D9,
+
+ H26_3630_DSS_DATA18,
+ H25_3630_DSS_DATA19,
+ E28_3630_DSS_DATA20,
+ J26_3630_DSS_DATA21,
+ AC27_3630_DSS_DATA22,
+ AC28_3630_DSS_DATA23,
+
+ AF9_3630_ETKD8,
+ AG9_3630_ETKD9,
+ AG7_3630_ETK12,
+
+ AA25_3630_UART2_TX,
+ AD25_3630_UART2_RX,
+ AB25_3630_UART2_RTS,
+ AB26_3630_UART2_CTS,
+
+ H20_UART3_RX_IRRX,
+ H21_UART3_TX_IRTX,
+
};
struct omap_mux_cfg {
--
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: SMP: BUG with PREEMPT enabled
The patch submitted to patch-system I based it on 2.6.32-rc4
Have you tried that patch ?
The one attached was in email was based on 2.6.31
Regards,
Santosh
-Original Message-
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
Sent: Thursday, October 15, 2009 5:11 PM
To: Shilimkar, Santosh
Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Subject: Re: SMP: BUG with PREEMPT enabled
On Wed, Oct 14, 2009 at 04:56:18PM +0530, Shilimkar, Santosh wrote:
On the latest ARM kernel(v2.6.32-rc4),I have observed a BUG() dump
when
Umm...
@@ -350,7 +350,7 @@ static inline void local_flush_tlb_mm(struct
mm_struct *mm)
if (tlb_flag(TLB_WB))
dsb();
- if (cpu_isset(smp_processor_id(), mm-cpu_vm_mask)) {
+ if (cpu_isset(get_cpu(), mm-cpu_vm_mask)) {
This isn't 2.6.32-rc4 code - which actually is:
if (cpumask_test_cpu(smp_processor_id(), mm_cpumask(mm))) {
so what kernel version are you working with?
The result is this patch won't apply to 2.6.32-rc4.
--
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: SMP: BUG with PREEMPT enabled
-Original Message- From: linux-arm-kernel-boun...@lists.infradead.org [mailto:linux-arm- kernel-boun...@lists.infradead.org] On Behalf Of Shilimkar, Santosh Sent: Thursday, October 15, 2009 6:55 PM To: Russell King - ARM Linux Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: RE: SMP: BUG with PREEMPT enabled The patch submitted to patch-system I based it on 2.6.32-rc4 Have you tried that patch ? The one attached was in email was based on 2.6.31 I have submitted the correct version to patch system again. Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/2] OMAP3: PM: Make PRM setup times and CPUidle latencies/threshold board specific
Hi, 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. The CPUidle latencies and hence thresholds (derived from latencies and Power consumption numbers) and very much dependent on these setup values and hence also need to be board specific. This patchset makes it possible for the PRM setup times and the CPUidle latencies/threshold numbers to be configured from board files, and some default values are used if nothing gets passed from board files. Only the 3430SDP board file is currently been modifed to pass these values. regards, Rajendra-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] OMAP3: PM: Configure CPUidle latencies/thresholds from board file
The CPUidle C state latencies and thresholds are dependent
on various board specific details.
This patch makes it possible to configure these values from the
respective board files.
omap3_pm_init_cpuidle() can now be optionally called from board
files to pass board specific cpuidle parameters.
If the board files do not use this function to pass the params
default values are used which might cause higher consumption
dur to wrong state selection by the governor.
This patch only updates the 3430sdp board files to use
omap3_pm_init_cpuidle().
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c | 19 +++
arch/arm/mach-omap2/cpuidle34xx.c | 42 +++
arch/arm/mach-omap2/pm.h|8 ++
3 files changed, 69 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 0f1975c..d2b2f8f 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -73,6 +73,24 @@ static struct prm_setup_vc omap3_setuptime_table = {
.vdd1_off = 0x00,
};
+/* FIXME: These values need to be updated based on more profiling on 3430sdp*/
+static struct cpuidle_params omap3_cpuidle_params_table[] = {
+ /* C1 */
+ {2, 2, 5},
+ /* C2 */
+ {10, 10, 30},
+ /* C3 */
+ {50, 50, 300},
+ /* C4 */
+ {1500, 1800, 4000},
+ /* C5 */
+ {2500, 7500, 12000},
+ /* C6 */
+ {3000, 8500, 15000},
+ /* C7 */
+ {1, 3, 30},
+};
+
static int board_keymap[] = {
KEY(0, 0, KEY_LEFT),
KEY(0, 1, KEY_RIGHT),
@@ -203,6 +221,7 @@ static void __init omap_3430sdp_init_irq(void)
omap_board_config = sdp3430_config;
omap_board_config_size = ARRAY_SIZE(sdp3430_config);
omap3_pm_init_vc(omap3_setuptime_table);
+ omap3_pm_init_cpuidle(omap3_cpuidle_params_table);
omap2_init_common_hw(hyb18m512160af6_sdrc_params, NULL,
omap3_mpu_rate_table,
omap3_dsp_rate_table, omap3_l3_rate_table);
omap_init_irq();
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index c44a942..f5d8f55 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -60,6 +60,30 @@ struct omap3_processor_cx
omap3_power_states[OMAP3_MAX_STATES];
struct omap3_processor_cx current_cx_state;
struct powerdomain *mpu_pd, *core_pd, *per_pd;
+/*
+ * The latencies/thresholds for various C states have
+ * to be configured from the respective board files.
+ * These are some default values (which might not provide
+ * the best power savings) used on boards which do not
+ * pass these details from the board file.
+ */
+static struct cpuidle_params cpuidle_params_table[] = {
+ /* C1 */
+ {2, 2, 5},
+ /* C2 */
+ {10, 10, 30},
+ /* C3 */
+ {50, 50, 300},
+ /* C4 */
+ {1500, 1800, 4000},
+ /* C5 */
+ {2500, 7500, 12000},
+ /* C6 */
+ {3000, 8500, 15000},
+ /* C7 */
+ {1, 3, 30},
+};
+
static int omap3_idle_bm_check(void)
{
if (!omap3_can_sleep())
@@ -165,6 +189,24 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
DEFINE_PER_CPU(struct cpuidle_device, omap3_idle_dev);
+void omap3_pm_init_cpuidle(struct cpuidle_params *cpuidle_board_params)
+{
+ int i;
+
+ if (!cpuidle_board_params)
+ return;
+
+ for (i = OMAP3_STATE_C1; i OMAP3_MAX_STATES; i++) {
+ cpuidle_params_table[i].sleep_latency =
+ cpuidle_board_params[i].sleep_latency;
+ cpuidle_params_table[i].wake_latency =
+ cpuidle_board_params[i].wake_latency;
+ cpuidle_params_table[i].threshold =
+ cpuidle_board_params[i].threshold;
+ }
+ return;
+}
+
/* omap3_init_power_states - Initialises the OMAP3 specific C states.
*
* Below is the desciption of each C state.
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index ca673c5..0b814ab 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -41,7 +41,15 @@ struct prm_setup_vc {
u16 vdd1_ret;
u16 vdd1_off;
};
+
+struct cpuidle_params {
+ u32 sleep_latency;
+ u32 wake_latency;
+ u32 threshold;
+};
+
extern void omap3_pm_init_vc(struct prm_setup_vc *setup_vc);
+extern void omap3_pm_init_cpuidle(struct cpuidle_params *cpuidle_board_params);
extern int resource_set_opp_level(int res, u32 target_level, int flags);
extern int resource_access_opp_lock(int res, int delta);
--
1.5.4.7
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] OMAP3: PM: Configure PRM setup times from board files
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.
omap3_pm_init_vc() can now be optionally called from board files
to initialise the setup times. If board files do not use
this function to pass the setup times, default/conservative
values are used which are safe but would cause higher wakeup
latencies from sleep states.
This patch only updates the 3430sdp board file to use
omap3_pm_init_vc() to update the setup times.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c | 18 ++
arch/arm/mach-omap2/pm.h|2 +-
arch/arm/mach-omap2/pm34xx.c|5 -
3 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 14868b5..0f1975c 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -56,6 +56,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 board_keymap[] = {
KEY(0, 0, KEY_LEFT),
KEY(0, 1, KEY_RIGHT),
@@ -185,6 +202,7 @@ static void __init omap_3430sdp_init_irq(void)
{
omap_board_config = sdp3430_config;
omap_board_config_size = ARRAY_SIZE(sdp3430_config);
+ omap3_pm_init_vc(omap3_setuptime_table);
omap2_init_common_hw(hyb18m512160af6_sdrc_params, NULL,
omap3_mpu_rate_table,
omap3_dsp_rate_table, omap3_l3_rate_table);
omap_init_irq();
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index f8d11a2..ca673c5 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -41,7 +41,7 @@ struct prm_setup_vc {
u16 vdd1_ret;
u16 vdd1_off;
};
-extern void omap3_set_prm_setup_vc(struct prm_setup_vc *setup_vc);
+extern void omap3_pm_init_vc(struct prm_setup_vc *setup_vc);
extern int resource_set_opp_level(int res, u32 target_level, int flags);
extern int resource_access_opp_lock(int res, int delta);
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 01260ec..3d7ae2f 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -1027,8 +1027,11 @@ int omap3_pm_set_suspend_state(struct powerdomain
*pwrdm, int state)
return -EINVAL;
}
-void omap3_set_prm_setup_vc(struct prm_setup_vc *setup_vc)
+void omap3_pm_init_vc(struct prm_setup_vc *setup_vc)
{
+ if (!setup_vc)
+ return;
+
prm_setup.clksetup = setup_vc-clksetup;
prm_setup.voltsetup_time1 = setup_vc-voltsetup_time1;
prm_setup.voltsetup_time2 = setup_vc-voltsetup_time2;
--
1.5.4.7
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP3: PM: Removing redundant and potentially dangerous PRCM configration
As part of Core domain context restoration while coming out of off mode there are some registers being restored which are not required to be restored. ROM code should have restored them already. Overwriting some of them can have potential side effect. Eg: CM_CLKEN_PLL register should not be written while dpll is locked. Signed-off-by: Vishwanath BS vishwanath...@ti.com --- diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c index fb864cc..da16804 100644 --- a/arch/arm/mach-omap2/prcm.c +++ b/arch/arm/mach-omap2/prcm.c @@ -279,7 +279,6 @@ void omap3_prcm_save_context(void) prcm_context.cm_sysconfig = __raw_readl(OMAP3430_CM_SYSCONFIG); prcm_context.sgx_cm_clksel = cm_read_mod_reg(OMAP3430ES2_SGX_MOD, CM_CLKSEL); - prcm_context.wkup_cm_clksel = cm_read_mod_reg(WKUP_MOD, CM_CLKSEL); prcm_context.dss_cm_clksel = cm_read_mod_reg(OMAP3430_DSS_MOD, CM_CLKSEL); prcm_context.cam_cm_clksel = @@ -296,8 +295,6 @@ void omap3_prcm_save_context(void) cm_read_mod_reg(PLL_MOD, OMAP3430ES2_CM_CLKSEL4); prcm_context.pll_cm_clksel5 = cm_read_mod_reg(PLL_MOD, OMAP3430ES2_CM_CLKSEL5); - prcm_context.pll_cm_clken = - cm_read_mod_reg(PLL_MOD, CM_CLKEN); prcm_context.pll_cm_clken2 = cm_read_mod_reg(PLL_MOD, OMAP3430ES2_CM_CLKEN2); prcm_context.cm_polctrl = __raw_readl(OMAP3430_CM_POLCTRL); @@ -343,8 +340,6 @@ void omap3_prcm_save_context(void) cm_read_mod_reg(OMAP3430_IVA2_MOD, CM_AUTOIDLE2); prcm_context.mpu_cm_autoidle2 = cm_read_mod_reg(MPU_MOD, CM_AUTOIDLE2); - prcm_context.pll_cm_autoidle = -cm_read_mod_reg(PLL_MOD, CM_AUTOIDLE); prcm_context.iva2_cm_clkstctrl = cm_read_mod_reg(OMAP3430_IVA2_MOD, CM_CLKSTCTRL); prcm_context.mpu_cm_clkstctrl = @@ -436,7 +431,6 @@ void omap3_prcm_restore_context(void) __raw_writel(prcm_context.cm_sysconfig, OMAP3430_CM_SYSCONFIG); cm_write_mod_reg(prcm_context.sgx_cm_clksel, OMAP3430ES2_SGX_MOD, CM_CLKSEL); - cm_write_mod_reg(prcm_context.wkup_cm_clksel, WKUP_MOD, CM_CLKSEL); cm_write_mod_reg(prcm_context.dss_cm_clksel, OMAP3430_DSS_MOD, CM_CLKSEL); cm_write_mod_reg(prcm_context.cam_cm_clksel, OMAP3430_CAM_MOD, @@ -453,7 +447,6 @@ void omap3_prcm_restore_context(void) OMAP3430ES2_CM_CLKSEL4); cm_write_mod_reg(prcm_context.pll_cm_clksel5, PLL_MOD, OMAP3430ES2_CM_CLKSEL5); - cm_write_mod_reg(prcm_context.pll_cm_clken, PLL_MOD, CM_CLKEN); cm_write_mod_reg(prcm_context.pll_cm_clken2, PLL_MOD, OMAP3430ES2_CM_CLKEN2); __raw_writel(prcm_context.cm_polctrl, OMAP3430_CM_POLCTRL); @@ -492,7 +485,6 @@ void omap3_prcm_restore_context(void) cm_write_mod_reg(prcm_context.iva2_cm_autiidle2, OMAP3430_IVA2_MOD, CM_AUTOIDLE2); cm_write_mod_reg(prcm_context.mpu_cm_autoidle2, MPU_MOD, CM_AUTOIDLE2); - cm_write_mod_reg(prcm_context.pll_cm_autoidle, PLL_MOD, CM_AUTOIDLE); cm_write_mod_reg(prcm_context.iva2_cm_clkstctrl, OMAP3430_IVA2_MOD, CM_CLKSTCTRL); cm_write_mod_reg(prcm_context.mpu_cm_clkstctrl, MPU_MOD, CM_CLKSTCTRL); -- 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] ARM: OMAP: SDMA: Fix omap_stop_dma() API for channel linking
* Shilimkar, Santosh santosh.shilim...@ti.com [091014 21:40]: -Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Wednesday, October 14, 2009 10:36 PM To: Shilimkar, Santosh Cc: linux-omap@vger.kernel.org; S, Venkatraman; Hari n; Jarkko Nikula Subject: Re: [PATCH] ARM: OMAP: SDMA: Fix omap_stop_dma() API for channel linking * Santosh Shilimkar santosh.shilim...@ti.com [091013 23:14]: OMAP sDMA driver API omap_stop_dma() doesn't really stop the dma when used in linking scenario. This patch fixes the same. To me it looks like this will break things for omap1 as the DMA channel interrupt is not disabled first. I guess the fix is to move the Disable all interrupts on the channel part above clearing the link mappings. Indeed it will break OMAP1. Initially I thought of putting this change at this place so that it takes care of both normal and linking scenario. I will rework this and send v2. OK, thanks. This fix should be tested in linux-omap before we send this to mainline. Yes ofcourse. That what I meant by merge. Yeah, we should still have enough time to get it into mainline kernel as a fix during this -rc cycle. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
MMC_CAP_SDIO_IRQ for omap 3430
I have seen several discussions about lack of sdio irq support in the hsmmc driver but no patches. Has anyone on this list implemented this and/or can anyone point me to patches? Thanks John -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP3: PM: Removing redundant and potentially dangerous PRCM configration
As part of Core domain context restoration while coming out of off mode there are some registers being restored which are not required to be restored. ROM code should have restored them already. Overwriting some of them can have potential side effect. Eg: CM_CLKEN_PLL register should not be written while dpll is locked. Signed-off-by: Vishwanath BS vishwanath...@ti.com --- diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c index fb864cc..da16804 100644 --- a/arch/arm/mach-omap2/prcm.c +++ b/arch/arm/mach-omap2/prcm.c @@ -279,7 +279,6 @@ void omap3_prcm_save_context(void) prcm_context.cm_sysconfig = __raw_readl(OMAP3430_CM_SYSCONFIG); prcm_context.sgx_cm_clksel = cm_read_mod_reg(OMAP3430ES2_SGX_MOD, CM_CLKSEL); - prcm_context.wkup_cm_clksel = cm_read_mod_reg(WKUP_MOD, CM_CLKSEL); prcm_context.dss_cm_clksel = cm_read_mod_reg(OMAP3430_DSS_MOD, CM_CLKSEL); prcm_context.cam_cm_clksel = @@ -296,8 +295,6 @@ void omap3_prcm_save_context(void) cm_read_mod_reg(PLL_MOD, OMAP3430ES2_CM_CLKSEL4); prcm_context.pll_cm_clksel5 = cm_read_mod_reg(PLL_MOD, OMAP3430ES2_CM_CLKSEL5); - prcm_context.pll_cm_clken = - cm_read_mod_reg(PLL_MOD, CM_CLKEN); prcm_context.pll_cm_clken2 = cm_read_mod_reg(PLL_MOD, OMAP3430ES2_CM_CLKEN2); prcm_context.cm_polctrl = __raw_readl(OMAP3430_CM_POLCTRL); @@ -343,8 +340,6 @@ void omap3_prcm_save_context(void) cm_read_mod_reg(OMAP3430_IVA2_MOD, CM_AUTOIDLE2); prcm_context.mpu_cm_autoidle2 = cm_read_mod_reg(MPU_MOD, CM_AUTOIDLE2); - prcm_context.pll_cm_autoidle = -cm_read_mod_reg(PLL_MOD, CM_AUTOIDLE); prcm_context.iva2_cm_clkstctrl = cm_read_mod_reg(OMAP3430_IVA2_MOD, CM_CLKSTCTRL); prcm_context.mpu_cm_clkstctrl = @@ -436,7 +431,6 @@ void omap3_prcm_restore_context(void) __raw_writel(prcm_context.cm_sysconfig, OMAP3430_CM_SYSCONFIG); cm_write_mod_reg(prcm_context.sgx_cm_clksel, OMAP3430ES2_SGX_MOD, CM_CLKSEL); - cm_write_mod_reg(prcm_context.wkup_cm_clksel, WKUP_MOD, CM_CLKSEL); cm_write_mod_reg(prcm_context.dss_cm_clksel, OMAP3430_DSS_MOD, CM_CLKSEL); cm_write_mod_reg(prcm_context.cam_cm_clksel, OMAP3430_CAM_MOD, @@ -453,7 +447,6 @@ void omap3_prcm_restore_context(void) OMAP3430ES2_CM_CLKSEL4); cm_write_mod_reg(prcm_context.pll_cm_clksel5, PLL_MOD, OMAP3430ES2_CM_CLKSEL5); - cm_write_mod_reg(prcm_context.pll_cm_clken, PLL_MOD, CM_CLKEN); cm_write_mod_reg(prcm_context.pll_cm_clken2, PLL_MOD, OMAP3430ES2_CM_CLKEN2); __raw_writel(prcm_context.cm_polctrl, OMAP3430_CM_POLCTRL); @@ -492,7 +485,6 @@ void omap3_prcm_restore_context(void) cm_write_mod_reg(prcm_context.iva2_cm_autiidle2, OMAP3430_IVA2_MOD, CM_AUTOIDLE2); cm_write_mod_reg(prcm_context.mpu_cm_autoidle2, MPU_MOD, CM_AUTOIDLE2); - cm_write_mod_reg(prcm_context.pll_cm_autoidle, PLL_MOD, CM_AUTOIDLE); cm_write_mod_reg(prcm_context.iva2_cm_clkstctrl, OMAP3430_IVA2_MOD, CM_CLKSTCTRL); cm_write_mod_reg(prcm_context.mpu_cm_clkstctrl, MPU_MOD, CM_CLKSTCTRL); -- 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
24xx/n8x0 booting again, linux-omap updated to -rc5
Hi all, Thanks to Paul's OMAP2xxx clock: set up clockdomain pointer in struct clk patch, we got 24xx booting again both in mainline and in linux-omap. The following patch is also needed to change the n8x0 serial console CMDLINE from ttyS0 to ttyS2 as the port numbering now matches the physical ports. The patch is already in linux-omap, but not yet in mainline. Also, I've rebuilt linux-omap again on top of -rc5. Will merge in the plat header patches tomorrow. Cheers, Tony From 71d3bff80f77cdd286303f19308058c6c844458f Mon Sep 17 00:00:00 2001 From: Tony Lindgren t...@atomide.com Date: Thu, 15 Oct 2009 18:13:28 -0700 Subject: [PATCH] omap: Fix console serial port number for n8x0 With the recent changes omap serial ports match the physical numbering like they should. Fix the kernel CMDLINE accordingly so console works. Signed-off-by: Tony Lindgren t...@atomide.com diff --git a/arch/arm/configs/n8x0_defconfig b/arch/arm/configs/n8x0_defconfig index 8da75de..264f52b 100644 --- a/arch/arm/configs/n8x0_defconfig +++ b/arch/arm/configs/n8x0_defconfig @@ -304,7 +304,7 @@ CONFIG_ALIGNMENT_TRAP=y CONFIG_ZBOOT_ROM_TEXT=0x10C08000 CONFIG_ZBOOT_ROM_BSS=0x1020 # CONFIG_ZBOOT_ROM is not set -CONFIG_CMDLINE=root=1f03 rootfstype=jffs2 console=ttyS0,115200n8 +CONFIG_CMDLINE=root=1f03 rootfstype=jffs2 console=ttyS2,115200n8 # CONFIG_XIP_KERNEL is not set # CONFIG_KEXEC is not set
RE: [RFC][Patch V1] OMAP3: Mux Changes.
Hi Allen,
a) A simple comment to all my comments: why cant we have these in bootloader
and just simply leave the mux file alone?
[Allen] Yes Nishanth, this would be a much cleaner approach. Even Santosh had
suggested
The same, if we can conclude on a approach here, I can go ahead and do the Mux
Change it accordingly.
b) Are you doing this for a specific platform or are they generic 3630 pin mux
changes?
[Allen] No, not as of now.
- Allen
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Menon, Nishanth
Sent: Thursday, October 15, 2009 7:24 AM
To: Pais, Allen; Aguirre Rodriguez, Sergio Alberto; linux-omap
Cc: Chikkature Rajashekar, Madhusudhan; Pandita, Vikram; Gadiyar,
Anand; Cousson, Benoit; Felipe Balbi; Kevin Hilman; Premi, Sanjeev;
Shilimkar, Santosh; Tony Lindgren
Subject: RE: [RFC][Patch V1] OMAP3: Mux Changes.
Please send your patch using git send email. And generate your patch
using git format patch
-Original Message-
From: Pais, Allen
Sent: Thursday, October 15, 2009 4:38 AM
Please ignore my previous mail.
Muxes for OMAP 3630.
Signed-off-by: Allen Pais allen.p...@ti.com diff --git
a/arch/arm/mach-
omap2/mux.c b/arch/arm/mach-omap2/mux.c index b5fac32..93abb74
100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -551,6 +551,42 @@ MUX_CFG_34XX(AF13_3430_MMC3_DAT3, 0x5e2,
MUX_CFG_34XX(AF26_34XX_SYS_NIRQ, 0x1E0,
OMAP3_WAKEUP_EN | OMAP34XX_PIN_INPUT_PULLUP |
OMAP34XX_MUX_MODE0)
+
+/*Muxes for 3630 */
+MUX_CFG_34XX(H26_3630_DSS_DATA18, 0x100,
+ OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLDOWN)
+MUX_CFG_34XX(H25_3630_DSS_DATA19, 0x102,
+ OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLDOWN)
+MUX_CFG_34XX(E28_3630_DSS_DATA20, 0x104,
+ OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLDOWN)
+MUX_CFG_34XX(J26_3630_DSS_DATA21, 0x106,
+ OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLDOWN)
+MUX_CFG_34XX(AC27_3630_DSS_DATA22, 0x108,
+ OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLDOWN)
+MUX_CFG_34XX(AC28_3630_DSS_DATA23, 0x10A,
+ OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLDOWN)
Why cant I do this in Board file?
I Really typed that??? Dumb me.. apologies on the noise.. I had meant
bootloader..
+
+MUX_CFG_34XX(AF9_3630_ETKD8, 0x5EC,
+ OMAP34XX_MUX_MODE1 | OMAP34XX_PIN_INPUT_PULLDOWN)
+MUX_CFG_34XX(AG9_3630_ETKD9, 0x5EE,
+ OMAP34XX_MUX_MODE1 | OMAP34XX_PIN_INPUT_PULLDOWN)
+MUX_CFG_34XX(AG7_3630_ETKD12, 0x5F0,
+ OMAP34XX_MUX_MODE1 | OMAP34XX_PIN_INPUT_PULLDOWN)
Why am I doing this?
+
+MUX_CFG_34XX(AA25_3630_UART2_TX, 0x178,
+ OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULLDOWN)
+MUX_CFG_34XX(AD25_3630_UART2_RX, 0x17A,
+ OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULLDOWN)
+MUX_CFG_34XX(AB25_3630_UART2_RTS, 0x176,
+ OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULLDOWN)
+MUX_CFG_34XX(AB26_3630_UART2_CTS, 0x174,
+ OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULLDOWN)
Please explain..
+
+MUX_CFG_34XX(H20_UART3_RX_IRRX, 0x19E,
+ OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLDOWN)
+MUX_CFG_34XX(H21_UART3_TX_IRTX, 0x1A0,
+ OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLDOWN)
+
};
??
#define OMAP34XX_PINS_SZ ARRAY_SIZE(omap34xx_pins)
diff --git a/arch/arm/plat-omap/include/mach/mux.h b/arch/arm/plat-
omap/include/mach/mux.h index 0f49d2d..8d8cbe1 100644
--- a/arch/arm/plat-omap/include/mach/mux.h
+++ b/arch/arm/plat-omap/include/mach/mux.h
@@ -890,6 +890,32 @@ enum omap34xx_index {
/* SYS_NIRQ T2 INT1 */
AF26_34XX_SYS_NIRQ,
+
+ /*Muxes for 3630*/
+ K28_3630_CAM_D6,
+ L28_3630_CAM_D7,
+ K27_3630_CAM_D8,
+ L27_3630_CAM_D9,
+
+ H26_3630_DSS_DATA18,
+ H25_3630_DSS_DATA19,
+ E28_3630_DSS_DATA20,
+ J26_3630_DSS_DATA21,
+ AC27_3630_DSS_DATA22,
+ AC28_3630_DSS_DATA23,
+
+ AF9_3630_ETKD8,
+ AG9_3630_ETKD9,
+ AG7_3630_ETK12,
+
+ AA25_3630_UART2_TX,
+ AD25_3630_UART2_RX,
+ AB25_3630_UART2_RTS,
+ AB26_3630_UART2_CTS,
+
+ H20_UART3_RX_IRRX,
+ H21_UART3_TX_IRTX,
+
};
struct omap_mux_cfg {
--
To unsubscribe from this list: send the line unsubscribe linux-omap
in the body of a message to majord...@vger.kernel.org More majordomo
info at http://vger.kernel.org/majordomo-info.html
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][Patch V1] OMAP3: Mux Changes.
Pais, Allen had written, on 10/15/2009 11:53 PM, the following: a) A simple comment to all my comments: why cant we have these in bootloader and just simply leave the mux file alone? [Allen] Yes Nishanth, this would be a much cleaner approach. Even Santosh had suggested The same, if we can conclude on a approach here, I can go ahead and do the Mux Change it accordingly. Then lets please fix the bootloader and drop this patch. - Allen -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Menon, Nishanth Sent: Thursday, October 15, 2009 7:24 AM To: Pais, Allen; Aguirre Rodriguez, Sergio Alberto; linux-omap Please try not to Top post. see [1] -- Regards, Nishanth Menon Ref: [1] http://www.arm.linux.org.uk/mailinglists/etiquette.php#e3 -- 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] ARM: OMAP: SDMA: Fix omap_stop_dma() API for channel linking
snip This fix should be tested in linux-omap before we send this to mainline. Yes ofcourse. That what I meant by merge. Yeah, we should still have enough time to get it into mainline kernel as a fix during this -rc cycle. OK. Also please merge other two patches in linux-omap master since omap4 needs those two patches to boot. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
