| 
									
										
										
										
											2008-03-18 15:09:51 +02:00
										 |  |  | /*
 | 
					
						
							|  |  |  |  * OMAP3-specific clock framework functions | 
					
						
							|  |  |  |  * | 
					
						
							| 
									
										
										
										
											2008-07-03 12:24:45 +03:00
										 |  |  |  * Copyright (C) 2007-2008 Texas Instruments, Inc. | 
					
						
							| 
									
										
										
										
											2011-02-25 15:39:30 -07:00
										 |  |  |  * Copyright (C) 2007-2011 Nokia Corporation | 
					
						
							| 
									
										
										
										
											2008-03-18 15:09:51 +02:00
										 |  |  |  * | 
					
						
							| 
									
										
										
										
											2010-01-26 20:13:10 -07:00
										 |  |  |  * Paul Walmsley | 
					
						
							|  |  |  |  * Jouni Högander | 
					
						
							| 
									
										
										
										
											2008-03-18 15:09:51 +02:00
										 |  |  |  * | 
					
						
							|  |  |  |  * Parts of this code are based on code written by | 
					
						
							| 
									
										
											  
											
												OMAP3/4 clock: split into per-chip family files
clock34xx_data.c now contains data for the OMAP34xx family, the
OMAP36xx family, and the OMAP3517 family, so rename it to
clock3xxx_data.c.  Rename clock34xx.c to clock3xxx.c, and move the
chip family-specific clock functions to clock34xx.c, clock36xx.c, or
clock3517.c, as appropriate.  So now "clock3xxx.*" refers to the OMAP3
superset.
The main goal here is to prepare to compile chip family-specific clock
functions only for kernel builds that target that chip family.  To get to
that point, we also need to add CONFIG_SOC_* options for those other
chip families; that will be done in future patches, planned for 2.6.35.
OMAP4 is also affected by this.  It duplicated the OMAP3 non-CORE DPLL
clkops structure.  The OMAP4 variant of this clkops structure has been
removed, and since there was nothing else currently in clock44xx.c, it
too has been removed -- it can always be added back later when there
is some content for it.  (The OMAP4 clock autogeneration scripts have been
updated accordingly.)
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Ranjith Lohithakshan <ranjithl@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
											
										 
											2010-02-22 22:09:20 -07:00
										 |  |  |  * Richard Woodruff, Tony Lindgren, Tuukka Tikkanen, Karthik Dasu, | 
					
						
							|  |  |  |  * Russell King | 
					
						
							| 
									
										
										
										
											2008-03-18 15:09:51 +02:00
										 |  |  |  * | 
					
						
							|  |  |  |  * 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>
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | #include "clock.h"
 | 
					
						
							| 
									
										
										
										
											2009-12-08 16:18:47 -07:00
										 |  |  | #include "clock34xx.h"
 | 
					
						
							| 
									
										
										
										
											2012-10-21 01:01:11 -06:00
										 |  |  | #include "cm3xxx.h"
 | 
					
						
							| 
									
										
										
										
											2008-03-18 15:09:51 +02:00
										 |  |  | #include "cm-regbits-34xx.h"
 | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
											  
											
												OMAP3 clock: correct module IDLEST bits: SSI; DSS; USBHOST; HSOTGUSB
Fix two bugs in the OMAP3 clock tree pertaining to the SSI, DSS,
USBHOST, and HSOTGUSB devices.  These devices are both interconnect
initiators and targets.  Without this patch, clk_enable()s on clocks for
these modules can be very high latency (potentially up to ~200
milliseconds) and message such as the following are generated:
    Clock usbhost_48m_fck didn't enable in 100000 tries
Two bugs are fixed by this patch.  First, OMAP hardware only supports
target CM_IDLEST register bits on ES2+ chips and beyond.  ES1 chips
should not wait for these clocks to enable.  So, split the appropriate
clocks into ES1 and ES2+ variants, so that kernels running on ES1
devices won't try to wait.
Second, the current heuristic in omap2_clk_dflt_find_idlest() will
fail for these clocks.  It assumes that the CM_IDLEST bit to wait upon
is the same as the CM_*CLKEN bit, which is false[1].  Fix by
implementing custom clkops .find_idlest function pointers for the
appropriate clocks that return the correct slave IDLEST bit shift.
This was originally fixed in the linux-omap kernel during 2.6.29 in a
slightly different manner[2][3].
In the medium-term future, all of the module IDLEST code will
eventually be moved to the omap_hwmod code.
Problem reported by Jarkko Nikula <jhnikula@gmail.com>:
    http://marc.info/?l=linux-omap&m=124306184903679&w=2
...
1. See for example 34xx TRM Revision P Table 4-213 and 4-217 (for the
   DSS case).
2. http://www.spinics.net/lists/linux-omap/msg05512.html et seq.
3. http://lkml.indiana.edu/hypermail/linux/kernel/0901.3/01498.html
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Jarkko Nikula <jhnikula@gmail.com>
											
										 
											2009-07-24 19:44:06 -06:00
										 |  |  | /**
 | 
					
						
							|  |  |  |  * omap3430es2_clk_ssi_find_idlest - return CM_IDLEST info for SSI | 
					
						
							|  |  |  |  * @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 | 
					
						
							| 
									
										
										
										
											2010-02-24 12:05:54 -07:00
										 |  |  |  * @idlest_val: pointer to a u8 to store the CM_IDLEST indicator | 
					
						
							| 
									
										
											  
											
												OMAP3 clock: correct module IDLEST bits: SSI; DSS; USBHOST; HSOTGUSB
Fix two bugs in the OMAP3 clock tree pertaining to the SSI, DSS,
USBHOST, and HSOTGUSB devices.  These devices are both interconnect
initiators and targets.  Without this patch, clk_enable()s on clocks for
these modules can be very high latency (potentially up to ~200
milliseconds) and message such as the following are generated:
    Clock usbhost_48m_fck didn't enable in 100000 tries
Two bugs are fixed by this patch.  First, OMAP hardware only supports
target CM_IDLEST register bits on ES2+ chips and beyond.  ES1 chips
should not wait for these clocks to enable.  So, split the appropriate
clocks into ES1 and ES2+ variants, so that kernels running on ES1
devices won't try to wait.
Second, the current heuristic in omap2_clk_dflt_find_idlest() will
fail for these clocks.  It assumes that the CM_IDLEST bit to wait upon
is the same as the CM_*CLKEN bit, which is false[1].  Fix by
implementing custom clkops .find_idlest function pointers for the
appropriate clocks that return the correct slave IDLEST bit shift.
This was originally fixed in the linux-omap kernel during 2.6.29 in a
slightly different manner[2][3].
In the medium-term future, all of the module IDLEST code will
eventually be moved to the omap_hwmod code.
Problem reported by Jarkko Nikula <jhnikula@gmail.com>:
    http://marc.info/?l=linux-omap&m=124306184903679&w=2
...
1. See for example 34xx TRM Revision P Table 4-213 and 4-217 (for the
   DSS case).
2. http://www.spinics.net/lists/linux-omap/msg05512.html et seq.
3. http://lkml.indiana.edu/hypermail/linux/kernel/0901.3/01498.html
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Jarkko Nikula <jhnikula@gmail.com>
											
										 
											2009-07-24 19:44:06 -06:00
										 |  |  |  * | 
					
						
							|  |  |  |  * The OMAP3430ES2 SSI target CM_IDLEST bit is at a different shift | 
					
						
							|  |  |  |  * from the CM_{I,F}CLKEN bit.  Pass back the correct info via | 
					
						
							|  |  |  |  * @idlest_reg and @idlest_bit.  No return value. | 
					
						
							|  |  |  |  */ | 
					
						
							| 
									
										
										
										
											2012-04-27 15:53:48 +05:30
										 |  |  | static void omap3430es2_clk_ssi_find_idlest(struct clk_hw_omap *clk, | 
					
						
							| 
									
										
											  
											
												OMAP3 clock: correct module IDLEST bits: SSI; DSS; USBHOST; HSOTGUSB
Fix two bugs in the OMAP3 clock tree pertaining to the SSI, DSS,
USBHOST, and HSOTGUSB devices.  These devices are both interconnect
initiators and targets.  Without this patch, clk_enable()s on clocks for
these modules can be very high latency (potentially up to ~200
milliseconds) and message such as the following are generated:
    Clock usbhost_48m_fck didn't enable in 100000 tries
Two bugs are fixed by this patch.  First, OMAP hardware only supports
target CM_IDLEST register bits on ES2+ chips and beyond.  ES1 chips
should not wait for these clocks to enable.  So, split the appropriate
clocks into ES1 and ES2+ variants, so that kernels running on ES1
devices won't try to wait.
Second, the current heuristic in omap2_clk_dflt_find_idlest() will
fail for these clocks.  It assumes that the CM_IDLEST bit to wait upon
is the same as the CM_*CLKEN bit, which is false[1].  Fix by
implementing custom clkops .find_idlest function pointers for the
appropriate clocks that return the correct slave IDLEST bit shift.
This was originally fixed in the linux-omap kernel during 2.6.29 in a
slightly different manner[2][3].
In the medium-term future, all of the module IDLEST code will
eventually be moved to the omap_hwmod code.
Problem reported by Jarkko Nikula <jhnikula@gmail.com>:
    http://marc.info/?l=linux-omap&m=124306184903679&w=2
...
1. See for example 34xx TRM Revision P Table 4-213 and 4-217 (for the
   DSS case).
2. http://www.spinics.net/lists/linux-omap/msg05512.html et seq.
3. http://lkml.indiana.edu/hypermail/linux/kernel/0901.3/01498.html
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Jarkko Nikula <jhnikula@gmail.com>
											
										 
											2009-07-24 19:44:06 -06:00
										 |  |  | 					    void __iomem **idlest_reg, | 
					
						
							| 
									
										
										
										
											2010-02-24 12:05:54 -07:00
										 |  |  | 					    u8 *idlest_bit, | 
					
						
							|  |  |  | 					    u8 *idlest_val) | 
					
						
							| 
									
										
											  
											
												OMAP3 clock: correct module IDLEST bits: SSI; DSS; USBHOST; HSOTGUSB
