1. 22 3月, 2011 1 次提交
  2. 16 3月, 2011 1 次提交
  3. 15 3月, 2011 1 次提交
    • D
      omap: iovmm: don't check 'da' to set IOVMF_DA_FIXED flag · d038aee2
      David Cohen 提交于
      Currently IOVMM driver sets IOVMF_DA_FIXED/IOVMF_DA_ANON flags according
      to input 'da' address when mapping memory:
      da == 0: IOVMF_DA_ANON
      da != 0: IOVMF_DA_FIXED
      
      It prevents IOMMU to map first page with fixed 'da'. To avoid such
      issue, IOVMM will not automatically set IOVMF_DA_FIXED. It should now
      come from the user throught 'flags' parameter when mapping memory.
      As IOVMF_DA_ANON and IOVMF_DA_FIXED are mutually exclusive, IOVMF_DA_ANON
      can be removed. The driver will now check internally if IOVMF_DA_FIXED
      is set or not.
      Signed-off-by: NDavid Cohen <dacohen@gmail.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      d038aee2
  4. 12 3月, 2011 1 次提交
  5. 11 3月, 2011 4 次提交
  6. 10 3月, 2011 5 次提交
  7. 09 3月, 2011 1 次提交
  8. 08 3月, 2011 3 次提交
  9. 02 3月, 2011 3 次提交
    • K
      OMAP: adapt hsmmc to hwmod framework · 4621d5f8
      Kishore Kadiyala 提交于
      OMAP2420 platform consists of mmc block as in omap1 and not the
      hsmmc block as present in omap2430, omap3, omap4 platforms.
      Removing all base address macro defines except keeping one for OMAP2420 and
      adapting only hsmmc device registration and driver to hwmod framework.
      
      Changes involves:
      1) Remove controller reset in devices.c which is taken care of
         by hwmod framework.
      2) Using omap-device layer to register device and utilizing data from
         hwmod data file for base address, dma channel number, Irq_number,
         device attribute.
      3) Update the driver to use dev_attr to find whether controller
         supports dual volt cards
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Signed-off-by: NKishore Kadiyala <kishore.kadiyala@ti.com>
      Reviewed-by: NBalaji T K <balajitk@ti.com>
      Cc: Benoit Cousson <b-cousson@ti.com>
      CC: Kevin Hilman <khilman@deeprootsystems.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      4621d5f8
    • K
      OMAP: hwmod data: Add dev_attr and use in the host driver · 6ab8946f
      Kishore Kadiyala 提交于
      Add a device attribute to hwmod data of omap2430, omap3, omap4.
      Currently the device attribute holds information regarding dual volt MMC card
      support by the controller which will be later passed to the host driver via
      platform data.
      Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      Signed-off-by: NKishore Kadiyala <kishore.kadiyala@ti.com>
      Acked-by: Benoit Cousson<b-cousson@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      6ab8946f
    • A
      omap: mmc: split out init for 2420 · e08016d0
      Anand Gadiyar 提交于
      The MMC controller on the OMAP2420 is different from those
      on the OMAP2430, OMAP3 and OMAP4 families - all of the latter
      are identical. The one on the OMAP2420 is closer to that
      on OMAP1 chips.
      
      Currently, the n8x0 is the only OMAP2420 platform supported
      in mainline which registers the MMC controller. Upcoming
      changes to register the controllers using hwmod data are
      potentially invasive. To reduce the risk, separate out the
      2420 controller registration from the common init function
      and update its only user. Also seperating out mux settings
      for OMAP2420.
      Signed-off-by: NAnand Gadiyar <gadiyar@ti.com>
      Signed-off-by: NKishore Kadiyala <kishore.kadiyala@ti.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
      Cc: Chris Ball <cjb@laptop.org>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      e08016d0
  10. 01 3月, 2011 7 次提交
  11. 28 2月, 2011 1 次提交
  12. 26 2月, 2011 2 次提交
    • R
      OMAP4: DPLL: Add dpll api to control GATE_CTRL · 97f67898
      Rajendra Nayak 提交于
      On OMAP4, the dpll post divider outputs (MX outputs)
      along with clockout_x2 output provide a way to allow/deny
      hardware level autogating.
      Allowing autoidle would mean that the hw would autogate
      this clock when there is no dependency for it.
      Denying idle would mean that this clock output will be
      forced to stay enabled.
      
      Add dpll api's to read/allow/deny idle control
      for these dpll mx postdividers.
      
      NOTE: The gatectrl bit set to 0 allows gatectrl,
      and the bit set to 1 denies gatectrl.
      Signed-off-by: NRajendra Nayak <rnayak@ti.com>
      [paul@pwsan.com: moved OMAP4-specific DPLL control code to
       mach-omap2/dpll44xx.c; added some documentation for CLOCK_CLKOUTX2]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      97f67898
    • R
      OMAP: clock: Add allow_idle/deny_idle support in clkops · 58e846fe
      Rajendra Nayak 提交于
      On OMAP various clock nodes (dpll's, mx post dividers, interface clocks)
      support hardware level autogating which can be controlled from
      software.
      Support such functionality by adding two new function pointer
      allow_idle and deny_idle in the clkops structure.
      
      These function pointers can be populated for any clock
      node which supports hardware level autogating.
      
      Also add 2 new functions (omap_clk_enable_autoidle_all and
      omap_clk_disable_autoidle_all) which can be called from
      architecture specific PM core code, if hardware level
      autogating (for all supported clock nodes) is to be
      enabled or disabled.
      Signed-off-by: NRajendra Nayak <rnayak@ti.com>
      [paul@pwsan.com: use spinlock rather than mutex due to race; renamed functions;
       functions now return ints]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      58e846fe
  13. 25 2月, 2011 10 次提交