On Thu, 2010-11-18 at 09:45 +0800, ext Bryan Wu wrote:
Signed-off-by: Bryan Wu bryan...@canonical.com
---
drivers/video/omap2/displays/panel-generic-dpi.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c
On Thu, 2010-11-18 at 10:14 +0800, ext Bryan Wu wrote:
On Wed, Nov 17, 2010 at 10:18 PM, Tomi Valkeinen
Are you also interested in solving the backlight issue? =)
Yeah, can I start with
drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c. I plan to move
the blacklight code to
Ordinary I2C read consist of two messages. First a write operation
to tell register address and then read operation to get data.
CPU wake up latency is set and removed twice in read case.
Set latency requirement before the message processing loop
and remove the requirement after the loop to remove
Certain errata's in OMAP2+ processors will require forcing
master standby to no standby mode before completing on going
operation. Without this, the results will be unpredictable.
Since current implementation of PM run time framework does not support
changing sysconfig settings during middle of
Thomas Petazzoni had written, on 11/16/2010 07:20 AM, the following:
would prevent you from having no OPP table (the case where a NULL OPP
table is passed is tested *before* in omapX_init_opp()).
HUH?? NULL table to a static function - what code are you talking
about?? why are you so behind
CONFIG_MTD_NAND_OMAP_HWECC defined wronly in patch submitted during 2.6.36
that using the hardware ECC by default
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
drivers/mtd/nand/omap2.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Charles Manning
Sent: Thursday, November 18, 2010 6:36 AM
To: linux-omap@vger.kernel.org
Subject: No more software ECC in omap2.c NAND driver. Why?
Between 2.6.35
Vishwanath BS vishwanath...@ti.com, Jean Pihet j-pi...@ti.com:
[PATCH 1/2]: OMAP3 PM: move omap3 sleep to ddr
For historical reasons the OMAP3 sleep code is run from SRAM.
This code can run from DDR which provides better performance and
leaves the SRAM available for other uses.
From: Vishwanath BS vishwanath...@ti.com
For historical reasons the OMAP3 sleep code is run from SRAM.
This code can run from DDR which provides better performance and
leaves the SRAM available for other uses.
Tested on ZOOM3, OMAP3EVM, Beagleboard, n900
with full RET and OFF modes.
From: Vishwanath BS vishwanath...@ti.com
Clean up of the ASM code:
- reworked and simplified the execution paths, for better
readability and to avoid duplication of code,
- reworked the comments for better readability,
- reworked the code formating and alignment,
- added comments for the i443
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Jean Pihet
Sent: Thursday, November 18, 2010 8:52 AM
To: linux-omap@vger.kernel.org
Cc: Vishwanath BS; Kevin Hillman; Jean Pihet
Subject: [PATCH 1/2] OMAP3 PM: move
NIshant,
On Thu, Nov 18, 2010 at 8:27 PM, Nishanth Menon n...@ti.com wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Jean Pihet
Sent: Thursday, November 18, 2010 8:52 AM
To: linux-omap@vger.kernel.org
Cc:
-Original Message-
From: Sripathy, Vishwanath [mailto:vishwanath...@ti.com]
Sent: Thursday, November 18, 2010 9:09 AM
To: Nishanth Menon
Cc: Jean Pihet; linux-omap@vger.kernel.org; Kevin Hillman; Jean
Pihet-XID
Subject: Re: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
NIshant,
Hi Nishant,
On Thu, Nov 18, 2010 at 4:11 PM, Nishanth Menon n...@ti.com wrote:
-Original Message-
From: Sripathy, Vishwanath [mailto:vishwanath...@ti.com]
Sent: Thursday, November 18, 2010 9:09 AM
To: Nishanth Menon
Cc: Jean Pihet; linux-omap@vger.kernel.org; Kevin Hillman; Jean
On Tue, 2010-11-16 at 12:49 +0100, ext Samreen wrote:
A null pointer check added. And using kstrdup()
instead of kmalloc() strcpy()
Signed-off-by: Samreen samr...@ti.com
---
Version2:
- Using kstrdup() instead of kmalloc() strcpy()
- Using ENOMEM as error code instead of EINVAL
-Original Message-
From: Jean Pihet [mailto:jean.pi...@newoldbits.com]
Sent: Thursday, November 18, 2010 9:15 AM
[...]
Tested on ZOOM3, OMAP3EVM, Beagleboard, n900
with full RET and OFF modes.
Sorry, But I disagree with this patch.
There is a silicon errata which
Nishanth Menon n...@ti.com writes:
From: Vishwanath BS vishwanath...@ti.com
For historical reasons the OMAP3 sleep code is run from SRAM.
This code can run from DDR which provides better performance and
leaves the SRAM available for other uses.
Tested on ZOOM3, OMAP3EVM, Beagleboard, n900
* Paul Mundt let...@linux-sh.org [101117 22:09]:
On Wed, Nov 17, 2010 at 02:28:11PM +0200, Tomi Valkeinen wrote:
On Tue, 2010-11-16 at 21:10 +0100, ext Tony Lindgren wrote:
Sure a module would be even better. My point is that the selection of
all the features should be enabled by default
Kevin Hilman had written, on 11/18/2010 09:52 AM, the following:
Nishanth Menon n...@ti.com writes:
From: Vishwanath BS vishwanath...@ti.com
For historical reasons the OMAP3 sleep code is run from SRAM.
This code can run from DDR which provides better performance and
leaves the SRAM available
* Jean Pihet jean.pi...@newoldbits.com [101118 06:43]:
From: Vishwanath BS vishwanath...@ti.com
Clean up of the ASM code:
- reworked and simplified the execution paths, for better
readability and to avoid duplication of code,
- reworked the comments for better readability,
- reworked
* Nishanth Menon n...@ti.com [101118 08:46]:
But after wfi in wait_sdrc_ok as part of the code executing in SRAM
today omap34xx_cpu_suspend - we are waiting for DPLL3 lock prior to
accessing DDR - how do we execute that logic in SDRAM?
I too am a bit concerned how this will all keep working.
Hi Dan,
* Dan Murphy dmur...@ti.com [101117 09:58]:
@@ -81,10 +81,14 @@ void omap_mux_write(struct omap_mux_partition *partition,
u16 val,
void omap_mux_write_array(struct omap_mux_partition *partition,
struct omap_board_mux *board_mux)
{
- while
Make some functions static to get rid of the following sparse warnings:
arch/arm/mach-omap1/mcbsp.c:177:12: warning: symbol 'omap1_mcbsp_init'
was not declared. Should it be static?
arch/arm/mach-omap1/mux.c:346:22: warning: symbol 'omap1_cfg_reg' was
not declared. Should it be
Delete unused variable from probe().
Signed-off-by: Aaro Koskinen aaro.koski...@nokia.com
---
arch/arm/mach-omap1/mailbox.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap1/mailbox.c b/arch/arm/mach-omap1/mailbox.c
index 12d6880..c0e1f48 100644
---
Make some variables static to get rid of the following warnings:
arch/arm/mach-omap1/mailbox.c:136:18: warning: symbol 'mbox_dsp_info'
was not declared. Should it be static?
arch/arm/mach-omap1/mailbox.c:142:18: warning: symbol 'omap1_mboxes'
was not declared. Should it be
Delete a redundant local variable.
Signed-off-by: Aaro Koskinen aaro.koski...@nokia.com
---
arch/arm/mach-omap2/timer-gp.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/timer-gp.c b/arch/arm/mach-omap2/timer-gp.c
index e13c29e..f9052e1 100644
---
Use IOMEM() macro to get rid of the following sparse warning:
arch/arm/mach-omap1/board-ams-delta.c:319:36: warning: incorrect type
in initializer (different address spaces)
arch/arm/mach-omap1/board-ams-delta.c:319:36:expected void
[noderef] asn:2*membase
Some small OMAP cleanups to eliminate noise from compilation/sparse
checks:
Aaro Koskinen (6):
arm: omap1: add missing includes
arm: omap1: make some functions static
arm: omap1: mbox: make variables static
arm: omap1: mbox: delete unused variable
arm: omap1: board-ams-delta: fix cast
Add missing includes to get rid of the following sparse warnings:
arch/arm/mach-omap1/devices.c:225:13: warning: symbol
'omap1_camera_init' was not declared. Should it be static?
arch/arm/mach-omap1/flash.c:15:6: warning: symbol 'omap1_set_vpp' was
not declared. Should it be
* Sukumar Ghorai s-gho...@ti.com [101118 06:12]:
CONFIG_MTD_NAND_OMAP_HWECC defined wronly in patch submitted during 2.6.36
that using the hardware ECC by default
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
drivers/mtd/nand/omap2.c |1 -
1 files changed, 0 insertions(+), 1
* Tony Lindgren t...@atomide.com [101118 09:42]:
* Nishanth Menon n...@ti.com [101118 08:46]:
But after wfi in wait_sdrc_ok as part of the code executing in SRAM
today omap34xx_cpu_suspend - we are waiting for DPLL3 lock prior to
accessing DDR - how do we execute that logic in SDRAM?
On Thu, Nov 18, 2010 at 6:52 PM, Tony Lindgren t...@atomide.com wrote:
* Nishanth Menon n...@ti.com [101118 08:46]:
But after wfi in wait_sdrc_ok as part of the code executing in SRAM
today omap34xx_cpu_suspend - we are waiting for DPLL3 lock prior to
accessing DDR - how do we execute that
On Thu, Nov 18, 2010 at 6:41 PM, Tony Lindgren t...@atomide.com wrote:
* Jean Pihet jean.pi...@newoldbits.com [101118 06:43]:
From: Vishwanath BS vishwanath...@ti.com
Clean up of the ASM code:
- reworked and simplified the execution paths, for better
readability and to avoid duplication
* Jean Pihet jean.pi...@newoldbits.com [101118 10:06]:
On Thu, Nov 18, 2010 at 6:52 PM, Tony Lindgren t...@atomide.com wrote:
About the DPLL lock:
1) wait_sdrc_ok is only called when back from the non-OFF modes,
2) I checked that when running wait_sdrc_ok the CORE is already out of
idle and
On Thu, Nov 18, 2010 at 7:27 PM, Tony Lindgren t...@atomide.com wrote:
* Jean Pihet jean.pi...@newoldbits.com [101118 10:06]:
On Thu, Nov 18, 2010 at 6:52 PM, Tony Lindgren t...@atomide.com wrote:
About the DPLL lock:
1) wait_sdrc_ok is only called when back from the non-OFF modes,
2) I
On Thu, Nov 18, 2010 at 08:44:14AM -0800, Tony Lindgren wrote:
* Paul Mundt let...@linux-sh.org [101117 22:09]:
Unless you can say with certainty that all OMAP3 boards are going to want
DSS enabled or modular by default, it's almost always better to just
leave it up to the defconfigs.
I
* sricharan r.sricha...@ti.com [101114 23:26]:
Use the mux framework to initialise the mmc mux pins.
Signed-off-by: sricharan r.sricha...@ti.com
---
arch/arm/mach-omap2/devices.c | 83
+
1 files changed, 83 insertions(+), 0 deletions(-)
diff
* sricharan r.sricha...@ti.com [101114 23:26]:
This series updates the core device drivers to use mux framework
for OMAP4 SDP and PANDA board. It's generated against the
linux-omap master branch. It has a dependency on the Benoit's
omap4 mux data series.
snip
2. Do PAD configuration
* Paul Mundt let...@linux-sh.org [101118 10:29]:
On Thu, Nov 18, 2010 at 08:44:14AM -0800, Tony Lindgren wrote:
* Paul Mundt let...@linux-sh.org [101117 22:09]:
Unless you can say with certainty that all OMAP3 boards are going to want
DSS enabled or modular by default, it's almost always
Fix the checkpatch warnings observed in mailbox module
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
---
arch/arm/plat-omap/mailbox.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index
From: Fernando Guzman Lugo x0095...@ti.com
As pointed by Ohad Ben-Cohen, the variable rq_full flag is a
global variable, so if there are multiple mailbox users
there will be conflics. Now there is a full flag per
mailbox queue.
Version 2:
- Rebase to the latest.
Version 3:
- Remove spin_lock
disabling rx interrupt on omap4 is different than its pre-decessors.
The bit in OMAP4_MAILBOX_IRQENABLE_CLR should be set to disable the
interrupts instead of clearing the bit.
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
---
arch/arm/mach-omap2/mailbox.c |5 -
1 files changed, 4
Sending the patch set by seperating the clock related patch seperated
out based on Paul Walmsey's comment.
http://www.spinics.net/lists/arm-kernel/msg103692.html
The clock patch will be sent out as a seperate patch.
The previous versions of this patch set can be found here
Schedule the Tasklet to send only when mailbox fifo is full and there are
pending messages in kifo, else send the message directly in the Process
context. This would avoid needless scheduling of Tasklet for every message
transfer
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
---
In the current mailbox driver, the mailbox internal pointer for
callback can be directly manipulated by the Users, so a second
User can easily corrupt the first user's callback pointer.
The initial effort to correct this issue can be referred here:
https://patchwork.kernel.org/patch/107520/
Along
In omap4, there is no explicit configuration register to enable mailbox clocks.
Defining dummy clock for mailbox clock module to keep the mailbox driver
backward compatible with previous omaps.
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
---
arch/arm/mach-omap2/clock44xx_data.c |1 +
1
Hi Tony,
On 11/18/2010 6:57 PM, Tony Lindgren wrote:
Hi Dan,
[...]
Can you please make this into a separate patch. And instead of
indenting the code more, just do something like:
if (!partition)
return -EINVAL;
Do you want me to merge that in my current OMAP4
On 11/18/2010 8:06 PM, Tony Lindgren wrote:
* sricharanr.sricha...@ti.com [101114 23:26]:
This series updates the core device drivers to use mux framework
for OMAP4 SDP and PANDA board. It's generated against the
linux-omap master branch. It has a dependency on the Benoit's
omap4 mux data
All,
I have a 2.6.32 kernel based on the L23.i3.3 kernel (2.6.32) from TI,
and I've run into an interesting problem with UART3 (maps to /dev/ttyS1
on the Torpedo board).
On the host I have it hooked up to /dev/ttyS1, so I turn on CTS/RTS and
set the baudrate by:
host$ stty 115200 crtscts
* Cousson, Benoit b-cous...@ti.com [101118 12:56]:
On 11/18/2010 8:06 PM, Tony Lindgren wrote:
* sricharanr.sricha...@ti.com [101114 23:26]:
This series updates the core device drivers to use mux framework
for OMAP4 SDP and PANDA board. It's generated against the
linux-omap master branch. It
* Cousson, Benoit b-cous...@ti.com [101118 12:52]:
Hi Tony,
On 11/18/2010 6:57 PM, Tony Lindgren wrote:
Hi Dan,
[...]
Can you please make this into a separate patch. And instead of
indenting the code more, just do something like:
if (!partition)
return -EINVAL;
I am working with a board that deviates from what seems to be common
OMAP-as-clock-slave-from-the-TWL4030-PMIC-clock-master practice. In order to
get this board to work correctly when used with SmartReflex-enabled, I had to
add the following to the board initialization function:
/* In this
Hi Hari,
On 11/18/2010 8:20 PM, Kanigeri, Hari wrote:
In omap4, there is no explicit configuration register to enable mailbox clocks.
Defining dummy clock for mailbox clock module to keep the mailbox driver
backward compatible with previous omaps.
Signed-off-by: Hari Kanigerih-kanige...@ti.com
Benoit,
OK, that one is easy but... I will still have to update the script to
generate it, so:
Sure, thank you.
Best regards,
Hari Kanigeri
--
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
On 11/18/2010 8:15 PM, Kanigeri, Hari wrote:
From: Fernando Guzman Lugox0095...@ti.com
As pointed by Ohad Ben-Cohen, the variable rq_full flag is a
global variable, so if there are multiple mailbox users
there will be conflics. Now there is a full flag per
mailbox queue.
Version 2:
- Rebase to
On 11/18/2010 8:15 PM, Hari Kanigeri wrote:
disabling rx interrupt on omap4 is different than its pre-decessors.
The bit in OMAP4_MAILBOX_IRQENABLE_CLR should be set to disable the
interrupts instead of clearing the bit.
Signed-off-by: Hari Kanigerih-kanige...@ti.com
---
Benoit,
On Thu, Nov 18, 2010 at 5:28 PM, Cousson, Benoit b-cous...@ti.com wrote:
On 11/18/2010 8:15 PM, Hari Kanigeri wrote:
disabling rx interrupt on omap4 is different than its pre-decessors.
The bit in OMAP4_MAILBOX_IRQENABLE_CLR should be set to disable the
interrupts instead of clearing
Bunch of fixes as part of phase 1 targetting mainly OMAP3630 HS devices
for OFF mode logic.
It is important to note - for proper functionality of HS OFF mode on OMAP3630,
CONFIG_OMAP3_L2_AUX_SECURE_SAVE_RESTORE=y and
CONFIG_OMAP3_L2_AUX_SECURE_SERVICE_SET_ID should be set to the correct
From: Tero Kristo tero.kri...@nokia.com
Currently memory is allocated from kernel heap, which is located at high-mem.
Low-mem allocation is needed due to limitation in ROMCode which mirrors
memory every 256MB of memory blocks back to the first block
Allocation needs to be done later in the
From: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com
This disables L2 cache before invalidating it and reenables it afterwards.
This is be done according to ARM documentation. Currently this is identified
as being needed on OMAP3630 as the disable enable is done from public side
while, on
From: Richard Woodruff r-woodru...@ti.com
Analysis in TI kernel with ETM showed that using cache mapped flush
in kernel instead of SO mapped flush cost drops by 65% (3.39mS down
to 1.17mS) for clean_l2 which is used during sleep sequences.
Overall:
- speed up
- unfortunately there
From: Eduardo Valentin eduardo.valen...@nokia.com
We need to disable the autoidle bit from MPU INTC,
otherwise INTC would get stall, and we would never
come out of WFI. This must be done before save secure ram
as well because save secure ram also does WFI.
This patch is just a addition to the
From: Archana Sriram archana.sri...@ti.com
Errata Id:i582
PER Domain reset issue after Domain-OFF/OSWR Wakeup.
Issue:
When Peripheral Power Domain (PER-PD) is woken up from OFF / OSWR
state while Core Power Domain (CORE-PD) is kept active, write or
read access to some internal memory (e.g.,
OMAP3 users of HS/EMU devices at times choose to use their
own PPA which could be configured to use different sized storage
area based on their security needs. Convert the hardcoded size
define to a more configurable form to map to these users. we introduce
the structure omap3_secure_copy_data to
Errata id: i608
RTA (Retention Till Access) feature is not supported and leads to device
stability issues when enabled. This impacts modules with embedded memories
on OMAP3630
Workaround is to disable RTA on boot and coming out of core off.
For disabling rta coming out of off mode, we do this by
Use TI recommended save_secure_ram size for OMAP3 using TI official
OMAP3 PPA. Note: custom platforms may have different save sizes.
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/pm34xx.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git
From: Tero Kristo tero.kri...@nokia.com
Currently this is done during initialization. move this to just before
wfi call in omap_sram_idle.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
---
arch/arm/mach-omap2/pm34xx.c | 35 ++-
1 files changed, 14
From: Eduardo Valentin eduardo.valen...@nokia.com
Deny MPU idle before save secure ram and allow it after save secure RAM.
We want to deny MPU going to low power state because, there is a short
time window where a wakeup event would happen around the time the MPU
is going to idle. Since the first
From: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com
Errata i581 impacts OMAP3 platforms.
PRCM DPLL control FSM removes SDRC_IDLEREQ before DPLL3 locks causing
the DPLL not to be locked at times.
IMPORTANT: this is not a complete workaround implementation as recommended
by the silicon
From: Eduardo Valentin eduardo.valen...@nokia.com
Limitation i583: Self_Refresh Exit issue after OFF mode
Issue:
When device is waking up from OFF mode, then SDRC state machine sends
inappropriate sequence violating JEDEC standards.
Impact:
OMAP3630 ES1.2 is impacted as follows depending on
From: Tero Kristo tero.kri...@nokia.com
Some PPAs now supports saving secure RAM context several times.
Now we will save it before every core off cycle.
board files can register with params to allow configuration based
on the PPA used.
[...@ti.com: converted to struct option for various PPAs in
Hi Benoît,
On Tue, 16 Nov 2010, Cousson, Benoit wrote:
Funny, I was about to send you a RFC to get rid of that mutex :-)
Today that mutex is preventing us to be re-entrant during hwmod lookup and
for_each_by_class iteration, and we'd like to in order to manage link between
2 hwmods.
The
On Thu, Nov 18, 2010 at 04:21:48PM +0530, G, Manjunath Kondaiah wrote:
Certain errata's in OMAP2+ processors will require forcing
master standby to no standby mode before completing on going
operation. Without this, the results will be unpredictable.
Since current implementation of PM run
Certain errata's in OMAP2+ processors will require forcing
master standby to no standby mode before completing on going
operation. Without this, the results will be unpredictable.
Since current implementation of PM run time framework does not support
changing sysconfig settings during middle of
74 matches
Mail list logo