Fix two bugs in the OMAP3 clock tree pertaining to the SSI, DSS,
USBHOST, and HSOTGUSB devices.  These devices are both interconnect
initiators and targets.  Without this patch, clk_enable()s on clocks for
these modules can be very high latency (potentially up to ~200
milliseconds) and message such as the following are generated:
    Clock usbhost_48m_fck didn't enable in 100000 tries
Two bugs are fixed by this patch.  First, OMAP hardware only supports
target CM_IDLEST register bits on ES2+ chips and beyond.  ES1 chips
should not wait for these clocks to enable.  So, split the appropriate
clocks into ES1 and ES2+ variants, so that kernels running on ES1
devices won't try to wait.
Second, the current heuristic in omap2_clk_dflt_find_idlest() will
fail for these clocks.  It assumes that the CM_IDLEST bit to wait upon
is the same as the CM_*CLKEN bit, which is false[1].  Fix by
implementing custom clkops .find_idlest function pointers for the
appropriate clocks that return the correct slave IDLEST bit shift.
This was originally fixed in the linux-omap kernel during 2.6.29 in a
slightly different manner[2][3].
In the medium-term future, all of the module IDLEST code will
eventually be moved to the omap_hwmod code.
Problem reported by Jarkko Nikula <jhnikula@gmail.com>:
    http://marc.info/?l=linux-omap&m=124306184903679&w=2
...
1. See for example 34xx TRM Revision P Table 4-213 and 4-217 (for the
   DSS case).
