Re: [PATCH libdrm] libdrm: update drm/drm_fourcc.h from kernel to add multi plane formats

[Ville Syrjälä]

On Fri, Apr 06, 2012 at 03:05:36PM +0900, Inki Dae wrote:
> Hi Ville,
> 
> > -Original Message-
> > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> > Sent: Friday, April 06, 2012 3:14 AM
> > To: airl...@redhat.com
> > Cc: inki@samsung.com; kyungmin.p...@samsung.com; dri-
> > de...@lists.freedesktop.org; Seung-Woo Kim
> > Subject: Re: [PATCH libdrm] libdrm: update drm/drm_fourcc.h from kernel to
> > add multi plane formats
> > 
> > On Fri, Mar 30, 2012 at 01:12:58PM +0300, Ville Syrjälä wrote:
> > > On Fri, Mar 30, 2012 at 11:54:50AM +0900, Seung-Woo Kim wrote:
> > > > Multi buffer plane pixel formats are added as like kernel header.
> > > >
> > > > Signed-off-by: Seung-Woo Kim 
> > > > ---
> > > >  include/drm/drm_fourcc.h |7 +++
> > > >  1 files changed, 7 insertions(+), 0 deletions(-)
> > > >
> > > > diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
> > > > index 85facb0..7cfd95a 100644
> > > > --- a/include/drm/drm_fourcc.h
> > > > +++ b/include/drm/drm_fourcc.h
> > > > @@ -107,6 +107,10 @@
> > > >  #define DRM_FORMAT_NV16fourcc_code('N', 'V', '1', '6') 
> > > > /*
> > 2x1 subsampled Cr:Cb plane */
> > > >  #define DRM_FORMAT_NV61fourcc_code('N', 'V', '6', '1') 
> > > > /*
> > 2x1 subsampled Cb:Cr plane */
> > > >
> > > > +/* 2 non contiguous plane YCbCr */
> > > > +#define DRM_FORMAT_NV12M   fourcc_code('N', 'M', '1', '2') /* 2x2
> > subsampled Cr:Cb plane */
> > >
> > > NAK. DRM_FORMAT_NV12 handles this just fine.
> > 
> > And I just realized that I was already too late with my NAK since this a
> > libdrm patch. Apparently the kernel drm_fourcc.h changes were snuck in
> > via some backdoor without review. Sigh.
> > 
> 
> We had already requested review for it. for this you can refer to link
> below:
>   
> http://lists.freedesktop.org/archives/dri-devel/2011-December/017654.html

I see. I couldn't find it in my work mailbox for some reason, and I
don't remember having seen the patch before. I suppose I just missed it
due to Christmas vacations, and was too blind to see it in my mailbox.
Also google decicded to filter my search results too much, so I didn't
spot it via the web archives either. I'm sorry for the false accusation.

> > So they're now in Linus's tree. But looks like format_check() was never
> > updated to accept them, so there's no way anyone could actually be using
> > them. So Dave, can we still remove them from the kernel header?
> > 
> 
> Yes, right. these formats aren't used for any SoCs except Exynos series yet
> but just we are first. I think they should be added because anyone may use
> them someday at least possible.

Since DRM_FORMAT_NV12M is _identical_ to DRM_FORMAT_NV12, I see no point
in adding it (similarly for YUV420M vs. YUV420).

-- 
Ville Syrjälä
syrj...@sci.fi
http://www.sci.fi/~syrjala/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm] libdrm: update drm/drm_fourcc.h from kernel to add multi plane formats

[Kyungmin Park]

+ V4L2 develper
Sylwester, please give your opinions? How to handle it at v4l2 side.

Thank you,
Kyungmin Park
On Apr 6, 2012 12:44 AM, "Ville Syrjälä"  wrote:

> On Fri, Apr 06, 2012 at 03:05:36PM +0900, Inki Dae wrote:
> > Hi Ville,
> >
> > > -Original Message-
> > > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> > > Sent: Friday, April 06, 2012 3:14 AM
> > > To: airl...@redhat.com
> > > Cc: inki@samsung.com; kyungmin.p...@samsung.com; dri-
> > > de...@lists.freedesktop.org; Seung-Woo Kim
> > > Subject: Re: [PATCH libdrm] libdrm: update drm/drm_fourcc.h from
> kernel to
> > > add multi plane formats
> > >
> > > On Fri, Mar 30, 2012 at 01:12:58PM +0300, Ville Syrjälä wrote:
> > > > On Fri, Mar 30, 2012 at 11:54:50AM +0900, Seung-Woo Kim wrote:
> > > > > Multi buffer plane pixel formats are added as like kernel header.
> > > > >
> > > > > Signed-off-by: Seung-Woo Kim 
> > > > > ---
> > > > >  include/drm/drm_fourcc.h |7 +++
> > > > >  1 files changed, 7 insertions(+), 0 deletions(-)
> > > > >
> > > > > diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
> > > > > index 85facb0..7cfd95a 100644
> > > > > --- a/include/drm/drm_fourcc.h
> > > > > +++ b/include/drm/drm_fourcc.h
> > > > > @@ -107,6 +107,10 @@
> > > > >  #define DRM_FORMAT_NV16fourcc_code('N', 'V', '1',
> '6') /*
> > > 2x1 subsampled Cr:Cb plane */
> > > > >  #define DRM_FORMAT_NV61fourcc_code('N', 'V', '6',
> '1') /*
> > > 2x1 subsampled Cb:Cr plane */
> > > > >
> > > > > +/* 2 non contiguous plane YCbCr */
> > > > > +#define DRM_FORMAT_NV12M   fourcc_code('N', 'M', '1', '2') /*
> 2x2
> > > subsampled Cr:Cb plane */
> > > >
> > > > NAK. DRM_FORMAT_NV12 handles this just fine.
> > >
> > > And I just realized that I was already too late with my NAK since this
> a
> > > libdrm patch. Apparently the kernel drm_fourcc.h changes were snuck in
> > > via some backdoor without review. Sigh.
> > >
> >
> > We had already requested review for it. for this you can refer to link
> > below:
> >
> >
> http://lists.freedesktop.org/archives/dri-devel/2011-December/017654.html
>
> I see. I couldn't find it in my work mailbox for some reason, and I
> don't remember having seen the patch before. I suppose I just missed it
> due to Christmas vacations, and was too blind to see it in my mailbox.
> Also google decicded to filter my search results too much, so I didn't
> spot it via the web archives either. I'm sorry for the false accusation.
>
> > > So they're now in Linus's tree. But looks like format_check() was never
> > > updated to accept them, so there's no way anyone could actually be
> using
> > > them. So Dave, can we still remove them from the kernel header?
> > >
> >
> > Yes, right. these formats aren't used for any SoCs except Exynos series
> yet
> > but just we are first. I think they should be added because anyone may
> use
> > them someday at least possible.
>
> Since DRM_FORMAT_NV12M is _identical_ to DRM_FORMAT_NV12, I see no point
> in adding it (similarly for YUV420M vs. YUV420).
>
> --
> Ville Syrjälä
> syrj...@sci.fi
> http://www.sci.fi/~syrjala/
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: Linux 3.4-rc1

[Marek Szyprowski]

Hi,

On Wednesday, April 04, 2012 2:34 PM Anca Emanuel

> @Subash Patel, prime is already included.
> 
> Why the CMA is at 24 version and still not included ?
> Linus, please include
> CMA,git://git.linaro.org/people/mszyprowski/linux-dma-mapping.git
> 3.4-rc1-cma-v24

CMA is expected to be merged via akpm tree together with other core memory 
management
patches. I got a message that Andrew Morton scheduled it for v3.5 kernel, so it 
should
be soon available in linux-next tree.

Best regards
-- 
Marek Szyprowski
Samsung Poland R&D Center

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

Re: [PATCH 02/11] Documentation: media: description of DMABUF importing in V4L2

[Rémi Denis-Courmont]

