1. 17 Sep, 2012 5 commits
  2. 13 Sep, 2012 24 commits
  3. 12 Sep, 2012 7 commits
  4. 11 Sep, 2012 4 commits
    • Vaibhav Hiremath's avatar
      ARM: OMAP3+: hwmod: Add AM33XX HWMOD data · a2cfc509
      Vaibhav Hiremath authored
      This patch adds HWMOD data for all the peripherals of
      AM335X device and also hooks up to the existing OMAP framework.
      
      hwmod data has been already been cleaned up for the recent
      changes in clocktree, where all leaf nodes have been removed,
      since with modulemode based control, both clock and hwmod
      interface does same thing. This reduces the code size to large
      extent and also avoids duplication of same control.
      So instead of specifying module's leaf node as a main_clk,
      now we are relying on parent clock of module's functional clock.
      Signed-off-by: default avatarVaibhav Hiremath <hvaibhav@ti.com>
      Signed-off-by: default avatarAfzal Mohammed <afzal@ti.com>
      Signed-off-by: default avatarVaibhav Bedia <vaibhav.bedia@ti.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Benoit Cousson <b-cousson@ti.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Kevin Hilman <khilman@ti.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      [paul@pwsan.com: removed period in hwmod device names; changed mmc2 main_clk
       to mmc_clk at Vaibhav's request; added trailing commas to structure
       records at Tony's request to deal with some rmk parsing issues; added
       OMAP_INTC_START to facilitate sparse-IRQ conversion]
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      a2cfc509
    • Vaibhav Hiremath's avatar
      ARM: OMAP2+: hwmod: Hook-up am33xx support in omap_hwmod framework · 1688bf19
      Vaibhav Hiremath authored
      AM33XX PRCM architecture is different that any OMAP family
      of devices, so it is required to have separate implementation
      to handle AM33XX module enable/disable, reset assert/deassert
      functionality.
      This patch adds wrapper api's in omap_hwmod framework to
      access prm/cm for AM33XX family of devices.
      Signed-off-by: default avatarVaibhav Hiremath <hvaibhav@ti.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Kevin Hilman <khilman@ti.com>
      Cc: Tony Lindgren <tony@atomide.com>
      [paul@pwsan.com: fixed checkpatch messages]
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      1688bf19
    • Tony Lindgren's avatar
      serial/8250: Limit the omap workarounds to omap1 · cdd86b27
      Tony Lindgren authored
      These workarounds do not apply for CONFIG_ARCH_OMAP2PLUS at all,
      so let's make it just CONFIG_ARCH_OMAP1.
      
      This is needed to for ARM common zImage changes for
      omap2+ to avoid including plat and mach headers.
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      Acked-by: default avatarAlan Cox <alan@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cdd86b27
    • Stephen Warren's avatar
      ARM: tegra: cpu-tegra: explicitly manage re-parenting · ce32ddaa
      Stephen Warren authored
      When changing a PLL's rate, it must have no active children. The CPU
      clock cannot be stopped, and CPU clock's divider is not used. The old
      clock driver used to handle this by internally reparenting the CPU clock
      onto a different PLL when changing the CPU clock rate. However, the new
      common-clock based clock driver does not do this, and probably cannot do
      this due to the locking issues it would cause.
      
      To solve this, have the Tegra cpufreq driver explicitly perform the
      reparenting operations itself. This is probably reasonable anyway,
      since such reparenting is somewhat a matter of policy (e.g. which
      alternate clock source to use, whether to leave the CPU clock a child
      of the alternate clock source if it's running at the desired rate),
      and hence is something more appropriate for the cpufreq driver than
      the core clock driver anyway.
      
      Cc: Prashant Gaikwad <pgaikwad@nvidia.com>
      Cc: Peter De Schrijver <pdeschrijver@nvidia.com>
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      ce32ddaa