2. http://www.spinics.net/lists/linux-omap/msg05512.html et seq.
3. http://lkml.indiana.edu/hypermail/linux/kernel/0901.3/01498.html
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Jarkko Nikula <jhnikula@gmail.com>
											
										 
											2009-07-24 19:44:06 -06:00
										 |  |  | { | 
					
						
							|  |  |  | 	u32 r; | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | 	r = (((__force u32)clk->enable_reg & ~0xf0) | 0x20); | 
					
						
							|  |  |  | 	*idlest_reg = (__force void __iomem *)r; | 
					
						
							|  |  |  | 	*idlest_bit = OMAP3430ES2_ST_SSI_IDLE_SHIFT; | 
					
						
							| 
									
										
										
										
											2010-02-24 12:05:54 -07:00
										 |  |  | 	*idlest_val = OMAP34XX_CM_IDLEST_VAL; | 
					
						
							| 
									
										
											  
											
												OMAP3 clock: correct module IDLEST bits: SSI; DSS; USBHOST; HSOTGUSB
Fix two bugs in the OMAP3 clock tree pertaining to the SSI, DSS,
USBHOST, and HSOTGUSB devices.  These devices are both interconnect
initiators and targets.  Without this patch, clk_enable()s on clocks for
these modules can be very high latency (potentially up to ~200
milliseconds) and message such as the following are generated:
    Clock usbhost_48m_fck didn't enable in 100000 tries
Two bugs are fixed by this patch.  First, OMAP hardware only supports
target CM_IDLEST register bits on ES2+ chips and beyond.  ES1 chips
should not wait for these clocks to enable.  So, split the appropriate
clocks into ES1 and ES2+ variants, so that kernels running on ES1
devices won't try to wait.
Second, the current heuristic in omap2_clk_dflt_find_idlest() will
fail for these clocks.  It assumes that the CM_IDLEST bit to wait upon
is the same as the CM_*CLKEN bit, which is false[1].  Fix by
implementing custom clkops .find_idlest function pointers for the
appropriate clocks that return the correct slave IDLEST bit shift.
This was originally fixed in the linux-omap kernel during 2.6.29 in a
slightly different manner[2][3].
In the medium-term future, all of the module IDLEST code will
eventually be moved to the omap_hwmod code.
Problem reported by Jarkko Nikula <jhnikula@gmail.com>:
    http://marc.info/?l=linux-omap&m=124306184903679&w=2
...
1. See for example 34xx TRM Revision P Table 4-213 and 4-217 (for the
   DSS case).
2. http://www.spinics.net/lists/linux-omap/msg05512.html et seq.
3. http://lkml.indiana.edu/hypermail/linux/kernel/0901.3/01498.html
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Jarkko Nikula <jhnikula@gmail.com>
											
										 
											2009-07-24 19:44:06 -06:00
										 |  |  | } | 
					
						
							| 
									
										
										
										
											2012-04-27 15:53:48 +05:30
										 |  |  | const struct clk_hw_omap_ops clkhwops_omap3430es2_ssi_wait = { | 
					
						
							|  |  |  | 	.find_idlest	= omap3430es2_clk_ssi_find_idlest, | 
					
						
							|  |  |  | 	.find_companion	= omap2_clk_dflt_find_companion, | 
					
						
							|  |  |  | }; | 
					
						
							| 
									
										
											  
											
												OMAP3 clock: correct module IDLEST bits: SSI; DSS; USBHOST; HSOTGUSB
Fix two bugs in the OMAP3 clock tree pertaining to the SSI, DSS,
USBHOST, and HSOTGUSB devices.  These devices are both interconnect
initiators and targets.  Without this patch, clk_enable()s on clocks for
these modules can be very high latency (potentially up to ~200
milliseconds) and message such as the following are generated:
    Clock usbhost_48m_fck didn't enable in 100000 tries
Two bugs are fixed by this patch.  First, OMAP hardware only supports
target CM_IDLEST register bits on ES2+ chips and beyond.  ES1 chips
should not wait for these clocks to enable.  So, split the appropriate
clocks into ES1 and ES2+ variants, so that kernels running on ES1
devices won't try to wait.
Second, the current heuristic in omap2_clk_dflt_find_idlest() will
fail for these clocks.  It assumes that the CM_IDLEST bit to wait upon
is the same as the CM_*CLKEN bit, which is false[1].  Fix by
implementing custom clkops .find_idlest function pointers for the
appropriate clocks that return the correct slave IDLEST bit shift.
This was originally fixed in the linux-omap kernel during 2.6.29 in a
slightly different manner[2][3].
In the medium-term future, all of the module IDLEST code will
eventually be moved to the omap_hwmod code.
Problem reported by Jarkko Nikula <jhnikula@gmail.com>:
    http://marc.info/?l=linux-omap&m=124306184903679&w=2
...
1. See for example 34xx TRM Revision P Table 4-213 and 4-217 (for the
   DSS case).
2. http://www.spinics.net/lists/linux-omap/msg05512.html et seq.
3. http://lkml.indiana.edu/hypermail/linux/kernel/0901.3/01498.html
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Jarkko Nikula <jhnikula@gmail.com>
											
										 
											2009-07-24 19:44:06 -06:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2012-04-27 15:53:48 +05:30
										 |  |  | const struct clk_hw_omap_ops clkhwops_omap3430es2_iclk_ssi_wait = { | 
					
						
							|  |  |  | 	.allow_idle	= omap2_clkt_iclk_allow_idle, | 
					
						
							|  |  |  | 	.deny_idle	= omap2_clkt_iclk_deny_idle, | 
					
						
							|  |  |  | 	.find_idlest	= omap3430es2_clk_ssi_find_idlest, | 
					
						
							|  |  |  | 	.find_companion = omap2_clk_dflt_find_companion, | 
					
						
							|  |  |  | }; | 
					
						
							| 
									
										
										
										
											2011-02-25 15:39:30 -07:00
										 |  |  | 
 | 
					
						
							| 
									
										
											  
											
												OMAP3 clock: correct module IDLEST bits: SSI; DSS; USBHOST; HSOTGUSB