Le jeudi 5 avril 2012 16:59:59 Tomasz Stanislawski, vous avez écrit :
> This patch adds description and usage examples for importing
> DMABUF file descriptor in V4L2.
> 
> Signed-off-by: Tomasz Stanislawski 
> Signed-off-by: Kyungmin Park 
> ---
>  Documentation/DocBook/media/v4l/compat.xml |4 +
>  Documentation/DocBook/media/v4l/io.xml |  177
>  .../DocBook/media/v4l/vidioc-create-bufs.xml   | 
>   1 +
>  Documentation/DocBook/media/v4l/vidioc-qbuf.xml|   15 ++
>  Documentation/DocBook/media/v4l/vidioc-reqbufs.xml |8 +-
>  5 files changed, 203 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/DocBook/media/v4l/compat.xml
> b/Documentation/DocBook/media/v4l/compat.xml index bce97c5..2a2083d 100644
> --- a/Documentation/DocBook/media/v4l/compat.xml
> +++ b/Documentation/DocBook/media/v4l/compat.xml
> @@ -2523,6 +2523,10 @@ ioctls.
>  
> Selection API. 
>  
> +
> +   Importing DMABUF file descriptors as a new IO method described
> +   in .
> +
>
>  
> 
> diff --git a/Documentation/DocBook/media/v4l/io.xml
> b/Documentation/DocBook/media/v4l/io.xml index b815929..2a32363 100644
> --- a/Documentation/DocBook/media/v4l/io.xml
> +++ b/Documentation/DocBook/media/v4l/io.xml
> @@ -472,6 +472,160 @@ rest should be evident.
>
>
> 
> +  
> +Streaming I/O (DMA buffer importing)
> +
> +
> +  Experimental
> +  This is an  experimental 
> +  interface and may change in the future.
> +
> +
> +The DMABUF framework was introduced to provide a generic mean for
> sharing +buffers between multiple HW devices. Some device drivers provide
> an API that +may be capable to export a DMA buffer as a DMABUF file
> descriptor. The other +device drivers may be configured to use such a
> buffer. They implements an API +for importing of DMABUF. This section
> describes the support of DMABUF importing +in V4L2.
> +
> +Input and output devices support this I/O method when the
> +V4L2_CAP_STREAMING flag in the
> +capabilities field of &v4l2-capability;
> returned by +the &VIDIOC-QUERYCAP; ioctl is set. If the particular
> importing buffer via +DMABUF file descriptors method is supported must be
> determined by calling the +&VIDIOC-REQBUFS; ioctl.
> +
> +This I/O method is dedicated for sharing DMA buffers between V4L
> and +other APIs. Buffers (planes) are allocated by the application itself
> using +a client API. The buffers must be exported as DMABUF file
> descriptor.  Only those +file descriptor are exchanged, these files and
> meta-information are passed in +&v4l2-buffer; (or in &v4l2-plane; in the
> multi-planar API case).  The driver +must be switched into DMABUF I/O mode
> by calling the &VIDIOC-REQBUFS; with the +desired buffer type. No buffers
> (planes) are allocated beforehand, consequently +they are not indexed and
> cannot be queried like mapped buffers with the
> +VIDIOC_QUERYBUF ioctl.
> +
> +
> +  Initiating streaming I/O with DMABUF file descriptors
> +
> +  
> +&v4l2-requestbuffers; reqbuf;
> +
> +memset (&reqbuf, 0, sizeof (reqbuf));
> +reqbuf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
> +reqbuf.memory = V4L2_MEMORY_DMABUF;
> +
> +if (ioctl (fd, &VIDIOC-REQBUFS;, &reqbuf) == -1) {
> + if (errno == EINVAL)
> + printf ("Video capturing or user pointer streaming is not 
supported\n");

User pointer??

> + else
> + perror ("VIDIOC_REQBUFS");
> +
> + exit (EXIT_FAILURE);
> +}
> +  
> +
> +
> +Buffer (plane) file is passed on the fly with the &VIDIOC-QBUF;
> +ioctl. In case of multiplanar buffers, every plane can be associated with
> a +different DMABUF descriptor.Although buffers are commonly cycled,
> applications +can pass different DMABUF descriptor at each
> VIDIOC_QBUF +call.
> +
> +
> +  Queueing DMABUF using single plane API
> +
> +  
> +int buffer_queue(int v4lfd, int index, int dmafd)
> +{
> + &v4l2-buffer; buf;
> +
> + memset(&buf, 0, sizeof buf);
> + buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
> + buf.memory = V4L2_MEMORY_DMABUF;
> + buf.index = index;
> + buf.m.fd = dmafd;
> +
> + if (ioctl (v4lfd, &VIDIOC-QBUF;, &buf) == -1) {
> + perror ("VIDIOC_QBUF");
> + return -1;
> + }
> +
> + return 0;
> +}
> +  
> +
> +
> +
> +  Queueing DMABUF using multi plane API
> +
> +  
> +int buffer_queue_mp(int v4lfd, int index, int dmafd[], int n_planes)
> +{
> + &v4l2-buffer; buf;
> + &v4l2-plane; planes[VIDEO_MAX_PLANES];
> + int i;
> +
> + memset(&buf, 0, sizeof buf);
> + buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE;
> + buf.memory = V4L2_MEMORY_DMABUF;
> + buf.index = index;
> + buf.m.planes = planes;
> + buf.length = n_planes;
> +
> + memset(&planes, 0, sizeof planes);
> +
> + for (i = 0; i < n_planes; ++i)
> + buf.m.planes[i].m.fd = dmafd[i];
> +
> + if (io

Re: [PATCH 03/11] v4l: vb2: add support for shared buffer (dma_buf)

[Rémi Denis-Courmont]

Le jeudi 5 avril 2012 17:00:00 Tomasz Stanislawski, vous avez écrit :
> From: Sumit Semwal 
> 
> This patch adds support for DMABUF memory type in videobuf2. It calls
> relevant APIs of dma_buf for v4l reqbuf / qbuf / dqbuf operations.
> 
> For this version, the support is for videobuf2 as a user of the shared
> buffer; so the allocation of the buffer is done outside of V4L2. [A sample
> allocator of dma-buf shared buffer is given at [1]]
> 
> [1]: Rob Clark's DRM:
>https://github.com/robclark/kernel-omap4/commits/drmplane-dmabuf
> 
> Signed-off-by: Tomasz Stanislawski 
>[original work in the PoC for buffer sharing]
> Signed-off-by: Sumit Semwal 
> Signed-off-by: Sumit Semwal 
> ---
>  drivers/media/video/videobuf2-core.c |  184
> +- include/media/videobuf2-core.h   | 
>  31 ++
>  2 files changed, 214 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/media/video/videobuf2-core.c
> b/drivers/media/video/videobuf2-core.c index 2e8f1df..b37feea 100644
> --- a/drivers/media/video/videobuf2-core.c
> +++ b/drivers/media/video/videobuf2-core.c
> @@ -106,6 +106,27 @@ static void __vb2_buf_userptr_put(struct vb2_buffer
> *vb) }
> 
>  /**
> + * __vb2_buf_dmabuf_put() - release memory associated with
> + * a DMABUF shared buffer
> + */
> +static void __vb2_buf_dmabuf_put(struct vb2_buffer *vb)
> +{
> + struct vb2_queue *q = vb->vb2_queue;
> + unsigned int plane;
> +
> + for (plane = 0; plane < vb->num_planes; ++plane) {
> + void *mem_priv = vb->planes[plane].mem_priv;
> +
> + if (mem_priv) {
> + call_memop(q, detach_dmabuf, mem_priv);
> + dma_buf_put(vb->planes[plane].dbuf);
> + vb->planes[plane].dbuf = NULL;
> + vb->planes[plane].mem_priv = NULL;
> + }
> + }
> +}
> +
> +/**
>   * __setup_offsets() - setup unique offsets ("cookies") for every plane in
>   * every buffer on the queue
>   */
> @@ -227,6 +248,8 @@ static void __vb2_free_mem(struct vb2_queue *q,
> unsigned int buffers) /* Free MMAP buffers or release USERPTR buffers */
>   if (q->memory == V4L2_MEMORY_MMAP)
>   __vb2_buf_mem_free(vb);

Missing 'else' here? A switch() statement might be better?

> + if (q->memory == V4L2_MEMORY_DMABUF)
> + __vb2_buf_dmabuf_put(vb);
>   else
>   __vb2_buf_userptr_put(vb);
>   }
> @@ -349,6 +372,12 @@ static int __fill_v4l2_buffer(struct vb2_buffer *vb,
> struct v4l2_buffer *b) */
>   memcpy(b->m.planes, vb->v4l2_planes,
>   b->length * sizeof(struct v4l2_plane));
> +
> + if (q->memory == V4L2_MEMORY_DMABUF) {
> + unsigned int plane;
> + for (plane = 0; plane < vb->num_planes; ++plane)
> + b->m.planes[plane].m.fd = 0;
> + }
>   } else {
>   /*
>* We use length and offset in v4l2_planes array even for
> @@ -360,6 +389,8 @@ static int __fill_v4l2_buffer(struct vb2_buffer *vb,
> struct v4l2_buffer *b) b->m.offset = vb->v4l2_planes[0].m.mem_offset;
>   else if (q->memory == V4L2_MEMORY_USERPTR)
>   b->m.userptr = vb->v4l2_planes[0].m.userptr;
> + else if (q->memory == V4L2_MEMORY_DMABUF)
> + b->m.fd = 0;
>   }
> 
>   /*
> @@ -451,6 +482,21 @@ static int __verify_mmap_ops(struct vb2_queue *q)
>  }
> 
>  /**
> + * __verify_dmabuf_ops() - verify that all memory operations required for
> + * DMABUF queue type have been provided
> + */
> +static int __verify_dmabuf_ops(struct vb2_queue *q)
> +{
> + if (!(q->io_modes & VB2_DMABUF) || !q->mem_ops->attach_dmabuf
> + || !q->mem_ops->detach_dmabuf
> + || !q->mem_ops->map_dmabuf
> + || !q->mem_ops->unmap_dmabuf)
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> +/**
>   * vb2_reqbufs() - Initiate streaming
>   * @q:   videobuf2 queue
>   * @req: struct passed from userspace to vidioc_reqbufs handler in 
driver
> @@ -484,6 +530,7 @@ int vb2_reqbufs(struct vb2_queue *q, struct
> v4l2_requestbuffers *req) }
> 
>   if (req->memory != V4L2_MEMORY_MMAP
> + && req->memory != V4L2_MEMORY_DMABUF
>   && req->memory != V4L2_MEMORY_USERPTR) {
>   dprintk(1, "reqbufs: unsupported memory type\n");
>   return -EINVAL;
> @@ -513,6 +560,11 @@ int vb2_reqbufs(struct vb2_queue *q, struct
> v4l2_requestbuffers *req) return -EINVAL;
>   }
> 
> + if (req->memory == V4L2_MEMORY_DMABUF && __verify_dmabuf_ops(q)) {
> + dprintk(1, "reqbufs: DMABUF for current setup unsupported\n");
> + return -EINVAL;
> + }
> +
>   if (req->count == 0 || q->num_buffers != 0 || q->memory != req->memory) 
> {
>   /*
>

[Bug 36769] Sporadic corruption of hardware cursor.

[bugzilla-daemon]

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

--- Comment #7 from Chris Rankin  2012-04-06 03:55:36 
PDT ---
(In reply to comment #6)
> Possibly a duplicate of bug 46796.
Or vice versa?

> Can you try the patch there or a 3.4 kernel snapshot?
I believe that this patch has now been added to both 3.2 and 3.3 stable trees
too. And no, the problem hasn't reoccurred yet - but it's still early days. I
never had a reliable method of triggering it in the first place, so I can only
*really* be sure if it *isn't* fixed...

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 48304] text in fbterm is garbled

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||NOTOURBUG

--- Comment #8 from Michel Dänzer  2012-04-06 03:58:59 PDT 
---
(In reply to comment #7)
> You're right. It's Infinality's patches for freetype. Uninstalling them makes
> fbterm work.

Thanks for the followup, resolving.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 36769] Sporadic corruption of hardware cursor.

[bugzilla-daemon]

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

--- Comment #8 from Michel Dänzer  2012-04-06 04:06:42 PDT 
---
If your card has more than 128M of VRAM (that's just one reason why Xorg.0.log
and dmesg should be attached to every bug report...), let's mark this as a
duplicate of bug 46796, which has more information about the likely cause and
its fix. If you ever hit it again, we can go from there.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 48305] llpp gets segfault in r600g_dri.so

[bugzilla-daemon]

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

--- Comment #8 from Michel Dänzer  2012-04-06 04:11:52 PDT 
---
Smells more like a compiler bug then. Which version of gcc is this? Does it
also happen with an older one?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 36769] Sporadic corruption of hardware cursor.

[bugzilla-daemon]

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

--- Comment #9 from Chris Rankin  2012-04-06 05:10:05 
PDT ---
(In reply to comment #8)
> If your card has more than 128M of VRAM...

256 MB, to be exact:

radeon :01:00.0: putting AGP V3 device into 8x mode
radeon :01:00.0: GTT: 256M 0xC000 - 0xCFFF
[drm] Generation 2 PCI interface, using max accessible memory
radeon :01:00.0: VRAM: 256M 0xE000 - 0xEFFF (256M
used)
[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] Driver supports precise vblank timestamp query.
[drm] radeon: irq initialized.
[drm] Detected VRAM RAM=256M, BAR=256M
[drm] RAM width 128bits DDR
[TTM] Zone  kernel: Available graphics memory: 444042 kiB.
[TTM] Zone highmem: Available graphics memory: 1037688 kiB.
[TTM] Initializing pool allocator.
[drm] radeon: 256M of VRAM memory ready
[drm] radeon: 256M of GTT memory ready.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 02/11] Documentation: media: description of DMABUF importing in V4L2

[Laurent Pinchart]

Hi Tomasz,

Thanks for the patch.

On Thursday 05 April 2012 15:59:59 Tomasz Stanislawski wrote:
> This patch adds description and usage examples for importing
> DMABUF file descriptor in V4L2.

[snip]

> diff --git a/Documentation/DocBook/media/v4l/io.xml
> b/Documentation/DocBook/media/v4l/io.xml index b815929..2a32363 100644
> --- a/Documentation/DocBook/media/v4l/io.xml
> +++ b/Documentation/DocBook/media/v4l/io.xml
> @@ -472,6 +472,160 @@ rest should be evident.
>
>
> 
> +  
> +Streaming I/O (DMA buffer importing)

This section is very similar to the Streaming I/O (User Pointers) section. Do 
you think we should merge the two ?

> +
> +  Experimental
> +  This is an  experimental 
> +  interface and may change in the future.
> +
> +
> +The DMABUF framework was introduced to provide a generic mean for
> sharing buffers between multiple HW devices. Some device drivers provide
> an API that may be capable to export a DMA buffer as a DMABUF file
> descriptor. The other device drivers may be configured to use such a
> buffer. They implements an API for importing of DMABUF. This section
> describes the support of DMABUF importing in V4L2.

I would rephrase this as follows:

The DMABUF framework provides a generic mean for sharing buffers between
 multiple devices. Device drivers that support DMABUF can export a DMA buffer 
to userspace as a file descriptor (known as the exporter role), import a DMA 
buffer from userspace using a file descriptor previously exported for a 
different or the same device (known as the importer role), or both. This 
section describes the DMABUF importer role API in V4L2.

> +Input and output devices support this I/O method when the
> +V4L2_CAP_STREAMING flag in the
> +capabilities field of &v4l2-capability; returned
> by the &VIDIOC-QUERYCAP; ioctl is set. If the particular importing buffer
> via DMABUF file descriptors method is supported must be determined by
> calling the &VIDIOC-REQBUFS; ioctl.

What about

Input and output devices support the streaming I/O method when the 
V4L2_CAP_STREAMING flag in the 
capabilities field of &v4l2-capability; returned by 
the &VIDIOC-QUERYCAP; ioctl is set. Whether importing DMA buffers through 
DMABUF file descriptors is supported is determined by calling the &VIDIOC-
REQBUFS; ioctl with the memory type set to 
V4L2_MEMORY_DMABUF.

> +This I/O method is dedicated for sharing DMA buffers between V4L
> and other APIs. Buffers (planes) are allocated by the application itself
> using a client API. The buffers must be exported as DMABUF file descriptor.

I would say that "Buffers (planes) are allocated by a driver on behalf of the 
application, and exported to the application as file descriptors using an API 
specific to the allocator driver."

> Only those file descriptor are exchanged, these files and meta-information
> are passed in &v4l2-buffer; (or in &v4l2-plane; in the multi-planar API
> case).  The driver must be switched into DMABUF I/O mode by calling the
> &VIDIOC-REQBUFS; with the desired buffer type. No buffers (planes) are
> allocated beforehand, consequently they are not indexed and cannot be
> queried like mapped buffers with the VIDIOC_QUERYBUF
> ioctl.

[snip]

> +Filled or displayed buffers are dequeued with the
> +&VIDIOC-DQBUF; ioctl. The driver can unpin the buffer at any
> +time between the completion of the DMA and this ioctl. The memory is
> +also unpinned when &VIDIOC-STREAMOFF; is called, &VIDIOC-REQBUFS;, or
> +when the device is closed.
>
> +For capturing applications it is customary to enqueue a
> +number of empty buffers, to start capturing and enter the read loop.
> +Here the application waits until a filled buffer can be dequeued, and
> +re-enqueues the buffer when the data is no longer needed. Output
> +applications fill and enqueue buffers, when enough buffers are stacked
> +up output is started. In the write loop, when the application
> +runs out of free buffers it must wait until an empty buffer can be
> +dequeued and reused. Two methods exist to suspend execution of the
> +application until one or more buffers can be dequeued. By default
> +VIDIOC_DQBUF blocks when no buffer is in the
> +outgoing queue. When the O_NONBLOCK flag was
> +given to the &func-open; function, VIDIOC_DQBUF
> +returns immediately with an &EAGAIN; when no buffer is available. The
> +&func-select; or &func-poll; function are always available.
> +
> +To start and stop capturing or output applications call the
> +&VIDIOC-STREAMON; and &VIDIOC-STREAMOFF; ioctl.

s/ioctl/ioctls.

> + Note VIDIOC_STREAMOFF removes all buffers from both

s/Note/Note that/

> + queues and unlocks/unpins all buffers as a side effect. Since there is no
> + notion of doing anything "now" on a multitasking system, if an application
> + needs to synchronize with another event it should examine the &v4l2-
> + buffer; timestamp of captured buffers, or set
> + the field before enqueuing buffers for output.
> +

[Bug 48382] New: weird rendering distortions on R200M

[bugzilla-daemon]

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

 Bug #: 48382
   Summary: weird rendering distortions on R200M
Classification: Unclassified
   Product: DRI
   Version: unspecified
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: mds...@gmail.com


Created attachment 59582
  --> https://bugs.freedesktop.org/attachment.cgi?id=59582
Xonotic distortion

Here are my specs:

ATI Radeon X200M (RS482)
AMD Turion 64
X.Org X11 7.4-r1 
Xorg Server- 1.11.2-r2
Mesa 7.11.2
Linux Kernel 3.2.12

I get these strange distortions in xonotic(screenie attached). This vertex
distortion also occurs in wings3D and blender.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm/i915: fix integer overflow in i915_gem_execbuffer2()

[Xi Wang]

A large args->buffer_count from userspace may overflow the allocation
size, leading to out-of-bounds access.

Use kmalloc_array() to avoid that.

Signed-off-by: Xi Wang 
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index f51a696..19962bd 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1409,8 +1409,8 @@ i915_gem_execbuffer2(struct drm_device *dev, void *data,
return -EINVAL;
}
 
-   exec2_list = kmalloc(sizeof(*exec2_list)*args->buffer_count,
-GFP_KERNEL | __GFP_NOWARN | __GFP_NORETRY);
+   exec2_list = kmalloc_array(args->buffer_count, sizeof(*exec2_list),
+  GFP_KERNEL | __GFP_NOWARN | __GFP_NORETRY);
if (exec2_list == NULL)
exec2_list = drm_malloc_ab(sizeof(*exec2_list),
   args->buffer_count);
-- 
1.7.5.4

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

[PATCH 2/2] drm/i915: fix integer overflow in i915_gem_do_execbuffer()

[Xi Wang]

A large args->num_cliprects from userspace may overflow the allocation
size, leading to out-of-bounds access.

| i915_gem_do_execbuffer()
| i915_gem_execbuffer()

Use kmalloc_array() to avoid that.

Signed-off-by: Xi Wang 
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 19962bd..607be3d 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1133,8 +1133,8 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
return -EINVAL;
}
 
-   cliprects = kmalloc(args->num_cliprects * sizeof(*cliprects),
-   GFP_KERNEL);
+   cliprects = kmalloc_array(args->num_cliprects, 
sizeof(*cliprects),
+ GFP_KERNEL);
if (cliprects == NULL) {
ret = -ENOMEM;
goto pre_mutex_err;
-- 
1.7.5.4

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

[Bug 36769] Sporadic corruption of hardware cursor.

[bugzilla-daemon]

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

Alex Deucher  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE

--- Comment #10 from Alex Deucher  2012-04-06 06:14:08 PDT ---


*** This bug has been marked as a duplicate of bug 46796 ***

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 46796] [X800SE] Mouse cursor corruption when switching users

[bugzilla-daemon]

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

Alex Deucher  changed:

   What|Removed |Added

 CC||ranki...@googlemail.com

--- Comment #16 from Alex Deucher  2012-04-06 06:14:08 PDT ---
*** Bug 36769 has been marked as a duplicate of this bug. ***

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 48382] weird rendering distortions on R200M

[bugzilla-daemon]

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

Alex Deucher  changed:

   What|Removed |Added

Product|DRI |Mesa
Version|unspecified |7.11
  Component|DRM/Radeon  |Drivers/Gallium/r300

--- Comment #1 from Alex Deucher  2012-04-06 06:16:02 UTC ---
Please attach your xorg log, dmesg output, and glxinfo output.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 03/11] v4l: vb2: add support for shared buffer (dma_buf)

[Laurent Pinchart]

Hi Tomasz,

On Thursday 05 April 2012 16:00:00 Tomasz Stanislawski wrote:
> From: Sumit Semwal 
> 
> This patch adds support for DMABUF memory type in videobuf2. It calls
> relevant APIs of dma_buf for v4l reqbuf / qbuf / dqbuf operations.
> 
> For this version, the support is for videobuf2 as a user of the shared
> buffer; so the allocation of the buffer is done outside of V4L2. [A sample
> allocator of dma-buf shared buffer is given at [1]]
> 
> [1]: Rob Clark's DRM:
>https://github.com/robclark/kernel-omap4/commits/drmplane-dmabuf
> 
> Signed-off-by: Tomasz Stanislawski 
>[original work in the PoC for buffer sharing]
> Signed-off-by: Sumit Semwal 
> Signed-off-by: Sumit Semwal 
> ---
>  drivers/media/video/videobuf2-core.c |  184 ++-
>  include/media/videobuf2-core.h   |   31 ++
>  2 files changed, 214 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/media/video/videobuf2-core.c
> b/drivers/media/video/videobuf2-core.c index 2e8f1df..b37feea 100644
> --- a/drivers/media/video/videobuf2-core.c
> +++ b/drivers/media/video/videobuf2-core.c

[snip]

> @@ -451,6 +482,21 @@ static int __verify_mmap_ops(struct vb2_queue *q)
>  }
> 
>  /**
> + * __verify_dmabuf_ops() - verify that all memory operations required for
> + * DMABUF queue type have been provided
> + */
> +static int __verify_dmabuf_ops(struct vb2_queue *q)
> +{
> + if (!(q->io_modes & VB2_DMABUF) || !q->mem_ops->attach_dmabuf
> + || !q->mem_ops->detach_dmabuf
> + || !q->mem_ops->map_dmabuf
> + || !q->mem_ops->unmap_dmabuf)

That's pretty strange indentation. What about

if (!(q->io_modes & VB2_DMABUF) || !q->mem_ops->attach_dmabuf ||
!q->mem_ops->detach_dmabuf || !q->mem_ops->map_dmabuf ||
!q->mem_ops->unmap_dmabuf)

> + return -EINVAL;
> +
> + return 0;
> +}
> +
> +/**
>   * vb2_reqbufs() - Initiate streaming
>   * @q:   videobuf2 queue
>   * @req: struct passed from userspace to vidioc_reqbufs handler in driver
> @@ -484,6 +530,7 @@ int vb2_reqbufs(struct vb2_queue *q, struct
> v4l2_requestbuffers *req) }
> 
>   if (req->memory != V4L2_MEMORY_MMAP
> + && req->memory != V4L2_MEMORY_DMABUF
>   && req->memory != V4L2_MEMORY_USERPTR) {
>   dprintk(1, "reqbufs: unsupported memory type\n");
>   return -EINVAL;

Ditto.

[snip]

> @@ -620,7 +672,8 @@ int vb2_create_bufs(struct vb2_queue *q, struct
> v4l2_create_buffers *create) }
> 
>   if (create->memory != V4L2_MEMORY_MMAP
> - && create->memory != V4L2_MEMORY_USERPTR) {
> + && create->memory != V4L2_MEMORY_USERPTR
> + && create->memory != V4L2_MEMORY_DMABUF) {
>   dprintk(1, "%s(): unsupported memory type\n", __func__);
>   return -EINVAL;
>   }

And here too.

[snip]

> diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
> index a15d1f1..665e846 100644
> --- a/include/media/videobuf2-core.h
> +++ b/include/media/videobuf2-core.h

[snip]

> @@ -65,6 +82,17 @@ struct vb2_mem_ops {
>   unsigned long size, int write);
>   void(*put_userptr)(void *buf_priv);
> 
> + /*
> +  * Comment from Rob Clark: XXX: I think the attach / detach could be
> +  * handled in the vb2 core, and vb2_mem_ops really just need to get/put
> +  * the sglist (and make sure that the sglist fits it's needs..)
> +  */

I think we should address this now. We've previously discussed the question, 
but haven't reached an agreement.

Quoting my reply to "[RFCv2 PATCH 3/9] v4l: vb2: Add dma-contig allocator as 
dma_buf user" on 28/03/2012:

> > Calling dma_buf_attach could be moved to vb2-core. But it gives little
> > gain. First, the pointer of dma_buf_attachment would have to be added to
> > struct vb2_plane. Second, the allocator would have to keep in the copy of
> > this pointer in its context structure for use of vb2_dc_(un)map_dmabuf
> > functions.
> 
> Right. Would it make sense to pass the vb2_plane pointer, or possibly the 
> dma_buf_attachment pointer, to the mmap_dmabuf and unmap_dmabuf operations ?
> 
> > Third, dma_buf_attach requires a pointer to 'struct device' which is not
> > available in the vb2-core layer.
> 
> OK, that's a problem.
> 
> > Because of the mentioned reasons I decided to keep attach_dmabuf in
> > allocator-specific code.
> 
> Maybe it would make sense to create a vb2_mem_buf structure from which 
> vb2_dc_buf (and other allocator-specific buffer descriptors) would inherit ? 
> That structure would store the dma_buf_attach pointer, and common dma-buf
> code could be put in videobuf2-memops.c and shared between allocators. Just
> an idea.

If we find out that the best course of action is to leave the code as-is, we 
should remove the above comment.

> + void*(*attach_

Re: [PATCH 09/11] v4l: vb2: add prepare/finish callbacks to allocators

[Laurent Pinchart]

Hi Tomasz,

On Thursday 05 April 2012 16:00:06 Tomasz Stanislawski wrote:
> From: Marek Szyprowski 
> 
> This patch adds support for prepare/finish callbacks in VB2 allocators.
> These callback are used for buffer flushing.
> 
> Signed-off-by: Marek Szyprowski 
> ---
>  drivers/media/video/videobuf2-core.c |   11 +++
>  include/media/videobuf2-core.h   |7 +++
>  2 files changed, 18 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/media/video/videobuf2-core.c
> b/drivers/media/video/videobuf2-core.c index b37feea..abb0592 100644
> --- a/drivers/media/video/videobuf2-core.c
> +++ b/drivers/media/video/videobuf2-core.c
> @@ -834,6 +834,7 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum
> vb2_buffer_state state) {
>   struct vb2_queue *q = vb->vb2_queue;
>   unsigned long flags;
> + int plane;

Please make plane an unsigned int, otherwise you will compare a signed and an 
unsigned int below.

> 
>   if (vb->state != VB2_BUF_STATE_ACTIVE)
>   return;
> @@ -844,6 +845,10 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum
> vb2_buffer_state state) dprintk(4, "Done processing on buffer %d, state:
> %d\n",
>   vb->v4l2_buf.index, vb->state);
> 
> + /* sync buffers */
> + for (plane = 0; plane < vb->num_planes; ++plane)
> + call_memop(q, finish, vb->planes[plane].mem_priv);
> +
>   /* Add the buffer to the done buffers list */
>   spin_lock_irqsave(&q->done_lock, flags);
>   vb->state = state;
> @@ -1131,9 +1136,15 @@ err:
>  static void __enqueue_in_driver(struct vb2_buffer *vb)
>  {
>   struct vb2_queue *q = vb->vb2_queue;
> + int plane;

Same here.

>   vb->state = VB2_BUF_STATE_ACTIVE;
>   atomic_inc(&q->queued_count);
> +
> + /* sync buffers */
> + for (plane = 0; plane < vb->num_planes; ++plane)
> + call_memop(q, prepare, vb->planes[plane].mem_priv);
> +
>   q->ops->buf_queue(vb);
>  }

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH 1/2] drm/i915: fix integer overflow in i915_gem_execbuffer2()

[Chris Wilson]

On Fri,  6 Apr 2012 08:58:18 -0400, Xi Wang  wrote:
> A large args->buffer_count from userspace may overflow the allocation
> size, leading to out-of-bounds access.
> 
> Use kmalloc_array() to avoid that.

I can safely say that exec list larger than 4GiB is going to be an
illegal operation and would rather the ioctl failed outright with
EINVAL.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm/i915: fix integer overflow in i915_gem_execbuffer2()

[Xi Wang]

On Apr 6, 2012, at 9:36 AM, Chris Wilson wrote:

> On Fri,  6 Apr 2012 08:58:18 -0400, Xi Wang  wrote:
>> A large args->buffer_count from userspace may overflow the allocation
>> size, leading to out-of-bounds access.
>> 
>> Use kmalloc_array() to avoid that.
> 
> I can safely say that exec list larger than 4GiB is going to be an
> illegal operation and would rather the ioctl failed outright with
> EINVAL.

On 32-bit platform?

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

Re: [PATCH 1/2] drm/i915: fix integer overflow in i915_gem_execbuffer2()

[Chris Wilson]

On Fri, 6 Apr 2012 09:46:46 -0400, Xi Wang  wrote:
> On Apr 6, 2012, at 9:36 AM, Chris Wilson wrote:
> 
> > On Fri,  6 Apr 2012 08:58:18 -0400, Xi Wang  wrote:
> >> A large args->buffer_count from userspace may overflow the allocation
> >> size, leading to out-of-bounds access.
> >> 
> >> Use kmalloc_array() to avoid that.
> > 
> > I can safely say that exec list larger than 4GiB is going to be an
> > illegal operation and would rather the ioctl failed outright with
> > EINVAL.
> 
> On 32-bit platform?

On any platform. The largest it can legally be is a few tens of megabytes.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm/i915: fix integer overflow in i915_gem_execbuffer2()

[Xi Wang]

On Apr 6, 2012, at 9:54 AM, Chris Wilson wrote:

> On Fri, 6 Apr 2012 09:46:46 -0400, Xi Wang  wrote:
>> On Apr 6, 2012, at 9:36 AM, Chris Wilson wrote:
>> 
>>> On Fri,  6 Apr 2012 08:58:18 -0400, Xi Wang  wrote:
 A large args->buffer_count from userspace may overflow the allocation
 size, leading to out-of-bounds access.
 
 Use kmalloc_array() to avoid that.
>>> 
>>> I can safely say that exec list larger than 4GiB is going to be an
>>> illegal operation and would rather the ioctl failed outright with
>>> EINVAL.
>> 
>> On 32-bit platform?
> 
> On any platform. The largest it can legally be is a few tens of megabytes.

IDGI.  First we come to i915_gem_execbuffer2() from ioctl:

  exec2_list = kmalloc(sizeof(*exec2_list)*args->buffer_count, ...);

args->buffer_count is passed from userspace so it can be any value.
Let it overflow the 32-bit multiplication and turn the call to:

  exec2_list = kmalloc(0, ...);

Then the subsequent call to i915_gem_do_execbuffer(..., exec2_list)
may read exec2_list, which is out of bounds.

- xi

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

[Bug 48382] weird rendering distortions on R200M

[bugzilla-daemon]

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

--- Comment #2 from Ned Anderson  2012-04-06 07:38:02 PDT ---
Created attachment 59587
  --> https://bugs.freedesktop.org/attachment.cgi?id=59587
xorg log

Xorg Log

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 48382] weird rendering distortions on R200M

