1. 15 8月, 2017 5 次提交
  2. 02 6月, 2017 4 次提交
  3. 03 4月, 2017 2 次提交
    • J
      drm/omap: Rename enum omap_plane to enum omap_plane_id · 864050c7
      Jyri Sarha 提交于
      The enum omap_plane conflicted with the same struct name for omapdrm
      plane private data. This rename should solve the conflict.
      
      The rename was implement with this very simple coccinelle patch:
      ------------------------
      @@
      @@
      enum
      -omap_plane
      +omap_plane_id
      ------------------------
      The patch was applied like this:
      spatch --sp-file <cocci_file> --all-includes --in-place --dir drivers/gpu/drm/omapdrm
      
      The above patch did not rename the actual enum definition. That was
      added manually on top of the spatch changes.
      Signed-off-by: NJyri Sarha <jsarha@ti.com>
      Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      864050c7
    • T
      drm/omap: move dispc related dss-feat funcs to dispc · c283400a
      Tomi Valkeinen 提交于
      omapdrm still uses a few non-dispc functions: dss_feat_get_num_mgrs(),
      dss_feat_get_num_ovls() and  dss_feat_get_supported_color_modes(). We
      want to provide omapdrm a single dispc_ops function pointer struct so
      that omapdrm will use either the current omapdss or the new omapdss6
      driver depending on the platform.
      
      Those three functions are really dispc functions, but are located in the
      dss_features.c for legacy reasons.
      
      This patch adds similar functionss to the dispc, and changes omapdrm to
      use those new functions. Underneath the functions still call the
      functions from dss_feature.c.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      c283400a
  4. 20 5月, 2016 2 次提交
  5. 29 12月, 2015 3 次提交
  6. 12 11月, 2014 2 次提交
  7. 17 4月, 2014 1 次提交
  8. 30 12月, 2013 1 次提交
  9. 09 10月, 2013 1 次提交
    • A
      omapdss: HDMI: Use OMAP4 HDMI core functions directly and remove hdmi_ip_ops · 425f02fd
      Archit Taneja 提交于
      After removing wrapper, pll and phy funcs from ti_hdmi_4xxx_ip.c, we are left
      with OMAP4 HDMI core functions. Use these directly in hdmi.c rather than using
      hdmi_ip_ops. Rename the core functions with a 'hdmi4' suffix.
      
      We used to have hdmi_ip_ops so that one could support HDMI within a TI SoC which
      had a non-DSS display subsytem. This however never got put into use, and hence
      these ops aren't useful any more.
      
      The DT/hwmod information for hdmi doesn't split the address space according to
      the required sub blocks. Keep the address offset and size information in the
      driver for now. This will be removed when the driver gets the information
      correctly from DT/hwmod.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      425f02fd
  10. 07 12月, 2012 1 次提交
  11. 20 11月, 2012 1 次提交
  12. 16 10月, 2012 2 次提交
  13. 26 9月, 2012 2 次提交
    • A
      OMAPDSS: DISPC: Add writeback register offsets and dss features structs · 7a155be3
      Archit Taneja 提交于
      Since writeback has many overlay like properties, and most of it's registers are
      similar to that of overlays, it's possible to reuse most of the overlay related
      DISPC code for writeback when considering it as a plane. Writeback was added as
      a plane in the omap_plane field as OMAP_DSS_WB.
      
      Add the writeback register offsets in dispc.h, add minimal WB plane related info
      needed in dss_features. Add a function which returns the number of writeback
      pipelines an OMAP version has.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      7a155be3
    • A
      OMAPDSS: APPLY: Add manager set/unset output ops for omap_overlay_manager · 97f01b3a
      Archit Taneja 提交于
      Add set_output/unset_output ops for overlay managers, these form links between
      managers and outputs. Create a function in dss features which tell all the
      output instances that connect to a manager, use it when a manager tries to set
      an output. Add a constraint of not unsetting an output when the manager is
      enabled.
      
      Keep the omap_dss_device pointer and set/unset_device ops in overlay_manager for
      now to not break things. Keep the dss feature function get_supported_displays
      as it's used in some places. These will be removed later.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      97f01b3a
  14. 24 9月, 2012 3 次提交
  15. 08 9月, 2012 1 次提交
  16. 22 8月, 2012 1 次提交
  17. 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
  18. 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
  19. 23 4月, 2012 1 次提交
  20. 21 2月, 2012 2 次提交
  21. 25 1月, 2012 2 次提交
  22. 02 1月, 2012 1 次提交
    • C
      OMAPDSS: DISPC: Update Scaling Clock Logic · 7282f1b7
      Chandrabhanu Mahapatra 提交于
      Clock requirements for scaling in OMAP2, OMAP3 and OMAP4 are different. In
      OMAP2 and OMAP3 the required clock rate is a function of pixel clock, vertical
      downscale ratio and horizontal downscale ratio whereas in OMAP4 it is a
      function of pixel clock and horizontal downscale ratio only. Selection of 3-tap
      vs 5-tap coefficients depends on clock rate line buffer width in OMAP3 whereas
      in OMAP4 it is independent of clock rate and line buffer width. In OMAP2 3-tap
      for vertical and 5-tap for horizontal scaling is used. In OMAP4 5-tap is used
      both for horizontal and vertical scaling for better performance. Also, the
      number and width of line buffers differs in OMAP3 and OMAP4.
      
      So, clock functions have been fined tuned for OMAP3 and support has been added
      added for OMAP4. This code has been tested on OMAP2, OMAP3 and OMAP4, and
      scaling issues due to clock errors have been resolved.
      Signed-off-by: NChandrabhanu Mahapatra <cmahapatra@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      7282f1b7