-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Menon, Nishanth
Sent: Thursday, May 26, 2011 7:27 AM
To: linux-omap
Cc: V, Aneesh; Menon, Nishanth
Subject: [RFC][PATCH 1/9] OMAP: ID: introduce chip detection
for
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Menon, Nishanth
Sent: Thursday, May 26, 2011 7:27 AM
To: linux-omap
Cc: Sonasath, Moiz; Menon, Nishanth
Subject: [RFC][PATCH 3/9] OMAP4460: HWMOD: DO not reset GPIO1
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Menon, Nishanth
Sent: Thursday, May 26, 2011 7:27 AM
To: linux-omap
Cc: Nayak, Rajendra
Subject: [RFC][PATCH 4/9] OMAP4: clocks: distinguish 4430 and 4460
From:
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Menon, Nishanth
Sent: Thursday, May 26, 2011 7:27 AM
To: linux-omap
Cc: Nayak, Rajendra
Subject: [RFC][PATCH 8/9] OMAP4: clockdomain: Use
CHIP_IS_44XX to reuse all
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Menon, Nishanth
Sent: Thursday, May 26, 2011 7:27 AM
To: linux-omap
Cc: Nayak, Rajendra
Subject: [RFC][PATCH 7/9] OMAP4: powerdomain: Update MPU
powerdomain for 4460
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
DebBarma, Tarun Kanti
Sent: Tuesday, May 24, 2011 7:55 PM
To: linux-omap@vger.kernel.org
Cc: Hilman, Kevin; Shilimkar, Santosh; t...@atomide.com;
On Thu, May 26, 2011 at 04:44, Kevin Hilman khil...@ti.com wrote:
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
From: Charulatha V ch...@ti.com
In set_24xx_gpio_triggering(), for OMAP4, GPIO wakeup request
is set for all type of GPIO triggers whereas as per TRM the GPIO
wakeup request can
On Thu, May 26, 2011 at 04:31, Kevin Hilman khil...@ti.com wrote:
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
It is not required to use hard-coded offsets any more in context
save and restore functions and instead use the generic offsets
which have been correctly initialized during device
On Thu, May 26, 2011 at 04:09, Kevin Hilman khil...@ti.com wrote:
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
From: Charulatha V ch...@ti.com
Make workaround_enabled flag bank-specific instead of using a single
flag for all the banks together. This would be helpful while making
use of
Kevin,
Thanks for the comments on this series.
On Thu, May 26, 2011 at 03:13, Kevin Hilman khil...@ti.com wrote:
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
From: Charulatha V ch...@ti.com
Modify the omap_gpio_save/restore_context to support OMAP4
architecture so that the OMAP GPIO
On Thu, May 26, 2011 at 03:04, Kevin Hilman khil...@ti.com wrote:
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
From: Charulatha V ch...@ti.com
Non-wakeup GPIOs are available only in OMAP2420 and OMAP3430. But
the GPIO driver initializes the non-wakeup GPIO bits for OMAP24xx
(bothe OMAP
On Thu, May 26, 2011 at 02:49, Kevin Hilman khil...@ti.com wrote:
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
From: Charulatha V ch...@ti.com
Remove cpu-is checks while enabling/disabling OMAP GPIO module
during a gpio request/free.
Signed-off-by: Charulatha V ch...@ti.com
This looks
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
DebBarma, Tarun Kanti
Sent: Tuesday, May 24, 2011 7:55 PM
To: linux-omap@vger.kernel.org
Cc: Hilman, Kevin; Shilimkar, Santosh; t...@atomide.com;
Sanjeev,
Thanks for the comments.
On Thu, May 26, 2011 at 14:53, Premi, Sanjeev pr...@ti.com wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
DebBarma, Tarun Kanti
Sent: Tuesday, May 24, 2011 7:55 PM
To:
Hi all,
I'll be away until 31st of May on a business travel. Don't expect me to
look into patches during that period.
Thanks :-)
--
balbi
signature.asc
Description: Digital signature
Sanjeev,
On Thu, May 26, 2011 at 15:12, Premi, Sanjeev pr...@ti.com wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
DebBarma, Tarun Kanti
Sent: Tuesday, May 24, 2011 7:55 PM
To: linux-omap@vger.kernel.org
Cc:
Kevin,
On Thu, May 26, 2011 at 04:57, Kevin Hilman khil...@ti.com wrote:
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
From: Charulatha V ch...@ti.com
Getting rid of ifdefs within the function by adding register offset intctrl
and associating OMAP_GPIO_INT_CONTROL in respective SoC
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
DebBarma, Tarun Kanti
Sent: Tuesday, May 24, 2011 7:55 PM
To: linux-omap@vger.kernel.org
Cc: Hilman, Kevin; Shilimkar, Santosh; t...@atomide.com;
-Original Message-
From: Premi, Sanjeev
Sent: Thursday, May 26, 2011 3:29 PM
To: DebBarma, Tarun Kanti; linux-omap@vger.kernel.org
Cc: Hilman, Kevin; Shilimkar, Santosh; t...@atomide.com;
linux-arm-ker...@lists.infradead.org; Varadarajan, Charulatha
Subject: RE: [PATCH 05/15]
Kevin,
On Thu, May 26, 2011 at 04:27, Kevin Hilman khil...@ti.com wrote:
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
Since wake_status, wake_clear, wake_set is common for all banks on a given
OMAP version it is enough to get their values once during probe().
Also, register offsets are
On Thu, May 26, 2011 at 15:28, Premi, Sanjeev pr...@ti.com wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
DebBarma, Tarun Kanti
Sent: Tuesday, May 24, 2011 7:55 PM
To: linux-omap@vger.kernel.org
Cc: Hilman,
On 5/26/2011 11:23 AM, Premi, Sanjeev wrote:
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
DebBarma, Tarun Kanti
Sent: Tuesday, May 24, 2011 7:55 PM
From: Charulatha Vch...@ti.com
Non-wakeup GPIOs are available only in OMAP2420 and OMAP3430. But
The call to pwrdm_wait_transition() in clkdm_clk_enable()
is redundant since the function pwrdm_clkdm_state_switch()
which is called next also does the same thing.
Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
---
arch/arm/mach-omap2/clockdomain.c |1 -
1 files changed, 0 insertions(+),
Hi Linus,
Please pull omap updates for this merge window from:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
omap-for-linus
This contains clean-up to shrink down omap specific code a bit. Also included
are some fixes. But basically no new code at this point.
Regards,
-Original Message-
From: Cousson, Benoit
Sent: Thursday, May 26, 2011 3:41 PM
To: Premi, Sanjeev
Cc: DebBarma, Tarun Kanti; linux-omap@vger.kernel.org;
Hilman, Kevin; Shilimkar, Santosh; t...@atomide.com;
linux-arm-ker...@lists.infradead.org; Varadarajan,
Charulatha; Paul
On 5/26/2011 1:47 PM, Premi, Sanjeev wrote:
-Original Message-
From: Cousson, Benoit
Sent: Thursday, May 26, 2011 3:41 PM
To: Premi, Sanjeev
Cc: DebBarma, Tarun Kanti; linux-omap@vger.kernel.org;
Hilman, Kevin; Shilimkar, Santosh; t...@atomide.com;
linux-arm-ker...@lists.infradead.org;
Tony,
What about this one: [PATCH v2] arm: omap2plus: move NAND_BLOCK_SIZE out of
boards
Why not include it? It is no new code, just generalize stuff and 11 lines
off... not much but still.
On 05/26/11 14:39, Tony Lindgren wrote:
Hi Linus,
Please pull omap updates for this merge window
* Igor Grinberg grinb...@compulab.co.il [110526 05:10]:
What about this one: [PATCH v2] arm: omap2plus: move NAND_BLOCK_SIZE out of
boards
Why not include it? It is no new code, just generalize stuff and 11 lines
off... not much but still.
Sorry I must have missed it.. Let's see if we
-Original Message-
From: Cousson, Benoit
Sent: Thursday, May 26, 2011 5:41 PM
To: Premi, Sanjeev
Cc: DebBarma, Tarun Kanti; linux-omap@vger.kernel.org;
Hilman, Kevin; Shilimkar, Santosh; t...@atomide.com;
linux-arm-ker...@lists.infradead.org; Varadarajan,
Charulatha; Paul
On 5/26/2011 2:38 PM, Premi, Sanjeev wrote:
-Original Message-
From: Cousson, Benoit
Sent: Thursday, May 26, 2011 5:41 PM
To: Premi, Sanjeev
Cc: DebBarma, Tarun Kanti; linux-omap@vger.kernel.org;
Hilman, Kevin; Shilimkar, Santosh; t...@atomide.com;
linux-arm-ker...@lists.infradead.org;
On 05/26/11 15:24, Tony Lindgren wrote:
* Igor Grinberg grinb...@compulab.co.il [110526 05:10]:
What about this one: [PATCH v2] arm: omap2plus: move NAND_BLOCK_SIZE out of
boards
Why not include it? It is no new code, just generalize stuff and 11 lines
off... not much but still.
Sorry I
* Igor Grinberg grinb...@compulab.co.il [110526 05:48]:
On 05/26/11 15:24, Tony Lindgren wrote:
* Igor Grinberg grinb...@compulab.co.il [110526 05:10]:
What about this one: [PATCH v2] arm: omap2plus: move NAND_BLOCK_SIZE out
of boards
Why not include it? It is no new code, just
Get rid of the following and 8 other similar section mismatch
warnings
WARNING: vmlinux.o(.text+0x2740c): Section mismatch in reference from the
function zoom_lcd_panel_init() to the (unknown reference) .init.data:(unknown)
The function zoom_lcd_panel_init() references
the (unknown reference)
On 5/26/2011 6:30 PM, Silesh C V wrote:
Get rid of the following and 8 other similar section mismatch
warnings
I send this [1] patch a month back. It's still not considered
though even after reminder.
Regards
Santosh
[1] https://patchwork.kernel.org/patch/684831/
--
To unsubscribe from this
-Original Message-
From: Cousson, Benoit
Sent: Thursday, May 26, 2011 6:17 PM
To: Premi, Sanjeev
Cc: DebBarma, Tarun Kanti; linux-omap@vger.kernel.org;
Hilman, Kevin; Shilimkar, Santosh; t...@atomide.com;
linux-arm-ker...@lists.infradead.org; Varadarajan,
Charulatha; Paul
* Santosh Shilimkar santosh.shilim...@ti.com [110526 05:56]:
On 5/26/2011 6:30 PM, Silesh C V wrote:
Get rid of the following and 8 other similar section mismatch
warnings
I send this [1] patch a month back. It's still not considered
though even after reminder.
[1]
Hi!
There's a number of down-counting clocksources using various methods to
convert to an up-counting value - sometimes -readl(), sometimes
cs-mask - readl() and sometimes ~readl().
Then there's those which are either 16-bit or 32-bit, and some of those
16-bit implementations must use
On Thu, May 26, 2011 at 06:37:32AM -0700, Tony Lindgren wrote:
* Santosh Shilimkar santosh.shilim...@ti.com [110526 05:56]:
On 5/26/2011 6:30 PM, Silesh C V wrote:
Get rid of the following and 8 other similar section mismatch
warnings
I send this [1] patch a month back. It's still not
ping
On 05/11/11 10:35, Igor Grinberg wrote:
Tony,
You can fold this one to the original patch from Mike as well,
or do you want it into the rc1?
On 05/04/11 20:22, Thomas Weber wrote:
Am 04.05.2011 17:04, schrieb Igor Grinberg:
introduced by: 96974a24
(omap: consolidate touch
On 05/26/11 16:37, Tony Lindgren wrote:
* Santosh Shilimkar santosh.shilim...@ti.com [110526 05:56]:
On 5/26/2011 6:30 PM, Silesh C V wrote:
Get rid of the following and 8 other similar section mismatch
warnings
I send this [1] patch a month back. It's still not considered
though even
On 5/26/2011 3:38 PM, B.J. Buchalter wrote:
Why not do the following:
#define OMAP_GPIO_REV_0 0
#define OMAP_GPIO_REV_1 1
#define OMAP_GPIO_REV_2 2
#define OMAP_GPIO_REV_3 3
/*
OMAP_GPIO_REV_0:OMAP2420
OMAP_GPIO_REV_1:OMAP2430
Why not do the following:
#define OMAP_GPIO_REV_0 0
#define OMAP_GPIO_REV_1 1
#define OMAP_GPIO_REV_2 2
#define OMAP_GPIO_REV_3 3
/*
OMAP_GPIO_REV_0:OMAP2420
OMAP_GPIO_REV_1:OMAP2430
OMAP_GPIO_REV_2:OMAP3, DMxxx
On 14:03-20110526, Premi, Sanjeev wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Menon, Nishanth
Sent: Thursday, May 26, 2011 7:27 AM
To: linux-omap
Cc: V, Aneesh; Menon, Nishanth
Subject: [RFC][PATCH 1
On 14:06-20110526, Premi, Sanjeev wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Menon, Nishanth
Sent: Thursday, May 26, 2011 7:27 AM
To: linux-omap
Cc: Sonasath, Moiz; Menon, Nishanth
Subject: [RFC
On 14:22-20110526, Premi, Sanjeev wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Menon, Nishanth
Sent: Thursday, May 26, 2011 7:27 AM
To: linux-omap
Cc: Nayak, Rajendra
Subject: [RFC][PATCH 7/9] OMAP4
Tomi Valkeinen tomi.valkei...@ti.com writes:
On Wed, 2011-05-25 at 13:30 -0700, Kevin Hilman wrote:
Tomi Valkeinen tomi.valkei...@ti.com writes:
On Wed, 2011-05-25 at 11:34 -0700, Kevin Hilman wrote:
Tomi Valkeinen tomi.valkei...@ti.com writes:
snip
+ if
Op 26 mei 2011, om 13:39 heeft Tony Lindgren het volgende geschreven:
Hi Linus,
Please pull omap updates for this merge window from:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
omap-for-linus
This contains clean-up to shrink down omap specific code a bit.
I came up with these patches while implementing pm runtime adaptation for DSS
driver. I'm not quite sure on who's turf they belong, or do they even belong
together, but here they are anyway.
get_context_loss_count patch was discussed on l-o with Kevin.
The omap_device_reset patch I made as some
Add omap_device_reset() function which can be used to reset the hwmods
associated with the given platform device.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/plat-omap/include/plat/omap_device.h |1 +
arch/arm/plat-omap/omap_device.c | 23
get_context_loss_count functions return context loss count as u32, and
zero means an error. However, zero is also returned when context has
never been lost and could also be returned when the context loss count
has wrapped and goes to zero.
Change the functions to return an int, with negative
Add hwmod and omap_device versions of can_ever_lose_context functions
so that drivers are able to use it.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 22 ++
arch/arm/plat-omap/include/plat/omap_device.h |1 +
Menon, Nishanth n...@ti.com writes:
On Wed, May 25, 2011 at 17:16, Kevin Hilman khil...@ti.com wrote:
Nishanth Menon n...@ti.com writes:
Since we have multiple CPUs, the cpuinit call for CPU1 causes
freq_table of CPU0 to be overwritten. Instead, we maintain
a counter to keep track of
Varadarajan, Charulatha ch...@ti.com writes:
On Thu, May 26, 2011 at 03:04, Kevin Hilman khil...@ti.com wrote:
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
From: Charulatha V ch...@ti.com
Non-wakeup GPIOs are available only in OMAP2420 and OMAP3430. But
the GPIO driver initializes the
Tomi Valkeinen tomi.valkei...@ti.com writes:
get_context_loss_count functions return context loss count as u32, and
zero means an error. However, zero is also returned when context has
never been lost and could also be returned when the context loss count
has wrapped and goes to zero.
Tomi Valkeinen tomi.valkei...@ti.com writes:
I came up with these patches while implementing pm runtime adaptation for DSS
driver. I'm not quite sure on who's turf they belong, or do they even belong
together, but here they are anyway.
get_context_loss_count patch was discussed on l-o with
Nishanth Menon n...@ti.com writes:
Clk name does'nt need to dynamically detected during clk init.
move them off to driver initialization, if we dont have a clk name,
there is no point in registering the driver anyways. The actual clk
get and put is left at cpu_init and exit functions.
Nishanth Menon n...@ti.com writes:
if we do not have mpu_dev we normally fail in cpu_init. It is better
to fail driver registration if the devices are not available.
Signed-off-by: Nishanth Menon n...@ti.com
Thanks, applied.
Kevin
--
To unsubscribe from this list: send the line unsubscribe
Nishanth Menon n...@ti.com writes:
OMAP2 is the only family using clk_[init|exit]_cpufreq_table, while
OMAP3+ use OPP table to generate and release the cpufreq tables.
Hence use a flag to mark which API to use for allocating and freeing
the tables.
Signed-off-by: Nishanth Menon n...@ti.com
Kevin,
On Thu, May 26, 2011 at 12:15, Kevin Hilman khil...@ti.com wrote:
Varadarajan, Charulatha ch...@ti.com writes:
On Thu, May 26, 2011 at 03:04, Kevin Hilman khil...@ti.com wrote:
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
From: Charulatha V ch...@ti.com
Non-wakeup GPIOs are
So here's a dumb question, being rather ignorant of CPUfreq on SMP.
Should we be running a CPUfreq instance on both CPUs when they cannot be
scaled independently?
What is being scaled here is actually the cluster (the MPU SS via
dpll_mpu_ck), not an individual CPU. So to me, it only makes sense
Nishanth Menon n...@ti.com writes:
Minor file header updates to reflect 2011 for omap2-cpufreq code
and remove misleading OMAP3 reference in omap1 cpufreq code.
Should probably be squashed to:
OMAP: cpufreq: Split OMAP1 and OMAP2PLUS CPUfreq drivers.
Thanks, squashed.
Kevin
Reported-by:
Varadarajan, Charulatha ch...@ti.com writes:
Kevin,
On Thu, May 26, 2011 at 12:15, Kevin Hilman khil...@ti.com wrote:
Varadarajan, Charulatha ch...@ti.com writes:
On Thu, May 26, 2011 at 03:04, Kevin Hilman khil...@ti.com wrote:
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
From:
On Thu, May 26, 2011 at 10:11, Kevin Hilman khil...@ti.com wrote:
When you're talking about potentially concurrent modification of data,
that make sense. Here you're implementing a plugin for an existing
framework, and you can (and have to) make assumptions about when the
callbacks are used.
On Thu, May 26, 2011 at 10:38, Kevin Hilman khil...@ti.com wrote:
I'd prefer to see this even cleaner by dropping the clk_* versions all
together. Then, for those who want OMAP2 support (currently not working
or validated anyways), all that's needed is to add a function simlilar
to
Hello Tomi, Kevin,
On Thu, 26 May 2011, Tomi Valkeinen wrote:
get_context_loss_count functions return context loss count as u32, and
zero means an error. However, zero is also returned when context has
never been lost and could also be returned when the context loss count
has wrapped and
On Thu, May 26, 2011 at 11:10, Kevin Hilman khil...@ti.com wrote:
So here's a dumb question, being rather ignorant of CPUfreq on SMP.
Should we be running a CPUfreq instance on both CPUs when they cannot be
scaled independently?
What is being scaled here is actually the cluster (the MPU SS
On Thu, May 26, 2011 at 11:35, Menon, Nishanth n...@ti.com wrote:
On Thu, May 26, 2011 at 10:38, Kevin Hilman khil...@ti.com wrote:
I'd prefer to see this even cleaner by dropping the clk_* versions all
together. Then, for those who want OMAP2 support (currently not working
or validated
!dev case needs iounmap before return.
Signed-off-by: Todd Poynor toddpoy...@google.com
---
arch/arm/mach-omap2/omap_phy_internal.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_phy_internal.c
b/arch/arm/mach-omap2/omap_phy_internal.c
index
A script of mine that reads the rev gpios on the beagleboard started failing
when I upgraded to .37, since board-omap3beagle.c doesn´t free the rev gpios
after using them.
Signed-off-by: Tasslehoff Kjappfot tasskj...@gmail.com
---
arch/arm/mach-omap2/board-omap3beagle.c |3 +++
1 files
Menon, Nishanth n...@ti.com writes:
On Thu, May 26, 2011 at 11:35, Menon, Nishanth n...@ti.com wrote:
On Thu, May 26, 2011 at 10:38, Kevin Hilman khil...@ti.com wrote:
I'd prefer to see this even cleaner by dropping the clk_* versions all
together. Then, for those who want OMAP2 support
jean.pi...@newoldbits.com writes:
From: Jean Pihet j-pi...@ti.com
Clean-up SRAM functions usage to better isolate PM code, in order
to allow it to be used as a module.
Could use some more description as to why this is needed. e.g. SRAM code
is built-in, but PM code pushed to SRAM is module,
jean.pi...@newoldbits.com writes:
From: Jean Pihet j-pi...@ti.com
Move the powerdomains time accounting code from in pm-debug to the
powerdomain code. The pm-debug code only displays the information on
request.
This also cleans up the core PM code, in order to allow it to be used
as a
Inspired by Jean's work to move PM code to modules, I decided it's
time to remove a bunch of ugly and difficult to maintain code from PM
debug.
The main chunk here is removing the register dump features for
OMAP2/OMAP3 which are awful to read, and impossible to scale for
OMAP4+. Also, there are
Remove the OMAP-specific PM debug 'sleep_while_idle' feature which is
currently available as an OMAP-specific debugfs entry.
This duplicates existing ARM-generic functionality available as a
boot-time option using the boot cmdline option 'hohlt'.
If runtime configuration of this is needed, then
Remove OMAP3-specific register dumping feature from PM debug layer.
This is removed because:
- it's ugly
- it's OMAP3-specific, and will obviously not scale to OMAP4+
- userspace /dev/mem-based tools (like omapconf) can do this much better
Signed-off-by: Kevin Hilman khil...@ti.com
---
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/pm-debug.c | 119
arch/arm/mach-omap2/pm.h |4 -
arch/arm/mach-omap2/pm24xx.c |6 +-
3 files changed, 2 insertions(+), 127 deletions(-)
diff --git
Move suspend wakeup timer from suspend path to be triggered based
on clockevent suspend path.
When gptimers are eventually converted to be a driver, the wakeup
timer feature can be made to be a driver-specific feature using the
driver's suspend method.
Signed-off-by: Kevin Hilman khil...@ti.com
jean.pi...@newoldbits.com writes:
From: Jean Pihet j-pi...@ti.com
Provide omap_pm_tick_nohz_get_sleep_length_us so that the code
from the OMAP PM modules can use it.
Signed-off-by: Jean Pihet j-pi...@ti.com
This patch is doing more than mentioned in the changelog.
---
jean.pi...@newoldbits.com writes:
From: Jean Pihet j-pi...@ti.com
Export the suspend_set_ops API as omap_pm_suspend_set_ops in the pm
generic code, under CONFIG_SUSPEND.
Note -hack warning-: since the 'suspend_valid_only_mem' function is
not exported to modules, fill the 'valid' field
Nishanth Menon n...@ti.com writes:
On 14:03-20110526, Premi, Sanjeev wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Menon, Nishanth
Sent: Thursday, May 26, 2011 7:27 AM
To: linux-omap
Cc: V, Aneesh
Nishanth Menon n...@ti.com writes:
From: Moiz Sonasath m-sonas...@ti.com
For OMAP4460, GPIO-7 of bank1 is used for controling
the TPS modes, hence GPIO1 should not be reset
during init as reset will cause the TPS voltage to
drop to 0.9 V.
ouch. I knew one of these days something like this
On Thu, May 26, 2011 at 16:15, Kevin Hilman khil...@ti.com wrote:
Nishanth Menon n...@ti.com writes:
On 14:03-20110526, Premi, Sanjeev wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Menon, Nishanth
Sent
On Thu, May 26, 2011 at 16:24, Kevin Hilman khil...@ti.com wrote:
Nishanth Menon n...@ti.com writes:
From: Moiz Sonasath m-sonas...@ti.com
For OMAP4460, GPIO-7 of bank1 is used for controling
the TPS modes, hence GPIO1 should not be reset
during init as reset will cause the TPS voltage to
Rev 4 of cleanups for cpufreq to take care of the review comments on
the remaining rev3 patches.
Applies on top of:
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git
branch: pm-wip/cpufreq
Tested on SDP4430 - with a TI internal loadgenerator controlled on each cpu
while
OMAP2+ all have frequency tables, hence the hacks we had for older
silicon do not need to be carried forward. As part of this change,
use cpufreq_frequency_table_target to find the best match for
frequency requested.
Signed-off-by: Nishanth Menon n...@ti.com
---
OMAP2 is the only family using clk_[init|exit]_cpufreq_table, however,
the cpufreq code has does not use clk_init_cpufreq_table. As a result,
it is unusuable for OMAP2 and only usable only on platforms using OPP
library.
So move the compilation for cpufreq only if OPP is available for the
Release the mpu_clk in fail paths.
Reported-by: Todd Poynor toddpoy...@google.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/omap2plus-cpufreq.c | 14 +++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/omap2plus-cpufreq.c
We use a single frequency table for multiple CPUs. But, with
OMAP4, since we have multiple CPUs, the cpu_init call for CPU1
causes freq_table previously allocated for CPU0 to be overwritten.
In addition, we dont free the table on exit path.
We solve this by maintaining an atomic type counter to
Reading the VPVOLTAGE field of PRM_VP_*_VOLTAGE registers currently
relies on a u32 - u8 conversion to mask off the FORCEUPDATEWAIT field
in the upper bits. Make this explicit using the mask and shift symbols
already defined, added as new fields in struct omap_vp_common.
Signed-off-by: Todd
On Fri, May 20, 2011 at 05:14:43PM +0200, Kevin Hilman wrote:
Start moving SoC-specific register handling out of the driver by passing
in register offsets in via platform data.
Also, move OMAP1 MPUIO IRQ handling over to genric IRQ chip.
Applies on top of Tony's for-next branch (which
On 5/26/2011 11:40 PM, Kevin Hilman wrote:
So here's a dumb question, being rather ignorant of CPUfreq on SMP.
Should we be running a CPUfreq instance on both CPUs when they cannot be
scaled independently?
What is being scaled here is actually the cluster (the MPU SS via
dpll_mpu_ck), not an
On 5/27/2011 4:32 AM, Kevin Hilman wrote:
Move suspend wakeup timer from suspend path to be triggered based
on clockevent suspend path.
When gptimers are eventually converted to be a driver, the wakeup
timer feature can be made to be a driver-specific feature using the
driver's suspend method.
On Thu, 2011-05-26 at 12:37 -0600, Paul Walmsley wrote:
Hello Tomi, Kevin,
On Thu, 26 May 2011, Tomi Valkeinen wrote:
get_context_loss_count functions return context loss count as u32, and
zero means an error. However, zero is also returned when context has
never been lost and could
On Thu, 2011-05-26 at 10:30 -0700, Kevin Hilman wrote:
Tomi Valkeinen tomi.valkei...@ti.com writes:
I came up with these patches while implementing pm runtime adaptation for
DSS
driver. I'm not quite sure on who's turf they belong, or do they even belong
together, but here they are
94 matches
Mail list logo