[bugzilla-daemon]

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

--- Comment #3 from Ned Anderson  2012-04-06 07:38:37 PDT ---
Created attachment 59588
  --> https://bugs.freedesktop.org/attachment.cgi?id=59588
Dmesg

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 48382] weird rendering distortions on R200M

[bugzilla-daemon]

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

--- Comment #4 from Ned Anderson  2012-04-06 07:39:16 PDT ---
Created attachment 59589
  --> https://bugs.freedesktop.org/attachment.cgi?id=59589
glxinfo output

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm/i915: fix integer overflow in i915_gem_execbuffer2()

[Chris Wilson]

On Fri, 6 Apr 2012 10:01:36 -0400, Xi Wang  wrote:
> On Apr 6, 2012, at 9:54 AM, Chris Wilson wrote:
> 
> > On Fri, 6 Apr 2012 09:46:46 -0400, Xi Wang  wrote:
> >> On Apr 6, 2012, at 9:36 AM, Chris Wilson wrote:
> >> 
> >>> On Fri,  6 Apr 2012 08:58:18 -0400, Xi Wang  wrote:
>  A large args->buffer_count from userspace may overflow the allocation
>  size, leading to out-of-bounds access.
>  
>  Use kmalloc_array() to avoid that.
> >>> 
> >>> I can safely say that exec list larger than 4GiB is going to be an
> >>> illegal operation and would rather the ioctl failed outright with
> >>> EINVAL.
> >> 
> >> On 32-bit platform?
> > 
> > On any platform. The largest it can legally be is a few tens of megabytes.
> 
> IDGI.  First we come to i915_gem_execbuffer2() from ioctl:
> 
>   exec2_list = kmalloc(sizeof(*exec2_list)*args->buffer_count, ...);
> 
> args->buffer_count is passed from userspace so it can be any value.

That I agreed with, I just disagree with how you chose to handle it.
Rather than continue on and attempt to vmalloc a large array we should
just fail the ioctl with EINVAL.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 08/11] v4l: vb2-dma-contig: add support for scatterlist in userptr mode

[Laurent Pinchart]

Hi Tomasz,

On Thursday 05 April 2012 16:00:05 Tomasz Stanislawski wrote:
> From: Andrzej Pietrasiewicz 
> 
> This patch introduces usage of dma_map_sg to map memory behind
> a userspace pointer to a device as dma-contiguous mapping.
> 
> Signed-off-by: Andrzej Pietrasiewicz 
> Signed-off-by: Marek Szyprowski 
>   [bugfixing]
> Signed-off-by: Kamil Debski 
>   [bugfixing]
> Signed-off-by: Tomasz Stanislawski 
>   [add sglist subroutines/code refactoring]
> Signed-off-by: Kyungmin Park 
> ---
>  drivers/media/video/videobuf2-dma-contig.c |  282 +++--
>  1 files changed, 265 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/media/video/videobuf2-dma-contig.c
> b/drivers/media/video/videobuf2-dma-contig.c index 476e536..6ab3165 100644
> --- a/drivers/media/video/videobuf2-dma-contig.c
> +++ b/drivers/media/video/videobuf2-dma-contig.c

[snip]

> @@ -32,6 +36,98 @@ struct vb2_dc_buf {
>  };
> 
>  /*/
> +/*scatterlist table functions*/
> +/*/
> +
> +static struct sg_table *vb2_dc_pages_to_sgt(struct page **pages,
> + unsigned long n_pages, size_t offset, size_t offset2)

"offset2" isn't very descriptive. I would replace it with the total size of 
the buffer instead (or, alternatively, rename offset to offset_start and 
offset2 to offset_end, but I like the first option better).

> +{
> + struct sg_table *sgt;
> + int i, j; /* loop counters */

I don't think the comment is needed.

> + int cur_page, chunks;

i, j, cur_page and chunks can't be negative. Could you please make them 
unsigned int (and I would order them) ?

Also, Documentation/CodingStyle favors one variable declaration per line, 
without commas for multiple declarations.

> + int ret;
> + struct scatterlist *s;
> +
> + sgt = kzalloc(sizeof *sgt, GFP_KERNEL);
> + if (!sgt)
> + return ERR_PTR(-ENOMEM);
> +
> + /* compute number of chunks */
> + chunks = 1;
> + for (i = 1; i < n_pages; ++i)
> + if (pages[i] != pages[i - 1] + 1)
> + ++chunks;
> +
> + ret = sg_alloc_table(sgt, chunks, GFP_KERNEL);
> + if (ret) {
> + kfree(sgt);
> + return ERR_PTR(-ENOMEM);
> + }
> +
> + /* merging chunks and putting them into the scatterlist */
> + cur_page = 0;
> + for_each_sg(sgt->sgl, s, sgt->orig_nents, i) {
> + size_t size = PAGE_SIZE;
> +
> + for (j = cur_page + 1; j < n_pages; ++j) {
> + if (pages[j] != pages[j - 1] + 1)
> + break;
> + size += PAGE_SIZE;
> + }
> +
> + /* cut offset if chunk starts at the first page */
> + if (cur_page == 0)
> + size -= offset;
> + /* cut offset2 if chunk ends at the last page */
> + if (j == n_pages)
> + size -= offset2;
> +
> + sg_set_page(s, pages[cur_page], size, offset);
> + offset = 0;
> + cur_page = j;
> + }
> +
> + return sgt;
> +}
> +
> +static void vb2_dc_release_sgtable(struct sg_table *sgt)
> +{
> + sg_free_table(sgt);
> + kfree(sgt);
> +}
> +
> +static void vb2_dc_sgt_foreach_page(struct sg_table *sgt,
> + void (*cb)(struct page *pg))
> +{
> + struct scatterlist *s;
> + int i, j;
> +
> + for_each_sg(sgt->sgl, s, sgt->nents, i) {
> + struct page *page = sg_page(s);
> + int n_pages = PAGE_ALIGN(s->offset + s->length) >> PAGE_SHIFT;
> +
> + for (j = 0; j < n_pages; ++j, ++page)
> + cb(page);

Same for i, j and n_pages here.

> + }
> +}
> +
> +static unsigned long vb2_dc_get_contiguous_size(struct sg_table *sgt)
> +{
> + struct scatterlist *s;
> + dma_addr_t expected = sg_dma_address(sgt->sgl);
> + int i;

Same for i here.

> + unsigned long size = 0;
> +
> + for_each_sg(sgt->sgl, s, sgt->nents, i) {
> + if (sg_dma_address(s) != expected)
> + break;
> + expected = sg_dma_address(s) + sg_dma_len(s);
> + size += sg_dma_len(s);
> + }
> + return size;
> +}
> +
> +/*/
>  /* callbacks for all buffers */
>  /*/
> 
> @@ -116,42 +212,194 @@ static int vb2_dc_mmap(void *buf_priv, struct
> vm_area_struct *vma) /*   callbacks for USERPTR buffers   */
>  /*/
> 
> +static inline int vma_is_io(struct vm_area_struct *vma)
> +{
> + return !!(vma->vm_flags & (VM_IO | VM_PFNMAP));
> +}
> +
> +static struct vm_area_struct *vb2_dc_get_user_vma(
> + unsigned long start, unsigned long size)
> +{
> + struct vm_area_struct *vma;
> +
> + /* current->mm->mmap_sem is taken by videobuf2 core */
> + vma = fin

Re: [PATCH 11/11] v4l: vb2: Add dma-contig allocator as dma_buf user

[Laurent Pinchart]

Hi Tomasz,

