Looping in OMAP ML to the good news..
Congrats!
sim0nx said the following on 04/05/2008 06:35 AM:
> I can't believe it !!!
> Android runs on the maemo n810 !!!
>
> After reading this:
> http://groups.google.lu/group/android-internals/browse_thread/thread/93570c41bce07f16?hl=en
> for the 100th time,
://groups.google.com/group/beagleboard/browse_thread/thread/80ad3da0eb2aa555
(Sample code also attached in the thread)
Do let us know your views.
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTE
6.html
Interesting... ;)... I never got 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
propriate?
in arch/arm/mach-omap2/Kconfig:
config MACH_OMAP_ZOOM2
bool "OMAP3 ZOOM2 board"
depends on ARCH_OMAP3 && ARCH_OMAP34XX
+select TWL4030_CORE if VIDEO_OMAP3
A similar strategy has been implemented for N800, albeit for other
peripherals.
Regar
Curran, Dominic said the following on 02/17/2009 04:27 PM:
>> -Original Message-
>> From: Nishanth Menon [mailto:[email protected]]
>> Sent: Tuesday, February 17, 2009 2:12 AM
>> To: Curran, Dominic
>> Cc: linux-omap; Aguirre Rodriguez, Sergio Alb
On Tue, Feb 17, 2009 at 6:02 PM, Aguirre Rodriguez, Sergio Alberto
wrote:
>> -Original Message-
>> From: Nishanth Menon [mailto:[email protected]]
>> Sent: Tuesday, February 17, 2009 9:33 AM
>> To: Curran, Dominic
>> Cc: linux-omap; Aguirre Rodriguez,
?
>
>
Just follow [1] to get the code downloaded. then look at
sound/soc/codecs/twl4030.c (quick link - [2])
Regards,
Nishanth Menon
Ref:
[1] http://muru.com/linux/omap/README_OMAP_GIT
[2]
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=blob;f=sound/so
50004 uSec (spec min is
0.6uSec)
tLow = ( scll +7 )*iclk =(5+7)*0.104167 = 1.250004 uSec (spec min is
1.3uSec <== I might be missing something here - but does that look like
some sort of violation?
Now, from a s/w perspective, If we would like to have it so that we can
configure tHigh and tLow
ably should give it as a platform
specific data. if this is not provided, use the run time computation..
just a thought..
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
vary based on electrical
characteristics of a platform? I mean beagleboard Vs Zoom Vs SDP
atleast have variances of i2c trace lengths and number of devices per
i2c bus.. wont the equation change based on board configuration?
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "uns
so that we can
configure tHigh and tLow based on devices, electrical characteristics on
a bus, not just speed of the bus, the current implementation would
probably need to change(I think).
"
maybe take tHigh, tLow as a platform data input to the driver? that
could allow scaling for all boards
Aaro Koskinen said the following on 02/24/2009 11:09 AM:
> ext Nishanth Menon wrote:
>> Oops.. copy-paste typo.. :(
>> tLow = (scll+3) * iclk
>> tHigh = (sclh+9) * iclk
>> Vs:
>> TRM:
>> tHigh = ( sclh +5 )*iclk period
>> tLow = ( scll +7 )*iclk per
Eero Nurkkala said the following on 03/06/2009 03:41 PM:
> On Thu, 2009-03-05 at 13:54 +0100, ext Menon, Nishanth wrote:
>
>> me? I am just a code junkie ;).. "They" wont let me write the TRM :(.. :D...
>>
>
> I was referring "you" in plural, meaning TI, not you personally =)
>
>
Aaaah.
>From b30537e692ac7e72858479327935b16813ea3f56 Mon Sep 17 00:00:00 2001
From: Nishanth Menon
Date: Wed, 11 Mar 2009 11:29:11 -0500
Subject: [PATCH] OMAP:clock: missing list_del for clk_notifier_unregister
Apologies on the spam.. looks like my git-send-email needs a bit more
tweaking :(.. send
al
<5>Memory: 125880KB available (3304K code, 307K data, 140K init, 0K highmem)
<6>Calibrating delay loop...
Has anyone tried this recently?
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Jarkko Nikula said the following on 04/09/2009 02:03 AM:
> On Thu, 9 Apr 2009 08:45:00 +0200
> ext Nishanth Menon wrote:
>
>
>> just messing around with tony's master branch on SDP3430, just did a
>> defconfig and a build with 2007q3-51 codesourcery comp
>From fdc5cc07b1e674ae081e331a62d0771124c3910f Mon Sep 17 00:00:00 2001
From: Nishanth Menon
Date: Thu, 9 Apr 2009 13:12:31 -0500
Subject: [PATCH] OMAP3: Rename configuration files
Rename 3430sdp and ldp with omap3 prefix
This allows for all omap3 configurations to be listed together
Signed-
Rename the 3430sdp and ldp defconfig to make
names to make them collected with omap3 filenames
Signed-off-by: Nishanth Menon
---
...p_3430sdp_defconfig => omap3_3430sdp_defconfig} |0
.../{omap_ldp_defconfig => omap3_zoom1_defconfig} |0
2 files changed, 0 insertions(+), 0 del
e addressed one way or another. So, can
> we have at least have a TODO file with these complaints?
>
>
;) Acked-by: Nishanth
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
ld. BTW, if you need to find out omap3
> boards, just $ grep CONFIG_ARCH_OMAP3 arch/arm/configs/
>
heh ;) sure.. np :)
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More major
omap_register_i2c_bus(2, 400, NULL, 0);
>> + omap_register_i2c_bus(3, 400, NULL, 0);
>> + return 0;
>> +}
This code badly worries me given the omap3 story and i2c bus
capacitance. The new code for omap4 should allow for scll and sclh to
be board specific configurable [1] and [2] - i would expect a si
e configuration..
e) for boards which are fine with default equations, the current
mechanism of providing speeds as parameter should be retained.
Unless we ensure we do it as part of initial driver, we will fall into
OMAP3 trap of inflexibility.. just my 2 cents
Regards,
Nishanth Menon
--
To unsu
data transfers can be
made at *up to* 100 kbit/s in the Standard-mode, *up to*
400 kbit/s in the Fast-mode, or *up to* 3.4 Mbit/s in the
High-speed mode"
Why do say high speed is >1000khz?
Thanks and Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "uns
Looping in list. my html mail bounced :(
Original Message
Subject:Re: [PATCH] i2c: omap: highspeed only over 1000mhz
Date: Mon, 20 Oct 2008 08:18:20 -0500
From: Nishanth Menon <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
CC: [email protected], Ben
gt;
> Any ideas?
>
See [1]. Further, you might want to look at the beagleboard discussion
archives in [2] - you may want to ask on that mailing list also though..
Regards,
Nishanth Menon
[1] http://elinux.org/BeagleBoardJTAG
[2] http://groups.google.com/group/beagleboard
--
To unsubsc
when the omap_opp structures are disabled by setting the
frequency as 0 as below (as an example)
{0, VDD2_OPP1, 0x1E},
program_opp attempts to set voltage even after frequency
setting fails. we can instead return if we see invalid
values for either frequency or voltage
Signed-off-by: Nishanth
changes done
Nishanth Menon (2):
OMAP3:PM:SR: prepare: remove old SR code
OMAP3:PM:SR: SmartReflex Refactor Rev2.0
arch/arm/mach-omap2/resource34xx.c |8 +-
arch/arm/mach-omap2/smartreflex.c | 1899 +---
arch/arm/mach-omap2/smartreflex.h | 241 +++---
arch
Preparation: remove original smart reflex code base.
This prevents the refactor appearing as a confusing diff
and hindering patch review process.
Signed-off-by: Nishanth Menon
Cc: Rajendra Nayak
Cc: Roger Quadros
Cc: Kalle Jokiniemi
Cc: Teerth Reddy
Cc: Kevin Hilman
Cc: Paul Walmsley
Cc
ons with Guilhem
Signed-off-by: Nishanth Menon
Cc: Rajendra Nayak
Cc: Roger Quadros
Cc: Kalle Jokiniemi
Cc: Teerth Reddy
Cc: Kevin Hilman
Cc: Paul Walmsley
Cc: Högander Jouni
Cc: Imberton Guilhem
Cc: Mike Chan
---
arch/arm/mach-omap2/resource34xx.c |8 +-
arch/arm/mach-omap2/smart
revision.
This revision is meant to be RFC due to the nature of
intrusive changes done
Nishanth Menon (2):
OMAP3:PM:SR: prepare: remove old SR code
OMAP3:PM:SR: SmartReflex Refactor Rev2.0
arch/arm/mach-omap2/resource34xx.c |8 +-
arch/arm/mach-omap2/smartreflex.c | 1899
_CS_CONFIG7);
> + }
>
here is a theoretical bug:
1: GPMC, 1, 2, 3 4 5 configured 6 7 not configured.
2. Save and restore 1: save and restore variables which are static will
contain 1-5 and not 6&7
3. next I disable 2,3
3. save will save 1,4,5 BUT my variable will contain 1,2,3,4,5 ->
restore will rename 2,3 (which I did not intend)..
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
ant to write to the IRQENABLE register even before configuring
the rest of the registers (such as data direction etc?
usually my understanding was:
configure the device,
enable the irq..
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
3, 0x30},
> + /*OPP4*/
> + {S550M, VDD1_OPP4, 0x36},
> + /*OPP5*/
> + {S600M, VDD1_OPP5, 0x3C},
> +};
>
For those involved,
if we wanted to convert omap3_mpu_table[] into *omap3_mpu_table so that
we dynamically initialize it based on cpu type - what would be the
recom
e is used in devices.
> - phyconfiguration
PHY - Physical timing configurations. btw, if it is camera specific you
could get a lot of inputs from [1].
Regards,
Nishanth Menon
Ref:
[1] http://vger.kernel.org/vger-lists.html#linux-media
--
To unsubscribe from this list: send the line "unsubscrib
Kevin Hilman had written, on 10/05/2009 11:56 AM, the following:
"Premi, Sanjeev" writes:
-Original Message-----
From: Nishanth Menon [mailto:[email protected]]
Sent: Saturday, October 03, 2009 8:35 PM
To: Premi, Sanjeev
Cc: [email protected]
Subject: Quest
risk of a glitch on the line (between the corrupted restore
data to the time we restore with correct data).
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo inf
UT my variable will contain 1,2,3,4,5 ->
restore will rename 2,3 (which I did not intend)..
I wonder if there should be an else with a memset to 0..
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vge
Kevin Hilman had written, on 10/05/2009 12:29 PM, the following:
Nishanth Menon writes:
+ gpmc_context.cs_context[i].is_valid =
+ (gpmc_cs_read_reg(i, GPMC_CS_CONFIG7))
+ & GPMC_CONFIG7_CSV
Kevin Hilman had written, on 10/05/2009 12:35 PM, the following:
Nishanth Menon writes:
Kevin Hilman said the following on 10/01/2009 06:58 PM:
From: Rajendra Nayak
Signed-off-by: Rajendra Nayak
---
arch/arm/plat-omap/gpio.c | 92
arch/arm
). AFAICT, the save hook will have cleared the
is_valid flag, so the restore will do nothing.
For clarity, I'm also going to modify this patch to set the is_valid
flag using gpmc_cs_mem_enabled() which make it more clear that
it's using the same check as gpmc_cs_[enable|disable]_mem()
Got
o overheads
Recommendation a.k.a hybrid approach:
* Each silicon has it's own static OPP table
* Each table has a invalid marker which is disabled for silicon variants
which dont need specific OPPs
* OPPs table be stored in a hash table a.k.a how do we optimize search
for OPP params?
--
Re
hope to see a final patch then I believe?
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
different OPPs in __initdata. Copy the
runtime detected CPU's OPP table in memory. Others get discarded!
I like this approach.. takers?
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.
revision and add errata number?
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
O BE NUMBERED... */
blah blah
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
W16_7XX_USB_PU_EN,
W17_7XX_USB_VBUSI,
+
+ /* MMC */
+ MMC_7XX_CMD,
+ MMC_7XX_CLK,
+ MMC_7XX_DAT0,
probably a dumb question -> but should'nt these go off to bootloader
perhaps?
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "
enable to clk_disable), when off mode was not enabled.
>
just a quick 2cents: I understand that the 500uSec might need to be
board dependent - here is why:
one theory we have regarding the timeout delay having to be modified on
zoom2 was that if the delay was 500uSec, the touch screen co
series are added, OMAP3430_REV_ES can be
added on top of the existing 3630 ones are renumbered
This patch was tested on SDP3430.
Signed-off-by: Madhusudhan Chikkature Rajashekar
Signed-off-by: Nishanth Menon
Signed-off-by: Vikram Pandita
Cc: Allen Pais
Cc: Anand Gadiyar
Cc: Benoit Co
able. we should be able to disable OPPs for each OPP
from the OPP array. with different silicons, we could have the same OPP
enabled/disabled. NAK -> need to handle based on mpu_opps[vale].rate ==0
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe li
y specifics should be feature based IMHO. we will need to extend
the feature list.
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
r follow on patches
Signed-off-by: Madhusudhan Chikkature Rajashekar
Signed-off-by: Nishanth Menon
Signed-off-by: Vikram Pandita
Cc: Allen Pais
Cc: Anand Gadiyar
Cc: Benoit Cousson
Cc: Felipe Balbi
Cc: Kevin Hilman
Cc: Sanjeev Premi
Cc: Santosh Shilimkar
Cc: Sergio Alberto Aguirre Rodriguez
the above noise..
any comments?
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
try the current l-o master
and make sure things work?
http://pastebin.mozilla.org/675489
3630 board with SDPdefconfig +8250 hack (with 3430 OPP values + wrong
GPIOs) -> boots up mostly fine..
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap&qu
using
3430sdp defconfig
Signed-off-by: Madhusudhan Chikkature Rajashekar
Signed-off-by: Nishanth Menon
Signed-off-by: Vikram Pandita
Cc: Allen Pais
Cc: Anand Gadiyar
Cc: Benoit Cousson
Cc: Felipe Balbi
Cc: Kevin Hilman
Cc: Sanjeev Premi
Cc: Santosh Shilimkar
Cc: Sergio Alberto Aguirre
s. Could we sync on this?
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
S/RTS that is expected?
>
> Yes, the loss of the first character is expected.
Curious Question: even with 3430 ES3.1 and IORING? I wonder why..
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord.
ore features, we decide which ones to
show.
this still a bunch of noise which is unusable for applications -> e.g.
if an app wanted to use ISP, how would it do it?
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a m
= &rx51_vaux3_cam;
rx51_twldata.vmmc2 = &rx51_vmmc2;
}
- omap_register_i2c_bus(1, 2600, rx51_peripherals_i2c_board_info_1,
+ omap_register_i2c_bus(1, 2200, rx51_peripherals_i2c_board_info_1,
why?
--
Regards,
Nishanth Menon
--
To unsubscribe from this list:
-omap please..
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
NOTE:
* If additional 34xx series are added, OMAP3430_REV_ES can be
added on top of the existing 3630 ones are renumbered
This patch was tested on SDP3430, boot tested on 3630 platform using
3430sdp defconfig
Signed-off-by: Madhusudhan Chikkature Rajashekar
Signed-off-by: Nishanth Menon
Signe
X can be
added on top of the existing 3630 ones are renumbered
This patch was tested on SDP3430, boot tested on 3630 platform using
3430sdp defconfig
Signed-off-by: Madhusudhan Chikkature Rajashekar
Signed-off-by: Nishanth Menon
Signed-off-by: Vikram Pandita
Cc: Allen Pais
Cc: Anand Gadiy
Tony Lindgren had written, on 10/09/2009 01:53 PM, the following:
* Nishanth Menon [091009 11:47]:
Tony Lindgren had written, on 10/09/2009 01:03 PM, the following:
* Aguirre Rodriguez, Sergio Alberto [091009 08:59]:
-Original Message-
From: Menon, Nishanth Sent: Friday, October
strcpy(cpu_name, "3430/3530");
> + }
> + else if (omap3_has_sgx()) {
> + omap_revision = OMAP3525_REV(rev);
your patch conflicts with mine unfortunately. could you introduce 36xx
on top of the aligned version for 36xx?
see http://marc.info/?t=12551041066&r=1&w=2
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
We used to enable and disable OPPs based on
rate being set to 0, this has been confusing in
general. So, allow specific OPPs to be now
enabled/disabled by an explicit enabled flag.
Recommendations from Kevin and Sanjeev contributed
to this patch
Tested on: SDP3430
Signed-off-by: Nishanth Menon
plicit enabled flag.
>>
>
> A dumb question, what is the intention of this flag?
>
the idea was to allow a field to properly disable the OPP instead of
reusing rate flag itself.
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsu
/disabled by an explicit enabled flag
instead of re-using rate flag itself.
Tested on: SDP3430
Cc: Sanjeev Premi
Cc: Kevin Hilman
Cc: Madhusudhan Chikkature Rajashekar
Cc: Sergio Alberto Aguirre Rodriguez
Signed-off-by: Nishanth Menon
---
arch/arm/mach-omap2/pm34xx.c | 32
Kevin Hilman had written, on 10/09/2009 04:37 PM, the following:
Nishanth Menon writes:
Refactor the smart reflex implementation.
One other request for this refactor.
Can you remove the usage of OMAP2_IO_ADDRESS (now gone from l-o master)
in favor of ioremap().
Here's a totally unt
e renumbered
This patch was tested on SDP3430, boot tested on 3630 platform using
3430sdp defconfig
Signed-off-by: Madhusudhan Chikkature Rajashekar
Signed-off-by: Nishanth Menon
Signed-off-by: Vikram Pandita
Cc: Allen Pais
Cc: Anand Gadiyar
Cc: Benoit Cousson
Cc: Felipe Balbi
Cc: Kevin
(IGEP2_GPIO_LED_0_GREEN, 1);
+ } else {
+ printk(KERN_ERR "could not obtain gpio for "
"GPIO_LED_0_GREEN\n");
+ }
+ if ((gpio_request(IGEP2_GPIO_LED_1_RED, "GPIO_LED_1_RED") == 0) &&
(gpio_direction_output(IGEP2_GPIO_LED_1_RED, 1) ==
troduce OMAP3630
>
> Below patch from Vikram fixes the build break.
>
ouch.. my bad.. thanks for answering my question. I am guessing we need
this coz of is_omap3630() translation..
Ack for the patch from me.
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line &qu
fine cpu_is_omap3430() is_omap3430()
so is it
#define cpu_is_omap() blah blah
or
#define cpu_is_omapblah blah
would have though it is cpu_is_omap()
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap"
f-by: Peter 'p2' De Schrijver
>
> These should be exported via debugfs instead of sysfs.
>
> Also, the SR rewrite is underway and will be merged shortly, so I
> recommend waiting until that is in place before we add this. Unless
> Nishanth wants to add it sooner.
>
: Thursday, October 15, 2009 7:24 AM
To: Pais, Allen; Aguirre Rodriguez, Sergio Alberto; linux-omap
Please try not to Top post. see [1]
--
Regards,
Nishanth Menon
Ref:
[1] http://www.arm.linux.org.uk/mailinglists/etiquette.php#e3
--
To unsubscribe from this list: send the line "unsubscribe linux
Cory Maccarrone had written, on 10/16/2009 09:15 AM, the following:
On Thu, Oct 15, 2009 at 9:53 PM, Nishanth Menon <mailto:[email protected]>> wrote:
Pais, Allen had written, on 10/15/2009 11:53 PM, the following:
a) A simple comment to all my comments: why cant we have these
omap3_check_revision() does not depend on omap3_check_features()
move this above so that we can add logic based on revision
detected in check_features.
Signed-off-by: Nishanth Menon
---
arch/arm/mach-omap2/id.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm
The patchset introduces jtype DPLLs which as a first stage
introduces it for 3630. 3430 has a previous version of DPLL
and process changes in 3630 neccessitates this for DPLL4
Patchset has been created for linux-omap - tmlind tree
Nishanth Menon (1):
OMAP3: move check_revision above
: Sonasath, Moiz Sonasath
Signed-off-by: Richard Woodruff
Signed-off-by: Nishanth Menon
---
arch/arm/mach-omap2/clock34xx.c | 45 ++-
arch/arm/mach-omap2/cm-regbits-34xx.h |6 +++-
arch/arm/mach-omap2/id.c|3 ++
arch/arm/plat-omap
this, this is introduced
as a omap3_has_jtype_dpll4() and is enabled for 3630
silicon
Tested with SDP3430, SDP3630
Cc: Vikram Pandita
Cc: Sonasath, Moiz Sonasath
Cc: Sergio Alberto Aguirre Rodriguez
Signed-off-by: Richard Woodruff
Signed-off-by: Nishanth Menon
---
arch/arm/mach-omap2
.
The choice is upto this community to make.. options are very easy to
implement ;).
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Nishanth Menon had written, on 10/20/2009 08:07 PM, the following:
Paul Walmsley had written, on 10/20/2009 06:14 PM, the following:
Hi Vikram, Nishanth, Richard,
a few comments on this:
On Tue, 20 Oct 2009, Vikram Pandita wrote:
Add bits for future expansion of omap_chip_id type field
tel(store_pad_config, CONTROL_PADCONF_ETK_D14);
^^^
omap_ctrl_writel?
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
s impact ALL OMAP3
variants such as 35xx,36xx as well as 34xx??
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi,
Smart Reflex sequencing recommendation has improved
in recent times and presents an opportunity to refactor
the code to add in understanding that we have of the
system. The patch set replaces smartreflex.c with a
new revision.
Revision 3 of the patch rebased to PM
Nishanth Menon (2):
OMAP3
Preparation: remove original smart reflex code base.
This prevents the refactor appearing as a confusing diff
and hindering patch review process.
Signed-off-by: Nishanth Menon
Cc: Rajendra Nayak
Cc: Roger Quadros
Cc: Kalle Jokiniemi
Cc: Teerth Reddy
Cc: Kevin Hilman
Cc: Paul Walmsley
Cc
Cc: Kalle Jokiniemi
Cc: Teerth Reddy
Cc: Kevin Hilman
Cc: Paul Walmsley
Cc: Högander Jouni
Cc: Mike Chan
Signed-off-by: Imberton Guilhem
Signed-off-by: Nishanth Menon
---
arch/arm/mach-omap2/pm-debug.c |3 +
arch/arm/mach-omap2/resource34xx.c |8 +-
arch/arm/mach-omap2/smartrefle
=11 will make it a
negative value, which is not helpeful.
so, the decrement has to be by 10 OR i can pad timeout_us .. not exactly
useful either..
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger
send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
Mor
h the modules shared accordingly in Makefile.
Camera is already doing that ;)
What do you think?
Ack.
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at http://
nk->chip.base + offset);
spin_unlock_irqrestore(&bank->lock, flags);
}
@@ -1700,6 +1721,7 @@ static int __init _omap_gpio_init(void)
gpio_count = 32;
}
#endif
+ bank->gpio_status = 0;
/* REVISIT eventually switch f
&& attempts) {
cpu_relax();
if (attempts % 5)
udelay(1);
attempts--;
}
allows the kernel to do somethin else while we also ensure we have a 5
usec guarenteed delay before giving up..
--
Regards,
N
* srid is standardised to u8 and it is not a bit field
* Guilhem's changes for non-twl5030 PMIC incorporated
* uses ioremap
V2 - made possible to work with non twl5030 PMICs
V1 - original rewrite
Requesting as much testing as possible and all comments welcome.
Nishanth Menon (2):
Preparation: remove original smart reflex code base.
This prevents the refactor appearing as a confusing diff
and hindering patch review process.
Signed-off-by: Nishanth Menon
Cc: Rajendra Nayak
Cc: Roger Quadros
Cc: Kalle Jokiniemi
Cc: Teerth Reddy
Cc: Kevin Hilman
Cc: Paul Walmsley
Cc
nnot comment - but it does look to
have scope of usage beyond omap2/3/4 series?
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
t;> + sr_vp_reset_voltage(srid);
>> +}
>> +EXPORT_SYMBOL(disable_smartreflex);
>> +
>> +/**
>> + * @brief enable_smartreflex - enable smart reflex after WFI is hit
>> + *
>> + * @param srid -SR ID to hit
>> + */
>> +void enable_smartreflex(u8 srid)
>>
>
> The naming is not coherent with previous API name sr_vp_enable_both. You
> should use the same denomination for smartreflex everywhere.
>
NAK - read the context please before you comment -> the call is from
cpu_idle perspective..
>
>> +{
>> + struct omap_sr *sr;
>> + int ret;
>> + u32 current_opp_no;
>> +
>> + /* I want to be in irq_disabled context..
>> + * else I will die.. find the rootcause and fix it instead
>> + */
>> + BUG_ON(!irqs_disabled());
>> +
>> + sr = get_sr(srid);
>> + current_opp_no = get_current_opp_number_from_sr(sr);
>> +
>> + if (sr->is_autocomp_active && sr->is_sr_reset) {
>> + ret = srvp_enable(sr, current_opp_no);
>> + if (ret)
>> + pr_err("SR[%d]:enable_smartreflex:"
>> +"failed enable SR\n", sr->srid);
>> + }
>> +}
>> +EXPORT_SYMBOL(enable_smartreflex);
>> +
>>
>
> [snip]
>
> For my point of view, this code should be dispatched into several files:
> smartreflex.c (pure SR IP driver), vp_vc.c (voltage processor and control),
> pmic driver, omap specific code and board initialization code.
>
come up with a clean proposal that can have code attached to it, or
better still a patch and I will gladly back my patch out.
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Alexander Shishkin had written, on 11/02/2009 07:12 AM, the following:
2009/10/21 Nishanth Menon :
Paul Walmsley had written, on 10/20/2009 06:14 PM, the following:
Hi Vikram, Nishanth, Richard,
a few comments on this:
On Tue, 20 Oct 2009, Vikram Pandita wrote:
Add bits for future
let's have it in, perhaps.
Tony, Kevin, upto you guys now..
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
nit omap_zoom2_init_irq(void)
+static void __init omap_zoom_init_irq(void)
Question on naming.. as raised above.
[...]
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo
+ .init_irq = omap_sdp_init_irq,
+ .init_machine = omap_sdp_init,
+ .timer = &omap_timer,
+MACHINE_END
nice and simple :).. thanks..
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
U General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef ARCH_ARM_MACH_OMAP2_SDRAM_HYNIX_H8MBX00U0MER0EM
^^^ maybe a prefix of __?
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-
purpose of #ifdef CONFIG_ARCH_OMAP in
arch/arm/plat-omap/include/plat/uncompress.h
is'nt it already OMAP?
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at
1 - 100 of 2458 matches
Mail list logo
