1. 06 Jul, 2012 2 commits
  2. 05 Jul, 2012 7 commits
  3. 04 Jul, 2012 11 commits
    • Paul Walmsley's avatar
      Merge branches 'hwmod_am335x_support_3.6', 'clkdm_pwrdm_devel_a_3.6' and... · 8cb8de5d
      Paul Walmsley authored
      Merge branches 'hwmod_am335x_support_3.6', 'clkdm_pwrdm_devel_a_3.6' and 'misc_devel_3.6' into omap_devel_f_3.6
      8cb8de5d
    • Kishon Vijay Abraham I's avatar
      ARM: OMAP2+: hwmod code: add support to set dmadisable in hwmod framework · 6668546f
      Kishon Vijay Abraham I authored
      The DMADISABLE bit is a semi-automatic bit present in sysconfig register
      of some modules. When the DMA must perform read/write accesses, the
      DMADISABLE bit is cleared by the hardware. But when the DMA must stop for power
      management, software must set the DMADISABLE bit back to 1.
      
      In cases where the ROMCODE/BOOTLOADER uses dma, the hardware clears the
      DMADISABLE bit (but the romcode/bootloader might not set it back to 1).
      In order for the kernel to start in a clean state, it is
      necessary for the kernel to set DMADISABLE bit back to 1 (irrespective
      of whether it's been set to 1 in romcode or bootloader).
      
      During _reset of the (hwmod)device, the DMADISABLE bit is set so that it
      does not prevent idling of the system. (NOTE: having DMADISABLE to 0,
      prevents the system to idle)
      
      DMADISABLE bit is present in usbotgss module of omap5.
      
      Cc: Benoit Cousson <b-cousson@ti.com>
      Cc: Kevin Hilman <khilman@ti.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      Signed-off-by: default avatarKishon Vijay Abraham I <kishon@ti.com>
      [paul@pwsan.com: updated to apply; fixed checkpatch warnings]
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      6668546f
    • R Sricharan's avatar
      ARM: OMAP2+: PRM/CM: Move the stubbed prm and cm functions to prcm.c file and make them __weak · 3f4990f4
      R Sricharan authored
      Some prm and cm registers read/write and status functions
      are built only for some custom OMAP2+ builds and are stubbed
      in header files for other builds under ifdef statements.
      But this results in adding new CONFIG_ARCH_OMAPXXX
      checks when SOCs are added in the future. So move them
      to a common place for OMAP2+ and make them 'weak' implementations.
      
      This way no new ifdefs would be required in the future and also
      cleans up the existing code.
      Signed-off-by: default avatarR Sricharan <r.sricharan@ti.com>
      [paul@pwsan.com: unsplit quoted strings; moved PRM functions to
       mach-omap2/prm_common.c; resolved sparse warnings]
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      3f4990f4
    • Tarun Kanti DebBarma's avatar
      ARM: OMAP2+: hwmod: add omap_hwmod_get_main_clk() API · bed9d1bb
      Tarun Kanti DebBarma authored
      Add an API to get main clock name associated with a given @oh.
      This will avoid the need to construct fclk names during early
      initialization in order to get fclk handle using clk_get().
      Signed-off-by: default avatarTarun Kanti DebBarma <tarun.kanti@ti.com>
      Cc: Benoit Cousson <b-cousson@ti.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Kevin Hilman <khilman@ti.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
      Acked-by: default avatarBenoit Cousson <b-cousson@ti.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      bed9d1bb
    • Vikram Pandita's avatar
      ARM: OMAP3+: dpll: optimize noncore dpll locking logic · 55ffe163
      Vikram Pandita authored
      If the dpll is already locked, code can be optimized
      to return much earlier than doing redundent set of lock mode
      and wait on idlest.
      
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Jon Hunter <jon-hunter@ti.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Mike Turquette <mturquette@ti.com>
      Signed-off-by: default avatarVikram Pandita <vikram.pandita@ti.com>
      Signed-off-by: default avatarNishanth Menon <nm@ti.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      55ffe163
    • Sakari Ailus's avatar
      ARM: OMAP3: control: add definition for CONTROL_CAMERA_PHY_CTRL · f0d3d821
      Sakari Ailus authored
      The register is used to configure the behaviour of the CSI-2 and CCP-2
      receivers. This register is available only in OMAP3630.
      
      The original patch was submitted by Vimarsh Zutshi.
      Signed-off-by: default avatarSakari Ailus <sakari.ailus@iki.fi>
      Cc: Vimarsh Zutshi <vimarsh.zutshi@gmail.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      f0d3d821
    • Jon Hunter's avatar
      ARM: OMAP2+: powerdomain code: Fix Wake-up power domain power status · d49cae92
      Jon Hunter authored
      The wake-up power domain is an alway-on power domain and so this power domain
      does not have a power state status (PM_PWSTST_xxx) register that indicates the
      current state. However, during the registering of the wake-up power domain the
      state of the domain is queried by calling pwrdm_read_pwrst(). This actually
      tries to read a register that does not exist and returns a value of 0 that
      indicates that the current state is OFF. The OFF state count of the wake-up
      power domain is then set to 1 and the current state to OFF. Both of which are
      incorrect.
      
      To fix this, if a power domain only supports the ON state, do not attempt to
      read the power state status register and simply return ON as the current power
      state.
      
      This is based upon Tony's current linux-omap master branch.
      
      Testing:
      - Boot tested on OMAP4460 panda.
      - Boot tested on OMAP3430 beagle and validated CORE RET still working (using
        Paul's 32k timer patch [1]).
      
      [1] http://marc.info/?l=linux-omap&m=134000053229888&w=2Signed-off-by: default avatarJon Hunter <jon-hunter@ti.com>
      Acked-by: default avatarKevin Hilman <khilman@ti.com>
      Acked-by: default avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
      [paul@pwsan.com: edited commit message slightly]
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      d49cae92
    • Jon Hunter's avatar
      ARM: OMAP4: clockdomain/CM code: Update supported transition modes · 65aa94b2
      Jon Hunter authored
      For OMAP3+ devices, the clock domains (CLKDMs) support one or more of the
      following transition modes ...
      
      NO_SLEEP (0x0) - A clock domain sleep transition is never initiated,
      		 irrespective of the hardware conditions.
      SW_SLEEP (0x1) - A software-forced sleep transition. The transition is initiated
      		 when the associated hardware conditions are satisfied
      SW_WKUP  (0x2) - A software-forced clock domain wake-up transition is initiated,
      		 irrespective of the hardware conditions.
      HW_AUTO  (0x3) - Hardware-controlled automatic sleep and wake-up transition is
      		 initiated by the PRCM module when the associated hardware
      		 conditions are satisfied.
      
      For OMAP4 devices, SW_SLEEP is equivalent to HW_AUTO and NO_SLEEP is equivalent
      to SW_WKUP. The only difference between HW_AUTO and SW_SLEEP for OMAP4 devices
      is that the PRM_IRQSTATUS_MPU.TRANSITION_ST interrupt status is set in case of
      SW_SLEEP transition, and not set in case of HW_AUTO transition.
      
      For OMAP4 devices, all CLKDMs support HW_AUTO and therefore we can place the
      CLKDMs in the HW_AUTO state instead of the SW_SLEEP mode. Hence, we do not
      need to use the SW_SLEEP mode. With regard to NO_SLEEP and SW_WKUP it is
      preferred to use SW_WKUP mode if the CLKDM supports it and so use this mode
      instead of NO_SLEEP where possible.
      
      For a software perspective the above 4 modes are represented by the following
      flags to indicate what modes are supported by each of the CLKDMs.
      
      CLKDM_CAN_DISABLE_AUTO	--> NO_SLEEP
      CLKDM_CAN_ENABLE_AUTO	--> HW_AUTO
      CLKDM_CAN_FORCE_SLEEP	--> SW_SLEEP
      CLKDM_CAN_FORCE_WAKEUP	--> SW_WKUP
      
      By eliminating the SW_SLEEP mode the the mapping of the flags for OMAP4 devices
      can becomes ...
      
      CLKDM_CAN_DISABLE_AUTO	--> NO_SLEEP
      CLKDM_CAN_ENABLE_AUTO	--> HW_AUTO
      CLKDM_CAN_FORCE_SLEEP	--> HW_AUTO
      CLKDM_CAN_FORCE_WAKEUP	--> SW_WKUP
      
      Cc: Ming Lei <ming.lei@canonical.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Benoit Cousson <b-cousson@ti.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Kevin Hilman <khilman@ti.com>
      Reviewed-by: default avatarBenoit Cousson <b-cousson@ti.com>
      Reviewed-by: default avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
      Signed-off-by: default avatarJon Hunter <jon-hunter@ti.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      65aa94b2
    • Vaibhav Hiremath's avatar
      ARM: OMAP3/4: omap_hwmod: Add rstst_offs field to struct omap_hwmod_omap4_prcm · 768c69f5
      Vaibhav Hiremath authored
      In case of AM33XX device, XXX_RSTST register offset is not
      consistent across PRM modules/instances,
      
      PRM_XXX            RSTST
      =========================
      PRM_PER_MOD:       0x04
      PRM_WKUP_MOD:      0x0C
      PRM_MPU_MOD:       NA
      PRM_DEVICE_MOD:    0x08
      
      This means, we need to pass on XXX_RSTST register offset
      information through omap_hwmod data, similar to XXX_RSTCTRL.
      
      Currently, this field is only applicable and used for AM33XX
      devices.
      Signed-off-by: default avatarVaibhav Hiremath <hvaibhav@ti.com>
      Cc: Benoit Cousson <b-cousson@ti.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Kevin Hilman <khilman@ti.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      768c69f5
    • Vaibhav Hiremath's avatar
      ARM: OMAP2+: hwmod: Add new sysc_type3 into omap_hwmod required for am33xx · 248b3b3d
      Vaibhav Hiremath authored
      In case of AM33xx family of devices (like cpsw) have different sysc
      bit field offsets defined,
      
      sysc_type3:
      |  3     2  |  1    0  |
      | STDBYMODE | IDLEMODE |
      
      So introduce new sysc_type3 in omap_hwmod common data.
      Signed-off-by: default avatarVaibhav Hiremath <hvaibhav@ti.com>
      Signed-off-by: default avatarVaibhav Bedia <vaibhav.bedia@ti.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      248b3b3d
    • Tony Lindgren's avatar
      Merge tags 'omap-cleanup-for-v3.6', 'omap-devel-dmtimer-for-v3.6' and... · 3f96a2d9
      Tony Lindgren authored
      Merge tags 'omap-cleanup-for-v3.6', 'omap-devel-dmtimer-for-v3.6' and 'omap-devel-am33xx-for-v3.6' into devel-am33xx-part2
      3f96a2d9
  4. 30 Jun, 2012 13 commits
  5. 29 Jun, 2012 7 commits