Re: [PATCH 2/9 v2] omap3: pm: introduce opp accessor functions

[Nishanth Menon]

Menon, Nishanth had written, on 11/19/2009 08:16 PM, the following:

Kevin Hilman had written, on 11/19/2009 07:31 PM, the following:

Nishanth Menon  writes:


Menon, Nishanth had written, on 11/15/2009 08:54 AM, the following:


[...]


Thanks for a thorough review and the new ideas. I will do a proposal
later tomorrow to aggregate and provide a common solution I hope. some
views follow.

Here it is inlined:
/*
 * OMAP OPP Interface
 *
 * Copyright (C) 2009 Texas Instruments Incorporated.
 *  Nishanth Menon
 * Copyright (C) 2009 Deep Root Systems, LLC.
 *  Kevin Hilman
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License version 2 as
 * published by the Free Software Foundation.
 */
#ifndef __ASM_ARM_OMAP_OPP_H
#ifndef __ASM_ARM_OMAP_OPP_H

/**
 * struct omap_opp - OMAP OPP description structure
 * @enabled:true/false - marking this OPP as enabled/disabled
 * @rate:   Frequency in hertz
 * @opp_id: (DEPRECATED) opp identifier
 * @vsel:   Voltage in volt processor level(this usage is
 *  DEPRECATED to use Voltage in millivolts in future)
 *  mV= (vsel * 12.5) + 600
 *
 * This structure stores the OPP information for a given domain.
 * Due to legacy reasons, this structure is currently exposed and
 * will soon be removed elsewhere and will only be used as a handle
 * from the OPP internal referencing mechanism
 */
struct omap_opp {
bool enabled;
unsigned long rate;
u8 opp_id;
u16 vsel;
};

/**
 * opp_get_voltage - Gets the voltage corresponding to an opp
 * @m_volt: Voltage in millivolts corresponding to an opp
 * @opp:opp for which voltage has to be returned for
 *
 * Return 0 and the voltage in milli volt corresponding to the opp,
 * else return the corresponding error value.
 */
int opp_get_voltage(u16 *m_volt, const struct omap_opp *opp);

/**
 * opp_get_freq - Gets the frequency corresponding to an opp
 * @freq:   Frequency in hertz corresponding to an opp
 * @opp:opp for which frequency has to be returned for
 *
 * Return 0 and the frequency in hertz corresponding to the opp,
 * else return the corresponding error value.
 */
int opp_get_freq(unsigned long *freq, const struct omap_opp *opp);

/**
 * opp_is_valid - Verifies if a given frequency is enabled in the opp list
 * @opp:Pointer to opp returned if opp match is achieved
 * @oppl:   opp list
 * @freq:   Frequency in hertz to check for
 *
 * Searches the OPP list to find if the provided frequency is an enabled
 * frequency. If a match is achieved, it returns 0 and the pointer to 
the opp

 * is returned, else a corresponding error value is returned.
 */
int opp_is_valid(struct omap_opp **opp, const struct omap_opp *oppl,
const unsigned long freq);

/**
 * opp_has_freq - Checks if a frequency is exists(enabled/disabled) in 
opp list

 * @opp:Pointer to opp returned if opp match is achieved
 * @oppl:   opp list
 * @freq:   Frequency in hertz to check for
 *
 * Searches the OPP list to find a frequency. This is a more generic 
function

 * than the opp_is_valid since it searches for both enabled/disabled
 * frequencies.
 *
 * This function may be used by detection logic to enable a disabled OPP as
 * all other search functions work on enabled OPPs only.
 */
int opp_has_freq(struct omap_opp **opp, const struct omap_opp *oppl,
const unsigned long freq);

/**
 * opp_get_opp_count - Get number of opps enabled in the opp list
 * @num:returns the number of opps
 * @oppl:   opp list
 *
 * This functions returns 0 and the number of opps are updated in num if
 * success, else returns corresponding error value.
 */
int opp_get_opp_count(u8 *num, const struct omap_opp *oppl);

/**
 * opp_get_higher_opp - search for the next highest opp in the list
 * @opp:pointer to the opp
 * @freq:   frequency to start the search on
 * @oppl:   opp list to search on
 *
 * Searches for the higher *enabled* OPP than a starting freq/opp
 * Decision of start condition:
 *  if *opp is NULL, *freq is checked (usually the start condition)
 *  if *opp is populated, *freq is ignored
 * Returns 0 and *opp and *freq is populated with the next highest match,
 * else returns corresponding error value.
 *
 * Example usage:
 *  * print a all frequencies ascending order *
 *  unsigned long freq = 0;
 *  struct omap_opp *opp = NULL;
 *  while(!opp_get_higher_opp(&opp, &freq, oppl))
 *  pr_info("%ld ", freq);
 * NOTE: if we set freq as 0, we get the lowest enabled frequency
 */
int opp_get_higher_opp(struct omap_opp **opp, unsigned long *freq,
const struct omap_opp *oppl);

/**
 * opp_get_lower_opp - search for the next lower opp in the list
 * @opp:pointer to the opp
 * @freq:   frequency to start the search on
 * @oppl:   opp list to search on
 *

Re: hub 2-0:1.0: port 2 disabled by hub (EMI?), re-enabling...

[Michael Trimarchi]

Michael Trimarchi wrote:

Hi all,

I'm working on a overo board + a palo43 daughter board. I connect a 
camera to hit with the following result:


hub 2-0:1.0: port 2 disabled by hub (EMI?), 
re-enabling...  usb 2-2: USB disconnect, address 
16 gspca: disconnect 
complete usb 2-2: new high speed USB device using ehci-omap and address 
16   usb 2-2: New USB device found, idVendor=05a9, 
idProduct=a538usb 2-2: New USB device strings: 
Mfr=1, Product=2, SerialNumber=0   usb 2-2: Product: OV538 
USB camera-013008-1 usb 2-2: 
Manufacturer: OmniVision Application Team  
usb 2-2: configuration #1 chosen from 1 
choice  gspca: probing 
05a9:a538ov538: 
sensor is ov7691 
gspca: probe ok 
every time...
This sometimes happen and simetimes in some boot is ok. But when I start 
some transaction
I have similar problem write packet on the usb device. Can you have any 
idea?


Ok I use isoc transfer to the sensor and I use a 2.6.29 kernel openembedded 
tree.

# CONFIG_USB_C67X00_HCD is not set
CONFIG_USB_EHCI_HCD=y
CONFIG_OMAP_EHCI_PHY_MODE=y
# CONFIG_OMAP_EHCI_TLL_MODE is not set
CONFIG_USB_EHCI_ROOT_HUB_TT=y

Is there a part of the support patched where I can check?

Michael



Michael
--
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 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

hub 2-0:1.0: port 2 disabled by hub (EMI?), re-enabling...

[Michael Trimarchi]

Hi all,

I'm working on a overo board + a palo43 daughter board. I connect a camera to 
hit with the following result:

hub 2-0:1.0: port 2 disabled by hub (EMI?), re-enabling...  
usb 2-2: USB disconnect, address 16 
gspca: disconnect complete 
usb 2-2: new high speed USB device using ehci-omap and address 16   
usb 2-2: New USB device found, idVendor=05a9, idProduct=a538
usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0   
usb 2-2: Product: OV538 USB camera-013008-1 
usb 2-2: Manufacturer: OmniVision Application Team  
usb 2-2: configuration #1 chosen from 1 choice  
gspca: probing 05a9:a538
ov538: sensor is ov7691 
gspca: probe ok  


every time...
This sometimes happen and simetimes in some boot is ok. But when I start some 
transaction
I have similar problem write packet on the usb device. Can you have any idea?

Michael
--
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

Re: linux-next: omap tree misaplied patch

[Tony Lindgren]

* Stephen Rothwell  [091119 18:01]:
> Hi Tony,
> 
> I think commit 8552f084d80cfc191ea5affacbeffe44e8629496 ("ARM OMAP3:
> RX-51 board - add initialization of gpio keys") has been misapplied.  It
> has this line:
> 
>   +#endif /* CONFIG_KEYBOARD_GPIO || CONFIG_KEYBOARD_GPIO_MODULE */
> 
> with the leading '+'.   I noticed this when merging with the input tree
> as this made for a strange looking conflict.

Oops, my fault. Will fix ASAP.

Regards,

Tony

--
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

Re: linux-next: manual merge of the input tree with the omap tree

[Tony Lindgren]

* Dmitry Torokhov  [091120 00:59]:
> On Wed, Nov 18, 2009 at 06:53:30PM -0800, Tony Lindgren wrote:
> > 
> > Dmitry, could you please drop 5018461a887d58f4601207deeebb7c352c2da20a from
> > your tree now?
> > 
> 
> Done.

Thanks!

Tony
--
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

RE: FEATURES - is it good enough

[Aguirre, Sergio]

 

> -Original Message-
> From: Ramirez Luna, Omar 
> Sent: Friday, November 20, 2009 2:07 PM
> To: Aguirre, Sergio
> Cc: linux-omap@vger.kernel.org
> Subject: RE: FEATURES - is it good enough
> 
> >
> >IMHO, That "for the time being" will stay forever if we 
> don't do something now.
> >
> >Most of the big problems are raised because someone says 
> "ok, lets have this for
> >the time being". But that time never comes.
> >
> >See that crazy CaMeL-Casing hanging around in 
> /drivers/dsp/bridge/ for a while as
> >an example. When that will ever be fixed? I bet someone said 
> some time:
> >"ok, lets fix it later" :-)
> >
> 
> IMHO read http://marc.info/?l=linux-omap&m=125729526105560&w=2
> 
> :P

Damn... I didn't catch that one before. :-(

Apologies.

> 
> - omar
> --
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

Re: FEATURES - is it good enough

[Nishanth Menon]

Aguirre, Sergio had written, on 11/20/2009 01:43 PM, the following:
 


-Original Message-
From: Menon, Nishanth 
Sent: Friday, November 20, 2009 1:24 PM

To: Kevin Hilman
Cc: Shilimkar, Santosh; Aguirre, Sergio; Pandita, Vikram; 
linux-omap@vger.kernel.org

Subject: Re: FEATURES - is it good enough

Kevin Hilman had written, on 11/20/2009 12:35 PM, the following:

"Shilimkar, Santosh"  writes:

[...]


Probably not something ot be attached in this patch, but...

I'm a bit curious about something:

Why touching omap3_features in OMAP4?

Isn't there a omap4_features?

Or even better, an omap_features?

This "is_feature" suppose to take care of Errata's also, is it?

"It's not a bug it's a feature." :)
Bug. Santosh pointed out internally to h/w discussion which clearly 
shows this as a h/w limitation. (thanks santosh)



This is errata more than a feature. We better differentiate in
this regard

I agree, I have a hard time calling this empty fifo read fault a
"feature."  We need a similar thing for errata.
Agreed. This is a classic example why we need a common errata 
handling 
mechanism scalable across silicon variants on an IP basis. 
two problems 
in front of us:
a) what do we want to do with 8250 workaround needed for omap3630 and 
omap4? can we go ahead with features marking it clearly as a 
"misuse of 
features for the time being"


IMHO, That "for the time being" will stay forever if we don't do something now.

Most of the big problems are raised because someone says "ok, lets have this for
the time being". But that time never comes.

See that crazy CaMeL-Casing hanging around in /drivers/dsp/bridge/ for a while 
as
an example. When that will ever be fixed? I bet someone said some time:
"ok, lets fix it later" :-)

On the other hand. What's the big motivation to have this as a "feature"?

Who else than the serial driver cares about the "feature" awareness?


please see [1] and [2]. this wont be the first time I published 
something previously that got ignored and got re-discussed. note:


BTW, to be fair, DSPBridge already has plans to get fixed anyways..

Options I can think which were discussed:
a) introduce omap3_features omap3_errata: negative: wont read like if I 
use omap3_has_errata() for OMAP4 code.
b) introduce omap_features and omap_errata: negative: how do you link 
this to IP based usage across silicon (e.g. I2C).


I dont think these are scalable solutions though..

--
Regards,
Nishanth Menon
[1] http://marc.info/?l=linux-omap&m=125018632606920&w=2
[2] http://marc.info/?l=linux-omap&m=125319739327677&w=2
--
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

RE: FEATURES - is it good enough

[Ramirez Luna, Omar]

>
>IMHO, That "for the time being" will stay forever if we don't do something now.
>
>Most of the big problems are raised because someone says "ok, lets have this 
>for
>the time being". But that time never comes.
>
>See that crazy CaMeL-Casing hanging around in /drivers/dsp/bridge/ for a while 
>as
>an example. When that will ever be fixed? I bet someone said some time:
>"ok, lets fix it later" :-)
>

IMHO read http://marc.info/?l=linux-omap&m=125729526105560&w=2

:P

- omar
--
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

RE: FEATURES - is it good enough

[Aguirre, Sergio]

 

> -Original Message-
> From: Menon, Nishanth 
> Sent: Friday, November 20, 2009 1:24 PM
> To: Kevin Hilman
> Cc: Shilimkar, Santosh; Aguirre, Sergio; Pandita, Vikram; 
> linux-omap@vger.kernel.org
> Subject: Re: FEATURES - is it good enough
> 
> Kevin Hilman had written, on 11/20/2009 12:35 PM, the following:
> > "Shilimkar, Santosh"  writes:
> > 
> > [...]
> > 
>  Probably not something ot be attached in this patch, but...
> 
>  I'm a bit curious about something:
> 
>  Why touching omap3_features in OMAP4?
> 
>  Isn't there a omap4_features?
> 
>  Or even better, an omap_features?
> >> This "is_feature" suppose to take care of Errata's also, is it?
> > 
> > "It's not a bug it's a feature." :)
> Bug. Santosh pointed out internally to h/w discussion which clearly 
> shows this as a h/w limitation. (thanks santosh)
> 
> > 
> >> This is errata more than a feature. We better differentiate in
> >> this regard
> > 
> > I agree, I have a hard time calling this empty fifo read fault a
> > "feature."  We need a similar thing for errata.
> Agreed. This is a classic example why we need a common errata 
> handling 
> mechanism scalable across silicon variants on an IP basis. 
> two problems 
> in front of us:
> a) what do we want to do with 8250 workaround needed for omap3630 and 
> omap4? can we go ahead with features marking it clearly as a 
> "misuse of 
> features for the time being"

IMHO, That "for the time being" will stay forever if we don't do something now.

Most of the big problems are raised because someone says "ok, lets have this for
the time being". But that time never comes.

See that crazy CaMeL-Casing hanging around in /drivers/dsp/bridge/ for a while 
as
an example. When that will ever be fixed? I bet someone said some time:
"ok, lets fix it later" :-)

On the other hand. What's the big motivation to have this as a "feature"?

Who else than the serial driver cares about the "feature" awareness?

> b) a common silicon errata handling mechanism: Does anyone have 
> proposals for this? I can see it help in numerous places in our code 
> today and will help readability of the code instead of 
> getting the risk 
> of "feature not a bug" misread.. ;)..

My very personal opinion is that, good code commenting can make this very
clear.

But, the way it is right now, brings so much confusion (being a feature).

Regards,
Sergio

> 
> -- 
> 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

RE: FEATURES - is it good enough

[Premi, Sanjeev]

> -Original Message-
> From: linux-omap-ow...@vger.kernel.org 
> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Menon, Nishanth
> Sent: Saturday, November 21, 2009 12:54 AM
> To: Kevin Hilman
> Cc: Shilimkar, Santosh; Aguirre, Sergio; Pandita, Vikram; 
> linux-omap@vger.kernel.org
> Subject: Re: FEATURES - is it good enough
> 
> Kevin Hilman had written, on 11/20/2009 12:35 PM, the following:
> > "Shilimkar, Santosh"  writes:
> > 
> > [...]
> > 
>  Probably not something ot be attached in this patch, but...
> 
>  I'm a bit curious about something:
> 
>  Why touching omap3_features in OMAP4?
> 
>  Isn't there a omap4_features?
> 
>  Or even better, an omap_features?
> >> This "is_feature" suppose to take care of Errata's also, is it?
> > 
> > "It's not a bug it's a feature." :)
> Bug. Santosh pointed out internally to h/w discussion which clearly 
> shows this as a h/w limitation. (thanks santosh)
> 
> > 
> >> This is errata more than a feature. We better differentiate in
> >> this regard
> > 
> > I agree, I have a hard time calling this empty fifo read fault a
> > "feature."  We need a similar thing for errata.
> Agreed. This is a classic example why we need a common errata 
> handling 
> mechanism scalable across silicon variants on an IP basis. 
> two problems 
> in front of us:
> a) what do we want to do with 8250 workaround needed for omap3630 and 
> omap4? can we go ahead with features marking it clearly as a 
> "misuse of 
> features for the time being"
> b) a common silicon errata handling mechanism: Does anyone have 
> proposals for this? I can see it help in numerous places in our code 
> today and will help readability of the code instead of 
> getting the risk 
> of "feature not a bug" misread.. ;)..

Can we define omap3_errata on lines of omap3_features?

To the original question of why resue omap3_xyz name for omap4?
I guess very valid - unlike features, erratas may not be reused.
So it may make sense to have another omap4_errata as well. Any
duplications due to IP reuse can be handled on the omap3_errata
list (original IP where errata applies).

Deciding whether errata is feature or vice versa?
...ahem, pass.

Best regards,
Sanjeev

> 
> -- 
> 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 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

RE: VDD1 voltage after resume from idle

[Premi, Sanjeev]

> -Original Message-
> From: linux-omap-ow...@vger.kernel.org 
> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Premi, Sanjeev
> Sent: Friday, November 20, 2009 11:46 PM
> To: Maxime Petazzoni
> Cc: linux-omap@vger.kernel.org
> Subject: RE: VDD1 voltage after resume from idle
> 
> > -Original Message-
> > From: Maxime Petazzoni [mailto:mpetazz...@mvista.com] 
> > Sent: Friday, November 20, 2009 10:00 PM
> > To: Premi, Sanjeev
> > Cc: linux-omap@vger.kernel.org
> > Subject: Re: VDD1 voltage after resume from idle
> > 

[snip]--[snip]--[snip]

> 
> I guess the root cause could be same. I have not been able to 
> ascertain
> the reason for the voltage changing during the idle/wakeup sequence.
> Also tried to eliminate the enable_smartreflex() calls on wakeup path.
> Sill I see voltage ramp-up.
> 
> I am trying to find the cause of voltage ramping to 1.2V in hope that
> the reason for ramp down will be just inverted reflection.
> 
> With smartreflex disabled, there is no change in the voltage during
> suspend; so the problem area seems to be smartreflex.
> 
> Best regards,
> Sanjeev

Found the problem!

In sr_configure_vp() the vsel is picked up from the OPP table and used,
setting the voltage as expected (1.35V in my case).

A printk confirms PRM_VC_CMD_VAL_0 is 0x3C201E00. 

By the time, kernel boots up, the value has changed to 0x30201E00.
(0x30 corresponds to 1.2V)

[r...@omap3evm /]# devmem 0x4830722c 32
0x30201E00

Now, when I update the init voltage back to 3C (via devmem) the voltage
after resume/idle-wakeup is right (as expected).

[r...@omap3evm /]# devmem 0x4830722c 32 0x3c201e00
[r...@omap3evm /]#

So, I just need to find exact location where the configuration is being
overwritten.

It is well past midnight now. So the patch will have to wait until
tomorrow.

Best regards,
Sanjeev

[snip]--[snip]--[snip]
--
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

Re: FEATURES - is it good enough

[Nishanth Menon]

Kevin Hilman had written, on 11/20/2009 12:35 PM, the following:

"Shilimkar, Santosh"  writes:

[...]


Probably not something ot be attached in this patch, but...

I'm a bit curious about something:

Why touching omap3_features in OMAP4?

Isn't there a omap4_features?

Or even better, an omap_features?

This "is_feature" suppose to take care of Errata's also, is it?


"It's not a bug it's a feature." :)
Bug. Santosh pointed out internally to h/w discussion which clearly 
shows this as a h/w limitation. (thanks santosh)





This is errata more than a feature. We better differentiate in
this regard


I agree, I have a hard time calling this empty fifo read fault a
"feature."  We need a similar thing for errata.
Agreed. This is a classic example why we need a common errata handling 
mechanism scalable across silicon variants on an IP basis. two problems 
in front of us:
a) what do we want to do with 8250 workaround needed for omap3630 and 
omap4? can we go ahead with features marking it clearly as a "misuse of 
features for the time being"
b) a common silicon errata handling mechanism: Does anyone have 
proposals for this? I can see it help in numerous places in our code 
today and will help readability of the code instead of getting the risk 
of "feature not a bug" misread.. ;)..


--
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

Re: VDD1 voltage after resume from idle

[Jean Pihet]

On Friday 20 November 2009 20:11:26 Kevin Hilman wrote:
> Jean Pihet  writes:
> > Hi Kevin,
> >
> > On Friday 20 November 2009 19:29:02 Kevin Hilman wrote:
> >> Maxime Petazzoni  writes:
> >> > Hi,
> >> >
> >> > * Premi, Sanjeev  [2009-11-20 21:17:04]:
> >> >> I am facing a strange problem on OMAP3EVM after resuming from idle.
> >> >> When using OPP5, the VDD1 voltage ramps to 1.35V.
> >> >>
> >> >> However, when i go thru the idle/wakeup cycle, the voltage never
> >> >> ramps back to 1.35V but stays at 1.20V.
> >> >
> >> > I'm seeing some interesting behavior with the OPP values here, too,
> >> > with suspend/resume. I'm using SRF based PM and CPUFREQ. Here's what
> >> > happens:
> >> >
> >> > When changing the CPU frequency through the scaling_setfreq knob of
> >> > CPUFREQ, the vdd{1,2}_opp values are updated accordingly. After a
> >> > suspend/resume cycles, the OPPs return to their pre-suspend values,
> >> > all is fine.
> >> >
> >> > But when changing the OPP values by hand through the vdd{1,2}_opp
> >> > knobs, the CPU frequency is changed accordingly, which is expected.
> >> > But after a suspend/resume cycle, the OPP values return to the value
> >> > CPUFREQ set them to (which may be different than the default OPP
> >> > values of 3).
> >> >
> >> > Is this the normal behavior? Is cpufreq authoritative on the OPP
> >> > values on resume? Or should it follow whatever value was manually set
> >> > before suspending?
> >>
> >> FWIW, the vdd*_opp sysfs hooks were for initial debug/dev and should
> >> be considered experimental (a.k.a broken.) They will disappear from
> >> the PM branch shortly.
> >>
> >> CPUfreq should be the only interface used for DVFS.
> >
> > Could the PM page on elinux.org be updated with that info? I am proposing
> > to change it before you ask me ;p
>
> Done.
>
> I added the following note to the 'opp control' section.
>
> OPP control via sysfs is deprecated. Please use CPUfreq interfaces for
> DVFS.
Thanks!

