[Openchrome-devel] [drm-openchrome]DRM driver for VIA IGPs branch master updated. aa74d1a0f99acb1f0f376aef2ae8d2826c9189ec

[James Simmons]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "DRM driver for VIA IGPs".

The branch, master has been updated
       via  aa74d1a0f99acb1f0f376aef2ae8d2826c9189ec (commit)
       via  e26a8da608fa8d4dd334ba1917fd0a93107ae11b (commit)
      from  74fbb65b73d9c7d6182459d167a1f0a58fa454e4 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit aa74d1a0f99acb1f0f376aef2ae8d2826c9189ec
Author: James Simmons <jsimmons at infradead.org>
Date:   Sat Feb 9 13:00:17 2013 -0500

    The start of basic fence handling. We have via_fence which is the object used to act as a barrier. Different classes of fences are handled by the hardware in very similiar ways. For these cases each of these fences will be mapped to the same via_fence_pool. The via_fence_pool handles the shared functionality that different types of fences have in common. Each pool itself supported different number of types of fences so to handle a specific type the via_fence_engine was created. An easy example of this is the DMA blit engine. We have a fence_pool to represent blits in general and for the fence pool we have 4 engines were each one represents a DMA channel that can be used. The reason a fence is mapped to a pool instead of a engine is this design allows a fence to map to different engines at the same time. Also note the way we handle sequencing is very different than other drivers. Most drivers handle ordering of the commands in a pipe line fashion were our driver does it in
  a more parallel fashion. With this approach the sequence number does not have to sequenctial. Also we don't have to worry about over flow of the next sequence number. The bonus is that hastables also preform better then list iternations as the number of items increases.

commit e26a8da608fa8d4dd334ba1917fd0a93107ae11b
Author: James Simmons <jsimmons at infradead.org>
Date:   Sat Jan 26 19:51:13 2013 -0500

    via_dmabuffer.h really is for dma blitting and not the command engine. Make drm_via_sg_info a structure.

-----------------------------------------------------------------------

Summary of changes:
 drivers/gpu/drm/via/Makefile        |    4 +-
 drivers/gpu/drm/via/via_dma.h       |  157 +++++++++++++++++++
 drivers/gpu/drm/via/via_dmabuffer.h |  158 -------------------
 drivers/gpu/drm/via/via_drv.h       |    3 +-
 drivers/gpu/drm/via/via_fence.c     |  282 +++++++++++++++++++++++++++++++++++
 drivers/gpu/drm/via/via_fence.h     |   99 ++++++++++++
 drivers/gpu/drm/via/via_h1_cmdbuf.c |   10 +-
 drivers/gpu/drm/via/via_h1_dma.c    |  177 ++++++++++------------
 drivers/gpu/drm/via/via_ttm.c       |    4 +-
 9 files changed, 627 insertions(+), 267 deletions(-)
 create mode 100644 drivers/gpu/drm/via/via_dma.h
 delete mode 100644 drivers/gpu/drm/via/via_dmabuffer.h
 create mode 100644 drivers/gpu/drm/via/via_fence.c
 create mode 100644 drivers/gpu/drm/via/via_fence.h


hooks/post-receive
-- 
DRM driver for VIA IGPs