1. 08 5月, 2012 1 次提交
  2. 27 2月, 2012 1 次提交
  3. 25 2月, 2012 4 次提交
  4. 15 2月, 2012 1 次提交
  5. 05 1月, 2012 1 次提交
  6. 14 12月, 2011 2 次提交
  7. 09 12月, 2011 6 次提交
  8. 06 12月, 2011 1 次提交
  9. 18 11月, 2011 1 次提交
  10. 08 11月, 2011 1 次提交
    • T
      ARM: OMAP: HWMOD: Unify DSS resets for OMAPs · 13662dc5
      Tomi Valkeinen 提交于
      This patch adds a custom DSS reset function used on OMAPs from OMAP2
      forward.
      
      The function doesn't actually do a reset, it only waits for the reset to
      complete. The reason for this is that on OMAP4 there is no possibility
      to do a SW reset, and on OMAP2/3 doing a SW reset for dss_core resets
      all the other DSS modules also, thus breaking the HWMOD model where
      every DSS module is handled independently.
      
      This fixes the problem with DSS reset on OMAP4, caused by the fact that
      because there's no SW reset for dss_core on OMAP4, the HWMOD framework
      doesn't try to reset dss_core and thus the DSS clocks were never enabled
      at the same time. This causes causes the HWMOD reset to fail for
      dss_dispc and dss_rfbi.
      
      The common reset function will also allow us to fix another problem in
      the future: before doing a reset we need to disable DSS outputs, which
      are in some cases enabled by the bootloader, as otherwise DSS HW seems
      to get more or less stuck, requiring a power reset to recover.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      [paul@pwsan.com: modified to build arch/arm/mach-omap2/display.o
       unconditionally to avoid an error when !CONFIG_OMAP2_DSS]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      13662dc5
  11. 20 10月, 2011 3 次提交
  12. 27 9月, 2011 1 次提交
  13. 24 8月, 2011 1 次提交
  14. 20 6月, 2011 1 次提交
    • T
      omap: Set separate timer init functions to avoid cpu_is_omap tests · e74984e4
      Tony Lindgren 提交于
      This is needed for the following patches so we can initialize the
      rest of the hardware timers later on.
      
      As with the init_irq calls, there's no need to do cpu_is_omap calls
      during the timer init as we only care about the major omap generation.
      This means that we can initialize the sys_timer with the .timer
      entries alone.
      
      Note that for now we just set stubs for the various sys_timer entries
      that will get populated in a later patch. The following patches will
      also remove the omap_dm_timer_init calls and change the init for the
      rest of the hardware timers to happen with an arch_initcall.
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      Reviewed-by: NKevin Hilman <khilman@ti.com>
      e74984e4
  15. 10 3月, 2011 1 次提交
    • K
      OMAP2+: remove unused UART base addresses from omap_globals · df93bd76
      Kevin Hilman 提交于
      Now that omap_hwmod + omap_device is used for OMAP UART device and
      driver code, we no longer need the UART physical addresses in
      omap_globals.
      
      Note that the #defines for the base addresses are still left in
      <plat/serial.h> since they are used by DEBUG_LL and uncompress code.
      
      Build tested for OMAP1 (omap1_defconfig) and OMAP2+ (omap2plus_defconfig)
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      df93bd76
  16. 17 2月, 2011 1 次提交
  17. 20 1月, 2011 2 次提交
  18. 19 1月, 2011 1 次提交
    • P
      OMAP: counter_32k: init clocksource as part of machine timer init · d8328f3b
      Paul Walmsley 提交于
      After commit dc548fbb ("ARM: omap: convert
      sched_clock() to use new infrastructure"), OMAPs that use the 32KiHz
      "synchronization timer" as their clocksource crash during boot:
      
      [    0.000000] OMAP clockevent source: GPTIMER1 at 32768 Hz
      [    0.000000] Unable to handle kernel NULL pointer dereference at virtual address 00000000
      [    0.000000] pgd = c0004000
      [    0.000000] [00000000] *pgd=00000000
      [    0.000000] Internal error: Oops: 80000005 [#1] SMP
      [    0.000000] last sysfs file:
      [    0.000000] Modules linked in:
      [    0.000000] CPU: 0    Tainted: G        W    (2.6.37-07734-g2467802 #7)
      [    0.000000] PC is at 0x0
      [    0.000000] LR is at sched_clock_poll+0x2c/0x3c
      [    0.000000] pc : [<00000000>]    lr : [<c0060b74>]    psr: 600001d3
      [    0.000000] sp : c058bfd0  ip : c058a000  fp : 00000000
      [    0.000000] r10: 00000000  r9 : 411fc092  r8 : 800330c8
      [    0.000000] r7 : c05a08e0  r6 : c0034c48  r5 : c05ffc40  r4 : c0034c4c
      [    0.000000] r3 : c05ffe6c  r2 : c05a0bc0  r1 : c059f098  r0 : 00000000
      [    0.000000] Flags: nZCv  IRQs off  FIQs off  Mode SVC_32  ISA ARM  Segment kernel
      [    0.000000] Control: 10c53c7f  Table: 8000404a  DAC: 00000017
      
      This is due to the recent ARM init_sched_clock() changes and the late
      initialization of the counter_32k clock source.  More information here:
      
         http://marc.info/?l=linux-omap&m=129513468605208&w=2
      
      Fix by initializing the counter_32k clocksource during the machine timer
      initialization.
      Reported-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Tested-by: NThomas Weber <weber@corscience.de>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      d8328f3b
  19. 22 12月, 2010 1 次提交
  20. 30 9月, 2010 1 次提交
  21. 28 9月, 2010 1 次提交
    • S
      omap4: control: Add ctrl_pad_base to omap_globals · 0c349246
      Santosh Shilimkar 提交于
      On omap4 control module is divided in four IP blocks.
      - CTRL_MODULE_CORE			0x4a002000
      - CTRL_MODULE_PAD_CORE		0x4a100000
      - CTRL_MODULE_WKUP			0x4a30c000
      - CTRL_MODULE_PAD_WKUP		0x4a31e000
      
      Addressing all the modules with single base address is not possible
      considering 16 bit offsets. The mux code manages the pad core and pad
      wakeup related base address inside the mux framework. For other usage
      only control core and control pad bases are necessary. So this patch
      maps only needed pad control base address which is used by device drivers
      and infrastructure code
      
      The main control core base is still kept same in this patch to
      keep git-bisect working. This will be fixed in the relevant patch
      in this series.
      Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
      Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      0c349246
  22. 24 9月, 2010 1 次提交
    • T
      OMAP4: pm.c extensions for OMAP4 support · b3294e23
      Thara Gopinath 提交于
      OMAP4 has an iva device and a dsp devcice where as OMAP2/3
      has only an iva device. In this file the iva device in the
      system is registered under the name dsp_dev and the API
      to retrieve the iva device is omap2_get_dsp_device.
      This patch renames the dsp_dev to iva_dev, renames
      omap2_get_dsp_device to omap2_get_iva_device,
      registers dsp_dev for OMAP4 and adds a new API
      omap4_get_dsp_device to retrieve the dep_dev.
      Signed-off-by: NThara Gopinath <thara@ti.com>
      Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      b3294e23
  23. 04 8月, 2010 2 次提交
  24. 27 7月, 2010 1 次提交
    • K
      OMAP: PM: create omap_devices for MPU, DSP, L3 · 6f88e9bc
      Kevin Hilman 提交于
      Create simple omap_devices for the main processors and busses.
      
      This is required to support the forth-coming device-based OPP
      approach, where OPPs are managed and tracked at the device level.
      
      Also, move these common PM init functions into a common_pm_init call
      that is called as a device_initcall().  The PM init is done at this level
      to ensure that the driver core is initialized before initialized.
      Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      [paul@pwsan.com: sparse warnings cleaned up; newly-created functions moved
       from mach-omap2/io.c to mach-omap2/pm.c; newly-created functions renamed
       to start with "omap2" rather than "omap"]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      6f88e9bc
  25. 16 7月, 2010 1 次提交
  26. 21 5月, 2010 1 次提交
  27. 24 2月, 2010 1 次提交