Jean

--
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

Re: VDD1 voltage after resume from idle

[Kevin Hilman]

Jean Pihet  writes:

> Hi Kevin,
>
> On Friday 20 November 2009 19:29:02 Kevin Hilman wrote:
>> Maxime Petazzoni  writes:
>> > Hi,
>> >
>> > * Premi, Sanjeev  [2009-11-20 21:17:04]:
>> >> I am facing a strange problem on OMAP3EVM after resuming from idle.
>> >> When using OPP5, the VDD1 voltage ramps to 1.35V.
>> >>
>> >> However, when i go thru the idle/wakeup cycle, the voltage never
>> >> ramps back to 1.35V but stays at 1.20V.
>> >
>> > I'm seeing some interesting behavior with the OPP values here, too, with
>> > suspend/resume. I'm using SRF based PM and CPUFREQ. Here's what happens:
>> >
>> > When changing the CPU frequency through the scaling_setfreq knob of
>> > CPUFREQ, the vdd{1,2}_opp values are updated accordingly. After a
>> > suspend/resume cycles, the OPPs return to their pre-suspend values, all
>> > is fine.
>> >
>> > But when changing the OPP values by hand through the vdd{1,2}_opp knobs,
>> > the CPU frequency is changed accordingly, which is expected. But after a
>> > suspend/resume cycle, the OPP values return to the value CPUFREQ set
>> > them to (which may be different than the default OPP values of 3).
>> >
>> > Is this the normal behavior? Is cpufreq authoritative on the OPP values
>> > on resume? Or should it follow whatever value was manually set before
>> > suspending?
>>
>> FWIW, the vdd*_opp sysfs hooks were for initial debug/dev and should
>> be considered experimental (a.k.a broken.) They will disappear from
>> the PM branch shortly.
>>
>> CPUfreq should be the only interface used for DVFS.
> Could the PM page on elinux.org be updated with that info? I am proposing to 
> change it before you ask me ;p

Done.

I added the following note to the 'opp control' section.

OPP control via sysfs is deprecated. Please use CPUfreq interfaces for DVFS. 
--
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

Re: VDD1 voltage after resume from idle

[Jean Pihet]

Hi Kevin,

On Friday 20 November 2009 19:29:02 Kevin Hilman wrote:
> Maxime Petazzoni  writes:
> > Hi,
> >
> > * Premi, Sanjeev  [2009-11-20 21:17:04]:
> >> I am facing a strange problem on OMAP3EVM after resuming from idle.
> >> When using OPP5, the VDD1 voltage ramps to 1.35V.
> >>
> >> However, when i go thru the idle/wakeup cycle, the voltage never
> >> ramps back to 1.35V but stays at 1.20V.
> >
> > I'm seeing some interesting behavior with the OPP values here, too, with
> > suspend/resume. I'm using SRF based PM and CPUFREQ. Here's what happens:
> >
> > When changing the CPU frequency through the scaling_setfreq knob of
> > CPUFREQ, the vdd{1,2}_opp values are updated accordingly. After a
> > suspend/resume cycles, the OPPs return to their pre-suspend values, all
> > is fine.
> >
> > But when changing the OPP values by hand through the vdd{1,2}_opp knobs,
> > the CPU frequency is changed accordingly, which is expected. But after a
> > suspend/resume cycle, the OPP values return to the value CPUFREQ set
> > them to (which may be different than the default OPP values of 3).
> >
> > Is this the normal behavior? Is cpufreq authoritative on the OPP values
> > on resume? Or should it follow whatever value was manually set before
> > suspending?
>
> FWIW, the vdd*_opp sysfs hooks were for initial debug/dev and should
> be considered experimental (a.k.a broken.) They will disappear from
> the PM branch shortly.
>
> CPUfreq should be the only interface used for DVFS.
Could the PM page on elinux.org be updated with that info? I am proposing to 
change it before you ask me ;p

>
> Kevin

Thanks,
Jean

> --
> 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 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

Re: FEATURES - is it good enough

[Kevin Hilman]

"Shilimkar, Santosh"  writes:

[...]

>> >
>> > Probably not something ot be attached in this patch, but...
>> >
>> > I'm a bit curious about something:
>> >
>> > Why touching omap3_features in OMAP4?
>> >
>> > Isn't there a omap4_features?
>> >
>> > Or even better, an omap_features?
>
> This "is_feature" suppose to take care of Errata's also, is it?

"It's not a bug it's a feature." :)

> This is errata more than a feature. We better differentiate in
> this regard

I agree, I have a hard time calling this empty fifo read fault a
"feature."  We need a similar thing for errata.

Kevin

--
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

Re: VDD1 voltage after resume from idle

[Maxime Petazzoni]

* Kevin Hilman  [2009-11-20 10:29:02]:

> FWIW, the vdd*_opp sysfs hooks were for initial debug/dev and should
> be considered experimental (a.k.a broken.) They will disappear from
> the PM branch shortly.
> 
> CPUfreq should be the only interface used for DVFS.

Ah, well then I guess that fixes my problem. So, was I right on saying
that CPUfreq is "taking control" of the OPP values on wake up? (just
trying to make sure I understand how this works correctly).

Thanks for the info,
- Maxime
-- 
Maxime Petazzoni
Linux kernel & software dev
MontaVista Software, Inc


signature.asc
Description: Digital signature

Re: VDD1 voltage after resume from idle

[Kevin Hilman]

Maxime Petazzoni  writes:

> Hi,
>
> * Premi, Sanjeev  [2009-11-20 21:17:04]:
>
>> I am facing a strange problem on OMAP3EVM after resuming from idle.
>> When using OPP5, the VDD1 voltage ramps to 1.35V.
>>  
>> However, when i go thru the idle/wakeup cycle, the voltage never
>> ramps back to 1.35V but stays at 1.20V.
>
> I'm seeing some interesting behavior with the OPP values here, too, with
> suspend/resume. I'm using SRF based PM and CPUFREQ. Here's what happens:
>
> When changing the CPU frequency through the scaling_setfreq knob of
> CPUFREQ, the vdd{1,2}_opp values are updated accordingly. After a
> suspend/resume cycles, the OPPs return to their pre-suspend values, all
> is fine.
>
> But when changing the OPP values by hand through the vdd{1,2}_opp knobs,
> the CPU frequency is changed accordingly, which is expected. But after a
> suspend/resume cycle, the OPP values return to the value CPUFREQ set
> them to (which may be different than the default OPP values of 3).
>
> Is this the normal behavior? Is cpufreq authoritative on the OPP values
> on resume? Or should it follow whatever value was manually set before
> suspending?

FWIW, the vdd*_opp sysfs hooks were for initial debug/dev and should
be considered experimental (a.k.a broken.) They will disappear from
the PM branch shortly.

CPUfreq should be the only interface used for DVFS.

Kevin
--
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

RE: VDD1 voltage after resume from idle

[Premi, Sanjeev]

> -Original Message-
> From: Maxime Petazzoni [mailto:mpetazz...@mvista.com] 
> Sent: Friday, November 20, 2009 10:00 PM
> To: Premi, Sanjeev
> Cc: linux-omap@vger.kernel.org
> Subject: Re: VDD1 voltage after resume from idle
> 
> Hi,
> 
> * Premi, Sanjeev  [2009-11-20 21:17:04]:
> 
> > I am facing a strange problem on OMAP3EVM after resuming from idle.
> > When using OPP5, the VDD1 voltage ramps to 1.35V.
> >  
> > However, when i go thru the idle/wakeup cycle, the voltage never
> > ramps back to 1.35V but stays at 1.20V.
> 
> I'm seeing some interesting behavior with the OPP values 
> here, too, with
> suspend/resume. I'm using SRF based PM and CPUFREQ. Here's 
> what happens:
> 
> When changing the CPU frequency through the scaling_setfreq knob of
> CPUFREQ, the vdd{1,2}_opp values are updated accordingly. After a
> suspend/resume cycles, the OPPs return to their pre-suspend 
> values, all
> is fine.
> 
> But when changing the OPP values by hand through the 
> vdd{1,2}_opp knobs,
> the CPU frequency is changed accordingly, which is expected. 
> But after a
> suspend/resume cycle, the OPP values return to the value CPUFREQ set
> them to (which may be different than the default OPP values of 3).
> 
> Is this the normal behavior? Is cpufreq authoritative on the 
> OPP values
> on resume? Or should it follow whatever value was manually set before
> suspending?

I guess the root cause could be same. I have not been able to ascertain
the reason for the voltage changing during the idle/wakeup sequence.
Also tried to eliminate the enable_smartreflex() calls on wakeup path.
Sill I see voltage ramp-up.

I am trying to find the cause of voltage ramping to 1.2V in hope that
the reason for ramp down will be just inverted reflection.

With smartreflex disabled, there is no change in the voltage during
suspend; so the problem area seems to be smartreflex.

Best regards,
Sanjeev

> 
> Thanks,
> - Maxime
> 
> PS: if I was not clear, I can provide a console log that may be more
> explicit--just ask.
> 
> -- 
> Maxime Petazzoni
> Linux kernel & software dev
> MontaVista Software, Inc
> --
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

RE: FEATURES - is it good enough (was Re: [PATCH v3 1/2] omap: introduce uart_no_empty_fifo_read feature)

[Shilimkar, Santosh]

Started reading threads today

> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Menon, Nishanth
> Sent: Friday, November 20, 2009 9:47 PM
> To: Aguirre, Sergio
> Cc: Pandita, Vikram; linux-omap@vger.kernel.org
> Subject: FEATURES - is it good enough (was Re: [PATCH v3 1/2] omap:
> introduce uart_no_empty_fifo_read feature)
> 
> Aguirre, Sergio had written, on 11/20/2009 10:14 AM, the following:
> >
> >
> >> -Original Message-
> >> From: linux-omap-ow...@vger.kernel.org
> >> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Nishanth
> Menon
> >> Sent: Friday, November 20, 2009 10:10 AM
> >> To: Pandita, Vikram
> >> Cc: linux-omap@vger.kernel.org
> >> Subject: Re: [PATCH v3 1/2] omap: introduce
> >> uart_no_empty_fifo_read feature
> >>
> >> Vikram Pandita had written, on 11/20/2009 10:02 AM, the
> following:
> >>> Interoduce omap feature OMAP3_HAS_UART_NO_EMPTY_FIFO_READ
> >> ^ <- you meant introduce
> >>> On omap3630/omap4 an empty fifo read causes a crash
> >>>
> >>> Signed-off-by: Vikram Pandita 
> >>> Ack-by: Menon, Nishanth 
> >> ^ <- :P nope you dont have my Acked-by until you
> >> change this to
> >> Acked from Ack ;)..
> >>
> >> Thanks for the simpler patch.
> >>
> >>> ---
> >>>  arch/arm/mach-omap2/id.c  |7 +++
> >>>  arch/arm/plat-omap/include/plat/cpu.h |2 ++
> >>>  2 files changed, 9 insertions(+), 0 deletions(-)
> >>>
> >>> diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
> >>> index f48a4b2..3e266cd 100644
> >>> --- a/arch/arm/mach-omap2/id.c
> >>> +++ b/arch/arm/mach-omap2/id.c
> >>> @@ -176,6 +176,12 @@ void __init omap3_check_features(void)
> >>>   OMAP3_CHECK_FEATURE(status, NEON);
> >>>   OMAP3_CHECK_FEATURE(status, ISP);
> >>>
> >>> + /* On omap3630 and omap4: UART empty rx fifo read aborts */
> >>> + if (cpu_is_omap3630())
> >>> + omap3_features |= OMAP3_HAS_UART_NO_EMPTY_FIFO_READ;
> >>> + if (cpu_is_omap44xx())
> >>> + omap3_features |= OMAP3_HAS_UART_NO_EMPTY_FIFO_READ;
> >>> +
> >
> > Probably not something ot be attached in this patch, but...
> >
> > I'm a bit curious about something:
> >
> > Why touching omap3_features in OMAP4?
> >
> > Isn't there a omap4_features?
> >
> > Or even better, an omap_features?

This "is_feature" suppose to take care of Errata's also, is it?
This is errata more than a feature. We better differentiate in this regard

Regards,
Santosh
--
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

Re: [PATCH 2/3] Input:TouchScreen: Introduce TSC2004 driver support

[Dmitry Torokhov]

Hi Vaibhav,

On Thu, Nov 19, 2009 at 08:16:40PM +0530, hvaib...@ti.com wrote:
> From: Vaibhav Hiremath 
> 
> Signed-off-by: Vaibhav Hiremath 


If I do:

sed 's/2004/2007/g' drivers/input/touchscreen/tsc2004.c | diff -u
drivers/input/touchscreen/tsc2007.c -

the diff is miniscule so why can't TSC2004 support be simply added to
TSC2007 driver?

Thanks.

-- 
Dmitry
--
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

Re: VDD1 voltage after resume from idle

[Maxime Petazzoni]

Hi,

* Premi, Sanjeev  [2009-11-20 21:17:04]:

> I am facing a strange problem on OMAP3EVM after resuming from idle.
> When using OPP5, the VDD1 voltage ramps to 1.35V.
>  
> However, when i go thru the idle/wakeup cycle, the voltage never
> ramps back to 1.35V but stays at 1.20V.

I'm seeing some interesting behavior with the OPP values here, too, with
suspend/resume. I'm using SRF based PM and CPUFREQ. Here's what happens:

When changing the CPU frequency through the scaling_setfreq knob of
CPUFREQ, the vdd{1,2}_opp values are updated accordingly. After a
suspend/resume cycles, the OPPs return to their pre-suspend values, all
is fine.

But when changing the OPP values by hand through the vdd{1,2}_opp knobs,
the CPU frequency is changed accordingly, which is expected. But after a
suspend/resume cycle, the OPP values return to the value CPUFREQ set
them to (which may be different than the default OPP values of 3).

Is this the normal behavior? Is cpufreq authoritative on the OPP values
on resume? Or should it follow whatever value was manually set before
suspending?

Thanks,
- Maxime

PS: if I was not clear, I can provide a console log that may be more
explicit--just ask.

-- 
Maxime Petazzoni
Linux kernel & software dev
MontaVista Software, Inc


signature.asc
Description: Digital signature

Re: [PATCH V4 3/3] OMAP: I2C: Add mpu wake up latency constraint in i2c

[Kevin Hilman]

 writes:

> Could you please take this patch in? Currently i2c is not working
> very well with cpuidle and off mode, and the patch is needed.
>
> I would go with V4 of the patch.

Kalle,

Last I saw with this thread, it didn't look like there was resolution.
If things are resolved, this shouldn't go upstream via PM branch, since
it doesn't seem to have any dependencies on the PM branch.

It should go upstream either via the I2C list, or via Tony.

If it goes via i2c list, I can add it to PM branch while waiting for
it to merge.

Kevin


>>-Original Message-
>>From: linux-omap-ow...@vger.kernel.org 
>>[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of ext 
>>Kalle Jokiniemi
>>Sent: 29. lokakuuta 2009 10:55
>>To: Sonasath, Moiz
>>Cc: khil...@deeprootsystems.com; linux-omap@vger.kernel.org
>>Subject: RE: [PATCH V4 3/3] OMAP: I2C: Add mpu wake up latency 
>>constraint in i2c
>>
>>OK, let's try this once more, since my mail did not seem to go 
>>to linux-omap.
>>
>>Sorry for the spam.
>>
>>See my comments below:
>>
>>On Fri, 2009-10-23 at 18:53 +0300, Sonasath, Moiz wrote:
>>> Hello Jokiniemi!
>>> 
>>> > -Original Message-
>>> > From: Kalle Jokiniemi [mailto:kalle.jokini...@digia.com]
>>> > Sent: Wednesday, October 21, 2009 6:51 AM
>>> > To: khil...@deeprootsystems.com
>>> > Cc: linux-omap@vger.kernel.org; Kalle Jokiniemi; Sonasath, Moiz;
>>> Jarkko
>>> > Nikula; Paul Walmsley; Menon, Nishanth
>>> > Subject: [PATCH V4 3/3] OMAP: I2C: Add mpu wake up latency
>>> constraint in
>>> > i2c
>>> > 
>>> > While waiting for completion of the i2c transfer, the MPU 
>>could hit 
>>> > OFF mode and cause several msecs of delay that made i2c transfers 
>>> > fail more often. The extra delays and subsequent re-trys cause i2c 
>>> > clocks to be active more often. This has also an negative 
>>effect on 
>>> > power consumption.
>>> > 
>>> > Created a mechanism for passing and using the constraint setting 
>>> > function in driver code. The used mpu wake up latency constraints 
>>> > are now set individually per bus, and they are calculated based on 
>>> > clock rate and fifo size.
>>> > 
>>> > Thanks to Jarkko Nikula, Moiz Sonasath, Paul Walmsley, and 
>>Nishanth 
>>> > Menon for tuning out the details of this patch.
>>> > 
>>> > Cc: Moiz Sonasath 
>>> > Cc: Jarkko Nikula 
>>> > Cc: Paul Walmsley 
>>> > Cc: Nishanth Menon 
>>> > Signed-off-by: Kalle Jokiniemi 
>>> > ---
>>> > 
>>> 
>>> 
>>> >   dev->speed = speed;
>>> >   dev->idle = 1;
>>> > @@ -911,6 +923,11 @@ omap_i2c_probe(struct platform_device *pdev)
>>> >*/
>>> >   dev->fifo_size = (dev->fifo_size / 2);
>>> >   dev->b_hw = 1; /* Enable hardware fixes */
>>> > +
>>> > + /* calculate wakeup latency constraint for MPU */
>>> > + if (dev->set_mpu_wkup_lat != NULL)
>>> > + dev->latency = (100 * dev->fifo_size) /
>>> > +(1000 * speed / 8);
>>> >   }
>>> 
>>> IMHO, here instead of using 'dev->fifo_size' for calculating the 
>>> 'dev->latency', we need to use:
>>> 
>>> 1. For RX case, to avoid Reciver overrun:
>>> if (msg->flags & I2C_M_RD)
>>> Use [(FIFO Depth)bytes - (FIFO THRSH)bytes] in 
>>calculating 
>>> dev->latency
>>> 
>>> Because conceptually, RDR/RRDY interrupts are generated when 
>>RTRSH is 
>>> reached, so we want the MPU to be wake up within the time it 
>>takes to 
>>> fill the FIFO from RTRSH to FIFO Depth (FIFO full).
>>> 
>>> 2. For TX case, to avoid Transmitter Underflow:
>>> if (!(msg->flags & I2C_M_RD))
>>> Use (FIFO THRSH)bytes in calculating dev->latency
>>> 
>>> Because conceptually, XDR/XRDY interrupts are generated when 
>>XTRSH is 
>>> reached, so we want the MPU to be wake up within the time it 
>>takes to 
>>> drain the FIFO from XTRSH to Zero (FIFO empty).
>>> 
>>> Using, dev->fifo_size instead, works in the present code because we 
>>> have a RTRSH/XTRSH = dev->fifo_size/2 = 4 bytes And therefore, (FIFO 
>>> Depth)bytes - (FIFO THRSH)bytes = 8 - 4 = 4 bytes
>>> 
>>> But, to make it more generic in future and to make it independent of 
>>> any changes in the RTRSH/XTRSH values or FIFO depths in future, we 
>>> should use a generic code here.
>>
>>Well, I don't completely agree with the necessity of preparing 
>>for different rx/tx thresholds. For this to make sense, the 
>>i2c-omap driver should first separate in it's code the use of 
>>rx and tx thresholds. If someone is planning to do that, 
>>he/she should anyway update the usage of fifo_size throughout 
>>the code, including the wake up latency setting.
>>
>>Anyways, attached a patch that separates the mpu wake up 
>>latencies for rx and tx. In case that is needed. Though I'm 
>>not for it, since it adds unneeded complexity.
>>
>>- Kalle
>>
>>> 
>>> > 
>>> >   /* reset ASAP, clearing any IRQs */ diff --git 
>>> > a/include/linux/i2c-omap.h b/include/linux/i2c-omap.h new 
>>file mode 
>>> > 100644 index 000..1362fba
>>> > --- /dev/

Re: [PATCHV2 4/4] OMAP3: add support for 192Mhz sgx clock

[Nishanth Menon]

unrelated to this patch comment: we might want to consider thinking in 
terms of optimizing the memory as OMAP4 also kicks in.. some sort of 
dynamic clock tree traversal and __initdata method perhaps??


Hi Vishwa,
Thanks for the patch, few minor comments follow:

Sripathy, Vishwanath had written, on 11/20/2009 09:28 AM, the following:

SGX can run at 192MHz on 3630 and this patch has changes to support this
feature. Basically DPLL4 M2 will be 192Mhz which will be used as SGX
Clock. 192Mhz clock is divided by 2 (using CM_CLKSEL_CORE) to generate
96Mh clock

   <- you probably intended 96Mhz


Signed-off-by: Vishwanath BS 
---
 arch/arm/mach-omap2/clock34xx.c   |   16 +++-
 arch/arm/mach-omap2/clock34xx.h   |   33 +
 arch/arm/mach-omap2/cm-regbits-34xx.h |2 ++
 arch/arm/mach-omap2/id.c  |7 +--
 arch/arm/plat-omap/include/plat/cpu.h |3 +++
 5 files changed, 58 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