Fix two bugs in the OMAP3 clock tree pertaining to the SSI, DSS,
USBHOST, and HSOTGUSB devices.  These devices are both interconnect
initiators and targets.  Without this patch, clk_enable()s on clocks for
these modules can be very high latency (potentially up to ~200
milliseconds) and message such as the following are generated:
    Clock usbhost_48m_fck didn't enable in 100000 tries
Two bugs are fixed by this patch.  First, OMAP hardware only supports
target CM_IDLEST register bits on ES2+ chips and beyond.  ES1 chips
should not wait for these clocks to enable.  So, split the appropriate
clocks into ES1 and ES2+ variants, so that kernels running on ES1
devices won't try to wait.
Second, the current heuristic in omap2_clk_dflt_find_idlest() will
fail for these clocks.  It assumes that the CM_IDLEST bit to wait upon
is the same as the CM_*CLKEN bit, which is false[1].  Fix by
implementing custom clkops .find_idlest function pointers for the
appropriate clocks that return the correct slave IDLEST bit shift.
This was originally fixed in the linux-omap kernel during 2.6.29 in a
slightly different manner[2][3].
In the medium-term future, all of the module IDLEST code will
eventually be moved to the omap_hwmod code.
Problem reported by Jarkko Nikula <jhnikula@gmail.com>:
    http://marc.info/?l=linux-omap&m=124306184903679&w=2
...
1. See for example 34xx TRM Revision P Table 4-213 and 4-217 (for the
   DSS case).
2. http://www.spinics.net/lists/linux-omap/msg05512.html et seq.
3. http://lkml.indiana.edu/hypermail/linux/kernel/0901.3/01498.html
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Jarkko Nikula <jhnikula@gmail.com>
											
										 
											2009-07-24 19:44:06 -06:00
										 |  |  | /**
 | 
					
						
							|  |  |  |  * omap3430es2_clk_dss_usbhost_find_idlest - CM_IDLEST info for DSS, USBHOST | 
					
						
							|  |  |  |  * @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 | 
					
						
							| 
									
										
										
										
											2010-02-24 12:05:54 -07:00
										 |  |  |  * @idlest_val: pointer to a u8 to store the CM_IDLEST indicator | 
					
						
							| 
									
										
											  
											
												OMAP3 clock: correct module IDLEST bits: SSI; DSS; USBHOST; HSOTGUSB
Fix two bugs in the OMAP3 clock tree pertaining to the SSI, DSS,
USBHOST, and HSOTGUSB devices.  These devices are both interconnect
initiators and targets.  Without this patch, clk_enable()s on clocks for
these modules can be very high latency (potentially up to ~200
milliseconds) and message such as the following are generated:
    Clock usbhost_48m_fck didn't enable in 100000 tries
Two bugs are fixed by this patch.  First, OMAP hardware only supports
target CM_IDLEST register bits on ES2+ chips and beyond.  ES1 chips
should not wait for these clocks to enable.  So, split the appropriate
clocks into ES1 and ES2+ variants, so that kernels running on ES1
devices won't try to wait.
Second, the current heuristic in omap2_clk_dflt_find_idlest() will
fail for these clocks.  It assumes that the CM_IDLEST bit to wait upon
is the same as the CM_*CLKEN bit, which is false[1].  Fix by
implementing custom clkops .find_idlest function pointers for the
appropriate clocks that return the correct slave IDLEST bit shift.
This was originally fixed in the linux-omap kernel during 2.6.29 in a
slightly different manner[2][3].
In the medium-term future, all of the module IDLEST code will
eventually be moved to the omap_hwmod code.
Problem reported by Jarkko Nikula <jhnikula@gmail.com>:
    http://marc.info/?l=linux-omap&m=124306184903679&w=2
...
1. See for example 34xx TRM Revision P Table 4-213 and 4-217 (for the
   DSS case).
2. http://www.spinics.net/lists/linux-omap/msg05512.html et seq.
3. http://lkml.indiana.edu/hypermail/linux/kernel/0901.3/01498.html
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Jarkko Nikula <jhnikula@gmail.com>
											
										 
											2009-07-24 19:44:06 -06:00
										 |  |  |  * | 
					
						
							|  |  |  |  * Some OMAP modules on OMAP3 ES2+ chips have both initiator and | 
					
						
							|  |  |  |  * target IDLEST bits.  For our purposes, we are concerned with the | 
					
						
							|  |  |  |  * target IDLEST bits, which exist at a different bit position than | 
					
						
							|  |  |  |  * the *CLKEN bit position for these modules (DSS and USBHOST) (The | 
					
						
							|  |  |  |  * default find_idlest code assumes that they are at the same | 
					
						
							|  |  |  |  * position.)  No return value. | 
					
						
							|  |  |  |  */ | 
					
						
							| 
									
										
										
										
											2012-04-27 15:53:48 +05:30
										 |  |  | static void omap3430es2_clk_dss_usbhost_find_idlest(struct clk_hw_omap *clk, | 
					
						
							| 
									
										
											  
											
												OMAP3 clock: correct module IDLEST bits: SSI; DSS; USBHOST; HSOTGUSB
Fix two bugs in the OMAP3 clock tree pertaining to the SSI, DSS,
USBHOST, and HSOTGUSB devices.  These devices are both interconnect
initiators and targets.  Without this patch, clk_enable()s on clocks for
these modules can be very high latency (potentially up to ~200
milliseconds) and message such as the following are generated:
    Clock usbhost_48m_fck didn't enable in 100000 tries
Two bugs are fixed by this patch.  First, OMAP hardware only supports
target CM_IDLEST register bits on ES2+ chips and beyond.  ES1 chips
should not wait for these clocks to enable.  So, split the appropriate
clocks into ES1 and ES2+ variants, so that kernels running on ES1
devices won't try to wait.
Second, the current heuristic in omap2_clk_dflt_find_idlest() will
fail for these clocks.  It assumes that the CM_IDLEST bit to wait upon
is the same as the CM_*CLKEN bit, which is false[1].  Fix by
implementing custom clkops .find_idlest function pointers for the
appropriate clocks that return the correct slave IDLEST bit shift.
This was originally fixed in the linux-omap kernel during 2.6.29 in a
slightly different manner[2][3].
In the medium-term future, all of the module IDLEST code will
eventually be moved to the omap_hwmod code.
Problem reported by Jarkko Nikula <jhnikula@gmail.com>:
    http://marc.info/?l=linux-omap&m=124306184903679&w=2
...
1. See for example 34xx TRM Revision P Table 4-213 and 4-217 (for the
   DSS case).
2. http://www.spinics.net/lists/linux-omap/msg05512.html et seq.
3. http://lkml.indiana.edu/hypermail/linux/kernel/0901.3/01498.html
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Jarkko Nikula <jhnikula@gmail.com>
											
										 
											2009-07-24 19:44:06 -06:00
										 |  |  | 						    void __iomem **idlest_reg, | 
					
						
							| 
									
										
										
										
											2010-02-24 12:05:54 -07:00
										 |  |  | 						    u8 *idlest_bit, | 
					
						
							|  |  |  | 						    u8 *idlest_val) | 
					
						
							| 
									
										
											  
											
												OMAP3 clock: correct module IDLEST bits: SSI; DSS; USBHOST; HSOTGUSB
