1. 25 2月, 2012 1 次提交
  2. 26 1月, 2012 1 次提交
  3. 05 1月, 2012 2 次提交
  4. 07 12月, 2011 1 次提交
  5. 08 11月, 2011 2 次提交
    • A
      ARM: OMAP2PLUS: DSS: Ensure DSS works correctly if display is enabled in bootloader · b923d40d
      Archit Taneja 提交于
      Resetting DISPC when a DISPC output is enabled causes the DSS to go into an
      inconsistent state. Thus if the bootloader has enabled a display, the hwmod code
      cannot reset the DISPC module just like that, but the outputs need to be
      disabled first.
      
      Add function dispc_disable_outputs() which disables all active overlay manager
      and ensure all frame transfers are completed.
      
      Modify omap_dss_reset() to call this function and clear DSS_CONTROL,
      DSS_SDI_CONTROL and DSS_PLL_CONTROL so that DSS is in a clean state when the
      DSS2 driver starts.
      
      This resolves the hang issue(caused by a L3 error during boot) seen on the
      beagle board C3, which has a factory bootloader that enables display. The issue
      is resolved with this patch.
      
      Thanks to Tomi and Sricharan for some additional testing.
      Acked-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Tested-by: NR, Sricharan <r.sricharan@ti.com>
      Signed-off-by: NArchit Taneja <archit@ti.com>
      [paul@pwsan.com: restructured code, removed omap_{read,write}l(), removed
       cpu_is_omap*() calls and converted to dev_attr]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      b923d40d
    • 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
  6. 01 11月, 2011 1 次提交
    • P
      arm: fix implicit memset/string.h usage in various arch/arm files · d44b28c4
      Paul Gortmaker 提交于
      To fix things like this:
      
      arch/arm/mach-omap2/usb-tusb6010.c:58: error: implicit declaration of function 'memset'
      arch/arm/kernel/leds.c:40: error: implicit declaration of function 'strcspn'
      arch/arm/kernel/leds.c:40: warning: incompatible implicit declaration of built-in function 'strcspn'
      arch/arm/kernel/leds.c:45: error: implicit declaration of function 'strncmp'
      arch/arm/kernel/leds.c:55: error: implicit declaration of function 'strlen'
      arch/arm/kernel/leds.c:55: warning: incompatible implicit declaration of built-in function 'strlen'
      arch/arm/mach-omap2/clockdomain.c:52: error: implicit declaration of function 'strcmp'
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      d44b28c4
  7. 05 10月, 2011 1 次提交
  8. 30 9月, 2011 3 次提交
  9. 16 9月, 2011 1 次提交
    • K
      OMAP: omap_device: when building return platform_device instead of omap_device · 3528c58e
      Kevin Hilman 提交于
      All of the device init and device driver interaction with omap_device
      is done using platform_device pointers.  To make this more explicit,
      have omap_device return a platform_device pointer instead of an
      omap_device pointer.
      
      All current users of the omap_device pointer were only using it to get
      at the platform_device pointer or struct device pointer, so fixing all
      of the users was trivial.
      
      This also makes it more difficult for device init code to directly
      access members of struct omap_device, and allows for easier changing
      of omap_device internals.
      
      Cc: Paul Walmsley <paul@pwsan.com>
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      3528c58e
  10. 25 7月, 2011 4 次提交
  11. 11 5月, 2011 2 次提交
  12. 11 3月, 2011 3 次提交
  13. 23 2月, 2011 1 次提交