Skip to content

L
linux
Switch branch/tag
  1. 17 Sep, 2012 5 commits
  3. 13 Sep, 2012 24 commits
  5. 12 Sep, 2012 7 commits
  7. 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
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7