On Thursday 05 April 2012 16:00:08 Tomasz Stanislawski wrote:
> From: Sumit Semwal 
> 
> This patch makes changes for adding dma-contig as a dma_buf user. It
> provides function implementations for the {attach, detach, map,
> unmap}_dmabuf() mem_ops of DMABUF memory type.
> 
> Signed-off-by: Sumit Semwal 
> Signed-off-by: Sumit Semwal 
>   [author of the original patch]
> Signed-off-by: Tomasz Stanislawski 
>   [integration with refactored dma-contig allocator]
> ---
>  drivers/media/video/videobuf2-dma-contig.c |  117 +
>  1 files changed, 117 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/media/video/videobuf2-dma-contig.c
> b/drivers/media/video/videobuf2-dma-contig.c index 30f316588..6329483
> 100644
> --- a/drivers/media/video/videobuf2-dma-contig.c
> +++ b/drivers/media/video/videobuf2-dma-contig.c
> @@ -10,6 +10,7 @@
>   * the Free Software Foundation.
>   */
> 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -33,6 +34,9 @@ struct vb2_dc_buf {
> 
>   /* USERPTR related */
>   struct vm_area_struct   *vma;
> +
> + /* DMABUF related */
> + struct dma_buf_attachment   *db_attach;
>  };
> 
>  /*/
> @@ -425,6 +429,115 @@ fail_buf:
>  }
> 
>  /*/
> +/*   callbacks for DMABUF buffers*/
> +/*/
> +
> +static int vb2_dc_map_dmabuf(void *mem_priv)
> +{
> + struct vb2_dc_buf *buf = mem_priv;
> + struct sg_table *sgt;
> + unsigned long contig_size;
> + int ret = 0;
> +
> + if (WARN_ON(!buf->db_attach)) {
> + printk(KERN_ERR "trying to pin a non attached buffer\n");
> + return -EINVAL;
> + }
> +
> + if (WARN_ON(buf->dma_sgt)) {
> + printk(KERN_ERR "dmabuf buffer is already pinned\n");
> + return 0;
> + }
> +
> + /* get the associated scatterlist for this buffer */
> + sgt = dma_buf_map_attachment(buf->db_attach, buf->dma_dir);
> + if (IS_ERR_OR_NULL(sgt)) {
> + printk(KERN_ERR "Error getting dmabuf scatterlist\n");
> + return -EINVAL;
> + }
> +
> + /* checking if dmabuf is big enough to store contiguous chunk */
> + contig_size = vb2_dc_get_contiguous_size(sgt);
> + if (contig_size < buf->size) {
> + printk(KERN_ERR "contiguous chunk of dmabuf is too small\n");
> + ret = -EFAULT;
> + goto fail_map;

The fail_map label is only used here, you can move the 
dma_buf_unmap_attachment() call here and return -EFAULT directly.

> + }
> +
> + buf->dma_addr = sg_dma_address(sgt->sgl);
> + buf->dma_sgt = sgt;
> +
> + return 0;
> +
> +fail_map:
> + dma_buf_unmap_attachment(buf->db_attach, sgt, buf->dma_dir);
> +
> + return ret;
> +}
> +
> +static void vb2_dc_unmap_dmabuf(void *mem_priv)
> +{
> + struct vb2_dc_buf *buf = mem_priv;
> + struct sg_table *sgt = buf->dma_sgt;
> +
> + if (WARN_ON(!buf->db_attach)) {
> + printk(KERN_ERR "trying to unpin a not attached buffer\n");
> + return;
> + }
> +
> + if (WARN_ON(!sgt)) {
> + printk(KERN_ERR "dmabuf buffer is already unpinned\n");
> + return;
> + }
> +
> + dma_buf_unmap_attachment(buf->db_attach, sgt, buf->dma_dir);
> +
> + buf->dma_addr = 0;
> + buf->dma_sgt = NULL;
> +}
> +
> +static void vb2_dc_detach_dmabuf(void *mem_priv)
> +{
> + struct vb2_dc_buf *buf = mem_priv;
> +
> + if (buf->dma_addr)
> + vb2_dc_unmap_dmabuf(buf);

What would you think about calling vb2_dc_unmap_dmabuf() from vb2 core 
instead, to keep the map/unmap calls symmetrical (the second WARN_ON and the 
related printk in vb2_dc_unmap_dmabuf() might need to go then) ?

> + /* detach this attachment */
> + dma_buf_detach(buf->db_attach->dmabuf, buf->db_attach);
> + kfree(buf);
> +}
> +
> +static void *vb2_dc_attach_dmabuf(void *alloc_ctx, struct dma_buf *dbuf,
> + unsigned long size, int write)
> +{
> + struct vb2_dc_buf *buf;
> + struct dma_buf_attachment *dba;
> +
> + if (dbuf->size < size)
> + return ERR_PTR(-EFAULT);
> +
> + buf = kzalloc(sizeof *buf, GFP_KERNEL);
> + if (!buf)
> + return ERR_PTR(-ENOMEM);
> +
> + buf->dev = alloc_ctx;
> + /* create attachment for the dmabuf with the user device */
> + dba = dma_buf_attach(dbuf, buf->dev);
> + if (IS_ERR(dba)) {
> + printk(KERN_ERR "failed to attach dmabuf\n");
> + kfree(buf);
> + return dba;
> + }
> +
> + buf->dma_dir = write ? DMA_FROM_DEVICE : DMA_TO_DEVICE;
> + buf->size = size;
> + buf->db_attach = dba;
> +
> + return buf;
> +}
> +
> +/*/
>  /*   DMA CONTIG exported functions   */
>  /*/
> 
> @@ -438,6 +551,

Re: [PATCH libdrm] libdrm: update drm/drm_fourcc.h from kernel to add multi plane formats

[Sylwester Nawrocki]

Hello,

On 04/06/2012 11:22 AM, Kyungmin Park wrote:
> + V4L2 develper
> Sylwester, please give your opinions? How to handle it at v4l2 side.
> 
> Thank you,
> Kyungmin Park
> 
> On Apr 6, 2012 12:44 AM, "Ville Syrjälä"  > wrote:
> 
> On Fri, Apr 06, 2012 at 03:05:36PM +0900, Inki Dae wrote:
> > Hi Ville,
> >
> > > -Original Message-
> > > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com
> ]
> > > Sent: Friday, April 06, 2012 3:14 AM
> > > To: airl...@redhat.com 
> > > Cc: inki@samsung.com ;
> kyungmin.p...@samsung.com ; dri-
> > > de...@lists.freedesktop.org ;
> Seung-Woo Kim
> > > Subject: Re: [PATCH libdrm] libdrm: update drm/drm_fourcc.h from 
> kernel to
> > > add multi plane formats
> > >
> > > On Fri, Mar 30, 2012 at 01:12:58PM +0300, Ville Syrjälä wrote:
> > > > On Fri, Mar 30, 2012 at 11:54:50AM +0900, Seung-Woo Kim wrote:
> > > > > Multi buffer plane pixel formats are added as like kernel header.
> > > > >
> > > > > Signed-off-by: Seung-Woo Kim  >
> > > > > ---
> > > > >  include/drm/drm_fourcc.h |7 +++
> > > > >  1 files changed, 7 insertions(+), 0 deletions(-)
> > > > >
> > > > > diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
> > > > > index 85facb0..7cfd95a 100644
> > > > > --- a/include/drm/drm_fourcc.h
> > > > > +++ b/include/drm/drm_fourcc.h
> > > > > @@ -107,6 +107,10 @@
> > > > >  #define DRM_FORMAT_NV16fourcc_code('N', 'V', '1',
> '6') /*
> > > 2x1 subsampled Cr:Cb plane */
> > > > >  #define DRM_FORMAT_NV61fourcc_code('N', 'V', '6',
> '1') /*
> > > 2x1 subsampled Cb:Cr plane */
> > > > >
> > > > > +/* 2 non contiguous plane YCbCr */
> > > > > +#define DRM_FORMAT_NV12M   fourcc_code('N', 'M', '1', '2') 
> /* 2x2
> > > subsampled Cr:Cb plane */
> > > >
> > > > NAK. DRM_FORMAT_NV12 handles this just fine.
> > >
> > > And I just realized that I was already too late with my NAK since 
> this a
> > > libdrm patch. Apparently the kernel drm_fourcc.h changes were snuck in
> > > via some backdoor without review. Sigh.
> > >
> >
> > We had already requested review for it. for this you can refer to link
> > below:
> >
> > 
> http://lists.freedesktop.org/archives/dri-devel/2011-December/017654.html
> 
> I see. I couldn't find it in my work mailbox for some reason, and I
> don't remember having seen the patch before. I suppose I just missed it
> due to Christmas vacations, and was too blind to see it in my mailbox.
> Also google decicded to filter my search results too much, so I didn't
> spot it via the web archives either. I'm sorry for the false accusation.
> 
> > > So they're now in Linus's tree. But looks like format_check() was 
> never
> > > updated to accept them, so there's no way anyone could actually be 
> using
> > > them. So Dave, can we still remove them from the kernel header?
> > >
> >
> > Yes, right. these formats aren't used for any SoCs except Exynos series 
> yet
> > but just we are first. I think they should be added because anyone may 
> use
> > them someday at least possible.
> 
> Since DRM_FORMAT_NV12M is _identical_ to DRM_FORMAT_NV12, I see no point
> in adding it (similarly for YUV420M vs. YUV420).

In V4L2 the fourcc also determines the number of memory planes in the frame
buffer. The multi-planar API has been added to support devices with odd
alignment requirements (image components, like Y/CbCr in separate physical
memory buffers) for which it was difficult to map whole frame into contiguous
user memory region.

Here is some excample:
http://linuxtv.org/downloads/v4l-dvb-apis/V4L2-PIX-FMT-NV12M.html

I'm not terribly familiar with the buffer structure in DRM, maybe there are
better ways to handle something like this in DRI.

> --
> Ville Syrjälä
> syrj...@sci.fi 
> http://www.sci.fi/~syrjala/

Regards,
-- 
Sylwester Nawrocki
Samsung Poland R&D Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 48382] weird rendering distortions on R200M

[bugzilla-daemon]

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

--- Comment #5 from Ned Anderson  2012-04-06 09:09:54 PDT ---
Also fyi, i noticed that the same thing occurs in a different game(BZFlag) when
i turn on shadows...

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm/i915: fix integer overflow in i915_gem_execbuffer2()

[Xi Wang]

On Apr 6, 2012, at 10:44 AM, Chris Wilson wrote:

> That I agreed with, I just disagree with how you chose to handle it.
> Rather than continue on and attempt to vmalloc a large array we should
> just fail the ioctl with EINVAL.

Why an attempt to vmalloc?  The overflow check in drm_malloc_ab()
will simply return NULL and fail the ioctl with -ENOMEM.

- xi

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

Re: [PATCH 1/2] drm/i915: fix integer overflow in i915_gem_execbuffer2()

[Chris Wilson]

On Fri, 6 Apr 2012 14:17:41 -0400, Xi Wang  wrote:
> On Apr 6, 2012, at 10:44 AM, Chris Wilson wrote:
> 
> > That I agreed with, I just disagree with how you chose to handle it.
> > Rather than continue on and attempt to vmalloc a large array we should
> > just fail the ioctl with EINVAL.
> 
> Why an attempt to vmalloc?  The overflow check in drm_malloc_ab()
> will simply return NULL and fail the ioctl with -ENOMEM.

It's an invalid value for the ioctl and should be treated as such, not
making ENOMEM more ambiguous.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm/i915: fix integer overflow in i915_gem_execbuffer2()

[Xi Wang]

On Apr 6, 2012, at 3:40 PM, Chris Wilson wrote:
> On Fri, 6 Apr 2012 14:17:41 -0400, Xi Wang  wrote:
>> 
>> Why an attempt to vmalloc?  The overflow check in drm_malloc_ab()
>> will simply return NULL and fail the ioctl with -ENOMEM.
> 
> It's an invalid value for the ioctl and should be treated as such, not
> making ENOMEM more ambiguous.

We could copy and paste the overflow check so as to return -EINVAL.
I just doubt how much that would help --- you can find existing usages
in other functions, for example, in i915_gem_execbuffer():

  /* Copy in the exec list from userland */
  exec_list = drm_malloc_ab(sizeof(*exec_list), args->buffer_count);
  exec2_list = drm_malloc_ab(sizeof(*exec2_list), args->buffer_count);
  if (exec_list == NULL || exec2_list == NULL) {
  DRM_DEBUG("Failed to allocate exec list for %d buffers\n",
args->buffer_count);
  drm_free_large(exec_list);
  drm_free_large(exec2_list);
  return -ENOMEM;
  }

Should we fix all these as well by repeating the checks and returning
-EINVAL?  I am worried about the code bloat / readability price you
would pay for getting a different error code.

BTW, I've also seen code using E2BIG.  Any documented guideline?

- xi

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

Re: i915_driver_irq_handler: irq 42: nobody cared [generic IRQ handling broken?]

[Jiri Slaby]

On 03/30/2012 02:24 PM, Chris Wilson wrote:
> On Fri, 30 Mar 2012 14:11:47 +0200, Jiri Slaby  wrote:
>> On 03/30/2012 12:45 PM, Chris Wilson wrote:
>>> On Fri, 30 Mar 2012 11:59:28 +0200, Jiri Slaby  wrote:
 I don't know what to dump more, because iir is obviously zero too. What
 other sources of interrupts are on the (G33) chip?
>>>
>>> IIR is the master interrupt, with chained secondary interrupt statuses.
>>> If IIR is 0, the interrupt wasn't raised by the GPU.
>>
>> This does not make sense, the handler does something different. Even if
>> IIR is 0, it still takes a look at pipe stats.
> 
> That was introduced in 05eff845a28499762075d3a72e238a31f4d2407c to close
> a race where the pipestat triggered an interrupt after we processed the
> secondary registers and before reseting the primary.
> 
> But the basic premise that we should only enter the interrupt handler
> with IIR!=0 holds (presuming non-shared interrupt lines such as MSI).

Ok, this behavior is definitely new. I get several "nobody cared" about
this interrupt a week. This never used to happen. And something weird
emerges in /proc/interrupts when this happens:
 42:10032921212890   PCI-MSI-edge  �s::00:02.0
instead of
 42:10067151218472   PCI-MSI-edge  i915@pci::00:02.0

It very looks like the generic IRQ handling code is broken. Like it
frees/corrupts irq_desc and then as well calls random handlers.

Suspend/resume cycle helps in this case and "i915@pci::00:02.0" is
back in /proc/interrupts as can be seen above.

Running 3.3.0-next-20120326_64+ now.

thanks,
-- 
js
suse labs

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

[PATCH] drm/savage: fix integer overflows in savage_bci_cmdbuf()

[Xi Wang]

Since cmdbuf->size and cmdbuf->nbox are from userspace, a large value
would overflow the allocation size, leading to out-of-bounds access.

Signed-off-by: Xi Wang 
---
 drivers/gpu/drm/savage/savage_state.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/savage/savage_state.c 
