date:20111219

Hello Everyone,

This is RFC v3 for DMA buffer sharing mechanism - changes from v2 are in the
changelog below.

Various subsystems - V4L2, GPU-accessors, DRI to name a few - have felt the 
need to have a common mechanism to share memory buffers across different
devices - ARM, video hardware, GPU.

This need comes forth from a variety of use cases including cameras, image 
processing, video recorders, sound processing, DMA engines, GPU and display
buffers, and others.

This RFC is an attempt to define such a buffer sharing mechanism- it is the
result of discussions from a couple of memory-management mini-summits held by
Linaro to understand and address common needs around memory management. [1]

A new dma_buf buffer object is added, with operations and API to allow easy
sharing of this buffer object across devices.

The framework allows:
- a new buffer-object to be created with fixed size.
- different devices to 'attach' themselves to this buffer, to facilitate
  backing storage negotiation, using dma_buf_attach() API.
- association of a file pointer with each user-buffer and associated
   allocator-defined operations on that buffer. This operation is called the
   'export' operation.
- this exported buffer-object to be shared with the other entity by asking for
   its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
   the associated exporter-defined operations.
- the exporter and user to share the scatterlist using map_dma_buf and
   unmap_dma_buf operations.

Documentation present in the patch-set gives more details.

This is based on design suggestions from many people at the mini-summits,
most notably from Arnd Bergmann a...@arndb.de, Rob Clark r...@ti.com and
Daniel Vetter dan...@ffwll.ch.

The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski t.stanisl...@samsung.com, who demonstrated buffer sharing
between two v4l2 devices. [2]

References:
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389

Patchset based on top of 3.2-rc3, the current version can be found at

http://git.linaro.org/gitweb?p=people/sumitsemwal/linux-3.x.git
Branch: dma-buf-upstr-v2

Earlier versions:
v2 at: https://lkml.org/lkml/2011/12/2/53
v1 at: https://lkml.org/lkml/2011/10/11/92

Best regards,
~Sumit Semwal

History:

v3:
- Review comments incorporated:
   - from Konrad Rzeszutek Wilk [https://lkml.org/lkml/2011/12/3/45]
 - replaced BUG_ON with WARN_ON - various places
 - added some error-checks
 - replaced EXPORT_SYMBOL with EXPORT_SYMBOL_GPL
 - some cosmetic / documentation comments

   - from Arnd Bergmann, Daniel Vetter, Rob Clark
  [https://lkml.org/lkml/2011/12/5/321]
 - removed mmap() fop and dma_buf_op, also the sg_sync* operations, and
documented that mmap is not allowed for exported buffer
 - updated documentation to clearly state when migration is allowed
 - changed kconfig
 - some error code checks

   - from Rob Clark [https://lkml.org/lkml/2011/12/5/572]
 - update documentation to allow map_dma_buf to return -EINTR

v2:
- Review comments incorporated:
   - from Tomasz Stanislawski [https://lkml.org/lkml/2011/10/14/136]
 - kzalloc moved out of critical section
 - corrected some in-code comments

   - from Dave Airlie [https://lkml.org/lkml/2011/11/25/123]

   - from Daniel Vetter and Rob Clark [https://lkml.org/lkml/2011/11/26/53]
 - use struct sg_table in place of struct scatterlist
 - rename {get,put}_scatterlist to {map,unmap}_dma_buf
 - add new wrapper APIs dma_buf_{map,unmap}_attachment for ease of users
 
- documentation updates as per review comments from Randy Dunlap
 [https://lkml.org/lkml/2011/10/12/439]

v1: original


Sumit Semwal (2):
  dma-buf: Introduce dma buffer sharing mechanism
  dma-buf: Documentation for buffer sharing framework

 Documentation/dma-buf-sharing.txt |  222 
 drivers/base/Kconfig  |   10 ++
 drivers/base/Makefile |1 +
 drivers/base/dma-buf.c|  289 +
 include/linux/dma-buf.h   |  172 ++
 5 files changed, 694 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/dma-buf-sharing.txt
 create mode 100644 drivers/base/dma-buf.c
 create mode 100644 include/linux/dma-buf.h

-- 
1.7.4.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC v3 0/2] Introduce DMA buffer sharing mechanism

Hello Everyone,

This is RFC v3 for DMA buffer sharing mechanism - changes from v2 are in the
changelog below.

Various subsystems - V4L2, GPU-accessors, DRI to name a few - have felt the 
need to have a common mechanism to share memory buffers across different
devices - ARM, video hardware, GPU.

This need comes forth from a variety of use cases including cameras, image 
processing, video recorders, sound processing, DMA engines, GPU and display
buffers, and others.

This RFC is an attempt to define such a buffer sharing mechanism- it is the
result of discussions from a couple of memory-management mini-summits held by
Linaro to understand and address common needs around memory management. [1]

A new dma_buf buffer object is added, with operations and API to allow easy
sharing of this buffer object across devices.

The framework allows:
- a new buffer-object to be created with fixed size.
- different devices to 'attach' themselves to this buffer, to facilitate
  backing storage negotiation, using dma_buf_attach() API.
- association of a file pointer with each user-buffer and associated
   allocator-defined operations on that buffer. This operation is called the
   'export' operation.
- this exported buffer-object to be shared with the other entity by asking for
   its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
   the associated exporter-defined operations.
- the exporter and user to share the scatterlist using map_dma_buf and
   unmap_dma_buf operations.

Documentation present in the patch-set gives more details.

This is based on design suggestions from many people at the mini-summits,
most notably from Arnd Bergmann a...@arndb.de, Rob Clark r...@ti.com and
Daniel Vetter dan...@ffwll.ch.

The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski t.stanisl...@samsung.com, who demonstrated buffer sharing
between two v4l2 devices. [2]

Some sample implementations and WIP for dma-buf as user and exporter are
available at [3] and [4]. [These are not being submitted for discussion /
inclusion right now, but are for reference only]

References:
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
[3]: Dave Airlie's:
   http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-prime-dmabuf
[4]: Rob Clark's:
   https://github.com/robclark/kernel-omap4/commits/dmabuf

Patchset based on top of 3.2-rc3, the current version can be found at

http://git.linaro.org/gitweb?p=people/sumitsemwal/linux-3.x.git
Branch: dma-buf-upstr-v3

Earlier versions:
v2 at: https://lkml.org/lkml/2011/12/2/53
v1 at: https://lkml.org/lkml/2011/10/11/92

Best regards,
~Sumit Semwal

History:

v3:
- Review comments incorporated:
   - from Konrad Rzeszutek Wilk [https://lkml.org/lkml/2011/12/3/45]
 - replaced BUG_ON with WARN_ON - various places
 - added some error-checks
 - replaced EXPORT_SYMBOL with EXPORT_SYMBOL_GPL
 - some cosmetic / documentation comments

   - from Arnd Bergmann, Daniel Vetter, Rob Clark
  [https://lkml.org/lkml/2011/12/5/321]
 - removed mmap() fop and dma_buf_op, also the sg_sync* operations, and
documented that mmap is not allowed for exported buffer
 - updated documentation to clearly state when migration is allowed
 - changed kconfig
 - some error code checks

   - from Rob Clark [https://lkml.org/lkml/2011/12/5/572]
 - update documentation to allow map_dma_buf to return -EINTR

v2:
- Review comments incorporated:
   - from Tomasz Stanislawski [https://lkml.org/lkml/2011/10/14/136]
 - kzalloc moved out of critical section
 - corrected some in-code comments

   - from Dave Airlie [https://lkml.org/lkml/2011/11/25/123]

   - from Daniel Vetter and Rob Clark [https://lkml.org/lkml/2011/11/26/53]
 - use struct sg_table in place of struct scatterlist
 - rename {get,put}_scatterlist to {map,unmap}_dma_buf
 - add new wrapper APIs dma_buf_{map,unmap}_attachment for ease of users
 
- documentation updates as per review comments from Randy Dunlap
 [https://lkml.org/lkml/2011/10/12/439]

v1: original

Sumit Semwal (2):
  dma-buf: Introduce dma buffer sharing mechanism
  dma-buf: Documentation for buffer sharing framework

 Documentation/dma-buf-sharing.txt |  222 
 drivers/base/Kconfig  |   10 ++
 drivers/base/Makefile |1 +
 drivers/base/dma-buf.c|  289 +
 include/linux/dma-buf.h   |  172 ++
 5 files changed, 694 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/dma-buf-sharing.txt
 create mode 100644 drivers/base/dma-buf.c
 create mode 100644 include/linux/dma-buf.h

-- 
1.7.4.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC v3 1/2] dma-buf: Introduce dma buffer sharing mechanism

This is the first step in defining a dma buffer sharing mechanism.

A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.

The framework allows:
- different devices to 'attach' themselves to this buffer, to facilitate
  backing storage negotiation, using dma_buf_attach() API.
- association of a file pointer with each user-buffer and associated
   allocator-defined operations on that buffer. This operation is called the
   'export' operation.
- this exported buffer-object to be shared with the other entity by asking for
   its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
   the associated exporter-defined operations.
- the exporter and user to share the scatterlist using map_dma_buf and
   unmap_dma_buf operations.

Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.

Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.

More details are there in the documentation patch.

This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann a...@arndb.de, Rob Clark r...@ti.com and
Daniel Vetter dan...@ffwll.ch.

The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski t.stanisl...@samsung.com, who demonstrated buffer sharing
between two v4l2 devices. [2]

[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389

Signed-off-by: Sumit Semwal sumit.sem...@linaro.org
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
---
 drivers/base/Kconfig|   10 ++
 drivers/base/Makefile   |1 +
 drivers/base/dma-buf.c  |  289 +++
 include/linux/dma-buf.h |  172 
 4 files changed, 472 insertions(+), 0 deletions(-)
 create mode 100644 drivers/base/dma-buf.c
 create mode 100644 include/linux/dma-buf.h

diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 21cf46f..8a0e87f 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -174,4 +174,14 @@ config SYS_HYPERVISOR
 
 source drivers/base/regmap/Kconfig
 
+config DMA_SHARED_BUFFER
+   bool Buffer framework to be shared between drivers
+   default n
+   select ANON_INODES
+   help
+ This option enables the framework for buffer-sharing between
+ multiple drivers. A buffer is associated with a file using driver
+ APIs extension; the file's descriptor can then be passed on to other
+ driver.
+
 endmenu
diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index 99a375a..d0df046 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_DEVTMPFS)  += devtmpfs.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
 obj-$(CONFIG_ISA)  += isa.o
 obj-$(CONFIG_FW_LOADER)+= firmware_class.o
 obj-$(CONFIG_NUMA) += node.o
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
new file mode 100644
index 000..e920709
--- /dev/null
+++ b/drivers/base/dma-buf.c
@@ -0,0 +1,289 @@
+/*
+ * Framework for buffer objects that can be shared across devices/subsystems.
+ *
+ * Copyright(C) 2011 Linaro Limited. All rights reserved.
+ * Author: Sumit Semwal sumit.sem...@ti.com
+ *
+ * Many thanks to linaro-mm-sig list, and specially
+ * Arnd Bergmann a...@arndb.de, Rob Clark r...@ti.com and
+ * Daniel Vetter dan...@ffwll.ch for their support in creation and
+ * refining of this idea.
+ *
+ * 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 http://www.gnu.org/licenses/.
+ */
+
+#include linux/fs.h
+#include linux/slab.h
+#include linux/dma-buf.h
+#include linux/anon_inodes.h
+#include linux/export.h
+
+static inline int is_dma_buf_file(struct file *);
+
+static int dma_buf_release(struct inode *inode, struct file *file)
+{
+   struct dma_buf *dmabuf;
+
+   if (!is_dma_buf_file(file))
+   return -EINVAL;
+
+   dmabuf = file-private_data;
+
+   dmabuf-ops-release(dmabuf);
+   kfree(dmabuf);
+   return 0;
+}
+
+static const struct file_operations dma_buf_fops = {
+   .release= dma_buf_release,
+};
+
+/*
+ * is_dma_buf_file - Check if struct

[RFC v3 2/2] dma-buf: Documentation for buffer sharing framework

Add documentation for dma buffer sharing framework, explaining the
various operations, members and API of the dma buffer sharing
framework.

Signed-off-by: Sumit Semwal sumit.sem...@linaro.org
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
---
 Documentation/dma-buf-sharing.txt |  222 +
 1 files changed, 222 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/dma-buf-sharing.txt

diff --git a/Documentation/dma-buf-sharing.txt 
b/Documentation/dma-buf-sharing.txt
new file mode 100644
index 000..3a2a35f
--- /dev/null
+++ b/Documentation/dma-buf-sharing.txt
@@ -0,0 +1,222 @@
+DMA Buffer Sharing API Guide
+
+
+Sumit Semwal
+sumit dot semwal at linaro dot org
+ sumit dot semwal at ti dot com
+
+This document serves as a guide to device-driver writers on what is the dma-buf
+buffer sharing API, how to use it for exporting and using shared buffers.
+
+Any device driver which wishes to be a part of DMA buffer sharing, can do so as
+either the 'exporter' of buffers, or the 'user' of buffers.
+
+Say a driver A wants to use buffers created by driver B, then we call B as the
+exporter, and A as buffer-user.
+
+The exporter
+- implements and manages operations[1] for the buffer
+- allows other users to share the buffer by using dma_buf sharing APIs,
+- manages the details of buffer allocation,
+- decides about the actual backing storage where this allocation happens,
+- takes care of any migration of scatterlist - for all (shared) users of this
+   buffer,
+
+The buffer-user
+- is one of (many) sharing users of the buffer.
+- doesn't need to worry about how the buffer is allocated, or where.
+- needs a mechanism to get access to the scatterlist that makes up this buffer
+   in memory, mapped into its own address space, so it can access the same area
+   of memory.
+
+*IMPORTANT*: A buffer shared using the dma_buf sharing API *must not* be
+exported to user space using mmap. [see https://lkml.org/lkml/2011/12/2/53
+for more on the discussion]
+
+The dma_buf buffer sharing API usage contains the following steps:
+
+1. Exporter announces that it wishes to export a buffer
+2. Userspace gets the file descriptor associated with the exported buffer, and
+   passes it around to potential buffer-users based on use case
+3. Each buffer-user 'connects' itself to the buffer
+4. When needed, buffer-user requests access to the buffer from exporter
+5. When finished with its use, the buffer-user notifies end-of-DMA to exporter
+6. when buffer-user is done using this buffer completely, it 'disconnects'
+   itself from the buffer.
+
+
+1. Exporter's announcement of buffer export
+
+   The buffer exporter announces its wish to export a buffer. In this, it
+   connects its own private buffer data, provides implementation for operations
+   that can be performed on the exported dma_buf, and flags for the file
+   associated with this buffer.
+
+   Interface:
+  struct dma_buf *dma_buf_export(void *priv, struct dma_buf_ops *ops,
+int flags)
+
+   If this succeeds, dma_buf_export allocates a dma_buf structure, and returns 
a
+   pointer to the same. It also associates an anonymous file with this buffer,
+   so it can be exported. On failure to allocate the dma_buf object, it returns
+   NULL.
+
+2. Userspace gets a handle to pass around to potential buffer-users
+
+   Userspace entity requests for a file-descriptor (fd) which is a handle to 
the
+   anonymous file associated with the buffer. It can then share the fd with 
other
+   drivers and/or processes.
+
+   Interface:
+  int dma_buf_fd(struct dma_buf *dmabuf)
+
+   This API installs an fd for the anonymous file associated with this buffer;
+   returns either 'fd', or error.
+
+3. Each buffer-user 'connects' itself to the buffer
+
+   Each buffer-user now gets a reference to the buffer, using the fd passed to
+   it.
+
+   Interface:
+  struct dma_buf *dma_buf_get(int fd)
+
+   This API will return a reference to the dma_buf, and increment refcount for
+   it.
+
+   After this, the buffer-user needs to attach its device with the buffer, 
which
+   helps the exporter to know of device buffer constraints.
+
+   Interface:
+  struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
+struct device *dev)
+
+   This API returns reference to an attachment structure, which is then used
+   for scatterlist operations. It will optionally call the 'attach' dma_buf
+   operation, if provided by the exporter.
+
+   The dma-buf sharing framework does the bookkeeping bits related to managing
+   the list of all attachments to a buffer.
+
+Until this stage, the buffer-exporter has the option to choose not to actually
+allocate the backing storage for this buffer, but wait for the first 
buffer-user
+to request use of

allow drivers to fix kexec bus mastering hole

kexec relies on disabling bus mastering on PCI devices to block wayward DMAs
left set by the previous kernel. However the drm midlayer was enabling bus
mastering for all PCI drivers before calling into them. This meant no matter
what they did, there was always going to be a small race window. The
first patch pushes the enable into the drivers, and the second radeon patch
moves bus mastering enable to later in the driver load procedure for the kms
driver. These two along with Jerome's sanity patch should close the race 
completely.

please check the first one to make sure I didn't miss any drivers.

Dave.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm: move pci bus master enable into driver.

From: Dave Airlie airl...@redhat.com

The current enabling of bus mastering in the drm midlayer allows a large
race condition under kexec. When a kexec'ed kernel re-enables bus mastering
for the GPU, previously setup dma blocks may cause writes to random pieces
of memory. On radeon the writeback mechanism can cause these sorts of issues.

This patch doesn't fix the problem, but it moves the bus master enable under
the individual drivers control so they can move enabling it until later in
their load cycle and close the race.

Fix for radeon kms driver will be in a follow-up patch.

Signed-off-by: Dave Airlie airl...@redhat.com
---
 drivers/gpu/drm/drm_pci.c   |2 --
 drivers/gpu/drm/gma500/psb_drv.c|2 ++
 drivers/gpu/drm/i810/i810_dma.c |2 ++
 drivers/gpu/drm/i915/i915_dma.c |2 ++
 drivers/gpu/drm/mga/mga_dma.c   |2 ++
 drivers/gpu/drm/nouveau/nouveau_state.c |2 ++
 drivers/gpu/drm/r128/r128_drv.c |1 +
 drivers/gpu/drm/radeon/radeon_cp.c  |2 ++
 drivers/gpu/drm/radeon/radeon_kms.c |2 ++
 drivers/gpu/drm/sis/sis_drv.c   |2 ++
 drivers/gpu/drm/via/via_map.c   |2 ++
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |2 ++
 12 files changed, 21 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index d4d10b7..13f3d93 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -324,8 +324,6 @@ int drm_get_pci_dev(struct pci_dev *pdev, const struct 
pci_device_id *ent,
if (ret)
goto err_g1;
 
-   pci_set_master(pdev);
-
dev-pdev = pdev;
dev-dev = pdev-dev;
 
diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu/drm/gma500/psb_drv.c
index add3156..ff30b71 100644
--- a/drivers/gpu/drm/gma500/psb_drv.c
+++ b/drivers/gpu/drm/gma500/psb_drv.c
@@ -286,6 +286,8 @@ static int psb_driver_load(struct drm_device *dev, unsigned 
long chipset)
dev_priv-dev = dev;
dev-dev_private = (void *) dev_priv;
 
+   pci_set_master(dev-pdev);
+
if (!IS_PSB(dev)) {
if (pci_enable_msi(dev-pdev))
dev_warn(dev-dev, Enabling MSI failed!\n);
diff --git a/drivers/gpu/drm/i810/i810_dma.c b/drivers/gpu/drm/i810/i810_dma.c
index 8f371e8..56989a3 100644
--- a/drivers/gpu/drm/i810/i810_dma.c
+++ b/drivers/gpu/drm/i810/i810_dma.c
@@ -1210,6 +1210,8 @@ int i810_driver_load(struct drm_device *dev, unsigned 
long flags)
dev-types[8] = _DRM_STAT_SECONDARY;
dev-types[9] = _DRM_STAT_DMA;
 
+   pci_set_master(dev-pdev);
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index a9533c5..da07a8c 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1917,6 +1917,8 @@ int i915_driver_load(struct drm_device *dev, unsigned 
long flags)
goto free_priv;
}
 
+   pci_set_master(dev-pdev);
+
/* overlay on gen2 is broken and can't address above 1G */
if (IS_GEN2(dev))
dma_set_coherent_mask(dev-pdev-dev, DMA_BIT_MASK(30));
diff --git a/drivers/gpu/drm/mga/mga_dma.c b/drivers/gpu/drm/mga/mga_dma.c
index 5ccb65de..507aa3d 100644
--- a/drivers/gpu/drm/mga/mga_dma.c
+++ b/drivers/gpu/drm/mga/mga_dma.c
@@ -403,6 +403,8 @@ int mga_driver_load(struct drm_device *dev, unsigned long 
flags)
dev_priv-usec_timeout = MGA_DEFAULT_USEC_TIMEOUT;
dev_priv-chipset = flags;
 
+   pci_set_master(dev-pdev);
+
dev_priv-mmio_base = pci_resource_start(dev-pdev, 1);
dev_priv-mmio_size = pci_resource_len(dev-pdev, 1);
 
diff --git a/drivers/gpu/drm/nouveau/nouveau_state.c 
b/drivers/gpu/drm/nouveau/nouveau_state.c
index 82478e0..37f7bba 100644
--- a/drivers/gpu/drm/nouveau/nouveau_state.c
+++ b/drivers/gpu/drm/nouveau/nouveau_state.c
@@ -1000,6 +1000,8 @@ int nouveau_load(struct drm_device *dev, unsigned long 
flags)
dev-dev_private = dev_priv;
dev_priv-dev = dev;
 
+   pci_set_master(dev-pdev);
+
dev_priv-flags = flags  NOUVEAU_FLAGS;
 
NV_DEBUG(dev, vendor: 0x%X device: 0x%X class: 0x%X\n,
diff --git a/drivers/gpu/drm/r128/r128_drv.c b/drivers/gpu/drm/r128/r128_drv.c
index 6a5f439..88718fa 100644
--- a/drivers/gpu/drm/r128/r128_drv.c
+++ b/drivers/gpu/drm/r128/r128_drv.c
@@ -85,6 +85,7 @@ static struct drm_driver driver = {
 
 int r128_driver_load(struct drm_device *dev, unsigned long flags)
 {
+   pci_set_master(dev-pdev);
return drm_vblank_init(dev, 1);
 }
 
diff --git a/drivers/gpu/drm/radeon/radeon_cp.c 
b/drivers/gpu/drm/radeon/radeon_cp.c
index 72ae826..0ebb7d4 100644
--- a/drivers/gpu/drm/radeon/radeon_cp.c
+++ b/drivers/gpu/drm/radeon/radeon_cp.c
@@ -2115,6 +2115,8 @@ int radeon_driver_load(struct drm_device *dev, unsigned 
long flags)
break;
}
 
+   pci_set_master(dev-pdev);
+
if (drm_pci_device_is_agp(dev))

[PATCH 2/2] drm/radeon/kms: move pci bus master enable further into driver.

From: Dave Airlie airl...@redhat.com

This doesn't completely close the kexec hole for all drivers, but it fixes
it for some cases, by enabling PCI bus mastering later.

Signed-off-by: Dave Airlie airl...@redhat.com
---
 drivers/gpu/drm/radeon/evergreen.c  |2 ++
 drivers/gpu/drm/radeon/ni.c |2 ++
 drivers/gpu/drm/radeon/r100.c   |   10 ++
 drivers/gpu/drm/radeon/r300.c   |5 +
 drivers/gpu/drm/radeon/r420.c   |4 ++--
 drivers/gpu/drm/radeon/r600.c   |2 ++
 drivers/gpu/drm/radeon/radeon_kms.c |2 --
 drivers/gpu/drm/radeon/rv770.c  |2 ++
 8 files changed, 21 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index 5d51035..bb01c04 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -3001,6 +3001,8 @@ static int evergreen_startup(struct radeon_device *rdev)
/* enable pcie gen2 link */
evergreen_pcie_gen2_enable(rdev);
 
+   pci_set_master(rdev-pdev);
+
if (ASIC_IS_DCE5(rdev)) {
if (!rdev-me_fw || !rdev-pfp_fw || !rdev-rlc_fw || 
!rdev-mc_fw) {
r = ni_init_microcode(rdev);
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 1d1047a..60b4b9b 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1343,6 +1343,8 @@ static int cayman_startup(struct radeon_device *rdev)
/* enable pcie gen2 link */
evergreen_pcie_gen2_enable(rdev);
 
+   pci_set_master(rdev-pdev);
+
if (!rdev-me_fw || !rdev-pfp_fw || !rdev-rlc_fw || !rdev-mc_fw) {
r = ni_init_microcode(rdev);
if (r) {
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index dcc5b3c..567924c 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -596,6 +596,16 @@ int r100_pci_gart_init(struct radeon_device *rdev)
 void r100_enable_bm(struct radeon_device *rdev)
 {
uint32_t tmp;
+
+   pci_set_master(rdev-pdev);
+
+   if (rdev-family == CHIP_R300 ||
+   rdev-family == CHIP_R350 ||
+   rdev-family == CHIP_RV350 ||
+   rdev-family == CHIP_R423 ||
+   rdev-family == CHIP_RV410)
+   return;
+
/* Enable bus mastering */
tmp = RREG32(RADEON_BUS_CNTL)  ~RADEON_BUS_MASTER_DIS;
WREG32(RADEON_BUS_CNTL, tmp);
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index 400b26d..b1c171f 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -1372,10 +1372,7 @@ static int r300_startup(struct radeon_device *rdev)
return r;
}
 
-   if (rdev-family == CHIP_R300 ||
-   rdev-family == CHIP_R350 ||
-   rdev-family == CHIP_RV350)
-   r100_enable_bm(rdev);
+   r100_enable_bm(rdev);
 
if (rdev-flags  RADEON_IS_PCI) {
r = r100_pci_gart_enable(rdev);
diff --git a/drivers/gpu/drm/radeon/r420.c b/drivers/gpu/drm/radeon/r420.c
index 417fab8..b9123d6 100644
--- a/drivers/gpu/drm/radeon/r420.c
+++ b/drivers/gpu/drm/radeon/r420.c
@@ -400,8 +400,8 @@ int r420_init(struct radeon_device *rdev)
if (r) {
return r;
}
-   if (rdev-family == CHIP_R420)
-   r100_enable_bm(rdev);
+
+   r100_enable_bm(rdev);
 
if (rdev-flags  RADEON_IS_PCIE) {
r = rv370_pcie_gart_init(rdev);
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 936d107..36c9b86 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -2468,6 +2468,8 @@ int r600_startup(struct radeon_device *rdev)
/* enable pcie gen2 link */
r600_pcie_gen2_enable(rdev);
 
+   pci_set_master(rdev-pdev);
+
if (!rdev-me_fw || !rdev-pfp_fw || !rdev-rlc_fw) {
r = r600_init_microcode(rdev);
if (r) {
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
b/drivers/gpu/drm/radeon/radeon_kms.c
index 601b6bd..be2c122 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -57,8 +57,6 @@ int radeon_driver_load_kms(struct drm_device *dev, unsigned 
long flags)
}
dev-dev_private = (void *)rdev;
 
-   pci_set_master(dev-pdev);
-
/* update BUS flag */
if (drm_pci_device_is_agp(dev)) {
flags |= RADEON_IS_AGP;
diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
index e4e2132..ac1b451 100644
--- a/drivers/gpu/drm/radeon/rv770.c
+++ b/drivers/gpu/drm/radeon/rv770.c
@@ -1043,6 +1043,8 @@ static int rv770_startup(struct radeon_device *rdev)
/* enable pcie gen2 link */
rv770_pcie_gen2_enable(rdev);
 
+   pci_set_master(rdev-pdev);
+
if (!rdev-me_fw || !rdev-pfp_fw || !rdev-rlc_fw) {
r = r600_init_microcode(rdev);
if

[git pull] vmware fixes


Hi Linus,

These are just vmware fixes, Thomas sent them a couple of weeks back and 
my brain misparsed them, they are all crucial correctness fixes for vmwgfx 
and I really should have sent them on earlier.

Thanks,
Dave.

The following changes since commit 390f998509bf049019df0b078c0a6606e0d57fb4:

  Merge git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6 
(2011-12-18 14:28:31 -0800)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux drm-fixes

Jakob Bornecrantz (7):
  vmwgfx: Remove dmabuf check in present ioctl
  vmwgfx: Refactor cursor update
  vmwgfx: Add helper function to get surface or dmabuf
  vmwgfx: Refactor kms code to use vmw_user_lookup_handle helper
  vmwgfx: Do better culling of presents
  vmwgfx: Resend the cursor after legacy modeset
  vmwgfx: Clip cliprects against screen boundaries in present and dirty

Thomas Hellstrom (1):
  vmwgfx: Use the revised fifo hw version register when present

 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h  |5 +
 drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c |8 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c|   16 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c  |  394 +++---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.h  |5 +
 drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c  |   22 ++-
 drivers/gpu/drm/vmwgfx/vmwgfx_resource.c |   23 ++
 7 files changed, 318 insertions(+), 155 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 42883] Firefox crashes in state_tracker/st_cb_blit.c:87

https://bugs.freedesktop.org/show_bug.cgi?id=42883

--- Comment #2 from Alex Deucher ag...@yahoo.com 2011-12-19 06:39:32 PST ---
Thread for reference:
http://lists.freedesktop.org/archives/mesa-dev/2011-November/015286.html

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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

[Bug 43941] 'BUG: scheduling while atomic' after: 'panic occurred, switching back to text console'

https://bugs.freedesktop.org/show_bug.cgi?id=43941

Michel Dänzer mic...@daenzer.net changed:

   What|Removed |Added

 AssignedTo|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop
   ||.org
  QAContact|xorg-t...@lists.x.org   |
Summary|Driver BUG on MCE error |'BUG: scheduling while
   |report  |atomic' after: 'panic
   ||occurred, switching back to
   ||text console'
Product|xorg|DRI
Version|7.7 (2011)  |unspecified
  Component|Driver/Radeon   |DRM/Radeon

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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

Re: [PATCH] drm_edid: support CEA video modes

On Tue, Dec 13, 2011 at 5:47 PM, Jesse Barnes jbar...@virtuousgeek.org wrote:
 On Sun, 13 Nov 2011 01:31:35 +0100
 Christian Schmidt schm...@digadd.de wrote:

 TFT/plasma televisions and projectors have become commonplace, and so
 has the use of PCs to drive them. Add the video modes specified by an
 EDID's CEA extension to the mode database for a connector.

 Dave, Christian has a few patches outstanding for CEA mode handling.
 Getting them in makes sense to me and this patch looks like it's
 structured nicely at least (I haven't checked the CEA bits against the
 specs though).

 Any chance we can get them included for 3.3?

I've put this patch in, but please (and reviewers too, please tell
people before acking) in future,

submit patches as per the kernel's Documentation/SubmittingPatches

This patch was attached instead of inlined, wasn't in git format (not
essential but less work for me so more patches for you).

Is there other patches outstanding if so? please resend with collected reviews.

really anything that involves me taking manual steps will generally
mean I'll just drop the patch without caring with the understanding
that whoever wants the patch merged will care more than I do.

Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 43941] 'BUG: scheduling while atomic' after: 'panic occurred, switching back to text console'

https://bugs.freedesktop.org/show_bug.cgi?id=43941

--- Comment #11 from Michel Dänzer mic...@daenzer.net 2011-12-19 07:09:11 PST 
---
Created attachment 54573
  -- https://bugs.freedesktop.org/attachment.cgi?id=54573
Use mdelay instead of msleep

Does this patch fix the hang when switching back to console after the MCE?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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

[Bug 42883] Firefox crashes in state_tracker/st_cb_blit.c:87

https://bugs.freedesktop.org/show_bug.cgi?id=42883

--- Comment #3 from Stefan kde...@vogtner.de 2011-12-19 07:17:37 PST ---
(In reply to comment #2)

Mesa Works again. Thx.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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

[Bug 43861] Build error in Mesa with llvm = r145623

https://bugs.freedesktop.org/show_bug.cgi?id=43861

--- Comment #3 from Michel Dänzer mic...@daenzer.net 2011-12-19 07:21:05 PST 
---
I'd still argue it's not our bug, strictly speaking: llvm-config should only
expose compiler flags absolutely necessary for building against LLVM, such as
-I... -D..., certainly not such generic ones as -pedantic. We've run into
similar issues before with other flags.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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

[Bug 43941] 'BUG: scheduling while atomic' after: 'panic occurred, switching back to text console'

https://bugs.freedesktop.org/show_bug.cgi?id=43941

--- Comment #12 from Drago drago.iva...@gmail.com 2011-12-19 07:39:11 PST ---
Thanks, I will test this, but it may take some time for MCE to happen again.
I will report with the result here.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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

DVI/VGA/HDI mess on Radeon HD 6570

Hi,

about two months ago I bought a Radeon HD 6570 with
2GB memory for my main computer and I have a single
monitor connected to it, until now via VGA D-Sub.

Last week our secondary TV died (it was 15 years old, R.I.P.)
so I bought a nice 32 LED TV which has 3 external HDMI
connectors.

The HD 6570 has one DVI-D, one HDMI and one VGA connectors
so I thought it would be fun to allow the family to watch videos
while I can also work on the computer.

Here comes my problem: no matter which connectors I use
for the monitor (DVI-D or D-Sub), if the TV is switched on,
HDMI comes up as primary display. The result: GNOME 3
workspaces are switchable on the TV but a single workspace
is visible on my monitor. This would be the perfect setup
if I can reverse the roles of the TV and the monitor.

man radeon had an option which I tried but didn't help:
Option ZaphodHeads DVI-0,HDMI-0

Is there any other option that does what I want?

Thanks in advance,
Zoltán Böszörményi

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: DVI/VGA/HDI mess on Radeon HD 6570

2011-12-19 Thread David Airlie


 
 about two months ago I bought a Radeon HD 6570 with
 2GB memory for my main computer and I have a single
 monitor connected to it, until now via VGA D-Sub.
 
 Last week our secondary TV died (it was 15 years old, R.I.P.)
 so I bought a nice 32 LED TV which has 3 external HDMI
 connectors.
 
 The HD 6570 has one DVI-D, one HDMI and one VGA connectors
 so I thought it would be fun to allow the family to watch videos
 while I can also work on the computer.
 
 Here comes my problem: no matter which connectors I use
 for the monitor (DVI-D or D-Sub), if the TV is switched on,
 HDMI comes up as primary display. The result: GNOME 3
 workspaces are switchable on the TV but a single workspace
 is visible on my monitor. This would be the perfect setup
 if I can reverse the roles of the TV and the monitor.
 
 man radeon had an option which I tried but didn't help:
 Option ZaphodHeads DVI-0,HDMI-0

xrandr --output DVI-0 --primary

or open the gnome display applet and drag the bar from one monitor to another.

Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: DVI/VGA/HDI mess on Radeon HD 6570

2011-12-19 18:14 keltezéssel, David Airlie írta:
 about two months ago I bought a Radeon HD 6570 with
 2GB memory for my main computer and I have a single
 monitor connected to it, until now via VGA D-Sub.

 Last week our secondary TV died (it was 15 years old, R.I.P.)
 so I bought a nice 32 LED TV which has 3 external HDMI
 connectors.

 The HD 6570 has one DVI-D, one HDMI and one VGA connectors
 so I thought it would be fun to allow the family to watch videos
 while I can also work on the computer.

 Here comes my problem: no matter which connectors I use
 for the monitor (DVI-D or D-Sub), if the TV is switched on,
 HDMI comes up as primary display. The result: GNOME 3
 workspaces are switchable on the TV but a single workspace
 is visible on my monitor. This would be the perfect setup
 if I can reverse the roles of the TV and the monitor.

 man radeon had an option which I tried but didn't help:
 Option ZaphodHeads DVI-0,HDMI-0
 xrandr --output DVI-0 --primary

 or open the gnome display applet and drag the bar from one monitor to another.

Thanks.
Is this setting permanent after reboot and applies to GDM, too?


 Dave.


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: DVI/VGA/HDI mess on Radeon HD 6570

On Mon, 2011-12-19 at 18:19 +0100, Boszormenyi Zoltan wrote:

 Thanks.
 Is this setting permanent after reboot and applies to GDM, too?

It's stored in the session, so if there's not a Make system default
button in the UI, then no it won't affect gdm.

- ajax


signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: DVI/VGA/HDI mess on Radeon HD 6570

2011-12-19 18:42 keltezéssel, Adam Jackson írta:
 On Mon, 2011-12-19 at 18:19 +0100, Boszormenyi Zoltan wrote:

 Thanks.
 Is this setting permanent after reboot and applies to GDM, too?
 It's stored in the session, so if there's not a Make system default
 button in the UI, then no it won't affect gdm.

Thanks. As I am logged in as my user, there's no such button.
How can I set it as the system default? It was a long time ago
when GNOME allowed a root login.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: DVI/VGA/HDI mess on Radeon HD 6570

On Mon, 2011-12-19 at 18:56 +0100, Boszormenyi Zoltan wrote:

 Thanks. As I am logged in as my user, there's no such button.
 How can I set it as the system default? It was a long time ago
 when GNOME allowed a root login.

Ideally, gnome would implement that button.

Failing that you can set Option Primary for the appropriate monitor
section in xorg.conf.

- ajax


signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] fixes to drm-next - TTM DMA code (v1)

2011-12-19 Thread Thomas Hellstrom


On 12/13/2011 05:40 PM, Konrad Rzeszutek Wilk wrote:

On Tue, Dec 13, 2011 at 05:23:30PM +0100, Thomas Hellstrom wrote:
   

On 12/13/2011 05:07 PM, Jerome Glisse wrote:
 

On Mon, Dec 12, 2011 at 03:09:26PM -0500, Konrad Rzeszutek Wilk wrote:
   

Jerome pointed me to some accounting error in the DMA API debugging code and
while I can't figure it out yet, I did notice some extreme slowness - which
is due to the nouveau driver calling the unpopulate (now that unbind +
unpopulate are squashed) quite a lot (this is using Gnome Shell - I think GNOME2
did not have those issues but I can't recall).

Anyhow these patches fix the 50% perf regression I saw and also some minor bugs
that I noticed.

 

Gonna review those today and test them.

Cheers,
Jerome
   

Hi!

I'm not whether any drivers are still using the AGP backend?
 

Uh, probably they do if the cards are AGP?
The problem I encountered was with an PCIe Nvidia card:

01:00.0 VGA compatible controller: nVidia Corporation G84 [GeForce 8600 GT] 
(rev a1

   

Calling unpopulate / (previous clear) each time unbind is done
should be quite
inefficient with that one, as AGP sets up its own data structures
and copies page tables
on each populate. That should really be avoided unless there is a
good reason to have it.
 

nouveau_bo_rd32 and nv50_crtc_cursor_set showed up as the callers that
were causing the unpopulate calls. It did happen _a lot_ when I moved the
cursor madly.
   


Konrad, Jerome
Was there a resolution to this. If the ttm_tt rewrite results in 
unpopulate being called more often than before,
and that causes performance regressions, that must be fixed as soon as 
possible.


/Thomas




___
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

[Bug 43858] DVI of ATI RADEON 9200 AGP don't work

https://bugs.freedesktop.org/show_bug.cgi?id=43858

Valter valter.giovanne...@alice.it changed:

   What|Removed |Added

   Severity|normal  |critical

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 01/12] drm: Add a missing ')'

From: Ville Syrjälä ville.syrj...@linux.intel.com

The code happened to compile because the flag wasn't actually used yet.

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
 include/drm/drm_mode.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index 95d7aad..966fe7d 100644
--- a/include/drm/drm_mode.h
+++ b/include/drm/drm_mode.h
@@ -268,7 +268,7 @@ struct drm_mode_fb_cmd {
__u32 handle;
 };
 
-#define DRM_MODE_FB_INTERLACED (10 /* for interlaced framebuffers */
+#define DRM_MODE_FB_INTERLACED (10) /* for interlaced framebuffers */
 
 struct drm_mode_fb_cmd2 {
__u32 fb_id;
-- 
1.7.3.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 04/12] drm: plane: mutex_unlock() was missing

From: Ville Syrjälä ville.syrj...@linux.intel.com

Unlock the mode_config mutex if drm_plane_init() fails.

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
 drivers/gpu/drm/drm_crtc.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 2556589..7cb02f6 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -566,6 +566,7 @@ int drm_plane_init(struct drm_device *dev, struct drm_plane 
*plane,
if (!plane-format_types) {
DRM_DEBUG_KMS(out of memory when allocating plane\n);
drm_mode_object_put(dev, plane-base);
+   mutex_unlock(dev-mode_config.mutex);
return -ENOMEM;
}
 
-- 
1.7.3.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 05/12] drm: Fix __user sparse warnings

From: Ville Syrjälä ville.syrj...@linux.intel.com

Several pointers and casts were missing __user annotations.

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
 drivers/gpu/drm/drm_crtc.c |   30 +++---
 1 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 7cb02f6..e05d997 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1441,7 +1441,7 @@ int drm_mode_getconnector(struct drm_device *dev, void 
*data,
 */
if ((out_resp-count_modes = mode_count)  mode_count) {
copied = 0;
-   mode_ptr = (struct drm_mode_modeinfo *)(unsigned 
long)out_resp-modes_ptr;
+   mode_ptr = (struct drm_mode_modeinfo __user *)(unsigned 
long)out_resp-modes_ptr;
list_for_each_entry(mode, connector-modes, head) {
drm_crtc_convert_to_umode(u_mode, mode);
if (copy_to_user(mode_ptr + copied,
@@ -1456,8 +1456,8 @@ int drm_mode_getconnector(struct drm_device *dev, void 
*data,
 
if ((out_resp-count_props = props_count)  props_count) {
copied = 0;
-   prop_ptr = (uint32_t *)(unsigned long)(out_resp-props_ptr);
-   prop_values = (uint64_t *)(unsigned 
long)(out_resp-prop_values_ptr);
+   prop_ptr = (uint32_t __user *)(unsigned 
long)(out_resp-props_ptr);
+   prop_values = (uint64_t __user *)(unsigned 
long)(out_resp-prop_values_ptr);
for (i = 0; i  DRM_CONNECTOR_MAX_PROPERTY; i++) {
if (connector-property_ids[i] != 0) {
if (put_user(connector-property_ids[i],
@@ -1479,7 +1479,7 @@ int drm_mode_getconnector(struct drm_device *dev, void 
*data,
 
if ((out_resp-count_encoders = encoders_count)  encoders_count) {
copied = 0;
-   encoder_ptr = (uint32_t *)(unsigned 
long)(out_resp-encoders_ptr);
+   encoder_ptr = (uint32_t __user *)(unsigned 
long)(out_resp-encoders_ptr);
for (i = 0; i  DRM_CONNECTOR_MAX_ENCODER; i++) {
if (connector-encoder_ids[i] != 0) {
if (put_user(connector-encoder_ids[i],
@@ -1561,7 +1561,7 @@ int drm_mode_getplane_res(struct drm_device *dev, void 
*data,
 */
if (config-num_plane 
(plane_resp-count_planes = config-num_plane)) {
-   plane_ptr = (uint32_t *)(unsigned long)plane_resp-plane_id_ptr;
+   plane_ptr = (uint32_t __user *)(unsigned 
long)plane_resp-plane_id_ptr;
 
list_for_each_entry(plane, config-plane_list, head) {
if (put_user(plane-base.id, plane_ptr + copied)) {
@@ -1628,7 +1628,7 @@ int drm_mode_getplane(struct drm_device *dev, void *data,
 */
if (plane-format_count 
(plane_resp-count_format_types = plane-format_count)) {
-   format_ptr = (uint32_t *)(unsigned 
long)plane_resp-format_type_ptr;
+   format_ptr = (uint32_t __user *)(unsigned 
long)plane_resp-format_type_ptr;
if (copy_to_user(format_ptr,
 plane-format_types,
 sizeof(uint32_t) * plane-format_count)) {
@@ -1829,7 +1829,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
}
 
for (i = 0; i  crtc_req-count_connectors; i++) {
-   set_connectors_ptr = (uint32_t *)(unsigned 
long)crtc_req-set_connectors_ptr;
+   set_connectors_ptr = (uint32_t __user *)(unsigned 
long)crtc_req-set_connectors_ptr;
if (get_user(out_id, set_connectors_ptr[i])) {
ret = -EFAULT;
goto out;
@@ -2201,7 +2201,7 @@ int drm_mode_dirtyfb_ioctl(struct drm_device *dev,
fb = obj_to_fb(obj);
 
num_clips = r-num_clips;
-   clips_ptr = (struct drm_clip_rect *)(unsigned long)r-clips_ptr;
+   clips_ptr = (struct drm_clip_rect __user *)(unsigned long)r-clips_ptr;
 
if (!num_clips != !clips_ptr) {
ret = -EINVAL;
@@ -2591,7 +2591,7 @@ int drm_mode_getproperty_ioctl(struct drm_device *dev,
struct drm_property_enum *prop_enum;
struct drm_mode_property_enum __user *enum_ptr;
struct drm_property_blob *prop_blob;
-   uint32_t *blob_id_ptr;
+   uint32_t __user *blob_id_ptr;
uint64_t __user *values_ptr;
uint32_t __user *blob_length_ptr;
 
@@ -2621,7 +2621,7 @@ int drm_mode_getproperty_ioctl(struct drm_device *dev,
out_resp-flags = property-flags;
 
if ((out_resp-count_values = value_count)  value_count) {
-   values_ptr = (uint64_t *)(unsigned long)out_resp-values_ptr;
+   values_ptr = (uint64_t __user *)(unsigned 
long)out_resp-values_ptr;
for (i = 0; i

[PATCH 06/12] drm: plane: Clear plane.crtc and plane.fb after disable_plane()

From: Ville Syrjälä ville.syrj...@linux.intel.com

These are the only indication to user space that the plane was disabled.

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
Acked-by: Jesse Barnes jbar...@virtuousgeek.org
---
 drivers/gpu/drm/drm_crtc.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index e05d997..d9bf9d8 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1684,6 +1684,8 @@ int drm_mode_setplane(struct drm_device *dev, void *data,
/* No fb means shut it down */
if (!plane_req-fb_id) {
plane-funcs-disable_plane(plane);
+   plane-crtc = NULL;
+   plane-fb = NULL;
goto out;
}
 
-- 
1.7.3.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 07/12] drm: plane: Check source coordinates

From: Ville Syrjälä ville.syrj...@linux.intel.com

Make sure the source coordinates stay within the buffer.

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
 drivers/gpu/drm/drm_crtc.c |   23 +++
 1 files changed, 23 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index d9bf9d8..1242e12 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1661,6 +1661,7 @@ int drm_mode_setplane(struct drm_device *dev, void *data,
struct drm_crtc *crtc;
struct drm_framebuffer *fb;
int ret = 0;
+   unsigned int fb_width, fb_height;
 
if (!drm_core_check_feature(dev, DRIVER_MODESET))
return -EINVAL;
@@ -1709,6 +1710,28 @@ int drm_mode_setplane(struct drm_device *dev, void *data,
}
fb = obj_to_fb(obj);
 
+   fb_width = fb-width  16;
+   fb_height = fb-height  16;
+
+   /* Make sure source coordinates are inside the fb. */
+   if (plane_req-src_w  fb_width ||
+   plane_req-src_x  fb_width - plane_req-src_w ||
+   plane_req-src_h  fb_height ||
+   plane_req-src_y  fb_height - plane_req-src_h) {
+   DRM_DEBUG_KMS(Invalid source coordinates 
+ %u.%06ux%u.%06u+%u.%06u+%u.%06u\n,
+ plane_req-src_w  16,
+ ((plane_req-src_w  0x) * 15625)  10,
+ plane_req-src_h  16,
+ ((plane_req-src_h  0x) * 15625)  10,
+ plane_req-src_x  16,
+ ((plane_req-src_x  0x) * 15625)  10,
+ plane_req-src_y  16,
+ ((plane_req-src_y  0x) * 15625)  10);
+   ret = -ENOSPC;
+   goto out;
+   }
+
ret = plane-funcs-update_plane(plane, crtc, fb,
 plane_req-crtc_x, plane_req-crtc_y,
 plane_req-crtc_w, plane_req-crtc_h,
-- 
1.7.3.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Rebased drm_plane patches

I rebased this set on top of drm-next.

I updated some of the error values based on what Jesse suggested.

I also added a few patches to fix various issues that came up 
since I last posted the patches.

Since the patch to drop the planar formats with YVU plane order wasn't 
applied to drm-next, I check those too in patch 11/12.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 02/12] drm: Install drm_fourcc.h

From: Ville Syrjälä ville.syrj...@linux.intel.com

Userspace needs this header.

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
 include/drm/Kbuild |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/include/drm/Kbuild b/include/drm/Kbuild
index 3a60ac8..a5c0e10 100644
--- a/include/drm/Kbuild
+++ b/include/drm/Kbuild
@@ -1,4 +1,5 @@
 header-y += drm.h
+header-y += drm_fourcc.h
 header-y += drm_mode.h
 header-y += drm_sarea.h
 header-y += i810_drm.h
-- 
1.7.3.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 03/12] drm: fourcc: Use __u32 instead of u32

From: Ville Syrjälä ville.syrj...@linux.intel.com

drm_fourcc.h can be included from user space so use the appropriate types.

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
 include/drm/drm_fourcc.h |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index bb75249..4f99cb4 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -26,8 +26,8 @@
 
 #include linux/types.h
 
-#define fourcc_code(a,b,c,d) ((u32)(a) | ((u32)(b)  8) | \
- ((u32)(c)  16) | ((u32)(d)  24))
+#define fourcc_code(a, b, c, d) ((__u32)(a) | ((__u32)(b)  8) | \
+((__u32)(c)  16) | ((__u32)(d)  24))
 
 #define DRM_FORMAT_BIG_ENDIAN (131) /* format is big endian instead of 
little endian */
 
-- 
1.7.3.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 08/12] drm: plane: Check crtc coordinates against integer overflows in setplane ioctl

From: Ville Syrjälä ville.syrj...@linux.intel.com

Help drivers a little by guaranteeing that crtc_x+crtc_w and
crtc_y+crtc_h don't overflow.

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
 drivers/gpu/drm/drm_crtc.c |   12 
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 1242e12..b98e491 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1732,6 +1732,18 @@ int drm_mode_setplane(struct drm_device *dev, void *data,
goto out;
}
 
+   /* Give drivers some help against integer overflows */
+   if (plane_req-crtc_w  INT_MAX ||
+   plane_req-crtc_x  INT_MAX - (int32_t) plane_req-crtc_w ||
+   plane_req-crtc_h  INT_MAX ||
+   plane_req-crtc_y  INT_MAX - (int32_t) plane_req-crtc_h) {
+   DRM_DEBUG_KMS(Invalid CRTC coordinates %ux%u+%d+%d\n,
+ plane_req-crtc_w, plane_req-crtc_h,
+ plane_req-crtc_x, plane_req-crtc_y);
+   ret = -ERANGE;
+   goto out;
+   }
+
ret = plane-funcs-update_plane(plane, crtc, fb,
 plane_req-crtc_x, plane_req-crtc_y,
 plane_req-crtc_w, plane_req-crtc_h,
-- 
1.7.3.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 09/12] drm: plane: Make 'formats' parameter to drm_plane_init() const

From: Ville Syrjälä ville.syrj...@linux.intel.com

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
 drivers/gpu/drm/drm_crtc.c |2 +-
 include/drm/drm_crtc.h |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index b98e491..80cfe1c 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -554,7 +554,7 @@ EXPORT_SYMBOL(drm_encoder_cleanup);
 int drm_plane_init(struct drm_device *dev, struct drm_plane *plane,
   unsigned long possible_crtcs,
   const struct drm_plane_funcs *funcs,
-  uint32_t *formats, uint32_t format_count)
+  const uint32_t *formats, uint32_t format_count)
 {
mutex_lock(dev-mode_config.mutex);
 
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index dd55727..42c89b2 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -828,7 +828,7 @@ extern int drm_plane_init(struct drm_device *dev,
  struct drm_plane *plane,
  unsigned long possible_crtcs,
  const struct drm_plane_funcs *funcs,
- uint32_t *formats, uint32_t format_count);
+ const uint32_t *formats, uint32_t format_count);
 extern void drm_plane_cleanup(struct drm_plane *plane);
 
 extern void drm_encoder_cleanup(struct drm_encoder *encoder);
-- 
1.7.3.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 10/12] drm: plane: Check that the fb pixel format is supported by the plane

From: Ville Syrjälä ville.syrj...@linux.intel.com

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
 drivers/gpu/drm/drm_crtc.c |   11 +++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 80cfe1c..66a165d 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1662,6 +1662,7 @@ int drm_mode_setplane(struct drm_device *dev, void *data,
struct drm_framebuffer *fb;
int ret = 0;
unsigned int fb_width, fb_height;
+   int i;
 
if (!drm_core_check_feature(dev, DRIVER_MODESET))
return -EINVAL;
@@ -1710,6 +1711,16 @@ int drm_mode_setplane(struct drm_device *dev, void *data,
}
fb = obj_to_fb(obj);
 
+   /* Check whether this plane supports the fb pixel format. */
+   for (i = 0; i  plane-format_count; i++)
+   if (fb-pixel_format == plane-format_types[i])
+   break;
+   if (i == plane-format_count) {
+   DRM_DEBUG_KMS(Invalid pixel format 0x%08x\n, 
fb-pixel_format);
+   ret = -EINVAL;
+   goto out;
+   }
+
fb_width = fb-width  16;
fb_height = fb-height  16;
 
-- 
1.7.3.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 11/12] drm: Check that the requested pixel format is valid

From: Ville Syrjälä ville.syrj...@linux.intel.com

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
 drivers/gpu/drm/drm_crtc.c |   75 
 1 files changed, 75 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 66a165d..07d78e2 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2061,6 +2061,75 @@ out:
return ret;
 }
 
+static int format_check(struct drm_mode_fb_cmd2 *r)
+{
+   uint32_t format = r-pixel_format  ~DRM_FORMAT_BIG_ENDIAN;
+
+   switch (format) {
+   case DRM_FORMAT_C8:
+   case DRM_FORMAT_RGB332:
+   case DRM_FORMAT_BGR233:
+   case DRM_FORMAT_XRGB:
+   case DRM_FORMAT_XBGR:
+   case DRM_FORMAT_RGBX:
+   case DRM_FORMAT_BGRX:
+   case DRM_FORMAT_ARGB:
+   case DRM_FORMAT_ABGR:
+   case DRM_FORMAT_RGBA:
+   case DRM_FORMAT_BGRA:
+   case DRM_FORMAT_XRGB1555:
+   case DRM_FORMAT_XBGR1555:
+   case DRM_FORMAT_RGBX5551:
+   case DRM_FORMAT_BGRX5551:
+   case DRM_FORMAT_ARGB1555:
+   case DRM_FORMAT_ABGR1555:
+   case DRM_FORMAT_RGBA5551:
+   case DRM_FORMAT_BGRA5551:
+   case DRM_FORMAT_RGB565:
+   case DRM_FORMAT_BGR565:
+   case DRM_FORMAT_RGB888:
+   case DRM_FORMAT_BGR888:
+   case DRM_FORMAT_XRGB:
+   case DRM_FORMAT_XBGR:
+   case DRM_FORMAT_RGBX:
+   case DRM_FORMAT_BGRX:
+   case DRM_FORMAT_ARGB:
+   case DRM_FORMAT_ABGR:
+   case DRM_FORMAT_RGBA:
+   case DRM_FORMAT_BGRA:
+   case DRM_FORMAT_XRGB2101010:
+   case DRM_FORMAT_XBGR2101010:
+   case DRM_FORMAT_RGBX1010102:
+   case DRM_FORMAT_BGRX1010102:
+   case DRM_FORMAT_ARGB2101010:
+   case DRM_FORMAT_ABGR2101010:
+   case DRM_FORMAT_RGBA1010102:
+   case DRM_FORMAT_BGRA1010102:
+   case DRM_FORMAT_YUYV:
+   case DRM_FORMAT_YVYU:
+   case DRM_FORMAT_UYVY:
+   case DRM_FORMAT_VYUY:
+   case DRM_FORMAT_AYUV:
+   case DRM_FORMAT_NV12:
+   case DRM_FORMAT_NV21:
+   case DRM_FORMAT_NV16:
+   case DRM_FORMAT_NV61:
+   case DRM_FORMAT_YUV410:
+   case DRM_FORMAT_YVU410:
+   case DRM_FORMAT_YUV411:
+   case DRM_FORMAT_YVU411:
+   case DRM_FORMAT_YUV420:
+   case DRM_FORMAT_YVU420:
+   case DRM_FORMAT_YUV422:
+   case DRM_FORMAT_YVU422:
+   case DRM_FORMAT_YUV444:
+   case DRM_FORMAT_YVU444:
+   return 0;
+   default:
+   return -EINVAL;
+   }
+}
+
 /**
  * drm_mode_addfb2 - add an FB to the graphics configuration
  * @inode: inode from the ioctl
@@ -2100,6 +2169,12 @@ int drm_mode_addfb2(struct drm_device *dev,
return -EINVAL;
}
 
+   ret = format_check(r);
+   if (ret) {
+   DRM_ERROR(bad framebuffer format 0x%08x\n, r-pixel_format);
+   return ret;
+   }
+
mutex_lock(dev-mode_config.mutex);
 
fb = dev-mode_config.funcs-fb_create(dev, file_priv, r);
-- 
1.7.3.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 12/12] drm: Replace pitch with pitches[] in drm_framebuffer

From: Ville Syrjälä ville.syrj...@linux.intel.com

Otherwise each driver would need to keep the information inside
their own framebuffer object structure. Also add offsets[]. BOs
on the other hand are driver specific, so those can be kept in
driver specific structures.

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
 drivers/gpu/drm/drm_crtc.c  |2 +-
 drivers/gpu/drm/drm_crtc_helper.c   |7 -
 drivers/gpu/drm/exynos/exynos_drm_crtc.c|2 +-
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c   |4 +-
 drivers/gpu/drm/gma500/accel_2d.c   |2 +-
 drivers/gpu/drm/gma500/cdv_intel_display.c  |4 +-
 drivers/gpu/drm/gma500/framebuffer.c|2 +-
 drivers/gpu/drm/gma500/oaktrail_crtc.c  |4 +-
 drivers/gpu/drm/gma500/psb_intel_display.c  |4 +-
 drivers/gpu/drm/i915/i915_irq.c |2 +-
 drivers/gpu/drm/i915/intel_display.c|   36 +-
 drivers/gpu/drm/i915/intel_fb.c |2 +-
 drivers/gpu/drm/nouveau/nouveau_display.c   |8 +++---
 drivers/gpu/drm/nouveau/nouveau_fbcon.c |2 +-
 drivers/gpu/drm/nouveau/nv04_crtc.c |   14 +-
 drivers/gpu/drm/radeon/atombios_crtc.c  |4 +-
 drivers/gpu/drm/radeon/radeon_display.c |2 +-
 drivers/gpu/drm/radeon/radeon_fb.c  |4 +-
 drivers/gpu/drm/radeon/radeon_legacy_crtc.c |2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |8 +++---
 drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c |4 +-
 include/drm/drm_crtc.h  |3 +-
 22 files changed, 64 insertions(+), 58 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 07d78e2..0d1faa7 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2292,7 +2292,7 @@ int drm_mode_getfb(struct drm_device *dev,
r-width = fb-width;
r-depth = fb-depth;
r-bpp = fb-bits_per_pixel;
-   r-pitch = fb-pitch;
+   r-pitch = fb-pitches[0];
fb-funcs-create_handle(fb, file_priv, r-handle);
 
 out:
diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index 2ce61d7..ccbdc0b 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -814,9 +814,14 @@ EXPORT_SYMBOL(drm_helper_connector_dpms);
 int drm_helper_mode_fill_fb_struct(struct drm_framebuffer *fb,
   struct drm_mode_fb_cmd2 *mode_cmd)
 {
+   int i;
+
fb-width = mode_cmd-width;
fb-height = mode_cmd-height;
-   fb-pitch = mode_cmd-pitches[0];
+   for (i = 0; i  4; i++) {
+   fb-pitches[i] = mode_cmd-pitches[i];
+   fb-offsets[i] = mode_cmd-offsets[i];
+   }
drm_fb_get_bpp_depth(mode_cmd-pixel_format, fb-depth,
fb-bits_per_pixel);
fb-pixel_format = mode_cmd-pixel_format;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 9337e5e..73893e5 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -119,7 +119,7 @@ static int exynos_drm_overlay_update(struct 
exynos_drm_overlay *overlay,
overlay-fb_width = fb-width;
overlay-fb_height = fb-height;
overlay-bpp = fb-bits_per_pixel;
-   overlay-pitch = fb-pitch;
+   overlay-pitch = fb-pitches[0];
 
/* set overlay range to be displayed. */
overlay-crtc_x = pos-crtc_x;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index 1f4b3d1..81fba29 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -100,7 +100,7 @@ static int exynos_drm_fbdev_update(struct drm_fb_helper 
*helper,
 
exynos_fb-fb = fb;
 
-   drm_fb_helper_fill_fix(fbi, fb-pitch, fb-depth);
+   drm_fb_helper_fill_fix(fbi, fb-pitches[0], fb-depth);
drm_fb_helper_fill_var(fbi, helper, fb_width, fb_height);
 
entry = exynos_drm_fb_get_buf(fb);
@@ -110,7 +110,7 @@ static int exynos_drm_fbdev_update(struct drm_fb_helper 
*helper,
}
 
offset = fbi-var.xoffset * (fb-bits_per_pixel  3);
-   offset += fbi-var.yoffset * fb-pitch;
+   offset += fbi-var.yoffset * fb-pitches[0];
 
dev-mode_config.fb_base = entry-paddr;
fbi-screen_base = entry-vaddr + offset;
diff --git a/drivers/gpu/drm/gma500/accel_2d.c 
b/drivers/gpu/drm/gma500/accel_2d.c
index f0ce82a..d5ef1a5 100644
--- a/drivers/gpu/drm/gma500/accel_2d.c
+++ b/drivers/gpu/drm/gma500/accel_2d.c
@@ -253,7 +253,7 @@ static void psbfb_copyarea_accel(struct fb_info *info,
return;
 
offset = psbfb-gtt-offset;
-   stride = fb-pitch;
+   stride = fb-pitches[0];
 
switch (fb-depth) {
case 8:
diff --git a/drivers/gpu/drm/gma500/cdv_intel_display.c 
b/drivers/gpu/drm/gma500/cdv_intel_display.c
index

Plane helpers and a new plane options ioctl

Here are the utility functions again. Rebased and updated slightly.

I adapted drm_framebuffer_check() to handle multiple handles, and I changed
some of the error values it returns.

The plane options ioctl is a bit of an open question. I started by adding
separate ioctls for some subsets of the fucntionality, but then I was just
writing so much duplicated ioctl handling code that I decided it doesn't
seem right. I'm not really happy with this monster ioctl either.

I would actually like to replace the whole KMS API with some tag-length-value
(TLV) type of thing. Basically you'd just feed the ioctl a KMS object ID and
bunch of attribute IDs + values. The ioctl could take multiple such streams
for any number of KMS objects.

It would be easily extendible simply by adding new types of attributes.

It would also support atomic mode setting changes across an arbitrary set
of KMS objects, without having to do some kind begin+set+set+set...+commit
multi ioctl sequence with all the state management nightmares that it would
entail.

It would also cleanly handle cases where some attributes would be somehow
tied together in hardware (eg. you have to set one attribute to a specific
value, before another atribute can be set). With a multi ioctl approach you
would have to accept invalid intermediate states, and delay error checking
until the commit ioctl.

Of course you'd need to parse the stream and feed the resulting state to
the driver somehow. I'm think the common code would pass the stream to the
driver attribute at a time, and the driver would build up the state, possibly
doing some early error checking. Finally when the whole state is built up,
it would would be passed to the driver for final error checking, and if
everything looks good the driver could push the state to the hardware. The
driver could then attempt to do its thing in an atomic fashion, if possible.

Well, that's my utopian idea. Would require quite a bit of work though.
Anyone else thinking along similar lines?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH 1/8] drm: Add drm_format_num_planes() utility function

From: Ville Syrjälä ville.syrj...@linux.intel.com

This function returns the number of planes used by a specific pixel
format.

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
 drivers/gpu/drm/drm_crtc_helper.c |   33 +
 include/drm/drm_crtc_helper.h |3 +++
 2 files changed, 36 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index ccbdc0b..f388708 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -979,3 +979,36 @@ void drm_helper_hpd_irq_event(struct drm_device *dev)
queue_delayed_work(system_nrt_wq, 
dev-mode_config.output_poll_work, 0);
 }
 EXPORT_SYMBOL(drm_helper_hpd_irq_event);
+
+
+/**
+ * drm_format_num_planes - get the number of planes for format
+ * @format: pixel format (DRM_FORMAT_*)
+ *
+ * RETURNS:
+ * The number of planes used by the specified pixel format.
+ */
+int drm_format_num_planes(uint32_t format)
+{
+   switch (format) {
+   case DRM_FORMAT_YUV410:
+   case DRM_FORMAT_YVU410:
+   case DRM_FORMAT_YUV411:
+   case DRM_FORMAT_YVU411:
+   case DRM_FORMAT_YUV420:
+   case DRM_FORMAT_YVU420:
+   case DRM_FORMAT_YUV422:
+   case DRM_FORMAT_YVU422:
+   case DRM_FORMAT_YUV444:
+   case DRM_FORMAT_YVU444:
+   return 3;
+   case DRM_FORMAT_NV12:
+   case DRM_FORMAT_NV21:
+   case DRM_FORMAT_NV16:
+   case DRM_FORMAT_NV61:
+   return 2;
+   default:
+   return 1;
+   }
+}
+EXPORT_SYMBOL(drm_format_num_planes);
diff --git a/include/drm/drm_crtc_helper.h b/include/drm/drm_crtc_helper.h
index e88b7d7..37515d1 100644
--- a/include/drm/drm_crtc_helper.h
+++ b/include/drm/drm_crtc_helper.h
@@ -144,4 +144,7 @@ extern void drm_helper_hpd_irq_event(struct drm_device 
*dev);
 
 extern void drm_kms_helper_poll_disable(struct drm_device *dev);
 extern void drm_kms_helper_poll_enable(struct drm_device *dev);
+
+extern int drm_format_num_planes(uint32_t format);
+
 #endif
-- 
1.7.3.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH 4/8] drm: Add drm_framebuffer_check() utility function

From: Ville Syrjälä ville.syrj...@linux.intel.com

This function performs a battery of sanity checks on the requested
framebuffer layout. Drivers can call it from their fb_create hook.

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
 drivers/gpu/drm/drm_crtc_helper.c |   85 +
 include/drm/drm_crtc_helper.h |2 +
 2 files changed, 87 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index 00d1218..e87f932 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -1117,3 +1117,88 @@ int drm_format_vert_chroma_subsampling(uint32_t format)
}
 }
 EXPORT_SYMBOL(drm_format_vert_chroma_subsampling);
+
+/**
+ * drm_framebuffer_check - check the framebuffer layout
+ * @r: cmd from ioctl
+ * @sizes: sizes of the used BOs
+ *
+ * For each handle in the handles[] array of @r, the size of the
+ * corresponding BO must be passed in @sizes using the same index.
+ *
+ * RETURNS:
+ * Zero on success, error code on failure.
+ */
+int drm_framebuffer_check(const struct drm_mode_fb_cmd2 *r, const uint64_t 
sizes[4])
+{
+   struct {
+   unsigned int start, end;
+   } ranges[4];
+   unsigned int req_sizes[4] = {};
+   int hsub = drm_format_horz_chroma_subsampling(r-pixel_format);
+   int vsub = drm_format_vert_chroma_subsampling(r-pixel_format);
+   int num_planes = drm_format_num_planes(r-pixel_format);
+   int i, j;
+
+   if (r-width == 0 || r-height == 0)
+   return -EINVAL;
+
+   /* Keep things safe for s15.16 fixed point math. */
+   if (r-width  0x7fff || r-height  0x7fff)
+   return -ERANGE;
+
+   if (r-width % hsub || r-height % vsub)
+   return -EINVAL;
+
+   for (i = 0; i  num_planes; i++) {
+   unsigned int height = r-height / (i != 0 ? vsub : 1);
+   unsigned int width = r-width / (i != 0 ? hsub : 1);
+   unsigned int size = r-pitches[i] * height;
+   unsigned int cpp = drm_format_plane_cpp(r-pixel_format, i);
+   unsigned int min_pitch = cpp * width;
+
+   if (!r-handles[i])
+   return -EINVAL;
+
+   if (size  r-pitches[i] || size  height)
+   return -ERANGE;
+
+   if (min_pitch  width || min_pitch  cpp)
+   return -ERANGE;
+
+   if (r-pitches[i]  min_pitch)
+   return -EINVAL;
+
+   ranges[i].start = r-offsets[i];
+   ranges[i].end = ranges[i].start + size;
+
+   if (ranges[i].end  ranges[i].start)
+   return -ERANGE;
+
+   /* update all indexes of req_sizes that match this handle */
+   for (j = 0; j  num_planes; j++) {
+   if (r-handles[i] == r-handles[j])
+   req_sizes[j] = max(req_sizes[j], ranges[i].end);
+   }
+   }
+
+   /* Check that the passed BO sizes are sufficient */
+   for (i = 0; i  num_planes; i++) {
+   if (sizes[i]  req_sizes[i])
+   return -ENOSPC;
+   }
+
+   /* Check for overlapping ranges within the same BO */
+   /* FIXME what about formats with interleaved planes (eg. IMC2/IMC4)? */
+   for (i = 0; i  num_planes; i++) {
+   for (j = i + 1; j  num_planes; j++) {
+   if (r-handles[i] == r-handles[j] 
+   ranges[i].start  ranges[j].end 
+   ranges[j].start  ranges[i].end)
+   return -EINVAL;
+   }
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_framebuffer_check);
diff --git a/include/drm/drm_crtc_helper.h b/include/drm/drm_crtc_helper.h
index 30a6610..81b325f 100644
--- a/include/drm/drm_crtc_helper.h
+++ b/include/drm/drm_crtc_helper.h
@@ -149,5 +149,7 @@ extern int drm_format_num_planes(uint32_t format);
 extern int drm_format_plane_cpp(uint32_t format, int plane);
 extern int drm_format_horz_chroma_subsampling(uint32_t format);
 extern int drm_format_vert_chroma_subsampling(uint32_t format);
+extern int drm_framebuffer_check(const struct drm_mode_fb_cmd2 *r,
+const uint64_t sizes[4]);
 
 #endif
-- 
1.7.3.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH 6/8] drm: Add drm_calc_{hscale, vscale}() utility functions

From: Ville Syrjälä ville.syrj...@linux.intel.com

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
 drivers/gpu/drm/drm_crtc_helper.c |  102 +
 include/drm/drm_crtc_helper.h |4 ++
 2 files changed, 106 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index 3a5dac6..5e0b94c 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -1358,3 +1358,105 @@ bool drm_region_clip_scaled(struct drm_region *src, 
struct drm_region *dst,
return drm_region_clip(dst, clip);
 }
 EXPORT_SYMBOL(drm_region_clip_scaled);
+
+/**
+ * drm_calc_hscale - calculate the horizontal scaling factor
+ * @src: source window region
+ * @dst: destination window region
+ * @min_hscale: minimum allowed horizontal scaling factor
+ * @max_hscale: maximum allowed horizontal scaling factor
+ *
+ * Calculate the horizontal scaling factor as
+ * (@src width) / (@dst width).
+ *
+ * If the calculated scaling factor is below @min_hscale,
+ * decrease the width of region @dst to compensate.
+ *
+ * If the calculcated scaling factor is above @max_hscale,
+ * decrease the width of region @src to compensate.
+ *
+ * RETURNS:
+ * The horizontal scaling factor.
+ */
+int drm_calc_hscale(struct drm_region *src, struct drm_region *dst,
+   int min_hscale, int max_hscale)
+{
+   int src_w = drm_region_width(src);
+   int dst_w = drm_region_width(dst);
+   int hscale;
+
+   if (dst_w = 0)
+   return 0;
+
+   hscale = src_w / dst_w;
+
+   if (hscale  min_hscale) {
+   int max_dst_w = src_w / min_hscale;
+
+   drm_region_adjust_size(dst, max_dst_w - dst_w, 0);
+
+   return min_hscale;
+   }
+
+   if (hscale  max_hscale) {
+   int max_src_w = dst_w * max_hscale;
+
+   drm_region_adjust_size(src, max_src_w - src_w, 0);
+
+   return max_hscale;
+   }
+
+   return hscale;
+}
+EXPORT_SYMBOL(drm_calc_hscale);
+
+/**
+ * drm_calc_vscale - calculate the vertical scaling factor
+ * @src: source window region
+ * @dst: destination window region
+ * @min_vscale: minimum allowed vertical scaling factor
+ * @max_vscale: maximum allowed vertical scaling factor
+ *
+ * Calculate the vertical scaling factor as
+ * (@src height) / (@dst height).
+ *
+ * If the calculated scaling factor is below @min_vscale,
+ * decrease the height of region @dst to compensate.
+ *
+ * If the calculcated scaling factor is above @max_vscale,
+ * decrease the height of region @src to compensate.
+ *
+ * RETURNS:
+ * The vertical scaling factor.
+ */
+int drm_calc_vscale(struct drm_region *src, struct drm_region *dst,
+   int min_vscale, int max_vscale)
+{
+   int src_h = drm_region_height(src);
+   int dst_h = drm_region_height(dst);
+   int vscale;
+
+   if (dst_h = 0)
+   return 0;
+
+   vscale = src_h / dst_h;
+
+   if (vscale  min_vscale) {
+   int max_dst_h = src_h / min_vscale;
+
+   drm_region_adjust_size(dst, 0, max_dst_h - dst_h);
+
+   return min_vscale;
+   }
+
+   if (vscale  max_vscale) {
+   int max_src_h = dst_h * max_vscale;
+
+   drm_region_adjust_size(src, 0, max_src_h - src_h);
+
+   return max_vscale;
+   }
+
+   return vscale;
+}
+EXPORT_SYMBOL(drm_calc_vscale);
diff --git a/include/drm/drm_crtc_helper.h b/include/drm/drm_crtc_helper.h
index 591102f..78e77af 100644
--- a/include/drm/drm_crtc_helper.h
+++ b/include/drm/drm_crtc_helper.h
@@ -175,5 +175,9 @@ extern bool drm_region_clip_scaled(struct drm_region *src,
   struct drm_region *dst,
   const struct drm_region *clip,
   int hscale, int vscale);
+extern int drm_calc_hscale(struct drm_region *src, struct drm_region *dst,
+  int min_hscale, int max_hscale);
+extern int drm_calc_vscale(struct drm_region *src, struct drm_region *dst,
+  int min_vscale, int max_vscale);
 
 #endif
-- 
1.7.3.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH 7/8] drm: plane: Add plane options ioctl

From: Ville Syrjälä ville.syrj...@linux.intel.com

Add a new ioctl DRM_IOCTL_MODE_PLANE_OPTS which is used to configure
various settings for the plane.

I left out gamma correction thinking that it could be added using a
separate ioctl, since there's already a gamma ioctl for CRTCs.

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
 drivers/gpu/drm/drm_crtc.c|  168 +
 drivers/gpu/drm/drm_crtc_helper.c |   19 
 drivers/gpu/drm/drm_drv.c |3 +-
 include/drm/drm.h |2 +
 include/drm/drm_crtc.h|   60 +
 include/drm/drm_crtc_helper.h |1 +
 include/drm/drm_mode.h|  111 
 7 files changed, 363 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 0d1faa7..9cec7f0 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1772,6 +1772,174 @@ out:
 }
 
 /**
+ * drm_mode_plane_opts - set and get plane options
+ * @dev: DRM device
+ * @data: ioctl data*
+ * @file_prive: DRM file info
+ *
+ */
+int drm_mode_plane_opts(struct drm_device *dev, void *data,
+   struct drm_file *file_priv)
+{
+   struct drm_mode_plane_opts_cmd *req = data;
+   struct drm_mode_object *obj;
+   struct drm_plane *plane;
+   int ret = 0;
+
+   if (!drm_core_check_feature(dev, DRIVER_MODESET))
+   return -EINVAL;
+
+   mutex_lock(dev-mode_config.mutex);
+
+   /*
+* First, find the plane object.  If not available,
+* we don't bother to call the driver.
+*/
+   obj = drm_mode_object_find(dev, req-plane_id,
+  DRM_MODE_OBJECT_PLANE);
+   if (!obj) {
+   DRM_DEBUG_KMS(Unknown plane ID %d\n,
+ req-plane_id);
+   ret = -ENOENT;
+   goto out;
+   }
+   plane = obj_to_plane(obj);
+
+   if (req-flags  ~plane-opts_flags) {
+   ret = -ENOTSUPP;
+   goto out;
+   }
+
+   if (req-flags) {
+   /* Start with the current values. */
+   struct drm_plane_opts opts = plane-opts;
+   uint32_t flags = 0;
+
+   /* Overwrite with user provided values. */
+   if (req-flags  DRM_MODE_PLANE_BRIGHTNESS 
+   opts.brightness != req-brightness) {
+   flags |= DRM_MODE_PLANE_BRIGHTNESS;
+   opts.brightness = req-brightness;
+   }
+   if (req-flags  DRM_MODE_PLANE_CONTRAST 
+   opts.contrast != req-contrast) {
+   flags |= DRM_MODE_PLANE_CONTRAST;
+   opts.contrast = req-contrast;
+   }
+   if (req-flags  DRM_MODE_PLANE_HUE 
+   opts.hue != req-hue) {
+   flags |= DRM_MODE_PLANE_HUE;
+   opts.hue = req-hue;
+   }
+   if (req-flags  DRM_MODE_PLANE_SATURATION 
+   opts.saturation != req-saturation) {
+   flags |= DRM_MODE_PLANE_SATURATION;
+   opts.saturation = req-saturation;
+   }
+   if (req-flags  DRM_MODE_PLANE_SRC_KEY 
+   (opts.src_key_low != req-src_key_low ||
+opts.src_key_high != req-src_key_high)) {
+   flags |= DRM_MODE_PLANE_SRC_KEY;
+   opts.src_key_low = req-src_key_low;
+   opts.src_key_high = req-src_key_high;
+   }
+   if (req-flags  DRM_MODE_PLANE_DST_KEY 
+   (opts.dst_key_value != req-dst_key_value ||
+opts.dst_key_mask != req-dst_key_mask)) {
+   flags |= DRM_MODE_PLANE_DST_KEY;
+   opts.dst_key_value = req-dst_key_value;
+   opts.dst_key_mask = req-dst_key_mask;
+   }
+   if (req-flags  DRM_MODE_PLANE_CONST_ALPHA 
+   opts.const_alpha != req-const_alpha) {
+   flags |= DRM_MODE_PLANE_CONST_ALPHA;
+   opts.const_alpha = req-const_alpha;
+   }
+   if (req-flags  DRM_MODE_PLANE_ZORDER 
+   opts.zorder != req-zorder) {
+   if (req-zorder == 0) {
+   ret = -EINVAL;
+   goto out;
+   }
+   flags |= DRM_MODE_PLANE_ZORDER;
+   opts.zorder = req-zorder;
+   }
+   if (req-flags  DRM_MODE_PLANE_CSC_MATRIX 
+   opts.csc_matrix != req-csc_matrix) {
+   flags |= DRM_MODE_PLANE_CSC_MATRIX;
+   opts.csc_matrix = req-csc_matrix;
+   }
+   if (req-flags  DRM_MODE_PLANE_CSC_RANGE 
+

[RFC PATCH 5/8] drm: Add struct drm_region and assorted utility functions

From: Ville Syrjälä ville.syrj...@linux.intel.com

struct drm_region represents a two dimensional region. The utility
functions are there to help driver writers.

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
 drivers/gpu/drm/drm_crtc_helper.c |  156 +
 include/drm/drm_crtc_helper.h |   24 ++
 2 files changed, 180 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index e87f932..3a5dac6 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -1202,3 +1202,159 @@ int drm_framebuffer_check(const struct drm_mode_fb_cmd2 
*r, const uint64_t sizes
return 0;
 }
 EXPORT_SYMBOL(drm_framebuffer_check);
+
+
+/**
+ * drm_region_adjust_size - adjust the size of the region
+ * @r: region to be adjusted
+ * @x: horizontal adjustment
+ * @y: vertical adjustment
+ *
+ * Change the size of region @r by @x in the horizontal direction,
+ * and by @y in the vertical direction, while keeping the center
+ * of @r stationary.
+ *
+ * Positive @x and @y increase the size, negative values decrease it.
+ */
+void drm_region_adjust_size(struct drm_region *r, int x, int y)
+{
+   r-x1 -= x  1;
+   r-y1 -= y  1;
+   r-x2 += (x + 1)  1;
+   r-y2 += (y + 1)  1;
+}
+EXPORT_SYMBOL(drm_region_adjust_size);
+
+/**
+ * drm_region_translate - translate the region
+ * @r: region to be tranlated
+ * @x: horizontal translation
+ * @y: vertical translation
+ *
+ * Move region @r by @x in the horizontal direction,
+ * and by @y in the vertical direction.
+ */
+void drm_region_translate(struct drm_region *r, int x, int y)
+{
+   r-x1 += x;
+   r-y1 += y;
+   r-x2 += x;
+   r-y2 += y;
+}
+EXPORT_SYMBOL(drm_region_translate);
+
+/**
+ * drm_region_subsample - subsample a region
+ * @r: region to be subsampled
+ * @hsub: horizontal subsampling factor
+ * @vsub: vertical subsampling factor
+ *
+ * Divide the coordinates of region @r by @hsub and @vsub.
+ */
+void drm_region_subsample(struct drm_region *r, int hsub, int vsub)
+{
+   r-x1 /= hsub;
+   r-y1 /= vsub;
+   r-x2 /= hsub;
+   r-y2 /= vsub;
+}
+EXPORT_SYMBOL(drm_region_subsample);
+
+/**
+ * drm_region_width - determine the region width
+ * @r: region whose width is returned
+ *
+ * RETURNS:
+ * The width of the region.
+ */
+int drm_region_width(const struct drm_region *r)
+{
+   return r-x2 - r-x1;
+}
+EXPORT_SYMBOL(drm_region_width);
+
+/**
+ * drm_region_height - determine the region height
+ * @r: region whose height is returned
+ *
+ * RETURNS:
+ * The height of the region.
+ */
+int drm_region_height(const struct drm_region *r)
+{
+   return r-y2 - r-y1;
+}
+EXPORT_SYMBOL(drm_region_height);
+
+/**
+ * drm_region_visible - determine if the the region is visible
+ * @r: region whose visibility is returned
+ *
+ * RETURNS:
+ * @true if the region is visible, @false otherwise.
+ */
+bool drm_region_visible(const struct drm_region *r)
+{
+   return drm_region_width(r)  0  drm_region_height(r)  0;
+}
+EXPORT_SYMBOL(drm_region_visible);
+
+/**
+ * drm_region_clip - clip one region by another region
+ * @r: region to be clipped
+ * @clip: clip region
+ *
+ * Clip region @r by region @clip.
+ *
+ * RETURNS:
+ * @true if the region is still visible after being clipped,
+ * @false otherwise.
+ */
+bool drm_region_clip(struct drm_region *r, const struct drm_region *clip)
+{
+   r-x1 = max(r-x1, clip-x1);
+   r-y1 = max(r-y1, clip-y1);
+   r-x2 = min(r-x2, clip-x2);
+   r-y2 = min(r-y2, clip-y2);
+
+   return drm_region_visible(r);
+}
+EXPORT_SYMBOL(drm_region_clip);
+
+/**
+ * drm_region_clip_scaled - perform a scaled clip operation
+ * @src: source window region
+ * @dst: destination window region
+ * @clip: clip region
+ * @hscale: horizontal scaling factor
+ * @vscale: vertical scaling factor
+ *
+ * Clip region @dst by region @clip. Clip region @src by the same
+ * amounts multiplied by @hscale and @vscale.
+ *
+ * RETUTRNS:
+ * @true if region @dst is still visible after being clipped,
+ * @false otherwise
+ */
+bool drm_region_clip_scaled(struct drm_region *src, struct drm_region *dst,
+   const struct drm_region *clip,
+   int hscale, int vscale)
+{
+   int diff;
+
+   diff = clip-x1 - dst-x1;
+   if (diff  0)
+   src-x1 += diff * hscale;
+   diff = clip-y1 - dst-y1;
+   if (diff  0)
+   src-y1 += diff * vscale;
+   diff = dst-x2 - clip-x2;
+   if (diff  0)
+   src-x2 -= diff * hscale;
+   diff = dst-y2 - clip-y2;
+   if (diff  0)
+   src-y2 -= diff * vscale;
+
+   return drm_region_clip(dst, clip);
+}
+EXPORT_SYMBOL(drm_region_clip_scaled);
diff --git a/include/drm/drm_crtc_helper.h b/include/drm/drm_crtc_helper.h
index 81b325f..591102f 100644
--- a/include/drm/drm_crtc_helper.h
+++ b/include/drm/drm_crtc_helper.h

[RFC PATCH 8/8] drm: Add drm_chroma_phase_offsets() utility function

From: Ville Syrjälä ville.syrj...@linux.intel.com

This function is is there to help driver writers.

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
 drivers/gpu/drm/drm_crtc_helper.c |   47 +
 include/drm/drm_crtc_helper.h |3 ++
 2 files changed, 50 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index 0153187..341f05c 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -1479,3 +1479,50 @@ void drm_plane_opts_defaults(struct drm_plane_opts *opts)
opts-const_alpha = 0x;
 }
 EXPORT_SYMBOL(drm_plane_opts_defaults);
+
+/**
+ * drm_chroma_phase_offsets - calculate the chroma phase offsets
+ * @ret_xoff: returned horizontal offset (16.16)
+ * @ret_yoff: returned vertical offset (16.16)
+ * @hsub: horizontal chroma subsampling factor
+ * @vsub: vertical chroma subsampling factor
+ * @chroma: chroma siting information
+ * @second_chroma_plane: first or second chroma plane?
+ *
+ * Calculates the phase offset between chroma and luma pixel centers,
+ * based on infromation provided in @chroma, @hsub, @vsub, and
+ * @second_chroma_plane.
+ *
+ * RETURNS:
+ * The chroma phase offsets in 16.16 format. The returned
+ * phase offsets are in chroma (ie. subsampled) coordinate space.
+ */
+void drm_chroma_phase_offsets(int *ret_xoff, int *ret_yoff,
+ int hsub, int vsub, uint8_t chroma_siting,
+ bool second_chroma_plane)
+{
+   *ret_xoff = 0;
+   *ret_yoff = 0;
+
+   switch (chroma_siting  0x3) {
+   case DRM_CHROMA_SITING_HORZ_LEFT:
+   break;
+   case DRM_CHROMA_SITING_HORZ_CENTER:
+   *ret_xoff -= (hsub - 1) * 0x8000 / hsub;
+   break;
+   }
+
+   switch (chroma_siting  0xc0) {
+   case DRM_CHROMA_SITING_VERT_TOP:
+   break;
+   case DRM_CHROMA_SITING_VERT_CENTER:
+   *ret_yoff -= (vsub - 1) * 0x8000 / vsub;
+   break;
+   }
+
+   /* Chroma planes out of phase by 0.5 chroma lines? */
+   if (second_chroma_plane 
+   (chroma_siting  DRM_CHROMA_SITING_MISALIGNED_PLANES))
+   *ret_yoff -= 0x8000;
+}
+EXPORT_SYMBOL(drm_chroma_phase_offsets);
diff --git a/include/drm/drm_crtc_helper.h b/include/drm/drm_crtc_helper.h
index e4946a5..58881f6 100644
--- a/include/drm/drm_crtc_helper.h
+++ b/include/drm/drm_crtc_helper.h
@@ -180,5 +180,8 @@ extern int drm_calc_hscale(struct drm_region *src, struct 
drm_region *dst,
 extern int drm_calc_vscale(struct drm_region *src, struct drm_region *dst,
   int min_vscale, int max_vscale);
 extern void drm_plane_opts_defaults(struct drm_plane_opts *opts);
+extern void drm_chroma_phase_offsets(int *ret_xoff, int *ret_yoff,
+int hsub, int vsub, uint8_t chroma_siting,
+bool second_chroma_plane);
 
 #endif
-- 
1.7.3.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 43964] A script fail to build in Penumbra Overture game

https://bugs.freedesktop.org/show_bug.cgi?id=43964

Laurent carlier lordhea...@gmail.com changed:

   What|Removed |Added

 AssignedTo|i...@freedesktop.org |dri-devel@lists.freedesktop
   ||.org
  Component|glsl-compiler   |Drivers/Gallium/r600

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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

high_memory address in /proc/dri/*/vma

[Re-sent to the right address, I hope.]

Kees, in commit 01e2f533a234dc62d16c0d3d4fb9d71cf1ce50c3 (drm: do not
leak kernel addresses via /proc/dri/*/vma) you changed the logging of
high_memory:

-   seq_printf(m, vma use count: %d, high_memory = %p, 0x%08llx\n,
+   seq_printf(m, vma use count: %d, high_memory = %pK, 0x%pK\n,
   atomic_read(dev-vma_count),
-  high_memory, (u64)virt_to_phys(high_memory));
+  high_memory, (void *)virt_to_phys(high_memory));

This doesn't make sense because the physical address may be truncated
(in theory at least).

I think it would make more sense to make this entire file readable by
root only, but I don't know whether anything depends on being able to
read it.  Its existence is conditional on DRM_DEBUG_CODE != 0 but that
is always true at the moment.

Ben.

-- 
Ben Hutchings
Humans are not rational beings; they are rationalising beings.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: high_memory address in /proc/dri/*/vma

On Mon, 2011-12-19 at 16:14 -0800, Kees Cook wrote:
 On Mon, Dec 19, 2011 at 4:09 PM, Ben Hutchings b...@decadent.org.uk wrote:
  Kees, in commit 01e2f533a234dc62d16c0d3d4fb9d71cf1ce50c3 (drm: do not
  leak kernel addresses via /proc/dri/*/vma) you changed the logging of
  high_memory:
 
  -   seq_printf(m, vma use count: %d, high_memory = %p, 0x%08llx\n,
  +   seq_printf(m, vma use count: %d, high_memory = %pK, 0x%pK\n,
atomic_read(dev-vma_count),
  -  high_memory, (u64)virt_to_phys(high_memory));
  +  high_memory, (void *)virt_to_phys(high_memory));
 
  This doesn't make sense because the physical address may be truncated
  (in theory at least).
 
 Leaking even a truncated address is still a problem, IMO. Or do you
 mean there is some side-effect causing a problem?

I mean that this the conversion to void * can be a narrowing conversion,
so when printing of kernel pointers is enabled the full physical address
may not be displayed.

  I think it would make more sense to make this entire file readable by
  root only, but I don't know whether anything depends on being able to
  read it.  Its existence is conditional on DRM_DEBUG_CODE != 0 but that
  is always true at the moment.
 
 The kptr_restrict syscall (that controls %pK behavior) has 3 modes,
 including one that hides these values even from the root user, so I
 would prefer this stays as-is.
 
 Sorry I'm being dense, but what problem is %pK causing here? I'd be
 happy to help get it fixed.

The problem is that it is not suitable for printing physical addresses,
because they are not pointers.
 
Ben.

-- 
Ben Hutchings
Humans are not rational beings; they are rationalising beings.


signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 43771] [i915g] src/gallium/auxiliary/gallivm/lp_bld_sample_aos.c:821:lp_build_sample_mipmap: Assertion `img_filter == 1' failed.

https://bugs.freedesktop.org/show_bug.cgi?id=43771

Stephane Marchesin marche...@icps.u-strasbg.fr changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #1 from Stephane Marchesin marche...@icps.u-strasbg.fr 2011-12-19 
18:35:14 PST ---
Fixed at
http://cgit.freedesktop.org/mesa/mesa/commit/?id=9c76ba04f845077d51912cc11970232cc9160294

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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

Re: high_memory address in /proc/dri/*/vma

On Mon, 2011-12-19 at 18:35 -0800, Kees Cook wrote:
 On Mon, Dec 19, 2011 at 6:18 PM, Ben Hutchings b...@decadent.org.uk wrote:
  On Mon, 2011-12-19 at 16:14 -0800, Kees Cook wrote:
  On Mon, Dec 19, 2011 at 4:09 PM, Ben Hutchings b...@decadent.org.uk 
  wrote:
   Kees, in commit 01e2f533a234dc62d16c0d3d4fb9d71cf1ce50c3 (drm: do not
   leak kernel addresses via /proc/dri/*/vma) you changed the logging of
   high_memory:
  
   -   seq_printf(m, vma use count: %d, high_memory = %p, 0x%08llx\n,
   +   seq_printf(m, vma use count: %d, high_memory = %pK, 0x%pK\n,
 atomic_read(dev-vma_count),
   -  high_memory, (u64)virt_to_phys(high_memory));
   +  high_memory, (void *)virt_to_phys(high_memory));
  
   This doesn't make sense because the physical address may be truncated
   (in theory at least).
 
  Leaking even a truncated address is still a problem, IMO. Or do you
  mean there is some side-effect causing a problem?
 
  I mean that this the conversion to void * can be a narrowing conversion,
  so when printing of kernel pointers is enabled the full physical address
  may not be displayed.
 
 Ah-ha, okay, I see what you mean now. This is, as you say, only a
 problem in theory. Is it worth fixing currently?

I don't know.

 If so, we probably need to add the K option to %x in some fashion.

Something like that, yes.

Ben.

-- 
Ben Hutchings
Humans are not rational beings; they are rationalising beings.


signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: high_memory address in /proc/dri/*/vma

On Mon, Dec 19, 2011 at 4:09 PM, Ben Hutchings b...@decadent.org.uk wrote:
 Kees, in commit 01e2f533a234dc62d16c0d3d4fb9d71cf1ce50c3 (drm: do not
 leak kernel addresses via /proc/dri/*/vma) you changed the logging of
 high_memory:

 -       seq_printf(m, vma use count: %d, high_memory = %p, 0x%08llx\n,
 +       seq_printf(m, vma use count: %d, high_memory = %pK, 0x%pK\n,
                   atomic_read(dev-vma_count),
 -                  high_memory, (u64)virt_to_phys(high_memory));
 +                  high_memory, (void *)virt_to_phys(high_memory));

 This doesn't make sense because the physical address may be truncated
 (in theory at least).

Leaking even a truncated address is still a problem, IMO. Or do you
mean there is some side-effect causing a problem?

 I think it would make more sense to make this entire file readable by
 root only, but I don't know whether anything depends on being able to
 read it.  Its existence is conditional on DRM_DEBUG_CODE != 0 but that
 is always true at the moment.

The kptr_restrict syscall (that controls %pK behavior) has 3 modes,
including one that hides these values even from the root user, so I
would prefer this stays as-is.

Sorry I'm being dense, but what problem is %pK causing here? I'd be
happy to help get it fixed.

-Kees

-- 
Kees Cook
ChromeOS Security
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism

2011-12-19 Thread Robert Morell

On Tue, Dec 13, 2011 at 07:10:02AM -0800, Arnd Bergmann wrote:
On Monday 12 December 2011, Robert Morell wrote:

Doing a buffer sharing with something that is not GPL is not fun, as, if
any
issue rises there, it would be impossible to discover if the problem is
either
at the closed-source driver or at the open source one. At the time I was
using
the Nvidia proprietary driver, it was very common to have unexplained
issues
caused likely by bad code there at the buffer management code, causing X
applications and extensions (like xv) to break.

We should really make this EXPORT_SYMBOL_GPL(), in order to be able to
latter
debug future share buffer issues, when needed.

Sorry, I don't buy this argument. Making these exports GPL-only is not
likely to cause anybody to open-source their driver, but will rather
just cause them to use yet more closed-source code that is even less
debuggable than this would be, to those without access to the source.

But at least the broken module then won't be interacting with other modules
because it cannot share any buffers.

One of the goals of this project is to unify the fragmented space of the
ARM SoC memory managers so that each vendor doesn't implement their own,
and they can all be closer to mainline.

I fear that restricting the use of this buffer sharing mechanism to GPL
drivers only will prevent that goal from being achieved, if an SoC
driver has to interact with modules that use a non-GPL license.

As a hypothetical example, consider laptops that have multiple GPUs.
Today, these ship with onboard graphics (integrated to the CPU or
chipset) along with a discrete GPU, where in many cases only the onboard
graphics can actually display to the screen. In order for anything
rendered by the discrete GPU to be displayed, it has to be copied to
memory available for the smaller onboard graphics to texture from or
display directly. Obviously, that's best done by sharing dma buffers
rather than bouncing them through the GPU. It's not much of a stretch
to imagine that we'll see such systems with a Tegra CPU/GPU plus a
discrete GPU in the future; in that case, we'd want to be able to share
memory between the discrete GPU and the Tegra system. In that scenario,
if this interface is GPL-only, we'd be unable to adopt the dma_buffer
sharing mechanism for Tegra.

(This isn't too pie-in-the-sky, either; people are already combining
Tegra with discrete GPUs:
http://blogs.nvidia.com/2011/11/world%e2%80%99s-first-arm-based-supercomputer-to-launch-in-barcelona/
)

Thanks,
Robert
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: high_memory address in /proc/dri/*/vma

On Mon, Dec 19, 2011 at 6:18 PM, Ben Hutchings b...@decadent.org.uk wrote:
 On Mon, 2011-12-19 at 16:14 -0800, Kees Cook wrote:
 On Mon, Dec 19, 2011 at 4:09 PM, Ben Hutchings b...@decadent.org.uk wrote:
  Kees, in commit 01e2f533a234dc62d16c0d3d4fb9d71cf1ce50c3 (drm: do not
  leak kernel addresses via /proc/dri/*/vma) you changed the logging of
  high_memory:
 
  -       seq_printf(m, vma use count: %d, high_memory = %p, 0x%08llx\n,
  +       seq_printf(m, vma use count: %d, high_memory = %pK, 0x%pK\n,
                    atomic_read(dev-vma_count),
  -                  high_memory, (u64)virt_to_phys(high_memory));
  +                  high_memory, (void *)virt_to_phys(high_memory));
 
  This doesn't make sense because the physical address may be truncated
  (in theory at least).

 Leaking even a truncated address is still a problem, IMO. Or do you
 mean there is some side-effect causing a problem?

 I mean that this the conversion to void * can be a narrowing conversion,
 so when printing of kernel pointers is enabled the full physical address
 may not be displayed.

Ah-ha, okay, I see what you mean now. This is, as you say, only a
problem in theory. Is it worth fixing currently? If so, we probably
need to add the K option to %x in some fashion.

-Kees

-- 
Kees Cook
ChromeOS Security
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

high_memory address in /proc/dri/*/vma

Kees, in commit 01e2f533a234dc62d16c0d3d4fb9d71cf1ce50c3 ("drm: do not
leak kernel addresses via /proc/dri/*/vma") you changed the logging of
high_memory:

-   seq_printf(m, "vma use count: %d, high_memory = %p, 0x%08llx\n",
+   seq_printf(m, "vma use count: %d, high_memory = %pK, 0x%pK\n",
   atomic_read(>vma_count),
-  high_memory, (u64)virt_to_phys(high_memory));
+  high_memory, (void *)virt_to_phys(high_memory));

This doesn't make sense because the physical address may be truncated
(in theory at least).

I think it would make more sense to make this entire file readable by
root only, but I don't know whether anything depends on being able to
read it.  Its existence is conditional on DRM_DEBUG_CODE != 0 but that
is always true at the moment.

Ben.

-- 
Ben Hutchings
Humans are not rational beings; they are rationalising beings.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 828 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111219/11639bef/attachment.pgp>

[Bug 42622] [r300g] mupen64plus invalid command stream

https://bugs.freedesktop.org/show_bug.cgi?id=42622

--- Comment #3 from Scott Moreau  2011-12-18 21:43:34 PST 
---
Created attachment 54566
  --> https://bugs.freedesktop.org/attachment.cgi?id=54566
patch

I went ahead and bisected mesa. Here's what I came up with:

12fa91b6753dccbd3aa12c570d1f1e55c7dc0582 is the first bad commit
commit 12fa91b6753dccbd3aa12c570d1f1e55c7dc0582
Author: Thomas Hellstrom 
Date:   Mon Mar 7 11:24:43 2011 +0100

st/mesa: Fix an incorrect user vertex buffer reference

st->user_vb[attr] was always pointing to the same user vb, regardless
of the value of attr. Together with reverting the temporary workaround
for bug 34378, and a fix in the svga driver, this fixes googleearth on
svga.

Signed-off-by: Thomas Hellstrom 

:04 04 ca575588faeb8fe79c3d768ff28a7a808a64afac
2b9a78c9034e26ee411981d8d0cd06b72133beab Msrc


The previous commit works. I've attached a patch that simply reverts the
relevant bits.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 42622] [r300g] mupen64plus invalid command stream

https://bugs.freedesktop.org/show_bug.cgi?id=42622

--- Comment #4 from Scott Moreau  2011-12-18 21:48:12 PST 
---
(In reply to comment #2)
> Which kernel version do you have?

I've tested on 2.6.38 and 3.0.0 both 32bit.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism

2011-12-19 Thread Semwal, Sumit

Hi Arnd, Daniel,

On Mon, Dec 12, 2011 at 10:18 PM, Arnd Bergmann  wrote:
> On Saturday 10 December 2011, Daniel Vetter wrote:
>> If userspace (through some driver calls)
>> tries to do stupid things, it'll just get garbage. See
>> Message-ID: > mail.gmail.com>
>> for my reasons why it think this is the right way to go forward. So in
>> essence I'm really interested in the reasons why you want the kernel
>> to enforce this (or I'm completely missing what's the contentious
>> issue here).
>
> This has nothing to do with user space mappings. Whatever user space does,
> you get garbage if you don't invalidate cache lines that were introduced
> through speculative prefetching before you access cache lines that were
> DMA'd from a device.
I didn't see a consensus on whether dma_buf should enforce some form
of serialization within the API - so atleast for v1 of dma-buf, I
propose to 'not' impose a restriction, and we can tackle it (add new
ops or enforce as design?) whenever we see the first need of it - will
that be ok? [I am bending towards the thought that it is a problem to
solve at a bigger platform than dma_buf.]
>
> ? ? ? ?Arnd

Best regards,
~Sumit.
>
> --

[RFC v3 0/2] Introduce DMA buffer sharing mechanism

Hello Everyone,

This is RFC v3 for DMA buffer sharing mechanism - changes from v2 are in the
changelog below.

Various subsystems - V4L2, GPU-accessors, DRI to name a few - have felt the 
need to have a common mechanism to share memory buffers across different
devices - ARM, video hardware, GPU.

This need comes forth from a variety of use cases including cameras, image 
processing, video recorders, sound processing, DMA engines, GPU and display
buffers, and others.

This RFC is an attempt to define such a buffer sharing mechanism- it is the
result of discussions from a couple of memory-management mini-summits held by
Linaro to understand and address common needs around memory management. [1]

A new dma_buf buffer object is added, with operations and API to allow easy
sharing of this buffer object across devices.

The framework allows:
- a new buffer-object to be created with fixed size.
- different devices to 'attach' themselves to this buffer, to facilitate
  backing storage negotiation, using dma_buf_attach() API.
- association of a file pointer with each user-buffer and associated
   allocator-defined operations on that buffer. This operation is called the
   'export' operation.
- this exported buffer-object to be shared with the other entity by asking for
   its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
   the associated exporter-defined operations.
- the exporter and user to share the scatterlist using map_dma_buf and
   unmap_dma_buf operations.

Documentation present in the patch-set gives more details.

This is based on design suggestions from many people at the mini-summits,
most notably from Arnd Bergmann , Rob Clark  
and
Daniel Vetter .

The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski , who demonstrated buffer 
sharing
between two v4l2 devices. [2]

References:
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389

Patchset based on top of 3.2-rc3, the current version can be found at

http://git.linaro.org/gitweb?p=people/sumitsemwal/linux-3.x.git
Branch: dma-buf-upstr-v2

Earlier versions:
v2 at: https://lkml.org/lkml/2011/12/2/53
v1 at: https://lkml.org/lkml/2011/10/11/92

Best regards,
~Sumit Semwal

History:

v3:
- Review comments incorporated:
   - from Konrad Rzeszutek Wilk [https://lkml.org/lkml/2011/12/3/45]
 - replaced BUG_ON with WARN_ON - various places
 - added some error-checks
 - replaced EXPORT_SYMBOL with EXPORT_SYMBOL_GPL
 - some cosmetic / documentation comments

   - from Arnd Bergmann, Daniel Vetter, Rob Clark
  [https://lkml.org/lkml/2011/12/5/321]
 - removed mmap() fop and dma_buf_op, also the sg_sync* operations, and
documented that mmap is not allowed for exported buffer
 - updated documentation to clearly state when migration is allowed
 - changed kconfig
 - some error code checks

   - from Rob Clark [https://lkml.org/lkml/2011/12/5/572]
 - update documentation to allow map_dma_buf to return -EINTR

v2:
- Review comments incorporated:
   - from Tomasz Stanislawski [https://lkml.org/lkml/2011/10/14/136]
 - kzalloc moved out of critical section
 - corrected some in-code comments

   - from Dave Airlie [https://lkml.org/lkml/2011/11/25/123]

   - from Daniel Vetter and Rob Clark [https://lkml.org/lkml/2011/11/26/53]
 - use struct sg_table in place of struct scatterlist
 - rename {get,put}_scatterlist to {map,unmap}_dma_buf
 - add new wrapper APIs dma_buf_{map,unmap}_attachment for ease of users

- documentation updates as per review comments from Randy Dunlap
 [https://lkml.org/lkml/2011/10/12/439]

v1: original


Sumit Semwal (2):
  dma-buf: Introduce dma buffer sharing mechanism
  dma-buf: Documentation for buffer sharing framework

 Documentation/dma-buf-sharing.txt |  222 
 drivers/base/Kconfig  |   10 ++
 drivers/base/Makefile |1 +
 drivers/base/dma-buf.c|  289 +
 include/linux/dma-buf.h   |  172 ++
 5 files changed, 694 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/dma-buf-sharing.txt
 create mode 100644 drivers/base/dma-buf.c
 create mode 100644 include/linux/dma-buf.h

-- 
1.7.4.1

[RFC v3 0/2] Introduce DMA buffer sharing mechanism

Hello Everyone,

This is RFC v3 for DMA buffer sharing mechanism - changes from v2 are in the
changelog below.

Various subsystems - V4L2, GPU-accessors, DRI to name a few - have felt the 
need to have a common mechanism to share memory buffers across different
devices - ARM, video hardware, GPU.

This need comes forth from a variety of use cases including cameras, image 
processing, video recorders, sound processing, DMA engines, GPU and display
buffers, and others.

This RFC is an attempt to define such a buffer sharing mechanism- it is the
result of discussions from a couple of memory-management mini-summits held by
Linaro to understand and address common needs around memory management. [1]

A new dma_buf buffer object is added, with operations and API to allow easy
sharing of this buffer object across devices.

The framework allows:
- a new buffer-object to be created with fixed size.
- different devices to 'attach' themselves to this buffer, to facilitate
  backing storage negotiation, using dma_buf_attach() API.
- association of a file pointer with each user-buffer and associated
   allocator-defined operations on that buffer. This operation is called the
   'export' operation.
- this exported buffer-object to be shared with the other entity by asking for
   its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
   the associated exporter-defined operations.
- the exporter and user to share the scatterlist using map_dma_buf and
   unmap_dma_buf operations.

Documentation present in the patch-set gives more details.

This is based on design suggestions from many people at the mini-summits,
most notably from Arnd Bergmann , Rob Clark  
and
Daniel Vetter .

The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski , who demonstrated buffer 
sharing
between two v4l2 devices. [2]

Some sample implementations and WIP for dma-buf as user and exporter are
available at [3] and [4]. [These are not being submitted for discussion /
inclusion right now, but are for reference only]

References:
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
[3]: Dave Airlie's:
   http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-prime-dmabuf
[4]: Rob Clark's:
   https://github.com/robclark/kernel-omap4/commits/dmabuf

Patchset based on top of 3.2-rc3, the current version can be found at

http://git.linaro.org/gitweb?p=people/sumitsemwal/linux-3.x.git
Branch: dma-buf-upstr-v3

Earlier versions:
v2 at: https://lkml.org/lkml/2011/12/2/53
v1 at: https://lkml.org/lkml/2011/10/11/92

Best regards,
~Sumit Semwal

History:

v3:
- Review comments incorporated:
   - from Konrad Rzeszutek Wilk [https://lkml.org/lkml/2011/12/3/45]
 - replaced BUG_ON with WARN_ON - various places
 - added some error-checks
 - replaced EXPORT_SYMBOL with EXPORT_SYMBOL_GPL
 - some cosmetic / documentation comments

   - from Arnd Bergmann, Daniel Vetter, Rob Clark
  [https://lkml.org/lkml/2011/12/5/321]
 - removed mmap() fop and dma_buf_op, also the sg_sync* operations, and
documented that mmap is not allowed for exported buffer
 - updated documentation to clearly state when migration is allowed
 - changed kconfig
 - some error code checks

   - from Rob Clark [https://lkml.org/lkml/2011/12/5/572]
 - update documentation to allow map_dma_buf to return -EINTR

v2:
- Review comments incorporated:
   - from Tomasz Stanislawski [https://lkml.org/lkml/2011/10/14/136]
 - kzalloc moved out of critical section
 - corrected some in-code comments

   - from Dave Airlie [https://lkml.org/lkml/2011/11/25/123]

   - from Daniel Vetter and Rob Clark [https://lkml.org/lkml/2011/11/26/53]
 - use struct sg_table in place of struct scatterlist
 - rename {get,put}_scatterlist to {map,unmap}_dma_buf
 - add new wrapper APIs dma_buf_{map,unmap}_attachment for ease of users

- documentation updates as per review comments from Randy Dunlap
 [https://lkml.org/lkml/2011/10/12/439]

v1: original

Sumit Semwal (2):
  dma-buf: Introduce dma buffer sharing mechanism
  dma-buf: Documentation for buffer sharing framework

 Documentation/dma-buf-sharing.txt |  222 
 drivers/base/Kconfig  |   10 ++
 drivers/base/Makefile |1 +
 drivers/base/dma-buf.c|  289 +
 include/linux/dma-buf.h   |  172 ++
 5 files changed, 694 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/dma-buf-sharing.txt
 create mode 100644 drivers/base/dma-buf.c
 create mode 100644 include/linux/dma-buf.h

-- 
1.7.4.1

[RFC v3 1/2] dma-buf: Introduce dma buffer sharing mechanism

This is the first step in defining a dma buffer sharing mechanism.

A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.

The framework allows:
- different devices to 'attach' themselves to this buffer, to facilitate
  backing storage negotiation, using dma_buf_attach() API.
- association of a file pointer with each user-buffer and associated
   allocator-defined operations on that buffer. This operation is called the
   'export' operation.
- this exported buffer-object to be shared with the other entity by asking for
   its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
   the associated exporter-defined operations.
- the exporter and user to share the scatterlist using map_dma_buf and
   unmap_dma_buf operations.

Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.

Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.

More details are there in the documentation patch.

This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann , Rob Clark  
and
Daniel Vetter .

The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski , who demonstrated buffer 
sharing
between two v4l2 devices. [2]

[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389

Signed-off-by: Sumit Semwal 
Signed-off-by: Sumit Semwal 
---
 drivers/base/Kconfig|   10 ++
 drivers/base/Makefile   |1 +
 drivers/base/dma-buf.c  |  289 +++
 include/linux/dma-buf.h |  172 
 4 files changed, 472 insertions(+), 0 deletions(-)
 create mode 100644 drivers/base/dma-buf.c
 create mode 100644 include/linux/dma-buf.h

diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 21cf46f..8a0e87f 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -174,4 +174,14 @@ config SYS_HYPERVISOR

 source "drivers/base/regmap/Kconfig"

+config DMA_SHARED_BUFFER
+   bool "Buffer framework to be shared between drivers"
+   default n
+   select ANON_INODES
+   help
+ This option enables the framework for buffer-sharing between
+ multiple drivers. A buffer is associated with a file using driver
+ APIs extension; the file's descriptor can then be passed on to other
+ driver.
+
 endmenu
diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index 99a375a..d0df046 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_DEVTMPFS)  += devtmpfs.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
 obj-$(CONFIG_ISA)  += isa.o
 obj-$(CONFIG_FW_LOADER)+= firmware_class.o
 obj-$(CONFIG_NUMA) += node.o
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
new file mode 100644
index 000..e920709
--- /dev/null
+++ b/drivers/base/dma-buf.c
@@ -0,0 +1,289 @@
+/*
+ * Framework for buffer objects that can be shared across devices/subsystems.
+ *
+ * Copyright(C) 2011 Linaro Limited. All rights reserved.
+ * Author: Sumit Semwal 
+ *
+ * Many thanks to linaro-mm-sig list, and specially
+ * Arnd Bergmann , Rob Clark  and
+ * Daniel Vetter  for their support in creation and
+ * refining of this idea.
+ *
+ * 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 .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static inline int is_dma_buf_file(struct file *);
+
+static int dma_buf_release(struct inode *inode, struct file *file)
+{
+   struct dma_buf *dmabuf;
+
+   if (!is_dma_buf_file(file))
+   return -EINVAL;
+
+   dmabuf = file->private_data;
+
+   dmabuf->ops->release(dmabuf);
+   kfree(dmabuf);
+   return 0;
+}
+
+static const struct file_operations dma_buf_fops = {
+   .release= dma_buf_release,
+};
+
+/*
+ * is_dma_buf_file - Check if struct file* is associated with dma_buf
+ */
+static inline int is_dma_buf_file(struct file *file)
+{
+   return file->f_op == _buf_fops;
+}
+
+/**
+ * dma_buf_export - Creates a new dma_buf, and associates an anon file
+ * with

[RFC v3 2/2] dma-buf: Documentation for buffer sharing framework

Add documentation for dma buffer sharing framework, explaining the
various operations, members and API of the dma buffer sharing
framework.

Signed-off-by: Sumit Semwal 
Signed-off-by: Sumit Semwal 
---
 Documentation/dma-buf-sharing.txt |  222 +
 1 files changed, 222 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/dma-buf-sharing.txt

diff --git a/Documentation/dma-buf-sharing.txt 
b/Documentation/dma-buf-sharing.txt
new file mode 100644
index 000..3a2a35f
--- /dev/null
+++ b/Documentation/dma-buf-sharing.txt
@@ -0,0 +1,222 @@
+DMA Buffer Sharing API Guide
+
+
+Sumit Semwal
+
+ 
+
+This document serves as a guide to device-driver writers on what is the dma-buf
+buffer sharing API, how to use it for exporting and using shared buffers.
+
+Any device driver which wishes to be a part of DMA buffer sharing, can do so as
+either the 'exporter' of buffers, or the 'user' of buffers.
+
+Say a driver A wants to use buffers created by driver B, then we call B as the
+exporter, and A as buffer-user.
+
+The exporter
+- implements and manages operations[1] for the buffer
+- allows other users to share the buffer by using dma_buf sharing APIs,
+- manages the details of buffer allocation,
+- decides about the actual backing storage where this allocation happens,
+- takes care of any migration of scatterlist - for all (shared) users of this
+   buffer,
+
+The buffer-user
+- is one of (many) sharing users of the buffer.
+- doesn't need to worry about how the buffer is allocated, or where.
+- needs a mechanism to get access to the scatterlist that makes up this buffer
+   in memory, mapped into its own address space, so it can access the same area
+   of memory.
+
+*IMPORTANT*: A buffer shared using the dma_buf sharing API *must not* be
+exported to user space using "mmap". [see https://lkml.org/lkml/2011/12/2/53
+for more on the discussion]
+
+The dma_buf buffer sharing API usage contains the following steps:
+
+1. Exporter announces that it wishes to export a buffer
+2. Userspace gets the file descriptor associated with the exported buffer, and
+   passes it around to potential buffer-users based on use case
+3. Each buffer-user 'connects' itself to the buffer
+4. When needed, buffer-user requests access to the buffer from exporter
+5. When finished with its use, the buffer-user notifies end-of-DMA to exporter
+6. when buffer-user is done using this buffer completely, it 'disconnects'
+   itself from the buffer.
+
+
+1. Exporter's announcement of buffer export
+
+   The buffer exporter announces its wish to export a buffer. In this, it
+   connects its own private buffer data, provides implementation for operations
+   that can be performed on the exported dma_buf, and flags for the file
+   associated with this buffer.
+
+   Interface:
+  struct dma_buf *dma_buf_export(void *priv, struct dma_buf_ops *ops,
+int flags)
+
+   If this succeeds, dma_buf_export allocates a dma_buf structure, and returns 
a
+   pointer to the same. It also associates an anonymous file with this buffer,
+   so it can be exported. On failure to allocate the dma_buf object, it returns
+   NULL.
+
+2. Userspace gets a handle to pass around to potential buffer-users
+
+   Userspace entity requests for a file-descriptor (fd) which is a handle to 
the
+   anonymous file associated with the buffer. It can then share the fd with 
other
+   drivers and/or processes.
+
+   Interface:
+  int dma_buf_fd(struct dma_buf *dmabuf)
+
+   This API installs an fd for the anonymous file associated with this buffer;
+   returns either 'fd', or error.
+
+3. Each buffer-user 'connects' itself to the buffer
+
+   Each buffer-user now gets a reference to the buffer, using the fd passed to
+   it.
+
+   Interface:
+  struct dma_buf *dma_buf_get(int fd)
+
+   This API will return a reference to the dma_buf, and increment refcount for
+   it.
+
+   After this, the buffer-user needs to attach its device with the buffer, 
which
+   helps the exporter to know of device buffer constraints.
+
+   Interface:
+  struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
+struct device *dev)
+
+   This API returns reference to an attachment structure, which is then used
+   for scatterlist operations. It will optionally call the 'attach' dma_buf
+   operation, if provided by the exporter.
+
+   The dma-buf sharing framework does the bookkeeping bits related to managing
+   the list of all attachments to a buffer.
+
+Until this stage, the buffer-exporter has the option to choose not to actually
+allocate the backing storage for this buffer, but wait for the first 
buffer-user
+to request use of buffer for allocation.
+
+
+4. When needed, buffer-user requests access to the buffer
+
+   Whenever a

allow drivers to fix kexec bus mastering hole

kexec relies on disabling bus mastering on PCI devices to block wayward DMAs
left set by the previous kernel. However the drm midlayer was enabling bus
mastering for all PCI drivers before calling into them. This meant no matter
what they did, there was always going to be a small race window. The
first patch pushes the enable into the drivers, and the second radeon patch
moves bus mastering enable to later in the driver load procedure for the kms
driver. These two along with Jerome's sanity patch should close the race 
completely.

please check the first one to make sure I didn't miss any drivers.

Dave.

[PATCH 1/2] drm: move pci bus master enable into driver.

From: Dave Airlie 

The current enabling of bus mastering in the drm midlayer allows a large
race condition under kexec. When a kexec'ed kernel re-enables bus mastering
for the GPU, previously setup dma blocks may cause writes to random pieces
of memory. On radeon the writeback mechanism can cause these sorts of issues.

This patch doesn't fix the problem, but it moves the bus master enable under
the individual drivers control so they can move enabling it until later in
their load cycle and close the race.

Fix for radeon kms driver will be in a follow-up patch.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/drm_pci.c   |2 --
 drivers/gpu/drm/gma500/psb_drv.c|2 ++
 drivers/gpu/drm/i810/i810_dma.c |2 ++
 drivers/gpu/drm/i915/i915_dma.c |2 ++
 drivers/gpu/drm/mga/mga_dma.c   |2 ++
 drivers/gpu/drm/nouveau/nouveau_state.c |2 ++
 drivers/gpu/drm/r128/r128_drv.c |1 +
 drivers/gpu/drm/radeon/radeon_cp.c  |2 ++
 drivers/gpu/drm/radeon/radeon_kms.c |2 ++
 drivers/gpu/drm/sis/sis_drv.c   |2 ++
 drivers/gpu/drm/via/via_map.c   |2 ++
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |2 ++
 12 files changed, 21 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index d4d10b7..13f3d93 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -324,8 +324,6 @@ int drm_get_pci_dev(struct pci_dev *pdev, const struct 
pci_device_id *ent,
if (ret)
goto err_g1;

-   pci_set_master(pdev);
-
dev->pdev = pdev;
dev->dev = >dev;

diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu/drm/gma500/psb_drv.c
index add3156..ff30b71 100644
--- a/drivers/gpu/drm/gma500/psb_drv.c
+++ b/drivers/gpu/drm/gma500/psb_drv.c
@@ -286,6 +286,8 @@ static int psb_driver_load(struct drm_device *dev, unsigned 
long chipset)
dev_priv->dev = dev;
dev->dev_private = (void *) dev_priv;

+   pci_set_master(dev->pdev);
+
if (!IS_PSB(dev)) {
if (pci_enable_msi(dev->pdev))
dev_warn(dev->dev, "Enabling MSI failed!\n");
diff --git a/drivers/gpu/drm/i810/i810_dma.c b/drivers/gpu/drm/i810/i810_dma.c
index 8f371e8..56989a3 100644
--- a/drivers/gpu/drm/i810/i810_dma.c
+++ b/drivers/gpu/drm/i810/i810_dma.c
@@ -1210,6 +1210,8 @@ int i810_driver_load(struct drm_device *dev, unsigned 
long flags)
dev->types[8] = _DRM_STAT_SECONDARY;
dev->types[9] = _DRM_STAT_DMA;

+   pci_set_master(dev->pdev);
+
return 0;
 }

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index a9533c5..da07a8c 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1917,6 +1917,8 @@ int i915_driver_load(struct drm_device *dev, unsigned 
long flags)
goto free_priv;
}

+   pci_set_master(dev->pdev);
+
/* overlay on gen2 is broken and can't address above 1G */
if (IS_GEN2(dev))
dma_set_coherent_mask(>pdev->dev, DMA_BIT_MASK(30));
diff --git a/drivers/gpu/drm/mga/mga_dma.c b/drivers/gpu/drm/mga/mga_dma.c
index 5ccb65de..507aa3d 100644
--- a/drivers/gpu/drm/mga/mga_dma.c
+++ b/drivers/gpu/drm/mga/mga_dma.c
@@ -403,6 +403,8 @@ int mga_driver_load(struct drm_device *dev, unsigned long 
flags)
dev_priv->usec_timeout = MGA_DEFAULT_USEC_TIMEOUT;
dev_priv->chipset = flags;

+   pci_set_master(dev->pdev);
+
dev_priv->mmio_base = pci_resource_start(dev->pdev, 1);
dev_priv->mmio_size = pci_resource_len(dev->pdev, 1);

diff --git a/drivers/gpu/drm/nouveau/nouveau_state.c 
b/drivers/gpu/drm/nouveau/nouveau_state.c
index 82478e0..37f7bba 100644
--- a/drivers/gpu/drm/nouveau/nouveau_state.c
+++ b/drivers/gpu/drm/nouveau/nouveau_state.c
@@ -1000,6 +1000,8 @@ int nouveau_load(struct drm_device *dev, unsigned long 
flags)
dev->dev_private = dev_priv;
dev_priv->dev = dev;

+   pci_set_master(dev->pdev);
+
dev_priv->flags = flags & NOUVEAU_FLAGS;

NV_DEBUG(dev, "vendor: 0x%X device: 0x%X class: 0x%X\n",
diff --git a/drivers/gpu/drm/r128/r128_drv.c b/drivers/gpu/drm/r128/r128_drv.c
index 6a5f439..88718fa 100644
--- a/drivers/gpu/drm/r128/r128_drv.c
+++ b/drivers/gpu/drm/r128/r128_drv.c
@@ -85,6 +85,7 @@ static struct drm_driver driver = {

 int r128_driver_load(struct drm_device *dev, unsigned long flags)
 {
+   pci_set_master(dev->pdev);
return drm_vblank_init(dev, 1);
 }

diff --git a/drivers/gpu/drm/radeon/radeon_cp.c 
b/drivers/gpu/drm/radeon/radeon_cp.c
index 72ae826..0ebb7d4 100644
--- a/drivers/gpu/drm/radeon/radeon_cp.c
+++ b/drivers/gpu/drm/radeon/radeon_cp.c
@@ -2115,6 +2115,8 @@ int radeon_driver_load(struct drm_device *dev, unsigned 
long flags)
break;
}

+   pci_set_master(dev->pdev);
+
if (drm_pci_device_is_agp(dev))

[PATCH 2/2] drm/radeon/kms: move pci bus master enable further into driver.

From: Dave Airlie 

This doesn't completely close the kexec hole for all drivers, but it fixes
it for some cases, by enabling PCI bus mastering later.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/radeon/evergreen.c  |2 ++
 drivers/gpu/drm/radeon/ni.c |2 ++
 drivers/gpu/drm/radeon/r100.c   |   10 ++
 drivers/gpu/drm/radeon/r300.c   |5 +
 drivers/gpu/drm/radeon/r420.c   |4 ++--
 drivers/gpu/drm/radeon/r600.c   |2 ++
 drivers/gpu/drm/radeon/radeon_kms.c |2 --
 drivers/gpu/drm/radeon/rv770.c  |2 ++
 8 files changed, 21 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index 5d51035..bb01c04 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -3001,6 +3001,8 @@ static int evergreen_startup(struct radeon_device *rdev)
/* enable pcie gen2 link */
evergreen_pcie_gen2_enable(rdev);

+   pci_set_master(rdev->pdev);
+
if (ASIC_IS_DCE5(rdev)) {
if (!rdev->me_fw || !rdev->pfp_fw || !rdev->rlc_fw || 
!rdev->mc_fw) {
r = ni_init_microcode(rdev);
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 1d1047a..60b4b9b 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1343,6 +1343,8 @@ static int cayman_startup(struct radeon_device *rdev)
/* enable pcie gen2 link */
evergreen_pcie_gen2_enable(rdev);

+   pci_set_master(rdev->pdev);
+
if (!rdev->me_fw || !rdev->pfp_fw || !rdev->rlc_fw || !rdev->mc_fw) {
r = ni_init_microcode(rdev);
if (r) {
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index dcc5b3c..567924c 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -596,6 +596,16 @@ int r100_pci_gart_init(struct radeon_device *rdev)
 void r100_enable_bm(struct radeon_device *rdev)
 {
uint32_t tmp;
+
+   pci_set_master(rdev->pdev);
+
+   if (rdev->family == CHIP_R300 ||
+   rdev->family == CHIP_R350 ||
+   rdev->family == CHIP_RV350 ||
+   rdev->family == CHIP_R423 ||
+   rdev->family == CHIP_RV410)
+   return;
+
/* Enable bus mastering */
tmp = RREG32(RADEON_BUS_CNTL) & ~RADEON_BUS_MASTER_DIS;
WREG32(RADEON_BUS_CNTL, tmp);
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index 400b26d..b1c171f 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -1372,10 +1372,7 @@ static int r300_startup(struct radeon_device *rdev)
return r;
}

-   if (rdev->family == CHIP_R300 ||
-   rdev->family == CHIP_R350 ||
-   rdev->family == CHIP_RV350)
-   r100_enable_bm(rdev);
+   r100_enable_bm(rdev);

if (rdev->flags & RADEON_IS_PCI) {
r = r100_pci_gart_enable(rdev);
diff --git a/drivers/gpu/drm/radeon/r420.c b/drivers/gpu/drm/radeon/r420.c
index 417fab8..b9123d6 100644
--- a/drivers/gpu/drm/radeon/r420.c
+++ b/drivers/gpu/drm/radeon/r420.c
@@ -400,8 +400,8 @@ int r420_init(struct radeon_device *rdev)
if (r) {
return r;
}
-   if (rdev->family == CHIP_R420)
-   r100_enable_bm(rdev);
+
+   r100_enable_bm(rdev);

if (rdev->flags & RADEON_IS_PCIE) {
r = rv370_pcie_gart_init(rdev);
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 936d107..36c9b86 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -2468,6 +2468,8 @@ int r600_startup(struct radeon_device *rdev)
/* enable pcie gen2 link */
r600_pcie_gen2_enable(rdev);

+   pci_set_master(rdev->pdev);
+
if (!rdev->me_fw || !rdev->pfp_fw || !rdev->rlc_fw) {
r = r600_init_microcode(rdev);
if (r) {
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
b/drivers/gpu/drm/radeon/radeon_kms.c
index 601b6bd..be2c122 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -57,8 +57,6 @@ int radeon_driver_load_kms(struct drm_device *dev, unsigned 
long flags)
}
dev->dev_private = (void *)rdev;

-   pci_set_master(dev->pdev);
-
/* update BUS flag */
if (drm_pci_device_is_agp(dev)) {
flags |= RADEON_IS_AGP;
diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
index e4e2132..ac1b451 100644
--- a/drivers/gpu/drm/radeon/rv770.c
+++ b/drivers/gpu/drm/radeon/rv770.c
@@ -1043,6 +1043,8 @@ static int rv770_startup(struct radeon_device *rdev)
/* enable pcie gen2 link */
rv770_pcie_gen2_enable(rdev);

+   pci_set_master(rdev->pdev);
+
if (!rdev->me_fw || !rdev->pfp_fw || !rdev->rlc_fw) {
r = r600_init_microcode(rdev);

[git pull] vmware fixes


Hi Linus,

These are just vmware fixes, Thomas sent them a couple of weeks back and 
my brain misparsed them, they are all crucial correctness fixes for vmwgfx 
and I really should have sent them on earlier.

Thanks,
Dave.

The following changes since commit 390f998509bf049019df0b078c0a6606e0d57fb4:

  Merge git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6 
(2011-12-18 14:28:31 -0800)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux drm-fixes

Jakob Bornecrantz (7):
  vmwgfx: Remove dmabuf check in present ioctl
  vmwgfx: Refactor cursor update
  vmwgfx: Add helper function to get surface or dmabuf
  vmwgfx: Refactor kms code to use vmw_user_lookup_handle helper
  vmwgfx: Do better culling of presents
  vmwgfx: Resend the cursor after legacy modeset
  vmwgfx: Clip cliprects against screen boundaries in present and dirty

Thomas Hellstrom (1):
  vmwgfx: Use the revised fifo hw version register when present

 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h  |5 +
 drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c |8 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c|   16 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c  |  394 +++---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.h  |5 +
 drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c  |   22 ++-
 drivers/gpu/drm/vmwgfx/vmwgfx_resource.c |   23 ++
 7 files changed, 318 insertions(+), 155 deletions(-)

[Bug 42883] Firefox crashes in state_tracker/st_cb_blit.c:87

https://bugs.freedesktop.org/show_bug.cgi?id=42883

--- Comment #2 from Alex Deucher  2011-12-19 06:39:32 PST 
---
Thread for reference:
http://lists.freedesktop.org/archives/mesa-dev/2011-November/015286.html

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 43941] 'BUG: scheduling while atomic' after: 'panic occurred, switching back to text console'

https://bugs.freedesktop.org/show_bug.cgi?id=43941

Michel D?nzer  changed:

   What|Removed |Added

 AssignedTo|xorg-driver-ati at lists.x.org |dri-devel at 
lists.freedesktop
   ||.org
  QAContact|xorg-team at lists.x.org   |
Summary|Driver BUG on MCE error |'BUG: scheduling while
   |report  |atomic' after: 'panic
   ||occurred, switching back to
   ||text console'
Product|xorg|DRI
Version|7.7 (2011)  |unspecified
  Component|Driver/Radeon   |DRM/Radeon

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] drm_edid: support CEA video modes

On Tue, Dec 13, 2011 at 5:47 PM, Jesse Barnes  
wrote:
> On Sun, 13 Nov 2011 01:31:35 +0100
> Christian Schmidt  wrote:
>
>> TFT/plasma televisions and projectors have become commonplace, and so
>> has the use of PCs to drive them. Add the video modes specified by an
>> EDID's CEA extension to the mode database for a connector.
>
> Dave, Christian has a few patches outstanding for CEA mode handling.
> Getting them in makes sense to me and this patch looks like it's
> structured nicely at least (I haven't checked the CEA bits against the
> specs though).
>
> Any chance we can get them included for 3.3?

I've put this patch in, but please (and reviewers too, please tell
people before acking) in future,

submit patches as per the kernel's Documentation/SubmittingPatches

This patch was attached instead of inlined, wasn't in git format (not
essential but less work for me so more patches for you).

Is there other patches outstanding if so? please resend with collected reviews.

really anything that involves me taking manual steps will generally
mean I'll just drop the patch without caring with the understanding
that whoever wants the patch merged will care more than I do.

Dave.

[Bug 43941] 'BUG: scheduling while atomic' after: 'panic occurred, switching back to text console'

https://bugs.freedesktop.org/show_bug.cgi?id=43941

--- Comment #11 from Michel D?nzer  2011-12-19 07:09:11 
PST ---
Created attachment 54573
  --> https://bugs.freedesktop.org/attachment.cgi?id=54573
Use mdelay instead of msleep

Does this patch fix the hang when switching back to console after the MCE?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 42883] Firefox crashes in state_tracker/st_cb_blit.c:87

https://bugs.freedesktop.org/show_bug.cgi?id=42883

--- Comment #3 from Stefan  2011-12-19 07:17:37 PST ---
(In reply to comment #2)

Mesa Works again. Thx.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 43861] Build error in Mesa with llvm >= r145623

https://bugs.freedesktop.org/show_bug.cgi?id=43861

--- Comment #3 from Michel D?nzer  2011-12-19 07:21:05 
PST ---
I'd still argue it's not our bug, strictly speaking: llvm-config should only
expose compiler flags absolutely necessary for building against LLVM, such as
-I<...> -D<...>, certainly not such generic ones as -pedantic. We've run into
similar issues before with other flags.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 43941] 'BUG: scheduling while atomic' after: 'panic occurred, switching back to text console'

https://bugs.freedesktop.org/show_bug.cgi?id=43941

--- Comment #12 from Drago  2011-12-19 07:39:11 PST 
---
Thanks, I will test this, but it may take some time for MCE to happen again.
I will report with the result here.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH 2/2] drm/radeon/kms: move pci bus master enable further into driver.

2011-12-19 Thread Alex Deucher

On Mon, Dec 19, 2011 at 9:16 AM, Dave Airlie  wrote:
> From: Dave Airlie 
>
> This doesn't completely close the kexec hole for all drivers, but it fixes
> it for some cases, by enabling PCI bus mastering later.
>
> Signed-off-by: Dave Airlie 
> ---
> ?drivers/gpu/drm/radeon/evergreen.c ?| ? ?2 ++
> ?drivers/gpu/drm/radeon/ni.c ? ? ? ? | ? ?2 ++
> ?drivers/gpu/drm/radeon/r100.c ? ? ? | ? 10 ++
> ?drivers/gpu/drm/radeon/r300.c ? ? ? | ? ?5 +
> ?drivers/gpu/drm/radeon/r420.c ? ? ? | ? ?4 ++--
> ?drivers/gpu/drm/radeon/r600.c ? ? ? | ? ?2 ++
> ?drivers/gpu/drm/radeon/radeon_kms.c | ? ?2 --
> ?drivers/gpu/drm/radeon/rv770.c ? ? ?| ? ?2 ++
> ?8 files changed, 21 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/evergreen.c 
> b/drivers/gpu/drm/radeon/evergreen.c
> index 5d51035..bb01c04 100644
> --- a/drivers/gpu/drm/radeon/evergreen.c
> +++ b/drivers/gpu/drm/radeon/evergreen.c
> @@ -3001,6 +3001,8 @@ static int evergreen_startup(struct radeon_device *rdev)
> ? ? ? ?/* enable pcie gen2 link */
> ? ? ? ?evergreen_pcie_gen2_enable(rdev);
>
> + ? ? ? pci_set_master(rdev->pdev);
> +
> ? ? ? ?if (ASIC_IS_DCE5(rdev)) {
> ? ? ? ? ? ? ? ?if (!rdev->me_fw || !rdev->pfp_fw || !rdev->rlc_fw || 
> !rdev->mc_fw) {
> ? ? ? ? ? ? ? ? ? ? ? ?r = ni_init_microcode(rdev);
> diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
> index 1d1047a..60b4b9b 100644
> --- a/drivers/gpu/drm/radeon/ni.c
> +++ b/drivers/gpu/drm/radeon/ni.c
> @@ -1343,6 +1343,8 @@ static int cayman_startup(struct radeon_device *rdev)
> ? ? ? ?/* enable pcie gen2 link */
> ? ? ? ?evergreen_pcie_gen2_enable(rdev);
>
> + ? ? ? pci_set_master(rdev->pdev);
> +
> ? ? ? ?if (!rdev->me_fw || !rdev->pfp_fw || !rdev->rlc_fw || !rdev->mc_fw) {
> ? ? ? ? ? ? ? ?r = ni_init_microcode(rdev);
> ? ? ? ? ? ? ? ?if (r) {
> diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
> index dcc5b3c..567924c 100644
> --- a/drivers/gpu/drm/radeon/r100.c
> +++ b/drivers/gpu/drm/radeon/r100.c
> @@ -596,6 +596,16 @@ int r100_pci_gart_init(struct radeon_device *rdev)
> ?void r100_enable_bm(struct radeon_device *rdev)
> ?{
> ? ? ? ?uint32_t tmp;
> +
> + ? ? ? pci_set_master(rdev->pdev);
> +
> + ? ? ? if (rdev->family == CHIP_R300 ||
> + ? ? ? ? ? rdev->family == CHIP_R350 ||
> + ? ? ? ? ? rdev->family == CHIP_RV350 ||
> + ? ? ? ? ? rdev->family == CHIP_R423 ||
> + ? ? ? ? ? rdev->family == CHIP_RV410)
> + ? ? ? ? ? ? ? return;
> +

The logic is reversed for some of these.
RADEON_BUS_CNTL.RADEON_BUS_MASTER_DIS only exists on AGP and RS4xx
chips.  The logic should be:

/* bail early on PCIE asics */
if (rdev->family == CHIP_RV380 ||
rdev->family == CHIP_R423 ||
rdev->family == CHIP_RV410 ||
rdev->family >= CHIP_RS600)
return;

> ? ? ? ?/* Enable bus mastering */
> ? ? ? ?tmp = RREG32(RADEON_BUS_CNTL) & ~RADEON_BUS_MASTER_DIS;
> ? ? ? ?WREG32(RADEON_BUS_CNTL, tmp);
> diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
> index 400b26d..b1c171f 100644
> --- a/drivers/gpu/drm/radeon/r300.c
> +++ b/drivers/gpu/drm/radeon/r300.c
> @@ -1372,10 +1372,7 @@ static int r300_startup(struct radeon_device *rdev)
> ? ? ? ? ? ? ? ? ? ? ? ?return r;
> ? ? ? ?}
>
> - ? ? ? if (rdev->family == CHIP_R300 ||
> - ? ? ? ? ? rdev->family == CHIP_R350 ||
> - ? ? ? ? ? rdev->family == CHIP_RV350)
> - ? ? ? ? ? ? ? r100_enable_bm(rdev);
> + ? ? ? r100_enable_bm(rdev);
>
> ? ? ? ?if (rdev->flags & RADEON_IS_PCI) {
> ? ? ? ? ? ? ? ?r = r100_pci_gart_enable(rdev);
> diff --git a/drivers/gpu/drm/radeon/r420.c b/drivers/gpu/drm/radeon/r420.c
> index 417fab8..b9123d6 100644
> --- a/drivers/gpu/drm/radeon/r420.c
> +++ b/drivers/gpu/drm/radeon/r420.c
> @@ -400,8 +400,8 @@ int r420_init(struct radeon_device *rdev)
> ? ? ? ?if (r) {
> ? ? ? ? ? ? ? ?return r;
> ? ? ? ?}
> - ? ? ? if (rdev->family == CHIP_R420)
> - ? ? ? ? ? ? ? r100_enable_bm(rdev);
> +
> + ? ? ? r100_enable_bm(rdev);
>
> ? ? ? ?if (rdev->flags & RADEON_IS_PCIE) {
> ? ? ? ? ? ? ? ?r = rv370_pcie_gart_init(rdev);
> diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
> index 936d107..36c9b86 100644
> --- a/drivers/gpu/drm/radeon/r600.c
> +++ b/drivers/gpu/drm/radeon/r600.c
> @@ -2468,6 +2468,8 @@ int r600_startup(struct radeon_device *rdev)
> ? ? ? ?/* enable pcie gen2 link */
> ? ? ? ?r600_pcie_gen2_enable(rdev);
>
> + ? ? ? pci_set_master(rdev->pdev);
> +
> ? ? ? ?if (!rdev->me_fw || !rdev->pfp_fw || !rdev->rlc_fw) {
> ? ? ? ? ? ? ? ?r = r600_init_microcode(rdev);
> ? ? ? ? ? ? ? ?if (r) {
> diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
> b/drivers/gpu/drm/radeon/radeon_kms.c
> index 601b6bd..be2c122 100644
> --- a/drivers/gpu/drm/radeon/radeon_kms.c
> +++ b/drivers/gpu/drm/radeon/radeon_kms.c
> @@ -57,8 +57,6 @@ int radeon_driver_load_kms(struct drm_device *dev, unsigned 
> long flags)
> ? ? ? ?}
> ? ? ? ?dev->dev_private = (void *)rdev;
>
> - ? ? ? pci_set_master(dev->pdev);
> -
> ? ? ? ?/* update BUS flag */
> ? ? ? ?if

DVI/VGA/HDI mess on Radeon HD 6570

Hi,

about two months ago I bought a Radeon HD 6570 with
2GB memory for my main computer and I have a single
monitor connected to it, until now via VGA D-Sub.

Last week our secondary TV died (it was 15 years old, R.I.P.)
so I bought a nice 32" LED TV which has 3 external HDMI
connectors.

The HD 6570 has one DVI-D, one HDMI and one VGA connectors
so I thought it would be fun to allow the family to watch videos
while I can also work on the computer.

Here comes my problem: no matter which connectors I use
for the monitor (DVI-D or D-Sub), if the TV is switched on,
HDMI comes up as primary display. The result: GNOME 3
workspaces are switchable on the TV but a single workspace
is visible on my monitor. This would be the perfect setup
if I can reverse the roles of the TV and the monitor.

"man radeon" had an option which I tried but didn't help:
Option "ZaphodHeads" "DVI-0,HDMI-0"

Is there any other option that does what I want?

Thanks in advance,
Zolt?n B?sz?rm?nyi

DVI/VGA/HDI mess on Radeon HD 6570

2011-12-19 Thread David Airlie


> 
> about two months ago I bought a Radeon HD 6570 with
> 2GB memory for my main computer and I have a single
> monitor connected to it, until now via VGA D-Sub.
> 
> Last week our secondary TV died (it was 15 years old, R.I.P.)
> so I bought a nice 32" LED TV which has 3 external HDMI
> connectors.
> 
> The HD 6570 has one DVI-D, one HDMI and one VGA connectors
> so I thought it would be fun to allow the family to watch videos
> while I can also work on the computer.
> 
> Here comes my problem: no matter which connectors I use
> for the monitor (DVI-D or D-Sub), if the TV is switched on,
> HDMI comes up as primary display. The result: GNOME 3
> workspaces are switchable on the TV but a single workspace
> is visible on my monitor. This would be the perfect setup
> if I can reverse the roles of the TV and the monitor.
> 
> "man radeon" had an option which I tried but didn't help:
> Option "ZaphodHeads" "DVI-0,HDMI-0"

xrandr --output DVI-0 --primary

or open the gnome display applet and drag the bar from one monitor to another.

Dave.

DVI/VGA/HDI mess on Radeon HD 6570

2011-12-19 18:14 keltez?ssel, David Airlie ?rta:
>> about two months ago I bought a Radeon HD 6570 with
>> 2GB memory for my main computer and I have a single
>> monitor connected to it, until now via VGA D-Sub.
>>
>> Last week our secondary TV died (it was 15 years old, R.I.P.)
>> so I bought a nice 32" LED TV which has 3 external HDMI
>> connectors.
>>
>> The HD 6570 has one DVI-D, one HDMI and one VGA connectors
>> so I thought it would be fun to allow the family to watch videos
>> while I can also work on the computer.
>>
>> Here comes my problem: no matter which connectors I use
>> for the monitor (DVI-D or D-Sub), if the TV is switched on,
>> HDMI comes up as primary display. The result: GNOME 3
>> workspaces are switchable on the TV but a single workspace
>> is visible on my monitor. This would be the perfect setup
>> if I can reverse the roles of the TV and the monitor.
>>
>> "man radeon" had an option which I tried but didn't help:
>> Option "ZaphodHeads" "DVI-0,HDMI-0"
> xrandr --output DVI-0 --primary
>
> or open the gnome display applet and drag the bar from one monitor to another.

Thanks.
Is this setting permanent after reboot and applies to GDM, too?

>
> Dave.
>

DVI/VGA/HDI mess on Radeon HD 6570

On Mon, 2011-12-19 at 18:19 +0100, Boszormenyi Zoltan wrote:

> Thanks.
> Is this setting permanent after reboot and applies to GDM, too?

It's stored in the session, so if there's not a "Make system default"
button in the UI, then no it won't affect gdm.

- ajax
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111219/3d77ea5a/attachment.pgp>

DVI/VGA/HDI mess on Radeon HD 6570

2011-12-19 18:42 keltez?ssel, Adam Jackson ?rta:
> On Mon, 2011-12-19 at 18:19 +0100, Boszormenyi Zoltan wrote:
>
>> Thanks.
>> Is this setting permanent after reboot and applies to GDM, too?
> It's stored in the session, so if there's not a "Make system default"
> button in the UI, then no it won't affect gdm.

Thanks. As I am logged in as my user, there's no such button.
How can I set it as the system default? It was a long time ago
when GNOME allowed a root login.

[Bug 43954] New: Some textures are not correctly rendered on HD 6950

https://bugs.freedesktop.org/show_bug.cgi?id=43954

 Bug #: 43954
   Summary: Some textures are not correctly rendered on HD 6950
Classification: Unclassified
   Product: Mesa
   Version: git
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: alexandre.f.demers at gmail.com


Created attachment 54575
  --> https://bugs.freedesktop.org/attachment.cgi?id=54575
Corrupted background

Using latest mesa, drm and kernel available. Running Ubuntu 11.11 64 bit.

With some applications like RendererFeatTest.bin64, some textures are corrupted
(see screenshot) using my HD6950. Last time I had tried, my onboard HD3200 was
displaying everything properly.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

DVI/VGA/HDI mess on Radeon HD 6570

On Mon, 2011-12-19 at 18:56 +0100, Boszormenyi Zoltan wrote:

> Thanks. As I am logged in as my user, there's no such button.
> How can I set it as the system default? It was a long time ago
> when GNOME allowed a root login.

Ideally, gnome would implement that button.

Failing that you can set Option "Primary" for the appropriate monitor
section in xorg.conf.

- ajax
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111219/4f62497b/attachment.pgp>

[PATCH] fixes to drm-next - TTM DMA code (v1)

2011-12-19 Thread Thomas Hellstrom

On 12/13/2011 05:40 PM, Konrad Rzeszutek Wilk wrote:
> On Tue, Dec 13, 2011 at 05:23:30PM +0100, Thomas Hellstrom wrote:
>
>> On 12/13/2011 05:07 PM, Jerome Glisse wrote:
>>  
>>> On Mon, Dec 12, 2011 at 03:09:26PM -0500, Konrad Rzeszutek Wilk wrote:
>>>
 Jerome pointed me to some accounting error in the DMA API debugging code 
 and
 while I can't figure it out yet, I did notice some extreme slowness - which
 is due to the nouveau driver calling the unpopulate (now that unbind +
 unpopulate are squashed) quite a lot (this is using Gnome Shell - I think 
 GNOME2
 did not have those issues but I can't recall).

 Anyhow these patches fix the 50% perf regression I saw and also some minor 
 bugs
 that I noticed.

  
>>> Gonna review those today and test them.
>>>
>>> Cheers,
>>> Jerome
>>>
>> Hi!
>>
>> I'm not whether any drivers are still using the AGP backend?
>>  
> Uh, probably they do if the cards are AGP?
> The problem I encountered was with an PCIe Nvidia card:
>
> 01:00.0 VGA compatible controller: nVidia Corporation G84 [GeForce 8600 GT] 
> (rev a1
>
>
>> Calling unpopulate / (previous clear) each time unbind is done
>> should be quite
>> inefficient with that one, as AGP sets up its own data structures
>> and copies page tables
>> on each populate. That should really be avoided unless there is a
>> good reason to have it.
>>  
> nouveau_bo_rd32 and nv50_crtc_cursor_set showed up as the callers that
> were causing the unpopulate calls. It did happen _a lot_ when I moved the
> cursor madly.
>

Konrad, Jerome
Was there a resolution to this. If the ttm_tt rewrite results in 
unpopulate being called more often than before,
and that causes performance regressions, that must be fixed as soon as 
possible.

/Thomas



> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

[Bug 43858] DVI of ATI RADEON 9200 AGP don't work

https://bugs.freedesktop.org/show_bug.cgi?id=43858

Valter  changed:

   What|Removed |Added

   Severity|normal  |critical

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 43964] A script fail to build in Penumbra Overture game

https://bugs.freedesktop.org/show_bug.cgi?id=43964

Laurent carlier  changed:

   What|Removed |Added

 AssignedTo|idr at freedesktop.org |dri-devel at 
lists.freedesktop
   ||.org
  Component|glsl-compiler   |Drivers/Gallium/r600

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

high_memory address in /proc/dri/*/vma

On Mon, Dec 19, 2011 at 4:09 PM, Ben Hutchings  wrote:
> Kees, in commit 01e2f533a234dc62d16c0d3d4fb9d71cf1ce50c3 ("drm: do not
> leak kernel addresses via /proc/dri/*/vma") you changed the logging of
> high_memory:
>
> - ? ? ? seq_printf(m, "vma use count: %d, high_memory = %p, 0x%08llx\n",
> + ? ? ? seq_printf(m, "vma use count: %d, high_memory = %pK, 0x%pK\n",
> ? ? ? ? ? ? ? ? ? atomic_read(>vma_count),
> - ? ? ? ? ? ? ? ? ?high_memory, (u64)virt_to_phys(high_memory));
> + ? ? ? ? ? ? ? ? ?high_memory, (void *)virt_to_phys(high_memory));
>
> This doesn't make sense because the physical address may be truncated
> (in theory at least).

Leaking even a truncated address is still a problem, IMO. Or do you
mean there is some side-effect causing a problem?

> I think it would make more sense to make this entire file readable by
> root only, but I don't know whether anything depends on being able to
> read it. ?Its existence is conditional on DRM_DEBUG_CODE != 0 but that
> is always true at the moment.

The kptr_restrict syscall (that controls %pK behavior) has 3 modes,
including one that hides these values even from the root user, so I
would prefer this stays as-is.

Sorry I'm being dense, but what problem is %pK causing here? I'd be
happy to help get it fixed.

-Kees

-- 
Kees Cook
ChromeOS Security

[Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism

2011-12-19 Thread Robert Morell

On Tue, Dec 13, 2011 at 07:10:02AM -0800, Arnd Bergmann wrote:
> On Monday 12 December 2011, Robert Morell wrote:
> > > 
> > > Doing a buffer sharing with something that is not GPL is not fun, as, if 
> > > any
> > > issue rises there, it would be impossible to discover if the problem is 
> > > either
> > > at the closed-source driver or at the open source one. At the time I was 
> > > using
> > > the Nvidia proprietary driver, it was very common to have unexplained 
> > > issues
> > > caused likely by bad code there at the buffer management code, causing X
> > > applications and extensions (like xv) to break.
> > >
> > > We should really make this EXPORT_SYMBOL_GPL(), in order to be able to 
> > > latter
> > > debug future share buffer issues, when needed.
> > 
> > Sorry, I don't buy this argument.  Making these exports GPL-only is not
> > likely to cause anybody to open-source their driver, but will rather
> > just cause them to use yet more closed-source code that is even less
> > debuggable than this would be, to those without access to the source.
> 
> But at least the broken module then won't be interacting with other modules
> because it cannot share any buffers.

One of the goals of this project is to unify the fragmented space of the
ARM SoC memory managers so that each vendor doesn't implement their own,
and they can all be closer to mainline.

I fear that restricting the use of this buffer sharing mechanism to GPL
drivers only will prevent that goal from being achieved, if an SoC
driver has to interact with modules that use a non-GPL license.

As a hypothetical example, consider laptops that have multiple GPUs.
Today, these ship with onboard graphics (integrated to the CPU or
chipset) along with a discrete GPU, where in many cases only the onboard
graphics can actually display to the screen.  In order for anything
rendered by the discrete GPU to be displayed, it has to be copied to
memory available for the smaller onboard graphics to texture from or
display directly.  Obviously, that's best done by sharing dma buffers
rather than bouncing them through the GPU.  It's not much of a stretch
to imagine that we'll see such systems with a Tegra CPU/GPU plus a
discrete GPU in the future; in that case, we'd want to be able to share
memory between the discrete GPU and the Tegra system.  In that scenario,
if this interface is GPL-only, we'd be unable to adopt the dma_buffer
sharing mechanism for Tegra.

(This isn't too pie-in-the-sky, either; people are already combining
Tegra with discrete GPUs:
http://blogs.nvidia.com/2011/11/world%e2%80%99s-first-arm-based-supercomputer-to-launch-in-barcelona/
)

Thanks,
Robert

high_memory address in /proc/dri/*/vma