[PATCH] drm/i915: remove duplicated include from intel_modes.c

[Daniel Vetter]

On Sun, Oct 07, 2012 at 09:26:35PM +0800, Wei Yongjun wrote:
> From: Wei Yongjun 
> 
> Remove duplicated include.
> 
> dpatch engine is used to auto generate this patch.
> (https://github.com/weiyj/dpatch)
> 
> Signed-off-by: Wei Yongjun 

Patch applied to drm-intel-next, thanks.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

question about drivers/gpu/drm/i915/dvo_ch7xxx.c

[Daniel Vetter]

On Sat, Oct 06, 2012 at 03:20:19PM +0200, Julia Lawall wrote:
> Hello,
> 
> I am looking at introducing some macros for i2c_msg initialization,
> and Ryan Mallon suggested that sometimes it could be useful to at
> the same time replace explicit lengths with the size of the
> associated buffer.  But in some cases the sizes are not the same.
> An example is as follows, in drivers/gpu/drm/i915/dvo_ch7xxx.c:
> 
> static bool ch7xxx_readb(struct intel_dvo_device *dvo, int addr,
> uint8_t *ch)
> {
> struct ch7xxx_priv *ch7xxx = dvo->dev_priv;
> struct i2c_adapter *adapter = dvo->i2c_bus;
> u8 out_buf[2];
> u8 in_buf[2];
> 
> struct i2c_msg msgs[] = {
> {
> .addr = dvo->slave_addr,
> .flags = 0,
> .len = 1,
> .buf = out_buf,
> },
> {
> .addr = dvo->slave_addr,
> .flags = I2C_M_RD,
> .len = 1,
> .buf = in_buf,
> }
> };
> 
> out_buf[0] = addr;
> out_buf[1] = 0;
> 
> if (i2c_transfer(adapter, msgs, 2) == 2) {
> *ch = in_buf[0];
> return true;
> };
> 
> if (!ch7xxx->quiet) {
> DRM_DEBUG_KMS("Unable to read register 0x%02x from 
> %s:%02x.\n",
>   addr, adapter->name, dvo->slave_addr);
> }
> return false;
> }
> 
> The buffers both have size 2, but only one byte is asked to be read
> or written.  Is there any need for the buffers to have size 2 in
> this case?

Looks like the 2 byte buffer size is just copy from writeb. And
didn't find any other reson for it not being just 1 byte.

> Unrelatedly, is it correct that ch has type uint8_t and out_buf and
> in_buf have type u8?

drm/i915 is totally confused about the (u)int*_t vs (s|t)* types
unfortunately. I think nowadays we mostly stick to _t typedefs, but not
consistenly.

Yours, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[RFC 4/4] drm: add support for raw monotonic vblank timestamps

[Daniel Vetter]

On Sat, Oct 06, 2012 at 03:49:16AM +0300, Imre Deak wrote:
> On Fri, 2012-10-05 at 18:09 -0600, Rob Clark wrote:
> > 
> > /* Called before vblank count and timestamps have
> >  * been updated for the vblank interval of flip
> >  * completion? Need to increment vblank count and
> >  * add one videorefresh duration to returned timestamp
> >  * to account for this. We assume this happened if we
> >  * get called over 0.9 frame durations after the last
> >  * timestamped vblank.
> >  *
> >  * This calculation can not be used with vrefresh rates
> >  * below 5Hz (10Hz to be on the safe side) without
> >  * promoting to 64 integers.
> >  */
> > if (10 * (timeval_to_ns() - timeval_to_ns()) >
> > 9 * crtc->framedur_ns) {
> > event->event.sequence++;
> > tvbl = ns_to_timeval(timeval_to_ns() +
> >  crtc->framedur_ns);
> > }
> 
> This has been recently removed by danvet's "drm/i915: don't frob the
> vblank ts in finish_page_flip", though not yet committed, so we can do
> away with it here too.

Yeah, I'd prefer if the common code doesn't have such hackes - this bit
here papered over some bugs in our driver code, but only partially
successfully ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH] gma500: medfield: fix potential NULL pointer dereference in mdfld_dsi_output_init()

[Wei Yongjun]

From: Wei Yongjun 

The dereference should be moved below the NULL test.

dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)

Signed-off-by: Wei Yongjun 
---
 drivers/gpu/drm/gma500/mdfld_dsi_output.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/gma500/mdfld_dsi_output.c 
b/drivers/gpu/drm/gma500/mdfld_dsi_output.c
index 32dba2a..f92932f 100644
--- a/drivers/gpu/drm/gma500/mdfld_dsi_output.c
+++ b/drivers/gpu/drm/gma500/mdfld_dsi_output.c
@@ -500,17 +500,18 @@ void mdfld_dsi_output_init(struct drm_device *dev,
struct mdfld_dsi_connector *dsi_connector;
struct drm_connector *connector;
struct mdfld_dsi_encoder *encoder;
-   struct drm_psb_private *dev_priv = dev->dev_private;
+   struct drm_psb_private *dev_priv;
struct panel_info dsi_panel_info;
u32 width_mm, height_mm;

-   dev_dbg(dev->dev, "init DSI output on pipe %d\n", pipe);
-
if (!dev || ((pipe != 0) && (pipe != 2))) {
DRM_ERROR("Invalid parameter\n");
return;
}

+   dev_dbg(dev->dev, "init DSI output on pipe %d\n", pipe);
+   dev_priv = dev->dev_private;
+
/*create a new connetor*/
dsi_connector = kzalloc(sizeof(struct mdfld_dsi_connector), GFP_KERNEL);
if (!dsi_connector) {

[PATCH] drm/nouveau: remove duplicated include from nouveau_drm.c

[Wei Yongjun]

From: Wei Yongjun 

Remove duplicated include.

dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)

Signed-off-by: Wei Yongjun 
---
 drivers/gpu/drm/nouveau/nouveau_drm.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index ccae8c2..f5c8ccf 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -49,7 +49,6 @@
 #include "nouveau_fbcon.h"
 #include "nouveau_fence.h"

-#include "nouveau_ttm.h"

 MODULE_PARM_DESC(config, "option string to pass to driver core");
 static char *nouveau_config;

[PATCH] drm/i915: remove duplicated include from intel_modes.c

[Wei Yongjun]

From: Wei Yongjun 

Remove duplicated include.

dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)

Signed-off-by: Wei Yongjun 
---
 drivers/gpu/drm/i915/intel_modes.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_modes.c 
b/drivers/gpu/drm/i915/intel_modes.c
index cabd84b..8c97b7a 100644
--- a/drivers/gpu/drm/i915/intel_modes.c
+++ b/drivers/gpu/drm/i915/intel_modes.c
@@ -28,7 +28,6 @@
 #include 
 #include 
 #include 
-#include 
 #include "intel_drv.h"
 #include "i915_drv.h"

[3.2.y] drm/i915: add Ivy Bridge GT2 Server entries

[Maik Zumstrull]

On Sun, Oct 7, 2012 at 7:44 PM, Jonathan Nieder  wrote:

> X should have been able to start using the vesa or fbdev driver.  I'm
> not sure why that doesn't happen --- do you have an Xorg log from
> booting and trying to start X with a 3.2.y kernel without the
> "drm/i915: add Ivy Bridge GT2 Server entries" patch?

No, and it would be a bit of fiddling to get one. Like I said, I've
modified that system with a graphics card since. If it's important, I
could get it done, but probably not next week, I'll be traveling and
otherwise busy.

[PATCH] drm: fix returning -EINVAL on setmaster if another master is active

[David Herrmann]

We link every DRM "file_priv" to a "drm_master" structure. Currently, the
drmSetMaster() call returns 0 when there is _any_ active master associated
with the "drm_master" structure of the calling "file_priv". This means,
that after drmSetMaster() we are not guaranteed to be DRM-Master and might
not be able to perform mode-setting.

A way to reproduce this is by starting weston with the DRM backend from
within an X-console (eg., xterm). Because the xserver's "drm_master" is
currently active, weston is assigned to the same master but is inactive
because its VT is inactive and the xserver is still active. But when
"fake-activating" weston, it calls drmSetMaster(). With current behavior
this returns "0/success" and weston thinks that it is DRM-Master, even
though it is not (as the xserver is still DRM-Master).
Expected behavior would be drmSetMaster() to return -EINVAL, because the
xserver is still DRM-Master. This patch changes exactly that.

The only way this bogus behavior would be useful is for clients to check
whether their associated "drm_master" is currently the active DRM-Master.
But this logic fails if no DRM-Master is currently active at all. Because
then the client itself would become DRM-Master (if it is root) and this
makes this whole thing useles.

Also note that the second "if-condition":
  file_priv->minor->master != file_priv->master
is always true and can be skipped.

Signed-off-by: David Herrmann 
---
Note:
Note that this only removes the "if-clause". The code that performs the
setmaster() is actually left unchanged but makes the patch look scarier than it
really is.

 drivers/gpu/drm/drm_stub.c | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index c236fd2..581e61d 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -221,20 +221,20 @@ int drm_setmaster_ioctl(struct drm_device *dev, void 
*data,
if (!file_priv->master)
return -EINVAL;

-   if (!file_priv->minor->master &&
-   file_priv->minor->master != file_priv->master) {
-   mutex_lock(>struct_mutex);
-   file_priv->minor->master = drm_master_get(file_priv->master);
-   file_priv->is_master = 1;
-   if (dev->driver->master_set) {
-   ret = dev->driver->master_set(dev, file_priv, false);
-   if (unlikely(ret != 0)) {
-   file_priv->is_master = 0;
-   drm_master_put(_priv->minor->master);
-   }
+   if (file_priv->minor->master)
+   return -EINVAL;
+
+   mutex_lock(>struct_mutex);
+   file_priv->minor->master = drm_master_get(file_priv->master);
+   file_priv->is_master = 1;
+   if (dev->driver->master_set) {
+   ret = dev->driver->master_set(dev, file_priv, false);
+   if (unlikely(ret != 0)) {
+   file_priv->is_master = 0;
+   drm_master_put(_priv->minor->master);
}
-   mutex_unlock(>struct_mutex);
}
+   mutex_unlock(>struct_mutex);

return 0;
 }
-- 
1.7.12.2

[Intel-gfx] [3.2.y] drm/i915: add Ivy Bridge GT2 Server entries

[Maik Zumstrull]

On Sun, Oct 7, 2012 at 7:26 PM, Julien Cristau  wrote:
> On Mon, Oct  1, 2012 at 03:24:32 -0700, Jonathan Nieder wrote:
>
>>  - without this patch, modern X errors out instead of starting,
>>because the intel driver requires kms.  (In a hypothetical better
>>world, userspace would know to fall back to vesa or something.)
>>
> I'd expect X to start with vesa or fbdev, rather than erroring out?

There's a corner case when X and the kernel know about the graphics
device, but libdrm doesn't, in which case an assertion in the X driver
fails and X doesn't start. Upstream libdrm has been okay for a few
releases. A bug against Debian libdrm has been open for a while, but
they seem to disagree about the importance, nothing has happened. In
fairness, this device seems to be rare so far. I'm not really using
mine any more, I put an extra graphics card in the box.

[Intel-gfx] [3.2.y] drm/i915: add Ivy Bridge GT2 Server entries

[Julien Cristau]

On Mon, Oct  1, 2012 at 03:24:32 -0700, Jonathan Nieder wrote:

>  - without this patch, modern X errors out instead of starting,
>because the intel driver requires kms.  (In a hypothetical better
>world, userspace would know to fall back to vesa or something.)
> 
I'd expect X to start with vesa or fbdev, rather than erroring out?

Cheers,
Julien

[RFC libdrm] freedreno: add freedreno DRM

[Rob Clark]

The libdrm_freedreno helper layer for use by xf86-video-freedreno,
fdre (freedreno r/e library and tests for driving gpu), and eventual
gallium driver for the Adreno GPU.  This uses the msm gpu driver
from QCOM's android kernel tree.

Note that current msm kernel driver is a bit strange.  It provides a
DRM interface for GEM, which is basically sufficient to have DRI2
working.  But it does not provide KMS.  And interface to 2d and 3d
cores is via different other devices (/dev/kgsl-*).  This is not
quite how I'd write a DRM driver, but at this stage it is useful for
xf86-video-freedreno and fdre (and eventual gallium driver) to be
able to work on existing kernel driver from QCOM, to allow to
capture cmdstream dumps from the binary blob drivers without having
to reboot.  So libdrm_freedreno attempts to hide most of the crazy.
The intention is that when there is a proper kernel driver, it will
be mostly just changes in libdrm_freedreno to adapt the gallium
driver and xf86-video-freedreno (ignoring the fbdev->KMS changes).

So don't look at freedreno as an example of how to write a libdrm
module or a DRM driver.. it is just an attempt to paper over a non-
standard kernel driver architecture.

Signed-off-by: Rob Clark 
---
 .gitignore   |1 +
 Makefile.am  |6 +-
 configure.ac |   13 +
 freedreno/Makefile.am|   19 ++
 freedreno/README |   16 ++
 freedreno/freedreno_bo.c |  229 +
 freedreno/freedreno_device.c |   45 
 freedreno/freedreno_drmif.h  |   97 +++
 freedreno/freedreno_pipe.c   |  163 
 freedreno/freedreno_priv.h   |   90 +++
 freedreno/freedreno_ringbuffer.c |  123 +
 freedreno/freedreno_ringbuffer.h |   75 ++
 freedreno/kgsl_drm.h |  192 ++
 freedreno/libdrm_freedreno.pc.in |   11 +
 freedreno/msm_kgsl.h |  519 ++
 15 files changed, 1598 insertions(+), 1 deletion(-)
 create mode 100644 freedreno/Makefile.am
 create mode 100644 freedreno/README
 create mode 100644 freedreno/freedreno_bo.c
 create mode 100644 freedreno/freedreno_device.c
 create mode 100644 freedreno/freedreno_drmif.h
 create mode 100644 freedreno/freedreno_pipe.c
 create mode 100644 freedreno/freedreno_priv.h
 create mode 100644 freedreno/freedreno_ringbuffer.c
 create mode 100644 freedreno/freedreno_ringbuffer.h
 create mode 100644 freedreno/kgsl_drm.h
 create mode 100644 freedreno/libdrm_freedreno.pc.in
 create mode 100644 freedreno/msm_kgsl.h

diff --git a/.gitignore b/.gitignore
index 243457e..a20a3eb 100644
--- a/.gitignore
+++ b/.gitignore
@@ -42,6 +42,7 @@ libdrm.pc
 libdrm_intel.pc
 libdrm_nouveau.pc
 libdrm_radeon.pc
+libdrm_freedreno.pc
 libkms.pc
 libtool
 ltmain.sh
diff --git a/Makefile.am b/Makefile.am
index 8ecd9d9..ebf2ae2 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -49,7 +49,11 @@ if HAVE_EXYNOS
 EXYNOS_SUBDIR = exynos
 endif

-SUBDIRS = . $(LIBKMS_SUBDIR) $(INTEL_SUBDIR) $(NOUVEAU_SUBDIR) 
$(RADEON_SUBDIR) $(OMAP_SUBDIR) $(EXYNOS_SUBDIR) tests include man
+if HAVE_FREEDRENO
+FREEDRENO_SUBDIR = freedreno
+endif
+
+SUBDIRS = . $(LIBKMS_SUBDIR) $(INTEL_SUBDIR) $(NOUVEAU_SUBDIR) 
$(RADEON_SUBDIR) $(OMAP_SUBDIR) $(EXYNOS_SUBDIR) $(FREEDRENO_SUBDIR) tests 
include man

 libdrm_la_LTLIBRARIES = libdrm.la
 libdrm_ladir = $(libdir)
diff --git a/configure.ac b/configure.ac
index 290362c..8ce6011 100644
--- a/configure.ac
+++ b/configure.ac
@@ -114,6 +114,11 @@ AC_ARG_ENABLE(exynos-experimental-api,
  [Enable support for EXYNOS's experimental API (default: 
disabled)]),
  [EXYNOS=$enableval], [EXYNOS=no])

