Re: [PATCH 06/10 V3] omap3: pm: use opp accessor functions for omap-target
Hello Nishanth,
Little style comment.
On Wed, Nov 25, 2009 at 06:56:08PM +0100, ext Kevin Hilman wrote:
Nishanth Menon n...@ti.com writes:
The logic in omap-target can now be improved with the accessor
functions. Dont scan through the list manually, instead use
get_next_freq to do the scanning.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Madhusudhan Chikkature Rajashekar madhu...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Romit Dasgupta ro...@ti.com
Cc: Sanjeev Premi pr...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Sergio Alberto Aguirre Rodriguez saagui...@ti.com
Cc: Thara Gopinath th...@ti.com
Cc: Vishwanath Sripathy vishwanath...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/plat-omap/cpu-omap.c | 19 +++
1 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/arch/arm/plat-omap/cpu-omap.c b/arch/arm/plat-omap/cpu-omap.c
index 449b6b6..7b3ca11 100644
--- a/arch/arm/plat-omap/cpu-omap.c
+++ b/arch/arm/plat-omap/cpu-omap.c
@@ -111,14 +111,17 @@ static int omap_target(struct cpufreq_policy *policy,
cpufreq_notify_transition(freqs, CPUFREQ_POSTCHANGE);
#elif defined(CONFIG_ARCH_OMAP3) !defined(CONFIG_OMAP_PM_NONE)
if (mpu_opps) {
- int ind;
- for (ind = 1; ind = MAX_VDD1_OPP; ind++) {
- if (mpu_opps[ind].rate/1000 = target_freq) {
- omap_pm_cpu_set_freq
- (mpu_opps[ind].rate);
- break;
- }
- }
+ unsigned long freq = target_freq * 1000;
+ struct omap_opp *opp = NULL;
+ int res;
Not mandatory, but add a blank line to separate declaration from rest of the
code.
+ /* see if we have exact freq match */
+ res = opp_is_valid(opp, mpu_opps, freq);
+ /* Get next best if we cant find a exact match */
+ if (res)
+ res = opp_get_higher_opp(opp, freq, mpu_opps);
These two could just be replaced by a single call to
opp_find_freq_rounding()
Indeed, I also agree here that having a find_rounded as a search option
would make sense.
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
--
Eduardo Valentin
--
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 03/10 V3] omap3: pm: use opp accessor functions for omap34xx
Hello Nishanth,
Same comments from patch 09/10 applies here. Copying those to make like easier:
On Wed, Nov 25, 2009 at 05:09:12AM +0100, ext Nishanth Menon wrote:
Move the definitions from omap3-opp.h to pm34xx.c. The definitions
are now based on omap_opp_def instead of omap_opp itself.
Since the opp.h has the omap_opp definition, omap-pm.h conflicts and
has been removed in favor of opp.h.
omap3_pm_init_opp_table is used to initialize the OPP table and
relevant board files which have omap2_init_common_hw called with opp
arrays have been updated with omap3_pm_init_opp_table.
This change now allows us to dynamically register OPPs to the system
based on silicon type we detect.
NOTE: This introduces the following warnings highlighting areas we
need to cleanup:
arch/arm/mach-omap2/smartreflex.c: In function 'get_opp':
arch/arm/mach-omap2/smartreflex.c:161: warning: 'opp_id' is deprecated
(declared at arch/arm/plat-omap/include/plat/opp.h:33)
arch/arm/mach-omap2/smartreflex.c:164: warning: 'opp_id' is deprecated
(declared at arch/arm/plat-omap/include/plat/opp.h:33)
arch/arm/mach-omap2/smartreflex.c:166: warning: 'opp_id' is deprecated
(declared at arch/arm/plat-omap/include/plat/opp.h:33)
arch/arm/mach-omap2/smartreflex.c:168: warning: 'opp_id' is deprecated
(declared at arch/arm/plat-omap/include/plat/opp.h:33)
arch/arm/mach-omap2/resource34xx.c: In function 'get_opp':
arch/arm/mach-omap2/resource34xx.c:165: warning: 'opp_id' is deprecated
(declared at arch/arm/plat-omap/include/plat/opp.h:33)
arch/arm/mach-omap2/resource34xx.c:168: warning: 'opp_id' is deprecated
(declared at arch/arm/plat-omap/include/plat/opp.h:33)
arch/arm/mach-omap2/resource34xx.c:170: warning: 'opp_id' is deprecated
(declared at arch/arm/plat-omap/include/plat/opp.h:33)
arch/arm/mach-omap2/resource34xx.c:172: warning: 'opp_id' is deprecated
(declared at arch/arm/plat-omap/include/plat/opp.h:33)
arch/arm/mach-omap2/resource34xx.c: In function 'program_opp':
arch/arm/mach-omap2/resource34xx.c:284: warning: 'opp_id' is deprecated
(declared at arch/arm/plat-omap/include/plat/opp.h:33)
arch/arm/mach-omap2/resource34xx.c:285: warning: 'opp_id' is deprecated
(declared at arch/arm/plat-omap/include/plat/opp.h:33)
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c |1 +
arch/arm/mach-omap2/board-omap3beagle.c |1 +
arch/arm/mach-omap2/board-omap3evm.c |1 +
arch/arm/mach-omap2/board-rx51.c |1 +
arch/arm/mach-omap2/board-zoom2.c |2 +
arch/arm/mach-omap2/omap3-opp.h | 58 +---
arch/arm/mach-omap2/pm.h |6 +++
arch/arm/mach-omap2/pm34xx.c | 68
+
arch/arm/plat-omap/include/plat/omap-pm.h | 17 +---
9 files changed, 84 insertions(+), 71 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index eac529f..0ec8327 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -220,6 +220,7 @@ static void __init omap_3430sdp_init_irq(void)
{
omap_board_config = sdp3430_config;
omap_board_config_size = ARRAY_SIZE(sdp3430_config);
+ omap3_pm_init_opp_table();
omap3_pm_init_vc(omap3_setuptime_table);
omap3_pm_init_cpuidle(omap3_cpuidle_params_table);
omap2_init_common_hw(hyb18m512160af6_sdrc_params, NULL,
omap3_mpu_rate_table,
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 2ec3520..a937238 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -361,6 +361,7 @@ static void __init omap3_beagle_init_irq(void)
{
omap_board_config = omap3_beagle_config;
omap_board_config_size = ARRAY_SIZE(omap3_beagle_config);
+ omap3_pm_init_opp_table();
omap2_init_common_hw(mt46h32m32lf6_sdrc_params,
mt46h32m32lf6_sdrc_params, omap3_mpu_rate_table,
omap3_dsp_rate_table, omap3_l3_rate_table);
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 8130eca..44a5861 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -404,6 +404,7 @@ static void __init omap3_evm_init_irq(void)
{
omap_board_config = omap3_evm_config;
omap_board_config_size = ARRAY_SIZE(omap3_evm_config);
+ omap3_pm_init_opp_table();
omap2_init_common_hw(mt46h32m32lf6_sdrc_params, NULL,
omap3_mpu_rate_table,
omap3_dsp_rate_table, omap3_l3_rate_table);
omap_init_irq();
diff --git a/arch/arm/mach-omap2/board-rx51.c
b/arch/arm/mach-omap2/board-rx51.c
index 2f1c2be..997fd1c 100644
--- a/arch/arm/mach-omap2/board-rx51.c
+++ b/arch/arm/mach-omap2/board-rx51.c
Re: [PATCH 02/10 V3] omap3: pm: introduce opp accessor functions
Hello Nishanth and Kevin, On Thu, Nov 26, 2009 at 01:22:49AM +0100, ext Nishanth Menon wrote: Kevin Hilman had written, on 11/25/2009 05:46 PM, the following: [...] something like this instead: /** * opp_find_freq() * @oppl:OPP list * @freq:Frequency to look for in OPP table * * Look for an enabled OPP with a frequency value matching @freq. * * Returns pointer to OPP entry if match is found, or NULL if no match * found. */ struct omap_opp *opp_find_freq(const struct omap_opp *oppl, u32 freq); I did think about it(single function doing multiple things), the intention is as follows in reality: opp_is_valid : Search only for enabled frequencies opp_has_freq : Searches for enabled/disabled frequencies This is useful for some logic which wants to enable a frequency which may have been disabled in the table. now, to retain that functionality, A) /** * opp_find_freq() - Find a opp corresponding to frequency * @oppl: opp list to search * @freq: frequency to loopup in OPP table * @enabled:search only enabled frequencies * * return opp handle corresponding to the frequency found, else * return NULL. Search for enabled frequencies if enabled flag * is true, else search for disabled frequencies also */ struct omap_opp *opp_find_freq(const struct omap_opp *oppl, unsigned long freq, bool enabled); This will handle the functionalities that are supported in rev 3. B) I rename existing functions: opp_has_freq == opp_is_disabled() opp_is_valid == opp_is_enabled() I would still prefer to go with explicit function search APIs.. I like (A) here. Ack. I can see it useful if we go to a list iterator at a later point of time. [...] /** * opp_find_freq_rounded() * @oppl:OPP list * @freq:Frequency to look for in OPP table * @rounding:Rounding option: NONE, UP, DOWN * * Look for an OPP with a frequency value matching @freq. If * @rounding != ROUND_NONE, find closest match using rounding. * * Can be used to find exact OPP, or match using given rounding: * @rounding == UP: find next highest frequency * @rounding == DOWN:find next lowest frequency * @rounding == CLOSEST: find closest frequency * * Returns pointer to OPP entry if match is found, or NULL if no match * found (only possible when no rounding is used) */ struct omap_opp *opp_find_freq_rounded(struct omap_opp *oppl, u32 freq, u32 rounding); Looking at the users of the 'higher' and 'lower' OPPs in the current code, I see that SRF tries to use all three one after the other. First it checks for exact match, then for higher, then for lower. This could be replaced simply by doing a 'closest' match. hmmm.. I think we are going a full circle here. /* Search exact frequency */ #define OPP_ROUND_NONE (0 0) /* Search approx frequency */ #define OPP_ROUND_CLOSEST (1 0) /* Search up */ #define OPP_ROUND_HIGH (0 1) /* Search down */ #define OPP_ROUND_LOW(1 1) struct omap_opp *opp_find_freq_rounded(struct omap_opp *oppl, unsigned long freq, u8 rounding_flag); Note: the only difference b/w this and opp_find_freq is that opp_find_freq will also search for enabled/disabled. If I add that here, this is exactly the #1 implementation I did in http://marc.info/?l=linux-omapm=125800489123496w=2 ok, I used bool instead of a #define and added the complexity of using enabled flag also: bool search_higher, bool search_enabled_only, bool exact_search what you are proposing is that I go back to my implementation #1 and remove my bools instead by adding #defines: /* Search up */ #define OPP_ROUND_ENABLED (0 2) /* Search down */ #define OPP_ROUND_ANY(1 2) would even make the find_freq redundant.. Now, in your comment in http://marc.info/?l=linux-omapm=125816031406704w=2 quote:I think all the options to this function make it not terribly readable. Does it become any different now? Yeah, I still think multiple bools to a function is a readability problem. Every time you look at a call, you have to look at the prototype to remember what all the options are. A single bool or flag is better IMHO. without taking this in, exact searches can be done by specific functions and approximate searches by another function.. we go generic functions or we go specific functions.. generic comments I have been getting is to go specific, hence the v2 and v3 series. OK, you're right. I am causing us to go around in circles now, but we're going around in increasingly smaller circles and hopefully converging on the target. ;) Yep :) So what I propose is having two functions. One for exact matches (your proposal A above) and one for approximate matches which is something like my find_freq_rounded(), but
Re: [PATCH 0/2] [RESEND] Amstrad Delta: add support for LCD contrast
On Mon, 2009-12-07 at 22:32 +0100, ext Tony Lindgren wrote: * Janusz Krzysztofik jkrzy...@tis.icnet.pl [091205 05:54]: Monday 23 November 2009 18:57:51 Janusz Krzysztofik napisał(a): Initialy submitted on 2009-11-16 (http://www.spinics.net/lists/linux-omap/msg20629.html). Resendig due to fbdev mailing list address changed. The series consists of 2 patches: [PATCH 1/2] omapfb: lcd_ams_delta: add support for contrast control [PATCH 2/2] OMAP: ams_delta_defconfig: enable LCD class device support It is intended for 2.6.33, if it's not too late. Hi, Now that Tony has changed the series status from New to Awaiting Upstream in his patchwork queue[1][2], chances of getting it in throungh linux-omap tree, like a few other omapfb related patches managed to do lately, seem falling down drastically to me if still not answered by anyone involved in omapfb development. Imre, Could you please take the patches, or give your ack for Tony to take them, or just point me on the right way to the get them integrated or NAKed, if none of the former is? Tomi, I am not sure if you are the right person for bothering here, but maybe you could give your comments that would help pushing it forward? I'd prefer Tomi to merge all the drivers/video/omap code rather than merge it via linux-omap tree. Ideally with an ack from Imre where possible. And I, on the other hand, would like to keep away from the old omapfb driver =). Imre, do you still want to be the maintainer of the old omapfb, or how should we handle it? I didn't have any plans to maintain it, but then again, perhaps it wouldn't be too much of a burden to have the (hopefully) few patches for old omapfb in the DSS2 tree. 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: [PATCH] omap3: cm-t35: add mux initialization
Tony Lindgren wrote:
* Gadiyar, Anand gadi...@ti.com [091207 08:35]:
Tony Lindgren wrote:
* Mike Rapoport m...@compulab.co.il [091206 07:30]:
Tony,
Any chance this can go to 2.6.33?
Sure, I was just waiting to hear back if the OUTPUT_PULLUP is
needed for sure? Or is just OUTPUT enough for musb to work?
Tony
OUTPUT should work too. The ULPI spec recommends a weak pull-up
on STP line, but we needn't really have that. Plain OUTPUT is sufficient.
OK, thanks for checking that. Mike, what do you prefer to do?
I'll test without the pull and if it's Ok this way I'll update the mux
initialization patch and drop the OUTPUT_PULL{UP,DOWN}.
I guess in some cases the pull may be needed for a pin
to change faster if an external pull is not used?
We could add the OUTPUT_PULL defines, but we should probably
mark them with comments that they should be rarely needed.
Regards,
Tony
--
Sincerely yours,
Mike.
--
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 09/10 V3] omap3: pm: introduce 3630 opps
Hi,
thanks for your comments. few thoughts below.
Eduardo Valentin said the following on 12/08/2009 01:49 AM:
Hello Nishanth,
Few comments bellow.
On Wed, Nov 25, 2009 at 05:09:18AM +0100, ext Nishanth Menon wrote:
Introduce the OMAP3630 OPPs including the defined OPP tuples.
Further information on OMAP3630 can be found here:
http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateId=6123navigationId=12836contentId=52606
OMAP36xx family introduces:
VDD1 with 4 OPPs, of which OPP3 4 are available only on devices yet
to be introduced in 36xx family. Meanwhile, VDD2 has 2 opps.
Device Support of OPPs-
|-3630-600-| (default)
|- 3630-800-| (device: TBD)
|- 3630-1000-| (device: TBD)
H/w OPP- OPP50 OPP100 OPP-Turbo OPP1G-SB
VDD1 OPP1 OPP2 OPP3OPP4
VDD2 OPP1 OPP2 OPP2OPP2
Note:
a) TI h/w naming for OPPs are now standardized in terms of OPP50, 100,
Turbo and SB. This maps as shown above to the opp IDs (s/w term).
b) For boards which need custom VDD1/2 OPPs, the opp table can be
updated by the board file on a need basis after the
omap3_pm_init_opp_table call. The OPPs introduced here are the
official OPP table at this point in time.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Madhusudhan Chikkature Rajashekar madhu...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Romit Dasgupta ro...@ti.com
Cc: Sanjeev Premi pr...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Sergio Alberto Aguirre Rodriguez saagui...@ti.com
Cc: Thara Gopinath th...@ti.com
Cc: Vishwanath Sripathy vishwanath...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/pm34xx.c | 49
-
1 files changed, 47 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index ad21f5f..05ecf02 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -143,6 +143,41 @@ static struct omap_opp_def __initdata
omap34xx_dsp_rate_table[] = {
{.enabled = 0, .freq = 0, .u_volt = 0}
};
+static struct omap_opp_def __initdata omap36xx_mpu_rate_table[] = {
+/*OPP1 - OPP50*/
+{.enabled = true, .freq = 3, .u_volt = 93},
+/*OPP2 - OPP100*/
+{.enabled = true, .freq = 6, .u_volt = 110},
+/*OPP3 - OPP-Turbo*/
+{.enabled = false, .freq = 8, .u_volt = 126},
+/*OPP4 - OPP-SB*/
+{.enabled = false, .freq = 10, .u_volt = 131},
+/* Terminator */
+{.enabled = 0, .freq = 0, .u_volt = 0}
+};
+
+static struct omap_opp_def __initdata omap36xx_l3_rate_table[] = {
+/*OPP1 - OPP50 */
+{.enabled = true, .freq = 1, .u_volt = 93},
+/*OPP2 - OPP100, OPP-Turbo, OPP-SB*/
+{.enabled = true, .freq = 2, .u_volt = 1137500},
+/* Terminator */
+{.enabled = 0, .freq = 0, .u_volt = 0}
+};
+
+static struct omap_opp_def __initdata omap36xx_dsp_rate_table[] = {
+/*OPP1 - OPP50*/
+{.enabled = true, .freq = 26000, .u_volt = 93},
+/*OPP2 - OPP100*/
+{.enabled = true, .freq = 52000, .u_volt = 110},
+/*OPP3 - OPP-Turbo*/
+{.enabled = false, .freq = 66000, .u_volt = 126},
+/*OPP4 - OPP-SB*/
+{.enabled = false, .freq = 87500, .u_volt = 131},
+/* Terminator */
+{.enabled = 0, .freq = 0, .u_volt = 0}
+};
+
Although it is not mandatory, I'd say this way of initializing structure
array is more common:
static struct omap_opp_def __initdata omap36xx_dsp_rate_table[] = {
/*OPP1 - OPP50*/
{
.enabled= true,
.freq = 26000,
.u_volt = 93,
},
/*OPP2 - OPP100*/
{
.enabled= true,
.freq = 52000,
.u_volt = 110,
},
/*OPP3 - OPP-Turbo*/
{
.enabled= false,
.freq = 66000,
.u_volt = 126,
},
/*OPP4 - OPP-SB*/
{
.enabled= false,
.freq = 87500,
.u_volt = 131,
},
/* Terminator */
{
.enabled= 0,
.freq = 0,
.u_volt = 0,
}
};
and if you thing it is line consuming, you can always define a INIT macro:
#define OMAP_OPP_DEF(_enabled, _freq, _uv) \
{ \
.enabled= _enabled, \
.freq = _freq,\
.u_volt = _uv, \
}
and use it to initialize your array:
/*OPP1 - OPP50*/
static struct
Re: [PATCH 02/10 V3] omap3: pm: introduce opp accessor functions
Eduardo Valentin said the following on 12/08/2009 02:23 AM: Hello Nishanth and Kevin, On Thu, Nov 26, 2009 at 01:22:49AM +0100, ext Nishanth Menon wrote: Kevin Hilman had written, on 11/25/2009 05:46 PM, the following: [...] something like this instead: /** * opp_find_freq() * @oppl:OPP list * @freq:Frequency to look for in OPP table * * Look for an enabled OPP with a frequency value matching @freq. * * Returns pointer to OPP entry if match is found, or NULL if no match * found. */ struct omap_opp *opp_find_freq(const struct omap_opp *oppl, u32 freq); I did think about it(single function doing multiple things), the intention is as follows in reality: opp_is_valid : Search only for enabled frequencies opp_has_freq : Searches for enabled/disabled frequencies This is useful for some logic which wants to enable a frequency which may have been disabled in the table. now, to retain that functionality, A) /** * opp_find_freq() - Find a opp corresponding to frequency * @oppl: opp list to search * @freq: frequency to loopup in OPP table * @enabled:search only enabled frequencies * * return opp handle corresponding to the frequency found, else * return NULL. Search for enabled frequencies if enabled flag * is true, else search for disabled frequencies also */ struct omap_opp *opp_find_freq(const struct omap_opp *oppl, unsigned long freq, bool enabled); This will handle the functionalities that are supported in rev 3. B) I rename existing functions: opp_has_freq == opp_is_disabled() opp_is_valid == opp_is_enabled() I would still prefer to go with explicit function search APIs.. I like (A) here. Ack. I can see it useful if we go to a list iterator at a later point of time. [...] /** * opp_find_freq_rounded() * @oppl:OPP list * @freq:Frequency to look for in OPP table * @rounding:Rounding option: NONE, UP, DOWN * * Look for an OPP with a frequency value matching @freq. If * @rounding != ROUND_NONE, find closest match using rounding. * * Can be used to find exact OPP, or match using given rounding: * @rounding == UP: find next highest frequency * @rounding == DOWN:find next lowest frequency * @rounding == CLOSEST: find closest frequency * * Returns pointer to OPP entry if match is found, or NULL if no match * found (only possible when no rounding is used) */ struct omap_opp *opp_find_freq_rounded(struct omap_opp *oppl, u32 freq, u32 rounding); Looking at the users of the 'higher' and 'lower' OPPs in the current code, I see that SRF tries to use all three one after the other. First it checks for exact match, then for higher, then for lower. This could be replaced simply by doing a 'closest' match. hmmm.. I think we are going a full circle here. /* Search exact frequency */ #define OPP_ROUND_NONE (0 0) /* Search approx frequency */ #define OPP_ROUND_CLOSEST (1 0) /* Search up */ #define OPP_ROUND_HIGH (0 1) /* Search down */ #define OPP_ROUND_LOW(1 1) struct omap_opp *opp_find_freq_rounded(struct omap_opp *oppl, unsigned long freq, u8 rounding_flag); Note: the only difference b/w this and opp_find_freq is that opp_find_freq will also search for enabled/disabled. If I add that here, this is exactly the #1 implementation I did in http://marc.info/?l=linux-omapm=125800489123496w=2 ok, I used bool instead of a #define and added the complexity of using enabled flag also: bool search_higher, bool search_enabled_only, bool exact_search what you are proposing is that I go back to my implementation #1 and remove my bools instead by adding #defines: /* Search up */ #define OPP_ROUND_ENABLED (0 2) /* Search down */ #define OPP_ROUND_ANY(1 2) would even make the find_freq redundant.. Now, in your comment in http://marc.info/?l=linux-omapm=125816031406704w=2 quote:I think all the options to this function make it not terribly readable. Does it become any different now? Yeah, I still think multiple bools to a function is a readability problem. Every time you look at a call, you have to look at the prototype to remember what all the options are. A single bool or flag is better IMHO. without taking this in, exact searches can be done by specific functions and approximate searches by another function.. we go generic functions or we go specific functions.. generic comments I have been getting is to go specific, hence the v2 and v3 series. OK, you're right. I am causing us to go around in circles now, but we're going around in increasingly smaller circles and hopefully converging on the target. ;) Yep :) So what I propose is having two functions. One for exact matches (your proposal A above) and one for approximate matches which is something like
Re: [PATCH 07/10 V3] omap3: clk: use pm accessor functions for cpufreq table
tero.kri...@nokia.com said the following on 12/07/2009 10:54 AM:
Hi,
One comment below.
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of ext
Nishanth Menon
Sent: 25 November, 2009 06:09
To: linux-omap
Cc: Nishanth Menon; Benoit Cousson; Kevin Hilman; Madhusudhan
Chikkature Rajashekar; Paul Walmsley; Romit Dasgupta; Sanjeev
Premi; Santosh Shilimkar; Sergio Alberto Aguirre Rodriguez;
Thara Gopinath; Vishwanath Sripathy
Subject: [PATCH 07/10 V3] omap3: clk: use pm accessor
functions for cpufreq table
omap2_clk_init_cpufreq_table currently directly accesses the opp
table, making it unscalable to various OMAPs. Instead use the
accessor functions to populate the cpufreq table
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Madhusudhan Chikkature Rajashekar madhu...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Romit Dasgupta ro...@ti.com
Cc: Sanjeev Premi pr...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Sergio Alberto Aguirre Rodriguez saagui...@ti.com
Cc: Thara Gopinath th...@ti.com
Cc: Vishwanath Sripathy vishwanath...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/clock34xx.c | 32
+++-
1 files changed, 19 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx.c
b/arch/arm/mach-omap2/clock34xx.c
index 5150939..d07f1c1 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -1042,30 +1042,36 @@ static unsigned long
omap3_clkoutx2_recalc(struct clk *clk)
#if defined(CONFIG_ARCH_OMAP3)
#ifdef CONFIG_CPU_FREQ
-static struct cpufreq_frequency_table freq_table[MAX_VDD1_OPP+1];
+
+static struct cpufreq_frequency_table *freq_table;
void omap2_clk_init_cpufreq_table(struct
cpufreq_frequency_table **table)
{
-struct omap_opp *prcm;
int i = 0;
+u8 opp_num;
+struct omap_opp *opp = NULL;
+unsigned long freq = ULONG_MAX;
-if (!mpu_opps)
+if (!mpu_opps || opp_get_opp_count(opp_num, mpu_opps)) {
+pr_warning(%s: failed to initialize frequency
+table\n, __func__);
return;
-
-prcm = mpu_opps + MAX_VDD1_OPP;
-for (; prcm-rate; prcm--) {
-freq_table[i].index = i;
-freq_table[i].frequency = prcm-rate / 1000;
-i++;
}
-if (i == 0) {
-printk(KERN_WARNING %s: failed to initialize
frequency \
-
table\n,
-
__func__);
+freq_table = kmalloc(sizeof(struct cpufreq_frequency_table) *
+(opp_num + 1), GFP_KERNEL);
I guess this should be GFP_ATOMIC, we have clockfw spinlock reserved when
this is called (gave me a runtime warning.)
Thanks.. I must have missed the warning.. :( will check and add..
+if (!freq_table) {
+pr_warning(%s: failed to allocate frequency
+table\n, __func__);
return;
}
+while (!opp_get_lower_opp(opp, freq, mpu_opps)) {
+freq_table[i].index = i;
+freq_table[i].frequency = freq / 1000;
+i++;
+}
+
freq_table[i].index = i;
freq_table[i].frequency = CPUFREQ_TABLE_END;
--
1.6.3.3
--
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
--
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 04/10 V3] omap3: pm: srf: use opp accessor functions
tero.kri...@nokia.com said the following on 12/07/2009 10:59 AM: Hi, Couple of comments below. -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of ext Nishanth Menon Sent: 25 November, 2009 06:09 To: linux-omap Cc: Nishanth Menon; Benoit Cousson; Kevin Hilman; Madhusudhan Chikkature Rajashekar; Paul Walmsley; Romit Dasgupta; Sanjeev Premi; Santosh Shilimkar; Sergio Alberto Aguirre Rodriguez; Thara Gopinath; Vishwanath Sripathy Subject: [PATCH 04/10 V3] omap3: pm: srf: use opp accessor functions With the accessor functions, many of the direct accesses are redundant. However we do not want to rewrite SRF at this point of time We do the following here: Remove get_opp and introduce three SRF specific accessor functions: opp_to_freq, freq_to_opp - need this coz of usage of opp IDs NOTE: These functions should be removed at a later point of time. get_opp is removed because, with the above functions, it is redundant. NOTE: this implementation is just a start and leaves scope for further cleanups which can be added on top. NOTE: this increases the number of warnings to: arch/arm/mach-omap2/resource34xx.c: In function 'opp_to_freq': arch/arm/mach-omap2/resource34xx.c:182: warning: 'opp_id' is deprecated (declared at arch/arm/plat-omap/include/plat/opp.h:33) arch/arm/mach-omap2/resource34xx.c: In function 'freq_to_opp': arch/arm/mach-omap2/resource34xx.c:213: warning: 'opp_id' is deprecated (declared at arch/arm/plat-omap/include/plat/opp.h:33) arch/arm/mach-omap2/resource34xx.c: In function 'init_opp': arch/arm/mach-omap2/resource34xx.c:242: warning: 'freq_to_opp' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:205) arch/arm/mach-omap2/resource34xx.c:249: warning: 'freq_to_opp' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:205) arch/arm/mach-omap2/resource34xx.c: In function 'program_opp_freq': arch/arm/mach-omap2/resource34xx.c:302: warning: 'opp_to_freq' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) arch/arm/mach-omap2/resource34xx.c:303: warning: 'opp_to_freq' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) arch/arm/mach-omap2/resource34xx.c:308: warning: 'opp_to_freq' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) arch/arm/mach-omap2/resource34xx.c: In function 'program_opp': arch/arm/mach-omap2/resource34xx.c:351: warning: 'opp_id' is deprecated (declared at arch/arm/plat-omap/include/plat/opp.h:33) arch/arm/mach-omap2/resource34xx.c:352: warning: 'opp_id' is deprecated (declared at arch/arm/plat-omap/include/plat/opp.h:33) arch/arm/mach-omap2/resource34xx.c:356: warning: 'opp_to_freq' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) arch/arm/mach-omap2/resource34xx.c:380: warning: 'opp_to_freq' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) arch/arm/mach-omap2/resource34xx.c: In function 'resource_set_opp_level': arch/arm/mach-omap2/resource34xx.c:417: warning: 'opp_to_freq' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) arch/arm/mach-omap2/resource34xx.c:418: warning: 'opp_to_freq' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) arch/arm/mach-omap2/resource34xx.c:420: warning: 'opp_to_freq' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) arch/arm/mach-omap2/resource34xx.c: In function 'set_opp': arch/arm/mach-omap2/resource34xx.c:497: warning: 'freq_to_opp' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:205) arch/arm/mach-omap2/resource34xx.c: In function 'validate_opp': arch/arm/mach-omap2/resource34xx.c:516: warning: 'opp_to_freq' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) arch/arm/mach-omap2/resource34xx.c:518: warning: 'opp_to_freq' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) arch/arm/mach-omap2/resource34xx.c: In function 'init_freq': arch/arm/mach-omap2/resource34xx.c:541: warning: 'opp_to_freq' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) arch/arm/mach-omap2/resource34xx.c:544: warning: 'opp_to_freq' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) arch/arm/mach-omap2/resource34xx.c: In function 'set_freq': arch/arm/mach-omap2/resource34xx.c:560: warning: 'freq_to_opp' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:205) arch/arm/mach-omap2/resource34xx.c:565: warning: 'freq_to_opp' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:205) arch/arm/mach-omap2/resource34xx.c: In function 'validate_freq': arch/arm/mach-omap2/resource34xx.c:579: warning: 'freq_to_opp' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:205) arch/arm/mach-omap2/resource34xx.c:581: warning: 'freq_to_opp' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:205) Cc: Benoit Cousson b-cous...@ti.com Cc: Kevin Hilman
Re: [PATCH 03/10 V3] omap3: pm: use opp accessor functions for omap34xx
tero.kri...@nokia.com said the following on 12/07/2009 11:02 AM: One additional comment to this patch, compilation of board-rx51.c fails unless #include pm.h is added to it. This might be true for other boards also seeing it has been added to zoom2 at least. Huh.. Weird, I did build and test with omap3_pm_defconfig - rx51 should have been part of the build.. will check also next time.. -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of ext Kevin Hilman Sent: 25 November, 2009 19:22 To: Nishanth Menon Cc: linux-omap Subject: Re: [PATCH 03/10 V3] omap3: pm: use opp accessor functions for omap34xx Nishanth Menon n...@ti.com writes: Move the definitions from omap3-opp.h to pm34xx.c. The definitions are now based on omap_opp_def instead of omap_opp itself. Since the opp.h has the omap_opp definition, omap-pm.h conflicts and has been removed in favor of opp.h. ok omap3_pm_init_opp_table is used to initialize the OPP table and relevant board files which have omap2_init_common_hw called with opp arrays have been updated with omap3_pm_init_opp_table. This change now allows us to dynamically register OPPs to the system based on silicon type we detect. Nice. With this patch, I would suggest a couple more cleanups in how we are handling the master OPP lists for MPU, DSP and L3. Namely, It's time we could remove the rate_table passing from the OMAP PM layer all together and just keep them as pointers in opp.h. The longer term goal is to remove OPP handling from OMAP PM all together, so this will be a step in that direction. I've attached a patch that applies on top of your series that drops the OPPs from OMAP PM layer. After doing this, we now have some duplicate global pointers to the various rate tables that could be cleaned up. In addition, all the rate tables could be dropped from init_common_hw. If you follow my proposal for using opp_add() instead of opp_init() the board files that want to just use default OPPs do not have to do anyting with the rate tables. Only board files wanting to add OPPs would have to include opp.h and use opp_add(). Also, dropping the rate tables from init_common_hw would mean you shouldn't have init sequence issues anymore and you can do the OPP init inside existing PM init. Kevin NOTE: This introduces the following warnings highlighting areas we need to cleanup: arch/arm/mach-omap2/smartreflex.c: In function 'get_opp': arch/arm/mach-omap2/smartreflex.c:161: warning: 'opp_id' is deprecated (declared at arch/arm/plat-omap/include/plat/opp.h:33) arch/arm/mach-omap2/smartreflex.c:164: warning: 'opp_id' is deprecated (declared at arch/arm/plat-omap/include/plat/opp.h:33) arch/arm/mach-omap2/smartreflex.c:166: warning: 'opp_id' is deprecated (declared at arch/arm/plat-omap/include/plat/opp.h:33) arch/arm/mach-omap2/smartreflex.c:168: warning: 'opp_id' is deprecated (declared at arch/arm/plat-omap/include/plat/opp.h:33) arch/arm/mach-omap2/resource34xx.c: In function 'get_opp': arch/arm/mach-omap2/resource34xx.c:165: warning: 'opp_id' is deprecated (declared at arch/arm/plat-omap/include/plat/opp.h:33) arch/arm/mach-omap2/resource34xx.c:168: warning: 'opp_id' is deprecated (declared at arch/arm/plat-omap/include/plat/opp.h:33) arch/arm/mach-omap2/resource34xx.c:170: warning: 'opp_id' is deprecated (declared at arch/arm/plat-omap/include/plat/opp.h:33) arch/arm/mach-omap2/resource34xx.c:172: warning: 'opp_id' is deprecated (declared at arch/arm/plat-omap/include/plat/opp.h:33) arch/arm/mach-omap2/resource34xx.c: In function 'program_opp': arch/arm/mach-omap2/resource34xx.c:284: warning: 'opp_id' is deprecated (declared at arch/arm/plat-omap/include/plat/opp.h:33) arch/arm/mach-omap2/resource34xx.c:285: warning: 'opp_id' is deprecated (declared at arch/arm/plat-omap/include/plat/opp.h:33) Signed-off-by: Nishanth Menon n...@ti.com --- arch/arm/mach-omap2/board-3430sdp.c |1 + arch/arm/mach-omap2/board-omap3beagle.c |1 + arch/arm/mach-omap2/board-omap3evm.c |1 + arch/arm/mach-omap2/board-rx51.c |1 + arch/arm/mach-omap2/board-zoom2.c |2 + arch/arm/mach-omap2/omap3-opp.h | 58 +--- arch/arm/mach-omap2/pm.h |6 +++ arch/arm/mach-omap2/pm34xx.c | 68 + arch/arm/plat-omap/include/plat/omap-pm.h | 17 +--- 9 files changed, 84 insertions(+), 71 deletions(-) diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-omap2/board-3430sdp.c index eac529f..0ec8327 100644 --- a/arch/arm/mach-omap2/board-3430sdp.c +++ b/arch/arm/mach-omap2/board-3430sdp.c
Re: [PATCH 09/10 V3] omap3: pm: introduce 3630 opps
On Tue, Dec 08, 2009 at 11:59:49AM +0100, ext Nishanth Menon wrote:
Hi,
thanks for your comments. few thoughts below.
Eduardo Valentin said the following on 12/08/2009 01:49 AM:
Hello Nishanth,
Few comments bellow.
On Wed, Nov 25, 2009 at 05:09:18AM +0100, ext Nishanth Menon wrote:
Introduce the OMAP3630 OPPs including the defined OPP tuples.
Further information on OMAP3630 can be found here:
http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateId=6123navigationId=12836contentId=52606
OMAP36xx family introduces:
VDD1 with 4 OPPs, of which OPP3 4 are available only on devices yet
to be introduced in 36xx family. Meanwhile, VDD2 has 2 opps.
Device Support of OPPs-
|-3630-600-| (default)
|- 3630-800-| (device: TBD)
|- 3630-1000-| (device: TBD)
H/w OPP- OPP50 OPP100 OPP-Turbo OPP1G-SB
VDD1 OPP1 OPP2 OPP3OPP4
VDD2 OPP1 OPP2 OPP2OPP2
Note:
a) TI h/w naming for OPPs are now standardized in terms of OPP50, 100,
Turbo and SB. This maps as shown above to the opp IDs (s/w term).
b) For boards which need custom VDD1/2 OPPs, the opp table can be
updated by the board file on a need basis after the
omap3_pm_init_opp_table call. The OPPs introduced here are the
official OPP table at this point in time.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Madhusudhan Chikkature Rajashekar madhu...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Romit Dasgupta ro...@ti.com
Cc: Sanjeev Premi pr...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Sergio Alberto Aguirre Rodriguez saagui...@ti.com
Cc: Thara Gopinath th...@ti.com
Cc: Vishwanath Sripathy vishwanath...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/pm34xx.c | 49
-
1 files changed, 47 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index ad21f5f..05ecf02 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -143,6 +143,41 @@ static struct omap_opp_def __initdata
omap34xx_dsp_rate_table[] = {
{.enabled = 0, .freq = 0, .u_volt = 0}
};
+static struct omap_opp_def __initdata omap36xx_mpu_rate_table[] = {
+ /*OPP1 - OPP50*/
+ {.enabled = true, .freq = 3, .u_volt = 93},
+ /*OPP2 - OPP100*/
+ {.enabled = true, .freq = 6, .u_volt = 110},
+ /*OPP3 - OPP-Turbo*/
+ {.enabled = false, .freq = 8, .u_volt = 126},
+ /*OPP4 - OPP-SB*/
+ {.enabled = false, .freq = 10, .u_volt = 131},
+ /* Terminator */
+ {.enabled = 0, .freq = 0, .u_volt = 0}
+};
+
+static struct omap_opp_def __initdata omap36xx_l3_rate_table[] = {
+ /*OPP1 - OPP50 */
+ {.enabled = true, .freq = 1, .u_volt = 93},
+ /*OPP2 - OPP100, OPP-Turbo, OPP-SB*/
+ {.enabled = true, .freq = 2, .u_volt = 1137500},
+ /* Terminator */
+ {.enabled = 0, .freq = 0, .u_volt = 0}
+};
+
+static struct omap_opp_def __initdata omap36xx_dsp_rate_table[] = {
+ /*OPP1 - OPP50*/
+ {.enabled = true, .freq = 26000, .u_volt = 93},
+ /*OPP2 - OPP100*/
+ {.enabled = true, .freq = 52000, .u_volt = 110},
+ /*OPP3 - OPP-Turbo*/
+ {.enabled = false, .freq = 66000, .u_volt = 126},
+ /*OPP4 - OPP-SB*/
+ {.enabled = false, .freq = 87500, .u_volt = 131},
+ /* Terminator */
+ {.enabled = 0, .freq = 0, .u_volt = 0}
+};
+
Although it is not mandatory, I'd say this way of initializing structure
array is more common:
static struct omap_opp_def __initdata omap36xx_dsp_rate_table[] = {
/*OPP1 - OPP50*/
{
.enabled= true,
.freq = 26000,
.u_volt = 93,
},
/*OPP2 - OPP100*/
{
.enabled= true,
.freq = 52000,
.u_volt = 110,
},
/*OPP3 - OPP-Turbo*/
{
.enabled= false,
.freq = 66000,
.u_volt = 126,
},
/*OPP4 - OPP-SB*/
{
.enabled= false,
.freq = 87500,
.u_volt = 131,
},
/* Terminator */
{
.enabled= 0,
.freq = 0,
.u_volt = 0,
}
};
and if you thing it is line consuming, you can always define a INIT macro:
#define OMAP_OPP_DEF(_enabled, _freq, _uv) \
{ \
.enabled= _enabled, \
.freq = _freq,\
.u_volt = _uv, \
Re: [PATCH 09/10 V3] omap3: pm: introduce 3630 opps
Eduardo Valentin said the following on 12/08/2009 05:18 AM:
On Tue, Dec 08, 2009 at 11:59:49AM +0100, ext Nishanth Menon wrote:
Hi,
thanks for your comments. few thoughts below.
Eduardo Valentin said the following on 12/08/2009 01:49 AM:
Hello Nishanth,
Few comments bellow.
On Wed, Nov 25, 2009 at 05:09:18AM +0100, ext Nishanth Menon wrote:
Introduce the OMAP3630 OPPs including the defined OPP tuples.
Further information on OMAP3630 can be found here:
http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateId=6123navigationId=12836contentId=52606
OMAP36xx family introduces:
VDD1 with 4 OPPs, of which OPP3 4 are available only on devices yet
to be introduced in 36xx family. Meanwhile, VDD2 has 2 opps.
Device Support of OPPs-
|-3630-600-| (default)
|- 3630-800-| (device: TBD)
|- 3630-1000-| (device: TBD)
H/w OPP- OPP50 OPP100 OPP-Turbo OPP1G-SB
VDD1 OPP1 OPP2 OPP3OPP4
VDD2 OPP1 OPP2 OPP2OPP2
Note:
a) TI h/w naming for OPPs are now standardized in terms of OPP50, 100,
Turbo and SB. This maps as shown above to the opp IDs (s/w term).
b) For boards which need custom VDD1/2 OPPs, the opp table can be
updated by the board file on a need basis after the
omap3_pm_init_opp_table call. The OPPs introduced here are the
official OPP table at this point in time.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Madhusudhan Chikkature Rajashekar madhu...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Romit Dasgupta ro...@ti.com
Cc: Sanjeev Premi pr...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Sergio Alberto Aguirre Rodriguez saagui...@ti.com
Cc: Thara Gopinath th...@ti.com
Cc: Vishwanath Sripathy vishwanath...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/pm34xx.c | 49
-
1 files changed, 47 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index ad21f5f..05ecf02 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -143,6 +143,41 @@ static struct omap_opp_def __initdata
omap34xx_dsp_rate_table[] = {
{.enabled = 0, .freq = 0, .u_volt = 0}
};
+static struct omap_opp_def __initdata omap36xx_mpu_rate_table[] = {
+ /*OPP1 - OPP50*/
+ {.enabled = true, .freq = 3, .u_volt = 93},
+ /*OPP2 - OPP100*/
+ {.enabled = true, .freq = 6, .u_volt = 110},
+ /*OPP3 - OPP-Turbo*/
+ {.enabled = false, .freq = 8, .u_volt = 126},
+ /*OPP4 - OPP-SB*/
+ {.enabled = false, .freq = 10, .u_volt = 131},
+ /* Terminator */
+ {.enabled = 0, .freq = 0, .u_volt = 0}
+};
+
+static struct omap_opp_def __initdata omap36xx_l3_rate_table[] = {
+ /*OPP1 - OPP50 */
+ {.enabled = true, .freq = 1, .u_volt = 93},
+ /*OPP2 - OPP100, OPP-Turbo, OPP-SB*/
+ {.enabled = true, .freq = 2, .u_volt = 1137500},
+ /* Terminator */
+ {.enabled = 0, .freq = 0, .u_volt = 0}
+};
+
+static struct omap_opp_def __initdata omap36xx_dsp_rate_table[] = {
+ /*OPP1 - OPP50*/
+ {.enabled = true, .freq = 26000, .u_volt = 93},
+ /*OPP2 - OPP100*/
+ {.enabled = true, .freq = 52000, .u_volt = 110},
+ /*OPP3 - OPP-Turbo*/
+ {.enabled = false, .freq = 66000, .u_volt = 126},
+ /*OPP4 - OPP-SB*/
+ {.enabled = false, .freq = 87500, .u_volt = 131},
+ /* Terminator */
+ {.enabled = 0, .freq = 0, .u_volt = 0}
+};
+
Although it is not mandatory, I'd say this way of initializing structure
array is more common:
static struct omap_opp_def __initdata omap36xx_dsp_rate_table[] = {
/*OPP1 - OPP50*/
{
.enabled= true,
.freq = 26000,
.u_volt = 93,
},
/*OPP2 - OPP100*/
{
.enabled= true,
.freq = 52000,
.u_volt = 110,
},
/*OPP3 - OPP-Turbo*/
{
.enabled= false,
.freq = 66000,
.u_volt = 126,
},
/*OPP4 - OPP-SB*/
{
.enabled= false,
.freq = 87500,
.u_volt = 131,
},
/* Terminator */
{
.enabled= 0,
.freq = 0,
.u_volt = 0,
}
};
and if you thing it is line consuming, you can always define a INIT macro:
#define OMAP_OPP_DEF(_enabled, _freq, _uv) \
{ \
.enabled= _enabled, \
.freq = _freq,\
.u_volt = _uv, \
}
and use it to initialize your array:
Re: [PATCH 09/10 V3] omap3: pm: introduce 3630 opps
On Tue, Dec 08, 2009 at 12:31:13PM +0100, ext Nishanth Menon wrote:
Eduardo Valentin said the following on 12/08/2009 05:18 AM:
On Tue, Dec 08, 2009 at 11:59:49AM +0100, ext Nishanth Menon wrote:
Hi,
thanks for your comments. few thoughts below.
Eduardo Valentin said the following on 12/08/2009 01:49 AM:
Hello Nishanth,
Few comments bellow.
On Wed, Nov 25, 2009 at 05:09:18AM +0100, ext Nishanth Menon wrote:
Introduce the OMAP3630 OPPs including the defined OPP tuples.
Further information on OMAP3630 can be found here:
http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateId=6123navigationId=12836contentId=52606
OMAP36xx family introduces:
VDD1 with 4 OPPs, of which OPP3 4 are available only on devices yet
to be introduced in 36xx family. Meanwhile, VDD2 has 2 opps.
Device Support of OPPs-
|-3630-600-| (default)
|- 3630-800-| (device: TBD)
|- 3630-1000-| (device: TBD)
H/w OPP- OPP50 OPP100 OPP-Turbo OPP1G-SB
VDD1 OPP1 OPP2 OPP3OPP4
VDD2 OPP1 OPP2 OPP2OPP2
Note:
a) TI h/w naming for OPPs are now standardized in terms of OPP50, 100,
Turbo and SB. This maps as shown above to the opp IDs (s/w term).
b) For boards which need custom VDD1/2 OPPs, the opp table can be
updated by the board file on a need basis after the
omap3_pm_init_opp_table call. The OPPs introduced here are the
official OPP table at this point in time.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Madhusudhan Chikkature Rajashekar madhu...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Romit Dasgupta ro...@ti.com
Cc: Sanjeev Premi pr...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Sergio Alberto Aguirre Rodriguez saagui...@ti.com
Cc: Thara Gopinath th...@ti.com
Cc: Vishwanath Sripathy vishwanath...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/pm34xx.c | 49
-
1 files changed, 47 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index ad21f5f..05ecf02 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -143,6 +143,41 @@ static struct omap_opp_def __initdata
omap34xx_dsp_rate_table[] = {
{.enabled = 0, .freq = 0, .u_volt = 0}
};
+static struct omap_opp_def __initdata omap36xx_mpu_rate_table[] = {
+ /*OPP1 - OPP50*/
+ {.enabled = true, .freq = 3, .u_volt = 93},
+ /*OPP2 - OPP100*/
+ {.enabled = true, .freq = 6, .u_volt = 110},
+ /*OPP3 - OPP-Turbo*/
+ {.enabled = false, .freq = 8, .u_volt = 126},
+ /*OPP4 - OPP-SB*/
+ {.enabled = false, .freq = 10, .u_volt = 131},
+ /* Terminator */
+ {.enabled = 0, .freq = 0, .u_volt = 0}
+};
+
+static struct omap_opp_def __initdata omap36xx_l3_rate_table[] = {
+ /*OPP1 - OPP50 */
+ {.enabled = true, .freq = 1, .u_volt = 93},
+ /*OPP2 - OPP100, OPP-Turbo, OPP-SB*/
+ {.enabled = true, .freq = 2, .u_volt = 1137500},
+ /* Terminator */
+ {.enabled = 0, .freq = 0, .u_volt = 0}
+};
+
+static struct omap_opp_def __initdata omap36xx_dsp_rate_table[] = {
+ /*OPP1 - OPP50*/
+ {.enabled = true, .freq = 26000, .u_volt = 93},
+ /*OPP2 - OPP100*/
+ {.enabled = true, .freq = 52000, .u_volt = 110},
+ /*OPP3 - OPP-Turbo*/
+ {.enabled = false, .freq = 66000, .u_volt = 126},
+ /*OPP4 - OPP-SB*/
+ {.enabled = false, .freq = 87500, .u_volt = 131},
+ /* Terminator */
+ {.enabled = 0, .freq = 0, .u_volt = 0}
+};
+
Although it is not mandatory, I'd say this way of initializing structure
array is more common:
static struct omap_opp_def __initdata omap36xx_dsp_rate_table[] = {
/*OPP1 - OPP50*/
{
.enabled= true,
.freq = 26000,
.u_volt = 93,
},
/*OPP2 - OPP100*/
{
.enabled= true,
.freq = 52000,
.u_volt = 110,
},
/*OPP3 - OPP-Turbo*/
{
.enabled= false,
.freq = 66000,
.u_volt = 126,
},
/*OPP4 - OPP-SB*/
{
.enabled= false,
.freq = 87500,
.u_volt = 131,
},
/* Terminator */
{
.enabled= 0,
.freq = 0,
.u_volt = 0,
}
};
and if you thing it is line consuming, you can always define a INIT
macro:
#define OMAP_OPP_DEF(_enabled, _freq, _uv) \
{ \
RE: u-boot for omap3
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Weng, Wending Sent: Friday, December 04, 2009 1:14 AM To: 'Gary Thomas' Cc: Pandita, Vikram; linux-omap@vger.kernel.org; Tom Subject: RE: u-boot for omap3 Hi, You are right, I checked u-boot from BSP 2.1.1.7 and BSP 2.1.3.11. Is there any reason to do thing in this way? I use the u-boot from BSP 1.0.0. Regards Wending Wending, I think the discussion will be more useful/ appropriate on the u-boot mailing list (u-b...@lists.denx.de). If I recall your old mail, on kernel being slow on your board, was it due to cache being disabled? Best regards, Sanjeev [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
eac and mcbsp for omap850
Hi, I would like to rewrite old eac audio driver for omap730 to current ASoc implementation but as I can understand new implementation use McBsP to transfer data to codec. Could this approach be used in omap850 which use EAC like codec and data from memory is transfered via DMA? Thanks in advance, Marek -- 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] USB ehci: replace mach header with plat
Replace the mach/usb.h with plat/usb.h Patch was already done in commit: 801db9180010676f97bb3fbd7074291128b7b5fc , but overwritten. Signed-off-by: Thomas Weber we...@corscience.de --- drivers/usb/host/ehci-omap.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c index 7ba8df3..5cfed78 100644 --- a/drivers/usb/host/ehci-omap.c +++ b/drivers/usb/host/ehci-omap.c @@ -37,7 +37,7 @@ #include linux/platform_device.h #include linux/clk.h #include linux/gpio.h -#include mach/usb.h +#include plat/usb.h /* * OMAP USBHOST Register addresses: VIRTUAL ADDRESSES -- 1.6.4.4 -- 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: eac and mcbsp for omap850
On Tue, 8 Dec 2009 13:06:05 +0100 Belisko Marek marek.beli...@gmail.com wrote: Hi, I would like to rewrite old eac audio driver for omap730 to current ASoc implementation but as I can understand new implementation use McBsP to transfer data to codec. Could this approach be used in omap850 which use EAC like codec and data from memory is transfered via DMA? Basically it should be possible to develop a new ASoC DAI driver using EAC. Even currently there is only one McBSP based DAI driver sound/soc/omap/omap-mcbsp.c, there is no restrictions to develop another DAI drivers since the sound/soc/omap/omap-pcm.c is not tied to underlying DAI. -- 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] USB ehci: replace mach header with plat
On Tue, Dec 08, 2009 at 01:15:06PM +0100, ext Thomas Weber wrote: Replace the mach/usb.h with plat/usb.h Patch was already done in commit: 801db9180010676f97bb3fbd7074291128b7b5fc , but overwritten. Signed-off-by: Thomas Weber we...@corscience.de Acked-by: Felipe Balbi felipe.ba...@nokia.com Tony, this should probably go into for-next or for-next-vol2. -- 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: [PATCHV3 3/4] OMAP3: Correct width for CLKSEL Fields
Paul,
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Monday, November 30, 2009 3:45 PM
To: Sripathy, Vishwanath
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCHV3 3/4] OMAP3: Correct width for CLKSEL Fields
Hello Vishwanath,
On Thu, 26 Nov 2009, Vishwanath BS wrote:
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. Primary changes are
1. Added clksel_mask_3630 to take care clksel width changes
2. CLock nodes which are newly added for 3630 are marked under CK_363X
3. Clock nodes which have changes for 3630 are marked as CK_3XXX | CK_363X
4. Clock nodes which are unchanged for 3630 are retained as CK_3XXX
5. 3630 specific Clock rates are marked as RATE_IN_363X
...
@@ -1232,6 +1238,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*/
Please follow the comment style in Documentation/CodingStyle.
+ if (cpu_is_omap3630() (c-cpu CK_363X)) {
+ c-lk.clk-clksel_mask =
+ c-lk.clk-clksel_mask_3630;
+ }
Again, let's avoid dynamic rewriting of the clock tree.
...
@@ -754,7 +796,8 @@ static struct clk dpll4_m4_ck = {
.init = omap2_init_clksel_parent,
.clksel_reg = OMAP_CM_REGADDR(OMAP3430_DSS_MOD, CM_CLKSEL),
.clksel_mask= OMAP3430_CLKSEL_DSS1_MASK,
- .clksel = div16_dpll4_clksel,
+ .clksel_mask_3630 = OMAP3630_CLKSEL_DSS1_MASK,
+ .clksel = div32_dpll4_clksel,
.clkdm_name = dpll4_clkdm,
.recalc = omap2_clksel_recalc,
.set_rate = omap2_clksel_set_rate,
Okay, now I am convinced. We need to explore converting the struct clk
parent pointer into a const char * and a struct clk *, the latter resolved
at clock code init. That should let us split some of these struct clks
that vary between OMAP34xx and OMAP36xx without needing to split other
unrelated sections of the clock tree.
I am thinking of adding a new file called /mach-omap2/clock36xx.h and have
complete 36xx clock tree defined over there instead of tweaking 34xx clock
tree. Any comments?
- Paul
--
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 09/10 V3] omap3: pm: introduce 3630 opps
Eduardo Valentin had written, on 12/08/2009 05:40 AM, the following:
On Tue, Dec 08, 2009 at 12:31:13PM +0100, ext Nishanth Menon wrote:
Eduardo Valentin said the following on 12/08/2009 05:18 AM:
On Tue, Dec 08, 2009 at 11:59:49AM +0100, ext Nishanth Menon wrote:
Hi,
thanks for your comments. few thoughts below.
Eduardo Valentin said the following on 12/08/2009 01:49 AM:
Hello Nishanth,
Few comments bellow.
On Wed, Nov 25, 2009 at 05:09:18AM +0100, ext Nishanth Menon wrote:
Introduce the OMAP3630 OPPs including the defined OPP tuples.
Further information on OMAP3630 can be found here:
http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateId=6123navigationId=12836contentId=52606
OMAP36xx family introduces:
VDD1 with 4 OPPs, of which OPP3 4 are available only on devices yet
to be introduced in 36xx family. Meanwhile, VDD2 has 2 opps.
Device Support of OPPs-
|-3630-600-| (default)
|- 3630-800-| (device: TBD)
|- 3630-1000-| (device: TBD)
H/w OPP- OPP50 OPP100 OPP-Turbo OPP1G-SB
VDD1 OPP1 OPP2 OPP3OPP4
VDD2 OPP1 OPP2 OPP2OPP2
Note:
a) TI h/w naming for OPPs are now standardized in terms of OPP50, 100,
Turbo and SB. This maps as shown above to the opp IDs (s/w term).
b) For boards which need custom VDD1/2 OPPs, the opp table can be
updated by the board file on a need basis after the
omap3_pm_init_opp_table call. The OPPs introduced here are the
official OPP table at this point in time.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Madhusudhan Chikkature Rajashekar madhu...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Romit Dasgupta ro...@ti.com
Cc: Sanjeev Premi pr...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Sergio Alberto Aguirre Rodriguez saagui...@ti.com
Cc: Thara Gopinath th...@ti.com
Cc: Vishwanath Sripathy vishwanath...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/pm34xx.c | 49 -
1 files changed, 47 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index ad21f5f..05ecf02 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -143,6 +143,41 @@ static struct omap_opp_def __initdata
omap34xx_dsp_rate_table[] = {
{.enabled = 0, .freq = 0, .u_volt = 0}
};
+static struct omap_opp_def __initdata omap36xx_mpu_rate_table[] = {
+ /*OPP1 - OPP50*/
+ {.enabled = true, .freq = 3, .u_volt = 93},
+ /*OPP2 - OPP100*/
+ {.enabled = true, .freq = 6, .u_volt = 110},
+ /*OPP3 - OPP-Turbo*/
+ {.enabled = false, .freq = 8, .u_volt = 126},
+ /*OPP4 - OPP-SB*/
+ {.enabled = false, .freq = 10, .u_volt = 131},
+ /* Terminator */
+ {.enabled = 0, .freq = 0, .u_volt = 0}
+};
+
+static struct omap_opp_def __initdata omap36xx_l3_rate_table[] = {
+ /*OPP1 - OPP50 */
+ {.enabled = true, .freq = 1, .u_volt = 93},
+ /*OPP2 - OPP100, OPP-Turbo, OPP-SB*/
+ {.enabled = true, .freq = 2, .u_volt = 1137500},
+ /* Terminator */
+ {.enabled = 0, .freq = 0, .u_volt = 0}
+};
+
+static struct omap_opp_def __initdata omap36xx_dsp_rate_table[] = {
+ /*OPP1 - OPP50*/
+ {.enabled = true, .freq = 26000, .u_volt = 93},
+ /*OPP2 - OPP100*/
+ {.enabled = true, .freq = 52000, .u_volt = 110},
+ /*OPP3 - OPP-Turbo*/
+ {.enabled = false, .freq = 66000, .u_volt = 126},
+ /*OPP4 - OPP-SB*/
+ {.enabled = false, .freq = 87500, .u_volt = 131},
+ /* Terminator */
+ {.enabled = 0, .freq = 0, .u_volt = 0}
+};
+
Although it is not mandatory, I'd say this way of initializing structure array
is more common:
static struct omap_opp_def __initdata omap36xx_dsp_rate_table[] = {
/*OPP1 - OPP50*/
{
.enabled= true,
.freq = 26000,
.u_volt = 93,
},
/*OPP2 - OPP100*/
{
.enabled= true,
.freq = 52000,
.u_volt = 110,
},
/*OPP3 - OPP-Turbo*/
{
.enabled= false,
.freq = 66000,
.u_volt = 126,
},
/*OPP4 - OPP-SB*/
{
.enabled= false,
.freq = 87500,
.u_volt = 131,
},
/* Terminator */
{
.enabled= 0,
.freq = 0,
.u_volt = 0,
}
};
and if you thing it is line consuming, you can always define a INIT macro:
#define OMAP_OPP_DEF(_enabled, _freq, _uv) \
{ \
.enabled= _enabled, \
.freq = _freq,\
.u_volt = _uv, \
}
and use it to initialize your array:
/*OPP1 - OPP50*/
[PATCH] Smartreflex: Avoid unnecessary spam
From: Tero Kristo tero.kri...@nokia.com
Current warning messages will be constantly printed out during normal operation
if smartreflex autocompensation is disabled.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
---
arch/arm/mach-omap2/smartreflex.c | 10 +-
1 files changed, 1 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index be3a1da..db228b2 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -675,13 +675,8 @@ void sr_start_vddautocomap(int srid, u32 target_opp_no)
sr_configure(sr);
}
- if (sr-is_autocomp_active == 1)
- pr_warning(SR%d: VDD autocomp is already active\n,
- srid);
-
sr-is_autocomp_active = 1;
if (!sr_enable(sr, target_opp_no)) {
- pr_warning(SR%d: VDD autocomp not activated\n, srid);
sr-is_autocomp_active = 0;
if (sr-is_sr_reset == 1)
sr_clk_disable(sr);
@@ -707,11 +702,8 @@ int sr_stop_vddautocomap(int srid)
/* Reset the volatage for current OPP */
sr_reset_voltage(srid);
return true;
- } else {
- pr_warning(SR%d: VDD autocomp is not active\n,
- srid);
+ } else
return false;
- }
}
EXPORT_SYMBOL(sr_stop_vddautocomap);
--
1.5.4.3
--
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 0/2] OMAP: convert boards to use platform data with smc91x
As smc91x driver allows specifying settings in board resources, use that rather than needing CONFIG_ARCH_OMAP in the drivers/net/smc91x.h header. arch/arm/mach-omap1/board-fsample.c | 10 ++ arch/arm/mach-omap1/board-h2.c| 10 ++ arch/arm/mach-omap1/board-h3.c| 10 ++ arch/arm/mach-omap1/board-innovator.c | 13 + arch/arm/mach-omap1/board-osk.c | 10 ++ arch/arm/mach-omap1/board-perseus2.c | 10 ++ arch/arm/mach-omap1/board-voiceblue.c | 10 ++ arch/arm/mach-omap2/board-apollon.c | 10 ++ arch/arm/mach-omap2/gpmc-smc91x.c |8 +--- arch/arm/plat-omap/debug-devices.c| 10 ++ drivers/net/smc91x.h | 15 --- 11 files changed, 98 insertions(+), 18 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 1/2] OMAP: use smc91x_platdata to setup smc91x
Use smc91x_platdata to setup smc91x, so we can get rid of OMAP specific stuff
in smc91x driver
Signed-off-by: Ladislav Michl la...@linux-mips.org
diff --git a/arch/arm/mach-omap1/board-fsample.c
b/arch/arm/mach-omap1/board-fsample.c
index f4b72c1..91e7b2f 100644
--- a/arch/arm/mach-omap1/board-fsample.c
+++ b/arch/arm/mach-omap1/board-fsample.c
@@ -19,6 +19,7 @@
#include linux/mtd/nand.h
#include linux/mtd/partitions.h
#include linux/input.h
+#include linux/smc91x.h
#include mach/hardware.h
#include asm/mach-types.h
@@ -100,6 +101,12 @@ static int fsample_keymap[] = {
0
};
+static struct smc91x_platdata smc91x_info = {
+ .flags = SMC91X_USE_16BIT | SMC91X_NOWAIT,
+ .leda = RPC_LED_100_10,
+ .ledb = RPC_LED_TX_RX,
+};
+
static struct resource smc91x_resources[] = {
[0] = {
.start = H2P2_DBG_FPGA_ETHR_START, /* Physical */
@@ -190,6 +197,9 @@ static struct platform_device nand_device = {
static struct platform_device smc91x_device = {
.name = smc91x,
.id = 0,
+ .dev= {
+ .platform_data = smc91x_info,
+ },
.num_resources = ARRAY_SIZE(smc91x_resources),
.resource = smc91x_resources,
};
diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
index 89ba8ec..eeafe6e 100644
--- a/arch/arm/mach-omap1/board-h2.c
+++ b/arch/arm/mach-omap1/board-h2.c
@@ -28,6 +28,7 @@
#include linux/mtd/partitions.h
#include linux/input.h
#include linux/i2c/tps65010.h
+#include linux/smc91x.h
#include mach/hardware.h
#include asm/gpio.h
@@ -200,6 +201,12 @@ static struct platform_device h2_nand_device = {
.resource = h2_nand_resource,
};
+static struct smc91x_platdata h2_smc91x_info = {
+ .flags = SMC91X_USE_16BIT | SMC91X_NOWAIT,
+ .leda = RPC_LED_100_10,
+ .ledb = RPC_LED_TX_RX,
+};
+
static struct resource h2_smc91x_resources[] = {
[0] = {
.start = OMAP1610_ETHR_START, /* Physical */
@@ -216,6 +223,9 @@ static struct resource h2_smc91x_resources[] = {
static struct platform_device h2_smc91x_device = {
.name = smc91x,
.id = 0,
+ .dev= {
+ .platform_data = h2_smc91x_info,
+ },
.num_resources = ARRAY_SIZE(h2_smc91x_resources),
.resource = h2_smc91x_resources,
};
diff --git a/arch/arm/mach-omap1/board-h3.c b/arch/arm/mach-omap1/board-h3.c
index f5cc0a7..e0aee66 100644
--- a/arch/arm/mach-omap1/board-h3.c
+++ b/arch/arm/mach-omap1/board-h3.c
@@ -28,6 +28,7 @@
#include linux/input.h
#include linux/spi/spi.h
#include linux/i2c/tps65010.h
+#include linux/smc91x.h
#include asm/setup.h
#include asm/page.h
@@ -202,6 +203,12 @@ static struct platform_device nand_device = {
.resource = nand_resource,
};
+static struct smc91x_platdata smc91x_info = {
+ .flags = SMC91X_USE_16BIT | SMC91X_NOWAIT,
+ .leda = RPC_LED_100_10,
+ .ledb = RPC_LED_TX_RX,
+};
+
static struct resource smc91x_resources[] = {
[0] = {
.start = OMAP1710_ETHR_START, /* Physical */
@@ -218,6 +225,9 @@ static struct resource smc91x_resources[] = {
static struct platform_device smc91x_device = {
.name = smc91x,
.id = 0,
+ .dev= {
+ .platform_data = smc91x_info,
+ },
.num_resources = ARRAY_SIZE(smc91x_resources),
.resource = smc91x_resources,
};
diff --git a/arch/arm/mach-omap1/board-innovator.c
b/arch/arm/mach-omap1/board-innovator.c
index cf0fdb9..91b3b8e 100644
--- a/arch/arm/mach-omap1/board-innovator.c
+++ b/arch/arm/mach-omap1/board-innovator.c
@@ -23,6 +23,7 @@
#include linux/mtd/mtd.h
#include linux/mtd/partitions.h
#include linux/input.h
+#include linux/smc91x.h
#include mach/hardware.h
#include asm/mach-types.h
@@ -159,6 +160,12 @@ static struct map_desc innovator1510_io_desc[] __initdata
= {
}
};
+static struct smc91x_platdata innovator_smc91x_info = {
+ .flags = SMC91X_USE_16BIT | SMC91X_NOWAIT,
+ .leda = RPC_LED_100_10,
+ .ledb = RPC_LED_TX_RX,
+};
+
static struct resource innovator1510_smc91x_resources[] = {
[0] = {
.start = OMAP1510_FPGA_ETHR_START, /* Physical */
@@ -175,6 +182,9 @@ static struct resource innovator1510_smc91x_resources[] = {
static struct platform_device innovator1510_smc91x_device = {
.name = smc91x,
.id = 0,
+ .dev= {
+ .platform_data = innovator_smc91x_info,
+ },
.num_resources = ARRAY_SIZE(innovator1510_smc91x_resources),
.resource = innovator1510_smc91x_resources,
};
@@ -241,6 +251,9 @@ static struct resource innovator1610_smc91x_resources[] = {
static struct platform_device innovator1610_smc91x_device = {
.name = smc91x,
[RFC][RFT][PATCH 3/4 v6] OMAP: McBSP: Introduce caching in register write operations
Allocate space for storing cached copies of McBSP register values.
Modify omap_msbcp_write() to update the cache with every register write
operation.
Modify omap_mcbsp_read() to support reading from cache or hardware.
Update MCBSP_READ/MCBSP_WRITE macros for modified function APIs.
Introduce a new macro that reads from the cache.
Applies on top of patch 2 from this series:
[PATCH v3 2/4] OMAP: McBSP: Prepare register read/write macros API for caching
Tested on OMAP1510 based Amstrad Delta using linux-omap for-next,
commit 82f1d8f22f2c65e70206e40a6f17688bf64a892c.
Compile-tested with omap_generic_2420_defconfig, omap_3430sdp_defconfig.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
Monday 07 December 2009 22:06:31 Tony Lindgren wrote:
Well if you want to optimize it out further, how about just kzalloc it
during init? Then you have just one copy that gets set the right size
depending on what you boot.
Tony,
In v4 of the patch, a single table was actually kzalloced during init as a
part of struct omap_mcbsp for each McBSP port configured. Since you objected
it, and the reason was not quite obvious to me, I submitted two alternate
versions: 5a, with ifdef...else cleanup, maybe still not good enough but
keeping that dynamic allocation, and 5b, using static storage instead, since I
could suspect you may like it better. Now it appears not quite true.
Anyway, sorry for all that long discussion, but it's really important for me
to understand precisely what your concearns, goals and preferences are when
you request changes before I'm able to implement them correctly, ie. in an way
acceptable for you. Otherwise, it all turns into a kind of quiz.
Tuesday 08 December 2009 08:35:21 Jarkko Nikula wrote:
How about declaring the reg_cache as a void pointer in struct
omap_mcbsp and allocate the cache and its size in omap_mcbsp_request
according to omap type? Read and write functions would access the
*reg_cache either as 16-bit or 32-bit table depending on omap.
No ifdefs, no unused cache tables in multi-omap binary and cache tables
are allocated only for used ports. I don't think there is need to
preserve cache content over omap_mcbsp_free and new omap_mcbsp_request?
Jarkko,
I think this is the best solution. I had almost already sent a modified
version last night, with two pointers, u16 *omap1_cache and u32 *omap2_cache,
inside omap_mcbsp structre, but now I think that if using casts inside
omap_mcbsp_read()/_write() is not objected by anyone, the version below,
based on your idea, seems the most clean one.
I was not sure about deferring memory allocation until omap_mcbsp_request(),
but if you say it should be ok, I'm all in favour of that.
Note: 2420 handling may look weird, but I just tried to follow exactly what I
was able to learn about it by reading the code: register address spacing
were 32-bit, register read/write operations - 16-bit, since u16 reg_cache
elements.
Thanks,
Janusz
arch/arm/plat-omap/include/plat/mcbsp.h |9 ++
arch/arm/plat-omap/mcbsp.c | 66
+--
2 files changed, 63 insertions(+), 12 deletions(-)
diff -upr git.orig/arch/arm/plat-omap/include/plat/mcbsp.h
git/arch/arm/plat-omap/include/plat/mcbsp.h
--- git.orig/arch/arm/plat-omap/include/plat/mcbsp.h2009-12-02
15:48:51.0 +0100
+++ git/arch/arm/plat-omap/include/plat/mcbsp.h 2009-12-08 14:26:42.0
+0100
@@ -157,6 +157,14 @@
#endif
+#define OMAP7XX_MCBSP_REG_NUM (OMAP_MCBSP_REG_XCERH / sizeof(u16) + 1)
+#define OMAP15XX_MCBSP_REG_NUM (OMAP_MCBSP_REG_XCERH / sizeof(u16) + 1)
+#define OMAP16XX_MCBSP_REG_NUM (OMAP_MCBSP_REG_XCERH / sizeof(u16) + 1)
+
+#define OMAP24XX_MCBSP_REG_NUM (OMAP_MCBSP_REG_RCCR / sizeof(u32) + 1)
+#define OMAP34XX_MCBSP_REG_NUM (OMAP_MCBSP_REG_RCCR / sizeof(u32) + 1)
+#define OMAP44XX_MCBSP_REG_NUM (OMAP_MCBSP_REG_RCCR / sizeof(u32) + 1)
+
/** McBSP SPCR1 bit definitions
***/
#define RRST 0x0001
#define RRDY 0x0002
@@ -415,6 +423,7 @@ struct omap_mcbsp {
u16 max_tx_thres;
u16 max_rx_thres;
#endif
+ void *reg_cache;
};
extern struct omap_mcbsp **mcbsp_ptr;
extern int omap_mcbsp_count;
diff -upr git.orig/arch/arm/plat-omap/mcbsp.c git/arch/arm/plat-omap/mcbsp.c
--- git.orig/arch/arm/plat-omap/mcbsp.c 2009-12-07 22:43:56.0 +0100
+++ git/arch/arm/plat-omap/mcbsp.c 2009-12-08 14:38:38.0 +0100
@@ -30,26 +30,40 @@
struct omap_mcbsp **mcbsp_ptr;
int omap_mcbsp_count;
-void omap_mcbsp_write(void __iomem *io_base, u16 reg, u32 val)
+void omap_mcbsp_write(struct omap_mcbsp *mcbsp, u16 reg, u32 val)
{
- if (cpu_class_is_omap1() || cpu_is_omap2420())
- __raw_writew((u16)val, io_base + reg);
- else
- __raw_writel(val, io_base + reg);
+ if (cpu_class_is_omap1()) {
+ ((u16 *)mcbsp-reg_cache)[reg / sizeof(u16)] =
[PATCH 2/2] smc91x: remove OMAP specific bits
Now that all OMAP boards are using the board resources, we don't need to keep the arch/board specific crap in the driver header. Signed-off-by: Ladislav Michl la...@linux-mips.org diff --git a/drivers/net/smc91x.h b/drivers/net/smc91x.h index 3911be7..bfc53eb 100644 --- a/drivers/net/smc91x.h +++ b/drivers/net/smc91x.h @@ -206,21 +206,6 @@ SMC_outw(u16 val, void __iomem *ioaddr, int reg) } } -#elif defined(CONFIG_ARCH_OMAP) - -/* We can only do 16-bit reads and writes in the static memory space. */ -#define SMC_CAN_USE_8BIT 0 -#define SMC_CAN_USE_16BIT 1 -#define SMC_CAN_USE_32BIT 0 -#define SMC_IO_SHIFT 0 -#define SMC_NOWAIT 1 - -#define SMC_inw(a, r) readw((a) + (r)) -#define SMC_outw(v, a, r) writew(v, (a) + (r)) -#define SMC_insw(a, r, p, l) readsw((a) + (r), p, l) -#define SMC_outsw(a, r, p, l) writesw((a) + (r), p, l) -#defineSMC_IRQ_FLAGS (-1)/* from resource */ - #elif defined(CONFIG_SH_SH4202_MICRODEV) #define SMC_CAN_USE_8BIT 0 -- 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/8] Board file of Always Innovating OMAP3-based Touch Book
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Tuesday, December 08, 2009 4:49 AM
To: Tim Yamin
Cc: Hiremath, Vaibhav; Gregoire Gentil; linux-omap@vger.kernel.org
Subject: Re: [PATCH 2/8] Board file of Always Innovating OMAP3-based
Touch Book
* Tim Yamin plasma...@gmail.com [091207 14:10]:
2009/12/7 Tony Lindgren t...@atomide.com:
One more thing just came in my mind, have you thought of using
standard backlight class driver???
I'll add this without the backlight code so we get the basic
support into mainline while using the backlight class driver
issue is being discussed.
But the board file *is* implementing the standard backlight class,
i.e. the interface in linux/backlight.h... perhaps I'm
misunderstanding the intention here?
Hmm, yeah. Hiremath care to clarify what you had in mind
with that standard backlight class driver comment?
[Hiremath, Vaibhav] I was referring to generic_bl driver? Actually when I had
submitted the similar patch for OMAP3EVM, I had received similar comment to use
generic_bl interface.
In your case, you just need to do something -
static void touchbook_set_backlight(int intensity)
{
}
static struct generic_bl_info touchbook_bl_platform_data = {
.name = touchbook-bklight,
.max_intensity = 100,
.default_intensity = 50,
.limit_mask = 0,
.set_bl_intensity = touchbook_set_backlight,
.kick_battery = NULL,
};
static struct platform_device touchbook_bklight_device = {
.name = generic-bl,
.id = -1,
.dev= {
.platform_data = touchbook_bl_platform_data,
},
};
Thanks,
Vaibhav
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: [RFC][RFT][PATCH 3/4 v6] OMAP: McBSP: Introduce caching in register write operations
Hi,
Almost there :) Just one more comment below.
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [091208 08:06]:
Allocate space for storing cached copies of McBSP register values.
Modify omap_msbcp_write() to update the cache with every register write
operation.
Modify omap_mcbsp_read() to support reading from cache or hardware.
Update MCBSP_READ/MCBSP_WRITE macros for modified function APIs.
Introduce a new macro that reads from the cache.
Applies on top of patch 2 from this series:
[PATCH v3 2/4] OMAP: McBSP: Prepare register read/write macros API for caching
Tested on OMAP1510 based Amstrad Delta using linux-omap for-next,
commit 82f1d8f22f2c65e70206e40a6f17688bf64a892c.
Compile-tested with omap_generic_2420_defconfig, omap_3430sdp_defconfig.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
Monday 07 December 2009 22:06:31 Tony Lindgren wrote:
Well if you want to optimize it out further, how about just kzalloc it
during init? Then you have just one copy that gets set the right size
depending on what you boot.
Tony,
In v4 of the patch, a single table was actually kzalloced during init as a
part of struct omap_mcbsp for each McBSP port configured. Since you objected
it, and the reason was not quite obvious to me, I submitted two alternate
versions: 5a, with ifdef...else cleanup, maybe still not good enough but
keeping that dynamic allocation, and 5b, using static storage instead, since I
could suspect you may like it better. Now it appears not quite true.
Anyway, sorry for all that long discussion, but it's really important for me
to understand precisely what your concearns, goals and preferences are when
you request changes before I'm able to implement them correctly, ie. in an way
acceptable for you. Otherwise, it all turns into a kind of quiz.
Yeah, thanks for considering all the issues, hopefully it will make
things easier for us in the long run.
Tuesday 08 December 2009 08:35:21 Jarkko Nikula wrote:
How about declaring the reg_cache as a void pointer in struct
omap_mcbsp and allocate the cache and its size in omap_mcbsp_request
according to omap type? Read and write functions would access the
*reg_cache either as 16-bit or 32-bit table depending on omap.
No ifdefs, no unused cache tables in multi-omap binary and cache tables
are allocated only for used ports. I don't think there is need to
preserve cache content over omap_mcbsp_free and new omap_mcbsp_request?
Jarkko,
I think this is the best solution. I had almost already sent a modified
version last night, with two pointers, u16 *omap1_cache and u32 *omap2_cache,
inside omap_mcbsp structre, but now I think that if using casts inside
omap_mcbsp_read()/_write() is not objected by anyone, the version below,
based on your idea, seems the most clean one.
I was not sure about deferring memory allocation until omap_mcbsp_request(),
but if you say it should be ok, I'm all in favour of that.
Note: 2420 handling may look weird, but I just tried to follow exactly what I
was able to learn about it by reading the code: register address spacing
were 32-bit, register read/write operations - 16-bit, since u16 reg_cache
elements.
Thanks,
Janusz
arch/arm/plat-omap/include/plat/mcbsp.h |9 ++
arch/arm/plat-omap/mcbsp.c | 66
+--
2 files changed, 63 insertions(+), 12 deletions(-)
diff -upr git.orig/arch/arm/plat-omap/include/plat/mcbsp.h
git/arch/arm/plat-omap/include/plat/mcbsp.h
--- git.orig/arch/arm/plat-omap/include/plat/mcbsp.h 2009-12-02
15:48:51.0 +0100
+++ git/arch/arm/plat-omap/include/plat/mcbsp.h 2009-12-08
14:26:42.0 +0100
@@ -157,6 +157,14 @@
#endif
+#define OMAP7XX_MCBSP_REG_NUM(OMAP_MCBSP_REG_XCERH / sizeof(u16) + 1)
+#define OMAP15XX_MCBSP_REG_NUM (OMAP_MCBSP_REG_XCERH / sizeof(u16) + 1)
+#define OMAP16XX_MCBSP_REG_NUM (OMAP_MCBSP_REG_XCERH / sizeof(u16) + 1)
+
+#define OMAP24XX_MCBSP_REG_NUM (OMAP_MCBSP_REG_RCCR / sizeof(u32) + 1)
+#define OMAP34XX_MCBSP_REG_NUM (OMAP_MCBSP_REG_RCCR / sizeof(u32) + 1)
+#define OMAP44XX_MCBSP_REG_NUM (OMAP_MCBSP_REG_RCCR / sizeof(u32) + 1)
+
/** McBSP SPCR1 bit definitions
***/
#define RRST 0x0001
#define RRDY 0x0002
@@ -415,6 +423,7 @@ struct omap_mcbsp {
u16 max_tx_thres;
u16 max_rx_thres;
#endif
+ void *reg_cache;
};
extern struct omap_mcbsp **mcbsp_ptr;
extern int omap_mcbsp_count;
diff -upr git.orig/arch/arm/plat-omap/mcbsp.c git/arch/arm/plat-omap/mcbsp.c
--- git.orig/arch/arm/plat-omap/mcbsp.c 2009-12-07 22:43:56.0
+0100
+++ git/arch/arm/plat-omap/mcbsp.c2009-12-08 14:38:38.0 +0100
@@ -30,26 +30,40 @@
struct omap_mcbsp **mcbsp_ptr;
int omap_mcbsp_count;
-void omap_mcbsp_write(void __iomem *io_base,
Re: [RFC][RFT][PATCH 3/4 v6] OMAP: McBSP: Introduce caching in register write operations
* Tony Lindgren t...@atomide.com [091208 08:39]:
@@ -391,6 +405,31 @@ int omap_mcbsp_request(unsigned int id)
}
mcbsp = id_to_mcbsp_ptr(id);
+ if (cpu_is_omap7xx()) {
+ mcbsp-reg_cache = kzalloc(sizeof(u16) *
+ OMAP7XX_MCBSP_REG_NUM, GFP_KERNEL);
+ } else if (cpu_is_omap15xx()) {
+ mcbsp-reg_cache = kzalloc(sizeof(u16) *
+ OMAP15XX_MCBSP_REG_NUM, GFP_KERNEL);
+ } else if (cpu_is_omap16xx()) {
+ mcbsp-reg_cache = kzalloc(sizeof(u16) *
+ OMAP16XX_MCBSP_REG_NUM, GFP_KERNEL);
+ } else if (cpu_is_omap2420()) {
+ mcbsp-reg_cache = kzalloc(sizeof(u16) *
+ OMAP24XX_MCBSP_REG_NUM, GFP_KERNEL);
+ } else if (cpu_is_omap2430()) {
+ mcbsp-reg_cache = kzalloc(sizeof(u32) *
+ OMAP24XX_MCBSP_REG_NUM, GFP_KERNEL);
+ } else if (cpu_is_omap34xx()) {
+ mcbsp-reg_cache = kzalloc(sizeof(u32) *
+ OMAP34XX_MCBSP_REG_NUM, GFP_KERNEL);
+ } else if (cpu_is_omap44xx()) {
+ mcbsp-reg_cache = kzalloc(sizeof(u32) *
+ OMAP44XX_MCBSP_REG_NUM, GFP_KERNEL);
+ }
How about just set the cache size above based on the processor,
then do kzalloc here:
mcbsp-reg_cache = kzalloc(size, GFP_KERNEL);
+ if (!mcbsp-reg_cache)
+ return -ENOMEM;
+
That way the kzalloc and error checking are in the same place.
Actually since we already have mach-omap1/mcbsp.c and mach-omap2/mcbsp.c,
it would be best to pass the cache size from omap1_mcbsp_init and
omap2_mcbsp_init. That leaves some of the if cpu_is_omap() else
stuff.
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
[PATCH v2 0/6] Basic OMAP4 PRCM register def series
Hi, This series contains patches which define OMAP4430 PRM/CM1/CM2 module register offsets and masks. These patches apply on top of the latest mainline kernel and are tested on the OMAP4 simulator platform as well the omap4430sdp based on ES1.0 silicon. These patches are also boot tested on omap3430sdp and compile tested for h4 and 2430. All the headers as part of this series are autogenerated using OMAP4 hardware database and is a joint effort of Paul Walmsley (p...@pwsan.com), Benoit Cousson (b-cous...@ti.com) and me. regards, Rajendra Rajendra Nayak (6): ARM: OMAP4: PM: Fix the PRM and CM base addresses ARM: OMAP4: PM: PRM/CM module offsets for OMAP4 ARM: OMAP4: PM: Adds PRM register defs for OMAP4 ARM: OMAP4: PM: Adds PRM register shift and mask bits ARM: OMAP4: PM: Adds CM1/2 register defs for OMAP4 ARM: OMAP4: PM: Adds CM1/2 register field masks -- 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 v2 1/6] ARM: OMAP4: PM: Fix the PRM and CM base addresses
This patch fixes the PRM and CM base addresses and adds
a new CM2 base address for OMAP4
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/prcm.c |2 ++
arch/arm/plat-omap/clock.c |5 -
arch/arm/plat-omap/common.c|2 ++
arch/arm/plat-omap/include/plat/common.h |1 +
arch/arm/plat-omap/include/plat/omap44xx.h |6 --
6 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index b6e011a..2996974 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -11,6 +11,7 @@ clock-common = clock.o clockdomain.o
obj-$(CONFIG_ARCH_OMAP2) += $(omap-2-3-common) $(prcm-common) $(clock-common)
obj-$(CONFIG_ARCH_OMAP3) += $(omap-2-3-common) $(prcm-common) $(clock-common)
+obj-$(CONFIG_ARCH_OMAP4) += prcm.o
obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
index 029d376..bfe9a15 100644
--- a/arch/arm/mach-omap2/prcm.c
+++ b/arch/arm/mach-omap2/prcm.c
@@ -34,6 +34,7 @@
static void __iomem *prm_base;
static void __iomem *cm_base;
+static void __iomem *cm2_base;
#define MAX_MODULE_ENABLE_WAIT 10
@@ -265,6 +266,7 @@ void __init omap2_set_globals_prcm(struct omap_globals
*omap2_globals)
{
prm_base = omap2_globals-prm;
cm_base = omap2_globals-cm;
+ cm2_base = omap2_globals-cm2;
}
#ifdef CONFIG_ARCH_OMAP3
diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c
index 681bfc3..b857d11 100644
--- a/arch/arm/plat-omap/clock.c
+++ b/arch/arm/plat-omap/clock.c
@@ -57,11 +57,6 @@ void omap2_clk_prepare_for_reboot(void)
{
}
EXPORT_SYMBOL(omap2_clk_prepare_for_reboot);
-
-void omap_prcm_arch_reset(char mode)
-{
-}
-EXPORT_SYMBOL(omap_prcm_arch_reset);
#endif
int clk_enable(struct clk *clk)
{
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index cc050b3..01ab1e5 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -284,12 +284,14 @@ static struct omap_globals omap4_globals = {
.ctrl = OMAP2_L4_IO_ADDRESS(OMAP443X_CTRL_BASE),
.prm= OMAP2_L4_IO_ADDRESS(OMAP4430_PRM_BASE),
.cm = OMAP2_L4_IO_ADDRESS(OMAP4430_CM_BASE),
+ .cm2= OMAP2_L4_IO_ADDRESS(OMAP4430_CM2_BASE),
};
void __init omap2_set_globals_443x(void)
{
omap2_set_globals_tap(omap4_globals);
omap2_set_globals_control(omap4_globals);
+ omap2_set_globals_prcm(omap4_globals);
}
#endif
diff --git a/arch/arm/plat-omap/include/plat/common.h
b/arch/arm/plat-omap/include/plat/common.h
index 754fbc8..5876373 100644
--- a/arch/arm/plat-omap/include/plat/common.h
+++ b/arch/arm/plat-omap/include/plat/common.h
@@ -46,6 +46,7 @@ struct omap_globals {
void __iomem*ctrl; /* System Control Module */
void __iomem*prm; /* Power and Reset Management */
void __iomem*cm;/* Clock Management */
+ void __iomem*cm2;
};
void omap2_set_globals_242x(void);
diff --git a/arch/arm/plat-omap/include/plat/omap44xx.h
b/arch/arm/plat-omap/include/plat/omap44xx.h
index e52902a..ef870de 100644
--- a/arch/arm/plat-omap/include/plat/omap44xx.h
+++ b/arch/arm/plat-omap/include/plat/omap44xx.h
@@ -26,8 +26,10 @@
#define OMAP44XX_EMIF2_BASE0x4d00
#define OMAP44XX_DMM_BASE 0x4e00
#define OMAP4430_32KSYNCT_BASE 0x4a304000
-#define OMAP4430_CM_BASE 0x4a004000
-#define OMAP4430_PRM_BASE 0x48306000
+#define OMAP4430_CM1_BASE 0x4a004000
+#define OMAP4430_CM_BASE OMAP4430_CM1_BASE
+#define OMAP4430_CM2_BASE 0x4a008000
+#define OMAP4430_PRM_BASE 0x4a306000
#define OMAP44XX_GPMC_BASE 0x5000
#define OMAP443X_SCM_BASE 0x4a002000
#define OMAP443X_CTRL_BASE OMAP443X_SCM_BASE
--
1.5.4.7
--
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 v2 2/6] ARM: OMAP4: PM: PRM/CM module offsets for OMAP4
This patch adds the offsets for new modules in PRM and CM for OMAP4 These are autogenerated using a python script (gen_prcm44xx_h.py) developed by Paul Walmsley and Benoit Cousson. Signed-off-by: Rajendra Nayak rna...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Benoit Cousson b-cous...@ti.com --- arch/arm/mach-omap2/prcm-common.h | 67 +++- 1 files changed, 65 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/prcm-common.h b/arch/arm/mach-omap2/prcm-common.h index cb1ae84..4f1b736 100644 --- a/arch/arm/mach-omap2/prcm-common.h +++ b/arch/arm/mach-omap2/prcm-common.h @@ -4,10 +4,12 @@ /* * OMAP2/3 PRCM base and module definitions * - * Copyright (C) 2007-2008 Texas Instruments, Inc. - * Copyright (C) 2007-2008 Nokia Corporation + * Copyright (C) 2007-2009 Texas Instruments, Inc. + * Copyright (C) 2007-2009 Nokia Corporation * * Written by Paul Walmsley + * OMAP4 defines in this file are automatically generated from the OMAP hardware + * databases. * * 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 @@ -49,6 +51,67 @@ #define OMAP3430_NEON_MOD 0xb00 #define OMAP3430ES2_USBHOST_MOD0xc00 +/* OMAP44XX specific module offsets */ + +/* CM1 instances */ + +#define OMAP4430_CM1_OCP_SOCKET_MOD0x +#define OMAP4430_CM1_CKGEN_MOD 0x0100 +#define OMAP4430_CM1_MPU_MOD 0x0300 +#define OMAP4430_CM1_TESLA_MOD 0x0400 +#define OMAP4430_CM1_ABE_MOD 0x0500 +#define OMAP4430_CM1_RESTORE_MOD 0x0e00 +#define OMAP4430_CM1_INSTR_MOD 0x0f00 + +/* CM2 instances */ + +#define OMAP4430_CM2_OCP_SOCKET_MOD0x +#define OMAP4430_CM2_CKGEN_MOD 0x0100 +#define OMAP4430_CM2_ALWAYS_ON_MOD 0x0600 +#define OMAP4430_CM2_CORE_MOD 0x0700 +#define OMAP4430_CM2_IVAHD_MOD 0x0f00 +#define OMAP4430_CM2_CAM_MOD 0x1000 +#define OMAP4430_CM2_DSS_MOD 0x1100 +#define OMAP4430_CM2_GFX_MOD 0x1200 +#define OMAP4430_CM2_L3INIT_MOD0x1300 +#define OMAP4430_CM2_L4PER_MOD 0x1400 +#define OMAP4430_CM2_CEFUSE_MOD0x1600 +#define OMAP4430_CM2_RESTORE_MOD 0x1e00 +#define OMAP4430_CM2_INSTR_MOD 0x1f00 + +/* PRM instances */ + +#define OMAP4430_PRM_OCP_SOCKET_MOD0x +#define OMAP4430_PRM_CKGEN_MOD 0x0100 +#define OMAP4430_PRM_MPU_MOD 0x0300 +#define OMAP4430_PRM_TESLA_MOD 0x0400 +#define OMAP4430_PRM_ABE_MOD 0x0500 +#define OMAP4430_PRM_ALWAYS_ON_MOD 0x0600 +#define OMAP4430_PRM_CORE_MOD 0x0700 +#define OMAP4430_PRM_IVAHD_MOD 0x0f00 +#define OMAP4430_PRM_CAM_MOD 0x1000 +#define OMAP4430_PRM_DSS_MOD 0x1100 +#define OMAP4430_PRM_GFX_MOD 0x1200 +#define OMAP4430_PRM_L3INIT_MOD0x1300 +#define OMAP4430_PRM_L4PER_MOD 0x1400 +#define OMAP4430_PRM_CEFUSE_MOD0x1600 +#define OMAP4430_PRM_WKUP_MOD 0x1700 +#define OMAP4430_PRM_WKUP_CM_MOD 0x1800 +#define OMAP4430_PRM_EMU_MOD 0x1900 +#define OMAP4430_PRM_EMU_CM_MOD0x1a00 +#define OMAP4430_PRM_DEVICE_MOD0x1b00 +#define OMAP4430_PRM_INSTR_MOD 0x1f00 + +/* SCRM instances */ + +#define OMAP4430_SCRM_SCRM_MOD 0x + +/* CHIRONSS instances */ + +#define OMAP4430_CHIRONSS_CHIRONSS_OCP_SOCKET_PRCM_MOD 0x +#define OMAP4430_CHIRONSS_CHIRONSS_DEVICE_PRM_MOD 0x0200 +#define OMAP4430_CHIRONSS_CHIRONSS_CPU0_MOD0x0400 +#define OMAP4430_CHIRONSS_CHIRONSS_CPU1_MOD0x0800 /* 24XX register bits shared between CM PRM registers */ -- 1.5.4.7 -- 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 v2 5/6] ARM: OMAP4: PM: Adds CM1/2 register defs for OMAP4
This patch adds OMAP4 specific CM1 and CM2 module register defs. Autogenerated using a python scripts (gen_cm1_4430_h.py,gen_cm2_4430_h.py) developed by Paul Walmsley and Benoit Cousson. Signed-off-by: Rajendra Nayak rna...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Benoit Cousson b-cous...@ti.com --- arch/arm/mach-omap2/cm.h | 11 +- arch/arm/mach-omap2/cm44xx.h | 358 ++ 2 files changed, 367 insertions(+), 2 deletions(-) create mode 100644 arch/arm/mach-omap2/cm44xx.h diff --git a/arch/arm/mach-omap2/cm.h b/arch/arm/mach-omap2/cm.h index a2fcfcc..e8814a6 100644 --- a/arch/arm/mach-omap2/cm.h +++ b/arch/arm/mach-omap2/cm.h @@ -4,8 +4,8 @@ /* * OMAP2/3 Clock Management (CM) register definitions * - * Copyright (C) 2007-2008 Texas Instruments, Inc. - * Copyright (C) 2007-2008 Nokia Corporation + * Copyright (C) 2007-2009 Texas Instruments, Inc. + * Copyright (C) 2007-2009 Nokia Corporation * * Written by Paul Walmsley * @@ -22,6 +22,12 @@ OMAP2_L4_IO_ADDRESS(OMAP2430_CM_BASE + (module) + (reg)) #define OMAP34XX_CM_REGADDR(module, reg) \ OMAP2_L4_IO_ADDRESS(OMAP3430_CM_BASE + (module) + (reg)) +#define OMAP44XX_CM1_REGADDR(module, reg) \ + OMAP2_L4_IO_ADDRESS(OMAP4430_CM1_BASE + (module) + (reg)) +#define OMAP44XX_CM2_REGADDR(module, reg) \ + OMAP2_L4_IO_ADDRESS(OMAP4430_CM2_BASE + (module) + (reg)) + +#include cm44xx.h /* * Architecture-specific global CM registers @@ -89,6 +95,7 @@ #define OMAP3430_CM_CLKSEL2_EMU0x0050 #define OMAP3430_CM_CLKSEL3_EMU0x0054 +/* CM2.CEFUSE_CM2 register offsets */ /* Clock management domain register get/set */ diff --git a/arch/arm/mach-omap2/cm44xx.h b/arch/arm/mach-omap2/cm44xx.h new file mode 100644 index 000..c575b9b --- /dev/null +++ b/arch/arm/mach-omap2/cm44xx.h @@ -0,0 +1,358 @@ +/* + * OMAP44xx CM1 CM2 instance offset macros + * + * Copyright (C) 2009 Texas Instruments, Inc. + * Copyright (C) 2009 Nokia Corporation + * + * Paul Walmsley (p...@pwsan.com) + * Rajendra Nayak (rna...@ti.com) + * Benoit Cousson (b-cous...@ti.com) + * + * This file is automatically generated from the OMAP hardware databases. + * We respectfully ask that any modifications to this file be coordinated + * with the public linux-omap@vger.kernel.org mailing list and the + * authors above to ensure that the autogeneration scripts are kept + * up-to-date with the file contents. + * + * 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 __ARCH_ARM_MACH_OMAP2_CM44XX_H +#define __ARCH_ARM_MACH_OMAP2_CM44XX_H + + +/* CM1 */ + + +/* CM1.OCP_SOCKET_CM1 register offsets */ +#define OMAP4430_REVISION_CM1 OMAP44XX_CM1_REGADDR(OMAP4430_CM1_OCP_SOCKET_MOD, 0x) +#define OMAP4430_CM_CM1_PROFILING_CLKCTRL OMAP44XX_CM1_REGADDR(OMAP4430_CM1_OCP_SOCKET_MOD, 0x0040) + +/* CM1.CKGEN_CM1 register offsets */ +#define OMAP4430_CM_CLKSEL_CORE OMAP44XX_CM1_REGADDR(OMAP4430_CM1_CKGEN_MOD, 0x) +#define OMAP4430_CM_CLKSEL_ABE OMAP44XX_CM1_REGADDR(OMAP4430_CM1_CKGEN_MOD, 0x0008) +#define OMAP4430_CM_DLL_CTRL OMAP44XX_CM1_REGADDR(OMAP4430_CM1_CKGEN_MOD, 0x0010) +#define OMAP4430_CM_CLKMODE_DPLL_CORE OMAP44XX_CM1_REGADDR(OMAP4430_CM1_CKGEN_MOD, 0x0020) +#define OMAP4430_CM_IDLEST_DPLL_CORE OMAP44XX_CM1_REGADDR(OMAP4430_CM1_CKGEN_MOD, 0x0024) +#define OMAP4430_CM_AUTOIDLE_DPLL_CORE OMAP44XX_CM1_REGADDR(OMAP4430_CM1_CKGEN_MOD, 0x0028) +#define OMAP4430_CM_CLKSEL_DPLL_CORE OMAP44XX_CM1_REGADDR(OMAP4430_CM1_CKGEN_MOD, 0x002c) +#define OMAP4430_CM_DIV_M2_DPLL_CORE OMAP44XX_CM1_REGADDR(OMAP4430_CM1_CKGEN_MOD, 0x0030) +#define OMAP4430_CM_DIV_M3_DPLL_CORE OMAP44XX_CM1_REGADDR(OMAP4430_CM1_CKGEN_MOD, 0x0034) +#define OMAP4430_CM_DIV_M4_DPLL_CORE OMAP44XX_CM1_REGADDR(OMAP4430_CM1_CKGEN_MOD, 0x0038) +#define OMAP4430_CM_DIV_M5_DPLL_CORE OMAP44XX_CM1_REGADDR(OMAP4430_CM1_CKGEN_MOD, 0x003c) +#define OMAP4430_CM_DIV_M6_DPLL_CORE OMAP44XX_CM1_REGADDR(OMAP4430_CM1_CKGEN_MOD, 0x0040) +#define OMAP4430_CM_DIV_M7_DPLL_CORE OMAP44XX_CM1_REGADDR(OMAP4430_CM1_CKGEN_MOD, 0x0044) +#define OMAP4430_CM_SSC_DELTAMSTEP_DPLL_CORE OMAP44XX_CM1_REGADDR(OMAP4430_CM1_CKGEN_MOD, 0x0048) +#define OMAP4430_CM_SSC_MODFREQDIV_DPLL_CORE OMAP44XX_CM1_REGADDR(OMAP4430_CM1_CKGEN_MOD, 0x004c) +#define OMAP4430_CM_EMU_OVERRIDE_DPLL_CORE
[PATCH v2 3/6] ARM: OMAP4: PM: Adds PRM register defs for OMAP4
This patch adds OMAP4 specific PRM register defs. Auto generated using a python script (gen_prm_4430_h.py) developed by Paul Walmsley and Benoit Cousson. Signed-off-by: Rajendra Nayak rna...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Benoit Cousson b-cous...@ti.com --- arch/arm/mach-omap2/prm.h |8 +- arch/arm/mach-omap2/prm44xx.h | 411 + 2 files changed, 417 insertions(+), 2 deletions(-) create mode 100644 arch/arm/mach-omap2/prm44xx.h diff --git a/arch/arm/mach-omap2/prm.h b/arch/arm/mach-omap2/prm.h index a117f85..ea050ce 100644 --- a/arch/arm/mach-omap2/prm.h +++ b/arch/arm/mach-omap2/prm.h @@ -4,8 +4,8 @@ /* * OMAP2/3 Power/Reset Management (PRM) register definitions * - * Copyright (C) 2007 Texas Instruments, Inc. - * Copyright (C) 2007 Nokia Corporation + * Copyright (C) 2007-2009 Texas Instruments, Inc. + * Copyright (C) 2009 Nokia Corporation * * Written by Paul Walmsley * @@ -22,6 +22,10 @@ OMAP2_L4_IO_ADDRESS(OMAP2430_PRM_BASE + (module) + (reg)) #define OMAP34XX_PRM_REGADDR(module, reg) \ OMAP2_L4_IO_ADDRESS(OMAP3430_PRM_BASE + (module) + (reg)) +#define OMAP44XX_PRM_REGADDR(module, reg) \ + OMAP2_L4_IO_ADDRESS(OMAP4430_PRM_BASE + (module) + (reg)) + +#include prm44xx.h /* * Architecture-specific global PRM registers diff --git a/arch/arm/mach-omap2/prm44xx.h b/arch/arm/mach-omap2/prm44xx.h new file mode 100644 index 000..89be97f --- /dev/null +++ b/arch/arm/mach-omap2/prm44xx.h @@ -0,0 +1,411 @@ +/* + * OMAP44xx PRM instance offset macros + * + * Copyright (C) 2009 Texas Instruments, Inc. + * Copyright (C) 2009 Nokia Corporation + * + * Paul Walmsley (p...@pwsan.com) + * Rajendra Nayak (rna...@ti.com) + * Benoit Cousson (b-cous...@ti.com) + * + * This file is automatically generated from the OMAP hardware databases. + * We respectfully ask that any modifications to this file be coordinated + * with the public linux-omap@vger.kernel.org mailing list and the + * authors above to ensure that the autogeneration scripts are kept + * up-to-date with the file contents. + * + * 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 __ARCH_ARM_MACH_OMAP2_PRM44XX_H +#define __ARCH_ARM_MACH_OMAP2_PRM44XX_H + + +/* PRM */ + + +/* PRM.OCP_SOCKET_PRM register offsets */ +#define OMAP4430_REVISION_PRM OMAP44XX_PRM_REGADDR(OMAP4430_PRM_OCP_SOCKET_MOD, 0x) +#define OMAP4430_PRM_IRQSTATUS_MPU OMAP44XX_PRM_REGADDR(OMAP4430_PRM_OCP_SOCKET_MOD, 0x0010) +#define OMAP4430_PRM_IRQSTATUS_MPU_2 OMAP44XX_PRM_REGADDR(OMAP4430_PRM_OCP_SOCKET_MOD, 0x0014) +#define OMAP4430_PRM_IRQENABLE_MPU OMAP44XX_PRM_REGADDR(OMAP4430_PRM_OCP_SOCKET_MOD, 0x0018) +#define OMAP4430_PRM_IRQENABLE_MPU_2 OMAP44XX_PRM_REGADDR(OMAP4430_PRM_OCP_SOCKET_MOD, 0x001c) +#define OMAP4430_PRM_IRQSTATUS_DUCATI OMAP44XX_PRM_REGADDR(OMAP4430_PRM_OCP_SOCKET_MOD, 0x0020) +#define OMAP4430_PRM_IRQENABLE_DUCATI OMAP44XX_PRM_REGADDR(OMAP4430_PRM_OCP_SOCKET_MOD, 0x0028) +#define OMAP4430_PRM_IRQSTATUS_TESLA OMAP44XX_PRM_REGADDR(OMAP4430_PRM_OCP_SOCKET_MOD, 0x0030) +#define OMAP4430_PRM_IRQENABLE_TESLA OMAP44XX_PRM_REGADDR(OMAP4430_PRM_OCP_SOCKET_MOD, 0x0038) +#define OMAP4430_PRM_PRM_PROFILING_CLKCTRL OMAP44XX_PRM_REGADDR(OMAP4430_PRM_OCP_SOCKET_MOD, 0x0040) + +/* PRM.CKGEN_PRM register offsets */ +#define OMAP4430_CM_ABE_DSS_SYS_CLKSEL OMAP44XX_PRM_REGADDR(OMAP4430_PRM_CKGEN_MOD, 0x) +#define OMAP4430_CM_DPLL_SYS_REF_CLKSEL OMAP44XX_PRM_REGADDR(OMAP4430_PRM_CKGEN_MOD, 0x0004) +#define OMAP4430_CM_L4_WKUP_CLKSEL OMAP44XX_PRM_REGADDR(OMAP4430_PRM_CKGEN_MOD, 0x0008) +#define OMAP4430_CM_ABE_PLL_REF_CLKSEL OMAP44XX_PRM_REGADDR(OMAP4430_PRM_CKGEN_MOD, 0x000c) +#define OMAP4430_CM_SYS_CLKSEL OMAP44XX_PRM_REGADDR(OMAP4430_PRM_CKGEN_MOD, 0x0010) + +/* PRM.MPU_PRM register offsets */ +#define OMAP4430_PM_MPU_PWRSTCTRL OMAP44XX_PRM_REGADDR(OMAP4430_PRM_MPU_MOD, 0x) +#define OMAP4430_PM_MPU_PWRSTST OMAP44XX_PRM_REGADDR(OMAP4430_PRM_MPU_MOD, 0x0004) +#define OMAP4430_RM_MPU_RSTST OMAP44XX_PRM_REGADDR(OMAP4430_PRM_MPU_MOD, 0x0014) +#define OMAP4430_RM_MPU_MPU_CONTEXT OMAP44XX_PRM_REGADDR(OMAP4430_PRM_MPU_MOD, 0x0024) + +/* PRM.TESLA_PRM register offsets */ +#define OMAP4430_PM_TESLA_PWRSTCTRL OMAP44XX_PRM_REGADDR(OMAP4430_PRM_TESLA_MOD, 0x) +#define OMAP4430_PM_TESLA_PWRSTST
[PATCH 0/2] OMAP: use physmap-flash
There is nothing special on omapflash driver, so it can be replaced with physmap-flash. First patch in serie does exactly this and second one removes drivers/mtd/maps/omap_nor.c and associated Kconfig option. I'd like to have either ack or merge into mtd git tree by mtd maintainers for that second part. arch/arm/mach-omap1/flash.c | 33 ++ arch/arm/plat-omap/include/plat/flash.h | 16 + arch/arm/mach-omap1/Makefile |2 arch/arm/mach-omap1/board-fsample.c |9 arch/arm/mach-omap1/board-h2.c |9 arch/arm/mach-omap1/board-h3.c |9 arch/arm/mach-omap1/board-innovator.c|9 arch/arm/mach-omap1/board-osk.c |9 arch/arm/mach-omap1/board-palmte.c |9 arch/arm/mach-omap1/board-palmtt.c |9 arch/arm/mach-omap1/board-palmz71.c | 10 arch/arm/mach-omap1/board-perseus2.c |9 arch/arm/mach-omap1/board-sx1.c | 11 arch/arm/mach-omap1/board-voiceblue.c|9 arch/arm/mach-omap2/board-2430sdp.c |7 arch/arm/mach-omap2/board-h4.c |7 drivers/mtd/maps/Kconfig |9 drivers/mtd/maps/Makefile|1 drivers/mtd/maps/omap_nor.c | 188 - 19 files changed, 112 insertions(+), 253 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 1/2] OMAP: convert boards to use physmap-flash
Convert OMAP based boards to use physmap-flash.
Signed-off-by: Ladislav Michl la...@linux-mips.org
--- /dev/null 2009-12-08 14:04:43.543715066 +0100
+++ linux-omap-2.6/arch/arm/plat-omap/include/plat/flash.h 2009-12-08
18:53:34.0 +0100
@@ -0,0 +1,16 @@
+/*
+ * Flash support for OMAP1
+ *
+ * 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 __OMAP_FLASH_H
+#define __OMAP_FLASH_H
+
+#include linux/mtd/map.h
+
+extern void omap1_set_vpp(struct map_info *map, int enable);
+
+#endif
--- /dev/null 2009-12-08 14:04:43.543715066 +0100
+++ linux-omap-2.6/arch/arm/mach-omap1/flash.c 2009-12-08 18:45:16.0
+0100
@@ -0,0 +1,33 @@
+/*
+ * Flash support for OMAP1
+ *
+ * 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.
+ */
+
+#include linux/mtd/mtd.h
+#include linux/mtd/map.h
+
+#include plat/io.h
+#include plat/tc.h
+
+void omap1_set_vpp(struct map_info *map, int enable)
+{
+ static int count;
+ u32 l;
+
+ if (enable) {
+ if (count++ == 0) {
+ l = omap_readl(EMIFS_CONFIG);
+ l |= OMAP_EMIFS_CONFIG_WP;
+ omap_writel(l, EMIFS_CONFIG);
+ }
+ } else {
+ if (count (--count == 0)) {
+ l = omap_readl(EMIFS_CONFIG);
+ l = ~OMAP_EMIFS_CONFIG_WP;
+ omap_writel(l, EMIFS_CONFIG);
+ }
+ }
+}
diff --git a/arch/arm/mach-omap1/Makefile b/arch/arm/mach-omap1/Makefile
index 87e539a..c5c1360 100644
--- a/arch/arm/mach-omap1/Makefile
+++ b/arch/arm/mach-omap1/Makefile
@@ -3,7 +3,7 @@
#
# Common support
-obj-y := io.o id.o sram.o clock.o irq.o mux.o serial.o devices.o
+obj-y := io.o id.o sram.o clock.o irq.o mux.o serial.o flash.o devices.o
obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
diff --git a/arch/arm/mach-omap1/board-fsample.c
b/arch/arm/mach-omap1/board-fsample.c
index f4b72c1..6b681d1 100644
--- a/arch/arm/mach-omap1/board-fsample.c
+++ b/arch/arm/mach-omap1/board-fsample.c
@@ -18,18 +18,19 @@
#include linux/mtd/mtd.h
#include linux/mtd/nand.h
#include linux/mtd/partitions.h
+#include linux/mtd/physmap.h
#include linux/input.h
#include mach/hardware.h
#include asm/mach-types.h
#include asm/mach/arch.h
-#include asm/mach/flash.h
#include asm/mach/map.h
#include plat/tc.h
#include mach/gpio.h
#include plat/mux.h
#include plat/fpga.h
+#include plat/flash.h
#include plat/nand.h
#include plat/keypad.h
#include plat/common.h
@@ -144,9 +145,9 @@ static struct mtd_partition nor_partitions[] = {
},
};
-static struct flash_platform_data nor_data = {
- .map_name = cfi_probe,
+static struct physmap_flash_data nor_data = {
.width = 2,
+ .set_vpp= omap1_set_vpp,
.parts = nor_partitions,
.nr_parts = ARRAY_SIZE(nor_partitions),
};
@@ -158,7 +159,7 @@ static struct resource nor_resource = {
};
static struct platform_device nor_device = {
- .name = omapflash,
+ .name = physmap-flash,
.id = 0,
.dev= {
.platform_data = nor_data,
diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
index 89ba8ec..3e7200e 100644
--- a/arch/arm/mach-omap1/board-h2.c
+++ b/arch/arm/mach-omap1/board-h2.c
@@ -26,6 +26,7 @@
#include linux/mtd/mtd.h
#include linux/mtd/nand.h
#include linux/mtd/partitions.h
+#include linux/mtd/physmap.h
#include linux/input.h
#include linux/i2c/tps65010.h
@@ -34,12 +35,12 @@
#include asm/mach-types.h
#include asm/mach/arch.h
-#include asm/mach/flash.h
#include asm/mach/map.h
#include plat/mux.h
#include plat/dma.h
#include plat/tc.h
+#include plat/flash.h
#include plat/nand.h
#include plat/irda.h
#include plat/usb.h
@@ -121,9 +122,9 @@ static struct mtd_partition h2_nor_partitions[] = {
}
};
-static struct flash_platform_data h2_nor_data = {
- .map_name = cfi_probe,
+static struct physmap_flash_data h2_nor_data = {
.width = 2,
+ .set_vpp= omap1_set_vpp,
.parts = h2_nor_partitions,
.nr_parts = ARRAY_SIZE(h2_nor_partitions),
};
@@ -134,7 +135,7 @@ static struct resource h2_nor_resource = {
};
static struct platform_device h2_nor_device = {
- .name = omapflash,
+ .name = physmap-flash,
.id = 0,
.dev= {
.platform_data = h2_nor_data,
diff --git a/arch/arm/mach-omap1/board-h3.c b/arch/arm/mach-omap1/board-h3.c
index f5cc0a7..8a99a7c 100644
--- a/arch/arm/mach-omap1/board-h3.c
+++
[PATCH 2/2] MTD: remove no longer used OMAP flash map
All OMAP boards are now using physmap-flash.
Signed-off-by: Ladislav Michl la...@linux-mips.org
diff --git a/drivers/mtd/maps/Kconfig b/drivers/mtd/maps/Kconfig
index 14be075..c165a27 100644
--- a/drivers/mtd/maps/Kconfig
+++ b/drivers/mtd/maps/Kconfig
@@ -436,15 +436,6 @@ config MTD_H720X
This enables access to the flash chips on the Hynix evaluation boards.
If you have such a board, say 'Y'.
-config MTD_OMAP_NOR
- tristate TI OMAP board mappings
- depends on MTD_CFI ARCH_OMAP
- help
- This enables access to the NOR flash chips on TI OMAP-based
- boards defining flash platform devices and flash platform data.
- These boards include the Innovator, H2, H3, OSK, Perseus2, and
- more. If you have such a board, say 'Y'.
-
# This needs CFI or JEDEC, depending on the cards found.
config MTD_PCI
tristate PCI MTD driver
diff --git a/drivers/mtd/maps/Makefile b/drivers/mtd/maps/Makefile
index ae2f6db..ef11888 100644
--- a/drivers/mtd/maps/Makefile
+++ b/drivers/mtd/maps/Makefile
@@ -55,7 +55,6 @@ obj-$(CONFIG_MTD_IXP2000) += ixp2000.o
obj-$(CONFIG_MTD_WRSBC8260)+= wr_sbc82xx_flash.o
obj-$(CONFIG_MTD_DMV182) += dmv182.o
obj-$(CONFIG_MTD_PLATRAM) += plat-ram.o
-obj-$(CONFIG_MTD_OMAP_NOR) += omap_nor.o
obj-$(CONFIG_MTD_INTEL_VR_NOR) += intel_vr_nor.o
obj-$(CONFIG_MTD_BFIN_ASYNC) += bfin-async-flash.o
obj-$(CONFIG_MTD_RBTX4939) += rbtx4939-flash.o
--- a/drivers/mtd/maps/omap_nor.c 2009-10-20 13:04:52.0 +0200
+++ b/drivers/mtd/maps/omap_nor.c 2009-12-08 14:04:43.543715066 +0100
@@ -1,188 +0,0 @@
-/*
- * Flash memory support for various TI OMAP boards
- *
- * Copyright (C) 2001-2002 MontaVista Software Inc.
- * Copyright (C) 2003-2004 Texas Instruments
- * Copyright (C) 2004 Nokia Corporation
- *
- * Assembled using driver code copyright the companies above
- * and written by David Brownell, Jian Zhang jzh...@ti.com,
- * Tony Lindgren t...@atomide.com and others.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
- *
- * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
- * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
- * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN
- * NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
- * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
- * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
- * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
- * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
- * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
- * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- *
- * You should have received a copy of the GNU General Public License along
- * with this program; if not, write to the Free Software Foundation, Inc.,
- * 675 Mass Ave, Cambridge, MA 02139, USA.
- */
-
-#include linux/platform_device.h
-#include linux/module.h
-#include linux/types.h
-#include linux/kernel.h
-#include linux/init.h
-#include linux/ioport.h
-#include linux/slab.h
-
-#include linux/mtd/mtd.h
-#include linux/mtd/map.h
-#include linux/mtd/partitions.h
-
-#include asm/io.h
-#include mach/hardware.h
-#include asm/mach/flash.h
-#include plat/tc.h
-
-#ifdef CONFIG_MTD_PARTITIONS
-static const char *part_probes[] = { /* RedBoot, */ cmdlinepart, NULL };
-#endif
-
-struct omapflash_info {
- struct mtd_partition*parts;
- struct mtd_info *mtd;
- struct map_info map;
-};
-
-static void omap_set_vpp(struct map_info *map, int enable)
-{
- static int count;
- u32 l;
-
- if (cpu_class_is_omap1()) {
- if (enable) {
- if (count++ == 0) {
- l = omap_readl(EMIFS_CONFIG);
- l |= OMAP_EMIFS_CONFIG_WP;
- omap_writel(l, EMIFS_CONFIG);
- }
- } else {
- if (count (--count == 0)) {
- l = omap_readl(EMIFS_CONFIG);
- l = ~OMAP_EMIFS_CONFIG_WP;
- omap_writel(l, EMIFS_CONFIG);
- }
- }
- }
-}
-
-static int __init omapflash_probe(struct platform_device *pdev)
-{
- int err;
- struct omapflash_info *info;
- struct flash_platform_data *pdata = pdev-dev.platform_data;
- struct resource *res = pdev-resource;
- unsigned long size = res-end - res-start + 1;
-
- info = kzalloc(sizeof(struct omapflash_info), GFP_KERNEL);
- if (!info)
-
[PATCH v2 0/5] OMAP4 clock framework support
Hi, This patch series adds support for OMAP4 clock framework and models all clock nodes in PRM/CM1/CM2 modules and also models all the DPLL nodes. This series has a dependency on [1],[2] and can be applied on top of the latest mainline kernel. This series is tested on the OMAP4 simulator platform as well the omap4430sdp based on ES1.0 silicon. These patches are also boot tested on omap3430sdp and compile tested for h4 and 2420. The complete omap4 clock tree and clkdev table (clock44xx_data.c) is autogenerated using OMAP4 hardware database and is a joint effort of Paul Walmsley (p...@pwsan.com), Benoit Cousson (b-cous...@ti.com) and me. regards, Rajendra [1]: http://marc.info/?l=linux-omapm=126029617123185w=2 [2]: http://marc.info/?l=linux-omapm=126019069331368w=2 Rajendra Nayak (5): ARM: OMAP4: PM: OMAP4 clock tree and clkdev registration ARM: OMAP4: PM: Add dummy hooks for OMAP4 dpll api's ARM: OMAP4: PM: Move DPLL control apis to dpll.c ARM: OMAP4: PM: Add support for OMAP4 dpll api's ARM: OMAP4: PM: Add init api for DPLL nodes -- 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 v2 2/5] ARM: OMAP4: PM: Add dummy hooks for OMAP4 dpll api's
This patch adds dummy hooks for OMAP4 dpll api's. Removes
dummy hooks for clkdev api's and enables CLKDEV
for OMAP4.
Also comments clockdomain calls from within the clock
framework as its not supported yet for OMAP4.
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/Makefile|3 +-
arch/arm/mach-omap2/clock.c |8 +
arch/arm/mach-omap2/clock44xx.c | 58 +++
arch/arm/mach-omap2/cm.h|4 +++
arch/arm/mach-omap2/gpmc.c |2 +-
arch/arm/mach-omap2/io.c|4 +--
arch/arm/plat-omap/Kconfig |1 +
arch/arm/plat-omap/clock.c | 21 --
8 files changed, 75 insertions(+), 26 deletions(-)
create mode 100644 arch/arm/mach-omap2/clock44xx.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 284277e..e3743cf 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -11,7 +11,7 @@ clock-common = clock.o
clock_common_data.o clockdomain.o
obj-$(CONFIG_ARCH_OMAP2) += $(omap-2-3-common) $(prcm-common) $(clock-common)
obj-$(CONFIG_ARCH_OMAP3) += $(omap-2-3-common) $(prcm-common) $(clock-common)
-obj-$(CONFIG_ARCH_OMAP4) += prcm.o
+obj-$(CONFIG_ARCH_OMAP4) += prcm.o clock.o
obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
@@ -49,6 +49,7 @@ obj-$(CONFIG_ARCH_OMAP2) += clock2xxx.o
clock2xxx_data.o
obj-$(CONFIG_ARCH_OMAP2420)+= opp2420_data.o
obj-$(CONFIG_ARCH_OMAP3) += clock34xx.o clock34xx_data.o
obj-$(CONFIG_ARCH_OMAP2430)+= opp2430_data.o
+obj-$(CONFIG_ARCH_OMAP4) += clock44xx.o clock44xx_data.o
obj-$(CONFIG_OMAP_MBOX_FWK)+= mailbox_mach.o
mailbox_mach-objs := mailbox.o
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index 4716206..5cb2dcb 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -149,6 +149,7 @@ static int _dpll_test_fint(struct clk *clk, u8 n)
* clockdomain pointer, and save it into the struct clk. Intended to be
* called during clk_register(). No return value.
*/
+#ifndef CONFIG_ARCH_OMAP4 /* FIXME: Remove this once clkdm f/w is in place */
void omap2_init_clk_clkdm(struct clk *clk)
{
struct clockdomain *clkdm;
@@ -166,6 +167,7 @@ void omap2_init_clk_clkdm(struct clk *clk)
clkdm %s\n, clk-name, clk-clkdm_name);
}
}
+#endif
/**
* omap2_init_clksel_parent - set a clksel clk's parent field from the hardware
@@ -437,8 +439,10 @@ void omap2_clk_disable(struct clk *clk)
_omap2_clk_disable(clk);
if (clk-parent)
omap2_clk_disable(clk-parent);
+#ifndef CONFIG_ARCH_OMAP4 /* FIXME: Remove this once clkdm f/w is in place */
if (clk-clkdm)
omap2_clkdm_clk_disable(clk-clkdm, clk);
+#endif
}
}
@@ -448,8 +452,10 @@ int omap2_clk_enable(struct clk *clk)
int ret = 0;
if (clk-usecount++ == 0) {
+#ifndef CONFIG_ARCH_OMAP4 /* FIXME: Remove this once clkdm f/w is in place */
if (clk-clkdm)
omap2_clkdm_clk_enable(clk-clkdm, clk);
+#endif
if (clk-parent) {
ret = omap2_clk_enable(clk-parent);
@@ -468,8 +474,10 @@ int omap2_clk_enable(struct clk *clk)
return ret;
err:
+#ifndef CONFIG_ARCH_OMAP4 /* FIXME: Remove this once clkdm f/w is in place */
if (clk-clkdm)
omap2_clkdm_clk_disable(clk-clkdm, clk);
+#endif
clk-usecount--;
return ret;
}
diff --git a/arch/arm/mach-omap2/clock44xx.c b/arch/arm/mach-omap2/clock44xx.c
new file mode 100644
index 000..5b25d38
--- /dev/null
+++ b/arch/arm/mach-omap2/clock44xx.c
@@ -0,0 +1,58 @@
+/*
+ * OMAP4-specific clock framework functions
+ *
+ * Copyright (C) 2009 Texas Instruments, Inc.
+ *
+ * Rajendra Nayak (rna...@ti.com)
+ *
+ * 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.
+ */
+
+#include linux/errno.h
+#include clock.h
+
+struct clk_functions omap2_clk_functions = {
+ .clk_enable = omap2_clk_enable,
+ .clk_disable= omap2_clk_disable,
+ .clk_round_rate = omap2_clk_round_rate,
+ .clk_set_rate = omap2_clk_set_rate,
+ .clk_set_parent = omap2_clk_set_parent,
+ .clk_disable_unused = omap2_clk_disable_unused,
+};
+
+/*
+ * Dummy functions for DPLL control. Plan is to re-use
+ * existing OMAP3 dpll control functions.
+ */
+
+unsigned long omap3_dpll_recalc(struct clk *clk)
+{
+ return 0;
+}
+
+int omap3_noncore_dpll_set_rate(struct clk *clk, unsigned long rate)
+{
+ return 0;
+}
+
+int omap3_noncore_dpll_enable(struct clk *clk)
+{
+
[PATCH v2 3/5] ARM: OMAP4: PM: Move DPLL control apis to dpll.c
This patch moves all the dpll control api's to a
common file dpll.c. This is in preperation of omap4
support wherein most of these api's can be reused.
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/Makefile|3 +-
arch/arm/mach-omap2/clock.h | 13 +
arch/arm/mach-omap2/clock34xx.c | 489 ---
arch/arm/mach-omap2/clock34xx.h | 11 -
arch/arm/mach-omap2/clock44xx.h |8 -
arch/arm/mach-omap2/dpll.c | 532 +++
6 files changed, 547 insertions(+), 509 deletions(-)
create mode 100644 arch/arm/mach-omap2/dpll.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index e3743cf..e5946c1 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -10,7 +10,8 @@ prcm-common = prcm.o powerdomain.o
clock-common = clock.o clock_common_data.o
clockdomain.o
obj-$(CONFIG_ARCH_OMAP2) += $(omap-2-3-common) $(prcm-common) $(clock-common)
-obj-$(CONFIG_ARCH_OMAP3) += $(omap-2-3-common) $(prcm-common) $(clock-common)
+obj-$(CONFIG_ARCH_OMAP3) += $(omap-2-3-common) $(prcm-common) $(clock-common) \
+ dpll.o
obj-$(CONFIG_ARCH_OMAP4) += prcm.o clock.o
obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index 87c0805..4df7aa4 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -36,6 +36,11 @@
#define OMAP3XXX_EN_DPLL_FRBYPASS 0x6
#define OMAP3XXX_EN_DPLL_LOCKED0x7
+/* CM_CLKEN_PLL*.EN* bit values - not all are available for every DPLL */
+#define DPLL_LOW_POWER_STOP0x1
+#define DPLL_LOW_POWER_BYPASS 0x5
+#define DPLL_LOCKED0x7
+
int omap2_clk_init(void);
int omap2_clk_enable(struct clk *clk);
void omap2_clk_disable(struct clk *clk);
@@ -44,6 +49,14 @@ int omap2_clk_set_rate(struct clk *clk, unsigned long rate);
int omap2_clk_set_parent(struct clk *clk, struct clk *new_parent);
int omap2_dpll_set_rate_tolerance(struct clk *clk, unsigned int tolerance);
long omap2_dpll_round_rate(struct clk *clk, unsigned long target_rate);
+unsigned long omap3_dpll_recalc(struct clk *clk);
+unsigned long omap3_clkoutx2_recalc(struct clk *clk);
+void omap3_dpll_allow_idle(struct clk *clk);
+void omap3_dpll_deny_idle(struct clk *clk);
+u32 omap3_dpll_autoidle_read(struct clk *clk);
+int omap3_noncore_dpll_set_rate(struct clk *clk, unsigned long rate);
+int omap3_noncore_dpll_enable(struct clk *clk);
+void omap3_noncore_dpll_disable(struct clk *clk);
#ifdef CONFIG_OMAP_RESET_CLOCKS
void omap2_clk_disable_unused(struct clk *clk);
diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
index 7dffbfc..d4217b9 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -42,12 +42,6 @@
#include cm.h
#include cm-regbits-34xx.h
-/* CM_AUTOIDLE_PLL*.AUTO_* bit values */
-#define DPLL_AUTOIDLE_DISABLE 0x0
-#define DPLL_AUTOIDLE_LOW_POWER_STOP 0x1
-
-#define MAX_DPLL_WAIT_TRIES100
-
#define CYCLES_PER_MHZ 100
/*
@@ -148,376 +142,11 @@ const struct clkops clkops_omap3430es2_hsotgusb_wait = {
.find_companion = omap2_clk_dflt_find_companion,
};
-/**
- * omap3_dpll_recalc - recalculate DPLL rate
- * @clk: DPLL struct clk
- *
- * Recalculate and propagate the DPLL rate.
- */
-unsigned long omap3_dpll_recalc(struct clk *clk)
-{
- return omap2_get_dpll_rate(clk);
-}
-
-/* _omap3_dpll_write_clken - write clken_bits arg to a DPLL's enable bits */
-static void _omap3_dpll_write_clken(struct clk *clk, u8 clken_bits)
-{
- const struct dpll_data *dd;
- u32 v;
-
- dd = clk-dpll_data;
-
- v = __raw_readl(dd-control_reg);
- v = ~dd-enable_mask;
- v |= clken_bits __ffs(dd-enable_mask);
- __raw_writel(v, dd-control_reg);
-}
-
-/* _omap3_wait_dpll_status: wait for a DPLL to enter a specific state */
-static int _omap3_wait_dpll_status(struct clk *clk, u8 state)
-{
- const struct dpll_data *dd;
- int i = 0;
- int ret = -EINVAL;
-
- dd = clk-dpll_data;
-
- state = __ffs(dd-idlest_mask);
-
- while (((__raw_readl(dd-idlest_reg) dd-idlest_mask) != state)
- i MAX_DPLL_WAIT_TRIES) {
- i++;
- udelay(1);
- }
-
- if (i == MAX_DPLL_WAIT_TRIES) {
- printk(KERN_ERR clock: %s failed transition to '%s'\n,
- clk-name, (state) ? locked : bypassed);
- } else {
- pr_debug(clock: %s transition to '%s' in %d loops\n,
-clk-name, (state) ? locked : bypassed, i);
-
- ret = 0;
- }
-
- return ret;
-}
-
-/* From 3430 TRM ES2 4.7.6.2 */
-static u16 _omap3_dpll_compute_freqsel(struct
[PATCH v2 4/5] ARM: OMAP4: PM: Add support for OMAP4 dpll api's
Most of the dpll api's from dpll.c are reused for OMAP4.
This patch does extend a few api's for OMAP4 support.
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/Makefile|5 +++--
arch/arm/mach-omap2/clock.c |5 +
arch/arm/mach-omap2/clock.h |6 ++
arch/arm/mach-omap2/clock44xx.c | 25 -
arch/arm/mach-omap2/dpll.c | 28 +---
5 files changed, 31 insertions(+), 38 deletions(-)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index e5946c1..6925a78 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -6,13 +6,14 @@
obj-y := id.o io.o control.o mux.o devices.o serial.o gpmc.o timer-gp.o
omap-2-3-common= irq.o sdrc.o omap_hwmod.o
+omap-3-4-common= dpll.o
prcm-common= prcm.o powerdomain.o
clock-common = clock.o clock_common_data.o
clockdomain.o
obj-$(CONFIG_ARCH_OMAP2) += $(omap-2-3-common) $(prcm-common) $(clock-common)
obj-$(CONFIG_ARCH_OMAP3) += $(omap-2-3-common) $(prcm-common) $(clock-common) \
- dpll.o
-obj-$(CONFIG_ARCH_OMAP4) += prcm.o clock.o
+ $(omap-3-4-common)
+obj-$(CONFIG_ARCH_OMAP4) += $(omap-3-4-common) prcm.o clock.o
obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index 5cb2dcb..61ee235 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -249,6 +249,11 @@ u32 omap2_get_dpll_rate(struct clk *clk)
if (v == OMAP3XXX_EN_DPLL_LPBYPASS ||
v == OMAP3XXX_EN_DPLL_FRBYPASS)
return dd-clk_bypass-rate;
+ } else if (cpu_is_omap44xx()) {
+ if (v == OMAP4XXX_EN_DPLL_LPBYPASS ||
+ v == OMAP4XXX_EN_DPLL_FRBYPASS ||
+ v == OMAP4XXX_EN_DPLL_MNBYPASS)
+ return dd-clk_bypass-rate;
}
v = __raw_readl(dd-mult_div1_reg);
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index 4df7aa4..8418f3a 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -36,6 +36,12 @@
#define OMAP3XXX_EN_DPLL_FRBYPASS 0x6
#define OMAP3XXX_EN_DPLL_LOCKED0x7
+/* OMAP4xxx CM_CLKMODE_DPLL*.EN_*_DPLL bits - for omap2_get_dpll_rate() */
+#define OMAP4XXX_EN_DPLL_MNBYPASS 0x4
+#define OMAP4XXX_EN_DPLL_LPBYPASS 0x5
+#define OMAP4XXX_EN_DPLL_FRBYPASS 0x6
+#define OMAP4XXX_EN_DPLL_LOCKED0x7
+
/* CM_CLKEN_PLL*.EN* bit values - not all are available for every DPLL */
#define DPLL_LOW_POWER_STOP0x1
#define DPLL_LOW_POWER_BYPASS 0x5
diff --git a/arch/arm/mach-omap2/clock44xx.c b/arch/arm/mach-omap2/clock44xx.c
index 5b25d38..e370868 100644
--- a/arch/arm/mach-omap2/clock44xx.c
+++ b/arch/arm/mach-omap2/clock44xx.c
@@ -22,31 +22,6 @@ struct clk_functions omap2_clk_functions = {
.clk_disable_unused = omap2_clk_disable_unused,
};
-/*
- * Dummy functions for DPLL control. Plan is to re-use
- * existing OMAP3 dpll control functions.
- */
-
-unsigned long omap3_dpll_recalc(struct clk *clk)
-{
- return 0;
-}
-
-int omap3_noncore_dpll_set_rate(struct clk *clk, unsigned long rate)
-{
- return 0;
-}
-
-int omap3_noncore_dpll_enable(struct clk *clk)
-{
- return 0;
-}
-
-void omap3_noncore_dpll_disable(struct clk *clk)
-{
- return;
-}
-
const struct clkops clkops_noncore_dpll_ops = {
.enable = omap3_noncore_dpll_enable,
.disable= omap3_noncore_dpll_disable,
diff --git a/arch/arm/mach-omap2/dpll.c b/arch/arm/mach-omap2/dpll.c
index d55f8df..36ea1dc 100644
--- a/arch/arm/mach-omap2/dpll.c
+++ b/arch/arm/mach-omap2/dpll.c
@@ -26,9 +26,9 @@
#include linux/limits.h
#include linux/bitops.h
-#include mach/cpu.h
-#include mach/clock.h
-#include mach/sram.h
+#include plat/cpu.h
+#include plat/clock.h
+#include plat/sram.h
#include asm/div64.h
#include asm/clkdev.h
@@ -311,10 +311,12 @@ int omap3_noncore_dpll_program(struct clk *clk, u16 m, u8
n, u16 freqsel)
_omap3_noncore_dpll_bypass(clk);
/* Set jitter correction */
- v = __raw_readl(dd-control_reg);
- v = ~dd-freqsel_mask;
- v |= freqsel __ffs(dd-freqsel_mask);
- __raw_writel(v, dd-control_reg);
+ if (!cpu_is_omap44xx()) {
+ v = __raw_readl(dd-control_reg);
+ v = ~dd-freqsel_mask;
+ v |= freqsel __ffs(dd-freqsel_mask);
+ __raw_writel(v, dd-control_reg);
+ }
/* Set DPLL multiplier, divider */
v = __raw_readl(dd-mult_div1_reg);
@@ -346,7 +348,7 @@ int omap3_noncore_dpll_program(struct clk *clk, u16 m, u8
n, u16 freqsel)
Re: [PATCH 0/2] OMAP: use physmap-flash
* Ladislav Michl ladislav.mi...@seznam.cz [091208 10:20]: There is nothing special on omapflash driver, so it can be replaced with physmap-flash. First patch in serie does exactly this and second one removes drivers/mtd/maps/omap_nor.c and associated Kconfig option. I'd like to have either ack or merge into mtd git tree by mtd maintainers for that second part. Nice work! Ack from me to merge all this via the MTD tree. Acked-by: Tony Lindgren t...@atomide.com arch/arm/mach-omap1/flash.c | 33 ++ arch/arm/plat-omap/include/plat/flash.h | 16 + arch/arm/mach-omap1/Makefile |2 arch/arm/mach-omap1/board-fsample.c |9 arch/arm/mach-omap1/board-h2.c |9 arch/arm/mach-omap1/board-h3.c |9 arch/arm/mach-omap1/board-innovator.c|9 arch/arm/mach-omap1/board-osk.c |9 arch/arm/mach-omap1/board-palmte.c |9 arch/arm/mach-omap1/board-palmtt.c |9 arch/arm/mach-omap1/board-palmz71.c | 10 arch/arm/mach-omap1/board-perseus2.c |9 arch/arm/mach-omap1/board-sx1.c | 11 arch/arm/mach-omap1/board-voiceblue.c|9 arch/arm/mach-omap2/board-2430sdp.c |7 arch/arm/mach-omap2/board-h4.c |7 drivers/mtd/maps/Kconfig |9 drivers/mtd/maps/Makefile|1 drivers/mtd/maps/omap_nor.c | 188 - 19 files changed, 112 insertions(+), 253 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 -- 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 1/2] OMAP3: Enable DSS2 for OMAP3EVM board
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Tomi Valkeinen Sent: Tuesday, November 10, 2009 3:43 PM To: Hiremath, Vaibhav Cc: Tony Lindgren; linux-omap@vger.kernel.org Subject: RE: [PATCH 1/2] OMAP3: Enable DSS2 for OMAP3EVM board On Tue, 2009-11-10 at 04:42 +0100, ext Hiremath, Vaibhav wrote: It's best that we let Tomi queue up all the DSS2 related patches. [Hiremath, Vaibhav] I am ok with that. Let me update this patch with the latest kernel + DSS2 and re- submit it again. Wait until DSS2 patches have been merged. I don't want the extra complexity of board/panel patches, there's enough work with just the half-megabyte DSS patches =). [Hiremath, Vaibhav] Tomi and Tony, Now since DSS2 has already merged to linux-omap/master, I think now we can merge all other dependent patches like, - OMAP3EVM support - Sharp LQ LCD panel - AM3517EVM support - V4L2 Driver support Please let me know your opinion on this, so that I can submit it to the list. Thanks, Vaibhav 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 -- 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
OMAP36xx Public TRM Available Now!
I would like to inform you all of the availability of the OMAP36xx Silicon Rev1.0 Public TRM. Direct Link: http://focus.ti.com/pdfs/wtbu/SWPU177B_FinalEPDF_12_04_2009.pdf (Caution: 42MB PDF) Alternatively you can go to : http://focus.ti.com/general/docs/wtbu/wtbudocumentcenter.tsp?templateId=6123navigationId=12667 And look for OMAP36xx Multimedia Device Silicon Rev 1.0 under Technical Documents section. NOTE: * About every month as needed an updated version of the OMAP36xx TRM will be made available in above alternate location as there are update/fixes to the document. * The OMAP3630 SOM' (System on Module) should be available to open community via LogicPD.com website sometime soon. I will inform you once it's ready. Best Regards, Jayabharath OMAP Process Business Unit, Texas Instruments 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: [RFC][RFT][PATCH 3/4 v6] OMAP: McBSP: Introduce caching in register write operations
Tuesday 08 December 2009 17:59:31 Tony Lindgren napisał(a): * Tony Lindgren t...@atomide.com [091208 08:39]: How about just set the cache size above based on the processor, then do kzalloc here: mcbsp-reg_cache = kzalloc(size, GFP_KERNEL); + if (!mcbsp-reg_cache) + return -ENOMEM; + That way the kzalloc and error checking are in the same place. Actually since we already have mach-omap1/mcbsp.c and mach-omap2/mcbsp.c, it would be best to pass the cache size from omap1_mcbsp_init and omap2_mcbsp_init. That leaves some of the if cpu_is_omap() else stuff. Tony, Almost ready with it, one more question: what do you think about splitting and moving omap_mcbsp_read()/_write() there as well? If you agree, should I submit 2 patches, one with this cleanup, the other one actually introducing cache support, or is one combined OK? Thanks, Janusz -- 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 1/2] OMAP3: Enable DSS2 for OMAP3EVM board
On Wed, Dec 09, 2009 at 12:19:22AM +0530, Hiremath, Vaibhav wrote: Wait until DSS2 patches have been merged. I don't want the extra complexity of board/panel patches, there's enough work with just the half-megabyte DSS patches =). [Hiremath, Vaibhav] Tomi and Tony, Now since DSS2 has already merged to linux-omap/master, I think now we can merge all other dependent patches like, - OMAP3EVM support - Sharp LQ LCD panel - AM3517EVM support - V4L2 Driver support Please let me know your opinion on this, so that I can submit it to the list. linux-omap/master doesn't count. The only place that matters if it's made it to Linus' tree. Don't get me wrong, I want additional patches on top as well but the base work needs to make it _all the way up_. -Olof -- 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 1/2] OMAP3: Enable DSS2 for OMAP3EVM board
On Wed, Dec 09, 2009 at 01:36:57AM +0530, Hiremath, Vaibhav wrote: [Hiremath, Vaibhav] I understand, but if we put the patches on master for whatever period of time available, people can try and validate it. Some people are forward porting the patches (earlier versions submitted) or pinging me for the patches. Let DSS2 alone go in the first slot. Can we use it as a staging here? In a perfect world Tomi would have the staging branch in his tree since he is the maintainer, and Tony would merge that into his master branch for testing. I've been pinging Tomi about my DSS2 patch off-list and he seems to be waiting for DSS2 to be merged before touching any other code, which is a little confusing to me but he's free to run it the way he sees fit. -Olof -- 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 1/2] OMAP3: Enable DSS2 for OMAP3EVM board
-Original Message- From: Olof Johansson [mailto:o...@lixom.net] Sent: Wednesday, December 09, 2009 1:45 AM To: Hiremath, Vaibhav Cc: Tomi Valkeinen; Tony Lindgren; linux-omap@vger.kernel.org Subject: Re: [PATCH 1/2] OMAP3: Enable DSS2 for OMAP3EVM board On Wed, Dec 09, 2009 at 01:36:57AM +0530, Hiremath, Vaibhav wrote: [Hiremath, Vaibhav] I understand, but if we put the patches on master for whatever period of time available, people can try and validate it. Some people are forward porting the patches (earlier versions submitted) or pinging me for the patches. Let DSS2 alone go in the first slot. Can we use it as a staging here? In a perfect world Tomi would have the staging branch in his tree since he is the maintainer, and Tony would merge that into his master branch for testing. I've been pinging Tomi about my DSS2 patch off-list and he seems to be waiting for DSS2 to be merged before touching any other code, which is a little confusing to me but he's free to run it the way he sees fit. [Hiremath, Vaibhav] Probably because of the amount/size of DSS2 code/patches. Thanks, Vaibhav -Olof -- 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: OMAP36xx Public TRM Available Now!
On Tue, 8 Dec 2009 12:57:26 -0600 Goluguri, Jayabharath jayabhar...@ti.com wrote: I would like to inform you all of the availability of the OMAP36xx Silicon Rev1.0 Public TRM. Direct Link: http://focus.ti.com/pdfs/wtbu/SWPU177B_FinalEPDF_12_04_2009.pdf (Caution: 42MB PDF) Nice coincide, page count is 3630 :-) -- 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: [RFC][RFT][PATCH 3/4 v6] OMAP: McBSP: Introduce caching in register write operations
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [091208 11:45]: Tuesday 08 December 2009 17:59:31 Tony Lindgren napisał(a): * Tony Lindgren t...@atomide.com [091208 08:39]: How about just set the cache size above based on the processor, then do kzalloc here: mcbsp-reg_cache = kzalloc(size, GFP_KERNEL); + if (!mcbsp-reg_cache) + return -ENOMEM; + That way the kzalloc and error checking are in the same place. Actually since we already have mach-omap1/mcbsp.c and mach-omap2/mcbsp.c, it would be best to pass the cache size from omap1_mcbsp_init and omap2_mcbsp_init. That leaves some of the if cpu_is_omap() else stuff. Tony, Almost ready with it, one more question: what do you think about splitting and moving omap_mcbsp_read()/_write() there as well? If you agree, should I submit 2 patches, one with this cleanup, the other one actually introducing cache support, or is one combined OK? Sounds good to me! 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: [RFC][RFT][PATCH 3/4 v6] OMAP: McBSP: Introduce caching in register write operations
* Tony Lindgren t...@atomide.com [091208 15:32]: * Janusz Krzysztofik jkrzy...@tis.icnet.pl [091208 11:45]: Tuesday 08 December 2009 17:59:31 Tony Lindgren napisał(a): * Tony Lindgren t...@atomide.com [091208 08:39]: How about just set the cache size above based on the processor, then do kzalloc here: mcbsp-reg_cache = kzalloc(size, GFP_KERNEL); + if (!mcbsp-reg_cache) + return -ENOMEM; + That way the kzalloc and error checking are in the same place. Actually since we already have mach-omap1/mcbsp.c and mach-omap2/mcbsp.c, it would be best to pass the cache size from omap1_mcbsp_init and omap2_mcbsp_init. That leaves some of the if cpu_is_omap() else stuff. Tony, Almost ready with it, one more question: what do you think about splitting and moving omap_mcbsp_read()/_write() there as well? If you agree, should I submit 2 patches, one with this cleanup, the other one actually introducing cache support, or is one combined OK? Sounds good to me! Oh sorry forgot to reply to your question. If a single patch looks unreadable, then split it into two where the first patch splits omap_mcbsp_read/write. 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
[APPLIED] [PATCH] USB ehci: replace mach header with plat
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: omap-testing Initial commit ID (Likely to change): 6a7426ea75ca387aa65f8f9215f5b40b1a4460b9 PatchWorks http://patchwork.kernel.org/patch/65678/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=6a7426ea75ca387aa65f8f9215f5b40b1a4460b9 -- 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/2]: Introducing 'gpmc-nand.c' for GPMC specific NAND init
* Tony Lindgren t...@atomide.com [091207 09:56]:
* Vimal Singh vimal.neww...@gmail.com [091207 05:28]:
On Mon, Dec 7, 2009 at 11:59 AM, Vimal Singh vimal.neww...@gmail.com
wrote:
On Sat, Dec 5, 2009 at 3:31 AM, Tony Lindgren t...@atomide.com wrote:
Hi,
Looks good, just one comment below.
* Govindraj.R govindraj.r...@ti.com [091204 05:37]:
From: Vimal Singh vimalsi...@ti.com
Date: Wed, 25 Nov 2009 18:23:15 +0530
Subject: [PATCH] Introducing 'gpmc-nand.c' for GPMC specific NAND init
Introducing 'gpmc-nand.c' for GPMC specific NAND init.
For example: GPMC timing parameters and all.
This patch also migrates gpmc related calls from 'nand/omap2.c'
to 'gpmc-nand.c'.
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
arch/arm/mach-omap2/Makefile | 3 +
arch/arm/mach-omap2/gpmc-nand.c | 141
arch/arm/plat-omap/include/plat/nand.h | 6 ++
drivers/mtd/nand/omap2.c | 26 +-
4 files changed, 153 insertions(+), 23 deletions(-)
create mode 100644 arch/arm/mach-omap2/gpmc-nand.c
snip
--- /dev/null
+++ b/arch/arm/mach-omap2/gpmc-nand.c
snip
+int __init gpmc_nand_init(struct omap_nand_platform_data *_nand_data)
+{
+ unsigned int val;
+ int err = 0;
+ struct device *dev = gpmc_nand_device.dev;
+
+ gpmc_nand_data = _nand_data;
+ gpmc_nand_data-nand_setup = gpmc_nand_setup;
+ gpmc_nand_device.dev.platform_data = gpmc_nand_data;
+
+ err = gpmc_nand_setup(gpmc_nand_data-gpmc_cs_baseaddr);
+ if (err 0) {
+ dev_err(dev, NAND platform setup failed: %d\n, err);
+ return err;
+ }
+
+ /* Enable RD PIN Monitoring Reg */
+ if (gpmc_nand_data-dev_ready) {
+ val = gpmc_cs_read_reg(gpmc_nand_data-cs,
+ GPMC_CS_CONFIG1);
+ val |= WR_RD_PIN_MONITORING;
+ gpmc_cs_write_reg(gpmc_nand_data-cs,
+ GPMC_CS_CONFIG1, val);
+ }
Above looks OK..
+ val = gpmc_cs_read_reg(gpmc_nand_data-cs, GPMC_CS_CONFIG7);
+ val = ~(0xf 8);
+ val |= (0xc 0xf) 8;
+ gpmc_cs_write_reg(gpmc_nand_data-cs, GPMC_CS_CONFIG7, val);
..but this looks messy. Maybe use some GPMC defines for the
0xf 8 mask?
Then the 0xc 0xf part looks a bit redundant, what's the 0xf
there for?
I know it's all from the old code, but might as well clean it up
while at it :)
Ok, I'll drop next version of this patch for this.
In fact this peace of code is not required too. This will be taken
care in 'gpmc_cs_request'.
I will remove it.
OK, cool.
Any news on posting the updated version of this? Would be nice to
get it in this merge window, so time's running out :)
When re-posting, please also cc linux-arm-ker...@lists.infradead.org
in addition to linux-omap list. That way we can have it quickly
reviewed there too.
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: [PATCH 1/2] OMAP: use smc91x_platdata to setup smc91x
* Ladislav Michl ladislav.mi...@seznam.cz [091208 08:04]:
Use smc91x_platdata to setup smc91x, so we can get rid of OMAP specific stuff
in smc91x driver
Thanks, will merge both via linux-omap tree.
Regards,
Tony
Signed-off-by: Ladislav Michl la...@linux-mips.org
diff --git a/arch/arm/mach-omap1/board-fsample.c
b/arch/arm/mach-omap1/board-fsample.c
index f4b72c1..91e7b2f 100644
--- a/arch/arm/mach-omap1/board-fsample.c
+++ b/arch/arm/mach-omap1/board-fsample.c
@@ -19,6 +19,7 @@
#include linux/mtd/nand.h
#include linux/mtd/partitions.h
#include linux/input.h
+#include linux/smc91x.h
#include mach/hardware.h
#include asm/mach-types.h
@@ -100,6 +101,12 @@ static int fsample_keymap[] = {
0
};
+static struct smc91x_platdata smc91x_info = {
+ .flags = SMC91X_USE_16BIT | SMC91X_NOWAIT,
+ .leda = RPC_LED_100_10,
+ .ledb = RPC_LED_TX_RX,
+};
+
static struct resource smc91x_resources[] = {
[0] = {
.start = H2P2_DBG_FPGA_ETHR_START, /* Physical */
@@ -190,6 +197,9 @@ static struct platform_device nand_device = {
static struct platform_device smc91x_device = {
.name = smc91x,
.id = 0,
+ .dev= {
+ .platform_data = smc91x_info,
+ },
.num_resources = ARRAY_SIZE(smc91x_resources),
.resource = smc91x_resources,
};
diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
index 89ba8ec..eeafe6e 100644
--- a/arch/arm/mach-omap1/board-h2.c
+++ b/arch/arm/mach-omap1/board-h2.c
@@ -28,6 +28,7 @@
#include linux/mtd/partitions.h
#include linux/input.h
#include linux/i2c/tps65010.h
+#include linux/smc91x.h
#include mach/hardware.h
#include asm/gpio.h
@@ -200,6 +201,12 @@ static struct platform_device h2_nand_device = {
.resource = h2_nand_resource,
};
+static struct smc91x_platdata h2_smc91x_info = {
+ .flags = SMC91X_USE_16BIT | SMC91X_NOWAIT,
+ .leda = RPC_LED_100_10,
+ .ledb = RPC_LED_TX_RX,
+};
+
static struct resource h2_smc91x_resources[] = {
[0] = {
.start = OMAP1610_ETHR_START, /* Physical */
@@ -216,6 +223,9 @@ static struct resource h2_smc91x_resources[] = {
static struct platform_device h2_smc91x_device = {
.name = smc91x,
.id = 0,
+ .dev= {
+ .platform_data = h2_smc91x_info,
+ },
.num_resources = ARRAY_SIZE(h2_smc91x_resources),
.resource = h2_smc91x_resources,
};
diff --git a/arch/arm/mach-omap1/board-h3.c b/arch/arm/mach-omap1/board-h3.c
index f5cc0a7..e0aee66 100644
--- a/arch/arm/mach-omap1/board-h3.c
+++ b/arch/arm/mach-omap1/board-h3.c
@@ -28,6 +28,7 @@
#include linux/input.h
#include linux/spi/spi.h
#include linux/i2c/tps65010.h
+#include linux/smc91x.h
#include asm/setup.h
#include asm/page.h
@@ -202,6 +203,12 @@ static struct platform_device nand_device = {
.resource = nand_resource,
};
+static struct smc91x_platdata smc91x_info = {
+ .flags = SMC91X_USE_16BIT | SMC91X_NOWAIT,
+ .leda = RPC_LED_100_10,
+ .ledb = RPC_LED_TX_RX,
+};
+
static struct resource smc91x_resources[] = {
[0] = {
.start = OMAP1710_ETHR_START, /* Physical */
@@ -218,6 +225,9 @@ static struct resource smc91x_resources[] = {
static struct platform_device smc91x_device = {
.name = smc91x,
.id = 0,
+ .dev= {
+ .platform_data = smc91x_info,
+ },
.num_resources = ARRAY_SIZE(smc91x_resources),
.resource = smc91x_resources,
};
diff --git a/arch/arm/mach-omap1/board-innovator.c
b/arch/arm/mach-omap1/board-innovator.c
index cf0fdb9..91b3b8e 100644
--- a/arch/arm/mach-omap1/board-innovator.c
+++ b/arch/arm/mach-omap1/board-innovator.c
@@ -23,6 +23,7 @@
#include linux/mtd/mtd.h
#include linux/mtd/partitions.h
#include linux/input.h
+#include linux/smc91x.h
#include mach/hardware.h
#include asm/mach-types.h
@@ -159,6 +160,12 @@ static struct map_desc innovator1510_io_desc[]
__initdata = {
}
};
+static struct smc91x_platdata innovator_smc91x_info = {
+ .flags = SMC91X_USE_16BIT | SMC91X_NOWAIT,
+ .leda = RPC_LED_100_10,
+ .ledb = RPC_LED_TX_RX,
+};
+
static struct resource innovator1510_smc91x_resources[] = {
[0] = {
.start = OMAP1510_FPGA_ETHR_START, /* Physical */
@@ -175,6 +182,9 @@ static struct resource innovator1510_smc91x_resources[] =
{
static struct platform_device innovator1510_smc91x_device = {
.name = smc91x,
.id = 0,
+ .dev= {
+ .platform_data = innovator_smc91x_info,
+ },
.num_resources = ARRAY_SIZE(innovator1510_smc91x_resources),
.resource = innovator1510_smc91x_resources,
};
@@ -241,6 +251,9 @@
Re: [PATCH 2/2] smc91x: remove OMAP specific bits
* Ladislav Michl ladislav.mi...@seznam.cz [091208 08:07]: Now that all OMAP boards are using the board resources, we don't need to keep the arch/board specific crap in the driver header. Planning to merge this via linux-omap list too with the platform data patch unless somebody at netdev has objections. Nico, care to ack this? Regards, Tony Signed-off-by: Ladislav Michl la...@linux-mips.org diff --git a/drivers/net/smc91x.h b/drivers/net/smc91x.h index 3911be7..bfc53eb 100644 --- a/drivers/net/smc91x.h +++ b/drivers/net/smc91x.h @@ -206,21 +206,6 @@ SMC_outw(u16 val, void __iomem *ioaddr, int reg) } } -#elifdefined(CONFIG_ARCH_OMAP) - -/* We can only do 16-bit reads and writes in the static memory space. */ -#define SMC_CAN_USE_8BIT 0 -#define SMC_CAN_USE_16BIT1 -#define SMC_CAN_USE_32BIT0 -#define SMC_IO_SHIFT 0 -#define SMC_NOWAIT 1 - -#define SMC_inw(a, r)readw((a) + (r)) -#define SMC_outw(v, a, r)writew(v, (a) + (r)) -#define SMC_insw(a, r, p, l) readsw((a) + (r), p, l) -#define SMC_outsw(a, r, p, l)writesw((a) + (r), p, l) -#define SMC_IRQ_FLAGS (-1)/* from resource */ - #elifdefined(CONFIG_SH_SH4202_MICRODEV) #define SMC_CAN_USE_8BIT 0 -- 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
[APPLIED] [PATCH 1/2] OMAP: use smc91x_platdata to setup smc91x
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: for-next Initial commit ID (Likely to change): 3bbdd7f9bb4ec490324f9dcc790c2e006b23965e PatchWorks http://patchwork.kernel.org/patch/65709/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=3bbdd7f9bb4ec490324f9dcc790c2e006b23965e -- 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] [I2C-OMAP] Add support for 16-bit registers
On Sat, Dec 05, 2009 at 11:14:08PM -0800, Cory Maccarrone wrote:
The current i2c-omap driver is set up for 32-bit registers, which
corresponds to most OMAP devices. However, OMAP730/850 based
devices use a 16-bit register size.
This change modifies the driver to perform a runtime CPU type check
to determine the register sizes, and uses a bit shift of either 1
or 2 bits to compute the proper register sizes for all registers.
Signed-off-by: Cory Maccarrone darkstar6...@gmail.com
---
drivers/i2c/busses/i2c-omap.c | 138
++---
1 files changed, 73 insertions(+), 65 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 827da08..dc7cf71 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -49,24 +49,26 @@
#define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000))
#define OMAP_I2C_REV_REG 0x00
-#define OMAP_I2C_IE_REG 0x04
-#define OMAP_I2C_STAT_REG0x08
-#define OMAP_I2C_IV_REG 0x0c
+#define OMAP_I2C_IE_REG 0x01
+#define OMAP_I2C_STAT_REG0x02
+#define OMAP_I2C_IV_REG 0x03
/* For OMAP3 I2C_IV has changed to I2C_WE (wakeup enable) */
-#define OMAP_I2C_WE_REG 0x0c
-#define OMAP_I2C_SYSS_REG0x10
-#define OMAP_I2C_BUF_REG 0x14
-#define OMAP_I2C_CNT_REG 0x18
-#define OMAP_I2C_DATA_REG0x1c
-#define OMAP_I2C_SYSC_REG0x20
-#define OMAP_I2C_CON_REG 0x24
-#define OMAP_I2C_OA_REG 0x28
-#define OMAP_I2C_SA_REG 0x2c
-#define OMAP_I2C_PSC_REG 0x30
-#define OMAP_I2C_SCLL_REG0x34
-#define OMAP_I2C_SCLH_REG0x38
-#define OMAP_I2C_SYSTEST_REG 0x3c
-#define OMAP_I2C_BUFSTAT_REG 0x40
+#define OMAP_I2C_WE_REG 0x03
+#define OMAP_I2C_SYSS_REG0x04
+#define OMAP_I2C_BUF_REG 0x05
+#define OMAP_I2C_CNT_REG 0x06
+#define OMAP_I2C_DATA_REG0x07
+#define OMAP_I2C_SYSC_REG0x08
+#define OMAP_I2C_CON_REG 0x09
+#define OMAP_I2C_OA_REG 0x0a
+#define OMAP_I2C_SA_REG 0x0b
+#define OMAP_I2C_PSC_REG 0x0c
+#define OMAP_I2C_SCLL_REG0x0d
+#define OMAP_I2C_SCLH_REG0x0e
+#define OMAP_I2C_SYSTEST_REG 0x0f
+#define OMAP_I2C_BUFSTAT_REG 0x10
+
+#define OMAP_I2C_REG(host, reg) (OMAP_I2C_##reg##_REG
(host)-reg_shift)
could you leave the definitions alone and shift the other way?
/* I2C Interrupt Enable Register (OMAP_I2C_IE): */
#define OMAP_I2C_IE_XDR (1 14) /* TX Buffer drain int
enable */
@@ -161,6 +163,7 @@ struct omap_i2c_dev {
struct device *dev;
void __iomem*base; /* virtual */
int irq;
+ int reg_shift; /* bit shift for I2C register
addresses */
struct clk *iclk; /* Interface clock */
struct clk *fclk; /* Functional clock */
struct completion cmd_complete;
@@ -232,7 +235,7 @@ static void omap_i2c_unidle(struct omap_i2c_dev *dev)
clk_enable(dev-fclk);
dev-idle = 0;
if (dev-iestate)
- omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev-iestate);
+ omap_i2c_write_reg(dev, OMAP_I2C_REG(dev, IE), dev-iestate);
how about changing the read and write register calls to do the
necessary address munging so you don't have to change all the
callsites throughout the file?
}
static void omap_i2c_idle(struct omap_i2c_dev *dev)
@@ -241,15 +244,15 @@ static void omap_i2c_idle(struct omap_i2c_dev *dev)
WARN_ON(dev-idle);
- dev-iestate = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
- omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, 0);
+ dev-iestate = omap_i2c_read_reg(dev, OMAP_I2C_REG(dev, IE));
+ omap_i2c_write_reg(dev, OMAP_I2C_REG(dev, IE), 0);
if (dev-rev OMAP_I2C_REV_2) {
- iv = omap_i2c_read_reg(dev, OMAP_I2C_IV_REG); /* Read clears */
+ iv = omap_i2c_read_reg(dev, OMAP_I2C_REG(dev, IV)); /* Read
clears */
} else {
- omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, dev-iestate);
+ omap_i2c_write_reg(dev, OMAP_I2C_REG(dev, STAT), dev-iestate);
/* Flush posted write before the dev-idle store occurs */
- omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
+ omap_i2c_read_reg(dev, OMAP_I2C_REG(dev, STAT));
}
dev-idle = 1;
clk_disable(dev-fclk);
@@ -265,12 +268,12 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
unsigned long internal_clk = 0;
if (dev-rev = OMAP_I2C_REV_2) {
-
[PATCH 0/9] Few more omap patches for v2.6.33 merge window
Hi all, Here are few more patches that have been posted earlier to linux-omap list but not yet posted to LAKML. The series has few clean-up patches, updates Pandor board file, adds omap7xx USB support and minimal support for Always Innovating Touch Book. Regards, Tony --- Cory Maccarrone (2): omap1: Add omap7xx USB support omap1: I2C mux and clocks for omap7xx Grazvydas Ignotas (1): omap3: pandora: board file updates for .33 Gregoire Gentil (2): omap3: Board file of Always Innovating OMAP3-based Touch Book omap3: Defconfig file of Always Innovating OMAP3-based Touch Book Janusz Krzysztofik (1): omap1: DMA: move LCD related code from plat-omap to mach-omap1 Ladislav Michl (3): omap: use smc91x_platdata to setup smc91x smc91x: remove OMAP specific bits omap1: Use gen_nand arch/arm/configs/omap3_touchbook_defconfig | 2431 arch/arm/mach-omap1/Makefile |4 arch/arm/mach-omap1/board-fsample.c| 60 + arch/arm/mach-omap1/board-h2.c | 59 + arch/arm/mach-omap1/board-h3.c | 66 + arch/arm/mach-omap1/board-htcherald.c | 64 + arch/arm/mach-omap1/board-innovator.c | 13 arch/arm/mach-omap1/board-osk.c| 10 arch/arm/mach-omap1/board-perseus2.c | 58 + arch/arm/mach-omap1/board-voiceblue.c | 10 arch/arm/mach-omap1/clock.c|4 arch/arm/mach-omap1/i2c.c | 10 arch/arm/mach-omap1/include/mach/lcd_dma.h | 78 + arch/arm/mach-omap1/lcd_dma.c | 447 + arch/arm/mach-omap1/mux.c |8 arch/arm/mach-omap2/Kconfig|5 arch/arm/mach-omap2/Makefile |3 arch/arm/mach-omap2/board-apollon.c| 10 arch/arm/mach-omap2/board-omap3pandora.c | 26 arch/arm/mach-omap2/board-omap3touchbook.c | 572 +++ arch/arm/mach-omap2/gpmc-smc91x.c |8 arch/arm/plat-omap/debug-devices.c | 10 arch/arm/plat-omap/dma.c | 410 - arch/arm/plat-omap/include/plat/dma.h | 60 - arch/arm/plat-omap/include/plat/mux.h |6 arch/arm/plat-omap/usb.c |8 drivers/net/smc91x.h | 15 27 files changed, 3900 insertions(+), 555 deletions(-) create mode 100644 arch/arm/configs/omap3_touchbook_defconfig create mode 100644 arch/arm/mach-omap1/include/mach/lcd_dma.h create mode 100644 arch/arm/mach-omap1/lcd_dma.c create mode 100644 arch/arm/mach-omap2/board-omap3touchbook.c -- Signature -- 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/9] omap: use smc91x_platdata to setup smc91x
From: Ladislav Michl la...@linux-mips.org
Use smc91x_platdata to setup smc91x, so we can get rid of OMAP specific stuff
in smc91x driver
Signed-off-by: Ladislav Michl la...@linux-mips.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap1/board-fsample.c | 10 ++
arch/arm/mach-omap1/board-h2.c| 10 ++
arch/arm/mach-omap1/board-h3.c| 10 ++
arch/arm/mach-omap1/board-innovator.c | 13 +
arch/arm/mach-omap1/board-osk.c | 10 ++
arch/arm/mach-omap1/board-perseus2.c | 10 ++
arch/arm/mach-omap1/board-voiceblue.c | 10 ++
arch/arm/mach-omap2/board-apollon.c | 10 ++
arch/arm/mach-omap2/gpmc-smc91x.c |8 +---
arch/arm/plat-omap/debug-devices.c| 10 ++
10 files changed, 98 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap1/board-fsample.c
b/arch/arm/mach-omap1/board-fsample.c
index f4b72c1..91e7b2f 100644
--- a/arch/arm/mach-omap1/board-fsample.c
+++ b/arch/arm/mach-omap1/board-fsample.c
@@ -19,6 +19,7 @@
#include linux/mtd/nand.h
#include linux/mtd/partitions.h
#include linux/input.h
+#include linux/smc91x.h
#include mach/hardware.h
#include asm/mach-types.h
@@ -100,6 +101,12 @@ static int fsample_keymap[] = {
0
};
+static struct smc91x_platdata smc91x_info = {
+ .flags = SMC91X_USE_16BIT | SMC91X_NOWAIT,
+ .leda = RPC_LED_100_10,
+ .ledb = RPC_LED_TX_RX,
+};
+
static struct resource smc91x_resources[] = {
[0] = {
.start = H2P2_DBG_FPGA_ETHR_START, /* Physical */
@@ -190,6 +197,9 @@ static struct platform_device nand_device = {
static struct platform_device smc91x_device = {
.name = smc91x,
.id = 0,
+ .dev= {
+ .platform_data = smc91x_info,
+ },
.num_resources = ARRAY_SIZE(smc91x_resources),
.resource = smc91x_resources,
};
diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
index 89ba8ec..eeafe6e 100644
--- a/arch/arm/mach-omap1/board-h2.c
+++ b/arch/arm/mach-omap1/board-h2.c
@@ -28,6 +28,7 @@
#include linux/mtd/partitions.h
#include linux/input.h
#include linux/i2c/tps65010.h
+#include linux/smc91x.h
#include mach/hardware.h
#include asm/gpio.h
@@ -200,6 +201,12 @@ static struct platform_device h2_nand_device = {
.resource = h2_nand_resource,
};
+static struct smc91x_platdata h2_smc91x_info = {
+ .flags = SMC91X_USE_16BIT | SMC91X_NOWAIT,
+ .leda = RPC_LED_100_10,
+ .ledb = RPC_LED_TX_RX,
+};
+
static struct resource h2_smc91x_resources[] = {
[0] = {
.start = OMAP1610_ETHR_START, /* Physical */
@@ -216,6 +223,9 @@ static struct resource h2_smc91x_resources[] = {
static struct platform_device h2_smc91x_device = {
.name = smc91x,
.id = 0,
+ .dev= {
+ .platform_data = h2_smc91x_info,
+ },
.num_resources = ARRAY_SIZE(h2_smc91x_resources),
.resource = h2_smc91x_resources,
};
diff --git a/arch/arm/mach-omap1/board-h3.c b/arch/arm/mach-omap1/board-h3.c
index f5cc0a7..e0aee66 100644
--- a/arch/arm/mach-omap1/board-h3.c
+++ b/arch/arm/mach-omap1/board-h3.c
@@ -28,6 +28,7 @@
#include linux/input.h
#include linux/spi/spi.h
#include linux/i2c/tps65010.h
+#include linux/smc91x.h
#include asm/setup.h
#include asm/page.h
@@ -202,6 +203,12 @@ static struct platform_device nand_device = {
.resource = nand_resource,
};
+static struct smc91x_platdata smc91x_info = {
+ .flags = SMC91X_USE_16BIT | SMC91X_NOWAIT,
+ .leda = RPC_LED_100_10,
+ .ledb = RPC_LED_TX_RX,
+};
+
static struct resource smc91x_resources[] = {
[0] = {
.start = OMAP1710_ETHR_START, /* Physical */
@@ -218,6 +225,9 @@ static struct resource smc91x_resources[] = {
static struct platform_device smc91x_device = {
.name = smc91x,
.id = 0,
+ .dev= {
+ .platform_data = smc91x_info,
+ },
.num_resources = ARRAY_SIZE(smc91x_resources),
.resource = smc91x_resources,
};
diff --git a/arch/arm/mach-omap1/board-innovator.c
b/arch/arm/mach-omap1/board-innovator.c
index cf0fdb9..91b3b8e 100644
--- a/arch/arm/mach-omap1/board-innovator.c
+++ b/arch/arm/mach-omap1/board-innovator.c
@@ -23,6 +23,7 @@
#include linux/mtd/mtd.h
#include linux/mtd/partitions.h
#include linux/input.h
+#include linux/smc91x.h
#include mach/hardware.h
#include asm/mach-types.h
@@ -159,6 +160,12 @@ static struct map_desc innovator1510_io_desc[] __initdata
= {
}
};
+static struct smc91x_platdata innovator_smc91x_info = {
+ .flags = SMC91X_USE_16BIT | SMC91X_NOWAIT,
+ .leda = RPC_LED_100_10,
+ .ledb = RPC_LED_TX_RX,
+};
+
static struct resource
[PATCH 2/9] smc91x: remove OMAP specific bits
From: Ladislav Michl la...@linux-mips.org Now that all OMAP boards are using the board resources, we don't need to keep the arch/board specific crap in the driver header. Cc: linux-...@vger.kernel.org Signed-off-by: Ladislav Michl la...@linux-mips.org Signed-off-by: Tony Lindgren t...@atomide.com --- drivers/net/smc91x.h | 15 --- 1 files changed, 0 insertions(+), 15 deletions(-) diff --git a/drivers/net/smc91x.h b/drivers/net/smc91x.h index 7815bfc..5479954 100644 --- a/drivers/net/smc91x.h +++ b/drivers/net/smc91x.h @@ -206,21 +206,6 @@ SMC_outw(u16 val, void __iomem *ioaddr, int reg) } } -#elif defined(CONFIG_ARCH_OMAP) - -/* We can only do 16-bit reads and writes in the static memory space. */ -#define SMC_CAN_USE_8BIT 0 -#define SMC_CAN_USE_16BIT 1 -#define SMC_CAN_USE_32BIT 0 -#define SMC_IO_SHIFT 0 -#define SMC_NOWAIT 1 - -#define SMC_inw(a, r) readw((a) + (r)) -#define SMC_outw(v, a, r) writew(v, (a) + (r)) -#define SMC_insw(a, r, p, l) readsw((a) + (r), p, l) -#define SMC_outsw(a, r, p, l) writesw((a) + (r), p, l) -#defineSMC_IRQ_FLAGS (-1)/* from resource */ - #elif defined(CONFIG_SH_SH4202_MICRODEV) #define SMC_CAN_USE_8BIT 0 -- 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 3/9] omap1: Use gen_nand
From: Ladislav Michl la...@linux-mips.org
Since omapnand driver never find its way into mainline, switch to gen_nand
instead.
Following patch is compile tested only, but it is based on code I wrote for
NetStar board and runtime tested it there.
Signed-off-by: Ladislav Michl la...@linux-mips.org
Cc: Imre Deak imre.d...@nokia.com
Cc: Brian Swetland swetl...@google.com
Cc: Kevin Hilman k...@hilman.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap1/board-fsample.c | 50 ++
arch/arm/mach-omap1/board-h2.c | 49 --
arch/arm/mach-omap1/board-h3.c | 56 --
arch/arm/mach-omap1/board-perseus2.c | 48 ++---
4 files changed, 152 insertions(+), 51 deletions(-)
diff --git a/arch/arm/mach-omap1/board-fsample.c
b/arch/arm/mach-omap1/board-fsample.c
index 91e7b2f..7e70c3c 100644
--- a/arch/arm/mach-omap1/board-fsample.c
+++ b/arch/arm/mach-omap1/board-fsample.c
@@ -31,7 +31,6 @@
#include mach/gpio.h
#include plat/mux.h
#include plat/fpga.h
-#include plat/nand.h
#include plat/keypad.h
#include plat/common.h
#include plat/board.h
@@ -174,8 +173,40 @@ static struct platform_device nor_device = {
.resource = nor_resource,
};
-static struct omap_nand_platform_data nand_data = {
- .options= NAND_SAMSUNG_LP_OPTIONS,
+static void nand_cmd_ctl(struct mtd_info *mtd, int cmd,unsigned int
ctrl)
+{
+ struct nand_chip *this = mtd-priv;
+ unsigned long mask;
+
+ if (cmd == NAND_CMD_NONE)
+ return;
+
+ mask = (ctrl NAND_CLE) ? 0x02 : 0;
+ if (ctrl NAND_ALE)
+ mask |= 0x04;
+ writeb(cmd, (unsigned long)this-IO_ADDR_W | mask);
+}
+
+#define FSAMPLE_NAND_RB_GPIO_PIN 62
+
+static int nand_dev_ready(struct mtd_info *mtd)
+{
+ return gpio_get_value(FSAMPLE_NAND_RB_GPIO_PIN);
+}
+
+static const char *part_probes[] = { cmdlinepart, NULL };
+
+static struct platform_nand_data nand_data = {
+ .chip = {
+ .nr_chips = 1,
+ .chip_offset= 0,
+ .options= NAND_SAMSUNG_LP_OPTIONS,
+ .part_probe_types = part_probes,
+ },
+ .ctrl = {
+ .cmd_ctrl = nand_cmd_ctl,
+ .dev_ready = nand_dev_ready,
+ },
};
static struct resource nand_resource = {
@@ -185,7 +216,7 @@ static struct resource nand_resource = {
};
static struct platform_device nand_device = {
- .name = omapnand,
+ .name = gen_nand,
.id = 0,
.dev= {
.platform_data = nand_data,
@@ -243,13 +274,6 @@ static struct platform_device *devices[] __initdata = {
lcd_device,
};
-#define P2_NAND_RB_GPIO_PIN62
-
-static int nand_dev_ready(struct omap_nand_platform_data *data)
-{
- return gpio_get_value(P2_NAND_RB_GPIO_PIN);
-}
-
static struct omap_lcd_config fsample_lcd_config __initdata = {
.ctrl_name = internal,
};
@@ -260,9 +284,9 @@ static struct omap_board_config_kernel fsample_config[] = {
static void __init omap_fsample_init(void)
{
- if (gpio_request(P2_NAND_RB_GPIO_PIN, NAND ready) 0)
+ if (gpio_request(FSAMPLE_NAND_RB_GPIO_PIN, NAND ready) 0)
BUG();
- nand_data.dev_ready = nand_dev_ready;
+ gpio_direction_input(FSAMPLE_NAND_RB_GPIO_PIN);
omap_cfg_reg(L3_1610_FLASH_CS2B_OE);
omap_cfg_reg(M8_1610_FLASH_CS2B_WE);
diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
index eeafe6e..fa7cece 100644
--- a/arch/arm/mach-omap1/board-h2.c
+++ b/arch/arm/mach-omap1/board-h2.c
@@ -41,7 +41,6 @@
#include plat/mux.h
#include plat/dma.h
#include plat/tc.h
-#include plat/nand.h
#include plat/irda.h
#include plat/usb.h
#include plat/keypad.h
@@ -180,11 +179,43 @@ static struct mtd_partition h2_nand_partitions[] = {
},
};
-/* dip switches control NAND chip access: 8 bit, 16 bit, or neither */
-static struct omap_nand_platform_data h2_nand_data = {
- .options= NAND_SAMSUNG_LP_OPTIONS,
- .parts = h2_nand_partitions,
- .nr_parts = ARRAY_SIZE(h2_nand_partitions),
+static void h2_nand_cmd_ctl(struct mtd_info *mtd, int cmd, unsigned int ctrl)
+{
+ struct nand_chip *this = mtd-priv;
+ unsigned long mask;
+
+ if (cmd == NAND_CMD_NONE)
+ return;
+
+ mask = (ctrl NAND_CLE) ? 0x02 : 0;
+ if (ctrl NAND_ALE)
+ mask |= 0x04;
+ writeb(cmd, (unsigned long)this-IO_ADDR_W | mask);
+}
+
+#define H2_NAND_RB_GPIO_PIN62
+
+static int h2_nand_dev_ready(struct mtd_info *mtd)
+{
+ return gpio_get_value(H2_NAND_RB_GPIO_PIN);
+}
+
+static const char *h2_part_probes[] = { cmdlinepart, NULL };
+
+struct platform_nand_data h2_nand_platdata = {
+ .chip
[PATCH 5/9] omap1: Add omap7xx USB support
From: Cory Maccarrone darkstar6...@gmail.com
This change implements USB client side support into the HTC
Herald board configuration. It uses a similar, but updated
algorithm to initialize the USB as is used in the linwizard
project.
Signed-off-by: Cory Maccarrone darkstar6...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap1/board-htcherald.c | 64 +
arch/arm/mach-omap1/mux.c |4 ++
arch/arm/plat-omap/include/plat/mux.h |2 +
arch/arm/plat-omap/usb.c |8
4 files changed, 76 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap1/board-htcherald.c
b/arch/arm/mach-omap1/board-htcherald.c
index 5f28a5c..e36639f 100644
--- a/arch/arm/mach-omap1/board-htcherald.c
+++ b/arch/arm/mach-omap1/board-htcherald.c
@@ -39,6 +39,7 @@
#include plat/common.h
#include plat/board.h
#include plat/keypad.h
+#include plat/usb.h
#include mach/irqs.h
@@ -140,6 +141,15 @@ static struct platform_device kp_device = {
.resource = kp_resources,
};
+/* USB Device */
+static struct omap_usb_config htcherald_usb_config __initdata = {
+ .otg = 0,
+ .register_host = 0,
+ .register_dev = 1,
+ .hmc_mode = 4,
+ .pins[0] = 2,
+};
+
/* LCD Device resources */
static struct platform_device lcd_device = {
.name = lcd_htcherald,
@@ -214,6 +224,57 @@ static void __init htcherald_disable_watchdog(void)
}
}
+#define HTCHERALD_GPIO_USB_EN1 33
+#define HTCHERALD_GPIO_USB_EN2 73
+#define HTCHERALD_GPIO_USB_DM 35
+#define HTCHERALD_GPIO_USB_DP 36
+
+static void __init htcherald_usb_enable(void)
+{
+ unsigned int tries = 20;
+ unsigned int value = 0;
+
+ /* Request the GPIOs we need to control here */
+ if (gpio_request(HTCHERALD_GPIO_USB_EN1, herald_usb) 0)
+ goto err1;
+
+ if (gpio_request(HTCHERALD_GPIO_USB_EN2, herald_usb) 0)
+ goto err2;
+
+ if (gpio_request(HTCHERALD_GPIO_USB_DM, herald_usb) 0)
+ goto err3;
+
+ if (gpio_request(HTCHERALD_GPIO_USB_DP, herald_usb) 0)
+ goto err4;
+
+ /* force USB_EN GPIO to 0 */
+ do {
+ /* output low */
+ gpio_direction_output(HTCHERALD_GPIO_USB_EN1, 0);
+ } while ((value = gpio_get_value(HTCHERALD_GPIO_USB_EN1)) == 1
+ --tries);
+
+ if (value == 1)
+ printk(KERN_WARNING Unable to reset USB, trying to
continue\n);
+
+ gpio_direction_output(HTCHERALD_GPIO_USB_EN2, 0); /* output low */
+ gpio_direction_input(HTCHERALD_GPIO_USB_DM); /* input */
+ gpio_direction_input(HTCHERALD_GPIO_USB_DP); /* input */
+
+ goto done;
+
+err4:
+ gpio_free(HTCHERALD_GPIO_USB_DM);
+err3:
+ gpio_free(HTCHERALD_GPIO_USB_EN2);
+err2:
+ gpio_free(HTCHERALD_GPIO_USB_EN1);
+err1:
+ printk(KERN_ERR Unabled to request GPIO for USB\n);
+done:
+ printk(KERN_INFO USB setup complete.\n);
+}
+
static void __init htcherald_init(void)
{
printk(KERN_INFO HTC Herald init.\n);
@@ -225,6 +286,9 @@ static void __init htcherald_init(void)
platform_add_devices(devices, ARRAY_SIZE(devices));
htcherald_disable_watchdog();
+
+ htcherald_usb_enable();
+ omap_usb_init(htcherald_usb_config);
}
static void __init htcherald_init_irq(void)
diff --git a/arch/arm/mach-omap1/mux.c b/arch/arm/mach-omap1/mux.c
index 785371e..5e183cd 100644
--- a/arch/arm/mach-omap1/mux.c
+++ b/arch/arm/mach-omap1/mux.c
@@ -50,7 +50,9 @@ MUX_CFG_7XX(E3_7XX_KBC4,13, 25,0, 24, 1,
0)
MUX_CFG_7XX(AA17_7XX_USB_DM, 2, 21,0, 20, 0, 0)
MUX_CFG_7XX(W16_7XX_USB_PU_EN, 2, 25,0, 24, 0, 0)
-MUX_CFG_7XX(W17_7XX_USB_VBUSI, 2, 29,0, 28, 0, 0)
+MUX_CFG_7XX(W17_7XX_USB_VBUSI, 2, 29,6, 28, 1, 0)
+MUX_CFG_7XX(W18_7XX_USB_DMCK_OUT,3,3,1,2, 0, 0)
+MUX_CFG_7XX(W19_7XX_USB_DCRST, 3,7,1,6, 0, 0)
/* MMC Pins */
MUX_CFG_7XX(MMC_7XX_CMD, 2,9,0,8, 1, 0)
diff --git a/arch/arm/plat-omap/include/plat/mux.h
b/arch/arm/plat-omap/include/plat/mux.h
index 6067cf7..8ed5f25 100644
--- a/arch/arm/plat-omap/include/plat/mux.h
+++ b/arch/arm/plat-omap/include/plat/mux.h
@@ -172,6 +172,8 @@ enum omap7xx_index {
AA17_7XX_USB_DM,
W16_7XX_USB_PU_EN,
W17_7XX_USB_VBUSI,
+ W18_7XX_USB_DMCK_OUT,
+ W19_7XX_USB_DCRST,
/* MMC */
MMC_7XX_CMD,
diff --git a/arch/arm/plat-omap/usb.c b/arch/arm/plat-omap/usb.c
index 51033a4..d3bf17c 100644
--- a/arch/arm/plat-omap/usb.c
+++ b/arch/arm/plat-omap/usb.c
@@ -137,7 +137,13 @@ static u32 __init omap_usb0_init(unsigned nwires, unsigned
is_device)
if (is_device) {
if (cpu_is_omap24xx())
omap_cfg_reg(J20_24XX_USB0_PUEN);
- else
+ else if (cpu_is_omap7xx()) {
+
[PATCH 6/9] omap1: I2C mux and clocks for omap7xx
From: Cory Maccarrone darkstar6...@gmail.com
This change adds MUX pin configuration and clocks for I2C support
to OMAP 730 and 850-based devices.
Signed-off-by: Cory Maccarrone darkstar6...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap1/clock.c |4 ++--
arch/arm/mach-omap1/i2c.c | 10 --
arch/arm/mach-omap1/mux.c |4
arch/arm/plat-omap/include/plat/mux.h |4
4 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap1/clock.c b/arch/arm/mach-omap1/clock.c
index 42cbe20..dc8ca91 100644
--- a/arch/arm/mach-omap1/clock.c
+++ b/arch/arm/mach-omap1/clock.c
@@ -132,9 +132,9 @@ static struct omap_clk omap_clks[] = {
CLK(mmci-omap.1, ick, armper_ck.clk, CK_16XX),
/* Virtual clocks */
CLK(NULL, mpu, virtual_ck_mpu, CK_16XX | CK_1510 |
CK_310),
- CLK(i2c_omap.1, fck,i2c_fck, CK_16XX | CK_1510 |
CK_310),
+ CLK(i2c_omap.1, fck,i2c_fck, CK_16XX | CK_1510 |
CK_310 | CK_7XX),
CLK(i2c_omap.1, ick,i2c_ick, CK_16XX),
- CLK(i2c_omap.1, ick,dummy_ck, CK_1510 | CK_310),
+ CLK(i2c_omap.1, ick,dummy_ck, CK_1510 | CK_310 |
CK_7XX),
CLK(omap_uwire, fck,armxor_ck.clk, CK_16XX | CK_1510 |
CK_310),
CLK(omap-mcbsp.1, ick, dspper_ck, CK_16XX),
CLK(omap-mcbsp.1, ick, dummy_ck, CK_1510 | CK_310),
diff --git a/arch/arm/mach-omap1/i2c.c b/arch/arm/mach-omap1/i2c.c
index bc9d12b..1bf4735 100644
--- a/arch/arm/mach-omap1/i2c.c
+++ b/arch/arm/mach-omap1/i2c.c
@@ -21,13 +21,19 @@
#include plat/i2c.h
#include plat/mux.h
+#include plat/cpu.h
int __init omap_register_i2c_bus(int bus_id, u32 clkrate,
struct i2c_board_info const *info,
unsigned len)
{
- omap_cfg_reg(I2C_SDA);
- omap_cfg_reg(I2C_SCL);
+ if (cpu_is_omap7xx()) {
+ omap_cfg_reg(I2C_7XX_SDA);
+ omap_cfg_reg(I2C_7XX_SCL);
+ } else {
+ omap_cfg_reg(I2C_SDA);
+ omap_cfg_reg(I2C_SCL);
+ }
return omap_plat_register_i2c_bus(bus_id, clkrate, info, len);
}
diff --git a/arch/arm/mach-omap1/mux.c b/arch/arm/mach-omap1/mux.c
index 5e183cd..07212cc 100644
--- a/arch/arm/mach-omap1/mux.c
+++ b/arch/arm/mach-omap1/mux.c
@@ -58,6 +58,10 @@ MUX_CFG_7XX(W19_7XX_USB_DCRST, 3,7,1,6, 0,
0)
MUX_CFG_7XX(MMC_7XX_CMD, 2,9,0,8, 1, 0)
MUX_CFG_7XX(MMC_7XX_CLK, 2, 13,0, 12, 1, 0)
MUX_CFG_7XX(MMC_7XX_DAT0,2, 17,0, 16, 1, 0)
+
+/* I2C interface */
+MUX_CFG_7XX(I2C_7XX_SCL, 5,1,0,0, 1, 0)
+MUX_CFG_7XX(I2C_7XX_SDA, 5,5,0,0, 1, 0)
};
#define OMAP7XX_PINS_SZARRAY_SIZE(omap7xx_pins)
#else
diff --git a/arch/arm/plat-omap/include/plat/mux.h
b/arch/arm/plat-omap/include/plat/mux.h
index 8ed5f25..8f069cc 100644
--- a/arch/arm/plat-omap/include/plat/mux.h
+++ b/arch/arm/plat-omap/include/plat/mux.h
@@ -179,6 +179,10 @@ enum omap7xx_index {
MMC_7XX_CMD,
MMC_7XX_CLK,
MMC_7XX_DAT0,
+
+ /* I2C */
+ I2C_7XX_SCL,
+ I2C_7XX_SDA,
};
enum omap1xxx_index {
--
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 7/9] omap3: Board file of Always Innovating OMAP3-based Touch Book
From: Gregoire Gentil grego...@gentil.com
Board file of Always Innovating OMAP3-based Touch Book
Signed-off-by: Gregoire Gentil grego...@gentil.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/Kconfig|5
arch/arm/mach-omap2/Makefile |3
arch/arm/mach-omap2/board-omap3touchbook.c | 572
3 files changed, 579 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-omap3touchbook.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index afa184a..2ea50bf 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -90,6 +90,11 @@ config MACH_OMAP3_PANDORA
depends on ARCH_OMAP3 ARCH_OMAP34XX
select OMAP_PACKAGE_CBB
+config MACH_OMAP3_TOUCHBOOK
+ bool OMAP3 Touch Book
+ depends on ARCH_OMAP3 ARCH_OMAP34XX
+ select BACKLIGHT_CLASS_DEVICE
+
config MACH_OMAP_3430SDP
bool OMAP 3430 SDP board
depends on ARCH_OMAP3 ARCH_OMAP34XX
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 1cc1d26..0c5d886 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -99,7 +99,8 @@ obj-$(CONFIG_MACH_CM_T35) += board-cm-t35.o \
mmc-twl4030.o
obj-$(CONFIG_MACH_IGEP0020)+= board-igep0020.o \
mmc-twl4030.o
-
+obj-$(CONFIG_MACH_OMAP3_TOUCHBOOK) += board-omap3touchbook.o \
+ mmc-twl4030.o
obj-$(CONFIG_MACH_OMAP_4430SDP)+= board-4430sdp.o
obj-$(CONFIG_MACH_OMAP3517EVM) += board-am3517evm.o
diff --git a/arch/arm/mach-omap2/board-omap3touchbook.c
b/arch/arm/mach-omap2/board-omap3touchbook.c
new file mode 100644
index 000..c9e5ebb
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap3touchbook.c
@@ -0,0 +1,572 @@
+/*
+ * linux/arch/arm/mach-omap2/board-omap3touchbook.c
+ *
+ * Copyright (C) 2009 Always Innovating
+ *
+ * Modified from mach-omap2/board-omap3beagleboard.c
+ *
+ * Initial code: Grégoire Gentil, Tim Yamin
+ *
+ * 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.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/platform_device.h
+#include linux/delay.h
+#include linux/err.h
+#include linux/clk.h
+#include linux/io.h
+#include linux/leds.h
+#include linux/gpio.h
+#include linux/input.h
+#include linux/gpio_keys.h
+
+#include linux/mtd/mtd.h
+#include linux/mtd/partitions.h
+#include linux/mtd/nand.h
+
+#include plat/mcspi.h
+#include linux/spi/spi.h
+
+#include linux/spi/ads7846.h
+
+#include linux/regulator/machine.h
+#include linux/i2c/twl4030.h
+
+#include mach/hardware.h
+#include asm/mach-types.h
+#include asm/mach/arch.h
+#include asm/mach/map.h
+#include asm/mach/flash.h
+
+#include plat/board.h
+#include plat/common.h
+#include plat/gpmc.h
+#include plat/nand.h
+#include plat/usb.h
+#include plat/timer-gp.h
+
+#include mux.h
+#include mmc-twl4030.h
+
+#include asm/setup.h
+
+#define GPMC_CS0_BASE 0x60
+#define GPMC_CS_SIZE 0x30
+
+#define NAND_BLOCK_SIZESZ_128K
+
+#define OMAP3_AC_GPIO 136
+#define OMAP3_TS_GPIO 162
+#define TB_BL_PWM_TIMER9
+#define TB_KILL_POWER_GPIO 168
+
+unsigned long touchbook_revision;
+
+static struct mtd_partition omap3touchbook_nand_partitions[] = {
+ /* All the partition sizes are listed in terms of NAND block size */
+ {
+ .name = X-Loader,
+ .offset = 0,
+ .size = 4 * NAND_BLOCK_SIZE,
+ .mask_flags = MTD_WRITEABLE,/* force read-only */
+ },
+ {
+ .name = U-Boot,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x8 */
+ .size = 15 * NAND_BLOCK_SIZE,
+ .mask_flags = MTD_WRITEABLE,/* force read-only */
+ },
+ {
+ .name = U-Boot Env,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x26 */
+ .size = 1 * NAND_BLOCK_SIZE,
+ },
+ {
+ .name = Kernel,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x28 */
+ .size = 32 * NAND_BLOCK_SIZE,
+ },
+ {
+ .name = File System,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x68 */
+ .size = MTDPART_SIZ_FULL,
+ },
+};
+
+static struct omap_nand_platform_data omap3touchbook_nand_data = {
+ .options= NAND_BUSWIDTH_16,
+ .parts = omap3touchbook_nand_partitions,
+ .nr_parts =
[PATCH 9/9] omap3: pandora: board file updates for .33
From: Grazvydas Ignotas nota...@gmail.com
Pandora board file updates:
- change keycodes of game buttons
it was decided not to use ABXY layout by the developers.
- drop i2c bus 3 speed to 100kHz
this is needed for battery monitoring chip to work reliably.
- drop pandora_lcd platform_device
the older DSS driver was never functional on l-o or mainline
kernels due to missing panel driver, so remove unneeded
pandora_lcd platform_device. This also removes last OMAP_TAG
from the board file.
Signed-off-by: Grazvydas Ignotas nota...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-omap3pandora.c | 26 +-
1 files changed, 5 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3pandora.c
b/arch/arm/mach-omap2/board-omap3pandora.c
index c1cc99c..6f6c601 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -98,10 +98,10 @@ static struct gpio_keys_button pandora_gpio_keys[] = {
GPIO_BUTTON_LOW(103,KEY_DOWN, down),
GPIO_BUTTON_LOW(96, KEY_LEFT, left),
GPIO_BUTTON_LOW(98, KEY_RIGHT, right),
- GPIO_BUTTON_LOW(111,BTN_A, a),
- GPIO_BUTTON_LOW(106,BTN_B, b),
- GPIO_BUTTON_LOW(109,BTN_X, x),
- GPIO_BUTTON_LOW(101,BTN_Y, y),
+ GPIO_BUTTON_LOW(109,KEY_KP1,game 1),
+ GPIO_BUTTON_LOW(111,KEY_KP2,game 2),
+ GPIO_BUTTON_LOW(106,KEY_KP3,game 3),
+ GPIO_BUTTON_LOW(101,KEY_KP4,game 4),
GPIO_BUTTON_LOW(102,BTN_TL, l),
GPIO_BUTTON_LOW(97, BTN_TL2,l2),
GPIO_BUTTON_LOW(105,BTN_TR, r),
@@ -315,7 +315,7 @@ static int __init omap3pandora_i2c_init(void)
omap_register_i2c_bus(1, 2600, omap3pandora_i2c_boardinfo,
ARRAY_SIZE(omap3pandora_i2c_boardinfo));
/* i2c2 pins are not connected */
- omap_register_i2c_bus(3, 400, NULL, 0);
+ omap_register_i2c_bus(3, 100, NULL, 0);
return 0;
}
@@ -368,23 +368,8 @@ static struct spi_board_info omap3pandora_spi_board_info[]
__initdata = {
}
};
-static struct platform_device omap3pandora_lcd_device = {
- .name = pandora_lcd,
- .id = -1,
-};
-
-static struct omap_lcd_config omap3pandora_lcd_config __initdata = {
- .ctrl_name = internal,
-};
-
-static struct omap_board_config_kernel omap3pandora_config[] __initdata = {
- { OMAP_TAG_LCD, omap3pandora_lcd_config },
-};
-
static void __init omap3pandora_init_irq(void)
{
- omap_board_config = omap3pandora_config;
- omap_board_config_size = ARRAY_SIZE(omap3pandora_config);
omap2_init_common_hw(mt46h32m32lf6_sdrc_params,
mt46h32m32lf6_sdrc_params);
omap_init_irq();
@@ -392,7 +377,6 @@ static void __init omap3pandora_init_irq(void)
}
static struct platform_device *omap3pandora_devices[] __initdata = {
- omap3pandora_lcd_device,
pandora_leds_gpio,
pandora_keys_gpio,
};
--
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] [I2C-OMAP] Add support for 16-bit registers
On Tue, Dec 8, 2009 at 4:29 PM, Ben Dooks ben-li...@fluff.org wrote: how about changing the read and write register calls to do the necessary address munging so you don't have to change all the callsites throughout the file? Huh, yeah, that would be smarter. I'll do that and resubmit. Thanks - Cory -- 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/2] smc91x: remove OMAP specific bits
On Tue, 8 Dec 2009, Tony Lindgren wrote: * Ladislav Michl ladislav.mi...@seznam.cz [091208 08:07]: Now that all OMAP boards are using the board resources, we don't need to keep the arch/board specific crap in the driver header. Planning to merge this via linux-omap list too with the platform data patch unless somebody at netdev has objections. Nico, care to ack this? ACK. Regards, Tony Signed-off-by: Ladislav Michl la...@linux-mips.org diff --git a/drivers/net/smc91x.h b/drivers/net/smc91x.h index 3911be7..bfc53eb 100644 --- a/drivers/net/smc91x.h +++ b/drivers/net/smc91x.h @@ -206,21 +206,6 @@ SMC_outw(u16 val, void __iomem *ioaddr, int reg) } } -#elif defined(CONFIG_ARCH_OMAP) - -/* We can only do 16-bit reads and writes in the static memory space. */ -#define SMC_CAN_USE_8BIT 0 -#define SMC_CAN_USE_16BIT 1 -#define SMC_CAN_USE_32BIT 0 -#define SMC_IO_SHIFT 0 -#define SMC_NOWAIT 1 - -#define SMC_inw(a, r) readw((a) + (r)) -#define SMC_outw(v, a, r) writew(v, (a) + (r)) -#define SMC_insw(a, r, p, l) readsw((a) + (r), p, l) -#define SMC_outsw(a, r, p, l) writesw((a) + (r), p, l) -#defineSMC_IRQ_FLAGS (-1)/* from resource */ - #elif defined(CONFIG_SH_SH4202_MICRODEV) #define SMC_CAN_USE_8BIT 0 -- 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 1/9] omap: use smc91x_platdata to setup smc91x
* Tony Lindgren t...@atomide.com [091208 16:48]:
From: Ladislav Michl la...@linux-mips.org
Use smc91x_platdata to setup smc91x, so we can get rid of OMAP specific stuff
in smc91x driver
Signed-off-by: Ladislav Michl la...@linux-mips.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap1/board-fsample.c | 10 ++
arch/arm/mach-omap1/board-h2.c| 10 ++
arch/arm/mach-omap1/board-h3.c| 10 ++
arch/arm/mach-omap1/board-innovator.c | 13 +
arch/arm/mach-omap1/board-osk.c | 10 ++
arch/arm/mach-omap1/board-perseus2.c | 10 ++
arch/arm/mach-omap1/board-voiceblue.c | 10 ++
arch/arm/mach-omap2/board-apollon.c | 10 ++
arch/arm/mach-omap2/gpmc-smc91x.c |8 +---
arch/arm/plat-omap/debug-devices.c| 10 ++
10 files changed, 98 insertions(+), 3 deletions(-)
Looks like this needs a minor change to build for innovator 1610.
Will merge in the following fix as otherwise the smc91x_platdata
is not defined for 1610.
Tony
From e23309bc7d76cc06d7df2659120410398f50b039 Mon Sep 17 00:00:00 2001
From: Tony Lindgren t...@atomide.com
Date: Tue, 8 Dec 2009 18:11:12 -0800
Subject: [PATCH] Fix compile on Innovator 1610 for smc91x
Fix compile on Innovator 1610 for smc91x
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/mach-omap1/board-innovator.c b/arch/arm/mach-omap1/board-innovator.c
index 91b3b8e..2133b00 100644
--- a/arch/arm/mach-omap1/board-innovator.c
+++ b/arch/arm/mach-omap1/board-innovator.c
@@ -143,6 +143,11 @@ static struct platform_device innovator_kp_device = {
.resource = innovator_kp_resources,
};
+static struct smc91x_platdata innovator_smc91x_info = {
+ .flags = SMC91X_USE_16BIT | SMC91X_NOWAIT,
+ .leda = RPC_LED_100_10,
+ .ledb = RPC_LED_TX_RX,
+};
#ifdef CONFIG_ARCH_OMAP15XX
@@ -160,12 +165,6 @@ static struct map_desc innovator1510_io_desc[] __initdata = {
}
};
-static struct smc91x_platdata innovator_smc91x_info = {
- .flags = SMC91X_USE_16BIT | SMC91X_NOWAIT,
- .leda = RPC_LED_100_10,
- .ledb = RPC_LED_TX_RX,
-};
-
static struct resource innovator1510_smc91x_resources[] = {
[0] = {
.start = OMAP1510_FPGA_ETHR_START, /* Physical */
[APPLIED] [RFT/RFC/PATCH 05/10] cbus: tahvo-usb: make it build again
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: cbus Initial commit ID (Likely to change): ea51ab278e51ec3ef596862aae4ec2b63e3e82ad PatchWorks http://patchwork.kernel.org/patch/64371/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=ea51ab278e51ec3ef596862aae4ec2b63e3e82ad -- 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
[APPLIED] [RFT/RFC/PATCH 06/10] cbus: switch to kzalloc
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: cbus Initial commit ID (Likely to change): b57560b33964a00931ebde9deb6d99eb5172f1c2 PatchWorks http://patchwork.kernel.org/patch/64369/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=b57560b33964a00931ebde9deb6d99eb5172f1c2 -- 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
[APPLIED] [RFT/RFC/PATCH 10/10] cbus: add platform_data to pass gpios
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: cbus Initial commit ID (Likely to change): 54fb6e87c520616922a960aeb6d27a5c61976cdb PatchWorks http://patchwork.kernel.org/patch/64370/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=54fb6e87c520616922a960aeb6d27a5c61976cdb -- 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 0/4] TWL patch series
Hi Samuel, This patch is not merged. Please let me know if I am missing something so that i can post the patches rebased on the latest 2.6.32. Thanks and Regards, Balaji T K -Original Message- From: Krishnamoorthy, Balaji T Sent: Thursday, October 01, 2009 5:35 PM To: linux-omap@vger.kernel.org Cc: Krishnamoorthy, Balaji T; Shilimkar, Santosh; Nayak, Rajendra; a.zu...@towertech.it; p_gortma...@yahoo.com; sa...@linux.intel.com; t...@atomide.com Subject: [PATCH v3 0/4] TWL patch series This patch series v3 incorporates comments received earlier[1]. The upcoming TWL6030 is companion chip for OMAP4 like the current TWL4030 for OMAP3. The common modules like RTC, Regulator creates opportunity to re-use the most of the code from twl4030. [PATCH v3 01/04] ARM: OMAP: Rename twl4030* driver files to enable re- use [PATCH v3 02/04] ARM: OMAP: Rename all twl4030_i2c*. [PATCH v3 03/04] ARM: OMAP: Rename twl4030_ in rtc-twl.c to make it generic rtc [PATCH v3 04/04] ARM: OMAP: Rename twl4030_ to twl_ in twl-regulator.c to make it generic reg [1] http://marc.info/?l=linux-omapm=124757921417187w=2 [PATCH 0/4] TWL patch series -- 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 00/10 v4] omap3: pm: introduce support for 3630 OPPs
Hi,
Thanks for all the comments. Here is V4 of the patch series.
What changed in V4 (or stage1 as discussed in l-o v3):
* Search OPP APIs changed.
* review comment incorporated
History:
V3: http://marc.info/?t=12591223421r=1w=2
V2: http://marc.info/?l=linux-omapm=125809232732700w=2
V1: http://marc.info/?l=linux-omapm=125800488923479w=2
Ref: http://elinux.org/OMAP_Power_Management#Future_directions
Also note that OMAP3630 is dependent on clk tree changes which needs
to come in - but that is an independent parallel activity.
NOTE: SR should be disabled for testing on 3630, there are deltas for
OMAP3630 which are not in place in SR codebase and behavior is not
trustworthy.
TODO Cleanups:
* Kevin's recommended cleanups in:
http://marc.info/?l=linux-omapm=125917007423545w=2
(requesting this be posted once we get the initial set in..)
* SRF cleanup in a detailed and to make it robust.
* Smartreflex cleanups/refactor + support 3630
TODO items (other than cleanups):
* Add on a dependency b/w vdd1 and vdd2 in a clean manner - probably
after we cleanup the resource34xx.c, all folks needing a quick hack
can easily follow the following pseudo logic:
resource34xx.c::set_opp:
if (cpu_is_omap3630()) {
vdd1_threshold_freq = 600mhz (opp2)
vdd2_required_freq = 200Mhz
} else {
vdd1_threshold_freq = 500 Mhz (opp3)
vdd2_required_freq = 100Mhz
}
if (vdd1_target vdd1_threshold_freq)
free_vdd2_dep_if_acquired();
/* Do other stuff */
if (vdd1_target_freq = vdd1_threshold_freq)
request_vdd2(at least vdd2_required_freq)
The 3630 vdd1-vdd2 dependency comes from the OPP table dependency
of OPP100 and above on VDD1 requires VDD2 to be OPP100. VDD2 is free
to go as it pleases, but optimal is to be at OPP50 if VDD1 is at
OPP50. Lots of possible hacks are possible, and I dont recommend any
at the moment.
* OMAP3630: Add speedbin detection and enable support for OPP-Turbo and
OPP-SB
Finally,
NOTE: SDP3630 needs the patch for 8250 as discussed here:
http://marc.info/?l=linux-omapm=125873296522723w=2
(pushed to l-o, will be available once pm is rebased)
This patch series is based on previous discussions:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg17632.html
I have modified the initial patch From Sanjeev:
http://patchwork.kernel.org/patch/50998/
Other than these, we cannot use the old VDDx_MAX based usage
anymore as 3630 OPPs are now different and runtime handling
is a must-have, hence introducing these accessor functions is not
avoidable.
The changes are incremental and tries to avoid intrusive change
as much as possible.
The OPP accessor functions introduced in this series is hopefully
a start for us to optimize this heavily used path.
An alternate approach for detecting 3630 OPP is using FEATURES
instead of detecting the cpu_type as I have implemented in this series.
Testing: mostly on SDP3430 and SDP3630: using cpufreq-utils, sysfs
vddx_lock, RET/OFF using shell scripts. Further testing requested.
Most of the commands used documented here:
http://elinux.org/OMAP_Power_Management
Reposting the series for consistency as only 3 patches retained the v1
status due to change in accessor function names and nature.
Nishanth Menon (10):
Following are the OPP accessor function introduction:
omap3: pm: introduce enabled flag to omap_opp
omap3: pm: introduce opp accessor functions - v4
omap3: pm: use opp accessor functions for omap34xx - v4
The following are attempts to cleanup existing code from VDDx dep:
omap3: pm: srf: use opp accessor functions - v4
omap3: pm: sr: replace get_opp with freq_to_opp - v4
omap3: pm: use opp accessor functions for omap-target - v4
omap3: clk: use pm accessor functions for cpufreq table - v4
omap3: pm: remove VDDx_MIN/MAX macros
The following two introduce 3630 support:
omap3: pm: introduce 3630 opps - v4
omap3: pm: omap3630 boards: enable 3630 opp tables
arch/arm/mach-omap2/board-3430sdp.c|1 +
arch/arm/mach-omap2/board-3630sdp.c|9 +-
arch/arm/mach-omap2/board-omap3beagle.c|1 +
arch/arm/mach-omap2/board-omap3evm.c |1 +
arch/arm/mach-omap2/board-rx51.c |1 +
arch/arm/mach-omap2/board-zoom2.c |2 +
arch/arm/mach-omap2/board-zoom3.c |9 +-
arch/arm/mach-omap2/clock34xx.c| 40 +++--
arch/arm/mach-omap2/omap3-opp.h| 58 +--
arch/arm/mach-omap2/pm.h |6 +
arch/arm/mach-omap2/pm34xx.c | 106 +++
arch/arm/mach-omap2/resource34xx.c | 238 ++---
arch/arm/mach-omap2/smartreflex.c | 44 ++---
arch/arm/plat-omap/Makefile|3 +
arch/arm/plat-omap/cpu-omap.c | 12 +-
arch/arm/plat-omap/include/plat/omap-pm.h | 15 +--
arch/arm/plat-omap/include/plat/omap34xx.h |5 -
arch/arm/plat-omap/include/plat/opp.h | 230 +++
[PATCH 01/10] omap3: pm: introduce enabled flag to omap_opp
We used to enable and disable OPPs based on rate being set to 0, this
has been confusing in general. So, we now allow specific OPPs to be
now enabled/disabled by an explicit enabled flag instead of re-using
rate flag itself.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Eduardo Valentin eduardo.valen...@nokia.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Madhusudhan Chikkature Rajashekar madhu...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Romit Dasgupta ro...@ti.com
Cc: Sanjeev Premi pr...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Sergio Alberto Aguirre Rodriguez saagui...@ti.com
Cc: Tero Kristo tero.kri...@nokia.com
Cc: Thara Gopinath th...@ti.com
Cc: Vishwanath Sripathy vishwanath...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/omap3-opp.h | 32 ++--
arch/arm/mach-omap2/resource34xx.c|4 +++
arch/arm/plat-omap/include/plat/omap-pm.h |2 +
3 files changed, 22 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-omap2/omap3-opp.h b/arch/arm/mach-omap2/omap3-opp.h
index c773ea7..42557e1 100644
--- a/arch/arm/mach-omap2/omap3-opp.h
+++ b/arch/arm/mach-omap2/omap3-opp.h
@@ -22,41 +22,41 @@
#define S166M 16600
static struct omap_opp omap3_mpu_rate_table[] = {
- {0, 0, 0},
+ {0, 0, 0, 0},
/*OPP1*/
- {S125M, VDD1_OPP1, 0x1E},
+ {true, S125M, VDD1_OPP1, 0x1E},
/*OPP2*/
- {S250M, VDD1_OPP2, 0x26},
+ {true, S250M, VDD1_OPP2, 0x26},
/*OPP3*/
- {S500M, VDD1_OPP3, 0x30},
+ {true, S500M, VDD1_OPP3, 0x30},
/*OPP4*/
- {S550M, VDD1_OPP4, 0x36},
+ {true, S550M, VDD1_OPP4, 0x36},
/*OPP5*/
- {S600M, VDD1_OPP5, 0x3C},
+ {true, S600M, VDD1_OPP5, 0x3C},
};
static struct omap_opp omap3_l3_rate_table[] = {
- {0, 0, 0},
+ {0, 0, 0, 0},
/*OPP1*/
- {0, VDD2_OPP1, 0x1E},
+ {false, 0, VDD2_OPP1, 0x1E},
/*OPP2*/
- {S83M, VDD2_OPP2, 0x24},
+ {true, S83M, VDD2_OPP2, 0x24},
/*OPP3*/
- {S166M, VDD2_OPP3, 0x2C},
+ {true, S166M, VDD2_OPP3, 0x2C},
};
static struct omap_opp omap3_dsp_rate_table[] = {
- {0, 0, 0},
+ {0, 0, 0, 0},
/*OPP1*/
- {S90M, VDD1_OPP1, 0x1E},
+ {true, S90M, VDD1_OPP1, 0x1E},
/*OPP2*/
- {S180M, VDD1_OPP2, 0x26},
+ {true, S180M, VDD1_OPP2, 0x26},
/*OPP3*/
- {S360M, VDD1_OPP3, 0x30},
+ {true, S360M, VDD1_OPP3, 0x30},
/*OPP4*/
- {S400M, VDD1_OPP4, 0x36},
+ {true, S400M, VDD1_OPP4, 0x36},
/*OPP5*/
- {S430M, VDD1_OPP5, 0x3C},
+ {true, S430M, VDD1_OPP5, 0x3C},
};
#endif
diff --git a/arch/arm/mach-omap2/resource34xx.c
b/arch/arm/mach-omap2/resource34xx.c
index 04be4d2..af6b3c1 100644
--- a/arch/arm/mach-omap2/resource34xx.c
+++ b/arch/arm/mach-omap2/resource34xx.c
@@ -285,6 +285,10 @@ static int program_opp(int res, struct omap_opp *opp, int
target_level,
c_opp = ID_VDD(res) | ID_OPP_NO(opp[current_level].opp_id);
#endif
+ /* Only allow enabled OPPs */
+ if (!opp[target_level].enabled)
+ return -EINVAL;
+
/* Sanity check of the OPP params before attempting to set */
if (!opp[target_level].rate || !opp[target_level].vsel)
return -EINVAL;
diff --git a/arch/arm/plat-omap/include/plat/omap-pm.h
b/arch/arm/plat-omap/include/plat/omap-pm.h
index 583e540..5dc2048 100644
--- a/arch/arm/plat-omap/include/plat/omap-pm.h
+++ b/arch/arm/plat-omap/include/plat/omap-pm.h
@@ -21,6 +21,7 @@
/**
* struct omap_opp - clock frequency-to-OPP ID table for DSP, MPU
+ * @enabled: enabled if true, disabled if false
* @rate: target clock rate
* @opp_id: OPP ID
* @min_vdd: minimum VDD1 voltage (in millivolts) for this OPP
@@ -28,6 +29,7 @@
* Operating performance point data. Can vary by OMAP chip and board.
*/
struct omap_opp {
+ bool enabled;
unsigned long rate;
u8 opp_id;
u16 vsel;
--
1.6.3.3
--
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 03/10 V4] omap3: pm: use opp accessor functions for omap34xx
Move the definitions from omap3-opp.h to pm34xx.c. The definitions
are now based on omap_opp_def instead of omap_opp itself.
Since the opp.h has the omap_opp definition, omap-pm.h conflicts and
has been removed in favor of opp.h.
omap3_pm_init_opp_table is used to initialize the OPP table and
relevant board files which have omap2_init_common_hw called with opp
arrays have been updated with omap3_pm_init_opp_table.
This change now allows us to dynamically register OPPs to the system
based on silicon type we detect.
NOTE: This introduces the following warnings highlighting areas we
need to cleanup:
arch/arm/mach-omap2/smartreflex.c: In function 'get_opp':
arch/arm/mach-omap2/smartreflex.c:161: warning: 'opp_id' is deprecated
(declared at arch/arm/plat-omap/include/plat/opp.h:33)
arch/arm/mach-omap2/smartreflex.c:164: warning: 'opp_id' is deprecated
(declared at arch/arm/plat-omap/include/plat/opp.h:33)
arch/arm/mach-omap2/smartreflex.c:166: warning: 'opp_id' is deprecated
(declared at arch/arm/plat-omap/include/plat/opp.h:33)
arch/arm/mach-omap2/smartreflex.c:168: warning: 'opp_id' is deprecated
(declared at arch/arm/plat-omap/include/plat/opp.h:33)
arch/arm/mach-omap2/resource34xx.c: In function 'get_opp':
arch/arm/mach-omap2/resource34xx.c:165: warning: 'opp_id' is deprecated
(declared at arch/arm/plat-omap/include/plat/opp.h:33)
arch/arm/mach-omap2/resource34xx.c:168: warning: 'opp_id' is deprecated
(declared at arch/arm/plat-omap/include/plat/opp.h:33)
arch/arm/mach-omap2/resource34xx.c:170: warning: 'opp_id' is deprecated
(declared at arch/arm/plat-omap/include/plat/opp.h:33)
arch/arm/mach-omap2/resource34xx.c:172: warning: 'opp_id' is deprecated
(declared at arch/arm/plat-omap/include/plat/opp.h:33)
arch/arm/mach-omap2/resource34xx.c: In function 'program_opp':
arch/arm/mach-omap2/resource34xx.c:284: warning: 'opp_id' is deprecated
(declared at arch/arm/plat-omap/include/plat/opp.h:33)
arch/arm/mach-omap2/resource34xx.c:285: warning: 'opp_id' is deprecated
(declared at arch/arm/plat-omap/include/plat/opp.h:33)
Cc: Benoit Cousson b-cous...@ti.com
Cc: Eduardo Valentin eduardo.valen...@nokia.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Madhusudhan Chikkature Rajashekar madhu...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Romit Dasgupta ro...@ti.com
Cc: Sanjeev Premi pr...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Sergio Alberto Aguirre Rodriguez saagui...@ti.com
Cc: Tero Kristo tero.kri...@nokia.com
Cc: Thara Gopinath th...@ti.com
Cc: Vishwanath Sripathy vishwanath...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c |1 +
arch/arm/mach-omap2/board-omap3beagle.c |1 +
arch/arm/mach-omap2/board-omap3evm.c |1 +
arch/arm/mach-omap2/board-rx51.c |1 +
arch/arm/mach-omap2/board-zoom2.c |2 +
arch/arm/mach-omap2/omap3-opp.h | 58 +
arch/arm/mach-omap2/pm.h |6 +++
arch/arm/mach-omap2/pm34xx.c | 65 +
arch/arm/plat-omap/include/plat/omap-pm.h | 17 +---
9 files changed, 81 insertions(+), 71 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index eac529f..0ec8327 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -220,6 +220,7 @@ static void __init omap_3430sdp_init_irq(void)
{
omap_board_config = sdp3430_config;
omap_board_config_size = ARRAY_SIZE(sdp3430_config);
+ omap3_pm_init_opp_table();
omap3_pm_init_vc(omap3_setuptime_table);
omap3_pm_init_cpuidle(omap3_cpuidle_params_table);
omap2_init_common_hw(hyb18m512160af6_sdrc_params, NULL,
omap3_mpu_rate_table,
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 2ec3520..a937238 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -361,6 +361,7 @@ static void __init omap3_beagle_init_irq(void)
{
omap_board_config = omap3_beagle_config;
omap_board_config_size = ARRAY_SIZE(omap3_beagle_config);
+ omap3_pm_init_opp_table();
omap2_init_common_hw(mt46h32m32lf6_sdrc_params,
mt46h32m32lf6_sdrc_params, omap3_mpu_rate_table,
omap3_dsp_rate_table, omap3_l3_rate_table);
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 8130eca..44a5861 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -404,6 +404,7 @@ static void __init omap3_evm_init_irq(void)
{
omap_board_config = omap3_evm_config;
omap_board_config_size = ARRAY_SIZE(omap3_evm_config);
+ omap3_pm_init_opp_table();
omap2_init_common_hw(mt46h32m32lf6_sdrc_params, NULL,
omap3_mpu_rate_table,
omap3_dsp_rate_table,
[PATCH 08/10] omap3: pm: remove VDDx_MIN/MAX macros
Since accessor functions are used through out, we dont depend on the predefined macros to know the limits of the opp table. Hence, remove these. Cc: Benoit Cousson b-cous...@ti.com Cc: Eduardo Valentin eduardo.valen...@nokia.com Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Madhusudhan Chikkature Rajashekar madhu...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Romit Dasgupta ro...@ti.com Cc: Sanjeev Premi pr...@ti.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Sergio Alberto Aguirre Rodriguez saagui...@ti.com Cc: Tero Kristo tero.kri...@nokia.com Cc: Thara Gopinath th...@ti.com Cc: Vishwanath Sripathy vishwanath...@ti.com Signed-off-by: Nishanth Menon n...@ti.com --- arch/arm/plat-omap/include/plat/omap34xx.h |5 - 1 files changed, 0 insertions(+), 5 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/omap34xx.h b/arch/arm/plat-omap/include/plat/omap34xx.h index 6b849e5..9768f8a 100644 --- a/arch/arm/plat-omap/include/plat/omap34xx.h +++ b/arch/arm/plat-omap/include/plat/omap34xx.h @@ -98,10 +98,5 @@ #define VDD2_OPP2 0x2 #define VDD2_OPP3 0x3 -#define MIN_VDD1_OPP VDD1_OPP1 -#define MAX_VDD1_OPP VDD1_OPP5 -#define MIN_VDD2_OPP VDD2_OPP1 -#define MAX_VDD2_OPP VDD2_OPP3 - #endif /* __ASM_ARCH_OMAP34XX_H */ -- 1.6.3.3 -- 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 10/10] omap3: pm: omap3630 boards: enable 3630 opp tables
Enable the OPP tables for 3630 platforms: SDP3630, zoom3.
NOTE: This needs the corresponding clockframework changes.
Currently this dumps the following on OPP transitions on SDP3630:
[c002d734] (dump_backtrace+0x0/0x110) from [c02c9698] (dump_stack+0x18/0x1c)
r7: r6:c003bff8 r5:c034a227 r4:0309
[c02c9680] (dump_stack+0x0/0x1c) from [c0052f24]
(warn_slowpath_common+0x50/0x68)
[c0052ed4] (warn_slowpath_common+0x0/0x68) from [c0052f54]
(warn_slowpath_null+0x18/0x1c)
r7:c7801000 r6:0f7f4900 r5:8013 r4:
[c0052f3c] (warn_slowpath_null+0x0/0x1c) from [c003bff8]
(omap3_noncore_dpll_set_rate+0x294/0x2d8)
[c003bd64] (omap3_noncore_dpll_set_rate+0x0/0x2d8) from [c0036e24]
(omap2_clk_set_rate+0x28/0x34)
[c0036dfc] (omap2_clk_set_rate+0x0/0x34) from [c003ecec]
(clk_set_rate+0x54/0xb8)
[c003ec98] (clk_set_rate+0x0/0xb8) from [c003c750] (program_opp+0x120/0x228)
r7:c7801000 r6: r5:c03c9fe0 r4:c03c9fd8
[c003c630] (program_opp+0x0/0x228) from [c003c990]
(resource_set_opp_level+0x138/0x1b0)
[c003c858] (resource_set_opp_level+0x0/0x1b0) from [c0038534]
(vdd_opp_store+0x148/0x17c)
[c00383ec] (vdd_opp_store+0x0/0x17c) from [c01b39dc]
(kobj_attr_store+0x20/0x24)
r7:c7833740 r6:c794bec0 r5:c78c8960 r4:0001
[c01b39bc] (kobj_attr_store+0x0/0x24) from [c0102c3c]
(sysfs_write_file+0x110/0x144)
[c0102b2c] (sysfs_write_file+0x0/0x144) from [c00b2f90]
(vfs_write+0xb8/0x164)
[c00b2ed8] (vfs_write+0x0/0x164) from [c00b3100] (sys_write+0x44/0x70)
r8:4000 r7:0001 r6:c783de00 r5: r4:
[c00b30bc] (sys_write+0x0/0x70) from [c0029f80] (ret_fast_syscall+0x0/0x2c)
r8:c002a104 r7:0004 r6:001d7918 r5:4000 r4:0001
Cc: Benoit Cousson b-cous...@ti.com
Cc: Eduardo Valentin eduardo.valen...@nokia.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Madhusudhan Chikkature Rajashekar madhu...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Romit Dasgupta ro...@ti.com
Cc: Sanjeev Premi pr...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Sergio Alberto Aguirre Rodriguez saagui...@ti.com
Cc: Tero Kristo tero.kri...@nokia.com
Cc: Thara Gopinath th...@ti.com
Cc: Vishwanath Sripathy vishwanath...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/board-3630sdp.c |9 -
arch/arm/mach-omap2/board-zoom3.c |9 -
2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3630sdp.c
b/arch/arm/mach-omap2/board-3630sdp.c
index 185f48d..7a429db 100755
--- a/arch/arm/mach-omap2/board-3630sdp.c
+++ b/arch/arm/mach-omap2/board-3630sdp.c
@@ -24,6 +24,8 @@
#include mach/board-zoom.h
#include sdram-hynix-h8mbx00u0mer-0em.h
+#include pm.h
+#include omap3-opp.h
#if defined(CONFIG_SMC91X) || defined(CONFIG_SMC91X_MODULE)
@@ -76,9 +78,14 @@ static void __init omap_sdp_init_irq(void)
{
omap_board_config = sdp_config;
omap_board_config_size = ARRAY_SIZE(sdp_config);
+
+ omap3_pm_init_opp_table();
+ /* TODO: Add RET, OFF, cpu_idle params */
+
omap2_init_common_hw(h8mbx00u0mer0em_sdrc_params,
h8mbx00u0mer0em_sdrc_params,
- NULL, NULL, NULL);
+omap3_mpu_rate_table, omap3_dsp_rate_table,
+omap3_l3_rate_table);
omap_init_irq();
omap_gpio_init();
}
diff --git a/arch/arm/mach-omap2/board-zoom3.c
b/arch/arm/mach-omap2/board-zoom3.c
index fe97324..0574811 100644
--- a/arch/arm/mach-omap2/board-zoom3.c
+++ b/arch/arm/mach-omap2/board-zoom3.c
@@ -22,6 +22,8 @@
#include plat/board.h
#include sdram-hynix-h8mbx00u0mer-0em.h
+#include pm.h
+#include omap3-opp.h
static void __init omap_zoom_map_io(void)
{
@@ -36,9 +38,14 @@ static void __init omap_zoom_init_irq(void)
{
omap_board_config = zoom_config;
omap_board_config_size = ARRAY_SIZE(zoom_config);
+
+ omap3_pm_init_opp_table();
+ /* TODO: Add RET, OFF, cpu_idle params */
+
omap2_init_common_hw(h8mbx00u0mer0em_sdrc_params,
h8mbx00u0mer0em_sdrc_params,
-NULL, NULL, NULL);
+omap3_mpu_rate_table, omap3_dsp_rate_table,
+omap3_l3_rate_table);
omap_init_irq();
omap_gpio_init();
}
--
1.6.3.3
--
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 06/10 V4] omap3: pm: use opp accessor functions for omap-target
The logic in omap-target can now be improved with the accessor
functions. Dont scan through the list manually, instead use
get_next_freq to do the scanning.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Eduardo Valentin eduardo.valen...@nokia.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Madhusudhan Chikkature Rajashekar madhu...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Romit Dasgupta ro...@ti.com
Cc: Sanjeev Premi pr...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Sergio Alberto Aguirre Rodriguez saagui...@ti.com
Cc: Tero Kristo tero.kri...@nokia.com
Cc: Thara Gopinath th...@ti.com
Cc: Vishwanath Sripathy vishwanath...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/plat-omap/cpu-omap.c | 12
1 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/arch/arm/plat-omap/cpu-omap.c b/arch/arm/plat-omap/cpu-omap.c
index 449b6b6..43d3da5 100644
--- a/arch/arm/plat-omap/cpu-omap.c
+++ b/arch/arm/plat-omap/cpu-omap.c
@@ -111,14 +111,10 @@ static int omap_target(struct cpufreq_policy *policy,
cpufreq_notify_transition(freqs, CPUFREQ_POSTCHANGE);
#elif defined(CONFIG_ARCH_OMAP3) !defined(CONFIG_OMAP_PM_NONE)
if (mpu_opps) {
- int ind;
- for (ind = 1; ind = MAX_VDD1_OPP; ind++) {
- if (mpu_opps[ind].rate/1000 = target_freq) {
- omap_pm_cpu_set_freq
- (mpu_opps[ind].rate);
- break;
- }
- }
+ unsigned long freq = target_freq * 1000;
+ if (!IS_ERR(opp_find_freq_approx(mpu_opps, freq,
+ OPP_SEARCH_HIGH)))
+ omap_pm_cpu_set_freq(freq);
}
#endif
return ret;
--
1.6.3.3
--
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 04/10 V4] omap3: pm: srf: use opp accessor functions
With the accessor functions, many of the direct accesses are redundant. However we do not want to rewrite SRF at this point of time We do the following here: Remove get_opp and introduce three SRF specific accessor functions: opp_to_freq, freq_to_opp - need this coz of usage of opp IDs NOTE: These functions should be removed at a later point of time. get_opp is removed because, with the above functions, it is redundant. NOTE: this implementation is just a start and leaves scope for further cleanups which can be added on top. NOTE: this adds the following warnings: arch/arm/mach-omap2/resource34xx.c: In function 'opp_to_freq': arch/arm/mach-omap2/resource34xx.c:184: warning: 'opp_id' is deprecated (declared at arch/arm/plat-omap/include/plat/opp.h:33) arch/arm/mach-omap2/resource34xx.c: In function 'freq_to_opp': arch/arm/mach-omap2/resource34xx.c:213: warning: 'opp_id' is deprecated (declared at arch/arm/plat-omap/include/plat/opp.h:33) arch/arm/mach-omap2/resource34xx.c: In function 'init_opp': arch/arm/mach-omap2/resource34xx.c:237: warning: 'freq_to_opp' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:204) arch/arm/mach-omap2/resource34xx.c:244: warning: 'freq_to_opp' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:204) arch/arm/mach-omap2/resource34xx.c: In function 'program_opp_freq': arch/arm/mach-omap2/resource34xx.c:297: warning: 'opp_to_freq' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) arch/arm/mach-omap2/resource34xx.c:298: warning: 'opp_to_freq' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) arch/arm/mach-omap2/resource34xx.c:303: warning: 'opp_to_freq' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) arch/arm/mach-omap2/resource34xx.c: In function 'program_opp': arch/arm/mach-omap2/resource34xx.c:346: warning: 'opp_id' is deprecated (declared at arch/arm/plat-omap/include/plat/opp.h:33) arch/arm/mach-omap2/resource34xx.c:347: warning: 'opp_id' is deprecated (declared at arch/arm/plat-omap/include/plat/opp.h:33) arch/arm/mach-omap2/resource34xx.c:351: warning: 'opp_to_freq' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) arch/arm/mach-omap2/resource34xx.c:376: warning: 'opp_to_freq' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) arch/arm/mach-omap2/resource34xx.c: In function 'resource_set_opp_level': arch/arm/mach-omap2/resource34xx.c:414: warning: 'opp_to_freq' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) arch/arm/mach-omap2/resource34xx.c:415: warning: 'opp_to_freq' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) arch/arm/mach-omap2/resource34xx.c:417: warning: 'opp_to_freq' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) arch/arm/mach-omap2/resource34xx.c: In function 'set_opp': arch/arm/mach-omap2/resource34xx.c:491: warning: 'freq_to_opp' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:204) arch/arm/mach-omap2/resource34xx.c: In function 'validate_opp': arch/arm/mach-omap2/resource34xx.c:510: warning: 'opp_to_freq' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) arch/arm/mach-omap2/resource34xx.c:512: warning: 'opp_to_freq' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) arch/arm/mach-omap2/resource34xx.c: In function 'init_freq': arch/arm/mach-omap2/resource34xx.c:535: warning: 'opp_to_freq' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) arch/arm/mach-omap2/resource34xx.c:538: warning: 'opp_to_freq' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) arch/arm/mach-omap2/resource34xx.c: In function 'set_freq': arch/arm/mach-omap2/resource34xx.c:554: warning: 'freq_to_opp' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:204) arch/arm/mach-omap2/resource34xx.c:559: warning: 'freq_to_opp' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:204) arch/arm/mach-omap2/resource34xx.c: In function 'validate_freq': arch/arm/mach-omap2/resource34xx.c:573: warning: 'freq_to_opp' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:204) arch/arm/mach-omap2/resource34xx.c:575: warning: 'freq_to_opp' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:204) Cc: Benoit Cousson b-cous...@ti.com Cc: Eduardo Valentin eduardo.valen...@nokia.com Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Madhusudhan Chikkature Rajashekar madhu...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Romit Dasgupta ro...@ti.com Cc: Sanjeev Premi pr...@ti.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Sergio Alberto Aguirre Rodriguez saagui...@ti.com Cc: Tero Kristo tero.kri...@nokia.com Cc: Thara Gopinath th...@ti.com Cc: Vishwanath Sripathy vishwanath...@ti.com Signed-off-by: Nishanth Menon n...@ti.com --- arch/arm/mach-omap2/resource34xx.c | 242 ++-- 1 files changed, 176 insertions(+), 66 deletions(-) diff --git
[PATCH 02/10 V4] omap3: pm: introduce opp accessor functions
Modifies the initial patch From Sanjeev:
http://patchwork.kernel.org/patch/50998/
Discussions and comments from:
http://marc.info/?l=linux-omapm=125482970102327w=2
http://marc.info/?t=12580924752r=1w=2
http://marc.info/?l=linux-omapm=126025973426007w=2
incorporated.
OMAP SOCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. This
is called Operating Points or OPP. The actual definitions of OMAP
Operating Points varies over silicon within the same family of
devices. For a specific domain, you can have a set of
{frequency, voltage} pairs. As the kernel boots and more information
is available, a set of these are activated based on the precise
nature of device the kernel boots up on. It is interesting to
remember that each IP which belongs to a voltage domain may define
their own set of OPPs on top of this.
This introduces a common handling OPP mechanism accross all OMAPs.
As a start this is introduced for OMAP3 and intends to replace
current OMAP3 opp handling mechanism.
Note:
fields of struct omap_opp is currently exposed due to the necessity
that SRF and SR logic directly indexes the structure array fields.
The goal however, is to make the direct usage of omap_opp deprecated
and move to using these accessor functions. The usage in SRF and SR
indexes based on opp_id and hence opp_id is marked deprecated to
generate build warnings at least. Further, this usage necessitates
need of terminator entries at the start and end of opp_* tables which
are dynamically allocated.
The accessor function definitions were collaborated with Kevin, and
doing justice here, this implementation could not go with some of
the better suggestions from kevin due to constraint imposed by SRF
and SR. A better and more optimal implementation is definitely
possible once SRF and SR are cleanedup/replaced.
NOTE: OPP is a concept that can be used in all OMAPs, it is hence
introduced under plat-omap
Introduces warning:
arch/arm/plat-omap/opp.c: In function 'opp_add':
arch/arm/plat-omap/opp.c:191: warning: 'opp_id' is deprecated (declared at
arch/arm/plat-omap/include/plat/opp.h:33)
arch/arm/plat-omap/opp.c:199: warning: 'opp_id' is deprecated (declared at
arch/arm/plat-omap/include/plat/opp.h:33)
arch/arm/plat-omap/opp.c: In function 'opp_init_list':
arch/arm/plat-omap/opp.c:240: warning: 'opp_id' is deprecated (declared at
arch/arm/plat-omap/include/plat/opp.h:33)
Cc: Benoit Cousson b-cous...@ti.com
Cc: Eduardo Valentin eduardo.valen...@nokia.com
Cc: Madhusudhan Chikkature Rajashekar madhu...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Romit Dasgupta ro...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Sergio Alberto Aguirre Rodriguez saagui...@ti.com
Cc: Tero Kristo tero.kri...@nokia.com
Cc: Thara Gopinath th...@ti.com
Cc: Vishwanath Sripathy vishwanath...@ti.com
Signed-off-by: Sanjeev Premi pr...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Nishanth Menon n...@ti.com
---
Kevin,
I have put your Signed-off-by to ack your contribs. pending
formal confirmation ofcourse.
arch/arm/plat-omap/Makefile |3 +
arch/arm/plat-omap/include/plat/opp.h | 230
arch/arm/plat-omap/opp.c | 271 +
3 files changed, 504 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-omap/include/plat/opp.h
create mode 100644 arch/arm/plat-omap/opp.c
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index 95f8413..e9cf601 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -12,6 +12,9 @@ obj- :=
# OCPI interconnect support for 1710, 1610 and 5912
obj-$(CONFIG_ARCH_OMAP16XX) += ocpi.o
+# OPP support in (OMAP3+ only at the moment)
+obj-$(CONFIG_ARCH_OMAP3) += opp.o
+
# omap_device support (OMAP2+ only at the moment)
obj-$(CONFIG_ARCH_OMAP2) += omap_device.o
obj-$(CONFIG_ARCH_OMAP3) += omap_device.o
diff --git a/arch/arm/plat-omap/include/plat/opp.h
b/arch/arm/plat-omap/include/plat/opp.h
new file mode 100644
index 000..341c02b
--- /dev/null
+++ b/arch/arm/plat-omap/include/plat/opp.h
@@ -0,0 +1,230 @@
+/*
+ * 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
+#define __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 microvolts in future)
+ * uV = ((vsel *
[PATCH 07/10 V4] omap3: clk: use pm accessor functions for cpufreq table
omap2_clk_init_cpufreq_table currently directly accesses the opp
table, making it unscalable to various OMAPs. Instead use the
accessor functions to populate the cpufreq table.
includes fixes from comment:
http://marc.info/?l=linux-omapm=126027057909254w=2
Cc: Benoit Cousson b-cous...@ti.com
Cc: Eduardo Valentin eduardo.valen...@nokia.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Madhusudhan Chikkature Rajashekar madhu...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Romit Dasgupta ro...@ti.com
Cc: Sanjeev Premi pr...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Sergio Alberto Aguirre Rodriguez saagui...@ti.com
Cc: Tero Kristo tero.kri...@nokia.com
Cc: Thara Gopinath th...@ti.com
Cc: Vishwanath Sripathy vishwanath...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/clock34xx.c | 40 ++
1 files changed, 27 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
index 5150939..6c4a609 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -1042,30 +1042,44 @@ static unsigned long omap3_clkoutx2_recalc(struct clk
*clk)
#if defined(CONFIG_ARCH_OMAP3)
#ifdef CONFIG_CPU_FREQ
-static struct cpufreq_frequency_table freq_table[MAX_VDD1_OPP+1];
+
+static struct cpufreq_frequency_table *freq_table;
void omap2_clk_init_cpufreq_table(struct cpufreq_frequency_table **table)
{
- struct omap_opp *prcm;
int i = 0;
+ int opp_num;
+ struct omap_opp *opp = mpu_opps;
+ unsigned long freq = ULONG_MAX;
- if (!mpu_opps)
+ if (!mpu_opps) {
+ pr_warning(%s: failed to initialize frequency
+ table\n, __func__);
+ return;
+ }
+ opp_num = opp_get_opp_count(mpu_opps);
+ if (opp_num 0) {
+ pr_err(%s: no opp table?\n, __func__);
return;
-
- prcm = mpu_opps + MAX_VDD1_OPP;
- for (; prcm-rate; prcm--) {
- freq_table[i].index = i;
- freq_table[i].frequency = prcm-rate / 1000;
- i++;
}
- if (i == 0) {
- printk(KERN_WARNING %s: failed to initialize frequency \
- table\n,
- __func__);
+ freq_table = kmalloc(sizeof(struct cpufreq_frequency_table) *
+ (opp_num + 1), GFP_ATOMIC);
+ if (!freq_table) {
+ pr_warning(%s: failed to allocate frequency
+ table\n, __func__);
return;
}
+ while (!IS_ERR(opp = opp_find_freq_approx(opp, freq,
+ OPP_SEARCH_LOW))) {
+ freq_table[i].index = i;
+ freq_table[i].frequency = freq / 1000;
+ i++;
+ /* set the next benchmark to search */
+ freq--;
+ }
+
freq_table[i].index = i;
freq_table[i].frequency = CPUFREQ_TABLE_END;
--
1.6.3.3
--
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 09/10 V4] omap3: pm: introduce 3630 opps
Introduce the OMAP3630 OPPs including the defined OPP tuples.
Further information on OMAP3630 can be found here:
http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateId=6123navigationId=12836contentId=52606
OMAP36xx family introduces:
VDD1 with 4 OPPs, of which OPP3 4 are available only on devices yet
to be introduced in 36xx family. Meanwhile, VDD2 has 2 opps.
Device Support of OPPs-
|-3630-600-| (default)
|- 3630-800-| (device: TBD)
|- 3630-1000-| (device: TBD)
H/w OPP- OPP50 OPP100 OPP-Turbo OPP1G-SB
VDD1 OPP1 OPP2 OPP3OPP4
VDD2 OPP1 OPP2 OPP2OPP2
Note:
a) TI h/w naming for OPPs are now standardized in terms of OPP50, 100,
Turbo and SB. This maps as shown above to the opp IDs (s/w term).
b) For boards which need custom VDD1/2 OPPs, the opp table can be
updated by the board file on a need basis after the
omap3_pm_init_opp_table call. The OPPs introduced here are the
official OPP table at this point in time.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Eduardo Valentin eduardo.valen...@nokia.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Madhusudhan Chikkature Rajashekar madhu...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Romit Dasgupta ro...@ti.com
Cc: Sanjeev Premi pr...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Sergio Alberto Aguirre Rodriguez saagui...@ti.com
Cc: Tero Kristo tero.kri...@nokia.com
Cc: Thara Gopinath th...@ti.com
Cc: Vishwanath Sripathy vishwanath...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/pm34xx.c | 43 +-
1 files changed, 42 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index e40a036..e5fa5bf 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -140,6 +140,38 @@ static struct omap_opp_def __initdata
omap34xx_dsp_rate_table[] = {
OMAP_OPP_DEF_TERMINATOR
};
+static struct omap_opp_def __initdata omap36xx_mpu_rate_table[] = {
+ /* OPP1 - OPP50 */
+ OMAP_OPP_DEF(true, 3, 93),
+ /* OPP2 - OPP100 */
+ OMAP_OPP_DEF(true, 6, 110),
+ /* OPP3 - OPP-Turbo */
+ OMAP_OPP_DEF(false, 8, 126),
+ /* OPP4 - OPP-SB */
+ OMAP_OPP_DEF(false, 10, 131),
+ OMAP_OPP_DEF_TERMINATOR
+};
+
+static struct omap_opp_def __initdata omap36xx_l3_rate_table[] = {
+ /* OPP1 - OPP50 */
+ OMAP_OPP_DEF(true, 1, 93),
+ /* OPP2 - OPP100, OPP-Turbo, OPP-SB */
+ OMAP_OPP_DEF(true, 2, 1137500),
+ OMAP_OPP_DEF_TERMINATOR
+};
+
+static struct omap_opp_def __initdata omap36xx_dsp_rate_table[] = {
+ /* OPP1 - OPP50 */
+ OMAP_OPP_DEF(true, 26000, 93),
+ /* OPP2 - OPP100 */
+ OMAP_OPP_DEF(true, 52000, 110),
+ /* OPP3 - OPP-Turbo */
+ OMAP_OPP_DEF(false, 66000, 126),
+ /* OPP4 - OPP-SB */
+ OMAP_OPP_DEF(false, 87500, 131),
+ OMAP_OPP_DEF_TERMINATOR
+};
+
/* OMAP3 Rate Table */
struct omap_opp *omap3_mpu_rate_table;
struct omap_opp *omap3_dsp_rate_table;
@@ -1296,18 +1328,27 @@ static void __init configure_vc(void)
void __init omap3_pm_init_opp_table(void)
{
int i;
+ struct omap_opp_def **omap3_opp_def_list;
struct omap_opp_def *omap34xx_opp_def_list[] = {
omap34xx_mpu_rate_table,
omap34xx_l3_rate_table,
omap34xx_dsp_rate_table
};
+ struct omap_opp_def *omap36xx_opp_def_list[] = {
+ omap36xx_mpu_rate_table,
+ omap36xx_l3_rate_table,
+ omap36xx_dsp_rate_table
+ };
struct omap_opp **omap3_rate_tables[] = {
omap3_mpu_rate_table,
omap3_l3_rate_table,
omap3_dsp_rate_table
};
+
+ omap3_opp_def_list = cpu_is_omap3630() ? omap36xx_opp_def_list :
+ omap34xx_opp_def_list;
for (i = 0; i ARRAY_SIZE(omap3_rate_tables); i++) {
- *omap3_rate_tables[i] = opp_init_list(omap34xx_opp_def_list[i]);
+ *omap3_rate_tables[i] = opp_init_list(omap3_opp_def_list[i]);
/* We dont want half configured system at the moment */
BUG_ON(IS_ERR(omap3_rate_tables[i]));
}
--
1.6.3.3
--
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 05/10 V4] omap3: pm: sr: replace get_opp with freq_to_opp
SmartReflex implements a get_opp to search through the opp table,
replace it opp_is_valid to verify the OPPs and getting the opp_id.
NOTE: usage of opp_id is deprecated and this introduces the following
warnings:
arch/arm/mach-omap2/smartreflex.c: In function 'get_vdd1_opp':
arch/arm/mach-omap2/smartreflex.c:161: warning: 'opp_id' is deprecated
(declared at arch/arm/plat-omap/include/plat/opp.h:33)
arch/arm/mach-omap2/smartreflex.c: In function 'get_vdd2_opp':
arch/arm/mach-omap2/smartreflex.c:176: warning: 'opp_id' is deprecated
(declared at arch/arm/plat-omap/include/plat/opp.h:33)
Cc: Benoit Cousson b-cous...@ti.com
Cc: Eduardo Valentin eduardo.valen...@nokia.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Madhusudhan Chikkature Rajashekar madhu...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Romit Dasgupta ro...@ti.com
Cc: Sanjeev Premi pr...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Sergio Alberto Aguirre Rodriguez saagui...@ti.com
Cc: Tero Kristo tero.kri...@nokia.com
Cc: Thara Gopinath th...@ti.com
Cc: Vishwanath Sripathy vishwanath...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/smartreflex.c | 44 +++-
1 files changed, 14 insertions(+), 30 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index be3a1da..ccc98a0 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -146,50 +146,34 @@ static u32 cal_test_nvalue(u32 sennval, u32 senpval)
(rnsenn NVALUERECIPROCAL_RNSENN_SHIFT);
}
-/* determine the current OPP from the frequency
- * we need to give this function last element of OPP rate table
- * and the frequency
- */
-static u16 get_opp(struct omap_opp *opp_freq_table,
- unsigned long freq)
-{
- struct omap_opp *prcm_config;
-
- prcm_config = opp_freq_table;
-
- if (prcm_config-rate = freq)
- return prcm_config-opp_id; /* Return the Highest OPP */
- for (; prcm_config-rate; prcm_config--)
- if (prcm_config-rate freq)
- return (prcm_config+1)-opp_id;
- else if (prcm_config-rate == freq)
- return prcm_config-opp_id;
- /* Return the least OPP */
- return (prcm_config+1)-opp_id;
-}
-
-static u16 get_vdd1_opp(void)
+static u8 get_vdd1_opp(void)
{
- u16 opp;
+ struct omap_opp *opp;
if (sr1.vdd_opp_clk == NULL || IS_ERR(sr1.vdd_opp_clk) ||
mpu_opps == NULL)
return 0;
- opp = get_opp(mpu_opps + MAX_VDD1_OPP, sr1.vdd_opp_clk-rate);
- return opp;
+ opp = opp_find_freq_exact(mpu_opps, sr1.vdd_opp_clk-rate, true);
+ if (IS_ERR(opp))
+ return 0;
+
+ return opp-opp_id;
}
-static u16 get_vdd2_opp(void)
+static u8 get_vdd2_opp(void)
{
- u16 opp;
+ struct omap_opp *opp;
if (sr2.vdd_opp_clk == NULL || IS_ERR(sr2.vdd_opp_clk) ||
l3_opps == NULL)
return 0;
- opp = get_opp(l3_opps + MAX_VDD2_OPP, sr2.vdd_opp_clk-rate);
- return opp;
+ opp = opp_find_freq_exact(l3_opps, sr2.vdd_opp_clk-rate, true);
+ if (IS_ERR(opp))
+ return 0;
+
+ return opp-opp_id;
}
--
1.6.3.3
--
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 v2] omap3: cm-t35: add mux initialization
CM-T35 can be assembled with different set of peripherals thus making
certain interfaces available to user as GPIOs or dedicated pins. Because
of it CM-T35 bootloader sets up mux configuration only for pins
necessary to boot the system and the rest of the mux configuration is
done by the kernel. Besides, having mux configuration in the kernel
allows to minimize dependancy on bootloader.
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
arch/arm/mach-omap2/Kconfig|1 +
arch/arm/mach-omap2/board-cm-t35.c | 95 +--
2 files changed, 90 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 034d990..96e7e3f 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -108,6 +108,7 @@ config MACH_OMAP_ZOOM3
config MACH_CM_T35
bool CompuLab CM-T35 module
depends on ARCH_OMAP3 ARCH_OMAP34XX
+ select OMAP_MUX
config MACH_IGEP0020
bool IGEP0020
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index e5f3039..c28afd6 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -482,13 +482,98 @@ static void __init cm_t35_map_io(void)
omap2_map_common_io();
}
-#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
+ /* nCS and IRQ for CM-T35 ethernet */
+ OMAP3_MUX(GPMC_NCS5, OMAP_MUX_MODE0),
+ OMAP3_MUX(UART3_CTS_RCTX, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP),
+
+ /* nCS and IRQ for SB-T35 ethernet */
+ OMAP3_MUX(GPMC_NCS4, OMAP_MUX_MODE0),
+ OMAP3_MUX(GPMC_WAIT3, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP),
+
+ /* PENDOWN GPIO */
+ OMAP3_MUX(GPMC_NCS6, OMAP_MUX_MODE4 | OMAP_PIN_INPUT),
+
+ /* mUSB */
+ OMAP3_MUX(HSUSB0_CLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_STP, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(HSUSB0_DIR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_NXT, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA0, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA1, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA2, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA3, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA4, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA5, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA6, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA7, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+
+ /* MMC 2 */
+ OMAP3_MUX(MMC2_DAT4, OMAP_MUX_MODE1 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(MMC2_DAT5, OMAP_MUX_MODE1 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(MMC2_DAT6, OMAP_MUX_MODE1 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(MMC2_DAT7, OMAP_MUX_MODE1 | OMAP_PIN_INPUT),
+
+ /* McSPI 1 */
+ OMAP3_MUX(MCSPI1_CLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(MCSPI1_SIMO, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(MCSPI1_SOMI, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(MCSPI1_CS0, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLDOWN),
+
+ /* McSPI 4 */
+ OMAP3_MUX(MCBSP1_CLKR, OMAP_MUX_MODE1 | OMAP_PIN_INPUT),
+ OMAP3_MUX(MCBSP1_DX, OMAP_MUX_MODE1 | OMAP_PIN_INPUT),
+ OMAP3_MUX(MCBSP1_DR, OMAP_MUX_MODE1 | OMAP_PIN_INPUT),
+ OMAP3_MUX(MCBSP1_FSX, OMAP_MUX_MODE1 | OMAP_PIN_INPUT_PULLUP),
+
+ /* McBSP 2 */
+ OMAP3_MUX(MCBSP2_FSX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(MCBSP2_CLKX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(MCBSP2_DR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(MCBSP2_DX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+
+ /* serial ports */
+ OMAP3_MUX(MCBSP3_CLKX, OMAP_MUX_MODE1 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(MCBSP3_FSX, OMAP_MUX_MODE1 | OMAP_PIN_INPUT),
+ OMAP3_MUX(UART1_TX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(UART1_RX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+
+ /* DSS */
+ OMAP3_MUX(DSS_PCLK, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_HSYNC, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_VSYNC, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_ACBIAS, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA0, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA1, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA2, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA3, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA4, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA5, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA6, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA7, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA8, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA9, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA10, OMAP_MUX_MODE0 |
[GIT PULL] OMAP clock, SDRC, PM, hwmod updates for 2.6.33
Hello Tony,
The following changes since commit 9a01609e1885b827b979d6d9dd86f43208a9e5fc:
Olof Johansson (1):
arm: omap: Add omap3_defconfig
are available in the git repository at:
git://git.pwsan.com/linux-2.6 for_2_6_33
Kevin Hilman (6):
OMAP: omap_device: add to_omap_device() macro
OMAP: omap_device: use UINT_MAX for default wakeup latency limit
OMAP: omap_device: use read_persistent_clock() instead of getnstimeofday()
OMAP: hwmod: warn on missing clockdomain
OMAP: omap_device: fix nsec/usec conversion in latency calculations
OMAP: omap_device: track latency in nanoseconds
Paul Walmsley (19):
OMAP1/2/3 clock: remove paranoid checks in preparation for
clock{,2xxx,3xxx}_data.c
OMAP2 clock: APLL code shouldn't rely on static clocks in its local
namespace
OMAP2/3: move SDRC macros to mach-omap2/sdrc.h
OMAP2xxx clock: remove implicit dependency between rate CPU flag and
clkdev_omap CPU flag
OMAP3 clock: convert clock34xx.h to clock34xx_data.c
OMAP2 clock: convert clock24xx.h to clock2xxx_data.c, opp2xxx*
OMAP1 clock: convert test in disable_unused() to use ENABLE_ON_INIT
OMAP1 clock: convert mach-omap1/clock.h to mach-omap1/clock_data.c
OMAP2/3 PRCM: don't export prm_*(), cm_*() functions
OMAP clockdomain/powerdomain: remove CONFIG_OMAP_DEBUG_{CLOCK,POWER}DOMAIN
OMAP clockdomain/powerdomain: optimize out sleepdep code on OMAP24xx
OMAP powerdomain/PM: use symbolic constants for the max number of power
states
OMAP powerdomain: rearrange struct powerdomain to save some memory
OMAP3: SDRC: Place SDRC AC timing and MR changes in CORE DVFS SRAM code
behind Kconfig
OMAP clock/hwmod: fix off-by-one errors
OMAP3 hwmod: reprogram OCP_SYSCONFIG register after setting SOFTRESET
OMAP3 hwmod: Add automatic OCP_SYSCONFIG AUTOIDLE handling
OMAP hwmod: add names to module MPU IRQ lines
OMAP3 hwmod: drop most of the OCP_SYSCONFIG.CLOCKACTIVITY code
Rajendra Nayak (11):
ARM: OMAP4: PM: Fix the PRM and CM base addresses
ARM: OMAP4: PM: PRM/CM module offsets for OMAP4
ARM: OMAP4: PM: Adds CM1/2 register defs for OMAP4
ARM: OMAP4: PM: Adds PRM register defs for OMAP4
ARM: OMAP4: PM: Adds PRM register shift and mask bits
ARM: OMAP4: PM: Adds CM1/2 register field masks
ARM: OMAP4: PM: OMAP4 clock tree and clkdev registration
ARM: OMAP4: PM: Add dummy hooks for OMAP4 dpll api's
ARM: OMAP4: PM: Move DPLL control apis to dpll.c
ARM: OMAP4: PM: Add support for OMAP4 dpll api's
ARM: OMAP4: PM: Add init api for DPLL nodes
Roel Kluin (1):
OMAP2/3 powerdomain: return errors rather than returning the output of
IS_ERR()
Thara Gopinath (1):
OMAP3: PM: Fix for MPU power domain MEM BANK position
arch/arm/mach-omap1/Makefile |3 +-
arch/arm/mach-omap1/clock.c| 499 +---
arch/arm/mach-omap1/clock.h| 647 +
arch/arm/mach-omap1/clock_data.c | 843 +
arch/arm/mach-omap1/io.c |3 +-
arch/arm/mach-omap1/opp.h | 28 +
arch/arm/mach-omap1/opp_data.c | 59 +
arch/arm/mach-omap2/Kconfig| 13 +
arch/arm/mach-omap2/Makefile | 14 +-
arch/arm/mach-omap2/clock.c| 47 +-
arch/arm/mach-omap2/clock.h| 50 +-
arch/arm/mach-omap2/clock24xx.c| 805 -
.../mach-omap2/{clock24xx.h = clock2xxx_data.c} | 836 ++
arch/arm/mach-omap2/clock34xx.c| 953 +--
arch/arm/mach-omap2/clock34xx.h| 2999 +--
arch/arm/mach-omap2/clock34xx_data.c | 3289
arch/arm/mach-omap2/clock44xx.c| 33 +
arch/arm/mach-omap2/clock44xx.h| 15 +
arch/arm/mach-omap2/clock44xx_data.c | 2766
arch/arm/mach-omap2/clockdomain.c |6 +-
arch/arm/mach-omap2/cm-regbits-44xx.h | 1474 +
arch/arm/mach-omap2/cm.c |7 +-
arch/arm/mach-omap2/cm.h | 15 +-
arch/arm/mach-omap2/cm44xx.h | 358 +++
arch/arm/mach-omap2/dpll.c | 538
arch/arm/mach-omap2/gpmc.c |2 +-
arch/arm/mach-omap2/io.c |4 +-
arch/arm/mach-omap2/omap_hwmod.c | 164 +-
arch/arm/mach-omap2/pm-debug.c |4 +-
arch/arm/mach-omap2/powerdomain.c | 36 +-
arch/arm/mach-omap2/powerdomains34xx.h |1 +
arch/arm/mach-omap2/prcm-common.h | 73 +-
arch/arm/mach-omap2/prcm.c | 13 +-
