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 <jsimm...@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 <jsimm...@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
_______________________________________________
Openchrome-devel mailing list
Openchrome-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/openchrome-devel