+AC_ARG_ENABLE(freedreno-experimental-api,
+ AS_HELP_STRING([--enable-freedreno-experimental-api],
+ [Enable support for freedreno's experimental API (default: 
disabled)]),
+ [FREEDRENO=$enableval], [FREEDRENO=no])
+
 dnl ===
 dnl check compiler flags
 AC_DEFUN([LIBDRM_CC_TRY_FLAG], [
@@ -222,6 +227,11 @@ if test "x$EXYNOS" = xyes; then
AC_DEFINE(HAVE_EXYNOS, 1, [Have EXYNOS support])
 fi

+AM_CONDITIONAL(HAVE_FREEDRENO, [test "x$FREEDRENO" = xyes])
+if test "x$FREEDRENO" = xyes; then
+   AC_DEFINE(HAVE_FREEDRENO, 1, [Have freedreno support])
+fi
+
 PKG_CHECK_MODULES(CAIRO, cairo, [HAVE_CAIRO=yes], [HAVE_CAIRO=no])
 if test "x$HAVE_CAIRO" = xyes; then
AC_DEFINE(HAVE_CAIRO, 1, [Have cairo support])
@@ -346,6 +356,8 @@ AC_CONFIG_FILES([
omap/libdrm_omap.pc
exynos/Makefile
exynos/libdrm_exynos.pc
+   freedreno/Makefile
+   freedreno/libdrm_freedreno.pc
tests/Makefile
tests/modeprint/Makefile
tests/modetest/Makefile
@@ -368,4 +380,5 @@ echo "  Radeon API $RADEON"
 echo "  Nouveau API$NOUVEAU"
 echo "  OMAP API   $OMAP"
 echo "  EXYNOS API $EXYNOS"
+echo "  Freedreno API  

[PATCH 2/5] fence: dma-buf cross-device synchronization (v9)

[Maarten Lankhorst]

Op 28-09-12 14:42, Maarten Lankhorst schreef:
> A fence can be attached to a buffer which is being filled or consumed
> by hw, to allow userspace to pass the buffer without waiting to another
> device.  For example, userspace can call page_flip ioctl to display the
> next frame of graphics after kicking the GPU but while the GPU is still
> rendering.  The display device sharing the buffer with the GPU would
> attach a callback to get notified when the GPU's rendering-complete IRQ
> fires, to update the scan-out address of the display, without having to
> wake up userspace.
>
> A fence is transient, one-shot deal.  It is allocated and attached
> to one or more dma-buf's.  When the one that attached it is done, with
> the pending operation, it can signal the fence:
>   + fence_signal()
>
> To have a rough approximation whether a fence is fired, call:
>   + fence_is_signaled()
>
> The dma-buf-mgr handles tracking, and waiting on, the fences associated
> with a dma-buf.
>
> The one pending on the fence can add an async callback:
>   + fence_add_callback()
>
> The callback can optionally be cancelled with:
>   + fence_remove_callback()
>
> To wait synchronously, optionally with a timeout:
>   + fence_wait()
>   + fence_wait_timeout()
>
...

Implementing this makes the locking feel weird, instead of abusing
fence->event_queue.lock I think it would make sense to remove this part 
entirely,
and have a simply linked list plus a pointer to a spinlock.

enable_signaling should be called with this spinlock held. This way,
the enable_signaling callback would be easier to implement
and doesn't have to double check for races as much in there.

Also __fence_signal should be exported which would be the
same as fence_signal, but without taking the spinlock as separate
step, so it can be called with the spinlock held.

How do you feel about these proposed changes?

~Maarten

[3.2.y] drm/i915: add Ivy Bridge GT2 Server entries

[Ben Hutchings]

On Sun, 2012-10-07 at 15:11 +0100, Chris Wilson wrote:
> On Sun, 07 Oct 2012 15:01:17 +0100, Ben Hutchings  
> wrote:
> > On Mon, 2012-10-01 at 03:24 -0700, Jonathan Nieder wrote:
> > > Hi Ben,
> > > 
> > > Please consider
> > > 
> > >   cc22a938fc1d drm/i915: add Ivy Bridge GT2 Server entries, 2012-03-29
> > > 
> > > for application to the 3.2.y tree.  It adds a PCI id to the i915
> > > driver, making kms work.  It was applied during the 3.4-rc2 cycle, so
> > > newer stable kernels don't need it.
> > > 
> > > Maik Zumstrull tried it[1] on top of 3.2.30 and found it to work ok
> > > (thanks!).
> > > 
> > > Note that pre-2.4.34 versions of libdrm don't cope well with that
> > > card, with or without this patch:
> > [...]
> > >  - with this patch, and with libdrm lacking 2.4.34~22 and 2.4.38~10,
> > >X freezes at startup.
> > > 
> > > "No regressions" means you probably shouldn't take this patch without
> > > a safety to work around the old X userspace,
> > [...]
> > 
> > Then this workaround is also required in mainline.  And once that's
> > done, I can take both patches.
> 
> The bugs Jonathan mentions are both in userspace packages; not
> recognising the existence of Bromlow, and then misprogramming it.

Yes, I understand that.

> There
> are no other kernel patches required specifically for this chipset,
> afaik.

If upgrading the kernel currently triggers a (more) serious bug in
typical userland then the kernel should work around that.  If I've
misunderstood, and the userland behaviour is roughly equally broken with
or without this change, then I'll be happy to take it.

Ben.

-- 
Ben Hutchings
You can't have everything.  Where would you put it?
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121007/74eabf1e/attachment.pgp>

[PATCHv9 18/25] v4l: add buffer exporting via dmabuf

[Hans Verkuil]

On Sun October 7 2012 15:38:30 Laurent Pinchart wrote:
> Hi Hans,
> 
> On Friday 05 October 2012 10:55:40 Hans Verkuil wrote:
> > On Tue October 2 2012 16:27:29 Tomasz Stanislawski wrote:
> > > This patch adds extension to V4L2 api. It allow to export a mmap buffer as
> > > file descriptor. New ioctl VIDIOC_EXPBUF is added. It takes a buffer
> > > offset used by mmap and return a file descriptor on success.
> > > 
> > > Signed-off-by: Tomasz Stanislawski 
> > > Signed-off-by: Kyungmin Park 
> 
> [snip]
> 
> > > diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
> > > index e04a73e..f429b6a 100644
> > > --- a/include/linux/videodev2.h
> > > +++ b/include/linux/videodev2.h
> > > @@ -688,6 +688,33 @@ struct v4l2_buffer {
> > > 
> > >  #define V4L2_BUF_FLAG_NO_CACHE_INVALIDATE0x0800
> > >  #define V4L2_BUF_FLAG_NO_CACHE_CLEAN 0x1000
> > > 
> > > +/**
> > > + * struct v4l2_exportbuffer - export of video buffer as DMABUF file
> > > descriptor + *
> > > + * @fd:  file descriptor associated with DMABUF (set by driver)
> > > + * @flags:   flags for newly created file, currently only O_CLOEXEC 
> > > is
> > > + *   supported, refer to manual of open syscall for more 
> > > details
> > > + * @index:   id number of the buffer
> > > + * @type:enum v4l2_buf_type; buffer type (type == *_MPLANE for
> > > + *   multiplanar buffers);
> > > + * @plane:   index of the plane to be exported, 0 for single plane 
> > > queues
> > > + *
> > > + * Contains data used for exporting a video buffer as DMABUF file
> > > descriptor. + * The buffer is identified by a 'cookie' returned by
> > > VIDIOC_QUERYBUF + * (identical to the cookie used to mmap() the buffer to
> > > userspace). All + * reserved fields must be set to zero. The field
> > > reserved0 is expected to + * become a structure 'type' allowing an
> > > alternative layout of the structure + * content. Therefore this field
> > > should not be used for any other extensions. + */
> > > +struct v4l2_exportbuffer {
> > > + __s32   fd;
> > > + __u32   flags;
> > > + __u32   type; /* enum v4l2_buf_type */
> > > + __u32   index;
> > > + __u32   plane;
> > 
> > As suggested in my comments in the previous patch, I think it is a more
> > natural order to have the type/index/plane fields first in this struct.
> > 
> > Actually, I think that flags should also come before fd:
> > 
> > struct v4l2_exportbuffer {
> > __u32   type; /* enum v4l2_buf_type */
> > __u32   index;
> > __u32   plane;
> > __u32   flags;
> > __s32   fd;
> > __u32   reserved[11];
> > };
> 
> It would indeed feel more natural, but putting them right before the reserved 
> fields allows creating an anonymous union around type, index and plane and 
> extending it with reserved fields if needed. That's (at least to my 
> understanding) the rationale behind the current structure layout.

The anonymous union argument makes no sense to me, to be honest. It's standard
practice within V4L2 to have the IN fields first, then the OUT fields, followed
by reserved fields for future expansion. Should we ever need a, say, sub-plane
index (whatever that might be), then we can use one of the reserved fields.

Regards,

Hans

> 
> > > + __u32   reserved[11];
> > > +};
> > > +
> > > 
> > >  /*
> > >  
> > >   *   O V E R L A Y   P R E V I E W
> > >   */
> 
> 

[PATCHv9 22/25] v4l: vb2-dma-contig: fail if user ptr buffer is not correctly aligned

[Laurent Pinchart]

Hi Tomasz,

Thanks for the patch.

On Tuesday 02 October 2012 16:27:33 Tomasz Stanislawski wrote:
> From: Marek Szyprowski 
> 
> The DMA transfer must be aligned to a specific value. If userptr is not
> aligned to DMA requirements then unexpected corruptions of the memory may
> occur before or after a buffer.  To prevent such situations, all unligned
> userptr buffers are rejected at VIDIOC_QBUF.
> 
> Signed-off-by: Marek Szyprowski 
> ---
>  drivers/media/video/videobuf2-dma-contig.c |7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/media/video/videobuf2-dma-contig.c
> b/drivers/media/video/videobuf2-dma-contig.c index b4d287a..55f8c80 100644
> --- a/drivers/media/video/videobuf2-dma-contig.c
> +++ b/drivers/media/video/videobuf2-dma-contig.c
> @@ -494,6 +494,13 @@ static void *vb2_dc_get_userptr(void *alloc_ctx,
> unsigned long vaddr, struct vm_area_struct *vma;
>   struct sg_table *sgt;
>   unsigned long contig_size;
> + unsigned long dma_align = dma_get_cache_alignment();
> +
> + /* Only cache aligned DMA transfers are reliable */
> + if (!IS_ALIGNED(vaddr | size, dma_align)) {
> + pr_err("user data must be aligned to %lu bytes\n", dma_align);
> + return ERR_PTR(-EINVAL);

Do you think EFAULT would be more descriptive ? EINVAL is already used quite 
extensively. We could then possibly turn pr_err() into pr_dbg() to avoid 
flooding the kernel log.

> + }
> 
>   buf = kzalloc(sizeof *buf, GFP_KERNEL);
>   if (!buf)

-- 
Regards,

Laurent Pinchart

[PATCH 2/2 v6] of: add generic videomode description

[Laurent Pinchart]

Hi Steffen,

On Friday 05 October 2012 17:51:21 Steffen Trumtrar wrote:
> On Thu, Oct 04, 2012 at 12:51:00PM -0600, Stephen Warren wrote:
> > On 10/04/2012 11:59 AM, Steffen Trumtrar wrote:
> > > Get videomode from devicetree in a format appropriate for the
> > > backend. drm_display_mode and fb_videomode are supported atm.
> > > Uses the display signal timings from of_display_timings
> > > 
> > > +++ b/drivers/of/of_videomode.c
> > > 
> > > +int videomode_from_timing(struct display_timings *disp, struct
> > > videomode *vm,
> > > 
> > > + st = display_timings_get(disp, index);
> > > +
> > > + if (!st) {
> > 
> > It's a little odd to leave a blank line between those two lines.
> 
> Hm, well okay. That can be remedied
> 
> > Only half of the code in this file seems OF-related; the routines to
> > convert a timing to a videomode or drm display mode seem like they'd be
> > useful outside device tree, so I wonder if putting them into
> > of_videomode.c is the correct thing to do. Still, it's probably not a
> > big deal.
> 
> I am not sure, what the appropriate way to do this is. I can split it up
> (again).

I think it would make sense to move them to their respective subsystems.

-- 
Regards,

Laurent Pinchart

[PATCHv9 18/25] v4l: add buffer exporting via dmabuf

[Laurent Pinchart]

Hi Hans,

On Friday 05 October 2012 10:55:40 Hans Verkuil wrote:
> On Tue October 2 2012 16:27:29 Tomasz Stanislawski wrote:
> > This patch adds extension to V4L2 api. It allow to export a mmap buffer as
> > file descriptor. New ioctl VIDIOC_EXPBUF is added. It takes a buffer
> > offset used by mmap and return a file descriptor on success.
> > 
> > Signed-off-by: Tomasz Stanislawski 
> > Signed-off-by: Kyungmin Park 

[snip]

> > diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
> > index e04a73e..f429b6a 100644
> > --- a/include/linux/videodev2.h
> > +++ b/include/linux/videodev2.h
> > @@ -688,6 +688,33 @@ struct v4l2_buffer {
> > 
> >  #define V4L2_BUF_FLAG_NO_CACHE_INVALIDATE  0x0800
> >  #define V4L2_BUF_FLAG_NO_CACHE_CLEAN   0x1000
> > 
> > +/**
> > + * struct v4l2_exportbuffer - export of video buffer as DMABUF file
> > descriptor + *
> > + * @fd:file descriptor associated with DMABUF (set by driver)
> > + * @flags: flags for newly created file, currently only O_CLOEXEC is
> > + * supported, refer to manual of open syscall for more details
> > + * @index: id number of the buffer
> > + * @type:  enum v4l2_buf_type; buffer type (type == *_MPLANE for
> > + * multiplanar buffers);
> > + * @plane: index of the plane to be exported, 0 for single plane queues
> > + *
> > + * Contains data used for exporting a video buffer as DMABUF file
> > descriptor. + * The buffer is identified by a 'cookie' returned by
> > VIDIOC_QUERYBUF + * (identical to the cookie used to mmap() the buffer to
> > userspace). All + * reserved fields must be set to zero. The field
> > reserved0 is expected to + * become a structure 'type' allowing an
> > alternative layout of the structure + * content. Therefore this field
> > should not be used for any other extensions. + */
> > +struct v4l2_exportbuffer {
> > +   __s32   fd;
> > +   __u32   flags;
> > +   __u32   type; /* enum v4l2_buf_type */
> > +   __u32   index;
> > +   __u32   plane;
> 
> As suggested in my comments in the previous patch, I think it is a more
> natural order to have the type/index/plane fields first in this struct.
> 
> Actually, I think that flags should also come before fd:
> 
> struct v4l2_exportbuffer {
>   __u32   type; /* enum v4l2_buf_type */
>   __u32   index;
>   __u32   plane;
>   __u32   flags;
>   __s32   fd;
>   __u32   reserved[11];
> };

It would indeed feel more natural, but putting them right before the reserved 
fields allows creating an anonymous union around type, index and plane and 
extending it with reserved fields if needed. That's (at least to my 
understanding) the rationale behind the current structure layout.

> > +   __u32   reserved[11];
> > +};
> > +
> > 
> >  /*
> >  
> >   * O V E R L A Y   P R E V I E W
> >   */

-- 
Regards,

Laurent Pinchart

[PATCH 1/2 v6] of: add helper to parse display timings

[Laurent Pinchart]

Hi Steffen,

On Friday 05 October 2012 18:38:58 Steffen Trumtrar wrote:
> On Fri, Oct 05, 2012 at 10:21:37AM -0600, Stephen Warren wrote:
> > On 10/05/2012 10:16 AM, Steffen Trumtrar wrote:
> > > On Thu, Oct 04, 2012 at 12:47:16PM -0600, Stephen Warren wrote:
> > >> On 10/04/2012 11:59 AM, Steffen Trumtrar wrote:
> > ...
> > 
> > >>> +   for_each_child_of_node(timings_np, entry) {
> > >>> +   struct signal_timing *st;
> > >>> +
> > >>> +   st = of_get_display_timing(entry);
> > >>> +
> > >>> +   if (!st)
> > >>> +   continue;
> > >> 
> > >> I wonder if that shouldn't be an error?
> > > 
> > > In the sense of a pr_err not a -EINVAL I presume?! It is a little bit
> > > quiet in case of a faulty spec, that is right.
> > 
> > I did mean return an error; if we try to parse something and can't,
> > shouldn't we return an error?
> > 
> > I suppose it may be possible to limp on and use whatever subset of modes
> > could be parsed and drop the others, which is what this code does, but
> > the code after the loop would definitely return an error if zero timings
> > were parseable.
> 
> If a display supports multiple modes, I think it is better to have a working
> mode (even if it is not the preferred one) than have none at all.
> If there is no mode at all, that should be an error, right.

If we fail completely in case of an error, DT writers will notice their bugs. 
If we ignore errors silently they won't, and we'll end up with buggy DTs (or, 
to be accurate, even more buggy DTs :-)). I'd rather fail completely in the 
first implementation and add workarounds later only if we need to.

-- 
Regards,

Laurent Pinchart

[PATCHv9 21/25] v4l: vb2-dma-contig: add reference counting for a device from allocator context

[Laurent Pinchart]

Hi Tomasz,

Thanks for the patch.

On Tuesday 02 October 2012 16:27:32 Tomasz Stanislawski wrote:
> This patch adds taking reference to the device for MMAP buffers.
> 
> Such buffers, may be exported using DMABUF mechanism. If the driver that
> created a queue is unloaded then the queue is released, the device might be
> released too.  However, buffers cannot be released if they are referenced by
> DMABUF descriptor(s). The device pointer kept in a buffer must be valid for
> the whole buffer's lifetime. Therefore MMAP buffers should take a reference
> to the device to avoid risk of dangling pointers.
> 
> Signed-off-by: Tomasz Stanislawski 
>
> ---
>  drivers/media/video/videobuf2-dma-contig.c |5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/media/video/videobuf2-dma-contig.c
> b/drivers/media/video/videobuf2-dma-contig.c index b138b5c..b4d287a 100644
> --- a/drivers/media/video/videobuf2-dma-contig.c
> +++ b/drivers/media/video/videobuf2-dma-contig.c
> @@ -148,6 +148,7 @@ static void vb2_dc_put(void *buf_priv)
>   kfree(buf->sgt_base);
>   }
>   dma_free_coherent(buf->dev, buf->size, buf->vaddr, buf->dma_addr);
> + put_device(buf->dev);
>   kfree(buf);
>  }
> 
> @@ -161,9 +162,13 @@ static void *vb2_dc_alloc(void *alloc_ctx, unsigned
> long size) if (!buf)
>   return ERR_PTR(-ENOMEM);
> 
> + /* prevent the device from release while the buffer is exported */
> + get_device(dev);
> +

What about moving this below the dma_alloc_coherent() call ? You could then 
avoid the put_device() call in the error path.

>   buf->vaddr = dma_alloc_coherent(dev, size, >dma_addr, GFP_KERNEL);
>   if (!buf->vaddr) {
>   dev_err(dev, "dma_alloc_coherent of size %ld failed\n", size);
> + put_device(dev);
>   kfree(buf);
>   return ERR_PTR(-ENOMEM);
>   }

Something like

-   buf->dev = dev;
+   buf->dev = get_device(dev);
buf->size = size

-- 
Regards,

Laurent Pinchart

[PATCHv9 20/25] v4l: vb2-dma-contig: add support for DMABUF exporting

[Laurent Pinchart]

Hi Tomasz,

Thanks for the patch.

On Tuesday 02 October 2012 16:27:31 Tomasz Stanislawski wrote:
> This patch adds support for exporting a dma-contig buffer using
> DMABUF interface.
> 
> Signed-off-by: Tomasz Stanislawski 
> Signed-off-by: Kyungmin Park 

Acked-by: Laurent Pinchart 

> ---
>  drivers/media/video/videobuf2-dma-contig.c |  200 +
>  1 file changed, 200 insertions(+)
> 
> diff --git a/drivers/media/video/videobuf2-dma-contig.c
> b/drivers/media/video/videobuf2-dma-contig.c index 0e065ce..b138b5c 100644
> --- a/drivers/media/video/videobuf2-dma-contig.c
> +++ b/drivers/media/video/videobuf2-dma-contig.c
> @@ -36,6 +36,7 @@ struct vb2_dc_buf {
>   /* MMAP related */
>   struct vb2_vmarea_handler   handler;
>   atomic_trefcount;
> + struct sg_table *sgt_base;
> 
>   /* USERPTR related */
>   struct vm_area_struct   *vma;
> @@ -142,6 +143,10 @@ static void vb2_dc_put(void *buf_priv)
>   if (!atomic_dec_and_test(>refcount))
>   return;
> 
> + if (buf->sgt_base) {
> + sg_free_table(buf->sgt_base);
> + kfree(buf->sgt_base);
> + }
>   dma_free_coherent(buf->dev, buf->size, buf->vaddr, buf->dma_addr);
>   kfree(buf);
>  }
> @@ -213,6 +218,200 @@ static int vb2_dc_mmap(void *buf_priv, struct
> vm_area_struct *vma) }
> 
>  /*/
> +/* DMABUF ops for exporters  */
> +/*/
> +
> +struct vb2_dc_attachment {
> + struct sg_table sgt;
> + enum dma_data_direction dir;
> +};
> +
> +static int vb2_dc_dmabuf_ops_attach(struct dma_buf *dbuf, struct device
> *dev, +   struct dma_buf_attachment *dbuf_attach)
> +{
> + struct vb2_dc_attachment *attach;
> + unsigned int i;
> + struct scatterlist *rd, *wr;
> + struct sg_table *sgt;
> + struct vb2_dc_buf *buf = dbuf->priv;
> + int ret;
> +
> + attach = kzalloc(sizeof(*attach), GFP_KERNEL);
> + if (!attach)
> + return -ENOMEM;
> +
> + sgt = >sgt;
> + /* Copy the buf->base_sgt scatter list to the attachment, as we can't
> +  * map the same scatter list to multiple attachments at the same time.
> +  */
> + ret = sg_alloc_table(sgt, buf->sgt_base->orig_nents, GFP_KERNEL);
> + if (ret) {
> + kfree(attach);
> + return -ENOMEM;
> + }
> +
> + rd = buf->sgt_base->sgl;
> + wr = sgt->sgl;
> + for (i = 0; i < sgt->orig_nents; ++i) {
> + sg_set_page(wr, sg_page(rd), rd->length, rd->offset);
> + rd = sg_next(rd);
> + wr = sg_next(wr);
> + }
> +
> + attach->dir = DMA_NONE;
> + dbuf_attach->priv = attach;
> +
> + return 0;
> +}
> +
> +static void vb2_dc_dmabuf_ops_detach(struct dma_buf *dbuf,
> + struct dma_buf_attachment *db_attach)
> +{
> + struct vb2_dc_attachment *attach = db_attach->priv;
> + struct sg_table *sgt;
> +
> + if (!attach)
> + return;
> +
> + sgt = >sgt;
> +
> + /* release the scatterlist cache */
> + if (attach->dir != DMA_NONE)
> + dma_unmap_sg(db_attach->dev, sgt->sgl, sgt->orig_nents,
> + attach->dir);
> + sg_free_table(sgt);
> + kfree(attach);
> + db_attach->priv = NULL;
> +}
> +
> +static struct sg_table *vb2_dc_dmabuf_ops_map(
> + struct dma_buf_attachment *db_attach, enum dma_data_direction dir)
> +{
> + struct vb2_dc_attachment *attach = db_attach->priv;
> + /* stealing dmabuf mutex to serialize map/unmap operations */
> + struct mutex *lock = _attach->dmabuf->lock;
> + struct sg_table *sgt;
> + int ret;
> +
> + mutex_lock(lock);
> +
> + sgt = >sgt;
> + /* return previously mapped sg table */
> + if (attach->dir == dir) {
> + mutex_unlock(lock);
> + return sgt;
> + }
> +
> + /* release any previous cache */
> + if (attach->dir != DMA_NONE) {
> + dma_unmap_sg(db_attach->dev, sgt->sgl, sgt->orig_nents,
> + attach->dir);
> + attach->dir = DMA_NONE;
> + }
> +
> + /* mapping to the client with new direction */
> + ret = dma_map_sg(db_attach->dev, sgt->sgl, sgt->orig_nents, dir);
> + if (ret <= 0) {
> + pr_err("failed to map scatterlist\n");
> + mutex_unlock(lock);
> + return ERR_PTR(-EIO);
> + }
> +
> + attach->dir = dir;
> +
> + mutex_unlock(lock);
> +
> + return sgt;
> +}
> +
> +static void vb2_dc_dmabuf_ops_unmap(struct dma_buf_attachment *db_attach,
> + struct sg_table *sgt, enum dma_data_direction dir)
> +{
> + /* nothing to be done here */
> +}
> +
> +static void vb2_dc_dmabuf_ops_release(struct dma_buf *dbuf)
> +{
> + /* drop reference obtained in vb2_dc_get_dmabuf */
> + vb2_dc_put(dbuf->priv);
> +}
> +
> +static void *vb2_dc_dmabuf_ops_kmap(struct 

[3.2.y] drm/i915: add Ivy Bridge GT2 Server entries

[Chris Wilson]

On Sun, 07 Oct 2012 15:01:17 +0100, Ben Hutchings  
wrote:
> On Mon, 2012-10-01 at 03:24 -0700, Jonathan Nieder wrote:
> > Hi Ben,
> > 
> > Please consider
> > 
> >   cc22a938fc1d drm/i915: add Ivy Bridge GT2 Server entries, 2012-03-29
> > 
> > for application to the 3.2.y tree.  It adds a PCI id to the i915
> > driver, making kms work.  It was applied during the 3.4-rc2 cycle, so
> > newer stable kernels don't need it.
> > 
> > Maik Zumstrull tried it[1] on top of 3.2.30 and found it to work ok
> > (thanks!).
> > 
> > Note that pre-2.4.34 versions of libdrm don't cope well with that
> > card, with or without this patch:
> [...]
> >  - with this patch, and with libdrm lacking 2.4.34~22 and 2.4.38~10,
> >X freezes at startup.
> > 
> > "No regressions" means you probably shouldn't take this patch without
> > a safety to work around the old X userspace,
> [...]
> 
> Then this workaround is also required in mainline.  And once that's
> done, I can take both patches.

The bugs Jonathan mentions are both in userspace packages; not
recognising the existence of Bromlow, and then misprogramming it. There
are no other kernel patches required specifically for this chipset,
afaik.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH] drm/radeon: allocate page tables on demand v3

[Christian König]

Based on Dmitries work, but splitting the code into page
directory and page table handling makes it far more
readable and (hopefully) more reliable.

Allocations of page tables are made from the SA on demand,
that should still work fine since all page tables are of
the same size.

Also using the fact that allocations from the SA are mostly
continuously (except for end of buffer wraps and under very
high memory pressure) to group updates send to the chipset
specific code into larger chunks.

v3: mostly a rewrite of Dmitries previous patch.

Signed-off-by: Dmitry Cherkasov 
Signed-off-by: Christian K?nig 
---
 drivers/gpu/drm/radeon/ni.c  |2 +-
 drivers/gpu/drm/radeon/radeon.h  |   11 +-
 drivers/gpu/drm/radeon/radeon_gart.c |  323 ++
 3 files changed, 263 insertions(+), 73 deletions(-)

diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 9a46f7d..48e2337 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1576,7 +1576,7 @@ void cayman_vm_flush(struct radeon_device *rdev, int 
ridx, struct radeon_vm *vm)
radeon_ring_write(ring, 0);

radeon_ring_write(ring, PACKET0(VM_CONTEXT0_PAGE_TABLE_END_ADDR + 
(vm->id << 2), 0));
-   radeon_ring_write(ring, vm->last_pfn);
+   radeon_ring_write(ring, rdev->vm_manager.max_pfn);

radeon_ring_write(ring, PACKET0(VM_CONTEXT0_PAGE_TABLE_BASE_ADDR + 
(vm->id << 2), 0));
radeon_ring_write(ring, vm->pd_gpu_addr >> 12);
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index b04c064..bc6b56b 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -663,9 +663,14 @@ struct radeon_vm {
struct list_headlist;
struct list_headva;
unsignedid;
-   unsignedlast_pfn;
-   u64 pd_gpu_addr;
-   struct radeon_sa_bo *sa_bo;
+
+   /* contains the page directory */
+   struct radeon_sa_bo *page_directory;
+   uint64_tpd_gpu_addr;
+
+   /* array of page tables, one for each page directory entry */
+   struct radeon_sa_bo **page_tables;
+
struct mutexmutex;
/* last fence for cs using this vm */
struct radeon_fence *fence;
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c 
b/drivers/gpu/drm/radeon/radeon_gart.c
index 753b7ca..40088b0 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -423,6 +423,18 @@ void radeon_gart_fini(struct radeon_device *rdev)
  */

 /**
+ * radeon_vm_num_pde - return the number of page directory entries
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Calculate the number of page directory entries (cayman+).
+ */
+static unsigned radeon_vm_num_pdes(struct radeon_device *rdev)
+{
+   return (rdev->vm_manager.max_pfn >> RADEON_VM_BLOCK_SIZE);
+}
+
+/**
  * radeon_vm_directory_size - returns the size of the page directory in bytes
  *
  * @rdev: radeon_device pointer
@@ -431,7 +443,7 @@ void radeon_gart_fini(struct radeon_device *rdev)
  */
 static unsigned radeon_vm_directory_size(struct radeon_device *rdev)
 {
-   return (rdev->vm_manager.max_pfn >> RADEON_VM_BLOCK_SIZE) * 8;
+   return RADEON_GPU_PAGE_ALIGN(radeon_vm_num_pdes(rdev) * 8);
 }

 /**
@@ -451,11 +463,11 @@ int radeon_vm_manager_init(struct radeon_device *rdev)

if (!rdev->vm_manager.enabled) {
/* allocate enough for 2 full VM pts */
-   size = RADEON_GPU_PAGE_ALIGN(radeon_vm_directory_size(rdev));
-   size += RADEON_GPU_PAGE_ALIGN(rdev->vm_manager.max_pfn * 8);
+   size = radeon_vm_directory_size(rdev);
+   size += rdev->vm_manager.max_pfn * 8;
size *= 2;
r = radeon_sa_bo_manager_init(rdev, 
>vm_manager.sa_manager,
- size,
+ RADEON_GPU_PAGE_ALIGN(size),
  RADEON_GEM_DOMAIN_VRAM);
if (r) {
dev_err(rdev->dev, "failed to allocate vm bo (%dKB)\n",
@@ -476,7 +488,7 @@ int radeon_vm_manager_init(struct radeon_device *rdev)

/* restore page table */
list_for_each_entry(vm, >vm_manager.lru_vm, list) {
-   if (vm->sa_bo == NULL)
+   if (vm->page_directory == NULL)
continue;

list_for_each_entry(bo_va, >va, vm_list) {
@@ -500,16 +512,25 @@ static void radeon_vm_free_pt(struct radeon_device *rdev,
struct radeon_vm *vm)
 {
struct radeon_bo_va *bo_va;
+   int i;

-   if (!vm->sa_bo)
+   if (!vm->page_directory)
return;

list_del_init(>list);
-   radeon_sa_bo_free(rdev, 

[3.2.y] drm/i915: add Ivy Bridge GT2 Server entries

[Ben Hutchings]

On Mon, 2012-10-01 at 03:24 -0700, Jonathan Nieder wrote:
> Hi Ben,
> 
> Please consider
> 
>   cc22a938fc1d drm/i915: add Ivy Bridge GT2 Server entries, 2012-03-29
> 
> for application to the 3.2.y tree.  It adds a PCI id to the i915
> driver, making kms work.  It was applied during the 3.4-rc2 cycle, so
> newer stable kernels don't need it.
> 
> Maik Zumstrull tried it[1] on top of 3.2.30 and found it to work ok
> (thanks!).
> 
> Note that pre-2.4.34 versions of libdrm don't cope well with that
> card, with or without this patch:
[...]
>  - with this patch, and with libdrm lacking 2.4.34~22 and 2.4.38~10,
>X freezes at startup.
> 
> "No regressions" means you probably shouldn't take this patch without
> a safety to work around the old X userspace,
[...]

Then this workaround is also required in mainline.  And once that's
done, I can take both patches.

Ben.

-- 
Ben Hutchings
You can't have everything.  Where would you put it?
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121007/a7f8f6d5/attachment.pgp>

Using Linux 3.2.23, GNOME 3.4 fallback, `evolution --component=mail mailto:i...@example.net` hangs

[Paul Menzel]

Dear Linux folks,


using Debian Sid/unstable, clicking on a mail address in Iceweasel
(Firefox) a composer window is opened in Evolution 3.4.3-1. But then the
windows are only gray and hang and the only way to fix this is to kill
the process. I reported this issue to the GNOME Bugzilla as 685640 and
the developer Matthew Barnes pointed out the following [1].

--- Comment #1 from Matthew Barnes  2012-10-07 
11:59:35 UTC ---
Radeon video driver thread looks stuck:

Thread 5 (Thread 0x7f6656d4d700 (LWP 4375)):
#0  pthread_cond_wait@@GLIBC_2.3.2 ()
at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
No locals.
#1  0x7f6656f4c9f3 in pipe_semaphore_wait (sema=0x7f666b6577b8)
at ../../../../../src/gallium/auxiliary/os/os_thread.h:432
No locals.
#2  radeon_drm_cs_emit_ioctl (param=0x7f666b635c40) at 
radeon_drm_cs.c:401
cs = 0x7f666b635c40

Any hints how to fix this are much appreciated. If it is indeed a Linux
issue, I will gladly create a new ticket in the freedesktop.org
Bugzilla.


Thanks,

Paul


[1] https://bugzilla.gnome.org/show_bug.cgi?id=685640
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121007/9ced3a1f/attachment.pgp>

[Bug 55692] [KMS][Cayman] Garbled screen and oops with 6950 with linus git from 20121006 (3.7-rc0)

[bugzilla-dae...@freedesktop.org]

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

Christian K?nig  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #9 from Christian K?nig  ---
Mhm, interesting. You get a GPU lockup, but not a pagefault.

Need to look deeper into it, but this looks rather strange to me.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121007/099ca6b2/attachment.html>

[PATCHv9 00/25] Integration of videobuf2 with DMABUF

[Hans Verkuil]

Hi all!

On Tue October 2 2012 16:27:11 Tomasz Stanislawski wrote:
> Hello everyone,
> This patchset adds support for DMABUF [2] importing and exporting to V4L2
> stack.

I see that there is a lot of interest to getting this into 3.7. I understand
that, but IMHO this is a bit too soon. I would like to see the review comments
I made for v9 addressed, and more importantly, I would *really* like to see
mem2mem_testdev.c be dmabuf aware. One of the problems today is that it is
hard to test this, but if vivi and mem2mem_testdev can do dmabuf, then it is
easy to setup a pipeline that everyone can use for testing and application
development without requiring special hardware.

My suggestion would be to get a v10 out, and merge that as soon as the for_v3.8
branch opens. Then get mem2mem_testdev ready for dmabuf as well for 3.8.

Regards,

Hans

> 
> v9:
> - rebase on 3.6
> - change type for fs to __s32
> - add support for vb2_ioctl_expbuf
> - remove patch 'v4l: vb2: add support for DMA_ATTR_NO_KERNEL_MAPPING',
>   it will be posted as a separate patch
> - fix typos and style in Documentation (from Hans Verkuil)
> - only vb2-core and vb2-dma-contig selects DMA_SHARED_BUFFER in Kconfig
> - use data_offset and length while queueing DMABUF
> - return the most recently used fd at VIDIOC_DQBUF
> - use (buffer-type, index, plane) tuple instead of mem_offset
>   to identify a for exporting (from Hans Verkuil)
> - support for DMABUF mmap in vb2-dma-contig (from Laurent Pinchart)
> - add testing alignment of vaddr and size while verifying userptr
>   against DMA capabilities (from Laurent Pinchart)
> - substitute VM_DONTDUMP with VM_RESERVED
> - simplify error handling in vb2_dc_get_dmabuf (from Laurent Pinchart)
> 
> v8:
> - rebased on 3.6-rc1
> - merged importer and exporter patchsets
> - fixed missing fields in v4l2_plane32 and v4l2_buffer32 structs
> - fixed typos/style in documentation
> - significant reduction of warnings from checkpatch.pl
> - fixed STREAMOFF issues reported by Dima Zavin [4] by adding
>   __vb2_dqbuf helper to vb2-core
> - DC fails if userptr is not correctly aligned
> - add support for DMA attributes in DC
> - add support for buffers with no kernel mapping
> - add reference counting on device from allocator context
> - dummy support for mmap
> - use dma_get_sgtable, drop vb2_dc_kaddr_to_pages hack and
>   vb2_dc_get_base_sgt helper
> 
> v7:
> - support for V4L2_MEMORY_DMABUF in v4l2-compact-ioctl32.c
> - cosmetic fixes to the documentation
> - added importing for vmalloc because vmap support in dmabuf for 3.5
>   was pull-requested
> - support for dmabuf importing for VIVI
> - resurrect allocation of dma-contig context
> - remove reference of alloc_ctx in dma-contig buffer
> - use sg_alloc_table_from_pages
> - fix DMA scatterlist calls to use orig_nents instead of nents
> - fix memleak in vb2_dc_sgt_foreach_page (use orig_nents instead of nents)
> 
> v6:
> - fixed missing entry in v4l2_memory_names
> - fixed a bug occuring after get_user_pages failure
> - fixed a bug caused by using invalid vma for get_user_pages
> - prepare/finish no longer call dma_sync for dmabuf buffers
> 
> v5:
> - removed change of importer/exporter behaviour
> - fixes vb2_dc_pages_to_sgt basing on Laurent's hints
> - changed pin/unpin words to lock/unlock in Doc
> 
> v4:
> - rebased on mainline 3.4-rc2
> - included missing importing support for s5p-fimc and s5p-tv
> - added patch for changing map/unmap for importers
> - fixes to Documentation part
> - coding style fixes
> - pairing {map/unmap}_dmabuf in vb2-core
> - fixing variable types and semantic of arguments in videobufb2-dma-contig.c
> 
> v3:
> - rebased on mainline 3.4-rc1
> - split 'code refactor' patch to multiple smaller patches
> - squashed fixes to Sumit's patches
> - patchset is no longer dependant on 'DMA mapping redesign'
> - separated path for handling IO and non-IO mappings
> - add documentation for DMABUF importing to V4L
> - removed all DMABUF exporter related code
> - removed usage of dma_get_pages extension
> 
> v2:
> - extended VIDIOC_EXPBUF argument from integer memoffset to struct
>   v4l2_exportbuffer
> - added patch that breaks DMABUF spec on (un)map_atachment callcacks but 
> allows
>   to work with existing implementation of DMABUF prime in DRM
> - all dma-contig code refactoring patches were squashed
> - bugfixes
> 
> v1: List of changes since [1].
> - support for DMA api extension dma_get_pages, the function is used to 
> retrieve
>   pages used to create DMA mapping.
> - small fixes/code cleanup to videobuf2
> - added prepare and finish callbacks to vb2 allocators, it is used keep
>   consistency between dma-cpu acess to the memory (by Marek Szyprowski)
> - support for exporting of DMABUF buffer in V4L2 and Videobuf2, originated 
> from
>   [3].
> - support for dma-buf exporting in vb2-dma-contig allocator
> - support for DMABUF for s5p-tv and s5p-fimc (capture interface) drivers,
>   originated from [3]
> - changed handling for 

[3.2.y] drm/i915: add Ivy Bridge GT2 Server entries

[Jonathan Nieder]

Maik Zumstrull wrote:
> On Sun, Oct 7, 2012 at 7:26 PM, Julien Cristau  wrote:
>> On Mon, Oct  1, 2012 at 03:24:32 -0700, Jonathan Nieder wrote:

>>>  - without this patch, modern X errors out instead of starting,
[...]
>> I'd expect X to start with vesa or fbdev, rather than erroring out?
>
> There's a corner case when X and the kernel know about the graphics
> device, but libdrm doesn't, in which case an assertion in the X driver
> fails and X doesn't start. Upstream libdrm has been okay for a few
> releases.

I think Julien means the case where the kernel does not know about the
graphics device.  From [1]:

| 3.2 crashes as well, but not as hard as 3.4. With 3.2, X doesn't come
| up, but you can switch to a console and reboot. 3.4 needs the reset
| button.

X should have been able to start using the vesa or fbdev driver.  I'm
not sure why that doesn't happen --- do you have an Xorg log from
booting and trying to start X with a 3.2.y kernel without the
"drm/i915: add Ivy Bridge GT2 Server entries" patch?

Thanks,
Jonathan

[1] http://bugs.debian.org/684767

[git pull] drm merge for rc1 (part 1)

[Shentino]

On Thu, Oct 4, 2012 at 2:49 AM, David Howells  wrote:
> Linus Torvalds  wrote:
>
>> Ok, as usual I actually wanted to do the merge myself despite the
>> annoying conflicts (this *really* is the last time I will ever accept
>> any header file "cleanups" - they simply aren't worth the pain).
>
> There was a reason I asked you to pull the patches at the *end* of the merge
> window, and a reason I asked you to give me a chance to regenerate the patches
> before you pulled them.
>
> Anyway, I can feed much of the main set of patches through subsystem trees now
> - so thanks for that at least.

Saw this LWN article about the UAPI cleanup.

http://lwn.net/Articles/507794/

Have you had much feedback from subsystem maintainers about accepting
these?  I'm no kernel developer yet but I have had a keen interest in
this patch set ever since I heard of it.

> David
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv9 00/25] Integration of videobuf2 with DMABUF

[Hans Verkuil]

Hi all!

On Tue October 2 2012 16:27:11 Tomasz Stanislawski wrote:
 Hello everyone,
 This patchset adds support for DMABUF [2] importing and exporting to V4L2
 stack.

I see that there is a lot of interest to getting this into 3.7. I understand
that, but IMHO this is a bit too soon. I would like to see the review comments
I made for v9 addressed, and more importantly, I would *really* like to see
mem2mem_testdev.c be dmabuf aware. One of the problems today is that it is
hard to test this, but if vivi and mem2mem_testdev can do dmabuf, then it is
easy to setup a pipeline that everyone can use for testing and application
development without requiring special hardware.

My suggestion would be to get a v10 out, and merge that as soon as the for_v3.8
branch opens. Then get mem2mem_testdev ready for dmabuf as well for 3.8.

Regards,

Hans

 
 v9:
 - rebase on 3.6
 - change type for fs to __s32
 - add support for vb2_ioctl_expbuf
 - remove patch 'v4l: vb2: add support for DMA_ATTR_NO_KERNEL_MAPPING',
   it will be posted as a separate patch
 - fix typos and style in Documentation (from Hans Verkuil)
 - only vb2-core and vb2-dma-contig selects DMA_SHARED_BUFFER in Kconfig
 - use data_offset and length while queueing DMABUF
 - return the most recently used fd at VIDIOC_DQBUF
 - use (buffer-type, index, plane) tuple instead of mem_offset
   to identify a for exporting (from Hans Verkuil)
 - support for DMABUF mmap in vb2-dma-contig (from Laurent Pinchart)
 - add testing alignment of vaddr and size while verifying userptr
   against DMA capabilities (from Laurent Pinchart)
 - substitute VM_DONTDUMP with VM_RESERVED
 - simplify error handling in vb2_dc_get_dmabuf (from Laurent Pinchart)
 
 v8:
 - rebased on 3.6-rc1
 - merged importer and exporter patchsets
 - fixed missing fields in v4l2_plane32 and v4l2_buffer32 structs
 - fixed typos/style in documentation
 - significant reduction of warnings from checkpatch.pl
 - fixed STREAMOFF issues reported by Dima Zavin [4] by adding
   __vb2_dqbuf helper to vb2-core
 - DC fails if userptr is not correctly aligned
 - add support for DMA attributes in DC
 - add support for buffers with no kernel mapping
 - add reference counting on device from allocator context
 - dummy support for mmap
 - use dma_get_sgtable, drop vb2_dc_kaddr_to_pages hack and
   vb2_dc_get_base_sgt helper
 
 v7:
 - support for V4L2_MEMORY_DMABUF in v4l2-compact-ioctl32.c
 - cosmetic fixes to the documentation
 - added importing for vmalloc because vmap support in dmabuf for 3.5
   was pull-requested
 - support for dmabuf importing for VIVI
 - resurrect allocation of dma-contig context
 - remove reference of alloc_ctx in dma-contig buffer
 - use sg_alloc_table_from_pages
 - fix DMA scatterlist calls to use orig_nents instead of nents
 - fix memleak in vb2_dc_sgt_foreach_page (use orig_nents instead of nents)
 
 v6:
 - fixed missing entry in v4l2_memory_names
 - fixed a bug occuring after get_user_pages failure
 - fixed a bug caused by using invalid vma for get_user_pages
 - prepare/finish no longer call dma_sync for dmabuf buffers
 
 v5:
 - removed change of importer/exporter behaviour
 - fixes vb2_dc_pages_to_sgt basing on Laurent's hints
 - changed pin/unpin words to lock/unlock in Doc
 
 v4:
 - rebased on mainline 3.4-rc2
 - included missing importing support for s5p-fimc and s5p-tv
 - added patch for changing map/unmap for importers
 - fixes to Documentation part
 - coding style fixes
 - pairing {map/unmap}_dmabuf in vb2-core
 - fixing variable types and semantic of arguments in videobufb2-dma-contig.c
 
 v3:
 - rebased on mainline 3.4-rc1
 - split 'code refactor' patch to multiple smaller patches
 - squashed fixes to Sumit's patches
 - patchset is no longer dependant on 'DMA mapping redesign'
 - separated path for handling IO and non-IO mappings
 - add documentation for DMABUF importing to V4L
 - removed all DMABUF exporter related code
 - removed usage of dma_get_pages extension
 
 v2:
 - extended VIDIOC_EXPBUF argument from integer memoffset to struct
   v4l2_exportbuffer
 - added patch that breaks DMABUF spec on (un)map_atachment callcacks but 
 allows
   to work with existing implementation of DMABUF prime in DRM
 - all dma-contig code refactoring patches were squashed
 - bugfixes
 
 v1: List of changes since [1].
 - support for DMA api extension dma_get_pages, the function is used to 
 retrieve
   pages used to create DMA mapping.
 - small fixes/code cleanup to videobuf2
 - added prepare and finish callbacks to vb2 allocators, it is used keep
   consistency between dma-cpu acess to the memory (by Marek Szyprowski)
 - support for exporting of DMABUF buffer in V4L2 and Videobuf2, originated 
 from
   [3].
 - support for dma-buf exporting in vb2-dma-contig allocator
 - support for DMABUF for s5p-tv and s5p-fimc (capture interface) drivers,
   originated from [3]
 - changed handling for userptr buffers (by Marek Szyprowski, Andrzej
   Pietrasiewicz)
 - let mmap method to use 

Using Linux 3.2.23, GNOME 3.4 fallback, `evolution --component=mail mailto:i...@example.net` hangs

[Paul Menzel]

Dear Linux folks,


using Debian Sid/unstable, clicking on a mail address in Iceweasel
(Firefox) a composer window is opened in Evolution 3.4.3-1. But then the
windows are only gray and hang and the only way to fix this is to kill
the process. I reported this issue to the GNOME Bugzilla as 685640 and
the developer Matthew Barnes pointed out the following [1].

--- Comment #1 from Matthew Barnes mbar...@redhat.com 2012-10-07 
11:59:35 UTC ---
Radeon video driver thread looks stuck:

Thread 5 (Thread 0x7f6656d4d700 (LWP 4375)):
#0  pthread_cond_wait@@GLIBC_2.3.2 ()
at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
No locals.
#1  0x7f6656f4c9f3 in pipe_semaphore_wait (sema=0x7f666b6577b8)
at ../../../../../src/gallium/auxiliary/os/os_thread.h:432
No locals.
#2  radeon_drm_cs_emit_ioctl (param=0x7f666b635c40) at 
radeon_drm_cs.c:401
cs = 0x7f666b635c40

Any hints how to fix this are much appreciated. If it is indeed a Linux
issue, I will gladly create a new ticket in the freedesktop.org
Bugzilla.


Thanks,

Paul


[1] https://bugzilla.gnome.org/show_bug.cgi?id=685640


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

[PATCH] drm/radeon: allocate page tables on demand v3

[Christian König]

Based on Dmitries work, but splitting the code into page
directory and page table handling makes it far more
readable and (hopefully) more reliable.

Allocations of page tables are made from the SA on demand,
that should still work fine since all page tables are of
the same size.

Also using the fact that allocations from the SA are mostly
continuously (except for end of buffer wraps and under very
high memory pressure) to group updates send to the chipset
specific code into larger chunks.

v3: mostly a rewrite of Dmitries previous patch.

Signed-off-by: Dmitry Cherkasov dmitrii.cherka...@amd.com
Signed-off-by: Christian König deathsim...@vodafone.de
---
 drivers/gpu/drm/radeon/ni.c  |2 +-
 drivers/gpu/drm/radeon/radeon.h  |   11 +-
 drivers/gpu/drm/radeon/radeon_gart.c |  323 ++
 3 files changed, 263 insertions(+), 73 deletions(-)

diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 9a46f7d..48e2337 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1576,7 +1576,7 @@ void cayman_vm_flush(struct radeon_device *rdev, int 
ridx, struct radeon_vm *vm)
radeon_ring_write(ring, 0);
 
radeon_ring_write(ring, PACKET0(VM_CONTEXT0_PAGE_TABLE_END_ADDR + 
(vm-id  2), 0));
-   radeon_ring_write(ring, vm-last_pfn);
+   radeon_ring_write(ring, rdev-vm_manager.max_pfn);
 
radeon_ring_write(ring, PACKET0(VM_CONTEXT0_PAGE_TABLE_BASE_ADDR + 
(vm-id  2), 0));
radeon_ring_write(ring, vm-pd_gpu_addr  12);
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index b04c064..bc6b56b 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -663,9 +663,14 @@ struct radeon_vm {
struct list_headlist;
struct list_headva;
unsignedid;
-   unsignedlast_pfn;
-   u64 pd_gpu_addr;
-   struct radeon_sa_bo *sa_bo;
+
+   /* contains the page directory */
+   struct radeon_sa_bo *page_directory;
+   uint64_tpd_gpu_addr;
+
+   /* array of page tables, one for each page directory entry */
+   struct radeon_sa_bo **page_tables;
+
struct mutexmutex;
/* last fence for cs using this vm */
struct radeon_fence *fence;
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c 
b/drivers/gpu/drm/radeon/radeon_gart.c
index 753b7ca..40088b0 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -423,6 +423,18 @@ void radeon_gart_fini(struct radeon_device *rdev)
  */
 
 /**
+ * radeon_vm_num_pde - return the number of page directory entries
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Calculate the number of page directory entries (cayman+).
+ */
+static unsigned radeon_vm_num_pdes(struct radeon_device *rdev)
+{
+   return (rdev-vm_manager.max_pfn  RADEON_VM_BLOCK_SIZE);
+}
+
+/**
  * radeon_vm_directory_size - returns the size of the page directory in bytes
  *
  * @rdev: radeon_device pointer
@@ -431,7 +443,7 @@ void radeon_gart_fini(struct radeon_device *rdev)
  */
 static unsigned radeon_vm_directory_size(struct radeon_device *rdev)
 {
-   return (rdev-vm_manager.max_pfn  RADEON_VM_BLOCK_SIZE) * 8;
+   return RADEON_GPU_PAGE_ALIGN(radeon_vm_num_pdes(rdev) * 8);
 }
 
 /**
@@ -451,11 +463,11 @@ int radeon_vm_manager_init(struct radeon_device *rdev)
 
if (!rdev-vm_manager.enabled) {
/* allocate enough for 2 full VM pts */
-   size = RADEON_GPU_PAGE_ALIGN(radeon_vm_directory_size(rdev));
-   size += RADEON_GPU_PAGE_ALIGN(rdev-vm_manager.max_pfn * 8);
+   size = radeon_vm_directory_size(rdev);
+   size += rdev-vm_manager.max_pfn * 8;
size *= 2;
r = radeon_sa_bo_manager_init(rdev, 
rdev-vm_manager.sa_manager,
- size,
+ RADEON_GPU_PAGE_ALIGN(size),
  RADEON_GEM_DOMAIN_VRAM);
if (r) {
dev_err(rdev-dev, failed to allocate vm bo (%dKB)\n,
@@ -476,7 +488,7 @@ int radeon_vm_manager_init(struct radeon_device *rdev)
 
/* restore page table */
list_for_each_entry(vm, rdev-vm_manager.lru_vm, list) {
-   if (vm-sa_bo == NULL)
+   if (vm-page_directory == NULL)
continue;
 
list_for_each_entry(bo_va, vm-va, vm_list) {
@@ -500,16 +512,25 @@ static void radeon_vm_free_pt(struct radeon_device *rdev,
struct radeon_vm *vm)
 {
struct radeon_bo_va *bo_va;
+   int i;
 
-   if (!vm-sa_bo)
+   if (!vm-page_directory)
return;
 

[Bug 55692] [KMS][Cayman] Garbled screen and oops with 6950 with linus git from 20121006 (3.7-rc0)

[bugzilla-daemon]

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

Christian König deathsim...@vodafone.de changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #9 from Christian König deathsim...@vodafone.de ---
Mhm, interesting. You get a GPU lockup, but not a pagefault.

Need to look deeper into it, but this looks rather strange to me.

-- 
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: [PATCHv9 20/25] v4l: vb2-dma-contig: add support for DMABUF exporting

[Laurent Pinchart]

Hi Tomasz,

Thanks for the patch.

On Tuesday 02 October 2012 16:27:31 Tomasz Stanislawski wrote:
 This patch adds support for exporting a dma-contig buffer using
 DMABUF interface.
 
 Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com

Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com

 ---
  drivers/media/video/videobuf2-dma-contig.c |  200 +
  1 file changed, 200 insertions(+)
 
 diff --git a/drivers/media/video/videobuf2-dma-contig.c
 b/drivers/media/video/videobuf2-dma-contig.c index 0e065ce..b138b5c 100644
 --- a/drivers/media/video/videobuf2-dma-contig.c
 +++ b/drivers/media/video/videobuf2-dma-contig.c
 @@ -36,6 +36,7 @@ struct vb2_dc_buf {
   /* MMAP related */
   struct vb2_vmarea_handler   handler;
   atomic_trefcount;
 + struct sg_table *sgt_base;
 
   /* USERPTR related */
   struct vm_area_struct   *vma;
 @@ -142,6 +143,10 @@ static void vb2_dc_put(void *buf_priv)
   if (!atomic_dec_and_test(buf-refcount))
   return;
 
 + if (buf-sgt_base) {
 + sg_free_table(buf-sgt_base);
 + kfree(buf-sgt_base);
 + }
   dma_free_coherent(buf-dev, buf-size, buf-vaddr, buf-dma_addr);
   kfree(buf);
  }
 @@ -213,6 +218,200 @@ static int vb2_dc_mmap(void *buf_priv, struct
 vm_area_struct *vma) }
 
  /*/
 +/* DMABUF ops for exporters  */
 +/*/
 +
 +struct vb2_dc_attachment {
 + struct sg_table sgt;
 + enum dma_data_direction dir;
 +};
 +
 +static int vb2_dc_dmabuf_ops_attach(struct dma_buf *dbuf, struct device
 *dev, +   struct dma_buf_attachment *dbuf_attach)
 +{
 + struct vb2_dc_attachment *attach;
 + unsigned int i;
 + struct scatterlist *rd, *wr;
 + struct sg_table *sgt;
 + struct vb2_dc_buf *buf = dbuf-priv;
 + int ret;
 +
 + attach = kzalloc(sizeof(*attach), GFP_KERNEL);
 + if (!attach)
 + return -ENOMEM;
 +
 + sgt = attach-sgt;
 + /* Copy the buf-base_sgt scatter list to the attachment, as we can't
 +  * map the same scatter list to multiple attachments at the same time.
 +  */
 + ret = sg_alloc_table(sgt, buf-sgt_base-orig_nents, GFP_KERNEL);
 + if (ret) {
 + kfree(attach);
 + return -ENOMEM;
 + }
 +
 + rd = buf-sgt_base-sgl;
 + wr = sgt-sgl;
 + for (i = 0; i  sgt-orig_nents; ++i) {
 + sg_set_page(wr, sg_page(rd), rd-length, rd-offset);
 + rd = sg_next(rd);
 + wr = sg_next(wr);
 + }
 +
 + attach-dir = DMA_NONE;
 + dbuf_attach-priv = attach;
 +
 + return 0;
 +}
 +
 +static void vb2_dc_dmabuf_ops_detach(struct dma_buf *dbuf,
 + struct dma_buf_attachment *db_attach)
 +{
 + struct vb2_dc_attachment *attach = db_attach-priv;
 + struct sg_table *sgt;
 +
 + if (!attach)
 + return;
 +
 + sgt = attach-sgt;
 +
 + /* release the scatterlist cache */
 + if (attach-dir != DMA_NONE)
 + dma_unmap_sg(db_attach-dev, sgt-sgl, sgt-orig_nents,
 + attach-dir);
 + sg_free_table(sgt);
 + kfree(attach);
 + db_attach-priv = NULL;
 +}
 +
 +static struct sg_table *vb2_dc_dmabuf_ops_map(
 + struct dma_buf_attachment *db_attach, enum dma_data_direction dir)
 +{
 + struct vb2_dc_attachment *attach = db_attach-priv;
 + /* stealing dmabuf mutex to serialize map/unmap operations */
 + struct mutex *lock = db_attach-dmabuf-lock;
 + struct sg_table *sgt;
 + int ret;
 +
 + mutex_lock(lock);
 +
 + sgt = attach-sgt;
 + /* return previously mapped sg table */
 + if (attach-dir == dir) {
 + mutex_unlock(lock);
 + return sgt;
 + }
 +
 + /* release any previous cache */
 + if (attach-dir != DMA_NONE) {
 + dma_unmap_sg(db_attach-dev, sgt-sgl, sgt-orig_nents,
 + attach-dir);
 + attach-dir = DMA_NONE;
 + }
 +
 + /* mapping to the client with new direction */
 + ret = dma_map_sg(db_attach-dev, sgt-sgl, sgt-orig_nents, dir);
 + if (ret = 0) {
 + pr_err(failed to map scatterlist\n);
 + mutex_unlock(lock);
 + return ERR_PTR(-EIO);
 + }
 +
 + attach-dir = dir;
 +
 + mutex_unlock(lock);
 +
 + return sgt;
 +}
 +
 +static void vb2_dc_dmabuf_ops_unmap(struct dma_buf_attachment *db_attach,
 + struct sg_table *sgt, enum dma_data_direction dir)
 +{
 + /* nothing to be done here */
 +}
 +
 +static void vb2_dc_dmabuf_ops_release(struct dma_buf *dbuf)
 +{
 + /* drop reference obtained in vb2_dc_get_dmabuf */
 + vb2_dc_put(dbuf-priv);
 +}
 +
 +static void *vb2_dc_dmabuf_ops_kmap(struct dma_buf *dbuf, unsigned long
 pgnum) +{
 + struct vb2_dc_buf *buf = dbuf-priv;
 +
 + return 

Re: [PATCHv9 21/25] v4l: vb2-dma-contig: add reference counting for a device from allocator context

[Laurent Pinchart]

Hi Tomasz,

Thanks for the patch.

On Tuesday 02 October 2012 16:27:32 Tomasz Stanislawski wrote:
 This patch adds taking reference to the device for MMAP buffers.
 
 Such buffers, may be exported using DMABUF mechanism. If the driver that
 created a queue is unloaded then the queue is released, the device might be
 released too.  However, buffers cannot be released if they are referenced by
 DMABUF descriptor(s). The device pointer kept in a buffer must be valid for
 the whole buffer's lifetime. Therefore MMAP buffers should take a reference
 to the device to avoid risk of dangling pointers.
 
 Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com

 ---
  drivers/media/video/videobuf2-dma-contig.c |5 +
  1 file changed, 5 insertions(+)
 
 diff --git a/drivers/media/video/videobuf2-dma-contig.c
 b/drivers/media/video/videobuf2-dma-contig.c index b138b5c..b4d287a 100644
 --- a/drivers/media/video/videobuf2-dma-contig.c
 +++ b/drivers/media/video/videobuf2-dma-contig.c
 @@ -148,6 +148,7 @@ static void vb2_dc_put(void *buf_priv)
   kfree(buf-sgt_base);
   }
   dma_free_coherent(buf-dev, buf-size, buf-vaddr, buf-dma_addr);
 + put_device(buf-dev);
   kfree(buf);
  }
 
 @@ -161,9 +162,13 @@ static void *vb2_dc_alloc(void *alloc_ctx, unsigned
 long size) if (!buf)
   return ERR_PTR(-ENOMEM);
 
 + /* prevent the device from release while the buffer is exported */
 + get_device(dev);
 +

What about moving this below the dma_alloc_coherent() call ? You could then 
avoid the put_device() call in the error path.

   buf-vaddr = dma_alloc_coherent(dev, size, buf-dma_addr, GFP_KERNEL);
   if (!buf-vaddr) {
   dev_err(dev, dma_alloc_coherent of size %ld failed\n, size);
 + put_device(dev);
   kfree(buf);
   return ERR_PTR(-ENOMEM);
   }

Something like

-   buf-dev = dev;
+   buf-dev = get_device(dev);
buf-size = size

-- 
Regards,

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

Re: [PATCH 1/2 v6] of: add helper to parse display timings

[Laurent Pinchart]

Hi Steffen,

On Friday 05 October 2012 18:38:58 Steffen Trumtrar wrote:
 On Fri, Oct 05, 2012 at 10:21:37AM -0600, Stephen Warren wrote:
  On 10/05/2012 10:16 AM, Steffen Trumtrar wrote:
   On Thu, Oct 04, 2012 at 12:47:16PM -0600, Stephen Warren wrote:
   On 10/04/2012 11:59 AM, Steffen Trumtrar wrote:
  ...
  
   +   for_each_child_of_node(timings_np, entry) {
   +   struct signal_timing *st;
   +
   +   st = of_get_display_timing(entry);
   +
   +   if (!st)
   +   continue;
   
   I wonder if that shouldn't be an error?
   
   In the sense of a pr_err not a -EINVAL I presume?! It is a little bit
   quiet in case of a faulty spec, that is right.
  
  I did mean return an error; if we try to parse something and can't,
  shouldn't we return an error?
  
  I suppose it may be possible to limp on and use whatever subset of modes
  could be parsed and drop the others, which is what this code does, but
  the code after the loop would definitely return an error if zero timings
  were parseable.
 
 If a display supports multiple modes, I think it is better to have a working
 mode (even if it is not the preferred one) than have none at all.
 If there is no mode at all, that should be an error, right.

If we fail completely in case of an error, DT writers will notice their bugs. 
If we ignore errors silently they won't, and we'll end up with buggy DTs (or, 
to be accurate, even more buggy DTs :-)). I'd rather fail completely in the 
first implementation and add workarounds later only if we need to.

-- 
Regards,

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

Re: [PATCHv9 18/25] v4l: add buffer exporting via dmabuf

[Laurent Pinchart]

Hi Hans,

On Friday 05 October 2012 10:55:40 Hans Verkuil wrote:
 On Tue October 2 2012 16:27:29 Tomasz Stanislawski wrote:
  This patch adds extension to V4L2 api. It allow to export a mmap buffer as
  file descriptor. New ioctl VIDIOC_EXPBUF is added. It takes a buffer
  offset used by mmap and return a file descriptor on success.
  
  Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
  Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com

[snip]

  diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
  index e04a73e..f429b6a 100644
  --- a/include/linux/videodev2.h
  +++ b/include/linux/videodev2.h
  @@ -688,6 +688,33 @@ struct v4l2_buffer {
  
   #define V4L2_BUF_FLAG_NO_CACHE_INVALIDATE  0x0800
   #define V4L2_BUF_FLAG_NO_CACHE_CLEAN   0x1000
  
  +/**
  + * struct v4l2_exportbuffer - export of video buffer as DMABUF file
  descriptor + *
  + * @fd:file descriptor associated with DMABUF (set by driver)
  + * @flags: flags for newly created file, currently only O_CLOEXEC is
  + * supported, refer to manual of open syscall for more details
  + * @index: id number of the buffer
  + * @type:  enum v4l2_buf_type; buffer type (type == *_MPLANE for
  + * multiplanar buffers);
  + * @plane: index of the plane to be exported, 0 for single plane queues
  + *
  + * Contains data used for exporting a video buffer as DMABUF file
  descriptor. + * The buffer is identified by a 'cookie' returned by
  VIDIOC_QUERYBUF + * (identical to the cookie used to mmap() the buffer to
  userspace). All + * reserved fields must be set to zero. The field
  reserved0 is expected to + * become a structure 'type' allowing an
  alternative layout of the structure + * content. Therefore this field
  should not be used for any other extensions. + */
  +struct v4l2_exportbuffer {
  +   __s32   fd;
  +   __u32   flags;
  +   __u32   type; /* enum v4l2_buf_type */
  +   __u32   index;
  +   __u32   plane;
 
 As suggested in my comments in the previous patch, I think it is a more
 natural order to have the type/index/plane fields first in this struct.
 
 Actually, I think that flags should also come before fd:
 
 struct v4l2_exportbuffer {
   __u32   type; /* enum v4l2_buf_type */
   __u32   index;
   __u32   plane;
   __u32   flags;
   __s32   fd;
   __u32   reserved[11];
 };

It would indeed feel more natural, but putting them right before the reserved 
fields allows creating an anonymous union around type, index and plane and 
extending it with reserved fields if needed. That's (at least to my 
understanding) the rationale behind the current structure layout.

  +   __u32   reserved[11];
  +};
  +
  
   /*
   
* O V E R L A Y   P R E V I E W
*/

-- 
Regards,

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

Re: [PATCH 2/2 v6] of: add generic videomode description

[Laurent Pinchart]

Hi Steffen,

On Friday 05 October 2012 17:51:21 Steffen Trumtrar wrote:
 On Thu, Oct 04, 2012 at 12:51:00PM -0600, Stephen Warren wrote:
  On 10/04/2012 11:59 AM, Steffen Trumtrar wrote:
   Get videomode from devicetree in a format appropriate for the
   backend. drm_display_mode and fb_videomode are supported atm.
   Uses the display signal timings from of_display_timings
   
   +++ b/drivers/of/of_videomode.c
   
   +int videomode_from_timing(struct display_timings *disp, struct
   videomode *vm,
   
   + st = display_timings_get(disp, index);
   +
   + if (!st) {
  
  It's a little odd to leave a blank line between those two lines.
 
 Hm, well okay. That can be remedied
 
  Only half of the code in this file seems OF-related; the routines to
  convert a timing to a videomode or drm display mode seem like they'd be
  useful outside device tree, so I wonder if putting them into
  of_videomode.c is the correct thing to do. Still, it's probably not a
  big deal.
 
 I am not sure, what the appropriate way to do this is. I can split it up
 (again).

I think it would make sense to move them to their respective subsystems.

-- 
Regards,

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

Re: [PATCHv9 18/25] v4l: add buffer exporting via dmabuf

[Hans Verkuil]

On Sun October 7 2012 15:38:30 Laurent Pinchart wrote:
 Hi Hans,
 
 On Friday 05 October 2012 10:55:40 Hans Verkuil wrote:
  On Tue October 2 2012 16:27:29 Tomasz Stanislawski wrote:
   This patch adds extension to V4L2 api. It allow to export a mmap buffer as
   file descriptor. New ioctl VIDIOC_EXPBUF is added. It takes a buffer
   offset used by mmap and return a file descriptor on success.
   
   Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
   Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 
 [snip]
 
   diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
   index e04a73e..f429b6a 100644
   --- a/include/linux/videodev2.h
   +++ b/include/linux/videodev2.h
   @@ -688,6 +688,33 @@ struct v4l2_buffer {
   
#define V4L2_BUF_FLAG_NO_CACHE_INVALIDATE0x0800
#define V4L2_BUF_FLAG_NO_CACHE_CLEAN 0x1000
   
   +/**
   + * struct v4l2_exportbuffer - export of video buffer as DMABUF file
   descriptor + *
   + * @fd:  file descriptor associated with DMABUF (set by driver)
   + * @flags:   flags for newly created file, currently only O_CLOEXEC 
   is
   + *   supported, refer to manual of open syscall for more 
   details
   + * @index:   id number of the buffer
   + * @type:enum v4l2_buf_type; buffer type (type == *_MPLANE for
   + *   multiplanar buffers);
   + * @plane:   index of the plane to be exported, 0 for single plane 
   queues
   + *
   + * Contains data used for exporting a video buffer as DMABUF file
   descriptor. + * The buffer is identified by a 'cookie' returned by
   VIDIOC_QUERYBUF + * (identical to the cookie used to mmap() the buffer to
   userspace). All + * reserved fields must be set to zero. The field
   reserved0 is expected to + * become a structure 'type' allowing an
   alternative layout of the structure + * content. Therefore this field
   should not be used for any other extensions. + */
   +struct v4l2_exportbuffer {
   + __s32   fd;
   + __u32   flags;
   + __u32   type; /* enum v4l2_buf_type */
   + __u32   index;
   + __u32   plane;
  
  As suggested in my comments in the previous patch, I think it is a more
  natural order to have the type/index/plane fields first in this struct.
  
  Actually, I think that flags should also come before fd:
  
  struct v4l2_exportbuffer {
  __u32   type; /* enum v4l2_buf_type */
  __u32   index;
  __u32   plane;
  __u32   flags;
  __s32   fd;
  __u32   reserved[11];
  };
 
 It would indeed feel more natural, but putting them right before the reserved 
 fields allows creating an anonymous union around type, index and plane and 
 extending it with reserved fields if needed. That's (at least to my 
 understanding) the rationale behind the current structure layout.

The anonymous union argument makes no sense to me, to be honest. It's standard
practice within V4L2 to have the IN fields first, then the OUT fields, followed
by reserved fields for future expansion. Should we ever need a, say, sub-plane
index (whatever that might be), then we can use one of the reserved fields.

Regards,

Hans

 
   + __u32   reserved[11];
   +};
   +
   
/*

 *   O V E R L A Y   P R E V I E W
 */
 
 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [3.2.y] drm/i915: add Ivy Bridge GT2 Server entries

[Ben Hutchings]

On Sun, 2012-10-07 at 15:11 +0100, Chris Wilson wrote:
 On Sun, 07 Oct 2012 15:01:17 +0100, Ben Hutchings b...@decadent.org.uk 
 wrote:
  On Mon, 2012-10-01 at 03:24 -0700, Jonathan Nieder wrote:
   Hi Ben,
   
   Please consider
   
 cc22a938fc1d drm/i915: add Ivy Bridge GT2 Server entries, 2012-03-29
   
   for application to the 3.2.y tree.  It adds a PCI id to the i915
   driver, making kms work.  It was applied during the 3.4-rc2 cycle, so
   newer stable kernels don't need it.
   
   Maik Zumstrull tried it[1] on top of 3.2.30 and found it to work ok
   (thanks!).
   
   Note that pre-2.4.34 versions of libdrm don't cope well with that
   card, with or without this patch:
  [...]
- with this patch, and with libdrm lacking 2.4.34~22 and 2.4.38~10,
  X freezes at startup.
   
   No regressions means you probably shouldn't take this patch without
   a safety to work around the old X userspace,
  [...]
  
  Then this workaround is also required in mainline.  And once that's
  done, I can take both patches.
 
 The bugs Jonathan mentions are both in userspace packages; not
 recognising the existence of Bromlow, and then misprogramming it.

Yes, I understand that.

 There
 are no other kernel patches required specifically for this chipset,
 afaik.

If upgrading the kernel currently triggers a (more) serious bug in
typical userland then the kernel should work around that.  If I've
misunderstood, and the userland behaviour is roughly equally broken with
or without this change, then I'll be happy to take it.

Ben.

-- 
Ben Hutchings
You can't have everything.  Where would you put it?


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 2/5] fence: dma-buf cross-device synchronization (v9)

[Maarten Lankhorst]

Op 28-09-12 14:42, Maarten Lankhorst schreef:
 A fence can be attached to a buffer which is being filled or consumed
 by hw, to allow userspace to pass the buffer without waiting to another
 device.  For example, userspace can call page_flip ioctl to display the
 next frame of graphics after kicking the GPU but while the GPU is still
 rendering.  The display device sharing the buffer with the GPU would
 attach a callback to get notified when the GPU's rendering-complete IRQ
 fires, to update the scan-out address of the display, without having to
 wake up userspace.

 A fence is transient, one-shot deal.  It is allocated and attached
 to one or more dma-buf's.  When the one that attached it is done, with
 the pending operation, it can signal the fence:
   + fence_signal()

 To have a rough approximation whether a fence is fired, call:
   + fence_is_signaled()

 The dma-buf-mgr handles tracking, and waiting on, the fences associated
 with a dma-buf.

 The one pending on the fence can add an async callback:
   + fence_add_callback()

 The callback can optionally be cancelled with:
   + fence_remove_callback()

 To wait synchronously, optionally with a timeout:
   + fence_wait()
   + fence_wait_timeout()

...

Implementing this makes the locking feel weird, instead of abusing
fence-event_queue.lock I think it would make sense to remove this part 
entirely,
and have a simply linked list plus a pointer to a spinlock.

enable_signaling should be called with this spinlock held. This way,
the enable_signaling callback would be easier to implement
and doesn't have to double check for races as much in there.

Also __fence_signal should be exported which would be the
same as fence_signal, but without taking the spinlock as separate
step, so it can be called with the spinlock held.

How do you feel about these proposed changes?

~Maarten

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

Re: [Intel-gfx] [3.2.y] drm/i915: add Ivy Bridge GT2 Server entries

[Julien Cristau]

On Mon, Oct  1, 2012 at 03:24:32 -0700, Jonathan Nieder wrote:

  - without this patch, modern X errors out instead of starting,
because the intel driver requires kms.  (In a hypothetical better
world, userspace would know to fall back to vesa or something.)
 
I'd expect X to start with vesa or fbdev, rather than erroring out?

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

[PATCH] drm: fix returning -EINVAL on setmaster if another master is active

[David Herrmann]

We link every DRM file_priv to a drm_master structure. Currently, the
drmSetMaster() call returns 0 when there is _any_ active master associated
with the drm_master structure of the calling file_priv. This means,
that after drmSetMaster() we are not guaranteed to be DRM-Master and might
not be able to perform mode-setting.

A way to reproduce this is by starting weston with the DRM backend from
within an X-console (eg., xterm). Because the xserver's drm_master is
currently active, weston is assigned to the same master but is inactive
because its VT is inactive and the xserver is still active. But when
fake-activating weston, it calls drmSetMaster(). With current behavior
this returns 0/success and weston thinks that it is DRM-Master, even
though it is not (as the xserver is still DRM-Master).
Expected behavior would be drmSetMaster() to return -EINVAL, because the
xserver is still DRM-Master. This patch changes exactly that.

The only way this bogus behavior would be useful is for clients to check
whether their associated drm_master is currently the active DRM-Master.
But this logic fails if no DRM-Master is currently active at all. Because
then the client itself would become DRM-Master (if it is root) and this
makes this whole thing useles.

Also note that the second if-condition:
  file_priv-minor-master != file_priv-master
is always true and can be skipped.

Signed-off-by: David Herrmann dh.herrm...@googlemail.com
---
Note:
Note that this only removes the if-clause. The code that performs the
setmaster() is actually left unchanged but makes the patch look scarier than it
really is.

 drivers/gpu/drm/drm_stub.c | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index c236fd2..581e61d 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -221,20 +221,20 @@ int drm_setmaster_ioctl(struct drm_device *dev, void 
*data,
if (!file_priv-master)
return -EINVAL;
 
-   if (!file_priv-minor-master 
-   file_priv-minor-master != file_priv-master) {
-   mutex_lock(dev-struct_mutex);
-   file_priv-minor-master = drm_master_get(file_priv-master);
-   file_priv-is_master = 1;
-   if (dev-driver-master_set) {
-   ret = dev-driver-master_set(dev, file_priv, false);
-   if (unlikely(ret != 0)) {
-   file_priv-is_master = 0;
-   drm_master_put(file_priv-minor-master);
-   }
+   if (file_priv-minor-master)
+   return -EINVAL;
+
+   mutex_lock(dev-struct_mutex);
+   file_priv-minor-master = drm_master_get(file_priv-master);
+   file_priv-is_master = 1;
+   if (dev-driver-master_set) {
+   ret = dev-driver-master_set(dev, file_priv, false);
+   if (unlikely(ret != 0)) {
+   file_priv-is_master = 0;
+   drm_master_put(file_priv-minor-master);
}
-   mutex_unlock(dev-struct_mutex);
}
+   mutex_unlock(dev-struct_mutex);
 
return 0;
 }
-- 
1.7.12.2

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

Re: question about drivers/gpu/drm/i915/dvo_ch7xxx.c

[Daniel Vetter]

On Sat, Oct 06, 2012 at 03:20:19PM +0200, Julia Lawall wrote:
 Hello,
 
 I am looking at introducing some macros for i2c_msg initialization,
 and Ryan Mallon suggested that sometimes it could be useful to at
 the same time replace explicit lengths with the size of the
 associated buffer.  But in some cases the sizes are not the same.
 An example is as follows, in drivers/gpu/drm/i915/dvo_ch7xxx.c:
 
 static bool ch7xxx_readb(struct intel_dvo_device *dvo, int addr,
 uint8_t *ch)
 {
 struct ch7xxx_priv *ch7xxx = dvo-dev_priv;
 struct i2c_adapter *adapter = dvo-i2c_bus;
 u8 out_buf[2];
 u8 in_buf[2];
 
 struct i2c_msg msgs[] = {
 {
 .addr = dvo-slave_addr,
 .flags = 0,
 .len = 1,
 .buf = out_buf,
 },
 {
 .addr = dvo-slave_addr,
 .flags = I2C_M_RD,
 .len = 1,
 .buf = in_buf,
 }
 };
 
 out_buf[0] = addr;
 out_buf[1] = 0;
 
 if (i2c_transfer(adapter, msgs, 2) == 2) {
 *ch = in_buf[0];
 return true;
 };
 
 if (!ch7xxx-quiet) {
 DRM_DEBUG_KMS(Unable to read register 0x%02x from 
 %s:%02x.\n,
   addr, adapter-name, dvo-slave_addr);
 }
 return false;
 }
 
 The buffers both have size 2, but only one byte is asked to be read
 or written.  Is there any need for the buffers to have size 2 in
 this case?

Looks like the 2 byte buffer size is just copypasta from writeb. And
didn't find any other reson for it not being just 1 byte.

 Unrelatedly, is it correct that ch has type uint8_t and out_buf and
 in_buf have type u8?

drm/i915 is totally confused about the (u)int*_t vs (s|t)* types
unfortunately. I think nowadays we mostly stick to _t typedefs, but not
consistenly.

Yours, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915: remove duplicated include from intel_modes.c

[Daniel Vetter]

On Sun, Oct 07, 2012 at 09:26:35PM +0800, Wei Yongjun wrote:
 From: Wei Yongjun yongjun_...@trendmicro.com.cn
 
 Remove duplicated include.
 
 dpatch engine is used to auto generate this patch.
 (https://github.com/weiyj/dpatch)
 
 Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn

Patch applied to drm-intel-next, thanks.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm merge for rc1 (part 1)

[Shentino]

On Thu, Oct 4, 2012 at 2:49 AM, David Howells dhowe...@redhat.com wrote:
 Linus Torvalds torva...@linux-foundation.org wrote:

 Ok, as usual I actually wanted to do the merge myself despite the
 annoying conflicts (this *really* is the last time I will ever accept
 any header file cleanups - they simply aren't worth the pain).

 There was a reason I asked you to pull the patches at the *end* of the merge
 window, and a reason I asked you to give me a chance to regenerate the patches
 before you pulled them.

 Anyway, I can feed much of the main set of patches through subsystem trees now
 - so thanks for that at least.

Saw this LWN article about the UAPI cleanup.

http://lwn.net/Articles/507794/

Have you had much feedback from subsystem maintainers about accepting
these?  I'm no kernel developer yet but I have had a keen interest in
this patch set ever since I heard of it.

 David
 --
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/i915: remove duplicated include from intel_modes.c

[Wei Yongjun]

From: Wei Yongjun yongjun_...@trendmicro.com.cn

Remove duplicated include.

dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)

Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
 drivers/gpu/drm/i915/intel_modes.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_modes.c 
b/drivers/gpu/drm/i915/intel_modes.c
index cabd84b..8c97b7a 100644
--- a/drivers/gpu/drm/i915/intel_modes.c
+++ b/drivers/gpu/drm/i915/intel_modes.c
@@ -28,7 +28,6 @@
 #include linux/fb.h
 #include drm/drm_edid.h
 #include drm/drmP.h
-#include drm/drm_edid.h
 #include intel_drv.h
 #include i915_drv.h
 

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

[PATCH] drm/nouveau: remove duplicated include from nouveau_drm.c

[Wei Yongjun]

From: Wei Yongjun yongjun_...@trendmicro.com.cn

Remove duplicated include.

dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)

Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
 drivers/gpu/drm/nouveau/nouveau_drm.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index ccae8c2..f5c8ccf 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -49,7 +49,6 @@
 #include nouveau_fbcon.h
 #include nouveau_fence.h
 
-#include nouveau_ttm.h
 
 MODULE_PARM_DESC(config, option string to pass to driver core);
 static char *nouveau_config;

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

[PATCH] gma500: medfield: fix potential NULL pointer dereference in mdfld_dsi_output_init()

[Wei Yongjun]

From: Wei Yongjun yongjun_...@trendmicro.com.cn

The dereference should be moved below the NULL test.

dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)

Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
 drivers/gpu/drm/gma500/mdfld_dsi_output.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/gma500/mdfld_dsi_output.c 
b/drivers/gpu/drm/gma500/mdfld_dsi_output.c
index 32dba2a..f92932f 100644
--- a/drivers/gpu/drm/gma500/mdfld_dsi_output.c
+++ b/drivers/gpu/drm/gma500/mdfld_dsi_output.c
@@ -500,17 +500,18 @@ void mdfld_dsi_output_init(struct drm_device *dev,
struct mdfld_dsi_connector *dsi_connector;
struct drm_connector *connector;
struct mdfld_dsi_encoder *encoder;
-   struct drm_psb_private *dev_priv = dev-dev_private;
+   struct drm_psb_private *dev_priv;
struct panel_info dsi_panel_info;
u32 width_mm, height_mm;
 
-   dev_dbg(dev-dev, init DSI output on pipe %d\n, pipe);
-
if (!dev || ((pipe != 0)  (pipe != 2))) {
DRM_ERROR(Invalid parameter\n);
return;
}
 
+   dev_dbg(dev-dev, init DSI output on pipe %d\n, pipe);
+   dev_priv = dev-dev_private;
+
/*create a new connetor*/
dsi_connector = kzalloc(sizeof(struct mdfld_dsi_connector), GFP_KERNEL);
if (!dsi_connector) {

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

Re: [Intel-gfx] [3.2.y] drm/i915: add Ivy Bridge GT2 Server entries

[Maik Zumstrull]

On Sun, Oct 7, 2012 at 7:26 PM, Julien Cristau jcris...@debian.org wrote:
 On Mon, Oct  1, 2012 at 03:24:32 -0700, Jonathan Nieder wrote:

  - without this patch, modern X errors out instead of starting,
because the intel driver requires kms.  (In a hypothetical better
world, userspace would know to fall back to vesa or something.)

 I'd expect X to start with vesa or fbdev, rather than erroring out?

There's a corner case when X and the kernel know about the graphics
device, but libdrm doesn't, in which case an assertion in the X driver
fails and X doesn't start. Upstream libdrm has been okay for a few
releases. A bug against Debian libdrm has been open for a while, but
they seem to disagree about the importance, nothing has happened. In
fairness, this device seems to be rare so far. I'm not really using
mine any more, I put an extra graphics card in the box.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [3.2.y] drm/i915: add Ivy Bridge GT2 Server entries

[Jonathan Nieder]

Maik Zumstrull wrote:
 On Sun, Oct 7, 2012 at 7:26 PM, Julien Cristau jcris...@debian.org wrote:
 On Mon, Oct  1, 2012 at 03:24:32 -0700, Jonathan Nieder wrote:

  - without this patch, modern X errors out instead of starting,
[...]
 I'd expect X to start with vesa or fbdev, rather than erroring out?

 There's a corner case when X and the kernel know about the graphics
 device, but libdrm doesn't, in which case an assertion in the X driver
 fails and X doesn't start. Upstream libdrm has been okay for a few
 releases.

I think Julien means the case where the kernel does not know about the
graphics device.  From [1]:

| 3.2 crashes as well, but not as hard as 3.4. With 3.2, X doesn't come
| up, but you can switch to a console and reboot. 3.4 needs the reset
| button.

X should have been able to start using the vesa or fbdev driver.  I'm
not sure why that doesn't happen --- do you have an Xorg log from
booting and trying to start X with a 3.2.y kernel without the
drm/i915: add Ivy Bridge GT2 Server entries patch?

Thanks,
Jonathan

[1] http://bugs.debian.org/684767
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [3.2.y] drm/i915: add Ivy Bridge GT2 Server entries

[Maik Zumstrull]

On Sun, Oct 7, 2012 at 7:44 PM, Jonathan Nieder jrnie...@gmail.com wrote:

 X should have been able to start using the vesa or fbdev driver.  I'm
 not sure why that doesn't happen --- do you have an Xorg log from
 booting and trying to start X with a 3.2.y kernel without the
 drm/i915: add Ivy Bridge GT2 Server entries patch?

No, and it would be a bit of fiddling to get one. Like I said, I've
modified that system with a graphics card since. If it's important, I
could get it done, but probably not next week, I'll be traveling and
otherwise busy.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC libdrm] freedreno: add freedreno DRM

[Rob Clark]

The libdrm_freedreno helper layer for use by xf86-video-freedreno,
fdre (freedreno r/e library and tests for driving gpu), and eventual
gallium driver for the Adreno GPU.  This uses the msm gpu driver
from QCOM's android kernel tree.

Note that current msm kernel driver is a bit strange.  It provides a
DRM interface for GEM, which is basically sufficient to have DRI2
working.  But it does not provide KMS.  And interface to 2d and 3d
cores is via different other devices (/dev/kgsl-*).  This is not
quite how I'd write a DRM driver, but at this stage it is useful for
xf86-video-freedreno and fdre (and eventual gallium driver) to be
able to work on existing kernel driver from QCOM, to allow to
capture cmdstream dumps from the binary blob drivers without having
to reboot.  So libdrm_freedreno attempts to hide most of the crazy.
The intention is that when there is a proper kernel driver, it will
be mostly just changes in libdrm_freedreno to adapt the gallium
driver and xf86-video-freedreno (ignoring the fbdev-KMS changes).

So don't look at freedreno as an example of how to write a libdrm
module or a DRM driver.. it is just an attempt to paper over a non-
standard kernel driver architecture.

Signed-off-by: Rob Clark robcl...@freedesktop.org
---
 .gitignore   |1 +
 Makefile.am  |6 +-
 configure.ac |   13 +
 freedreno/Makefile.am|   19 ++
 freedreno/README |   16 ++
 freedreno/freedreno_bo.c |  229 +
 freedreno/freedreno_device.c |   45 
 freedreno/freedreno_drmif.h  |   97 +++
 freedreno/freedreno_pipe.c   |  163 
 freedreno/freedreno_priv.h   |   90 +++
 freedreno/freedreno_ringbuffer.c |  123 +
 freedreno/freedreno_ringbuffer.h |   75 ++
 freedreno/kgsl_drm.h |  192 ++
 freedreno/libdrm_freedreno.pc.in |   11 +
 freedreno/msm_kgsl.h |  519 ++
 15 files changed, 1598 insertions(+), 1 deletion(-)
 create mode 100644 freedreno/Makefile.am
 create mode 100644 freedreno/README
 create mode 100644 freedreno/freedreno_bo.c
 create mode 100644 freedreno/freedreno_device.c
 create mode 100644 freedreno/freedreno_drmif.h
 create mode 100644 freedreno/freedreno_pipe.c
 create mode 100644 freedreno/freedreno_priv.h
 create mode 100644 freedreno/freedreno_ringbuffer.c
 create mode 100644 freedreno/freedreno_ringbuffer.h
 create mode 100644 freedreno/kgsl_drm.h
 create mode 100644 freedreno/libdrm_freedreno.pc.in
 create mode 100644 freedreno/msm_kgsl.h

diff --git a/.gitignore b/.gitignore
index 243457e..a20a3eb 100644
--- a/.gitignore
+++ b/.gitignore
@@ -42,6 +42,7 @@ libdrm.pc
 libdrm_intel.pc
 libdrm_nouveau.pc
 libdrm_radeon.pc
+libdrm_freedreno.pc
 libkms.pc
 libtool
 ltmain.sh
diff --git a/Makefile.am b/Makefile.am
index 8ecd9d9..ebf2ae2 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -49,7 +49,11 @@ if HAVE_EXYNOS
 EXYNOS_SUBDIR = exynos
 endif
 
-SUBDIRS = . $(LIBKMS_SUBDIR) $(INTEL_SUBDIR) $(NOUVEAU_SUBDIR) 
$(RADEON_SUBDIR) $(OMAP_SUBDIR) $(EXYNOS_SUBDIR) tests include man
+if HAVE_FREEDRENO
+FREEDRENO_SUBDIR = freedreno
+endif
+
+SUBDIRS = . $(LIBKMS_SUBDIR) $(INTEL_SUBDIR) $(NOUVEAU_SUBDIR) 
$(RADEON_SUBDIR) $(OMAP_SUBDIR) $(EXYNOS_SUBDIR) $(FREEDRENO_SUBDIR) tests 
include man
 
 libdrm_la_LTLIBRARIES = libdrm.la
 libdrm_ladir = $(libdir)
diff --git a/configure.ac b/configure.ac
index 290362c..8ce6011 100644
--- a/configure.ac
+++ b/configure.ac
@@ -114,6 +114,11 @@ AC_ARG_ENABLE(exynos-experimental-api,
  [Enable support for EXYNOS's experimental API (default: 
disabled)]),
  [EXYNOS=$enableval], [EXYNOS=no])
 
+AC_ARG_ENABLE(freedreno-experimental-api,
+ AS_HELP_STRING([--enable-freedreno-experimental-api],
+ [Enable support for freedreno's experimental API (default: 
disabled)]),
+ [FREEDRENO=$enableval], [FREEDRENO=no])
+
 dnl ===
 dnl check compiler flags
 AC_DEFUN([LIBDRM_CC_TRY_FLAG], [
@@ -222,6 +227,11 @@ if test x$EXYNOS = xyes; then
AC_DEFINE(HAVE_EXYNOS, 1, [Have EXYNOS support])
 fi
 
+AM_CONDITIONAL(HAVE_FREEDRENO, [test x$FREEDRENO = xyes])
+if test x$FREEDRENO = xyes; then
+   AC_DEFINE(HAVE_FREEDRENO, 1, [Have freedreno support])
+fi
+
 PKG_CHECK_MODULES(CAIRO, cairo, [HAVE_CAIRO=yes], [HAVE_CAIRO=no])
 if test x$HAVE_CAIRO = xyes; then
AC_DEFINE(HAVE_CAIRO, 1, [Have cairo support])
@@ -346,6 +356,8 @@ AC_CONFIG_FILES([
omap/libdrm_omap.pc
exynos/Makefile
exynos/libdrm_exynos.pc
+   freedreno/Makefile
+   freedreno/libdrm_freedreno.pc
tests/Makefile
tests/modeprint/Makefile
tests/modetest/Makefile
@@ -368,4 +380,5 @@ echo   Radeon API $RADEON
 echo   Nouveau API$NOUVEAU
 echo   OMAP API   $OMAP
 echo   EXYNOS API $EXYNOS
+echo   

[git pull] drm for 3.7-rc1 (part 2)

[Dave Airlie]

Hi Linus,

This is the follow-up pull, 3 pieces

a) exynos next stuff, was delayed but looks okay to me, one patch in v4l 
bits but it was acked by v4l person.
b) UAPI disintegration bits
c) intel fixes - DP fixes, hang fixes, other misc fixes.

Dave.

The following changes since commit 0b8e74c6f44094189dbe78baf4101acc7570c6af:

  Merge branch 'v4l_for_linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media (2012-10-07 
17:49:05 +0900)

are available in the git repository at:


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

for you to fetch changes up to 1f31c69dac71bebc0f00bc8534a6345782045501:

  Merge branch 'drm-intel-fixes' of 
git://people.freedesktop.org/~danvet/drm-intel into drm-next (2012-10-07 
21:13:54 +1000)



Adam Jackson (6):
  drm: Export drm_probe_ddc()
  drm/dp: Update DPCD defines
  drm/i915/dp: Fetch downstream port info if needed during DPCD fetch
  drm/i915/dp: Be smarter about connection sense for branch devices
  drm/dp: Document DP spec versions for various DPCD registers
  drm/dp: Make sink count DP 1.2 aware

Ben Widawsky (2):
  drm/i915: Fix set_caching locking
  drm/i915: Fix GT_MODE default value

Chris Wilson (3):
  drm/i915: Actually invalidate the TLB for the SandyBridge HW contexts w/a
  drm/i915: Flush the pending flips on the CRTC before modification
  drm/i915: Try harder to complete DP training pattern 1

Daniel Vetter (2):
  drm/i915: call drm_handle_vblank before finish_page_flip
  drm/i915: don't frob the vblank ts in finish_page_flip

Dave Airlie (3):
  Merge branch 'disintegrate-drm' of 
git://git.infradead.org/users/dhowells/linux-headers into drm-next
  Merge branch 'exynos-drm-next' of 
git://git.infradead.org/users/kmpark/linux-samsung into drm-next
  Merge branch 'drm-intel-fixes' of 
git://people.freedesktop.org/~danvet/drm-intel into drm-next

David Howells (1):
  UAPI: (Scripted) Disintegrate include/drm

Dmitry Rogozhkin (1):
  drm/i915: EBUSY status handling added to i915_gem_fault().

Inki Dae (16):
  drm/exynos: added device object to subdrv's remove callback as argument
  drm/exynos: separated subdrv_probe function into two parts.
  drm/exynos: separeated fimd_power_on into some parts.
  drm/exynos: fixed duplicated mode setting.
  drm/exynos: add wait_for_vblank callback interface.
  drm/exynos: make sure that hardware overlay for fimd is disabled
  drm/exynos: make sure that hardware overlay for hdmi is disabled
  drm/exynos: check NV12M format specific to Exynos properly
  drm/exynos: update crtc to plane safely
  drm/exynos: Disable plane when released
  drm/exynos: add pid to g2d_runqueue_node
  drm/exynos: fix duplicated mutex lock issue
  drm/exynos: check crtc's dpms mode at page flip
  drm/exynos: check crtc's dpms mode at SetCrtc
  drm/exynos: support drm_wait_vblank feature for VIDI
  drm/exynos: fix display power call issue.

Jani Nikula (1):
  drm/i915: use adjusted_mode instead of mode for checking the 6bpc force 
flag

Jesse Barnes (1):
  drm/i915: set swizzling to none on VLV

Joonyoung Shim (2):
  drm/exynos: fix to calculate CRTC shown via screen
  drm/exynos: fix kcalloc size of g2d cmdlist node

Leela Krishna Amudala (1):
  drm/exynos: add platform_device_id table and driver data for drm fimd

Mika Kuoppala (1):
  drm/i915: print warning if vmi915_gem_fault error is not handled

Rahul Sharma (9):
  drm: exynos: remove drm hdmi platform data struct
  drm: exynos: hdmi: add support for exynos5 ddc
  drm: exynos: hdmi: add support for exynos5 hdmiphy
  drm: exynos: hdmi: add support for platform variants for mixer
  drm: exynos: hdmi: add support to disable video processor in mixer
  drm: exynos: hdmi: add support for exynos5 mixer
  drm: exynos: hdmi: replace is_v13 with version check in hdmi
  drm: exynos: hdmi: add support for exynos5 hdmi
  drm: exynos: hdmi: remove drm common hdmi platform data struct

Sachin Kamat (1):
  drm/exynos: Fix potential NULL pointer dereference

Tomasz Stanislawski (5):
  media: s5p-hdmi: add HPD GPIO to platform data
  drm: exynos: hdmi: support for platform variants
  drm: exynos: hdmi: fix interrupt handling
  drm: exynos: hdmi: use s5p-hdmi platform data
  drm: exynos: hdmi: turn off HPD interrupt in HDMI chip

 drivers/gpu/drm/drm_edid.c|3 +-
 drivers/gpu/drm/exynos/exynos_ddc.c   |   22 +-
 drivers/gpu/drm/exynos/exynos_drm_connector.c |   50 +-
 drivers/gpu/drm/exynos/exynos_drm_connector.h |4 +
 drivers/gpu/drm/exynos/exynos_drm_core.c  |  100 ++-
 drivers/gpu/drm/exynos/exynos_drm_crtc.c  |   20 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |   19 +-
 drivers/gpu/drm/exynos/exynos_drm_encoder.c   |  116 ++-
 

[PATCH 0/3] Android support

[Tapani Pälli]

Upstreaming old set of patches here to enable Android support in libdrm.
Some little rebasing was required for the first one.

Chad Versace (2):
  libdrm,intel: Factor source file lists into sources.mk
  libdrm,intel: Add Android makefiles (v2)

Haitao Huang (1):
  Android.mk: use LOCAL_COPY_HEADERS to export headers.

 Android.mk| 62 +++
 Makefile.am   |  9 
 intel/Android.mk  | 57 ++
 intel/Makefile.am |  9 
 intel/sources.mk  | 30 +++
 sources.mk| 30 +++
 6 files changed, 187 insertions(+), 10 deletions(-)
 create mode 100644 Android.mk
 create mode 100644 intel/Android.mk
 create mode 100644 intel/sources.mk
 create mode 100644 sources.mk

-- 
1.7.11.7

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