From: Hiroshi DOYU hiroshi.d...@nokia.com
A bit (2 0) is set both on SECTION and SUPERSECTION. To identify
SUPERSECTION correctly, other bits should be compared too.
Reported-by: Srinivas Pulukuru srinivas.puluk...@ti.com
Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com
---
Can you dump the first few lines of the kernel log_buf during the kernel boot?
Something like this:
[0.00] Linux version 2.6.29-omap1-5-gf9f407c-dirty (ro...@maxwell)
(gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203) ) #14 PREEMPT Fri Oct 9
14:04:52 IST 2009
[0.00] CPU:
Hello,
On Fri, Oct 09, 2009 at 01:03:47PM +0200, Mark Brown wrote:
On Fri, Oct 09, 2009 at 09:45:29AM +0300, Eduardo Valentin wrote:
On Thu, Oct 08, 2009 at 03:21:10PM +0200, Mark Brown wrote:
On Thu, Oct 08, 2009 at 02:58:54PM +0300, Eduardo Valentin wrote:
I may have missed it but I
On Fri, 2009-10-09 at 23:08 +0200, ext Mikkel Christensen wrote:
This patch adds suspend / resume functionality to the RFBI driver along with
missing callback functions needed by OMAP Frame buffer.
Signed-off-by: Mikkel Christensen m...@ti.com
---
drivers/video/omap2/dss/rfbi.c | 76
On Monday 12 October 2009 10:54:09 ext e...@gmx.de wrote:
I found the memory performance of newer kernels are quit poor on an
EVM-Omap3 board. It works with 2-6 times performance on the old 2.6.22
kernel from TI's PSP.
Possible reasons:
- problem in config the kernel (did
Linux version 2.6.31 (s...@localhost) (gcc version 4.3.3 (Sourcery G++ Lite
2009q1-203) ) #1 Mon Oct 12 08:30:58 CEST 2009
CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=10c53c7f
CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
Machine: OMAP3 EVM
Memory policy: ECC
2009/10/12 Linus Walleij linus.ml.wall...@gmail.com:
2009/10/11 Alexander Shishkin virtu...@slind.org:
This driver implements support for on-chip Embedded Tracing Macrocell and
Embedded Trace Buffer. It allows to trigger tracing of kernel execution flow
and exporting trace output to userspace
On Thu, Oct 08, 2009 at 03:26:19PM +0200, Mark Brown wrote:
On Thu, Oct 08, 2009 at 02:58:55PM +0300, Eduardo Valentin wrote:
+static struct regulator_consumer_supply rx51_vmmc2_supplies[] = {
+ REGULATOR_SUPPLY(avdd_dac, 2-0018), /* tlv320aic3x */
+ REGULATOR_SUPPLY(vdd, 2-0060), /*
Please update to the latest HEAD on the linux-omap pm branch. In the gitweb it
shows
b7ecc865c5f0885fae4c4401fa78a24084f45c40
Thanks,
-Romit
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of e...@gmx.de
Sent: Monday,
On Mon, Oct 12, 2009 at 09:17:41AM +0300, Eero Nurkkala wrote:
Indeed. If I'm not totally wrong, the sidetone engineering is such,
that the sinetones should be of constant volume (this may depend on
the usecase). So, let's say we have the TPA6130 codec's volume used
along with a sidetone:
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of e...@gmx.de
Sent: Monday, October 12, 2009 2:08 PM
To: linux-omap@vger.kernel.org
Subject: RE: Memory performance / Cache problem
Linux version 2.6.31 (s...@localhost)
On Mon, Oct 12, 2009 at 11:08:58AM +0300, Eduardo Valentin wrote:
I'm afraid using dev_name is not that easy. The mmc driver generates device
name at runtime. That's why this board file setups .dev at runtime as well.
rx51_twlgpio_setup - twl4030_mmc_init - omap2_init_mmc
So, changing this
On Mon, Oct 12, 2009 at 12:04:55PM +0300, Eduardo Valentin wrote:
Right. Should we add 4 instances of drvdd and 2 of iovdd? So, naming those
would be like:
No, if there's multiple pins for the supply then there's no need to
represent those individually - they're required to be wired together
On Mon, 2009-10-12 at 11:12 +0200, ext Mark Brown wrote:
On Mon, Oct 12, 2009 at 09:17:41AM +0300, Eero Nurkkala wrote:
Indeed. If I'm not totally wrong, the sidetone engineering is such,
that the sinetones should be of constant volume (this may depend on
the usecase). So, let's say we
On Mon, Oct 12, 2009 at 12:28:25PM +0300, Eero Nurkkala wrote:
As mentioned, in some (or most) cases the absolute sinetone level (dB)
is expected constant. Even a volume change should not effect the
sidetone level. Thus, if there's a change in volume, the sidetone gains
should be readjusted.
I am sorry, the code mentioned is from the Android Public Git tree not LO PM.
Sorry for the confusion.
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Dasgupta, Romit
Sent: Monday, October 12, 2009 2:38 PM
To:
On Fri, Sep 04, 2009 at 12:04:08AM +0530, S, Venkatraman wrote:
+static int dma_caps0_status;
+
+struct omap_dma_list_config_params {
+ int chid;
This seems to be unused.
+ int num_elem;
This might want to be unsigned.
+ struct omap_dma_sglist_node *sghead;
+ int
From: Jagadeesh Bhaskar Pakaravoor j-pakarav...@ti.com
Include wake up events for receiver overflow and transmitter
underflow in OMAP_I2C_WE_REG configuration. Also fix a small
typo.
Signed-off-by: Jagadeesh Bhaskar Pakaravoor j-pakarav...@ti.com
Signed-off-by: Aaro Koskinen
On Mon, 2009-10-12 at 11:32 +0200, ext Mark Brown wrote:
On Mon, Oct 12, 2009 at 12:28:25PM +0300, Eero Nurkkala wrote:
As mentioned, in some (or most) cases the absolute sinetone level (dB)
is expected constant. Even a volume change should not effect the
sidetone level. Thus, if there's
On Mon, Oct 12, 2009 at 01:28:48PM +0300, Eero Nurkkala wrote:
No HW limits here... it's all about the hmm, friendliness of
sidetones.
This is an application level issue. We've no way of determining within
the drivers if a given path is actually being used as a real sidetone or
if it is being
Resending this patch to SPI mailing list as well.
McSPI RX timeout issues are reported on some of the OMAP3 custom boards.
After verifying configuration sequence in TRM, there seems to be issue with
McSPI configuration sequence.
The steps to be followed for both TX and RX:
1. Configure
On Tue, Sep 22, 2009 at 07:58:46PM +0530, C.A, Subramaniam wrote:
Hi All,
Following is the second version of patches for mailbox driver.
The comments provided by Hiroshi and Russell King have been in-corporated.
Resending the entire series of patches, below is the summary of changes.
Please
This patch adds support for ARM running at 720MHz part.
The 720MHz capability can be probed run-time by reading the
PRODID.SKUID[3:0] at 0x4830A20C.
[1] http://focus.ti.com/lit/ug/spruff1d/spruff1d.pdf
Signed-off-by: Sanjeev Premi pr...@ti.com
---
arch/arm/mach-omap2/clock34xx.c |
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
Remove rate tables being passed to omap2_init_common_hw, instead
pass them as arguments to omap3_pm_early_init and
call this function from board files.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c |5 +++--
arch/arm/mach-omap2/board-apollon.c |
The CPUidle C state latencies and thresholds are dependent
on various board specific details.
Hence this patch makes it possible to configure these values from the
respective board files.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c | 21 ++-
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
On Mon, Oct 12, 2009 at 03:25:27, Tomi Valkeinen wrote:
Subject: Re: [PATCH 1/1] OMAP: DSS2: RFBI driver update
On Fri, 2009-10-09 at 23:08 +0200, ext Mikkel Christensen wrote:
This patch adds suspend / resume functionality to the RFBI
driver along with missing callback functions needed by
On Mon, 2009-10-12 at 16:03 +0200, ext Christensen, Mikkel wrote:
On Mon, Oct 12, 2009 at 03:25:27, Tomi Valkeinen wrote:
Subject: Re: [PATCH 1/1] OMAP: DSS2: RFBI driver update
On Fri, 2009-10-09 at 23:08 +0200, ext Mikkel Christensen wrote:
This patch adds suspend / resume
This patch exports the smartreflex efuse values for all 5 OPPs via
sysfs. This can be useful to track down silicon specific problems.
Signed-off-by: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com
---
arch/arm/mach-omap2/smartreflex.c | 22 ++
1 files changed, 22
From: De-Schrijver Peter (Nokia-D/Helsinki) peter.de-schrij...@nokia.com
This patch exports the OMAP3 IDCODE, Production ID and Die ID to userspace via
sysfs. This can be used to track down silicon specific issues. The info is
exported via sysfs because it should be possible to include this in
This patch restores the observability settings after resuming from off mode.
Signed-off-by: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com
---
arch/arm/mach-omap2/debobs.c |9 +
arch/arm/mach-omap2/pm34xx.c |4
On Mon, Oct 12, 2009 at 5:51 PM, Peter 'p2' De Schrijver
peter.de-schrij...@nokia.com wrote:
From: De-Schrijver Peter (Nokia-D/Helsinki) peter.de-schrij...@nokia.com
This patch exports the OMAP3 IDCODE, Production ID and Die ID to userspace via
sysfs. This can be used to track down silicon
On Mon, Oct 12, 2009 at 09:17:27, Tomi Valkeinen wrote:
Subject: RE: [PATCH 1/1] OMAP: DSS2: RFBI driver update
On Mon, 2009-10-12 at 16:03 +0200, ext Christensen, Mikkel wrote:
On Mon, Oct 12, 2009 at 03:25:27, Tomi Valkeinen wrote:
Subject: Re: [PATCH 1/1] OMAP: DSS2: RFBI driver update
This patch has been applied to the linux-omap
by youw fwiendly patch wobot.
Branch in linux-omap: for-next
Initial commit ID (Likely to change): a277c0d7d189e74cd13bfd74d180c4eec0a177e7
PatchWorks
http://patchwork.kernel.org/patch/52896/
Git (Likely to change, and takes a while to get
Hello Aaro!
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Aaro Koskinen
Sent: Monday, October 12, 2009 5:21 AM
To: ben-li...@fluff.org; linux-...@vger.kernel.org
Cc: linux-omap@vger.kernel.org; j-pakarav...@ti.com
omap3: ehci: trivial fix of a debug print
We're interested in uhh_hostconfig, not uhh_base. While we
are actually printing the former, we're calling it the latter.
Signed-off-by: Anand Gadiyar gadi...@ti.com
---
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index
* Sanjeev Premi pr...@ti.com [091009 12:54]:
This patch allows run-time detection of different
variants in the OMAP35x family.
[1] http://marc.info/?l=linux-omapm=125387617812499w=2
This patch was been created against omap3-upstream at:
21f1a8f : omap: Include bitops from cpu.h
On Fri, Oct 9, 2009 at 3:04 PM, Kevin Hilman
khil...@deeprootsystems.com wrote:
Kevin Hilman khil...@deeprootsystems.com writes:
Kevin Hilman khil...@deeprootsystems.com writes:
Kevin Hilman khil...@deeprootsystems.com writes:
Juha Kuikka juha.kui...@gmail.com writes:
On Tue, Oct
Juha Kuikka wrote:
[...]
I updated both x-loader and u-boot. And I also pulled the latest
omap-pm and did a fresh build. I noticed there is a commit that should
fix the serial port issue.
Unfortunately I am still plagued by it.
X-Loader 1.41
U-Boot 2009.08 (Oct 09 2009 - 15:59:45)
Latest
make default cpu_is_omap3630() return zero
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
---
arch/arm/plat-omap/include/mach/cpu.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/mach/cpu.h
b/arch/arm/plat-omap/include/mach/cpu.h
index
On Mon, Oct 12, 2009 at 1:47 PM, Kevin Hilman
khil...@deeprootsystems.com wrote:
Juha Kuikka wrote:
[...]
I updated both x-loader and u-boot. And I also pulled the latest
omap-pm and did a fresh build. I noticed there is a commit that should
fix the serial port issue.
Unfortunately I am
-Original Message-
From: Menon, Nishanth
Sent: Monday, October 12, 2009 4:05 PM
To: Pandita, Vikram
Cc: linux-omap@vger.kernel.org
Subject: RE: [PATCH] [RFC] omap: 3630: default cpu_is_omap3630 to zero
-Original Message-
From: Pandita, Vikram
Sent: Monday, October 12, 2009
-Original Message-
From: Pandita, Vikram
Sent: Monday, October 12, 2009 4:08 PM
-Original Message-
From: Pandita, Vikram
Sent: Monday, October 12, 2009 3:51 PM
make default cpu_is_omap3630() return zero
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
---
Juha Kuikka juha.kui...@gmail.com writes:
On Mon, Oct 12, 2009 at 1:47 PM, Kevin Hilman
khil...@deeprootsystems.com wrote:
Juha Kuikka wrote:
[...]
I updated both x-loader and u-boot. And I also pulled the latest
omap-pm and did a fresh build. I noticed there is a commit that should
fix
Hi,
This is the first public release of gst-dsp; a native GStreamer plug-in to
access Texas Instruments' DSP algorithms for OMAP3 platforms.
The code came originally from a series of TI projects: tiopenmax[1], and
libbridge[2]. gst-dsp replaces these two layers and talks directly to the DSP
46 matches
Mail list logo