b/drivers/gpu/drm/savage/savage_state.c
index 031aaaf..b6d8608 100644
--- a/drivers/gpu/drm/savage/savage_state.c
+++ b/drivers/gpu/drm/savage/savage_state.c
@@ -988,7 +988,7 @@ int savage_bci_cmdbuf(struct drm_device *dev, void *data, 
struct drm_file *file_
 * for locking on FreeBSD.
 */
if (cmdbuf->size) {
-   kcmd_addr = kmalloc(cmdbuf->size * 8, GFP_KERNEL);
+   kcmd_addr = kmalloc_array(cmdbuf->size, 8, GFP_KERNEL);
if (kcmd_addr == NULL)
return -ENOMEM;
 
@@ -1015,8 +1015,8 @@ int savage_bci_cmdbuf(struct drm_device *dev, void *data, 
struct drm_file *file_
cmdbuf->vb_addr = kvb_addr;
}
if (cmdbuf->nbox) {
-   kbox_addr = kmalloc(cmdbuf->nbox * sizeof(struct drm_clip_rect),
-   GFP_KERNEL);
+   kbox_addr = kmalloc_array(cmdbuf->nbox, sizeof(struct 
drm_clip_rect),
+ GFP_KERNEL);
if (kbox_addr == NULL) {
ret = -ENOMEM;
goto done;
-- 
1.7.5.4

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

[Bug 27314] displayport link training fails on certain panels (channel equalization fails)

[bugzilla-daemon]

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

--- Comment #67 from Rafael Ávila de Espíndola  
2012-04-06 17:22:46 PDT ---
Created attachment 59612
  --> https://bugs.freedesktop.org/attachment.cgi?id=59612
dmesg with bios booting and kernel 3.3.0

Results are similar to 3.2 :-(
This is an imac 11,1. Let me know if there any additional debugging I could do.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm] libdrm: update drm/drm_fourcc.h from kernel to add multi plane formats

[daeinki]

나의 iPad에서 보냄

2012. 4. 6. 오후 4:43 Ville Syrjälä  작성:

> On Fri, Apr 06, 2012 at 03:05:36PM +0900, Inki Dae wrote:
>> Hi Ville,
>> 
>>> -Original Message-
>>> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>>> Sent: Friday, April 06, 2012 3:14 AM
>>> To: airl...@redhat.com
>>> Cc: inki@samsung.com; kyungmin.p...@samsung.com; dri-
>>> de...@lists.freedesktop.org; Seung-Woo Kim
>>> Subject: Re: [PATCH libdrm] libdrm: update drm/drm_fourcc.h from kernel to
>>> add multi plane formats
>>> 
>>> On Fri, Mar 30, 2012 at 01:12:58PM +0300, Ville Syrjälä wrote:
 On Fri, Mar 30, 2012 at 11:54:50AM +0900, Seung-Woo Kim wrote:
> Multi buffer plane pixel formats are added as like kernel header.
> 
> Signed-off-by: Seung-Woo Kim 
> ---
> include/drm/drm_fourcc.h |7 +++
> 1 files changed, 7 insertions(+), 0 deletions(-)
> 
> diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
> index 85facb0..7cfd95a 100644
> --- a/include/drm/drm_fourcc.h
> +++ b/include/drm/drm_fourcc.h
> @@ -107,6 +107,10 @@
> #define DRM_FORMAT_NV16fourcc_code('N', 'V', '1', '6') /*
>>> 2x1 subsampled Cr:Cb plane */
> #define DRM_FORMAT_NV61fourcc_code('N', 'V', '6', '1') /*
>>> 2x1 subsampled Cb:Cr plane */
> 
> +/* 2 non contiguous plane YCbCr */
> +#define DRM_FORMAT_NV12Mfourcc_code('N', 'M', '1', '2') /* 2x2
>>> subsampled Cr:Cb plane */
 
 NAK. DRM_FORMAT_NV12 handles this just fine.
>>> 
>>> And I just realized that I was already too late with my NAK since this a
>>> libdrm patch. Apparently the kernel drm_fourcc.h changes were snuck in
>>> via some backdoor without review. Sigh.
>>> 
>> 
>> We had already requested review for it. for this you can refer to link
>> below:
>>
>> http://lists.freedesktop.org/archives/dri-devel/2011-December/017654.html
> 
> I see. I couldn't find it in my work mailbox for some reason, and I
> don't remember having seen the patch before. I suppose I just missed it
> due to Christmas vacations, and was too blind to see it in my mailbox.
> Also google decicded to filter my search results too much, so I didn't
> spot it via the web archives either. I'm sorry for the false accusation.
> 
>>> So they're now in Linus's tree. But looks like format_check() was never
>>> updated to accept them, so there's no way anyone could actually be using
>>> them. So Dave, can we still remove them from the kernel header?
>>> 
>> 
>> Yes, right. these formats aren't used for any SoCs except Exynos series yet
>> but just we are first. I think they should be added because anyone may use
>> them someday at least possible.
> 
> Since DRM_FORMAT_NV12M is _identical_ to DRM_FORMAT_NV12, I see no point
> in adding it (similarly for YUV420M vs. YUV420).
> 

but with this way,  user and device driver should understand NV12M format and 
how gem handles should send to driver and also how the driver should decide 
whether these handles mean NV12M or NV12. I think these things are unnecessary 
codes. with such theory, maybe current some fourcc formats couldn't be removed 
because we can identify desired format if we add some codes for it. as you 
mentioned, it's important to avoid such duplicated formats but also to consider 
user and device driver. so I think it's not good for user and driver should 
understand and decide them. Please give me your opinion.

thanks,
Inki Dae

> -- 
> Ville Syrjälä
> syrj...@sci.fi
> http://www.sci.fi/~syrjala/
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

drm: Branch 'master' - 5 commits

[Ville Syrjälä]

On Tue, Apr 03, 2012 at 02:50:01PM -0700, Rob Clark wrote:
> + /* just testing a limited # of formats to test single
> +  * and multi-planar path.. would be nice to add more..
> +  */
> + if (!strcmp(p->format_str, "YUYV")) {
> + pitches[0] = p->w * 2;
> + offsets[0] = 0;
> + kms_bo_get_prop(plane_bo, KMS_HANDLE, &handles[0]);
> +
> + fill422(virtual, 0, p->w, p->h, pitches[0]);
> +
> + format = DRM_FORMAT_YUYV;
> + } else if (!strcmp(p->format_str, "NV12")) {
> + pitches[0] = p->w;
> + offsets[0] = 0;
> + kms_bo_get_prop(plane_bo, KMS_HANDLE, &handles[0]);
> + pitches[1] = p->w;
> + offsets[1] = p->w * p->h;
> + kms_bo_get_prop(plane_bo, KMS_HANDLE, &handles[1]);
> +
> + fill420(virtual, virtual+offsets[1], 
> virtual+offsets[1]+1,
> + 2, 0, p->w, p->h, pitches[0]);
> +
> + format = DRM_FORMAT_NV12;
> + } else if (!strcmp(p->format_str, "YV12")) {
> + pitches[0] = p->w;
> + offsets[0] = 0;
> + kms_bo_get_prop(plane_bo, KMS_HANDLE, &handles[0]);
> + pitches[1] = p->w / 2;
> + offsets[1] = p->w * p->h;
> + kms_bo_get_prop(plane_bo, KMS_HANDLE, &handles[1]);
> + pitches[2] = p->w / 2;
> + offsets[2] = offsets[1] + (p->w * p->h) / 4;
> + kms_bo_get_prop(plane_bo, KMS_HANDLE, &handles[1]);
   ^
Should be '2'. The kernel patch I just posted might have caught this.
OTOH it might not have in case handles[2] contains uninitialized data.

We should add a test that would make sure that passing an invalid bo
handle for any plane would return with an error. The problem is knowing
what exactly is an invalid handle since it's all driver specific.
Perhaps 0x would be a reasonably safe choice. Hmm, now I wonder
if 0 might actually be a valid handle for some of the current drivers...

There should obviously also be a test that does use separate bos
for reach plane. That should either succeed and produce the correct
result, or the driver should respond with an error at least to the
setplane ioctl. Whether it would allow addfb2 to succeed is a slightly
more complicated matter. I suppose it could be possible that on some
odd hardware some planes would support multiple bos and some would
not. In which case the driver would need to allow the addfb2.

-- 
Ville Syrj?l?
syrjala at sci.fi
http://www.sci.fi/~syrjala/

--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
--
___
Dri-devel mailing list
Dri-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Bug 48305] llpp gets segfault in r600g_dri.so

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

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

--- Comment #7 from myxol  2012-04-05 17:49:05 PDT ---
> Maybe you can try isolating which specific option implied by -O3 but not by 
> -O2 makes the difference.
I tried. It is -ftree-vectorize

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

[PATCH libdrm] libdrm: update drm/drm_fourcc.h from kernel to add multi plane formats

[Inki Dae]

Hi Ville,

> -Original Message-
> From: Ville Syrj?l? [mailto:ville.syrjala at linux.intel.com]
> Sent: Friday, April 06, 2012 3:14 AM
> To: airlied at redhat.com
> Cc: inki.dae at samsung.com; kyungmin.park at samsung.com; dri-
> devel at lists.freedesktop.org; Seung-Woo Kim
> Subject: Re: [PATCH libdrm] libdrm: update drm/drm_fourcc.h from kernel to
> add multi plane formats
> 
> On Fri, Mar 30, 2012 at 01:12:58PM +0300, Ville Syrj?l? wrote:
> > On Fri, Mar 30, 2012 at 11:54:50AM +0900, Seung-Woo Kim wrote:
> > > Multi buffer plane pixel formats are added as like kernel header.
> > >
> > > Signed-off-by: Seung-Woo Kim 
> > > ---
> > >  include/drm/drm_fourcc.h |7 +++
> > >  1 files changed, 7 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
> > > index 85facb0..7cfd95a 100644
> > > --- a/include/drm/drm_fourcc.h
> > > +++ b/include/drm/drm_fourcc.h
> > > @@ -107,6 +107,10 @@
> > >  #define DRM_FORMAT_NV16  fourcc_code('N', 'V', '1', '6') /*
> 2x1 subsampled Cr:Cb plane */
> > >  #define DRM_FORMAT_NV61  fourcc_code('N', 'V', '6', '1') /*
> 2x1 subsampled Cb:Cr plane */
> > >
> > > +/* 2 non contiguous plane YCbCr */
> > > +#define DRM_FORMAT_NV12M fourcc_code('N', 'M', '1', '2') /* 2x2
> subsampled Cr:Cb plane */
> >
> > NAK. DRM_FORMAT_NV12 handles this just fine.
> 
> And I just realized that I was already too late with my NAK since this a
> libdrm patch. Apparently the kernel drm_fourcc.h changes were snuck in
> via some backdoor without review. Sigh.
> 

We had already requested review for it. for this you can refer to link
below:

http://lists.freedesktop.org/archives/dri-devel/2011-December/017654.html

> So they're now in Linus's tree. But looks like format_check() was never
> updated to accept them, so there's no way anyone could actually be using
> them. So Dave, can we still remove them from the kernel header?
> 

Yes, right. these formats aren't used for any SoCs except Exynos series yet
but just we are first. I think they should be added because anyone may use
them someday at least possible. but they couldn?t be standard format so we
can send the patch that these formats are removed from drm_fourcc.h anytime
if you are still opposite to my opinion. but please know that at least in
case of v4l2, they have already been used as standard format. For this you
can refer to include/linux/videodev2.h file in mainline and Dave, please
give me your opinion.


Thanks,
Inki Dae

>
> Just to clarify once mode. The original planar formats I defined in
> drm_fourcc.h handle non-contiguous planes. The drivers are supposed to
> use handles[],offsets[],pitches[] to handle this. The 'index' comments
> in the drm_fourcc.h tells you which index of those arrays matches which
> plane. This means that DRM_FORMAT_NV12M is functionally _identical_ to
> DRM_FORMAT_NV12, and the same holds for the three plane format that got
> submarined in.
> 
> The driver is not even supposed to accept DRM_FORMAT_NV12 unless both
> index 0 and 1 are filled in properly by userspace. If the planes are
> contiguous then userspace _must_ pass the same handle for index 0 and
> 1, and use offsets[] to tell the driver where each plane is. If the
> hardware can't handle non-contiguous planes (never seen such hardware
> myself) then the driver must refuse the operation if userspace passes
> such a buffer to it.
> 
> I already posted a patch with a drm_framebuffer_check() function that
> does basic sanity checking on this stuff. I'll pull some checksa from
> that function and add them directly to drm_mode_addfb2(). Some of the
> checks require the driver to pass the BO sizes, so those I can't add.
> Also the plane overlap checks I had shouldn't be in generic code
> because some hardware can handle line-by-line interleaved planes, and
> my code would refuse those. Ideally the code should be improved to
> allow such interleaved planes, and then the check could be added to the
> generic code.
> 
> --
> Ville Syrj?l?
> Intel OTC

[PATCH libdrm] libdrm: update drm/drm_fourcc.h from kernel to add multi plane formats

[Ville Syrjälä]

On Fri, Apr 06, 2012 at 03:05:36PM +0900, Inki Dae wrote:
> Hi Ville,
> 
> > -Original Message-
> > From: Ville Syrj?l? [mailto:ville.syrjala at linux.intel.com]
> > Sent: Friday, April 06, 2012 3:14 AM
> > To: airlied at redhat.com
> > Cc: inki.dae at samsung.com; kyungmin.park at samsung.com; dri-
> > devel at lists.freedesktop.org; Seung-Woo Kim
> > Subject: Re: [PATCH libdrm] libdrm: update drm/drm_fourcc.h from kernel to
> > add multi plane formats
> > 
> > On Fri, Mar 30, 2012 at 01:12:58PM +0300, Ville Syrj?l? wrote:
> > > On Fri, Mar 30, 2012 at 11:54:50AM +0900, Seung-Woo Kim wrote:
> > > > Multi buffer plane pixel formats are added as like kernel header.
> > > >
> > > > Signed-off-by: Seung-Woo Kim 
> > > > ---
> > > >  include/drm/drm_fourcc.h |7 +++
> > > >  1 files changed, 7 insertions(+), 0 deletions(-)
> > > >
> > > > diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
> > > > index 85facb0..7cfd95a 100644
> > > > --- a/include/drm/drm_fourcc.h
> > > > +++ b/include/drm/drm_fourcc.h
> > > > @@ -107,6 +107,10 @@
> > > >  #define DRM_FORMAT_NV16fourcc_code('N', 'V', '1', '6') 
> > > > /*
> > 2x1 subsampled Cr:Cb plane */
> > > >  #define DRM_FORMAT_NV61fourcc_code('N', 'V', '6', '1') 
> > > > /*
> > 2x1 subsampled Cb:Cr plane */
> > > >
> > > > +/* 2 non contiguous plane YCbCr */
> > > > +#define DRM_FORMAT_NV12M   fourcc_code('N', 'M', '1', '2') /* 2x2
> > subsampled Cr:Cb plane */
> > >
> > > NAK. DRM_FORMAT_NV12 handles this just fine.
> > 
> > And I just realized that I was already too late with my NAK since this a
> > libdrm patch. Apparently the kernel drm_fourcc.h changes were snuck in
> > via some backdoor without review. Sigh.
> > 
> 
> We had already requested review for it. for this you can refer to link
> below:
>   
> http://lists.freedesktop.org/archives/dri-devel/2011-December/017654.html

I see. I couldn't find it in my work mailbox for some reason, and I
don't remember having seen the patch before. I suppose I just missed it
due to Christmas vacations, and was too blind to see it in my mailbox.
Also google decicded to filter my search results too much, so I didn't
spot it via the web archives either. I'm sorry for the false accusation.

> > So they're now in Linus's tree. But looks like format_check() was never
> > updated to accept them, so there's no way anyone could actually be using
> > them. So Dave, can we still remove them from the kernel header?
> > 
> 
> Yes, right. these formats aren't used for any SoCs except Exynos series yet
> but just we are first. I think they should be added because anyone may use
> them someday at least possible.

Since DRM_FORMAT_NV12M is _identical_ to DRM_FORMAT_NV12, I see no point
in adding it (similarly for YUV420M vs. YUV420).

-- 
Ville Syrj?l?
syrjala at sci.fi
http://www.sci.fi/~syrjala/

[PATCH libdrm] libdrm: update drm/drm_fourcc.h from kernel to add multi plane formats

[Kyungmin Park]

+ V4L2 develper
Sylwester, please give your opinions? How to handle it at v4l2 side.

Thank you,
Kyungmin Park
On Apr 6, 2012 12:44 AM, "Ville Syrj?l?"  wrote:

> On Fri, Apr 06, 2012 at 03:05:36PM +0900, Inki Dae wrote:
> > Hi Ville,
> >
> > > -Original Message-
> > > From: Ville Syrj?l? [mailto:ville.syrjala at linux.intel.com]
> > > Sent: Friday, April 06, 2012 3:14 AM
> > > To: airlied at redhat.com
> > > Cc: inki.dae at samsung.com; kyungmin.park at samsung.com; dri-
> > > devel at lists.freedesktop.org; Seung-Woo Kim
> > > Subject: Re: [PATCH libdrm] libdrm: update drm/drm_fourcc.h from
> kernel to
> > > add multi plane formats
> > >
> > > On Fri, Mar 30, 2012 at 01:12:58PM +0300, Ville Syrj?l? wrote:
> > > > On Fri, Mar 30, 2012 at 11:54:50AM +0900, Seung-Woo Kim wrote:
> > > > > Multi buffer plane pixel formats are added as like kernel header.
> > > > >
> > > > > Signed-off-by: Seung-Woo Kim 
> > > > > ---
> > > > >  include/drm/drm_fourcc.h |7 +++
> > > > >  1 files changed, 7 insertions(+), 0 deletions(-)
> > > > >
> > > > > diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
> > > > > index 85facb0..7cfd95a 100644
> > > > > --- a/include/drm/drm_fourcc.h
> > > > > +++ b/include/drm/drm_fourcc.h
> > > > > @@ -107,6 +107,10 @@
> > > > >  #define DRM_FORMAT_NV16fourcc_code('N', 'V', '1',
> '6') /*
> > > 2x1 subsampled Cr:Cb plane */
> > > > >  #define DRM_FORMAT_NV61fourcc_code('N', 'V', '6',
> '1') /*
> > > 2x1 subsampled Cb:Cr plane */
> > > > >
> > > > > +/* 2 non contiguous plane YCbCr */
> > > > > +#define DRM_FORMAT_NV12M   fourcc_code('N', 'M', '1', '2') /*
> 2x2
> > > subsampled Cr:Cb plane */
> > > >
> > > > NAK. DRM_FORMAT_NV12 handles this just fine.
> > >
> > > And I just realized that I was already too late with my NAK since this
> a
> > > libdrm patch. Apparently the kernel drm_fourcc.h changes were snuck in
> > > via some backdoor without review. Sigh.
> > >
> >
> > We had already requested review for it. for this you can refer to link
> > below:
> >
> >
> http://lists.freedesktop.org/archives/dri-devel/2011-December/017654.html
>
> I see. I couldn't find it in my work mailbox for some reason, and I
> don't remember having seen the patch before. I suppose I just missed it
> due to Christmas vacations, and was too blind to see it in my mailbox.
> Also google decicded to filter my search results too much, so I didn't
> spot it via the web archives either. I'm sorry for the false accusation.
>
> > > So they're now in Linus's tree. But looks like format_check() was never
> > > updated to accept them, so there's no way anyone could actually be
> using
> > > them. So Dave, can we still remove them from the kernel header?
> > >
> >
> > Yes, right. these formats aren't used for any SoCs except Exynos series
> yet
> > but just we are first. I think they should be added because anyone may
> use
> > them someday at least possible.
>
> Since DRM_FORMAT_NV12M is _identical_ to DRM_FORMAT_NV12, I see no point
> in adding it (similarly for YUV420M vs. YUV420).
>
> --
> Ville Syrj?l?
> syrjala at sci.fi
> http://www.sci.fi/~syrjala/
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120406/efd63853/attachment.htm>

[Bug 36769] Sporadic corruption of hardware cursor.

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

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

--- Comment #7 from Chris Rankin  2012-04-06 
03:55:36 PDT ---
(In reply to comment #6)
> Possibly a duplicate of bug 46796.
Or vice versa?

> Can you try the patch there or a 3.4 kernel snapshot?
I believe that this patch has now been added to both 3.2 and 3.3 stable trees
too. And no, the problem hasn't reoccurred yet - but it's still early days. I
never had a reliable method of triggering it in the first place, so I can only
*really* be sure if it *isn't* fixed...

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

[Bug 48304] text in fbterm is garbled

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

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

Michel D?nzer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||NOTOURBUG

--- Comment #8 from Michel D?nzer  2012-04-06 03:58:59 
PDT ---
(In reply to comment #7)
> You're right. It's Infinality's patches for freetype. Uninstalling them makes
> fbterm work.

Thanks for the followup, resolving.

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

[Bug 36769] Sporadic corruption of hardware cursor.

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

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

--- Comment #8 from Michel D?nzer  2012-04-06 04:06:42 
PDT ---
If your card has more than 128M of VRAM (that's just one reason why Xorg.0.log
and dmesg should be attached to every bug report...), let's mark this as a
duplicate of bug 46796, which has more information about the likely cause and
its fix. If you ever hit it again, we can go from there.

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

[Bug 48305] llpp gets segfault in r600g_dri.so

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

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

--- Comment #8 from Michel D?nzer  2012-04-06 04:11:52 
PDT ---
Smells more like a compiler bug then. Which version of gcc is this? Does it
also happen with an older one?

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

[Bug 36769] Sporadic corruption of hardware cursor.

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

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

--- Comment #9 from Chris Rankin  2012-04-06 
05:10:05 PDT ---
(In reply to comment #8)
> If your card has more than 128M of VRAM...

256 MB, to be exact:

radeon :01:00.0: putting AGP V3 device into 8x mode
radeon :01:00.0: GTT: 256M 0xC000 - 0xCFFF
[drm] Generation 2 PCI interface, using max accessible memory
radeon :01:00.0: VRAM: 256M 0xE000 - 0xEFFF (256M
used)
[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] Driver supports precise vblank timestamp query.
[drm] radeon: irq initialized.
[drm] Detected VRAM RAM=256M, BAR=256M
[drm] RAM width 128bits DDR
[TTM] Zone  kernel: Available graphics memory: 444042 kiB.
[TTM] Zone highmem: Available graphics memory: 1037688 kiB.
[TTM] Initializing pool allocator.
[drm] radeon: 256M of VRAM memory ready
[drm] radeon: 256M of GTT memory ready.

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

[PATCH 02/11] Documentation: media: description of DMABUF importing in V4L2

[Laurent Pinchart]

Hi Tomasz,

Thanks for the patch.

On Thursday 05 April 2012 15:59:59 Tomasz Stanislawski wrote:
> This patch adds description and usage examples for importing
> DMABUF file descriptor in V4L2.

[snip]

> diff --git a/Documentation/DocBook/media/v4l/io.xml
> b/Documentation/DocBook/media/v4l/io.xml index b815929..2a32363 100644
> --- a/Documentation/DocBook/media/v4l/io.xml
> +++ b/Documentation/DocBook/media/v4l/io.xml
> @@ -472,6 +472,160 @@ rest should be evident.
>
>
> 
> +  
> +Streaming I/O (DMA buffer importing)

This section is very similar to the Streaming I/O (User Pointers) section. Do 
you think we should merge the two ?

> +
> +  Experimental
> +  This is an  experimental 
> +  interface and may change in the future.
> +
> +
> +The DMABUF framework was introduced to provide a generic mean for
> sharing buffers between multiple HW devices. Some device drivers provide
> an API that may be capable to export a DMA buffer as a DMABUF file
> descriptor. The other device drivers may be configured to use such a
> buffer. They implements an API for importing of DMABUF. This section
> describes the support of DMABUF importing in V4L2.

I would rephrase this as follows:

The DMABUF framework provides a generic mean for sharing buffers between
 multiple devices. Device drivers that support DMABUF can export a DMA buffer 
to userspace as a file descriptor (known as the exporter role), import a DMA 
buffer from userspace using a file descriptor previously exported for a 
different or the same device (known as the importer role), or both. This 
section describes the DMABUF importer role API in V4L2.

> +Input and output devices support this I/O method when the
> +V4L2_CAP_STREAMING flag in the
> +capabilities field of &v4l2-capability; returned
> by the &VIDIOC-QUERYCAP; ioctl is set. If the particular importing buffer
> via DMABUF file descriptors method is supported must be determined by
> calling the &VIDIOC-REQBUFS; ioctl.

What about

Input and output devices support the streaming I/O method when the 
V4L2_CAP_STREAMING flag in the 
capabilities field of &v4l2-capability; returned by 
the &VIDIOC-QUERYCAP; ioctl is set. Whether importing DMA buffers through 
DMABUF file descriptors is supported is determined by calling the &VIDIOC-
REQBUFS; ioctl with the memory type set to 
V4L2_MEMORY_DMABUF.

> +This I/O method is dedicated for sharing DMA buffers between V4L
> and other APIs. Buffers (planes) are allocated by the application itself
> using a client API. The buffers must be exported as DMABUF file descriptor.

I would say that "Buffers (planes) are allocated by a driver on behalf of the 
application, and exported to the application as file descriptors using an API 
specific to the allocator driver."

> Only those file descriptor are exchanged, these files and meta-information
> are passed in &v4l2-buffer; (or in &v4l2-plane; in the multi-planar API
> case).  The driver must be switched into DMABUF I/O mode by calling the
> &VIDIOC-REQBUFS; with the desired buffer type. No buffers (planes) are
> allocated beforehand, consequently they are not indexed and cannot be
> queried like mapped buffers with the VIDIOC_QUERYBUF
> ioctl.

[snip]

> +Filled or displayed buffers are dequeued with the
> +&VIDIOC-DQBUF; ioctl. The driver can unpin the buffer at any
> +time between the completion of the DMA and this ioctl. The memory is
> +also unpinned when &VIDIOC-STREAMOFF; is called, &VIDIOC-REQBUFS;, or
> +when the device is closed.
>
> +For capturing applications it is customary to enqueue a
> +number of empty buffers, to start capturing and enter the read loop.
> +Here the application waits until a filled buffer can be dequeued, and
> +re-enqueues the buffer when the data is no longer needed. Output
> +applications fill and enqueue buffers, when enough buffers are stacked
> +up output is started. In the write loop, when the application
> +runs out of free buffers it must wait until an empty buffer can be
> +dequeued and reused. Two methods exist to suspend execution of the
> +application until one or more buffers can be dequeued. By default
> +VIDIOC_DQBUF blocks when no buffer is in the
> +outgoing queue. When the O_NONBLOCK flag was
> +given to the &func-open; function, VIDIOC_DQBUF
> +returns immediately with an &EAGAIN; when no buffer is available. The
> +&func-select; or &func-poll; function are always available.
> +
> +To start and stop capturing or output applications call the
> +&VIDIOC-STREAMON; and &VIDIOC-STREAMOFF; ioctl.

s/ioctl/ioctls.

> + Note VIDIOC_STREAMOFF removes all buffers from both

s/Note/Note that/

> + queues and unlocks/unpins all buffers as a side effect. Since there is no
> + notion of doing anything "now" on a multitasking system, if an application
> + needs to synchronize with another event it should examine the &v4l2-
> + buffer; timestamp of captured buffers, or set
> + the field before enqueuing buffers for output.
> +

[Bug 48382] New: weird rendering distortions on R200M

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

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

 Bug #: 48382
   Summary: weird rendering distortions on R200M
Classification: Unclassified
   Product: DRI
   Version: unspecified
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: mdskpr at gmail.com


Created attachment 59582
  --> https://bugs.freedesktop.org/attachment.cgi?id=59582
Xonotic distortion

Here are my specs:

ATI Radeon X200M (RS482)
AMD Turion 64
X.Org X11 7.4-r1 
Xorg Server- 1.11.2-r2
Mesa 7.11.2
Linux Kernel 3.2.12

I get these strange distortions in xonotic(screenie attached). This vertex
distortion also occurs in wings3D and blender.

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

[PATCH 1/2] drm/i915: fix integer overflow in i915_gem_execbuffer2()

[Xi Wang]

A large args->buffer_count from userspace may overflow the allocation
size, leading to out-of-bounds access.

Use kmalloc_array() to avoid that.

Signed-off-by: Xi Wang 
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index f51a696..19962bd 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1409,8 +1409,8 @@ i915_gem_execbuffer2(struct drm_device *dev, void *data,
return -EINVAL;
}

-   exec2_list = kmalloc(sizeof(*exec2_list)*args->buffer_count,
-GFP_KERNEL | __GFP_NOWARN | __GFP_NORETRY);
+   exec2_list = kmalloc_array(args->buffer_count, sizeof(*exec2_list),
+  GFP_KERNEL | __GFP_NOWARN | __GFP_NORETRY);
if (exec2_list == NULL)
exec2_list = drm_malloc_ab(sizeof(*exec2_list),
   args->buffer_count);
-- 
1.7.5.4

[PATCH 2/2] drm/i915: fix integer overflow in i915_gem_do_execbuffer()

[Xi Wang]

A large args->num_cliprects from userspace may overflow the allocation
size, leading to out-of-bounds access.

| i915_gem_do_execbuffer()
| i915_gem_execbuffer()

Use kmalloc_array() to avoid that.

Signed-off-by: Xi Wang 
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 19962bd..607be3d 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1133,8 +1133,8 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
return -EINVAL;
}

-   cliprects = kmalloc(args->num_cliprects * sizeof(*cliprects),
-   GFP_KERNEL);
+   cliprects = kmalloc_array(args->num_cliprects, 
sizeof(*cliprects),
+ GFP_KERNEL);
if (cliprects == NULL) {
ret = -ENOMEM;
goto pre_mutex_err;
-- 
1.7.5.4

[Bug 36769] Sporadic corruption of hardware cursor.

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

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

Alex Deucher  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE

--- Comment #10 from Alex Deucher  2012-04-06 06:14:08 PDT 
---


*** This bug has been marked as a duplicate of bug 46796 ***

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

[Bug 46796] [X800SE] Mouse cursor corruption when switching users

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

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

Alex Deucher  changed:

   What|Removed |Added

 CC||rankincj at googlemail.com

--- Comment #16 from Alex Deucher  2012-04-06 06:14:08 PDT 
---
*** Bug 36769 has been marked as a duplicate of this bug. ***

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

[Bug 48382] weird rendering distortions on R200M

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

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

Alex Deucher  changed:

   What|Removed |Added

Product|DRI |Mesa
Version|unspecified |7.11
  Component|DRM/Radeon  |Drivers/Gallium/r300

--- Comment #1 from Alex Deucher  2012-04-06 06:16:02 UTC 
---
Please attach your xorg log, dmesg output, and glxinfo output.

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

[PATCH 03/11] v4l: vb2: add support for shared buffer (dma_buf)

[Laurent Pinchart]

Hi Tomasz,

On Thursday 05 April 2012 16:00:00 Tomasz Stanislawski wrote:
> From: Sumit Semwal 
> 
> This patch adds support for DMABUF memory type in videobuf2. It calls
> relevant APIs of dma_buf for v4l reqbuf / qbuf / dqbuf operations.
> 
> For this version, the support is for videobuf2 as a user of the shared
> buffer; so the allocation of the buffer is done outside of V4L2. [A sample
> allocator of dma-buf shared buffer is given at [1]]
> 
> [1]: Rob Clark's DRM:
>https://github.com/robclark/kernel-omap4/commits/drmplane-dmabuf
> 
> Signed-off-by: Tomasz Stanislawski 
>[original work in the PoC for buffer sharing]
> Signed-off-by: Sumit Semwal 
> Signed-off-by: Sumit Semwal 
> ---
>  drivers/media/video/videobuf2-core.c |  184 ++-
>  include/media/videobuf2-core.h   |   31 ++
>  2 files changed, 214 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/media/video/videobuf2-core.c
> b/drivers/media/video/videobuf2-core.c index 2e8f1df..b37feea 100644
> --- a/drivers/media/video/videobuf2-core.c
> +++ b/drivers/media/video/videobuf2-core.c

[snip]

> @@ -451,6 +482,21 @@ static int __verify_mmap_ops(struct vb2_queue *q)
>  }
> 
>  /**
> + * __verify_dmabuf_ops() - verify that all memory operations required for
> + * DMABUF queue type have been provided
> + */
> +static int __verify_dmabuf_ops(struct vb2_queue *q)
> +{
> + if (!(q->io_modes & VB2_DMABUF) || !q->mem_ops->attach_dmabuf
> + || !q->mem_ops->detach_dmabuf
> + || !q->mem_ops->map_dmabuf
> + || !q->mem_ops->unmap_dmabuf)

That's pretty strange indentation. What about

if (!(q->io_modes & VB2_DMABUF) || !q->mem_ops->attach_dmabuf ||
!q->mem_ops->detach_dmabuf || !q->mem_ops->map_dmabuf ||
!q->mem_ops->unmap_dmabuf)

> + return -EINVAL;
> +
> + return 0;
> +}
> +
> +/**
>   * vb2_reqbufs() - Initiate streaming
>   * @q:   videobuf2 queue
>   * @req: struct passed from userspace to vidioc_reqbufs handler in driver
> @@ -484,6 +530,7 @@ int vb2_reqbufs(struct vb2_queue *q, struct
> v4l2_requestbuffers *req) }
> 
>   if (req->memory != V4L2_MEMORY_MMAP
> + && req->memory != V4L2_MEMORY_DMABUF
>   && req->memory != V4L2_MEMORY_USERPTR) {
>   dprintk(1, "reqbufs: unsupported memory type\n");
>   return -EINVAL;

Ditto.

[snip]

> @@ -620,7 +672,8 @@ int vb2_create_bufs(struct vb2_queue *q, struct
> v4l2_create_buffers *create) }
> 
>   if (create->memory != V4L2_MEMORY_MMAP
> - && create->memory != V4L2_MEMORY_USERPTR) {
> + && create->memory != V4L2_MEMORY_USERPTR
> + && create->memory != V4L2_MEMORY_DMABUF) {
>   dprintk(1, "%s(): unsupported memory type\n", __func__);
>   return -EINVAL;
>   }

And here too.

[snip]

> diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
> index a15d1f1..665e846 100644
> --- a/include/media/videobuf2-core.h
> +++ b/include/media/videobuf2-core.h

[snip]

> @@ -65,6 +82,17 @@ struct vb2_mem_ops {
>   unsigned long size, int write);
>   void(*put_userptr)(void *buf_priv);
> 
> + /*
> +  * Comment from Rob Clark: XXX: I think the attach / detach could be
> +  * handled in the vb2 core, and vb2_mem_ops really just need to get/put
> +  * the sglist (and make sure that the sglist fits it's needs..)
> +  */

I think we should address this now. We've previously discussed the question, 
but haven't reached an agreement.

Quoting my reply to "[RFCv2 PATCH 3/9] v4l: vb2: Add dma-contig allocator as 
dma_buf user" on 28/03/2012:

> > Calling dma_buf_attach could be moved to vb2-core. But it gives little
> > gain. First, the pointer of dma_buf_attachment would have to be added to
> > struct vb2_plane. Second, the allocator would have to keep in the copy of
> > this pointer in its context structure for use of vb2_dc_(un)map_dmabuf
> > functions.
> 
> Right. Would it make sense to pass the vb2_plane pointer, or possibly the 
> dma_buf_attachment pointer, to the mmap_dmabuf and unmap_dmabuf operations ?
> 
> > Third, dma_buf_attach requires a pointer to 'struct device' which is not
> > available in the vb2-core layer.
> 
> OK, that's a problem.
> 
> > Because of the mentioned reasons I decided to keep attach_dmabuf in
> > allocator-specific code.
> 
> Maybe it would make sense to create a vb2_mem_buf structure from which 
> vb2_dc_buf (and other allocator-specific buffer descriptors) would inherit ? 
> That structure would store the dma_buf_attach pointer, and common dma-buf
> code could be put in videobuf2-memops.c and shared between allocators. Just
> an idea.

If we find out that the best course of action is to leave the code as-is, we 
should remove the above comment.

> + void*(*attach_

[PATCH 09/11] v4l: vb2: add prepare/finish callbacks to allocators

[Laurent Pinchart]

Hi Tomasz,

On Thursday 05 April 2012 16:00:06 Tomasz Stanislawski wrote:
> From: Marek Szyprowski 
> 
> This patch adds support for prepare/finish callbacks in VB2 allocators.
> These callback are used for buffer flushing.
> 
> Signed-off-by: Marek Szyprowski 
> ---
>  drivers/media/video/videobuf2-core.c |   11 +++
>  include/media/videobuf2-core.h   |7 +++
>  2 files changed, 18 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/media/video/videobuf2-core.c
> b/drivers/media/video/videobuf2-core.c index b37feea..abb0592 100644
> --- a/drivers/media/video/videobuf2-core.c
> +++ b/drivers/media/video/videobuf2-core.c
> @@ -834,6 +834,7 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum
> vb2_buffer_state state) {
>   struct vb2_queue *q = vb->vb2_queue;
>   unsigned long flags;
> + int plane;

Please make plane an unsigned int, otherwise you will compare a signed and an 
unsigned int below.

> 
>   if (vb->state != VB2_BUF_STATE_ACTIVE)
>   return;
> @@ -844,6 +845,10 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum
> vb2_buffer_state state) dprintk(4, "Done processing on buffer %d, state:
> %d\n",
>   vb->v4l2_buf.index, vb->state);
> 
> + /* sync buffers */
> + for (plane = 0; plane < vb->num_planes; ++plane)
> + call_memop(q, finish, vb->planes[plane].mem_priv);
> +
>   /* Add the buffer to the done buffers list */
>   spin_lock_irqsave(&q->done_lock, flags);
>   vb->state = state;
> @@ -1131,9 +1136,15 @@ err:
>  static void __enqueue_in_driver(struct vb2_buffer *vb)
>  {
>   struct vb2_queue *q = vb->vb2_queue;
> + int plane;

Same here.

>   vb->state = VB2_BUF_STATE_ACTIVE;
>   atomic_inc(&q->queued_count);
> +
> + /* sync buffers */
> + for (plane = 0; plane < vb->num_planes; ++plane)
> + call_memop(q, prepare, vb->planes[plane].mem_priv);
> +
>   q->ops->buf_queue(vb);
>  }

-- 
Regards,

Laurent Pinchart

[PATCH 1/2] drm/i915: fix integer overflow in i915_gem_execbuffer2()

[Chris Wilson]

On Fri,  6 Apr 2012 08:58:18 -0400, Xi Wang  wrote:
> A large args->buffer_count from userspace may overflow the allocation
> size, leading to out-of-bounds access.
> 
> Use kmalloc_array() to avoid that.

I can safely say that exec list larger than 4GiB is going to be an
illegal operation and would rather the ioctl failed outright with
EINVAL.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH 1/2] drm/i915: fix integer overflow in i915_gem_execbuffer2()

[Xi Wang]

On Apr 6, 2012, at 9:36 AM, Chris Wilson wrote:

> On Fri,  6 Apr 2012 08:58:18 -0400, Xi Wang  wrote:
>> A large args->buffer_count from userspace may overflow the allocation
>> size, leading to out-of-bounds access.
>> 
>> Use kmalloc_array() to avoid that.
> 
> I can safely say that exec list larger than 4GiB is going to be an
> illegal operation and would rather the ioctl failed outright with
> EINVAL.

On 32-bit platform?

- xi

[PATCH 1/2] drm/i915: fix integer overflow in i915_gem_execbuffer2()

[Chris Wilson]

On Fri, 6 Apr 2012 09:46:46 -0400, Xi Wang  wrote:
> On Apr 6, 2012, at 9:36 AM, Chris Wilson wrote:
> 
> > On Fri,  6 Apr 2012 08:58:18 -0400, Xi Wang  wrote:
> >> A large args->buffer_count from userspace may overflow the allocation
> >> size, leading to out-of-bounds access.
> >> 
> >> Use kmalloc_array() to avoid that.
> > 
> > I can safely say that exec list larger than 4GiB is going to be an
> > illegal operation and would rather the ioctl failed outright with
> > EINVAL.
> 
> On 32-bit platform?

On any platform. The largest it can legally be is a few tens of megabytes.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH 1/2] drm/i915: fix integer overflow in i915_gem_execbuffer2()

[Xi Wang]

On Apr 6, 2012, at 9:54 AM, Chris Wilson wrote:

> On Fri, 6 Apr 2012 09:46:46 -0400, Xi Wang  wrote:
>> On Apr 6, 2012, at 9:36 AM, Chris Wilson wrote:
>> 
>>> On Fri,  6 Apr 2012 08:58:18 -0400, Xi Wang  wrote:
 A large args->buffer_count from userspace may overflow the allocation
 size, leading to out-of-bounds access.
 
 Use kmalloc_array() to avoid that.
>>> 
>>> I can safely say that exec list larger than 4GiB is going to be an
>>> illegal operation and would rather the ioctl failed outright with
>>> EINVAL.
>> 
>> On 32-bit platform?
> 
> On any platform. The largest it can legally be is a few tens of megabytes.

IDGI.  First we come to i915_gem_execbuffer2() from ioctl:

  exec2_list = kmalloc(sizeof(*exec2_list)*args->buffer_count, ...);

args->buffer_count is passed from userspace so it can be any value.
Let it overflow the 32-bit multiplication and turn the call to:

  exec2_list = kmalloc(0, ...);

Then the subsequent call to i915_gem_do_execbuffer(..., exec2_list)
may read exec2_list, which is out of bounds.

- xi

[Bug 48382] weird rendering distortions on R200M

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

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

--- Comment #2 from Ned Anderson  2012-04-06 07:38:02 PDT 
---
Created attachment 59587
  --> https://bugs.freedesktop.org/attachment.cgi?id=59587
xorg log

Xorg Log

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

[Bug 48382] weird rendering distortions on R200M

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

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

--- Comment #3 from Ned Anderson  2012-04-06 07:38:37 PDT 
---
Created attachment 59588
  --> https://bugs.freedesktop.org/attachment.cgi?id=59588
Dmesg

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

[Bug 48382] weird rendering distortions on R200M

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

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

--- Comment #4 from Ned Anderson  2012-04-06 07:39:16 PDT 
---
Created attachment 59589
  --> https://bugs.freedesktop.org/attachment.cgi?id=59589
glxinfo output

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

[PATCH 1/2] drm/i915: fix integer overflow in i915_gem_execbuffer2()

[Chris Wilson]

On Fri, 6 Apr 2012 10:01:36 -0400, Xi Wang  wrote:
> On Apr 6, 2012, at 9:54 AM, Chris Wilson wrote:
> 
> > On Fri, 6 Apr 2012 09:46:46 -0400, Xi Wang  wrote:
> >> On Apr 6, 2012, at 9:36 AM, Chris Wilson wrote:
> >> 
> >>> On Fri,  6 Apr 2012 08:58:18 -0400, Xi Wang  wrote:
>  A large args->buffer_count from userspace may overflow the allocation
>  size, leading to out-of-bounds access.
>  
>  Use kmalloc_array() to avoid that.
> >>> 
> >>> I can safely say that exec list larger than 4GiB is going to be an
> >>> illegal operation and would rather the ioctl failed outright with
> >>> EINVAL.
> >> 
> >> On 32-bit platform?
> > 
> > On any platform. The largest it can legally be is a few tens of megabytes.
> 
> IDGI.  First we come to i915_gem_execbuffer2() from ioctl:
> 
>   exec2_list = kmalloc(sizeof(*exec2_list)*args->buffer_count, ...);
> 
> args->buffer_count is passed from userspace so it can be any value.

That I agreed with, I just disagree with how you chose to handle it.
Rather than continue on and attempt to vmalloc a large array we should
just fail the ioctl with EINVAL.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH 08/11] v4l: vb2-dma-contig: add support for scatterlist in userptr mode