Fix two bugs in the OMAP3 clock tree pertaining to the SSI, DSS,
USBHOST, and HSOTGUSB devices.  These devices are both interconnect
initiators and targets.  Without this patch, clk_enable()s on clocks for
these modules can be very high latency (potentially up to ~200
milliseconds) and message such as the following are generated:
    Clock usbhost_48m_fck didn't enable in 100000 tries
Two bugs are fixed by this patch.  First, OMAP hardware only supports
target CM_IDLEST register bits on ES2+ chips and beyond.  ES1 chips
should not wait for these clocks to enable.  So, split the appropriate
clocks into ES1 and ES2+ variants, so that kernels running on ES1
devices won't try to wait.
Second, the current heuristic in omap2_clk_dflt_find_idlest() will
fail for these clocks.  It assumes that the CM_IDLEST bit to wait upon
is the same as the CM_*CLKEN bit, which is false[1].  Fix by
implementing custom clkops .find_idlest function pointers for the
appropriate clocks that return the correct slave IDLEST bit shift.
This was originally fixed in the linux-omap kernel during 2.6.29 in a
slightly different manner[2][3].
In the medium-term future, all of the module IDLEST code will
eventually be moved to the omap_hwmod code.
Problem reported by Jarkko Nikula <jhnikula@gmail.com>:
    http://marc.info/?l=linux-omap&m=124306184903679&w=2
...
1. See for example 34xx TRM Revision P Table 4-213 and 4-217 (for the
   DSS case).
2. http://www.spinics.net/lists/linux-omap/msg05512.html et seq.
3. http://lkml.indiana.edu/hypermail/linux/kernel/0901.3/01498.html
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Jarkko Nikula <jhnikula@gmail.com>
											
										 
											2009-07-24 19:44:06 -06:00
										 |  |  | { | 
					
						
							|  |  |  | 	u32 r; | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | 	r = (((__force u32)clk->enable_reg & ~0xf0) | 0x20); | 
					
						
							|  |  |  | 	*idlest_reg = (__force void __iomem *)r; | 
					
						
							|  |  |  | 	/* USBHOST_IDLE has same shift */ | 
					
						
							|  |  |  | 	*idlest_bit = OMAP3430ES2_ST_DSS_IDLE_SHIFT; | 
					
						
							| 
									
										
										
										
											2010-02-24 12:05:54 -07:00
										 |  |  | 	*idlest_val = OMAP34XX_CM_IDLEST_VAL; | 
					
						
							| 
									
										
											  
											
												OMAP3 clock: correct module IDLEST bits: SSI; DSS; USBHOST; HSOTGUSB
Fix two bugs in the OMAP3 clock tree pertaining to the SSI, DSS,
USBHOST, and HSOTGUSB devices.  These devices are both interconnect
initiators and targets.  Without this patch, clk_enable()s on clocks for
these modules can be very high latency (potentially up to ~200
milliseconds) and message such as the following are generated:
    Clock usbhost_48m_fck didn't enable in 100000 tries
Two bugs are fixed by this patch.  First, OMAP hardware only supports
target CM_IDLEST register bits on ES2+ chips and beyond.  ES1 chips
should not wait for these clocks to enable.  So, split the appropriate
clocks into ES1 and ES2+ variants, so that kernels running on ES1
devices won't try to wait.
Second, the current heuristic in omap2_clk_dflt_find_idlest() will
fail for these clocks.  It assumes that the CM_IDLEST bit to wait upon
is the same as the CM_*CLKEN bit, which is false[1].  Fix by
implementing custom clkops .find_idlest function pointers for the
appropriate clocks that return the correct slave IDLEST bit shift.
This was originally fixed in the linux-omap kernel during 2.6.29 in a
slightly different manner[2][3].
In the medium-term future, all of the module IDLEST code will
eventually be moved to the omap_hwmod code.
Problem reported by Jarkko Nikula <jhnikula@gmail.com>:
    http://marc.info/?l=linux-omap&m=124306184903679&w=2
...
1. See for example 34xx TRM Revision P Table 4-213 and 4-217 (for the
   DSS case).
2. http://www.spinics.net/lists/linux-omap/msg05512.html et seq.
3. http://lkml.indiana.edu/hypermail/linux/kernel/0901.3/01498.html
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Jarkko Nikula <jhnikula@gmail.com>
											
										 
											2009-07-24 19:44:06 -06:00
										 |  |  | } | 
					
						
							| 
									
										
										
										
											2012-04-27 16:35:52 +05:30
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2012-04-27 15:53:48 +05:30
										 |  |  | const struct clk_hw_omap_ops clkhwops_omap3430es2_dss_usbhost_wait = { | 
					
						
							|  |  |  | 	.find_idlest	= omap3430es2_clk_dss_usbhost_find_idlest, | 
					
						
							|  |  |  | 	.find_companion	= omap2_clk_dflt_find_companion, | 
					
						
							|  |  |  | }; | 
					
						
							| 
									
										
											  
											
												OMAP3 clock: correct module IDLEST bits: SSI; DSS; USBHOST; HSOTGUSB