index 1e35f9a..bce7e46 100755
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -128,6 +128,7 @@ static struct omap_clk omap34xx_clks[] = {
CLK(NULL,   "emu_core_alwon_ck", &emu_core_alwon_ck, CK_3XXX),
CLK(NULL,   "dpll4_ck",   &dpll4_ck,  CK_3XXX),
CLK(NULL,   "dpll4_x2_ck",&dpll4_x2_ck,   CK_3XXX),
+   CLK(NULL,   "omap_192m_alwon_ck", &omap_192m_alwon_ck, CK_363X),
CLK(NULL,   "omap_96m_alwon_fck", &omap_96m_alwon_fck, CK_3XXX),
CLK(NULL,   "omap_96m_fck",   &omap_96m_fck,  CK_3XXX),
CLK(NULL,   "cm_96m_fck", &cm_96m_fck,CK_3XXX),
@@ -1226,7 +1227,20 @@ int __init omap2_clk_init(void)
OMAP3630_PERIPH_DPLL_SD_DIV_MASK;
dpll4_dd.mult_mask = OMAP3630_PERIPH_DPLL_MULT_MASK;
cpu_mask |= RATE_IN_363X;
-   }
+   cpu_clkflg |= CK_363X;


I think introduce CK_36XX should be done seperately.


+   }
+
+   if (omap3_has_192mhz_clk()) {
+   omap_96m_alwon_fck.parent = &omap_192m_alwon_ck;
+   omap_96m_alwon_fck.init = &omap2_init_clksel_parent;
+   omap_96m_alwon_fck.clksel_reg =
+   OMAP_CM_REGADDR(CORE_MOD, CM_CLKSEL),
+   omap_96m_alwon_fck.clksel_mask =
+   OMAP3630_CLKSEL_96M_MASK;
+   omap_96m_alwon_fck.clksel = omap_96m_alwon_fck_clksel;
+   omap_96m_alwon_fck.recalc = &omap2_clksel_recalc;
+   }
+
}
 
 	clk_init(&omap2_clk_functions);

diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h
index 93c92e5..6fe89df 100644
--- a/arch/arm/mach-omap2/clock34xx.h
+++ b/arch/arm/mach-omap2/clock34xx.h
@@ -654,12 +654,31 @@ static struct clk dpll4_m2x2_ck = {
.recalc = &omap3_clkoutx2_recalc,
 };
 
+/* Adding 192MHz Clock node needed by SGX */

+static struct clk omap_192m_alwon_ck = {
+   .name   = "omap_192m_alwon_ck",
+   .ops= &clkops_null,
+   .parent = &dpll4_m2x2_ck,
+   .recalc = &followparent_recalc,
+};
+
 /*
  * DPLL4 generates DPLL4_M2X2_CLK which is then routed into the PRM as
  * PRM_96M_ALWON_(F)CLK.  Two clocks then emerge from the PRM:
  * 96M_ALWON_FCLK (called "omap_96m_alwon_fck" below) and
  * CM_96K_(F)CLK.
  */
+static const struct clksel_rate omap_96m_alwon_fck_rates[] = {
+   { .div = 1, .val = 1, .flags = RATE_IN_363X },
+   { .div = 2, .val = 2, .flags = RATE_IN_363X | DEFAULT_RATE },
+   { .div = 0 }
+};
+
+static const struct clksel omap_96m_alwon_fck_clksel[] = {
+   { .parent = &omap_192m_alwon_ck, .rates = omap_96m_alwon_fck_rates },
+   { .parent = NULL }
+};
+
 static struct clk omap_96m_alwon_fck = {
.name   = "omap_96m_alwon_fck",
.ops= &clkops_null,
@@ -1223,6 +1242,18 @@ static const struct clksel_rate sgx_core_rates[] = {
{ .div = 3, .val = 0, .flags = RATE_IN_3XXX | DEFAULT_RATE },
{ .div = 4, .val = 1, .flags = RATE_IN_3XXX },
{ .div = 6, .val = 2, .flags = RATE_IN_3XXX },
+   { .div = 2, .val = 5, .flags = RATE_IN_363X },
dont we have more options here? thinking: does this mean that all 3XXX 
and 36XX defines are valid ones for SGX?



+   { .div = 0 },
+};
+
+static const struct clksel_rate sgx_192m_rates[] = {
+   { .div = 1,  .val = 4, .flags = RATE_IN_363X | DEFAULT_RATE },
+   { .div = 0 },
+};
+
+static const struct clksel_rate sgx_corex2_rates[] = {
+   { .div = 3, .val = 6, .flags = RATE_IN_363X | DEFAULT_RATE },
+   { .div = 5, .val = 7, .flags = RATE_IN_363X },
{ .div = 0 },
 };
 
@@ -1234,6 +1265,8 @@ static const struct clkse

FEATURES - is it good enough (was Re: [PATCH v3 1/2] omap: introduce uart_no_empty_fifo_read feature)

[Nishanth Menon]

Aguirre, Sergio had written, on 11/20/2009 10:14 AM, the following:
 


-Original Message-
From: linux-omap-ow...@vger.kernel.org 
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Nishanth Menon

Sent: Friday, November 20, 2009 10:10 AM
To: Pandita, Vikram
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH v3 1/2] omap: introduce 
uart_no_empty_fifo_read feature


Vikram Pandita had written, on 11/20/2009 10:02 AM, the following:

Interoduce omap feature OMAP3_HAS_UART_NO_EMPTY_FIFO_READ

^ <- you meant introduce

On omap3630/omap4 an empty fifo read causes a crash

Signed-off-by: Vikram Pandita 
Ack-by: Menon, Nishanth 
^ <- :P nope you dont have my Acked-by until you 
change this to 
Acked from Ack ;)..


Thanks for the simpler patch.


---
 arch/arm/mach-omap2/id.c  |7 +++
 arch/arm/plat-omap/include/plat/cpu.h |2 ++
 2 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index f48a4b2..3e266cd 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -176,6 +176,12 @@ void __init omap3_check_features(void)
OMAP3_CHECK_FEATURE(status, NEON);
OMAP3_CHECK_FEATURE(status, ISP);
 
+	/* On omap3630 and omap4: UART empty rx fifo read aborts */

+   if (cpu_is_omap3630())
+   omap3_features |= OMAP3_HAS_UART_NO_EMPTY_FIFO_READ;
+   if (cpu_is_omap44xx())
+   omap3_features |= OMAP3_HAS_UART_NO_EMPTY_FIFO_READ;
+


Probably not something ot be attached in this patch, but...

I'm a bit curious about something:

Why touching omap3_features in OMAP4?

Isn't there a omap4_features?

Or even better, an omap_features?


yep, that is a limitation in today's FEATUREs design which we have to 
fix. I see issues such as:

a) ability to scale across silicons (OMAP1 - 4)
b) differentiate between silicon feature vs erratas
c) limit to 32 bits.. meaning, we may want to think something else at a 
later point..


FEATUREs is the first step in this.. we have more to go for a uniform system



Regards,
Sergio


/*
 * TODO: Get additional info (where applicable)
 *   e.g. Size of L2 cache.
@@ -316,6 +322,7 @@ void __init omap3_cpuinfo(void)
OMAP3_SHOW_FEATURE(sgx);
OMAP3_SHOW_FEATURE(neon);
OMAP3_SHOW_FEATURE(isp);
+   OMAP3_SHOW_FEATURE(uart_no_empty_fifo_read);
 
 	printk(")\n");

 }
diff --git a/arch/arm/plat-omap/include/plat/cpu.h 

b/arch/arm/plat-omap/include/plat/cpu.h

index 2e17890..c32f015 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -497,6 +497,7 @@ extern u32 omap3_features;
 #define OMAP3_HAS_SGX  BIT(2)
 #define OMAP3_HAS_NEON BIT(3)
 #define OMAP3_HAS_ISP  BIT(4)
+#define OMAP3_HAS_UART_NO_EMPTY_FIFO_READ  BIT(5)
 
 #define OMAP3_HAS_FEATURE(feat,flag)			\

 static inline unsigned int omap3_has_ ##feat(void) \
@@ -509,5 +510,6 @@ OMAP3_HAS_FEATURE(sgx, SGX)
 OMAP3_HAS_FEATURE(iva, IVA)
 OMAP3_HAS_FEATURE(neon, NEON)
 OMAP3_HAS_FEATURE(isp, ISP)
+OMAP3_HAS_FEATURE(uart_no_empty_fifo_read, UART_NO_EMPTY_FIFO_READ)
 
 #endif


--
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

RE: [PATCH v3 1/2] omap: introduce uart_no_empty_fifo_read feature

[Aguirre, Sergio]

 

> -Original Message-
> From: linux-omap-ow...@vger.kernel.org 
> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Nishanth Menon
> Sent: Friday, November 20, 2009 10:10 AM
> To: Pandita, Vikram
> Cc: linux-omap@vger.kernel.org
> Subject: Re: [PATCH v3 1/2] omap: introduce 
> uart_no_empty_fifo_read feature
> 
> Vikram Pandita had written, on 11/20/2009 10:02 AM, the following:
> > Interoduce omap feature OMAP3_HAS_UART_NO_EMPTY_FIFO_READ
> ^ <- you meant introduce
> > 
> > On omap3630/omap4 an empty fifo read causes a crash
> > 
> > Signed-off-by: Vikram Pandita 
> > Ack-by: Menon, Nishanth 
> ^ <- :P nope you dont have my Acked-by until you 
> change this to 
> Acked from Ack ;)..
> 
> Thanks for the simpler patch.
> 
> > ---
> >  arch/arm/mach-omap2/id.c  |7 +++
> >  arch/arm/plat-omap/include/plat/cpu.h |2 ++
> >  2 files changed, 9 insertions(+), 0 deletions(-)
> > 
> > diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
> > index f48a4b2..3e266cd 100644
> > --- a/arch/arm/mach-omap2/id.c
> > +++ b/arch/arm/mach-omap2/id.c
> > @@ -176,6 +176,12 @@ void __init omap3_check_features(void)
> > OMAP3_CHECK_FEATURE(status, NEON);
> > OMAP3_CHECK_FEATURE(status, ISP);
> >  
> > +   /* On omap3630 and omap4: UART empty rx fifo read aborts */
> > +   if (cpu_is_omap3630())
> > +   omap3_features |= OMAP3_HAS_UART_NO_EMPTY_FIFO_READ;
> > +   if (cpu_is_omap44xx())
> > +   omap3_features |= OMAP3_HAS_UART_NO_EMPTY_FIFO_READ;
> > +

Probably not something ot be attached in this patch, but...

I'm a bit curious about something:

Why touching omap3_features in OMAP4?

Isn't there a omap4_features?

Or even better, an omap_features?

Regards,
Sergio

> > /*
> >  * TODO: Get additional info (where applicable)
> >  *   e.g. Size of L2 cache.
> > @@ -316,6 +322,7 @@ void __init omap3_cpuinfo(void)
> > OMAP3_SHOW_FEATURE(sgx);
> > OMAP3_SHOW_FEATURE(neon);
> > OMAP3_SHOW_FEATURE(isp);
> > +   OMAP3_SHOW_FEATURE(uart_no_empty_fifo_read);
> >  
> > printk(")\n");
> >  }
> > diff --git a/arch/arm/plat-omap/include/plat/cpu.h 
> b/arch/arm/plat-omap/include/plat/cpu.h
> > index 2e17890..c32f015 100644
> > --- a/arch/arm/plat-omap/include/plat/cpu.h
> > +++ b/arch/arm/plat-omap/include/plat/cpu.h
> > @@ -497,6 +497,7 @@ extern u32 omap3_features;
> >  #define OMAP3_HAS_SGX  BIT(2)
> >  #define OMAP3_HAS_NEON BIT(3)
> >  #define OMAP3_HAS_ISP  BIT(4)
> > +#define OMAP3_HAS_UART_NO_EMPTY_FIFO_READ  BIT(5)
> >  
> >  #define OMAP3_HAS_FEATURE(feat,flag)   \
> >  static inline unsigned int omap3_has_ ##feat(void) \
> > @@ -509,5 +510,6 @@ OMAP3_HAS_FEATURE(sgx, SGX)
> >  OMAP3_HAS_FEATURE(iva, IVA)
> >  OMAP3_HAS_FEATURE(neon, NEON)
> >  OMAP3_HAS_FEATURE(isp, ISP)
> > +OMAP3_HAS_FEATURE(uart_no_empty_fifo_read, UART_NO_EMPTY_FIFO_READ)
> >  
> >  #endif
> 
> 
> -- 
> 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 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

Re: [PATCH v3 1/2] omap: introduce uart_no_empty_fifo_read feature

[Nishanth Menon]

Vikram Pandita had written, on 11/20/2009 10:02 AM, the following:

Interoduce omap feature OMAP3_HAS_UART_NO_EMPTY_FIFO_READ

   ^ <- you meant introduce


On omap3630/omap4 an empty fifo read causes a crash

Signed-off-by: Vikram Pandita 
Ack-by: Menon, Nishanth 
   ^ <- :P nope you dont have my Acked-by until you change this to 
Acked from Ack ;)..


Thanks for the simpler patch.


---
 arch/arm/mach-omap2/id.c  |7 +++
 arch/arm/plat-omap/include/plat/cpu.h |2 ++
 2 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index f48a4b2..3e266cd 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -176,6 +176,12 @@ void __init omap3_check_features(void)
OMAP3_CHECK_FEATURE(status, NEON);
OMAP3_CHECK_FEATURE(status, ISP);
 
+	/* On omap3630 and omap4: UART empty rx fifo read aborts */

+   if (cpu_is_omap3630())
+   omap3_features |= OMAP3_HAS_UART_NO_EMPTY_FIFO_READ;
+   if (cpu_is_omap44xx())
+   omap3_features |= OMAP3_HAS_UART_NO_EMPTY_FIFO_READ;
+
/*
 * TODO: Get additional info (where applicable)
 *   e.g. Size of L2 cache.
@@ -316,6 +322,7 @@ void __init omap3_cpuinfo(void)
OMAP3_SHOW_FEATURE(sgx);
OMAP3_SHOW_FEATURE(neon);
OMAP3_SHOW_FEATURE(isp);
+   OMAP3_SHOW_FEATURE(uart_no_empty_fifo_read);
 
 	printk(")\n");

 }
diff --git a/arch/arm/plat-omap/include/plat/cpu.h 
b/arch/arm/plat-omap/include/plat/cpu.h
index 2e17890..c32f015 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -497,6 +497,7 @@ extern u32 omap3_features;
 #define OMAP3_HAS_SGX  BIT(2)
 #define OMAP3_HAS_NEON BIT(3)
 #define OMAP3_HAS_ISP  BIT(4)
+#define OMAP3_HAS_UART_NO_EMPTY_FIFO_READ  BIT(5)
 
 #define OMAP3_HAS_FEATURE(feat,flag)			\

 static inline unsigned int omap3_has_ ##feat(void) \
@@ -509,5 +510,6 @@ OMAP3_HAS_FEATURE(sgx, SGX)
 OMAP3_HAS_FEATURE(iva, IVA)
 OMAP3_HAS_FEATURE(neon, NEON)
 OMAP3_HAS_FEATURE(isp, ISP)
+OMAP3_HAS_FEATURE(uart_no_empty_fifo_read, UART_NO_EMPTY_FIFO_READ)
 
 #endif



--
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

RE: VDD1 voltage after resume from idle

[Premi, Sanjeev]

> -Original Message-
> From: Menon, Nishanth 
> Sent: Friday, November 20, 2009 9:29 PM
> To: Premi, Sanjeev; linux-omap@vger.kernel.org
> Subject: RE: VDD1 voltage after resume from idle
> 
> > From: Premi, Sanjeev
> > Sent: Friday, November 20, 2009 9:54 AM
> > > >
> > > > Hi,
> > > >
> > > > I am facing a strange problem on OMAP3EVM after 
> resuming from idle.
> > > > When using OPP5, the VDD1 voltage ramps to 1.35V.
> > > >
> > > > However, when i go thru the idle/wakeup cycle, the voltage never
> > > > ramps back to 1.35V but stays at 1.20V.
> > > >
> > > > I don't notice many changes in smartreflex.c since 
> 2.6.31-rc7 but
> > > > this problem is not observed there. Actually, here the voltage
> > > > did not drop during suspend at all.
> > > >
> > > > While I continue to debug, any suggestions?
> > >
> > > Look for retention voltage setup (they should be OPP dependent)..
> > > this was one of my plans of cleanups anyways..
> > 
> > So far the problem seems to be optimizations in the 
> enable_smartreflex and
> > disable_smartreflex.
> > 
> > On resume path, enable_smartreflex() is called, but doesn't 
> do anything
> > unless autocomp flag is on. This is different from the 
> boot-time where
> > the current freq is looked at and appropriate voltage is set.
> > 
> > I am currently trying to get rid of optimizations and see 
> the result.
> > We do need the optimizations; but may be different ones.
> What specific optimization are you talking about?
> http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-p
> m.git;a=blob;f=arch/arm/mach-omap2/resource34xx.c;h=04be4d2694
> 5beccf81cad08a8cdfc6086d6ce70a;hb=refs/heads/pm#l277 ?

I not using SRF - vanilla no-op layer.

The optimization is check for is_autocomp_active and is_sr_reset flags.
unless both are set, there is no real processing in the both the functions.

However, I it is possible that voltage processor has lost the configuration
set earlier via sr_configure_vp(). Only thing still puzzling me is that
same behavior occurs even when enable_off_mode=0 (Only sleep_while_idle=1).

Or, it may just be something missing at init...

Best regards,
Sanjeev

> 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

[PATCH v3 2/2] omap: serial: fix non-empty uart fifo read abort

[Vikram Pandita]

OMAP3630 and OMAP4430 UART IP blocks have a restriction wrt RX FIFO.
Empty RX fifo read causes an abort. OMAP1/2/3 do not have this restriction.

Override the default 8250 read handler: mem_serial_in()
by a custom handler: serial_in_8250()

serial_in_8250() makes sure that RX fifo is not read when empty,
on omap4 and 3630 silicons only

tested on zoom3(3630) board

Signed-off-by: Vikram Pandita 
Cc: Alan Cox 
---
 arch/arm/mach-omap2/serial.c |   21 +
 1 files changed, 21 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 2e17b57..600e4d2 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -572,6 +572,23 @@ static struct omap_uart_state omap_uart[] = {
 #endif
 };
 
+/*
+ * Override the default 8250 read handler: mem_serial_in()
+ * Empty RX fifo read causes an abort on omap3630 and omap4
+ * This function makes sure that an empty rx fifo is not read on these silicons
+ * (OMAP1/2/3 are not affected)
+ */
+static unsigned int serial_in_override(struct uart_port *up, int offset)
+{
+   if (UART_RX == offset) {
+   unsigned int lsr;
+   lsr = serial_read_reg(omap_uart[up->line].p, UART_LSR);
+   if (!(lsr & UART_LSR_DR))
+   return -EPERM;
+   }
+   return serial_read_reg(omap_uart[up->line].p, offset);
+}
+
 void __init omap_serial_early_init(void)
 {
int i;
@@ -627,6 +644,10 @@ void __init omap_serial_early_init(void)
if (cpu_is_omap44xx())
p->irq += 32;
 
+   /* Do not read empty UART fifo on omap3630/omap4 */
+   if (omap3_has_uart_no_empty_fifo_read())
+   p->serial_in = serial_in_override;
+
omap_uart_enable_clocks(uart);
}
 }
-- 
1.6.5.1.69.g36942

--
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

[PATCH v3 0/2] omap: serial: handle abort on empty rx fifo read

[Vikram Pandita]

introduce OMAP3_HAS_UART_NO_EMPTY_FIFO_READ feature

this feature is set for omap3630 and omap4 currently as 
empty uart rx fifo read causes an abort

check on this feature on omap3630 and omap4 for now and extend for future
vairants in future

Patch history:
V1: initial implementation
http://patchwork.kernel.org/patch/60785/
http://patchwork.kernel.org/patch/60786/

V2: incorporate review comments from Alan Cox
http://patchwork.kernel.org/patch/60785/
to remove 8250.c file changes by override serial_in
No 8250 driver change required now

V3: incorporate review comments
khilman: make function override only for affected silicons
nishant m: interoduce has_feature check, rather than cpu_is
anand g: minor commit message change

Vikram Pandita (2):
  omap: introduce uart_no_empty_fifo_read feature
  omap: serial: fix non-empty uart fifo read abort

 arch/arm/mach-omap2/id.c  |7 +++
 arch/arm/mach-omap2/serial.c  |   21 +
 arch/arm/plat-omap/include/plat/cpu.h |2 ++
 3 files changed, 30 insertions(+), 0 deletions(-)

--
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

[PATCH v3 1/2] omap: introduce uart_no_empty_fifo_read feature

[Vikram Pandita]

Interoduce omap feature OMAP3_HAS_UART_NO_EMPTY_FIFO_READ

On omap3630/omap4 an empty fifo read causes a crash

Signed-off-by: Vikram Pandita 
Ack-by: Menon, Nishanth 
---
 arch/arm/mach-omap2/id.c  |7 +++
 arch/arm/plat-omap/include/plat/cpu.h |2 ++
 2 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index f48a4b2..3e266cd 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -176,6 +176,12 @@ void __init omap3_check_features(void)
OMAP3_CHECK_FEATURE(status, NEON);
OMAP3_CHECK_FEATURE(status, ISP);
 
