| 
									
										
											  
											
												OMAP2 clock: split OMAP2420, OMAP2430 clock data into their own files
In preparation for multi-OMAP2 kernels, split
mach-omap2/clock2xxx_data.c into mach-omap2/clock2420_data.c and
mach-omap2/clock2430_data.c.  2430 uses a different device space
physical memory layout than past or future OMAPs, and we use a
different virtual memory layout as well, which causes trouble for
architecture-level code/data that tries to support both.  We tried
using offsets from the virtual base last year, but those patches never
made it upstream; so after some discussion with Tony about the best
all-around approach, we'll just grit our teeth and duplicate the
structures.  The maintenance advantages of a single kernel config that
can compile and boot on OMAP2, 3, and 4 platforms are simply too
compelling.
This approach does have some nice benefits beyond multi-OMAP 2 kernel
support.  The runtime size of OMAP2420-specific and OMAP2430-specific
kernels is smaller, since unused clocks for the other OMAP2 chip will
no longer be compiled in.  (At some point we will mark the clock data
__initdata and allocate it during registration, which will eliminate
the runtime memory advantage.)  It also makes the clock trees slightly
easier to read, since 2420-specific and 2430-specific clocks are no
longer mixed together.
This patch also splits 2430-specific clock code into its own file,
mach-omap2/clock2430.c, which is only compiled in for 2430 builds -
mostly for organizational clarity.
While here, fix a bug in the OMAP2430 clock tree: "emul_ck" was
incorrectly marked as being 2420-only, when actually it is present on
both OMAP2420 and OMAP2430.
Thanks to Tony for some good discussions about how to approach this
problem.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Richard Woodruff <r-woodruff2@ti.com>
											
										 
											2010-02-22 22:09:22 -07:00
										 |  |  | /*
 | 
					
						
							|  |  |  |  * clock2430.c - OMAP2430-specific clock integration code | 
					
						
							|  |  |  |  * | 
					
						
							|  |  |  |  * Copyright (C) 2005-2008 Texas Instruments, Inc. | 
					
						
							|  |  |  |  * Copyright (C) 2004-2010 Nokia Corporation | 
					
						
							|  |  |  |  * | 
					
						
							|  |  |  |  * Contacts: | 
					
						
							|  |  |  |  * Richard Woodruff <r-woodruff2@ti.com> | 
					
						
							|  |  |  |  * Paul Walmsley | 
					
						
							|  |  |  |  * | 
					
						
							|  |  |  |  * Based on earlier work by Tuukka Tikkanen, Tony Lindgren, | 
					
						
							|  |  |  |  * Gordon McNutt and RidgeRun, Inc. | 
					
						
							|  |  |  |  * | 
					
						
							|  |  |  |  * 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. | 
					
						
							|  |  |  |  */ | 
					
						
							|  |  |  | #undef DEBUG
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | #include <linux/kernel.h>
 | 
					
						
							|  |  |  | #include <linux/clk.h>
 | 
					
						
							|  |  |  | #include <linux/io.h>
 | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2012-08-31 10:59:07 -07:00
										 |  |  | #include "soc.h"
 | 
					
						
							| 
									
										
										
										
											2012-02-24 10:34:35 -08:00
										 |  |  | #include "iomap.h"
 | 
					
						
							| 
									
										
											  
											
												OMAP2 clock: split OMAP2420, OMAP2430 clock data into their own files
In preparation for multi-OMAP2 kernels, split
mach-omap2/clock2xxx_data.c into mach-omap2/clock2420_data.c and
mach-omap2/clock2430_data.c.  2430 uses a different device space
physical memory layout than past or future OMAPs, and we use a
different virtual memory layout as well, which causes trouble for
architecture-level code/data that tries to support both.  We tried
using offsets from the virtual base last year, but those patches never
made it upstream; so after some discussion with Tony about the best
all-around approach, we'll just grit our teeth and duplicate the
structures.  The maintenance advantages of a single kernel config that
can compile and boot on OMAP2, 3, and 4 platforms are simply too
compelling.
This approach does have some nice benefits beyond multi-OMAP 2 kernel
support.  The runtime size of OMAP2420-specific and OMAP2430-specific
kernels is smaller, since unused clocks for the other OMAP2 chip will
no longer be compiled in.  (At some point we will mark the clock data
__initdata and allocate it during registration, which will eliminate
the runtime memory advantage.)  It also makes the clock trees slightly
easier to read, since 2420-specific and 2430-specific clocks are no
longer mixed together.
This patch also splits 2430-specific clock code into its own file,
mach-omap2/clock2430.c, which is only compiled in for 2430 builds -
mostly for organizational clarity.
While here, fix a bug in the OMAP2430 clock tree: "emul_ck" was
incorrectly marked as being 2420-only, when actually it is present on
both OMAP2420 and OMAP2430.
Thanks to Tony for some good discussions about how to approach this
problem.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Richard Woodruff <r-woodruff2@ti.com>
											
										 
											2010-02-22 22:09:22 -07:00
										 |  |  | #include "clock.h"
 | 
					
						
							|  |  |  | #include "clock2xxx.h"
 | 
					
						
							| 
									
										
										
										
											2012-10-21 01:01:11 -06:00
										 |  |  | #include "cm2xxx.h"
 | 
					
						
							| 
									
										
											  
											
												OMAP2 clock: split OMAP2420, OMAP2430 clock data into their own files
