1. 10 6月, 2014 1 次提交
  2. 02 6月, 2014 9 次提交
  3. 04 4月, 2014 1 次提交
  4. 23 3月, 2014 9 次提交
  5. 20 3月, 2014 1 次提交
  6. 07 2月, 2014 1 次提交
  7. 07 1月, 2014 1 次提交
  8. 18 12月, 2013 1 次提交
  9. 02 12月, 2013 1 次提交
    • I
      drm/exynos: release unhandled page flip events at postclose. · 0cbc330e
      Inki Dae 提交于
      This patch resolves a dead lock issue that could be incurred when
      exynos_drm_crtc_dpms function was called.
      
      The exynos_drm_crtc_dpms function waits for the completion of pended
      page flip events. However, preclose callback - this releases all unhandled
      page flip events - is called prior to the exynos_drm_crtc_dpms function call
      when drm is closed. So at this time, this will make the exynos_drm_crtc_dpms
      to wait infiniately for the completion of the page flip events.
      
      This patch releases the unhandled page flip events at postclose instead
      of preclose so that exynos_drm_crtc_dpms function can be waked up.
      
      Changelog v2:
      - fix a memory leak when drm is closed.
        . it has a memory leak when a requeste page flip is handled after
          drm_events_release() is called and before drm_fb_release()
          is called. At this time, a drm_pending_event will not be freed.
          So also this chage releases the drm_pending_event at postclose().
          And it calls drm_vblank_put() for pair if there is any unhandled page
          flip event.
      Signed-off-by: NInki Dae <inki.dae@samsung.com>
      Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
      0cbc330e
  10. 31 10月, 2013 1 次提交
  11. 09 10月, 2013 1 次提交
    • D
      drm: kill ->gem_init_object() and friends · 16eb5f43
      David Herrmann 提交于
      All drivers embed gem-objects into their own buffer objects. There is no
      reason to keep drm_gem_object_alloc(), gem->driver_private and
      ->gem_init_object() anymore.
      
      New drivers are highly encouraged to do the same. There is no benefit in
      allocating gem-objects separately.
      
      Cc: Dave Airlie <airlied@gmail.com>
      Cc: Alex Deucher <alexdeucher@gmail.com>
      Cc: Daniel Vetter <daniel@ffwll.ch>
      Cc: Jerome Glisse <jglisse@redhat.com>
      Cc: Rob Clark <robdclark@gmail.com>
      Cc: Inki Dae <inki.dae@samsung.com>
      Cc: Ben Skeggs <skeggsb@gmail.com>
      Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
      Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
      Acked-by: NAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      16eb5f43
  12. 05 9月, 2013 1 次提交
  13. 07 8月, 2013 2 次提交
  14. 04 7月, 2013 1 次提交
  15. 28 6月, 2013 1 次提交
  16. 29 4月, 2013 2 次提交
  17. 04 1月, 2013 2 次提交
  18. 15 12月, 2012 4 次提交
    • E
      drm/exynos: add gsc ipp driver · f2646380
      Eunchul Kim 提交于
      This patch adds IPP subsystem-based gsc driver for exynos5 series.
      GSC is stand for General SCaler and supports the following features:
      - image scaler/rotator/crop/flip/csc and input/output DMA operations.
      - image rotation and image effect functions.
      - writeback and display output operations.
      - M2M operation to crop, scale, rotation and csc.
      
      The below is GSC hardware path:
      Memory------->GSC------>Memory
      FIMD--------->GSC------>HDMI
      FIMD--------->GSC------>Memory
      Memory------->GSC------>FIMD, Mixer
      
      This driver is registered to IPP subsystem framework to be used by user side
      and user can control the GSC hardware through some interfaces of IPP subsystem
      framework.
      
      Changelog v1 ~ v5:
      - added comments, code fixups and cleanups.
      Signed-off-by: NEunchul Kim <chulspro.kim@samsung.com>
      Signed-off-by: NJinyoung Jeon <jy0.jeon@samsung.com>
      Signed-off-by: NInki Dae <inki.dae@samsung.com>
      Signed-off-by: NKyungmin.park <kyungmin.park@samsung.com>
      f2646380
    • E
      drm/exynos: add rotator ipp driver · bea8a429
      Eunchul Kim 提交于
      This patch adds IPP subsystem-based rotator driver.
      And Rotator supports the following features.
      - Image crop operation support.
      - Rotate operation support to 90, 180 or 270 degree.
      - Flip operation support to vertical, horizontal or both.
        . as limitaions, the pixel format to source buffer should be
          same as the one to destination buffer and no scaler.
      
      This driver is registered to IPP subsystem framework to be used by user side
      and user can control the Rotator hardware through some interfaces of IPP
      subsystem framework.
      
      Changelog v6:
      - fix build warning.
      
      Changelog v1 ~ v5:
      - added comments, code fixups and cleanups.
      Signed-off-by: NEunchul Kim <chulspro.kim@samsung.com>
      Signed-off-by: NYoungjun Cho <yj44.cho@samsung.com>
      Signed-off-by: NInki Dae <inki.dae@samsung.com>
      Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
      bea8a429
    • E
      drm/exynos: add fimc ipp driver · 16102edb
      Eunchul Kim 提交于
      FIMC is stand for Fully Interfactive Mobile Camera and
      supports image scaler/rotator/crop/flip/csc and input/output DMA operations
      and also supports writeback and display output operations.
      
      This driver is registered to IPP subsystem framework to be used by user side
      and user can control the FIMC hardware through some interfaces of IPP subsystem
      framework.
      
      Changelog v6:
      - fix build warning.
      
      Changelog v1 ~ v5:
      - add comments, code fixups and cleanups.
      Signed-off-by: NEunchul Kim <chulspro.kim@samsung.com>
      Signed-off-by: NJinyoung Jeon <jy0.jeon@samsung.com>
      Signed-off-by: NInki Dae <inki.dae@samsung.com>
      Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
      16102edb
    • E
      drm/exynos: add ipp subsystem · cb471f14
      Eunchul Kim 提交于
      This patch adds Image Post Processing(IPP) support for exynos drm driver.
      
      IPP supports image scaler/rotator and input/output DMA operations
      using IPP subsystem framework to control FIMC, Rotator and GSC hardware
      and supports some user interfaces for user side.
      
      And each IPP-based drivers support Memory to Memory operations
      with various converting. And in case of FIMC hardware, it also supports
      Writeback and Display output operations through local path.
      
      Features:
      - Memory to Memory operation support.
      - Various pixel formats support.
      - Image scaling support.
      - Color Space Conversion support.
      - Image crop operation support.
      - Rotate operation support to 90, 180 or 270 degree.
      - Flip operation support to vertical, horizontal or both.
      - Writeback operation support to display blended image of FIMD fifo on screen
      
      A summary to IPP Subsystem operations:
      First of all, user should get property capabilities from IPP subsystem
      and set these properties to hardware registers for desired operations.
      The properties could be pixel format, position, rotation degree and
      flip operation.
      
      And next, user should set source and destination buffer data using
      DRM_EXYNOS_IPP_QUEUE_BUF ioctl command with gem handles to source and
      destinition buffers.
      
      And next, user can control user-desired hardware with desired operations
      such as play, stop, pause and resume controls.
      
      And finally, user can aware of dma operation completion and also get
      destination buffer that it contains user-desried result through dequeue
      command.
      
      IOCTL commands:
      - DRM_EXYNOS_IPP_GET_PROPERTY
        . get ipp driver capabilitis and id.
      - DRM_EXYNOS_IPP_SET_PROPERTY
        . set format, position, rotation, flip to source and destination buffers
      - DRM_EXYNOS_IPP_QUEUE_BUF
        . enqueue/dequeue buffer and make event list.
      - DRM_EXYNOS_IPP_CMD_CTRL
        . play/stop/pause/resume control.
      
      Event:
      - DRM_EXYNOS_IPP_EVENT
        . a event to notify dma operation completion to user side.
      
      Basic control flow:
      Open -> Get properties -> User choose desired IPP sub driver(FIMC, Rotator
      or GSCALER) -> Set Property -> Create gem handle -> Enqueue to source and
      destination buffers -> Command control(Play) -> Event is notified to User
      -> User gets destinition buffer complated -> (Enqueue to source and
      destination buffers -> Event is notified to User) * N -> Queue/Dequeue to
      source and destination buffers -> Command control(Stop) -> Free gem handle
      -> Close
      
      Changelog v1 ~ v5:
      - added comments, code fixups and cleanups.
      Signed-off-by: NEunchul Kim <chulspro.kim@samsung.com>
      Signed-off-by: NJinyoung Jeon <jy0.jeon@samsung.com>
      Signed-off-by: NInki Dae <inki.dae@samsung.com>
      Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
      cb471f14