Hi Tomi,
On Thu, Jun 23, 2011 at 6:01 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Thu, 2011-06-23 at 17:35 +0530, K, Mythri P wrote:
Hi Tomi,
On Thu, Jun 23, 2011 at 3:28 PM, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
On Fri, 2011-06-17 at 13:47 +0530, Mythri P K wrote:
HDMI IP
Hi Rajendra, Todd,
On Fri, 10 Jun 2011, Rajendra Nayak wrote:
Paul/Benoit any thoughts on if a per-clkdm lock seems reasonable?
Sounds okay to me.
The experimental patch that you sent didn't add the locking to the *wkdep,
*sleepdep functions; I guess we'd better add it there at the same
Hi Santosh,
On Sat, Jun 25, 2011 at 3:23 PM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
On 6/24/2011 7:38 AM, jean.pi...@newoldbits.com wrote:
From: Jean Pihetj-pi...@ti.com
Since cpuidle is a CPU centric framework it decides the MPU
next power state based on the MPU exit_latency and
* Kevin Hilman khil...@ti.com [110623 10:02]:
Tony Lindgren t...@atomide.com writes:
This patch makes timer-gp.c to use only a subset of dmtimer
functions without the need to initialize dmtimer code early.
Also note that now with the inline functions, timer_set_next_event
becomes more
On Mon, Jun 27, 2011 at 10:24:43AM +0530, Premi, Sanjeev wrote:
-Original Message-
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
Sent: Sunday, June 26, 2011 12:39 AM
To: Premi, Sanjeev
Cc: Shilimkar, Santosh; linux-omap@vger.kernel.org;
* Kevin Hilman khil...@ti.com [110623 09:56]:
Tony Lindgren t...@atomide.com writes:
There's no need to initialize the dmtimer framework early.
Actually, there is, because it's being used from the early code.
The sys_timer.init functions are called before arch_initcalls, so before
* Kevin Hilman khil...@ti.com [110623 10:08]:
Tony Lindgren t...@atomide.com writes:
There's no need to initialize the dmtimer framework early.
Just mark the clocksource and timesource as reserved, and
initialize dmtimer with an arch_initcall.
Signed-off-by: Tony Lindgren
* Kevin Hilman khil...@ti.com [110623 10:06]:
Tony Lindgren t...@atomide.com writes:
+
+ res = omap_dm_timer_init_one(clksrc, gptimer_id, fck_source);
This function makes calls into real driver, but is called from
sys_timer.init so happens before driver is initialized.
That one is the
On Thu, Jun 23, 2011 at 07:43:34PM +0200, Benoit Cousson wrote:
usb_host_fs_fck does have a clkdev mapping with usbhs-omap.0
and fs_fck alias used by the driver.
The entry with NULL dev is thus not needed anymore.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley
Hi,
On Fri, Jun 24, 2011 at 10:37:56PM +0530, Jaswinder Singh wrote:
[CC'ing Liam and Mark as well]
On 24 June 2011 20:07, Jassi Brar jaswinder.si...@linaro.org wrote:
VUSB is a fixed level line and hence have no set_voltage
callback in regulator ops, but has apply_uV set to true.
As a
* Santosh Shilimkar santosh.shilim...@ti.com [110623 08:09]:
On 6/23/2011 8:35 PM, Kevin Hilman wrote:
Tony Lindgrent...@atomide.com writes:
So now, the only thing OMAP-specific is the debugfs file used to trigger
it.
Maybe Kevin can just carry it along in the PM branch for now?
I'd
Hi Felipe,
On 27 June 2011 13:30, Felipe Balbi ba...@ti.com wrote:
+static struct regulator_consumer_supply sdp4430_vusb_supply =
+ REGULATOR_SUPPLY(hsusb0, ehci-omap.0);
this should be an array.
Ok, I can make it an array of _one_ element.
Though I am not sure why is that a good
Hi,
On Mon, Jun 27, 2011 at 01:38:54PM +0530, Jaswinder Singh wrote:
Hi Felipe,
On 27 June 2011 13:30, Felipe Balbi ba...@ti.com wrote:
+static struct regulator_consumer_supply sdp4430_vusb_supply =
+ REGULATOR_SUPPLY(hsusb0, ehci-omap.0);
this should be an array.
Ok, I
Tony,
I'd really like us to decide, because I want my (currently) out of tree port
to be based on one of the patches (v2 or v3).
Can you please, look into this?
Thanks
On 06/22/11 17:56, Igor Grinberg wrote:
Tony,
Does this one look better?
On 06/15/11 00:16, Igor Grinberg wrote:
Hi Todd,
On 6/26/2011 10:07 PM, Todd Poynor wrote:
On Fri, Jun 24, 2011 at 02:06:32PM +0200, Benoit Cousson wrote:
Duplicate the existing API for clockdomain enable from clock to enable
a clock domain from hwmod framework.
This will be needed when the hwmod framework will move from the current
Hi Tony, Samuel,
Would you have time to take a look at this series?
Thanks,
Péter
On Tuesday 21 June 2011 15:38:58 Ujfalusi, Peter wrote:
Hello,
Changes since v5:
- Use alloc_workqueue in the twl6040-vibra driver (comment from Tejun Heo)
- Allow user to change the headset power mode, but
Hi Felipe,
On 27 June 2011 14:05, Felipe Balbi ba...@ti.com wrote:
+static struct regulator_consumer_supply sdp4430_vusb_supply =
+ REGULATOR_SUPPLY(hsusb0, ehci-omap.0);
this should be an array.
Ok, I can make it an array of _one_ element.
Though I am not sure why is that a
Hi,
On Mon, Jun 27, 2011 at 03:35:41PM +0530, Jaswinder Singh wrote:
On 27 June 2011 14:05, Felipe Balbi ba...@ti.com wrote:
+static struct regulator_consumer_supply sdp4430_vusb_supply =
+ REGULATOR_SUPPLY(hsusb0, ehci-omap.0);
this should be an array.
Ok, I can make it an
* Paul Walmsley p...@pwsan.com [110625 15:42]:
On Sun, 26 Jun 2011, Premi, Sanjeev wrote:
[sp] I didn't include a reason - because the problem may not
be reproducible on the public trees.
During tests performed in internal development trees, the
BogoMIPS calculations @
* Péter Ujfalusi peter.ujfal...@ti.com [110627 02:39]:
Hi Tony, Samuel,
Would you have time to take a look at this series?
Looks good to me. If it conflicts with what we have queued
in the devel-cleanup branch, I should probably queue it.
If there are no conflicts, then Samuel can queue it.
* Igor Grinberg grinb...@compulab.co.il [110627 01:31]:
Tony,
I'd really like us to decide, because I want my (currently) out of tree port
to be based on one of the patches (v2 or v3).
Can you please, look into this?
Sorry for the delay, yes that looks good to me. Will add to devel-board
From: Hrishikesh Bhandiwad hrishikes...@ti.com
Present current selection of the GPTIMER on Beagleboard
was result of a hardware issue in early versions of the
Beagleboards (Ax and B1 thru B4). [1][2]
Its been long since the hardware issue has been fixed.
This patch uses GPTIMER 1 for all newer
* Tony Lindgren t...@atomide.com [110627 00:46]:
* Kevin Hilman khil...@ti.com [110623 10:08]:
Tony Lindgren t...@atomide.com writes:
There's no need to initialize the dmtimer framework early.
Just mark the clocksource and timesource as reserved, and
initialize dmtimer with an
* Tony Lindgren t...@atomide.com [110627 00:50]:
* Kevin Hilman khil...@ti.com [110623 10:06]:
Tony Lindgren t...@atomide.com writes:
+
+ res = omap_dm_timer_init_one(clksrc, gptimer_id, fck_source);
This function makes calls into real driver, but is called from
sys_timer.init so
Kevin,
[...]
With register offsets now defined for respective OMAP versions we can
get rid
of cpu_class_* checks. In addition, organized common initialization for
the
different OMAP silicon versions.
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Tarun Kanti DebBarma
On 27 June 2011 15:41, Felipe Balbi ba...@ti.com wrote:
Hi,
On Mon, Jun 27, 2011 at 03:35:41PM +0530, Jaswinder Singh wrote:
On 27 June 2011 14:05, Felipe Balbi ba...@ti.com wrote:
+static struct regulator_consumer_supply sdp4430_vusb_supply =
+ REGULATOR_SUPPLY(hsusb0,
* Sanjeev Premi pr...@ti.com [110627 03:33]:
From: Hrishikesh Bhandiwad hrishikes...@ti.com
Present current selection of the GPTIMER on Beagleboard
was result of a hardware issue in early versions of the
Beagleboards (Ax and B1 thru B4). [1][2]
Its been long since the hardware issue has
* Kevin Hilman khil...@ti.com [110623 17:32]:
Tony,
Please pull the following misc. OMAP PM updates targetted for v3.1.
This branch is based on your 'fixes' branch due to some dependencies.
OMAP2: PM debug: move wakeup timer into clockevent code
This won't work with the devel-timer
* Sebastian Reichel s...@debian.org [110623 12:49]:
On Tue, Jun 07, 2011 at 02:53:31PM +0300, Tony Lindgren wrote:
* Sebastian Reichel s...@debian.org [110606 15:51]:
On Sat, Apr 30, 2011 at 06:23:57PM +0200, Sebastian Reichel wrote:
I'm currently trying to get a mainline based kernel
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Monday, June 27, 2011 4:46 PM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org;
linux-arm-ker...@lists.infradead.org; Gregoire Gentil;
Bhandiwad, Hrishikesh; Jason Lam; Thomas Weber
Subject: Re: [PATCHv2]
* Premi, Sanjeev pr...@ti.com [110627 05:08]:
From: Tony Lindgren [mailto:t...@atomide.com]
I don't think omap3_beagle_init_rev is even called when
the timer is set?
[sp] I verified the patch based on the print indicating that
GPTIMER1 being used as clockevent source.
On 06/27/11 13:21, Tony Lindgren wrote:
* Igor Grinberg grinb...@compulab.co.il [110627 01:31]:
Tony,
I'd really like us to decide, because I want my (currently) out of tree port
to be based on one of the patches (v2 or v3).
Can you please, look into this?
Sorry for the delay, yes that
Convert OMAPs 32kHz clocksource implementation to use the generic MMIO
clocksource support. This achieves several things:
1. It means we get rid of all these helper functions which frankly should
never have been necessary.
2. It means omap_readl() inside these helper functions does not appear
* Russell King - ARM Linux li...@arm.linux.org.uk [110627 05:28]:
--- a/arch/arm/plat-omap/counter_32k.c
+++ b/arch/arm/plat-omap/counter_32k.c
+#ifdef CONFIG_ARCH_OMAP16XX
+ else if (cpu_is_omap16xx())
+ base =
On Sat, Jun 25, 2011 at 3:58 AM, Kevin Hilman khil...@ti.com wrote:
Govindraj.R govindraj.r...@ti.com writes:
Cleanup serial.c file in preparation to addition of runtime api's in
omap-serial
file. Remove all clock handling mechanism as this will be taken care with
pm runtime api's in
On Sat, Jun 25, 2011 at 3:59 AM, Kevin Hilman khil...@ti.com wrote:
Govindraj.R govindraj.r...@ti.com writes:
The pad values here are same as the default pad values updated in
serial.c file.
Avoid structure duplication and use default pads.
Signed-off-by: Govindraj.R govindraj.r...@ti.com
On 06/25/11 21:10, Koen Kooi wrote:
Op 25 jun 2011, om 20:51 heeft Premi, Sanjeev het volgende geschreven:
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Koen Kooi
Sent: Saturday, June 25, 2011 1:47 PM
To:
On Sat, Jun 25, 2011 at 5:42 AM, Kevin Hilman khil...@ti.com wrote:
Govindraj.R govindraj.r...@ti.com writes:
The following UART parameters are defined within the UART driver:
1). Whether the UART uses DMA (dma_enabled), by default set to 0
2). The size of dma buffer (set to 4096 bytes)
3).
On Mon, 2011-06-27 at 11:21 +0530, K, Mythri P wrote:
Hi Tomi,
On Thu, Jun 23, 2011 at 6:01 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Thu, 2011-06-23 at 17:35 +0530, K, Mythri P wrote:
Hi Tomi,
On Thu, Jun 23, 2011 at 3:28 PM, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
On Sat, Jun 25, 2011 at 5:59 AM, Kevin Hilman khil...@ti.com wrote:
Govindraj.R govindraj.r...@ti.com writes:
Prior to this patch the uart_clock was cut using prepare/resume calls since
these funcs are no more available with runtime changes use has_async_wake
flag to keep clock active during
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Monday, June 27, 2011 6:02 PM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org;
linux-arm-ker...@lists.infradead.org; Gregoire Gentil;
Bhandiwad, Hrishikesh; Jason Lam; Thomas Weber
Subject: Re: [PATCHv2]
On Sat, Jun 25, 2011 at 5:36 AM, Kevin Hilman khil...@ti.com wrote:
Govindraj.R govindraj.r...@ti.com writes:
Acquire console lock before enabling and writing to console-uart
to avoid any recursive prints from console write.
for ex:
-- printk
-- uart_console_write
On Fri, Jun 24, 2011 at 04:37:57PM +0200, jean.pi...@newoldbits.com wrote:
From: Jean Pihet j-pi...@ti.com
This patch set is in an RFC state, for review and comments.
In order to implement the new class in PM QoS the following changes
have been made:
1. Add a new PM QoS class for device
On 6/26/2011 11:53 PM, Jean Pihet wrote:
Hi Santosh,
On Sat, Jun 25, 2011 at 3:23 PM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
On 6/24/2011 7:38 AM, jean.pi...@newoldbits.com wrote:
From: Jean Pihetj-pi...@ti.com
Since cpuidle is a CPU centric framework it decides the MPU
next
Hi Tony,
On Monday 27 June 2011 12:18:35 Tony Lindgren wrote:
* Péter Ujfalusi peter.ujfal...@ti.com [110627 02:39]:
Hi Tony, Samuel,
Would you have time to take a look at this series?
Looks good to me. If it conflicts with what we have queued
in the devel-cleanup branch, I should
Santosh,
On Mon, Jun 27, 2011 at 4:11 PM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
On 6/26/2011 11:53 PM, Jean Pihet wrote:
Hi Santosh,
On Sat, Jun 25, 2011 at 3:23 PM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
On 6/24/2011 7:38 AM, jean.pi...@newoldbits.com wrote:
On Sat, Jun 25, 2011 at 5:00 AM, Kevin Hilman khil...@ti.com wrote:
Govindraj.R govindraj.r...@ti.com writes:
Adapts omap-serial driver to use pm_runtime api's.
1.) Populate reg values to uart port which can be used for context restore.
Please make this part a separate patch.
2.) Moving
On Wed, Jun 22, 2011 at 9:57 PM, Cousson, Benoit b-cous...@ti.com wrote:
On 6/22/2011 4:18 PM, Krishnamoorthy, Balaji T wrote:
After runtime conversion to handle clk,
iclk node is not used
However fclk node is still used to get clock rate.
Signed-off-by: Balaji T Kbalaj...@ti.com
---
Just a heads up on this, to let you know I have not ignored your
comments. :)
I have been doing some re-work / testing on this set based on your
comments, and will hopefully post a new set tomorrow. One of the bigger
changes is that I have changed pad wakeups to use omap_mux and they are
now
VUSB is a fixed level line and hence have no set_voltage
callback in regulator ops, but has apply_uV set to true.
As a result it fails to register with the regulator core.
Remove setting apply_uV.
Also, assign name to VUSB supply, without which regulator core
fails to find it and assigns the
From: Moiz Sonasath m-sonas...@ti.com
With this commit: cccad6d4b103e53fb3d1fc1467f654ecb572d047
usb: otg: notifier: switch to atomic notifier
Following dumps are observed on attach/detach for MUSB HOST
mode and on a detach for MUSB Device mode.
BUG: sleeping function called from invalid
On Sat, Jun 25, 2011 at 5:53 AM, Kevin Hilman khil...@ti.com wrote:
Govindraj.R govindraj.r...@ti.com writes:
Use resume idle call from prcm_irq to enable uart_port from low power states.
Comment is valid for OMAP3 but not for OMAP2. Maybe [01/12] should just
leave this call in for OMAP2
On Mon, Jun 27, 2011 at 08:32:03PM +0530, Jassi Brar wrote:
VUSB is a fixed level line and hence have no set_voltage
callback in regulator ops, but has apply_uV set to true.
As a result it fails to register with the regulator core.
Remove setting apply_uV.
Also, assign name to VUSB supply,
Todd,
On Sat, Jun 25, 2011 at 1:31 AM, Todd Poynor toddpoy...@google.com wrote:
On Fri, Jun 24, 2011 at 10:14:03AM -0500, Moiz Sonasath wrote:
...
+ if (enabled)
+ twl-vbus_enable = 1;
+ else
+ twl-vbus_enable = 0;
+
Suggest twl-vbus_enable = enabled;
On Mon, 27 Jun 2011, Tony Lindgren wrote:
This fix will cause bad dependency issues with sys_timer.
This patch has a dependency to omap3_beagle_init_rev, which depends on
the mux framework and gpio framework. Not cool for init_early. We just
want to initialize sys_timer early without any
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Monday, June 27, 2011 9:00 PM
To: Premi, Sanjeev; Tony Lindgren
Cc: Koen Kooi; linux-omap@vger.kernel.org List; linux-arm-kernel
Subject: Re: [PATCH] omap3: beagle: Use GPTIMERi 1 for clockevents
On Mon, 27 Jun
Hi Paul,
Here is the series that finally add the management of the modulemode
directly from hwmod fmwk instead of using a fake clock node to represent
the IP.
This v2 update is fixing a couple of regressions I introduced in the first
release.
A second series will clean most of the remaining
In OMAP PRCM terminology, the clock domain is defined as a group of IPs
that share some clocks and most of the time an interface clock.
Every IP does belong to a clockdomain.
For the moment the clock domain attribute is affected to a clock node.
The issue with that approach, is that a clock might
At boot time, lookup the clkdm_name to get the clkdm
structure pointer for further usage.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 34 +-
The CLKCTRL register was accessed using an absolute address.
The usage of hardcoded macros to calculate virtual address from physical
one should be avoided as much as possible.
The usage of a offset will allow future improvement like migration from
the current architecture code toward a module
It is mandatory to wait for a module to be in disabled state before
potentially disabling source clock or re-asserting a reset.
omap_hwmod_idle and omap_hwmod_shutdown does not wait for
the module to be fully idle.
Add a cm_xxx accessor to wait the clkctrl idle status to be disabled.
Fix
Since the clkdm is now part of the omap_hwmod structure, there is no need
to retrieve it from the main_clock or interface clock.
The code can be simplified a little bit with a direct access.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Rajendra Nayak
The RSTCTRL register was accessed using an absolute address.
The usage of hardcoded macros to calculate virtual address from physical
one should be avoided as much as possible.
The usage of an offset will allow future improvement like migration from
the current architecture code toward a module
The new prminst_xxx accessors based on partition and offset
is now used, so removed all the previous prcm_xxx accessors.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/prm44xx.c | 37
The interconnect modules were using a slightly different layout than
the regular modules.
Align the layout for better consitency.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 48
Add a 'context_offs' entry in the prcm.omap4 structure to all
IPs when applicable.
The offset will be used to retrieve the per module context lost
information now available on OMAP4.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Rajendra Nayak rna...@ti.com
In OMAP4, a new programming model based on module control instead
of clock control was introduced.
Expose two APIs to allow the upper layer (omap_hwmod) to control
the module mode independently of the parent clocks management.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley
Add a new field to provide the mode supported by the module.
The mode will control the way mandatory clocks are managed by the PRCM.
0 : Module is temporarily disabled by SW. OCP access to module are stalled.
Can be used to change timing parameter of GPMC module.
1 : Module is managed
Take advantage of the explicit modulemode control to fix
the way parents clocks are managed.
A module must be disabled before any parents are disabled.
That programming model was not possible with the previous
implementation that was considering a modulemode as a leaf
clock node managed by the
Hi Paul,
Here is an updated version of the series started by Rajendra.
It takes into account comments from Todd.
I had to update it because this series is mandatory for the hwmod
modulemodule control series.
I rebased it on top of the various fixes done on hwmod framework
to take advantage of
From: Rajendra Nayak rna...@ti.com
Add a clockdomain api to check if hardware supervised
idle transitions are enabled on a clockdomain.
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/clockdomain.c | 21 +
From: Rajendra Nayak rna...@ti.com
Add the SoC specific implemenation for clkdm_is_idle
for OMAP2/3 and OMAP4.
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/clockdomain2xxx_3xxx.c | 12
arch/arm/mach-omap2/clockdomain44xx.c
From: Rajendra Nayak rna...@ti.com
sleep_switch which is initialised to 0 in omap_set_pwrdm_state
happens to be a valid sleep_switch type (FORCEWAKEUP_SWITCH)
which are defined as:
#define FORCEWAKEUP_SWITCH 0
#define LOWPOWERSTATE_SWITCH1
This causes the function to wrongly program
From: Rajendra Nayak rna...@ti.com
The omap_set_pwrdm_state function forces clockdomains
to idle, without checking the existing idle state
programmed, instead based solely on the HW capability
of the clockdomain to support idle.
This is wrong and the clockdomains should be idled
post a
From: Rajendra Nayak rna...@ti.com
Since MMC driver is yet to be adapted to
runtime PM and still uses direct clock
calls to enable/disable module, its needed
that the clockdomain (for MMC) is always kept force
enabled since the next few patches move
the clockdomain handling from clock framework
Duplicate the existing API for clockdomain enable from clock to enable
a clock domain from hwmod framework.
This will be needed when the hwmod framework will move from the current
clock centric approach to the module based approach.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley
From: Rajendra Nayak rna...@ti.com
On OMAP4, the PRCM recommended sequence for enabling
a module after power-on-reset is:
-1- Force clkdm to SW_WKUP
-2- Enabling the clocks
-3- Configure desired module mode to enable or auto
-4- Wait for the desired module idle status to be FUNC
-5- Program clkdm
From: Rajendra Nayak rna...@ti.com
Since the clkdm state programming is now done from within the hwmod
framework (which uses a per-hwmod lock) instead of the being done
from the clock framework (which used a global lock), there is now a
need to have per-clkdm locking to prevent races between
Tony Lindgren t...@atomide.com writes:
* Santosh Shilimkar santosh.shilim...@ti.com [110623 08:09]:
On 6/23/2011 8:35 PM, Kevin Hilman wrote:
Tony Lindgrent...@atomide.com writes:
So now, the only thing OMAP-specific is the debugfs file used to trigger
it.
Maybe Kevin can just carry it
Hi Paul,
Here is the second part of the modulemode series.
The goal here is to do the cleanup on the clock nodes and PRCM macros
that are not needed anymore by the hwmod data.
Some macros are still needed because of clock data. It should be removed
once the clock data will be cleaned.
Moreover,
Change the debug into warning to check what IPs are failing.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c
Since the MMC driver is not pm_runtime adapted, do not put
them in idle after boot.
It will allow the driver to work as expected until the migration
to pm_runtime.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Rajendra Nayak rna...@ti.com
---
Extend the existing function to create clkdev for every optional
clocks to add a well one fck alias for the main_clk of the
omap_hwmod.
It will allow to remove these static clkdev entries from the
clockXXX_data.c file.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley
Previously, main_clk was a fake clock node that was accessing the
PRCM modulemode register. Since the module mode is directly
controlled by the hwmod fmwk, these fake clock node are not
needed anymore. The hwmod main_clk will point directly to the
input clock node if applicable.
For example, some
Since the timer is still not pm_runtime adapted, it is still
using directly the physical clock nodes at init time.
Replace the clock node by the original one in the clock data
file.
Keep the original name until the driver is fixed.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul
Tony Lindgren t...@atomide.com writes:
* Kevin Hilman khil...@ti.com [110623 17:32]:
Tony,
Please pull the following misc. OMAP PM updates targetted for v3.1.
This branch is based on your 'fixes' branch due to some dependencies.
OMAP2: PM debug: move wakeup timer into clockevent
Tony Lindgren t...@atomide.com writes:
* Tony Lindgren t...@atomide.com [110627 00:50]:
* Kevin Hilman khil...@ti.com [110623 10:06]:
Tony Lindgren t...@atomide.com writes:
+
+res = omap_dm_timer_init_one(clksrc, gptimer_id, fck_source);
This function makes calls into real
Tony Lindgren t...@atomide.com writes:
* Kevin Hilman khil...@ti.com [110623 09:56]:
Tony Lindgren t...@atomide.com writes:
There's no need to initialize the dmtimer framework early.
Actually, there is, because it's being used from the early code.
The sys_timer.init functions are
On Tue, May 31, 2011 at 10:51:39AM +0200, Sebastian Reichel wrote:
The driver is accessing to i2c bus in interrupt handler.
Therefore, it should use threaded irq.
I think the patch should also remove the local_irq_enable() call in
twl_rtc_interrupt, since it's no longer needed with threaded
Tony Lindgren t...@atomide.com writes:
* Kevin Hilman khil...@ti.com [110623 17:32]:
Tony,
Please pull the following misc. OMAP PM updates targetted for v3.1.
This branch is based on your 'fixes' branch due to some dependencies.
OMAP2: PM debug: move wakeup timer into clockevent
On Mon, 27 Jun 2011, Premi, Sanjeev wrote:
[sp] Can you look at my query to Tony? Will that be an acceptable
workaround until DT. Going to two machine IDs and then unifying
back again could cause confusion - esp. during transition times.
It's up to Tony, he's the maintainer...
-
Tony Lindgren t...@atomide.com writes:
This allows us to remove cpu_is_omap calls from init_irq functions.
There should not be any need for cpu_is_omap calls as at this point.
During the timer init we only care about SoC generation, and not about
subrevisions.
The main reason for the patch
There's no guarantee that the error handler worker thread
will run while the dispc clocks are on. Explicitly enable/disable
them.
Signed-off-by: Dima Zavin d...@android.com
---
drivers/video/omap2/dss/dispc.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git
Tony Lindgren t...@atomide.com writes:
This removes the support for setting the wake-up timer for debugging.
Later on we can reserve gptimer1 for PM code only and have similar
functionality.
Signed-off-by: Tony Lindgren t...@atomide.com
Reviewed-by: Kevin Hilman khil...@ti.com
Another
* Premi, Sanjeev pr...@ti.com [110627 06:24]:
[sp] While I take my time understanding things on devel-timer;
I had a quick question - at risk of being flamed.
Adding a new machine ID would trickle to u-boot and same
uImage (default) may not work across board revisions.
Yes
* Paul Walmsley p...@pwsan.com [110627 09:50]:
On Mon, 27 Jun 2011, Premi, Sanjeev wrote:
[sp] Can you look at my query to Tony? Will that be an acceptable
workaround until DT. Going to two machine IDs and then unifying
back again could cause confusion - esp. during transition
* Kevin Hilman khil...@ti.com [110627 09:25]:
Tony Lindgren t...@atomide.com writes:
* Santosh Shilimkar santosh.shilim...@ti.com [110623 08:09]:
On 6/23/2011 8:35 PM, Kevin Hilman wrote:
Tony Lindgrent...@atomide.com writes:
So now, the only thing OMAP-specific is the debugfs file
From: Sergei Shtylyov
Sent: Friday, June 24, 2011 8:14 AM
Grosen, Mark wrote:
It should work on DA830 as well,
So please make it dependent on ARCH_DAVINCI_DA8XX.
but not on real DaVinci, so the name is misleading...
Yes, we debated calling it da8xx, but felt that with
From: Nori, Sekhar
Sent: Friday, June 24, 2011 8:44 AM
Hi Mark,
Sekhar, thanks for your feedback and ideas. Comments below.
Mark
Since procedure to set the boot address varies across DaVinci
platforms, you could have a callback populated in platform data
which will be implemented
On Fri, Jun 24, 2011 at 04:38:05PM +0200, jean.pi...@newoldbits.com wrote:
...
+ /* Find the associated omap_device for dev */
+ od = container_of(pdev, struct omap_device, pdev);
+ if (!od || (od-hwmods_cnt != 1)) {
+ pr_err(%s: Error: No unique hwmod for device %s\n,
1 - 100 of 133 matches
Mail list logo
