summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2010-12-23OMAP4: Adding voltage driver supportThara Gopinath4-1/+304
OMAP4 has three scalable voltage domains vdd_mpu, vdd_iva and vdd_core. This patch adds the voltage tables and other configurable voltage processor and voltage controller settings to control these three scalable domains in OMAP4. Signed-off-by: Thara Gopinath <thara@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-12-23OMAP4: Register voltage PMIC parameters with the voltage layerThara Gopinath3-0/+172
TWL6030 is the power IC used along with OMAP4 in OMAP4 SDPs, blaze boards and panda boards. This patch registers the OMAP4 PMIC specific information with the voltage layer. This also involves implementing a different formula for voltage to vsel and vsel to voltage calculations from TWL4030. Signed-off-by: Thara Gopinath <thara@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-12-23OMAP3: PM: Program correct init voltages for VDD1 and VDD2Thara Gopinath1-0/+76
By default the system boots up at nominal voltage for every voltage domain in the system. This patch puts VDD1 and VDD2 to the correct boot up voltage as per the opp tables specified. This patch implements this by matching the rate of the main clock of the voltage domain with the opp table and picking up the correct voltage. Signed-off-by: Thara Gopinath <thara@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-12-23OMAP3: PM: Adding debug support to Voltage and Smartreflex driversThara Gopinath2-2/+110
This patch adds debug support to the voltage and smartreflex drivers. This means a whole bunch of voltage processor and smartreflex parameters are now visible through the pm debugfs. The voltage parameters can be viewed at /debug/voltage/vdd_<x>/<parameter> and the smartreflex parameters can be viewed at /debug/voltage/vdd_<x>/smartreflex/<parameter> Also smartreflex n-target values are now exposed out at /debug/voltage/vdd_<x>/smartreflex/nvalue/<voltage> This is a read-write interface which means user has the flexibility to change the n-target values for any opp. Signed-off-by: Thara Gopinath <thara@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-12-23OMAP3: PM: Register TWL4030 pmic info with the voltage driver.Thara Gopinath4-0/+126
This patch registers the TWL4030 PMIC specific informtion with the voltage driver. Failing this patch the voltage driver is unware of the formula to use for vsel to voltage and vice versa conversion and lot of other PMIC dependent parameters. This file is based on the arch/arm/plat-omap opp_twl_tpl.c file by Paul Walmsley. The original file is replaced by this file. Signed-off-by: Thara Gopinath <thara@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-12-23OMAP3: PM: Adding smartreflex class3 driverThara Gopinath3-0/+69
Smartreflex Class3 implementation continuously monitors silicon performance and instructs the Voltage Processors to increase or decrease the voltage. This patch adds smartreflex class 3 driver. This driver hooks up with the generic smartreflex driver smartreflex.c to abstract out class specific implementations out of the generic driver. Class3 driver is chosen as the default class driver for smartreflex. If any other class driver needs to be implemented, the init of that driver should be called from the board file. That way the new class driver will over-ride the Class3 driver. Signed-off-by: Thara Gopinath <thara@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-12-23OMAP3: PM: Adding smartreflex hwmod dataThara Gopinath1-0/+175
This patch adds the smartreflex hwmod data for OMAP3430 and OMAP3630. Signed-off-by: Thara Gopinath <thara@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-12-23OMAP3: PM: Adding smartreflex device file.Thara Gopinath4-1/+148
This patch adds support for device registration of various smartreflex module present in the system. This patch introduces the platform data for smartreflex devices which include the efused n-target vaules, a parameter to indicate whether smartreflex autocompensation needs to be enabled on init or not. An API omap_enable_smartreflex_on_init is provided for the board files to enable smartreflex autocompensation during system boot up. Signed-off-by: Thara Gopinath <thara@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-12-23OMAP3: PM: Adding smartreflex driver support.Thara Gopinath4-0/+1251
SmartReflex modules do adaptive voltage control for real-time voltage adjustments. With Smartreflex the power supply voltage can be adapted to the silicon performance(manufacturing process, temperature induced performance, age induced performance etc). There are differnet classes of smartreflex implementation. Class-0: Manufacturing Test Calibration Class-1: Boot-Time Software Calibration Class-2: Continuous Software Calibration Class-3: Continuous Hardware Calibration Class-4: Fully Integrated Power Management OMAP3 has two smartreflex modules one associated with VDD MPU and the other associated with VDD CORE. This patch adds support for smartreflex driver. The driver is designed for Class-1 , Class-2 and Class-3 support and is a platform driver. Smartreflex driver can be enabled through a Kconfig option "SmartReflex support" under "System type"->"TI OMAP implementations" menu. Smartreflex autocompensation feature can be enabled runtime through a debug fs option. To enable smartreflex autocompensation feature echo 1 > /debug/voltage/vdd_<X>/smartreflex/autocomp To disable smartreflex autocompensation feature echo 0 > /debug/voltage/vdd_<X>/smartreflex/autocomp where X can be mpu, core , iva etc. This patch contains code originally in linux omap pm branch. Major contributors to this driver are Lesly A M, Rajendra Nayak, Kalle Jokiniemi, Paul Walmsley, Nishant Menon, Kevin Hilman. Signed-off-by: Thara Gopinath <thara@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-12-23OMAP: Introduce voltage domain information in the hwmod structuresThara Gopinath1-0/+5
This patch extends the device hwmod structure to contain info about the voltage domain to which the device belongs to. This is needed to support a device based DVFS where the device knows which voltage domain it belongs to. Signed-off-by: Thara Gopinath <thara@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-12-23OMAP3: PM: Adding voltage driver support.Thara Gopinath5-2/+1388
This patch adds voltage driver support for OMAP3. The driver allows configuring the voltage controller and voltage processors during init and exports APIs to enable/disable voltage processors, scale voltage and reset voltage. The driver maintains the global voltage table on a per VDD basis which contains the various voltages supported by the VDD along with per voltage dependent data like smartreflex efuse offset, errminlimit and voltage processor errorgain. The driver also allows the voltage parameters dependent on the PMIC to be passed from the PMIC file through an API. The driver allows scaling of VDD voltages either through "vc bypass method" or through "vp forceupdate method" the choice being configurable through the board file. This patch contains code originally in linux omap pm branch smartreflex driver. Major contributors to this driver are Lesly A M, Rajendra Nayak, Kalle Jokiniemi, Paul Walmsley, Nishant Menon, Kevin Hilman. The separation of PMIC parameters into a separate structure which can be populated from the PMIC file is based on the work of Lun Chang from Motorola in an internal tree. Signed-off-by: Thara Gopinath <thara@ti.com> [khilman: fixed link error for OMAP2-only defconfig] Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-12-22OMAP4: clock data: Add missing fixed divisorsJon Hunter1-11/+22
The following OMAP4 clocks have the following fixed divisors that determine the frequency at which these clocks operate. These dividers are defined by the PRCM specification and without these dividers the rates of the below clocks are calculated incorrectly. This may cause internal peripherals using these clocks to operate at the wrong frequency. - abe_24m_fclk (freq = divided-by-8) - ddrphy_ck (freq = parent divided-by-2) - dll_clk_div_ck (freq = parent divided-by-2) - per_hs_clk_div_ck (freq = parent divided-by-2) - usb_hs_clk_div_ck (freq = parent divided-by-3) - func_12m_fclk (freq = parent divided-by-16) - func_24m_clk (freq = parent divided-by-4) - func_24mc_fclk (freq = parent divided-by-8) - func_48mc_fclk (freq = divided-by-4) - lp_clk_div_ck (freq = divided-by-16) - per_abe_24m_fclk (freq = divided-by-4) Signed-off-by: Jon Hunter <jon-hunter@ti.com> Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Rajendra Nayak <rnayak@ti.com>
2010-12-22OMAP3: SDRC: Add comments on Errata i520 for Global SW resetVishwanath BS1-0/+28
This patch adds comments on precaution to be taken if Global Warm reset is used as the means to trigger system reset. Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com> [paul@pwsan.com: fixed typos, one mentioned by Sanjeev] Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Sanjeev Premi <premi@ti.com>
2010-12-22OMAP4: clock data: Keep L3INSTR clock domain modulemode under HW controlSantosh Shilimkar1-0/+3
L3INSTR clock domain is read only register and its reset value is HW_AUTO. The modules withing this clock domain needs to be kept under hardware control. MODULEMODE: - 0x0: Module is disable by software. Any INTRCONN access to module results in an error, except if resulting from a module wakeup (asynchronous wakeup). - 0x1: Module is managed automatically by hardware according to clock domain transition. A clock domain sleep transition put module into idle. A wakeup domain transition put it back into function. If CLKTRCTRL=3, any INTRCONN access to module is always granted. Module clocks may be gated according to the clock domain state. This patch keeps CM_L3INSTR_L3_3_CLKCTRL, CM_L3INSTR_L3_INSTR_CLKCTRL and CM_L3INSTR_INTRCONN_WP1_CLKCTRL module mode under hardware control by using ENABLE_ON_INIT flag. Without this the OMAP4 device OFF mode SAR restore phase aborts during interconnect register restore phase. This can be also handled by doing explicit a clock enable and disable in the low power code since there is no direct module associated with it. But that seems not necessary since the clock domain is under HW control. Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-12-22OMAP4: powerdomain: Remove L3INIT_PD OFF stateSantosh Shilimkar1-1/+1
On OMAP4, there is an issue when L3INIT transitions to OFF mode without device OFF. The SAR restore mechanism will not get triggered without wakeup from device OFF and hence the USB host and USB TLL context will not be restored. Hardware team recommended to remove the OFF state support for L3INIT_PD since there is no power impact. It will be removed on next OMAP revision (OMAP4440 and beyond). Hence this patch removed the OFF state from L3INIT_PD. The deepest state supported on L3INIT_PD is OSWR just like CORE_PD and PER_PD Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> [b-cousson@ti.com: update the changelog with next OMAP info] Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-12-22OMAP4: powerdomain: l4per pwrdm does not support OFFRajendra Nayak1-1/+1
The l4per power domain in ES2.0 does support only RET and ON states. The previous ES1.0 HW database was wrong and thus fixed on ES2. Change the pwrsts field to reflect that. Signed-off-by: Rajendra Nayak <rnayak@ti.com> Acked-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-12-22OMAP4: PM: Do not assume clkdm supports hw transitionsRajendra Nayak1-3/+5
omap_set_pwrdm_state today assumes a clkdm supports hw_auto transitions and hence leaves some which do not support this in sw wkup state preventing low power transitions. Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Benoit Cousson <b-cousson@ti.com> Acked-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-12-22OMAP4: PM: Use the low-power state change feature on OMAP4Rajendra Nayak1-6/+22
For pwrdm's which support LOWPOWERSTATECHANGE, do not try waking up the domain to put it back to deeper sleep state. Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Acked-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-12-22OMAP: PM noop: implement context loss count for non-omap_devicesKevin Hilman3-1/+52
For devices which have not (yet) been converted to use omap_device, implement the context loss counter using the "brutal method" as originally proposed by Paul Walmsley[1]. The dummy context loss counter is incremented every time it is checked, but only when off-mode is enabled. When off-mode is disabled, the dummy counter stops incrementing. Tested on 36xx/Zoom3 using MMC driver, which is currently the only in-tree user of this API. This patch should be reverted after all devices are converted to using omap_device. [1] http://marc.info/?l=linux-omap&m=129176260000626&w=2 Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> [paul@pwsan.com: fixed compile warning; fixed to compile on OMAP1] Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-12-22OMAP: PM: implement context loss count APIsKevin Hilman6-14/+65
Implement OMAP PM layer omap_pm_get_dev_context_loss_count() API by creating similar APIs at the omap_device and omap_hwmod levels. The omap_hwmod level call is the layer with access to the powerdomain core, so it is the place where the powerdomain is queried to get the context loss count. The new APIs return an unsigned value that can wrap as the context-loss count grows. However, the wrapping is not important as the role of this function is to determine context loss by checking for any difference in subsequent calls to this function. Note that these APIs at each level can return zero when no context loss is detected, or on errors. This is to avoid returning error codes which could potentially be mistaken for large context loss counters. NOTE: only works for devices which have been converted to use omap_device/omap_hwmod. Longer term, we could possibly remove this API from the OMAP PM layer, and instead directly use the omap_device level API. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-12-22OMAP2+: powerdomain: add API to get context loss countKevin Hilman2-0/+30
Add new powerdomain API u32 pwrdm_get_context_loss_count(struct powerdomain *pwrdm) for checking how many times the powerdomain has lost context. The loss count is the sum of the powerdomain off-mode counter, the logic off counter and the per-bank memory off counter. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> [paul@pwsan.com: removed bogus return value on error; improved kerneldoc; tweaked commit message] Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-12-22OMAP4: clocks: add dummy clock for mailboxHari Kanigeri1-0/+1
In omap4, there is no explicit configuration register to enable mailbox clocks. Defining dummy clock for mailbox clock module to keep the mailbox driver backward compatible with previous omaps. Signed-off-by: Hari Kanigeri <h-kanigeri2@ti.com> Acked-by: Benoît Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-12-22OMAP: clock: fix configuration of J-Type DPLLs to work for OMAP3 and OMAP4Jon Hunter5-22/+42
J-Type DPLLs have additional configuration parameters that need to be programmed when setting the multipler and divider for the DPLL. These parameters being the sigma delta divider (SD_DIV) for the DPLL and the digital controlled oscillator (DCO) to be used by the DPLL. The current code is implemented specifically to configure the OMAP3630 PER J-Type DPLL. The OMAP4430 USB DPLL is also a J-Type DPLL and so this code needs to be updated to work for both OMAP3 and OMAP4 devices and any other future devices that have J-TYPE DPLLs. For the OMAP3630 PER DPLL both the SD_DIV and DCO paramenters are used but for the OMAP4430 USB DPLL only the SD_DIV field is used. The current implementation will only program the SD_DIV and DCO fields if the DPLL has both and hence this does not work for OMAP4430. In order to make the code more generic add two new fields to the dpll_data structure for the SD_DIV field and DCO field bit-masks and only program these fields if the masks are defined for a specific DPLL. This simplifies the code and allows us to remove the flag DPLL_NO_DCO_SEL. Tested on OMAP36xx Zoom3 and OMAP4 Blaze. Signed-off-by: Jon Hunter <jon-hunter@ti.com> [paul@pwsan.com: removed explicit inlining and added '_' prefix on lookup_*() functions; added testing info to commit message; added 35xx comments back in] Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-12-22OMAP3: clock: Update clock domain name for mcspi fckCharulatha V1-0/+4
Update clock3xxx_data for mcspi1-4 with appropriate clock domain name. Signed-off-by: Charulatha V <charu@ti.com> Signed-off-by: Govindraj.R <govindraj.raja@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-12-22OMAP4: hwmod data: Add SIDLE_SMART_WKUP modes to several IPsBenoit Cousson1-4/+8
uart, gpio, wd_timer and i2c does support the new smart-idle with wakeup added in OMAP4. Add the flag to allow the hwmod core to enable this mode when applicable. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Rajendra Nayak <rnayak@ti.com>
2010-12-22OMAP2+: hwmod: Add wakeup support for new OMAP4 IPsBenoit Cousson2-3/+18
The new OMAP4 IPs introduced a new idle mode named smart-idle with wakeup. This new idlemode replaces the enawakeup for the new IPs but seems to coexist as well for some legacy IPs (UART, GPIO, MCSPI...) Add the new SIDLE_SMART_WKUP flag to mark the IPs that support this capability. The omap_hwmod_44xx_data.c will have to be updated to add this new flag. Enable this new mode when applicable in _enable_wakeup, _enable_sysc and _idle_sysc. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Tested-by: Sebastien Guiriec <s-guiriec@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Rajendra Nayak <rnayak@ti.com>
2010-12-22OMAP2+: hwmod: Disable clocks when hwmod enable failsRajendra Nayak1-0/+1
In cases where a module (hwmod) does not become accesible on enabling the main clocks (can happen if there are external clocks needed for the module to become accesible), make sure the clocks are not left enabled. This ensures that when the requisite external dependencies are met a omap_hwmod_enable and omap_hwmod_idle/shutdown would rightly enable and disable clocks using clk framework. Leaving the clocks enabled in the error case causes additional usecounting at the clock framework level leaving the clock enabled forever. Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com>
2010-12-22OMAP2+: hwmod: Remove omap_hwmod_mutexBenoit Cousson1-22/+4
The hwmod list will be built are init time and never be modified at runtime. There is no need anymore to protect the list from concurrent accesses using a mutex. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com>
2010-12-22OMAP2+: hwmod: Mark functions used only during initialization with __initBenoit Cousson1-4/+4
_register, _find_mpu_port_index and _find_mpu_rt_base are static APIs that will be used only during the omap_hwmod initialization phase. There is no need to keep them for runtime. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com>
2010-12-22OMAP2+: hwmod: Make omap_hwmod_register private and remove omap_hwmod_unregisterBenoit Cousson2-84/+55
Do not allow omap_hwmod_register to be used outside the core hwmod code. An omap_hwmod should be registered only at init time. Remove the omap_hwmod_unregister that is not used today since the hwmod list will be built once at init time and never be modified at runtime. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com>
2010-12-22OMAP2430: hwmod data: Use common dev_attr for i2c1 and i2c2Benoit Cousson1-9/+5
Since i2c1 and i2c2 are using the same data, remove the two previous instances and use a common i2c_dev_attr one. Moreover, that will fix the following warning: arch/arm/mach-omap2/omap_hwmod_2430_data.c:485: warning: 'i2c_dev_attr' defined but not used Signed-off-by: Benoit Cousson <b-cousson@ti.com> Acked-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Charulatha V <charu@ti.com>
2010-12-22OMAP2+: omap_hwmod: fix wakeup enable/disable for consistencyKevin Hilman1-15/+17
In the omap_hwmod core, most of the SYSCONFIG register helper functions do not directly write the register, but instead just modify a value passed in. This patch converts the _enable_wakeup() and _disable_wakeup() helper functions to take a value argument and only modify it instead of actually writing the register. This makes the wakeup helpers consistent with the other helper functions and avoids unintentional problems like the following. This problem was found after discovering that GPIO wakeups were no longer functional. The root cause was that the ENAWAKEUP bit of the SYSCONFIG register was being unintentionaly overwritten, leaving wakeups disabled after the following two commits were combined: commit: 9980ce53c97392a3dbdc9d1ac3e455d79b4167ed OMAP: hwmod: Enable module wakeup if in smartidle commit: 78f26e872f77b6312273216de1a8f836c6f2e143 OMAP: hwmod: Set autoidle after smartidle during _sysc_enable There resulting in code in _enable_sysc() was this: /* * XXX The clock framework should handle this, by * calling into this code. But this must wait until the * clock structures are tagged with omap_hwmod entries */ if ((oh->flags & HWMOD_SET_DEFAULT_CLOCKACT) && (sf & SYSC_HAS_CLOCKACTIVITY)) _set_clockactivity(oh, oh->class->sysc->clockact, &v); _write_sysconfig(v, oh); so here, 'v' has wakeups disabled. /* If slave is in SMARTIDLE, also enable wakeup */ if ((sf & SYSC_HAS_SIDLEMODE) && !(oh->flags & HWMOD_SWSUP_SIDLE)) _enable_wakeup(oh); Here wakeup is enabled in the SYSCONFIG register (but 'v' is not updated) /* * Set the autoidle bit only after setting the smartidle bit * Setting this will not have any impact on the other modules. */ if (sf & SYSC_HAS_AUTOIDLE) { idlemode = (oh->flags & HWMOD_NO_OCP_AUTOIDLE) ? 0 : 1; _set_module_autoidle(oh, idlemode, &v); _write_sysconfig(v, oh); } And here, SYSCONFIG is updated again using 'v', which does not have wakeups enabled, resulting in ENAWAKEUP being cleared. Special thanks to Benoit Cousson for pointing out that wakeups were supposed to be automatically enabled when a hwmod is enabled, and thus helping target the root cause of this problem. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-12-22OMAP4: hwmod & clock data: Fix GPIO opt_clks and ocp_if iclkBenoit Cousson2-12/+23
Fix opt clocks name in clock framework and hwmod. Add the missing iclk in the ocp_if structure. Add the HWMOD_CONTROL_OPT_CLKS_IN_RESET flag to ensure the the GPIO optional clock is enable during reset. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Tested-by: Charulatha V <charu@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com>
2010-12-22OMAP4: hwmod data: Add IVA and DSPBenoit Cousson1-2/+241
Add IVA and DSP hwmods in order to allow the pm code to initialize properly the processors devices during omap2_init_processor_devices. It will avoid the following warnings. _init_omap_device: could not find omap_hwmod for iva _init_omap_device: could not find omap_hwmod for dsp Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com>
2010-12-22OMAP4: hwmod data: Fix missing address in DMM and EMIF_FWBenoit Cousson1-3/+23
The DMM is a piece of interconnect that need to be configured properly for the tiler functionnality. It thus exposes some configuration registers that were missing previously. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-12-22OMAP4: hwmod data: Add SYSS_HAS_RESET_STATUS flagBenoit Cousson1-5/+7
Update the data for GPIO, UART, WD_TIMER and I2C in order to support the new reset status flag introduce in the following commit: commit 2cb068149c365f1c2b10f2ece6786139527dcc16 OMAP: hwmod: Fix softreset status check for some new OMAP4 IPs Without this flag properly set, the reset is done, but the hwmod core code will not wait for the reset completion to continue its excecution. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Tested-by: Charulatha V <charu@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Govindraj.R <govindraj.raja@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com>
2010-12-22OMAP4: hwmod data: Fix hwmod entries orderBenoit Cousson1-450/+553
The original OMAP4 hwmod data files is fully generated from HW database. But since the file is introduced incrementaly along with driver that uses the data, it has to be splitted by the driver owner and then re-merged by the maintainer. Because of the similarity of the data, git is completely lost during such merge and thus the data does not look like the original one at the end. Re-order properly the structures to stay in sync with original data set. This makes it much easier to diff the autogenerated script output with what's in mainline, see differences, and generate patches for those diffs. The goal is to stay in sync with the autogenerated data from now on. Add a comment that does contain all the IPs that can have a hwmod, but do not have it in the file for the moment. It gives a good indication of the progress. Signed-off-by: Benoit Cousson <b-cousson@ti.com> [paul@pwsan.com: updated to apply against current core integration branch, commit message slightly amplified; fixed opt_clks_cnt whitespace] Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Govindraj.R <govindraj.raja@ti.com> Cc: Charulatha V <charu@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com>
2010-12-22OMAP1: clock_data: use runtime cpu / machine checksJanusz Krzysztofik1-9/+8
Otherwise multi-omap1 configurations may set wrong clock speed. Created and tested against l-o master on Amstrad Delta. Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-12-22OMAP2/3: SRAM: add comment about crashes during a TLB missPaul Walmsley3-0/+18
Some users were observing crashes during the execution of CORE DVFS code from OCM RAM -- a locally-modified copy of the linux-omap code. Richard Woodruff tracked this down to a DTLB miss which had been inadvertently and intermittently caused by the local modifications. (The TLB miss caused the ARM MMU to attempt to walk the page tables stored in SDRAM, which was not possible since SDRAM is off-line for a portion of the CORE DVFS OCM RAM code.) Add a note to the OMAP2 & OMAP3 CORE DVFS SRAM code to warn others that changes may result in crashes here if they are not carefully tested. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Richard Woodruff <r-woodruff2@ti.com> Cc: Jon Hunter <jon-hunter@ti.com> Cc: Nishanth Menon <nm@ti.com>
2010-12-22OMAP3: clock: fix incorrect rate display when switching MPU rate at bootPaul Walmsley1-1/+1
The OMAP3 clock code contains some legacy code to allow the MPU rate to be specified as a kernel command line parameter. If the 'mpurate' parameter is specified, the kernel will attempt to switch the MPU rate to this rate during boot. As part of this process, a short message "Switched to new clocking rate" is generated -- and in this message, the "Core" clock rate and "MPU" clock rate are transposed. This patch ensures that the clock rates are displayed in the correct order. Thanks to Bruno Guerin <br.guerin@free.fr> for reporting this bug and proposing a fix. Thanks to Richard Woodruff <r-woodruff2@ti.com> for reviewing the problem and passing the report on. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Bruno Guerin <br.guerin@free.fr> Cc: Richard Woodruff <r-woodruff2@ti.com>
2010-12-22OMAP3: clock: clarify usage of struct clksel_rate.flags and struct omap_clk.cpuPaul Walmsley3-117/+120
Clarify the usage of the struct omap_clk.cpu flags (e.g., CK_*) to use bits only for individual SoC variants (e.g., CK_3430ES1, CK_3505, etc.). Superset flags, such as CK_3XXX or CK_AM35XX, are now defined as disjunctions of individual SoC variant flags. This simplifies the definition and use of these flags. struct omap_clk record definitions can now simply specify the bitmask of actual SoCs that the records are valid for. The clock init code can simply set a single CPU type mask bit for the SoC that is currently in use, and test against that, rather than needing to set some combination of flags. Similarly, clarify the use of struct clksel_rate.flags. The bit allocated for RATE_IN_3XXX has been reassigned, and RATE_IN_3XXX has been defined as a disjunction of the 34xx and 36xx rate flags. The advantages are the same as the above. Clarify the usage of struct omap_clk.cpu flags such as CK_34XX to only apply to the SoCs that they name, e.g., OMAP34xx chips. The previous practice caused significantly different SoCs, such as OMAP36xx, to be included in CK_34XX. In my opinion, this is much more intuitive. Similarly, clarify the use of struct clksel_rate.flags, such that RATE_IN_3430ES2PLUS now only applies to 34xx chips with ES level >= 2 - it does not apply to OMAP36xx. ... At some point, it probably makes sense to collapse the CK_* and RATE_IN_* flags together into a single bitfield, and possibly use the existing CHIP_IS_OMAP* flags for platform detection. ... This all seems to work fine on OMAP34xx and OMAP36xx Beagle. Not sure if it works on Sitara or the TI816X, unfortunately I don't have any here to test with. Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-12-22OMAP2xxx clock: fix dss2_fck recalc to use clkselPaul Walmsley2-2/+2
dss2_fck is a clksel clock, and therefore its rate should be recalculated with the clksel mechanism. This was working in early 2009, but was one of the casualties of the big OMAP clock merge between 2.6.29 and 2.6.30. Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-12-22OMAP4: clock data: Export control to enable/disable CORE/PER M3 clocksRajendra Nayak1-2/+6
The CORE and PER M3 post dividers are different from the rest of the DPLL post dividers as in they go to SCRM, and are used there to export clocks for instance used by external sensor. There is no automatic HW dependency in PRCM to manage them. Hence these two clocks (dpll post dividers) should be managed by SW and explicitly enabled/disabled. Add control in clock framework to handle that. Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-12-22OMAP4: clock data: Add SCRM auxiliary clock nodesRajendra Nayak1-0/+175
Add support for auxiliary clocks nodes which are part of SCRM. Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-12-22OMAP4: clock data: Add missing fields in iva_hsd_byp_clk_mux_ckJonathan Bergsagel1-1/+5
Add register address, mask and link to the clksel structure that were missing in the IVA DPLL mux clock node. Signed-off-by: Jonathan Bergsagel <jbergsagel@ti.com> Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com>
2010-12-22OMAP4: clock data: Add missing DPLL x2 clock nodesThara Gopinath1-175/+240
This patch extends the OMAP4 clock data to include various x2 clock nodes between DPLL and HS dividers as the clock framework skips a x2 while calculating the dpll locked frequency. The clock database extensions are autogenerated using the scripts maintained by Benoit Cousson. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Thara Gopinath <thara@ti.com> [paul@pwsan.com: fixed merge conflicts against v2.6.37-rc5; dropped dpll_mpu_x2_ck on advice from Benoît] Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com>
2010-12-22OMAP3: clock data: Add "wkup_clkdm" in sr1_fck and sr2_fckBenoit Cousson1-0/+2
The smartreflex modules belong to an ALWON_FCLK clock domain that does not have any SW control. The gating of that interface clock is triggered by a transition of the WKUP clock domain to idle. Attach both smartreflex instances on OMAP3 to the WKUP clock domain. The missing clock domain field in srX_fck clock nodes was reported by Kevin during the discussion about smartreflex on OMAP3: https://patchwork.kernel.org/patch/199342/ Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com>
2010-12-22OMAP4: clock data: Add control for pad_clks_ck and slimbus_clkBenoit Cousson1-2/+6
The gating of pad_clks and slimbus_ck is controlled by the PRCM, but since the clock source is external, this is the SW responsability to gate / un-gate it when the mcpdm or slimbus module need to be used. There is no autogating possible with such external clock. Add SW control to enable / disable this SW gating in the pad_clks_ck and slimbus_clk clock node. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Sebastien Guiriec <s-guiriec@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com>
2010-12-22OMAP3: control/PM: move padconf save code to mach-omap2/control.cPaul Walmsley4-13/+33
Move the padconf save code from pm34xx.c to the System Control Module code in mach-omap2/control.c. This is part of the general push to move direct register access from middle-layer core code to low-level core code, so the middle-layer code can be abstracted to work on multiple platforms and cleaned up. In the medium-to-long term, this code should be called by the mux layer code, not the PM idle code. This is because, according to the TRM, saving the padconf only needs to be done when the padconf changes[1]. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Tested-by: Rajendra Nayak <rnayak@ti.com> Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com> 1. OMAP34xx Multimedia Device Silicon Revision 3.1.x [Rev. ZH] [SWPU222H] Section 4.11.4 "Device Off-Mode Sequences"
2010-12-22OMAP2+: powerdomain: move header file from plat-omap to mach-omap2Paul Walmsley27-72/+45
The OMAP powerdomain code and data is all OMAP2+-specific. This seems unlikely to change any time soon. Move plat-omap/include/plat/powerdomain.h to mach-omap2/powerdomain.h. The primary point of doing this is to remove the temptation for unrelated upper-layer code to access powerdomain code and data directly. As part of this process, remove the references to powerdomain data from the GPIO "driver" and the OMAP PM no-op layer, both in plat-omap. Change the DSPBridge code to point to the new location for the powerdomain headers. The DSPBridge code should not be including the powerdomain headers; these should be removed. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Omar Ramirez Luna <omar.ramirez@ti.com> Cc: Felipe Contreras <felipe.contreras@gmail.com> Cc: Greg Kroah-Hartman <greg@kroah.com>