“5f25e3fd065f7e7cfde608fc3bfa399160afaaf6”上不存在“projects/R00kieman/imports.yml”
  1. 24 9月, 2012 35 次提交
    • J
      ARM: OMAP4460/4470: PMU: Enable PMU for OMAP4460/70 · 76a5d9bf
      Jon Hunter 提交于
      OMAP4460 and OMAP4470 devices have dedicated PMU interrupts and so add these
      interrupts to the MPU HWMOD so we can use these for PMU events on these
      devices. The PMU interrupts need to be the first interrupts in the array of
      interrupts as the ARM PMU driver assumes this.
      
      By using these dedicated interrupts we only need to enable the MPU and DEBUG
      sub-systems for PMU to work. This is different to OMAP4430 that did not have
      dedicated interrupts and required other power domains in addition to the DEBUG
      sub-system to be enabled so we could route the PMU events to the CTI interrupts.
      Hence, OMAP4460 and OMAP4470 devices can use the same list of HWMODs to create
      the PMU device that is using by OMAP3.
      
      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>
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      [paul@pwsan.com: updated to apply]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      76a5d9bf
    • J
      ARM: OMAP2+: PMU: Add runtime PM support · 6a9bce27
      Jon Hunter 提交于
      The original implementation of this patch was done by Ming Lei for PMU on OMAP4
      [1]. Since then the PM runtime calls have been moved into the ARM PMU code and
      this greatly simplifies the changes.
      
      The another differnce since the original version, is that it is no longer
      necessary to call pm_runtime_get/put during the PMU initialisation was we are no
      longer accessing the hardware at this stage.
      
      By adding runtime PM support, we can ensure that the appropriate power and clock
      domains are kept on while PMU is being used.
      
      [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074153.html
      
      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>
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      6a9bce27
    • M
      ARM: OMAP4430: PMU: prepare to create PMU device via HWMOD · efc7f49c
      Ming Lei 提交于
      For OMAP4430 PMU events are routed to the CPU via the cross trigger interface
      (CTI) because there are no dedicated interrupts. In order to route the PMU
      events via the CTI IRQs, the following modules must be enabled:
      
              l3_instr, l3_main_3, debugss
      
      Therefore, build the arm-pmu device via these three HWMODs.
      
      However, the CTI support for this platform still needs some work.  Until
      that's finished, temporarily disable the PMU on OMAP4430.
      
      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>
      Signed-off-by: NMing Lei <ming.lei@canonical.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      [paul@pwsan.com: temporarily disabled OMAP4430 PMU support until a
       better CTI interface can be implemented; added patch description note]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      efc7f49c
    • J
      ARM: OMAP2+: PMU: Convert OMAP2/3 devices to use HWMOD · ee75d95c
      Jon Hunter 提交于
      Convert OMAP2/3 devices to use HWMOD for creating a PMU device. To support PMU
      on OMAP2 devices we only need to use MPU sub-system and so we can simply use
      the MPU HWMOD to create the PMU device. To support PMU on OMAP3 devices, we need
      to use the MPU and DEBUG sub-systems and so use these HWMODs to create the PMU
      device for OMAP3.
      
      The MPU HWMOD for OMAP2/3 devices is currently missing the PMU interrupt and so
      add the PMU interrupt to the MPU HWMOD for these devices.
      
      This change also moves the PMU code out of the mach-omap2/devices.c files into
      its own pmu.c file as suggested by Kevin Hilman to de-clutter devices.c.
      
      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>
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      [paul@pwsan.com: fixed checkpatch messages; updated to apply; dropped old-style
       initial filename line in header comments]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      ee75d95c
    • J
      ARM: OMAP3: hwmod data: Add debugss HWMOD data · c7dad45f
      Jon Hunter 提交于
      To enable PMU with runtime PM support on OMAP3 devices we need to be able to
      dynamically enable and disable the debug sub-system at runtime. By adding HWMOD
      data for the debug sub-system for OMAP3, we can build the PMU device using the
      debug sub-system HWMOD and control this power domain using runtime PM.
      Reviewed-by: NBenoit Cousson <b-cousson@ti.com>
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      [paul@pwsan.com: updated to apply; added L4-EMU address space]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      c7dad45f
    • P
      ARM: OMAP2+: clockdomain/hwmod: add workaround for EMU clockdomain idle problems · b71c7217
      Paul Walmsley 提交于
      The idle status of the IP blocks and clocks inside the EMU clockdomain
      isn't taken into account by the PRCM hardware when deciding whether
      the clockdomain is idle.  Add a workaround flag in the clockdomain
      code, CLKDM_MISSING_IDLE_REPORTING, to deal with this problem, and add
      the code necessary to support it.
      
      If CLKDM_MISSING_IDLE_REPORTING is set on a clockdomain, the
      clockdomain will be forced active whenever an IP block inside that
      clockdomain is in use, even if the clockdomain supports
      hardware-supervised idle.  When the kernel indicates that the last
      active IP block inside the clockdomain is no longer used, the
      clockdomain will be forced idle, or, if that mode is not supported in
      the hardware, it will be placed into hardware-supervised idle.
      
      This patch is an equal collaboration with Jon Hunter
      <jon-hunter@ti.com>.  Ming Lei <ming.lei@canonical.com>, Will Deacon
      <will.deacon@arm.com>, Madhav Vij <mvij@ti.com>, Kevin Hilman
      <khilman@ti.com>, Benoît Cousson <b-cousson@ti.com>, and Santosh
      Shilimkar <santosh.shilimkar@ti.com> all made essential contributions
      to the understanding of EMU clockdomain power management on OMAP.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Jon Hunter <jon-hunter@ti.com>
      Cc: Ming Lei <ming.lei@canonical.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Madhav Vij <mvij@ti.com>
      Cc: Kevin Hilman <khilman@ti.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
      Tested-by: NJon Hunter <jon-hunter@ti.com>
      b71c7217
    • J
      ARM: OMAP: Add a timer attribute for timers that can interrupt the DSP · 5c3e4ec4
      Jon Hunter 提交于
      Some instances of the DMTIMER peripheral on OMAP devices have the ability
      to interrupt the on-chip DSP in addition to the ARM CPU. Add a DMTIMER
      attribute to indicate which timers can interrupt the DSP. By using the
      omap_dm_timer_request_by_cap() API, driver will now be able to allocate
      a DMTIMER that can interrupt the DSP based upon this attribute and not require
      the driver to know which instance has this capability.
      
      DMTIMERs that have the ability to interrupt the DSP on OMAP devices are as
      follows ...
      
      - OMAP1 (OMAP5912/16xx/17xx) devices	- All 8 DMTIMERs
      - OMAP2/3/4 devices			- DMTIMERs 5-8
      
      Please note that for OMAP3+, timer8 has the ability to interrupt the DSP and
      generate a PWM output.
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      5c3e4ec4
    • P
      hwrng: OMAP: remove SoC restrictions from driver registration · fe47c58b
      Paul Walmsley 提交于
      Remove the SoC restriction code from the OMAP RNG driver.  The
      integration code in arch/arm/*omap* should handle this.  The device
      shouldn't be created if it doesn't exist on the currently-booted SoC.
      
      This allows us to remove some OMAP-specific cpu_is_omap*() calls from
      the driver.  Also, if other OMAP chips have RNGs that can be used
      by Linux, there will be no need to modify the driver.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Matt Mackall <mpm@selenic.com>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Acked-by: NHerbert Xu <herbert@gondor.apana.org.au>
      fe47c58b
    • P
      ARM: OMAP: split OMAP1, OMAP2+ RNG device registration · 4848d460
      Paul Walmsley 提交于
      Move the OMAP1-specific RNG device creation off to mach-omap1/devices.c,
      and create a omap_device-backed registration function for OMAP2+ devices
      in mach-omap2/devices.c.
      
      As a nice side-benefit, we can also get rid of
      arch/arm/plat-omap/devices.c, thanks to some recent changes from Tony.
      
      One change from the previous behavior is that the RNG devices are now
      registered unconditionally.  This should allow the RNG drivers to be
      loaded as modules, even if the original kernel was not built that way.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      4848d460
    • P
      hwrng: OMAP: convert to use runtime PM · 665d92fa
      Paul Walmsley 提交于
      Convert the OMAP onboard hardware RNG driver to use runtime PM.
      
      This allows us to remove some OMAP-specific cpu_is_omap*() calls from
      the RNG driver.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Matt Mackall <mpm@selenic.com>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Acked-by: NHerbert Xu <herbert@gondor.apana.org.au>
      665d92fa
    • P
      hwrng: OMAP: store per-device data in per-device variables, not file statics · 02666360
      Paul Walmsley 提交于
      Encapsulate all of the RNG per-device state into a single per-device
      structure record, as opposed to a set of per-driver file variables.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Matt Mackall <mpm@selenic.com>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Acked-by: NHerbert Xu <herbert@gondor.apana.org.au>
      02666360
    • P
      ARM: OMAP2xxx: hwmod/CM: add RNG integration data · e9b0a2fb
      Paul Walmsley 提交于
      Add integration data for the hardware random number generator IP block
      on some OMAP SoCs.  This appears to be present on at least OMAP2xxx
      and OMAP3xxx SoCs, although it is not so easy to tell.  It may also be
      present on other OMAP2+ SoCs.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      e9b0a2fb
    • A
      ARM: OMAP2+: gpmc: minimal driver support · da496873
      Afzal Mohammed 提交于
      Create a minimal driver out of gpmc code.  Responsibilities handled by
      earlier gpmc initialization is now achieved in probe.
      Signed-off-by: NAfzal Mohammed <afzal@ti.com>
      Reviewed-by: NJon Hunter <jon-hunter@ti.com>
      [paul@pwsan.com: fixed some checkpatch messages]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      da496873
    • A
      ARM: OMAP2+: gpmc: Adapt to HWMOD · 4be48fd5
      Afzal Mohammed 提交于
      Create API for platforms to adapt GPMC to HWMOD
      Signed-off-by: NAfzal Mohammed <afzal@ti.com>
      Reviewed-by: NJon Hunter <jon-hunter@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      4be48fd5
    • A
      ARM: OMAP2/3: hwmod data: add gpmc · 49484a60
      Afzal Mohammed 提交于
      Add gpmc hwmod and associated interconnect data
      Signed-off-by: NAfzal Mohammed <afzal@ti.com>
      [paul@pwsan.com: added comments to the use of HWMOD_INIT_NO_RESET]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      49484a60
    • O
      ARM: OMAP4: hwmod data: add mmu hwmod for ipu and dsp · 230844db
      Omar Ramirez Luna 提交于
      Add mmu hwmod data for ipu and dsp.
      
      Cc: Benoit Cousson <b-cousson@ti.com>
      Signed-off-by: NOmar Ramirez Luna <omar.luna@linaro.org>
      Acked-by: NBenoit Cousson <b-cousson@ti.com>
      [paul@pwsan.com: cleaned up whitespace]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      230844db
    • P
      ARM: OMAP3: hwmod data: add mmu data for iva and isp · 5486474c
      Paul Walmsley 提交于
      Add mmu hwmod data for iva and isp.
      
      Due to compatibility an ifdef CONFIG_OMAP_IOMMU_IVA2 needs to be
      propagated (previously on iommu resource info) to hwmod data in OMAP3,
      so users of iommu and tidspbridge can avoid issues of two modules
      managing mmu data/irqs/resets; this until tidspbridge can be migrated
      to iommu framework.
      
      Cc: Benoit Cousson <b-cousson@ti.com>
      Signed-off-by: NOmar Ramirez Luna <omar.luna@linaro.org>
      [paul@pwsan.com: fixed some kerneldoc and whitespace; ISP MMUs not present
       on AM35xx so restricted these hwmods to 34xx/36xx]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      5486474c
    • O
      ARM: OMAP: iommu: fix including iommu.h without IOMMU_API selected · 7460f140
      Omar Ramirez Luna 提交于
      If included without IOMMU_API being selected it will break
      compilation:
      
      arch/arm/plat-omap/include/plat/iommu.h:
      	In function 'dev_to_omap_iommu':
      arch/arm/plat-omap/include/plat/iommu.h:148:
      	error: 'struct dev_archdata' has no member named 'iommu'
      
      This will be seen when hwmod includes iommu.h to get the
      structure for attributes. Also needed for tidspbridge
      incremental migration to use iommu code.
      
      Cc: Tony Lindgren <tony@atomide.com>
      Signed-off-by: NOmar Ramirez Luna <omar.luna@linaro.org>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      7460f140
    • P
      ARM: OMAP4: hwmod data: add missing HWMOD_NO_IDLEST flags to some PRCM IP blocks · 53cce97c
      Paul Walmsley 提交于
      Some struct omap_hwmod records belonging to PRCM IP blocks are missing
      HWMOD_NO_IDLEST flags; add them.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      53cce97c
    • K
      ARM: OMAP4: hwmod data: make *phy_48m* as the main_clk of ocp2scp · 1b024d2f
      Kishon Vijay Abraham I 提交于
      Made *ocp2scp_usb_phy_phy_48m* as the main_clk for ocp2scp.
      Since this ocp2scp module does not have any fck but does have a
      single opt_clock, it is added as the main_clk for ocp2scp. Also
      removed phy_48m as the optional clock since it is now made as the
      main clock. By this the driver need not enable/disable phy_48m clk
      separately and runtime_get/runtime_put will take care of that.
      
      Cc: Benoît Cousson <b-cousson@ti.com>
      Reviewed-by: NFelipe Balbi <balbi@ti.com>
      Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
      Acked-by: NBenoît Cousson <b-cousson@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      1b024d2f
    • B
      ARM: OMAP4: hwmod data: Fix ocp2scp_usb_phy and usb_host_hs entries · 33c976ec
      Benoit Cousson 提交于
      ocp2scp_usb_phy was missing the address space data and thus
      the sysconfig was not populated either.
      The usb_host_hs address space was wrong.
      
      Fix both of them and add the missing sysconfig entry.
      Reported-by: NKishon Vijay Abraham <kishon@ti.com>
      Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      33c976ec
    • T
      ARM: OMAP3: hwmod data: add sad2d hwmod · 8f993a01
      Tero Kristo 提交于
      SAD2D stands for the die to die interface, and is used for communicating
      with the optional stacked modem. This hwmod is added in preparation for
      the d2d_idle move from pm34xx.c to hwmod data.
      Signed-off-by: NTero Kristo <t-kristo@ti.com>
      [paul@pwsan.com: SAD2D presumably doesn't exist on non-OMAP34xx/OMAP36xx,
       so only add it to the OMAP34xx/OMAP36xx lists]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      8f993a01
    • O
      ARM: OMAP: hwmod: revise deassert sequence · e8e96dff
      Omar Ramirez Luna 提交于
      For a reset sequence to complete cleanly, a module needs its
      associated clocks to be enabled, otherwise the timeout check
      in prcm code can print a false failure (failed to hardreset)
      that occurs because the clocks aren't powered ON and the status
      bit checked can't transition without them.
      Signed-off-by: NOmar Ramirez Luna <omar.luna@linaro.org>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      e8e96dff
    • O
      ARM: OMAP: hwmod: partially un-reset hwmods might not be properly enabled · eb05f691
      Omar Ramirez Luna 提交于
      Some IP blocks might not be using/controlling more than one
      reset line, this check loosens the restriction to fully use
      hwmod framework for those drivers.
      
      E.g.: ipu has reset lines: mmu_cache, cpu0 and cpu1.
      - As of now cpu1 is not used and hence (with previous check) the
        IP block isn't fully enabled by hwmod code.
      - Usually ipu and dsp processors configure their mmu module first
        and then enable the processors, this involves:
          * Deasserting mmu reset line, and enabling the module.
          * Deasserting cpu0 reset line, and enabling the processor.
        The ones portrayed in this example are controlled through
        rproc_fw_boot in drivers/remoteproc/remoteproc_core.c
      
      While at it, prevent _omap4_module_disable if all the hardreset
      lines on an IP block are not under reset.
      
      This will allow the driver to:
        a. Deassert the reset line.
        b. Enable the hwmod through runtime PM default callbacks.
        c. Do its usecase.
        d. Disable hwmod through runtime PM.
        e. Assert the reset line.
      Signed-off-by: NOmar Ramirez Luna <omar.luna@linaro.org>
      [paul@pwsan.com: updated to apply]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      eb05f691
    • T
      ARM: OMAP4: hwmod: flag hwmods/modules not supporting module level context status · 46b3af27
      Tero Kristo 提交于
      On OMAP4 most modules/hwmods support module level context status. On
      OMAP3 and earlier, we relied on the power domain level context status.
      Identify all modules that don't support 'context_offs' by adding a
      flag bit, HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT.  Rest have a valid
      'context_offs' populated in .prcm structure already.
      Signed-off-by: NTero Kristo <t-kristo@ti.com>
      [paul@pwsan.com: add flag bit rather than overloading .context_offs;
       update changelog message]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      46b3af27
    • T
      ARM: OMAP4: hwmod data: add support for lostcontext_mask · ce80979a
      Tero Kristo 提交于
      Currently hwmod only provides the offset for the context lose
      register, and if we attempt to share the same register between two or
      more hwmods, the resulting context loss counts get wrong. Thus, we
      need a way to specify which bits are used for the context loss
      information for each.  This is accomplished by adding a new field to
      the omap4 prcm struct, 'lostcontext_mask', which specifies a bit-mask
      to use for filtering the register.
      
      Mark the affected hwmods appropriately.  'l4_abe' hwmod uses the
      LOSTMEM_AESSMEM bit of RM_ABE_AESS_CONTEXT register, as l4_abe doesn't
      have its own dedicated register for this purpose. This register is
      shared with 'aess' hwmod, thus both hwmods must also specify which
      bits of the register are used for them.
      
      This patch only adds the hwmod data, but a future patch should add
      code support such that only the specified bits are read and cleared by
      the context lose counter update code. If a hwmod doesn't specify
      'lostcontext_mask' (default behavior), the whole contents of the
      context register should be used without any filtering.
      Signed-off-by: NTero Kristo <t-kristo@ti.com>
      [paul@pwsan.com: updated to apply after conversion to use flag bit for
       missing module context-loss register; combined data and code patches;
       dropped code change due to serial driver breakage]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      ce80979a
    • T
      ARM: OMAP4: powerdomain: add support for reading prev logic and mem states · 5b8a14be
      Tero Kristo 提交于
      On OMAP4, there is no support to read previous logic state
      or previous memory state achieved when a power domain transitions
      to RET. Instead there are module level context registers.
      
      In order to support the powerdomain level logic/mem_off_counters
      on OMAP4, instead use the previous power state achieved (RET) and
      the *programmed* logic/mem RET state to derive if a powerdomain lost
      logic or did not.
      
      If the powerdomain is programmed to enter RET state and lose logic
      in RET state, knowing that the powerdomain entered RET is good enough
      to derive that the logic was lost as well, in such cases.
      Signed-off-by: NTero Kristo <t-kristo@ti.com>
      [paul@pwsan.com: removed dependency on functional power state series for now;
       bumped copyright date]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      5b8a14be
    • P
      ARM: OMAP2+: hwmod code: convert missing clockdomain warnings to debug messages · 3bb05dbf
      Paul Walmsley 提交于
      The decision was made a few months ago to allow struct omap_hwmod
      records and struct clk records to omit clockdomain information if the
      clockdomain is not software-controllable.  See for example commit
      868c157d ("ARM: OMAP2+: hwmod: remove
      prm_clkdm, cm_clkdm; allow hwmods to have no clockdomain").
      
      So convert an existing pr_warning() to a pr_debug() (regarding missing
      clockdomains in clocks), and add a pr_debug() for missing hwmod
      clockdomains.  It's still useful to enable these messages for
      debugging, since missing clockdomains can cause hard-to-debug problems
      with power management; see for example commit
      6c4a057b ("ARM: OMAP4: clock data:
      Force a DPLL clkdm/pwrdm ON before a relock").
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      3bb05dbf
    • P
      ARM: OMAP4+: hwmod code: remove clkdm requirement in _omap4_wait_target_*() · 2b026d13
      Paul Walmsley 提交于
      We're no longer requiring struct omap_hwmod records to contain a
      clockdomain.  So we shouldn't return -EINVAL any more from
      _omap4_wait_target_disable() or _omap4_wait_target_ready() if there's
      no clockdomain defined, since that just gets passed back to the
      caller.  This can result in pointless warnings under the relaxed data
      format.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      2b026d13
    • O
      ARM: OMAP2+: omap_device: expose hwmod assert/deassert to omap devices · 8bb9fde2
      Omar Ramirez Luna 提交于
      This API is meant to be an interface to hwmod assert/deassert
      function, omap devices can call them through their platform data to
      control their reset lines, they are expected to know the name of the
      reset line they are trying to control.
      Signed-off-by: NOmar Ramirez Luna <omar.luna@linaro.org>
      [paul@pwsan.com: tweaked some documentation; fixed CodingStyle issue]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      8bb9fde2
    • I
      ARM: OMAP: hwmod code: remove unused hwmod function prototypes · c9e49024
      Igor Grinberg 提交于
      Several hwmod function prototypes appear to not have an implementation
      because the corresponding functions were removed or renamed.
      Those prototypes are unneeded anymore - remove them.
      Signed-off-by: NIgor Grinberg <grinberg@compulab.co.il>
      [paul@pwsan.com: tweaked subject]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      c9e49024
    • P
      Merge branch 'clock_devel_3.7' into hwmod_prcm_clock_a_3.7 · 4fb85d35
      Paul Walmsley 提交于
      Conflicts:
      	arch/arm/mach-omap2/clkt34xx_dpll3m2.c
      	arch/arm/mach-omap2/clkt_clksel.c
      	arch/arm/mach-omap2/clock.c
      4fb85d35
    • P
      Merge tag 'omap-devel-am33xx-for-v3.7' into test_v3.6-rc6_ocb3.7_cff3.7_odaf3.7 · 1e2ee2a6
      Paul Walmsley 提交于
      From Paul Walmsley <paul@pwsan.com>:
      
      AM33xx hwmod data and miscellaneous clock and hwmod fixes.  AM33xx
      should now boot on mainline after this is applied, according to
      Vaibhav.
      1e2ee2a6
    • P
      Merge tag 'cleanup-fixes-for-v3.7' into test_v3.6-rc6_ocb3.7_cff3.7_odaf3.7 · 291852e8
      Paul Walmsley 提交于
      These fixes are needed to fix non-omap build breakage for
      twl-core driver and to fix omap1_defconfig compile when
      led driver changes and omap sparse IRQ changes are merged
      together. Also fix warnings for omaps not using pinctrl
      framework yet.
      291852e8
    • P
      Merge tag 'omap-cleanup-b-for-3.7' into test_v3.6-rc6_ocb3.7_cff3.7_odaf3.7 · 2910f145
      Paul Walmsley 提交于
      smatch and string-wrapping cleanups for the OMAP subarch code.
      
      These changes fix some of the more meaningful warnings that smatch
      returns for the OMAP subarch code, and unwraps strings that are
      wrapped at the 80-column boundary, to conform with the current
      practice.
      
      Basic build, boot, and PM logs are available here:
      
      http://www.pwsan.com/omap/testlogs/warnings_a_cleanup_3.7/20120912025927/
      2910f145
  2. 23 9月, 2012 5 次提交
    • V
      ARM: AM33XX: cm: Add bit-field width values · a86c0b98
      Vaibhav Hiremath 提交于
      The new common clk framework includes basic definitions for mux and
      divider clocks.  These definitions depend on shift and width values
      instead of the pre-computed masks that the OMAP/AM33XX clk framework
      has traditionally used when accessing the register to control the
      mux or divisor.
      
      To ease this transition the masks are left intact and
      the width field is simply added alongside the shift and mask data.
      Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Mike Turquette <mturquette@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      a86c0b98
    • M
      ARM: OMAP4: cm: add bitfield width values · f19a3022
      Mike Turquette 提交于
      The new common clk framework includes basic definitions for mux and
      divider clocks.  These definitions depend on shift and width values
      instead of the pre-computed masks that the OMAP clk framework has
      traditionally used when accessing the register to control the mux or
      divisor.
      
      To ease this transition the masks are left intact and the width field is
      simply added alongside the shift and mask data.
      Signed-off-by: NMike Turquette <mturquette@ti.com>
      Signed-off-by: NRajendra Nayak <rnayak@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      f19a3022
    • R
      ARM: OMAP2+: clock: Remove all direct dereferencing of struct clk · 5dcc3b97
      Rajendra Nayak 提交于
      While we move to Common Clk Framework (CCF), direct deferencing of struct
      clk wouldn't be possible anymore. Hence get rid of all such instances
      in the current clock code and use macros/helpers similar to the ones that
      are provided by CCF.
      
      While here also concatenate some strings split across multiple lines
      which seem to be needed anyway.
      Signed-off-by: NRajendra Nayak <rnayak@ti.com>
      [paul@pwsan.com: simplified some compound expressions; reformatted some
       messages]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Mike Turquette <mturquette@linaro.org>
      5dcc3b97
    • R
      ARM: OMAP2+: hwmod: get rid of all omap_clk_get_by_name usage · 6ea74cb9
      Rajendra Nayak 提交于
      Moving to Common clk framework for OMAP would mean we no longer use
      internal lookup mechanism like omap_clk_get_by_name().
      get rid of all its usage mostly from hwmod and omap_device
      code.
      
      Moving to clk_get() also means the respective platforms
      need the clkdev tables updated with an entry for all clocks
      used by hwmod to have clock name same as the alias.
      
      Based on original changes from Mike Turquette.
      Signed-off-by: NRajendra Nayak <rnayak@ti.com>
      Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>
      [paul@pwsan.com: removed IS_ERR_OR_NULL() conversion (rmk comment);
       restricted omap_96m_alwon_fck_3630 to OMAP36xx; added missing AM35xx
       clock aliases for emac_fck, emac_ick, vpfe_ick, vpfe_fck; added
       aliases rng_ick and several emulation clocks]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      6ea74cb9
    • R
      ARM: omap: clk: add clk_prepare and clk_unprepare · 4d7cb45e
      Rajendra Nayak 提交于
      As part of Common Clk Framework (CCF) the clk_enable() operation
      was split into a clk_prepare() which could sleep, and a clk_enable()
      which should never sleep. Similarly the clk_disable() was
      split into clk_disable() and clk_unprepare(). This was
      needed to handle complex cases where in a clk gate/ungate
      would require a slow and a fast part to be implemented.
      None of the clocks below seem to be in the 'complex' clocks
      category and are just simple clocks which are enabled/disabled
      through simple register writes.
      Most of the instances also seem to be called in non-atomic
      context which means its safe to move all of those from
      using a clk_enable() to clk_prepare_enable() and clk_disable() to
      clk_disable_unprepare().
      
      For some others, mainly the ones handled through the hwmod framework
      there is a possibility that they get called in either an atomic
      or a non-atomic context.
      
      The way these get handled below work only as long as clk_prepare
      is implemented as a no-op (which is the case today) since this gets
      called very early at boot while most subsystems are unavailable.
      Hence these are marked with a *HACK* comment, which says we need
      to re-visit these once we start doing something meaningful with
      clk_prepare/clk_unprepare like doing voltage scaling or something
      that involves i2c.
      
      This is in preparation of OMAP moving to CCF.
      
      Based on initial changes from Mike Turquette.
      Signed-off-by: NRajendra Nayak <rnayak@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      4d7cb45e