1. 16 Feb, 2011 3 commits
  2. 14 Feb, 2011 2 commits
  3. 19 Jan, 2011 2 commits
  4. 18 Jan, 2011 1 commit
    • Paul Walmsley's avatar
      OMAP: counter_32k: init clocksource as part of machine timer init · d8328f3b
      Paul Walmsley authored
      After commit dc548fbb ("ARM: omap: convert
      sched_clock() to use new infrastructure"), OMAPs that use the 32KiHz
      "synchronization timer" as their clocksource crash during boot:
      
      [    0.000000] OMAP clockevent source: GPTIMER1 at 32768 Hz
      [    0.000000] Unable to handle kernel NULL pointer dereference at virtual address 00000000
      [    0.000000] pgd = c0004000
      [    0.000000] [00000000] *pgd=00000000
      [    0.000000] Internal error: Oops: 80000005 [#1] SMP
      [    0.000000] last sysfs file:
      [    0.000000] Modules linked in:
      [    0.000000] CPU: 0    Tainted: G        W    (2.6.37-07734-g2467802 #7)
      [    0.000000] PC is at 0x0
      [    0.000000] LR is at sched_clock_poll+0x2c/0x3c
      [    0.000000] pc : [<00000000>]    lr : [<c0060b74>]    psr: 600001d3
      [    0.000000] sp : c058bfd0  ip : c058a000  fp : 00000000
      [    0.000000] r10: 00000000  r9 : 411fc092  r8 : 800330c8
      [    0.000000] r7 : c05a08e0  r6 : c0034c48  r5 : c05ffc40  r4 : c0034c4c
      [    0.000000] r3 : c05ffe6c  r2 : c05a0bc0  r1 : c059f098  r0 : 00000000
      [    0.000000] Flags: nZCv  IRQs off  FIQs off  Mode SVC_32  ISA ARM  Segment kernel
      [    0.000000] Control: 10c53c7f  Table: 8000404a  DAC: 00000017
      
      This is due to the recent ARM init_sched_clock() changes and the late
      initialization of the counter_32k clock source.  More information here:
      
         http://marc.info/?l=linux-omap&m=129513468605208&w=2
      
      
      
      Fix by initializing the counter_32k clocksource during the machine timer
      initialization.
      Reported-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Tested-by: default avatarThomas Weber <weber@corscience.de>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      d8328f3b
  5. 10 Jan, 2011 5 commits
  6. 07 Jan, 2011 3 commits
    • Santosh Shilimkar's avatar
      omap2plus: voltage: Trivial linking fix for 'EINVAL' undeclared · faacebc5
      Santosh Shilimkar authored
      
      
      CC      arch/arm/mach-omap2/omap_hwmod_common_data.o
      In file included from arch/arm/plat-omap/include/plat/omap_hwmod.h:38,
                       from arch/arm/mach-omap2/omap_hwmod_common_data.c:20:
      arch/arm/plat-omap/include/plat/voltage.h: In function 'omap_voltage_late_init':
      arch/arm/plat-omap/include/plat/voltage.h:145: error: 'EINVAL' undeclared (first use in this function)
      arch/arm/plat-omap/include/plat/voltage.h:145: error: (Each undeclared identifier is reported only once
      arch/arm/plat-omap/include/plat/voltage.h:145: error: for each function it appears in.)
      make[1]: *** [arch/arm/mach-omap2/omap_hwmod_common_data.o] Error 1
      make: *** [arch/arm/mach-omap2] Error 2
      
      The error is reported when omap2plus_defconfig built with CONFIG_PM disabled
      Signed-off-by: default avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
      Cc: Thara Gopinath <thara@ti.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      Cc: Nishanth Menon <nm@ti.com>
      Signed-off-by: default avatarKevin Hilman <khilman@ti.com>
      faacebc5
    • Santosh Shilimkar's avatar
      omap2plus: voltage: Trivial linking fix 'undefined reference' · dd361b6f
      Santosh Shilimkar authored
      
      
      LD      init/built-in.o
      LD      .tmp_vmlinux1
      arch/arm/mach-omap2/built-in.o: In function `omap2_set_init_voltage':
      arch/arm/mach-omap2/pm.c:181: undefined reference to `omap_voltage_domain_lookup'
      arch/arm/mach-omap2/built-in.o: In function `omap4_twl_init':
      arch/arm/mach-omap2/omap_twl.c:244: undefined reference to `omap_voltage_domain_lookup'
      arch/arm/mach-omap2/omap_twl.c:247: undefined reference to `omap_voltage_domain_lookup'
      arch/arm/mach-omap2/omap_twl.c:250: undefined reference to `omap_voltage_domain_lookup'
      make: *** [.tmp_vmlinux1] Error 1
      
      The error is reported when omap2plus_defconfig built with CONFIG_PM disabled
      Signed-off-by: default avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
      Cc: Thara Gopinath <thara@ti.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      Cc: Nishanth Menon <nm@ti.com>
      Signed-off-by: default avatarKevin Hilman <khilman@ti.com>
      dd361b6f
    • Santosh Shilimkar's avatar
      omap2plus: voltage: Trivial warning fix 'no return statement' · d7e08f1b
      Santosh Shilimkar authored
      
      
      Fix below build warnings
      
       CC      arch/arm/mach-omap2/common.o
        CC      arch/arm/mach-omap2/gpio.o
      In file included from arch/arm/plat-omap/include/plat/omap_hwmod.h:38,
                       from arch/arm/mach-omap2/gpio.c:25:
      arch/arm/plat-omap/include/plat/voltage.h: In function 'omap_voltage_register_pmic':
      arch/arm/plat-omap/include/plat/voltage.h:137: warning: no return statement in function returning non-void
        CC      arch/arm/mach-omap2/dma.o
      In file included from arch/arm/plat-omap/include/plat/omap_hwmod.h:38,
                       from arch/arm/mach-omap2/dma.c:32:
      arch/arm/plat-omap/include/plat/voltage.h: In function 'omap_voltage_register_pmic':
      arch/arm/plat-omap/include/plat/voltage.h:137: warning: no return statement in function returning non-void
        CC      arch/arm/mach-omap2/wd_timer.o
      In file included from arch/arm/plat-omap/include/plat/omap_hwmod.h:38,
                       from arch/arm/mach-omap2/wd_timer.c:15:
      arch/arm/plat-omap/include/plat/voltage.h: In function 'omap_voltage_register_pmic':
      arch/arm/plat-omap/include/plat/voltage.h:137: warning: no return statement in function returning non-void
        CC      arch/arm/mach-omap2/prm44xx.o
        CC      arch/arm/mach-omap2/omap_hwmod.o
      In file included from arch/arm/plat-omap/include/plat/omap_hwmod.h:38,
                       from arch/arm/mach-omap2/omap_hwmod.c:145:
      arch/arm/plat-omap/include/plat/voltage.h: In function 'omap_voltage_register_pmic':
      arch/arm/plat-omap/include/plat/voltage.h:137: warning: no return statement in function returning non-void
        CC      arch/arm/mach-omap2/omap_hwmod_common_data.o
      In file included from arch/arm/plat-omap/include/plat/omap_hwmod.h:38,
                       from arch/arm/mach-omap2/omap_hwmod_common_data.c:20:
      arch/arm/plat-omap/include/plat/voltage.h: In function 'omap_voltage_register_pmic':
      arch/arm/plat-omap/include/plat/voltage.h:137: warning: no return statement in function returning non-void
      
      The error is reported when omap2plus_defconfig built with CONFIG_PM disabled
      Signed-off-by: default avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
      Cc: Thara Gopinath <thara@ti.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      Cc: Nishanth Menon <nm@ti.com>
      Signed-off-by: default avatarKevin Hilman <khilman@ti.com>
      d7e08f1b
  7. 06 Jan, 2011 1 commit
  8. 03 Jan, 2011 1 commit
  9. 22 Dec, 2010 7 commits
    • Tony Lindgren's avatar
      omap2+: Add struct omap_board_data and use it for platform level serial init · 40e44399
      Tony Lindgren authored
      
      
      This is needed to pass board specific data such as pads used to the
      platform level driver init code.
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      40e44399
    • Tony Lindgren's avatar
      omap2+: Add support for hwmod specific muxing of devices · 9796b323
      Tony Lindgren authored
      
      
      This allows adding hwmod specific pads dynamically during the
      platform device init.
      
      Note that we don't currently have the hwmod specific signals
      listed in the hwmod data, but struct omap_hwmod_mux_info will
      make that possible if necessary.
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      9796b323
    • Thara Gopinath's avatar
      OMAP4: Adding voltage driver support · bd38107b
      Thara Gopinath authored
      
      
      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: default avatarThara Gopinath <thara@ti.com>
      Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      bd38107b
    • 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
    • Janusz Krzysztofik's avatar
      Keyboard: omap-keypad: use matrix_keypad.h · da1f026b
      Janusz Krzysztofik authored
      
      
      Most keypad drivers make use of the <linux/input/matrix_keypad.h>
      defined macros, structures and inline functions.
      
      Convert omap-keypad driver to use those as well, as suggested by a
      compile time warning, hardcoded into the OMAP <palt/keypad.h>.
      
      Created against linux-2.6.37-rc5.
      Tested on Amstrad Delta.
      Compile tested with omap1_defconfig and omap2plus_defconfig shrinked to
      board-h4.
      Signed-off-by: default avatarJanusz Krzysztofik <jkrzyszt@tis.icnet.pl>
      Reviewed-by: default avatarAaro Koskinen <aaro.koskinen@nokia.com>
      Acked-by: default avatarDmitry Torokhov <dtor@mail.ru>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      da1f026b
  10. 21 Dec, 2010 15 commits
    • 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
    • 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
    • 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
    • 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
    • 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
      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: 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
      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