Fix two bugs in the OMAP3 clock tree pertaining to the SSI, DSS,
USBHOST, and HSOTGUSB devices.  These devices are both interconnect
initiators and targets.  Without this patch, clk_enable()s on clocks for
these modules can be very high latency (potentially up to ~200
milliseconds) and message such as the following are generated:
    Clock usbhost_48m_fck didn't enable in 100000 tries
Two bugs are fixed by this patch.  First, OMAP hardware only supports
target CM_IDLEST register bits on ES2+ chips and beyond.  ES1 chips
should not wait for these clocks to enable.  So, split the appropriate
clocks into ES1 and ES2+ variants, so that kernels running on ES1
devices won't try to wait.
Second, the current heuristic in omap2_clk_dflt_find_idlest() will
fail for these clocks.  It assumes that the CM_IDLEST bit to wait upon
is the same as the CM_*CLKEN bit, which is false[1].  Fix by
implementing custom clkops .find_idlest function pointers for the
appropriate clocks that return the correct slave IDLEST bit shift.
This was originally fixed in the linux-omap kernel during 2.6.29 in a
slightly different manner[2][3].
In the medium-term future, all of the module IDLEST code will
eventually be moved to the omap_hwmod code.
Problem reported by Jarkko Nikula <jhnikula@gmail.com>:
    http://marc.info/?l=linux-omap&m=124306184903679&w=2
...
1. See for example 34xx TRM Revision P Table 4-213 and 4-217 (for the
   DSS case).
2. http://www.spinics.net/lists/linux-omap/msg05512.html et seq.
3. http://lkml.indiana.edu/hypermail/linux/kernel/0901.3/01498.html
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Jarkko Nikula <jhnikula@gmail.com>
											
										 
											2009-07-24 19:44:06 -06:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2012-04-27 15:53:48 +05:30
										 |  |  | const struct clk_hw_omap_ops clkhwops_omap3430es2_iclk_dss_usbhost_wait = { | 
					
						
							|  |  |  | 	.allow_idle	= omap2_clkt_iclk_allow_idle, | 
					
						
							|  |  |  | 	.deny_idle	= omap2_clkt_iclk_deny_idle, | 
					
						
							|  |  |  | 	.find_idlest	= omap3430es2_clk_dss_usbhost_find_idlest, | 
					
						
							|  |  |  | 	.find_companion	= omap2_clk_dflt_find_companion, | 
					
						
							|  |  |  | }; | 
					
						
							| 
									
										
										
										
											2011-02-25 15:39:30 -07:00
										 |  |  | 
 | 
					
						
							| 
									
										
											  
											
												OMAP3 clock: correct module IDLEST bits: SSI; DSS; USBHOST; HSOTGUSB
Fix two bugs in the OMAP3 clock tree pertaining to the SSI, DSS,
USBHOST, and HSOTGUSB devices.  These devices are both interconnect
initiators and targets.  Without this patch, clk_enable()s on clocks for
these modules can be very high latency (potentially up to ~200
milliseconds) and message such as the following are generated:
    Clock usbhost_48m_fck didn't enable in 100000 tries
Two bugs are fixed by this patch.  First, OMAP hardware only supports
target CM_IDLEST register bits on ES2+ chips and beyond.  ES1 chips
should not wait for these clocks to enable.  So, split the appropriate
clocks into ES1 and ES2+ variants, so that kernels running on ES1
devices won't try to wait.
Second, the current heuristic in omap2_clk_dflt_find_idlest() will
fail for these clocks.  It assumes that the CM_IDLEST bit to wait upon
is the same as the CM_*CLKEN bit, which is false[1].  Fix by
implementing custom clkops .find_idlest function pointers for the
appropriate clocks that return the correct slave IDLEST bit shift.
This was originally fixed in the linux-omap kernel during 2.6.29 in a
slightly different manner[2][3].
In the medium-term future, all of the module IDLEST code will
eventually be moved to the omap_hwmod code.
Problem reported by Jarkko Nikula <jhnikula@gmail.com>:
    http://marc.info/?l=linux-omap&m=124306184903679&w=2
...
1. See for example 34xx TRM Revision P Table 4-213 and 4-217 (for the
   DSS case).