+   /* On omap3630 and omap4: UART empty rx fifo read aborts */
+   if (cpu_is_omap3630())
+   omap3_features |= OMAP3_HAS_UART_NO_EMPTY_FIFO_READ;
+   if (cpu_is_omap44xx())
+   omap3_features |= OMAP3_HAS_UART_NO_EMPTY_FIFO_READ;
+
/*
 * TODO: Get additional info (where applicable)
 *   e.g. Size of L2 cache.
@@ -316,6 +322,7 @@ void __init omap3_cpuinfo(void)
OMAP3_SHOW_FEATURE(sgx);
OMAP3_SHOW_FEATURE(neon);
OMAP3_SHOW_FEATURE(isp);
+   OMAP3_SHOW_FEATURE(uart_no_empty_fifo_read);
 
printk(")\n");
 }
diff --git a/arch/arm/plat-omap/include/plat/cpu.h 
b/arch/arm/plat-omap/include/plat/cpu.h
index 2e17890..c32f015 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -497,6 +497,7 @@ extern u32 omap3_features;
 #define OMAP3_HAS_SGX  BIT(2)
 #define OMAP3_HAS_NEON BIT(3)
 #define OMAP3_HAS_ISP  BIT(4)
+#define OMAP3_HAS_UART_NO_EMPTY_FIFO_READ  BIT(5)
 
 #define OMAP3_HAS_FEATURE(feat,flag)   \
 static inline unsigned int omap3_has_ ##feat(void) \
@@ -509,5 +510,6 @@ OMAP3_HAS_FEATURE(sgx, SGX)
 OMAP3_HAS_FEATURE(iva, IVA)
 OMAP3_HAS_FEATURE(neon, NEON)
 OMAP3_HAS_FEATURE(isp, ISP)
+OMAP3_HAS_FEATURE(uart_no_empty_fifo_read, UART_NO_EMPTY_FIFO_READ)
 
 #endif
-- 
1.6.5.1.69.g36942

--
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

Re: [PATCHV2 3/4] OMAP3: Correct width for CLKSEL Fields

[Nishanth Menon]

Hi Vishwa,
Thanks for the patch, few comments follow:
Sripathy, Vishwanath had written, on 11/20/2009 09:28 AM, the following:

DPLL4 M, M3, M4, M5 and M6 field width has been increased by 1 bit in
3630.This patch has changes to accommodate this in CM dynamically based on
chip version.

Signed-off-by: Vishwanath BS 
---
 arch/arm/mach-omap2/clock34xx.c |   18 --
 arch/arm/mach-omap2/clock34xx.h |   53 --
 arch/arm/mach-omap2/cm-regbits-34xx.h   |7 +++-
 arch/arm/plat-omap/include/plat/clock.h |4 +-
 4 files changed, 71 insertions(+), 11 deletions(-)
 mode change 100644 => 100755 arch/arm/mach-omap2/clock34xx.c

diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
index 167f075..1e35f9a
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -43,6 +43,7 @@
 #include "prm-regbits-34xx.h"
 #include "cm.h"
 #include "cm-regbits-34xx.h"
+#include 
 
 static const struct clkops clkops_noncore_dpll_ops;
 
@@ -97,6 +98,7 @@ struct omap_clk {

 #define CK_3XXX(1 << 0)
 #define CK_3430ES1 (1 << 1)
 #define CK_3430ES2 (1 << 2)
+#define CK_363X(1 << 3)


The patch subject/commit msg and actual action here seem to differ 
unfortunately ->  you are in reality introducing the CK_36XX deltas 
here, you may want to fix the commit message OR split this patch into two:
a) introduce 36XX clocks - You may want to consider these in multiple 
patches each introducing one specific change -> clock wise perhaps.

b) introduce the DPLL4 Mx changes
this will allow:
1. Later traceability when we do a git bisect to know a specific change 
if we are tracking a bug at a later date.

2. easier review for us as each would be one smaller chunk topic to review

 
 static struct omap_clk omap34xx_clks[] = {

CLK(NULL,   "omap_32k_fck",   &omap_32k_fck,  CK_3XXX),
@@ -134,13 +136,13 @@ static struct omap_clk omap34xx_clks[] = {
CLK(NULL,   "omap_12m_fck",   &omap_12m_fck,  CK_3XXX),
CLK(NULL,   "dpll4_m2_ck",&dpll4_m2_ck,   CK_3XXX),
CLK(NULL,   "dpll4_m2x2_ck", &dpll4_m2x2_ck, CK_3XXX),
-   CLK(NULL,   "dpll4_m3_ck",&dpll4_m3_ck,   CK_3XXX),
+   CLK(NULL,   "dpll4_m3_ck",&dpll4_m3_ck,   CK_3XXX | 
CK_363X),



CLK(NULL,   "dpll4_m3x2_ck", &dpll4_m3x2_ck, CK_3XXX),
-   CLK(NULL,   "dpll4_m4_ck",&dpll4_m4_ck,   CK_3XXX),
+   CLK(NULL,   "dpll4_m4_ck",&dpll4_m4_ck,   CK_3XXX | 
CK_363X),
CLK(NULL,   "dpll4_m4x2_ck", &dpll4_m4x2_ck, CK_3XXX),
-   CLK(NULL,   "dpll4_m5_ck",&dpll4_m5_ck,   CK_3XXX),
+   CLK(NULL,   "dpll4_m5_ck",&dpll4_m5_ck,   CK_3XXX | 
CK_363X),
CLK(NULL,   "dpll4_m5x2_ck", &dpll4_m5x2_ck, CK_3XXX),
-   CLK(NULL,   "dpll4_m6_ck",&dpll4_m6_ck,   CK_3XXX),
+   CLK(NULL,   "dpll4_m6_ck",&dpll4_m6_ck,   CK_3XXX | 
CK_363X),
CLK(NULL,   "dpll4_m6x2_ck", &dpll4_m6x2_ck, CK_3XXX),
CLK(NULL,   "emu_per_alwon_ck", &emu_per_alwon_ck, CK_3XXX),
CLK(NULL,   "dpll5_ck",   &dpll5_ck,  CK_3430ES2),
@@ -1222,6 +1224,8 @@ int __init omap2_clk_init(void)
OMAP3630_PERIPH_DPLL_DCO_SEL_MASK;
dpll4_ck.dpll_data->sd_div_mask =
OMAP3630_PERIPH_DPLL_SD_DIV_MASK;
+   dpll4_dd.mult_mask = OMAP3630_PERIPH_DPLL_MULT_MASK;
+   cpu_mask |= RATE_IN_363X;

these two things probably are different actions..


}
}
 
@@ -1232,6 +1236,12 @@ int __init omap2_clk_init(void)
 
 	for (c = omap34xx_clks; c < omap34xx_clks + ARRAY_SIZE(omap34xx_clks); c++)

if (c->cpu & cpu_clkflg) {
+   /* for 3630, change the mask value for clocks which are
+   marked as CK_363X*/
+   if (cpu_is_omap3630() && (c->cpu & CK_363X)) {
+   c->lk.clk->clksel_mask =
+   c->lk.clk->clksel_mask_3630;
+   }
clkdev_add(&c->lk);
clk_register(c->lk.clk);
omap2_init_clk_clkdm(c->lk.clk);
diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h
index 813a83e..93c92e5 100644
--- a/arch/arm/mach-omap2/clock34xx.h
+++ b/arch/arm/mach-omap2/clock34xx.h
@@ -243,6 +243,42 @@ static const struct clksel_rate div16_dpll_rates[] = {
{ .div = 0 }
 };
 
