Re: [PATCHv2 2/2] OMAP3: PM: Consistently report cpuidle C-state's names
Hello Kevin, On Tue, Mar 02, 2010 at 01:11:52AM +0100, ext Kevin Hilman wrote: > Eduardo Valentin writes: > > > From: Eduardo Valentin > > > > This patch changes the naming convention for OMAP3 cpuidle > > C-states. Currently, depending on which Cstates are enabled/disabled, > > there is a inconsistency between C-state name and what power domain > > states it is supposed to reach when that C-state is selected. > > > > For instance, if all cstates are enabled, "C1" means mpu on and > > core on. But if this exact cstate is disabled, then "C1" doesn't mean > > same power domains state configuration anymore. > > > > So, this patch tries changing the cstates naming convention in order > > to proper and consistently report the cstates names. > > > > Signed-off-by: Eduardo Valentin > > I like this, however... > > Have you considered patching powertop as well? Powertop doesn't seem > to take into consideration the 'desc' field and just names C-states > in increasing order. > > So this patch combined with current powertop acutally makes things > even more confusing. :( Right. I didn't think about powertop in the first place, but you are right. It is worth to have similar changes also on it, to properly use the 'desc' and name fields. I will figure out about it as well. > > Kevin > > > --- > > arch/arm/mach-omap2/cpuidle34xx.c |2 +- > > 1 files changed, 1 insertions(+), 1 deletions(-) > > > > diff --git a/arch/arm/mach-omap2/cpuidle34xx.c > > b/arch/arm/mach-omap2/cpuidle34xx.c > > index 50fe9ab..7ab9992 100644 > > --- a/arch/arm/mach-omap2/cpuidle34xx.c > > +++ b/arch/arm/mach-omap2/cpuidle34xx.c > > @@ -367,7 +367,7 @@ int __init omap3_idle_init(void) > > omap3_enter_idle_bm : omap3_enter_idle; > > if (cx->type == OMAP3_STATE_C1) > > dev->safe_state = state; > > - sprintf(state->name, "C%d", count+1); > > + sprintf(state->name, "C%d", cx->type + 1); > > sprintf(state->desc, "MPU=%s NEON=%s CORE=%s", > > pd_states[cx->mpu_state], pd_states[cx->mpu_state], > > pd_states[cx->core_state]); > > -- > > 1.6.5.7.g9ecb2 -- Eduardo Valentin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 1/2] OMAP3: PM: Add cpuidle C-state description information
On Tue, Mar 02, 2010 at 01:09:55AM +0100, ext Kevin Hilman wrote:
> Eduardo Valentin writes:
>
> > From: Eduardo Valentin
> >
> > Add a basic description information for each cpuidle C-state.
> > The info contains only which state the MPU, NEON and CORE
> > power domains should reach when the C-state is selected.
> >
> > Signed-off-by: Eduardo Valentin
>
> I like this series. Some minor comments...
>
> > ---
> > arch/arm/mach-omap2/cpuidle34xx.c |4
> > 1 files changed, 4 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
> > b/arch/arm/mach-omap2/cpuidle34xx.c
> > index 1cfa5a6..50fe9ab 100644
> > --- a/arch/arm/mach-omap2/cpuidle34xx.c
> > +++ b/arch/arm/mach-omap2/cpuidle34xx.c
> > @@ -339,6 +339,7 @@ struct cpuidle_driver omap3_idle_driver = {
> > */
> > int __init omap3_idle_init(void)
> > {
> > + const char *pd_states[4] = {"OFF", "RET", "INA", "ON "};
>
> I'd rather see something like this for this array, just in case
> those values change for any reason.
>
> static const char *pd_states[] = {
> [PWRDM_POWER_OFF] = "OFF",
> [PWRDM_POWER_RET] = "RET",
> [PWRDM_POWER_INACTIVE] = "INA",
> [PWRDM_POWER_ON] = "ON",
Nice! I'll resend with your proposal.
> };
>
> > int i, count = 0;
> > struct omap3_processor_cx *cx;
> > struct cpuidle_state *state;
> > @@ -367,6 +368,9 @@ int __init omap3_idle_init(void)
> > if (cx->type == OMAP3_STATE_C1)
> > dev->safe_state = state;
> > sprintf(state->name, "C%d", count+1);
> > + sprintf(state->desc, "MPU=%s NEON=%s CORE=%s",
> > + pd_states[cx->mpu_state], pd_states[cx->mpu_state],
> > + pd_states[cx->core_state]);
> > count++;
> > }
> >
> > --
> > 1.6.5.7.g9ecb2
--
Eduardo Valentin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC]OMAP3:PM:Dynamic Calculation of SDRC stall latency during DVFS
"ext Reddy, Teerth" writes: > Hi Jouni, > >> -Original Message- >> From: Högander Jouni [mailto:jouni.hogan...@nokia.com] >> Sent: Monday, February 15, 2010 2:27 PM >> To: Reddy, Teerth >> Cc: linux-omap@vger.kernel.org; Sripathy, Vishwanath; Paul Walmsley; Kevin >> Hilman >> Subject: Re: [PATCH RFC]OMAP3:PM:Dynamic Calculation of SDRC stall latency >> during DVFS >> >> "ext Reddy, Teerth" writes: >> >> > From: Teerth Reddy >> > >> > Dynamic Calculation of SDRC stall latency during DVFS >> > >> > The patch has the changes to calculate the dpll3 clock stabilization >> delay dynamically. The SRAM delay is calibrated during bootup using the >> gptimers and used while calculating the stabilization delay. By using the >> dynamic method the dependency on the type of cache being used is removed. >> Hence there is no need of loop based calculation. >> > >> > The wait time for L3 clock stabilization is calculated using the formula >> : 4*REFCLK + 8*CLKOUTX2, which uses the M, N and M2 read from the >> registers.Since this value gives slightly less value, 2us is added as >> buffer for safety. >> > This works fine for omap3. >> >> I think you could make a difference on 3630 in this patch. 3630 has >> different formula to calculate needed delay after setting m2 divider. > > We have considered the worst case scenario and used this formula > which holds good for 3630 as well. We have used register dump and > observability signal analysis to comeup with this formula. At least the formula used in the patch is quite strictly the one used for 3430. In 3430 used oscillator and m and n selection have huge impact on needed delay (12, 19.2 etc...). In 3630 these doesn't have impact on needed delay anymore. So using own formula for 3630, would give few benefits. No need to take this delay into account in oscillator selection and on m and n selection. > > > Regards > Teerth > -- > 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 -- Jouni Högander -- 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] serial: Add OMAP high-speed UART driver.
* G, Manjunath Kondaiah [100301 22:24]: > > > > > > > > + up->uart_dma.prev_rx_dma_pos = > > up->uart_dma.rx_buf_dma_phys; > > > > > + if (cpu_is_omap44xx()) > > > > > + omap_writel(0, OMAP44XX_DMA4_BASE > > > > > + + > > OMAP_DMA4_CDAC(up->uart_dma.rx_dma_channel)); > > > > > + else > > > > > + omap_writel(0, OMAP34XX_DMA4_BASE > > > > > + + > > OMAP_DMA4_CDAC(up->uart_dma.rx_dma_channel)); > > > > > > > > NAK. Please don't use omap_read/write for for new code. And do not > > > > tinker with the omap hardware registers directly in the driver. > > > > > > > > This needs to be done properly in > > arch/arm/plat-omap/dma.c instead. > > > > > > Thanks for the suggestion. > > > > > > Currently, dma_read/dma_write are #define's in dma.c which > > cannot be > > > accessed outside dma.c. I don't see any API's in dma.c for > > setting required > > > value for this register? > > > > Hmm isn't this the same as omap_get_dma_dst_pos(int lch)? If you're > > trying do something that's not in dma.c, we can add a new function > > for it. > > The omap_get_dma_dst_pos(int lch) is for read operation in CDAC register. > But, We need to write required value into CDAC register. For this, I propose: > > omap_set_dma_dst_pos(int lch, int value) which does not exist in current dma > driver. OK, it that's needed. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] serial: Add OMAP high-speed UART driver.
> > > > + up->uart_dma.prev_rx_dma_pos = > up->uart_dma.rx_buf_dma_phys; > > > > + if (cpu_is_omap44xx()) > > > > + omap_writel(0, OMAP44XX_DMA4_BASE > > > > + + > OMAP_DMA4_CDAC(up->uart_dma.rx_dma_channel)); > > > > + else > > > > + omap_writel(0, OMAP34XX_DMA4_BASE > > > > + + > OMAP_DMA4_CDAC(up->uart_dma.rx_dma_channel)); > > > > > > NAK. Please don't use omap_read/write for for new code. And do not > > > tinker with the omap hardware registers directly in the driver. > > > > > > This needs to be done properly in > arch/arm/plat-omap/dma.c instead. > > > > Thanks for the suggestion. > > > > Currently, dma_read/dma_write are #define's in dma.c which > cannot be > > accessed outside dma.c. I don't see any API's in dma.c for > setting required > > value for this register? > > Hmm isn't this the same as omap_get_dma_dst_pos(int lch)? If you're > trying do something that's not in dma.c, we can add a new function > for it. The omap_get_dma_dst_pos(int lch) is for read operation in CDAC register. But, We need to write required value into CDAC register. For this, I propose: omap_set_dma_dst_pos(int lch, int value) which does not exist in current dma driver. -Manjunath-- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/1] Regulator: Registering USB internal LDOs for TWL4030
> -Original Message- > From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com] > Sent: Monday, January 11, 2010 4:26 PM > To: Aggarwal, Anuj > Cc: linux-omap@vger.kernel.org; l...@slimlogic.co.uk > Subject: Re: [PATCH 1/1] Regulator: Registering USB internal LDOs for > TWL4030 > > On Mon, Jan 11, 2010 at 02:55:18PM +0530, Anuj Aggarwal wrote: > > Adding member variables for USB internal LDOs in twl4030_platform_data > > and registering them in twl-core.c if the variables are populated > > from board-evm file. > > > Signed-off-by: Anuj Aggarwal > > Acked-by: Mark Brown Tony, Can you pull this patch? I have tried it on for-next tip, it applies cleanly. -- 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: linux-next: manual merge of the omap tree with the tree
* Stephen Rothwell [100228 16:17]:
> Hi all,
>
> Today's linux-next merge of the omap tree got a conflict in
> arch/arm/plat-omap/Kconfig between commit
> d6d502fa4be1acd01971476fc732c95a4da16d90 ("ARM: 5952/1: ARM: MM: Add
> ARM_L1_CACHE_SHIFT_6 for handle inside each ARCH Kconfig") from the arm
> tree and commits 56213ca4e440c0b6e56a48f5901c55c4ce3cf1ba ("omap2/3:
> Multiboot compile fixes to compile in omap2 and omap3") and
> a8eb7ca0cbb41c9cd379b8d2a2a5efb503aa65e9 ("omap3: Replace ARCH_OMAP34XX
> with ARCH_OMAP3") from the omap tree.
>
> I fixed it up (see below) and can carry the fix as necessary.
> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
>
> diff --cc arch/arm/plat-omap/Kconfig
> index 2e3eec6,be9484a..000
> --- a/arch/arm/plat-omap/Kconfig
> +++ b/arch/arm/plat-omap/Kconfig
> @@@ -19,10 -28,9 +28,10 @@@ config ARCH_OMAP
>
> config ARCH_OMAP3
> bool "TI OMAP3"
> + depends on ARCH_OMAP2PLUS
> select CPU_V7
> - select COMMON_CLKDEV
> +select ARM_L1_CACHE_SHIFT_6
> + select USB_ARCH_HAS_EHCI
>
> config ARCH_OMAP4
> bool "TI OMAP4"
Thanks, I've merged omap for-next with the mainline to resolve this.
FYI, also need the following not-yet-ready patch to compile omaps.
The weird thing is that unless I set ehci_pdata from __initconst
to __initdata in board-omap3touchbook.c, I get the following early_param
error:
error: __setup_str_early_touchbook_revision causes a section type conflict
The error does not seem to be related to ehci_pdata, and only happens
for board-omap3touchbook.c.
Anybody got ideas?
Regards,
Tony
>From f8b8a130c8cfef6cc885a61dcee339ba71b497a4 Mon Sep 17 00:00:00 2001
From: Tony Lindgren
Date: Mon, 1 Mar 2010 21:54:09 -0800
Subject: [PATCH] omap: Fix compile for early_param and omap_smc1
Commit 2b0d8c251b8876d530a6bf671eb5425838fa698a changed ARM to use
the common early_param code. Fix compile for omaps accordingly.
Commit d309427e792ea750cdd312e7a92cf6047ae44962 added support for
CACHE_L2X0, this however breaks multi-omap builds for V6 because of
dsb and smc. The proper fix is to separate omap_smc1 into a separate
.S file and compile it with -Wa,-march=armv7-a flags.
Also for some reason touchbook produces a compile error
error: __setup_str_early_touchbook_revision causes a section type conflict
Unless ehci_pdata is set to __initdata instead of __initconst.
No idea yet why this happens only on touchbook.
Not-Yet-Signed-off-by: Tony Lindgren
diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
index 180ac11..a462d50 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -49,7 +49,7 @@ static struct omap_board_config_kernel sdp4430_config[] __initdata = {
{ OMAP_TAG_LCD, &sdp4430_lcd_config },
};
-#ifdef CONFIG_CACHE_L2X0
+#if defined(CONFIG_SMP) && defined(CONFIG_CACHE_L2X0)
noinline void omap_smc1(u32 fn, u32 arg)
{
register u32 r12 asm("r12") = fn;
diff --git a/arch/arm/mach-omap2/board-omap3touchbook.c b/arch/arm/mach-omap2/board-omap3touchbook.c
index 3943d0f..07b7a32 100644
--- a/arch/arm/mach-omap2/board-omap3touchbook.c
+++ b/arch/arm/mach-omap2/board-omap3touchbook.c
@@ -493,7 +493,7 @@ static void __init omap3touchbook_flash_init(void)
}
}
-static struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
+static struct ehci_hcd_omap_platform_data ehci_pdata __initdata = {
.port_mode[0] = EHCI_HCD_OMAP_MODE_PHY,
.port_mode[1] = EHCI_HCD_OMAP_MODE_PHY,
@@ -518,14 +518,14 @@ static void omap3_touchbook_poweroff(void)
gpio_direction_output(TB_KILL_POWER_GPIO, 0);
}
-static void __init early_touchbook_revision(char **p)
+static int __init early_touchbook_revision(char *p)
{
- if (!*p)
- return;
+ if (!p)
+ return 0;
- strict_strtoul(*p, 10, &touchbook_revision);
+ return strict_strtoul(p, 10, &touchbook_revision);
}
-__early_param("tbr=", early_touchbook_revision);
+early_param("tbr", early_touchbook_revision);
static struct omap_musb_board_data musb_board_data = {
.interface_type = MUSB_INTERFACE_ULPI,
diff --git a/drivers/video/omap2/vram.c b/drivers/video/omap2/vram.c
index 55a4de5..1d88425 100644
--- a/drivers/video/omap2/vram.c
+++ b/drivers/video/omap2/vram.c
@@ -511,13 +511,17 @@ static u32 omap_vram_sdram_size __initdata;
static u32 omap_vram_def_sdram_size __initdata;
static u32 omap_vram_def_sdram_start __initdata;
-static void __init omap_vram_early_vram(char **p)
+static int __init omap_vram_early_vram(char *p)
{
- omap_vram_def_sdram_size = memparse(*p, p);
- if (**p == ',')
- omap_vram_def_sdram_start = simple_strtoul((*p) + 1, p, 16);
+ char *endp;
+
+ omap_vram_def_sdram_size = memparse(p, &endp);
+ if (*endp == ',')
+ omap_vram_def_sdram_start = simple_strtoul(endp + 1, &p, 16);
+
+ return 0;
}
-__early_param("vram=", omap_vram_early_vram);
+early_param("vram", omap_vram_early_vram);
/*
* Called from map_io. We need to call to this early eno
Re: [PATCH] serial: Add OMAP high-speed UART driver.
* G, Manjunath Kondaiah [100301 21:48]:
> Tony,
>
> > -Original Message-
> > From: linux-omap-ow...@vger.kernel.org
> > [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tony Lindgren
> > Sent: Tuesday, March 02, 2010 12:16 AM
> > To: Raja, Govindraj
> > Cc: Greg KH; linux-ser...@vger.kernel.org;
> > linux-omap@vger.kernel.org; linux-ker...@vger.kernel.org;
> > Kevin Hilman; Olof Johansson
> > Subject: Re: [PATCH] serial: Add OMAP high-speed UART driver.
> >
> > * Govindraj.R [100301 06:40]:
> > > --- /dev/null
> > > +++ b/drivers/serial/omap-serial.c
> > > +
> > > +static void serial_omap_stop_tx(struct uart_port *port)
> > > +{
> > > + struct uart_omap_port *up = (struct uart_omap_port *)port;
> > > +
> > > + if (up->use_dma &&
> > > + up->uart_dma.tx_dma_channel != OMAP_UART_DMA_CH_FREE) {
> > > + /*
> > > + * Check if dma is still active . If yes do nothing,
> >
> > Looks like an extra space here before the period above.
> >
> > ...
> >
> > > +static int serial_omap_start_rxdma(struct uart_omap_port *up)
> > > +{
> > > + int ret = 0;
> > > +
> > > + if (up->uart_dma.rx_dma_channel == -1) {
> > > + ret = omap_request_dma(up->uart_dma.uart_dma_rx,
> > > + "UART Rx DMA",
> > > + (void *)uart_rx_dma_callback, up,
> > > + &(up->uart_dma.rx_dma_channel));
> > > + if (ret < 0)
> > > + return ret;
> > > +
> > > + omap_set_dma_src_params(up->uart_dma.rx_dma_channel, 0,
> > > + OMAP_DMA_AMODE_CONSTANT,
> > > + up->uart_dma.uart_base, 0, 0);
> > > + omap_set_dma_dest_params(up->uart_dma.rx_dma_channel, 0,
> > > + OMAP_DMA_AMODE_POST_INC,
> > > + up->uart_dma.rx_buf_dma_phys, 0, 0);
> > > +
> > omap_set_dma_transfer_params(up->uart_dma.rx_dma_channel,
> > > + OMAP_DMA_DATA_TYPE_S8,
> > > + up->uart_dma.rx_buf_size, 1,
> > > + OMAP_DMA_SYNC_ELEMENT,
> > > + up->uart_dma.uart_dma_rx, 0);
> > > + }
> > > + up->uart_dma.prev_rx_dma_pos = up->uart_dma.rx_buf_dma_phys;
> > > + if (cpu_is_omap44xx())
> > > + omap_writel(0, OMAP44XX_DMA4_BASE
> > > + + OMAP_DMA4_CDAC(up->uart_dma.rx_dma_channel));
> > > + else
> > > + omap_writel(0, OMAP34XX_DMA4_BASE
> > > + + OMAP_DMA4_CDAC(up->uart_dma.rx_dma_channel));
> >
> > NAK. Please don't use omap_read/write for for new code. And do not
> > tinker with the omap hardware registers directly in the driver.
> >
> > This needs to be done properly in arch/arm/plat-omap/dma.c instead.
>
> Thanks for the suggestion.
>
> Currently, dma_read/dma_write are #define's in dma.c which cannot be
> accessed outside dma.c. I don't see any API's in dma.c for setting required
> value for this register?
Hmm isn't this the same as omap_get_dma_dst_pos(int lch)? If you're
trying do something that's not in dma.c, we can add a new function
for it.
> Can we move dma_read/dma_write to header file so that it can be global or
> Is there alternate way to perform this operation with existing dma driver?
No thanks, that again leads all drivers messing with the DMA registers
directly and can easily lead to errors.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] serial: Add OMAP high-speed UART driver.
Tony,
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org
> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tony Lindgren
> Sent: Tuesday, March 02, 2010 12:16 AM
> To: Raja, Govindraj
> Cc: Greg KH; linux-ser...@vger.kernel.org;
> linux-omap@vger.kernel.org; linux-ker...@vger.kernel.org;
> Kevin Hilman; Olof Johansson
> Subject: Re: [PATCH] serial: Add OMAP high-speed UART driver.
>
> * Govindraj.R [100301 06:40]:
> > --- /dev/null
> > +++ b/drivers/serial/omap-serial.c
> > +
> > +static void serial_omap_stop_tx(struct uart_port *port)
> > +{
> > + struct uart_omap_port *up = (struct uart_omap_port *)port;
> > +
> > + if (up->use_dma &&
> > + up->uart_dma.tx_dma_channel != OMAP_UART_DMA_CH_FREE) {
> > + /*
> > +* Check if dma is still active . If yes do nothing,
>
> Looks like an extra space here before the period above.
>
> ...
>
> > +static int serial_omap_start_rxdma(struct uart_omap_port *up)
> > +{
> > + int ret = 0;
> > +
> > + if (up->uart_dma.rx_dma_channel == -1) {
> > + ret = omap_request_dma(up->uart_dma.uart_dma_rx,
> > + "UART Rx DMA",
> > + (void *)uart_rx_dma_callback, up,
> > + &(up->uart_dma.rx_dma_channel));
> > + if (ret < 0)
> > + return ret;
> > +
> > + omap_set_dma_src_params(up->uart_dma.rx_dma_channel, 0,
> > + OMAP_DMA_AMODE_CONSTANT,
> > + up->uart_dma.uart_base, 0, 0);
> > + omap_set_dma_dest_params(up->uart_dma.rx_dma_channel, 0,
> > + OMAP_DMA_AMODE_POST_INC,
> > + up->uart_dma.rx_buf_dma_phys, 0, 0);
> > +
> omap_set_dma_transfer_params(up->uart_dma.rx_dma_channel,
> > + OMAP_DMA_DATA_TYPE_S8,
> > + up->uart_dma.rx_buf_size, 1,
> > + OMAP_DMA_SYNC_ELEMENT,
> > + up->uart_dma.uart_dma_rx, 0);
> > + }
> > + up->uart_dma.prev_rx_dma_pos = up->uart_dma.rx_buf_dma_phys;
> > + if (cpu_is_omap44xx())
> > + omap_writel(0, OMAP44XX_DMA4_BASE
> > + + OMAP_DMA4_CDAC(up->uart_dma.rx_dma_channel));
> > + else
> > + omap_writel(0, OMAP34XX_DMA4_BASE
> > + + OMAP_DMA4_CDAC(up->uart_dma.rx_dma_channel));
>
> NAK. Please don't use omap_read/write for for new code. And do not
> tinker with the omap hardware registers directly in the driver.
>
> This needs to be done properly in arch/arm/plat-omap/dma.c instead.
Thanks for the suggestion.
Currently, dma_read/dma_write are #define's in dma.c which cannot be
accessed outside dma.c. I don't see any API's in dma.c for setting required
value for this register?
Can we move dma_read/dma_write to header file so that it can be global or
Is there alternate way to perform this operation with existing dma driver?
-Manjunath--
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
[UPDATE] kill camel case
Hi All, CamelCase script execution has been completed, so far I replaced all the tokens picked up by the killcc script[1], and all the changes are present in the following branches: dspbridge-next-camelcase It has all the changes made in three steps: 1) Replaced all the new tokens not present in bridge code, after that solved compilation problems caused by symbols with same name as kernel symbols. 2) Replaced tokens that were already present in bridge code either as symbols or strings. 3) Replaced tokens generated by script, which were same as other symbols, i.e. hChnlMgr and pChnlMgr will generate chnl_mgr. dspbridge-next-camelcase2 - It has the same changes as above but these are broken into single patches. Total number of patches: 2795 diff-stat: 157 files changed, 18385 insertions(+), 18385 deletions(-) Please take a look to the logs[2] as they might be easier to review rather than looking at each patch. Also I placed the steps to follow on the patch commits of dspbridge-next-camelcase. - omar --- [1] http://marc.info/?l=linux-omap&m=125353475429517&w=2 [2] https://gforge.ti.com/gf/project/omapbridge/docman/?subdir=30, logs for point 2 and 3 have the following format for tokens | | -- 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] [PATCHv4 7/7] ASoC: TWL6030: Detect power-up sequence completion
On Monday, March 01, 2010 6:14 AM Mark Brown wrote:
> On Fri, Feb 26, 2010 at 06:22:34PM -0600, Olaya, Margarita wrote:
>
>> Do you mean something like this?
>> time_left = wait_for_completion_timeout(&priv->ready,
>> msecs_to_jiffies(48));
>> if(!time_left) { twl_i2c_read_u8(TWL4030_MODULE_AUDIO_VOICE,
>> &intid, TWL6040_REG_INTID);
>> if (!(intid & TWL6040_READYINT))
>> goto error;
>> }
>>
>> return 0;
>>
>> error:
>> dev_err(codec->dev, "timeout waiting for READYINT\n");
>> return -ETIMEDOUT;
>
> Yes, or wrapped in a for loop with shorter timeouts on the
> individual waits.
>
>> but in this case will it not take unnecessarily 48ms when the
>> interruption line is not valid?
>
> You're always going to get some additional delay when polling
> unless you
> busy wait for completion, which obviously has its own problems.
Ok, thanks for the comment I'll re-write the loop for next version of
patches--
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 part2 v1][PATCH 1/4] omap2/3/4: serial: rename omap_serial_init
> -Original Message-
> From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
> Sent: Monday, March 01, 2010 5:49 PM
> To: Aguirre, Sergio
> Cc: linux-omap@vger.kernel.org
> Subject: Re: [RFC part2 v1][PATCH 1/4] omap2/3/4: serial: rename
> omap_serial_init
>
> "Aguirre, Sergio" writes:
>
> >> -Original Message-
> >> From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
> >> Sent: Monday, March 01, 2010 3:10 PM
> >> To: Aguirre, Sergio
> >> Cc: linux-omap@vger.kernel.org
> >> Subject: Re: [RFC part2 v1][PATCH 1/4] omap2/3/4: serial: rename
> >> omap_serial_init
> >>
> >> Sergio Aguirre writes:
> >>
> >> > The name itself doesn't make clear that all UARTs of the platform
> >> > are going to be initted. This is just to give more awareness of the
> >> > real action being done here.
> >> >
> >> > Signed-off-by: Sergio Aguirre
> >>
> >> IMO, I don't think this adds any more clarity.
> >
> > OK. But, do you mean that this is clear enough already, or that you have
> a better suggestion than mine?
>
> Personally, I think it's clear enough the way it is.
Ok, I think I'll drop it from the series, and repost a new version tomorrow.
Regards,
Sergio
>
> Kevin
>
>
> > The reason I wanted to propose this change is because, you either use:
> >
> > omap_serial_init()
> >
> > or
> >
> > omap_serial_init_port(number)
> >
> > And for me it looked more consistent to have it named
> omap_serial_init_allports instead...
>
>
> >
> >>
> >> Kevin
> >>
> >>
> >> > ---
> >> > arch/arm/mach-omap2/board-2430sdp.c |2 +-
> >> > arch/arm/mach-omap2/board-3430sdp.c |2 +-
> >> > arch/arm/mach-omap2/board-4430sdp.c |2 +-
> >> > arch/arm/mach-omap2/board-am3517evm.c|2 +-
> >> > arch/arm/mach-omap2/board-apollon.c |2 +-
> >> > arch/arm/mach-omap2/board-cm-t35.c |2 +-
> >> > arch/arm/mach-omap2/board-devkit8000.c |2 +-
> >> > arch/arm/mach-omap2/board-generic.c |2 +-
> >> > arch/arm/mach-omap2/board-h4.c |2 +-
> >> > arch/arm/mach-omap2/board-igep0020.c |2 +-
> >> > arch/arm/mach-omap2/board-ldp.c |2 +-
> >> > arch/arm/mach-omap2/board-n8x0.c |2 +-
> >> > arch/arm/mach-omap2/board-omap3beagle.c |2 +-
> >> > arch/arm/mach-omap2/board-omap3evm.c |2 +-
> >> > arch/arm/mach-omap2/board-omap3pandora.c |2 +-
> >> > arch/arm/mach-omap2/board-omap3touchbook.c |2 +-
> >> > arch/arm/mach-omap2/board-overo.c|2 +-
> >> > arch/arm/mach-omap2/board-rx51.c |2 +-
> >> > arch/arm/mach-omap2/board-zoom-peripherals.c |2 +-
> >> > arch/arm/mach-omap2/serial.c |8
> >> > arch/arm/plat-omap/include/plat/serial.h |2 +-
> >> > 21 files changed, 24 insertions(+), 24 deletions(-)
> >> > mode change 100755 => 100644 arch/arm/mach-omap2/board-zoom-
> >> peripherals.c
> >> >
> >> > diff --git a/arch/arm/mach-omap2/board-2430sdp.c b/arch/arm/mach-
> >> omap2/board-2430sdp.c
> >> > index 01d113f..abc55bc 100644
> >> > --- a/arch/arm/mach-omap2/board-2430sdp.c
> >> > +++ b/arch/arm/mach-omap2/board-2430sdp.c
> >> > @@ -206,7 +206,7 @@ static void __init omap_2430sdp_init(void)
> >> > omap2430_i2c_init();
> >> >
> >> > platform_add_devices(sdp2430_devices,
> ARRAY_SIZE(sdp2430_devices));
> >> > - omap_serial_init();
> >> > + omap_serial_init_allports();
> >> > omap2_hsmmc_init(mmc);
> >> > usb_musb_init(&musb_board_data);
> >> > board_smc91x_init();
> >> > diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-
> >> omap2/board-3430sdp.c
> >> > index f312b15..8c84973 100644
> >> > --- a/arch/arm/mach-omap2/board-3430sdp.c
> >> > +++ b/arch/arm/mach-omap2/board-3430sdp.c
> >> > @@ -799,7 +799,7 @@ static void __init omap_3430sdp_init(void)
> >> > spi_register_board_info(sdp3430_spi_board_info,
> >> > ARRAY_SIZE(sdp3430_spi_board_info));
> >> > ads7846_dev_init();
> >> > - omap_serial_init();
> >> > + omap_serial_init_allports();
> >> > usb_musb_init(&musb_board_data);
> >> > board_smc91x_init();
> >> > sdp_flash_init(sdp_flash_partitions);
> >> > diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-
> >> omap2/board-4430sdp.c
> >> > index 029c6c9..1d47064 100644
> >> > --- a/arch/arm/mach-omap2/board-4430sdp.c
> >> > +++ b/arch/arm/mach-omap2/board-4430sdp.c
> >> > @@ -84,7 +84,7 @@ static struct omap_musb_board_data musb_board_data
> = {
> >> > static void __init omap_4430sdp_init(void)
> >> > {
> >> > platform_add_devices(sdp4430_devices,
> ARRAY_SIZE(sdp4430_devices));
> >> > - omap_serial_init();
> >> > + omap_serial_init_allports();
> >> > /* OMAP4 SDP uses internal transceiver so register nop
> transceiver
> >> */
> >> > usb_nop_xceiv_register();
> >> > /* FIXME: allow multi-omap to boot until musb is updated for
> omap4
>
Re: [RFC part2 v1][PATCH 1/4] omap2/3/4: serial: rename omap_serial_init
"Aguirre, Sergio" writes:
>> -Original Message-
>> From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
>> Sent: Monday, March 01, 2010 3:10 PM
>> To: Aguirre, Sergio
>> Cc: linux-omap@vger.kernel.org
>> Subject: Re: [RFC part2 v1][PATCH 1/4] omap2/3/4: serial: rename
>> omap_serial_init
>>
>> Sergio Aguirre writes:
>>
>> > The name itself doesn't make clear that all UARTs of the platform
>> > are going to be initted. This is just to give more awareness of the
>> > real action being done here.
>> >
>> > Signed-off-by: Sergio Aguirre
>>
>> IMO, I don't think this adds any more clarity.
>
> OK. But, do you mean that this is clear enough already, or that you have a
> better suggestion than mine?
Personally, I think it's clear enough the way it is.
Kevin
> The reason I wanted to propose this change is because, you either use:
>
> omap_serial_init()
>
> or
>
> omap_serial_init_port(number)
>
> And for me it looked more consistent to have it named
> omap_serial_init_allports instead...
>
>>
>> Kevin
>>
>>
>> > ---
>> > arch/arm/mach-omap2/board-2430sdp.c |2 +-
>> > arch/arm/mach-omap2/board-3430sdp.c |2 +-
>> > arch/arm/mach-omap2/board-4430sdp.c |2 +-
>> > arch/arm/mach-omap2/board-am3517evm.c|2 +-
>> > arch/arm/mach-omap2/board-apollon.c |2 +-
>> > arch/arm/mach-omap2/board-cm-t35.c |2 +-
>> > arch/arm/mach-omap2/board-devkit8000.c |2 +-
>> > arch/arm/mach-omap2/board-generic.c |2 +-
>> > arch/arm/mach-omap2/board-h4.c |2 +-
>> > arch/arm/mach-omap2/board-igep0020.c |2 +-
>> > arch/arm/mach-omap2/board-ldp.c |2 +-
>> > arch/arm/mach-omap2/board-n8x0.c |2 +-
>> > arch/arm/mach-omap2/board-omap3beagle.c |2 +-
>> > arch/arm/mach-omap2/board-omap3evm.c |2 +-
>> > arch/arm/mach-omap2/board-omap3pandora.c |2 +-
>> > arch/arm/mach-omap2/board-omap3touchbook.c |2 +-
>> > arch/arm/mach-omap2/board-overo.c|2 +-
>> > arch/arm/mach-omap2/board-rx51.c |2 +-
>> > arch/arm/mach-omap2/board-zoom-peripherals.c |2 +-
>> > arch/arm/mach-omap2/serial.c |8
>> > arch/arm/plat-omap/include/plat/serial.h |2 +-
>> > 21 files changed, 24 insertions(+), 24 deletions(-)
>> > mode change 100755 => 100644 arch/arm/mach-omap2/board-zoom-
>> peripherals.c
>> >
>> > diff --git a/arch/arm/mach-omap2/board-2430sdp.c b/arch/arm/mach-
>> omap2/board-2430sdp.c
>> > index 01d113f..abc55bc 100644
>> > --- a/arch/arm/mach-omap2/board-2430sdp.c
>> > +++ b/arch/arm/mach-omap2/board-2430sdp.c
>> > @@ -206,7 +206,7 @@ static void __init omap_2430sdp_init(void)
>> > omap2430_i2c_init();
>> >
>> > platform_add_devices(sdp2430_devices, ARRAY_SIZE(sdp2430_devices));
>> > - omap_serial_init();
>> > + omap_serial_init_allports();
>> > omap2_hsmmc_init(mmc);
>> > usb_musb_init(&musb_board_data);
>> > board_smc91x_init();
>> > diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-
>> omap2/board-3430sdp.c
>> > index f312b15..8c84973 100644
>> > --- a/arch/arm/mach-omap2/board-3430sdp.c
>> > +++ b/arch/arm/mach-omap2/board-3430sdp.c
>> > @@ -799,7 +799,7 @@ static void __init omap_3430sdp_init(void)
>> > spi_register_board_info(sdp3430_spi_board_info,
>> > ARRAY_SIZE(sdp3430_spi_board_info));
>> > ads7846_dev_init();
>> > - omap_serial_init();
>> > + omap_serial_init_allports();
>> > usb_musb_init(&musb_board_data);
>> > board_smc91x_init();
>> > sdp_flash_init(sdp_flash_partitions);
>> > diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-
>> omap2/board-4430sdp.c
>> > index 029c6c9..1d47064 100644
>> > --- a/arch/arm/mach-omap2/board-4430sdp.c
>> > +++ b/arch/arm/mach-omap2/board-4430sdp.c
>> > @@ -84,7 +84,7 @@ static struct omap_musb_board_data musb_board_data = {
>> > static void __init omap_4430sdp_init(void)
>> > {
>> > platform_add_devices(sdp4430_devices, ARRAY_SIZE(sdp4430_devices));
>> > - omap_serial_init();
>> > + omap_serial_init_allports();
>> > /* OMAP4 SDP uses internal transceiver so register nop transceiver
>> */
>> > usb_nop_xceiv_register();
>> > /* FIXME: allow multi-omap to boot until musb is updated for omap4
>> */
>> > diff --git a/arch/arm/mach-omap2/board-am3517evm.c b/arch/arm/mach-
>> omap2/board-am3517evm.c
>> > index e6b8967..d88b31f 100644
>> > --- a/arch/arm/mach-omap2/board-am3517evm.c
>> > +++ b/arch/arm/mach-omap2/board-am3517evm.c
>> > @@ -300,7 +300,7 @@ static void __init am3517_evm_init(void)
>> > platform_add_devices(am3517_evm_devices,
>> > ARRAY_SIZE(am3517_evm_devices));
>> >
>> > - omap_serial_init();
>> > + omap_serial_init_allports();
>> > usb_ehci_init(&ehci_pdata);
>> > /* DSS */
>> > am3517_evm_display_init();
>> > dif
Re: [PATCHv6 9/9] OMAP3: PM: Added support for suspending to INACTIVE state
Tero Kristo writes:
> From: Tero Kristo
>
> With the new support functions this is now possible. Suspending to INACTIVE
> is useful for testing purposes.
>
> Signed-off-by: Tero Kristo
> ---
> arch/arm/mach-omap2/pm34xx.c | 11 ++-
> 1 files changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> index cdbedcf..41d6cc3 100644
> --- a/arch/arm/mach-omap2/pm34xx.c
> +++ b/arch/arm/mach-omap2/pm34xx.c
> @@ -633,11 +633,12 @@ int set_pwrdm_state(struct powerdomain *pwrdm, u32
> state)
> if (pwrdm == NULL || IS_ERR(pwrdm))
> return -EINVAL;
>
> - while (!(pwrdm->pwrsts & (1 << state))) {
> - if (state == PWRDM_POWER_OFF)
> - return ret;
> - state--;
> - }
The comment above set_pwrdm_state() says only ON & RET are supported.
Please update that comment as well.
> + if (state != PWRDM_POWER_INACTIVE)
> + while (!(pwrdm->pwrsts & (1 << state))) {
> + if (state == PWRDM_POWER_OFF)
> + return ret;
> + state--;
> + }
I think all powerdomains can be inactive right?
I think it would be cleaner to just have all the pwrdm->pwrsts fields
include intactive as a valid option.
Something like the patch below. IIRC, you did something like this in
one of the earlier versions of the patch.
Kevin
diff --git a/arch/arm/plat-omap/include/plat/powerdomain.h
b/arch/arm/plat-omap/include/plat/powerdomain.h
index a1ecd47..c692472 100644
--- a/arch/arm/plat-omap/include/plat/powerdomain.h
+++ b/arch/arm/plat-omap/include/plat/powerdomain.h
@@ -31,17 +31,17 @@
#define PWRDM_MAX_PWRSTS 4
/* Powerdomain allowable state bitfields */
-#define PWRSTS_OFF_ON ((1 << PWRDM_POWER_OFF) | \
+#define PWRSTS_ON ((1 << PWRDM_POWER_INACTIVE) | \
(1 << PWRDM_POWER_ON))
+#define PWRSTS_OFF_ON ((1 << PWRDM_POWER_OFF) | PWRSTS_ON)
+
#define PWRSTS_OFF_RET ((1 << PWRDM_POWER_OFF) | \
(1 << PWRDM_POWER_RET))
-#define PWRSTS_RET_ON ((1 << PWRDM_POWER_RET) | \
-(1 << PWRDM_POWER_ON))
-
-#define PWRSTS_OFF_RET_ON (PWRSTS_OFF_RET | (1 << PWRDM_POWER_ON))
+#define PWRSTS_RET_ON ((1 << PWRDM_POWER_RET) | PWRSTS_ON)
+#define PWRSTS_OFF_RET_ON (PWRSTS_OFF_RET | PWRSTS_ON)
/* Powerdomain flags */
#define PWRDM_HAS_HDWR_SAR (1 << 0) /* hardware save-and-restore support */
--
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: [PATCHv6 6/9] OMAP: Powerdomains: Add support for checking if pwrdm/clkdm can idle
Tero Kristo writes:
> From: Tero Kristo
>
> pwrdm_can_idle(pwrdm) will check if the specified powerdomain can enter
> idle. This is done by checking all clockdomains under the powerdomain
> if they can idle also.
>
> omap2_clkdm_can_idle(clkdm) will check if the specified clockdomain can
> enter idle. This checks the functional clocks and idle status bits of the
> domain according to following rules:
> 1) functional clock check
> * get FCLK register content
> * ignore all clocks defined in idle_def.fclk_ignore
> * if any active functional clocks remain, domain can't idle
> 2) idle status check
> * get IDLEST register content
> * inverse it (any non-idle blocks are now as 1)
> * mask against idle_def.idlest_mask
> * if any bits remain high, domain can't idle
>
> These calls can be used e.g. inside cpuidle to decide which power states
> core and mpu should enter during idle, as there are certain dependencies
> between wakeup capabilities and reset logic.
>
> Signed-off-by: Tero Kristo
I'm OK with this version.
Paul?
Kevin
> ---
> arch/arm/mach-omap2/clockdomain.c | 32
> arch/arm/mach-omap2/clockdomains.h| 106
> +
> arch/arm/mach-omap2/powerdomain.c | 20 +
> arch/arm/plat-omap/include/plat/clockdomain.h | 17
> arch/arm/plat-omap/include/plat/powerdomain.h |1 +
> 5 files changed, 176 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/clockdomain.c
> b/arch/arm/mach-omap2/clockdomain.c
> index a38a615..9ebff51 100644
> --- a/arch/arm/mach-omap2/clockdomain.c
> +++ b/arch/arm/mach-omap2/clockdomain.c
> @@ -867,6 +867,38 @@ int omap2_clkdm_wakeup(struct clockdomain *clkdm)
> return 0;
> }
>
> +
> +/**
> + * omap2_clkdm_can_idle - check if clockdomain has any active clocks or not
> + * @clkdm: struct clockdomain *
> + *
> + * Checks if the clockdomain has any active clock or not, i.e. whether it
> + * can enter idle. Returns -EINVAL if clkdm is NULL; 0 if unable to idle;
> + * 1 if can idle.
> + */
> +int omap2_clkdm_can_idle(struct clockdomain *clkdm)
> +{
> + int i;
> +
> + if (!clkdm)
> + return -EINVAL;
> +
> + for (i = 0; i < clkdm->clk_reg_num; i++) {
> + u32 idlest, fclk;
> +
> + fclk = cm_read_mod_reg(clkdm->pwrdm.ptr->prcm_offs,
> + CM_FCLKEN + 4 * i);
> + if (fclk & ~clkdm->idle_def[i].fclk_ignore)
> + return 0;
> +
> + idlest = cm_read_mod_reg(clkdm->pwrdm.ptr->prcm_offs,
> + CM_IDLEST + 4 * i);
> + if (~idlest & clkdm->idle_def[i].idlest_mask)
> + return 0;
> + }
> + return 1;
> +}
> +
> /**
> * omap2_clkdm_allow_idle - enable hwsup idle transitions for clkdm
> * @clkdm: struct clockdomain *
> diff --git a/arch/arm/mach-omap2/clockdomains.h
> b/arch/arm/mach-omap2/clockdomains.h
> index 8fc19ff..5e29de8 100644
> --- a/arch/arm/mach-omap2/clockdomains.h
> +++ b/arch/arm/mach-omap2/clockdomains.h
> @@ -663,6 +663,12 @@ static struct clockdomain iva2_clkdm = {
> .wkdep_srcs = iva2_wkdeps,
> .clktrctrl_mask = OMAP3430_CLKTRCTRL_IVA2_MASK,
> .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
> + .clk_reg_num= 1,
> + .idle_def = {
> + [0] = {
> + .idlest_mask = OMAP3430_ST_IVA2,
> + },
> + },
> };
>
> static struct clockdomain gfx_3430es1_clkdm = {
> @@ -686,6 +692,12 @@ static struct clockdomain sgx_clkdm = {
> .sleepdep_srcs = gfx_sgx_sleepdeps,
> .clktrctrl_mask = OMAP3430ES2_CLKTRCTRL_SGX_MASK,
> .omap_chip = OMAP_CHIP_INIT(CHIP_GE_OMAP3430ES2),
> + .clk_reg_num= 1,
> + .idle_def = {
> + [0] = {
> + .idlest_mask = OMAP3430ES2_ST_SGX_SHIFT,
> + },
> + },
> };
>
> /*
> @@ -717,6 +729,57 @@ static struct clockdomain core_l3_3xxx_clkdm = {
> .dep_bit= OMAP3430_EN_CORE_SHIFT,
> .clktrctrl_mask = OMAP3430_CLKTRCTRL_L3_MASK,
> .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
> + .clk_reg_num= 3,
> + .idle_def = {
> + [0] = {
> + /* UARTs are controlled by idle loop so ignore */
> + .fclk_ignore = OMAP3430_EN_UART2 |
> + OMAP3430_EN_UART1,
> + /*
> + * Reason for IDLEST ignores:
> + * - SDRC and OMAPCTRL controlled by HW
> + * - HSOTGUSB_IDLE bit is autoidled by HW
> + * - MAILBOX is controlled by HW
> + */
> + .idlest_mask =
> + OMAP3430ES2_ST_MMC3_MASK |
> + OMAP3430_ST_ICR_MASK |
> + OMAP3430_ST_AES2_MASK |
> + OMA
Re: [PATCHv6 4/9] OMAP3: PM: Removed pwrdm state hacking from omap_sram_idle
Tero Kristo writes:
> From: Tero Kristo
>
> Following hacks will be moved inside cpuidle in subsequent patch:
>
> - CAM domain prevents idle completely
> - PER should not go OFF if core remains active
>
> This simplifies the design and allows cpuidle to keep better track of which
> power states system will actually enter.
>
> Signed-off-by: Tero Kristo
I think this should be combined with PATCH 7. IOW, the removal and
re-addition should be in the same patch.
Kevin
> ---
> arch/arm/mach-omap2/pm34xx.c | 19 ++-
> 1 files changed, 2 insertions(+), 17 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> index c2d80fc..cdbedcf 100644
> --- a/arch/arm/mach-omap2/pm34xx.c
> +++ b/arch/arm/mach-omap2/pm34xx.c
> @@ -93,7 +93,6 @@ static int (*_omap_save_secure_sram)(u32 *addr);
>
> static struct powerdomain *mpu_pwrdm, *neon_pwrdm;
> static struct powerdomain *core_pwrdm, *per_pwrdm;
> -static struct powerdomain *cam_pwrdm;
>
> static struct prm_setup_vc prm_setup = {
> .clksetup = 0xff,
> @@ -373,7 +372,6 @@ void omap_sram_idle(void)
> int core_next_state = PWRDM_POWER_ON;
> int core_prev_state, per_prev_state;
> u32 sdrc_pwr = 0;
> - int per_state_modified = 0;
>
> if (!_omap_sram_idle)
> return;
> @@ -411,20 +409,11 @@ void omap_sram_idle(void)
> core_next_state = omap3_pwrdm_read_next_pwrst(core_pwrdm);
> if (per_next_state < PWRDM_POWER_ON) {
> omap2_gpio_prepare_for_idle(per_next_state);
> - if (per_next_state == PWRDM_POWER_OFF) {
> - if (core_next_state == PWRDM_POWER_ON) {
> - per_next_state = PWRDM_POWER_RET;
> - pwrdm_set_next_pwrst(per_pwrdm, per_next_state);
> - per_state_modified = 1;
> - } else
> - omap3_per_save_context();
> - }
> + if (per_next_state == PWRDM_POWER_OFF)
> + omap3_per_save_context();
> omap_uart_prepare_idle(2);
> }
>
> - if (pwrdm_read_pwrst(cam_pwrdm) == PWRDM_POWER_ON)
> - omap2_clkdm_deny_idle(mpu_pwrdm->pwrdm_clkdms[0]);
> -
> /*
>* Disable smartreflex before entering WFI.
>* Only needed if we are going to enter retention or off.
> @@ -554,8 +543,6 @@ void omap_sram_idle(void)
> }
> omap2_gpio_resume_after_idle();
> omap_uart_resume_idle(2);
> - if (per_state_modified)
> - pwrdm_set_next_pwrst(per_pwrdm, PWRDM_POWER_OFF);
> }
>
> /* Disable IO-PAD and IO-CHAIN wakeup */
> @@ -564,7 +551,6 @@ void omap_sram_idle(void)
> omap3_disable_io_chain();
> }
>
> -
> pwrdm_post_transition();
> }
>
> @@ -1239,7 +1225,6 @@ static int __init omap3_pm_init(void)
> neon_pwrdm = pwrdm_lookup("neon_pwrdm");
> per_pwrdm = pwrdm_lookup("per_pwrdm");
> core_pwrdm = pwrdm_lookup("core_pwrdm");
> - cam_pwrdm = pwrdm_lookup("cam_pwrdm");
>
> neon_clkdm = clkdm_lookup("neon_clkdm");
> mpu_clkdm = clkdm_lookup("mpu_clkdm");
> --
> 1.5.4.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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 part2 v1][PATCH 1/4] omap2/3/4: serial: rename omap_serial_init
> -Original Message-
> From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
> Sent: Monday, March 01, 2010 3:10 PM
> To: Aguirre, Sergio
> Cc: linux-omap@vger.kernel.org
> Subject: Re: [RFC part2 v1][PATCH 1/4] omap2/3/4: serial: rename
> omap_serial_init
>
> Sergio Aguirre writes:
>
> > The name itself doesn't make clear that all UARTs of the platform
> > are going to be initted. This is just to give more awareness of the
> > real action being done here.
> >
> > Signed-off-by: Sergio Aguirre
>
> IMO, I don't think this adds any more clarity.
OK. But, do you mean that this is clear enough already, or that you have a
better suggestion than mine?
The reason I wanted to propose this change is because, you either use:
omap_serial_init()
or
omap_serial_init_port(number)
And for me it looked more consistent to have it named omap_serial_init_allports
instead...
Regards,
Sergio
>
> Kevin
>
>
> > ---
> > arch/arm/mach-omap2/board-2430sdp.c |2 +-
> > arch/arm/mach-omap2/board-3430sdp.c |2 +-
> > arch/arm/mach-omap2/board-4430sdp.c |2 +-
> > arch/arm/mach-omap2/board-am3517evm.c|2 +-
> > arch/arm/mach-omap2/board-apollon.c |2 +-
> > arch/arm/mach-omap2/board-cm-t35.c |2 +-
> > arch/arm/mach-omap2/board-devkit8000.c |2 +-
> > arch/arm/mach-omap2/board-generic.c |2 +-
> > arch/arm/mach-omap2/board-h4.c |2 +-
> > arch/arm/mach-omap2/board-igep0020.c |2 +-
> > arch/arm/mach-omap2/board-ldp.c |2 +-
> > arch/arm/mach-omap2/board-n8x0.c |2 +-
> > arch/arm/mach-omap2/board-omap3beagle.c |2 +-
> > arch/arm/mach-omap2/board-omap3evm.c |2 +-
> > arch/arm/mach-omap2/board-omap3pandora.c |2 +-
> > arch/arm/mach-omap2/board-omap3touchbook.c |2 +-
> > arch/arm/mach-omap2/board-overo.c|2 +-
> > arch/arm/mach-omap2/board-rx51.c |2 +-
> > arch/arm/mach-omap2/board-zoom-peripherals.c |2 +-
> > arch/arm/mach-omap2/serial.c |8
> > arch/arm/plat-omap/include/plat/serial.h |2 +-
> > 21 files changed, 24 insertions(+), 24 deletions(-)
> > mode change 100755 => 100644 arch/arm/mach-omap2/board-zoom-
> peripherals.c
> >
> > diff --git a/arch/arm/mach-omap2/board-2430sdp.c b/arch/arm/mach-
> omap2/board-2430sdp.c
> > index 01d113f..abc55bc 100644
> > --- a/arch/arm/mach-omap2/board-2430sdp.c
> > +++ b/arch/arm/mach-omap2/board-2430sdp.c
> > @@ -206,7 +206,7 @@ static void __init omap_2430sdp_init(void)
> > omap2430_i2c_init();
> >
> > platform_add_devices(sdp2430_devices, ARRAY_SIZE(sdp2430_devices));
> > - omap_serial_init();
> > + omap_serial_init_allports();
> > omap2_hsmmc_init(mmc);
> > usb_musb_init(&musb_board_data);
> > board_smc91x_init();
> > diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-
> omap2/board-3430sdp.c
> > index f312b15..8c84973 100644
> > --- a/arch/arm/mach-omap2/board-3430sdp.c
> > +++ b/arch/arm/mach-omap2/board-3430sdp.c
> > @@ -799,7 +799,7 @@ static void __init omap_3430sdp_init(void)
> > spi_register_board_info(sdp3430_spi_board_info,
> > ARRAY_SIZE(sdp3430_spi_board_info));
> > ads7846_dev_init();
> > - omap_serial_init();
> > + omap_serial_init_allports();
> > usb_musb_init(&musb_board_data);
> > board_smc91x_init();
> > sdp_flash_init(sdp_flash_partitions);
> > diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-
> omap2/board-4430sdp.c
> > index 029c6c9..1d47064 100644
> > --- a/arch/arm/mach-omap2/board-4430sdp.c
> > +++ b/arch/arm/mach-omap2/board-4430sdp.c
> > @@ -84,7 +84,7 @@ static struct omap_musb_board_data musb_board_data = {
> > static void __init omap_4430sdp_init(void)
> > {
> > platform_add_devices(sdp4430_devices, ARRAY_SIZE(sdp4430_devices));
> > - omap_serial_init();
> > + omap_serial_init_allports();
> > /* OMAP4 SDP uses internal transceiver so register nop transceiver
> */
> > usb_nop_xceiv_register();
> > /* FIXME: allow multi-omap to boot until musb is updated for omap4
> */
> > diff --git a/arch/arm/mach-omap2/board-am3517evm.c b/arch/arm/mach-
> omap2/board-am3517evm.c
> > index e6b8967..d88b31f 100644
> > --- a/arch/arm/mach-omap2/board-am3517evm.c
> > +++ b/arch/arm/mach-omap2/board-am3517evm.c
> > @@ -300,7 +300,7 @@ static void __init am3517_evm_init(void)
> > platform_add_devices(am3517_evm_devices,
> > ARRAY_SIZE(am3517_evm_devices));
> >
> > - omap_serial_init();
> > + omap_serial_init_allports();
> > usb_ehci_init(&ehci_pdata);
> > /* DSS */
> > am3517_evm_display_init();
> > diff --git a/arch/arm/mach-omap2/board-apollon.c b/arch/arm/mach-
> omap2/board-apollon.c
> > index aa69fb9..6c14392 100644
> > --- a/arch/arm/mach-omap2/board-apollon.c
> > +++ b/arch/arm/mach-omap2/boar
Re: [PATCHv6 0/9] Refreshed idlestatus patches with minor fixes
Tero Kristo writes: > From: Tero Kristo > > Following changes compared to previous set: > > - Fixed a problem with PER domain handling when PER was active > - Removed rwlock usage from pwrdm_can_idle as the lock was removed from > powerdomain code > > Still applies on top of PM branch. This is looking good now, and I'm mostly ready to merge this. However, a couple more small things need attention. I'll have some small comments on a couple of the individual patches. The CPUidle patches (3, 7, and 8) need a refresh against current PM branch. In fact, I think 8 can be dropped as a similar fix from Sanjeev is merged in the PM branch now. Also, patch 7 doesn't compile against PM branch as it's missing the definition of 'iva2_pd'. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv6 1/9] OMAP3: PM: Added support functions for omap3 pwrdm handling
Tero Kristo writes:
> From: Tero Kristo
>
> Added omap3_pwrdm_set_next_pwrst and omap3_pwrdm_read_next_pwrst. These
> functions add support for INACTIVE and ON states to the standard OMAP
> powerdomain functions, and add caching logic for the next state. These
> functions are used in subsequent patches to simplify the logic of the idle
> loop.
>
> Signed-off-by: Tero Kristo
> ---
> arch/arm/mach-omap2/pm.h |2 +
> arch/arm/mach-omap2/pm34xx.c | 60
> +-
> 2 files changed, 61 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
> index 75aa685..1d9a740 100644
> --- a/arch/arm/mach-omap2/pm.h
> +++ b/arch/arm/mach-omap2/pm.h
> @@ -67,6 +67,8 @@ static inline void omap3_pm_init_vc(struct prm_setup_vc
> *setup_vc)
>
> extern int omap3_pm_get_suspend_state(struct powerdomain *pwrdm);
> extern int omap3_pm_set_suspend_state(struct powerdomain *pwrdm, int state);
> +extern int omap3_pwrdm_set_next_pwrst(struct powerdomain *pwrdm, u8 pwrst);
> +extern int omap3_pwrdm_read_next_pwrst(struct powerdomain *pwrdm);
>
> extern u32 wakeup_timer_seconds;
> extern struct omap_dm_timer *gptimer_wakeup;
> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> index 1359ec9..f20d3d8 100644
> --- a/arch/arm/mach-omap2/pm34xx.c
> +++ b/arch/arm/mach-omap2/pm34xx.c
> @@ -576,6 +576,64 @@ int omap3_can_sleep(void)
> return 1;
> }
>
> +struct powerdomain_data {
> + u8 next_state;
> + u8 init_done;
> +};
> +
> +static struct powerdomain_data mpu_pwrdm_data;
> +static struct powerdomain_data core_pwrdm_data;
> +static struct powerdomain_data neon_pwrdm_data;
> +
> +static struct powerdomain_data *get_pwrdm_data(struct powerdomain *pwrdm)
> +{
> + if (pwrdm == mpu_pwrdm)
> + return &mpu_pwrdm_data;
> + else if (pwrdm == core_pwrdm)
> + return &core_pwrdm_data;
> + else if (pwrdm == neon_pwrdm)
> + return &neon_pwrdm_data;
> + return NULL;
> +}
> +
> +int omap3_pwrdm_set_next_pwrst(struct powerdomain *pwrdm, u8 pwrst)
I think this func should be documented along the lines of the changelog.
It should describe the caching and the fact that 'INACTIVE' is a state
that can be read, but not written.
> +{
> + struct powerdomain_data *data = get_pwrdm_data(pwrdm);
> + u8 prg_pwrst;
> +
> + if (!data)
> + return pwrdm_set_next_pwrst(pwrdm, pwrst);
> +
> + if (!data->init_done)
> + data->init_done = 1;
Not sure I follow the purpose of the 'init_done' flag here, but I'm having
an averse reaction to it.
> + else if (data->next_state == pwrst)
> + return 0;
> +
> + if (pwrst == PWRDM_POWER_INACTIVE)
> + prg_pwrst = PWRDM_POWER_ON;
> + else
> + prg_pwrst = pwrst;
> +
> + pwrdm_set_next_pwrst(pwrdm, prg_pwrst);
> +
> + if (pwrst == PWRDM_POWER_ON)
> + omap2_clkdm_deny_idle(pwrdm->pwrdm_clkdms[0]);
> + else
> + omap2_clkdm_allow_idle(pwrdm->pwrdm_clkdms[0]);
> +
> + data->next_state = pwrst;
> + return 0;
> +}
> +
> +int omap3_pwrdm_read_next_pwrst(struct powerdomain *pwrdm)
> +{
> + struct powerdomain_data *data = get_pwrdm_data(pwrdm);
> +
> + if (!data || !data->init_done)
> + return pwrdm_read_next_pwrst(pwrdm);
> + return data->next_state;
> +}
> +
> /* This sets pwrdm state (other than mpu & core. Currently only ON &
> * RET are supported. Function is assuming that clkdm doesn't have
> * hw_sup mode enabled. */
> @@ -604,7 +662,7 @@ int set_pwrdm_state(struct powerdomain *pwrdm, u32 state)
> pwrdm_wait_transition(pwrdm);
> }
>
> - ret = pwrdm_set_next_pwrst(pwrdm, state);
> + ret = omap3_pwrdm_set_next_pwrst(pwrdm, state);
> if (ret) {
> printk(KERN_ERR "Unable to set state of powerdomain: %s\n",
> pwrdm->name);
> --
> 1.5.4.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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] board-n8x0: add USB initialization
From: Francisco Alecrim
Based on Kalle's and Tony's patches. Some variables re-organized and
unused code remove(68499cc5716bbeca16ca8c83ec6e9f04b8dbfacb).
Signed-off-by: Kalle Valo
Signed-off-by: Francisco Alecrim
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/board-n8x0.c | 92 ++
arch/arm/mach-omap2/clock2420_data.c |1 +
include/linux/usb/musb.h |4 ++
3 files changed, 97 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-n8x0.c b/arch/arm/mach-omap2/board-n8x0.c
index ee548dd..79d659a 100644
--- a/arch/arm/mach-omap2/board-n8x0.c
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@ -32,6 +32,97 @@
#include
#include
+#if defined(CONFIG_USB_TUSB6010) || \
+ defined(CONFIG_USB_TUSB6010_MODULE)
+/*
+ * Enable or disable power to TUSB6010. When enabling, turn on 3.3 V and
+ * 1.5 V voltage regulators of PM companion chip. Companion chip will then
+ * provide then PGOOD signal to TUSB6010 which will release it from reset.
+ */
+static int tusb_set_power(int state)
+{
+ int i, retval = 0;
+
+ if (state) {
+ gpio_set_value(TUSB6010_GPIO_ENABLE, 1);
+ msleep(1);
+
+ /* Wait until TUSB6010 pulls INT pin down */
+ i = 100;
+ while (i && gpio_get_value(TUSB6010_GPIO_INT)) {
+ msleep(1);
+ i--;
+ }
+
+ if (!i) {
+ printk(KERN_ERR "tusb: powerup failed\n");
+ retval = -ENODEV;
+ }
+ } else {
+ gpio_set_value(TUSB6010_GPIO_ENABLE, 0);
+ msleep(10);
+ }
+
+ return retval;
+}
+
+static struct musb_hdrc_config musb_config = {
+ .multipoint = 1,
+ .dyn_fifo = 1,
+ .num_eps= 16,
+ .ram_bits = 12,
+};
+
+static struct musb_hdrc_platform_data tusb_data = {
+#if defined(CONFIG_USB_MUSB_OTG)
+ .mode = MUSB_OTG,
+#elif defined(CONFIG_USB_MUSB_PERIPHERAL)
+ .mode = MUSB_PERIPHERAL,
+#else /* defined(CONFIG_USB_MUSB_HOST) */
+ .mode = MUSB_HOST,
+#endif
+ .set_power = tusb_set_power,
+ .min_power = 25, /* x2 = 50 mA drawn from VBUS as peripheral */
+ .power = 100, /* Max 100 mA VBUS for host mode */
+ .config = &musb_config,
+};
+
+static void __init n8x0_usb_init(void)
+{
+ int ret = 0;
+ static char announce[] __initdata = KERN_INFO "TUSB 6010\n";
+
+ /* PM companion chip power control pin */
+ ret = gpio_request(TUSB6010_GPIO_ENABLE, "TUSB6010 enable");
+ if (ret != 0) {
+ printk(KERN_ERR "Could not get TUSB power GPIO%i\n",
+ TUSB6010_GPIO_ENABLE);
+ return;
+ }
+ gpio_direction_output(TUSB6010_GPIO_ENABLE, 0);
+
+ tusb_set_power(0);
+
+ ret = tusb6010_setup_interface(&tusb_data, TUSB6010_REFCLK_19, 2,
+ TUSB6010_ASYNC_CS, TUSB6010_SYNC_CS,
+ TUSB6010_GPIO_INT, 0x3f);
+ if (ret != 0)
+ goto err;
+
+ printk(announce);
+
+ return;
+
+err:
+ gpio_free(TUSB6010_GPIO_ENABLE);
+}
+#else
+
+static void __init n8x0_usb_init(void) {}
+
+#endif /*CONFIG_USB_TUSB6010 */
+
+
static struct omap2_mcspi_device_config p54spi_mcspi_config = {
.turbo_mode = 0,
.single_channel = 1,
@@ -148,6 +239,7 @@ static void __init n8x0_init_machine(void)
omap_serial_init();
n8x0_onenand_init();
+ n8x0_usb_init();
}
MACHINE_START(NOKIA_N800, "Nokia N800")
diff --git a/arch/arm/mach-omap2/clock2420_data.c
b/arch/arm/mach-omap2/clock2420_data.c
index f12af95..d932b14 100644
--- a/arch/arm/mach-omap2/clock2420_data.c
+++ b/arch/arm/mach-omap2/clock2420_data.c
@@ -1841,6 +1841,7 @@ static struct omap_clk omap2420_clks[] = {
CLK(NULL, "aes_ick", &aes_ick, CK_242X),
CLK(NULL, "pka_ick", &pka_ick, CK_242X),
CLK(NULL, "usb_fck", &usb_fck, CK_242X),
+ CLK("musb_hdrc","fck", &osc_ck,CK_242X),
};
/*
diff --git a/include/linux/usb/musb.h b/include/linux/usb/musb.h
index 3fdeef5..c281ce0 100644
--- a/include/linux/usb/musb.h
+++ b/include/linux/usb/musb.h
@@ -98,6 +98,10 @@ struct musb_hdrc_platform_data {
#defineTUSB6010_OSCCLK_60 16667 /* psec/clk @ 60.0 MHz */
#defineTUSB6010_REFCLK_24 41667 /* psec/clk @ 24.0 MHz XI */
#defineTUSB6010_REFCLK_19 52083 /* psec/clk @ 19.2 MHz CLKIN */
+#define TUSB6010_ASYNC_CS 1
+#define TUSB6010_SYNC_CS 4
+#define TUSB6010_GPIO_INT 58
+#define TUSB6010_GPIO_ENABLE 0
#ifdef CONFIG_ARCH_OMAP2
--
1.6.3.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majo
Re: [RFC part2 v1][PATCH 2/4] omap3: zoom2/3 / 3630sdp: Don't init always all uarts
Sergio Aguirre writes:
> This is useless, since in Zoom2/3 boards, the ports aren't even
> physically accessible.
>
> They must be explicitly initted in the board-zoom2.c, board-zoom3.c
> and board-3630sdp.c files instead.
>
> Signed-off-by: Sergio Aguirre
/me likes
Acked-by: Kevin Hilman
> ---
> arch/arm/mach-omap2/board-zoom-peripherals.c |1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c
> b/arch/arm/mach-omap2/board-zoom-peripherals.c
> index a1011ee..6b39849 100644
> --- a/arch/arm/mach-omap2/board-zoom-peripherals.c
> +++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
> @@ -280,7 +280,6 @@ static void enable_board_wakeup_source(void)
> void __init zoom_peripherals_init(void)
> {
> omap_i2c_init();
> - omap_serial_init_allports();
> usb_musb_init(&musb_board_data);
> enable_board_wakeup_source();
> }
> --
> 1.6.3.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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 part2 v1][PATCH 4/4] omap3: zoom 2/3: Change debugboard serial port id
Sergio Aguirre writes:
> This is now changed to PLAT8250_DEV_PLATFORM (= 0), because
> it is the only port that's going to be initted in Zoom 2/3 boards.
>
> So, it doesn't make sense to keep the hardcoded 3 value anymore.
>
> Signed-off-by: Sergio Aguirre
Acked-by: Kevin Hilman
In addition, when we switch to using omap-serial, this will be the
only 8250 driver (ttyS*), so it makes sense that it is zero.
Kevin
> --- arch/arm/mach-omap2/board-zoom-debugboard.c | 2 +- 1 files
> changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-zoom-debugboard.c
> b/arch/arm/mach-omap2/board-zoom-debugboard.c
> index bb4018b..e15d2e8 100644
> --- a/arch/arm/mach-omap2/board-zoom-debugboard.c
> +++ b/arch/arm/mach-omap2/board-zoom-debugboard.c
> @@ -96,7 +96,7 @@ static struct plat_serial8250_port serial_platform_data[] =
> {
>
> static struct platform_device zoom_debugboard_serial_device = {
> .name = "serial8250",
> - .id = 3,
> + .id = PLAT8250_DEV_PLATFORM,
> .dev= {
> .platform_data = serial_platform_data,
> },
> --
> 1.6.3.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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 part2 v1][PATCH 1/4] omap2/3/4: serial: rename omap_serial_init
Sergio Aguirre writes:
> The name itself doesn't make clear that all UARTs of the platform
> are going to be initted. This is just to give more awareness of the
> real action being done here.
>
> Signed-off-by: Sergio Aguirre
IMO, I don't think this adds any more clarity.
Kevin
> ---
> arch/arm/mach-omap2/board-2430sdp.c |2 +-
> arch/arm/mach-omap2/board-3430sdp.c |2 +-
> arch/arm/mach-omap2/board-4430sdp.c |2 +-
> arch/arm/mach-omap2/board-am3517evm.c|2 +-
> arch/arm/mach-omap2/board-apollon.c |2 +-
> arch/arm/mach-omap2/board-cm-t35.c |2 +-
> arch/arm/mach-omap2/board-devkit8000.c |2 +-
> arch/arm/mach-omap2/board-generic.c |2 +-
> arch/arm/mach-omap2/board-h4.c |2 +-
> arch/arm/mach-omap2/board-igep0020.c |2 +-
> arch/arm/mach-omap2/board-ldp.c |2 +-
> arch/arm/mach-omap2/board-n8x0.c |2 +-
> arch/arm/mach-omap2/board-omap3beagle.c |2 +-
> arch/arm/mach-omap2/board-omap3evm.c |2 +-
> arch/arm/mach-omap2/board-omap3pandora.c |2 +-
> arch/arm/mach-omap2/board-omap3touchbook.c |2 +-
> arch/arm/mach-omap2/board-overo.c|2 +-
> arch/arm/mach-omap2/board-rx51.c |2 +-
> arch/arm/mach-omap2/board-zoom-peripherals.c |2 +-
> arch/arm/mach-omap2/serial.c |8
> arch/arm/plat-omap/include/plat/serial.h |2 +-
> 21 files changed, 24 insertions(+), 24 deletions(-)
> mode change 100755 => 100644 arch/arm/mach-omap2/board-zoom-peripherals.c
>
> diff --git a/arch/arm/mach-omap2/board-2430sdp.c
> b/arch/arm/mach-omap2/board-2430sdp.c
> index 01d113f..abc55bc 100644
> --- a/arch/arm/mach-omap2/board-2430sdp.c
> +++ b/arch/arm/mach-omap2/board-2430sdp.c
> @@ -206,7 +206,7 @@ static void __init omap_2430sdp_init(void)
> omap2430_i2c_init();
>
> platform_add_devices(sdp2430_devices, ARRAY_SIZE(sdp2430_devices));
> - omap_serial_init();
> + omap_serial_init_allports();
> omap2_hsmmc_init(mmc);
> usb_musb_init(&musb_board_data);
> board_smc91x_init();
> diff --git a/arch/arm/mach-omap2/board-3430sdp.c
> b/arch/arm/mach-omap2/board-3430sdp.c
> index f312b15..8c84973 100644
> --- a/arch/arm/mach-omap2/board-3430sdp.c
> +++ b/arch/arm/mach-omap2/board-3430sdp.c
> @@ -799,7 +799,7 @@ static void __init omap_3430sdp_init(void)
> spi_register_board_info(sdp3430_spi_board_info,
> ARRAY_SIZE(sdp3430_spi_board_info));
> ads7846_dev_init();
> - omap_serial_init();
> + omap_serial_init_allports();
> usb_musb_init(&musb_board_data);
> board_smc91x_init();
> sdp_flash_init(sdp_flash_partitions);
> diff --git a/arch/arm/mach-omap2/board-4430sdp.c
> b/arch/arm/mach-omap2/board-4430sdp.c
> index 029c6c9..1d47064 100644
> --- a/arch/arm/mach-omap2/board-4430sdp.c
> +++ b/arch/arm/mach-omap2/board-4430sdp.c
> @@ -84,7 +84,7 @@ static struct omap_musb_board_data musb_board_data = {
> static void __init omap_4430sdp_init(void)
> {
> platform_add_devices(sdp4430_devices, ARRAY_SIZE(sdp4430_devices));
> - omap_serial_init();
> + omap_serial_init_allports();
> /* OMAP4 SDP uses internal transceiver so register nop transceiver */
> usb_nop_xceiv_register();
> /* FIXME: allow multi-omap to boot until musb is updated for omap4 */
> diff --git a/arch/arm/mach-omap2/board-am3517evm.c
> b/arch/arm/mach-omap2/board-am3517evm.c
> index e6b8967..d88b31f 100644
> --- a/arch/arm/mach-omap2/board-am3517evm.c
> +++ b/arch/arm/mach-omap2/board-am3517evm.c
> @@ -300,7 +300,7 @@ static void __init am3517_evm_init(void)
> platform_add_devices(am3517_evm_devices,
> ARRAY_SIZE(am3517_evm_devices));
>
> - omap_serial_init();
> + omap_serial_init_allports();
> usb_ehci_init(&ehci_pdata);
> /* DSS */
> am3517_evm_display_init();
> diff --git a/arch/arm/mach-omap2/board-apollon.c
> b/arch/arm/mach-omap2/board-apollon.c
> index aa69fb9..6c14392 100644
> --- a/arch/arm/mach-omap2/board-apollon.c
> +++ b/arch/arm/mach-omap2/board-apollon.c
> @@ -331,7 +331,7 @@ static void __init omap_apollon_init(void)
>* if not needed.
>*/
> platform_add_devices(apollon_devices, ARRAY_SIZE(apollon_devices));
> - omap_serial_init();
> + omap_serial_init_allports();
> }
>
> static void __init omap_apollon_map_io(void)
> diff --git a/arch/arm/mach-omap2/board-cm-t35.c
> b/arch/arm/mach-omap2/board-cm-t35.c
> index afa77ca..e148835 100644
> --- a/arch/arm/mach-omap2/board-cm-t35.c
> +++ b/arch/arm/mach-omap2/board-cm-t35.c
> @@ -820,7 +820,7 @@ static struct omap_musb_board_data musb_board_data = {
> static void __init cm_t35_init(void)
> {
> omap3_mux_init(board_mux, OMAP_PACKAGE_CUS);
> - omap_serial_init();
> + omap_serial_init_allports();
Re: [PATCHv6] OMAP3: Serial: Improved sleep logic
Tero Kristo writes:
> From: Tero Kristo
>
> This patch contains following improvements:
> - Only RX interrupt will now kick the sleep prevent timer
> - TX fifo status is checked before disabling clocks, this will prevent
> on-going transmission to be cut
> - Smartidle is now enabled/disabled only while switching clocks, as having
> smartidle enabled while RX/TX prevents any wakeups from being received
> from UART module
> - Added workqueue for wakeup checks, as jiffy timer access within the
> idle loop results into skewed timers as jiffy timers are stopped
> - Added garbage_timer for ignoring the first character received during
> the first tick after clock enable, this prevents garbage characters to be
> received in low sleep states
> - omap_uart_enable_irqs() changed to use enable_irq / disable_irq instead
> of request / free. Using request/free changes the behavior after first
> suspend due to reversed interrupt handler ordering
>
> Signed-off-by: Tero Kristo
Thanks Tero. This version looks good.
Adding to pm-fixes queue for 2.6.34-rcX after minor change below...
> ---
> arch/arm/mach-omap2/serial.c | 67
> +++---
> 1 files changed, 56 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
> index 5f3035e..06d18f5 100644
> --- a/arch/arm/mach-omap2/serial.c
> +++ b/arch/arm/mach-omap2/serial.c
> @@ -23,6 +23,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -48,7 +49,10 @@ struct omap_uart_state {
> int num;
> int can_sleep;
> struct timer_list timer;
> + struct timer_list garbage_timer;
> + struct work_struct wakeup_work;
> u32 timeout;
> + u8 garbage_ignore;
>
> void __iomem *wk_st;
> void __iomem *wk_en;
> @@ -243,6 +247,11 @@ static inline void omap_uart_save_context(struct
> omap_uart_state *uart) {}
> static inline void omap_uart_restore_context(struct omap_uart_state *uart) {}
> #endif /* CONFIG_PM && CONFIG_ARCH_OMAP3 */
>
> +#ifdef CONFIG_PM
> +static void omap_uart_smart_idle_enable(struct omap_uart_state *uart,
> + int enable);
> +#endif
I moved this up into the #ifdef block just above and added a dummy function
into the #else clause...
> static inline void omap_uart_enable_clocks(struct omap_uart_state *uart)
> {
> if (uart->clocked)
> @@ -252,6 +261,15 @@ static inline void omap_uart_enable_clocks(struct
> omap_uart_state *uart)
> clk_enable(uart->fck);
> uart->clocked = 1;
> omap_uart_restore_context(uart);
> +#ifdef CONFIG_PM
> + omap_uart_smart_idle_enable(uart, 0);
> +#endif
and then dropped this #ifdef.
> + /* Set up garbage timer to ignore RX during first jiffy */
> + if (uart->timeout) {
> + mod_timer(&uart->garbage_timer, jiffies + 1);
> + uart->garbage_ignore = 1;
> + }
> }
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 1/2] OMAP: omap_device: add omap_device_has_lost_context()
Paul Walmsley writes:
> Hi Kevin,
>
> a few questions:
>
> On Wed, 3 Feb 2010, Kevin Hilman wrote:
>
>> Add new function omap_device_has_lost_context() as a simple check
>> to be used after omap_device_enable() to determine if device has
>> lost context (and thus needs context restore.)
>>
>> Motivation: Currently, each driver needs to read the context-loss
>> count before suspend, and again upon resume to determine if
>> device context needs to be restored. Rather than duplicating
>> this process across all drivers, move it into omap_device. After
>> omap_device_enable(), omap_device_has_lost_context() can be called
>> to determine if context was lost.
>>
>> This API is not intended for direct use by drivers. Rather, the
>> OMAP runtime PM core will use this to determine whether or not
>> to call the drivers runtime_resume hook which can then be used to
>> restore context.
>>
>> The goal is to only call drivers "restore" hook when necessary.
>>
>> Signed-off-by: Kevin Hilman
>> ---
>> arch/arm/plat-omap/include/plat/omap_device.h |3 ++
>> arch/arm/plat-omap/omap_device.c | 35
>> +
>> 2 files changed, 38 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/plat-omap/include/plat/omap_device.h
>> b/arch/arm/plat-omap/include/plat/omap_device.h
>> index 76d4917..ff98eb4 100644
>> --- a/arch/arm/plat-omap/include/plat/omap_device.h
>> +++ b/arch/arm/plat-omap/include/plat/omap_device.h
>> @@ -71,6 +71,8 @@ struct omap_device {
>> s8 pm_lat_level;
>> u8 hwmods_cnt;
>> u8 _state;
>> +u32 activate_loss_cnt;
>> +u32 deactivate_loss_cnt;
>
> Would it be sufficient to just note the context loss count on a disable
> and then compare it against the powerdomain's loss count during activate,
> and if different, set a flag in _state ? That way only one loss count
> variable would be needed.
That's possible, but when should that flag be cleared? when
has_lost_context() is called? Maybe before _deactivate() actually
does the deactivate? Thoughts?
>> };
>>
>> /* Device driver interface (call via platform_data fn ptrs) */
>> @@ -78,6 +80,7 @@ struct omap_device {
>> int omap_device_enable(struct platform_device *pdev);
>> int omap_device_idle(struct platform_device *pdev);
>> int omap_device_shutdown(struct platform_device *pdev);
>> +bool omap_device_has_lost_context(struct platform_device *pdev);
>>
>> /* Core code interface */
>>
>> diff --git a/arch/arm/plat-omap/omap_device.c
>> b/arch/arm/plat-omap/omap_device.c
>> index d8c75c8..aaa009d 100644
>> --- a/arch/arm/plat-omap/omap_device.c
>> +++ b/arch/arm/plat-omap/omap_device.c
>> @@ -84,6 +84,7 @@
>>
>> #include
>> #include
>> +#include
>>
>> /* These parameters are passed to _omap_device_{de,}activate() */
>> #define USE_WAKEUP_LAT 0
>> @@ -119,6 +120,7 @@
>> static int _omap_device_activate(struct omap_device *od, u8 ignore_lat)
>> {
>> struct timespec a, b, c;
>> +struct powerdomain *pwrdm;
>>
>> pr_debug("omap_device: %s: activating\n", od->pdev.name);
>>
>> @@ -168,6 +170,10 @@ static int _omap_device_activate(struct omap_device
>> *od, u8 ignore_lat)
>> od->dev_wakeup_lat -= odpl->activate_lat;
>> }
>>
>> +pwrdm = omap_device_get_pwrdm(od);
>> +if (pwrdm)
>> +od->activate_loss_cnt = pwrdm->state_counter[PWRDM_POWER_OFF];
>
> This probably will also depend on the powerdomain's logic_retst,
> mem_retst, mem_onst bits, since context can be lost even when the
> powerdomain is in RET or ON state.
Agreed.
Seems like this type of thing belongs in the powerdomain layer, don't
you think? Maybe, along with the OSWR patches, we can add some more
checking/accounting for whether a domain has gone off (or needs
restore.)
Kevin
>
>> +
>> return 0;
>> }
>>
>> @@ -188,6 +194,7 @@ static int _omap_device_activate(struct omap_device *od,
>> u8 ignore_lat)
>> static int _omap_device_deactivate(struct omap_device *od, u8 ignore_lat)
>> {
>> struct timespec a, b, c;
>> +struct powerdomain *pwrdm;
>>
>> pr_debug("omap_device: %s: deactivating\n", od->pdev.name);
>>
>> @@ -239,6 +246,10 @@ static int _omap_device_deactivate(struct omap_device
>> *od, u8 ignore_lat)
>> od->pm_lat_level++;
>> }
>>
>> +pwrdm = omap_device_get_pwrdm(od);
>> +if (pwrdm)
>> +od->deactivate_loss_cnt = pwrdm->state_counter[PWRDM_POWER_OFF];
>
> Same comment as above.
>
>> +
>> return 0;
>> }
>>
>> @@ -560,6 +571,30 @@ int omap_device_shutdown(struct platform_device *pdev)
>> }
>>
>> /**
>> + * omap_device_has_lost_context() - check if omap_device has lost context
>> + * @od: struct omap_device *
>> + *
>> + * When an omap_device has been deactivated via omap_device_idle() or
>> + *
Re: [PATCH 2/2] OMAP: UART: omap_device converions, remove implicit 8520 assumptions
"Nayak, Rajendra" writes:
[...]
>> + /*
>> + * Need to block sleep long enough for interrupt driven
>> + * driver to start. Console driver is in polling mode
>> + * so device needs to be kept enabled while
>> polling driver
>> + * is in use.
>> + */
>> + uart->timeout = (30 * HZ);
>> + omap_uart_block_sleep(uart);
>> + uart->timeout = DEFAULT_TIMEOUT;
>> +
>> + if ((cpu_is_omap34xx() && uart->padconf) ||
>> + (uart->wk_en && uart->wk_mask)) {
>> + device_init_wakeup(&od->pdev.dev, true);
>> + DEV_CREATE_FILE(&od->pdev.dev,
>> &dev_attr_sleep_timeout);
>> + }
>> +
>> +#ifdef CONFIG_SERIAL_8250_CONSOLE
>> /* omap44xx: Never read empty UART fifo
>>* omap3xxx: Never read empty UART fifo on UARTs
>>* with IP rev >=0x52
>>*/
>> if (cpu_is_omap44xx())
>> - uart->p->serial_in = serial_in_override;
>> - else if ((serial_read_reg(uart->p,
>> UART_OMAP_MVER) & 0xFF)
>> + p->serial_in = serial_in_override;
>> + else if ((serial_read_reg(uart, UART_OMAP_MVER) & 0xFF)
>> >= UART_OMAP_NO_EMPTY_FIFO_READ_IP_REV)
>> - uart->p->serial_in = serial_in_override;
>> + p->serial_in = serial_in_override;
>> +#endif
>
> I think this (overriding serial_in) needs to be done sometime before you do a
> omap_device_build() call. Else this has no affect.
>
Thanks Rajendra, you're right, good catch.
Will fix in next spin.
Thanks ,
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mmc: omap_hsmmc: Fix conditional locking
Conditional locking on (!in_interrupt()) is broken by design and there
is no reason to keep the host->irq_lock across the call to
mmc_request_done(). Also the host->protect_card magic hack does not
depend on the context
Fix the mess by dropping host->irq_lock before calling
mmc_request_done().
Signed-off-by: Thomas Gleixner
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 4b23225..99a3383 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -468,14 +468,6 @@ omap_hsmmc_start_command(struct omap_hsmmc_host *host,
struct mmc_command *cmd,
if (host->use_dma)
cmdreg |= DMA_EN;
- /*
-* In an interrupt context (i.e. STOP command), the spinlock is unlocked
-* by the interrupt handler, otherwise (i.e. for a new request) it is
-* unlocked here.
-*/
- if (!in_interrupt())
- spin_unlock_irqrestore(&host->irq_lock, host->flags);
-
OMAP_HSMMC_WRITE(host->base, ARG, cmd->arg);
OMAP_HSMMC_WRITE(host->base, CMD, cmdreg);
}
@@ -506,7 +498,9 @@ omap_hsmmc_xfer_done(struct omap_hsmmc_host *host, struct
mmc_data *data)
}
host->mrq = NULL;
+ spin_unlock(&host->irq_lock);
mmc_request_done(host->mmc, mrq);
+ spin_lock(&host->irq_lock);
return;
}
@@ -523,7 +517,9 @@ omap_hsmmc_xfer_done(struct omap_hsmmc_host *host, struct
mmc_data *data)
if (!data->stop) {
host->mrq = NULL;
+ spin_unlock(&host->irq_lock);
mmc_request_done(host->mmc, data->mrq);
+ spin_lock(&host->irq_lock);
return;
}
omap_hsmmc_start_command(host, data->stop, NULL);
@@ -551,7 +547,9 @@ omap_hsmmc_cmd_done(struct omap_hsmmc_host *host, struct
mmc_command *cmd)
}
if ((host->data == NULL && !host->response_busy) || cmd->error) {
host->mrq = NULL;
+ spin_unlock(&host->irq_lock);
mmc_request_done(host->mmc, cmd->mrq);
+ spin_lock(&host->irq_lock);
}
}
@@ -1077,37 +1075,31 @@ static void omap_hsmmc_request(struct mmc_host *mmc,
struct mmc_request *req)
struct omap_hsmmc_host *host = mmc_priv(mmc);
int err;
+ spin_lock_irqsave(&host->irq_lock, host->flags);
/*
-* Prevent races with the interrupt handler because of unexpected
-* interrupts, but not if we are already in interrupt context i.e.
-* retries.
+* Protect the card from I/O if there is a possibility
+* it can be removed.
*/
- if (!in_interrupt()) {
- spin_lock_irqsave(&host->irq_lock, host->flags);
- /*
-* Protect the card from I/O if there is a possibility
-* it can be removed.
-*/
- if (host->protect_card) {
- if (host->reqs_blocked < 3) {
- /*
-* Ensure the controller is left in a consistent
-* state by resetting the command and data state
-* machines.
-*/
- omap_hsmmc_reset_controller_fsm(host, SRD);
- omap_hsmmc_reset_controller_fsm(host, SRC);
- host->reqs_blocked += 1;
- }
- req->cmd->error = -EBADF;
- if (req->data)
- req->data->error = -EBADF;
- spin_unlock_irqrestore(&host->irq_lock, host->flags);
- mmc_request_done(mmc, req);
- return;
- } else if (host->reqs_blocked)
- host->reqs_blocked = 0;
- }
+ if (host->protect_card) {
+ if (host->reqs_blocked < 3) {
+ /*
+* Ensure the controller is left in a consistent
+* state by resetting the command and data state
+* machines.
+*/
+ omap_hsmmc_reset_controller_fsm(host, SRD);
+ omap_hsmmc_reset_controller_fsm(host, SRC);
+ host->reqs_blocked += 1;
+ }
+ req->cmd->error = -EBADF;
+ if (req->data)
+ req->data->error = -EBADF;
+ spin_unlock_irqrestore(&host->irq_lock, host->flags);
+ mmc_request_done(mmc, req);
+ return;
+ } else if (host->reqs_blocked)
+ host->reqs_blocked = 0;
+
WARN_ON(host->mrq != NULL);
host->mrq = req;
err = omap_hsmmc_prepare_data(host, req);
@@ -1116,13 +1108,13 @@ static void omap_hsmmc_request(
[RFC part2 v1][PATCH 4/4] omap3: zoom 2/3: Change debugboard serial port id
This is now changed to PLAT8250_DEV_PLATFORM (= 0), because
it is the only port that's going to be initted in Zoom 2/3 boards.
So, it doesn't make sense to keep the hardcoded 3 value anymore.
Signed-off-by: Sergio Aguirre
---
arch/arm/mach-omap2/board-zoom-debugboard.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom-debugboard.c
b/arch/arm/mach-omap2/board-zoom-debugboard.c
index bb4018b..e15d2e8 100644
--- a/arch/arm/mach-omap2/board-zoom-debugboard.c
+++ b/arch/arm/mach-omap2/board-zoom-debugboard.c
@@ -96,7 +96,7 @@ static struct plat_serial8250_port serial_platform_data[] = {
static struct platform_device zoom_debugboard_serial_device = {
.name = "serial8250",
- .id = 3,
+ .id = PLAT8250_DEV_PLATFORM,
.dev= {
.platform_data = serial_platform_data,
},
--
1.6.3.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC part2 v1][PATCH 3/4] omap3: 3630sdp: Explicitly enable all UARTs
All UARTs seem physically reachable, so, enable them all.
Signed-off-by: Sergio Aguirre
---
arch/arm/mach-omap2/board-3630sdp.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
mode change 100755 => 100644 arch/arm/mach-omap2/board-3630sdp.c
diff --git a/arch/arm/mach-omap2/board-3630sdp.c
b/arch/arm/mach-omap2/board-3630sdp.c
old mode 100755
new mode 100644
index 4386d2b..35df894
--- a/arch/arm/mach-omap2/board-3630sdp.c
+++ b/arch/arm/mach-omap2/board-3630sdp.c
@@ -96,6 +96,7 @@ static struct omap_board_mux board_mux[] __initdata = {
static void __init omap_sdp_init(void)
{
omap3_mux_init(board_mux, OMAP_PACKAGE_CBP);
+ omap_serial_init_allports();
zoom_peripherals_init();
board_smc91x_init();
enable_board_wakeup_source();
--
1.6.3.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC part2 v1][PATCH 2/4] omap3: zoom2/3 / 3630sdp: Don't init always all uarts
This is useless, since in Zoom2/3 boards, the ports aren't even
physically accessible.
They must be explicitly initted in the board-zoom2.c, board-zoom3.c
and board-3630sdp.c files instead.
Signed-off-by: Sergio Aguirre
---
arch/arm/mach-omap2/board-zoom-peripherals.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c
b/arch/arm/mach-omap2/board-zoom-peripherals.c
index a1011ee..6b39849 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -280,7 +280,6 @@ static void enable_board_wakeup_source(void)
void __init zoom_peripherals_init(void)
{
omap_i2c_init();
- omap_serial_init_allports();
usb_musb_init(&musb_board_data);
enable_board_wakeup_source();
}
--
1.6.3.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC part2 v1][PATCH 1/4] omap2/3/4: serial: rename omap_serial_init
The name itself doesn't make clear that all UARTs of the platform
are going to be initted. This is just to give more awareness of the
real action being done here.
Signed-off-by: Sergio Aguirre
---
arch/arm/mach-omap2/board-2430sdp.c |2 +-
arch/arm/mach-omap2/board-3430sdp.c |2 +-
arch/arm/mach-omap2/board-4430sdp.c |2 +-
arch/arm/mach-omap2/board-am3517evm.c|2 +-
arch/arm/mach-omap2/board-apollon.c |2 +-
arch/arm/mach-omap2/board-cm-t35.c |2 +-
arch/arm/mach-omap2/board-devkit8000.c |2 +-
arch/arm/mach-omap2/board-generic.c |2 +-
arch/arm/mach-omap2/board-h4.c |2 +-
arch/arm/mach-omap2/board-igep0020.c |2 +-
arch/arm/mach-omap2/board-ldp.c |2 +-
arch/arm/mach-omap2/board-n8x0.c |2 +-
arch/arm/mach-omap2/board-omap3beagle.c |2 +-
arch/arm/mach-omap2/board-omap3evm.c |2 +-
arch/arm/mach-omap2/board-omap3pandora.c |2 +-
arch/arm/mach-omap2/board-omap3touchbook.c |2 +-
arch/arm/mach-omap2/board-overo.c|2 +-
arch/arm/mach-omap2/board-rx51.c |2 +-
arch/arm/mach-omap2/board-zoom-peripherals.c |2 +-
arch/arm/mach-omap2/serial.c |8
arch/arm/plat-omap/include/plat/serial.h |2 +-
21 files changed, 24 insertions(+), 24 deletions(-)
mode change 100755 => 100644 arch/arm/mach-omap2/board-zoom-peripherals.c
diff --git a/arch/arm/mach-omap2/board-2430sdp.c
b/arch/arm/mach-omap2/board-2430sdp.c
index 01d113f..abc55bc 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -206,7 +206,7 @@ static void __init omap_2430sdp_init(void)
omap2430_i2c_init();
platform_add_devices(sdp2430_devices, ARRAY_SIZE(sdp2430_devices));
- omap_serial_init();
+ omap_serial_init_allports();
omap2_hsmmc_init(mmc);
usb_musb_init(&musb_board_data);
board_smc91x_init();
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index f312b15..8c84973 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -799,7 +799,7 @@ static void __init omap_3430sdp_init(void)
spi_register_board_info(sdp3430_spi_board_info,
ARRAY_SIZE(sdp3430_spi_board_info));
ads7846_dev_init();
- omap_serial_init();
+ omap_serial_init_allports();
usb_musb_init(&musb_board_data);
board_smc91x_init();
sdp_flash_init(sdp_flash_partitions);
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 029c6c9..1d47064 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -84,7 +84,7 @@ static struct omap_musb_board_data musb_board_data = {
static void __init omap_4430sdp_init(void)
{
platform_add_devices(sdp4430_devices, ARRAY_SIZE(sdp4430_devices));
- omap_serial_init();
+ omap_serial_init_allports();
/* OMAP4 SDP uses internal transceiver so register nop transceiver */
usb_nop_xceiv_register();
/* FIXME: allow multi-omap to boot until musb is updated for omap4 */
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index e6b8967..d88b31f 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -300,7 +300,7 @@ static void __init am3517_evm_init(void)
platform_add_devices(am3517_evm_devices,
ARRAY_SIZE(am3517_evm_devices));
- omap_serial_init();
+ omap_serial_init_allports();
usb_ehci_init(&ehci_pdata);
/* DSS */
am3517_evm_display_init();
diff --git a/arch/arm/mach-omap2/board-apollon.c
b/arch/arm/mach-omap2/board-apollon.c
index aa69fb9..6c14392 100644
--- a/arch/arm/mach-omap2/board-apollon.c
+++ b/arch/arm/mach-omap2/board-apollon.c
@@ -331,7 +331,7 @@ static void __init omap_apollon_init(void)
* if not needed.
*/
platform_add_devices(apollon_devices, ARRAY_SIZE(apollon_devices));
- omap_serial_init();
+ omap_serial_init_allports();
}
static void __init omap_apollon_map_io(void)
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index afa77ca..e148835 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -820,7 +820,7 @@ static struct omap_musb_board_data musb_board_data = {
static void __init cm_t35_init(void)
{
omap3_mux_init(board_mux, OMAP_PACKAGE_CUS);
- omap_serial_init();
+ omap_serial_init_allports();
cm_t35_init_i2c();
cm_t35_init_nand();
cm_t35_init_ads7846();
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 3710190..fcc790f 100644
--- a/arch/arm/mach-o
[RFC part2 v1][PATCH 0/4] omap2/3/4: Some more serial work
Hi, This is some proposed cleanups I have been keeping in mind for serial initialization. I'm basically proposing: - Rename "omap_serial_init" -> "omap_serial_init_allports" to give more clarity to the function purpose. - Don't enable internal UARTs for Zoom2/3, since they aren't even physically reachable. As an end result, Zoom2/3 Default uart will be ttyS0. As a side change, I'm doing a chmod to "644" of some "755" files. IMPORTANT: This changes are meant to be applied on top of [1] and [2] Please let me know your comments and thoughts. Regards, Sergio Detailed changelog: Sergio Aguirre (4): omap2/3/4: serial: rename omap_serial_init omap3: zoom2/3 / 3630sdp: Don't init always all uarts omap3: 3630sdp: Explicitly enable all UARTs omap3: zoom 2/3: Change debugboard serial port id arch/arm/mach-omap2/board-2430sdp.c |2 +- arch/arm/mach-omap2/board-3430sdp.c |2 +- arch/arm/mach-omap2/board-3630sdp.c |1 + arch/arm/mach-omap2/board-4430sdp.c |2 +- arch/arm/mach-omap2/board-am3517evm.c|2 +- arch/arm/mach-omap2/board-apollon.c |2 +- arch/arm/mach-omap2/board-cm-t35.c |2 +- arch/arm/mach-omap2/board-devkit8000.c |2 +- arch/arm/mach-omap2/board-generic.c |2 +- arch/arm/mach-omap2/board-h4.c |2 +- arch/arm/mach-omap2/board-igep0020.c |2 +- arch/arm/mach-omap2/board-ldp.c |2 +- arch/arm/mach-omap2/board-n8x0.c |2 +- arch/arm/mach-omap2/board-omap3beagle.c |2 +- arch/arm/mach-omap2/board-omap3evm.c |2 +- arch/arm/mach-omap2/board-omap3pandora.c |2 +- arch/arm/mach-omap2/board-omap3touchbook.c |2 +- arch/arm/mach-omap2/board-overo.c|2 +- arch/arm/mach-omap2/board-rx51.c |2 +- arch/arm/mach-omap2/board-zoom-debugboard.c |2 +- arch/arm/mach-omap2/board-zoom-peripherals.c |1 - arch/arm/mach-omap2/serial.c |8 arch/arm/plat-omap/include/plat/serial.h |2 +- 23 files changed, 25 insertions(+), 25 deletions(-) mode change 100755 => 100644 arch/arm/mach-omap2/board-3630sdp.c mode change 100755 => 100644 arch/arm/mach-omap2/board-zoom-peripherals.c [1] http://marc.info/?l=linux-omap&m=126730356232287&w=2 [2] http://marc.info/?l=linux-kernel&m=126709078514087&w=2 -- 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] serial: Add OMAP high-speed UART driver.
* Govindraj.R [100301 06:40]:
> --- /dev/null
> +++ b/drivers/serial/omap-serial.c
> +
> +static void serial_omap_stop_tx(struct uart_port *port)
> +{
> + struct uart_omap_port *up = (struct uart_omap_port *)port;
> +
> + if (up->use_dma &&
> + up->uart_dma.tx_dma_channel != OMAP_UART_DMA_CH_FREE) {
> + /*
> + * Check if dma is still active . If yes do nothing,
Looks like an extra space here before the period above.
...
> +static int serial_omap_start_rxdma(struct uart_omap_port *up)
> +{
> + int ret = 0;
> +
> + if (up->uart_dma.rx_dma_channel == -1) {
> + ret = omap_request_dma(up->uart_dma.uart_dma_rx,
> + "UART Rx DMA",
> + (void *)uart_rx_dma_callback, up,
> + &(up->uart_dma.rx_dma_channel));
> + if (ret < 0)
> + return ret;
> +
> + omap_set_dma_src_params(up->uart_dma.rx_dma_channel, 0,
> + OMAP_DMA_AMODE_CONSTANT,
> + up->uart_dma.uart_base, 0, 0);
> + omap_set_dma_dest_params(up->uart_dma.rx_dma_channel, 0,
> + OMAP_DMA_AMODE_POST_INC,
> + up->uart_dma.rx_buf_dma_phys, 0, 0);
> + omap_set_dma_transfer_params(up->uart_dma.rx_dma_channel,
> + OMAP_DMA_DATA_TYPE_S8,
> + up->uart_dma.rx_buf_size, 1,
> + OMAP_DMA_SYNC_ELEMENT,
> + up->uart_dma.uart_dma_rx, 0);
> + }
> + up->uart_dma.prev_rx_dma_pos = up->uart_dma.rx_buf_dma_phys;
> + if (cpu_is_omap44xx())
> + omap_writel(0, OMAP44XX_DMA4_BASE
> + + OMAP_DMA4_CDAC(up->uart_dma.rx_dma_channel));
> + else
> + omap_writel(0, OMAP34XX_DMA4_BASE
> + + OMAP_DMA4_CDAC(up->uart_dma.rx_dma_channel));
NAK. Please don't use omap_read/write for for new code. And do not
tinker with the omap hardware registers directly in the driver.
This needs to be done properly in arch/arm/plat-omap/dma.c instead.
We really don't want drivers tinkering with the omap hardware
registers directly except for the driver block registers.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] serial: Add OMAP high-speed UART driver.
> + 213 = /dev/ttyO0 OMAP serial port 0 > + 214 = /dev/ttyO1 OMAP serial port 1 > + 215 = /dev/ttyO2 OMAP serial port 2 > + 216 = /dev/ttyO3 OMAP serial port 3 I think it might be best to allocate a dynamic tty major nowdays Other problem is that I don't see where you hold the port lock over all uses of port->tty. That is an assumption of the serial layer and done in the original 8250 driver correctly. Rest looks good and I agree that OMAP is different enough from 8250 that it makes sense not to further clutter the 8250 driver. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.33-rc8-rt1 on Beagle
On Mon, 1 Mar 2010, Uwe Kleine-König wrote: > You might want to report that to the author(s) of > drivers/mmc/host/omap_hsmmc.c. FYI, thats fixed in 33-rt3 and the fix is going mainline as well. Thanks, tglx
Re: [PATCH 2/4] USB: MUSB: Enable MUSB for OMAP4 in Kconfig
On Mon, Mar 01, 2010 at 11:11:29AM +0530, Maulik wrote: > > Olof, > > > > We have such an option "USB_MUSB_SOC" that takes care of all platforms > where > > MUSB is present. But the Inventra DMA case is typical. Not all > architectures > > that have MUSB use Inventra DMA for e.g Davinci uses CPPI DMA. > > >>Yeah, sorry. I didn't mean the INVENTRA_DMA config option as much as the > >>top > >>MUSB one. So you should be able to switch to that instead of adding a > >>check for > >>OMAP4 there then? > > Olof, > So you suggest adding something like below for OMAP4 and all others as well > right? > > comment "OMAP 44xx high speed USB support" > depends on USB_MUSB_HDRC && USB_MUSB_SOC Hmm. I must be missing something, but it looks odd to have both the USB_MUSB_HDRC and USB_MUSB_SOC high-level config options, especially since the depends are duplicated across them. In general, options like these tend to scale badly: config USB_MUSB_SOC boolean depends on USB_MUSB_HDRC default y if ARCH_DAVINCI default y if ARCH_OMAP2430 default y if ARCH_OMAP34XX default y if (BF54x && !BF544) default y if (BF52x && !BF522 && !BF523) I.e. every single platform needs to add a new line. It's better to have a config option that is selected from the platform code (arch/arm/mach-omap2/Kconfig for the specific SOC in this case), that for example does a : config ARCH_OMAP34XX bool "OMAP34xx Based System" depends on ARCH_OMAP3 select USB_ARCH_HAS_EHCI select USB_ARCH_HAS_MUSB and then just do the USB_MUSB_HDRC or USB_MUSB_SOC config option based on: config USB_MUSB_SOC boolena depends on USB_ARCH_HAS_MUSB default y That way a new platform doesn't need to change the common files. I also don't see the direct need to provide a specific comment saying "44xx high speed USB support" when you configure for 44xx. With the work Tony is doing you can build one kernel that boots across OMAP2/3/4, which comment should then be displayed? It's better to just do a generic comment such as "OMAP on-chip OTG USB support" The DMA config is also a bit confusing. I scratched my head over that one a few times, the fact that one is described with OMAP in the name, and the other one (INVENTRA) is the one actually used on newer OMAP platforms. -Olof -- 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: 2.6.33-rc8-rt1 on Beagle
Hello,
On Thu, Feb 25, 2010 at 04:36:23PM +0530, Chatterjee, Amit wrote:
> Migrated to 2.6.33-rc8-rt2 but still am facing the same issue.
>
> Regards,
> Amit
>
> -Original Message-
> From: linux-rt-users-ow...@vger.kernel.org
> [mailto:linux-rt-users-ow...@vger.kernel.org] On Behalf Of Chatterjee, Amit
> Sent: Wednesday, February 24, 2010 5:50 PM
> To: LKML; rt-users
> Subject: 2.6.33-rc8-rt1 on Beagle
>
> Hi,
> I am facing NULL pointer deference error with beagle board. The
> bootargs used are -
>
> setenv bootargs 'console=ttyS2,115200n8 root=/dev/mmcblk0p2 rootwait
> rootfstype=ext3 omapfb.mode=dvi:800x600mr...@60 omapdss.def_disp=dvi
> omapfb.vram=0:8M,1:2M,2:4M mem=216M'
> setenv bootcmd 'mmc init;fatload mmc 0 0x8020 uImage;bootm 0x8020'
>
> The crash log is as follows -
>
> Waiting for root device /dev/mmcblk0p2...
> Unable to handle kernel NULL pointer dereference at virtual address
> pgd = c0004000
> [] *pgd=
> Internal error: Oops: 805 [#1] PREEMPT
> last sysfs file:
> Modules linked in:
> CPU: 0Not tainted (2.6.33-rc8-rt1 #3)
> PC is at rt_spin_lock_slowlock+0x64/0x220
This corresponds to:
BUG_ON(rt_mutex_owner(lock) == current);
in rt_spin_lock_slowlock. If you had CONFIG_BUG_VERBOSE this would have
been more obvious.
> LR is at rt_spin_lock_slowlock+0x24/0x220
> pc : []lr : []psr: 6093
> sp : cd1a1ed8 ip : cd1a1f08 fp : 0053
> r10: cd3bc664 r9 : c039c8c4 r8 : cd3bc400
> r7 : cd1a r6 : cd3bc664 r5 : 6013 r4 : cd3bc664
> r3 : r2 : cd3fb480 r1 : r0 : cd1a1ed8
> Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
> Control: 10c5387d Table: 80004019 DAC: 0017
> Process irq/83-mmc0 (pid: 355, stack limit = 0xcd1a02e8)
> Stack: (0xcd1a1ed8 to 0xcd1a2000)
> 1ec0: 0001 0006
> 1ee0: cd070040 c0397f48 0001 cd3fb480 0002 cd3bc664 6013
> 1f00: cd1a c029f9f0 cd3bc600 cd0c3ef4 cd3bc664
> 1f20: cd3bc400 cd3bc664 c0213850 cd0c2000 cd0c201c cd3fb480 0017
> 1f40: cd3bc600 00018000 0001 cd3bc664 c020bb94
> 1f60: cd0c3f24 c02145fc c039c880 cd3d07c0 cd1a cd3d07e4 0800 c039c8c4
> 1f80: c039c8dc c00768e8 cd3d07c0 0032 cd1a1f88 cd021e58 cd1a1fbc c0076828
> 1fa0: cd3d07c0 c0060ae8
> 1fc0: cd1a1fc0 cd1a1fc0 cd1a1fc8 cd1a1fc8 cd1a1fd8 cd1a1fd8
> 1fe0: c0028ec4 107fcd00 0a33ef94
> [] (rt_spin_lock_slowlock+0x64/0x220) from []
> (omap_hsmmc_request+0x44/0x400)
> [] (omap_hsmmc_request+0x44/0x400) from []
> (mmc_request_done+0x64/0x90)
> [] (mmc_request_done+0x64/0x90) from []
> (omap_hsmmc_irq+0x364/0x46c)
> [] (omap_hsmmc_irq+0x364/0x46c) from []
> (irq_thread+0xc0/0x208)
> [] (irq_thread+0xc0/0x208) from [] (kthread+0x78/0x80)
> [] (kthread+0x78/0x80) from []
> (kernel_thread_exit+0x0/0x8)
> Code: e597300c e1520003 1a02 e3a03000 (e5833000)
I assume the problem is that the function omap_hsmmc_request tries to be
clever in a non-rt compatible way:
/*
* Prevent races with the interrupt handler because of unexpected
* interrupts, but not if we are already in interrupt context i.e.
* retries.
*/
if (!in_interrupt()) {
spin_lock_irqsave(&host->irq_lock, host->flags);
But looking at the backtrace in this context in_interrupt() would be
true in !PREEMPT_RT.
You might want to report that to the author(s) of
drivers/mmc/host/omap_hsmmc.c.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
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] serial: Add OMAP high-speed UART driver.
This patch adds driver support for OMAP3/4 high speed UART.
This driver is made separate from 8250 driver as we cannot
over load 8250 driver with omap platform specific configuration for
features like DMA, it makes easier to implement features like DMA and
hardware flow control and software flow control configuration with
this driver as required for the omap-platform.
This patch involves only the core driver and its dependent.
This patch doesn't incorporate platform specific data as this will be
posted from linux-omap tree and this driver was tested with Kevin's PM
branch which currently hosts the omap-serial platform data which utilises
the omap-hwmod framework.
Cc: Tony Lindgren
Cc: Olof Johansson
Tested-by: Kevin Hilman
Signed-off-by: Govindraj R
---
Documentation/devices.txt |4 +
arch/arm/plat-omap/include/plat/omap-serial.h | 135 +++
drivers/serial/Kconfig| 27 +
drivers/serial/Makefile |1 +
drivers/serial/omap-serial.c | 1319 +
include/linux/serial_core.h |3 +
6 files changed, 1489 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-omap/include/plat/omap-serial.h
create mode 100644 drivers/serial/omap-serial.c
diff --git a/Documentation/devices.txt b/Documentation/devices.txt
index 53d64d3..cf7d481 100644
--- a/Documentation/devices.txt
+++ b/Documentation/devices.txt
@@ -2801,6 +2801,10 @@ Your cooperation is appreciated.
210 = /dev/ttyMAX1 MAX3100 serial port 1
211 = /dev/ttyMAX2 MAX3100 serial port 2
212 = /dev/ttyMAX3 MAX3100 serial port 3
+213 = /dev/ttyO0 OMAP serial port 0
+214 = /dev/ttyO1 OMAP serial port 1
+215 = /dev/ttyO2 OMAP serial port 2
+216 = /dev/ttyO3 OMAP serial port 3
205 char Low-density serial ports (alternate device)
0 = /dev/culu0Callout device for ttyLU0
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
b/arch/arm/plat-omap/include/plat/omap-serial.h
new file mode 100644
index 000..ff46b44
--- /dev/null
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -0,0 +1,135 @@
+/*
+ * Driver for OMAP-UART controller.
+ * Based on drivers/serial/8250.c
+ *
+ * Copyright (C) 2010 Texas Instruments.
+ *
+ * Authors:
+ * Govindraj R
+ * Thara Gopinath
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#ifndef __OMAP_SERIAL_H__
+#define __OMAP_SERIAL_H__
+
+#include
+#include
+
+#include
+#include
+
+#define DRIVER_NAME"omap-hsuart"
+
+/*
+ * Use tty device name as ttyO, [O -> OMAP]
+ * in bootargs we specify as console=ttyO0 if uart1
+ * is used as console uart.
+ * Use Major 204 and minor 213.
+ * This is necessary in order to coexist with the 8250 driver,
+ * if we have an external TI-16C750 UART. Ex.ZOOM2/3 Boards.
+ */
+
+#define OMAP_SERIAL_NAME "ttyO"
+#define OMAP_SERIAL_MAJOR 204
+#define OMAP_SERIAL_MINOR 213
+
+#define OMAP_MDR1_DISABLE 0x07
+#define OMAP_MDR1_MODE13X 0x03
+#define OMAP_MDR1_MODE16X 0x00
+#define OMAP_MODE13X_SPEED 230400
+
+/*
+ * LCR = 0XBF: Switch to Configuration Mode B.
+ * In configuration mode b allow access
+ * to EFR,DLL,DLH.
+ * Reference OMAP TRM Chapter 17
+ * Section: 1.4.3 Mode Selection
+ */
+#define OMAP_UART_LCR_CONF_MDB 0XBF
+
+/* WER = 0x7F
+ * Enable module level wakeup in WER reg
+ */
+#define OMAP_UART_WER_MOD_WKUP 0X7F
+
+/* Enable XON/XOFF flow control on output */
+#define OMAP_UART_SW_TX0x04
+
+/* Enable XON/XOFF flow control on input */
+#define OMAP_UART_SW_RX0x04
+
+#define OMAP_UART_SYSC_RESET 0X07
+#define OMAP_UART_TCR_TRIG 0X0F
+#define OMAP_UART_SW_CLR 0XF0
+
+#define OMAP_UART_DMA_CH_FREE -1
+
+#define RX_TIMEOUT (3 * HZ)
+#define OMAP_MAX_HSUART_PORTS 4
+
+#define MSR_SAVE_FLAGS UART_MSR_ANY_DELTA
+
+struct omap_uart_port_info {
+ booldma_enabled;/* To specify DMA Mode */
+ unsigned intuartclk;/* UART clock rate */
+ void __iomem*membase; /* ioremap cookie or NULL */
+ resource_size_t mapbase;/* resource base */
+ unsigned long irqflags; /* request_irq flags */
+ upf_t flags; /* UPF_* flags */
+};
+
+struct uart_omap_dma {
+ u8 uart_dma_tx;
+ u8 uart_dma_rx;
+ int rx_dma_channel;
+ int tx_dma_channel;
+
Re: [PATCH 01/03] omap hsmmc: prevent race between dma and hsmmc callback
Hello.
Venkatraman S wrote:
It is observed that sometimes the MMC Transfer Complete (TC) is not
received when DMA completion callback is processed (or takes too long
to process)
This patch moves the releasing of DMA channel from dma callback to the
mmc transfer complete handler.
This is observed consistently when descriptor loading is used (see the
rest of the series)
Signed-off-by: Venkatraman S
---
drivers/mmc/host/omap_hsmmc.c | 19 +++
1 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 83f0aff..06337f6 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1046,8 +1046,18 @@ static irqreturn_t omap_hsmmc_irq(int irq, void *dev_id)
if (end_cmd || ((status & CC) && host->cmd))
omap_hsmmc_cmd_done(host, host->cmd);
- if ((end_trans || (status & TC)) && host->mrq)
+ if ((end_trans || (status & TC)) && host->mrq) {
omap_hsmmc_xfer_done(host, data);
+ if (host->dma_ch != -1) {
+ omap_free_dma(host->dma_ch);
+ host->dma_ch = -1;
+ /*
+* Callback: run in interrupt context.
+* mutex_unlock will throw a kernel warning if used.
+*/
The comment should be aligned with the rest of the code.
+ up(&host->sem);
+ }
+ }
spin_unlock(&host->irq_lock);
WBR, Sergei
--
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] [PATCHv4 7/7] ASoC: TWL6030: Detect power-up sequence completion
On Fri, Feb 26, 2010 at 06:22:34PM -0600, Olaya, Margarita wrote:
> Do you mean something like this?
> time_left = wait_for_completion_timeout(&priv->ready,
> msecs_to_jiffies(48));
> if(!time_left) {
> twl_i2c_read_u8(TWL4030_MODULE_AUDIO_VOICE, &intid,
> TWL6040_REG_INTID);
> if (!(intid & TWL6040_READYINT))
> goto error;
> }
>
> return 0;
>
> error:
> dev_err(codec->dev, "timeout waiting for READYINT\n");
> return -ETIMEDOUT;
Yes, or wrapped in a for loop with shorter timeouts on the individual
waits.
> but in this case will it not take unnecessarily 48ms when the
> interruption line is not valid?
You're always going to get some additional delay when polling unless you
busy wait for completion, which obviously has its own problems.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/03] omap hsmmc: adaptation of sdma descriptor autoloading feature
Start to use the sDMA descriptor autoloading feature.
For large datablocks, the MMC driver has to repeatedly setup, program
and teardown the
dma channel for each element of the sglist received in omap_hsmmc_request.
By using descriptor autoloading, transfers from / to each element of
the sglist is pre programmed
into a linked list. The sDMA driver completes the entire transaction
and provides a single interrupt.
Due to this, number of dma interrupts for a typical 100MB transfer on the MMC is
reduced from 25000 to about 400 (approximate). Transfer speeds are
improved by ~5%
(Though it varies on the size of read / write & improves on huge transfers)
Descriptor autoloading is available only in 3630 and 4430 (as of now).
Hence normal DMA
mode is also retained.
Tested on omap4430 sdp.
Signed-off-by: Venkatraman S
---
drivers/mmc/host/omap_hsmmc.c | 143 +++--
1 files changed, 122 insertions(+), 21 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 06337f6..425129b 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -102,6 +102,7 @@
#define SRD(1 << 26)
#define SOFTRESET (1 << 1)
#define RESETDONE (1 << 0)
+#define DMA_ICR_QUIET 0xD00
/*
* FIXME: Most likely all the data using these _DEVID defines should come
@@ -118,6 +119,12 @@
#define OMAP_MMC_MASTER_CLOCK 9600
#define DRIVER_NAME"mmci-omap-hs"
+#define DMA_TYPE_NODMA 0
+#define DMA_TYPE_SDMA 1
+#define DMA_TYPE_SDMA_DLOAD 2
+
+#define DMA_CTRL_BUF_SIZE (PAGE_SIZE * 3)
+
/* Timeouts for entering power saving states on inactivity, msec */
#define OMAP_MMC_DISABLED_TIMEOUT 100
#define OMAP_MMC_SLEEP_TIMEOUT 1000
@@ -172,7 +179,11 @@ struct omap_hsmmc_host {
u32 bytesleft;
int suspended;
int irq;
- int use_dma, dma_ch;
+ int dma_caps;
+ int dma_in_use;
+ int dma_ch;
+ void*dma_ctrl_buf;
+ dma_addr_t dma_ctrl_buf_phy;
int dma_line_tx, dma_line_rx;
int slot_id;
int got_dbclk;
@@ -768,7 +779,7 @@ omap_hsmmc_start_command(struct omap_hsmmc_host
*host, struct mmc_command *cmd,
OMAP_HSMMC_WRITE(host->base, STAT, STAT_CLEAR);
OMAP_HSMMC_WRITE(host->base, ISE, INT_EN_MASK);
- if (host->use_dma)
+ if (host->dma_in_use)
OMAP_HSMMC_WRITE(host->base, IE,
INT_EN_MASK & ~(BRR_ENABLE | BWR_ENABLE));
else
@@ -803,7 +814,7 @@ omap_hsmmc_start_command(struct omap_hsmmc_host
*host, struct mmc_command *cmd,
cmdreg &= ~(DDIR);
}
- if (host->use_dma)
+ if (host->dma_in_use)
cmdreg |= DMA_EN;
/*
@@ -850,7 +861,7 @@ omap_hsmmc_xfer_done(struct omap_hsmmc_host *host,
struct mmc_data *data)
host->data = NULL;
- if (host->use_dma && host->dma_ch != -1)
+ if (host->dma_in_use && host->dma_ch != -1)
dma_unmap_sg(mmc_dev(host->mmc), data->sg, host->dma_len,
omap_hsmmc_get_dma_dir(host, data));
@@ -900,7 +911,7 @@ static void omap_hsmmc_dma_cleanup(struct
omap_hsmmc_host *host, int errno)
{
host->data->error = errno;
- if (host->use_dma && host->dma_ch != -1) {
+ if (host->dma_in_use && host->dma_ch != -1) {
dma_unmap_sg(mmc_dev(host->mmc), host->data->sg, host->dma_len,
omap_hsmmc_get_dma_dir(host, host->data));
omap_free_dma(host->dma_ch);
@@ -1253,7 +1264,6 @@ static void omap_hsmmc_config_dma_params(struct
omap_hsmmc_host *host,
omap_hsmmc_get_dma_sync_dev(host, data),
!(data->flags & MMC_DATA_WRITE));
- omap_start_dma(dma_ch);
}
/*
@@ -1268,21 +1278,32 @@ static void omap_hsmmc_dma_cb(int lch, u16
ch_status, void *data)
if (host->dma_ch < 0)
return;
-
- host->dma_sg_idx++;
- if (host->dma_sg_idx < host->dma_len) {
- /* Fire up the next transfer. */
- omap_hsmmc_config_dma_params(host, host->data,
+ if (host->dma_in_use == DMA_TYPE_SDMA) {
+ host->dma_sg_idx++;
+ if (host->dma_sg_idx < host->dma_len) {
+ /* Fire up the next transfer. */
+ omap_hsmmc_config_dma_params(host, host->data,
host->data->sg + host->dma_sg_idx);
- return;
+ omap_start_dma(host->dma_ch);
+ return;
+ }
}
}
+static int omap_hsmmc_start_dma_transfer(struct omap_hsmmc_host *host)
+{
+ if
[PATCH 02/03] sDMA driver: descriptor autoloading feature [v5]
This patch introduces the sDMA driver API for descriptor autoloading feature
(available in OMAP3630 and OMAP4430)
v1 http://marc.info/?l=linux-omap&m=125012097403050&w=2
v2 http://marc.info/?l=linux-omap&m=125137152606644&w=2
v3 http://patchwork.kernel.org/patch/45408/
v4 http://patchwork.kernel.org/patch/66690/
The feature works as described below
1) A sDMA channel is programmed to be in 'linked list' mode
2) The client (sDMA user) provides a list of descriptors in a linked list format
3) Each of the 'descriptor' (element in the linked list) contains an
updated set of
DMA configuration register values
4) Client starts DMA transfer
5) sDMA controller loads the first element to its register
configuration memory and
executes the transfer 6) After completion, loads the next element (in
linked list) to
configuration memory and executes the transfer, without MCU intervention. 7)
Interrupt is generated after all transfers are completed; this can be
configured to
be done differently.
Configurations and additional features
1) Fast mode & non-fast mode
Fast mode/non-fast decides on how the first transfer begins. In
non-fast mode,
the first element in the linked list is loaded only after completing
the transfer
according to the configurations already in the sDMA channel registers.
In fast mode,
the loading of the first element precedes the transfer.
2) Pause / resume of transfers
A transfer can be paused after a descriptor set has been
loaded, provided the
'pause bit' is set in the linked list element. An ongoing transfer
cannot be paused.
If the 'pause bit' is set, transfer is not started after loading the
register set
from memory. Such a transfer can be resumed later.
3) Descriptor types
3 possible configurations of descriptors (initialized as linked
list elements)
are possible. Type 1 provides the maximum flexibility, which contains
most register
definitions of a DMA logical channel. Fewer options are present in
type 2. Type 3 can
just modify source/destinations address of transfers. In all
transfers, unmodified
registers settings are maintained for the next transfer.
Patch provides options / API for
1) Setting up a descriptor loading for DMA channel for sg type transfers
2) configuration with linked list elements
3) Starting / pause and resume of the said transfers, query state
4) Closing/Releasing the DMA channel
Changes since version 4:
1) Removed the binding of linked list mode to omap_request_dma. Now
client driver
can request a 'normal' dma channel and then switch it to linked list
mode. Conversely, dma channel
can be cleared of linked list mode and used in normal mode, without releasing.
2) client driver is now responsible for allocation/free of memory for
descriptors.
This provides for flexibility of configuration and reuse /repeated
use of descriptors for multiple transfers if needed.
The memory should be "coherent alloc"ed.
Signed-off-by: Venkatraman S
---
arch/arm/plat-omap/dma.c | 269 -
arch/arm/plat-omap/include/plat/dma.h | 170 +
2 files changed, 438 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 2ab224c..6c92c34 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -46,12 +46,40 @@ enum { DMA_CH_ALLOC_DONE, DMA_CH_PARAMS_SET_DONE,
DMA_CH_STARTED,
enum { DMA_CHAIN_STARTED, DMA_CHAIN_NOTSTARTED };
#endif
+/* CDP Register bitmaps */
+#define DMA_LIST_CDP_DST_VALID (BIT(0))
+#define DMA_LIST_CDP_SRC_VALID (BIT(2))
+#define DMA_LIST_CDP_TYPE1 (BIT(4))
+#define DMA_LIST_CDP_TYPE2 (BIT(5))
+#define DMA_LIST_CDP_TYPE3 (BIT(4) | BIT(5))
+#define DMA_LIST_CDP_PAUSEMODE (BIT(7))
+#define DMA_LIST_CDP_LISTMODE (BIT(8))
+#define DMA_LIST_CDP_FASTMODE (BIT(10))
+/* CAPS register bitmaps */
+#define DMA_CAPS_SGLIST_SUPPORT(BIT(20))
+
+#define DMA_LIST_DESC_PAUSE(BIT(0))
+#define DMA_LIST_DESC_SRC_VALID(BIT(24))
+#define DMA_LIST_DESC_DST_VALID(BIT(26))
+#define DMA_LIST_DESC_BLK_END (BIT(28))
+
#define OMAP_DMA_ACTIVE0x01
#define OMAP2_DMA_CSR_CLEAR_MASK 0xffe
#define OMAP_FUNC_MUX_ARM_BASE (0xfffe1000 + 0xec)
+#define OMAP_DMA_INVALID_FRAME_COUNT (0x)
+#define OMAP_DMA_INVALID_ELEM_COUNT(0xff)
+#define OMAP_DMA_INVALID_DESCRIPTOR_POINTER(0xfffc)
static int enable_1510_mode;
+static int dma_caps0_status;
+
+struct omap_dma_list_config_params {
+ unsigned int num_elem;
+ struct omap_dma_sglist_node *sghead;
+ dma_addr_t sgheadphy;
+ unsigned int pausenode;
+};
static struct omap_dma_global_context_registers {
u32 dma_irqenable_l0;
@@ -76,7 +104,11 @@ struct omap_dma_lch {
int chain_id;
int status;
+
+ /* Required for descriptor loading */
+ struct omap_dma_list_config_params list_config;
#endif
+
long flags;
};
@@ -214,6 +246,76 @@ static void clear_
[PATCH 01/03] omap hsmmc: prevent race between dma and hsmmc callback
It is observed that sometimes the MMC Transfer Complete (TC) is not
received when DMA completion callback is processed (or takes too long
to process)
This patch moves the releasing of DMA channel from dma callback to the
mmc transfer complete handler.
This is observed consistently when descriptor loading is used (see the
rest of the series)
Signed-off-by: Venkatraman S
---
drivers/mmc/host/omap_hsmmc.c | 19 +++
1 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 83f0aff..06337f6 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1046,8 +1046,18 @@ static irqreturn_t omap_hsmmc_irq(int irq, void *dev_id)
if (end_cmd || ((status & CC) && host->cmd))
omap_hsmmc_cmd_done(host, host->cmd);
- if ((end_trans || (status & TC)) && host->mrq)
+ if ((end_trans || (status & TC)) && host->mrq) {
omap_hsmmc_xfer_done(host, data);
+ if (host->dma_ch != -1) {
+ omap_free_dma(host->dma_ch);
+ host->dma_ch = -1;
+ /*
+* Callback: run in interrupt context.
+* mutex_unlock will throw a kernel warning if used.
+*/
+ up(&host->sem);
+ }
+ }
spin_unlock(&host->irq_lock);
@@ -1267,13 +1277,6 @@ static void omap_hsmmc_dma_cb(int lch, u16
ch_status, void *data)
return;
}
- omap_free_dma(host->dma_ch);
- host->dma_ch = -1;
- /*
-* DMA Callback: run in interrupt context.
-* mutex_unlock will throw a kernel warning if used.
-*/
- up(&host->sem);
}
/*
--
1.6.3.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/03] sDMA driver descriptor autoloading feature [version 5] and omap hsmmc driver adaptations
This patch series is introduction of new sDMA feature: descriptor autoloading (v5) and its adoption by omap hsmmc driver. Previous thread (v4 of sDMA patch, without hsmmc adoptions) is here: http://patchwork.kernel.org/patch/66690/ Current version(s) based on for-next branch, 7b97f3ed. Tested on omap4430 sdp. Venkatraman S (3): MMC: prevent race between dma and hsmmc callback sDMA: descriptor autoloading feature [version 5] MMC: omap hsmmc adaptation of descriptor autoloading feature arch/arm/plat-omap/dma.c | 269 - arch/arm/plat-omap/include/plat/dma.h | 170 + drivers/mmc/host/omap_hsmmc.c | 162 3 files changed, 571 insertions(+), 30 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] OMAPFB: install omapfb.h
Hi, On Tue, 2010-02-23 at 23:36 +0100, Syrjala Ville (Nokia-D/Helsinki) wrote: > From: Ville Syrjälä > > omapfb has several custom ioctls so user space needs > the header in order to utilize them. > > Signed-off-by: Ville Syrjälä This one, and the 2/3 patch look fine, I'll apply them. The third one does not apply to my current DSS2 tree, so it needs some updating. Tomi -- 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] OMAP4: prcm: Use logical OR instead of bitwise OR
This patch fixes usage of bitwise OR in if conditions, and instead
uses logical OR.
Signed-off-by: Rajendra Nayak
Cc: Abhijit Pagare
---
arch/arm/mach-omap2/clockdomain.c |6 +++---
arch/arm/mach-omap2/powerdomain.c |2 +-
arch/arm/mach-omap2/prcm.c|4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomain.c
b/arch/arm/mach-omap2/clockdomain.c
index b87ad66..6e568ec 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -240,7 +240,7 @@ static void _omap2_clkdm_set_hwsup(struct clockdomain
*clkdm, int enable)
bits = OMAP24XX_CLKSTCTRL_ENABLE_AUTO;
else
bits = OMAP24XX_CLKSTCTRL_DISABLE_AUTO;
- } else if (cpu_is_omap34xx() | cpu_is_omap44xx()) {
+ } else if (cpu_is_omap34xx() || cpu_is_omap44xx()) {
if (enable)
bits = OMAP34XX_CLKSTCTRL_ENABLE_AUTO;
else
@@ -812,7 +812,7 @@ int omap2_clkdm_sleep(struct clockdomain *clkdm)
cm_set_mod_reg_bits(OMAP24XX_FORCESTATE,
clkdm->pwrdm.ptr->prcm_offs, OMAP2_PM_PWSTCTRL);
- } else if (cpu_is_omap34xx() | cpu_is_omap44xx()) {
+ } else if (cpu_is_omap34xx() || cpu_is_omap44xx()) {
u32 bits = (OMAP34XX_CLKSTCTRL_FORCE_SLEEP <<
__ffs(clkdm->clktrctrl_mask));
@@ -856,7 +856,7 @@ int omap2_clkdm_wakeup(struct clockdomain *clkdm)
cm_clear_mod_reg_bits(OMAP24XX_FORCESTATE,
clkdm->pwrdm.ptr->prcm_offs, OMAP2_PM_PWSTCTRL);
- } else if (cpu_is_omap34xx() | cpu_is_omap44xx()) {
+ } else if (cpu_is_omap34xx() || cpu_is_omap44xx()) {
u32 bits = (OMAP34XX_CLKSTCTRL_FORCE_WAKEUP <<
__ffs(clkdm->clktrctrl_mask));
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 9a0fb38..ebfce7d 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -222,7 +222,7 @@ void pwrdm_init(struct powerdomain **pwrdm_list)
{
struct powerdomain **p = NULL;
- if (cpu_is_omap24xx() | cpu_is_omap34xx()) {
+ if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
pwrstctrl_reg_offs = OMAP2_PM_PWSTCTRL;
pwrstst_reg_offs = OMAP2_PM_PWSTST;
} else if (cpu_is_omap44xx()) {
diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
index 81872aa..fc3fd38 100644
--- a/arch/arm/mach-omap2/prcm.c
+++ b/arch/arm/mach-omap2/prcm.c
@@ -123,7 +123,7 @@ struct omap3_prcm_regs prcm_context;
u32 omap_prcm_get_reset_sources(void)
{
/* XXX This presumably needs modification for 34XX */
- if (cpu_is_omap24xx() | cpu_is_omap34xx())
+ if (cpu_is_omap24xx() || cpu_is_omap34xx())
return prm_read_mod_reg(WKUP_MOD, OMAP2_RM_RSTST) & 0x7f;
if (cpu_is_omap44xx())
return prm_read_mod_reg(WKUP_MOD, OMAP4_RM_RSTST) & 0x7f;
@@ -157,7 +157,7 @@ void omap_prcm_arch_reset(char mode)
else
WARN_ON(1);
- if (cpu_is_omap24xx() | cpu_is_omap34xx())
+ if (cpu_is_omap24xx() || cpu_is_omap34xx())
prm_set_mod_reg_bits(OMAP_RST_DPLL3, prcm_offs,
OMAP2_RM_RSTCTRL);
if (cpu_is_omap44xx())
--
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] OMAP4: clockdomain: Use logical OR instead of bitwise OR
> -Original Message-
> From: Tony Lindgren [mailto:t...@atomide.com]
> Sent: Saturday, February 27, 2010 6:12 AM
> To: Nayak, Rajendra
> Cc: p...@pwsan.com; linux-omap@vger.kernel.org; Pagare, Abhijit
> Subject: Re: [PATCH] OMAP4: clockdomain: Use logical OR
> instead of bitwise OR
>
> * Rajendra Nayak [100226 04:44]:
> > This patch fixes usage of bitwise OR in if conditions, and instead
> > uses logical OR.
>
> Great, can you please check and update this for other similar errors:
ok.. updated patch on the way.
>
> $ grep -r ") | cpu" .
> ./mach-omap2/prcm.c:if (cpu_is_omap24xx() | cpu_is_omap34xx())
> ./mach-omap2/prcm.c:if (cpu_is_omap24xx() | cpu_is_omap34xx())
> ./mach-omap2/clockdomain.c: } else if (cpu_is_omap34xx()
> | cpu_is_omap44xx()) {
> ./mach-omap2/clockdomain.c: } else if (cpu_is_omap34xx()
> | cpu_is_omap44xx()) {
> ./mach-omap2/clockdomain.c: } else if (cpu_is_omap34xx()
> | cpu_is_omap44xx()) {
> ./mach-omap2/powerdomain.c: if (cpu_is_omap24xx() |
> cpu_is_omap34xx()) {
>
> Regards,
>
> Tony
>
>
> > Signed-off-by: Rajendra Nayak
> > Cc: Abhijit Pagare
> > ---
> >
> > Patch generated on top of for_2.6.34_b branch from
> > git://git.pwsan.com/linux-2.6 tree.
> >
> > arch/arm/mach-omap2/clockdomain.c |4 ++--
> > arch/arm/mach-omap2/powerdomain.c |2 +-
> > 2 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/clockdomain.c
> b/arch/arm/mach-omap2/clockdomain.c
> > index b87ad66..be846e6 100644
> > --- a/arch/arm/mach-omap2/clockdomain.c
> > +++ b/arch/arm/mach-omap2/clockdomain.c
> > @@ -812,7 +812,7 @@ int omap2_clkdm_sleep(struct clockdomain *clkdm)
> > cm_set_mod_reg_bits(OMAP24XX_FORCESTATE,
> > clkdm->pwrdm.ptr->prcm_offs,
> OMAP2_PM_PWSTCTRL);
> >
> > - } else if (cpu_is_omap34xx() | cpu_is_omap44xx()) {
> > + } else if (cpu_is_omap34xx() || cpu_is_omap44xx()) {
> >
> > u32 bits = (OMAP34XX_CLKSTCTRL_FORCE_SLEEP <<
> > __ffs(clkdm->clktrctrl_mask));
> > @@ -856,7 +856,7 @@ int omap2_clkdm_wakeup(struct
> clockdomain *clkdm)
> > cm_clear_mod_reg_bits(OMAP24XX_FORCESTATE,
> > clkdm->pwrdm.ptr->prcm_offs,
> OMAP2_PM_PWSTCTRL);
> >
> > - } else if (cpu_is_omap34xx() | cpu_is_omap44xx()) {
> > + } else if (cpu_is_omap34xx() || cpu_is_omap44xx()) {
> >
> > u32 bits = (OMAP34XX_CLKSTCTRL_FORCE_WAKEUP <<
> > __ffs(clkdm->clktrctrl_mask));
> > diff --git a/arch/arm/mach-omap2/powerdomain.c
> b/arch/arm/mach-omap2/powerdomain.c
> > index 9a0fb38..ebfce7d 100644
> > --- a/arch/arm/mach-omap2/powerdomain.c
> > +++ b/arch/arm/mach-omap2/powerdomain.c
> > @@ -222,7 +222,7 @@ void pwrdm_init(struct powerdomain **pwrdm_list)
> > {
> > struct powerdomain **p = NULL;
> >
> > - if (cpu_is_omap24xx() | cpu_is_omap34xx()) {
> > + if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
> > pwrstctrl_reg_offs = OMAP2_PM_PWSTCTRL;
> > pwrstst_reg_offs = OMAP2_PM_PWSTST;
> > } else if (cpu_is_omap44xx()) {
> > --
> > 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
> --
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] board-n8x0: add USB initialization
Francisco Alecrim writes: > Hi Kalle, Hi again Francisco, > On Sun, Feb 28, 2010 at 2:57 PM, Kalle Valo wrote: > Please do not add my Signed-off-by unless I have explicitly added it. > And I don't recall giving it to this patch, so it can be removed. > > > I got the initial code from http://www.valot.fi/kalle/n8x0/patches/n8x0-add/ > 2009-07-31-12:15/07-n8x0-add-usb-support.patch . I just re-organized some > variables. So I didn't remove your Signed-off-by. Hehe, I had totally forgotten that patch! Sorry :) > And I merged your patch to Tony's code http://www.mail-archive.com/ > linux-omap@vger.kernel.org/msg21443.html . So I kept his Signed-off-by. [...] > Sorry! I was not sure about keep or not these Signed-off-by. Do you > want me to re-send it without your Signed-off-by? No, this was my mistake. Please don't remove the Signed-off-by line. But when you improve a patch originally implemented by somene else it's a good practise to mention the history of the patch. For example, "Based on Kalle's and Tony's patches", or something like that, is enough IMHO. -- Kalle Valo -- 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
