1
linux/arch/arm/mach-omap2/clock34xx.c

154 lines
5.1 KiB
C
Raw Normal View History

/*
* OMAP3-specific clock framework functions
*
* Copyright (C) 2007-2008 Texas Instruments, Inc.
* Copyright (C) 2007-2011 Nokia Corporation
*
* Paul Walmsley
* Jouni Högander
*
* Parts of this code are based on code written by
* Richard Woodruff, Tony Lindgren, Tuukka Tikkanen, Karthik Dasu,
* Russell King
*
* 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 <plat/clock.h>
#include "clock.h"
#include "clock34xx.h"
#include "cm2xxx_3xxx.h"
#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 18:44:06 -07: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
* @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 18:44:06 -07: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.
*/
static void omap3430es2_clk_ssi_find_idlest(struct clk *clk,
void __iomem **idlest_reg,
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 18:44:06 -07:00
{
u32 r;
r = (((__force u32)clk->enable_reg & ~0xf0) | 0x20);
*idlest_reg = (__force void __iomem *)r;
*idlest_bit = OMAP3430ES2_ST_SSI_IDLE_SHIFT;
*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 18:44:06 -07:00
}
const struct clkops clkops_omap3430es2_ssi_wait = {
.enable = omap2_dflt_clk_enable,
.disable = omap2_dflt_clk_disable,
.find_idlest = omap3430es2_clk_ssi_find_idlest,
.find_companion = omap2_clk_dflt_find_companion,
};
const struct clkops clkops_omap3430es2_iclk_ssi_wait = {
.enable = omap2_dflt_clk_enable,
.disable = omap2_dflt_clk_disable,
.find_idlest = omap3430es2_clk_ssi_find_idlest,
.find_companion = omap2_clk_dflt_find_companion,
.allow_idle = omap2_clkt_iclk_allow_idle,
.deny_idle = omap2_clkt_iclk_deny_idle,
};
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 18:44:06 -07: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
* @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 18:44:06 -07: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.
*/
static void omap3430es2_clk_dss_usbhost_find_idlest(struct clk *clk,
void __iomem **idlest_reg,
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 18:44:06 -07: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;
*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 18:44:06 -07:00
}
const struct clkops clkops_omap3430es2_dss_usbhost_wait = {
.enable = omap2_dflt_clk_enable,
.disable = omap2_dflt_clk_disable,
.find_idlest = omap3430es2_clk_dss_usbhost_find_idlest,
.find_companion = omap2_clk_dflt_find_companion,
};
const struct clkops clkops_omap3430es2_iclk_dss_usbhost_wait = {
.enable = omap2_dflt_clk_enable,
.disable = omap2_dflt_clk_disable,
.find_idlest = omap3430es2_clk_dss_usbhost_find_idlest,
.find_companion = omap2_clk_dflt_find_companion,
.allow_idle = omap2_clkt_iclk_allow_idle,
.deny_idle = omap2_clkt_iclk_deny_idle,
};
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 18:44:06 -07: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
* @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 18:44:06 -07: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.
*/
static void omap3430es2_clk_hsotgusb_find_idlest(struct clk *clk,
void __iomem **idlest_reg,
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 18:44:06 -07:00
{
u32 r;
r = (((__force u32)clk->enable_reg & ~0xf0) | 0x20);
*idlest_reg = (__force void __iomem *)r;
*idlest_bit = OMAP3430ES2_ST_HSOTGUSB_IDLE_SHIFT;
*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 18:44:06 -07:00
}
const struct clkops clkops_omap3430es2_hsotgusb_wait = {
.enable = omap2_dflt_clk_enable,
.disable = omap2_dflt_clk_disable,
.find_idlest = omap3430es2_clk_hsotgusb_find_idlest,
.find_companion = omap2_clk_dflt_find_companion,
};
const struct clkops clkops_omap3430es2_iclk_hsotgusb_wait = {
.enable = omap2_dflt_clk_enable,
.disable = omap2_dflt_clk_disable,
.find_idlest = omap3430es2_clk_hsotgusb_find_idlest,
.find_companion = omap2_clk_dflt_find_companion,
.allow_idle = omap2_clkt_iclk_allow_idle,
.deny_idle = omap2_clkt_iclk_deny_idle,
};