+static const struct clksel_rate div32_dpll_rates[] = {

+   { .div = 1, .val = 1, .flags = RATE_IN_3XXX | DEFAULT_RATE },
+   { .div = 2, .val = 2, .flags = RATE_IN_3XXX },
+   { .div = 3, .val = 3, .flags = RATE_IN_3XXX },
+   { .div = 4, .val = 4, .flags = RATE_IN_3X

RE: VDD1 voltage after resume from idle

[Menon, Nishanth]

> From: Premi, Sanjeev
> Sent: Friday, November 20, 2009 9:54 AM
> > >
> > > Hi,
> > >
> > > I am facing a strange problem on OMAP3EVM after resuming from idle.
> > > When using OPP5, the VDD1 voltage ramps to 1.35V.
> > >
> > > However, when i go thru the idle/wakeup cycle, the voltage never
> > > ramps back to 1.35V but stays at 1.20V.
> > >
> > > I don't notice many changes in smartreflex.c since 2.6.31-rc7 but
> > > this problem is not observed there. Actually, here the voltage
> > > did not drop during suspend at all.
> > >
> > > While I continue to debug, any suggestions?
> >
> > Look for retention voltage setup (they should be OPP dependent)..
> > this was one of my plans of cleanups anyways..
> 
> So far the problem seems to be optimizations in the enable_smartreflex and
> disable_smartreflex.
> 
> On resume path, enable_smartreflex() is called, but doesn't do anything
> unless autocomp flag is on. This is different from the boot-time where
> the current freq is looked at and appropriate voltage is set.
> 
> I am currently trying to get rid of optimizations and see the result.
> We do need the optimizations; but may be different ones.
What specific optimization are you talking about?
http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=blob;f=arch/arm/mach-omap2/resource34xx.c;h=04be4d26945beccf81cad08a8cdfc6086d6ce70a;hb=refs/heads/pm#l277
 ?
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

RE: [PATCHV2 3/4] OMAP3: Correct width for CLKSEL Fields

[Aguirre, Sergio]

Vishwa, 

> -Original Message-
> From: linux-omap-ow...@vger.kernel.org 
> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of 
> Sripathy, Vishwanath
> Sent: Friday, November 20, 2009 9:29 AM
> To: linux-omap@vger.kernel.org; Sripathy, Vishwanath
> Subject: [PATCHV2 3/4] OMAP3: Correct width for CLKSEL Fields
> 
> DPLL4 M, M3, M4, M5 and M6 field width has been increased by 1 bit in
> 3630.This patch has changes to accommodate this in CM 
> dynamically based on
> chip version.
> 
> Signed-off-by: Vishwanath BS 
> ---
>  arch/arm/mach-omap2/clock34xx.c |   18 --
>  arch/arm/mach-omap2/clock34xx.h |   53 
> --
>  arch/arm/mach-omap2/cm-regbits-34xx.h   |7 +++-
>  arch/arm/plat-omap/include/plat/clock.h |4 +-
>  4 files changed, 71 insertions(+), 11 deletions(-)
>  mode change 100644 => 100755 arch/arm/mach-omap2/clock34xx.c

No file mode changes, please.

> 
> diff --git a/arch/arm/mach-omap2/clock34xx.c 
> b/arch/arm/mach-omap2/clock34xx.c
> index 167f075..1e35f9a
> --- a/arch/arm/mach-omap2/clock34xx.c
> +++ b/arch/arm/mach-omap2/clock34xx.c
> @@ -43,6 +43,7 @@
>  #include "prm-regbits-34xx.h"
>  #include "cm.h"
>  #include "cm-regbits-34xx.h"
> +#include 
>  
>  static const struct clkops clkops_noncore_dpll_ops;
>  
> @@ -97,6 +98,7 @@ struct omap_clk {
>  #define CK_3XXX  (1 << 0)
>  #define CK_3430ES1   (1 << 1)
>  #define CK_3430ES2   (1 << 2)
> +#define CK_363X  (1 << 3)
>  
>  static struct omap_clk omap34xx_clks[] = {
>   CLK(NULL,   "omap_32k_fck", &omap_32k_fck,  CK_3XXX),
> @@ -134,13 +136,13 @@ static struct omap_clk omap34xx_clks[] = {
>   CLK(NULL,   "omap_12m_fck", &omap_12m_fck,  CK_3XXX),
>   CLK(NULL,   "dpll4_m2_ck",  &dpll4_m2_ck,   CK_3XXX),
>   CLK(NULL,   "dpll4_m2x2_ck", &dpll4_m2x2_ck, CK_3XXX),
> - CLK(NULL,   "dpll4_m3_ck",  &dpll4_m3_ck,   CK_3XXX),
> + CLK(NULL,   "dpll4_m3_ck",  &dpll4_m3_ck,   CK_3XXX 
> | CK_363X),

Shouldn't CK_363X replace CK_3XXX?

CK_363X is always inside the CK_3XXX scope, but not the other way around.

>   CLK(NULL,   "dpll4_m3x2_ck", &dpll4_m3x2_ck, CK_3XXX),
> - CLK(NULL,   "dpll4_m4_ck",  &dpll4_m4_ck,   CK_3XXX),
> + CLK(NULL,   "dpll4_m4_ck",  &dpll4_m4_ck,   CK_3XXX 
> | CK_363X),
>   CLK(NULL,   "dpll4_m4x2_ck", &dpll4_m4x2_ck, CK_3XXX),
> - CLK(NULL,   "dpll4_m5_ck",  &dpll4_m5_ck,   CK_3XXX),
> + CLK(NULL,   "dpll4_m5_ck",  &dpll4_m5_ck,   CK_3XXX 
> | CK_363X),
>   CLK(NULL,   "dpll4_m5x2_ck", &dpll4_m5x2_ck, CK_3XXX),
> - CLK(NULL,   "dpll4_m6_ck",  &dpll4_m6_ck,   CK_3XXX),
> + CLK(NULL,   "dpll4_m6_ck",  &dpll4_m6_ck,   CK_3XXX 
> | CK_363X),
>   CLK(NULL,   "dpll4_m6x2_ck", &dpll4_m6x2_ck, CK_3XXX),
>   CLK(NULL,   "emu_per_alwon_ck", &emu_per_alwon_ck, CK_3XXX),
>   CLK(NULL,   "dpll5_ck", &dpll5_ck,  CK_3430ES2),
> @@ -1222,6 +1224,8 @@ int __init omap2_clk_init(void)
>   OMAP3630_PERIPH_DPLL_DCO_SEL_MASK;
>   dpll4_ck.dpll_data->sd_div_mask =
>   OMAP3630_PERIPH_DPLL_SD_DIV_MASK;
> + dpll4_dd.mult_mask = 
> OMAP3630_PERIPH_DPLL_MULT_MASK;
> + cpu_mask |= RATE_IN_363X;
>   }
>   }
>  
> @@ -1232,6 +1236,12 @@ int __init omap2_clk_init(void)
>  
>   for (c = omap34xx_clks; c < omap34xx_clks + 
> ARRAY_SIZE(omap34xx_clks); c++)
>   if (c->cpu & cpu_clkflg) {
> + /* for 3630, change the mask value for 
> clocks which are
> + marked as CK_363X*/
> + if (cpu_is_omap3630() && (c->cpu & CK_363X)) {
> + c->lk.clk->clksel_mask =
> + 
> c->lk.clk->clksel_mask_3630;
> + }
>   clkdev_add(&c->lk);
>   clk_register(c->lk.clk);
>   omap2_init_clk_clkdm(c->lk.clk);
> diff --git a/arch/arm/mach-omap2/clock34xx.h 
> b/arch/arm/mach-omap2/clock34xx.h
> index 813a83e..93c92e5 100644
> --- a/arch/arm/mach-omap2/clock34xx.h
> +++ b/arch/arm/mach-omap2/clock34xx.h
> @@ -243,6 +243,42 @@ static const struct clksel_rate 
> div16_dpll_rates[] = {
>   { .div = 0 }
>  };
>  
> +static const struct clksel_rate div32_dpll_rates[] = {
> + { .div = 1, .val = 1, .flags = RATE_IN_3XXX | DEFAULT_RATE },
> + { .div = 2, .val = 2, .flags = RATE_IN_3XXX },
> + { .div = 3, .val = 3, .flags = RATE_IN_3XXX },
> + { .div = 4, .val = 4, .flags = RATE_IN_3XXX },
> + { .div = 5, .val = 5, .flags = RATE_IN_3XXX },
> + { .div = 6, .val = 6, .flags = RATE_IN_3XXX },
> + { .div = 7, .val = 7, .flags = RATE_IN_3XXX },
> + { .div = 8, .val = 8, .flags = RATE_IN_3XXX },
> + { .div = 9, .val = 9, .flags = RATE_IN_3XXX },
> + { .div =

RE: VDD1 voltage after resume from idle

[Premi, Sanjeev]

> -Original Message-
> From: Menon, Nishanth 
> Sent: Friday, November 20, 2009 9:19 PM
> To: Premi, Sanjeev; linux-omap@vger.kernel.org
> Subject: RE: VDD1 voltage after resume from idle
> 
> > -Original Message-
> > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> > ow...@vger.kernel.org] On Behalf Of Premi, Sanjeev
> > Sent: Friday, November 20, 2009 9:47 AM
> > To: linux-omap@vger.kernel.org
> > Subject: VDD1 voltage after resume from idle
> > 
> > Hi,
> > 
> > I am facing a strange problem on OMAP3EVM after resuming from idle.
> > When using OPP5, the VDD1 voltage ramps to 1.35V.
> > 
> > However, when i go thru the idle/wakeup cycle, the voltage never
> > ramps back to 1.35V but stays at 1.20V.
> > 
> > I don't notice many changes in smartreflex.c since 2.6.31-rc7 but
> > this problem is not observed there. Actually, here the voltage
> > did not drop during suspend at all.
> > 
> > While I continue to debug, any suggestions?
> 
> Look for retention voltage setup (they should be OPP dependent).. 
> this was one of my plans of cleanups anyways..

So far the problem seems to be optimizations in the enable_smartreflex and
disable_smartreflex.

On resume path, enable_smartreflex() is called, but doesn't do anything
unless autocomp flag is on. This is different from the boot-time where
the current freq is looked at and appropriate voltage is set.

I am currently trying to get rid of optimizations and see the result.
We do need the optimizations; but may be different ones.

~sanjeev

> 
> > 
> > Best regards,
> > Sanjeev
> 
> 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

RE: VDD1 voltage after resume from idle

[Menon, Nishanth]

> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Premi, Sanjeev
> Sent: Friday, November 20, 2009 9:47 AM
> To: linux-omap@vger.kernel.org
> Subject: VDD1 voltage after resume from idle
> 
> Hi,
> 
> I am facing a strange problem on OMAP3EVM after resuming from idle.
> When using OPP5, the VDD1 voltage ramps to 1.35V.
> 
> However, when i go thru the idle/wakeup cycle, the voltage never
> ramps back to 1.35V but stays at 1.20V.
> 
> I don't notice many changes in smartreflex.c since 2.6.31-rc7 but
> this problem is not observed there. Actually, here the voltage
> did not drop during suspend at all.
> 
> While I continue to debug, any suggestions?

Look for retention voltage setup (they should be OPP dependent).. 
this was one of my plans of cleanups anyways..

> 
> Best regards,
> Sanjeev

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

VDD1 voltage after resume from idle

[Premi, Sanjeev]

Hi,
 
I am facing a strange problem on OMAP3EVM after resuming from idle.
When using OPP5, the VDD1 voltage ramps to 1.35V.
 
However, when i go thru the idle/wakeup cycle, the voltage never
ramps back to 1.35V but stays at 1.20V.
 
I don't notice many changes in smartreflex.c since 2.6.31-rc7 but
this problem is not observed there. Actually, here the voltage
did not drop during suspend at all.
 
While I continue to debug, any suggestions?
 
Best regards,
Sanjeev
--
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

Re: [PATCHV2 2/4] OMAP3: Clock Type change for OMAP3 Clocks

[Nishanth Menon]

Thanks for the patch. few minor comments follow

Vishwanath BS had written, on 11/20/2009 09:28 AM, the following:

please provide a detailed commit message why we want to shift from 34XX 
to 3XXX define.



Signed-off-by: Vishwanath BS 
---
 arch/arm/mach-omap2/clock.h |   15 +-
 arch/arm/mach-omap2/clock34xx.c |  370 +++---
 arch/arm/mach-omap2/clock34xx.h |  158 +++---
 arch/arm/plat-omap/include/plat/clock.h |2 +-
 4 files changed, 274 insertions(+), 271 deletions(-)

diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index 43b6bed..8ceefcc 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -79,20 +79,23 @@ extern u8 cpu_mask;

 /* clksel_rate data common to 24xx/343x */
 static const struct clksel_rate gpt_32k_rates[] = {
-{ .div = 1, .val = 0, .flags = RATE_IN_24XX | RATE_IN_343X | 
DEFAULT_RATE },
+{ .div = 1, .val = 0, .flags = RATE_IN_24XX | RATE_IN_3XXX |
+   DEFAULT_RATE },
 { .div = 0 }
 };

 static const struct clksel_rate gpt_sys_rates[] = {
-{ .div = 1, .val = 1, .flags = RATE_IN_24XX | RATE_IN_343X | 
DEFAULT_RATE },
+{ .div = 1, .val = 1, .flags = RATE_IN_24XX | RATE_IN_3XXX |
+   DEFAULT_RATE },
 { .div = 0 }
 };

 static const struct clksel_rate gfx_l3_rates[] = {
-   { .div = 1, .val = 1, .flags = RATE_IN_24XX | RATE_IN_343X },
-   { .div = 2, .val = 2, .flags = RATE_IN_24XX | RATE_IN_343X | 
DEFAULT_RATE },
-   { .div = 3, .val = 3, .flags = RATE_IN_243X | RATE_IN_343X },
-   { .div = 4, .val = 4, .flags = RATE_IN_243X | RATE_IN_343X },
+   { .div = 1, .val = 1, .flags = RATE_IN_24XX | RATE_IN_3XXX },
+   { .div = 2, .val = 2, .flags = RATE_IN_24XX | RATE_IN_3XXX |
+   DEFAULT_RATE },
+   { .div = 3, .val = 3, .flags = RATE_IN_243X | RATE_IN_3XXX },
+   { .div = 4, .val = 4, .flags = RATE_IN_243X | RATE_IN_3XXX },
{ .div = 0 }
 };

diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
index 832ed0b..167f075 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -94,69 +94,69 @@ struct omap_clk {
},  \
}

-#define CK_343X(1 << 0)
+#define CK_3XXX(1 << 0)
 #define CK_3430ES1 (1 << 1)
 #define CK_3430ES2 (1 << 2)


unrelated to this patch - just a reminder to all that we need to kill 
the above defines at a later point -> ES1 is not a production device. 
ES2 and 3XXX should ideally not be differentiated with ES3.x devices - 
not thought yet why they would be different, any comments to the effect 
will be good -> but we probably need to clean those out elegantly later 
on I guess.




 static struct omap_clk omap34xx_clks[] = {
-   CLK(NULL,   "omap_32k_fck", &omap_32k_fck,  CK_343X),
-   CLK(NULL,   "virt_12m_ck",  &virt_12m_ck,   CK_343X),
-   CLK(NULL,   "virt_13m_ck",  &virt_13m_ck,   CK_343X),
+   CLK(NULL,   "omap_32k_fck", &omap_32k_fck,  CK_3XXX),
+   CLK(NULL,   "virt_12m_ck",  &virt_12m_ck,   CK_3XXX),
+   CLK(NULL,   "virt_13m_ck",  &virt_13m_ck,   CK_3XXX),
CLK(NULL,   "virt_16_8m_ck", &virt_16_8m_ck, CK_3430ES2),
-   CLK(NULL,   "virt_19_2m_ck", &virt_19_2m_ck, CK_343X),
-   CLK(NULL,   "virt_26m_ck",  &virt_26m_ck,   CK_343X),
-   CLK(NULL,   "virt_38_4m_ck", &virt_38_4m_ck, CK_343X),
-   CLK(NULL,   "osc_sys_ck",   &osc_sys_ck,CK_343X),
-   CLK(NULL,   "sys_ck",   &sys_ck,CK_343X),
-   CLK(NULL,   "sys_altclk",   &sys_altclk,CK_343X),
-   CLK(NULL,   "mcbsp_clks",   &mcbsp_clks,CK_343X),
-   CLK(NULL,   "sys_clkout1",  &sys_clkout1,   CK_343X),
-   CLK(NULL,   "dpll1_ck", &dpll1_ck,  CK_343X),
-   CLK(NULL,   "dpll1_x2_ck",  &dpll1_x2_ck,   CK_343X),
-   CLK(NULL,   "dpll1_x2m2_ck", &dpll1_x2m2_ck, CK_343X),
-   CLK(NULL,   "dpll2_ck", &dpll2_ck,  CK_343X),
-   CLK(NULL,   "dpll2_m2_ck",  &dpll2_m2_ck,   CK_343X),
-   CLK(NULL,   "dpll3_ck", &dpll3_ck,  CK_343X),
-   CLK(NULL,   "core_ck",  &core_ck,   CK_343X),
-   CLK(NULL,   "dpll3_x2_ck",  &dpll3_x2_ck,   CK_343X),
-   CLK(NULL,   "dpll3_m2_ck",  &dpll3_m2_ck,   CK_343X),
-   CLK(NULL,   "dpll3_m2x2_ck", &dpll3_m2x2_ck, CK_343X),
-   CLK(NULL,   "dpll3_m3_ck",  &dpll3_m3_ck,   CK_343X),
-   CLK(NULL,   "dpll3_m3x2_ck", &dpll3_m3x2_ck, CK_343X),
-   CLK(NULL,   "emu_core_alwon_ck", &emu_core_alwon_ck, CK_343X),
-   CLK(NULL,   "dpll4_ck", &dpll4_ck,  CK_343X),
-   CLK(NULL,   "dpll4_x2_ck",  &dpll4_x2_ck,   CK_343X),
-   CLK(NULL

[PATCHV2 4/4] OMAP3: add support for 192Mhz sgx clock

[Vishwanath BS]

SGX can run at 192MHz on 3630 and this patch has changes to support this
feature. Basically DPLL4 M2 will be 192Mhz which will be used as SGX
Clock. 192Mhz clock is divided by 2 (using CM_CLKSEL_CORE) to generate
96Mh clock

Signed-off-by: Vishwanath BS 
---
 arch/arm/mach-omap2/clock34xx.c   |   16 +++-
 arch/arm/mach-omap2/clock34xx.h   |   33 +
 arch/arm/mach-omap2/cm-regbits-34xx.h |2 ++
 arch/arm/mach-omap2/id.c  |7 +--
 arch/arm/plat-omap/include/plat/cpu.h |3 +++
 5 files changed, 58 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
index 1e35f9a..bce7e46 100755
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -128,6 +128,7 @@ static struct omap_clk omap34xx_clks[] = {
CLK(NULL,   "emu_core_alwon_ck", &emu_core_alwon_ck, CK_3XXX),
CLK(NULL,   "dpll4_ck", &dpll4_ck,  CK_3XXX),
CLK(NULL,   "dpll4_x2_ck",  &dpll4_x2_ck,   CK_3XXX),
+   CLK(NULL,   "omap_192m_alwon_ck", &omap_192m_alwon_ck, CK_363X),
CLK(NULL,   "omap_96m_alwon_fck", &omap_96m_alwon_fck, CK_3XXX),
CLK(NULL,   "omap_96m_fck", &omap_96m_fck,  CK_3XXX),
CLK(NULL,   "cm_96m_fck",   &cm_96m_fck,CK_3XXX),
@@ -1226,7 +1227,20 @@ int __init omap2_clk_init(void)
OMAP3630_PERIPH_DPLL_SD_DIV_MASK;
dpll4_dd.mult_mask = OMAP3630_PERIPH_DPLL_MULT_MASK;
cpu_mask |= RATE_IN_363X;
-   }
+   cpu_clkflg |= CK_363X;
+   }
+
+   if (omap3_has_192mhz_clk()) {
+   omap_96m_alwon_fck.parent = &omap_192m_alwon_ck;
+   omap_96m_alwon_fck.init = &omap2_init_clksel_parent;
+   omap_96m_alwon_fck.clksel_reg =
+   OMAP_CM_REGADDR(CORE_MOD, CM_CLKSEL),
+   omap_96m_alwon_fck.clksel_mask =
+   OMAP3630_CLKSEL_96M_MASK;
+   omap_96m_alwon_fck.clksel = omap_96m_alwon_fck_clksel;
+   omap_96m_alwon_fck.recalc = &omap2_clksel_recalc;
+   }
+
}
 
clk_init(&omap2_clk_functions);
diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h
index 93c92e5..6fe89df 100644
--- a/arch/arm/mach-omap2/clock34xx.h
+++ b/arch/arm/mach-omap2/clock34xx.h
@@ -654,12 +654,31 @@ static struct clk dpll4_m2x2_ck = {
.recalc = &omap3_clkoutx2_recalc,
 };
 
+/* Adding 192MHz Clock node needed by SGX */
+static struct clk omap_192m_alwon_ck = {
+   .name   = "omap_192m_alwon_ck",
+   .ops= &clkops_null,
+   .parent = &dpll4_m2x2_ck,
+   .recalc = &followparent_recalc,
+};
+
 /*
  * DPLL4 generates DPLL4_M2X2_CLK which is then routed into the PRM as
  * PRM_96M_ALWON_(F)CLK.  Two clocks then emerge from the PRM:
  * 96M_ALWON_FCLK (called "omap_96m_alwon_fck" below) and
  * CM_96K_(F)CLK.
  */
+static const struct clksel_rate omap_96m_alwon_fck_rates[] = {
+   { .div = 1, .val = 1, .flags = RATE_IN_363X },
+   { .div = 2, .val = 2, .flags = RATE_IN_363X | DEFAULT_RATE },
+   { .div = 0 }
+};
+
+static const struct clksel omap_96m_alwon_fck_clksel[] = {
+   { .parent = &omap_192m_alwon_ck, .rates = omap_96m_alwon_fck_rates },
+   { .parent = NULL }
+};
+
 static struct clk omap_96m_alwon_fck = {
.name   = "omap_96m_alwon_fck",
.ops= &clkops_null,
@@ -1223,6 +1242,18 @@ static const struct clksel_rate sgx_core_rates[] = {
{ .div = 3, .val = 0, .flags = RATE_IN_3XXX | DEFAULT_RATE },
{ .div = 4, .val = 1, .flags = RATE_IN_3XXX },
{ .div = 6, .val = 2, .flags = RATE_IN_3XXX },
+   { .div = 2, .val = 5, .flags = RATE_IN_363X },
+   { .div = 0 },
+};
+
+static const struct clksel_rate sgx_192m_rates[] = {
+   { .div = 1,  .val = 4, .flags = RATE_IN_363X | DEFAULT_RATE },
+   { .div = 0 },
+};
+
+static const struct clksel_rate sgx_corex2_rates[] = {
+   { .div = 3, .val = 6, .flags = RATE_IN_363X | DEFAULT_RATE },
+   { .div = 5, .val = 7, .flags = RATE_IN_363X },
{ .div = 0 },
 };
 
@@ -1234,6 +1265,8 @@ static const struct clksel_rate sgx_96m_rates[] = {
 static const struct clksel sgx_clksel[] = {
{ .parent = &core_ck,.rates = sgx_core_rates },
{ .parent = &cm_96m_fck, .rates = sgx_96m_rates },
+   { .parent = &omap_192m_alwon_ck, .rates = sgx_192m_rates },
+   { .parent = &corex2_fck, .rates = sgx_corex2_rates },
{ .parent = NULL },
 };
 
diff --git a/arch/arm/mach-omap2/cm-regbits-34xx.h 
b/arch/arm/mach-omap2/cm-regbits-34xx.h
index a6383f9..39b3399 100644
--- a/arch/arm/mach-omap2/cm-regbits-34xx.h
+++ b/arch/arm/mach-omap2/cm-regbits-34xx.h

[PATCHV2 2/4] OMAP3: Clock Type change for OMAP3 Clocks

[Vishwanath BS]

Signed-off-by: Vishwanath BS 
---
 arch/arm/mach-omap2/clock.h |   15 +-
 arch/arm/mach-omap2/clock34xx.c |  370 +++---
 arch/arm/mach-omap2/clock34xx.h |  158 +++---
 arch/arm/plat-omap/include/plat/clock.h |2 +-
 4 files changed, 274 insertions(+), 271 deletions(-)

diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index 43b6bed..8ceefcc 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -79,20 +79,23 @@ extern u8 cpu_mask;
 
 /* clksel_rate data common to 24xx/343x */
 static const struct clksel_rate gpt_32k_rates[] = {
-{ .div = 1, .val = 0, .flags = RATE_IN_24XX | RATE_IN_343X | 
DEFAULT_RATE },
+{ .div = 1, .val = 0, .flags = RATE_IN_24XX | RATE_IN_3XXX |
+   DEFAULT_RATE },
 { .div = 0 }
 };
 
 static const struct clksel_rate gpt_sys_rates[] = {
-{ .div = 1, .val = 1, .flags = RATE_IN_24XX | RATE_IN_343X | 
DEFAULT_RATE },
+{ .div = 1, .val = 1, .flags = RATE_IN_24XX | RATE_IN_3XXX |
+   DEFAULT_RATE },
 { .div = 0 }
 };
 
 static const struct clksel_rate gfx_l3_rates[] = {
-   { .div = 1, .val = 1, .flags = RATE_IN_24XX | RATE_IN_343X },
-   { .div = 2, .val = 2, .flags = RATE_IN_24XX | RATE_IN_343X | 
DEFAULT_RATE },
-   { .div = 3, .val = 3, .flags = RATE_IN_243X | RATE_IN_343X },
-   { .div = 4, .val = 4, .flags = RATE_IN_243X | RATE_IN_343X },
+   { .div = 1, .val = 1, .flags = RATE_IN_24XX | RATE_IN_3XXX },
+   { .div = 2, .val = 2, .flags = RATE_IN_24XX | RATE_IN_3XXX |
+   DEFAULT_RATE },
+   { .div = 3, .val = 3, .flags = RATE_IN_243X | RATE_IN_3XXX },
+   { .div = 4, .val = 4, .flags = RATE_IN_243X | RATE_IN_3XXX },
{ .div = 0 }
 };
 
diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
index 832ed0b..167f075 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -94,69 +94,69 @@ struct omap_clk {
},  \
}
 
-#define CK_343X(1 << 0)
+#define CK_3XXX(1 << 0)
 #define CK_3430ES1 (1 << 1)
 #define CK_3430ES2 (1 << 2)
 
 static struct omap_clk omap34xx_clks[] = {
-   CLK(NULL,   "omap_32k_fck", &omap_32k_fck,  CK_343X),
-   CLK(NULL,   "virt_12m_ck",  &virt_12m_ck,   CK_343X),
-   CLK(NULL,   "virt_13m_ck",  &virt_13m_ck,   CK_343X),
+   CLK(NULL,   "omap_32k_fck", &omap_32k_fck,  CK_3XXX),
+   CLK(NULL,   "virt_12m_ck",  &virt_12m_ck,   CK_3XXX),
+   CLK(NULL,   "virt_13m_ck",  &virt_13m_ck,   CK_3XXX),
CLK(NULL,   "virt_16_8m_ck", &virt_16_8m_ck, CK_3430ES2),
-   CLK(NULL,   "virt_19_2m_ck", &virt_19_2m_ck, CK_343X),
-   CLK(NULL,   "virt_26m_ck",  &virt_26m_ck,   CK_343X),
-   CLK(NULL,   "virt_38_4m_ck", &virt_38_4m_ck, CK_343X),
-   CLK(NULL,   "osc_sys_ck",   &osc_sys_ck,CK_343X),
-   CLK(NULL,   "sys_ck",   &sys_ck,CK_343X),
-   CLK(NULL,   "sys_altclk",   &sys_altclk,CK_343X),
-   CLK(NULL,   "mcbsp_clks",   &mcbsp_clks,CK_343X),
-   CLK(NULL,   "sys_clkout1",  &sys_clkout1,   CK_343X),
-   CLK(NULL,   "dpll1_ck", &dpll1_ck,  CK_343X),
-   CLK(NULL,   "dpll1_x2_ck",  &dpll1_x2_ck,   CK_343X),
-   CLK(NULL,   "dpll1_x2m2_ck", &dpll1_x2m2_ck, CK_343X),
-   CLK(NULL,   "dpll2_ck", &dpll2_ck,  CK_343X),
-   CLK(NULL,   "dpll2_m2_ck",  &dpll2_m2_ck,   CK_343X),
-   CLK(NULL,   "dpll3_ck", &dpll3_ck,  CK_343X),
-   CLK(NULL,   "core_ck",  &core_ck,   CK_343X),
-   CLK(NULL,   "dpll3_x2_ck",  &dpll3_x2_ck,   CK_343X),
-   CLK(NULL,   "dpll3_m2_ck",  &dpll3_m2_ck,   CK_343X),
-   CLK(NULL,   "dpll3_m2x2_ck", &dpll3_m2x2_ck, CK_343X),
-   CLK(NULL,   "dpll3_m3_ck",  &dpll3_m3_ck,   CK_343X),
-   CLK(NULL,   "dpll3_m3x2_ck", &dpll3_m3x2_ck, CK_343X),
-   CLK(NULL,   "emu_core_alwon_ck", &emu_core_alwon_ck, CK_343X),
-   CLK(NULL,   "dpll4_ck", &dpll4_ck,  CK_343X),
-   CLK(NULL,   "dpll4_x2_ck",  &dpll4_x2_ck,   CK_343X),
-   CLK(NULL,   "omap_96m_alwon_fck", &omap_96m_alwon_fck, CK_343X),
-   CLK(NULL,   "omap_96m_fck", &omap_96m_fck,  CK_343X),
-   CLK(NULL,   "cm_96m_fck",   &cm_96m_fck,CK_343X),
-   CLK(NULL,   "omap_54m_fck", &omap_54m_fck,  CK_343X),
-   CLK(NULL,   "omap_48m_fck", &omap_48m_fck,  CK_343X),
-   CLK(NULL,   "omap_12m_fck", &omap_12m_fck,  CK_343X),
-   CLK(NULL,   "dpll4_m2_ck",  &dpll4_m2_ck,   CK_343X),
-   CLK(NULL,   "dpll4_m2x2_ck", &dpll4_m2x2_ck, CK_343X),
-   CLK(NULL,   "dpll4_m3_ck",  &dpll4_m3_ck,   

[PATCHV2 3/4] OMAP3: Correct width for CLKSEL Fields

[Vishwanath BS]

DPLL4 M, M3, M4, M5 and M6 field width has been increased by 1 bit in
3630.This patch has changes to accommodate this in CM dynamically based on
chip version.

Signed-off-by: Vishwanath BS 
---
 arch/arm/mach-omap2/clock34xx.c |   18 --
 arch/arm/mach-omap2/clock34xx.h |   53 --
 arch/arm/mach-omap2/cm-regbits-34xx.h   |7 +++-
 arch/arm/plat-omap/include/plat/clock.h |4 +-
 4 files changed, 71 insertions(+), 11 deletions(-)
 mode change 100644 => 100755 arch/arm/mach-omap2/clock34xx.c

diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
index 167f075..1e35f9a
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -43,6 +43,7 @@
 #include "prm-regbits-34xx.h"
 #include "cm.h"
 #include "cm-regbits-34xx.h"
+#include 
 
 static const struct clkops clkops_noncore_dpll_ops;
 
@@ -97,6 +98,7 @@ struct omap_clk {
 #define CK_3XXX(1 << 0)
 #define CK_3430ES1 (1 << 1)
 #define CK_3430ES2 (1 << 2)
+#define CK_363X(1 << 3)
 
 static struct omap_clk omap34xx_clks[] = {
CLK(NULL,   "omap_32k_fck", &omap_32k_fck,  CK_3XXX),
@@ -134,13 +136,13 @@ static struct omap_clk omap34xx_clks[] = {
CLK(NULL,   "omap_12m_fck", &omap_12m_fck,  CK_3XXX),
CLK(NULL,   "dpll4_m2_ck",  &dpll4_m2_ck,   CK_3XXX),
CLK(NULL,   "dpll4_m2x2_ck", &dpll4_m2x2_ck, CK_3XXX),
-   CLK(NULL,   "dpll4_m3_ck",  &dpll4_m3_ck,   CK_3XXX),
+   CLK(NULL,   "dpll4_m3_ck",  &dpll4_m3_ck,   CK_3XXX | CK_363X),
CLK(NULL,   "dpll4_m3x2_ck", &dpll4_m3x2_ck, CK_3XXX),
-   CLK(NULL,   "dpll4_m4_ck",  &dpll4_m4_ck,   CK_3XXX),
+   CLK(NULL,   "dpll4_m4_ck",  &dpll4_m4_ck,   CK_3XXX | CK_363X),
CLK(NULL,   "dpll4_m4x2_ck", &dpll4_m4x2_ck, CK_3XXX),
-   CLK(NULL,   "dpll4_m5_ck",  &dpll4_m5_ck,   CK_3XXX),
+   CLK(NULL,   "dpll4_m5_ck",  &dpll4_m5_ck,   CK_3XXX | CK_363X),
CLK(NULL,   "dpll4_m5x2_ck", &dpll4_m5x2_ck, CK_3XXX),
-   CLK(NULL,   "dpll4_m6_ck",  &dpll4_m6_ck,   CK_3XXX),
+   CLK(NULL,   "dpll4_m6_ck",  &dpll4_m6_ck,   CK_3XXX | CK_363X),
CLK(NULL,   "dpll4_m6x2_ck", &dpll4_m6x2_ck, CK_3XXX),
CLK(NULL,   "emu_per_alwon_ck", &emu_per_alwon_ck, CK_3XXX),
CLK(NULL,   "dpll5_ck", &dpll5_ck,  CK_3430ES2),
@@ -1222,6 +1224,8 @@ int __init omap2_clk_init(void)
OMAP3630_PERIPH_DPLL_DCO_SEL_MASK;
dpll4_ck.dpll_data->sd_div_mask =
OMAP3630_PERIPH_DPLL_SD_DIV_MASK;
+   dpll4_dd.mult_mask = OMAP3630_PERIPH_DPLL_MULT_MASK;
+   cpu_mask |= RATE_IN_363X;
}
}
 
@@ -1232,6 +1236,12 @@ int __init omap2_clk_init(void)
 
for (c = omap34xx_clks; c < omap34xx_clks + ARRAY_SIZE(omap34xx_clks); 
c++)
if (c->cpu & cpu_clkflg) {
+   /* for 3630, change the mask value for clocks which are
+   marked as CK_363X*/
+   if (cpu_is_omap3630() && (c->cpu & CK_363X)) {
+   c->lk.clk->clksel_mask =
+   c->lk.clk->clksel_mask_3630;
+   }
clkdev_add(&c->lk);
clk_register(c->lk.clk);
omap2_init_clk_clkdm(c->lk.clk);
diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h
index 813a83e..93c92e5 100644
--- a/arch/arm/mach-omap2/clock34xx.h
+++ b/arch/arm/mach-omap2/clock34xx.h
@@ -243,6 +243,42 @@ static const struct clksel_rate div16_dpll_rates[] = {
{ .div = 0 }
 };
 
+static const struct clksel_rate div32_dpll_rates[] = {
+   { .div = 1, .val = 1, .flags = RATE_IN_3XXX | DEFAULT_RATE },
+   { .div = 2, .val = 2, .flags = RATE_IN_3XXX },
+   { .div = 3, .val = 3, .flags = RATE_IN_3XXX },
+   { .div = 4, .val = 4, .flags = RATE_IN_3XXX },
+   { .div = 5, .val = 5, .flags = RATE_IN_3XXX },
+   { .div = 6, .val = 6, .flags = RATE_IN_3XXX },
+   { .div = 7, .val = 7, .flags = RATE_IN_3XXX },
+   { .div = 8, .val = 8, .flags = RATE_IN_3XXX },
+   { .div = 9, .val = 9, .flags = RATE_IN_3XXX },
+   { .div = 10, .val = 10, .flags = RATE_IN_3XXX },
+   { .div = 11, .val = 11, .flags = RATE_IN_3XXX },
+   { .div = 12, .val = 12, .flags = RATE_IN_3XXX },
+   { .div = 13, .val = 13, .flags = RATE_IN_3XXX },
+   { .div = 14, .val = 14, .flags = RATE_IN_3XXX },
+   { .div = 15, .val = 15, .flags = RATE_IN_3XXX },
+   { .div = 16, .val = 16, .flags = RATE_IN_3XXX },
+   { .div = 17, .val = 17, .flags = RATE_IN_363X },
+   { .div = 18, .val = 18, .flags = RATE_IN_363X },
+   { .div = 19, .val = 19, .flags = RATE_IN_363X },
+   { .div = 20, .val = 20, .fla

[PATCHV2 1/4] OMAP3: introduce DPLL4 Jtype

[Vishwanath BS]

From: Richard Woodruff 

DPLL4 for 3630 introduces a changed block requiring special divisor bits and
additional reg fields. To allow for silicons to use this, this is introduced 
as a omap3_has_jtype_dpll4() and is enabled for 3630 silicon

Tested with 3630 ZOOM3
Signed-off-by: Richard Woodruff 
Signed-off-by: Nishanth Menon 
Signed-off-by: Vishwanath BS 
---
 arch/arm/mach-omap2/clock34xx.c |   51 ++-
 arch/arm/mach-omap2/cm-regbits-34xx.h   |6 +++-
 arch/arm/mach-omap2/id.c|4 ++-
 arch/arm/plat-omap/include/plat/clock.h |3 ++
 arch/arm/plat-omap/include/plat/cpu.h   |3 +-
 5 files changed, 63 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
index da5bc1f..832ed0b 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -679,6 +679,41 @@ static void omap3_noncore_dpll_disable(struct clk *clk)
_omap3_noncore_dpll_stop(clk);
 }
 
+/**
+ * lookup_dco_sddiv -  Set j-type DPLL4 compensation variables
+ * @clk: pointer to a DPLL struct clk
+ * @dco: digital control oscillator selector
+ * @sd_div: target sigma-delta divider
+ * @m: DPLL multiplier to set
+ * @n: DPLL divider to set
+ */
+static void lookup_dco_sddiv(struct clk *clk, u8 *dco, u8 *sd_div, u16
+   m, u8 n)
+   {
+   unsigned long fint, clkinp, sd; /* watch out for overflow */
+   int mod1, mod2;
+
+   clkinp = clk->parent->rate;
+   fint = (clkinp / n) * m;
+
+   if (fint < 10)
+   *dco = 2;
+   else
+   *dco = 4;
+   /*
+* target sigma-delta to near 250MHz
+* sd = ceil[(m/(n+1)) * (clkinp_MHz / 250)]
+*/
+   clkinp /= 10; /* shift from MHz to 10*Hz for 38.4 and 19.2*/
+   mod1 = (clkinp * m) % (250 * n);
+   sd = (clkinp * m) / (250 * n);
+   mod2 = sd % 10;
+   sd /= 10;
+
+   if (mod1 + mod2)
+   sd++;
+   *sd_div = sd;
+}
 
 /* Non-CORE DPLL rate set code */
 
@@ -711,6 +746,13 @@ static int omap3_noncore_dpll_program(struct clk *clk, u16 
m, u8 n, u16 freqsel)
v &= ~(dd->mult_mask | dd->div1_mask);
v |= m << __ffs(dd->mult_mask);
v |= (n - 1) << __ffs(dd->div1_mask);
+   if (dd->jtype) {
+   u8 dco, sd_div;
+   lookup_dco_sddiv(clk, &dco, &sd_div, m, n);
+   v &= ~(dd->dco_sel_mask | dd->sd_div_mask);
+   v |=  dco << __ffs(dd->dco_sel_mask);
+   v |=  sd_div << __ffs(dd->sd_div_mask);
+   }
__raw_writel(v, dd->mult_div1_reg);
 
/* We let the clock framework set the other output dividers later */
@@ -1026,7 +1068,7 @@ static unsigned long omap3_clkoutx2_recalc(struct clk 
*clk)
 
v = __raw_readl(dd->control_reg) & dd->enable_mask;
v >>= __ffs(dd->enable_mask);
-   if (v != OMAP3XXX_EN_DPLL_LOCKED)
+   if (v != OMAP3XXX_EN_DPLL_LOCKED && (!dd->jtype))
rate = clk->parent->rate;
else
rate = clk->parent->rate * 2;
@@ -1174,6 +1216,13 @@ int __init omap2_clk_init(void)
cpu_mask |= RATE_IN_3430ES2;
cpu_clkflg |= CK_3430ES2;
}
+   if (omap3_has_jtype_dpll4()) {
+   dpll4_ck.dpll_data->jtype = 1;
+   dpll4_ck.dpll_data->dco_sel_mask =
+   OMAP3630_PERIPH_DPLL_DCO_SEL_MASK;
+   dpll4_ck.dpll_data->sd_div_mask =
+   OMAP3630_PERIPH_DPLL_SD_DIV_MASK;
+   }
}
 
clk_init(&omap2_clk_functions);
diff --git a/arch/arm/mach-omap2/cm-regbits-34xx.h 
b/arch/arm/mach-omap2/cm-regbits-34xx.h
index 6923deb..6f2802b 100644
--- a/arch/arm/mach-omap2/cm-regbits-34xx.h
+++ b/arch/arm/mach-omap2/cm-regbits-34xx.h
@@ -516,9 +516,13 @@
 
 /* CM_CLKSEL2_PLL */
 #define OMAP3430_PERIPH_DPLL_MULT_SHIFT8
-#define OMAP3430_PERIPH_DPLL_MULT_MASK (0x7ff << 8)
+#define OMAP3430_PERIPH_DPLL_MULT_MASK (0xfff << 8)
 #define OMAP3430_PERIPH_DPLL_DIV_SHIFT 0
 #define OMAP3430_PERIPH_DPLL_DIV_MASK  (0x7f << 0)
+#define OMAP3630_PERIPH_DPLL_DCO_SEL_SHIFT 21
+#define OMAP3630_PERIPH_DPLL_DCO_SEL_MASK  (0x7 << 21)
+#define OMAP3630_PERIPH_DPLL_SD_DIV_SHIFT  24
+#define OMAP3630_PERIPH_DPLL_SD_DIV_MASK   (0xff << 24)
 
 /* CM_CLKSEL3_PLL */
 #define OMAP3430_DIV_96M_SHIFT 0
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index f48a4b2..3c1194c 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -176,6 +176,8 @@ void __init omap3_check_features(void)
OMAP3_CHECK_FEATURE(status, NEON);
OMAP3_CHECK_FEATURE(status, ISP);
 
+   if (cpu_

[PATCHV2 0/4] OMAP3: Clock changes for OMAP3630

[Vishwanath BS]

This patch set introduces clock changes for OMAP3630. Major changes in OMAP3630 
w.r.t clock are 1. Introduction of j type dpll4 2. CLKSEL filed width is 
increased by 1 bit for DPLL4M3, M4, M5 and M6 3. SGX can be run at 192Mhz

Patch set has been created for linux-omap-pm tree
V1: Initital Patch Series
V2: Fixed Line wrap issue and incorporated comments for adding 192MHz Feature

Richard Woodruff (1):
  OMAP3: introduce DPLL4 Jtype

Vishwanath BS (3):
  OMAP3: Clock Type change for OMAP3 Clocks
  OMAP3: Correct width for CLKSEL Fields
  OMAP3: add support for 192Mhz sgx clock

 arch/arm/mach-omap2/clock.h |   15 +-
 arch/arm/mach-omap2/clock34xx.c |  445 ++-
 arch/arm/mach-omap2/clock34xx.h |  244 +++--
 arch/arm/mach-omap2/cm-regbits-34xx.h   |   11 +
 arch/arm/mach-omap2/id.c|7 +-
 arch/arm/plat-omap/include/plat/clock.h |9 +-
 arch/arm/plat-omap/include/plat/cpu.h   |4 +
 7 files changed, 456 insertions(+), 279 deletions(-)

--
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

Re: [alsa-devel] [PATCH 1/2] OMAP3: MCBSP: Suspend/resume failure fix

[Anuj Aggarwal]

On Fri, Nov 20, 2009 at 7:39 PM, Eero Nurkkala
 wrote:
> On Fri, 2009-11-20 at 14:53 +0100, ext Jarkko Nikula wrote:
>> On Fri, 20 Nov 2009 09:51:13 +0200
>> Peter Ujfalusi  wrote:
>>
>> > > My question is: is sysfs the only way to choose threshold or can it be 
>> > > made
>> > >  as default? I could not see that happening in the code so thinking of 
>> > > the
>> > >  possible reason of choosing not to do so. Because the user who wants to
>> > >  hit suspend will not like to issue driver specific commands. Any 
>> > > specific
>> > >  reason of not doing that by default?
>> >
>> > It is not selected as default on OMAP3, since it is a new feature, and we 
>> > don't
>> > want to change the behavior of the audio. If the reports are positive 
>> > regarding
>> > to the threshold mode, than we can make it as default on OMAP3, at least 
>> > that is
>> > the plan AFAIK.
>>
>> Yep. Currently we want to keep DMA behaviour consistent across the
>> OMAPs and McBSP ports since the large internal FIFO is found only
>> from McBSP2 on OMAP3.
>>
>> This is good finding that you have found that it's the audio preventing
>> the suspend and the threshold transfer mode can make it hit better.
>>
>> But anyway, I'm afraid that threshold mode doesn't help to create
>> robust suspend. Threshold allow the DMA and core to be mode in idle
>> between the FIFO fills and probably that's why suspend might work
>> during these idle periods. For robust implementation there must be
>> explicit code stopping and resuming all activity gracefully so that it
>> can hit the suspend also if the fill is happening or if using another
>> transfer mode.
>>
>>
>
> Looking at the very original patch, I don't know how things could get
> into deep sleep by disabling the fclk only... need to disable the iclk
> also. In threshold mode, HW autogates the iclk, so you may be just
> "lucky".
[Anuj] No, I am not :(. I had to modify the original patch to include
the disable part for the ICLK too. Without that, I was not able to hit
retention.
I will try to do some further regression on OMAP3 EVM and post my
findings. As of now, audio is working fine with these patches + ICLK
modification.
>
> One may want to be aware of this also:
>
> http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commitdiff;h=72cc6d715d5b018e2cff4adb68966855850d4e77
>
> I think it's an undocumented feature.
>
> - Eero
>
> ___
> Alsa-devel mailing list
> alsa-de...@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
--
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

RE: [PATCH] V4L2: clear buf when vrfb buf not allocated

[Y, Kishore]

> -Original Message-
> From: Hiremath, Vaibhav
> Sent: Wednesday, November 18, 2009 8:44 PM
> To: Y, Kishore; linux-me...@vger.kernel.org
> Cc: linux-omap@vger.kernel.org
> Subject: RE: [PATCH] V4L2: clear buf when vrfb buf not allocated
> 
> 
> > -Original Message-
> > From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> > ow...@vger.kernel.org] On Behalf Of Y, Kishore
> > Sent: Wednesday, November 18, 2009 7:20 PM
> > To: linux-me...@vger.kernel.org
> > Cc: linux-omap@vger.kernel.org
> > Subject: [PATCH] V4L2: clear buf when vrfb buf not allocated
> >
> > From 15246e4dfa6853d9aef48a4b8633f93efe40ed81 Mon Sep 17 00:00:00
> > 2001
> > From: Kishore Y 
> > Date: Thu, 12 Nov 2009 20:47:58 +0530
> > Subject: [PATCH] V4L2: clear buf when vrfb buf not allocated
> >
> > buffer memory is set to 0 only for the first time
> > before the vrfb buffer is allocated
> >
> > Signed-off-by:  Kishore Y 
> > ---
> > This patch is dependent on the patch
> > [PATCH 4/4] OMAP2/3 V4L2: Add support for OMAP2/3 V4L2 driver on top
> > of DSS2
> >
> >  drivers/media/video/omap/omap_vout.c |   10 +++---
> >  1 files changed, 7 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/media/video/omap/omap_vout.c
> > b/drivers/media/video/omap/omap_vout.c
> > index 7092ef2..0a9fdd7 100644
> > --- a/drivers/media/video/omap/omap_vout.c
> > +++ b/drivers/media/video/omap/omap_vout.c
> > @@ -223,9 +223,11 @@ static int
> > omap_vout_allocate_vrfb_buffers(struct omap_vout_device *vout,
> > unsigned int *count, int startindex)
> >  {
> > int i, j;
> > +   int buffer_set;
> >
> > for (i = 0; i < *count; i++) {
> > -   if (!vout->smsshado_virt_addr[i]) {
> > +   buffer_set = vout->smsshado_virt_addr[i];
> > +   if (!buffer_set) {
> > vout->smsshado_virt_addr[i] =
> > omap_vout_alloc_buffer(vout->smsshado_size,
> > &vout->smsshado_phy_addr[i]);
> > @@ -247,8 +249,10 @@ static int
> > omap_vout_allocate_vrfb_buffers(struct omap_vout_device *vout,
> > *count = 0;
> > return -ENOMEM;
> > }
> > -   memset((void *) vout->smsshado_virt_addr[i], 0,
> > -   vout->smsshado_size);
> > +   if (!buffer_set) {
> > +   memset((void *) vout->smsshado_virt_addr[i], 0,
> > +   vout->smsshado_size);
> > +   }
> > }
> [Hiremath, Vaibhav] Why do we need this? Anyway if I understand correctly
> this function is getting called only once during REQBUF or probe, right?
> 
> If you are selecting static_vrfb_allocation through module_params, then
> anyway REQBUF won't call this function again, since the buffers are
> already allocated.
> 
> Thanks,
> Vaibhav
> 

[Kishore] omap_vout_vrfb_buffer_setup has been called from streamon to support 
stop-restart use case without calling REQBUF again. Due to the clear buffer we 
are unable to fill buffer in time before display and see green frame for the 
first time when streaming video.

> > return 0;
> >  }
> > --
> > 1.5.4.3
> >
> >
> > Regards,
> > Kishore Y
> > Ph:- +918039813085
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-
> > media" in
> > the body of a message to majord...@vger.kernel.org
> > 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 5/5] ZOOM3: DSS2: zoom3 defconfig changes to enable dss2

[Y, Kishore]

>From c4e51b87aa1d619ff97c220c03363437e5b9b452 Mon Sep 17 00:00:00 2001
From: Kishore 
Date: Tue, 10 Nov 2009 15:00:09 +0530
Subject: [PATCH] ZOOM3: DSS2: zoom3 defconfig changes to enable dss2

Defconfig has been changed to enable nec panel and dss2 on
zoom3 board.

Signed-off-by: Kishore Y 
---
 arch/arm/configs/omap_zoom3_defconfig |  159 -
 1 files changed, 157 insertions(+), 2 deletions(-)

diff --git a/arch/arm/configs/omap_zoom3_defconfig 
b/arch/arm/configs/omap_zoom3_defconfig
index cccd85a..b2cb3b0 100644
--- a/arch/arm/configs/omap_zoom3_defconfig
+++ b/arch/arm/configs/omap_zoom3_defconfig
@@ -209,6 +209,7 @@ CONFIG_OMAP_MUX_DEBUG=y
 CONFIG_OMAP_MUX_WARNINGS=y
 CONFIG_OMAP_MCBSP=y
 # CONFIG_OMAP_MBOX_FWK is not set
+CONFIG_OMAP_IOMMU=y
 # CONFIG_OMAP_MPU_TIMER is not set
 CONFIG_OMAP_32K_TIMER=y
 # CONFIG_OMAP3_DEBOBS is not set
@@ -1002,14 +1003,157 @@ CONFIG_REGULATOR_TWL4030=y
 # CONFIG_REGULATOR_LP3971 is not set
 # CONFIG_REGULATOR_TPS65023 is not set
 # CONFIG_REGULATOR_TPS6507X is not set
-# CONFIG_MEDIA_SUPPORT is not set
+CONFIG_MEDIA_SUPPORT=y
+
+#
+# Multimedia core support
+#
+CONFIG_VIDEO_DEV=y
+CONFIG_VIDEO_V4L2_COMMON=y
+# CONFIG_VIDEO_ALLOW_V4L1 is not set
+CONFIG_VIDEO_V4L1_COMPAT=y
+# CONFIG_DVB_CORE is not set
+CONFIG_VIDEO_MEDIA=y
+
+#
+# Multimedia drivers
+#
+# CONFIG_MEDIA_ATTACH is not set
+CONFIG_MEDIA_TUNER=y
+# CONFIG_MEDIA_TUNER_CUSTOMISE is not set
+CONFIG_MEDIA_TUNER_SIMPLE=y
+CONFIG_MEDIA_TUNER_TDA8290=y
+CONFIG_MEDIA_TUNER_TDA9887=y
+CONFIG_MEDIA_TUNER_TEA5761=y
+CONFIG_MEDIA_TUNER_TEA5767=y
+CONFIG_MEDIA_TUNER_MT20XX=y
+CONFIG_MEDIA_TUNER_XC2028=y
+CONFIG_MEDIA_TUNER_XC5000=y
+CONFIG_MEDIA_TUNER_MC44S803=y
+CONFIG_VIDEO_V4L2=y
+CONFIG_VIDEOBUF_GEN=y
+CONFIG_VIDEOBUF_DMA_SG=y
+CONFIG_VIDEO_CAPTURE_DRIVERS=y
+# CONFIG_VIDEO_ADV_DEBUG is not set
+# CONFIG_VIDEO_FIXED_MINOR_RANGES is not set
+CONFIG_VIDEO_HELPER_CHIPS_AUTO=y
+# CONFIG_VIDEO_VIVI is not set
+# CONFIG_VIDEO_SAA5246A is not set
+# CONFIG_VIDEO_SAA5249 is not set
+CONFIG_VIDEO_OMAP3=y
+CONFIG_VIDEO_OMAP3_OUT=y
+CONFIG_NTSC_M=y
+# CONFIG_PAL_BDGHI is not set
+# CONFIG_SOC_CAMERA is not set
+CONFIG_V4L_USB_DRIVERS=y
+# CONFIG_USB_VIDEO_CLASS is not set
+CONFIG_USB_VIDEO_CLASS_INPUT_EVDEV=y
+CONFIG_USB_GSPCA=m
+# CONFIG_USB_M5602 is not set
+# CONFIG_USB_STV06XX is not set
+# CONFIG_USB_GSPCA_CONEX is not set
+# CONFIG_USB_GSPCA_ETOMS is not set
+# CONFIG_USB_GSPCA_FINEPIX is not set
+# CONFIG_USB_GSPCA_MARS is not set
+# CONFIG_USB_GSPCA_MR97310A is not set
+# CONFIG_USB_GSPCA_OV519 is not set
+# CONFIG_USB_GSPCA_OV534 is not set
+# CONFIG_USB_GSPCA_PAC207 is not set
+# CONFIG_USB_GSPCA_PAC7311 is not set
+# CONFIG_USB_GSPCA_SN9C20X is not set
+# CONFIG_USB_GSPCA_SONIXB is not set
+# CONFIG_USB_GSPCA_SONIXJ is not set
+# CONFIG_USB_GSPCA_SPCA500 is not set
+# CONFIG_USB_GSPCA_SPCA501 is not set
+# CONFIG_USB_GSPCA_SPCA505 is not set
+# CONFIG_USB_GSPCA_SPCA506 is not set
+# CONFIG_USB_GSPCA_SPCA508 is not set
+# CONFIG_USB_GSPCA_SPCA561 is not set
+# CONFIG_USB_GSPCA_SQ905 is not set
+# CONFIG_USB_GSPCA_SQ905C is not set
+# CONFIG_USB_GSPCA_STK014 is not set
+# CONFIG_USB_GSPCA_SUNPLUS is not set
+# CONFIG_USB_GSPCA_T613 is not set
+# CONFIG_USB_GSPCA_TV8532 is not set
+# CONFIG_USB_GSPCA_VC032X is not set
+# CONFIG_USB_GSPCA_ZC3XX is not set
+# CONFIG_VIDEO_PVRUSB2 is not set
+# CONFIG_VIDEO_HDPVR is not set
+# CONFIG_VIDEO_EM28XX is not set
+# CONFIG_VIDEO_CX231XX is not set
+# CONFIG_VIDEO_USBVISION is not set
+# CONFIG_USB_ET61X251 is not set
+# CONFIG_USB_SN9C102 is not set
+# CONFIG_USB_ZC0301 is not set
+CONFIG_USB_PWC_INPUT_EVDEV=y
+# CONFIG_USB_ZR364XX is not set
+# CONFIG_USB_STKWEBCAM is not set
+# CONFIG_USB_S2255 is not set
+CONFIG_RADIO_ADAPTERS=y
+# CONFIG_USB_DSBR is not set
+# CONFIG_USB_SI470X is not set
+# CONFIG_USB_MR800 is not set
+# CONFIG_RADIO_TEA5764 is not set
+# CONFIG_DAB is not set
+
 
 #
 # Graphics support
 #
 # CONFIG_VGASTATE is not set
 CONFIG_VIDEO_OUTPUT_CONTROL=m
-# CONFIG_FB is not set
+CONFIG_FB=y
+# CONFIG_FIRMWARE_EDID is not set
+# CONFIG_FB_DDC is not set
+# CONFIG_FB_BOOT_VESA_SUPPORT is not set
+CONFIG_FB_CFB_FILLRECT=y
+CONFIG_FB_CFB_COPYAREA=y
+CONFIG_FB_CFB_IMAGEBLIT=y
+# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
+# CONFIG_FB_SYS_FILLRECT is not set
+# CONFIG_FB_SYS_COPYAREA is not set
+# CONFIG_FB_SYS_IMAGEBLIT is not set
+# CONFIG_FB_FOREIGN_ENDIAN is not set
+# CONFIG_FB_SYS_FOPS is not set
+# CONFIG_FB_SVGALIB is not set
+# CONFIG_FB_MACMODES is not set
+# CONFIG_FB_BACKLIGHT is not set
+# CONFIG_FB_MODE_HELPERS is not set
+# CONFIG_FB_TILEBLITTING is not set
+
+#
+# Frame buffer hardware drivers
+#
+# CONFIG_FB_UVESA is not set
+# CONFIG_FB_S1D13XXX is not set
+# CONFIG_FB_VIRTUAL is not set
+# CONFIG_FB_METRONOME is not set
+# CONFIG_FB_MB862XX is not set
+# CONFIG_FB_BROADSHEET is not set
+# CONFIG_FB_OMAP_BOOTLOADER_INIT is not set
+CONFIG_OMAP2_VRAM=y
+CONFIG_OMAP2_VRFB=y
+CONFIG_OMAP2_DSS=y
+CONFIG_OMAP2_VRAM_SIZE

[PATCH 4/5] ZOOM2: DSS2: zoom2 defconfig changes to enable dss2

[Y, Kishore]

>From 39c06b756d9683ae257ef1166dd8d593e6886709 Mon Sep 17 00:00:00 2001
From: Kishore 
Date: Tue, 10 Nov 2009 15:01:11 +0530
Subject: [PATCH] ZOOM2: DSS2: zoom2 defconfig changes to enable dss2

Defconfig has been changed to enable nec panel and dss2 on
zoom2 board.

Signed-off-by: Kishore Y 
---
 arch/arm/configs/omap_zoom2_defconfig |  161 -
 1 files changed, 159 insertions(+), 2 deletions(-)

diff --git a/arch/arm/configs/omap_zoom2_defconfig 
b/arch/arm/configs/omap_zoom2_defconfig
index 146304c..a66e1f3 100644
--- a/arch/arm/configs/omap_zoom2_defconfig
+++ b/arch/arm/configs/omap_zoom2_defconfig
@@ -210,6 +210,7 @@ CONFIG_OMAP_MUX_DEBUG=y
 CONFIG_OMAP_MUX_WARNINGS=y
 CONFIG_OMAP_MCBSP=y
 # CONFIG_OMAP_MBOX_FWK is not set
+CONFIG_OMAP_IOMMU=y
 # CONFIG_OMAP_MPU_TIMER is not set
 CONFIG_OMAP_32K_TIMER=y
 # CONFIG_OMAP3_DEBOBS is not set
@@ -982,14 +983,159 @@ CONFIG_REGULATOR_TWL4030=y
 # CONFIG_REGULATOR_LP3971 is not set
 # CONFIG_REGULATOR_TPS65023 is not set
 # CONFIG_REGULATOR_TPS6507X is not set
-# CONFIG_MEDIA_SUPPORT is not set
+CONFIG_MEDIA_SUPPORT=y
+
+#
+# Multimedia core support
+#
+CONFIG_VIDEO_DEV=y
+CONFIG_VIDEO_V4L2_COMMON=y
+# CONFIG_VIDEO_ALLOW_V4L1 is not set
+CONFIG_VIDEO_V4L1_COMPAT=y
+# CONFIG_DVB_CORE is not set
+CONFIG_VIDEO_MEDIA=y
+
+#
+# Multimedia drivers
+#
+# CONFIG_MEDIA_ATTACH is not set
+CONFIG_MEDIA_TUNER=y
+# CONFIG_MEDIA_TUNER_CUSTOMISE is not set
+CONFIG_MEDIA_TUNER_SIMPLE=y
+CONFIG_MEDIA_TUNER_TDA8290=y
+CONFIG_MEDIA_TUNER_TDA9887=y
+CONFIG_MEDIA_TUNER_TEA5761=y
+CONFIG_MEDIA_TUNER_TEA5767=y
+CONFIG_MEDIA_TUNER_MT20XX=y
+CONFIG_MEDIA_TUNER_XC2028=y
+CONFIG_MEDIA_TUNER_XC5000=y
+CONFIG_MEDIA_TUNER_MC44S803=y
+CONFIG_VIDEO_V4L2=y
+CONFIG_VIDEOBUF_GEN=y
+CONFIG_VIDEOBUF_DMA_SG=y
+CONFIG_VIDEO_CAPTURE_DRIVERS=y
+# CONFIG_VIDEO_ADV_DEBUG is not set
+# CONFIG_VIDEO_FIXED_MINOR_RANGES is not set
+CONFIG_VIDEO_HELPER_CHIPS_AUTO=y
+# CONFIG_VIDEO_VIVI is not set
+# CONFIG_VIDEO_SAA5246A is not set
+# CONFIG_VIDEO_SAA5249 is not set
+CONFIG_VIDEO_OMAP3=y
+CONFIG_VIDEO_OMAP3_OUT=y
+CONFIG_NTSC_M=y
+# CONFIG_PAL_BDGHI is not set
+# CONFIG_SOC_CAMERA is not set
+CONFIG_V4L_USB_DRIVERS=y
+# CONFIG_USB_VIDEO_CLASS is not set
+CONFIG_USB_VIDEO_CLASS_INPUT_EVDEV=y
+CONFIG_USB_GSPCA=m
+# CONFIG_USB_M5602 is not set
+# CONFIG_USB_STV06XX is not set
+# CONFIG_USB_GSPCA_CONEX is not set
+# CONFIG_USB_GSPCA_ETOMS is not set
+# CONFIG_USB_GSPCA_FINEPIX is not set
+# CONFIG_USB_GSPCA_MARS is not set
+# CONFIG_USB_GSPCA_MR97310A is not set
+# CONFIG_USB_GSPCA_OV519 is not set
+# CONFIG_USB_GSPCA_OV534 is not set
+# CONFIG_USB_GSPCA_PAC207 is not set
+# CONFIG_USB_GSPCA_PAC7311 is not set
+# CONFIG_USB_GSPCA_SN9C20X is not set
+# CONFIG_USB_GSPCA_SONIXB is not set
+# CONFIG_USB_GSPCA_SONIXJ is not set
+# CONFIG_USB_GSPCA_SPCA500 is not set
+# CONFIG_USB_GSPCA_SPCA501 is not set
+# CONFIG_USB_GSPCA_SPCA505 is not set
+# CONFIG_USB_GSPCA_SPCA506 is not set
+# CONFIG_USB_GSPCA_SPCA508 is not set
+# CONFIG_USB_GSPCA_SPCA561 is not set
+# CONFIG_USB_GSPCA_SQ905 is not set
+# CONFIG_USB_GSPCA_SQ905C is not set
+# CONFIG_USB_GSPCA_STK014 is not set
+# CONFIG_USB_GSPCA_SUNPLUS is not set
+# CONFIG_USB_GSPCA_T613 is not set
+# CONFIG_USB_GSPCA_TV8532 is not set
+# CONFIG_USB_GSPCA_VC032X is not set
+# CONFIG_USB_GSPCA_ZC3XX is not set
+# CONFIG_VIDEO_PVRUSB2 is not set
+# CONFIG_VIDEO_HDPVR is not set
+# CONFIG_VIDEO_EM28XX is not set
+# CONFIG_VIDEO_CX231XX is not set
+# CONFIG_VIDEO_USBVISION is not set
+# CONFIG_USB_ET61X251 is not set
+# CONFIG_USB_SN9C102 is not set
+# CONFIG_USB_ZC0301 is not set
+CONFIG_USB_PWC_INPUT_EVDEV=y
+# CONFIG_USB_ZR364XX is not set
+# CONFIG_USB_STKWEBCAM is not set
+# CONFIG_USB_S2255 is not set
+CONFIG_RADIO_ADAPTERS=y
+# CONFIG_USB_DSBR is not set
+# CONFIG_USB_SI470X is not set
+# CONFIG_USB_MR800 is not set
+# CONFIG_RADIO_TEA5764 is not set
+# CONFIG_DAB is not set
+
+
 
 #
 # Graphics support
 #
 # CONFIG_VGASTATE is not set
 CONFIG_VIDEO_OUTPUT_CONTROL=m
-# CONFIG_FB is not set
+CONFIG_FB=y
+# CONFIG_FIRMWARE_EDID is not set
+# CONFIG_FB_DDC is not set
+# CONFIG_FB_BOOT_VESA_SUPPORT is not set
+CONFIG_FB_CFB_FILLRECT=y
+CONFIG_FB_CFB_COPYAREA=y
+CONFIG_FB_CFB_IMAGEBLIT=y
+# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
+# CONFIG_FB_SYS_FILLRECT is not set
+# CONFIG_FB_SYS_COPYAREA is not set
+# CONFIG_FB_SYS_IMAGEBLIT is not set
+# CONFIG_FB_FOREIGN_ENDIAN is not set
+# CONFIG_FB_SYS_FOPS is not set
+# CONFIG_FB_SVGALIB is not set
+# CONFIG_FB_MACMODES is not set
+# CONFIG_FB_BACKLIGHT is not set
+# CONFIG_FB_MODE_HELPERS is not set
+# CONFIG_FB_TILEBLITTING is not set
+
+#
+# Frame buffer hardware drivers
+#
+# CONFIG_FB_UVESA is not set
+# CONFIG_FB_S1D13XXX is not set
+# CONFIG_FB_VIRTUAL is not set
+# CONFIG_FB_METRONOME is not set
+# CONFIG_FB_MB862XX is not set
+# CONFIG_FB_BROADSHEET is not set
+# CONFIG_FB_OMAP_BOOTLOADER_INIT is not set
+CONFIG_OMAP2_VRAM=y
+CONFIG_OMAP2_VRFB=y
+CONFIG_OMAP2_DSS=y
+CONFIG_OMAP2_VRAM_SIZE

[PATCH 3/5] ZOOM: DSS2: Mux changes to enable zoom display

[Y, Kishore]

>From d8dc84fb92a6083729599f1d45e467e66495fec7 Mon Sep 17 00:00:00 2001
From: Mukund Mittal 
Date: Tue, 10 Nov 2009 15:11:39 +0530
Subject: [PATCH] ZOOM: DSS2: Mux changes to enable zoom display

Changes made in mux files to enable display on zoom boards

Signed-off-by: Kishore Y 
---
 arch/arm/mach-omap2/mux.c |5 +
 arch/arm/plat-omap/include/plat/mux.h |3 +++
 2 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 714550f..86d6152 100755
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -549,6 +549,11 @@ MUX_CFG_34XX("AF13_3430_MMC3_DAT2", 0x5e8,
 MUX_CFG_34XX("AF13_3430_MMC3_DAT3", 0x5e2,
OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
 
+MUX_CFG_34XX("C25_34XX_GPIO96", 0x110,
+   OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT)
+MUX_CFG_34XX("T8_34XX_GPIO55", 0x0B6,
+   OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT)
+
 /* SYS_NIRQ T2 INT1 */
 MUX_CFG_34XX("AF26_34XX_SYS_NIRQ", 0x1E0,
OMAP3_WAKEUP_EN | OMAP34XX_PIN_INPUT_PULLUP |
diff --git a/arch/arm/plat-omap/include/plat/mux.h 
b/arch/arm/plat-omap/include/plat/mux.h
index 86d8cad..59149f1 100644
--- a/arch/arm/plat-omap/include/plat/mux.h
+++ b/arch/arm/plat-omap/include/plat/mux.h
@@ -839,6 +839,9 @@ enum omap34xx_index {
AF13_3430_MMC3_DAT2,
AF13_3430_MMC3_DAT3,
 
+   C25_34XX_GPIO96,
+   T8_34XX_GPIO55,
+
/* SYS_NIRQ T2 INT1 */
AF26_34XX_SYS_NIRQ,
 };
-- 
1.5.4.3


Regards,
Kishore Y
Ph:- +918039813085

--
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

[PATCH 2/5] ZOOM: DSS2: Add nec panel for zoom display

[Y, Kishore]

>From df64194feedc16c3f3f552dc26bc3050b7245005 Mon Sep 17 00:00:00 2001
From: Mukund Mittal 
Date: Fri, 20 Nov 2009 18:35:26 +0530
Subject: [PATCH] ZOOM: DSS2: Add nec panel for zoom display

Nec panel has been added which is used on both
zoom2 and zoom3 boards

Signed-off-by: Kishore Y 
---
 drivers/video/omap2/displays/panel-nec.c |  291 ++
 1 files changed, 291 insertions(+), 0 deletions(-)
 create mode 100644 drivers/video/omap2/displays/panel-nec.c

diff --git a/drivers/video/omap2/displays/panel-nec.c 
b/drivers/video/omap2/displays/panel-nec.c
new file mode 100644
index 000..c18f3ba
--- /dev/null
+++ b/drivers/video/omap2/displays/panel-nec.c
@@ -0,0 +1,291 @@
+/*
+ * NEC panel support
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ * Author: Tomi Valkeinen 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define LCD_XRES   800
+#define LCD_YRES   480
+
+#define LCD_PIXCLOCK_MIN   21800 /* NEC MIN PIX Clock is 21.8MHz */
+#define LCD_PIXCLOCK_TYP   23800 /* Typical PIX clock is 23.8MHz */
+#define LCD_PIXCLOCK_MAX   25700 /* Maximum is 25.7MHz */
+
+/* Current Pixel clock */
+#define LCD_PIXEL_CLOCKLCD_PIXCLOCK_MIN
+
+
+/*NEC NL8048HL11-01B  Manual
+ * defines HFB, HSW, HBP, VFP, VSW, VBP as shown below
+ */
+
+static struct omap_video_timings nec_panel_timings = {
+   /* 800 x 480 @ 60 Hz  Reduced blanking VESA CVT 0.31M3-R */
+   .x_res  = LCD_XRES,
+   .y_res  = LCD_YRES,
+   .pixel_clock= LCD_PIXEL_CLOCK,
+   .hfp= 6,
+   .hsw= 1,
+   .hbp= 4,
+   .vfp= 3,
+   .vsw= 1,
+   .vbp= 4,
+};
+
+static int nec_panel_probe(struct omap_dss_device *dssdev)
+{
+   dssdev->panel.config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_IVS |
+OMAP_DSS_LCD_IHS | OMAP_DSS_LCD_RF |
+OMAP_DSS_LCD_ONOFF;
+   dssdev->panel.timings = nec_panel_timings;
+   dssdev->panel.recommended_bpp = 16;
+
+   return 0;
+}
+
+static void nec_panel_remove(struct omap_dss_device *dssdev)
+{
+}
+
+static int nec_panel_enable(struct omap_dss_device *dssdev)
+{
+   int r = 0;
+
+   mdelay(4);
+   if (dssdev->platform_enable)
+   r = dssdev->platform_enable(dssdev);
+
+   return r;
+}
+
+static void nec_panel_disable(struct omap_dss_device *dssdev)
+{
+   if (dssdev->platform_disable)
+   dssdev->platform_disable(dssdev);
+   mdelay(4);
+}
+
+static int nec_panel_suspend(struct omap_dss_device *dssdev)
+{
+   nec_panel_disable(dssdev);
+   return 0;
+}
+
+static int nec_panel_resume(struct omap_dss_device *dssdev)
+{
+   return nec_panel_enable(dssdev);
+}
+
+static struct omap_dss_driver nec_driver = {
+   .probe  = nec_panel_probe,
+   .remove = nec_panel_remove,
+
+   .enable = nec_panel_enable,
+   .disable= nec_panel_disable,
+   .suspend= nec_panel_suspend,
+   .resume = nec_panel_resume,
+
+   .driver = {
+   .name   = "NEC_panel",
+   .owner  = THIS_MODULE,
+   },
+};
+
+static int
+spi_send(struct spi_device *spi, unsigned char reg_addr, unsigned char 
reg_data)
+{
+   int ret = 0;
+   unsigned int cmd = 0;
+   unsigned int data = 0;
+
+   cmd = 0x | reg_addr; /* register address write */
+   data = 0x0100 | reg_data ; /* register data write */
+   data = (cmd << 16) | data;
+   if (spi_write(spi, (unsigned char *)&data, 4))
+   printk(KERN_WARNING "error in spi_write %x\n", data);
+
+   udelay(10);
+   return ret;
+}
+
+
+static int init_nec_wvga_lcd(struct spi_device *spi)
+{
+   /* Initialization Sequence */
+   spi_send(spi, 3, 0x01);/* R3 = 01h */
+   spi_send(spi, 0, 0x00);/* R0 = 00h */
+   spi_send(spi, 1, 0x01);/* R1 = 0x01 (normal), 0x03 (reversed) */
+   spi_send(spi, 4, 0x00);/* R4 = 00h */
+   spi_send(spi, 5, 0x14);/* R5 = 14h */
+   spi_send(spi, 6, 0x24);/* R6 = 24h */
+   spi_send(spi, 16, 0xD7);   /* R16 = D7h */
+   spi_send(spi, 17, 0x00);   /* R17 = 00h */
+   spi_send(spi, 18, 

[PATCH 0/5] ZOOM: DSS2: Enable display on zoom2 and zoom3

[Y, Kishore]

Following patches enable Display support on zoom2 and zoom3. They have been 
tested on 2.6.32-rc5 kernel

Regards,
Kishore Y
Ph:- +918039813085

--
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

[PATCH 1/5] ZOOM: DSS2: changes in zoom board file for display support

[Y, Kishore]

>From e9394adabaa4418db50147cb464f314f396e0ec5 Mon Sep 17 00:00:00 2001
From: Mukund Mittal 
Date: Fri, 20 Nov 2009 18:14:30 +0530
Subject: [PATCH] ZOOM: DSS2: changes in zoom board file for display support

board-zoom-peripherals.c is common file for zoom boards to support
peripherals. Display support has been added here to enable display in
zoom2 and zoom3

Signed-off-by: Kishore Y 
---
 arch/arm/mach-omap2/board-zoom-peripherals.c |  212 +-
 1 files changed, 209 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c 
b/arch/arm/mach-omap2/board-zoom-peripherals.c
index 32adfea..a8628db 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -27,10 +27,166 @@
 #include 
 #include 
 
+#include 
+#include 
+#include 
 #include "mmc-twl4030.h"
 
 #define OMAP_SYNAPTICS_GPIO163
 
+#define LCD_PANEL_BACKLIGHT_GPIO(15 + OMAP_MAX_GPIO_LINES)
+#define LCD_PANEL_ENABLE_GPIO   (7 + OMAP_MAX_GPIO_LINES)
+
+#define LCD_PANEL_RESET_GPIO55
+#define LCD_PANEL_QVGA_GPIO 56
+
+#define TV_PANEL_ENABLE_GPIO95
+
+
+#define ENABLE_VAUX2_DEDICATED  0x09
+#define ENABLE_VAUX2_DEV_GRP0x20
+#define ENABLE_VAUX3_DEDICATED  0x03
+#define ENABLE_VAUX3_DEV_GRP0x20
+
+#define ENABLE_VPLL2_DEDICATED  0x05
+#define ENABLE_VPLL2_DEV_GRP0xE0
+#define TWL4030_VPLL2_DEV_GRP   0x33
+#define TWL4030_VPLL2_DEDICATED 0x36
+
+/*#define SIL9022_RESET_GPIO  97*/
+
+
+static void zoom_lcd_tv_panel_init(void)
+{
+   unsigned char lcd_panel_reset_gpio;
+
+   if (omap_rev() > OMAP3430_REV_ES3_0) {
+   /* Production Zoom Board:
+ *  * GPIO-96 is the LCD_RESET_GPIO
+ *  */
+   lcd_panel_reset_gpio = 96;
+   } else {
+   /* Pilot Zoom board
+ *  * GPIO-55 is the LCD_RESET_GPIO
+ *  */
+   lcd_panel_reset_gpio = 55;
+   }
+
+   gpio_request(lcd_panel_reset_gpio, "lcd reset");
+   gpio_request(LCD_PANEL_QVGA_GPIO, "lcd qvga");
+   gpio_request(LCD_PANEL_ENABLE_GPIO, "lcd panel");
+   gpio_request(LCD_PANEL_BACKLIGHT_GPIO, "lcd backlight");
+
+   gpio_request(TV_PANEL_ENABLE_GPIO, "tv panel");
+
+   gpio_direction_output(LCD_PANEL_QVGA_GPIO, 0);
+   gpio_direction_output(lcd_panel_reset_gpio, 0);
+   gpio_direction_output(LCD_PANEL_ENABLE_GPIO, 0);
+   gpio_direction_output(LCD_PANEL_BACKLIGHT_GPIO, 0);
+   gpio_direction_output(TV_PANEL_ENABLE_GPIO, 0);
+
+   gpio_direction_output(LCD_PANEL_QVGA_GPIO, 1);
+   gpio_direction_output(lcd_panel_reset_gpio, 1);
+}
+
+static int zoom_panel_power_enable(int enable)
+{
+   twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
+   (enable) ? ENABLE_VPLL2_DEDICATED : 0,
+   TWL4030_VPLL2_DEDICATED);
+   twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
+   (enable) ? ENABLE_VPLL2_DEV_GRP : 0,
+   TWL4030_VPLL2_DEV_GRP);
+   return 0;
+}
+
+static int zoom_panel_enable_lcd(struct omap_dss_device *dssdev)
+{
+   zoom_panel_power_enable(1);
+
+   gpio_request(LCD_PANEL_ENABLE_GPIO, "lcd panel");
+   gpio_direction_output(LCD_PANEL_ENABLE_GPIO, 1);
+   gpio_request(LCD_PANEL_BACKLIGHT_GPIO, "lcd backlight");
+   gpio_direction_output(LCD_PANEL_BACKLIGHT_GPIO, 1);
+
+   return 0;
+}
+
+static void zoom_panel_disable_lcd(struct omap_dss_device *dssdev)
+{
+   zoom_panel_power_enable(0);
+
+   gpio_request(LCD_PANEL_ENABLE_GPIO, "lcd panel");
+   gpio_direction_output(LCD_PANEL_ENABLE_GPIO, 0);
+   gpio_request(LCD_PANEL_BACKLIGHT_GPIO, "lcd backlight");
+   gpio_direction_output(LCD_PANEL_BACKLIGHT_GPIO, 0);
+
+}
+
+static struct omap_dss_device zoom_lcd_device = {
+   .name = "lcd",
+   .driver_name = "NEC_panel",
+   .type = OMAP_DISPLAY_TYPE_DPI,
+   .phy.dpi.data_lines = 24,
+   .platform_enable = zoom_panel_enable_lcd,
+   .platform_disable = zoom_panel_disable_lcd,
+ };
+
+static struct omap_dss_device *zoom_dss_devices[] = {
+   &zoom_lcd_device,
+/*&zoom_tv_device,
+ *#ifdef CONFIG_SIL9022
+ * &zoom_hdmi_device,
+ * #endif
+ * */
+};
+
+
+
+static struct omap_dss_board_info zoom_dss_data = {
+   .num_devices = ARRAY_SIZE(zoom_dss_devices),
+   .devices = zoom_dss_devices,
+   .default_device = &zoom_lcd_device,
+};
+
+static struct platform_device zoom_dss_device = {
+   .name  = "omapdss",
+   .id= -1,
+   .dev= {
+   .platform_data = &zoom_dss_data,
+   },
+};
+
+static struct regulator_consumer_supply zoom_vdda_dac_supply = {
+   .supply = "vdda_dac",
+   .dev 

Re: [alsa-devel] [PATCH 1/2] OMAP3: MCBSP: Suspend/resume failure fix

[Eero Nurkkala]

On Fri, 2009-11-20 at 14:53 +0100, ext Jarkko Nikula wrote:
> On Fri, 20 Nov 2009 09:51:13 +0200
> Peter Ujfalusi  wrote:
> 
> > > My question is: is sysfs the only way to choose threshold or can it be 
> > > made
> > >  as default? I could not see that happening in the code so thinking of the
> > >  possible reason of choosing not to do so. Because the user who wants to
> > >  hit suspend will not like to issue driver specific commands. Any specific
> > >  reason of not doing that by default?
> > 
> > It is not selected as default on OMAP3, since it is a new feature, and we 
> > don't 
> > want to change the behavior of the audio. If the reports are positive 
> > regarding 
> > to the threshold mode, than we can make it as default on OMAP3, at least 
> > that is 
> > the plan AFAIK. 
> 
> Yep. Currently we want to keep DMA behaviour consistent across the
> OMAPs and McBSP ports since the large internal FIFO is found only
> from McBSP2 on OMAP3.
> 
> This is good finding that you have found that it's the audio preventing
> the suspend and the threshold transfer mode can make it hit better.
> 
> But anyway, I'm afraid that threshold mode doesn't help to create
> robust suspend. Threshold allow the DMA and core to be mode in idle
> between the FIFO fills and probably that's why suspend might work
> during these idle periods. For robust implementation there must be
> explicit code stopping and resuming all activity gracefully so that it
> can hit the suspend also if the fill is happening or if using another
> transfer mode.
> 
> 

Looking at the very original patch, I don't know how things could get
into deep sleep by disabling the fclk only... need to disable the iclk
also. In threshold mode, HW autogates the iclk, so you may be just
"lucky".

One may want to be aware of this also:

http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commitdiff;h=72cc6d715d5b018e2cff4adb68966855850d4e77

I think it's an undocumented feature.

- Eero

--
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

Re: DSS2 DSI Sync

[Tomi Valkeinen]

On Fri, 2009-11-20 at 14:29 +0100, ext Steven Fischer wrote:
> 
> 
> On Fri, Nov 20, 2009 at 5:40 AM, Tomi Valkeinen
>  wrote:

> Just out of interest, may I ask why you are not using omapfb?
> Are you
> using V4L2 driver from TI?
> 
> 
> For the graphic plane, we don't use the "omapfb" code as an
> optimization.  We have a shorter path which is being used.  For the
> video planes, we have a V4L2 overlay driver we wrote.  It is based on
> the V4L2 driver from TI, but we found the TI driver had some gaps, so
> we wrote our own.

You can configure omapfb to use only one framebuffer. Was there some
spesific part in omapfb that was too slow? I'd be happy to get it
optimized.

> Given that the DSS2 exposes all three planes and knowing that there is
> at least two expected input paths, omapfb and the TI V4L2 driver, how
> is one expected to use the DSS2?  Are you suggesting that omapfb or
> V4L2 be used exclusively, not in combination?

No, I'm not suggesting that. This is a known problem, but it can't be
solved inside the kernel.

Optimally all the changes to overlays are done first, then one update is
issued. But if the overlays are handled by different entities, there's
no synchronization point and the entities compete about the display. And
the kernel driver cannot know what is going to happen next, so it cannot
wait for the next entity to issue update, before actually starting the
update.

I don't know how it should be handled with V4L2, but the same problem is
with omapfb. One entity is drawing to fb0, and some other entity draws
to fb1. The only solution I see is that there's one control point
between the kernel and the drawing-entities, and in our case this is X
server (I think). The X server has a better understanding of what is
going on, and can do updates better.

> So how double buffering is supposed to be done is:
> 
> 1) Fill frame A
> 2) Setup overlay for A
> 3) Wait until Frame B is done, with sync()
> 4) Start sending frame A, with update()
> 5) Fill frame B
> 6) Setup overlay for B
> 7) sync()
> 8) update()
> 9) Go back to 1
> 
> When you say "Setup overlay" I assume you mean both
> "overlay->set_overlay_info()" and "manager->apply()", correct?

Yes, I think apply is needed also.

> 
> We have been calling sync after calling update as a means of
> determining that the previous buffer is free.  In your example, sync
> is called, I assume, to ensure the previous update is complete before
> calling update again.  I need to consider this to see if this helps or
> hinders our cause.

If you call sync after update, you'll wait for that update to finish.
Which is not what you want. So yes, the idea is to start the update for
the front buffer, modify the back buffer, and when back buffer is ready,
use sync to make sure that the previous transfer has been finished.

 Tomi



--
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

Re: [alsa-devel] [PATCH 1/2] OMAP3: MCBSP: Suspend/resume failure fix

[Jarkko Nikula]

On Fri, 20 Nov 2009 09:51:13 +0200
Peter Ujfalusi  wrote:

> > My question is: is sysfs the only way to choose threshold or can it be made
> >  as default? I could not see that happening in the code so thinking of the
> >  possible reason of choosing not to do so. Because the user who wants to
> >  hit suspend will not like to issue driver specific commands. Any specific
> >  reason of not doing that by default?
> 
> It is not selected as default on OMAP3, since it is a new feature, and we 
> don't 
> want to change the behavior of the audio. If the reports are positive 
> regarding 
> to the threshold mode, than we can make it as default on OMAP3, at least that 
> is 
> the plan AFAIK. 

Yep. Currently we want to keep DMA behaviour consistent across the
OMAPs and McBSP ports since the large internal FIFO is found only
from McBSP2 on OMAP3.

This is good finding that you have found that it's the audio preventing
the suspend and the threshold transfer mode can make it hit better.

But anyway, I'm afraid that threshold mode doesn't help to create
robust suspend. Threshold allow the DMA and core to be mode in idle
between the FIFO fills and probably that's why suspend might work
during these idle periods. For robust implementation there must be
explicit code stopping and resuming all activity gracefully so that it
can hit the suspend also if the fill is happening or if using another
transfer mode.


-- 
Jarkko
--
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

RE: [PATCH 4/4] OMAP3: add support for 192Mhz sgx clock

[Sripathy, Vishwanath]

> -Original Message-
> From: Menon, Nishanth
> Sent: Wednesday, November 18, 2009 10:20 PM
> To: Sripathy, Vishwanath
> Cc: linux-omap
> Subject: Re: [PATCH 4/4] OMAP3: add support for 192Mhz sgx clock
> 
> Sripathy, Vishwanath had written, on 11/18/2009 08:16 AM, the following:
> > SGX can run at 192MHz on 3630 and this patch has changes to support this 
> > feature.
> >
> > Signed-off-by: Vishwanath BS 
> > ---
> >  arch/arm/mach-omap2/clock34xx.c   |   10 ++
> >  arch/arm/mach-omap2/clock34xx.h   |   33
> +
> >  arch/arm/mach-omap2/cm-regbits-34xx.h |2 ++
> >  3 files changed, 45 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-
> omap2/clock34xx.c
> > index 77b88aa..885043e 100755
> > --- a/arch/arm/mach-omap2/clock34xx.c
> > +++ b/arch/arm/mach-omap2/clock34xx.c
> > @@ -128,6 +128,7 @@ static struct omap_clk omap34xx_clks[] = {
> > CLK(NULL,   "emu_core_alwon_ck", &emu_core_alwon_ck, CK_3XXX),
> > CLK(NULL,   "dpll4_ck", &dpll4_ck,  CK_3XXX),
> > CLK(NULL,   "dpll4_x2_ck",  &dpll4_x2_ck,   CK_3XXX),
> > +   CLK(NULL,   "omap_192m_alwon_ck", &omap_192m_alwon_ck,
> CK_363X),
> > CLK(NULL,   "omap_96m_alwon_fck", &omap_96m_alwon_fck, CK_3XXX),
> > CLK(NULL,   "omap_96m_fck", &omap_96m_fck,  CK_3XXX),
> > CLK(NULL,   "cm_96m_fck",   &cm_96m_fck,CK_3XXX),
> > @@ -1224,6 +1225,15 @@ int __init omap2_clk_init(void)
> > dpll4_ck.dpll_data->sd_div_mask =
> OMAP3630_PERIPH_DPLL_SD_DIV_MASK;
> > dpll4_dd.mult_mask = OMAP3630_PERIPH_DPLL_MULT_MASK;
> > cpu_mask |= RATE_IN_363X;
> > +   cpu_clkflg |= CK_363X;
> > +   omap_96m_alwon_fck.parent = &omap_192m_alwon_ck;
> > +   omap_96m_alwon_fck.init = &omap2_init_clksel_parent;
> > +   omap_96m_alwon_fck.clksel_reg =
> > +   OMAP_CM_REGADDR(CORE_MOD, CM_CLKSEL),
> > +   omap_96m_alwon_fck.clksel_mask =
> > +   OMAP3630_CLKSEL_96M_MASK;
> > +   omap_96m_alwon_fck.clksel = omap_96m_alwon_fck_clksel;
> > +   omap_96m_alwon_fck.recalc = &omap2_clksel_recalc;
> 
> We should not ideally be linking this to j type DPLL perhaps? are'nt
> these 36xx series specific? do we need FEATURE_HAS_192Mhz_CLK? that way
> the future AM series/37xx series could also use this.

I will add FEATURE_HAS_192Mhz_CLK and put the code under this feature.
> 
> > }
> > }
> >
> > diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-
> omap2/clock34xx.h
> > index 93c92e5..6fe89df 100755
> > --- a/arch/arm/mach-omap2/clock34xx.h
> > +++ b/arch/arm/mach-omap2/clock34xx.h
> > @@ -654,12 +654,31 @@ static struct clk dpll4_m2x2_ck = {
> > .recalc = &omap3_clkoutx2_recalc,
> >  };
> >
> > +/* Adding 192MHz Clock node needed by SGX */
> > +static struct clk omap_192m_alwon_ck = {
> > +   .name   = "omap_192m_alwon_ck",
> > +   .ops= &clkops_null,
> > +   .parent = &dpll4_m2x2_ck,
> > +   .recalc = &followparent_recalc,
> > +};
> > +
> >  /*
> >   * DPLL4 generates DPLL4_M2X2_CLK which is then routed into the PRM as
> >   * PRM_96M_ALWON_(F)CLK.  Two clocks then emerge from the PRM:
> >   * 96M_ALWON_FCLK (called "omap_96m_alwon_fck" below) and
> >   * CM_96K_(F)CLK.
> >   */
> > +static const struct clksel_rate omap_96m_alwon_fck_rates[] = {
> > +   { .div = 1, .val = 1, .flags = RATE_IN_363X },
> > +   { .div = 2, .val = 2, .flags = RATE_IN_363X | DEFAULT_RATE },
> > +   { .div = 0 }
> > +};
> > +
> > +static const struct clksel omap_96m_alwon_fck_clksel[] = {
> > +   { .parent = &omap_192m_alwon_ck, .rates = omap_96m_alwon_fck_rates },
> > +   { .parent = NULL }
> > +};
> > +
> >  static struct clk omap_96m_alwon_fck = {
> > .name   = "omap_96m_alwon_fck",
> > .ops= &clkops_null,
> > @@ -1223,6 +1242,18 @@ static const struct clksel_rate sgx_core_rates[] = {
> > { .div = 3, .val = 0, .flags = RATE_IN_3XXX | DEFAULT_RATE },
> > { .div = 4, .val = 1, .flags = RATE_IN_3XXX },
> > { .div = 6, .val = 2, .flags = RATE_IN_3XXX },
> > +   { .div = 2, .val = 5, .flags = RATE_IN_363X },
> > +   { .div = 0 },
> > +};
> > +
> > +static const struct clksel_rate sgx_192m_rates[] = {
> > +   { .div = 1,  .val = 4, .flags = RATE_IN_363X | DEFAULT_RATE },
> > +   { .div = 0 },
> > +};
> > +
> > +static const struct clksel_rate sgx_corex2_rates[] = {
> > +   { .div = 3, .val = 6, .flags = RATE_IN_363X | DEFAULT_RATE },
> > +   { .div = 5, .val = 7, .flags = RATE_IN_363X },
> > { .div = 0 },
> >  };
> >
> > @@ -1234,6 +1265,8 @@ static const struct clksel_rate sgx_96m_rates[] = {
> >  static const struct clksel sgx_clksel[] = {
> > { .parent = &core_ck,.rates = sgx_core_rates },

Re: [PATCHv3 0/3] OMAP UART: Adding support for omap-serial driver.

[Govindraj]

I have not seen any comments on this patch series yet.

Tony,
Is there something I need to modify?

Or it can be unstreamed now?

---
Regards,
Govindraj.R


On Fri, Nov 13, 2009 at 12:23 PM, Govindraj.R  wrote:
>
> From 8dae69c5e17421123b88414021289974e968fd02 Mon Sep 17 00:00:00 2001
> From: Govindraj R 
> Date: Fri, 13 Nov 2009 12:09:38 +0530
> Subject: [PATCH] OMAP UART: Adding support for omap-serial driver.
>
> The Following series of patch adds support for OMAP3430-HIGH SPEED UART 
> Controller.
>
> Govindraj R (3):
>  OMAP UART: Add omap-serial driver support.
>  OMAP UART: Add platform data for omap-serial driver.
>  OMAP UART: Add omap-serial driver support in omap_3430sdp_defconfig
>
>  arch/arm/configs/omap_3430sdp_defconfig       |    1 +
>  arch/arm/mach-omap2/serial.c                  |  335 +--
>  arch/arm/plat-omap/include/plat/omap-serial.h |  115 +++
>  drivers/serial/Kconfig                        |   23 +
>  drivers/serial/Makefile                       |    1 +
>  drivers/serial/omap-serial.c                  | 1330 
> +
>  include/linux/serial_core.h                   |    3 +
>  7 files changed, 1714 insertions(+), 94 deletions(-)
>  create mode 100644 arch/arm/plat-omap/include/plat/omap-serial.h
>  create mode 100644 drivers/serial/omap-serial.c
>
>
> --
> 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 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

Re: linux-next: manual merge of the input tree with the omap tree

[Dmitry Torokhov]

On Wed, Nov 18, 2009 at 06:53:30PM -0800, Tony Lindgren wrote:
> 
> Dmitry, could you please drop 5018461a887d58f4601207deeebb7c352c2da20a from
> your tree now?
> 

Done.

-- 
Dmitry
--
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

Re: [PATCH] USB: twl4030: Enable USB regulators before enabling USB charging

[Felipe Balbi]

On Thu, Nov 19, 2009 at 07:34:55PM +0100, ext Aguilar Pena, Leed wrote:

For TWL family of power management ICs, USB charging works only
when USB regulators are in enabled state: 3v1, 1v5, 1v8

On a USB cable attach, twl4030_phy_resume(twl) function enables
the regulators. Enable USB charging, only after all regulators
are enabled.

Its observed that enabling USB charging before regulators are
enabled, causes USB charging to fail.

Tested on: Zoom2: omap3430: ES3.1 + TWL5030
Needs T2-MADC and T2-BCI drivers which are still not upstreamed.

Signed-off-by: Moiz Sonasath 
Signed-off-by: Leed Aguilar 
Acked-by: Vikram Pandita 
Acked-by: Anand Gadiyar 
Acked-by: Nishanth Menon 


Acked-by: Felipe Balbi 

this should go to linux-usb, please Cc Greg KH and David Brownell.

--
balbi
--
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

RE: [PATCH V4 3/3] OMAP: I2C: Add mpu wake up latency constraint in i2c

[kalle.jokiniemi]

Kevin,

Could you please take this patch in? Currently i2c is not working very well 
with cpuidle and off mode, and the patch is needed.

I would go with V4 of the patch.

- Kalle

>-Original Message-
>From: linux-omap-ow...@vger.kernel.org 
>[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of ext 
>Kalle Jokiniemi
>Sent: 29. lokakuuta 2009 10:55
>To: Sonasath, Moiz
>Cc: khil...@deeprootsystems.com; linux-omap@vger.kernel.org
>Subject: RE: [PATCH V4 3/3] OMAP: I2C: Add mpu wake up latency 
>constraint in i2c
>
>OK, let's try this once more, since my mail did not seem to go 
>to linux-omap.
>
>Sorry for the spam.
>
>See my comments below:
>
>On Fri, 2009-10-23 at 18:53 +0300, Sonasath, Moiz wrote:
>> Hello Jokiniemi!
>> 
>> > -Original Message-
>> > From: Kalle Jokiniemi [mailto:kalle.jokini...@digia.com]
>> > Sent: Wednesday, October 21, 2009 6:51 AM
>> > To: khil...@deeprootsystems.com
>> > Cc: linux-omap@vger.kernel.org; Kalle Jokiniemi; Sonasath, Moiz;
>> Jarkko
>> > Nikula; Paul Walmsley; Menon, Nishanth
>> > Subject: [PATCH V4 3/3] OMAP: I2C: Add mpu wake up latency
>> constraint in
>> > i2c
>> > 
>> > While waiting for completion of the i2c transfer, the MPU 
>could hit 
>> > OFF mode and cause several msecs of delay that made i2c transfers 
>> > fail more often. The extra delays and subsequent re-trys cause i2c 
>> > clocks to be active more often. This has also an negative 
>effect on 
>> > power consumption.
>> > 
>> > Created a mechanism for passing and using the constraint setting 
>> > function in driver code. The used mpu wake up latency constraints 
>> > are now set individually per bus, and they are calculated based on 
>> > clock rate and fifo size.
>> > 
>> > Thanks to Jarkko Nikula, Moiz Sonasath, Paul Walmsley, and 
>Nishanth 
>> > Menon for tuning out the details of this patch.
>> > 
>> > Cc: Moiz Sonasath 
>> > Cc: Jarkko Nikula 
>> > Cc: Paul Walmsley 
>> > Cc: Nishanth Menon 
>> > Signed-off-by: Kalle Jokiniemi 
>> > ---
>> > 
>> 
>> 
>> >dev->speed = speed;
>> >dev->idle = 1;
>> > @@ -911,6 +923,11 @@ omap_i2c_probe(struct platform_device *pdev)
>> > */
>> >dev->fifo_size = (dev->fifo_size / 2);
>> >dev->b_hw = 1; /* Enable hardware fixes */
>> > +
>> > +  /* calculate wakeup latency constraint for MPU */
>> > +  if (dev->set_mpu_wkup_lat != NULL)
>> > +  dev->latency = (100 * dev->fifo_size) /
>> > + (1000 * speed / 8);
>> >}
>> 
>> IMHO, here instead of using 'dev->fifo_size' for calculating the 
>> 'dev->latency', we need to use:
>> 
>> 1. For RX case, to avoid Reciver overrun:
>>  if (msg->flags & I2C_M_RD)
>>  Use [(FIFO Depth)bytes - (FIFO THRSH)bytes] in 
>calculating 
>>  dev->latency
>> 
>> Because conceptually, RDR/RRDY interrupts are generated when 
>RTRSH is 
>> reached, so we want the MPU to be wake up within the time it 
>takes to 
>> fill the FIFO from RTRSH to FIFO Depth (FIFO full).
>> 
>> 2. For TX case, to avoid Transmitter Underflow:
>>  if (!(msg->flags & I2C_M_RD))
>>  Use (FIFO THRSH)bytes in calculating dev->latency
>> 
>> Because conceptually, XDR/XRDY interrupts are generated when 
>XTRSH is 
>> reached, so we want the MPU to be wake up within the time it 
>takes to 
>> drain the FIFO from XTRSH to Zero (FIFO empty).
>> 
>> Using, dev->fifo_size instead, works in the present code because we 
>> have a RTRSH/XTRSH = dev->fifo_size/2 = 4 bytes And therefore, (FIFO 
>> Depth)bytes - (FIFO THRSH)bytes = 8 - 4 = 4 bytes
>> 
>> But, to make it more generic in future and to make it independent of 
>> any changes in the RTRSH/XTRSH values or FIFO depths in future, we 
>> should use a generic code here.
>
>Well, I don't completely agree with the necessity of preparing 
>for different rx/tx thresholds. For this to make sense, the 
>i2c-omap driver should first separate in it's code the use of 
>rx and tx thresholds. If someone is planning to do that, 
>he/she should anyway update the usage of fifo_size throughout 
>the code, including the wake up latency setting.
>
>Anyways, attached a patch that separates the mpu wake up 
>latencies for rx and tx. In case that is needed. Though I'm 
>not for it, since it adds unneeded complexity.
>
>- Kalle
>
>> 
>> > 
>> >/* reset ASAP, clearing any IRQs */ diff --git 
>> > a/include/linux/i2c-omap.h b/include/linux/i2c-omap.h new 
>file mode 
>> > 100644 index 000..1362fba
>> > --- /dev/null
>> > +++ b/include/linux/i2c-omap.h
>> > @@ -0,0 +1,9 @@
>> > +#ifndef __I2C_OMAP_H__
>> > +#define __I2C_OMAP_H__
>> > +
>> > +struct omap_i2c_bus_platform_data {
>> > +  u32 clkrate;
>> > +  void(*set_mpu_wkup_lat)(struct device *dev, 
>int set);
>> > +};
>> > +
>> > +#endif
>> > --
>> > 1.5.4.3
>> 
>> Regards
>> Moiz Sonasath
>> 
>--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to maj