1. 29 1月, 2010 4 次提交
    • P
      OMAP3 clock: split out DPLL3 M2 divider functions into mach-omap2/clkt34xx_dpll3m2.c · 35e424e2
      Paul Walmsley 提交于
      Split the DPLL3 M2 divider clock functions out of clock34xx.c and move
      them into mach-omap2/clkt34xx_dpll3m2.c. This is intended to make the
      clock code easier to understand, since all of the functions needed to
      manage the OMAP3 DPLL3 M2 divider are now located in their own file,
      rather than being mixed with other, unrelated functions.
      
      Clock debugging is also now more finely-grained, since the DEBUG macro
      can now be defined for the DPLL3 M2 clock alone.  This should reduce
      unnecessary console noise when debugging DVFS.
      
      Also, if at some future point the mach-omap2/ directory is split
      into OMAP2/3/4 variants, this clkt file can be placed in the mach-omap34xx/
      directory, rather than shared with other chip types that don't use this
      clock type.
      
      This patch also lays the groundwork to skip compilation of this
      code on OMAP3 chips that don't support DVFS (e.g., AM35xx) via
      the Makefile, rather than via #ifdefs.
      
      Thanks to Alexander Shishkin <virtuoso@slind.org> for his comments to
      improve the patch description.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Jouni Högander <jouni.hogander@nokia.com>
      Cc: Alexander Shishkin <virtuoso@slind.org>
      35e424e2
    • P
      OMAP2xxx clock: move sys_clk code into mach-omap2/clkt2xxx_sys.c · 44da0a51
      Paul Walmsley 提交于
      Move the sys_clk clock functions from clock2xxx.c to
      mach-omap2/clkt2xxx_sys.c.  This is intended to make the clock code
      easier to understand, since all of the functions needed to manage the
      sys_clk are now located in their own file, rather than being mixed
      with other, unrelated functions.
      
      Clock debugging is also now more finely-grained, since the DEBUG
      macro can now be defined for the sys_clk clock alone.  This
      should reduce unnecessary console noise when debugging.
      
      Also, if at some future point the mach-omap2/ directory is split into
      OMAP2/3/4 variants, this clkt file can be placed in the mach-omap2xxx/
      directory, rather than shared with other chip types that don't use
      this clock type.
      
      Thanks to Alexander Shishkin <virtuoso@slind.org> for his comments to
      improve the patch description.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Alexander Shishkin <virtuoso@slind.org>
      44da0a51
    • P
      OMAP2xxx clock: move osc_clk code into mach-omap2/clkt2xxx_osc.c · 87a1b26c
      Paul Walmsley 提交于
      Move the osc_clk clock functions from clock2xxx.c to
      mach-omap2/clkt2xxx_osc.  This is intended to make the clock code
      easier to understand, since all of the functions needed to manage the
      osc_clk are now located in their own file, rather than being mixed
      with other, unrelated functions.
      
      Clock debugging is also now more finely-grained, since the DEBUG
      macro can now be defined for osc_clk clocks alone.  This
      should reduce unnecessary console noise when debugging.
      
      Also, if at some future point the mach-omap2/ directory is split
      into OMAP2/3/4 variants, this clkt file can be placed in the mach-omap2xxx/
      directory, rather than shared with other chip types that don't use this
      clock type.
      
      Thanks to Alexander Shishkin <virtuoso@slind.org> for his comments to
      improve the patch description.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Alexander Shishkin <virtuoso@slind.org>
      87a1b26c
    • P
      OMAP2xxx clock: move the APLL clock code into mach-omap2/clkt2xxx_apll.c · 49214640
      Paul Walmsley 提交于
      Move the APLL-related clock functions from clock2xxx.c to
      mach-omap2/clkt2xxx_apll.c.  This is intended to make the clock code
      easier to understand, since all of the functions needed to manage APLLs
      are now located in their own file, rather than being mixed with other,
      unrelated functions.
      
      Clock debugging is also now more finely-grained, since the DEBUG
      macro can now be defined for APLL clocks alone.  This
      should reduce unnecessary console noise when debugging.
      
      Also, if at some future point the mach-omap2/ directory is split
      into OMAP2/3/4 variants, this clkt file can be placed in the mach-omap2xxx/
      directory, rather than shared with other chip types that don't use this
      clock type.
      
      Thanks to Alexander Shishkin <virtuoso@slind.org> for his comments to
      improve the patch description.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Richard Woodruff <r-woodruff2@ti.com>
      Cc: Alexander Shishkin <virtuoso@slind.org>
      49214640
  2. 27 1月, 2010 7 次提交
    • P
      OMAP2xxx clock: move the DVFS virtual clock code into mach-omap2/clkt2xxx_virt_prcm_set.c · 734f69a7
      Paul Walmsley 提交于
      Move the DVFS virtual clock functions from clock2xxx.c to
      mach-omap2/clkt2xxx_virt_prcm_set.c.  This is intended to make the
      clock code easier to understand, since all of the functions needed to
      manage the virt_prcm_set clock are now located in their own file,
      rather than being mixed with other, unrelated functions.
      
      Clock debugging is also now more finely-grained, since the DEBUG macro
      can now be defined for the virt_prcm_set clock alone.  This should
      reduce unnecessary console noise when debugging.
      
      Also, if at some future point the mach-omap2/ directory is split into
      OMAP2/3/4 variants, this clkt file can be placed in the mach-omap2xxx/
      directory, rather than shared with other chip types that don't use
      this clock type.
      
      Thanks to Alexander Shishkin <virtuoso@slind.org> for his comments.
      Thanks also to Kevin Hilman <khilman@deeprootsystems.com> for finding
      and fixing a bug with the CONFIG_CPU_FREQ portion of this patch.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Richard Woodruff <r-woodruff2@ti.com>
      Cc: Alexander Shishkin <virtuoso@slind.org>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      734f69a7
    • P
      OMAP2xxx clock: move the DPLL+CORE composite clock code into mach-omap2/clkt2xxx_dpllcore.c · b1823d86
      Paul Walmsley 提交于
      Move the DPLL+CORE composite clock functions from clock2xxx.c to
      mach-omap2/clkt2xxx_dpllcore.c.  This is intended to make the clock
      code easier to understand, since all of the functions needed to manage
      the OMAP2 DPLL+CORE clock are now located in their own file, rather
      than being mixed with other, unrelated functions.
      
      Clock debugging is also now more finely-grained, since the DEBUG
      macro can now be defined for the DPLL+CORE clock alone.  This
      should reduce unnecessary console noise when debugging.
      
      Also, if at some future point the mach-omap2/ directory is split
      into OMAP2/3/4 variants, this clkt file can be placed in the mach-omap2xxx/
      directory, rather than shared with other chip types that don't use this
      clock type.
      
      Thanks to Alexander Shishkin <virtuoso@slind.org> for his comments to
      improve the patch description.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Richard Woodruff <r-woodruff2@ti.com>
      Cc: Alexander Shishkin <virtuoso@slind.org>
      b1823d86
    • P
      OMAP2/3/4 clock: move clksel clock functions into mach-omap2/clkt_clksel.c · df791b3e
      Paul Walmsley 提交于
      Move all clksel-related clock functions from mach-omap2/clock.c to
      mach-omap2/clkt_clksel.c.  This is intended to make the clock code
      easier to understand, since all of the functions needed to manage
      clksel clocks are now located in their own file, rather than being
      mixed with other, unrelated functions.
      
      Clock debugging is also now more finely-grained, since the DEBUG macro
      can now be defined for clksel clocks alon.  This should reduce
      unnecessary console noise when debugging.
      
      Also, if at some future point the mach-omap2/ directory is split
      into OMAP2/3/4 variants, this clkt file can be moved to the plat-omap/
      directory to be shared.
      
      Thanks to Alexander Shishkin <virtuoso@slind.org> for his comments to
      improve the patch description.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Alexander Shishkin <virtuoso@slind.org>
      df791b3e
    • P
      OMAP2/3/4 clock: move DPLL clock functions into mach-omap2/clkt_dpll.c · 0b96af68
      Paul Walmsley 提交于
      Move all DPLL-related clock functions from mach-omap2/clock.c to
      mach-omap2/clkt_dpll.c.  This is intended to make the clock code
      easier to understand, since all of the functions needed to manage
      DPLLs are now located in their own file, rather than being mixed with
      other, unrelated functions.
      
      Clock debugging is also now more finely-grained, since the DEBUG macro
      can now be defined for DPLLs alone.  This should reduce unnecessary
      console noise when debugging.
      
      Also, if at some future point the mach-omap2/ directory is split
      into OMAP2/3/4 variants, this clkt file can be moved to the plat-omap/
      directory to be shared.
      
      Thanks to Alexander Shishkin <virtuoso@slind.org> for his comments to
      improve the patch description.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Alexander Shishkin <virtuoso@slind.org>
      0b96af68
    • P
      OMAP3 clock: move OMAP3-specific DPLL functions to dpll3xxx.c · 98c45457
      Paul Walmsley 提交于
      Mark the OMAP3-specific DPLL functions as being OMAP3-specific by moving
      them from mach-omap2/dpll.c to mach-omap2/dpll3xxx.c.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      98c45457
    • A
      ARM: OMAP4: PM: Refine the APIs to support OMAP4 features. · 8a3ddc75
      Abhijit Pagare 提交于
      Port the APIs to support the OMAP4 clockdomain framework.
      Also take care of the compiling requirements for the same.
      Signed-off-by: NAbhijit Pagare <abhijitpagare@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoit Cousson <b-cousson@ti.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      8a3ddc75
    • A
      ARM: OMAP4: PM: Refine the APIs to support OMAP4 features. · 3a759f09
      Abhijit Pagare 提交于
      The proper Macros have to be used for platform specific calls and
      some of the compiling requirements and init calls are taken care of.
      Signed-off-by: NAbhijit Pagare <abhijitpagare@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoit Cousson <b-cousson@ti.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      3a759f09
  3. 12 12月, 2009 9 次提交
  4. 02 12月, 2009 1 次提交
  5. 26 11月, 2009 4 次提交
  6. 23 11月, 2009 5 次提交
  7. 12 11月, 2009 1 次提交
  8. 04 9月, 2009 2 次提交
    • P
      OMAP2/3/4: create omap_hwmod layer · 63c85238
      Paul Walmsley 提交于
      OMAP SoCs can be considered a collection of hardware IP blocks
      connected by various interconnects.  The bus topology and device
      integration data is somewhat more complex than platform_device can
      encode.  This patch creates code and structures to manage information
      about OMAP on-chip devices ("hardware modules") and their integration
      to the rest of the chip.  Hardware module data is intended to be
      generated dynamically from the TI hardware database for the OMAP4
      chips and beyond, easing Linux support for new chip variants.
      
      This code currently:
      
      - resets and configures all hardware modules upon startup, reducing bootloader
        dependencies;
      
      - provides hooks for Linux driver model code to enable, idle, and shutdown
        hardware modules (forthcoming patch);
      
      - waits for hardware modules to leave idle once their clocks
        are enabled and OCP_SYSCONFIG bits are set appropriately.
      
      - provides a means to pass arbitrary IP block configuration data (e.g.,
        FIFO size) to the device driver (via the dev_attr void pointer)
      
      In the future this code is intended to:
      
      - estimate interconnect bandwidth and latency characteristics to
        ensure constraints are satisfied during DVFS
      
      - provide *GRPSEL bit data to the powerdomain code
      
      - handle pin/ball muxing for devices
      
      - generate IO mapping information dynamically
      
      - supply device firewall configuration data
      
      - provide hardware module data to other on-chip coprocessor software
      
      - allow the removal of the "disable unused clocks" code in the OMAP2/3
        clock code
      
      This patch represents a collaborative effort involving many people from TI,
      Nokia, and the Linux-OMAP community.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoit Cousson <b-cousson@ti.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      Cc: Vikram Pandita <vikram.pandita@ti.com>
      Cc: Sakari Poussa <sakari.poussa@nokia.com>
      Cc: Anand Sawant <sawant@ti.com>
      Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
      Cc: Eric Thomas <ethomas@ti.com>
      Cc: Richard Woodruff <r-woodruff2@ti.com>
      63c85238
    • P
      OMAP2/3/4 PRCM: add module IDLEST wait code · 71348bca
      Paul Walmsley 提交于
      After a hardware module's clocks are enabled, Linux must wait for it
      to indicate readiness via its IDLEST bit before attempting to access
      the device, otherwise register accesses to the device may trigger an
      abort.  This has traditionally been implemented in the clock
      framework, but this is the wrong place for it: the clock framework
      doesn't know which module clocks must be enabled for a module to leave
      idle; and if a module is not in smart-idle mode, it may never leave
      idle at all.  This type of information is best stored in a
      per-hardware module data structure (coming in a following patch),
      rather than a per-clock data structure.  The new code will use these new
      functions to handle waiting for modules to enable.
      
      Once hardware module data is filled in for all of the on-chip devices,
      the clock framework code to handle IDLEST waiting can be removed.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      71348bca
  9. 29 8月, 2009 2 次提交
  10. 09 6月, 2009 1 次提交
  11. 29 5月, 2009 4 次提交