1. 22 Dec, 2010 6 commits
    • Thara Gopinath's avatar
      OMAP3: PM: Adding smartreflex device file. · 0c0a5d61
      Thara Gopinath authored
      
      
      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: default avatarThara Gopinath <thara@ti.com>
      Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      0c0a5d61
    • Thara Gopinath's avatar
      OMAP3: PM: Adding smartreflex driver support. · 984aa6db
      Thara Gopinath authored
      
      
      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: default avatarThara Gopinath <thara@ti.com>
      Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      984aa6db
    • Thara Gopinath's avatar
      OMAP: Introduce voltage domain information in the hwmod structures · 3b92408c
      Thara Gopinath authored
      
      
      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: default avatarThara Gopinath <thara@ti.com>
      Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      3b92408c
    • Thara Gopinath's avatar
      OMAP3: PM: Adding voltage driver support. · 2f34ce81
      Thara Gopinath authored
      
      
      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: default avatarThara Gopinath <thara@ti.com>
      [khilman: fixed link error for OMAP2-only defconfig]
      Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      2f34ce81
    • Jon Hunter's avatar
      OMAP4: clock data: Add missing fixed divisors · f17f9726
      Jon Hunter authored
      
      
      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: default avatarJon Hunter <jon-hunter@ti.com>
      Signed-off-by: default avatarBenoit Cousson <b-cousson@ti.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      f17f9726
    • Vishwanath BS's avatar
      OMAP3: SDRC: Add comments on Errata i520 for Global SW reset · 9bf83918
      Vishwanath BS authored
      
      
      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: default avatarVishwanath BS <vishwanath.bs@ti.com>
      [paul@pwsan.com: fixed typos, one mentioned by Sanjeev]
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Sanjeev Premi <premi@ti.com>
      9bf83918
  2. 21 Dec, 2010 34 commits
    • Santosh Shilimkar's avatar
      OMAP4: clock data: Keep L3INSTR clock domain modulemode under HW control · 60a0e5d9
      Santosh Shilimkar authored
      
      
      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: default avatarRajendra Nayak <rnayak@ti.com>
      Signed-off-by: default avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
      Acked-by: default avatarBenoit Cousson <b-cousson@ti.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      60a0e5d9
    • Santosh Shilimkar's avatar
      OMAP4: powerdomain: Remove L3INIT_PD OFF state · 80f09365
      Santosh Shilimkar authored
      
      
      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: default avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
      [b-cousson@ti.com: update the changelog with next OMAP info]
      Signed-off-by: default avatarBenoit Cousson <b-cousson@ti.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      80f09365
    • Rajendra Nayak's avatar
      OMAP4: powerdomain: l4per pwrdm does not support OFF · 474e7aeb
      Rajendra Nayak authored
      
      
      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: default avatarRajendra Nayak <rnayak@ti.com>
      Acked-by: default avatarBenoit Cousson <b-cousson@ti.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      474e7aeb
    • Rajendra Nayak's avatar
      OMAP4: PM: Do not assume clkdm supports hw transitions · 33de32b3
      Rajendra Nayak authored
      
      
      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: default avatarRajendra Nayak <rnayak@ti.com>
      Signed-off-by: default avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
      Acked-by: default avatarBenoit Cousson <b-cousson@ti.com>
      Acked-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      33de32b3
    • Rajendra Nayak's avatar
      OMAP4: PM: Use the low-power state change feature on OMAP4 · 71a488db
      Rajendra Nayak authored
      
      
      For pwrdm's which support LOWPOWERSTATECHANGE, do not try waking
      up the domain to put it back to deeper sleep state.
      
      Signed-off-by: default avatarRajendra Nayak <rnayak@ti.com>
      Signed-off-by: default avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
      Acked-by: default avatarBenoit Cousson <b-cousson@ti.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      Acked-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      71a488db
    • Kevin Hilman's avatar
      OMAP: PM noop: implement context loss count for non-omap_devices · 6081dc34
      Kevin Hilman authored
      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: default avatarKevin Hilman <khilman@deeprootsystems.com>
      [paul@pwsan.com: fixed compile warning; fixed to compile on OMAP1]
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      6081dc34
    • Kevin Hilman's avatar
      OMAP: PM: implement context loss count APIs · c80705aa
      Kevin Hilman authored
      
      
      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: default avatarKevin Hilman <khilman@deeprootsystems.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      c80705aa
    • Kevin Hilman's avatar
      OMAP2+: powerdomain: add API to get context loss count · 7f595674
      Kevin Hilman authored
      
      
      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: default avatarKevin Hilman <khilman@deeprootsystems.com>
      [paul@pwsan.com: removed bogus return value on error; improved kerneldoc;
       tweaked commit message]
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      7f595674
    • Hari Kanigeri's avatar
      OMAP4: clocks: add dummy clock for mailbox · 0a01aa21
      Hari Kanigeri authored
      
      
      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: default avatarHari Kanigeri <h-kanigeri2@ti.com>
      Acked-by: default avatarBenoît Cousson <b-cousson@ti.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      0a01aa21
    • Jon Hunter's avatar
      OMAP: clock: fix configuration of J-Type DPLLs to work for OMAP3 and OMAP4 · a36795c1
      Jon Hunter authored
      
      
      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: default avatarJon 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: default avatarPaul Walmsley <paul@pwsan.com>
      a36795c1
    • Charulatha V's avatar
      OMAP3: clock: Update clock domain name for mcspi fck · b183aaf7
      Charulatha V authored
      
      
      Update clock3xxx_data for mcspi1-4 with appropriate clock domain name.
      
      Signed-off-by: default avatarCharulatha V <charu@ti.com>
      Signed-off-by: default avatarGovindraj.R <govindraj.raja@ti.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      b183aaf7
    • Benoit Cousson's avatar
      OMAP4: hwmod data: Add SIDLE_SMART_WKUP modes to several IPs · 7cffa6b8
      Benoit Cousson authored
      
      
      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: default avatarBenoit Cousson <b-cousson@ti.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      7cffa6b8
    • Benoit Cousson's avatar
      OMAP2+: hwmod: Add wakeup support for new OMAP4 IPs · 86009eb3
      Benoit Cousson authored
      
      
      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: default avatarBenoit Cousson <b-cousson@ti.com>
      Tested-by: default avatarSebastien Guiriec <s-guiriec@ti.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      86009eb3
    • Rajendra Nayak's avatar
      OMAP2+: hwmod: Disable clocks when hwmod enable fails · f2dd7e09
      Rajendra Nayak authored
      
      
      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: default avatarRajendra Nayak <rnayak@ti.com>
      Signed-off-by: default avatarBenoit Cousson <b-cousson@ti.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      f2dd7e09
    • Benoit Cousson's avatar
      OMAP2+: hwmod: Remove omap_hwmod_mutex · ce35b244
      Benoit Cousson authored
      
      
      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: default avatarBenoit Cousson <b-cousson@ti.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      ce35b244
    • Benoit Cousson's avatar
      OMAP2+: hwmod: Mark functions used only during initialization with __init · 01592df9
      Benoit Cousson authored
      
      
      _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: default avatarBenoit Cousson <b-cousson@ti.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      01592df9
    • Benoit Cousson's avatar
      OMAP2+: hwmod: Make omap_hwmod_register private and remove omap_hwmod_unregister · 0102b627
      Benoit Cousson authored
      
      
      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: default avatarBenoit Cousson <b-cousson@ti.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      0102b627
    • Benoit Cousson's avatar
      OMAP2430: hwmod data: Use common dev_attr for i2c1 and i2c2 · 50ebb777
      Benoit Cousson authored
      
      
      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: default avatarBenoit Cousson <b-cousson@ti.com>
      Acked-by: default avatarRajendra Nayak <rnayak@ti.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Charulatha V <charu@ti.com>
      50ebb777
    • Kevin Hilman's avatar
      OMAP2+: omap_hwmod: fix wakeup enable/disable for consistency · 5a7ddcbd
      Kevin Hilman authored
      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: 9980ce53
              OMAP: hwmod: Enable module wakeup if in smartidle
      
      commit: 78f26e87
      
      
              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: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Benoit Cousson <b-cousson@ti.com>
      Signed-off-by: default avatarBenoit Cousson <b-cousson@ti.com>
      Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      5a7ddcbd
    • Benoit Cousson's avatar
      OMAP4: hwmod & clock data: Fix GPIO opt_clks and ocp_if iclk · b399bca8
      Benoit Cousson authored
      
      
      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: default avatarBenoit Cousson <b-cousson@ti.com>
      Tested-by: default avatarCharulatha V <charu@ti.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      b399bca8
    • Benoit Cousson's avatar
      OMAP4: hwmod data: Add IVA and DSP · 8f25bdc5
      Benoit Cousson authored
      
      
      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: default avatarBenoit Cousson <b-cousson@ti.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      8f25bdc5
    • Benoit Cousson's avatar
      OMAP4: hwmod data: Fix missing address in DMM and EMIF_FW · 659fa822
      Benoit Cousson authored
      
      
      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: default avatarBenoit Cousson <b-cousson@ti.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      659fa822
    • Benoit Cousson's avatar
      OMAP4: hwmod data: Add SYSS_HAS_RESET_STATUS flag · 0cfe8751
      Benoit Cousson authored
      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 2cb06814
      
      
      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: default avatarBenoit Cousson <b-cousson@ti.com>
      Tested-by: default avatarCharulatha V <charu@ti.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      Cc: Govindraj.R <govindraj.raja@ti.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      0cfe8751
    • Benoit Cousson's avatar
      OMAP4: hwmod data: Fix hwmod entries order · 3b54baad
      Benoit Cousson authored
      
      
      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: default avatarBenoit 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: default avatarPaul 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>
      3b54baad
    • Janusz Krzysztofik's avatar
      OMAP1: clock_data: use runtime cpu / machine checks · 65ae65c9
      Janusz Krzysztofik authored
      
      
      Otherwise multi-omap1 configurations may set wrong clock speed.
      
      Created and tested against l-o master on Amstrad Delta.
      
      Signed-off-by: default avatarJanusz Krzysztofik <jkrzyszt@tis.icnet.pl>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      65ae65c9
    • Paul Walmsley's avatar
      OMAP2/3: SRAM: add comment about crashes during a TLB miss · 1124d2f9
      Paul Walmsley authored
      
      
      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: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Richard Woodruff <r-woodruff2@ti.com>
      Cc: Jon Hunter <jon-hunter@ti.com>
      Cc: Nishanth Menon <nm@ti.com>
      1124d2f9
    • Paul Walmsley's avatar
      OMAP3: clock: fix incorrect rate display when switching MPU rate at boot · f1f4b770
      Paul Walmsley authored
      
      
      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: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Bruno Guerin <br.guerin@free.fr>
      Cc: Richard Woodruff <r-woodruff2@ti.com>
      f1f4b770
    • Paul Walmsley's avatar
      OMAP3: clock: clarify usage of struct clksel_rate.flags and struct omap_clk.cpu · 553d239a
      Paul Walmsley authored
      
      
      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: default avatarPaul Walmsley <paul@pwsan.com>
      553d239a
    • Paul Walmsley's avatar
      OMAP2xxx clock: fix dss2_fck recalc to use clksel · d4521f67
      Paul Walmsley authored
      
      
      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: default avatarPaul Walmsley <paul@pwsan.com>
      d4521f67
    • Rajendra Nayak's avatar
      OMAP4: clock data: Export control to enable/disable CORE/PER M3 clocks · cb13459b
      Rajendra Nayak authored
      
      
      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: default avatarRajendra Nayak <rnayak@ti.com>
      Signed-off-by: default avatarBenoit Cousson <b-cousson@ti.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      cb13459b
    • Rajendra Nayak's avatar
      OMAP4: clock data: Add SCRM auxiliary clock nodes · e0cb70c5
      Rajendra Nayak authored
      
      
      Add support for auxiliary clocks nodes which are part of SCRM.
      
      Signed-off-by: default avatarRajendra Nayak <rnayak@ti.com>
      Signed-off-by: default avatarBenoit Cousson <b-cousson@ti.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      e0cb70c5
    • Jonathan Bergsagel's avatar
      OMAP4: clock data: Add missing fields in iva_hsd_byp_clk_mux_ck · 768ab94f
      Jonathan Bergsagel authored
      
      
      Add register address, mask and link to the clksel structure that
      were missing in the IVA DPLL mux clock node.
      
      Signed-off-by: default avatarJonathan Bergsagel <jbergsagel@ti.com>
      Signed-off-by: default avatarBenoit Cousson <b-cousson@ti.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      768ab94f
    • Thara Gopinath's avatar
      OMAP4: clock data: Add missing DPLL x2 clock nodes · 032b5a7e
      Thara Gopinath authored
      
      
      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: default avatarBenoit Cousson <b-cousson@ti.com>
      Signed-off-by: default avatarThara 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: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      032b5a7e
    • Benoit Cousson's avatar
      OMAP3: clock data: Add "wkup_clkdm" in sr1_fck and sr2_fck · ae4b4fc1
      Benoit Cousson authored
      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: default avatarBenoit Cousson <b-cousson@ti.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      ae4b4fc1