In preparation for multi-OMAP2 kernels, split
mach-omap2/clock2xxx_data.c into mach-omap2/clock2420_data.c and
mach-omap2/clock2430_data.c.  2430 uses a different device space
physical memory layout than past or future OMAPs, and we use a
different virtual memory layout as well, which causes trouble for
architecture-level code/data that tries to support both.  We tried
using offsets from the virtual base last year, but those patches never
made it upstream; so after some discussion with Tony about the best
all-around approach, we'll just grit our teeth and duplicate the
structures.  The maintenance advantages of a single kernel config that
can compile and boot on OMAP2, 3, and 4 platforms are simply too
compelling.
This approach does have some nice benefits beyond multi-OMAP 2 kernel
support.  The runtime size of OMAP2420-specific and OMAP2430-specific
kernels is smaller, since unused clocks for the other OMAP2 chip will
no longer be compiled in.  (At some point we will mark the clock data
__initdata and allocate it during registration, which will eliminate
the runtime memory advantage.)  It also makes the clock trees slightly
easier to read, since 2420-specific and 2430-specific clocks are no
longer mixed together.
This patch also splits 2430-specific clock code into its own file,
mach-omap2/clock2430.c, which is only compiled in for 2430 builds -
mostly for organizational clarity.
While here, fix a bug in the OMAP2430 clock tree: "emul_ck" was
incorrectly marked as being 2420-only, when actually it is present on
both OMAP2420 and OMAP2430.
Thanks to Tony for some good discussions about how to approach this
problem.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Richard Woodruff <r-woodruff2@ti.com>
											
										 
											2010-02-22 22:09:22 -07:00
										 |  |  | #include "cm-regbits-24xx.h"
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | /**
 | 
					
						
							|  |  |  |  * omap2430_clk_i2chs_find_idlest - return CM_IDLEST info for 2430 I2CHS | 
					
						
							|  |  |  |  * @clk: struct clk * being enabled | 
					
						
							|  |  |  |  * @idlest_reg: void __iomem ** to store CM_IDLEST reg address into | 
					
						
							|  |  |  |  * @idlest_bit: pointer to a u8 to store the CM_IDLEST bit shift into | 
					
						
							|  |  |  |  * @idlest_val: pointer to a u8 to store the CM_IDLEST indicator | 
					
						
							|  |  |  |  * | 
					
						
							|  |  |  |  * OMAP2430 I2CHS CM_IDLEST bits are in CM_IDLEST1_CORE, but the | 
					
						
							|  |  |  |  * CM_*CLKEN bits are in CM_{I,F}CLKEN2_CORE.  This custom function | 
					
						
							|  |  |  |  * passes back the correct CM_IDLEST register address for I2CHS | 
					
						
							|  |  |  |  * modules.  No return value. | 
					
						
							|  |  |  |  */ | 
					
						
							| 
									
										
										
										
											2012-04-27 15:59:32 +05:30
										 |  |  | static void omap2430_clk_i2chs_find_idlest(struct clk_hw_omap *clk, | 
					
						
							| 
									
										
											  
											
												OMAP2 clock: split OMAP2420, OMAP2430 clock data into their own files
In preparation for multi-OMAP2 kernels, split
mach-omap2/clock2xxx_data.c into mach-omap2/clock2420_data.c and
mach-omap2/clock2430_data.c.  2430 uses a different device space
physical memory layout than past or future OMAPs, and we use a
different virtual memory layout as well, which causes trouble for
architecture-level code/data that tries to support both.  We tried
using offsets from the virtual base last year, but those patches never
made it upstream; so after some discussion with Tony about the best
all-around approach, we'll just grit our teeth and duplicate the
structures.  The maintenance advantages of a single kernel config that
can compile and boot on OMAP2, 3, and 4 platforms are simply too
compelling.
This approach does have some nice benefits beyond multi-OMAP 2 kernel
support.  The runtime size of OMAP2420-specific and OMAP2430-specific
kernels is smaller, since unused clocks for the other OMAP2 chip will
no longer be compiled in.  (At some point we will mark the clock data
__initdata and allocate it during registration, which will eliminate
the runtime memory advantage.)  It also makes the clock trees slightly
easier to read, since 2420-specific and 2430-specific clocks are no
longer mixed together.
This patch also splits 2430-specific clock code into its own file,
mach-omap2/clock2430.c, which is only compiled in for 2430 builds -
mostly for organizational clarity.
While here, fix a bug in the OMAP2430 clock tree: "emul_ck" was
incorrectly marked as being 2420-only, when actually it is present on
both OMAP2420 and OMAP2430.
Thanks to Tony for some good discussions about how to approach this
problem.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Richard Woodruff <r-woodruff2@ti.com>
											
										 
											2010-02-22 22:09:22 -07:00
										 |  |  | 					   void __iomem **idlest_reg, | 
					
						
							|  |  |  | 					   u8 *idlest_bit, | 
					
						
							|  |  |  | 					   u8 *idlest_val) | 
					
						
							|  |  |  | { | 
					
						
							|  |  |  | 	*idlest_reg = OMAP2430_CM_REGADDR(CORE_MOD, CM_IDLEST); | 
					
						
							|  |  |  | 	*idlest_bit = clk->enable_bit; | 
					
						
							|  |  |  | 	*idlest_val = OMAP24XX_CM_IDLEST_VAL; | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | /* 2430 I2CHS has non-standard IDLEST register */ | 
					
						
							| 
									
										
										
										
											2012-04-27 15:59:32 +05:30
										 |  |  | const struct clk_hw_omap_ops clkhwops_omap2430_i2chs_wait = { | 
					
						
							|  |  |  | 	.find_idlest	= omap2430_clk_i2chs_find_idlest, | 
					
						
							|  |  |  | 	.find_companion	= omap2_clk_dflt_find_companion, | 
					
						
							|  |  |  | }; |