Hello everyone,
This patchset adds support for DMABUF [2] importing to V4L2 stack. It was
updated after Laurent Pinchart's review. The support for DMABUF exporting was
moved to separate patchset due to dependency on patches for DMA mapping
redesign by Marek Szyprowski [4].
v3:
- rebased on mainline 3.4-rc1
- split 'code refactor' patch to multiple smaller patches
- squashed fixes to Sumit's patches
- patchset is no longer dependant on 'DMA mapping redesign'
- separated path for handling IO …
[View More]and non-IO mappings
- add documentation for DMABUF importing to V4L
- removed all DMABUF exporter related code
- removed usage of dma_get_pages extension
v2:
- extended VIDIOC_EXPBUF argument from integer memoffset to struct
v4l2_exportbuffer
- added patch that breaks DMABUF spec on (un)map_atachment callcacks but allows
to work with existing implementation of DMABUF prime in DRM
- all dma-contig code refactoring patches were squashed
- bugfixes
v1: List of changes since [1].
- support for DMA api extension dma_get_pages, the function is used to retrieve
pages used to create DMA mapping.
- small fixes/code cleanup to videobuf2
- added prepare and finish callbacks to vb2 allocators, it is used keep
consistency between dma-cpu acess to the memory (by Marek Szyprowski)
- support for exporting of DMABUF buffer in V4L2 and Videobuf2, originated from
[3].
- support for dma-buf exporting in vb2-dma-contig allocator
- support for DMABUF for s5p-tv and s5p-fimc (capture interface) drivers,
originated from [3]
- changed handling for userptr buffers (by Marek Szyprowski, Andrzej
Pietrasiewicz)
- let mmap method to use dma_mmap_writecombine call (by Marek Szyprowski)
[1] http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/4296…
[2] https://lkml.org/lkml/2011/12/26/29
[3] http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/3635…
[4] http://thread.gmane.org/gmane.linux.kernel.cross-arch/12819
Andrzej Pietrasiewicz (1):
v4l: vb2-dma-contig: add support for scatterlist in userptr mode
Laurent Pinchart (2):
v4l: vb2-dma-contig: Shorten vb2_dma_contig prefix to vb2_dc
v4l: vb2-dma-contig: Reorder functions
Marek Szyprowski (2):
v4l: vb2: add prepare/finish callbacks to allocators
v4l: vb2-dma-contig: add prepare/finish to dma-contig allocator
Sumit Semwal (4):
v4l: Add DMABUF as a memory type
v4l: vb2: add support for shared buffer (dma_buf)
v4l: vb: remove warnings about MEMORY_DMABUF
v4l: vb2: Add dma-contig allocator as dma_buf user
Tomasz Stanislawski (2):
Documentation: media: description of DMABUF importing in V4L2
v4l: vb2-dma-contig: Remove unneeded allocation context structure
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 +-
drivers/media/video/videobuf-core.c | 4 +
drivers/media/video/videobuf2-core.c | 195 +++++++-
drivers/media/video/videobuf2-dma-contig.c | 536 +++++++++++++++++---
include/linux/videodev2.h | 8 +
include/media/videobuf2-core.h | 38 ++
10 files changed, 910 insertions(+), 76 deletions(-)
--
1.7.5.4
[View Less]
https://bugzilla.kernel.org/show_bug.cgi?id=29412
Summary: fans running at full-speed after resume from suspend
with radeon and KMS
Product: Drivers
Version: 2.5
Kernel Version: 2.6.38-rc5+
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Video(DRI - non Intel)
AssignedTo: drivers_video-dri(a)kernel-bugs.…
[View More]osdl.org
ReportedBy: jon+bugzilla.kernel.org(a)alcopop.org
Regression: No
Hi,
Originally reported against the wrong product, here:
https://bugzilla.kernel.org/show_bug.cgi?id=18552
I have an ATI Radeon X850XT PCIE card plugged into an Intel DG35EC motherboard.
With kernels since 2.6.32-rc1 and most recently tested with mainline commit
2a324ce7b79a3a90cc2d4ade5d5f960a99000caa (2.6.38-rc5+), if I attempt a
suspend-to-ram, upon resume, the fan on my ATI card remains at full speed
(loud), and does not throttle back to quiet (normal behaviour).
Booting with 'radeon.modeset=0' prevents this.
Please let me know what further information is needed.
Thanks!
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
--
_______________________________________________
Dri-devel mailing list
Dri-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[View Less]
https://bugs.freedesktop.org/show_bug.cgi?id=17902
--- Comment #65 from Daniel Vetter <daniel(a)ffwll.ch> 2012-04-16 11:24:43 PDT ---
You need to check where the dvo chip actually is, i915 has about 6 different
i2c channels. The easiest way is to use one of the i2c-tools to detect chips on
all the i2c buses that drm/i915 exposes.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
In some cases ioclt->alarm->ioctl loop can be infinite:
ioctl(7, 0x40086482, 0xbfb62738) = ? ERESTARTSYS (To be restarted)
--- SIGALRM (Alarm clock) @ 0 (0) ---
sigreturn() = ? (mask now [])
ioctl(7, 0x40086482, 0xbfb62738) = ? ERESTARTSYS (To be restarted)
and forever.
It seems, that limiting ioctl restarting by some resonable number of trys
is a dirty but working way to prevent Xorg lockups.
Signed-off-by: Anton V. Boyarshinov <boyarsh(a)…
[View More]altlinux.org>
---
xf86drm.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/xf86drm.c b/xf86drm.c
index 6ea068f..9663f21 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -162,10 +162,11 @@ int
drmIoctl(int fd, unsigned long request, void *arg)
{
int ret;
+ int count=0;
do {
ret = ioctl(fd, request, arg);
- } while (ret == -1 && (errno == EINTR || errno == EAGAIN));
+ } while (ret == -1 && (errno == EINTR || errno == EAGAIN) && ++count < 100 );
return ret;
}
--
1.7.5.4
[View Less]
The code should obviously check the EDID feature field for EDID feature flags
and not the color_formats field of the drm_display_info struct. Also update the
color_formats field with new modes instead of overwriting the current mode.
Signed-off-by: Lars-Peter Clausen <lars(a)metafoo.de>
Reviewed-by: Jesse Barnes <jbarnes(a)virtuousgeek.org>
---
drivers/gpu/drm/drm_edid.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/…
[View More]drivers/gpu/drm/drm_edid.c
index 5a18b0d..8a4580c 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1699,10 +1699,10 @@ static void drm_add_display_info(struct edid *edid,
}
info->color_formats = DRM_COLOR_FORMAT_RGB444;
- if (info->color_formats & DRM_EDID_FEATURE_RGB_YCRCB444)
- info->color_formats = DRM_COLOR_FORMAT_YCRCB444;
- if (info->color_formats & DRM_EDID_FEATURE_RGB_YCRCB422)
- info->color_formats = DRM_COLOR_FORMAT_YCRCB422;
+ if (edid->features & DRM_EDID_FEATURE_RGB_YCRCB444)
+ info->color_formats |= DRM_COLOR_FORMAT_YCRCB444;
+ if (edid->features & DRM_EDID_FEATURE_RGB_YCRCB422)
+ info->color_formats |= DRM_COLOR_FORMAT_YCRCB422;
/* Get data from CEA blocks if present */
edid_ext = drm_find_cea_extension(edid);
--
1.7.9.5
[View Less]
https://bugs.freedesktop.org/show_bug.cgi?id=36228
Chris Wilson <chris(a)chris-wilson.co.uk> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #6 from Chris Wilson <chris(a)chris-wilson.co.uk> 2012-04-16 05:46:28 PDT ---
Accidentally fixed in the meantime. Sigh.
--
…
[View More]Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[View Less]