1. 29 6月, 2012 1 次提交
    • C
      OMAPDSS: Add LCD3 overlay manager and Clock and IRQ support · e86d456a
      Chandrabhanu Mahapatra 提交于
      The support for LCD3 manager has been added into the manager module. LCD3 panel
      has registers as DISPC_CONTROL3 and DISPC_CONFIG3 just like those in LCD and
      LCD2 panels. These registers control the Display Controller (DISPC) module for
      LCD3 output. The three LCDs support Display Serial Interface (DSI), Remote Frame
      Buffer Interface (RFBI) and Parallel CMOS Output Interface (DPI). These LCDs can
      be connected through parallel output interface using DISPC and RFBI or DPI. For
      serial interface DSS uses DSI.
      
      The LCD3 panel, just like LCD and LCD2 panels, has a clock switch in DSS_CTRL
      register which has been enabled. The clock switch chooses between DSS_CLK and
      DPLL_DSI1_C_CLK1 as source for LCD3_CLK. New IRQs as DISPC_IRQ_VSYNC3,
      DISPC_IRQ_FRAMEDONE3, DISPC_IRQ_ACBIAS_COUNT_STAT3 and DISPC_IRQ_SYNC_LOST3 have
      been added specific to the new manager.
      Signed-off-by: NChandrabhanu Mahapatra <cmahapatra@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      e86d456a
  2. 28 6月, 2012 1 次提交
    • T
      OMAPDSS: remove enum omap_dss_overlay_managers · 0df8ad71
      Tomi Valkeinen 提交于
      We have two almost the same enums: omap_channel and
      omap_dss_overlay_managers. omap_channel is used almost everywhere, and
      omap_channel assigns explicit values to the enum values which are needed
      for proper operation.
      
      omap_dss_overlay_managers is only used in one place, so it's easy to
      remove it, which is what this patch does.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      0df8ad71
  3. 22 5月, 2012 1 次提交
    • C
      OMAPDSS: DISPC: Support rotation through TILER · 65e006ff
      Chandrabhanu Mahapatra 提交于
      TILER is a block in OMAP4's DMM which lets DSS fetch frames in a rotated manner.
      Physical memory can be mapped to a portion of OMAP's system address space called
      TILER address space. The TILER address space is split into 8 views. Each view
      represents a rotated or mirrored form of the mapped physical memory. When a
      DISPC overlay's base address is programmed to one of these views, the TILER
      fetches the pixels according to the orientation of the view. A view is further
      split into 4 containers, each container holds elements of a particular size.
      Rotation can be achieved at the granularity of elements in the container. For
      more information on TILER, refer to the Memory Subsytem section in OMAP4 TRM.
      Rotation type TILER has been added which is used to exploit the capabilities of
      these 8 views for performing various rotations.
      
      When fetching from addresses mapped to TILER space, the DISPC DMA can fetch
      pixels in either 1D or 2D bursts. The fetch depends on which TILER container we
      are accessing. Accessing 8, 16 and 32 bit sized containers requires 2D bursts,
      and page mode sized containers require 1D bursts.
      
      The DSS2 user is expected to provide the Tiler address of the view that it is
      interested in. This is passed to the paddr and p_uv_addr parameters in
      omap_overlay_info. It is also expected to provide the stride value based on the
      view's orientation and container type, this should be passed to the screen_width
      parameter of omap_overlay_info. In calc_tiler_rotation_offset screen_width is
      used to calculate the required row_inc for DISPC. x_predecim and y_predecim are
      also used to calculate row_inc and pix_inc thereby adding predecimation support
      for TILER.
      Signed-off-by: NChandrabhanu Mahapatra <cmahapatra@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      65e006ff
  4. 09 5月, 2012 1 次提交
    • A
      OMAPDSS: APPLY: Remove display dependency from overlay and manager checks · 228b2134
      Archit Taneja 提交于
      In order to check the validity of overlay and manager info, there was a need to
      use the omap_dss_device struct to get the panel resolution. The manager's
      private data in APPLY now contains the manager timings. Hence, we don't need to
      rely on the display resolution any more.
      
      Pass the manager's timings in private data to dss_mgr_check(). Remove the need
      to pass omap_dss_device structs in the functions which check for the validity
      of overlay and manager parameters.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      228b2134
  5. 02 1月, 2012 2 次提交
  6. 02 12月, 2011 8 次提交
    • T
      OMAPDSS: APPLY: move ovl->info to apply.c · c1a9febf
      Tomi Valkeinen 提交于
      struct omap_overlayr contains info and info_dirty fields, both of which
      should be internal to apply.c.
      
      This patch moves those fields into ovl_priv data, and names them
      user_info and user_info_dirty.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      c1a9febf
    • T
      OMAPDSS: APPLY: rewrite overlay enable/disable · aaa874a9
      Tomi Valkeinen 提交于
      Overlays are currently enabled and disabled with a boolean in the struct
      omap_overlay_info. The overlay info is set with ovl->set_overlay_info(),
      and made into use with mgr->apply().
      
      This doesn't work properly, as the enable/disable status may affect also
      other overlays, for example when using fifo-merge. Thus the enabling and
      disabling of the overlay needs to be done outside the normal overlay
      configuration.
      
      This patch achieves that by doing the following things:
      
      1) Add function pointers to struct omap_overlay: enable(), disable() and
      is_enabled(). These are used to do the obvious. The functions may block.
      
      2) Move the "enabled" field from struct omap_overlay to ovl_priv_data.
      
      3) Add a new route for settings to be applied to the HW, called
      "extra_info". The status of the normal info and extra_info are tracked
      separately.
      
      The point here is to allow the normal info to be changed and
      applied in non-blocking matter, whereas the extra_info can only be
      changed when holding the mutex. This makes it possible to, for example,
      set the overlay enable flag, apply it, and wait until the HW has taken
      the flag into use.
      
      This is not possible if the enable flag would be in the normal info, as
      a new value for the flag could be set at any time from the users of
      omapdss.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      aaa874a9
    • T
      OMAPDSS: remove ovl/mgr check-code temporarily · 5738b633
      Tomi Valkeinen 提交于
      DSS currently tries to check that the given overlay and overlay manager
      settings are acceptable, but the code does not work quite properly.
      Things may change between the check and the actual use of the settings.
      
      Furthermore, the following patches will rewrite how settings are
      configured and managed, and trying to keep the (broken) settings
      checking working during the rewrite would be very difficult.
      
      This patch removes the checking code, and a working version of checking
      will be added back after the settings rewrite has been done.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      5738b633
    • T
      OMAPDSS: APPLY: move ovl funcs to apply.c · f77b3070
      Tomi Valkeinen 提交于
      apply.c will handle the management of dispc in the future patches. This
      patch moves overlay related functions to apply.c so that they will have
      access to the private data and functions of apply.c.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      f77b3070
    • T
      OMAPDSS: store overlays in a list for each manager · 07e327c9
      Tomi Valkeinen 提交于
      Current way of handling overlay-manager links is a bit strange: each
      manager has a static array, containing pointers to all the overlays
      (even those used by other managers). The overlays contain a pointer to
      the manager being used.
      
      This patch makes the system a bit saner: each manager has a linked list
      of overlays, and only the overlays linked to that manager are in the
      list.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      07e327c9
    • T
      OMAPDSS: store overlays in an array · 58452341
      Tomi Valkeinen 提交于
      Overlays are stored in a linked list. There's no need for this list, as
      an array would do just as fine.
      
      This patch changes the code to use an array for overlays.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      58452341
    • T
      OMAPDSS: remove unneeded dss_ovl_wait_for_go() · 550a8f64
      Tomi Valkeinen 提交于
      There's an unnecessary wrapper function, dss_ovl_wait_for_go(), which
      does nothing else than call dss_mgr_wait_for_go_ovl(). The
      dss_ovl_wait_for_go() function can be removed.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      550a8f64
    • T
      OMAPDSS: remove L4_EXAMPLE code · b952b553
      Tomi Valkeinen 提交于
      Some old example code has been left lying around. Remove the example
      code.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      b952b553
  7. 03 10月, 2011 2 次提交
    • A
      OMAPDSS: DISPC: zorder support for DSS overlays · 54128701
      Archit Taneja 提交于
      Add zorder support on OMAP4, this feature allows deciding the visibility order
      of the overlays based on the zorder value provided as an overlay info parameter
      or a sysfs attribute of the overlay object.
      
      Use the overlay cap OMAP_DSS_OVL_CAP_ZORDER to determine whether zorder is
      supported for the overlay or not. Use dss feature FEAT_ALPHA_FREE_ZORDER
      if the caps are not available.
      
      Ensure that all overlays that are enabled and connected to the same manager
      have different zorders. Swapping zorders of 2 enabled overlays currently
      requires disabling one of the overlays.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      54128701
    • A
      OMAPDSS: DISPC: VIDEO3 pipeline support · b8c095b4
      Archit Taneja 提交于
      Add support for VIDEO3 pipeline on OMAP4:
      - Add VIDEO3 pipeline information in dss_features and omapdss.h
      - Add VIDEO3 pipeline register coefficients in dispc.h
      - Create a new overlay structure corresponding to VIDEO3.
      - Make changes in dispc.c for VIDEO3
      Signed-off-by: NArchit Taneja <archit@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      b8c095b4
  8. 30 9月, 2011 5 次提交
  9. 25 7月, 2011 1 次提交
  10. 01 7月, 2011 1 次提交
  11. 11 5月, 2011 3 次提交
  12. 16 3月, 2011 1 次提交
  13. 11 3月, 2011 1 次提交
  14. 10 1月, 2011 2 次提交
  15. 23 10月, 2010 1 次提交
  16. 05 8月, 2010 1 次提交
  17. 30 3月, 2010 1 次提交
    • T
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      Tejun Heo 提交于
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
      
      percpu.h is included by sched.h and module.h and thus ends up being
      included when building most .c files.  percpu.h includes slab.h which
      in turn includes gfp.h making everything defined by the two files
      universally available and complicating inclusion dependencies.
      
      percpu.h -> slab.h dependency is about to be removed.  Prepare for
      this change by updating users of gfp and slab facilities include those
      headers directly instead of assuming availability.  As this conversion
      needs to touch large number of source files, the following script is
      used as the basis of conversion.
      
        http://userweb.kernel.org/~tj/misc/slabh-sweep.py
      
      The script does the followings.
      
      * Scan files for gfp and slab usages and update includes such that
        only the necessary includes are there.  ie. if only gfp is used,
        gfp.h, if slab is used, slab.h.
      
      * When the script inserts a new include, it looks at the include
        blocks and try to put the new include such that its order conforms
        to its surrounding.  It's put in the include block which contains
        core kernel includes, in the same order that the rest are ordered -
        alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
        doesn't seem to be any matching order.
      
      * If the script can't find a place to put a new include (mostly
        because the file doesn't have fitting include block), it prints out
        an error message indicating which .h file needs to be added to the
        file.
      
      The conversion was done in the following steps.
      
      1. The initial automatic conversion of all .c files updated slightly
         over 4000 files, deleting around 700 includes and adding ~480 gfp.h
         and ~3000 slab.h inclusions.  The script emitted errors for ~400
         files.
      
      2. Each error was manually checked.  Some didn't need the inclusion,
         some needed manual addition while adding it to implementation .h or
         embedding .c file was more appropriate for others.  This step added
         inclusions to around 150 files.
      
      3. The script was run again and the output was compared to the edits
         from #2 to make sure no file was left behind.
      
      4. Several build tests were done and a couple of problems were fixed.
         e.g. lib/decompress_*.c used malloc/free() wrappers around slab
         APIs requiring slab.h to be added manually.
      
      5. The script was run on all .h files but without automatically
         editing them as sprinkling gfp.h and slab.h inclusions around .h
         files could easily lead to inclusion dependency hell.  Most gfp.h
         inclusion directives were ignored as stuff from gfp.h was usually
         wildly available and often used in preprocessor macros.  Each
         slab.h inclusion directive was examined and added manually as
         necessary.
      
      6. percpu.h was updated not to include slab.h.
      
      7. Build test were done on the following configurations and failures
         were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
         distributed build env didn't work with gcov compiles) and a few
         more options had to be turned off depending on archs to make things
         build (like ipr on powerpc/64 which failed due to missing writeq).
      
         * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
         * powerpc and powerpc64 SMP allmodconfig
         * sparc and sparc64 SMP allmodconfig
         * ia64 SMP allmodconfig
         * s390 SMP allmodconfig
         * alpha SMP allmodconfig
         * um on x86_64 SMP allmodconfig
      
      8. percpu.h modifications were reverted so that it could be applied as
         a separate patch and serve as bisection point.
      
      Given the fact that I had only a couple of failures from tests on step
      6, I'm fairly confident about the coverage of this conversion patch.
      If there is a breakage, it's likely to be something in one of the arch
      headers which should be easily discoverable easily on most builds of
      the specific arch.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
      5a0e3ad6
  18. 08 3月, 2010 1 次提交
  19. 24 2月, 2010 1 次提交
  20. 09 12月, 2009 1 次提交