the chance to debug this issue..
Kevin, Khasim, did u guys get a chance to look at this later?? I dont
recollect hearing any one saying the same for 3430 though..
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED
in
3630ES1.0 but exists on older (3430 ES3.1) and newer revisions.
Additionally, update some of the CHIP_GE_* macros to use other
macros for ease of maintenance.
Signed-off-by: Anand Gadiyar gadi...@ti.com
Cc: Nishanth Menon n...@ti.com
Cc: Manjunatha GK manj...@ti.com
[t...@atomide.com: update
OMAP4 Blaze (with TI u-boot, xloader, mmc boot): does not boot, hell lot
of crashes - note, need to explicitly enable MACH_OMAP4430_SDP in .config
full Bootlog: http://pastebin.mozilla.org/761968
[...]
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux
khil...@deeprootsystems.com
Cc: Manjunath K manj...@ti.com
Cc: Anand Gadiyar gadi...@ti.com
Cc: Felipe Balbi felipe.ba...@nokia.com
Cc: linux-omap@vger.kernel.org
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/id.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff
sr_dev_init should return error on error conditions
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Thara Gopinath th...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/sr_device.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach
=127750241431955w=2 (June 25)
omap3: sr: device: add unlikely checks was dropped from this series
based on Artem's guidance - none of the other patches have recieved
any review comments so far.
Nishanth Menon (12):
omap3: voltage: cleanup pr_
omap3: voltage: make required variables static
omap3
In the unlikely case that hwmod database is messed up, dont crash
report error and attempt to recover.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Thara Gopinath th...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/sr_device.c |6 ++
1 files changed, 6
: Kevin Hilman khil...@deeprootsystems.com
Cc: Thara Gopinath th...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/plat-omap/include/plat/smartreflex.h |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/smartreflex.h
b/arch/arm
. Should it be static?
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Thara Gopinath th...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/voltage.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2
it be static?
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Thara Gopinath th...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
Note: i had initially considered splitting these into three seperate patches,
but these are too trivial.
arch/arm/mach-omap2/voltage.c |6 +++---
1 files
it be static?
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Thara Gopinath th...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/sr_device.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/sr_device.c b/arch/arm/mach-omap2
pr_xxx family is not informative for debug unless one decides
to grep the code, instead print the function to help debug
easier on the field.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Thara Gopinath th...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2
sr_exit has no business being a public function.
fixes sparse:
arch/arm/mach-omap2/smartreflex.c:959:13: warning: symbol 'sr_exit' was not
declared. Should it be static?
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Thara Gopinath th...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
Few more pr_ need cleanup for printing the function name and
not using multiline prints when c allows us to do .
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Thara Gopinath th...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/voltage.c |7 ---
1 files
We dont need to go down the path of enabling/disabling the SR
if we dont need to. do some sanity check and trigger if needed
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Thara Gopinath th...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/smartreflex.c | 19
Kevin Hilman had written, on 08/05/2010 05:29 PM, the following:
Nishanth Menon n...@ti.com writes:
Kevin Hilman had written, on 08/04/2010 05:50 PM, the following:
[...]
I've only tested the new PM branch on a couple boards to avoid any
further delay getting this version out, update, so
have that
intelligence there, and my suggestion - it is better to do the check
before calling a helper function.
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
if they passed device_build?).. if
they are, what is the point in enabling SR in half the domains - we
should flag this as an error to developer and get him to fix it instead
of encouraging this slipping by half a dozen developers as only sr_l3
failed or something similar..
Regards,
Nishanth Menon
/12. sorry.
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
kevin's pm branch is what I work on and post to l-o. I am
not interested if others have a private tree that none in this community
can see or work with - sorry l-o does not provide me an indication on an
alternate kernel tree for sr development!
Regards,
Nishanth Menon
--
To unsubscribe
On 08/06/2010 02:42 AM, Gopinath, Thara wrote:
-Original Message-
From: Menon, Nishanth
Sent: Friday, August 06, 2010 3:54 AM
To: linux-omap
Cc: Menon, Nishanth; Kevin Hilman; Gopinath, Thara
Subject: [PM-SR][PATCH 01/12] omap3: voltage: cleanup pr_
Few more pr_ need cleanup
Mark Brown had written, on 08/06/2010 07:18 AM, the following:
On Fri, Aug 06, 2010 at 06:08:03AM -0500, Nishanth Menon wrote:
Well that is my motivation here. if driver reports a warning to kernel
syslog, well, I expect the log to contain the function name for me to
maintain faster
Mark Brown had written, on 08/06/2010 08:32 AM, the following:
On Fri, Aug 06, 2010 at 08:10:44AM -0500, Nishanth Menon wrote:
a) when the strings are split up when they go multiple lines:
E.g.:
abcd
efg
print comes out abcd efg
That's generally considered bad practice
khil...@deeprootsystems.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Sanjeev Premi pr...@ti.com
Cc: Thara Gopinath th...@ti.com
Cc: Tony Lindgren t...@atomide.com
Signed-off-by: Nishanth Menon n...@ti.com
---
NOTE: for those desiring to live with SRF will have to revert
...@atomide.com
Signed-off-by: Nishanth Menon n...@ti.com
---
Note:
This takes care of the discussion on opp file renaming and making
it independent of cpufreq, unless I missed something else
arch/arm/mach-omap2/Makefile |5 +
.../mach-omap2/{cpufreq34xx.c = opp3xxx_data.c
Cc: Rajendra Nayak rna...@ti.com
Cc: Sanjeev Premi pr...@ti.com
Cc: Thara Gopinath th...@ti.com
Cc: Tony Lindgren t...@atomide.com
Regards,
Nishanth Menon
Ref:
[1]: http://marc.info/?t=12749597273r=1w=2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body
khil...@deeprootsystems.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Sanjeev Premi pr...@ti.com
Cc: Thara Gopinath th...@ti.com
Cc: Tony Lindgren t...@atomide.com
Signed-off-by: Nishanth Menon n...@ti.com
---
v1: original patch https://patchwork.kernel.org/patch/118723/
v2
to have it in the same file? Remember, 3630,3430 are
under OMAP3 family, but omap4 is considered a different arch.
Regards,
Nishanth Menon
[...]
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
On 08/11/2010 06:23 AM, Gopinath, Thara wrote:
-Original Message-
From: Nishanth Menon [mailto:menon.nisha...@gmail.com]
Sent: Wednesday, August 11, 2010 4:14 PM
To: Gopinath, Thara
Cc: Menon, Nishanth; linux-omap; Eduardo Valentin; Kevin Hilman; Paul Walmsley;
Nayak, Rajendra;
Premi
Kevin Hilman had written, on 08/11/2010 06:46 PM, the following:
Nishanth Menon n...@ti.com writes:
Remove the concept of opp_id now that SRF is gone from pm branch
the new framework should exist on silicon variants without the
notion of opp ids
[...]
arch/arm/plat-omap/include/plat/opp.h
it makes sense to introduce
SOC specific API library for usage. hoping for some suggestions to
enlighten us.
Ref:
[1] http://marc.info/?t=12795577423r=1w=2
[2] http://dri.sourceforge.net/doc/hardware_locking_low_level.html
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send
files have a very simple init function (device_initcall) that just
registers
their data.
yep, this sounds like a good idea, let me try something on this line and
post a new rev..
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body
variables
patch 2 - fix sparse warnings functions that should have been static
patch 3 - fix specific warnings/errors?
makes this patch at least readable in some context.. this patch in
effect is almost equivalent to - fix all build warnings on
arch/arm/mach-omap2...
[...]
--
Regards,
Nishanth
On 08/16/2010 11:36 PM, Thara Gopinath wrote:
OMAP4 has an iva device and a dsp devcice where as OMAP2/3
has only an iva device. In this file the iva device in the
a bit confused regarding this - IVA on OMAP3 was a C64 DSP. OMAP3 also
had iva accelerators, but ARM does not directly talk to the
in s/w implementation
c) lock handling - esp impact on omap_sram_idle paths..
--
Regards,
Nishanth Menon
PS:personally though concept of latency additions when scaling voltages,
disabling SR etc should be a parameter in userspace governor decisions
(the fact that cpuidle and cpufreq
Felipe Balbi had written, on 09/02/2010 05:00 AM, the following:
On Thu, 2 Sep 2010 03:17:56 -0500, Nishanth Menon n...@ti.com wrote:
Just brainstorming - if we use the regulator framework - there are
potential benefits - agreed. BUT, consider the cpuidle path - currently
we disable SR while
Felipe Balbi had written, on 09/02/2010 05:28 AM, the following:
Hi,
On Thu, 2 Sep 2010 05:17:01 -0500, Nishanth Menon n...@ti.com wrote:
note - if we allow unlock of irqs at this point, we cannot predictably
progress down the logic.
spin_unlock() would not re-enable IRQs, would it ? Isn't
Kevin Hilman had written, on 09/02/2010 12:47 PM, the following:
Nishanth Menon n...@ti.com writes:
Thomas Petazzoni had written, on 09/02/2010 02:43 AM, the following:
Hello,
On Wed, 01 Sep 2010 15:51:40 -0700
Kevin Hilman khil...@deeprootsystems.com wrote:
Looking closer at this, keeping
your mailer to round off for 70/80 chars..
- might be good to point folks to rfc patchset for voltage layer to give
context.
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info
-specific these days, so why should
OPPs be?
As far as I see this patch :
hwmod[1] which is omap specific which inturn depends on omap_device. -
this impacts opp_add function in the opp layer.
[1] http://marc.info/?l=linux-omapm=128226580816341w=2
--
Regards,
Nishanth Menon
--
To unsubscribe from
+++ b/arch/arm/plat-omap/opp.c
@@ -0,0 +1,461 @@
+/*
+ * OMAP OPP Interface
+ *
+ * Copyright (C) 2009-2010 Texas Instruments Incorporated.
+ * Nishanth Menon
+ * Romit Dasguptaro...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms
for voltage layer to give
context.
https://patchwork.kernel.org/patch/119429/
thanks..
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
enable disable based on previous
discussion in l-o - the framework to use opp layer in that manner is yet
to go up yet.
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info
anything for us.
thanks.. The only contention ahead is: where do we want this?
Is drivers/opp/opp_core.c the right place? Given that this is just a
support library and not really a driver? for some reason lib/opp.c
does'nt sound just right either :(
[..]
--
Regards,
Nishanth Menon
/arch/mach-soc/oppdata_xyz.c or what ever they choose
the intent being lib/ is no place to put mach or arch specific data
definitions.. it is just noise..
if folks are ok with this, will post a new rev soonish..
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line
/khilman/linux-omap-pm.git;a=blob;f=drivers/mfd/twl4030-core.c;h=769b34bd48e445880ac0920423d9b73eabaf4cb7;hb=HEAD
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
Mark Brown had written, on 09/17/2010 10:36 AM, the following:
On Thu, Sep 16, 2010 at 08:29:33PM -0500, Nishanth Menon wrote:
+struct opp_def {
+ unsigned long freq;
+ unsigned long u_volt;
+
+ bool enabled;
+};
It might be clearer to use some term other than enabled
Rafael J. Wysocki had written, on 09/17/2010 05:22 PM, the following:
On Friday, September 17, 2010, Nishanth Menon wrote:
Mark Brown had written, on 09/17/2010 10:36 AM, the following:
On Thu, Sep 16, 2010 at 08:29:33PM -0500, Nishanth Menon wrote:
+struct opp_def {
+ unsigned long
vishwanath...@ti.com
Cc: Linus Walleij linus.wall...@stericsson.com
Cc: Mark Brown broo...@opensource.wolfsonmicro.com
Cc: Andrew Morton a...@linux-foundation.org
Cc: Rafael J. Wysocki r...@sisk.pl
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
Greg KH had written, on 09/18/2010 12:38 AM, the following:
On Sat, Sep 18, 2010 at 12:24:19AM -0500, Nishanth Menon wrote:
This is hence introduced under lib allowing all architectures to
selectively enable the feature based on their capabilities.
snip
Documentation/power/00-INDEX |2
Menon, Nishanth had written, on 09/18/2010 12:42 AM, the following:
Greg KH had written, on 09/18/2010 12:38 AM, the following:
On Sat, Sep 18, 2010 at 12:24:19AM -0500, Nishanth Menon wrote:
This is hence introduced under lib allowing all architectures to
selectively enable the feature based
Gopinath th...@ti.com
Cc: Vishwanath BS vishwanath...@ti.com
Cc: Linus Walleij linus.wall...@stericsson.com
Cc: Mark Brown broo...@opensource.wolfsonmicro.com
Cc: Andrew Morton a...@linux-foundation.org
Cc: Rafael J. Wysocki r...@sisk.pl
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Kevin
/* CONFIG_CPU_FREQ */
The rest looks fine to me.
thx.
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
-by: Nishanth Menon n...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
V4:
Cc list trimmed to just the MLs.
RCU implementation - thanks for the pointers Rafael
re-tested on OMAP3630 with lock debugging enabled including cpufreq,
idle paths and exception cases - enable/disable
on
it's feasibility..
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Paul Walmsley had written, on 09/24/2010 12:17 PM, the following:
On Fri, 24 Sep 2010, Paul Walmsley wrote:
On Fri, 24 Sep 2010, Nishanth Menon wrote:
The intent of omap_has_featureX() is to ensure that the drivers dont do
cpu_is_omap123(). Now if we had OMAP dma driver which has DMA
.
[...]
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Paul E. McKenney had written, on 09/25/2010 07:56 PM, the following:
On Sat, Sep 25, 2010 at 10:55:20PM +0200, Rafael J. Wysocki wrote:
On Friday, September 24, 2010, Paul E. McKenney wrote:
On Fri, Sep 24, 2010 at 07:50:40AM -0500, Nishanth Menon wrote:
...
Looks like a good start!!! Some
for me!
thx.
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
to give the iXYZ id as well for some of these
erratas might scale across processors.
+ if (cpu_is_omap34xx() (l OMAP_DMA_CCR_SEL_SRC_DST_SYNC)) {
does it make sense to use an dma_errata variable and populate it?
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line
variable to
help track them all..
[...]
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Peter Ujfalusi had written, on 10/01/2010 03:51 AM, the following:
On Friday 01 October 2010 10:45:12 ext Nishanth Menon wrote:
...
- l = ~OMAP_DMA_CCR_EN;
- dma_write(l, CCR(lch));
+ /* OMAP3 Errata: sDMA FIFO draining does not finish */
would be informative to give the iXYZ
...@linux.vnet.ibm.com
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
V5:
opp pointers were being passed to callers outside rcu locks, this
causes the pointers to be potentially invalid between calls if
opp_enable/disable calls take place.
The solution
Rafael J. Wysocki had written, on 10/04/2010 05:36 PM, the following:
On Friday, October 01, 2010, Nishanth Menon wrote:
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points
Kevin Hilman had written, on 10/05/2010 03:50 PM, the following:
Rafael J. Wysocki r...@sisk.pl writes:
On Tuesday, October 05, 2010, Nishanth Menon wrote:
Rafael J. Wysocki had written, on 10/04/2010 05:36 PM, the following:
On Friday, October 01, 2010, Nishanth Menon wrote:
[...]
I'm
...@linux.vnet.ibm.com
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
V6:
mutexes reduced to a single one. dev_opp_list_lock now protects
both the devices and the opp lists, doc updated accordingly.
fixed opp_add removed an irrelevant find_device_opp, used
dont
solve the real issue of namespace here. fix should be in
arch/arm/include/asm/io.h IMHO. so that there are no overlaps as this.
[1]http://marc.info/?l=linux-omapm=128506333803725w=2
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body
...@linux.vnet.ibm.com
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
V7:
removed pr_fmt and used dev_err/warn instead of pr_xx family where
possible
replaced out1 label with unlock to make it readable
Accepted a offline suggestion to use IS_ERR_OR_NULL
__u16)cpu_to_le16(v), p); })
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Rafael J. Wysocki had written, on 10/09/2010 05:59 PM, the following:
[...]
Signed-off-by: Nishanth Menon n...@ti.com
OK
Your error messages are a bit inconsistent (e.g. some of them print the
error code while others don't), but I guess I can fix that up.
Thanks a bunch.
Still, to apply
Rafael J. Wysocki had written, on 10/12/2010 06:25 PM, the following:
On Tuesday, October 12, 2010, Rafael J. Wysocki wrote:
On Monday, October 11, 2010, Nishanth Menon wrote:
Rafael J. Wysocki had written, on 10/09/2010 05:59 PM, the following:
[...]
Signed-off-by: Nishanth Menon n...@ti.com
Elvis Dowson had written, on 10/14/2010 06:08 PM, the following:
Hi Nishanth,
On Oct 15, 2010, at 2:56 AM, Nishanth Menon wrote:
Dont have a board-sholes-hsmm.c in l-o[1]... :( so not sure which kernel you
are talking about here.
This is in the omapzoom, p-android-omap-2.6.32 branch
http
Elvis Dowson had written, on 10/14/2010 06:18 PM, the following:
Hi,
On Oct 15, 2010, at 2:56 AM, Nishanth Menon wrote:
mainline does it this way:
board files report using omap2_hsmmc_info[2] to hsmmc.c using
omap2_hsmmc_init[3] - hsmmc.c
converts them to required datastructures
at this patch - the commit
message and $subject should explain to them as well..
more as part of patch 1 review comments.
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info
,
+ .reserve= omap_reserve,
+ .init_irq = am3517_crane_init_irq,
+ .init_machine = am3517_crane_init,
+ .timer = omap_timer,
+MACHINE_END
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message
to the same and make mmc work.
Cc: Tony Lindgren t...@atomide.com
Cc: Madhusudhan Chikkature madhu...@ti.com
Cc: Adrian Hunter adrian.hun...@nokia.com
Cc: Samuel Ortiz sa...@linux.intel.com
Acked-by: Kishore Kadiyala kishore.kadiy...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
Depends on
http
...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
Depends on
http://git.kernel.org/?p=linux/kernel/git/sameo/mfd-2.6.git;a=commitdiff;h=1bf5197061a4aec99e9fd4f92d4a543310f83585;hp=0c9b33e5a23e2053165c9e303b3a3cf1b2b8
This patch probably should be squashed to that.
Note to Tony/Sameo:
I
to kernel.org
Sync pandaboard to the same and make mmc work.
Cc: Tony Lindgren t...@atomide.com
Cc: Madhusudhan Chikkature madhu...@ti.com
Cc: Adrian Hunter adrian.hun...@nokia.com
Cc: Samuel Ortiz sa...@linux.intel.com
Acked-by: Kishore Kadiyala kishore.kadiy...@ti.com
Signed-off-by: Nishanth Menon n
;h=252e3d0cb6050a64f390b9311c1c4977d74f762a;hb=refs/heads/omap4_next
Signed-off-by: Thara Gopinath th...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
[...@ti.com: cleaned up, synced to latest code, removed iva,dsp,gpu,aess
as these hwmods are not added yet to l-o for-next. Retaining Thara's
=252e3d0cb6050a64f390b9311c1c4977d74f762a;hb=refs/heads/omap4_next
Kevin Hilman (1):
OMAP3: remove OPP interfaces from OMAP PM layer
Nishanth Menon (2):
omap: opp: add OMAP3 OPP table data and common init
omap4: opp: add OPP table data
arch/arm/mach-omap2/Kconfig |2 +
arch/arm/mach-omap2
Add OPP data for OMAP34xx and OMAP36xx and initialization functions
to populate OPP tables based on current SoC.
introduce an OMAP generic opp initialization routine which OMAP3
and OMAP4+ SoCs can use to register their OPP definitions.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off
From: Kevin Hilman khil...@deeprootsystems.com
With new OPP layer, OPP users will access OPP API directly instead of
using OMAP PM layer, so remove all notions of OPPs from the OMAP PM
layer.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
register today
and hence its not something to be done from a insmod'able 'driver'.
[sp] How does this work for - say dspbridge - where the DSP as device
may not be 'registered' until it is really expected to be used?
arch/arm/mach-omap2/dspbridge.c? ;)
--
Regards,
Nishanth Menon
--
To unsubscribe
if you'd like better ideas from the community I guess.
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
:(
[...]
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
when he creates his
usual defconfig cleanups :)
look at commit ids:
58e111621d402d41cb0cabae7c532d6194b7d943 - IGEP board
b075f58b2c0f377b4bfbe11b817e003393bcb489 - PandaBoard
for examples how the board introductions have been done recently.
[...]
rest looks ok to me.
--
Regards,
Nishanth
From: Arno Steffen arno.stef...@googlemail.com
OMAP3_IVA_MASK should use OMAP3_IVA_SHIFT instead of OMAP3_SGX_SHIFT
Signed-off-by: Arno Steffen arno.stef...@googlemail.com
---
Sending on behalf of Arno - he pointed at the change and everything
except for the patch ;)
Reported here:
rebase --continue
OR
edit the patch Manually and change:
From: Ionut Nicu ionut.n...@gmail.com
to
From: Felipe Contreras felipe.contre...@gmail.com
The From shows the authorship, that way, when you do a git send email,
the proper acknowledgements are done :)
--
Regards,
Nishanth Menon
as a result
- but we ought to get this fixed at some point.
Regards,
Nishanth Menon
Original Message
Subject: ARM: OMAP3/4: proposal: Cleanup MUX
Date: Fri, 05 Nov 2010 15:56:46 -0400
From: Nishanth Menon menon.nisha...@gmail.com
To: u-b...@lists.denx.de
Folks,
I would like to work
of
a great Linux phone like N900 is definitely not my personal preference.
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Mans Rullgard m...@mansr.com
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
;h=252e3d0cb6050a64f390b9311c1c4977d74f762a;hb=refs/heads/omap4_next
Signed-off-by: Thara Gopinath th...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
Warning: http://lkml.org/lkml/2010/11/9/389
Introduces ARCH_HAS_OPP which needs to be enabled as well
for OMAP4 in Kconfig
v3
Series version 3 incorporating changes for the comments
for using device_initcall to initialize the opp layer
patches based on kernel.org 2.6.37-rc1
V2: http://marc.info/?t=12875366533r=1w=2
Kevin Hilman (1):
OMAP3: remove OPP interfaces from OMAP PM layer
Nishanth Menon (2):
omap: opp
Signed-off-by: Nishanth Menon n...@ti.com
---
Warning: http://lkml.org/lkml/2010/11/9/389
Introduces ARCH_HAS_OPP which needs to be enabled as well
for OMAP3 in the Kconfig
v3:
* added documentation for custom opp modification
by board files
* switched to using device_initcall
From: Kevin Hilman khil...@deeprootsystems.com
With new OPP layer, OPP users will access OPP API directly instead of
using OMAP PM layer, so remove all notions of OPPs from the OMAP PM
layer.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
v3
Thomas Petazzoni had written, on 11/15/2010 04:51 PM, the following:
Hello,
On Mon, 15 Nov 2010 13:27:39 -0600
Nishanth Menon n...@ti.com wrote:
+++ b/arch/arm/mach-omap2/opp3xxx_data.h
+
+static struct omap_opp_def __initdata omap34xx_opp_def_list[] = {
+
+static struct omap_opp_def
, system can still survive without cpufreq, no need to stop system
operations because of that.
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
from having no OPP table (the case where a NULL OPP
table is passed is tested *before* in omapX_init_opp()).
HUH?? NULL table to a static function - what code are you talking
about?? why are you so behind BUG_ON, when there are valid reasons for
reentry into code.
--
Regards,
Nishanth Menon
://marc.info/?l=linux-omapm=127507237109393w=2
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Thomas Petazzoni had written, on 11/16/2010 09:50 AM, the following:
On Tue, 16 Nov 2010 09:23:06 -0600
Nishanth Menon n...@ti.com wrote:
my initial implementation had forced board files to call the
opp_init_table, then changed that here:
http://marc.info/?l=linux-omapm=127431810922704w=2
1 - 100 of 2389 matches
Mail list logo