[Laurent Pinchart]

Hi Tomasz,

On Thursday 05 April 2012 16:00:05 Tomasz Stanislawski wrote:
> From: Andrzej Pietrasiewicz 
> 
> This patch introduces usage of dma_map_sg to map memory behind
> a userspace pointer to a device as dma-contiguous mapping.
> 
> Signed-off-by: Andrzej Pietrasiewicz 
> Signed-off-by: Marek Szyprowski 
>   [bugfixing]
> Signed-off-by: Kamil Debski 
>   [bugfixing]
> Signed-off-by: Tomasz Stanislawski 
>   [add sglist subroutines/code refactoring]
> Signed-off-by: Kyungmin Park 
> ---
>  drivers/media/video/videobuf2-dma-contig.c |  282 +++--
>  1 files changed, 265 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/media/video/videobuf2-dma-contig.c
> b/drivers/media/video/videobuf2-dma-contig.c index 476e536..6ab3165 100644
> --- a/drivers/media/video/videobuf2-dma-contig.c
> +++ b/drivers/media/video/videobuf2-dma-contig.c

[snip]

> @@ -32,6 +36,98 @@ struct vb2_dc_buf {
>  };
> 
>  /*/
> +/*scatterlist table functions*/
> +/*/
> +
> +static struct sg_table *vb2_dc_pages_to_sgt(struct page **pages,
> + unsigned long n_pages, size_t offset, size_t offset2)

"offset2" isn't very descriptive. I would replace it with the total size of 
the buffer instead (or, alternatively, rename offset to offset_start and 
offset2 to offset_end, but I like the first option better).

> +{
> + struct sg_table *sgt;
> + int i, j; /* loop counters */

