OMAP sDMA driver API omap_stop_dma() doesn't really stop the dma when used
in linking scenario. This patch fixes the same.
Signed-off-by: Santosh Shilimkar
Signed-off-by: Venkatraman S
Reviewed-By: Tony Lindgren
CC: Hari n
CC: Jarkko Nikula
---
arch/arm/plat-omap/dma.c |5 +
1 files
On Thursday 15 October 2009 09:10:54 ext Shilimkar, Santosh wrote:
> > > > > > - writew(buf, base + OMAP_MCBSP_REG_DXR1);
> > > > > > + OMAP_MCBSP_WRITE(base, DXR, buf);
> > > > >
> > > > > Why do you need this? Is writew()/readw() not doing 16 bit
> > > > > operations ?
> > > >
> > > > The in
Charu,
> -Original Message-
> From: Peter Ujfalusi [mailto:peter.ujfal...@nokia.com]
> Sent: Thursday, October 15, 2009 12:56 PM
> To: Shilimkar, Santosh
> Cc: Varadarajan, Charu Latha; linux-omap@vger.kernel.org; Syed, Rafiuddin
> Subject: Re: [PATCH] OMAP3: Fix McBSP poll read and write f
On Wed, Oct 14, 2009 at 10:15:48AM -0700, Tony Lindgren wrote:
> * Mark Brown [091012 02:18]:
> > On Mon, Oct 12, 2009 at 11:08:58AM +0300, Eduardo Valentin wrote:
> > > I'm afraid using dev_name is not that easy. The mmc driver generates
> > > device
> > > name at runtime. That's why this board
Muxes for OMAP 3630.
Signed-off-by: Allen Pais
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index b5fac32..93abb74 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -551,6 +551,42 @@ MUX_CFG_34XX("AF13_3430_MMC3_DAT3", 0x5e2,
MUX_CFG_34XX("AF26_34XX_
Please ignore my previous mail.
Muxes for OMAP 3630.
Signed-off-by: Allen Pais diff --git
a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c index b5fac32..93abb74
100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -551,6 +551,42 @@ MUX_CFG_34XX("AF13_3430_MMC3_DAT3
Thanks Paul. The bit positions are goofed up only in PWRSTS and PREPWRSTS not
in PWSTCTRL register. As per the approach you have suggested below, if we
change the mem bank number from 0 to 1 , we will have to change the logic for
read/write into PWSTCTRL for mpu pwr domain.
Regards
Thara
>>---
> Muxes for OMAP 3630.
What is the plan to add omap_cfg_reg calls for these new pins, which actually
configures these pin muxes.
Thanks
Hemanth
>
> Signed-off-by: Allen Pais
> diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
> index b5fac32..93abb74 100644
> --- a/arch/arm/mac
> On Wednesday 14 October 2009 17:48:39 ext e...@gmx.de wrote:
> > Mem clock is both times 166MHz. I don't know whether are differences in
> > cycle access and timing, but memclock is fine.
> >
> > Following Siarhei hints of initialize the buffers (around 1.2 MByte
> each)
> > I get different resu
On Wed, Oct 14, 2009 at 04:56:18PM +0530, Shilimkar, Santosh wrote:
> > On the latest ARM kernel(v2.6.32-rc4),I have observed a BUG() dump when
Umm...
> @@ -350,7 +350,7 @@ static inline void local_flush_tlb_mm(struct mm_struct
> *mm)
> if (tlb_flag(TLB_WB))
> dsb();
>
> -
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Shilimkar, Santosh
Sent: Thursday, October 15, 2009 1:01 PM
To: Peter Ujfalusi
Cc: Varadarajan, Charu Latha; linux-omap@vger.kernel.org; Syed, Rafiuddin
Subject: RE: [PATCH] OMA
Please send your patch using git send email. And generate your patch using git
format patch
> -Original Message-
> From: Pais, Allen
> Sent: Thursday, October 15, 2009 4:38 AM
>
> Please ignore my previous mail.
>
> Muxes for OMAP 3630.
>
> Signed-off-by: Allen Pais diff --git a/arch/
Hi Allen,
a) A simple comment to all my comments: why cant we have these in bootloader
and just simply leave the mux file alone?
b) Are you doing this for a specific platform or are they generic 3630 pin mux
changes?
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:l
The patch submitted to patch-system I based it on 2.6.32-rc4
Have you tried that patch ?
The one attached was in email was based on 2.6.31
Regards,
Santosh
> -Original Message-
> From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> Sent: Thursday, October 15, 2009 5:11 PM
>
> -Original Message-
> From: linux-arm-kernel-boun...@lists.infradead.org [mailto:linux-arm-
> kernel-boun...@lists.infradead.org] On Behalf Of Shilimkar, Santosh
> Sent: Thursday, October 15, 2009 6:55 PM
> To: Russell King - ARM Linux
> Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lis
Hi,
The setup times to be programmed in the PRM module on OMAP (for clksetup,
voltsetup etc)
are board specific. They depend heavily on the PMIC used and even on different
boards
with the same PMIC, they vary based on the sleep/wake sequence used, system
clock speed et al.
The CPUidle latencie
The CPUidle C state latencies and thresholds are dependent
on various board specific details.
This patch makes it possible to configure these values from the
respective board files.
omap3_pm_init_cpuidle() can now be optionally called from board
files to pass board specific cpuidle parameters.
If
The setup times to be programmed in the PRM module on OMAP
(for clksetup, voltsetup etc) are board specific.
They depend heavily on the PMIC used and even on different boards
with the same PMIC, they vary based on the sleep/wake
sequence used, system clock speed et al.
This patch makes it possible
As part of Core domain context restoration while coming out of off mode
there are some registers being restored which are not required to be restored.
ROM code should have restored them already. Overwriting some of them can have
potential side effect. Eg: CM_CLKEN_PLL register should not be written
* Shilimkar, Santosh [091014 21:40]:
> > -Original Message-
> > From: Tony Lindgren [mailto:t...@atomide.com]
> > Sent: Wednesday, October 14, 2009 10:36 PM
> > To: Shilimkar, Santosh
> > Cc: linux-omap@vger.kernel.org; S, Venkatraman; Hari n; Jarkko Nikula
> > Subject: Re: [PATCH] ARM: OM
I have seen several discussions about lack of sdio irq support in the
hsmmc driver but no patches. Has anyone on this list implemented this
and/or can anyone point me to patches?
Thanks
John
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to major
As part of Core domain context restoration while coming out of off mode
there are some registers being restored which are not required to be restored.
ROM code should have restored them already. Overwriting some of them can have
potential side effect. Eg: CM_CLKEN_PLL register should not be written
Hi all,
Thanks to Paul's "OMAP2xxx clock: set up clockdomain pointer in struct clk"
patch, we got 24xx booting again both in mainline and in linux-omap.
The following patch is also needed to change the n8x0 serial console CMDLINE
from ttyS0 to ttyS2 as the port numbering now matches the physical
Hi Allen,
a) A simple comment to all my comments: why cant we have these in bootloader
and just simply leave the mux file alone?
[Allen] Yes Nishanth, this would be a much cleaner approach. Even Santosh had
suggested
The same, if we can conclude on a approach here, I can go ahead and do the M
Pais, Allen had written, on 10/15/2009 11:53 PM, the following:
a) A simple comment to all my comments: why cant we have these in bootloader
and just simply leave the mux file alone?
[Allen] Yes Nishanth, this would be a much cleaner approach. Even Santosh had
suggested
The same, if we can conc
> > > This fix should be tested in linux-omap before we send this to
> mainline.
> > Yes ofcourse. That what I meant by merge.
>
> Yeah, we should still have enough time to get it into mainline kernel
> as a fix during this -rc cycle.
OK. Also please merge other two patches in linux-omap master
I missed updating omap_init_power_states() to look into cpuidle_params_table
at init, as part of this patch. Will send a fixed patch shortly.
Thanks to Thara for catching this.
>-Original Message-
>From: Nayak, Rajendra
>Sent: Thursday, October 15, 2009 8:19 PM
>To: linux-omap@vger.kernel
27 matches
Mail list logo
