1. 14 4月, 2010 1 次提交
  2. 16 2月, 2010 1 次提交
  3. 09 2月, 2010 1 次提交
  4. 19 1月, 2010 1 次提交
  5. 15 1月, 2010 1 次提交
  6. 09 12月, 2009 1 次提交
  7. 01 12月, 2009 2 次提交
  8. 01 10月, 2009 1 次提交
  9. 16 9月, 2009 2 次提交
  10. 04 9月, 2009 1 次提交
    • P
      OMAP2/3 PM: create the OMAP PM interface and add a default OMAP PM no-op layer · c0407a96
      Paul Walmsley 提交于
      The interface provides device drivers, CPUFreq, and DSPBridge with a
      means of controlling OMAP power management parameters that are not yet
      supported by the Linux PM PMQoS interface.  Copious documentation is
      in the patch in Documentation/arm/OMAP/omap_pm and the interface
      header file, arch/arm/plat-omap/include/mach/omap-pm.h.
      
      Thanks to Rajendra Nayak <rnayak@ti.com> for adding CORE (VDD2) OPP
      support and moving the OPP table initialization earlier in the event
      that the clock code needs them.  Thanks to Tero Kristo
      <tero.kristo@nokia.com> for fixing the parameter check in
      omap_pm_set_min_bus_tput().  Jouni signed off on Tero's patch.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      Signed-off-by: NRajendra Nayak <rnayak@ti.com>
      Signed-off-by: NTero Kristo <tero.kristo@nokia.com>
      Signed-off-by: NJouni Högander <jouni.hogander@nokia.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Igor Stoppa <igor.stoppa@nokia.com>
      Cc: Richard Woodruff <r-woodruff2@ti.com>
      Cc: Anand Sawant <sawant@ti.com>
      Cc: Sakari Poussa <sakari.poussa@nokia.com>
      Cc: Veeramanikandan Raju <veera@ti.com>
      Cc: Karthik Dasu <karthik-dp@ti.com>
      c0407a96
  11. 31 7月, 2009 1 次提交
  12. 30 7月, 2009 1 次提交
  13. 18 5月, 2009 1 次提交
  14. 16 3月, 2009 1 次提交
    • N
      [ARM] fixmap support · 5f0fbf9e
      Nicolas Pitre 提交于
      This is the minimum fixmap interface expected to be implemented by
      architectures supporting highmem.
      
      We have a second level page table already allocated and covering
      0xfff00000-0xffffffff because the exception vector page is located
      at 0xffff0000, and various cache tricks already use some entries above
      0xffff0000.  Therefore the PTEs covering 0xfff00000-0xfffeffff are free
      to be used.
      
      However the XScale cache flushing code already uses virtual addresses
      between 0xfffe0000 and 0xfffeffff.
      
      So this reserves the 0xfff00000-0xfffdffff range for fixmap stuff.
      
      The Documentation/arm/memory.txt information is updated accordingly,
      including the information about the actual top of DMA memory mapping
      region which didn't match the code.
      Signed-off-by: NNicolas Pitre <nico@marvell.com>
      5f0fbf9e
  15. 08 3月, 2009 1 次提交
  16. 29 12月, 2008 1 次提交
  17. 15 12月, 2008 1 次提交
  18. 30 10月, 2008 1 次提交
  19. 09 8月, 2008 4 次提交
  20. 07 8月, 2008 1 次提交
  21. 27 7月, 2008 1 次提交
  22. 23 4月, 2008 1 次提交
  23. 03 2月, 2008 1 次提交
  24. 20 10月, 2007 1 次提交
  25. 13 10月, 2007 1 次提交
  26. 09 5月, 2007 2 次提交
  27. 02 3月, 2007 1 次提交
  28. 14 2月, 2007 3 次提交
  29. 31 12月, 2006 1 次提交
  30. 04 10月, 2006 3 次提交