I don't think the comment is needed.

> + int cur_page, chunks;

i, j, cur_page and chunks can't be negative. Could you please make them 
unsigned int (and I would order them) ?

Also, Documentation/CodingStyle favors one variable declaration per line, 
without commas for multiple declarations.

> + int ret;
> + struct scatterlist *s;
> +
> + sgt = kzalloc(sizeof *sgt, GFP_KERNEL);
> + if (!sgt)
> + return ERR_PTR(-ENOMEM);
> +
> + /* compute number of chunks */
> + chunks = 1;
> + for (i = 1; i < n_pages; ++i)
> + if (pages[i] != pages[i - 1] + 1)
> + ++chunks;
> +
> + ret = sg_alloc_table(sgt, chunks, GFP_KERNEL);
> + if (ret) {
> + kfree(sgt);
> + return ERR_PTR(-ENOMEM);
> + }
> +
> + /* merging chunks and putting them into the scatterlist */
> + cur_page = 0;
> + for_each_sg(sgt->sgl, s, sgt->orig_nents, i) {
> + size_t size = PAGE_SIZE;
> +
> + for (j = cur_page + 1; j < n_pages; ++j) {
> + if (pages[j] != pages[j - 1] + 1)
> + break;
> + size += PAGE_SIZE;
> + }
> +
> + /* cut offset if chunk starts at the first page */
> + if (cur_page == 0)
> + size -= offset;
> + /* cut offset2 if chunk ends at the last page */
> + if (j == n_pages)
> + size -= offset2;
> +
> + sg_set_page(s, pages[cur_page], size, offset);
> + offset = 0;
> + cur_page = j;
> + }
> +
> + return sgt;
> +}
> +
> +static void vb2_dc_release_sgtable(struct sg_table *sgt)
> +{
> + sg_free_table(sgt);
> + kfree(sgt);
> +}
> +
> +static void vb2_dc_sgt_foreach_page(struct sg_table *sgt,
> + void (*cb)(struct page *pg))
> +{
> + struct scatterlist *s;
> + int i, j;
> +
> + for_each_sg(sgt->sgl, s, sgt->nents, i) {
> + struct page *page = sg_page(s);
> + int n_pages = PAGE_ALIGN(s->offset + s->length) >> PAGE_SHIFT;
> +
> + for (j = 0; j < n_pages; ++j, ++page)
> + cb(page);

Same for i, j and n_pages here.

> + }
> +}
> +
> +static unsigned long vb2_dc_get_contiguous_size(struct sg_table *sgt)
> +{
> + struct scatterlist *s;
> + dma_addr_t expected = sg_dma_address(sgt->sgl);
> + int i;

Same for i here.

> + unsigned long size = 0;
> +
> + for_each_sg(sgt->sgl, s, sgt->nents, i) {
> + if (sg_dma_address(s) != expected)
> + break;
> + expected = sg_dma_address(s) + sg_dma_len(s);
> + size += sg_dma_len(s);
> + }
> + return size;
> +}
> +
> +/*/
>  /* callbacks for all buffers */
>  /*/
> 
> @@ -116,42 +212,194 @@ static int vb2_dc_mmap(void *buf_priv, struct
> vm_area_struct *vma) /*   callbacks for USERPTR buffers   */
>  /*/
> 
> +static inline int vma_is_io(struct vm_area_struct *vma)
> +{
> + return !!(vma->vm_flags & (VM_IO | VM_PFNMAP));
> +}
> +
> +static struct vm_area_struct *vb2_dc_get_user_vma(
> + unsigned long start, unsigned long size)
> +{
> + struct vm_area_struct *vma;
> +
> + /* current->mm->mmap_sem is taken by videobuf2 core */
> + vma = fin

[PATCH 11/11] v4l: vb2: Add dma-contig allocator as dma_buf user

[Laurent Pinchart]

Hi Tomasz,

