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
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
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.
>
From: Eduardo Valentin
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 the platform:
CS0: for 38.4M
From: Tero Kristo
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 the wild]
Signed-off-b
From: Tero Kristo
Currently this is done during initialization. move this to just before
wfi call in omap_sram_idle.
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/pm34xx.c | 35 ++-
1 files changed, 14 insertions(+), 21 deletions(-)
diff --git a/arch/arm
From: Eduardo Valentin
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 thing ROM code does after
From: Peter 'p2' De Schrijver
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 errata. this is a support logic f
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 d
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 o
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
---
arch/arm/mach-omap2/pm34xx.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx
From: Eduardo Valentin
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 current W/A we have for i540,
From: Archana Sriram
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., UART3 FIFO) does not
work
From: Richard Woodruff
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 isn't a good alter
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
s
From: Tero Kristo
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 process compared to the tra
From: Peter 'p2' De Schrijver
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 OMAP3430, this is done in th
Benoit,
On Thu, Nov 18, 2010 at 5:28 PM, Cousson, Benoit 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 the bit
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 Kanigeri
---
arch/arm/mach-omap2/mailbox.c |5 +++
On 11/18/2010 8:15 PM, Kanigeri, Hari wrote:
From: Fernando Guzman Lugo
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.
Ver
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
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 Kanigeri
---
arch/arm/mac
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
* Cousson, Benoit [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;
>
* Cousson, Benoit [101118 12:56]:
> On 11/18/2010 8:06 PM, Tony Lindgren wrote:
> >* sricharan [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 th
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 <
On 11/18/2010 8:06 PM, Tony Lindgren wrote:
* sricharan [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.
2. Do PAD
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 serie
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
---
arch/arm/mach-omap2/clock44xx_data.c |1 +
1 files changed, 1 ins
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
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
---
arch/arm/plat-omap/mailbox.c |
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
---
arch/arm/mach-omap2/mailbox.c |5 -
1 files changed, 4 insertions(+), 1 deleti
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
http://www.spinics.net/l
Fix the checkpatch warnings observed in mailbox module
Signed-off-by: Hari Kanigeri
---
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 9ce3570..abfc495 100644
--- a/ar
From: Fernando Guzman Lugo
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 protection. When th
* Paul Mundt [101118 10:29]:
> On Thu, Nov 18, 2010 at 08:44:14AM -0800, Tony Lindgren wrote:
> > * Paul Mundt [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
* sricharan [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.
> 2. Do PAD configuration independently for each m
* sricharan [101114 23:26]:
> Use the mux framework to initialise the mmc mux pins.
>
> Signed-off-by: sricharan
> ---
> arch/arm/mach-omap2/devices.c | 83
> +
> 1 files changed, 83 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/d
On Thu, Nov 18, 2010 at 08:44:14AM -0800, Tony Lindgren wrote:
> * Paul Mundt [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 wish we cou
On Thu, Nov 18, 2010 at 7:27 PM, Tony Lindgren wrote:
> * Jean Pihet [101118 10:06]:
>> On Thu, Nov 18, 2010 at 6:52 PM, Tony Lindgren 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
* Jean Pihet [101118 10:06]:
> On Thu, Nov 18, 2010 at 6:52 PM, Tony Lindgren 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 the DPLL is already locked. Note: l
On Thu, Nov 18, 2010 at 6:41 PM, Tony Lindgren wrote:
> * Jean Pihet [101118 06:43]:
>> From: Vishwanath BS
>>
>> 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 reada
On Thu, Nov 18, 2010 at 6:52 PM, Tony Lindgren wrote:
> * Nishanth Menon [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
* Tony Lindgren [101118 09:42]:
> * Nishanth Menon [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
* Sukumar Ghorai [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
> ---
> drivers/mtd/nand/omap2.c |1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git
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 stat
Delete a redundant local variable.
Signed-off-by: Aaro Koskinen
---
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
--- a/arch/arm/mach-omap2/ti
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] *membase
arch/arm/mach-om
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
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 s
Delete unused variable from probe().
Signed-off-by: Aaro Koskinen
---
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
--- a/arch/arm/mach-omap1/mailb
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 static
Hi Dan,
* Dan Murphy [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 (board_mux->reg
* Nishanth Menon [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. For l
* Jean Pihet [101118 06:43]:
> From: Vishwanath BS
>
> 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,
> - add
Kevin Hilman had written, on 11/18/2010 09:52 AM, the following:
Nishanth Menon writes:
From: Vishwanath BS
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 ZOOM
* Paul Mundt [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 and the boa
Nishanth Menon writes:
>> From: Vishwanath BS
>>
>> 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 a
> -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.
> >> >
> >> >
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
> ---
> Version2:
>- Using kstrdup() instead of kmalloc() & strcpy()
>- Using ENOMEM as error code instead of EINVAL
>-
Hi Nishant,
On Thu, Nov 18, 2010 at 4:11 PM, Nishanth Menon 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
> Pihe
> -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
>
> NIsha
NIshant,
On Thu, Nov 18, 2010 at 8:27 PM, Nishanth Menon 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: Vishw
> -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: mov
From: Vishwanath BS
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 errata workarounds,
-
From: Vishwanath BS
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.
Signed-off-by: Vishwanath BS
Cc
Vishwanath BS , Jean Pihet :
[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.
Tested on ZOOM3, OMAP3EVM, Beagleboard
> -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.
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
---
drivers/mtd/nand/omap2.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.
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 BUG_
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
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
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 dri
On Thu, 2010-11-18 at 09:45 +0800, ext Bryan Wu wrote:
> Signed-off-by: Bryan Wu
> ---
> 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
> b/drivers/video/om
74 matches
Mail list logo