2. http://www.spinics.net/lists/linux-omap/msg05512.html et seq.
3. http://lkml.indiana.edu/hypermail/linux/kernel/0901.3/01498.html
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Jarkko Nikula <jhnikula@gmail.com>
											
										 
											2009-07-24 19:44:06 -06:00
										 |  |  | /**
 | 
					
						
							|  |  |  |  * omap3430es2_clk_hsotgusb_find_idlest - return CM_IDLEST info for HSOTGUSB | 
					
						
							|  |  |  |  * @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 | 
					
						
							| 
									
										
										
										
											2010-02-24 12:05:54 -07:00
										 |  |  |  * @idlest_val: pointer to a u8 to store the CM_IDLEST indicator | 
					
						
							| 
									
										
											  
											
												OMAP3 clock: correct module IDLEST bits: SSI; DSS; USBHOST; HSOTGUSB
Fix two bugs in the OMAP3 clock tree pertaining to the SSI, DSS,
USBHOST, and HSOTGUSB devices.  These devices are both interconnect
initiators and targets.  Without this patch, clk_enable()s on clocks for
these modules can be very high latency (potentially up to ~200
milliseconds) and message such as the following are generated:
    Clock usbhost_48m_fck didn't enable in 100000 tries
Two bugs are fixed by this patch.  First, OMAP hardware only supports
target CM_IDLEST register bits on ES2+ chips and beyond.  ES1 chips
should not wait for these clocks to enable.  So, split the appropriate
clocks into ES1 and ES2+ variants, so that kernels running on ES1
devices won't try to wait.
Second, the current heuristic in omap2_clk_dflt_find_idlest() will
fail for these clocks.  It assumes that the CM_IDLEST bit to wait upon
is the same as the CM_*CLKEN bit, which is false[1].  Fix by
implementing custom clkops .find_idlest function pointers for the
appropriate clocks that return the correct slave IDLEST bit shift.
This was originally fixed in the linux-omap kernel during 2.6.29 in a
slightly different manner[2][3].
In the medium-term future, all of the module IDLEST code will
eventually be moved to the omap_hwmod code.
Problem reported by Jarkko Nikula <jhnikula@gmail.com>:
    http://marc.info/?l=linux-omap&m=124306184903679&w=2
...
1. See for example 34xx TRM Revision P Table 4-213 and 4-217 (for the
   DSS case).
2. http://www.spinics.net/lists/linux-omap/msg05512.html et seq.
3. http://lkml.indiana.edu/hypermail/linux/kernel/0901.3/01498.html
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Jarkko Nikula <jhnikula@gmail.com>
											
										 
											2009-07-24 19:44:06 -06:00
										 |  |  |  * | 
					
						
							|  |  |  |  * The OMAP3430ES2 HSOTGUSB target CM_IDLEST bit is at a different | 
					
						
							|  |  |  |  * shift from the CM_{I,F}CLKEN bit.  Pass back the correct info via | 
					
						
							|  |  |  |  * @idlest_reg and @idlest_bit.  No return value. | 
					
						
							|  |  |  |  */ | 
					
						
							| 
									
										
										
										
											2012-04-27 15:53:48 +05:30
										 |  |  | static void omap3430es2_clk_hsotgusb_find_idlest(struct clk_hw_omap *clk, | 
					
						
							| 
									
										
											  
											
												OMAP3 clock: correct module IDLEST bits: SSI; DSS; USBHOST; HSOTGUSB
Fix two bugs in the OMAP3 clock tree pertaining to the SSI, DSS,
USBHOST, and HSOTGUSB devices.  These devices are both interconnect
initiators and targets.  Without this patch, clk_enable()s on clocks for
these modules can be very high latency (potentially up to ~200
milliseconds) and message such as the following are generated:
    Clock usbhost_48m_fck didn't enable in 100000 tries
Two bugs are fixed by this patch.  First, OMAP hardware only supports
target CM_IDLEST register bits on ES2+ chips and beyond.  ES1 chips
should not wait for these clocks to enable.  So, split the appropriate
clocks into ES1 and ES2+ variants, so that kernels running on ES1
devices won't try to wait.
Second, the current heuristic in omap2_clk_dflt_find_idlest() will
fail for these clocks.  It assumes that the CM_IDLEST bit to wait upon
is the same as the CM_*CLKEN bit, which is false[1].  Fix by
implementing custom clkops .find_idlest function pointers for the
appropriate clocks that return the correct slave IDLEST bit shift.
This was originally fixed in the linux-omap kernel during 2.6.29 in a
slightly different manner[2][3].
In the medium-term future, all of the module IDLEST code will
eventually be moved to the omap_hwmod code.
Problem reported by Jarkko Nikula <jhnikula@gmail.com>:
    http://marc.info/?l=linux-omap&m=124306184903679&w=2
...
1. See for example 34xx TRM Revision P Table 4-213 and 4-217 (for the
   DSS case).
2. http://www.spinics.net/lists/linux-omap/msg05512.html et seq.
3. http://lkml.indiana.edu/hypermail/linux/kernel/0901.3/01498.html
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Jarkko Nikula <jhnikula@gmail.com>
											
										 
											2009-07-24 19:44:06 -06:00
										 |  |  | 						 void __iomem **idlest_reg, | 
					
						
							| 
									
										
										
										
											2010-02-24 12:05:54 -07:00
										 |  |  | 						 u8 *idlest_bit, | 
					
						
							|  |  |  | 						 u8 *idlest_val) | 
					
						
							| 
									
										
											  
											
												OMAP3 clock: correct module IDLEST bits: SSI; DSS; USBHOST; HSOTGUSB
Fix two bugs in the OMAP3 clock tree pertaining to the SSI, DSS,
USBHOST, and HSOTGUSB devices.  These devices are both interconnect
initiators and targets.  Without this patch, clk_enable()s on clocks for
these modules can be very high latency (potentially up to ~200
milliseconds) and message such as the following are generated:
    Clock usbhost_48m_fck didn't enable in 100000 tries
Two bugs are fixed by this patch.  First, OMAP hardware only supports
target CM_IDLEST register bits on ES2+ chips and beyond.  ES1 chips
should not wait for these clocks to enable.  So, split the appropriate
clocks into ES1 and ES2+ variants, so that kernels running on ES1
devices won't try to wait.
Second, the current heuristic in omap2_clk_dflt_find_idlest() will
fail for these clocks.  It assumes that the CM_IDLEST bit to wait upon
is the same as the CM_*CLKEN bit, which is false[1].  Fix by
implementing custom clkops .find_idlest function pointers for the
appropriate clocks that return the correct slave IDLEST bit shift.
This was originally fixed in the linux-omap kernel during 2.6.29 in a
slightly different manner[2][3].
In the medium-term future, all of the module IDLEST code will
eventually be moved to the omap_hwmod code.
Problem reported by Jarkko Nikula <jhnikula@gmail.com>:
    http://marc.info/?l=linux-omap&m=124306184903679&w=2
...
1. See for example 34xx TRM Revision P Table 4-213 and 4-217 (for the
   DSS case).
