Dirk Behme wrote:
Madhusudhan wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Phaneendra Kumar Alapati
Sent: Wednesday, October 28, 2009 8:19 AM
To: linux-omap@vger.kernel.org
Subject: [PATCH] OMAP35xx: Added SDIO
> -Original Message-
> From: Felipe Balbi [mailto:felipe.ba...@nokia.com]
> Sent: Thursday, October 29, 2009 12:29 PM
> To: Gupta, Ajay Kumar
> Cc: linux-omap@vger.kernel.org; Balbi Felipe (Nokia-D/Helsinki); Menon,
> Nishanth; Gadiyar, Anand
> Subject: Re: [PATCH 3/3] omap3evm: musb: Updat
On Wed, 28 Oct 2009 08:53:34 +0200
Eero Nurkkala wrote:
> On Wed, 2009-10-28 at 06:52 +0100, Ujfalusi Peter (Nokia-D/Tampere)
> > Yeah, but I think this locking issue has nothing to do with SMP safe or not.
> > On playback start in omap_mcbsp_request the mcbsp->free is cleared.
> > Further modifi
On Thu, 29 Oct 2009 08:35:51 +0200
Peter Ujfalusi wrote:
> > The spinlocks are unnecessary. In the above example, you get the same
> > with just "return mcbsp->dma_op_mode;"
> >
> > -> Peter's patch is a good cleanup.
>
> Jarkko: are we going to take this?
>
Yep, you can have my
Acked-by: Jar
All of the OMAP3 IVA physical address macros in
plat-omap/include/plat/omap34xx.h are wrong[1]:
OMAP34XX_IVA_INTC_BASE: The IVA interrupt controller does not appear
to be accessible from the L3 interconnect, and in any case is
definitely not at 0x4000; the latter address appears to be the
int
Paul/Kevin,
As Madhu explained it looks like there are instances
where we forcibly need to bump up to a higher CPU + L3 frequencies (VDD1 + VDD2
scaling). I understand that this should be done by cpufreq governors but here
is reason that I think the current cpufreq governor
I rebased my both audio and l-o trees but could not find this patch
there. Is there a problem in this which I have to fix and re-submit?
Regards,
Anuj Aggarwal
> -Original Message-
> From: Aggarwal, Anuj
> Sent: Wednesday, September 23, 2009 12:41 PM
> To: alsa-de...@alsa-project.org; li
Hi Kevin,
Made some patches to enable setting RX-51 cpu idle parameters
as we use them. Added "valid" field passing to cpuidle_params
in the process.
Tested on RX-51. Applies on top of linux-omap/pm branch.
Kalle Jokiniemi (3):
OMAP:PM: Fix non-cpu idle builds using omap3_pm_init_cpuidle
Building without CONFIG_CPU_IDLE causes build to fail if
cpu idle parameters are tried to pass using
omap3_pm_init_cpuidle function.
Fixed by defining a dummy function for non-cpu idle
builds.
Signed-off-by: Kalle Jokiniemi
---
arch/arm/mach-omap2/pm.h |7 +++
1 files changed, 7 inserti
Pass cpuidle parameters for RX-51. Numbers based on
measurements made in October 2009 for PM optimized
kernel with CPU freq enabled. Assumes OPP2 (main
idle OPP, and worst case latencies).
Signed-off-by: Kalle Jokiniemi
---
arch/arm/mach-omap2/board-rx51.c | 18 ++
1 files chan
Different boards benefit differently from the available
seven C-states for cpu idle. In most cases, only few,
properly spaced (in terms of consumption and latency)
C-states are required to make the power management
optimal. Hence we need a possibility to pass which
C-states are actually used for ea
OK, let's try this once more, since my mail did not seem to go to
linux-omap.
Sorry for the spam.
See my comments below:
On Fri, 2009-10-23 at 18:53 +0300, Sonasath, Moiz wrote:
> Hello Jokiniemi!
>
> > -Original Message-
> > From: Kalle Jokiniemi [mailto:kalle.jokini...@digia.com]
> >
On Thursday 29 October 2009 10:00:41 ext Aggarwal, Anuj wrote:
> I rebased my both audio and l-o trees but could not find this patch
> there. Is there a problem in this which I have to fix and re-submit?
Yes, I have seen the patch, and it look good.
You can have my:
Acked-by: Peter Ujfalusi
if
Hi,
On Thu, Oct 29, 2009 at 08:03:21AM +0100, ext Gupta, Ajay Kumar wrote:
> > I was thinking on adding a musb_hdrc_board_data which would group
> > board-specific data such as this one.
> >
> > Musb's init phase is quite messy as of today so we would need to clean
> > that up. Anyways, the main
Dirk and Madhu, Thanks for the review/comments. I have explained below
the reasons behind certain changes i made esp the interrupt enabling
and irq routine changes.
On Thu, Oct 29, 2009 at 2:22 AM, Madhusudhan wrote:
>
>
>> -Original Message-
>> From: Dirk Behme [mailto:dirk.be...@googlem
Tony Lindgren wrote:
> * Mike Rapoport [091028 06:17]:
>> This is an attempt to start rework of the mux framework keeping as
>> much backward compatibility as possible.
>> The patch serie introduces a new mux configuration interface that
>> follows the ideas of PXA MFP implementation ([1] and [2
Hi Kevin,
On Wed, 2009-10-21 at 14:51 +0300, Kalle Jokiniemi wrote:
> Hello,
> Here are some fruits from digging out the latency sources
> of our idle loop. The main latency source was powerdomain
> state counter updating at beginning and end of the idle
> loop. Also PER previous state reading str
On Thu, Oct 29, 2009 at 01:30:41PM +0530, Aggarwal, Anuj wrote:
> I rebased my both audio and l-o trees but could not find this patch
> there. Is there a problem in this which I have to fix and re-submit?
You should always CC the relevant maintainers on patches, otherwise
there is no guarantee th
Hi,
> On Thu, Oct 29, 2009 at 08:03:21AM +0100, ext Gupta, Ajay Kumar wrote:
> > > I was thinking on adding a musb_hdrc_board_data which would group
> > > board-specific data such as this one.
> > >
> > > Musb's init phase is quite messy as of today so we would need to clean
> > > that up. Anyways,
On Thu, Oct 29, 2009 at 01:09:25PM +0530, Dasgupta, Romit wrote:
[Reflowed into 80 columns - you might want to look at your MUA setup.]
> The sampling intervals for the cpufreq governors are quite large
> and thus the latency for the frequency change to occur is large.
> This was s
Hi Romit,
>
Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet.
036 420 040 R.C.S Antibes. Capital de EUR 753.920
-Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Dasgupta, Romit
>
> Paul/Kevin
Enable Nand suport on the OMAP3EVM.
Signed-off-by: Sriramakrishnan
---
This patch has been generated against the tip of for-next branch.
arch/arm/configs/omap3_evm_defconfig |2 +
arch/arm/mach-omap2/board-omap3evm.c | 102 ++
2 files changed, 104 insertions
Hi,
On Wed, 2009-10-28 at 08:13 +0100, ext Govindraj.R wrote:
> From 0f017ffac2990876331a2378e7845d91b2e0088c Mon Sep 17 00:00:00 2001
> From: Govindraj R
> Date: Wed, 28 Oct 2009 12:23:02 +0530
> Subject: [PATCHv2 2/3] OMAP UART: Add platform data for omap-serial driver.
>
> This patch adds pla
Currently the default silicon - in absence of
identification - is set to OMAP3630 ES1.0.
Though, condition may/should not arise; but
the default should be latest in the most
common silicon variant - currently OMAP3430
ES3.1.
Signed-off-by: Sanjeev Premi
---
arch/arm/mach-omap2/id.c |4 ++--
On Thu, Oct 29, 2009 at 12:30 PM, Dirk Behme wrote:
> Dirk Behme wrote:
>
> I promised to come back with test results. As mentioned in this thread
> already, I can't test on my own yet, instead Steve (many, many thanks!)
> tests it on Overo air. Overo air uses Marvell's 88W8686 connected to MMC
>
Hello Benoit,
One comment below:
>
> In fact, this is Mike who started that analysis. We discussed that internally
> and
> our point is that if the CPUFreq ondemand or conservative heuristic is not
> able
> to increase quickly enough the CPU need to handle correctly the U
"Dasgupta, Romit" writes:
> Hello Benoit,
> One comment below:
>>
>> In fact, this is Mike who started that analysis. We discussed that
>> internally and
>> our point is that if the CPUFreq ondemand or conservative heuristic is not
>> able
>> to increase quickly enough
* Mike Rapoport [091029 02:45]:
>
>
> Tony Lindgren wrote:
> > * Mike Rapoport [091028 06:17]:
> >> This is an attempt to start rework of the mux framework keeping as
> >> much backward compatibility as possible.
> >> The patch serie introduces a new mux configuration interface that
> >> follow
* Mike Rapoport [091028 06:17]:
> Signed-off-by: Mike Rapoport
> ---
> arch/arm/mach-omap2/mux.c | 25 +++--
> 1 files changed, 19 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
> index 32c953e..eb6e202 100644
> --- a/a
Enable Nand support on am3517evm
Signed-off-by: Sriramakrishnan
---
This patch builds on the am3517evm board support patch submitted earlier.
http://marc.info/?l=linux-omap&m=125673923227266&w=2
arch/arm/configs/am3517_evm_defconfig | 103 -
arch/arm/mach-omap2/
Hi, all!
I need to transfer block of data using sDMA from memory address
to RFBI_PARAM FIFO, so to put that into display module.
I do this like this:
/* DMA */
#define RFBI_BASE 0x48050800
#define RFBI_PARAM 0x0050
static void configure_dma(int dma_ch, u32 data, int size)
{
int nblk;
* Tony Lindgren [091029 08:50]:
> * Mike Rapoport [091028 06:17]:
> > Signed-off-by: Mike Rapoport
> > ---
> > arch/arm/mach-omap2/mux.c | 25 +++--
> > 1 files changed, 19 insertions(+), 6 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/
On Thu, Oct 29, 2009 at 11:29:39AM +0100, ext Gupta, Ajay Kumar wrote:
> Hi,
> > On Thu, Oct 29, 2009 at 08:03:21AM +0100, ext Gupta, Ajay Kumar wrote:
> > > > I was thinking on adding a musb_hdrc_board_data which would group
> > > > board-specific data such as this one.
> > > >
> > > > Musb's init
This patch series add support for OMAP3517 / AM3517 EVM in ASOC.
It also enables the required drivers - I2C and McBSP, along with
Alsa SoC subsystem, in the default configuration for the EVM.
Anuj Aggarwal (4):
Audio: Adding OMAP3517 / AM3517 EVM support in ASOC
Audio: Modifying Kconfig/Makefi
Adding support for OMAP3517 / AM3517 EVM in Alsa SoC.
Signed-off-by: Anuj Aggarwal
---
sound/soc/omap/am3517evm.c | 202
1 files changed, 202 insertions(+), 0 deletions(-)
create mode 100644 sound/soc/omap/am3517evm.c
diff --git a/sound/soc/omap/am
Modifying the Kconfig and Makefile in sound/soc/omap folder
to add support for OMAP3517 / AM3517 EVM in Alsa SoC.
Signed-off-by: Anuj Aggarwal
---
sound/soc/omap/Kconfig |9 +
sound/soc/omap/Makefile |2 ++
2 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/sound/so
Adding I2C bus registration code in board-evm file for OMAP3517 /
AM3517 EVM for AIC23 audio codec.
Signed-off-by: Anuj Aggarwal
---
arch/arm/mach-omap2/board-am3517evm.c | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am351
Enabling Audio for OMAP3517 / AM3517 EVM in the defconfig.
Also enabling McBSP and I2C drivers as both are required for
audio on this EVM.
Signed-off-by: Anuj Aggarwal
---
arch/arm/configs/am3517_evm_defconfig | 78 +++-
1 files changed, 75 insertions(+), 3 deletio
On Thu, Oct 29, 2009 at 6:51 PM, Tony Lindgren wrote:
> * Tony Lindgren [091029 08:50]:
>> * Mike Rapoport [091028 06:17]:
>> > Signed-off-by: Mike Rapoport
>> > ---
>> > arch/arm/mach-omap2/mux.c | 25 +++--
>> > 1 files changed, 19 insertions(+), 6 deletions(-)
>> >
>>
* Mike Rapoport [091029 13:28]:
> On Thu, Oct 29, 2009 at 6:51 PM, Tony Lindgren wrote:
> > * Tony Lindgren [091029 08:50]:
> >> * Mike Rapoport [091028 06:17]:
> >> > Signed-off-by: Mike Rapoport
> >> > ---
> >> > arch/arm/mach-omap2/mux.c | 25 +++--
> >> > 1 files cha
Hi all,
Here's an initial version of the new mux code to play with.
Big thanks to Paul & Benoit for the 34xx mux data!
To try out the new code, compile a kernel with CONFIG_OMAP_MUX
and CONFIG_DEBUG_FS and these patches. The series is also
availabe in the l-o git in mux branch.
To see the mux co
From: Mike Rapoport
intoduce omap_mux_{read,write}
Signed-off-by: Mike Rapoport
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/mux.c | 44 ++--
1 files changed, 38 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/
Initially only for 34xx. Keep the old code working
until the data has been converted to the new style
format.
REVISIT: Add support for cmdline parsing
REVISIT: Add a function to get mux register by GPIO pin
REVISIT: Add a function to set an array of mux entries
Signed-off-by: Tony Lindgren
---
Add new style mux init functions to omap3 board-*.c files
REVISIT: Check package type for each board CBB for now
REVISIT: Remove OMAP_MUX_ALL_DYNAMIC debug option
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/board-3430sdp.c |9 +
arch/arm/mach-omap2/board-cm-t35.c
Add debugfs support for new mux code
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/mux.c | 143 +
1 files changed, 143 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 45e6d4d..a31bcfa 1006
Adjust OMAP3 frequency transition latency from 10,000,000uS to a more
reasonable 300,000uS. This causes ondemand and conservative governors to
sample CPU load more often resulting in more responsive behavior.
Tested on Android 2.6.29; using this value and conservative governor, CORE
power consump
Comments below...
Phaneendra Kumar Alapati wrote:
Dirk and Madhu, Thanks for the review/comments. I have explained below
the reasons behind certain changes i made esp the interrupt enabling
and irq routine changes.
On Thu, Oct 29, 2009 at 2:22 AM, Madhusudhan wrote:
-Original Message--
Mike Turquette writes:
> Adjust OMAP3 frequency transition latency from 10,000,000uS to a more
> reasonable 300,000uS. This causes ondemand and conservative governors to
> sample CPU load more often resulting in more responsive behavior.
>
> Tested on Android 2.6.29; using this value and conserv
Hi Tony,
On Thu, Oct 29, 2009 at 10:35 PM, Tony Lindgren wrote:
> Hi all,
>
> Here's an initial version of the new mux code to play with.
> Big thanks to Paul & Benoit for the 34xx mux data!
>
> To try out the new code, compile a kernel with CONFIG_OMAP_MUX
> and CONFIG_DEBUG_FS and these patches
Kevin Hilman wrote:
"Dasgupta, Romit" writes:
Hello Benoit,
One comment below:
In fact, this is Mike who started that analysis. We discussed that internally
and
our point is that if the CPUFreq ondemand or conservative heuristic is not able
to increase quickly enough
Kevin Hilman wrote:
Mike Turquette writes:
Adjust OMAP3 frequency transition latency from 10,000,000uS to a more
reasonable 300,000uS. This causes ondemand and conservative governors to
sample CPU load more often resulting in more responsive behavior.
Tested on Android 2.6.29; using this val
Mike Turquette writes:
> Kevin Hilman wrote:
>> Mike Turquette writes:
>>
>>> Adjust OMAP3 frequency transition latency from 10,000,000uS to a more
>>> reasonable 300,000uS. This causes ondemand and conservative governors to
>>> sample CPU load more often resulting in more responsive behavior.
* Mike Rapoport [091029 14:19]:
> Hi Tony,
>
> On Thu, Oct 29, 2009 at 10:35 PM, Tony Lindgren wrote:
> > Hi all,
> >
> > Here's an initial version of the new mux code to play with.
> > Big thanks to Paul & Benoit for the 34xx mux data!
> >
> > To try out the new code, compile a kernel with CONF
> -Original Message-
> From: Mike Turquette [mailto:mturque...@ti.com]
> Sent: Thursday, October 29, 2009 4:38 PM
> To: Kevin Hilman
> Cc: Dasgupta, Romit; Cousson, Benoit; Chikkature Rajashekar, Madhusudhan;
> 'Paul Walmsley'; linux-omap@vger.kernel.org; Titiano, Patrick
> Subject: Re: [
On Fri, Oct 30, 2009 at 12:22:17AM +0530, Anuj Aggarwal wrote:
> This patch series add support for OMAP3517 / AM3517 EVM in ASOC.
> It also enables the required drivers - I2C and McBSP, along with
> Alsa SoC subsystem, in the default configuration for the EVM.
>
> Anuj Aggarwal (4):
> Audio: Add
With CONFIG_PM=y, the omapfb/lcd device on Amstrad Delta, after initially
starting correctly, breaks with the following error messages:
omapfb omapfb: resetting (status 0xff96,reset count 1)
...
omapfb omapfb: resetting (status 0xff96,reset count 100)
omapfb omapfb: too many reset attempts
Kalle Jokiniemi writes:
> From: Kalle Jokiniemi
>
> The biggest source of latency in idle loop (omap_sram_idle
> function) comes from updating the state counters for each
> power domain. The two purposes of these counters are to
> provide debug data in debugfs, and to keep track of context
> los
"Madhusudhan" writes:
>> -Original Message-
>> From: Mike Turquette [mailto:mturque...@ti.com]
>> Sent: Thursday, October 29, 2009 4:38 PM
>> To: Kevin Hilman
>> Cc: Dasgupta, Romit; Cousson, Benoit; Chikkature Rajashekar, Madhusudhan;
>> 'Paul Walmsley'; linux-omap@vger.kernel.org; Titia
Thursday 29 October 2009 23:39:44 Janusz Krzysztofik napisał(a):
>
> Since PM area is quite new to me, I am not sure if there may be a better
> solution. AFAICS, the standard way to prevent an ARM_CLKCT1 bit being
s/ARM_CLKCT1/ARM_IDLECT1/
> switched to idle is to enable a clock that uses it (tip
Hi all,
Today's linux-next merge of the omap tree got a conflict in
arch/arm/mach-omap1/serial.c between commit
c33da3a80074094303d643a90ef589330b491270 ("omap1: Fix redundant UARTs pin
muxing that can break other hardware support") from Linus' tree and
commits 84f90c9cc81d8db172d4f768fc4010f50889
Hi all,
Today's linux-next merge of the omap tree got conflicts in
arch/arm/mach-omap2/board-3430sdp.c, arch/arm/mach-omap2/board-ldp.c,
arch/arm/mach-omap2/board-omap3evm.c,
arch/arm/mach-omap2/board-omap3pandora.c,
arch/arm/mach-omap2/board-rx51-peripherals.c,
arch/arm/mach-omap2/board-rx51.c an
>From a36dac7ee6140ffa23f0adc024964aaf3e266e5f Mon Sep 17 00:00:00 2001
From: Tao Hu
Date: Thu, 29 Oct 2009 17:17:21 -0500
Subject: [PATCH] Fix race condition in omap_request_dma()
The bug could cause irq enable bit of one DMA channel is
cleared unexpectedly when 2 (or more) drivers are calling
o
For ease of use it is preferrable to build in HSMMC driver
rather than build it as kernel module. This patches updates
default configuration for omap3evm to reflect this change.
Signed-off-by: Sriramakrishnan
---
arch/arm/configs/omap3_evm_defconfig |2 +-
1 files changed, 1 insertions(+), 1
63 matches
Mail list logo
