FOSDEM2013: DevRoom or not?
On Fri, Sep 28, 2012 at 05:44:27PM +0200, Luc Verhaegen wrote: > > Final reminder: the deadline is tonight. > > So far there are three speakers who lined up, and my feeling is that > Matthieu and Marc lined up just so that the deadline and requirement > will be met. So only a single person is intending to come to fosdem and > has a topic he wants to talk about. > > Come on guys. Surely we can do better than that. > > Luc Verhaegen. After a bit of a scramble, we now have 7.5 speakers confirmed, and two pending budget/approval (which do not count towards the limit). I have therefor sent off the request to the organizers, there is little doubt that we will once again get a nice devroom next year :) We still have, i hope (depends on what the FOSDEM organizers have left for us), 6 slots fully open: first come first serve, and the earlier bird gets the nicer slot! Thanks all, especially those who stepped up already. Luc Verhaegen.
[PATCH libdrm 4/4] man: add drm-memory overview page
This adds an overview page that describes Dumb-Buffers, TTM and GEM. It
does not describe chipset-specific features. You should do that in the
driver-manpages.
Signed-off-by: David Herrmann
Reviewed-by: Jesse Barnes
---
man/Makefile.am| 9 +-
man/drm-memory.xml | 430 +
2 files changed, 437 insertions(+), 2 deletions(-)
create mode 100644 man/drm-memory.xml
diff --git a/man/Makefile.am b/man/Makefile.am
index ae02728..fb69c45 100644
--- a/man/Makefile.am
+++ b/man/Makefile.am
@@ -7,10 +7,14 @@
MANPAGES = \
drm.7 \
drm-kms.7 \
+ drm-memory.7 \
drmAvailable.3 \
drmHandleEvent.3 \
drmModeGetResources.3
-MANPAGES_ALIASES =
+MANPAGES_ALIASES = \
+ drm-mm.7 \
+ drm-gem.7 \
+ drm-ttm.7
XML_FILES = \
${patsubst %.1,%.xml,${patsubst %.3,%.xml,${patsubst
%.5,%.xml,${patsubst %.7,%.xml,$(MANPAGES)
@@ -32,7 +36,8 @@ XSLTPROC_FLAGS = \
XSLTPROC_PROCESS_MAN = \
$(AM_V_GEN)$(MKDIR_P) $(dir $@) && \
- $(XSLTPROC) -o $@ $(XSLTPROC_FLAGS)
http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl $<
+ $(XSLTPROC) -o $@ $(XSLTPROC_FLAGS)
http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl $< && \
+ $(SED) -i -e 's/^\.so \(.*\)\.\(.\)$$/\.so man\2\/\1\.\2/'
$(MANPAGES_ALIASES)
%.1: %.xml
$(XSLTPROC_PROCESS_MAN)
diff --git a/man/drm-memory.xml b/man/drm-memory.xml
new file mode 100644
index 000..6b4f075
--- /dev/null
+++ b/man/drm-memory.xml
@@ -0,0 +1,430 @@
+
+http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd";>
+
+
+
+
+
+Direct Rendering Manager
+libdrm
+September 2012
+
+
+Developer
+David
+Herrmann
+dh.herrmann at googlemail.com
+
+
+
+
+
+drm-memory
+7
+
+
+
+drm-memory
+drm-mm
+drm-gem
+drm-ttm
+DRM Memory Management
+
+
+
+
+ #include
+
+
+
+
+Description
+ Many modern high-end GPUs come with their own memory managers. They
+even include several different caches that need to be synchronized
+during access. Textures, framebuffers, command buffers and more
need
+to be stored in memory that can be accessed quickly by the GPU.
+Therefore, memory management on GPUs is highly driver- and
+hardware-dependent.
+
+ However, there are several frameworks in the kernel that are used
by
+more than one driver. These can be used for trivial mode-setting
+without requiring driver-dependent code. But for
+hardware-accelerated rendering you need to read the manual pages
for
+the driver you want to work with.
+
+
+ Dumb-Buffers
+ Almost all in-kernel DRM hardware drivers support an API called
+Dumb-Buffers. This API allows to create
buffers
+of arbitrary size that can be used for scanout. These buffers can
be
+memory mapped via
+
mmap2
+so you can render into them on the CPU. However, GPU access to
these
+buffers is often not possible. Therefore, they are fine for simple
+tasks but not suitable for complex compositions and
+renderings.
+
+ The DRM_IOCTL_MODE_CREATE_DUMB ioctl can be
+used to create a dumb buffer. The kernel will return a 32bit handle
+that can be used to manage the buffer with the DRM API. You can
+create framebuffers with
+
drmModeAddFB3
+and use it for mode-setting and scanout. To access the buffer, you
+first need to retrieve the offset of the buffer. The
+DRM_IOCTL_MODE_MAP_DUMB ioctl requests the DRM
+subsystem to prepare the buffer for memory-mapping and returns a
+fake-offset that can be used with
+
mmap2.
+
+ The DRM_IOCTL_MODE_CREATE_DUMB ioctl takes as
+argument a structure of type
+struct drm_mode_create_dumb:
+
+
+struct drm_mode_create_dumb {
+ __u32 height;
+ __u32 width;
+ __u32 bpp;
+ __u32 flags;
+
+ __u32 handle;
+ __u32 pitch;
+ __u64 size;
+};
+
+
+The fields height,
+width, bpp
and
+flags have to be provided by the caller.
+The other fields are filled by the kernel with the return values.
+height and
+width are the dimensions of the
+rectangular buffer that is created. bpp
+is the number of bits-per-pixel and must be a multiple of
+8. You most commonly want to pass
+32 here. The flags
+field is currently unused and must be zeroed. Different flags to
+modify the behavior may be added in the future. After calling the
+ioctl, the handle,
+pitch and
size
[PATCH libdrm 3/4] man: add drm-kms overview page
This is an overview page for KMS. It is again targeted at novice users that need redirection to the correct function man-pages. Signed-off-by: David Herrmann Reviewed-by: Jesse Barnes --- man/Makefile.am | 1 + man/drm-kms.xml | 342 2 files changed, 343 insertions(+) create mode 100644 man/drm-kms.xml diff --git a/man/Makefile.am b/man/Makefile.am index d55f444..ae02728 100644 --- a/man/Makefile.am +++ b/man/Makefile.am @@ -6,6 +6,7 @@ MANPAGES = \ drm.7 \ + drm-kms.7 \ drmAvailable.3 \ drmHandleEvent.3 \ drmModeGetResources.3 diff --git a/man/drm-kms.xml b/man/drm-kms.xml new file mode 100644 index 000..5f04157 --- /dev/null +++ b/man/drm-kms.xml @@ -0,0 +1,342 @@ + +http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd";> + + + + + +Direct Rendering Manager +libdrm +September 2012 + + +Developer +David +Herrmann +dh.herrmann at googlemail.com + + + + + +drm-kms +7 + + + +drm-kms +Kernel Mode-Setting + + + + + #include+ #include + + + + +Description +Each DRM device provides access to manage which monitors and displays + are currently used and what frames to be displayed. This task is + called Kernel Mode-Setting (KMS). Historically, + this was done in user-space and called + User-space Mode-Setting (UMS). Almost all + open-source drivers now provide the KMS kernel API to do this in the + kernel, however, many non-open-source binary drivers from different + vendors still do not support this. You can use + drmModeSettingSupported3 + to check whether your driver supports this. To understand how KMS + works, we need to introduce 5 objects: CRTCs, + Planes, Encoders, + Connectors and + Framebuffers. + + + + CRTCs + +A CRTC short for + CRT Controller is an abstraction + representing a part of the chip that contains a pointer to a + scanout buffer. Therefore, the number of CRTCs available + determines how many independent scanout buffers can be active + at any given time. The CRTC structure contains several fields + to support this: a pointer to some video memory (abstracted as + a frame-buffer object), a list of driven connectors, a display + mode and an (x, y) offset into the video memory to support + panning or configurations where one piece of video memory + spans multiple CRTCs. A CRTC is the central point where + configuration of displays happens. You select which objects to + use, which modes and which parameters and then configure each + CRTC via + drmModeCrtcSet3 + to drive the display devices. + + + + Planes + +A plane respresents an image source that + can be blended with or overlayed on top of a CRTC during the + scanout process. Planes are associated with a frame-buffer to + crop a portion of the image memory (source) and optionally + scale it to a destination size. The result is then blended + with or overlayed on top of a CRTC. Planes are not provided by + all hardware and the number of available planes is limited. If + planes are not available or if not enough planes are + available, the user should fall back to normal software + blending (via GPU or CPU). + + + + Encoders + +An encoder takes pixel data from a CRTC + and converts it to a format suitable for any attached + connectors. On some devices, it may be possible to have a CRTC + send data to more than one encoder. In that case, both + encoders would receive data from the same scanout buffer, + resulting in a cloned display + configuration across the connectors attached to each + encoder. + + + + Connectors + +A connector is the final destination of + pixel-data on a device, and usually connects directly to an + external display device like a monitor or laptop panel. A + connector can only be attached to one encoder at a time. The + connector is also the structure where information about the + attached display is kept, so it contains fields for
[PATCH libdrm 2/4] man: add drm.7 overview page
The drm.xml file compiles to drm.7 and is meant as a global overview page for libdrm. It is targeted to new users of libdrm and redirects to all other main man-pages. Signed-off-by: David Herrmann Reviewed-by: Jesse Barnes --- man/Makefile.am | 1 + man/drm.xml | 137 2 files changed, 138 insertions(+) create mode 100644 man/drm.xml diff --git a/man/Makefile.am b/man/Makefile.am index 3030e5f..d55f444 100644 --- a/man/Makefile.am +++ b/man/Makefile.am @@ -5,6 +5,7 @@ # MANPAGES = \ + drm.7 \ drmAvailable.3 \ drmHandleEvent.3 \ drmModeGetResources.3 diff --git a/man/drm.xml b/man/drm.xml new file mode 100644 index 000..5a49fe1 --- /dev/null +++ b/man/drm.xml @@ -0,0 +1,137 @@ + +http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd";> + + + + + +Direct Rendering Manager +libdrm +September 2012 + + +Developer +David +Herrmann +dh.herrmann at googlemail.com + + + + + +drm +7 + + + +drm +Direct Rendering Manager + + + + + #include+ + + + +Description +The Direct Rendering Manager (DRM) is a framework + to manage Graphics Processing Units (GPUs). It is + designed to support the needs of complex graphics devices, usually + containing programmable pipelines well suited to 3D graphics + acceleration. Furthermore, it is responsible for memory management, + interrupt handling and DMA to provide a uniform interface to + applications. + +In earlier days, the kernel framework was solely used to provide raw + hardware access to priviledged user-space processes which implement + all the hardware abstraction layers. But more and more tasks where + moved into the kernel. All these interfaces are based on + ioctl2 + commands on the DRM character device. The libdrm + library provides wrappers for these system-calls and many helpers to + simplify the API. + +When a GPU is detected, the DRM system loads a driver for the detected + hardware type. Each connected GPU is then presented to user-space via + a character-device that is usually available as + /dev/dri/card0 and can be accessed with + open2 + and + close2. + However, it still depends on the grapics driver which interfaces are + available on these devices. If an interface is not available, the + syscalls will fail with EINVAL. + + + Authentication + All DRM devices provide authentication mechanisms. Only a DRM-Master +is allowed to perform mode-setting or modify core state and only one +user can be DRM-Master at a time. See + drmSetMaster3 +for information on how to become DRM-Master and what the limitations +are. Other DRM users can be authenticated to the DRM-Master via + drmAuthMagic3 +so they can perform buffer allocations and rendering. + + + + Mode-Setting + Managing connected monitors and displays and changing the current +modes is called Mode-Setting. This is +restricted to the current DRM-Master. Historically, this was +implemented in user-space, but new DRM drivers implement a kernel +interface to perform mode-setting called +Kernel Mode Setting (KMS). If your +hardware-driver supports it, you can use the KMS API provided by +DRM. This includes allocating framebuffers, selecting modes and +managing CRTCs and encoders. See + drm-kms7 +for more. + + + + Memory Management + The most sophisticated tasks for GPUs today is managing memory +objects. Textures, framebuffers, command-buffers and all other kinds +of commands for the GPU have to be stored in memory. The DRM driver +takes care of managing all memory objects, flushing caches, +synchronizing access and providing CPU access to GPU memory. All +memory management is hardware driver dependent. However, two generic +frameworks are available that are used by most DRM drivers. These +are the Translation Table Manager (TTM) and the +Graphics Execution Manager (GEM). They provide +generic APIs to create, destroy and access buffers from user-space. +However, there are still many differences between the drivers so +driver-depedent code is still needed. Many helpers are provided in +libgbm (Graphics Buffer Manager) from the +mesa-project. For more information on DRM +memory-management, see + drm-memory7. + + + + +Reporting Bugs +B
[PATCH libdrm 1/4] man: convert manpages to XML instead of plain troff
If we want to use the manpages in external documentation other than normal
manpages, we should rather use XML. Furthermore, almost no-one knows troff
today, anyway, and XML allows others to easily add more pages without
having to learn troff.
Signed-off-by: David Herrmann
---
.gitignore | 4 ++
configure.ac| 24 +---
man/Makefile.am | 58 ++
man/drmAvailable.man| 25
man/drmAvailable.xml| 75
man/drmHandleEvent.man | 45 --
man/drmHandleEvent.xml | 102
man/drmModeGetResources.man | 79 -
man/drmModeGetResources.xml | 139
9 files changed, 370 insertions(+), 181 deletions(-)
delete mode 100644 man/drmAvailable.man
create mode 100644 man/drmAvailable.xml
delete mode 100644 man/drmHandleEvent.man
create mode 100644 man/drmHandleEvent.xml
delete mode 100644 man/drmModeGetResources.man
create mode 100644 man/drmModeGetResources.xml
diff --git a/.gitignore b/.gitignore
index 243457e..d297f94 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,5 +1,9 @@
bsd-core/*/@
bsd-core/*/machine
+*.1
+*.3
+*.5
+*.7
*.flags
*.ko
*.ko.cmd
diff --git a/configure.ac b/configure.ac
index 290362c..7fd7f11 100644
--- a/configure.ac
+++ b/configure.ac
@@ -35,27 +35,6 @@ AM_MAINTAINER_MODE([enable])
# Enable quiet compiles on automake 1.11.
m4_ifdef([AM_SILENT_RULES], [AM_SILENT_RULES([yes])])
-if test x$LIB_MAN_SUFFIX = x; then
-LIB_MAN_SUFFIX=3
-fi
-if test x$LIB_MAN_DIR = x; then
-LIB_MAN_DIR='$(mandir)/man$(LIB_MAN_SUFFIX)'
-fi
-AC_SUBST([LIB_MAN_SUFFIX])
-AC_SUBST([LIB_MAN_DIR])
-
-MAN_SUBSTS="\
- -e 's|__vendorversion__|\"\$(PACKAGE_STRING)\" |' \
- -e 's|__projectroot__|\$(prefix)|g' \
- -e 's|__apploaddir__|\$(appdefaultdir)|g' \
- -e 's|__appmansuffix__|\$(APP_MAN_SUFFIX)|g' \
- -e 's|__drivermansuffix__|\$(DRIVER_MAN_SUFFIX)|g' \
- -e 's|__adminmansuffix__|\$(ADMIN_MAN_SUFFIX)|g' \
- -e 's|__libmansuffix__|\$(LIB_MAN_SUFFIX)|g' \
- -e 's|__miscmansuffix__|\$(MISC_MAN_SUFFIX)|g' \
- -e 's|__filemansuffix__|\$(FILE_MAN_SUFFIX)|g'"
-AC_SUBST([MAN_SUBSTS])
-
# Check for programs
AC_PROG_CC
@@ -235,6 +214,9 @@ if test "x$HAVE_LIBUDEV" = xyes; then
fi
AM_CONDITIONAL(HAVE_LIBUDEV, [test "x$HAVE_LIBUDEV" = xyes])
+AC_PATH_PROG(XSLTPROC, xsltproc)
+AM_CONDITIONAL([HAVE_XSLTPROC], [test "x$XSLTPROC" != "x"])
+
if test "x$INTEL" != "xno" -o "x$RADEON" != "xno" -o "x$NOUVEAU" != "xno" -o
"x$OMAP" != "xno"; then
# Check for atomic intrinsics
AC_CACHE_CHECK([for native atomic primitives], drm_cv_atomic_primitives,
diff --git a/man/Makefile.am b/man/Makefile.am
index 73068e6..3030e5f 100644
--- a/man/Makefile.am
+++ b/man/Makefile.am
@@ -1,11 +1,47 @@
-libmandir = $(LIB_MAN_DIR)
-libman_PRE = drmAvailable.man \
- drmHandleEvent.man \
- drmModeGetResources.man
-libman_DATA = $(libman_PRE:man=@LIB_MAN_SUFFIX@)
-EXTRA_DIST = $(libman_PRE)
-CLEANFILE = $(libman_DATA)
-SUFFIXES = .$(LIB_MAN_SUFFIX) .man
-
-.man.$(LIB_MAN_SUFFIX):
- $(AM_V_GEN)$(SED) $(MAN_SUBSTS) < $< > $@
+#
+# This generates man-pages out of the Docbook XML files. Simply add your files
+# to the $MANPAGES array. If aliases are created, please add them to the
+# MANPAGES_ALIASES array so they get installed correctly.
+#
+
+MANPAGES = \
+ drmAvailable.3 \
+ drmHandleEvent.3 \
+ drmModeGetResources.3
+MANPAGES_ALIASES =
+
+XML_FILES = \
+ ${patsubst %.1,%.xml,${patsubst %.3,%.xml,${patsubst
%.5,%.xml,${patsubst %.7,%.xml,$(MANPAGES)
+CLEANFILES =
+EXTRA_DIST =
+man_MANS =
+
+if HAVE_XSLTPROC
+
+CLEANFILES += $(MANPAGES) $(MANPAGES_ALIASES)
+EXTRA_DIST += $(MANPAGES) $(MANPAGES_ALIASES) $(XML_FILES)
+man_MANS += $(MANPAGES) $(MANPAGES_ALIASES)
+
+XSLTPROC_FLAGS = \
+ --stringparam man.authors.section.enabled 0 \
+ --stringparam man.copyright.section.enabled 0 \
+ --stringparam funcsynopsis.style ansi \
+ --stringparam man.output.quietly 1
+
+XSLTPROC_PROCESS_MAN = \
+ $(AM_V_GEN)$(MKDIR_P) $(dir $@) && \
+ $(XSLTPROC) -o $@ $(XSLTPROC_FLAGS)
http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl $<
+
+%.1: %.xml
+ $(XSLTPROC_PROCESS_MAN)
+
+%.3: %.xml
+ $(XSLTPROC_PROCESS_MAN)
+
+%.5: %.xml
+ $(XSLTPROC_PROCESS_MAN)
+
+%.7: %.xml
+ $(XSLTPROC_PROCESS_MAN)
+
+endif # HAVE_XSLTPROC
diff --git a/man/drmAvailable.man b/man/drmAvailable.man
deleted file mode 100644
index e1bb8dc..000
--- a/man/drmAvailable.man
+++ /dev/null
@@ -1,25 +0,0 @@
-.\" shorthand for double quote that works everywhere.
-.ds q \N'34'
-.TH drmAvailable __drivermansuffix__ __vendorversion__
-.SH NAME
-drmAvailable \- determine whether a DRM kernel driver has been loaded
-.SH SYNOPSIS
-.nf
-.B "#include "
-
-.B "int drmAvailable(void);"
-.fi
[PATCH libdrm 0/4] Manpages for libdrm
Hi This is revision 2 of the manpages for libdrm. I converted everything to docbook XML. This makes it easier to write them (troff is really hard to read) and allows us to integrate it into other documentation. Other than that I only fixed typos and the small corrections you guys mentioned. Thanks for reviewing! Regards David David Herrmann (4): man: convert manpages to XML instead of plain troff man: add drm.7 overview page man: add drm-kms overview page man: add drm-memory overview page .gitignore | 4 + configure.ac| 24 +-- man/Makefile.am | 65 +-- man/drm-kms.xml | 342 +++ man/drm-memory.xml | 430 man/drm.xml | 137 ++ man/drmAvailable.man| 25 --- man/drmAvailable.xml| 75 man/drmHandleEvent.man | 45 - man/drmHandleEvent.xml | 102 +++ man/drmModeGetResources.man | 79 man/drmModeGetResources.xml | 139 ++ 12 files changed, 1286 insertions(+), 181 deletions(-) create mode 100644 man/drm-kms.xml create mode 100644 man/drm-memory.xml create mode 100644 man/drm.xml delete mode 100644 man/drmAvailable.man create mode 100644 man/drmAvailable.xml delete mode 100644 man/drmHandleEvent.man create mode 100644 man/drmHandleEvent.xml delete mode 100644 man/drmModeGetResources.man create mode 100644 man/drmModeGetResources.xml -- 1.7.12.1
FOSDEM2013: DevRoom or not?
Hello, I believe that the audience at FOSDEM might be interested in a general course about the graphics infrastructure under Linux. What I have in mind would be a talk that explains : what's X, why do we need it, what is so special about 3D applications that you need a "driver" to run any of them (and who's this driver anyway), what's software rendering, HW acceleration, what is Mesa, what is a DRI driver, ... with examples aimed at making people understand not only *how* they are supposed to set up any new hardware they lay their hands upon, but why it works the way it does. Bonus points for a complete status report of current hardware support under Linux at the end. Perhaps I'm wrong but I think that would be a good way to reach out to a community of people who usually have a very, very limited grasp of what it is exactly that we are doing. (I'm including myself because it's easier to do so for the purpose of this e-mail) Would anyone be willing to do such a presentation? -- Greetings, A. Huillet
[PATCH 1/5] dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER
On 09/28/2012 09:42 PM, Thomas Hellstrom wrote: > On 09/28/2012 04:14 PM, Maarten Lankhorst wrote: >> Hey, >> >> Op 28-09-12 14:41, Maarten Lankhorst schreef: >>> Documentation says that code requiring dma-buf should add it to >>> select, so inline fallbacks are not going to be used. A link error >>> will make it obvious what went wrong, instead of silently doing >>> nothing at runtime. >>> >> >> >> The whole patch series is in my tree, I use stg so things might >> move around, do not use for merging currently: >> >> http://cgit.freedesktop.org/~mlankhorst/linux/log/?h=v10-wip >> >> It contains everything in here plus the patches for ttm to make >> it work, I use a old snapshot of drm-next + merge of nouveau as >> base. Description of what the parts do: >> >> Series to fix small api issues when moving over: >> >> drm/ttm: Remove cpu_writers related code >> drm/ttm: Add ttm_bo_is_reserved function >> drm/radeon: Use ttm_bo_is_reserved >> drm/vmwgfx: use ttm_bo_is_reserved >> >> drm/vmwgfx: remove use of fence_obj_args >> drm/ttm: remove sync_obj_arg >> drm/ttm: remove sync_obj_arg from ttm_bo_move_accel_cleanup >> drm/ttm: remove sync_arg entirely >> >> drm/nouveau: unpin buffers before releasing to prevent lockdep warnings >> drm/nouveau: add reservation to nouveau_bo_vma_del >> drm/nouveau: add reservation to nouveau_gem_ioctl_cpu_prep >> >> Hey great, now we only have one user left for fence waiting before >> reserving, >> lets fix that and remove fence lock: >> ttm_bo_cleanup_refs_or_queue and ttm_bo_cleanup_refs have to reserve >> before >> waiting, lets do it in the squash commit so we don't have to throw >> lock order >> around everywhere: >> >> drm/ttm: remove fence_lock >> >> -- Up to this point should be mergeable now >> >> Then we start working on lru_lock removal slightly, this means the lru >> list no longer is empty but can contain only reserved buffers: >> >> drm/ttm: do not check if list is empty in ttm_bo_force_list_clean >> drm/ttm: move reservations for ttm_bo_cleanup_refs >> >> -- Still mergeable up to this point, just fixes >> >> Patch series from this email: >> dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER >> fence: dma-buf cross-device synchronization (v9) >> seqno-fence: Hardware dma-buf implementation of fencing (v3) >> reservation: cross-device reservation support >> reservation: Add lockdep annotation and selftests >> >> Now hook it up to drm/ttm in a few steps: >> usage around reservations: >> drm/ttm: make ttm reservation calls behave like reservation calls >> drm/ttm: use dma_reservation api >> dma-buf: use reservations >> drm/ttm: allow drivers to pass custom dma_reservation_objects for a bo >> >> then kill off the lru lock around reservation: >> drm/ttm: remove lru_lock around ttm_bo_reserve >> drm/ttm: simplify ttm_eu_* >> >> The lru_lock removal patch removes the lock around lru_lock around the >> reservation, this will break the assumption that items on the lru list >> and swap list can always be reserved, and this gets patched up too. >> Is there any part in ttm you disagree with? I believe that this >> is all mergeable, the lru_lock removal patch could be moved to before >> the reservation parts, this might make merging easier, but I don't >> think there is any ttm part of the series that are wrong on a conceptual >> level. >> >> ~Maarten >> > From another email > >>> As previously discussed, I'm unfortunately not prepared to accept >>> removal of the reserve-lru atomicity >>> into the TTM code at this point. >>> The current code is based on this assumption and removing it will >>> end up with >>> efficiencies, breaking the delayed delete code and probably a >>> locking nightmare when trying to write >>> new TTM code. >> The lru lock removal patch fixed the delayed delete code, it really >> is not different from the current >> situation. In fact it is more clear without the guarantee what >> various parts are trying to protect. >> >> Nothing prevents you from holding the lru_lock while trylocking, > [1] > While this would not cause any deadlocks, Any decent lockdep code > would establish lru->reserve as the locking > order once a lru- reserve trylock succeeds, but the locking order is > really reserve->lru for obvious reasons, which > means we will get a lot of lockdep errors? Yes, there are a two > reversals like these already in the TTM code, and I'm > not very proud of them. > > leaving that guarantee intact for that part. Can you really just review > the patch and tell me where it breaks and/or makes the code unreadable? > > OK. Now I'm looking at > http://cgit.freedesktop.org/~mlankhorst/linux/tree/drivers/gpu/drm/ttm/ttm_bo.c?h=v10-wip&id=1436e2e64697c744d6e186618448e1e6354846bb > > > > And let's start with a function that's seen some change, > ttm_mem_evict_first: > > *) Line 715: You're traversing a list using list_for_each() calling a > function that may remove the list entry > *) Line 722: You're unlocking the lock protecting t
[Intel-gfx] [PATCH 3/3] drm/i915: Add HDMI vendor info frame support
On Thu, Sep 27, 2012 at 3:41 PM, Damien Lespiau
wrote:
> From: Damien Lespiau
>
> When scanning out a 3D framebuffer, send the corresponding infoframe to
> the HDMI sink.
>
> See http://www.hdmi.org/manufacturer/specification.aspx for details.
>
> Signed-off-by: Damien Lespiau
> ---
> drivers/gpu/drm/i915/intel_drv.h | 14 +++
> drivers/gpu/drm/i915/intel_hdmi.c | 49
> +-
> drivers/gpu/drm/i915/intel_modes.c | 12 ++
> 3 files changed, 74 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index cd54cf8..c326d30e 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -263,6 +263,13 @@ struct cxsr_latency {
> #define DIP_SPD_BD 0xa
> #define DIP_SPD_SCD0xb
>
> +#define DIP_TYPE_VENDOR0x81
> +#define DIP_VERSION_VENDOR 0x1
> +#define DIP_HDMI_3D_PRESENT(0x2<<5)
> +#define DIP_HDMI_3D_STRUCT_FP (0x0<<4)
> +#define DIP_HDMI_3D_STRUCT_TB (0x6<<4)
> +#define DIP_HDMI_3D_STRUCT_SBSH(0x8<<4)
> +
> struct dip_infoframe {
> uint8_t type; /* HB0 */
> uint8_t ver;/* HB1 */
> @@ -292,6 +299,12 @@ struct dip_infoframe {
> uint8_t pd[16];
> uint8_t sdi;
> } __attribute__ ((packed)) spd;
> + struct {
> + uint8_t vendor_id[3];
> + uint8_t video_format;
> + uint8_t s3d_struct;
> + uint8_t s3d_ext_data;
> + } __attribute__ ((packed)) hdmi;
> uint8_t payload[27];
> } __attribute__ ((packed)) body;
> } __attribute__((packed));
> @@ -348,6 +361,7 @@ int intel_ddc_get_modes(struct drm_connector *c, struct
> i2c_adapter *adapter);
>
> extern void intel_attach_force_audio_property(struct drm_connector
> *connector);
> extern void intel_attach_broadcast_rgb_property(struct drm_connector
> *connector);
> +extern void intel_attach_expose_3d_modes_property(struct drm_connector
> *connector);
>
> extern void intel_crt_init(struct drm_device *dev);
> extern void intel_hdmi_init(struct drm_device *dev, int sdvox_reg);
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 98f6024..2d51b7e 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -83,6 +83,8 @@ static u32 g4x_infoframe_index(struct dip_infoframe *frame)
> return VIDEO_DIP_SELECT_AVI;
> case DIP_TYPE_SPD:
> return VIDEO_DIP_SELECT_SPD;
> + case DIP_TYPE_VENDOR:
> + return VIDEO_DIP_SELECT_VENDOR;
> default:
> DRM_DEBUG_DRIVER("unknown info frame type %d\n", frame->type);
> return 0;
> @@ -96,6 +98,8 @@ static u32 g4x_infoframe_enable(struct dip_infoframe *frame)
> return VIDEO_DIP_ENABLE_AVI;
> case DIP_TYPE_SPD:
> return VIDEO_DIP_ENABLE_SPD;
> + case DIP_TYPE_VENDOR:
> + return VIDEO_DIP_ENABLE_VENDOR;
> default:
> DRM_DEBUG_DRIVER("unknown info frame type %d\n", frame->type);
> return 0;
> @@ -338,6 +342,42 @@ static void intel_hdmi_set_spd_infoframe(struct
> drm_encoder *encoder)
> intel_set_infoframe(encoder, &spd_if);
> }
>
> +static void intel_hdmi_set_hdmi_infoframe(struct drm_encoder *encoder,
> + struct drm_display_mode
> *adjusted_mode)
> +{
> + struct dip_infoframe hdmi_if;
> +
> + /* We really only need to send a HDMI vendor info frame when having
> +* a 3D format to describe */
> + if (!(adjusted_mode->flags & DRM_MODE_FLAG_3D_MASK))
> + return;
> +
> + memset(&hdmi_if, 0, sizeof(hdmi_if));
> + hdmi_if.type = DIP_TYPE_VENDOR;
> + hdmi_if.ver = DIP_VERSION_VENDOR;
> + /* HDMI IEEE registration id, least significant bit first */
> + hdmi_if.body.hdmi.vendor_id[0] = 0x03;
> + hdmi_if.body.hdmi.vendor_id[1] = 0x0c;
> + hdmi_if.body.hdmi.vendor_id[2] = 0x00;
> + hdmi_if.body.hdmi.video_format = DIP_HDMI_3D_PRESENT;
> + if (adjusted_mode->flags & DRM_MODE_FLAG_3D_FRAME_PACKING)
> + hdmi_if.body.hdmi.s3d_struct = DIP_HDMI_3D_STRUCT_FP;
> + else if (adjusted_mode->flags & DRM_MODE_FLAG_3D_TOP_BOTTOM)
> + hdmi_if.body.hdmi.s3d_struct = DIP_HDMI_3D_STRUCT_TB;
> + else if (adjusted_mode->flags & DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF)
> + hdmi_if.body.hdmi.s3d_struct = DIP_HDMI_3D_STRUCT_SBSH;
> + /* len is the payload len, not including checksum. Side by side (half)
> +* has an extra byte for 3D_Ext_Data */
> + if (adjusted_mode->flags & DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF) {
> + hdmi_if.len = 6;
> + /*
[PATCH 2/3] drm: Parse the HDMI cea vendor block for 3D present
Reviewed-by: Rodrigo Vivi
Tested-by: Rodrigo Vivi
On Thu, Sep 27, 2012 at 3:41 PM, Damien Lespiau
wrote:
> From: Damien Lespiau
>
> For now, let's just look at the 3D_present flag of the CEA HDMI vendor
> block to detect if the sink supports a small list of then mandatory 3D
> formats.
>
> See the HDMI 1.4a 3D extraction for detail:
> http://www.hdmi.org/manufacturer/specification.aspx
>
> Signed-off-by: Damien Lespiau
> ---
> drivers/gpu/drm/drm_edid.c | 87
> --
> include/drm/drm_mode.h | 35 +++
> 2 files changed, 105 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index b7ee230..7eecfa0 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1522,21 +1522,102 @@ do_cea_modes (struct drm_connector *connector, u8
> *db, u8 len)
> return modes;
> }
>
> +static bool cea_hdmi_3d_present(u8 *hdmi)
> +{
> + u8 len, skip = 0;
> +
> + len = hdmi[0] & 0x1f;
> +
> + if (len < 8)
> + return false;
> +
> + /* no HDMI_Video_present */
> + if (!(hdmi[8] & (1<<5)))
> + return false;
> +
> + /* Latency_fields_present */
> + if (hdmi[8] & (1 << 7))
> + skip += 2;
> +
> + /* I_Latency_fields_present */
> + if (hdmi[8] & (1 << 6))
> + skip += 2;
> +
> + /* the declared length is not long enough */
> + if (len < (9 + skip))
> + return false;
> +
> + return (hdmi[9 + skip] & (1 << 7)) != 0;
> +}
> +
> +static const struct {
> + int width, height, freq;
> + unsigned int select, value;
> + unsigned int formats;
> +} s3d_mandatory_modes[] = {
> + { 1920, 1080, 24, DRM_MODE_FLAG_INTERLACE, 0,
> + DRM_MODE_FLAG_3D_TOP_BOTTOM | DRM_MODE_FLAG_3D_FRAME_PACKING },
> + { 1920, 1080, 50, DRM_MODE_FLAG_INTERLACE, DRM_MODE_FLAG_INTERLACE,
> + DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF },
> + { 1920, 1080, 60, DRM_MODE_FLAG_INTERLACE, DRM_MODE_FLAG_INTERLACE,
> + DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF },
> + { 1280, 720, 50, DRM_MODE_FLAG_INTERLACE, 0,
> + DRM_MODE_FLAG_3D_TOP_BOTTOM | DRM_MODE_FLAG_3D_FRAME_PACKING },
> + { 1280, 720, 60, DRM_MODE_FLAG_INTERLACE, 0,
> + DRM_MODE_FLAG_3D_TOP_BOTTOM | DRM_MODE_FLAG_3D_FRAME_PACKING }
> +};
> +
> +static void cea_hdmi_patch_mandatory_3d_mode(struct drm_display_mode *mode)
> +{
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(s3d_mandatory_modes); i++) {
> + if (mode->hdisplay == s3d_mandatory_modes[i].width &&
> + mode->vdisplay == s3d_mandatory_modes[i].height &&
> + (mode->flags & s3d_mandatory_modes[i].select) ==
> + s3d_mandatory_modes[i].value &&
> + drm_mode_vrefresh(mode) == s3d_mandatory_modes[i].freq) {
> + mode->flags |= s3d_mandatory_modes[i].formats;
> + }
> + }
> +}
> +
> +static void cea_hdmi_patch_mandatory_3d_modes(struct drm_connector
> *connector)
> +{
> + struct drm_display_mode *mode;
> +
> + list_for_each_entry(mode, &connector->probed_modes, head)
> + cea_hdmi_patch_mandatory_3d_mode(mode);
> +}
> +
> static int
> add_cea_modes(struct drm_connector *connector, struct edid *edid)
> {
> u8 * cea = drm_find_cea_extension(edid);
> - u8 * db, dbl;
> - int modes = 0;
> + u8 * db, *hdmi = NULL, dbl;
> + int modes = 0, vendor_id;
>
> + /* let's find the cea modes before looking at the hdmi vendor block
> +* as the 3d_present flag needs to know about the supported modes
> +* to infer the 3D modes */
> if (cea && cea[1] >= 3) {
> for (db = cea + 4; db < cea + cea[2]; db += dbl + 1) {
> dbl = db[0] & 0x1f;
> - if (((db[0] & 0xe0) >> 5) == VIDEO_BLOCK)
> + switch ((db[0] & 0xe0) >> 5) {
> + case VIDEO_BLOCK:
> modes += do_cea_modes (connector, db+1, dbl);
> + break;
> + case VENDOR_BLOCK:
> + vendor_id = db[1] | db[2] << 8 | db[3] << 16;
> + if (vendor_id == HDMI_IDENTIFIER)
> + hdmi = db;
> + }
> }
> }
>
> + if (connector->expose_3d_modes && hdmi && cea_hdmi_3d_present(hdmi))
> + cea_hdmi_patch_mandatory_3d_modes(connector);
> +
> return modes;
> }
>
> diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
> index 45b19c6..d5d22de 100644
> --- a/include/drm/drm_mode.h
> +++ b/include/drm/drm_mode.h
> @@ -44,20 +44,27 @@
>
> /* Video mode flags */
> /* bit compatible with the xorg definitions. */
>
[Intel-gfx] [PATCH 1/2] lib: Dump information about the supported 3D stereo formats
Reviewed-by: Rodrigo Vivi
Tested-by: Rodrigo Vivi
On Thu, Sep 27, 2012 at 3:42 PM, Damien Lespiau
wrote:
> From: Damien Lespiau
>
> When dumping the details of a mode, let's add the 3D formats the mode
> supports.
>
> Signed-off-by: Damien Lespiau
> ---
> lib/drmtest.c | 13 +++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/lib/drmtest.c b/lib/drmtest.c
> index 8df9797..4d5a67c 100644
> --- a/lib/drmtest.c
> +++ b/lib/drmtest.c
> @@ -812,7 +812,15 @@ unsigned int kmstest_create_fb(int fd, int width, int
> height, int bpp,
>
> void kmstest_dump_mode(drmModeModeInfo *mode)
> {
> - printf(" %s %d %d %d %d %d %d %d %d %d 0x%x 0x%x %d\n",
> + bool stereo_3d = mode->flags & DRM_MODE_FLAG_3D_MASK;
> + char flags_str[32];
> +
> + snprintf(flags_str, sizeof(flags_str), " (3D:%s%s%s)",
> +mode->flags & DRM_MODE_FLAG_3D_TOP_BOTTOM ? " TB": "",
> +mode->flags & DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF ? " SBSH":
> "",
> +mode->flags & DRM_MODE_FLAG_3D_FRAME_PACKING ? " FP": "");
> +
> + printf(" %s %d %d %d %d %d %d %d %d %d 0x%x 0x%x %d%s\n",
>mode->name,
>mode->vrefresh,
>mode->hdisplay,
> @@ -825,7 +833,8 @@ void kmstest_dump_mode(drmModeModeInfo *mode)
>mode->vtotal,
>mode->flags,
>mode->type,
> - mode->clock);
> + mode->clock,
> + stereo_3d ? flags_str : "");
> fflush(stdout);
> }
>
> --
> 1.7.11.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
[Intel-gfx] [PATCH 1/3] drm: Add an "expose 3d modes" property
Reviewed-by: Rodrigo Vivi
Tested-by: Rodrigo Vivi
On Thu, Sep 27, 2012 at 3:41 PM, Damien Lespiau
wrote:
> From: Damien Lespiau
>
> The "expose 3D modes" property can be attached to connectors to allow
> user space to indicate it can deal with 3D modes and that the drm driver
> should expose those 3D modes.
>
> Signed-off-by: Damien Lespiau
> ---
> drivers/gpu/drm/drm_crtc.c | 35 ++-
> include/drm/drm_crtc.h | 6 ++
> include/drm/drm_mode.h | 4
> 3 files changed, 44 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 6fbfc24..10a289c 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -841,6 +841,35 @@ int drm_mode_create_tv_properties(struct drm_device
> *dev, int num_modes,
> }
> EXPORT_SYMBOL(drm_mode_create_tv_properties);
>
> +static const struct drm_prop_enum_list expose_3d_modes_list[] =
> +{
> + { DRM_MODE_EXPOSE_3D_MODES_OFF, "Off" },
> + { DRM_MODE_EXPOSE_3D_MODES_ON, "On" }
> +};
> +
> +/**
> + * drm_mode_create_s3d_properties - create stereo 3D properties
> + * @dev: DRM device
> + *
> + * This functions create properties that are used by the stereo 3D code.
> Those
> + * properties must be attached to the desired connectors afterwards.
> + */
> +int drm_mode_create_s3d_properties(struct drm_device *dev)
> +{
> + struct drm_property *prop;
> +
> + if (dev->mode_config.s3d_expose_modes_property)
> + return 0;
> +
> + prop = drm_property_create_enum(dev, 0, "expose 3D modes",
> + expose_3d_modes_list,
> + ARRAY_SIZE(expose_3d_modes_list));
> + dev->mode_config.s3d_expose_modes_property = prop;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_mode_create_s3d_properties);
> +
> /**
> * drm_mode_create_scaling_mode_property - create scaling mode property
> * @dev: DRM device
> @@ -3170,12 +3199,16 @@ static int drm_mode_connector_set_obj_prop(struct
> drm_mode_object *obj,
> {
> int ret = -EINVAL;
> struct drm_connector *connector = obj_to_connector(obj);
> + struct drm_device *dev = connector->dev;
>
> /* Do DPMS ourselves */
> - if (property == connector->dev->mode_config.dpms_property) {
> + if (property == dev->mode_config.dpms_property) {
> if (connector->funcs->dpms)
> (*connector->funcs->dpms)(connector, (int)value);
> ret = 0;
> + } else if (property == dev->mode_config.s3d_expose_modes_property) {
> + connector->expose_3d_modes = value;
> + ret = 0;
> } else if (connector->funcs->set_property)
> ret = connector->funcs->set_property(connector, property,
> value);
>
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index bfacf0d..34372cb 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -578,6 +578,8 @@ struct drm_connector {
> /* requested DPMS state */
> int dpms;
>
> + int expose_3d_modes;
> +
> void *helper_private;
>
> /* forced on connector */
> @@ -802,6 +804,9 @@ struct drm_mode_config {
> struct drm_property *tv_saturation_property;
> struct drm_property *tv_hue_property;
>
> + /* Stereo 3D properties */
> + struct drm_property *s3d_expose_modes_property;
> +
> /* Optional properties */
> struct drm_property *scaling_mode_property;
> struct drm_property *dithering_mode_property;
> @@ -950,6 +955,7 @@ extern int drm_property_add_enum(struct drm_property
> *property, int index,
> extern int drm_mode_create_dvi_i_properties(struct drm_device *dev);
> extern int drm_mode_create_tv_properties(struct drm_device *dev, int
> num_formats,
> char *formats[]);
> +extern int drm_mode_create_s3d_properties(struct drm_device *dev);
> extern int drm_mode_create_scaling_mode_property(struct drm_device *dev);
> extern int drm_mode_create_dithering_property(struct drm_device *dev);
> extern int drm_mode_create_dirty_info_property(struct drm_device *dev);
> diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
> index 3d6301b..45b19c6 100644
> --- a/include/drm/drm_mode.h
> +++ b/include/drm/drm_mode.h
> @@ -83,6 +83,10 @@
> #define DRM_MODE_DIRTY_ON 1
> #define DRM_MODE_DIRTY_ANNOTATE 2
>
> +/* Expose 3D modes */
> +#define DRM_MODE_EXPOSE_3D_MODES_OFF 0
> +#define DRM_MODE_EXPOSE_3D_MODES_ON1
> +
> struct drm_mode_modeinfo {
> __u32 clock;
> __u16 hdisplay, hsync_start, hsync_end, htotal, hskew;
> --
> 1.7.11.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
[PATCH 2/2] tests/testdisplay: Test the stereo 3D modes
On Thu, Sep 27, 2012 at 3:42 PM, Damien Lespiau
wrote:
> From: Damien Lespiau
>
> Now that modes have flags to describe which 3d formats the sink
> supports, it's time to test them.
>
> The new test cycles through the supported 3D formats and paint 3D
> stereoscopic images taken from publicly available samples:
> http://www.quantumdata.com/apps/3D/sample_BMP.asp
>
> Signed-off-by: Damien Lespiau
> ---
> tests/testdisplay.c | 226
> ++--
> 1 file changed, 221 insertions(+), 5 deletions(-)
>
> diff --git a/tests/testdisplay.c b/tests/testdisplay.c
> index c52bb2f..e179c83 100644
> --- a/tests/testdisplay.c
> +++ b/tests/testdisplay.c
> @@ -52,6 +52,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -68,7 +69,7 @@
> drmModeRes *resources;
> int drm_fd, modes;
> int dump_info = 0, test_all_modes =0, test_preferred_mode = 0, force_mode =
> 0,
> - test_plane, enable_tiling;
> + test_plane, test_3d_modes, enable_tiling;
> int sleep_between_modes = 5;
> uint32_t depth = 24, stride, bpp;
> int qr_code = 0;
> @@ -153,8 +154,51 @@ struct connector {
> drmModeConnector *connector;
> int crtc;
> int pipe;
> +
> + /* stereo 3d */
> + int s3d_format;
> + char s3d_image[32];
> };
>
> +static bool connector_expose_3d(uint32_t connector_id, bool enable)
> +{
> + drmModeConnector *connector;
> + drmModePropertyRes *property;
> + bool status = false;
> + int i;
> +
> + connector = drmModeGetConnector(drm_fd, connector_id);
> + if (connector->count_props == 0)
> + return false;
> +
> + for (i = 0; i < connector->count_props; i++) {
> + property = drmModeGetProperty(drm_fd, connector->props[i]);
> + if (!property)
> + continue;
> +
> + if (strcmp(property->name, "expose 3D modes") == 0) {
> + if (drmModeConnectorSetProperty(drm_fd,
> + connector_id,
> + property->prop_id,
> + enable))
> + fprintf(stderr, "failed to set the \"expose
> 3D "
> + "modes\" property on connector %d:
> %s\n",
> + connector_id, strerror(errno));
> + else
> + status = true;
> + drmModeFreeProperty(property);
> + goto out;
> + }
> +
> + drmModeFreeProperty(property);
> + property = NULL;
> + }
> +
> +out:
> + drmModeFreeConnector(connector);
> + return status;
> +}
> +
> static void dump_connectors_fd(int drmfd)
> {
> int i, j;
> @@ -172,11 +216,13 @@ static void dump_connectors_fd(int drmfd)
> for (i = 0; i < mode_resources->count_connectors; i++) {
> drmModeConnector *connector;
>
> + connector_expose_3d(mode_resources->connectors[i], TRUE);
> +
> connector = drmModeGetConnector(drmfd,
> mode_resources->connectors[i]);
> if (!connector) {
> fprintf(stderr, "could not get connector %i: %s\n",
> mode_resources->connectors[i],
> strerror(errno));
> - continue;
> + goto next;
> }
>
> printf("%d\t%d\t%s\t%s\t%dx%d\t\t%d\n",
> @@ -188,7 +234,7 @@ static void dump_connectors_fd(int drmfd)
>connector->count_modes);
>
> if (!connector->count_modes)
> - continue;
> + goto next;
>
> printf(" modes:\n");
> printf(" name refresh (Hz) hdisp hss hse htot vdisp "
> @@ -197,6 +243,9 @@ static void dump_connectors_fd(int drmfd)
> kmstest_dump_mode(&connector->modes[j]);
>
> drmModeFreeConnector(connector);
> +
> +next:
> + connector_expose_3d(mode_resources->connectors[i], FALSE);
> }
> printf("\n");
>
> @@ -554,6 +603,154 @@ set_mode(struct connector *c)
> drmModeFreeConnector(c->connector);
> }
>
> +static void
> +paint_3d_image(cairo_t *cr, int l_width, int l_height, void *priv)
> +{
> + struct connector *c = priv;
> + cairo_surface_t *image;
> +
> + image = cairo_image_surface_create_from_png(c->s3d_image);
> +
> + cairo_set_source_surface(cr, image, 0, 0);
> + cairo_paint(cr);
> +
> + cairo_surface_destroy(image);
> +}
> +
> +static void adjust_3d_timings(drmModeModeInfo *mode, unsigned int format)
> +{
> + uint16_t vdisplay, vactive_space;
> +
> + /* just set the 3D format we are setting (this
[PATCH 1/5] dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER
On 09/28/2012 04:14 PM, Maarten Lankhorst wrote: > Hey, > > Op 28-09-12 14:41, Maarten Lankhorst schreef: >> Documentation says that code requiring dma-buf should add it to >> select, so inline fallbacks are not going to be used. A link error >> will make it obvious what went wrong, instead of silently doing >> nothing at runtime. >> > > > > The whole patch series is in my tree, I use stg so things might > move around, do not use for merging currently: > > http://cgit.freedesktop.org/~mlankhorst/linux/log/?h=v10-wip > > It contains everything in here plus the patches for ttm to make > it work, I use a old snapshot of drm-next + merge of nouveau as > base. Description of what the parts do: > > Series to fix small api issues when moving over: > > drm/ttm: Remove cpu_writers related code > drm/ttm: Add ttm_bo_is_reserved function > drm/radeon: Use ttm_bo_is_reserved > drm/vmwgfx: use ttm_bo_is_reserved > > drm/vmwgfx: remove use of fence_obj_args > drm/ttm: remove sync_obj_arg > drm/ttm: remove sync_obj_arg from ttm_bo_move_accel_cleanup > drm/ttm: remove sync_arg entirely > > drm/nouveau: unpin buffers before releasing to prevent lockdep warnings > drm/nouveau: add reservation to nouveau_bo_vma_del > drm/nouveau: add reservation to nouveau_gem_ioctl_cpu_prep > > Hey great, now we only have one user left for fence waiting before reserving, > lets fix that and remove fence lock: > ttm_bo_cleanup_refs_or_queue and ttm_bo_cleanup_refs have to reserve before > waiting, lets do it in the squash commit so we don't have to throw lock order > around everywhere: > > drm/ttm: remove fence_lock > > -- Up to this point should be mergeable now > > Then we start working on lru_lock removal slightly, this means the lru > list no longer is empty but can contain only reserved buffers: > > drm/ttm: do not check if list is empty in ttm_bo_force_list_clean > drm/ttm: move reservations for ttm_bo_cleanup_refs > > -- Still mergeable up to this point, just fixes > > Patch series from this email: > dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER > fence: dma-buf cross-device synchronization (v9) > seqno-fence: Hardware dma-buf implementation of fencing (v3) > reservation: cross-device reservation support > reservation: Add lockdep annotation and selftests > > Now hook it up to drm/ttm in a few steps: > usage around reservations: > drm/ttm: make ttm reservation calls behave like reservation calls > drm/ttm: use dma_reservation api > dma-buf: use reservations > drm/ttm: allow drivers to pass custom dma_reservation_objects for a bo > > then kill off the lru lock around reservation: > drm/ttm: remove lru_lock around ttm_bo_reserve > drm/ttm: simplify ttm_eu_* > > The lru_lock removal patch removes the lock around lru_lock around the > reservation, this will break the assumption that items on the lru list > and swap list can always be reserved, and this gets patched up too. > Is there any part in ttm you disagree with? I believe that this > is all mergeable, the lru_lock removal patch could be moved to before > the reservation parts, this might make merging easier, but I don't > think there is any ttm part of the series that are wrong on a conceptual > level. > > ~Maarten > From another email >> As previously discussed, I'm unfortunately not prepared to accept removal of >> the reserve-lru atomicity >> into the TTM code at this point. >> The current code is based on this assumption and removing it will end up with >> efficiencies, breaking the delayed delete code and probably a locking >> nightmare when trying to write >> new TTM code. > The lru lock removal patch fixed the delayed delete code, it really is not > different from the current > situation. In fact it is more clear without the guarantee what various parts > are trying to protect. > > Nothing prevents you from holding the lru_lock while trylocking, [1] While this would not cause any deadlocks, Any decent lockdep code would establish lru->reserve as the locking order once a lru- reserve trylock succeeds, but the locking order is really reserve->lru for obvious reasons, which means we will get a lot of lockdep errors? Yes, there are a two reversals like these already in the TTM code, and I'm not very proud of them. leaving that guarantee intact for that part. Can you really just review the patch and tell me where it breaks and/or makes the code unreadable? OK. Now I'm looking at http://cgit.freedesktop.org/~mlankhorst/linux/tree/drivers/gpu/drm/ttm/ttm_bo.c?h=v10-wip&id=1436e2e64697c744d6e186618448e1e6354846bb And let's start with a function that's seen some change, ttm_mem_evict_first: *) Line 715: You're traversing a list using list_for_each() calling a function that may remove the list entry *) Line 722: You're unlocking the lock protecting the list in the middle of list traversal *) Line 507: WARN_ON_ONCE in a code path quite likely to get called? *) Line 512: sleep while atomic *) Line 729: Forgot to unreserve *) Line 730: Forgot to lock
[PATCH 0/3] [RFC] DRM Render Nodes
On Fri, Sep 28, 2012 at 8:42 PM, Ilija Hadzic wrote: > > > On Fri, 28 Sep 2012, Daniel Vetter wrote: > >> On a quick look the rendernode Kristian propose and your work seem to >> attack slightly different issues. Your/Dave's patch series seems to >> put large efforts into (dynamically) splitting up the resources of a >> drm device, including the modeset stuff. > > > Correct, the goal is to be able to run multiseat while sharing a GPU. > Actually, with my variant of render nodes, I even got multiple desktops > residing in different LXC containers to share the GPU, which is kind of > cool. > > >> Kristians proposal here is >> much more modest, with just enabling a way for to do the same for >> render clients. All the modeset (and flink open stuff) would still be >> only done through the legacy drm node. >> > > OK I see. From what I can tell from the second patch, drm_get_pci_dev will > create one (and I guess only one, right ?) render node if the underlying > driver has DRIVER_RENDER node feature. The third patch (among other things) > adds that feature to Intel driver. > > So if I boot up a system with these patches and with Intel GPU, I will > automagically get one more /dev/dri/renderD128 node, right ? The intent is > that the render client opens and uses that render node. The > /dev/dri/controlDNN node still remains an unused "orphan", right ? Yeah, the plan is to just have one single render node and ensure insulation by not allowing any open file of that render node to access any other buffer not associated to the file_prive. Like I've said, the current patches have a little hole wrt mmap handling there ;-) The only way to share buffers is via dma_buf (which is fd based, so we could attach full selinux contexts if required) or flink (but not opening an flink name, that requires master rights on the legacy node). > So would you entertain the possibility that the render node is created from > user space on demand using an ioctl into the control node ? If that's a > possiblity for you, then my set of patches is a superset of what Kristian > needs. If you just need a render client, you can create a node with no > display resources and you would get something quite close to what these 3 > patches try to do. unless I am missing something. Well, dynamically creating render nodes is not required just for insulating different render clients. The goal is very much to allow background/headless usage of the gpu, e.g. for opencl and video encode/decode. So first asking a central deamon to span another render node just to transcode another video isn't that great. Obviously the security separation only works if the gpu actually supports different vm address spaces for each node ... The multi-seat issue is imo orthogonal to that and I don't think we should mangle (like you've noticed, ppl seem to get scared about it and not push those patches too much). And with new stuff like atomic modeset and gpus having a lot of shared resources in the display hw (plls, memory bw, shared links between pipes, ...) I don't think we could even statically split up the modeset resurces, like your patch would allow. Imho a better solution for the mutliseat use-case would be to have a (priviledge) system-compositor that handles the resource sharing between the different seats. Display servers would then simply be yet another render node client (and doing modeset changes through a protocol to the system compositor). The system-compositor could be very well something that would aweful closely resemble wayland ;-) Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH 0/3] [RFC] DRM Render Nodes
On Fri, Sep 28, 2012 at 7:59 PM, Ilija Hadzic wrote: > > > On Fri, 28 Sep 2012, Alex Deucher wrote: >> >> >> I haven't read through your patches yet, but Dave and Ilija already >> did something similar a while back: >> >> http://lists.freedesktop.org/archives/dri-devel/2012-March/020765.html >> > > Actually, there is a, a newer series of patches here (applied few comments I > got after first series) > > http://lists.freedesktop.org/archives/dri-devel/2012-April/021326.html > > I have the v3 series (applied more comments I got after v2 series, plus some > more cleanup) that I have never sent out, because my perception was that > there was low interest in this work. I can send the v3 out, if there is a > revived interest in this work. > > The original work is by Dave and I did some major cleanup and built more on > the top of it. > > Kristian's patches at the first glance (I have not looked them in detail) > appear more like prep. work (like which ioctl can a render node use and > which can't, etc.), but my impression is that they still require the work > cited above (Dave's original work and/or my followup work) to actually be > able to create and use the render node. > > BTW, the third patch in Kristian's series is for Intel only and we'll > probably need equivalent patches for radeon and nouveau. On a quick look the rendernode Kristian propose and your work seem to attack slightly different issues. Your/Dave's patch series seems to put large efforts into (dynamically) splitting up the resources of a drm device, including the modeset stuff. Kristians proposal here is much more modest, with just enabling a way for to do the same for render clients. All the modeset (and flink open stuff) would still be only done through the legacy drm node. One thing though that Kristians patches miss is properly splitting out mmap support such that each open file of the rendernode only has access to it's file-private gem object and not all of them. Since linux has the mmap interface at the struct file level, that shouldn't be a big hassle to get off the ground: We just need to add an mmap_offset table to file_prive and then add the offset lookup at the right place (and do the lookup with the right table), depending upon whether it's a legacy or a new render node doing the offset create (or mmap syscall). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH 14/14] drm: exynos: hdmi: remove drm common hdmi platform data struct
exynos-drm-hdmi need context pointers from hdmi and mixer. These
pointers were expected from the plf data. Cleaned this dependency
by exporting i/f which are called by hdmi, mixer driver probes
for setting their context.
Signed-off-by: Rahul Sharma
---
drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 51 +++--
drivers/gpu/drm/exynos/exynos_drm_hdmi.h |2 +
drivers/gpu/drm/exynos/exynos_hdmi.c |3 ++
drivers/gpu/drm/exynos/exynos_mixer.c|3 ++
include/drm/exynos_drm.h | 14
5 files changed, 34 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
index 0584132..85304c4 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
@@ -29,6 +29,11 @@
#define get_ctx_from_subdrv(subdrv)container_of(subdrv,\
struct drm_hdmi_context, subdrv);
+/* Common hdmi subdrv needs to access the hdmi and mixer though context.
+* These should be initialied by the repective drivers */
+static struct exynos_drm_hdmi_context *hdmi_ctx;
+static struct exynos_drm_hdmi_context *mixer_ctx;
+
/* these callback points shoud be set by specific drivers. */
static struct exynos_hdmi_ops *hdmi_ops;
static struct exynos_mixer_ops *mixer_ops;
@@ -41,6 +46,18 @@ struct drm_hdmi_context {
boolenabled[MIXER_WIN_NR];
};
+void exynos_hdmi_drv_attach(struct exynos_drm_hdmi_context *ctx)
+{
+ if (ctx)
+ hdmi_ctx = ctx;
+}
+
+void exynos_mixer_drv_attach(struct exynos_drm_hdmi_context *ctx)
+{
+ if (ctx)
+ mixer_ctx = ctx;
+}
+
void exynos_hdmi_ops_register(struct exynos_hdmi_ops *ops)
{
DRM_DEBUG_KMS("%s\n", __FILE__);
@@ -303,46 +320,30 @@ static int hdmi_subdrv_probe(struct drm_device *drm_dev,
{
struct exynos_drm_subdrv *subdrv = to_subdrv(dev);
struct drm_hdmi_context *ctx;
- struct platform_device *pdev = to_platform_device(dev);
- struct exynos_drm_common_hdmi_pd *pd;
DRM_DEBUG_KMS("%s\n", __FILE__);
- pd = pdev->dev.platform_data;
-
- if (!pd) {
- DRM_DEBUG_KMS("platform data is null.\n");
+ if (!hdmi_ctx) {
+ DRM_ERROR("hdmi context not initialized.\n");
return -EFAULT;
}
- if (!pd->hdmi_dev) {
- DRM_DEBUG_KMS("hdmi device is null.\n");
- return -EFAULT;
- }
-
- if (!pd->mixer_dev) {
- DRM_DEBUG_KMS("mixer device is null.\n");
+ if (!mixer_ctx) {
+ DRM_ERROR("mixer context not initialized.\n");
return -EFAULT;
}
ctx = get_ctx_from_subdrv(subdrv);
- ctx->hdmi_ctx = (struct exynos_drm_hdmi_context *)
- to_context(pd->hdmi_dev);
- if (!ctx->hdmi_ctx) {
- DRM_DEBUG_KMS("hdmi context is null.\n");
+ if (!ctx) {
+ DRM_ERROR("no drm hdmi context.\n");
return -EFAULT;
}
- ctx->hdmi_ctx->drm_dev = drm_dev;
-
- ctx->mixer_ctx = (struct exynos_drm_hdmi_context *)
- to_context(pd->mixer_dev);
- if (!ctx->mixer_ctx) {
- DRM_DEBUG_KMS("mixer context is null.\n");
- return -EFAULT;
- }
+ ctx->hdmi_ctx = hdmi_ctx;
+ ctx->mixer_ctx = mixer_ctx;
+ ctx->hdmi_ctx->drm_dev = drm_dev;
ctx->mixer_ctx->drm_dev = drm_dev;
return 0;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
index d9f9e9f..2da5ffd 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
@@ -73,6 +73,8 @@ struct exynos_mixer_ops {
void (*win_disable)(void *ctx, int zpos);
};
+void exynos_hdmi_drv_attach(struct exynos_drm_hdmi_context *ctx);
+void exynos_mixer_drv_attach(struct exynos_drm_hdmi_context *ctx);
void exynos_hdmi_ops_register(struct exynos_hdmi_ops *ops);
void exynos_mixer_ops_register(struct exynos_mixer_ops *ops);
#endif
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 5caf49f..e6b784d 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -2454,6 +2454,9 @@ static int __devinit hdmi_probe(struct platform_device
*pdev)
goto err_free_irq;
}
+ /* Attach HDMI Driver to common hdmi. */
+ exynos_hdmi_drv_attach(drm_hdmi_ctx);
+
/* register specific callbacks to common hdmi. */
exynos_hdmi_ops_register(&hdmi_ops);
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index d34562a..672e6f7 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -1163,6 +1163,9 @@ static int __devinit mixer_probe(struct platform_device
*pdev)
[PATCH 13/14] drm: exynos: hdmi: add support for exynos5 hdmi
This patch adds support for exynos5 hdmi with device tree enabled.
Signed-off-by: Rahul Sharma
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 83 --
1 files changed, 79 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 89e798b..5caf49f 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -32,6 +32,9 @@
#include
#include
#include
+#include
+#include
+#include
#include
@@ -2250,6 +2253,41 @@ void hdmi_attach_hdmiphy_client(struct i2c_client
*hdmiphy)
hdmi_hdmiphy = hdmiphy;
}
+#ifdef CONFIG_OF
+static struct s5p_hdmi_platform_data *drm_hdmi_dt_parse_pdata
+ (struct device *dev)
+{
+ struct device_node *np = dev->of_node;
+ struct s5p_hdmi_platform_data *pd;
+ enum of_gpio_flags flags;
+ u32 value;
+
+ pd = devm_kzalloc(dev, sizeof(*pd), GFP_KERNEL);
+ if (!pd) {
+ DRM_ERROR("memory allocation for pdata failed\n");
+ goto err_data;
+ }
+
+ if (!of_find_property(np, "hpd-gpio", &value)) {
+ DRM_ERROR("no hpd gpio property found\n");
+ goto err_data;
+ }
+
+ pd->hpd_gpio = of_get_named_gpio_flags(np, "hpd-gpio", 0, &flags);
+
+ return pd;
+
+err_data:
+ return NULL;
+}
+#else
+static struct s5p_hdmi_platform_data *drm_hdmi_dt_parse_pdata
+ (struct device *dev)
+{
+ return NULL;
+}
+#endif
+
static struct platform_device_id hdmi_driver_types[] = {
{
.name = "s5pv210-hdmi",
@@ -2259,7 +2297,19 @@ static struct platform_device_id hdmi_driver_types[] = {
.driver_data= HDMI_TYPE13,
}, {
.name = "exynos4-hdmi14",
- .driver_data= HDMI_TYPE14,
+ .driver_data= HDMI_TYPE14,
+ }, {
+ .name = "exynos5-hdmi",
+ .driver_data= HDMI_TYPE14,
+ }, {
+ /* end node */
+ }
+};
+
+static struct of_device_id hdmi_match_types[] = {
+ {
+ .compatible = "samsung,exynos5-hdmi",
+ .data = (void *)HDMI_TYPE14,
}, {
/* end node */
}
@@ -2276,7 +2326,16 @@ static int __devinit hdmi_probe(struct platform_device
*pdev)
DRM_DEBUG_KMS("[%d]\n", __LINE__);
- pdata = pdev->dev.platform_data;
+ if (pdev->dev.of_node) {
+ pdata = drm_hdmi_dt_parse_pdata(dev);
+ if (IS_ERR(pdata)) {
+ DRM_ERROR("failed to parse dt\n");
+ return PTR_ERR(pdata);
+ }
+ } else {
+ pdata = pdev->dev.platform_data;
+ }
+
if (!pdata) {
DRM_ERROR("no platform data specified\n");
return -EINVAL;
@@ -2303,18 +2362,33 @@ static int __devinit hdmi_probe(struct platform_device
*pdev)
platform_set_drvdata(pdev, drm_hdmi_ctx);
- hdata->type = (enum hdmi_type)platform_get_device_id
+ if (dev->of_node) {
+ const struct of_device_id *match;
+ match = of_match_node(of_match_ptr(hdmi_match_types),
+ pdev->dev.of_node);
+ hdata->type = (enum hdmi_type)match->data;
+ } else {
+ hdata->type = (enum hdmi_type)platform_get_device_id
(pdev)->driver_data;
+ }
+
hdata->hpd_gpio = pdata->hpd_gpio;
hdata->dev = dev;
ret = hdmi_resources_init(hdata);
+
if (ret) {
ret = -EINVAL;
+ DRM_ERROR("hdmi_resources_init failed\n");
goto err_data;
}
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res) {
+ DRM_ERROR("failed to find registers\n");
+ ret = -ENOENT;
+ goto err_resource;
+ }
hdata->regs = devm_request_and_ioremap(&pdev->dev, res);
if (!hdata->regs) {
@@ -2462,8 +2536,9 @@ struct platform_driver hdmi_driver = {
.remove = __devexit_p(hdmi_remove),
.id_table = hdmi_driver_types,
.driver = {
- .name = "exynos4-hdmi",
+ .name = "exynos-hdmi",
.owner = THIS_MODULE,
.pm = &hdmi_pm_ops,
+ .of_match_table = hdmi_match_types,
},
};
--
1.7.0.4
[PATCH 12/14] drm: exynos: hdmi: replace is_v13 with version check in hdmi
This patch removed the is_v13 variable from the hdmi driver context.
It is replaced with condition check for the hdmi version. This cleans
the way for handling further hdmi versions.
Signed-off-by: Rahul Sharma
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 40 +-
1 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index e3ab840..89e798b 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -47,6 +47,11 @@
#define MAX_HEIGHT 1080
#define get_hdmi_context(dev) platform_get_drvdata(to_platform_device(dev))
+enum hdmi_type {
+ HDMI_TYPE13,
+ HDMI_TYPE14,
+};
+
struct hdmi_resources {
struct clk *hdmi;
struct clk *sclk_hdmi;
@@ -62,7 +67,6 @@ struct hdmi_context {
struct drm_device *drm_dev;
boolhpd;
boolpowered;
- boolis_v13;
booldvi_mode;
struct mutexhdmi_mutex;
@@ -80,6 +84,8 @@ struct hdmi_context {
void*parent_ctx;
int hpd_gpio;
+
+ enum hdmi_type type;
};
/* HDMI Version 1.3 */
@@ -1211,7 +1217,7 @@ static void hdmi_v14_regs_dump(struct hdmi_context
*hdata, char *prefix)
static void hdmi_regs_dump(struct hdmi_context *hdata, char *prefix)
{
- if (hdata->is_v13)
+ if (hdata->type == HDMI_TYPE13)
hdmi_v13_regs_dump(hdata, prefix);
else
hdmi_v14_regs_dump(hdata, prefix);
@@ -1252,7 +1258,7 @@ static int hdmi_v14_conf_index(struct drm_display_mode
*mode)
static int hdmi_conf_index(struct hdmi_context *hdata,
struct drm_display_mode *mode)
{
- if (hdata->is_v13)
+ if (hdata->type == HDMI_TYPE13)
return hdmi_v13_conf_index(mode);
return hdmi_v14_conf_index(mode);
@@ -1348,7 +1354,7 @@ static int hdmi_check_timing(void *ctx, void *timing)
check_timing->yres, check_timing->refresh,
check_timing->vmode);
- if (hdata->is_v13)
+ if (hdata->type == HDMI_TYPE13)
return hdmi_v13_check_timing(check_timing);
else
return hdmi_v14_check_timing(check_timing);
@@ -1414,7 +1420,7 @@ static void hdmi_reg_acr(struct hdmi_context *hdata, u8
*acr)
hdmi_reg_writeb(hdata, HDMI_ACR_CTS1, acr[2]);
hdmi_reg_writeb(hdata, HDMI_ACR_CTS2, acr[1]);
- if (hdata->is_v13)
+ if (hdata->type == HDMI_TYPE13)
hdmi_reg_writeb(hdata, HDMI_V13_ACR_CON, 4);
else
hdmi_reg_writeb(hdata, HDMI_ACR_CON, 4);
@@ -1518,7 +1524,7 @@ static void hdmi_conf_reset(struct hdmi_context *hdata)
{
u32 reg;
- if (hdata->is_v13)
+ if (hdata->type == HDMI_TYPE13)
reg = HDMI_V13_CORE_RSTOUT;
else
reg = HDMI_CORE_RSTOUT;
@@ -1550,7 +1556,7 @@ static void hdmi_conf_init(struct hdmi_context *hdata)
HDMI_VID_PREAMBLE_DIS | HDMI_GUARD_BAND_DIS);
}
- if (hdata->is_v13) {
+ if (hdata->type == HDMI_TYPE13) {
/* choose bluescreen (fecal) color */
hdmi_reg_writeb(hdata, HDMI_V13_BLUE_SCREEN_0, 0x12);
hdmi_reg_writeb(hdata, HDMI_V13_BLUE_SCREEN_1, 0x34);
@@ -1832,7 +1838,7 @@ static void hdmi_v14_timing_apply(struct hdmi_context
*hdata)
static void hdmi_timing_apply(struct hdmi_context *hdata)
{
- if (hdata->is_v13)
+ if (hdata->type == HDMI_TYPE13)
hdmi_v13_timing_apply(hdata);
else
hdmi_v14_timing_apply(hdata);
@@ -1854,7 +1860,7 @@ static void hdmiphy_conf_reset(struct hdmi_context *hdata)
if (hdata->hdmiphy_port)
i2c_master_send(hdata->hdmiphy_port, buffer, 2);
- if (hdata->is_v13)
+ if (hdata->type == HDMI_TYPE13)
reg = HDMI_V13_PHY_RSTOUT;
else
reg = HDMI_PHY_RSTOUT;
@@ -1881,7 +1887,7 @@ static void hdmiphy_conf_apply(struct hdmi_context *hdata)
}
/* pixel clock */
- if (hdata->is_v13)
+ if (hdata->type == HDMI_TYPE13)
hdmiphy_data = hdmi_v13_confs[hdata->cur_conf].hdmiphy_data;
else
hdmiphy_data = hdmi_confs[hdata->cur_conf].hdmiphy_data;
@@ -1949,7 +1955,7 @@ static void hdmi_mode_fixup(void *ctx, struct
drm_connector *connector,
drm_mode_set_crtcinfo(adjusted_mode, 0);
- if (hdata->is_v13)
+ if (hdata->type == HDMI_TYPE13)
index = hdmi_v13_conf_index(adjusted_mode);
else
index = hdmi_v14_conf_index(adjusted_mode);
@@ -1963,7 +19
[PATCH 11/14] drm: exynos: hdmi: add support for exynos5 mixer
This patch adds support for exynos5 mixer with device tree enabled.
Signed-off-by: Rahul Sharma
Signed-off-by: Fahad Kunnathadi
---
drivers/gpu/drm/exynos/exynos_mixer.c | 41 ++--
drivers/gpu/drm/exynos/regs-mixer.h |2 +
2 files changed, 40 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index ff2a45d..d34562a 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -645,6 +645,10 @@ static void mixer_win_reset(struct mixer_context *ctx)
if (ctx->vp_enabled)
mixer_reg_writemask(res, MXR_CFG, 0, MXR_CFG_VP_ENABLE);
+ /* enable vsync interrupt after mixer reset*/
+ mixer_reg_writemask(res, MXR_INT_EN, MXR_INT_EN_VSYNC,
+ MXR_INT_EN_VSYNC);
+
mixer_vsync_set_update(ctx, true);
spin_unlock_irqrestore(&res->reg_slock, flags);
}
@@ -913,6 +917,11 @@ static irqreturn_t mixer_irq_handler(int irq, void *arg)
/* handling VSYNC */
if (val & MXR_INT_STATUS_VSYNC) {
+ if (ctx->mxr_ver == MXR_VER_16_0_33_0) {
+ /* layer update mandatory for mixer 16.0.33.0 */
+ mixer_reg_writemask(res, MXR_CFG, ~0,
+ MXR_CFG_LAYER_UPDATE);
+ }
/* interlace scan need to check shadow register */
if (ctx->interlace) {
base = mixer_reg_read(res, MXR_GRAPHIC_BASE(0));
@@ -1066,6 +1075,11 @@ fail:
return ret;
}
+static struct mixer_drv_data exynos5_mxr_drv_data = {
+ .version = MXR_VER_16_0_33_0,
+ .is_vp_enabled = 0,
+};
+
static struct mixer_drv_data exynos4_mxr_drv_data = {
.version = MXR_VER_0_0_0_16,
.is_vp_enabled = 1,
@@ -1075,6 +1089,18 @@ static struct platform_device_id mixer_driver_types[] = {
.name = "s5p-mixer",
.driver_data= (unsigned long)&exynos4_mxr_drv_data,
}, {
+ .name = "exynos5-mixer",
+ .driver_data= (unsigned long)&exynos5_mxr_drv_data,
+ }, {
+ /* end node */
+ }
+};
+
+static struct of_device_id mixer_match_types[] = {
+ {
+ .compatible = "samsung,exynos5-mixer",
+ .data = &exynos5_mxr_drv_data,
+ }, {
/* end node */
}
};
@@ -1104,8 +1130,16 @@ static int __devinit mixer_probe(struct platform_device
*pdev)
mutex_init(&ctx->mixer_mutex);
- drv = (struct mixer_drv_data *)platform_get_device_id(
- pdev)->driver_data;
+ if (dev->of_node) {
+ const struct of_device_id *match;
+ match = of_match_node(of_match_ptr(mixer_match_types),
+ pdev->dev.of_node);
+ drv = match->data;
+ } else {
+ drv = (struct mixer_drv_data *)
+ platform_get_device_id(pdev)->driver_data;
+ }
+
ctx->dev = &pdev->dev;
drm_hdmi_ctx->ctx = (void *)ctx;
ctx->vp_enabled = drv->is_vp_enabled;
@@ -1167,9 +1201,10 @@ static SIMPLE_DEV_PM_OPS(mixer_pm_ops, mixer_suspend,
NULL);
struct platform_driver mixer_driver = {
.driver = {
- .name = "s5p-mixer",
+ .name = "exynos-mixer",
.owner = THIS_MODULE,
.pm = &mixer_pm_ops,
+ .of_match_table = mixer_match_types,
},
.probe = mixer_probe,
.remove = __devexit_p(mixer_remove),
diff --git a/drivers/gpu/drm/exynos/regs-mixer.h
b/drivers/gpu/drm/exynos/regs-mixer.h
index fd2f4d1..6ee60be 100644
--- a/drivers/gpu/drm/exynos/regs-mixer.h
+++ b/drivers/gpu/drm/exynos/regs-mixer.h
@@ -69,6 +69,7 @@
(((val) << (low_bit)) & MXR_MASK(high_bit, low_bit))
/* bits for MXR_STATUS */
+#define MXR_STATUS_SOFT_RESET (1 << 8)
#define MXR_STATUS_16_BURST(1 << 7)
#define MXR_STATUS_BURST_MASK (1 << 7)
#define MXR_STATUS_BIG_ENDIAN (1 << 3)
@@ -77,6 +78,7 @@
#define MXR_STATUS_REG_RUN (1 << 0)
/* bits for MXR_CFG */
+#define MXR_CFG_LAYER_UPDATE (1 << 31)
#define MXR_CFG_RGB601_0_255 (0 << 9)
#define MXR_CFG_RGB601_16_235 (1 << 9)
#define MXR_CFG_RGB709_0_255 (2 << 9)
--
1.7.0.4
[PATCH 10/14] drm: exynos: hdmi: add support to disable video processor in mixer
This patch adds support for disabling the video processor code based
on the platform type. This is done based on a field in the mixer driver
data which changes with the platform variant.
Signed-off-by: Rahul Sharma
---
drivers/gpu/drm/exynos/exynos_mixer.c | 151 +
1 files changed, 98 insertions(+), 53 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 30233a3..ff2a45d 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -84,6 +84,7 @@ struct mixer_context {
int pipe;
boolinterlace;
boolpowered;
+ boolvp_enabled;
u32 int_en;
struct mutexmixer_mutex;
@@ -94,6 +95,7 @@ struct mixer_context {
struct mixer_drv_data {
enum mixer_version_id version;
+ boolis_vp_enabled;
};
static const u8 filter_y_horiz_tap8[] = {
@@ -262,7 +264,8 @@ static void mixer_vsync_set_update(struct mixer_context
*ctx, bool enable)
mixer_reg_writemask(res, MXR_STATUS, enable ?
MXR_STATUS_SYNC_ENABLE : 0, MXR_STATUS_SYNC_ENABLE);
- vp_reg_write(res, VP_SHADOW_UPDATE, enable ?
+ if (ctx->vp_enabled)
+ vp_reg_write(res, VP_SHADOW_UPDATE, enable ?
VP_SHADOW_UPDATE_ENABLE : 0);
}
@@ -344,8 +347,11 @@ static void mixer_cfg_layer(struct mixer_context *ctx, int
win, bool enable)
mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_GRP1_ENABLE);
break;
case 2:
- vp_reg_writemask(res, VP_ENABLE, val, VP_ENABLE_ON);
- mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_VP_ENABLE);
+ if (ctx->vp_enabled) {
+ vp_reg_writemask(res, VP_ENABLE, val, VP_ENABLE_ON);
+ mixer_reg_writemask(res, MXR_CFG, val,
+ MXR_CFG_VP_ENABLE);
+ }
break;
}
}
@@ -603,7 +609,8 @@ static void mixer_win_reset(struct mixer_context *ctx)
*/
val = MXR_LAYER_CFG_GRP1_VAL(3);
val |= MXR_LAYER_CFG_GRP0_VAL(2);
- val |= MXR_LAYER_CFG_VP_VAL(1);
+ if (ctx->vp_enabled)
+ val |= MXR_LAYER_CFG_VP_VAL(1);
mixer_reg_write(res, MXR_LAYER_CFG, val);
/* setting background color */
@@ -626,14 +633,17 @@ static void mixer_win_reset(struct mixer_context *ctx)
val = MXR_GRP_CFG_ALPHA_VAL(0);
mixer_reg_write(res, MXR_VIDEO_CFG, val);
- /* configuration of Video Processor Registers */
- vp_win_reset(ctx);
- vp_default_filter(res);
+ if (ctx->vp_enabled) {
+ /* configuration of Video Processor Registers */
+ vp_win_reset(ctx);
+ vp_default_filter(res);
+ }
/* disable all layers */
mixer_reg_writemask(res, MXR_CFG, 0, MXR_CFG_GRP0_ENABLE);
mixer_reg_writemask(res, MXR_CFG, 0, MXR_CFG_GRP1_ENABLE);
- mixer_reg_writemask(res, MXR_CFG, 0, MXR_CFG_VP_ENABLE);
+ if (ctx->vp_enabled)
+ mixer_reg_writemask(res, MXR_CFG, 0, MXR_CFG_VP_ENABLE);
mixer_vsync_set_update(ctx, true);
spin_unlock_irqrestore(&res->reg_slock, flags);
@@ -656,8 +666,10 @@ static void mixer_poweron(struct mixer_context *ctx)
pm_runtime_get_sync(ctx->dev);
clk_enable(res->mixer);
- clk_enable(res->vp);
- clk_enable(res->sclk_mixer);
+ if (ctx->vp_enabled) {
+ clk_enable(res->vp);
+ clk_enable(res->sclk_mixer);
+ }
mixer_reg_write(res, MXR_INT_EN, ctx->int_en);
mixer_win_reset(ctx);
@@ -677,8 +689,10 @@ static void mixer_poweroff(struct mixer_context *ctx)
ctx->int_en = mixer_reg_read(res, MXR_INT_EN);
clk_disable(res->mixer);
- clk_disable(res->vp);
- clk_disable(res->sclk_mixer);
+ if (ctx->vp_enabled) {
+ clk_disable(res->vp);
+ clk_disable(res->sclk_mixer);
+ }
pm_runtime_put_sync(ctx->dev);
@@ -811,7 +825,7 @@ static void mixer_win_commit(void *ctx, int win)
DRM_DEBUG_KMS("[%d] %s, win: %d\n", __LINE__, __func__, win);
- if (win > 1)
+ if (win > 1 && mixer_ctx->vp_enabled)
vp_video_buffer(mixer_ctx, win);
else
mixer_graph_buffer(mixer_ctx, win);
@@ -947,39 +961,20 @@ static int __devinit mixer_resources_init(struct
exynos_drm_hdmi_context *ctx,
ret = -ENODEV;
goto fail;
}
- mixer_res->vp = clk_get(dev, "vp");
- if (IS_ERR_OR_NULL(mixer_res->vp)) {
- dev_err(dev, "failed to get clock 'vp'\n");
- ret = -ENODEV;
- goto fail;
- }
- mixer_res->sclk_mixer = clk_get(dev,
[PATCH 09/14] drm: exynos: hdmi: add support for platform variants for mixer
This patch adds the support for multiple mixer versions avaialble in
various platform variants. Version is passed as a driver data field
instead of paltform data.
Signed-off-by: Rahul Sharma
---
drivers/gpu/drm/exynos/exynos_mixer.c | 28
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 8a43ee1..30233a3 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -73,6 +73,12 @@ struct mixer_resources {
struct clk *sclk_dac;
};
+enum mixer_version_id {
+ MXR_VER_INVALID = -1,
+ MXR_VER_0_0_0_16,
+ MXR_VER_16_0_33_0,
+};
+
struct mixer_context {
struct device *dev;
int pipe;
@@ -83,6 +89,11 @@ struct mixer_context {
struct mutexmixer_mutex;
struct mixer_resources mixer_res;
struct hdmi_win_datawin_data[MIXER_WIN_NR];
+ enum mixer_version_id mxr_ver;
+};
+
+struct mixer_drv_data {
+ enum mixer_version_id version;
};
static const u8 filter_y_horiz_tap8[] = {
@@ -1023,11 +1034,24 @@ fail:
return ret;
}
+static struct mixer_drv_data exynos4_mxr_drv_data = {
+ .version = MXR_VER_0_0_0_16,
+};
+static struct platform_device_id mixer_driver_types[] = {
+ {
+ .name = "s5p-mixer",
+ .driver_data= (unsigned long)&exynos4_mxr_drv_data,
+ }, {
+ /* end node */
+ }
+};
+
static int __devinit mixer_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct exynos_drm_hdmi_context *drm_hdmi_ctx;
struct mixer_context *ctx;
+ struct mixer_drv_data *drv;
int ret;
dev_info(dev, "probe start\n");
@@ -1047,8 +1071,11 @@ static int __devinit mixer_probe(struct platform_device
*pdev)
mutex_init(&ctx->mixer_mutex);
+ drv = (struct mixer_drv_data *)platform_get_device_id(
+ pdev)->driver_data;
ctx->dev = &pdev->dev;
drm_hdmi_ctx->ctx = (void *)ctx;
+ ctx->mxr_ver = drv->version;
platform_set_drvdata(pdev, drm_hdmi_ctx);
@@ -1101,4 +1128,5 @@ struct platform_driver mixer_driver = {
},
.probe = mixer_probe,
.remove = __devexit_p(mixer_remove),
+ .id_table = mixer_driver_types,
};
--
1.7.0.4
[PATCH 08/14] drm: exynos: hdmi: add support for exynos5 hdmiphy
This patch adds support for exynos5 hdmi phy with device tree enabled.
Signed-off-by: Rahul Sharma
---
drivers/gpu/drm/exynos/exynos_hdmiphy.c | 12 +++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmiphy.c
b/drivers/gpu/drm/exynos/exynos_hdmiphy.c
index 9fe2995..a33073b 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmiphy.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmiphy.c
@@ -42,13 +42,23 @@ static int hdmiphy_remove(struct i2c_client *client)
static const struct i2c_device_id hdmiphy_id[] = {
{ "s5p_hdmiphy", 0 },
+ { "exynos5-hdmiphy", 0 },
{ },
};
+static struct of_device_id hdmiphy_match_types[] = {
+ {
+ .compatible = "samsung,exynos5-hdmiphy",
+ }, {
+ /* end node */
+ }
+};
+
struct i2c_driver hdmiphy_driver = {
.driver = {
- .name = "s5p-hdmiphy",
+ .name = "exynos-hdmiphy",
.owner = THIS_MODULE,
+ .of_match_table = hdmiphy_match_types,
},
.id_table = hdmiphy_id,
.probe = hdmiphy_probe,
--
1.7.0.4
[PATCH 07/14] drm: exynos: hdmi: add support for exynos5 ddc
This patch adds support for exynos5 ddc with device tree enabled.
Signed-off-by: Rahul Sharma
---
drivers/gpu/drm/exynos/exynos_ddc.c | 22 +-
1 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_ddc.c
b/drivers/gpu/drm/exynos/exynos_ddc.c
index 7e1051d..ef28779 100644
--- a/drivers/gpu/drm/exynos/exynos_ddc.c
+++ b/drivers/gpu/drm/exynos/exynos_ddc.c
@@ -26,29 +26,41 @@ static int s5p_ddc_probe(struct i2c_client *client,
{
hdmi_attach_ddc_client(client);
- dev_info(&client->adapter->dev, "attached s5p_ddc "
- "into i2c adapter successfully\n");
+ dev_info(&client->adapter->dev,
+ "attached %s into i2c adapter successfully\n",
+ client->name);
return 0;
}
static int s5p_ddc_remove(struct i2c_client *client)
{
- dev_info(&client->adapter->dev, "detached s5p_ddc "
- "from i2c adapter successfully\n");
+ dev_info(&client->adapter->dev,
+ "detached %s from i2c adapter successfully\n",
+ client->name);
return 0;
}
static struct i2c_device_id ddc_idtable[] = {
{"s5p_ddc", 0},
+ {"exynos5-hdmiddc", 0},
{ },
};
+static struct of_device_id hdmiddc_match_types[] = {
+ {
+ .compatible = "samsung,exynos5-hdmiddc",
+ }, {
+ /* end node */
+ }
+};
+
struct i2c_driver ddc_driver = {
.driver = {
- .name = "s5p_ddc",
+ .name = "exynos-hdmiddc",
.owner = THIS_MODULE,
+ .of_match_table = hdmiddc_match_types,
},
.id_table = ddc_idtable,
.probe = s5p_ddc_probe,
--
1.7.0.4
[PATCH 06/14] drm: exynos: remove drm hdmi platform data struct
This patch removes the drm hdmi platform data structure which is no
longer in use by drm hdmi driver after this patch set get merged. s5p
hdmi platform data structure is used instead.
Signed-off-by: Rahul Sharma
---
include/drm/exynos_drm.h | 13 -
1 files changed, 0 insertions(+), 13 deletions(-)
diff --git a/include/drm/exynos_drm.h b/include/drm/exynos_drm.h
index 0d1c503..8bdd49a 100644
--- a/include/drm/exynos_drm.h
+++ b/include/drm/exynos_drm.h
@@ -254,18 +254,5 @@ struct exynos_drm_common_hdmi_pd {
struct device *mixer_dev;
};
-/**
- * Platform Specific Structure for DRM based HDMI core.
- *
- * @is_v13: set if hdmi version 13 is.
- * @cfg_hpd: function pointer to configure hdmi hotplug detection pin
- * @get_hpd: function pointer to get value of hdmi hotplug detection pin
- */
-struct exynos_drm_hdmi_pdata {
- bool is_v13;
- void (*cfg_hpd)(bool external);
- int (*get_hpd)(void);
-};
-
#endif /* __KERNEL__ */
#endif /* _EXYNOS_DRM_H_ */
--
1.7.0.4
[PATCH 05/14] drm: exynos: hdmi: turn off HPD interrupt in HDMI chip
From: Tomasz Stanislawski
The plug/unplug interrupt are handled by a separate interrupt.
So there is no need to replicate this mechanism in HDMI core.
Signed-off-by: Tomasz Stanislawski
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_hdmi.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 90dce8c..e3ab840 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1532,12 +1532,9 @@ static void hdmi_conf_reset(struct hdmi_context *hdata)
static void hdmi_conf_init(struct hdmi_context *hdata)
{
- /* enable HPD interrupts */
+ /* disable HPD interrupts */
hdmi_reg_writemask(hdata, HDMI_INTC_CON, 0, HDMI_INTC_EN_GLOBAL |
HDMI_INTC_EN_HPD_PLUG | HDMI_INTC_EN_HPD_UNPLUG);
- mdelay(10);
- hdmi_reg_writemask(hdata, HDMI_INTC_CON, ~0, HDMI_INTC_EN_GLOBAL |
- HDMI_INTC_EN_HPD_PLUG | HDMI_INTC_EN_HPD_UNPLUG);
/* choose HDMI mode */
hdmi_reg_writemask(hdata, HDMI_MODE_SEL,
--
1.7.0.4
[PATCH 04/14] drm: exynos: hdmi: use s5p-hdmi platform data
From: Tomasz Stanislawski
The 'exynos-drm-hdmi' driver makes use of s5p-tv platform devices. Therefore
the driver should use the same platform data to prevent crashes caused by
dereferencing incorrect types. This patch corrects the exynos-drm-hdmi driver
to the platform data from s5p-hdmi.
Signed-off-by: Tomasz Stanislawski
Signed-off-by: Joonyoung Shim
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 55 +++---
1 files changed, 24 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 3902917..90dce8c 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -40,6 +40,9 @@
#include "exynos_hdmi.h"
+#include
+#include
+
#define MAX_WIDTH 1920
#define MAX_HEIGHT 1080
#define get_hdmi_context(dev) platform_get_drvdata(to_platform_device(dev))
@@ -76,8 +79,7 @@ struct hdmi_context {
struct hdmi_resources res;
void*parent_ctx;
- void(*cfg_hpd)(bool external);
- int (*get_hpd)(void);
+ int hpd_gpio;
};
/* HDMI Version 1.3 */
@@ -2024,8 +2026,6 @@ static void hdmi_poweron(struct hdmi_context *hdata)
hdata->powered = true;
- if (hdata->cfg_hpd)
- hdata->cfg_hpd(true);
mutex_unlock(&hdata->hdmi_mutex);
pm_runtime_get_sync(hdata->dev);
@@ -2061,8 +2061,6 @@ static void hdmi_poweroff(struct hdmi_context *hdata)
pm_runtime_put_sync(hdata->dev);
mutex_lock(&hdata->hdmi_mutex);
- if (hdata->cfg_hpd)
- hdata->cfg_hpd(false);
hdata->powered = false;
@@ -2110,17 +2108,13 @@ static irqreturn_t hdmi_external_irq_thread(int irq,
void *arg)
struct exynos_drm_hdmi_context *ctx = arg;
struct hdmi_context *hdata = ctx->ctx;
- if (!hdata->get_hpd)
- goto out;
-
mutex_lock(&hdata->hdmi_mutex);
- hdata->hpd = hdata->get_hpd();
+ hdata->hpd = gpio_get_value(hdata->hpd_gpio);
mutex_unlock(&hdata->hdmi_mutex);
if (ctx->drm_dev)
drm_helper_hpd_irq_event(ctx->drm_dev);
-out:
return IRQ_HANDLED;
}
@@ -2143,18 +2137,9 @@ static irqreturn_t hdmi_internal_irq_thread(int irq,
void *arg)
HDMI_INTC_FLAG_HPD_PLUG);
}
- mutex_lock(&hdata->hdmi_mutex);
- hdata->hpd = hdmi_reg_read(hdata, HDMI_HPD_STATUS);
- if (hdata->powered && hdata->hpd) {
- mutex_unlock(&hdata->hdmi_mutex);
- goto out;
- }
- mutex_unlock(&hdata->hdmi_mutex);
-
if (ctx->drm_dev)
drm_helper_hpd_irq_event(ctx->drm_dev);
-out:
return IRQ_HANDLED;
}
@@ -2287,7 +2272,7 @@ static int __devinit hdmi_probe(struct platform_device
*pdev)
struct device *dev = &pdev->dev;
struct exynos_drm_hdmi_context *drm_hdmi_ctx;
struct hdmi_context *hdata;
- struct exynos_drm_hdmi_pdata *pdata;
+ struct s5p_hdmi_platform_data *pdata;
struct resource *res;
int ret;
enum hdmi_type hdmi_type;
@@ -2323,8 +2308,7 @@ static int __devinit hdmi_probe(struct platform_device
*pdev)
hdmi_type = platform_get_device_id(pdev)->driver_data;
hdata->is_v13 = (hdmi_type == HDMI_TYPE13);
- hdata->cfg_hpd = pdata->cfg_hpd;
- hdata->get_hpd = pdata->get_hpd;
+ hdata->hpd_gpio = pdata->hpd_gpio;
hdata->dev = dev;
ret = hdmi_resources_init(hdata);
@@ -2342,11 +2326,17 @@ static int __devinit hdmi_probe(struct platform_device
*pdev)
goto err_resource;
}
+ ret = gpio_request(hdata->hpd_gpio, "HPD");
+ if (ret) {
+ DRM_ERROR("failed to request HPD gpio\n");
+ goto err_resource;
+ }
+
/* DDC i2c driver */
if (i2c_add_driver(&ddc_driver)) {
DRM_ERROR("failed to register ddc i2c driver\n");
ret = -ENOENT;
- goto err_resource;
+ goto err_gpio;
}
hdata->ddc_port = hdmi_ddc;
@@ -2360,32 +2350,31 @@ static int __devinit hdmi_probe(struct platform_device
*pdev)
hdata->hdmiphy_port = hdmi_hdmiphy;
- hdata->external_irq = platform_get_irq_byname(pdev, "external_irq");
+ hdata->external_irq = gpio_to_irq(hdata->hpd_gpio);
if (hdata->external_irq < 0) {
- DRM_ERROR("failed to get platform irq\n");
+ DRM_ERROR("failed to get GPIO external irq\n");
ret = hdata->external_irq;
goto err_hdmiphy;
}
- hdata->internal_irq = platform_get_irq_byname(pdev, "internal_irq");
+ hdata->internal_irq = platform_get_irq(pdev, 0);
if (hdata->internal_irq < 0) {
DRM_ERROR("f
[PATCH 03/14] drm: exynos: hdmi: fix interrupt handling
From: Tomasz Stanislawski
This patch fixes 'unsigned < 0' check in probe. Moreover it
releases an interrupt at remove.
Signed-off-by: Tomasz Stanislawski
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_hdmi.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index b3a802b..3902917 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -64,8 +64,8 @@ struct hdmi_context {
struct mutexhdmi_mutex;
void __iomem*regs;
- unsigned intexternal_irq;
- unsigned intinternal_irq;
+ int external_irq;
+ int internal_irq;
struct i2c_client *ddc_port;
struct i2c_client *hdmiphy_port;
@@ -2424,6 +2424,7 @@ static int __devexit hdmi_remove(struct platform_device
*pdev)
pm_runtime_disable(dev);
free_irq(hdata->internal_irq, hdata);
+ free_irq(hdata->external_irq, hdata);
hdmi_resources_cleanup(hdata);
--
1.7.0.4
[PATCH 02/14] drm: exynos: hdmi: support for platform variants
From: Tomasz Stanislawski
This patch implements check if HDMI is version 1.3 by using a driver variant
instead of platform data.
Signed-off-by: Tomasz Stanislawski
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 25 -
1 files changed, 24 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index a6aea6f..b3a802b 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -2262,6 +2262,26 @@ void hdmi_attach_hdmiphy_client(struct i2c_client
*hdmiphy)
hdmi_hdmiphy = hdmiphy;
}
+enum hdmi_type {
+ HDMI_TYPE13,
+ HDMI_TYPE14,
+};
+
+static struct platform_device_id hdmi_driver_types[] = {
+ {
+ .name = "s5pv210-hdmi",
+ .driver_data= HDMI_TYPE13,
+ }, {
+ .name = "exynos4-hdmi",
+ .driver_data= HDMI_TYPE13,
+ }, {
+ .name = "exynos4-hdmi14",
+ .driver_data= HDMI_TYPE14,
+ }, {
+ /* end node */
+ }
+};
+
static int __devinit hdmi_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -2270,6 +2290,7 @@ static int __devinit hdmi_probe(struct platform_device
*pdev)
struct exynos_drm_hdmi_pdata *pdata;
struct resource *res;
int ret;
+ enum hdmi_type hdmi_type;
DRM_DEBUG_KMS("[%d]\n", __LINE__);
@@ -2300,7 +2321,8 @@ static int __devinit hdmi_probe(struct platform_device
*pdev)
platform_set_drvdata(pdev, drm_hdmi_ctx);
- hdata->is_v13 = pdata->is_v13;
+ hdmi_type = platform_get_device_id(pdev)->driver_data;
+ hdata->is_v13 = (hdmi_type == HDMI_TYPE13);
hdata->cfg_hpd = pdata->cfg_hpd;
hdata->get_hpd = pdata->get_hpd;
hdata->dev = dev;
@@ -2447,6 +2469,7 @@ static SIMPLE_DEV_PM_OPS(hdmi_pm_ops, hdmi_suspend,
hdmi_resume);
struct platform_driver hdmi_driver = {
.probe = hdmi_probe,
.remove = __devexit_p(hdmi_remove),
+ .id_table = hdmi_driver_types,
.driver = {
.name = "exynos4-hdmi",
.owner = THIS_MODULE,
--
1.7.0.4
[PATCH 01/14] media: s5p-hdmi: add HPD GPIO to platform data
From: Tomasz Stanislawski
This patch extends s5p-hdmi platform data by a GPIO identifier for
Hot-Plug-Detection pin.
Signed-off-by: Tomasz Stanislawski
Signed-off-by: Kyungmin Park
---
include/media/s5p_hdmi.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/media/s5p_hdmi.h b/include/media/s5p_hdmi.h
index 361a751..181642b 100644
--- a/include/media/s5p_hdmi.h
+++ b/include/media/s5p_hdmi.h
@@ -20,6 +20,7 @@ struct i2c_board_info;
* @hdmiphy_info: template for HDMIPHY I2C device
* @mhl_bus: controller id for MHL control bus
* @mhl_info: template for MHL I2C device
+ * @hpd_gpio: GPIO for Hot-Plug-Detect pin
*
* NULL pointer for *_info fields indicates that
* the corresponding chip is not present
@@ -29,6 +30,7 @@ struct s5p_hdmi_platform_data {
struct i2c_board_info *hdmiphy_info;
int mhl_bus;
struct i2c_board_info *mhl_info;
+ int hpd_gpio;
};
#endif /* S5P_HDMI_H */
--
1.7.0.4
[PATCH 00/14] drm: exynos: hdmi: add dt based support for exynos5 hdmi
This patch set adds the DT based support for Samsung's Exynos5250 in DRM-HDMI. It includes disabling of hdmi internal interrupt, suppport for platform variants for hdmi and mixer, support to disable video processor based on platform type and removal of drm common platform data. Rahul Sharma (9): drm: exynos: remove drm hdmi platform data struct drm: exynos: hdmi: add support for exynos5 ddc drm: exynos: hdmi: add support for exynos5 hdmiphy drm: exynos: hdmi: add support for platform variants for mixer drm: exynos: hdmi: add support to disable video processor in mixer drm: exynos: hdmi: add support for exynos5 mixer drm: exynos: hdmi: replace is_v13 with version check in hdmi drm: exynos: hdmi: add support for exynos5 hdmi drm: exynos: hdmi: remove drm common hdmi platform data struct Tomasz Stanislawski (5): media: s5p-hdmi: add HPD GPIO to platform data drm: exynos: hdmi: support for platform variants drm: exynos: hdmi: fix interrupt handling drm: exynos: hdmi: use s5p-hdmi platform data drm: exynos: hdmi: turn off HPD interrupt in HDMI chip drivers/gpu/drm/exynos/exynos_ddc.c | 22 +++- drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 51 drivers/gpu/drm/exynos/exynos_drm_hdmi.h |2 + drivers/gpu/drm/exynos/exynos_hdmi.c | 196 --- drivers/gpu/drm/exynos/exynos_hdmiphy.c | 12 ++- drivers/gpu/drm/exynos/exynos_mixer.c| 219 ++ drivers/gpu/drm/exynos/regs-mixer.h |2 + include/drm/exynos_drm.h | 27 include/media/s5p_hdmi.h |2 + 9 files changed, 369 insertions(+), 164 deletions(-)
FOSDEM2013: DevRoom or not?
On Fri, Sep 28, 2012 at 6:07 PM, Jesse Barnes wrote: > On Fri, 28 Sep 2012 17:44:27 +0200 > Luc Verhaegen wrote: > >> On Fri, Sep 21, 2012 at 11:35:12AM +0200, Luc Verhaegen wrote: >> > On Sun, Aug 12, 2012 at 03:50:16PM +0200, Luc Verhaegen wrote: >> > > Hi, >> > > >> > > The FOSDEM organizers have sent out a call for devrooms. FOSDEM this >> > > year is on the weekend of the 2nd and 3rd of February 2013. >> > > >> > > After the success of this formula last year, where, for the first time >> > > ever, we had a properly filled devroom schedule when the deadline hit, i >> > > am going to re-apply the same formula: >> > > * By the 28th of september, i need 6 committed speakers, otherwise i >> > > will not apply for a DevRoom. 6 people need to apply for a talk slot >> > > who _definitely_ will come to FOSDEM on February 2nd and/or 3rd 2013. >> > > This "definitely" means: >> > > * Don't knowingly plan anything else for this weekend. >> > > * Come to FOSDEM even if your corporation does not fund you (though >> > > feel free to contact the board individually for funding) >> > > * Make sure that you are allowed to travel to the shengen area in >> > > february. >> > > * Catastrophies excluded of course. Such catastrophies include >> > > things like train-derailments and such, but explicitely excludes >> > > hangovers :p >> > > * Scheduling based on timeliness of application: the earlier you apply, >> > > the better slot you get. >> > > * FOSDEMs final deadline for the full schedule is likely around 15th of >> > > january 2013. But do not count on that deadline, we will only do >> > > hourly slots, to keep people from running around between devrooms like >> > > headless chickens. Only 12-16 slots will be available, first come, >> > > first serve. >> > > >> > > I will set up a wiki page tonight, at http://wiki.x.org/wiki/fosdem2013 >> > > >> > > I hope we get a nice devroom like we had last time. That new building we >> > > were in was really amazing, even though it took a while before all >> > > FOSDEM visitors found it. >> > > >> > > Thanks, >> > > >> > > Luc Verhaegen. >> > >> > Just a heads up guys, we have a week left and not a single speaker yet! >> > >> > Given the timing of XDC and the FOSDEM deadines, this is not too >> > surprising, but still, with XDC2012 in its final day it is high time >> > that we start thinking about FOSDEM. I will later on shout at people >> > here in the room too :) >> > >> > All we need now is people who will definitely come to FOSDEM, and who >> > are willing to talk in the DevRoom. If a vague idea of a topic is >> > already known, then great, but this is not necessary yet. I now put up a >> > preliminary wiki page at wiki.x.org/wiki/fosdem2013, add yourself to the >> > list there. >> > >> > Thanks, >> > >> > Luc Verhaegen. >> >> Final reminder: the deadline is tonight. >> >> So far there are three speakers who lined up, and my feeling is that >> Matthieu and Marc lined up just so that the deadline and requirement >> will be met. So only a single person is intending to come to fosdem and >> has a topic he wants to talk about. >> >> Come on guys. Surely we can do better than that. > > I could come up with something, maybe people would be interested in > hearing about some of our recent SoC work? I'd have to see what I > could get approval for, but I could probably find *something* that's > not still secret. :) Ok, ok, I'll volunteer myself for another a talk about something kernel-ish. Maybe and update on drm/i915 modesettting stuff (we should be able to check off a lot of the todos from the xdc slides by then) or maybe a talk about drm/i915 testing efforts (yeah, a lot has been happening there without much publicity this year). Or something else. To make the intel roundup complete: Chris, can I volunteer you to give another stab at an "updates from flatland" talk? Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 55416] [R600g] Torchlight gives GPU lockup
https://bugs.freedesktop.org/show_bug.cgi?id=55416 --- Comment #3 from Anthony Waters --- I bisected this a few days ago, the commit that causes the issue is c8b06dccff9cb89e20378664f3cbc202876a180f r600g: atomize framebuffer state -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/5] reservation: cross-device reservation support
Op 28-09-12 17:29, Thomas Hellstr?m schreef: > On 9/28/12 2:43 PM, Maarten Lankhorst wrote: >> This adds support for a generic reservations framework that can be >> hooked up to ttm and dma-buf and allows easy sharing of reservations >> across devices. >> >> The idea is that a dma-buf and ttm object both will get a pointer >> to a struct reservation_object, which has to be reserved before >> anything is done with the buffer. > "Anything is done with the buffer" should probably be rephrased, as different > members of the buffer struct > may be protected by different locks. It may not be practical or even possible > to > protect all buffer members with reservation. Agreed. >> Some followup patches are needed in ttm so the lru_lock is no longer >> taken during the reservation step. This makes the lockdep annotation >> patch a lot more useful, and the assumption that the lru lock protects >> atomic removal off the lru list will fail soon, anyway. > As previously discussed, I'm unfortunately not prepared to accept removal of > the reserve-lru atomicity > into the TTM code at this point. > The current code is based on this assumption and removing it will end up with > efficiencies, breaking the delayed delete code and probably a locking > nightmare when trying to write > new TTM code. The lru lock removal patch fixed the delayed delete code, it really is not different from the current situation. In fact it is more clear without the guarantee what various parts are trying to protect. Nothing prevents you from holding the lru_lock while trylocking, leaving that guarantee intact for that part. Can you really just review the patch and tell me where it breaks and/or makes the code unreadable? See my preemptive reply to patch 1/5 for details. I would prefer you followup there. :-) ~Maarten
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Add HDMI vendor info frame support
On Thu, Sep 27, 2012 at 3:41 PM, Damien Lespiau
wrote:
> From: Damien Lespiau
>
> When scanning out a 3D framebuffer, send the corresponding infoframe to
> the HDMI sink.
>
> See http://www.hdmi.org/manufacturer/specification.aspx for details.
>
> Signed-off-by: Damien Lespiau
> ---
> drivers/gpu/drm/i915/intel_drv.h | 14 +++
> drivers/gpu/drm/i915/intel_hdmi.c | 49
> +-
> drivers/gpu/drm/i915/intel_modes.c | 12 ++
> 3 files changed, 74 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index cd54cf8..c326d30e 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -263,6 +263,13 @@ struct cxsr_latency {
> #define DIP_SPD_BD 0xa
> #define DIP_SPD_SCD0xb
>
> +#define DIP_TYPE_VENDOR0x81
> +#define DIP_VERSION_VENDOR 0x1
> +#define DIP_HDMI_3D_PRESENT(0x2<<5)
> +#define DIP_HDMI_3D_STRUCT_FP (0x0<<4)
> +#define DIP_HDMI_3D_STRUCT_TB (0x6<<4)
> +#define DIP_HDMI_3D_STRUCT_SBSH(0x8<<4)
> +
> struct dip_infoframe {
> uint8_t type; /* HB0 */
> uint8_t ver;/* HB1 */
> @@ -292,6 +299,12 @@ struct dip_infoframe {
> uint8_t pd[16];
> uint8_t sdi;
> } __attribute__ ((packed)) spd;
> + struct {
> + uint8_t vendor_id[3];
> + uint8_t video_format;
> + uint8_t s3d_struct;
> + uint8_t s3d_ext_data;
> + } __attribute__ ((packed)) hdmi;
> uint8_t payload[27];
> } __attribute__ ((packed)) body;
> } __attribute__((packed));
> @@ -348,6 +361,7 @@ int intel_ddc_get_modes(struct drm_connector *c, struct
> i2c_adapter *adapter);
>
> extern void intel_attach_force_audio_property(struct drm_connector
> *connector);
> extern void intel_attach_broadcast_rgb_property(struct drm_connector
> *connector);
> +extern void intel_attach_expose_3d_modes_property(struct drm_connector
> *connector);
>
> extern void intel_crt_init(struct drm_device *dev);
> extern void intel_hdmi_init(struct drm_device *dev, int sdvox_reg);
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 98f6024..2d51b7e 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -83,6 +83,8 @@ static u32 g4x_infoframe_index(struct dip_infoframe *frame)
> return VIDEO_DIP_SELECT_AVI;
> case DIP_TYPE_SPD:
> return VIDEO_DIP_SELECT_SPD;
> + case DIP_TYPE_VENDOR:
> + return VIDEO_DIP_SELECT_VENDOR;
> default:
> DRM_DEBUG_DRIVER("unknown info frame type %d\n", frame->type);
> return 0;
> @@ -96,6 +98,8 @@ static u32 g4x_infoframe_enable(struct dip_infoframe *frame)
> return VIDEO_DIP_ENABLE_AVI;
> case DIP_TYPE_SPD:
> return VIDEO_DIP_ENABLE_SPD;
> + case DIP_TYPE_VENDOR:
> + return VIDEO_DIP_ENABLE_VENDOR;
> default:
> DRM_DEBUG_DRIVER("unknown info frame type %d\n", frame->type);
> return 0;
> @@ -338,6 +342,42 @@ static void intel_hdmi_set_spd_infoframe(struct
> drm_encoder *encoder)
> intel_set_infoframe(encoder, &spd_if);
> }
>
> +static void intel_hdmi_set_hdmi_infoframe(struct drm_encoder *encoder,
> + struct drm_display_mode
> *adjusted_mode)
> +{
> + struct dip_infoframe hdmi_if;
> +
> + /* We really only need to send a HDMI vendor info frame when having
> +* a 3D format to describe */
> + if (!(adjusted_mode->flags & DRM_MODE_FLAG_3D_MASK))
> + return;
> +
> + memset(&hdmi_if, 0, sizeof(hdmi_if));
> + hdmi_if.type = DIP_TYPE_VENDOR;
> + hdmi_if.ver = DIP_VERSION_VENDOR;
> + /* HDMI IEEE registration id, least significant bit first */
> + hdmi_if.body.hdmi.vendor_id[0] = 0x03;
> + hdmi_if.body.hdmi.vendor_id[1] = 0x0c;
> + hdmi_if.body.hdmi.vendor_id[2] = 0x00;
> + hdmi_if.body.hdmi.video_format = DIP_HDMI_3D_PRESENT;
> + if (adjusted_mode->flags & DRM_MODE_FLAG_3D_FRAME_PACKING)
> + hdmi_if.body.hdmi.s3d_struct = DIP_HDMI_3D_STRUCT_FP;
> + else if (adjusted_mode->flags & DRM_MODE_FLAG_3D_TOP_BOTTOM)
> + hdmi_if.body.hdmi.s3d_struct = DIP_HDMI_3D_STRUCT_TB;
> + else if (adjusted_mode->flags & DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF)
> + hdmi_if.body.hdmi.s3d_struct = DIP_HDMI_3D_STRUCT_SBSH;
> + /* len is the payload len, not including checksum. Side by side (half)
> +* has an extra byte for 3D_Ext_Data */
> + if (adjusted_mode->flags & DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF) {
> + hdmi_if.len = 6;
> + /*
Re: [PATCH 2/3] drm: Parse the HDMI cea vendor block for 3D present
Reviewed-by: Rodrigo Vivi
Tested-by: Rodrigo Vivi
On Thu, Sep 27, 2012 at 3:41 PM, Damien Lespiau
wrote:
> From: Damien Lespiau
>
> For now, let's just look at the 3D_present flag of the CEA HDMI vendor
> block to detect if the sink supports a small list of then mandatory 3D
> formats.
>
> See the HDMI 1.4a 3D extraction for detail:
> http://www.hdmi.org/manufacturer/specification.aspx
>
> Signed-off-by: Damien Lespiau
> ---
> drivers/gpu/drm/drm_edid.c | 87
> --
> include/drm/drm_mode.h | 35 +++
> 2 files changed, 105 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index b7ee230..7eecfa0 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1522,21 +1522,102 @@ do_cea_modes (struct drm_connector *connector, u8
> *db, u8 len)
> return modes;
> }
>
> +static bool cea_hdmi_3d_present(u8 *hdmi)
> +{
> + u8 len, skip = 0;
> +
> + len = hdmi[0] & 0x1f;
> +
> + if (len < 8)
> + return false;
> +
> + /* no HDMI_Video_present */
> + if (!(hdmi[8] & (1<<5)))
> + return false;
> +
> + /* Latency_fields_present */
> + if (hdmi[8] & (1 << 7))
> + skip += 2;
> +
> + /* I_Latency_fields_present */
> + if (hdmi[8] & (1 << 6))
> + skip += 2;
> +
> + /* the declared length is not long enough */
> + if (len < (9 + skip))
> + return false;
> +
> + return (hdmi[9 + skip] & (1 << 7)) != 0;
> +}
> +
> +static const struct {
> + int width, height, freq;
> + unsigned int select, value;
> + unsigned int formats;
> +} s3d_mandatory_modes[] = {
> + { 1920, 1080, 24, DRM_MODE_FLAG_INTERLACE, 0,
> + DRM_MODE_FLAG_3D_TOP_BOTTOM | DRM_MODE_FLAG_3D_FRAME_PACKING },
> + { 1920, 1080, 50, DRM_MODE_FLAG_INTERLACE, DRM_MODE_FLAG_INTERLACE,
> + DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF },
> + { 1920, 1080, 60, DRM_MODE_FLAG_INTERLACE, DRM_MODE_FLAG_INTERLACE,
> + DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF },
> + { 1280, 720, 50, DRM_MODE_FLAG_INTERLACE, 0,
> + DRM_MODE_FLAG_3D_TOP_BOTTOM | DRM_MODE_FLAG_3D_FRAME_PACKING },
> + { 1280, 720, 60, DRM_MODE_FLAG_INTERLACE, 0,
> + DRM_MODE_FLAG_3D_TOP_BOTTOM | DRM_MODE_FLAG_3D_FRAME_PACKING }
> +};
> +
> +static void cea_hdmi_patch_mandatory_3d_mode(struct drm_display_mode *mode)
> +{
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(s3d_mandatory_modes); i++) {
> + if (mode->hdisplay == s3d_mandatory_modes[i].width &&
> + mode->vdisplay == s3d_mandatory_modes[i].height &&
> + (mode->flags & s3d_mandatory_modes[i].select) ==
> + s3d_mandatory_modes[i].value &&
> + drm_mode_vrefresh(mode) == s3d_mandatory_modes[i].freq) {
> + mode->flags |= s3d_mandatory_modes[i].formats;
> + }
> + }
> +}
> +
> +static void cea_hdmi_patch_mandatory_3d_modes(struct drm_connector
> *connector)
> +{
> + struct drm_display_mode *mode;
> +
> + list_for_each_entry(mode, &connector->probed_modes, head)
> + cea_hdmi_patch_mandatory_3d_mode(mode);
> +}
> +
> static int
> add_cea_modes(struct drm_connector *connector, struct edid *edid)
> {
> u8 * cea = drm_find_cea_extension(edid);
> - u8 * db, dbl;
> - int modes = 0;
> + u8 * db, *hdmi = NULL, dbl;
> + int modes = 0, vendor_id;
>
> + /* let's find the cea modes before looking at the hdmi vendor block
> +* as the 3d_present flag needs to know about the supported modes
> +* to infer the 3D modes */
> if (cea && cea[1] >= 3) {
> for (db = cea + 4; db < cea + cea[2]; db += dbl + 1) {
> dbl = db[0] & 0x1f;
> - if (((db[0] & 0xe0) >> 5) == VIDEO_BLOCK)
> + switch ((db[0] & 0xe0) >> 5) {
> + case VIDEO_BLOCK:
> modes += do_cea_modes (connector, db+1, dbl);
> + break;
> + case VENDOR_BLOCK:
> + vendor_id = db[1] | db[2] << 8 | db[3] << 16;
> + if (vendor_id == HDMI_IDENTIFIER)
> + hdmi = db;
> + }
> }
> }
>
> + if (connector->expose_3d_modes && hdmi && cea_hdmi_3d_present(hdmi))
> + cea_hdmi_patch_mandatory_3d_modes(connector);
> +
> return modes;
> }
>
> diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
> index 45b19c6..d5d22de 100644
> --- a/include/drm/drm_mode.h
> +++ b/include/drm/drm_mode.h
> @@ -44,20 +44,27 @@
>
> /* Video mode flags */
> /* bit compatible with the xorg definitions. */
>
Re: [Intel-gfx] [PATCH 1/2] lib: Dump information about the supported 3D stereo formats
Reviewed-by: Rodrigo Vivi
Tested-by: Rodrigo Vivi
On Thu, Sep 27, 2012 at 3:42 PM, Damien Lespiau
wrote:
> From: Damien Lespiau
>
> When dumping the details of a mode, let's add the 3D formats the mode
> supports.
>
> Signed-off-by: Damien Lespiau
> ---
> lib/drmtest.c | 13 +++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/lib/drmtest.c b/lib/drmtest.c
> index 8df9797..4d5a67c 100644
> --- a/lib/drmtest.c
> +++ b/lib/drmtest.c
> @@ -812,7 +812,15 @@ unsigned int kmstest_create_fb(int fd, int width, int
> height, int bpp,
>
> void kmstest_dump_mode(drmModeModeInfo *mode)
> {
> - printf(" %s %d %d %d %d %d %d %d %d %d 0x%x 0x%x %d\n",
> + bool stereo_3d = mode->flags & DRM_MODE_FLAG_3D_MASK;
> + char flags_str[32];
> +
> + snprintf(flags_str, sizeof(flags_str), " (3D:%s%s%s)",
> +mode->flags & DRM_MODE_FLAG_3D_TOP_BOTTOM ? " TB": "",
> +mode->flags & DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF ? " SBSH":
> "",
> +mode->flags & DRM_MODE_FLAG_3D_FRAME_PACKING ? " FP": "");
> +
> + printf(" %s %d %d %d %d %d %d %d %d %d 0x%x 0x%x %d%s\n",
>mode->name,
>mode->vrefresh,
>mode->hdisplay,
> @@ -825,7 +833,8 @@ void kmstest_dump_mode(drmModeModeInfo *mode)
>mode->vtotal,
>mode->flags,
>mode->type,
> - mode->clock);
> + mode->clock,
> + stereo_3d ? flags_str : "");
> fflush(stdout);
> }
>
> --
> 1.7.11.4
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 1/3] drm: Add an "expose 3d modes" property
Reviewed-by: Rodrigo Vivi
Tested-by: Rodrigo Vivi
On Thu, Sep 27, 2012 at 3:41 PM, Damien Lespiau
wrote:
> From: Damien Lespiau
>
> The "expose 3D modes" property can be attached to connectors to allow
> user space to indicate it can deal with 3D modes and that the drm driver
> should expose those 3D modes.
>
> Signed-off-by: Damien Lespiau
> ---
> drivers/gpu/drm/drm_crtc.c | 35 ++-
> include/drm/drm_crtc.h | 6 ++
> include/drm/drm_mode.h | 4
> 3 files changed, 44 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 6fbfc24..10a289c 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -841,6 +841,35 @@ int drm_mode_create_tv_properties(struct drm_device
> *dev, int num_modes,
> }
> EXPORT_SYMBOL(drm_mode_create_tv_properties);
>
> +static const struct drm_prop_enum_list expose_3d_modes_list[] =
> +{
> + { DRM_MODE_EXPOSE_3D_MODES_OFF, "Off" },
> + { DRM_MODE_EXPOSE_3D_MODES_ON, "On" }
> +};
> +
> +/**
> + * drm_mode_create_s3d_properties - create stereo 3D properties
> + * @dev: DRM device
> + *
> + * This functions create properties that are used by the stereo 3D code.
> Those
> + * properties must be attached to the desired connectors afterwards.
> + */
> +int drm_mode_create_s3d_properties(struct drm_device *dev)
> +{
> + struct drm_property *prop;
> +
> + if (dev->mode_config.s3d_expose_modes_property)
> + return 0;
> +
> + prop = drm_property_create_enum(dev, 0, "expose 3D modes",
> + expose_3d_modes_list,
> + ARRAY_SIZE(expose_3d_modes_list));
> + dev->mode_config.s3d_expose_modes_property = prop;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_mode_create_s3d_properties);
> +
> /**
> * drm_mode_create_scaling_mode_property - create scaling mode property
> * @dev: DRM device
> @@ -3170,12 +3199,16 @@ static int drm_mode_connector_set_obj_prop(struct
> drm_mode_object *obj,
> {
> int ret = -EINVAL;
> struct drm_connector *connector = obj_to_connector(obj);
> + struct drm_device *dev = connector->dev;
>
> /* Do DPMS ourselves */
> - if (property == connector->dev->mode_config.dpms_property) {
> + if (property == dev->mode_config.dpms_property) {
> if (connector->funcs->dpms)
> (*connector->funcs->dpms)(connector, (int)value);
> ret = 0;
> + } else if (property == dev->mode_config.s3d_expose_modes_property) {
> + connector->expose_3d_modes = value;
> + ret = 0;
> } else if (connector->funcs->set_property)
> ret = connector->funcs->set_property(connector, property,
> value);
>
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index bfacf0d..34372cb 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -578,6 +578,8 @@ struct drm_connector {
> /* requested DPMS state */
> int dpms;
>
> + int expose_3d_modes;
> +
> void *helper_private;
>
> /* forced on connector */
> @@ -802,6 +804,9 @@ struct drm_mode_config {
> struct drm_property *tv_saturation_property;
> struct drm_property *tv_hue_property;
>
> + /* Stereo 3D properties */
> + struct drm_property *s3d_expose_modes_property;
> +
> /* Optional properties */
> struct drm_property *scaling_mode_property;
> struct drm_property *dithering_mode_property;
> @@ -950,6 +955,7 @@ extern int drm_property_add_enum(struct drm_property
> *property, int index,
> extern int drm_mode_create_dvi_i_properties(struct drm_device *dev);
> extern int drm_mode_create_tv_properties(struct drm_device *dev, int
> num_formats,
> char *formats[]);
> +extern int drm_mode_create_s3d_properties(struct drm_device *dev);
> extern int drm_mode_create_scaling_mode_property(struct drm_device *dev);
> extern int drm_mode_create_dithering_property(struct drm_device *dev);
> extern int drm_mode_create_dirty_info_property(struct drm_device *dev);
> diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
> index 3d6301b..45b19c6 100644
> --- a/include/drm/drm_mode.h
> +++ b/include/drm/drm_mode.h
> @@ -83,6 +83,10 @@
> #define DRM_MODE_DIRTY_ON 1
> #define DRM_MODE_DIRTY_ANNOTATE 2
>
> +/* Expose 3D modes */
> +#define DRM_MODE_EXPOSE_3D_MODES_OFF 0
> +#define DRM_MODE_EXPOSE_3D_MODES_ON1
> +
> struct drm_mode_modeinfo {
> __u32 clock;
> __u16 hdisplay, hsync_start, hsync_end, htotal, hskew;
> --
> 1.7.11.4
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
_
Re: [PATCH 2/2] tests/testdisplay: Test the stereo 3D modes
On Thu, Sep 27, 2012 at 3:42 PM, Damien Lespiau
wrote:
> From: Damien Lespiau
>
> Now that modes have flags to describe which 3d formats the sink
> supports, it's time to test them.
>
> The new test cycles through the supported 3D formats and paint 3D
> stereoscopic images taken from publicly available samples:
> http://www.quantumdata.com/apps/3D/sample_BMP.asp
>
> Signed-off-by: Damien Lespiau
> ---
> tests/testdisplay.c | 226
> ++--
> 1 file changed, 221 insertions(+), 5 deletions(-)
>
> diff --git a/tests/testdisplay.c b/tests/testdisplay.c
> index c52bb2f..e179c83 100644
> --- a/tests/testdisplay.c
> +++ b/tests/testdisplay.c
> @@ -52,6 +52,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -68,7 +69,7 @@
> drmModeRes *resources;
> int drm_fd, modes;
> int dump_info = 0, test_all_modes =0, test_preferred_mode = 0, force_mode =
> 0,
> - test_plane, enable_tiling;
> + test_plane, test_3d_modes, enable_tiling;
> int sleep_between_modes = 5;
> uint32_t depth = 24, stride, bpp;
> int qr_code = 0;
> @@ -153,8 +154,51 @@ struct connector {
> drmModeConnector *connector;
> int crtc;
> int pipe;
> +
> + /* stereo 3d */
> + int s3d_format;
> + char s3d_image[32];
> };
>
> +static bool connector_expose_3d(uint32_t connector_id, bool enable)
> +{
> + drmModeConnector *connector;
> + drmModePropertyRes *property;
> + bool status = false;
> + int i;
> +
> + connector = drmModeGetConnector(drm_fd, connector_id);
> + if (connector->count_props == 0)
> + return false;
> +
> + for (i = 0; i < connector->count_props; i++) {
> + property = drmModeGetProperty(drm_fd, connector->props[i]);
> + if (!property)
> + continue;
> +
> + if (strcmp(property->name, "expose 3D modes") == 0) {
> + if (drmModeConnectorSetProperty(drm_fd,
> + connector_id,
> + property->prop_id,
> + enable))
> + fprintf(stderr, "failed to set the \"expose
> 3D "
> + "modes\" property on connector %d:
> %s\n",
> + connector_id, strerror(errno));
> + else
> + status = true;
> + drmModeFreeProperty(property);
> + goto out;
> + }
> +
> + drmModeFreeProperty(property);
> + property = NULL;
> + }
> +
> +out:
> + drmModeFreeConnector(connector);
> + return status;
> +}
> +
> static void dump_connectors_fd(int drmfd)
> {
> int i, j;
> @@ -172,11 +216,13 @@ static void dump_connectors_fd(int drmfd)
> for (i = 0; i < mode_resources->count_connectors; i++) {
> drmModeConnector *connector;
>
> + connector_expose_3d(mode_resources->connectors[i], TRUE);
> +
> connector = drmModeGetConnector(drmfd,
> mode_resources->connectors[i]);
> if (!connector) {
> fprintf(stderr, "could not get connector %i: %s\n",
> mode_resources->connectors[i],
> strerror(errno));
> - continue;
> + goto next;
> }
>
> printf("%d\t%d\t%s\t%s\t%dx%d\t\t%d\n",
> @@ -188,7 +234,7 @@ static void dump_connectors_fd(int drmfd)
>connector->count_modes);
>
> if (!connector->count_modes)
> - continue;
> + goto next;
>
> printf(" modes:\n");
> printf(" name refresh (Hz) hdisp hss hse htot vdisp "
> @@ -197,6 +243,9 @@ static void dump_connectors_fd(int drmfd)
> kmstest_dump_mode(&connector->modes[j]);
>
> drmModeFreeConnector(connector);
> +
> +next:
> + connector_expose_3d(mode_resources->connectors[i], FALSE);
> }
> printf("\n");
>
> @@ -554,6 +603,154 @@ set_mode(struct connector *c)
> drmModeFreeConnector(c->connector);
> }
>
> +static void
> +paint_3d_image(cairo_t *cr, int l_width, int l_height, void *priv)
> +{
> + struct connector *c = priv;
> + cairo_surface_t *image;
> +
> + image = cairo_image_surface_create_from_png(c->s3d_image);
> +
> + cairo_set_source_surface(cr, image, 0, 0);
> + cairo_paint(cr);
> +
> + cairo_surface_destroy(image);
> +}
> +
> +static void adjust_3d_timings(drmModeModeInfo *mode, unsigned int format)
> +{
> + uint16_t vdisplay, vactive_space;
> +
> + /* just set the 3D format we are setting (this
FOSDEM2013: DevRoom or not?
On Fri, Sep 21, 2012 at 11:35:12AM +0200, Luc Verhaegen wrote: > On Sun, Aug 12, 2012 at 03:50:16PM +0200, Luc Verhaegen wrote: > > Hi, > > > > The FOSDEM organizers have sent out a call for devrooms. FOSDEM this > > year is on the weekend of the 2nd and 3rd of February 2013. > > > > After the success of this formula last year, where, for the first time > > ever, we had a properly filled devroom schedule when the deadline hit, i > > am going to re-apply the same formula: > > * By the 28th of september, i need 6 committed speakers, otherwise i > > will not apply for a DevRoom. 6 people need to apply for a talk slot > > who _definitely_ will come to FOSDEM on February 2nd and/or 3rd 2013. > > This "definitely" means: > > * Don't knowingly plan anything else for this weekend. > > * Come to FOSDEM even if your corporation does not fund you (though > > feel free to contact the board individually for funding) > > * Make sure that you are allowed to travel to the shengen area in > > february. > > * Catastrophies excluded of course. Such catastrophies include > > things like train-derailments and such, but explicitely excludes > > hangovers :p > > * Scheduling based on timeliness of application: the earlier you apply, > > the better slot you get. > > * FOSDEMs final deadline for the full schedule is likely around 15th of > > january 2013. But do not count on that deadline, we will only do > > hourly slots, to keep people from running around between devrooms like > > headless chickens. Only 12-16 slots will be available, first come, > > first serve. > > > > I will set up a wiki page tonight, at http://wiki.x.org/wiki/fosdem2013 > > > > I hope we get a nice devroom like we had last time. That new building we > > were in was really amazing, even though it took a while before all > > FOSDEM visitors found it. > > > > Thanks, > > > > Luc Verhaegen. > > Just a heads up guys, we have a week left and not a single speaker yet! > > Given the timing of XDC and the FOSDEM deadines, this is not too > surprising, but still, with XDC2012 in its final day it is high time > that we start thinking about FOSDEM. I will later on shout at people > here in the room too :) > > All we need now is people who will definitely come to FOSDEM, and who > are willing to talk in the DevRoom. If a vague idea of a topic is > already known, then great, but this is not necessary yet. I now put up a > preliminary wiki page at wiki.x.org/wiki/fosdem2013, add yourself to the > list there. > > Thanks, > > Luc Verhaegen. Final reminder: the deadline is tonight. So far there are three speakers who lined up, and my feeling is that Matthieu and Marc lined up just so that the deadline and requirement will be met. So only a single person is intending to come to fosdem and has a topic he wants to talk about. Come on guys. Surely we can do better than that. Luc Verhaegen.
[PATCH 4/5] reservation: cross-device reservation support
On 9/28/12 2:43 PM, Maarten Lankhorst wrote:
> This adds support for a generic reservations framework that can be
> hooked up to ttm and dma-buf and allows easy sharing of reservations
> across devices.
>
> The idea is that a dma-buf and ttm object both will get a pointer
> to a struct reservation_object, which has to be reserved before
> anything is done with the buffer.
"Anything is done with the buffer" should probably be rephrased, as
different members of the buffer struct
may be protected by different locks. It may not be practical or even
possible to
protect all buffer members with reservation.
> Some followup patches are needed in ttm so the lru_lock is no longer
> taken during the reservation step. This makes the lockdep annotation
> patch a lot more useful, and the assumption that the lru lock protects
> atomic removal off the lru list will fail soon, anyway.
As previously discussed, I'm unfortunately not prepared to accept
removal of the reserve-lru atomicity
into the TTM code at this point.
The current code is based on this assumption and removing it will end up
with
efficiencies, breaking the delayed delete code and probably a locking
nightmare when trying to write
new TTM code.
>
> Signed-off-by: Maarten Lankhorst
> ---
> Documentation/DocBook/device-drivers.tmpl |2
> drivers/base/Makefile |2
> drivers/base/reservation.c| 285
> +
> include/linux/reservation.h | 179 ++
> 4 files changed, 467 insertions(+), 1 deletion(-)
> create mode 100644 drivers/base/reservation.c
> create mode 100644 include/linux/reservation.h
>
> diff --git a/Documentation/DocBook/device-drivers.tmpl
> b/Documentation/DocBook/device-drivers.tmpl
> index ad14396..24e6e80 100644
> --- a/Documentation/DocBook/device-drivers.tmpl
> +++ b/Documentation/DocBook/device-drivers.tmpl
> @@ -129,6 +129,8 @@ X!Edrivers/base/interface.c
> !Edrivers/base/fence.c
> !Iinclude/linux/fence.h
> !Iinclude/linux/seqno-fence.h
> +!Edrivers/base/reservation.c
> +!Iinclude/linux/reservation.h
> !Edrivers/base/dma-coherent.c
> !Edrivers/base/dma-mapping.c
>
> diff --git a/drivers/base/Makefile b/drivers/base/Makefile
> index 0026563..f6f731d 100644
> --- a/drivers/base/Makefile
> +++ b/drivers/base/Makefile
> @@ -10,7 +10,7 @@ obj-$(CONFIG_CMA) += dma-contiguous.o
> obj-y += power/
> obj-$(CONFIG_HAS_DMA) += dma-mapping.o
> obj-$(CONFIG_HAVE_GENERIC_DMA_COHERENT) += dma-coherent.o
> -obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf.o fence.o
> +obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf.o fence.o reservation.o
> obj-$(CONFIG_ISA) += isa.o
> obj-$(CONFIG_FW_LOADER) += firmware_class.o
> obj-$(CONFIG_NUMA) += node.o
> diff --git a/drivers/base/reservation.c b/drivers/base/reservation.c
> new file mode 100644
> index 000..93e2d9f
> --- /dev/null
> +++ b/drivers/base/reservation.c
> @@ -0,0 +1,285 @@
> +/*
> + * Copyright (C) 2012 Canonical Ltd
> + *
> + * Based on bo.c which bears the following copyright notice,
> + * but is dual licensed:
> + *
> + * Copyright (c) 2006-2009 VMware, Inc., Palo Alto, CA., USA
> + * All Rights Reserved.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the
> + * "Software"), to deal in the Software without restriction, including
> + * without limitation the rights to use, copy, modify, merge, publish,
> + * distribute, sub license, and/or sell copies of the Software, and to
> + * permit persons to whom the Software is furnished to do so, subject to
> + * the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the
> + * next paragraph) shall be included in all copies or substantial portions
> + * of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
> + * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY
> CLAIM,
> + * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
> + * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
> + * USE OR OTHER DEALINGS IN THE SOFTWARE.
> + *
> + **/
> +/*
> + * Authors: Thomas Hellstrom
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +atomic64_t reservation_counter = ATOMIC64_INIT(1);
> +EXPORT_SYMBOL(reservation_counter);
> +
> +int
> +object_reserve(struct reservation_object *obj, bool intr, bool no_wait,
> +reservation_ticket_t *ticket)
> +{
> + int ret;
> + u64 sequence = ticket ? ticket->seqno : 1;
> + u64 oldseq;
> +
> + while (unlikely(oldseq = at
[PATCH 1/5] dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER
Hey, Op 28-09-12 14:41, Maarten Lankhorst schreef: > Documentation says that code requiring dma-buf should add it to > select, so inline fallbacks are not going to be used. A link error > will make it obvious what went wrong, instead of silently doing > nothing at runtime. > The whole patch series is in my tree, I use stg so things might move around, do not use for merging currently: http://cgit.freedesktop.org/~mlankhorst/linux/log/?h=v10-wip It contains everything in here plus the patches for ttm to make it work, I use a old snapshot of drm-next + merge of nouveau as base. Description of what the parts do: Series to fix small api issues when moving over: drm/ttm: Remove cpu_writers related code drm/ttm: Add ttm_bo_is_reserved function drm/radeon: Use ttm_bo_is_reserved drm/vmwgfx: use ttm_bo_is_reserved drm/vmwgfx: remove use of fence_obj_args drm/ttm: remove sync_obj_arg drm/ttm: remove sync_obj_arg from ttm_bo_move_accel_cleanup drm/ttm: remove sync_arg entirely drm/nouveau: unpin buffers before releasing to prevent lockdep warnings drm/nouveau: add reservation to nouveau_bo_vma_del drm/nouveau: add reservation to nouveau_gem_ioctl_cpu_prep Hey great, now we only have one user left for fence waiting before reserving, lets fix that and remove fence lock: ttm_bo_cleanup_refs_or_queue and ttm_bo_cleanup_refs have to reserve before waiting, lets do it in the squash commit so we don't have to throw lock order around everywhere: drm/ttm: remove fence_lock -- Up to this point should be mergeable now Then we start working on lru_lock removal slightly, this means the lru list no longer is empty but can contain only reserved buffers: drm/ttm: do not check if list is empty in ttm_bo_force_list_clean drm/ttm: move reservations for ttm_bo_cleanup_refs -- Still mergeable up to this point, just fixes Patch series from this email: dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER fence: dma-buf cross-device synchronization (v9) seqno-fence: Hardware dma-buf implementation of fencing (v3) reservation: cross-device reservation support reservation: Add lockdep annotation and selftests Now hook it up to drm/ttm in a few steps: usage around reservations: drm/ttm: make ttm reservation calls behave like reservation calls drm/ttm: use dma_reservation api dma-buf: use reservations drm/ttm: allow drivers to pass custom dma_reservation_objects for a bo then kill off the lru lock around reservation: drm/ttm: remove lru_lock around ttm_bo_reserve drm/ttm: simplify ttm_eu_* The lru_lock removal patch removes the lock around lru_lock around the reservation, this will break the assumption that items on the lru list and swap list can always be reserved, and this gets patched up too. Is there any part in ttm you disagree with? I believe that this is all mergeable, the lru_lock removal patch could be moved to before the reservation parts, this might make merging easier, but I don't think there is any ttm part of the series that are wrong on a conceptual level. ~Maarten
[PATCH] drm: call connector->dpms(OFF) when disabling
On Fri, Sep 28, 2012 at 3:36 PM, Alex Deucher wrote: > Thinking about modern hw, I'd probably only expose connectors and > monitors (or maybe call them displays). You could hang backlight > controls and brightness, etc on the monitor objects. Also you could > have a multiple monitors connected to a single connector (DP 1.2 or > virtual adapters (wireless or remote display for example)). > Everything else (crtcs, plls, encoders, etc.) would be driver > controlled and validated. Yeah, that's pretty much my idea, too. For backwards-compat we could expose a fake encoder for each connector, but essentially ignore it in the generic modeset code. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH 1/5] dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER
On Fri, Sep 28, 2012 at 02:41:48PM +0200, Maarten Lankhorst wrote:
> Documentation says that code requiring dma-buf should add it to
> select, so inline fallbacks are not going to be used. A link error
> will make it obvious what went wrong, instead of silently doing
> nothing at runtime.
>
> Signed-off-by: Maarten Lankhorst
Reviewed-by: Daniel Vetter
I think it'd be good if we could merge this for 3.7 ...
-Daniel
> ---
> include/linux/dma-buf.h | 99
> ---
> 1 file changed, 99 deletions(-)
>
> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> index eb48f38..bd2e52c 100644
> --- a/include/linux/dma-buf.h
> +++ b/include/linux/dma-buf.h
> @@ -156,7 +156,6 @@ static inline void get_dma_buf(struct dma_buf *dmabuf)
> get_file(dmabuf->file);
> }
>
> -#ifdef CONFIG_DMA_SHARED_BUFFER
> struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
> struct device *dev);
> void dma_buf_detach(struct dma_buf *dmabuf,
> @@ -184,103 +183,5 @@ int dma_buf_mmap(struct dma_buf *, struct
> vm_area_struct *,
>unsigned long);
> void *dma_buf_vmap(struct dma_buf *);
> void dma_buf_vunmap(struct dma_buf *, void *vaddr);
> -#else
> -
> -static inline struct dma_buf_attachment *dma_buf_attach(struct dma_buf
> *dmabuf,
> - struct device *dev)
> -{
> - return ERR_PTR(-ENODEV);
> -}
> -
> -static inline void dma_buf_detach(struct dma_buf *dmabuf,
> - struct dma_buf_attachment *dmabuf_attach)
> -{
> - return;
> -}
> -
> -static inline struct dma_buf *dma_buf_export(void *priv,
> - const struct dma_buf_ops *ops,
> - size_t size, int flags)
> -{
> - return ERR_PTR(-ENODEV);
> -}
> -
> -static inline int dma_buf_fd(struct dma_buf *dmabuf, int flags)
> -{
> - return -ENODEV;
> -}
> -
> -static inline struct dma_buf *dma_buf_get(int fd)
> -{
> - return ERR_PTR(-ENODEV);
> -}
> -
> -static inline void dma_buf_put(struct dma_buf *dmabuf)
> -{
> - return;
> -}
> -
> -static inline struct sg_table *dma_buf_map_attachment(
> - struct dma_buf_attachment *attach, enum dma_data_direction write)
> -{
> - return ERR_PTR(-ENODEV);
> -}
> -
> -static inline void dma_buf_unmap_attachment(struct dma_buf_attachment
> *attach,
> - struct sg_table *sg, enum dma_data_direction dir)
> -{
> - return;
> -}
> -
> -static inline int dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
> -size_t start, size_t len,
> -enum dma_data_direction dir)
> -{
> - return -ENODEV;
> -}
> -
> -static inline void dma_buf_end_cpu_access(struct dma_buf *dmabuf,
> - size_t start, size_t len,
> - enum dma_data_direction dir)
> -{
> -}
> -
> -static inline void *dma_buf_kmap_atomic(struct dma_buf *dmabuf,
> - unsigned long pnum)
> -{
> - return NULL;
> -}
> -
> -static inline void dma_buf_kunmap_atomic(struct dma_buf *dmabuf,
> - unsigned long pnum, void *vaddr)
> -{
> -}
> -
> -static inline void *dma_buf_kmap(struct dma_buf *dmabuf, unsigned long pnum)
> -{
> - return NULL;
> -}
> -
> -static inline void dma_buf_kunmap(struct dma_buf *dmabuf,
> - unsigned long pnum, void *vaddr)
> -{
> -}
> -
> -static inline int dma_buf_mmap(struct dma_buf *dmabuf,
> -struct vm_area_struct *vma,
> -unsigned long pgoff)
> -{
> - return -ENODEV;
> -}
> -
> -static inline void *dma_buf_vmap(struct dma_buf *dmabuf)
> -{
> - return NULL;
> -}
> -
> -static inline void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
> -{
> -}
> -#endif /* CONFIG_DMA_SHARED_BUFFER */
>
> #endif /* __DMA_BUF_H__ */
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH] drm: call connector->dpms(OFF) when disabling
On Fri, Sep 28, 2012 at 01:55:19PM +0200, Daniel Vetter wrote: > On Fri, Sep 28, 2012 at 12:54 PM, Rob Clark wrote: > > Maybe it just makes sense to always do connector->dpms(OFF) before > > unhooking the chain, rather than directly calling dpms on the > > encoder/crtc? > > Well, that makes the entire (optional) ->disable stuff a bit more > awkward. The thing imo really is that the crtc helper assume that the > connectors do not hold any hw state, whereas you're omap driver > violates that assumption. > > For the intel driver we've fixed this by doing any sink handling (e.g. > for dp) in the encoder->dpms functions. So I think the right way for > omap is to do the same (or conclude that the crtc helpers are a bad > fit and ditch them). Having connectors that are special, but only in > some of the cases imo makes squat sense for a generic helper library. > > >> Which is imo a clear sign that the crtc helper is a misfit for your hw and > >> you should stop using it ;-) And adding special-case handling like this > >> into common code, especially if it weakens the semantic concepts in the > >> helper layer is a recipe for a maintainance disaster a few years down the > >> road. Hence > > > > well, I think by the time we start adding atomic-modeset and > > common/dsi panel framework, there might be need for a new set of > > helpers.. but I'm not sure that the hw is quite strange enough to need > > an omap specific set of helpers. Maybe I start w/ something in > > omapdrm but then refactor into common functions once a few drivers are > > converted to atomic modeset and panel framework. > > I see a few ways forward with the crtc helpers and atomic modeset: > - bake the assumption into the code that drivers using the crtc > helpers don't have any shared global resources and drop all these > checks. This would boil down to writing a new set_config to handle > global modeset changes (instead of changes to just one crtc). > Obviously the current possible_encoders/possible_crtcs would still be > checked. > - like above, but add a driver-global ->check callback before starting > the modeset sequence, but with the new configuration already applied > to the kms structures. That's essentially what my intel_atomic.c code does. Somewhat ironically, since your modeset rework, that code is now more suited for other drivers and I need to go and rewrite it for i915. -- Ville Syrj?l? Intel OTC
[PATCH] drm: call connector->dpms(OFF) when disabling
On Fri, Sep 28, 2012 at 2:52 PM, Alan Cox wrote: > On Fri, 28 Sep 2012 09:27:18 +0200 > Rob Clark wrote: > >> From: Rob Clark >> >> When disabling unused connectors, be sure to call connector->dpms(OFF), >> so if there is actually some IP to turn off (such as external bridge >> chips, etc), these actually do get turned off. > > That's a fairly drastic and non-obvious API change for all the other > drivers. Have you tested this widely on other hardware ? no, not yet.. just testing the waters to see how much others freak out first ;-) But since we disconnect the encoder first, drm_helper_connector_dpms() should end up being a no-op so I don't think it works out to be quite as drastic as it sounds. BR, -R > Alan > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 55421] [llvm] glxgears discolored and flickering
https://bugs.freedesktop.org/show_bug.cgi?id=55421 --- Comment #2 from Stanis?aw Halik --- Yes, LLVM only. It happens on 'radeon' and 'r600g' the same. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120928/660c47e6/attachment.html>
Re: FOSDEM2013: DevRoom or not?
On Fri, Sep 28, 2012 at 05:44:27PM +0200, Luc Verhaegen wrote: > > Final reminder: the deadline is tonight. > > So far there are three speakers who lined up, and my feeling is that > Matthieu and Marc lined up just so that the deadline and requirement > will be met. So only a single person is intending to come to fosdem and > has a topic he wants to talk about. > > Come on guys. Surely we can do better than that. > > Luc Verhaegen. After a bit of a scramble, we now have 7.5 speakers confirmed, and two pending budget/approval (which do not count towards the limit). I have therefor sent off the request to the organizers, there is little doubt that we will once again get a nice devroom next year :) We still have, i hope (depends on what the FOSDEM organizers have left for us), 6 slots fully open: first come first serve, and the earlier bird gets the nicer slot! Thanks all, especially those who stepped up already. Luc Verhaegen. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 55421] [llvm] glxgears discolored and flickering
https://bugs.freedesktop.org/show_bug.cgi?id=55421 Michel D?nzer changed: What|Removed |Added Summary|glxgears discolored and |[llvm] glxgears discolored |flickering |and flickering Component|Drivers/DRI/R600|Drivers/Gallium/r600 --- Comment #1 from Michel D?nzer --- >From your description on IRC, this only happens with the LLVM shader compiler, right? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120928/2763e1f0/attachment-0001.html>
[PATCH libdrm 4/4] man: add drm-memory overview page
This adds an overview page that describes Dumb-Buffers, TTM and GEM. It
does not describe chipset-specific features. You should do that in the
driver-manpages.
Signed-off-by: David Herrmann
Reviewed-by: Jesse Barnes
---
man/Makefile.am| 9 +-
man/drm-memory.xml | 430 +
2 files changed, 437 insertions(+), 2 deletions(-)
create mode 100644 man/drm-memory.xml
diff --git a/man/Makefile.am b/man/Makefile.am
index ae02728..fb69c45 100644
--- a/man/Makefile.am
+++ b/man/Makefile.am
@@ -7,10 +7,14 @@
MANPAGES = \
drm.7 \
drm-kms.7 \
+ drm-memory.7 \
drmAvailable.3 \
drmHandleEvent.3 \
drmModeGetResources.3
-MANPAGES_ALIASES =
+MANPAGES_ALIASES = \
+ drm-mm.7 \
+ drm-gem.7 \
+ drm-ttm.7
XML_FILES = \
${patsubst %.1,%.xml,${patsubst %.3,%.xml,${patsubst
%.5,%.xml,${patsubst %.7,%.xml,$(MANPAGES)
@@ -32,7 +36,8 @@ XSLTPROC_FLAGS = \
XSLTPROC_PROCESS_MAN = \
$(AM_V_GEN)$(MKDIR_P) $(dir $@) && \
- $(XSLTPROC) -o $@ $(XSLTPROC_FLAGS)
http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl $<
+ $(XSLTPROC) -o $@ $(XSLTPROC_FLAGS)
http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl $< && \
+ $(SED) -i -e 's/^\.so \(.*\)\.\(.\)$$/\.so man\2\/\1\.\2/'
$(MANPAGES_ALIASES)
%.1: %.xml
$(XSLTPROC_PROCESS_MAN)
diff --git a/man/drm-memory.xml b/man/drm-memory.xml
new file mode 100644
index 000..6b4f075
--- /dev/null
+++ b/man/drm-memory.xml
@@ -0,0 +1,430 @@
+
+http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd";>
+
+
+
+
+
+Direct Rendering Manager
+libdrm
+September 2012
+
+
+Developer
+David
+Herrmann
+dh.herrm...@googlemail.com
+
+
+
+
+
+drm-memory
+7
+
+
+
+drm-memory
+drm-mm
+drm-gem
+drm-ttm
+DRM Memory Management
+
+
+
+
+ #include
+
+
+
+
+Description
+ Many modern high-end GPUs come with their own memory managers. They
+even include several different caches that need to be synchronized
+during access. Textures, framebuffers, command buffers and more
need
+to be stored in memory that can be accessed quickly by the GPU.
+Therefore, memory management on GPUs is highly driver- and
+hardware-dependent.
+
+ However, there are several frameworks in the kernel that are used
by
+more than one driver. These can be used for trivial mode-setting
+without requiring driver-dependent code. But for
+hardware-accelerated rendering you need to read the manual pages
for
+the driver you want to work with.
+
+
+ Dumb-Buffers
+ Almost all in-kernel DRM hardware drivers support an API called
+Dumb-Buffers. This API allows to create
buffers
+of arbitrary size that can be used for scanout. These buffers can
be
+memory mapped via
+
mmap2
+so you can render into them on the CPU. However, GPU access to
these
+buffers is often not possible. Therefore, they are fine for simple
+tasks but not suitable for complex compositions and
+renderings.
+
+ The DRM_IOCTL_MODE_CREATE_DUMB ioctl can be
+used to create a dumb buffer. The kernel will return a 32bit handle
+that can be used to manage the buffer with the DRM API. You can
+create framebuffers with
+
drmModeAddFB3
+and use it for mode-setting and scanout. To access the buffer, you
+first need to retrieve the offset of the buffer. The
+DRM_IOCTL_MODE_MAP_DUMB ioctl requests the DRM
+subsystem to prepare the buffer for memory-mapping and returns a
+fake-offset that can be used with
+
mmap2.
+
+ The DRM_IOCTL_MODE_CREATE_DUMB ioctl takes as
+argument a structure of type
+struct drm_mode_create_dumb:
+
+
+struct drm_mode_create_dumb {
+ __u32 height;
+ __u32 width;
+ __u32 bpp;
+ __u32 flags;
+
+ __u32 handle;
+ __u32 pitch;
+ __u64 size;
+};
+
+
+The fields height,
+width, bpp
and
+flags have to be provided by the caller.
+The other fields are filled by the kernel with the return values.
+height and
+width are the dimensions of the
+rectangular buffer that is created. bpp
+is the number of bits-per-pixel and must be a multiple of
+8. You most commonly want to pass
+32 here. The flags
+field is currently unused and must be zeroed. Different flags to
+modify the behavior may be added in the future. After calling the
+ioctl, the handle,
+pitch and
size
[PATCH libdrm 3/4] man: add drm-kms overview page
This is an overview page for KMS. It is again targeted at novice users that need redirection to the correct function man-pages. Signed-off-by: David Herrmann Reviewed-by: Jesse Barnes --- man/Makefile.am | 1 + man/drm-kms.xml | 342 2 files changed, 343 insertions(+) create mode 100644 man/drm-kms.xml diff --git a/man/Makefile.am b/man/Makefile.am index d55f444..ae02728 100644 --- a/man/Makefile.am +++ b/man/Makefile.am @@ -6,6 +6,7 @@ MANPAGES = \ drm.7 \ + drm-kms.7 \ drmAvailable.3 \ drmHandleEvent.3 \ drmModeGetResources.3 diff --git a/man/drm-kms.xml b/man/drm-kms.xml new file mode 100644 index 000..5f04157 --- /dev/null +++ b/man/drm-kms.xml @@ -0,0 +1,342 @@ + +http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd";> + + + + + +Direct Rendering Manager +libdrm +September 2012 + + +Developer +David +Herrmann +dh.herrm...@googlemail.com + + + + + +drm-kms +7 + + + +drm-kms +Kernel Mode-Setting + + + + + #include+ #include + + + + +Description +Each DRM device provides access to manage which monitors and displays + are currently used and what frames to be displayed. This task is + called Kernel Mode-Setting (KMS). Historically, + this was done in user-space and called + User-space Mode-Setting (UMS). Almost all + open-source drivers now provide the KMS kernel API to do this in the + kernel, however, many non-open-source binary drivers from different + vendors still do not support this. You can use + drmModeSettingSupported3 + to check whether your driver supports this. To understand how KMS + works, we need to introduce 5 objects: CRTCs, + Planes, Encoders, + Connectors and + Framebuffers. + + + + CRTCs + +A CRTC short for + CRT Controller is an abstraction + representing a part of the chip that contains a pointer to a + scanout buffer. Therefore, the number of CRTCs available + determines how many independent scanout buffers can be active + at any given time. The CRTC structure contains several fields + to support this: a pointer to some video memory (abstracted as + a frame-buffer object), a list of driven connectors, a display + mode and an (x, y) offset into the video memory to support + panning or configurations where one piece of video memory + spans multiple CRTCs. A CRTC is the central point where + configuration of displays happens. You select which objects to + use, which modes and which parameters and then configure each + CRTC via + drmModeCrtcSet3 + to drive the display devices. + + + + Planes + +A plane respresents an image source that + can be blended with or overlayed on top of a CRTC during the + scanout process. Planes are associated with a frame-buffer to + crop a portion of the image memory (source) and optionally + scale it to a destination size. The result is then blended + with or overlayed on top of a CRTC. Planes are not provided by + all hardware and the number of available planes is limited. If + planes are not available or if not enough planes are + available, the user should fall back to normal software + blending (via GPU or CPU). + + + + Encoders + +An encoder takes pixel data from a CRTC + and converts it to a format suitable for any attached + connectors. On some devices, it may be possible to have a CRTC + send data to more than one encoder. In that case, both + encoders would receive data from the same scanout buffer, + resulting in a cloned display + configuration across the connectors attached to each + encoder. + + + + Connectors + +A connector is the final destination of + pixel-data on a device, and usually connects directly to an + external display device like a monitor or laptop panel. A + connector can only be attached to one encoder at a time. The + connector is also the structure where information about the + attached display is kept, so it contains fields for d
[PATCH libdrm 2/4] man: add drm.7 overview page
The drm.xml file compiles to drm.7 and is meant as a global overview page for libdrm. It is targeted to new users of libdrm and redirects to all other main man-pages. Signed-off-by: David Herrmann Reviewed-by: Jesse Barnes --- man/Makefile.am | 1 + man/drm.xml | 137 2 files changed, 138 insertions(+) create mode 100644 man/drm.xml diff --git a/man/Makefile.am b/man/Makefile.am index 3030e5f..d55f444 100644 --- a/man/Makefile.am +++ b/man/Makefile.am @@ -5,6 +5,7 @@ # MANPAGES = \ + drm.7 \ drmAvailable.3 \ drmHandleEvent.3 \ drmModeGetResources.3 diff --git a/man/drm.xml b/man/drm.xml new file mode 100644 index 000..5a49fe1 --- /dev/null +++ b/man/drm.xml @@ -0,0 +1,137 @@ + +http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd";> + + + + + +Direct Rendering Manager +libdrm +September 2012 + + +Developer +David +Herrmann +dh.herrm...@googlemail.com + + + + + +drm +7 + + + +drm +Direct Rendering Manager + + + + + #include+ + + + +Description +The Direct Rendering Manager (DRM) is a framework + to manage Graphics Processing Units (GPUs). It is + designed to support the needs of complex graphics devices, usually + containing programmable pipelines well suited to 3D graphics + acceleration. Furthermore, it is responsible for memory management, + interrupt handling and DMA to provide a uniform interface to + applications. + +In earlier days, the kernel framework was solely used to provide raw + hardware access to priviledged user-space processes which implement + all the hardware abstraction layers. But more and more tasks where + moved into the kernel. All these interfaces are based on + ioctl2 + commands on the DRM character device. The libdrm + library provides wrappers for these system-calls and many helpers to + simplify the API. + +When a GPU is detected, the DRM system loads a driver for the detected + hardware type. Each connected GPU is then presented to user-space via + a character-device that is usually available as + /dev/dri/card0 and can be accessed with + open2 + and + close2. + However, it still depends on the grapics driver which interfaces are + available on these devices. If an interface is not available, the + syscalls will fail with EINVAL. + + + Authentication + All DRM devices provide authentication mechanisms. Only a DRM-Master +is allowed to perform mode-setting or modify core state and only one +user can be DRM-Master at a time. See + drmSetMaster3 +for information on how to become DRM-Master and what the limitations +are. Other DRM users can be authenticated to the DRM-Master via + drmAuthMagic3 +so they can perform buffer allocations and rendering. + + + + Mode-Setting + Managing connected monitors and displays and changing the current +modes is called Mode-Setting. This is +restricted to the current DRM-Master. Historically, this was +implemented in user-space, but new DRM drivers implement a kernel +interface to perform mode-setting called +Kernel Mode Setting (KMS). If your +hardware-driver supports it, you can use the KMS API provided by +DRM. This includes allocating framebuffers, selecting modes and +managing CRTCs and encoders. See + drm-kms7 +for more. + + + + Memory Management + The most sophisticated tasks for GPUs today is managing memory +objects. Textures, framebuffers, command-buffers and all other kinds +of commands for the GPU have to be stored in memory. The DRM driver +takes care of managing all memory objects, flushing caches, +synchronizing access and providing CPU access to GPU memory. All +memory management is hardware driver dependent. However, two generic +frameworks are available that are used by most DRM drivers. These +are the Translation Table Manager (TTM) and the +Graphics Execution Manager (GEM). They provide +generic APIs to create, destroy and access buffers from user-space. +However, there are still many differences between the drivers so +driver-depedent code is still needed. Many helpers are provided in +libgbm (Graphics Buffer Manager) from the +mesa-project. For more information on DRM +memory-management, see + drm-memory7. + + + + +Reporting Bugs +Bug
[PATCH libdrm 1/4] man: convert manpages to XML instead of plain troff
If we want to use the manpages in external documentation other than normal
manpages, we should rather use XML. Furthermore, almost no-one knows troff
today, anyway, and XML allows others to easily add more pages without
having to learn troff.
Signed-off-by: David Herrmann
---
.gitignore | 4 ++
configure.ac| 24 +---
man/Makefile.am | 58 ++
man/drmAvailable.man| 25
man/drmAvailable.xml| 75
man/drmHandleEvent.man | 45 --
man/drmHandleEvent.xml | 102
man/drmModeGetResources.man | 79 -
man/drmModeGetResources.xml | 139
9 files changed, 370 insertions(+), 181 deletions(-)
delete mode 100644 man/drmAvailable.man
create mode 100644 man/drmAvailable.xml
delete mode 100644 man/drmHandleEvent.man
create mode 100644 man/drmHandleEvent.xml
delete mode 100644 man/drmModeGetResources.man
create mode 100644 man/drmModeGetResources.xml
diff --git a/.gitignore b/.gitignore
index 243457e..d297f94 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,5 +1,9 @@
bsd-core/*/@
bsd-core/*/machine
+*.1
+*.3
+*.5
+*.7
*.flags
*.ko
*.ko.cmd
diff --git a/configure.ac b/configure.ac
index 290362c..7fd7f11 100644
--- a/configure.ac
+++ b/configure.ac
@@ -35,27 +35,6 @@ AM_MAINTAINER_MODE([enable])
# Enable quiet compiles on automake 1.11.
m4_ifdef([AM_SILENT_RULES], [AM_SILENT_RULES([yes])])
-if test x$LIB_MAN_SUFFIX = x; then
-LIB_MAN_SUFFIX=3
-fi
-if test x$LIB_MAN_DIR = x; then
-LIB_MAN_DIR='$(mandir)/man$(LIB_MAN_SUFFIX)'
-fi
-AC_SUBST([LIB_MAN_SUFFIX])
-AC_SUBST([LIB_MAN_DIR])
-
-MAN_SUBSTS="\
- -e 's|__vendorversion__|\"\$(PACKAGE_STRING)\" |' \
- -e 's|__projectroot__|\$(prefix)|g' \
- -e 's|__apploaddir__|\$(appdefaultdir)|g' \
- -e 's|__appmansuffix__|\$(APP_MAN_SUFFIX)|g' \
- -e 's|__drivermansuffix__|\$(DRIVER_MAN_SUFFIX)|g' \
- -e 's|__adminmansuffix__|\$(ADMIN_MAN_SUFFIX)|g' \
- -e 's|__libmansuffix__|\$(LIB_MAN_SUFFIX)|g' \
- -e 's|__miscmansuffix__|\$(MISC_MAN_SUFFIX)|g' \
- -e 's|__filemansuffix__|\$(FILE_MAN_SUFFIX)|g'"
-AC_SUBST([MAN_SUBSTS])
-
# Check for programs
AC_PROG_CC
@@ -235,6 +214,9 @@ if test "x$HAVE_LIBUDEV" = xyes; then
fi
AM_CONDITIONAL(HAVE_LIBUDEV, [test "x$HAVE_LIBUDEV" = xyes])
+AC_PATH_PROG(XSLTPROC, xsltproc)
+AM_CONDITIONAL([HAVE_XSLTPROC], [test "x$XSLTPROC" != "x"])
+
if test "x$INTEL" != "xno" -o "x$RADEON" != "xno" -o "x$NOUVEAU" != "xno" -o
"x$OMAP" != "xno"; then
# Check for atomic intrinsics
AC_CACHE_CHECK([for native atomic primitives], drm_cv_atomic_primitives,
diff --git a/man/Makefile.am b/man/Makefile.am
index 73068e6..3030e5f 100644
--- a/man/Makefile.am
+++ b/man/Makefile.am
@@ -1,11 +1,47 @@
-libmandir = $(LIB_MAN_DIR)
-libman_PRE = drmAvailable.man \
- drmHandleEvent.man \
- drmModeGetResources.man
-libman_DATA = $(libman_PRE:man=@LIB_MAN_SUFFIX@)
-EXTRA_DIST = $(libman_PRE)
-CLEANFILE = $(libman_DATA)
-SUFFIXES = .$(LIB_MAN_SUFFIX) .man
-
-.man.$(LIB_MAN_SUFFIX):
- $(AM_V_GEN)$(SED) $(MAN_SUBSTS) < $< > $@
+#
+# This generates man-pages out of the Docbook XML files. Simply add your files
+# to the $MANPAGES array. If aliases are created, please add them to the
+# MANPAGES_ALIASES array so they get installed correctly.
+#
+
+MANPAGES = \
+ drmAvailable.3 \
+ drmHandleEvent.3 \
+ drmModeGetResources.3
+MANPAGES_ALIASES =
+
+XML_FILES = \
+ ${patsubst %.1,%.xml,${patsubst %.3,%.xml,${patsubst
%.5,%.xml,${patsubst %.7,%.xml,$(MANPAGES)
+CLEANFILES =
+EXTRA_DIST =
+man_MANS =
+
+if HAVE_XSLTPROC
+
+CLEANFILES += $(MANPAGES) $(MANPAGES_ALIASES)
+EXTRA_DIST += $(MANPAGES) $(MANPAGES_ALIASES) $(XML_FILES)
+man_MANS += $(MANPAGES) $(MANPAGES_ALIASES)
+
+XSLTPROC_FLAGS = \
+ --stringparam man.authors.section.enabled 0 \
+ --stringparam man.copyright.section.enabled 0 \
+ --stringparam funcsynopsis.style ansi \
+ --stringparam man.output.quietly 1
+
+XSLTPROC_PROCESS_MAN = \
+ $(AM_V_GEN)$(MKDIR_P) $(dir $@) && \
+ $(XSLTPROC) -o $@ $(XSLTPROC_FLAGS)
http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl $<
+
+%.1: %.xml
+ $(XSLTPROC_PROCESS_MAN)
+
+%.3: %.xml
+ $(XSLTPROC_PROCESS_MAN)
+
+%.5: %.xml
+ $(XSLTPROC_PROCESS_MAN)
+
+%.7: %.xml
+ $(XSLTPROC_PROCESS_MAN)
+
+endif # HAVE_XSLTPROC
diff --git a/man/drmAvailable.man b/man/drmAvailable.man
deleted file mode 100644
index e1bb8dc..000
--- a/man/drmAvailable.man
+++ /dev/null
@@ -1,25 +0,0 @@
-.\" shorthand for double quote that works everywhere.
-.ds q \N'34'
-.TH drmAvailable __drivermansuffix__ __vendorversion__
-.SH NAME
-drmAvailable \- determine whether a DRM kernel driver has been loaded
-.SH SYNOPSIS
-.nf
-.B "#include "
-
-.B "int drmAvailable(void);"
-
[PATCH 5/5] reservation: Add lockdep annotation and selftests
Signed-off-by: Maarten Lankhorst
---
The self-tests will fail if the commit "lockdep: Check if nested
lock is actually held" from linux tip core/locking is not applied.
---
drivers/base/reservation.c | 46 +-
include/linux/reservation.h | 29 +++-
lib/Kconfig.debug |1
lib/locking-selftest.c | 353 +--
4 files changed, 403 insertions(+), 26 deletions(-)
diff --git a/drivers/base/reservation.c b/drivers/base/reservation.c
index 93e2d9f..b8d4f4d 100644
--- a/drivers/base/reservation.c
+++ b/drivers/base/reservation.c
@@ -41,6 +41,18 @@
atomic64_t reservation_counter = ATOMIC64_INIT(1);
EXPORT_SYMBOL(reservation_counter);
+const char reservation_object_name[] = "reservation_object";
+EXPORT_SYMBOL(reservation_object_name);
+
+const char reservation_ticket_name[] = "reservation_ticket";
+EXPORT_SYMBOL(reservation_ticket_name);
+
+struct lock_class_key reservation_object_class;
+EXPORT_SYMBOL(reservation_object_class);
+
+struct lock_class_key reservation_ticket_class;
+EXPORT_SYMBOL(reservation_ticket_class);
+
int
object_reserve(struct reservation_object *obj, bool intr, bool no_wait,
reservation_ticket_t *ticket)
@@ -49,6 +61,10 @@ object_reserve(struct reservation_object *obj, bool intr,
bool no_wait,
u64 sequence = ticket ? ticket->seqno : 1;
u64 oldseq;
+ if (!no_wait)
+ mutex_acquire_nest(&obj->dep_map, 0, 0,
+ ticket ? &ticket->dep_map : NULL, _RET_IP_);
+
while (unlikely(oldseq = atomic64_cmpxchg(&obj->reserved, 0,
sequence))) {
/**
@@ -58,14 +74,18 @@ object_reserve(struct reservation_object *obj, bool intr,
bool no_wait,
/**
* We've already reserved this one.
*/
- if (unlikely(sequence == oldseq))
- return -EDEADLK;
+ if (unlikely(sequence == oldseq)) {
+ ret = -EDEADLK;
+ goto fail;
+ }
/**
* Already reserved by a thread that will not back
* off for us. We need to back off.
*/
- if (unlikely(sequence - oldseq < (1ULL << 63)))
- return -EAGAIN;
+ if (unlikely(sequence - oldseq < (1ULL << 63))) {
+ ret = -EAGAIN;
+ goto fail;
+ }
}
if (no_wait)
@@ -74,9 +94,12 @@ object_reserve(struct reservation_object *obj, bool intr,
bool no_wait,
ret = object_wait_unreserved(obj, intr);
if (unlikely(ret))
- return ret;
+ goto fail;
}
+ if (no_wait)
+ mutex_acquire(&obj->dep_map, 0, 1, _RET_IP_);
+
/**
* Wake up waiters that may need to recheck for deadlock,
* if we decreased the sequence number.
@@ -84,6 +107,11 @@ object_reserve(struct reservation_object *obj, bool intr,
bool no_wait,
wake_up_all(&obj->event_queue);
return 0;
+
+fail:
+ if (!no_wait)
+ mutex_release(&obj->dep_map, 1, _RET_IP_);
+ return ret;
}
EXPORT_SYMBOL(object_reserve);
@@ -105,6 +133,14 @@ void
object_unreserve(struct reservation_object *obj,
reservation_ticket_t *ticket)
{
+ mutex_release(&obj->dep_map, 1, _RET_IP_);
+
+ if (!object_is_reserved(obj)) {
+#ifndef CONFIG_DEBUG_LOCKING_API_SELFTESTS
+ WARN_ON(1);
+#endif
+ return;
+ }
smp_mb();
atomic64_set(&obj->reserved, 0);
wake_up_all(&obj->event_queue);
diff --git a/include/linux/reservation.h b/include/linux/reservation.h
index 93280af..6fa0cdb 100644
--- a/include/linux/reservation.h
+++ b/include/linux/reservation.h
@@ -44,6 +44,10 @@
#include
extern atomic64_t reservation_counter;
+extern const char reservation_object_name[];
+extern struct lock_class_key reservation_object_class;
+extern const char reservation_ticket_name[];
+extern struct lock_class_key reservation_ticket_class;
struct reservation_object {
wait_queue_head_t event_queue;
@@ -53,10 +57,17 @@ struct reservation_object {
u32 fence_shared_count;
struct fence *fence_excl;
struct fence *fence_shared[BUF_MAX_SHARED_FENCE];
+
+#ifdef CONFIG_DEBUG_LOCK_ALLOC
+ struct lockdep_map dep_map;
+#endif
};
typedef struct reservation_ticket {
u64 seqno;
+#ifdef CONFIG_DEBUG_LOCK_ALLOC
+ struct lockdep_map dep_map;
+#endif
} reservation_ticket_t;
/**
@@ -73,11 +84,13 @@ struct reservation_entry {
unsigned long obj_shared;
};
-
static inline void
__reservation_object_init(struct reservation_object *obj
[PATCH 4/5] reservation: cross-device reservation support
This adds support for a generic reservations framework that can be
hooked up to ttm and dma-buf and allows easy sharing of reservations
across devices.
The idea is that a dma-buf and ttm object both will get a pointer
to a struct reservation_object, which has to be reserved before
anything is done with the buffer.
Some followup patches are needed in ttm so the lru_lock is no longer
taken during the reservation step. This makes the lockdep annotation
patch a lot more useful, and the assumption that the lru lock protects
atomic removal off the lru list will fail soon, anyway.
Signed-off-by: Maarten Lankhorst
---
Documentation/DocBook/device-drivers.tmpl |2
drivers/base/Makefile |2
drivers/base/reservation.c| 285 +
include/linux/reservation.h | 179 ++
4 files changed, 467 insertions(+), 1 deletion(-)
create mode 100644 drivers/base/reservation.c
create mode 100644 include/linux/reservation.h
diff --git a/Documentation/DocBook/device-drivers.tmpl
b/Documentation/DocBook/device-drivers.tmpl
index ad14396..24e6e80 100644
--- a/Documentation/DocBook/device-drivers.tmpl
+++ b/Documentation/DocBook/device-drivers.tmpl
@@ -129,6 +129,8 @@ X!Edrivers/base/interface.c
!Edrivers/base/fence.c
!Iinclude/linux/fence.h
!Iinclude/linux/seqno-fence.h
+!Edrivers/base/reservation.c
+!Iinclude/linux/reservation.h
!Edrivers/base/dma-coherent.c
!Edrivers/base/dma-mapping.c
diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index 0026563..f6f731d 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -10,7 +10,7 @@ obj-$(CONFIG_CMA) += dma-contiguous.o
obj-y += power/
obj-$(CONFIG_HAS_DMA) += dma-mapping.o
obj-$(CONFIG_HAVE_GENERIC_DMA_COHERENT) += dma-coherent.o
-obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf.o fence.o
+obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf.o fence.o reservation.o
obj-$(CONFIG_ISA) += isa.o
obj-$(CONFIG_FW_LOADER)+= firmware_class.o
obj-$(CONFIG_NUMA) += node.o
diff --git a/drivers/base/reservation.c b/drivers/base/reservation.c
new file mode 100644
index 000..93e2d9f
--- /dev/null
+++ b/drivers/base/reservation.c
@@ -0,0 +1,285 @@
+/*
+ * Copyright (C) 2012 Canonical Ltd
+ *
+ * Based on bo.c which bears the following copyright notice,
+ * but is dual licensed:
+ *
+ * Copyright (c) 2006-2009 VMware, Inc., Palo Alto, CA., USA
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * "Software"), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM,
+ * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
+ * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
+ * USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ **/
+/*
+ * Authors: Thomas Hellstrom
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+atomic64_t reservation_counter = ATOMIC64_INIT(1);
+EXPORT_SYMBOL(reservation_counter);
+
+int
+object_reserve(struct reservation_object *obj, bool intr, bool no_wait,
+ reservation_ticket_t *ticket)
+{
+ int ret;
+ u64 sequence = ticket ? ticket->seqno : 1;
+ u64 oldseq;
+
+ while (unlikely(oldseq = atomic64_cmpxchg(&obj->reserved, 0,
sequence))) {
+
+ /**
+* Deadlock avoidance for multi-obj reserving.
+*/
+ if (sequence > 1 && oldseq > 1) {
+ /**
+* We've already reserved this one.
+*/
+ if (unlikely(sequence == oldseq))
+ return -EDEADLK;
+ /**
+* Already reserved by a thread that will not back
+* off for us. We need to back off.
+*/
+ if (unlikely(sequence - oldseq < (1ULL << 63)))
+ return -EAGAIN;
+ }
+
+ if (no_wait)
+ return -EBUSY;
+
+
[PATCH libdrm 0/4] Manpages for libdrm
Hi This is revision 2 of the manpages for libdrm. I converted everything to docbook XML. This makes it easier to write them (troff is really hard to read) and allows us to integrate it into other documentation. Other than that I only fixed typos and the small corrections you guys mentioned. Thanks for reviewing! Regards David David Herrmann (4): man: convert manpages to XML instead of plain troff man: add drm.7 overview page man: add drm-kms overview page man: add drm-memory overview page .gitignore | 4 + configure.ac| 24 +-- man/Makefile.am | 65 +-- man/drm-kms.xml | 342 +++ man/drm-memory.xml | 430 man/drm.xml | 137 ++ man/drmAvailable.man| 25 --- man/drmAvailable.xml| 75 man/drmHandleEvent.man | 45 - man/drmHandleEvent.xml | 102 +++ man/drmModeGetResources.man | 79 man/drmModeGetResources.xml | 139 ++ 12 files changed, 1286 insertions(+), 181 deletions(-) create mode 100644 man/drm-kms.xml create mode 100644 man/drm-memory.xml create mode 100644 man/drm.xml delete mode 100644 man/drmAvailable.man create mode 100644 man/drmAvailable.xml delete mode 100644 man/drmHandleEvent.man create mode 100644 man/drmHandleEvent.xml delete mode 100644 man/drmModeGetResources.man create mode 100644 man/drmModeGetResources.xml -- 1.7.12.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/5] seqno-fence: Hardware dma-buf implementation of fencing (v3)
This type of fence can be used with hardware synchronization for simple
hardware that can block execution until the condition
(dma_buf[offset] - value) >= 0 has been met.
A software fallback still has to be provided in case the fence is used
with a device that doesn't support this mechanism. It is useful to expose
this for graphics cards that have an op to support this.
Some cards like i915 can export those, but don't have an option to wait,
so they need the software fallback.
I extended the original patch by Rob Clark.
v1: Original
v2: Renamed from bikeshed to seqno, moved into dma-fence.c since
not much was left of the file. Lots of documentation added.
v3: Use fence_ops instead of custom callbacks. Moved to own file
to avoid circular dependency between dma-buf.h and fence.h
Signed-off-by: Maarten Lankhorst
---
Documentation/DocBook/device-drivers.tmpl |1
drivers/base/fence.c | 36 ++
include/linux/seqno-fence.h | 107 +
3 files changed, 144 insertions(+)
create mode 100644 include/linux/seqno-fence.h
diff --git a/Documentation/DocBook/device-drivers.tmpl
b/Documentation/DocBook/device-drivers.tmpl
index 6f53fc0..ad14396 100644
--- a/Documentation/DocBook/device-drivers.tmpl
+++ b/Documentation/DocBook/device-drivers.tmpl
@@ -128,6 +128,7 @@ X!Edrivers/base/interface.c
!Edrivers/base/dma-buf.c
!Edrivers/base/fence.c
!Iinclude/linux/fence.h
+!Iinclude/linux/seqno-fence.h
!Edrivers/base/dma-coherent.c
!Edrivers/base/dma-mapping.c
diff --git a/drivers/base/fence.c b/drivers/base/fence.c
index b90a09e..0a184b2 100644
--- a/drivers/base/fence.c
+++ b/drivers/base/fence.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
static int __fence_signal(struct fence *fence)
{
@@ -335,3 +336,38 @@ struct fence *fence_create(void *priv)
return fence;
}
EXPORT_SYMBOL(fence_create);
+
+static bool seqno_enable_signaling(struct fence *fence)
+{
+ struct seqno_fence *seqno_fence = to_seqno_fence(fence);
+ return seqno_fence->ops->enable_signaling(fence);
+}
+
+static bool seqno_signaled(struct fence *fence)
+{
+ struct seqno_fence *seqno_fence = to_seqno_fence(fence);
+ return seqno_fence->ops->signaled && seqno_fence->ops->signaled(fence);
+}
+
+static void seqno_release(struct fence *fence)
+{
+ struct seqno_fence *f = to_seqno_fence(fence);
+
+ if (f->ops->release)
+ f->ops->release(fence);
+ dma_buf_put(f->sync_buf);
+}
+
+static long seqno_wait(struct fence *fence, bool intr, signed long timeout)
+{
+ struct seqno_fence *f = to_seqno_fence(fence);
+ return f->ops->wait(fence, intr, timeout);
+}
+
+const struct fence_ops seqno_fence_ops = {
+ .enable_signaling = seqno_enable_signaling,
+ .signaled = seqno_signaled,
+ .wait = seqno_wait,
+ .release = seqno_release
+};
+EXPORT_SYMBOL_GPL(seqno_fence_ops);
diff --git a/include/linux/seqno-fence.h b/include/linux/seqno-fence.h
new file mode 100644
index 000..971cebe
--- /dev/null
+++ b/include/linux/seqno-fence.h
@@ -0,0 +1,107 @@
+/*
+ * seqno-fence, using a dma-buf to synchronize fencing
+ *
+ * Copyright (C) 2012 Texas Instruments
+ * Copyright (C) 2012 Canonical Ltd
+ * Authors:
+ * Rob Clark
+ * Maarten Lankhorst
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see
[PATCH 2/5] fence: dma-buf cross-device synchronization (v9)
A fence can be attached to a buffer which is being filled or consumed
by hw, to allow userspace to pass the buffer without waiting to another
device. For example, userspace can call page_flip ioctl to display the
next frame of graphics after kicking the GPU but while the GPU is still
rendering. The display device sharing the buffer with the GPU would
attach a callback to get notified when the GPU's rendering-complete IRQ
fires, to update the scan-out address of the display, without having to
wake up userspace.
A fence is transient, one-shot deal. It is allocated and attached
to one or more dma-buf's. When the one that attached it is done, with
the pending operation, it can signal the fence:
+ fence_signal()
To have a rough approximation whether a fence is fired, call:
+ fence_is_signaled()
The dma-buf-mgr handles tracking, and waiting on, the fences associated
with a dma-buf.
The one pending on the fence can add an async callback:
+ fence_add_callback()
The callback can optionally be cancelled with:
+ fence_remove_callback()
To wait synchronously, optionally with a timeout:
+ fence_wait()
+ fence_wait_timeout()
A default software-only implementation is provided, which can be used
by drivers attaching a fence to a buffer when they have no other means
for hw sync. But a memory backed fence is also envisioned, because it
is common that GPU's can write to, or poll on some memory location for
synchronization. For example:
fence = custom_get_fence(...);
if ((seqno_fence = to_seqno_fence(fence)) != NULL) {
dma_buf *fence_buf = fence->sync_buf;
get_dma_buf(fence_buf);
... tell the hw the memory location to wait ...
custom_wait_on(fence_buf, fence->seqno_ofs, fence->seqno);
} else {
/* fall-back to sw sync * /
fence_add_callback(fence, my_cb);
}
On SoC platforms, if some other hw mechanism is provided for synchronizing
between IP blocks, it could be supported as an alternate implementation
with it's own fence ops in a similar way.
To facilitate other non-sw implementations, the enable_signaling callback
can be used to keep track if a device not supporting hw sync is waiting
on the fence, and in this case should arrange to call fence_signal()
at some point after the condition has changed, to notify other devices
waiting on the fence. If there are no sw waiters, this can be skipped to
avoid waking the CPU unnecessarily. The handler of the enable_signaling
op should take a refcount until the fence is signaled, then release its ref.
The intention is to provide a userspace interface (presumably via eventfd)
later, to be used in conjunction with dma-buf's mmap support for sw access
to buffers (or for userspace apps that would prefer to do their own
synchronization).
v1: Original
v2: After discussion w/ danvet and mlankhorst on #dri-devel, we decided
that dma-fence didn't need to care about the sw->hw signaling path
(it can be handled same as sw->sw case), and therefore the fence->ops
can be simplified and more handled in the core. So remove the signal,
add_callback, cancel_callback, and wait ops, and replace with a simple
enable_signaling() op which can be used to inform a fence supporting
hw->hw signaling that one or more devices which do not support hw
signaling are waiting (and therefore it should enable an irq or do
whatever is necessary in order that the CPU is notified when the
fence is passed).
v3: Fix locking fail in attach_fence() and get_fence()
v4: Remove tie-in w/ dma-buf.. after discussion w/ danvet and mlankorst
we decided that we need to be able to attach one fence to N dma-buf's,
so using the list_head in dma-fence struct would be problematic.
v5: [ Maarten Lankhorst ] Updated for dma-bikeshed-fence and dma-buf-manager.
v6: [ Maarten Lankhorst ] I removed dma_fence_cancel_callback and some comments
about checking if fence fired or not. This is broken by design.
waitqueue_active during destruction is now fatal, since the signaller
should be holding a reference in enable_signalling until it signalled
the fence. Pass the original dma_fence_cb along, and call __remove_wait
in the dma_fence_callback handler, so that no cleanup needs to be
performed.
v7: [ Maarten Lankhorst ] Set cb->func and only enable sw signaling if
fence wasn't signaled yet, for example for hardware fences that may
choose to signal blindly.
v8: [ Maarten Lankhorst ] Tons of tiny fixes, moved __dma_fence_init to
header and fixed include mess. dma-fence.h now includes dma-buf.h
All members are now initialized, so kmalloc can be used for
allocating a dma-fence. More documentation added.
v9: Change compiler bitfields to flags, change return type of
enable_signaling to bool. Rework dma_fence_wait. Added
dma_fence_is_signaled and dma_fence_wait_timeout.
s/dma// and change exports to non GPL. Added fence_is_signaled and
fence_enable_sw_signaling calls, add ability to override def
[PATCH 1/5] dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER
Documentation says that code requiring dma-buf should add it to
select, so inline fallbacks are not going to be used. A link error
will make it obvious what went wrong, instead of silently doing
nothing at runtime.
Signed-off-by: Maarten Lankhorst
---
include/linux/dma-buf.h | 99 ---
1 file changed, 99 deletions(-)
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index eb48f38..bd2e52c 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -156,7 +156,6 @@ static inline void get_dma_buf(struct dma_buf *dmabuf)
get_file(dmabuf->file);
}
-#ifdef CONFIG_DMA_SHARED_BUFFER
struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
struct device *dev);
void dma_buf_detach(struct dma_buf *dmabuf,
@@ -184,103 +183,5 @@ int dma_buf_mmap(struct dma_buf *, struct vm_area_struct
*,
unsigned long);
void *dma_buf_vmap(struct dma_buf *);
void dma_buf_vunmap(struct dma_buf *, void *vaddr);
-#else
-
-static inline struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
- struct device *dev)
-{
- return ERR_PTR(-ENODEV);
-}
-
-static inline void dma_buf_detach(struct dma_buf *dmabuf,
- struct dma_buf_attachment *dmabuf_attach)
-{
- return;
-}
-
-static inline struct dma_buf *dma_buf_export(void *priv,
-const struct dma_buf_ops *ops,
-size_t size, int flags)
-{
- return ERR_PTR(-ENODEV);
-}
-
-static inline int dma_buf_fd(struct dma_buf *dmabuf, int flags)
-{
- return -ENODEV;
-}
-
-static inline struct dma_buf *dma_buf_get(int fd)
-{
- return ERR_PTR(-ENODEV);
-}
-
-static inline void dma_buf_put(struct dma_buf *dmabuf)
-{
- return;
-}
-
-static inline struct sg_table *dma_buf_map_attachment(
- struct dma_buf_attachment *attach, enum dma_data_direction write)
-{
- return ERR_PTR(-ENODEV);
-}
-
-static inline void dma_buf_unmap_attachment(struct dma_buf_attachment *attach,
- struct sg_table *sg, enum dma_data_direction dir)
-{
- return;
-}
-
-static inline int dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
- size_t start, size_t len,
- enum dma_data_direction dir)
-{
- return -ENODEV;
-}
-
-static inline void dma_buf_end_cpu_access(struct dma_buf *dmabuf,
- size_t start, size_t len,
- enum dma_data_direction dir)
-{
-}
-
-static inline void *dma_buf_kmap_atomic(struct dma_buf *dmabuf,
- unsigned long pnum)
-{
- return NULL;
-}
-
-static inline void dma_buf_kunmap_atomic(struct dma_buf *dmabuf,
-unsigned long pnum, void *vaddr)
-{
-}
-
-static inline void *dma_buf_kmap(struct dma_buf *dmabuf, unsigned long pnum)
-{
- return NULL;
-}
-
-static inline void dma_buf_kunmap(struct dma_buf *dmabuf,
- unsigned long pnum, void *vaddr)
-{
-}
-
-static inline int dma_buf_mmap(struct dma_buf *dmabuf,
- struct vm_area_struct *vma,
- unsigned long pgoff)
-{
- return -ENODEV;
-}
-
-static inline void *dma_buf_vmap(struct dma_buf *dmabuf)
-{
- return NULL;
-}
-
-static inline void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
-{
-}
-#endif /* CONFIG_DMA_SHARED_BUFFER */
#endif /* __DMA_BUF_H__ */
[Bug 49981] On HD6850, Power Profile doesn't change if 2 screen is attached.
https://bugs.freedesktop.org/show_bug.cgi?id=49981 graham changed: What|Removed |Added CC||grhm.perry at gmail.com --- Comment #3 from graham --- The profiles appear to be set in r600_pm_init_profile in r600.c, and it seems that the power profile is one higher than the single head settings, but the clock mode steps up the same. That doesn't appear to be the behaviour seen though, as in multi-head mode on the HD6k the clock mode stays on full all the time. That leads me to think maybe the r600 profile is not suitable for HD6k cards. That would depend on whether the same behaviour is seen on other cards that use r600 profile, as it's used for many more families than just Northern Islands (see radeon_asic.c, radeon_asic btc_asic is used for hd6k series). Also, why is it necessary to increase the power profile just for an extra head? I can't actually figure out the logic in some of the power state and clock mode differences between the card families, are they based on anything other than guesswork? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120928/b00e8ead/attachment.html>
[PATCH] drm: call connector->dpms(OFF) when disabling
On Fri, Sep 28, 2012 at 1:55 PM, Daniel Vetter wrote: > On Fri, Sep 28, 2012 at 12:54 PM, Rob Clark wrote: >> Maybe it just makes sense to always do connector->dpms(OFF) before >> unhooking the chain, rather than directly calling dpms on the >> encoder/crtc? > > Well, that makes the entire (optional) ->disable stuff a bit more > awkward. The thing imo really is that the crtc helper assume that the > connectors do not hold any hw state, whereas you're omap driver > violates that assumption. > > For the intel driver we've fixed this by doing any sink handling (e.g. > for dp) in the encoder->dpms functions. So I think the right way for > omap is to do the same (or conclude that the crtc helpers are a bad > fit and ditch them). Having connectors that are special, but only in > some of the cases imo makes squat sense for a generic helper library. hmm.. well I have been thinking that some of what is currently in the connectors needs to move into the encoders.. this would help, although will take some time. >>> Which is imo a clear sign that the crtc helper is a misfit for your hw and >>> you should stop using it ;-) And adding special-case handling like this >>> into common code, especially if it weakens the semantic concepts in the >>> helper layer is a recipe for a maintainance disaster a few years down the >>> road. Hence >> >> well, I think by the time we start adding atomic-modeset and >> common/dsi panel framework, there might be need for a new set of >> helpers.. but I'm not sure that the hw is quite strange enough to need >> an omap specific set of helpers. Maybe I start w/ something in >> omapdrm but then refactor into common functions once a few drivers are >> converted to atomic modeset and panel framework. > > I see a few ways forward with the crtc helpers and atomic modeset: > - bake the assumption into the code that drivers using the crtc > helpers don't have any shared global resources and drop all these > checks. This would boil down to writing a new set_config to handle > global modeset changes (instead of changes to just one crtc). > Obviously the current possible_encoders/possible_crtcs would still be > checked. > - like above, but add a driver-global ->check callback before starting > the modeset sequence, but with the new configuration already applied > to the kms structures. > - an alternative would be a new ->global_adjust_modes after the > ->adjust_mode stage that gets all the new adjusted_modes and could > check global resource constrains. > > Imo anything more complicated than that has dubious value in a common > framework. I also dunno yet how (or if at all) we should bake in > handling of planes restrictions ... > > For panel framework integration I don't think we need much, this is > likely just a driver internal thing. well.. I guess it where the panel driver fits in KMS. I think it would be common that we need to send a command to the panel to turn off / disable backlight / etc. Versus an hdmi/dp/etc monitor which would just do this automatically when it stops receiving a signal. So it doesn't seem like a bad idea to not assume that your connector is completely passive. But I could buy the argument that this should be part of crtc helpers v2. BR, -R > Cheers, Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 55421] New: glxgears discolored and flickering
https://bugs.freedesktop.org/show_bug.cgi?id=55421 Priority: medium Bug ID: 55421 Assignee: dri-devel at lists.freedesktop.org Summary: glxgears discolored and flickering Severity: normal Classification: Unclassified OS: Linux (All) Reporter: sthalik at misaki.pl Hardware: x86 (IA32) Status: NEW Version: git Component: Drivers/DRI/R600 Product: Mesa On 69700 glxgears has the red gear's part colored yellow and it flickers every half a second or so. No errors are emitted. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120928/bb474a45/attachment.html>
[Bug 55416] [R600g] Torchlight gives GPU lockup
https://bugs.freedesktop.org/show_bug.cgi?id=55416 --- Comment #2 from Laurent carlier --- Mesa is built with: ./autogen.sh --prefix=/usr --sysconfdir=/etc --with-dri-driverdir=/usr/lib/xorg/modules/dri --with-gallium-drivers=r300,r600,radeonsi,nouveau,swrast,svga --with-egl-platforms=x11,wayland,drm --enable-gallium-llvm --enable-gallium-egl --enable-glx-tls --enable-glx --enable-gles1 --enable-gles2 --enable-egl --enable-r600-llvm-compiler --enable-shared-glapi --enable-texture-float --enable-xa --enable-gbm --enable-osmesa --enable-vdpau -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120928/0fcbb7a1/attachment.html>
[PATCH] drm: call connector->dpms(OFF) when disabling
On Fri, Sep 28, 2012 at 12:54 PM, Rob Clark wrote: > Maybe it just makes sense to always do connector->dpms(OFF) before > unhooking the chain, rather than directly calling dpms on the > encoder/crtc? Well, that makes the entire (optional) ->disable stuff a bit more awkward. The thing imo really is that the crtc helper assume that the connectors do not hold any hw state, whereas you're omap driver violates that assumption. For the intel driver we've fixed this by doing any sink handling (e.g. for dp) in the encoder->dpms functions. So I think the right way for omap is to do the same (or conclude that the crtc helpers are a bad fit and ditch them). Having connectors that are special, but only in some of the cases imo makes squat sense for a generic helper library. >> Which is imo a clear sign that the crtc helper is a misfit for your hw and >> you should stop using it ;-) And adding special-case handling like this >> into common code, especially if it weakens the semantic concepts in the >> helper layer is a recipe for a maintainance disaster a few years down the >> road. Hence > > well, I think by the time we start adding atomic-modeset and > common/dsi panel framework, there might be need for a new set of > helpers.. but I'm not sure that the hw is quite strange enough to need > an omap specific set of helpers. Maybe I start w/ something in > omapdrm but then refactor into common functions once a few drivers are > converted to atomic modeset and panel framework. I see a few ways forward with the crtc helpers and atomic modeset: - bake the assumption into the code that drivers using the crtc helpers don't have any shared global resources and drop all these checks. This would boil down to writing a new set_config to handle global modeset changes (instead of changes to just one crtc). Obviously the current possible_encoders/possible_crtcs would still be checked. - like above, but add a driver-global ->check callback before starting the modeset sequence, but with the new configuration already applied to the kms structures. - an alternative would be a new ->global_adjust_modes after the ->adjust_mode stage that gets all the new adjusted_modes and could check global resource constrains. Imo anything more complicated than that has dubious value in a common framework. I also dunno yet how (or if at all) we should bake in handling of planes restrictions ... For panel framework integration I don't think we need much, this is likely just a driver internal thing. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH] drm: call connector->dpms(OFF) when disabling
On Fri, 28 Sep 2012 09:27:18 +0200 Rob Clark wrote: > From: Rob Clark > > When disabling unused connectors, be sure to call connector->dpms(OFF), > so if there is actually some IP to turn off (such as external bridge > chips, etc), these actually do get turned off. That's a fairly drastic and non-obvious API change for all the other drivers. Have you tested this widely on other hardware ? Alan
[Bug 55416] [R600g] Torchlight gives GPU lockup
https://bugs.freedesktop.org/show_bug.cgi?id=55416 --- Comment #1 from Laurent carlier --- Here is a trace that i can reproduce the lockup: http://pkgbuild.com/~lcarlier/trace/Torchlight.bin.x86_64.trace.tar.gz -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120928/46ea6b10/attachment.html>
[PATCH 0/3] [RFC] DRM Render Nodes
On Fri, Sep 28, 2012 at 12:35 PM, Kristian H?gsberg wrote: > Here's the patch to implement render nodes as discussed in the "DRM2" > talk at XDC: > > http://wiki.x.org/wiki/Events/XDC2012/Proceedings#DRM2 > > The core problem is that DRM security is compromised in the face of > VT switching and multiple DRM masters. Any local user can access all > shared buffers from within any X server on the system, even when that > user doesn't have access to any of those X servers. > > The fix for this is to use dmabuf/prime and fd passing for buffer sharing. > That infrastructure is already in place and we need to start using that in > user space. Once we're passing buffers between display servers and clients > in a point-to-point fashion, we no longer need to authenticate clients. We > just need to make sure they can only render and import/export buffers to > fds. That's what this patch does, by creating a new type of drm device > node. Accessing this node doesn't require authentication (and as such > can be used without a master, ie headless), but will only expose the safe, > modern (DRI2ish) rendering ioctls. > > Once userspace is sharing buffers through fd passing, the legacy card0 node > can be locked down by unix permissions, for example in a drm-master group, > so that only setgid binaries (X, weston, other KMS apps) can access it. > I haven't read through your patches yet, but Dave and Ilija already did something similar a while back: http://lists.freedesktop.org/archives/dri-devel/2012-March/020765.html Alex > Kristian > > > See also: > > http://wiki.x.org/wiki/Events/XDC2012/Proceedings#Graphics_stack_security > > https://lwn.net/Articles/517375/ > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/3] [RFC] DRM Render Nodes
On Fri, 28 Sep 2012, Daniel Vetter wrote: > On a quick look the rendernode Kristian propose and your work seem to > attack slightly different issues. Your/Dave's patch series seems to > put large efforts into (dynamically) splitting up the resources of a > drm device, including the modeset stuff. Correct, the goal is to be able to run multiseat while sharing a GPU. Actually, with my variant of render nodes, I even got multiple desktops residing in different LXC containers to share the GPU, which is kind of cool. > Kristians proposal here is > much more modest, with just enabling a way for to do the same for > render clients. All the modeset (and flink open stuff) would still be > only done through the legacy drm node. > OK I see. From what I can tell from the second patch, drm_get_pci_dev will create one (and I guess only one, right ?) render node if the underlying driver has DRIVER_RENDER node feature. The third patch (among other things) adds that feature to Intel driver. So if I boot up a system with these patches and with Intel GPU, I will automagically get one more /dev/dri/renderD128 node, right ? The intent is that the render client opens and uses that render node. The /dev/dri/controlDNN node still remains an unused "orphan", right ? So would you entertain the possibility that the render node is created from user space on demand using an ioctl into the control node ? If that's a possiblity for you, then my set of patches is a superset of what Kristian needs. If you just need a render client, you can create a node with no display resources and you would get something quite close to what these 3 patches try to do. unless I am missing something. -- Ilija
Re: FOSDEM2013: DevRoom or not?
Hello, I believe that the audience at FOSDEM might be interested in a general course about the graphics infrastructure under Linux. What I have in mind would be a talk that explains : what's X, why do we need it, what is so special about 3D applications that you need a "driver" to run any of them (and who's this driver anyway), what's software rendering, HW acceleration, what is Mesa, what is a DRI driver, ... with examples aimed at making people understand not only *how* they are supposed to set up any new hardware they lay their hands upon, but why it works the way it does. Bonus points for a complete status report of current hardware support under Linux at the end. Perhaps I'm wrong but I think that would be a good way to reach out to a community of people who usually have a very, very limited grasp of what it is exactly that we are doing. (I'm including myself because it's easier to do so for the purpose of this e-mail) Would anyone be willing to do such a presentation? -- Greetings, A. Huillet ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm: Fix DRM_MINOR limits for control and render nodes
On Fri, 28 Sep 2012, Kristian H?gsberg wrote:
if (type == DRM_MINOR_CONTROL) {
base += 64;
-limit = base + 127;
+limit = base + 64;
} else if (type == DRM_MINOR_RENDER) {
base += 128;
-limit = base + 255;
+limit = base + 64;
If my first grade arithmetics serves me well, shouldn't limit in the first
clause be base + 63 and in the second clause, base + 127. The render
node starts at 128 and spans to 255, so there are total of 128 render
nodes, 64 card (legacy) nodes and 64 control nodes allowed.
Actually, this construction of limit relative to the base does not achieve
anything. The code would be much more readable if it were something like
this:
if (type == DRM_MINOR_CONTROL) {
base = 64;
limit = 127;
} else if (type == DRM_MINOR_RENDER) {
base = 128;
limit = 255;
}
-- Ilija
Re: [PATCH 1/5] dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER
On 09/28/2012 09:42 PM, Thomas Hellstrom wrote: On 09/28/2012 04:14 PM, Maarten Lankhorst wrote: Hey, Op 28-09-12 14:41, Maarten Lankhorst schreef: Documentation says that code requiring dma-buf should add it to select, so inline fallbacks are not going to be used. A link error will make it obvious what went wrong, instead of silently doing nothing at runtime. The whole patch series is in my tree, I use stg so things might move around, do not use for merging currently: http://cgit.freedesktop.org/~mlankhorst/linux/log/?h=v10-wip It contains everything in here plus the patches for ttm to make it work, I use a old snapshot of drm-next + merge of nouveau as base. Description of what the parts do: Series to fix small api issues when moving over: drm/ttm: Remove cpu_writers related code drm/ttm: Add ttm_bo_is_reserved function drm/radeon: Use ttm_bo_is_reserved drm/vmwgfx: use ttm_bo_is_reserved drm/vmwgfx: remove use of fence_obj_args drm/ttm: remove sync_obj_arg drm/ttm: remove sync_obj_arg from ttm_bo_move_accel_cleanup drm/ttm: remove sync_arg entirely drm/nouveau: unpin buffers before releasing to prevent lockdep warnings drm/nouveau: add reservation to nouveau_bo_vma_del drm/nouveau: add reservation to nouveau_gem_ioctl_cpu_prep Hey great, now we only have one user left for fence waiting before reserving, lets fix that and remove fence lock: ttm_bo_cleanup_refs_or_queue and ttm_bo_cleanup_refs have to reserve before waiting, lets do it in the squash commit so we don't have to throw lock order around everywhere: drm/ttm: remove fence_lock -- Up to this point should be mergeable now Then we start working on lru_lock removal slightly, this means the lru list no longer is empty but can contain only reserved buffers: drm/ttm: do not check if list is empty in ttm_bo_force_list_clean drm/ttm: move reservations for ttm_bo_cleanup_refs -- Still mergeable up to this point, just fixes Patch series from this email: dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER fence: dma-buf cross-device synchronization (v9) seqno-fence: Hardware dma-buf implementation of fencing (v3) reservation: cross-device reservation support reservation: Add lockdep annotation and selftests Now hook it up to drm/ttm in a few steps: usage around reservations: drm/ttm: make ttm reservation calls behave like reservation calls drm/ttm: use dma_reservation api dma-buf: use reservations drm/ttm: allow drivers to pass custom dma_reservation_objects for a bo then kill off the lru lock around reservation: drm/ttm: remove lru_lock around ttm_bo_reserve drm/ttm: simplify ttm_eu_* The lru_lock removal patch removes the lock around lru_lock around the reservation, this will break the assumption that items on the lru list and swap list can always be reserved, and this gets patched up too. Is there any part in ttm you disagree with? I believe that this is all mergeable, the lru_lock removal patch could be moved to before the reservation parts, this might make merging easier, but I don't think there is any ttm part of the series that are wrong on a conceptual level. ~Maarten From another email As previously discussed, I'm unfortunately not prepared to accept removal of the reserve-lru atomicity into the TTM code at this point. The current code is based on this assumption and removing it will end up with efficiencies, breaking the delayed delete code and probably a locking nightmare when trying to write new TTM code. The lru lock removal patch fixed the delayed delete code, it really is not different from the current situation. In fact it is more clear without the guarantee what various parts are trying to protect. Nothing prevents you from holding the lru_lock while trylocking, [1] While this would not cause any deadlocks, Any decent lockdep code would establish lru->reserve as the locking order once a lru- reserve trylock succeeds, but the locking order is really reserve->lru for obvious reasons, which means we will get a lot of lockdep errors? Yes, there are a two reversals like these already in the TTM code, and I'm not very proud of them. leaving that guarantee intact for that part. Can you really just review the patch and tell me where it breaks and/or makes the code unreadable? OK. Now I'm looking at http://cgit.freedesktop.org/~mlankhorst/linux/tree/drivers/gpu/drm/ttm/ttm_bo.c?h=v10-wip&id=1436e2e64697c744d6e186618448e1e6354846bb And let's start with a function that's seen some change, ttm_mem_evict_first: *) Line 715: You're traversing a list using list_for_each() calling a function that may remove the list entry *) Line 722: You're unlocking the lock protecting the list in the middle of list traversal *) Line 507: WARN_ON_ONCE in a code path quite likely to get called? *) Line 512: sleep while atomic *) Line 729: Forgot to unreserve *) Line 730: Forgot to lock lru *) Line 735: Now you're restarting with the first item on the LRU list. Why the loop at line 715? *) Line 740
[Bug 52997] evergreen_cs_track_validate_cb:477 cb[0] bo too small when launching ds2 in wine
https://bugs.freedesktop.org/show_bug.cgi?id=52997 --- Comment #8 from Alex Deucher --- Is this still an issue with a newer version of mesa? git master or a 9.0 snapshot? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120928/34cd012f/attachment.html>
Re: [PATCH 1/5] dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER
On 09/28/2012 04:14 PM, Maarten Lankhorst wrote: Hey, Op 28-09-12 14:41, Maarten Lankhorst schreef: Documentation says that code requiring dma-buf should add it to select, so inline fallbacks are not going to be used. A link error will make it obvious what went wrong, instead of silently doing nothing at runtime. The whole patch series is in my tree, I use stg so things might move around, do not use for merging currently: http://cgit.freedesktop.org/~mlankhorst/linux/log/?h=v10-wip It contains everything in here plus the patches for ttm to make it work, I use a old snapshot of drm-next + merge of nouveau as base. Description of what the parts do: Series to fix small api issues when moving over: drm/ttm: Remove cpu_writers related code drm/ttm: Add ttm_bo_is_reserved function drm/radeon: Use ttm_bo_is_reserved drm/vmwgfx: use ttm_bo_is_reserved drm/vmwgfx: remove use of fence_obj_args drm/ttm: remove sync_obj_arg drm/ttm: remove sync_obj_arg from ttm_bo_move_accel_cleanup drm/ttm: remove sync_arg entirely drm/nouveau: unpin buffers before releasing to prevent lockdep warnings drm/nouveau: add reservation to nouveau_bo_vma_del drm/nouveau: add reservation to nouveau_gem_ioctl_cpu_prep Hey great, now we only have one user left for fence waiting before reserving, lets fix that and remove fence lock: ttm_bo_cleanup_refs_or_queue and ttm_bo_cleanup_refs have to reserve before waiting, lets do it in the squash commit so we don't have to throw lock order around everywhere: drm/ttm: remove fence_lock -- Up to this point should be mergeable now Then we start working on lru_lock removal slightly, this means the lru list no longer is empty but can contain only reserved buffers: drm/ttm: do not check if list is empty in ttm_bo_force_list_clean drm/ttm: move reservations for ttm_bo_cleanup_refs -- Still mergeable up to this point, just fixes Patch series from this email: dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER fence: dma-buf cross-device synchronization (v9) seqno-fence: Hardware dma-buf implementation of fencing (v3) reservation: cross-device reservation support reservation: Add lockdep annotation and selftests Now hook it up to drm/ttm in a few steps: usage around reservations: drm/ttm: make ttm reservation calls behave like reservation calls drm/ttm: use dma_reservation api dma-buf: use reservations drm/ttm: allow drivers to pass custom dma_reservation_objects for a bo then kill off the lru lock around reservation: drm/ttm: remove lru_lock around ttm_bo_reserve drm/ttm: simplify ttm_eu_* The lru_lock removal patch removes the lock around lru_lock around the reservation, this will break the assumption that items on the lru list and swap list can always be reserved, and this gets patched up too. Is there any part in ttm you disagree with? I believe that this is all mergeable, the lru_lock removal patch could be moved to before the reservation parts, this might make merging easier, but I don't think there is any ttm part of the series that are wrong on a conceptual level. ~Maarten From another email As previously discussed, I'm unfortunately not prepared to accept removal of the reserve-lru atomicity into the TTM code at this point. The current code is based on this assumption and removing it will end up with efficiencies, breaking the delayed delete code and probably a locking nightmare when trying to write new TTM code. The lru lock removal patch fixed the delayed delete code, it really is not different from the current situation. In fact it is more clear without the guarantee what various parts are trying to protect. Nothing prevents you from holding the lru_lock while trylocking, [1] While this would not cause any deadlocks, Any decent lockdep code would establish lru->reserve as the locking order once a lru- reserve trylock succeeds, but the locking order is really reserve->lru for obvious reasons, which means we will get a lot of lockdep errors? Yes, there are a two reversals like these already in the TTM code, and I'm not very proud of them. leaving that guarantee intact for that part. Can you really just review the patch and tell me where it breaks and/or makes the code unreadable? OK. Now I'm looking at http://cgit.freedesktop.org/~mlankhorst/linux/tree/drivers/gpu/drm/ttm/ttm_bo.c?h=v10-wip&id=1436e2e64697c744d6e186618448e1e6354846bb And let's start with a function that's seen some change, ttm_mem_evict_first: *) Line 715: You're traversing a list using list_for_each() calling a function that may remove the list entry *) Line 722: You're unlocking the lock protecting the list in the middle of list traversal *) Line 507: WARN_ON_ONCE in a code path quite likely to get called? *) Line 512: sleep while atomic *) Line 729: Forgot to unreserve *) Line 730: Forgot to lock lru *) Line 735: Now you're restarting with the first item on the LRU list. Why the loop at line 715? *) Line 740: Deadlocking reserve *) Line 757: Calling TTM Bo evict
[PATCH 0/3] [RFC] DRM Render Nodes
On Fri, 28 Sep 2012, Alex Deucher wrote: > > I haven't read through your patches yet, but Dave and Ilija already > did something similar a while back: > > http://lists.freedesktop.org/archives/dri-devel/2012-March/020765.html > Actually, there is a, a newer series of patches here (applied few comments I got after first series) http://lists.freedesktop.org/archives/dri-devel/2012-April/021326.html I have the v3 series (applied more comments I got after v2 series, plus some more cleanup) that I have never sent out, because my perception was that there was low interest in this work. I can send the v3 out, if there is a revived interest in this work. The original work is by Dave and I did some major cleanup and built more on the top of it. Kristian's patches at the first glance (I have not looked them in detail) appear more like prep. work (like which ioctl can a render node use and which can't, etc.), but my impression is that they still require the work cited above (Dave's original work and/or my followup work) to actually be able to create and use the render node. BTW, the third patch in Kristian's series is for Intel only and we'll probably need equivalent patches for radeon and nouveau. -- Ilija
[Bug 55416] New: [R600g] Torchlight gives GPU lockup
https://bugs.freedesktop.org/show_bug.cgi?id=55416 Priority: medium Bug ID: 55416 Assignee: dri-devel at lists.freedesktop.org Summary: [R600g] Torchlight gives GPU lockup Severity: normal Classification: Unclassified OS: Linux (All) Reporter: lordheavym at gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa When i try to play the game (after character selection),i've got several GPU lockup until i kill the game: dmesg: --8<-- [ 900.867633] radeon :01:00.0: GPU lockup CP stall for more than 1msec [ 900.867645] radeon :01:00.0: GPU lockup (waiting for 0x00012fb4 last fence id 0x00012faa) [ 900.868726] radeon :01:00.0: GPU softreset [ 900.868732] radeon :01:00.0: GRBM_STATUS=0xE7730828 [ 900.868737] radeon :01:00.0: GRBM_STATUS_SE0=0xFC01 [ 900.868743] radeon :01:00.0: GRBM_STATUS_SE1=0xFC01 [ 900.868748] radeon :01:00.0: SRBM_STATUS=0x20C0 [ 900.868756] radeon :01:00.0: GRBM_SOFT_RESET=0x7F6B [ 900.868863] radeon :01:00.0: GRBM_STATUS=0x3828 [ 900.868868] radeon :01:00.0: GRBM_STATUS_SE0=0x0007 [ 900.868873] radeon :01:00.0: GRBM_STATUS_SE1=0x0007 [ 900.868878] radeon :01:00.0: SRBM_STATUS=0x20C0 [ 900.869884] radeon :01:00.0: GPU reset succeed [ 900.878264] [drm] PCIE GART of 512M enabled (table at 0x0004). [ 900.878371] radeon :01:00.0: WB enabled [ 900.878379] radeon :01:00.0: fence driver on ring 0 use gpu addr 0x4c00 and cpu addr 0x8802218a5c00 [ 900.894717] [drm] ring test on 0 succeeded in 2 usecs [ 900.894770] [drm] ib test on ring 0 succeeded in 0 usecs [ 911.968025] radeon :01:00.0: GPU lockup CP stall for more than 1msec [ 911.968038] radeon :01:00.0: GPU lockup (waiting for 0x00013018 last fence id 0x00013014) [ 911.969149] radeon :01:00.0: GPU softreset [ 911.969155] radeon :01:00.0: GRBM_STATUS=0xE7730828 [ 911.969161] radeon :01:00.0: GRBM_STATUS_SE0=0xFC01 [ 911.969167] radeon :01:00.0: GRBM_STATUS_SE1=0xFC01 [ 911.969172] radeon :01:00.0: SRBM_STATUS=0x20C0 [ 911.969183] radeon :01:00.0: GRBM_SOFT_RESET=0x7F6B [ 911.969291] radeon :01:00.0: GRBM_STATUS=0x3828 [ 911.969297] radeon :01:00.0: GRBM_STATUS_SE0=0x0007 [ 911.969302] radeon :01:00.0: GRBM_STATUS_SE1=0x0007 [ 911.969307] radeon :01:00.0: SRBM_STATUS=0x20C0 [ 911.970313] radeon :01:00.0: GPU reset succeed [ 911.978920] [drm] PCIE GART of 512M enabled (table at 0x0004). [ 911.979030] radeon :01:00.0: WB enabled [ 911.979039] radeon :01:00.0: fence driver on ring 0 use gpu addr 0x4c00 and cpu addr 0x8802218a5c00 [ 911.995378] [drm] ring test on 0 succeeded in 2 usecs [ 911.995432] [drm] ib test on ring 0 succeeded in 0 usecs -->8-- uname -a: Linux archMain 3.5.4-1-ARCH #1 SMP PREEMPT Sat Sep 15 08:12:04 CEST 2012 x86_64 GNU/Linux glxinfo: OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD BARTS OpenGL version string: 2.1 Mesa 9.1-devel (git-124b214) OpenGL shading language version string: 1.30 libdrm: local/libdrm 2.4.39-1 I've got similar lockup with kernel 3.6rc6 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120928/b9734214/attachment.html>
[PATCH] drm: call connector->dpms(OFF) when disabling
On Fri, Sep 28, 2012 at 11:56 AM, Daniel Vetter wrote:
> On Fri, Sep 28, 2012 at 09:27:18AM +0200, Rob Clark wrote:
>> From: Rob Clark
>>
>> When disabling unused connectors, be sure to call connector->dpms(OFF),
>> so if there is actually some IP to turn off (such as external bridge
>> chips, etc), these actually do get turned off.
>>
>> Signed-off-by: Rob Clark
>> Tested-by: Roger Quadros
>
> I think this runs counter to the crtc helper design: connectors are pretty
> much just dummy entities, and any dpms handling is done in the
> encoders/crtcs. If you call connector->funcs->dpms you don't call a crtc
> helper function, but actually the official dpms interface (which then
> again calls down into the encoder/crtc dpms callbacks (which are again
> crtc helper private). This functions are called again a few lines down in
> disable_unused_functions anyway, so the only way this changes behaviour is
> if you already overwrite the dpms interface and don't directly use
> drm_helper_connector_dpms.
yeah, I do this.. I have my own fxn in the connector which does some
stuff, and then calls drm_helper_connector_dpms().
Maybe it just makes sense to always do connector->dpms(OFF) before
unhooking the chain, rather than directly calling dpms on the
encoder/crtc?
> Which is imo a clear sign that the crtc helper is a misfit for your hw and
> you should stop using it ;-) And adding special-case handling like this
> into common code, especially if it weakens the semantic concepts in the
> helper layer is a recipe for a maintainance disaster a few years down the
> road. Hence
well, I think by the time we start adding atomic-modeset and
common/dsi panel framework, there might be need for a new set of
helpers.. but I'm not sure that the hw is quite strange enough to need
an omap specific set of helpers. Maybe I start w/ something in
omapdrm but then refactor into common functions once a few drivers are
converted to atomic modeset and panel framework.
BR,
-R
>
> NACKed-by: Daniel Vetter
>
> Cheers, Daniel
>>
>> ---
>> drivers/gpu/drm/drm_crtc_helper.c |6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_crtc_helper.c
>> b/drivers/gpu/drm/drm_crtc_helper.c
>> index 3252e70..000cda4 100644
>> --- a/drivers/gpu/drm/drm_crtc_helper.c
>> +++ b/drivers/gpu/drm/drm_crtc_helper.c
>> @@ -244,16 +244,16 @@ void drm_helper_disable_unused_functions(struct
>> drm_device *dev)
>> struct drm_crtc *crtc;
>>
>> list_for_each_entry(connector, &dev->mode_config.connector_list, head)
>> {
>> - if (!connector->encoder)
>> - continue;
>> if (connector->status == connector_status_disconnected)
>> connector->encoder = NULL;
>> + if (!connector->encoder)
>> + connector->funcs->dpms(connector, DRM_MODE_DPMS_OFF);
>> }
>>
>> list_for_each_entry(encoder, &dev->mode_config.encoder_list, head) {
>> if (!drm_helper_encoder_in_use(encoder)) {
>> drm_encoder_disable(encoder);
>> - /* disconnector encoder from any connector */
>> + /* disconnect encoder from any connector */
>> encoder->crtc = NULL;
>> }
>> }
>> --
>> 1.7.9.5
>>
>> ___
>> dri-devel mailing list
>>
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/i915: Support render nodes
Enable support for drm render nodes for i915 by flagging the ioctls that
are safe and just needed for rendering.
Signed-off-by: Kristian H?gsberg
---
drivers/gpu/drm/i915/i915_dma.c | 36 ++--
drivers/gpu/drm/i915/i915_drv.c |3 ++-
2 files changed, 20 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 914c0df..d253d71 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1819,7 +1819,7 @@ struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_BATCHBUFFER, i915_batchbuffer, DRM_AUTH),
DRM_IOCTL_DEF_DRV(I915_IRQ_EMIT, i915_irq_emit, DRM_AUTH),
DRM_IOCTL_DEF_DRV(I915_IRQ_WAIT, i915_irq_wait, DRM_AUTH),
- DRM_IOCTL_DEF_DRV(I915_GETPARAM, i915_getparam, DRM_AUTH),
+ DRM_IOCTL_DEF_DRV(I915_GETPARAM, i915_getparam,
DRM_AUTH|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_SETPARAM, i915_setparam,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
DRM_IOCTL_DEF_DRV(I915_ALLOC, drm_noop, DRM_AUTH),
DRM_IOCTL_DEF_DRV(I915_FREE, drm_noop, DRM_AUTH),
@@ -1832,32 +1832,32 @@ struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_HWS_ADDR, i915_set_status_page,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
DRM_IOCTL_DEF_DRV(I915_GEM_INIT, i915_gem_init_ioctl,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY|DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER, i915_gem_execbuffer,
DRM_AUTH|DRM_UNLOCKED),
- DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER2, i915_gem_execbuffer2,
DRM_AUTH|DRM_UNLOCKED),
+ DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER2, i915_gem_execbuffer2,
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_PIN, i915_gem_pin_ioctl,
DRM_AUTH|DRM_ROOT_ONLY|DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(I915_GEM_UNPIN, i915_gem_unpin_ioctl,
DRM_AUTH|DRM_ROOT_ONLY|DRM_UNLOCKED),
- DRM_IOCTL_DEF_DRV(I915_GEM_BUSY, i915_gem_busy_ioctl,
DRM_AUTH|DRM_UNLOCKED),
- DRM_IOCTL_DEF_DRV(I915_GEM_THROTTLE, i915_gem_throttle_ioctl,
DRM_AUTH|DRM_UNLOCKED),
+ DRM_IOCTL_DEF_DRV(I915_GEM_BUSY, i915_gem_busy_ioctl,
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(I915_GEM_THROTTLE, i915_gem_throttle_ioctl,
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_ENTERVT, i915_gem_entervt_ioctl,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY|DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(I915_GEM_LEAVEVT, i915_gem_leavevt_ioctl,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY|DRM_UNLOCKED),
- DRM_IOCTL_DEF_DRV(I915_GEM_CREATE, i915_gem_create_ioctl, DRM_UNLOCKED),
- DRM_IOCTL_DEF_DRV(I915_GEM_PREAD, i915_gem_pread_ioctl, DRM_UNLOCKED),
- DRM_IOCTL_DEF_DRV(I915_GEM_PWRITE, i915_gem_pwrite_ioctl, DRM_UNLOCKED),
- DRM_IOCTL_DEF_DRV(I915_GEM_MMAP, i915_gem_mmap_ioctl, DRM_UNLOCKED),
- DRM_IOCTL_DEF_DRV(I915_GEM_MMAP_GTT, i915_gem_mmap_gtt_ioctl,
DRM_UNLOCKED),
- DRM_IOCTL_DEF_DRV(I915_GEM_SET_DOMAIN, i915_gem_set_domain_ioctl,
DRM_UNLOCKED),
- DRM_IOCTL_DEF_DRV(I915_GEM_SW_FINISH, i915_gem_sw_finish_ioctl,
DRM_UNLOCKED),
- DRM_IOCTL_DEF_DRV(I915_GEM_SET_TILING, i915_gem_set_tiling,
DRM_UNLOCKED),
- DRM_IOCTL_DEF_DRV(I915_GEM_GET_TILING, i915_gem_get_tiling,
DRM_UNLOCKED),
- DRM_IOCTL_DEF_DRV(I915_GEM_GET_APERTURE, i915_gem_get_aperture_ioctl,
DRM_UNLOCKED),
+ DRM_IOCTL_DEF_DRV(I915_GEM_CREATE, i915_gem_create_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(I915_GEM_PREAD, i915_gem_pread_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(I915_GEM_PWRITE, i915_gem_pwrite_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(I915_GEM_MMAP, i915_gem_mmap_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(I915_GEM_MMAP_GTT, i915_gem_mmap_gtt_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(I915_GEM_SET_DOMAIN, i915_gem_set_domain_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(I915_GEM_SW_FINISH, i915_gem_sw_finish_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(I915_GEM_SET_TILING, i915_gem_set_tiling,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(I915_GEM_GET_TILING, i915_gem_get_tiling,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(I915_GEM_GET_APERTURE, i915_gem_get_aperture_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GET_PIPE_FROM_CRTC_ID,
intel_get_pipe_from_crtc_id, DRM_UNLOCKED),
- DRM_IOCTL_DEF_DRV(I915_GEM_MADVISE, i915_gem_madvise_ioctl,
DRM_UNLOCKED),
+ DRM_IOCTL_DEF_DRV(I915_GEM_MADVISE, i915_gem_madvise_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_OVERLAY_PUT_IMAGE, intel_overlay_put_image,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(I915_OVERLAY_ATTRS, intel_overlay_attrs,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(I915_SET_SPRITE_COLORKEY, intel_sprite_se
[PATCH 2/3] drm: Add support for render nodes
This patch introduces a new kind of drm device node: the render node.
A render node exposes a safe subset of the legacy drm device ioctls and can
only be used for rendering. The legacy node supports modesetting, DRI1
and global buffer sharing, while the render node only supports rendering
and limited buffer sharing. A render node can either export a buffer using
the gem flink mechanism, or it can import and export buffers using the
prime fd passing mechanism.
A render node is not associated with any drm master and does not require
the legacy authentication step. Render nodes can be used without
a master, potentially in headless setups such as video-transcoding or
GPGPU work.
Signed-off-by: Kristian H?gsberg
---
drivers/gpu/drm/drm_drv.c | 13 +++--
drivers/gpu/drm/drm_fops.c |9 ++---
drivers/gpu/drm/drm_pci.c |9 +
include/drm/drmP.h |3 +++
4 files changed, 25 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 9238de4..2876e17 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -131,14 +131,14 @@ static struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_UPDATE_DRAW, drm_noop,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
- DRM_IOCTL_DEF(DRM_IOCTL_GEM_CLOSE, drm_gem_close_ioctl, DRM_UNLOCKED),
- DRM_IOCTL_DEF(DRM_IOCTL_GEM_FLINK, drm_gem_flink_ioctl,
DRM_AUTH|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_GEM_CLOSE, drm_gem_close_ioctl, DRM_UNLOCKED |
DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF(DRM_IOCTL_GEM_FLINK, drm_gem_flink_ioctl,
DRM_AUTH|DRM_UNLOCKED | DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_GEM_OPEN, drm_gem_open_ioctl,
DRM_AUTH|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETRESOURCES, drm_mode_getresources,
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
- DRM_IOCTL_DEF(DRM_IOCTL_PRIME_HANDLE_TO_FD,
drm_prime_handle_to_fd_ioctl, DRM_AUTH|DRM_UNLOCKED),
- DRM_IOCTL_DEF(DRM_IOCTL_PRIME_FD_TO_HANDLE,
drm_prime_fd_to_handle_ioctl, DRM_AUTH|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_PRIME_HANDLE_TO_FD,
drm_prime_handle_to_fd_ioctl, DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF(DRM_IOCTL_PRIME_FD_TO_HANDLE,
drm_prime_fd_to_handle_ioctl, DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETPLANERESOURCES, drm_mode_getplane_res,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETCRTC, drm_mode_getcrtc,
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
@@ -427,9 +427,10 @@ long drm_ioctl(struct file *filp,
DRM_DEBUG("no function\n");
retcode = -EINVAL;
} else if (((ioctl->flags & DRM_ROOT_ONLY) && !capable(CAP_SYS_ADMIN))
||
- ((ioctl->flags & DRM_AUTH) && !file_priv->authenticated) ||
+ ((ioctl->flags & DRM_AUTH) && (file_priv->minor->type !=
DRM_MINOR_RENDER) && !file_priv->authenticated) ||
((ioctl->flags & DRM_MASTER) && !file_priv->is_master) ||
- (!(ioctl->flags & DRM_CONTROL_ALLOW) &&
(file_priv->minor->type == DRM_MINOR_CONTROL))) {
+ (!(ioctl->flags & DRM_CONTROL_ALLOW) &&
(file_priv->minor->type == DRM_MINOR_CONTROL)) ||
+ (!(ioctl->flags & DRM_RENDER_ALLOW) &&
(file_priv->minor->type == DRM_MINOR_RENDER))) {
retcode = -EACCES;
} else {
if (cmd & (IOC_IN | IOC_OUT)) {
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 5062eec..bee4244 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -279,7 +279,7 @@ static int drm_open_helper(struct inode *inode, struct file
*filp,
/* if there is no current master make this fd it */
mutex_lock(&dev->struct_mutex);
- if (!priv->minor->master) {
+ if (!priv->minor->master && priv->minor->type != DRM_MINOR_RENDER) {
/* create a new master */
priv->minor->master = drm_master_create(priv->minor);
if (!priv->minor->master) {
@@ -318,10 +318,12 @@ static int drm_open_helper(struct inode *inode, struct
file *filp,
}
}
mutex_unlock(&dev->struct_mutex);
- } else {
+ } else if (priv->minor->type != DRM_MINOR_RENDER) {
/* get a reference to the master */
priv->master = drm_master_get(priv->minor->master);
mutex_unlock(&dev->struct_mutex);
+ } else {
+ mutex_unlock(&dev->struct_mutex);
}
mutex_lock(&dev->struct_mutex);
@@ -513,7 +515,8 @@ int drm_release(struct inode *inode, struct file *filp)
iput(container_of(dev->dev_mapping, struct inode, i_data));
/* drop the reference held my the file priv */
- drm_master_put(&file_priv->master);
+ if (file_priv->master)
+ drm_master_put(&file_priv->master);
file_priv->is_master = 0;
[PATCH 1/3] drm: Fix DRM_MINOR limits for control and render nodes
We got the minor number base right, but limit is too big and causes the
minor numer ranges for the control and render nodes to overlap.
Signed-off-by: Kristian H?gsberg
---
drivers/gpu/drm/drm_stub.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index 21bcd4a..d6d5160 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -107,10 +107,10 @@ static int drm_minor_get_id(struct drm_device *dev, int
type)
if (type == DRM_MINOR_CONTROL) {
base += 64;
-limit = base + 127;
+limit = base + 64;
} else if (type == DRM_MINOR_RENDER) {
base += 128;
-limit = base + 255;
+limit = base + 64;
}
again:
--
1.7.10.2
[PATCH 0/3] [RFC] DRM Render Nodes
Here's the patch to implement render nodes as discussed in the "DRM2" talk at XDC: http://wiki.x.org/wiki/Events/XDC2012/Proceedings#DRM2 The core problem is that DRM security is compromised in the face of VT switching and multiple DRM masters. Any local user can access all shared buffers from within any X server on the system, even when that user doesn't have access to any of those X servers. The fix for this is to use dmabuf/prime and fd passing for buffer sharing. That infrastructure is already in place and we need to start using that in user space. Once we're passing buffers between display servers and clients in a point-to-point fashion, we no longer need to authenticate clients. We just need to make sure they can only render and import/export buffers to fds. That's what this patch does, by creating a new type of drm device node. Accessing this node doesn't require authentication (and as such can be used without a master, ie headless), but will only expose the safe, modern (DRI2ish) rendering ioctls. Once userspace is sharing buffers through fd passing, the legacy card0 node can be locked down by unix permissions, for example in a drm-master group, so that only setgid binaries (X, weston, other KMS apps) can access it. Kristian See also: http://wiki.x.org/wiki/Events/XDC2012/Proceedings#Graphics_stack_security https://lwn.net/Articles/517375/
[PATCH] drm: call connector->dpms(OFF) when disabling
On Fri, Sep 28, 2012 at 09:27:18AM +0200, Rob Clark wrote:
> From: Rob Clark
>
> When disabling unused connectors, be sure to call connector->dpms(OFF),
> so if there is actually some IP to turn off (such as external bridge
> chips, etc), these actually do get turned off.
>
> Signed-off-by: Rob Clark
> Tested-by: Roger Quadros
I think this runs counter to the crtc helper design: connectors are pretty
much just dummy entities, and any dpms handling is done in the
encoders/crtcs. If you call connector->funcs->dpms you don't call a crtc
helper function, but actually the official dpms interface (which then
again calls down into the encoder/crtc dpms callbacks (which are again
crtc helper private). This functions are called again a few lines down in
disable_unused_functions anyway, so the only way this changes behaviour is
if you already overwrite the dpms interface and don't directly use
drm_helper_connector_dpms.
Which is imo a clear sign that the crtc helper is a misfit for your hw and
you should stop using it ;-) And adding special-case handling like this
into common code, especially if it weakens the semantic concepts in the
helper layer is a recipe for a maintainance disaster a few years down the
road. Hence
NACKed-by: Daniel Vetter
Cheers, Daniel
>
> ---
> drivers/gpu/drm/drm_crtc_helper.c |6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc_helper.c
> b/drivers/gpu/drm/drm_crtc_helper.c
> index 3252e70..000cda4 100644
> --- a/drivers/gpu/drm/drm_crtc_helper.c
> +++ b/drivers/gpu/drm/drm_crtc_helper.c
> @@ -244,16 +244,16 @@ void drm_helper_disable_unused_functions(struct
> drm_device *dev)
> struct drm_crtc *crtc;
>
> list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
> - if (!connector->encoder)
> - continue;
> if (connector->status == connector_status_disconnected)
> connector->encoder = NULL;
> + if (!connector->encoder)
> + connector->funcs->dpms(connector, DRM_MODE_DPMS_OFF);
> }
>
> list_for_each_entry(encoder, &dev->mode_config.encoder_list, head) {
> if (!drm_helper_encoder_in_use(encoder)) {
> drm_encoder_disable(encoder);
> - /* disconnector encoder from any connector */
> + /* disconnect encoder from any connector */
> encoder->crtc = NULL;
> }
> }
> --
> 1.7.9.5
>
> ___
> dri-devel mailing list
>
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
Re: [PATCH 0/3] [RFC] DRM Render Nodes
On Fri, Sep 28, 2012 at 8:42 PM, Ilija Hadzic wrote: > > > On Fri, 28 Sep 2012, Daniel Vetter wrote: > >> On a quick look the rendernode Kristian propose and your work seem to >> attack slightly different issues. Your/Dave's patch series seems to >> put large efforts into (dynamically) splitting up the resources of a >> drm device, including the modeset stuff. > > > Correct, the goal is to be able to run multiseat while sharing a GPU. > Actually, with my variant of render nodes, I even got multiple desktops > residing in different LXC containers to share the GPU, which is kind of > cool. > > >> Kristians proposal here is >> much more modest, with just enabling a way for to do the same for >> render clients. All the modeset (and flink open stuff) would still be >> only done through the legacy drm node. >> > > OK I see. From what I can tell from the second patch, drm_get_pci_dev will > create one (and I guess only one, right ?) render node if the underlying > driver has DRIVER_RENDER node feature. The third patch (among other things) > adds that feature to Intel driver. > > So if I boot up a system with these patches and with Intel GPU, I will > automagically get one more /dev/dri/renderD128 node, right ? The intent is > that the render client opens and uses that render node. The > /dev/dri/controlDNN node still remains an unused "orphan", right ? Yeah, the plan is to just have one single render node and ensure insulation by not allowing any open file of that render node to access any other buffer not associated to the file_prive. Like I've said, the current patches have a little hole wrt mmap handling there ;-) The only way to share buffers is via dma_buf (which is fd based, so we could attach full selinux contexts if required) or flink (but not opening an flink name, that requires master rights on the legacy node). > So would you entertain the possibility that the render node is created from > user space on demand using an ioctl into the control node ? If that's a > possiblity for you, then my set of patches is a superset of what Kristian > needs. If you just need a render client, you can create a node with no > display resources and you would get something quite close to what these 3 > patches try to do. unless I am missing something. Well, dynamically creating render nodes is not required just for insulating different render clients. The goal is very much to allow background/headless usage of the gpu, e.g. for opencl and video encode/decode. So first asking a central deamon to span another render node just to transcode another video isn't that great. Obviously the security separation only works if the gpu actually supports different vm address spaces for each node ... The multi-seat issue is imo orthogonal to that and I don't think we should mangle (like you've noticed, ppl seem to get scared about it and not push those patches too much). And with new stuff like atomic modeset and gpus having a lot of shared resources in the display hw (plls, memory bw, shared links between pipes, ...) I don't think we could even statically split up the modeset resurces, like your patch would allow. Imho a better solution for the mutliseat use-case would be to have a (priviledge) system-compositor that handles the resource sharing between the different seats. Display servers would then simply be yet another render node client (and doing modeset changes through a protocol to the system compositor). The system-compositor could be very well something that would aweful closely resemble wayland ;-) Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[ 192/262] drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222S
From: Greg KH
3.5-stable review patch. If anyone has any objections, please let me know.
--
From: Paul Menzel
commit 6f33814bd4d9cfe76033a31b1c0c76c960cd8e4b upstream.
Connecting an ASUS VW222S [1] over VGA a garbled screen is shown with
vertical stripes in the top half.
In commit bc42aabc [2]
commit bc42aabc6a01b92b0f961d65671564e0e1cd7592
Author: Adam Jackson
Date: Wed May 23 16:26:54 2012 -0400
drm/edid/quirks: ViewSonic VA2026w
Adam Jackson added the quirk `EDID_QUIRK_FORCE_REDUCED_BLANKING` which
is also needed for this ASUS monitor.
All log files and output from `xrandr` is included in the referenced
Bugzilla report #17629.
Please note that this monitor only has a VGA (D-Sub) connector [1].
[1] http://www.asus.com/Display/LCD_Monitors/VW222S/
[2]
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=bc42aabc6a01b92b0f961d65671564e0e1cd7592
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=17629
Signed-off-by: Paul Menzel
Cc:
Cc: Adam Jackson
Cc: Ian Pilcher
Signed-off-by: Dave Airlie
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/drm_edid.c |3 +++
1 file changed, 3 insertions(+)
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -87,6 +87,9 @@ static struct edid_quirk {
int product_id;
u32 quirks;
} edid_quirk_list[] = {
+ /* ASUS VW222S */
+ { "ACI", 0x22a2, EDID_QUIRK_FORCE_REDUCED_BLANKING },
+
/* Acer AL1706 */
{ "ACR", 44358, EDID_QUIRK_PREFER_LARGE_60 },
/* Acer F51 */
Re: [PATCH 0/3] [RFC] DRM Render Nodes
On Fri, 28 Sep 2012, Daniel Vetter wrote: On a quick look the rendernode Kristian propose and your work seem to attack slightly different issues. Your/Dave's patch series seems to put large efforts into (dynamically) splitting up the resources of a drm device, including the modeset stuff. Correct, the goal is to be able to run multiseat while sharing a GPU. Actually, with my variant of render nodes, I even got multiple desktops residing in different LXC containers to share the GPU, which is kind of cool. Kristians proposal here is much more modest, with just enabling a way for to do the same for render clients. All the modeset (and flink open stuff) would still be only done through the legacy drm node. OK I see. From what I can tell from the second patch, drm_get_pci_dev will create one (and I guess only one, right ?) render node if the underlying driver has DRIVER_RENDER node feature. The third patch (among other things) adds that feature to Intel driver. So if I boot up a system with these patches and with Intel GPU, I will automagically get one more /dev/dri/renderD128 node, right ? The intent is that the render client opens and uses that render node. The /dev/dri/controlDNN node still remains an unused "orphan", right ? So would you entertain the possibility that the render node is created from user space on demand using an ioctl into the control node ? If that's a possiblity for you, then my set of patches is a superset of what Kristian needs. If you just need a render client, you can create a node with no display resources and you would get something quite close to what these 3 patches try to do. unless I am missing something. -- Ilija ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] [RFC] DRM Render Nodes
On Fri, Sep 28, 2012 at 7:59 PM, Ilija Hadzic wrote: > > > On Fri, 28 Sep 2012, Alex Deucher wrote: >> >> >> I haven't read through your patches yet, but Dave and Ilija already >> did something similar a while back: >> >> http://lists.freedesktop.org/archives/dri-devel/2012-March/020765.html >> > > Actually, there is a, a newer series of patches here (applied few comments I > got after first series) > > http://lists.freedesktop.org/archives/dri-devel/2012-April/021326.html > > I have the v3 series (applied more comments I got after v2 series, plus some > more cleanup) that I have never sent out, because my perception was that > there was low interest in this work. I can send the v3 out, if there is a > revived interest in this work. > > The original work is by Dave and I did some major cleanup and built more on > the top of it. > > Kristian's patches at the first glance (I have not looked them in detail) > appear more like prep. work (like which ioctl can a render node use and > which can't, etc.), but my impression is that they still require the work > cited above (Dave's original work and/or my followup work) to actually be > able to create and use the render node. > > BTW, the third patch in Kristian's series is for Intel only and we'll > probably need equivalent patches for radeon and nouveau. On a quick look the rendernode Kristian propose and your work seem to attack slightly different issues. Your/Dave's patch series seems to put large efforts into (dynamically) splitting up the resources of a drm device, including the modeset stuff. Kristians proposal here is much more modest, with just enabling a way for to do the same for render clients. All the modeset (and flink open stuff) would still be only done through the legacy drm node. One thing though that Kristians patches miss is properly splitting out mmap support such that each open file of the rendernode only has access to it's file-private gem object and not all of them. Since linux has the mmap interface at the struct file level, that shouldn't be a big hassle to get off the ground: We just need to add an mmap_offset table to file_prive and then add the offset lookup at the right place (and do the lookup with the right table), depending upon whether it's a legacy or a new render node doing the offset create (or mmap syscall). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm: Fix DRM_MINOR limits for control and render nodes
On Fri, 28 Sep 2012, Kristian Høgsberg wrote:
if (type == DRM_MINOR_CONTROL) {
base += 64;
-limit = base + 127;
+limit = base + 64;
} else if (type == DRM_MINOR_RENDER) {
base += 128;
-limit = base + 255;
+limit = base + 64;
If my first grade arithmetics serves me well, shouldn't limit in the first
clause be base + 63 and in the second clause, base + 127. The render
node starts at 128 and spans to 255, so there are total of 128 render
nodes, 64 card (legacy) nodes and 64 control nodes allowed.
Actually, this construction of limit relative to the base does not achieve
anything. The code would be much more readable if it were something like
this:
if (type == DRM_MINOR_CONTROL) {
base = 64;
limit = 127;
} else if (type == DRM_MINOR_RENDER) {
base = 128;
limit = 255;
}
-- Ilija
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] [RFC] DRM Render Nodes
On Fri, 28 Sep 2012, Alex Deucher wrote: I haven't read through your patches yet, but Dave and Ilija already did something similar a while back: http://lists.freedesktop.org/archives/dri-devel/2012-March/020765.html Actually, there is a, a newer series of patches here (applied few comments I got after first series) http://lists.freedesktop.org/archives/dri-devel/2012-April/021326.html I have the v3 series (applied more comments I got after v2 series, plus some more cleanup) that I have never sent out, because my perception was that there was low interest in this work. I can send the v3 out, if there is a revived interest in this work. The original work is by Dave and I did some major cleanup and built more on the top of it. Kristian's patches at the first glance (I have not looked them in detail) appear more like prep. work (like which ioctl can a render node use and which can't, etc.), but my impression is that they still require the work cited above (Dave's original work and/or my followup work) to actually be able to create and use the render node. BTW, the third patch in Kristian's series is for Intel only and we'll probably need equivalent patches for radeon and nouveau. -- Ilija ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] [RFC] DRM Render Nodes
On Fri, Sep 28, 2012 at 12:35 PM, Kristian Høgsberg wrote: > Here's the patch to implement render nodes as discussed in the "DRM2" > talk at XDC: > > http://wiki.x.org/wiki/Events/XDC2012/Proceedings#DRM2 > > The core problem is that DRM security is compromised in the face of > VT switching and multiple DRM masters. Any local user can access all > shared buffers from within any X server on the system, even when that > user doesn't have access to any of those X servers. > > The fix for this is to use dmabuf/prime and fd passing for buffer sharing. > That infrastructure is already in place and we need to start using that in > user space. Once we're passing buffers between display servers and clients > in a point-to-point fashion, we no longer need to authenticate clients. We > just need to make sure they can only render and import/export buffers to > fds. That's what this patch does, by creating a new type of drm device > node. Accessing this node doesn't require authentication (and as such > can be used without a master, ie headless), but will only expose the safe, > modern (DRI2ish) rendering ioctls. > > Once userspace is sharing buffers through fd passing, the legacy card0 node > can be locked down by unix permissions, for example in a drm-master group, > so that only setgid binaries (X, weston, other KMS apps) can access it. > I haven't read through your patches yet, but Dave and Ilija already did something similar a while back: http://lists.freedesktop.org/archives/dri-devel/2012-March/020765.html Alex > Kristian > > > See also: > > http://wiki.x.org/wiki/Events/XDC2012/Proceedings#Graphics_stack_security > > https://lwn.net/Articles/517375/ > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: FOSDEM2013: DevRoom or not?
On Fri, Sep 28, 2012 at 6:07 PM, Jesse Barnes wrote: > On Fri, 28 Sep 2012 17:44:27 +0200 > Luc Verhaegen wrote: > >> On Fri, Sep 21, 2012 at 11:35:12AM +0200, Luc Verhaegen wrote: >> > On Sun, Aug 12, 2012 at 03:50:16PM +0200, Luc Verhaegen wrote: >> > > Hi, >> > > >> > > The FOSDEM organizers have sent out a call for devrooms. FOSDEM this >> > > year is on the weekend of the 2nd and 3rd of February 2013. >> > > >> > > After the success of this formula last year, where, for the first time >> > > ever, we had a properly filled devroom schedule when the deadline hit, i >> > > am going to re-apply the same formula: >> > > * By the 28th of september, i need 6 committed speakers, otherwise i >> > > will not apply for a DevRoom. 6 people need to apply for a talk slot >> > > who _definitely_ will come to FOSDEM on February 2nd and/or 3rd 2013. >> > > This "definitely" means: >> > > * Don't knowingly plan anything else for this weekend. >> > > * Come to FOSDEM even if your corporation does not fund you (though >> > > feel free to contact the board individually for funding) >> > > * Make sure that you are allowed to travel to the shengen area in >> > > february. >> > > * Catastrophies excluded of course. Such catastrophies include >> > > things like train-derailments and such, but explicitely excludes >> > > hangovers :p >> > > * Scheduling based on timeliness of application: the earlier you apply, >> > > the better slot you get. >> > > * FOSDEMs final deadline for the full schedule is likely around 15th of >> > > january 2013. But do not count on that deadline, we will only do >> > > hourly slots, to keep people from running around between devrooms like >> > > headless chickens. Only 12-16 slots will be available, first come, >> > > first serve. >> > > >> > > I will set up a wiki page tonight, at http://wiki.x.org/wiki/fosdem2013 >> > > >> > > I hope we get a nice devroom like we had last time. That new building we >> > > were in was really amazing, even though it took a while before all >> > > FOSDEM visitors found it. >> > > >> > > Thanks, >> > > >> > > Luc Verhaegen. >> > >> > Just a heads up guys, we have a week left and not a single speaker yet! >> > >> > Given the timing of XDC and the FOSDEM deadines, this is not too >> > surprising, but still, with XDC2012 in its final day it is high time >> > that we start thinking about FOSDEM. I will later on shout at people >> > here in the room too :) >> > >> > All we need now is people who will definitely come to FOSDEM, and who >> > are willing to talk in the DevRoom. If a vague idea of a topic is >> > already known, then great, but this is not necessary yet. I now put up a >> > preliminary wiki page at wiki.x.org/wiki/fosdem2013, add yourself to the >> > list there. >> > >> > Thanks, >> > >> > Luc Verhaegen. >> >> Final reminder: the deadline is tonight. >> >> So far there are three speakers who lined up, and my feeling is that >> Matthieu and Marc lined up just so that the deadline and requirement >> will be met. So only a single person is intending to come to fosdem and >> has a topic he wants to talk about. >> >> Come on guys. Surely we can do better than that. > > I could come up with something, maybe people would be interested in > hearing about some of our recent SoC work? I'd have to see what I > could get approval for, but I could probably find *something* that's > not still secret. :) Ok, ok, I'll volunteer myself for another a talk about something kernel-ish. Maybe and update on drm/i915 modesettting stuff (we should be able to check off a lot of the todos from the xdc slides by then) or maybe a talk about drm/i915 testing efforts (yeah, a lot has been happening there without much publicity this year). Or something else. To make the intel roundup complete: Chris, can I volunteer you to give another stab at an "updates from flatland" talk? Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] dma-buf: might_sleep() in dma_buf_unmap_attachment()
Op 28-09-12 09:29, Rob Clark schreef:
> From: Rob Clark
>
> We never really clarified if unmap could be done in atomic context.
> But since mapping might require sleeping, this implies mutex in use
> to synchronize mapping/unmapping, so unmap could sleep as well. Add
> a might_sleep() to clarify this.
>
> Signed-off-by: Rob Clark
> Acked-by: Daniel Vetter
> ---
> drivers/base/dma-buf.c |2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
> index c30f3e1..877eacb 100644
> --- a/drivers/base/dma-buf.c
> +++ b/drivers/base/dma-buf.c
> @@ -298,6 +298,8 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment
> *attach,
> struct sg_table *sg_table,
> enum dma_data_direction direction)
> {
> + might_sleep();
> +
> if (WARN_ON(!attach || !attach->dmabuf || !sg_table))
> return;
>
Looks good to me!
Reviewed-by: Maarten Lankhorst
[PATCH 3/3] drm/i915: Support render nodes
Enable support for drm render nodes for i915 by flagging the ioctls that
are safe and just needed for rendering.
Signed-off-by: Kristian Høgsberg
---
drivers/gpu/drm/i915/i915_dma.c | 36 ++--
drivers/gpu/drm/i915/i915_drv.c |3 ++-
2 files changed, 20 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 914c0df..d253d71 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1819,7 +1819,7 @@ struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_BATCHBUFFER, i915_batchbuffer, DRM_AUTH),
DRM_IOCTL_DEF_DRV(I915_IRQ_EMIT, i915_irq_emit, DRM_AUTH),
DRM_IOCTL_DEF_DRV(I915_IRQ_WAIT, i915_irq_wait, DRM_AUTH),
- DRM_IOCTL_DEF_DRV(I915_GETPARAM, i915_getparam, DRM_AUTH),
+ DRM_IOCTL_DEF_DRV(I915_GETPARAM, i915_getparam,
DRM_AUTH|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_SETPARAM, i915_setparam,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
DRM_IOCTL_DEF_DRV(I915_ALLOC, drm_noop, DRM_AUTH),
DRM_IOCTL_DEF_DRV(I915_FREE, drm_noop, DRM_AUTH),
@@ -1832,32 +1832,32 @@ struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_HWS_ADDR, i915_set_status_page,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
DRM_IOCTL_DEF_DRV(I915_GEM_INIT, i915_gem_init_ioctl,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY|DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER, i915_gem_execbuffer,
DRM_AUTH|DRM_UNLOCKED),
- DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER2, i915_gem_execbuffer2,
DRM_AUTH|DRM_UNLOCKED),
+ DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER2, i915_gem_execbuffer2,
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_PIN, i915_gem_pin_ioctl,
DRM_AUTH|DRM_ROOT_ONLY|DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(I915_GEM_UNPIN, i915_gem_unpin_ioctl,
DRM_AUTH|DRM_ROOT_ONLY|DRM_UNLOCKED),
- DRM_IOCTL_DEF_DRV(I915_GEM_BUSY, i915_gem_busy_ioctl,
DRM_AUTH|DRM_UNLOCKED),
- DRM_IOCTL_DEF_DRV(I915_GEM_THROTTLE, i915_gem_throttle_ioctl,
DRM_AUTH|DRM_UNLOCKED),
+ DRM_IOCTL_DEF_DRV(I915_GEM_BUSY, i915_gem_busy_ioctl,
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(I915_GEM_THROTTLE, i915_gem_throttle_ioctl,
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_ENTERVT, i915_gem_entervt_ioctl,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY|DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(I915_GEM_LEAVEVT, i915_gem_leavevt_ioctl,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY|DRM_UNLOCKED),
- DRM_IOCTL_DEF_DRV(I915_GEM_CREATE, i915_gem_create_ioctl, DRM_UNLOCKED),
- DRM_IOCTL_DEF_DRV(I915_GEM_PREAD, i915_gem_pread_ioctl, DRM_UNLOCKED),
- DRM_IOCTL_DEF_DRV(I915_GEM_PWRITE, i915_gem_pwrite_ioctl, DRM_UNLOCKED),
- DRM_IOCTL_DEF_DRV(I915_GEM_MMAP, i915_gem_mmap_ioctl, DRM_UNLOCKED),
- DRM_IOCTL_DEF_DRV(I915_GEM_MMAP_GTT, i915_gem_mmap_gtt_ioctl,
DRM_UNLOCKED),
- DRM_IOCTL_DEF_DRV(I915_GEM_SET_DOMAIN, i915_gem_set_domain_ioctl,
DRM_UNLOCKED),
- DRM_IOCTL_DEF_DRV(I915_GEM_SW_FINISH, i915_gem_sw_finish_ioctl,
DRM_UNLOCKED),
- DRM_IOCTL_DEF_DRV(I915_GEM_SET_TILING, i915_gem_set_tiling,
DRM_UNLOCKED),
- DRM_IOCTL_DEF_DRV(I915_GEM_GET_TILING, i915_gem_get_tiling,
DRM_UNLOCKED),
- DRM_IOCTL_DEF_DRV(I915_GEM_GET_APERTURE, i915_gem_get_aperture_ioctl,
DRM_UNLOCKED),
+ DRM_IOCTL_DEF_DRV(I915_GEM_CREATE, i915_gem_create_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(I915_GEM_PREAD, i915_gem_pread_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(I915_GEM_PWRITE, i915_gem_pwrite_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(I915_GEM_MMAP, i915_gem_mmap_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(I915_GEM_MMAP_GTT, i915_gem_mmap_gtt_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(I915_GEM_SET_DOMAIN, i915_gem_set_domain_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(I915_GEM_SW_FINISH, i915_gem_sw_finish_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(I915_GEM_SET_TILING, i915_gem_set_tiling,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(I915_GEM_GET_TILING, i915_gem_get_tiling,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(I915_GEM_GET_APERTURE, i915_gem_get_aperture_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GET_PIPE_FROM_CRTC_ID,
intel_get_pipe_from_crtc_id, DRM_UNLOCKED),
- DRM_IOCTL_DEF_DRV(I915_GEM_MADVISE, i915_gem_madvise_ioctl,
DRM_UNLOCKED),
+ DRM_IOCTL_DEF_DRV(I915_GEM_MADVISE, i915_gem_madvise_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_OVERLAY_PUT_IMAGE, intel_overlay_put_image,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(I915_OVERLAY_ATTRS, intel_overlay_attrs,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(I915_SET_SPRITE_COLORKEY, intel_sprite_se
[PATCH 2/3] drm: Add support for render nodes
This patch introduces a new kind of drm device node: the render node.
A render node exposes a safe subset of the legacy drm device ioctls and can
only be used for rendering. The legacy node supports modesetting, DRI1
and global buffer sharing, while the render node only supports rendering
and limited buffer sharing. A render node can either export a buffer using
the gem flink mechanism, or it can import and export buffers using the
prime fd passing mechanism.
A render node is not associated with any drm master and does not require
the legacy authentication step. Render nodes can be used without
a master, potentially in headless setups such as video-transcoding or
GPGPU work.
Signed-off-by: Kristian Høgsberg
---
drivers/gpu/drm/drm_drv.c | 13 +++--
drivers/gpu/drm/drm_fops.c |9 ++---
drivers/gpu/drm/drm_pci.c |9 +
include/drm/drmP.h |3 +++
4 files changed, 25 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 9238de4..2876e17 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -131,14 +131,14 @@ static struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_UPDATE_DRAW, drm_noop,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
- DRM_IOCTL_DEF(DRM_IOCTL_GEM_CLOSE, drm_gem_close_ioctl, DRM_UNLOCKED),
- DRM_IOCTL_DEF(DRM_IOCTL_GEM_FLINK, drm_gem_flink_ioctl,
DRM_AUTH|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_GEM_CLOSE, drm_gem_close_ioctl, DRM_UNLOCKED |
DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF(DRM_IOCTL_GEM_FLINK, drm_gem_flink_ioctl,
DRM_AUTH|DRM_UNLOCKED | DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_GEM_OPEN, drm_gem_open_ioctl,
DRM_AUTH|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETRESOURCES, drm_mode_getresources,
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
- DRM_IOCTL_DEF(DRM_IOCTL_PRIME_HANDLE_TO_FD,
drm_prime_handle_to_fd_ioctl, DRM_AUTH|DRM_UNLOCKED),
- DRM_IOCTL_DEF(DRM_IOCTL_PRIME_FD_TO_HANDLE,
drm_prime_fd_to_handle_ioctl, DRM_AUTH|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_PRIME_HANDLE_TO_FD,
drm_prime_handle_to_fd_ioctl, DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF(DRM_IOCTL_PRIME_FD_TO_HANDLE,
drm_prime_fd_to_handle_ioctl, DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETPLANERESOURCES, drm_mode_getplane_res,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETCRTC, drm_mode_getcrtc,
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
@@ -427,9 +427,10 @@ long drm_ioctl(struct file *filp,
DRM_DEBUG("no function\n");
retcode = -EINVAL;
} else if (((ioctl->flags & DRM_ROOT_ONLY) && !capable(CAP_SYS_ADMIN))
||
- ((ioctl->flags & DRM_AUTH) && !file_priv->authenticated) ||
+ ((ioctl->flags & DRM_AUTH) && (file_priv->minor->type !=
DRM_MINOR_RENDER) && !file_priv->authenticated) ||
((ioctl->flags & DRM_MASTER) && !file_priv->is_master) ||
- (!(ioctl->flags & DRM_CONTROL_ALLOW) &&
(file_priv->minor->type == DRM_MINOR_CONTROL))) {
+ (!(ioctl->flags & DRM_CONTROL_ALLOW) &&
(file_priv->minor->type == DRM_MINOR_CONTROL)) ||
+ (!(ioctl->flags & DRM_RENDER_ALLOW) &&
(file_priv->minor->type == DRM_MINOR_RENDER))) {
retcode = -EACCES;
} else {
if (cmd & (IOC_IN | IOC_OUT)) {
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 5062eec..bee4244 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -279,7 +279,7 @@ static int drm_open_helper(struct inode *inode, struct file
*filp,
/* if there is no current master make this fd it */
mutex_lock(&dev->struct_mutex);
- if (!priv->minor->master) {
+ if (!priv->minor->master && priv->minor->type != DRM_MINOR_RENDER) {
/* create a new master */
priv->minor->master = drm_master_create(priv->minor);
if (!priv->minor->master) {
@@ -318,10 +318,12 @@ static int drm_open_helper(struct inode *inode, struct
file *filp,
}
}
mutex_unlock(&dev->struct_mutex);
- } else {
+ } else if (priv->minor->type != DRM_MINOR_RENDER) {
/* get a reference to the master */
priv->master = drm_master_get(priv->minor->master);
mutex_unlock(&dev->struct_mutex);
+ } else {
+ mutex_unlock(&dev->struct_mutex);
}
mutex_lock(&dev->struct_mutex);
@@ -513,7 +515,8 @@ int drm_release(struct inode *inode, struct file *filp)
iput(container_of(dev->dev_mapping, struct inode, i_data));
/* drop the reference held my the file priv */
- drm_master_put(&file_priv->master);
+ if (file_priv->master)
+ drm_master_put(&file_priv->master);
file_priv->is_mast
[PATCH 1/3] drm: Fix DRM_MINOR limits for control and render nodes
We got the minor number base right, but limit is too big and causes the
minor numer ranges for the control and render nodes to overlap.
Signed-off-by: Kristian Høgsberg
---
drivers/gpu/drm/drm_stub.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index 21bcd4a..d6d5160 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -107,10 +107,10 @@ static int drm_minor_get_id(struct drm_device *dev, int
type)
if (type == DRM_MINOR_CONTROL) {
base += 64;
-limit = base + 127;
+limit = base + 64;
} else if (type == DRM_MINOR_RENDER) {
base += 128;
-limit = base + 255;
+limit = base + 64;
}
again:
--
1.7.10.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: call connector->dpms(OFF) when disabling
On Fri, Sep 28, 2012 at 8:19 AM, Rob Clark wrote: > On Fri, Sep 28, 2012 at 1:55 PM, Daniel Vetter wrote: >> On Fri, Sep 28, 2012 at 12:54 PM, Rob Clark wrote: >>> Maybe it just makes sense to always do connector->dpms(OFF) before >>> unhooking the chain, rather than directly calling dpms on the >>> encoder/crtc? >> >> Well, that makes the entire (optional) ->disable stuff a bit more >> awkward. The thing imo really is that the crtc helper assume that the >> connectors do not hold any hw state, whereas you're omap driver >> violates that assumption. >> >> For the intel driver we've fixed this by doing any sink handling (e.g. >> for dp) in the encoder->dpms functions. So I think the right way for >> omap is to do the same (or conclude that the crtc helpers are a bad >> fit and ditch them). Having connectors that are special, but only in >> some of the cases imo makes squat sense for a generic helper library. > > hmm.. well I have been thinking that some of what is currently in the > connectors needs to move into the encoders.. this would help, although > will take some time. > Which is imo a clear sign that the crtc helper is a misfit for your hw and you should stop using it ;-) And adding special-case handling like this into common code, especially if it weakens the semantic concepts in the helper layer is a recipe for a maintainance disaster a few years down the road. Hence >>> >>> well, I think by the time we start adding atomic-modeset and >>> common/dsi panel framework, there might be need for a new set of >>> helpers.. but I'm not sure that the hw is quite strange enough to need >>> an omap specific set of helpers. Maybe I start w/ something in >>> omapdrm but then refactor into common functions once a few drivers are >>> converted to atomic modeset and panel framework. >> >> I see a few ways forward with the crtc helpers and atomic modeset: >> - bake the assumption into the code that drivers using the crtc >> helpers don't have any shared global resources and drop all these >> checks. This would boil down to writing a new set_config to handle >> global modeset changes (instead of changes to just one crtc). >> Obviously the current possible_encoders/possible_crtcs would still be >> checked. >> - like above, but add a driver-global ->check callback before starting >> the modeset sequence, but with the new configuration already applied >> to the kms structures. >> - an alternative would be a new ->global_adjust_modes after the >> ->adjust_mode stage that gets all the new adjusted_modes and could >> check global resource constrains. >> >> Imo anything more complicated than that has dubious value in a common >> framework. I also dunno yet how (or if at all) we should bake in >> handling of planes restrictions ... >> >> For panel framework integration I don't think we need much, this is >> likely just a driver internal thing. > > well.. I guess it where the panel driver fits in KMS. I think it > would be common that we need to send a command to the panel to turn > off / disable backlight / etc. Versus an hdmi/dp/etc monitor which > would just do this automatically when it stops receiving a signal. So > it doesn't seem like a bad idea to not assume that your connector is > completely passive. But I could buy the argument that this should be > part of crtc helpers v2. Thinking about modern hw, I'd probably only expose connectors and monitors (or maybe call them displays). You could hang backlight controls and brightness, etc on the monitor objects. Also you could have a multiple monitors connected to a single connector (DP 1.2 or virtual adapters (wireless or remote display for example)). Everything else (crtcs, plls, encoders, etc.) would be driver controlled and validated. Alex
[PATCH 0/3] [RFC] DRM Render Nodes
Here's the patch to implement render nodes as discussed in the "DRM2" talk at XDC: http://wiki.x.org/wiki/Events/XDC2012/Proceedings#DRM2 The core problem is that DRM security is compromised in the face of VT switching and multiple DRM masters. Any local user can access all shared buffers from within any X server on the system, even when that user doesn't have access to any of those X servers. The fix for this is to use dmabuf/prime and fd passing for buffer sharing. That infrastructure is already in place and we need to start using that in user space. Once we're passing buffers between display servers and clients in a point-to-point fashion, we no longer need to authenticate clients. We just need to make sure they can only render and import/export buffers to fds. That's what this patch does, by creating a new type of drm device node. Accessing this node doesn't require authentication (and as such can be used without a master, ie headless), but will only expose the safe, modern (DRI2ish) rendering ioctls. Once userspace is sharing buffers through fd passing, the legacy card0 node can be locked down by unix permissions, for example in a drm-master group, so that only setgid binaries (X, weston, other KMS apps) can access it. Kristian See also: http://wiki.x.org/wiki/Events/XDC2012/Proceedings#Graphics_stack_security https://lwn.net/Articles/517375/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 14/14] drm: exynos: hdmi: remove drm common hdmi platform data struct
exynos-drm-hdmi need context pointers from hdmi and mixer. These
pointers were expected from the plf data. Cleaned this dependency
by exporting i/f which are called by hdmi, mixer driver probes
for setting their context.
Signed-off-by: Rahul Sharma
---
drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 51 +++--
drivers/gpu/drm/exynos/exynos_drm_hdmi.h |2 +
drivers/gpu/drm/exynos/exynos_hdmi.c |3 ++
drivers/gpu/drm/exynos/exynos_mixer.c|3 ++
include/drm/exynos_drm.h | 14
5 files changed, 34 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
index 0584132..85304c4 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
@@ -29,6 +29,11 @@
#define get_ctx_from_subdrv(subdrv)container_of(subdrv,\
struct drm_hdmi_context, subdrv);
+/* Common hdmi subdrv needs to access the hdmi and mixer though context.
+* These should be initialied by the repective drivers */
+static struct exynos_drm_hdmi_context *hdmi_ctx;
+static struct exynos_drm_hdmi_context *mixer_ctx;
+
/* these callback points shoud be set by specific drivers. */
static struct exynos_hdmi_ops *hdmi_ops;
static struct exynos_mixer_ops *mixer_ops;
@@ -41,6 +46,18 @@ struct drm_hdmi_context {
boolenabled[MIXER_WIN_NR];
};
+void exynos_hdmi_drv_attach(struct exynos_drm_hdmi_context *ctx)
+{
+ if (ctx)
+ hdmi_ctx = ctx;
+}
+
+void exynos_mixer_drv_attach(struct exynos_drm_hdmi_context *ctx)
+{
+ if (ctx)
+ mixer_ctx = ctx;
+}
+
void exynos_hdmi_ops_register(struct exynos_hdmi_ops *ops)
{
DRM_DEBUG_KMS("%s\n", __FILE__);
@@ -303,46 +320,30 @@ static int hdmi_subdrv_probe(struct drm_device *drm_dev,
{
struct exynos_drm_subdrv *subdrv = to_subdrv(dev);
struct drm_hdmi_context *ctx;
- struct platform_device *pdev = to_platform_device(dev);
- struct exynos_drm_common_hdmi_pd *pd;
DRM_DEBUG_KMS("%s\n", __FILE__);
- pd = pdev->dev.platform_data;
-
- if (!pd) {
- DRM_DEBUG_KMS("platform data is null.\n");
+ if (!hdmi_ctx) {
+ DRM_ERROR("hdmi context not initialized.\n");
return -EFAULT;
}
- if (!pd->hdmi_dev) {
- DRM_DEBUG_KMS("hdmi device is null.\n");
- return -EFAULT;
- }
-
- if (!pd->mixer_dev) {
- DRM_DEBUG_KMS("mixer device is null.\n");
+ if (!mixer_ctx) {
+ DRM_ERROR("mixer context not initialized.\n");
return -EFAULT;
}
ctx = get_ctx_from_subdrv(subdrv);
- ctx->hdmi_ctx = (struct exynos_drm_hdmi_context *)
- to_context(pd->hdmi_dev);
- if (!ctx->hdmi_ctx) {
- DRM_DEBUG_KMS("hdmi context is null.\n");
+ if (!ctx) {
+ DRM_ERROR("no drm hdmi context.\n");
return -EFAULT;
}
- ctx->hdmi_ctx->drm_dev = drm_dev;
-
- ctx->mixer_ctx = (struct exynos_drm_hdmi_context *)
- to_context(pd->mixer_dev);
- if (!ctx->mixer_ctx) {
- DRM_DEBUG_KMS("mixer context is null.\n");
- return -EFAULT;
- }
+ ctx->hdmi_ctx = hdmi_ctx;
+ ctx->mixer_ctx = mixer_ctx;
+ ctx->hdmi_ctx->drm_dev = drm_dev;
ctx->mixer_ctx->drm_dev = drm_dev;
return 0;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
index d9f9e9f..2da5ffd 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
@@ -73,6 +73,8 @@ struct exynos_mixer_ops {
void (*win_disable)(void *ctx, int zpos);
};
+void exynos_hdmi_drv_attach(struct exynos_drm_hdmi_context *ctx);
+void exynos_mixer_drv_attach(struct exynos_drm_hdmi_context *ctx);
void exynos_hdmi_ops_register(struct exynos_hdmi_ops *ops);
void exynos_mixer_ops_register(struct exynos_mixer_ops *ops);
#endif
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 5caf49f..e6b784d 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -2454,6 +2454,9 @@ static int __devinit hdmi_probe(struct platform_device
*pdev)
goto err_free_irq;
}
+ /* Attach HDMI Driver to common hdmi. */
+ exynos_hdmi_drv_attach(drm_hdmi_ctx);
+
/* register specific callbacks to common hdmi. */
exynos_hdmi_ops_register(&hdmi_ops);
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index d34562a..672e6f7 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -1163,6 +1163,9 @@ static int __devinit mixer_probe(struct platform_device
*pd
[PATCH 13/14] drm: exynos: hdmi: add support for exynos5 hdmi
This patch adds support for exynos5 hdmi with device tree enabled.
Signed-off-by: Rahul Sharma
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 83 --
1 files changed, 79 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 89e798b..5caf49f 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -32,6 +32,9 @@
#include
#include
#include
+#include
+#include
+#include
#include
@@ -2250,6 +2253,41 @@ void hdmi_attach_hdmiphy_client(struct i2c_client
*hdmiphy)
hdmi_hdmiphy = hdmiphy;
}
+#ifdef CONFIG_OF
+static struct s5p_hdmi_platform_data *drm_hdmi_dt_parse_pdata
+ (struct device *dev)
+{
+ struct device_node *np = dev->of_node;
+ struct s5p_hdmi_platform_data *pd;
+ enum of_gpio_flags flags;
+ u32 value;
+
+ pd = devm_kzalloc(dev, sizeof(*pd), GFP_KERNEL);
+ if (!pd) {
+ DRM_ERROR("memory allocation for pdata failed\n");
+ goto err_data;
+ }
+
+ if (!of_find_property(np, "hpd-gpio", &value)) {
+ DRM_ERROR("no hpd gpio property found\n");
+ goto err_data;
+ }
+
+ pd->hpd_gpio = of_get_named_gpio_flags(np, "hpd-gpio", 0, &flags);
+
+ return pd;
+
+err_data:
+ return NULL;
+}
+#else
+static struct s5p_hdmi_platform_data *drm_hdmi_dt_parse_pdata
+ (struct device *dev)
+{
+ return NULL;
+}
+#endif
+
static struct platform_device_id hdmi_driver_types[] = {
{
.name = "s5pv210-hdmi",
@@ -2259,7 +2297,19 @@ static struct platform_device_id hdmi_driver_types[] = {
.driver_data= HDMI_TYPE13,
}, {
.name = "exynos4-hdmi14",
- .driver_data= HDMI_TYPE14,
+ .driver_data= HDMI_TYPE14,
+ }, {
+ .name = "exynos5-hdmi",
+ .driver_data= HDMI_TYPE14,
+ }, {
+ /* end node */
+ }
+};
+
+static struct of_device_id hdmi_match_types[] = {
+ {
+ .compatible = "samsung,exynos5-hdmi",
+ .data = (void *)HDMI_TYPE14,
}, {
/* end node */
}
@@ -2276,7 +2326,16 @@ static int __devinit hdmi_probe(struct platform_device
*pdev)
DRM_DEBUG_KMS("[%d]\n", __LINE__);
- pdata = pdev->dev.platform_data;
+ if (pdev->dev.of_node) {
+ pdata = drm_hdmi_dt_parse_pdata(dev);
+ if (IS_ERR(pdata)) {
+ DRM_ERROR("failed to parse dt\n");
+ return PTR_ERR(pdata);
+ }
+ } else {
+ pdata = pdev->dev.platform_data;
+ }
+
if (!pdata) {
DRM_ERROR("no platform data specified\n");
return -EINVAL;
@@ -2303,18 +2362,33 @@ static int __devinit hdmi_probe(struct platform_device
*pdev)
platform_set_drvdata(pdev, drm_hdmi_ctx);
- hdata->type = (enum hdmi_type)platform_get_device_id
+ if (dev->of_node) {
+ const struct of_device_id *match;
+ match = of_match_node(of_match_ptr(hdmi_match_types),
+ pdev->dev.of_node);
+ hdata->type = (enum hdmi_type)match->data;
+ } else {
+ hdata->type = (enum hdmi_type)platform_get_device_id
(pdev)->driver_data;
+ }
+
hdata->hpd_gpio = pdata->hpd_gpio;
hdata->dev = dev;
ret = hdmi_resources_init(hdata);
+
if (ret) {
ret = -EINVAL;
+ DRM_ERROR("hdmi_resources_init failed\n");
goto err_data;
}
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res) {
+ DRM_ERROR("failed to find registers\n");
+ ret = -ENOENT;
+ goto err_resource;
+ }
hdata->regs = devm_request_and_ioremap(&pdev->dev, res);
if (!hdata->regs) {
@@ -2462,8 +2536,9 @@ struct platform_driver hdmi_driver = {
.remove = __devexit_p(hdmi_remove),
.id_table = hdmi_driver_types,
.driver = {
- .name = "exynos4-hdmi",
+ .name = "exynos-hdmi",
.owner = THIS_MODULE,
.pm = &hdmi_pm_ops,
+ .of_match_table = hdmi_match_types,
},
};
--
1.7.0.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] dma-buf: might_sleep() in dma_buf_unmap_attachment()
From: Rob Clark
We never really clarified if unmap could be done in atomic context.
But since mapping might require sleeping, this implies mutex in use
to synchronize mapping/unmapping, so unmap could sleep as well. Add
a might_sleep() to clarify this.
Signed-off-by: Rob Clark
Acked-by: Daniel Vetter
---
drivers/base/dma-buf.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index c30f3e1..877eacb 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -298,6 +298,8 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment
*attach,
struct sg_table *sg_table,
enum dma_data_direction direction)
{
+ might_sleep();
+
if (WARN_ON(!attach || !attach->dmabuf || !sg_table))
return;
--
1.7.9.5
[PATCH 12/14] drm: exynos: hdmi: replace is_v13 with version check in hdmi
This patch removed the is_v13 variable from the hdmi driver context.
It is replaced with condition check for the hdmi version. This cleans
the way for handling further hdmi versions.
Signed-off-by: Rahul Sharma
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 40 +-
1 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index e3ab840..89e798b 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -47,6 +47,11 @@
#define MAX_HEIGHT 1080
#define get_hdmi_context(dev) platform_get_drvdata(to_platform_device(dev))
+enum hdmi_type {
+ HDMI_TYPE13,
+ HDMI_TYPE14,
+};
+
struct hdmi_resources {
struct clk *hdmi;
struct clk *sclk_hdmi;
@@ -62,7 +67,6 @@ struct hdmi_context {
struct drm_device *drm_dev;
boolhpd;
boolpowered;
- boolis_v13;
booldvi_mode;
struct mutexhdmi_mutex;
@@ -80,6 +84,8 @@ struct hdmi_context {
void*parent_ctx;
int hpd_gpio;
+
+ enum hdmi_type type;
};
/* HDMI Version 1.3 */
@@ -1211,7 +1217,7 @@ static void hdmi_v14_regs_dump(struct hdmi_context
*hdata, char *prefix)
static void hdmi_regs_dump(struct hdmi_context *hdata, char *prefix)
{
- if (hdata->is_v13)
+ if (hdata->type == HDMI_TYPE13)
hdmi_v13_regs_dump(hdata, prefix);
else
hdmi_v14_regs_dump(hdata, prefix);
@@ -1252,7 +1258,7 @@ static int hdmi_v14_conf_index(struct drm_display_mode
*mode)
static int hdmi_conf_index(struct hdmi_context *hdata,
struct drm_display_mode *mode)
{
- if (hdata->is_v13)
+ if (hdata->type == HDMI_TYPE13)
return hdmi_v13_conf_index(mode);
return hdmi_v14_conf_index(mode);
@@ -1348,7 +1354,7 @@ static int hdmi_check_timing(void *ctx, void *timing)
check_timing->yres, check_timing->refresh,
check_timing->vmode);
- if (hdata->is_v13)
+ if (hdata->type == HDMI_TYPE13)
return hdmi_v13_check_timing(check_timing);
else
return hdmi_v14_check_timing(check_timing);
@@ -1414,7 +1420,7 @@ static void hdmi_reg_acr(struct hdmi_context *hdata, u8
*acr)
hdmi_reg_writeb(hdata, HDMI_ACR_CTS1, acr[2]);
hdmi_reg_writeb(hdata, HDMI_ACR_CTS2, acr[1]);
- if (hdata->is_v13)
+ if (hdata->type == HDMI_TYPE13)
hdmi_reg_writeb(hdata, HDMI_V13_ACR_CON, 4);
else
hdmi_reg_writeb(hdata, HDMI_ACR_CON, 4);
@@ -1518,7 +1524,7 @@ static void hdmi_conf_reset(struct hdmi_context *hdata)
{
u32 reg;
- if (hdata->is_v13)
+ if (hdata->type == HDMI_TYPE13)
reg = HDMI_V13_CORE_RSTOUT;
else
reg = HDMI_CORE_RSTOUT;
@@ -1550,7 +1556,7 @@ static void hdmi_conf_init(struct hdmi_context *hdata)
HDMI_VID_PREAMBLE_DIS | HDMI_GUARD_BAND_DIS);
}
- if (hdata->is_v13) {
+ if (hdata->type == HDMI_TYPE13) {
/* choose bluescreen (fecal) color */
hdmi_reg_writeb(hdata, HDMI_V13_BLUE_SCREEN_0, 0x12);
hdmi_reg_writeb(hdata, HDMI_V13_BLUE_SCREEN_1, 0x34);
@@ -1832,7 +1838,7 @@ static void hdmi_v14_timing_apply(struct hdmi_context
*hdata)
static void hdmi_timing_apply(struct hdmi_context *hdata)
{
- if (hdata->is_v13)
+ if (hdata->type == HDMI_TYPE13)
hdmi_v13_timing_apply(hdata);
else
hdmi_v14_timing_apply(hdata);
@@ -1854,7 +1860,7 @@ static void hdmiphy_conf_reset(struct hdmi_context *hdata)
if (hdata->hdmiphy_port)
i2c_master_send(hdata->hdmiphy_port, buffer, 2);
- if (hdata->is_v13)
+ if (hdata->type == HDMI_TYPE13)
reg = HDMI_V13_PHY_RSTOUT;
else
reg = HDMI_PHY_RSTOUT;
@@ -1881,7 +1887,7 @@ static void hdmiphy_conf_apply(struct hdmi_context *hdata)
}
/* pixel clock */
- if (hdata->is_v13)
+ if (hdata->type == HDMI_TYPE13)
hdmiphy_data = hdmi_v13_confs[hdata->cur_conf].hdmiphy_data;
else
hdmiphy_data = hdmi_confs[hdata->cur_conf].hdmiphy_data;
@@ -1949,7 +1955,7 @@ static void hdmi_mode_fixup(void *ctx, struct
drm_connector *connector,
drm_mode_set_crtcinfo(adjusted_mode, 0);
- if (hdata->is_v13)
+ if (hdata->type == HDMI_TYPE13)
index = hdmi_v13_conf_index(adjusted_mode);
else
index = hdmi_v14_conf_index(adjusted_mode);
[PATCH 11/14] drm: exynos: hdmi: add support for exynos5 mixer
This patch adds support for exynos5 mixer with device tree enabled.
Signed-off-by: Rahul Sharma
Signed-off-by: Fahad Kunnathadi
---
drivers/gpu/drm/exynos/exynos_mixer.c | 41 ++--
drivers/gpu/drm/exynos/regs-mixer.h |2 +
2 files changed, 40 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index ff2a45d..d34562a 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -645,6 +645,10 @@ static void mixer_win_reset(struct mixer_context *ctx)
if (ctx->vp_enabled)
mixer_reg_writemask(res, MXR_CFG, 0, MXR_CFG_VP_ENABLE);
+ /* enable vsync interrupt after mixer reset*/
+ mixer_reg_writemask(res, MXR_INT_EN, MXR_INT_EN_VSYNC,
+ MXR_INT_EN_VSYNC);
+
mixer_vsync_set_update(ctx, true);
spin_unlock_irqrestore(&res->reg_slock, flags);
}
@@ -913,6 +917,11 @@ static irqreturn_t mixer_irq_handler(int irq, void *arg)
/* handling VSYNC */
if (val & MXR_INT_STATUS_VSYNC) {
+ if (ctx->mxr_ver == MXR_VER_16_0_33_0) {
+ /* layer update mandatory for mixer 16.0.33.0 */
+ mixer_reg_writemask(res, MXR_CFG, ~0,
+ MXR_CFG_LAYER_UPDATE);
+ }
/* interlace scan need to check shadow register */
if (ctx->interlace) {
base = mixer_reg_read(res, MXR_GRAPHIC_BASE(0));
@@ -1066,6 +1075,11 @@ fail:
return ret;
}
+static struct mixer_drv_data exynos5_mxr_drv_data = {
+ .version = MXR_VER_16_0_33_0,
+ .is_vp_enabled = 0,
+};
+
static struct mixer_drv_data exynos4_mxr_drv_data = {
.version = MXR_VER_0_0_0_16,
.is_vp_enabled = 1,
@@ -1075,6 +1089,18 @@ static struct platform_device_id mixer_driver_types[] = {
.name = "s5p-mixer",
.driver_data= (unsigned long)&exynos4_mxr_drv_data,
}, {
+ .name = "exynos5-mixer",
+ .driver_data= (unsigned long)&exynos5_mxr_drv_data,
+ }, {
+ /* end node */
+ }
+};
+
+static struct of_device_id mixer_match_types[] = {
+ {
+ .compatible = "samsung,exynos5-mixer",
+ .data = &exynos5_mxr_drv_data,
+ }, {
/* end node */
}
};
@@ -1104,8 +1130,16 @@ static int __devinit mixer_probe(struct platform_device
*pdev)
mutex_init(&ctx->mixer_mutex);
- drv = (struct mixer_drv_data *)platform_get_device_id(
- pdev)->driver_data;
+ if (dev->of_node) {
+ const struct of_device_id *match;
+ match = of_match_node(of_match_ptr(mixer_match_types),
+ pdev->dev.of_node);
+ drv = match->data;
+ } else {
+ drv = (struct mixer_drv_data *)
+ platform_get_device_id(pdev)->driver_data;
+ }
+
ctx->dev = &pdev->dev;
drm_hdmi_ctx->ctx = (void *)ctx;
ctx->vp_enabled = drv->is_vp_enabled;
@@ -1167,9 +1201,10 @@ static SIMPLE_DEV_PM_OPS(mixer_pm_ops, mixer_suspend,
NULL);
struct platform_driver mixer_driver = {
.driver = {
- .name = "s5p-mixer",
+ .name = "exynos-mixer",
.owner = THIS_MODULE,
.pm = &mixer_pm_ops,
+ .of_match_table = mixer_match_types,
},
.probe = mixer_probe,
.remove = __devexit_p(mixer_remove),
diff --git a/drivers/gpu/drm/exynos/regs-mixer.h
b/drivers/gpu/drm/exynos/regs-mixer.h
index fd2f4d1..6ee60be 100644
--- a/drivers/gpu/drm/exynos/regs-mixer.h
+++ b/drivers/gpu/drm/exynos/regs-mixer.h
@@ -69,6 +69,7 @@
(((val) << (low_bit)) & MXR_MASK(high_bit, low_bit))
/* bits for MXR_STATUS */
+#define MXR_STATUS_SOFT_RESET (1 << 8)
#define MXR_STATUS_16_BURST(1 << 7)
#define MXR_STATUS_BURST_MASK (1 << 7)
#define MXR_STATUS_BIG_ENDIAN (1 << 3)
@@ -77,6 +78,7 @@
#define MXR_STATUS_REG_RUN (1 << 0)
/* bits for MXR_CFG */
+#define MXR_CFG_LAYER_UPDATE (1 << 31)
#define MXR_CFG_RGB601_0_255 (0 << 9)
#define MXR_CFG_RGB601_16_235 (1 << 9)
#define MXR_CFG_RGB709_0_255 (2 << 9)
--
1.7.0.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
