Hi Ernesto,
From: ext Ramos Falcon, Ernesto erne...@ti.com
Subject: [PATCH] DSPBRIDGE: Interface tightening to check for invalid
Date: Mon, 23 Nov 2009 21:12:08 +0100
From f28ec22e48a9b61ac00b7711e035e117bdc71aeb Mon Sep 17 00:00:00 2001
From: Ernesto Ramos erne...@ti.com
Date: Mon, 23 Nov
-Original Message-
From: Olof Johansson [mailto:o...@lixom.net]
Sent: Monday, November 23, 2009 10:36 PM
To: Govindraj; g...@lixom.net
Cc: Tony Lindgren; linux-omap@vger.kernel.org; Pandita,
Vikram; Raja, Govindraj; G, Manjunath Kondaiah
Subject: Re: [PATCHv3 0/3] OMAP UART:
-Original Message-
From: Menon, Nishanth
Sent: Tuesday, November 24, 2009 7:09 AM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH] omap3: sr: Update ON voltage levels based on VSEL
Premi, Sanjeev had written, on 11/23/2009 07:38 AM, the following:
The
From: Tero Kristo tero.kri...@nokia.com
VFP save context is called before MPU/NEON off. Restore is not needed as
the next VFP trap will restore context automatically. Uses the support
routine implemented in arch/arm/vfp/vfpmodule.c.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
Acked-by: Tony
From: Tero Kristo tero.kri...@nokia.com
Hi,
The following two patches are needed by OMAP3 to save/restore VFP context
during off-mode. Patch 1 adds generic support inside ARM VFP code, and the
second one adds the necessary hooks into OMAP3 power management code.
--Tero
--
To unsubscribe from
From: Tero Kristo tero.kri...@nokia.com
In some ARM architectures, like OMAP3, the VFP context can be lost during
dynamic sleep cycle. For this purpose, there is now a function
vfp_pm_save_context() that should be called before the VFP is assumed to
lose context. Next VFP trap will then restore
Change the way McBSP registers are updated: use cached values instead of
relying upon those read back from the device.
With this patch, I have finally managed to get rid of all random
playback/recording hangups on my OMAP1510 based Amstrad Delta hardware. Before
that, values read back from McBSP
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Tero Kristo
Sent: Tuesday, November 24, 2009 4:07 PM
To: linux-arm-ker...@lists.infradead.org
Cc: linux-omap@vger.kernel.org
Subject: [PATCH 2/2] OMAP3: Implemented
Hi,
On Fri, 2009-11-20 at 15:27 +0100, ext Y, Kishore wrote:
From df64194feedc16c3f3f552dc26bc3050b7245005 Mon Sep 17 00:00:00 2001
From: Mukund Mittal mmit...@ti.com
Date: Fri, 20 Nov 2009 18:35:26 +0530
Subject: [PATCH] ZOOM: DSS2: Add nec panel for zoom display
Nec panel has been added
On Tue, Nov 24, 2009 at 12:37:03PM +0200, Tero Kristo wrote:
In some ARM architectures, like OMAP3, the VFP context can be lost during
dynamic sleep cycle. For this purpose, there is now a function
vfp_pm_save_context() that should be called before the VFP is assumed to
lose context. Next VFP
The rtc-omap driver currently hardcodes the RTC to be
not capable of wakeup events. On the DA850/OMAP-L138
SoC, the RTC is a wake up source from its deep sleep
mode.
Let platform data set the wakeup capability flag instead.
Signed-off-by: Sekhar Nori nsek...@ti.com
Signed-off-by: Kevin Hilman
On Tue, 2009-11-24 at 11:48 +, Russell King - ARM Linux wrote:
On Tue, Nov 24, 2009 at 12:37:03PM +0200, Tero Kristo wrote:
In some ARM architectures, like OMAP3, the VFP context can be lost during
dynamic sleep cycle. For this purpose, there is now a function
vfp_pm_save_context() that
-Original Message-
From: ext Catalin Marinas [mailto:catalin.mari...@arm.com]
Sent: 24 November, 2009 15:20
To: Russell King - ARM Linux
Cc: Kristo Tero (Nokia-D/Tampere); linux-omap@vger.kernel.org;
linux-arm-ker...@lists.infradead.org; Dave Estes
Subject: Re: [PATCH 1/2] ARM:
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Monday, November 23, 2009 11:23 PM
To: Hiremath, Vaibhav
Cc: linux-in...@vger.kernel.org; linux-omap@vger.kernel.org
Subject: Re: [PATCH 1/3] Mux configuration for AM3517 TouchScreen
support
* hvaib...@ti.com
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Monday, November 23, 2009 11:25 PM
To: Hiremath, Vaibhav
Cc: linux-in...@vger.kernel.org; linux-omap@vger.kernel.org
Subject: Re: [PATCH 3/3] AM3517: Add support for TSC2004 driver
Hi,
* hvaib...@ti.com
Hi,
Is there any update on this chain seeing this has been pending for a month now?
-Tero
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of ext
Woodruff, Richard
Sent: 22 October, 2009 15:20
To: Cousson, Benoit; Paul
Dear All,
We are trying to make the HSUSB1 port on the OMAP3430 work as an USB host.
To do that, an ISP1507A ULPI HighSpeed USB transceiver is connected to
the HSUSB1pins (HSUSB1_STP, CLK, D-0..D7, DIR, NXT).
I have all these USB related kernel config options enabled:
USB_EHCI_HCD
On Thu, 2009-11-19 at 19:38 +0530, Vimal Singh wrote:
Here is the v6 of this patch series. I am cc'ing mtd list too this time.
From 8bc97108cf9c78216f1ea5407ccbd900e6b63dc2 Mon Sep 17 00:00:00 2001
From: Vimal Singh vimalsi...@ti.com
Date: Thu, 19 Nov 2009 19:28:11 +0530
This patch
Hi, all!
I use PM branch merged with linux-omap branch. A board is custom, so I
can't bisect this problem
(and I don't know latest working revision). It seems that's because
missing clock domain somewhere,
[16515.695617] Unable to handle kernel NULL pointer dereference at
virtual address
Hi,
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of ext
Sonasath, Moiz
Sent: 23. marraskuuta 2009 18:10
To: Kalle Jokiniemi
Cc: khil...@deeprootsystems.com; linux-omap@vger.kernel.org;
Jarkko Nikula; Paul
On Tue, Nov 24, 2009 at 01:20:26PM +, Catalin Marinas wrote:
BTW, the two patches below were mentioned to me some time ago but I
haven't got the time to look at them:
[ARM] vfp: Fix bug in vfp_pm_suspend
On Tue, Nov 24, 2009 at 8:36 PM, Artem Bityutskiy dedeki...@gmail.com wrote:
On Thu, 2009-11-19 at 19:38 +0530, Vimal Singh wrote:
Here is the v6 of this patch series. I am cc'ing mtd list too this time.
From 8bc97108cf9c78216f1ea5407ccbd900e6b63dc2 Mon Sep 17 00:00:00 2001
From: Vimal Singh
kalle.jokini...@nokia.com writes:
The patch V4 looks perfect to me :)
Great :)
So, where do we push it?
I suggest to Ben Dooks (i2c maintainer for embedded platforms) and to linux-i2c
list.
Also Cc linux-omap.
From MAINTAINERS:
I2C SUBSYSTEM
M: Jean Delvare (PC drivers, core)
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Y, Kishore
Sent: Friday, November 20, 2009 7:58 PM
To: linux-omap@vger.kernel.org
Subject: [PATCH 2/5] ZOOM: DSS2: Add nec panel for zoom display
From
Kovacs Peter Tamas wrote:
Sent: Tuesday, November 24, 2009 8:04 PM
To: linux-omap@vger.kernel.org
Subject: Enabling HSUSB1 port on OMAP3430 labrador
Dear All,
We are trying to make the HSUSB1 port on the OMAP3430 work as an USB host.
To do that, an ISP1507A ULPI HighSpeed USB transceiver
On Tue, Nov 24, 2009 at 03:04:09PM +0530, G, Manjunath Kondaiah wrote:
-Original Message-
From: Olof Johansson [mailto:o...@lixom.net]
Sent: Monday, November 23, 2009 10:36 PM
To: Govindraj; g...@lixom.net
Cc: Tony Lindgren; linux-omap@vger.kernel.org; Pandita,
Vikram;
This is a fresh look at the problem [1] discussed earlier.
Generic approach here is same; but the 'valid' flag for the
target state is verified in omap3_enter_idle_bm(). If the
valid flag == 0, we look for next (lower) state with valid
flag == 1.
Have tried to optimize the look-up without
When 'enable_off_mode' is 0, the target power state for MPU
and CORE was locally changed to PWRDM_POWER_RET but, the
statistics are updated for idle state originally selected
by the governor.
This patch 'invalidates' the idle states that lead either of
MPU or Core to PWRDM_POWER_OFF state when
-Original Message-
From: Premi, Sanjeev
Sent: Tuesday, November 24, 2009 11:20 PM
To: linux-omap@vger.kernel.org
Cc: Premi, Sanjeev
Subject: [PATCHv2 0/1] omap3: cpuidle: Update statistics for
correct state
This is a fresh look at the problem [1] discussed earlier.
Generic
If an omap_hwmod is setup using HWMOD_INIT_NO_IDLE flag, there is
currently way to idle it since omap_hwmod_idle() requires the hwmod to
be in the enabled state.
This patch adds a check to omap_hwmod_idle() so if the hwmod was has
the INIT_NO_IDLE flag, calling omap_hwmod_idle() will still
On Wed, Nov 18, 2009 at 2:51 AM, Paul Walmsley p...@pwsan.com wrote:
Hello Kevin,
On Tue, 17 Nov 2009, Kevin Hilman wrote:
Add use counters to omap_device to enable multiple potential users of
an omap_device. This is needed if ever there are multiple users or
multiple instances of a driver
Sergey Lapin slapi...@gmail.com writes:
I use PM branch merged with linux-omap branch.
Not sure what this means. PM branch is already based at linux-omap
master branch. You'll need to be more specific, ideally with commit
IDs.
A board is custom, so I can't bisect this problem (and I don't
Following the model of to_platform_device(), add to_omap_device()
macro so a platform_device pointer can be converted into an
omap_device pointer.
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/plat-omap/include/plat/omap_device.h |4 +++-
1 files changed, 3
Govindraj.R govindraj.r...@ti.com writes:
From 4756e3743c7acd2de1030b2bd432c1b19f0b9ff5 Mon Sep 17 00:00:00 2001
From: Govindraj R govindraj.r...@ti.com
Date: Fri, 13 Nov 2009 12:01:54 +0530
Subject: [PATCH] OMAP UART: Add omap-serial driver support.
This patch adds support for
Hi Paul,
In working with the UART conversion to hwmod, I noticed something I
don't see when not using hwmod for managing the UARTs.
Namely, in the idle path for PER we do disable the PER UART (via
omap_uart_prepare_for_idle(2)) and then the GPIO context is saved via
omap3_per_save_context();
FYI...
PM branch was rebased to today's linux-omap master branch (currently
v2.6.32-rc8)
As usual, the PM wiki[1] has all the details on using the PM branch as well
as some known issues.
Also note that starting with the official v2.6.32 release, I will be moving
from a continual rebase model to
Hi Kevin,
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Kevin Hilman
Hi Paul,
In working with the UART conversion to hwmod, I noticed something I
don't see when not using hwmod for managing the UARTs.
Namely, in the idle path for PER we do
Cousson, Benoit b-cous...@ti.com writes:
Hi Kevin,
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Kevin Hilman
Hi Paul,
In working with the UART conversion to hwmod, I noticed something I
don't see when not using hwmod for managing the UARTs.
This series converts the UART core and PM code to use the omap_device
layer based on the omap_hwmod layer.
This depends on the various omap_hwmod and omap_device updates from
Paul as well as omap_hwmod and omap_device patches I've sent to the
list. The 'pm-wip/omap_device' branch in my
This is temporary and will likely be replaced by autogenerated hwmods
for OMAP3.
---
arch/arm/mach-omap2/omap_hwmod_34xx.h | 188 +
1 files changed, 188 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_34xx.h
From: Govindraj R govindraj.r...@ti.com
In preparation for a new omap-serial driver, remove 8250 assumptions
and dependencies from the serial core.
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/serial.c | 202 ++---
1 files
Convert UART core and PM support to use omap_device layer. Also add
support for both console on 8250 or omap-serial driver.
omap_device conversion:
- Convert clock API calls to omap_device calls
- Remove all static platform_data setup and configuration. This is
all done by the omap_device
Govindraj.R govindraj.r...@ti.com writes:
From 4756e3743c7acd2de1030b2bd432c1b19f0b9ff5 Mon Sep 17 00:00:00 2001
From: Govindraj R govindraj.r...@ti.com
Date: Fri, 13 Nov 2009 12:01:54 +0530
Subject: [PATCH] OMAP UART: Add omap-serial driver support.
This patch adds support for
From: Kevin Hilman [khil...@deeprootsystems.com]
Sent: Tuesday, November 24, 2009 11:57 PM
To: Sergey Lapin; Premi, Sanjeev
Cc: linux-omap@vger.kernel.org
Subject: Re: OMAP3: enabling CPU idle leads to panic
Sergey Lapin slapi...@gmail.com writes:
I use PM branch merged with linux-omap branch.
The function mipid_spi_remove is used only wrapped by __devexit_p so
define it using __devexit.
Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de
Cc: Arnaud Patard arnaud.pat...@rtp-net.org
Cc: Andrew Morton a...@linux-foundation.org
Cc: Mike Wege ext-mike.w...@nokia.com
Cc: Imre
From: Madhusudhan Chikkature madhu...@ti.com
Subject: [PATCH] Zoom2/3:Update hsmmc board config params.
Update the hsmmc zoom peripheral configuration to support:
Power saving mode
mmc2 8-bit support
Configure mmc2 as non removable
Signed-off-by: Madhusudhan Chikkature madhu...@ti.com
---
The patch corrects the issue introduced with one of my earlier patches:
OMAP: DMA: Fix omapfb/lcdc on OMAP1510 broken when PM set[1]
as pointed out by OMAP subsystem maintainer.
Applies on top of my prevoius patch:
OMAP: DMA: move LCD DMA related code from plat-omap to mach-omap1[2]
Hi,
Here is V3 of the patch series. What changed in V3:
* Major rewrite of OPP APIs. This includes changes from offline
discussions with lots of folks and taking in l-o comments - all
patches have changed as a result.
* rebased to latest lo-pm
V2:
Move the definitions from omap3-opp.h to pm34xx.c. The definitions
are now based on omap_opp_def instead of omap_opp itself.
Since the opp.h has the omap_opp definition, omap-pm.h conflicts and
has been removed in favor of opp.h.
omap3_pm_init_opp_table is used to initialize the OPP table and
enable the OPP tables for 3630 platforms: SDP3630, zoom3.
NOTE: This needs the corresponding clockframework changes.
Currently this dumps the following on OPP transitions on SDP3630:
[c002d734] (dump_backtrace+0x0/0x110) from [c02c9698] (dump_stack+0x18/0x1c)
r7: r6:c003bff8 r5:c034a227
We used to enable and disable OPPs based on rate being set to 0, this
has been confusing in general. So, we now allow specific OPPs to be
now enabled/disabled by an explicit enabled flag instead of re-using
rate flag itself.
Tested on: SDP3430
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman
Modifies the initial patch From Sanjeev:
http://patchwork.kernel.org/patch/50998/
Discussions and comments from:
http://marc.info/?l=linux-omapm=125482970102327w=2
http://marc.info/?t=12580924752r=1w=2
incorporated.
OMAP SOCs have a standard set of tuples consisting of frequency and
voltage
SmartReflex implements a get_opp to search through the opp table,
replace it opp_is_valid to verify the OPPs and getting the opp_id.
NOTE: usage of opp_id is deprecated and this introduces the following
warnings:
arch/arm/mach-omap2/smartreflex.c: In function 'get_vdd1_opp':
Since accessor functions are used through out, we dont depend
on the predefined macros to know the limits of the opp table.
Hence, remove these.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Madhusudhan Chikkature Rajashekar madhu...@ti.com
Cc: Paul Walmsley
The logic in omap-target can now be improved with the accessor
functions. Dont scan through the list manually, instead use
get_next_freq to do the scanning.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Madhusudhan Chikkature Rajashekar madhu...@ti.com
Cc:
omap2_clk_init_cpufreq_table currently directly accesses the opp
table, making it unscalable to various OMAPs. Instead use the
accessor functions to populate the cpufreq table
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Madhusudhan Chikkature Rajashekar
With the accessor functions, many of the direct accesses are
redundant. However we do not want to rewrite SRF at this point of time
We do the following here:
Remove get_opp and introduce three SRF specific accessor functions:
opp_to_freq, freq_to_opp - need this coz of usage of opp IDs
Introduce the OMAP3630 OPPs including the defined OPP tuples.
Further information on OMAP3630 can be found here:
http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateId=6123navigationId=12836contentId=52606
OMAP36xx family introduces:
VDD1 with 4 OPPs, of which OPP3 4 are
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Olof Johansson
Sent: Tuesday, November 24, 2009 10:52 PM
To: G, Manjunath Kondaiah
Cc: Govindraj; g...@lixom.net; Tony Lindgren; linux-
o...@vger.kernel.org; Pandita,
-Original Message-
From: Shilimkar, Santosh
Sent: Wednesday, November 25, 2009 12:06 PM
To: Olof Johansson; G, Manjunath Kondaiah
Cc: Govindraj; g...@lixom.net; Tony Lindgren;
linux-omap@vger.kernel.org; Pandita, Vikram; Raja, Govindraj
Subject: RE: [PATCHv3 0/3] OMAP UART:
G, Manjunath Kondaiah wrote:
You should allow both of them to be enabled at the same time, so the
same
kernel can for example be booted on a ZOOM2 with debug board
attached
(8250 on GPMC), or on a beagle/overo board.
Making them exclusive would be a step backwards.
More so, selecting
61 matches
Mail list logo