2. http://www.spinics.net/lists/linux-omap/msg05512.html et seq.
3. http://lkml.indiana.edu/hypermail/linux/kernel/0901.3/01498.html
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Jarkko Nikula <jhnikula@gmail.com>
											
										 
											2009-07-24 19:44:06 -06:00
										 |  |  | { | 
					
						
							|  |  |  | 	u32 r; | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | 	r = (((__force u32)clk->enable_reg & ~0xf0) | 0x20); | 
					
						
							|  |  |  | 	*idlest_reg = (__force void __iomem *)r; | 
					
						
							|  |  |  | 	*idlest_bit = OMAP3430ES2_ST_HSOTGUSB_IDLE_SHIFT; | 
					
						
							| 
									
										
										
										
											2010-02-24 12:05:54 -07:00
										 |  |  | 	*idlest_val = OMAP34XX_CM_IDLEST_VAL; | 
					
						
							| 
									
										
											  
											
												OMAP3 clock: correct module IDLEST bits: SSI; DSS; USBHOST; HSOTGUSB
Fix two bugs in the OMAP3 clock tree pertaining to the SSI, DSS,
USBHOST, and HSOTGUSB devices.  These devices are both interconnect
initiators and targets.  Without this patch, clk_enable()s on clocks for
these modules can be very high latency (potentially up to ~200
milliseconds) and message such as the following are generated:
    Clock usbhost_48m_fck didn't enable in 100000 tries
Two bugs are fixed by this patch.  First, OMAP hardware only supports
target CM_IDLEST register bits on ES2+ chips and beyond.  ES1 chips
should not wait for these clocks to enable.  So, split the appropriate
clocks into ES1 and ES2+ variants, so that kernels running on ES1
devices won't try to wait.
Second, the current heuristic in omap2_clk_dflt_find_idlest() will
fail for these clocks.  It assumes that the CM_IDLEST bit to wait upon
is the same as the CM_*CLKEN bit, which is false[1].  Fix by
implementing custom clkops .find_idlest function pointers for the
appropriate clocks that return the correct slave IDLEST bit shift.
This was originally fixed in the linux-omap kernel during 2.6.29 in a
slightly different manner[2][3].
In the medium-term future, all of the module IDLEST code will
eventually be moved to the omap_hwmod code.
Problem reported by Jarkko Nikula <jhnikula@gmail.com>:
    http://marc.info/?l=linux-omap&m=124306184903679&w=2
...
1. See for example 34xx TRM Revision P Table 4-213 and 4-217 (for the
   DSS case).
2. http://www.spinics.net/lists/linux-omap/msg05512.html et seq.
3. http://lkml.indiana.edu/hypermail/linux/kernel/0901.3/01498.html
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Jarkko Nikula <jhnikula@gmail.com>
											
										 
											2009-07-24 19:44:06 -06:00
										 |  |  | } | 
					
						
							| 
									
										
										
										
											2012-04-27 16:35:52 +05:30
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2012-04-27 15:53:48 +05:30
										 |  |  | const struct clk_hw_omap_ops clkhwops_omap3430es2_iclk_hsotgusb_wait = { | 
					
						
							|  |  |  | 	.allow_idle	= omap2_clkt_iclk_allow_idle, | 
					
						
							|  |  |  | 	.deny_idle	= omap2_clkt_iclk_deny_idle, | 
					
						
							|  |  |  | 	.find_idlest	= omap3430es2_clk_hsotgusb_find_idlest, | 
					
						
							|  |  |  | 	.find_companion	= omap2_clk_dflt_find_companion, | 
					
						
							|  |  |  | }; | 
					
						
							| 
									
										
											  
											
												OMAP3 clock: correct module IDLEST bits: SSI; DSS; USBHOST; HSOTGUSB
Fix two bugs in the OMAP3 clock tree pertaining to the SSI, DSS,
USBHOST, and HSOTGUSB devices.  These devices are both interconnect
initiators and targets.  Without this patch, clk_enable()s on clocks for
these modules can be very high latency (potentially up to ~200
milliseconds) and message such as the following are generated:
    Clock usbhost_48m_fck didn't enable in 100000 tries
Two bugs are fixed by this patch.  First, OMAP hardware only supports
target CM_IDLEST register bits on ES2+ chips and beyond.  ES1 chips
should not wait for these clocks to enable.  So, split the appropriate
clocks into ES1 and ES2+ variants, so that kernels running on ES1
devices won't try to wait.
Second, the current heuristic in omap2_clk_dflt_find_idlest() will
fail for these clocks.  It assumes that the CM_IDLEST bit to wait upon
is the same as the CM_*CLKEN bit, which is false[1].  Fix by
implementing custom clkops .find_idlest function pointers for the
appropriate clocks that return the correct slave IDLEST bit shift.
This was originally fixed in the linux-omap kernel during 2.6.29 in a
slightly different manner[2][3].
In the medium-term future, all of the module IDLEST code will
eventually be moved to the omap_hwmod code.
Problem reported by Jarkko Nikula <jhnikula@gmail.com>:
    http://marc.info/?l=linux-omap&m=124306184903679&w=2
...
1. See for example 34xx TRM Revision P Table 4-213 and 4-217 (for the
   DSS case).
2. http://www.spinics.net/lists/linux-omap/msg05512.html et seq.
3. http://lkml.indiana.edu/hypermail/linux/kernel/0901.3/01498.html
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Jarkko Nikula <jhnikula@gmail.com>
											
										 
											2009-07-24 19:44:06 -06:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2012-04-27 15:53:48 +05:30
										 |  |  | const struct clk_hw_omap_ops clkhwops_omap3430es2_hsotgusb_wait = { | 
					
						
							|  |  |  | 	.find_idlest	= omap3430es2_clk_hsotgusb_find_idlest, | 
					
						
							|  |  |  | 	.find_companion	= omap2_clk_dflt_find_companion, | 
					
						
							|  |  |  | }; |