Felipe,
On Fri, Nov 19, 2010 at 5:07 PM, Felipe Balbi wrote:
> Hi Hari,
>
> On Fri, 2010-11-19 at 08:44 -0600, Kanigeri, Hari wrote:
>> Not really :). Please let me know if if I am wrong, what you
>> addressing is getting the confirmation that a message is sent and what
>> I am addressing with th
Hi Hari,
On Fri, 2010-11-19 at 08:44 -0600, Kanigeri, Hari wrote:
> Not really :). Please let me know if if I am wrong, what you
> addressing is getting the confirmation that a message is sent and what
> I am addressing with the patch is that a response is received from
> M3/DSP.
You got it wrong
Kevin Hilman had written, on 11/19/2010 03:20 PM, the following:
Request for testing this series for comparison between master and this
series requested for additional platforms where available.
I haven't yet been through the entire series, but some general comments
to share before the weekend
Nishanth Menon writes:
> 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_
Kevin Hilman had written, on 11/19/2010 03:06 PM, the following:
Nishanth Menon writes:
Kevin Hilman had written, on 11/19/2010 02:39 PM, the following:
[...]
In addtion, the patch from Santosh needs to better describe what other
problems it is solving, since it is clearly not fixing this par
Nishanth Menon writes:
> Kevin Hilman had written, on 11/19/2010 02:55 PM, the following:
> [...]
>> Now, based on what you say below, it seems like there is no way to
>> guarantee that SMIs don't do this, so I guess we have no choice but to
>> protect them all.
> In that way, I do like the patch
Nishanth Menon writes:
> Kevin Hilman had written, on 11/19/2010 02:39 PM, the following:
> [...]
>> In addtion, the patch from Santosh needs to better describe what other
>> problems it is solving, since it is clearly not fixing this particular
>> secure mode entry. Therefore, there must be oth
Kevin Hilman had written, on 11/19/2010 02:55 PM, the following:
[...]
Now, based on what you say below, it seems like there is no way to
guarantee that SMIs don't do this, so I guess we have no choice but to
protect them all.
In that way, I do like the patch from Santosh - with the relevant
cha
Nishanth Menon writes:
> Kevin Hilman had written, on 11/19/2010 01:41 PM, the following:
>
I believe the fix we are attempting here is for a specific scenario
which IMHO is different from the issue solved in the link above.
>>> It will also solve the above issue indirectly.
>>
>> Yes,
Kevin Hilman had written, on 11/19/2010 02:39 PM, the following:
[...]
In addtion, the patch from Santosh needs to better describe what other
problems it is solving, since it is clearly not fixing this particular
secure mode entry. Therefore, there must be others that are also doing
WFI. That
> -Original Message-
> From: Grazvydas Ignotas [mailto:nota...@gmail.com]
> Sent: Friday, November 19, 2010 4:06 PM
> To: Ghorai, Sukumar
> Cc: Charles Manning; linux-omap@vger.kernel.org
> Subject: Re: No more software ECC in omap2.c NAND driver. Why?
>
> On Thu, Nov 18, 2010 at 4:33 PM
Nishanth Menon writes:
> Santosh Shilimkar had written, on 11/19/2010 11:28 AM, the following:
>>> -Original Message-
>>> From: Nishanth Menon [mailto:n...@ti.com]
>>> Sent: Friday, November 19, 2010 10:55 PM
>>> To: Santosh Shilimkar
>>> Cc: Kevin Hilman; linux-omap; Jean Pihet; Vishwana
Kevin Hilman had written, on 11/19/2010 01:41 PM, the following:
I believe the fix we are attempting here is for a specific scenario
which IMHO is different from the issue solved in the link above.
It will also solve the above issue indirectly.
Yes, it indirectly fixes the issue solved by $SU
Kevin Hilman had written, on 11/19/2010 01:47 PM, the following:
Nishanth Menon writes:
Kevin Hilman had written, on 11/19/2010 11:15 AM, the following:
Nishanth Menon writes:
From: Eduardo Valentin
We need to disable the autoidle bit from MPU INTC,
otherwise INTC would get stall, and we
Nishanth Menon writes:
> Kevin Hilman had written, on 11/19/2010 11:15 AM, the following:
>> Nishanth Menon writes:
>>
>>> 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 d
Santosh Shilimkar writes:
>> -Original Message-
>> From: Nishanth Menon [mailto:n...@ti.com]
>> Sent: Friday, November 19, 2010 10:55 PM
>> To: Santosh Shilimkar
>> Cc: Kevin Hilman; linux-omap; Jean Pihet; Vishwanath Sripathy; Tony
>> Subject: Re: [PATCH 08/13] OMAP3: PM: Deny MPU idle w
Santosh Shilimkar had written, on 11/19/2010 11:28 AM, the following:
-Original Message-
From: Nishanth Menon [mailto:n...@ti.com]
Sent: Friday, November 19, 2010 10:55 PM
To: Santosh Shilimkar
Cc: Kevin Hilman; linux-omap; Jean Pihet; Vishwanath Sripathy; Tony
Subject: Re: [PATCH 08/13]
On Fri, 2010-11-19 at 17:31 +, Santosh Shilimkar wrote:
> This patch adds the PL310 Auxiliary Control Register bitfields
> so that SOC's can use these bit fields to construct the AUXCTRL
> value to be passed/programmed instead of hardcoding it.
>
> Signed-off-by: Santosh Shilimkar
> Cc: Catal
Santosh Shilimkar writes:
> The AXI protocol specifies that the write response can only
> be sent back to an AXI master when the last write data has been
> accepted. This optimization enables the PL310 to send the write
> response of certain write transactions as soon as the store buffer
> accept
* Dan Murphy [101117 09:58]:
> --- a/arch/arm/mach-omap2/mux.c
> +++ b/arch/arm/mach-omap2/mux.c
>
> +static struct omap_mux *omap_mux_get_by_mux(struct omap_mux_partition
> *partition,
> + char *name)
> +{
> + struct omap_mux_entry *e;
> + int i = 0;
This patch adds the PL310 Auxiliary Control Register bitfields
so that SOC's can use these bit fields to construct the AUXCTRL
value to be passed/programmed instead of hardcoding it.
Signed-off-by: Santosh Shilimkar
Cc: Catalin Marinas
---
arch/arm/include/asm/hardware/cache-l2x0.h | 12 +
This patch removes the hardcoded value of auxctrl value and
construct it using bitfields
Bit 25 is reserved and is always set to 1. Same value
of this bit is retained in this patch
Signed-off-by: Santosh Shilimkar
Tested-by: Nishanth Menon
---
arch/arm/mach-omap2/omap4-common.c | 13
The AXI protocol specifies that the write response can only
be sent back to an AXI master when the last write data has been
accepted. This optimization enables the PL310 to send the write
response of certain write transactions as soon as the store buffer
accepts the write address. This behavior is
Clearing bit 22 in the PL310 Auxiliary Control register (shared
attribute override enable) has the side effect of transforming Normal
Shared Non-cacheable reads into Cacheable no-allocate reads.
Coherent DMA buffers in Linux always have a Cacheable alias via the
kernel linear mapping and the proce
This series is outcome of the below discussion thread.
http://www.spinics.net/lists/arm-kernel/msg104254.html
The series in brief has following patches
- adds PL310 aux-control register bitfields
- Use these bitfields instead of hardcoded values as part of init
- En
From: Mans Rullgard
Enabling L2 prefetching improves performance as shown on Panda
ES2.1 board with mem test, and it has measurable impact on
performances. I think we should consider it, even though it damages
"writes" a bit. (rebased to k.org)
Usually the prefetch is used at both levels together
> -Original Message-
> From: Nishanth Menon [mailto:n...@ti.com]
> Sent: Friday, November 19, 2010 10:55 PM
> To: Santosh Shilimkar
> Cc: Kevin Hilman; linux-omap; Jean Pihet; Vishwanath Sripathy; Tony
> Subject: Re: [PATCH 08/13] OMAP3: PM: Deny MPU idle while saving secure
> RAM
>
> Santo
Santosh Shilimkar had written, on 11/19/2010 11:18 AM, the following:
[..]
I guess we need some more details on which secure mode calls can trigger
this problem. If this is an isolated case, I'm OK with this fix. If
it's more general, I'd like to see a more general fix.
On the related topic I
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Kevin Hilman
> Sent: Friday, November 19, 2010 10:39 PM
> To: Nishanth Menon
> Cc: linux-omap; Jean Pihet; Vishwanath Sripathy; Tony
> Subject: Re: [PATCH 08/13] OMAP3: PM
Kevin Hilman had written, on 11/19/2010 11:15 AM, the following:
Nishanth Menon writes:
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
Kevin Hilman had written, on 11/19/2010 11:08 AM, the following:
Nishanth Menon writes:
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 woul
Nishanth Menon writes:
> 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 additi
Nishanth Menon writes:
> 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
Hi Srinath,
On 11/19/10 18:07, srin...@mistralsolutions.com wrote:
> From: Srinath
>
> AM3517/05 Craneboard has one EHCI interface on board using port1.
>
> GPIO35 is used as power enable.
> GPIO38 is used as port1 PHY reset.
>
> Signed-off-by: Srinath
> ---
> arch/arm/mach-omap2/board-am3517c
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Kevin Hilman
> Sent: Wednesday, November 17, 2010 12:19 AM
> To: Nishanth Menon
> Cc: linux-omap; linux-arm; Mans Rullgard
> Subject: Re: [PATCH] omap4: enable L2 prefetch
Madhusudhan Gowda writes:
> A corner case where prcm_interrupt handler is handling the WKST_WKUP and
> before acknowledging the wakeup sources if an IO Pad wakeup ST_IO is
> indicated then hits the below warning since the wakeup sources are already
> cleared.
> WARN(c == 0, "prcm: WARNING:
From: Srinath
AM3517/05 Craneboard has one EHCI interface on board using port1.
GPIO35 is used as power enable.
GPIO38 is used as port1 PHY reset.
Signed-off-by: Srinath
---
arch/arm/mach-omap2/board-am3517crane.c | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
On Fri, Nov 19, 2010 at 5:14 PM, Derrick, David wrote:
>>-Original Message-
>>From: Jean Pihet [mailto:jean.pi...@newoldbits.com]
>>Sent: Friday, November 19, 2010 9:37 AM
>
>>On Thu, Nov 18, 2010 at 7:34 PM, Jean Pihet
>>>wrote:
>>> On Thu, Nov 18, 2010 at 7:27 PM, Tony Lindgren wrote:
>-Original Message-
>From: Jean Pihet [mailto:jean.pi...@newoldbits.com]
>Sent: Friday, November 19, 2010 9:37 AM
>On Thu, Nov 18, 2010 at 7:34 PM, Jean Pihet >wrote:
>> On Thu, Nov 18, 2010 at 7:27 PM, Tony Lindgren wrote:
>>> * Jean Pihet [101118 10:06]:
On Thu, Nov 18, 2010 at
* Jean Pihet [101119 07:27]:
> HI Tony,
>
> On Thu, Nov 18, 2010 at 7:34 PM, Jean Pihet wrote:
> > 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
Include sched.h to ensure sched_clock() has the notrace
annotation, and mark any functions it calls as notrace
too.
Cc: Tony Lindgren
Cc: linux-omap@vger.kernel.org
Signed-off-by: Rabin Vincent
---
arch/arm/plat-omap/counter_32k.c | 13 +++--
arch/arm/plat-omap/io.c |2 +-
* R, Sricharan [101119 00:39]:
>
> Ok . This means that the pin muxing introduced
> would be applicable for omap 2 ,3 and 4 also, with the
> board file passing the respective data if they are different ?
Well the pin configuration stays board specific, but the code
to set the pads is same for a
This patch (as1431b) makes the synchronous runtime-PM interface
suitable for use in interrupt handlers. Subsystems can call the new
pm_runtime_irq_safe() function to tell the PM core that a device's
runtime-PM callbacks should be invoked with interrupts disabled
(runtime_suspend and runtime_resume
HI Tony,
On Thu, Nov 18, 2010 at 7:34 PM, Jean Pihet wrote:
> 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-O
From: Thara Gopinath
Convert OMAP1 dmtimers into a platform devices and then registers with
device model framework so that it can be bound to corresponding driver.
Signed-off-by: Thara Gopinath
Signed-off-by: Tarun Kanti DebBarma
---
arch/arm/mach-omap1/Makefile |2 +-
arch/arm/mach-omap
Convert dmtimers static array in functions into list structure.
Please note that the static arrays will be completely removed
in subsequent patches when dmtimer is converted to platform driver.
Signed-off-by: Tarun Kanti DebBarma
---
arch/arm/plat-omap/dmtimer.c | 67 +++---
From: Thara Gopinath
Add dmtimer platform driver functions which include:
(1) platform driver initialization
(2) driver probe function
(3) driver remove function
Signed-off-by: Thara Gopinath
Signed-off-by: Tarun Kanti DebBarma
---
arch/arm/plat-omap/dmtimer.c | 168 +
From: Cousson, Benoit
Add hwmod database for OMAP4.
Signed-off-by: Cousson, Benoit
Signed-off-by: Tarun Kanti DebBarma
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 622
1 files changed, 622 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_
From: Thara Gopinath
Add routines to converts dmtimers to platform devices. The device data
is obtained from hwmod database of respective platform and is registered
to device model after successful binding to driver. It also provides
provision to access timers during early boot when pm_runtime fr
Add pm_runtime support to dmtimer. Since dmtimer is used during
early boot before pm_runtime is initialized completely there are
provisions to enable/disable clocks directly in the code during
early boot.
Signed-off-by: Tarun Kanti DebBarma
[p-bas...@ti.com: added pm_runtime logic in probe()]
Sig
switch-over to platform device driver through following changes:
(a) call to dmtimer initialization routine from timer-gp.c is
removed (b) initiate dmtimer early initialization from omap2_init_common_hw
in io.c (c) modify plat-omap/dmtimer routines to use new register map and
platform data.
Signed
reset is handled by hwmod framework and so removing it
from the code.
Signed-off-by: Tarun Kanti DebBarma
Reviewed-by: Cousson, Benoit
---
arch/arm/plat-omap/dmtimer.c | 42 ++
1 files changed, 2 insertions(+), 40 deletions(-)
diff --git a/arch/arm/pla
From: Thara Gopinath
Add hwmod database for OMAP2420.
Signed-off-by: Thara Gopinath
Signed-off-by: Tarun Kanti DebBarma
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 633
1 files changed, 633 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap
Add low level read/write routines to access dmtimer interrupt
registers. These routines would be used later when we support
OMAP 4 new IP revision. When that happens the present read/write
routines would be used to access dmtimer functional registers
only.
Signed-off-by: Tarun Kanti DebBarma
Sign
From: Thara Gopinath
Add hwmod database for OMAP3.
Signed-off-by: Thara Gopinath
Signed-off-by: Tarun Kanti DebBarma
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 674
1 files changed, 674 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hw
From: Thara Gopinath
Add hwmod database for OMAP2430.
Signed-off-by: Thara Gopinath
Signed-off-by: Tarun Kanti DebBarma
---
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 632
1 files changed, 632 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap
(1) Add new fields and data structures to support dmtimer conversion
to platform driver.
(2) Constants to identify IP revision so that Highlander IP in OMAP 4
can be distinguished.
(3) field to identify OMAP4 abe timers.
(4) Interface function to support early boot.
Signed-off-by: Tarun Kanti DebB
dmtimer adaptation to platform_driver.
This patch series is adaptation of dmtimer code to platform driver
using omap_device and omap_hwmod abstraction.
v4:
(1) clock aliases are renamed as "32k_ck", "sys_ck" and "alt_ck"
(2) incorporate missing clk_put() for corresponding clk_get()
(3) modified c
From: Thara Gopinath
Add device name to OMAP2 dmtimer fclk nodes so that the fclk nodes can be
retrieved by doing a clk_get with the corresponding device pointers or
device names.
Signed-off-by: Thara Gopinath
Signed-off-by: Tarun Kanti DebBarma
---
arch/arm/mach-omap2/clock2420_data.c | 58
G, Manjunath Kondaiah had written, on 11/19/2010 01:21 AM, the following:
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.
[..]
These API's are required for mult
On 11/19/2010 3:22 PM, Kanigeri, Hari wrote:
Felipe,
On Fri, Nov 19, 2010 at 2:32 AM, Felipe Balbi wrote:
On Thu, Nov 18, 2010 at 06:07:40PM -0600, Kanigeri, Hari wrote:
Benoit,
On Thu, Nov 18, 2010 at 5:28 PM, Cousson, Benoit wrote:
On 11/18/2010 8:15 PM, Hari Kanigeri wrote:
disablin
CONFIG_MTD_NAND_OMAP_HWECC defined wrongly in patch submitted for 2.6.36.
This flag enables hw ecc by default. Boards like beagle and pandora uses
sw ecc for write (e.g. binary flushed from u-boot) and read from kernel.
https://patchwork.kernel.org/patch/111036/
Signed-off-by: Sukumar Ghorai
---
Felipe,
On Fri, Nov 19, 2010 at 8:25 AM, Felipe Balbi wrote:
> Hi, (at home already),
>
> On Fri, 2010-11-19 at 07:57 -0600, Kanigeri, Hari wrote:
>> > think of it as FIFO. So the first completed message is the first in your
>> > list of requests. Ain't that easy ? :-)
>>
>> Actually it isn't th
Hi,
(please read elinux.org/Netiquette :-)
On Fri, 2010-11-19 at 14:53 +0100, ext-madhusudhan.1.go...@nokia.com
wrote:
> Yes Balbi. I will incorporate your comments.
> WARN(!c && (ct == 1), "prcm: WARNING: PRCM indicated "
> "MPU wakeup but no wakeup sources "
> "are marked\n");
>
Hi, (at home already),
On Fri, 2010-11-19 at 07:57 -0600, Kanigeri, Hari wrote:
> > think of it as FIFO. So the first completed message is the first in your
> > list of requests. Ain't that easy ? :-)
>
> Actually it isn't that easy ;) because there is no guarantee that the
> completed message is
Felipe,
On Fri, Nov 19, 2010 at 2:32 AM, Felipe Balbi wrote:
> On Thu, Nov 18, 2010 at 06:07:40PM -0600, Kanigeri, Hari wrote:
>>
>> 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
A corner case where prcm_interrupt handler is handling the WKST_WKUP and
before acknowledging the wakeup sources if an IO Pad wakeup ST_IO is
indicated then hits the below warning since the wakeup sources are already
cleared.
WARN(c == 0, "prcm: WARNING: PRCM indicated "
"MP
Currently driver storred digest results in req->results
provided by the client. But some clients do not set it
until final() call. It leads to crash.
Changed to use internal buffer to store temporary digest results.
Signed-off-by: Dmitry Kasatkin
---
drivers/crypto/omap-sham.c | 11 ---
bufcnt is 0 if it was no update requests before,
which is exact meaning of FLAGS_FIRST.
Signed-off-by: Dmitry Kasatkin
---
drivers/crypto/omap-sham.c |8 +---
1 files changed, 1 insertions(+), 7 deletions(-)
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index c8d3
Hash-in-progress is now stored in hw format.
Only on final call, hash is converted to correct format.
Speedup copy procedure and will allow to use OMAP burst mode.
Signed-off-by: Dmitry Kasatkin
---
drivers/crypto/omap-sham.c | 38 --
1 files changed, 24 ins
According to the Herbert Xu, client may not always call
crypto_ahash_final().
In the case of error in hash calculation resources will be
automatically cleaned up.
But if no hash calculation error happens and client will not call
crypto_ahash_final() at all, then internal buffer will not be freed,
If scatterlist have more than one entry, current driver uses
aligned buffer to copy data to to accelerator to tackle possible
issues with DMA and SHA buffer alignment.
This commit adds more intelligence to verify SG alignment and
possibility to use DMA directly on the data without using copy
buffe
Introduces DMA error handling.
DMA error is returned as a result code of the hash request.
Clients needs to handle error codes and may repeat hash calculation attempt.
Also in the case of DMA error, SHAM module is set to be re-initialized again.
It significantly improves stability against possibl
Locking for queuing and dequeuing is combined.
test_and_set_bit() is also replaced with checking under dd->lock.
Signed-off-by: Dmitry Kasatkin
---
drivers/crypto/omap-sham.c | 47 +++
1 files changed, 21 insertions(+), 26 deletions(-)
diff --git a/driv
DMA parameters for constant data were initialized during driver probe().
It seems that those settings sometimes are lost when devices goes to off mode.
This patch makes DMA initialization just before use.
It solves off mode problems.
Fixes: NB#202786 - Aegis & SHA1 block off mode changes
Signed-o
Hi,
Here is a set of patches which provides fixes and improvements.
Based on Herbert feedback it also includes fixes so that calling final()
is not mandatory.
BR, Dmitry
Dmitry Kasatkin (8):
omap-sham: uses digest buffer in request context
omap-sham: DMA initialization fixes for off mode
Felipe,
On Fri, Nov 19, 2010 at 6:53 AM, Felipe Balbi wrote:
> Hi Hari,
>
> On Fri, Nov 19, 2010 at 06:29:39AM -0600, Kanigeri, Hari wrote:
>>
>> How do you know that a response is received for a particular sender ?
>
> think of it as FIFO. So the first completed message is the first in your
> li
Yes Balbi. I will incorporate your comments.
Regards
Gowda
From: linux-omap-ow...@vger.kernel.org [linux-omap-ow...@vger.kernel.org] On
Behalf Of ext Felipe Balbi [ba...@ti.com]
Sent: Friday, November 19, 2010 1:47 PM
To: Gowda Madhusudhan.1 (EXT-Elektro
On Fri, Nov 19, 2010 at 1:12 PM, Nishanth Menon wrote:
> Jean Pihet wrote, on 11/19/2010 04:09 AM:
> [...]
>>>
>>> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
>>> index f520b38..c7e2db0 100644
>>> --- a/arch/arm/mach-omap2/pm34xx.c
>>> +++ b/arch/arm/mach-omap2/pm34xx.
Hi Hari,
On Fri, Nov 19, 2010 at 06:29:39AM -0600, Kanigeri, Hari wrote:
How do you know that a response is received for a particular sender ?
think of it as FIFO. So the first completed message is the first in your
list of requests. Ain't that easy ? :-)
By reading mailbox payload or by rea
Felipe,
>
>> I think handling of per-message callback should be handled at one
>> level above mailbox, like in IPC modules such as dspbridge,
>> syslink..etc.
>
> then you'll have duplication of functionality :-)
>
yes in mailbox :). One solution doesn't fit all and this should be
handled at IPC d
Jean Pihet wrote, on 11/19/2010 04:07 AM:
[..]
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 0102d60..1890e49 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -86,6 +86,7 @@ static int secure_ram_saved;
#define PER_WAKEUP_ERRATA_i
Jean Pihet wrote, on 11/19/2010 04:09 AM:
[...]
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index f520b38..c7e2db0 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -422,6 +422,14 @@ void omap_sram_idle(void)
Jean Pihet wrote, on 11/19/2010 03:57 AM:
[...]
diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
index 5a4468f..7259541 100644
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
...
/* Function call to get the restore pointer for for ES3
On Fri, Nov 19, 2010 at 05:50:19AM -0600, Kanigeri, Hari wrote:
Thanks for your comments :).
np.
I think handling of per-message callback should be handled at one
level above mailbox, like in IPC modules such as dspbridge,
syslink..etc.
then you'll have duplication of functionality :-)
Ma
Jean Pihet wrote, on 11/19/2010 04:18 AM:
Hi,
On Fri, Nov 19, 2010 at 2:54 AM, Nishanth Menon wrote:
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_AU
Felipe,
On Fri, Nov 19, 2010 at 2:33 AM, Felipe Balbi wrote:
> Hi,
>
> On Thu, Nov 18, 2010 at 01:15:40PM -0600, Hari Kanigeri wrote:
>>
>> Fix the checkpatch warnings observed in mailbox module
>
> you should put which warnings are those here :-)
>
Sure, will add some descriptions in next patch
Felipe,
On Fri, Nov 19, 2010 at 2:50 AM, Felipe Balbi wrote:
> Hi,
>
> On Thu, Nov 18, 2010 at 01:15:42PM -0600, Hari Kanigeri wrote:
>>
>> 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
Hi,
On Fri, Nov 19, 2010 at 01:26:33PM +0200, Madhusudhan Gowda wrote:
@@ -277,13 +278,16 @@ static irqreturn_t prcm_interrupt_handler (int irq, void
*dev_id)
if (irqstatus_mpu & (OMAP3430_WKUP_ST_MASK |
OMAP3430_IO_ST_MASK)) {
A corner case where prcm_interrupt handler is handling the WKST_WKUP and
before acknowledging the wakeup sources if an IO Pad wakeup ST_IO is
indicated then hits the below warning since the wakeup sources are already
cleared.
WARN(c == 0, "prcm: WARNING: PRCM indicated "
"MP
On Fri, Nov 19, 2010 at 2:35 AM, Peter Barada wrote:
> 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 C
On Thu, Nov 18, 2010 at 8:01 PM, Tony Lindgren wrote:
> * 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
wrongly
>>
>> Signed-off-by: Sukumar Ghorai
>> ---
>> drivers/mtd/nand/omap2.c |
On Thu, Nov 18, 2010 at 4:33 PM, Ghorai, Sukumar wrote:
>> -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 m
Hi,
On Fri, Nov 19, 2010 at 2:54 AM, Nishanth Menon wrote:
> 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
> CONFI
Hi Peter,
On Fri, Nov 19, 2010 at 10:57 AM, Peter 'p2' De Schrijver
wrote:
> On Fri, Nov 19, 2010 at 10:46:19AM +0100, ext Jean Pihet wrote:
>> On Fri, Nov 19, 2010 at 2:54 AM, Nishanth Menon wrote:
>> > From: Richard Woodruff
>> >
>> > Analysis in TI kernel with ETM showed that using cache map
On Fri, Nov 19, 2010 at 2:54 AM, Nishanth Menon wrote:
> 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.
On Fri, Nov 19, 2010 at 2:54 AM, Nishanth Menon wrote:
> 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
On Fri, Nov 19, 2010 at 10:46:19AM +0100, ext Jean Pihet wrote:
> On Fri, Nov 19, 2010 at 2:54 AM, Nishanth Menon wrote:
> > 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
>
On Fri, Nov 19, 2010 at 2:54 AM, Nishanth Menon wrote:
> 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
On Fri, Nov 19, 2010 at 2:54 AM, Nishanth Menon wrote:
> 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:
1 - 100 of 106 matches
Mail list logo