Hi,
>-Original Message-
>From: Hiroshi DOYU [mailto:hiroshi.d...@nokia.com]
>Sent: Monday, February 15, 2010 7:49 AM
>To: Guzman Lugo, Fernando
>Cc: linux-omap@vger.kernel.org
>Subject: Re: [PATCH 5/6] Mailbox: sleeping function called from invalid
>context fix
>
>Hi Fernando,
>
>From: "e
From: Eduardo Valentin
Add a basic description information for each cpuidle C-state.
The info contains only which state the MPU, NEON and CORE
power domains should reach when the C-state is selected.
Signed-off-by: Eduardo Valentin
---
arch/arm/mach-omap2/cpuidle34xx.c |4
1 files cha
From: Tero Kristo
Added definitions for OMAP3430ES2_ST_SGX_SHIFT and OMAP3430ES2_ST_SGX_MASK
as these were missing.
Signed-off-by: Tero Kristo
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/cm-regbits-34xx.h |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arc
From: Thara Gopinath
This patch adds APIs pwrdm_read_logic_retst and
pwrdm_read_mem_retst for reading the next programmed
logic and memory state a powerdomain is to hit in event
of the next power domain state being retention.
These are needed for OSWR support.
Signed-off-by: Thara Gopinath
Sign
From: Ranjith Lohithakshan
This patch adds clock support for the following AM35xx modules
- Ethernet MAC
- CAN Controller (HECC)
- New MUSB OTG Controller with integrated Phy
- Video Processing Front End (VPFE)
- Additional UART (UART4)
Signed-off-by: Ranj
From: Vishwanath BS
DPLL_FREQSEL field in CLKEN_PLL register is no longer valid for
OMAP3630. So remove references to that.
Signed-off-by: Vishwanath BS
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/dpll3xxx.c | 11 +++
1 files changed, 7 insertions(+), 4 deletions(-)
diff -
From: Kevin Hilman
- missing return in omap_prcm_get_reset_sources()
- potential use of uninitialized variable in omap_prcm_arch_reset()
Signed-off-by: Kevin Hilman
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/prcm.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff
From: Mike Turquette
This patch implements a workaround for the DPLL HS divider limitation
in OMAP3630 as given by Errata ID: i556.
Errata:
When PWRDN bit is set, it resets the internal HSDIVIDER divide-by value (Mx).
The reset value gets loaded instead of the previous value.
The following HSDIV
From: Thara Gopinath
This patch adds support in omap device layer to register devices
as early platform devices. Certain devices needed during system boot up
like timers, gpio etc can be registered as early devices. This will
allow for them to be probed very early on during system boot up.
This p
From: Thara Gopinath
In OMAP3 Some modules like Smartreflex do not have the regular sysconfig
register.Instead clockactivity bits are part of another register at a
different bit position than the usual bit positions 8 and 9.
In OMAP4, a new scheme is available due to the new protocol
between th
From: Abhijit Pagare
A check is added for avoiding the sleep/wakeup dependency updates
for OMAP4 as the structures for the dependencies are currently absent.
Signed-off-by: Abhijit Pagare
[p...@pwsan.com: added warnings, explanatory comment, copyright update]
Signed-off-by: Paul Walmsley
---
From: Richard Woodruff
DPLL4 for 3630 introduces a changed block called j type dpll, requiring
special divisor bits and additional reg fields. To allow for silicons to
use this, this is introduced as a flag and is enabled for 3630 silicon.
OMAP4 also has j type dpll for usb.
Tested with 3630 ZOO
From: Vishwanath BS
In 3630, DPLL4M2 output can be 96MHz or 192MHz (for SGX to run at
192). This patch has changes to support this feature. 96MHz clock is
generated by dividing 192Mhz clock by 2 using CM_CLKSEL_CORE register.
SGX can select Core Clock, 192MHz clock or CM_96M_FCLK as it's
function
From: Vishwanath BS
Divider (M2, M3, M4, M5 and M6) field width has been increased by 1 bit
in 3630. This patch has changes to accommodate this in CM dynamically
based on chip version.
Basically new clock nodes have been added for 3630 DPLL4 M2,M3,M4,M5 and
M6 and value of these nodes are used if
From: Ranjith Lohithakshan
Current implementation defines clock idle state indicators based on the
cpu information (cpu_is_omap24xx() or cpu_is_omap34xx()) in a system wide
manner. This patch extends the find_idlest() function in clkops to pass
back the idle state indicator for that clock, thus a
From: Sanjeev Premi
This patch checks if clk_get() returned success for
the clocks used in function omap2_clk_arch_init().
This version incorporates review comments from
Kevin Hilman and Paul Walmsley.
Signed-off-by: Sanjeev Premi
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/clock34x
From: Thara Gopinath
This patch adds counters to keep track of whether the powerdomain
logic or software controllable memory banks are turned off when
the power domain enters retention. During power domain retention
if logic gets turned off, the scenario is known as Open Switch Retention.
Also du
From: Thara Gopinath
This patch adds the flag .pwrsts_logic_ret info for the core power domain
in the associated powerdomain structure. This flag specifies the states
core domain logic can hit in event of the domain entering retention.
Signed-off-by: Thara Gopinath
Signed-off-by: Paul Walmsley
From: Kevin Hilman
Add _MASK suffix to CM_FCLKEN_IVA2 bitfieds to conform with the rest
of the usage in cm-regbits-34xx.h of using _SHIFT and _MASK suffixes.
Signed-off-by: Kevin Hilman
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/cm-regbits-34xx.h |2 +-
arch/arm/mach-omap2/pm34x
From: Kevin Hilman
The omap_device_[enable|idle|shutdown] functions print a warning
when called from an invalid state. Print the invalid state in
the warning messages. This also uses __func__ to get the function
name.
Also, move the entire print string onto a single line to facilitate
grepping
From: Kevin Hilman
The omap_device struct contains a 'struct platform_device'. Normally,
converting a platform_device pointer to an omap_device pointer
consists of simply doing a container_of(), as is done currently by the
to_omap_device() macro.
However, if this is attempted when using platfor
Hello,
Here are some more OMAP clock, clockdomain, powerdomain, and hwmod
patches intended for 2.6.34, posted in case anyone has any comments.
- Paul
---
Abhijit Pagare (1):
ARM: OMAP4 clock domain: Add check for avoiding dependency related update.
Kevin Hilman (4):
OMAP: omap_dev
The RATE_FIXED clock flag is pointless. In the OMAP1 clock code, it
simply causes the omap1_clk_round_rate() function to return the
current rate of the clock. omap1_clk_round_rate(), however, should
never be called for a fixed-rate clock, since none of these clocks
have a .round_rate function po
clock34xx_data.c now contains data for the OMAP34xx family, the
OMAP36xx family, and the OMAP3517 family, so rename it to
clock3xxx_data.c. Rename clock34xx.c to clock3xxx.c, and move the
chip family-specific clock functions to clock34xx.c, clock36xx.c, or
clock3517.c, as appropriate. So now "cl
On Thu, 11 Feb 2010, Paul Walmsley wrote:
> this series, targeted for 2.6.34,
>
> - fixes several OMAP clock bugs,
>
> - removes several unnecessary clock structure fields and clock flags,
>
> - splits the OMAP2420 and OMAP2430 clock trees in preparation for
> multi-OMAP 2 kernels,
>
> - and
On Tue, 9 Feb 2010, Vimarsh Zutshi wrote:
> Add necessary clk_sel definitions to clock framework to allow changing
> dpll4_m5_ck_3630 rate. This is used by the ISP driver.
>
> Signed-off-by: Vimarsh Zutshi
Thanks, queued for 2.6.34 with minor changes to apply against the current
2.6.34 set of
Hi all,
I'm using the rowboat project(Android over beagleboard),and I have
enabled the CPUFREQ kernel driver,and I can switch between the
different frequencies,however when I measure the current consumed ,I
found that in some certain OP,the current remains constant without any
change in it's value,
* Paul Walmsley [100214 17:38]:
> On Fri, 12 Feb 2010, Paul Walmsley wrote:
>
> > On Fri, 12 Feb 2010, Varadarajan, Charulatha wrote:
> >
> > > OMAP: Convert GPIO into a early driver
> >
> > The above patch appears to be missing. Could you please re-send?
>
> This patch was too big for the
On 02/15/2010 09:10 AM, Tony Lindgren wrote:
* Peter Barada [100214 13:44]:
What's a known good toolcahin for linux-omap development?
I'm currently using CodeSroucery 2009q1-203 and wondering if there's a
better toolchain or if people have had problems using the the
2009q1-203 toolchain.
Tha
* Peter Barada [100214 13:44]:
> What's a known good toolcahin for linux-omap development?
>
> I'm currently using CodeSroucery 2009q1-203 and wondering if there's a
> better toolchain or if people have had problems using the the
> 2009q1-203 toolchain.
That seems to work OK, I can't think of an
>-Original Message-
>From: Ameya Palande [mailto:ameya.pala...@nokia.com]
>Sent: Monday, February 15, 2010 9:50 AM
>To: Contreras Felipe (Nokia-D/Helsinki)
>Cc: Guzman Lugo, Fernando; linux-omap; Doyu Hiroshi (Nokia-D/Helsinki)
>Subject: Re: [PATCH 0/3] DSPBRIDGE: Replace custom mailbox i
On Mon, Feb 15, 2010 at 04:35:08PM +0100, Ameya Palande wrote:
> DSP_RSV_OBJECT is introduced to track reserved memory accounting information.
> This will allow us to do proper cleanup for memory reserved using
> PROC_ReserveMemory().
>
> Signed-off-by: Ameya Palande
> ---
[...]
> diff --git a/
On Mon, Feb 15, 2010 at 04:36:31PM +0100, Ameya Palande wrote:
> This patch fixes following issues:
>
> 1. pDMMRes was dereferenced and modified when it was already freed by
> PROC_Ummap(). This results in memory corruption.
>
> 2.Instead of passing ulDSPAddr, ulDSPResAddr was passed to PROC_UnMa
On Mon, 2010-02-15 at 16:07 +0100, Contreras Felipe (Nokia-D/Helsinki)
wrote:
> On Sat, Feb 13, 2010 at 03:01:57AM +0100, ext Guzman Lugo, Fernando wrote:
> > >From d287e11cdb126f2c9b4be8d6d6f958ffdf7ff716 Mon Sep 17 00:00:00 2001
> > From: Fernando Guzman Lugo
> > Date: Fri, 12 Feb 2010 19:55:55
This patch fixes following issues:
1. pDMMRes was dereferenced and modified when it was already freed by
PROC_Ummap(). This results in memory corruption.
2.Instead of passing ulDSPAddr, ulDSPResAddr was passed to PROC_UnMap()
which will not retrieve correct DMMRes element.
Signed-off-by: Ameya P
In its current state DMM_RES_OBJECT is not correctly tracking reserve and
unreserve but only map and unmap. So lets rename it to DMM_MAP_OBJECT to
clarify what it is really doing!
In addition to this, this patch also does some trivial code cleanup.
Signed-off-by: Ameya Palande
---
arch/arm/plat
DSP_RSV_OBJECT is introduced to track reserved memory accounting information.
This will allow us to do proper cleanup for memory reserved using
PROC_ReserveMemory().
Signed-off-by: Ameya Palande
---
arch/arm/plat-omap/include/dspbridge/drv.h | 13
arch/arm/plat-omap/include/dspbridge
This patch series splits DMM_RES_OBJECT into DMM_MAP_OBJECT and DMM_RSV_OBJECT
which are used independently for mapped and reserved memory resources
accounting. This will help in cleanup of reserved memory resources which was
not handled properly before. With these patches resource cleanup mechanis
> -Original Message-
> From: Tony Lindgren [mailto:t...@atomide.com]
> Sent: Wednesday, February 10, 2010 11:04 PM
> To: Premi, Sanjeev
> Cc: linux-omap@vger.kernel.org
> Subject: Re: omap3evm: Doesn't boot at 4fa42e46
>
> * Premi, Sanjeev [100210 09:09]:
> > > -Original Message-
On Sat, Feb 13, 2010 at 03:01:57AM +0100, ext Guzman Lugo, Fernando wrote:
> >From d287e11cdb126f2c9b4be8d6d6f958ffdf7ff716 Mon Sep 17 00:00:00 2001
> From: Fernando Guzman Lugo
> Date: Fri, 12 Feb 2010 19:55:55 -0600
> Subject: [PATCH] DSPBRIDGE: Replace custom mailbox implementation with
> kerne
On Thu, Feb 04, 2010 at 08:04:44PM -0800, Tony Lindgren wrote:
> Russell, can you please let me know if you have some static
> commit ID containing the patch above that I could use that as
> base for my patches?
Right, when it eventually gets through linux-next, 4e6d488
--
Russell King
Linux ke
I am interested in porting my 5 mega pixel CMOS sensor design to the
beagle board (OMAP3) but after checking out two different kernel trees
and checking the beagle and OMAP lists, I can't find support for the
VPFE hardware for this processor.
I did find a patch on this list that created a ti-media
On Mon, Feb 15, 2010 at 2:11 PM, Hiremath, Vaibhav wrote:
>> -Original Message-
>> From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com]
>> Sent: Monday, February 15, 2010 4:28 PM
>> To: Hiremath, Vaibhav
>> Cc: linux-omap@vger.kernel.org; linux-fb...@vger.kernel.org
>> Subject: RE: [PATC
Hi Fernando,
From: "ext Guzman Lugo, Fernando"
Subject: [PATCH 5/6] Mailbox: sleeping function called from invalid context fix
Date: Sat, 13 Feb 2010 02:42:16 +0100
> From e06b2716824f225747c4dc83ed2623d0160ae132 Mon Sep 17 00:00:00 2001
> From: Fernando Guzman Lugo
> Date: Fri, 29 Jan 2010 17:
On Mon, 2010-02-15 at 13:11 +0100, ext Hiremath, Vaibhav wrote:
> > -Original Message-
> > From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com]
> > Sent: Monday, February 15, 2010 4:28 PM
> > To: Hiremath, Vaibhav
> > Cc: linux-omap@vger.kernel.org; linux-fb...@vger.kernel.org
> > Subject
> -Original Message-
> From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com]
> Sent: Monday, February 15, 2010 4:28 PM
> To: Hiremath, Vaibhav
> Cc: linux-omap@vger.kernel.org; linux-fb...@vger.kernel.org
> Subject: RE: [PATCH 01/13] OMAP: DSS2: enable VDDS_DSI when using
> DPI
>
> On Mon
On Mon, 2010-02-15 at 11:22 +0100, ext Hiremath, Vaibhav wrote:
> > -Original Message-
> > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> > ow...@vger.kernel.org] On Behalf Of Tomi Valkeinen
> > Sent: Monday, February 08, 2010 9:26 PM
> > To: linux-omap@vger.kernel.org; linux-
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Tomi Valkeinen
> Sent: Monday, February 08, 2010 9:26 PM
> To: linux-omap@vger.kernel.org; linux-fb...@vger.kernel.org
> Cc: Tomi Valkeinen
> Subject: [PATCH 01/13] OMAP:
"ext Reddy, Teerth" writes:
> From: Teerth Reddy
>
> Dynamic Calculation of SDRC stall latency during DVFS
>
> The patch has the changes to calculate the dpll3 clock stabilization delay
> dynamically. The SRAM delay is calibrated during bootup using the gptimers
> and used while calculating th
Hi Fernando,
From: "ext Guzman Lugo, Fernando"
Subject: [PATCH 0/6] Mailbox: Fix some issues in mailbox module
Date: Sat, 13 Feb 2010 02:37:33 +0100
> From a7b162f3af04bbfa39c439c47b8499962410a9c9 Mon Sep 17 00:00:00 2001
> From: Fernando Guzman Lugo
> Date: Fri, 12 Feb 2010 19:35:05 -0600
> Su
50 matches
Mail list logo