On Thursday 05 April 2012 16:00:08 Tomasz Stanislawski wrote:
> From: Sumit Semwal 
> 
> This patch makes changes for adding dma-contig as a dma_buf user. It
> provides function implementations for the {attach, detach, map,
> unmap}_dmabuf() mem_ops of DMABUF memory type.
> 
> Signed-off-by: Sumit Semwal 
> Signed-off-by: Sumit Semwal 
>   [author of the original patch]
> Signed-off-by: Tomasz Stanislawski 
>   [integration with refactored dma-contig allocator]
> ---
>  drivers/media/video/videobuf2-dma-contig.c |  117 +
>  1 files changed, 117 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/media/video/videobuf2-dma-contig.c
> b/drivers/media/video/videobuf2-dma-contig.c index 30f316588..6329483
> 100644
> --- a/drivers/media/video/videobuf2-dma-contig.c
> +++ b/drivers/media/video/videobuf2-dma-contig.c
> @@ -10,6 +10,7 @@
>   * the Free Software Foundation.
>   */
> 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -33,6 +34,9 @@ struct vb2_dc_buf {
> 
>   /* USERPTR related */
>   struct vm_area_struct   *vma;
> +
> + /* DMABUF related */
> + struct dma_buf_attachment   *db_attach;
>  };
> 
>  /*/
> @@ -425,6 +429,115 @@ fail_buf:
>  }
> 
>  /*/
> +/*   callbacks for DMABUF buffers*/
> +/*/
> +
> +static int vb2_dc_map_dmabuf(void *mem_priv)
> +{
> + struct vb2_dc_buf *buf = mem_priv;
> + struct sg_table *sgt;
> + unsigned long contig_size;
> + int ret = 0;
> +
> + if (WARN_ON(!buf->db_attach)) {
> + printk(KERN_ERR "trying to pin a non attached buffer\n");
> + return -EINVAL;
> + }
> +
> + if (WARN_ON(buf->dma_sgt)) {
> + printk(KERN_ERR "dmabuf buffer is already pinned\n");
> + return 0;
> + }
> +
> + /* get the associated scatterlist for this buffer */
> + sgt = dma_buf_map_attachment(buf->db_attach, buf->dma_dir);
> + if (IS_ERR_OR_NULL(sgt)) {
> + printk(KERN_ERR "Error getting dmabuf scatterlist\n");
> + return -EINVAL;
> + }
> +
> + /* checking if dmabuf is big enough to store contiguous chunk */
> + contig_size = vb2_dc_get_contiguous_size(sgt);
> + if (contig_size < buf->size) {
> + printk(KERN_ERR "contiguous chunk of dmabuf is too small\n");
> + ret = -EFAULT;
> + goto fail_map;

The fail_map label is only used here, you can move the 
dma_buf_unmap_attachment() call here and return -EFAULT directly.

> + }
> +
> + buf->dma_addr = sg_dma_address(sgt->sgl);
> + buf->dma_sgt = sgt;
> +
> + return 0;
> +
> +fail_map:
> + dma_buf_unmap_attachment(buf->db_attach, sgt, buf->dma_dir);
> +
> + return ret;
> +}
> +
> +static void vb2_dc_unmap_dmabuf(void *mem_priv)
> +{
> + struct vb2_dc_buf *buf = mem_priv;
> + struct sg_table *sgt = buf->dma_sgt;
> +
> + if (WARN_ON(!buf->db_attach)) {
> + printk(KERN_ERR "trying to unpin a not attached buffer\n");
> + return;
> + }
> +
> + if (WARN_ON(!sgt)) {
> + printk(KERN_ERR "dmabuf buffer is already unpinned\n");
> + return;
> + }
> +
> + dma_buf_unmap_attachment(buf->db_attach, sgt, buf->dma_dir);
> +
> + buf->dma_addr = 0;
> + buf->dma_sgt = NULL;
> +}
> +
> +static void vb2_dc_detach_dmabuf(void *mem_priv)
> +{
> + struct vb2_dc_buf *buf = mem_priv;
> +
> + if (buf->dma_addr)
> + vb2_dc_unmap_dmabuf(buf);

What would you think about calling vb2_dc_unmap_dmabuf() from vb2 core 
instead, to keep the map/unmap calls symmetrical (the second WARN_ON and the 
related printk in vb2_dc_unmap_dmabuf() might need to go then) ?

> + /* detach this attachment */
> + dma_buf_detach(buf->db_attach->dmabuf, buf->db_attach);
> + kfree(buf);
> +}
> +
> +static void *vb2_dc_attach_dmabuf(void *alloc_ctx, struct dma_buf *dbuf,
> + unsigned long size, int write)
> +{
> + struct vb2_dc_buf *buf;
> + struct dma_buf_attachment *dba;
> +
> + if (dbuf->size < size)
> + return ERR_PTR(-EFAULT);
> +
> + buf = kzalloc(sizeof *buf, GFP_KERNEL);
> + if (!buf)
> + return ERR_PTR(-ENOMEM);
> +
> + buf->dev = alloc_ctx;
> + /* create attachment for the dmabuf with the user device */
> + dba = dma_buf_attach(dbuf, buf->dev);
> + if (IS_ERR(dba)) {
> + printk(KERN_ERR "failed to attach dmabuf\n");
> + kfree(buf);
> + return dba;
> + }
> +
> + buf->dma_dir = write ? DMA_FROM_DEVICE : DMA_TO_DEVICE;
> + buf->size = size;
> + buf->db_attach = dba;
> +
> + return buf;
> +}
> +
> +/*/
>  /*   DMA CONTIG exported functions   */
>  /*/
> 
> @@ -438,6 +551,

[PATCH libdrm] libdrm: update drm/drm_fourcc.h from kernel to add multi plane formats

[Sylwester Nawrocki]

Hello,

On 04/06/2012 11:22 AM, Kyungmin Park wrote:
> + V4L2 develper
> Sylwester, please give your opinions? How to handle it at v4l2 side.
> 
> Thank you,
> Kyungmin Park
> 
> On Apr 6, 2012 12:44 AM, "Ville Syrj?l?"  > wrote:
> 
> On Fri, Apr 06, 2012 at 03:05:36PM +0900, Inki Dae wrote:
> > Hi Ville,
> >
> > > -Original Message-
> > > From: Ville Syrj?l? [mailto:ville.syrjala at linux.intel.com
> ]
> > > Sent: Friday, April 06, 2012 3:14 AM
> > > To: airlied at redhat.com 
> > > Cc: inki.dae at samsung.com ;
> kyungmin.park at samsung.com ; dri-
> > > devel at lists.freedesktop.org  lists.freedesktop.org>;
> Seung-Woo Kim
> > > Subject: Re: [PATCH libdrm] libdrm: update drm/drm_fourcc.h from 
> kernel to
> > > add multi plane formats
> > >
> > > On Fri, Mar 30, 2012 at 01:12:58PM +0300, Ville Syrj?l? wrote:
> > > > On Fri, Mar 30, 2012 at 11:54:50AM +0900, Seung-Woo Kim wrote:
> > > > > Multi buffer plane pixel formats are added as like kernel header.
> > > > >
> > > > > Signed-off-by: Seung-Woo Kim  >
> > > > > ---
> > > > >  include/drm/drm_fourcc.h |7 +++
> > > > >  1 files changed, 7 insertions(+), 0 deletions(-)
> > > > >
> > > > > diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
> > > > > index 85facb0..7cfd95a 100644
> > > > > --- a/include/drm/drm_fourcc.h
> > > > > +++ b/include/drm/drm_fourcc.h
> > > > > @@ -107,6 +107,10 @@
> > > > >  #define DRM_FORMAT_NV16fourcc_code('N', 'V', '1',
> '6') /*
> > > 2x1 subsampled Cr:Cb plane */
> > > > >  #define DRM_FORMAT_NV61fourcc_code('N', 'V', '6',
> '1') /*
> > > 2x1 subsampled Cb:Cr plane */
> > > > >
> > > > > +/* 2 non contiguous plane YCbCr */
> > > > > +#define DRM_FORMAT_NV12M   fourcc_code('N', 'M', '1', '2') 
> /* 2x2
> > > subsampled Cr:Cb plane */
> > > >
> > > > NAK. DRM_FORMAT_NV12 handles this just fine.
> > >
> > > And I just realized that I was already too late with my NAK since 
> this a
> > > libdrm patch. Apparently the kernel drm_fourcc.h changes were snuck in
> > > via some backdoor without review. Sigh.
> > >
> >
> > We had already requested review for it. for this you can refer to link
> > below:
> >
> > 
> http://lists.freedesktop.org/archives/dri-devel/2011-December/017654.html
> 
> I see. I couldn't find it in my work mailbox for some reason, and I
> don't remember having seen the patch before. I suppose I just missed it
> due to Christmas vacations, and was too blind to see it in my mailbox.
> Also google decicded to filter my search results too much, so I didn't
> spot it via the web archives either. I'm sorry for the false accusation.
> 
> > > So they're now in Linus's tree. But looks like format_check() was 
> never
> > > updated to accept them, so there's no way anyone could actually be 
> using
> > > them. So Dave, can we still remove them from the kernel header?
> > >
> >
> > Yes, right. these formats aren't used for any SoCs except Exynos series 
> yet
> > but just we are first. I think they should be added because anyone may 
> use
> > them someday at least possible.
> 
> Since DRM_FORMAT_NV12M is _identical_ to DRM_FORMAT_NV12, I see no point
> in adding it (similarly for YUV420M vs. YUV420).

In V4L2 the fourcc also determines the number of memory planes in the frame
buffer. The multi-planar API has been added to support devices with odd
alignment requirements (image components, like Y/CbCr in separate physical
memory buffers) for which it was difficult to map whole frame into contiguous
user memory region.

Here is some excample:
http://linuxtv.org/downloads/v4l-dvb-apis/V4L2-PIX-FMT-NV12M.html

I'm not terribly familiar with the buffer structure in DRM, maybe there are
better ways to handle something like this in DRI.

> --
> Ville Syrj?l?
> syrjala at sci.fi 
> http://www.sci.fi/~syrjala/

Regards,
-- 
Sylwester Nawrocki
Samsung Poland R&D Center

[Bug 48382] weird rendering distortions on R200M

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

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

--- Comment #5 from Ned Anderson  2012-04-06 09:09:54 PDT 
---
Also fyi, i noticed that the same thing occurs in a different game(BZFlag) when
i turn on shadows...

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

[PATCH 1/2] drm/i915: fix integer overflow in i915_gem_execbuffer2()

[Xi Wang]

On Apr 6, 2012, at 10:44 AM, Chris Wilson wrote:

> That I agreed with, I just disagree with how you chose to handle it.
> Rather than continue on and attempt to vmalloc a large array we should
> just fail the ioctl with EINVAL.

Why an attempt to vmalloc?  The overflow check in drm_malloc_ab()
will simply return NULL and fail the ioctl with -ENOMEM.

- xi

[PATCH 1/2] drm/i915: fix integer overflow in i915_gem_execbuffer2()

[Chris Wilson]

On Fri, 6 Apr 2012 14:17:41 -0400, Xi Wang  wrote:
> On Apr 6, 2012, at 10:44 AM, Chris Wilson wrote:
> 
> > That I agreed with, I just disagree with how you chose to handle it.
> > Rather than continue on and attempt to vmalloc a large array we should
> > just fail the ioctl with EINVAL.
> 
> Why an attempt to vmalloc?  The overflow check in drm_malloc_ab()
> will simply return NULL and fail the ioctl with -ENOMEM.

It's an invalid value for the ioctl and should be treated as such, not
making ENOMEM more ambiguous.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH 1/2] drm/i915: fix integer overflow in i915_gem_execbuffer2()

[Xi Wang]

On Apr 6, 2012, at 3:40 PM, Chris Wilson wrote:
> On Fri, 6 Apr 2012 14:17:41 -0400, Xi Wang  wrote:
>> 
>> Why an attempt to vmalloc?  The overflow check in drm_malloc_ab()
>> will simply return NULL and fail the ioctl with -ENOMEM.
> 
> It's an invalid value for the ioctl and should be treated as such, not
> making ENOMEM more ambiguous.

We could copy and paste the overflow check so as to return -EINVAL.
I just doubt how much that would help --- you can find existing usages
in other functions, for example, in i915_gem_execbuffer():

  /* Copy in the exec list from userland */
  exec_list = drm_malloc_ab(sizeof(*exec_list), args->buffer_count);
  exec2_list = drm_malloc_ab(sizeof(*exec2_list), args->buffer_count);
  if (exec_list == NULL || exec2_list == NULL) {
  DRM_DEBUG("Failed to allocate exec list for %d buffers\n",
args->buffer_count);
  drm_free_large(exec_list);
  drm_free_large(exec2_list);
  return -ENOMEM;
  }

Should we fix all these as well by repeating the checks and returning
-EINVAL?  I am worried about the code bloat / readability price you
would pay for getting a different error code.

BTW, I've also seen code using E2BIG.  Any documented guideline?

- xi

i915_driver_irq_handler: irq 42: nobody cared [generic IRQ handling broken?]

[Jiri Slaby]

On 03/30/2012 02:24 PM, Chris Wilson wrote:
> On Fri, 30 Mar 2012 14:11:47 +0200, Jiri Slaby  wrote:
>> On 03/30/2012 12:45 PM, Chris Wilson wrote:
>>> On Fri, 30 Mar 2012 11:59:28 +0200, Jiri Slaby  wrote:
 I don't know what to dump more, because iir is obviously zero too. What
 other sources of interrupts are on the (G33) chip?
>>>
>>> IIR is the master interrupt, with chained secondary interrupt statuses.
>>> If IIR is 0, the interrupt wasn't raised by the GPU.
>>
>> This does not make sense, the handler does something different. Even if
>> IIR is 0, it still takes a look at pipe stats.
> 
> That was introduced in 05eff845a28499762075d3a72e238a31f4d2407c to close
> a race where the pipestat triggered an interrupt after we processed the
> secondary registers and before reseting the primary.
> 
> But the basic premise that we should only enter the interrupt handler
> with IIR!=0 holds (presuming non-shared interrupt lines such as MSI).

Ok, this behavior is definitely new. I get several "nobody cared" about
this interrupt a week. This never used to happen. And something weird
emerges in /proc/interrupts when this happens:
 42:10032921212890   PCI-MSI-edge  ?s::00:02.0
instead of
 42:10067151218472   PCI-MSI-edge  i915 at pci::00:02.0

It very looks like the generic IRQ handling code is broken. Like it
frees/corrupts irq_desc and then as well calls random handlers.

Suspend/resume cycle helps in this case and "i915 at pci::00:02.0" is
back in /proc/interrupts as can be seen above.

Running 3.3.0-next-20120326_64+ now.

thanks,
-- 
js
suse labs

[PATCH] drm/savage: fix integer overflows in savage_bci_cmdbuf()

[Xi Wang]

Since cmdbuf->size and cmdbuf->nbox are from userspace, a large value
would overflow the allocation size, leading to out-of-bounds access.

Signed-off-by: Xi Wang 
---
 drivers/gpu/drm/savage/savage_state.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/savage/savage_state.c 
b/drivers/gpu/drm/savage/savage_state.c
index 031aaaf..b6d8608 100644
--- a/drivers/gpu/drm/savage/savage_state.c
+++ b/drivers/gpu/drm/savage/savage_state.c
@@ -988,7 +988,7 @@ int savage_bci_cmdbuf(struct drm_device *dev, void *data, 
struct drm_file *file_
 * for locking on FreeBSD.
 */
if (cmdbuf->size) {
-   kcmd_addr = kmalloc(cmdbuf->size * 8, GFP_KERNEL);
+   kcmd_addr = kmalloc_array(cmdbuf->size, 8, GFP_KERNEL);
if (kcmd_addr == NULL)
return -ENOMEM;

@@ -1015,8 +1015,8 @@ int savage_bci_cmdbuf(struct drm_device *dev, void *data, 
struct drm_file *file_
cmdbuf->vb_addr = kvb_addr;
}
if (cmdbuf->nbox) {
-   kbox_addr = kmalloc(cmdbuf->nbox * sizeof(struct drm_clip_rect),
-   GFP_KERNEL);
+   kbox_addr = kmalloc_array(cmdbuf->nbox, sizeof(struct 
drm_clip_rect),
+ GFP_KERNEL);
if (kbox_addr == NULL) {
ret = -ENOMEM;
goto done;
-- 
1.7.5.4

[PATCH libdrm] libdrm: update drm/drm_fourcc.h from kernel to add multi plane formats

[Sylwester Nawrocki]

On 03/30/2012 01:09 PM, Marcus Lorentzon wrote:
> On 03/30/2012 12:12 PM, Ville Syrj?l? wrote:
>>> +#define DRM_FORMAT_NV12MT fourcc_code('T', 'M', '1', '2') /* 2x2
>>> subsampled Cr:Cb plane 64x32 macroblocks */
>> This one is more difficult. Until now tiling was always handled in
>> driver specific manner. OTOH if this format is really supported by
>> different devices from multiple vendors, then it would probably
>> make sense to add it as a standard format.
>>
> What about adding a DRM_FORMAT_PRIV_NV12MT and force vendor to add
> detailed documentation about this new format. Because if the format is
> not defined and documented, how will we ever discover if vendors have
> similar formats? And if we document all these MB formats "everyone"
> uses, then maybe we can get HW vendors to unify on a de facto standard.
> It would be nice to have an efficient format supported by everyone,
> instead of having to fallback to old linear formats every time you
> interact with another device.

Just for the record, documentation of this tiled macro-block format
can be found here:

http://linuxtv.org/downloads/v4l-dvb-apis/re27.html

--
Regards,
Sylwester