1. 11 5月, 2012 3 次提交
    • T
      OMAPDSS: create DPI & SDI devices · 53f576a8
      Tomi Valkeinen 提交于
      We currently have separate device/driver for each DSS HW module. The DPI
      and SDI outputs are more or less parts of the DSS or DISPC hardware
      modules, but in SW it makes sense to represent them as device/driver
      pairs similarly to all the other outputs. This also makes sense for
      device tree, as each node under dss will be a platform device, and
      handling DPI & SDI somehow differently than the rest would just make the
      code more complex.
      
      This patch modifies arch/arm/mach-omap2/display.c to create platform
      devices for DPI and SDI, and later patches will implement driver for
      them.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      53f576a8
    • T
      OMAPDSS: create custom pdevs for DSS omap_devices · 966eaed0
      Tomi Valkeinen 提交于
      Instead of using omap_device_build() to create the omap_devices for DSS
      hwmods, create them with a custom function. This will allow us to create
      a parent-child hierarchy for the devices so that the omapdss_core device
      is parent for the rest of the dss hwmod devices.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      966eaed0
    • T
      OMAPDSS: clean up the omapdss platform data mess · 00928eaf
      Tomi Valkeinen 提交于
      The omapdss pdata handling is a mess. This is more evident when trying
      to use device tree for DSS, as we don't have platform data anymore in
      that case. This patch cleans the pdata handling by:
      
      - Remove struct omap_display_platform_data. It was used just as a
        wrapper for struct omap_dss_board_info.
      - Pass the platform data only to omapdss device. The drivers for omap
        dss hwmods do not need the platform data. This should also work better
        for DT, as we can create omapdss device programmatically in generic omap
        boot code, and thus we can pass the pdata to it.
      - Create dss functions for get_ctx_loss_count and dsi_enable/disable_pads
        that the dss hwmod drivers can call.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      00928eaf
  2. 23 4月, 2012 1 次提交
  3. 20 3月, 2012 1 次提交
  4. 25 2月, 2012 2 次提交
  5. 26 1月, 2012 1 次提交
  6. 05 1月, 2012 2 次提交
  7. 07 12月, 2011 1 次提交
  8. 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
  9. 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
  10. 05 10月, 2011 1 次提交
  11. 30 9月, 2011 3 次提交
  12. 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
  13. 25 7月, 2011 4 次提交
  14. 11 5月, 2011 2 次提交
  15. 11 3月, 2011 3 次提交
  16. 23 2月, 2011 1 次提交