1. 25 2月, 2010 28 次提交
    • P
      OMAP2 clock: split OMAP2420, OMAP2430 clock data into their own files · 81b34fbe
      Paul Walmsley 提交于
      In preparation for multi-OMAP2 kernels, split
      mach-omap2/clock2xxx_data.c into mach-omap2/clock2420_data.c and
      mach-omap2/clock2430_data.c.  2430 uses a different device space
      physical memory layout than past or future OMAPs, and we use a
      different virtual memory layout as well, which causes trouble for
      architecture-level code/data that tries to support both.  We tried
      using offsets from the virtual base last year, but those patches never
      made it upstream; so after some discussion with Tony about the best
      all-around approach, we'll just grit our teeth and duplicate the
      structures.  The maintenance advantages of a single kernel config that
      can compile and boot on OMAP2, 3, and 4 platforms are simply too
      compelling.
      
      This approach does have some nice benefits beyond multi-OMAP 2 kernel
      support.  The runtime size of OMAP2420-specific and OMAP2430-specific
      kernels is smaller, since unused clocks for the other OMAP2 chip will
      no longer be compiled in.  (At some point we will mark the clock data
      __initdata and allocate it during registration, which will eliminate
      the runtime memory advantage.)  It also makes the clock trees slightly
      easier to read, since 2420-specific and 2430-specific clocks are no
      longer mixed together.
      
      This patch also splits 2430-specific clock code into its own file,
      mach-omap2/clock2430.c, which is only compiled in for 2430 builds -
      mostly for organizational clarity.
      
      While here, fix a bug in the OMAP2430 clock tree: "emul_ck" was
      incorrectly marked as being 2420-only, when actually it is present on
      both OMAP2420 and OMAP2430.
      
      Thanks to Tony for some good discussions about how to approach this
      problem.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Richard Woodruff <r-woodruff2@ti.com>
      81b34fbe
    • P
      OMAP3/4 clock: split into per-chip family files · 657ebfad
      Paul Walmsley 提交于
      clock34xx_data.c now contains data for the OMAP34xx family, the
      OMAP36xx family, and the OMAP3517 family, so rename it to
      clock3xxx_data.c.  Rename clock34xx.c to clock3xxx.c, and move the
      chip family-specific clock functions to clock34xx.c, clock36xx.c, or
      clock3517.c, as appropriate.  So now "clock3xxx.*" refers to the OMAP3
      superset.
      
      The main goal here is to prepare to compile chip family-specific clock
      functions only for kernel builds that target that chip family.  To get to
      that point, we also need to add CONFIG_SOC_* options for those other
      chip families; that will be done in future patches, planned for 2.6.35.
      
      OMAP4 is also affected by this.  It duplicated the OMAP3 non-CORE DPLL
      clkops structure.  The OMAP4 variant of this clkops structure has been
      removed, and since there was nothing else currently in clock44xx.c, it
      too has been removed -- it can always be added back later when there
      is some content for it.  (The OMAP4 clock autogeneration scripts have been
      updated accordingly.)
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      Cc: Ranjith Lohithakshan <ranjithl@ti.com>
      Cc: Tony Lindgren <tony@atomide.com>
      657ebfad
    • P
      OMAP clock: drop .id field; ensure each clock has a unique name · b92c170d
      Paul Walmsley 提交于
      After the clkdev conversion, the struct clk.id field became
      superfluous, so, drop it.  Bring the clock names closer to the TRMs
      and ensure they are unique for debugfs.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      b92c170d
    • P
      OMAP clock: compress clock flags down to a u8 · f71eddb1
      Paul Walmsley 提交于
      There are now only eight OMAP clock flags, so renumber the flags to
      fit in a u8 and shrink the size of struct clk.flags from a u32 to a
      u8.  The intention is to save memory.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      f71eddb1
    • P
      OMAP2 clock: drop CONFIG_PARTICIPANT clock flag · 1a337717
      Paul Walmsley 提交于
      It turns out that the only purpose of the CONFIG_PARTICIPANT clock
      flag is to prevent omap2_clk_set_rate() and omap2_clk_set_parent()
      from being executed on clocks with that flag set.  The rate-changing
      component can be more directly accomplished by dropping the .set_rate
      and .round_rate function pointers from those CONFIG_PARTICIPANT struct
      clks.  As far as the parent-changing component is concerned, it turns
      out that none of the CONFIG_PARTICIPANT clocks have multiple parent
      choices, so all that is necessary is for omap2_clk_set_parent() to
      bail out early if the new parent is equal to the old parent.
      Implement this change and get rid of the flag, which has always had a
      confusing name (it appears to be a Kconfig option, falsely).
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Richard Woodruff <r-woodruff2@ti.com>
      1a337717
    • P
      OMAP2xxx clock: drop DELAYED_APP flag from non-clksel clocks · 17d09273
      Paul Walmsley 提交于
      The DELAYED_APP flag is effective only with clksel clocks, so drop it from
      clocks that are not rate-changeable or that use non-clksel rate changing code
      (e.g., virt_prcm_set).
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Richard Woodruff <r-woodruff2@ti.com>
      17d09273
    • P
      OMAP2xxx clock: GFX functional clock rates are not independently changeable · 94297784
      Paul Walmsley 提交于
      According to the OMAP242x TRM Rev X Figure 5-15 "Clock Output Control
      - Functional Clocks 2", the GFX functional clocks should be marked
      both DELAYED_APP and CONFIG_PARTICIPANT, meaning that their rates must
      be reprogrammed as part of a larger OPP set change.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Richard Woodruff <r-woodruff2@ti.com>
      94297784
    • P
      OMAP4 clock: drop the CLOCK_IN_OMAP4430 clock flag · c78a05e8
      Paul Walmsley 提交于
      The CLOCK_IN_OMAP4430 clock flag is not currently needed in the OMAP4
      ES1 clock tree, and platform discrimination via clock flags is
      deprecated in favor of the clkdev mechanism, so, drop it.  (The OMAP4
      clock tree autogeneration script has been updated accordingly.)
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      c78a05e8
    • P
      OMAP2/3/4 clock: fix DPLL multiplier value errors; also copyrights, includes, documentation · 93340a22
      Paul Walmsley 提交于
      The maximum DPLL multiplier (M) values for OMAP2xxx and OMAP3xxx are
      one increment higher than they should be.  See for example the
      OMAP242x TRM Rev X Section 5.10.6 "Clock Generator Registers" and the
      OMAP36xx TRM Rev C Table 3-202 "CM_CLKSEL1_PLL".  Programming a 0 into
      the DPLL's M register bitfield is valid for OMAP2/3 and indicates that
      the DPLL should enter MN-bypass mode.  Also, increase the minimum
      multiplier (M) value for the DPLL rate rounding code from 1 to 2, to
      ensure that it does not inadvertently put the DPLL into bypass.
      
      Note that the register documentation in the OMAP2xxx and OMAP3xxx TRMs
      does not make clear that the actual DPLL divider value (the "N") is
      the content of the appropriate register bitfield for the N value,
      _plus one_.  (In other words, an N register bitfield of 0 indicates a
      DPLL divider value of 1.)  This is only clearly documented in the
      OMAP4430 TRM, in, for example, OMAP4430 TRM Rev A Table 3-1167
      "CM_CLKSEL_DPLL_USB".
      
      While here, update copyrights, add kerneldoc for struct dpll_data,
      drop the unused struct dpll_data.max_tolerance field, remove some
      unnecessary #includes in DPLL-related code, and replace the #include
      of <linux/module.h> with <linux/list.h>, which is what was really
      needed.  The OMAP4 clock autogenerator script has been updated
      accordingly.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      93340a22
    • V
      OMAP3 clock: add support for 192Mhz DPLL4M2 output · 7356f0b2
      Vishwanath BS 提交于
      In 3630, DPLL4M2 output can be 96MHz or 192MHz (for SGX to run at
      192). This patch has changes to support this feature. 96MHz clock is
      generated by dividing 192Mhz clock by 2 using CM_CLKSEL_CORE register.
      SGX can select Core Clock, 192MHz clock or CM_96M_FCLK as it's
      functional clock. In summary changes done are:
      1. Added a feature called omap3_has_192mhz_clk and enabled for 3630
      2. Added a new clock node called omap_192m_alwon_ck
      3. Made omap_96m_alwon_fck to derive its clock from omap_192m_alwon_ck
      Signed-off-by: NVishwanath BS <Vishwanath.bs@ti.com>
      [paul@pwsan.com: fixed whitespace]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      7356f0b2
    • V
      OMAP3 clock: Introduce 3630 DPLL4 HSDivider changes · 678bc9a2
      Vishwanath BS 提交于
      Divider (M2, M3, M4, M5 and M6) field width has been increased by 1 bit
      in 3630. This patch has changes to accommodate this in CM dynamically
      based on chip version.
      Basically new clock nodes have been added for 3630 DPLL4 M2,M3,M4,M5 and
      M6 and value of these nodes are used if cpu type is 3630.
      Signed-off-by: NVishwanath BS <vishwanath.bs@ti.com>
      [paul@pwsan.com: updated to apply on 2.6.34 queue; comments added]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      678bc9a2
    • R
      OMAP3 clock: introduce DPLL4 Jtype · 358965d7
      Richard Woodruff 提交于
      DPLL4 for 3630 introduces a changed block called j type dpll, requiring
      special divisor bits and additional reg fields. To allow for silicons to
      use this, this is introduced as a flag and is enabled for 3630 silicon.
      OMAP4 also has j type dpll for usb.
      
      Tested with 3630 ZOOM3 and OMAP3430 ZOOM2
      Signed-off-by: NRichard Woodruff <r-woodruff2@ti.com>
      Signed-off-by: NNishanth Menon <nm@ti.com>
      Signed-off-by: NVishwanath BS <Vishwanath.bs@ti.com>
      [paul@pwsan.com: added some comments; updated copyrights and credits; fixed
       some style issues]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      358965d7
    • A
      ARM: OMAP4 clock domain: Add check for avoiding dependency related update. · 91808a81
      Abhijit Pagare 提交于
      A check is added for avoiding the sleep/wakeup dependency updates
      for OMAP4 as the structures for the dependencies are currently absent.
      Signed-off-by: NAbhijit Pagare <abhijitpagare@ti.com>
      [paul@pwsan.com: added warnings, explanatory comment, copyright update]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      91808a81
    • M
      OMAP3630: Clock: Workaround for DPLL HS divider limitation · a7e069fc
      Mike Turquette 提交于
      This patch implements a workaround for the DPLL HS divider limitation
      in OMAP3630 as given by Errata ID: i556.
      
      Errata:
      When PWRDN bit is set, it resets the internal HSDIVIDER divide-by value (Mx).
      The reset value gets loaded instead of the previous value.
      The following HSDIVIDERs exhibit above behavior:
      . DPLL4 : M6 / M5 / M4 / M3 / M2 (CM_CLKEN_PLL[31:26] register bits)
      . DPLL3 : M3 (CM_CLKEN_PLL[12] register bit).
      
      Work Around:
      It is mandatory to apply the following sequence to ensure the write
      value will
      be loaded in DPLL HSDIVIDER FSM:
      The global sequence when using PWRDN bit is the following:
      . Disable Mx HSDIVIDER clock output related functional clock enable bits
              (in CM_FCLKEN_xxx / CM_ICLKEN_xxx)
      . Enable PWRDN bit of HSDIVIDER
      . Disable PWRDN bit of HSDIVIDER
      . Read current HSDIVIDER register value
      . Write different value in HSDIVIDER register
      . Write expected value in HSDIVIDER register
      . Enable Mx HSDIVIDER clock output related functional clocks
              (CM_FCLKEN_xxx / CM_ICLKEN_xxx)
      Signed-off-by: NMike Turquette <mturquette@ti.com>
      Signed-off-by: NVishwanath BS <vishwanath.bs@ti.com>
      Signed-off-by: NVijaykumar GN <vijaykumar.gn@ti.com>
      [paul@pwsan.com: updated patch to apply; made workaround function static;
       marked as being 36xx-specific]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      a7e069fc
    • T
      OMAP: HWMOD: Add support for early device register into omap device layer · c23a97d3
      Thara Gopinath 提交于
      This patch adds support in omap device layer to register devices
      as early platform devices. Certain devices needed during system boot up
      like timers, gpio etc can be registered as early devices. This will
      allow for them to be probed very early on during system boot up.
      This patch adds a parameter is_early_device in omap_device_build.
      Depending on this parameter a call to early_platform_add_devices
      or platform_register_device is made.
      Signed-off-by: NThara Gopinath <thara@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      c23a97d3
    • T
      OMAP3: hwmod: support to specify the offset position of various SYSCONFIG register bits. · 358f0e63
      Thara Gopinath 提交于
      In OMAP3 Some modules like Smartreflex do not have the regular sysconfig
      register.Instead clockactivity bits are part of another register at a
      different bit position than the usual bit positions 8 and 9.
      
      In OMAP4, a new scheme is available  due to the new protocol
      between the PRCM and the IPs. Depending of the scheme, the SYSCONFIG
      bitfields position will be different.
      The IP_REVISION register should be at offset 0x00.
      It should contain a SCHEME field. From this we can determine whether
      the IP follows legacy scheme or the new scheme.
      
      31:30 SCHEME  Used to distinguish between old scheme and current.
       Read 0x0:  Legacy protocol.
       Read 0x1:  New PRCM protocol defined for new OMAP4 IPs
      
      For legacy IP
       13:12 MIDLEMODE
       11:8  CLOCKACTIVITY
       6     EMUSOFT
       5     EMUFREE
       4:3   SIDLEMODE
       2     ENAWAKEUP
       1     SOFTRESET
       0     AUTOIDLE
      
      For new OMAP4 IP's, the bit position in SYSCONFIG is (for simple target):
       5:4   STANDBYMODE (Ex MIDLEMODE)
       3:2   IDLEMODE (Ex SIDLEMODE)
       1     FREEEMU (Ex EMUFREE)
       0     SOFTRESET
      
      Unfortunately In OMAP4 also some IPs will not follow any of these
      two schemes. This is the case at least for McASP, SmartReflex
      and some security IPs.
      
      This patch introduces a new field sysc_fields in omap_hwmod_sysconfig which
      can be used by the hwmod structures to specify the offsets for the
      sysconfig register of the IP.Also two static structures
      omap_hwmod_sysc_type1 and omap_hwmod_sysc_type2 are defined
      which can be used directly to populate the sysc_fields if the IP follows
      legacy or new OMAP4 scheme. If the IP follows none of these two schemes
      a new omap_hwmod_sysc_fields structure has to be defined and
      passed as part of omap_hwmod_sysconfig.
      Signed-off-by: NThara Gopinath <thara@ti.com>
      Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      358f0e63
    • V
      OMAP3 clock: Remove FreqSel for 3630 · 5eb75f55
      Vishwanath BS 提交于
      DPLL_FREQSEL field in CLKEN_PLL register is no longer valid for
      OMAP3630. So remove references to that.
      Signed-off-by: NVishwanath BS <vishwanath.bs@ti.com>
      Cc: Sergei Shtylyov <sshtylyov@mvista.com>
      [paul@pwsan.com: added comment fix from Sergei Shtylyov]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      5eb75f55
    • K
      OMAP2/3: PRCM: fix misc. compiler warnings · 0cc9314e
      Kevin Hilman 提交于
      - missing return in omap_prcm_get_reset_sources()
      - potential use of uninitialized variable in omap_prcm_arch_reset()
      Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      0cc9314e
    • S
      OMAP3 clock: Check return values for clk_get() · a51ba284
      Sanjeev Premi 提交于
      This patch checks if clk_get() returned success for
      the clocks used in function omap2_clk_arch_init().
      
      This version incorporates review comments from
      Kevin Hilman and Paul Walmsley.
      Signed-off-by: NSanjeev Premi <premi@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      a51ba284
    • R
      AM35xx: Add clock support for new modules on AM35xx · 3cc4a2fc
      Ranjith Lohithakshan 提交于
      This patch adds clock support for the following AM35xx modules
      	- Ethernet MAC
      	- CAN Controller (HECC)
      	- New MUSB OTG Controller with integrated Phy
      	- Video Processing Front End (VPFE)
      	- Additional UART (UART4)
      Signed-off-by: NRanjith Lohithakshan <ranjithl@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      3cc4a2fc
    • R
      OMAP2/3 clock: Extend find_idlest() to pass back idle state value · 419cc97d
      Ranjith Lohithakshan 提交于
      Current implementation defines clock idle state indicators based on the
      cpu information (cpu_is_omap24xx() or cpu_is_omap34xx()) in a system wide
      manner. This patch extends the find_idlest() function in clkops to pass
      back the idle state indicator for that clock, thus allowing idle state
      indicators to be defined on a per clock basis if required.
      
      This is specifically needed on AM35xx devices as the new IPSS clocks
      indicates the idle status (0 is idle, 1 is ready) in a way just
      opposite to how its handled in OMAP3 (0 is ready, 1 is idle).
      Signed-off-by: NRanjith Lohithakshan <ranjithl@ti.com>
      [paul@pwsan.com: updated to apply after commit 98c45457 et seq.]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      419cc97d
    • T
      OMAP3 PM: Adding counters for power domain logic off and mem off during retention. · cde08f81
      Thara Gopinath 提交于
      This patch adds counters to keep track of whether the powerdomain
      logic or software controllable memory banks are turned off when
      the power domain enters retention. During power domain retention
      if logic gets turned off, the scenario is known as Open Switch Retention.
      Also during retention s/w controllable memory banks of a power
      domain can be chosen to be kept in retention or off.
      
      This patch adds one counter per powerdomain to track the power domain
      logic state during retention. Number of memory bank state counters
      added depends on the number of software controllable memory banks
      of the powerdomain. To view these counters do
      	cat ../debug/pm_debug/count
      Signed-off-by: NThara Gopinath <thara@ti.com>
      [paul@pwsan.com: conditional expressions simplified; counter increment
       code moved to its own function]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      cde08f81
    • T
      OMAP3 PM: Defining .pwrsts_logic_ret field for core power domain structure · 4133a44e
      Thara Gopinath 提交于
      This patch adds the flag .pwrsts_logic_ret info for the core power domain
      in the associated powerdomain structure. This flag specifies the states
      core domain logic can hit in event of the domain entering retention.
      Signed-off-by: NThara Gopinath <thara@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      4133a44e
    • T
      OMAP2/3 PM: Adding powerdomain APIs for reading the next logic and mem state · 1e3d0d2b
      Thara Gopinath 提交于
      This patch adds APIs pwrdm_read_logic_retst and
      pwrdm_read_mem_retst for reading the next programmed
      logic and memory state a powerdomain is to hit in event
      of the next power domain state being retention.
      These are needed for OSWR support.
      Signed-off-by: NThara Gopinath <thara@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      1e3d0d2b
    • T
      OMAP3: Clock: Added IDLEST definitions for SGX · b024b542
      Tero Kristo 提交于
      Added definitions for OMAP3430ES2_ST_SGX_SHIFT and OMAP3430ES2_ST_SGX_MASK
      as these were missing.
      Signed-off-by: NTero Kristo <tero.kristo@nokia.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      b024b542
    • K
      OMAP3: clock: use std _MASK suffix for CM_FCLKEN_IVA2 defines · dfa6d6f8
      Kevin Hilman 提交于
      Add _MASK suffix to CM_FCLKEN_IVA2 bitfieds to conform with the rest
      of the usage in cm-regbits-34xx.h of using _SHIFT and _MASK suffixes.
      Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      dfa6d6f8
    • K
      OMAP: omap_device: when 'called from invalid state', print state · 24d82e34
      Kevin Hilman 提交于
      The omap_device_[enable|idle|shutdown] functions print a warning
      when called from an invalid state.  Print the invalid state in
      the warning messages.  This also uses __func__ to get the function
      name.
      
      Also, move the entire print string onto a single line to facilitate
      grepping or error messages.  Recent discussions on LKML show
      strong preference for grep-able code vs. strict 80 column limit.
      Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      24d82e34
    • K
      OMAP: omap_device: add omap_device_is_valid() · 0007122a
      Kevin Hilman 提交于
      The omap_device struct contains a 'struct platform_device'.  Normally,
      converting a platform_device pointer to an omap_device pointer
      consists of simply doing a container_of(), as is done currently by the
      to_omap_device() macro.
      
      However, if this is attempted when using platform_device that has not
      been created as part of the omap_device creation, the container_of()
      will point to a memory location before the platform_device pointer
      which will contain random data.
      
      Therefore, we need a way to detect valid omap_device pointers.  This
      patch solves this by using the simple magic number approach.
      Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      0007122a
  2. 18 2月, 2010 2 次提交
    • T
      80c20d54
    • R
      omap: Remove DEBUG_FS dependency for mux name checking · b72c7d54
      Ranjith Lohithakshan 提交于
      The check for a valid mux name should be performed regardless of whether
      DEBUG_FS is enabled or not. Otherwise without DEBUG_FS, we get:
      
      Unable to handle kernel NULL pointer dereference at virtual address 00000000
      pgd = c0004000
      [00000000] *pgd=00000000
      Internal error: Oops: 5 [#1]
      last sysfs file:
      Modules linked in:
      CPU: 0    Not tainted  (2.6.33-rc8 #10)
      PC is at strcmp+0x18/0x40
      LR is at omap_mux_init_signal+0x68/0x14c
      ...
      
      This fixes the issue currently seen with boards not booting up
      if DEBUG_FS is not enabled in defconfig.
      
      Note that the earlier ifndef + ifdef now becomes simpler ifdef else:
      If CONFIG_OMAP_MUX is selected, we use pin names. If it's not selected,
      we only want the GPIO to mux register mapping.
      Signed-off-by: NRanjith Lohithakshan <ranjithl@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      b72c7d54
  3. 16 2月, 2010 10 次提交