1. 21 Dec, 2010 40 commits
    • 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
    • Benoit Cousson's avatar
      OMAP4: clock data: Add control for pad_clks_ck and slimbus_clk · d9b98f5f
      Benoit Cousson authored
      
      
      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: default avatarBenoit Cousson <b-cousson@ti.com>
      Signed-off-by: default avatarSebastien Guiriec <s-guiriec@ti.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      d9b98f5f
    • Paul Walmsley's avatar
      OMAP3: control/PM: move padconf save code to mach-omap2/control.c · 596efe47
      Paul Walmsley authored
      
      
      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: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Tested-by: default avatarRajendra Nayak <rnayak@ti.com>
      Tested-by: default avatarSantosh 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"
      596efe47
    • Paul Walmsley's avatar
      OMAP2+: powerdomain: move header file from plat-omap to mach-omap2 · 72e06d08
      Paul Walmsley authored
      
      
      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: default avatarPaul 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>
      72e06d08
    • Paul Walmsley's avatar
      OMAP2+: clockdomain: move header file from plat-omap to mach-omap2 · 1540f214
      Paul Walmsley authored
      
      
      The OMAP clockdomain code and data is all OMAP2+-specific.  This seems
      unlikely to change any time soon.  Move plat-omap/include/plat/clockdomain.h
      to mach-omap2/clockdomain.h.  The primary point of doing this is to remove
      the temptation for unrelated upper-layer code to access clockdomain code
      and data directly.
      
      DSPBridge also uses the clockdomain headers for some reason, so,
      modify it also. The DSPBridge code should not be including the
      clockdomain headers; these should be removed.
      Signed-off-by: default avatarPaul 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>
      Tested-by: default avatarRajendra Nayak <rnayak@ti.com>
      Tested-by: default avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
      1540f214
    • Paul Walmsley's avatar
      OMAP2/3: clockdomain: remove unneeded .clkstctrl_reg, remove some direct CM register accesses · 55ae3507
      Paul Walmsley authored
      Reverse some of the effects of commit
      84c0c39a
      
       ("ARM: OMAP4: PM: Make OMAP3
      Clock-domain framework compatible for OMAP4").  On OMAP2/3, the
      CM_CLKSTCTRL register is at a constant offset from the powerdomain's
      CM instance.
      
      Also, remove some of the direct CM register access from the
      clockdomain code, moving it to the OMAP2/3 CM code instead.  The
      intention here is to simplify the clockdomain code.  (The long-term
      goal is to move all direct CM register access across the OMAP core
      code to the appropriate cm*.c file.)
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Tested-by: default avatarRajendra Nayak <rnayak@ti.com>
      Tested-by: default avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
      55ae3507
    • Paul Walmsley's avatar
      OMAP4: clockdomains: add OMAP4 PRCM data and OMAP4 support · bd2122ca
      Paul Walmsley authored
      
      
      Add PRCM partition, CM instance register address offset, and clockdomain
      register address offset to each OMAP4 struct clockdomain record.  Add OMAP4
      clockdomain code to use this new data to access registers properly.
      
      While here, clean up some nearby clockdomain code to allocate auto variables
      in my recollection of Linus's preferred style.
      
      The autogeneration scripts have been updated.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Tested-by: default avatarRajendra Nayak <rnayak@ti.com>
      Tested-by: default avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
      bd2122ca
    • Paul Walmsley's avatar
      OMAP4: CM instances: add clockdomain register offsets · e4156ee5
      Paul Walmsley authored
      
      
      In OMAP4 CM instances, some registers (CM_CLKSTCTRL, CM_STATICDEP,
      CM_DYNAMICDEP, and the module-specific registers underneath) are
      organized by clockdomain.  Add the clockdomain offset macros to the
      appropriate PRCM module header files.
      
      This data was almost completely autogenerated from the TI hardware
      database; the autogeneration scripts have been updated.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Tested-by: default avatarRajendra Nayak <rnayak@ti.com>
      Tested-by: default avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
      e4156ee5
    • Paul Walmsley's avatar
      OMAP2+: clockdomains: split the clkdm hwsup enable/disable function · b170fbe1
      Paul Walmsley authored
      
      
      Split _omap2_clkdm_set_hwsup() into _disable_hwsup() and _enable_hwsup().
      
      While here, also document that the autodeps are deprecated and that they
      should be removed at the earliest opportunity.
      
      The documentation has been fixed for _{enable,disable}_hwsup(), thanks
      to Kevin Hilman <khilman@deeprootsystems.com> for pointing out that those
      functions still had placeholder documentation in an earlier patch revision.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      Tested-by: default avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
      Tested-by: default avatarRajendra Nayak <rnayak@ti.com>
      b170fbe1
    • Paul Walmsley's avatar
      OMAP4: powerdomains: add PRCM partition data; use OMAP4 PRM functions · a64bb9cd
      Paul Walmsley authored
      
      
      OMAP4 powerdomain control registers are split between the PRM hardware
      module and the PRCM_MPU local PRCM.  Add this PRCM partition
      information to each OMAP4 powerdomain record, and convert the OMAP4
      powerdomain function implementations to use the OMAP4 PRM instance
      functions.
      
      Also fixes a potential null pointer dereference of pwrdm->name.
      
      The autogeneration scripts have been updated.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Tested-by: default avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
      Tested-by: default avatarRajendra Nayak <rnayak@ti.com>
      a64bb9cd
    • Paul Walmsley's avatar
      OMAP2/3: PRM/CM: prefix OMAP2 PRM/CM functions with "omap2_" · c4d7e58f
      Paul Walmsley authored
      
      
      Now that OMAP4-specific PRCM functions have been added, distinguish the
      existing OMAP2/3-specific PRCM functions by prefixing them with "omap2_".
      
      This patch should not result in any functional change.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      Cc: Jarkko Nikula <jhnikula@gmail.com>
      Cc: Peter Ujfalusi <peter.ujfalusi@nokia.com>
      Cc: Liam Girdwood <lrg@slimlogic.co.uk>
      Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
      Tested-by: default avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
      Tested-by: default avatarRajendra Nayak <rnayak@ti.com>
      c4d7e58f
    • Paul Walmsley's avatar
      OMAP4: PRCM: move global reset function for OMAP4 to an OMAP4-specific file · dac9a771
      Paul Walmsley authored
      
      
      Move the OMAP4 global software reset function to the OMAP4-specific
      prm44xx.c file, where it belongs.  Part of the long-term process of
      moving all of the direct PRCM register writes into lower-layer code.
      
      Also add OCP barriers on OMAP2/3/4 to reduce the chance that the MPU
      will continue executing while the system is supposed to be resetting
      itself.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Tested-by: default avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
      Tested-by: default avatarRajendra Nayak <rnayak@ti.com>
      dac9a771
    • Paul Walmsley's avatar
      OMAP4: PRCM: add OMAP4-specific accessor/mutator functions · 2ace831f
      Paul Walmsley authored
      
      
      In some ways, the OMAP4 PRCM register layout is quite different than
      the OMAP2/3 PRCM register layout.  For example, on OMAP2/3, from a
      register layout point of view, all CM instances were located in the CM
      subsystem, and all PRM instances were located in the PRM subsystem.
      OMAP4 changes this.  Now, for example, some CM instances, such as
      WKUP_CM and EMU_CM, are located in the system PRM subsystem.  And a
      "local PRCM" exists for the MPU - this PRCM combines registers that
      would normally appear in both CM and PRM instances, but uses its own
      register layout which matches neither the OMAP2/3 PRCM layout nor the
      OMAP4 PRCM layout.
      
      To try to deal with this, introduce some new functions, omap4_cminst*
      and omap4_prminst*.  The former is to be used when writing to a CM
      instance register (no matter what subsystem or hardware module it
      exists in), and the latter, similarly, with PRM instance registers.
      To determine which "PRCM partition" to write to, the functions take a
      PRCM instance ID argument.  Subsequent patches add these partition IDs
      to the OMAP4 powerdomain and clockdomain definitions.
      
      As far as I can see, there's really no good way to handle these types
      of register access inconsistencies.  This patch seemed like the least
      bad approach.
      
      Moving forward, the long-term goal is to remove all direct PRCM
      register access from the PM code.  PRCM register access should go
      through layers such as the powerdomain and clockdomain code that can
      hide the details of how to interact with the specific hardware
      variant.
      
      While here, rename cm4xxx.c to cm44xx.c to match the naming convention
      of the other OMAP4 PRCM files.
      
      Thanks to Santosh Shilimkar <santosh.shilimkar@ti.com>, Rajendra Nayak
      <rnayak@ti.com>, and Benoît Cousson <b-cousson@ti.com> for some comments.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
      2ace831f
    • Paul Walmsley's avatar
      OMAP3: PRM/CM: separate CM context save/restore; remove PRM context save/restore · f0611a5c
      Paul Walmsley authored
      
      
      The OMAP3 PRM module is in the WKUP powerdomain, which is always
      powered when the chip is powered, so it shouldn't be necessary to save
      and restore those PRM registers.  Remove the PRM register save/restore
      code, which should save several microseconds during off-mode
      entry/exit, since PRM register accesses are relatively slow.
      
      While doing so, move the CM register save/restore code into
      CM-specific code.  The CM module has been distinct from the PRM module
      since 2430.
      
      This patch includes some minor changes to pm34xx.c.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      Cc: Tero Kristo <tero.kristo@nokia.com>
      Cc: Kalle Jokiniemi <kalle.jokiniemi@digia.com>
      Reviewed-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      Tested-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      Tested-by: default avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
      Tested-by: default avatarRajendra Nayak <rnayak@ti.com>
      f0611a5c
    • Paul Walmsley's avatar
      OMAP2/3: PRCM: split OMAP2/3-specific PRCM code into OMAP2/3-specific files · 59fb659b
      Paul Walmsley authored
      
      
      In preparation for adding OMAP4-specific PRCM accessor/mutator
      functions, split the existing OMAP2/3 PRCM code into OMAP2/3-specific
      files.  Most of what was in mach-omap2/{cm,prm}.{c,h} has now been
      moved into mach-omap2/{cm,prm}2xxx_3xxx.{c,h}, since it was
      OMAP2xxx/3xxx-specific.
      
      This process also requires the #includes in each of these files to be
      changed to reference the new file name.  As part of doing so, add some
      comments into plat-omap/sram.c and plat-omap/mcbsp.c, which use
      "sideways includes", to indicate that these users of the PRM/CM includes
      should not be doing so.
      
      Thanks to Felipe Contreras <felipe.contreras@gmail.com> for comments on this
      patch.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Jarkko Nikula <jhnikula@gmail.com>
      Cc: Peter Ujfalusi <peter.ujfalusi@nokia.com>
      Cc: Liam Girdwood <lrg@slimlogic.co.uk>
      Cc: Omar Ramirez Luna <omar.ramirez@ti.com>
      Acked-by: default avatarOmar Ramirez Luna <omar.ramirez@ti.com>
      Cc: Felipe Contreras <felipe.contreras@gmail.com>
      Acked-by: default avatarFelipe Contreras <felipe.contreras@gmail.com>
      Cc: Greg Kroah-Hartman <greg@kroah.com>
      Acked-by: default avatarMark Brown <broonie@opensource.wolfsonmicro.com>
      Reviewed-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      Tested-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      Tested-by: default avatarRajendra Nayak <rnayak@ti.com>
      Tested-by: default avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
      59fb659b
    • Paul Walmsley's avatar
      OMAP4: PRCM: rename _MOD macros to _INST · cdb54c44
      Paul Walmsley authored
      
      
      Back in the OMAP2/3 PRCM interface days, the macros that referred to
      the offsets of individual PRM/CM instances from the top of the PRM/CM
      hardware modules were incorrectly suffixed with "_MOD".  (They should
      have been suffixed with something like "_INST" or "_INSTANCE".)  These
      days, now that we have better contact with the OMAP hardware people,
      we know that this naming is wrong.  And in fact in OMAP4, there are
      actual hardware module offsets inside the instances, so the incorrect
      naming gets confusing very quickly for anyone who knows the hardware.
      
      Fix this naming for OMAP4, before things get too far along, by
      changing "_MOD" to "_INST" on the end of these macros.  So, for
      example, OMAP4430_CM2_INSTR_MOD becomes OMAP4430_CM2_INSTR_INST.
      
      This unfortunately creates quite a large diff, but it is a
      straightforward rename.  This patch should not result in any
      functional changes.
      
      The autogeneration scripts have been updated accordingly.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
      Reviewed-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      Tested-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      Tested-by: default avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
      Tested-by: default avatarRajendra Nayak <rnayak@ti.com>
      cdb54c44
    • Benoit Cousson's avatar
      OMAP4: PRCM: Add SCRM header file · 0f318fd5
      Benoit Cousson authored
      
      
      Add the header file with scrm registers absolute address, offset
      and bitfields.
      Signed-off-by: default avatarBenoit Cousson <b-cousson@ti.com>
      Signed-off-by: default avatarRajendra Nayak <rnayak@ti.com>
      [paul@pwsan.com: renamed OMAP4_SCRM to OMAP4_SCRM_BASE]
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      0f318fd5
    • Paul Walmsley's avatar
      OMAP4: PRCM: reorganize existing OMAP4 PRCM header files · d198b514
      Paul Walmsley authored
      
      
      Split the existing cm44xx.h file into cm1_44xx.h and cm2_44xx.h files
      so they match their underlying OMAP hardware modules.  Add clockdomain
      offset information.
      
      Add header files for the MPU local PRCM, prcm_mpu44xx.h, and for the
      SCRM, scrm44xx.h.  SCRM register offsets still need to be added; TI
      should do this.
      
      Move the "_MOD" macros out of the prcm-common.h header file, into the
      header file of the hardware module that they belong to.  For example,
      OMAP4430_PRM_*_MOD macros have been moved into the prm44xx.h header.
      
      Adjust #includes of all files that used the old PRCM header file names
      to point to the new filenames.
      
      The autogeneration scripts have been updated accordingly.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      Reviewed-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      Tested-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      Tested-by: default avatarRajendra Nayak <rnayak@ti.com>
      Tested-by: default avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
      d198b514